system dependability analysis: main issues and · pdf filesystem dependability analysis: main...

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


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


System Dependability and RAMS Analysis


� 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


SAFETY:

From Safety Requirements to Simulation-driven Design of Safe

Systems

A Model-based approach for Safety Analysis of Systems


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.


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


Main Concepts of the proposed meta-model for modeling System Requirements as RequirementAssertions


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


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


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


� 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


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.



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.

� …



…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


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


… 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


… 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


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


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


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


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


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


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


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;


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.


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


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.


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.


Fault Tree Analysis of a Tank System

System Design (SD) �� integration of Physical Component Models (PCMs)



A RequirementsModel (RM) for the Tank System



Extended System Design (ESD) = System Design (SD) + RequirementsModel (RM) by using the Modelica extensions:- fulfill equation- requirement class


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.


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.


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


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


� 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)





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


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).


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.


The On-Board Communication System (OBCS) of a Metro Train


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


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.


RAMSAS: The System Modeling phase �System Structure Modeling

� In this phase the System is decomposed in component entities by applying in-out zooming mechanisms .


Behavior Modeling

Structure Modeling

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


� Intended behavior of a Control Unit

RAMSAS: The System Modeling phase �Intended Behavior Modeling


� Intended Behavior of a Control Unit when a Passenger Call occurs




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


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)


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 .



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



� FaultManagement task of a Control Unit subsystem



� 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


� BehaviorIntegration of the Control Unit subsystem behavior



� Failure situation of a PassengerCall



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


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


RAMSAS: The System Simulation phase �Parameter Setting


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



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




� 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



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.



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);


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.


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 .


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 .


Model-Based Dependability Analysis

A model-chain for enabling Platform-Independent Dependability Analysis


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


� 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.




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 .




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.




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)� …


Languages for the definition of PISM-D


UML/SysML (Extensible Markup Language/Systems Model ing Languages):




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.




…� EXPRESS a standard modeling language for define data objects and

relationships among them for a specific domain of interest.



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


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.



Meta-Model based transformation approach



Annotations based transformation approach



� 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.



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.


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


Thank you for your kind attention


[email protected]

system dependability analysis: main issues and · pdf filesystem dependability analysis: main...

Documents