Faïda Mhenni

Nga Nguyen

Jean-Yves Choley

SafeSysE: A Safety Analysis Integration in Systems Engineering Approach

Keywords:

The main objective of this paper is the integration of safety analysis in a SysML-based systems engineering approach in order to make it more effective and efficient. It helps to ensure the consistency between safety analyses and system design and then to avoid late errors and to reduce system development time. To achieve this purpose, we tackled the following axes: 1) formalizing a SysML-based design methodology that will be the support for safety analyses; 2) providing an extension of SysML to enable the integration of specific needs for safety concepts in the system model; and 3) performing an automated exploration of the SysML models to generate necessary information to elaborate safety artifacts such as failure mode and effects analysis (FMEA) and fault tree analysis (FTA). The proposed methodology named safety integration in systems engineering (SafeSysE) is applied to a real case study from the aeronautics domain: electromechanical actuator (EMA).

I. INTRODUCTION

M ODERN systems are getting more complex due to the integration of several interacting components with different technologies to offer more functionality to the final user. Accidents can result from unsafe interactions between nonfailed components or software-related errors [START_REF] Thomas | Extending and automating a systems-theoretic hazard analysis for requirements generation and analysis[END_REF]. The complexity in these systems requires new appropriate processes, tools, and methodologies for their design, analysis, and validation while remaining competitive with regard to cost and time-to-market constraints. Model-based systems engineering (MBSE) [START_REF]INCOSE, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities[END_REF] is a systems engineering approach that explores the use of models, which are more expressive and less ambiguous than documents. Model simulation also offers an easier way to perform tradeoffs and comparisons between alternative designs. Another major advantage of using models is that traceability between the different views and between models of different levels of abstraction is easily established. In the MBSE approach, different languages and modeling tools can be used according to the domains involved in the system, the level of detail, the system aspects to be modeled, etc. SysML [START_REF] Omg | Systems Modeling Language, Object Management Group Std[END_REF] is a systems modeling language that aims at providing a unified standard for "specifying, analyzing, designing, and verifying F. Mhenni and J.-Y. Choley are with Quartz, SUPMECA, Paris 93400, France (e-mail: faida.mhenni@supmeca.fr; jean-yves.choley@supmeca.fr).

N. Nguyen is with Quartz, EISTI, Cergy 95000, France (e-mail: nga.nguyen@eisti.eu). complex systems that may include hardware, software, information, personnel, procedures, and facilities." It also allows a multiview model and building traceability links. This relatively recent language is already widely used in both industrial and academic worlds like in [START_REF] Holt | SysML for Systems Engineering[END_REF]- [START_REF] Helle | Automatic SysML-based safety analysis[END_REF] to cite only few works.

Safety analysis has the objective to assess system safety during design phase and ensure that the designed systems have satisfactory safety level. Different techniques and methods exist and are used for different purposes and at different design levels [START_REF] Ericson | Hazard Analysis Techniques for System Safety[END_REF]. The two most traditionally used techniques are failure mode and effects' analysis (FMEA) and fault tree analysis (FTA) [START_REF] Ericson | Hazard Analysis Techniques for System Safety[END_REF], [START_REF] Balz | Use case-based fault tree analysis of safety-related embedded systems[END_REF]. FMEA aims to evaluate the effects of potential failure modes of components or functions, and eliminate these potential risks in the system design. FMEA is an inductive bottom-up safety analysis that identifies the failure modes of system functions or components and then determines their effects on the system level. Meanwhile, FTA, when used in a qualitative approach, is a top-down deductive analytic method in which the analysis starts from an undesired event called the top-level event and then, the initiating primary events such as component failures, human errors, and external events are traced through Boolean logic gates to this top-level event. FTA can also be used in a quantitative analysis and in this case, the probability of the top-level event is evaluated based on the different probabilities of the leaf events of the fault tree. These safety analyses, however, are based on independent tools and performed separately by safety engineers. The extraction of information from the system model is usually done manually. As a consequence, these analyses are error prone and time-consuming. During safety analysis, the design usually continues to evolve and thus safety studies are done for obsolete versions of the design model. To be efficient and correctly explored by system designers, safety analyses must be performed in the early phase of design. That will help to influence the design choices without having recourse to late and costly changes. They should also be done rapidly enough to keep consistent with design, and, of course, errorlessly. To respond to these requirements, safety analyses should be integrated into the design process. To reduce error proneness and development time, the generation of safety artifacts via modelto-model transformation approach (automating the building and modification of models) is needed.

In this paper, we propose a methodology of safety integration in systems engineering approach named SafeSysE. This methodology, we believe, contributes to solving the problems mentioned above. Based on a SysML system model, the methodology provides to all the contributors, a common reference system model that takes into account the constraints of all the domains. It is noteworthy, however, that this is a highlevel model useful at the early design stages and it shall be complemented by domain-specific models at lower detail levels. Based on this model, the methodology automates some steps of the safety artifacts generation via model exploration and model-to-model transformation. One important point of our approach with respect to other methods in the literature is that the design data and safety data are kept in the same SysML model, via an integrated safety profile. Since safety artifacts can be either constructed from structural models as well as from the dynamic behavioral models of the system, a safety analysis can be qualified as compositional or behavioral, respectively [START_REF] Sharvia | Integrated application of compositional and behavioural safety analysis[END_REF]. Our approach studies the two well-known compositional safety techniques, namely FMEA and FTA, recommended by safety standards such as IEC 61508 [15], and SAE ARP 4754 and 4761 [START_REF]Guidelines for Development of Civil Aircraft and Systems[END_REF], [START_REF]Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment[END_REF]. The general IEC 61508 concerns all systems based on electric, electronics, and programmable electronics, and SAE ARP 4754 and 4761 are civil aircraft and systems standards. SafeSysE addresses also a behavioral safety analysis (BSA) based on model checking [START_REF] Clarke | Model Checking[END_REF], a formal verification method that allows validating if the system dynamic behavior satisfies some safety requirements written in temporal logic. These interrelated analysis techniques are used by SafeSysE to perform safety analyses in a very complementary way, during the whole system design process. However, as the BSA is not in the scope of the paper, the readers can reference to our other publications [START_REF] Mhenni | Safety analysis integration in a SysML-based complex system design[END_REF], [START_REF] Mhenni | Safety analysis integration in a systems engineering approach for mechatronic systems design[END_REF] for more details.

This paper is organized as follows. Section II represents related work about the integration of systems engineering and safety analysis. Section III details the SafeSysE methodology. It also introduces the safety profile, a SysML extension which allows integrating safety-relevant properties in the system model to facilitate the automatic generation of safety artifacts. The implemented tool supporting SafeSysE is also described in this section. Section IV explains the automated generation of the functional and the component FMEA from SysML models. The fault tree generation algorithm, including the pattern identification phase as well as the graph traversal phase, is given in Section V. The same case study, i.e., electromechanical actuator (EMA), is used throughout Sections IV and V to illustrate the different steps in SafeSysE. Finally, this paper is concluded in Section VI.

II. RELATED WORK

This section discusses related work concerning the integration of safety analysis into MBSE, called model-based safety analysis (MBSA). In order to compare them with SafeSysE, we will focus on publications using SysML as systems modeling language as well as literature on automating FMEA and fault tree generation.

Laleau et al. [START_REF] Laleau | A first attempt to combine SysML requirements diagrams and B[END_REF] tried to combine SysML requirement diagrams and the B formal specification language. Since requirements in SysML are textual, the SysML requirement models are first extended to represent some concepts in the goal-oriented requirement engineering approach, such as expectation, elementary or abstract goal for requirement classes and milestone, and/or refinement for relationship between requirements. Then, derivation rules are proposed to translate the SysML goal models into B specifications. By doing so, a more precise semantics of SysML goal models is given, narrowing the gap between the requirement phase and the formal specification.

Also regarding requirements, Albinet et al. [START_REF] Albinet | Model-based methodology for requirements traceability in embedded systems[END_REF] proposed to directly include system requirements in the design process but the separation with the proposed solutions as required by safety standards such as ISO 26262 [START_REF]ISO 26262 Road Vehicles-Functional Safety[END_REF] is achieved by isolating the following triplet: requirement models, solution models, and validation and verification models. 1 A SysML profile called requirement profile for MeMVaTEX (RPM) has been developed in [START_REF] Albinet | Model-based methodology for requirements traceability in embedded systems[END_REF]. The requirement stereotype of SysML is replaced by the MeMVaTEX requirement, by adding various properties such as verifiable, verification type, derived from, satisfied by, refined by, traced to, etc. So, the traceability is assured between requirement models, between requirement and solution models, and between requirement and V&V models using these properties. These V&V models have also been explored in the work of Guillerm et al. [START_REF] Guillerm | Safety evaluation and management of complex systems: A system engineering approach[END_REF].

Another approach to integrate SysML and safety analysis is the use of the common modeling Eclipse framework [START_REF] Thomas | Performing safety analyses and SysML designs conjointly: A viewpoint matter[END_REF]. In this work, an independent tool called Obeo designer safety viewpoint that implements classical risk analyses is developed. Then, the interoperability of this modeling tool and the SysML model is achieved through the Eclipse modeling framework. To make the integration possible, the authors used the open source SysML Topcased editor. Safety elements can reference SysML model elements since they are both expressed in the same framework. Furthermore, the Topcased GenDoc plugin can also be used to generate safety documentation from the two models. So, in this approach, SysML is not extended with a safety profile to tune the SysML models. In a more recent work [START_REF] Belmonte | A model based approach for safety analysis[END_REF], a translation from Obeo designer's domain-specific language for FMEA and preliminary hazard analysis (PHA) into AltaRica [START_REF] Arnold | The AltaRica language and its semantics[END_REF] is added to enable formal verification. However, no real system has been studied yet to prove the scalability of the method.

Helle [START_REF] Helle | Automatic SysML-based safety analysis[END_REF] presented an integration process of MBSA in a SysML-based MBSE. In this work, an extension of SysML allows to include safety-related information into the system model allowing the systems engineer to take some light decisions without the help of safety expert. A Java program called safety analyzer retrieves the system model to extract relevant information. The safety analyzer can then provide as outputs the minimal cut set for each failure case and system alternative as well as reliability block diagrams [START_REF] Xu | DRBD: Dynamic reliability block diagrams for system reliability modeling[END_REF], [START_REF] Rausand | System Reliability Theory-Models, Statistical Methods, and Applications[END_REF] representing this cut set.

Garro and Tundis [START_REF] Garro | Enhancing the RAMSAS method for system reliability analysis-An exploitation in the automotive domain[END_REF] developed RAMSAS, a model-based method for system reliability analysis that combines SysML and the Simulink tool allowing the verification of reliability performance of the system though simulation. A formal verification method was not used in this research for safety assessment.

Tajarrod and Latif-Shabgahi [START_REF] Tajarrod | A novel methodology for synthesis of fault trees from MATLAB Simulink model[END_REF] described fault trees' construction from MATLAB Simulink models. In this work, the nominal model is built in Simulink and then manually extended with failure behavioral information of the system. Based on this extended model and the classification of components, the fault tree for a specific top event is automatically constructed.

An automatic generation of fault trees from architecture analysis and design language (AADL) models is proposed in [START_REF] Joshi | Automatic generation of static fault trees from AADL models[END_REF]. In this work, the system architectural model is built with the AADL language and then annotated with fault and failure information using the error annex, a sublanguage of AADL. Based on the annotated model, fault trees are automatically generated in the commercial tool CAFTA.

FSAP/NuSMV-SA [START_REF] Bozzano | The FSAP/NuSMV-SA safety analysis platform[END_REF] is an automated safety analysis tool that aims at providing a uniform environment for design and safety assessment of complex systems. It provides a library of predefined failure modes that can be injected to the initial system model to augment it with failure behavior and thus create a so-called extended system model. By having both nominal and extended modeling, the tool allows to assess the system safety both in nominal conditions and in user-specified degraded situations, i.e., in the presence of faults. The safety analysis engine based on the NuSMV model checker can be used to produce FTA. However, one limitation of this tool is that the fault trees automatically generated with minimal cut sets have a flat structure with only two levels deep. This representation does not reflect the structure of system and consequently, exploring the fault tree to understand the fault propagation through the system components is not very intuitive for systems engineers.

In her thesis [START_REF] Sharvia | Integrated application of compositional and behavioural safety analysis[END_REF], Sharvia dealt with the integration of the compositional safety analysis (CSA) and the BSA. The first part is carried out with hierarchically performed hazards' origin and propagation studies (HiP-HOPS), a safety analysis technique presented in [START_REF] Papadopoulos | Hierarchically performed hazard origin and propagation studies[END_REF]. In this part, system failure models such as FTA and FMEA are constructed by establishing how the local effects of component failures combine as they propagate through the hierarchical structure of the system. CSA gives preliminary information about state automata that represent the transition between normal and failure states of the system. Next, in the BSA, model checking can be carried out on these behavioral models to verify automatically the satisfaction of safety properties. So, the CSA and BSA could be effectively combined to benefit from the advantages of both approaches. Even so, behavioral information captured from CSA is rather limited because its main purpose is the failure propagation and hierarchy, not the dynamic behavior.

David et al. [START_REF] David | Reliability study of complex physical systems using SysML[END_REF] worked on the generation of an FMEA report from system functional behaviors written in SysML models and on the construction of dysfunctional models using the AltaRica language to compute reliability indicators. In their methodology called MéDISIS, they start with the automatic computation of a preliminary FMEA. The structural diagrams, namely block definition diagram (BDD) and internal block diagram (IBD), and the behavioral diagrams such as sequence diagram (SD) and activity diagram (AD) are analyzed in detail to give an exhaustive list of failure modes for each component and each function, with their possible causes and effects. Then the final FMEA report is created with help from experts in the safety domain. To facilitate a deductive and iterative method like MéDISIS, a database of dysfunctional behaviors is kept updated to rapidly identify failure modes in different analysis phases. The next step of their work is the mapping between SysML models and AltaRica data-flow language, so that existing tools to quantify reliability indicators such as the global failure rate, the mean time to failure, etc., can be used directly on the failure modes identified in the previous step.

Ya ky m e t s et al. [START_REF] Yakymets | Model-based system engineering for fault tree generation and analysis[END_REF] presented a safety modeling framework for fault tree generation SMF-FTA. This framework includes metamodels, profiles, model transformation, verification, and FTA tools. In this approach, several steps are needed. First, the system to be analyzed is designed and its structural models are built using the SysML BDD and IBD diagrams. These models are then annotated with failure behavior. Then the entire model is converted into AltaRica language. An algorithm already existing in the ARC tool analyzes the AltaRica model and derives the different minimal cut sets from the model. These cut sets are assembled to form the final fault tree. The resulting fault tree can be represented either with open-probabilistic safety assessment (PSA) or a SysML dedicated profile.

In our work, the safety artifacts including FMEA, FTA, and NuSMV programs are extracted directly from SysML system models, not using an external language such as AltaRica. In this way, we reduce the model-to-model transformations and thus the possibility of data losses during successive transformations. We also update the system model directly with the results of different safety analyses via the integrated safety profile: safety data and design data are stored in the same model. The work of David et al. [START_REF] David | Reliability study of complex physical systems using SysML[END_REF] requires accessing an external database to import dysfunctional behavior. In addition, SafeSysE takes into account both compositional and behavioral aspects of safety analyses. The result of one analysis is used in the next step to refine the other, assuring the consistency of the methodology. A proof-of-concept tool has also been implemented to illustrate SafeSysE.

III. SAFESYSEMETHODOLOGY

This section begins with a description of the SafeSysE process. The proposed safety profile, which is a part of the methodology content, is discussed in Section III-B. The implementation details of the SafeSysE tool are presented in Section III-C.

A. SafeSysE Integrated Process

In this section, the integrated process of systems engineering and safety analysis is presented through a set of steps. In Fig. 1, an AD is used to describe the process. Swim lanes are used to make a distinction between systems engineering and safety analysis activities (or processes). SafeSysE starts with a requirements' definition and analysis process with, as a starting point, a set of initial requirements describing the need. Data stores are used to model the storage of the different artifacts issued from each activity.

1) Step 1: Requirements Definition and Analysis: In this step, system functionalities as well as its external interfaces are described by a set of requirements. Several SysML diagrams such as use case diagrams and BDDs for the system context can be used to help in the identification of these requirements. Since the requirement definition and analysis are not in the main scope of this paper, refer to our paper about SysML-based systems engineering methodology in [START_REF] Mhenni | A SysML-based methodology for mechatronic systems architectural design[END_REF] for more detail.

2) Step 2: Functional Architecture Definition: Based on the functional requirements identified in Step 1), one or more functional architectures are proposed during this step. The final result is a hierarchical model of the breakdown of the system main function(s) into subfunctions. In SysML, functions are represented by activities, and the functional breakdown is modeled through a set of ADs, each AD representing the breakdown of a given function (activity) into subfunctions. ADs also show the progressive transformation of input flows into output flows.

3) Step 3: Functional Risk Assessment: In this step, a functional FMEA is used to identify potential hazards caused by failures and their effects. The automatically generated FMEA data sheet contains the list of functions and a list of generic failure modes. The safety expert then performs the analysis and completes the FMEA with the relevant data. All this new safety information is then updated into the SysML model via the safety profile extension (Section III-B). The gap between safety analysis and design modification is shortened, thanks to this integrated model. At the end of this step, safety requirements are derived and added to the set of requirements. The rule is that for each failure mode with hazardous effects, at least one safety requirement is added. Design changes can be done from this early design stage at the functional level to eliminate or reduce identified risks. Risk effects' mitigation can be obtained by eliminating or modifying high-risk functions, adding new fault tolerance mechanisms such as diagnosis and reconfiguration functions. Each time that the functional architecture is modified, the FMEA shall be updated to take into account the new changes. The previous steps iterate until a satisfactory solution is identified.

4)

Step 4: Logical Architecture Definition: Once the functional architecture is defined taking into account the results of the safety analysis in Step 3), one or more logical architectures are built by allocating components to functions. A BDD describes the components of the system and an IBD describes the interactions between the components. The logical architecture defined at this step already takes into account safety aspects since it integrates the results of the functional safety assessment performed in Step 3).

5)

Step 5: Component Risk Assessment: When the structure of the system is defined, the safety analysis results are updated and a component-level risk assessment is performed. To ensure consistency with previous safety analysis, the generated FMEA, in addition to the components, contains in front of each component the functions allocated to the component as well as the failure modes identified at the functional level as a reminder. The safety expert then identifies the failure modes at the component level and performs FMEA analysis. If there are identified risks at a nonacceptable level, then these risks shall be eliminated or reduced to an acceptable level by performing changes to the design. Once again, these safety data are saved back in the same SysML model. This step, as well as Step 3), is explained in more detail in Section IV.

6)

Step 6: Fault Propagation and Reliability Assessment: Fault trees are used for both qualitative and quantitative analyses. In our approach, fault trees are automatically generated from SysML IBDs describing the system architecture. Information from the previous FMEA analysis is taken into account to create fault tree with specific failure modes. Fault trees can be generated in a graphical form for qualitative analysis purposes like fault propagation studies and critical paths' identifications. They can also be generated in an appropriate format for existing FTA tools. For more details about fault tree generation refer to Section V.

7)

Step 7: Behavioral Safety Analysis: This final step is carried out to complete the safety analyses. The SysML state machines of different components representing the nominal and error states as well as the IBD of the system modeling error propagation are explored to generate automatically a NuSMV program. This program, which is an abstraction model of the system, will be used to verify if some safety requirements (written in temporal logic formulas) are satisfied. Since this step is not in the scope of this paper, the readers can reference to our other publication [START_REF] Mhenni | Safety analysis integration in a systems engineering approach for mechatronic systems design[END_REF] for more details.

B. SysML Safety Profile

During the design phase, the designers (systems or domain engineers) may have relevant information concerning safety especially if they are integrating new concepts or innovating technology. In this case, they are recommended to transmit these data to safety experts. And in the opposite direction, it is important for a safety expert to feedback safety analysis results to systems engineers to take them into account in the system design. In order to integrate safety information directly into SysML models, we have explored the extension mechanism of UML to create a so-called safety profile. A profile allows adaptation or customization of UML metamodels to a specific platform, domain, or method through stereotype and tag definition concepts. In our case, the safety profile is built from stereotypes and tag definitions that represent artifacts useful for the safety analysis techniques we selected for our integrated process, i.e., FMEA, FTA, and BSA.

Since in our methodology, a system function is represented by an activity, it is straightforward to consider function as a stereotype extending the activity metaclass. A system component is a SysML block, so the component stereotype will extend the class metaclass of UML. Because each activity may have several parameters and each class may have several attributes, Parameter and attribute are chosen as extended metaclasses for FailureMode stereotype. By doing so, we could represent the fact that each function and each component may have different failure modes. The other information about a failure mode such as rate, severity, causal factors, and detection methods can be simply considered as the tag definitions of the FailureMode stereotype. Fig. 2 gives the profile diagram of our safety profile. This diagram models also a simple redundancy mechanism as well as dysfunctional behavior information such as degraded and failed states. It is also noted that there is no unique solution for the safety profile. A simple and efficient solution that allows us to represent all needed information while not overloading the XML metadata interchange (XMI) file generated from the SysML model is preferred.

C. SafeSysE Tool Implementation

To support and validate the methodology for real-scale applications, we have developed the SafeSysE tool to automatically generate different safety artifacts. This proof-of-concept tool is written in the Python language. For the automatic generation, first the SysML model is exported into an XMI file [START_REF]Object-Management-Group, XML Metadata Interchange (XMI) Specification, Object Management Group Standard[END_REF]. Since the most common usage of XMI is to exchange metadata for UML models, it is straightforward for us to work with XMI files generated from a SysML modeling tool, so our program will be tool independent. In an XMI document, after the header section containing information about the versions of the standards and the tool that created it, we have the UML and SysML sections that describe the model itself. Data are organized in a tree structure. Our SafeSysE tool parses the XMI file using Beautiful Soup,a Python library that provides methods to navigate, search, and modify a parse tree. For each function, the tool builds a graph with nodes and edges containing all information needed for the generation of the corresponding safety artifacts. Fig. 3 shows the program's main functionalities with the corresponding input and output data. Further algorithmic details will be given in the following sections for each functionality.

IV. FMEA GENERATION FROM SYSML MODELS

FMEA is a reliability tool widely used in safety analysis. To take full benefit of FMEA, it is critical to conduct it at early design stages and continue concurrently with the design evolution, in order to reduce development time and error proneness. In our work, the preliminary FMEA is automatically generated from the system model, and the consistency with the system model is then ensured. Information added by safety experts in the generated FMEA then will be updated in SysML models via the safety profile. Concretely, our SafeSysE tool uses the updated FMEA worksheet and the current XMI file corresponding to the system model as input, and outputs a new XMI file containing updated safety information in the appropriate stereotypes and tag definitions.

A. Functional FMEA

As described in Step 2) of SafeSysE, the functional breakdown of the system mission into subfunctions is modeled with ADs. A progressive breakdown of the system functions with several levels of detail is performed. The decomposition is stopped once the designer is able to allocate components to the functions in an appropriate manner. This results in a tree-like hierarchical representation of the functions. In our study, we consider all the leaf functions in the FMEA generation because the failure modes of the higher level functions are the result of the failure modes of the lower level ones. In an AD, in addition to the functions' list, we have the input/output flows of each function, and we can see the way the system progressively transforms inputs into outputs. This kind of information not only is very important to understand the system functioning but it is also critical for safety analysis.

When using SafeSysE tool, the user can choose to generate a functional FMEA for a particular package that represents a specific functional architecture solution. The functional FMEA generation algorithm realizes the following steps.

1) AD Extraction: From the node corresponding to the chosen package in the parsed tree, the tool extracts all the information related to ADs and stores them in a graph. A node in the graph can be an activity, an action, etc., which is made up of its identity (id), name, type, and the activity it belongs to. If the node is an action node, input and output pins are also collected as nodes in the graph. The edges of the constructed graph represent all possible relationships between nodes.

2) XLS File Generation: This step generates an .xls file corresponding to the FMEA worksheet by creating columns and adding information, when available, for each function in the given columns. For the functional FMEA, the column headers are "Function," "Function failure mode," "Causal factors," "Immediate effects," "System effects," "Recommended actions," and "Severity" but this list can be modified if we want to add other information. The prefilled columns are described hereafter.

a) Function: Functions corresponding to activities are found from the graph built from the previous step. Through the edges connecting different nodes, information about input and output pins as well as predecessor and successor activities is used to fill the other columns. b) Function failure mode: The list of generic failure modes available in a functional FMEA is saved in a configuration file containing: "Fails to perform," "Performs incorrectly (degraded performance)," "Operates inadvertently," "Operates at incorrect time (early, late)," "Unable to stop operation," "Receives erroneous data," and "Sends erroneous data." This list is used to fill in automatically the failure mode cells of each function. Other specific failure modes of the system functions will be added later by safety experts directly in the FMEA worksheet. c) Causal factors: They are the input and output parameters of the current activity/function. These data are not real information in an FMEA analysis, but they help to be exhaustive in finding all possible causes of failures. d) Immediate effects: As the causal factors, we prefill the immediate effect cells by the upstream and downstream activities which are direct predecessors and successors of the current function, respectively. It means that a failure mode of a function can cause immediate effects for the functions that are related with the current function by flow controls. Once the preliminary worksheet is generated, the safety expert then completes the FMEA by adding the relevant information. He can add new failure modes that have not been considered if any, or remove irrelevant failure modes. As failure can propagate with the system flows, the failure in one function can be caused by a failure of the upstream functions. For instance, because of a failure, the upstream function could send a wrong flow causing an overload and consequently leading to a failure of the function in question. In some cases, a function can also fail because of the failure or degraded operating of the downstream functions. The safety expert has to analyze each failure mode and determine the failure effects at the local and system levels and the possible corrective actions to eliminate or reduce the risks caused by each failure mode. Finally, the severity of each failure mode is assessed to identify critical functions and prioritize the list of corrective actions.

B. Component FMEA

The component FMEA generation is based on the structural models of the system. In our case, it is generated from SysML BDD and IBD. The first diagram provides the list of system components, while the second one provides the interactions among components. Knowing the way in which the components interact and the different flows exchanged among them is very useful for the safety analysis. Indeed, when errors occur, they also propagate in the same way. As a result, the interactions among components help in identifying potential causes and effects of failures.

For the automated generation of component FMEA, a new XMI file is generated from the SysML model. This XMI file contains the latest version of the system including the list of functions, the list of components, and the allocation links between them. It also contains the information about the input and output flows of each component and the connections among the ports that give the communication paths among components. The XMI file also contains the results of the safety analysis performed at the functional level, thanks to the safety profile. The elaboration of a component FMEA is quite similar to the functional FMEA. The only difference is that instead of activity nodes, the graph is built from block data extracted from the parsed tree. In the XLS file generation step, one more column for the component name is added. If n functions are allocated for this component, there will be in different lines which have the same format as the functional FMEA corresponding to this component.

C. Case Study

In this paper, the EMA example [START_REF] Moir | Aircraft Systems-Mechanical Electrical and Avionics Subsystems Integration[END_REF] is used to illustrate SafeSysE. The use of EMAs in flight control is increasing since they have many advantages, such as better environmental respect, weight saving, maintenance cost reduction, performance increase, and speed accuracy. An EMA is mainly made of three parts: an electric motor, a mechanical transmission, and an electronic and software part composed of a calculator that controls the system. After the requirements' definition and analysis process, the functional analysis of the EMA is performed. A functional breakdown is represented with nested ADs in SysML. The resulting functional architecture of the EMA is given in a BDD in Fig. 4.

By using SafeSysE tool and the flows exchanged between functions in corresponding ADs (to avoid redundancy, these diagrams will be given later, only for the updated functional architecture), the preliminary FMEA automatically generated for leaf functions in Fig. 4 is given in Fig. 5. The automatic generation will ensure exhaustiveness of failure modes, causal factors, and effects of failures. To save space, we only show an extract of FMEA, i.e., for function "Measure Incidence." Based on this preliminary FMEA and on a good understanding of the system functioning, the safety expert performs the analysis to generate the complete FMEA (Fig. 6). Then, our SafeSysE tool will update the system model with the new FMEA information. This allows to regenerate new FMEA when needed (when design changes occurred) without losing the safety expert's work. As seen in the FMEA in Fig. 6, several functions are critical because their failure could have catastrophic effects. Corrective measures are then required to reduce the risk. This can be obtained by allocating components with very high reliability to achieve these functions but also by performing some changes at the functional level. In this case, we decided to add a new function "Internal Diagnosis" to the system. This function collects measures of some critical parameters of the other functions and tries to identify potential faults in the system. In case of abnormal behavior, this function will inform the "Control and Command" function that will inform the pilot and adjust the outputs it provides accordingly if needed. The new added function implies modification of the other functions since they have to provide this function with monitoring data. The updated ADs of the top-level function "Control Aileron Incidence" and the function "Actuate Aileron Updated" (as an example) are given in Figs. 7 and8, respectively. As the functional architecture of the system has been modified, a new iteration should be done in the functional FMEA to integrate the new function, analyze the impact of its failure modes, and also assess that this new function does not impact the already established safety level. When no more change needs to be done at the functional level, it is time to move to Step 4) of SafeSysE. The logical architecture is obtained in two steps. The first one is the identification of the components and allocating them to the functions, and the next one then consists in identifying the communication among components. This leads to the BDD representing the system structure in Fig. 9 and the IBD representing the interactions among the components in Fig. 10.

A preliminary FMEA generated from the IBD is given in Fig. 11 containing the list of components. To ensure the consistency of the component FMEA with respect to the functional FMEA, the functions allocated to each component and their failure modes are also added in the preliminary component FMEA. The safety expert then associates the functional failure modes into the corresponding component failure to obtain the final FMEA.

V. AUTOMATIC FAULT TREE GENERATION FROM SYSML MODELS

In this section, we will describe our method to generate fault treesautomatically from structural diagrams, i.e., SysML IBDs. IBD gives the internal structure of the system and the interactions among components. The interfaces through which the components interact are represented via standard and flow ports, and the interactions are represented via paths between the corresponding ports called "connectors." If a failure occurs in one component, it will be propagated throughout the system via these paths. The idea of this work is to automatically generate fault trees using two concepts: directed graph traversal and block design patterns. Each concept is detailed hereafter.

A. Directed Graph Traversal

An IBD can be represented as a directed graph G =(V, E) where V is the set of vertices and E is the set of directed edges. The set of vertices is composed of system components and external interfaces, respectively, represented by the parts of an IBD and ports that are situated on the border of the system. The external interfaces can be either input ports through which the system receives flows from its environment (users or contributing systems) or output ports through which the system provides required output flows to its environment. The internal ports through which the components interact do not need to be represented since they can be abstracted by edges directly connecting parts. It is also noted that the graph G accepts multiedges between two parts that symbolize different kinds of items flowing between these two parts. So, to build a fault tree for a given undesired top event, a graph traversal algorithm can be used to find out components relating to each other using the directed edges. This algorithm follows the principle of backtracking from the hazard to the leaf events. The traversal starts at an external output port and traces back to nodes that are his predecessors and continue to visit the other nodes. Since a node can have several predecessors, a branch is finished when we reach an external input port, or when we arrive back to a node that has already been visisted.

B. Block Design Patterns

To facilitate the fault tree generation, we also use the "divide and conquer" principle by partitioning the IBD and treating each partition separately. So, the IBD is splitted into smaller IBDs which are more trivial to solve. Indeed, during the graph traversal, the algorithm also identifies some interesting patterns in an IBD. Each pattern gives rise to a subfault tree and the whole fault tree will be assembled automatically using the mentioned graph traversal algorithm. The fault tree generated in this way is a generic one transcribing the system topology, i.e., the different paths within a system through which faults can propagate to reach the mentioned output port. If the system has several outputs, then a generic fault tree is built for each output port to describe all the paths that could lead to an error on this output.

In this work, we have identified different patterns, each of which has a specific role in the system. These patterns are Entry, Exit, Single, and Feedback. Another kind of pattern, named Redundant pattern, related to safety design criteria where a block part can have input ports coming from components assuring redundancy for higher reliability is also studied.

The following sections describe the recognized patterns as well as their generated partial fault trees. All these patterns are grouped into an illustrating IBD in Fig. 12. Each pattern is surrounded with a dashed rectangle annotated with the corresponding name in an attached note.

1) Entry Pattern: An "Entry pattern" is composed of an entry part and its ports. An entry part in an IBD is a block part that has at least one input port receiving item flow from outside the actual system/subsystem (block B1 in Fig. 12 is an entry part). In the generated subfault tree [Fig. 13(a)], this special input port will be transformed into a basic event representing a failure or error of a system component that is outside the actual block. We will have an OR logic gate whose operands are as follows: the internal failure of the part and the basic events representing the external failures (from input ports on the boundary) and failure of all eventual input ports of the part coming from other components.

2) Exit Pattern: An "Exit pattern" is composed of an exit part and its ports. An exit part in an IBD is a block part that has at least one output port sending item flow out of the actual system/subsystem (block B6 in Fig. 12). In the corresponding fault tree [Fig. 13(b)], this special output port gives rise to a top event undesired state of the actual block. We will have an OR gate whose operands are: the internal failure of the exit part and all other eventual intermediate events that characterize failures coming from other input ports of the part. 3) Single Pattern: A "Single pattern" is an unique block that is not an entry nor an exit pattern (block B5 in Fig. 12 for example). The construction of the fault tree corresponding to this pattern is straightforward, based on the number of input and output ports of the block as shown in Fig. 15(a).

4) Feedback Pattern: By traversing the directed graph representing an IBD, if we encounter a node that has already been visited, then we have a loop or a "Feedback pattern" in the current graph. In Fig. 12, when generating the logic diagram for the output port o4-2 of the part B4, we need to take into account the input port i4 which comes from the output port o3 of the part B3. In its turn, the logic diagram of o3 must consider errors that may come from i3-2, propagated from B4. A cut can be realized here in order not to take into consideration the input ports such as i4 as an operand of the OR gate. The corresponding fault tree of the feedback pattern of Fig. 12 is illustrated in Fig. 14.

5) Redundant Pattern: When a part in an IBD receives item flows coming from redundant blocks that carry out the same system function, then we have a "Redundant pattern" (B2, B11, and B12 in Fig. 12). By using the safety profile described in Section III-B, the blocks B11 and B12 are stereotyped "redundant" and, in order to ensure consistency, the two blocks must be allocated to the same system function. In this case, an AND gate is used for different faults coming from different inputs to model the fact that if there is no internal failure in the component B2, the component will not work only if all the redundant item flows fail. The fault tree for our example of redundant pattern is given in Fig. 15(b). When the whole fault tree is generated automatically from an IBD using the identified patterns and a graph traversal algorithm, we will have a generic fault tree for the corresponding system top event. In order to have a specific fault tree for an undesired top event failure, information from previous safety analysis results, i.e., component FMEA can be used to refine this generic fault tree. Knowledge of safety experts is also very important in order to detail some branches with different failure modes or to cut out some unreachable branches, regarding the undesired top event failure. This proposal will be explained via the case study given in Section V-C.

C. Case Study

The starting point of this step is the logical architecture for the EMA given in Fig. 10. Based on this IBD, and according to the patterns and the depth-first search graph traversal algorithm given in the previous sections, the generic fault tree for the "Mechanical Power" output is automatically generated and given in Fig. 16.

Several undesired events can occur at each output. For each specific undesired top event, we can extract from the FMEA results of the previous steps related to the corresponding failure modes of each component that lead to the top event in question. The specific fault tree for the "Aileron locked" top event is given in Fig. 17. In this fault tree, a branch is eliminated because no failure mode of the geared motor with encoder leads to the "Aileron locked" event. Internal failure of some components such as geared motor with encoder and embedded MCU with power bridge is completed by their specific failure modes.

Our SafeSysE tool can generate fault trees in different formats. Actually, two options are proposed: the SVG image format useful for visualizing the fault tree and the Open-PSA model exchange format to make the results explorable by the XFTA engine [START_REF] Hibti | Overview of the open PSA platform[END_REF].

VI. CONCLUSION

The increasing complexity that characterizes new manufactured systems is a real challenge for designers, mainly for systems engineers and safety experts that deal with the whole systems. The question is how to perform safety analyses efficiently to have full benefit of their results and thus avoid costly and time-consuming redesign iterations. The main contribution of this paper is to deal with this issue by efficiently merging systems engineering process and safety assessment methods in a unique framework that we named SafeSysE. In this SysML-based MBSE approach, we automated the generation of some well-known safety assessment artifacts such as FMEA and FTA. We have extended SysML to integrate some safety-relevant concepts to better support safety analyses. A SysML safety profile has been developed for this purpose. This paper, we believe, contributes to tackling the current issues of designing complex safety critical systems. The automated generation of safety artifacts reduces the time spent in performing safety analyses and thus reduces the whole development time and increases the competitiveness. It also reduces error proneness since it automatically extracts the relevant information from system models. The consistency between the different safety analysis artifacts is also enhanced since, in each step of safety analysis, the results of previous analyses are explored.

As a continuity to this work, we will try to improve the consistency between the system model and the safety analysis artifacts by linking the safety properties of the system to modeling elements such as requirements. We will also examine the different possible ways to model dysfunctional behavior in SysML to improve the V&V of the system. Finally, scalability will be addressed to prove the adequacy of SafeSysE for larger and more complex systems, with different interacting components and state combination problems. Quantitative analysis about the performance of the suggested method will be carried out with different benchmarks.

We would like to thank the anonymous reviewers for their careful reading of our manuscript and their many insightful comments and suggestions.

Fig. 1 .

 1 Fig. 1. SafeSysE integrated process.

Fig. 2 .

 2 Fig. 2. Safety profile diagram.

Fig. 3 .

 3 Fig. 3. SafeSysE tool.

Fig. 4 .

 4 Fig. 4. Functional architecture of the EMA.

Fig. 5 .

 5 Fig. 5. Automatically generated functional FMEA.

Fig. 6 .

 6 Fig. 6. Functional FMEA completed by the safety expert.

Fig. 7 .

 7 Fig. 7. Updated AD for Control Aileron Incidence.

Fig. 8 .

 8 Fig. 8. Updated AD for Actuate Aileron.

Fig. 9 .

 9 Fig. 9. EMA logical structure with functional allocation.

Fig. 10 .

 10 Fig. 10. EMA internal architecture.

Fig. 11 .

 11 Fig. 11. Extract of the component FMEA of the EMA (the text in italics is generated automatically).

Fig. 12 .

 12 Fig. 12. IBD block design patterns.

Fig. 13 .

 13 Fig. 13. Fault trees for (a) entry and (b) exit patterns in Fig. 12.

Fig. 14 .

 14 Fig. 14. Fault tree for feedback pattern in Fig. 12.

Fig. 15 .

 15 Fig. 15. Fault trees for (a) single and (b) redundant patterns in Fig. 12.

Fig. 16 .

 16 Fig. 16. EMA generic fault tree.

Fig. 17 .

 17 Fig.17. EMA-specific fault tree for "Aileron locked" top event.

ISO

26262, an adaptation of the Functional Safety Standard IEC 61508 for automotive electric/electronic systems imposes a clear distinction between the concepts: the solution has to be developed independently with respect to the requirements as well as to the verification and validation (V&V) part. The separation is important because from the given requirements, various solutions can be defined. Also, as cited in[START_REF] Vismari | A practical analytical approach to increase confidence in software safety arguments[END_REF], the developed solutions must be evaluated by actors independently of the design process, which will promote a diversity of analysis while increasing the coverage and confidence levels of the safety conclusions. Of course, this is not in contradiction with an integrated framework where the traceability between the solutions and the requirements as well as the safety analysis will be respected.


Mourad Chibane

Faïda Mhenni

Jean-Yves Choley

Product-Process MBSE and Dysfunctional Analysis Approach Applied to a Production Line

Keywords: Dysfunctional analysis, MBSE, FTA, FMECA, Product, Process

The integration of new technologies and the increasing customer requirements in manufactured products requires more complex and automated production lines. Manufacturing processes are usually designed for a specific range of products. Thus, it is important to consider the dysfunctions of the product ans process conjointly. The aim of this paper is to propose a Model-Based Systems Engineering product-process approach for the dysfunctional analysis. This methodology consists in two phases: a functional analysis using SysML language for the system behavior and structure modeling, and a dysfunctional analysis using a combination of FMECA and FTA considering external intervention of the humans. This approach highlights the relations between the process and product failures and the importance of MBSE in the productprocess dysfunctional analysis.

I. INTRODUCTION

The manufacturing industry benefited from the technological advances in automation over the last twenty years to strongly enhance its performance and competitiveness. Today, the scientific and technological progress brings several possibilities of collecting information to enhance the piloting and controlling of the industrial production lines thanks to the presence of numerous sensors and control components integrated into the machines. However, this improvement is not well used because of a delay in the development of the production monitoring and piloting tools with regard to the development of the machines.

The fourth industrial revolution, that was first introduced by the German government through a strategical project, promotes the computerization of manufacturing and thus benefit from available technologies to the full extent. This initiative was later supported by other countries and regions [START_REF] Fantini | Placing the operator at the centre of industry 4.0 design: Modelling and assessing human activities within cyber-physical systems[END_REF]. Solutions proposed by the concepts of the Industry 4.0 allow to optimize data collection and analysis to convert it into real-time exploitable information for a better monitoring of the production processes.

The present work is done within the "EUGENE" project which aims at the modernization of the production lines in perfume industry in order to improve existing systems and make them compliant with Industry 4.0. These improvements shall enable an optimal exploitation of the production line and assure a better product quality. A multi-view modeling of the industrial scenario and a reliability analysis are the starting point to the expected improvements and play essential role in the realization of this project.

The reliability analysis aims at ensuring the good functioning of the production line during the exploitation by identifying and reducing the effects of potential failures. There are several methods for the reliability and safety analysis. The most used in the manufacturing industry and other critical sectors are the Failure Modes and Effects Analysis (FMEA) and Fault Tree Analysis (FTA).

FMEA is a systematic inductive method for reliability analysis. It aims at estimating the possible effects and causes of the potential failure modes. FMEA provides a classification of the failures using Risk Priority Number (RPN). FTA is a structured deductive method for the analysis and the identification of the internal and external causes of a failure. FTA provides both qualitative and quantitative analysis. Unlike FMEA which considers single component or function failures, FTA analyzes the combination of basic event failures that lead to a given system-level failure or faulty state (usually called top/ undesirable event).

The use of these methods for safety analysis requires a thorough knowledge of the studied system [START_REF]Analysis techniques for system reliability Procedure for failure mode and effects analysis (FMEA)[END_REF], [START_REF] Bertsche | Reliability in automotive and mechanical engineering: determination of component and system reliability[END_REF]. Thus, a system model is necessary to assure a good application of FMEA and FTA analyzes.

To model system under study, there are several methods, tools and approaches. Model Based Systems Engineering (MBSE) approaches using SysML language [START_REF]Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities[END_REF] is widely used to provide a descriptive architectural model of systems. SysML allows building structured system models with different views and traceability links enabling to efficiently conduct modifications on the systems and to compare various configurations or possible solutions.

However, most of MBSE approaches focus on the product modeling independently from its productions system. Due to the mutual interdependence between both the system (or product) and its production system, the latter should also be considered since early phases of the product design to enable the optimization of the product-process simultaneously. Such conjoint design highlights the inter-dependencies and thus helps in making better design choices as shown in [START_REF] Mhenni | Systems engineering approach for the conjoint design of mechatronic products and their manufacturing systems[END_REF].

This paper presents a methodology for improving an existing production line within the EUGENE project. The proposed methodology is based on a conjoint modeling and dysfunctional analysis of the product (perfume) and its production system in order to identify the critical points that need to be improved in the whole process while taking into account the product-process dependencies.

The approach starts with building a system model for both the product and the process and then uses these models to perform FMEA and FTA analyses for both the manufacturing process and the product in order to identify the ways in which defaults in the product influence the production line and failures in the production line lead to a quality default in the product. The critical points needing to be improved are identified at the end of the approach.

The remainder of this paper is organized as follows. Section II presents some related work on MBSE approaches and the integration of the safety and reliability analysis. Section III explains the proposed methodology for the productprocess dysfunctional analysis starting with the functional analysis using SysML and the dysfunctional analysis with the FTA and FMECA methods. A case study is presented in section V to illustrate the steps of realization of the methodology. Finally, the paper is concluded in section ??.

II. RELATED WORK

This section discusses related work about the integration of MBSE with safety and reliability analyses based on FMECA and FTA. Concerning MBSE approaches, SysML is one of the most used languages in both academic and industrial fields. Developed by the Object Management Group (OMG), SysML is a graphical systems modeling language with the objective of providing an easier and less ambiguous way for the description of complex systems. Indeed, it allows modeling of different complementary aspects of a system in a single model by offering several diagrams to represent the requirements, the structure and the behavior. It is used for MBSE in several works such as [START_REF] Mhenni | A SysML-based methodology for mechatronic systems architectural design[END_REF] that presented a SysMLbased methodology to design mechatronic systems starting from the initial requirements until the synthesis of a system architecture that respects them. SysML is also complemented with other techniques such as artificial intelligence in [START_REF] Chami | Towards an integrated conceptual design evaluation of mechatronic systems: The sysdice approach[END_REF] where an approach called SysDICE is presented for the conceptual design and evaluation of mechatronic systems.

Mhenni et al.

Other works also attempted to integrate safety analysis within SysML-based MBSE approaches. For instance, Mhenni et al. [START_REF] Mhenni | SafeSysE: A safety analysis integration in systems engineering approach[END_REF] complemented the methodology presented in [START_REF] Mhenni | A SysML-based methodology for mechatronic systems architectural design[END_REF] with the integration of safety and reliability analysis and proposed an approach called SafeSysE. This approach uses SysML language for the critical system modeling then performs the safety analysis by automatically generating safety artifacts such as (partially filled) FMEA and FTA from the system models. Safety analysis is performed based on the generated artifacts and the resulting safety requirements imply changes in the system design to take into account the results of the safety analysis.

Evans et al. presented a methodology in [START_REF] Evans | Towards a framework for reliability and safety analysis of complex space missions[END_REF] to perform safety analysis for a NASA system designed for a long duration mission. Based on an MBSE approach, they represented the system with SysML under various views. Then, based on the information provided by the system model, they implemented an automatic extraction of the FMECA. In addition, FTA is performed on top level events selected from the system effects list in the previously generated FMECA.

Several similar works can be found in literature such as [START_REF] Helle | Automatic sysml-based safety analysis[END_REF], [START_REF] David | Reliability study of complex physical systems using sysml[END_REF] to cite a few. However, although the proposed methodologies help in bridging the gap between safety analysis and MBSE, none of them considered the human factors as a cause of the failure while human errors play a significant role in causing system failures.

A number of studies have postulated a convergence between FMEA or FMECA and FTA. Indeed, there are two main approaches in the application. In one side, the recursive manner, starting with the FTA to identify the failure modes and after that the application of the FMEA proposed by Peeters et al. [START_REF] Peeters | Improving failure analysis efficiency by combining fta and fmea in a recursive manner[END_REF]. On the other side starting with the FMEA and develop the resulted effects using FTA the most used one [START_REF] Evans | Towards a framework for reliability and safety analysis of complex space missions[END_REF]. However, the FMEA Risk Priority Number (RPN) present weakness in the real appreciation and signification in the case of an equal Number. Other approaches are proposed to calculate the RPN like Fuzzy FMEA to Separate the priority of intervention, but it remains an ambiguous task for the application [START_REF] Zhu | Failure mode and effect analysis for wind turbine systems in china[END_REF].

III. METHODOLOGY

In order to perform a complete safety analysis for a given system, the international standards such as [START_REF]Analysis techniques for system reliability Procedure for failure mode and effects analysis (FMEA)[END_REF] recommend relying on a thorough knowledge of its architecture and functioning. These aspects can be described in the system models using languages such as SysML, that provides designers and experts with graphical multi-level views of the system. Consequently, the first step of the proposed approach is to build a system model with SysML. When it comes to dependability, FMEA and FTA analyses [START_REF] Aizpurua | Model-based design of dependable systems: Limitations and evolution of analysis and verification approaches[END_REF] are among the most widely used techniques for reliability and safety.

They focus respectively on the failure effects and propagation in the studied system. However, they are usually performed without a close collaboration with system designers.

In this paper, we propose a methodology that:

• strongly connects design to safety analysis since the latter is based on MBSE models.

• takes into account the inter-dependencies between the product and its production system. The proposed integrated approach combines the MBSE approach and safety and reliability analysis of both the product and its manufacturing line. First, the MBSE approach provides the necessary information about the system/product and its production line. Then, dependability analysis is performed through FMEA and FTA techniques based on the information provided by MBSE models. The steps of the proposed approach and their relationships are presented in Fig. 1.

As, for this work, we aim at improving an existing system, we start our MBSE modeling from the functional view given by the SysML activity diagram. After that, the Block Definition Diagram and Internal Block Definition Diagram is used to model the structure of respectively the product and its production line.

A. MBSE System Model

In this first step, the nominal model of the system in built using an MBSE approach with SysML language. The functional architecture, system structure and components interactions are respectively modeled for both the system and its production line.

1) Functional architecture: SysML activity diagram is used to model the activities or functions performed by the system under study be it the product itself or the production line.

The SysML activity diagram provides a general view about the functional breakdown of the system and the different flow transformations among the functions and sub-functions represented by activities or actions in SysML. The breakdown may be performed into several levels until it is obvious to identify the components to be allocated to the functions.

2) System Structure: After the different functions are identified in the activity diagram, a Block Definition diagram provides the composition of the system considered as the main block and the hierarchy of the components that constitute it, be they software or hardware. As a Structure Diagrams, the BDD adduces information about the structure of the system by specifying their role and their quantity. Each component can be the object of a more detailed description by specifying its components.

3) Components Interactions: The final step in the MBSE part of the process is to model the interactions among the components. This is achieved through an IBD diagram in accordance with the previous steps, i.e. the flows exchange in the functional architecture and the components allocation. Indeed, all the system components declared in the BDD are automatically included as parts in the IBD. In other words, the IBD is an internal view of blocks and it provides information about connections between the components. The logical organization and the functional distribution of components are clearly shown. Based on the in, out or bidirectional flow ports, the IBD highlights the physical and/or signal flows circulation in the represented system by the directed links between the parts.

B. Safety Analysis

Once the system model is built, a dysfunctional analysis is performed to identify the critical points that need to be improved. This analysis begins with an FMECA in order to identify the potential causes and effects for the failure modes and their criticality. Then, an FTA is performed to represent the possible combination of basic events which engenders the undesired event.

1) Failure Mode Effects and Criticality Analysis (FMECA): FMECA is a systematic widely used method for the analysis of dependability in several domains to determine the causes and effects of the defined failures modes in a technical system. It is a deductive and bottom-up method [START_REF] Bertsche | Reliability in automotive and mechanical engineering: determination of component and system reliability[END_REF]. The analysis starts from the functional or components level, determines the failures modes of each element (function or compnent) to identify the consequences of each failure mode at the system level. The FMECA is performed by a safety experts. The inputs of an FMECA are the functions and/or components and should be provided by the designers or MBSE team. FMECA includes a criticality evaluation to classify the failure modes based on a Risk Priority Number (RP. The RPN is the product of three indicators: an occurrence indicator (O), a severity indicator (S) and a detection indicator (D) [START_REF]Analysis techniques for system reliability Procedure for failure mode and effects analysis (FMEA)[END_REF]. The weakness of the traditional FMECA is that in the case of an equal RPN for two different failure modes the determination of the most important one is not done. In this paper, we propose a modified FMECA to solve this problem by the addition of criteria based on the effects on the product in the case of a process FMECA and the effects on the process in the case of the product FMECA. The classification of the effects is given in the TableI and range from "No effect" to "Major effect". The rates for the parameters O, S, D are also determined by the industrialist for both the product and the process and range from 1 to 4.

2) Fault Tree Analysis (FTA): FTA is a deductive reliability analysis method based on a deductive process from an undesired event to a potential combination of failures that causes it, called basic events for the FTA. It is a top-down method based on the directed cyclic graph (Tree) composed Fig. 2. FCMachine Activity Diagram of two types of nodes "events and gates [START_REF] Ruijters | Fault tree analysis: A survey of the state-of-the-art in modeling, analysis and tools[END_REF]. The inputs of a complete FTA analysis for the liability is the knowledge of the studied system and the detailed information about the functioning and the relations between the components of the system. Information provided by the functional analysis done using MBSE. In addition, the definition of the top event to start the FTA is an important step of the analysis. Indeed, the top event is provided by the FMECA analysis performed on the same system. The FTA can be performed on a process as well as a product.

IV. CASE STUDY: THE PERFUME PUMP INSTALLATION

In this section, the proposed methodology (Fig. 1) is applied on a case study. To give a simple overview of a part of the studied system to better understand the process of achieving the methodology. First, the functional analysis of the two systems is given in the section IV-A. Second section IV-B, the application of failure analysis and discussion of the results. Because of the lack of space constraints and clarity, we only show a part of the system.

A. MBSE System Model

For the case study the functional architectures of the product and its production line are both modeled using activity diagrams. For the production line, two different activity diagrams are built, one for the whole production line describing the different steps for the production of the perfume (the filling and the assembly of the different components of the perfume bottle) given in Fig. 2 and another focusing on the pump pose given in Fig. 3.

The functional architecture of the product (perfume bottle) also modeled is not presented in this paper.

Once the functions are identified, the composition of the product and the production system are both modeled by allocating the components to the appropriate functions and then building a Block Definition Diagram to describe the structure (composition). Fig. 4 shows the composition of the production line. The product components will be shown directly in the next step. The multiplicity (number at the At this level, we are able to model the interactions among the identified components to show the different flow exchanges among them. For the production line, a first level IBD is shown in Fig. 5. This diagram shows that composed of four main subsystems: the "Juice Circuit", the "Bottle Circuit", the "air Compressor" and the "Electric Power Supply". In the following, we will be interested in the dysfunctional behavior of the "Pump Placing System" that is part of the "Perfume Bottle Circuit". The IBD of this sub-system is thus given in Fig. 6.

The product models are realized following the same steps as for the processes and due to their simplicity, we only provide the IBD showing the flow exchange for the perfume bottle in Fig. 7.

B. Safety Analysis a) FMECA:

The failure modes that we choose for the application of FMECA on the subsystem are: "fail to perform" and "performs incorrectly". Based on the functional analysis we extract manually the components list and their functions in the system to constitute the first FMECA worksheet. After that, the safety team experts directly add the information about the Occurrence, Severity, Detectability, and effect on the product or effect on the process based on the available rating tables.

For the process FMECA, we considered that the composition of the studied system is a set of the functional chain of an automated system. So, each component is a separate chain made up of an effector and an actuator. Indeed, the generic causes of the failures are parts of the functional chain. In addition to that, we take into account the human, product, and interaction of the product and process causes. For the product FMECA we propose a generic list of causes chaired by all the system components. The MBSE models provide the expert team with a multi-view and multi-level model of the system. Information about the occurrence, severity and detectability are extracted from the data collected during the operation of the production line. However, the values provided here are only approximate. The complete FMECA for the function "Aspiration of the juice to spray it in the air" is given in Fig. 8. The last column gives the effect of each failure of the product on the process itself and this effect is also considered b) FTA: Fault trees are then built for each critical system effect identified in the FMECA. Taking the considered system effect we want to mitigate as a top event of the fault tree, the combinations of causes leading to that event are identified through the construction of the corresponding FT. Solutions such as redundancy or higher reliability should then be considered in enhancing the system by eliminating single failure points. The fault tree for the "Dip tube outside the bottle" is given in Fig. 9 C. Discussion

The modeling of the product and the process using SysML allowed us firstly to have a global view on the functioning of the system and its structure by providing the multi-view and multi-level models, and secondly to establish a consistent basis for the dysfunctional analysis with the use of FMECA and FTA method, and to take into account the relations between the production system and the product. The case study provides a clear and practical example of the proposed approach. The SysML modeling allows us to perform a reliability analysis in an easier and consistent manner, with less time needed. The deployment of the method provides reliability information on both the manufacturing system and its product, taking into account all components and the relation between the production system failures and the product defects.

The FMECA highlights potential causes and effects of a failure mode of each component separately. The FTA provides a mapping of the combination of failures which may generate the undesired top event, taking into account the relationship between the components of the system. These analyses generate change recommendations on the production system and the product in order to avoid potential failures.

However, implementing this method comes at a cost since a dual product-process system modeling has to be performed. This may be a heavy task for a highly complex manufacturing system, but this kind of modeling can be reused and adapted if it is applied to a family of systems. A real added value may come with a partially automated generation of FMEA and FTA artifacts, thus reducing the whole modeling and analysis task.

V. C ONCLUSION AND FUTURE WORKS

In this paper, we have proposed a Model-Based System Engineering approach for the reliability analysis on a perfume manufacturing line and its product. They are both modeled using SysML modeling language with Activity Diagram, Block Definition Diagram, and Internal Block Definition, providing a multi-level and multi-view modeling of the structure and the functioning of the whole productprocess system, thus allowing experts to perform a consistent reliability analysis using FMECA and FTA to determine the potential process failures and their effects on the product and the potential failures of the product and their effects on the process functioning.

We also suggest a modification in the priority classification of the Risk Priority Number depending on the effects of the process on the product in one hand, the effects of the product failures on the process in the other hand, in the case of an equal RPN.

Our next research studies will extend the use of these SysML modeling, FMECA and FTA to support diagnostic during the production.

Fig. 1 .

 1 Fig. 1. Steps of the Proposed Approach

Fig. 3 .

 3 Fig. 3. Pumps installation Activity Diagram

Fig. 4 .Fig. 5 .

 45 Fig. 4. FCMachine Structure Diagram (BDD)

Fig. 8 .

 8 Fig. 8. Product FMECA Extract

TABLE I EFFECTS

 I APPRECIATION FOR A FAILURE ON THE PRODUCT AND PROCESS.

ACKNOWLEDGMENT

The work presented in this paper has been performed during the Eugene Project founded by the French government.