SOTIF – The workflow and work products

In the second part of our three-part blog series on the recently published Publicly Available Specification ISO/PAS 21448:2019 ‘Road vehicles – Safety of the intended functionality’ (SOTIF) we focus on the workflow and work products.

The key initial work product in SOTIF is the Function and System Specification. One important point to note in SOTIF is that only sections 5.1, 6.1, 7.1, 8.1, 9.1, 10.1, 11.1 and 12.1 are normative all other sections are informative.

The Function and System Specification has two normative requirements:

• Compile and create evidence containing the information sufficient to initiate the SOTIF related activities
• Update the evidence as necessary after each iteration of the SOTIF related activities

The informative sections however list many very helpful tips, that can be applied to a given project and these are split into two distinct groups

Function related:

• The goals of the intended functionality
• The use cases in which the intended functionality is activated, deactivated and active
• The description of the intended functionality
• The level of automation/authority over the vehicle dynamics
• The dependencies on, and interaction with:
  • the car driver, passengers, pedestrians and other road users
  • relevant environmental conditions
  • the interfaces with the road infrastructure

System related:

• The description of the system and elements implementing the intended functionality
• The description and behaviour of the installed sensors, controllers and actuators used by the intended functionality
• The assumptions about how the intended functionality makes use of inputs from other elements
• The assumptions about how other elements make use of outputs from the intended functionality
• The concepts and technologies for the system and sub systems
• The limitations and their countermeasures
• The system architecture supporting the countermeasures
• The degradation concept
• The warning strategies
• The dependencies on, and interaction with other functions and systems of the vehicle

From these listed points a clear set of requirements can be defined for the SOTIF project. Figure 1 shows the SOTIF workflow but surprisingly the two factors jump out of this workflow: first, the project can be deemed to be complete without an assessment of the residual risk (if in item 6 the decision is Yes) the assumption here that the residual risk is automatically assumed to be acceptable. The second is the lack of post market surveillance particularly taking into account the subject of human factors. We will visit the human factors aspects in more detail in the 3 part of the blog (See: “SOTIF – The Human Factor“).

Figure 1 SOTIF Workflow

Through the subsequent activities, the SOTIF risks and triggering events are evaluated, the risk reduction activities are then applied as applicable. When triggering events are deemed to be acceptable, the process moves on to verification and validation activities and if successful the criteria for SOTIF release.

The techniques listed in section 8 on improving SOTIF and then subsequent sections on the verification and validation strategy help focus teams of the aspects of algorithms, sensors and actuators. Again, returning to the topics of diversity and degradation concepts. The listed methods for verification and validation are also good checklists supporting these activities.

In our final part of this blog we will visit the topic of how SOTIF approaches human factors and compare this with how other industries approach the subject.

By Alastair Walker, Functional Safety Consultant