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

More documents

Recommendations

Info

Modélisation des systèmes temps-réel répartis embarqués du processus et du système global. Nous retrouvons les éléments de la description de haut niveau des threads : les transitions thread2_begin et thread2_end correspondent à la transition de traitement du thread, les places thread2_c_begin et thread2_c_end demeurent celles de la modélisation de haut niveau, de même que la transition thread2_init. Il en est de même pour thread1. Les deux séquences d’appels de thread2 sont délimitées par des transitions begin et end ; il s’agit du même principe que pour les transitions encadrant le contenu des threads. La transition thread2_appel1_appel2 permet de connecter les deux appels de sous-programme thread2_appel1 et thread2_appel2 ; elle centralise les différentes connexions AADL vers les paramètres de l’appel thread2_appel2. VII-6 Intégration des descriptions comportementales Comme nous l’avons expliqué au chapitre III, AADL décrit les aspects architecturaux des systèmes, c’est-à-dire principalement l’agencement des composants ; les aspects algorithmiques sont en dehors du cadre des modélisations. De la même façon que pour la génération de code (cf. chapitre V) une description comportementale des composants en réseau de Petri doit pouvoir être fournie ; elle doit correspondre à l’implantation en code source. Par conséquent, seuls les sous-programmes peuvent avoir une telle description comportementale. De la même façon qu’au chapitre V, nous distinguons quatre cas de sous-programmes : VII-6.1 Composant sans modélisation comportementale En l’absence d’éléments complémentaires, la modélisation d’un composant est celle que nous avons décrite en section VII-4. Règle VII.20 (Traduction d’un composant sans modélisation comportementale) Un composant sans modélisation comportementale est traduit par une simple transition. VII-6.2 Composant possédant une description comportementale Dans le cas d’un composant simple, l’introduction d’une modélisation comportementale consiste à substituer la transition centrale par le réseau de Petri modélisant le comportement du composant. Règle VII.21 (Traduction d’un composant dont l’implantation est opaque) Le sous-réseau de Petri modélisant le comportement d’un sous-programme doit comporter une place de départ begin et une place de fin end. La transition représentant le corps du sous-programme composant est transformée en deux transitions composant_begin et composant_end. composant_begin est reliée à la place begin ; la place end est reliée à la transition composant_end. Le sous-réseau comportemental doit faire apparaître les différentes places correspondant aux paramètres du sous-programme ; ces places sont reliées aux transitions composant_begin et composant_end. Le réseau de Petri de la modélisation comportementale des composants doit faire apparaître les places initiales et finales. De cette façon, il est possible de fusionner les places contenues dans la description comportementale avec celles générées automatiquement à partir de la description AADL. La description fournie par l’utilisateur doit reprendre les noms de places utilisées dans la description AADL. 140 c○ 2007 Thomas Vergnaud
Chapitre VII – Vérification formelle de la structure des applications VII-6.3 Séquence d’appel pure Dans le cas où un composant (sous-programme ou thread) est constitué seulement d’une séquence d’appel, nous considérons que cette séquence décrit complètement le comportement du composant – nous suivons donc les mêmes hypothèses que pour la génération de code. Le réseau de Petri issu de la séquence constitue alors la description comportementale du composant. VII-6.4 Composant hybride Lorsque la description AADL d’un composant comporte plusieurs séquences d’appel, toutes les combinaisons d’exécutions sont possibles. Contrairement à la génération de code, qui génère les séquences possibles mais n’en exécute aucune par défaut, nous avons vu en section VII-5.3 que la traduction en réseau de Petri permet de représenter tous les scénarios d’exécutions possibles. Dans un cas comme dans l’autre, il est nécessaire d’adjoindre une description comportementale pour indiquer dans quel ordre et sous quelles conditions les séquences doivent s’exécuter. Le réseau de Petri comportemental décrit alors la circulation du jeton de contrôle à travers les séquences. Afin de pouvoir en effectuer un traitement automatique, les places et les transitions du réseau comportemental doivent respecter certaines règles de nommage : Règle VII.22 (Descriptions comportementales pour les sous-programmes hybrides) La description de l’enchaînement des séquences d’appel à exécuter est constituée d’un réseau de Petri dont la première place doit s’appeler begin et la dernière place end. Les séquences d’appel qui doivent être exécutée sont représentées par des transition dont le nom correspond au nom AADL des séquences à coordonner. La description complète du composant s’obtient par fusion des transitions avec les sousréseaux des séquences. Règle VII.23 (Coordination des séquences d’appel) La coordination des séquences d’appel d’un sous-programme composant est effectuée par la fusion des transitions de la description comportementale avec les séquences correspondantes. Les places begin et end du réseau comportemental sont reliées aux transitions composant_begin et composant_end. Les transitions composant_begin et composant_end ont été définies dans la règle VII.17. 1 subprogram sspg_a 2 features 3 e : in parameter; 4 end sspg_a; 5 6 subprogram sspg_b 7 features 8 e : in parameter; 9 calls 10 seq1 : {appel1 : subprogram sspg_a;}; 11 seq2 : {appel2 : subprogram sspg_a;}; 12 connections 13 parameter e -> appel1.e; 14 parameter e -> appel2.e; c○ 2007 Thomas Vergnaud 141
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 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 202 and 203:
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?