ISO 21448 — SOTIF (Safety of the Intended Functionality)
How SOTIF concepts for performance-limitation-driven hazards relate to NexoGraph requirements and scenario management.
ISO 21448:2022 (Road vehicles — Safety of the intended functionality) addresses a class of safety issues that fall outside the scope of ISO 26262. Where ISO 26262 targets failures caused by hardware faults or software errors, SOTIF targets hazardous behaviour that arises from the performance limitations of correctly functioning systems — particularly perception and decision systems in advanced driver assistance (ADAS) and automated driving (AD) applications.
SOTIF is especially relevant for systems that use sensors (camera, LiDAR, radar, ultrasonic), machine learning models, or sensor fusion, because these systems can behave safely in most conditions but encounter edge cases where their performance degrades to a hazardous level.
Core Concept: The SOTIF Space
The fundamental insight of SOTIF is the four-quadrant decomposition of operational scenarios:
| Quadrant | Description | Engineering goal |
|---|---|---|
| Known unsafe | Identified triggering conditions that produce hazardous behaviour | Eliminate or mitigate through functional improvements or safety mechanisms |
| Unknown unsafe | Hazardous conditions not yet identified — the residual risk | Minimize through extensive validation and coverage-driven testing |
| Known safe | Confirmed safe operating conditions | Define and validate the ODD |
| Unknown safe | Unidentified conditions that happen to be safe | Accept — these become known safe over time |
Key Concepts
| Concept | Definition |
|---|---|
| Intended functionality | The nominal behaviour the system is designed to perform under expected conditions |
| Performance limitation | An inherent constraint in the system's ability to sense, interpret, or respond — not a failure |
| Triggering condition | A scene, scenario, or environmental factor that exposes a performance limitation |
| Hazardous behaviour | Deviation from intended functionality that could cause harm in the absence of a fault |
| Operational Design Domain (ODD) | The specific conditions within which a system is designed to operate safely |
| Reasonably foreseeable misuse | User behaviour outside the ODD that the system must also handle or reject |
SOTIF Process
The SOTIF process is iterative: each validation pass shrinks the unknown unsafe quadrant by converting unknown conditions into known ones. Release requires that the residual unknown-unsafe risk is judged acceptable.
NexoGraph Alignment
| SOTIF concept | NexoGraph implementation |
|---|---|
| SOTIF safety goal | Requirement (reqCat: SAFETY) — derived from SOTIF analysis |
| Functional specification | Requirement (reqType: SYSTEM/SOFTWARE) under a performance constraint package |
| ODD definition | Package — coarsely captures system context; no formal ODD attribute set |
| Stakeholder (ODD authority / regulator) | Stakeholder (category: REGULATORY) |
| Hazardous behaviour reference | rationale field on Requirement — narrative only, no structured field |
| Performance requirement | Requirement (reqCat: PERFORMANCE) — captures measurable perception thresholds |
| Lifecycle state | Lifecycle service governs review and approval gates |
Gap Analysis
| Gap | SOTIF clause | Status |
|---|---|---|
| Triggering condition entity | §8 | Not modelled — triggering conditions have no first-class representation |
| ODD formal attributes | §5.3 | Gap — Package approximates scope but lacks structured ODD fields (speed range, weather, lighting, road type) |
| Scenario management | §8, §9 | Not in scope currently — scenario database requires a dedicated entity type |
| SOTIF-specific requirement attribute | §9.2 | No field linking a Requirement to its originating triggering condition |
| Residual risk acceptance record | §10 | Not modelled — safety case / risk acceptance artefact is planned |
| Validation coverage metric | §9.3 | Not modelled — requires scenario coverage tracking against ODD |
Relationship to ISO 26262
SOTIF and ISO 26262 are complementary, not overlapping:
| Aspect | ISO 26262 | ISO 21448 (SOTIF) |
|---|---|---|
| Trigger for harm | Hardware fault or software error | Performance limitation of correct functionality |
| Target systems | Any E/E system | Perception-dependent ADAS/AD systems |
| Primary tool | HARA + ASIL allocation | Triggering condition analysis + ODD validation |
| Artefact | FSR/TSR with ASIL | SOTIF safety goal with performance specification |
| Coverage measure | Fault coverage (DC, SPFM) | Scenario/ODD coverage |
For modern ADAS features, both standards apply simultaneously. NexoGraph can host requirements from both analyses; the traceability chain links SOTIF safety goals and ISO 26262 safety goals through the same requirement hierarchy.