# 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.

<!--
Guidance: How to use this template
- One file per function (for example an automatic emergency braking
  function or a lane keeping function), kept alongside the ISO 26262
  safety case for the same item. Share the item definition and hazard
  list where you can, and link rather than copy.
- Work in the order of the standard's activity flow: specify (section
  1), evaluate hazards and set acceptance criteria (section 2), search
  for insufficiencies and triggering conditions (section 3), modify the
  function where needed (section 4), plan verification and validation
  (section 5), evaluate known and unknown scenarios (sections 6 and 7),
  argue release (section 8), monitor in the field (section 9). Expect
  to loop back several times.
- Clause numbers in headings point to ISO 21448:2022 for orientation.
  The wording here is original and does not reproduce the standard.
- The examples use a fictional camera and radar automatic emergency
  braking function, "KD-AEB2", from the fictional supplier Kestrel Drive
  Systems (the same fictional supplier as in the HARA template).
  Delete them.
- Related templates: hazard analysis and risk assessment
  (`compliance/iso-26262-hara`), software FMEA (`ops/fmea-software`),
  verification and validation plan (`quality/vv-plan`), automotive
  threat analysis and risk assessment (`compliance/automotive-tara`).
-->

## Document control

<!-- Guidance: Treat the SOTIF analysis as a controlled work product in the same configuration management system as the ISO 26262 work products. Record the software and calibration baseline it was performed on, because a change to a perception model or a threshold can invalidate the evaluation. -->

| 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

0. Scope and relationship to other safety work (cl. 4)
1. Specification and design (cl. 5)
2. Hazard identification, evaluation and acceptance criteria (cl. 6)
3. Functional insufficiencies and triggering conditions (cl. 7)
4. Functional modifications (cl. 8)
5. Verification and validation strategy (cl. 9)
6. Evaluation of known scenarios (cl. 10)
7. Evaluation of unknown scenarios (cl. 11)
8. Evaluation of the achievement of the SOTIF and release (cl. 12)
9. Operation phase activities (cl. 13)
10. Traceability matrix
11. Glossary and references

## 0. Scope and relationship to other safety work (cl. 4)

<!-- Guidance: State what this analysis covers and what it hands to other disciplines. Reviewers look for a clear boundary between SOTIF, functional safety and cybersecurity, and for a single owner of every shared hazard. -->

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 |

```mermaid
flowchart TD
  S["1 Specification and design"] --> H["2 Hazards and acceptance criteria"]
  H --> T["3 Insufficiencies and triggering conditions"]
  T --> D{"Response acceptable?"}
  D -->|No| M["4 Functional modifications"]
  M --> S
  D -->|Yes| V["5 V and V strategy"]
  V --> K["6 Known scenarios"]
  V --> U["7 Unknown scenarios"]
  K --> R{"8 Residual risk meets criteria?"}
  U --> R
  R -->|No| M
  R -->|Yes| O["9 Operation phase monitoring"]
  O -->|New issue found| H
```

## 1. Specification and design (cl. 5)

<!-- Guidance: Describe the function as built, not as marketed. The analysis is only as good as the description of what the function senses, decides and does, and under which conditions it is meant to work. A common pitfall is an operational design domain that says "all roads, all weather" while the camera is specified only for daylight. -->

### 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)

<!-- Guidance: Identify hazardous behaviour at vehicle level that the intended function could produce, evaluate whether it is relevant to SOTIF, and set acceptance criteria for the residual risk before any validation. Reuse the severity and controllability reasoning of the HARA where the hazard is the same, and say so. -->

### 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)

<!-- Guidance: This is the heart of SOTIF. Search systematically for weaknesses of the specification (the function was asked to do the wrong thing) and of performance (it cannot do the right thing well enough), and for the conditions that trigger them. Use guide words, past field data, sensor physics and expert workshops. A list that holds only weather conditions has usually missed perception, prediction and human-machine interaction causes. -->

### 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)

<!-- Guidance: Record each change made to reduce SOTIF risk: improving a component, restricting the function, handing control to the driver, or adding a measure that detects the triggering condition. After each modification, update sections 1 to 3; a fix often creates a new triggering condition. -->

| 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)

<!-- Guidance: Plan how you will show that the acceptance criteria are met, before running the campaigns. Justify each method and each target: simulation, test track, open road, replay of recorded data, shadow mode. A validation target without a stated confidence level and a stated assumption about representativeness will not survive review. -->

### 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)

<!-- Guidance: Show the results for each known potentially hazardous scenario, including the ones you judged acceptable in section 3.4. A pass without the measured value and the criterion next to it is not evidence. -->

| 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)

<!-- Guidance: Unknown hazardous scenarios are by definition not in your catalogue. Show the activities that try to reveal them (open-road driving, randomised simulation, expert review of rare events) and how anything found is moved into the known set. Report the exposure achieved against the target in section 5.2. -->

| 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)

<!-- Guidance: Pull the argument together: every SOTIF-relevant hazard has a criterion, every known scenario has a result, the unknown scenario search reached its target, and remaining limits are communicated to the driver. Use a structured argument (for example goal structuring notation) if your organisation does. -->

| 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)

<!-- Guidance: Define what is watched after start of production, who looks at it, how often, and what level of signal reopens the analysis. Over-the-air updates make this loop shorter: every model or threshold update needs an impact analysis against this file. -->

| 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

<!-- Guidance: One row per chain from hazardous behaviour to evidence. A reviewer should be able to start from any hazard and reach the verdict without searching. -->

| 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

<!-- Guidance: Define your own working terms in plain words and point to the standard for the normative definitions; do not copy those definitions. Record the editions and regulations you actually applied. -->

| 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.

Official text: ISO, purchase or licensed access:
https://www.iso.org/standard/77490.html (also available from national
standards bodies).

Template licence: MIT.