Modelos Arquiteturais em Sistemas Aviônicos

   Antes de me aventurar no domínio de sistemas embarcados, trabalhei com desenvolvimento de sistemas financeiros e de administração público-privada. Diversas vezes, ao perguntar por modelos arquiteturais do sistema, era informado que ele era inexistente estava desatualizado. Depois de algum tempo nesse contexto, me juntei ao grupo de profissionais que acreditam que um bom código fonte e algumas linhas de comentário são suficientes enquanto documentação.

A realidade no domínio de embarcados é bem diferente. Entidades que regulamentam sistemas que, em caso de falha, causarão danos à pessoas ou ao meio-ambiente (mais conhecidos como sistemas safety-critical), exigem que as empresas que constroem esses sistemas sigam rigidamente as etapas dos processos de desenvolvimento, e gerem artefatos de documentação extremamente detalhados.

No caso de sistemas aviônicos, o DO-178B – Software Considerations in Airborne Systems and Equipment Certification, por exemplo, define processos rígidos para (i) Planejamento, (ii) Desenvolvimento, (iii) Requisitos, (iv) Design, (v) Codificação e Integração, (vi) Teste e Verificação, (vii) Gerencia de configuração, e (viii) Gerenciamento de qualidade. Para se ter uma ideia geral das etapas e artefatos, recomendo uma olhada na seguinte apresentação: Introduction to Avionic Systems Development.

Um dos artefatos exigidos pelo DO-178B é a documentação arquitetural dos vários sistemas que compõe um sistemas aviônico: diagramas de componentes, diagramas comportamentais de tempo-continuo e de estados, dentre outros.

Alem de servir para documentação, esses modelos são usados como base para geração de código funcional. Essa historia de geração automática de código soava um tanto quanto utópica para mim também, até que, certa vez, o chefe da engenharia de uma grande empresa de aviação me disse que não confiava em códigos escritos por desenvolvedores, mas sim em códigos gerados a partir de especificações arquiteturais. Tentando entender o que se passava na cabeça desse cidadão, comecei a me inteirar mais sobre o assunto, e me convenci do quão poderosos mecanismos de geração de código podem ser quando utilizados apropriadamente. Para uma visão prática sobre o assunto, recomendo conhecerem um pouco sobre ferramentas como OpenArchitectureware e Acceleo.

Esses modelos são também peças-chave nos processos de garantia de qualidade, que vão desde testes baseados em modelos à técnicas formais de Model-Checking (sim, estou falando de assuntos relacionados a métodos formais. Eles são amplamente utilizados na industria aviônica). Toda essa amarração exigida pelas normas regulatórias implica em lentidão no desenvolvimento, e, quando não gerido adequadamente, pode gerar atrasos consideráveis na entrega do produto (ver caso do Boeing 787 Dreamliner). No entanto, empresas que desenvolvem esses produtos muitas vezes optam por atrasos aceitáveis no time-to-markt, mas assegurar que os produtos são feitos como manda a norma; caso contrário, o prejuízo financeiro será ainda maior, e a reputação da empresa desaparece.

Aí vai um recado para turma do “anti-modelos-e-apenas-código-escrito-é-o-que-conta”: Sistemas dessa natureza não podem falhar! Não existe possibilidade de reiniciar o sistema de navegação ou de propulsão de uma aeronave enquanto ela voa a 900Km/h a uma altitude de 30000 pés. O custo de voltar a versão de um software depois que ele já foi inserido em uma família de jatos tem um custo que pode comprometer o projeto como um todo. Não estamos tratando de sistemas web; também não quero dizer que estes sejam menos complexos ou de menor importância; digo apenas que as restrições de domínio são mais rígidas, levando em conta as catástrofes causadas se um sistema desse falhar.

Anúncios

5 comentários sobre “Modelos Arquiteturais em Sistemas Aviônicos

  1. ok, entao talvez em sistemas que nao sejam críticos ou safety relevant ou que nao necessitem se enquadrar em nenhum padrao estabelecido podemos considerar modelos arquiteturais (em sua grande maioria) desnecessários (pra nao dizer inúteis)? Qual sua opiniao?

    • Concordo com Simon Brown (@simonbrown) quando ele diz que “The code tells “a” story, but it doesn’t tell “the whole” story”. Sou absolutamente contra documentacao arquitetural que seja verborragica; ela deve ser “just enough”. Tem um monte de gente falando sobre “Just enough Software Architecture”. No entanto, mais uma vez, gosto do que Brown entende por documentacao arquitetural suficiente:

      1 – Prove estruturas e guidelines que fornecem claridade e entendimento comum do sistema;

      2 – Documenta todas as decisoes relevantes para o desenvolvimento “correto” do sistema. (acredito que concordamos que corretude nao se resume a funcionalidades corretas); e

      3 – Ajuda a entender como os elementos constituintes do sistema se encaixam.

      Dai a necessidade de se ter alguem que responda pela arquitetura (Architecture Owner), que seja responsavel por identificar o que eh “suficiente”, baseado em analises detalhadas das necessidades dos times de desenvolvimento, e dos demais stakeholders envolvidos.

  2. Muito bom o post… É impressionante como a realidade da engenharia de software nos Sistemas safety-critical parece ser algo completamente distinto do desenvolvimento de software convencional… Porque será que não conseguimos aplicar os mesmos conceitos? Será apenas a questão do custo? O software convencional está sempre buscando entregar num menor tempo com um menor custo…

    • A questao para mim é: será que precisamos aplicar os mesmos conceitos? Na minha cabeca a resposta é que nao (apesar de ter pensado pouco no assunto). É evidente que os custos aumentam com isso e ninguem também está disposto a pagar por algo que “teoricamente” poderia ser evitado.

  3. Eu acredito que toda essa cautela em sistemas safety-critical e’ diretamente proporcional ao tamanho dos prejuizos que eles causam se falharem. No caso de sistemas “tradicionais” como, por exemplo sistemas de aplicacoes financeiras, uma operacao “nao planejada” pode zerar os investimentos de muita gente. Por mais auditoria que exista implementada, existe como “trazer” os valores desaparecidos de volta, caso seja comprovado que falhas tecnicas resultaram nisso. Ja quando sistemas de plantas nucleares e avioes falham, a gante ja sabe o resultado: Fukushima, Air France, … . Se a gente conseguisse ressucitar o povo que morreria em queda de aviao, ou despoulir estragos nucleares rapidamente, duvido que essa cautela toda existiria.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s