Université Henri Poincaré

Introduction à l’ingénierie de la d d SEDcommande des SED

Jean François PETINJean-François PETIN

CRAN UMR 7039, Nancy-Université, CNRSESIAL Ecole Supérieure d’Informatique et Applications de LorraineESIAL, Ecole Supérieure d Informatique et Applications de Lorraine

SommaireSommaire

IntroductionIntroductionProblématiqueEtat de l’artEtat de l’artQuelques illustrations

mar

s 20

09Transformations de modèlesMéta-modélisationV é i ifié ?

–19

& 2

0 mVers une représentation unifiée ?

Conclusions

s JD

MA

CS

–

Eco

le d

esJF

Pét

in

Introduction (I)SYSTEME REACTIFSYSTEME REACTIF

Introduction (I)

Le terme "SYSTEME REACTIF" a été introduit par D. HAREL et A. PNUELI en 1985 pour caractériser des systèmes qui maintiennent une INTERACTION PERMANENTE avec leur environnement …

Les problèmes dus aux échanges de signaux sont plus importants que les problèmes liés aux calculs à faire.

mar

s 20

09INTERACTIONPERMANENTE

–19

& 2

0 m

SYSTEME ENVIRONNEMENT

t T

s JD

MA

CS

Contraintes Temporelles

–E

cole

des

… par opposition aux systèmes TRANSFORMATIONNELS qui se terminent avec la production d'un résultat à partir de données initiales.

JF P

étin

Introduction (II)

Les systèmes réactifs "temps réel" doivent respecter, outre de fortes contraintes

Introduction (II)

Contraintes de SÛRETE DE FONCTIONNEMENTContraintes de SÛRETE DE FONCTIONNEMENT

y p ptemporelles, d'autres contraintes qui peuvent être aussi, voire plus, importante :

Contraintes de SÛRETE DE FONCTIONNEMENTContraintes de SÛRETE DE FONCTIONNEMENTDans les pires conditions, les réactions du système doivent conserver leurs caractéristiques (permanence de l'action avec l'environnement : chaque action "non

mar

s 20

09maîtrisée" peut avoir des conséquences catastrophiques sur l'environnement)

Propriété d'invariance préservée dans un nombre fini d'états du système : "ce qui ne doit jamais arriver"

–19

& 2

0 mce qui ne doit jamais arriver

Propriété de vivacité (ou de fatalité) devant être atteinte dans un état futur dusystème:

"ce qui doit arriver un jour"

s JD

MA

CS

q j

Contraintes LOGIQUESContraintes LOGIQUESDéterminisme de comportement qui impose le respect de la SPECIFICATION

–E

cole

des

Déterminisme de comportement qui impose le respect de la SPECIFICATION des relations entre ENTREES et SORTIES :"Une même séquence d'entrées provoque toujours la même séquence de sortie"

JF P

étin

Introduction (III)Introduction (III)

Systèmes complexesy pPropriétés complexes qui résultent d’unréseau d’interactions entre composantsVérification de propriétés « système » vs« propriétés locales » ?

mar

s 20

09L’augmentation de la complexité a unimpact négatif sur la disponibilité ou plusgénéralement la sûreté de fonctionnement

–19

& 2

0 mgénéralement la sûreté de fonctionnement

des systèmesTypique au

réseau d ’i t ti

Typique au réseau

d ’i t tiPropriPropriééttééPropriPropriééttéé

s JD

MA

CS

d ’interactiond ’interactionpppp

<<de type>><<de type>><<de type>><<de type>><<de type>>

Propriété de conjonction

<<de type>>

Propriété de conjonction

<<de type>>

Propriété de conjonction

<<de type>>

Propriété propre

<<de type>>

Propriété propre

<<de type>>

Propriété propre

<<de type>>

–E

cole

des

Spécifique à chacun des éléments du

Spécifique à chacun des éléments du

Couplage des propriétés de Couplage des propriétés de

0..* 0..*

Propriété composite

0..* 0..*

Propriété composite

0..* 0..*

Propriété composite

0..* 0..*

Propriété composite

0..* 0..*

Propriété composite

0..*0..* 0..*0..*

Propriété composite

1..* 1..*

0..*

JF P

étin

des éléments du système

des éléments du système

p pdifférents typesp p

différents types0..*0..*0..*0..*0..*0..*0..*0..*0..*0..*0..*0..*0..*0..*

Problématique (I)Problématique (I)

Assurer le respect des exigences par la solution développée

S E ⇔ S x S E

p g p pp

S E ⇔ Sc x Sp E

mar

s 20

09Ensemble d’exigences, notées EContraintes fonctionnellesC t i t d f

–19

& 2

0 mContraintes de performances,

Propriétés de sécurité

s JD

MA

CS

Système, noté S, composé d’un ensemble de sous-système:de processus de commande, notés Sc

–E

cole

desde processus de transformations de matière et/ou d’énergie, notés Sp

E t S t é S t à défi i

JF P

étinE et Sp sont supposés connus, Sc est à définir

Problématique (II)Problématique (II)Les exigences E peuvent être exprimées selon plusieurs niveaux d’abstractionet décomposées en sous-exigencesS est composé d’un ensemble de processus en interactionsLes propriétés de S ne sont pas réductibles aux propriétés des composants duLes propriétés de S ne sont pas réductibles aux propriétés des composants dusystème mais résultent d’un réseau d’interactions entre ces composants

E {E1 E2 E }

mar

s 20

09

E = {E1, E2, …Em }S = {S1, S2, … Sn }

–19

& 2

0 m

Si {Ek}k∈[1, m]

{S } EPas de relation bijective entre l’ensemble des exigences et l’ bl d t

s JD

MA

CS

{Sk}k∈[1, n] Eil’ensemble des composants d’un système

–E

cole

des

JF P

étin

Problématique (III)Problématique (III)Processus de génération de la commande interprété comme un réseaude traitement de données hétérogènesde traitement de données hétérogènes

Basé sur des modèles de SEDBasé sur des modèles de SEDExprimés à différents niveaux d’abstraction

Modèles conceptuels4

b6

5a

7

8

3

X2.d /X2.d

/d

mar

s 20

09Modèles opérationnelsx2

a a

6 7

c

c28

c31

i_dpoe24

e27 epo

i_dpoe22

e23

Modèle Grafcet

–19

& 2

0 m

x1 x3

x4b

b

b

a

c36rq88e31 rq60e24

Modèle Automates à Etats Finis

Modèle LADDER

Modèle Réseaux de Petri

s JD

MA

CS

Exprimant des points de vue sur différents espaces techniquesComportement de la commande

Modèle Automates à Etats Finis

Produire un effortmécanique

Trans-stockereffort mécanique

Effort mécaniquex: profondeur de passe

y: vitesse avance, positiont( ) it d

–E

cole

des

pArchitecture de la commandeSurveillance / supervisionDiagnostic des SED Modèle

A1

mécanique

A4

Usiner Pièce surTour

A3

Trans-StockerPièce

A6

effort mécanique

Outils d'usinage

Motorisation outil Système d'évacuationmatièreet énergie

Mandrin

rot(y): vitesse de coupe

Flux

Résidus matière (copeaux)et énergie (echauffement)

JF P

étinDiagnostic des SED

….

Modèlefonctionnel

gMandrin

Architecture decomposants

Etat de l’art : aspects organisationnels (I)Etat de l art : aspects organisationnels (I)Approches par Cycle de Vie

Besoin Système opérationnel

pp p y

SpécificationRecette

Scénarios de tests

mar

s 20

09

ConceptionGénérale

Tests intégration

Scénarios de tests

modèleoutils

méthodeVue

Fonctionnelle

–19

& 2

0 m

ConceptionDétaillée

Tests intégration

modèleoutils

méthode

VueComportementale

s JD

MA

CS

Détaillée

Tests unitairesScénariosde tests

modèleoutilsVueOrganique

–E

cole

des

Codage

méthode

Système

Organique

Vue

JF P

étinmodèleoutils

méthode

VuePhysique

Etat de l’art : aspects organisationnels (II)Etat de l art : aspects organisationnels (II)Limites des approches par CdV

Juxtaposition de plusieurs cycles de vie, les activités de conception d’un composant appelant lesactivités de définition des exigences de ces sous constituants

Les activités de validation et de vérification commencent dès l’expression du besoin et ne sontLes activités de validation et de vérification commencent dès l expression du besoin et ne sontpas limitées à la branche gauche du cycle en V, considérée comme postérieure aux activités decodage et de réalisation

( )

mar

s 20

09

Démarche descendante (du besoin jusqu’à la réalisation) associée à une démarche ascendante(construction progressive d’une solution à partir de l’assemblage de composants existants COTSComponents On The Shelves).

–19

& 2

0 m

s JD

MA

CS

–

Eco

le d

esJF

Pét

in

Etat de l’art : aspects organisationnels (III)Etat de l art : aspects organisationnels (III)Approches par Processus

► Un processus est un ensemble d'activités corrélées ou interactives qui transforme des élémentsd'entrée en éléments de sortie. Ainsi, il répond à sa finalité (mission) dans un environnementdonné. Il est soumis à des contraintes et consomme des ressources.

pp p

► La vision processus remplace l’approche par cycle de vie

► Tout projet implique la réalisation de divers types d’activité :

mar

s 20

09

► Tout projet implique la réalisation de divers types d activité :• activités techniques d’analyse du problème, de conception de la solution, d’intégration, devérification et validation,• activités de management de ces activités techniques,

–19

& 2

0 m• activités liées aux relations contractuelles entre clients et fournisseurs.

IEEE 1220

s JD

MA

CS

P j tP j t AcquisitionAcquisition E t iE t i

ISO 15288EIA 632

–E

cole

des

conceptualisationconceptiondu réalisation

intégrationdu

transfertvers

Exploitation

i ti ditiretrait

d i

ProjetProjet qfourniture

qfourniture EntrepriseEntreprise

JF P

étin

psystème

réalisationdes constituants système l'exploitation maintien en condition

opérationnellede service

Etat de l’art : aspects organisationnels (IV)Systems Engineering – System Life-Cycle Processes,

Etat de l art : aspects organisationnels (IV)

Novembre 2003AFNOR Z 67-288 (Ingénierie systèmes – Processus de cycle de vie des systèmes)

mar

s 20

09–

19 &

20

ms

JD M

AC

S

–E

cole

des

JF P

étin

Etat de l’art : cohérence sémantique (I)Etat de l art : cohérence sémantique (I)Assurer la cohérence sémantique entre les modèles

B i

Exprimés à différents niveaux d’abstractionMécanismes de transformations de modèles

Spécification

ConceptionGénérale

Recette

Scénarios de tests

Scénarios de tests

BesoinSystème opérationnel

modèleoutils

méthode

Mécanismes de transformations de modèlesVerrous :

Mécanismes de raffinementEnrichissement/pertes sémantiques

ConceptionDétaillée

Tests unitaires

Tests intégration

Scénariosde tests

modèleoutils

méthode

modèleoutils

méthode

mar

s 20

09

Enrichissement/pertes sémantiques

Exprimant de multiples points de vue et/ou domaines techniques

Codage

modèleoutils

méthode

–19

& 2

0 mCohérence entre modèles et intégration multi-points de vue

Verrous : Langage de représentation unifié ou mécanismes de vérification de lacohérence ?

s JD

MA

CS

Model based System EngineeringSpécification

Recette

Scénarios de tests

BesoinSystème opérationnel

Spécification

Recette

Scénarios de tests

BesoinSystème opérationnel

Spécification

Recette

Scénarios de tests

BesoinSystème opérationnel

en ng en ng en ng–

Eco

le d

es

ConceptionGénérale

ConceptionDétaillée

Tests unitaires

Tests intégration

Scénarios de tests

Scénariosde tests

modèleoutils

méthode

modèleoutils

méthode

modèleoutils

méthode

ConceptionGénérale

ConceptionDétaillée

Tests unitaires

Tests intégration

Scénarios de tests

Scénariosde tests

modèleoutils

méthode

modèleoutils

méthode

modèleoutils

méthode

ConceptionGénérale

ConceptionDétaillée

Tests unitaires

Tests intégration

Scénarios de tests

Scénariosde tests

modèleoutils

méthode

modèleoutils

méthode

modèleoutils

méthodeodel

Driv

ngin

eerin

odel

Driv

ngin

eerin

odel

Driv

ngin

eerin

JF P

étinCodage

modèleoutils

méthode

Points de vues / Espaces techniques

Codage

modèleoutils

méthode

Codage

modèleoutils

méthode

Mo En Mo En Mo En

Etat de l’art : cohérence sémantique (II)Etat de l art : cohérence sémantique (II)Trois niveauxTrois niveaux

Modèle unifié pourModèle unifié pour

Modèle

Transformations simplesTransformations simplesModèle unifié pour Modèle unifié pour la représentation la représentation

de systèmes ?de systèmes ?x

Modèley

Modèlez Modèle x

mar

s 20

09

Modèlev

Modèleu Modèle unifié

???

–19

& 2

0 m

MétaMéta--modélisationmodélisation

s JD

MA

CS

Concepts communsModèle

–E

cole

desConcepts communs

(méta-modèle)Modèle

x

JF P

étinpréprocesseur

post-processeur

Quelques illustrationsQuelques illustrations

Transformations simplesTransformations simplesImplantation de modèles synchronesPassage d’un superviseur (SCT) à un contrôleur implantablePassage d un superviseur (SCT) à un contrôleur implantable

mar

s 20

09Méta-modèlisationApproches en R&D industriels

–19

& 2

0 mApproches en R&D industriels

Projets PRIAM en Actionnement et Mesure IntelligentsTraçabilité des exigences en sécurité machine

s JD

MA

CS

Modèle unifié : utopie ?

–E

cole

desApproches en Ingénierie des SystèmesExemples avec le langage B

JF P

étin

Implantation des modèles synchrones (I)Modèles basés sur une hypothèse synchrone

Implantation des modèles synchrones (I)

L'évolution interne de l'ensemble du système réactif est toujours contenuedans l'intervalle de temps qui sépare les occurrences distinctes d'événementse ternesexternes

Les sorties peuvent être considérées comme produites dans le mêmeINSTANT LOGIQUE que les événements d'entrée qui ont provoqué leur

mar

s 20

09

INSTANT LOGIQUE que les événements d entrée qui ont provoqué leurdéclenchement

E1 E2 E3 E4 E5

–19

& 2

0 m

Temps physique

t1 t2 t3 t4 t5

S1 S2 S3 S4 S5

s JD

MA

CS

S1 S2 S3 S4 S5

E1

–E

cole

desE1

t1 t1 + δ t

JF P

étin

S1

Implantation des modèles synchrones (II)

Synchronisme faible

Implantation des modèles synchrones (II)

Synchronisme faible

Le temps de réaction (calcul interne des sorties en fonction des entrées et d é i ) ê d AUSSI PETIT ' l dé i i NONdes états internes) peut être rendu AUSSI PETIT qu'on le désire mais NON NUL

0t →δFormalisme concerné : GRAFCET

mar

s 20

09

S h i f t

ik ttt −<<δFormalisme concerné : GRAFCET

–19

& 2

0 mSynchronisme fort

Le temps de réaction (calcul interne des sorties en fonction des entrées et des

s JD

MA

CS

p (états internes) est considéré comme NUL

Les sorties et les événements d'entrée qui les ont provoquées sont SIMULTANES

–E

cole

desSIMULTANES

0t =δ Formalismes concernés : L S h STATECHARTS

JF P

étinLangages Synchrones, STATECHARTS

Implantation des modèles synchrones (III)Implantation des modèles synchrones (III)

Rappels sur le modèle STATECHARTS

ORIGINE : Proposé en 1987 par D. HAREL comme une EXTENSION DES MACHINES A ETATS FINIS

pp

FORMALISME : Diagramme ETAT-TRANSITION (graphe orienté)

MACHINES A ETATS FINIS

mar

s 20

09

O S ag a e S O (g ap e o e té)

- nœuds : représentent les états du système

- liaisons orientées : représentent les transitions entre états.

–19

& 2

0 ma so s o e tées ep ése te t es t a s t o s e t e états

A chaque transition est associée une expression du type événement déclenchant / action

s JD

MA

CS

S E

F

–E

cole

desUG/A E/B

F

JF P

étinT G/A

Implantation des modèles synchrones (IV)Implantation des modèles synchrones (IV)

Rappels sur le modèle STATECHARTS

STATECHART = DIAGRAMME ETAT-TRANSITION + HIERARCHIE + ORTHOGONALITE + DIFFUSION

pp

Décomposition AND / OR des états avec des transitions inter-niveaux et un mécanisme de diffusion synchrone pour les communications entre les

mar

s 20

09composants parallèles

A

–19

& 2

0 m

AA

B

s JD

MA

CS

B

CC

–E

cole

desC

D D

JF P

étin

Un seul des sous-états B, C, Dest actif lorsque l'état A est actif

Tous les sous-états B, C, D sont actifs lorsque l'état A est actif

Implantation des modèles synchrones (V)[HAREL 1990] : Vision externe

Implantation des modèles synchrones (V)

Utilisé pour la sémantique de simulation de l'atelier STATEMATE (i-Logix) supportant le modèle STATECHART

STEP iE := Evénements d'entrée

C l l d é é t dé i é (t (E) f (E) )

mar

s 20

09

Calcul des événements dérivés (tr(E), fs(E), …)

Enabled (T) = Relevant (C) ∩ Triggered(E)Step (T) = Enabled (T) ∩ Consistent (T)

–19

& 2

0 mp ( ) ( ) ( )

E = Generated (Step (T) )C = nouvelle situation par franchissement des transitions Step(T)

Next STEP

s JD

MA

CS

Next STEP

Les réactions en chaîne provoquées par un vecteur d'entrée sont traités l'une après l'autre par chaque pas de l'algorithme. Les changements d'états des signaux d'entrée

–E

cole

des

Relevant (C) = transitions susceptibles d'être franchies lorsque le Statechart est dans l'état C

l autre par chaque pas de l algorithme. Les changements d états des signaux d entrée peuvent être pris en compte pendant le calcul de ces réactions en chaîne.

JF P

étinTriggered (E) = transitions déclenchées par les événements de l'ensemble E

Generated (T) = événements générés par le franchissement des transitions de l'ensemble TConsistent (T) = ensemble de transitions cohérentes ne pouvant provoquer un conflit (règles de priorité)

Implantation des modèles synchrones (VI)

HAREL [1987] : Micro-pas

Implantation des modèles synchrones (VI)

HAREL [1987] : Micro pas

Les micro-pas sont considérés comme prenant un temps nul vis à vis del'environnement mais sont ordonnés logiquement par une relation de CAUSALITEg q p(Proche des modèles interne/externe proposés pour le Grafcet - Voir § GRAFCET)

STEP k

mar

s 20

09E := Evénements d'entréeCalcul des événements dérivés (tr(E), fs(E), …)

REPEAT M-STEP

–19

& 2

0 m

Vi = Relevant (C) ∩ Triggered (E ∪ Generated(Ti-1))ti = [Vi - (Ti-1 ∩ Vi )] ∩ Consistent(Ti-1 ∪ Vi )

Ti = Ti-1 ∪ ti

s JD

MA

CS

UNTIL ti = ∅C = nouvelle situation par franchissement des transitions Step(T)

Next STEP

–E

cole

des

Relevant (C) = transitions susceptibles d'être franchies lorsque le Statechart est dans l'état CTriggered (E) = transitions déclenchées par les événements de l'ensemble E

Next STEP

JF P

étin

Triggered (E) = transitions déclenchées par les événements de l ensemble EGenerated (T) = événements générés par le franchissement des transitions de l'ensemble T

Consistent (T) = ensemble de transitions cohérentes ne pouvant provoquer un conflit (règles de priorité)

Implantation des modèles synchrones (VII)Implantation des modèles synchrones (VII)Rappels sur le modèle Grafcet

SYNTAXE 1 Etape (1) Transition

pp

10

p

Etape initiale Liaisons orientées

mar

s 20

09

+ Règle de syntaxe : alternance étape / transition

–19

& 2

0 m

31

s JD

MA

CS

4 58

X2.d /X2.da

2

X3 b

–E

cole

des

b

6

a

7

/dX3.b

JF P

étin

c

Implantation des modèles synchrones (VIII)FORME ALGEBRIQUE DU MODELE GRAFCETFORME ALGEBRIQUE DU MODELE GRAFCET

Implantation des modèles synchrones (VIII)

)E,X(gY

)E,X(fX

ttt

tt1t

=

=+

Calcul deF(Xt , Et)

MémoireXt

Calcul deG(Xt , Et)

E Y

mar

s 20

09

El b ti D t t

–19

& 2

0 mElaboration Dates t

Forme Générale de F :

s JD

MA

CS

)CFX(CFX avktktamkt1kt ∑¬∧∑ ∨=+

Forme Générale de F :

avec

–E

cole

desavec

Xkt : état étape k (à la date t)CFamkt : condition de franchissement d'une transition amont à l'étape kCfavkt : condition de franchissement d'une transition avale à l'étape k

JF P

étinen sachant que

avec Rit : réceptivité associée à la transition i (à la date t)

∏∧= amititit XRCF

Implantation des modèles synchrones (IX)INTERPRETATIONS SYNCHRONE / ASYNCHRONEINTERPRETATIONS SYNCHRONE / ASYNCHRONE

AU PASSAGE A LA REALISATIONAU PASSAGE A LA REALISATION

Implantation des modèles synchrones (IX)

AU PASSAGE A LA REALISATIONAU PASSAGE A LA REALISATION

1

bp

2C

10

11Cbp. X2

mar

s 20

09

2

b

CYCL

11

c

CYCL

–19

& 2

0 m

10

bp . X2

E1

bp

E

s JD

MA

CS

p11

c

p2

b

–E

cole

des

Selon l’ordre utilisé, le résultat n’est pas le même !!!

JF P

étinComment respecter une évolution synchrone

dans un environnement à évolution asynchrone ?

Implantation des modèles synchrones (X)PBS

Implantation des modèles synchrones (X)

Passage d’une spécification Grafcet à sa réalisation

Algorithmes d’InterprétationAlgorithmes d’Interprétation

mar

s 20

09

Déterminisme

–19

& 2

0 m

Synchronisme externeRéactivité

Hypothèses temporellesrelatives

Synchronisme d’évolution (interne)

Organisation des calculs :séparation entre calculs des

s JD

MA

CS

relativesséparation entre calculs desévolutions et évolution

–E

cole

des

Sans Recherche de StabilitéA R h h d St bilité

JF P

étinAvec Recherche de Stabilité

Superviseur vs contrôleur (I)Superviseur vs contrôleur (I)

Rappels sur la synthèse de la commandeContexte

Générateur G = (X, E, f, x0, Xm).

pp y

( , , , , )Superviseur S : fonction de L(G) → 2E qui pourchaque séquence s ∈ L(G), retourne l’ensemble desséquences autorisées par la spécification.

SuperviseurS

sS(s)

mar

s 20

09

q p pComportement en boucle fermée, noté S/G: Procédé

Ge ∈ L(S/G)[(s ∈ L(S/G)) and (sσ ∈ L(G)) and (s ∈ S(s))] ⇔ [sσ ∈ L(S/G)]

–19

& 2

0 m[(s ∈ L(S/G)) and (sσ ∈ L(G)) and (s ∈ S(s))] ⇔ [sσ ∈ L(S/G)]

Algorithmes de synthèse [Ramadge & Wonham][Kumar]Composition synchrone des spécifications et du procédé G

s JD

MA

CS

Limites

Recherche et élimination des états défendus

–E

cole

desLimites

Explosion combinatoire: approches modulaires [Wong, Wonham, Chafik, Lafortune, …]Déterminisme des superviseurs / contrôleur réactif [Fabian, Balemi]

/ f ’

JF P

étinAutorisation / forçage d’événements

Interprétation des événements incontrôlables/contrôlables en termes d’entrées/sorties

Modélisation: formalismes peu structurants

Superviseur vs contrôleur (II)Superviseur vs contrôleur (II)

Superviseur autorise/interdit événements (nonSuperviseur autorise/interdit événements (nondéterministe)Contrôleur force des sorties en fonctions des états etContrôleur force des sorties en fonctions des états etdes entrées du système

mar

s 20

09

Evénements / Signaux logiques

–19

& 2

0 mInterprétation de Balemi des événements

incontrôlables/contrôlables en terme d’entrées/sorties

s JD

MA

CS

Jean-Marc Roussel & Alessandro Guia – WODES 08

–E

cole

des

JF P

étin

Superviseur vs contrôleur : exemple (III)Superviseur vs contrôleur : exemple (III)Implantation par activation/désactivation synchrone

Niveau n+1 t b titi

(Gouyon, 2004)

Priorités

Superviseur niveau n

demandecompte-rendu

action action

Niveau n+12demande

observation

report3

demande demande1

observationaction

niveau n

action4

observationcompte-rendu6

action action

observationNiveau n-1

: transition prioritaire : transition non prioritaire

compte-rendu5

observation

mar

s 20

09

Traduction observation, demande : événements incontrôlables action, compte-rendu : événements contrôlables

: transition prioritaire : transition non prioritaire

Evaluation des transitions Tr1dre0

–19

& 2

0 mfranchissables

(Prise en compte des règles de priorités)

Tr2

Tr3

e0

ore1 cs

e1

Calcul de la ll

Init

cs

e0

e2 e1 e3cs

dr

orTr3Tr2

Tr1

Tr4 Tr5

Inite0

e2 e1 e3cs

dr

orTr3Tr2

Tr1

Tr4 Tr5

Init0 T 1

s JD

MA

CS

e1

nouvelle situation

Tr1

e1 Tr2 Tr3

e2Tr2

e0e0 e0 Tr1

–E

cole

des

e2 Tr4

e3Tr3

e3 Tr5

dr : événement incontrôlablecs : événement incontrôlable prioritaireor : événement (interne) contrôlable non prioritaireout_or: sortie associé à l’événement interne orEi : Etats (variable interne)T i C diti d’ ti ti ( i bl i t )

JF P

étinor

out_or

e1

e2

Génération des événements internes et des sorties

Tri: Conditions d’activations (variables internes)

Approches par méta-modélisation (I)Approches par méta modélisation (I)

Modélisation des concepts utilisés : éléments d ’un formalisme,p ,objets « métier »Exemple avec le GrafcetMéta-modèle

ETR11

ET1

1

mar

s 20

09

NF C 03-190

ETAPE0,N

0,N R12

TR1

1

(1)

–19

& 2

0 m

UTE C 03-191 Précèdesuccède

succèdeprécède

R11 R12R11

TR

ET2

2

s JD

MA

CS

IEC 848

p

0,N

0,N TR

2R12 (2)

–E

cole

des

Langage

TRTRANSITION

N N

ET3 3

JF P

étin

g gModèle Méta-modèle Instance modèle

Approches par méta-modélisation (II)Approches par méta modélisation (II)

Méta méta modèleMéta-méta-modèle

MC13èle

es es)

Lhoste, 1994 (HDR)

Mm2 MC23Mm1 MC12 Mm3

MC13m

éta-

mod

è(m

odèl

e d

form

alis

me

mar

s 20

09

M1 M2 M3alis

mes

m ( f

–19

& 2

0 mM1 M2 M3

esfo

rm

s JD

MA

CS

m1 m2 m3

mod

èle

Utilisation du formalisme Mi pour créer mi

–E

cole

des

Ab t ti d ét dèl t d dèl d

Utilisation du formalisme Mi pour créer mi

Règles de passage (connexion) entre deux formalismes

Modélisation des définitions du formalisme Mi,création des méta-modèles Mmi

JF P

étinAbstraction des méta-modèles et des modèles de

connexions pour créer le méta-méta-modèleModélisation des connexions

Approches par méta-modélisation (III)Approches par méta modélisation (III)Projet européen ESPRIT III 6188 – PRIAM

Distribution des fonctions d’Actionnement et de MesureIntégration des fonctions Contrôle, Maintenance et Gestion TechniqueInteropérabilité des équipements « intelligents » StandardisationInteropérabilité des équipements « intelligents » StandardisationMéta-modèle des concepts et objets en IAM (formalisme NIAM)

Class(cl name)

P1: Object belongs to the same class

hasofMeaningthan the function which has produced it

mar

s 20

09

( _ )

of

belongs

P1

Function(fc_name)

describedbyofAlgorithm

to

of

belongsto

–19

& 2

0 m

Type(typ_name)

Component(cp_name)

VectorArrayofcontains(array_name) (vct_name)

Fonction(nom_fc)

producedbyproduces

consumedbyconsume

Objet(nom_ob)

Informational

(nom_fd)

associatedto usesFlow

T

a) function

s JD

MA

CS

Domainde Validity

T

caractérisépar(dom_name)

privateobject of

has privateobject

uses

used

uses

used

Uindex

–E

cole

desObject

(ob_name)

Observation

belongsto

of decaractérisé Meaningpar

Report

T

usedby

usedby

Objectin flow

composedof composes

JF P

étinAction

ObjectFCS

Request associatedto

accessedAccess

(md_name)mode

by

b) object c) informational flow

Approches par méta-modélisation (IV)Approches par méta modélisation (IV)Projet européen ESPRIT III 6188 – PRIAM

Développement d’un outil d’ingénierie basé sur le méta-modèle pourExtraction & standardisation des exigencesDescription comportementale des équipements et des architecturesDescription comportementale des équipements et des architectures

Documentation

Expression des besoins

Description comportementale etsimulation sur l’outil SPEX

Documentation

Expression des besoins

Description comportementale etsimulation sur l’outil SPEX

Expression des besoins

Description et simulation comportementale (Spex / TNI)

OUTIL PRIAM

mar

s 20

09

Documentation

State

Modes

Rq1 1 MRQDDIS1Rp1 2 MRPDDIS1

Rp2 3 MRPSDIS1

Documentation

State

Modes

Rq1 1 MRQDDIS1Rp1 2 MRPDDIS1

Rp2 3 MRPSDIS1

–19

& 2

0 m

Rp1

Modes…

Identification des fonctionsEquipement E1

Allocation et définition des interfaces

Rp1

Modes…

Identification des fonctionsEquipement E1

Allocation et définition des interfacesIdentification des fonctions

Allocation etdéfinition des interfaces

s JD

MA

CS

FonctionF1

Rq1p

Rp2

F tiRq2 Rp3

F1F2

Rq1

Rq2

Rp1

Rp3Rp4

Rp2Fonction

F1Rq1

p

Rp2

F tiRq2 Rp3

F1F2

Rq1

Rq2

Rp1

Rp3Rp4

Rp2

–E

cole

desFonction

F2Rp4

FonctionRq3

Rp5

Rp2 Equipement E2

F3Rq3 Rp5

FonctionF2

Rp4

FonctionRq3

Rp5

Rp2 Equipement E2

F3Rq3 Rp5

JF P

étin

FonctionF3

Rp5

Rp4

F3Rp4

pFonctionF3

Rp5

Rp4

F3Rp4

p

Approches par méta-modélisation (V)Approches par méta modélisation (V)Diagramme des exigences SysML (Référentiels normatifs du domaine)Raffinement des exigences (décomposition dépendance)Raffinement des exigences (décomposition, dépendance)Allocation sur une architecture de fonctions / composants

MODEL CHECKING: MODEL CHECKING: RéutilisationRéutilisation des des propriétéspropriétés relatives à relatives à chaquechaquecomposantcomposant soussous formeforme de de prédicatsprédicats

mar

s 20

09–

19 &

20

m

ExigencesExigences de de sécuritésécurité

s JD

MA

CS

–

Eco

le d

es

RaffinementRaffinement en en soussous‐‐exigencesexigences

SIMULATIONSIMULATION Ré tili tiRé tili ti dd iétéiété l ti àl ti à hh

JF P

étinSIMULATION: SIMULATION: RéutilisationRéutilisation des des propriétéspropriétés relatives à relatives à chaquechaque

composantcomposant soussous formeforme de postde post--conditionsconditions

Vers un langage unifié ? (I)Vers un langage unifié ? (I)Langage de modélisation « système » ?

• Décrire ce que le système doit faireet partager une compréhension commune et cohérente des services attendus d'un système

mar

s 20

09• Maitriser la complexité des architectures des systèmes (propriétés

t t l t t t ll

–19

& 2

0 mcomportementales et structurelles

(relatives aux architectures, aux composants et leurs interfaces).

s JD

MA

CS

• Retarder l’utilisation de langages ou modèles orientés métier qui sont nécessaires pour supporter toute

–E

cole

desnécessaires pour supporter toute

activité de conception

JF P

étin

Vers un langage unifié ? (II)Vers un langage unifié ? (II)

mar

s 20

09–

19 &

20

ms

JD M

AC

S

SYSML, Langage B ??

–E

cole

des

, g g

JF P

étin

Vers un langage unifié ? (III)Vers un langage unifié ? (III)

SysML: System Modelling Languagey y g g gSysML customizes the UML™, the industry standard for modeling software-intensivesystems, for systems engineering applications. It supports the specification, analysis,design verification and validation of a broad range of systems and systems ofdesign, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes,personnel, and facilities.

mar

s 20

09

Profil UML2.0

–19

& 2

0 m

s JD

MA

CS

–

Eco

le d

esJF

Pét

in

Vers un langage unifié ? (IV)Vers un langage unifié ? (IV)Diagramme « Requirements » de SysML

• Structuration des exigences

CompositionComposition

« derive »Dérivation

Composition

« derive »Dérivation

Composition

mar

s 20

09« satisfy »Satisfy « satisfy »Satisfy

A DeriveReqt relationship is a dependency between two requirements in which a

–19

& 2

0 m

« verify »Verify « verify »Verify client requirement can be derived from the supplier requirement. For example, asystem requirement may be derived from a business need, or lower-levelrequirements may be derived from a system requirement. As with other dependencies,the arrow direction points from the derived (client) requirement to the (supplier)requirement from which it is derived

s JD

MA

CS

« Requirement »Requirement Name

« Requirement »

requirement from which it is derived.

–E

cole

des

qId =Source = Text =Kind =

JF P

étinVerify Method =

Vers un langage unifié ? (V)Vers un langage unifié ? (V)

Liens entre e s e emodèles et points de vue différents

mar

s 20

09–

19 &

20

ms

JD M

AC

S

… mais attentionPas (ou peu) de sémantique formelle offrant notamment des

–E

cole

desPas (ou peu) de sémantique formelle offrant notamment des possibilités de vérificationBoite à outils sans garde fous sur le plan méthodologique

JF P

étin

Boite à outils sans garde fous sur le plan méthodologique

Vers un langage unifié ? (VI)Vers un langage unifié ? (VI)

Langage B MACHINE nomLangage BThéorie des ensemblesLogique des prédicats 1er ordre

MACHINE nomSETS sCONSTANTS cPROPERTIES p

Machine abstraite

Opérations

PROPERTIES pVARIABLES xINVARIANT I(x)INITIALISATION init(x)

mar

s 20

09

pSubstitutionGarde +/- déterministe

ANY ’ WHERE ( ’) THEN ’

( )OPERATIONSO1= select P1(x) then S1(x)…

–19

& 2

0 mANY x’ WHERE p(x’) THEN x :=x’

InvariantsOn = select Pn(x) then Sn(x)END

s JD

MA

CS

Propriétés préservées lors de l’initialisation et après exécution d’une opération(INV1) Init(x) fi I(x)

(INV2) I(x) ¶ P(x) fi I( S(x))

–E

cole

des(INV2) I(x) ¶ P(x) fi I( S(x))

RaffinementEnrichissement progressif des modèles préservant les propriétés invariantes des

JF P

étin

Enrichissement progressif des modèles préservant les propriétés invariantes desmachines raffinées

I(x) ¶ J(x,y) ¶ Qi(y) fi Pi(x) ¶ J(Si(x), Ti(y))

Vers un langage unifié ? (VII)Vers un langage unifié ? (VII)Spécification documents Interviews, contacts, memos

STE STE STE

mar

s 20

09

System levelB formal

–19

& 2

0 m

specification

s JD

MA

CS

Hardwarespecification

Softwarespecification

–E

cole

des

specification

Hardware

specification

Software

Dedicated models

JF P

étinHardware

implementationSoftware

implementation

Vers un langage unifié ? (VIII)Vers un langage unifié ? (VIII)

Cadre méthodologique pour structurer le processus deCadre méthodologique pour structurer le processus demodélisation en B

Control

(Pétin et al, EJC 2007)

SystemRequirements

Composition(automated

System)

BRefinement

Controlsystems

B Machines

BI l i

mécanismes de composition B : invocation etinstanciation de machines dans le cadre d’uneapproche modulaire

mar

s 20

09

Requirements

B Machine

y )

B Machine

∧Processsystems

B Machines

Inclusion⊃mécanisme de raffinement : préservation despropriétés préalablement prouvées.

–19

& 2

0 m

Joueur B permettant de prendre en compte, dans le processusd é ifi ti l i t ti d t ti / é ti

s JD

MA

CS

de vérification, les interactions de type action/réactioncaractérisant les relations entre un système automatisé et sonenvironnement.

–E

cole

des

environnement.OPERATION ij =

SELECT Drapeau = DijTHEN IF Gij THEN Sij || Drapeau := D(i+1)1

JF P

étin

THEN IF Gij THEN Sij || Drapeau : D(i+1)1ELSE Drapeau := Fi(j+1)

End;Où Gij et Fij représentent respectivement la garde et la substitution de l’opération ij

Vers un langage unifié ? (IX)Vers un langage unifié ? (IX)Problème

Domain engineering : D S EDomain engineering : D, S ERègles sémantiques de construction des modèlesDémontrer la correction des modèles vis-à-vis des connaissances du domaine

Formalisation de constructs en B

mar

s 20

09

1Model constructs

properties

instantiation

Knowledge formalisationKnowledge formalisationMetamodelsand

Constructs

Constantes et propriétésinvariantes du domaine

–19

& 2

0 m

2

derivation generalisation

ControlSpecificationCorrectness

checkingControl

specification

Comportementsgénériques

s JD

MA

CS

System modelsCS ∧PS ⇒ Goals

Models properties

ProcessSpecification

ConsistencyChecking

Specificationof expected

servicesProcess

Specification

Composition

Correctnesschecking

Correctness

Règles d’assemblage desconstructs

–E

cole

des

Real systemSystem

properties

abstractionconcretisation

CS ∧ PS • Correction locale de chaque spécification• Cohérence globale de l’ensemble des spécifications

checking

JF P

étin

Cohérence globale de l ensemble des spécifications

Constructs : "a textual or graphical artefact devised to represent in an orderly way the diverse information on common properties and elements of a collection of phenomena" [ISO 19440].

ConclusionsConclusions

Modèles de SED / Ingénierie de SED

Passer d’une vision contemplative des modèles à une

mar

s 20

09ingénierie dirigée par les modèlesCohérence sémantique entre modèles de SED exprimés à

–19

& 2

0 mdifférents niveaux d’abstraction

Transformations de modèles

s JD

MA

CS

Vers une ingénierie « système » formelle ?

–E

cole

des

JF P

étin