An integrated design methodology for safety critical systems

Abstract

Nowadays man-made systems are getting more complex including new technologies and components from different domains. In addition, they are used in many safety critical missions. This induces new challenges in the design of such systems as new methods and tools are needed to manage the complexity while taking into account safety aspects. To face these challenges, the use of model-based approaches such as MBSE is compulsory. In addition, only an efficient integration of safety concerns early in the design process guarantees an optimal design avoiding late and costly changes. Our proposal is an integrated methodology named SafeSysE, including both MBSE and MBSA processes. SafeSysE narrows the gap between the design and safety analyses since it allows to assist the safety expert in generating the safety artifacts such as FMEA and FTA from the system models. It enhances the consistency between the system model including the requirements, structure and behavior of the system in one side and the safety artifacts in the other side.

Full text

An Integrated Design Methodology for Safety
Critical Systems
Fa¨
ıda Mhenni, Jean-Yves Choley
Quartz, SUPMECA Paris
Saint-Ouen, France
Email: faida.mhenni, jean-yves.choley@supmeca.fr
Nga Nguyen
Quartz, EISTI
Cergy Pontoise, France
Email: nga.nguyen@eisti.fr
Abstract—Nowadays man-made systems are getting more
complex including new technologies and components from dif-
ferent domains. In addition, they are used in many safety critical
missions. This induces new challenges in the design of such
systems as new methods and tools are needed to manage the
complexity while taking into account safety aspects. To face these
challenges, the use of model-based approaches such as MBSE is
compulsory. In addition, only an efficient integration of safety
concerns early in the design process guarantees an optimal design
avoiding late and costly changes. Our proposal is an integrated
methodology named SafeSysE, including both MBSE and MBSA
processes. SafeSysE narrows the gap between the design and
safety analyses since it allows to assist the safety expert in
generating the safety artifacts such as FMEA and FTA from the
system models. It enhances the consistency between the system
model including the requirements, structure and behavior of the
system in one side and the safety artifacts in the other side.
I. INTRODUCTION
With the increasing technological advances, nowadays
man-made systems are getting more complex and offering a
variety of new functions to users. They are used for safety
critical missions to assist users or replace them for tasks in
risky and harsh environments. Unfortunately, this implies an
increasing exposure to mishaps as systems can fail or perform
improperly resulting in damage, injury, and deaths. The design
of these systems is thus challenging since it needs to manage
the complexity while taking into account safety concerns.
Indeed, the potential risks of such systems must be thoroughly
identified and guarded against during the development cycle
to bring them to an accepted level. In the current state, safety
analyses usually occur late in the design process when the
solution is defined with enough detail. This results in delays
and extra cost to modify the design accordingly to the safety
analysis results [1]. To cope with this, new approaches and
tools are needed to efficiently integrate safety analyses since
early stages of the design.
In this paper, a process that tackles these challenges is
presented. To manage the first challenge, which is complexity,
a SysML-based Model Based Systems Engineering (MBSE)
approach is suggested for the design. As for the safety aspect,
safety analysis methods such as Failure Mode and Effects
Analysis (FMEA) and Fault Tree Analysis (FTA) are integrated
to the design approach.
The paper is organized as follows. First, an overview of
related work about the integration of safety analysis within a
SysML-based systems engineering approach is given in section
II. Then, the proposed integrated process called SafeSysE is
detailed in section III. Finally the paper is concluded in section
IV. A drone (unmanned aerial vehicle) is used in this paper as
a case study to illustrate the design methodology.
II. RELATED WORK
In this section a review of the related work about the inte-
gration of MBSE and Model Based Safety Analysis (MBSA)
is given. Different literature works tackled different aspects of
the integration.
Some works tackled the integration of safety into the
design process through the requirements. Laleau et al. in
[2] dealt with formalizing the requirements by combining
SysML requirement diagrams and the B formal specification
language through the extension of the SysML requirements
model with concepts of goal-oriented requirements. Also re-
garding requirements, Dubois [3] proposed to directly include
system requirements in the design process. A SysML profile
respecting safety standards called RPM (Requirement Profile
for MeMVaTEX) has been developed. This new profile al-
lowed adding various properties such as verifiable, verification
type, derived from, satisfied by, refined by, traced to, etc. to
enhance the traceability between requirement models, between
requirement and solution models, and between requirement and
Verification and Validation models. These V&V models have
also been exploited in the thesis of Guillerm [4]. All these
works facilitate the verification and validation of requirements
in general and particularly of safety requirements which is of
a predominant importance for safety.
The second approach concerns the automatic generation of
safety artifacts from system models. Most of these approaches
support the integration of safety related information into the
system model. A methodology called M´
eDISIS was developed
by David et al. [5], [6], [7], [8] to enhance the integration
of MBSE and MBSA by automatically extracting data from
the system model to automatically generate (partially filled)
safety artifacts. In this work, preliminary FMEAs are generated
from system functional behaviors and as well as from the
system structure models written in SysML models. Then the
final FMEA report is created with help from experts in the
safety domain. Philipp Helle in [9] also presents an integration
process of MBSA in a SysML-based MBSE. In this work, an
extension of SysML allows to include safety related informa-
tion 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, is also implemented that
978-1-4673-9519-9/16/$31.00 ©2016 IEEE

retrieves the system model to extract relevant information in
order to provide outputs such as the minimal cut-set for each
failure case and system alternative as well as RBD representing
this cut-set. Garro et al. [10] developed RAMSAS, a model-
based method for system reliability analysis that combines
SysML and the Simulink tool allowing the verification of relia-
bility performance of the system through simulation. A formal
verification method was not used in this research for safety
assessment. Another method for supporting the Dependability
Analysis of systems that is based on RAMSAS is also proposed
in [11]. This method called RAMSAS4Modelica starts from a
Modelica-based system design and allows the generation of
fault tree diagrams.
A third approach focused only on the integration of safety
related information into the system model assuming that safety
analyses have already been performed like in [12]. In this work,
a SysML profile for safety called SafeML is developed. This
profile is organized in two parts, one part dealing with hazards,
harm and the context leading to the occurrence of harm while
the second part deals with safety measures intended to prevent
the harm from occurring.
The aim of this paper is to give a more comprehensive
approach dealing with the automatic generation of safety
artifacts as well as the integration of safety related concepts
into the system design through the extension of the system
model.
III. SAFESYSE: THE INTEGRATED PROCESS
This section details the integrated process of systems en-
gineering and safety analysis called SafeSysE. This integrated
process extends a SysML-based systems engineering method-
ology already presented in [13] with safety analysis processes
in order to take into account safety aspects since early design
stages and thus avoid late design changes that are very costly
and time consuming. In our Work a prototyping tool was
also developed to generate automatically safety artifacts by
extracting the relevant information from the XML Metadata
Interchange XMI [14] file generated from the SysML model.
As a first step of this work, SafeSysE integrates the two
most widely used safety analysis techniques, i.e. Failure Mode
and Effects Analysis (FMEA) and Fault Tree Analysis (FTA) in
a MBSE approach. In the next steps other techniques are also
intended to be supported by SafeSysE. This process is made
up of a set of iterative steps. In Figure 1, an activity diagram
describes SafeSysE with the sequencing of the different sub-
processes as well as the exchanges between them. Data stores
are used to model the storage of the different artifacts issued
from each activity. 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 require-
ments describing the need and potentially some constraints.
Then, the different steps including design activities and safety
analyses are performed successively in a well defined sequence
as shown in Figure 1. At each design process are associated
relevant safety analyses. By integrating safety analysis early
in the design process, we avoid late design changes that are
usually very expensive and very long to perform.
Fig. 1. SafeSysE Integrated Process
A. Step 1: Requirements Definition and Analysis
The Requirements Definition and Analysis is the initial step
of the design methodology. It deals with the capture of the
different requirements such as system functionality, external
interfaces and other constraints. Several SysML diagrams are
used in this step to model different views of the system that
contribute to collect and elicit requirements. As an example,
block definition diagrams can be used to model the system
context and the interactions of the system with its environment
actors, use case diagrams and associated sequence diagrams
can be used to model the system usage in terms of services
and scenarios. An extract of the requirements diagram obtained
at the end of the Step 1 is given in Figure 2.
Fig. 2. Extracts of the Requirement Diagram
B. Step 2: Functional Structure Definition
Based on the functional requirements identified in Step 1,
one or more functional structures are identified. By functional
structure we mean a functional breakdown that describes the
progressive transformations of input flows into output flows.
The breakdown can be done at several abstraction levels. The
final result is a hierarchical model of the breakdown of the
system main function(s) into sub-functions, at several abstrac-
tion levels. In SysML, activity diagrams have been extended to
support the EFFBD (Enhanced Function Flow Block Diagram)
concept that is very used to model the functional breakdown.

In our work, SysML activities are selected to represent the
functions and the functional breakdown is modeled through
a set of activity diagrams, each activity diagram representing
the breakdown of a given function (activity) into sub-functions.
Activity diagrams also show the progressive transformation of
input flows into output flows.
The breakdown of the Drone functions at the first level is
given in Figure 3. At this level, we have six sub-functions:
’Communicate with G-S’ where G-S stands for the ground
station, ’Film’, ’Control’, ’Fly’, ’Manage Energy’ and ’Com-
municate with Pilot’. By ’Communicate with the Pilot’ we
mean to include some visual information to inform the pilot
if there is any problem for the drone. The other five first-
level functions need to be more detailed to better describe
the system functioning and be able to allocate the appropriate
components later on. Each of these sub-functions is detailed
in an activity diagram detailing its sub-functions (only one of
these diagrams is presented here to keep within the requested
number of pages). The activity diagram detailing the ’Manage
Energy’ is given in Figure 4. The final functional hierarchy is
presented in Figure 5.
Fig. 3. First Level Functional Breakdown
Fig. 4. Manage Energy Activity Diagram
C. Step 3: Functional Risk Assessment
In this step, a risk assessment at the functional level is
performed. For this purpose, a functional FMEA is conducted
Fig. 5. Functional Specification of the Drone
to identify potential hazards caused by the potential failures
of the functions as well as their effects at the system level.
An FMEA data-sheet is automatically generated and contains
the list of all the functions in the system model as well as
a generic list of failure modes for each function (the same
generic failure modes are considered for all functions). This
automatic generation of the exhaustive list of functions helps in
reducing the time needed as well as the error proneness if this
work had to be done manually. The safety expert then performs
the analysis and completes the FMEA with the relevant data
based on the preliminary FMEA automatically generated and
on a good understanding of the system functioning. All the
safety information added by the safety expert (i.e. the failure
modes of each function, the effects of each failure mode etc.)
are then updated into the SysML model via the safety profile
extension explained in [15] and the developed tool. The system
model is thus extended to include the safety analyses results.
This helps in enhancing the communication between safety
experts and system designers. At the end of this step, safety
requirements are derived and added to the set of requirements
in the system model. 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 the risks
identified by the safety analysis and the modifications in the
system model can be traced into the corresponding safety
analysis results/requirements. Risk effects mitigation can be
obtained by eliminating or modifying high risk functions,
adding new fault tolerance mechanisms like diagnosis and
reconfiguration functions, etc. Each time that the functional
structure is modified, the FMEA shall be updated to take into
account the new changes. The potential new risks that could
be induced with these changes must be assessed. The previous
steps iterate until a satisfactory solution is identified and the
final results of the safety analysis are stored in the extended
system model.
An extract of the functional FMEA of the drone for the
’Store Energy’ function is given in Table I. The preliminary
FMEA that is automatically generated already contains some
information including the list of functions, and for each func-
tion, a list of generic failure modes, input and output flows in
the causal factors column to help the expert identify the causes
as well as the immediate upstream and downstream function

to help the expert in identifying the immediate effect of each
failure mode. The automatically generated information is in
italic red color font in Table I. The functional modeling of the
system is then modified to integrate the recommended actions
mentioned in the FMEA. The updated activity diagram for the
’Manage Energy’ function is given in Figure 6.
:
Fig. 6. Updated Activity Diagram for ’Manage Energy’
D. Step 4: Component Structure Definition
Once the functional structure is defined taking into account
the results of the safety analysis in Step 3, one or more
component structures are defined by allocating components to
functions. By a component structure we mean an organized
view of the system in terms of its constituent components
where the latter are represented by generic classes (motor,
sensor, etc.). A Block Definition Diagram (BDD) describes
the components of the system and an Internal Block Diagram
(IBD) describes the interactions between the components. The
component structure defined at this step already takes into
account safety aspects since it integrates the results of the
functional safety assessment performed in step 3.
For the drone, the functions identified in Step 2 are
allocated to a set of components as shown in Figure 7. The
interactions among the components are modeled in an IBD in
Figure 8. The connections between the output flow port on the
’Energy Unit’ part and the input flow port on each of the other
parts except the ’Chassis’, typed ’Electric Energy’, are hided
on the figure to improve its readability.
E. Step 5: Component-level Risk Assessment
When the structure of the system is defined, the safety
analysis results are updated and a component level risk as-
sessment is performed. For this purpose, a component FMEA
is generated from the XMI file like in step 3 for the functional
FMEA. 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 with unacceptable level,
then these risks shall be eliminated or reduced to an acceptable
Fig. 7. Drone Components Allocated to Functions
Fig. 8. Drone Internal Structure
level by performing changes to the design. Once again, these
safety data are saved back in the same SysML model using
the safety profile developed in this work. If design changes are
performed (by going back to previous steps), a new FMEA is
generated to assess the new structure. In this case, the previous
results are also automatically generated as they are stored in
the model and the safety expert updates the FMEA without
loosing his previous work. An extract of the component FMEA
of the Drone is given in Table II.
F. Step 6: Fault Propagation and Reliability Assessment
The final step is the fault propagation and reliability
assessment. Fault trees are used in this step for both qualitative
and quantitative analyses. In our approach, fault trees are auto-
matically generated from SysML IBDs describing the system
structure. 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 fault tree analysis tools. For

TABLE I. EXTRACT OF THE FUNCTIONAL FMEA OF THE DRONE
more details about fault tree generation please refer to [16].
The fault tree for the undesired event ’Propulsion Default’ is
given in Figure 9.
IV. CONCLUSION
SafeSysE is an integrated process that aims at encompass-
ing MBSE and MBSA design and analysis processes in order
to take into account safety aspects as soon as possible in the
design process of safety critical systems. Using a drone as a
scenario, we have shown in this paper how to use SysML
system model of the requirements and the functional and
component structures in order to perform functional and com-
ponent level risk assessment, along with fault propagation and
reliability assessment. It provides the safety expert with means
to generate functional and components FMEAs consistent with
the system modeling, thus allowing the definition of new
relevant safety requirements to be taken into account in fewer
design iterations. Once a component structure is defined, it also
allows generating a generic fault tree for fault propagation and
reliability assessment. SafeSysE has been partially prototyped
in order to be tested on academic simplified scenarios. Scaling
up has also been performed with an industrial aerospace use
case. Taking into account these experiments, a fully oper-
ational demonstrator supported with relevant comprehensive
methodological documentation has to be developed. Research
activities are ongoing to extend SafeSysE to make it support
FDIR (Fault Detection Isolation and Recovery) mechanisms.
For testing purposes, a test cell under development will in-
tegrate electro-mechanical actuators and ailerons with faults
generations and redundancies management.
REFERENCES
[1] A. Berres, S. H., and S. H., “Concurrent safety analysis : A method for
information exchange between systems and safety engineers.” in Safety
and Reliability of Complex Engineerd Systems, 2015.
[2] R. Laleau, F. Semmak, A. Matoussi, D. Petit, A. Hammad, and
B. Tatibouet, “A first attempt to combine SysML requirements diagrams
and B,” Innovations in Systems and Software Engineering, vol. 6, pp.
47–54, 2010.
[3] H. Dubois, “Gestion des exigences de sˆ
uret´
e de fonctionnement dans
une approche IDM,” in Journ´
ees Neptune N 5, Paris, France, 08 avril
2008.
[4] R. Guillerm, “Int´
egration de la sˆ
uret´
e de fonctionnement dans les
processus de l ing´
enierie syst`
eme,” Ph.D. dissertation, Universit´
ede
Toulouse, 2011.
[5] P. David, “Contribution `
a l’analyse de sˆ
uret´
e de fonctionnement des
syst`
emes complexes en phase de conception: application `
al’
´
evaluation
des missions d’un r´
eseau de capteurs de pr´
esence humaine,” Ph.D.
dissertation, Universit´
e d’Orl´
eans, Novembre 2009.
[6] R. Cressent, V. Idasiak, and F. Kratz, “Prise en compte des analyses
de la sˆ
uret´
e de fonctionnement dans l’ing´
enierie de syst`
eme dirig´
ee par
les mod`
eles SysML,” G´
enie Logiciel, pp. 33–39, 2011.
[7] R. Cressent, P. David, V. Idasiak, and F. Kratz, “Designing the database
for a reliability aware model-based system engineering process,” Reli-
ability Engineering & System Safety, vol. 111, pp. 171 – 182, 2013.
[8] A. Kaijdan and V. Idasiak, “Model-based systems engineering and
failure analysis: Experience feedback,” in Safety and Reliability of
Complex Engineered Systems, P. et al., Ed., 2015.
[9] P. Helle, “Automatic SysML-based safety analysis,” in Proceedings
of the 5th International Workshop on Model Based Architecting and
Construction of Embedded Systems, 2012.
[10] A. Garro and A. Tundis, “Enhancing the RAMSAS method for system
reliability analysis - an exploitation in the automotive domain,” in
SIMULTECH, 2012, pp. 328–333.
[11] ——, “RAMSAS4Modelica: a simulation-driven method for system
dependability analysis centered on the modelica language and related
tools,” in DEVS ’14 Proceedings of the Symposium on Theory of
Modeling & Simulation - DEVS Integrative, 2014.
[12] G. Biggs, T. Sakamoto, and T. Kotoku, “A profile and tool for modelling
safety information with design information in sysml,” Software &
Systems Modeling, vol. 15, no. 1, pp. 147–178, 2014.
[13] F. Mhenni, J.-Y. Choley, O. Penas, R. Plateaux, and M. Hammadi,
“A SysML-based methodology for mechatronic systems architectural
design,” Advanced Engineering Informatics, vol. 28, no. 3, pp. 218 –
231, 2014.
[14] Object-Management-Group, XML Metadata Interchange (XMI) Specifi-
cation, Object Management Group Std.
[15] F. Mhenni, J.-Y. Choley, and N. Nguyen, “SysML safety profile for
mechatronics,” in Mecatronics, Tokyo, japan, November 2014.
[16] F. Mhenni, N. Nguyen, and J.-Y. Choley, “Automatic fault tree gen-
eration from SysML system models,” in IEEE/ASME International
Conference on Advanced Intelligent Mechatronics, AIM, 2014.

TABLE II. EXTRACT OF THE COMPONENT FMEA OF THE DRONE
Fig. 9. Fault Tree for ’Propulsion Default’ Undesired Event