SOTIF Analysis: [Function or system name]
The safety of the intended functionality (SOTIF) analysis for one
vehicle function that relies on sensing, perception, prediction or
decision algorithms, structured on ISO 21448:2022 (Road vehicles,
Safety of the intended functionality, first edition, June 2022). SOTIF
covers hazards that arise when the function works exactly as designed
but the design is not good enough for the situation: a camera that
cannot see in low sun, a classifier that has never met a certain
object, a driver who misreads what the system will do. Faults of the
E/E system are the subject of ISO 26262; cybersecurity threats belong
to ISO/SAE 21434. This file holds the specification, the hazard
evaluation, the triggering conditions and functional insufficiencies,
the modifications, the verification and validation strategy, the
evaluation of known and unknown scenarios, the release argument and
the field monitoring plan. Replace every [bracketed] value and every
row marked Example. This is a documentation format, not regulatory,
type-approval or legal advice: check the current official texts and
involve a qualified safety assessor.
Document control
| Field | Value |
|---|
| Document ID | [SOTIF-NNN] |
| Function | [Name, version, vehicle programme] |
| Automation level | [For example SAE J3016 level 0 warning, level 1 or level 2 assistance] |
| Related item definition and HARA | [HARA-NNN] |
| Software and calibration baseline | [Release tag, perception model version] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner | [@sotif-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
Approvals
| Role | Name | Decision | Date |
|---|
| SOTIF lead | [@name] | [Approved] | YYYY-MM-DD |
| Functional safety manager | [@name] | [Approved] | YYYY-MM-DD |
| Independent assessor | [@name] | [Reviewed] | YYYY-MM-DD |
| Programme or release owner | [@name] | [Approved] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: specification and hazard evaluation |
| 0.5 | YYYY-MM-DD | [@name] | Example: Triggering condition analysis and V&V strategy added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Release argument approved for start of production |
Contents
- Scope and relationship to other safety work (cl. 4)
- Specification and design (cl. 5)
- Hazard identification, evaluation and acceptance criteria (cl. 6)
- Functional insufficiencies and triggering conditions (cl. 7)
- Functional modifications (cl. 8)
- Verification and validation strategy (cl. 9)
- Evaluation of known scenarios (cl. 10)
- Evaluation of unknown scenarios (cl. 11)
- Evaluation of the achievement of the SOTIF and release (cl. 12)
- Operation phase activities (cl. 13)
- Traceability matrix
- Glossary and references
0. Scope and relationship to other safety work (cl. 4)
The analysis covers hazardous behaviour of the function that results
from limits of its specification or of its performance, and from
reasonably foreseeable misuse by the driver or other road users. It does
not cover random hardware faults or systematic faults of the E/E
implementation; those stay in the ISO 26262 work products. Where a
hazard can arise both from a fault and from a performance limit, record
it in both analyses and cross-reference the IDs.
| Topic | Covered here | Covered elsewhere | Reference |
|---|
| Performance limits of sensors and perception | Yes | | Sections 3 and 6 |
| E/E faults and safety mechanisms | | ISO 26262 safety case | [FSC-NNN] |
| Machine-learning lifecycle (data, training, model assurance) | Partly | ISO/PAS 8800:2024 work products | [AI-SAFETY-NNN] |
| Cybersecurity threats | | ISO/SAE 21434 TARA | compliance/automotive-tara |
| Driver misuse and misunderstanding of the function | Yes | Human factors studies | Section 3.3 |
1. Specification and design (cl. 5)
1.1 Intended functionality
| Item | Value |
|---|
| Purpose | Example: Reduce the severity of, or avoid, front-to-rear collisions with vehicles, pedestrians and cyclists by warning the driver and braking automatically |
| Driver role | Example: Driver remains responsible at all times; the function intervenes only when a collision is imminent |
| Activation and deactivation | Example: Active by default above 5 km/h at every ignition cycle; the driver can switch it off in the settings menu |
| Actuation authority | Example: Partial braking up to 4 m/s^2, full braking up to 9 m/s^2 |
| Warnings | Example: Visual and acoustic forward collision warning 1.6 s before predicted impact |
1.2 Operational design domain and use conditions
| Dimension | Inside the specification | Outside or degraded |
|---|
| Speed | Example: 5 to 160 km/h for vehicles, 5 to 60 km/h for pedestrians and cyclists | Above these speeds the function warns only |
| Road types | Example: All public roads | Off-road, car parks with ramps (reduced performance documented) |
| Light | Example: Daylight, dusk, night with headlamps | Direct low sun into the camera |
| Weather | Example: Dry, light to moderate rain | Heavy snow covering the radar fascia |
| Targets | Example: Passenger cars, trucks, motorcycles, adult and child pedestrians, cyclists | Animals, debris, crossing trains |
1.3 Architecture and known performance limits
| Element | Role | Known limit at design time | Source |
|---|
| Front camera (Example) | Object classification, lane geometry | Dynamic range limited in low sun and tunnel exits | Supplier data sheet [DS-CAM-NNN] |
| Front radar (Example) | Range and relative speed | Reflections from metal structures above the road | Radar test report [RT-NNN] |
| Fusion and threat assessment software (Example) | Combines tracks, predicts time to collision | Prediction assumes constant acceleration over 1.5 s | Design document [SWAD-NNN] |
| Brake system interface (Example) | Executes deceleration request | Build-up time 180 ms to full deceleration | Brake supplier specification |
2. Hazard identification, evaluation and acceptance criteria (cl. 6)
2.1 Hazardous behaviour and hazards
A hazardous behaviour is relevant to SOTIF unless every resulting hazard
is either controllable in general by the people involved or would cause
no harm. Record the reasoning for that decision in the last column, as
it decides whether the hazard enters the rest of the analysis.
| ID | Hazardous behaviour at vehicle level | Driving situation | Harm | Severity and controllability rationale | SOTIF-relevant? |
|---|
| HB-01 (Example) | Unintended full braking with no obstacle | Motorway, following traffic at 120 km/h | Rear-end collision by following vehicle | Following driver often cannot react in time, injuries possible; cross-reference the HARA event if also rated there | Yes |
| HB-02 (Example) | No braking for a crossing pedestrian | Urban road at night, 40 km/h | Pedestrian injured | Driver relied on the function and reacted late | Yes |
| HB-03 (Example) | Late braking for a stationary vehicle | Rural road, curve exit, 80 km/h | Front collision | Speed reduced but impact remains | Yes |
| HB-04 (Example) | Short warning with no obstacle | Any | Distraction | Controllable in general, no braking | No, recorded for comfort tracking |
2.2 Acceptance criteria for residual risk
Set a quantitative or qualitative criterion for each SOTIF-relevant
hazardous behaviour. Base it on a stated reference such as the
performance of human drivers, field data from comparable functions, or a
regulatory expectation, and document the reasoning. The standard does
not fix a number; the values below are illustrative.
| ID | Acceptance criterion | Basis | Validation target |
|---|
| AC-01 (Example) | Unintended braking above 5 m/s^2 occurs at a rate below 1 per 100,000 operating hours | Rate judged not to raise rear-end collision risk compared with traffic without the function, from internal accident study [ACC-STUDY-NNN] | 299,573 h with zero events at 95% confidence (section 5.2) |
| AC-02 (Example) | Pedestrian detection rate at least 95% across the night test catalogue in section 6 | Consumer test protocols and internal benchmark | Known scenario catalogue SC-10 to SC-24 |
| AC-03 (Example) | No increase of front collisions at curve exits compared with the previous generation in field data | Field monitoring baseline [FIELD-NNN] | Section 9 indicator KPI-03 |
3. Functional insufficiencies and triggering conditions (cl. 7)
3.1 Functional insufficiencies
| ID | Type | Insufficiency | Element | Linked hazardous behaviour |
|---|
| FI-01 (Example) | Performance insufficiency | Radar confirms an overhead sign gantry as an in-path stationary object | Radar, fusion | HB-01 |
| FI-02 (Example) | Performance insufficiency | Camera classifier misses pedestrians in dark clothing at night beyond 25 m | Camera, perception model | HB-02 |
| FI-03 (Example) | Specification insufficiency | Threat assessment ignores objects partly hidden at a curve exit until fully visible | Fusion, threat assessment | HB-03 |
| FI-04 (Example) | Specification insufficiency | Constant acceleration prediction misjudges a vehicle braking hard ahead | Threat assessment | HB-03 |
3.2 Triggering conditions
| ID | Triggering condition | Insufficiency triggered | Plausibility in the use domain | Evidence |
|---|
| TC-01 (Example) | Low metal gantry on a downhill motorway section | FI-01 | Frequent on certain road networks | Radar test drive log [LOG-NNN] |
| TC-02 (Example) | Pedestrian in dark clothing on an unlit road with oncoming headlamps | FI-02 | Common in winter months | Night test campaign [NT-NNN] |
| TC-03 (Example) | Parked vehicle directly after a sharp curve | FI-03 | Occasional on rural roads | Accident database query [ACC-NNN] |
| TC-04 (Example) | Lead vehicle brakes at above 8 m/s^2 | FI-04 | Rare | Naturalistic driving study [NDS-NNN] |
3.3 Reasonably foreseeable misuse
| ID | Misuse | Cause | Effect | Measure |
|---|
| MU-01 (Example) | Driver follows closely, expecting the function to brake | Over-trust after weeks without intervention | Late driver reaction in HB-03 | Owner manual wording, follow-distance warning (FM-03) |
| MU-02 (Example) | Driver covers the camera area with a phone holder | Lack of awareness | Degraded detection | Blockage detection and driver message (FM-04) |
3.4 Evaluation of the system response
For each pair of triggering condition and insufficiency, decide whether
the response of the function is acceptable against the criteria in
section 2.2. If it is not, a functional modification is needed (section
4); if it is, the pair moves into the verification and validation
strategy as a known scenario.
| Pair | Response acceptable? | Reasoning | Next step |
|---|
| TC-01 / FI-01 (Example) | No | Braking events seen in test drives | FM-01 |
| TC-02 / FI-02 (Example) | No | Detection below AC-02 target | FM-02 |
| TC-03 / FI-03 (Example) | Yes, to be confirmed | Simulation shows speed reduction before impact | Known scenario SC-30 |
| TC-04 / FI-04 (Example) | Yes, to be confirmed | Warning still precedes impact | Known scenario SC-31 |
4. Functional modifications (cl. 8)
| ID | Modification | Type | Addresses | Side effects checked | Status |
|---|
| FM-01 (Example) | Require camera confirmation before full braking on radar-only stationary objects at above 60 km/h | Performance improvement | TC-01 / FI-01 | Reduced reaction for real stationary vehicles in fog, added to section 3.2 as a new triggering condition for analysis | Implemented in [release] |
| FM-02 (Example) | Retrained perception model with night pedestrian data set, low-light camera mode | Performance improvement | TC-02 / FI-02 | Model change also assessed under ISO/PAS 8800 process | Implemented |
| FM-03 (Example) | Follow-distance indicator and owner manual explanation of limits | Human-machine interface | MU-01 | Distraction review | Implemented |
| FM-04 (Example) | Camera blockage detection that degrades to warning only and informs the driver | Restriction plus driver information | MU-02 | False blockage messages counted in field KPI-04 | Implemented |
5. Verification and validation strategy (cl. 9)
5.1 Methods
| ID | Method | Purpose | Scenarios | Coverage argument |
|---|
| VV-01 (Example) | Sensor-level bench and track tests | Verify sensor performance at known limits | SC-01 to SC-09 | One test per specified limit in section 1.3 |
| VV-02 (Example) | Scenario-based simulation with sensor models | Verify the decision logic over parameter ranges | SC-10 to SC-31 | Parameter sweeps on speed, offset, light and target type |
| VV-03 (Example) | Proving ground tests with soft targets | Verify the integrated system | Selected known scenarios | Highest-risk combinations from VV-02 |
| VV-04 (Example) | Open-road test fleet | Search for unknown scenarios and estimate unintended braking rate | All | Route mix matched to target market traffic statistics |
| VV-05 (Example) | Shadow mode in a customer fleet, function computes but does not brake | Estimate unintended braking rate at scale | All | Representative only if the fleet covers the operational design domain |
5.2 Validation target derivation
For acceptance criterion AC-01, the example uses a zero-failure test
argument based on a Poisson model: with a target rate lambda of 1 per
100,000 hours and a confidence of 95%, the hours needed with no event
observed are -ln(0.05) / lambda, about 3.0 / lambda.
| Quantity | Value (Example) |
|---|
| Target rate (lambda) | 1 x 10^-5 per hour |
| Confidence | 95% |
| Events allowed | 0 |
| Required hours | 299,573 h |
| Average speed assumed | 45 km/h |
| Equivalent distance | about 13.5 million km |
| Required hours if 1 event is allowed | 474,386 h |
Planned exposure: 95,000 h of open-road test fleet (VV-04) plus 210,000
h of shadow mode data (VV-05), a total of 305,000 h, which exceeds the
zero-event target. Record why the shadow mode data is representative
(regions, seasons, road types) and how events are labelled.
6. Evaluation of known scenarios (cl. 10)
| Scenario | Description | Method | Criterion | Result | Verdict |
|---|
| SC-25 (Example) | Overhead gantry, downhill, 120 km/h | VV-02, VV-04 | No braking above 5 m/s^2 | 0 events in 1,200 passes | Pass |
| SC-12 (Example) | Pedestrian in dark clothing, unlit road, oncoming headlamps, 40 km/h | VV-02, VV-03 | Detection rate at least 95% | 1,022 of 1,060 runs (1,000 simulated, 60 track), 96.4% | Pass |
| SC-30 (Example) | Parked vehicle after a sharp curve, 80 km/h | VV-02 | Impact speed reduced by at least 20 km/h | Mean reduction 27 km/h | Pass |
| SC-31 (Example) | Lead vehicle brakes at 9 m/s^2 from 100 km/h | VV-03 | Warning before impact, braking initiated | Warning at 1.4 s, braking at 1.1 s | Pass with note: below 1.6 s design value, analysed in FI-04 |
7. Evaluation of unknown scenarios (cl. 11)
| Activity | Exposure or volume (Example) | New scenarios found | Action |
|---|
| Open-road test fleet VV-04 | 95,000 h across 4 climate zones | 2 (tunnel exit glare, reflective road works barrier) | Added to the catalogue as SC-40 and SC-41 for evaluation in section 6 (rows not shown) |
| Shadow mode VV-05 | 210,000 h | 0 unintended braking events above 5 m/s^2 | None |
| Randomised simulation with mutated scenarios | 2 million generated scenarios | 1 (cyclist emerging behind a bus) | Added as SC-42 |
| Expert review of field events from the previous generation | 340 events reviewed | 0 new | None |
Total exposure for AC-01: 305,000 h with zero qualifying events, above
the 299,573 h target. Residual uncertainty: [state the regions, seasons
or road types that are under-represented].
8. Evaluation of the achievement of the SOTIF and release (cl. 12)
| Check | Result | Evidence |
|---|
| All SOTIF-relevant hazardous behaviours have acceptance criteria | [Yes / No] | Section 2.2 |
| All triggering conditions evaluated or modified | [Yes / No] | Sections 3 and 4 |
| Known scenarios pass their criteria | [Yes / No, with notes] | Section 6 |
| Unknown scenario exposure meets its target | [Yes / No] | Sections 5.2 and 7 |
| Residual limits disclosed to the driver | [Yes / No] | Owner manual [OM-ref], HMI specification |
| Field monitoring in place | [Yes / No] | Section 9 |
Release recommendation: [Release / Release with conditions / Do not
release], with reasoning. Conditions: [list]. Signed: [@sotif-lead],
YYYY-MM-DD; reviewed by [@assessor].
9. Operation phase activities (cl. 13)
| ID | Indicator | Source | Threshold for action | Owner | Review frequency |
|---|
| KPI-01 (Example) | Unintended braking events above 5 m/s^2 per 100,000 h | Fleet event data where the customer has agreed to data sharing | Any confirmed event triggers root cause analysis | [@name] | Monthly |
| KPI-02 (Example) | Customer complaints about phantom braking | Dealer and hotline reports | 3 complaints with the same road location | [@name] | Monthly |
| KPI-03 (Example) | Front collisions at curve exits | Accident and warranty data | Increase compared with baseline | [@name] | Quarterly |
| KPI-04 (Example) | Camera blockage messages per 1,000 h | Fleet data | Above design expectation | [@name] | Quarterly |
Privacy note: collect only the vehicle data needed for the indicators,
with the legal basis and retention set by the data protection team.
10. Traceability matrix
| Hazardous behaviour | Criterion | Insufficiency | Triggering condition | Modification | Scenarios | Verdict |
|---|
| HB-01 (Example) | AC-01 | FI-01 | TC-01 | FM-01 | SC-25, VV-04, VV-05 | Pass |
| HB-02 (Example) | AC-02 | FI-02 | TC-02 | FM-02 | SC-12 | Pass |
| HB-03 (Example) | AC-03 | FI-03, FI-04 | TC-03, TC-04 | FM-03 | SC-30, SC-31 | Pass with note |
11. Glossary and references
| Term | Working meaning in this file |
|---|
| Functional insufficiency | A weakness of the specification or of the performance of the function that can lead to hazardous behaviour without any fault |
| Triggering condition | A circumstance of the scenario that activates a functional insufficiency |
| Known and unknown scenarios | Scenarios already identified and analysed, versus scenarios not yet identified; each can be hazardous or not |
| Validation target | The amount of evidence (hours, distance, test cases) planned to show that an acceptance criterion is met |
| Shadow mode | Running the function in the background without actuation, to compare its decisions with real traffic |
| Reference | Edition or date | Use |
|---|
| ISO 21448, Road vehicles, Safety of the intended functionality | 2022 (first edition, June 2022; replaced ISO/PAS 21448:2019) | Activity structure and clause numbers |
| ISO 26262 series, Road vehicles, Functional safety | 2018 (second edition) | Faults, HARA link |
| ISO/PAS 8800, Road vehicles, Safety and artificial intelligence | 2024 (December 2024) | Machine-learning elements |
| ISO/SAE 21434, Road vehicles, Cybersecurity engineering | 2021 | Threats out of SOTIF scope |
| SAE J3016, levels of driving automation | [Edition applied] | Automation level vocabulary |
| EU example: Commission Implementing Regulation (EU) 2022/1426 (automated driving systems of fully automated vehicles) | Adopted 5 August 2022, check the consolidated text | Type-approval context for automated driving systems: https://eur-lex.europa.eu/eli/reg_impl/2022/1426/oj/eng |
| UK and US | [Applicable rules and guidance at the time of release] | UK: Automated Vehicles Act 2024 and its secondary legislation; US: NHTSA rules and guidance. Check the current official texts |
Standard and licence note
Structure aligned with ISO 21448:2022 (Road vehicles, Safety of the
intended functionality, first edition, published June 2022, current as
checked in October 2026; the ISO catalogue lists it as under revision,
with a working draft in preparation, so check for a new edition).
Clause numbers 4 to 13 are given for
orientation only. All wording, tables, IDs and the worked example are
original; no text, figure, table or definition is reproduced from the
standard. The acceptance criteria, rates and test results are fictional
examples, not recommended values. Check the current edition, any
amendment and the type-approval rules of your target markets before
use. This template is not regulatory, type-approval or legal advice:
check the current official texts and involve a qualified safety
assessor.