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

100 connections
Chapitre VIII – Mise en pratique
101 event data port noeud1.s -> noeud2.e;
102 event data port noeud2.s -> noeud1.e;
103 properties
104 Actual_Processor_Binding => reference processeur applies to
noeud1;
105 Actual_Processor_Binding => reference processeur applies to
noeud2;
106 end Client_Serveur.i2;
Listing VIII.10 – Configuration alternative de l’application de test
L’analyse du réseau de Petri correspondant fait immédiatement apparaître que le marquage
initial est bloqué, traduisant le fait qu’en l’absence du processus initiateur, les deux processus de
l’architecture ne se déclenchent pas.
VIII-4 Conclusion
Ce chapitre a été consacré à l’évaluation de notre approche de génération.
Au cours de nos travaux nous avons développé une application, Ocarina, qui implante les
différentes transformations que nous avons décrites aux chapitres V, VI et VII. Ocarina constitue
donc un compilateur pour AADL.
Pour mesurer les performances d’exécution, nous avons comparé une application AADL simple
et différentes contreparties basées sur CORBA. Pour pouvoir établir facilement une comparaison,
nous avons dû nous placer dans un contexte correspondant à une utilisation classique de CORBA.
Cette situation se révèle en l’occurrence défavorable à l’utilisation d’AADL ; notre application
AADL est donc légèrement moins efficace. Nos mesures doivent donc être considérées comme
une évaluation d’un pire cas.
Une architecture « naturelle » pour AADL, mise en place avec CORBA ou tout autre implantation
d’intergiciel impliquerait le développement d’une couche logicielle pour synchroniser l’arrivée
des données des ports, semblable à celle que nous avons présentée en section VI.1, page 102,
et qui constitue la personnalité AADL pour PolyORB. Le développement d’une telle application
pour PolyORB/CORBA serait donc nécessairement plus coûteuse qu’une solution basée sur la
personnalité AADL, puisqu’elle ajouterait les traitements de la personnalité CORBA à la couche
de synchronisation.
La génération de réseau de Petri permet de mettre en évidence certaines propriétés structurelles
comme le blocage des architectures. Le nombre d’état des réseaux produits dépend à la fois du
nombre de threads AADL et de leur inter-connexions ; il est assez difficile de prévoir le nombre
d’états.
L’étude d’une architecture de grande taille nécessite a priori un travail de préparation afin de
réduire la modélisation AADL, tout en conservant la sémantique d’exécution. Certaines opérations
de réduction peuvent effectuées de façon systématique ; d’autres s’appuient sur des caractéristiques
remarquables de l’architecture considérée.
Nous avons étudié ici un système dans lequel les threads étaient fortement couplés, ce qui a
permis de simplifier considérablement l’architecture. Nous n’avons cependant pas eu à prendre en
compte les séquences d’appels de l’implantation des threads, qui auraient généré beaucoup d’états.
Dans une situation moins favorable, il peut être nécessaire de ne considérer que des sous-parties
de l’architecture.
c○ 2007 Thomas Vergnaud 169