Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Applying STPA to Human‑Machine Interaction Evaluations: Key Practices from SAE J3187‑1
The SAE J3187‑1:2023 standard provides a comprehensive appendix on using System Theoretic Process Analysis (STPA) specifically for human‑machine interaction (HMI) evaluations. It addresses a critical gap: modelling the human operator as a controller with all their cognitive complexities. This article highlights the main practices and design insights from the standard, focusing on the Human Extension Representation (HER), system scoping, and the identification of unsafe control actions (UCAs) and causal scenarios.
🛠️ Engineering Design Insight: Treat the human operator as an integral component of the control structure, not an external element. Use the Human Extension Representation (HER) to model situation assessment, action selection, and mental model updates. This systematic approach reveals causal factors that generic human error models may miss.
Understanding the Human as a Controller in STPA
In traditional STPA, controllers can be humans, automated systems, or both. However, when analyzing human‑machine interactions, it is insufficient to treat the human simply as a black box that issues control actions. The standard emphasises that the human operator must be modelled with explicit representation of their internal processes, including mental models of the system, decision‑making logic, and assessment of feedback. This is done by expanding the “Human” block in the control structure into a detailed Human Extension Representation (HER).
The system scope must include all elements that influence or are influenced by the human operator, such as feedback displays, controls, external environment, and the automated system’s state. Figure 1 in the standard shows the driver as part of the control structure, and Figure 2 expands this into HER components.
Modeling Human Cognition with Human Extension Representation (HER)
The HER method decomposes the human controller into several sub‑models:
- Situation Assessment – How the human observes and interprets system state via feedback.
- Mental Models – The internal representation of system behaviour, which drives action selection.
- Action Selection – Decision process that chooses a control action based on current goals and mental models.
- Execution and Response Assessment – Carrying out the action and evaluating its effect.
Each of these interacts with feedback and commands in the control loop.
| HER Component | STPA Control Task | Example in Automotive HMI |
|---|---|---|
| Situation Assessment | Receiving feedback (e.g., instrument cluster) | Driver sees speed and warnings |
| Mental Model | Internal state of what the system is doing | Driver believes car is in Park |
| Action Selection | Choosing control action (e.g., push Park button) | Driver decides to shift to Park |
| Execution | Physical interaction with controls | Driver presses button |
| Response Assessment | Evaluate if action had intended effect | Driver checks gear indicator |
The standard provides an example of “Shifting Vehicle to Park” to illustrate how these components work together and how unsafe control actions can arise if, for example, the feedback is ambiguous or delayed, leading to an incorrect mental model.
⚠️ Common Pitfall: Failing to model the human’s mental model updates can lead to incomplete causal scenario analysis. For instance, if a driver receives inadequate feedback about the gear state, they may mistakenly think the vehicle is in Park, resulting in an unintended roll‑away.
Analyzing Unsafe Control Actions and Causal Scenarios in HMI
Unsafe control actions (UCAs) in the context of HMI include not only erroneous commands but also incidental interactions. The standard explicitly defines:
- Erroneous Interaction – When the human issues a correct command for the wrong reason.
- Incidental Interaction – Accidental or unintended activation of a control (e.g., brushing a button).
- Purposeful Activation – Intentional but unsafe action due to a flawed mental model.
Identifying UCAs requires careful consideration of the context in which the human operator makes decisions. The standard recommends involving driver performance and behavioral experts to develop realistic causal scenario descriptions. These scenarios consider factors like feedback design, workload, and automation transparency.
For example, in an automated driving system (ADS), a UCA might occur when the human does not take over control in time because the system failed to provide an appropriate handover request. The HER analysis can highlight missing or misleading feedback as a root cause.
Frequently Asked Questions
- Why model the human operator inside the control structure?
Treating the human as an external element obscures the cognitive processes that lead to unsafe actions. Placing them inside the control structure allows STPA to systematically capture how feedback, mental models, and decision‑making contribute to unsafe control actions. - What is the main benefit of using HER over generic human error models?
HER provides a structured, systems‑theoretic representation that integrates with STPA’s causal analysis. It focuses on the system design (feedback, controls) that influences human behavior, rather than attributing errors solely to human fallibility. - How is feedback handled in automotive HMI according to SAE J3187‑1?
Feedback is a crucial control path that informs the driver’s situation assessment and mental model. The standard emphasizes analyzing if feedback is timely, unambiguous, and correctly interpreted to prevent mode confusion and incorrect actions. - Can this method be applied to other industries beyond automotive?
Yes. The standard is written for any safety‑critical industry. The examples are automotive, but the principles of HER and STPA for HMI are transferable to aviation, medical devices, industrial control, etc.
🔍 By focusing on the human as a controller with cognitive depth, SAE J3187‑1 provides a powerful toolkit for engineers designing safety‑critical systems where human interaction is key. Incorporating these practices from the earliest stages of development helps prevent accidents rooted in human‑automation coordination.
