What is SOTIF? (Safety of the Intended Functionality) ISO/PAS 21448

 

The practical operation of automated vehicles in a real-world environment requires that they achieve and maintain a certifiable functionally safe state. These vehicles must maintain this state even when they are operating in chaotic environments shared with older vehicles that may have less or no automation. Thus, attaining this certification—in an environment filled with variables—must itself encompass a broad spectrum of requirements and processes.

Master Data Webinar

This blog is the first in a series of articles about one segment of this spectrum that is known by “SOTIF,” an acronym which stands for “Safety Of The Intended Functionality.” SOTIF itself is a very broad subject, with many nuances and interactions to consider. So, in this first installment on SOTIF, we start at the very beginning by laying out several foundational concepts.

Subsequent articles in this series will then build upon that base knowledge and walk us through the key pieces of the SOTIF puzzle. We will then explore some of SOTIF’s vulnerabilities and discuss what it takes to define and build high-quality SOTIF scenarios. Next, we will explore SOTIF-related software development. We will then summarize by putting all these pieces together. And lastly, we will close with a look forward to the new frontiers just over the SOTIF horizon, as well as the next steps for getting there.

SOTIF is a key component in automated driving, but it is only one element of many. To gain a better sense of SOTIF’s scope and purpose within the overall context of functional safety, let’s begin by examining how SOTIF meshes with the rest of the automated vehicle domain. This will first provide us with context as we define what SOTIF is, and then we will begin to drill down into SOTIF’s various elements and considerations.

Why is SOTIF Needed

The Modern Mechatronic System

The vehicles of today are a far cry from their late 20th century predecessors. Long gone are the days when electrical and mechanical systems were essentially separate systems, augmented by rudimentary control units bolted to the firewall. Today’s modern vehicles are highly complex mechatronic machines that tightly interweave mechanical systems, software, computational power, sensing, data and bandwidth capacity, and physical actuation, implemented by electrical and electronic systems. The interwoven nature of these systems stretches from bumper to bumper and beyond, reaching out to include the environment in which the vehicle is operating. This capability enables the mechatronic system, as a unified whole, to make decisions and take actions based on what it perceives, and what it has been designed to do.

Managing Risk

In recent years, there has been a significant increase in the number, capability, and complexity of advanced vehicle functions. Bit by bit, the capability of the vehicle is growing to the point that it can augment, or in some cases take over, functions that before could only be handled by humans. However, with increased complexity also comes increased risk. To efficiently manage these risks, it makes sense for functional safety efforts to focus on the areas of greatest risk, and then try to reduce or eliminate them.

Because most vehicle functions are controlled by humans, most vehicle accidents can be traced to human error. Therefore, the most effective way to reduce the number of accidents is to provide trustworthy assistance to the human who controls the vehicle. This is accomplished by off-loading select decisions and capability to automated systems that have been proven to perform these specific tasks faster, more accurately, and more reliably than the typical human. The intent is not to replace the human driver, but for the driver and the vehicle to work together, allowing the driver to focus on those tasks which humans perform best.

AdobeStock_166038073

ADAS and SOTIF: Distinct and Complimentary

Foundations Concepts 

Advanced Driver Assistance Systems (ADAS) are the hardware, software, and communication systems that are designed to increase safety and reduce risk by using the human-machine interface to aid the humans driving the vehicle. ADAS provide early warnings and reduced reaction times to potential hazards. This enhanced capability helps prevent injuries and deaths by one, lowering the number of vehicle accidents, and two, reducing the serious impact of accidents that cannot be avoided.

In comparison, international standard ISO/PAS 21448, Road vehicles — Safety of the intended functionality, defines SOTIF as “… the absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.”

The absence of unreasonable risk… hazards resulting from functional insufficiency… the intended functionality of a system versus the actual degree of functionality that it achieves in the real world… foreseeable misuse by persons, either accidental or intentional… In this series, we will examine all these SOTIF considerations in detail, as well as the processes and systems we use to define and create these systems and measure their effectiveness.

Making a Difference in the Real World

Defining precisely what the “safety of the intended functionality” establishes the criteria that need to be met when an ADAS system is designed, built, and deployed. In other words, SOTIF defines the target and what the intended definition of “functionally safe” is in each scenario. Then, ADAS systems determine how you hit that target by turning intended safety into actual safety in the real world. If teams don’t first define the intended functionality via SOTIF, they have no way of knowing what they are aiming for, and no way of confirming they hit it. And if they don’t follow through by deploying vetted ADAS solutions, real-world safety is not improved.

Providing the Driver with Assistance

It can be said that ADAS systems and SOTIF are themselves extensions of some of the earliest automotive safety efforts. When automobiles were first introduced, they were little more than a stepped progression from the horse-drawn wagons and carriages they replaced. Neither the vehicles nor the environments they operated in were designed to accommodate the speeds, weights, and quantity of vehicles that the invention of the automobile would rapidly introduce.

The early pioneers designed their vehicles primarily through experimentation. If something worked, the early builders simply tried to replicate it, even before they fully understood why it worked. Just as lessons were learned from what worked, more poignant and valuable lessons were learned by what didn’t work, often at a tremendous cost in human suffering.

As we transitioned to self-propelled vehicles, the entire system evolved in a familiar pattern that directly correlates to the design progression of today’s modern vehicles. This included the earliest hints of what would eventually become SOTIF—the key word being intention. The design of vehicles and roads slowly started to transition from being reactive to having functionality that was the product of intentional forethought, or, designing to a purpose.

We deliberately increased safety by applying sound engineering principles to both the design and construction phases, improving the stability and safe carrying capacity of the vehicles as well as the roads and bridges on which they operate. Engineers combined scientific studies with environmental and materials science to introduce safer vehicles. America began building better roads. Correspondingly, vehicles were fitted with better tires to improve safety by providing enhanced grip and a more stable ride specifically engineered for these new surfaces. The roads themselves evolved into engineered systems built to strict and consistent universal standards; these were designed and exhaustively tested under the guidance of various highway-building associations and, eventually, federal regulatory agencies.

There are key take-aways from all this history:

  • Safety through deliberate forethought is a concept that predates the automobile and is more important today than ever.
  • We keep defining and applying intended functionality because we have the data to prove that doing so makes our world safer.
  • Applying vetted and repeatable scientific principles is more effective than guesswork.

All these points underscore the very concept of designing with the safety of the intended functionality (SOTIF) in mind. And once the SOTIF of the vehicles and roads was defined, engineers began looking for ways to improve the functionality of the drivers themselves.

There are many examples of ADAS systems that have been in common use for decades. Some of the more established and less-complex electrical and mechanical systems include anti-lock braking systems that were first introduced in the 1970s, traction control, headlights that automatically turn themselves on in low light conditions, and rearview mirrors that automatically dim. More recent innovations include rearview cameras to help prevent backing accidents (especially those involving children playing behind the vehicle), adaptive cruise control that allows you to set and maintain a fixed distance from the car in front of you, navigation assistance in the form of GPS-based graphical and audible systems, hazard avoidance in some or all directions around the vehicle, and lane departure and centering.

The technologies used in these systems can typically be categorized as either those that improve driver awareness and/or those that automate driving tasks. These technologies were selected, and these ADAS systems were designed and built, only after engineers first defined:

  • what safety problems the systems were intended to solve,
  • what a “safe” system looked like, and
  • what known and unknown risks might be encountered in their use.

Defining these criteria is the act of defining the safety of the intended functionality.

Before you can formally define the safety of the intended functionality, you must first have a standard to guide you. This will enable you to confirm that your definitions are accurate and complete, and will provide a defined, measurable, and repeatable process for achieving the defined goals. ISO/PAS 21448 is that standard. It is an ISO standards document created and maintained by the International Organization for Standardization (ISO), a worldwide federation made up of national-level standards bodies. SOTIF helps ensure functional safety by first making sure that the standard that governs this work is itself robust and properly vetted.

How does SOTIF ensure functional safety in autonomous driving?

As noted in the standard itself, the preparation of ISO International standards is normally carried out through ISO technical committees. International organizations (both governmental and non-governmental), in liaison with ISO, also help support this work. Through the diligent work of these entities and persons, the standard is continuously evaluated and improved.

The process journey by which this standard is prepared and evolves through various drafts and reviews, and is eventually approved for publication, occurs in the following order:

  1. Subcommittee SC 32, Electrical and electronic components and general system aspects
  2. Technical Committee ISO/TC 22, Road vehicles
  3. ISO approval and publication

Note that the SOTIF standard originated in a subcommittee from the realm of electronics and general systems, not at the road vehicle level. This makes practical sense, given that today’s modern vehicles are electromechanical, and some of those same sensors and components may be found in other types of vehicles and applications. The same or similar components might also be shared across on-highway, off-highway, or even aerospace applications.

It is important to grasp this added complexity right from the start. Long gone are the days when a vehicle was simple enough to be subdivided into separate electrical and mechanical systems. And yet, each application will necessitate requirements tailored to the particulars of its use case and operating environment.

Functional-safety-accelerator

What does ISO/PAS 21448 mean for automotive developers and OEMs?

Automotive developers and OEMs contribute their expertise in a variety of technologies and systems. Although the work on this standard originated in a subcommittee focused on electronics and general systems, that does not reflect the highest priorities of the standard itself. Because each application might utilize a similar component in different ways to achieve varied criteria, it does not make sense for team members to focus first on parts and software. Instead, the standard focuses on first defining what is meant by the term, “Safety Of The Intended Functionality,” and then provides guidance on the applicable design, as well as verification and validation, measures needed to achieve the SOTIF. This helps to ensure that the expensive design and development work, and the eventual selection of specific technologies, is targeted to an end goal that is clearly defined, rather than teams plucking possible safety applications out of thin air to justify the use of a given technology.

This is the first introductory article in a series on SOTIF. In our next installment, we will explore the scope of SOTIF, including the process for creating and improving ADAS systems, the different types of SOTIF scenarios, and the verification and validation measures needed to achieve SOTIF.

Interested in learning more about SOTIF for your organization? Contact our team today!

CONTACT US

 

 

Adam Saenz

Written by Adam Saenz

Adam joined LHP in 2018 bringing over 15 years of engineering experience in many areas of product lifecycle development. He specializes in embedded system design and has held positions as a software engineer, electrical engineer and systems engineer. As a software engineer, he has worked on control algorithm development and device driver level software. His hardware experience includes analog and digital circuit design, PCB layout, and FPGA firmware development. His system engineering experience includes developing architectures, writing requirements, and test case/procedure development and execution. Over the years, Adam has gained extensive experience in board bring up, hardware/software integration, and troubleshooting at the PCB, system and system-of-systems levels. He utilizes his experience in both hardware and software to determine the root causes of problems and apply the appropriate solution at the right level. Adam has also designed Automated Test Equipment (ATE) systems for verification and validation of safety-critical applications. His design approach utilizes as much off-the-shelf hardware as possible with a common software architecture to minimize costs and development time between projects. His ATE designs have been used in testing high input/output (I/O) products for military, aerospace, and industrial applications. Adam is a Functional Safety Certified Automotive Engineer (FSCAE) and has spent most of his career working on safety-critical projects. He has developed software for Aerospace DO178 Level A products, and hardware and FPGA designs for safety-critical products in the rail and industrial machine tooling industries. Adam attended California Polytechnic University Pomona and has a Bachelor’s of Science in Electrical and Computer Engineering. He also has an Embedded System Engineering Certificate from the University of Irvine.