IEC 61508 vs ISO 26262: What Automotive Engineers Need to Know

A supplier hands you a controller described as "IEC 61508 SIL 3 capable". Your vehicle safety goal is ASIL D. Can you accept it and move on?

No. The label alone is not enough. The evidence behind it may be genuinely useful and honestly described, but it describes what the supplier built and had assessed, not your vehicle. This article covers what carries across and what does not.

How the standards fit together

IEC 61508 is a generic functional safety standard for electrical, electronic and programmable electronic safety-related systems. ISO 26262 is its automotive adaptation, written for safety-related electrical and electronic systems in series production road vehicles. The introduction to every part of ISO 26262 says exactly that.

The lineage is real: a managed safety lifecycle, rigor that scales with risk, systematic failures separated from random hardware failures, independent confirmation, and traceable evidence. What the automotive context changes is the calibration of the risk and the level at which the argument has to be made.

The lifecycle does not end at development.

A quick comparison

Why a SIL does not convert into an ASIL

A lookup table in which SIL 2 becomes ASIL C looks efficient in a presentation and does not survive an engineering review. But the usual explanation, that the two standards use completely different risk models, is not right either.

The parameter sets are close cousins. IEC 61508-5 builds its Annex E risk graph from four inputs: how bad the consequence is (C), how often and how long anyone is in the hazardous zone (F), whether the event can be avoided (P), and how likely it is to happen unprotected (W). ISO 26262 rates a hazardous event on severity (S), exposure (E) and controllability (C), the last judged for the persons involved, meaning the driver, the passengers and people around the vehicle. The first three line up almost one for one.

What blocks conversion is calibration. Annex E is informative, one method among several, and each user calibrates it against their own tolerable risk before it yields a SIL. ISO 26262-3 Table 1 is normative and already calibrated, so every road vehicle project reads the same cells. The fourth parameter has no counterpart at all: ISO 26262 rates the event assuming the malfunctioning behaviour occurs, and handles other risk reduction as external measures.

Two scales calibrated against different tolerable risk cannot be mapped onto each other, however alike their inputs look.

The parameters line up. The calibration behind them does not.

Where the integrity level actually lives

Behind the conversion question sits a more common misunderstanding: that an integrity level is a property you can buy.

In ISO 26262 an ASIL is determined for a hazardous event, then assigned to the safety goal derived from it. A safety goal is a top-level safety requirement for the item, stated at vehicle level and in functional terms. Every safety goal carries an ASIL. It also fixes, where they apply, the safe state, the fault tolerant time interval, and the physical characteristic at stake. From there it is allocated downward through functional, technical, and hardware and software safety requirements, each inheriting the ASIL of the goal it serves.

Read in that direction, a component's position is clear. It receives allocated requirements. It does not carry an ASIL of its own, and it cannot be sold with one.

IEC 61508 makes the same point and has a term for it. A SIL applies to a safety function. What an element carries is a systematic capability, SC 1 to SC 4: a rating of how far you can trust that its design and development process kept systematic faults down to the level a given SIL needs, provided it is used the way its safety manual says. So "SIL 3 capable" means this: assessed at systematic capability 3, with failure data stated for a defined mission profile, valid only inside the conditions that safety manual records.

The level is allocated downward. A component receives requirements.

The level can also move

The opposite trap is just as expensive. A component with a quality managed pedigree, or with none at all, is not disqualified from an ASIL D item.

ISO 26262-9 allows a requirement to be decomposed and its ASIL redistributed across sufficiently independent elements. One of the permitted schemes pairs an ASIL D(D) requirement with a QM(D) one, which is the case in point. IEC 61508 reaches a comparable place through architectural redundancy. So a quality managed part can serve an ASIL D safety goal when the architecture does the work: redundancy, an independent monitor, or diagnostics with adequate coverage. The conditions are strict: independence has to be demonstrated rather than assumed, dependent failures analysed, and the bracketed ASIL records that the goal itself was never downgraded.

A certificate, and the absence of one, are both weaker signals than the architecture.

Safe state and timing exist on both sides

The safe state and the timing budget are often called the automotive addition. They are not. IEC 61508 defines a safe state, and a process safety time: how long you have, once a failure happens, to finish reacting before it turns into a hazardous event. Where a design takes credit for its diagnostics, detection and reaction have to fit inside that budget. This is the concept an automotive engineer knows as the fault tolerant time interval.

What ISO 26262 adds is explicitness and decomposition. Both are named attributes of the safety goal, and the budget is broken down further into a fault handling time interval and an emergency operation tolerance time interval. So the vocabulary transfers and the timing evidence is often a useful input. The values do not transfer: both are re-derived for your hazardous event and your vehicle item.

Putting the evidence to work

Treat cross-standard reuse as an evidence-mapping exercise, and run it through a mechanism ISO 26262 already provides rather than inventing one: safety element out of context (Part 10), qualification of software components or evaluation of hardware elements (Part 8, Clauses 12 and 13), or a proven in use argument (Part 8, Clause 14).

Around whichever mechanism fits, the work runs in five steps, and the third is where projects fail: map evidence to specific ISO 26262 objectives, never document title to document title.

An electric power steering team taking a systematic capability 3 controller into an ASIL D item still has to ask whether the assumed temperatures and mission profile hold in the target vehicle, whether the element's safe state suits steering at speed, and whether its diagnostics complete inside the allocated fault tolerant time interval. The certificate settles none of them.

Scope the evidence, map it, close the gaps, validate in the vehicle.

Where teams get into trouble

1. Publishing a SIL to ASIL conversion table. The parameters resemble each other. The calibrations do not, and the calibration sets the level.
2. Reading an integrity level as a property of a part. A component carries a systematic capability, failure data and a safety manual.
3. Treating a missing certificate as disqualifying. Decomposition and architecture can carry integrity that no single part provides.
4. Stopping at component compliance. Safety is achieved by the integrated item, not by collecting certified parts.

The question for your next design review

When a certificate or an assessment report appears, bring the discussion back to one question:

What does this evidence prove for our exact vehicle item, configuration and assumptions of use?

That turns a certificate from a marketing label into safety evidence, and it exposes missing assumptions before they become a gap in the safety case.

This article stops at the conclusions. How a SIL is determined and calibrated, how probability targets and architectural routes constrain what a design may claim, and a worked ASIL comparison, are in the IEC 61508 concept.

Abbreviations

• ASIL: Automotive Safety Integrity Level. Determined for a hazardous event and assigned to its safety goal, as ASIL A to ASIL D.
• FTTI: Fault Tolerant Time Interval.
• QM: Quality Management, the classification used when no ASIL is required.
• SC: Systematic Capability, SC 1 to SC 4. A property of an element in IEC 61508.
• SIL: Safety Integrity Level, SIL 1 to SIL 4. A property of a safety function, not of a component.