Safety Standards Quick-Reference Matrix

This is for someone entering a regulated domain, or holding two of them up against each other to see where they differ. Each standard is written as though it were the only one you had to read, so the comparison here is the one none of them make for you.

Nothing on this sheet governs anything. The clause text of the standard — as read by the assessor who signs your system off — is the only authority, and where the two disagree, the standard is right.

1. The standards, by domain

Standard	Domain	What it governs	The artefact it demands
IEC 61508	Generic	Safety lifecycle and SIL allocation. Parent of the sector standards	Safety requirements spec; functional safety assessment
EN 50126 / EN 50129	Rail	RAMS lifecycle, hazard management, and the signalling approval route	RAMS programme plan and hazard log; the safety case
EN 50128	Rail	Software lifecycle and role independence by SIL. Superseded by EN 50716:2023	SQA plan, V&V reports, the software safety case
DO-178C	Airborne	Software life cycle for certification. The DAL comes from the safety assessment	PSAC and a Software Accomplishment Summary
ISO 26262	Automotive	E/E functional safety; ASIL from severity, exposure, controllability	HARA, work products per part, safety case
Automotive SPICE	Automotive	Process capability. Assessed and rated, never certified	Assessment report rating each process 0 to 5

CBTC is an architecture, not a safety standard: IEEE 1474.1 sets its functional and performance requirements, and its safety argument is still made under EN 5012x or IEC 61508.

2. Integrity levels, side by side

Band	Rail (SIL)	Airborne (DAL)	Automotive (ASIL)	Dangerous failures per hour	Consequence guarded against
Highest	SIL 4	Level A	ASIL D	`10^-9` to `10^-8`	Multiple fatalities
High	SIL 3	Level B	ASIL C	`10^-8` to `10^-7`	A fatality or severe injuries
Medium	SIL 2	Level C	ASIL B	`10^-7` to `10^-6`	Serious permanent injury
Low	SIL 1	Level D	ASIL A	`10^-6` to `10^-5`	Minor, recoverable injury
None	SIL 0	Level E	QM	Not apportioned	No safety effect

These mappings are approximate — an orientation aid, not a substitution rule. SIL is set by a quantified failure rate, DAL by the severity of the system-level failure condition, ASIL by severity, exposure and controllability together, so a level in one column is never evidence for a level in another. The rates are IEC 61508 continuous mode and apply to the SIL column only; DO-178C assigns software no numerical rate.

3. What each level demands of software

Requirement	Lower (SIL 1–2, DAL C–D, ASIL A–B)	Higher (SIL 3–4, DAL A–B, ASIL C–D)
Traceability	Requirement to test, forward only	Bidirectional, and kept live
Structural coverage	Statement at DAL C, none at DAL D	Decision at DAL B, MC-DC at DAL A
Independence	Roles may be combined within limits	Independent verifier and validator
Tool qualification	None where a tool cannot introduce or mask an error	EN 50128 T2/T3, DO-330, ISO 26262 TCL
Formal methods	Optional; static analysis suffices	EN 50128 recommends them; DO-333 for DO-178C
Change control	Reviewed, attributable changes	Baselines and change impact analysis

4. Evidence an assessor asks for

Artefact	What it must show	Where it usually comes from
Requirements specification	Testable and uniquely identified	Systems engineering, not developers
Traceability matrix	Forward and backward, with no gaps	The requirements tool, per baseline
Test and coverage results	Tests pass on target; coverage met	The CI or HIL pipeline, per build
Tool qualification records	Each tool's class and its evidence	The vendor's kit, or your own suite
Hazard log	Every hazard, its level and status	The safety team, live from concept
Safety case	That the system is acceptably safe	Safety engineer; independent assessor
Competency records	That role holders were qualified	Training records, per EN 50128 Annex B

5. Vital and non-vital partitioning

Flow across the barrier	Permitted	Condition
Vital to non-vital: status for display	Yes	One way; the vital side never blocks on it
Non-vital to vital: commands or parameters	No	A read-only API is still an input
Non-vital to vital: configuration or map data	Offline only	Authenticated, and vitally checked on load
Shared CPU, memory, bus or power rail	Only if partitioned	Non-vital code must not starve the vital side

Mechanism	What it actually enforces	What it costs
Physically separate hardware	Independence by construction	Two boxes, two BOMs, two lifecycles
Hypervisor or MMU partitioning, ARINC 653 style	Space and time separation on one processor	The hypervisor is vital at the top level it hosts
One-way link: a data diode, or a UART with no return path	The vital side cannot receive at all	No acknowledgements; tolerate silent loss
Independent watchdog or vital relay	Failure ends in the defined safe state	Not a barrier; only a failure behaviour

The barrier is part of the vital system and carries its integrity level. A SIL 4 system joined to a SIL 0 system through a SIL 0 gateway is a SIL 0 system.

How to read this matrix

Levels are assigned, not chosen. The integrity level falls out of the hazard analysis; it is an output of the safety process, not an input to it. A team that decides it is building a SIL 2 product before anyone has identified the hazards has skipped the step that determines the answer.

The evidence is the deliverable. Working software with no traceable evidence behind it does not certify. Every artefact in section 4 is cheap to produce as the work happens and expensive to reconstruct later, because reconstruction means re-deriving decisions from code written by people who have moved on — and an assessor can usually tell the difference.

ITAR and export control are orthogonal to all of it. They constrain who may see the code and where it may live, independently of any safety level: a SIL 0 build script can be as controlled as a SIL 4 protection algorithm. Disclosure to a foreign person is an export even when nobody leaves the building, Canadian firms handling controlled goods need Controlled Goods Program registration, and getting it wrong is a legal problem rather than an engineering one.

When this needs outside help

Most of this is learnable, and a team with the time should learn it. It is worth bringing in help when the learning lands on the wrong side of a deadline:

A first certification with no in-house precedent to copy. The standards say what evidence is required, not how much satisfies your assessor, and a first project gets that wrong in both directions
A legacy codebase that must be certified without a rewrite, where the work is reconstructing evidence for code that already ships
A system where the vital and non-vital boundary has not been drawn, because that decision sets the certification scope and the architecture, and has to precede the code

If any of those describe where you are, this is work we do: contact@mnpsystems.ca.