integrated SE-dependability meta-model

Towards anintegrated SE-dependability meta-model

S. DENIAUD É. BONJOUR J.-P. MICAËLLI D. LOISE

M3M-INCIS FEMTO-AS2M ITUS – EVS PSA

UTBM UFC Univ. Lyon, INSA Lyon

Aalto U. – 2010 CRECOS seminar, Espoo, 19.11.10

Towards an integrated SE-dependability metamodel

Agenda

Context and motivation

Systems Engineering (SE) meta-model

Dependability meta-model

Integrated SE-dependability meta-model

Conclusion

11.11.10


Context and motivation

Context• Functional design of powertrain at PSA Peugeot-Citroën

• Hybrid powertrain

• Application of Systems Engineering processes

• Functional safety concept

Motivation• Better integrate the dependability analyses into the functional architecture

design

• Road vehicles – Functional safety standard (ISO 26262)

• Define the necessary set of key concepts related to SE and dependability

• BB / WB approach

11.11.10


SE meta-model

Source: Wikipedia about systems engineering


Description of mission profiles and operating modes• A system provides different services in different operational situations

• A mission profile is usually modelled by means of a sequence of operating modes that correspond to stationary states of the system-of-interest

• Within a specific operating mode, different (functions of) services are being activated in order to carry out the mission. Transitions from one mode to another are triggered by control flows

11.11.10

Operational situation

activates, controls,triggers

Mission

Operatingmode

Sollicitation

Control flow

Environment

System

Service

MEI flow

transforms

is activated in

del

iver

s ser

vice

ssa

tisfie

s

triggersactivates

del

iver

ed b

y

realizes

Interface

has

is quantified by

Constraint

Performance

constrains

generates

Requirement

has

receivesdelivers

is expressed as

External scenario

is a sequence of

operates in

is quanti-fied by

is expressed as

takes place in

generates


Description of external scenarios• External scenarios (or use scenarios, exchange scenarios) represent the answers that the system (black

box) provides to sollicitations that are generated by (the entities of) the environment

• These scenarios trigger control flows of the operation of the system

• External scenarios are usually modelled in the form of a sequence of flows between the system and its environment according to the operational conditions

• External scenarios describe the nominal operation and the degraded operation, within the phases of system lifecycle: startup, use, maintenance, etc.

11.11.10



Mission

Operatingmode

Sollicitation

Control flow

Environment

System

Service

MEI flow

transforms

is activated in

del

iver

s ser

vice

ssa

tisfie

s

triggersactivates

del

iver

ed b

y

realizes

Interface

has

is quantified by

Constraint

Performance

constrains

generates

Requirement

has

receivesdelivers

is expressed as

External scenario

is a sequence of

operates in

is quanti-fied by

is expressed as

takes place in

generates


External functional analysis• Services correspond to transformations of MEI flows (Material, Energy, Information). They are activated,

controlled or triggered by control flows. They have interfaces with the environment which will be characterized by requirements of functional interfaces.

• A system is scoped by defining its boundary and its interfaces; this means choosing which entities are inside the system and which are outside - part of the environment.

11.11.10



Mission

Operatingmode

Sollicitation

Control flow

Environment

System

Service

MEI flow

transforms

is activated in

del

iver

s ser

vice

ssa

tisfie

s

triggersactivates

del

iver

ed b

y

realizes

Interface

has

is quantified by

Constraint

Performance

constrains

generates

Requirement

has

receivesdelivers

is expressed as

External scenario

is a sequence of

operates in

is quanti-fied by

is expressed as

takes place in

generates


Definition of system requirements (or technical requirments)

• The initial specifications of the system gradually are supplemented and/or translated into technical requirements. The analysis of the expected services provides functional requirements

• The study of both the missions and the sollicitations also provides functional requirements (including interfaces) and nonfunctional requirements (e.g operational requirements, of physical interfaces, constraints)

• In each operating mode, services are characterized by performance requirements



Mission

Operatingmode

Sollicitation

Control flow

Environment

System

Service

MEI flow

transforms

is activated in

del

iver

s ser

vice

ssa

tisfie

s

triggersactivates

del

iver

ed b

y

realizes

Interface

has

is quantified by

Constraint

Performance

constrains

generates

Requirement

has

receivesdelivers

is expressed as

External scenario

is a sequence of

operates in

is quanti-fied by

is expressed as

takes place in

generates

11.11.10


11.11.10

Internal functional analysis• The internal functional analysis breaks up each service

(or function of service) into a tree structure of internal functions and control functions

is allocated to

Operatingmode

Service

Operating mode /s-system

Function

is gr

oup

ed in

Interfacehas

activates, controls, triggersControl flow

transformsMEI flow

is activated in an

is decomposed in

Requirementis allocated to

refin

e has

Internal function

Control function

is a

Internalscenario

External scenario

refin

etriggers

operates in

is a

describes the behaviour

activates receives, delivers


11.11.10

Functional architecture• Functional architecture represents the logical and temporal sequence of the internal functions that are

activated/triggered/controlled by control flows. These control flows are either external (flows exchanged with external entities by considering that the system is encompassed in a larger system) or internal (flows within the system)

• Each internal function transforms MEI flows and has interfaces, either with other internal functions, or with the environment

• The analysis of the interfaces of the internal functions results in gathering them in subsystems. The interfaces of the subsystems are then identified

is allocated to

Operatingmode

Service


Function

is gr

oup

ed in

Interfacehas


transformsMEI flow

is activated in an

is decomposed in


refin

e has

Internal function

Control function

is a

Internalscenario

External scenario

refin

etriggers

operates in

is a




11.11.10

Internal scenarios• Internal scenarios refine external scenarios while revealing the answers which the subsystems provide

to the sollicitations generated by (the entities of) the environment and the other subsystems. These sollicitations trigger control flows of the operation of the subsystems

• Internal scenarios are modelled in the form of a sequence of flow (MEI, control) between the subsystems and with the environment according to the operational conditions

• Each subsystem presents various operating modes which come at the same time from a refinement of the operating modes of the system and from an enrichment that comes from the investigation of functional architectures

• An ideal functional architecture then is obtained

is allocated to

Operatingmode

Service


Function

is gr

oup

ed in

Interfacehas


transformsMEI flow

is activated in an

is decomposed in


refin

e has

Internal function

Control function

is a

Internalscenario

External scenario

refin

etriggers

operates in

is a



Towards an integrated SE-dependability metamodelDesign architecture• The granularity of the internal functions should make it possible to allocate them with one and only one

component

• The whole of the internal functions is analyzed and organized to highlight the operation of various components (physical resources). The physical choices may result either in defining new functions -induced - or in breaking up some functions

• Functional architecture is then refined and enables to design an allocated functional architecture. Each subsystem is then regarded as a dynamic fitting of internal functions and components, and is seen in its turn like a black box

• All the design results obtained are used as a basis for the drafting of the specifications of each subsystem

Component Port Linkhas connects

is a

lloca

ted

to

is materialized by

is allocated to

Operatingmode

Service


Function

is gr

oup

ed in

Interfacehas


transformsMEI flow

is activated in an

is decomposed in


refin

e has

Internal function

Control function

is a

Internalscenario

External scenario

refin

etriggers

operates in

is a



11.11.10


Component Port Linkhas connects

is a

lloca

ted

to

is materialized by

is allocated to



Mission

Operatingmode

Sollicitation

Control flow

Environment

System

Service

MEI flow

transforms

is activated in

del

iver

s ser

vice

ssa

tisfie

s

triggersactivates

del

iver

ed b

y

realizes

Interface

has

is quantified by

Constraint

Performance

constrains

generates


Function

is gr

oup

ed in

Interfacehas


transformsMEI flow

is activated in an

is decomposed inRequirementis allocated to

refin

e

has

receivesdelivers

is expressed as

has

Internal function

Control function

is a

Internalscenario

External scenario

is a sequence of

refin

e

triggers

operates in

operates in

is a


activates

is quanti-fied by

receives, delivers

is expressed as

takes place in

generates

11.11.10


Dependability meta-model

based on ISO 26262


Dependability concepts

11.11.10

Dependability

ReliabilityMaintainabilityAvailabilitySafety

Diagnosticability Reparability…

Durability …

Systems Engineering

Functional architecture Design architecture

Safety Availability

DiagnosticabilityReparability…

requirements

functional safety concept


ISO 26262-2 process: safety lifecycle

11.11.10

• Quantitative demonstration

of the safety goals

• Traceability of the safety requirements

• Safety requirements V&V

by modeling and testing

[ISO 26262-2]


Failure propagation Recursivity

11.11.10

F1 F2SS2

SS4SS3

Sub-System 1 (SS1) System (S)

oil leakage

in the turbooverload

oil seal

failure

fault(latent error)

in F1

(effective)errorin F1

F1 failureinterface error

between F1 in F2 error in SS1

(latent then effective)

SS1 failureinterface error

between SS1 and SS2 error in SS2

S failure


Conclusion


Conclusion

Systems Engineering

Dependability Object-based Modeling

ProductProcess

Non-functionalapproach

Ontology

Model-based Dependability

SE

(a) SysMLIntegrated SE-Dependability (b)

(c)SysML-based dependability

11.11.10

Date post:	05-Mar-2016
Category:	Documents
Upload:	pedro-parraguez
View:	215 times
Download:	0 times

integrated SE-dependability meta-model

Documents