Validation des besoins opérationnels et industriels

Pour rappeler la section 4.1.2, le contexte opérationnel et industriel demande la vé-rification de plusieurs caractéristiques essentielles à l’acceptation de l’architecture comme solution pouvant servir en situation réelle. Reprenons ci-dessous les besoin opérationnels déjà présentés et tentons de montrer en quoi la solution présentée en 4.2 et 4.3 satisfont ces besoins.

Validation des besoins opérationnels :(Besoins exprimés en section 4.1.2.2) Besoin 1 : Prédictibilité des résultats

Plusieurs composants et mécanismes ont été conçus afin de garantir une prédictibi-lité des résultats. L’architecture de l’agent tactique, basé sur deux machines à états permet de prédire en fonction de l’état en cours lors de l’exécution les différentes phases du cycle de vie de l’agent et donc des phases de calculs, projections, déduc-tion de connaissances et compiladéduc-tion de plans. La mémoire de l’agent dont sa carte des connaissances permet d’avoir à chaque instant une vue complète de l’état de fonctionnement de l’agent tactique. Couplée à ses machines à état, composées de son cycle de vie et sa machine à états tactique, chacune des sorties de l’agent est vérifiable et prédictible.

La priorité déterminée par les règles, politiques et algorithmes de l’agent tactique ré-sume la perception et la connaissance d’un objet en une valeur (ici entière) évoluant au cours du temps. La priorité découle de la carte des connaissances de l’agent à un instant donné. Les mécanismes de justification du niveau de priorité permettent à un opérateur de comprendre à tout instant quelles données sont exploitées et remontées lors du calcul de priorité.

La compilation des plans senseurs est réalisée par les agents à partir de leurs connaissances et des structures de plans définies dans les bases de données de plans chargées en préparation de mission. Les calculs réalisés lors de la construction des plans, de la projection de l’attitude de la plateforme à partir du plan de vol jusqu’aux durées des tâches exécutées par les ressources sont déterministes. Les modèles de performances permettant le calcul des durées des actions senseurs sont aussi des calculs déterministes.

L’ordonnancement est basé essentiellement sur la priorité des plans compilés par les agents tactiques. L’ordonnancement n’accepte pas de retard d’exécution de tâches. L’ordonnancement sortant est prédictible dans le sens où l’ensemble des plans les plus prioritaires du set de plan soumis seront ordonnancés tant que les contraintes peuvent être satisfaites.

L’ensemble de la chaine de décision est donc déterministe et donne des résultats pré-dictibles tant que les données permettant la prédiction sont accessibles. Il est possible à partir de l’ensemble des données, modèles de performances, bases de données et signaux (état des senseurs, variables environnementales, données plateformes) dis-ponibles au SMS de reproduire le comportement du SMS au sol à des fins de diag-nostic et monitoring des systèmes (jumeau numérique du SMS).

Besoin 2 : Fonctionnement par règles

Comme détaillé dans la section précédente, le fonctionnement des agents est basé sur les ontologies, les plans senseurs, les bases de données permettant la prise de décision des actions senseurs. De pair avec le fonctionnement interne des agents (machines à état et cycle de vie) ces données constituent ensemble des règles suivies par le SMS lors de son fonctionnement. Les règles peuvent être changées et modifiées afin de correspondre au contexte opérationnel.

Certaines règles opérationnelles telles que l’autorité maximale du gestionnaire de mission sur le SMS a été instanciée au sein de l’architecture via des mécanismes dédiés, l’agent de priorité absolue dans cet exemple. La nature modulaire des agents tactiques et leur placement dans l’architecture permettent d’apporter de nouveaux mécanismes avec un taux de reprise minimal tout en permettant des changements en profondeur de l’architecture.

6.2. Validation 167

Les politiques données par le gestionnaire de mission au SMS permettent de con-traindre sous la forme de règles simples l’ensemble des décisions prises par les agents du SMA.

Besoin 3 : Flexibilité de fonctionnement

D’un point de vue opérationnel, la flexibilité du SMS est atteinte par la capacité qu’a l’architecture à accepter à la fois un contrôle autonome des senseurs tout en intégrant des requêtes senseurs directes et haut-niveaux. La prise en compte des ordres en plus des objectifs déterminés en autonomie des requêtes bas et haut niveau est rendue possible par la caractéristique exhaustive de la représentation des objets du théâtre en plus d’une gestion des priorités par l’ordonnanceur. Voir section 6.1.2.2.

Besoin 4 : Modularité

Du point de vue opérationnel, la modularité présentée en 6.1.2.1 permet de disposer d’un SMS modulaire. Pouvoir personnaliser les SMS de chaque plateformes permet aux opérationnels de s’adapter du mieux possible à chaque missions, tout en dispo-sant d’un nombre de senseurs restreint. Pouvoir connecter un pod plug&play com-patible SMA permettrait de disposer d’un SMS à géométrie variable, reconfigurable rapidement.

Besoin 5 : Faible latence

Les résultats de l’expérimentation en section 5.3.2.1 montrent que dans un contexte de développement tel que décrit dans le chapitre 5, c’est-à-dire avec des ressources matérielles de calcul limitées et un langage fonctionnant sur machine virtuelle, les mesures des délais de la simulation 5.2.2 sont en adéquation avec les besoins de réactivité actuels et moyen terme.

Besoin 6 : Exploitation du plan de vol

Le plan de vol est une entrée exploitée par les agents afin de projeter l’attitude de la plateforme sur les prochains instants du vol de la plateforme. Ces projections per-mettent de définir quels sont les plans senseurs acceptables pour accomplir ses objec-tifs opérationnels propres. Un exemple de projection de plan de vol a été présentée en section 4.3.2.5, cas d’étude de la compilation d’un plan SAR.

Besoin 7 : Robustesse et résilience

Les sections 5.3.1 et 6.1.2.5 ont montré en quoi les agents et leur structure permettent une robustesse et résilience adaptée au besoin opérationnel. Plusieurs mécanismes en plus des mécanismes de récupération internes aux agents peuvent être introduits au sein du SMA, tels que des agents services dédiés, une copie systématique de l’ensemble des données sur une plateforme déportée, etc. La redondance et l’em-placement de chaque mécanisme peuvent être adaptés aux architectures matérielles et logicielles (langage d’implémentation et technologies) choisies afin de disposer d’une robustesse adaptée.

Validation des besoins industriels(Besoins exprimés en section 4.1.2.3) Besoin 8 : Décentralisation de la conception

La capacité modulaire de l’architecture apporte une possibilité de développement elle aussi par module (voir section 6.1.2.1). Ceci permet de décentraliser la concep-tion par modules. Certains modes senseurs/foncconcep-tions nécessitent la coopéraconcep-tion de plusieurs senseurs distincts, demandant dans ce cas une coopération de plusieurs modules senseurs, avec des données propres aux modes individuels de chaque mo-dule et des données communes. Par exemple, lors du développement de deux nou-veaux senseurs, deux équipes de développement distinctes peuvent considérer indé-pendamment un senseur, ses modes, ses données de plans et d’interprétation. Dans le cas où des fonctions communes sont envisagées, donc des plans senseurs dans les-quels les deux senseurs sont exploités, alors des données dédiées à ces plans doivent être définies.

Besoin 9 : Modularité

Le besoin industriel en modularité est différent de celui de la modularité opération-nelle. La configuration générale du SMS par la modification du réseau de capteurs et des plans permet aux opérationnels de personnaliser le SMS. La modularité indus-trielle quant à elle permet à différentes équipes d’étudier et développer des portions du SMS par modules. L’existence des plans, des agents tactiques, de leurs machines à états et des ontologies permet aux équipes de développement logiciel et matériel de maitriser les tenants et aboutissants de la prise de décision au sein du SMS. Les autres composants système tels que l’ordonnanceur et les ressources donnent aux ingénieurs la maîtrise du workflow général de l’architecture.

L’ensemble des interfaces permettent les échanges de données au sein de l’architec-ture sont robustes et pérennes vis-à-vis du cycle de vie de l’architecl’architec-ture, permet-tant de faire varier la configuration générale du SMS tout en conservant son work-flow original : la modification des systèmes tout en exploitant les interfaces dispo-nibles au sein de l’architecture permet de construire plusieurs configurations, afin par exemple de mettre en place plusieurs version d’architectures tout en conservant le squelette standard du SMS. La gestion de configuration, la maintenance et les évo-lutions sont alors mieux gérées et maitrisées.