STPASTPA Mentioned in ISO 26262, and VisualPro Supporting All Safety Analyses
01Summary
02STPA is mentioned in the ISO/DIS 26262 third-edition draft
The third edition of ISO 26262 is at the Draft International Standard stage. The ballot opened on October 14, 2026 and closes on January 6, 2027, and wording and clause numbers can still change after that. This article is based on Parts 1 to 10 of the draft. Part 11 (semiconductors) and Part 12 (motorcycles) were not reviewed.
STPA is mentioned in two places in the body text of the ten parts.
| Where | What it says | Nature |
|---|---|---|
| Part 9, Clause 8.2 (Safety analyses, General) | List of qualitative analysis methods: qualitative FMEA, qualitative FTA, HAZOP, STPA (see SAE J3187), qualitative ETA | A list of examples in explanatory text |
| NOTE in Part 10, Clause 13.6.1 | For exploring hazardous scenarios, methods such as STPA in Part 9 can be used | A NOTE in the clause on the interaction between functional safety and SOTIF |
The list in Part 9 is explanatory text that opens with "include, but are not limited to." STPA does not appear in the requirement clauses (8.4). The method tables in Parts 4 and 5 recommend inductive and deductive analysis by ASIL, and Part 6 only says to follow Part 9, Clause 8. The draft does not classify STPA as either inductive or deductive. An organization that wants to claim it has met those table recommendations with STPA has to provide its own rationale.
In short, in the third-edition draft STPA is a method "mentioned in the body of the standard as a qualitative safety analysis method that can be used." The same list in Part 9 of the 2018 edition did not include STPA. One more point: Clause 8.4.1 requires safety analyses to be performed in accordance with appropriate standards or guidelines. For an organization that chooses STPA, SAE J3187, which the draft references, serves as that guideline.
03What ISO 26262 requires
ISO 26262 is the functional safety standard for preventing harm caused by malfunctioning electrical and electronic (E/E) systems in road vehicles. It adapts the cross-industry standard IEC 61508 to automotive use, with a first edition in 2011 and a second in 2018.
The overall flow starts with the hazard analysis and risk assessment (HARA), where each hazardous event is rated for severity (S), exposure (E) and controllability (C) to determine an ASIL from A to D, and safety goals are set. Safety goals are refined into functional safety requirements and allocated to the system, hardware and software. At each stage, safety analyses check whether the design could violate its requirements, and testing and confirmation measures complete the work. In the third-edition draft, the values in the ASIL determination table, the hardware metric targets (SPFM, LFM, PMHF) and the recommendation levels for inductive and deductive analysis are unchanged. Because this is a DIS, they may still differ in the final edition.
The foreword of the draft lists eight main changes. Three of them relate to safety analysis.
- The interaction with the safety of the intended functionality (SOTIF, ISO 21448) is defined
- The interaction with other technologies (OT: mechanical, hydraulic, chemical and other non-E/E technologies) is defined
- Predictive maintenance is included
04The context in which STPA was added
The draft does not explain why STPA was added. Reading the sentences in the same Clause 8, though, shows where STPA would be used.
Clause 8.1 puts "identifying new hazards not previously identified during the hazard analysis and risk assessment" first in its list of what safety analyses do, depending on the application. Clause 8.4.5 requires hazards found that way to be included in an updated HARA.
Clause 8.4.9 names three origins of the faults and failures that qualitative analysis has to identify systematically: the item or element itself, its interaction with other items or elements, and its usage.
Clauses 8.2 and 8.4.9 describe the requirements a fault or failure could violate as "including SOTIF-relevant requirements." Hazards that arise without any failure are still handled by ISO 21448, but the two analyses now look at the same requirements.
FMEA starts from the failure modes of a component and follows the effects upward, and FTA works down from a top event to combinations of causes. Both are good at asking what fails. STPA starts somewhere else. It models the controllers, the controlled process, and the control actions and feedback between them as a control structure, and then looks for control actions that lead to a hazard in a particular context (unsafe control actions, UCAs) and for the scenarios that produce them. A required control action that is not provided is also a UCA, and STPA covers both the case where nothing has failed and the case where a failure is involved. Problems between the driver and the system, and between one system and another, show up here. That is the area the second point above refers to.
| Method | What it finds well | What it covers less |
|---|---|---|
| FMEA (mostly inductive) | What happens if this component or function fails this way | When done by component and failure mode, interactions between elements are easily missed (partly covered by function and interface FMEA) |
| FTA (mostly deductive) | Which combinations of failures cause this event, and how likely it is | Causes that are hard to express as failure events, such as elements that each work correctly but are hazardous in combination |
| HAZOP | Causes and consequences of deviations from design intent (more, less, late and so on) | Structuring scenarios where a controller's decisions and feedback are intertwined |
| Dependent failure analysis (DFA) | Causes that make two supposedly independent elements fail together, or let one failure propagate to the other | Functional faults of an individual element |
| STPA | Control actions that become hazardous in a particular context, interactions and context of use | Failure rates and hardware metric calculation. The number of scenarios is large, so screening takes effort |
STPA does not replace FMEA or FTA. Hardware metrics are still calculated with quantitative FMEA (FMEDA) and FTA, and the draft leaves that part unchanged. Nor is STPA the only method that addresses interactions. HAZOP, in the same list, does that too. STPA fits best where the control structure is complex and human and software decisions are intertwined.
05The number of safety analyses to perform is growing
Read clause by clause, the draft asks for a number of analyses on a single item and for links between them. Adding STPA increases that number. The clause numbers below are those of the DIS and may change in the final edition.
| What the draft says | Clause | What it means in practice |
|---|---|---|
| Technology-related hazards that E/E systems help prevent or mitigate are also handled in the HARA | Part 3, 6.4.6 | If the item has such functions, hazards not caused by an E/E malfunction, such as electric shock, enter the HARA table |
| HARA verification checks consistency with other risk assessments | Part 3, 6.4.7.1 | If a SOTIF risk assessment or a cybersecurity TARA exists, compare it with the HARA |
| The requirements a fault or failure could violate include SOTIF-relevant requirements | Part 9, 8.2 and 8.4.9 | Link safety analysis entries to SOTIF-relevant requirements |
| Dependent failure analysis is an analysis distinct from the safety analyses | Part 9, 7.2 | Where independence or freedom from interference is required, present DFA results separately from safety analysis results. Leaving them as one column in an FMEA is not enough. Work products are listed for the system (Part 4, 6.5.7), hardware (Part 5, 7.5.3) and software (Part 6, 7.5.4) |
| Qualitative analysis identifies causes originating in interactions and usage | Part 9, 8.4.9 | Decide which analysis identifies those causes |
| Hazards newly identified by an analysis go into an updated HARA | Part 9, 8.4.5 | A link from the analysis entry to the HARA hazardous event, plus change management |
| Safety analysis tools are an example of tools subject to tool confidence evaluation | Part 8, Annex B.1 | Prepare the classification and qualification evidence for the analysis tool |
With STPA added, one item ends up with HARA, FMEA, FTA, DFA and STPA, and the results also have to be compared with the cybersecurity TARA. If each analysis lives in a different file and a different tool, the same hazardous event and the same safety goal are recorded separately in several places, and a change on one side does not reach the other. The draft also makes consistency between analysis results a requirement. The dependent failure analysis has to be consistent with the safety analysis results (Part 9, 7.4.1), newly identified hazards have to be included in the HARA (Part 9, 8.4.5), and the HARA has to be consistent with other risk assessments (Part 3, 6.4.7.1).
06VisualPro: several safety analyses in one project
VisualPro is the safety analysis tool developed by VWAY. It handles HARA, FMEA, FTA, STPA, CAST (accident causation analysis) and TARA together in one project. "All safety analyses" in the title of this article refers to these six. It does not mean VisualPro also covers HAZOP, ETA or Markov models from the draft's lists. Dependent failure analysis (DFA) will be added soon.
The STPA module follows the four steps of the MIT STPA Handbook: define the purpose of the analysis, model the control structure, identify unsafe control actions, and identify loss scenarios. It is listed among the STAMP Tools published by MIT PSASS. Being listed does not mean MIT has evaluated or endorsed it. VisualPro holds a tool certification from SGS-TÜV Saar (ISO 26262, IEC 61508, IEC 62304). This is material you can use in the situation described in the last row of the table above, when you are asked for the confidence evidence for the analysis tool itself. The certificate is an input to the tool classification and qualification that the user performs. It does not replace that evaluation.
07What AI does, and what people do
When the number of analyses grows, people's time runs short first. VisualPro provides an MCP (Model Context Protocol) connection, so an AI such as Claude can read the analysis data of the open project and create and save entries. The FMEA, FTA, STPA, TARA and HARA modules are connected.
We tried this in a tech brief we published in October 2026. In one training example of a driving assistance function, the AI read the control structure and the guide words and created and saved 17 loss scenarios. Six were single-archetype scenarios used as the baseline, and 11 were combined-archetype scenarios. When a person judged those 11, three led to a different countermeasure, three could have been found by picking more single archetypes, two partly overlapped existing scenarios, two were hypotheses that need a design check, and one was a duplicate. The AI produced a broad set of candidates, and a person judged against the design documents whether each candidate holds in the actual design. These results come from one example judged by the author, so it is too early to generalize.
Set against the draft's requirements, it looks like this. Part 9, Clause 8.4.8 requires the safety analyses and their outcomes to be verified, and Part 8, Clause 10.4.1 requires evaluation of a tool whose outputs are not sufficiently examined or verified. Having a person review every AI-created entry before it becomes a work product is meant to meet that condition. Part 8, Clause 10.4.1 also carries a NOTE that AI-based tools are subject to further considerations in specialized standards.
08What to check tomorrow
- Next to your current list of analyses, write the three origins in Part 9, Clause 8.4.9 (the element itself, interaction, usage) and mark which analysis covers each one. If an origin is not covered by any analysis, consider a method such as HAZOP or STPA.
- Where independence or freedom from interference is required, check whether you can present dependent failure analysis results separately from safety analysis results.
- Check that there is a procedure, and a record, for bringing a hazard newly found in an analysis into the HARA.
- Compare one hazardous event across the HARA, the SOTIF risk assessment and the TARA to see whether they record it differently.
- Collect the classification and qualification evidence for the safety analysis tools you use (certificates, known-issue lists, release notes).
- Decide how to record who reviewed each AI-created analysis entry, and when.
09Closing
In the third-edition draft, STPA is a mentioned method, not a required one. The draft requires qualitative analysis to identify causes that originate in interactions and usage, and it mentions STPA as a method that can be used for that requirement.
Managing the growing set of analyses separately makes it hard to keep them consistent. Handle the analyses together in one project, and have a person judge the candidates the AI produces.
10FAQ
Q1Once the third edition of ISO 26262 is published, will STPA be mandatory?
No. In the draft, STPA is only mentioned in the list of example qualitative analysis methods in Part 9, Clause 8.2. It is not in the requirement clauses or in the ASIL-dependent recommendation tables. Clause 8.4.9 does require qualitative analysis to identify causes that originate in interactions and usage. Each organization decides which method to use for that requirement, and STPA is one of the options the draft mentions.
Q2If we perform STPA, can we do less FMEA or FTA?
No. The hardware architectural metrics and PMHF are evaluated with quantitative analysis based on failure rates, and the draft keeps its recommendations for inductive and deductive analysis. The draft does not classify STPA as either inductive or deductive. STPA is used to find control actions and interactions that become hazardous in a particular context, alongside FMEA and FTA.
Q3What is SAE J3187, which the draft references?
It is an SAE document with recommended practices for applying STPA to the evaluation of automotive safety-critical systems. Part 9 of the draft does not describe the STPA procedure itself and points to this document in its bibliography. To learn the procedure, the MIT STPA Handbook is the basic reference.
Q4It is still a draft. Is there any point in preparing now?
The wording can change through the ballot and comment resolution, so it is too early for document work tied to clause numbers. What is worth doing now is checking the scope of your analyses. Which analysis identifies causes originating in interactions and usage, and whether you can present dependent failure analysis results separately, are worth confirming regardless of the final wording.
Q5Can AI-generated analysis results be submitted to an assessment as they are?
No. Part 9, Clause 8.4.8 of the draft requires the safety analyses and their outcomes to be verified, and Part 8, Clause 10.4.1 carries a NOTE that AI-based tools need further considerations. The right way is for the AI to create candidates and for a person to check them against the design documents and adopt only those that hold as work products.
References
- ISO/DIS 26262-1 to -10:2026, Road vehicles — Functional safety (Draft International Standard, ballot October 14, 2026 to January 6, 2027). Clauses cited in this article: Part 9, 7.2, 7.4.1, 8.1, 8.2, 8.4.1, 8.4.5, 8.4.8, 8.4.9 / Part 10, 13.6.1 / Part 3, 6.4.6, 6.4.7.1 / Part 4, 6.5.7 / Part 5, 7.5.3 / Part 6, 7.5.4 / Part 8, 10.4.1, Annex B.1
- SAE J3187, System Theoretic Process Analysis (STPA) Recommended Practices for Evaluations of Automotive Related Safety-Critical Systems
- ISO 26262-9:2018, Clause 8 Safety analyses; ISO 21448:2022 (SOTIF); ISO/SAE 21434 (cybersecurity)
- VWAY Tech Brief, "The Next Step in STPA Loss Scenarios: Cross-Class Guide Words + MCP AI," October 29, 2026
- Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — psas.scripts.mit.edu
- MIT PSASS, STAMP Tools — psas.scripts.mit.edu/home/stamp-tools
This article is based on Parts 1 to 10 of ISO/DIS 26262:2026 (Draft International Standard) and does not cover Parts 11 and 12. A Draft International Standard is not a published standard, and its wording and clause numbers may change through the ballot and comment resolution. Short phrases are quoted from the draft; the summaries and the interpretation are the author's and do not replace certification or assessment judgments. The driving assistance function in the screenshots is a fictional training example and not the design of any specific vehicle or manufacturer. The AI-generation figures are the results of the October 29, 2026 tech brief cited above; the judging was done by the author and has not been independently re-judged.