ISO 21448 (SOTIF): ISO 21448 – Tutorial (about 60 minutes)

ISO 21448, known as SOTIF (Safety Of The Intended Functionality), is the international standard that helps carmakers and their suppliers deal with a specific kind of danger: a driver-assistance or automated-driving feature that has no fault at all, yet still behaves unsafely because its sensors, algorithms or specification were not good enough for the situation it met. It is used by system engineers, perception and machine-learning teams, validation engineers and safety managers who build features such as emergency braking, adaptive cruise control, lane keeping and automated driving. After this tutorial you will be able to explain what SOTIF covers and what it leaves to other standards, walk through its activities from specification to field monitoring, and plan a basic SOTIF argument for a real feature.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO 21448:2022, Road vehicles – Safety of the intended functionality, the first edition of the International Standard, published by ISO in June 2022 and prepared by technical committee ISO/TC 22 (road vehicles), subcommittee SC 32 (electrical and electronic components and general system aspects). It replaced ISO/PAS 21448:2019, a Publicly Available Specification issued in January 2019 that focused mainly on emergency intervention and driver-assistance features at automation levels 1 and 2. The 2022 edition is still the published, current one, but ISO has marked it "to be revised" (stage 90.92, October 2025). A second edition is in development as ISO/WD 21448 (ISO project 93071), a working draft whose comment period closed on 11 September 2026 (stage 20.60). That revision is not published, so the 2022 edition is the one to apply and the one this course teaches; details of the future edition may change before publication. Verified 2026-10-29 against the ISO committee catalogue entries for ISO 21448:2022 (project 77490) and ISO/WD 21448 (project 93071).

Who it is for: engineers, product owners, test and validation staff, quality and safety people, and project managers who work on (or buy) vehicle features that sense the world and act on it, and who are new to SOTIF. It is also useful for people from functional safety (ISO 26262) who want to understand where their work ends and SOTIF begins.

Prerequisites: none. A rough idea of how a driver-assistance system works (sensors, software that interprets them, actuators such as brakes and steering) helps. Every technical term is explained the first time it appears.

By the end of this tutorial:

You will be able to explain why a fault-free system can still be hazardous, and how SOTIF differs from functional safety and cybersecurity.
You will be able to define the core SOTIF vocabulary: functional insufficiency, triggering condition, hazardous behaviour, reasonably foreseeable misuse, acceptance criterion and validation target.
You will be able to describe the structure of ISO 21448:2022, its clauses 4 to 13 and its informative annexes.
You will be able to use the four scenario areas (known or unknown, hazardous or not) to reason about how much is left to discover.
You will be able to walk through the SOTIF activity flow, from specification and hazard analysis to verification, validation, release and the operation phase.
You will be able to explain how SOTIF evidence is reviewed and why there is no ISO certificate for SOTIF itself.
You will be able to apply the ideas to a realistic feature such as automatic emergency braking.

Lesson 1 – Origins, purpose and scope

A system that works as designed and still hurts someone

For decades, vehicle safety engineering for electronics was mostly about faults. A sensor wire breaks, a microcontroller has a bit flip, a software bug sends the wrong torque request. ISO 26262, the functional safety standard for road vehicles, gives a complete framework for this kind of problem: it calls the resulting unsafe behaviour a malfunction and asks engineers to prevent, detect and control the faults behind it.

Driver-assistance and automated-driving features exposed a gap in that thinking. Imagine an emergency braking system that uses a camera and a radar. On a sunny evening the camera faces a low sun and cannot see a stopped car ahead; the radar alone is not trusted to brake. No component has failed, every line of code does exactly what it was written to do, and yet the car does not brake. On another day the radar receives a strong reflection from a metal plate in the road surface, the software interprets it as an obstacle and the car brakes hard on an empty motorway, with a truck close behind. Again, nothing is broken.

These are not malfunctions in the ISO 26262 sense. They come from the limits of the intended functionality itself: the sensors cannot perceive everything, the algorithms cannot interpret everything, and the people who wrote the specification could not foresee every situation. SOTIF exists to manage exactly that residual danger. The name says it: the safety of the functionality that was intended, as opposed to the safety of a broken implementation of it.

From a specification to an International Standard

The topic grew in the same ISO committee community that maintains ISO 26262. When the second edition of ISO 26262 was being prepared, experts agreed that hazards from performance limits needed their own guidance rather than an add-on to the fault-based standard. The first result was ISO/PAS 21448:2019. A PAS (Publicly Available Specification) is a lighter ISO deliverable that shares an emerging consensus before a full standard is ready. It concentrated on emergency intervention systems and on driver assistance at automation levels 1 and 2, where a human driver is still expected to supervise.

Experience with the PAS, and the rapid growth of higher automation, led to the full International Standard ISO 21448:2022. Compared with the PAS, the 2022 edition widened the scope to all levels of driving automation, from 1 to 5 in the SAE J3016 sense, and gave much more guidance on validation, perception, machine learning, misuse and the activities needed after the feature reaches customers. A further revision is now in progress (see the edition note above), which tells you the field is still maturing.

What the standard covers

In plain terms, ISO 21448:2022 applies to intended functionalities where good situational awareness is essential to safety and where that awareness comes from complex sensors and processing algorithms. Typical examples are emergency braking, adaptive cruise control, lane keeping and lane centring, automated parking, traffic-jam pilots and fully automated driving systems in series-production road vehicles (mopeds are excluded). It considers two broad sources of insufficiency:

gaps in the specification of the intended functionality at vehicle level (the feature was told to do the wrong thing, or nothing at all, in some situation), and
gaps in the specification or performance of the electric and electronic elements that implement it (a camera that cannot see far enough in rain, a classifier that confuses two kinds of object).

It also covers reasonably foreseeable misuse: ways people will predictably use the feature that its designers did not intend, such as a driver who stops watching the road because lane centring feels reliable. Remote operation and communication with back-office systems that could affect safety are in view as well.

What it deliberately leaves to others

ISO 21448 is clear about its boundaries, and knowing them prevents a lot of confusion:

Hazards caused by faults in hardware or software are handled by ISO 26262.
Hazards caused by malicious attacks are handled by cybersecurity engineering, mainly ISO/SAE 21434.
Hazards caused directly by the technology itself, such as eye damage from a laser emitter, and classic physical hazards such as electric shock, fire, heat or toxic release, are out of scope unless they come directly from the intended functionality.
Deliberate abuse that clearly violates the intended use of the feature is out of scope; foreseeable, non-deliberate misuse is in scope.
Functions of established systems for which well-trusted design, verification and validation measures already exist, such as dynamic stability control or airbags, are not the target of the standard.

Figure 1 – Where SOTIF sits: hazards with no fault and foreseeable misuse belong to ISO 21448, faults to ISO 26262 and attacks to ISO/SAE 21434.

Figure 1 is the single most useful picture to keep in mind. When a hazardous behaviour is found, ask what caused it. If something broke, it is functional safety. If someone attacked the system, it is cybersecurity. If the system did exactly what it was built to do and that was not good enough, or if a person used it in a predictable but unintended way, it is SOTIF. Real projects need all three, and the same hazard (say, unwanted hard braking) can have causes in more than one box.

Lesson 2 – Key concepts and vocabulary

SOTIF has its own vocabulary, partly borrowed from ISO 26262. The definitions below are explained in our own words; the standard's Clause 3 holds the official wording.

Intended functionality – the behaviour the feature is specified to deliver, for example "keep the vehicle centred in its lane on motorways up to a stated speed".
SOTIF – the absence of unreasonable risk caused by hazards that result from functional insufficiencies. "Unreasonable" means unacceptable according to valid societal and moral standards, the same idea ISO 26262 uses; zero risk is not the goal.
Functional insufficiency – the umbrella term for a weakness of the intended functionality. It has two flavours, defined next.
Insufficiency of specification – the specification is incomplete or wrong for some situation. Example: the lane-keeping specification never said what to do where lane markings split at a motorway exit, so the software follows the wrong line.
Performance insufficiency – a limit of technical capability: the sensor, algorithm or actuator cannot do well enough what it was specified to do. Example: the camera's detection range drops sharply in heavy rain.
Triggering condition – a specific condition in a scenario that starts a system reaction leading to hazardous behaviour (or to a failure to prevent, detect or mitigate foreseeable misuse). Low sun, tar seams that look like lane markings, a bridge that reflects radar, and an unusual vehicle shape are typical triggering conditions.
Hazardous behaviour – the vehicle-level behaviour that can contribute to harm, such as unwanted full braking, missing braking, or a steering movement out of the lane.
Hazard and hazardous event – a hazard is a potential source of harm; a hazardous event is the combination of a hazard with an operational situation, such as unwanted braking while a truck follows closely.
Scenario and scene – a scene is a snapshot of the environment and the actors in it; a scenario is a sequence of scenes over time, including the actions of the vehicle and other road users. SOTIF analysis and testing are built around scenarios.
Operational design domain (ODD) – the conditions under which a feature is designed to work: road types, speeds, weather, lighting, regions and so on. Restricting the ODD is one of the main ways to reduce SOTIF risk.
Reasonably foreseeable misuse – use of the feature in a way the designer did not intend but which results from predictable human behaviour. Direct misuse is the person's own action (for example, enabling the feature on a road type it was not designed for); indirect misuse is a wrong reaction that the system's behaviour or interface encourages (for example, over-trust because the system rarely complains).
Acceptance criterion – the criterion that says what level of residual risk counts as not unreasonable, for a hazard or hazardous behaviour. It may be qualitative or quantitative.
Validation target – a concrete value used to argue that the acceptance criterion is met, for example a maximum rate of a hazardous behaviour per hour of driving that testing must demonstrate.
Residual risk – the risk that remains after all measures have been applied. SOTIF is achieved when residual risk is shown to be below the acceptance criteria.
Known and unknown scenarios – scenarios the team has already identified and analysed versus scenarios nobody has thought of yet. Both can be hazardous or harmless, which leads to the four areas explained in Lesson 3.

The cause–effect chain

The terms fit together in a chain. A triggering condition in a scenario activates a functional insufficiency. The insufficiency produces a wrong output somewhere in the sense–plan–act pipeline, which becomes a hazardous behaviour at vehicle level. If the scenario contains people or vehicles who can be hurt and nobody can control the situation, the hazardous behaviour becomes a hazardous event and then harm. Every SOTIF measure works by breaking one of these links: avoiding the triggering condition (for example through ODD limits), removing or reducing the insufficiency (better sensors, better algorithms, a better specification), stopping the wrong output from reaching the actuators (plausibility checks, sensor fusion), or making the situation controllable (driver warnings, a gentle rather than full braking response).

Figure 2 – The SOTIF cause–effect chain: a triggering condition activates an insufficiency that can end in harm unless a link is broken.

Two things in Figure 2 deserve emphasis. First, the same insufficiency can stay hidden for millions of kilometres and appear only when the right triggering condition shows up, which is why SOTIF is so focused on scenarios rather than on components. Second, misuse enters the chain at the level of the situation: an inattentive driver can turn a mild, controllable system behaviour into an uncontrollable event, so the design of warnings, driver monitoring and handover is part of SOTIF work.

Lesson 3 – Structure of the standard

ISO 21448:2022 is a long document. Its normative part runs from Clause 1 to Clause 13, and it is followed by large informative annexes full of guidance and examples. The clause titles below are public; the descriptions are summaries in our own words.

Introductory clauses 1 to 4

Clause 1 Scope – which features and hazards are in and out (Lesson 1).
Clause 2 Normative references – the documents the standard relies on, chiefly the ISO 26262 vocabulary.
Clause 3 Terms and definitions – the vocabulary from Lesson 2 and many more terms.
Clause 4 Overview and organization of SOTIF activities – the principles of SOTIF, how to use the document, and how SOTIF activities are managed alongside other processes. It introduces the scenario categories and the overall activity flow.

The activity clauses 5 to 13

Each activity clause follows the same pattern: objectives, general explanation, the activities themselves and a list of work products (the documented results). That repeated pattern makes the standard easier to navigate once you know it.

Clause 5 Specification and design – describe the intended functionality, the system design and architecture, and known performance limits with their countermeasures. This becomes the input to every later analysis.
Clause 6 Identification and evaluation of hazards – find the hazardous behaviours, evaluate the risk of the resulting hazardous events, and specify acceptance criteria for residual risk.
Clause 7 Identification and evaluation of potential functional insufficiencies and potential triggering conditions – analyse where the system can fall short and what can trigger it, then estimate whether the system's response to those triggers is acceptable.
Clause 8 Functional modifications addressing SOTIF-related risks – improve the system, restrict it, hand authority to the driver, or address misuse; then feed the changes back into the specification.
Clause 9 Definition of the verification and validation strategy – plan integration and testing, including the validation targets and how they will be demonstrated.
Clause 10 Evaluation of known scenarios – verify sensing, planning algorithms, actuation and the integrated system against the known scenarios, and evaluate the residual risk they leave.
Clause 11 Evaluation of unknown scenarios – search for scenarios nobody identified and evaluate the residual risk from them.
Clause 12 Evaluation of the achievement of the SOTIF – judge, with defined methods and criteria, whether the evidence is enough, and make a recommendation on SOTIF release.
Clause 13 Operation phase activities – observe the feature in the field, and evaluate and resolve SOTIF issues found after release.

The informative annexes

The annexes are where most practitioners spend their time, because they show how to do the work:

Annex A, general guidance – examples of structuring a SOTIF argument with Goal Structuring Notation (GSN), an explanation of how SOTIF and ISO 26262 interact, and simplified application examples.
Annex B, scenario and system analyses – methods for deriving misuse scenarios, building scenario factors, adapting classic safety analyses to find triggering conditions, and applying STPA (System-Theoretic Process Analysis) to driver assistance and automated driving.
Annex C, verification and validation – the purpose of a V&V strategy, how validation targets can be derived, perception testing, scenario parameterization and sampling, and ways to reduce the amount of validation driving.
Annex D, specific aspects – driving policy specification, implications of machine learning, maps, vehicle-to-everything (V2X) communication, perception performance targets and sensor limitations, and over-the-air software updates.

The four scenario areas

Clause 4 introduces a simple model that underpins the whole standard. Every scenario the feature could meet falls into one of four areas, depending on two questions: has the team identified it (known or unknown), and does the feature behave hazardously in it (hazardous or not)?

Area 1, known and not hazardous – scenarios that have been analysed and in which the feature behaves acceptably. This is where you want as much of the world as possible.
Area 2, known and hazardous – scenarios the team has found that still lead to hazardous behaviour. They must be fixed or shown to carry acceptable residual risk.
Area 3, unknown and hazardous – the dangerous blind spot: problems nobody has found yet. You cannot list them, but you can search for them and estimate how much risk could remain there.
Area 4, unknown and not hazardous – situations nobody analysed, but which happen to be harmless. They need no action, though discovering them still builds confidence.

The aim of SOTIF is to move scenarios out of Area 3 by discovering them (they become Area 2), then out of Area 2 by modifying the system (they become Area 1), and finally to argue that what may remain in Areas 2 and 3 is small enough to accept. Clauses 10 and 11 map neatly onto this picture: Clause 10 evaluates the known areas, Clause 11 targets the unknown ones.

Lesson 4 – How it works in practice

SOTIF is not a single analysis done once; it is an iterative loop that runs alongside development and continues after launch. Figure 4 shows the main flow.

Figure 4 – The SOTIF activity flow from ISO 21448 clauses 5 to 13, with feedback loops whenever residual risk is not yet acceptable.

Step 1 – Specify the function and its limits (Clause 5)

Everything starts with a good description of the intended functionality: what the feature does, in which ODD, with which sensors and actuators, how it interacts with the driver, and what it is not designed to do. The team also records known performance limits of each element (for example, the radar's poor ability to separate stationary objects from road infrastructure) and the countermeasures already planned. A vague specification produces vague analyses, so this step deserves time.

Step 2 – Identify and evaluate hazards (Clause 6)

Next, the team identifies the hazardous behaviours the feature could show at vehicle level, such as unwanted braking, insufficient braking, unwanted steering or a late takeover request, and combines them with relevant situations to form hazardous events. The method is close to the hazard analysis in ISO 26262, and severity and controllability are estimated in the same way. There is an important difference, though: SOTIF does not assign an ASIL (Automotive Safety Integrity Level) and does not use exposure in this evaluation. Instead, the question is whether the hazardous event could cause harm and whether it would be generally controllable. If evidence shows that it cannot cause harm or that typical drivers and other road users can control it, no further SOTIF measures are needed for it; otherwise it needs acceptance criteria. Exposure comes back later, when validation targets are derived.

The acceptance criteria for residual risk are set here. They express what "not unreasonable" means for this feature. The standard lists several recognised ways to justify quantitative criteria, including comparison with human driving performance (often called a positive risk balance), the ALARP principle (as low as reasonably practicable), the French railway principle GAMAB (globally at least as good as an existing system) and MEM (minimal endogenous mortality). A qualitative criterion can also be valid, especially for simpler features. Choosing and justifying the criterion is a key decision that engineering, management and often the carmaker's legal and product-safety teams must agree on.

Step 3 – Find insufficiencies and triggering conditions (Clause 7)

Now the team asks: where can the sense–plan–act chain fall short, and what in the world can provoke it? Typical sources of triggering conditions include weather and lighting, road geometry and surface, infrastructure (tunnels, bridges, guard rails, construction zones), other road users and their behaviour, unusual objects, and the vehicle's own state (dirty sensors, heavy load). Clause 7 expects a systematic analysis using expert knowledge plus inductive, deductive or exploratory methods. In practice teams adapt familiar techniques, such as an FMEA-style table per sensor, fault-tree-style analysis starting from a hazardous behaviour, or STPA (Annex B), and combine them with data from earlier products and road tests.

For each relevant triggering condition, the team estimates whether the system's response is acceptable. If it is, the analysis is documented. If it is not, or if the uncertainty is too high, the loop goes to Clause 8.

Step 4 – Modify the function (Clause 8)

Clause 8 groups the possible measures into a few families:

Improve the system – better or additional sensors, sensor fusion that cross-checks camera and radar, improved algorithms, retrained machine-learning models with better data, plausibility checks before acting.
Restrict the functionality – narrow the ODD (only on motorways, only below a speed, not in heavy rain), reduce the authority of the function (gentler braking, limited steering torque), or degrade gracefully when the system knows its perception is poor.
Hand over authority – make the driver responsible earlier and more clearly, with timely and understandable takeover requests.
Address reasonably foreseeable misuse – driver monitoring, clear human–machine interface (HMI) design, user information, and preventing activation outside the ODD.

Every modification changes the specification, so the results flow back to Clause 5 and the analyses are updated. This feedback is the heart of SOTIF: the loop between Clauses 5 and 8 repeats until the known risks are acceptable.

Step 5 – Plan verification and validation (Clause 9)

Verification checks that the system meets its specification; validation checks that the specified behaviour is actually safe enough in the real world. The V&V strategy defines which methods will produce which evidence, with what coverage, and against which validation targets. Methods include requirement-based tests, scenario-based simulation, hardware-in-the-loop (HIL) and software-in-the-loop (SIL) testing, test-track trials, open-road driving, and analysis of recorded data. The strategy should explain why the chosen effort is enough for each target.

A validation target often has a statistical side. As an illustration (not a value from the standard): if a team must show that unwanted full braking happens less often than once per 100,000 hours of driving, and the event is rare and random, then observing zero such events in roughly 300,000 hours of representative driving supports that claim with about 95 % confidence. This "rule of three" style reasoning shows why pure road testing quickly becomes impractical for demanding targets, and why the standard puts so much weight on simulation, scenario sampling and techniques for reducing validation effort (Annex C).

Step 6 – Evaluate known and unknown scenarios (Clauses 10 and 11)

Clause 10 works through the known scenarios. It verifies the sensing part (does perception detect and classify correctly under the triggering conditions?), the planning algorithms (does the decision logic react correctly to good and imperfect inputs?), actuation (do brakes and steering respond as required?) and the integrated system, and it evaluates the residual risk left by the known hazardous scenarios.

Clause 11 is about the unknown. Because you cannot test what you do not know, the methods are exploratory: long-duration driving in varied regions and conditions, randomised or stochastic simulation that combines scenario parameters in new ways, testing at the edges of the ODD, analysis of field data from previous products, and recording "near misses" where the system came close to misbehaving. Each new hazardous scenario found moves from Area 3 to Area 2 and goes back through Clauses 7 and 8. The evidence also supports an estimate of the residual risk that may remain in Area 3.

Step 7 – Decide on release (Clause 12)

Clause 12 brings the evidence together. The team evaluates whether the acceptance criteria and validation targets are met, whether the known and unknown scenario evaluations are convincing, and whether any open issues are acceptable. The output is a recommendation on SOTIF release. In practice the answer is not always a simple yes or no: a team may, for example, recommend release only with a narrower ODD while further evidence is collected. Many organisations present this evaluation as a structured SOTIF argument, often drawn in GSN as Annex A suggests, with claims supported by evidence.

Step 8 – Watch the field (Clause 13)

Release is not the end. Vehicles meet situations no test fleet saw. Clause 13 asks the organisation to define what to observe in the field (for example, unusual interventions, driver takeovers, customer complaints, accident data, data from connected vehicles), and to run a process that evaluates each SOTIF issue and resolves it, possibly by an over-the-air update or a change to the ODD. Field monitoring is therefore part of the safety argument, not just customer service.

Roles and work products

The standard does not prescribe job titles, but projects usually involve a function owner or system architect who owns the specification, perception and planning specialists, a validation team, a SOTIF or safety manager who plans and tracks the activities, and an independent reviewer or assessor. Clause 4 expects SOTIF activities to be planned and managed together with functional safety and quality management; many companies run a combined safety plan. Typical work products include the functional specification with ODD, the hazard analysis and acceptance criteria, the triggering-condition analysis, the list of functional modifications, the V&V strategy and reports, the residual-risk evaluation, the release recommendation and the field-monitoring plan.

Lesson 5 – Assessment, certification and compliance

Guidance, not a certification scheme

ISO 21448 describes objectives, activities and work products; it does not define a certification scheme, and ISO itself does not certify products or companies. There is no official "ISO 21448 certificate" issued by ISO. When people talk about SOTIF compliance, they mean that an organisation can show, with evidence, that it has carried out the activities appropriately and that the residual risk of its feature is acceptable.

Several things make this harder than with many management-system standards. Much of ISO 21448:2022 is written as guidance, the standard allows qualitative as well as quantitative evaluation, and the right depth of work depends on the feature: a simple warning function needs far less than a Level 4 automated driving system. Two companies can therefore both claim to follow SOTIF while producing very different amounts of evidence. Judgement and transparency matter.

Who checks the work

Internal reviews and assessments – most carmakers and large suppliers have safety assessment functions, independent of the development team, that review SOTIF work products and the release argument, often in the same process used for ISO 26262 confirmation measures.
Customers in the supply chain – a carmaker typically asks its suppliers for SOTIF evidence for the elements they deliver (for example, perception performance data and known limitations of a camera system) and agrees in a contract who does which activities.
Third-party assessors – independent technical service and testing organisations offer SOTIF process and product assessments and issue their own statements or certificates. These are private schemes; their value depends on the assessor's competence and on what exactly was assessed.
Personnel training – training providers offer courses and personal certificates for SOTIF engineers; again, these are not issued by ISO.

What an assessor looks for

A competent review asks questions such as: Is the ODD clearly defined and enforced? Were hazards identified systematically, including misuse? Are the acceptance criteria justified, and are the validation targets traceable to them? Were triggering conditions searched for with more than one method? Is there evidence for each validation target, with a rationale for test effort and coverage? How was the unknown space explored, and what is the estimate of remaining risk? Are open issues recorded with a decision? Is there a working field-monitoring process?

Regulation and type approval

ISO 21448 is a voluntary standard. However, regulators increasingly expect manufacturers of driver-assistance and automated-driving features to document their safety concept, validation and in-use monitoring. For example, the UNECE regulation on automated lane keeping systems (UN R157) requires manufacturers to provide documentation of their safety approach, which approval authorities audit. Standards such as ISO 21448 and ISO 26262 are commonly used to structure that evidence, though using them does not by itself guarantee approval. Product liability is another driver: a documented, state-of-the-art SOTIF process helps show that the manufacturer took reasonable care.

Lesson 6 – Worked example: emergency braking at a Tier-1 supplier

To tie everything together, follow a fictional company, Northlake Mobility, a Tier-1 supplier developing an automatic emergency braking (AEB) function for a carmaker's new compact car. The system uses a front camera and a front radar. The carmaker owns the vehicle-level safety argument; Northlake owns the AEB function and its sensors. All numbers below are illustrative.

1. Specification and design

The team writes the intended functionality: warn the driver and then brake automatically to avoid or mitigate collisions with vehicles, pedestrians and cyclists ahead, at speeds from walking pace up to motorway speed, in daylight and at night, in dry and wet conditions. The ODD excludes off-road use and snow-covered roads, and the function is inactive while reversing. Known performance limits are recorded: camera degradation in low sun, heavy rain and darkness without street lights; radar difficulty with stationary metal objects and overhead structures; limited classification of unusual vehicles such as car transporters.

2. Hazards and acceptance criteria

Two main hazardous behaviours are identified. First, unwanted braking: the system brakes hard when there is no obstacle, which could cause a rear-end collision with a following vehicle. Second, missing or insufficient braking when a collision threat exists. The second is mainly a performance question for an AEB function that supports, but does not replace, an attentive driver, so it is judged largely controllable as long as the driver stays responsible; the team still sets performance requirements and checks the driver interaction. Unwanted hard braking at speed with a close follower, however, is not generally controllable by the following driver and can cause serious harm, so it needs an acceptance criterion.

The carmaker and Northlake agree that unwanted full braking events must be rarer than a rate derived from human-driving accident statistics for comparable rear-end collisions, with a margin. From that criterion, and using data on how often a close follower is present, they derive a validation target: fewer than one unwanted full-braking event per a stated large number of operating hours.

3. Insufficiencies and triggering conditions

The team runs workshops with radar, camera and planning experts, applies an adapted FMEA to each sensor's output, and uses STPA on the driver–system interaction. They also mine recordings from the previous AEB generation. The resulting list of triggering conditions includes metal plates and drain covers, bridges and overhead signs, tunnel entrances with sudden brightness change, low sun, spray from trucks in rain, parked cars at the road edge on bends, and a pedestrian partly hidden by a parked van. For indirect misuse, they consider drivers who start to rely on AEB and follow too closely.

4. Functional modifications

The analysis shows that the radar alone triggers too many false hard-braking requests near metal infrastructure. Northlake changes the design: full braking now requires confirmation by both camera and radar, while radar-only detection may trigger only a warning and a partial pre-brake. When the camera reports low confidence (for example, low sun), the function reduces its braking authority and informs the driver. The HMI is reviewed so that the warning is clear and the manual states the system's limits. These changes update the specification, and the hazard and triggering-condition analyses are repeated.

5. V&V strategy and known scenarios

The V&V strategy combines several layers. Perception performance is tested against labelled recordings covering each triggering condition. The decision logic is tested in simulation with injected perception errors. Braking response is verified on a test track with soft targets. The integrated system is tested at proving grounds for the standard collision scenarios. For unwanted braking, Northlake replays a large library of recorded real-world driving through the new software on HIL benches, counting any false hard-braking decisions.

6. Exploring the unknown

To search Area 3, Northlake and the carmaker run a test fleet in several countries and seasons, with the new software in "shadow mode": it computes braking decisions without acting on them, and every decision that would have braked is logged and reviewed. Randomised simulation varies speed, road curvature, object types and weather combinations. During this phase the team discovers a new triggering condition: reflective road-edge posts in one market, combined with a sharp bend, produce a ghost target. It moves into Area 2, the tracking logic is adjusted, and the analysis loop runs again.

7. Release decision and field monitoring

At the end, the evidence shows the validation target for unwanted braking is met with the agreed confidence, the known triggering conditions are handled or accepted with rationale, and the fleet campaign has found no further hazardous scenarios in its final stage. The SOTIF argument recommends release. The carmaker's field-monitoring plan then collects anonymised data on AEB interventions and driver overrides from connected vehicles. Months later, monitoring shows an unusual cluster of interventions near a new type of tollbooth gantry. The issue is analysed, a software update is tested and deployed over the air, and the case is recorded in the SOTIF records.

Figure 5 – The operation-phase loop in the worked example: field data reveals a new trigger, which is analysed, fixed and deployed.

Notice how the example used every part of the standard: a clear specification with ODD, a hazard analysis that separated controllable from uncontrollable behaviour, a justified acceptance criterion and derived validation target, systematic and data-driven search for triggering conditions, design changes of several kinds, layered V&V, active exploration of unknowns, a release decision and a working field loop.

Lesson 7 – Relationship to other standards and frameworks

SOTIF never stands alone. A modern vehicle feature is usually developed under several standards at once, each answering a different question. The table summarises the most important neighbours.

Standard or framework	Main question it answers	How it relates to ISO 21448
ISO 26262 (road vehicles functional safety, current edition 2018; a third edition is under development)	Can faults in hardware or software cause unsafe behaviour, and are they controlled?	Complementary. Same vocabulary and similar hazard analysis; SOTIF covers fault-free hazards. Annex A of ISO 21448 explains the interaction.
ISO/SAE 21434 (road vehicles cybersecurity engineering, 2021)	Can attackers cause harm through the vehicle's systems?	Complementary. Malicious threats are out of SOTIF scope, but attacks on sensors can look like triggering conditions, so analyses should be aligned.
ISO/PAS 8800 (road vehicles safety and artificial intelligence, 2024)	How do we develop and assure AI and machine-learning elements in safety-related vehicle systems?	Builds on both ISO 26262 and ISO 21448; goes deeper into data, training and AI-specific insufficiencies than SOTIF's machine-learning annex.
ISO/TS 5083 (safety for automated driving systems, 2025)	How is an automated driving system designed, verified and validated as safe overall?	Uses SOTIF and functional safety as building blocks within a wider safety case for automated driving.
ISO 34502 (scenario-based safety evaluation framework for automated driving systems, 2022)	How should test scenarios for automated driving be structured and selected?	Supports SOTIF Clauses 9 to 11 with a scenario-based method for evaluation.
UL 4600 (evaluation of autonomous products)	Is the safety case of an autonomous product complete and convincing?	Goal-based safety-case standard; often used together with ISO 21448 to structure and check the argument.
SAE J3016 (levels of driving automation)	What level of automation does a feature have, and who is responsible for what?	Provides the levels 1 to 5 used in SOTIF's scope; it is a taxonomy, not a safety process.

A practical way to remember the split: ISO 26262 asks "what if something breaks?", ISO/SAE 21434 asks "what if someone attacks?", and ISO 21448 asks "what if it works exactly as built, but the world is harder than we thought?". Many organisations run one combined hazard analysis and then route each cause to the right process, which avoids duplicated work and gaps between teams.

SOTIF also connects with process frameworks. Automotive SPICE assesses the capability of development processes, and quality management standards such as IATF 16949 cover production. Neither replaces a SOTIF argument, but good requirements management, traceability and configuration control make SOTIF evidence much easier to produce and trust.

Common pitfalls and best practices

Common pitfalls

Treating SOTIF as a document exercise. Writing a SOTIF report at the end of a project, after the design is frozen, misses the point: the loop between analysis and modification only works early.
Confusing SOTIF with functional safety. Assigning ASILs to SOTIF hazards, or asking "which component failed?", leads teams away from performance limits and specification gaps.
A vague ODD. If the conditions of use are not defined and enforced, every analysis and validation target rests on sand.
Relying only on mileage. Driving many kilometres without a strategy may never meet the rare triggering conditions that matter, and cannot reach demanding targets in practice.
Ignoring the unknown. A report that covers only known scenarios, with no exploration of Area 3 and no estimate of remaining risk, is incomplete.
Forgetting the human. Driver over-trust, confusing warnings and late takeover requests cause many SOTIF hazards, yet HMI and misuse are often analysed last.
Stopping at release. Without field monitoring and a working issue-resolution process, new triggering conditions in the fleet go unnoticed.

Best practices

Start with the specification and ODD, and revisit them every time a modification is made.
Agree acceptance criteria early with the carmaker, management and product-safety experts, and trace every validation target back to them.
Use several methods to find triggering conditions (expert workshops, adapted FMEA or fault trees, STPA, data from earlier products and fleets) and keep a living catalogue.
Combine evidence layers: simulation, HIL and SIL, test tracks, open-road driving and recorded data, each chosen for what it shows best.
Explore the unknown deliberately with shadow-mode fleets, randomised simulation and testing at the ODD boundary, and record near misses.
Align with ISO 26262 and ISO/SAE 21434 through a shared hazard analysis and clear interfaces between teams.
Write the SOTIF argument as you go, for example in GSN, so gaps in evidence become visible early.
Plan field monitoring before launch, including what data to collect, who reviews it and how fixes are deployed.

Summary and key takeaways

ISO 21448:2022 (SOTIF) addresses hazards that arise when a sensing-based vehicle feature works as built but its specification or performance is insufficient, and hazards from reasonably foreseeable misuse.
Faults belong to ISO 26262 and malicious attacks to ISO/SAE 21434; the three standards complement each other.
The core chain is triggering condition, functional insufficiency, hazardous behaviour, hazardous event and harm; every measure breaks one link.
The four scenario areas guide the work: discover the unknown hazardous scenarios, fix the known ones, and argue that what remains is acceptable.
Clauses 5 to 13 form an iterative flow: specify, analyse hazards, analyse triggers, modify, plan V&V, evaluate known and unknown scenarios, decide on release, monitor the field.
Acceptance criteria define what residual risk is not unreasonable; validation targets turn them into measurable evidence goals.
There is no ISO certificate for SOTIF; compliance is shown through evidence, reviewed internally, by customers or by third-party assessors.
The 2022 edition is current; a revision is under development, so watch for the second edition.

Reflection questions

Pick a driver-assistance feature in a car you know. Describe one hazard it could cause with no fault at all, and name the triggering condition and the insufficiency behind it.
For the same feature, how would you define its ODD, and which part of that definition would you most want the system to enforce automatically?
Your team has driven a large distance with no hazardous behaviour observed. What would you still need to argue before claiming that the residual risk in unknown scenarios is acceptable?
When would you prefer to restrict a function rather than improve its sensors or algorithms? Give an example and the trade-offs for the driver.
If you were setting up field monitoring for an automated parking feature, which signals would you collect, and how would you decide that a pattern is a SOTIF issue?