SOTIF (ISO 21448, Safety of the Intended Functionality)
1. Overview
A. Definition
SOTIF (Safety Of The Intended Functionality) is an automotive safety concept concerned with the freedom from unreasonable risk that arises—even when the system has no malfunction whatsoever—from the performance limitations, misperception, or specification gaps of the intended function itself, and the international standard that systematizes it is ISO 21448:2022. It rests on the problem awareness that "even when no component has failed, and even when the function operates correctly within its designed limits, the outcome can still be hazardous."
The background to SOTIF's emergence lies in the shift of automotive safety's center of gravity from "guarding against faults" to "guarding against the performance limits of perception and decision-making." The traditional functional safety standard [[iso-26262]] prevents "faults whose cause can be pinpointed"—a sensor open-circuit, a bit flip, a software defect—from escalating into hazards. But in ADAS (advanced driver assistance) and autonomous driving, which rely on cameras, radar, lidar, and deep-learning perception algorithms, accidents occur where no component has failed yet the system misses a pedestrian in backlight, or mistakes a plastic bag on the road for an obstacle and brakes hard. This is not a "fault" but "a situation the designed function cannot handle (performance insufficiency)," so it is neither explained nor controlled within the ISO 26262 framework. To fill this gap it began in 2019 as ISO/PAS 21448 (a technical specification) and was published as a formal international standard (ISO 21448:2022) in June 2022.
The starting point for understanding SOTIF is the paradox that "the system can be unsafe even without any fault." Whereas ISO 26262 addresses "when the system fails to operate correctly (malfunction)," SOTIF addresses "when the outcome is hazardous even though the system operated correctly per specification." For example, an automatic emergency braking (AEB) system failing to recognize a stationary vehicle ahead is a performance limitation—the radar being unable to distinguish a metal structure from a stationary vehicle within its "designed reflectivity range"—not a fault. The core SOTIF question is therefore not "how do we detect and respond to faults" but "how far can we discover the limits of the intended function, and how do we demonstrate that those limits do not become hazards."
ISO 21448 spans ADAS and driving automation levels 1–5 (SAE J3016), taking as its scope especially functions that perceive situations through complex sensors and processing algorithms, and even reasonably foreseeable misuse. That is, misuse such as a driver overtrusting an assistance function and letting go of the wheel is also treated as "a condition the system must handle" and included in the safety argument—a distinctive feature.
The evolution path of the standard itself shows the maturing of this problem awareness. It began in 2019 as a "Publicly Available Specification," ISO/PAS 21448—that is, provisional guidance not yet fully agreed upon. As autonomous-driving accident cases accumulated and industry experience grew, it was elevated to a formal international standard in 2022, and at that point its scope was explicitly extended from level 1–2 driver assistance to level 3–5 autonomous driving. It compactly reveals the process by which the notion of "risk without a fault" rose from a peripheral concern to a central agenda of automotive safety.
B. The two sources of risk SOTIF addresses
The risk SOTIF targets stems largely from two specification deficiencies. The first is functional insufficiency, a gap that arises when, in defining the intended function at the vehicle level, a particular situation was not adequately considered. The second is performance limitation, the limits that sensors and perception/decision algorithms inevitably have physically and statistically (sensor resolution, adverse-weather attenuation, training-data bias). When these meet a particular triggering condition—environmental and scenario factors such as backlight, fog, construction zones, or unusual road signs—they are realized as hazardous behavior.
A concept that must be distinguished here is the relationship between the "triggering condition" and the "functional insufficiency." A functional insufficiency is a weakness the system inherently possesses, while a triggering condition is a situation that stimulates that weakness from the outside to make it manifest. For example, even with a functional insufficiency such as "degraded recognition of a pedestrian in black clothing in low nighttime light," if there is no triggering condition in which such a pedestrian appears, no accident occurs. The essence of SOTIF activity therefore reduces to ① finding and reducing functional insufficiencies, ② systematically uncovering the triggering conditions that make them manifest, and ③ designing and verifying so that even when the two meet they do not escalate into harm. In an exam answer, clearly describing the causal structure "performance limitation × triggering condition = hazardous scenario" is key.
C. Reasonably foreseeable misuse
Another point that clearly distinguishes SOTIF from ISO 26262 is that it includes even human misuse as a condition the system must handle. Mistaking an assistance function for "autonomous driving" and letting go of the wheel, ignoring warnings and delaying takeover, or turning on a function on a road it was not designed for—all of these constitute "reasonably foreseeable misuse." SOTIF does not dismiss such human factors as "the user's fault" but regards them as design inputs the system must foresee and mitigate. This reflects the insight that in autonomous driving a substantial share of accidents stems from "human-machine interaction (HMI)" problems where technical limits and human overtrust/misjudgment are intertwined.
The practical implication of this perspective is large. Raising perception performance alone cannot demonstrate safety; a Driver Monitoring System (DMS), clear notification of operating limits, staged takeover warnings, and design to prevent mode confusion become essential elements of the SOTIF safety argument. For example, one must explicitly specify "the situation in which a driver who believes the system is on does not intervene" as a triggering condition and design so that even in such a situation the system transitions to a safe minimal-risk state. SOTIF is therefore an engineering problem of sensors and algorithms while at the same time a problem of ergonomics and behavioral science.
2. SOTIF's four scenario areas and core concepts
SOTIF's most widely known conceptual framework is the four areas (Area 1–4) that divide scenarios along two axes: "known/unknown" × "safe/unsafe." The structure diagram below shows this 2×2 framework and how SOTIF activity tries to move each area.
graph TD
subgraph KNOWN["Known scenarios"]
A1["Area 1: known safe<br/>normal operating region"]
A2["Area 2: known unsafe<br/>identified hazardous scenarios"]
end
subgraph UNKNOWN["Unknown scenarios"]
A4["Area 4: unknown safe"]
A3["Area 3: unknown unsafe<br/>undiscovered hazardous scenarios"]
end
A3 -->|"scenario mining·driving accumulation"| A2
A2 -->|"design improvement·function change"| A1
A4 -.->|"confirm by analysis"| A1
GOAL["Goal: minimize Area 2·3"]
A2 --> GOAL
A3 --> GOAL
The meaning of these four areas unfolds as follows. Area 1 (known safe) is the region confirmed to operate safely as intended—the final state development aims for. Area 2 (known unsafe) comprises hazardous scenarios already identified through analysis and testing, which must be moved to Area 1 by measures such as design improvement, function limitation, or driver warning. Area 3 (unknown unsafe) comprises hazardous scenarios not yet discovered and is the area SOTIF guards against most—because their very existence is unknown they cannot be removed directly, and they can be removed only after being pulled into the "known" region (Area 2) through scenario mining and large-scale driving-data accumulation. Area 4 (unknown safe) comprises scenarios not yet known but actually safe. SOTIF's strategic goal is therefore clear—to reduce the size of Area 2 and Area 3 to an acceptable level.
This framework matters because it reveals the essential difficulty of autonomous-driving safety. Area 3 is the region of "unknown unknowns" and cannot be emptied completely, because it is impossible to enumerate in advance every driving situation in the world. SOTIF therefore sets a validation target—"at what point of verification do we declare it sufficiently safe"—and relies on a method of showing, by statistical argument, that the residual risk is acceptable. This is precisely what fundamentally differs from ISO 26262, which deterministically traces fault paths.
| Area | Known? | Safe/unsafe | Core activity |
|---|---|---|---|
| Area 1 | known | safe | normal operation — maintain·expand |
| Area 2 | known | unsafe | turn into Area 1 by design improvement |
| Area 3 | unknown | unsafe | turn into Area 2 by scenario mining |
| Area 4 | unknown | safe | confirm as Area 1 by analysis |
The table organizes the four areas, but in actual development the core effort concentrates on the boundaries. That is, the Area 2↔Area 3 boundary (how to reveal risks still unknown) and the Area 1↔Area 2 boundary (by what measures to make identified risks safe) are the two fronts of SOTIF engineering. In practice, systematic hazard analysis (HAZOP, functional analysis) widens Area 2, while simulation, field operation, and edge-case mining pull Area 3 into Area 2.
Overlaying this four-area model with the ODD deepens understanding further. Setting the ODD narrowly shrinks the scenario space the system will encounter, so Area 3 (unknown risk) also shrinks, but the range in which the function is provided is correspondingly limited. Conversely, widening the ODD increases utility but causes unknown triggering conditions to surge, so Area 3 expands. That is, the ODD is the "boundary of the stage" that defines the total size of the four areas, and SOTIF activity is the work of illuminating and reducing the risk regions within that stage. For this reason, "how far to widen the ODD and how to detect and enforce its boundary" becomes the first button of SOTIF strategy.
One must also note that movement among the four areas is not one-directional but iterative. Changing the design to move Area 2 to Area 1 may create unexpected new hazards and give rise to yet another Area 3. For example, lowering perception sensitivity to reduce false-positive braking increases the false-negative risk of missing a real obstacle (a new Area 3). Because SOTIF risk thus has a "trade-off structure," an iterative loop that cross-checks whether a measure reducing one area enlarges another is essential.
3. The SOTIF activity process and verification/validation
ISO 21448 presents the activities for achieving SOTIF as an iterative process spanning the lifecycle. The detail diagram below depicts the flow that starts from function definition and cycles through risk assessment, design measures, verification/validation, and operational-phase feedback.
flowchart LR
F["intended function definition<br/>(function·ODD spec)"] --> H["hazard identification·assessment<br/>(HARA, hazardous-behavior analysis)"]
H --> T["triggering-condition analysis<br/>(derive insufficiency·performance limit)"]
T --> D["design improvement·function change<br/>(reduce Area 2)"]
D --> V["Verification<br/>confirm known risk removed"]
V --> VAL["Validation<br/>statistical argument for unknown risk"]
VAL --> ACC{"acceptable?"}
ACC -->|"no"| T
ACC -->|"yes"| REL["release·deployment"]
REL --> OP["operational-phase monitoring<br/>(field data·OTA improvement)"]
OP -.->|"new trigger found"| T
It is worth noting how this process resembles yet differs from ISO 26262's V-model. Both standards share the lifecycle skeleton of "requirement→design→verification" and traceability, but whereas ISO 26262's V-model is a "closed loop" that deterministically verifies the consistency of each stage's deliverables, the SOTIF process is closer to an "open iterative loop" that continually uncovers and feeds back unknown risk. That is, for SOTIF "the point at which development ends" is not clear; it keeps running until the acceptance criteria are met and even during operation. This structural difference splits the two standards' verification philosophies.
Explaining each stage of the process in prose: first, in the intended-function definition stage one specifies, along with the function's purpose, the ODD (Operational Design Domain)—the range of conditions such as road type, speed, weather, and illumination under which the system is designed to operate safely. The ODD is both SOTIF's starting point and boundary, a promise that "within this range safety is guaranteed, and outside it the function is safely limited or handed over." Narrowing the ODD makes safety easier to demonstrate but reduces functional utility, while widening it increases utility but causes the verification burden to surge—the trade-off is decided here.
Next, hazard identification and assessment derives the hazardous behavior that can occur even when the function operates as intended, and triggering-condition analysis systematically finds the environmental and situational factors that induce that harm and the functional insufficiencies and performance limits behind them. Then design improvement reduces the identified risk (Area 2) by measures such as sensor redundancy (camera+radar+lidar fusion), strengthening the perception algorithm, function limitation (operate only at low speed), and driver takeover requests.
The highlight of SOTIF activity is the distinction between Verification and Validation. Verification is the activity of confirming "whether the identified known risk (Area 2) was actually removed by the measures," carried out by testing and simulation against target scenarios. Validation, by contrast, is the activity of arguing, through statistical and scenario coverage, "whether the residual risk, including risk not yet identified (Area 3), is at an acceptable level." If the former is a deterministic check, the latter is probabilistic persuasion, and the reason autonomous driving demands hundreds of millions of kilometers of real-world and simulation data lies precisely in this validation burden. For example, to show statistically that fatal accidents are rarer than with a human driver, an "approval trap" is known whereby an astronomical driving distance is needed because the mean distance between accidents is very long, and to mitigate it, scenario-based verification, simulation, and accelerated testing are combined.
A stage easily overlooked in the SOTIF argument is setting the acceptance criteria. Because unknown risk cannot be eliminated completely, only by defining in advance "at what level of residual risk it is socially acceptable" does the declaration of "sufficiently verified" become possible. In practice, quantitative targets are set with reference to risk-acceptance principles such as GAMAB (Globally At Least As Good—at least as safe as existing means), MEM (Minimum Endogenous Mortality—limiting added risk relative to natural mortality), and ALARP (As Low As Reasonably Practicable). For example, taking "at or below the accident rate of a comparable human driver" as the target, the driving distance and scenario coverage needed to prove it statistically are back-calculated. If this acceptance criterion is ambiguous, verification either grows endlessly or ends arbitrarily, so the criterion's transparency and social consensus govern SOTIF's credibility.
Another core design element is the minimal risk state (MRM/MRC, Minimal Risk Maneuver/Condition). When the system leaves the ODD boundary or senses its own performance limit, it must transition to a state that does not increase risk—for example, safely decelerating to a roadside stop or handing control over to the driver. What matters here is the "ability to know one's own limits." Without a design that detects at runtime situations where perception uncertainty rises (adverse weather, OOD input) and performs graceful degradation, the system makes hazardous decisions without even knowing that it is wrong. Uncertainty quantification and ODD monitoring therefore lie at the heart of the SOTIF architecture.
Finally, operational-phase monitoring is the axis that makes SOTIF not a one-time certification but continuous safety assurance. Even after release, when a new triggering condition is found in field data it is reflected as Area 3→Area 2, and perception models and control logic are improved via OTA (over-the-air update) to maintain and raise the safety level. This feedback loop is the core operating model of autonomous-driving safety.
4. Comparison — the relationship with ISO 26262 and application cases
To use SOTIF accurately, the division of labor with ISO 26262 must be made clear. The two standards are not competitors but in a mutually complementary relationship. What ISO 26262 addresses is the risk created by "E/E faults," that is the "fault space," while what SOTIF addresses is the risk arising from insufficient performance even without a fault, that is the "insufficiency space." The root reason for the difference lies in the source of risk and the mode of proof. Faults can be pinpointed by cause and quantified by probability, so they are traced by FTA·FMEA and the residual risk is quantified by hardware metrics. Performance insufficiency, by contrast, cannot have "when and in what situation it will misperceive" fully enumerated, so it relies on scenario coverage and statistical argument. Interestingly, ISO 21448 was originally discussed as a part of ISO 26262, but its character of "risk without a fault" was so fundamentally different that it was separated into a standalone standard.
| Aspect | ISO 26262 | ISO 21448 (SOTIF) |
|---|---|---|
| Target risk | E/E fault (malfunction) | performance limit·misperception (no fault) |
| Space | fault space | insufficiency space |
| Grading scheme | ASIL A~D(+QM) | no grades (scenario argument) |
| Core techniques | HARA·FTA·FMEA·HW metrics | scenario mining·V&V·statistical argument |
| Proof philosophy | deterministic evidence | probabilistic·scenario argument |
The practically important implication of this comparison is that to make a single autonomous-driving system safe, both standards must be applied simultaneously. Consider automatic emergency braking (AEB). A radar ECU malfunctioning via a bit flip and omitting a braking command is ISO 26262's domain, while the radar, without any fault, mistaking a metal manhole cover for a stationary vehicle and applying unnecessary hard braking (false positive) is SOTIF's domain. Indeed, some 2016–2018 autonomous-driving and driver-assistance accidents were analyzed as stemming not from component failure but from the limits of perception algorithms (misidentifying a stationary trailer or a construction structure), and this became the direct driver for SOTIF's elevation to a formal standard.
Seeing how the two standards coexist within the same ECU makes the division of labor even clearer. An autonomous-driving controller, from the ISO 26262 perspective, guarantees "fault-free computation" with lockstep cores, ECC, and watchdogs, while from the SOTIF perspective it quantifies the uncertainty of perception results and safely degrades the function when it cannot be trusted. The former asks "was the computation not wrong," the latter asks "the computation was right, but may we trust the result." Thus within a single safety architecture a deterministic fault-safety mechanism and a probabilistic performance-safety mechanism coexist in layers, and if either one is missing the autonomous-driving safety argument does not hold. In an answer, unfolding the division "26262 = guarding against faults, SOTIF = guarding against performance limits, the two complement each other" with concrete cases gives the comparison depth.
Another application case is lane-keeping assist (LKAS). Under a triggering condition where road markings are worn away or, in a construction zone, temporary lanes overlap existing lanes, LKAS steering along the wrong lane is a typical SOTIF risk. This is mitigated by ODD specification (restricting operation to roads whose lane-marking quality is above a certain standard), driver takeover requests, and multi-sensor fusion. SOTIF is thus the activity of designing, between a function's utility and safety, how to draw the ODD and how to detect limit situations and hand over safely.
The weight sensor fusion carries in SOTIF is also revealed in common by these cases. A camera is strong at color and shape recognition but weak in low light and backlight; radar is strong at distance and speed but weak at distinguishing stationary objects and shapes; lidar is strong at 3-D shape but weak in adverse weather and on cost. By fusing heterogeneous sensors (redundancy·diversity) so their performance limits do not overlap, even if one sensor fails under a particular triggering condition another compensates, structurally reducing Area 3. However, fusion itself can give rise to new functional insufficiencies (spatiotemporal alignment errors between sensors, conflict resolution), so one must not forget that the fusion logic too becomes an object of SOTIF analysis.
5. In depth — extension into AI safety standards and recent trends
The biggest change in the recent SOTIF landscape is the challenge of demonstrating the safety of AI/machine-learning-based perception. Deep-learning perception models fail unpredictably on out-of-distribution inputs not present in the training data and have a black-box character whose internal decision process is hard to explain. This is a prototype of the "functional insufficiency" SOTIF speaks of, but traditional scenario analysis alone struggles to reveal the model's limits sufficiently. To fill this gap, ISO/PAS 8800 (Road vehicles — Safety and artificial intelligence) was published in 2024, presenting a system that links automotive AI's safety lifecycle, dataset quality, and model performance assurance with SOTIF and ISO 26262. Together, UL 4600 (the autonomous-vehicle safety-case standard) demands a safety case for the complete system, and these standards combine in layers to form a three-dimensional system of "fault safety (26262) + performance safety (21448) + AI safety (8800) + overall safety case (UL 4600)."
Attracting attention as foundational technologies supporting this flow are uncertainty quantification and runtime monitoring. These are designs that make a deep-learning model also output how trustworthy its prediction is (e.g., Bayesian neural networks, ensembles, OOD detection) and, when confidence is low, cross-check with another sensor or degrade the function. Capturing the moment the model is "confidently wrong" is precisely the core capability SOTIF demands of AI perception, and it is the contact point where explainable AI (XAI) meets the safety architecture.
The second trend is the rise of scenario-based validation and simulation. Because of the aforementioned "approval trap" (astronomical real-world driving distance), the industry describes driving scenarios in standard formats such as OpenSCENARIO·OpenDRIVE and explores Area 3 by automatically generating and running millions of variant scenarios in high-fidelity simulation and digital twins. In particular, edge-case mining (extracting rare and hazardous situations from real-driving and accident data) combined with adversarial scenario generation (synthesizing situations that intentionally disturb perception) has become a core research topic for raising the coverage of unknown risk at limited cost.
The third is the recognition that dataset quality becomes a safety property. Because the performance limits of deep-learning perception ultimately stem from the distribution of the training and validation data, ISO/PAS 8800 elevates a dataset's completeness, representativeness, balance, and accuracy to safety requirements. If a particular ethnicity, body type, adverse weather, or regional road is undersampled in the data, it remains directly as Area 3's unknown risk. Accordingly, data requirements engineering, which reverse-engineers "what distribution of data and how much is needed to cover which ODD," and data governance, which tracks data provenance, label quality, and bias, have emerged as new axes of SOTIF practice. This is the point where the data-quality and MLOps capabilities of the AI·data field directly mesh with safety engineering.
The fourth is convergence with security. In connected and autonomous-driving environments, an adversarial attack—for example, sticking a sticker on a traffic sign to make the perception model misclassify—is a "maliciously induced triggering condition," lying at the boundary of SOTIF (performance limit) and the cybersecurity standard ISO/SAE 21434. An approach that integrates safety and security into a single threat model is therefore required. Likely exam directions are a convergence-type question such as "discuss the integrated safety process of ISO 26262·SOTIF·ISO/PAS 8800 with an autonomous-driving perception case," or an architecture-type question such as "design a scenario-based verification and simulation strategy to reduce SOTIF's Area 3 (unknown risk)."
6. Considerations and implications
Application strategy — ODD-centric design and staged narrowing: The success or failure of SOTIF activity hinges on how clearly the ODD is drawn and how safely the function is limited or handed over by detecting its boundary in real time. A realistic staged-rollout strategy is to set the ODD conservatively narrow at first to firmly demonstrate safety, then gradually expand the ODD while reducing unknown risk (Area 3) with field data and simulation. Detecting situations that leave the ODD (ODD monitoring) and designing a safe minimal risk state (MRM, Minimal Risk Maneuver) are core capabilities.
Trade-off — utility vs verification burden vs cost: The more the ODD is widened and the automation level raised, the greater the functional utility, but the scenario space to be proven explodes and the verification cost and duration increase nonlinearly. Conversely, an overly conservative design (frequent false-positive braking, frequent takeover requests) is safe but harms marketability. From the professional engineer's perspective, under the premise that "safety is non-negotiable," a sense of balance that finds the risk-proportionate optimum among ODD, sensor configuration, and verification target is required.
Outlook — a shift to data-driven continuous safety assurance: SOTIF shifts the paradigm from one-time certification at the point of shipment to continuous safety assurance through field data, OTA, and simulation during operation. A "living safety case" that updates the safety case each time a new triggering condition is found will become the center of standard practice, and this is directly tied to digital-twin, scenario-DB, and edge-case-mining capabilities.
Related technologies — integration of functional safety·AI safety·security: SOTIF is not a standalone activity but must organically combine with [[iso-26262]] (fault safety), ISO/PAS 8800 (AI safety), ISO/SAE 21434 (cybersecurity), the FMEA·FTA of [[software-safety-analysis]], and the real-time nature of [[rtos]]. In particular, because the opacity and data dependence of deep-learning perception cannot be handled by traditional safety-analysis techniques alone, the design capability to integrate new technologies such as explainable AI, uncertainty quantification, and runtime monitoring into the safety architecture becomes essential.
Domestic·institutional perspective — alignment with regulation and certification: In Korea too, as temporary-operation permits for autonomous driving and level-3 safety standards are established, SOTIF directly affects the type-approval and safety-assessment practice of the OEM and parts industries. In the flow where UNECE WP.29's autonomous-driving regulations and ISO 21448·ISO/PAS 8800 take root as certification bases, the professional engineer must survey not only the standard's technical content but also how it meshes with the regulation, certification, and (product) liability systems. The legal debate over where responsibility for an accident caused by a performance limit lies—among manufacturer, operator, and driver—is also directly tied to the level of SOTIF demonstration.
Organization·governance — scenario assets and safety culture: SOTIF's competitiveness ultimately comes down to "how rich and systematic a set of scenario and driving-data assets has been accumulated." Without the backing of configuration and version management of the scenario DB, data-quality governance, and an organizational process that continually uncovers and reflects unknown risk, even the finest algorithm remains "unproven safety." The professional engineer must hold a governance perspective that designs and operates SOTIF not as a single project's verification activity but as an enterprise-wide, continuous investment across data, process, and culture.
References
- ISO, "ISO 21448:2022 Road vehicles — Safety of the intended functionality (SOTIF)": https://www.iso.org/standard/77490.html
- ISO, "ISO/PAS 8800:2024 Road vehicles — Safety and artificial intelligence": https://www.iso.org/standard/83303.html
- PTC, "ISO 26262 vs. SOTIF (ISO/PAS 21448): What's the Difference?": https://www.ptc.com/en/blogs/alm/iso-26262-vs-sotif-iso-pas-21448-whats-the-difference
- Visure Solutions, "ISO 21448 (SOTIF) — Safety of the Intended Functionality": https://visuresolutions.com/automotive/iso-21448/
In one line: SOTIF (ISO 21448:2022) is an automotive safety standard addressing the risk that arises—even without a fault—from the performance limits and misperception of the intended function; it divides scenarios into four areas of known×safe to reduce Area 2·3, statistically argues unknown risk through triggering-condition analysis·verification·validation·operational monitoring, and, combined with ISO 26262 (fault safety)·ISO/PAS 8800 (AI safety), underpins autonomous-driving safety.