DO-178C
- Deliverable Type Certificate / PSAC
- Tooling DO-330 qualified
Topic · DO-178C
I need DO-178C style verification but I'm not in aerospace. What can I use?
Proof re-runs the parts of DO-178C that are a discipline: shalls a compiler accepts, links it re-derives, MC/DC on the code you ship. That is ordinary CI, not a Type Certificate.
proof auditLDRA, VectorCAST, and Parasoft still win when you need a qualified C toolchain and a DER. Proof is not that product.
01 · The distinction
The standard is a certificate. The useful part is four jobs.
DO-178C is RTCA guidance for airborne software. Most of its cost is artefacts an auditor demands. The four jobs that actually change the software are cheaper to steal than to certify against.
NASA and DO-178C name four verification methods. Every shall gets one: Test, Analysis, Inspection, or Demonstration. Only the behavioural shalls belong under Test. A coding-standard shall is Inspection. A 20 ms loop budget is Analysis. You do not formalize the lot.
ISO 26262 Part 6 and IEC 62304 steal the same four jobs for automotive and medical software. They sit on this page, not on twins. The ALM that stores the shalls (Jama, DOORS, Polarion) is still the programme author. Proof is the re-read in CI.
02 · The exhibit
Four jobs. Two products. One you can run tonight.
A green Proof run is an exit code on those four jobs. It is not a PSAC, and it is not tool qualification.
Ordinary CI
Not a DER stamp.
Not this productCertificate
Keep it if you certify airborne software.
TheirsProof
- Jobs shalls, links, MC/DC, named reviewer
- Command proof audit
Same four jobs. Two products. Click the tabs.
| Job | Avionics product | Proof in ordinary CI |
|---|---|---|
| Shall a machine can check | Prose in the ALM, then a human translation into tests. | FRETish compiles or it does not. proof validate --preflight |
| Bidirectional traceability | Asserted links in Jama / DOORS. They age. | Links re-derived from the code. proof audit --check spec_lint_ac_subset_of_satisfies |
| MC/DC | LDRA / VectorCAST on a qualified C/Ada compiler pairing. | Native on the stack you ship. proof mcdc measure ./... --engine go |
| Independence | A separate V&V organisation. A DER who already knows the report. | A named reviewer on the finding. Not a DER. Not independence as the standard means it. |
| Tool qualification | DO-330. The toolchain is the product. | Not qualified. Keep theirs if a certificate is the point. |
Drawn for this page. The split is the product, not a score from their analyzer.
# behavioural shall → Test when sensor_high the controller shall immediately satisfy safe_mode # coding standard → Inspection (linter + review, not this compiler) # loop budget → Analysis (WCET, not this compiler)
proof validate --preflight proof audit --check spec_lint_ac_subset_of_satisfies proof mcdc measure ./... --engine go proof audit
The first command rejects a sentence the 288 templates cannot parse. The second fails the build when a shall has no code that still keeps it. The third is structural coverage on Go, not on object code a qualified compiler emitted. The fourth is the standing gate.
03 · The honest loss
Proof is not a DO-330 qualified tool.
A green audit is not a Type Certificate. Keep the avionics toolchain if you certify airborne software. Proof does not produce a PSAC a DER will stamp.
On C and C++, structural coverage is theirs. Proof imports compiler coverage; it does not instrument. That row lives on Proof vs LDRA. VectorCAST and Parasoft are the same cluster, named there.
Jama still wins at programme authoring: thousands of shalls, reviews, baselines. DOORS sits on the Jama page, not a twin. Formal analysis of source (SPARK, Frama-C) is outside Proof. Safety assessment (FHA, FTA) is outside Proof. ISO 26262 shops keep their own Part 6 toolchain if a safety case is the deliverable.
The shalls themselves are the FRETish compiler. The ageing links are the traceability matrix. The coverage criterion is MC/DC for Go.