Our SOTIF Manifesto | Functional Safety
Addressing Misunderstandings and Misconceptions of SOTIF
An Unintentional Side Effect of SOTIF
Since attending the first-ever Safety of the Intended Function (SOTIF) conference in March 2019 in Munich, I have heard advocates for the SOTIF effort make the following statements about ISO 26262:
“ISO 26262 does not address hazards that may occur when the system is working correctly.”
“ISO 26262 addresses faults due to random hardware failures and software bugs.”
This understanding of ISO 26262 is wrong. I knew it was wrong at the time, but I shrugged it off and focused on what the real contribution or actual idea behind SOTIF was. However, after a year and half, this misunderstanding of ISO 26262 has become central to the identity of SOTIF, and from my experience talking with clients and following the latest industry conferences, this misunderstanding is now becoming widespread. Folks who are not familiar with ISO 26262 are being introduced to it through this incorrect understanding and end up struggling through confused and unproductive development. The claim that ISO 26262 does not deal with the correct functional specification, does not deal with the outside environment, and is only focused on hardware and software is a dangerous mantra. And it’s growing.
How This Comes to Play in the Industry
Let me start by giving you an example based on real experiences. In the past year and a half, I have worked on several autonomous vehicle projects where we have written out high-level safety requirements for autonomous functionality. In fact, as a functional safety consultant, every project we work on for clients gets to the point of writing out the high-level safety requirements because this is where clients tend to need the most help, and where functional safety projects start to go wrong. If the functional safety requirements are not correct, the safety project has a 0% chance of succeeding.
In these projects, I would start by writing out a functional safety requirement, like this:
“The EGO VEHICLE shall produce a vehicle deceleration of at least 0.5g within 900 ms if an IN-LANE TARGET OBJECT position is less than or equal to TTC_X_DISTANCE.”
(For examples on writing safe perception requirements, check out our previous blog, and in future posts we will be diving deeper into safety requirements.)
Almost immediately, I’d get pushback from the client or a colleague: “Wait,” they’d say, “Isn’t this ‘Safety of the Intended Functionality?’ Should we really be specifying this? I don’t think we can specify that. Someone else needs to specify what we intend to do.”
When they pushed back on the proposed requirement, I would ask them what would they write down instead. Here’s an example of a typical response: “Let’s just write, ‘The EGO needs to avoid hitting the TARGET,’ and let the X team specify how to do that in the technical requirements (or software requirements).”
The “X team” in reference here could be an L3 ADAS module development team, an electronic brake control supplier, or a perception system team. Inevitably, the responsibility to determine the vehicle behavior would fall on some unsuspecting software developer, and any software developers reading this know this is true. The software team has to fix all the unsolved product issues before the product goes out the door.
To have one person or a handful of people to be responsible for the success or failure of the entire project in the last weeks and months before the release is dangerous, especially when wrestling with safety issues such as, “How much does the car need to brake when there’s an object in front of it?” Or, “How far ahead does the car need to detect an object?” “How much risk is acceptable?” Could you imagine the type of dangerous safety culture this presents? The whole purpose of ISO 26262 is to avoid this program conflict completely by making sure safety requirements are correct, such as through an FMEA type of process, and assigning a safety manager to plan the safety activities of subsequent development.
So, going back to my projects, what I end up doing is I explain and convince my client or colleague that right now, while writing the FSRs, is when we, along with the various stakeholders, specify how the product behaves (be it Item, Vehicle, etc.). If this is not written down at a high-level, the perception team might interpret their requirements differently from the brake-by-wire team. And when the whole system is integrated someone finds holes or “functional insufficiencies.”
This resistance to write out the functional safety requirements has happened multiple times. If our clients had gotten their wish and pushed off writing the requirements we had suggested, the project would otherwise appear to be on track or better for the next 6-12 months. But eventually, things would have fallen apart as questions, confusion, and issues escalated. Instead, we spent that time identifying and solving issues at the functional level long before the problems would have appeared in integration testing and customer demos. I expect these hang ups and delays are not unique, and I think they are all tied to an incorrect understanding of ISO 26262: the belief that the right thing to do is to hold off on specifying functional requirements either until a later point in development or until the SOTIF standard provides answers on the safe intended function.
So Then, What Is ISO 26262?
If ISO 26262 is anything, it is a standard that addresses functional insufficiencies, first and foremost. It addresses functional insufficiencies in the performance of the system: the sensors, processors, and actuators, and it addresses them through complete and correct requirements. It also addresses management insufficiencies throughout the product lifecycle, including personnel incompetence on who has actually been trained or has experience with ISO 26262, and in failures to sufficiently verify the completeness and correctness in safety requirements. Such safety management makes it impossible or very difficult to get a successful assessment from an independent organization regarding the fulfillment of ISO 26262.
When SOTIF experts say ISO 26262 does not address the hazards of incorrectly sensing the environment, whether it is sensor functionality, or noise filtering, or robustness to environmental variations, they are wrong. I can’t say it nicer than that. It’s just wrong. The consequence of a group of consultants, experts, and conference speakers repeatedly making this claim is that a large portion of the industry, for which functional safety is new and growing, is being misled into a dangerous and unproductive mess where the safe, well-trusted “standards” are no longer “standard.”
What we need to do, when we want to present new ideas and methodologies for how to universally achieve safety in autonomous driving, is not exclude or redefine well-trusted standards. What we want to do is actually develop the safe solution first, using the current, well-trusted standards for guidance. Once we have one or more safe solutions realized and independently assessed, we may want to standardize the solutions for the benefit of the industry. Saying it’s very difficult to create the standard before the solution is an understatement, but this is what many in the industry are currently pursuing and hoping will work out.
The Progression of Autonomous Safety
I’ve been pretty negative so far, but I want to point out not everyone is stuck in confusion, and good progress in safe autonomy is being made in the industry. Since the original SOTIF effort began as an ISO 26262 working group, questions surrounding the scope and purpose were raised, and some very good answers were provided such as this response found in a paper written in September of 2015 (yes, 5 years ago, from the time of this writing). (Bergenhem, Johansson, Soderberg, et al.) The authors of this paper stressed the importance of safety requirements in autonomous development, arguing for a more thorough review of completeness, correctness, and formal verification of requirements when it comes to addressing the complexities of autonomy. And they made this comment about SOTIF:
“In the current work with revision of ISO 26262, there is a sub-working group denoted ‘safety of the intended function’ (SoTIF). The problem addressed, is that today there are examples of items that shall take care of complex environment sensing as e.g. part of an ADAS function. It is difficult to build a sensing system that is able to take care of all possible situations. Given that nominal performance limits of the sensing system are accepted, there is still the risk of (very rare) situations leading to violations of a SG, without any fault in the sensing system itself. The cause might be that the processing algorithm takes a hazardous decision about the environment. The SoTIF initiative aims at providing guidance to manage such a violation of a SG.
“We claim that the SoTIF discussion is a consequence of improper safety requirement refinement and/or of improper item definition, i.e. the initial requirement statement. If the intended function is potentially hazardous in some situation, then the item is simply not well defined. We claim that every SG violation will manifest as a violation of the underlying safety requirement structure. This means that either at least one of underlying FSR is violated or is the verification of the completeness of the FSC not performed properly. Similarly, the violation of such a FSR implies that either at least one technical safety requirement is violated, or is the verification of the completeness of the TSC incorrect.
“It is our understanding that the SoTIF discussion has evolved from a problem of handling implicit complex items. The SoTIF perspective becomes redundant once a methodology is applied in which the item definition is checked to reflect the responsibility of the E/E system and where the set of SGs can be shown to be complete w.r.t. all hazardous events possible according to the item definition. The complexity problem will then be possible to master by introducing safety requirement in so many steps that each step can be verified w.r.t. correctness and completeness.”
Again, the authors emphasize the importance of having complete and correct safety requirements regarding the sensing functionality or any autonomous function in order to fulfill the ISO 26262 standard. This is contrary to the message often heard from those explaining SOTIF, when they claim ISO 26262 does not address the completeness and correctness of the high-level safety requirements, especially those about sensing functionality.
ISO 26262’s Relationship with Hardware and Software
Before getting off my soapbox, I do want to briefly touch on the equally devastating and false claim about ISO 26262, the one focusing on hardware and software:
“ISO 26262 addresses faults due to random hardware failures and systematic software bugs.”
Is this claim entirely wrong? Well, it depends on the context, but I would suggest the intent here is to make a distinction that ISO 26262 applies more to the aspects of the system technology and not to the system functionality. The truth is ISO 26262 contains very little prescriptive information for hardware and software technology, often referring to outside, domain-specific standards like SN29500, AEC-Q200, and MISRA-C. ISO 26262 only tells us hardware and software faults have to be controlled to an acceptable level of risk, and it prescribes the general processes we must use for deriving and verifying the control of those faults, namely, the process of writing safety requirements.
It is not uncommon to hear design engineers say: “I read through the entire standard (26262) and it tells me nothing about how to design my hardware!” or, “ISO 26262 doesn’t tell me one way or another if I need a memory management unit for my software.” That’s because ISO 26262 doesn’t tell us how to control hardware and software faults, explicitly. That’s left up to the team responsible for the safety design. Can you imagine how dangerous that might be if we all had to use the same “safety” design across a variety of products and applications?
It’s impossible to prescribe methods for safely controlling one fault vs. another when the consequence of the fault with regard to safety is unknown. Safety is context-specific and the safety requirements provide the context, or should, for any point in the development of the vehicle. Writing real safety requirements is challenging and often much more work than originally expected, but the good news is once completed and the problem clearly understood, the ensuing development effort is much easier and quicker than expected.
Looking Forward – Our Hopes, and Goals for the Future of Autonomous Safety
Our hope and desire for those actively improving and promoting the SOTIF effort is to publish more up-to-date developments on the essential theme and contribution of SOTIF, and less on redefining ISO 26262 in contradictory terms. In the current version of SOTIF, ISO/PAS 21448:2019, the Introduction refers to SOTIF five times, whereas it refers to ISO 26262 seven times. I don’t think it matters one way or another if SOTIF ended up becoming an ADAS-specific safety standard within the context of ISO 26262 Part 3. Why does SOTIF need to be distinct from ISO 26262? There is a similar precedence with the German OEM E-Gas Monitoring Concept for an engine-specific safety standard, which is related to the context of ISO 26262. The hazards it addresses are a subset of the hazards addressed by ISO 26262. I see no reason for making a new automotive functional safety standard that is distinct from ISO 26262, and I would I encourage any safety manager to follow ISO 26262 in their functional safety development for autonomous vehicles.
If you are developing the many safety requirements for autonomous vehicles and would like to discuss questions about complexities and completeness, please reach out to us through the contact information on our website and we would be happy to offer any assistance. If you are interested in practical methods for developing safe autonomous solutions for SOTIF or ISO 26262, including FMEA and verification and validation activities, please subscribe to our newsletter, as we will be sending out an exclusive 5-part series on working through the safety standards. And follow us on LinkedIn as we will dive deeper in the coming weeks into more SOTIF insights. If you enjoyed reading about this topic, or would like to hear more on a certain topic, please leave a comment or contact us through our website. We look forward to hearing from you.