A Comparative Study of STPA-Extension and the UFoI-E Method for Safety and Security Co-analysis

Emerging challenges in cyber-physical systems (CPSs) have been encouraging the development of safety and security co-analysis methods. These methods aim at mitigating the new risks associated with the convergence of safety-related systemic flaws and security-related cyber-attacks that have led to major losses in CPSs. Although several studies have reviewed existing safety and security co-analysis methods, only a few empirical studies have attempted to compare their strengths and limitations to guide risk analysis in practice. This paper bridges the gap between two novel safety and security co-analysis methods and their practical implementations. Namely, this paper compares a novel extension of the System-Theoretic Process Analysis (STPA-Extension) and the Uncon-trolled Flows of Information and Energy (UFoI-E) method through a common case study. In our case study, the CPS under analysis is a conceptual autonomous ship. We conducted our comparative study as two independent teams to guarantee that the implementation of one method did not influence the other method. Furthermore, we developed a comparative framework that evaluates the relative completeness and the effort required in each analysis. Finally, we propose a tailored combination of these methods, exploiting their unique strengths to achieve more complete and cost-effective risk analysis results.


Introduction
Increasingly, cyber-physical systems (CPSs) integrate novel information technologies and higher levels of automation into physical world operations.However, as CPSs are becoming both safety-critical and security-critical in real-world applications, one of the main challenges at present and for the future of risk science is the integration of safety and security analysis [50].Indeed, safety-related systemic flaws and security-related cyber-attacks have overlapped in their contribution to recent hazardous events in CPSs [9].Examples include major damages and losses in industrial control systems, autonomous vehicles, medical devices, among others [21,47].
Traditionally, the domain of safety analysis was bounded to accidental or unintentional risks, whereas the domain of security analysis focuses on intentional sources of risk [1,35].More recently, researchers have proposed and reviewed different methods that integrate safety and security analysis into a co-analysis framework.In the literature, comprehensive surveys have assessed the distinguishing features of many of these novel safety and security co-analysis methods, providing theoretical classifications and insights about their capabilities [10,23,25,33,34].
However, to the best of our knowledge, there is no sufficient empirical studies to assess the benefits and limitations of applying these co-analysis methods in real systems.The novelty of these methods results in little evidence that can demonstrate their applicability and usefulness to mitigate the emerging risks in CPSs.Moreover, the complexity, openness and novelty of autonomous systems such as selfdriving vehicles, industrial robots, and autonomous ships carry with them unprecedented cyber risks, which likely cannot be handled by traditional safety or security risk analysis methods.We need to explore whether those novel safety and security co-analysis methods can properly identify safety hazards and security threats and effectively mitigate them.
In this paper, we compare two newly developed safety and security co-analysis methods in a common case study to bridge the gap between the theoretical methods and their practical implementation.Namely, we

Related work
In this section, we briefly introduce UFoI-E and STPA-Extension to provide the necessary background knowledge for the following content of the paper.Then, we review the state-of-the-art on comparing safety and security co-analysis methods in practice.

The Uncontrolled Flows of Information and Energy (UFoI-E) method
The Uncontrolled Flows of Information and Energy (UFoI-E) method supports risk analysts in the identification and mitigation of harm scenarios in CPSs.This method provides a systems engineering approach to model complex risk scenarios in CPSs, identify safety and security risk sources, map propagation effects across the layers of the system and finally provide a layers of protection strategy to mitigate the risks.
As shown in Fig. 1, the UFoI-E method consists of three main constituents: (a) UFoI-E causality concept The first constituent of the UFoI-E method is the UFoI-E causality concept.The UFoI-E causality concept is a model of causation that considers safety and security risks into an integrated model.Accident causation models are highly regarded as the fundamental theories supporting all safety analysis methods [20,29].However, these theoretical foundations of safety analysis were separated from the field of security engineering [3,20,28,38].Therefore, for the first time in the domain of safety analysis, the UFoI-E causality concept provides an accident causation model that integrates safety and security engineering with the incorporation of physical and cybersecurity threats as risk sources [5,7].
The UFoI-E causality concept is an extension of the Uncontrolled Flows of Energy (UFoE) model [17,36].In the UFoE model, an undesired release of energye.g.potential, thermal, or electricalor a release of toxic materials can lead to physical harm to valuable entities.To avoid or mitigate harm, designers can allocate safety barriers to separate the UFoE from the valuable entities.The UFoI-E causality concept extends this UFoE model to include the ways that Uncontrolled Flows of Information (UFoI) could also kill humans and cause physical damages.Cases of UFoI stress how software flaws, network design errors and novel cyber-physical attacks threaten the safety of CPSs and could lead to human fatalities, asset damages and environmental impacts.Consequently, a combination of safety barriers and security barriers is needed to avoid or mitigate harm [7].
As the first constituent of the UFoI-E method, the UFoI-E causality concept is the only constituent that is not an operational tool of the method.Instead, this constituent is the fundamental theory that supports the other two practical constituents. (

b) CPS master diagram
The second constituent of the UFoI-E method is the CPS master diagram.The UFoI-E method emphasizes the need to represent and visualise the CPS under analysis using a comprehensive framework.In the words of P. L. Clemens, "we never analyse a systemwe analyse only a conceptual model of a system" [38].
For this purpose, this method provides the CPS master diagram, a generic representation of CPSs that teams of analysts can use as an initial template to translate their particular system specifications into a tailored diagram.The CPS master diagram establishes a common terminology and a system model to integrate the knowledge of multidisciplinary risk analysis teams.In general, the CPS master diagram conceptualises CPSs as a system of three interacting layers: the cyber layer (CL), the cyber-physical layer (CPL), and the physical layer (PL).
In a nutshell, the PL is the domain of the system that influences the physical world.This PL includes the energy flows and material processes monitored by humans via manual and analog interfaces.The CPL is the domain of the system where networked control systems perform realtime and autonomous actions to influence the PL.This CPL includes sensors, programmable controllers and actuators that transmit information flows via real-time communication networks.The CL is the domain of the system that monitors the rest of the CPS as supervisory control technologies and processes.This CL includes computer networks and humans that monitor information flows coming from the PL and the CPL.Finally, all these layers also interact with their cyber and physical environments, exchanging flows of information and energy.For a comprehensive description of the CPS master diagram, see Carreras Guzman, Wied, et al. [9].
As the second constituent of the UFoI-E method, the CPS master diagram stresses the need to agree on a common model of the CPS before conducting the identification of safety and security risk scenarios.Consequently, a generic CPS master diagram can be used to create a tailored diagram of the specific CPS under analysis.
(c) CyPHASS The third and final constituent of the UFoI-E method is the Cyber-Physical Harm Analysis for Safety and Security (CyPHASS).CyPHASS is a harm scenario builder to assist a systematic identification of safety and security risk scenarios using an extended bowtie model.Overall, CyPHASS is a toolkit composed of two main parts: (1) an ontology of scenarios and (2) a database of checklists and guidewords.
(1) Ontology of scenarios: The ontology of scenarios in CyPHASS is an extended bowtie model that illustrates a comprehensive set of generic paths that could lead to unsafe consequences in CPSs.
Following the conventions of bowtie models [13], the ontology of scenarios describes an extended bowtie composed of three consecutive top events, each of them associated to their causes to the left and their potential consequences to the right.As depicted in Fig. 2, various causes and propagation effects could cascade across the layers of the CPS master diagram and lead to complex scenarios in a series of stages.This ontology of scenarios is a generalisation that considers the experience from a wide set of hazardous events in CPSs, where accidents and cyber-attacks have demonstrated how risk sources affecting one layer of the CPS have cascaded throughout the connected layers and produced catastrophic damages.Indeed, these cascades across layers have occurred in diverse CPS applications including industrial plants, driverless vehicles, medical devices, among others [6,21,48].(2) Database of checklists and guidewords: CyPHASS includes a database of checklists and guidewords for each stage of the scenario.This database is a knowledge repository of lessons learned and expert knowledge to assist risk analysis teams [6].
As shown in Fig. 2, for each component of the extended bowtie in the ontology of scenarios, a list of checklists and guidewords is available to be used as supporting material.As a prototype tool, this database of checklists and guidewords is available as an open-source material for risk analysts [4].In combination, the CyPHASS ontology of scenarios and its database of checklists and guidewords provide a tool to identify harm scenarios and to recommend barriers to prevent and mitigate these scenarios.

Application process of the UFoI-E method
After a team of analysts translate their system specifications into a tailored CPS master diagram, the risk identification with CyPHASS is a stepwise process.Previous works have illustrated how to develop tailored CPS master diagrams for safety and security analysis [7][8][9].In the following paragraphs, we will focus on the systematic application of CyPHASS, which is a novel development of the UFoI-E method [6].
The risk identification process with CyPHASS addresses how unsafe consequences can arise from different risk sources targetingeither unintentionally or intentionally -the different layers of the CPS.In line with the Society for Risk Analysis Glossary, the UFoI-E method uses the term "hazard" for unintentional or natural sources of risks associated to safety, whereas the term "threat" corresponds to intentional sources of risk associated to security [1,2].In the CyPHASS ontology, hazards and threats (H/T) are the initial risk sources in the scenarios.
In a systematic way, the process of scenario identification with CyPHASS consists on linking a set of ultimate safety consequences all the way back to their initial risk sources.In CyPHASS, the ultimate safety consequences occur at the physical layer (PL) and the physical environment of the CPS master diagram.At these layers, the physical entities of the systemhumans, assets and the natural ecosystem -can suffer  injuries and damages as ultimate safety consequences.In CyPHASS, the direct causes of these ultimate safety consequences are uncontrolled flows of energy (UFoE) and toxins occurring at the PL.Examples include uncontrolled kinetic or thermal energies, releases of toxic and radioactive substances, among others.
In CyPHASS, an UFoE is the result linked to oneor a combination of -process variable and functional deviations (PV-F) arising at the PL.To discover these potential deviations, the CyPHASS database recommends the use of hazard and operability (HAZOP) guidewords [14,45] and functional failure checklists [15].This integration of HAZOP guidewords and functional failure checklist offers an comprehensive toolkit to analyse the PL.Examples include deviations associated to actions of human operators at the PL, deviations in mechanical and electrical parameters at the PL, among others [6].
Starting from the PV-F deviations to the left, the causes in the bowtie ontology can be separated into two categories.The first category is a direct risk source (H/T) threatening the system layer under analysis.The second category is a propagation effect from the adjacent layer of the CPS.In CyPHASS, these propagation effects can arise as intermediate events that cascade across the layers of the system.Moreover, a concurrent presence of direct risk sources and propagation effects can also lead to the discovery of complex scenarios.
As causes of PV-F deviations at the physical layer, the propagation effect can be the result of an uncontrolled flow of information (UFoI) occurring at the cyber-physical layer (CPL).Examples of UFoI include corrupted, delayed or missing information flows.Specifically, these UFoI at the CPL are deviations associated to real-time control subsystems -i.e.sensors, programmable controllers, actuators and the realtime communication networks that transmit their information flows -.As with the PL, the CPL is exposed to direct risk sources as H/T as well as to additional propagation effects.In this final case, the propagation effects arise from the cyber layer (CL).
In CyPHASS, UFoI occurring at the CL are the final and most distant stage associated to the unsafe safety consequences.Nevertheless, recent catastrophic events in industrial plants, driverless vehicles and medical devices have shown how cases of UFoI at the CL can propagate across all the layers of the CPS and lead to unsafe safety consequences [6,21,48].Notable examples are the Stuxnet attack [27] and the TRITON attack [22].The risk sources associated to these particular CL UFoI include unintentional supervisory errors as well as intentional cyber-attacks.
As referred by Carreras Guzman, Kozine et al. [6] and illustrated in Fig. 3, CyPHASS describes a stepwise process to perform risk identification backwards, i.e. starting from the ultimate consequences and discovering all the stages of the scenarios towards the initial risk sources.The steps can be summarized as follows: Step 7: For each CL UFoI, identify causes as cyber and physical H/T Step 7.1: For each cyber and physical H/T, identify and recommend prevention barriers" [6] Notice that in CyPHASS, an event tree with mitigation barriers follows to the right of each intermediate event.These mitigation barriers are detection and response countermeasures that aim at avoiding the propagation of the scenario to reach a safe state.At the left of each intermediate event, a set of hazards or threats (H/T) can be direct causes for each intermediate event.To prevent the H/T, prevention barriers can eliminate or reduce the likelihood of the H/T.
In sum, CyPHASS suggests the allocation of sequential prevention and mitigation barriers acting as layers of protection throughout the stages of the scenarios.This layers of protection strategy is considered critical to ensure that, even if one safety or security barrier is breached, other barriers can be activated across the layers of the system.As an illustrative case, even if a malwaree.g.Stuxnet or TRITONinfects a computer network at the CL and attempts to propagate to the control network at the CPL, additional barriers can still detect and respond at the CPL or at the PL to contain or mitigate damages.These barriers include technical components and system architecture arrangements as well as human operations and organisational strategies.
At each step of the stepwise process in CyPHASS, the analysts can use a database of generic checklists built from lessons learned and expert knowledge of CPSs.This overall database is available as a software prototype in common spreadsheets format and is shared as an opensource material [4].For each case in the database, the analysts can Fig. 3. CyPHASS extended bowtie model in analysis steps, adapted from Carreras Guzman, Kozine et al. [6].
N.H.Carreras Guzman et al. visualise their CPS master diagram, ask the question "Is this case possible in my system?" and link the connections between the sequential stages of their scenarios in the CyPHASS ontology.

STPA safety and security co-analysis framework
The Systems-Theoretic Process Analysis (STPA) was primarily developed as a safety hazard analysis technique based on the Systems-Theoretic Accident Model and Processes (STAMP) [30].STPA is a top-down approach consisting of four fundamental steps [32] listed below: • Step 1: Define the purpose of the analysis and establish the system engineering foundation • Step 2: Model the control structure • Step 3: Identify unsafe control actions • Step 4: Identify causal scenarios Later, STPA-Sec was proposed to extend the hazard analysis scope by incorporating systems security engineering into analysis as well [49].STPA-Sec maintains the four fundamental steps unchanged while essentially introducing security threats/vulnerabilities identification into Step 4.More recently, several researchers have proposed extensions of STPA for safety and security co-analysis [16,24,39].
When applying the conventional STPA or STPA-Sec approaches to the analysis of novel CPSs, such as autonomous ships, the method faces several challenges.Firstly, Step 1 does not provide sufficient analysis artefacts to guide the system design of novel systems, which are typically in the exploration phase and not well defined.It is not straightforward to model the control structure in Step 2 with limited prior knowledge and experience of such systems.To bridge such a gap, a structured STPA safety and security co-analysis approach was proposed [19].The structured co-analysis approach is depicted in Fig. 4 and is referred to in this paper as STPA-Extension.
As shown in Fig. 4, this co-analysis approach introduces Functional Requirements, i.e., sub-step number (6), into Step 1 to facilitate the development of the control structure in Step 2. Secondly, STPA-Sec does not explicitly consider the security-related losses, which could be equally critical as safety-related losses for many systems.To cope with this issue, the structured STPA co-analysis approach explicitly includes system-level security-related losses when identifying the system-level losses.It also differentiates the system-level security incidents from safety accidents to guide the identification of system-level hazards in Step 1.It further enhances the co-analysis in Step 4 where not only accidental and unintentional, but also intentional causes, are comprehensively analysed at component-level.In short, there are two separate aspects of security and they need to be separately included in the coanalysis process.These are (1) security-related causes can lead to safety-related losses, and (2) safety-related causes can lead to securityrelated losses.

Review of comparative studies of safety and security co-analysis methods
This subsection reviews empirical studies comparing risk analysis methods with a focus on the safety and security of CPSs.Based on this body of knowledge, we discuss a research gap that hinders the validity and replicability of these comparative studies.
Kriaa et al. [26] compared the Combined Harm Assessment of Safety and Security for Information Systems (CHASSIS) [37] and the Boolean logic Driven Markov Processes (BDMP) [35] in a case study.The case study was a CPS previously modelled with BDMP.During the comparison, the BDMP model was changed to match the CHASSIS model.At this point, the two methods influenced each other during the analysis to have "harmonizing" models of system representation.This comparison also highlighted the strengths of both methods and showed the possibility to combine them.
Schmittner et al. [40] compared CHASSIS and the Failure Modes, Vulnerabilities and Effects Analysis (FMVEA) for an automotive CPS.This study showed that the two methods do not have many overlapping failures, as the FMVEA found more component-based failures and the CHASSIS found more software and cyber threats.This study also stated that the CHASSIS method analyses safety and security as two separate parameters, which is not ideal as they could affect each other.A unified  risk rating for threats and failures that influences security would be a necessary improvement for both methods.This paper did not evaluate the amount of time and effort needed for both analyses.
Sulaman et al. [43] compared the STPA and the Failure Modes and Effects Analysis (FMEA) method by applying STPA hazards categories to the FMEA failures found in their case study.For comparison purposes, they used an assessment criteria following the technology acceptance model (TAM) [12].This study concluded that the difference between the exposed hazards and failures is little to almost indifferent between the methods.However, their result showed that FMEA provides more specific failures, whereas STPA provides more detailed causes.According to the analysis, the difficulty of the two methods seemed to be very similar.When comparing the effort to use the two methods, they only made a rough estimation of the time used to determine if there was a relationship between effort, time, and outcome.The main limitation of their comparison is that they categorized the items in the STPA categories.Therefore, the hazards found from the STPA analysis look best illustratively, since the categories were made for the STPA method.
Wei et al. [46] used the STPA-Sec method to identify threats to a conceptual mobility-as-a-service fleet of autonomous vehicles.After obtaining the STPA-Sec results, they performed a CHASSIS analysis to complement their STPA results rather than to compare the two methods.The two analyses were not performed on an equal base, which led to different results.As the same authors applied the two methods, they gained knowledge in the process of applying the different methods.However, as each method has a different objective, it is hard to tell to what degree this gained knowledge affected the outcome.
The reviewed literature mainly compared the complexity and the outcome obtained from the different safety and security co-analysis methods.However, we identify four specific issues that hinder the validity and replicability of these previous studies: 1 Some comparative studies do not take sufficient measures to avoid the problem of accumulation of knowledge.This problem arises when a single team of analysts performs the first analysis with one safety and security co-analysis method and then performs the second analysis with the second method.For the second analysis, the single team is carrying the knowledge gained during the first analysis and influencing the results obtained in the second analysis.2 Most comparative studies fail to report the level of knowledge of the analyst teams.We argue that, when two teams of analysts have differences in their (a) level of experience as analysts and (b) knowledge about the system under analysis; the results of the comparison will favour the safety and security co-analysis method that was used by the more experienced and knowledgeable team of analysts.3 Most comparative studies give little or no indication about the effort required to obtain the results with each safety and security coanalysis method.Arguably, if more time and resources are dedicated for one method, this additional effort will favour the method in question.4 Finally, some comparative studies only consider how one safety and security co-analysis method complements the results obtained from a previous analysis with a different method.These studies not only suffer from the issue of accumulation of knowledge, but also tend to reflect an a priori preference towards one of the methods.We argue that the goal of this type of studies is not to compare the two methods, but only to use some insights to refine the preferred method.
In the following section, we address these issues by presenting our research methodology for comparison of safety and security co-analysis methods.Accordingly, the goal is to present a framework to facilitate the validity and replicability of these comparative studies.

Research Methodology
The research objective of this empirical study is to evaluate the qualitative strengths and limitations of two safety and security coanalysis methods in terms of (1) completeness of the results and (2) effort required.Furthermore, this paper aims at identifying potential ways to combine these two methods effectively to overcome their respective limitations.
According to Creswell [11], case studies are research methods that are practical for the evaluation of qualitative data.As previously illustrated in Section 2.3, other comparative studies of safety and security co-analysis methods have used case study research.Therefore, we designed a case study as a suitable research method to achieve our research objective, overcoming some limitations identified in other comparative studies.
In particular, our case study is a prototypical implementation with feedback.Our prototypical implementation is the analysis of one common system using two different safety and security co-analysis methods.As shown in Fig. 5, the common system under analysis is the ReVolt autonomous vessel prototype, and the safety and security co-analysis methods are the UFoI-E method and STPA-Extension.After performing the analyses, the feedback is the comparison of the results obtained using each safety and security co-analysis method.
In our case study design, we designated two independent teams.Two authors of this paper composed Team 1, and the other two authors of this paper composed Team 2. Each team used only one safety and security co-analysis method, namely, Team 1 deployed the UFoI-E method and Team 2 used STPA-Extension.To avoid the issue of accumulation of knowledge, the two teams performed the analyses independently.
In terms of knowledge of the system, from the initial stage onwards, the teams shared a common documentation of the system specifications and a limited set of preliminary analyses performed for previous versions of the ReVolt.Regarding the knowledge of the other team's method and results, the teams conducted workshops to train each other in the generic features of their respective safety and security co-analysis methods.During the analysis, the teams only communicated and exchanged ideas to agree on the ways to represent their results in a comparable framework.This comparable framework implied the need to specify a common scope of the analysis and a similar level of abstraction.
To set a common scope of the analysis, the teams agreed to consider a unique ultimate consequence as system loss.This unique system loss is a collision of the ReVolt vessel while operating in autonomous mode.This scope of the analysis excludes the issues related to the other three modes of operation of the ReVolt (see Section 3.2).Moreover, the specification of a unique system loss emphasizes safety as the goal of the analysis, excluding other types of system losses such as financial losses, reputation losses, data privacy, among others.
To set a similar level of abstraction, the system specifications of the ReVolt as currently designed are a shared constant for both teams.These system specifications considered the hardware architecture and some Fig. 5. Overview of our case study design.
N.H.Carreras Guzman et al. technical specifications of the components as installed.For the software design and implementation, the level of abstraction was limited to the functional requirements of the control algorithms.Therefore, the analyses did not consider specific errors or vulnerabilities in the software code or the communication protocols.This level of abstraction is consistent with a systems perspective shared by both safety and security co-analysis methods deployed.

Evaluation criteria for the comparison
Completeness: To assess the quality and completeness of risk identification methods, Taylor [44] propose a theoretical measure of completeness.It defines completeness in terms of the number of risks identified by the method with respect to the total number of risks existing in the system under analysis.Therefore, as shown in Equation ( 1), the theoretical measure of completeness can be defined as a ratio.

Completeness =
Number of risks identified Total number of risks If the ratio were equal to one, the risk identification would be "absolutely complete".However, the total number of risks is an objective benchmark that is usually not available for novel and complex systems.Therefore, one way to obtain a relative evaluation of completeness in risk identification is to compare several analyses of the same system [44].
In our comparative framework, the number of risks correspond to the number of risk scenarios identified by the safety and security co-analysis methods.In this paper, we define a risk scenario as a combination of conditions and events that can lead to a loss.As previously mentioned, in our case study we predefine a unique safety-related loss, namely, a collision of the ReVolt vessel while operating in autonomous mode.Therefore, different risk scenarios are different combinations of conditions and eventsincluding common causes and sequential eventsleading to a collision of the ReVolt.Considering the safety and security co-analysis of a CPS, the risk scenarios include accidental, unintentional and intentional causes related to cyber and physical parts of the system.Subsequently, Fig. 6 illustrates our comparative framework for a relative evaluation of completeness in a Venn diagram.Each set of this Venn diagram corresponds to the total number of risks identified by each method.At their intersection, one can enumerate the risks identified by both methods independently.Conversely, the relative complements are the risks identified only by one method and not by the other.Finally, the union of the two sets corresponds to the relative benchmark of total number of risks.
In this comparative study, we identify two types of reasons that result in the relative complements in the Venn diagrami.e. in the results obtained only by one method: 1 Team-specific: reasons associated with the teams using the method 2 Method-specific: generic reasons associated with the safety and security co-analysis methods as such.
These reasons serve to explain the differences obtained by the two methods.If the difference is team-specific, a proper application of the two methods can provide sufficient guidance to identify those risks missed by one of the teams.The team that missed those risks may have overlooked them due to different factors that are typical in risk analysis tasks (see Section 5.1).Conversely, if the difference is method-specific, it reveals a relative strength of the method that identified those specific risks.By identifying similarities and patterns between the methodspecific results, we can propose potential improvements in which one method could complement the other in a combined analysis to obtain better results.
Effort required: To account for the background experience and knowledge about the ReVolt system, Table 1 explicitly shows these criteria distributed across the team members.This table includes the years of experience as safety and security analysts and the background knowledge about the ReVolt system at the beginning of the case study.Fig. 6.Conceptual framework to compare the results as a relative evaluation of completeness.

Table 1
Background experience and knowledge about the system before the comparative study.

Criteria
Team 1 (UFoI-E) After the teams concluded their independent analyses, they reported the total working hours used to prepare for and to perform their respective safety and security co-analysis.In conjunction, our comparative framework accounts for the total working hours used in each method and the level of knowledge of each team as the contributing factors leading to team-specific differences in the analysis results.
Furthermore, the working hours used in each method serve as an indicator of the cost or the resources needed to apply the method.In short, if both methods were to obtain the same results, the method that facilitates these results in less time would arguably be more costeffective.However, this simplified reasoning assumes the same level of knowledge of the system and comparable expertise as a risk analyst, while it neglects the synergic interactions between the team members.Therefore, we provide this indicator of working hours alongside the information about the team members, including their knowledge of the system and the tools used for the analysis.We argue that, by keeping all these factors partially under control and by explicitly illustrating their partial differences, we provide sufficient basis to make the results comparable in a fair context.

The ReVolt (A conceptual autonomous ship) -System under analysis
DNV GL 2 is a leading classification society that is influential in shaping future maritime safety regulations and develops corresponding rules and standards for the classification of ships.It is crucial for DNV GL to comprehensively assess the potential safety and security risks of operating autonomous ships under diversely operational scenarios and unexpectedly environmental situations.DNV GL Group Technology and Research department has been developing a conceptual autonomous ship, called the ReVolt, since 2014.The ReVolt has been dedicated to explore and experiment how to safely and securely integrate novel and emerging technologies/equipment into marine ships to achieve various degrees of automation.
In this paper, we select the ReVolt as the system under analysis to perform our comparative study.The ReVolt currently supports four operation modes, i.e., remote-controlled mode, dynamic positioning mode, emergency stop mode and autonomous navigation mode.In this paper, we limit our analysis scope to the autonomous navigation mode.Under the autonomous navigation mode, the most critical accident that the ReVolt has to avoid is colliding with other objects, including vessels, swimmers, floating obstacles, or structures.To limit our analysis effort to a controllable level, we only focus on analysing the collision accidents under the autonomous navigation mode.Since the ReVolt is an unmanned ship and does not collect any confidential data during its missions, we do not consider security-related system-level losses due to confidentiality breaches in this study.
As shown in Fig. 7, various types of sensors and advanced functionalities have been integrated into the ReVolt to enable autonomous navigation.The notations used in Fig. 7 are explained in Table 2. Furthermore, the operational scenario under analysis and the possible collision accidents are described in Table 3, which specifies the scope of our comparative study performed by the two teams.

A brief overview of autonomous operation mode
Under the autonomous operation mode, the ReVolt will be able to receive a destination from the operator as input and move to the desired position autonomously.This will be accomplished by autonomously creating a safety path for the ReVolt to follow.When it navigates along the planned path, it will use cameras and a LiDAR to monitor its surroundings.These sensor measurements will be used for collision avoidance and to update the path plan.
The navigation controller is the most complex part of the ReVolt system and implements the major functionality of autonomous navigation.The navigation controller receives inputs from the operator via 4G communication network, the obstacle avoidance and the observer.The inputs include the desired destination, the position of any detected obstacles, and the current position, speed and heading of ReVolt.Then, the navigation controller provides a safety path as a set of waypoints to follow in order to safely reach the desired destination.Finally, it provides the force controller with the current position and orientation and the next desired position and orientation.
The obstacle avoidance receives the vision sensor data about the surroundings of the ReVolt.Those data are used to detect obstacles in the surrounding area and estimate the position, speed and heading of the detected obstacles.Those data are shared with the navigation controller.
The observer receives position and velocity sensor data to estimate the position, linear and angular velocity of the ReVolt.Those data are shared with the navigation controller.The ReVolt communicates with the onshore operator via the 4G communication network.It sends and receives messages in real-time.The operator mainly provides the ReVolt with its desired destination and control commands.The navigation controller uses the 4G network to send feedback information to the operator.

Analysis results
This section describes and compares the results obtained from the safety and security co-analysis of the ReVolt using the UFoI-E method and STPA-Extension.

Tailored CPS master diagram of the ReVolt
Fig. 8 illustrates the diagrammatic representation of the ReVolt as a tailored CPS master diagram.This tailored CPS master diagram is the result of a workshop adapting the generic CPS master diagram with the system specifications of the ReVolt.The team applying the UFoI-E method conducted this workshop using a shared widescreen and basic diagrammatic tools.
The tailored CPS master diagram provides a comprehensive model of the system that the team members used to communicate about the system and to analyse it systematically using CyPHASS.For the comparative study, this diagram emphasizes the components and interactions in the system relevant only for the autonomous mode of operation.Therefore, some parts of the master diagram are hidden with filters in the background and can be retrieved only if required.
At the physical layer (PL), the diagram shows the energy flow interactions between the thrusters and the vessel hull for the propulsion and steering of the vessel.The PL interacts with the physical environment, which poses energy disturbances (e.g.ocean currents, waves, and wind) as well as obstacles in the way (e.g.other vessels).At the cyberphysical layer (CPL), the diagram shows the information flows between the sensors, the computer on-board and the microcontrollers.The CPL implements the autonomous control actions that influence the PL in real-time feedback loops.At the cyber layer (CL), the diagram illustrates the remote workstation onshore, where the human supervisor issues commands via an HMI and uses a wireless network to communicate with the CPL, particularly with the computer onboard the vessel.Finally, the cyber and physical environments interact with the different layers of the system supplying information and energy flows, which may be subject to manipulations by the actions of hackers and saboteurs.These hackers and saboteurs could potentially penetrate the system layers to perform attacks.Similarly, malicious insiders could violate system guidelines and cause a sequence of UFoI-E.

Identification of scenarios and barriers in the CyPHASS bowtie
Fig. 9 summarizes the aggregation of scenarios identified with CyPHASS.To identify these scenarios, the team in charge conducted risk 2 DNV GL is the independent expert in risk management and quality assurance: www.dnvgl.comN.H.Carreras Guzman et al. identification workshops using the CyPHASS database of checklists in spreadsheets format.The team applying the UFoI-E method conducted this workshop using a shared widescreen and basic spreadsheet software.
According to the scope of this comparative study, the scope of the analysis is a collision as an ultimate safety consequence.From this point, CyPHASS allows for systematic backward tracing of causes with their respective intermediate events according to the extended bowtie model.For each stage of the scenarios, the team also identified prevention and mitigation barriers according to the suggestions in CyPHASS.If the barriers were already present in the ReVolt, the team marked them as present (P).Conversely, the team marked the barriers as recommended (R) to add into the system.
For illustration purposes, Fig. 10 summarizes an extract of three scenarios in CyPHASS shown as three branches: • Branch (1): extract of a scenario that initiates with a risk source at the physical layer.• Branch (2): extract of a scenario that initiates with a risk source at the cyber-physical layer.• Branch (3): extract of a scenario that initiates with a combination of risk sources at the cyber layer.

Table 2
Notations used in Fig. 7.  intermediate event breaches the mitigation barriers and causes a subsequent event, the mitigation barriers allocated at the subsequent stage of the scenario may still lead the system to a safe state.To simplify the visualisation of specific barriers, this figure only shows a single barrier at each stage of the bowtie.In the complete set of scenarios in spreadsheet form, each element of a scenario has an assigned identifier (ID).These IDs trace the intermediate events identified in CyPHASS to their respective causes and consequences and their associated barriers.

Effort required in person-hours
As an indication of the effort required using the UFoI-E method to analyse the ReVolt system, Table 4 summarizes the person-hours that Team 1 spent in this analysis.Notice that, neglecting the preparation time reading the system specifications, the time designing the tailored CPS master diagram of the ReVolt was only seven person-hours.As expected, the most expensive part of the analysis was the identification of risk scenarios and the recommendation of barriers with CyPHASS.Still, the database of checklists in CyPHASS represented a benefit for Team 1 to complete this part of the analysis cost-effectively, not needing to spend time collecting documentation about lessons learned and checklists from external risk repositories.Moreover, the results of UFoI-E already include the recommendation of prevention and mitigation barriers acting as layers of protection.For a similar time of work and effort required, this recommendation of barriers is a benefit that is usually beyond the scope of STPA analyses.

STPA-Extension results
The beauty of performing an STPA analysis is to establish a traceability between a precedent (sub)-step and the following (sub)-steps by following a top-down approach.We demonstrate such traceability through presenting our analysis results by following the STPA-Extension workflow illustrated in Fig. 4. STPA-Extension is an iterative approach.All steps shown in Fig. 4 can be re-visited and the analysis results of each step can be revised accordingly.

Step 1: Define the purpose of this analysis
STPA-Extension starts from identifying system-level losses that must be prevented.Theoretically, conventional STPA and its variations can be applied broadly to not only safety losses but also losses related to security, privacy, performance and other system emergent properties.Practically, we have to define the system boundary and limit the scope of analysis to efficiently achieve desired results.
The operational scenario considered in this paper is to safely and securely navigate the ReVolt by following a predefined waypoint plan.Therefore, the scope of our analysis focuses on safety, security and performance-related losses.The identified system-level losses are listed in Table 5.
Losses are typically the result of accidents and often of a non-specific nature.As shown in Table 5, we may identify similarly generic losses for many other safety-critical systems as well.To bridge the gap between generic losses and further analysis, STPA-Extension re-introduces identification of system-level accidents, which are identified in a specific context or under specific operational scenarios [19].Note that the system-level accident was originally included in the conventional STPA [31] but is replaced by "loss" in the latest version of STPA [32].
We chose one particular system-level accident to exemplify the complete analysis process of STPA-Extension due to time limitations when performing this comparative study.We further identified systemlevel hazards that could lead to this accident.Subsequently, we have to prevent the hazards from occurring or minimise the loss in case the hazards do occur by defining corresponding system-level constraints.The system-level accident, hazards and constraints identified in the study are listed in Table 6.

Table 4
Summary of person-hours used by Team 1 with the UFoI-E method.may be related to one accident (i.e., A1).A system-level constraint is simply to invert a system-level hazard.Therefore, one constraint (i.e., C1) typically corresponds to one hazard (H1).
Step 1 of the conventional STPA stops here.However, STPA-Extension introduces an additional sub-step, i.e., functional requirements, to facilitate modelling the control structure of the ReVolt.As shown in Table 7, we finished Step 1 analysis by specifying a list of functional requirements to fulfil constraint C1.

Step 2: Model control structure of the ReVolt
A hierarchical control structure is a system model that is composed of feedback control loops [32].The control structure consists of two important control system properties, i.e., controllability (control input and control actions) and observability (feedback and process model) [19].
We began with an abstract control structure (refer Fig. 7) and iteratively refined it.More specifically, we identified controllers, the corresponding control actions of each controller and the feedback of each control action by analysing functional requirements specified in Table 7.Those artefacts identified during control structure modelling are summarized in Table 8.

Step 3: Identify unsafe control actions (UCAs)
Identification of unsafe control actions (UCAs) plays a vital role in STPA analysis.The definition of an UCA is a control action that, in a particular context and worst-case environment, will lead to a hazard [32].To consistently identify UCAs for different systems, four types of UCAs are defined in the conventional STPA.Moreover, we introduced two additional types of UCAs to properly describe the cases in our study.Particularly, UCA3 is implicitly covered in UCA2, but we introduce it in STPA-Extension to explicitly represent this type of UCA.The complete list of UCAs adopted in our study is described in Table 9, where UCA3 and UCA6 are the two additional types introduced in this study.
The practice of identifying UCAs is to enumerate all possible combinations of the controller, control action, and UCA type, which may lead to a hazard.Table 8 lists three controllers and five control actions.Note that UCA5 does not apply to our study and was excluded from UCA identification.The possible UCAs identified by combining the controller and control action is summarized in Table 10.

Step 4: Identify causal scenarios
A causal scenario describes the causal factors that can lead to the unsafe control actions and hazards [32].To explicitly identify initial causal factors for each unsafe control action identified in Step 3, we conducted the causal scenario identification in a step-wise fashion as illustrated in Fig. 4.
Firstly, we started with examining each UCA listed in Table 10 and enumerated the potential effects of all possible failures that could result in this UCA by following four general types of Accident Causes (ACs) listed below.
• AC1 -Wrong or missing control input • AC2 -Wrong control logic • AC3 -Wrong or missing situation understanding, feedback/sensing • AC4 -Lost/altered control action or actuation Note that the four types of ACs are adapted from Leveson and Thomas [32] but customized to more precisely capture hazards and threats of the system under analysis.Remarkably, the sole combination of UCA6 and AC4 is reasonable.
One causal scenario was specified to describe one specific effect and the resulted UCA.One example of causal scenarios is:

CS-1 (Causal scenario 1): ReVolt does not provide deviating waypoint plan (UCA1) because ReVolt does not detect or track other vessel/ obstacle at all.
Secondly, we listed all possible failure modes for the specific effect described in each causal scenario and named the failure modes as Design-specific causes (DSC) in this paper.Following the causal scenario example given above, we identified five DSCs for CS-1 as listed in Table 11.
Lastly, for each DSC listed in Table 11, we enumerated all initial causal factors, which could contribute to the occurrence of this DSC by following three generic cause categories: accidental, unintentional, and intentional.Both accidental and unintentional causes belong to safety category, while intentional causes are of security category.The accidental causes are inherent in the design of an element (e.g.component or functionality), such as design defects, software implementation errors, hardware failures, communication failures, etc.The unintentional causes are generally due to human errors.For instance, the human operator forgets to send a control command to the system under control or unintentionally configures a wrong value of some parameters.The intentional causes represent all possibilities that a malicious entity could deliberately compromise a specific element by exploiting the security vulnerabilities of this element.
The summary of causal scenarios analysis for hazard H1 is given in Table 12.One casual scenario may correspond to more than one designspecific causes.In addition, one DSC may be traced to several initial causal factors that are still at a very generic level.We can apply traditional safety or security analysis methods to model concrete root causes for each (generic) initial factor.However, we did not reach this level of details in our study due to time limitations.

Effort spent on STPA-Extension analysis
The STPA-Extension analysis team divided the analysis work into two parts according to the competence of the two analysts.The first analyst, who has extensive knowledge of cybernetics and two years of experience in applying STPA to safety analysis, was mainly responsible for the tasks from Step 1 to design-specific causes in Step 4. The second analyst, who had a certain knowledge of the ReVolt and two years of experience in safety and security co-analysis, mainly worked on categorising initial causal factors into three generic groups and applying such categorisation to initial causal factor analysis of each designspecific cause.The total effort spent on the STPA-Extension analysis is summarized in Table 13.

Comparison of results
Based on the results previously described for each safety and security co-analysis method, we conducted a comparison of results in terms of relative completeness obtained by each method.Table 14 summarizes the relative completeness from the STPA-Extension and the UFoI-E analyses of the ReVolt.This table counts the number of risk scenarios and classifies them according to the relative completeness framework described in Section 3. Similarly, Fig. 11 illustrates the results in our Venn diagram framework.
To better illustrate these results, Table 15 shows a representative extract of the comparison.This table describes specific risk scenarios identified only by one of the methods and specific risk scenarios identified by both methods.Note that this table shows at least one scenario for each of the cases previously described in the Venn diagram.Moreover, for each scenario, there is an explanation of the reason for diverging results or the common factors in the correspondence of results.Notice that the STPA-Extension method does not suggest barriers to prevent and mitigate the occurrence of the scenarios, being beyond the scope of the analysis.Therefore, we did not include in the comparison the prevention, detection and response barriers identified in UFoI-E.For more details into the criteria for comparison, see the discussions in Section 5.2.
From this comparison of results, we can argue that, for a similar degree of effort required to perform the analyses, both UFoI-E and STPA-Extension achieved a similar level of completeness in the safety and security co-analysis of the ReVolt.Nevertheless, this similar completeness in terms of the number of scenarios identified is partially different in terms of the scope of the results obtained by each method.Based on these results, the following section discusses our propositional generalisations about the strengths and limitations of the methods used.The control action lasts too long or is stopped too soon (only for continuous control actions) *UCA6 Providing the control action but it is not followed by the receiver

Table 10
Possible UCAs identified.

Threats to the validity of this case study
The results from this case study rely on the experience of two risk analysis teams performing safety and security co-analysis of a single common system.Therefore, the aim of this case study is not statistical validity.Instead, this case study research allows for the discovery of propositional generalisations [42].Using inductive reasoning, from this case study we can derive propositions that are relevant beyond our specific domain of application [18].Namely, we argue that these generic propositions apply for other risk analyst groups using the UFoI-E method and STPA-Extension to analyse other systems.
For the relative evaluation of completeness, we separate the reasons leading to diverging results in our analyses in two classes of reasons: 1 Team-specific: reasons associated with the team deploying the method 2 Method-specific: generic reasons associated with the safety and security co-analysis methods as such.
We argue that this separation is necessary to account for two main team-specific factors.
First, the execution of the method may lead to incomplete results because the team may have carried out the analysis imperfectly.This imperfect execution can lead to oversights in risk identification.The causes of imperfect execution can be a lack of knowledge of the system under analysis, or because the method was not perfectly applied by the team in some specific sections [44].To partially control against these analysis imperfections, the two teams provided their level of knowledge of the ReVolt and their years of experience as safety and security analysts.It is worth to emphasize that STPA-Extension can be applied to a very broad view of accident mechanism concerning social, environmental, human, technological, and contextual factors.To leverage the analysis scope to an appropriate level where both UFoI-E and STPA-Extension could generate comparable results, the STPA-Extension team had to narrow the system boundary and excluded non-technical aspects from the analysis.
Second, the execution of the method may also lead to incomplete results because one team dedicated more resources and effort to perform the analysis.Namely, software tools, time of work and previous analyses available can influence the relative level of completeness achieved by a team using a method.In addition, the analysts may subjectively make a trade-off to reach a certain level of analysis granularity under time limitations.This is a common practice in industry when conducting a risk analysis for a complex system.To partially control against resources and effort required, each team recorded the number of hours spent performing each phase of the risk analysis.We conceived the number of hours used as one indicator of the effort required.Furthermore, the teams reported the software tools used to perform their analyses, which were limited to typical software drawing and spreadsheet tools without automation features.Since the team members are knowledgeable in the use of their particular methods, this case study does not discuss the effort  required to familiarise a new team with the terminologies and tools of each method.

Ensuring mutual correspondence between the results in UFoI-E and STPA-Extension
In our experience, it was not straightforward to decide beforehand  how to compare the analysis results of UFoI-E and STPA-Extension regarding the evaluation criterion of completeness.The reasons include the terminology discrepancy between the two methods, the different execution stages defined in each method, and the different supporting tools used by each method.Although we conducted several workshops to discuss the differences in terminologies, we could not agree on the theoretical correspondence between the results obtained from the two methods.Therefore, we agreed to perform the analyses as each method recommends, i.e. without a predefined template to compare the results.After we obtained the results from each method, we were able to identify more clearly the correspondence between the results obtained in each method.Table 16 illustrates the approximate correspondence between the terminologies used in each method.As a main difference, note the definition of the term "hazard".In STPA-Extension, based on Leveson [30], a hazard is an unsafe system state leading to a loss.In UFoI-E, based on the Society for Risk Analysis Glossary [1,2], a hazard is an unintentional or natural risk source, in opposition to a threat that is an intentional risk source.Therefore, a comparison of the "hazards" identified in each method would not have been a suitable comparison.Instead, our comparison was based on the common meaning of the terms that have a direct correspondence between the two methods.
Furthermore, in Table 17 we describe the correspondence between the stages of the analysis in each method.Namely, this table compares the stages that show how each method identifies the risk scenarios.As the scope of STPA-Extension does not include the recommendation of barriers, we did not include in the comparison the prevention, detection and response barriers documented in the UFoI-E results.Finally, this table summarizes our suggestions to combine each method with some corresponding features of the other method, exploiting the strengths of each method and allowing for a more comprehensive risk identification result.

Suggestions to combine features of UFoI-E and STPA-Extension
From the system representation and modelling perspective, STPA-Extension is an iterative method that begins from a simple systemlevel control structure and continue revising the control structure until reaching the desired level of system abstraction.This simple control structure representation applies for many types of engineered systems and it is not exclusive for CPSs.The UFoI-E method, instead, provides the CPS master diagram as a predefined template to represent the specific architecture of the CPS under analysis.Therefore, even if both STPA-Extension and the UFoI-E method can be applied to analyse CPSs, the UFoI-E method is specifically tailored for this class of systems and STPA-Extension is more generic.
STPA-Extension is a top-down risk analysis approach for a broad range of socio-technical systems as well as CPSs.It can guide analysts to perform an initial round analysis without acquiring too much prior domain or system-specific knowledge.It allows iteratively adding more details into each step to make the analysis more complete as the analysts gain more knowledge or acquire more information about the system under analysis.Moreover, causal scenarios capture the dynamism of the system under analysis by combining the worst-case environmental conditions, system state, failure modes, and the interactions among all involved components/functions along the control path.
The comparative study reveals that STPA-Extension can be enhanced by combining the strengths of UFoI-E or other safety/security analysis methods.More specifically, we propose three possible improvements listed below.
1 A generic list of sources of hazards and types of accidents can be helpful in STPA step 1 to find a more complete list of accidents and STPA hazards. 2 The CPS master diagram of UFoI-E can be beneficial in abstracting the control structure efficiently.However, to avoid adding too many details too early, the analyst has to carefully decide the right abstraction level for which the CPS diagram is suitable.3 As we have introduced the generic categories of initial causal factors, the checklist of hazards and threats developed in UFoI-E can be referred to concretize the specific initial causal factors for each element.Moreover, we can combine other suitable safety/security analysis methods to better cover and investigate relevant causes for the unsafe control scenarios.
Similarly, the UFoI-E method can benefit from the results obtained using STPA-Extension in two generic ways: 1 In parallel with the system conceptualisation phase with the CPS master diagram, the analysts could develop a detailed explanation of the context of losses as in STPA step 1.In terms of the CPS master diagram, this context of losses would be a description of the different interactions between the physical layer of the CPS and the physical environment in different circumstances. 2 The CyPHASS database has the capacity to learn with new inputs and expert feedbacks.Therefore, from the comparison of results obtained in this case study, the CyPHASS database was enhanced with an expanded checklist of CPL UFoI.We identified some cases from the STPA results that were not suggested to consider in the CyPHASS database.Particularly, new considerations for autonomous navigation control algorithms and machine learning technologies were included as CPL UFoI, together with their generic risk sources and suggested barriers.
In summary, both STPA-Extension and the UFoI-E method proved to be suitable risk identification methods for safety and security coanalysis.Each method has some particular features that facilitate a similar level of completeness.However, to obtain a higher and more reliable level of completeness, we suggest that risk analysts can benefit from the combined results of applying the two methods in their studies.Particularly for teams of experts specialised in one of these methods, we provide tailored recommendations to combine specific parts of the other method to enhance and validate their results.These tailored recommendations support a more complete analysis with a cost-efficient approach.

Conclusions
In this paper, we objectively assessed the feasibility and efficiency of applying the UFoI-E method and STPA-Extension to safety and security co-analysis through an empirical study carried out by two independent analyst teams.We purposely defined the scope of a common system under analysis (i.e., the ReVolt, a conceptual autonomous ship) to leverage the advantages of the two methods.
Furthermore, we carefully defined evaluation criteria to formulate an original comparative framework where the results obtained from the two methods can be interpreted properly.This comparative framework

Table 16
Correspondence between the terminologies in UFoI-E and STPA-Extension.facilitates the replicability of comparative studies assessing the capabilities of safety and security co-analysis methods.We selected two fundamental aspects, which are completeness and analysis effort, to evaluate the efficiency of two methods.More specifically, we used the relative level of completeness to assess the results obtained from this comparative study because no benchmark results of the ReVolt is available for calculating the absolute level of completeness.
Correlating the completeness of analysis results with analysis effort demonstrates that the two methods yield similar efficiencies.However, we must be aware that there is a significant discrepancy of risk scenarios identified by the two methods.This is mainly caused by two reasons: (1) the unique strengths and weaknesses of each method, and (2) the variety of each analyst team's domain knowledge and analytical skills.We further mutually mapped the results of one method to those of the other.Such mapping reveals insights into the derivation of propositional generalisations and discussion of the strengths and limitations of UFoI-E and STPA-Extension.
In the end, we propose a more comprehensive co-analysis framework to combine the UFoI-E method and STPA-Extension, which exploits their unique strengths and allow for a more complete and cost-effective safety and security co-analysis of cyber-physical systems.

Table 17
The stages of each method, their mutual correspondence, and potential for combination.Model the generic control structure of the system and refine it from analysis iterations -UFoI-E provides more level of detail to assist the analysts in drawing a comprehensive control structure of the CPS.
-In STPA-Extension, the system under analysis could be different from a CPS, so it is more generic in scope.
-In STPA-Extension, use the CPS master diagram to review the control structure of the CPS and refine it.Still, one can have the risk of adding too much detail too early.
(2) Analysis -In UFoI-E, the method assists the analysts to check how different energy sources in the system could lead to physical harm -In STPA-Extension, the sources of harm are inferred from the system level losses in a systematic way In STPA-Extension, a generic list of sources of hazards and types of accidents can help to find a more complete list of accidents and STPA hazards (2.2) Identification of deviations leading to unsafe system states Using the CyPHASS database: Selected for the specific system using the database of process variable and functional deviations (PV-F) at the physical layer, and from the uncontrolled flows of information (UFoI) at the cyber and cyber-physical layers.
Using STPA deviation guidewords: Inferred from inverting the control requirements into unsafe control actions (UCAs) -In UFoI-E, the conditions leading to harm are not uniquely associated with the actions of a controller.They can also be the result of sequential deviations in the performance of specific components of the system.
-In STPA-Extension, the analyst applies the deviation guidewords to each control action as a hierarchic process.Arguably, STPA-Extension assists the analysts in a deeper study of the control algorithm and process model of the controllers.
-In UFoI-E, enhance the CyPHASS database with an expanded checklist of CPL UFoI related to process models.The CyPHASS database has the capacity to learn from new inputs and expert feedbacks.
(2.3) Identification of risk sources leading to deviations Using the CyPHASS database: -Selected for the specific system using the databases of risk sources (hazards and threats) at each layer of the system Identification of causal factors at different sections of the control structure -In UFoI-E, the analyst can use the extensive checklists of hazards and threats derived from lessons learned and apply it to their specific CPS architecture.
-In STPA-Extension, the causal factors reach the level of generic risk sources, without further detail into underlying causes.For in-depth causal analysis, the analysts need to refer to other security analysis methods, e.g.attack trees.
-In STPA-Extension, use the CyPHASS database to complement the causal analysis of both unintentional and intentional causal factors, including explicit reliance on resources. (2.4)

Recommendations for system protection and countermeasures
Using the CyPHASS database: Selected for the specific system using the databases of prevention barriers against threats/hazards at each layer, as well as detection and response barriers for each deviation leading to harm.
Design decisions to prevent UCAs in the control structure (2.2).
-In UFoI-E, there is a comprehensive set of countermeasures to protect the system, using both prevention and mitigation strategies in the bowtie convention.

N/A
N.H.Carreras Guzman et al.

Fig. 4 .
Fig. 4. A Structured STPA Safety and Security Co-analysis framework (STPA-Extension).(Bold texts: describe the conventional STPA steps in details.Italics texts with underline: highlight the structured STPA co-analysis improvements to concretize the analysis steps).

Fig. 10 Fig. 7 .
Fig. 10 shows how CyPHASS traces and links the different scenarios that converge into a unique consequence.Moreover, this figure demonstrates how barriers allocated at different stages of the scenarios act as layers of protection.If a risk source breaches a prevention barrier and leads to an intermediate event, the mitigation barriers to the right may mitigate the consequences of the intermediate event.Furthermore, if an The estimated position and heading of a detected obstacle vo The estimated velocity of a detected obstacle τ Forces and moments vector Trajectory from η to η dx : The trajectory from the current position to the next point along the path Thruster eff.(s & p) Effort for the stern thrusters Thruster dir.(s & p) Direction for the stern thrusters

Fig. 8 .
Fig. 8. Tailored CPS master diagram of the ReVolt (emphasis on autonomous mode of operation).

Fig. 10 .
Fig. 10.Extract of three illustrative scenarios in CyPHASS, each with risk source origin at a different stage.
Identify the cases of UFoE that could lead to ultimate safety consequences Step 2: For each UFoE, identify the causes as PL PV-F deviations "Step 1:

Table 3
The ReVolt's operational scenario under analysis.
b Receive waypoint plan and destination from the human operator via an onshore control station 1) Another vessel collides with the ReVolt 2) The ReVolt drifts into other vessel or nearby structure 1.c Follow the waypoint plan to the destination while avoiding collision with detected vessels/obstacles 1) Another vessel collides with the ReVolt 2) The ReVolt collides with another vessel 3) The ReVolt collides with the nearby structure 1.d Reduce to zero speed at the destination 1) Another vessel collides with the ReVolt 2) The ReVolt drifts in other vessel or nearby structure 3)The ReVolt collides with nearby structure N.H.Carreras Guzman et al.

Table 5
Identified system-level losses a .
a COLREGs: Convention on the International Regulations for Preventing Collisions at Sea, 1972.N.H. CarrerasGuzman et al.

Table 6
System-level accident, hazard & constraints of the ReVolt.

Table 7
Functional requirements derived from constraint C1.

Table 8
Control structure analysis results.

Table 9
Six types of Unsafe Control Actions.

Table 11
Design-specific causes and initial causal factors for Causal scenario -1.

Table 12
Summary of causal scenarios analysis.

Table 14
Summary of relative completeness results.
Fig. 11.Relative completeness results in Venn diagram framework.N.H. Carreras Guzman et al.

Table 15
Illustrative examples comparing the results from the STPA-Extension and the UFoI-E analyses.