A Modern Approach to Complex Systems
The tragic Boeing 737 MAX crashes showed the world how fragile even the most advanced machines can be. These weren’t outdated aircraft—they were modern iterations, equipped with automation like the MCAS system, meant to make flying safer. But what happened instead? The system failed, and traditional safety analysis methods didn’t catch it in time.
Why? Because most of these methods still focus mainly on hardware failures. But in today’s systems, that’s no longer enough. Modern aviation—and many other industries—need tools that consider software, human interaction, and control logic. That’s where STPA (System-Theoretic Process Analysis) comes into play.
Why STPA Matters More Than Ever
In 2024, the U.S. FAA released a comprehensive report evaluating STPA, involving experts from FAA, EASA, ANAC, ICAO, and NASA. A striking 69% of them said that STPA better identifies hazards related to automation and human factors—exactly the kind of issues we saw with the 737 MAX.
This isn’t just an academic insight. It reflects a real shift in how we need to think about safety in complex, software-driven systems.
A Quick Refresher: Traditional Safety Analysis Methods
As we already covered STPA here, and our other insights, it’s worth recalling the classic trio of safety analysis techniques still widely used across industries:
- FMEA (Failure Modes and Effects Analysis): A bottom-up method that identifies how individual component failures might affect the larger system.
- HAZOP (Hazard and Operability Study): Common in chemical and process industries, HAZOP looks for deviations from a system’s design intent.
- FTA (Fault Tree Analysis): A top-down, deductive approach that visualizes the path from component failures to system-wide hazards.
These tools have served industries well for decades, but their limitations become more obvious when systems grow more interconnected and automated.
FMEA vs. STPA: Components vs. Control
FMEA and STPA aim to spot hazards, but they come from two very different mindsets. First is rooted in reliability theory. It assumes things fail, and tries to track down the effects. It’s detailed and systematic—but very component-focused.
STPA, by contrast, treats safety as a control problem. It doesn’t start with “what might break?” but rather “how can unsafe control or decisions emerge even when nothing is broken?” It’s a top-down method that looks at how components interact dynamically—including humans and software.
A case study on forward collision avoidance systems compared both methods. Here’s what came out of it:
- FMEA caught more pure component failure risks.
- STPA excelled at catching unique software and interaction hazards, especially around timing, feedback, and communication errors.
One standout difference: STPA can dig deeper into causal chains. It doesn’t just point to what might go wrong, but why—especially in systems involving automation and decision-making logic.
However, FMEA has an edge in calculating risk levels (using RPN, for instance), which STPA doesn’t natively support.
In short: FMEA is great for identifying failure points; STPA is better at understanding system behavior. And together, they can form a more complete picture.
HAZOP vs. STPA: Design Deviations vs. System Control
HAZOP is a staple in process safety. It’s structured, team-driven, and thorough. The core idea is simple: walk through a system and look for deviations from how it’s supposed to work. Use guide words to systematically challenge each part of the design.
STPA, again, shifts focus. It doesn’t just look for deviations from design—it asks if the system might be inherently unsafe even when it behaves as designed. That’s a huge difference.
In a case study involving autonomous machinery:
- Both methods caught issues related to timing and data correctness.
- HAZOP focused on deviations in expected behavior.
- STPA uncovered hazards rooted in the lack of control—like missing feedback loops or wrong assumptions about how a human or machine might respond.
STPA also forces you to build a model of the system’s control structure. That takes more time, yes—but it can result in clearer documentation and deeper insights.
In fact, the HAZOP standard often recommends combining it with FMEA or FTA. STPA, on the other hand, was designed to stand alone and still find hazards traditional methods can miss.
A study involving dam safety used STPA to identify hazards and their causes, and then HAZOP to help design mitigations. The takeaway? Combining both can be very effective—especially in cyber-physical systems.
FTA vs. STPA: Event Logic vs. Dynamic Interactions
Both FTA and STPA work top-down, but their logic and goals are different.
FTA builds logical trees—starting from a failure and tracing back to its possible causes. It’s excellent at showing how things might go wrong through combinations of failures.
But again, it’s grounded in reliability theory. It tends to focus on failures of physical components.
STPA is based on system theory. It looks at unsafe control actions—which might involve things working as intended but interacting in the wrong way. It digs into things like:
- Conflicted or missing control commands
- Faulty control logic
- Feedback loops that don’t provide timely or accurate information
- FTA found component-level causes effectively.
- STPA uncovered wider system-level problems—especially in software-heavy systems.
Neither method found all hazards. But combined, they cover more ground.
Also worth noting: FMEA remains stronger for risk quantification, something STPA doesn’t do by design.
Final Thoughts: A Realistic Look at STPA vs. Traditional Safety Methods
As systems grow more complex, traditional safety analysis methods like FMEA, HAZOP, and FTA are no longer enough on their own. STPA offers a powerful, modern framework that looks beyond physical failures to understand systemic risks, software behavior, and human factors.
But let me be clear: I’m not claiming to be a specialist in all these domains. Most of the conclusions shared here are based on case studies conducted by domain experts, and results can differ depending on the knowledge, experience, and background of the team performing the analysis.
When it comes to methods, I think of them as structured ways or steps to achieve a specific outcome. While they can often be adapted, they can’t evolve too much without losing clarity or consistency. That’s why it’s crucial to embrace new tools and frameworks—especially when the real world and technology are changing faster than ever before.
No single method is perfect. In many cases, using a combination of tools—both traditional and modern—can give the most complete safety picture. What matters most is choosing the right approach for the system you’re working with, and staying open to new methods that help you understand and prevent failures in an increasingly automated world.
Bibliography
- Elizebeth, M. J., Khastgir, S., Babaev, I., Chen, S., & Jennings, P. (2023, March 20). Comparison of FTA and Stpa Approaches: A Brake-by-Wire Case Study. SSRN.
- Farooq, M., Inayat, I., & Daneva, M. (n.d.). Security-based Safety Hazard Analysis using STAMP, STPA & HAZOP: A DAM Case Study. (PDF document/paper).
- Heikkilä, E., Malm, T., Sarsama, J., Tiusanen, R., & Ahonen, T. (2023). HAZARD ANALYSIS OF AN AUTONOMOUS CONTAINER HANDLING SYSTEM – A COMPARISON OF STPA AND HAZOP METHODS. Scientific Journal of Gdynia Maritime University, No. 125/23, 25–39. https://doi.org/10.26408/125.02 (Submitted: 23.11.2022, Accepted: 02.02.2023, Published: 31.03.2023).
- Sulaman, S. M., Beer, A., Felderer, M., & Höst, M. (2019). Comparison of the FMEA and STPA safety analysis methods–a case study. Software Quality Journal, 27, 349–387. https://doi.org/10.1007/s11219-017-9396-0 (Published online: 04 December 2017).
- Thomas, J. P., & Van Houdt, J. G. (2024, July). Evaluation of System-Theoretic Process Analysis (STPA) for Improving Aviation Safety. (Report No. DOT/FAA/TC-24/16). Federal Aviation Administration William J. Hughes Technical Center.
- Thomas, S. (2025, May 30). An Introduction to STAMP. FunctionalSafetyEngineer.com
Leave a Reply