Sitraer 7 (2008) 334-345 Tr.

413

CONSIDERAES SOBRE REUSO DE SOFTWARE AVINICO

talo Romani de Oliveira Atech Tecnologias Crticas

RESUMO Os sistemas embarcados para comunicao, navegao e controle da aeronave, denominados avinicos, so crticos para a segurana de vo e, por isso, passam por processos de verificao e testes exigentes e custosos. Com o intuito de reduzir os custos de homologao e certificao, os principais fabricantes de aeronaves esto investindo em componentes padronizados e reutilizveis. Este artigo cientfico explora os principais aspectos relacionados ao reuso de software, comeando por suas justificativas, apresentando suas dificuldades tericas e prticas, o panorama atual de aplicao desse conceito na indstria, e suas perspectivas para o futuro. 1. INTRODUO

A operao de aeronaves comerciais modernas depende de sistemas computacionais para uma grande variedade de propsitos. Alguns destes sistemas operam no solo, como os sistemas de gerenciamento de trfego areo, e outros operam a bordo das aeronaves, denominados avinicos, como pilotos automticos e o sistema de climatizao da cabine, entre outros. Na maioria dos casos, os sistemas computacionais na aviao so crticos segurana, pois suas eventuais falhas podem contribuir para conseqncias catastrficas. Devido ao importante impacto social relacionado segurana de vo e complexidade dos sistemas avinicos, surge a necessidade de submeter o software avinico a rigorosos processos de verificao e testes, determinados e acompanhados por autoridades governamentais. 1.1.A evoluo do uso de software em equipamentos avinicos A diminuio dos custos e dimenses fsicas do hardware digital intensificou seu emprego na aviao. Em alguns casos, implementaes digitais substituiram aplicaes analgicas, como no caso do piloto automtico; em outros casos, arquiteturas digitais possibilitaram a introduo novos conceitos de sistema, como os FADEC Full Authority Digital Engine Controller-, que gerenciam com preciso a operao de motores aeronuticos de grande porte, fazendo monitoramento de parmetros vitais, com deteco e gerenciamento de possveis falhas. Existem diversos outros exemplos de introduo de novos conceitos atravs de sistemas digitais, como a navegao por satlite, a vigilncia dependente automtica, sistema anti-coliso, para mencionar s alguns. Se, por um lado tais sistemas demonstram muitos benefcios eficincia e segurana de vo, eles aumentaram drasticamente a complexidade do conjunto de sistemas embarcados, principalmente se for considerada a vasta quantidade de linhas de cdigo de programao. Sendo assim, o esforo para verificao e teste de software aumentou proporcionalmente, anulando em parte o ganho de custo obtido com a evoluo do hardware. 1.2.Verificao e Validao de Software Para obter o mximo de segurana nos itens de software de aeronaves civis, estes precisam ser desenvolvidos e verificados de acordo com normas estabelecidas pelas autoridades aeronuticas do pas ou regio onde a aeronave ir operar. Logo, para que a aeronave opere

334

Sitraer 7 (2008) 334-345 Tr. 413

internacionalmente, ela deve atender aos requisitos de todos os pases e regies onde ir operar. Para uniformizar os requisitos normativos e facilitar as autorizaes para operao internacional de aeronaves, as autoridades aeronuticas locais estabelecem acordos. No caso do Brasil, as normas para homologao de aeronaves civis so denominadas RBHA Regulamento Brasileiro de Homologao Aeronutica (ANAC, 2008) que, por sua vez, adotam como base as Federal Aviation Regulation (FAR) dos EUA. No que se refere a software, tais regulamentaes exigem o cumprimento da norma DO-178B (RTCA, 1992), entitulada Software Consideration in Airborne Systems and Equipment Certification. 1.3.Certificao de Software Aeronutico Uma aeronave civil estar autorizada a operar somente quando receber o certificado de homologao da autoridade aeronutica, no caso do Brasil a Agncia Nacional de Aviao Civil (ANAC) e, para tal, deve haver evidncia de que seu projeto foi desenvolvido de acordo com as RBHA e, por causa dos acordos internacionais, o processo de certificao segue o modelo de certificao da Federal Aviation Administration (FAA) dos EUA. De acordo com esse processo, o certificado para operao (denominado Type Certificate ou TC) concedido para a aeronave como um todo, no para partes especficas da aeronave. Por outro lado, a FAA estabelece uma lista de equipamentos padronizados, para os quais o processo de certificao pode ser reaproveitado para a obteno de um TC. Tais itens so comprovados de atender a um conjunto especfico de requisitos de desempenho determinados por meio de Technical Standad Orders (TSO) (FAA, 2008), e assim evitam que a maior parte do trabalho de verificao e validao associados a eles sejam refeitos. Entretanto, o conceito de TSO no aplicvel para componentes de software isolados e, de acordo com essa lgica, qualquer item de software que no esteja contido em um equipamento TSO precisa ser completamente reavaliado, ab initio, em cada novo modelo de aeronave a ser lanado. Tal era a situao at dezembro de 2004, quando a FAA lanou a circular AC 20-148 (FAA, 2004), regulamentando o uso de componentes reutilizveis de software. Especialistas da indstria aeronutica afirmam que o esforo para obteno do certificado de homologao podem aumentar o custo do software em torno de 100%, dependendo da complexidade do projeto e a maturidade do processo de desenvolvimento. Sendo assim, existe um grande interesse em diminuir esse custo, e uma formas mais eficazes de faz-lo reaproveitar o esforo de projetos anteriores, atravs dos componentes reutilizveis. 2. O REUSO DE SOFTWARE EM APLICAES AVINICAS

Segundo Adolph (1999), se voc perguntar a cinco programadores o que reuso, voc obter oito respostas diferentes. Em seu artigo, Adolph tenta reforar a idia de que, para fazer um reuso appropriado de software, preciso que o software tenha sido projetado desde o incio para ser reutilizado, afirmando ainda que reuso diferente de resgate. De acordo com Sodhi e Sodhi (1999), reuso de software o processo de implementar e atualizar sistemas de software utilizando artefatos de software j existentes. Tais artefatos podem ser definidos como componentes, objetos, modelos de anlise de requisito, arquitetura de domnio, esquema de base de dados, cdigo, documentao, manuais, normas, cenrios de testes e planos. De qualquer forma, o reuso apresenta riscos, conforme explicado abaixo. 2.1. Alguns riscos associados ao reuso de software Est comprovado empiricamente que reuso de software nem sempre uma opo segura. A exploso do foguete Ariane V em 1996 um exemplo clssico de um evento catastrfico

335

Sitraer 7 (2008) 334-345 Tr. 413

resultante de reuso de software realizado indevidamente. A maior parte do software fora herdado do Ariane IV, e funcionava perfeitamente naquele modelo de foguete. Contudo, havia diferenas entre os dois foguetes que no foram propriamente consideradas, ocasionando o acidente. Alguns outros exemplos de acidentes graves causados por reuso indevido de software podem ser encontrados em (LEVESON, 1995), sendo que um deles se refere a um software avinico que, desenvolvido para aeronaves no hemisfrio norte e acima do nvel do mar, causa problemas para aeronaves no hemisfrio sul ou operando em aeroportos abaixo do nvel do mar. Outro risco relacionado ao reuso de software est associado manuteno e atualizao do sistema. Caso a documentao do software reutilizado seja deficiente, fica difcil para novos desenvolvedores realizarem alteraes e corrigirem problemas em artefatos de software desenvolvidos por outros; de uma forma geral, se o software reutilizado no for estruturado adequadamente para manuteno, alteraes em uma pequena parte do software podem introduzir erros em outras partes que no sero testadas no processo de manuteno e, provavelmente, causaro falhas durante a operao do sistema. 2.2. Abordagens para reuso seguro de software Com o intuito de minimizar os riscos associados ao reuso de software, algumas abordagens tm sido aplicadas com sucesso na indstria de software crtico. Segundo Rierson (2000), so elas: Planejamento de Reuso: o reuso no acontece por acaso, ele precisa ser planejado e gerenciado. Esta abordagem acontece no nvel gerencial da empresa, e procura valorizar algumas polticas gerenciais como a continuidade de pessoal entre projetos, assegurar comprometimento dos gerentes com a estratgia de reuso, manter sempre ativo um grupo especializado em tcnicas de reuso, e dedicar esforos para construir modelos com tcnicas de abstrao e modularizao. Engenharia de Domnio: um domnio uma famlia de sistemas relacionados, que compartilham funcionalidades, estruturas e modelos. A engenharia de domnio consiste em analisar, projetar e implementar domnios gerenciveis e reutilizveis, resultando em uma arquitetura que atenda s necessidades de uma rea de aplicao. A engenharia de domnio deve ser tal que minimize o esforo intelectual para passar de um estgio ao outro no desenvolvimento de software. Componentes de Software: o termo componente de software tem diversas definies, contudo a definio bsica adotada neste trabalho de pesquisa a da norma DO-178B (RTCA, 1992): Uma parte auto-contida, combinao de partes, sub-montagens ou unidades, que realiza uma funcionalidade distinta em um sistema. O conceito de componente predominantemente herdado da indstria de hardware, em que os produtos finais nada mais so do que uma montagem fsica de componentes claramente delimitados, que podem ser reutilizados em uma ampla variedade de produtos. A idia de trabalhar com componentes de software reutilizveis uma abordagem importante para o reuso de software. Orientao a Objeto: a orientao a objeto facilita o encapsulamento de dados e funcionalidades, isolando a lgica interna de cada objeto da interao com o ambiente. Isso facilita garantir que alteraes internas de um objeto no introduzam erros ou comportamentos inesperados em outras partes do sistema. Alm disso, a aplicao do conceito de herana permite gerenciar funcionalidades hierarquicamente e aumenta a estabilidade na reutilizao de cdigo.

336

Sitraer 7 (2008) 334-345 Tr. 413

Portabilidade: um software possui portabilidade quando pode ser instalado em diferentes configuraes de hardware, com um mnimo de esforo para adaptao. O aspecto de segurana requerido que o software tenha sido projetado e testado para ser portvel. Commercial-Off-The-Shelf (COTS) Software: so softwares prontos e disponveis ao pblico. Esse tipo de software no pensado para ser customizado ou estendido. O exemplo mais comum na indstria de sistemas crticos so os sistemas operacionais de tempo real. As vantagens de se utilizar COTS so o menor custo, o fato de ele j ter sido testado (ao menos em baixo nvel) e ter um histrico de servio. Existem requisitos adicionais de segurana para software COTS em sistemas crticos, que sero discutidos mais adiante. Histrico de Servio do Produto: o histrico de servio permite ganhar confiana em um determinado software ao longo do tempo de uso prvio e, de acordo com DO-178B, permite substituir outras formas de verificao, desde que venha acompanhado de um processo apropriado e devidamente documentado. A regulamentao sobre uso do histrico de servio de software na certificao pode ser encontrada em (FAA, 2002). Tais abordagens favorecem o reuso eficiente e seguro de software, mas importante observar que cada componente de software pode ter um nvel diferente de criticalidade. Por exemplo, uma falha no piloto automtico muito mais grave que uma falha no sistema de troca de mensagens com a companhia area (ACARS) e, sendo assim, os nveis de rigor exigido em verificao e testes so diferentes, o que ser explicado na prxima seo. 2.3. Nveis de Criticalidade de Software A norma DO-178B (RTCA, 1992) estabelece cinco distintos nveis de criticalidade, de A a D, baseados na contribuio do mdulo ou componente de software para potenciais condies de falha, a serem determinados em uma anlise de segurana inicial do projeto. O nvel de criticalidade implicar uma certa quantidade de esforo requerida para demonstrar adequao aos requisitos de certificao. Existem algumas orientaes para determinao do nvel de criticalidade no prprio documento DO-178B, mas elas no so exaustivas e, por isso, outro documento normativo utilizado como orientao nesta tarefa, denominado Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment (SAE, 1996b). Tal documento recomenda que seja feita uma Anlise Preliminar de Segurana do Sistema, baseada em uma anlise funcional de perigos (FHA Functional Hazard Analysis) que, por sua vez, deve contar com a elaborao de rvores de falhas para os perigos identificados. A FHA fornece uma classificao do efeito de cada falha funcional, informao que, combinada com a alocao de funcionalidades da arquitetura geral do sistema, permite determinar o nvel de criticalidade de cada mdulo de software. Resumindo, a distino dos nveis de criticalidade permite alocar esforos de forma justa para cada mdulo ou componente de software. Do ponto de vista tcnico, a modularizao ou componentizao de software a abordagem mais promissora para promover um reuso eficiente e seguro de software. Este paradigma explora a idia de erros e falhas em um componente sejam devidamente isolados no ambiente e, alm disso, explora a existncia de funcionalidades comuns em diversos modelos de aeronaves, diluindo o custo de desenvolvimento. Entretanto, o emprego de componentes reutilizveis deve estar de acordo com os padres normativos vigentes na aviao civil, que sero explicados nas prxima sees.

337

Sitraer 7 (2008) 334-345 Tr. 413

3.

PADRES NORMATIVOS RELACIONADOS COMPONENTIZAO E REUSO DE SOFTWARE AVINICO

Conforme afirmado anteriormente neste artigo, at dezembro de 2004, a aprovao do emprego de componentes reutilizveis no contava com referncia normativa e era avaliada caso a caso, requerendo esforo e criatividade considerveis dos stakeholders do projeto. Naquele dado momento, foi publicada circular de orientao AC 20-148 (FAA, 2004), entitulada Reusable Software Components (RSC), que estabeleceu uma nova era para o reuso de componentes de software. Com ela, uma empresa desenvolvedora de software pode obter um certificado RSC para o seu produto, associado a um determinado nvel de criticalidade e, a partir desse momento, este produto de software pode ser instalado e operado em qualquer plataforma e configurao de hardware previstos na documentao associada ao certificado RSC, sem necessidade de ser re-submetido aos processos prescritos na norma DO178B. Contudo, a obteno de um certificado RSC gera um considervel trabalho adicional, se compararmos ao trabalho de aprovao de um componente no-reutilizvel. Por outro lado, possvel fazer uma outra abordagem, menos radical, baseada na idia de modularizao, mas exigindo um pouco mais de retrabalho de verificao, testes e documentao. Tal abordagem mista se apia no conceito de Integrated Modular Avionics (IMA), que definido na norma RTCA DO-297 (RTCA, 2005), e j era aplicado informalmente desde o final da dcada de 1990. As prximas sees apresentam uma viso geral desses dois padres normativos, e consideraes a respeito da aplio de uma e de outra. 3.1. IMA Integrated Modular Avionics H algumas dcadas atrs, os sistemas avinicos dentro de uma aeronave eram organizados como uma federao de mdulos independentes, tanto em hardware como em software, conectados por barramentos de comunicao padronizados, sendo o padro ARINC 429 um dos mais difundidos (ARINC, 1978-1995), tendo sido utilizado em aeronaves como Airbus A310, A320, A340, Boeing 737-300, 747-400, e 767. Cada funcionalidade dentro da aeronave ficava confinado a uma unidade fisicamente independente, em uma caixa com fonte de alimentao prpria, conforme ilustrado na Fig. 1.

Ambientao da cabine Gerenciamento de combustvel Gerenc. energia eltrica

Rede de comunicao

Controle do trem de pouso Gerenciamento de vo Fig. 1: Arquitetura tradicional de mdulos aplicativos federados.

338

Sitraer 7 (2008) 334-345 Tr. 413

O fato de esta arquitetura possuir mdulos de hardware isolados, em diferentes posies da aeronave, faz com que seja necessria uma grande quantidade de fios para a rede de comunicao, inclusive porque o padro ARINC 429 requer diversas conexes ponto-a-ponto. Cada mdulo de hardware pode ter um hardware diferente, com peas diferentes, o que tambm contribui para tornar a manuteno cara. Com a evoluo do hardware digital, percebeu-se que uma organizao mais centralizada do hardware de processamento oferecia melhor desempenho, menor peso, menor consumo de energia e, sobretudo, menor custo de aquisio e manuteno. Procurou-se ento projetar arquiteturas de sistema em que as diversas aplicaes so meramente processos sendo executados em um hardware compartilhado, conectado com outras unidades de hardware genricas, por meio de um barramento de comunicao de alta velocidade. Em determinados casos, as unidades de hardware compartilhado so placas padronizadas e fisicamente localizadas dentro de um nico mdulo genrico, compartilhando recursos como fonte de alimentao, memria e armazenamento de dados, etc. Para orientar a elaborao de arquiteturas de sistema deste tipo, sugiu o conceito de Integrated Modular Avionics (IMA) (RTCA, 2005), que versa tanto sobre aspectos de hardware como de software.

Fonte de energia Mdulo compartilhado 1 Mdulo compartilhado 2 Aplicativos de software Aplicativo 1 ... Aplicativo n Aplicativo 2 Mdulo compartilhado 3 Fonte de energia Fig. 2: Arquitetura tpica do conceito IMA.

Uma plataforma do tipo IMA deve ser capaz de prover particionamento robusto e outros meios de proteo que permitam que mltiplas aplicaes compartilhem os recursos comuns dessa plataforma, princpio detalhado na norma ARINC 653 (ARINC, 2006a), ou suportar funes distribudas atravs de uma rede tolerante a falhas. A tolerncia a falhas obtida com o uso de redundncia fsica de todo o conjunto de mdulos compartilhados. Apesar do particionamento robusto da arquitetura IMA, o projeto de uma plataforma de acordo com a norma RTCA DO-297 (RTCA, 2005), mesmo tendo sido certificado para ser usado em um modelo de aeronave, no est automaticamente aprovado para utilizao em outros modelos de aeronaves. Isto significa que uma plataforma IMA no pode, de forma nenhuma, ser tratada como uma caixa preta e, sendo assim, toda documentao sobre o processo de desenvolvimento da mesma deve estar disponvel nos subsequentes processos de certificao, e uma quantidade considervel de testes podem ter que ser refeitos, caso as diferenas de um modelo/configurao de aeronave para outra assim o exijam.

339

Sitraer 7 (2008) 334-345 Tr. 413

Alguns exemplos de aplicao da arquitetura IMA so o Boeing 777, e a plataforma Primus Epic, desenolvida pela Honeywell e utilizada em aeronaves como as da famlia 170/190 da Embraer, e jatos executivos Gulfstream, Cessna Citation Sovereign e Dassault Falcon, entre outros. 3.2. RSC Reusable Software Components O conceito RSC foi formalizado na circular AC 20-148 (FAA, 2004), que estabeleceu diretivas para que um determinado componente de software seja certificado apenas uma vez como RSC e, em utilizaes subsequentes, dispense verificaes e testes sobre seu funcionamento interno. Desta forma, um RSC, em determinados aspectos, pode ser tratado como uma caixa preta, e os testes a serem refeitos com esse componente so somente os testes de integrao com o ambiente formado pelos outros componentes. Um produto estar autorizado a ser utilizado como RSC quando receber uma carta de aceitao RSC emitida pela FAA. A obteno desta carta, entretanto, no um processo trivial. Em primeiro lugar, uma empresa desenvolvedora de software no pode obter uma cata de aceitao RSC indepentendemente do fabricante de aeronave. De uma forma geral, a aprovao e reuso de um RSC envolve alguns stakeholders, definidos a seguir. 3.2.1. Stakeholders do Processo RSC Desenvolvedor: a empresa que desenvolve o software; Integrador: a empresa responsvel por integrar o componente de software reutilizvel no hardware alvo e com outros componentes de software; tipicamente, o integrador a empresa que produz um sistema avinico; Aplicante: a empresa que busca a certificao ou autorizao do sistema como um todo; tipicamente, o aplicante o fabricante da aeronave; Autoridade de Certificao: a entidade ou pessoa representante da autoridade aeronutica que emitir os certificados de aprovao do componente de software e da aeronave como um todo. Os papis de desenvolvedor, integrador e aplicante podem ser acumulados por uma nica empresa. 3.2.2. Viso Geral do Processo RSC A obteno de uma carta de aceitao RSC, de acordo com (FAA, 2005), deve ser parte de um processo maior de certificao de uma aeronave, e est ilustrado na Fig. 3. A primeira parte do processo RSC chegar a um consenso de que o reuso desejvel e alcanvel. Aps isso, preciso produzir um Plano de Aspectos de Software para Certificao (PSAC Plan for Software Aspects of Certification), tanto para o RSC, o que ser feito pelo desenvolvedor como para a aeronave como um todo, o que ser feito pelo aplicante. Aps isso, os stakeholders precisam alocar os crditos de certificao, isto , definir quais requisitos de certificao, dentre aqueles exigidos pela norma DO-178B, devem ser atendidos pelo RSC e seu desenvolvedor, e quais requisitos devem ser atendidos pelo integrador ou pelo aplicante. Por exemplo, os testes de baixo nvel, em que cada linha de cdigo deve ser testada, ficam a cargo do desenvolvedor, enquanto os testes de integrao do componente com outros elementos do sistema ficam a cargo do integrador ou do aplicante.

340

Sitraer 7 (2008) 334-345 Tr. 413

Os stakeholders (incluindo aplicante, integrador, desenvolvedor RSC, e autoridade de cert.) concordam que o reuso uma meta desejvel e alcanvel. O desenvolvedor RSC, o integrador e o aplicante planejam o reuso. O desenvolvedor RSC, o integrator, e o aplicante documentam o crdito de reuso para cada objetivo DO-178B. O PSAC revisado e aprovado pelas autoridades de certificao. O RSC desenvolvido de acordo com o plano, com superviso da autoridade de certificao. A autoridade de certificao escreve a carta de aceitao para o desenvolvedor e o aplicante A mesma configurao e verso do RSC reutilizada em outros projetos, guardando as devidas restries.

Fig. 3: Abordagem para obteno de uma carta de aceitao RSC.

A prxima etapa consiste no desenvolvimento do RSC e dos outros elementos do sistema com os quais ele ir operar. Tal processo deve ser acompanhado periodicamente pelo representante da autoridade de certificao. Por fim, quando o projeto estiver concludo e a autoridade de certificao tiver evidncias suficientes de que o RSC e o restante do projeto atingiram todos os requisitos para obteno dos crditos de certificao, ser emitida a carta de aceitao RSC e, concomitantemente, sero emitidos os certificados necessrios para toda a aeronave. Uma carta de aceitao RSC vlida para um determinado nvel de criticalidade, para algumas configuraes especficas de hardware e, de maneira geral, para um conjunto de hipteses sobre o ambiente operacional, como por exemplo a carga de utilizao do processador, temporizaes de comunicao, etc. Tais configuraes e ambientes devem ser especificados pelo desenvolvedor e aprovadas pela autoridade de certificao que, para isso, deve ter evidncias de que o conjunto de configuraes e ambientes atendem aos requisitos de certificao aplicveis. 3.2.3. Uso de um RSC existente Quando um integrador ou aplicante buscar a certificao de um novo projeto com um RSC existente, diversos os testes relacionados integrao do RSC no ambiente operacional precisam ser feitos novamente, como por exemplo: Anlise de acoplamento de dados; Anlise de acoplamento de controle; Anlise de temporizao; Anlise de uso de memria; Testes de integrao de software; Testes de integrao hardware-software; Testes de robustez das funes do RSC, incluindo caractersticas de segurana e proteo.
341

Sitraer 7 (2008) 334-345 Tr. 413

Conforme estabelecido em (FAA, 2005), se a autoridade de certificao levantar questionamentos sobre estes aspectos, ela poder reavaliar a documentao do ciclo de vida do RSC e, sendo assim, o desenvolvedor do RSC precisa fornecer essa documentao. Consequentemente, o RSC no pode ser tratado completamente como uma caixa preta. Mais orientaes sobre o processo para uso de um RSC existente podem ser encontrados em (FAA, 2005). 3.2.4. Componentes RSC disponveis no mercado Atualmente existem somente trs produtos de software no mercado que receberam a carta de aceitao RSC. Um deles um componente denominado vocoder, para codificao e decodificao de voz em canais de comunicao VDL 3 (VHF Digital Link Mode 3), desenvolvido pela empresa DVSI, e utilizado em mdulos da empresa Rockwell-Collins; tal componente est autorizado para reuso com nvel C de criticalidade. Os outros dois RSC existentes so sistemas operacionais de tempo real, sendo um deles o VxWorks, desenvolvido pela empresa Wind River, j utilizado nas aeronaves Boeing 787 e 767 verso tanqueadora (militar); e o outro o LynxOS-178, desenvolvido pela empresa LinuxWorks, e atualmente utilizado na aeronave tanqueadora KC-135. Ambos sistemas operacionais so autorizados como nvel A de criticalidade. Tais RSC apresentam caractersticas peculiares que favorecem a obteno do ttulo de RSC. No caso do vocoder, a caracterstica mais favorvel a de ser uma funcionalidade muito bem definida e delimitada, o que facilita a integrao com outros componentes de software; mesmo assim, a sua carta RSC admite apenas uma configurao de hardware. J no caso do VxWorks justamente o fato de ele ser um sistema operacional de tempo real, que permite que diversas aplicaes compartilhem de forma robusta e segura os mesmos recursos de hardware, conforme recomendado no conceito de IMA, e oferecendo para o integrador a vantagem de no ter que desenvolver toda a lgica de gerenciamento bsico de sistema. 4. PANORAMA ATUAL DE REUSO DE SOFTWARE NA INDSTRIA AERONUTICA

Esta seo descreve de maneira sucinta os casos de aplicao de reuso de software em dois casos significativos da indstria aeronutica moderna, o Airbus A380 e o Boeing 787. Os exemplos citados nem sempre se referem a RSC autorizados conforme (FAA, 2005) e, nestes casos, os artefatos do ciclo de vida do software reutilizado podem ter sidos reavaliados nos processos de certificao pertinentes. 4.1. Reuso de Software no Airbus A380 A arquitetura geral de avinicos no A380 est fortemente baseada no conceito de IMA (ITIER, 2008). Os recursos comuns de hardware so uma rede de comunicao AFDX (Avionics Full Duplex Ethernet), que possui diversos elementos em comum com as redes Ethernet utilizadas em escritrios, mas com funcionamento em tempo real, e os mdulos de processamento, denominados CPIOM (Core Processing & Input / Output Modules), onde so executados os softwares aplicativos, e os IOM (Input / Output Modules), que realizam tarefas referentes a aquisio e transmisso de sinais. Cada CPIOM ou IOM executa um sistema operacional desenvolvido pela prpria Airbus, de acordo com o padro ARINC 653, e que foi projetado para ser reutilizado em projetos em andamento na empresa, como os modelos A400M (cargueiro) e A350. Como o padro

342

Sitraer 7 (2008) 334-345 Tr. 413

ARINC 653 isola os aplicativos do software bsico, a modificao de aplicativos altamente facilitada. Alm das unidades centrais terem sido projetadas para reuso, existem diversos outros sistemas perifricos que utilizam software COTS (Commercial-Of-The-Shelf, softwares prontos e disponveis no mercado), como por exemplo: O software de controle do protocolo TTP (Time-Triggered Protocol), comercializado pela empresa TTTech desde 2002, utilizado no A380 no sistema de controle de presso da cabine; O sistema operacional Integrity-178B utilizado no sistema de monitoramento de motor e no sistema de navegao do A380, alm de tambm estar sendo utilizado em diversas outras aeronaves; O sistema operacional LynxOS utilizado para simulaes e testes conjuntos dos diversos mdulos na rede AFDX; O sistema de informao a bordo (OIS On-Board Information System), incorporado no cockpit e utilizado para informaes no crticas, como planejamento de vo e cartas, baseado no sistema operacional Windows XP.

O projeto A380 foi um dos primeiros onde se planejou um reuso mais intensivo de software, e acredita-se que mais frutos sejam colhidos em projetos futuros, inclusive na diminuio do custo de manuteno do sistema. 4.2. Reuso de Software no Boeing 787 O Boeing 787 um projeto ainda mais recente que o A380 e, at a data de escrita do presente artigo, ainda no fora completamente concludo. Assim como o A380, ele se baseia fortemente no conceito de IMA, indo um pouco alm, pois seu sistema central de processamento utiliza um sistema operacional autorizado como RSC pela FAA. O sistema de processamento central do 787, denominado CCS (Common Core System), foi desenvolvido pela empresa Smiths e possui dois mdulos redundantes que abrigam placas de processamento, gerenciamento de energia, switches de rede, e ainda placas de aplicaes especficas, fornecidas por terceiros. Tais mdulos so denominados CCR (Common Computing Resource). Outro elemento do CCS a CDN (Common Data Network), fornecida pela empresa Rockwell Collins, e constituda pelos switches dentro dos CCRs e outros espalhados pela aeronave, e tambm por cabeamento tico Ethernet. A soluo CDN est passando por um processo de definio formal em comits da indstria, para ser reconhecida como compatvel com o padro ARINC 664 (ARINC, 2006b), de forma similar ao padro AFDX, citado na seo anterior. Mesmo assim, a soluo adotada no 787 possui concentradores de dados que permitem comunicao com alguns equipamentos no padro ARINC 429, que ainda esto presentes. Estima-se que o CCS abrigar entre 80 a 100 aplicaes distintas, sendo que a maior parte delas usa recursos compartilhados de hardware. Alguns exemplos dessas aplicaes so: FMS (Flight Management System), monitoramento geral de sade operacional da aeronave, alertas tripulao, gerenciamento de: displays, trem de pouso, energia eltrica, sistema hidrulico, ambientao da cabine, entre outros.

343

Sitraer 7 (2008) 334-345 Tr. 413

Alguns casos especficos de reuso de software no 787 podem ser citados: O sistema operacional VxWorks um produto COTS autorizado como RSC, sendo utilizado como o sistema operacional bsico dos CCRs (processamento central da aeronave); O sistema operacional Integrity-178B tambm utilizado no 787, no subsistema da Honeywell para gerenciamento de superfcies de controle aerodinmico (fly-by-wire); As unidades de controle de carga eltrica (ELCU) utilizam software COTS de controle do protocolo TTP, j citado no caso do A380. O gerenciamento de display utiliza o middleware (componentes intermedirios de software) MOSArt, fornecido pela empresa Barco, que comercializado como COTS para aplicaes avinicas.

Da mesma forma que no caso da Airbus, a Boeing e os usurios de suas aeronaves colhero frutos do esforo de reuso de software em projetos futuros e ao longo da vida til dos aparelhos. Outras aplicaes, como o sistema de entretenimento de bordo, tambm utilizam COTS, ainda que no podem ser chamadas propriamente de aplicaes avinicas, pois no influenciam na misso de vo da aeronave. 5. COMENTRIOS FINAIS

O uso de componentes padronizados e disponveis no mercado uma prtica corriqueira quando se trata de mdulos eletrnicos isolados. Contudo, o reuso de componentes puramente de software apresenta dificuldades adicionais, por causa de sua complexidade e do seu carter adaptativo. Este artigo apresentou diretrizes para elaborao de software reutilizvel, e tambm para o reuso de componentes existentes em novos projetos, com base em regulamentos normativos aceitos internacionalmente. De uma forma geral, componentes de software precisam ter atributos especiais para ser reutilizveis, sendo que o mais importante deles ter sido projetado para reuso. O fato de um componente ter sido reconhecido oficialmente como RSC Reusable Software Component pela FAA uma grande ajuda para suas reutilizaes futuras, mas no exime o integrador de realizar todos os testes pertinentes integrao do componente no sistema e, eventualmente, de despender esforo na reavaliao dos atributos do software reutilizado. O reuso de software avinico de forma intensiva e sistemtica ainda est em sua fase inicial, em que se realiza um esforo para desenvolver e consolidar os componentes fundamentais para aplicao desse paradigma. Contudo, possvel conjecturar que nas prximas dcadas haver uma acelerao na prtica do reuso, devido aos sucessos obtidos em projetos como o Airbus A380 e Boeing 787, na rea civil, apresentados neste artigo, e diversos outros, incluindo a rea militar, que possui regulamentaes distintas. Esta acelerao do reuso de software possibilitar considerveis redues de custo de desenvolvimento e manuteno, permitindo direcionar recursos para a pesquisa de aeronaves cada vez mais eficientes e seguras.
REFERNCIAS ADOLPH, S. Whatever Happened to Software Reuse? Software Development, November 1999. ANAC, Regulamento Brasileiro de Homologao Aeronutica, stio Web http://www.anac.gov.br/biblioteca/rbha.asp, acessado em junho de 2008.

344

Sitraer 7 (2008) 334-345 Tr. 413

ARINC Standards, 429(XX) Series, Aeronautical Radio Incorporated. Verses diversas entre 1978 e 1995. ARINC Standards, 653(XX) Series, Aeronautical Radio Incorporated, 2006a. ARINC Standards, 664(XX) Series, Aeronautical Radio Incorporated, 2006b. FAA, Current TSOs by Number, stio Web http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgTSO.nsf/MainFrame?OpenFrameSet , acessado em junho de 2008. FAA, Reusable Software Components. Advisory Circular (AC) 20-148, December 7, 2004. FAA, Software Service History Handbook. DOT/FAA/AR-01/116, February 2002. HOWDEN, W.E.: A Functional Approach to Program Testing and Analysis. IEEE Trans. Software Eng. SE12,10 (Oct. 1986), 997-1005. ITIER, J-B. A380 Integrated Modular Avionics, apresentao disponvel no stio Web http://www.artistembedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_Itier.pdf , acessado em julho de 2008. KNIGHT, J.C.; Software Challenges in Aviation Systems. Lecture Notes in Computer Science, vol. 2434, Springer, 2002. LEVESON, Nancy. Safeware: System Safety and Computers. Addison-Wesley, 1995. POWELL, P.B.: Software Validation, Verification and Testing Technique and Tool Reference Guide. In Software Validation, Verification, Testing and Documentation, S.J. Andriole, ed. Princeton, N.J.: Petrocelli, 1986, 189-310. RIERSON, L. Software Reuse in Safety-Critical Systems. Masters Thesis, Rochester Institute of Technology, May 2000. RIERSON, L. Software Reuse in Airborne Systems. IVT course # 62386. Aircraft Certification Service, Federal Aviation Administration, October 2003. RTCA Incorporated: Software Considerations in Airborne Systems and Equipment Certification. RTCA document number RTCA/DO-178B, 1992. RTCA Incorporated: Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations. RTCA document number RTCA/DO-297, 2005. SAE, Certification Considerations for Highly Integrated or Complex Aircraft Systems, Aerospace Recommended Practice (ARP) 4754, April 10, 1996(a). SAE, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, Aerospace Recommended Practice (ARP) 4761, Issue 12, 1996(b). SODHI, J.; SODHI, P. Software Reuse: Domain Analysis and Design Process. McGraw-Hill, 1999. talo Romani de Oliveira, Atech Tecnologias Crticas: Rua do Rocio, 313, So Paulo SP, CEP 04552-000. Email: iromani@atech.br.

345