A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

DO-178B Adriano Gomes. A GENDA DO-178B Definição Histórico Considerações Níveis de Softwares Processos Trabalho do Mestrado Motivações Contexto da Embraer.

Apresentações semelhantes


Apresentação em tema: "DO-178B Adriano Gomes. A GENDA DO-178B Definição Histórico Considerações Níveis de Softwares Processos Trabalho do Mestrado Motivações Contexto da Embraer."— Transcrição da apresentação:

1 DO-178B Adriano Gomes

2 A GENDA 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 : C RONOGRAMA H ISTÓRICO Nov DO-178-SC145 Mar 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 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 D IFERENÇ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... "... 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

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 S OFTWARE 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 - P ROCESSOS 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 – P ROCESSOS Estrutura do ciclo de vida dos processos

10 DO-178B - S OFTWARE P LANNING P ROCESS 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 - S OFTWARE D EVELOPMENT P ROCESS O processo de desenvolvimento de software é quebrado em quatro sub-processos:

12 DO-178B - S OFTWARE D EVELOPMENT P ROCESS 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 - S OFTWARE V ERIFICATION P ROCESS 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 - S OFTWARE C ONFIGURATION M ANAGEMENT P ROCESS 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 - S OFTWARE Q UALITY A SSURANCE P ROCESS 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 – C ERTIFICATION P ROCESS 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 E MBRAER : C ONTEXTO A ERONÁ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 (Functional Hazard Analysis) FTA (Fault Tree Analysis)

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 Porta OR Evento Intermediário Evento Básico

27 E MBRAER : A BORDAGEM 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 E MBRAER : A BORDAGEM 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 E MBRAER : R ESUMO DO C ONTEXTO 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 O BJETIVOS 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 O BJETIVOS 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 P ROPOSTA Modelagem seria de forma semi-automática e partiria das informações e modelos da análise de risco (Simulink, HAZOP)

33 P ROPOSTA - C ENÁRIO + Model Checking Hazard Analysis Prism Árvore de Falha

34 P ROPOSTA - B ENEFÍ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 P RÓXIMOS P ASSOS 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

40 REFERÊNCIAS Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite technologies.com/files/AeronauticsHandBook- DO178B.pdf technologies.com/files/AeronauticsHandBook- DO178B.pdf DO-178B, Software Considerations in Airborne Systems and Equipment Certification 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.

41 P ERGUNTAS ?


Carregar ppt "DO-178B Adriano Gomes. A GENDA DO-178B Definição Histórico Considerações Níveis de Softwares Processos Trabalho do Mestrado Motivações Contexto da Embraer."

Apresentações semelhantes


Anúncios Google