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

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