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 Andrea Tundis
Department of Electronics, Computer and System Department of Electronics, Computer and System
Sciences (DEIS) Sciences (DEIS)
University of Calabria University of Calabria
Via P. Bucci 41C, 87036, Rende (CS), Italy Via P. Bucci 41C, 87036, Rende (CS), Italy
garro@deis.unical.it atundis@deis.unical.it

increase in both system complexity and accuracy required

Abstract - The paper presents the up-to-date version of
in the reliability analysis often goes beyond the capabilities
RAMSAS, a recently proposed model-based method for the
of the so far mentioned techniques which are mainly based
reliability analysis of systems through simulation. RAMSAS
on statistical and probabilistic tools and on the hierarchical
can be easy plugged in various phases of a typical system
system decomposition. As a consequence, new techniques
development process ranging from the design to the testing
are emerging which are centered on model-based
phases so to complement other well-known and wide
approaches so to benefit from the available modeling
adopted techniques for system reliability analysis (e. g.
practices and which incorporate the use of simulation to
FMECA, FTA, RBD) by providing additional analysis
flexibly evaluate the system reliability indices and compare
capabilities. The present version of RAMSAS is the result
different design choices [1, 7]. In this context, RAMSAS, a
of an intensive experimentation phase in several
model-based method for the reliability analysis of systems
application domains (avionics, automotive, satellite) which
through simulation has been recently proposed [5].
allowed improving the effectiveness of the method
RAMSAS has been already experimented in the avionics
especially in the modeling of both the intended and
[4, 5] and automotive domain [3]; moreover, an ongoing
dysfunctional system behavior. The paper concludes with a
experimentation concerns the reliability analysis of an
discussion about the specific aspects of the reliability
Attitude Determination and Control System (ADCS) of a
analysis of System of Systems (SoS), and how RAMSAS can
Satellite. These experiences allowed improving RAMSAS
be further extended to effectively support it.
so to increase its effectiveness in system reliability analysis.
In particular, in the present version of RAMSAS, which is
Keywords: System Reliability Analysis, Model-Based
for the first time presented in details in this paper, new
Systems Engineering, Simulation, Failure Modeling.
approaches for modeling both the intended and
1 Introduction dysfunctional behavior of the system are proposed. In
particular, the modeling of the dysfunctional system
Large-scale systems are usually designed and behavior is based on the introduction of specific behavioral
implemented as a set of interconnected parts forming an templates of dysfunctional tasks and related fault/failure
integrated whole in order to obtain the desired functions patterns. A discussion about the specific aspects of the
with acceptable performance and costs. The increase in reliability analysis of System of Systems (SoS), and how
both the heterogeneity and numbers of system components RAMSAS can be further extended so to effectively support
raises several and challenging engineering issues and it, is also provided and concludes the paper.
demands for suitable analysis, design, verification and
validation methods and techniques to guarantee system 2 The RAMSAS method
integration and requirements satisfiability in a flexible way.
In particular, non-functional requirements play an important The RAMSAS method, which enables the reliability
role as they are decisive in the achievement of system analysis of systems through simulation, is based on a
objectives. More specifically, Reliability which represents classical iterative process consisting of four main phases
the ability of a system to perform its required functions which are reported in Table 1 along with their input and
under stated conditions, for a specified period of time, is a output work-products. In the first phase (Reliability
key requirement to satisfy especially for mission critical Requirements Analysis), the objectives of the reliability
systems where system failures could cause even human analysis are specified and the reliability functions and
losses [2]. To perform system reliability analysis several indicators to evaluate during the simulation are defined. In
quantitative and qualitative techniques are currently the System Modeling phase, the structure and behavior of
available (such as Series-Parallel system reliability analysis, the system are modeled in SysML (OMG Systems
Markov Chains, FMECA and FTA) [2]. Nevertheless, the Modeling Language) by using zooming in-out mechanisms
[9]; moreover, beside the intended system behaviors, of time. In addition, a Failure modes and effects analysis
specific dysfunctional behaviors and related tasks, which (FMEA) [2] can be also provided to highlight the potential
model the onset, propagation and management of faults and failure modes of the system along with their severity and
failures, are introduced. In the System Simulation phase, the likelihood. Starting from the above mentioned SR, in the
previously obtained models of the system are represented in Reliability Analysis Objectives (RAO) work-product, the
terms of the constructs offered by the target simulation reliability indicators and the scenarios of interests are
platform. Finally, simulation results are analyzed with identified along with the main analysis techniques to be
respect to the objectives of the reliability analysis; if applied to the data gathered from simulation. In the RAO, a
necessary, new partial or complete process iterations are visual representation of the SR can be also provided
executed. through SysML Requirements Diagrams along with the
allocation of these requirements (especially the reliability
In the following sub-sections each of the above ones) to main system components.
sketched phases will be described by focusing on the
enhancement introduced in the present version of RAMSAS 2.2 System Modeling
respect to the previous ones. Complete examples of the
execution of the RAMSAS phases and related work- In the System Modeling phase the structure and both
products can be found in [3, 4, 5]. the intended and dysfunctional behavior of the system
under consideration are represented in SysML by executing
Table 1. RAMSAS phases and related work-products four modeling activities (see Figure 1): System Structure
Modeling, Intended Behavior Modeling, Dysfunctional
Phases Input work-products Output work-
products
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. entity should be taken into account; as a consequence, for
Each system entity is defined by both a Block Definition each entity at a not-leaf decomposition level:
Diagram (BDD) and an Internal Block Diagram (IBD).
Specifically, for a given abstraction level, a BDD describes • beside the services (or function) provided by the
a block with its interfaces, attributes, operations, entity, how these services can be obtained by
constraints, parts and relationships with other blocks; composing the services provided by the sub-
whereas, an IBD provides a description of the block entities should be also specified;
internal structure in terms of the organization of its
component blocks. • each task (flow of activities/actions) performed
by the entity for providing a specific service (or
function) has to be specified by an Activity
2.2.2 Intended Behavior Modeling Diagram possibly highlighting through swimlanes
In the Intended Behavior Modeling activity the the responsibility of each sub-entity in carrying
intended (or normal or expected) behavior of the system is out the activities of the task;
represented following also a layered approach but
combining the top-down with a bottom-up strategy. The • the exchange of messages between the entity and
reference model is service and task-oriented: the behavior the external environment should be represented
of each entity is modeled in terms of the services (or through Sequence Diagrams possibly highlighting
functions) that the entity is able to provide and which are the role played by its sub-entities in each
performed through tasks. In order to specify the behavior of interaction (e.g. by explicitly representing them
the system and its component entities, two levels of as participants in the diagrams);
decomposition are considered: leaf level (e.g. component
level) and non-leaf level (e.g. equipment, subsystem or • in case the behavior of the entity depends on its
system level). internal state, a state machine which models the
entity life cycle can be specified through a
In particular, for each entity at the leaf decomposition Statechart Diagram; the diagram can adopt
level (the lowest decomposition level): advanced constructs, such as composite states,
AND/OR-decomposition and history pseudo-
• the services (or functions) provided by the entity, states, for representing how the behavior of the
in terms of their input and output work-products entity is related to the behavior of its sub-entities.
along with pre and post conditions, should be
specified;
2.2.3 Dysfunctional Behavior Modeling
• each task (flow of activities/actions) performed In the Dysfunctional Behavior Modeling activity, the
by the entity for providing a specific service (or focus is on the modeling of faults and failures, which are
function) has to be specified through an Activity key concepts of the system reliability analysis [2].
Diagram; each task can be scheduled or Specifically, the behavior, concerning faults and failures of
triggered by incoming events/messages; each system entity (i.e. the dysfunctional behavior), is
specified as a set of specific tasks (which can be modeled
• the exchange of messages between the entity and through Activity Diagrams). The reference model of a
the external environment (which can be another generic system entity, regardless on the considered
entity at the same or at a higher decomposition abstraction level, is shown in Figure 2. An entity is
level) should be represented through Sequence represented by a SysML Block which provides a set of
Diagrams; services/functions; the tasks performed by the entity for
providing these services are modeled during the Intended
• in case the behavior of the entity depends on its Behavior Modeling phase (see Section 2.2.2). Beside the
internal state, a state machine which models the intended behavior specified through these tasks, a set of
entity life cycle can be specified through a dysfunctional tasks are added so to model the dysfunctional
Statechart Diagram. behavior of the entity [1, 6]. In particular, each block could
receive as input a set of failure events (e.g. due to the
Moving from the leaf decomposition level to higher failures of other blocks) and could, in turn, produce in
decomposition levels (not-leaf decomposition levels), the output other failure events due to its failure; moreover,
representation of the entity behavior is similar; however, internal faults (represented as fault events) can be generated
how the component entities (i.e. sub-entities) participate and treated inside the block possibly producing block
and determine the behavior of the considered enclosing 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 Tasks of the Fault and Failure Generation type (see
individuated (see Figure 3): Fault Generation, Failure Figure 3.a and 3.b respectively) can generate a fault/failure
Generation, Failure Management, Fault Management as a result of specific causes occurring according to a given
Failure Propagation, and Failure Transformation. 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
Figure 2. The reference Behavioral Model of a system entity 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
(a) Fault Generation 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 Simulation Execution activity the ESM is
In the Behavior Integration activity, the normal/intend executed by varying the desired parameters according to the
behaviors and the dysfunctional behaviors modeled in the analysis objectives reported in the RAO. Specifically, the
previous modeling activities (see Section 2.2.2 and 2.2.3) ESM is executed by Simulink according to a synchronous
are integrated to obtain an overall behavioral model of the reactive model of computation: at each step, Simulink
system and its component entities. As an example, starting computes, for each block, the set of outputs as a function of
from the Activity and Sequence diagrams which have been the current inputs and the block state, then it updates the
used to model both the intended and dysfunctional block state. During the simulation faults and failures can be
behaviors of the system entities, a complete and integrated injected and/or caused to stress and analyze the reliability
definition of the life cycle of each entity, regardless on the performance of the system. At the end, the data generated
considered abstraction level, can be obtained and from the simulations are reported in the Simulation Results
represented through a Statechart diagram. This activity (SIRE) work-product to be analyzed in the next phase.
closes the System Modeling phase by delivering the System
Model for Reliability Analysis (SMRA) work-product. Table 2. Mapping among SysML and Simulink constructs
Entity SysML Simulink
2.3 System Simulation
System/Subsystem/ Block, Part Block, Subsystem
The objective of the System Simulation phase is to Equipment/Component Block
evaluate through simulation the reliability performance of Behavior/Constraint Activity Diagram, S-Function, State
the system and, possibly, compare different design Sequence Diagram, Flow diagram
alternatives and parameters settings; in particular, the Statechart Diagram,
following three (see Figure 4) main activities are Parametric Diagram
performed: Model Transformation, Parameters Setting, and Input/Output Interface Flow Port Input/Output
Simulation Execution. 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
Figure 4. Activities of the System Simulation phase
Simulink, whereas more advanced analyses can be
In the Model Transformation activity the previously performed by external tools by exporting the obtained
obtained Models of the System in the SMRA are results through the MATLAB Workspace. As a result, the
represented in terms of the constructs offered by the target following two work-products are produced in output:
simulation platform which is, currently, MathWorks
Simulink, so producing an Executable System Model • Reliability Analysis Report (RAR), which
(ESM). This transformation is based on a mapping between provides a detailed analysis about the reliability
the basic SysML and Simulink constructs (see Table 2) [3, performance of the system under consideration;
4, 10]. It is worth noting that not only the intended behavior
of the system but also the dysfunctional tasks (see Section • Design Suggestions Report (DSR), which
2.2.3) which are essential for analyzing during the provides a set of suggestion to improve the
simulation the reliability performance of the system are design of the system and/or choose among
generated. Indeed, this allows to suitably injecting faults different design choices. It is worth to note that
and failures during the simulation and setting the the DSR exploits typical FMECA and FTA
parameters of the related generation, management, notations and representation formats so to ease
propagation and transformation tasks (see Section 2.2.3). the use of RAMSAS in conjunction with classical
RAMS techniques.
In the Parameters Setting activity the ESM is refined
so to allow the flexible setting of system configuration and As for any iterative process, new (partial or complete)
simulation parameters which can be tuned according to iterations of RAMSAS can be executed for achieving new
both the characteristics of the operative scenario to simulate or missed analysis objectives.
and the dysfunctional behaviors to analyze.
 3 Discussion and Conclusions References
The current version of RAMSAS, described in Section [1] R. Cressent, V. Idasiak, F. Kratz, and P. David,
2, has been originally conceived for large-scale systems, i.e. “Mastering safety and reliability in a model based process,”
systems which are constituted by a multitude of components Proc. of the Reliability and Maintainability Symposium
organized so to form a whole with clearly defined (RAMS), Lake Buena Vista, FL (USA), January 2011.
boundaries. Examples of this kind of systems are military
and commercial aircraft, spacecraft, satellites, power plant [2] B. Dodson and D. Nolan, Practical Reliability
automobiles, etc. The reliability analysis of these systems is Engineering, John Wiley & Sons Ltd, England, 2001.
a challenging task which, as proved by RAMSAS, could
benefit both from model-based approaches and from [3] A. Garro and A. Tundis, “Enhancing the RAMSAS
simulation [3, 4, 5]. However, although the structure of method for System Reliability Analysis: an exploitation in
these large-scale systems is rather complex (or better the automotive domain,” Proc. of the 2nd Int. Conf. on
complicated) it remains quite the same during the system Simulation and Modeling Methodologies, Technologies and
life cycle; moreover, a great part of the system components Applications (SIMULTECH), Rome (Italy), July 2012.
manifest a reactive behavior and pro-activeness is limited to
a narrow subset of components. Moving from large-scale [4] A. Garro and A. Tundis, “A Model-Based method for
system to the System of Systems (SoS) context, these System Reliability Analysis,” Proc. of the Symposium On
assumptions typically do not hold [8]. Indeed, a SoS (e.g. a Theory of Modeling and Simulation (TMS), Orlando, FL
Coast Guard Integrated Deep-water System or an Air (USA), March 2012.
Traffic Management System) is constituted by a set of
interconnected, and often geographically distributed, [5] A. Garro, A. Tundis, and N. Chirillo, “System
systems which interact for achieving common goals and are reliability analysis: a Model-Based approach and a case
capable of autonomous and independent behaviors; study in the avionics industry,” Proc. of the 3rd Air and
moreover, the set of involved systems typically changes Space International Conference (CEAS), Venice (Italy),
during the SoS life as new systems join the SoS and other October 2011.
dynamically leave it. As a consequence, the reliability
analysis of a SoS presents different and peculiar aspects [6] L. Grunske and B. Kaiser, “Automatic Generation of
respect to that of a large-scale system that need to be Analyzable Failure Propagation Models from Component-
accurately taken into account and that require for specific Level Failure Annotations,” Proc. of the 5th Int. Conf. on
approaches and techniques. Some features of RAMSAS are Quality Software (QSIC), Melbourne (Australia),
particularly suited for the reliability analysis of SoS such as September 2005.
the adoption of zooming in-out mechanisms for the
structural and behavioral modeling of the system, and the [7] IEC 61508, Functional safety of
exploitation of simulation both for the analysis of system electrical/electronic/programmable electronic safety-
properties and for the evaluation of alternative scenarios related systems, Parts 1-7, 2010.
and design choices. However, new features need to be
added; as an example, the possibility to define the potential [8] M. W. Maier, “Architecting Principles for Systems of
changes in the system structure during the system life cycle. Systems,” Systems Engineering, Vol 1, No. 4, pp. 267-284,
Moreover, specific concepts to explicitly model the pro- 1999.
active (and thus autonomous) part of the behavior of the
SoS entities (which are themselves systems) should be [9] A. Molesini, A. Omicini, A. Ricci, and E. Denti,
introduced (such as the goals that the entity will to achieve). “Zooming multi-agent systems,” Proc. of the 6th Int.
These novelties could lead to evolve the current vision of Workshop on Agent-Oriented Software Engineering,
system adopted in RAMSAS to a more agent-oriented one Utrecht (The Netherlands), July 2005.
in which a SoS is treated, and thus modeled and simulated
as a Multi-Agent System [9]. Ongoing and future research [10] A. Sindico, M. Di Natale, and G. Panci, “Integrating
activities are devoted to investigate how to further extend SysML with Simulink using Open-Source model
RAMSAS in the above mentioned directions so as to transformations,” Proc. of the 1st Int. Conf. on Simulation
effectively support the reliability analysis of SoS. and Modeling Methodologies, Technologies and
Applications (SIMULTECH), Noordwikerhout (The
Acknowledgments Netherlands), July 2011.
Andrea Tundis was supported by a grant funded in the
framework of the “POR Calabria FSE 2007/2013”.

View publication stats