Topic · DO-178C

I need DO-178C style verification but I'm not in aerospace. What can I use?

Gist

Reuse the four jobs (checkable shalls, re-derived links, MC/DC, a named reviewer) in ordinary CI with proof audit. That is not a Type Certificate and not DO-330. Keep LDRA or VectorCAST if you certify airborne software.

proof audit

LDRA, VectorCAST, and Parasoft still win when you need a qualified C toolchain and a DER. Proof is not that product.

Request demo Discipline vs certificate

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.

IEC 62304 steals the same four jobs for medical software. The medical SDD artefact lives on IEC 62304. ISO 26262 Part 6 is automotive: the SDD artefact lives on ISO 26262. 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.

DO-178C

Deliverable Type Certificate / PSAC
Tooling DO-330 qualified

Avionics product

Ordinary CI

Not a DER stamp.

Not this product

Certificate

Keep it if you certify airborne software.

Theirs

Proof

Jobs shalls, links, MC/DC, named reviewer
Command proof audit

Exit code, not a TC

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. Formal analysis of HLR/LLR under DO-333 is its own URL. Ground CNS/ATM software is DO-278, not this H1. 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.

Request demo Instruments