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

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