STPA enabled safety assessment in the architecting of complex systems

Abstract STPA is a hazard assessment technique that represents systems as hierarchical control structures composed of feedback control loops. Existing computational support focuses on creating the diagrams that depict these hierarchies. However, the elements in the loops and the signals exchanged must be determined manually. This impedes safety assessment, thus reducing the number of designs that can potentially be explored. Furthermore, the manual approach does not guarantee the correct update of the architecture with changes resulting from safety assessment, which can make the architecture inconsistent with the safety assessment. To overcome these limitations, proposed for the first time are two methods that automate the creation of: (1) hierarchical control structures and (2) detailed control loops. The methods create STPA models by analysing the architecture, which is modelled as a graph. The concept is illustrated with a representative example of a wheel brake system. The resulting models are compared with those obtained manually by the authors of STPA. The automation is shown to significantly reduce the required time and effort. It was also found to ensure consistency among the safety analysis and the architecture definition as it requires safety features to be included in the architecture before being considered in STPA analysis.


Introduction
Safety refers to the avoidance of catastrophic effects such as injuries, loss of life and environmental damage. It is a crucial analytical element of systems design, as it rules out those options that fulfil the design goals but do not guarantee the elimination of behaviours that can lead to catastrophic effects.
Safety is particularly important for civil aircraft where accidents could result in many fatalities. This has motivated the establishment of regulatory agencies, such as the European Aviation Safety Agency (EASA), which define the minimum safety requirements aircraft must meet to obtain a certificate of airworthiness. Their efforts have succeeded in reducing the number of fatalities involving passenger and cargo operations of large aeroplanes worldwide (European Aviation Safety Agency, 2020a). However, the growing complexity of systems and the use of innovative solutions, such as novel configurations and increasingly more electric aircraft, introduce new challenges. Traditional safety methods might be insufficient for complex systems and much of the past experience regarding safety might not apply to the new designs (Leveson, 2012, pp. 3-6). Within this context, the broader aim of this research is to facilitate the application of safety methods that can improve the efficiency of the safety assessment process of complex, innovative systems.

Hazard assessment and the system theoretic process analysis STPA
Two standards, the ARP 4754 A (S-18 Aircraft and Sys Dev and Safety Assessment Committee, 2010) and ARP 4761 (S-18 Aircraft and Sys Dev and Safety Assessment Committee, 1996), describe the safety assessment process, which aims to show compliance with safety regulations such as EASA's CS-25 (European Aviation Safety Agency, 2020b). As defined by these standards, Functional Hazard Assessment (FHA) is the stage in the safety assessment process that identifies potential functional failures and classifies the associated hazards. Hazard assessment is a part of the FHA process where the system is examined to identify safety-related risks (Federal Aviation Administration, 2000), which can be used to derive safety requirements for the system.
Traditionally, hazard assessment revolves around the processes and methods described in the ARP 4761 such as fault tree analysis (FTA) and failure modes and effects criticality analysis (FMECA), and other traditional methods such as event tree analysis (ETA) and hazard and operability analysis (HAZOP). According to Leveson et al. (2014), these methods have been effective when applied to relatively simple electromechanical designs, but they are no longer suitable for more complex and software-intensive systems. This is because in complex systems accidents may result from unsafe interactions among the components and not just from component failures.
To overcome these limitations, alternative hazard assessment methods such as the System Theoretic Process Analysis STPA (Leveson, 2012) have been proposed. As shown by a review by Patriarca et al. (2022), the method has gained popularity in recent years, especially in the fields of aviation, maritime and automotive, which account for the highest number of publications. STPA is based on STAMP, an accident model that is founded on basic systems theory concepts (as opposed to traditional methods, which are based on reliability theory) and includes additional causes for accidents such as system design errors, human error and various types of systemic accident causes (Leveson, 2004). Leveson and Thomas (2018) argue that STPA hazard analysis can find the same failure scenarios found by traditional analyses but also many more software-related and non-failure scenarios. Additionally, STPA is claimed to be less costly in terms of time and resources than traditional methods (Leveson & Thomas, 2018). STPA-based safety assessment (Leveson, 2012;Leveson & Thomas, 2018) consists of four steps: 1. Define the purpose of the analysis identifying system-level hazards (states that lead to a catastrophic effect) and constraints (system-level requirements to prevent hazards). 2. Model the control structure, which is composed of feedback control loops ordered by a decreasing level of control authority. The structure includes controllers and controlled processes, which exchange control actions, feedback signals and other inputs and outputs. 3. Examine the control structure to identify unsafe control actions, which can lead to a hazard in a particular context, as they are not provided, provided improperly, or with inadequate timing. Controller constraints (safety requirements) are defined to prevent such actions. 4. Examine detailed control loops to identify loss scenarios, such as unsafe controller behaviour, inadequate feedback or component failures that can lead to unsafe control actions.

Existing STPA support methods and computation tools
A total of eleven state-of-the-art software tools that support STPA and two methods, which use STPA to automate the generation of safety requirements, were reviewed. Table 1 summarises the results from the literature review. It provides information about how the tools and the method support the STPA methodology based on three capabilities: Diagrams & Tables refers to the ability of a tool to provide a user interface to edit STPA analysis data, draw the control structure diagrams and edit tables such as the losses, hazards or unsafe control actions tables. Traceability implies that the tool is able to automatically indicate which elements, such as losses, hazards and unsafe control actions, relate to others. Traceability is obtained by automatically following links between elements, which are created manually by the analysts. Automation refers to additional support that automates any part of the STPA process except for traceability (The right column of Table 1 also lists particular automated capabilities where applicable).  (Krauss, Rejzek, Senn, et al., 2016) (Krauss, Rejzek, Reif, et al., 2016) (Thomas & Leveson, 2013) Rule-Based Approach for STPA (Gurgel et al., 2015) No No Context table, guidewords for scenarios All the computational tools provide a user interface which users can employ to create control loops and hierarchy diagrams, and populate tables with losses, hazards and control actions among others. The methods (last two rows of the table) are not computational tools and therefore do not have a user interface.
The most common automation feature is traceability, which is explicitly supported by SAHRA, Risk Management Studio and CAIRIS. SAHRA goes beyond the standard tabular format and introduces mind maps, a directed graph that enables traceability and presents elements such as losses, hazards and unsafe control actions among others.
A greater degree of automation is provided by the method for automated generation of formal model-based safety requirements (Thomas, 2013;Thomas & Leveson, 2013) and An STPA Tool, as it implements such a method. The method explains how to generate a list of potential hazardous control actions by combining controllers, types of action, control actions and contexts. Requirements are generated by determining the combinations that prevent hazardous behaviour. This can be automated depending on the availability of behavioural models. The method is also able to check the lack of consistency which arises when both providing or not providing an action within the same context is considered hazardous or when a necessary function of the system results in a hazard. Gurgel et al. (2015) extend the method by Thomas (2013) with a rulebased approach that assists in the identification of hazardous contexts. WebSTAMP is a web-based STPA tool that implements this approach.
The tool by Abdellatif and Holzapfel (2021), which links Simulink to STPA, is the only one that automatically determines the components in the STPA control hierarchy. However, it requires manual linking of the components of the hierarchy. It also provides automated verification of missing links (control or feedback) between controllers and controlled processes, and sensor compatibility.
As the review shows (Table 1), the degree of automation provided by the existing tools is generally low, especially regarding the creation of STPA diagrams, which model the control hierarchy and control loops. This can impact the total time required for STPA analysis, which is likely to result in common problems such as safety assessment lagging behind other aspects of the design (Delange & Feiler, 2014) and sometimes taking place later on in the product development process after the design is finalised (Mhenni et al., 2014). Manual application of safety methods is susceptible to errors when extracting safety models from the system definition, which has been found to bring unnecessary subjectivity and inconsistency to the analyses (Joshi et al., 2007). The lack of consistency between different design abstractions and outdated models as the design progresses has been identified as one of the primary sources of inconsistency in safety analyses (Papadopoulos et al., 2001). Errors when creating STPA models and inconsistent design abstractions might lead to problems such as missing or misplacing links or omitting elements in the control hierarchies and loops.
To overcome the above-presented limitations, two novel methods have been developed, enabling the automatic creation of STPA control hierarchies and control loops. The effect of such automation is twofold: it accelerates the STPA process while ensuring its consistency with the evolving system design. That is, safety can be performed concurrently with system architecting. The scope of the research is restricted to the conceptual design stage, which is critical in its impact on the whole product development process. For example, safety deficiencies discovered at later design stages might need to be corrected at the expense of performance or may require substantial costly redesign.
The rest of the paper is organised as follows. The proposed methods are presented in Section 2. Section 3 demonstrates the application of the proposed approach to a representative use case and compares it to the manual application of the method. Finally, conclusions are drawn and future work is suggested in Section 4.

Proposed methods
This section describes two novel methods developed to support the STPA hazard assessment process in the identification of unsafe control actions and loss scenarios. Specifically, the methods enable for the first time the automatic creation of the models required for steps 2, 3 and 4 of the STPA hazard assessment process (see Section 1.1.). The first method automatically generates the high-level view of the hierarchical control structures including all controllers. This is necessary to identify unsafe control actions during Step 2 of STPA. The second method automatically creates more detailed control loops, whose additional information supports the identification of loss scenarios during Step 4 of STPA. Both methods use the information in the (system) architecture to elaborate such models, and therefore, the quality and level of detail of the STPA analysis will be influenced by the quality and level of detail of the architecture definition.

Input to the methods, the logical view
The input to the methods is the logical view of the system, which is the part of the architecture definition that displays the solutions and the way they are interconnected. Solutions are the elements (such as parts, components or subsystems) that perform (fulfil) the required functions of the system (Guenov et al., 2020). As defined in the STPA methodology, certain solutions have the role of controllers in the systems, whereas the rest correspond to the controlled processes.
Solutions exchange energy, matter and signal flows through their input and output ports. These relations are referred to as flow relations. Flow relations can be modelled as a directed graph (Guenov et al., 2020). This graph can be used to determine which solutions are affected by the flow originating at one solution or which solutions affect a particular solution. Relations of this kind are used within the context of STPA to identify the flow exchange among controllers and processes. An example of a logical flow view is shown in Figure 1, which illustrates the architecture of a wheel brake system. The hydraulics, which provides the power to the wheel brake, can be controlled either directly by the crew or via a controller. The controller receives feedback from a sensor that measures the status of the wheel. Solutions can be formed by the aggregation of other solutions. For example, several simple components might form a subsystem. These relations are referred to as hierarchical relations. Hierarchies can be modelled as a treea directed acyclic graph. This graph can be used to determine the subsystem a component belongs to or the actual components that form a subsystem at the various levels of the hierarchy. Hierarchical relations provide a means of determining the position of the controllers in the STPA hierarchical control structure. Figure 2 shows the same architecture as in Figure 1 but emphasises how solutions are aggregated into subsystems. In particular, the figure highlights that the controller, the hydraulics, and the sensor are defined as children of the brake subsystem.
The methods were developed with the assumption that a logical view of the system exists, as part of the system architecting process. The logical view is used for defining the solutions (components) of the system and their interrelations and is not tied to any particular analysis. In this research, the input to the presented methods is an RFLP model of the architecture defined according to the framework introduced in (Jimeno Altelarrea, 2021). The RFLP paradigm, based on the German Guideline Design methodology for Mechatronic Systems (VDI 2206, VDI Department of Product Development and Mechatronics, 2004) assumes that systems architecting is distributed over four notional domains: Requirements, Functional, Logical and Physical. It must be noted that the proposed methods are not restricted to the RFLP paradigm and should be easily adaptable to other kinds of architectural representations, if they include equivalent concepts to flow and hierarchical relations and provide a means to identify controllers.

Creation of hierarchical control structures
The hierarchical control structure is a graph formed by controller nodes and one or more process nodes at the bottom of the hierarchy. Each controller solution in the logical view is mapped to a controller node in the hierarchy, and the rest of the solutions are grouped into process nodes. By default, only one process node is created in the presented method for creating hierarchical control structures. However, the user can specify more process nodes by indicating which solutions are to be included. Solutions for which no process node is specified will be grouped in the default node. The method uses Algorithm 1 to create the hierarchy and add the links from controller and non-controller solutions. Specifically, Algorithm 1 calls the function ADD-LINKS-FROM-CONTROLLER, which is described in Algorithm 2, to create the links in the hierarchy, starting from or ending at a controller j. The connections are determined by applying the following rules: 1. Traverse the logical view of the architecture starting from a port p in controller j including every component that can be reached by following flow links in the direction of the flow. The traversal through a particular link ends when a controller solution is found, immediately after including such controller. This forms the set of components R I j influenced by j.
2. The controller solutions in R I j represent the set of controllers K I j influenced by j. 3. A link in the hierarchical control structure is formed between the nodes representing j and each controller j i in K I j , excluding the initial controller j. The type of the link is determined by comparing the controllers' position in the logical hierarchy: If j is higher than j i a link of type 'ControlAction' is added. If j is lower than j i a link of type 'Feedback' is added. Otherwise, the link is of type 'SameLevelInputOutput'. The initial port in the traversal p is associated with the link.
4. The non-controller solutions in R I j represent the set of non-controller solutions S I j influenced by j. 5. If S I j 6 ¼ ;, which represents the case where non-controller solutions are directly controlled by j, a link of type 'ControlAction' is added between the node representing j and each process node p i that includes a solution in S I j : 6. Traverse the logical view starting from p including every component that can be reached by following flow links in the opposite direction to the flow. The traversal through a particular link ends when a controller solution is found, immediately after including such controller. This forms the set of components R I 0 j that influence j. 7. The controller solutions in R I 0 j represent the set controllers K I 0 j that influence j. 8. A link is formed in the hierarchical control structure between the nodes representing j and each controller j i in K I 0 j : The type of the link is determined by comparing the controllers' position in the logical hierarchy: If j i is higher than j a link of type 'ControlAction' is added. If j i is lower than j a link of type 'Feedback' is added. Otherwise, the link is of type 'SameLevelInputOutput'. The initial port in the traversal p is associated with the link. 9. The non-controller solutions in R I 0 j represent the set of non-controller solutions S I 0 j that influence j. 10. If S I 0 j 6 ¼ ;, a link of type 'Feedback' is added between the node representing j and each process node p i that includes a solution in S I 0 j : The function ADD-LINKS-FROM-NON-CONTROLLER, described in Algorithm 3, creates the links in the hierarchy, starting from or ending at a process node associated with a non-controller r. The connections are determined by applying the following rules: 1. Traverse the logical view of the architecture starting from a port p in solution r including every component that is directly linked to p by following flow links in the direction of the flow. This forms the set of components R I r influenced by r. 2. For each r i in R I r , a link is formed in the hierarchical control structure between the process node that contains r and the process node that contains r i . The link is of type 'SameLevelInputOutput'. Duplicated links are omitted. 3. Traverse the logical view starting from p including every component that is directly linked to p by following flow links in the opposite direction to the flow. This forms the set of components R I 0 r that influence r. 4. For each r i in R I 0 r , a link is formed in the hierarchical control structure between the process node that contains r and the process node that contains r i . The link is of type 'SameLevelInputOutput'. Duplicated links are omitted.
The analysis of the algorithm reveals that its asymptotic complexity is OðP K L þ P S Þ, where P K is the number of ports that belong to controllers, L is the number of links in the logical view (which represent the worst-case for a traversal originating in one port), and P S is the number of ports that belong to non-controllers. Provided that all ports are connected, the values of P K , P S , and L might be of similar magnitude, which implies a running time that increases quadratically with respect to the number of links in the logical view. This indicates that the worst-case asymptotic complexity is OðL 2 Þ: Figure 3 shows a simple example of a hierarchical control structure that is automatically created from the logical view of the system. The control hierarchy corresponds to the wheel brake system in Figure 1. The hierarchy is composed of controllers (solutions highlighted in blue) and a process node where the rest of the solutions are lumped together. Since the controller is lower than the crew in the solution hierarchy, this node is also situated lower in the control hierarchy. The hierarchy shows how the crew controls the process both directly and via the controller, which receives feedback from the process.

Creation of detailed control loops
Creating a detailed control loop requires the identification of four sets of components: the controller j, actuators R A j , sensors R S j and process solutions R P j : Given a controller, the developed method can automatically identify the actuators, sensors and process solutions. The process consists of the following steps: 1. Traverse the logical view starting from controller j including every solution that can be reached by following flow links in the direction of the flow. This forms the set of components R I j influenced by j. 2. The set of solutions in R I j with a direct flow link from j corresponds to R A j : 3. Traverse the logical view starting from controller j including every solution that can be reached by following flow links in the opposite Crew Controller Process Figure 3. Example of a hierarchical control model.
direction to the flow. This forms the set of components R I 0 j that influence j. 4. The set of solutions in R I 0 j with a direct flow link to j corresponds to R S j : 5. Finally, use the following equation to obtain the set of process solutions jÞ The union of the four sets forms the set of components in the loop reality the analyst can also provide different values for R A j and R S j , which will override the values obtained automatically and remove components from R P j as required. After the sets are identified, the method will classify the links among the various items in the control loop according to the links in the generic control loop provided in the STPA handbook (Leveson & Thomas, 2018, pp. 44, 49). These links cover the most common loss scenarios (unsafe controller behaviour, inadequate feedback and information, issues involving the control path and scenarios related to the controlled process). The method helps to produce the information required by STPA's Step 4 Identify Loss Scenarios with little input from the architect (only the controller j).
In practice, some links do not fall under any of the categories proposed in Leveson and Thomas (2018, pp. 44, 49) such as links from other components (outside the loop) to sensors and actuators and between them. The proposed algorithm does not discard any link a priori and allows the analysts to decide which links are relevant for them. Figure 4 displays the extended generic control loop, which includes all possible kinds of links. These links are tagged with a number corresponding to the description of the links presented in Table 2. The latter contains the criteria employed for link classification and marks the additional kinds of links with an asterisk ( Ã ). A link is named using one of these two ways: (1) Destination Inputs from Origin or (2) Origin Outputs to Destination, both of which indicate that a link exists from Origin to Destination.
The analysis of the algorithm reveals that its asymptotic complexity is OðL þ SÞ, where L is the number of links and S is the number of solutions in the logical view. The first summand appears because there are two traversals that will include every link in the architecture in the worst-case scenario. The second summand appears because every solution might be involved in the set operations. Set operations are performed with the help of hash tables, which yield an average time O(1) to search for an element in a set (Cormen et al., 2009). In the case of the architectures employed in this research, where all ports are connected, the number of links is of similar magnitude to the number of ports and solutions. This brings the complexity to linear O(L). Figure 5 shows a simple example of the creation of a detailed control loop, which corresponds to the solution labelled as 'Controller'. It is created from the logical view of the wheel braking system in Figure 1. All solutions are classified according to their role in the control loop. R I j is composed of the hydraulics, the wheel, the sensor and the controller. R A j contains the hydraulics as they are the only component in R I j with a direct link from j. R I 0 j is composed of the crew, the sensor, the wheel, the hydraulics and the controller. R S j contains the sensor as it is the only component in R I 0 j with a direct link to j. R P j corresponds to the wheel. The crew, which does not belong to the loop, is included in the figure as a direct influence on the controller.

Evaluation
Reported in this section are several studies which were performed to test and evaluate the two novel methods. The section starts with a brief introduction of AirCADia Architect, a prototype tool which incorporates the software implementation of the proposed techniques. This is followed by the description of the wheel brake use case (S-18 Aircraft and Sys Dev and Safety Assessment Committee, 1996) employed to evaluate the methods. Finally, the comparison between the automated and the manual application of STPA is discussed.

Software prototype
AirCADia Architect (Guenov et al., 2020) is a research prototype tool for rapid model-based system architecting and evaluation. It has been extended for this research according to the object model proposed in Jimeno Altelarrea (2021). The new capabilities include, among others, support for the STPA hazard assessment methods presented in this paper. Additionally, AirCADia Architect allows the interactive explorations of the resulting STPA models. Once a part of the model is selected, the related parts and analysis results are highlighted.

Wheel brake system case study
The use case consists in the application of the two STPA methods to the Wheel Brake System (WBS) example proposed in the ARP 4761 (S-18 Aircraft and Sys Dev and Safety Assessment Committee, 1996). This example was employed in Leveson et al. (2014) to compare the manual application of STPA to commonly used traditional methods. To facilitate comparison with the results obtained by Leveson et al., the diagram, textual description and assumptions regarding the WBS stated in (Leveson et al., 2014, pp. 68-72) are used to populate the logical view of the architecture in AirCADia Architect. Although many STPA tools exist (see Section 1.2), none of these fully automates the creation of hierarchies and detailed control loops. Therefore, the comparison of the proposed methods with the manual approach is considered a representative comparison of the existing tools.  Figure 6 portrays the system implemented in AirCADia Architect. As shown in the diagram the system has two hydraulic channels (green and blue) capable of applying pressure on the brakes of the aircraft wheels. The hydraulic part of the system is controlled by the Brake System Control Unit (BSCU) and by the pedal's mechanical input. The controller uses the manual brake commands from the pedals as well as inputs from the rest of the aircraft such as wheel speed or auto-brake mode. Apart from outputting control commands for various hydraulic valves, it also communicates its status to the Brake System Annunciation. The annunciation informs the crew about the state of the system so they can make the necessary decision to control the WBS through manual brake (using pedals) or automatic brake commands. More details about the system can be found in the original report (Leveson et al., 2014). Some connections and components (such as the autobrake), which were only implicit in the original diagram, but provided in the system's description, have been made explicit in this implementation. This is because the tool and the methods require links to be included explicitly to work properly.

Creation of hierarchical control structures
The first part of the evaluation focuses on the method to automatically create the control hierarchies used for STPA analysis. Figure 7 shows the control hierarchy as automatically modelled by AirCADia Architect. The degree of similarity with respect to the control hierarchy obtained by Leveson et al. (2014, p. 28) is high regarding the components which are included and their position in the hierarchy. In both cases, the crew is situated at the top of the hierarchy. At an intermediate level, one can find the brake system control unit's (BSCU) controllers. Finally, the WBS hydraulics and wheel are located at the bottom of the hierarchy. It must be noted that the wheel has to be explicitly declared as a separate process node to make it appear as a separate node in AirCADia Architect. There small difference arises because the original hierarchy merges the two redundant control channels of the BSCU, whereas the automated method considers them individually. There are also differences regarding the order of controllers within the BSCU. The original report omits the autobrake from the system diagram but situates it at a higher level than the rest of the BSCU controllers in the hierarchy. The autobrake had to be explicitly included in AirCADia Architect; placing it within the BSCU at the same level seemed the most appropriate option. As a result, the autobrake appears by default at the same level as the rest of the BSCU controllers in Figure 7. The wheels and the WBS hydraulics also appear at the same level in Figure 7. If desired, AirCADia Architect allows to change the type of the links (such as the link between the autobrake and the CMDs, or between the hydraulics and the wheel) to obtain an order identical to the original hierarchy.
Unlike the original hierarchy, Figure 7 does not show the description of the signals carried by the links, to avoid cluttering. Instead, this information is presented in a more convenient tabular format in Table 3. The table presents the comparison results regarding control commands (from a higher to a lower level in the hierarchy) and same level links in the hierarchy. The results show a considerable degree of similarity as the automated method discovers most of the signals and even some additional ones.
Nevertheless, there are some differences regarding which elements are identified by the creation algorithm as process nodes (every component that is not a controller). This includes the hydraulics and wheels, as in the original hierarchy, but also the aircraft and some BSCU components such as the monitors. This fact explains why the algorithm includes an additional command from the autobrake to the process, which corresponds to the flow link between the autobrake and the 2 MONs. It also explains why 'Touchdown' and 'Rejected take-off' are not identified as command links. This is because both signals come from the process node, which is situated lower in the hierarchy, as opposed to the original hierarchy that depicts these links as downward links.
The fact that the STPA method considers the two CMD individually leads to the identification of two additional commands between CMDs ('Brake Command' and 'Anti-skid Command') not considered in the original analysis. This link between CMDs is found by traversing the hydraulics up to the wheel and coming back via the wheel speed feedback signal. The consideration of independent CMDs also leads to the double discovery of many of the command and feedback links, which has been indicated as (x2) in both Tables 3 and 4.  Table 4 presents the feedback signals in the control hierarchy (from a lower to a higher level). The explanations for discrepancies in the case of control commands are also applicable to feedback signals. All feedback signals in the original report are found by the method except the 'Wheel Speed' feedback signal from the hydraulic controller to the autobrake, which is found from the wheel to the autobrake instead. This is because the autobrake is not included in the original diagram of the architecture and neither are all of its inputs and outputs explained in the textual description of the system. Table 4 shows the two missing signals from Table 3, 'Touchdown' and 'Rejected take-off', which are identified as feedback. A few additional feedback signals are identified by the automated methods, namely 'Fault detected', 'Manual brake', 'Validity signal', and 'Electrical power'. Perhaps these links were neglected or not considered relevant for the hierarchy in the original report (Leveson et al., 2014).

Creation of detailed control loops
The second part of the STPA support evaluation focuses on the method to model automatically detailed control loops for STPA analysis. The crew was the chosen controller for the evaluation control loop, the brake pedals were identified as the actuators and the annunciation system is the 'sensor' providing feedback to the crew. The controller process is the wheel brake system, including the hydraulic controller and the hydraulics. Table 5 presents the comparison of the links obtained by both the original manual analysis (Leveson et al., 2014, p. 38) and the automated analysis by the methods proposed in this research. There is a high similarity regarding the components which belong to each part of the loop, namely the controller, actuators, sensors and controlled process. The original loop is less detailed than the one provided in this research because of two reasons. The first one is because it did not provide any description for the links starting from or ending in the WBS. The second reason is that it does not distinguish between any of the two pedals or redundancies in the WBS. Because of this lack of detail, Table 5 shows a number of links that are not included in the original analysis. These links include 'Process Inputs From Actuators', 'Process Inputs From Other Process Solutions', 'Process Outputs To Sensors', and the second link in 'Controller Outputs To Actuators'. There are, however, a few links under the category 'Controller Inputs From Other Process Solutions' that appear in the original loop, but have not been identified by the proposed algorithm. This is because these links were not included in the diagram or the textual description of the architecture in the original document (Leveson et al., 2014).

Discussion of results
The comparison shows that the presented novel methods can reproduce the results obtained by manual application of the STPA methodology by Leveson et al. (2014). In fact, the methods are able to find additional links between elements, especially in the control loop. The automated approach was able to obtain this information and present diagrams and tables with link information with no or little input from the user. For example, in the case of the hierarchy, it was only necessary to indicate that the wheel belongs to its own process node. For the control loop, the crew was selected as the controller, while the pedals were selected as the actuators and the annunciation system as the sensor. To compare the time and effort required by the manual and automated approaches, it is assumed that the process that converts the architecture into a graphical STPA model occurs in two steps. First, the architecture is analysed to determine which components to include and how to link them. Second, the elements of the graphical model (such as nodes and links) are created and drawn on screen. The second step is assumed to be the same in both cases. It is difficult to formalise the manual approach to analyse its asymptotic complexity. However, the difference regarding running time is clear. The execution time of the automated methods is in the order of milliseconds on a standard PC (including the debugger overhead), while the manual process rehearsed by the authors takes at least several minutes. This is an indication that the time difference between the manual and the automated approaches will be many orders of magnitude larger as the architecture complexity increases. If the preparation of the inputs (in this case the logical view) is too time consuming, it might offset the benefits of the automation. However, as explained in Section 2.1, it is reasonable to assume that a logical view of the system exists, as a result of the system architecting process. That is, the logical view is not created specifically for the STPA analysis. It can be used for other kinds of analysis such as sizing and performance and, therefore, the cost of creating it is spread out. Additionally, the presented methods ensure that the STPA analysis is updated at a low cost as the design advances.
Some minor discrepancies resulted from the differences between the manual and automated approaches (e.g. grouping of redundant solutions in the BSCU) and from the lack of consistency between the models presented in the original report by Leveson et al. (2014). As explained earlier in this section, the manual approach merged the redundant solutions in the BSCU in one single node in the STPA models whereas the automated method kept them separate. Although the manual approach enables additional functionality such as merging redundant components, it can also be a source of inconsistency as explained next. Considering the use case, the original diagram of the system did not include the autobrake or any of its links, but the textual description of the system did. Other links, such as the BSCU power on/off are only mentioned implicitly in the description. Furthermore, Leveson et al. (2014) included a link between the BSCU controller and the autobrake in the control hierarchy that is not present neither in the diagram nor in the description of the system. This is a good example of how the manual application can be a source of error and inconsistency, both between system definition models (textual and diagram) and between definition and STPA analysis. That is, if the STPA analysis is performed exclusively with the information from the description of the system it will not be possible to reproduce the results from Leveson et al. (2014) as the link between the BSCU controller and the autobrake is missing. Furthermore, other teams working on the system will not be aware of the existence of the link and be able to include it in their analysis. By contrast, the presented methods ensure that the architecture is updated prior to obtaining the desired safety results, as safety results only change when the architecture is changed. If another team analysed the safety or any other characteristic of the architecture, they would be aware of the extra link, as it would have been necessarily included in the architecture.

Summary and conclusions
A review of the current state-of-the-art computational support methods for the creation of STPA models identified two main limitations: a significant amount of time required to create the models manually and the difficulty of ensuring consistency with the evolving architecture definition.
To overcome these limitations, two novel methods enabling the automatic creation of STPA models are proposed. The methods use the logical view of the systems architecture as input. The graphs formed by the hierarchical and flow relations in the logical view are utilised by the methods to create both hierarchical control structures and detailed control loops. These are used during STPA to determine unsafe control actions, loss scenarios and to derive safety requirements.
The proposed methods were implemented within a prototype object-oriented software, AirCADia Architect, to be tested and evaluated. The methods were applied to a wheel brake system use case that was previously used to compare the manual application of the STPA methodology to other hazard assessment methods. The results were compared with those provided by the manual application of STPA (Leveson et al., 2014). The comparison indicates that the proposed methods produce models that are almost identical to those obtained manually. Minor discrepancies were observed due to a different grouping of redundant solutions and an inconsistent system description. It was also demonstrated that the automatic process is orders of magnitude faster and requires less manual input. The automated approach was also found to ensure better consistency among the safety analysis and the architecture definition as it requires safety features to be included in the architecture definition prior to being considered in STPA analysis. In a wider context, this is seen as a step towards a more effective design for safety (DfS) process.
Future work, especially from an industrial perspective, will focus on exploring ways for efficient validation and verification of the presented methods. Another research avenue is the seamless integration with STPA methods and tools that automate other parts of the process, such as the method to automate the generation of formal model-based safety requirements (Thomas, 2013), or traditional safety methods such as FHA to utilise existing knowledge about functional hazards.

Disclosure statement
No potential competing interest was reported by the author(s).

Data availabilty statement
Data supporting this study are included within the article.

Notes on contributors
Sergio Jimeno Altelarrea PhD, is a Research Fellow in Aircraft Systems Architecting in Cranfield University. During his PhD he developed safety methods for the conceptual design of complex systems and contributed to the development of advanced Model-based Design tools such as AirCADia.