STPA and Functional Safety: A Natural Match

Recently, a company told us, “We don’t need to use Functional Safety standards, we use STPA.” This had us puzzled: are these methods mutually exclusive?

Two Worlds of Safety

Functional Safety (FuSa) processes are based on 150 years of experience in preventing accidents caused by the mechanical and electrical failure of physical components. They align well with traditional, thorough engineering standards. FuSa is backed by a number of well-recognized and actively used ISO standards.

STPA (System-Theoretic Process Analysis) is based on Nancy Leveson’s analysis of complex systems and why they fail even when all their individual components are functioning as designed. It aligns with holistic systems theory and top-down analysis and originates from a highly respected group at the Massachusetts Institute of Technology (MIT).

The Ariane 5 Lesson

The case of Ariane 5 (an unmanned rocket that failed on its first flight) is an example of why STPA is needed. A velocity sensor module threw an unhandled exception due to an integer overflow. The onboard computer interpreted that exception as if it was valid flight data, and sent erratic commands to the engines.
STPA is a top-down analysis method that focuses on the controls between components. Had it been applied, it would have found that, while both components performed as designed, the output of the velocity sensor did not match the expected input to the flight computer.

Software Critique

STPA proponents sometimes criticize FuSa methods for being unable to deal with software. This is unfair. Software guidelines are essential to standards like DO-178C and ISO 26262, and much more explicit than in STPA.

It is more accurate to say that while FuSa’s Hazard Analysis and Risk Assessment (HARA) is a top-down technique, its focus on discrete component malfunctions can miss the danger inherent in the system architecture itself: the risk that components work exactly as intended but create an unsafe state through their interaction. In Automotive FuSa this is recognized by the introduction of the ISO 21448 (SOTIF) and ISO 8800 (AI/Machine Learning) standards. For the more generic IEC 61508 (FuSa for electronic systems in industry) standard, STPA is recognized as a valid technique to implement the HARA.

How They Match

Instead of criticizing either FuSa or STPA, we should leverage their strengths.

• STPA (top-down): Excels at identifying safety requirements for control signals between components.
• Functional Safety (bottom-up): Excels at ensuring those requirements are met by the individual components and verified against failure rates.

For Ariane 5, STPA would have identified the requirement for a valid velocity input within a specific flight window. A (bottom-up) FuSa-based verification of the software’s implementation of that requirement would have flagged that a 16-bit integer was insufficient for the expected velocity.

Chapter 3 of Leveson and Thomas’ “STPA Handbook” shows how to integrate STPA in the V-model, which fits seamlessly with FuSa’s validation and verification activities.

Conclusion

STPA and FuSa are not rivals. They are complementary methods that, when used together, lead more efficiently to safer systems.