An Ontology-Based Approach to Aid STPA Analysis

The safety-critical systems we are building today employ software, use physical and cybernetic components, and have more interactions (including hierarchical controllers). Systems-Theoretic Process Analysis (STPA) is a hazard analysis method that is used in the concept stage of the safety-critical systems life-cycle. It is claimed that STPA identifies more loss scenarios and safety recommendations when compared to traditional safety analysis methods. However, the STPA analyses are lengthy and complex, and it is common to miss some loss scenarios and safety recommendations. Few STPA-based tools allow systematic and automated analyses. We propose an ontology that represents the STPA analysis domain knowledge and we built an STPA ontology-based tool, called AppSTPA, that aids the analyst providing a more systematic, automated and guided analyses. We evaluated the STPA analyses made with AppSTPA and without the assistance of tools. We also assessed the benefits of AppSTPA when compared to an existing STPA tool. The results show that our ontology-based tool provides pertinent guidance and allows a more complete analysis. We conclude that our STPA ontology-based tool is able to support analysts and provide valuable suggestions, resulting in better safety analyses.


I. INTRODUCTION
Today's safety-critical systems are becoming more complex. They make intensive use of software [1], employ processors with increasing power, use different networks, operate with physical and cybernetic components, have more interactions (including hierarchical controls), and must follow the directives of certification bodies. They include Unmanned Aircraft System (UAS) traffic management systems, autonomous vehicles, healthcare systems, and smart city applications [2], [3].
System-Theoretic Process Analysis (STPA) is a technique for hazard analysis that assists in identifying safety recommendations and constraints by considering that unsafe interactions among system components can cause accidents.
The associate editor coordinating the review of this manuscript and approving it for publication was Dominik Strzalka .
STPA is based on the System-Theoretic Accident Model and Processes (STAMP). STAMP is an accident causality model based on systems theory. It expands the traditional model of causality beyond a chain of directly-related failure events or component failures to include more complex processes and unsafe interactions among system components. It considers all potential causal factors of losses, including software and human causal factors [4]. STPA is a method that can be used to any type of system, including social systems [5], providing a comprehensive view of complex human-system interactions that can lead to hazards [6].
In general, the STPA analysis is lengthy and complex, however, it is claimed that STPA identifies more loss scenarios and recommendations when compared to other hazard analysis techniques, such as Fault Tree Analysis (FTA) and Failure Modes and Effects Analysis (FMEA) [7]. STPA is structured into four steps. ''Step 1 -Define the Purpose of knowledge [19]. For instance, with the ontology of STPA analysis, it is possible to model the component interactions and infer possible causal factors of loss scenarios.
Our hypothesis is that ontology together with a tool can make the STPA analysis more complete by considering all the elements that affect the analysis, systematizing, generating only pertinent recommendations, and resulting in less work for the analyst. Systematization allows the analysis to be performed in a more disciplined way, while automation allows a more time-efficient analysis. The goal is then to have a smart tool that encompasses ontology and makes the STPA analysis more systematic, automatic and guided. Guidance helps the analysts with more accurate information and achieves a more detailed analysis. To achieve this objective, we propose an ontology-based approach to create a smart tool that aids the analyst to perform STPA analyses.
The text is organized as follows. Section II briefly reports the related work, highlighting the gaps concerning our work. Section III presents the proposed STPA ontology and the ontology-based tool. Section IV describes the evaluations of the approach. Section V presents some analyzes, discusses the approach, and summarizes the contributions. Section VI concludes our work and presents future work.

II. RELATED WORK
Here we describe the existing tools for STPA analysis and also present the related work regarding safety ontology.

A. STPA TOOLS
When presenting the tools, we focus on the functionalities that are specific to accomplish STPA analysis. Other characteristics, such as a user-friendly interface and storage strategy, are out of our scope.
A-STPA [20] has a graphical user interface that allows the user to define the control structure of the system under study. However, the tool does not allow the identification of loss scenarios and the analysis process is very similar to filling out a spreadsheet.
RM Studio [21] is a tool to manage risk, data, and business. It uses the STPA as part of the risk analysis. It has a graphical user interface to draw the control structure. However, the tool has a weak validation of the control structure, allowing the creation of meaningless connections between components. RM Studio does not provide guidance for defining unsafe control actions and loss scenarios.
SafetyHAT [22] divides the STPA analysis into seven steps, starting with the definition of the control structure. The platform validates some component connections, but components can have ambiguous types (e.g. a component can be an actuator and controller at the same time). The tool does not provide means to add the process model variables to the analysis.
STAMP Workbench [23] presents a three-step interface, whereas Astah System Safety [24] (the commercial version of STAMP Workbench) does not specify an order to perform the STPA analysis. Both tools allow the elaboration of the graphical control structure; however, the interface is hard to use and does not allow the definition of the component type (i.e. actuator and controller). The tools do not provide guidance to identify causal factors and loss scenarios. The analysis process is very similar to filling out a spreadsheet.
WebSTAMP [25] provides a clear definition of the STPA steps, allows the distinction of component types (i.e. actuator and controller), shows a context table for UCAs using the variables defined in the control structure, and indicates a list of causal factors for loss scenarios. However, it does not associate the variables to links (between components); it does not check what connections can be made in the control structure, and it does not deal with hierarchical controllers (multiple controllers that interact on various levels).
After comparing WebSTAMP with the other tools, we consider that WebSTAMP is the most complete tool for STPA analyses. We highlight that the listed tools do not provide guidance for conducting STPA analysis. For instance, it was expected that a tool could validate the control structure, enable the identification of hierarchical controllers, show the elements that compound an UCA, and provide insights about the pertinent loss scenarios and recommendations. To avoid the gaps from previous works, our approach uses an ontology to systematize the knowledge and create a smart tool that can perform all the STPA steps.

B. ONTOLOGY FOR SAFETY
Chen and Helal [26] present an ontology-based approach for the safety analysis of the sensor domain for Internet of Things (IoT) systems. The ontology called Domain-independent Ontology for Safety (DiOS) combines the stakeholders' knowledge (e.g. situation and risk) and the terms used by device manufacturers (e.g. pervasive space, precondition, and sensing operation). The authors employ some terms related to the STPA analysis, such as sensor, actuator, and context. The authors evaluate their proposal with a case where sensors inform their domain of operation to discover risk scenarios. Their work is specific for the safety of the IoT domains considering the sensors' feedback. Our work is an ontology to conduct the STPA analysis to any cyber-physical system.
Provenzano et al. [15] describe a heuristic approach called Safety Requirements Elicitation (SARE). SARE uses the concepts of their previous work about Hazard Ontology [16] and describes how such knowledge can guide the elicitation of safety requirements. To evaluate their proposal, the authors applied SARE to the Parking Brake system to mitigate ''Collision Hazard'' of a high-speed train. Although their ontology presents general concepts of safety (e.g. hazard, initiating condition, initiator factor, and mishap), it is not related to a technique to reason about safety concerns. Our proposal presents an ontology that represents the STPA analysis, which is based on the safety analysis process, including concepts such as hazards, goals, control structure, losses, and requirements.
Zhou et al. [16] present an ontology to aid the preliminary hazard analysis, in a way to improve the description of hazards and related causes. By defining the ''Ontological Approach to Identify the Causes of Hazards'' (OCH), the authors aim to improve the description, completeness, and usefulness of Preliminary Hazard Analysis (PHA), based on Unified Foundational Ontology (UFO). To evaluate their idea, they apply OCH to the Temporary Speed Restriction of a train control system to categorize hazards, describe hazards, and finally, identify causes of hazards. Their work uses an ontology to support hazards' identification and analysis. In our paper, we choose STPA as the safety analysis and present an ontology to guide designers when using STPA.
Pereira et al. [27] discuss an ontology-based technique to STPA-Sec [28], which is an extension of STPA to consider safety and security issues. The idea is to improve the identification of causal scenarios and associated causal factors in STPA-Sec, specifically those related to cybersecurity. The authors conduct an evaluation with a flight management system. By focusing on security threats, their work considers a limited set of STPA concepts. They do not deal with important safety concepts, such as context, safety constraint, process model, and external information. Moreover, their ontology does not represent all the STPA steps. For instance, they do not consider the ''Model the Control Structure'' step in the ontology. Our approach considers all the STPA steps, so that it is possible to provide insights to identify causal factors of hazards and safety recommendations.
Additionally, the related works concentrate on proposing an ontology and using it manually, without the support of a tool. In this article, we created an ontology for STPA analyses and developed a tool based on that ontology.

III. PROPOSED STPA ONTOLOGY AND STPA TOOL
Section III-A explains the ontology through a context view for each step of STPA. Section III-B describes the process to create a smart tool, called AppSTPA.

A. THE STPA ONTOLOGY
The proposed ontology with all relations is shown in Figure 13. The figure can be downloaded in high quality from GitHub [30]. The ontology elaboration was performed according to the four STPA steps, by performing the tasks presented in Figure 1.
The proposed ontology represents the STPA analysis [4]. We reused the knowledge of safety ontologies, for instance, some elements (e.g. hazard, mishap or loss, and causal factor) and relations (e.g. ''UCA leads to hazards'' and ''hazards leads to loss'') from related work (section II-B). Due to the combination of software and hardware components, cyber-physical systems have specific characteristics, such as controller and algorithm, that we also incorporated into the ontology. We elaborated the ontology using two tools: the web version of Diagrams.net [31] and Protégé 5.5.0 [32]. Diagrams.net aids to build the visual representation of the ontology. Protégé is a free and open-source platform that provides a suite of tools to construct domain models and track down inconsistencies. We use the reasoner HermiT for Protégé.
In Figure 1, we present the procedure, composed of tasks, to elaborate the STPA ontology. We start by identifying the elements (Task A) and relations (Task B) to define the ontology (Task C) and validate the elements of the current step (Task D) of Step 1 of STPA. The validation is conducted by comparing with the related work (section II-B), checking the STPA Handbook [4], applying to existent STPA cases (such as the Train Door system [33]), and using Protégé to evaluate the ontology.
For the next steps of STPA, we perform tasks A to D, but we merge the ontology obtained in the current step with the ontology of the previous steps (Task E) and conduct a consistency analysis (Task F). To assess consistency, we follow the same activities indicated in Task D, except that Task D considers an isolated evaluation to a given step, and Task F includes an evaluation of the new links identified in Task E. Tasks D and F are critical due to the large number of elements driven from the incremental aggregation of STPA steps.
In the proposed ontology, all the steps are correlated. The Step 1 describes the goals of the system and hazards that Step 2 (Model the Control Structure) needs to consider. Step 3 uses the control actions identified in Step 2 and relates to the hazards of Step 1.
Step 4 uses the unsafe control actions of Step 3 and relates to the elements of Step 2 to explain, in the loss scenarios, how unsafe control actions can occur. In the STPA analysis, all the steps are related and some elements impact the system in more than one way.
In an ontology, a class (or ''superclass'' or ''parent class'') can be used to represent a template for creating objects. A class can also be seen as a general category of objects. A subclass (or ''child class'') is a class that inherits all the attributes and methods of its parent class(es). For example, a ''book'' is a general category, and ''comic'' is a particular subcategory of book [18]. In our STPA ontology, we use the yellow color to represent a class and the green color to depict a subclass. Below, we detail the ontology creation by explaining the created relations, as well as the particularities of each STPA step.

1) OBJECT PROPERTIES OF STPA ONTOLOGY
The ontology concepts can have several relationships, for instance, the class Controller may have links with other classes such as Algorithm, Process model, and Link controller actuator. In what follows, we describe the relations of the STPA ontology ( Figure 13). They are used to relate the concepts in the four STPA steps. We do not use the data properties, as they were not necessary to represent the STPA analysis. The names of the ontology relations and classes are in italic.
• affects: indicates that an Environmental disturbance can produce unexpected changes in the Controlled process (CP). Domain: Environmental disturbance; Range: Controlled process (CP).
• associates with: indicates how a class is dependent on another class, for instance, a Safety Constraint is created to prevent a Hazard, and a Hazard is created to explain a Loss / Mishap. • has: identifies the concepts used by some class to compound itself, for instance, the Control structure has Controller.
• identifies: indicates that the Causal factor A and Causal factor B are part of the Safety recommendation.
• inappropriate or missing control action: describes the subclass relation to explaining how the control action is a Causal factor B. Domain: Causal factor B.
• incorrect, ineffective, or updated control algorithm: describes the subclass relation to explain how the Algorithm is a Causal factor A. Domain: Causal factor A.
• is a: describes the subclass relation, for instance, the Link CP to HLC is a subclass of Link.
• is also: expresses that a class has also the same behavior as another class, for instance, the Higher-level Controller (HLC) is also a Controller.
• is part of Lxy: describes the subclass relation to identify the components that belong to the link between components x and y of the control structure, for instance, is part of LCA is used to represent that Controller and Actuator are subclass of Link controller actuator. Domain: is part of Lxy.
• issues: identifies the control action that a Controller or Higher-level controller can issue. Range: Control action.
• leads: identifies the result a concept produces, for instance a UCA implies that the system will have a hazardous situation.
• missing or wrong input: describes the subclass relation to explain how the Input is a Causal factor B. Domain: Causal factor B.
• produces: indicates the results expected by the operations of the Controlled process (CP). Domain: Controlled process (CP); Range: Output.
• receives: identifies the data received, for instance, the Controller receives External information received from the External system.
• refines: indicates that the UCA is used to refine the Safety Constraints.
• represents: indicates that Control structure is a representation of the System.
• respects: indicates that the System must never overpass the boundary established by an Assumption. Range: Assumption.
• selects: identifies that Algorithm can issue control actions.
• sends: identifies the data sent, for instance, the Controller sends the External information sent to External system.
• unidentified disturbance: describes the subclass relation to explain how the Environmental disturbance is a Causal factor B. Domain: Causal factor B. • updates: identifies that control actions and feedback produce changes in the Process model. Range: Process model.
• uses: indicates that the Algorithm uses the Process model to make decisions. Domain: Algorithm; Range: Process model.
• wrong or missing external information: describes the subclass relation to explain how the Externalinformation received is a Causal factor A. Domain: Causal factor A.
• wrong process model: describes the subclass relation to explain how the Process model is a Causal factor A. Domain: Causal factor A.

2) STPA STEP 1: DEFINE THE PURPOSE OF THE ANALYSIS
The ontology of Step 1 is presented in Figure 2. The classes of the ontology represent the concepts used in Step 1 of STPA, which include goal, loss, hazard, safety constraint, and assumption. The relations of the ontology denote the relationships between the concepts. In Figure 2, for instance, the relation associates with indicates that a hazard (represented by the class Hazard) can lead to a loss (represented by the class Loss / Mishap).
3) STPA STEP 2: MODEL THE CONTROL STRUCTURE Figure 3 shows the ontology of Step 2. The ontology of Step 2 represents all the elements that are used to build a control structure (e.g. controller, control actions, actuators, sensors, process model variables, feedback, input, output, and external information). Generally, the controller uses an actuator to interact with the controlled process (CP) and receives its feedback through a sensor. Each interaction between components has a specific link. In STPA, it is necessary to model the link, since failure can occur in it. The ontology also denotes elements that are internal to the controller component, which include process model and variables with values.
In Figure 3, we represent four subclasses of control actions: control action from the controller to an actuator (Control action actuator), control action from the controller to the controlled process (Control action CP), control action from the higher-level controller to a controller (Control action HLC to controller), and control action of the higher-level controller to the controlled process (Control action HLC to CP).
In the STPA analysis, each controller can act as a controller or a higher-level controller. The controller is defined as a class that can send control actions to actuators or controlled process. The higher-level controller is defined as a controller that can send control actions to another controller and controlled process. There is the possibility that a controller and a higher-level controller can concurrently send control actions to the controlled process.
The External system is a component that sends information (which is neither control action nor feedback) to a controller in a way to update the controller's process model [4]. The external system is outside of the system's boundary and it is not controlled by the system. Since the information provided by the external system affects the operation of the analyzed system, we have to represent it in the ontology. Such information is represented as the class External Information Received. Also, the controller can send information to an external system, which is represented by the class External Information Sent. Sending information is considered a responsibility of the controller and its hazard analysis is not made for the current system, but for the higher-level system that contains the system. Each control action can generate different unsafe control actions, which in turn have different causal factors and loss scenarios. For the feedback, we identify two subclasses in Figure 3. The first is the feedback from the controlled process (Feedback of CP) and the second one is the feedback from the controller (Feedback of controller). The feedback from the controlled process can flow through the sensor (and later to a controller) or flow directly to a controller. The feedback from the controller is the feedback that a controller sends to a higher-level controller.
We represent the links between the control structure components as classes in the ontology. Since the links between components are unidirectional, we name the classes representing the links using the pattern ''Link + element source + element destiny''. We identify four types of link: • Link for control actions: link used to represent a flow of control action issued by a controller or higher-level controller. They are the following: Link controller actuator, Link controller CP, Link HLC controller, and Link HLC to CP.
• Link for feedback: link used to represent a flow of feedback from a sensor or controlled process to a controller. In addition, it can also be used to send feedback from the controller to a higher-level controller. They are the following: Link CP controller, Link sensor controller, Link CP to HLC, Link sensor HLC, and Link controller HLC.
• Link for information: link used by a controller to send/receive information to/from an external system. They are the following: Link Controller External-system and Link External-system Controller.
• Link for energy: represented by Link actuator CP and Link CP sensor. For instance, the actuator uses mechanical force to interact with the controlled process, and the VOLUME 11, 2023 presence sensor detects thermal radiation and converts it into an electrical sign. This type of interaction is mainly physical (electrical or mechanical interactions) and does not involve information flow (e.g. control actions or feedback).

4) STPA STEP 3: IDENTIFY UNSAFE CONTROL ACTION (UCA)
An UCA is a control action that in a particular context will lead the system to a hazard, and consequently to losses. We highlight that a loss scenario leads to an UCA, and we use the UCA to identify all the potential scenarios. In addition, UCAs help to refine the safety constraints. Figure 4 shows the ontology for Step 3. Context, represented by the class Context in Figure 4, is defined as a set of all variables with their respective values that describes the system condition to issue a control action. The classes Variable and Value were defined in the ontology for Step 2 (see Figure 3). Control actions are those provided by controllers and higher-level controllers (i.e. control action to the actuator, controlled process, or another controller) and are used to define UCAs [4].
In Step 3, the analyst must analyze each context and each control action according to the type of issuance, represented by the class CA issuance type, and categorize the control action as hazardous or not hazardous. The types of issuance of control action are represented by the classes Provided, Not provided, Too early, Too late, Out of order, Applied too long, and Stopped too soon.
The classes of Step 3 (Context, CA Issuance type, and UCA), classes of Step 1 (Hazard and Safety constraint), and classes of Step 2 (Control action, Variable, and Value) are used to define an unsafe control action, represented by the class UCA. UCA is then associated to safety constraint, represented by the class Safety Constraint.

5) STPA STEP 4: IDENTIFY LOSS SCENARIOS
Loss scenarios have causal factors and lead to an UCA, in addition, the UCAs can also be used to identify the loss scenarios. The identification of loss scenarios uses the UCA and causal factor to produce the list of safety recommendations. In addition, the analyst can also provide a rationale for each recommendation. To identify loss scenarios, the analyst looks for causal factors that are located in two regions of the control structure (see Figure 5). Side A refers to the right side of the control structure, and Side B refers to the left side of the control structure.
Step 4 identifies the causal factors and the recommendations. It uses the elements that compound the control structure (obtained in Step 2) and considers UCAs identified in Step 3. As result, it identifies loss scenarios, causal factors, and safety recommendations. The ontology for the Step 4 to identify the loss scenarios is shown in Figure 6.
In what follows, we describe some classes of the ontology. Loss scenario A explains why the UCA would occur. The class Causal factor A represents the loss scenario A, which leads to a UCA. It explains how each element interaction may be a causal factor that leads to the UCA being analyzed. Causal factor A can be a flawed algorithm (class Algorithm), a wrong process model (class Process model), the lack of external information (class External information received), problems related to the feedback of the controlled process (class Feedback of CP), problems related to the feedback of controller (class Feedback of controller) to a higher-level controller (class Higher-level controller (HLC)), problems related to the feedback of the sensor (class Sensor), and failure of the controller (class Controller).
Loss scenario B explains why control actions are performed incorrectly. The class Causal factor B represents the loss scenario B, which leads to a UCA. Causal factor B can be problems with actuator (class Actuator), problems with control actions issued by the controller (classes Control action actuator and Control action CP), problems with control actions issued by HLC (classes Control action HLC to controller and Control action HLC to CP), unidentified environmental disturbance (class Environmental disturbance), and wrong input (class Input) to the controlled process.

B. AppSTPA: THE STPA TOOL
We developed the tool by using Python 3.9 (as programming language), the lib Owlready2 0.26 (a module developed for ontology-oriented programming), the HermiT reasoner (publicly-available OWL reasoner to determine if   the ontology is consistent and identify subsumption relationships between classes) [29] and SQLite (as database application). We call the tool as AppSTPA, and it can be downloaded from GitHub [30] under GPL license. Figure 7 presents the interface of Step 1 (Define the Purpose of the Analysis).
To design the AppSTPA tool, we use the proposed ontology model ( Figure 13) to acquire knowledge, make inferences, and save the data. The smart tool combines ontologies, a database to store the data, and a desktop interface with a precise flow to conduct the safety analysis based on STPA. The tool uses explicit knowledge and the logic of ontology. VOLUME 11, 2023 Explicit knowledge is the graphical representation ( Figure 13), which contains the elements and their relations. For example, we use the word leads to represent a dependency relation.
Step 1 of STPA includes goals, assumptions, hazards, losses, and safety constraints. For instance, there is a relation between the class Hazard and the class Loss, because hazard leads to one or more losses, so the tool interface of Step 1 must provide a way to bind hazards to losses. In Step 3, the class UCA has a relation with the class Hazard, because a UCA leads to one of the identified hazards, so the tool interface of Step 3 must implement a way to connect UCAs to hazards. We use this knowledge in all the STPA steps to create interfaces that guide the analyst.
The logic of ontology is related to the inferences that can be made using the reasoner. The reasoner rearranges, infers, and classifies all the classes according to the ontology's relations and shows the subclass knowledge. When using the reasoner, the analyst can see which elements are present in a link (e.g. the link Link Controller Actuator has the Controller, Actuator, and the Control action to the actuator) and understand how an element is related to causal factor and loss scenario (e.g. the Actuator is a Causal factor B that belongs to Loss scenarios B-side). The ontology's logic is used in Step 2 to identify the possible links for each component and in Step 4 to suggest the possible loss scenarios. For Step 2, AppSTPA is able to read the inferred ontology and discover which entities (representing the controller, actuator, sensor, and others) are part of a link (e.g. the Link Controller Actuator). To read the entities, AppSTPA has a dictionary of words that it looks at the ontology that represents the controller, actuator, and so on. For Step 4, AppSTPA is able to read the object properties, which is used to create the loss scenarios containing the causal factor and recommendation according to the words that compound the object property. AppSTPA has several triggers to provide the loss scenario according to the words of object properties of each causal factor. For this work, AppSTPA only reads the ontology.
Step 1 (Figure 7) is to define goals, losses, hazards, assumptions, and safety constraints. We assume that the analyst is capable to express this information about the system, so we do not provide any assistance here since such knowledge is fluid and difficult to structure.
Step 2 uses the logic of ontology to verify what connections can be made by the control structure components to prevent mistakes and wrong connections. Furthermore, it identifies the type of link for the components. Figure 8 presents a generic control structure with the sensor (representing an element Sensor), actuator (representing an element Actuator), controller (representing an element Controller), higher-level controller (representing an element HLC), and so on. Figure 8 (a) is the ontology model that has the possible connections for each element, in this case, we highlight the Sensor connections. As the Sensor is represented on the ontology having only two outgoing connections (Link sensor controller and Link sensor HLC), it reflects that the sensor in Figure 8 (b) can connect only with components that are the type Controller (represented by ''controller A'' and ''controller B'') or HLC (represented by ''higher-level controller'').
Step 3 is to identify the Unsafe Control Actions (Figure 9). For this, we use the information about hazards from Step 1, the information about the control structure from Step 2, the CA issuance type, and the context, in order to identify if a control action is unsafe. We define the context as a combination of variables and values of the process model. In this step, AppSTPA presents the context table [34], which is a combination of all possible variable values that compound the process model of a controller. The analyst must verify each context to identify if it is hazardous or create rules (i.e. expressions to represent one or more variable values) that defines hazardous contexts.
In Step 4, the potential causal factors list is created based on the ontology inferences and object properties for each element. For example, the Sensor can be a potential Causal factor A (or right side) if it causes problems such as delay, provision of wrong feedback, missing provision of feedback, and sensor failure. To provide a recommendation, AppSTPA has a model of a safety recommendation for each keyword of the object properties and modifies this recommendation according to the links present on the ontology and the links established in Step 2. For instance, each sensor problem can generate one or more causal factor(s) and recommendation(s), and each loss scenario is composed of a causal factor, a recommendation, and a UCA. It means that the same causal factor can have different recommendations, and the analyst must select the pertinent recommendations. Figure 10 shows an example of causal factor for Sensor. AppSTPA uses the object properties (for instance, delayed_wrong_missing_feedback_failure some Causal_factor_A) to generate the list of causal factors to infer loss scenarios. For Step 4, AppSTPA uses the ontology to find the causal factors for each relation of each UCA (ideally, the analyst must have identified all the UCAs in Step 3). The analyst starts by UCA to identify the causal factor and generate recommendations. AppSTPA presents the causal factor together with a loss scenario description and a recommendation. It is also possible to select a causal factor and specify a customized causal factor and recommendation. In addition, the analyst can customize the causal factor for each loss scenario to best suit the analysis. AppSTPA provides a report that shows the full result of the STPA analysis, and the analyst can export the report to a PDF file. Moreover, the reasoner identifies inconsistencies among the connections, properties, names, and others.

IV. EVALUATION
We conducted an inspection of the ontology and two experiments in order to identify whether AppSTPA is able to support the STPA analysis. We consider quantitative aspects by reasoning about changes in the number of identified UCAs and safety recommendations. Besides, we present qualitative  aspects of the evaluations, based on the feedback of participants when using AppSTPA. The main goal is to assess if AppSTPA can properly reproduce the STPA analysis, being a suitable way to guide the process and to support the identification of meaningful UCAs and safety recommendations.

A. STPA ONTOLOGY KNOWLEDGE
The proposed ontology has several concepts and relations to provide the STPA analysis knowledge, and one way to evaluate our ontology is to use the competence questions to verify if the ontology is able to provide the needed knowledge [35]. We consider that the ontology needs to answer two questions: (i) which components are part of a link, and (ii) which components may generate a causal factor. Figure 11 presents the SPARQL query algorithm result to identify the elements that belongs to the Link controller actuator, being an example to answer the question (i). Figure 12 shows the SPARQL query algorithm result to indicate the elements that can be the Causal factor A, being an example to address the question (ii). Changing the name of the link in question (i), we can use it to evaluate the elements of each link. Changing question (ii) to search for Causal factor B, instead of Causal factor A, we can find the causal factors of B side. In all cases, the SPARQL query provided the right answer.
Comparing the results of the first question with the elements that compound a link between the actuator and controller ( Figure 3) and comparing the causal factors A (Figure 6), we obtain the expected response, and we can infer that the ontology completeness is verified. With the answers to the competence questions, AppSTPA can provide the Control Structure validation (Step 2) and the identification of the causal factors (Step 4). Additionally, having this information is possible to limit the search to identify the causal factors (A or B) for each component present in the link, and leave to VOLUME 11, 2023   AppSTPA to read the relations (object properties) to format each causal factor and recommendation.

B. EXPERIMENT WITH AppSTPA
For the experiment, two participants performed the STPA analyses. This is an initial assessment of AppSTPA, however, it can reveal important characteristics of our tool and provides a suitable basis for further evaluations. We are aware that the result may be affected by analysts with different levels of competence in STPA. In this experiment, we chose participants who had the same knowledge and experience with STPA. The participants were Ph.D. students and had no knowledge of AppSTPA. Both received the same training about AppSTPA. Our goal was to compare the analyses made without AppSTPA and with AppSTPA, in a way to identify if AppSTPA affects positively the analysis results. In Step 1, we verified the number of goals, losses, hazards and safety constraints. In Step 2, we verified the control structure components, links, control actions and feedback. In Step 3, we counted the number of the identified UCAs. In Step 4, we counted the number of the identified recommendations.
In this experiment, participants accomplished the STPA analysis without using any tool and then they redid the analysis using AppSTPA. By comparing the analyses made by each participant, we were able to identify differences by focusing on the quantity of identified UCAs and safety recommendations. In addition, we assessed the participants' perceptions regarding the use of AppSTPA. We allowed the participants to choose a system of their interest for the safety analysis.
The first participant worked with the Landing Gear system (LDG), which is responsible to the retraction and extension of the aircraft's landing gear. The system aims to ensure that the landing gear is fully extended during the landing phase and fully retracted during the flight phase. LDG coordinates the landing gear actions with the door system, ensuring that the wheel door is opened before the landing gear extension and closed after the landing gear retraction.
Considering the analysis without AppSTPA and with AppSTPA, we identified that the results of Step 1 remained unchanged. For Step 2, the results show that the analyst removed one feedback connection of the control structure. In Step 3, the participant highlighted that AppSTPA helped when he made changes to UCAs and recommendations by presenting warnings as consequence of the changes. For instance, if a value of a variable of the context table is deleted, AppSTPA showed warnings related to the rules that use such variable and value. The participant commented that the context table in AppSTPA aided to understand the process model of the controlled process, to identify the impact of each rule, and to refine the UCAs. As shown in Table 1, AppSTPA supported the participant to understand that 8 UCAs from the analysis without AppSTPA had inconsistent contexts, which in turn made him to remove 4 UCAs and to update 4 UCAs. Moreover, he was able to identity 10 new UCAs. Appendix B shows all the UCA results in the analyses without AppSTPA and with AppSTPA.
As an example of an update, we highlight the UCA ''LDG Extension provides control action at the approach phase when the insufficient time to extend before landing'' was updated to the UCA ''Landing Gear Control Unit (LGCU) provided too late 'Extend Landing Gear' when Landing Gear Position is Down''. The first UCA does not specify a context that represents a hazard, while the second one presents a defined context that delimits the problem to be investigated. According to the analyst, constructing UCAs based on the context is more intuitive and prevent errors. We argue that this improvement is a consequence of the UCA generation strategy in AppSTPA, since the tool requires that the analyst must specify a context. With AppSTPA, the analyst was able to analyze the interactions that involve human controllers, such as the pilot. For instance, for the UCA ''Pilot (Human Controller) provided too late 'Gear Up' when Feedback on pilots display is UP, Warning is LDG gear lever disag'', a human pilot can have several reasons that can lead an airplane to a hazard situation (e.g. suddenly feeling sick or not respecting the protocols), but AppSTPA restricts the possibilities of reasons considering only the options of the context being analyzed.
The analysis without AppSTPA found 17 safety recommendations and, with AppSTPA, the number increased to 28. Comparing the list of recommendations, we identified that the participant removed 9 from the analysis without AppSTPA and added 20 new recommendations due to the suggestions made by AppSTPA. As an example of changes in safety recommendations, the analyst removed the recommendation ''The LGCU implementation information must be updated accordingly to the altitude'', as an attempt to specify the data to update the process model. The participant added

the recommendation ''Process model in the Landing Gear Control Unit (LGCU) must be consistent with the Physical Landing Gear and external system status''.
The participant commented that the AppSTPA's hints presented by using the ontology (in Step 2 and Step 4) were intuitive, helping to refine the analysis in Step 3 and Step 4. In Step 2, the ontology helped the participant to validate the control structure links, which gives more confidence in the analysis process. In Step 3, the support of AppSTPA in providing contexts aids to identify UCAs, making it easier to investigate the interactions between components that might be unsafe. In Step 4, as AppSTPA only shows the possible pertinent causal factors, it left more time to participant to understand complex scenarios and decide which one must be considered. The results of the number of recommendations are presented in Table 2, the AppSTPA analysis resulted in the removal of 9 recommendations and the addition of 20 new recommendations. Table 3 presents a comparison of the recommendations that resulted from the analysis without AppSTPA and with the support of AppSTPA. Analyzing the excerpt shown in Table 3, it is possible to note that the AppSTPA recommendations became more objective.
The second participant performed the STPA analyses of the drone CAS system, which is responsible for collision avoidance with other drones. CAS aims to keep a safe distance from other drones by providing an evasive maneuver, if necessary. CAS can eventually order the drone to return to the origin site or to go to a predefined site, depending on the maneuver.
Comparing the analysis without AppSTPA and the analysis with AppSTPA, we identified no changes in Step 1. In Step 2, the analyst removed one feedback connection of the control structure. The participant reported that AppSTPA provided a different view of the STPA analysis (mainly for the Step 3), aiding to understand the whole process, and how to proceed with the analysis. The participant considered that the support to define UCAs in AppSTPA is a helpful feature, providing a systematization of the analysis. The analyst reported that the scheme of rules' creation supported him to reason about the high number of UCAs, and to reduce the UCAs' list by creating UCAs that better specify a context. For instance, it is possible to create a rule when a variable has a specific value, which makes any context with this variable and value as a hazardous context. The analysis without AppSTPA resulted in 12 UCAs, and the analysis using AppSPTA generated 23 UCAs, as detailed in Table 4. Appendix C shows all the UCAs of the analyses without AppSTPA and with AppSTPA.
As an example of new UCA in the CAS analysis, we highlight the UCA ''Drone Collision Avoidance Controller provided in wrong order 'return to planned route' in any context'', which means that the drone should provide the return to the planned route only after ensuring that it is safe to provide this action, for instance, making sure that it does not have an object on the way or at risk of collision with another drone.
Another example of new UCA is ''Drone Collision Avoidance Controller applied too long 'avoidance maneuver' in any context''. If the drone takes a long time to make an evasive maneuver, it can make the drone go out of route or put it at risk of colliding with an object or another drone. The UCAs emphasize the importance the Collision Avoidance System to have the right algorithm and the proper performance to execute the tasks.
In Step 4, AppSTPA helped the participant to consider the links of the control structure (created in Step 2) that have a direct relation with the selected UCA (created in Step 3), and uses the object properties (from the ontology) to infer the causal factors and recommendations. As shown in Table 5, the analysis without AppSTPA resulted in 24 recommendation and the analysis with AppSTPA resulted in 28 new recommendations. Table 6 presents a comparison of some recommendations that resulted from the analysis without AppSTPA and the similar recommendations that resulted from analysis with the support of AppSTPA. Such excerpt demonstrates a more objective definition in the AppSTPA recommendations.
As examples of new recommendations, we highlight ''Communication between Drone Collision Avoidance Controller and Camera must be improved'' and ''Alternative sensor to read the Controlled Drone should be considered''. These recommendations address the need of reliable and redundant components. Furthermore, the analyst informed that the interface and usability of AppSTPA are strong features in Step 3 and Step 4.
Our experiment showed that the analysts found more UCAs and safety recommendations when they used  AppSTPA. The success of AppSTPA has three main reasons. First, all the interfaces of AppSTPA respect the ontology elements, so only the elements listed on the STPA ontology are present on the AppSTPA interface. Moreover, using the ontology to identify the relations between elements, AppSTPA allows analysts to define different roles, for instance, a sensor be part of a link and also be a causal factor. Finally, the ontology supports the reasoning about STPA, aiding the analysts to identify what is important to the system under study by providing only the possible suggestions (for example, the distinct types of safety recommendations).

C. COMPARISON BETWEEN AppSTPA AND WebSTAMP
We compared the use of AppSTPA with the use of WebSTAMP [25]. For this evaluation, two participants considered the results of a partial STPA analysis of the Insulin Pump system, which was made without using any STPA tool. The partial analysis consists of Steps 1, 2, and 3 of STPA.
Step 4 was intentionally not shared, so participants were asked to accomplish Step 4 with their tools. Since the tools use a similar way to support UCAs' identification, the goal is to understand how the tools can aid in defining pertinent recommendations for the identified UCAs. Both participants have good knowledge and experience in using STPA, having more than a year of working with STPA. The participants were instructed to accomplish the analysis using the tool suggestions. We emphasized that the objective was to compare the features provided by the tools and to understand how they can support the analyst to accomplish analyses. Here we present a quantitative analysis considering the identified UCAs (Step 3) and identified causal factors and recommendations (Step 4). We also discuss about a qualitative analysis comparing the tool functionalities to understand how it may have impacted the analyses. The Insulin Pump system is composed of a patient, a smartphone, and an insulin pump with a glucose sensor. It is a hierarchical control system, since the patient controls the smartphone, and the smartphone controls the insulin pump controller, which controls the pump. Through the Bluetooth connection, the smartphone receives information from the insulin pump controller and glucose sensor, processes data, and issues command to the insulin pump controller. In addition, the smartphone can contact the medical service in an emergency case, and receive a response from the medical service. The smartphone application is downloaded and updated by a virtual store and it is responsible for storing the information. The insulin pump is placed in the patient's belly, and the glucose sensor is placed in the patient's arm. The glucose is measured at five-minute intervals.
The results obtained in Step 1 for both participants had no differences. In Step 2, as WebSTAMP does not consider external systems, the participant (using WebSTAMP) was unable to represent the medical service. AppSTPA does not have the above limitation, so the analyst (using AppSTPA) was able to depict the full control structure model. The medical service is an external system, i.e. it does not belong to the Insulin Pump system. The smartphone communicates with the medical service in an emergency situation and requests help from the medical center. We consider that the smartphone can communicate in an autonomous way, since the patient may be unconscious. In our experiment, we take into account the link (interaction) between the smartphone and the medical service. We are not interested in analyzing the medical service. If the patient becomes unconscious, the smartphone requests an ambulance from the medical service. In this situation, we consider the responsibility of the smartphone sending a request message; however, there is no guideline in the STPA analysis about how to analyze this type of interaction.
In Step 3, the participants obtained the same results and numbers of UCAs. It was expected, because AppSTPA and WebSTAMP use a similar approach to identify the UCA. In Step 3, some UCAs from the analysis without any tool had the OR Boolean operator between context clauses in a rule expression. Both tools do not deal with the OR Boolean operator, so the 22 UCAs increased to 27 UCAs. The exclusion of the OR Boolean operator was purposely adopted in AppSTPA to make rules simple to understand by analysts. The results of analyses are shown in Table 7.
In Step 4, the participants worked with two UCAs and they had to identify the loss scenarios and safety recommendations. The UCAs were ''Insulin pump controller does not provide 'stop pumping' when remaining insulin to pump is zero'' (UCA-1) and ''Smartphone does not provide 'pump basal' when basal-is-needed is yes'' (UCA-2). UCA-1 can lead the patient to a hazardous situation given the glucose  level is going down (hypoglycemia). The UCA-2 can lead to a hyperglycemia situation (when the glucose level is going up).
Although AppSTPA and WebSTAMP provide a way to create customized causal factors and recommendations, we asked participants to identify recommendations from the standard suggestions provided by the tools. The aim was to understand if the suggestions made by the tools are, in fact, useful. The participant with WebSTAMP found 10 safety recommendations and the participant with AppSTPA identified 16 ( Table 7). The results of identified causal factors and selected safety recommendations of the two UCAs, are presented in Tables 8 and 9. The elements, mentioned in the tables, include for instance sensors, links, and actuators. Examples of causal factors related to elements are sensor delay, sensor failure, missing feedback.
For the UCA-1 (Table 8), the causal factors selected with WebSTAMP are related to component failures and control actions improperly executed. While the causal factors selected with AppSTPA are related to component failures, control actions improperly executed, inadequate algorithm, wrong process model, and controlled process.
For the UCA-2 (Table 9), the causal factors selected with WebSTAMP are related to the wrong process model, inadequate algorithm, feedback of sensor, component failures, and control actions problems. While the causal factors selected with AppSTPA are related to the wrong process model, inadequate algorithm, feedback of sensor, feedback of controller (to a higher-level controller), component failures, and control actions problems.
An example of recommendation suggestion made by AppSTPA that is not made by WebSTAMP is ''The process model of smartphone must be consistent with the process model of Insulin Pump Controller to avoid conflicting control actions''. This is a recommendation for the interaction between higher-level controller and controller, which is not supported by WebSTAMP. This recommendation is necessary since the variable Remaining insulin to pump in the Smartphone's process model may be greater than zero, and the variable Remaining insulin to pump in Insulin Pump Controller's process model may be equal to zero, due to the delay in transmitting the feedback from Insulin Pump Controller to Smartphone. The analyst must employ mechanisms that increase the communication or improve the algorithm, preventing this inconsistency.
An example of a recommendation suggestion from WebSTAMP is ''Problems in the process model and/or control algorithms''. As WebSTAMP always presents the same generic list for causal factors, we consider that this approach can induce the analyst to identify too general recommendations, which may require further refinement. According to Tables 8 and 9, the results show that AppSTPA provides more safety recommendations (considering both sides of the control structure). Additionally, all the recommendations identified with WebSTAMP were identified with AppSTPA, but the opposite is not true. Due to the different number of causal factors and safety recommendations, we conducted an analysis of functionalities that supports the STPA analysis with WebSTAMP and AppSTPA. AppSTPA and WebSTAMP have similar interfaces and functionalities, covering all the STPA steps, but only AppSTPA uses ontology. The distinctions found are described as follows.
• Component link. WebSTAMP does not verify the control structure, which allows the creation of wrong links between the control structure components. For instance, sensors could be connected to an actuator, which is not a possible relation in control structures.
• Variable and link. WebSTAMP allows adding the process model's variables to the controller and controlled process. AppSTPA permits to add variables only in the controller and ties the variable with an incoming link, making possible to trace variables and to use the ontology to make inferences.
• Control action and link. AppSTPA allows the creation of a control action to a controller and ties the control action to an outgoing link of the controller. This feature supports to trace the control action to the actuator or controlled process and use the ontology to make inferences.
• Input, output, environmental disturbances, and external system. WebSTAMP does not consider to add this information to the control structure, but adds the external information as a causal factor in Step 4. AppSTPA supports all the aforementioned elements to be added to the control structure, and they are used to generate the causal factors to the loss scenarios. • Higher-level controller (HLC). The HLC can send control actions to another controller and controlled process, and receives feedback. WebSTAMP does not consider the HLC, which is a limitation that AppSTPA addresses. A positive aspect of WebSTAMP is its Web-based collaborative feature that allows several users to access the same analysis concurrently. As the ontology reasoner may consume the processor, we choose a desktop version to keep the performance in AppSTPA. The main advantage of AppSTPA is its ontology-based feature that allows reasoning and provides more guidance to the analyst.

V. ANALYSES, DISCUSSIONS, CONTRIBUTIONS, AND LIMITATIONS
This section presents some analyzes, discusses the approach, summarizes the contributions, and describes the limitations of the research.

A. ANALYSES AND DISCUSSIONS
The results of the conducted evaluations show that AppSTPA supported the participants by providing guidance for both correct suggestions of possible alternatives and avoidance of wrong or non-pertinent alternatives. These features make the analysts not waste time. We did not find differences in the results of Step 1 and the participants did not provide any feedback about this step. The comments were made related to Steps 2, 3, and 4.
The STPA analysis is strongly related to the completeness and consistency of the control structure, and Step 2 of STPA has a significant impact on the analysis. Even though AppSTPA provides verification of the control structure, the participants commented that they resorted to using a graphical editor to model and show the control structure. The graphical editor assisted them to visualize the control structure and verify the completeness and consistency of the diagram.
In Step 3, the participants (from the experiment of section IV-B) mentioned that the strategy to identify the unsafe interactions and the context table helped them to identify and refine the UCAs. In addition, the possibility to specify a context as non-hazardous (an exclusive functionality of AppSTPA) helped to simplify the analysis.
In Step 4, the list of the options of causal factors and recommendations, limited by the ontology inference and control structure links, helped the participant to find more efficiently the pertinent causal factors. AppSTPA combines the ontology knowledge about the causal factors (through the object properties) and control structure connections (created in the current analysis) to create only the possible recommendations and leaves it to the analyst to decide about them.
The ontology model provides concepts and relations that ease the design of AppSTPA. The ontology enabled the developers to consider the intricacies to design the functionalities of a complex safety analysis tool (e.g the concepts of each step that the software must represent and how they relate to each other), including the software logic and expected outputs (e.g. explains how each component can be a causal factor). The use of ontology during the tool development resulted in a more trustable tool with fewer development errors. The ontology model is a contribution. In addition, AppSTPA also provides a graphical representation of the ontology, and occasionally, the participants resorted to the descriptions in the ontology to better understand the STPA steps.
The ontology, as it is, is not complete and can be improved. For instance, the proposed ontology does not help how to identify hazards and losses. We assume that the analysts are capable of performing those tasks before using AppSTPA. We consider these shortcomings as opportunities for future works.
STPA can be used in several areas (e.g. aerospace, transportation, healthcare, and others). As we model the ontology to represent the STPA analysis knowledge, we do not expect limitations for the ontology and for the areas in which STPA is used because the concepts involved (losses, hazards, unsafe control actions, loss scenarios, and safety recommendations) are general. The knowledge and information obtained with STPA are then used to perform the design of the system being analyzed. In the design, other models, such as architecture and SysML diagrams, are obtained. In the design phase, more detailed information such as thresholds are then specified.
Ontologies also allow formalizing heterogeneous domain knowledge [36], for instance, it is possible to create an ontology to formalize the safety knowledge for distinct analysis methods, such as Failure Modes and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and Hazop. Since each safety analysis requires specific modeling to formalize its knowledge, we consider it as an extension and opportunity for future work.
An important feature of ontology is that it is verifiable. Experts can verify if the proposed ontology contains all the relations, properties, formal names, categories, classifications, definitions, and how its elements relate among them in the domain of the STPA analysis. Since AppSTPA employs the STPA ontology, it is possible to verify if the tool respects STPA, for instance, if the tool considers all the STPA elements and their relations. This property gives confidence in using AppSTPA.
The development of today's critical cyber-physical systems needs systems theory-based approaches, such as STPA, to identify recommendations and requirements and they need systematic techniques that can be employed in tools. We showed that even for small systems it is easy to miss some UCAs, loss scenarios, causal factors, and recommendations. We also demonstrated that the ontology-based approach is a more trustable alternative to improve how to address this problem.

B. WORK CONTRIBUTIONS
There are two main contributions of this work: the STPA ontology and the AppSTPA tool. The proposed ontology is the first ontology that represents the complete STPA analysis knowledge. The ontology includes all concepts of the STPA method and their relations. The concepts include losses, hazards, control structure (and its elements), hazardous control actions, causal factors, and recommendations. The ontology considers the complete control structure, including controllers, process model variables, links between controllers and higher-level controllers, and links between controllers and external systems. The ontology also includes the controlled process, its inputs, its outputs, and environmental disturbances The relations are specified to allow inferences.
We present the AppSTPA tool that uses ontology knowledge to aid the analyst to conduct the STPA analyses. AppSTPA guides the analyst to model the system's control structure. Using the knowledge of the control structure, AppSTPA permits to identify hazardous contexts of every control action in a automated way using rules. The tool allows to find the causal factors and recommendations for each hazardous control action in a more systematic way, resulting into reduction of the workload and more guidance to analysts, and generating more complete results.

C. WORK LIMITATIONS
To evaluate our approach, we conducted experiments with users; however no statistical validation was performed since few participants were involved. Two participants performed the use cases of Landing Gear system and Collision Avoidance system and two participants performed comparative use cases of the Insulin Pump system. In the comparison, the WebSTAMP and AppSTPA tools were used. However, we acknowledge that experiments using statistical validation are required. VOLUME 11, 2023 In order to have an idea of the quality of results, we checked the recommendations generated by the tools with the recommendations of the report of Journal of Diabetes Science and Technology [37]. The report was elaborated by physicians, nurses, diabetes educators, and engineers. They discussed the safety features of insulin pump therapy and recommended adjustments to enhance overall safety. Six aspects of insulin pump technology were noted to present potential safety problems: software, wireless communication, hardware, alarms, human factors, and bolus-dose calculation. AppSTPA and WebSTAMP enable to address recommendations for the 6 aspects. The difference is that AppSTPA enabled to identify more recommendations than WebSTAMP.
As a limitation, we point out that the user must understand the STPA analysis and know how to use the tool. We think that understanding the STPA analysis is critical since it can take a long time for the user to understand the STPA analysis to be able to use AppSTPA, which is also a limitation for the tool adoption given that the use of the tool requires STPA analysis knowledge.

VI. CONCLUSION
This work proposes an ontology-based approach that supports the process of conducting the STPA analysis through a smart tool called AppSTPA. We evaluated AppSTPA with analyses using different systems and also compared AppSTPA with WebSTAMP.
We highlight two main contributions of this proposal. The first contribution is the ontology that represents the knowledge of STPA analysis, resulting in an ontology with several concepts. We understand that this knowledge is useful, since STPA is considered a rather complex method. The second contribution is the ontology-based tool provides useful guidance. The ontology provides the knowledge of the STPA analysis that AppSTPA uses to guide the analyst and produce consistent recommendations and more complete analysis. AppSTPA suggests only the pertinent recommendations, which saves time for the analyst and reduces the possibility of errors.
As critical cyber-physical systems become more elaborated, the analyses tend to be more extensive. They encompass various components of diverse types (i.e. software, human, hardware, and organizations) that are linked using different types of connections or networks. AppSTPA provides more appropriated guidance to analysts and enables more solid STPA analyses for complex systems. Based on the results obtained from the evaluations, we argue that the STPA analyses of complex systems require the application of smart tools that systematize and automate the analyses and guide the analysts. The STPA analysis process is complex and requires tools that are able to capture this complexity. We showed that is possible to improve the analysis results using an STPA ontology-based tool.
There are six suggestions for future work. The first work is to extend the proposed ontology to help in the identification of hazards and losses. The second work is to extend the proposed ontology to consider cybersecurity threats, using a threat model (e.g. STRIDE). The third is to create ontologies that consider the knowledge of different safety analysis methods, such as FTA, FMEA, and Hazop, and integrate the ontologies. The fourth suggestion is to augment the ontology model to analyze conflicts and reinforcements between constraints derived from requirements, and also between the mechanisms (e.g. hardware, software, protocol, and others) identified to meet the safety requirements. The fifth work is to conduct a usability test to understand the strong and weak points of the AppSTPA usability. The sixth is to conduct a study to store in the ontology (using the data properties) the information about the performed STPA analyses (e.g. the safe distance between drones and critical glucose levels), in a way to understand how this knowledge can be used in other STPA analyses. Figure 13 shows the proposed STPA ontology.

APPENDIX B LDG UNSAFE CONTROL ACTIONS
This section presents the hazards and the list of Unsafe Control Actions (UCAs) for the analysis without AppSTPA of the Landing Gear system (LDG). The hazards are:  • H-1: LDG Extension primary components (electrohydraulic) are not able to extend for landing during the approach phase.  • H-2: LDG Retraction components are not able to retract during the climbing phase.
• H-3: LDG feedback mechanism does not appear to pilot's monitor at a suitable time for emergence reactions.
• H-4: LDG Extension is unable to perform free fall extension. Table 10 presents the UCAs identified in the analysis without AppSTPA of LDG. Table 11 presents the UCAs converted from the analysis without a tool to the analysis using AppSTPA for LDG. Table 12 presents the additional UCAs identified  using AppSTPA for LDG. The UCAs 2, 8, 14 and 20 from  Table 10 were removed. The UCAS 5, 11, 17 and 23 from  Table 10 were respectively updated to UCAs 4, 9, 14 and 19 of Table 11.

APPENDIX C CAS UNSAFE CONTROL ACTIONS
This section presents the hazards and the list of Unsafe Control Actions (UCAs) for the analysis without AppSTPA of the Collision Avoidance System (CAS). The hazards are: • H-1: Drone/bird violates minimum separation standards. • H-2: Drone loses the planned route. Table 13 presents the UCAs identified in the analysis without AppSTPA. Table 14 presents the UCAs converted from the analysis without a tool for CAS to the analysis using the AppSTPA tool, and Table 15 presents the additional UCAs identified using AppSTPA for CAS.