Introduction
In 2009, a Toyota Camry accelerated uncontrollably on a California highway, killing four people. Investigations pointed, among other things, to software and pedal design flaws. The incident triggered one of the largest automotive recalls in history and pushed regulators, OEMs, and suppliers to confront an uncomfortable truth, electronic systems in vehicles can fail, and when they do, people die.
This is not hypothetical. Modern vehicles carry upwards of 150 Electronic Control Units running over 100 million lines of code. Every one of those ECUs, from the humble window lifter to the steering controller, has a failure mode. Functional safety is the engineering discipline that systematically identifies those failure modes, quantifies their risk, and puts in place design measures to ensure that when something goes wrong, the vehicle fails in a way that is predictable, controlled, and as safe as possible.
If you are building embedded systems for automotive, whether you are writing firmware, designing hardware, or architecting software, functional safety is not optional reading. It is the language your OEM customer speaks, and it governs every design decision from the choice of microcontroller to the structure of your interrupt handlers.
From IEC 61508 to ISO 26262: How the Standard Evolved
Functional safety as a formal discipline begins with IEC 61508, the international standard for the functional safety of electrical, electronic, and programmable electronic systems. Published by the IEC in 1998 and revised in 2010, it established the foundational concept of Safety Integrity Levels (SIL 1 through SIL 4) and introduced the idea of a systematic, lifecycle-based approach to safety.
IEC 61508 is a generic standard. It applies equally to a railway signalling system, an industrial process controller, and a medical ventilator. The automotive industry, with its unique combination of mass production, harsh operating environments, and software-intensive ECUs, needed something more specific.
That specificity arrived in 2011 with the first edition of ISO 26262, Road Vehicles: Functional Safety. Based directly on IEC 61508, ISO 26262 translates the general safety lifecycle into automotive-specific terminology, introduces the Automotive Safety Integrity Level (ASIL) classification system (replacing SIL), and covers the entire development lifecycle from concept through decommissioning. The second edition arrived in 2018, extending coverage to semiconductors (Part 11), motorcycles, and trucks.
ISO 26262 is now a de facto requirement for any ECU supplied to a major OEM globally. Understanding its structure is the first step to working within it.
The Safety Lifecycle: Engineering Safety, Not Assuming It
One of the most important ideas in ISO 26262 is that safety is not a property you test into a product at the end. It is an outcome of a deliberate, documented process that runs from the earliest concept phase through design, verification, and validation.
The standard defines a safety lifecycle that maps closely to the familiar V-model of embedded development, but adds a parallel safety track running alongside every engineering activity.
At the concept phase, the team performs a Hazard Analysis and Risk Assessment (HARA), the foundational activity that drives every safety requirement that follows. HARA asks three questions about every potential hazard:
- Severity (S): How badly can this hazard injure a person? Rated S0 (no injury) to S3 (life-threatening or fatal).
- Exposure (E): How frequently is the vehicle in an operating condition where this hazard could occur? Rated E0 (incredible) to E4 (high probability).
- Controllability (C): Can a typical driver react and prevent the hazard from causing harm? Rated C0 (fully controllable) to C3 (difficult or impossible to control).
These three parameters combine to produce an ASIL rating, from ASIL A (lowest safety requirement) through ASIL D (highest), or QM (Quality Managed), meaning no specific safety requirement beyond normal quality processes applies.
Consider two examples. A failure in the power window motor that causes the window to close unexpectedly might be rated S1 (minor injury possible), E4 (windows operated frequently), and C2 (driver can release quickly), resulting in ASIL A. A failure in the Electronic Power Steering that causes unintended steering input at highway speed might be S3, E4, C3, resulting in ASIL D, the most demanding classification.
The ASIL rating directly drives hardware and software requirements. ASIL D demands lockstep processor cores, hardware memory protection, systematic fault detection coverage targets above 99%, and rigorous independence between safety-critical and non-safety code. ASIL A demands significantly less.
FMEA and FMEDA: Finding the Failures Before the Field Does
Once ASIL ratings are established, the design team moves into failure analysis. Two methods are central to this.
FMEA (Failure Mode and Effects Analysis) is a bottom-up technique that systematically examines every component in the system, asks what failure modes it can exhibit, and traces the effect of each failure mode up through the system to the vehicle level. For an automotive ECU, this means going through every resistor, every communication line, every software module, and documenting: what fails, how it fails, what it causes, and what the detection mechanism is.
FMEDA (Failure Mode, Effects and Diagnostic Analysis) extends FMEA by adding quantitative failure rate data, typically sourced from IEC TR 62380 or SN 29500 component failure rate databases, and calculating diagnostic coverage. ISO 26262 specifies minimum targets for two key metrics:
- PMHF (Probabilistic Metric for random Hardware Failures): The rate at which random hardware failures can lead to a safety goal violation. For ASIL D, this must be below 10 FIT (Failures In Time, where 1 FIT = 1 failure per billion hours).
- SPFM / LFM (Single Point Fault Metric / Latent Fault Metric): Measures how well the design detects dangerous single-point and latent faults. ASIL D requires SPFM ≥ 99% and LFM ≥ 90%.
These numbers are not arbitrary. They represent a deliberate engineering target that forces hardware designers to add watchdogs, voltage monitors, CRC checks, redundant sensing, and self-test routines, not because they want to, but because the numbers demand it.
ASIL Decomposition: A Practical Design Tool
A concept that confuses many engineers new to ISO 26262 is ASIL decomposition. When a safety goal is rated ASIL D, it does not mean every single component in the system must independently be ASIL D; that would be prohibitively expensive.
Instead, the standard allows the ASIL D requirement to be decomposed across two independent channels, each designed to ASIL B. The key word is independent: the two channels must have no common cause failures, no shared silicon, and ideally no shared software developer. Together, they achieve a fault tolerance equivalent to a single ASIL D channel.
This principle shapes the hardware architecture of most high-ASIL ECUs. It is why you see dual-core lockstep processors for ASIL D functions running alongside a separate monitoring MCU. It is why ASIL D brake control systems route sensing and actuation through two physically separate paths. And it is why AUTOSAR mandates a strict separation between safety-relevant and non-safety software partitions.
Where ISO 26262 Ends and ISO 21434 Begins
Functional safety and cybersecurity are not the same problem, but they are deeply related. A vehicle that is cybersecure but not functionally safe can still kill someone through a hardware failure. A vehicle that is functionally safe but not secure can be attacked and turned into a weapon.
ISO 26262 governs accidental failures, such as random hardware faults and systematic design errors. ISO 21434, the automotive cybersecurity standard published in 2021, governs intentional attacks, such as threats that exploit vulnerabilities in software, communication interfaces, or update mechanisms.
In practice, both standards apply to almost every connected ECU. The concept phases of both standards are now often run in parallel: HARA for safety, TARA (Threat Analysis and Risk Assessment) for security. Embien's engineering teams are structured to address both simultaneously, recognising that modern ECU development cannot treat these as sequential concerns.
Why This Matters to Every Embedded Engineer on the Team
It is tempting to treat functional safety as the concern of a dedicated safety team, the people who write the Safety Plans and sign off the Safety Cases. That temptation is worth resisting.
Every firmware developer whose interrupt handler runs inside an ASIL B partition needs to understand coverage targets and why certain code constructs are banned under MISRA C. Every hardware engineer selecting a decoupling capacitor needs to understand that component failure rates feed into FMEDA calculations. Every test engineer writing test cases needs to understand the difference between structural coverage and safety coverage, and why achieving 100% branch coverage is a necessary but not sufficient condition for ASIL compliance.
Functional safety is a team sport. ISO 26262 is explicit that safety requires a shared safety culture across the organization, not a safety department that everyone else hands requirements over the wall to.
Conclusion
This article introduces the conceptual foundation. As we go deeper, we will encounter ASIL ratings in the context of every specific ECU we cover, from Adaptive Cruise Control (where camera and radar processing pipelines face ASIL B demands) to the Battery Junction Box (where contactor control failures carry ASIL D consequences).
We will also return to functional safety in the Technology Insights section when we cover AUTOSAR, where the Classic platform's BSW and the Adaptive platform's execution framework are both shaped by ISO 26262 requirements.
At Embien, functional safety is embedded into our development process, not bolted on at the end. Our engineering teams are structured around ISO 26262 compliance, with experience delivering ASIL-B and ASIL-D systems across powertrain, chassis, and body domains. If you are starting an ECU program and need a partner who speaks this language from day one, reach out to the Embien team to discuss your requirements.