DO-178B

1. DO-178B Adriano Gomes

2. Agenda • DO-178B • Definição • Histórico • Considerações • Níveis de Softwares • Processos • Trabalho do Mestrado • Motivações • Contexto da Embraer • Proposta • Conclusões

3. O que é o DO-178B? • “Considerações de software para a certificação de sistemas e equipamentos aeronáuticos” • Seu equivalente europeu é o ED-12B. • Padrão mundial comumente aceito • Regulamentação de segurança • Integração de software em sistemas de aeronaves.

4. DO-178B : Cronograma Histórico • Nov. 1981- DO-178-SC145 • Mar. 1985- DO-178A –SC152 (4 anos) • Níveis: 1,2,3 – Crit, Essential, NonEss • Etapas de Desenvolvimento:D1-D5 • Etapas de Verificação: V1-V7 • Dec. 1992- DO-178B –SC167 (7 anos) • Objetivos baseados em tabelas • Foca no O QUE, não no COMO • Categorias de criticidade (A,B,C,D, E) / Matriz de Objetivos • DO-178B(16 anos)

5. Diferenças entre o DO-178A e DO-178B DO-178A "... Objetivo é descrever as técnicas e métodos que podem ser utilizados para o desenvolvimento ordenado e gerenciamento de softwares sistemas e equipamentos aeronáuticos...” DO-178B "... Objetivo é fornecer orientações para a produção de software para sistemas e equipamentos aeronáuticos que exerce sua função pretendida com um nível de segurança que cumpra exigências do setor... "

6. Considerações sobre o DO-178B • As orientações DO-178B especificam: • Objetivos para processos de software no ciclo de vida. • Descrição das atividades e considerações design para atingir esses objetivos. • Descrição das provas que indiquem que os objetivos foram cumpridos • Orientado a processos • Atributos desejados no ciclo de vida do sofware: • sem ambiguidades, completos, verificável, consistente, modificável, rastreável.

7. DO-178B : Níveis de Software • O DO-178B requer que todos os requisitos do sistemas sejam mapeados em um dos seus 5 níveis: • A – Catastrophic • B – Hazardous • C – Major • D – Minor • E – No Effect

8. DO-178B - Processos • Independente do ciclo de vida adotado • Três categorias de processo exigidas em qualquer de ciclo de vida • Processo de Planejamento de Software • Processo de Desenvolvimento de Software • requisitos, projeto, codificação e integração • Processo de Integração de Software • verificação, QA, CM, e certificação • Cada processo tem um conjunto de documentos de saída esperados

9. DO-178B – Processos • Estrutura do ciclo de vida dos processos

10. DO-178B - Software Planning Process • Finalidade é determinar o que será feito para a produção segura, baseada em requisitos de software. • Resultados esperados: • Plan for Software Aspects of Certification (PSAC) • Software Development Plan • Software Verification Plan • Software Configuration Management Plan • Software Quality Assurance Plan

11. DO-178B - Software Development Process • O processo de desenvolvimento de software é quebrado em quatro sub-processos:

12. DO-178B - Software Development Process • Os resultados tangíveis são obtidos com a combinação dos quatro sub-processos: • Software requirements data (SRD) • Software design description (SDD) • Source code • Executable object code

13. DO-178B - Software Verification Process • A proposta é identificar e relatar quaisquer erros resultantes do processo de desenvolvimento. • O processo de verificação visa o cumprimento da revisões, tutoriais, testes unitários, integração testes, e muito mais. • Saídas incluem: • Software Verification Cases and Procedures • Software Verification Results

14. DO-178B - Software Configuration Management Process • O objetivo é estabelecer configuração segura e eficaz para controlar todos os artefatos. • As seguintes atividades são feitas dentro do processo: • Configuration Identification • Change Control • Baseline establishment • Archiving of the software • As saídas incluem: • Software Configuration Index • Software Life Cycle Environment • Configuration Index.

15. DO-178B - Software Quality Assurance Process • O objetivo é fornecer a garantia de que o processo de ciclo de vida do software vai produzir softwares de qualidade. • Cada processo é analisado para mostrar que cada um está produzindo os resultados esperados. • Qualquer mudança de planos inicialmente propostos são registradas, avaliadas, e resolvidos para assegurar a integridade processo.

16. DO-178B – Certification Process • As atividades definidas no DO-178B afetam diretamente o desenvolvimento do produto: • A certificação inclui a aprovação de todos os sistemas e subsistemas, hardware, software, firmware, ferramentas desenvolvimento, produção e testes do produto. • Práticas de codificação devem ser certificadas para garantir coisas como "código morto" não sejam permitidas. • A certificação exige o teste completo do sistema e de todos os seus componentes (inclusive firmware) • Feito sobre as plataformas e ambiente de destino. • A certificação exige teste de código no nível MCDC.

17. Motivações • O que é um sistema de "segurança crítica" ? • Como essa criticidade afeta o desenvolvimento dos sistemas? • Requisitos de certificação • Padrões de segurança • Escolha dos métodos e processos de implementação • tem grande impacto sobre o custo de desenvolvimento e na certificação desses sistemas

18. Motivações • Dilema: Como gerar soluções que ajudam no desenvolvimento sustentável dos sistemas sem interferir com certificação de segurança. • Essas soluções dependem dos métodos de modelagem e análise a utilizar durante o ciclo de vida do sistema.

19. Embraer: Contexto Aeronáutico • Referências e Documentações • Usadas pelas empresas que desenvolvem os equipamentos de aviação e pelas autoridades certificadoras. • DO-178B • ARP4754 • ARP 4761

20. Relação entre as ARP e DO-178B • ARP E DO-178B são complementares: • DO-178B: Fornece orientações para os processos do ciclo de vida de um software • ARP4754 : Descreve o processo de certificação de sistemas • ARP4761: Descreve os métodos que podem ser utilizados para este fim • FHA (FunctionalHazardAnalysis) • FTA (FaultTreeAnalysis)

21. FHA • “Consiste em uma grande tabela onde são identificadas todas as possíveis condições em que as diferentes funções da aeronave podem falhar” • Exemplo: • Falha do controle longitudinal durante o cruzeiro. • A cada condição de falha, uma criticidade é atribuída (DO-178B): • A – Catastrophic • B – Hazardous • C – Major • D – Minor • E – No Effect

22. FHA • Próximos passos: • inserir na FHA as condições de falhas de cada componente do sistema • Relacionar as dependências entre as condições de falha de cada componente. • Exemplo: • O sistema hidráulico auxilia no controle longitudinal • Se a perda do controle longitudinal é catastrófica, então a perda do controle hidráulico também é catastrófica. • No fim, a FHA deve possuir uma listagem das condições de falhas associadas ao sistema e suas respectivas criticidades.

23. FHA

24. FTA • Objetiva determinar as causas de um acidente • Possui eventos que resultam na ocorrência do evento indesejado, ou evento topo. • A análise árvore de falhas (FTA) é uma técnica dedutiva • Abordagem baseada na falha • Inicia a análise supondo a ocorrência da um evento indesejado, tal como a perda do controle longitudinal • A partir deste evento determina [deduz] suas causas.

25. FTA • É um Modelo Gráfico • Descrição da combinação das falhas • Cobre somente as falhas consideradas realísticas pelo analista. • Utiliza o modelo das entidades de portas lógicas (“OR”, “AND”, etc.) • As portas lógicas mostram a relação entre os eventos necessários para a ocorrência do evento “mais alto”

26. FTA Evento Indesejado Porta AND Evento Intermediário Porta OR Evento Básico

27. Embraer: Abordagem utilizada • De acordo com os requisitos da FAR Part 25: • Exigência de que qualquer falha de sistema considerada catastrófica seja extremamente improvável. • Ou seja: P < 1E-9 falhas / hora de vôo. • É nesse ponto que entra a análise de árvore de falhas • Para cada condição de falha considerada catastrófica no FHA, deve-se fazer uma FT para determinar ser a probabilidade de ocorrência de tal condição está abaixo do valor.

28. Embraer: Abordagem utilizada • toda vez que a probabilidade do evento topo viola o requisito de segurança (P >= 1E-9 ): • O sistema é remodelado • Todo o processo deve ser repetido

29. Embraer: Resumo do Contexto • A abordagem realiza avaliação qualitativa: • Está relacionada à análise dos cortes mínimos, natureza dos eventos básicos, e número de eventos combinados em cada corte. • A abordagem analisa o comportamento dos componentes do sistema apenas de forma estática • Modelo não é dinâmico. • Síntese das árvores de forma semi-manual.

30. Objetivos • Modelar os sistemas numa linguagem formal capaz de: • Realizar análises probabilísticas de sistemas e componentes • Verificar e validar os modelos • Permitir que uma boa quantidade de propriedades numéricas sejam computadas com precisão • O DO-178B aceita a inserção de linguagens formais como método de auxílio desenvolvimento e verificação de sistemas

31. Objetivos • O foco central seria: • Prover propriedades que não correspondessem aos aspectos funcionais de um sistema • O que queremos é medidas quantitativas, tais como desempenho e confiabilidade, por exemplo: • " A probabilidade de ocorrência de um desligamento, é no máximo, 0,01 “. • Ou :"a probabilidade de que uma mensagem será entregue dentro de 30ms é, pelo menos, 0,75 “ • Uso da linguagem formal PRISM!!!!

32. Proposta • Modelagem seria de forma semi-automática e partiria das informações e modelos da análise de risco (Simulink, HAZOP)

33. Proposta - Cenário Prism Hazard Analysis Árvore de Falha + Model Checking

34. Proposta - Benefícios • Geração de um modelo quantitativo, capaz de: • Fornecer informação sobre quais condições de falha realmente levam o sistema a uma situação catastrófica • Ou seja, filtrar o conjunto de FT a serem construídas. • As árvores de falha continuariam para cumprir as exigências dos órgãos certificadores • Extrair de forma automática os inputs necessários para síntese da árvore de falha (Hip-HOPS). • Cobertura de Vunerabilidade • É possível fazer também avaliação da incerteza.

35. Próximos Passos • Modelar os primeiros sistemas • Iniciar por exemplos simples • Identificar padrões de conversão • Detectar possíveis Incopatibilidades • Definir mais claramente os inputs e seus respectivos formatos para geração do modelo formal

36. Conclusão • Referências rigorosas e padrões são necessários para garantir a segurança do sistema • A evolução dos software aeronáuticos tem forçado uma mudança sobre o processo de certificação. • DO-178B foi escrito pensando nas mais velhas ferramentas de software. • Tecnologias avançadas e a crescente complexidade dos softwares mais novos tem de ser resolvida.

37. Conclusão • A tecnologia atual X As práticas e cultura da Indústria • Não pode atender a necessidades emergentes • O DO178-B permitir o uso métodos formais, mas ... • ... a abordagem ainda não é aceita como método de certificação.

38. Conclusão • Uma comissão já se formou para produzir o DO-178C / ED-12C • principais contribuintes (RTCA e EUROCAE) • Trabalho iniciado em 2005 • A ser concluído e publicado em Dez/2008. • O documento analisa a introdução de novas técnicas desenvolvimento de software, entre outras coisas.

39. Referências • Model-Based Safety Analysis • Joshi A., Heimdahl M. P. E., Miller S. P., Whalen M. W. • Towards Integrated Safety Analysis And Design • J A McDermid, P Fenelon, M Nicholson, D J Pumfrey • Probabilistc model-checking support for FMEA. • Lars Grunske, Robert Colvin, Kirsten Winter • PRISM A Tool for Automatic Verification of Probabilistic Systems • Marta Kwiatkowska, Andrew Hinton, Gethin Norman, David Parker • Model-Based Synthesis of Fault Trees from Matlab - Simulink models • Yiannis Papadopoulos, Matthias Maruhn • http://www.prismmodelchecker.org

40. Referências • Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite • http://www.esterel-technologies.com/files/AeronauticsHandBook-DO178B.pdf • “DO-178B, Software Considerations in Airborne Systems and Equipment Certification • http://en.wikipedia.org/wiki/DO-178B. • DO-178B, “Software Considerations in Airborne Systems and Equipment Certification.” Flight Systems. • http://www.stsc.hill.af.mil/crosstalk/1998/10/schad.asp. • Birds Project Introduction to DO-178B • http://www.sandroid.org/birdsproject/4dummies.html • Model-BasedSafetyAnalysis • Joshi A., Heimdahl M. P. E., Miller S. P., Whalen M. W.

41. Perguntas ?