VisualPro Tech Brief
Applying STPA to Support ISO/PAS 8800
A worked example of safety analysis for an AI-based vehicle function using VisualPro STPA and MCP
AI Safety Analysis | STPA and MCP Integration | VWAY White Paper Digest
ISO/PAS 8800STPAISO 26262ISO 21448MCP
The example in this document is hypothetical, for explanation only, and is not real vehicle data.
01Overview (TL;DR) — The Standard Names No Method; STPA Fills the Slot
ISO/PAS 8800:2024 (Road vehicles — Safety and artificial intelligence), the first automotive standard to address the safety of AI systems, does not prescribe an analysis technique. Instead it requires that you identify the paths by which an AI component’s performance insufficiency becomes a vehicle-level hazard, and connect the result to AI safety requirements and a safety argument.
STPA answers that requirement directly. Place the AI component as a controller inside the control structure, and AI-specific error causes — training-data bias, distribution shift, confidence miscalibration — fall into STPA’s standard category of “process model flaws.” Unlike FMEA and FTA, which struggle with software errors that have no failure rate, STPA takes unsafe control actions that occur without any failure as its analysis subject from the start.
This white paper uses a pedestrian-recognition AEB based on a camera neural network as a hypothetical example and builds the analysis in the VisualPro STPA module through MCP.
| Item | Count | Note |
|---|
| Losses | 4 | Pedestrian casualty, occupant injury, property damage, loss of trust and regulatory conformity |
| Hazards | 4 | Collision-avoidance distance not maintained, unnecessary hard deceleration, unclear control authority, operation outside ODD |
| System constraints | 4 | One per hazard |
| Control actions | 5 | One of them is the AI component’s output |
| Unsafe control actions (UCA) | 12 | Five on the AI component’s output |
| Loss scenarios | 16 | Nine with causes specific to the AI component |
| Countermeasures | 10 | In the form of AI safety requirements |
35 MCP calls, 0 failures. Of the 16 loss scenarios, 9 had causes specific to the AI component (dataset representativeness, out-of-distribution input, confidence calibration, robustness, execution time, tracking under occlusion, and post-deployment performance degradation), and those 9 connect directly to the data, verification, and monitoring activities of 8800. The 10 countermeasures take the form of AI safety requirements as 8800 describes them, and every one of the 16 loss scenarios is linked to at least one countermeasure.
A neural network missing a pedestrian in nighttime backlight is not a failure. The model behaved as designed and as trained; the training simply did not represent that situation.
[ [Figure 1] Pedestrian-recognition AEB control structure. The AI component (Pedestrian Recognition AI Module) is placed as a separate controller and its output is modeled as a control action. ]
02Why STPA — Three Reasons the Standard Needs It
1The Subject Is the AI System, Not the ItemScope
ISO/PAS 8800 applies to AI systems that implement or influence safety-related functions within the electrical and electronic systems of road vehicles. Measured against the item as ISO 26262 defines it, the scope is limited to the elements of that item that contain AI. The standard presupposes that the item lies within the scope of ISO 26262 (functional safety) and ISO 21448 (SOTIF): item-level hazard analysis and safety goals come from those two, and 8800 begins where AI safety requirements are derived from them. Safety-unrelated AI, systems that keep learning in operation, and cybersecurity (the ISO/SAE 21434 domain) are out of scope.
2AI Errors Are Not FailuresCore thesis
Traditional safety analysis starts from component failures: FMEA enumerates failure modes, FTA combines failure probabilities. But the class of error that ISO 21448 calls a “functional insufficiency” and ISO/PAS 8800 calls a “performance insufficiency” occurs without any failure rate. STPA was built from the outset to analyze accidents without failures. An unsafe control action includes cases where a controller operating normally issues a command inappropriate to the situation, and loss scenarios seek the cause in four categories: process model flaws, inadequate feedback, inadequate control execution, and controlled-process anomalies. In this frame a trained neural network is “the controller’s process model.”
3The AI Safety Analysis Activity Names No MethodThe open slot
The standard’s activities reduce to six: derivation of AI safety requirements, selection of AI technology and architecture, dataset requirements and management, verification and validation of the AI component, AI safety analysis, and safety argument with post-deployment monitoring. Among these, the “AI safety analysis” activity prescribes no technique — any method that systematically finds the paths from AI error causes to hazards will serve. This white paper proposes STPA for that slot.
03What ISO/PAS 8800 Requires and How STPA Answers
Six Activities of the AI Safety Lifecycle
| Activity | Requirement | Deliverable |
|---|
| Derivation of AI safety requirements | Derive requirements the AI system and component must satisfy from item safety requirements and the ODD | AI safety requirements, ODD definition |
| Selection of AI technology and architecture | Contain performance insufficiency through design measures such as monitors, redundancy, and uncertainty estimation | Architectural measures |
| Dataset requirements and management | Specify and demonstrate representativeness, label quality, distribution coverage, and inclusion of vulnerable cases | Data specification, datasets |
| Verification and validation of the AI component | Measure performance insufficiency; test robustness and distribution shift | Test results, acceptance criteria |
| AI safety analysis | Identify AI-specific causes such as performance insufficiency, distribution shift, ODD departure, and false confidence, and analyze causal paths to hazards | Cause and path analysis results |
| Safety argument and post-deployment monitoring | Assemble evidence into an argument; monitor field degradation; manage retraining and re-verification | Safety case, field metrics |
Mapping STPA Elements to 8800 Concepts
| STPA element | ISO/PAS 8800 concept | Correspondence |
|---|
| Controller | AI system, AI component | The controller containing the AI component, or the AI component itself, is placed as a controller |
| Process model | Internal representation of the trained model | Most performance insufficiencies are expressed as process model flaws |
| Control algorithm | Inference logic, post-processing, decision thresholds | Confidence thresholds and fusion rules belong here |
| UCA | Unsafe behavior caused by AI output | Missed detection, false detection, latency, and tracking loss match the four UCA types |
| Loss scenario | AI error causes, trigger conditions | Distribution shift, ODD departure, data bias, confidence miscalibration, sensor degradation |
| System constraint | Item-level safety requirements | The starting point for deriving AI safety requirements |
| Countermeasure | AI safety requirements, design measures, dataset requirements | Derived per loss scenario, maintaining the trace line |
| Control structure | AI system architecture, ODD boundary | Placing environment elements in the control structure makes the ODD boundary explicit |
Compared with established techniques FMEA/FTA start from component failure modes, handle failure-free errors poorly, and need a separate extension to express 8800’s performance insufficiency. HAZOP needs its guide words redefined. In STPA, failure-free errors are the default subject, performance insufficiency is expressed naturally as a process model flaw, and system constraints and countermeasures emerge in requirement form.
STPA does, however, not quantify probability of occurrence, so 8800’s verification and validation activities must still rely on quantitative testing and data coverage metrics. STPA does its work upstream, deciding what must be tested and which requirements are needed.
04Hypothetical Example: What Came Out of the Pedestrian-Recognition AEB
The example is an AEB-P function that processes front-camera video with a neural network to recognize pedestrians and performs automatic emergency braking. The AI component is the Pedestrian Recognition AI Module (producing pedestrian position, TTC, and confidence from video frames); the decision controller is the AEB Decision Controller (fusing the detection result with radar and vehicle state to decide on warnings and emergency braking); the rest is the front camera, front radar, brake actuator, the driver, and the road environment. ODD assumptions: urban and suburban roads, day and night, vehicle speed 10 to 60 km/h, weather conditions in which the camera field of view is clear.
Modeling the AI Component’s Output as a Control Action Pairs the Four UCA Types with Performance Insufficiency
| UCA type | AI performance insufficiency | UCA in the example |
|---|
| Not provided | Missed detection (false negative) | Pedestrian present but no detection result |
| Provided unsafely | False detection (false positive), confidence miscalibration | Detection with no pedestrian present; low confidence reported as high |
| Too early or too late | Latency, dropped frames | Detection result arrives after the TTC limit |
| Stopped too soon or applied too long | Tracking loss, ghost tracks | Detection drops out during occlusion |
Where the error types of a detector would otherwise be brainstormed freely, this puts in place a procedure that asks the four types systematically for every control action — a mechanism that guarantees completeness of the analysis. Applying the four UCA types widened the subject from missed and false detections to latency, tracking loss, and confidence miscalibration, and 5 of the 12 UCAs landed on the AI component’s output.
Representative Loss Scenarios — AI-Specific Causes Map Straight to 8800 Topics
| ID | Guide word class | Loss scenario | 8800 topic |
|---|
| LS-1 | Class 1 process model | Believes there is no pedestrian ahead in a nighttime backlit frame, but a pedestrian is crossing. Training data lacked night and backlight samples | Dataset representativeness / distribution shift |
| LS-4 | Class 1 algorithm | Interprets a billboard printed with a picture of a pedestrian as a “crossing pedestrian.” No mechanism to distinguish out-of-distribution input | Out-of-distribution (OOD) detection |
| LS-6 | Class 3 control execution | Detection result delayed by inference overrun on high-resolution frames and bus congestion, arriving after the TTC braking limit | Execution time budget / scheduling |
| LS-8 | Class 1 algorithm | Output layer interprets an out-of-distribution input as a “pedestrian with confidence 0.95.” Confidence not calibrated to actual accuracy | Uncertainty estimation / confidence calibration |
| LS-16 | Class 4 controlled process | Camera mounting angle drifts gradually, but the module keeps relying on the initial calibration assumption. Post-deployment degradation not monitored | Post-deployment monitoring / performance degradation |
Eleven of the 16 belong to Class 1 (inadequate controller behavior), and most of those are flaws in the trained process model and the algorithm. The loss scenarios of an AI system cluster inside the controller — in the trained process model and the decision algorithm — rather than in feedback failures. The reason 8800 weights dataset requirements and uncertainty estimation so heavily is confirmed directly by the STPA result.
Countermeasures Become the First Draft of AI Safety Requirements
| ID | Countermeasure (AI safety requirement) | Scenarios | 8800 activity |
|---|
| CM-1 | Define minimum sample counts and coverage metrics per lighting condition, weather, and pedestrian type, and demonstrate that they are met | LS-1, LS-2 | Data specification and management |
| CM-2 | ODD monitor: when illuminance, lens contamination, or blur metrics fall outside the ODD range, limit the function and notify the driver | LS-3, LS-15 | ODD definition and monitoring |
| CM-3 | Calibrate confidence with an out-of-distribution detector and uncertainty estimation, and pass only calibrated confidence to the decision controller | LS-4, LS-8 | Uncertainty estimation |
| CM-6 | Set an inference execution time budget with WCET monitoring, and transition to a safe state when the deadline is exceeded | LS-6 | AI component verification |
| CM-10 | Field monitoring: collect false and missed detection events and calibration deviations, and operate performance degradation alerts and retraining triggers | LS-1, LS-14, LS-16 | Post-deployment monitoring |
The trace line is the rationale Because “what must the dataset contain,” “which monitors are needed,” and “which tests must pass” come out of the loss scenarios with their rationale, the countermeasure statements serve directly as the first draft of AI safety requirements. The “rationale for the requirement” that 8800 demands is secured automatically by the STPA trace line. If a scenario remains in the traceability matrix with no countermeasure, read it as a missed requirement — in this example all 16 were linked.
[ [Figure 2] Mapping of ISO/PAS 8800 activities to STPA deliverables. The AI safety analysis activity connects to STPA’s central deliverables. ]
05How VisualPro STPA Supports It
The AI Component as a Controller, Its Output as a Control ActionModeling
Because the AI component exists as a separate controller in the control structure, UCAs can be asked of its output. With the road environment included as a component, ODD variables such as lighting, weather, and pedestrian type appear as the origin of feedback paths, and the driver’s enable/disable control action brings human-AI interaction scenarios into scope.
From Guide Word Archetypes to Loss ScenariosCompleteness
Loss scenarios are written by choosing an archetype sentence from VisualPro’s guide word set (Developing Loss Scenarios by MIT) and filling the placeholders with the example’s specifics. Because the archetype-to-scenario correspondence is retained, the derivation rationale survives a change of analyst.
The Trace Chain Forms the Backbone of the Safety ArgumentCore value
Loss to hazard to system constraint, and hazard to UCA to loss scenario to countermeasure, are stored as relations. That chain is the evidence for “why is this requirement needed” in the 8800 safety argument, and no separate compilation of rationale is required.
MCP Integration — The Analysis Is Reproducible as a ScriptAutomation
The VisualPro STPA module lets an external agent read and write analysis items through an MCP (Model Context Protocol) server. The example was built from a single script in 35 calls with 0 failures. When a dataset version or the ODD changes, the same procedure regenerates the analysis and the differences can be compared.
06Frequently Asked Questions (FAQ)
Q1Which systems does ISO/PAS 8800 apply to?
AI systems, and their AI components, that implement or influence safety-related functions within the electrical and electronic systems of road vehicles. The scope is not the whole item but the parts of it that contain AI, and that item must lie within the scope of ISO 26262 and ISO 21448.
Q2Is STPA mandatory under ISO/PAS 8800?
No. The standard requires an AI safety analysis activity but does not specify a technique. STPA can treat failure-free AI performance insufficiency as a flaw in the controller’s process model, which makes it well suited to filling that activity.
Q3Are FMEA and FTA not enough?
They fall short in places. Both start from component failures, so they struggle to express errors that arise without a failure rate, such as training-data bias or distribution shift. They remain useful for quantitative evaluation, so using them alongside STPA is the realistic approach.
Q4Why model the AI component’s output as a control action?
Because the four UCA types (not provided, provided unsafely, wrong timing, wrong duration) coincide with the AI performance insufficiency types of missed detection, false detection, latency, and tracking loss. Asking the four types systematically for every control action raises the completeness of the analysis.
Q5What can be done with MCP in VisualPro STPA?
An external agent can create and query losses, hazards, system constraints, the control structure, UCAs, loss scenarios, countermeasures, and their relations. The example in this white paper built the entire analysis in 35 calls, and the same script can reproduce it at any time.
07Start Now (Next Step)
The example here is hypothetical; in real application the ODD definition and dataset specification must be far more precise. STPA gives no probability of occurrence, so quantitative metrics for 8800’s verification and validation must be secured separately. As next steps, VWAY is considering adding an AI-specific guide word set, an AI component marker attribute, and export of countermeasures as AI safety requirements to VisualPro STPA.
What ISO/PAS 8800 asks for is the path by which an AI error becomes a hazard, and the rationale behind it. Start AI safety analysis with STPA, which takes that path as its subject from the beginning, and with VisualPro, which keeps the result as traceable data.
The path from AI error to hazard, with its rationale — meeting ISO/PAS 8800 with VisualPro STPA.
Referenced standards: ISO/PAS 8800:2024, Road vehicles — Safety and artificial intelligence · ISO 26262:2018 · ISO 21448:2022 · ISO/IEC TR 5469:2024 · Leveson, N. G., Thomas, J. P., STPA Handbook, MIT, 2018 · Source: VWAY White Paper “Applying STPA to Support ISO/PAS 8800” (2026-09-11)
VisualPro Inquiries & Demo
ISO/PAS 8800:2024 (Road vehicles — Safety and artificial intelligence), the first automotive standard to address the safety of AI systems, does not prescribe an analysis technique. Instead it requires that you identify the paths by which an AI component’s performance insufficiency becomes a vehicle-level hazard, and connect the result to AI safety requirements and a safety argument.
STPA answers that requirement directly. Place the AI component as a controller inside the control structure, and AI-specific error causes — training-data bias, distribution shift, confidence miscalibration — fall into STPA’s standard category of “process model flaws.” Unlike FMEA and FTA, which struggle with software errors that have no failure rate, STPA takes unsafe control actions that occur without any failure as its analysis subject from the start.
This white paper uses a pedestrian-recognition AEB based on a camera neural network as a hypothetical example and builds the analysis in the VisualPro STPA module through MCP.
35 MCP calls, 0 failures. Of the 16 loss scenarios, 9 had causes specific to the AI component (dataset representativeness, out-of-distribution input, confidence calibration, robustness, execution time, tracking under occlusion, and post-deployment performance degradation), and those 9 connect directly to the data, verification, and monitoring activities of 8800. The 10 countermeasures take the form of AI safety requirements as 8800 describes them, and every one of the 16 loss scenarios is linked to at least one countermeasure.
STPA does, however, not quantify probability of occurrence, so 8800’s verification and validation activities must still rely on quantitative testing and data coverage metrics. STPA does its work upstream, deciding what must be tested and which requirements are needed.
The example is an AEB-P function that processes front-camera video with a neural network to recognize pedestrians and performs automatic emergency braking. The AI component is the Pedestrian Recognition AI Module (producing pedestrian position, TTC, and confidence from video frames); the decision controller is the AEB Decision Controller (fusing the detection result with radar and vehicle state to decide on warnings and emergency braking); the rest is the front camera, front radar, brake actuator, the driver, and the road environment. ODD assumptions: urban and suburban roads, day and night, vehicle speed 10 to 60 km/h, weather conditions in which the camera field of view is clear.
Where the error types of a detector would otherwise be brainstormed freely, this puts in place a procedure that asks the four types systematically for every control action — a mechanism that guarantees completeness of the analysis. Applying the four UCA types widened the subject from missed and false detections to latency, tracking loss, and confidence miscalibration, and 5 of the 12 UCAs landed on the AI component’s output.
Eleven of the 16 belong to Class 1 (inadequate controller behavior), and most of those are flaws in the trained process model and the algorithm. The loss scenarios of an AI system cluster inside the controller — in the trained process model and the decision algorithm — rather than in feedback failures. The reason 8800 weights dataset requirements and uncertainty estimation so heavily is confirmed directly by the STPA result.
The example here is hypothetical; in real application the ODD definition and dataset specification must be far more precise. STPA gives no probability of occurrence, so quantitative metrics for 8800’s verification and validation must be secured separately. As next steps, VWAY is considering adding an AI-specific guide word set, an AI component marker attribute, and export of countermeasures as AI safety requirements to VisualPro STPA.
What ISO/PAS 8800 asks for is the path by which an AI error becomes a hazard, and the rationale behind it. Start AI safety analysis with STPA, which takes that path as its subject from the beginning, and with VisualPro, which keeps the result as traceable data.