ISO 26262 · IEC 61508 · Confirmation measures
Safety concepts almost never arrive before the architecture. They arrive afterwards, and have to be made to fit something that already exists.
We know that situation from the inside: an ASIL decomposition that has to survive an architecture nobody designed for it, a supplier component whose safety manual answers a different question, a deadline that assumed the safety case was a document rather than an argument. It is the normal case. It is also the expensive one — and most of what follows is about why.
The position we work from
Safety cannot be retrofitted
Safety is a property of the system, not of the documents written about it. You cannot inspect it in at the end, and you cannot write it in either.
Freedom from interference is an architectural property. If the architecture does not provide separation, no amount of documentation creates it — the safety case simply describes a system that does not exist. Traceability is the same: it is cheap when requirements were written to be traceable and ruinous when it has to be reconstructed eighteen months later by someone reading commit messages. A test strategy that was designed alongside the requirements produces evidence as a by-product. One invented after integration produces a spreadsheet.
The pattern we have seen repeatedly, on both sides of the table, is that teams who are simply good at engineering pass safety reviews almost incidentally. Their architecture is modular because that made it easier to work on. They know what went into a build because they needed to. The safety artefacts describe what they actually did. Teams who are weak at engineering try to close the same distance with documents — and each document is a promise that someone will later have to keep.
Which is why we sometimes give an answer nobody asked for. If you bring us in for a safety concept and the underlying engineering is the actual problem, we will say so — early, and before you have paid for a concept that cannot hold. It is a larger conversation than the one you started, and it is cheaper than the alternative. A hazard found in the concept phase costs an afternoon of argument. The same hazard found in validation costs a redesign.
The process side of the same argument: Automotive SPICE →
Confirmation measures
The work that needs someone from outside
ISO 26262 asks for confirmation measures carried out with a degree of independence that rises with the ASIL. An external practice satisfies that structurally — there is no reporting line to the project, no shared budget, and no career reason to soften a finding.
Confirmation reviews
Work product level
Review of the safety plan, the HARA, the safety concepts and the safety case for compliance with the standard — reported so the team can act on it, not just file it.
Safety audit
Process level
Whether the safety process was actually implemented in the project, as opposed to described in a handbook. Usually the point at which the gap between the two becomes visible.
Safety assessment
Item level
Judgement on whether the item achieves functional safety — the argument as a whole, not a checklist against clauses. With a recommendation you can defend to a customer.
What we do not do: certification
Issuing a certificate requires accreditation with a national body, which a one-person practice cannot sensibly hold. So we don’t claim to. What we do is get you to the point where a certification body finds nothing surprising — and tell you plainly, early, which of your questions genuinely needs one and which does not. In our experience a fair number do not.
Building the argument
Before anyone confirms anything
Most of the work happens well before a confirmation measure. A safety case is an argument, and arguments are easier to build than to repair.
Safety plan and concept
HARA, functional and technical safety concepts, ASIL decomposition that the architecture can actually carry — and a plan sized to the project rather than to the standard.
Work products that hold up
Requirements, architecture, verification and the traceability between them, produced as part of engineering rather than reconstructed afterwards for the reviewer.
Suppliers and SEooC
DIA, assumptions of use, qualification of software components — the places where a safety argument most often turns out to rest on something nobody checked.
Beyond road vehicles
IEC 61508 for industrial E/E
ISO 26262 is a sector adaptation of IEC 61508, and teams moving between the two often carry across habits that no longer apply. We work in both: SIL determination, the safety lifecycle, supplier qualification, and the safety case for industrial electrical and electronic systems — including for organisations whose automotive processes now have to serve a non-automotive product line.
Where safety meets security: Safety & Security Co-Engineering →