A Practitioner’s Guide to ISO 26262 Hardware Safety

Posted on by alex.novickis@gmail.com

A
Practitioner’s Guide to ISO 26262 Hardware Safety

This is a high-level summary. The full paper — with five worked
FMEDA examples, a complete safety-mechanism catalogue, and the
cross-standard mapping — is on Zenodo.

What it covers

ISO 26262 Part 5 is the part that most hardware engineers actually
have to live with day-to-day. It defines what a quantitative hardware
safety case looks like — and what auditors expect to see by the time the
silicon ships.

The paper is organised around the questions that come up in real
projects:

  1. Where do I start? Safety goals, item definition,
    and the safety lifecycle in the order you actually encounter them.
  2. Which architecture do I need? The four redundancy
    topologies (1oo1, 1oo1D, 1oo2, 1oo2D), with the trade-offs that
    determine which one your ASIL forces on you.
  3. How do I run an FMEDA without drowning in
    spreadsheets?     Five worked examples — MCU, sensor, power supply,
    FPGA, dual-channel system — each with the FMEDA table you’d actually
    submit.
  4. What diagnostic coverage can I claim? A catalogue
    of safety mechanisms with referenced DC values, separated honestly into
    “what the standard suggests” and “what’s defensible from data.”
  5. Which failure-rate database should I use? SN 29500,
    IEC 62380, FIDES, MIL-HDBK-217F — compared quantitatively on the same
    parts so you can see why the choice matters.
  6. How does this map to my other standard? Cross-walks
    to IEC 61508, DO-254, EN 50129, IEC 62304 — same methodology, different
    vocabulary.

Why this paper exists

After enough audits, the same gaps appear:

  • Diagnostic coverage values pulled from thin air.
    “We’re claiming 90% DC on this mechanism” is not justified. The
    justification is either a published reference, a fault-injection
    campaign, or a formal proof. Stating the number without the source is a
    finding waiting to happen.
  • FMEDA tables that don’t trace. An auditor will pick
    three failure modes at random and ask you to reproduce the metric
    contribution. If your spreadsheet has hidden adjustments, you fail the
    trace.
  • Dependent-failure analysis treated as a checklist.
    Common-cause failures across redundant channels, shared power supplies,
    shared clocks, shared reset paths — these need their own analysis.
    They’re where most lockstep-based designs take damage in audit.
  • Tool qualification missing. Every tool that affects
    the safety output (synthesis, P&R, fault simulator, formal tool)
    needs qualification evidence or a documented justification for why it
    doesn’t.

The paper writes down the patterns that close these gaps
consistently.

Worked examples

The five worked examples in §9 are the heart of it:

  • Single-MCU controller (ASIL-B) — minimum viable
    architecture, BIST, watchdog
  • Sensor with diagnostic stream (ASIL-B) —
    distinguishing safe vs. residual faults
  • Power supply with monitoring (ASIL-C) — classic
    1oo1D
  • FPGA with TMR (ASIL-D) — triple modular redundancy
    with majority voting; common-cause exposure
  • Dual-channel cross-checking system (ASIL-D) — the
    case where divergence on its own isn’t enough; the system must
    transition to a defined safe state, and you need to show the assessor
    exactly when

Each example includes the FMEDA spreadsheet, the safety-mechanism
choices, the FIT calculation, and the conclusions an assessor can
verify.

The paper has a companion piece — Probabilistic Fault
Metrics and Signal Jitter — A Unified Mathematical Framework —
which connects the FMEDA mathematics here to the jitter-budget
mathematics used in high-speed signal integrity. Same equations,
different vocabulary.

It also pairs naturally with the TLA+ for ISO 26262
article on this site, which covers the formal-methods angle that ISO
26262 Part 6 Table 7 recommends but most teams don’t actually do.

Get the full paper

Hardware
Safety Methodology for Electronic Systems: A Practitioner’s
Guide — Zenodo, 2026. DOI: 10.5281/zenodo.19349162. Open
access, archival, citation-ready.

Need help applying this methodology to your safety case — or want
a second opinion on an existing FMEDA? Get
in touch.

#FunctionalSafety #ISO26262 #IEC61508 #FMEDA #ASIL #HardwareSafety
#SafetyCritical #Automotive