Upload
tranthuan
View
222
Download
1
Embed Size (px)
Citation preview
Mini Scuola su Systems Engineering
System Dependability Analysis: Main Issues and Possible Solutions
Prof. Ing. Alfredo Garro
System Modeling and Simulation Hub (SMASH) Lab
Member of the Italian Chapter of INCOSE
CIISE 2014
Conferenza INCOSE Italia su Systems Engineering
24-25 Novembre, 2014 Università di Roma "Tor Vergata", Roma
� Reference context
� System Dependability and RAMSAS Analysis
� Safety:
� From Safety Requirements to Simulation-driven Design of Safe Systems
� Performing Fault Tree Analysis of a (Modelica-based) System Design through a Probability Model
� Reliability:
� RAMSAS: A Model-Based method for System Reliability Analysis
� From RAMSAS to RAMSAS4Modelica
� System Dependability Analysis through Platform-independent Simulation Model
� Conclusions and future works
Outline
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 2
The reference context…Systems Engineering and M&S: from V model to W model
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 3
WP2 - Properties Modeling involved partners…
: An European Project
Alfredo Garro - DIMES Department - University of Calabria (Italy) 4
WP2’s Objectives:
� Formalization of system requirements;
� Definition of methods for effective Safety Analysis of physical systems.
OTHER INFO on https://itea3.org/project/modrio.html
System Dependability and RAMS Analysis
16 September 2013 - ESA Directors at Technology Workshop - ESTEC, Noordwijk, the Netherlands.
“One failure has an equivalent impact to ten success es.”
Volker LiebigESA Director of Earth Observation Programmes
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 5
System Dependability and RAMS Analysis
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 6
� Currently RAMS (Reliability, Availability, Maintainability, Safety) analyses are typically carried out using a layered approach and through both quantitative and qualitative analysis techniques.
Quantitative Analysis
Qualitative Analysis
Suitable for Software Intensive Systems
Series-Parallel x - -
Markov Chains x - -
FMEA/FMECA - x X (S-FMEA/S-FMECA)
FTA - x X (S-FTA)
HAZOP - x xHSIA - x x
SCCFA - x xPSH - x x
Reliability Analysis: from LRUs (Lowest Replaceable Unit) to SoS (System of Systems)
LRU/component
equipment
system
large-scale system
System of Systems (SoS)
com
plex
ity
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 7
SAFETY:
From Safety Requirements to Simulation-driven Design of Safe
Systems
A Model-based approach for Safety Analysis of Systems
Alfredo Garro - DIMES Department - University of Calabria (Italy) 9
A model-based approach for the Safety Analysis of Systems (inspired by ISO-26262) which:
� is defined in terms of process by providing a methodological support for the verification and validation of safety requirements and their traceabilitythrough simulation;
� provides a comprehensive approach for the definition and modeling of requirements of a physical system in a more formal way;
� combines in a unified framework the benefits of popular OMG modeling languages (UML/SysML) as well as model-driven engineering tools and techniques with OpenModelica, an equation based simulation environment based on the Modelica language.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 10
Our Proposal:A Model-driven Process for the Validation and Verification
of Safety Properties of SystemsThe process is centered on a classical iterative process which consists of three main phases, defined according to a proposed meta-model.
A meta-model for modeling System Requirements as RequirementAssertions
Alfredo Garro - DIMES Department - University of Calabria (Italy) 11
Main Concepts of the proposed meta-model for modeling System Requirements as RequirementAssertions
Alfredo Garro - DIMES Department - University of Calabria (Italy) 12
Main Concepts:� requirement : which is represented by a
RequirementAssertion able to validate the behaviorof a specific PhysicalComponentModel which isrelated to, or to validate interactions among differentPhysicalComponentModels
� fulfill : which expresses the entailment relationshipbetween PhysicalComponentModels and aRequirementAssertion, as well as amongRequirementAssertions. Fulfill provides thepropagation mechanism of an assessment amongRequirementAssertions.
Ex. PhysicalComponentModel c1, c2, c3;RequirementAssertion ra1, ra2, ra3;
c1 fulfill ra1;ra1 fulfill ra2;c2, c3, ra2, fulfill ra3;
Requirements Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 13
In the Requirements Analysis phase the system safety objectives are analyzed and Safety requirements, in terms of System Requirements, are identified…
FROM
User Requirements (URs) ����
TO
���� System Requirements (SRs)
System Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 14
In the System Modeling phase, a possible physical model of the actual system, in terms of its components, is defined by applying in-out zooming mechanisms , by combining both a top-down and a bottom-up fashio n.
In particular, the Structural and the Behavioral views are generated by breaking down the system in (sub)components.
Behavior Modeling
Structure Modeling
System Requirements are further refined according to the defined meta-model in terms of RequirementAssertion …
Virtual Testing
Alfredo Garro - DIMES Department - University of Calabria (Italy) 15
� PhysicalComponentsModel and RequiremetsModel are represented byusing the Modelica language and integrated into anExtendedSystemDesign Model ;
� Different simulation scenarios are set and simulations are executed ;
� simulation results can be analyzed on the basis of the system s afetyrequirements identified in the first process phase.
In the Virtual Testing phase, the Models of the system under consideration are transformed into executable models and represented in terms of the constructs offered by the OpenModelica* platform; in particular:
* an Open Source simulation environment based on the Modelica language (an equation-based object-oriented language for representing physical systems with acausal features).
From Safety Requirements To a Safe Design of an Airbag System: A Case Study
Alfredo Garro - DIMES Department - University of Calabria (Italy) 16
Modeling of an airbag system; Validation and evaluation of the design according to the safety
requirements through simulation.
A brief description of the Airbag System Components:
- a sensor that detects the abrupt deceleration of the vehicle caused by animpact and the pressure;
- an Airbag Control Unit (ACU) that monitors the readiness of the entire airbagsystem.
- a detonator that triggers the substance contained in the explosive capsulethrough an electric current or a bump of a ferrule;
- a possible second capsule that contains pre-compressed inert gas whichinflates the airbag;
- a warning light which is illuminated if a fault is detected.
Requirements Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 17
In the Requirements Analysis phase requirements are firstly elicitated…
For example:
� AbruptDeceleration (Req1): when the deceleration d is greater than athreshold, a signal to switch on the electronic circuit has to be sent;
� InflationTime (Req2): the time to inflate the airbag has to take less than40ms: inflationTime<=40;
� CollitionDetection (Req3): when the collision is detected by the sensor, acollitionSignal has to be generated;
� DeflationTime (Req4): the airbag has to be able to deflate in adeflationTime lesser than a deflation threshold;
� Activation (Req5): after a crash the airbag is deployed in a delayTimeequal to 45ms.
� …
Requirements Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 18
…and then dependencies among them are identified…
Furthermore scenarios to be analyzed has to be defined:
(Scenario #1) the airbag is not ignited or is inflated too late even though a critical crash occurred;
(Scenario #2) the airbag is deployed unintentionally, which means that it is ignited even though no crash at all or only a non-critical crash has occurred
System Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 19
In System Modeling phase both the physical structure of the system is built by composing components…
BDD: Components of the Airbag System
IBD: Components Interactions of the Airbag System
System Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 20
… then the behavior of each single component is specified, by exploiting a ComputationalModel (CM) . In this case the CM is based on an EquationsSet…
Computational Model of the Airbag component
System Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 21
… finally, requirements modeled in the previous phase, which need to be verified, are allocated to (i) a single physical component in order to check its behavior or (ii) a set of physical components in order to check if the interaction among them is or is not consistent as expected.
Allocation of Safety Requirements to the Airbag Physical System Model
Virtual Testing
Alfredo Garro - DIMES Department - University of Calabria (Italy) 22
Verification is performed through simulation in order to study the behavior of the system under consideration and analyze interesting aspects or, possibly, to discover some issues that are not immediately obvious when applying static analysis techniques.
The OpenModelica environment has been chosen as simu lation platform since:
(i) it is equation based (by implementing the Modelica Language ) and, as a consequence, compliant with the Computational Model which has been used to represent the behavior of the overall Airbag System;
(ii) it is open source , thus allowing the possibility to extend both the language and the tool, to enable modeling of requirements and introduce allocation mechanisms.
Virtual Testing
Alfredo Garro - DIMES Department - University of Calabria (Italy) 23
Representation of the Behavior of the Airbagcomponent in Modelica standard language,according to the EquationsSet ComputationalModel.
Formalization of theInflationTime requirement byusing Modelica languageextensions (requirement andprecondition equation ).
DEFINITION STEP
Virtual Testing
Alfredo Garro - DIMES Department - University of Calabria (Italy) 24
The fulfill keyword is employed for creating the bindingamong the requirements as well as between requirementsand physical components of the AirbagSystemDesign.
ALLOCATION STEP
Virtual Testing: Verification of the Inflation Time
Alfredo Garro - DIMES Department - University of Calabria (Italy) 25
The airbagPressure (in light blue color) is not able to reach the safePressureLevel(in yellow color) within the maxInflationTime (in 40 milliseconds) as expected
Violation of the InflationTime requirement detected
ANALYSIS
STEP
Requirement Violation Detected
Virtual Testing: Verification of the Inflation Time
Alfredo Garro - DIMES Department - University of Calabria (Italy) 26
By setting opportunely some parameters of the airbag system, for example, byincreasing the pressure to be provided in input to the airbag (pressureIn in light greencolor), it is possible to reach the necessary parameters tuning which fulfills all therequirements in the considered scenario
ANALYSIS
STEP
Requirement Fulfillment Reached
Fulfillment of the InflationTime requirement reached
Relationships between the ISO-26262 standard and the proposed process
Alfredo Garro - DIMES Department - University of Calabria (Italy) 27
It is worth to notice that the proposed process is inspired by the IEC-61508 standard and, in particular, by the ISO-26262 whose goal is to show the capability to develop certain products with acceptable risks:
ISO-26262 Simulation-Driven Process for the Design of Safe Systems
VocabularyManagement of Functional Safety
Concept phase
Requirements Analysisphase
Product Development at system level Product development at the hardware levelProduct development at the software level
System Modelingphase
Supporting Process Virtual Testingphase
SAFETY:
Performing Fault Tree Analysis of a Modelica-based System Design
through a Probability Model
From System Design to Fault Tree Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 29
An approach for supporting Fault Tree Analysis of a Modelica-ba sed Design by providing:
� a methodological process for supporting Requirements definition and modeling of System Design as well as their Integration ;
� a Probability Model implemented through Annotations, which allows the representation of probabilities in relation with different design models (e.g. PhysicalComponentModels, RequirementsModels);
� an extension of the OpenModelica APIs for retrieving static information for the automatic generation of a Fault Tree Diagra m (FTD) by exploiting some proposed Modelica extensions to enable Fault Tree Analysis (FTA);
� an implementation in the OpenModelica environment (OpenModelica), an Open Source simulation environment based on the Modelica language;
Alfredo Garro - DIMES Department - University of Calabria (Italy) 30
The reference process for supporting the Fault Tree Analysis of a Modelica-based design
A PCM represents a Modelica-based model of a Physical System
A RM represents System Requirements through RequirementAssertions
An ESD is a composite model which is defined by integrating both the PCMs and the RMs to be verified.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 31
The reference process for supporting Fault Tree Analysis in Modelica
The PM consists of a list of possible states in which a component can be (i.e. operating, operating in degraded mode, broken) and, eventually, of a set of characteristics associated with each state.
Modelica Annotations are used to combine the Probability Modelwith a Modelica-based Design represented by an ESD
Alfredo Garro - DIMES Department - University of Calabria (Italy) 32
The reference process for supporting Fault Tree Analysis in Modelica
The generation of Fault Tree Diagrams (FTDs) is enabled in OMEdit through the implementation of Modelica APIs.
The diagram is generated by exploiting two main information sources:� the fulfill relationships, which are used to extract the structure of the Fault Tree Diagram from the ExtendedSystemDesign;�the information provided by the Probability Modelconcerning both the operating states and the related values of probability for each component of the Modelica-based design.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 33
Supporting Fault Tree Analysis of a Modelica-based design of Tank System
Tank System – description .The Tank System under consideration iscomposed by four main Components: a Source(also called LiquidSource) component, a Tankcomponent, a LevelController component and aSink component.
RequirementAssertions RAs (Properties ) to be verified: RA_1: LimitInFlow , which takes in input the value of
the qOut port of the Source component. It is satisfied if the liquid flow produced by the Source component is less than a specific “maxLevel” (i.e. liquidFlow<=maxLevel, in this case maxLevel =10).
RA_2: ControlOutFlow , which takes in input the h level from the Tank component and the qOut flow to validate the role of the LevelController; moreover, to be valid it requires that the RA_4 and the RA_4 are both fulfilled.
RA_3: ActuateOutFlow , which takes in input both the tActuator (Out-flow) and the outFlowArea and checks if the outFlowArea value is proportional at the tActuatorsignal.
RA_4: SenseLevel , which takes in input both the h level and the tSensor and checks if the sensor output is equals to the h level (i.e. lLevel=sensorOuput).
RA_5: ControlLevel , which takes in input the h level coming from the Tank component, checks if hLevel<9 and hLevel>5; moreover, to fulfill the RequirementAssertion_5, both the RA_1 and RA_2 have to be satisfied.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 34
Fault Tree Analysis of a Tank System
System Design (SD) ���� integration of Physical Component Models (PCMs)
Alfredo Garro - DIMES Department - University of Calabria (Italy) 35
Fault Tree Analysis of a Tank System
A RequirementsModel (RM) for the Tank System
Alfredo Garro - DIMES Department - University of Calabria (Italy) 36
Fault Tree Analysis of a Tank System
Extended System Design (ESD) = System Design (SD) + RequirementsModel (RM) by using the Modelica extensions:- fulfill equation- requirement class
Alfredo Garro - DIMES Department - University of Calabria (Italy) 37
Fault Tree Analysis of a Tank System: a Case study
Introducing the ProbabilityModel for the Tank System: in this case each model defines two possible states:- Success : which represents the
probability of success of a component performing its work;
- Failure : which represents the probability of failure of a component performing its work.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 38
Fault Tree Analysis of a Tank System: Type of Annotations
A PhysicalComponentModel annotated with a Probability Model during its definition
An instance of PhysicalComponentModelannotated with a Probability Model.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 39
Fault Tree Analysis of a Tank System: Using OMEdit –OpenModelica for generating the FTD
An extension of OMEdit, for supporting modeling and generation of Fault Tree Diagrams
Graphical representation of the ExtendedSystemDesign of the Tank System by using the GeNIe analysis environment.
Extensions of OpenModelica for supporting ProbabilityModel annotations and Faut Tree Diagram generation
Alfredo Garro - DIMES Department - University of Calabria (Italy) 40
Fault Tree Analysis of a Tank System: Results
Fault Tree Analysis in GeNIeanalysis environment
The Fault Tree Analysis of the system with the top level represented by the requirement ControlLevel shows that- the probability of Failure is equal to
14%;- whereas the probability of Success
is equal to 86%;
RELIABILITY:
RAMSAS: A Model-Based method for System Reliability Analysis
Depandability Analysis: from LRUs (Lowest Replaceable Unit) to SoS (System of Systems)
LRU/component
equipment
system
large-scale system
System of Systems (SoS)
com
plex
ity
Alfredo Garro - DIMES Department - University of Calabria (Italy) 42
� centered on a popular UML-based language for system modeling (SysML )
� exploiting a de facto standard platform for the simulation of multi-domain dynamic and embedded systems (Mathworks Simulink )
� fully specified as a method (in terms of phases, input and output workproducts, etc.) and thus “pluggable” in a complete System Development Process (e.g. based on a V-Model)
RAMSAS: A Model-Based method for System Reliability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 43
RAMSAS: A Model-Based method for System Reliability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 44
The RAMSAS method is centered on a classical iterative process which consists of four main phases.
When and where to exploit our method in a typical System Development Process
The proposed method is not intended to be an alternative to other RAMS techniques (FMECA, FTA, RDB, etc.) but rather
a complement able to provide
additional analysis capabilities
Alfredo Garro - DIMES Department - University of Calabria (Italy) 45
Exploiting the RAMSAS methodfor System Reliability Analysis
� RAMSAS has been also experimented:
� in the satellite domain for the reliability analysis of an Attitude Determination and Control System (ADCS) [1]
� in the avionics domain for the reliability analysis of:
� a Landing Gear System [2];
� a Flight Management System [3];
� in the automotive domain for the reliability analysis of an Electronic Stability Control (ESC) system [4];
� [1] A. Garro, J. Groß, M. Riestenpatt Gen. Richter, A. Tundis. Reliability Analysis of an Attitude Determination and Control System (ADCS) through the RAMSAS method. Journal of Computational Science, 5(3):439-449, 2013, Elsevier B.V., Amsterdam (The Netherlands).
� [2] A. Garro, A. Tundis, N. Chirillo. System reliability analysis: a model-based approach and a case study in the avionics industry. Proceedings of the 3rd Air and Space International Conference (CEAS). October 24-28, 2011, Venice (Italy).
� [3] A. Garro, A. Tundis. A model-based method for system reliability analysis. Proceedings of the Symposium on Theory of Modeling and Simulation (TMS). March 26-29, 2012, Orlando (FL, USA).
� [4] A. Garro, A. Tundis. Enhancing the RAMSAS method for System Reliability Analysis: an exploitation in the automotive domain. Proceedings of the 2nd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH). July 28-31, 2012, Rome (Italy).
Alfredo Garro - DIMES Department - University of Calabria (Italy) 46
The On-Board Communication System (OBCS) of a Metro Train
� The considered On-Board Communication System(OBCS), supplied by SELEX ES is installed on the Line 5 of the Milan Metro train
� It is composed by a set of devices required to perform safety tasks and functions as well as the dissemination of information to passengers such as: � bidirectional audio communication between the Central Station
Operator and Passengers when a situation of emergency occurs;
� communication between Operators;
� data exchanging for diagnosis among equipment;
� on board video monitoring, and sending of live/recorded messages to passengers.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 47
The On-Board Communication System (OBCS) of a Metro Train
Alfredo Garro - DIMES Department - University of Calabria (Italy) 48
RAMSAS: The Reliability Requirements Analysis phase
� Total Block (TB): a block of the system operation for a time more than 3 minutes;
� Partial Block (PB): a block of the overall system operation from 3 minutes up to 10 minutes;
� Delay : a delay of the overall system operation for a time less than 3 minutes
Alfredo Garro - DIMES Department - University of Calabria (Italy) 49
Adverse Event
Unavailability
Failure Rate (λ)[hour-1]
DownTime_evMAX[hour]
Total Block
1-0,9999 = 0,0001
- -
Partial Block
- 2,31E-06 0,16(~10 min.)
Delay - 4,33E-06 0,05(~3 min.)
Availability=MSPMSS
MPS: minutes of performed service
MSS: minutes of scheduled service
RAMSAS: The System Modeling phase
� In the System Modeling phase the structure and both the intended and dysfunctional behavior of the System under consideration are modeled by using a SysML based notation.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 50
RAMSAS: The System Modeling phase �System Structure Modeling
� In this phase the System is decomposed in component entities by applying in-out zooming mechanisms .
Alfredo Garro - DIMES Department - University of Calabria (Italy) 51
Behavior Modeling
Structure Modeling
RAMSAS: The System Modeling phase �System Structure Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 52
RAMSAS: The System Modeling phase �System Structure Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 53
RAMSAS: The System Modeling phase �Intended/Nominal Behavior Modeling
� Typically based on a bottom-up approach :
� the behavior of the system entities at the lowest l evel in the hierarchy (e.g. component level) are first specified ;
� then, the behavior of the entities at higher levels of abstraction (e.g. equipment and subsystem level) are modeledby specifying how the enclosed entities participate and determine the behavior of each considered enclosing entity.
� Different kind of SysML diagrams can be exploited to model the behavior of a given entity : o Activity
o Sequence
o Parametric
o Statechart
the choice is made the basis of to the characteristics of the behavior and the abstraction level to represent
Alfredo Garro - DIMES Department - University of Calabria (Italy) 54
� Intended behavior of a Control Unit
RAMSAS: The System Modeling phase �Intended Behavior Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 55
� Intended Behavior of a Control Unit when a Passenger Call occurs
RAMSAS: The System Modeling phase �Intended Behavior Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 56
RAMSAS: The System Modeling phase �Intended Behavior Modeling
The modeling of the intended behavior can be straightforward if during the system design similar structural and behavioral reference
models have been adopted along with a UML based modeling notation
Alfredo Garro - DIMES Department - University of Calabria (Italy) 57
RAMSAS: The System Modeling phase �Dysfunctional Behavior Modeling
� In the Dysfunctional Behavior Modeling activity, the focus is on the modeling of faults (a defect in a block) and failures(an observable deviation from the intended behavior at the system boundary)
Alfredo Garro - DIMES Department - University of Calabria (Italy) 58
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.
A basic pattern is associated to a couple
(dysfunctional task type ; fault/failure type )
As a consequence, beside the individuated six dysfunctional task types, a (possibly hierarchical) classification of faults/failures needs to be introduced .
RAMSAS: The System Modeling phase �Dysfunctional Behavior Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 59
A first solution could consider the following fault/failure types :
(i) reaction too late;
(ii) reaction too early;
(iii) value failure;
(iv) commission;
(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
RAMSAS: The System Modeling phase �Dysfunctional Behavior Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 60
� FaultManagement task of a Control Unit subsystem
RAMSAS: The System Modeling phase �Dysfunctional Behavior Modeling
Alfredo Garro - DIMES Department - University of Calabria (Italy) 61
� FailurePropagation task of a Control Unit subsystem
intended behaviors + dysfunctional behaviors
an overall behavioral model of the system and its component entities
This activity closes the System Modeling phase by delivering the System Model for Reliability Analysis (SMRA) work-product
RAMSAS: The System Modeling phase �Behavior Integration
Alfredo Garro - DIMES Department - University of Calabria (Italy) 62
� BehaviorIntegration of the Control Unit subsystem behavior
RAMSAS: The System Modeling phase �Behavior Integration
Alfredo Garro - DIMES Department - University of Calabria (Italy) 63
� Failure situation of a PassengerCall
RAMSAS: The System Modeling phase �Behavior Integration
Alfredo Garro - DIMES Department - University of Calabria (Italy) 64
RAMSAS: The System Simulation phase
� 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
Alfredo Garro - DIMES Department - University of Calabria (Italy) 65
RAMSAS: The System Simulation phase �Model Transformation
� Transformation between models is based on a mapping between the basic SysML and Simulink constructs :
Entity SysML SimulinkSystem/Subsystem/
Equipment/ComponentBlock, Part Block, Subsystem
Block
Behavior/Constraint Activity Diagram, Sequence Diagram, Statechart Diagram, Parametric Diagram
S-Function, State Flow diagram
Input/Output Interface Flow Port Input/Output Simulink Block
Association/Binding Connection Line
Alfredo Garro - DIMES Department - University of Calabria (Italy) 66
RAMSAS: The System Simulation phase �Model Transformation
Alfredo Garro - DIMES Department - University of Calabria (Italy) 67
RAMSAS: The System Simulation phase �Model Transformation
Alfredo Garro - DIMES Department - University of Calabria (Italy) 68
RAMSAS: The System Simulation phase �Parameter Setting
Alfredo Garro - DIMES Department - University of Calabria (Italy) 69
Parameter Description Range Value
Scale Factor
It represents the statistical dispersion of the Weibull
distribution
[0-∞] 1.5
ShapeFactor
It defines the shape of the Weibull distribution and
the position of itsmaximum.
[0-∞] 1
FailureManagement
threshold
It represents the threshold value for the management
of failure
[0-∞] 0.1
FailureGenerationthreshold
It represents the threshold value for the generation of
failure
[0-∞] 3.5
… … … …
RAMSAS: The Results Assessment phase
� In the Results Assessment phase, the data gathered from the simulations are analyzed with reference to the objectives of the reliability analysis identified i n the initial phase of the process:� directly in Simulink� by using useful add-on like SIMLOG� by external analysis tools
Alfredo Garro - DIMES Department - University of Calabria (Italy) 70
RAMSAS: The Results Assessment phase
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.
�As for any iterative process, new (partial or complete) iterations can be executed for achieving new or mis sed analysis objectives
Alfredo Garro - DIMES Department - University of Calabria (Italy) 71
RAMSAS: The Results Assessment phase
Alfredo Garro - DIMES Department - University of Calabria (Italy) 72
� The analysis of the simulation data can provide useful indications which allow obtaining a more descriptive and predictive reliability system model and suggest some design choices which could improve the system reliability indicators
Target values Design with One CU Design with Two CUs
TB
Unavailability = 1-Availability
= 1-0,9999 = 0,0001
Unavailability = 0,17 Unavailability = 0,0001
PBλ= 2,31E-06 [h-1]
DownTime_evMAX = 0,16 [h]
λ = 4,02E-07 [h-1]
DownTime_evMAX < 0,16[h]
λ = 9,01E-09 [h-1]
DownTime_evMAX < 0,16[h]
Delayλ= 4,33E-06 [h-1]
DownTime_evMAX = 0,05 [h]
λ=5,72E-06 [h-1]
DownTime_evMAX < 0,05 [h]
λ=6,33E-06 [h-1]
DownTime_evMAX < 0,05 [h]
RELIABILITY:
From RAMSAS to RAMSAS4Modelica
From RAMSAS to RAMSAS4Modelica
Alfredo Garro - DIMES Department - University of Calabria (Italy) 74
To define a version of RAMSAS based on the adoption of modeling and simulation technologies natively conceived for Modelica
���� RAMSAS4Modelica
Modelica :
• is an object-oriented equation-based programming language
• is acausal :
causal V= R*I � acausal R = V/I I = V/R V=R*I
• provides multi-domain modeling capabilities :
models of components corresponding to physical objects which belong to different domains can be described and connected in a unified model.
From RAMSAS to RAMSAS4Modelica
Alfredo Garro - DIMES Department - University of Calabria (Italy) 75
Main benefits of RAMSAS4Modelica :
availability of an integrated tool chain for supporting Dependability Analysis;
smooth learning curve for Modelica-skilled engineers; possibility to reuse Modelica-based system designs; possibility to combine advanced simulation
techniques with classic dependability analysis methods (such as Fault Tree Analysis);
Alfredo Garro - DIMES Department - University of Calabria (Italy) 76
How Activities change from RAMSAS to RAMSAS4Modelica method
Method
Phases
RAMSAS
Activities
RAMSAS4Modelica
ActivitiesDependability
Requirements Analysis -Requirements Modeling*
System Modeling System Structure Modeling System Structure Modeling** Intended Behavior Modeling Intended Behavior Modeling**Dysfunctional Behavior Modeling Dysfunctional Behavior ModelingBehavior Integration Behavior Integration**
- Requirement Binding*System Simulation Model Transformation Model Transformation**
Parameters Setting Parameters Setting**Simulation Execution Simulation Execution**
Results Assessment - Fault Tree Diagram Generation*(optional)
*new activity introduced in RAMSAS4Modelica.
**redefined activity respect to that of the RAMSAS Method.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 77
How Models change from RAMSAS to RAMSAS4Modelica
Entity SysML constructs ModelicaML constructs
System,Subsystem,Equipment,Component
Block, Part ModelicaClass,ModelicaFunction,ModelicaModel,ModelicaBlock,ModelicaRecord
Block Definition diagram Modelica Class diagram
Internal Block diagram Modelica Internal Classdiagram
Structuralrelationships
Connection, FlowPort,Interface
Modelica Connector
From Simulink To OpenModelica
Block, Subsystem Block Class, Function, Model, Block, Record
S-Function, State Flow diagram
Equations, Algorithms
Input/Output Simulink Port
Connector
Line connect
System Modeling phase: Main Constructs System Simulation phase: Main Constructs
Furthermore two new Modelica Constructs (ModelicaRequirement andModelicaFulfill) have been proposed for supporting:
• Dysfunctional Behavior Modeling;• Behavior Integration;• Requirement Binding.
���� ����
RELIABILITY:
System Dependability Analysis through Platform-independent Simulation
Model
� Analyze the dependability performances of a system on different simulation platforms starting from a comm on system representation could bring many advantages :
i. reusability of system models ;
ii. integration of different system models and their (co)simulation on heterogeneous and distributed environments ;
iii. combination and assessment of results gathered from the simulation of the same system model on different platforms .
Alfredo Garro - DIMES Department - University of Calabria (Italy) 79
Model-Based Dependability Analysis
� However, also some important cons could be identified:
i. the introduction of additional abstraction levels in the model-driven process ;
ii. the lack of (semi)automated mechanisms and rules for supporting the transformation from platform-independent to platform-specific simulation models ;
iii. the difficulty to keep the platform-independent models consistent with the platform-specific ones .
Alfredo Garro - DIMES Department - University of Calabria (Italy) 80
Model-Based Dependability Analysis
A model-chain for enabling Platform-Independent Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 81
82Alfredo Garro - DIMES Department - University of Calabria (Italy)
Current efforts as possible solutions:� The Simulation Model Portability (SMP) is a standard for simulation models
developed by ESA (European Space Agency) together with various stakeholders in the European Space Industry.
The main purpose of the SMP Standard is to promote portability and re-use of simulation models as well as at facilitating the use of simulation platform and allows for the rationalization of simulation developments by reusing existing models independently of the tool for which they have original been developed.
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Meta-models for the definition of PISM-D
83Alfredo Garro - DIMES Department - University of Calabria (Italy)
� Another research effort on system modeling and simulation is described in ECSS‐‐‐‐E‐‐‐‐TM‐‐‐‐10‐‐‐‐21A - Space engineering System modelling and simulat ion , which aims at providing guidance on how to use system simulation to support system engineering tasks . In particular, such guidance captures the current best practice within Industry and ESA and it is meant also to provide a support in order to specify and model concepts of systems, as well as to have a reference process plan.
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Meta-models for the definition of PISM-D
84Alfredo Garro - DIMES Department - University of Calabria (Italy)
In “Garro, Parisi, and Russo 2013” , a reference meta-model for the definition of PIM is presented in the context of a MDA-based process which is based on the exploitation of the Agent Modeling Framework (AMF). It is meant to provide an XML-based representation of PIMs that can be used t o generate platform-specific simulation models .
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Meta-models for the definition of PISM-D
85Alfredo Garro - DIMES Department - University of Calabria (Italy)
The NATO proposal is intended to be a guide for supporting the formalization of systems aspects in the modeling and simulation f ield , as well as for providing basic and shared concepts , widely accepted by the international M&S community, for representing Systems.
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Meta-models for the definition of PISM-D
86Alfredo Garro - DIMES Department - University of Calabria (Italy)
A second issue to be addressed for enabling the definition of PIMs is related to the choice of the modeling language to be used for representing PIMs compliant to a reference meta-model.� It depends on the concepts introduced in the meta-model as well as from
standards and best practices of reference for the communities of interest which range from cross-cutting communities (e.g. Modeling and Simulation, System Dependability Analysis) to those related to specific application domains in which dependability analysis is a critical and crucial task (e.g. Aerospace, Transportation, Energy).
Different textual and visual modeling languages are available to represent PIMs and can be considered as candidate solutions for the representation of PISM-Dsuch as:� XML (Extensible Markup Language)� UML/SysML (Unified Modeling Language/Systems Modeling Language) � CML (Conceptual Modeling formalism)� …
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Languages for the definition of PISM-D
87Alfredo Garro - DIMES Department - University of Calabria (Italy)
UML/SysML (Extensible Markup Language/Systems Model ing Languages):
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Languages for the definition of PISM-D
88Alfredo Garro - DIMES Department - University of Calabria (Italy)
Other visual languages are available to graphically represent PIMs such as: � CML (Conceptual Modeling Language formalism), that is specifically tailored
to model simulations of the tactical military mission space by using a formalism that is based on color-coded notation for representing the PIM concepts in which the Semantic Terms are organized in different types of concepts, such as Entities, Activities, Agents, Goals , and so on; whereas other Organizational Mechanisms are adopted for the definition of the structure and the relationships among such concept.
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Languages for the definition of PISM-D
89Alfredo Garro - DIMES Department - University of Calabria (Italy)
…� EXPRESS a standard modeling language for define data objects and
relationships among them for a specific domain of interest.
On The Definition of Platform-Independent Simulation Models for Dependability Analysis �
Languages for the definition of PISM-D
90
On the Definition of Platform-Specific Simulation Models for Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy)
Platform Specific Models (PSMs) are introduced in the Model-Driven Architecture (MDA) to specify and define the architecture and behavior of a system for its implementation on a specific software platform.In this case the objective is the definition of Platform-Specifi c Simulation Models for Dependability analysis (PSSMs-D) .A PSSM-D can be represented by using platform-speci fic and/or general purpose modeling languages (possibly ad-hoc extende d) with both textual and/or visual constructs.
The main factors that influence the choice of the targe t simulation platforms are:i. the simulation execution model ;ii. the supported modeling languages ;iii. the possibility to influence the simulation execution ;iv. the level of specialization and the explicit support pro vided for performing
dependability analysis .
91
Simulation Platforms and related distinctive features
Alfredo Garro - DIMES Department - University of Calabria (Italy)
The mentioned aspects should guide the choice of the target simulation platforms for the definition of PSSM-D
� Model transformation should allow to save effort in terms of time and cost for model development as well as to reduceerrors by possibly automating the building and updating of models where possible
� Model Transformation (MT) MT={m ∈M, n ∈N, ∃ T: M�N | n=T(m)}
Two main categories of Transformation techniques can be distinguished:
Model-to-Model (M2M)
Model-to-Code (M2C)
From Platform-Independent to Platform-Specific Simulation Models for Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 92
According to the proposed model-chain:
M2M techniques should map PISM-D into PSSM-D M2C should be used for generating the simulation
code starting from a PSSM-D Let us focus on the main approaches which allow moving
from PISM-D to PSSM-D :
Meta-Model based approaches ;
Annotation-based approaches ;
Structure-Driven approaches; Hybrid approaches.
From Platform-Independent to Platform-Specific Simulation Models for Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 93
Meta-Model based transformation approach
From Platform-Independent to Platform-Specific Simulation Models for Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 94
Annotations based transformation approach
From Platform-Independent to Platform-Specific Simulation Models for Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 95
� The described techniques for enabling M2M transformation are based on the definition of Transformation Rules that can be expressed by using specific Transformation Languages:
� QVT (Query/View/Transformation ) is a standard set of languages for model transformation defined by the Object Management Group (OMG);
� Atlas Transformation Language (ATL) is a transformation language for the definition of fully declarative, hybrid, or fully imperative rules.
From Platform-Independent to Platform-Specific Simulation Models for Dependability Analysis
Alfredo Garro - DIMES Department - University of Calabria (Italy) 96
Conclusions
� Analyze the dependability performances of a system on different simulation platforms starting from a common system representation could bring many advantages:� reusability of system models ;� combination and assessment of results gathered from the
simulation of the same system model on different platforms .
� Also some important cons could be identified:
� the introduction of additional abstraction levels in the model-driven process;
� the lack of (semi)automated mechanisms and rules for supporting the transformation from platform-independent to platform-specific simulation models;
� the difficulty to keep the platform-independent models consistent with the platform-specific ones.
Alfredo Garro - DIMES Department - University of Calabria (Italy) 97
Acknowledgments
� Andrea Tundis, Alberto Falcone (SMASH Lab, University ofCalabria)
� Johannes Groß (Caltech/NASA Jet Propulsion Laboratory)
� Marius Riestenpatt gen. Richter (Institute for Statics and Dynamics of Aerospace Structures University of Stuttgart)
� Peter Fritzson , Olena Rogovchenko (PELAB, Linköping University)
� Enrico Mancin (IBM Italia), Henry Broodney, Michael Masin (IBM Haifa Research Center)
� Gabriele Luceri, Nicola Chirillo (Z-Lab Engineering)
� Colleagues of the ITEA 2 MODRIO Project
� Colleagues of the Simulation Team
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 98
Thank you for your kind attention
Prof. Alfredo Garro - DIMES Department - University of Calabria (Italy) 99