The real-world evidence from industry adoption of Systems-Theoretic Process Analysis (STPA)
| Core Claim | Document Link | STPA Conclusion |
|---|---|---|
| More Complete Requirements | Comparison of the FMEA and STPA safety analysis methods | "STPA found more potential causes of the hazards considered ... identified 19 safety requirements that were not in either of the two official NextGen analysis documents." |
| More Efficient | Integrating STPA in Large Organizations | "STPA provided requirements at multiple levels more efficiently than a system element fault analysis did ... effective in finding missing requirements especially early in concept phase." |
| Finds More Hazards | Comparison of FMEA and STPA safety analysis methods | "With regard to software hazards, STPA found more hazards than FMEA. With regard to component interaction hazards, STPA found some hazards, however, FMEA did not find any distinct hazards." |
| More Effective | JAXA Evaluation of STPA | "Because the HTV was originally developed using fault tree analysis and following the NASA standards for safety-critical systems, the results of our ... STPA can be compared.” “STPA identified the failures in the existing fault tree analysis but STPA also identified additional causal factors which had not been identified in the existing FTA." Most of the STPA insights were related to system design flaws and to software. |
| Outperforms Common Methods | STPA for the Ballistic Missile Defense System Software Challenges in Achieving Space Safety |
"STPA found so many flaws during just a limited three-month analysis that deployment was delayed for six months to fix the newly identified hazardous scenarios." |
| More Effective/Efficient | Hazard Analysis of Collision Avoidance System Using STPA | "STPA has proved to be an effective and efficient hazard analysis method for assessing the safety of a safety-critical system." "The reason for the effectiveness of STPA is that it considers and greatly focuses on the control commands or events and their feedbacks … instead of focusing on individual component failures." "Our positive experiences with STPA suggest that performing both steps 1 and 2 in a group of both domain experts and risk analysts increase the discussion opportunities and lead to a more effective process and more in-depth results. We experienced that the identified risks and hazards had more technical depth and constituted a better view on the analyzed system safety." |
| More Scalable with Complexity | Hazard Analysis: Application of STPA to Ship-to-Ship Transfer | "A traditional hazard analysis tool, such as HAZOP or FMEA, cannot investigate the lack of complex systems properly ... STPA is established to evaluate the safety of such complex systems." |
| More Descriptive | Applying STPA in Development of Autonomous Container Handling Machinery | "STPA emphasizes consideration of the context ... leading to more descriptive scenarios than HAZOP... HAZOP focuses only on deviations, whereas STPA also looks at issues in the intended operation." |
| More Effective | Regulator Evaluations... | Catastrophic design flaws were found by STPA, including conditions that would cause dual engine shutdowns. The traditional methods (e.g., FHA, FTA) had missed these scenarios. The STPA results were not widely disseminated at the time. A few years after the STPA results, the exact scenarios started happening in operation. The fix was to implement the STPA-generated technical requirements from years prior. |
| Less Time Required | EPRI Nuclear Study | STPA took less time and fewer resources to perform than traditional methods. |
| More Effective | Comparing STPA and FMEA | "Of the 137 causes found by STPA, 53 causes were not covered by FMECA." Many of the STPA insights involve software behavior and flawed interaction." |
| Applicable Early | STPA for ISO26262 | "STPA is a top-down process and the detailed design of item is not necessary to be known before applying STPA to the item." "We believe that STPA can support the HARA process in ISO 26262 activities and help the functional safety engineers to develop the functional safety requirements for each item identified at an early stage in the concept phase based on the results of the STPA." |
| Applicable Early | A Systems-Theoretic... | "By starting the STPA analysis early in the development process at a high level of abstraction, a wide variety of different types of scenarios can be identified." |
| Higher Return on Investment | When STPA Results Surprise You | "STPA cost for this application: $2,400. Value added: Identifying and addressing the $1m design flaw. ROI: 416." |
| More Effective for Security | System-Theoretic Process Analysis for Security (STPA- Sec) | "Generate more scenarios with more interactive complexity ... STPA-Sec scenarios help identify functional vulnerabilities [and additional] successful attacks that will delay pulse feedback." |
| More Guidance | Application of STPA in Radiation Therapy: a Preliminary Study | "STPA offers more guidance in understanding human-related hazards ... STPA adds new hazards and safety-related recommendations to existing HFMEA results." |
| STPA for Compliance with ISO26262 | Using STPA in ISO26262 | Compared to HARA, STPA is strong on Human Error, Software failure, Interaction failure, and Environmental Error. |
| More Effective | Empirical Evaluations of STPA in the Aviation Industry | "STPA identified 30 additional scenarios that were missed w/ standard methods [in certified engine control]... The TCM flaws exactly match the STPA findings by other teams years earlier." |
| More Complete Requirements | Safety Assessment of Complex, Software-Intensive Systems | "Improves upon the human-system interaction aspect of safety assessment... We illustrate the effectiveness of this new methodology by an analysis of the NextGen 'In-Trail Procedure in Oceanic Airspace' ... STPA derives some additional safety requirements beyond those in the Operational Safety Analysis (OSA) of DO-312." |
| Industry | Document Link | Traditional Method Effort | STPA Effort | Outcome/Efficiency Gain |
|---|---|---|---|---|
|
Process |
HAZOP: 120 Hours
|
Team 1: 32 Hours Team 2: 12 Hours |
STPA 4x faster (minimum) in every trial
STPA caught hidden flaw others missed STPA produced 0-cost solution others missed |
|
|
Automotive |
3x Effort of STPA |
1x Effort | STPA found more causes with 1/3 the effort | |
|
Space |
FTA: Months/Years ~4000 Hours |
Weeks/Months ~170 Hours | STPA found all FTA causes + interactions + software flaws | |
|
Automotive |
FMECA: ~1 Year |
~6 Months | STPA found 76 causes missed by FMECA | |
|
Medical |
FMEA: Months/Years ~275 hours |
2 Weeks ~50 hours |
Reduced analysis time by >90% Found recall cause |
|
|
Aviation |
AFHA, SFHA, PSSA, CCA: ~1-2 Years |
3.5 Months |
STPA generated missed requirements
STPA reduced cost by preventing late rework |
|
|
Nuclear |
FTA/PRA/FMEA/HAZOP: Weeks |
Days "Much less time" |
STPA was only method to find the actual accident scenario |
Organizations are adopting STPA because of the growing evidence from industry about its advantages. The evidence, drawn mostly from real-world case studies and comparisons, highlights three primary benefits:
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 produced results faster than other teams, yielding an ROI of about 416:1 when comparing the cost of the analysis.
U.S. Missile Defense Agency (MDA) published findings from applying STPA to the Ballistic Missile Defense System (BMDS). The STPA effort was conducted by two people over three months. Meanwhile, the common MIL-STD-882 methods (FMEA, FTA, etc.) required over a dozen specialists working for over a year to complete the safety assessment. Quantitatively, the STPA effort required about 960 hours while the traditional approach (FMEA, FTA, etc.) required 28,800 hours, meaning STPA was completed 30x faster than other techniques.
General Motors (GM) reported that STPA provided requirements “more efficiently” and found missing requirements early in the concept phase. This is critical because “missing requirements” are the leading cause of software-related accidents. Traditional methods check if the software meets the requirements; STPA checks if the requirements are safe.
Medical Device Recall Analysis: A striking example involves a blood gas analyzer that was recalled due to 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. This contradicts the common assumption that a more rigorous analysis must be more time-consuming. Because STPA uses a top-down model (control structure) rather than a bottom-up component search, it directs the analyst immediately to the critical interfaces where complex errors hide.
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. Despite requiring triple the resources, the traditional methods “found less” than STPA. Why was STPA so much faster and more effective? 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, this is simply drawn as a control structure with two arrows, allowing for immediate analysis of conflicting commands. The system lacked a physical torque sensor, relying instead on “Software complexity to estimate torque”. Traditional FMEA struggles to analyze “estimation algorithms” because there is no physical component to “break”. STPA, however, specifically prompts for “Process Model” flaws (e.g., the software believes torque is X when it is actually Y), allowing for rapid identification of these software logic hazards.
The Japan Aerospace Exploration Agency (JAXA) applied STPA and evaluated its efficiency against NASA-mandated Fault Tree Analysis. This comparison yielded profound efficiency data. The STPA analysis was performed by 1-2 people in two weeks. The traditional safety analyses consumed teams of engineers for months in comparison, around 30x more effort than STPA. Despite the minimal time investment, the single STPA analyst identified everything found in the official Fault Tree Analysis.
Embraer used STPA to streamline the development of critical aircraft systems, such as the Smoke Control System and the Air Management System. The STPA analysis was completed in only 3.5 months, faster than other techniques, and produced many recommendations and low-cost opportunities to improve safety that were missed by standard approaches (FHA, FMEA, FTA, etc.)
Fatima Company performed a rigorous HAZOP by an experienced team, requiring months of effort. Despite this, an incident occurred due to missing control logic. They began a research project to determine whether other methods could be better suited. They asked a team that was unfamiliar with the incident or the flaw to apply STPA and look for any potential weaknesses. In less than a day, the STPA team successfully identified the exact missing control logic that led to the incident. The time difference was significant, with STPA over 30x faster than the traditional approach.
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 are not related to failure probabilities but still extremely necessary for safe behavior.
An extensive comparison study was performed on the product’s cooling system. The system involved a digital control system (DCS) to manage cooling pumps. A latent design flaw in the logic led to a scenario where the system would inadvertently shut down all cooling—a costly “Loss of Mission”—even though all components were operating within their design specifications. A description of the system was given to independent teams, each using different methods to look for flaws in the design and requirements.
The effectiveness gap here is absolute. The experienced professionals using traditional methods were not able to identify the hazards that existed under specific conditions (e.g., a critical interaction between voting logic and a human procedure). STPA, by focusing on the high-level control loops, immediately flagged the controller’s unsafe decision and the exact reason it would happen in the next 9 months.
A comparative study by Sotomayor and colleagues compared STPA against FMECA in the analysis of an EPS architecture with many software interactions. The quantitative results were striking:
The “missing” causes were not random; they clustered around software logic, complex signal interactions, and human-machine interface issues. For example, FMECA successfully 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. These are not random failures; they are design characteristics that become hazardous in specific contexts. STPA’s effectiveness lies in its ability to quickly uncover these logical and interactional spaces.
U.S. Missile Defense Agency (MDA) published findings from applying STPA to the Ballistic Missile Defense System (BMDS). The STPA team consisted of only two people, and they identified many additional hazards beyond what was found by the official military-standard analysis, including a vast number of scenarios 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—flaws that would have led to inadvertent launches or failure to intercept.
EPRI (Nuclear Power): In a study of High Pressure Coolant Injection (HPCI) and Reactor Core Isolation Cooling (RCIC) systems, STPA was compared against FTA and FMEA. None of the analysis teams were aware of a specific flaw that had been uncovered recently during operation, but they were all asked to analyze the system to identify potential weaknesses and flaws. The result: Only STPA found the specific accident scenario that had actually occurred at the plant in real life. The traditional analysts could not identify the scenario or the specific weakness because it involved complex interactions rather than simple component breakage.
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. Crucially, STPA 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 due to exactly the cause STPA had predicted. The thrusters worked, the sensors worked, and the computer worked, however, the timing and logic of their interaction under specific environmental loads led to a loss of station-keeping. FMEA and FTA, which iterates through “Part X Fails,” could not find these because “Part X” is working perfectly in the scenario.
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 realized that, given the display design, the pilot would systematically make the incorrect decision. The “error” was not a random human failure; it was a design flaw in the human-machine interface. This led to the identification of catastrophic scenarios that the official analysis had dismissed.
The work by Abdulkhaleq and Sotomayor shows that STPA provides the necessary framework for defining the “safety of the intended functionality” (SOTIF). In autonomous systems, the hazard is often that the autonomy perceives the world incorrectly—a process model mismatch—rather than a hardware failure. STPA’s explicit modeling of the controller’s beliefs makes it the ideal tool for validating autonomous architectures.
Regulator Evaluations of STPA: SMEs from the FAA, EASA, ICAO, and NASA teamed up to study STPA. They applied STPA to systems already certified through standard methods using FHA, FTA, FMEA. The result? “Catastrophic design flaws were found by STPA, including conditions for dual engine shutdowns without any component failure.” This finding showed it is possible to improve on the traditional processes that have been used for decades.
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 without any failure.
Aviation: In a certified aircraft engine control system, STPA identified 30 catastrophic scenarios missed by standard certification processes (ARP4761), which were later validated by real world dual-engine flameout incidents.
NextGen In-Trail Procedure (ITP): The transition to NextGen air traffic control involves shifting responsibility from ground controllers to cockpit automation. This shift introduces “component interaction” hazards that are subtle and dangerous. Researchers compared STPA results against the official safety analysis (OSA) contained in RTCA DO-312, which relied on fault trees and event trees. The comparative analysis revealed that STPA identified 19 safety requirements that were entirely absent from the official analysis.
Spacecraft Systems (HTV): In the analysis of the JAXA H-II Transfer Vehicle (HTV), STPA was pitted against the NASA-mandated Fault Tree Analysis. 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. Traditional FTA struggles to model the dynamic communication and coordination protocols between these agents. 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.
A team at Continental applied STPA alongside traditional HARA (FMEA, FTA, etc.) within the ISO 26262 standard for fully automated vehicles. STPA finds “more” because it goes beyond malfunctions to identify hazards arising from nominal performance. HARA was found to miss:
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.
Medical Device Recall Analysis: A striking example involves a blood gas analyzer that was recalled due to 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.
contradicts the common assumption that a more rigorous analysis must be more time-consuming. Because STPA uses a top-down model (control structure) rather than a bottom-up component search, it directs the analyst immediately to the critical interfaces where complex errors hide.
An Air Traffic Management (ATM) presentation at the 2025 STAMP Workshop demonstrates how STPA is applied at a high level of abstraction. The analysis identifies scenarios such as “Air Traffic Management does not coordinate the interaction between two aircraft when a collision is imminent.” This identification leads to the derivation of safety constraints (requirements) that the eventual system architecture must satisfy. This process occurs long before other safety/reliability methods are used, before the engineers have decided on the specific radar technologies, communication protocols, or software platforms that will be used. By developing control structure models to define the Functional Safety Concept early, STPA ensured that safety was “built into” the DNA of the system rather than “inspected in” at the end.
Abdulkhaleq et al. explored the mapping of STPA’s relationship to the ISO 26262 safety standard and Hazard Analysis and Risk Assessment (HARA), including FTA, FMEA, etc. The study found that applying STPA upfront before other methods, specifically during the Concept Phase, provided a better way to achieve the objectives of the Functional Safety Concept. While traditional HARA focuses on classifying hazardous events based on severity, exposure, and controllability, STPA identifies the specific causal scenarios—even with limited design details and before information is known about failures, their exposure, or likelihood. The team concludes that it is advantageous to apply SPTA with “a little bit knowledge about the detailed design of the system at early stages”. This integration allows defining key safety constraints for autonomous functions before the complex distributed architecture of the vehicle is frozen.
General Motors (GM) reported that STPA provided requirements “more efficiently” and found missing requirements early in the concept phase. This is critical because “missing requirements” are the leading cause of software-related accidents. Traditional methods check if the software meets the requirements, while STPA checks if the requirements are safe.
Embraer’s comparison of STPA identified a substantial number of safety-critical elements that existing processes missed:
STPA finds flaws and defects earlier, reducing the cost of fixes.
The data is clear: the cost to fix a defect or change a requirement doesn’t grow linearly—it grows exponentially. As shown in NASA’s Cost Effectiveness study (Fig 2.5-1), a change that costs $1 to fix during the Requirements phase can cost $100 or more once the system reaches the Development or Operations phase.
Given the many industry studies finding that STPA identifies crucial flaws that are otherwise missed, we face a choice:
Simply put, Option 1 is orders of magnitude less costly than Option 2. The argument for STPA is that catching defects early in the Concept and Design phases results in a significant cost savings, preventing the much higher expense of late-stage development fixes or, worse, catastrophic losses following an accident.
If you are preparing to brief your leadership, check the generic slides below that explain some of the fundamental reasons for using STPA.
We offer customized briefings to introduce STPA to your organization or leadership as one of our professional services. Contact us to schedule a session.
Stay informed about the latest from STAMP Institute.
Tell us what you’re interested in, and we’ll recommend a path forward.
By continuing, you agree to our Terms of Service and Privacy Policy.
Gain skills and confidence with expert guidance as you implement modern approaches in your organization.
Gain a strategic overview of the STAMP framework designed specifically for your executive team. Our briefings focus on high-level alignment, risk mitigation, and scaling impact across your organization.
The information provided will be used exclusively to prepare your tailored briefing. By submitting, you agree to our Terms of Service and Privacy Policy. This service is reserved for organizational leadership and project stakeholders.
We’ve received your industry details. Our team regularly updates our active industry list to reflect new sectors and innovative applications of the STAMP framework. We’ll reach out if we’d like to feature your work as a specific case study!
The STAMP Institute Team
We are constantly inspired by the diverse ways our community applies STAMP. Tell us about your industry and how you’re using these methods so we can better represent the full reach of our network.
The information collected here is for mapping purposes only. By submitting this form, you grant STAMP Institute permission to display your organization’s industry on our public website. Contact and use case details will not be shared without your consent.
Thank you for reaching out! A member of the STAMP Institute team will review your request to hand-select the case studies most relevant to your goals.
Our research spans diverse sectors, but we know your challenges are unique. Tell us a bit about your focus, and we’ll curate a selection of case studies and impact reports relevant to your specific field.
By submitting this form, you agree to our Privacy Policy. STAMP Institute will only use your information to provide the requested content and update you on relevant industry insights. You may unsubscribe at any time. We do not sell your personal data.
Thank you for contacting us. A STAMP Institute representative will follow up shortly to schedule a discovery call.
Learn modern approaches to safety, security, and reliability with customized, expert-led training from STAMP Institute. Gain skills and confidence with expert guidance as you implement modern approaches in your organization.
Thank you for contacting us. A STAMP Institute representative will follow up shortly to schedule a discovery call.
You’re on the list! Thank you for joining the STAMP Institute community. You’ll now be the first to receive updates on modern approaches to safety and security.
New Training Announcements: Stay ahead with the latest curriculum updates.
Research & Presentations: Exclusive insights and expert methodologies.
Upcoming Courses: Priority registration for specialized training sessions.