Réseaux de Petri - Université de Montpellier

Transcription

Université Montpellier II
Module 2 : Modèles de Coordination
Application des réseaux de Petri
à la structuration
d ’applications logicielles
[email protected]
1
[email protected]
2
Motivations
modélisation
Système
Modèle
Réseaux de Petri
modification
révision
et/ou
analyse
incorrect
Propriétés
du modèle
implémentation
Application
logicielle
correct
[email protected]
3
Repères
Réseau de Petri
programmation du modèle
animation du modèle
joueur de réseau de Petri
synchrone, monotâche
asynchrone, multitâches
décomposition
en MEF
structure
application
logicielle
[email protected]
4
Analyse d ’un réseau de Petri
pour la caractérisation des propriétés de l'application
Analyse du réseau de Petri
Propriétés
caractéristiques importantes du système
structure et comportement dynamique
modification et/ou l'amélioration
Évaluation
étude des performances temporelles (RdP T/P-temporisés, temporels)
étude des protocoles , des files, etc. (RdP stochastiques)
etc.
… avant la mise en œuvre !
[email protected]
5
Propriétés
Ré-initialisable
Bornage (état)
(évolution)
graphe fini
cycle
cycle
évaluation
Borné & ré-initialisable
[email protected]
Place puits
Non borné & Non ré-initialisable
6
Propriétés
Vivacité (évolution) ensemble du graphe tjs évolutif
Blocage
total
partiel
non-vivant
(évolution)
existence chemin totalement bloquant
existence branche morte
transition quasi-vivante
initialisation
initialisation
initialisation
Place source
quasi-vivante
cycle
cycle
cycle
quasi-vivantes
vivantes
inférence
non-vivante
BLOCAGE TOTAL
(« blocage mortel »)
[email protected]
BLOCAGE PARTIEL
(« branche morte »)
7
Propriétés
Composante conservative
structure
Invariant de marquage (places)
+ marquage initial
≡
contrainte
sur les états et les activités du système
toujours vérifiée ∀t
p1
M(p1) + M(p2) = Mo(p1) + Mo(p2) = 1 + 0 = 1
M(p1) + M(p2) =1
∀t
p2
i.e. soit p1 actif soit p2 actif, mais jamais p1 et p2 en même temps
[email protected]
8
Propriétés
Composante répétitive stationnaire
structure
Invariant de transition
+ marquage initial
≡
séquence cyclique d'événements
qui peut être répétée indéfiniment
t1
S = {t1, t2}
t2
[email protected]
9
Ordre(s) de fabrication de pièce
de type I
de type II
Exemple d’étude
Of_p2
Of_p1
M2
libre
M1
libre
TR2
TR1
pièce
sur M1
US1
M1
Robot
libre
pièce
sur M2
US2
stock
TR1
TR2
transport de pièce
du robot vers Mi
US1
US2
usinages
Robot
M2
nb_pI
nb_pII
Quantité de pièces produites
de type I
de type II
[email protected]
10
Résultats d'analyse : Modèle sans ordre de fabrication ni comptage des pièces produites
P-invariants:
1 0 0
(M1_libre)
0 1 0
(robot_libre)
0 0 1
(M2_libre)
1 1 0
(TR1)
0 1 1
(TR2)
1 0 0
(piece_M1)
0 0 1
(piece_M2)
1 0 0
(US1)
0 0 1
(US2)
T
1
0
1
0
1
0
1
0
invariants:
0
(t1)
1
(t2)
0
(t3)
1
(t4)
0
(t5)
1
(t6)
0
(t7)
1
(t8)
ie.
ie.
M(M1_libre)+M(TR1)+M(piece_M1)+M(US1)
M(robot_libre)+M(TR1)+M(TR2)
= 1
= 1
= 1
t1 ; t3 ; t5 ; t7
t2 ; t4 ; t6 ; t8
All transitions are covered by Tinvariants.
All places are covered by P-invariants.
General properties :
Net is bounded.
Deadlock is not possible.
Net is live.
Net has home states.
Coverability graph generation statistics: 15 unique markings
[email protected]
11
Résultats d'analyse : Modèle sans ordre de fabrication avec comptage des pièces produites
P-invariants:
1 0 0
(M1_libre)
0 1 0
(robot_libre)
0 0 1
(M2_libre)
1 1 0
(TR1)
0 1 1
(TR2)
1 0 0
(piece_M1)
0 0 1
(piece_M2)
1 0 0
(US1)
0 0 1
(US2)
0 0 0
(nb_pI)
0 0 0
(nb_pII)
ie.
T invariants:
None.
No transitions are covered by T-invariants.
=1
=1
=1
The following places are not covered by Pinvariants: nb_pI, nb_pII
Net is unbounded.
Place nb_pII can become unbounded via the following transition
firing sequence: t2
t4
t6
t8
Rem : idem nb_pI
[email protected]
12
Résultats d'analyse : Modèle sans comptage des pièces produites, avec ordre de fabrication
P-invariants:
1 0 0
(M1_libre)
0 1 0
(robot_libre)
0 0 1
(M2_libre)
1 1 0
(TR1)
0 1 1
(TR2)
1 0 0
(piece_M1)
0 0 1
(piece_M2)
1 0 0
(US1)
0 0 1
(US2)
0 0 0
(of_p2)
0 0 0
(of_p1)
ie.
T invariants:
None.
=1
=1
=1
The following places are not covered by Pinvariants: of_p2, of_p1
Net is bounded.
Deadlock is possible via the following transition firing sequence:
t2
t4
t6
t8
t2
t4
t6
t8
t1
t3
t5
t7
t1
t3
Net is not live (there is a deadlock).
t5
t7
[email protected]
13
Exploitation des résultats d'analyse
P-invariants:
1 0 0
(M1_libre)
0 1 0
(robot_libre)
0 0 1
(M2_libre)
1 1 0
(TR1)
0 1 1
(TR2)
1 0 0
(piece_M1)
0 0 1
(piece_M2)
1 0 0
(US1)
0 0 1
(US2)
M2
libre
M1
libre
TR2
TR1
pièce
sur M1
Robot
libre
pièce
sur M2
ie.
US1
= 1
= 1
= 1
US2
All places are covered by P-invariants.
RdP borné (relation non duale)
Affectation exclusive de la ressource
Sous-réseaux assimilables MEF pour décomposition
[email protected]
14
T
1
0
1
0
1
0
1
0
invariants:
0
(t1)
1
(t2)
0
(t3)
1
(t4)
0
(t5)
1
(t6)
0
(t7)
1
(t8)
t1
t2
t3
t4
ie.
t5
t6
t1 ; t3 ; t5 ; t7
t2 ; t4 ; t6 ; t8
t7
t8
All transitions are covered by Tinvariants.
RdP vivant (relation non duale)
Existence de processus cycliques
(rem: transitions impliquées et nombre d’occurrence sur le vecteur)
[email protected]
15
Net is bounded.
borné
Deadlock is not possible.
vivant
Net is live.
Ré-initialisable (états
d’accueil)
A
M2
libre
M1
libre
pièce
sur M1
US1
B
TR2
TR1
Robot
libre
C
D
pièce
sur M2
F
E
G
US2
H
Graphe des marquages
accessibles
I
J
L
N
K
M
O
[email protected]
16
P-invariants:
1 0 0
(M1_libre)
0 1 0
(robot_libre)
0 0 1
(M2_libre)
1 1 0
(TR1)
0 1 1
(TR2)
1 0 0
(piece_M1)
0 0 1
(piece_M2)
1 0 0
(US1)
0 0 1
(US2)
0 0 0
(nb_pI)
0 0 0
(nb_pII)
ie.
M2
libre
M1
libre
TR2
TR1
pièce
sur M1
Robot
libre
pièce
sur M2
US1
=1
=1
=1
The following places are not covered by Pinvariants: nb_pI, nb_pII
nb_pI
US2
nb_pII
de type I
de type II
(rem: places « puits »)
RdP borné ? Conclusion impossible !
(rem: places dédiées au comptage de pièces … donc logiquement non bornées)
Relations préservées car structure du RdP non modifiée sur cette partie du modèle
[email protected]
17
T invariants:
None.
M2
libre
M1
libre
TR2
TR1
pièce
sur M1
US1
nb_pI
Robot
libre
pièce
sur M2
US2
nb_pII
de type I
de type II
Perte des processus cycliques, en fait non identifiés par l’analyse
(induit par marquage croissant donc non stationnaire sur places puits)
[email protected]
18
Net is unbounded.
Place nb_pII can become unbounded via the following transition
firing sequence: t2
t4
t6
t8
Rem : idem nb_pI
Identification du chemin (séquence de franchissements de transitions)
conduisant à un marquage strictement croissant
Non borné … induit par marquage croissant sur places puits
Graphe de marquage > 85 états (analyse arrêtée là) … graphe infini
(rem : à noter la non détermination d’états d’accueil)
[email protected]
19
(rem: places « sources »)
P-invariants:
1 0 0
(M1_libre)
0 1 0
(robot_libre)
0 0 1
(M2_libre)
1 1 0
(TR1)
0 1 1
(TR2)
1 0 0
(piece_M1)
0 0 1
(piece_M2)
1 0 0
(US1)
0 0 1
(US2)
0 0 0
(of_p2)
0 0 0
(of_p1)
ie.
Ordres de fabrication de pièces
de type I
de type II
of_p1
of_p2
M2
libre
M1
libre
=1
=1
=1
The following places are not covered by Pinvariants: of_p2, of_p1
TR2
TR1
pièce
sur M1
US1
Robot
libre
pièce
sur M2
US2
RdP borné ? Conclusion impossible !
(rem: of_p1 et of_p2 = places sources … donc normalement bornées
mais n’appartiennent pas à composantes conservatives car marquage décroissant)
Relations préservées car structure du RdP non modifiée sur cette partie du modèle
[email protected]
20
Ordres de fabrication de pièces
de type I
de type II
of_p1
of_p2
T invariants:
None.
M2
libre
M1
libre
TR2
TR1
pièce
sur M1
US1
Robot
libre
pièce
sur M2
US2
Perte des processus cycliques, en fait non identifiés par l’analyse
(induit par marquage décroissant donc non stationnaire sur places sources)
[email protected]
21
Net is bounded.
Deadlock is possible via the following transition firing sequence:
t2
t4
t6
t8
t2
t4
t6
t8
t1
t3
t5
t7
t1
t3
Net is not live (there is a deadlock).
t5
t7
Non vivant … identification du chemin
(séquence de franchissements de transitions)
conduisant à un blocage total
borné … pas d ’influence des places sources
(marquage borné décroissant)
Graphe de marquage = 77 états … graphe fini mais bloquant
(rem : à noter la détermination d’états d’accueil même si non ré-initialisable)
[email protected]
22
Remarque sur la présence
d ’état source ou d ’état puits
Prise de la
ressource
OP1
OP2
Ressource
Unitaire
(i.e. capacité=1)
OP2
Libération de la
ressource
Avec prise en compte de la ressource
P-invariants:
1 0 (p1)
1 0 (attente)
Disparition de la
1 1 (OP1)
1 0 (OP2)
contrainte sur OP1
0 1 (ressource)
ie.
M(p1) + M(attente) + M(OP1) + M(OP2) = 3
M(OP1) + M(ressource) =1
[email protected]
OP1
!
Sans prise en compte de la ressource
P-invariants
1 (p1)
1 (attente)
1 (OP1)
1 (OP2)
ie.
M(p1) + M(attente) + M(OP1) + M(OP2) = 3
23
Remarque sur l ’analyse
d ’un RdP constitué de plusieurs sous-RdP
RdP_A
t1
t2
t3
RdP_B
RdP_B
t1
t3
t2
t4
t4
t5
RdP_A
… t4 … t5 … t4 ...
=> RdP_A non-bloqué
=> RdP_B
bloqué
… t1 … t2 … t1...
=> RdP_A et RdP_B bloqués
Sous-RdP corrects mais interactions bloquantes !
Nécessité d’une Analyse Globale !
Propriétés RdP Global non déductibles de celles des sous-RdP
[email protected]
24
Réalisation Logicielle
Plusieurs possibilités d’implémentation
• les machines à micro-processeur (langages assembleur, Pascal, C, Ada, ...)
directement (programmation du modèle) ou indirectement (traduction du modèle),
• les automates programmables
attention à l’utilisation d’automates orientés Grafcet car les règles d'évolution sont différentes,
• les systèmes d’exploitation multitâches temps-réel
le RdP décrit la structure des tâches et leurs interactions,
• les environnements orientés objets
structuration en objets dont les RdP associés décrivent les comportements et les interactions,
• les systèmes distribués (ou multiprocesseurs), etc.
Fonctionnement en mode synchrone (ou pseudo-synchrone) ou asynchrone.
[email protected]
25
Réalisation Logicielle … mode synchrone
mode synchrone = utilisation d’une horloge temps-réel (HTR) pour guider l’exécution du cycle.
Initialisation
système
Initialisation
système
IT HTR
Initialisation
cycle
LE
Initialisation
cycle
SORT
LE
Traitement
SORT
Attente HTR
Traitement
- Structure du programme synchrone • Entrées mémorisées (LE)
• Sorties réelles (SORT) appliquées à pas
constant
• Traitement (durée variable mais finie et
inférieure au temps de cycle )
[email protected]
- Structure du programme pseudo-synchrone • En fait asynchrone car cycle pas cadencé par une horloge
temps-réel
• Considéré parfois comme synchrone car E/S sont mémorisées
et fonctionnement cyclique
• Cependant pas de calcul pas nécessairement constant
26
Réalisation Logicielle … mode asynchrone
Asynchrone = pas d’horloge temps-réel
• lecture des entrées effectuée au besoin
• élaboration des sorties effectives au fur et à mesure des calculs
• avantages : simplicité (pas de mémorisation des E/S) et rapidité.
• inconvénient : les possibilités d’aléas
• Conséquence et règles
- Système monotâche : mémoriser toute variable d’entrée binaire ou numérique utilisée plusieurs fois au
cours du même cycle ... quasi-équivalent au mode pseudo-synchrone.
- Système multitâches : événement local à une tâche si possible, sinon événement testé à l’aide d’une
primitive de l’exécutif.
[email protected]
27
Réseaux de Petri Interprétés (flot de contrôle et flot de données)
Réseau de Petri = une structure de contrôle traduisant l'aspect comportemental du système
Or le système possède souvent de nombreuses données dont l'organisation peut fortement influencer les
performances de l'application résultante.
Données (et transformations) non représentées
Utiliser des diagrammes de flots de données (Data Flow Diagram).
La description de l'application est complète si elle comprend :
• l'expression du flot de contrôle (RdP décrivant le comportement)
• l’expression du flot de données (DFD décrivant la manipulation des données)
[email protected]
28
Réalisation logicielle monotâche synchrone
Réalisation guidée par les transitions
(plus adéquat pour réalisation monotâche)
• Places représentées par des variables du programme.
• Chaque transition = un bloc d’instructions.
Ce bloc est composé de 4 groupes :
• 1er groupe : il détermine si la transition est sensibilisée
•
a&b
2ème
groupe : il détermine si la réceptivité associée est vraie
• 3ème groupe : il effectue le franchissement de la transition.
- démarquage des places précédentes,
- marquage des places suivantes.
S1
• 4ème groupe : il désactive les actions (ou les sorties virtuelles selon le mode) associées aux places
démarquées et active celles associées aux places nouvellement marquées.
[email protected]
29
•
a&b
2ème
S1
[email protected]
30
•
a&b
2ème
S1
[email protected]
31
•
a&b
2ème
S1 vraie
[email protected]
32
Organisation générale du programme
Initialisations
début cycle
L.E. (Lecture des Entrées) ;
SORT (génération des sorties) ;
Bloc transition t1
Bloc transition t2
.
.
.
Bloc transition tn
fin cycle ...
En mode asynchrone blocs LE et SORT répartis
dans les blocs transitions
Sorties impulsionnelles produites directement dans les blocs
transitions quel que soit le mode de réalisation (synchrone,
asynchrone)
Transitions décrites en séquence dans un ordre indifférent
Pour deux transitions en conflit effectif,
la transition franchie est la première exécutée ...
Donc rendue prioritaire à l’implémentation :
défaut de reproductibilité
(éviter cet indéterminisme dès la spécification)
[email protected]
33
Illustration transitions en conflit effectif
Transitions décrites en séquence dans un ordre indifférent
Marquage courant
…
t1
?
t2
bloc t4
bloc t2
t3
bloc t5
t4
t5
conflit entre t2 et t3
bloc t1
bloc t3
bloc t6
la transition franchie
est la première exécutée ...
Après tir de t2,
t3 non franchissable
...
t6
donc t2 rendue prioritaire …
à l’implémentation !
Si t3 décrite avant t2 … t3 prioritaire
[email protected]
défaut de reproductibilité
34
Résolution de l ’indéterminisme d ’un conflit structurel
introduction de la place complémentaire
Boucle de lecture
Transitions en conflit
A
A’
A
A’
A’
A
B
A’ place complémentaire de A
évolution inverse du marquage
• transitions alimentant A vident A’
• transitions vidant A alimentent A’
conflit effectif impossible
(ici, priorité de A sur B)
[email protected]
35
Réalisation guidée par les transitions … Illustration implémentation
P1
P2
P3
ti
S2
S1
( x1&/x2 ; S0 )
P4
P5
P6
Bloc transition ti
•1er groupe : sensibilisation
var = P1 et P2 et P3
si var = faux alors saut à ti+1
•2ème groupe : condition
var = x1 et pas x2
si var = faux alors saut à ti+1
•3ème groupe : tir de ti.
P1 = faux ; P2 = faux ; P3 = faux ; P4 = vrai ; P5 = vrai ; P6 = vrai ;
•4ème groupe : actions
Actions sur les transitions
S0 = vrai ; S0 = faux ;
Actions sur les places
S1 = faux ; S2 = vrai ;
[email protected]
36
Réalisation guidée par le marquage
technique du choix multiple
appliquée pour la mise en œuvre des machines à états finis (systèmes séquentiels)
Pour l’appliquer aux réseaux de Petri (RdP), adaptation du modèle parfois nécessaire :
• soit en s’appuyant sur le Graphe des Marquages accessibles GA(R;Mo),
Méthode "lourde" mais efficace en terme de temps de calcul et de taille du programme,
• soit en décomposant le RdP en RdP machines à états (RdP ME).
S’il subsiste des sous-réseaux non ordinaires et/ou des RdP MEF k-bornés, il faut tirer leur graphe
des marquages accessibles
Décomposition en machine à états finis (MEF)
[email protected]
37
Rappels
• un RdP ordinaire est un RdP dans lequel les poids des arcs sont égaux à 1 (un RdP ordinaire binaire
est un RdP sauf, i.e. ordinaire 1-borné).
• un RdP ME est un RdP ordinaire dans lequel toute transition possède une seule place en entrée (Pré)
et une seule place en sortie (Post). Une ME permet effectivement d'exprimer les décisions mais pas le
parallélisme (contrairement au graphe d'événements).
Convergence en ET
[email protected]
Divergence en ET
Convergence en OU Divergence en OU
38
Rappels
• Un RdP ordinaire k-borné (avec k>1) n’est pas directement transposable en un RdP ME.
Il faut passer par le graphe des marquages accessibles afin d’obtenir un RdP ME
n’ayant qu’un état actif quelque soit t (caractéristique essentielle d’une ME).
Toutefois dans certains cas la pondération n'étant que l'expression d'un comptage d'entités
(symbolisées par les jetons), le RdP ordinaire k-borné reste transposable en un RdP ME.
(m;c+1)
(m;)
10
- RdP non binaire [email protected]
≡
(c=10;c=0)
- Transformation d'un compteur structurel en interprétation 39
Principe
• Différence structurelle entre un RdP ordinaire binaire et une Machine à Etats (ME) :
- essentiellement au niveau du parallélisme et des synchronisations
- repérables par les transitions ayant :
- plusieurs arcs sortants … départ en parallèle
- et/ou plusieurs arcs entrants … synchronisation
• La coupure de ces transitions en fragments possédant :
- 1 seul arc entrant
- et un seul arc sortant
définit des branches RdP
séquentielles ordinaires
• Les sous-RdP obtenus sont des RdP ME
Il suffit alors de refermer ces branches et de les synchroniser entre elles
pour rendre les RdP ME obtenus exploitables.
• Plusieurs branches RdP ordinaires peuvent être recomposées pourvu que cette composition
donne toujours un RdP ME
minimisation possible du nombre de RdP ME de l’application
[email protected]
40
Illustration
P1
(a>10;)
t3
t1
Action1
P3
P2
t2
(c=2.6;action4)
(b=5;)
P4
t8
P8
Action2
t4
(f<14;action5)
(d=21;) t7
t5
Action3
Action1
P5
t6
(e=1;)
P7
P6
Fragmentation des transitions
(x;y)
[email protected]
(condition ; action impulsionnelle)
41
Illustration
ß Décomposition en RdP ME ß
P1
P4
t'7
P8
P3
P2
t2
t8
t3
t1
t4
t'5
t7
t6
P5
t5
P6
P7
synchronisations
[email protected]
42
Illustration
ß RdP ME_B ß
ß RdP ME_A ß
P1
« fermeture »
t3
t1
P2
t2
t8
PB
t5 . synchroP4
P8
P3
P5
t4
P4
t6 . synchroP7
t6
t7 . synchroP6
P6
P7
t4 . synchroPB
inutile
(PB marquée avant P4)
[email protected]
SynchroPi = Variables de synchronisations
43
Exercice
P1
t1
P2
t2
P3
t3
P4
t4
[email protected]
t5
P5
P6
P7
t6
P8
t7
P9
t8
44
Solution
t5’
t1’
P5
t1
P1
t5
P6
t6’
t2’
P2
P7
t6
t2
P8
« fermeture »
P3
t7
t3
P9
P4
t4
PA
t2’
[email protected]
t5’
t1’
P5
t8
PB
t6’
45
Solution
t5’ & SynchroP6
t1’ & SynchroP1
PA
t2’ & SynchroP2
P5
PB
t6’ & SynchroP7
t5 & SynchroP5
t1 & SynchroP5
P1
P6
P7
P2
t6 & SynchroPB
t2 & SynchroPA
P8
P3
t3
P4
[email protected]
t4
Remarque
synchro sur les états
mais en toute rigueur
synchro sur les transitions
(fusion de transitions)
t7
P9
t8
46
Réalisation guidée par le marquage
technique du choix multiple … illustration
Organisation générale du programme
Initialisations
début cycle
répéter
LE
SORT
/* traitement */
switch (Etat_ME_A)
{ case P1 :
case P2 :
...
case Pn :
}
• chaque RdP ME a une variable d’état associée (ex : Etat_ME_A)
• chaque état est codé par une constante (ex : type énuméré du C)
• les synchronisations sont représentées par des variables (0/1)
jusqu’à faux (attention, il est préférable de prévoir une condition de sortie)
fin cycle
[email protected]
47
Réalisation guidée par le marquage … illustration (ex rdp p.43)
main()
{
/* déclaration des MEFs */
enum etats_ME_A {P1 ,P2 , P3 ,P4 , P7 , P8} Etat_ME_A ;
enum etats_ME_B {PB ,P5 ,P6} Etat_ME_B ;
/* déclaration des variables */
int SynchroP4, SynchroP6, SynchroP7 ;
int Condition_Sortie_Boucle = 0 ;
/* Initialisations de l‘état initial de chaque RdP ME et des
synchronisations */
Etat_ME_A = P1 ; Etat_ME_B = PB ;
SynchroP4 = 0 ; SynchroP6 = 0 ; SynchroP7 = 0 ;
do /* début cycle */
{
/* Bloc Lecture et mémorisation des entrées (mode synchrone
ou pseudo-synchrone) */
evt1=(a>10); evt3=(b==5); evt2=(c==2.6); evt4=(d==21);
evt5=1; evt7=1; evt8=(f<14); evt6=(e==1);
[email protected]
/* Bloc inférence ... description des réseaux de Petri */
switch (Etat_ME_A) {
case P1 : if (evt1) Etat_ME_A = P2 ;
else if (evt3) Etat_ME_A = P3 ; break ;
case P2 : if (evt2) Etat_ME_A = P4 ; Action4=1; Action4=0; break ;
case P3 : if (evt4) Etat_ME_A = P4 ; break ;
case P4 : if (evt5) Etat_ME_A = P7 ; break ;
case P7 : if (evt7 && synchroP6) Etat_ME_A = P8 ; break ;
case P8 : if (evt8) Etat_ME_A = P1 ; Action5=1; Action5=0; break ;
default : printf(‘’ Erreur RdP ME A non initialisée \n‘’ ) ;
}
switch (Etat_ME_B) {
case PB : if (evt5 && synchroP4) Etat_ME_B = P5 ; break ;
case P5 : if (evt6) Etat_ME_B = P6 ; break ;
case P6 : if (evt7 && synchroP7 ) Etat_ME_B = PB ; break ;
default : printf(‘’ Erreur RdP ME B non initialisée \n‘’ ) ;
}
/* Ce bloc d’actualisation des synchronisations peut être inséré en début
ou fin de cycle */
SynchroP4 = (Etat_ME_A==P4); SynchroP7 = (Etat_ME_A==P7);
SynchroP6 = (Etat_ME_B==P6);
/* Bloc Génération des sorties (bloc inséré avant ou après l’inférence selon
le mode désiré) */
Action1=((Etat_ME_A==P2)||( Etat_ME_A==P5));
Action2=(Etat_ME_A==P3);
Action3=(Etat_ME_A==P7);
}
while (condition_sortie_boucle) ; /*fin cycle */
}
48
Réalisation guidée par le marquage … PRECISION IMPORTANTE
Attention à la synchronisation !
Il ne faut pas toucher au marquage des places de synchronisation tant que tous les RdP ME n’ont pas été
exécutés. Le marquage de ces places doit donc être mémorisé et leur évolution effective doit être effectuée
en début ou fin de cycle.
Illustration du dysfonctionnement induit si évolution des variables de synchronisation lors des tirs
PA
PB
t1 & SynchroPB
t3 & SynchroPA
t2
SynchroPA=0
tir de t2
SynchroPA=1
T1 non franchissable
t4
t3 franchissable
SynchroPB=0
SynchroPB=1
tir de t3
(donc perte « simultanéité » du tir)
RdP désynchronisés !
[email protected]
Précision : tirs de t1 et de t3 pdt le même cycle
programme (2 MEF décrites en séquence)
49
Réalisation logicielle multitâches asynchrone
Représentation de la structuration d’une application multitâches par un modèle basé RdP
fonctionnement de l’application logicielle traduit sur la structure du modèle
(enchaînement des opérations, parallélisme potentiel, synchronisations, etc.)
Tâche A
Tâche B
structure
out
in
squelette
décomposition en
sous-systèmes
correspondant à
tâches indépendantes
et/ou coordonnées
Importance de la communication sur l ’OS
[email protected]
50
La décomposition en sous-systèmes … principe
• orientée matériel : à chaque entité commandée est associée 1 tâche
L’approche (intuitive ou aidée parfois par les composantes conservatives) consiste à associer une tâche à
chaque entité physique commandée, il faut cependant que ces dernières ne puissent intrinsèquement
mener qu’une activité à la fois. Le cas contraire ferait apparaître du parallélisme au sein des tâches
obtenues par cette décomposition, ce qui supposerait alors une re-décomposition des sous-réseaux
obtenus.
• orientée fonction : à chaque fonction du système est alors associée 1 tâche
Il faut identifier les cycles séquentiels suivis par les jetons (souvent reflétés à travers les composantes
répétitives stationnaires) : un cycle correspond alors au corps d’une tâche. Les places qui sont reliées par
un arc à ce cycle, en entrée ou en sortie, constituent alors les places de communication à travers
lesquelles s’effectue tout échange et/ou synchronisation entre tâches.
Les fonctions ne correspondent pas toujours aux activités utilisées pendant la modélisation, à savoir
qu’un processus (décrivant une fonction) peut correspondre à une séquence d’activités.
Les deux principes s’appuient sur la décomposition d’un RdP en RdP machines à états.
[email protected]
51
La décomposition en sous-systèmes … illustration
M2
libre
M1
libre
décomposition orientée matériel
TR2
TR1
• Robot en charge des transports
pièce
sur M1
Robot
libre
pièce
sur M2
rem : TR1 et TR2 exclusifs
• Machine 1 en charge Usinage US1
US1
Sous-RdP
M1
US2
• Machine 2 en charge Usinage US2
Sous-RdP
Sous-RdP
ROBOT
M2
3 RdP_ME
+
communication
[email protected]
52
Places
de
communication
Places
M2
libre
M1
libre
communication
TR2
TR1
de
Robot
pièce
sur M1
pièce
sur M1
pièce
sur M2
pièce
sur M2
US1
M1
libre
[email protected]
US2
M2
libre
53
La décomposition en sous-systèmes … implémentation
corps des tâches
(pseudo-code)
Définition des messages
Intialisation
Définition priorité, stratégie
d ’ordonnancement
etc.
{
corps de la tâche
}
pièce
sur M1
Send(pid_robot,M1_libre) ;
do
{
Receive(pid_robot, pièce_sur_M1) ;
Reply(pid_robot) ;
US1 ;
Send(pid_robot,M1_libre) ;
}
while (1) ;
US1
M1
libre
Libération(s) et destruction(s) diverses
Attention à l’initialisation
[email protected]
54
Structure particulière !
t1
M1
libre
t2
TR2
TR1
Robot
pièce
sur M1
pièce
sur M2
attention conflit non résolu,
priorité établie par l'implémentation
(ici, t1 prioritaire sur t2)
[email protected]
M2
libre
corps des tâches
(pseudo-code)
do
{
activite = aucune ;
while (activite= =aucune)
{
if ((pid=Creceive(pid_machine1,M1_libre)) !=-1)
activite=activite1 ;
else
if ((pid=Creceive(pid_machine2,M2_libre)) !=-1)
activite=activite2 ;
}
Reply (pid) ;
Switch (activite)
{
case activite1 :
TR1; Send(pid_machine1,pièce_sur_M1); break;
case activite2 :
TR2; Send(pid_machine2,pièce_sur_M2); break;
...}
}
while (1) ;
55
M2
libre
M1
libre
décomposition orientée fonction
TR2
TR1
• fonction 1
pièce
sur M1
Robot
libre
pièce
sur M2
« fabriquer pièce type I »
• fonction 2
US1
Sous-RdP
FONCTION 1
US2
Ressource
Partagée
ROBOT
« fabriquer pièce type II »
Sous-RdP
FONCTION 2
2 RdP_ME
+
sémaphore
[email protected]
56
Robot
« fabriquer pièce type II »
Robot
TR2
TR1
US2
US1
[email protected]
57
Robot
TR1
do
{
Sem_wait(sem_robot) ; // réservation du robot
TR1 ;
Sem_post(sem_robot) ; // libération du robot
US1 ;
}
while (1) ;
US1
Précision : une tâche initiale doit se charger de
la création et de l’initialisation du sémaphore,
ainsi que de sa destruction.
[email protected]
58
La communication entre réseaux de Petri
Différents types de communication possibles dans une relation Ecrivain/Lecteur
(en supposant chaque acteur représenté par une tâche)
• Ecrivain (Asynchrone) / Lecteur (Asynchrone) (1)
Pas de contrainte de synchronisation sur la production d’un document ni sur la
vérification … évolution libre de chaque acteur.
• Ecrivain (Synchrone) / Lecteur (Synchrone) (2)
Les acteurs se donnent RDV pour échanger le document.
• Ecrivain (Asynchrone) / Lecteur (Synchrone) (3)
L ’Ecrivain évolue librement mais le Lecteur attend le document avant de le
vérifier.
• Ecrivain (Synchrone) / Lecteur (Asynchrone) (4)
réciproque cas précédent.
[email protected]
59
La communication entre réseaux de Petri … illustration
Ecrivain (Asynchrone) / Lecteur (Asynchrone) (1)
aucune structure particulière car pas d’interaction.
Ecrivain
[email protected]
Lecteur
60
Ecrivain (Synchrone) / Lecteur (Synchrone) (2)
l’interaction correspond à un RDV.
Ecrivain
Lecteur
2
7
3
4
1
5
[email protected]
8
9
6
10
61
Ecrivain (Asynchrone) / Lecteur (Synchrone) (3)
l’interaction correspond à une synchronisation.
Ecrivain
[email protected]
Lecteur
62
Influence de la mise en œuvre des structures de communication
La communication inter-processus : exemple de QNX (Real-Time Operating System)
• la communication synchrone … avec accusé de réception !
Le récepteur du message doit répondre à l‘émetteur car ce dernier n’évolue pas sans avoir reçu
cette réponse.
Ce mode correspond sous QNX au mécanisme de communication par messages ; il implique les
primitives Send (pour l’émission), Receive (pour la réception) et Reply (pour la réponse).
• la communication asynchrone ...
Le récepteur du message n’a pas à répondre à l’émetteur, ce dernier évolue d’ailleurs sans
attendre une réponse quelconque.
Ce mode correspond sous QNX au mécanisme de communication soit par proxy soit par signal ;
la primitive triggers permet d’activer un proxy et raise d’émettre un signal. Ce mode ne permet pas
l’échange de messages, à l'exception de messages prédéfinis dans le cas des proxies.
[email protected]
63
Impact sur le cas du RDV … Ecrivain (Synchrone) / Lecteur (Synchrone) (2)
Début /* ECRIVAIN */
Répéter (à l’infini)
{
faire opération associée à P1,
envoyer message au lecteur (P2),
recevoir message du lecteur (P7),
répondre au message (P9),
faire opération associée à P5.
}
Fin
P2
P4
P7
P9
Début /* LECTEUR */
répéter (à l’infini)
{
envoyer message à l'écrivain (P7)
recevoir message écrivain (P2),
}
Fin
Les deux tâches effectuent une émission pour laquelle elles attendent chacune une réponse
(communication par message avec accusé de réception) ... qui ne se produira jamais puisqu'elles sont
toutes les deux en émission.
Primitives et ordre de déclaration des échanges = sources d’interblocage
[email protected]
64
Impact sur le cas du RDV … Ecrivain (Synchrone) / Lecteur (Synchrone) (2)
Début /* ECRIVAIN */
Répéter (à l’infini)
{
envoyer message au lecteur (P2),
// réception réponse implicite (P4)
}
Fin
P2
P4
Début /* LECTEUR */
répéter (à l’infini)
{
recevoir message écrivain (P2),
}
Fin
Se ramener à un simple échange : une seule émission-réponse
[email protected]
65
Adaptation nécessaire … Ecrivain (Asynchrone) / Lecteur (Synchrone) (3)
Communications asynchrones entre deux processus en s’appuyant uniquement sur l’ensemble de primitives de
communication synchrone (i.e. les primitives dédiées à l‘échange de messages).
Considérer que l’échange asynchrone entre deux processus est supporté par un troisième processus qui, après
avoir reçu le message du processus émetteur et lui avoir répondu, prend en charge l’échange de ce message avec
le processus cible. Il s'agit en quelque sorte d'un « facteur ».
La communication entre émetteur et cible est alors de nature asynchrone
[email protected]
66
Adaptation nécessaire … Ecrivain (Asynchrone) / Lecteur (Synchrone) (3)
Process A
émetteur
Process B
intermédiaire
Send()
time
Send-data
transmitted
Reply-data
transmitted
Process C
cible
Process A
émetteur
Process B
intermédiaire
Receive()
Process C
cible
Reply()
Send()
Receive()
Processus bloqué
dans l’attente de la
réception du
processus cible
Send-data
transmitted
Reply-data
transmitted
- Principe de fonctionnement [email protected]
Reply()
- Modèle correspondant 67
Réalisation logicielle par un joueur de réseaux de Petri
Réalisation basée sur un joueur de réseaux de Petri = une "réalisation par tables"
Réalisation indirecte par l'intermédiaire d'un module de traduction qui construit un ensemble de
tables représentant les interconnexions des éléments de base du modèle (la structure et
l'interprétation).
Cette réalisation repose sur trois modules :
1- la description
Places [
1 'p1' (54,250) 1 0 0 0
...]
TimedTrans [
2 't_ex' (191,213) 0 2 0
...]
2- la traduction
nom:
état :
suivante :
nom:
état :
suivante :
[email protected]
3- l'exécution
structure
noyau
68
La description du réseau
• directement par la donnée de la matrice d'incidence C
(mode d'entrée peu pratique ne concernant que la partie structurelle du modèle)
• un système d'entrée graphique
• plus simplement un système d'entrée par fichier (format texte)
Souvent faite à partir des transitions
§ déclaration des arcs du réseau,
(arcs d'entrée et de sortie pour chaque transition, i.e. connexion aux places amont et aval)
§ déclaration de l'interprétation associée à chaque transition (réceptivité),
§ description des réceptivités associées aux transitions
(plusieurs transitions pouvant avoir la même réceptivité),
§ déclaration des actions associées aux places et leurs valeurs,
§ description du marquage initial.
[email protected]
69
La description du réseau … illustration
• Arcs du réseau
Format : <nom transition>, <liste places d'entrée>, <liste places de sorties>;
Exemple : t1, P1, P2 P3;
• Interprétation associée à la transition
Format : <nom transition>, <nom réceptivité>;
Exemple : t1, R1; t8, R7 ;
• Réceptivité
Format : <nom réceptivité>, <type=T>, <base temps>,<durée>;
<type=B>, <entrée(capteur)>, <valeur>;
<type=L>, <opération 1>, <opération 2>, ..., <opération n>;
Exemple de temporisation, donc type T, de durée = 3 * base_de_temps_1 :
R1, T, 1, 3;
Exemple d'expression logique, donc type L, a & (distance <10) & /(b+c) :
R7, L, a ET 2, 3 ET 4, distance < 10, 5 PAS, b OU c.
• Actions associées aux places
•
Format : <nom place>, <sortie(actionneur)>, <valeur>;
Exemple : P1, S(2),1;
Marquage initial
Format : <nom place>, <marquage>;
// les autres sont initialisées non marquées.
Exemple : P1, 2;
[email protected]
70
La description du réseau …
exemple d’un éditeur-analyseur DNAnet
nom
Type 1 = place
Description textuelle générée à partir
de la saisie graphique du modèle
(pour RdP autonomes ou T-temporisés).
Type 2 =
timed transition
Type 3 =
imm transition
Places
1 'p1'
1 'p2'
1 'p3'
1 'p4'
...]
[
(54,250)
(229,189)
(418,250)
(152,251)
Marquage
initial
1
1
1
0
Nœud
d'arrivée
[email protected]
0
0
0
0
0
0
0
0
Temporisation
TimedTrans [
2 't_ex' (191,213) 0 2 0
...]
ImmedTrans [
3 't1' (152,163) 0 1 0
3 't2' (317,164) 0 1 0
3 't3' (151,296) 0 1 0
...]
Edges [
't8' to
't7' to
'p1' to
'p3' to
't2' to
...]
'p3'
'p1'
't1'
't2'
'p5'
Coordonnées
graphiques
Interactions
avec
sous-réseaux
Subnets [ ]
Nœud de
départ
0
0
0
0
1
1
2
1
3
[
[
[
[
[
]
]
]
]
]
Poids des
arcs
71
La traduction du modèle
description initiale
ensemble de données
(structures de données)
manipulées par
le module d'exécution
La traduction est donc la mise en forme du modèle au niveau informatique.
étape clef qui conditionne les performances de l'exécution
mise en forme de la structure = source d'optimisation du temps de cycle du joueur
compromis entre
rapidité d'inférence conférée par une meilleure structuration (exécution plus rapide) et
accroissement induit sur la dimension de l'espace mémoire nécessaire (stockage)
une solution = structures de données chaînées (pointeurs) pour décrire le modèle.
Cela permet d'atteindre immédiatement les transitions sensibilisées
et donc susceptibles d'être franchies, à partir du marquage courant.
[email protected]
72
L'exécution du modèle ... le joueur de réseaux de Petri
rôle = animer le modèle
en appliquant les règles régissant l'évolution du marquage au sein d'un RdP
Son algorithme « classique » s'appuie sur les places marquées
Pour chaque place marquée,
recherche de(s) transition(s) sensibilisée(s) par le marquage courant.
Exécution dirigée par le marquage
donc examen que des transitions sensibilisées (ou susceptibles de l'être)
et de plus, chacune d'elles une et une seule fois par cycle.
[email protected]
73
L'exécution du modèle ... le joueur de réseaux de Petri
cycle
Événement
externe ou interne
Places marquées
Recherche
transition sensibilisée
Plus aucune
Etat
stable
non
Test
si transition franchissable
oui
Tir de la transition =
Actualisation marquage
Evénements internes ou externes (exemples)
• un top d'horloge dans le cas d'un fonctionnement synchrone,
• l'arrivée d'un message ou la libération d'un sémaphore dans le cas
asynchrone
Etat stable
état sans évolution autonome possible,
i.e. attente de l’occurrence d’un événement
[email protected]
74
L'exécution du modèle ... Elément d’optimisation du joueur
Algorithme du joueur : étape essentielle = recherche des transitions sensibilisées
Transition sensibilisée = marquage de ses places amont suffisant
Rechercher une transition sensibilisée = examiner le marquage de toutes ses places amont
(l'examen s'arrête dès que le marquage de l'une de ces places est insuffisant)
La structure d'un modèle contient fréquemment des divergences en OU (choix explicite)
Place partagée alors "intéressante" puisque son état permet de juger de
la sensibilisation de plusieurs transitions à la fois.
Recherche des transitions sensibilisées réduite, i.e. plus rapide
Optimisation du joueur par réduction du nombre de tests …
notion de place de déclenchement
[email protected]
75
L'exécution du modèle ... Illustration de l’optimisation du joueur
Place de déclenchement = place désignée comme place devant nécessairement être marquée
pour franchir une transition donnée.
A chaque transition du réseau est associée une place de déclenchement, plusieurs transitions pouvant
avoir la même place de déclenchement ... là est d'ailleurs l'intérêt.
P2
P1
t1
t2
t3
P3
P4
t4
Places de déclenchement de l'exemple : P1 pour t1 ; P2 pour t2 t3 t4
2 places à examiner pour tester la sensibilisation de 4 transitions
• choix de la place de déclenchement associée à une transition est totalement libre
• choix totalement indépendant de celui effectué pour les autres transitions du réseau
• plus judicieux de choisir comme places de déclenchement les places partagées du réseau
[email protected]
76
L'exécution du modèle ... désignation des places de déclenchement
• Détermination, hors ligne, automatisée sans difficulté :
pour chaque transition prendre la place amont la plus partagée ou à défaut sa première place d'entrée
• Afin d'éviter la redondance dans la déclaration des arcs, pour chaque transition supprimer sa place
de déclenchement de son ensemble de places d'entrée
Pour chaque transition on obtient donc l'ensemble des places adjacentes à tester
si sa place de déclenchement est marquée.
P1
t1
P3
P2
t2
t3
t4
Transition t4 :
[email protected]
P4
- place de déclenchement = P2
- ensemble des places adjacentes = {P3 P4}
77
L'exécution du modèle ... Optimisation du joueur
pi
E(pi,ti)
= la place de déclenchement de la transition ti, pointée par pi,
= l'ensemble des places adjacentes à la place pi par rapport à la transition ti.
Nouvel algorithme du joueur
[email protected]
1.
Scruter la liste des places de déclenchement marquées
Si fin ou vide aller en 5, sinon aller en 2.
2.
Tester le marquage des places adjacentes
Si marquées aller en 3, sinon aller en 1.
3.
Tester la condition associée à la transition pointée
Si condition respectée aller en 4, sinon aller en 1.
4.
Franchir la transition (réactualisation du marquage)
Aller en 1.
5.
Etat Stable.
78
Quelques ouvrages de référence ou sites intéressants sur les RdP
[David89] R. David, H. Alla. "Du Grafcet aux réseaux de Petri". Edition Hermes, Traité des
nouvelles technologies, Paris 1989.
[Vidal92] G.Vidal-Naquet, A.Choquet-Geniet, "Réseaux de Petri et systèmes parallèles", Editions
Armand Collin 1992.
[Brams83] G.W.Brams, "Réseaux de Petri : théorie et pratique", Editions Masson 1983.
§ The Petri Nets Bibliography
http://www.informatik.uni-hamburg.de/TGI/pnbib/
§ Groupe francophone sur les réseaux de Petri
http://www.ec-lille.fr/~rdp/
§ Petri Nets Tools Database Quick Overview
http://www.daimi.aau.dk/~petrinet/tools/quick.html
§ Méthodes formelles de développement de Systèmes logiciels
http://lglwww.epfl.ch/Enseignement/GLA/GLA98/Transparents/
[email protected]
79

Réseaux de Petri - Université de Montpellier

Transcription

Documents pareils

Intervenants après le film « Emergence d`un nouveau Monde » 15

Sous-réseau « Robotique médicale »

organigramme de la direction des etudes et de la recherche

€330,000 Sant Andreu de la Barca, Barcelona, Catalogne, Espagne

Internet - Université de Montpellier

Nationaux 2016 : Le résumé de la ronde 1 par le GMI Apicella GMI

CHAMPIONNATS DE FRANCE « COMBAT KUNG FU

Connexion et prise en main a distance d`un PC

µControleur Rabbit RCM2X00 - Université de Montpellier