DO-178B Adriano Gomes

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

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. The purpose of the document is to provide a standard for software development in aircraft systems. Um documento que aborda o processo de vida do desenvolvimento de softwares embutidos em sistemas de aeronaves.

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)

Diferenças entre o DO-178A e DO-178B "... 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... " I will now address my subject. The following info is a direct quote from each standard. I will give you a minute to read it. There is a significant difference in the purpose of each revision. There is a lot more emphasis on safety and verification in the DO-178B standard. I will now outline the differences between DO-178A and DO-178B in accordance with DO-178B.

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. DO-178B guidelines specify: Objectives for software life-cycle processes. Description of activities and design considerations for achieving those objectives. Description of the evidence indicating that the objectives have been satisfied.

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

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

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

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

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

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

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

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.

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.

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. Modified Condition/Decision Coverage

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 A indústria de aviões exige que sistemas críticos (segurança) sejam avaliados de acordo com a exigentes orientações das autoridades certificadoras antes de poder ser utilizado em qualquer avião comercial. O que é um sistema de "segurança crítica" ? Se falhar, pode causar perda de vidas humanas, ou ter outras conseqüências catastróficas Como essa criticidade afeta o desenvolvimento dos sistemas? Agências Reguladoras exigem o cumprimento dos requisitos de certificação Padrões de segurança devem ser aplicados ao produto final ou ao processo de desenvolvimento Escolha dos métodos e processos de implementação tem grande impacto sobre o custo de desenvolvimento e na certificação desses sistemas

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.

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 As ARP são documentos criados pela SAE com práticas recomendadas para a certificação de sistemas aeronáuticos. Referências: ARP 4754, ARP 4761 e DO-178B Usadas pela empresas que desenvolvem os equipamentos de aviação e pelas autoridades certificadoras. DO-178B: Guia de orientações para os processos do ciclo de vida de um sistema ARP4754 : Descreve o processo de certificação de sistemas aeronáuticos complexos e altamente integrados ARP4761: Descreve os métodos que podem ser utilizados para este fim FHA (Functional Hazard Analysis) FTA (Fault Tree Analysis)

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 (Functional Hazard Analysis) FTA (Fault Tree Analysis)

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 O objetivo das criticalidades é identificar qual seria o efeito sobre a aeronave caso ocorresse aquela condição de falha.

FHA Próximos passos: Exemplo: 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. A uma dada função de nível da aeronave, diferentes sistemas são atribuídos. O próximo passo é inserir na FHA as condições de falhas associadas ao sistema Exemplo: O sistema hidráulico auxilia no controle longitudinal Se a perda do controle longitudinal é catastrófica, podemos assumir que 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 criticidade.

FHA

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. Com o objetivo de determinar as causas de um acidente, utilizamos à análise de árvore de falhas. Nela existem 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, iniciando a análise supondo a ocorrência da um evento indesejado, tal como a perda do controle longitudinal, e a partir deste evento determina [deduz] suas causas.

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”

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

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.

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

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.

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

Objetivos O foco central seria: Uso da linguagem formal PRISM!!!! 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!!!! Prover propriedades que correspondessem não apenas à aspectos funcionais de um sistema, como é o caso de técnicas de verificações formais não-probabilística, mas também à 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 “

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

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

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. As árvores de falha continuariam para cumprir as exigências dos órgãos certificadores

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

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.

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.

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.

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

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-Based Safety Analysis Joshi A., Heimdahl M. P. E., Miller S. P., Whalen M. W.

Perguntas ?