Contraintes de conception d’une architecture multi-senseur

Le premier objectif de la future architecture multi-senseur sera d’allier l’autonomie du SMS tout en respectant l’ensemble des autres contraintes opérationnelles du sys-tème.

Une augmentation de l’autonomie des SMS permettra de répondre à deux besoins opérationnels distincts. D’une part, comme décrit en section 2.2.1.2, si ledit SMS est embarqué sur RPAS, une rupture de liaison de communication entre le système sol de pilotage de la plateforme (le gestionnaire de mission) et le RPAS rend impossible l’envoi d’ordres au SMS. Si les algorithmes de commandes de vol s’adaptent à une perte de liaison et peuvent contrôler la plateforme sur une trajectoire de retour, voire de maintenir le plan de vol donné par l’opérateur, la situation est différente pour le SMS. Les actions senseurs à réaliser dépendent du contexte terrain ainsi que d’un ensemble de paramètres qui seront spécifiés par la suite. Avec une architecture de SMS classique, l’ensemble des actions senseurs ordonné par l’opérateur avant une rupture de liaison devient obsolète suite à un évènement imprévu sur le théâtre. La fréquence d’arrivée des évènements est proportionnelle à la dynamique du théâtre. D’autre part, l’augmentation de l’autonomie du SMS permet de répondre à la pro-blématique de surcharge des opérateurs et pilotes. En effet, dans un théâtre chargé, un certain nombre d’actions senseurs sont redondantes et nécessitent l’intervention permanente d’un opérateur afin de les programmer.

Dans la chaine de commandement des actions senseurs, l’opérateur occupe un rôle de décision. L’opérateur prend en charge la gestion de la trajectoire en fonction des objectifs et du théâtre d’opérations. Ensuite il observe l’ensemble des produits sen-seurs obtenus précédemment, le contexte et les objectifs de missions pour détermi-ner les actions senseurs compatibles avec la trajectoire puis les soumet au SMS. La problématique d’autonomie implique d’embarquer une partie de l’intelligence déci-sionnelle de l’opérateur à bord de la plateforme aéroportée.

La SiTac recueillie par le SMS représente un atout pour la chaîne de commande-ment et la survie de la plateforme. Pour cette raison, cette dernière doit prolonger sa construction si l’opérateur perd contact. De la même façon, pour une Plateforme Aéroportée Habitée, si le pilote est trop chargé ou dans l’impossibilité de lancer les ordres au SMS, un SMS autonome permettrait d’aider le pilote à accomplir l’objectif ou simplement de le décharger.

Une fois la SiTac recueillie, elle doit être transmise au centre de commande. L’ana-lyse de la SiTac en temps réel étant lourde, une synthèse doit être réalisée avant l’envoi à la chaîne de commandement afin de décharger le plus possible l’opérateur et raccourcir par la suite les délais de décisions.

2.3. Problématiques 21

Malgré une forte autonomie de la plateforme, celle-ci doit rester sous autorité com-plète du gestionnaire de mission. En effet, les objectifs réalisés par ses plateformes sont fortement critiques et nécessitent donc le déclenchement manuel d’actions pen-dant les phases les plus sensibles (comme la neutralisation de menaces). Même si le SMS ne gère pas le système d’arme de la plateforme, il peut être nécessaire d’utiliser des senseurs pendant les phases d’utilisation des armes.

L’opérateur peut à tout moment décider d’utiliser un senseur manuellement ou de monopoliser une ressource du système sans avertissement. Face à cette situation il est requis que le SMS se plie à la requête de l’opérateur sans gêner sa demande. De la même façon, la trajectoire de la plateforme peut à tout moment être modifiée par l’opérateur ou le pilote et ainsi modifier l’ensemble des actions senseurs déjà planifiées ou en cours. La trajectoire est dans ce cas considérée comme une variable d’entrée connue du SMS, mais non modifiable par ce dernier. Le SMS doit s’adapter et planifier les actions senseurs du mieux possible en fonction de cette donnée. Enfin, l’ensemble des séquences d’actions senseurs réalisées par le SMS doivent être reproductibles dans des situations similaires. Ceci est une contrainte apportée par la criticité des missions dans lesquelles le SMS intervient. Les scénarios de tests doivent être réalisés plusieurs fois et doivent illustrer le caractère prévisible du comporte-ment du SMS.

2.3.2.2 Répondre aux exigences industrielles

Du point de vue industriel, l’architecture devra être évolutive et modulaire tout en satisfaisant les exigences techniques propres au pilotage de senseurs. Ceci implique plusieurs points de travail au sein de l’architecture : (1) une quantité de re-travail moindre à la modification/l’ajout de senseurs et de fonctions ; (2) Une standardisa-tion des exigences de développement pour l’ensemble des interfaces des senseurs du SMS ; (3) la possibilité d’instauration d’un standard de communication au sein de l’architecture.

La caractéristique d’évolutivité du SMS demande une flexibilité d’adaptation aux futures évolutions de type matérielles et logicielles. Les potentielles évolutions ma-térielles sont nombreuses :

ä Évolution de la connectivité au sein de l’architecture (topologie du réseau, câble cuivre/fibre-optique, modification des temps de propagation des signaux) ;

ä Modification de la répartition logiciel/matériel ;

ä Décentralisation matérielle ;

ä Changement du matériel en interaction avec le SMS (par exemple les URL de la plateforme destinées au pilotage ou à l’armement)

De même pour les évolutions logicielles :

ä Nouveaux algorithmes de traitement ;

ä Modification des fonctions réalisables par les senseurs ;

ä Changement des procédures de gestion des menaces (exemple : ajout d’un nouveau type de menace dans les bibliothèques, les bases de données de sto-ckage des menaces) ;

ä Modification des logiciels en interaction avec le SMS (logiciel du gestionnaire de mission au sol, logiciel embarqué de contrôle de l’attitude de la plateforme)

Aussi, les senseurs peuvent être sujets à de nombreuses innovations non seulement concernant leur nombre, leur taille, leur puissance, mais aussi concernant leur façon de fonctionner de manière générale. Concernant les senseurs, la marge d’évolution est étendue :

ä Évolution des dimensions des senseurs existants

ä Modification de leur fonctionnement et interactions

ä Ajout de senseurs « jumeau » (exemple : ajout d’un deuxième radar à antenne active disposé différemment du premier)

ä Création d’un senseur fonctionnant sur une dimension physique jusqu’alors non exploitée

ä Répartition des senseurs sur plusieurs plateformes

Par exemple, à moyen termes il sera nécessaire de mettre en commun les antennes disposées sur un ensemble de plateformes en formation. Ceci suppose que les archi-tectures SMS des plateformes permettent la création de ce type de coopérations et donc a minima d’être conçues sur le même paradigme.

La modularité système implique que le SMS doit être capable d’accepter plusieurs configurations de senseurs et qu’il soit possible de les modifier sans reprogrammer l’ensemble du système. Ceci décrit la capacité « plug & play » du SMS. Cette aptitude suppose que l’ensemble des senseurs et ressources du SMS soit interfacé grâce au même standard de communication et que chacun d’entre eux ait un comportement similaire du point de vue système (protocole de réception des ordres, récupération des données bibliothèques, etc.). Sous l’angle de la conception des systèmes et sen-seurs, disposer d’un ensemble de standards de communication et de comportement permet de répartir plus facilement la tâche de conception en équipes et simplifie les étapes de vérification système. De plus cette capacité apporte une flexibilité optimale au regard de la préparation, de la maintenance et de la personnalisation du système. Les senseurs sont des instruments demandant une forte rigueur de pilotage. Ils fonc-tionnent sur une échelle temporelle pouvant être très réduite (de l’ordre de la di-zaine de millisecondes) les instructions de fonctionnement doivent ainsi être à cette échelle afin de ne pas bloquer le flux de commandes leur parvenant. Certains sen-seurs comme le radar à antenne active disposent en leur sein d’un ordonnanceur temps-réel lui permettant de segmenter des ordres de plusieurs secondes en des instructions de la classe de la milliseconde [Winter, 2008]. Ceci permet d’étaler l’exé-cution d’un ordre sur une durée plus longue, donc sur de plus longues distances grâce au défilement de la plateforme sur sa trajectoire.

2.3.2.3 Possibilité d’enrichir l’architecture avec d’autres technologies

Ces dernières années, les processus de décision occupent une place de plus en plus importante au sein des systèmes embarqués autonomes. Les algorithmes de décision peuvent être répartis en plusieurs points d’une architecture SMS (récupération et uti-lisation des données senseurs, transmission, envoi à une URL, traitement décentra-lisé, etc.). Certaines techniques d’apprentissage, comme les réseaux de neurones par exemple, peuvent nécessiter l’emprunt de canaux de communication spécifiques au sein d’un SMS afin d’avoir à disposition l’ensemble des données nécessaires pour le traitement. Ces données seront d’autant plus accessibles si l’architecture est conçue pour accepter de telles technologies en son sein. Les agents permettent la mise en place de limites et d’interfaces précises au sein des systèmes. Ainsi, les interfaces

2.3. Problématiques 23

entre un agent augmenté d’une technologie et un autre agent ne diffèrent pas tant que la nature de leurs échanges reste inchangée. De la même façon il reste possible lors de l’évolution des systèmes d’insérer un certain nombre d’entités autres que des agents (artefacts, voir section 3.1.2). Ceci permet l’ajout de traitements non encapsu-lés dans des agents, de réduire la complexité de la modification des systèmes sans toutefois remettre en question le fonctionnement du SMA déjà en place. Les résultats de ces traitements peuvent, par exemple, être accessibles au sein de l’architecture en tant que service aux agents. Des exemples seront donnés en section 6.1.2.2.