Nous avons évoqué dans les sections précédentes le fonctionnement de chacune des entités composant le système de simulation et explicité les liens qui les unissaient. Après avoir présenté une vue complète du système, nous menons une ré exion sur le choix du mode de connexion permettant aux composants d'échanger des données sur le réseau. Nous évoquons dans un troisième temps les limitations de l'architecture présentée, avant de monter en quoi elle respecte les spéci cations évoquées au chapitre précédent.
4.6.1 Vue globale
Nous présentons sur la gure 4.10 le synoptique du système entier. Par commodité nous n'avons représenté la connexion du système qu'avec un seul et unique véhicule et nous n'avons pas explicitement représenté les liens existants entre le superviseur et tous les processus.
Dans sa version actuelle le système de simulation totalise donc 16 processus auto- nomes, connectés à 10 zones de données partagées et peut être réparti sur six ordinateurs diérents, chacun d'entre eux comportant plusieurs processeurs. Un dernier ordinateur fait également partie du système de simulation mais n'a pas été représenté ici car il n'y participe pas en tant que tel : il s'agit du serveur de con guration et de compilation. Cet ordinateur permet de préparer des scenarii et de con gurer des véhicules. Par ailleurs, linux/RTAI y est installé a n de tester en local les diérents modules des architectures (contrôle et simulateur), avant de les distribuer sur le réseau. Nous reviendrons sur le rôle et les fonctionnalités de ce serveur dans la section 5.2.1. Il est à noter que le superviseur télécharge les dernières versions des exécutables, et l'ensemble des chiers de con guration depuis cet emplacement.
Nous avons représenté sur la gure 4.11 les ordinateurs impliqués dans une simulation faisant intervenir trois véhicules de type AUV. Nous avons précisé l'OS et le nombre de processeurs mis en jeu des ordinateurs hébergeant le système de simulation. T300_1,2,3 sont les noms donnés aux trois AUVs utilisés.
4.6 Cohérence de l'architecture proposée
Chapitre 4 : Proposition d'une architecture
Fig. 4.11 Un exemple de distribution du système
4.6.2 Choix du protocole
Distribuer l'ensemble de ces processus sur un réseau nécessite l'adoption d'un protocole de communication leur permettant d'échanger des données.
Sur un plan théorique, le choix d'un réseau déterministe s'impose naturellement. Ce- pendant, le temps d'implémentation de ce genre de technologie était incompatible avec les contraintes de la thèse. Par conséquent nous avons choisi d'utiliser un réseau ethernet en minimisant l'impact de ce choix sur le déterminisme du réseau.
En eet, une première solution consiste à maîtriser les instants d'échange sur le réseau, autrement dit, faire appel à un superviseur qui ordonne à chaque entité de parler dans une fenêtre de temps déterminée. Cette approche implique qu'il est nécessaire de s'isoler des autres tra cs non contrôlés, en particulier cela signi e qu'il n'est pas possible d'utiliser internet pour faire transiter des trames entre les constituants du simulateur.
La deuxième solution que nous avons retenue pour sa simplicité de mise en ÷uvre, ore cependant moins de garantie que la première. Nous avons utilisé un réseau ethernet micro-commuté : un seul ordinateur est connecté à une entrée d'un switch, ce qui limite fortement les risques de collisions et de latence sur le réseau.
Sur ce réseau, nous avons choisi d'utiliser le protocole UDP/IP, qui nous permet de faire transiter des paquets en mode non connecté, ce qui est bien le but recherché pour les raisons que nous avons précédemment évoquées.
4.6 Cohérence de l'architecture proposée
4.6.3 Respect des spéci cations
Dans cette section, nous véri ons que l'architecture proposée respecte bien les spéci- cations que nous avons précédemment établies. Un des premiers points que nous avons soulevé, était l'aspect collaboratif du simulateur. L'architecture proposée permet eecti- vement à plusieurs scienti ques appartenant à des domaines diérents de travailler sur un aspect sans avoir à connaître le fonctionnement de l'ensemble pour autant. Les mé- canismes mis en place permettent aux développeurs de s'aranchir des communications inter-processus et de la mise à jour des données ; ils peuvent se consacrer pleinement au développement et à l'implémentation de leur modèle. Un autre point important était la capacité de l'architecture à pouvoir simuler des robots diérents ; l'architecture proposée ne se préoccupe pas du type de robot connecté : seuls les modèles qui seront intégrés per- mettront de simuler diérents robots. Le système de simulation sépare donc clairement l'architecture à laquelle se connectent les robots, des modèles qui les simulent ; n'importe quel contrôleur de n'importe quel robot est donc potentiellement compatible avec cette architecture.
L'architecture proposée est clairement distribuée, ce qui correspond à un point cri- tique que nous avions soulevé. En eet, le simulateur est composé d'une dizaine de pro- cessus autonomes, répartis et exécutés sur plusieurs machines diérentes, connectées sur un réseau dédié. Cette approche nous permet donc clairement d'aborder le contexte du multi-véhicule en respectant les contraintes de temps réel en partie grâce à la répartition des traitements sur plusieurs unités de calcul.
Notre architecture supporte également les communications inter-véhicules et la plura- lité des moyens de communication pour chaque robot. Notre proposition permet de faire le distinguo entre le comportement logico-temporel du moyen de communication et la pro- pagation des ondes dans le medium ; ceci était également un point clé à respecter. Notre architecture prévoit de pouvoir connecter directement le contrôleur des robots au système ; nous avons donc bien créé un simulateur Hardware-in-Loop. Par ailleurs nous avons veillé à assurer le découplage temporel entre la commande et la boucle de simulation grâce à l'adoption du protocole UDP d'une part et à la mise en place d'un module élémentaire d'autre part. Ce module permet d'aranchir le processus de simulation des contraintes de communication réseau, et donc de garantir sa libre évolution. Cela nous permet de continuer à faire évoluer les véhicules sans considération du taux de rafraîchissement de la commande.
L'architecture proposée permet également de lancer une mission simulée, exactement de la même façon qu'une mission réelle ; seul le routage des données capteurs/ actionneurs/ communications vers ou en provenance de l'architecture diérencie les deux types de mis- sion. Cela n'a pas d'incidence sur le comportement temporel de l'architecture de contrôle. En n, notre architecture permet d'envisager la simulation hybride. En eet, même si elle est distribuée telle que nous l'avons présentée, il est possible d'exécuter l'ensemble de ces processus sur un seul et unique ordinateur. Il su t pour cela de spéci er diéremment les adresses réseau dans les chiers de con guration des composants. Cela permet donc d'exécuter le simulateur à bord du robot, et de faire de la simulation hybride embarquée. Pour nir, l'a chage 3D constitue un module de cette architecture et permet eecti- vement d'a cher un rendu en trois dimensions de la scène simulée. Même si cette fonc- tionnalité n'est pas encore implémentée, l'architecture est pensée pour cela et permettra facilement son ajout.
Chapitre 4 : Proposition d'une architecture