Safety of the intended functionality (SOTIF) – The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.
ISO 21448 Safety of Intended Functionality Training
- Introduction to advanced driver assistance systems (ADAS) and autonomous vehicles (AV)
- Safety of the Intended Function (SOTIF)
- The ISO 21448 framework for SOTIF
- ADAS and AV system specification and design
- Hazard identification and risk analysis
- Acceptance criteria, validation targets and validation effort
- Analysis of functional insufficiencies and triggering conditions using various methods such as failure modes and effects analysis (FMEA), fault tree analysis (FTA), and systems theoretic process analysis (STPA)
- Functional modifications to reduce SOTIF risks
- Developing a complete verification and validation strategy
- Verification: evaluating known hazardous scenarios using scenario testing at the system and vehicle levels
- Validation: evaluating unknown hazardous scenarios using simulation and test
- Defining a criteria for SOTIF release and the associated SOTIF release process
- Operating phase activities necessary for post-release implementation in the field
- An introduction to other relevant safety standards in ADAS and AV
- Process-oriented requirements for safety development processes
- Wrap-up and discussion topics
What Is ISO 21448: Road Vehicles — Safety of the Intended Functionality?
ISO 21448 applies to functionality that requires proper situational awareness in order to be safe. The standard is concerned with guaranteeing safety of the intended functionality — SOTIF — in the absence of a fault. This is in contrast with traditional functional safety, which is concerned with mitigating risk due to system failure.
SOTIF provides guidance on design, verification, and validation measures. Applying these measures helps you achieve safety in situations without failure.
Here are some examples that ISO 21448 provides:
- Design measure example: requirement for sensor performance.
- Verification measure example: test cases with high coverage of scenarios.
- Validation measure example: simulations.
How Is ISO 21448 Related to ISO 26262?
ISO 26262 covers functional safety in the event of system failures. It doesn’t cover safety hazards that result without system failure. That’s why ISO 21448 is necessary.
In fact, ISO 21448 was originally intended to be ISO 26262: Part 14. Because ensuring safety in situations without a system failure is so complicated, SOTIF is now a standard on its own.
ISO 26262 vs. ISO 21448
ISO 26262 still applies to existing, established systems — such as dynamic stability control (DSC) systems or airbags. For these systems, safety is ensured by mitigating the risk of system failure.
ISO 21448 applies to systems such as emergency intervention systems and advanced driver assistance systems. This systems could have safety hazards — without system failure. So, ISO 21448 complements ISO 26262.
Why SOTIF Is Important?
Verifying automated systems is difficult. Automated systems have huge volumes of data — and that data is fed to complex algorithms. AI and machine learning are critical for developing these systems. To avoid potential safety hazards, AI will need to make decisions. This includes scenarios that require situational awareness. Using ISO 21448 will be key to ensure that AI is able to make decisions and avoid safety hazards.
Example: Where SOTIF Applies
SOTIF applies to safety violations that occur without the failure of a system. Here’s an example of situational awareness.
The road is icy. An AI-based system might be unable to comprehend the situation — and respond properly. This impacts the vehicle’s ability to operate safely. Without sensing the icy road condition, a self-driving vehicle might drive at a faster speed than is safe for the condition. Fulfilling ISO 21448 means taking that situation into account and making decisions based on probability.
The goal of SOTIF is to reduce potential unknown, unsafe conditions. However, that definition is very broad. And it’s difficult to show that you’ve accounted for all potential edge cases.
How to Ensure Functional Safety in Autonomous Driving
Safety has always been critical in automotive software development. And ensuring functional safety remains critical for autonomous driving.
Here’s what development teams will need to do to continue producing safe software.
1. Use Secure Development Processes
One of the biggest challenges with AI and machine learning is security. There’s a lot to consider with cybersecurity and AI. This article covers the basics of getting security and privacy right.
Here are three examples of key secure development processes:
- Good programming practices and thorough testing efforts are critical for eliminating security vulnerabilities. This can be achieved by using secure coding standards.
- Threat modeling and risk mitigation are key to developing safe components. This can be achieved by doing a hazard and risk analysis.
- Control over the build/release environment is key to keeping hackers out — and keeping the build secure. This can be achieved through access controls in your CI/CD environment.
2. Apply Automation to Design, Verification, and Validation
AI. Machine Learning. Self-driving cars. There’s plenty for automotive software developers to worry about as they strive to produce safe software.
Applying automation to design, verification, and validation processes makes development teams more efficient.
ISO 21448 gave the following examples (listed earlier in this blog):
Design measure example: requirement for sensor performance.
Verification measure example: test cases with high coverage of scenarios.
Validation measure example: simulations.
Using a requirements management tool can help you fulfill a requirement for sensor performance. This contributes to safer design of the software.
Using a test case management tool can help you ensure high coverage of different scenarios. This helps with software verification.
Using a static analysis tool can help you simulate potential run-time scenarios. This helps with software validation.
3. Comply With Functional Safety Standards
ISO 21448 will be important for functional safety in autonomous driving. But compliance with established functional safety standards will remain important, too. Especially ISO 26262.
Best practices — and recommendations based on ASIL from ISO 26262 — will still need to be followed to ensure safe software for autonomous vehicles.
Learn more about fulfilling automotive functional safety requirements, such as ISO 26262, faster.