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
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... "
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
– 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



Processo de Integração de Software


requisitos, projeto, codificação e integração
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.
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”

FTA
Falha do sistema "D"
Evento
Sistema "D" Indesejado
G1
Porta AND
A
EventoC
Intermediário
Falha do
componente "A"
Falha do
componente "B" ou
"C"
A
G2
Porta OR
Evento
Básico
Falha do
componente "B"
Falha do
componente "C"
B
C
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
Hazard Analysis
Prism
+
Model Checking
Árvore de Falha
PROPOSTA - BENEFÍCIOS

Geração de um modelo quantitativo, capaz de:



As árvores de falha continuariam para cumprir
as exigências dos órgãos certificadores


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.
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 DO178C / 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


Towards Integrated Safety Analysis And Design


Lars Grunske, Robert Colvin, Kirsten Winter
PRISM A Tool for Automatic Verification of Probabilistic
Systems


J A McDermid, P Fenelon, M Nicholson, D J Pumfrey
Probabilistc model-checking support for FMEA.


Joshi A., Heimdahl M. P. E., Miller S. P., Whalen M. W.
Marta Kwiatkowska, Andrew Hinton, Gethin Norman, David
Parker
Model-Based Synthesis of Fault Trees from Matlab Simulink models

Yiannis Papadopoulos, Matthias Maruhn
REFERÊNCIAS

Efficient Development of Safe Avionics Software
with DO-178B Objectives Using SCADE Suite





http://www.estereltechnologies.com/files/AeronauticsHandBookDO178B.pdf
“DO-178B, Software Considerations in Airborne
Systems and Equipment Certification

http://en.wikipedia.org/wiki/DO-178B.

http://www.stsc.hill.af.mil/crosstalk/1998/10/schad.asp.

http://www.sandroid.org/birdsproject/4dummies.html
DO-178B, “Software Considerations in Airborne
Systems and Equipment Certification.” Flight
Systems.
Birds Project Introduction to DO-178B
Model-Based Safety Analysis

Joshi A., Heimdahl M. P. E., Miller S. P., Whalen M. W.
PERGUNTAS