SOTIF in Practice: Building Safe ADAS and Automated Driving Systems

In this interview, Abhash Das, Safety Standards Technical Manager at VinFast Europe, outlines the key SOTIF requirements that OEMs and suppliers need to address when developing ADAS and ADS, as well as the approaches that work best for demonstrating that automated systems can operate safely in both known and unforeseen situations. Abhash also discusses how the industry needs to evolve to keep pace with changing SOTIF requirements, and the steps organisations can take to ensure functional safety and cybersecurity activities are aligned rather than handled in silos.

*The following statement is based on his personal take*

Automotive IQ: Abhash, can you tell us about your background and role at VinFast?

Abhash: Safety expert with extensive experience in ADAS and Autonomous Driving technologies, currently leading initiatives at VinFast Europe. Over two decades of proven leadership in the automotive and semiconductor industries, complemented by a robust understanding of E/E architecture and requirement engineering, adhering to INCOSE and ASPICE standards, complemented by a strong foundation in system & software engineering, vehicle homologation, and type approval. Proficient in navigating complex UN regulations like R155, R157, R79, R171, ADS (upcoming) and industry standards such as IEC 61508, ISO 26262, ISO 21448, UL4600, and ISO 21434, committed to delivering production-ready safety-critical systems that meet customer expectations and market demands. Active participation in international technical forums, contributing to the development of ADS regulation, safety standards and innovative solutions. Authored several patents and trade secrets.

Automotive IQ: Could you outline the key SOTIF requirements that OEMs and suppliers need to address when developing ADAS and ADS?

Abhash: To demonstrate the safety of ADAS and automated driving (AD) systems, the industry must go beyond traditional, requirement-based safety approaches. Safety of the Intended Functionality (SOTIF), formalized in ISO 21448, addresses risks arising from incomplete specifications and inherent performance limitations rather than from system malfunctions. SOTIF does not replace Functional Safety (FuSa); since both apply to the same ADAS/AD functions, a comprehensive safety argument requires consideration of both perspectives.

SOTIF extends existing engineering practices, such as specification development, analysis, verification and validation (V&V), and field observation, to address the challenges of operating in an open-world environment. The complexity of the driving task and the absence of a fully closed specification make exhaustive upfront requirements impractical, increasing the importance of V&V. As a result, rigorous and continuous V&V activities play a critical role in supporting the SOTIF safety case.

Automotive IQ: SOTIF is often discussed alongside traditional functional safety. In your view, how do the two differ, and why do automated driving systems require both to ensure safe performance?

Abhash: SOTIF does not replace Functional Safety (FuSa); since both apply to the same ADAS/AD functions, a comprehensive safety argument requires consideration of both perspectives. In simplified term ISO 26262 FuSa address the Inside-Out perspective of a function, where SOTIF address the Outside-In perspective of the function. Automated driving operates in an open-world domain where:

• The driving task cannot be fully specified upfront
• ML-based perception introduces uncertainty and non-deterministic behavior
• Safety depends on the correct interpretation of complex, dynamic environments

FuSa alone cannot address these challenges because it does not cover hazards arising from correct but insufficient behavior. Conversely, SOTIF does not address risks due to system failures. Safe performance of automated driving systems can only be assured by combining FuSa and SOTIF. FuSa ensures robustness against failures, while SOTIF ensures that the system's intended behavior remains safe under real-world variability and uncertainty. Together, they form a comprehensive safety framework capable of addressing both failure-driven and performance-driven risks inherent in automated driving.

Automotive IQ: A major part of SOTIF involves defining acceptance criteria for safe operation. What approaches do you think work best for demonstrating that an automated system can operate safely in both known and unforeseen situations?

Abhash: Setting SOTIF acceptance criteria is not guesswork, but rather a careful choice informed by established safety principles and lots of real-world data. These criteria help us as an engineering community to draw a line in the sand for what is considered "safe enough" in terms of residual risk. These criteria specify what level of hazardous behavior (like missed detections or unintended actions) is permissible, often using quantitative targets (e.g., < X incidents per hour/mile) or qualitative measures (intuitive behavior), benchmarked against human drivers or existing systems, and validated through extensive testing in simulation and real-world driving. Validation targets make these acceptance criteria actionable – they specify how much evidence (in terms of test miles, scenario coverage, statistical confidence, etc.) we need to collect to convince ourselves and our users that our ADAS/ADS system meets the safety benchmark.

The most effective way to define and demonstrate SOTIF acceptance criteria is to combine:

• Scenario-based validation for known risks
• Statistical evidence for probabilistic behavior
• Uncertainty-aware design and fallback strategies
• Runtime safety monitors
• Continuous field learning
• A structured safety case

Together, these approaches acknowledge that unforeseen situations cannot be eliminated - but they can be detected, bounded, and managed safely, which is the core intent of SOTIF.

Automotive IQ: Validating rare or unusual scenarios is one of the biggest challenges for automated driving. How can companies balance the need for thorough testing with the practical limits of time, budget, and available data?

Abhash: To start with, companies should balance rare-scenario validation with practical constraints by:

• Prioritizing risk, not rarity
• Validating scenario classes instead of individual cases
• Using simulation and data-efficient methods at scale
• Relying on runtime safeguards and continuous learning
• Making residual risk explicit and defensible
• Lastly most important operational safety both from external and internal aspects during pre/post deployment

This approach accepts that rare scenarios cannot all be tested, but ensures that the most dangerous ones are addressed in a way that is both technically sound and economically viable.

Automotive IQ: Integrating SOTIF with functional safety and cyber security is a growing priority. What steps can organisations take to make sure these activities are aligned rather than handled in silos?

Abhash: To avoid siloed efforts and ensure that SOTIF, FuSa, V&V, data, and operations all work toward a single safety goal, organisations need structural, process, and cultural alignment. The most effective steps focus on shared artifacts, shared metrics, and shared accountability, rather than informal coordination. Organizations avoid siloed safety activities by:

• Defining a unifies System Management System for the overall development
• Defining a unified safety strategy
• Using shared scenario and hazard models
• Maintaining common safety artifacts and metrics
• Establishing cross-functional governance
• Closing the loop between field data and engineering
• Building shared competence and accountability

When alignment is achieved, safety activities reinforce each other - turning FuSa, SOTIF, and V&V into a coherent, defensible safety system rather than parallel efforts.

Automotive IQ: As automated driving functions become more capable and complex, what shifts do you think the industry needs to make to keep pace with evolving SOTIF requirements?

Abhash: To keep pace with evolving SOTIF requirements, the industry needs to make fundamental shifts in mindset, engineering practice, and governance. These shifts move safety from a static, compliance-driven activity toward a continuous, evidence-based risk management discipline suited to open-world automation.

• Requirement completeness to risk completeness
• Closed-world assumptions to open-world realism
• One-time validation to lifecycle assurance
• Deterministic correctness to probabilistic evidence
• Collaborative focus

Automotive IQ: What improvements, whether in tools, development methods, or regulatory guidance, would make SOTIF easier for companies to implement effectively?

Abhash: There is no easy way or shortcut for safety engineering. The biggest gains will come from reducing ambiguity, improving scalability, and increasing consistency across the industry. SOTIF becomes easier to implement when the industry:

• Has better tools for scenarios, uncertainty, and safety cases
• Uses risk-driven, lifecycle-aware development methods
• Receives clearer, example-driven regulatory guidance
• Collaborates across companies and with regulators

Together, these improvements turn SOTIF from a theoretical requirement into a repeatable, scalable, and auditable engineering practice.