Safety Driven Design with UML and STPA

; ; (). Safety Driven Design with UML and STPA: Talk. In: 4th MIT STAMP Workshop. (March 23-26). Boston, USA: Massachusetts Institute of Technology.

System Theoretic Process Analysis (STPA) is increasingly being used in diverse industrial sectors for the analysis of existing complex technical systems. At the Safety Critical Systems Research Lab of IAMP, we successfully applied STPA in several projects having a focus on the safety assessment of already designed and implemented systems. In accordance with proposals coming from other groups, we also strongly believe that STPA could ideally be used in the design phases of the systems engineering process, hence supporting the paradigm of safety driven design.

We certainly can state that every systems engineer has an intrinsic motivation to design safe and secure systems. With regard to the increasing complexity of today’s systems and the inadequateness of most of the established hazard analysis methods to cope with that in an efficient and timely way, it must not come as a surprise that the safety driven design paradigm remains on the wish list rather than to become reality.

We realize that the primary goal to reach in order to achieve safety guided design is to empower system engineers to analyze safety issues directly from their perspective and within their mindset. Approaches merely focusing on embedding safety processes into development processes will have little chance of success if this goal is not reached. Allowing system engineers to handle safety in a “natural” manner will automatically bring safety engineering and system engineering closer together.

Model driven design with UML and SysML is nowadays recognized as being the state of the art in technical systems engineering. As these tools are typically adopted from software system engineering it is primarily the software engineering community which proposes to use them for system safety – and security – matters, but not only [1-4].

In this talk we show how model driven design with UML and SysML can be extended to safety driven design by incorporating STPA directly into the design process.

1.1 Viewing a system as a Hierarchical Control Structure

UML and SysML allow multiple (graphical) representations of one and the same system from different perspectives. Depending on the interest of the stakeholders, respectively their context, different types of diagrams can be used to model specific aspects of a system. These types of diagrams include class diagrams, sequence and activity diagrams, requirement diagrams, deployment diagrams and others. We propose to use the hierarchical control structure as a new diagram type in UML/SysML to model the functional flow of control through the system, giving the system engineer yet another powerful option for design.

The advantage of using hierarchical control structures is that they have explicitly been designed to serve as a starting point for an STPA. They are optimized representations of the system for the purpose of hazard analysis with STPA. Indeed, being based on a well-defined type of system representation is one of the features that make STPA unique in our opinion. In contrast, FTA or FMEA typically base on whatever system documentation is available; for example electronic diagrams or mechanical drawings. However, such diagrams were not created primarily for the purpose of a safety analysis.

We investigated different types of UML and SysML diagrams with respect to their suitability to represent hierarchical control structures. Determining factors where the ability to represent the static structure in terms of controllers, controlled processes, control action connectors and feedback connectors but also the possibility to represent the dynamics of control actions and feedbacks which is typically not part of the hierarchical control structure but of importance for STPA Step 1 and 2. The result of our efforts is a metamodel specifically designed for the creation of hierarchical control structures derived from the class diagram specification of UML 2.0. We implemented this metamodel in the context of a software tool on the basis of Enterprise Architect by Sparx Systems [5].

The elements of hierarchical control structure diagrams (that is the controllers, control actions, etc.) can and should be linked to the design model of the system. However we did not aim for a stringent 1:1 coupling with the design model. Instead we propose a set of convenient processes which supports managing consistency between the models and which allow either to create a first version of a hierarchical control structure when a design model is available or vice versa to create parts of a design model based on an existing hierarchical control structure.

1.2 Inadequate Control Action Analysis (STPA Step 1)

The goal of STPA Step 1 is it to find Unsafe Control Actions which is accomplished by an assessment of all control actions of the hierarchical control structure with a set of pre-defined keywords. In recent projects where we applied STPA, we used to document this analysis in the form of tables. We not only captured the consequences that an inadequate control action might potentially have, but we documented any information necessary to re-construct the analysts’ thoughts. We left the choice of the format for this documentation, textual description, listings, or even drawings and figures, to the analyst. This way of documenting STPA Step 1 comes handy to analysts as they can simply write down what they think and do not need to bother about bringing their thoughts into a specific format and struggling with formulations to fit pre-defined tables. On the other hand this approach has the drawback in that it does not allow automatic machine interpretation nor a simple re-use of already captured scenarios. As a consequence, automated checks are not possible and every iteration, change or modification requires careful review of the complete tables again. A complete analysis of bigger systems is hence impracticable.

As in our approach the design model and the hierarchical control structure are already represented as UML models, the thought to make use of such models for STPA Step 1 is close. As a matter of fact, already before we considered using UML and SysML in combination with STPA, the idea to perform STPA Step 1 with graphical elements came up in one of the projects we worked on [6].

The approach which we developed and implemented in the software tool supports STPA Step 1 with generic elements which are specialized in the context of a specific control action and a keyword. The analysis of inadequate control actions can share the same specialized elements. Consequently the graph linking inadequate control actions to system hazards and accidents gradually evolves and is built up as the analysis progresses. Since the hierarchical control structure and the STPA Step 1 analysis are part of the UML/SysML model, inadequate control actions, hazards and accidents can ultimately be directly linked to system components and system design elements. Traceability from hazard analysis to system design comes in naturally.

1.3 Conclusion and Outlook

The approach we illustrate in this abstract is very promising and worked very well with the examples we applied it to. Having the design model linked with the safety analysis and all the elements of the hierarchical control structure and STPA Step 1 stored in the same repository allows to efficiently perform tasks which are central to safety guided design.

We are currently working on an extended case study together with a partner from industry. At the same time we continue to develop the software tool. We are integrating STPA Step 2 and we are building the necessary interfaces to finally seamlessly integrate it into the development processes and environment of our partner.


1. Douglas, B.P., Analyze system safety using UML within the IBM Rational Rhapsody environment. 2009.

2. Mayer, N., Model-Based Management of Information System Security Risk. 2009.

3. Teller, A. The implementation of system modeling methods in safety engineering. in Reliability and Maintainability Symposium (RAMS), 2014 Annual. 2014.

4. Mouratidis, H. and P. Giorgini, Integrating security and software engineering: Advances and future visions. 2007: Igi Global.

5. Enterprise Architect. Available from: www.sparxsystems.com/products/ea/.

6. Antoine, B., Systems Theoretic Hazard Analysis (STPA) applied to the risk review of complex systems: an example from the medical device industry. 2013, Massachusetts Institute of Technology.