Considerações de software em sistemas aéreos e certificação de equipamentos
Abreviação
  • DO-178C
  • ED-12C
Versão mais recente5 de janeiro de 2012
Organização
DomínioAviação

DO-178C, Considerações de Software em Sistemas Aéreos e Certificação de Equipamentos é o documento principal pelo qual as autoridades de certificação como FAA, EASA e Transport Canada aprovam todos os sistemas aeroespaciais baseados em software comercial. O documento é publicado pela RTCA, Incorporated, em um esforço conjunto com a EUROCAE, e substitui o DO-178B. O novo documento é chamado DO-178C/ED-12C e foi concluído em novembro de 2011 e aprovado pela RTCA em dezembro de 2011. Ficou disponível para venda e uso em janeiro de 2012. [1][2][3]

Com exceção da FAR 33/JAR E, os Regulamentos Federais de Aviação não fazem referência direta à aeronavegabilidade do software. [4] Em 19 de julho de 2013, a FAA aprovou o AC 20-115C, designando o DO-178C como um reconhecido “meio aceitável, mas não o único meio, para mostrar conformidade com os regulamentos de aeronavegabilidade FAR aplicáveis para os aspectos de software de sistemas aéreos e certificação de equipamentos”. [5]

Background[edição]

Desde o lançamento do DO-178B, houve fortes pedidos de DERs (Representantes de Engenharia Designados pela FAA) para esclarecimento/refinamento das definições e limites entre os principais conceitos DO-178B de requisitos de alto nível, requisitos de baixo nível e requisitos derivados e uma melhor definição dos critérios de saída/entrada entre os requisitos de sistemas e o projeto do sistema (ver ARP4754 ) e o dos requisitos de software e design de software (que é o domínio do DO-178B). Outras preocupações incluíam o significado de verificação em um paradigma de desenvolvimento baseado em modelos e considerações para substituir algumas ou todas as atividades de teste de software por simulação de modelo ou métodos formais. Foram criadas as informações adicionais do DO-178C e dos documentos complementares DO-278A (Sistemas Terrestres), DO-248C (Informações adicionais com justificativa para cada objetivo DO-178C), DO-330 (Qualificação de Ferramentas), DO-331 (Modelagem), DO-332 (Objeto Orientado) e DO-333 (Métodos Formais) para abordar as questões apontadas. Os membros da SC-205 trabalharam com o comitê SAE S-18 para garantir que o ARP4754A e os documentos do DO-xxx acima observados forneçam um processo unificado e vinculado com critérios complementares.

No geral, o DO-178C mantém a maior parte do texto DO-178B, que levantou preocupações de que questões com o DO-178B, como a ambiguidade sobre o conceito de requisitos de baixo nível, podem não ser totalmente resolvidas. [6]

Organização do comitê[edição]

O trabalho da comissão mista RTCA/EUROCAE foi dividido em sete Subgrupos:

  • SG1: Integração de documentos SCWG
  • SG2: Questões e Racionalidade
  • SG3: Qualificação de ferramentas
  • SG4: Desenvolvimento e Verificação baseados em modelos
  • SG5: Tecnologia orientada a objetos
  • SG6: Métodos Formais
  • SG7: Considerações relacionadas à segurança

O subgrupo de Desenvolvimento e Verificação Baseado em Modelos (SG4) foi o maior dos grupos de trabalho. Todo o trabalho é coletado e coordenado através de um site que é um mecanismo de gestão colaborativa do trabalho. [7] Artefatos de trabalho e documentos de rascunho foram mantidos em uma área restrita disponível apenas para os membros do grupo.

O trabalho foi focado em colocar o DO-178B/ED-12B atualizado em relação às práticas, ferramentas e tecnologias atuais de desenvolvimento de software. [8][9]

Nível de software[edição]

O Nível de Software, também conhecido como Nível de Garantia de Design (DAL) ou Nível de Garantia de Desenvolvimento de Itens (IDAL), conforme definido em ARP4754 (DO-178C menciona apenas o IDAL como sinônimo de Nível de Software[10]), é determinado a partir do processo de avaliação de segurança e análise de riscos examinando os efeitos de uma condição de falha no sistema. As condições de falha são categorizadas por seus efeitos na aeronave, tripulação e passageiros.

  • Catastrófico - Falha pode causar mortes, geralmente com perda do avião.
  • Perigoso - A falha tem um grande impacto negativo na segurança ou desempenho, ou reduz a capacidade da tripulação de operar a aeronave devido a sofrimento físico ou maior carga de trabalho, ou causa ferimentos graves ou fatais entre os passageiros.
  • Major - A falha reduz significativamente a margem de segurança ou aumenta significativamente a carga de trabalho da tripulação. Pode resultar em desconforto de passageiros (ou até mesmo ferimentos leves).
  • Menor - A falha reduz ligeiramente a margem de segurança ou aumenta ligeiramente a carga de trabalho da tripulação. Exemplos podem incluir causar inconveniência aos passageiros ou uma mudança de plano de voo de rotina.
  • Sem Efeito - A falha não tem impacto na segurança, operação da aeronave ou carga de trabalho da tripulação.

Só o DO-178C não se destina a garantir aspectos de segurança do software. Os atributos de segurança no projeto e, conforme implementado como funcionalidade, devem receber tarefas adicionais de segurança obrigatória do sistema para conduzir e mostrar evidências objetivas de atender aos requisitos explícitos de segurança. As autoridades de certificação exigem e o DO-178C especifica que o DAL correto seja estabelecido usando esses métodos abrangentes de análise para estabelecer o nível de software A-E. “O nível de software estabelece o rigor necessário para demonstrar conformidade” com o DO-178C. [10] Qualquer software que comande, controle e monitore funções críticas de segurança deve receber o mais alto DAL - Nível A.

O número de objetivos a serem satisfeitos (alguns com independência) é determinado pelo nível de software A-E. A frase “com independência” refere-se a uma separação de responsabilidades onde a objetividade dos processos de verificação e validação é garantida em virtude de sua “independência” da equipe de desenvolvimento de software. Para objetivos que devem ser satisfeitos com a independência, a pessoa que verifica o item (como um requisito ou código fonte) pode não ser a pessoa autora do item e essa separação deve ser claramente documentada. [11]

Nível Condição de falha Objetivos[12] Com independência
Um Catastrófico 71 30
B Perigoso 69 18
C Principal 62 5
D Menor 26 2
E Sem efeito de segurança 0 0

Processos e documentos[edição]

Os processos visam suportar os objetivos, de acordo com o nível de software (A a D — Nível E estava fora da alçada do DO-178C). Os processos são descritos como áreas abstratas de trabalho no DO-178C, cabendo aos planejadores de um projeto real definir e documentar as especificidades de como um processo será realizado. Em um projeto real, as atividades reais que serão feitas no contexto de um processo devem ser demonstradas para apoiar os objetivos. Essas atividades são definidas pelos planejadores do projeto como parte do processo de Planejamento.

Essa natureza objetiva do DO-178C permite muita flexibilidade em relação a seguir diferentes estilos de ciclo de vida do software. Uma vez definida uma atividade dentro de um processo, espera-se que o projeto respeite essa atividade documentada dentro de seu processo. Além disso, os processos (e suas atividades concretas) devem ter critérios de entrada e saída bem definidos, de acordo com o DO-178C, e um projeto deve mostrar que está respeitando esses critérios à medida que realiza as atividades no processo.

A natureza flexível dos processos e critérios de entrada/saída do DO-178C dificultam a implementação pela primeira vez, pois esses aspectos são abstratos e não há “conjunto base” de atividades a partir das quais trabalhar. A intenção do DO-178C não era ser prescritivo. Existem muitas maneiras possíveis e aceitáveis para um projeto real definir esses aspectos. Isso pode ser difícil na primeira vez que uma empresa tenta desenvolver um sistema de aviônica civil sob este padrão, e criou um nicho de mercado para treinamento e consultoria DO-178C.

Para um processo genérico baseado no DO-178C, Etapas de Envolvimento (SOI) são os portões mínimos que uma Autoridade de Certificação se envolve na revisão de um sistema ou subsecimento definido pela EASA no Memorando de Certificação SWCEH – 002: Sw Approval Guidelines e FAA on the Order 8110.49: SW Approval Guidelines.

Rastreabilidade[editar]

Diagrama ilustrando o rastreamento bidirecional necessário entre artefatos de certificação, conforme exigido pelo padrão RTCA DO-178C. Os traços de cor vermelha são necessários apenas para os traços de cor roxa são necessários para os níveis A, B e C. Os traços de cor verde são para os níveis A, B, C e D. O nível E não requer nenhum rastreamento. As referências em cada seta de traço representam referências ao padrão para o objetivo, a atividade e a revisão/verificação, respectivamente.

O DO-178 requer conexões bidirecionais documentadas (chamadas de traços) entre os artefatos de certificação. Por exemplo, um Requisito de Baixo Nível (LLR) é rastreado até um Requisito de Alto Nível (HLR) destinado a satisfazer, enquanto também está traçado para as linhas de código fonte destinadas a implementá-lo, os casos de teste destinados a verificar a correção do código-fonte em relação à exigência, os resultados desses testes, etc. Uma análise de rastreabilidade é então usada para garantir que cada requisito seja cumprido pelo código-fonte, que cada requisito funcional seja verificado por teste, que cada linha de código fonte tenha uma finalidade (está conectada a um requisito), e assim por diante. A análise de rastreabilidade acessa a completude do sistema. O rigor e o detalhamento dos artefatos de certificação estão relacionados ao nível do software.

Diferenças com DO-178B[edit]

O SC-205/WG-12 foi responsável pela revisão do DO-178B/ED-12B para atualizá-lo em relação às tecnologias atuais de desenvolvimento e verificação de software. A estrutura do documento permanece em grande parte a mesma de B para C. As alterações de exemplo incluem:[13]

  • Fornecer linguagem e terminologia mais claras, fornecer mais consistência
  • Mais objetivos (para os níveis A, B e C)
  • Esclareceu o “objetivo oculto”, aplicável ao Nível A, que estava implícito pelo DO-178B na seção 6.4.4.2b, mas não listado nas tabelas do anexo A. Este objetivo está agora explicitamente listado no DO-178C, anexo A, Tabela A-7, Objetivo 9: “A verificação de código adicional, que não pode ser rastreado ao Código Fonte, é alcançada.” [14]
  • Arquivos de itens de dados do parâmetro - Fornece informações separadas que influenciam o comportamento de um código de objeto executável (sem alterá-lo). Um exemplo seria um arquivo de configuração que configura o cronograma e os principais prazos de um sistema operacional particionado. O arquivo do item de dados do parâmetro deve ser verificado juntamente com o código do objeto executável, ou então ele deve ser testado para todas as faixas possíveis dos itens de dados do parâmetro.
  • DO-330 “Considerações de Qualificação de Ferramentas de Software”, um novo “documento externo independente de domínio”, foi desenvolvido para fornecer orientação para um processo aceitável de qualificação de ferramentas. Embora o DO-178B tenha sido utilizado como base para o desenvolvimento deste novo documento, o texto foi adaptado para ser diretamente e separadamente aplicável ao desenvolvimento de ferramentas e expandido para abordar todos os aspectos da ferramenta. Como independente de domínio, documento autônomo, o DO-330 destina-se a ser usado não apenas em apoio ao DO-178C/ED-12C, mas também ao DO-278/ED-109, AO-254/ED-80 e também ao DO-200, mesmo para aplicações não-aviação, por exemplo, ISO 26262 ou ECSS. [15] Consequentemente, a orientação de qualificação da ferramenta foi removida no DO-178C, substituída por orientação para decidir quando aplicar orientação de qualificação de ferramentas DO-330 às ferramentas utilizadas em um contexto DO-178C. [16]
  • Suplementos tecnológicos foram adicionados para estender a orientação do documento DO-178C a técnicas específicas. Em vez de expandir o texto anterior para responder por todas as técnicas atuais e futuras de desenvolvimento de software, os suplementos são disponibilizados para adicionar, excluir ou modificar explicitamente a orientação do padrão central de aplicação para técnicas ou tecnologias específicas. Todas as orientações nesses suplementos são escritas no contexto dos elementos de orientação afetados no DO-178C e, portanto, devem ser consideradas no mesmo nível de autoridade que esse documento central. [17]
    • DO-331 “Suplemento de desenvolvimento e verificação baseado em modelos para DO-178C e DO-278A” - abordando o Desenvolvimento Baseado em Modelo (MBD) e a verificação e a capacidade de usar técnicas de modelagem para melhorar o desenvolvimento e a verificação, evitando armadilhas inerentes a alguns métodos de modelagem
    • DO-332 “Suplemento de tecnologia orientada a objetos e técnicas relacionadas ao DO-178C e DO-278A” - abordando software orientado a objetos e as condições sob as quais ele pode ser usado
    • DO-333 “Suplemento de Métodos Formais para DO-178C e DO-278A” - abordando métodos formais para complementar (mas não substituir) testes

Diretrizes vs. Orientação[edição]

O DO-178B não foi completamente consistente no uso dos termos Diretrizes e Orientações dentro do texto. “Orientação” transmite um senso de obrigação um pouco mais forte do que “diretrizes”. Assim, com o DO-178C, o SCWG estabeleceu o uso de “orientação” para todas as declarações consideradas como “recomendações”, substituindo as demais instâncias de “diretrizes” por “informações de apoio” e usando essa frase onde quer que o texto seja mais “informação” orientada do que “recomendação” orientada.

Todo o documento DO-248C/ED-94C, que suporta informações para DO-178C e DO-278A, se enquadra na categoria “informações de suporte”, não orientação. [18]

Diferença de amostra entre DO-178B e DO-178C[edit]

O capítulo 6.1 define o propósito do processo de verificação do software. O DO-178C adiciona a seguinte instrução sobre o Código de Objeto Executável:

  • “O Código de Objetos Executável satisfaz os requisitos do software (ou seja, função pretendida) e fornece confiança na ausência de funcionalidade não intencional.”
  • “O Código de Objeto executável é robusto em relação aos requisitos de software que ele pode responder corretamente a insumos e condições anormais.”

Como comparação, o DO-178B afirma o seguinte em relação ao Código de Objeto Executável:

  • “O Código de Objeto executável satisfaz os requisitos do software.”

O esclarecimento adicional preenche uma lacuna que um desenvolvedor de software pode encontrar ao interpretar o documento. [19]

Veja também[edit]

Referências[edição]

  1. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-1 “Jump up”) Software de Associação Timberlake, 703-591-4232. “Rtca, Inc.” Rtca.org. Recuperado em 7 de agosto de 2016.
  2. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-2 “Jump up”) Charlotte Adams (1 de setembro de 2010). “O DO-178C se aproxima da linha de chegada, com crédito por ferramentas e tecnologias modernas”. Inteligência Aviônica. Recuperado em 23 de outubro de 2010. A indústria espera que o pacote final — DO-178C — seja lançado no primeiro trimestre de 2011 e seja obrigatório de seis a nove meses após a ratificação.
  3. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-3 “Jump up”) “Resumo da Diferença Entre DO-178B e DO-178C”. A FAA Consultants.com. Qualtech Consulting, Inc. Recuperado em 23 de outubro de 2010. A liberação dessas normas tão esperadas ocorrerá em meados de 2011 e será reconhecida pelas Autoridades de Certificação em 2012.
  4. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-Johnson11_4-0 “Jump up”) Leslie A. (Schad) Johnson. DO-178B, Considerações de Software em Sistemas Aéreos e Certificação de Equipamentos (no contexto do desenvolvimento de software para aeronaves militares, uma discussão do praticante sobre a evolução da prática atual e aplicação do RTCA/DO-178B). Grupo de Aviões Comerciais Boeing. p. 11. Recuperado em 3 de março de 2022.
  5. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-5 “Jump up”) “Cópia arquivada” (PDF). Arquivado do original (PDF) em 3 de setembro de 2014. Recuperado 2013-08-08.``: CS1 maint: archived copy as title (link)
  6. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-advances_6-0 “Jump up”) Dale, Chris; Anderson, Tom, eds. (2010). Avanços na segurança dos sistemas : procedimentos do 19º Simpósio de Sistemas Críticos de Segurança, Southampton, Reino Unido, de 8 a 10 de fevereiro de 2011. London: Springer. pp. 298-299. ISBN 9780857291325.
  7. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-7 “Jump up”) “Plenário SC-205/WG-71”. Arquivado do original em 19 de julho de 2011. Recuperado 2010-09-18.
  8. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-8 “Jump up”) Bill StClair & Tim King (7 de março de 2012). “O DO-178C traz tecnologia moderna para o desenvolvimento de software crítico à segurança”. Sistemas Militares Embarcados. Recuperado em 17 de abril de 2012.
  9. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-9 “Jump up”) “DO-178C melhora o desenvolvimento de software aviônico crítico à segurança”. Design Eletrônico. Design Eletrônico. Recuperado em 17 de abril de 2012.
  10. ^ Jump up to: um b RTCA/DO-178C “Considerações de software em sistemas aéreos e certificação de equipamentos”, p. 116. “Um exemplo é o termo “nível de garantia de desenvolvimento de itens” (IDAL), que para software é sinônimo do termo “nível de software”.
  11. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-11 “Jump up”) RTCA/DO-178C “Considerações de software em sistemas aéreos e certificação de equipamentos”, p. 41
  12. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-12 “Jump up”) RTCA/DO-178C “Considerações de software em sistemas aéreos e certificação de equipamentos”, anexo A
  13. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-13 “Jump up”) “HighRely Sinopse da Reunião Nacional de Software e Hardware da FAA inclui status DO-178C”. 2006. Recuperado em 30 de setembro de 2009. O DO-178C conterá mais detalhes sobre a modelagem de software e a capacidade potencial de usar modelagem para suplantar algumas das técnicas de verificação normalmente exigidas no DO-178B. O DO-178C também abordará mais totalmente o software OO (Object Oriented) e as condições sob as quais ele pode ser usado e as ramificações de certificação de OO no DO-178C.
  14. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-14 “Jump up”) Considerações de software RTCA/DO-178C em sistemas aéreos e certificação de equipamentos. RTCA, Inc. 2011.
  15. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-15 “Jump up”) Pothon, Frédéric. “Princípios e benefícios do uso do DO-330/ED-215” (PDF). validas. Recuperado em 3 de outubro de 2019.
  16. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-16 “Jump up”) Pothon, Frédéric; et al. (2012). DO-178C/ED-12C versus DO-178B/ED-12B Alterações e Melhorias (PDF). p. 49. Recuperado em 5 de janeiro de 2015.
  17. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-17 “Jump up”) Pothon, pp. 43-46
  18. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-18 “Jump up”) Pothon, p. 14
  19. [^](https://en.wikipedia.org/wiki/DO-178C#cite_ref-19 “Jump up”) “Alcançando o DO-178C em conformidade com os testes de desenvolvimento do Parasoft”. Arquivado do original em 11 de setembro de 2014. Recuperado 2013-03-07.