Safety of the Intended Function

Background

When you develop automotive safety-related functions an easy (well…) way to comply with regulations is to follow the ISO 26262 standard (“Road vehicles – Functional safety”), which has been in use for more than a decade.

One assumption behind ISO 26262 is that if you conclude the criticality of your function, encoded as an ASIL (Automotive Safety Integrity Level), and follow the recommendations of the standard, all will be fine.

ISO 26262 uses the term “intended functionality” to describe the specified behavior of the function or system. Normally we assume no difference between the specified and intended functionality, given normal reviews of requirements in the development process.

SystemWeaver ontology diagram depicting the definition of “intended functionality” among the definitions of ISO 26262.

Enter Advanced Driver Assistance and Autonomous Driving Systems

With the arrival of ADAS and AD systems, it was found that minor shortcomings in the specifications of such systems could lead to severe problems, given the complexity of such systems and their driving environment. For example, a driver may trick an autopilot into thinking that the driver is in control, while he or she has in fact no hands on the steering wheel. Under specific circumstances, the system may make false environment detections, due to limitations in the perception system, which could cause the system to intervene in a critical driving situation. Also, the system may entirely fail to detect other traffic objects, if these deviate from assumptions made during development, causing crashes. This shows that the “intended functionality” may be based on ever-so-small mistakes in the assumptions of the operating environment of the system. So what can we do about this?

ISO 21448 – Road vehicles – Safety of the intended functionality

In 2022 the automotive industry released the standard ISO 21448, to give enhanced guidelines for the development of advanced systems like ADAS or ADS. The old ISO 26262 still applies, to make sure the intended functionality is implemented in a reliable and safe way, while the new standard addresses issues about the “intended functionality”.

Note that the chance of faults in safety-related automotive systems is assumed to be so low that even extensive testing cannot guarantee the absence of unreasonable risk since that would require enormous cost and time for testing. Instead, ISO 26262 applies methods of applying a design of independent redundancy in the components of the systems, so that the combined reliability of the independent mechanisms will guarantee sufficient safety. For “intended functionality” these methods are of no use since systematic use of redundancy does not help much if the specification is wrong.

So, how can this be addressed? ISO 21448 does this in several ways, some similar, but completing the methods, of those recommended in ISO 26262. For example, the way to establish the risks of the system, using HARA - Hazard Analysis and Risk Assessment methods, as used in ISO 26262, is applied in a new way in 21448, with enhanced focus on analyzing the use and operating environment of the system, to minimize the risk of overlooked details. Part of this is covered by more detailed models of the intended user scenarios and driving environment of the systems, as seen in the figure below. These detailed models will be used throughout the development, with more and more details added in the later stage of development, simulations, and testing.

Detailed operational domain elements, in SystemWeaver

The overall layout of the HARA grid has many similarities with the classical HARA, with some critical differences:

• The operational situation during a hazardous event is detailed into separate scenes so that it can be better understood during analysis.
• The use of the occurrence property to define the likelihood of a hazardous event is not meaningful in the SOTIF HARA, since we are dealing with extremely rare, combined conditions of the system and its environment, which, in contrast to the assumptions to the normal safety methods, cannot be mitigated by systematic use of redundancy. Contrarily, the upper bounds of the conditions must be decided upon, in an open risk-benefit approach similar to the development of medical equipment, which can all be controversial in the automotive industry, where risks are implicit, hidden in the application of the ASIL attribute.
  

SOTIF HARA in SystemWeaver, with features to support systematic and complete analysis.

When the HARA and other analysis methods are performed systematically in a tool like SystemWeaver, with full traceability and life-cycle management, and support for the application of the methods, the intentions of ISO 21448 can indeed be fulfilled, although requiring an elevated effort in analysis and testing of the systems compare to that of non SOTIF relevant systems.[1]

[1] SOTIF relevant systems also need to be developed according to ISO 26262, to deal with potential deficiencies in design and implementation.