# Improved Safety Analysis Integration in a Systems Engineering Approach
## 1 Introduction  
Safety Analysis (SA) aims at assessing system safety and ensuring a Satisfactory Safety Level (SSL) of designed systems. Different techniques and methods are used to evaluate system safety [1, 2] such as HAZard and OPerability Analysis (HAZOP), Reliability Block Diagrams (RBDD), Process Hazard Analysis (PHA), and the two most traditionally used techniques are Failure Mode and Effects Analysis (FMEA) and Fault Tree Analysis (FTA). FMEA is an inductive bottom-up safety analysis method that allows the identification of Failure Modes (FM) of system components or functions and the determination of their respective effects at the system level. The analysis, then, aims at removing the potential risks from the design of the system. FTA is a deductive top-down approach that starts with an undesired Top Level Event (TLE) and progressively deduces its root causes [3], through a graphical logical representation of fault events. FTA aims at identifying all possible routes that leadto an undesired TLE and then mitigates the potential risks by making architectural and behavioral modifications. FTA can be used in a quantitative and qualitative approach. In practice, there is a gap between Model Based Systems Engineering (MBSE) [4] and SA as the latter takes place very late in the design process. This gap leads to inconsistency between Systems Engineering (SE) models and SA models. This inconsistency between models inhibits the dynamic updating of a critical system design to consider the required modifications after safety analyses are performed. Moreover, in the design process, this gap between models prevents the consideration of safety constraints early enough, which can be very costly when problems are detected late. The design process of the system may be organized in four main phases, which are the early concept phase, the design phase, the development phase, and the production phase. According to INCOSE [4], the elimination of the design faults detected during the design phase is 6 times more costly than removing them in the early concept phase. This number can be multiplied by 100 and 1000 if the design fault is detected during the development, production, or test stage. Hence, the integration of safety assessment into the systems engineering process is very important. To narrow the gap between SE and SA and thus enhance consistency and reduce late design changes, many research works dealt with the integration between MBSE and SA, such as in [5; 6; 7; 8; 9; 10; 11; 12; 13; 14]. In this paper, we propose a methodology that contributes in further reducing the gap between MBSE and SA. This work represents an extended version of the SafeSysE methodology [8; 15; 16]. In SafeSysE, the authors worked on the integration of SA in the MBSE process. FMEA and Static Fault Trees (SFT) are automatically generated from SysML diagrams, such as Internal Block Diagram (IBD) and activity diagrams. However, SafeSysE does not consider the feedback from the generated artifacts in order to recommend enhancements of system architecture and behavior. To efficiently guide the systems engineer in making system architectural modifications according to the safety analysis recommendations, SafeSysE needs to be completed. The aim of this work is to extend SafeSysE by using FMEA and FTA feedback to improve system design, as well as by a new Dynamic Fault Tree (DFT) generation approach. The paper is organized as follows. Section 2 discusses the state of the art concerning the integration of safety analysis in the systems engineering process. Section 3 gives an overview of the proposed methodology. Section 4 describes the first and second steps of this methodology (i.e., the automatic generation of FMEA from the system description and then structural modifications proposal based on FMEA information) that aim at improving the system architecture. Section 5 describes the third and the fourth steps of the methodology aiming at enhancing the system behavior. A dynamic fault tree is generated, automatically, from a system model.