Safety in numbers: Understanding and demonstrating SOTIF

Safety in numbers: Understanding and demonstrating SOTIF

The Safety of the intended functionality standard has increasing relevance in today’s automotive industry. Edith Holland , HORIBA MIRA’s Chief Engineer for Functional Safety, explains why. 

The evolution of vehicle technology has been nothing short of revolutionary, especially with the advent of Advanced Driver Assistance Systems (ADAS) and Automated Driving Systems (ADS). As the automotive industry moves towards greater autonomy, the importance of safety standards like ISO 21448, also known as the Safety of the Intended Functionality (SOTIF), has come to the fore. 

Launched in January 2023, ISO 21448 complements the established ISO 26262 standard for functional safety, addressing new challenges posed by modern driver assistance and automation systems. HORIBA MIRA, a key contributor to this standard, continues to lead its implementation as the automotive sector adapts to increasingly complex safety requirements.

SOTIF backstory

Ensuring the safety of road vehicles has always been a cornerstone of automotive development. Over the decades, electronic and software-based systems have played a significant role in reducing accidents and improving passenger protection. Active and passive safety systems have saved countless lives.

However, as vehicle systems become more sophisticated, so do their failure modes. The publication of ISO 26262 in 2011 marked a major milestone, providing a framework for addressing risks caused by Electronic/Electrical (E/E) system malfunctions. This standard, now approaching its third edition, offers extensive guidance on ensuring functional safety by mitigating risks arising from hardware and software faults.

But ISO 26262 had its limits. With the rise of ADAS and ADS technologies, new types of hazards emerged – those resulting not from malfunctions, but from the systems' inherent limitations or unintended misuse. Recognising this gap, the industry developed ISO 21448 to address these risks. SOTIF focuses on ensuring the intended functionality of a system is not only effective but also free from unacceptable risk due to design insufficiencies or foreseeable misuse.

Key concepts in SOTIF

ISO 21448 addresses hazards arising from incomplete or incorrect specifications, overlooked design issues, and user misuse. These risks can present themselves in two areas:

  • Driving functions: Situational awareness features like object detection or lane-keeping that must work reliably in diverse conditions
  • Driver interaction: Systems that monitor and respond to driver inputs or behaviour, accounting for potential user errors like distraction or misunderstanding

This dual focus ensures developers consider both the system's technical capabilities and its interaction with real-world users, creating a robust safety net.

Why ISO 21448 matters

While ISO 26262 assumes that fault-free systems inherently perform safely, ISO 21448 challenges this notion for systems relying on environmental perception and decision-making. For instance, a driver assistance system may misinterpret a common scenario, such as a cyclist near a parked car – even if no technical fault exists.

This distinction is increasingly recognised in regulatory frameworks. Emerging legislation now expects manufacturers to demonstrate safety compliance through both functional safety (ISO 26262) and SOTIF analyses. But these efforts must be supported by robust safety management systems and thorough validation processes. HORIBA MIRA, with its expertise in safety assessments and state-of-the-art proving ground facilities, is uniquely positioned to assist manufacturers in navigating these requirements.

Addressing common challenges with ISO 21448

As with any standard, questions and ambiguities surround ISO 21448, including:

  • Terminology: Engineers often grapple with terms like ‘intended behaviour’ versus ‘specified behaviour’
  • Process structure: Unlike the rigid lifecycle of ISO 26262, SOTIF employs an iterative approach, allowing flexibility but demanding more effort to integrate into development workflows

HORIBA MIRA has developed proprietary insights in these areas through extensive research and client collaboration. Our engineers are skilled in safety analysis, requirement derivation, and safety case documentation, ensuring clients meet ISO 21448’s objectives.

Navigating uncertainty in SOTIF

Both ISO 26262 and ISO 21448 aim to minimise unreasonable risk. However, they differ in their approach to risk thresholds:

  • ISO 26262 addresses risk through mitigation of systematic and random faults depending on the required integrity (ASIL). Systems that already meet acceptable risk and only need application of baseline engineering processes are classified as ‘Quality Management’ (QM)
  • ISO 21448 requires explicit risk acceptance criteria, placing the onus on manufacturers to define and demonstrate compliance

Defining these criteria is particularly challenging due to epistemic uncertainty – the existence of unknown risks stemming from incomplete knowledge or unforeseen scenarios. This uncertainty highlights why many organisations advocate for regulatory bodies to establish universal risk thresholds.

Despite the challenges, achieving quantitative risk targets remains the goal for many manufacturers. Yet, as ISO 21448 highlights, absolute risk clarity can only emerge after extensive operational data is collected post-deployment. This reality makes iterative validation and robust scenario modelling critical to ensuring safety during development.

Moving forward

As the industry accelerates toward greater automation, the role of SOTIF in guiding safe design practices will only grow. The support HORIBA MIRA can provide – from safety engineering to validation – ensures manufacturers can meet these evolving demands. By embracing ISO 21448 alongside ISO 26262, companies can confidently deliver the advanced technologies shaping the future of mobility.

The journey toward autonomous vehicles is as much about managing risk as it is about technological innovation. With ISO 21448, the industry has a powerful tool to safeguard this transition, paving the way for safer roads and smarter vehicles.

Vijaykumar Vaghasiya

Automotive Functional Safety | Angel Investor

2w

Insightful Article.

Like
Reply
Raimund Laqua, PMP, P.Eng.

Chief Compliance Engineer | Ensuring Mission Success through Compliance | Lean Compliance

4w

"This distinction is increasingly recognised in regulatory frameworks. Emerging legislation now expects manufacturers to demonstrate safety compliance through both functional safety (ISO 26262) and SOTIF analyses" -- this approach needs to be applied generally for all AI systems.

Like
Reply
Mike Allocco, Emeritus Fellow ISSS

System Safety Engineering and Management of Complex Systems; Risk Management Advisor...Complex System Risks

4w

There may be uncontrolled SYSTEM risks associated with availability, latency, loss of information, intelligent corruption of data, hazardous misleading information, missing functions, redundant functions, loss of function, delayed function, incorrect function, intermittent function, undetected function, inadvertent functional changes, or intentional or unintentional actions, alarm malfunction, inappropriate trust in the system. 

Mike Allocco, Emeritus Fellow ISSS

System Safety Engineering and Management of Complex Systems; Risk Management Advisor...Complex System Risks

4w

The so-called functional hazards may be the result of adverse integrations involving humans, software, firmware, hardware, and the environment. These risks may be apparent throughout the inclusive system life cycle from inception, through modified use to decommission. The safety specification represents applicable safety requirements, which are mitigations. Further, the system requires monitoring, isolation, detection, and stabilization; this relates also to the system accident life cycle. 

Like
Reply
Mike Allocco, Emeritus Fellow ISSS

System Safety Engineering and Management of Complex Systems; Risk Management Advisor...Complex System Risks

4w

Risk, probability, and safety more safety sound bites. Monte Carlo relies on: knowledge of Bayes and Boolean logic  and given many limitations, the understanding of modeling and simulation and the state of the art in protection and other human aspects of the equation: EE -2 to EE-3 error rates, real time decision errors, selection of an inappropriate models; limited data for prior and posterior distribution development; human decision attempts throughout the life cycle; differences between reliability engineering statistics and complex system risk: synergistic risk, systemic risk, system of system, families of systems risks. Software does not fail nor are the associated initiators random. Not everything is stochastic (probabilistic) when addressing system risk: dependence, independence, randomness is not easily determined in complex systems. Decomposition and integration of hardware, software, firmware, logic, the human, and environment are also a challenge. 

Like
Reply

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics