Organização Brasileira para o Desenvolvimento da ......CATEGORY Meaning SW Level ... • Tabela A5...

Organização Brasileira Organização Brasileira para o Desenvolvimento para o Desenvolvimento da Certificação Aeronáuticada Certificação Aeronáutica

Realização Apoio

“As informações contidas neste material são de autoria da DCA-BR, sendo vedada a sua reprodução total ou parcial”.

Patrocínio

Organização Brasileira Organização Brasileira para o Desenvolvimento para o Desenvolvimento da Certificação Aeronáuticada Certificação Aeronáutica

Qualificações de Software para Qualificações de Software para VANTsVANTs: :

“As informações contidas neste material são de autoria da DCA-BR, sendo vedada a sua reprodução total ou parcial”.

Qualificações de Software para Qualificações de Software para VANTsVANTs: :

Visão geral da RTCA DOVisão geral da RTCA DO--178B178B

Marina Mendonça Natalino ZenunMarina Mendonça Natalino Zenun

Organização Brasileira para o Desenvolvimento da Certificação Aeronáutica

MotivaçãoMotivação

• Uso crescente e Complexidade• Tecnologia está mudando

rapidamente• Tem sido usado para funções

críticas

33“As informações contidas neste material são de autoria da DCA-BR, sendo vedada a sua reprodução total ou parcial”.

críticas

• Safety• Ariane 5 – European Space

Agency (ESA) - 1996


Objetivo: Objetivo:

Apresentar uma Apresentar uma




Roteiro Roteiro

1. Introdução

2. Processos da DO-178B

• Planejamento

• Desenvolvimento


• Desenvolvimento• Integração

3. Conclusão

4. Referências


� Título:

� “Software considerations in Airborne Systems and Equipment Certification”

� Definição:� Conjunto de normas para a produção de software

IntroduçãoIntrodução


� Conjunto de normas para a produção de software embarcado.

� Desenvolvido:

� RTCA Special Committee 167 e EUROCAE WG-12.


� Objetivo: � Fornecer à comunidade da aviação um guia para

determinar de forma consistente e com um nível aceitável de confiança, que o software embarcado cumpre com os requisitos de aeronavegabilidade.

IntroduçãoIntrodução


cumpre com os requisitos de aeronavegabilidade.

� O que não faz� Não define relação entre requerente e seus fornecedores.� Não define as divisões de responsabilidades.� Não define como fazer.

Como usá-la?


Desenvolvimento Sistemas Desenvolvimento Sistemas

ComplexosComplexos

Requisitos Stakeholders(aeronavegabilidade)

Requisitos de Sistema


Requisitos de sub-sistemas

Requisitos de componentes

Software Hardware


Problema

Requisitos corretos

Requisitoserrados

Design Correto Design ErradoDesign baseado

Requisitos de baixo nível

Design

Importância de bons requisitosImportância de bons requisitos


Funções corretas Erros corrigíveis Erros incorrigíveis Erros Escondidos

Programas Corretos

Programascom erros

Programas baseadosem design errado

Programas baseados em especificação errada

Design Correto Design ErradoDesign baseado

em especificação errada

Programas imperfeitos

Implementação (coding)

Testes

Programas perfeitos


Características de bons Características de bons requisitosrequisitos

• Necessário• Conciso• Não ambíguo• Completo (standalone)


• Completo (standalone)• Consistente• Livre de implementação • Factível• Verificável

Ref.: INCOSE (International Council on Systems Engineering)


RequisitosRequisitos

� 23.1301Each item of installed equipment must be:- Of a kind and design appropriate to its intended function;- Labeled to its identification, function, or operating

limitations;


limitations;- Installed according to limitations specified for that

equipment; and- Able to function properly when installed.



� 23.1309- Design ensures it performs intended functions under anyforeseeable operating condition;- Systems and associated components, separately and in relation to other systems, designed so any failure condition


relation to other systems, designed so any failure conditionthat prevents continued flight and landing is extremelyimprobable;- Any other failure conditions which reduce the capability ofairplane or crew to cope with adverse operating conditions is improbable.



� STANAG 4671� AMC.1309(b) System Design and Analysis(6) Software development assurance levels(a) The software integrated in UAV System should perform

their intended function with a level of confidence in


their intended function with a level of confidence in safety that complies with the requirements set by this paragraph. A software safety program should include identification of the software rigor required for safety criticality elements (e.g., safety integrity level as described in IEC 61805), provide software development assurance evidence of safe software engineering (e.g, RTCA/DO-178B for software and RTCA/DO-254 for firmware)



� STANAG 4671 (cont.)� AMC.1309(b) System Design and Analysis(6) Software development assurance levels(b) The software life cycle assurance process agreed with the

Certifying Authority should be demonstrated with the


Certifying Authority should be demonstrated with the approach defined in RTCA DO- 178B / ED-12B “Software considerations in airborne systems and equipment certification”, especially with annex A for the process objectives and outputs by software level. If equivalent standards are provided, a Plan for Software Airworthiness should be provided and agreed with the Certifying Authority in order to present how the quoted standards will be applied.


• Software não segue as leis da física:

• Software não quebra;

• Não falha em modos previsíveis;

• Quanto mais o software é usado, menos provável será a

Software X Software X SafetySafety AssessmentAssessment


• Quanto mais o software é usado, menos provável será a ocorrência de falhas;

• Software não é confiável por sua própria natureza. Certamente terá erros.


• Não se pode usar abordagem de confiabilidade para software.

• Portanto design assurance é usado para se adquirir confiança no software.

• A meta do design assurance é eliminar quantos erros for possível antes de se carregar o software na aeronave (VANT).

Software X Software X SafetySafety AssessmentAssessment


possível antes de se carregar o software na aeronave (VANT). A ideia é detectar e corrigir os erros.

• Apenas um sistema simples, onde todas as combinações de entradas podem ser testadas, assegura o cumprimento dos requisitos FAR XX.1301 e 1309 sem a necessidade de se usar DO-178 B ou outro processo de design assurance.

• Assurance levels são atribuídos no processo de safety assessment.


AssuranceAssurance levelslevels -- aeronaveaeronave

CATEGORYCATEGORY MeaningMeaning SW LevelSW Level

CatastrophicCatastrophic All All failurefailure conditions that conditions that preventprevent continuedcontinued safe flight and safe flight and landinglanding

AA

HazardousHazardous Large reduction in safety margins; Large reduction in safety margins;

Crew canCrew can´́t perform tasks; t perform tasks;

Adverse impact upon occupants;Adverse impact upon occupants;

BB


Adverse impact upon occupants;Adverse impact upon occupants;

MajorMajor SignificantSignificant reductionreduction in in safetysafety;;

IncreaseIncrease workloadworkload crewcrew is is inefficientinefficient;;

DiscomfortDiscomfort to to occupantsoccupants;;

CC

Minor Minor Slight reduction in safety;Slight reduction in safety;

Slight increase in crew workload;Slight increase in crew workload;

Inconvenience to occupantsInconvenience to occupants

DD

NoNo--EffectEffect No effect on the operation of the aircraftNo effect on the operation of the aircraft EE


AssuranceAssurance levelslevels -- UAVUAV


Ref. STANAG 4671 Ref. STANAG 4671


Objetivos x Objetivos x AssuranceAssurance levelslevels DODO--178B178B

• Level A – 66 objetivos;

• Level B – 65 objetivos;Definição dos documentos

RIG

OR


• Level C – 57 objetivos;

• Level D – 28 objetivos.

Definição dos documentosa serem gerados

RIG

OR


Estrutura DOEstrutura DO--178B178B



Processo Planejamento Software

Anexo AAnexo A-- ex. Tabela Aex. Tabela A--11


Independência:Separação de

responsabilidades que garantam o cumprimento do objetivo avaliado.

(Outra pessoa)


ControleControle de de ConfiguraçãoConfiguração

� Categorias de controle p/ dados produzidos durante o ciclo de desenv. de software

� Control Category 1 (CC1) - Rigoroso

� Control Category 2 (CC2) – Folgado

� Essas categorias são relacionadas ao controle do gerenciamento da configuração indicados na tabela abaixo:


configuração indicados na tabela abaixo:


• Tabela A1 – Software Planning Process• Tabela A2 – Software Development Process• Tabela A3 – Verification of Outputs of Requirements Process• Tabela A4 – Verification of Outputs of Design Process• Tabela A5 – Verification of Outputs of Coding/ Integration Process

DODO--178B 178B –– Anexo AAnexo A


• Tabela A6 – Testing of Outputs of Integration Process• Tabela A7 – Verification of Verification Process Results• Tabela A8 – Software Configuration Management Process• Tabela A9 – Software Quality Assurance Process• Tabela A10 – Certification Liaison Process


DivisãoDivisão dos dos ciclosciclos da DOda DO--178B178B

Planejamento Define e coordena as atividades dos processos de desenvolvimento e integração de software para um projeto.

Desenvolvimento Produz o produto do software. É dividido em:- Processo de definição de requisitos do software

- Processo de projeto do software


- Processo de projeto do software

- Processo de codificação do software

- Processo de integração do software.

Integração Garante correção, controle e confiança nos processos de desenvolvimento do software e nas suas saídas. É dividido em:

- Processo de verificação do software

- Processo de controle de configuração do software

- Processo de garantia da qualidade do software

- Processo de interface com a certificação.DO-178B


DO-178B

Definição dos objetivospara os

Descrição das atividades

dos processos

Processos da DOProcessos da DO--178B178B


para os processos

Descrição das evidências (outputs)


ProcessoProcesso de de PlanejamentoPlanejamento do Softwaredo Software



Verificação

ProjetoControle de

Planejamento Requisitos

PlanejamentoPlanejamento


ProjetoControle de Configuração

Garantia da Qualidade

Interface com Autoridade

Codificação

Integração


Processo de Planejamento do

SoftwareInformações sobre o produto a ser gerado

Planos

ENTRADA SAÍDAS



produto a ser gerado

Padrões


Planos

PSAC - Plan for Software Aspects of CertificationSDP - Software Development PlanSVP - Software Verification PlanSCMP - Software Configuration Management Plan

SAÍDAS



SCMP - Software Configuration Management PlanSQAP - Software Quality Assurance Plan

PadrõesSRS - Software Requirements StandardsSDS - Software Design StandardSCS - Software Code Standard

Geração dos documentos: Baseada nos níveis de software


ProcessoProcesso de de DesenvolvimentoDesenvolvimento do do

SoftwareSoftware



Verificação

ProjetoControle de


DesenvolvimentoDesenvolvimento





Codificação

Integração



�� Saídas do Processo de DesenvolvimentoSaídas do Processo de Desenvolvimento

Dados SRD - Software Requirements Data

SDD – Software Design Description

Código SC – Source Code

Descrição


Código SC – Source CodeEOC – Executable Object Code

Geração dos documentos: Baseada nos níveis de software



�� Tabela ATabela A--22

((Desenv. de softwareDesenv. de software))



ProcessoProcesso de de DesenvolvimentoDesenvolvimento

((DefiniçãoDefinição de de RequisitosRequisitos do Software)do Software)


((DefiniçãoDefinição de de RequisitosRequisitos do Software)do Software)


Verificação

ProjetoControle de







Codificação

Integração



Processo de Projeto do

Processo de Definição de Requisitos do Software

Requisitos do sistema

Interface de Hardware

SRD - Software Requirements Data

ENTRADAS SAÍDA

(Requisitos de alto nível + derivados):

- Funcionais


Software

Processo de Integração

Processo de Codificação do

Software

Arquitetura do sistema

SDP- Software Develop. Plan

SRS - Software Req. Standards

- Funcionais

- Desempenho

- Interfaces HW e SW

- Segurança

Processo de Desenvolvimento



((ProjetoProjeto de Software)de Software)


((ProjetoProjeto de Software)de Software)


Verificação

ProjetoControle de


ProjetoProjeto





Codificação

Integração


ProjetoProjetoENTRADAS SAÍDA

SRD - Software Requirements Data


Processo de Projeto do

Processo de Definição de Requisitos do Software


SDP - Software Develop. Plan

SDS - Software Design Standards

(Arquitetura do Software e Requisitos de baixo

nível)

Requisitos de alto nível usados

Software


Processo de Codificação do

Software




((CodificaçãoCodificação de Software)de Software)


((CodificaçãoCodificação de Software)de Software)


Verificação

ProjetoControle de


CodificaçãoCodificação





Codificação

Integração


CodificaçãoCodificaçãoENTRADAS SAÍDAS

Código Fonte

Processo de Projeto de

Processo de Definição de Requisitos de Software

(Arquitetura do Software e Requisitos de baixo

nível)



Código Objeto Executável

Software


Processo de Codificação de

Software

SDP - Software Develop. Plan

SCS - Software Code Standards

nível)




((IntegraçãoIntegração))


((IntegraçãoIntegração))


Verificação

ProjetoControle de


IntegraçãoIntegração





Codificação

Integração


IntegraçãoIntegraçãoENTRADAS SAÍDA

Arquitetura do Software

Código FonteProcesso de Projeto de

Processo de Definição de Requisitos de Software

Estrutura selecionada para implementar os requisitos


Código Objeto Executável Final


Projeto de Software


Processo de Codificação de

SoftwareSDP - Software Develop. Plan


Computador principal


ProcessoProcesso de de IntegraçãoIntegração

((ProcessoProcesso de de VerificaçãoVerificação de Software)de Software)


((ProcessoProcesso de de VerificaçãoVerificação de Software)de Software)

“V&V”“V&V”


Verificação

ProjetoControle de


IntegraçãoIntegração





Codificação

Integração


Verificação

ProjetoControle de


VerificaçãoVerificação





Codificação

Integração



�Verificação não é simplesmente teste.

�O processo de verificação de software é uma combinação

de:� Revisões

� Análises


� Análises

� Desenvolvimento de casos de teste e procedimentos

� Execução dos procedimentos de teste.



Processo de Revisão e Análise

Requisitos do Sistema

Verificação de:

• precisão

• integralidade (perfeição)

• requisitos verificáveis

• Arquitetura do sw

Processo de Verificação de Software

Requisitos de Software (SRD)

Software Verification Cases &

Procedures

Arquitetura de Software (SDD)

ENTRADAS

SAÍDAS

Saídas dos processos:

Requisitos

Projeto

Codificação

Integração

VerificaçãoSVCP


Execução dos Procedimentos

Processo de Teste do Software

(Desenv. de test cases e

procedimentos)

• Arquitetura do sw

• Código fonte

Verificação de:

• consistência interna

• perfeição dos requisitos

Demonstração de cumprimento com os

requisitos

Rastreabildade de dados

Código Fonte


Software Verif. Plan (SVP)

Software Verification Results

SVR




(Verificação das saídas do(Verificação das saídas do

processo de processo de definição dedefinição de

requisitosrequisitos))

………até………até


………até………até


(Verificação dos resultados(Verificação dos resultados

do do processo de verificaçãoprocesso de verificação))




(Verificação das saídas do processo(Verificação das saídas do processo

de de projeto de softwareprojeto de software))





(Verificação das saídas(Verificação das saídas

dos dos processos de processos de

codificação codificação e integração)e integração)





(Teste das saídas(Teste das saídas

do do processo de processo de

integraçãointegração))





(Verificação dos resultados(Verificação dos resultados

do do processo de verificaçãoprocesso de verificação))




((ProcessoProcesso de de ControleControle de de ConfiguraçãoConfiguração


((ProcessoProcesso de de ControleControle de de ConfiguraçãoConfiguração

de Software)de Software)


Verificação

ProjetoControle de







Codificação

Integração



�� CategoriasCategorias de de controlecontrole p/ dados p/ dados produzidosproduzidos durantedurante o o ciclociclo de de desenvdesenv. de . de swsw

� Control Category 1 (CC1) - Rigoroso

� Control Category 2 (CC2) - Folgado

� Essas categorias são relacionadas ao controle do gerenciamento da configuração

indicados na tabela abaixo:


indicados na tabela abaixo:


ControleControle de de ConfiguraçãoConfiguraçãoENTRADA SAÍDAS

SCMR

Software Configuration Management Records

Processo de Controle de

Software Configuration Management Plan

SCI – Software Config. Index


SCMP

PR – Problem Report

Controle de Configuração

SECI

Software life Cycle Environment Config. Index

Management Plan Config. Index




(Processo de (Processo de controle de controle de

configuraçãoconfiguração de software)de software)




((ProcessoProcesso de de GarantiaGarantia da da QualidadeQualidade de de


((ProcessoProcesso de de GarantiaGarantia da da QualidadeQualidade de de

Software)Software)


Verificação

ProjetoControle de


GarantiaGarantia da da QualidadeQualidade





Codificação

Integração



ENTRADA SAÍDA

SQAP SQAR

Software Quality Assurance Plan

Processo de Garantia da

Software Quality Assurance Records


SQAP SQARGarantia da Qualidade




(Processo de (Processo de garantia dagarantia da

qualidade de softwarequalidade de software))



Processo de IntegraçãoProcesso de Integração

(Interface com a Autoridade)(Interface com a Autoridade)


(Interface com a Autoridade)(Interface com a Autoridade)


Verificação

ProjetoControle de


Interface com a AutoridadeInterface com a Autoridade





Codificação

Integração


SAÍDAS

PSAC


�� Documentação mínima Documentação mínima

submetida à autoridade de submetida à autoridade de

certificaçãocertificação

� PSAC: Plan for Software

Aspects of Certification


SAS

SCI

Documentos adicionais

Interface com a Certificação

� SCI: Software Configuration

Index

� SAS: Software

Accomplishment Summary



(Processo de (Processo de interface cominterface com

a Autoridadea Autoridade))




Verificação

ProjetoControle de


ConclusãoConclusão





Codificação

Integração


Objetivo: Objetivo:

Apresentar uma Apresentar uma




ReferênciasReferências

� RTCA DO-178B: “Software Considerations in Airborne Systems

and Equipment Certification”

� Livro: Avionics Certification: A complete guide to DO-178 (software)

and DO-254 (hardware)


and DO-254 (hardware)

� STANAG 4671: Standardization Agreement – Subject: Unmanned

Aerial Vehicles Systems Airworthiness Requirements (USAR)

� SAE ARP 4761: Guidelines and Methods for Conducting the

Safety Assessment Process on Civil Airborne Systems and

Equipment


Obrigada!Obrigada!Obrigada!Obrigada!


Organização Brasileira para o Desenvolvimento da ......CATEGORY Meaning SW Level ... • Tabela A5...

Documents

Transcript of Organização Brasileira para o Desenvolvimento da ......CATEGORY Meaning SW Level ... • Tabela A5...