SOTIF

In the previous blog post, we looked at the different layers of an operating scenario. In this blog post, we will look at the different abstraction levels, and why it matters for ISO 26262 HARA and SOTIF HARA. The Three Abstraction Levels of Operating Scenarios Each operating scenario can be described in 6 layers as described in the the previous blog post. In addition, each operating scenario can be described in 3 different abstraction levels. Functional scenarios - They are

Why Scenarios Need a Format You cannot test an automated driving function against "traffic." The real world offers an effectively infinite set of situations: every combination of road layout, weather, other vehicles, and split-second timing is its own test case. Scenario-based safety is the industry's answer to that problem, but it only works if scenarios are described in a structured, repeatable way. Without a common format, one engineer's "car cuts in ahead" is another's "a

In the previous blog post, we talked about what a SOTIF HARA is and what is the process to create one. This this blog post we talk about acceptance criteria for SOTIF. Acceptance Criteria: The New Discipline If "unreasonable risk" is the question, Acceptance Criteria (AC) is what makes the answer defensible. AC is the quantified definition of acceptable: a measurable threshold the system must demonstrably meet before its residual risk can be called reasonable. This is what se

Hazards that are not due to malfunctions Classical functional safety assumes something "failed". A sensor failed, a wire shorted, a software routine crashed. ISO 26262 is built around this idea: identify the malfunctions, judge how bad they'd be, and engineer against them. But consider a perception system that saw the road exactly as designed and still failed to recognize a stationary truck in dense fog. Nothing malfunctioned. Every component behaved to specification. The sys