FR 2881544 A3 20060804 FR 0450143 A 20040127 PROCEDE POUR REALISER UN SEGMENT SOL OU UN SEGMENT BORD DANS UN ROBOT MOBILE AERIEN OU TERRESTRE OU SOUS MARIN, POUR GERER LE ROBOT LOCALEMENT OU A DISTANCE, EN METTANT EN UVRE UNE ARCHITECTURE OUVERTE, MODULAIRE ET EVOLUTIVE DESTINEE A ASSURER LE TRAITEMENT DES CONTRAINTES SPATIALES ET TEMPORELLES RATTACHEES AU ROBOT. 1.1.1 Introduction L'invention concerne un procédé pour réaliser un segment sol ou un segment bord dans un robot mobile aérien ou terrestre ou sous marin, afin de gérer le robot localement ou à distance, en mettant en oeuvre une architecture ouverte, modulaire et évolutive destinée à assurer le traitement des contraintes spatiales et temporelles rattachées au robot. Le procédé comprend les étapes suivantes: - l'étape de gérer les configurations matérielles hétérogènes embarquées dans le robot mobile aérien ou terrestre ou sous-marin, - l'étape de réaliser un logiciel modulaire adaptable à des configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques, - l'étape de gérer des interfaces d'adaptation semi automatiques entre les configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques et le logiciel modulaire, - l'étape de gérer des interfaces d'adaptation automatiques entre les configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques répondant à des critères dits de "plug & play" et le logiciel modulaire, - l'étape de gérer les contraintes spatiales et temporelles et les contraintes liées à la modularité et au caractère évolutif du logiciel modulaire. L'invention concerne également un système permettant de réaliser un segment sol ou un segment bord dans un robot mobile aérien ou terrestre ou sous-marin, géré localement ou à distance, en mettant en oeuvre une architecture ouverte, modulaire et évolutive capable d'assurer le traitement des contraintes spatiales et temporelles rattachées au robot. Le système comprend: - un logiciel modulaire, ouvert et évolutif adaptable de manière automatique et semi automatique à des configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques, -des moyens de traitement informatique destinés à : É gérer les configurations matérielles hétérogènes embarquées dans le robot mobile aérien ou terrestre ou sous marin, É assurer le traitement des contraintes spatiales et temporelles rattachées au robot mobile aérien ou terrestre ou sous marin et liées à la modularité et au caractère évolutif du logiciel. Logique de conception et de définition de l'architecture La démarche de conception et définition d'une architecture ouverte que nous nous proposons de mener, cherche en outre à être compatible avec la réponse que nous apportons aux interrogations suivantes: Comment réaliser un logiciel modulaire capable de s'adapter à des configurations matérielles très différentes en effectuant le minimum de développements spécifiques ? Comment assurer la gestion de l'hétérogénéité matérielle embarquée (diversité des équipements sur un drone et plusieurs drones) ? Comment gérer les contraintes spatiales et temporelles d'une architecture ouverte, modulaire et évolutive pour les drones ? (changements instantanés de trajectoire, chargement automatique des missions, gestion de temps critiques, guidage par cible pour ne citer que quelques exemples. ..), Gestion de composants de haut niveau actifs éfmdépe ndânts _> Autonomie - ' " Définition des composants Indépendante de l'environnement logiciels. _> Interoperabilité f ' mng. a-: ïxx Définition des dépendances à l'extérieur des.composa nts (découplage entre composants) > Réutilisation e architecture ouve 3 1.1.2 Architecture générale L'architecture générale est basée sur quatre environnements technologiques complémentaires: un environnement Hot Plug&Play de haut niveau (UPnP) un environnement de programmation par composants (OpenComponents) un environnement de communication un environnement de contrôle (Systèmes Agents / Multi-Agents) Les technologies Plug&Play permettent la mise en oeuvre d'équipements Plugables à Chaud , reconnus et utilisables immédiatement. Cette distribution fonctionnelle et physique est reflétée par l'agrégation des composants correspondants suivant un modèle prédéfini par la taxonomie. Cette agrégation constitue un premier niveau de contrôle des équipements depuis une application elle même centralisée ou répartie. Pour finir, les technologies Agents / MultiAgents permettent de coiffer l'ensemble des composants d'un système de contrôle de haut niveau (station sol, exécuteur du plan de mission, etc.). 1.1.3 Architecture Bord Drone (Plug&Play) Les équipements du drones sont des sous-systèmes Plug&Play Figure 1. Le drone: un système Plug&Play Le drone est un système Plug&Play constitué lui-même de sous-systèmes Plug&Play (en particulier ses PayLoads). Suivant les circonstances, ce point de vue est directement implémenté au niveau du drone ou déplacé au sol entre la DataLink et la station sol (fig. 2). Cette souplesse permet en particulier de rendre Plug&Play des drones qui ne le sont pas nativement et sur lesquels il est difficile, voire impossible, d'opérer une telle transformation. Dans le cadre de cette proposition l'architecture bord et la Data Link ont déjà été définis. Notre segment sol s'interfacera avec le bord et la data link. De la même manière la gestion des trajectoires et les fonctions correspondantes à sa gestion sont assurés par un équipement dédie se trouvant à bord. [4] 1.1.4 Un drone Plug&Play Un drone Plug&Play est un drone qui présente une interface normalisée qui permet d'accéder à différentes informations le concernant comme: son constructeur, sa version, les différents types d'équipements qu'il accepte (décomposable en deux groupes: un groupe fixe' et un groupe variable2), etc. La prise de connaissance en temps réel du drone, de ses propriétés (fonctionnalités, structures), permet d'assurer la reconfiguration automatique (ou semi-automatique) des applications de contrôles sur le drone lui-même ou au sol. 1.1.5 Des équipements Plug&Play L'identification des équipements actuellement installés dans le drone permet d'approfondir le processus de reconfiguration des applications de contrôle en croisant les informations générales obtenues du drone lui-même (voir ci-dessus) et les information spécifiques sur ses équipements (détermine notamment la répartition des équipements embarqués entre le groupe fixe et le groupe variable). EADS fournira la liste en annexe des équipements retenus et leurs liaisons conformément aux informations transmises à ce jour. 1.1.6 Architecture Sol L'abstraction du drone en tant que système Plug&Play permet de définir une architecture sol indépendante des particularités du drone et donc transversale à l'ensemble des drones. Cette abstraction permet un premier niveau de configuration dynamique de l'application de contrôle (préparation mission et suivi) en chargeant automatiquement et à chaud les différents composants génériques correspondants à chaque équipement embarqué (les composants peuvent être téléchargés depuis les équipements, donc depuis le drone, ou disponibles au sol dans une base). Le premier niveau précédent est complété par un second niveau de configuration qui permet d'établir des liens d'interaction entre les composants (donc entre les équipements qu'ils contrôlent). Ce second niveau s'appuie sur la prise en compte d'une part des règles métier fixes (i.e. principes généraux immuables) et d'autre part de la mission3. Cet aspect de la configuration peut être ramené à une problématique plus générale de mise en oeuvre de compétences précises (réparties entre les différents équipements) suivant un plan donné (typiquement la mission). II s'agit alors d'un problème de planification. L'OS retenu pour supporter la station sol est Linux avec un noyau de version 2.4. Le degré d'automatisation de la reconfiguration des applications de contrôle dépend donc de la capacité du système d'intégration logiciel à établir lui-même le rapport entre les compétences qu'il connaît (potentiel issu de la taxonomie) et qu'il sait disponibles (réalité constatée) et une mission. En terme Agent, l'autonomie d'un tel système repose sur un mécanisme de planification que l'on peut Ce que l'on trouve obligatoirement sur le drone 2 Les différents équipements que l'on peut embarquer sur le drone 3 Une mission est considérée ici et par la suite comme un but à atteindre (éventuellement constitué d'objectifs intermédiaires). espérer générique dans la mesure où tout système de drone est contenu dans la taxonomie. Néanmoins, il est reste possible d'imaginer qu'une mission donnée ne soit pas réalisable par un drone donné (par exemple: nécessite une PayLoad dont le drone ne dispose pas et qui ne fait pas partie de son groupe variable). Dans ce cas, ou l'on considère que les compétences actuelles du drone ne permettent pas de remplir la mission ou l'on choisit de dégrader les objectifs de la mission. Ce dernier choix constituerai un mode de planification au mieux : auto-adaptativité de l'agent. Ci-dessous et à titre d'information les types de plug in proposés par l'architecture de station sol de SINOVIA. Sa llca d'htàjrdfbnd. tféc?ëc 111M Seilc de 6cUfl StrAeEi c coma tank; .1ch F arme ux de cc m NIadted c riüôIedet.. ,.. : ay C ntro kor es.y sterrlesadd. ni re _ Tues de ç:onû.olec arg .lhsfâb I ertel7racIdng Gestion des charges utiles > payload générique ispé d'Élue > Imagerie Vidéo Ov t s: E1reistra ent Capture d limages et Feporthg; > Dissémination d'Mages et données vers d'autres 041 Gestion de la mission M > Chargement de Li mission au sol Tasking J Ed Taski rxt Création!editionire-kiilhen!rouvegarde plan de r(Ibs(a:rant(en vol) validati on de rn sion Paramètrage spa_cili lue a I'UP.V tmodèle de l'tlAt: .) > Vérifi cation d e l'inten+isibilité ara, ! Statn FFprograrmmtion (Fe -Taskird Partage de Cri l._.On avec d la utr es LIC.. J4lgUA',;) r,il =. _rrrinaton > Post-mission Reports Messacieries et M.lerrnes attiGhage / log Gestion 1'i l. k ntterrisste&t écallage ri?rr'r dur ice pré-tlight4h GÏ :: : ;, tl "rl the.I n cionfiguralron DTf DT SY' UNE ARCHITECTURE MODULAIRE AU BORD Pour répondre à la demande d'une architecture modulaire avionique les parties avionique et mission sont complètement dissociées. La cohérence temporelle et spatiale des échanges sera gérée de manière non intrusive par une logique componentielle à faible couplage donnant lieu à une structure d'accueil chargée d'assurer l'éventuel transcodage protocolaire et l'interconnexion des protocoles et réseaux de communication. Cette structure d'accueil basée sur le principe du plugin garantira l'indépendance des médias, protocoles et transports. La criticité des échanges sera assurée par la présence d'un OS temps réel permettant de gérer de manière aisée le couplage avec le composant de virtualisation de flux. L'architecture que nous proposons n'est aucunement liée aux caractéristiques propres d'un type de drone. Elle s'inspire des travaux réalisés par SINOVIA sur les architectures modulaires, ouvertes, et évolutives. Elle peut être considérée comme une version minimale permettant d'être intégrée de manière fiable et rapide dans un drone déjà existant. En partant d'un drone existant, il s'agit de superposer au système embarqué déjà en place assurant les boucles courtes et la gestion de la mobilité du drone un réseau fédérateur et une structure d'accueil minimale permettant d'apporter de la modularité, de l'ouverture et une approche capacitaire pour une gestion souple des charges utiles diverses en particulier. Elle est aussi applicable sur une architecture de drone nouveau pour lequel une configuration ouverte, modulaire et évolutive est conçue dès le départ. Cette architecture est considéré comme un miroir de la structure d'accueil sol et reprends au bord ses fonctionnalités et réciproquement. Reconfig Lr afi n d,nmmiquè de r_rn p o -a nt- VIRTUALISATION ET GESTION DE FLUX DE COMMUNICATION HETEROGENES PAR BOUCLER LOCALE ULTRARING Un élément essentiel pour traiter l'hétérogénéité des entités communicantes est la capacité à réaliser l'interconnexion des réseaux et des protocoles afin de rendre transparents les mécanismes d'échange. Les travaux de SINOVIA dans ce domaine concernent la notion d'Automatismes Virtuels Distribués (AuVirD). Elle est basée sur une approche multi-(agents intelligents) et elle constitue une contribution pour la modélisation et la conception des systèmes à forte hétérogénéité utilisant des protocoles de communication de bas niveau (FIP, CAN, INTERBUS S, 1553) et de plus haut niveau (TCP en particulier). Elle adresse des domaines d'application, dont les drones font parti, où les contraintes de distribution sont maximisées, tout en demandant une très forte réactivité. La complexité de ce type d'applications est toujours croissante. Les installations sont devenues fortement hétérogènes d'un point de vue matériel et logiciel et le phénomène de Down Sizing conduit à une multiplication des unités de traitement et par conséquence des médiums et des protocoles de communication. La gestion des flux de communications proposée pour assurer la virtualisation est illustrée au niveau middleware par la gestion basée sur le principe de l'ULTRARING: i T.LTRIN Exemple Dot ale nr> a u ge' Séparation des équip enrnts par contraintes et CI ce' i peut ne= envis ag er de créer un. anneau liant les deux réseaux p?uraccroitte la Q 3S, Proposition 'lute Architecture Modulaire pour LTAV RECORDER INS Auia.cs 1 & 2 INS lande Msim GestiaraiÉe Ba%de damées t'IkiR#S& Ney PIS strbus Indue> 1 SATCOM ATC Middleware applicatif La programmation constructive est une technique de programmation qui s'appuie sur la définition d'unités logicielles autonomes et communicantes appelées composants que l'on intègre de manière incrémentale au sein d'un framework. Cette approche permet d'optimiser les efforts de développement, intégration et tests dans la mesure où elle assure une forte réutilisabilité du code (le composant) et la possibilité de valider de manière progressive une application en intégrant les composants un à un. La capacité de reconfiguration dynamique d'une application est dans ce cadre directement liée à la propriété de recomposition à chaud intrinsèque au framework Plug & Net OpenComponents . Ces différents aspects garantissent des propriétés de modularité et d'évolutivité fortes. D'autre part l'interopérabilité en tant que capacité d'interaction d'un ensemble des ressources pour réaliser une tâche implique la communication, la distribution d'informations, et la compréhension mutuelle entre les différents domaines d'exécution. Avec notre approche cette propriété devient indépendante de toute autre considération sur le modèle ou l'architecture de l'application car elle repose uniquement sur la mise en oeuvre des composants d'interface que l'on peut ajouter ou retirer de manière dynamique. Ces composants d'interfaces interviennent à deux niveaux: Niveau externe: l'interopérabilité repose sur l'adjonction de composants d'interface assurant le lien avec du matériel ou du logiciel existant, Niveau interne: la problématique de l'interopérabilité est soulevée par l'existence de composants hétérogènes dont le rôle induit une interface spécifique et est résolue par la mise en oeuvre d'un mécanisme d'intégration de plus haut niveau. Nous nous appuyons pour cela sur des architectures en cluster, chaque cluster étant géré par un composant d'interface tel que le composant Maestro. 13 1.1.7 APPROCHE D'INTEROPERABILITE Les systèmes (embarqués ou non) ne doivent pas être vus comme un ensemble homogène avec une commande unique, mais plutôt comme un système complexe constitué d'éléments divers coopérant ensemble pour résoudre les fonctionnalités de l'unité. Les systèmes de contrôle - commande actuels ne profitent pas complètement de cette modularité. Les échanges d'informations entre équipements sont redéfinis à chaque étude et la gestion des échanges entre équipements est finalement dédiée à l'application bien que les éléments de base possèdent toujours la même vue comportementale. La distribution de l'intelligence et la modularité ainsi introduite devront permettre au système de drones de s'adapter à une diversité d'équipements et offriront des services d'accompagnement qui faciliteront grandement la ré-utilisation. Pour être totalement interopérable un processus doit être engagé dès la conception d'un système ou d'un produit afin de maximiser les qualités d'échange et ré-utilisation de l'information externe ou interne. La capacité maximale d'inter-opérabilité signifie que les systèmes (ou produits) ont la propriété d'être considérés interchangeables de manière dynamique avec une capacité native d'auto- adaptation. Le paradigme de conception de systèmes complexes à partir d'entités autonomes, indépendantes pouvant être associées entre elles de manière temporaire ou permanente par des liens de communication assurant la propagation et la notification de messages répond de manière assez précise aux exigences de l'inter-opérabilité native. L'approche COTS (Commercial Off-The-Shelf), conception de systèmes à partir de composants, offre une technologie d'implémentation assurant ainsi la modularité, la construction incrémentale, la qualité et la performance de la mise au point et de tests, une meilleure traçabilité de la vie du système et une gestion plus fiable et aisée des évolutions. Les propriétés d'évolutivité, de réutilisabilité et d'ouverture sont donc intrinsèques à cette approche qui assure une indépendance réelle entre les composants depuis leur réalisation jusqu'à leur utilisation. Les composants peuvent être validés séparément ou par sous-groupes de manière itérative, l'ajout d'un nouveau composant ne remettant pas en cause les validations précédentes. Un composant étant la plus petite unité de description qui encapsule du logiciel (des agents par exemple) sa définition contient des renseignements complets et précis sur le type de code source encapsulé ainsi que sur son emplacement (par exemple pour l'installation d'un composant) ou encore ses besoins en terme de support d'exécution (OS, version, bibliothèques). Les connecteurs permettent l'interconnexion entre composants. Les interconnexions (ou bindings) sont des liens entre deux composants utilisant un connecteur qui permet d'assurer l'interopérabilité. Le Framework (s'agissant du logiciel) portant les composants, vérifie (ou non) les règles de connexions. 1.1.8 Notre approche avec Plug & Net OpenComponents Plug & Net OpenComponents de SINOVIA s'inscrit dans une démarche d'interopérabilité par composants, dont les principales caractéristiques sont: É Le contrôle et l'intégration de données sont mis en oeuvre à partir d'un modèle à base de composants. É Les dépendances de données sont réduites en encapsulant les composants par des interfaces bien définies. Plug & Net OpenComponents permet ainsi: É La réutilisation de modèles de procédés (composants) autonomes et fonctionnels, É L'interopérabilité entre composants hétérogènes, É L'évolution dynamique du modèle par composant. Communications sous OpenComponents Le modèle de communication retenu pour OpenComponents est le modèle par envoi de message notamment utilisé pour la mise en oeuvre des architectures des Systèmes Multi-Agents (SMA) à contrôle distribué. Les communications entre composants utilisent les liens tissés entre les plugs des composants. Les liens assurent alors la diffusion des messages (la résolution du destinataire est implicite). Clustering et communications par partage d'information Les communications par partage d'information, notamment utilisées pour la mise en oeuvre des architectures des SMA à contrôle centralisé, se retrouvent dans l'approche OpenComponents au travers de la notion de cluster. Dans cette approche les composants ne sont pas directement liés mais utilisent un intermédiaire pour communiquer. Cet intermédiaire est lui-même un composant qui peut se comporter comme un routeur qui assure la traduction et le routage des différents messages ou représenter et gérer un espace de travail commun (notion de blackboard) permettant le partage d'informations. Ces différentes approches sont complémentaires et permettent de mettre en oeuvre au sein d'une même application indifféremment un contrôle distribué et un contrôle centralisé. REVENDICATIONS 1. Procédé pour réaliser un segment sol ou un segment bord dans un robot mobile aérien ou terrestre ou sous marin, afin de gérer ledit robot localement ou à distance, en mettant en oeuvre une architecture ouverte, modulaire et évolutive destinée à assurer le traitement des contraintes spatiales et temporelles rattachées audit robot; ledit procédé comprenant les étapes suivantes: - l'étape de gérer les configurations matérielles hétérogènes embarquées dans ledit robot mobile aérien ou terrestre ou sous-marin, - l'étape de réaliser un logiciel modulaire adaptable à des configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques, - l'étape de gérer des interfaces d'adaptation semi automatiques entre lesdites configurations 10 matérielles hétérogènes comportant un nombre d'éléments spécifiques et ledit logiciel modulaire, l'étape de gérer des interfaces d'adaptation automatiques entre lesdites configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques répondant à des critères dits de "plug & play" et ledit logiciel modulaire, - l'étape de gérer lesdites contraintes spatiales et temporelles et les contraintes liées à la modularité et au caractère évolutif dudit logiciel modulaire. 2. Système permettant de réaliser un segment sol ou un segment bord dans un robot mobile aérien ou terrestre ou sous-marin, géré localement ou à distance, en mettant en oeuvre une architecture ouverte, modulaire et évolutive capable d'assurer le traitement des contraintes spatiales et temporelles rattachées audit robot; ledit système comprenant: - un logiciel modulaire, ouvert et évolutif adaptable de manière automatique et semi automatique à des configurations matérielles hétérogènes comportant un nombre d'éléments spécifiques, - des moyens de traitement informatique destinés à : É gérer lesdites configurations matérielles hétérogènes embarquées dans ledit robot mobile aérien ou terrestre ou sous marin, É assurer le traitement des contraintes spatiales et temporelles rattachées au dit robot mobile aérien ou terrestre ou sous marin et liées à la modularité et au caractère évolutif dudit logiciel.