ISO 26262 vs SOTIF (ISO 21448): Functional Safety vs Intended Functionality Explained

Hello, automotive safety engineers, ADAS developers, and autonomous driving architects! As vehicles become increasingly autonomous, a critical question arises: “My system doesn’t have a hardware fault or a software bug, but it still behaves unsafely – which standard addresses this?” The answer is SOTIF (Safety of the Intended Functionality) – ISO 21448. Understanding when ISO 26262 applies, when SOTIF applies, and how they work together is essential for anyone developing modern ADAS and autonomous driving systems.

In this comprehensive comparison at PiEmbSysTech, we will explain both standards, their fundamental philosophical difference, the four-area scenario model that defines SOTIF’s scope, and how the two standards complement each other – with a worked AEB (Automatic Emergency Braking) example that illustrates exactly which hazards each standard addresses. Let us begin.

ISO 26262 vs SOTIF (ISO 21448) Table of Contents

1. The Fundamental Difference – Malfunction vs Insufficiency
2. What is SOTIF (ISO 21448)?
3. What is Functional Safety (ISO 26262)? – A Recap
4. The Origin Story – Why SOTIF Was Created
5. Scope Boundaries – What Each Standard Covers and Excludes
6. The SOTIF Four-Area Model – Known/Unknown × Safe/Unsafe
7. Triggering Conditions – The Core SOTIF Concept
8. The Sense-Plan-Act Model in SOTIF
9. Worked Example – AEB System Under Both Standards
10. Hazard Sources Comparison – Failure vs Limitation
11. The Master Comparison Table
12. When to Apply ISO 26262 Only
13. When to Apply SOTIF Only
14. When to Apply Both Standards Together
15. The Overlap Area – Where Both Standards Interact
16. The Safety Triangle – ISO 26262, SOTIF, and ISO 21434
17. The Validation Challenge – Proving SOTIF
18. Future: ISO 26262 3rd Edition and SOTIF Integration
19. Frequently Asked Questions
20. Conclusion

1. The Fundamental Difference – Malfunction vs Insufficiency

The single most important distinction between ISO 26262 and SOTIF can be stated in one sentence:

ISO 26262 addresses hazards caused by malfunctioning behavior – the system fails to work as designed due to hardware faults or software bugs.

ISO 21448 (SOTIF) addresses hazards that occur even when the system works exactly as designed – but the design is insufficient for the real-world situation, or the system’s intended functionality has performance limitations that lead to unsafe behavior.

In other words: ISO 26262 asks “what if the system breaks?” while SOTIF asks “what if the system works as designed but the design isn’t good enough for this situation?”

2. What is SOTIF (ISO 21448)?

ISO 21448:2022 “Road Vehicles – Safety of the Intended Functionality” defines SOTIF as: “The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.”

SOTIF addresses scenarios where the intended functionality of an E/E system – particularly the sensing, perception, decision-making, and actuation capabilities – encounters situations that exceed its design limitations, resulting in unsafe behavior without any hardware fault or software bug. This includes sensor limitations (a camera blinded by low sun, a radar confused by metal bridge reflections), perception algorithm limitations (a neural network misclassifying a stationary truck as sky), decision-making insufficiencies (a path planner that cannot handle an unexpected road geometry), and reasonably foreseeable misuse (a driver who over-relies on L2 ADAS and stops paying attention).

SOTIF was originally intended to be Part 14 of ISO 26262 but was ultimately published as a separate standard – recognizing that it addresses a fundamentally different category of safety challenges that requires different analysis methods, different validation strategies, and a different philosophical approach.

3. What is Functional Safety (ISO 26262)? – A Recap

ISO 26262 defines functional safety as: “The absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.” It addresses random hardware failures (component wear-out, transistor-level defects – managed through hardware metrics SPFM/LFM/PMHF) and systematic failures (design errors, software bugs – managed through rigorous development methods). The fundamental assumption is that the system’s intended functionality is correct – the design specification is right – but faults and failures in the implementation can lead to hazardous behavior.

4. The Origin Story – Why SOTIF Was Created

As ADAS and autonomous driving systems became more sophisticated, the automotive industry recognized a safety gap. A forward-facing camera system could pass every ISO 26262 requirement – no hardware faults, no software bugs, fully compliant ASIL D development – yet still fail to detect a white truck against a bright sky because the camera’s dynamic range was insufficient for that lighting condition. This is not a malfunction – the camera is working exactly as its specification defines. The problem is that the specification (and the sensor technology) is insufficient for the real-world condition.

ISO 26262 has no mechanism to address this type of hazard because its entire framework is built on the assumption that the intended functionality is correct. SOTIF fills this gap by providing methods to identify situations where the intended functionality may be insufficient, evaluate the associated risks, and implement measures to reduce those risks to acceptable levels.

5. Scope Boundaries – What Each Standard Covers and Excludes

ISO 26262 covers: Hazards caused by E/E system malfunctions – random hardware failures and systematic design/implementation errors.

ISO 21448 (SOTIF) covers: Hazards caused by functional insufficiencies (performance limitations of sensors, algorithms, and actuators) and reasonably foreseeable misuse – all in the absence of faults.

SOTIF explicitly does NOT cover: Faults and failures (covered by ISO 26262), cybersecurity threats (covered by ISO/SAE 21434), hazards caused by the technology itself (e.g., laser eye damage from LiDAR – covered by IEC 60825), electrical shock or fire hazards (unless caused by the intended functionality), and deliberate feature abuse (willful misuse beyond what is reasonably foreseeable).

6. The SOTIF Four-Area Model – Known/Unknown × Safe/Unsafe

SOTIF introduces a powerful conceptual model that divides all possible operating scenarios into four areas:

	Safe Scenarios	Unsafe Scenarios
Known	Area 1: Known safe – system performs correctly in these scenarios	Area 2: Known unsafe – identified scenarios where the system may behave unsafely
Unknown	Area 3: Unknown safe – scenarios not yet identified but system performs correctly	Area 4: Unknown unsafe – unidentified scenarios where the system may behave unsafely

The goal of SOTIF is to maximize Area 1 (known safe) while minimizing Areas 2 and 4 (known unsafe and unknown unsafe) until the residual risk is acceptably low. Area 2 scenarios are addressed through design improvements, restrictions on the operational design domain (ODD), or driver warnings. Area 4 is the most challenging – these are the “unknown unknowns” that can only be reduced through extensive testing, simulation, and field monitoring.

7. Triggering Conditions – The Core SOTIF Concept

Triggering conditions are the specific circumstances that cause the intended functionality to produce hazardous behavior. They are the SOTIF equivalent of “failure modes” in ISO 26262, but instead of component failures, they represent environmental conditions, sensor limitations, or usage patterns that expose functional insufficiencies.

Examples of triggering conditions: direct sunlight blinding a forward camera (sensor limitation), heavy rain degrading radar cross-section estimates (environmental condition), a pedestrian wearing highly reflective clothing confusing a LiDAR classification algorithm (perception limitation), a driver removing hands from the steering wheel during L2 operation beyond the system’s intended use (foreseeable misuse), and a construction zone with temporary lane markings that conflict with permanent markings (environmental ambiguity).

Identifying triggering conditions is the central activity of SOTIF analysis – analogous to how identifying failure modes is the central activity of FMEA in ISO 26262.

8. The Sense-Plan-Act Model in SOTIF

SOTIF analyzes the intended functionality through the Sense-Plan-Act model, which decomposes the system’s operation into three phases:

Sense: The system’s ability to create a sufficiently accurate representation of the environment – including sensor performance, sensor fusion, object detection, classification, and ego-vehicle localization. SOTIF hazards at this level include sensor blind spots, misclassification of objects, false positive/negative detections, and degraded performance in adverse weather.

Plan: The system’s ability to make appropriate decisions based on the perceived environment – including path planning, behavior prediction of other road users, risk assessment, and maneuver selection. SOTIF hazards at this level include incorrect predictions of pedestrian behavior, suboptimal path selection, and failure to recognize unusual road geometries.

Act: The system’s ability to execute the planned actions accurately and in a timely manner – including actuator control, vehicle dynamics management, and stability control during maneuvers. SOTIF hazards at this level include actuator response limitations and dynamic stability issues during emergency maneuvers.

9. Worked Example – AEB System Under Both Standards

Consider an Automatic Emergency Braking (AEB) system to illustrate which hazards each standard addresses:

Hazardous Scenario	Root Cause	Standard
AEB fails to brake because the brake ECU microcontroller has a random hardware fault	Random HW failure	ISO 26262
AEB activates unexpectedly due to a software bug in the braking control algorithm	Systematic SW failure	ISO 26262
AEB fails to detect a stationary white truck because the camera cannot distinguish it from the bright sky	Sensor performance limitation (triggering condition)	SOTIF
AEB brakes for a plastic bag blowing across the road, mistaking it for a pedestrian	Perception algorithm insufficiency (false positive)	SOTIF
AEB does not detect a pedestrian because radar and camera fusion algorithm has a gap in coverage at a specific angle	Sensor fusion limitation (false negative)	SOTIF
AEB fails because a hacker compromises the CAN bus and sends spoofed radar data	Cybersecurity attack	ISO 21434
Driver over-relies on AEB and stops watching the road, leading to a crash when AEB’s ODD is exceeded	Reasonably foreseeable misuse	SOTIF

This example clearly illustrates that a complete safety assessment of an AEB system requires both ISO 26262 (for hardware faults and software bugs) and SOTIF (for sensor limitations, perception errors, and misuse scenarios).

10. Hazard Sources Comparison – Failure vs Limitation

ISO 26262 hazard sources: Random hardware failures (component wear-out, manufacturing defects, transient faults), systematic hardware errors (design mistakes in circuits), and systematic software errors (coding bugs, specification errors, integration errors).

SOTIF hazard sources: Sensor performance limitations (resolution, range, field of view, dynamic range, susceptibility to weather/lighting), perception algorithm limitations (false positives, false negatives, misclassification, edge cases in neural networks), decision-making insufficiencies (incorrect situation assessment, suboptimal trajectory planning), specification insufficiencies (ODD not adequately defined, incomplete scenario coverage), and reasonably foreseeable misuse (driver distraction, over-trust in automation, misunderstanding of system capabilities).

11. The Master Comparison Table

Dimension	ISO 26262 (Functional Safety)	ISO 21448 (SOTIF)
Full title	Road vehicles – Functional safety	Road vehicles – Safety of the intended functionality
Published	2011 (1st ed.), 2018 (2nd ed.)	2019 (PAS), 2022 (full standard)
Core question	What if the system breaks?	What if the system works as designed but isn’t good enough?
Hazard source	Malfunctioning behavior (HW faults, SW bugs)	Functional insufficiencies, performance limitations, foreseeable misuse
System state during hazard	System has a fault or failure	System is operating correctly (no fault)
Risk classification	ASIL (A–D) via HARA	No ASIL equivalent; scenario-based risk evaluation
Primary analysis method	HARA, FMEA, FTA, FMEDA	Triggering condition identification, scenario-based analysis
Validation approach	Requirements-based testing, structural coverage	Scenario-based testing, simulation, field monitoring, statistical evidence
Key challenge	Demonstrating adequate fault detection and metrics	Demonstrating sufficient coverage of unknown unsafe scenarios (Area 4)
Primary target systems	All E/E systems (EPS, ABS, airbags, powertrain, etc.)	ADAS and autonomous driving (L1–L5)
AI/ML systems	Not specifically addressed (systematic failure avoidance)	Directly relevant (perception, decision-making)
Parts	12 parts	1 part (~80 pages)
Cybersecurity	References ISO 21434 (interface)	Explicitly excludes (defers to ISO 21434)

12. When to Apply ISO 26262 Only

ISO 26262 alone is sufficient for well-understood E/E systems with deterministic functionality that do not rely on environment perception or AI-based decision-making. Examples include: Electric Power Steering (EPS), Anti-lock Braking System (ABS), Electronic Stability Control (ESC), airbag systems, engine management, body control modules, lighting systems, and seat heater controllers. For these systems, the intended functionality is well-defined, the failure modes are well-understood, and hazards arise from malfunctions – not from insufficient understanding of the environment.

13. When to Apply SOTIF Only

In practice, SOTIF is rarely applied in complete isolation from ISO 26262 because any ADAS system also contains E/E hardware that can fail. However, the SOTIF-specific analysis (triggering conditions, scenario-based testing) is most critical for systems that rely on environmental perception and machine-learning-based decision-making: forward collision warning, automatic emergency braking (AEB), lane keeping assist, adaptive cruise control, blind spot detection, traffic sign recognition, automated parking, and all SAE Level 3–5 autonomous driving functions.

14. When to Apply Both Standards Together

For modern ADAS and autonomous driving systems, both standards must be applied simultaneously. The E/E hardware and software must be developed to ISO 26262 (ensuring the system doesn’t malfunction), while the intended functionality – particularly the perception, decision-making, and human-machine interaction aspects – must be analyzed and validated according to SOTIF (ensuring the system performs safely even in challenging real-world conditions). The AEB example in Section 9 demonstrates this dual requirement clearly.

15. The Overlap Area – Where Both Standards Interact

There is a growing recognition that ISO 26262 and SOTIF have areas of overlap, particularly around systematic failures that could also be viewed as specification insufficiencies. For example: a software specification error that causes incorrect behavior – is this a systematic failure (ISO 26262) or a specification insufficiency (SOTIF)? In practice, both standards may apply to the same issue, and the development team must ensure coverage from both perspectives. The upcoming third edition of ISO 26262 (expected ~2027) includes working group discussions on how to better integrate SOTIF concepts into the functional safety framework.

16. The Safety Triangle – ISO 26262, SOTIF, and ISO 21434

Modern automotive safety requires a holistic approach covering three complementary standards: ISO 26262 (functional safety – system malfunctions), ISO 21448 (SOTIF – functional insufficiencies), and ISO/SAE 21434 (cybersecurity – malicious attacks). These three standards together form the “safety triangle” that addresses all major hazard sources for modern connected, autonomous vehicles. Each standard explicitly references the others and requires interfaces between the respective safety and security activities.

17. The Validation Challenge – Proving SOTIF

Validating SOTIF is fundamentally more challenging than validating ISO 26262 compliance. ISO 26262 validation is requirements-based – you verify that each requirement is met through testing and analysis. SOTIF validation requires demonstrating that the residual risk from unknown unsafe scenarios (Area 4) is acceptably low – but you cannot directly test for scenarios you haven’t identified. SOTIF validation strategies include massive-scale simulation (billions of simulated driving kilometers covering edge cases), scenario-based testing using structured scenario libraries (ISO 34502), real-world driving data collection and analysis, machine learning for generating adversarial test scenarios, and field monitoring after deployment with continuous improvement. The validation effort for SOTIF on L3+ autonomous systems is expected to be orders of magnitude greater than for ISO 26262 alone.

18. Future: ISO 26262 3rd Edition and SOTIF Integration

The third edition of ISO 26262 (expected around 2027) includes working group discussions on incorporating elements of SOTIF and safe nominal performance into the functional safety framework. This reflects the industry’s recognition that the sharp boundary between “malfunction” (ISO 26262) and “insufficiency” (SOTIF) is becoming increasingly blurred for AI-enabled systems. The evolution may result in a more unified safety framework that addresses both types of hazards within a single lifecycle, while maintaining the distinct analysis methods appropriate to each hazard category.

19. Frequently Asked Questions

Q1: Does SOTIF replace ISO 26262?

No. SOTIF complements ISO 26262 — it does not replace it. ISO 26262 remains essential for ensuring that E/E systems do not malfunction. SOTIF adds coverage for hazards that ISO 26262 cannot address – those arising from functional insufficiencies in the absence of faults. Both standards are needed for a comprehensive safety assessment of modern vehicles.

Q2: Does SOTIF have ASIL levels?

No. SOTIF does not use the ASIL classification system. Risk evaluation in SOTIF is scenario-based rather than requirements-based. The goal is to demonstrate that the residual probability of the system encountering an unknown unsafe scenario (Area 4) is acceptably low — expressed through statistical evidence from testing and simulation rather than through an ASIL lookup table.

Q3: Does SOTIF apply to non-ADAS systems?

SOTIF is most relevant to ADAS and autonomous driving systems that rely on environmental perception. For traditional E/E systems (EPS, ABS, engine management) with well-defined, deterministic functionality, ISO 26262 alone is typically sufficient. However, any system that interprets environmental data (such as a rain-sensing wiper or an automatic headlight dimmer) could potentially benefit from SOTIF analysis of its perception limitations.

Q4: How do I handle a hazard that could be either ISO 26262 or SOTIF?

Apply both perspectives. Analyze the hazard from the ISO 26262 viewpoint (could a malfunction cause this?) and from the SOTIF viewpoint (could a functional insufficiency cause this?). Document the analysis under both frameworks. The safety case should demonstrate that the hazard is adequately addressed regardless of its root cause.

Q5: Is SOTIF mandatory for ISO 26262 compliance?

SOTIF is a separate standard and is not required by ISO 26262 for compliance. However, for ADAS and autonomous driving systems, SOTIF compliance is increasingly expected by OEMs, regulatory bodies, and certification agencies as part of a comprehensive safety argument. The upcoming UNECE regulations for automated driving functions are expected to reference SOTIF principles.

20. Conclusion

ISO 26262 and SOTIF (ISO 21448) represent two complementary pillars of automotive safety. ISO 26262 ensures that E/E systems do not create hazards when they malfunction. SOTIF ensures that E/E systems do not create hazards even when they work exactly as designed – by identifying and addressing the functional insufficiencies, sensor limitations, and foreseeable misuse scenarios that could lead to unsafe behavior. For modern ADAS and autonomous driving systems, both standards are essential – together with ISO 21434 for cybersecurity – to provide comprehensive safety assurance.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For the foundational ISO 26262 coverage, visit our ISO 26262 Complete Guide.

Stay safe. Stay SOTIF-aware. Keep engineering the future.

— The PiEmbSysTech Team