Systems Theoretic Process Analysis (STPA) with safeTbox

This article will briefly show you how the STPA framework is supported in our modeling tool safeTbox. If you work in the safety field, you might also be interested in these other features CFT, HARA. GSN. Please have a look.

Management

The implementation done in safeTbox has been aligned with the procedures defined in the STPA handbook. This article assumes that you are familiar with the four-step process:

1. Defining the purpose of the analysis
2. Building the Control Structure Diagram
3. Identifying unsafe control actions
4. Identification of causal scenarios

In order to manage the complexity of the system and the analysis process itself, we have created in safeTbox the so called “STPA Manager”. The STPA Manager editor can be created for a model, a view or package in Enterprise Architect (EA) as shown in the figure below. (Use the safeTbox context menu-> e.g. select a model-> Ctrl + Space)

This editor includes a navigation pane on the left-hand side that allows you to follow the steps of the process one by one. As you will see later, the STPA Manager can aggregate multiple control structures, UCA analysis and causal scenario analysis. In a simple or focused analysis, it is likely that you will only need one for each of these. However, it may be difficult to determine how the analysis will evolve. Therefore, our approach allows you to create multiple tracks of analysis, depending on how you distribute your efforts. There are several reasons for this:

Because the system is too complex or too large.
Because of the need to investigate different concerns (e.g. safety / security).
To speed up the analysis process by assigning parts to different analysts.

Step 1: Defining the purpose of the analysis

As mentioned above, one of the first key aspects of knowing what to model and what to analyze is to define the boundary of the system and the focus of your analysis. The STPA Manager allows you to do this. Note that this information is not mandatory to proceed with the other steps in the process, for example if you want to start the analysis in an exploratory way. However, it is recommended that this information is filled in, to set the right level of detail or abstraction.

As you can see in the following figure, the navigation panel defines several sections that allow to structure this information. Firstly, the system and context can be defined. This gives an idea of the functionality of the system and the operational context. The editor will allow you to define this in natural language and will support you in associating artefacts that exist in the EA project. For example, architecture diagrams such as SysML block diagrams, activity diagrams and so on, as well as individual modelling elements if you prefer. This can be useful to show the exact context (e.g. highway, summer,…).

As part of this section, you can also specify assumptions and policies. The latter can be useful when considering security related analysis.

The Loss Identification section brings together two points as suggested in the STPA Handbook. One is the definition of stakeholders and their objectives, and the other is the definition of losses. In theory, reversing the objectives should give a good indication of the losses or aspects that are unacceptable to the stakeholders. In practice, this step is usually skipped and the losses are specified directly. Note that it would be wise to perform this step as it could give good hints in which direction the upcoming analysis should focus, e.g. safety, security, performance etc., which as mentioned earlier could lead to the definition of multiple analysis tracks.

The STPA manager supports the definition of safety-related hazards, security-related threats and generic undesirable states, which can be used to analyze any other system property. In particular, hazards could have been defined from one of our other modelling techniques, namely HARA for ISO 26262. Note that although this section is important, it could be considered optional, as you may not have any results from other analyses, your investigation of hazards may not have directly yielded any undesirable states, or you may simply decide not to define any, assuming that you will find them anyway during the analysis steps.

In a final step, system constraints are specified for the identified unwanted system states. In safeTbox, system constraints are supported by SysML requirements. A mapping could be established in a similar way to that shown above for stakeholders and goals.

Step 2: Construction of the control structure diagram

The Control Structure Diagram can be created using the appropriate section in the STPA Manager dialog. As mentioned above, multiple Control Structure Diagrams can be specified to manage the complexity of the system or analysis.

Once the control structure has been created in the STPA manager, the navigation button opens the EA diagram where you can carry out the modelling. It will automatically load the toolbox with the modelling elements and connectors. safeTbox also offers several usability features to facilitate the modelling activities. These can be found in the safeTbox context menu (Ctrl + Space).

Together with the EA diagram, a supporting dialog is opened. This dialog allows you to see the currently defined control interactions and to define functional requirements (SysML requirements) for them.

Step 3: Identification of Unsafe Control Actions (UCA) Analysis

The creation of a UCA analysis track can be done within the STPA Manager in the dedicated section. Note that there must be at least one Control Structure Diagram in place to start identifying unsafe control actions. This will allow you to follow a distributed analysis approach. For example, you could structure your analysis to create several sub-control structure diagrams as you intend to analyze them separately, i.e. for each control structure, you could dedicate a specific UCA analysis track. This might be useful if the system is too large to be considered in a single track, or if you have several analysts. Alternatively, you could decide to have a single Control Structure Diagram but define multiple UCA analysis tracks so that you split the analysis. This could be a useful approach if you are analyzing different system properties (e.g. safety and security).

Navigating to the UCA analysis will bring up an editor. In this editor, the user can add the control actions to be analyzed and proceed with the main parts of the analysis, i.e. identifying critical UCAs by associating them with hazards, threats or undesired states (generic form), as shown in the following figure. In addition, the user has the possibility to associate context variables. In safeTbox, these can be any modelling element present in the EA project.

Note that the analysis is usually guided by a set of guidewords. In safeTbox these can be set directly in the application settings or overridden directly in the specific UCA analysis editor. This allows you to specify a catalogue that you can easily reuse, but which you can tailor to your specific analysis needs. For example, you might decide to create a catalogue of safety and security related keywords and then, for a specific UCA analysis, remove those that are not relevant to analyze the specific system property. Another important part of this step is to define the requirements (e.g. safety / security) for the identified critical UCAs. This is done in the requirements section of the editor, where only those UCA’s that are associated with a hazard, threat or undesirable condition are displayed. Note that this view allows you to see the existing requirements associated with the hazard as defined in the purpose definition step as well as the requirements associated with the control actions as defined in step 1.

Step 4. Identification of Causal Scenarios

The final step in the STPA framework is the identification of causal scenarios and their associated causal factors. This takes place primarily after the critical UCAs have been defined, as the aim is to identify more concrete reasons why they might occur. For this reason, the creation of a Causal Scenario Analysis track within the STPA Manager requires the selection of a UCA analysis.

The Causal Scenario Analysis editor will allow scenarios to be specified using guidewords in a similar way to the UCA analysis. Note that these guidewords can also be specified and customized in a similar way. In addition to the scenario specification view, the editor will display a new Control Structure Diagram representation where the current UCAs under analysis can be easily displayed using the dedicated context menu functions. The editor will also display the requirements associated with the UCA as defined in the previous step, as well as the requirements tracing to the hazards and control actions. The user will also be able to define causal scenario specific requirements.

In STPA, the identification of causal scenarios shall be performed deductively and inductively. A deductive analysis is performed when the UCAs are used as the entity of analysis and an inductive analysis is performed when control interactions are used. The Causal Scenario Analysis Editor therefore provides a dedicated section for inductive analysis.

safeTbox is completely free for non-commercial usage. You can access the tool installer after completing the subscription to our email list.

For commercial usage of the safeTbox, please contact us and we will get back to you with the options suiting your particular usage scenario.