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

More documents

Recommendations

Info

VIII-3.1 Motifs AADL de base Modélisation des systèmes temps-réel répartis embarqués Nous nous sommes dans un premier temps intéressés au calcul du nombre d’état pour des configurations de threads simples. Nous avons pour cela étudié différents assemblages de threads AADL, qui sont synthétisés sur le tableau VIII.2. configuration d’architecture nombre d’états du réseau TAB. VIII.2 – Nombre d’états du réseau de Petri correspondant à diverses configurations architecturales Les deux premières architectures n’ont pas le même nombre d’états, bien qu’elles soient constituées du même nombre de threads et de connexions. Par ailleurs, trois architectures ont le même nombre d’états alors que leur configuration est différente. Aucun calcul simple ne permet donc de prévoir le nombre exact d’états correspondant à une architecture donnée à partir du nombre de threads, dans la mesure où il dépend en grande partie de l’agencement des différents éléments. La dernière architecture fait apparaître un cycle dans le flux de données. Le réseau de Petri correspondant ne contient qu’un seul état ; le réseau est bloqué. Cette situation peut être interprétée de deux façon, selon la nature des threads que nous considérons. S’il s’agit de threads périodiques, alors le blocage du réseau traduit le fait que le premier thread à se déclencher utilisera une donnée dont la valeur est indéterminée, ce qui peut entraîner des erreurs dans l’application modélisée. Si les threads sont apériodiques, alors aucun d’eux ne se déclenchera, puisqu’aucun d’eux ne recevra de donnée au démarrage de l’application. Le nombre d’état du réseau de Petri correspondant à une modélisation AADL est difficile à prévoir ; il a cependant tendance à croître avec le nombre de threads et de connexions. Un nombre d’états relativement faible dans une architecture complexe peut traduire la présence de blocages dans la totalité ou une partie de l’architecture. 24 32 32 32 1 166 c○ 2007 Thomas Vergnaud
VIII-3.2 Exemple de taille réelle Chapitre VIII – Mise en pratique La section précédente a permis d’évaluer le nombre d’état générés pour différents assemblages de composants. Nous nous intéressons maintenant à une modélisation de taille réelle afin d’évaluer la viabilité de la transformation en réseaux de Petri. AADL étant un langage encore assez récent, peu de descriptions d’architectures sont accessibles publiquement. Par ailleurs, la plupart d’entre elles ne prennent pas en considération la problématique de la génération automatique d’application ; elles représentent des constructions qui ne correspondent pas aux spécifications d’exécutif que nous avons faites au chapitre IV. Les exemples réellement exploitables sont donc à l’heure actuelle peu nombreux. VIII-3.2.1 Description de l’architecture Nous prenons comme objet d’étude la modélisation d’un système d’affichage d’une cabine de pilotage d’avion [Statezni, 2004]. Cette architecture est composée de 90 threads s’exécutant sur 13 processeurs. La modélisation AADL qui en a été faite avait pour objectif de démontrer la viabilité d’AADL comme langage de description. Cette modélisation fait 21000 lignes ; elle constitue donc un exemple significatif en terme de taille d’architecture. Il s’agit d’une modélisation de haut niveau, ne comprenant que la description du déploiement des threads AADL sur les processus. La description des composants applicatifs n’est pas abordée ; les différentes propriétés dont nous avons présenté la vérification en section VII-7 ne peuvent donc pas être vérifiées, puisque la description architecturale n’est pas assez précise. VIII-3.2.2 Expérimentations Nous exploitons la description AADL pour générer le réseau de Petri correspondant aux flux d’exécution entre les différents threads de l’architecture. L’application de nos règles de traduction produit un réseau constitué de 1564 places, 572 transitions et 2576 arcs. Il fait intervenir 166 variables de contrôle ; ces variables découlent du fait que certains threads possèdent de nombreux ports d’entrée. Ce grand nombre de variables entraînent la génération d’un trop grand nombre d’états, ce qui sature les outils actuels. Il est donc impossible d’analyser une telle architecture avec les techniques actuelles. Pour pouvoir analyser l’architecture, il est nécessaire de la réduire, tout en préservant sa sémantique vis-à-vis de la transformation en réseau de Petri. Nous nous appuyons pour cela sur la sémantique d’exécution que nous avons associée aux threads AADL : un thread lit toutes ses données d’entrée, effectue un traitement puis émet toutes ses données de sortie. L’architecture que nous étudions se caractérise par la présence de threads possédant de nombreux ports d’entrée et de sortie. Nous exploitons cette caractéristique, dans le cadre de la sémantique d’exécutif que nous avons définie, pour réduire la taille du réseau généré. Première réduction En section VII-3, page 125, nous avons établi que tous les types de données étaient confondus lors de la transformation en réseau de Petri. Tous les ports des threads sont donc considérés comme étant associés à un unique composant de donnée. Par ailleurs, selon la règle IV.6, énoncée en page 69, un thread AADL émet toutes les données sortantes en même temps, à la fin de son exécution. c○ 2007 Thomas Vergnaud 167
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:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
autre nœud Modélisation des syst
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
10 features Modélisation des syst
Page 126 and 127:
VI-3.4.6 Activation Modélisation d
Page 128 and 129: Modélisation des systèmes temps-r
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
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?