The Importance of SOTIF Principles in Autonomous Robotics
This article examines why autonomous robotics requires Safety of the Intended Functionality (SOTIF) principles alongside traditional functional safety. It explores the relationship between SOTIF and Systems Theoretic Process Analysis (STPA), the importance of operational design domains and scenario discovery, and practical methods for addressing functional insufficiencies and triggering conditions in autonomous robots.
It was written by Jody Nelson, SRES Managing Partner and Co-Founder, a veteran safety leader with more than 24 years of experience advancing safety-critical automotive and autonomous systems for OEMs, Tier 1/2 suppliers, semiconductor companies, and organizations developing autonomous vehicles, robotics, and other Physical AI systems.
Looking to go deeper? Explore SRES’ ISO 21448 Safety of the Intended Functionality (SOTIF) Training and ISO/IEC TS 22440 Functional Safety and AI Systems Training. Need support beyond training? Explore our robotics safety consulting services.
When Functional Safety Wasn’t Enough
Before getting into why Safety of the Intended Functionality (SOTIF) principles are essential for autonomous robots that rely on machine learning, I want to step back to when I first encountered the ideas that would eventually become SOTIF. I began safety consulting in 2009, and by 2012 we were working with our first autonomous vehicle customer. At the time, our focus was applying ISO 26262 to autonomy, but it quickly became clear that malfunction-based analysis alone could not explain or mitigate the kinds of misbehavior we were seeing. By 2013 we expanded into multiple autonomy projects across automotive and robotics, and the need for something more than functional safety was clear. SOTIF did not yet exist. Its development did not begin until 2016, with the first PAS drafts appearing in 2018 before the official ISO/PAS 21448 release in early 2019 and the full First Edition in 2022.
Without SOTIF in 2013, we relied heavily on Systems Theoretic Process Analysis (STPA). Originating at MIT in the early 2000s, STPA gained major momentum after Nancy Leveson published Engineering a Safer World in 2012. It provided a powerful, systems-thinking analysis method that helped us move beyond fault-based reasoning to examine unsafe interactions between subsystems, human-machine misunderstandings, and reasonably foreseeable misuse. However, STPA was only an analysis technique; it did not provide the full, end-to-end framework that SOTIF would later define for managing hazards stemming from intended functionality. Still, ISO 21448 ultimately adopted a highly compatible worldview. SOTIF’s focus on triggering conditions, functional insufficiencies, and scenario-based hazard discovery aligns perfectly with STPA’s concepts of unsafe control actions (UCAs) and causal analysis. STPA pioneered the systems-level perspective that SOTIF later required.
The Missing SOTIF Framework in Robotics
While automotive eventually received a structured framework through ISO 21448, robotics never gained a direct equivalent. Autonomous robots now rely on the exact same types of perception pipelines, machine-learning models, and nondeterministic behaviors that drove the creation of SOTIF, though a direct equivalent has not yet emerged within robotics standards. It is true that the scope of IEC 61508 requires engineers to identify hazards under “all reasonably foreseeable circumstances,” but demanding an outcome is not the same as providing a methodology. IEC 61508 contains broad statements touching on intended functionality, but it offers no actual infrastructure for handling perception insufficiencies, environmental triggering conditions, or ML-driven misbehavior. Similarly, industrial standards like IEC 62998 introduce SOTIF-like concepts for safety-related sensors, but are strictly limited to perception hardware and ignore the complex decision-making of the full autonomy stack. As a result, the robotics industry is currently facing SOTIF-class problems without a SOTIF-class framework.
To see exactly why this gap matters, we have to look at what a “SOTIF-class problem” actually looks like on the warehouse floor or out in the field.
Traditional functional safety, governed by standards like IEC 61508, is highly effective at managing faults. If a lidar motor burns out, a memory leak crashes the navigation node, or a wire degrades, traditional safety mechanisms handle it. The system detects the broken component and transitions to a safe state.
But with machine learning and advanced perception pipelines, the hardware can work perfectly, the code can execute exactly as written, and the robot can still do something dangerous. These are functional insufficiencies. Consider an Autonomous Mobile Robot (AMR) navigating a warehouse. If a skylight casts a harsh glare onto a recently polished concrete floor, the perception system might interpret the reflection as a drop-off or an obstacle, triggering an aggressive emergency stop right in the path of a human-driven forklift. Alternatively, an agricultural robot trained primarily in sunny, dry conditions might fail to distinguish a human worker from a crop when facing the low-angle, hazy sun of an autumn morning. In both cases, nothing “broke.” The system simply encountered a scenario its models were not equipped to handle safely.
The ODD and the Unknown-Unsafes
Tackling these functional insufficiencies requires robotics engineers to embrace two core SOTIF concepts: the Operational Design Domain (ODD) and the Scenario Space.
In robotics, systems are often deployed with loosely defined operating environments. A robot might be designed for “indoor warehouses,” but that definition is dangerously broad. What happens when a bay door is left open, flooding the sensors with direct sunlight? What happens when a facility changes its flooring material, or workers start wearing a new type of high-visibility gear that confuses the object classifier? SOTIF forces us to explicitly define the ODD, the exact conditions under which the system is designed to function safely, and systematically identify the “triggering conditions” that push the robot outside of those bounds. Robotics also introduces complex human‑robot interaction patterns that can create unsafe scenarios even when perception and planning behave as designed.
This ties directly into the SOTIF Scenario Space, which categorizes scenarios into known/unknown and safe/unsafe areas. The primary goal of SOTIF is to shrink the “Unknown-Unsafe” space. Traditional testing only validates what we already know to look for. SOTIF provides the methodology to systematically uncover the edge cases we haven’t thought of yet, transforming them into “Known-Unsafes” that can be engineered around or restricted by the ODD.
Bridging the Gap with STPA
Since the standards bodies have not yet formalized a robotics-specific equivalent to ISO 21448, safety engineers cannot afford to wait. The most effective approach right now is to borrow the architecture of automotive SOTIF and execute it using the tools we already have, which brings us right back to STPA.
STPA remains the ideal bridge. Because it is a top-down, systems-thinking approach, it does not require a failure to exist to find a hazard. You can use STPA today to systematically brainstorm the exact triggering conditions and unsafe control actions your ML models will face in the real world. By treating the environment, the human operators, and the perception models as interacting control loops, STPA helps uncover those “Unknown-Unsafe” scenarios before the robot leaves the facility.
The robotics industry must move beyond relying purely on FMEAs and fault trees for machine learning systems. Those tools will meticulously tell you how your system breaks, but they will never tell you how it misbehaves when operating exactly as designed. Proactively applying SOTIF principles is the only rigorous way to deploy autonomous robots that are truly safe, regardless of what the current standards mandate. In practice, this means defining strict ODDs, analyzing functional insufficiencies, and using STPA to discover triggering conditions.
Expanding Risk Reduction with FI2TC Analysis
Fulfilling the requirements of core robotics standards like ISO 12100 and ISO 10218 requires us to identify every possible risk reduction measure. Traditional hazard analysis techniques, like the risk graphs provided in IEC 61508, are highly effective at uncovering the measures required for traditional faults. To move beyond faults and address intended functionality, we use Functional Insufficiencies to Triggering Conditions (FI2TC) analysis. This specific analysis expands our list of necessary risk reduction measures to fully cover the SOTIF aspects of safety. It takes the abstract concept of a perception failure and maps it to a concrete triggering condition, allowing engineers to design mitigations that make autonomous robots genuinely safe for public and industrial use.Moving Robotics Toward a SOTIF‑Ready Future
Robotics cannot wait for a formal SOTIF standard to appear. Autonomous systems are already operating in warehouses, hospitals, farms, and public spaces, and they are already encountering the same perception limits, environmental edge cases, and ML‑driven behaviors that motivated the creation of ISO 21448 in automotive. The responsibility falls on robotics engineers to proactively adopt SOTIF principles today, even in the absence of a dedicated standard. That means defining clear ODDs, identifying functional insufficiencies, expanding scenario discovery, and applying systems‑thinking tools like STPA and FI2TC to uncover triggering conditions before deployment. The combination of these methods provides a practical, defensible way to manage intended‑functionality hazards across the full autonomy stack. As the industry continues to push robots into increasingly complex environments, embracing SOTIF‑class thinking is not just good engineering practice; it provides the essential framework needed to ensure that autonomous robots behave safely, reliably, and predictably in the real world.Have insights or questions? Send us an email at info@sres.ai or leave a comment below—we welcome thoughtful discussion from our technical community.
Interested in learning more about our approach? Explore why teams choose SRES training and how we support organizations with consulting for Automotive and Physical AI applications.
