Gestionnaire d’interactions : mise en œuvre partielle

Nous d´ecrivons dans cette sous-section les tests r´ealis´es avec le gestionnaire d’interactions : d’abord d´econnect´e du reste du syst`eme (tests internes ou “unitaires”). Puis avec le reste des ´el´ements de la couche d´elib´erative.

Tests du gestionnaire d’interaction seul

Nous nous sommes attach´es `a tester dans un premier temps les principales fonctionnalit´es et m´ecanismes du GI, sans interfacer celui-ci avec le reste de la CD. Ces tests ont donc concern´e la mod´elisation de tˆache jointe avec les mod`eles d’interaction, l’activation et le traitement d’un mod`ele d’interaction, la mod´elisation et la v´erification de contraintes spatiales actives, et la mise en œuvre et le traitement de modalit´es de n´egociations ´el´ementaires.

Nous d´ecrivons bri`evement ici les tests r´ealis´es pour valider le fonctionnement des diff´erents traitements dans le GI :

– Description d’un mod`ele d’interaction : nous avons en premier lieu v´erifi´e la coh´erence des structures et relations entres structures pour d´efinir un mod`ele d’interaction. Nous avons ´ecrit plusieurs rˆoles factices, plusieurs mod`eles de contraintes spatiales, et mis en relations ces donn´ees au sein d’une table de coordination, pour obtenir une variante de mod`ele d’interaction applicable.

– M´ecanismes de traitement de MI : le moteur de traitement du GI a ´et´e ´eprouv´e en ef- fectuant des op´erations de chargement de MI (voir la m´ecanique du GI, section V.4), puis en d´emarrant v´eritablement le traitement du rˆole pr´eselectionn´e dans la phase de chargement. Le moteur de traitement fonctionne de la fac¸on pr´evue.

– Mod`eles de contraintes spatiales : nous avons v´erifi´e le fonctionnement du VCS en d´efinissant des contraintes spatiales d’orientation et de distance sur un rˆole actif (en cours de traitement), et d´ependant de donn´ees (positions de points dans l’espace) r´ecup´er´ees `a partir de l’observateur : les donn´ees observ´ees correspondent `a des coordonn´ees de points mises `a jour `a travers le medium de communication BBCS. Il s’agit par exemple de positions d’UAV ou position d’alarmes d’incendie simul´ees, et dynamiquement mises `a jour en cours. Nous avons pu nous assurer de la g´en´eration d’un ´ev´enement de “viol de contraintes spatiales”, lorsqu’il advient qu’un mod`ele de contraintes spatiales impos´es ne soient plus satisfait dans le contexte courant d’ex´ecution (suite `a l’´evolution des objets observ´es dans l’environnement).

– Modalit´es de n´egociation : le gestionnaire de n´egociations fournit des capacit´es d’envoi de messages entre UAV, avec un support pour des informations de types diff´erents : chaˆıne de caract`ere, valeurs num´eriques, temporelles, mais aussi des informations g´eom´etriques comme des points. Une modalit´e de n´egociation doit donc d´efinir la nature des donn´ees `a ´echanger, et la s´emantique, dans le cadre de cette modalit´e, que les UAV impliqu´es doivent attacher aux informations. Dans le test mis en œuvre, nous nous sommes content´es de d´efinir un choix de rˆole sur une base al´eatoire : en cas de conflit sur les rˆoles s´electionn´es, l’un des deux choisit al´eatoirement parmi les autres rˆoles disponibles. Il s’agit bien entendu d’une modalit´e tr`es ´el´ementaire destin´ee `a tester l’application et le traitement d’une action de coordination dans le traitement des rˆoles. Des modalit´es beaucoup plus riches et pertinentes devraient ˆetre conc¸ues et d´evelopp´ees dans le cadre d’applications r´eelles.

Remarque sur la conception de mod`eles d’interaction : Le formalisme que nous avons mis au point est riche, mais se prette assez peu `a une description “ligne `a ligne” par un concep- teur : il n´ecessite en effet la d´efinition d’un nombre important de symboles repr´esentant les componels, les sources d’informations, les ´ev´enements, et les liens entre les diff´erentes donn´ees. En revanche, il est tout `a fait vraisemblable d’imaginer une interface graphique de conception de mod`eles d’interactions : des associations entre entit´es `a base de “drag’n drop” et des pointages `a la souris dans une repr´esentation de l’environnement, paraissent tout `a fait plausibles pour d´efinir `a un haut niveau et assez intuitivement les donn´ees requises pour la d´efinition de mod`eles d’interaction.

Premiers tests int´egr´es

Dans un second temps, nous avons r´ealis´e des tests d’int´egration du GI au sein d’une couche d´elib´erative : il s’agit l`a encore de tests restreints, le nœud d´ecisionnel (couche d´elib´erative + EMD) d´econnect´e d’un syst`eme fonctionnel (bas niveau).

– Requˆete de chargement `a destination du GI. Dans ce test, une mission est transmise `a la couche d´elibl´erative. La mission est trait´ee par le superviseur de CD (op´erateurs 0,1), et transmise au couple planificateur / raffineurs. Le plan r´esultant contient une tˆache jointe ´el´ementaire : le superviseur de CD transmet une requˆete de chargement de TJE au GI (op´erateur SCD-4). Le GI charge correctement le mod`ele d’interaction correspondant `a la TJE, en met- tant en correspondance les param`etres pass´es.

– Requˆete de traitement `a destination du GI. Le superviseur de CD transmet une requˆete pour le traitement de la modalit´e d’interaction charg´ee suite `a la requˆete initiale de chargement. Le moteur de traitement du GI applique le rˆole s´electionn´e au moment du chargement, et produit les tˆaches de haut niveau correspondantes : celles-ci sont r´eceptionn´ees par le superviseur de CD, qui les transmets pour raffinement au couple planificateur / raffineurs (op´erateur SCD-3), avant de les envoyer `a l’EMD pour ex´ecution (op´erateur SCD-5).

Des tests plus syst´ematiques du GI (et de la couche d´elib´erative), avec une mise en œuvre exhaustive des op´erateurs (en particulier l’op´erateur SCD-6 pour la replanification, ou l’utili- sation de l’op´erateur SCD-1 dans des cas o`u des missions sont d´eja programm´ees au niveau des UAV) seraient n´ecessaires afin de valider le paradigme et les notions introduits, ainsi que l’impl´ementation que nous en proposons : il s’agit ici de travaux prospectifs.

Dans les diff´erents tests impliquant le gestionnaire d’interactions, c’est un sc´enario `a 2 UAV proche de celui pr´esent´e dans les chapitres IV et V qui a ´et´e appliqu´e.

Conclusions et perspectives

VII.1

Retour sur les contributions

Nous avons propos´e dans ce m´emoire une approche pour appr´ehender le contrˆole et la prise de d´ecision dans les syst`emes multi-UAV.

Le probl`eme que nous avons consid´er´e est tr`es ambitieux, puisqu’il s’agit de doter un syst`eme multi-UAV `a la fois d’une architecture de contrˆole et de d´ecision flexible, et de proposer un cadre d’interaction puissant et maˆıtrisable. L’approche choisie est pragmatique, et tr`es orient´ee utilisateur ; elle peut se r´esumer ainsi : augmenter l’autonomie d´ecisionnelle des UAV, mais sans pour autant perdre le contrˆole du cadre des interactions entre UAV. Ainsi, notre approche permet `a un utilisateur de sp´ecifier explicitement ce qu’il attend de ces interactions.