Electronics Guide

The Limits of the Component-Failure Model

Traditional hazard analysis inherits its structure from analytical decomposition: break a system into parts, analyze each in isolation, combine the results. That strategy is valid whenever a short list of conditions holds. Components must behave the same in isolation as in the assembled system, interactions among them must be direct and known, feedback loops and indirect couplings must be negligible, and the separate results must combine arithmetically. For the electromechanical systems safety engineering grew up analyzing, those conditions were close enough to true.

Behavior in the same tradition is modeled as a chain of events, each the direct result of the one before it. Fault tree analysis, event tree analysis, and hazard and operability studies all express causality this way, with logic gates used to fold several chains into one diagram. If accidents are chains of failure events, then prevention means eliminating events or placing barriers between them, which is what redundancy, interlocks, fail-safe design, overdesign, procedures, and training are meant to do. Probability enters because the events are assumed to be stochastic, so a rate can be attached to each and the rates combined.

The assumptions break in two places, and both matter for modern electronics. First, software does not fail stochastically. A defect is present in the first unit shipped and in the millionth, and it produces a wrong output every time the triggering condition occurs, so attaching a failure rate to it is a category error rather than an approximation. Second, and more damaging, the interesting hazards in software-intensive systems are frequently not failures at all. They are interactions among components that each satisfied their requirements.

The examples used to teach the point are unusually clean. On the Mars Polar Lander, sensitive sensors on the landing legs told the flight software that touchdown had occurred so that it could shut down the descent engines. Deploying the legs generated spurious signals. That behavior was real, expected in the hardware sense, and absent from the software requirements, perhaps because the software was not supposed to be running yet and the engineers had started it early to level the processor load. The software concluded the spacecraft had landed and cut the engines while it was still roughly forty meters above the surface. No component failed. The specification was wrong.

An aircraft thrust reverser interlock provides a second case. Reversers must not deploy in flight, so software checks clues such as weight on wheels and wheel spin-up before permitting deployment. On a very wet runway the wheels hydroplaned, the clues did not hold, and the aircraft overran the runway. A Tupolev airliner landing in Moscow in 2012 suffered a related sequence: a soft touchdown in a crosswind left the weight-on-wheels switches unactivated, and the crew, expecting reverse thrust as usual, applied high engine power and accelerated into an embankment. The interlock logic did what it was designed to do. The design assumed a mapping between measurable quantities and the state of the world that does not always hold.

The general lesson is that decompositional analysis cannot identify requirements errors, system design flaws, or human error shaped by system design, because none of those live inside a component.

STAMP: Accidents as Inadequate Control

Systems theory, developed in engineering after the Second World War to cope with rising complexity, offers a different starting point. Its central claim is that some properties belong to the whole and not to the summation of the parts. Such emergent properties arise from the relationships among the parts. Safety is one of them, as are security, operability, and maintainability. If an emergent property arises from interactions, then controlling it requires controlling both individual component behavior and the interactions among components.

That is a control problem, and it has a standard shape. A controller issues control actions to a controlled process and receives feedback that tells it what effect those actions had. The controller's job is to enforce constraints on the behavior of the process. STAMP takes that shape as its model of causality. In the words of the STPA Handbook, safety is treated as a dynamic control problem rather than a failure prevention problem, and the emphasis changes from preventing failures to enforcing constraints on system behavior.

Three ideas do the work. The first is the safety constraint: a statement of a condition or behavior that must hold for the system to remain safe, such as that aircraft maintain minimum separation or that a weapon never detonate accidentally. Constraints are the primary unit of the analysis and what a design must be built to enforce. The second is the hierarchical control structure: a model of the system as nested feedback control loops, in which higher levels impose constraints on lower ones and receive feedback about whether those constraints are met. The third is the process model: the controller's internal representation of the state of the process it controls, updated by feedback and used by its control algorithm to choose actions. When the process model diverges from reality, a controller working perfectly will do the wrong thing, confidently.

Two clarifications prevent a common misreading. STAMP is not an analysis method; it is a set of assumptions about how losses occur, from which methods are built. And the chain-of-failure-events model is a subset of STAMP rather than a rival to it, since component failures are one way a control loop can be inadequate. Control is also interpreted broadly: design controls such as redundancy, interlocks, and barriers count, as do process controls such as development, manufacturing, and maintenance procedures, and social controls including regulation, professional culture, insurance, liability, and the incentive structure of the organization. That breadth is why STAMP-based analysis extends naturally above the equipment into the management and regulatory structures around it.

The Control Structure and the Control Loop

The generic control loop has four parts, each a place where things can go wrong. The controller makes decisions and issues control actions; inside it sit the control algorithm, which determines what action to provide, and the process model, which represents the controller's beliefs about the process and its environment. Actuators execute the control actions on the physical world. The controlled process is whatever is being controlled, which may be a physical process or another controller. Sensors observe that process and supply the feedback that updates the process model.

A hierarchical control structure is a system model composed of such loops, stacked. In a vehicle braking application the stack might run from the driver, through a braking system control unit and its actuators, to the wheels and the road surface, with wheel speed sensors and dashboard indications closing the loops. Above the vehicle sit the manufacturer's engineering organization, the type approval authority, and the regulator, each issuing control actions in the form of requirements, approvals, and enforcement, and each receiving feedback in the form of test results, field reports, and incident data.

Two properties of the model deserve emphasis for electronics work. The control structure is functional, not physical: it captures responsibilities and information flows and deliberately avoids committing to an implementation, which is what allows the analysis to begin during concept development, before an architecture exists, and means that the constraints derived from it survive a reallocation of functions between hardware and software. Second, the structure is built iteratively. A first pass may contain three boxes; a later pass introduces subsystem controllers, labels each control action and feedback channel, and adds the sensors and actuators the loss-scenario step will need.

Building the structure has value independent of the hazard analysis. Large systems routinely lack a single document stating who is responsible for what and which information flows where, and the first serious argument in an STPA workshop is often about who actually controls a given function, a question that turns out never to have been settled.

Step One: Losses, Hazards, and System-Level Constraints

STPA proceeds in four steps. The first defines the purpose of the analysis, and it has three mandatory parts plus one optional refinement.

Identify the losses. A loss involves something of value to stakeholders: loss of life or injury, property damage, environmental pollution, loss of mission, loss of reputation, or loss of sensitive information. Different industries say accident, mishap, or adverse event; the handbook uses loss to avoid the collision of terms. Losses may be ranked, which matters because every subsequent result traces back to one or more losses and can be prioritized by them. Losses should not name components or presumed causes; writing human error as a loss forecloses the analysis before it starts.

Identify the system-level hazards. In STAMP a hazard is a system state or set of conditions that, together with a particular set of worst-case environmental conditions, will lead to a loss. The definition places hazards inside the system boundary and losses potentially outside it, which is the whole point of distinguishing them: designers control the system, and only partially control the environment. Choosing the boundary is therefore an engineering decision with consequences. Draw it too tightly and the analysis will exclude the interactions that matter. Draw it too loosely and it will generate constraints nobody has authority to enforce.

Identify the system-level constraints. Each is obtained by inverting a hazard and is traceable to the hazards it addresses. The handbook's aviation examples are characteristically terse: if a hazard is that aircraft violate minimum separation standards, the constraint is that aircraft must satisfy minimum separation standards from other aircraft and objects. Hazards may then be refined into more specific sub-hazards where that helps the later steps.

The output of step one is short, typically a page, and it is the specification against which every later result is judged. Teams that rush it generate impressive volumes of findings without a defensible account of what those findings prevent.

Step Two: Modeling the Hierarchical Control Structure

The second step builds the control structure described above. In practice it begins at high abstraction and is refined through several passes, and the refinement is driven by the analysis rather than by an urge to complete the diagram.

A workable sequence starts by identifying the controllers and the processes each controls, then allocating responsibilities among them as statements of what each controller must ensure, traceable to the system-level constraints from step one. Next, control actions are labeled: the commands each controller can issue to the entity below it. Then feedback is labeled: the information each controller receives from below and from its peers. Only after the functional loops are settled does the analyst add the sensors that produce the feedback and the actuators that execute the commands, because those are implementation choices the analysis should not be tied to prematurely.

Several structural pathologies show up at this stage. A controller with authority but no feedback cannot know whether its actions took effect; a controller with feedback but no authority can only watch. Two controllers issuing conflicting control actions to the same process is a classic source of loss, particularly where automation and a human operator both act on the same actuator under a nominally shared division of responsibility. The STPA Handbook notes that unclear delineation of responsibility for control increases both coordination difficulty and the number of causal scenarios, citing a pilot who is partially controlled by the airline operations center, by air traffic control, and by onboard systems such as the traffic alert and collision avoidance system.

Step Three: Identifying Unsafe Control Actions

The third step is the one that gives the method its distinctive output. An unsafe control action is defined as a control action that, in a particular context and worst-case environment, will lead to a hazard. The definition has three parts that must all be present in a well-formed statement: the control action, the context that makes it unsafe, and the link to the hazard it produces. A UCA that omits the context is not usable, because almost every control action is safe in some contexts and unsafe in others.

Each control action is examined against four categories, which are the columns of a standard UCA table:

• Not providing the control action leads to a hazard.
• Providing the control action leads to a hazard.
• Providing a potentially safe control action but too early, too late, or in the wrong order leads to a hazard.
• The control action lasts too long or is stopped too soon. This category applies only to continuous control actions, not to discrete ones.

The braking example in the handbook illustrates all four. An automatic braking system that does not brake during the landing roll leaves insufficient deceleration; the same system braking during a normal takeoff is unsafe for the opposite reason; braking more than some defined number of seconds after touchdown is a timing failure; and braking that ceases before the aircraft has slowed is the fourth type. That fourth column does not apply to a discrete command such as power off, which has no meaningful duration.

Every unsafe control action is then inverted into a controller constraint, a statement of behavior the controller must satisfy. If braking during a normal takeoff is unsafe, the constraint is that the unit must not brake in that context. These constraints are requirements, and they are the point at which STPA output enters the ordinary engineering process: they can be written into a requirements database, allocated to hardware or software, and verified. They feed test planning directly, because a well-formed UCA names both the stimulus and the context under which a test must demonstrate correct behavior.

Two practical notes. The table grows quickly, so analysts should record the assumptions behind each entry; a UCA that reaches the requirements database without its rationale becomes uninterpretable a year later. And the procedure applies unchanged to human controllers: a crew that does not power off a misbehaving unit when the procedure requires it is an unsafe control action of exactly the same form as one produced by a microcontroller.

Step Four: Deriving Loss Scenarios

A loss scenario describes the causal factors that can lead to the unsafe control actions and to hazards. This is the step that explains why, and the step teams most often truncate under schedule pressure, which is unfortunate because the mitigations live here. Two types must be considered: why an unsafe control action would occur, and why a correct control action would be improperly executed or not executed at all.

Scenarios in Which the Controller Behaves Unsafely

Working backward from a UCA, four general reasons explain why a controller might provide, or fail to provide, an unsafe control action.

A failure of the physical controller itself is the first, and it is the category traditional methods already cover well: the control unit fails, its power supply fails, its clock stops. STPA places these alongside the others rather than discarding them.

An inadequate control algorithm is the second. The specified algorithm may be flawed, the implementation may deviate from the specification, or the algorithm may become inadequate over time as the system or its environment changes. A processing delay that provides braking too late after touchdown is an algorithm scenario, as is a control law tuned for a vehicle mass the fleet no longer carries. For human controllers, the control algorithm is decision making, shaped by training, written procedures, and experience, and an inadequate procedure is analyzed exactly as an inadequate algorithm. Unsafe control input from another controller is the third, and it is usually covered already when the higher controller's own unsafe control actions are analyzed.

An inadequate process model is the fourth, and where system-theoretic analysis earns most of its reputation. The controller's beliefs about the state of the process are wrong, so a correct algorithm produces a wrong action. The handbook's enumeration of how this happens is the most directly useful checklist in the method. The controller receives incorrect feedback. It receives correct feedback but interprets it incorrectly, or ignores it. It does not receive the feedback when needed, because the information is delayed or never arrives. Or the necessary feedback does not exist at all, because nobody designed a channel to carry it.

That last case is the one no failure-based method can reach. Nothing broke; the information the controller needed was never made available to it. The Mars Polar Lander scenario is of this type. The flight simulator example in the handbook is a gentler version of the same defect: rudder pedals in a fixed-base simulator broke far more often than in the aircraft, because the software did not reproduce the small pitch-down movement a real aircraft makes when it comes to a stop. Lacking the feedback that tells them when to stop pressing, pilots pressed longer and harder. The fix is feedback, not stronger pedals.

Scenarios in Which a Safe Control Action Is Not Executed

The second family assumes the controller did the right thing and asks what happened next. The actuator may not respond, may respond partially, or may respond with the wrong authority. The command may be lost, delayed, or corrupted in transit, which in modern vehicles means the analysis reaches into bus arbitration, network scheduling, and message timing. The controlled process may not respond as modeled, because of wear, contamination, temperature, or a state the model omitted. And feedback about the executed action may be missing, so no controller learns the command did not take effect. Refining the control structure to include sensors and actuators before this step is what makes any of that analyzable.

Scenarios are not the deliverable. They are raw material for additional requirements, mitigations, architectural choices, test cases, and leading indicators of risk that can be monitored in operation. Used early they shape the architecture; used late they identify gaps in a design already fixed. Turning any of this into a certifiable product is described under functional safety implementation.

What STPA Finds That Fault Trees and FMEA Do Not

The claim that matters commercially is not that system-theoretic analysis is philosophically superior. It is that it finds specific classes of hazard the established methods structurally cannot. Three classes stand out.

The first is requirements error. Fault tree analysis and FMEA both take the specification as given and ask what happens when the implementation departs from it; neither has a mechanism for asking whether the specification is right. STPA generates constraints before and independently of the specification, by asking what the system must be prevented from doing, so a missing requirement shows up as a UCA with no corresponding entry in the requirements database. Where most behavior is defined in software, requirements errors dominate systematic failure, and effort spent verifying an implementation against a wrong specification is wasted with great precision.

The second is the component interaction accident. When two subsystems each meet their requirements and the combination is nonetheless hazardous, a bottom-up FMEA has no row to write the finding in, and a fault tree has no basic event to attach a probability to. The control structure makes the interaction explicit because it is a modeled information flow rather than an emergent surprise. The interlock that trusts weight-on-wheels is of this type, as is a smoke evacuation system whose fans depend on the same power source that the smoke-producing fault removes.

The third is human behavior. Traditional analysis treats operator error as a basic event with a probability, which places the human at the end of the causal chain and stops there. STPA models the human as a controller with a control algorithm and a process model, so mode confusion, loss of situational awareness, and automation surprise appear as design consequences with identifiable causes rather than as an irreducible error rate.

Leveson and Thomas report that across published comparisons with fault tree analysis, failure modes and effects criticality analysis, event tree analysis, and hazard and operability studies, STPA found all the causal scenarios the traditional analyses found and identified many more, often software-related and not involving failure, at lower cost. These are the authors' own summaries of their community's evaluations, and the independent assessments discussed below are more measured. The uncontroversial claim, sufficient on its own, is the structural one: methods that begin by enumerating failures cannot enumerate non-failures.

Human Controllers as a Design Consequence

The treatment of people is not a side benefit of the method; it follows from the model. If a human operator is a controller, then the operator has a process model, updated through displays, through communications from other controllers, and through direct sensory observation, and the operator's actions are generated by a decision process shaped by training, procedures, and experience. Every one of those is a design variable.

The consequence is that mode confusion becomes analyzable. It arises from a loss of consistency between the actual state of the automation and the operator's model of that state, which is a locatable defect: a transition the automation makes without informing the operator, an indication ambiguous between two modes, a display showing the commanded value rather than the achieved one. Rather than recommending more training, the analysis identifies the missing or misleading feedback and specifies it.

The STPA Handbook is blunt about the alternative. Telling operators to be mindful of weak signals, it argues, mainly creates a pretext for blame after a loss, because hindsight is what converts a weak signal into an obvious one. Instead, people must be trained on the specific hazards, on how to interpret combinations and sequences of alerts rather than single events, and on general strategies for unanticipated events rather than memorized responses to anticipated ones. The handbook adds a point that applies directly to interface design: because documentation of automation behavior is often poor, operators resort to hypothesis testing on the live system to update their mental models, so designers should provide a safe way to test hypotheses rather than pretend the practice does not occur.

None of this replaces quantitative human reliability work. The two are complementary: system-theoretic analysis identifies which operator behaviors the design makes likely and why, and human reliability analysis estimates how often they will occur.

CAST: Applying the Same Model After a Loss

CAST, Causal Analysis based on System Theory, is the retrospective companion to STPA, documented in the CAST Handbook published by Leveson in 2019. Its premise is that an investigation searching for the failure and the responsible party learns far less than the event has to teach. CAST changes the question from what failed to why the structures meant to prevent this loss did not do so.

A CAST analysis begins by assembling foundational information: it defines the system and the analysis boundary, describes the loss and the hazardous state that produced it, derives the system-level safety constraints that should have prevented that hazard, describes the events without drawing conclusions or assigning blame, and analyzes the physical loss in terms of the equipment, the requirements on its design, the failures and unsafe interactions involved, and the contextual factors that shaped what happened. Throughout, it generates questions to be answered rather than answers to be asserted.

The analysis then models the safety control structure that existed for this hazard and examines each component of it, starting at the bottom, to determine the role it played and, critically, the explanation for its behavior: why the people and systems involved did what they did, and why it seemed to them the right thing at the time. Next it identifies systemic factors that span components, the flaws in the control structure as a whole. Finally it produces recommendations for strengthening that structure, and where appropriate a continuous improvement program for the hazard.

The handbook stresses that these are not rigid sequential steps and that the process is designed specifically to resist hindsight bias. Its running example is the explosion of a chemical reactor and subsequent fire at the Shell Moerdijk plant in the Netherlands on 3 June 2014, in which reactor sections were thrown 250 meters and debris was found 800 meters away. Leveson notes that she developed the method while contributing to the analysis of major accidents including the loss of the Space Shuttle Columbia, Deepwater Horizon, and Texas City, and that factors common to all of them were routinely absent from the official reports.

For electronics organizations the practical value of CAST is that its output is directly comparable to STPA output. Both are expressed as constraints on a control structure, so an incident analysis produces findings in the same currency as the design analysis and can be fed straight back into it. Conventional practice, which yields a root cause in one document and a hazard analysis in another, has no such exchange rate. The wider machinery of investigation and corrective action is covered under failure analysis methodologies.

ISO 21448 and the Safety of the Intended Functionality

The automotive industry reached a similar diagnosis from a different direction and wrote a standard for it. ISO 21448:2022, Road vehicles — Safety of the intended functionality, was prepared by ISO technical committee TC 22, subcommittee SC 32, and published in June 2022 as a first edition that cancels and replaces the earlier publicly available specification ISO/PAS 21448:2019. The main changes on promotion to a full International Standard were an extension of scope to all levels of driving automation, reworked definitions clarifying the hazard model, and a new clause covering the operation phase.

The motivation is stated plainly in the introduction. ISO 26262 defines functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behavior of the electrical and electronic system. But for systems that build situational awareness by sensing their environment, the intended functionality and its implementation can cause hazardous behavior even when the system is entirely free of the faults ISO 26262 addresses. The introduction names three example causes: inability of the function to perceive the environment correctly; lack of robustness with respect to sensor input variation, fusion heuristics, or diverse environmental conditions; and unexpected behavior from decision-making algorithms or divergent human expectations. It adds that these factors are particularly relevant to functions that use machine learning.

Functional Insufficiencies and Triggering Conditions

The vocabulary is precise and worth learning exactly. SOTIF is the absence of unreasonable risk resulting from hazardous behaviors related to functional insufficiencies. A functional insufficiency is either an insufficiency of specification or a performance insufficiency. An insufficiency of specification is a specification, possibly incomplete, that contributes to hazardous behavior or to an inability to prevent or detect and mitigate reasonably foreseeable indirect misuse, when activated by one or more triggering conditions. The standard's own examples are an incomplete specification of adaptive cruise control headway distance that leaves the vehicle following too closely, and a system that cannot handle uncommon road signs because they were never specified.

A triggering condition is a specific condition of a scenario that activates a functional insufficiency: weather, lighting, road geometry, an unusual object, or a particular behavior by another road user. The distinction between the insufficiency and its trigger is the analytical core of the standard. The insufficiency is a persistent property of the design, latent and often unknown; the trigger is the circumstance that makes it visible. Verification therefore has two jobs, closing insufficiencies and searching the scenario space for triggers.

Misuse is handled more sharply than the phrase reasonably foreseeable misuse usually implies. ISO 21448 divides it in two. Direct misuse can itself cause hazardous behavior and is therefore a potential triggering condition; the standard's example is a driver activating a highway function in an urban setting, where the vehicle then fails to react to a stop sign. Indirect misuse does not cause the hazardous behavior but reduces the driver's ability to control it or increases the severity of the outcome, and is explicitly not a triggering condition; the example is a driver falling asleep while supervising a hands-free level 2 highway assistant. Deliberate alteration and use intended to cause harm are excluded from misuse altogether, and deliberate violations of the intended use are classed as feature abuse, outside the scope.

The Four Scenario Areas

ISO 21448 organizes the whole problem on two axes, whether a scenario is known to the developer and whether it is hazardous, giving four areas: area 1, known and not hazardous; area 2, known and hazardous; area 3, unknown and hazardous; and area 4, unknown and not hazardous. The purpose of SOTIF activity is to shrink areas 2 and 3 until the residual risk satisfies the acceptance criteria, which is why the standard devotes one clause to the evaluation of known scenarios and their residual risk, and a separate clause to the evaluation of unknown scenarios and the residual risk they carry.

Area 3 is the difficult one, and difficult by construction: it consists of the hazardous scenarios nobody has thought of, and no analysis enumerates it directly. The standard offers a strategy of conversion instead. Systematic analysis of functional insufficiencies and potential triggering conditions moves scenarios from area 3 into area 2, where they can be designed against. Broad verification and validation campaigns, including long-term and test-track vehicle testing, simulation, and model, software, and hardware in the loop testing with deliberate injection of potential triggering conditions, expose what analysis missed. Field monitoring during the operation phase continues that process after release, which is why clause 13 exists.

Acceptance Criteria

An acceptance criterion in ISO 21448 represents the absence of an unreasonable level of risk, and may be qualitative or quantitative, including criteria of the as low as reasonably practicable form. Its two examples are instructive. One derives a reasonable level of risk from traffic statistics, expressed as one accident per some distance driven. The other compares the function with an equivalent vehicle-level effect already proven in use to be controllable by the driver, suggesting that the trajectory perturbation from an unwanted lane-keeping intervention be compared with a lateral wind gust to define an acceptable level of authority. The second pattern is the more useful, because demonstrating a very low accident rate directly requires a distance driven that no test program can afford, whereas bounding a function's authority to something a driver already handles routinely can be argued and tested.

How SOTIF Composes with ISO 26262

ISO 21448 does not replace ISO 26262; the standard's own introduction calls the two complementary aspects of safety. ISO 26262 assumes the intended functionality is safe and addresses faults that cause deviation from it; ISO 21448 assumes the faults are handled and addresses insufficiencies in the intended functionality itself. The normative reference list contains exactly one entry, ISO 26262-1, the vocabulary part, which is a concise statement of the relationship.

The introduction includes a table mapping causes of hazardous events to the standards that address them. Faults of the electrical and electronic system fall to the ISO 26262 series. Functional insufficiencies, including those of algorithms based on artificial intelligence, and inadequate human-machine interface design fall to ISO 21448. Attacks exploiting vehicle security vulnerabilities fall to ISO/SAE 21434. Hazards caused directly by the technology, such as eye damage from a lidar beam, fall to standards such as the IEC 60825 series for laser safety. Reasonably foreseeable misuse is shared between ISO 21448 and the ISO 26262 series.

The standard is explicit about what it is not for. It is not intended for functions of existing systems where well-established and well-trusted design, verification, and validation measures already exist, and it names dynamic stability control and airbags as examples. SOTIF work is aimed at functions whose safety depends on situational awareness derived from complex sensors and algorithms, particularly emergency intervention systems and driving automation levels 1 through 5. In practice the two standards share machinery: the hazard analysis and risk assessment performed under ISO 26262 part 3 identifies vehicle-level hazards that SOTIF work then examines from the insufficiency side. The regulatory context is treated under automotive electronics standards.

Standardization, Tooling, and Adoption

System-theoretic analysis spent its first fifteen years as an academic method with industrial pilots, and has been moving into normative documents since about 2020. SAE International issued J3187 in February 2022 as System Theoretic Process Analysis (STPA) Recommended Practices for Evaluations of Automotive Related Safety-Critical Systems, and revised it in May 2023 with the scope broadened from automotive to safety-critical systems in any industry, supported by appendix documents issued in September 2023 covering STPA for human-machine interactions and for model-based systems engineering. For many organizations the existence of a recommended practice matters more than its content, because it gives an auditor a document to point at.

The primary references remain freely available. The STPA Handbook by Nancy Leveson and John Thomas, dated March 2018, and the CAST Handbook by Leveson, dated 2019, are published by the MIT Partnership for Systems Approaches to Safety and Security, which also maintains a public, searchable archive of presentations from the annual MIT STAMP workshop. Those presentations are the most useful adoption evidence available, because practitioners give them describing applications at named companies.

Tooling has improved but remains uneven. The 2013 assessment discussed in the next section noted that automated tools were under development and did not support all steps. Tools now exist for building control structures, managing UCA tables, and exporting requirements, and integration with model-based systems engineering environments is the direction of travel. Teams should still expect to do meaningful work in a spreadsheet. Adoption has clustered where the failure mode the method addresses is most obviously present: automotive driving automation, aerospace and air traffic concepts, industrial autonomy, and increasingly the analysis of machine-learning components. STPA has also been extended to security as STPA-Sec, on the handbook's reasoning that because STAMP applies to any emergent property, the same analysis serves any system property.

Criticisms and Honest Limits

The literature on system-theoretic methods is written largely by advocates, which is a reason to weigh independent assessments heavily. The most detailed public one in aviation is MIT Lincoln Laboratory project report ATC-427, Review of Systems-Theoretic Process Analysis (STPA) Method and Results to Support NextGen Concept Assessment and Validation, by E. P. Harkleroad, A. E. Vela, and J. K. Kuchar, dated 25 October 2013 and prepared for the United States Federal Aviation Administration. It examined an STPA analysis of interval management spacing, a NextGen air traffic concept, and its eleven findings are unusually specific. They predate the 2018 handbook, but the substantive ones have not gone away.

The first and most important limitation is analyst dependence. The Lincoln Laboratory review found that STPA, like every other risk modeling method, cannot by itself ensure that all safety issues are captured, and that the breadth and depth of an analysis depend on the quality of information available about the system, the expertise of the people performing it, and the resources applied. Subject matter experts must review the constraints STPA generates to confirm they are specific enough to guide design, and building control structure diagrams and process models to a useful level of detail requires the same expertise. The review estimated that preparing new users to study complex systems takes several days of training coupled with subject matter expertise built over months or years. Independent studies observe that analysts with the same STPA training do not always produce the same set of requirements.

The second limitation is that the step from scenarios to requirements is weakly specified. The review named the structured framework for identifying unsafe control actions and causal scenarios as the method's key value, but found no comparable framework for deriving constraints from those scenarios, which appeared to follow an ad hoc process much like other methods. The analysis it examined produced multiple duplicative requirements, with no direct way to detect duplication or to inform prioritization. Anyone who has watched an STPA workshop generate several hundred constraints of wildly varying importance will recognize the complaint.

The third limitation is the absence of probability, a deliberate feature rather than an oversight. STAMP defines risk in terms of the effectiveness of the controls used to enforce safe system behavior, that is, the design and operation of the safety control structure, and Leveson notes explicitly that this does not require determining the likelihood of events. The argument is strong where software and human behavior dominate, since neither is stochastic in the way the arithmetic requires. The practical difficulty is equally real: IEC 61508 states its targets as an average probability of dangerous failure on demand or an average frequency per hour, ISO 26262 sets a probabilistic metric for random hardware failures alongside single-point and latent fault metrics, and DO-178C assigns design assurance levels against airworthiness targets expressed per flight hour. A method returning constraints and scenarios does not answer those questions, so it cannot be the only hazard analysis in a program that must satisfy them.

The fourth limitation follows from the third: integration with integrity-level regimes takes deliberate effort, and the workable arrangement is complementary rather than substitutive. STPA is applied early, during concept and architecture, to derive constraints and expose requirements errors and interaction hazards while they remain cheap to fix; those constraints then become inputs to the conventional process. The Lincoln Laboratory review reached the same conclusion, recommending that the FAA apply STPA as an additional tool in concept development while stating that it is not a replacement for the existing safety management process, and noting the reverse benefit that STPA can help ensure adequate coverage of the hazards later quantitative analyses evaluate. Fault tree analysis and FMEA still quantify random hardware failure and support the integrity level arithmetic; STPA still finds the scenarios that have no failure to quantify.

Two further cautions are worth naming. Scalability is a genuine concern, since the space of system states grows combinatorially and no analysis enumerates it exhaustively; the control structure abstraction manages this but does not eliminate it. And the vocabulary collides with existing practice. The Lincoln Laboratory review observed that STPA uses terms such as hazard and controller with meanings different from those in the FAA safety management system process, and that the analysis it examined handled this with special notes and terminology changes. Any organization introducing the method into an established safety process should expect to spend real effort on a vocabulary mapping.

Conclusion

System-theoretic hazard analysis answers a question the older methods do not ask. Fault tree analysis and FMEA ask what happens when a part breaks, and answer it well enough to support the quantified integrity targets that functional safety standards demand. STPA asks what the system must be prevented from doing, models it as a hierarchy of control loops meant to enforce that prevention, and enumerates the ways the enforcement can be inadequate. Its distinctive yield lies in requirements that were never written, in interactions between subsystems that each met their specification, and in operator behavior the design made predictable.

ISO 21448 addresses the same territory from the automotive side with different machinery: it separates functional insufficiencies from the triggering conditions that activate them, sorts scenarios by whether they are known and whether they are hazardous, and treats the reduction of unknown hazardous scenarios as an explicit engineering objective pursued through analysis, validation, and field monitoring. It composes with ISO 26262 rather than replacing it.

The honest summary is that these methods are powerful and demanding. Their output quality depends heavily on who performs them and on how well the system is understood beforehand. They produce constraints and scenarios, not probabilities, so they must be paired with quantitative techniques wherever an integrity level has to be argued, and the step from scenarios to a prioritized, non-duplicative requirements set remains under-specified. What they offer in return is a systematic way to find the hazards that a search for broken parts will never reveal, which in software-defined, sensor-driven, human-supervised electronics is a growing share of the hazards that matter. Used early, alongside conventional hazard analysis and risk assessment rather than instead of it, that is worth the effort it costs.

Related Topics