Software aviônico - Avionics software

O software da aviônica é um software integrado com questões de segurança e confiabilidade exigidas por lei, usado na aviônica . A principal diferença entre o software aviônico e o software embarcado convencional é que o processo de desenvolvimento é exigido por lei e é otimizado para segurança. Alega-se que o processo descrito abaixo é apenas um pouco mais lento e caro (talvez 15 por cento) do que os processos ad hoc normais usados ​​para software comercial . Como a maioria dos softwares falha por causa de erros, eliminá-los na primeira etapa possível também é uma maneira relativamente barata e confiável de produzir software. Em alguns projetos, no entanto, erros nas especificações podem não ser detectados até a implantação. Nesse ponto, eles podem ser muito caros para consertar.

A ideia básica de qualquer modelo de desenvolvimento de software é que cada etapa do processo de design tem saídas chamadas "entregas". Se as entregas forem testadas quanto à exatidão e corrigidas, os erros humanos normais não podem se transformar facilmente em problemas perigosos ou caros. A maioria dos fabricantes segue o modelo em cascata para coordenar o projeto do produto, mas quase todos permitem explicitamente que o trabalho anterior seja revisado. O resultado é mais frequentemente mais próximo de um modelo em espiral .

Para obter uma visão geral do software embarcado, consulte o sistema embarcado e os modelos de desenvolvimento de software . O restante deste artigo pressupõe familiaridade com essas informações e discute as diferenças entre sistemas embarcados comerciais e modelos de desenvolvimento comercial.

Visao geral

Como a maioria dos fabricantes de aviônicos vê o software como uma forma de agregar valor sem agregar peso, a importância do software embarcado em sistemas aviônicos está aumentando.

A maioria das aeronaves comerciais modernas com pilotos automáticos usa computadores de voo e os chamados sistemas de gerenciamento de voo (FMS), que podem voar a aeronave sem a intervenção ativa do piloto durante certas fases do voo. Também em desenvolvimento ou em produção estão os veículos não tripulados: mísseis e drones que podem decolar, cruzar e pousar sem a intervenção do piloto no ar.

Em muitos desses sistemas, a falha é inaceitável. A confiabilidade do software rodando em veículos aerotransportados (civis ou militares) é demonstrada pelo fato de que a maioria dos acidentes aerotransportados ocorre devido a erros manuais. Infelizmente, o software confiável não é necessariamente fácil de usar ou intuitivo, o design ruim da interface do usuário tem contribuído para muitos acidentes e mortes aeroespaciais.

Questões regulatórias

Devido a requisitos de segurança, a maioria das nações regulamenta a aviônica, ou pelo menos adota padrões em uso por um grupo de aliados ou uma união alfandegária. As três organizações reguladoras que mais afetam o desenvolvimento da aviação internacional são os EUA, a UE e a Rússia.

Nos EUA , aviônicos e outros componentes de aeronaves têm padrões de segurança e confiabilidade exigidos pelos Regulamentos Federais de Aviação, Parte 25 para aviões de transporte, Parte 23 para aviões pequenos e partes 27 e 29 para aeronaves de rotação. Esses padrões são aplicados por "representantes de engenharia designados" da FAA, que geralmente são pagos por um fabricante e certificados pela FAA.

Na União Européia, o IEC descreve os requisitos "recomendados" para sistemas críticos de segurança, que geralmente são adotados sem alteração pelos governos. Uma peça de aviônica segura e confiável possui uma "Marca CE". O arranjo regulatório é notavelmente semelhante ao da segurança contra incêndio nos Estados Unidos e Canadá. O governo certifica laboratórios de teste, e os laboratórios certificam tanto itens manufaturados quanto organizações. Essencialmente, a supervisão da engenharia é terceirizada do governo e do fabricante para o laboratório de testes.

Para garantir a segurança e a confiabilidade, as autoridades regulatórias nacionais (por exemplo , FAA , CAA ou DOD ) exigem padrões de desenvolvimento de software. Alguns padrões representativos incluem MIL-STD-2167 para sistemas militares ou RTCA DO-178B e seu sucessor DO-178C para aeronaves civis.

Os requisitos regulamentares para este software podem ser caros em comparação com outro software, mas geralmente são o mínimo necessário para produzir a segurança necessária.

Processo de desenvolvimento

A principal diferença entre o software aviônico e outros sistemas embarcados é que os padrões reais costumam ser muito mais detalhados e rigorosos do que os padrões comerciais, geralmente descritos por documentos com centenas de páginas. Geralmente é executado em um sistema operacional em tempo real.

Uma vez que o processo é legalmente exigido, a maioria dos processos possui documentos ou software para rastrear requisitos de parágrafos numerados nas especificações e projetos até partes exatas de código, com testes exatos para cada um e uma caixa na lista de verificação de certificação final. Isso serve especificamente para provar a conformidade com o padrão exigido por lei.

Desvios de um projeto específico para os processos descritos aqui podem ocorrer devido ao uso de métodos alternativos ou requisitos de baixo nível de segurança.

Quase todos os padrões de desenvolvimento de software descrevem como executar e melhorar especificações, projetos, codificação e testes (consulte o modelo de desenvolvimento de software ). No entanto, os padrões de desenvolvimento de software aviônico adicionam algumas etapas ao desenvolvimento para segurança e certificação:

Interfaces humanas

Projetos com interfaces humanas substanciais geralmente são prototipados ou simulados. A fita de vídeo geralmente é mantida, mas o protótipo foi retirado imediatamente após o teste, porque caso contrário, a alta administração e os clientes podem acreditar que o sistema está completo. Um dos principais objetivos é encontrar problemas de interface humana que podem afetar a segurança e a usabilidade.

Análise perigosa

Aviônicos de segurança crítica geralmente têm uma análise de risco . Os estágios iniciais do projeto, já têm pelo menos uma vaga ideia das principais partes do projeto. Um engenheiro então pega cada bloco de um diagrama de blocos e considera as coisas que podem dar errado com aquele bloco e como elas afetam o sistema como um todo. Posteriormente, a gravidade e a probabilidade dos perigos são estimadas. Os problemas então se tornam requisitos que alimentam as especificações do projeto.

Projetos envolvendo segurança criptográfica militar geralmente incluem uma análise de segurança, usando métodos muito semelhantes à análise de risco.

Manual de manutenção

Assim que as especificações de engenharia forem concluídas, pode-se começar a escrever o manual de manutenção. Um manual de manutenção é essencial para reparos e, claro, se o sistema não puder ser consertado, não será seguro.

Existem vários níveis para a maioria dos padrões. Um produto de baixa segurança, como uma unidade de entretenimento durante o vôo (uma TV voadora), pode escapar com um esquema e procedimentos para instalação e ajuste. Um sistema de navegação, piloto automático ou motor pode ter milhares de páginas de procedimentos, inspeções e instruções de montagem. Os documentos são agora (2003) entregues rotineiramente em CD-ROM, em formatos padrão que incluem texto e imagens.

Um dos requisitos de documentação mais estranhos é que a maioria dos contratos comerciais exige uma garantia de que a documentação do sistema estará disponível indefinidamente. O método comercial normal de fornecer essa garantia é formar e financiar uma pequena fundação ou fundo fiduciário. O truste então mantém uma caixa de correio e deposita cópias (geralmente em ultrafiche ) em um local seguro, como um espaço alugado na biblioteca de uma universidade (gerenciado como uma coleção especial) ou (mais raramente agora) enterrado em uma caverna ou em um local deserto.

Documentos de design e especificação

Geralmente, são muito parecidos com os de outros modelos de desenvolvimento de software . Uma diferença crucial é que os requisitos geralmente são rastreados conforme descrito acima. Em grandes projetos, a rastreabilidade de requisitos é uma tarefa tão grande e cara que requer programas de computador grandes e caros para gerenciá-la.

Produção e revisão de código

O código é escrito e geralmente revisado por um programador (ou grupo de programadores, geralmente de forma independente) que não o escreveu originalmente (outro requisito legal). Organizações especiais também costumam conduzir revisões de código com uma lista de verificação de possíveis erros. Quando um novo tipo de erro é encontrado, ele é adicionado à lista de verificação e corrigido em todo o código.

O código também é frequentemente examinado por programas especiais que analisam a correção ( análise de código estático ), como o examinador SPARK para o SPARK (um subconjunto da linguagem de programação Ada) ou lint para a família C de linguagens de programação (principalmente C, embora) . Os compiladores ou programas de verificação especial como "lint" verificam se os tipos de dados são compatíveis com as operações neles, também essas ferramentas são regularmente usadas para impor o uso estrito de subconjuntos de linguagem de programação e estilos de programação válidos. Outro conjunto de programas mede as métricas de software , para procurar partes do código que provavelmente contêm erros. Todos os problemas foram corrigidos ou, pelo menos, compreendidos e verificados novamente.

Alguns códigos, como filtros digitais , interfaces gráficas de usuário e sistemas de navegação inercial , são tão bem compreendidos que ferramentas de software foram desenvolvidas para escrever o software. Nestes casos, as especificações são desenvolvidas e um software confiável é produzido automaticamente.

Teste de unidade

O código de "teste de unidade" é escrito para exercitar todas as instruções do código pelo menos uma vez para obter 100% de cobertura do código . Uma ferramenta de "cobertura" costuma ser usada para verificar se todas as instruções são executadas e, em seguida, a cobertura do teste também é documentada, por motivos legais.

Este teste está entre os mais poderosos. Ele força uma revisão detalhada da lógica do programa e detecta a maioria dos erros de codificação, compilador e alguns erros de design. Algumas organizações escrevem os testes de unidade antes de escrever o código, usando o design do software como uma especificação do módulo. O código do teste de unidade é executado e todos os problemas são corrigidos.

Teste de integração

Conforme pedaços de código se tornam disponíveis, eles são adicionados a um esqueleto de código e testados no local para garantir que cada interface funcione. Normalmente, os testes internos da eletrônica devem ser concluídos primeiro, para começar os testes de queima e de emissões de rádio da eletrônica.

Em seguida, os recursos mais valiosos do software são integrados. É muito conveniente para os integradores ter uma maneira de executar pequenos pedaços selecionados de código, talvez a partir de um sistema de menu simples.

Alguns gerentes de programa tentam organizar esse processo de integração de modo que, após algum nível mínimo de função ser alcançado, o sistema se torne entregável em qualquer data seguinte, com um número crescente de recursos conforme o tempo passa.

Caixa preta e teste de aceitação

Enquanto isso, os engenheiros de teste geralmente começam a montar um equipamento de teste e liberar testes preliminares para uso pelos engenheiros de software. Em algum ponto, os testes cobrem todas as funções da especificação de engenharia. Neste ponto, o teste de toda a unidade aviônica começa. O objetivo do teste de aceitação é provar que a unidade é segura e confiável em operação.

O primeiro teste do software, e um dos mais difíceis de cumprir em um cronograma apertado, é um teste realista das emissões de rádio da unidade. Isso geralmente deve ser iniciado no início do projeto para garantir que haja tempo para fazer as alterações necessárias no design dos componentes eletrônicos. O software também é submetido a uma análise de cobertura estrutural, onde os testes são executados e a cobertura de código é coletada e analisada.

Certificação

Cada etapa produz uma entrega, seja um documento, código ou um relatório de teste. Quando o software passa em todos os seus testes (ou o suficiente para ser vendido com segurança), eles são vinculados a um relatório de certificação, que pode literalmente ter milhares de páginas. O representante de engenharia designado, que tem se esforçado para ser concluído, decide se o resultado é aceitável. Se for, ele assina e o software aviônico é certificado.

Veja também

Referências

links externos