STPAThe Next Step in Deriving STPA Loss Scenarios: Cross-Class Guide Words + MCP AI
Summary
STPA (System-Theoretic Process Analysis) loss scenarios are usually written by picking one guide-word archetype and filling in one sentence. Yet the story accident reports tell most often spans two archetypes: "the sensor died and the system kept driving on the last value it had." This article takes the 66 archetypes of the four Classes (controller, feedback, control path, process), distills 77 cross-class combined archetypes from them, adds those to the guide-word set, and lets an AI generate loss scenarios with them on an educational highway-driving-assist example. Of 11 combined scenarios, 6 were absent from the baseline, 2 were partial, 2 were questions until the design is checked, and 1 was a duplicate. Of the 6, however, 3 could have been reached by picking more single archetypes; the countermeasure changed in 3. Tomorrow, put four questions to one UCA in the analysis you are working on.
The scene: one UCA, two scenarios
Suppose you are analyzing a driving-assist function that changes lanes and adjusts speed on the highway. The example in this article is an educational virtual system, not any manufacturer's design (the NOA example, hereafter). The controller is the NOA System, the control action is the "speed request" sent to the Speed Controller, and feedback comes from the camera, radar, and map. One unsafe control action (UCA) is "NOA requests a speed above the speed limit."
The quickest way to write a scenario for this UCA is to pick a guide-word archetype. Pick the controller archetype "the controller believes a state different from the actual one" and you get "NOA believes the limit is 110 km/h from outdated map data while the road is actually a construction zone limited to 60 km/h." Pick the feedback archetype "feedback is wrong because of corrupted sensor data" and you get "a sign-recognition error reads a 60 km/h sign as 80." Both are valid scenarios.
But both sentences miss the story accident reports tell most often: "fog blinded the camera to the sign, and the system kept using the previous speed limit as it entered the construction zone." The first half is a feedback archetype; the second half is a controller archetype. Pick only one archetype and finish the sentence, and only half of that story survives. The sensor failure is written down but not the default used at that moment; the default assumption is written down but not why feedback was missing at that moment.
The handbook and the standards already ask. The gap is a habit
The MIT STPA Handbook (Leveson & Thomas, 2018) divides loss scenarios into two groups: why unsafe control actions occur (controller flaws, inadequate feedback) and why control actions are improperly executed (control path, controlled process). In the first group the handbook shows, by example, how to trace a process-model flaw back to feedback; in the second it asks whether the controller can tell that a command was not executed. The archetype list used in this article (the VisualPro STPA guide-word set) splits the two groups into four Classes: controller, feedback, control path, process. Each Class holds archetype sentences such as "the controller believes an outdated state," "feedback is delayed," "the actuator ignores the command," and "the process reacts automatically without input." There are 66 in all. This framework is sound and there is no reason to change it.
The standards automotive readers actually work with also ask much of what this article covers.
| Existing framework | Asks | Does not ask |
|---|---|---|
| STPA Handbook, two scenario groups | Shows by example how to trace a process-model flaw back to feedback | Does not enforce that link through an archetype list |
| Guide-word archetypes (Class 1–4, 66) | What can go wrong inside each Class | When flaws of two Classes close one loop inside one control loop |
| ISO 26262-9 dependent failure analysis (DFA) | Dependent failures from shared resources: power, bus, connectors | Which UCA's scenario that sharing belongs in |
| ISO 21448 (SOTIF) | Sensor performance limits and triggering conditions (fog, stationary-object filtering) | What the controller then takes as its default |
| AUTOSAR E2E, signal validity | Timeouts, CRC, validity flags | Whether the controller uses that flag in its safe-mode transition condition |
The gap lies not in the handbook or the standards but in a working habit: pick one archetype and finish the sentence. The validity flags the standards require and the results of shared-resource analysis have to be pulled into some UCA's scenario by someone.
Combined archetypes: not dividing the Classes, adding a layer that asks what lies between them
Pair the 66 archetypes of the four Classes with each other and the number of meaningful combinations is smaller than you would expect, and they arise in five ways.
| Mechanism | Meaning | Example (NOA) |
|---|---|---|
| Chain | A flaw in the first Class causes a flaw in the second (direction matters) | Loss of camera feedback → NOA enters a degraded mode that requests speed from the map alone |
| Masking | A flaw in one Class hides a flaw in the other from the controller | The brake actuator fails to deliver the deceleration, but feedback returns the "commanded deceleration," so the failure is invisible |
| Common cause | One link, bus, power supply, or connector hits two Classes at once | Vehicle-bus overload delays the speed request and the speed feedback together |
| Defeat | A fallback strategy of one Class meets a flaw of the other and backfires | NOA withholds commands under a fallback goal, and the vehicle side reacts on its own after a period without input |
| Multi-controller | Two controllers resolve the same ambiguous input differently and their commands collide | NOA and the subordinate Speed Controller read an ambiguous sign value differently and their commands conflict |
Filtered this way, the combined archetypes number 77. They are written by the same rule as the single archetypes: placeholders such as %Controller% and %Feedback% stay in place and only the real elements are filled in, and each combination records which two (or three) single archetypes it came from, so it can be traced.
These 77 were added to the VisualPro STPA guide-word set as "Class 5." In the tool it sits as a fifth Class node for convenience, but it is a relation layer between categories, not a category of causes. Class 1–4 were left untouched. Analysts pick archetypes as usual and switch to a combined archetype when any of the four questions below is answered "yes."
The experiment: same UCAs, 6 single-archetype scenarios versus 11 combined
Two UCAs and one control action were chosen from the NOA example: "NOA requests a speed above the limit," "NOA does not request a speed although there is an obstacle ahead," and, independent of any UCA, the case where the "speed request" is improperly executed. All three started with zero scenarios.
The AI (Claude) read the tool's guide words and the control-loop elements (controller, process model, subordinate controller), then generated and saved 6 scenarios from single archetypes, followed by 11 from combined archetypes. The AI chose the archetypes and filled the placeholders; the author chose the target UCAs and judged the results. Three criteria were used: Is the content absent from the 6 single-archetype scenarios? Does it hold in NOA's control structure? Does the countermeasure change? The judgment was made by the author, who also built the combined archetypes, and no independent review has been done yet, so read the figures below as an upper bound. The baseline is also thin, at two scenarios per target. Archetype numbers below follow the author's archetype list and differ from the tool's Class 1–4 item numbers.
| Combined archetype | Scenario in brief | Judgment |
|---|---|---|
| C2-11 + C1-19 (chain) | A 100 km/h main-road sign and a 60 km/h exit-ramp sign stand side by side; the two readings conflict and NOA picks the main-road limit, requesting 100 on the ramp | Countermeasure changes: a resolution policy, "on conflict, take the lower value." Not reachable by joining two single archetypes |
| C3-3 + C2-2 (common cause) | Bus overload delays the deceleration request and the speed feedback together; NOA sees an unchanged speed and keeps re-issuing requests | Countermeasure changes: is the E2E timeout already in use attached to the speed-feedback signal, and is it checked before re-issuing? |
| C3-1 + C2-6 (masking, no UCA) | The brake actuator fails to deliver the requested deceleration, but feedback returns the "commanded deceleration," so the failure is invisible to NOA | Countermeasure changes: measured-deceleration feedback |
| C2-1 + C1-20 (chain) | Fog blinds the camera to the sign and NOA keeps the previous limit of 110 km/h, requesting 110 in a 60 km/h construction zone | Absent from the baseline, but reachable by picking the single archetype "default or previous value assumed." The combination ties the two sentences into one loop |
| C2-1 + C1-20 (chain, obstacle UCA) | Heavy rain kills the radar and NOA assumes "no obstacle" by default, so no deceleration request is sent | Duplicate: two baseline scenarios (radar failure, default assumption) joined into one sentence |
| C4-2 + C2-1 (common cause) | A 12 V supply dip reduces brake authority and de-energizes the radar at the same time | Design check needed: a hypothesis until it is confirmed that the radar and the brakes share a power domain |
The five not in the table are: degraded-mode input validation (chain), the safe-mode condition not referencing the validity flag (chain), the map lacking temporary-zone context (chain), stationary-object filtering (chain), and a shared command/feedback link (common cause). The first two could also be reached with single archetypes, the next two partly overlap existing single scenarios, and the last is a hypothesis until the design is checked.
In total, of the 11 combined scenarios, 6 were absent from the baseline, 2 were partial, 2 were questions pending a design check, and 1 was a duplicate. Splitting the 6 again: in 3 the countermeasure changed, and 3 could have been reached by picking more single archetypes. Three things stood out.
First, the place where combined archetypes earn their keep is narrow and clear: where a countermeasure appears that joining two archetypes would not produce (a resolution policy, a timeout check, measured feedback). The rest can be reached by choosing single archetypes carefully. A combined archetype does not replace single archetypes; it is a layer that asks whether the space between two single archetypes is empty.
Second, the same combined archetype gives different results on different UCAs. "Sensor failure → default assumed" was absent from the baseline on the speed-limit UCA but a duplicate on the obstacle UCA. Once two single scenarios are already in the baseline, the combination can do no more than join them.
Third, a common-cause scenario is a hypothesis at the moment the AI produces it. Whether power or a link is really shared is answered by the ISO 26262-9 DFA results and the architecture documents. In another example (a virtual small modular reactor plant reconstructed from public design documents), six combined-scenario candidates obtained by simulation were checked against the redundancy and voting logic in the source, and three were rejected. Some of the combined archetypes in this article were abstracted from that work. A combined archetype is a candidate, not a finding.
In this experiment the AI's work was to choose archetypes, fill the placeholders with real elements, and save; the human's work was to design the guide-word set and judge the results. The second task does not shrink. The more candidates there are, the more time goes into asking "does this hold in our design?", and that time is the substance of the analysis.
What to check tomorrow
- Take one UCA from an analysis in progress and put the four questions to it (default when feedback is missing, awareness of execution failure, shared paths, automatic reaction after a withheld command). If any answer is "yes," that UCA's scenario spans two Classes.
- Find scenarios already written that end at "sensor failure" and append the default used at that moment.
- When adding combined archetypes to a guide-word set, leave Class 1–4 as they are and add a separate layer. Traceability of existing scenarios is preserved.
- Give common-cause scenarios a separate "design check needed" state that closes only when the DFA result (sharing, redundancy) is recorded.
- Record, signal by signal, whether feedback to the controller is the "commanded state" or the "achieved state." Feedback that returns only the commanded state is the raw material of masking scenarios.
- Record which signals carry E2E validity flags and timeouts, and whether the controller's safe-mode condition references them.
Closing
FAQ
Q1Why not just pick two single archetypes?
You can. In the experiment, 3 of the 6 could be reached that way. But when the two sentences are written separately, "sensor failure" and "default assumed" remain two different scenarios, and nobody writes the link between them (which default is used when which sensor dies). A combined archetype makes that link one sentence. The 3 cases where the countermeasure changed did not emerge from joining two sentences.
Q2DFA, SOTIF, and E2E already ask these questions. What is new?
No new countermeasure. DFA requires the shared-resource analysis, SOTIF the sensor-limit analysis, and E2E the validity flags. What is missing is which UCA's scenario their results end up in. The four questions of the combined archetypes are a device for asking that link for every UCA, and the 2 scenarios needing a design check close only when the DFA results are brought in.
Q3Can AI-generated scenarios be used as they are?
No. Of the 11, 2 stood on a hypothesis of shared power or a shared link; until confirmed they are questions, not scenarios. In another example, three of six combined-scenario candidates were rejected when checked against the source. The right division of labor is that the AI produces candidates exhaustively and people judge, against the design documents, whether they hold.
Q4Does this conflict with the handbook's two-group classification?
No. The handbook already shows by example how to trace a process-model flaw back to feedback. Combined archetypes turn that link into an archetype list, so that an analyst picking one archetype does not leave the link out.
Q5Our tool has no guide-word-set feature. Can this still be applied?
The four questions do not depend on a tool. Start by adding four columns next to the scenario column in a spreadsheet, "default when feedback is missing," "execution failure known," "shared path," and "automatic reaction after withheld command," and mark yes or no for each UCA. Using a guide-word set makes the difference that traceability is recorded automatically.
- ISO 26262-9:2018, Clause 7, Analysis of dependent failures; ISO 21448:2022 (SOTIF); AUTOSAR E2E Protocol Specification
- Author's compilation, Class 1–4 loss-scenario archetypes (66) and cross-class combined archetypes (77), 2026 — available on request
- 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
The NOA example in this article is an educational virtual system and not the design of any vehicle or manufacturer. The speed-limit figures (110, 60, 100 km/h) are illustrative. The baseline was deliberately thin at two single-archetype scenarios per target; the judgment was made by the author, who also built the combined archetypes, with no independent re-judgment. The AI chose the archetypes and filled the placeholders; the author chose the target UCAs. The two common-cause scenarios (shared power, shared link) are hypotheses pending architecture confirmation. The rejected cases from the virtual small-modular-reactor plant come from an in-house example reconstructed from public design documents. Scenario generation and saving were performed by Claude through the MCP connection of VisualPro STPA. The product screenshots show the English interface; the diagram was redrawn in English for this article.