Quantité de re-travail pour évolution

La modularité du SMS est un des besoins essentiels exprimés par le monde indus-triel afin de réduire les coûts, les durées de développements et le taux de reprise de l’existant, voir besoin 9 section 4.1.2.3.

L’architecture à base d’agent présentée dans ce manuscrit compartimente dans diffé-rents composants l’interprétation, la décision et la planification des actions senseurs ainsi que l’ordonnancement et la fusion des produits senseurs. Compartimenter les traitements permet de limiter l’impact de l’ajout de nouveaux composants sur le reste du système ou d’identifier et d’en maitriser plus simplement les conséquences. Hypothèses :

ä Le senseur K n’est dépendant d’aucune ressource encore non représentée dans le SMS.

ä Le senseur K est dépendant de la ressource virtuelle HF.

6.1. Critères d’évaluation 159

ä Un premier plan d’utilisation simple, le senseur K doit être réservé de manière synchrone avec la ressource virtuelle HF.

ä Un deuxième plan, plus complexe, fait intervenir le senseur «Antenne Active», la ressource «SAR Processing» et la ressource virtuelle «HF-Band».

Étudions l’impact de l’ajout d’un nouveau senseur K, dans le SMS selon une ap-proche ascendante (ou bottom-up, voir section 4.1.2.1). La première étape est d’ajou-ter matériellement le senseur au SMS :

1. Ajout de la tête senseur

Les têtes senseurs sont les parties matérielles physiquement actives du SMS, permettant de recueillir les informations du théâtre. Le senseur K est composé d’une tête senseur matérielle unique positionnée sur la plateforme et faisant partie du réseau de senseurs disponibles au sein du SMS.

2. Ajout du driver

Le driver est un composant logiciel qui permet de contrôler la ressource physique afin de la piloter et de regrouper/encapsuler les données de manière compatible avec le SMS englobant la ressource. Le driver est le composant pas-serelle entre le monde logiciel et matériel.

3. Création de la ressource

La ressource (voir section 4.2.3.1 composant 12) est un composant logi-ciel permettant de traduire les plans et tâches en instructions senseurs. La ressource gère les modes de fonctionnement du senseur, sa direction, les du-rées d’exécution précises en fonction de l’ensemble des informations spécifiées dans les tâches qu’elle reçoit.

La chaine constituée des trois éléments Tête senseur/Driver/Ressource permet d’in-tégrer un nouveau senseur au SMS, mais n’est pas suffisante afin de l’utiliser de manière autonome. Une étude top-down ou descendante permet d’identifier les élé-ments nécessaires :

4. Ajout de la définition du senseur et de ses modes

Cette étape consiste à ajouter la définition du senseur et de ses modes, c’est-à-dire de donner un nom unique à chacun des modes qu’il fournit, et de les ajouter à l’ensemble des ontologies accessibles aux agents. Les modes met-tant en jeu plusieurs senseurs sont aussi définis lors de cette étape. L’intégra-tion des ontologies au sein des agents permet à ces derniers d’être en mesure de désigner plusieurs modes fournis par le nouveau senseur pouvant atteindre les objectifs opérationnels qu’ils se sont fixés, ou par le biais du gestionnaire de mission.

5. Définition de la portée des modes du senseur

Une fois que les agents sont capables de choisir les modes exploitant le nouveau senseur, ceux-ci doivent être capable de planifier leur exécution et de vérifier leur compatibilité avec le contexte (trajectoire, météo, politiques). Les contraintes contextuelles (distances, plages de visions exploitables, etc.) sont alors définies pour chacun des modes. Les agents sont capables de choisir un sous-ensemble de modes permettant d’accomplir leurs objectifs opérationnels.

6. Écriture des plans senseurs

Les plans décrivant les réservations de ressources et les contraintes tempo-relles sont définis de façon à ce que les agents puissent planifier leur utilisation et les placer dans le temps. L’agent retient le mode préféré/optimal pour l’ob-jectif opérationnel entre tous les modes senseurs compatibles avec le contexte retenus précédemment. Si un des modes du nouveau senseur K est retenu alors il sera envoyé à l’ordonnancement.

7. Ajout des données d’interprétation des produits du senseur

Après exécution des tâches et des instructions au niveau matériel les don-nées remontées par la tête senseur et le driver sont ensuite fusiondon-nées par le track-merger (voir section 4.2.3.1 composant 9). Après fusion l’agent à l’ori-gine de la requête est enrichi des données remontées si besoin. Les données remontées par la ressource peuvent être de natures différentes en fonction des modes et senseurs présents sur le SMS. Afin de donner aux agents la capacité d’interpréter correctement les données remontées par les senseurs des don-nées d’interprétation doivent leur être mises à disposition, en enrichissant par exemple les bibliothèques et bases de données (voir Tactical Database en section 5.2.2.4).

La figure 6.1 permet de visualiser les ajouts nécessaires à l’architecture afin d’exploi-ter le nouveau senseur K.

FIGURE6.1 – Schéma de l’ajout d’un senseur au sein de l’architecture SMS.

L’aspect modulaire de l’architecture peut être optimisé si l’ensemble des composants logiciels et définitions nécessaires à l’exploitation d’un senseur sont empaquetés afin de simplifier le chargement/ajout d’un senseur à un SMS. De cette façon, des mo-dules, sous la forme de senseurs et de leurs dépendances, peuvent être ajoutés/-déplacés sur différentes plateformes afin de disposer, par exemple, d’une flotte de plateformes avec des SMS à géométries variables.

6.1. Critères d’évaluation 161

©Thales

FIGURE6.2 – Un pod multifonction Talios.

La figure 6.2 montre une nacelle senseur pouvant être ajoutée de manière modu-laire sur une plateforme aéroportée. Ce type de nacelle est appelée un pod et permet d’embarquer des instruments spécifiques en mission. Ce pod est multifonction et met à disposition un ensemble de fonctions au pilote en vol. L’installation de ce type de matériel à bord d’une plateforme ayant un SMS à bord est un bon exemple de besoin de modularité et de mise à disposition de fonctions d’un nouveau senseur à un SMS existant. Il est possible d’interfacer un tel pod avec un SMS orienté SMA si l’ensemble des plans, définitions et données permettant l’analyse sont embarqués dans la nacelle et partagés au SMS lors de sa connexion. Les agents tactiques pour-ront planifier l’utilisation du pod au même titre que n’importe quel autre senseur du SMS.

Afin de conserver une flexibilité et modularité dans le système de senseurs l’ordon-nanceur est indépendant de la création des plans et des agents, les paramètres pas-sés à l’ordonnanceur, nécessaires au lancement du processus d’ordonnancement ne dépendant pas des agents ni des composants amont. Ceci permet de découpler ce dernier du système multi-agent et ainsi de limiter le taux de rework de l’ensemble du SMS en cas de modification de l’ordonnanceur.