Modélisation des systèmes temps-réel répartis embarqués pour la ...

More documents

Recommendations

Info

15 end sspg_b; Modélisation des systèmes temps-réel répartis embarqués Listing VII.4 – Description d’un sous-programme avec deux séquences d’appel, correspondant au réseau de Petri de la figure VII.8(a) Le listing VII.4 décrit un sous-programme possédant deux séquences d’appel seq1 et seq2. Chaque séquence appelle un seul sous-programme, qui prend un paramètre en entrée et ne rend rien en sortie. La traduction en réseau de Petri est illustrée sur la figure VII.8(a). Nous voyons que les deux séquences peuvent s’exécuter dans un ordre arbitraire, un nombre quelconque de fois. La figure VII.8(b) modélise le comportement que nous souhaitons appliquer au sous-programme : nous voulons d’abord exécuter la séquence seq1 puis la séquence seq2, puis terminer l’exécution du sous-programme. La figure VII.8(c) est le résultat de la fusion du réseau issu de la description AADL et du réseau comportemental. Nous voyons que les transitions seq1 et seq2 sont fusionnées avec les sous-réseaux de séquences correspondantes ; les places begin et end sont connectée à la transition init pour que le réseau du sous-programme puisse contrôler le sous-réseau comportemental. VII-7 Propriétés étudiées sur l’architecture La traduction d’une modélisation AADL en réseau de Petri permet d’extraire les flux d’exécution et de les représenter dans un formalisme facilitant leur analyse. Il est possible d’utiliser les formules de logique temporelle afin de vérifier certains comportements sur l’architecture complète. Ces vérifications sont spécifiques à la modélisation considérée, et notamment dépendent a priori des modélisations comportementales fournies pour les différents composants. Parallèlement, la vérification de certaines caractéristiques de l’architecture peut être effectuée systématiquement. Ces vérifications concernent des propriétés structurelles concernant la viabilité des flux d’exécution ; par exemple, nous voulons systématiquement nous assurer que la construction architecturale ne fait pas apparaître de blocage dans les flux d’exécution. Le réseau de Petri généré à partir d’une description AADL modélise la circulation des données et des flux d’exécution. Nous pouvons donc l’exploiter afin d’analyser les éventuels dysfonctionnements dans l’exécution de l’architecture. Un dysfonctionnement dans l’architecture correspond à un arrêt de la circulation des données, et peut se manifester de plusieurs façons : – les communications entre les différents threads ne sont pas coordonnées ; – l’absence d’une donnée dans l’exécution des séquences d’un thread ; – la « famine » d’un thread ; – le blocage de l’exécution d’un thread ; – l’utilisation de données dont la valeur n’est pas déterministe. L’apparition de ces situations dans l’architecture peut être traduite par des propriétés structurelles sur le réseau ou des formules de logique temporelle. Dans la suite nous présentons les différentes formules correspondantes. VII-7.1 Cohérence des communications Nous avons vu en section VII-4.2.3 que les réseaux de Petri que nous construisons sont censés être bornés. Certaines configurations architecturales conduisent cependant à une surproduction de jetons qui ne peut pas être régulée par la boucle de rétroaction. Le listing VII.5 est un exemple d’une telle configuration ; la figure VII.9 représente de réseau de Petri correspondant. 142 c○ 2007 Thomas Vergnaud
begin Chapitre VII – Vérification formelle de la structure des applications seq1_begin seq2_begin seq1_end appel1 appel2 seq2_end (a) réseau de Petri correspondant au listing VII.4 seq2_begin seq1_begin mid appel1 appel2 seq1_end end (c) réseau de Petri final seq2_end loop FIG. VII.8 – Réseau de Petri pour un composant hybride c○ 2007 Thomas Vergnaud 143 1 begin seq1 mid seq2 end (b) réseau de Petri de coordination
Page 1 and 2:
École doctorale d’informatique,
Page 3:
Telle est la nature de l’esprit h
Page 6 and 7:
To validate this design process, we
Page 8 and 9:
Modélisation des systèmes temps-r
Page 10 and 11:
Page 12 and 13:
Page 14 and 15:
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
II-2.2.2 CORBA Modélisation des sy
Page 24 and 25:
II-2.2.3 RMI Modélisation des syst
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
II-4.4 Discussion Modélisation des
Page 34 and 35:
II-5.2.2 Connecteurs Modélisation
Page 36 and 37:
18 } Modélisation des systèmes te
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
11 end i486.AMD; 12 Modélisation d
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
1 system global 2 end global; 3 Mod
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
16 Modélisation des systèmes temp
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
phase 1 phase 2 Modélisation des s
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
descriptions comportementales Modé
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
17 end sp.impl; Modélisation des s
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
13 Modélisation des systèmes temp
Page 104 and 105: Modélisation des systèmes temps-r
Page 116 and 117: autre nœud Modélisation des syst
Page 124 and 125: 10 features Modélisation des syst
Page 126 and 127: VI-3.4.6 Activation Modélisation d
Page 138 and 139: donnee (a) donnée Modélisation de
Page 144 and 145: 53 end global.impl; Modélisation d
Page 156 and 157: 1 data donnee 2 end donnee; 3 4 thr
Page 172 and 173: 19 use Partition; 20 Modélisation
Page 174 and 175: 23 begin Modélisation des système
Page 178 and 179: VIII-3.1 Motifs AADL de base Modél
show all

Modélisation des systèmes temps-réel répartis embarqués pour la ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?