DO-178B

Adriano Gomes

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

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.

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 gerenciamentode softwares sistemas e equipamentos aeronáuticos...”

"... 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... "

DO-178A

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 : NÍVEIS DE SOFTWARE

O DO-178B requer que todos os requisitos do sistemas sejam mapeados em um dos seus 5 níveis:

A – CatastrophicB – HazardousC – MajorD – MinorE – 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 IdentificationChange ControlBaseline establishmentArchiving of the software

As saídas incluem:Software Configuration IndexSoftware 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.

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

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

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

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.

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.

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”

FTAEventoIndesejado

Porta AND

Porta OR

Evento Intermediário

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: 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!!!!

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

+ Model Checking

Hazard Analysis Prism Árvore de Falha

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.

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/Aeronauti

csHandBook-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.a

sp.

Birds Project Introduction to DO-178B http://www.sandroid.org/birdsproject/4dummies.htm

l Model-Based Safety Analysis

Joshi A., Heimdahl M. P. E., Miller S. P., Whalen M. W.

PERGUNTAS

?