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

More documents

Recommendations

Info

53 end global.impl; Modélisation des systèmes temps-réel répartis embarqués Listing VII.2 – Exemple de connexion AADL, traduit par le réseau VII.5 Règle VII.11 (Limitation du nombre d’états du réseau) À chaque transition modélisant un thread recevant des données doit correspondre une place de sortie. Cette place de sortie reçoit les différents jetons de contrôle dont les couleur correspondent à celles des jetons reçu dans les places d’entrée. Les jetons accumulés dans cette place de sortie sont envoyés vers les places reset des threads émetteurs afin de réguler leur production de jetons. La place reset du thread émetteur doit donc comporter une garde s’assurant que seul les jetons de contrôle correspondant à sa couleur sont acceptés. Il est par conséquent nécessaire de définir une couleur de contrôle par thread AADL, comme nous l’avons énoncé dans la règle VII.3. Notons que dans le cas d’un thread en tâche de fond, cette rétroaction est inutile, puisque le thread considéré ne boucle pas ; ces thread ne possèdent d’ailleurs pas de transition reset. La figure VII.5 donne le réseau de Petri issu de la modélisation du listing VII.2. Les représentations des threads sont repérées par les zones grisées. Les deux connexions cnx1 et cnx2 du processus processus_b sont fusionnées en une seule transition lors de la traduction en réseau de Petri. Nous nommons la transition résultante d’après la concaténation des différents threads impliqués : process1_thread1_process2_threads1_process2_thread2. process1_thread1_restart control process1_thread1_start process1_thread1_reset [c = th_1] process1_thread1_end control process1_thread1_s comm class donnee is [d, u]; control is 1 .. 3; domain comm is ; var v in donnee; c, c1 in control; process2_thread2_e comm process2_thread2_start control process2_thread2_choose control process2_thread1_choose process1_thread1_process2_thread1_process2_thread2 process2_thread1_e comm process2_thread1_start process2_thread2_restart process2_thread1_restart control process2_thread1_reset control process2_thread2_reset process2_thread2_end control control process2_thread1_end FIG. VII.5 – Réseau de Petri borné modélisant une architecture de haut niveau correspondant au listing VII.2, page 131 132 c○ 2007 Thomas Vergnaud
Chapitre VII – Vérification formelle de la structure des applications VII-5 Modélisation de l’implantation des composants Jusqu’ici, nous avons modélisé les opérations de traitement des composants par une transition. La représentation de l’implantation d’un composant consiste à remplacer cette transition par le sous-réseau de Petri décrivant les séquences d’appel décrits dans l’implantation du composant. Le réseau de Petri fait alors apparaître les connexions entre les différents sous-éléments du composant. VII-5.1 Modélisation des sous-composants En section VII-4.1.2, nous avons indiqué que la représentation en réseaux de Petri se basait sur les composants actifs de l’architecture. D’après ce que nous avons établi dans la règle VII.7, un composant possédant des sous-composants est systématiquement remplacé par ces derniers. Seuls les sous-composants sont donc représentés dans un réseau de Petri ; cette situation a donc déjà été traitée en section VII-4.1.2. VII-5.2 Modélisation des sous-programmes Contrairement à la génération de code que nous avons présentée au chapitre V, la traduction en réseau de Petri rend compte des flux d’exécution. Selon cette approche, chaque sous-programme est modélisé dans le réseau autant de fois qu’il est appelé. Chaque appel de sous-programme est donc assimilé à une instance. Il en est par conséquent de même pour un accès requis à un sousprogramme. Règle VII.12 (Traduction des accès à sous-programme) L’appel d’un sous-programme dont l’accès est requis par un thread ou un sousprogramme est assimilé à un appel normal au sous-programme correspondant. De la même façon que les composants de haut niveau, les sous-programmes sont modélisés par une transition entourée de places modélisant les paramètres d’entrée et de sortie. Règle VII.13 (Traduction des sous-programmes) Un appel de sous-programme AADL est traduit par une transition et des places correspondant à ses différents paramètres. Le flux d’exécution contrôlant l’appel du sousprogramme est matérialisé par deux places transmettant un jeton de contrôle à la transition du sous-programme. Ce jeton de contrôle est celui du thread dans lequel l’appel est effectué. Les places d’entrée sont connectées à la transition du sous-programme par un arc simple, de la même façon que pour les places de contrôle. Les places de sortie ont un marquage initial fixé à u. La transition du sous-programme consomme et réinjecte les jetons issus de ces places. Une garde est associée à la transition pour empêcher la consommation de la valeur indéfinie u. Un paramètre d’entrée sortie est traduit par une place d’entrée et une place de sortie. Les paramètres de sortie des sous-programmes modélisent des variables : leur valeur doit pouvoir être lue plusieurs fois, par différents sous-programmes. C’est pourquoi la transition du sousprogramme doit remplacer un jeton qui est constamment à disposition. Le cas d’un appel à un sous-programme distant – dont l’accès est fourni par un autre thread – présente quelques spécificités. En effet, un tel sous-programme met en jeu à la fois le thread local, qui effectue l’appel, et le thread distant, qui exécute effectivement le sous-programme. L’exécution du sous-programme nécessite donc les ressources d’exécution des deux threads. c○ 2007 Thomas Vergnaud 133
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: Modélisation des systèmes temps-r
Page 102 and 103: 13 Modélisation des systèmes temp
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 154 and 155: 15 end sspg_b; Modélisation des sy
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
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Page 200 and 201:
Page 202 and 203:
show all

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

Create successful ePaper yourself

Delete template?

Save as template?