Why Use STPA?

Abdulkhaleq et al. found that while traditional HARA (e.g., FTA, FMEA, etc.) focuses on failure-based causes, STPA extends this by identifying the specific causal scenarios that could lead to those events, including flaws in the architecture, unsafe interactions between non-failed components, and other factors. This allows engineers to define safety constraints for autonomous functions that do not depend on failure probabilities but are still needed for safe behavior.

Link to Source

A comparative study by Sotomayor and colleagues compared STPA against FMECA in the analysis of an EPS architecture with many software interactions.

What the EPS Comparison Found

• The Gap: 53 of the causes STPA found were not covered by the FMECA.
• STPA: Identified 137 potential causes.
• FMECA: Identified 95 potential causes of hazards.

The causes the FMECA missed clustered around software logic, complex signal interactions, and human-machine interface issues. For example, FMECA identified what would happen if a torque sensor broke. However, it missed scenarios involving algorithm thresholds that no longer match the physical process after extended operation, or a software functionality that would be eliminated because it would never be able to correctly resolve conflicting sensor feedback in certain situations. None of these is a component or function failure. Each is a design feature that becomes hazardous in a particular context, which is the kind of cause STPA looks for when it asks how a control action could be unsafe.

Link to Source

U.S. Missile Defense Agency (MDA) published findings from applying STPA to the Ballistic Missile Defense System (BMDS). A two-person STPA team identified many hazards beyond those in the official military-standard analysis, many of them involving software and logic. Upon reviewing the findings, the contractor agreed with their criticality and delayed the deployment of the system by six months to fix the software flaws, which would have led to inadvertent launches or failure to intercept.

Link to Source

U.S. Navy: Following two serious accidents on a vessel with a Dynamic Positioning System, STPA was applied. The official FTA/FMEA had identified component failures, but STPA identified those plus many “non-failure” hazard causes. STPA also identified a scenario involving a complex interaction that had not yet resulted in an accident on that ship. This scenario was ignored by the Navy at the time, but the vessel later collided with a nuclear submarine from the cause STPA had identified. No component or function failed: the thrusters, the sensors, and the computer all worked, and the timing and logic of their interaction under certain environmental loads led to a loss of station-keeping. FMEA and FTA look for components and functions that fail, so they did not identify a scenario in which every component and function worked as designed.

Link to Source

Blackhawk Helicopter: In a comparison with traditional PHA/FTA/FMEA that was performed, STPA examined a scenario involving the Blackhawk’s control system. The traditional analysis used “average” human error probabilities and deemed certain hazards “marginal”. STPA analyzed the specific information available to the pilot during the scenario and showed that, given the display design, the pilot would systematically make the incorrect decision. The cause of the “error” lay in the design of the human-machine interface, and the analysis identified catastrophic scenarios that the official analysis had rated marginal.

Link to Source

The work by Abdulkhaleq and Sotomayor shows that STPA provides a framework for defining the “safety of the intended functionality” (SOTIF). In autonomous systems, hazards often come from a process model mismatch, where the autonomy perceives the world incorrectly, more than from a hardware failure. STPA models what each controller believes about the world, so STPA can examine these mismatches.

Link to Source

Clinical Systems: The “STPA Applied to Healthcare Clinical Decision Support Systems” presentation provides results involving Electronic Health Records (EHR) and decision support. STPA treats the clinician and the software as a control loop, identifying scenarios where “alert fatigue” or poor data visualization leads to unsafe treatment decisions, even when no component or function fails.

Link to Source

Aviation: In a certified aircraft engine control system, STPA identified 30 catastrophic scenarios missed by standard certification processes (ARP4761), Years later, aircraft in service had dual-engine flameouts from flaws that matched the STPA findings.

Link to Source

NextGen In-Trail Procedure (ITP): The transition to NextGen air traffic control involves shifting responsibility from ground controllers to cockpit automation. Moving responsibility this way creates hazards from interactions among components, which are easy to overlook. Researchers compared STPA results against the official safety analysis (OSA) contained in RTCA DO-312, which relied on fault trees and event trees. STPA identified 19 safety requirements that were not in the official analysis.

Link to Source

Spacecraft Systems (HTV): In the analysis of the JAXA H-II Transfer Vehicle (HTV), STPA was compared with the Fault Tree Analysis that NASA requires. The results show that STPA found a superset of the FTA findings. The “additional hazardous scenarios” found by STPA were primarily located in the interfaces between the multiple controllers: the astronauts, the HTV autonomous software, the NASA mission controllers, and the JAXA mission controllers. Fault trees are built around component and function failures and have difficulty representing the communication and coordination between these controllers. STPA, by modeling the feedback loops and process models of each agent, identified scenarios where conflicting commands or missing feedback could lead to a collision or loss of mission, even if all hardware functioned reliably.

Link to Source

A team at Continental applied STPA alongside traditional HARA (FMEA, FTA, etc.) within the ISO 26262 standard for fully automated vehicles. STPA found more because it looks beyond malfunctions, at hazards that arise when the system performs as designed.

Two Causes of Hazards That HARA Missed

• Unsafe Interactions: The braking system and the steering system fight each other due to conflicting optimization targets.
• Environmental Error: The sensors see the world correctly, but the world presents a situation the algorithms cannot handle (e.g., perfect reflection of the sun blinding a camera).

Link to Source

Radiation Therapy, STPA vs. HFMEA: In a comparative study on radiation therapy processes, STPA was compared to Healthcare Failure Mode and Effect Analysis (HFMEA). The study found that while there was overlap, STPA offered “more guidance in understanding human-related hazards.” For instance, HFMEA might identify a hazard as “Radiographer fails to check patient ID.” The corrective action is “Retrain Radiographer.” STPA identified the same hazard but traced the cause to the control structure. It found that the process allowed the “Post-planner to send a plan to the delivery team before it was complete.” This systemic flaw sets the radiographer up for failure. One example of an STPA-generated requirement missing from HFMEA was “System must block plan transmission until ‘Approved’ status is set.” STPA identified 142 Unsafe Control Actions, including things related to the timing of image acquisition (“too long after immobilization”) that HFMEA missed because HFMEA focuses on the step being done, not the temporal relationship between steps.

Link to Source

A blood gas analyzer was recalled because of a safety defect. The manufacturer’s team spent a year performing FMEA and identified 75 hazardous scenarios. None of them explained the issue that caused the recall. A single analyst, identifying the control loops within the device, found 175 scenarios in two weeks. Included in these 175 was the specific interaction scenario that led to the recall. STPA found more scenarios in less time.

A more thorough analysis is often assumed to take longer. STPA works top-down from a model of the control structure, so the analysis starts at the interactions between controllers, where problems like this one tend to arise, without first working through the components one by one.

Link to Source

An extensive comparison study was performed on a product’s cooling system. Independent teams were asked to apply different methods to look for flaws in the design and requirements.

• FMEA: A team of professionals spent over 1,000 person-hours creating 200+ pages of FMEA documentation to fully analyze the system.
• FTA: A team of professionals spent weeks developing and reviewing detailed fault trees for the system.
• HAZOP: A team of professionals spent 120 person-hours completing a HAZOP study of the system.
• STPA: A team of professionals analyzed the system using STPA. The teams required between 1 and 32 person-hours to apply STPA. Some teams only had a few hours of STPA training and no previous experience using STPA.

Every STPA team finished faster than the teams using the other methods. At $75 an hour, the STPA cost about $2,400 and found a design flaw that would have cost at least $1 million, a return of at least 416 to 1. The source cautions that these figures come from one experiment and are not a recommendation for how long an STPA should take.

Link to Source

General Motors (GM) reported that STPA provided requirements “more efficiently” and found missing requirements early in the concept phase. Missing or flawed requirements are a leading cause of software-related accidents. Verification checks whether software meets its requirements, and STPA asks whether the requirements themselves are safe.

Link to Source

Valeo conducted a comparative study on STPA and FTA. The study compared the effort required to perform STPA against the combined effort of Fault Tree Analysis (FTA) and Critical Path Analysis (CPA). The traditional FTA/CPA process required three times the effort (person-hours) of the STPA analysis. With three times the effort, the CPA and FTA did not produce the two safety constraints that STPA allocated to the inverter control software. Two features of the system account for the difference. The system involved “Shared control with inverter software” and “One controller on two processes.” Modeling these shared dependencies in a Fault Tree requires complex Boolean logic structures that are time-consuming to build and verify. In STPA, the same arrangement is a control structure with two arrows, and the analysis can turn straight to conflicting commands. The system lacked a physical torque sensor, relying instead on “Software complexity to estimate torque.” FMEA has difficulty analyzing estimation algorithms, because they have no physical component that can break. STPA asks about process model flaws (for example, the software believes torque is X when it is actually Y), which leads the analysis to these software logic hazards.

Link to Source

The Japan Aerospace Exploration Agency (JAXA) applied STPA and evaluated its efficiency against NASA-mandated Fault Tree Analysis. The STPA analysis was performed by 1-2 people in two weeks. The traditional safety analyses took teams of engineers months, around 30 times the effort. The STPA identified everything in the official Fault Tree Analysis, along with causal factors that the fault tree had not identified.

Link to Source

Embraer applied STPA in developing aircraft systems, such as the Smoke Control System and the Air Management System. The STPA took 3.5 months, less time than the other techniques, and produced many recommendations and low-cost opportunities to improve safety that were missed by standard approaches (FHA, FMEA, FTA, etc.)

Link to Source