Les interactions externes entre engins

Les interactions externes concernent les communications directes entre les engins robotiques ainsi que le contrˆole sol. La figure 4.5 repr´esente tous les types de messages qui peuvent ˆetre ´echang´es entre les engins du r´eseau.

Ils se d´ecomposent en quatre grandes cat´egories :

– La gestion dynamique du r´eseau. Comme le syst`eme est ouvert, le r´eseau est dynamique et il faut int´egrer des nouveaux engins et g´erer les

Figure 4.5 – Types des messages ´echang´es, li´es aux interactions externes entre engins

d´eparts. Ici sont regroup´es les messages de pr´esentation et description des engins qui arrivent ainsi que ceux informant du d´epart d’un engin. – La gestion de la connaissance qui porte sur l’´etat des services et de la connaissance associ´ee `a chaque engin (ajouter / supprimer un service, mettre `a jour un service, mettre `a jour la connaissance de l’environne- ment).

– L’utilisation des services ainsi que la surveillance de leur ex´ecution et la r´eception de leurs r´esultats.

– La propagation d’objectifs mission et de messages sur le r´eseau afin de soutenir la planification et le travail collaboratif.

Les trois premi`eres cat´egories concernent les interactions directes des mo- dules ISIS entre eux. La derni`ere cat´egorie concerne les contrˆoleurs des archi- tectures logicielles locales des engins, mˆeme si ces messages peuvent transiter via les modules ISIS.

Des protocoles d’´echanges sont associ´es `a ces cat´egories de messages, ils d´ecrivent `a la fois la forme des messages ´echang´es et les actions / r´eactions qui sont li´ees aux diff´erents types de messages.

4.4.3.1 La gestion dynamique du r´eseau

Quand deux engins sont dans la mˆeme zone de communication, `a port´ee radio l’un de l’autre, ils peuvent s’envoyer un message de pr´esentation pour s’identifier et d´ecrire leur capacit´es l’un aupr`es de l’autre. Ce message peut ˆetre initi´e par le contrˆole au sol, qui demande un envoi forc´e du message d’un engin vers tous ses voisins. Mais il peut ´egalement ˆetre cr´e´e et envoy´e automatiquement : si un engin re¸coit un message d’un exp´editeur qui n’est pas dans sa liste de voisins connus, il enverra automatiquement un message de pr´esentation, auquel les autres engins qui le recevront r´epondront par leur propre message de pr´esentation.

Ce type de protocole a l’inconv´enient de g´en´erer beaucoup de messages et, dans un r´eseau de nombreux engins, il pourrait y avoir un risque de sur- charge des communications. Il faudrait alors mettre en place des strat´egies de propagation de l’information pour limiter les messages.

Ces strat´egies pourraient consister en la limitation des messages `a un certain nombre de sauts de nœuds sur le r´eseau par exemple, ou en dur´ee de validit´e (on ne propage pas une information qui a plus de xx minutes).

Un autre type d’utilisation des interactions externes pourrait ˆetre la mise en place de routines de surveillances (ou ”watchdog”). Par exemple, si un

engins n’a pas re¸cu de messages du contrˆole sol depuis X temps, il peut d´ecider de se mettre en mode survie pour attendre un retour `a la normale de la situation.

4.4.3.2 La gestion de la connaissance

Quand les caract´eristiques d’un service ou d’un ´el´ement de la connais- sance ´evoluent au sein d’un engin, le module ISIS g´en`ere automatiquement un message de mise `a jour qui est ”broadcast´e” `a tous les engins voisins, qui modifieront alors leur propre connaissance en fonction. Un engin peut ´egalement demander `a un autre la mise `a jour d’une partie pr´ecise de la connaissance (carte, service, partie d’un service ou partie de la description d’un engin qu’il n’avait pas encore...).

Par exemple, si un engin d´etecte une panne interne qui lui rend impossible l’ex´ecution de certains services, il va mettre `a jour sa liste de services et ensuite notifier le module ISIS qui va propager cette information, via les m´ecanismes de mise `a jour de la connaissance.

De mˆeme si un engin n’est plus disponible (mission prioritaire, autorisa- tions modifi´ees ...), il va en informer ses voisins, pour que ceux-ci puissent mettre `a jour leurs bases de connaissance en cons´equence.

De mani`ere indirecte, si un engin ne r´epond plus aux messages qui lui sont adress´es, il sera automatiquement consid´er´e comme hors service par les autres engins.

Bien qu’importants, les probl`emes de consistance de la connaissance et de qualit´e de l’information ne seront pas abord´es et devront faire l’objet d’´etudes sp´ecifiques. Que ce soit `a cause de l’envoi par un engin d’une infor- mation fausse (mauvaise acquisition d’un capteur, bug...) ou bien `a cause de la perte d’un message de mise `a jour de la connaissance, un ou plusieurs en- gins peuvent se retrouver avec une croyance de l’´etat de leur environnement qui est fausse.

4.4.3.3 L’utilisation des services

Quand un engin d´ecide d’utiliser un service, il va devoir en informer l’en- gin fournisseur du service. Il peut alors invoquer directement le service en fournissant les donn´ees n´ecessaires.

De son cot´e l’engin fournisseur du service va accuser r´eception de la de- mande et valider l’ex´ecution ou la r´eservation du service, via son architecture de contrˆole, ou bien il va la refuser, en renvoyant un message d’incapacit´e ou

d’indisponibilit´e, s’il ne peut pas satisfaire celle-ci.