Les connexions AADL se traduisent de différentes façon, selon leur nature. Nous traduisons les connexions AADL représentant une transmission de données par des transitions. Contrairement aux transitions des composants, ces transitions ne correspondent pas à une transformation des données ; elles permettent simplement d’exprimer la coordination de la transmission des données. Par rapport à ce que nous avons indiqué en sectionVII-4.1.2, nous considérons des connexions directes entre les différentes entités de haut niveau de plus fine granularité – c’est-à-dire les threads AADL ou les thread implicites correspondant aux processus ou aux systèmes. Comme les dif- férents composants englobants ne sont pas traduits par les construction en réseau de Petri, les différents ports des composants sont considérés comme étant directement reliés par une seule connexion, au lieu d’une suite de connexions point-à-point comme c’est le cas dans les descrip- tions AADL.
VII-4.2.1 Connexion des accès à composant de donnée
La connexion de sous-composants correspond à une situation simple : la place correspondant à l’instance du composant de donnée considéré doit être assimilé à l’interface offrant ou requérant le sous-composant.
Règle VII.8 (Connexion des accès à sous-composants)
Les connexions aux composants de donnée reviennent à fusionner la place modélisant le composant de donnée considéré avec la place correspondant à l’élément d’interface correspondant.
Nous ne considérons ici que les composants de données. En effet, les bus sont des composants matériels que nous ignorons dans le cadre de notre traduction. Les accès aux sous-programmes seront décrits dans la sectionVII-5.3.
VII-4.2.2 Connexions des ports
Le cas des connexions de ports est plus délicat. En effet, elles font partie intégrante des flux de données que nous souhaitons analyser.
Dans la mesure où nous ne considérons que des connexions directes, il s’agit d’interposer une transition entre les différents ports connectés. Dans le cas de multiples connexions issues d’un seul port de sortie, nous devons exprimer le fait que les données sont dupliquées et envoyées simultanément.
Règle VII.9 (Modélisation des connexions de ports)
La connexion de deux ports AADL se traduit par une transition. Les multiples connexions d’un port de sortie à plusieurs ports d’entrée sont traduites par une seule transition qui modélise la duplication des données transférées.
Une connexion de port d’événement/donnée se traduit par une simple transition. Une connexion de port de donnée se traduit par une transition consommant à la fois le jeton transmis et le jeton placé dans la place de destination. Le jeton précédemment stocké dans la place de destination est ainsi remplacé par le nouveau jeton.
La traduction exacte des connexions AADL diffère selon que nous considérons une connexion de ports d’événement/donnée ou de donnée. En effet, les ports de donnée ne peuvent pas être associés à des files d’attente ; la place correspondante doit donc ne comporter qu’un seul jeton, qui est remplacé lorsqu’une nouvelle donnée arrive. Nous appliquons la même démarche que pour la connexion des éléments d’interface aux composants eux-mêmes (règleVII.6).
La figureVII.3illustre les différentes traductions possibles pour les connexions de ports. Les modélisations des threads sont repérées par des zones grisées.
Le threadthread1possède deux ports de sortie :s1(port d’événement/donnée) ets2(port de
donnée). Ces deux ports sont reliés aux ports d’entrées1ets2du thread thread2par l’intermé-
diaire des connexions cnx1 etcnx2. La connexion cnx1 est une connexion de ports de données,
caractérisée par les doubles connexions entre les transitions et les places. La connexion cnx2est
une connexion de port d’événement/donnée, caractérisée par des connexions simples entre les transitions et les places.
<v1, c1> <c> <c> <c> <c> <v, c> <v2,c2> <v1,c1> <v1,c1> <v, c> <c> <c> <c> <c> <d,c> <d,c> <v, c> <v, c> cnx1 thread2_reset [v1 <> u] thread2 thread2_finish Control thread2_restart Control <2> thread2_e1 Comm <u,2> thread2_e2 Comm Class Value is ["u", "d"]; Control is 1 .. 2; Domain
Comm is <Value, Control>; Var v, v1, v2 in Value; c, c1, c2 in Control; cnx2 thread1_s2 Comm thread1_s1 Comm thread1_finish Control thread1_restart <1> Control thread1 thread1_reset
FIG. VII.3 – Description des connexions en réseau de Petri, correspondant à la figureVII.4
thread2 thread1 s1
s2
e1 e2
FIG. VII.4 – Connexions AADL, traduites par le réseau de la figureVII.3
VII-4.2.3 Optimisation des réseaux générés
Le fait de ne pas considérer les propriétés temporelles des architectures implique que la modé- lisation en réseau de Petri d’un thread émetteur n’a aucune contrainte dans son débit d’émission de jetons. L’architecture décrite au listingVII.2fait apparaître un thread émetteur et deux threads récepteurs. Si le thread émetteur s’exécute à une fréquence plus élevée que les récepteur, les files d’attente des threads récepteur déborderont. Ce scénario d’exécution se traduirait par un réseau de Petri non borné.
Pour pallier ce problème, nous exploitons le fait que nous ignorons délibérément les propriétés temporelles de l’architecture. Nous pouvons alors considérer que les threads sont bien synchro- nisés ; le thread émetteur ne produit une nouvelle donnée que lorsque les précédentes ont été consommées. Cette hypothèse permet de borner le réseau. Sa traduction en terme de construction syntaxique consiste à mettre en place une boucle de rétroaction entre les threads récepteur et les threadsémetteurs.
Règle VII.10 (Jetons modélisant les communications inter-threads)
Les jetons de donnée émis par la transition d’un thread est un couple < d,c > du do- maine Comm, où c appartient à la classe Control et a la valeur correspondant au thread émetteur.
Chaque message émis par un thread porte ainsi la marque de son émetteur. Cela permet de mettre en place un mécanisme d’acquittement à partir du thread récepteur.
1 data donnee
2 end donnee;
3
4 thread thread_a
5 features
6 s : out event data port donnee;
7 properties 8 Dispatch_Protocol => periodic; 9 end thread_a; 10 11 thread thread_b 12 features
13 e : in event data port donnee;
14 properties 15 Dispatch_Protocol => aperiodic; 16 end thread_b; 17 18 process processus_a 19 features
20 s : out event data port donnee;
21 end processus_a;
22
23 process processus_b
24 features
25 e : in event data port donnee;
26 end processus_b;
27
28 process implementation processus_a.impl
29 subcomponents
30 thread1 : thread thread_a;
31 connections
32 cnx1 : event data port thread1.s -> s;
33 end processus_a.impl;
34
35 process implementation processus_b.impl
36 subcomponents
37 thread1 : thread thread_b;
38 thread2 : thread thread_b;
39 connections
40 cnx1 : event data port e -> thread1.e;
41 cnx2 : event data port e -> thread2.e;
42 end processus_b.impl;
43
44 system global
45 end global;
46
47 system implementation global.impl
48 subcomponents
49 process1 : process processus_a.impl;
50 process2 : process processus_b.impl;
51 connections
53 end global.impl;
Listing VII.2 – Exemple de connexion AADL, traduit par le réseauVII.5 Règle VII.11 (Limitation du nombre d’états du réseau)
À chaque transition modélisant un thread recevant des données doit correspondre une place de sortie. Cette place de sortie reçoit les différents jetons de contrôle dont les couleur correspondent à celles des jetons reçu dans les places d’entrée.
Les jetons accumulés dans cette place de sortie sont envoyés vers les placesresetdes
threadsémetteurs afin de réguler leur production de jetons.
La placeresetdu thread émetteur doit donc comporter une garde s’assurant que seul les jetons
de contrôle correspondant à sa couleur sont acceptés. Il est par conséquent nécessaire de définir une couleur de contrôle par thread AADL, comme nous l’avons énoncé dans la règleVII.3.
Notons que dans le cas d’un thread en tâche de fond, cette rétroaction est inutile, puisque le threadconsidéré ne boucle pas ; ces thread ne possèdent d’ailleurs pas de transitionreset.
La figureVII.5donne le réseau de Petri issu de la modélisation du listing VII.2. Les repré- sentations des threads sont repérées par les zones grisées. Les deux connexionscnx1etcnx2 du
processusprocessus_bsont fusionnées en une seule transition lors de la traduction en réseau de
Petri. Nous nommons la transition résultante d’après la concaténation des différents threads im- pliqués :process1_thread1_process2_threads1_process2_thread2. <v,c> <c> <c> <c> <v,c> <c> <c> <c> <d,c> <c> <c> <v,c1> <c1> <c> <c> <c> <c> <v,c1> <c1> <v,c> <c> <c> process1_thread1_process2_thread1_process2_thread2 <1> control process1_thread1_restart control <2> process2_thread1_restart control process1_thread1_end control process2_thread1_end class donnee is [d, u]; control is 1 .. 3; domain
comm is <donnee, control>; var v in donnee; c, c1 in control; comm process1_thread1_s [c = th_1] process1_thread1_reset process1_thread1_start comm process2_thread1_e process2_thread1_reset process2_thread1_start control process2_thread1_choose control process2_thread2_choose process2_thread2_start process2_thread2_reset comm process2_thread2_e control process2_thread2_end control <3> process2_thread2_restart
FIG. VII.5 – Réseau de Petri borné modélisant une architecture de haut niveau correspondant au listingVII.2, page131