IEC 61508 Annex-A mapping (positioning, not certification)¶
IEC 61508 is the international standard for functional safety of electrical/electronic/programmable electronic safety-related systems. It defines SIL levels 1–4 (Safety Integrity Levels, where SIL 4 is most stringent) and prescribes the development, verification, validation, and maintenance activities a project must perform to claim a given SIL.
Unlike MISRA-C, IEC 61508 is not a list of coding rules to map against. It is a process standard: V-model lifecycle, hazard analysis, requirements traceability, V&V plans, change-control. Its Annex A and Annex B contain "Tables A.x" that list techniques and measures recommended at each SIL — and that's where a static-analysis tool like plc-st-review fits in.
[!important]
plc-st-reviewis NOT a TÜV-qualified safety tool. This page positions where the engine can contribute to an IEC 61508 software lifecycle. Using it on a SIL-rated project requires the integrator to perform their own tool-qualification activities (Clause 7.4.4 of IEC 61508-3). See the TÜV qualification note below for what that means in practice.
What this page is — and is not¶
- It is a position statement: "these IEC 61508-3 Annex-A techniques are recommended at SIL 2–4, and these
plc-st-reviewchecks help satisfy them — but the integrator is on the hook for qualification, evidence, and process." - It is honest about the gap between contributing to and fulfilling a 61508 software lifecycle. A static analyzer is one input; the lifecycle is many.
- It is not a claim that running
plc-st-reviewmakes your code SIL 2 / SIL 3 / SIL 4 compliant. SIL claims attach to systems and processes, not tools. - It is not a TÜV/exida certification, a Tool Confidence Level (TCL) claim, or a substitute for a qualified safety-engineering process.
What TÜV qualification actually means¶
"TÜV" is short for Technischer Überwachungsverein — German for "Technical Inspection Association." Several private organisations operate under the TÜV brand (TÜV SÜD, TÜV NORD, TÜV Rheinland, TÜV Austria) and similar bodies exist elsewhere (exida in the US, Sira / CASS in the UK, DEKRA, DNV). They are independent third-party certification bodies that audit tools, products, and processes against safety standards including IEC 61508, IEC 61511, and ISO 26262.
IEC 61508-3 Clause 7.4.4 distinguishes three "Tool Classes":
- T1 — A tool whose output cannot directly or indirectly contribute to errors in the executable safety-related system. (Example: a documentation editor.) Low qualification burden.
- T2 — A tool whose output is used to verify that other artifacts are correct, but cannot directly insert errors into the executable. (A static analyzer like
plc-st-reviewis a T2 tool.) Failing a T2 check could mean a defect isn't caught at review time. Qualification requires showing the tool is reliable enough that this risk is acceptable. - T3 — A tool that can directly or indirectly insert errors into the executable (compilers, code generators, optimisers). Highest qualification burden.
For a T2 tool used on a SIL 3 / SIL 4 project, the integrator must produce tool-qualification evidence: typically (a) a structured test suite the tool passes on representative inputs, (b) defect-class documentation, (c) version-control & change-management records, (d) an analysis of known limitations. A TÜV-certified T2 tool ships with this evidence already assembled and audited by a notified body — the integrator inherits it. An unqualified tool can still be used, but the integrator must do the qualification work themselves.
plc-st-review is in the second bucket. The engine is deterministic (see the dedicated page), the source is auditable, and the test suite is public — all of which makes integrator qualification easier. But the formal TÜV certification process is months of audits, costs tens of thousands of euros, and would have to be re-run for every meaningful release. We have not done it.
What this means in practice:
- For SIL 1 and most SIL 2 projects, integrator qualification of a deterministic OSS static analyzer is typically straightforward.
- For SIL 3 and SIL 4 projects, a notified-body-qualified commercial tool (e.g. TÜV-certified versions of Itris / Polyspace / etc.) is often the expected default.
plc-st-reviewcan still be used in addition, but it should be treated as a secondary check, not as the qualification-relevant primary tool. - If your project has a specific TÜV qualification requirement, read your safety case first — the answer to "can I use this tool?" depends on what your safety case has agreed with your assessor, not on what any tool's documentation claims.
IEC 61508-3 Annex-A techniques plc-st-review helps satisfy¶
The references below are to IEC 61508-3 (2010) Annex A and B — the software-specific tables. The columns "SIL 1" through "SIL 4" use the standard's notation: HR = Highly Recommended, R = Recommended, --- = no specific recommendation, NR = Not Recommended. The fourth column lists the plc-st-review checks that contribute to satisfying that technique.
Table A.4 — Software design and development: detailed design (extract)¶
| Technique | SIL 1 | SIL 2 | SIL 3 | SIL 4 | Contributing plc-st-review checks |
|---|---|---|---|---|---|
| Defensive programming | R | R | HR | HR | INFINITE_LOOP, ARRAY_INDEX_OUT_OF_BOUNDS, DIVISION_BY_ZERO, UNINITIALIZED_VAR_USED, BOOL_COMPARISON, REAL_EQUALITY, ASSIGNMENT_IN_CONDITION |
| No dynamic objects / No dynamic variables | --- | R | HR | HR | (Not applicable — ST has no dynamic allocation; the engine doesn't need to check.) |
| Limited use of pointers | R | R | HR | HR | POINTER_ARITHMETIC, POINTER_COMPARED, ADDRESS_OF_CONSTANT |
| Limited use of recursion | R | R | HR | HR | RECURSIVE_CALL, INDIRECT_RECURSIVE_CALL |
| No unconditional jumps | R | R | HR | HR | FORBIDDEN_STATEMENT (gated on GOTO) |
| Limited use of interrupts | R | R | HR | HR | (Out of scope — ST cycle/task model is system-level, not statically inferable from source.) |
| Strongly typed programming language | HR | HR | HR | HR | (Inherent in ST; IMPLICIT_TYPE_CONVERSION flags the cases where the type discipline is weakened.) |
| Structured programming | R | HR | HR | HR | MULTIPLE_EXIT_POINTS, IF_WITHOUT_ELSE, STATE_UNHANDLED, UNREACHABLE_CODE, FORBIDDEN_STATEMENT |
| Use of trusted / verified software modules | R | HR | HR | HR | (Process-level; the engine's role is to flag drift via SIGNATURE_CHANGED, INHERITANCE_CHANGED, PRAGMA_CHANGED.) |
Table A.5 — Software design and development: software module testing and integration¶
| Technique | SIL 1 | SIL 2 | SIL 3 | SIL 4 | Contributing plc-st-review checks |
|---|---|---|---|---|---|
| Static analysis | R | HR | HR | HR | The entire engine — 80 categories spanning data-flow (UNINITIALIZED_VAR_USED), control-flow (UNREACHABLE_CODE, INFINITE_LOOP), interface (CALL_SITE_OUTDATED, SIGNATURE_CHANGED), team-policy (NAMING_CONVENTION, FORBIDDEN_SYMBOL), and industrial cybersecurity (the IEC 62443 set; see the IEC 62443 mapping page). |
| Boundary value analysis | R | R | HR | HR | ARRAY_INDEX_OUT_OF_BOUNDS, ARRAY_BOUNDS_CHANGED, LOOP_BOUNDS_REVERSED, LOOP_BOUNDS_CHANGED |
| Symbolic execution | --- | R | R | HR | (Out of scope — would require a model checker.) |
| Test case execution from cause–consequence diagrams | R | R | R | HR | (Out of scope — process-level.) |
Table A.7 — Verification of software safety requirements¶
| Technique | SIL 1 | SIL 2 | SIL 3 | SIL 4 | Contributing plc-st-review checks |
|---|---|---|---|---|---|
| Static analysis | R | HR | HR | HR | (See Table A.5 above.) |
| Walkthroughs / inspections | R | HR | HR | HR | The PR/MR review mode posts inline review comments anchored to the affected lines, which slots directly into a code-walkthrough workflow as automated input. |
| Formal proof | --- | R | R | HR | (Out of scope.) |
Annex B — additional measures relevant to PLC code¶
| Technique (Annex B reference) | Contributing plc-st-review checks |
|---|---|
| Limited use of global variables (B.4) | TOO_MANY_GLOBALS_USED, EXTERNAL_VAR_IN_FUNCTION, MULTI_WRITER_GLOBAL |
| Information hiding / encapsulation (B.10) | INPUT_VAR_WRITTEN, OUTPUT_VAR_READ_INTERNALLY |
| Modular approach (B.3) — module size and complexity bounds | COMPLEXITY_INCREASED, NESTING_INCREASED, LOC_SPIKE, TOO_MANY_PARAMETERS |
Suggested severity policy for SIL bands¶
If you are running plc-st-review on a SIL-rated project and want the severity gate to match your safety case, a reasonable starting point:
| Project SIL | Suggested fail_on_severity |
Rationale |
|---|---|---|
| SIL 1 | error |
Block the merge on real bugs; warnings and style remain advisory. |
| SIL 2 | error |
Same as SIL 1, plus consider promoting POINTER_ARITHMETIC, POINTER_COMPARED, RECURSIVE_CALL, INDIRECT_RECURSIVE_CALL to error via severity_overrides. |
| SIL 3 | warn |
Block on warnings too; the cost of a missed defect is high. Promote defensive-programming and structured-programming checks to error. |
| SIL 4 | warn |
Same as SIL 3, plus expect the safety case to require additional tooling beyond plc-st-review. |
plc-st-review is not the only tool you need to use; it is one input into a much larger safety-engineering process.
Limits of this mapping¶
- IEC 61508 talks about systems;
plc-st-reviewanalyses source code. The standard's Annex-A techniques are necessary but not sufficient — process activities (hazard analysis, requirements management, V&V planning, change control) live outside any code-analysis tool. - The engine has no model of the runtime task scheduler, no model of cycle-time semantics, no model of interrupt latency. PLCopen CP10 (multi-task writes), CP12 (write physical outputs once per cycle), CP16 (task-to-PROGRAM mapping) are explicitly out of scope and remain a manual / architectural concern.
MULTI_WRITER_GLOBALis the engine's best static approximation of the multi-writer hazard — it flags the static shape of the problem, but a real concurrency analysis needs the task table the engine doesn't see. - The defect classes the engine catches are documented per-check in the Checks reference and Check limitations pages. Integrator tool-qualification activities should test against those documented limits, not against assumed capabilities.
If you are starting a SIL-rated project that wants to use this tool¶
- Read the Deterministic by design page and confirm the no-LLM / reproducibility / air-gap properties match your safety case's traceability requirements.
- Read Check limitations — these are the engine's documented blind spots and the starting point for your tool-qualification evidence.
- Read Tuning severities and pin a
severity_overridespolicy matched to your SIL. - Pin a specific release of the tool (via the npm package or the Docker image tag), document the version, and treat version bumps as configuration changes subject to your change-control process.
- Treat this page as a positioning document, not as qualification evidence in your safety case. Independent tool qualification is the integrator's responsibility.
For everything beyond that, talk to your assessor.