System-Theoretic Safety Analysis

The nature of accident causation has, however, become more complex over time. Twenty years ago, accidents causation theory was developed further to capture this increased complexity and a new class of models emerged based on a holistic and systematic approach [Lev04a]. Furthermore, the prevailing chain-of-failure-events models provide the basis for almost all of today’s hazard analysis techniques and the probabilistic risk assessment based on them. All of these analysis and design techniques focus on hardware component failures

and thus reliability theory [Lev11]. These methods assume that accidents are caused by component failures. However, they are not enough to explain accident causation in the more complex systems.

The development of accident causation models and safety analysis from for- merly sequential models to systemic models shows the evolution of safety analysis for complex systems. We must emphasis that traditional analysis types, like FMEA or FTA have been designed for simpler systems than nowadays being created in the industry. The integration of technological, software system compo- nents stretches the limits of safety analysis. Therefore, new methods are needed which can actually cope with today’s complex systems.

To overcome the limitations of the traditional hazard analysis, a recent coun- termeasure is to advance safety analysis techniques by system and control theory rather than reliability theory. The STAMP (System-Theoretic Accident Model and Processes) [Lev04a] accident model developed by Leveson, which uses system theory and treats safety as a control problem. Hence, it describes the system as a whole as opposed to linear cause effect relationships or epidemiological factors within the system. STAMP also continues corresponding hazard and accident analysis methods. Within this method, accidents are considered as results from inadequate enforcement of safety constraints in system design, development and operations. STAMP treats safety as a control problem rather than component failures. STAMP is based on system theory, which was designed to understand the structure and behavior of any type of system. In a system-theoretic approach, the system is seen as a set of control components which interact with each other (shown in Figure2.2). This helps to create models of systems which cover human, technology, software, and environmental factors [Lev04a]. Therefore, STAMP considers accidents not only arising from component failures, but also from the interaction among system components. In other words, accidents occur when component failures, external disturbances and/or dysfunctional interactions among system components are not adequately handled by the safety control system [Lev04a].

The STAMP approach can be divided into two different analysis methodologies. While STAMP acts as an underlying theory, the methods STPA (System-Theoretic Process Analysis) and CAST (Causal Accident Analysis based on STAMP) are to be practically used for safety analysis. STPA is designed for safety analysis in the

system development and operation stage; the goal here is to identify hazards existing in the system and providing so-called safety constraints to mitigate those hazards. CAST is designed for accident analysis, the goal here is to identify causal factors, which lead to the accident.

2.2.2.1. STPA

STPA (System-Theoretic Process Analysis) [Lev11] is a safety analysis technique based on the STAMP model of accidents for large and complex systems. STPA has been developed to identify more thoroughly causal factors in complex safety- critical systems including software design errors. STPA aims to create a set of unsafe scenarios that can lead to an accident. It is similar to FTA but STPA includes a broader set of potential scenarios, including those in which no failures occur, but the problems arise due to unsafe and unintended interactions among the system components [Lev11]. STPA provides guidance and a systematic process to identify the potential for inadequate control of the system that could lead to a hazardous state which results from inadequate control or enforcement of the safety constraints.

The basic components in STPA are fundamentals of analysis, safety constraints, unsafe control actions, and control structure diagrams and process models (shown in Figure2.3). A control structure diagram is made up of basic feedback control loops. An example is shown in Figure2.2. When put together, they can be used to model the high-level control structure of a particular system. In table 2.1, we itemized the most relevant terms of STPA approach.

Furthermore, STPA was developed also to address increasingly common com- ponent interaction accidents which can result from design flaws or unsafe inter- actions among non-failing (operational) components [Lev11]. It accumulates information about how hazards can occur. This information can then be used to eliminate, reduce, and control hazards in system design, development, man- ufacturing and operations. The STPA safety analysis process is carried out in three major steps (shown in Figure2.4):

• STPA Step 0. a: Establish the fundamentals of the analysis (e.g. system description, system-level accidents, system-level hazards, safety and design requirements).

Figure 2.3.: The main components which are used in STPA

• STPA Step 0. b: Draw a high-level safety control structure diagram in which the system is viewed as interacting components. Figure2.2shows the general control feedback control structure.

• STPA Step 1: Identify the potential unsafe control actions of the system that could lead to one or more system-level hazards. Leveson [Lev11] defined four types of hazardous actions:

– A control action required for safety is not provided or is not followed. – An unsafe control action is provided that leads to aHazard.

– A potentially safe control action is provided too late, too early, or out of sequence.

– A safe control action is stopped too soon or applied too long (for a continuous or nondiscrete control action).

• STPA Step 2: Identify accident scenarios that explain how unsafe control actions might occur and how safe control actions might not be followed or executed.

Figure 2.4.: The main steps of the STPA approach 2.2.2.2. Extended Approach to STPA

A new extended approach to STPA was introduced by Thomas [Tho13;TL11], whose approach aims to identify unsafe control actions in STPA Step 1 based on the combination of process model variables of each controller in the control structure diagram. Some control actions in the system can only be hazardous in a certain context. Therefore, the process model variables should be assembled to define a context and analysed based on their context to check whether this combination could lead to a hazard or not. Table2.2shows theContext table of providing control action CA_i based on the relevant process model variable values Cs =S(P1= v1, . . .Pn= vn).

Table 2.1.: STPA Terminology

Terminology Definition

Accident Accident (Loss) results from inadequate enforce- ment of the behavioral safety constraints on the process [Lev11].

Hazard Hazard is a system state or set of conditions that, together with a particular set of worst-case environ- mental conditions, will lead to an accident [Lev11]. Unsafe Control Ac-

tions are the hazardous scenarios which might occurin the system due to a provided or not provided control action when it was required. [Lev11]. Safety Constraints The safety constraints are the safeguards which

prevent the system from leading to losses (acci- dents) [Lev11].

Process model The process model is a model required to deter- mine the environmental and system variables and states that affect the safety of the control actions and it is updated through various forms of feedback. [Lev11] [Tho13].

Process model vari-

ables variables of the controller in the control structureThe process model variables are the safety-critical diagram which have an effect on the safety of issu- ing the control actions [Lev11] [Tho13].

Causal Factors Causal factors are the accident scenarios that ex- plain how unsafe control actions might occur and how safe control actions might not be followed or executed [Lev11] [Tho13].

• Identify the relevant process model variables of each control action of the controller in the control structure diagram.

• Create the context table for each control action. A context table is combi- nation sets of the process model variable values (shown in Table2.2and Table2.3).

Table 2.2.: The context table of providing the control actionCA_i Control Action Process model variables Hazardous ?

CA_i P₁ P₂ . . . P_n at any time too early too late v₁₁ v₂₁ . . . v_n1 no/yes no/yes no/yes v₁₂ v₂₂ . . . vn2 no/yes no/yes no/yes

. . . .. .. ..

v_1n v_2n . . . v_nn no/yes no/yes no/yes Table 2.3.: The context table of not providing the control action CA_i Control Action Process model variables

Hazardous ? CAi P₁ P₂ . . . P_n v₁₁ v₂₁ . . . v_n1 no/yes v₁₂ v₂₂ . . . vn2 no/yes . . . .. v_1n v_2n . . . v_nn no/yes

contexts (C₁= Providing CA or C₂ = Not Providing CA) to determine whether the control action CAi is hazardous in that context or not. Thomas [Tho13] mathematically discussed the formalization of STPA which can be used not only to identify unsafe control actions and other control flaws, but also to generate requirements that will enforce safe behaviors.