=Paper=
{{Paper
|id=Vol-1728/paper6
|storemode=property
|title=SySTEMA SYstem & Safety Tool for Executing Model-Based Analyses
|pdfUrl=https://ceur-ws.org/Vol-1728/paper6.pdf
|volume=Vol-1728
|authors=Alessio Costantini,Sergio Di Ponzio,Rodolfo Mazzei,Francesco Inglima,Andrea Chiellini
|dblpUrl=https://dblp.org/rec/conf/ciise/CostantiniPMIC16
}}
==SySTEMA SYstem & Safety Tool for Executing Model-Based Analyses==
https://ceur-ws.org/Vol-1728/paper6.pdf
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