Octo for DO-178C flight software
Octo can prepare, for human review, part of the verification work on flight software under DO-178C (RTCA's guidance for airborne software): MC/DC pairs (modified condition/decision coverage), test cases, pre-review against the coding standard, traceability and continuous integration (CI) scripts that call VectorCAST, Polyspace and GNATcoverage. The evidence is still the output of the qualified tool; decisions and certification belong to qualified people and authorities.
Six possible deliverables, drawn from the research. All are drafts prepared for human review or for checking by a qualified tool; none becomes evidence on its own.
It can read the code before the tool does and point out likely violations of MISRA C (the C coding standard for critical systems) or of the project's internal standard, explain the rule and propose the fix. The compliance that counts is still the output of Polyspace, LDRA or GNATcheck.
Deliverable: list of findings with the rule and the fixIt can build the decision's truth table and find, for each condition, the pair of tests in which only that condition changes and the outcome changes with it. For (A && B) || C, the minimum set is 4 tests.
It can read the low-level requirement and propose inputs, expected outputs and boundaries, and write the test script in VectorCAST or RapiTest format for the engineer to review before it enters the project.
Deliverable: draft test cases, in the tool's formatIt can cross-check the requirement → code → test matrix and point out requirements with no test, tests with no requirement and code with no requirement; in the coverage report, it proposes separating what is “missing a test” from what “needs a justification”.
Deliverable: gap report per requirementIt can draft the verification plan, the configuration index, the coverage justifications and the review packages, and propose a standard for what comes out of CI (tool version, commit, date, report) so nothing is missing at audit time.
Deliverable: draft documents for reviewIt can write and maintain the scripts that call VectorCAST/Manage with a CI license, Polyspace Bug Finder Server and Code Prover Server, and GNATcoverage with MC/DC, and store the execution context alongside.
Deliverable: .sh scripts + archived resultsThe same Octo cycle, applied to DO-178C verification. Each arm has a narrow role; the qualified engineer decides, and the certification authority accepts.
Which tools the project uses, in which version, with which qualification kit, for which software level. Reads the certification plan to know what each tool can and cannot replace.
Where each report lives, the requirement → code → test matrix and the context file of each run: date, commit and tool installation. Without that, the report isn't traceable.
Aerospace project data may be restricted by contract or by export rules. Sending controlled data (ITAR/EAR, U.S. export control regulations) to any external service, including AI, must first be assessed by the client's compliance team.
For each DO-178C objective, the project tool that produces the evidence, and whether the intended use, including in CI, fits within the scope of its qualification kit.
CI scripts, test cases, MC/DC pairs and pre-review against the standard. Every command-line option is checked against the --help of the installed version.
The result is read in the qualified tool's report, not in Octo's message. The reviews DO-178C requires with independence stay with people who didn't write the code.
The approved script goes into the project's CI and runs with every change. Octo sends nothing to the authority; your team does the submitting.
Versions, options confirmed on your installation, justifications accepted by the engineer and what was left pending. The next round starts from the right point.
Nothing Octo writes becomes evidence until a person or a qualified tool checks it.
The DO-178C objectives and the tools from this research that produce the evidence. Octo can prepare the work; the evidence comes from the middle column, and approval from qualified people.
| Objective or activity | Tool that produces the evidence | Where Octo helps |
|---|---|---|
| Code generated from a model (DO-331) | SCADE Suite, KCG generator (TQL-1) | Model → requirement traceability |
| Code compliant with the coding standard | Polyspace Bug Finder (MISRA), LDRA, GNATcheck (TQL-5) | Pre-review and an explanation of each rule |
| Accuracy and robustness (run-time errors) | Polyspace Code Prover; SPARK/GNATprove (DO-333) | CI script with a versioned options file |
| Low-level and integration testing | VectorCAST, LDRA, RapiTest | Draft test cases; manage --ci --build-execute in CI |
| Statement (C), decision (B) and MC/DC (A) coverage | VectorCAST, LDRA, RapiCover, GNATcoverage | MC/DC pairs; reading the report and listing what's missing |
| Additional object code verification at level A | LDRA (assembler coverage), RapiCover + RapiCover Zero, AdaCore compiler study | Organizing the evidence and justifications |
| Data and control coupling | LDRA, VectorCAST (optional) | Cross-check with the architecture and point out gaps |
| Requirement ↔ code ↔ test traceability | LDRA TBmanager; requirement annotations in Scade One | Cross-matrix: requirements with no test, code with no requirement |
| Partitioned real-time operating system (RTOS) with evidence ready | VxWorks 653 / Helix, INTEGRITY-178 tuMP, Deos, LynxOS-178 | Compare what each vendor declares in its evidence package |
| Multicore interference (AC 20-193) | INTEGRITY-178 tuMP, Deos SafeMC, Rapita multicore kits | Survey what each vendor declares |
Three steps. Each one only makes sense after the previous one has shown results on your project and been accepted by the responsible engineer.
A proposal, not a promise
The engineer asks in project terms and gets a draft to review.
The project's tools run from the command line with every change, with the result stored.
Traceability and draft documents keep pace with the code, for human review.
Every point below has a source published by the vendor, the project or the responsible agency. The sources are in the next section.
5
points with a published source, each with its reference alongside.
Octo prepares everything, but does not sign. The document of record stays with whoever is accountable for it.
Surveys, calculates, organizes and generates the documents: spreadsheets, reports, drawings and drafts.
Deliverable: material ready to checkThe licensed professional checks what Octo delivered before signing. If something doesn't add up, it goes back to Octo with the correction.
Step: review by the signerOcto does not sign. Designs, technical reports, ART/RRT (Brazil's professional responsibility records), accountability reports and any official document are still signed by the company's or agency's licensed professional: here, the responsible engineer and the certification authority.
Sign-off: responsible engineer and certification authorityVendor and FAA documentation used on this page, read on October 28, 2026.
manage syntaxThe assessment starts by reading your pipeline, the tool reports and the traceability matrix, respecting the project's export and contract rules, without changing anything. You get a map of what Octo can prepare for human review and decide with it in hand.