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

Chapitre VI – Construction et configuration de l’interface avec l’intergiciel d’exécution
11 Request : in parameter Ipao::Request;
12 Buffer : requires data access Buffer;
13 end Add_Request;
14
15 subprogram Exec_Request
16 features
17 Buffer : requires data access Buffer;
18 end Exec_Request;
19 end Ipao::Activation;
VI-3.4.7 Exécution
Listing VI.8 – Modélisation du service d’activation
Dans l’architecture schizophrène, le service d’exécution s’occupe d’attribuer une tâche (thread
système) au sous-programme applicatif approprié. La tâche utilisée peut être soit une tâche prêtée
temporairement à l’intergiciel par l’application, soit une tâche propre à l’intergiciel.
Dans le cas d’une modélisation en AADL, toutes les ressources d’exécutions sont connues
au moment de générer l’intergiciel ; le service d’exécution n’a donc pas de traduction à proprement
parler en terme de composant AADL, et nous pouvons considérer qu’il est confondu avec le
service d’activation.
VI-3.4.8 Le µBroker
Les services sont coordonnés par un composant central [Hugues, 2005] appelé µBroker, qui
gère les threads supportant l’exécution des services de communication. L’utilisation d’un intergiciel
de bas niveau revient donc à modéliser les services en AADL tandis que l’exécutif en lui-même
correspond à l’implantation du µBroker.
Le µBroker coordonne l’exécution des différents services. Il s’agit donc essentiellement d’une
machine à état. En conséquence, il est modélisé par un sous-programme pouvant appeler les différents
sous-programmes des services schizophrènes. Ce sous-programme a accès à un composant
de donnée AADL qui stocke l’état du µBroker.
Les services à coordonner dépendent de la nature des requêtes à prendre en charge. Deux cas
doivent être considérés : une requête venant d’une entité locale ou du réseau. La réception d’une
requête à partir du réseau s’effectue en deux phases : d’abord la réception de la requête et ensuite
son traitement par le service de liaison. Pour une requête émise par une entité locale, il n’y a qu’une
seule phase, qui est l’invocation du service de liaison. Les requêtes issues d’une entité locale sont
modélisées par des séquences d’appel dont l’origine est située dans les entités applicatives.
L’implantation du sous-programme du µBroker décrit les différentes séquences d’appels possibles.
Le listing VI.9 illustre une implantation générique du µBroker pour un nœud applicatif de
serveur, n’ayant qu’une seule personnalité protocolaire.
1 package Ipao:Mubroker
2 public
3 data Mubroker_State
4 end Mubroker_State;
5
6 subprogram Mubroker
7 features
c○ 2007 Thomas Vergnaud 115