We often hear that “SOTIF is just different from functional safety,” suggesting that the ISO 21448:2022 standard is fundamentally distinct from the ISO 26262:2018 standard. While this is true, and ISO 21448 goes to great lengths to highlight these differences, there are still significant overlaps in their concepts. This is important because, to make Safety Of The Intended Functionality (SOTIF) effective, one must also ensure functional safety. Achieving this will involve extensive efforts in building functional safety argumentation and documentation, as well as accumulating expertise and knowledge. Fortunately, this foundation doesn’t need to be discarded as we transition to SOTIF.
In this blog, we will discuss how ISO 21448, Clause 6 parallels ISO 26262-3, Clause 6, and how ISO 21448, Clause 7 is an analog to ISO 26262-4, Clause 6.4.4. If you’re familiar with those ISO 26262 clauses, transitioning to SOTIF might not be as challenging as you might think.
Let’s begin by examining the most significant difference between the two standards: the definition of a “hazard”:
- Hazard (according to ISO 21448:2022, Clause 3.11):
potential source of harm caused by the hazardous behavior at the vehicle level
- Hazard (according to ISO 26262-3:2018, Clause 3.75):
potential source of harm caused by malfunctioning behavior of the item
Although these definitions may seem similar, the subtle change from “malfunctioning” to “hazardous” is significant, particularly from a safety development perspective. Let’s delve into both definitions to understand the differences.
Hazardous behaviors at the vehicle level include speeding, running red lights, aggressive lane changing, failing to signal a turn, driving too fast for weather conditions, improper passing, sudden braking, swerving, and more. These hazardous behaviors may or may not result in a hazardous event that could cause harm. For instance, running a red light at 2 am when no cars or people are around doesn’t create a hazardous event. In the context of ISO 21448, we refer to these “events” as “scenarios.”
Now, let’s take a moment to understand what malfunctioning behaviors are. In ISO 26262, we analyze each vehicle-level system (referred to as an “item”) and identify its functions and sub-functions. We then examine how they can malfunction, typically using a Hazard and Operability (HAZOP) study, incorporating common guidewords like “too much,” “too long,” “inversely,” “does not,” “unintentionally,” etc., to the function. For example, an electronic braking system might malfunction by not providing braking (“does not”) when requested/intended or unintentionally providing braking when not requested/intended. Malfunctioning behavior may or may not result in a hazardous event that could cause harm. For instance, if the braking system unintentionally provides (“too much” of) a braking force while the vehicle is parked at a grocery store, it doesn’t create a hazardous event. In the language of ISO 26262, we refer to these “events” as “operational situations.”
The relationship between hazards and harm for these two standards can be illustrated in the following two figures:


It is important to note that in both ISO 21448, Clause 6, and ISO 26262-3, Clause 6, we are not evaluating the root causes of hazardous or malfunctioning behavior. Instead, we are simply asking if this behavior exists and, if it is put under a certain “event,” could there be harm to a human being if it isn’t controlled?
- In ISO 26262, if we say “yes”, then we assign an Automotive Safety Integrity Level (ASIL), and it follows a certain path through the standard.
- In ISO 21448, if we say “yes”, then we continue down the path to ISO 21448, Clause 7.
Before we get into the root causes, it’s important to understand why we call the “events” differently between ISO 21448 and ISO 26262. This comes down to the importance of exposure. In ISO 26262, rare (incredible) events are typically excluded from our analysis, and there is a higher weight placed on higher probable operational situations (events). Thus, in addition to evaluating controllability (C) and severity (S), ISO 26262 also evaluates the exposure (E) to the operational situation. In contrast, the success of ISO 21448 depends on identifying these rare events (or edge cases). Therefore, the exposure of a scenario isn’t considered in ISO 21448 during risk evaluation, only the controllability and severity.
While relying solely on the output of ISO 26262-3, Clause 6 (the Hazard Analysis and Risk Assessment – “HARA”) to support ISO 21448, Clause 6 is incorrect, it is also misguided to disregard it entirely. It’s crucial to understand the differences between scenarios and operational situations. The HARA provides valuable insights into vehicle behavior, and ISO 26262’s operational situations can help build out ISO 21448’s scenarios.
Now, let’s shift our focus to root causes. In ISO 21448, our primary concern is identifying “triggering conditions,” which are specific conditions of a scenario that can initiate hazardous behaviors from the automated system. When discussing hazardous driving behaviors from humans, they are often “triggered” due to distracted, impaired, drowsy, or emotional driving. In contrast, when addressing hazardous driving behaviors from automated systems, we focus on triggering conditions that activate a functional insufficiency in the system. For example, with an Automated Emergency Braking System (AEBS), a camera might detect a shadow on the road (triggering condition) and mistakenly identify it as an object requiring emergency braking. In this case, the AEBS has a functional insufficiency (in the sensing and/or planning subfunctions) that causes sudden braking (hazardous behavior). The process of systematically identifying and evaluating potential functional insufficiencies and triggering conditions is covered in ISO 21448, Clause 7.
Moving to ISO 26262, the root causes follow a different path. In ISO 26262, we evaluate faults in software, hardware, or the system that could cause a failure, subsequently manifesting as malfunctioning behavior at the vehicle level (item). For instance, in our AEBS example, the camera might correctly detect no objects and provide no braking request to the braking system. However, if the hardware pin associated with the braking request gets stuck in a “brake request” state, it could cause the vehicle to suddenly (or unintentionally) brake. The process of identifying and evaluating potential faults that could lead to vehicle-level failures is addressed through safety analyses. Various abstraction levels of safety analyses are prescribed by ISO 26262, with the system-level analysis that ties back to malfunctioning behavior leading to harm (safety goal) detailed in ISO 26262-4, Clause 6.4.4.
The difference in root causes leading to the hazard for the two standards can be illustrated in the following figures:


As described, although the ISO 21448 and ISO 26262 standards are inherently different in scope, a clear understanding of the meaning of “hazard” for both standards can establish a connection, allowing the resources used for functional safety to also be applied to SOTIF.
For a deeper discussion and understanding of SOTIF and functional safety, you can register for one of our upcoming training sessions.