SOTIF
Concept
Topic overview
Quick facts
SOTIF addresses hazards that occur without a fault: every component works as designed, yet the system still behaves hazardously because the design itself is insufficient for the situation.
Typical sources are sensor performance limitations (a camera blinded by low sun, a lidar confused by rain), algorithm weaknesses (a classifier that has never seen a person in a chicken costume), and edge-case scenarios outside what the developers anticipated.
It complements , which addresses hazards caused by system faults; a mature autonomy program runs both in parallel because a perception miss is not a malfunction in the 26262 sense but can be just as lethal.
organizes the problem as a scenario-space argument.
Scenarios are conceptually divided into known safe, known hazardous, unknown hazardous, and unknown safe, and the engineering goal is to shrink the hazardous regions: fix or mitigate the known hazardous scenarios, and argue through analysis, simulation, and field exposure that the residual unknown hazardous space is acceptably small.
Triggering conditions, the specific circumstances that turn a functional insufficiency into hazardous behavior, are the central analytical object.
SOTIF work products include scenario catalogs, triggering-condition and functional-insufficiency analyses, verification and validation strategies spanning simulation, closed course, and supervised field operation, and quantitative validation targets with the statistical rationale for the miles or hours accumulated.
The case for SOTIF
For any product that perceives and decides, ADAS, autonomous vehicles, AMRs, perception-based safeguarding, SOTIF is where the hardest and most expensive safety questions live, because you cannot test your way to safety against an open world by brute force alone.
The validation target question, how much evidence is enough, drives fleet size, simulation investment, and launch timelines, making SOTIF strategy a board-level economic issue. Regulators and standards such as increasingly expect an explicit SOTIF argument, and its absence is now a common blocker in autonomy due diligence.
SOTIF in practice
SOTIF activity flow (ISO 21448)
SOTIF work starts at concept alongside the : the team specifies the intended functionality and precisely, then systematically analyzes functional insufficiencies and triggering conditions, feeding a scenario catalog built from ODD analysis, field data, naturalistic driving studies, and accident databases.
Verification targets known scenarios via simulation and track testing; validation of the unknown space combines statistical field exposure with argumentation about scenario coverage. Residual risk criteria are defined up front, and field monitoring continues after release to detect emerging triggering conditions.
Assessors look for a defensible definition, systematic rather than anecdotal triggering-condition analysis, a validation target with statistical justification, and a working field feedback loop that updates the scenario catalog.
Where teams get SOTIF wrong
SOTIF and its standards
Assessors evaluate SOTIF against ISO 21448, addresses hazards from functional insufficiencies and foreseeable misuse in autonomous and driver-assistance systems.
UL 4600 sets the requirements that SOTIF work has to satisfy: safety case framework for fully autonomous products operating without human supervision.
SOTIF scenario quadrants
| Quadrant | Meaning | Objective |
|---|---|---|
| Known safe | Verified acceptable behavior | Maintain, grow this area |
| Known unsafe | Identified hazardous scenarios | Fix or restrict until acceptable |
| Unknown unsafe | Undiscovered hazardous scenarios | Reduce via exploration and field data |
| Unknown safe | Unverified but benign | Convert to known via validation |
Industries where SOTIF applies
SOTIF shapes how autonomous systems teams argue safety - autonomous mobile equipment, off-highway autonomy, and driverless platforms.
Ask our team about SOTIF
Ben TwomblyFounder & CEOLeads CSA's functional-safety, certification, and engineering programs for safety-critical products and organizations. His assessor-side background informs practical programs that connect standards, engineering work, and credible evidence.
Tom CyrPrincipal Safety Engineer, IFSPSupports industrial and rail functional-safety programs with safety analysis, requirements, lifecycle planning, and certification-readiness guidance.
Robert EllsworthSenior Safety EngineerSupports system-safety analysis, requirements, verification, and evidence development for safety-critical product and transportation programs.Terms related to SOTIF
How each connects to SOTIF:
ODD is the natural next concept after SOTIF; assessors expect teams to connect the two.
Safety Case is the natural next concept after SOTIF; assessors expect teams to connect the two.
Functional Safety is a concept of the same kind; teams comparing the two usually need both.
Hierarchy of Risk Reduction plays the same role in its domain that SOTIF plays here.
Safety Function is a concept of the same kind; teams comparing the two usually need both.
CENELEC Rail Standards plays the same role in its domain that SOTIF plays here.
Safety-Critical System is a concept of the same kind; teams comparing the two usually need both.
Reliability Engineering plays the same role in its domain that SOTIF plays here.