An STPA Primer

ion and hierarchy The first technique—abstraction and hierarchy—is commonly used to help people deal with complexity. STPA is a top-down approach and makes extensive use of abstraction and hierarchy in developing and analyzing hazards, safety constraints, and control structures. Abstraction can also be applied to control actions to allow high-level analyses that can later be refined. Problems that are solved at high levels of abstraction may not need to be analyzed at lower levels of analysis, thereby reducing the total analysis effort. For example, when analyzing new aviation procedures for pilots, the control action “pilots execute passing maneuver” can be analyzed to identify problems and solutions at that high level as opposed to first considering the various lower level control actions—like entering information into autopilot systems or communicating with copilots—that together make up the passing maneuver. This control action abstraction can significantly reduce the number of context tables that need to be created to complete STPA Step 1 and to begin identifying new procedures, requirements, and causal factors in STPA Step 2. More important, the use of abstraction is essential in defining the columns for the context tables. For example, the train door example used one column labeled “emergency”. Clearly there are many different kinds of emergencies that could occur—fire, smoke, toxic gases, etc. The context table could be created with separate columns for each of these cases, however the table would quickly grow and become much more complex than is necessary at this stage. For the purpose of determining high-level door controller behavior, the exact type of emergency is not what matters; what matters is that an evacuation is required. Therefore, “emergency” is defined in the context table as any condition that requires passenger evacuation. Further analysis can and should eventually identify and define all the types of emergencies that might require evacuation so that design efforts can be made to prevent those occurrences. However, the analysis of the door controller—including the context tables—can be performed at a higher level of abstraction in a top-down fashion before that level of detail is defined. In fact, an important goal of this approach is to help during early phases of design when very little is known about the system. In these cases, abstraction is natural because most details have not yet been defined, and the analysis can be used to drive the design and determine which details may need to be defined or developed first. Logical simplification The second technique—logical simplification—was already employed when introducing the context tables for the train door. In this example, the four columns of variables each with two possible values would really require a 16 row table. However, the context table in Table 3.2 only required six rows. By reducing similar rows with “doesn’t matter” terms, the table can be drastically simplified. For example, the last row in Table 3.2 represents eight unique contexts. This simplification is possible because if the train is moving, then the specific value of the other variables don’t matter – keeping the door closed is not hazardous. Automated tools can help perform this reduction automatically or assist the user in identifying and specifying these simplifications, as discussed later in this Chapter.