Imagine an autonomous truck braking hard on a clear highway, not for a stopped vehicle, not for heavy debris, but for an empty plastic bag blowing across the lane. Every sensor is functioning. Every algorithm is executing as designed. And yet the outcome is unsafe.
This is the central paradox of modern autonomy: a system can do everything right and still do the wrong thing. The industry standard SOTIF (Safety of the Intended Functionality) gives this gap a name: the “unknown unsafe” region, where the system seems like it performed as intended yet the outcome is still unsafe.
But naming a problem is not the same as solving it. To systematically shrink this unknown unsafe region to an acceptable minimum, PlusAI has built a rigorous, repeatable engine for discovery: the PlusAI Safety Analysis Framework (SAF). Not only does it find risks, it creates a safety system that gets smarter with every mile our trucks drive.
Safety as a Control Problem
Historically, automotive safety asked a simple question: which part broke, and what happens next? For hardware failures, that’s the right question. For SOTIF failures, where everything is technically working, it misses the point.
This is where Systems-Theoretic Process Analysis (STPA) comes in. Rooted in control theory, STPA reframes safety not as a component reliability issue but as a control problem. Rather than hunting for a severed wire or a failed sensor, STPA models the entire autonomous vehicle as an interconnected control hierarchy.
- The Environment is the physical world the truck moves through: roads, weather, other drivers.
- The Sensors (cameras, lidar, and radar) observe the environment and feed raw data to the system.
- The ADS Controller and Process Model form the brain. The Autonomous Driving System (ADS) ingests sensor data and builds a “Process Model”: an internal belief about what is happening in the world at any given moment.
- The Actuators (steering, braking, throttle) execute whatever the brain decides.
Using this framework, PlusAI engineers analyze the interactions between these layers to identify Unsafe Control Actions (UCAs): moments when the controller issues a command that is dangerous in a specific context. A UCA might be defined as: “The ADS issues a braking command when none is required.”
Every UCA can be traced back to a flaw in one of these layers. When a UCA originates in the Process Model, in a specific software component such as Perception or Localization, we call it a Loss Scenario. In the plastic bag example, STPA frames it as:
The ADS issues a braking command when not required because the Perception module wrongly identifies a lightweight plastic bag blowing across the road as a hazardous solid obstacle.
That framing transforms a mysterious, hard-to-reproduce incident into something an engineer can actually work with.
Where STPA Meets SOTIF
STPA is powerful at identifying what unsafe action occurred within the system architecture. SOTIF is powerful at explaining why it occurred in the physical world. The PlusAI SAF unites the two.
Once a UCA is identified using STPA, engineers trace it back through the control loop to find the root cause. The sensors may be functioning flawlessly, but the Process Model has formed an incorrect internal belief about the environment, and that error propagates through the system until it becomes an unsafe action. The root cause might lie in the environment, the sensors, or the control algorithm itself.
To make these failure modes actionable for software developers, PlusAI SAF breaks every Loss Scenario into three components drawn from the SOTIF standard:
- Functional Insufficiency (FI) is the root limitation — the flaw in the algorithm or process model itself.
- Triggering Condition (TC) is the specific real-world event that exposes the flaw: a weather anomaly, an unusual object, a particular lighting condition.
- Functional Scenario (FS) is the broader operational context: the road type, traffic situation, and environment the truck is navigating when the failure occurs.
We described a shadow example in Part One of this blog series. Applying this to our plastic bag example now, the PlusAI SAF breaks it down as follows:
Loss Scenario: The ADS issues a braking command when not required, because the perception system wrongly identifies a lightweight plastic bag as a hazardous solid obstacle.
- FI (The Flaw): The perception module cannot reliably determine the hazardous nature of lightweight, wind-blown debris.
- TC (The Trigger): A large, empty plastic bag blows across the highway lane directly in the vehicle’s path.
- FS (The Situation): The autonomous truck is traveling at highway speed with a human-driven car closely following behind.
From Safety Goals to Actionable Code
This decomposition bridges the gap between safety analysts and software engineers, translating abstract risk into precise, testable requirements.
Without this framework, a safety mandate might read simply as: “Prevent unintended braking.” That instruction is nearly impossible to act on. You cannot train an AI model against a general directive. Run the same mandate through the PlusAI SAF methodology, and it becomes something an engineer can build and test against:
The perception module shall distinguish low-mass, non-hazardous debris from physical obstacles.
That precision is what enables PlusAI to design targeted simulation tests, train AI models on the specific edge cases that matter, and close the gaps in the system’s reasoning.
The Living Safety Case
The hardest challenge in autonomous trucking isn’t the known risks. It’s the “unknown unknowns” — the bizarre, one-in-a-million scenarios that no engineering team can fully anticipate when 80,000-pound trucks are running routes continuously, in every season, across every road type.
PlusAI SAF is designed for this reality. Rather than producing a static safety document at the start of a program, it creates what we call a Living Safety Case: a continuously evolving model that learns from every new mile driven.
Consider what happens when a SuperDrive™ truck encounters a rare condition: wind-blown dust from a nearby construction zone briefly obscures the lane ahead. Out of caution, the truck slows more than necessary. With PlusAI SAF infrastructure in place, that event doesn’t just get logged and forgotten. Engineers identify the “wind-blown dust cloud” as a newly discovered Triggering Condition. They surface the exposed Functional Insufficiency: under certain low-visibility dust conditions, the ADS overestimates the likelihood of a solid obstacle. They update the STPA model and add this scenario to the safety analysis, feeding it back into simulation testing and targeted software improvements.
What was once an unpredictable one-off becomes a repeatable, documented, mitigated scenario. Safety analysis transforms from a one-time engineering exercise into a continuous, data-driven loop that gets sharper and more complete with every route completed.
What Comes Next
By uniting the structural logic of STPA with the real-world scenario analysis of SOTIF, the PlusAI Safety Analysis Framework gives us a repeatable, rigorous method for discovering, analyzing, and mitigating risk in autonomous trucking. It is a systematic answer to the central challenge SOTIF identifies: you cannot eliminate what you cannot name.
This foundation raises deeper questions. How safe is safe enough, and how do we quantify that for a Class 8 truck operating at highway speed? How much real-world testing is actually required? And how does this methodology scale as PlusAI expands to new routes, weather profiles, and geographies?
We’ll address these in the next installments of the PlusAI SAF series.