Sitraer 7 (2008) 334-345 – Tr.

413

CONSIDERAÇÕES SOBRE REUSO DE SOFTWARE AVIÔNICO

Ítalo Romani de Oliveira

Atech Tecnologias Críticas

RESUMO
Os sistemas embarcados para comunicação, navegação e controle da aeronave, denominados
aviônicos, são críticos para a segurança de vôo e, por isso, passam por processos de
verificação e testes exigentes e custosos. Com o intuito de reduzir os custos de homologação e
certificação, os principais fabricantes de aeronaves estão investindo em componentes
padronizados e reutilizáveis. Este artigo científico explora os principais aspectos relacionados
ao reuso de software, começando por suas justificativas, apresentando suas dificuldades
teóricas e práticas, o panorama atual de aplicação desse conceito na indústria, e suas
perspectivas para o futuro.

1. INTRODUÇÃO
A operação de aeronaves comerciais modernas depende de sistemas computacionais para uma
grande variedade de propósitos. Alguns destes sistemas operam no solo, como os sistemas de
gerenciamento de tráfego aéreo, e outros operam a bordo das aeronaves, denominados
aviônicos, como pilotos automáticos e o sistema de climatização da cabine, entre outros.
Na maioria dos casos, os sistemas computacionais na aviação são críticos à segurança, pois
suas eventuais falhas podem contribuir para conseqüências catastróficas. Devido ao
importante impacto social relacionado à segurança de vôo e à complexidade dos sistemas
aviônicos, surge a necessidade de submeter o software aviônico a rigorosos processos de
verificação e testes, determinados e acompanhados por autoridades governamentais.

1.1.A evolução do uso de software em equipamentos aviônicos

A diminuição dos custos e dimensões físicas do hardware digital intensificou seu emprego na
aviação. Em alguns casos, implementações digitais substituiram aplicações analógicas, como
no caso do piloto automático; em outros casos, arquiteturas digitais possibilitaram a
introdução novos conceitos de sistema, como os FADEC – Full Authority Digital Engine
Controller-, que gerenciam com precisão a operação de motores aeronáuticos de grande porte,
fazendo monitoramento de parâmetros vitais, com detecção e gerenciamento de possíveis
falhas. Existem diversos outros exemplos de introdução de novos conceitos através de
sistemas digitais, como a navegação por satélite, a vigilância dependente automática, sistema
anti-colisão, para mencionar só alguns. Se, por um lado tais sistemas demonstram muitos
benefícios à eficiência e à segurança de vôo, eles aumentaram drasticamente a complexidade
do conjunto de sistemas embarcados, principalmente se for considerada a vasta quantidade de
linhas de código de programação. Sendo assim, o esforço para verificação e teste de software
aumentou proporcionalmente, anulando em parte o ganho de custo obtido com a evolução do
hardware.

1.2.Verificação e Validação de Software

Para obter o máximo de segurança nos itens de software de aeronaves civis, estes precisam ser
desenvolvidos e verificados de acordo com normas estabelecidas pelas autoridades
aeronáuticas do país ou região 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 países e regiões onde irá
operar. Para uniformizar os requisitos normativos e facilitar as autorizações para operação
internacional de aeronaves, as autoridades aeronáuticas locais estabelecem acordos. No caso
do Brasil, as normas para homologação de aeronaves civis são denominadas RBHA –
Regulamento Brasileiro de Homologação Aeronáutica (ANAC, 2008) que, por sua vez,
adotam como base as Federal Aviation Regulation (FAR) dos EUA. No que se refere a
software, tais regulamentações exigem o cumprimento da norma DO-178B (RTCA, 1992),
entitulada “Software Consideration in Airborne Systems and Equipment Certification”.

1.3.Certificação de Software Aeronáutico

Uma aeronave civil estará autorizada a operar somente quando receber o certificado de
homologação da autoridade aeronáutica, no caso do Brasil a Agência Nacional de Aviação
Civil (ANAC) e, para tal, deve haver evidência de que seu projeto foi desenvolvido de acordo
com as RBHA e, por causa dos acordos internacionais, o processo de certificação segue o
modelo de certificação da Federal Aviation Administration (FAA) dos EUA. De acordo com
esse processo, o certificado para operação (denominado Type Certificate ou TC) é concedido
para a aeronave como um todo, não para partes específicas da aeronave. Por outro lado, a
FAA estabelece uma lista de equipamentos padronizados, para os quais o processo de
certificação pode ser reaproveitado para a obtenção de um TC. Tais itens são comprovados de
atender a um conjunto específico de requisitos de desempenho determinados por meio de
Technical Standad Orders (TSO) (FAA, 2008), e assim evitam que a maior parte do trabalho
de verificação e validação associados a eles sejam refeitos. Entretanto, o conceito de TSO não
é aplicável para componentes de software isolados e, de acordo com essa lógica, qualquer
item de software que não esteja contido em um equipamento TSO precisa ser completamente
reavaliado, ab initio, em cada novo modelo de aeronave a ser lançado. Tal era a situação até
dezembro de 2004, quando a FAA lançou a circular AC 20-148 (FAA, 2004), regulamentando
o uso de componentes reutilizáveis de software.
Especialistas da indústria aeronáutica afirmam que o esforço para obtenção do certificado de
homologação 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 esforço de projetos anteriores, através dos componentes reutilizáveis.

2. O REUSO DE SOFTWARE EM APLICAÇÕES AVIÔNICAS

Segundo Adolph (1999), “se você perguntar a cinco programadores o que é reuso, você
obterá oito respostas diferentes”. Em seu artigo, Adolph tenta reforçar a idéia de que, para
fazer um reuso appropriado de software, é preciso que o software tenha sido projetado desde o
início 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 análise de requisito, arquitetura de domínio,
esquema de base de dados, código, documentação, manuais, normas, cenários 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 opção segura. A
explosão do foguete Ariane V em 1996 é um exemplo clássico de um evento catastrófico

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
diferenças entre os dois foguetes que não 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 aviônico que, desenvolvido para aeronaves no hemisfério norte e acima do nível do
mar, causa problemas para aeronaves no hemisfério sul ou operando em aeroportos abaixo do
nível do mar.
Outro risco relacionado ao reuso de software está associado à manutenção e à atualização do
sistema. Caso a documentação do software reutilizado seja deficiente, fica difícil para novos
desenvolvedores realizarem alterações e corrigirem problemas em artefatos de software
desenvolvidos por outros; de uma forma geral, se o software reutilizado não for estruturado
adequadamente para manutenção, alterações em uma pequena parte do software podem
introduzir erros em outras partes que não serão testadas no processo de manutenção e,
provavelmente, causarão falhas durante a operação do sistema.

2.2. Abordagens para reuso seguro de software

Com o intuito de minimizar os riscos associados ao reuso de software, algumas abordagens
têm sido aplicadas com sucesso na indústria de software crítico. Segundo Rierson (2000), são
elas:
Planejamento de Reuso: o reuso não acontece por acaso, ele precisa ser planejado e
gerenciado. Esta abordagem acontece no nível gerencial da empresa, e procura valorizar
algumas políticas gerenciais como a continuidade de pessoal entre projetos, assegurar
comprometimento dos gerentes com a estratégia de reuso, manter sempre ativo um grupo
especializado em técnicas de reuso, e dedicar esforços para construir modelos com técnicas de
abstração e modularização.
Engenharia de Domínio: um domínio é uma família de sistemas relacionados, que
compartilham funcionalidades, estruturas e modelos. A engenharia de domínio consiste em
analisar, projetar e implementar domínios gerenciáveis e reutilizáveis, resultando em uma
arquitetura que atenda às necessidades de uma área de aplicação. A engenharia de domínio
deve ser tal que minimize o esforço intelectual para passar de um estágio ao outro no
desenvolvimento de software.
Componentes de Software: o termo componente de software tem diversas definições,
contudo a definição básica adotada neste trabalho de pesquisa é a da norma DO-178B
(RTCA, 1992): “Uma parte auto-contida, combinação de partes, sub-montagens ou unidades,
que realiza uma funcionalidade distinta em um sistema”. O conceito de componente é
predominantemente herdado da indústria de hardware, em que os produtos finais nada mais
são do que uma montagem física de componentes claramente delimitados, que podem ser
reutilizados em uma ampla variedade de produtos. A idéia de trabalhar com componentes de
software reutilizáveis é uma abordagem importante para o reuso de software.
Orientação a Objeto: a orientação a objeto facilita o encapsulamento de dados e
funcionalidades, isolando a lógica interna de cada objeto da interação com o ambiente. Isso
facilita garantir que alterações internas de um objeto não introduzam erros ou
comportamentos inesperados em outras partes do sistema. Além disso, a aplicação do
conceito de herança permite gerenciar funcionalidades hierarquicamente e aumenta a
estabilidade na reutilização de código.

336
 Sitraer 7 (2008) 334-345 – Tr. 413

Portabilidade: um software possui portabilidade quando pode ser instalado em diferentes

configurações de hardware, com um mínimo de esforço para adaptação. O aspecto de
segurança requerido é que o software tenha sido projetado e testado para ser portável.
Commercial-Off-The-Shelf (COTS) Software: são softwares prontos e disponíveis ao
público. Esse tipo de software não é pensado para ser customizado ou estendido. O exemplo
mais comum na indústria de sistemas críticos são os sistemas operacionais de tempo real. As
vantagens de se utilizar COTS são o menor custo, o fato de ele já ter sido testado (ao menos
em baixo nível) e ter um histórico de serviço. Existem requisitos adicionais de segurança para
software COTS em sistemas críticos, que serão discutidos mais adiante.
Histórico de Serviço do Produto: o histórico de serviço permite ganhar confiança em um
determinado software ao longo do tempo de uso prévio e, de acordo com DO-178B, permite
substituir outras formas de verificação, desde que venha acompanhado de um processo
apropriado e devidamente documentado. A regulamentação sobre uso do histórico de serviço
de software na certificação 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 nível diferente de criticalidade. Por exemplo,
uma falha no piloto automático é muito mais grave que uma falha no sistema de troca de
mensagens com a companhia aérea (ACARS) e, sendo assim, os níveis de rigor exigido em
verificação e testes são diferentes, o que será explicado na próxima seção.

2.3. Níveis de Criticalidade de Software

A norma DO-178B (RTCA, 1992) estabelece cinco distintos níveis de criticalidade, de A a D,
baseados na contribuição do módulo ou componente de software para potenciais condições de
falha, a serem determinados em uma análise de segurança inicial do projeto. O nível de
criticalidade implicará uma certa quantidade de esforço requerida para demonstrar adequação
aos requisitos de certificação.
Existem algumas orientações para determinação do nível de criticalidade no próprio
documento DO-178B, mas elas não são exaustivas e, por isso, outro documento normativo é
utilizado como orientação 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 Análise Preliminar de Segurança do Sistema,
baseada em uma análise funcional de perigos (FHA – Functional Hazard Analysis) que, por
sua vez, deve contar com a elaboração de árvores de falhas para os perigos identificados. A
FHA fornece uma classificação do efeito de cada falha funcional, informação que, combinada
com a alocação de funcionalidades da arquitetura geral do sistema, permite determinar o nível
de criticalidade de cada módulo de software.
Resumindo, a distinção dos níveis de criticalidade permite alocar esforços de forma justa para
cada módulo ou componente de software. Do ponto de vista técnico, a modularização ou
componentização de software é a abordagem mais promissora para promover um reuso
eficiente e seguro de software. Este paradigma explora a idéia de erros e falhas em um
componente sejam devidamente isolados no ambiente e, além disso, explora a existência de
funcionalidades comuns em diversos modelos de aeronaves, diluindo o custo de
desenvolvimento. Entretanto, o emprego de componentes reutilizáveis deve estar de acordo
com os padrões normativos vigentes na aviação civil, que serão explicados nas próxima
seções.

337
 Sitraer 7 (2008) 334-345 – Tr. 413

3. PADRÕES NORMATIVOS RELACIONADOS À COMPONENTIZAÇÃO E

REUSO DE SOFTWARE AVIÔNICO
Conforme afirmado anteriormente neste artigo, até dezembro de 2004, a aprovação do
emprego de componentes reutilizáveis não contava com referência normativa e era avaliada
caso a caso, requerendo esforço e criatividade consideráveis dos stakeholders do projeto.
Naquele dado momento, foi publicada circular de orientação 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 nível de
criticalidade e, a partir desse momento, este produto de software pode ser instalado e operado
em qualquer plataforma e configuração de hardware previstos na documentação associada ao
certificado RSC, sem necessidade de ser re-submetido aos processos prescritos na norma DO-
178B. Contudo, a obtenção de um certificado RSC gera um considerável trabalho adicional,
se compararmos ao trabalho de aprovação de um componente “não-reutilizável”.
Por outro lado, é possível fazer uma outra abordagem, menos radical, baseada na idéia de
modularização, mas exigindo um pouco mais de retrabalho de verificação, testes e
documentação. Tal abordagem “mista” se apóia 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 década de 1990. As próximas seções apresentam uma visão
geral desses dois padrões normativos, e considerações a respeito da aplição de uma e de outra.

3.1. IMA – Integrated Modular Avionics

Há algumas décadas atrás, os sistemas aviônicos dentro de uma aeronave eram organizados
como uma federação de módulos independentes, tanto em hardware como em software,
conectados por barramentos de comunicação padronizados, sendo o padrão 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
alimentação própria, conforme ilustrado na Fig. 1.

Ambientação
da cabine

Gerenciamento Gerenc.
de combustível Rede de energia elétrica
comunicação

Controle do
trem de pouso

Gerenciamento
de vôo

Fig. 1: Arquitetura tradicional de módulos aplicativos federados.

338
 Sitraer 7 (2008) 334-345 – Tr. 413

O fato de esta arquitetura possuir módulos de hardware isolados, em diferentes posições da

aeronave, faz com que seja necessária uma grande quantidade de fios para a rede de
comunicação, inclusive porque o padrão ARINC 429 requer diversas conexões ponto-a-ponto.
Cada módulo de hardware pode ter um hardware diferente, com peças diferentes, o que
também contribui para tornar a manutenção cara.
Com a evolução do hardware digital, percebeu-se que uma organização mais centralizada do
hardware de processamento oferecia melhor desempenho, menor peso, menor consumo de
energia e, sobretudo, menor custo de aquisição e manutenção. Procurou-se então projetar
arquiteturas de sistema em que as diversas aplicações são meramente processos sendo
executados em um hardware compartilhado, conectado com outras unidades de hardware
genéricas, por meio de um barramento de comunicação de alta velocidade. Em determinados
casos, as unidades de hardware compartilhado são placas padronizadas e fisicamente
localizadas dentro de um único módulo genérico, compartilhando recursos como fonte de
alimentação, memória e armazenamento de dados, etc. Para orientar a elaboração 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

Módulo compartilhado 1

Módulo compartilhado 2
Aplicativos de software
Aplicativo 1 ... Aplicativo n
Aplicativo 2

Módulo compartilhado 3
Fonte de energia

Fig. 2: Arquitetura típica do conceito IMA.

Uma plataforma do tipo IMA deve ser capaz de prover particionamento robusto e outros
meios de proteção que permitam que múltiplas aplicações compartilhem os recursos comuns
dessa plataforma, princípio detalhado na norma ARINC 653 (ARINC, 2006a), ou suportar
funções distribuídas através de uma rede tolerante a falhas. A tolerância a falhas é obtida com
o uso de redundância física de todo o conjunto de módulos 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, não está automaticamente aprovado para utilização em
outros modelos de aeronaves. Isto significa que uma plataforma IMA não pode, de forma
nenhuma, ser tratada como uma “caixa preta” e, sendo assim, toda documentação sobre o
processo de desenvolvimento da mesma deve estar disponível nos subsequentes processos de
certificação, e uma quantidade considerável de testes podem ter que ser refeitos, caso as
diferenças de um modelo/configuração de aeronave para outra assim o exijam.

339
 Sitraer 7 (2008) 334-345 – Tr. 413

Alguns exemplos de aplicação da arquitetura IMA são o Boeing 777, e a plataforma Primus
Epic, desenolvida pela Honeywell e utilizada em aeronaves como as da família 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 utilizações subsequentes, dispense verificações 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 são somente os
testes de integração com o ambiente formado pelos outros componentes.
Um produto estará autorizado a ser utilizado como RSC quando receber uma carta de
aceitação RSC emitida pela FAA. A obtenção desta carta, entretanto, não é um processo
trivial. Em primeiro lugar, uma empresa desenvolvedora de software não pode obter uma cata
de aceitação RSC indepentendemente do fabricante de aeronave. De uma forma geral, a
aprovação 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 responsável por integrar o componente de software
reutilizável no hardware alvo e com outros componentes de software; tipicamente, o
integrador é a empresa que produz um sistema aviônico;
• Aplicante: é a empresa que busca a certificação ou autorização do sistema como um
todo; tipicamente, o aplicante é o fabricante da aeronave;
• Autoridade de Certificação: é a entidade ou pessoa representante da autoridade
aeronáutica que emitirá os certificados de aprovação do componente de software e da
aeronave como um todo.
Os papéis de desenvolvedor, integrador e aplicante podem ser acumulados por uma única
empresa.

3.2.2. Visão Geral do Processo RSC

A obtenção de uma carta de aceitação RSC, de acordo com (FAA, 2005), deve ser parte de
um processo maior de certificação de uma aeronave, e está é ilustrado na Fig. 3.
A primeira parte do processo RSC é chegar a um consenso de que o reuso é desejável e
alcançável. Após isso, é preciso produzir um Plano de Aspectos de Software para Certificação
(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.
Após isso, os stakeholders precisam alocar os créditos de certificação, isto é, definir quais
requisitos de certificação, 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 nível, em que cada linha de código deve ser testada,
ficam a cargo do desenvolvedor, enquanto os testes de integração 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
desejável e alcançável.

O desenvolvedor RSC, o integrador e o aplicante planejam o reuso.

O desenvolvedor RSC, o integrator, e o aplicante documentam

o crédito de reuso para cada objetivo DO-178B.

O PSAC é revisado e aprovado pelas autoridades

de certificação.

O RSC é desenvolvido de acordo com o plano, com

supervisão da autoridade de certificação.

A autoridade de certificação escreve a carta de

aceitação para o desenvolvedor e o aplicante

A mesma configuração e versão do RSC é

reutilizada em outros projetos, guardando as
devidas restrições.

Fig. 3: Abordagem para obtenção de uma carta de aceitação RSC.

A próxima 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 certificação. Por fim, quando o projeto estiver concluído e a autoridade de
certificação tiver evidências suficientes de que o RSC e o restante do projeto atingiram todos
os requisitos para obtenção dos créditos de certificação, será emitida a carta de aceitação RSC
e, concomitantemente, serão emitidos os certificados necessários para toda a aeronave.
Uma carta de aceitação RSC é válida para um determinado nível de criticalidade, para
algumas configurações específicas de hardware e, de maneira geral, para um conjunto de
hipóteses sobre o ambiente operacional, como por exemplo a carga de utilização do
processador, temporizações de comunicação, etc. Tais configurações e ambientes devem ser
especificados pelo desenvolvedor e aprovadas pela autoridade de certificação que, para isso,
deve ter evidências de que o conjunto de configurações e ambientes atendem aos requisitos de
certificação aplicáveis.

3.2.3. Uso de um RSC existente

Quando um integrador ou aplicante buscar a certificação de um novo projeto com um RSC
existente, diversos os testes relacionados à integração do RSC no ambiente operacional
precisam ser feitos “novamente”, como por exemplo:
• Análise de acoplamento de dados;
• Análise de acoplamento de controle;
• Análise de temporização;
• Análise de uso de memória;
• Testes de integração de software;
• Testes de integração hardware-software;
• Testes de robustez das funções do RSC, incluindo características de segurança e
proteção.

341
 Sitraer 7 (2008) 334-345 – Tr. 413

Conforme estabelecido em (FAA, 2005), se a autoridade de certificação levantar

questionamentos sobre estes aspectos, ela poderá reavaliar a documentação do ciclo de vida
do RSC e, sendo assim, o desenvolvedor do RSC precisa fornecer essa documentação.
Consequentemente, o RSC não pode ser tratado completamente como uma “caixa preta”.
Mais orientações sobre o processo para uso de um RSC existente podem ser encontrados em
(FAA, 2005).

3.2.4. Componentes RSC disponíveis no mercado

Atualmente existem somente três produtos de software no mercado que receberam a carta de
aceitação RSC. Um deles é um componente denominado vocoder, para codificação e
decodificação de voz em canais de comunicação VDL 3 (VHF Digital Link Mode 3),
desenvolvido pela empresa DVSI, e utilizado em módulos da empresa Rockwell-Collins; tal
componente está autorizado para reuso com nível C de criticalidade. Os outros dois RSC
existentes são sistemas operacionais de tempo real, sendo um deles o VxWorks, desenvolvido
pela empresa Wind River, já utilizado nas aeronaves Boeing 787 e 767 versão tanqueadora
(militar); e o outro é o LynxOS-178, desenvolvido pela empresa LinuxWorks, e atualmente
utilizado na aeronave tanqueadora KC-135. Ambos sistemas operacionais são autorizados
como nível A de criticalidade.
Tais RSC apresentam características peculiares que favorecem a obtenção do título de RSC.
No caso do vocoder, a característica mais favorável é a de ser uma funcionalidade muito bem
definida e delimitada, o que facilita a integração com outros componentes de software;
mesmo assim, a sua carta RSC admite apenas uma configuração de hardware. Já no caso do
VxWorks é justamente o fato de ele ser um sistema operacional de tempo real, que permite
que diversas aplicações 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 não ter que desenvolver toda a lógica de gerenciamento básico de sistema.

4. PANORAMA ATUAL DE REUSO DE SOFTWARE NA INDÚSTRIA

AERONÁUTICA
Esta seção descreve de maneira sucinta os casos de aplicação de reuso de software em dois
casos significativos da indústria aeronáutica 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 certificação pertinentes.

4.1. Reuso de Software no Airbus A380

A arquitetura geral de aviônicos no A380 está fortemente baseada no conceito de IMA
(ITIER, 2008). Os recursos comuns de hardware são uma rede de comunicação AFDX
(Avionics Full Duplex Ethernet), que possui diversos elementos em comum com as redes
Ethernet utilizadas em escritórios, mas com funcionamento em tempo real, e os módulos de
processamento, denominados CPIOM (Core Processing & Input / Output Modules), onde são
executados os softwares aplicativos, e os IOM (Input / Output Modules), que realizam tarefas
referentes a aquisição e transmissão de sinais.
Cada CPIOM ou IOM executa um sistema operacional desenvolvido pela própria Airbus, de
acordo com o padrão ARINC 653, e que foi projetado para ser reutilizado em projetos em
andamento na empresa, como os modelos A400M (cargueiro) e A350. Como o padrão

342
 Sitraer 7 (2008) 334-345 – Tr. 413

ARINC 653 isola os aplicativos do software básico, a modificação de aplicativos é altamente

facilitada.
Além das unidades centrais terem sido projetadas para reuso, existem diversos outros sistemas
periféricos que utilizam software COTS (Commercial-Of-The-Shelf, softwares prontos e
disponíveis 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 pressão da
cabine;
• O sistema operacional Integrity-178B é utilizado no sistema de monitoramento de motor e
no sistema de navegação do A380, além de também estar sendo utilizado em diversas
outras aeronaves;
• O sistema operacional LynxOS é utilizado para simulações e testes conjuntos dos diversos
módulos na rede AFDX;
• O sistema de informação a bordo (OIS – On-Board Information System), incorporado no
cockpit e utilizado para informações não críticas, como planejamento de vôo 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 diminuição do
custo de manutenção 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 não fora completamente concluído. Assim como o A380, ele se baseia
fortemente no conceito de IMA, indo um pouco além, 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 módulos redundantes que abrigam placas de
processamento, gerenciamento de energia, switches de rede, e ainda placas de aplicações
específicas, fornecidas por terceiros. Tais módulos são denominados CCR (Common
Computing Resource).
Outro elemento do CCS é a CDN (Common Data Network), fornecida pela empresa Rockwell
Collins, e constituída pelos switches dentro dos CCRs e outros espalhados pela aeronave, e
também por cabeamento ótico Ethernet. A solução CDN está passando por um processo de
definição formal em comitês da indústria, para ser reconhecida como compatível com o
padrão ARINC 664 (ARINC, 2006b), de forma similar ao padrão AFDX, citado na seção
anterior. Mesmo assim, a solução adotada no 787 possui concentradores de dados que
permitem comunicação com alguns equipamentos no padrão ARINC 429, que ainda estão
presentes.
Estima-se que o CCS abrigará entre 80 a 100 aplicações distintas, sendo que a maior parte
delas usa recursos compartilhados de hardware. Alguns exemplos dessas aplicações são: FMS
(Flight Management System), monitoramento geral de saúde operacional da aeronave, alertas
à tripulação, gerenciamento de: displays, trem de pouso, energia elétrica, sistema hidráulico,
ambientação da cabine, entre outros.

343
 Sitraer 7 (2008) 334-345 – Tr. 413

Alguns casos específicos 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 básico dos CCRs (processamento central da
aeronave);
• O sistema operacional Integrity-178B também é utilizado no 787, no subsistema da
Honeywell para gerenciamento de superfícies de controle aerodinâmico (fly-by-wire);
• As unidades de controle de carga elétrica (ELCU) utilizam software COTS de controle do
protocolo TTP, já citado no caso do A380.
• O gerenciamento de display utiliza o middleware (componentes intermediários de
software) MOSArt, fornecido pela empresa Barco, que é comercializado como COTS para
aplicações aviônicas.
Da mesma forma que no caso da Airbus, a Boeing e os usuários de suas aeronaves colherão
frutos do esforço de reuso de software em projetos futuros e ao longo da vida útil dos
aparelhos.
Outras aplicações, como o sistema de entretenimento de bordo, também utilizam COTS, ainda
que não podem ser chamadas propriamente de aplicações aviônicas, pois não influenciam na
missão de vôo da aeronave.

5. COMENTÁRIOS FINAIS
O uso de componentes padronizados e disponíveis no mercado é uma prática corriqueira
quando se trata de módulos eletrônicos isolados. Contudo, o reuso de componentes puramente
de software apresenta dificuldades adicionais, por causa de sua complexidade e do seu caráter
adaptativo. Este artigo apresentou diretrizes para elaboração de software reutilizável, e
também 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
reutilizáveis, 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 reutilizações futuras, mas não exime o integrador de
realizar todos os testes pertinentes à integração do componente no sistema e, eventualmente,
de despender esforço na reavaliação dos atributos do software reutilizado.
O reuso de software aviônico de forma intensiva e sistemática ainda está em sua fase inicial,
em que se realiza um esforço para desenvolver e consolidar os componentes fundamentais
para aplicação desse paradigma. Contudo, é possível conjecturar que nas próximas décadas
haverá uma aceleração na prática 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 regulamentações distintas. Esta aceleração do reuso de
software possibilitará consideráveis reduções de custo de desenvolvimento e manutenção,
permitindo direcionar recursos para a pesquisa de aeronaves cada vez mais eficientes e
seguras.

REFERÊNCIAS
ADOLPH, S. “Whatever Happened to Software Reuse?” Software Development, November 1999.
ANAC, Regulamento Brasileiro de Homologação Aeronáutica, sítio 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. Versões 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, sítio 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. SE-
12,10 (Oct. 1986), 997-1005.
ITIER, J-B. A380 Integrated Modular Avionics, apresentação disponível no sítio Web http://www.artist-
embedded.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. Master’s 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 Críticas: Rua do Rocio, 313, São Paulo SP, CEP 04552-000.
Email: iromani@atech.br.

345