ISO 26262 (Automotive Functional Safety)
1. Overview
A. Definition
ISO 26262 is an international functional safety standard whose goal is to reduce the risk arising from the malfunctioning behavior of automotive electrical/electronic (E/E) systems to an acceptable level. Derived by tailoring the general safety standard IEC 61508 to the automotive domain, it rests on the principle that "safety must be demonstrated with evidence across the entire lifecycle of design, development, production, and operation."
The background to ISO 26262 lies in the "computerization" of the automobile. As braking, steering, and propulsion—once realized mechanically or hydraulically—shifted to electronic control units (ECUs) and software, a single sensor error, a single bit flip, or a single software defect could now escalate directly into a loss-of-life accident such as acceleration or braking failure. Whereas traditional quality management focused on "lowering the failure rate," functional safety goes a step further and asks, "is the system designed so that even when a failure occurs it does not go into a hazardous state (fail-safe / fail-operational)?" After the first edition in 2011 centered on passenger cars (gross weight up to 3.5 t), the second edition in 2018—as the E/E share exploded with electrification and autonomous driving—broadened the scope to trucks, buses, and motorcycles and added guidance for semiconductors (Part 11) and motorcycles (Part 12).
Therefore, the starting point for understanding ISO 26262 is the perspective that 'risk = severity × exposure frequency × controllability'. Because no failure can ever be reduced to zero, a risk-proportionate approach pervades the whole standard: more rigorous development and verification for high-risk functions, and ordinary quality management (QM) for low-risk functions. The yardstick of this proportionality is precisely the ASIL explained below.
ISO 26262 consists of 12 parts in total. With Part 1 (vocabulary) and Part 2 (safety management) as the backbone, Parts 3 (concept phase), 4 (system), 5 (hardware), and 6 (software) cover the development lifecycle, supported by Parts 7 (production/operation), 8 (supporting processes), 9 (ASIL-oriented analysis), and 10 (guidelines). Part 11, added in the 2018 second edition, addresses application guidance for semiconductors, and Part 12 addresses adaptation for motorcycles. The fact that the standard is thus an all-encompassing system spanning 'management–concept–development–operation–support' implies that functional safety is not a specific technology but a management task demanding processes, culture, and governance across the entire organization.
B. Distinguishing functional safety from other safety concepts
To use the term functional safety precisely, one must clearly draw the boundary with adjacent concepts. What ISO 26262 addresses is strictly the harm arising from the malfunctioning behavior of E/E systems (systematic failure + random hardware failure). For example, a brake ECU ignoring a braking command due to a software bug, or a memory bit flipped by radiation producing an erroneous torque. The very term 'functional safety' implies this scope—it means controlling the risk that arises when a function 'cannot operate functionally correctly' by means of another function (a safety mechanism) that monitors and compensates for it.
By contrast, cases where the system 'operates normally as designed' yet risk arises because of the performance limitations or misperception of the intended function itself fall outside the scope of ISO 26262, and these are addressed by ISO 21448 (SOTIF, Safety Of The Intended Functionality), formally published in 2022. A situation where an autonomous-driving camera fails to recognize a pedestrian in backlight is not a 'failure' but 'insufficient performance,' hence the domain of SOTIF. Non-functional harms such as electric shock or ignition are covered by electrical safety specifications, and the behavioral safety of the whole vehicle is complemented by UL 4600 (safety case for autonomous vehicles) and the like. In an exam answer, the key is to clearly describe the division of roles: "ISO 26262 = guarding against failures, SOTIF = guarding against performance limitations, the two are mutually complementary."
The reason this distinction matters in practice is that the 'mode of proof' for safety activities is fundamentally different. Because the failures of ISO 26262 have identifiable causes and can be quantified by probability, one can trace failure paths with FTA·FMEA and numerically express residual risk with hardware metrics. By contrast, the performance limitations that SOTIF addresses cannot be fully enumerated as 'when and in what situation misperception will occur,' and so depend on driving-scenario coverage and statistical argumentation. In other words, if the former is 'deterministic evidence,' the latter is closer to 'probabilistic·scenario-based argumentation.' From an information-management professional engineer's perspective, seeing through the difference in verification philosophy between the two approaches becomes the dividing line for a high score.
Moreover, functional safety distinguishes systematic failure from random failure and handles each by different means. A systematic failure, like a defect in requirements, design, or implementation, is a failure that inevitably reproduces whenever the conditions are met, and is 'prevented' by tightening the process (reviews, static analysis, test coverage). A random failure is a hardware failure that occurs probabilistically, like semiconductor aging or radiation, and is tamed by 'detection·response' through safety mechanisms and by metric management. This dichotomy is the backbone that determines how the activities of the whole standard are allocated.
2. ASIL — Risk-Level Determination and Overall Structure
Every activity of ISO 26262 starts from HARA (Hazard Analysis and Risk Assessment). It identifies the hazardous events that could arise when each function of the vehicle malfunctions and quantifies them along three axes. First, Severity (S0–S3)—the degree of injury to occupants·pedestrians when an accident occurs. Second, Exposure (E0–E4)—the probability·frequency with which the vehicle will be in that hazardous situation. Third, Controllability (C0–C3)—the degree to which the driver can avoid·control that situation. The combination of these three values determines the ASIL (Automotive Safety Integrity Level).
graph TD
START["Define vehicle function"] --> HARA["HARA: identify hazardous event"]
HARA --> S["Severity S0~S3"]
HARA --> E["Exposure E0~E4"]
HARA --> C["Controllability C0~C3"]
S --> COMB["Evaluate risk combination"]
E --> COMB
C --> COMB
COMB --> ASIL["ASIL level QM/A/B/C/D"]
ASIL --> SG["Derive Safety Goal"]
SG --> FSR["Functional safety req. FSR"]
FSR --> TSR["Technical safety req. TSR"]
As the structure diagram above shows, ASIL is not an end in itself but an input that decides 'how rigorously to develop·verify'. ASIL is divided into five levels—QM (Quality Management, ordinary quality management suffices) and A·B·C·D—with D being the most rigorous. Functions that are fatal when they malfunction, such as braking·steering, are usually classified as ASIL C/D, while low-risk functions such as power mirrors·cabin lights are classified as QM/A. As the level rises, the required intensity of analysis·testing·documentation·margin design grows non-linearly, so over- or under-estimating the ASIL at the HARA stage leads directly to excessive cost or insufficient safety, respectively. For exactly this reason, HARA must be performed through multidisciplinary consensus and recorded rationale, not the subjectivity of a few experts.
| Item | Content | Relation to ASIL |
|---|---|---|
| Severity (S) | S0 (no injury) ~ S3 (life-threatening·fatal) | Higher → ASIL ↑ |
| Exposure (E) | E0 (almost none) ~ E4 (constant) | Higher → ASIL ↑ |
| Controllability (C) | C0 (easy to control) ~ C3 (uncontrollable) | Higher → ASIL ↑ |
| ASIL | QM < A < B < C < D | Determines development·verification rigor |
The table organizes the directionality of the three factors, but the actual determination is not simple addition; it follows the risk matrix provided by the standard. For example, unintended full braking during high-speed driving is ASIL D because severity·exposure·uncontrollability are all high, whereas a rear-camera blackout during low-speed parking is assessed relatively lower. There is a deep reason for treating the three factors in multiplicative form. No matter how severe the consequence, if it almost never occurs (low E) or the driver can easily avoid it (low C), the actual risk is lowered. For instance, a 'defect that occurs only at 200 km/h' has low exposure and so is downgraded, and a 'warning-lamp error to which the driver can immediately respond by decelerating' has high controllability and so is downgraded. Thus ASIL is a measure of 'real risk' that integrates not only the magnitude of the consequence but also the conditions under which that consequence materializes, and this is precisely the key that separates functional safety grading from simple failure-severity classification. In an answer, merely listing S·E·C while omitting 'why they are bound multiplicatively' is judged as insufficient understanding of the principle.
Another important technique is ASIL decomposition. It is a technique that divides a single ASIL D requirement into two paths that operate independently (e.g., ASIL B + ASIL B(D)), lowering the development burden of each component; however, it holds only if independence (freedom from interference) is demonstrated so that the two paths do not collapse together through common-cause failure (CCF). If independence breaks (e.g., the two paths share the same power·clock·memory), the decomposition becomes invalid and the original ASIL D burden returns as is, so one must note that decomposition, before being a cost-saving means, entails another analysis task called 'proof of independence.'
3. Safety Lifecycle and the V-Model — Components and Procedure
The second axis of ISO 26262 is the safety lifecycle. This weaves safety activities in time order from the concept phase → product development (system·hardware·software) → production·operation → decommissioning, and the development phase unfolds as the typical V-model. On the left descending arm, requirements are decomposed from top to bottom (safety goal → FSR → TSR → HW/SW design), and on the right ascending arm, verification is performed at the unit·integration·system levels, demonstrating through traceability that each stage's work products satisfy the higher-level requirements.
flowchart LR
subgraph LEFT["Design (requirement decomposition)"]
direction TB
L1["Safety Goal"] --> L2["Functional safety req. (FSR)"]
L2 --> L3["Technical safety req. (TSR)"]
L3 --> L4["HW/SW safety req."]
L4 --> IMPL["Implementation (design·coding)"]
end
subgraph RIGHT["Verification (integration·validation)"]
direction TB
R4["Unit verification"] --> R3["HW/SW integration"]
R3 --> R2["System integration"]
R2 --> R1["Safety Validation"]
end
IMPL --> R4
L4 -. traceability .-> R4
L3 -. traceability .-> R3
L2 -. traceability .-> R2
L1 -. traceability .-> R1
The reason the V-model became the de facto standard development model of ISO 26262 lies in the 'symmetry of requirement and verification.' Each time a higher-level safety requirement is decomposed one step on the left, the corresponding stage on the right is meshed like a mirror to verify that the requirement has been satisfied. This symmetric structure naturally enforces the closed-loop principle that "every safety requirement must be closed by at least one verification activity," and it makes that closed loop visible through the traceability matrix. If a requirement is left without verification or a verification floats without a requirement, it is immediately revealed in the traceability check, so omitted safety activities can be caught early.
Looking at the detailed components by stage: In the concept phase, the item definition draws the boundary of the target system, HARA fixes the ASIL and safety goals, and these are then concretized into implementation-independent Functional Safety Requirements (FSR). In the system phase, the FSR are subdivided into Technical Safety Requirements (TSR) that can be allocated to hardware·software, and the safety architecture (monitoring·redundancy·safe-state transition) is designed. An important concept here is the safe state and the FTTI (Fault Tolerant Time Interval). It is a timing constraint that the system must transition to a safe state (e.g., torque cutoff, warn-then-decelerate) within the time from the moment a failure occurs until the hazard materializes, directly tied to the determinism·deadline concepts of [[rtos]]. The FTTI is further split into the sum of the 'fault detection time' and the 'fault reaction time,' and to guarantee the upper bound of these two times the diagnostic period and reaction path must satisfy real-time requirements. Thus safety architecture design cannot be separated from real-time scheduling design, and determining the period of the watchdog·monitoring core by working backward from the FTTI becomes the crux.
The production·operation phase is also part of the safety lifecycle. Safety is not guaranteed just because development is finished; whether the safety characteristics are reproduced in the production process (process control), and whether failures are diagnosed·reported during operation and fed back through recalls·field response, are all within the standard's concern. In other words, ISO 26262 demands, beyond the 'safety of design,' the 'maintenance of safety across the entire lifecycle,' and this is the point that distinguishes it from traditional certification that ends with a one-time test pass.
In the hardware phase, random hardware failures are quantitatively evaluated. There are three core metrics. SPFM (Single Point Fault Metric) shows how well safety mechanisms catch single-point faults, LFM (Latent Fault Metric) shows how well latent faults that remain hidden are diagnosed, and PMHF (Probabilistic Metric for random Hardware Failures) expresses the hourly hazardous-failure probability (FIT, failures per billion hours). The target values presented by the standard become steeper as the ASIL rises.
| Metric | ASIL B | ASIL C | ASIL D |
|---|---|---|---|
| SPFM | ≥ 90% | ≥ 97% | ≥ 99% |
| LFM | ≥ 60% | ≥ 80% | ≥ 90% |
| PMHF | < 100 FIT | < 100 FIT | < 10 FIT |
Rendered in prose, what these figures mean is as follows. ASIL D's SPFM of 99% means "safety mechanisms must detect·respond to 99% of single-point faults," and PMHF of 10 FIT demands an extremely low probability that "hazardous random failures must be fewer than 10 per billion hours (about 114,000 years of continuous driving)." To achieve this, safety mechanisms such as ECC memory, lockstep dual cores, watchdogs, and periodic built-in self-test (BIST) must be baked into the architecture.
The key here is the concept of 'diagnostic coverage'. No matter how low a component's failure rate, if the failure cannot be detected it is counted as risk in the safety metrics as is; conversely, even if the failure rate is somewhat high, if the safety mechanism detects a high proportion of failures and transitions to a safe state, the residual risk is lowered. In other words, the essence of hardware safety design is not 'eliminating failures' but 'detecting·isolating failures in time'. For this reason, an ASIL D system overlays lockstep that compares computation results along two paths, ECC that corrects memory errors, and BIST that periodically checks logic, structurally blocking the path by which a single fault propagates to the output without detection.
In the software phase, coding rules such as MISRA C, static analysis, requirement-based testing, and structural coverage (ASIL D requires MC/DC) are applied, and these mesh with the FMEA·FTA techniques of [[embedded-software-test]]·[[software-safety-analysis]] to eliminate systematic failures. Since software does not 'wear out' randomly, it is decisively different from hardware in that not a failure-rate figure but the rigor of the development process itself becomes the safety evidence. Thus the standard requires, in a graded manner, stronger design principles (modularity·prohibition of tight coupling·deterministic execution), more rigorous verification techniques (boundary values·equivalence partitioning·fault injection), and higher coverage targets at the 'highly recommended' level the higher the ASIL. It must also maintain bidirectional traceability among requirements·design·code·test, leaving complete evidence of which safety requirement is implemented in which code and verified by which test.
4. Comparison — Relationships Among Functional Safety Standards and Application Cases
ISO 26262 does not exist alone but sits within a hierarchy of safety standards. Its parent, IEC 61508, is a general cross-industry functional safety standard that divides the safety integrity level into SIL 1–4, and ISO 26262's ASIL is a reinterpretation of this tailored to the automotive domain. The reason the difference arises lies in the context of application. For factory equipment (IEC 61508), a 'stop (fail-safe)' upon failure is usually safe, but for a high-speed vehicle a sudden total stop can be dangerous, so fail-operational (maintaining some functions) design is required. This difference in practical implication separates the architectural choices of the two standards.
| Standard | Target | Grading scheme | Core concern |
|---|---|---|---|
| IEC 61508 | All industry (general) | SIL 1~4 | General functional-safety parent |
| ISO 26262 | Road-vehicle E/E | ASIL A~D(+QM) | Guarding against E/E failure |
| ISO 21448 (SOTIF) | Intended-function performance limits | No grade | Misperception·underperformance |
| DO-178C | Avionics SW | DAL A~E | Avionics software |
Also, comparing with the avionics software standard DO-178C (DAL A–E) reveals a common backbone of grading·V-model·traceability. Both standards require 'more rigorous verification the higher the safety integrity,' but aviation presumes examination by a certification authority (FAA/EASA), whereas automotive relies relatively more on manufacturer self-declaration·audit, so the burden of self-demonstration of process evidence is large. Pointing out in an answer that even the same functional safety is operated differently in practice when the per-industry certification ecosystem differs adds depth to the comparison.
Understanding deepens when we look at concrete application cases. Electric Power Steering (EPS), where loss of steering assist is fatal, is usually developed at ASIL D, placing lockstep cores and multiple sensors in the motor controller to guarantee the safe-state transition within the FTTI. A Battery Management System (BMS), which must prevent overcharge·thermal runaway, designs cell voltage·temperature monitoring and contactor cutoff at ASIL C/D. Conversely, an infotainment display is usually QM. Another concept important in practice is SEooC (Safety Element out of Context), a method of reusing semiconductor·software components (e.g., an automotive MCU) developed under generic assumptions without presuming a specific vehicle, by checking only whether those assumptions hold upon integration into the vehicle. This is how an ecosystem is formed in which semiconductor vendors supply ASIL grades 'pre-secured.'
Looking at how this ecosystem actually works, an automotive MCU supplier embeds safety mechanisms such as lockstep cores·ECC·BIST into the chip and provides, together with it, a safety manual that specifies 'the assumptions and usage conditions the vehicle must observe.' The OEM·component (Tier-1) suppliers need only check whether those assumptions hold in their own system, so they can satisfy the ASIL requirements without repeating the vast safety analysis at the semiconductor level. In this way ISO 26262 is significant in that, beyond the development norm of a single organization, it has institutionalized a DIA (Development Interface Agreement)-based collaboration model in which the entire supply chain divides and hands off safety evidence.
5. Advanced — Expansion of Functional Safety in the Autonomous-Driving Era and Latest Trends
Recently the landscape of functional safety has shifted rapidly toward autonomous driving and the software-defined vehicle (SDV). The biggest change is the recognition that autonomous driving cannot be handled by ISO 26262 (failure safety) alone. A large share of autonomous-driving accidents occur not because a component 'failed' but because the perception·decision algorithm 'operated normally within its designed limits' yet misjudged an exceptional situation. To fill this gap, ISO 21448 (SOTIF) was published as a formal standard in 2022, presenting an approach that divides the risk·safety regions into four quadrants of known/unknown and shrinks the unknown-risk region through verification·driving data. Furthermore, UL 4600, which addresses the full safety case of AI-based autonomous driving, and ISO/PAS 8800 (automotive AI safety), published in 2024, have appeared, multilayering the standards system.
SOTIF's four-quadrant approach is especially worth savoring. Dividing the regions along the two axes of safe/hazardous and known/unknown, the goal of development becomes to eliminate 'known hazards (Area 2)' by design and to pull 'unknown hazards (Area 3)' into the 'known' region through scenario discovery·driving accumulation and then eliminate them again. The problem is that Area 3 can never be fully emptied, so a statistical judgment of 'how much verification is enough to declare sufficiently safe (validation target)' intervenes. For this reason autonomous-driving safety demands hundreds of millions of km of real-driving·simulation data, imposing a fundamentally different proof burden from failure-centric ISO 26262.
The second trend is the convergence of security and safety. In connected cars a cyberattack becomes a safety threat, so the cybersecurity standard ISO/SAE 21434 and functional safety must be designed together. For example, when control software is updated over the air (OTA), security and safety requirements are cross-verified so that tampered firmware cannot impair ASIL D functions. Traditionally safety assumed 'accidental failure (random/systematic)' and security assumed 'malicious attack,' using different threat models, but in connected·autonomous environments attacks directly target safety goals, so the two threat models must be integrated into a single analysis. As the UN regulation UNECE WP.29 R155/R156 mandates a Cybersecurity Management System (CSMS) and a Software Update Management System (SUMS) as type-approval requirements, this convergence has become not a choice but a matter of regulatory compliance. The third is the shift to a centralized E/E architecture. As functions once distributed across dozens of ECUs are consolidated into a few high-performance domain·zonal controllers, ASIL D functions and QM functions now coexist on a single piece of hardware. Here, design that guarantees freedom from interference among mixed-criticality via hypervisors·partitioning has emerged as a core challenge, directly tied to the spatial·temporal partitioning concept of [[rtos]].
The benefits consolidation brings are clear. Wiring·connectors are reduced, lowering weight·cost, and as a software-defined vehicle functions can be continuously improved via OTA. From a safety standpoint, however, it throws up a new challenge called 'proof of isolation.' Resources must be partitioned temporally·spatially so that a runaway of a low-criticality application does not encroach on the CPU·memory·network bandwidth of high-criticality control, and it must be demonstrated that this isolation does not collapse even under fault conditions. For this reason foundational technologies such as the AUTOSAR Adaptive platform, safety-certified hypervisors, and deterministic Ethernet (TSN) are emerging as essential elements of functional-safety architecture. Likely exam directions include a convergence-type topic, "explain the integrated safety process of ISO 26262 and SOTIF·21434 with an autonomous-driving case," or an architecture-type topic, "discuss a design approach that guarantees mixed-criticality isolation in a centralized E/E architecture."
6. Considerations and Implications
Application strategy — ASIL-oriented design: Early in the project, HARA should fix the per-function ASIL and allocate the intensity of architecture·process·verification in proportion to that level. In particular, when distributing a high-level requirement across low-level multiple paths via ASIL decomposition, independence (freedom from interference) and exclusion of common-cause failure must always be left as evidence for the decomposition to be valid. Adjusting the level too late causes redesign cost to explode, so accurate ASIL determination at the concept phase governs the total cost.
Trade-off — safety vs. cost·performance·schedule: ASIL D requirements entail lockstep·redundancy·extensive coverage testing, greatly increasing BOM cost and development time. Conversely, SEooC·component reuse·ASIL decomposition reduce cost but leave the burden of demonstrating the validity of assumptions. From the professional engineer's perspective, under the principle that 'safety is non-negotiable,' a sense of balance is required to find the risk-proportionate optimum between over-design and under-design.
Outlook — data-driven·continuous safety assurance: In the era of autonomous driving and SDVs, the paradigm shifts from one-time certification at the point of shipment to continuous safety assurance during operation through driving data·OTA·field monitoring. Shrinking SOTIF's unknown risks, digital-twin·simulation-based verification, and continuous updating of the safety case will become the center of standard practice.
Related technology — integration of security·AI·real-time: Functional safety is no longer an independent activity but must be organically combined with ISO/SAE 21434 (cybersecurity), ISO/PAS 8800 (AI safety), the real-time nature of [[rtos]], and the FMEA·FTA of [[software-safety-analysis]]. Especially in a centralized architecture, mixed-criticality isolation and security-safety co-design become core capabilities, which must be underpinned by an organization-wide safety culture and governance.
Organization·governance — institutionalizing a safety culture: ISO 26262 demands, ahead of technical requirements, an 'organizational capability that makes safety the top priority.' Unless independent safety assessment (confirmation measures), clarification of roles·responsibilities, DIA agreements across the supply chain, and configuration·change management of work products are in place, even the most excellent design ends up as 'safety not demonstrated with evidence.' Therefore the professional engineer must have a governance perspective that designs·operates functional safety not as the quality activity of a single project but as a continuous investment spanning company-wide processes·people·culture.
References
- ISO, "ISO 26262:2018 Road vehicles — Functional safety": https://www.iso.org/standard/68383.html
- ISO, "ISO 21448:2022 Road vehicles — Safety of the intended functionality (SOTIF)": https://www.iso.org/standard/77490.html
- Semiconductor Engineering, "ISO 26262 Knowledge Center": https://semiengineering.com/knowledge_centers/automotive/automotive-standards/iso-26262/
- ISO26262 Academy, "Hardware Metrics: PMHF, SPFM and LFM Explained": https://iso26262.academy/blog/hardware-metrics-explained-pmhf-spfm-lfm
- ISO/SAE, "ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering": https://www.iso.org/standard/70918.html
In one line: ISO 26262 grades the risk of automotive E/E malfunction via HARA→ASIL (A–D) and, with the safety lifecycle·V-model and the SPFM·LFM·PMHF hardware metrics, demonstrates safety with evidence across the entire lifecycle; it is a functional safety standard now expanding into the autonomous-driving era by combining with SOTIF·21434·AI-safety standards.