SYLEN
AboutNewsConferenceMembership

Email updates

Conference, news, and membership updates by email.

Network

  • About
  • News
  • Membership
  • Waitlist

Conference

  • Conference 2026
  • Call for papers
  • Sponsor

Membership

  • Create profile
  • Search profiles
  • Who it's for

SYLEN

  • Guidelines
  • Privacy
  • Terms

© 2026 Systems Leadership and Engineering Network. sylen.org.

Membership details →
Back to news
STPA Adoption Accelerates as HARA Alternative in Safety-Critical Systems

Image courtesy of incose.org

Functional SafetySource: incose.orgFebruary 23, 2026

STPA Adoption Accelerates as HARA Alternative in Safety-Critical Systems

Systems-Theoretic Process Analysis is gaining traction in aerospace and automotive sectors as a complement or replacement for traditional FMEA, offering better coverage of software-intensive and emergent failure modes that fault-tree approaches routinely miss.

Why STPA Is Finding Its Moment

FMEA has been the workhorse of safety analysis for fifty years. It is systematic, auditable, and familiar to every certification authority. It is also fundamentally component-level: it asks "what can go wrong with this part?" and traces upward. For systems where failures emerge from interactions — between software components, between subsystems, between a system and its human operators — FMEA misses the failure modes that matter most.

STPA (Systems-Theoretic Process Analysis), developed by Nancy Leveson at MIT, takes the opposite approach. It starts from system-level safety constraints and asks: what inadequate control actions could violate these constraints? The analysis is structured around control loops rather than component failure modes.

Where STPA Outperforms Traditional Methods

The 2009 Piper Alpha Deepwater Horizon incident involved no component failures. Every sensor worked. Every alarm fired. The system failed because the interactions between human operators, automated controls, and physical processes produced behaviour that none of the individual components were designed to exhibit. STPA would have identified this class of hazard; FMEA would not have.

Similarly, the Boeing 737 MAX MCAS failures were not a component failure — the angle-of-attack sensor and the MCAS software both performed as designed. The failure was in the control structure: inadequate pilot override authority, missing feedback to flight crew, and a hazard analysis that did not model the pilot-automation interaction as a control loop.

Adoption Patterns in Practice

Teams adopting STPA typically face two challenges: learning curve and regulatory acceptance. STPA requires systems engineers to think in terms of control structures rather than failure modes, which is a genuine skill shift. Regulatory acceptance is improving: FAA guidance now acknowledges STPA as a valid complement to traditional methods, and several Tier 1 automotive suppliers have begun including STPA in their safety cases alongside ARP4761 analyses.

Getting Started

The most effective entry point for most teams is applying STPA to a subsystem with known software-intensive failure modes, running it in parallel with the required FMEA/FTA, and using the comparison to build internal familiarity with the method before attempting regulatory acceptance of STPA-only analyses.

Read the original article at incose.org.