Jabier Martinez
email: jabier.martinez@tecnalia.com

Jean Godot
email: jean.godot@all4tec.net

Alejandra Ruiz
email: alejandra.ruiz@tecnalia.com

Abel Balbis
email: abel.balbis@thalesaleniaspace.com

Ricardo Ruiz Nolasco
email: rruiznolasco@rgb-medical.com

Safety and Security Interference Analysis in the Design Stage

Keywords: Safety, Security, Co-Engineering, Interference analysis, fault tree analysis

Safety and security engineering have been traditionally separated disciplines (e.g., different required knowledge and skills, terminology, standards and life-cycles) and operated in quasi-silos of knowledge and practices. However, the co-engineering of these two critical qualities of a system is being largely investigated as it promises the removal of redundant work and the detection of trade-offs in early stages of the product development life-cycle. In this work, we enrich an existing safetysecurity co-analysis method in the design stage providing capabilities for interference analysis. Reports on interference analyses are crucial to trigger co-engineering meetings leading to the trade-offs analyses and system refinements. We detail our automatic approach for this interference analysis, performed through fault trees generated from safety and security local analyses. We evaluate and discuss our approach from the perspective of two industrial case studies on the space and medical domains.

Introduction

Several engineering disciplines are required to design and build the increasingly complex critical systems present in industrial settings and public infrastructures. Besides the different specialized disciplines related to designing and implementing the software and hardware parts for the functional capabilities of the system, there are experts on assuring the relevant non-functional properties. Safety is a non-functional property which considers the mitigation measures to avoid negative impact on humans or the environment, while Security is the combination of three criteria: confidentiality, the prevention of the unauthorized disclosure of information; integrity, the prevention of the unauthorized amendment or deletion of information; and availability, the prevention of the unauthorized withholding of information [START_REF] Abdulkhaleq | Using STPA in compliance with ISO 26262 for developing a safe architecture for fully automated vehicles[END_REF]. Thus, safety and security experts aim to reduce those risks to acceptable values by integrating the needed barriers and measures within the components of the system. However, preventing both safety and security could cause contradictory situations [START_REF] Avizienis | Basic concepts and taxonomy of dependable and secure computing[END_REF] (e.g., the introduction of a security method could cause a time delay which is in contradiction with a safety requirement).

Security is usually needed to ensure safety (security-informed safety) [START_REF] Netkachova | Security-informed safety[END_REF] and therefore they are highly interrelated. However, current engineering practices reveal that they are mostly faced independently because safety and security teams have different highly specialized knowledge and skills. For instance, safety experts and security experts tackle the analysis of feared events in different ways [START_REF] Steiner | Integrating Security Concerns into Safety Analysis of Embedded Systems Using Component Fault Trees[END_REF]. Also, they are forced to show compliance to standards, jurisdictions, and regulations focusing only on one aspect [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF] which usually impose the lifecycle, activities, methods, terminology conventions that they should follow, and the expected artefacts that they should produce.

Co-engineering safety and security is still a challenge [START_REF] Gruber | Co-engineering-in-the-loop[END_REF][START_REF] Paul | Recommendations for Security and Safety Co-engineering -Part A[END_REF] affecting several industrial scenarios such as medical devices, industrial automation, railway, air traffic management or space [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF]. Safety and security separation led to redundant efforts [START_REF] Ruiz | Preliminary safety-security co-engineering process in the industrial automation sector[END_REF] and, most importantly for this work, to late identification of conflicts and trade-offs in safety and security requirements [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF]. The costs of not identifying issues related to safety and security concerns during early phases of the product life-cycle can be very significant.

In this work, we focus on how to support the co-engineering process in the design stage. We contribute with the integration of safety-security co-engineering within mainstream practices. Concretely, we extend an existing method for the combined analysis of safety and security by introducing an interference analysis approach. Interference analysis refers to techniques analysing the mutual influence and inter-links of different quality attributes [START_REF]AQUAS project: D3: Combined Safety, Security and Performance Analysis and Assessment Techniques[END_REF]. Notably, there is a debate about what triggers trade-off meetings and interaction points [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF]. They may either be scheduled interaction points or interaction points triggered when a sufficient critical mass of interference needs to be treated. It is the goal of our work to define how this may be identified and measured. We propose a solution to these measurements taking as input fault trees [START_REF]IEC 61025: Fault tree analysis[END_REF][START_REF] Lee | Fault tree analysis, methods, and applications -a review[END_REF] automatically generated from component local analyses of the combined safety-security analysis. Thus, this interference analysis provides high-level reports on the interdependence of safety and security using artefacts from the combined analysis. The objective of these reports is to reveal and trigger the need of a co-engineering meeting and to visualise the evolution of the safety and security interdependence. We also contribute a qualitative evaluation of the presented approach from the perspective of two industrial pilot projects: earth observation and medical devices. This paper is structured as follows. Section 2 introduces the case studies and Section 3 presents background information on relevant topics needed to better understand this work and using the case studies context. Section 4 positions our approach for the co-engineering method including the interference analysis part.

Section 5 presents the qualitative evaluation and a discussion. Finally, Section 6 presents the conclusions and future work.

Case Studies

The two case studies of this work stems from the AQUAS project (Aggregated Quality Assurance for Systems) [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF] which objective is to provide a holistic approach to Safety/Security/Performance Co-Engineering. In the presented work, we have focused only on the design stage of two diverse domains, earth observation and medical devices, that we introduce below.

Earth observation market is growing with its main application on military settings followed by usage by civilians and enterprises. Earth observation is in many cases mission-critical and the cyber-physical systems enabling these services have strong requirements on safety, security and performance, notably because of the stringent rules specified for space equipment design. In this work, a simplified version of the AQUAS space case study [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF] supports the technical description. The original case study considered the more general Space multicore case, applicable to both Telecom and earth observation payloads. Most of the safety issues are related to the fact of using dual-core architectures (complex resource sharing schemes and software design). It has been simplified because of confidentiality issues but it also provides a more comprehensible presentation. We focused on a subsystem which architecture is illustrated in Figure 1. The mission-critical responsibility of this subsystem is taking pictures (Camera component), packaging them before the transmission (Data packaging component) and transmitting them to the ground station (Transmitter component). Medical devices integrated in hospital settings and information systems have strong safety, security and performance requirements. In the AQUAS project, the development of a closed-loop controller for muscle relaxation is being investigated with respect to co-engineering challenges [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF]. The device consists of a neuromuscular transmission monitor and an infusion pump system with several pumps for different patients. Because of space limitations, the architecture and more details can be found in a related publication [START_REF] Sango | Model-Based System[END_REF].

Background

This section provides details on safety and security engineering (Section 3.1) as well as basic technical information on component local analysis (Section 3.3) and fault and attack trees (Section 3.2) for a better understanding of this work.

Safety and Security Engineering

As mentioned in the introduction, safety and security are usually separated processes. An industrial survey on safety and security aspects has shown that the lack of communication between engineering disciplines and their different focus and approaches are considered as a major issue [START_REF] Kaspersky | The state of industrial cybersecurity[END_REF]. However, some approaches exist trying to support combined analyses. In the STAMP analysis [START_REF] Leveson | Engineering a Safer World: Systems Thinking Applied to Safety[END_REF] both disciplines combine applying system engineering for accident cause analysis. Other proposals are, for instance, Failure Modes Vulnerabilities and Effects Analysis (FMVEA) [START_REF] Schmittner | Security Application of Failure Mode and Effect Analysis (FMEA)[END_REF], SAHARA (Security-aware Hazard Analysis and Risk Assessment) [START_REF] Macher | Sahara: A security-aware hazard and risk analysis method[END_REF], or the combination of Fault Tree Analysis (FTA) [START_REF]IEC 61025: Fault tree analysis[END_REF][START_REF] Lee | Fault tree analysis, methods, and applications -a review[END_REF][START_REF] Ruijters | Fault tree analysis: A survey of the state-of-the-art in modeling, analysis and tools[END_REF], Stochastic Coloured Petri Net (SCPN) [START_REF] Gehlot | An introduction to systems modeling and simulation with colored petri nets[END_REF], Attack Trees Analysis (ATA) and FMVEA [START_REF] Verma | Combined approach for safety and security[END_REF]. Besides the safety-security combined analyses in the concept, requirements [START_REF] Apvrille | Harmonizing safety, security and performance requirements in embedded systems[END_REF], or risk analyses stages, other techniques are proposed for the subsequent phases. Extensive list of examples of those techniques are available [START_REF]AQUAS project: D3: Combined Safety, Security and Performance Analysis and Assessment Techniques[END_REF][START_REF] Paul | Recommendations for Security and Safety Co-engineering -Part A[END_REF] and a mapping of safety and security processes have been presented in several application domains such as medical [START_REF] Sango | Model-Based System[END_REF] or industrial automation systems [START_REF] Ruiz | Preliminary safety-security co-engineering process in the industrial automation sector[END_REF]. In this work, we focus on the design stage where the architecture and the components involved in the system are defined. This is a crucial stage before the actual software, hardware and communications implementation. Thus, preventing the late identification of issues that might have been avoided through co-engineering in the design stage is of high interest.

Fault Trees and Attack Trees

Fault Tree Analysis, a widely adopted practice on reliability and safety engineering [START_REF]IEC 61025: Fault tree analysis[END_REF][START_REF] Lee | Fault tree analysis, methods, and applications -a review[END_REF][START_REF] Ruijters | Fault tree analysis: A survey of the state-of-the-art in modeling, analysis and tools[END_REF], proposes a hierarchical structure of events, where the top event is an undesired event or system state, and the rest of the tree are events or gates describing the Boolean conditions which are sufficient to reach the top event. Traditional usage includes probability analysis to asses if the risk is under an acceptable threshold, and identification and analysis of the shortest or more probable paths to reach the top event with the objective to refine the system with the appropriate safety barriers. Besides that, diverse extensions to FTA were proposed [START_REF] Ruijters | Fault tree analysis: A survey of the state-of-the-art in modeling, analysis and tools[END_REF]. Fault trees quickly get complex in terms of size complicating their human visualization and comprehension [START_REF] Maaskant | Interactive visualization of fault trees[END_REF]. It is even more complicated to reason on high-level concepts (e.g., safety, security) and their interactions by just looking at the fault tree.

In the security engineering domain, a similar approach was used named attack trees [START_REF] Schneier | Attack Trees[END_REF] for modelling security threats where the top events represent an attack goal. Following the trend of safety-security co-engineering, approaches to conciliate safety-related fault trees with security attack trees are proposed [START_REF] Steiner | Integrating Security Concerns into Safety Analysis of Embedded Systems Using Component Fault Trees[END_REF] and industrial experiences of this mix are reported (e.g., railways domain [START_REF] Yi | A Safety-Security Assessment Approach for Communication-Based Train Control (CBTC) Systems Based on the Extended Fault Tree[END_REF]).

Component Local Analysis

In safety engineering, methods such as Failure Propagation and Transformation Notation (FPTN) [START_REF] Fenelon | Towards integrated safety analysis and design[END_REF] or Interface Focused-FMEA (IF-FMEA) [START_REF] Papadopoulos | Hierarchically performed hazard origin and propagation studies[END_REF] have been established to cope with the analysis of complex and large systems based on abstraction and decomposition. Thus, the analysis is conducted locally on components to identify and describe their failure behaviour. Technically, a component local analysis can be represented with specific equation syntax [START_REF] Fenelon | Towards integrated safety analysis and design[END_REF], table [START_REF] Papadopoulos | Hierarchically performed hazard origin and propagation studies[END_REF] or diagram [START_REF] Kaiser | Advances in component fault trees[END_REF]. The diagram solution is used in Safety Architect tool 5 with a notation based on Component Fault Trees [START_REF] Kaiser | Advances in component fault trees[END_REF] as depicted in Figure 2. In the earth observation case study, the Transmitter component design, with its input and output ports (Figure 1), is enriched with information about failure modes, feared events, and how system or local events can lead to the latter through logic expressed with Boolean gates. For instance, in the Transmitter component, perturbations, internal errors of the transmission, or errors from upstream components via the input port can lead to the feared event Erroneous transmitted signal. This local analysis is performed for single components of the system. However, given that this analysis is performed for each component in the system, the potential of components triggering feared events are captured for the whole system (i.e., the analysis span over components). Then, the enriched information introduced through the system components architecture, can be used to generate a Failure Modes and Effects Analysis (FMEA); taking as input the local analyses of all system components, or, more importantly for this work, a global system safety analysis such as, fault trees for feared events. Generated fault trees for the whole system, gathering the local analyses, present even more challenges for visualization and comprehension given their size and the technical details included directly from the system design.

4 Enriching safety-security co-analysis in the design stage with interference analysis

We propose a reusable building block for safety-security co-engineering in the design stage trying to integrate co-engineering into mainstream practices. Figure 3 is a UML activity diagram representing the enriched safety-security co-analysis approach that we propose. The parts tagged with 1 and 2 are advanced but established techniques dealing separately with safety and security aspects, and 3 is an advanced co-engineering technique. Then, 4 adds more co-engineering support through advanced interference analysis.

The proposed method falls within the design stage of the development lifecycle (see that the start and end UML symbols at Figure 3 are within the design stage). The main goal is to define the system architecture with the chosen technological solutions to cover the requirements. Then, several engineering domains are involved such as hardware, software, safety, security or performance. These specialist teams for each domain receive inputs including the results of the concept phase: requirements and specification; and they are responsible for evolving the initial system architecture under design. Each of these domains work with their own processes, methods and tools, and progress in parallel during the development life-cycle (e.g., 1 and 2 ).

As mentioned in Section 3.1, recent approaches propose to cross the result of different engineering domains. Our goal is to reduce the number of iterations for designing the system architecture that are usually required to tune the technical solutions and to find and solve potential trade-offs. The proposed method is dedicated to the co-engineering between safety and security domains based on a combined local analysis ( 3 and more explanations in Section 4.1). The co-engineering interference analysis is supported by an automatic tagging method applied on the fault trees and by high level reports that help to identify and set the scope of the issues to be analysed ( 4 and details in Section 4.2). Co-engineering meetings are triggered by issues or by an increase on the interference that should be discussed. These moments in the product life cycle where experts from the different disciplines met are called interaction points [START_REF] Pomante | The AQUAS ECSEL Project Aggregated Quality Assurance for Systems: Co-Engineering Inside and Across the Product Life Cycle[END_REF]. In case of trade-offs and where design decisions need to be made, rationale representations [START_REF] Dutoit | Rationale Management in Software Engineering[END_REF][START_REF] Shipman | Integrating different perspectives on design rationale: Supporting the emergence of design rationale from design communication[END_REF] (e.g., decision reports) are recommended.

The proposed method is associated with a fully integrated toolchain. Regarding tool-support, all parts are supported by Safety Architect and Cyber Architect, and we add the interference analysis with a seamless integration of the Concept-aware analysis library. The safety-security co-analysis and interference analysis are explained in details in the following sub-sections.

Safety-Security co-analysis

As described in the background Section 3, the safety analysis can be decomposed by local analysis of the system components to automatically generate fault trees, FMEA or reports for the whole system. Security analysis has its own concepts and methodology such as Ebios2010 [START_REF]ANSSI: Expression of Needs and Identification of Security Objectives -EBIOS Security knowledge Base[END_REF] or ISO/IEC 27005 [1]. To propose a coengineering method, a shared conceptual framework should be defined. Figure 4 presents the mapping proposal between safety and security concepts enabling the safety-security combined analysis ( 3 in Figure 3). Thanks to this mapping, it is possible to bring safety elements into security analysis and vice-versa. Thus, in Safety Architect, a security threat scenario can be displayed with the component local analysis syntax. Figure 5 shows an example. In the Transmitter component, the external threat source of malevolent people and internal vulnerabilities and threats can led to the feared event of Spying. Then a safety-security local analysis can be conducted on each of the components that integrate safety and security concerns to represent their mutual impact. For instance, if safety engineers require a new barrier to comply with the safety goals, or conversely, the security engineers require a new countermeasure to reach the desired security level, an automatic analysis can be conducted to identify if the addition of this element could impact or interfere on other engineering domains.

In the first version of the earth observation case study, no security protection was implemented as, traditionally, with the exception of commercial telecommunications missions, security mechanisms have not been widely employed on civilian space missions. However, in recognition of increased threat, there has been a steady migration towards the integration of security services and mechanisms [START_REF]The Consultative Committee for Space Data Systems[END_REF]. Then, in the case study, security engineers require to integrate an encryption module in the telecommunication space system. Thus, the previous security analysis (Figure 5) is updated with the proposal to add a Cipher to protect the transmitted message as shown in Figure 6. The safety-security view allows to overlay, in the same local analysis, the safety and security one. Then, it is possible to analyse how the cipher module impacts the safety-related elements. One of the problems common to all forms of satellite encryption relates to signal degradation caused by different perturbations: terrestrial weather, solar and cosmic radiation or many other forms of electromagnetic noise. Depending on the encryption algorithm chosen, this situation can be particularly problematic because the entire encrypted message may be lost if even a single bit of data is out of place [START_REF] Vacca | Computer and Information Security Handbook[END_REF]. Then, new propagation links related to safety are added as part of the design of the solution to describe that perturbations can conduct to the failure mode Absent (A) where the feared event "Loss of the message" is associated. Thanks to the combined safetysecurity local analysis, the safety analysis is updated with new links involving the cipher and the perturbations, as depicted in Figure 7. In this co-modelling

PackagedData_In TransmittedSignal

New safety propagation caused by the integration of the security countermeasure Functional behaviour Fig. 7. Example of a safety-security component local analysis step of the component local analysis, the interference can be easily identified and treated, however, we do not get system-level quantification of the interference.

Interference analysis

From the combined safety-security local analyses, fault trees are automatically generated. This is the input for 4 in Figure 3. The combined fault trees describe the combination of safety and security events (failure mode, vulnerability, threat) that conduct to a safety or a security feared event. Figure 8 presents an illustrative of a safety-security fault tree generated from the earth observation example. The events are annotated with Safety and Security. However, this is not visible in the tools. We added it for illustration purposes. In the example, because of its small size, the identification of the interference of safety and security is easy but in real projects it requires to deeply explore the generated safetysecurity trees which can count hundreds of events making it time-consuming or impossible to comprehend the safety-security interference. . {Main µC}::Data packaging .

Safety feared event

Safety Security

Fig. 8. Excerpt of a Safety-Security tree example

In the use of the CyberArchitect and SafetyArchitect tools, events belong to either safety or security concepts, we were able to export the fault tree models using Open-PSA exchange format [START_REF]Open-PSA: Fault tree exchange format[END_REF] with attributes to add this information for each event. This information is seamlessly consumed by the tool named Conceptaware which takes these attributes in the events and performs a propagation mechanism of these tags. When an event is annotated with a tag (e.g., Safety), this event is a Safety-related event but, at the same time, through the propagation, all ancestors and descendants are events where this tag is potentially involved. For example, Cipher,EncryptedData is a Security event and given that Loss of the transmitted message is its ancestor, Security is involved in Loss of transmitted message. This information of events and tags (direct and propagated) are used to identify the interference. We automatically create a formal context to perform a Formal Concept Analysis [START_REF] Ganter | Formal Concept Analysis: Mathematical Foundations[END_REF] (a wide-spread technique to create concept hierarchies and groups) where the objects are the events and the properties are the tags. The Concept-aware tool uses the Galatea library to perform this analysis [START_REF] Falleri | Automatic Refactoring and Alignment of Class Models (Contributions à l'IDM : reconstruction et alignement de modèles de classes)[END_REF]. The information of the obtained concept lattice [START_REF] Ganter | Formal Concept Analysis: Mathematical Foundations[END_REF] is then used to create high-level reports and visualisations.

We provided a report consisting on a snapshot of the interference at a given point in time, usually the latest version of the design, and another report on the evolution of the interference given that the design evolve during the design process and also during refinements caused by issues or improvements found in later product life-cycle stages. Figure 9 shows an example of the reports generated from the illustrative example of the fault tree from Figure 8. In the Concept size part on the left, we can observe how all events are involved in Safety and two on Security. In the right side, we can observe the level of the interference of Safety and Security in the system. In the evolution report we can compare the increase of the interference from zero to two (the latter corresponds to the latest version of the fault tree shown in Figure 8).

Qualitative Evaluation and Discussion

Given the confidentiality of the case studies, we rely on a qualitative discussion of the practitioners from the industrial companies involved in the pilots. To show the characteristics of the pilots, Table 1 reports on the size of the modelled sub-systems and Table 2 the size of the generated fault trees. As mentioned in Section 3.2, we highlight the difficulty on visualising such large fault trees to infer interferences between safety and security concerns. The following paragraphs are based on feedback from the persons who applied the approach. Earth observation feedback: The high level reports on safety-security interference created through the proposed tool-supported process can help to make "trade-offs" decisions at the design stage, specially in large projects, where integration of complex systems and the involvement of different teams make system design decisions more difficult to be evaluated because of the lack of visibility of the fine-grained details. Figure 10 shows the evolution report for a feared event. We can observe how the design evolved taking only Safety into account and then Security was integrated creating a significant interference. The interference analysis report and the design should be analysed to check whether the elements in the interference requires a decision, an action, or introduces a trade-off. As mentioned before, the final objective of this interference analysis technique is to potentially trigger a co-engineering meeting to discuss the implications of the refinements of the design.

Medical devices feedback: The proposed co-engineering method is a structured method that can help refining the design and may led to improve significantly the detection of interferences between safety and security requirements at early stages of the design. This improvement will have a positive impact on the reduction of cost and time required for designing a medical device. The cybersecurity is an increasingly important factor to consider for the design of medical Fig. 10. Evolution report for a feared event of the earth observation case study devices, so it is becoming highly regulated. Given the interlinks between safety and security, that we already acknowledged in the product-life cycles of RGB products [START_REF] Larrucea | Approach for enabling security across PLC phases: An industrial use case[END_REF], the proposed independent safety and security analyses followed by the combined analysis, can provide evidences that issues related to this interference were considered, and eventually, discussed and treated. As a drawback, RGB has experience on safety and security analysis using fault tree analysis, but integrating these new methods and tools can represent a significant learning curve.

Conclusion

We proposed a method for co-engineering in the design stage based on enriching components' local analyses and enabling interference analysis to avoid the later identification of issues and conflicts between safety and security aspects. The system-level reports on safety-security interference are possible through generated fault tree models. These high-level reports can help quantifying the interference at a given point in time as well as from the historic of changes. We used our approach in two pilot projects. As further work, we aim to provide more support for the interference analysis to rank or prioritize the interference events identified in fault tree analysis, and by supporting an integrated interference analysis approach using other artefacts such as requirements.

Fig. 1 .

 1 Fig. 1. Simplified system architecture of the space case study

Fig. 2 .

 2 Fig. 2. Example of a safety component local analysis in Safety Architect

Fig. 3 .

 3 Fig. 3. UML Activity Diagram representing the enriched safety-security co-analysis in the design stage with interference analysis

Fig. 4 .

 4 Fig. 4. Mapping between safety and security concepts

Fig. 5 .

 5 Fig. 5. Example of a security component local analysis

Fig. 6 .

 6 Fig. 6. Example of a security barrier in a component local analysis

Fig. 9 .

 9 Fig. 9. Concept report and Evolution report of the illustrative example

Table 1 .

 1 Number of components (HW: Hardware, SW: Software) for the two pilots

	Case study	HW components SW components Total
	Earth observation	2	8	10
	Medical devices	17	30	47

Table 2 .

 2 Elements in the fault trees (Tmtc: Tele-Metrics to TeleCommunication)

		Feared event	Events Gates Total
	Earth observation Absent Tmtc Out	24	67	91
		Erroneous Tmtc Out	17	49	66
		Data Spying	6	17	23
	Medical devices	Erroneous Drug Dose Rate	43	188	231
		Loss of integrity drug dose rate	2	16	18

Safety Architect: https://www.riskoversee.com/en/safety-architect-en/

Acknowledgments

The research leading to this paper has received funding from the AQUAS project (H2020-ECSEL grant agreement 737475). The ECSEL Joint Undertaking receives support from the European Union's Horizon 2020 research and innovation programme. It is a collaboration between Spain, France, United Kingdom, Austria, Italy, Czech Republic and Germany.