See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261334636

Modeling and simulation for system reliability analysis: The RAMSAS method

Conference Paper · July 2012

DOI: 10.1109/SYSoSE.2012.6384175

CITATIONS READS
11 494

2 authors:

Alfredo Garro Andrea Tundis

Università della Calabria Technische Universität Darmstadt
113 PUBLICATIONS   1,188 CITATIONS    51 PUBLICATIONS   265 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Space Reference FOM View project

PolyEnergyNet (PEN) View project

All content following this page was uploaded by Andrea Tundis on 04 March 2016.

The user has requested enhancement of the downloaded file.

Modeling and Simulation for System Reliability Analysis:
The RAMSAS Method
Alfredo Garro
Department of Electronics, Computer and System
Sciences (DEIS)
University of Calabria
Via P. Bucci 41C, 87036, Rende (CS), Italy
garro@deis.unical.it
Abstract - The paper presents the up-to-date version of
RAMSAS, a recently proposed model-based method for the
reliability analysis of systems through simulation. RAMSAS
can be easy plugged in various phases of a typical system
development process ranging from the design to the testing
phases so to complement other well-known and wide
adopted techniques for system reliability analysis (e. g.
FMECA, FTA, RBD) by providing additional analysis
capabilities. The present version of RAMSAS is the result
of an intensive experimentation phase in several
application domains (avionics, automotive, satellite) which
allowed improving the effectiveness of the method
especially in the modeling of both the intended and
dysfunctional system behavior. The paper concludes with a
discussion about the specific aspects of the reliability
analysis of System of Systems (SoS), and how RAMSAS can
be further extended to effectively support it.
Keywords: System Reliability Analysis, Model-Based
Systems Engineering, Simulation, Failure Modeling.
1 Introduction
Large-scale systems are usually designed and
implemented as a set of interconnected parts forming an
integrated whole in order to obtain the desired functions
with acceptable performance and costs. The increase in
both the heterogeneity and numbers of system components
raises several and challenging engineering issues and
demands for suitable analysis, design, verification and
validation methods and techniques to guarantee system
integration and requirements satisfiability in a flexible way.
In particular, non-functional requirements play an important
role as they are decisive in the achievement of system
objectives. More specifically, Reliability which represents
the ability of a system to perform its required functions
under stated conditions, for a specified period of time, is a
key requirement to satisfy especially for mission critical
systems where system failures could cause even human
losses [2]. To perform system reliability analysis several
quantitative and qualitative techniques are currently
available (such as Series-Parallel system reliability analysis,
Markov Chains, FMECA and FTA) [2]. Nevertheless, the
Andrea Tundis
Department of Electronics, Computer and System
Sciences (DEIS)
University of Calabria
Via P. Bucci 41C, 87036, Rende (CS), Italy
atundis@deis.unical.it
increase in both system complexity and accuracy required
in the reliability analysis often goes beyond the capabilities
of the so far mentioned techniques which are mainly based
on statistical and probabilistic tools and on the hierarchical
system decomposition. As a consequence, new techniques
are emerging which are centered on model-based
approaches so to benefit from the available modeling
practices and which incorporate the use of simulation to
flexibly evaluate the system reliability indices and compare
different design choices [1, 7]. In this context, RAMSAS, a
model-based method for the reliability analysis of systems
through simulation has been recently proposed [5].
RAMSAS has been already experimented in the avionics
[4, 5] and automotive domain [3]; moreover, an ongoing
experimentation concerns the reliability analysis of an
Attitude Determination and Control System (ADCS) of a
Satellite. These experiences allowed improving RAMSAS
so to increase its effectiveness in system reliability analysis.
In particular, in the present version of RAMSAS, which is
for the first time presented in details in this paper, new
approaches for modeling both the intended and
dysfunctional behavior of the system are proposed. In
particular, the modeling of the dysfunctional system
behavior is based on the introduction of specific behavioral
templates of dysfunctional tasks and related fault/failure
patterns. A discussion about the specific aspects of the
reliability analysis of System of Systems (SoS), and how
RAMSAS can be further extended so to effectively support
it, is also provided and concludes the paper.
2 The RAMSAS method
The RAMSAS method, which enables the reliability
analysis of systems through simulation, is based on a
classical iterative process consisting of four main phases
which are reported in Table 1 along with their input and
output work-products. In the first phase (Reliability
Requirements Analysis), the objectives of the reliability
analysis are specified and the reliability functions and
indicators to evaluate during the simulation are defined. In
the System Modeling phase, the structure and behavior of
the system are modeled in SysML (OMG Systems
Modeling Language) by using zooming in-out mechanisms
[9]; moreover, beside the intended system behaviors,
specific dysfunctional behaviors and related tasks, which
model the onset, propagation and management of faults and
failures, are introduced. In the System Simulation phase, the
previously obtained models of the system are represented in
terms of the constructs offered by the target simulation
platform. Finally, simulation results are analyzed with
respect to the objectives of the reliability analysis; if
necessary, new partial or complete process iterations are
executed.
In the following sub-sections each of the above
sketched phases will be described by focusing on the
enhancement introduced in the present version of RAMSAS
respect to the previous ones. Complete examples of the
execution of the RAMSAS phases and related work-
products can be found in [3, 4, 5].
Table 1. RAMSAS phases and related work-products
Phases Input work-products Output work-
products
of time. In addition, a Failure modes and effects analysis
(FMEA) [2] can be also provided to highlight the potential
failure modes of the system along with their severity and
likelihood. Starting from the above mentioned SR, in the
Reliability Analysis Objectives (RAO) work-product, the
reliability indicators and the scenarios of interests are
identified along with the main analysis techniques to be
applied to the data gathered from simulation. In the RAO, a
visual representation of the SR can be also provided
through SysML Requirements Diagrams along with the
allocation of these requirements (especially the reliability
ones) to main system components.
2.2 System Modeling
In the System Modeling phase the structure and both
the intended and dysfunctional behavior of the system
under consideration are represented in SysML by executing
four modeling activities (see Figure 1): System Structure
Modeling, Intended Behavior Modeling, Dysfunctional
Behavior Modeling and Behavior Integration.

Reliability System Design Model Reliability Analysis

Requirement (SDM), System Objectives (RAO)
Analysis Requirements (SR)
System System Design Model System Model for
Modeling (SDM), Reliability Analysis Reliability Analysis
Objectives (RAO) (SMRA)
System System Model for Reliability Simulation Results
Simulation Analysis (SMRA), (SIRE)
Reliability Analysis
Objectives (RAO) Figure 1. Activities of the System Modeling phase
Results Simulation Results (SIRE), Design Suggestions The specifications concerning the structure and
Assessment Reliability Analysis Report (DSR),
intended behavior of the system are derived from the
Objectives (RAO) Reliability Analysis
Report (RAR) System Design Model (SDM) resulting from previous
design phases; these activities can be straightforward if
during the system design similar structural and behavioral
2.1 Reliability Requirements Analysis reference models have been adopted along with a UML
In the Reliability Requirements Analysis phase the based modeling notation. With reference to the
objectives of the system reliability analysis are specified. dysfunctional behavior of the system, its modeling can be
The inputs of this phase are the work-products typically based on the results reported in the RAO document
resulting from previous System Design phases. Starting concerning the analysis of the failure modes of the system
from this documentation, the scenarios to be analyzed, the (see Section 2.1). Finally, the intended and dysfunctional
functions that the system has to perform, the related system behaviors are suitable integrated so to provide a
operative conditions, and the reference time horizons complete system specification for the subsequent simulation
should be clearly individuated along with the reliability phase. In the following Sub-Sections, each of these
functions and indicators to be derived from the analysis of modeling activities is discussed more in details.
the simulation results. In particular, the Reliability
Requirements Analysis phase takes as input a description of
the system under consideration in term of both System 2.2.1 System Structure Modeling
Requirements (SR) and System Design Model (SDM). SR In the System Structure Modeling activity, the system
includes functional (FR) and non-functional requirements structure is modeled by using SysML Blocks following a
(NFR), whereas SDM provides a system representation in top-down approach. To this aim, several decomposition
terms of its architecture and behavior. Among the NFR, the levels should be considered by applying in-out zooming
Reliability Requirements (RR) specify the ability required mechanisms [9] such as system, subsystems, equipment, and
for the system in performing the functions identified by the components; however to allow system analysis at the
FR under specific stated conditions and for a given period desired level of details, further abstraction levels along with
different and deeper hierarchies can be also introduced.
Each system entity is defined by both a Block Definition
Diagram (BDD) and an Internal Block Diagram (IBD).
Specifically, for a given abstraction level, a BDD describes
a block with its interfaces, attributes, operations,
constraints, parts and relationships with other blocks;
whereas, an IBD provides a description of the block
internal structure in terms of the organization of its
component blocks.
2.2.2 Intended Behavior Modeling
In the Intended Behavior Modeling activity the
intended (or normal or expected) behavior of the system is
represented following also a layered approach but
combining the top-down with a bottom-up strategy. The
reference model is service and task-oriented: the behavior
of each entity is modeled in terms of the services (or
functions) that the entity is able to provide and which are
performed through tasks. In order to specify the behavior of
the system and its component entities, two levels of
decomposition are considered: leaf level (e.g. component
level) and non-leaf level (e.g. equipment, subsystem or
system level).
In particular, for each entity at the leaf decomposition
level (the lowest decomposition level):
• the services (or functions) provided by the entity,
in terms of their input and output work-products
along with pre and post conditions, should be
specified;
• each task (flow of activities/actions) performed
by the entity for providing a specific service (or
function) has to be specified through an Activity
Diagram; each task can be scheduled or
triggered by incoming events/messages;
• the exchange of messages between the entity and
the external environment (which can be another
entity at the same or at a higher decomposition
level) should be represented through Sequence
Diagrams;
• in case the behavior of the entity depends on its
internal state, a state machine which models the
entity life cycle can be specified through a
Statechart Diagram.
Moving from the leaf decomposition level to higher
decomposition levels (not-leaf decomposition levels), the
representation of the entity behavior is similar; however,
how the component entities (i.e. sub-entities) participate
and determine the behavior of the considered enclosing
entity should be taken into account; as a consequence, for
each entity at a not-leaf decomposition level:
• beside the services (or function) provided by the
entity, how these services can be obtained by
composing the services provided by the sub-
entities should be also specified;
• each task (flow of activities/actions) performed
by the entity for providing a specific service (or
function) has to be specified by an Activity
Diagram possibly highlighting through swimlanes
the responsibility of each sub-entity in carrying
out the activities of the task;
• the exchange of messages between the entity and
the external environment should be represented
through Sequence Diagrams possibly highlighting
the role played by its sub-entities in each
interaction (e.g. by explicitly representing them
as participants in the diagrams);
• in case the behavior of the entity depends on its
internal state, a state machine which models the
entity life cycle can be specified through a
Statechart Diagram; the diagram can adopt
advanced constructs, such as composite states,
AND/OR-decomposition and history pseudo-
states, for representing how the behavior of the
entity is related to the behavior of its sub-entities.
2.2.3 Dysfunctional Behavior Modeling
In the Dysfunctional Behavior Modeling activity, the
focus is on the modeling of faults and failures, which are
key concepts of the system reliability analysis [2].
Specifically, the behavior, concerning faults and failures of
each system entity (i.e. the dysfunctional behavior), is
specified as a set of specific tasks (which can be modeled
through Activity Diagrams). The reference model of a
generic system entity, regardless on the considered
abstraction level, is shown in Figure 2. An entity is
represented by a SysML Block which provides a set of
services/functions; the tasks performed by the entity for
providing these services are modeled during the Intended
Behavior Modeling phase (see Section 2.2.2). Beside the
intended behavior specified through these tasks, a set of
dysfunctional tasks are added so to model the dysfunctional
behavior of the entity [1, 6]. In particular, each block could
receive as input a set of failure events (e.g. due to the
failures of other blocks) and could, in turn, produce in
output other failure events due to its failure; moreover,
internal faults (represented as fault events) can be generated
and treated inside the block possibly producing block
failures (and thus output failure events). With reference to
the above described behavioral reference model (see Figure
2), six templates of dysfunctional tasks have been
individuated (see Figure 3): Fault Generation, Failure
Generation, Failure Management, Fault Management
Failure Propagation, and Failure Transformation.
Figure 2. The reference Behavioral Model of a system entity
(a) Fault Generation
Tasks of the Fault and Failure Generation type (see
Figure 3.a and 3.b respectively) can generate a fault/failure
as a result of specific causes occurring according to a given
probability function. In order to allow driving, during the
simulation, the processes of fault/failure generation so as to
study the reliability performances of the system, these tasks
can be scheduled or triggered by specific events. However,
whereas a failure is directly associated to an output failure
event (see Figure 3.b), to produce a failure event starting
from a fault, the fault has to be taken in input from either a
Failure Propagation or a Failure Transformation task.
Incoming failures as well as internally generated faults can
be (successfully or not) handled by tasks of the Failure and
Fault Management type (see Figure 3.c and 3.d
respectively). Finally, tasks of the Failure Propagation and
the Failure Transformation type take dysfunctional events
in input and produce dysfunctional events in output. In
particular, tasks of the Failure Propagation type (Figure
3.e) generate output failure events either through the
propagation of incoming failure events or by combining
such incoming failures with internal faults. Tasks of Failure
Transformation type (Figure 3.f) produce output failure
events derived from the transformation or combination
either of incoming failure events or of internal faults.

To further support this crucial modeling activity, a set

of patterns to associate to each of the above discussed six
types of dysfunctional tasks should be defined. The
(b) Failure Generation definition of each of these patterns should take into account
the type of the dysfunctional task (e.g. Failure Generation,
Propagation or Transformation) as well as the specific
nature of the fault/failure to which the pattern refers to; in
other word, a basic pattern is associated to a couple
(c) Failure Management (dysfunctional task type; fault/failure type). As a
consequence, for the definition of these patterns, beside the
individuated six dysfunctional task types (see Figure 3), a
(possibly hierarchical) classification of faults/failures needs
to be introduced. A first solution could consider the
following fault/failure types [6]: (i) reaction too late; (ii)
(d) Fault Management reaction too early; (iii) value failure; (iv) commission; and
(v) omission. By combining the individuated six
dysfunctional task types with these five fault/failure types,
thirty different basic fault/failure behavioral patterns can be
defined (their complete description, which is the result of
an ongoing research activity, is beyond the scope of this
paper).
(e) Failure Propagation
The modeling of the dysfunctional behavior of each
system entity, in terms of a set of dysfunctional tasks of the
above described types and possibly based on available
fault/failure behavioral patterns, is essential to evaluate
through simulation the dysfunctional behaviors of the
system and analyze the possible consequences of failures as
(f) Failure Transformation well as feasible solutions for their management in order to
improve system reliability.
Figure 3. Templates of dysfunctional tasks
2.2.4 Behavior Integration
In the Behavior Integration activity, the normal/intend
behaviors and the dysfunctional behaviors modeled in the
previous modeling activities (see Section 2.2.2 and 2.2.3)
are integrated to obtain an overall behavioral model of the
system and its component entities. As an example, starting
from the Activity and Sequence diagrams which have been
used to model both the intended and dysfunctional
behaviors of the system entities, a complete and integrated
definition of the life cycle of each entity, regardless on the
considered abstraction level, can be obtained and
represented through a Statechart diagram. This activity
closes the System Modeling phase by delivering the System
Model for Reliability Analysis (SMRA) work-product.
2.3 System Simulation
The objective of the System Simulation phase is to
evaluate through simulation the reliability performance of
the system and, possibly, compare different design
alternatives and parameters settings; in particular, the
following three (see Figure 4) main activities are
performed: Model Transformation, Parameters Setting, and
Simulation Execution.
Figure 4. Activities of the System Simulation phase
In the Model Transformation activity the previously
obtained Models of the System in the SMRA are
represented in terms of the constructs offered by the target
simulation platform which is, currently, MathWorks
Simulink, so producing an Executable System Model
(ESM). This transformation is based on a mapping between
the basic SysML and Simulink constructs (see Table 2) [3,
4, 10]. It is worth noting that not only the intended behavior
of the system but also the dysfunctional tasks (see Section
2.2.3) which are essential for analyzing during the
simulation the reliability performance of the system are
generated. Indeed, this allows to suitably injecting faults
and failures during the simulation and setting the
parameters of the related generation, management,
propagation and transformation tasks (see Section 2.2.3).
In the Parameters Setting activity the ESM is refined
so to allow the flexible setting of system configuration and
simulation parameters which can be tuned according to
both the characteristics of the operative scenario to simulate
and the dysfunctional behaviors to analyze.
In the Simulation Execution activity the ESM is
executed by varying the desired parameters according to the
analysis objectives reported in the RAO. Specifically, the
ESM is executed by Simulink according to a synchronous
reactive model of computation: at each step, Simulink
computes, for each block, the set of outputs as a function of
the current inputs and the block state, then it updates the
block state. During the simulation faults and failures can be
injected and/or caused to stress and analyze the reliability
performance of the system. At the end, the data generated
from the simulations are reported in the Simulation Results
(SIRE) work-product to be analyzed in the next phase.
Table 2. Mapping among SysML and Simulink constructs
Entity SysML Simulink
System/Subsystem/ Block, Part Block, Subsystem
Equipment/Component Block
Behavior/Constraint Activity Diagram, S-Function, State
Sequence Diagram, Flow diagram
Statechart Diagram,
Parametric Diagram
Input/Output Interface Flow Port Input/Output
Simulink Block
Association/Binding Connection Line
2.4 Results Assessment
In the Results Assessment phase, the results reported
in the SIRE are elaborated with reference to the objectives
of the reliability analysis identified in the initial phase of
the process so to obtain important information on the
reliability properties of the system under consideration. A
great part of these analyses can be directly performed in
Simulink, whereas more advanced analyses can be
performed by external tools by exporting the obtained
results through the MATLAB Workspace. As a result, the
following two work-products are produced in output:
• Reliability Analysis Report (RAR), which
provides a detailed analysis about the reliability
performance of the system under consideration;
• Design Suggestions Report (DSR), which
provides a set of suggestion to improve the
design of the system and/or choose among
different design choices. It is worth to note that
the DSR exploits typical FMECA and FTA
notations and representation formats so to ease
the use of RAMSAS in conjunction with classical
RAMS techniques.
As for any iterative process, new (partial or complete)
iterations of RAMSAS can be executed for achieving new
or missed analysis objectives.
 3 Discussion and Conclusions
The current version of RAMSAS, described in Section
2, has been originally conceived for large-scale systems, i.e.
systems which are constituted by a multitude of components
organized so to form a whole with clearly defined
boundaries. Examples of this kind of systems are military
and commercial aircraft, spacecraft, satellites, power plant
automobiles, etc. The reliability analysis of these systems is
a challenging task which, as proved by RAMSAS, could
benefit both from model-based approaches and from
simulation [3, 4, 5]. However, although the structure of
these large-scale systems is rather complex (or better
complicated) it remains quite the same during the system
life cycle; moreover, a great part of the system components
manifest a reactive behavior and pro-activeness is limited to
a narrow subset of components. Moving from large-scale
system to the System of Systems (SoS) context, these
assumptions typically do not hold [8]. Indeed, a SoS (e.g. a
Coast Guard Integrated Deep-water System or an Air
Traffic Management System) is constituted by a set of
interconnected, and often geographically distributed,
systems which interact for achieving common goals and are
capable of autonomous and independent behaviors;
moreover, the set of involved systems typically changes
during the SoS life as new systems join the SoS and other
dynamically leave it. As a consequence, the reliability
analysis of a SoS presents different and peculiar aspects
respect to that of a large-scale system that need to be
accurately taken into account and that require for specific
approaches and techniques. Some features of RAMSAS are
particularly suited for the reliability analysis of SoS such as
the adoption of zooming in-out mechanisms for the
structural and behavioral modeling of the system, and the
exploitation of simulation both for the analysis of system
properties and for the evaluation of alternative scenarios
and design choices. However, new features need to be
added; as an example, the possibility to define the potential
changes in the system structure during the system life cycle.
Moreover, specific concepts to explicitly model the pro-
active (and thus autonomous) part of the behavior of the
SoS entities (which are themselves systems) should be
introduced (such as the goals that the entity will to achieve).
These novelties could lead to evolve the current vision of
system adopted in RAMSAS to a more agent-oriented one
in which a SoS is treated, and thus modeled and simulated
as a Multi-Agent System [9]. Ongoing and future research
activities are devoted to investigate how to further extend
RAMSAS in the above mentioned directions so as to
effectively support the reliability analysis of SoS.
Acknowledgments
Andrea Tundis was supported by a grant funded in the
framework of the “POR Calabria FSE 2007/2013”.
View publication stats
References
[1] R. Cressent, V. Idasiak, F. Kratz, and P. David,
“Mastering safety and reliability in a model based process,”
Proc. of the Reliability and Maintainability Symposium
(RAMS), Lake Buena Vista, FL (USA), January 2011.
[2] B. Dodson and D. Nolan, Practical Reliability
Engineering, John Wiley & Sons Ltd, England, 2001.
[3] A. Garro and A. Tundis, “Enhancing the RAMSAS
method for System Reliability Analysis: an exploitation in
the automotive domain,” Proc. of the 2nd Int. Conf. on
Simulation and Modeling Methodologies, Technologies and
Applications (SIMULTECH), Rome (Italy), July 2012.
[4] A. Garro and A. Tundis, “A Model-Based method for
System Reliability Analysis,” Proc. of the Symposium On
Theory of Modeling and Simulation (TMS), Orlando, FL
(USA), March 2012.
[5] A. Garro, A. Tundis, and N. Chirillo, “System
reliability analysis: a Model-Based approach and a case
study in the avionics industry,” Proc. of the 3rd Air and
Space International Conference (CEAS), Venice (Italy),
October 2011.
[6] L. Grunske and B. Kaiser, “Automatic Generation of
Analyzable Failure Propagation Models from Component-
Level Failure Annotations,” Proc. of the 5th Int. Conf. on
Quality Software (QSIC), Melbourne (Australia),
September 2005.
[7] IEC 61508, Functional safety of
electrical/electronic/programmable electronic safety-
related systems, Parts 1-7, 2010.
[8] M. W. Maier, “Architecting Principles for Systems of
Systems,” Systems Engineering, Vol 1, No. 4, pp. 267-284,
1999.
[9] A. Molesini, A. Omicini, A. Ricci, and E. Denti,
“Zooming multi-agent systems,” Proc. of the 6th Int.
Workshop on Agent-Oriented Software Engineering,
Utrecht (The Netherlands), July 2005.
[10] A. Sindico, M. Di Natale, and G. Panci, “Integrating
SysML with Simulink using Open-Source model
transformations,” Proc. of the 1st Int. Conf. on Simulation
and Modeling Methodologies, Technologies and
Applications (SIMULTECH), Noordwikerhout (The
Netherlands), July 2011.