Nous avons vu que les niveaux supérieurs (superviseur global et superviseurs locaux) gèrent le lancement et l'arrêt des objectifs et des sous-objectifs. Le lancement et l'arrêt de ces derniers se fait selon certains événements soit décrits par l'utilisateur soit imposés (ex : entrée d'eau, énergie faible,...) et surveillés par les superviseurs concernés.
Lorsque le superviseur global reçoit une mission, il consulte une base de données ( - gure 6.6) qui contient la liste des objectifs à lancer pour exécuter la mission donnée. Cette liste se compose des conditions de lancement de chaque objectif ainsi que de ses conditions d'arrêt.
6.4 Approche synchrone/asynchrone
Figure 6.13 Décomposition contextuelle des objectifs
Format général d'une mission :
[condition de lancement] nom objectif 1 [condition d'arrêt]
[condition de lancement] nom objectif 2 [condition d'arrêt]
...
[condition de lancement] nom objectif n [condition d'arrêt]
De manière analogue, les superviseurs locaux consultent une base de données qui contient la décomposition des objectifs en sous-objectifs accompagnés de leurs conditions de lancement et d'arrêt.
Une condition de lancement (resp. d'arrêt) pour un objectif ou pour un sous-objectif représente les conditions à satisfaire pour déclencher (resp. arrêter) l'objectif ou le sous- objectif concerné. Ces conditions concernent l'état interne ou externe (environnement) du système robotique commandé ainsi que le temps. L'état du véhicule est traduit par les capteurs (proprioceptifs et extéroceptifs) présents à bord. Les modules superviseurs ont alors besoin de pouvoir analyser les données de ces capteurs a n de pouvoir évaluer ces équations logiques.
Cependant ces modules n'ont pas directement accès à l'instrumentation de bord, d'autres modules sont dédiés à cela et l'utilisation de ces capteurs (dans le cas où ils seraient interférents) est soumise à des règles que seul l'ordonnanceur bas niveau est en mesure d'appliquer. D'autre part, les états du système à surveiller sont discrets, ils peuvent être détectés dans un ux continu de données. Par exemple si l'on veut détecter l'état : "obstacle en vue", nous n'avons pas besoin de toutes les valeurs du capteur de distance mais seulement d'une information ponctuelle qui indiquera le passage de cette valeur en dessous/dessus d'un certain seuil. On appellera ce type d'information "un événement".
Chapitre 6 : Construction d'une architecture logicielle
Figure 6.14 Architecture logicielle de commande
Ainsi l'analyse des événements produits par les modules bas niveau de l'architec- ture permet de connaître l'état du véhicule. Cela suppose d'une part que le superviseur concerné s'abonne à l'événement auprès du module bas niveau qui le produit et d'autre part que ce module soit en activité.
En plus des événements d'état générés par les modules bas niveau, les équations lo- giques vont aussi comporter des événements de temps. Pour une mission, on pourra in- diquer dans les conditions de lancement des objectifs qui la composent, des événements de temps avec comme référence le début de la mission. Par contre les conditions d'arrêt peuvent aussi contenir des événements de temps, mais avec comme référence le début de l'objectif.
Nous avons vu au chapitre 5 que les événements étaient produits par des modules à des ports spéci ques, si bien qu'un nom de module accompagné d'un numéro de port peut identi er un événement précis au sein de l'architecture. La dé nition d'une mission par exemple sera de la forme suivante :
Mission :
[nomModule :Nport ⊗ nomModule :Nport ⊕ temps=α s] nom objectif 1 [duree=η s ⊕ nomModule2 :Nport x date=γ s] [nomModule :Nport ⊕ temps=δ s] nom objectif 2 [temps=τ s ⊕ nomModule2 :Nport]
...
Les opérateurs "⊕" et "⊗" utilisés dans les équations logiques vont traduire respective- ment l'alternative et la simultanéité de deux événements. En ce qui concerne l'alternative, l'équation 6.1 signi e que l'équation donnera un résultat vrai si l'un des deux événements vient de se produire. Par contre pour la relation "simultanéité" (équation 6.2), donnera un résultat vrai lorsque les deux événements evt1 et evt2 se produisent, qui elle n'est jamais véri able (la simultanéité n'existant pas en événementiel).
6.4 Approche synchrone/asynchrone
Figure 6.15 Interférence entre les capteurs acoustiques
evt1 ⊕ evt2 (6.1)
evt1 ⊗ evt2 (6.2)
En eet, les modules du niveau supérieur de l'architecture fonctionnent de façon évé- nementielle, c'est à dire que les traitements sont engagés dès qu'un événement est reçu (nouvelle mission, nouvel objectif, événement provenant d'un module ou événement de temps). Donc l'équation logique sera évaluée dès la réception du premier événement (evt1) puis réévaluée à la réception du second. A la réception de l'un, l'autre n'est pas encore reçu (ou du moins pas encore traité) ce qui fait que les équations comportant un "et" logique seront toujours fausses.
Il y a des cas, pourtant où l'on voudrait exprimer une simultanéité entre deux évé- nements. Si nous prenons l'exemple d'un véhicule sous-marin qui doit faire des relevés topographiques de la surface d'une source d'eau douce sous-marine. Les relevés devant être faits au delà d'une certaine profondeur. Nous voudrions alors que l'objectif relevé topographique soit lancé une fois que la profondeur dépasse une valeur donnée et que la salinité (détection de la zone d'eau douce) descend en deçà d'une certaine valeur. Les événements "seuil de profondeur atteint" et "seuil de salinité atteint" ne seront pas reçus simultanément.
Pour traduire l'idée intuitive qu'on se fait de la simultanéité des événements, on doit pouvoir faire persister les événements sur lesquels on veut raisonner. On devra alors pré- ciser sur les événements liés par un "et" logique, la condition de n de persistance. Cette dernière pouvant être une durée ou un autre événement.
Dans l'équation 6.3, l'événement "evt1" sera mémorisé 5s après sa réception. Si l'"evt2" est reçu dans les 5 secondes après la réception de l'événement "evt1", l'équation 6.3 sera
Chapitre 6 : Construction d'une architecture logicielle vraie. Dans l'équation 6.4 la n de persistance de l'événement "evt2" est signalée par l'événement "evt3".
evt1(5s) ⊗ evt2 (6.3)
evt1 ⊗ evt2(evt3) (6.4)