Modélisation des systèmes temps-réel répartis embarqués pour la ...
Modélisation des systèmes temps-réel répartis embarqués pour la ...
Modélisation des systèmes temps-réel répartis embarqués pour la ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Modélisation</strong> <strong>des</strong> <strong>systèmes</strong> <strong>temps</strong>-<strong>réel</strong> <strong>répartis</strong> <strong>embarqués</strong><br />
IV-5.3 Description <strong>des</strong> modèles de répartition<br />
Les modèles de distribution sont décrits par les éléments d’interface fournis par les threads<br />
AADL. La modélisation fait apparaître une distinction entre les threads qui reçoivent et ceux<br />
qui envoient les données. La politique de déclenchement d’un thread récepteur est typiquement<br />
apériodique ; ils sont alors déclenchés à <strong>la</strong> réception de données. La politique de déclenchement<br />
<strong>des</strong> threads émetteurs est en général périodique ou sporadique.<br />
IV-5.3.1 Passage de message<br />
Les architectures basées sur une communication par passage de messages sont traduites par<br />
<strong>la</strong> présence de ports associés aux threads AADL. Nous pouvons considérer les trois catégories de<br />
ports (événement, donnée, événement/donnée) ; chacune d’elles correspond à un certain type de<br />
message.<br />
Typiquement, un message apporte deux informations : <strong>la</strong> donnée effectivement transportée<br />
et le fait que le thread doit être activé. Ce genre d’information correspond aux ports d’événement/donnée.<br />
Ces ports permettent de modéliser <strong>la</strong> gestion de messages synchrones qui peuvent<br />
déclencher le thread récepteur. La plupart <strong>des</strong> applications basées sur le passage de messages sont<br />
donc modélisées à l’aide de ces ports.<br />
Les ports de donnée permettent de modéliser les communications asynchrones. Dans cette situation,<br />
le message ne déclenche le thread récepteur ; <strong>la</strong> politique de déclenchement associée est<br />
a priori périodique ou sporadique. Cependant, le thread récepteur peut être déc<strong>la</strong>ré apériodique si<br />
l’application utilise par ailleurs <strong>des</strong> ports d’événement/donnée. Dans ce cas, le thread sera déclenché<br />
à l’arrivée du message synchrone et lira les données sur tous les ports.<br />
Les ports d’événement permettent de modéliser <strong>la</strong> transmission d’un signal simple entre deux<br />
nœuds, sans aucune donnée. Ce genre de port permet par exemple de modéliser <strong>la</strong> transmission<br />
d’un signal d’interruption (par exemple. un top d’horloge). Les threads offrant <strong>des</strong> ports d’événement<br />
en entrée sont typiquement apériodiques, étant donné que le seul usage d’un port d’événement<br />
est le déclenchement de threads.<br />
Spécification IV.2 (Communications par passage de message)<br />
Les ports d’événement/donnée permettent de modéliser une architecture basée sur le<br />
passage de messages. Les ports de donnée permettent de modéliser <strong>des</strong> transmissions de<br />
données asynchrones.<br />
Le listing IV.10 donne un exemple d’architecture AADL modélisant un client pouvant envoyer<br />
<strong>des</strong> messages à un serveur.<br />
1 thread a_client<br />
2 features<br />
3 out_msg : out event data port;<br />
4 end a_client;<br />
5<br />
6 thread implementation a_client.impl<br />
7 properties<br />
8 dispatch_protocol => periodic;<br />
9 period => 10 s;<br />
10 end a_client.impl;<br />
11<br />
12 thread a_server<br />
13 features<br />
66 c○ 2007 Thomas Vergnaud