Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Applying STPA to Safety of the Intended Functionality: Key Practices from SAE J3187-2
As safety-critical systems become more complex, traditional hazard analysis methods often fall short in addressing risks arising from system interactions and intended functionality limitations. The SAE J3187-2 standard provides recommended practices for applying System Theoretic Process Analysis (STPA) to Safety of the Intended Functionality (SOTIF) evaluations. This article distills the core concepts, mapping, and practical applications outlined in the standard.
Why STPA for SOTIF?
STPA, based on the Systems-Theoretic Accident Model and Processes (STAMP), identifies hazards and unsafe control actions arising from inadequate control, component failures, and system interactions. For SOTIF, which focuses on hazards due to functional insufficiencies or foreseeable misuse by users, STPA offers a systematic way to uncover safety concerns that may not be captured by failure-focused methods like FMEA or FTA. SAE J3187-2 bridges the gap between traditional functional safety (ISO 26262) and SOTIF by providing a structured approach to hazard identification and scenario generation.
🛠️ Engineering Insight: STPA can be applied early in the specification phase to derive safety requirements and validation targets, ensuring that SOTIF-related hazards are addressed before detailed design.
Mapping STPA Steps to SOTIF Clauses
A key contribution of SAE J3187-2 is the explicit mapping between the four STPA steps and the clauses of ISO/PAS 21448 (SOTIF). This alignment allows engineers to integrate STPA seamlessly into existing SOTIF workflows. The table below summarizes this mapping:
| STPA Step | SOTIF Clause | Description |
|---|---|---|
| Step 1: Define Purpose of Analysis | Clause 5: Specification & Design | Define the system, function, operational design domain (ODD), and hazards. |
| Step 2: Model Control Structure | Clause 5: Specification & Design | Develop control structure diagrams to represent interactions and feedback. |
| Step 3: Identify Unsafe Control Actions | Clause 6: Hazard Identification & Risk Evaluation | Identify control actions that can lead to hazards given context. |
| Step 4: Identify Loss Scenarios | Clause 9: Verification & Validation Strategy | Derive scenarios and test cases that could lead to hazardous events. |
This mapping ensures that STPA outputs directly feed into SOTIF hazard identification and risk evaluation (Clause 6) and the definition of verification and validation strategy (Clause 9).
Leveraging STPA for Specification and Testing
Identification of Relevant Control Actions
For automated systems, control actions must be identified with respect to the intended functionality and the Operational Design Domain (ODD). The standard emphasizes that control actions should be defined using abstract functionality rather than physical components. For example, a low-speed automated driving system may have control actions like “engage”, “disengage”, “brake”, “accelerate”, and “steer”. Each control action is analyzed in the context of the control structure and process model beliefs to identify unsafe control actions.
Scenario Generation from STPA Outputs
STPA’s loss scenarios directly translate into test scenarios. SAE J3187-2 provides detailed guidance on how to extract scenery, environmental conditions, and dynamic elements from loss scenarios. This systematic approach covers both known and unknown hazardous situations—a critical requirement for SOTIF compliance. The standard also defines pass criteria and validation targets based on the unsafe control actions identified.
⚠️ Common Pitfall: Incomplete identification of control actions due to inadequate modeling of process model beliefs or failing to consider the full ODD. Use the examples in the case study (Section 4.9) to guide your analysis.
Engineering Design Insight
When applying STPA for SOTIF, start by building a control structure that includes human operators, automation controllers, sensors, actuators, and the environment. Document the process model beliefs (what each controller assumes about the state of the system) because mismatches between believed and actual states are a primary source of unsafe control actions. The case study in SAE J3187-2 of a low-speed automated driving system illustrates how this identification leads to robust validation scenarios.
Frequently Asked Questions
How does STPA complement SOTIF?
STPA provides a top-down, systems-theoretic approach to identify hazards that may arise from functional insufficiencies, component interactions, or human-automation interaction—areas not fully covered by traditional reliability-focused methods. It aligns with the SOTIF emphasis on “safe intended functionality.”
What is the role of the control structure in STPA for SOTIF?
The control structure is the foundation of STPA. It models the feedback loops and decision-makers (human and automated) in the system. For SOTIF, it helps reveal where lack of feedback or incorrect mental models can lead to unsafe control actions due to functional limitations.
Can STPA be used to generate validation scenarios for unknown hazardous situations?
Yes. STPA systematically identifies loss scenarios that include both known (based on past experience) and unknown (emergent from control structure analysis) hazardous conditions. These scenarios can then be refined into concrete test cases for validation.
What industries can benefit from this recommended practice?
While the standard originated from the automotive domain (for road vehicles), the principles are applicable to any safety-critical system: aerospace, medical devices, industrial automation, robotics, and more. The appendix is written for any industry.
For more details, refer to the full SAE J3187-2 standard and its accompanying case study on low-speed automated driving systems. SAE J3187-2
