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

More documents

Recommendations

Info

donnee (a) donnée Modélisation des systèmes temps-réel répartis embarqués Control e_1 e_2 thread s_1 (b) thread périodique, apériodique ou sporadique Control e_1 e_2 thread s_1 (c) thread en tâche de fond FIG. VII.2 – Modélisation en réseaux de Petri de composants AADLi, décrit au listing VII.1 1 data donnee 2 end donnee; 3 4 thread thread1 5 features 6 e_1 : in data port; 7 e_2 : in event data port; 8 s_1 : out data port; 9 properties 10 Dispatch_Protocol => perdiodic; 11 end thread1; 12 13 thread thread2 14 features 15 e_1 : in data port; 16 e_2 : in event data port; 17 s_1 : out data port; 18 properties 19 Dispatch_Protocol => background; 20 end thread2; Listing VII.1 – Exemples de déclarations de composants AADL, traduites en réseaux de Petri sur la figure VII.2 VII-4.1.1 Traduction des composants de donnée Nous distinguons les composants de données des autres composants logiciels. Règle VII.4 (Traduction des composants de donnée) Une instance de composant de donnée est traduite par une place. Nous sommes ainsi cohérents avec la règle VII.1 : un composant de donnée ne donne pas lieu à une opération de traitement et ne peut donc pas contenir de transition. Les déclarations de composant de donnée AADL ne sont pas traduites dans le réseau, puisque celui-ci ne rend compte que des entités instanciées. Par ailleurs, contrairement à la traduction en langage de programmation, nous ne nous intéressons pas à la sémantique des données : toutes les déclarations de données sont donc considérées équivalentes vis-à-vis des flux d’exécution. La vérification de la cohérence des types doit être réalisée par ailleurs. 126 c○ 2007 Thomas Vergnaud
Chapitre VII – Vérification formelle de la structure des applications VII-4.1.2 Traduction des composants « actifs » Tous les composants autres que les données recueillent des données en entrée, les traitent et produisent des données en sortie. Les figures VII.2(b) et VII.2(c) illustrent les modélisations correspondant aux différents composants AADL considérés. Règle VII.5 (Traduction des types de composants) Les composants « actifs » de haut niveau (systèmes, processus, threads) d’une architecture sont traduits par une transition (représentant le composant lui-même) entourée de places modélisant ses éléments d’interface. Cette approche assure la cohérence du formalisme vis-à-vis de la syntaxe AADL : en effet, les ports des composants – que nous modélisons en réseaux de Petri par des places – sont typiquement associés à une déclaration de composant de donnée. Un composant de donnée est donc toujours représenté par une place, qu’il s’agisse d’une instance – c’est-à-dire un sous-composant – ou d’un élément d’interface. Notons que cette modélisation de haut niveau implique qu’un composant a besoin de recevoir des données sur tous ces ports pour s’exécuter. Pour les threads, cette hypothèse correspond aux spécifications que nous avons définies au chapitre IV ; ce n’est en revanche pas le cas pour les autres composants, tels que les systèmes. En l’absence d’information sur la structure interne du composant considéré, cette hypothèse, bien que forte, est cependant assez naturelle et permet une modélisation systématique. Afin de systématiser la traduction, nous créons une place par élément d’interface. De cette façon, il est notamment possible d’appliquer éventuellement des traitement différents à chaque élément d’interface lors de la génération du réseau de Petri – par exemple des fusions de places. Règle VII.6 (Traduction des éléments d’interface) Chaque élément d’interface est traduit par une place reliée à la transition représentant le composant considéré. Un port d’entrée d’événement/donnée ou un accès à un sous-composant de donnée est traduit par une place connectée à la transition du composant. Un port d’entrée de donnée est traduit par une place dont le marquage initial est u. La transition du composant consomme le jeton de cette place et le restitue. La transition du composant comporte une garde l’empêchant de se déclencher avec un jeton de couleur u. Tous les ports de sortie sont traduits par une place de sortie reliée à la transition du composant. Les ports d’entrée/sortie sont assimilés à un couple de ports, l’un en entrée, l’autre en sortie. Toutes les places représentant un port sont du domaine Comm. Les accès aux bus ou aux sous-programmes ne sont pas traduits. Un port de donnée ne comporte pas de file d’attente ; une donnée stockée dans un tel port n’est donc pas consommée : elle est seulement lue. Le marquage initial des places correspondantes correspond à la valeur indéfinie u afin d’empêcher le composant de se déclencher avec ce qui correspond en fait à une absence de valeur. Nous ne traduisons pas les accès aux bus car ces composants ne sont pas pris en considération dans notre traduction. La prise en charge des accès à sous-programmes sera étudiée dans la section VII-5.3. c○ 2007 Thomas Vergnaud 127
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: Modélisation des systèmes temps-r
Page 90 and 91: 17 end sp.impl; Modélisation des s
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 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 188 and 189:
Page 190 and 191:
Page 192 and 193:
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 ...

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

Delete template?

Save as template?