Octo para software de voo DO-178C
O Octo pode preparar, para revisão humana, parte do trabalho de verificação de software de voo sob DO-178C (guia da RTCA para software embarcado em aeronaves): pares de MC/DC (cobertura de condição e decisão modificada), casos de teste, revisão prévia contra o padrão de codificação, rastreabilidade e scripts de integração contínua (CI) que chamam VectorCAST, Polyspace e GNATcoverage. A evidência continua sendo a saída da ferramenta qualificada; a decisão e a certificação são de pessoas e autoridades habilitadas.
Seis entregas possíveis, tiradas do levantamento. Todas são rascunho preparado para revisão humana ou para conferência por ferramenta qualificada; nenhuma vira evidência sozinha.
Pode ler o código antes da ferramenta e apontar prováveis violações de MISRA C (padrão de codificação C para sistemas críticos) ou do padrão interno do projeto, explicar a regra e propor a correção. A conformidade que conta continua sendo a saída do Polyspace, do LDRA ou do GNATcheck.
Entrega: lista de achados com a regra e a correçãoPode montar a tabela-verdade da decisão e achar, para cada condição, o par de testes em que só ela muda e o resultado muda junto. Para (A && B) || C, o conjunto mínimo é de 4 testes.
Pode ler o requisito de baixo nível e propor entradas, saídas esperadas e limites, e escrever o script de teste no formato do VectorCAST ou do RapiTest para o engenheiro revisar antes de entrar no projeto.
Entrega: casos de teste em rascunho, no formato da ferramentaPode cruzar a matriz requisito → código → teste e apontar requisito sem teste, teste sem requisito e código sem requisito; no relatório de cobertura, propõe separar o que é “falta teste” do que “precisa de justificativa”.
Entrega: relatório de lacunas por requisitoPode rascunhar o plano de verificação, o índice de configuração, as justificativas de cobertura e os pacotes de revisão, e propor um padrão para o que sai do CI (versão da ferramenta, commit, data, relatório) para não faltar item na auditoria.
Entrega: rascunhos de documentos para revisãoPode escrever e manter os scripts que chamam o VectorCAST/Manage com licença de CI, o Polyspace Bug Finder Server e Code Prover Server, e o GNATcoverage com MC/DC, e guardar junto o contexto da execução.
Entrega: scripts .sh + resultados arquivadosO mesmo ciclo do Octo, aplicado à verificação DO-178C. Cada braço tem um papel estreito; quem decide é o engenheiro habilitado, e quem aceita é a autoridade certificadora.
Que ferramentas o projeto usa, em que versão, com que kit de qualificação, para que nível de software. Lê o plano de certificação para saber o que cada ferramenta pode e não pode substituir.
Onde fica cada relatório, a matriz requisito → código → teste e o arquivo de contexto de cada execução: data, commit e instalação da ferramenta. Sem isso o relatório não é rastreável.
Dados de projeto aeronáutico podem ter restrição de contrato ou de exportação. O envio de dados controlados (ITAR/EAR, regulamentos de controle de exportação dos EUA) a qualquer serviço externo, inclusive de IA, deve ser avaliado antes pela área de conformidade do cliente.
Para cada objetivo da DO-178C, a ferramenta do projeto que gera a evidência, e se o uso previsto, inclusive em CI, cabe no escopo do kit de qualificação dela.
Scripts de CI, casos de teste, pares de MC/DC e revisão prévia contra o padrão. Cada opção de linha de comando é conferida no --help da versão instalada.
O resultado se lê no relatório da ferramenta qualificada, não na mensagem do Octo. As revisões que a DO-178C pede com independência continuam com pessoas que não escreveram o código.
O script aprovado entra no CI do projeto e passa a rodar a cada mudança. Nada é enviado à autoridade pelo Octo; quem submete é a sua equipe.
Versões, opções confirmadas na sua instalação, justificativas aceitas pelo engenheiro e o que ficou pendente. A próxima rodada começa do ponto certo.
Nada do que o Octo escreve vira evidência sem uma pessoa ou uma ferramenta qualificada conferir.
Os objetivos da DO-178C e as ferramentas deste levantamento que geram a evidência. O Octo pode preparar o trabalho; a evidência vem da coluna do meio, e a aprovação, de pessoas habilitadas.
| Objetivo ou atividade | Ferramenta que gera a evidência | Onde o Octo ajuda |
|---|---|---|
| Código gerado a partir de modelo (DO-331) | SCADE Suite, gerador KCG (TQL-1) | Rastreabilidade modelo → requisito |
| Código conforme o padrão de codificação | Polyspace Bug Finder (MISRA), LDRA, GNATcheck (TQL-5) | Revisão prévia e explicação de cada regra |
| Exatidão e robustez (erros de execução) | Polyspace Code Prover; SPARK/GNATprove (DO-333) | Script de CI com arquivo de opções versionado |
| Teste de baixo nível e de integração | VectorCAST, LDRA, RapiTest | Casos de teste em rascunho; manage --ci --build-execute no CI |
| Cobertura de comando (C), decisão (B), MC/DC (A) | VectorCAST, LDRA, RapiCover, GNATcoverage | Pares de MC/DC; leitura do relatório e lista do que falta |
| Verificação adicional de código objeto no nível A | LDRA (cobertura de assembler), RapiCover + RapiCover Zero, estudo AdaCore do compilador | Organizar a evidência e as justificativas |
| Acoplamento de dados e controle | LDRA, VectorCAST (opcional) | Cruzar com a arquitetura e apontar lacunas |
| Rastreabilidade requisito ↔ código ↔ teste | LDRA TBmanager; anotações de requisito no Scade One | Matriz cruzada: requisito sem teste, código sem requisito |
| Sistema operacional de tempo real (RTOS) particionado com evidência pronta | VxWorks 653 / Helix, INTEGRITY-178 tuMP, Deos, LynxOS-178 | Comparar o que cada fornecedor declara no pacote de evidência |
| Interferência em multicore (AC 20-193) | INTEGRITY-178 tuMP, Deos SafeMC, kits multicore da Rapita | Levantar o que cada fornecedor declara |
Três degraus. Cada um só faz sentido depois que o anterior mostrou resultado no seu projeto e foi aceito pelo engenheiro responsável.
Proposta, não promessa
O engenheiro pede em linguagem de projeto e recebe um rascunho para revisar.
As ferramentas do projeto passam a rodar por linha de comando a cada mudança, com o resultado guardado.
A rastreabilidade e os rascunhos de documento acompanham o código, para revisão humana.
Cada ponto abaixo tem fonte publicada pelo fabricante, pelo projeto ou pelo órgão responsável. As fontes estão na seção seguinte.
5
pontos com fonte publicada, cada um com a referência indicada ao lado.
O Octo prepara tudo, mas não assina. O documento que vale continua com quem responde por ele.
Levanta, calcula, organiza e gera os documentos: planilhas, relatórios, desenhos e minutas.
Entrega: material pronto para conferirO profissional habilitado confere o que o Octo entregou antes de assinar. Se algo não fecha, volta para o Octo com a correção.
Etapa: conferência por quem assinaO Octo não assina. Projeto, laudo, ART/RRT, prestação de contas e qualquer documento oficial continuam assinados pelo profissional habilitado da empresa ou do órgão: aqui, o engenheiro responsável e a autoridade de certificação.
Assinatura: engenheiro responsável e autoridade de certificaçãoDocumentação dos fabricantes e da FAA usada nesta página, lida em 28/10/2026.
manageO diagnóstico começa lendo o seu pipeline, os relatórios das ferramentas e a matriz de rastreabilidade, respeitando as regras de exportação e de contrato do projeto, sem alterar nada. Você recebe o mapa do que o Octo pode preparar para revisão humana e decide com ele na mão.