A Novel Method for Safety Analysis of Cyber-Physical Systems—Application to a Ship Exhaust Gas Scrubber System

: Cyber-Physical Systems (CPSs) represent a systems category developed and promoted in the maritime industry to automate functions and system operations. In this study, a novel Combinatorial Approach for Safety Analysis is presented, which addresses the traditional safety methods’ limitations by integrating System Theoretic Process Analysis (STPA), Events Sequence Identiﬁcation (ETI) and Fault Tree Analysis (FTA). The developed method results in the development of a detailed Fault Tree that captures the e ﬀ ects of both the physical components / subsystems and the software functions’ failures. The quantitative step of the method employs the components’ failure rates to calculate the top event failure rate along with importance metrics for identifying the most critical components / functions. This method is implemented for an exhaust gas open loop scrubber system safety analysis to estimate its failure rate and identify critical failures considering the baseline system conﬁguration as well as various alternatives with advanced functions for monitoring and diagnostics. The results demonstrate that conﬁgurations with SOx sensor continuous monitoring or scrubber unit failure diagnosis / prognosis lead to signiﬁcantly lower failure rate. Based on the analysis results, the advantages / disadvantages of the novel method are also discussed. This study also provides insights for better safety analysis of the CPSs.


Introduction
Cyber-Physical Systems (CPSs) represent a class of systems advancing in a number of application areas including the maritime industry [1]. The CPSs are expected to increase the productivity and safety levels by removing, substituting [2] and/or supporting the operator in the decision-making process, thus reducing the number of human errors leading to accidents [3]. Typical examples of the CPSs include the Industrial and automation Control Systems (ICS), robots, and Cyber-Physical Systems of Systems [4]. Examples of marine CPSs include the Power Management System, Propulsion engines, Heat Ventilation Air Conditioning systems and autonomous ships whose functions are supported by the CPSs [1].
Whilst CPSs are expected to bring significant benefits, they are considered to be complex, which implies that they may behave unpredictably [4][5][6]. Their complexity can be attributed to a number of the potential to identify the harmful effects of successful cyberattacks on CPSs [44]. However, the STPA needs enhancement with the inclusion of a quantitative step to support the decision-making process.
On the other hand, FTA is effective for capturing the dependencies between components and analysing the physical failures [45]. Potentially, FTA could be substituted using other methods; however, FTA is rather simple to be applied. In addition, the ETA exhibits strength in identifying the event sequences of the investigated system and identifying multi-point failures [46]. This is important in CPSs, as CPSs have the ability to reconfigure responding to specific fault or control commands. Potentially, Event Sequence Diagrams as reported in [47] could be used, but the ETA based method was selected herein, due to its formalism simplicity.
Hence, integrating these three methods and a quantitative approach to form a novel method is expected to improve the analysis rigour, through increasing the number of identified complex scenarios, capturing the dependencies between different component failures, more effectively capturing the software related failures and identifying the temporal relationship between different events in the system. In addition, it allows for the quantification of appropriate safety and criticality/importance analysis metrics, thus facilitating the generation of safety recommendations and enhancement processes.
The preceding considerations led to the development of the proposed method, known as "Combinatorial Approach for Safety Analysis" (CASA), which consists of ten steps. Whilst some of the method steps were presented in [48], they are elaborated and enhanced further in this study by including the quantitative part description and delineating the method steps. The method phases and steps are provided in Figure 1, whereas the steps' characteristics are summarised in Table 1. On the other hand, FTA is effective for capturing the dependencies between components and analysing the physical failures [45]. Potentially, FTA could be substituted using other methods; however, FTA is rather simple to be applied. In addition, the ETA exhibits strength in identifying the event sequences of the investigated system and identifying multi-point failures [46]. This is important in CPSs, as CPSs have the ability to reconfigure responding to specific fault or control commands. Potentially, Event Sequence Diagrams as reported in [47] could be used, but the ETA based method was selected herein, due to its formalism simplicity.
Hence, integrating these three methods and a quantitative approach to form a novel method is expected to improve the analysis rigour, through increasing the number of identified complex scenarios, capturing the dependencies between different component failures, more effectively capturing the software related failures and identifying the temporal relationship between different events in the system. In addition, it allows for the quantification of appropriate safety and criticality/importance analysis metrics, thus facilitating the generation of safety recommendations and enhancement processes.
The preceding considerations led to the development of the proposed method, known as "Combinatorial Approach for Safety Analysis" (CASA), which consists of ten steps. Whilst some of the method steps were presented in [48], they are elaborated and enhanced further in this study by including the quantitative part description and delineating the method steps. The method phases and steps are provided in Figure 1, whereas the steps' characteristics are summarised in Table 1.

Steps
Step Description Employed Technique Justification Required Resources Output Output to Steps

Initiation
Step 0: Preparation Accumulating system data: accidents investigations reports, previous hazards analyses, components failure rates, system simulations, etc.
Publications and accident investigation reports analysis Good understanding of system problems required for analysis Access to data Good understanding of the system All other steps

STPA
Step The first four steps (steps 1-4) are similar to the steps of the STPA method. In step 5, the ESI method is employed to develop the "Event Trees" by analysing the system and using the STPA results, thus obtaining insight into the system temporal behaviour and potential complex failures. Step 6 employs the developed "Event Trees" and synthesizes/transforms them into one Fault Tree. In step 7, the generated Fault Tree is populated with the results from the STPA. In step 8, this Fault Tree is further refined to address inconsistencies due to the integration of STPA and ESI results.
Step 9 expands on some physical failures identified by STPA (nodes of step 8 Fault Tree) by using the FTA to develop the final Fault Tree.
Step 10 includes the quantitative analysis that is needed for calculating the top event failure rate for the investigated system, as well as the importance analysis that provides metrics for the critical system components and failures. The CASA results are used to derive the safety recommendations for the system safety enhancement. The method steps have to be applied in a specified sequence; otherwise, the results will differentiate from CASA results.

Preparatory Step (Step 0)
This step involves the activities required to gather the information about the system and system hazards. This includes, if available, the system simulations using detailed models depicting the system behaviour and responses, previous hazard identification analyses, the study of the system operation and maintenance manuals, development and analysis of system experts' questionnaires and the analysis of previous accident investigation reports, as well as getting access to the failure rates databases for the system components.

STPA (Steps 1-4)
Step 1 (Figure 1) aims at accurately defining the targets of the whole analysis. The process starts with the accidents' identification for the investigated system. Based on the identified accidents, the relevant hazards are subsequently identified. Hazards in the STPA framework are understood as 'the system states or the set of conditions that together with a worst-case set of environmental conditions will lead to an accident' [49]. The hazard identification can be implemented either with the assistance of a hazard review by an individual or an expert teams' brainstorming. According to the STPA framework, only the hazards related to the accident under consideration are taken into account, which can be further broken down in sub-hazards [49]. Based on these hazards and sub-hazards, the safety constraints and requirements of the system design are identified. The list of existing control measures is used to augment the ESI implementation as explained in the next step.
Step 2 ( Figure 1) focuses on the development of the investigated system hierarchical control structure, which is one of the differentiating points of the STPA analysis compared with the other methods [49]. As shown in Figure 2, the process commences with a high-level system abstraction and proceeds to a more detailed level. The initial control structure consists of the high-level controller, the human operator and the controlled process with its basic control, feedback and communication links. A more detailed description incorporates the controllers' hierarchies. The final refined control structure includes the information on responsibilities of each controller, the process model with the process variables and their ranges, the control actions, the actuators' behaviour, the information provided by sensors and the interactions between the controllers. The development of a hierarchical control structure is influenced by the system identifying accidents and hazards. The analysis output from this step is expected to be in the form shown on the right-hand side of Figure 2. The previous steps are the STPA initial steps. The actual hazard identification process starts in step 3 as shown in Figure 1, having as an objective to identify the Unsafe Control Actions (UCAs) that lead to hazards. The possible UCAs are categorised into the following four types [50]:


Type 1: Not providing the control action that leads to a hazard.  Type 2: Providing a control action that leads to a hazard.  Type 3: A control action is untimely provided (too late, too early or out of sequence).  Type 4: A control action duration is not adequate (stopped too soon or applied for too long).
In addition, there is also the following UCA type: "a safe control action is provided but not followed"; however, this is considered equivalent to the Type 1 UCAs [50]. This type of failure mode is analysed during the identification of causal factors in the next paragraph.
For each control action, the potential process variables values are considered, and it is investigated whether the control action will lead to a hazard/sub hazard or not. Similarly, with the system hazard identification, safety constraints can be derived from the UCAs, aiding the identification of appropriate hazard control measures.
Step 4 includes the causal factors' identification and forms an essential step for the STPA ( Figure  1) as the causal factors explain why an UCA can occur. In this study, the process was augmented by the usage of a modified tree structure proposed in Blandine [51], which was enhanced by a list of causal factors from [52], and it is shown in Figure 3. This allows for the easy transition from the STPA results into a Fault Tree structure, as in this way the causal factors can be connected to the UCAs by using the OR gate of a Fault Tree. The UCAs are considered undeveloped events, and their causal factors are connected to these UCAs using OR gates. Practically, this step is very similar to the checklist procedures. The list of typical generic causal factors is given in Appendix A. Such a provision of this checklist is beneficial, as it supports the repeatability and objectiveness of the STPA results. In this study, the term "scenario" is not used according to STPA framework; instead, scenario is considered in a much wider context, as, for example, a generic hazardous scenario. The previous steps are the STPA initial steps. The actual hazard identification process starts in step 3 as shown in Figure 1, having as an objective to identify the Unsafe Control Actions (UCAs) that lead to hazards. The possible UCAs are categorised into the following four types [49]: • Type 1: Not providing the control action that leads to a hazard. • Type 2: Providing a control action that leads to a hazard. • Type 3: A control action is untimely provided (too late, too early or out of sequence). • Type 4: A control action duration is not adequate (stopped too soon or applied for too long).
In addition, there is also the following UCA type: "a safe control action is provided but not followed"; however, this is considered equivalent to the Type 1 UCAs [49]. This type of failure mode is analysed during the identification of causal factors in the next paragraph.
For each control action, the potential process variables values are considered, and it is investigated whether the control action will lead to a hazard/sub hazard or not. Similarly, with the system hazard identification, safety constraints can be derived from the UCAs, aiding the identification of appropriate hazard control measures.
Step 4 includes the causal factors' identification and forms an essential step for the STPA (Figure 1) as the causal factors explain why an UCA can occur. In this study, the process was augmented by the usage of a modified tree structure proposed in Blandine [50], which was enhanced by a list of causal factors from [51], and it is shown in Figure 3. This allows for the easy transition from the STPA results into a Fault Tree structure, as in this way the causal factors can be connected to the UCAs by using the OR gate of a Fault Tree. The UCAs are considered undeveloped events, and their causal factors are connected to these UCAs using OR gates. Practically, this step is very similar to the checklist procedures. The list of typical generic causal factors is given in Appendix A. Such a provision of this checklist is beneficial, as it supports the repeatability and objectiveness of the STPA results. In this study, the term "scenario" is not used according to STPA framework; instead, scenario is considered in a much wider context, as, for example, a generic hazardous scenario.

ESI (Step 5)
The Events Sequence Identification (ESI) commences after the STPA results have been derived (Figure 1Error! Reference source not found.). The methodology employed in the ESI is very similar o Event Tree Analysis (ETA) [46] and all the tools relevant to ETA are also used herein to ensure the identified scenarios completeness and to capture potential sequences of events in the investigated system. Each sub hazard/hazard is used as an initiating event and the propagation of sub hazards/hazards into a hazard or an accident is investigated by considering: (a) the protective barriers designed to mitigate the sub hazards/hazards consequences; (b) the relevant system states; and (c) the identified UCAs from the previous step. The 'Event Trees' are considered fully developed when all the outcomes end at either the safe condition, another sub hazard/hazard, or the investigated hazard/accident. It was assumed that the events' duration has no effect on the identified event sequences, but it affects the probability of each selected branch and consequently the specific states' calculation (described in Section 2.6).
Despite the similarities between the ESI and the ETA, the following differences exist (justifying the method name): (a) the ESI analysis is completely internal to the system compared to the ETA, which can be external to the investigated system; (b) the ESI does not incorporate the calculation of the protective barriers' failure probability, and it is implemented only qualitatively; (c) the ESI outcome is not necessarily an accident but can be a hazard at the system level (the ESI corresponds to the left side of the classical Bow Tie, in comparison to the ETA that corresponds to the part on the right of the bow tie); (d) hence, no estimation of risk is provided by the ESI; (e) the ESI along with the STPA results are used to develop a Fault Tree as described in the next section. It must be noted that the introduction of the ESI term was followed for distinguishing between the two methods (ESI and ETA).

STPA and ESI Results' Integration (Steps 6-8)
Since not all sub hazards/hazards lead directly to the system hazard/accident and some interactions exist between the various sub hazards/hazards, the developed "Event Trees" are restructured in step 6 of the proposed method (Figure 1), so that the investigated sub

ESI (Step 5)
The Events Sequence Identification (ESI) commences after the STPA results have been derived ( Figure 1). The methodology employed in the ESI is very similar to Event Tree Analysis (ETA) [46] and all the tools relevant to ETA are also used herein to ensure the identified scenarios completeness and to capture potential sequences of events in the investigated system. Each sub hazard/hazard is used as an initiating event and the propagation of sub hazards/hazards into a hazard or an accident is investigated by considering: (a) the protective barriers designed to mitigate the sub hazards/hazards consequences; (b) the relevant system states; and (c) the identified UCAs from the previous step. The 'Event Trees' are considered fully developed when all the outcomes end at either the safe condition, another sub hazard/hazard, or the investigated hazard/accident. It was assumed that the events' duration has no effect on the identified event sequences, but it affects the probability of each selected branch and consequently the specific states' calculation (described in Section 2.6).
Despite the similarities between the ESI and the ETA, the following differences exist (justifying the method name): (a) the ESI analysis is completely internal to the system compared to the ETA, which can be external to the investigated system; (b) the ESI does not incorporate the calculation of the protective barriers' failure probability, and it is implemented only qualitatively; (c) the ESI outcome is not necessarily an accident but can be a hazard at the system level (the ESI corresponds to the left side of the classical Bow Tie, in comparison to the ETA that corresponds to the part on the right of the bow tie); (d) hence, no estimation of risk is provided by the ESI; (e) the ESI along with the STPA results are used to develop a Fault Tree as described in the next section. It must be noted that the introduction of the ESI term was followed for distinguishing between the two methods (ESI and ETA).

STPA and ESI Results' Integration (Steps 6-8)
Since not all sub hazards/hazards lead directly to the system hazard/accident and some interactions exist between the various sub hazards/hazards, the developed "Event Trees" are restructured in step 6 of the proposed method (Figure 1), so that the investigated sub hazards/hazards' propagation is identified. Subsequently, the ESIs are transformed into a Fault Tree by connecting the events in a Safety 2020, 6, 26 9 of 31 hazardous sequence using AND gates as shown in Figure 4 using exemplificatory "Event Trees". The different scenarios resulting in the same hazard/accident are connected using the OR gates ( Figure 4). The paths from a sub hazard/hazard to another sub hazard/hazard are connected using OR gates ( Figure 4). As a result, a preliminary Fault Tree is developed, which is enriched and refined in the next steps of the proposed method. This is an important difference between the proposed approach for employing the ESIs' "ETs" to develop an FT and the typical approach, according to which FTA is used to model the causes identified in ETA. In this way, accident becomes a top event in the Fault Tree, which is rather uncommon. However, accidents/hazards were used as the Fault Tree top events or nodes in BBN in the pertinent literature, as reported in [32,52]. ISO 31010 allows for using a broader outcome of a specific failure as the top event [46]. hazards/hazards' propagation is identified. Subsequently, the ESIs are transformed into a Fault Tree by connecting the events in a hazardous sequence using AND gates as shown in Figure 4 Error! eference source not found.using exemplificatory "Event Trees". The different scenarios resulting in the same hazard/accident are connected using the OR gates ( Figure 4). The paths from a sub hazard/hazard to another sub hazard/hazard are connected using OR gates ( Figure 4). As a result, a preliminary Fault Tree is developed, which is enriched and refined in the next steps of the proposed method. This is an important difference between the proposed approach for employing the ESIs' "ETs" to develop an FT and the typical approach, according to which FTA is used to model the causes identified in ETA. In this way, accident becomes a top event in the Fault Tree, which is rather uncommon. However, accidents/hazards were used as the Fault Tree top events or nodes in BBN in the pertinent literature, as reported in [32,53]. ISO 31010 allows for using a broader outcome of a specific failure as the top event [46]. In step 7 (Figure 1), the preliminary Fault Tree is enriched by using the derived STPA results. This is implemented in two stages. First, the UCAs are related to the branches in the ESI "Event Trees" (and, consequently, the events of the preliminary Fault Tree). These UCAs are connected to the event In step 7 (Figure 1), the preliminary Fault Tree is enriched by using the derived STPA results. This is implemented in two stages. First, the UCAs are related to the branches in the ESI "Event Trees" (and, consequently, the events of the preliminary Fault Tree). These UCAs are connected to the event in a Fault Tree using an OR gate. Subsequently, for each UCA, the causal factors are developed under the UCAs with an OR gate. An example for the implementation of this step is shown in Figure 5 using exemplificatory UCAs for accident (scenario 2). in a Fault Tree using an OR gate. Subsequently, for each UCA, the causal factors are developed under the UCAs with an OR gate. An example for the implementation of this step is shown in Figure 5 using exemplificatory UCAs for accident (scenario 2). The Fault Tree developed in step 7 is not accomplished by populating the Fault Tree with the UCAs and the causal factors as inconsistencies may arise due to the fact that the results from the two different methods are merged into one structure. Therefore, the developed Fault Tree further refinement takes place in Step 8 ( Figure 1). This step also takes into account the system architecture and the common causal factors. The conditions and applied actions for the FT refinement are described in Table 2. These conditions were identified from method application to other systems, as it is reported for example in [48]. An applied refinement example is provided in Figure 6, where UCA 1 is split into the UCA 1 representing its causal factors and the system state (in which UCA 1 occurs); UCA2 is split into UCA 2 representing its causal factors and the system fault (with which it occurs), whereas the common causal factor for UCA 3 and UCA 4 is 'upgraded' to a higher level in Fault Tree (the same level as other UCAs). The refinement is required to ensure that the OR and AND gates' calculation involves non repeated and independent events. Special refinement is applied when a UCA is connected by using OR gates or AND gates. In the former case (UCA connected using OR gates), the common causal factor is propagated to the UCA level, whereas, in the latter case (UCA connected using AND gates), the common causal factor is propagated even to a higher level in the Fault Tree moving from the basic events to the top event. This special refinement for the integration of the methods is an important novel aspect of this method. The Fault Tree developed in step 7 is not accomplished by populating the Fault Tree with the UCAs and the causal factors as inconsistencies may arise due to the fact that the results from the two different methods are merged into one structure. Therefore, the developed Fault Tree further refinement takes place in Step 8 ( Figure 1). This step also takes into account the system architecture and the common causal factors. The conditions and applied actions for the FT refinement are described in Table 2. These conditions were identified from method application to other systems, as it is reported for example in [48]. An applied refinement example is provided in Figure 6, where UCA 1 is split into the UCA 1 representing its causal factors and the system state (in which UCA 1 occurs); UCA2 is split into UCA 2 representing its causal factors and the system fault (with which it occurs), whereas the common causal factor for UCA 3 and UCA 4 is 'upgraded' to a higher level in Fault Tree (the same level as other UCAs). The refinement is required to ensure that the OR and AND gates' calculation involves non repeated and independent events. Special refinement is applied when a UCA is connected by using OR gates or AND gates. In the former case (UCA connected using OR gates), the common causal factor is propagated to the UCA level, whereas, in the latter case (UCA connected using AND gates), the common causal factor is propagated even to a higher level in the Fault Tree moving from the basic events to the top event. This special refinement for the integration of the methods is an important novel aspect of this method.

FTA (Step 9)
According to the STPA results, some of the hazardous situations are related to a combination of a control action and a system state, which in turn is caused by a physical failure. For the cases where this system state is attributed to a number of a subsystem physical components failures, FTA is employed to identify these components' failures ( Figure 1). The top event in the FTA is taken as the system state from the relevant UCA (a high level physical failure) and the causes are identified by: (a) breaking down the subsystem into components; (b) assessing which component failure will lead to the top event of the local FTA, and; (c) considering the functional dependencies between the identified components. The identification of components failures leading to the top failure can be supported by considering the conditions under which the safety functions in specific components are activated. This step requires much more detailed information about the investigated subsystem and its components dependencies, as well as the subsystem components' specific failures. The different components' failures are connected using OR gates. If the same components are connected in parallel, their failures are connected to other failures using AND gates. If some of the components have identical standby components, then these components failures are connected using OR gates, but special treatment is provided for estimating its probability of failure as described in the next section. The developed Fault Tree in this step is connected to the previous steps Fault Tree (as shown in Figure 6), resulting in a more detailed Fault Tree, linked to the investigated system components' failures, which can be used for the purposes of the Quantitative Analysis (QA) described in the next section.

Quantitative Analysis (Step 10)
The purpose of the QA is to support the decision-making process and the safer systems design [22,53]. The approach followed in this study is probabilistic based and the QA output includes the calculation of top event failure rate λ TE . The λ TE due to its linear connection to the frequency of events, which is used as a risk metric [54]. The top event failure rate is considered to be a more representative metric, as it corresponds to the investigated event and, therefore, historical data for its frequency can be retrieved through the number of the reported accidents. In this respect, ambiguous and computationally expensive calculations of the top event frequency (for example, by employing Markov chains) can be avoided. In addition, this step includes a importance analysis to identify the system critical failures.
The following assumptions were made for the QA purposes: • The basic events in the Fault Tree can be grouped to three categories: (a) the operating system components failures (p oc i ); (b) the safety systems failures (p ss i ) (it must be noted that the safety systems function is to control and handle the operating system components failures); and (c) specific system states, for example overloading of the generation sets (p sss i ).

•
The considered systems components' failure rates follow an Exponential failure probability distribution.

•
The inspection of the system components is performed according to the manufacturers' guidelines and can effectively detect the system components' condition including their failures and degradation level.

•
The implemented maintenance practice for the systems components is according to the manufacture guidelines and restores the system components to the best possible condition (repairing their detected faults and mitigating their degradation). The maintenance intervals of the system components are considered to be timely as proposed by the respective manufacturers.

•
The duration of testing and duration of repairs of faults detected during testing have negligible impact on the availability of the standby components or the components implementing safety functions.

•
The top event probability differential can be adequately approximated by employing the respective difference considering a relatively small time interval, which was taken as 1 h.
The failure rate for the top event λ TE is estimated using the following approximation based on the failure rate definition [55]: λ TE = P[ f ailure occurs between t and t + dt no prior f ailure] where P TE denotes the top event probability, which is derived from the Fault Tree (from Step 9) (an example is shown in Figure 6) by applying the specific calculation rules for the Fault Tree gates. The following equation is employed to calculate the probability outcome of an OR gate with z input events (E z ) [56]: The following equation is employed to calculate the probability outcome of an AND gate with z input events (E z ) [56]: The equations used for the calculation of the basic events probability P E j (for the basic event E j of the Fault Tree), which were derived considering the event type and the assumptions presented previously, are provided below. The required input parameters include the number of the redundant components, the components' maintenance and testing intervals (T i ), the maintenance repair rates (µ i ), the components failure rates (λ i ), and the probability of failure on demand for the software components (PFD i ).
For software, hardware, communication, and sensors' failures (based on [55,56]): For tested cold standby equipment failure on demand (except for software failures) (based on [55,56]): For safety system/functions with continuous monitoring failure on demand (based on [55,56]): For software failures in safety functions (based on [55,56]): The Birnbaum's importance measure (I B j ) [56], which is approximated according to Equation (8), is employed for the basic events importance analysis. This metric can be used to identify the components with a significant impact on the top event failure rate λ TE . In such cases, an improvement of the respective failure rates/probability can result in reducing the λ TE . In addition, this metric can be used to identify components having a structural importance or occupying important locations of the Fault Tree for the investigated system [57]. It depends on the quality of the developed Fault Tree, which is used for the calculation of the top event failure rate: The Fussell-Vesely importance measure (I FV j ), which is approximated according to Equation (9), is another metric that is employed in this study for facilitating the system importance analysis [56][57][58]. Based on this metric, the system components, the failure of which will most probably lead to the undesired event are identified [59]: Safety 2020, 6, 26 14 of 31

System Description and Analysis Input
For the application and demonstration of the proposed method, a rather simple industrial control system (ICS) has been selected, in particular, an open loop exhaust gas scrubber system. This can be considered as a simple example of CPSs, as it consists of a Programmable Logic Controller, the relevant actuators and physical components (pumps, scrubber unit, valves, etc.), and sensors for controlling the cleaning of exhaust gases.
The main purpose of the exhaust gas scrubber is to reduce the SOx emissions from the exhaust gas of the ship main engine and auxiliary engines when operating by burning High Sulphur Heavy Fuel Oil (HSHFO). The exhaust gases coming from the ship main and auxiliary engines are sprayed by injecting sea water within the scrubber. The sea water has a slightly higher pH (8) and, therefore, it will react with the SOx dissolved in the injected sea water. The main components of the open loop exhaust gas scrubber system are demonstrated in Figure 7 [60]. For the application and demonstration of the proposed method, a rather simple industrial control system (ICS) has been selected, in particular, an open loop exhaust gas scrubber system. This can be considered as a simple example of CPSs, as it consists of a Programmable Logic Controller, the relevant actuators and physical components (pumps, scrubber unit, valves, etc.), and sensors for controlling the cleaning of exhaust gases.
The main purpose of the exhaust gas scrubber is to reduce the SOx emissions from the exhaust gas of the ship main engine and auxiliary engines when operating by burning High Sulphur Heavy Fuel Oil (HSHFO). The exhaust gases coming from the ship main and auxiliary engines are sprayed by injecting sea water within the scrubber. The sea water has a slightly higher pH (8) and, therefore, it will react with the SOx dissolved in the injected sea water. The main components of the open loop exhaust gas scrubber system are demonstrated in Figure 7 Table 3. The exhaust gas scrubber control system can shut down the scrubber operations by closing the valves and switching off the sea water pumps. It also regulates the sea water flow rate and operating status of the sea water pumps based on the estimation of the fuel flow of the ship main and auxiliary engines. The process is supervised by the crew, which can implement switching over to a fuel with a low sulphur content if the exhaust gas SOx emissions exceed the acceptable limits. As an optional functionality, the exhaust gas scrubber control system could monitor the health status of the scrubber unit and predict its failures. In such a case, it is assumed that all the scrubber unit failures can be handled by the ship crew by switching over to a low Sulphur fuel. For the sake of the case study, it is considered that the scrubber unit failures as well as the SOx emissions sensor are not monitored by the alarm monitoring system, so the crew is not aware of the specific failures in order to switch off the scrubber system. It is also assumed that the crew can only mitigate the system hazards, but do not introduce the new hazards, so the crew cannot inadvertently switch off the exhaust gas scrubber system when the ship engines operate using HFO.  Table 3. The exhaust gas scrubber control system can shut down the scrubber operations by closing the valves and switching off the sea water pumps. It also regulates the sea water flow rate and operating status of the sea water pumps based on the estimation of the fuel flow of the ship main and auxiliary engines. The process is supervised by the crew, which can implement switching over to a fuel with a low sulphur content if the exhaust gas SOx emissions exceed the acceptable limits. As an optional functionality, the exhaust gas scrubber control system could monitor the health status of the scrubber unit and predict its failures. In such a case, it is assumed that all the scrubber unit failures can be handled by the ship crew by switching over to a low Sulphur fuel. For the sake of the case study, it is considered that the scrubber unit failures as well as the SOx emissions sensor are not monitored by the alarm monitoring system, so the crew is not aware of the specific failures in order to switch off the scrubber system. It is also assumed that the crew can only mitigate the system hazards, but do not introduce the new hazards, so the crew cannot inadvertently switch off the exhaust gas scrubber system when the ship engines operate using HFO. The failure rates used as input for this analysis and their sources are provided in Table 4. The inspection and testing of the SOx sensor and the standby pump are considered to be implemented every 5000 h, in line with the system maintenance manual [61]. The analysis in this study investigated the exhaust gas open loop system shown in Figure 7 considering the following functionalities and alternative configurations: (a) regular testing of the SOx emissions sensor (without continuous monitoring); (b) continuous monitoring of the SOx emissions sensor (the SOx emissions sensor failure/erroneous measurements are immediately identified using advanced diagnostic techniques); (c) when scrubber unit failures (Scrubber body, piping, droplet, venturi, injection nozzles) are monitored using diagnostic/prognostic techniques and immediately diagnosed; and (d) with two installed SOx emissions' sensors. (Steps 1-4) A number of accidents and hazardous scenarios that can arise in the investigated exhaust gas scrubber system are provided in Table 5 (results of step 1) (derived based on previous studies [42,43] and own analysis). As it can be observed, despite the fact that the system is simple and non-safety-critical, a number of accidents and hazards can occur, which may result in human injury or death, as well as damage to equipment or environment. The analysis in the CASA method subsequent steps will focus on the environmental pollution [A-3] and specifically on [H-5] (Exhaust gas not complying with regulatory requirements.), as this study scope is to demonstrate the functionality of the CASA method. As elaborated in Sections 1 and 3, the proper spraying of exhaust gas is an important scrubber function and its failure may result in environmental pollution and strict financial penalties. The hazard [H-5] is used for the development of the hierarchical control structure (step 2) and the identification of the UCAs (step 3). SOx sensor Sea water analysers

STPA Results
The system control structure (results of step 2) is provided in Figure 8. It can be observed that the control loop incorporates two controllers, the scrubber control system and the human operator. The scrubber controller uses as input the ship engines fuel flow to control the pumps' operating status, the sea water flow and the control valves' status. The crew can implement the fuel change command and switch off the scrubber, in cases where the measured SOx emissions exceed the regulatory threshold. In cases where a provisional functionality is available in the scrubber controller for monitoring the scrubber body failures based on pressure measurements, then the crew can immediately implement the fuel change to a low Sulphur fuel, when scrubber body failure occurs. Measuring the discharged sea water pH is also an important measure to ensure that the discharged sea water is in compliance with the environmental regulations. However, since this measure is not relevant to [H-5], it is not included in the hierarchical control system. The hierarchical control structure is used for the identification of the UCAs (step 3) and their causal factors (step 4). 2020, 7, x FOR PEER REVIEW 18 of 30 The list of identified Unsafe Control Actions (UCAs) is provided in Table 6 (results of step 3). In total, 10 UCAs were identified for the system hazard [H-5]. The 10th identified UCA is applicable only if a new functionality performing the exhaust gas scrubber unit health diagnosis/prognosis is employed (case c as described in Section 3). The identified UCAs are found to be of Type 1 (not provided), Type 2 (provided), or Type 3 (provided too early/late/out of sequence). This is attributed to the fact that mostly discrete control actions, such as start, open, or close are considered. Thus, Type 4 UCA (stopped too soon/applied for too long) for many of the identified UCAs can be considered as equivalent to Type 1 UCAs; for example, a start pump stopped too soon would be equivalent to not providing a control action (not starting the pump) in its final effect, leading to the specific hazard. Type 4 UCA, instead, is more applicable if the control action exhibits some variation in its effect, as in the case of the PID controllers, where overshoots can occur. However, in this particular case, they are either covered by other UCA Type or do not lead to the investigated hazard. Based on the UCAs shown in Table 7, their causal factors are identified (step 4). The UCAs are also used to support the 'Event Trees' development (step 5) as well as in step 7 to enrich the Fault Tree developed in step 6. The UCAs are also utilised to indicate which physical failures might need further elaboration in step 9. The list of identified Unsafe Control Actions (UCAs) is provided in Table 6 (results of step 3). In total, 10 UCAs were identified for the system hazard [H-5]. The 10th identified UCA is applicable only if a new functionality performing the exhaust gas scrubber unit health diagnosis/prognosis is employed (case c as described in Section 3). The identified UCAs are found to be of Type 1 (not provided), Type 2 (provided), or Type 3 (provided too early/late/out of sequence). This is attributed to the fact that mostly discrete control actions, such as start, open, or close are considered. Thus, Type 4 UCA (stopped too soon/applied for too long) for many of the identified UCAs can be considered as equivalent to Type 1 UCAs; for example, a start pump stopped too soon would be equivalent to not providing a control action (not starting the pump) in its final effect, leading to the specific hazard. Type 4 UCA, instead, is more applicable if the control action exhibits some variation in its effect, as in the case of the PID controllers, where overshoots can occur. However, in this particular case, they are either covered by other UCA Type or do not lead to the investigated hazard. Based on the UCAs shown in Table 7, their causal factors are identified (step 4). The UCAs are also used to support the 'Event Trees' development (step 5) as well as in step 7 to enrich the Fault Tree developed in step 6. The UCAs are also utilised to indicate which physical failures might need further elaboration in step 9. The causal factors list for the identified UCAs is provided in Table 7 (step 4). In total, 26 causal factors are identified. For the majority of the UCAs, software failures are considered as causal factors. In this study, software failure refers to all those conditions, which may lead to the controller inability to implement a specific function due to errors in the software design, integer overflows, software bugs, communication errors in the controller, etc. They are treated as software failure because the available statistical data does not offer their further description. The human error depicts the failure of the human operator to act as a protective barrier. The human error was also treated on a high-level based on the relevant statistical data reported in IEC 61511 [66]. The identification of human failure causes is out of the scope of this research. The results of this step are used in step 7 to enrich the Fault Tree developed in step 6.

ESI Results (Step 5)
The "Event Tree" derived by applying the ESI for the hazard [H-5] is provided in Figure 9, which also depicts the relations between the UCAs and the different events of "Event Tree". As it is deduced from this figure, the UCAs support the development of the "Event Tree". When the exhaust gas system operation does not comply with the emission regulations ([H-5]), the SOx emissions sensor provides an alarm. This can be used from the crew to switch the engine operation to the low sulphur fuel usage and simultaneously to switch off the scrubber system. If crew fails to do that, the first hazardous scenario occurs. If the SOx sensor is faulty, then the crew will be unaware of potential noncompliance with the emissions' regulations (scenario 2). The developed "Event Tree" will be converted to a Fault Tree in the next step (step 6). Human error 10 Software failure, inconsistent physical model, pressure sensor errors

ESI Results (Step 5)
The "Event Tree" derived by applying the ESI for the hazard [H-5] is provided in Figure 9, which also depicts the relations between the UCAs and the different events of "Event Tree". As it is deduced from this figure, the UCAs support the development of the "Event Tree". When the exhaust gas system operation does not comply with the emission regulations ([H-5]), the SOx emissions sensor provides an alarm. This can be used from the crew to switch the engine operation to the low sulphur fuel usage and simultaneously to switch off the scrubber system. If crew fails to do that, the first hazardous scenario occurs. If the SOx sensor is faulty, then the crew will be unaware of potential noncompliance with the emissions' regulations (scenario 2). The developed "Event Tree" will be converted to a Fault Tree in the next step (step 6).

STPA and ESI Results Integration (Steps 6-8), FTA Results (Step 9)
Since the investigated system is simple, there are no interactions between the different developed "Event Trees". By transforming the "Event Tree" (Figure 9) (step 6) and enriching it with the results of STPA (step 7), the Fault Tree shown in Figure 10 is generated. As the causal factors are given in Table 7, these causal factors were not developed further in Figure 10. The developed Fault Tree includes the two scenarios leading to environmental pollution, inheriting the structure of the "Event Tree" from Figure 9. This Fault Tree is refined further in step 8.

STPA and ESI Results Integration (Steps 6-8), FTA Results (Step 9)
Since the investigated system is simple, there are no interactions between the different developed "Event Trees". By transforming the "Event Tree" (Figure 9) (step 6) and enriching it with the results of STPA (step 7), the Fault Tree shown in Figure 10 is generated. As the causal factors are given in Table 7, these causal factors were not developed further in Figure 10. The developed Fault Tree includes the two scenarios leading to environmental pollution, inheriting the structure of the "Event Tree" from Figure 9. This Fault Tree is refined further in step 8. If we ignore steps (5-6), the Fault would be developed by connecting all the UCAs by OR gate. In the hypothetical case, all the UCAs (UCAs 1-10) were connected using the OR gate, then either 'Closing valves during normal operation/faulty conditions will restrict the scrubber functionality [H-5]' (UCA 1) or 'Not changing fuel during faulty operation of the scrubber [H-5]' (UCA10) would lead to the hazard [H-5], which is noncompliance with regulations. However, it is known from experience that these two UCAs must occur at the same time (there is a need for AND gate). Potentially, it would be possible to identify this relationship using the safety analyst experience. Nonetheless, using the ESI adds rigor to the analysis; hence, ESI was included in the CASA method.
After applying the refinement rules provided in Table 2 (step 8), the Fault Tree shown in Figure  11 is developed. As shown in Figure 11, the refinement was applied to UCAs 1-3 and 5-7 context (refinement rule 1, Table 2) and for the common causal factors to UCA 5 and 7 (erroneous measurement of fuel flow) (refinement rule 4, Table 2). The system is rather simple; hence, no other refinements were required. In more complex systems, such as the system analysed in [48], more refinement rules would be applicable. The Fault Tree of step 8 is enriched with the results of FTA for physical failures, thus providing the finally developed Fault Tree (shown in Figure 10), which is the output of the CASA method qualitative analysis. The FTA (step 9) is applied to the scrubber system to identify the components that may fail. Only five scrubber unit components have been considered in the analysis. The results of the FTA are also provided in Figure 11. The results of FTA are similar to the structural breakdown of the scrubber unit. The final Fault Tree depicted in Figure 11 is used for the purpose of quantitative analysis (step 10). The results for the cases a-d are almost identical. There is no difference in structure for cases a and b. The location of the optional functionality for case (c) is also provided in the modified Fault Tree in Figure 11. For case (d), instead of one sensor, two sensors are provided. If we ignore steps (5)(6), the Fault would be developed by connecting all the UCAs by OR gate. In the hypothetical case, all the UCAs (UCAs 1-10) were connected using the OR gate, then either 'Closing valves during normal operation/faulty conditions will restrict the scrubber functionality [H-5]' (UCA 1) or 'Not changing fuel during faulty operation of the scrubber [H-5]' (UCA10) would lead to the hazard [H-5], which is noncompliance with regulations. However, it is known from experience that these two UCAs must occur at the same time (there is a need for AND gate). Potentially, it would be possible to identify this relationship using the safety analyst experience. Nonetheless, using the ESI adds rigor to the analysis; hence, ESI was included in the CASA method.
After applying the refinement rules provided in Table 2 (step 8), the Fault Tree shown in Figure 11 is developed. As shown in Figure 11, the refinement was applied to UCAs 1-3 and 5-7 context (refinement rule 1, Table 2) and for the common causal factors to UCA 5 and 7 (erroneous measurement of fuel flow) (refinement rule 4, Table 2). The system is rather simple; hence, no other refinements were required. In more complex systems, such as the system analysed in [48], more refinement rules would be applicable. The Fault Tree of step 8 is enriched with the results of FTA for physical failures, thus providing the finally developed Fault Tree (shown in Figure 10), which is the output of the CASA method qualitative analysis. The FTA (step 9) is applied to the scrubber system to identify the components that may fail. Only five scrubber unit components have been considered in the analysis. The results of the FTA are also provided in Figure 11. The results of FTA are similar to the structural breakdown of the scrubber unit. The final Fault Tree depicted in Figure 11 is used for the purpose of quantitative analysis (step 10). The results for the cases a-d are almost identical. There is no difference in structure for cases a and b. The location of the optional functionality for case (c) is also provided in the modified Fault Tree in Figure 11. For case (d), instead of one sensor, two sensors are provided.

Quantitative Analysis (Step 10)
The results of estimating the top event failure rate by considering the different system functionalities (cases (a) to (d) as described in Section 3) are provided in Table 8. The results of the importance analysis (cases (a) to (d) as described in Section 3) are provided in Table 9. Only the five top failures according to each metric and system functionalities are demonstrated. The results of importance analysis are presented in a reduced ranking order, proceeding from the most critical to the least critical failures according to each importance measure. As it can be deduced from the derived Birnbaum metric values for case a, the top event failure is sensitive to the scrubber components failures and various software failures in the system with the regular SOx sensor testing (case a). The top event failure rate will emanate from the SOx sensor failure and some scrubber unit failures as well as the scrubber controller software failure according to Fussell-Vesely metric for case a. Therefore, the system safety performance can be improved if safety measures to address the SOx emissions sensor failure are implemented.
As it can be observed from Table 8, the implementation of continuous monitoring and diagnosis of the SOx sensor failures (case b) instead of regular testing of SOx sensor will lead to significant decrease in top event failure (several orders of magnitude). However, the human error becomes a more critical failure according to the calculated Fussell-Vesely metric ( Table 9). The scrubber and controller failures still remain critical failures with this additional system function. Therefore, to enhance the system safety performance further, it is required to provide information for the system conditions to support the crew in making decisions.
Instead, the application of diagnosis/prognosis techniques for the scrubber failure leads to approximately 27% reduction in the top event failure rate as depicted in Table 8 (case c). In case c, the system top failure rate also becomes sensitive to failures of the sensors used to control the sea water flow ( Table 9). The most probable cause of the system failure according to the Fussell-Vesely metric remains the SOx sensor failure and various scrubber components' failures (Table 9). Thus, with this system functionality, system safety enhancement will occur when redundancy to the SOx emissions sensor measurements is provided.
Installation of two SOx sensors (instead of one) also results in a significant reduction of the top event failure rate (an order of magnitude) ( Table 8). In case d, the failure of the SOx sensors (both fail) still remain critical, but their criticality is reduced compared to the case with the regular SOx sensor failure ( Table 9). The other importance analysis results are similar to the previous cases importance analysis results. Thus, the system safety in case c can be enhanced by closely monitoring the scrubber unit components for detecting failures.
Based on the presented results, it can be concluded that the exhaust gas open loop scrubber system compliance with the SOx emission regulations can be enhanced when functionality of the SOx emissions sensor is continuously monitored or two SOx emissions sensors (redundancy) are installed. The scrubber unit components' failures seem to be critical for the normal system operation. The installation of diagnosis/prognosis technologies will lead to the system design improvement, however not as effectively as the installation of continuous monitoring system for the SOx sensor failures or an additional SOx emissions' sensor. If diagnosis/prognosis techniques are employed, then the top event failure rate will become sensitive to other failures such as in fuel flow sensors, so redundancy in fuel measurements would be recommended. However, the cost-effectiveness of the suggested measures is outside the scope of present study.

Discussion on the Method
To the best knowledge of the authors, no article or conference paper providing results from scrubbers' safety analyses is currently available. Only two theses (master and bachelor) have been identified focusing on this type of system safety analysis [42,43]. Comparing these studies' results with the results derived in the present study is challenging due to the differences in the considered systems, the experience level of the involved safety analysts and used input data.
Nevertheless, it can be observed that the considered top events in the systems in these studies [42,43] are rather slightly different from the top event of the present study. In the present study, the top event was the noncompliance with the regulations, whilst in the investigated master theses one of the Fault Trees top events was improper treatment of exhaust gases ( Figure 11). However, it can be observed that the Fault Tree derived by the CASA method incorporated the SOx emissions' sensor failure at a much higher level connected to other events using an AND gate, highlighting its criticality. In the other studies Fault Trees [42,43], the SOx sensor failure was not included. Therefore, the present analysis considered more failures related to the top event. This can be attributed to the inclusion of the STPA and ESI results. STPA is a top-down approach, which guides the analysis of specific undesired events (called accidents in the STPA framework) and system states (hazards) rather than of system component failures. The ESI results can be used to demonstrate how the hazards propagate to accidents; the SOx sensors' failure appeared in the Fault Tree (Figure 9) based on this approach. Human failure was also incorporated in the present analysis. However, it was out of the analyses scope reported in [42,43].
In addition, several software failures were not considered in these analyses, whereas they are considered in the present study, such as 'scrubber control system not increasing sea water flow/decreasing sea water flow in the system' or 'scrubber control system shutting down the system'. These need to be included in the analysis, as they contribute to the improper treatment of the exhaust gases. Based on that, it can be argued that, thanks to incorporation of the STPA results, new scenarios are considered in the Fault Tree structure. Therefore, it could be claimed that the proposed CASA method guides a more accurate safety analysis, which incorporates software failures, addressing the software-intensive character of the modern ICS and CPSs.
In addition, the refinement, which was applied to the identified UCAs, allowed for the better consideration of the temporal system behaviour. To be specific, the consideration of probability of UCA context, such as 'significant power increase' allowed for the incorporation of cases where a specific UCA can become hazardous and their consideration in the analysis quantitative step. This is often a case for ICS, as specific control actions become hazardous only in specific system context [16].
The structure of the final Fault Tree developed in step 9 of this study is different from the Fault Trees presented in other studies FTA [42,43], which can be considered as the open-loop scrubber system breakdown. In addition, they also incorporated the failures during the system start-up. In this way, failures that can occur at different operating phases without any relation were incorporated in one Fault Tree [42,43]. This is not true in the actual system operation, as a number of factors must occur simultaneously or in a sequence, in order for a top event to occur in modern CPSs. In the present study Fault Tree, there is a logical sequence of events, which is depicted using AND gates as connectors. For instance, a failure in scrubber system together with the SOx emissions' sensor failure must occur, so that the system is noncompliant with the existing SOx regulations. Therefore, it can be argued that the presented Fault Tree, thanks to the ESI, more effectively considered the system multi-points failures and temporal character.
The method allowed for the comparison of the system behaviour using quantitate metrics in cases where advances monitoring/diagnostics functionalities were considered. It was demonstrated that, when including diagnosis/prognosis techniques or the SOx emissions, sensor failures' continuous monitoring settings change the system safety performance significantly, overcoming this STPA limitation. This can be useful when considering the implementation of new functions in system or design alternatives during the system design phase.
Based on the above, it is demonstrated that the proposed novel CASA method's main advantage is the development of a Fault Tree of greater accuracy in comparison with the Fault Tree that can be derived using the classical FTA. The classical FTA may result in inaccuracies if applied to a modern CPS. The CASA method incorporates a wider system context, considers the software failures, thus addressing the CPSs software-intensive character of CPSs, and incorporates the system temporal behaviour in the Fault Tree thanks to the inclusion of the ESI approach. The incorporation of the system temporal aspects is an advantage compared to other studies using FMEA [29], FTA [30,31], Bayesian Networks [32], and STPA [34][35][36][37][38].
Compared to the STPA, the CASA method included the estimation of the safety and importance metrics, thus supporting a financial resources' prioritisation for addressing the system safety enhancement. The importance metrics estimation is an advantage compared to Petri Nets based approaches [20,27,28]. As it was demonstrated, in the CASA method, a more detailed system safety model was developed than STPA based ranking approaches [34][35][36][37], which supports more accurate criticality/importance analysis.
Another advantage of the CASA method is the quantification of the impact on the system safety of adding advanced software-based functions, which was not demonstrated in STPA based approaches [34,[36][37][38], and only approximated in [35,38]. This is an advantage compared to a number of model-based approaches. For instance, a model based approach used for the Fault Tree development applied to a power system failed to quantify the power reduction functions impact on the system safety [68]. In this respect, it can be deduced that the quantification of the advanced functionalities impact on the system safety by using FTA is questionable. Potentially, this would be possible by using Bayesian Networks or Petri Nets, and this is a topic for future research.
The fact that the method was successfully implemented for the safety analysis of a non-safety critical ship system demonstrates that it can be applied to other safety critical and non-safety critical ICS, such as the ship power and propulsion systems, ballast water treatment systems, nuclear control systems, industrial power systems, heat, ventilation, and air conditioning control system. Forthcoming studies could also investigate if the CASA method is effective for the safety analysis of socio-technical systems and autonomous CPSs.
The increased CASA accuracy, however, comes at a cost. The method has rather a large number of steps, which indicates that more time is required to apply the method than the STPA or the classical FTA. This poses a need to automate the application of the method based on formal models. This is also a topic proposed for future research.

Conclusions
In this study, a novel method for safety analysis of the CPSs was developed and demonstrated. This method combines two hazard identification and analysis techniques and a modified hazard identification and analysis technique-to be specific, the systemic STPA, the traditional FTA as well as the ETA-based ESI method. The method commences with STPA to identify potential software failures, proceeds with system hazardous sequences identification using the ESI, employs the FTA to analyse further specific system failures and finishes with the Quantitative Analysis to estimate safety and importance metrics. The novel method was applied for safety analysis of the open-loop exhaust gas scrubber system.
The main findings of this study are summarised as follows: • The straightforward application of FTA to CPSs may result in inaccurate representation of the top event.

•
The CASA method guided and resulted in a more accurate safety analysis, compared with previous FTAs for the same system by incorporating the system software failures represented by UCAs, considering the system states' probabilities, multi-point failures, and temporal relationships in the system.

•
The CASA method also allowed for the investigation and quantitative estimation of the system behaviour for cases where new functions are added to the system, as was demonstrated with the monitoring techniques applied to the SOx sensor and scrubber unit.

•
The proposed method allowed for the estimation of the safety-related event failure rate and the identification of the most important factors and failures affecting the safety-related event guiding the safety enhancement of the investigated system.

•
The implementation of monitoring techniques for the SOx sensor failures or two SOx sensors' installation is expected to reduce significantly the system noncompliance failure rate (an order of magnitude) with regulations. Implementation of advanced monitoring techniques for the scrubber unit failures is expected to improve system safety, but to a lesser extent.
In summary, this study demonstrated that the developed method for a complex system undesired event failure rate estimation led to a more effective and complete Fault Tree development in comparison to the previous studies. The method also allowed for assessing the impact of different parameters to the overall system undesired event failure rate overcoming the STPA limitations. It is expected that the proposed method will constitute a valuable tool for the CPS safety analysis during the initial design phases and support the safe systems operation. A future work could investigate the proposed method automation based on formal models or application to other systems. Other safety/financial metrics estimation could also be considered for the exhaust gas open loop scrubber system.