SySTEMA SYstem & Safety Tool for Executing Model-based Analyses Alessio Costantini, Fancesco Inglima, Rodolfo Mazzei, Sergio Di Ponzio System Engineering Local Expertise Center ALTRAN ITALY alessio.costantini@altran.com, francesco.inglima@altran.com, rodolfo.mazzei@altran.com, sergio.diponzio@altran.com Andrea Chiellini, Cristina Biagi RAM and Safety Local Expertise Center ALTRAN ITALY andrea.chiellini@altran.com, cristina.biagi@altran.com Copyright © held by the authors. Abstract — This paper presents SySTEMA, an innovative approach to perform Safety Analyses on complex systems, based I. INTRODUCTION on the modelling of their functionalities, behaviors and SySTEMA ("System & Safety Tool for Executing Model-based architecture. System safety analysis techniques are well known Analyses") is an innovative approach that will allow to analyze the and are extensively used during the design of safety-critical Safety of complex systems, which typically are used in the field of systems. Since these analyses are highly subjective and dependent aerospace, defense, rail and automotive industries. on the skill of the practitioner, it is unlikely that they will be Safety analyses are currently carried out to support the design of complete, consistent and error free. In fact, the safety engineers "safety critical" systems, according to a traditional approach, i.e. devote much of their effort to find undocumented details of the starting from the documentation usually drawn downstream of the system behavior and to embed this information in the safety detailed design of the system. artifacts such as the fault trees. Most of the review effort is As a consequence, this approach often leads to analyze the system focused on uncovering and resolving misunderstandings and safety late and in ineffective way. missing information in the system design or the informal fault Moreover, being based on the interpretation of the documents model. Model-Based Systems Engineering (MBSE) is a describing functionalities and architecture, these analyses can present methodology aiming to design and develop complex and/or problems of completeness, consistency and subjectivity, because highly dependent on the experience of the Safety engineer performing critical systems, increasing productivity by promoting the activities. communication among different teams working on the same The proposed project aims to overcome the above cited problems project. Model-Based Safety Analysis (MBSA) is an emerging by using an approach based on the realization, through the use of a discipline that extends MBSE performing safety analyses in a graphical language standard, called SysML, of a unique model, which ‘model-based’ context, by building system models (both for is representative both of the functional/architectural characteristics and nominal and fault behavior), reducing the effort and increasing of the behavior of the system when a failure occurs. the quality of the final results. MBSA follows a failure analysis Specifically, the idea is to define the most appropriate approach, starting from the major state-of-the-art techniques methodology to model the fault types and the effects that they may such as Failure Mode Effect and Criticality Analysis, Functional have about the different features of the system. Analysis, Functional Hazard Analysis and Fault Tree Analysis. The main objective of the proposed project is to realize an This paper describes a theoretical approach to implement MBSA innovative tool (SySTEMA) to perform Safety Analyses on complex using one common SysML model of the system. This allows the systems, by using Systems Modelling Language (SysML). systems engineers to perform automated safety analyses to MBSA modelling approach has been evaluated by comparing receive quick feedback on their design decisions during the FMEA and FTA analyses carried out with traditional methods with the system design phase. ones generated by SySTEMA (MBSA tool). Keywords—MBSE; MBSA; SysML; FMEA; FTA. 1 Copyright © 2016 da Altran Italia SpA. Permesso concesso ad AISE di pubblicare e utilizzare. II. BACKGROUND A FTA is a model that graphically and logically represents the combinations of failures occurring in a system that lead to an This section briefly describes the steps in the SysML modelling hazardous condition. and safety analysis process considered in this study. FTA uses a “top-down” approach, in order to identify all potential causes of a particular undesired top event. A. SysML Modeling Starting from the Top Event, the analysis systematically determines all possible causes, both single fault and combination of The SysML approach used in this study considers the operational faults, at the subsequent lower levels until a Basic Event is analysis, functional analysis and architectural analysis [1]. encountered. The operational analysis will define the main use cases (UC) of A Basic Event is defined as an event that is no further developed the system, with a particular focus on the UC significant from a safety into a lower level of detail. If a basic event is attributed to items viewpoint. The primary goals of this analysis shall be: failures, it can be extracted from item failure modes analyzed in • The definition of the system environment from the user FMEA. perspective, by identifying all the entities that directly As shown in Fig. 1, the fault tree development includes two types interact with the system (actors). of symbols: event and logic gate. An event symbol is used to describe • The identification of the most significant UCs from a safety an existing condition or a physical event. A logic gate is used to tie standpoint, to be detailed by the functional analysis. together the events and to show the logical relationship among them. The functional analysis will allow to summarize the key functions of the system when it is in a specific UC. Each main function will be decomposed in lower hierarchical level functions that can be furthermore decomposed following an iterative process, in order to obtain a functional breakdown. The lowest functional level will be mapped to an architectural subsystem or component (allocation). The functional analysis will also allow to represent the system behavior, which can be modelled by means of different behavioral diagrams: • State Machine Diagrams (SMD), to represent the states, the transitions and the actions that the system will perform in response of well-defined events. • Sequence Diagrams (SD), to represent the event-based Fig. 1. FTA Events and Gates behavior, representing flow of control and describing interactions among system parts. This FTA method produces Boolean logic models representing the logic relationships between events leading to a final condition. The The architectural analysis will allow to describe the system in Boolean model is suitable to produce both qualitative and quantitative terms of internal components decomposition (subsystems or results. The qualitative results of the Fault Tree model is represented components) and functional interfaces description. Typical diagrams by the possibility to have a clear understanding of all the used in this phase are: combinations of failure events, which can cause the 'top event' • Block Definition Diagrams (BDD), to define the system, (Minimal Cut Sets). As for the quantitative aspect, the logical model by means of associations and composition relationships. of FTA is moreover suitable to evaluate the probability of occurrence • Internal Block Diagrams (IBD) to describe the structural of the top event based on the failure rates of basic events, exposure aspect of the model, defining how the different items times, and the Boolean Model that is at the base of the Fault tree collaborate and exchange information to realize the development. behavior of the entire system III. SYSTEMA APPROACH Functional and architectural analyses are typically performed in parallel, through an iterative process which will converge towards the SySTEMA approach consists of a framework for System Engineer final system architecture. Once the two analyses will be complete, and Safety Engineer containing: each function should be mapped to only one architectural element. • Theory and Fundamentals: definition of the theoretical approach representing the foundations of SySTEMA B. Classical Safety Analysis • Operative Guidelines: definition of modelling rules, The classical safety analyses considered in this study are the constraints and step-by-step descriptions of actions to be Failure Mode Effects Analysis (FMEA) and the Fault Tree Analysis performed with a tool. (FTA). • A tool: Commercial Tool + Altran SW Application. The FMEA is a “bottom-up” analysis based on a single-failure • A proof-of-concept (demonstrator): a tangible model of a approach and executed on each system item or functional block, case study to see how FMEA and FTA analyses can be according to the following main steps: automatically performed by the SySTEMA tool. • Identification of credible failure modes; • Evaluation of each single failure mode effects at different The theoretical approach develops a process that leads the levels up to system one; engineers to develop a model of the system on which the • Evaluation of severity of the failure effects consequences; SY.S.T.E.M.A tool can automate the generation of FMEA and FTA • Identification of failures detection method; analyses. • Assignment of the failure mode rate based on item A. Process reliability and apportionment criteria. The process of SySTEMA is shown in Fig. 2. It is divided into three main phases and consists of seven steps that engineers need to follow in order to automatically generate the FTA and FMEA analysis. 2 The process includes a phase in which to update and enrich the SysML model according to the criteria described in the following chapters. If the model does not exist, the same criteria can be used to define the entire architectural model of the system. The goal is to extend the model with stereotypes allowing to the SySTEMA tool the interpretation of the system information and produce the analysis. Furthermore, the approach describes the way to define the operations and their allocation in the same model. Finally, not least, this first phase defines the way for the allocation of the failure modes in the model. The definition of failures remains an activity related to the best practice of safety domain. In the second phase of the process, the engineers shall model the system in nominal behavior and in presence of failures. The modeling of the behavior takes place through an abstract way, very close to a logic level description of a system, but which can be used both to describe the high-level functional behavior and the lowest level physical one. The description of behavior is a sequence of messages Fig. 3. SySTEMA Tool-Chain with abstract parameters. This permits to describe any system as an algorithm, using three fundamental constructs (Böhm-Iacopini, [2]): the sequence, the selection, the selection and the cycle (iteration). This IV. SYSTEM’S ARCHITECTURE MODELLING approach can work thanks to abstraction of the logic of VALUE TAGs (described in par. V.B), that allows to express more situations The system architecture has to be adapted according to the (functional, logical and physical) with a language easily integrated in guidelines & fundamentals and enhanced with dedicated stereotypes. the FMEA and FTA formal output. A. System Architecture Update Finally, in the last phase will be defined a scenario trough a Use Case of the system in order to obtain the FMEA and FTA Starting from an existing (and maybe complex) model of the automatically. In the next paragraph the three macro steps of the system architecture, System and Safety Engineers will have to identify process are described in detail. the levels of interest on which SySTEMA will be able to perform the Safety Analyses. The architectural level of each block will be “classified” through a specific stereotype (see Fig. 4) in order to identify three indenture levels of interest, required to perform the FMEA analysis according to MIL-STD-1629: • ≪Local Level≫: level of the specific item being analyzed. • ≪Next Higher Level≫: next higher indenture level above the indenture level of the specific item being analyzed. • ≪End Level≫: the highest (root) indenture level. Typically, the ≪Local Level≫ is associated to “elementary” blocks of system architecture (items not further developed). Fig. 2. SySTEMA Process B. Tool SySTEMA tool is a general purpose tool that can operate with different MBSE commercial tools in order to obtain the automatic generation of safety analyses. For this study it has been developed only an interface for Artisan Studio. The output of the tool is an Excel Sheet. The tool can simulate the behavior of the model thanks to the Fig. 4. Architectural Update SySTEMA profile defined in the MBSE tool with custom stereotypy. The graphical output of FTA, in classical view, is made by a SySTEMA will use the system structure, described through an commercial tool. Internal Block Diagram (IBD) (see Fig. 5), to extract the The entire tool-chain is described in figure 3, the MBSE tool is the interconnections between the elements of the system. base of information of the model. Through a Visual Basic (VB) All the connections must be modelled by means of: software, the static model is simulated in order to obtain the FMEA • Connectors between elements (SysML Block Properties) and FTA analysis. The VB software provides a tabular output suitable • Connectors between ports to be manipulated to obtain a typical output of safety analysis. 3 Fig. 7. Hierarchy of Operations Fig. 5. Interconnections between elements SySTEMA can manage different levels of the system architecture C. Failure modes allocation and the corresponding levels of abstraction: Failure modes identification is a safety activity that consists in • Functional architecture, which defines a solution- generating a list of failure modes for each architectural block of the independent representation of the design; it is composed by system, classified in the BDD as ≪Local Level≫. pure functions. Failure Modes are characterized by the following features: • Logical architecture, which represents an intermediate • Failure Description: description about how a failure abstraction between functional and physical architecture. occurs (free text). Blocks of a logical architecture represent abstractions of • Failing Entity: type of failure. physical solutions. • Failure Behavior: input for Integrated System Behavior • Physical architecture, which gives the physical resources Modelling. to perform the system functions. SySTEMA allows to manage any type of failure modes, For each level of abstraction, the architecture will contain several depending on the level of abstraction assigned to the ≪Local Level≫ blocks implementing high-level or low-level functions. In SysML, blocks. This goal is achieved by considering the following failure when a function is defined in a block, it is called Operation. An modes types: Operation is the specification of a behavioral feature of a block, at any • OUTPUT: failure mode affecting the out-coming signal of level a ≪Local Level≫ block. • FUNCTION: failure mode affecting the function of a B. Operations definition and allocation ≪Local Level≫ block. Functional analysis, already performed by Systems Engineers on • COMPONENT: failure mode affecting physical existing systems, will be used by SySTEMA as a reference for the components. “Operation Definition”. No particular constraint is imposed to functional analysis, thus it can be performed according to the For physical architectures the failed output will be a physical identified level of abstraction. In functional architecture the operation signal, for functional architectures the failed output will be a function. of a block is strictly connected to the system functions. In For physical architectures, the failure will affect one or more logical/physical architecture each block can have one or more physical signals of the failed block, for functional architectures the operations, according to design choices; as an example, a System failure will affect one or more functions of the failed block (see Fig. Engineer can split a function into more than one operation of a 8). component, or can group more functions in an operation of a Component failures are applicable only to physical architectures, component (see Fig. 6). including for example (not exhaustive list): Mechanical parts, Switching devices, Capacitors, Connectors, Integrated Circuits, Optical, Lamps, Resistors, Semiconductors, Microprocessors. The output failure modes currently managed by SySTEMA are: • Analog Signals (threshold, single value): – Loss – Above/Below Threshold • Analog Signals (boundaries, in between): Fig. 6. Functions vs Operations – Loss – Out of Range The operations must be hierarchically traced among the levels of a – Stuck in Range system, in order to propagate the effect of the operation from local • Digital Signals (boolean): level to system level (see an example in Fig. 7). The hierarchy – Stuck at logic HIGH depends on the Operation Definition and it will be defined by means – Stuck at logic LOW of a specific stereotype. In this way it will be possible to identify for • Digital Signals (enumerated): each operation its Father Operation. – Stuck at specific value The function failure modes currently managed by SySTEMA are: • Analog Signals: – Double set of analog signals – Short from In and Out – Short From In and Out with set of a third signal (Status signal) 4 • Digital Signals: Parameters must assume specific tag values, corresponding to the – Double Stuck at logic level HIGH or LOW state of the signals (i.e. input or output of the associated operation). – Short from In and Out B. Operations and Tag Value – Short From In and Out with set of a third signal (Status signal) An operation describes how the input affects the output according to a cause and effect principle (see Fig. 10). For each local level block, System Engineers will have to allocate Tag values represent the foundations of MBA, because they are failure modes to model through stereotypes. used to describe different states of input and output signals (see Fig. Function/Component failing entities will be associated to 11). operations and Output failing entities will be associated to signals. The approach requires to treat a component as a black box and the associated operation, which “transforms” inputs into outputs, is assumed to be a cause-effect. Fig. 8. Failure modes allocation to model Fig. 10. Cause-Effect V. SYSTEM BEHAVIOUR MODELLING The state of inputs and outputs will depend on the context of the The system behavior follows two scopes: definition of the considered system. It can be a classification or a grouping of the real behavior and its modeling. The definition (see Fig. 9) is an activity values of a signal; e.g. Analog Values in a Range or out of a range, that has to be performed by both system and safety engineers, in order digital signal in a specific discrete values (see next figure). Otherwise, to obtain the information useful to model the behavior. Based on the it can be a specific condition of a signal or a function (i.e. signal loss, definition, the system engineers shall model the behavior. This model missed function and active function). Finally, it can be a condition use an approach based on the Sequence Diagram described in the next which may be considered valid for different values over time in the paragraph. specific analysis. In this way also the temporary effect can be handled in a single state. Fig. 9. Behaviour definition and modeling Fig. 11. Tag Value A. Message-Based Approach The Operations can describe different levels of abstraction by System behavior is described by means of Operations described using different classifications of tag values (corresponding to different with the Message-Based Approach (MBA). states of inputs and outputs). MBA consists in the usage of sequence diagrams (OSD) to represent the interaction among elements/components/items of a C. How to define Tag Values system as a sequence of message exchanges. Tag values will depend on the level of abstraction. In the Fig. 12 is Messages can be external events, signals or failure events. The reported an example. The example of the light in a room allows to interaction can be: understand how the Tag Value, using different meaning of the tags, • between the system and its environment (external event) can help the engineer to work at three level of abstraction. In • between the elements/components/items of a system functional description, the operation has the functionality to light the (signals) room. This functionality, in a logical view, can be considered as an • by means of a failure mode (failure events). ON/OFF signal, able to switch on/off a light. In the physical level, after some design choices (use the 220V voltage and physical contact), Messages can have parameters representing the information the operation describes the physical behavior of the switch. content. 5 Fig. 12. Tag Value at different levels Fig. 16. Failure Tag Value in different levels D. Failure mode injection E. Cause and effect Failures will affect operations depending on the failure mode type: • Output failure will impose the tag value to the associated The fundamental assumption in MBA is «If Causes Then signal, see Fig. 13 Effects». MBA will use the constructs defined as follows: • Function or component failure will impose the behavior to the associated component: see Fig. 14 TABLE I. CONSTRUCTS Both failures can generate new tag values for the output of the ID Construct operation. 1 If Causes then Effects 2 If Causes1 OR Causes2 then Effects 3 If Causes1 AND Causes2 then Effects • Causes: Start, Input Messages, Sequences. • Effects: End, Output Messages, Sequences. Fig. 13. Output Failure • Sequences: combination or loop of multiple constructs (ID1, ID2, ID3). Similarly to Böhm-Jacopini theorem, it is assumed that any operation can be implemented by using only the following elementary structures (to be applied also recursively): the sequence, the selection and the cycle (iteration). All the above cited structures are part of the OSD semantic, as Fig. 14. • Function or component failure reported into the following table: TABLE II. TABLE STYLES A failure mode could require the definition of new tag values (w.r.t. the nominal behavior) in order to manage the following Structure Element SysML OSD behaviors: the sequence SEQ • Behavior associated to an internal failure of the block itself • Behavior associated to input signals affected by a failure the selection SEQ , ALT and PAR which has not been previously managed the cycle (iteration) LOOP For this reason, SySTEMA makes use of OSDs to model an operation as in the example in the Fig. 17. Fig. 15. Failure impact beetwen components Tag values will depend on the level of abstraction. The failure mode could use new tag values (bold), see Fig. 16. Fig. 17. Sequence Diagram for Cause-Effect behavior 6 The failure can be represented by a single message (failure in In FTA simulation, for each use case (in a specific state of the output) or by a sequence of multiple messages (failure in function or system), Safety Engineers will have to identify the undesired top component). events, on the basis of the hazard analysis performed with the classical methods. B. Simulation of System’s Behaviours The core of Safety analyses generation is represented by the simulation of System behaviors:  Nominal behavior simulation: values assumed by all the output signals (one value for each system status in a specific Use Case) without failure injection.  Failure behavior simulation: values assumed by all the output signals (one value for each system status in a specific Use Case) upon injection of one or any combination of failures. Fig. 18. Sequence Diagram for failure Safety analyses generation relies upon the organization in different State Diagrams (STD) and Activity Diagrams (AD) can be used in databases (tables) of the integrated information relevant to the system SysML to describe sequences, selections and iterations, but they are definition: not the right diagrams to implement the MBA because:  List of functions: table reporting the functions  OSD is a more intuitive diagram to implement a cause- breakdown structure (hierarchy and dependency). effect logic. The typical OSD steps (seq, alt, par, loop)  List of system: table reporting the system breakdown can be easily mapped to the MBA construct (Sequence, structure (hierarchy and dependency). Selection, Cycle);  List of outputs: table listing all outputs and providing  Description of messages exchange between blocks is also the reference to the relevant block within List of more complex with STD or AD, than with OSD; System.  In STD most of the MBA constructs have to be described  List of failures: table listing all the failure modes and in text mode and not in graphical mode; providing also the reference to the related failing entity  It is easier to implement a Reverse navigation for FTA within List of outputs (output failure) or within List of (to perform a top-down approach), by using OSD than functions/System (function/component failure). STD or AD;  STD and AD are less integrated with IBD than OSD; C. FMEA Algorithm  OSD can be added as a new layer to an existing model behavior, with no impact to the already defined states of The FMEA algorithm consists in the comparison of the nominal a block. behavior with faulty ones (i.e. corresponding output values) in order to identify impacted outputs and involved functions, as shown in the following figure. VI. SIMULATION & OUTPUT GENERATION SySTEMA will generate the FMEA and FTA output, through simulations of system behavior. A. Preliminary operations The simulation is configured by means of Use Cases diagrams. UC represents the operative scenario inside which the system will operate. Use cases will consist of the following entities:  Actors (operator, user, environment, …)  System under analysis  External events System behavior is strictly dependent on external events. In Fig. 20. FMEA algorithm SySTEMA Use Cases will be described through OSD, as in the following figure. The actor, through external signals, stimulates the system in a specific scenario. Different uses of the system will be Since SySTEMA compares output values to define failure effects, described by different use cases. the goal to generate a FMEA, according to MIL-STD-1629, is obtained by classifying system outputs on 3 different levels: • LOCAL LEVEL OUTPUT: output signal from Local (Component) level block. • NEXT HIGHER LEVEL OUTPUT: output signal from any intermediate level block. • SYSTEM LEVEL OUTPUT: output signal from System block. According to MIL-STD-1629, FMEA output is provided in Fig. 19. Simulation Scenario tabular format as the table in Fig. 21. 7 • Identify in a timely manner any critical issues related to the impact of failures on the functionality of the system; • Facilitate and make unique understanding of the logic of the system; • Perform main safety analyses (FMEA, FTA) in an automated way thus receiving a rapid feedback, resulting in immediate impact on design choices. From that it follows that an integration have to be applied between the systems engineering domain and the safety domain. For this, SysML was extended to include safety-related information. Since Fig. 21. FMEA: Example of Output from SySTEMA these extensions are realized by stereotypes, applying it to existing SysML system models requires almost no additional modeling effort. At present, SySTEMA has been tested only on a limited type of D. FTA Algorithm systems (i.e. limited types of nominal and faulty behaviors). A The FTA is a “Top-Down Navigation” (in reverse direction) of the reference library has been created starting from the analyzed systems, OSDs in Non-Nominal behavior, starting from top event (see Fig. 22). with the purpose to support systems and safety engineers in the description of system behavior through Sequence Diagrams. Next steps will be to enrich the reference library with new systems behaviors or failure modes which are not currently taken into account. REFERENCES [1] http://www.omg.org/spec/SysML/1.3/ [2] Bohm, Corrado; Giuseppe Jacopini (May 1966). "Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules". Communications of the ACM. 9 (5): 366–371. doi:10.1145/355592.365646. Fig. 22. Top-Down Navigation SySTEMA will generate an EXCEL file with a table as Fig. 23, containing the list of all the logic conditions which are the basis to build the FTA graphical tree. Fig. 23. FTA: Example of Output from SySTEMA VII. CONCLUSIONS The SySTEMA approach developed in this work was motivated by the idea of an automated, integrated, operational-oriented and model based safety analysis of architectures modeled in SysML in a single tool. In doing so, this SySTEMA approach aims to enhance the classical safety analysis working on a unique model suitable for both safety and design purpose. The creation of such a model will allow to: • Think about safety since the starting phases of functional and architectural design; 8