Topic · IEC 61508

What is IEC 61508, and how do I keep the software safety requirements true in CI?

Gist

IEC 61508 is industrial functional safety. Part 3 is software. SIL 1 through 4 is the cost ladder, not a badge on the cover. Proof runs Kind2 on the software safety requirements with proof realize, then fails the merge when the graph is stale.

proof realize specs/system ./... --diagnose

Keep the TÜV assessment if you need a certificate. Keep LDRA or VectorCAST if a qualified C toolchain has to stamp structural coverage. Proof is not that certificate, and it is not hardware SIL.

Request demo Last SIL pack vs this push

01 · The dated SIL pack

A SIL number is not a software safety requirement. Last review is not this push.

Part 3 asks whether the software safety requirements are specified, consistent, and verifiable. A person can write those once. The next commit does not reopen Kind2.

ISO 26262 is the automotive child of this standard. Its SDD artefact lives on ISO 26262. IEC 62304 is medical software: IEC 62304. DO-333 is the aviation formal-methods supplement: DO-333. This page is the parent industrial document: run Kind2 on the shalls you already gate, then fail the merge when they go stale.

Formal methods on software safety requirements get more recommended as SIL rises. Kind2 realizability is that method on the shalls you actually wrote. It is not a Type Approval. It is not FMEDA. Hardware random-failure rates still belong to the safety engineer.

proof validate --preflight
proof realize specs/system ./... --diagnose
proof audit --fail-level warn

The first command rejects a sentence the templates cannot parse. The second is Kind2 on the loaded shalls, with a counterexample when they cannot all be true. The third is the standing gate. A green suite on last quarter's SIL pack is how the contradiction survived.

02 · The exhibit

Same SIL on the cover. A date, or this graph.

The pack still says SIL 3. The shalls moved. Click the tabs.

Word / TÜV pack

Cover SIL 3 from last assessment
SSR-12 still in the appendix

Sections present

This push

Two shalls now contradict. The pack did not reopen Kind2.

No diagnose

Word / TÜV pack

Still last assessment. Still a date.

Keep the certificate path

Proof

Ask are the shalls co-satisfiable
Gate audit --fail-level warn

Merge blocked if Kind2 returns a counterexample

Same SIL on the cover. A date, or this graph. Click the tabs.

SIL	What Part 3 is asking	What Proof runs	What Proof loses
SIL 1	Software safety requirements specified and verifiable	FRETish parse, then the audit on traces	Not a certificate. Jama still authors the shall.
SIL 2	More verification on the same shalls	`proof realize` plus re-derived links	Not hardware. Not FMEDA. Not a random-failure rate.
SIL 3	Formal methods recommended on the software safety requirements	Kind2 realizability on the shalls you wrote	Not TÜV. Not a qualified tool under DO-330.
SIL 4	Formal methods and structural coverage, including MC/DC in many programmes	Specification-level MC/DC via FLIP, same Kind2 check	Code-level MC/DC on C still wants LDRA or VectorCAST. Tests are not executed.

The realize command loads the project, then Kind2, then prints the counterexample when the shalls cannot all hold:

proof validate --preflight
proof realize specs/system ./... --diagnose
proof audit --fail-level warn

Unknown requirement language fails before the solver. A thin graph makes a thin check. Treat the Kind2 result as a view of the shalls, not as a second source of SIL. We have not run this against a frozen IEC 61508 corpus, and we have not scored it against LDRA or VectorCAST on the same pack. The loss is named, not scored.

03 · The honest loss

A green Proof audit is not a SIL.

SIL 1 through 4 still belong to the programme. Proof will not sign SIL 3. It will not pretend a named reviewer is a TÜV assessment.

Part 3 wants structural coverage that scales with SIL, including MC/DC at the top of many programmes. FLIP measures specification-level MC/DC. Code-level coverage on C still wants the qualified toolchain. That H1 lives on MC/DC for Go, not here. Proof generates inputs. It does not run them. Keep go test.

IEC 61511 is process-industry SIS. EN 50128 is railway software. ASPICE is a process-capability assessment. Proof does not assess those. ISO 26262 is the automotive child; the SDD artefact lives on ISO 26262. Medical software lives on IEC 62304. Aviation formal analysis lives on DO-333.

Jama still authors. The four jobs still live on that URL. The NASA SRS still lives on NPR 7150.2D.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What is a safety integrity level? SIL 1 through 4 is the cost ladder in IEC 61508. It is not a badge Proof prints. This page is the software shalls under that ladder.

What is SIL 3? What is SIL 4? Higher rungs recommend formal methods and heavier coverage. Kind2 still only sees the shalls you wrote. Keep the TÜV path.

What is ISO 26262? Automotive functional safety, derived from this parent. The SDD artefact lives on ISO 26262.

What is IEC 62304? Medical software. Different regulator. IEC 62304.

What is DO-333? Formal methods supplement to DO-178C. Different H1. DO-333.

What is IEC 61511? Process-industry safety instrumented systems. Proof does not do SIS. Keep that assessment.

What is ASPICE? A process-capability model. Proof does not assess your process. Keep the assessor.

What is a requirements traceability matrix, and how do I keep it true? Part 3 wants the links re-derived, not pasted. RTM.