Distributivité

Simuler plusieurs engins, possédant des modèles dynamiques diérents, évoluant dans un milieu complexe, et interagissant grâce à leurs capteurs plus ou moins sophistiqués et leurs moyens de communication, suggère une charge de calcul élevée, n'évoluant pas linéairement avec le nombre d'engins présents dans la simulation (gure 2.5). Un seul et

Chapitre 2 : Synthèse et approfondissement unique ordinateur ne semble donc pas susant pour implémenter un tel simulateur, tout du moins pour la simulation temps-réel. Plusieurs ordinateurs sont, de toute évidence, nécessaires et le simulateur se doit d'être distribué sur ces moyens de calculs : on parlera alors de système de simulation distribué. Ces ordinateurs appartiennent généralement à un réseau ethernet dédié, ou sont reliés entre eux via Internet. Un simulateur distribué est donc un simulateur dont la charge de calcul de la simulation est répartie sur plusieurs machines interconnectées. Il faut préciser ici que le contrôleur du robot ne fait pas partie de ce que l'on appelle simulateur ; ainsi par exemple le simulateur DEVRE, développé dans [33] n'est pas considéré comme étant distribué au sens de notre dénition.

Si le gain en terme de temps de calcul est évident, ce genre d'architecture n'est pas sans poser de problème. Les problématiques scientiques sont nombreuses et plusieurs communautés sont actives sur le sujet. Parmi ces problématiques, on peut citer :

 le mode de connexion entre les n÷uds du réseau (mode connecté avec acquittement sans perte de paquet, ou mode non connecté avec possibilité de perte)

 les aspects de synchronisation entre les machines (c'est-à-dire, le partage d'une hor- loge commune)

 les temps de réponse (comment garantir que la réponse d'un n÷ud puisse parvenir à son destinataire sans retard)

 la causalité (garantir que le calcul d'un événement à un instant donné aura les même implications sur l'évolution du système que dans la réalité)

Le chapitre 3 est consacré à notre positionnement par rapport à ces aspects importants de la simulation.

Beaucoup d'auteurs font le choix de dégrader la nesse de leur modélisation, de limi- ter la précision de leur capteur virtuel (sonar), ou d'augmenter la période d'intégration pour s'aranchir du problème de la surcharge de calculs [33], [35], [38], [19] entre autres. D'autres ont fait le choix d'essayer de répartir la charge de calcul sur plusieurs ordinateurs connectés en réseau, en usant de diérentes stratégies et congurations.

Dans [43], le simulateur CSE est un simulateur réparti sur un ensemble de machines hétérogènes (stations de travail, PC, ...), couplées entre elles en utilisant le réseau Inter- net. Cet ensemble est considéré comme une seule et unique machine virtuelle distribuée. La cohérence spatio-temporelle est maintenue de la façon suivante : tous les ordinateurs calculent l'évolution de la simulation à leur rythme. Si une incohérence (collision de véhi- cules par exemple) intervient, les ordinateurs reviennent dans le temps, pour recalculer un nouveau futur avec les nouveaux états. Cela permet d'éviter de cadencer l'ensemble sur la fréquence du simulateur le plus lent. Pour aider à maintenir la cohérence des données et pour garder un mécanisme propre et facile pour les programmes distribués, les auteurs utilisent une approche par abonnement pour le ux de données et la synchronisation. Pour ce faire, une base de données intelligente maintient en permanence à jour l'état du monde entier simulé. La base de données utilisée, appelée dVise, est intelligente dans le sens où c'est elle qui détecte les collisions spatiales et calcule les vues virtuelles des capteurs.

Dans [28], les diérents émulateurs d'AUVs sont connectés au serveur SAMON via un "wrapper". Ce terme désigne un programme permettant de transformer les ordres passés par un superviseur en commandes exécutables par l'AUV. Sur la gure 2.6, le bloc "In- herent Behavior" est en charge de reproduire le comportement de l'AUV face à diérents stimuli (ordre d'un superviseur, environnement, ...). Le bloc "Ocean Environment" est

2.3 Approfondissement des critères de classification

Fig. 2.6  Simulateur utilisant le VRML (Virtual Reality Modeling Language) et le Java chargé de fournir la bathymétrie et la valeur des paramètres océanographiques en réponse aux interrogations des capteurs.

Dans [49], les auteurs ont développé un simulateur HIL pour leur engin Romeo. Le système est divisé en trois réseaux locaux : un réseau dédié aux instruments de bord et au contrôleur appelé Onboard Ethernet LAN, un réseau dédié au simulateur appelé Lab Ethernet LAN et enn un réseau dédié à la supervision appelé Surface Ethernet LAN. Le système de simulation est réparti sur trois serveurs qui prennent chacun en charge un aspect de la simulation : rendu graphique, environnement et capteurs, et calcul de l'évolution dynamique de l'engin (voir 2.7).

Dans [23], le système de simulation est distribué sur quatre ordinateurs reliés par un réseau ethernet (voir gure 2.8). Un premier ordinateur ("control unit") est dédié au contrôleur, qui génère les commandes à partir de la simulation des capteurs et du panneau de surveillance du bateau mère. Un second ordinateur ("Simulator of AUV") est utilisé pour simuler l'évolution de la dynamique de l'engin (pour cela un modèle reproduisant les man÷uvres du véhiculé a été mis en place) et la réponse des capteurs. Un troisième ordinateur ("Monitoring panel") est utilisé pour la surveillance du statut du contrôleur et pour lui passer d'éventuelles commandes. Enn, un quatrième ordinateur est utilisé pour la génération et la soumission des informations nécessaires à l'exécution de la simulation ("Simulator on the mother Ship").

Dans [38], chaque véhicule est connecté à un simulateur de véhicule qui sont eux- même connectés au simulateur d'environnement en TCP/IP. Dédier un simulateur par AUV constitue sans aucun doute un premier pas vers la répartition de la charge du calcul sur le réseau. Cela peut s'avérer néanmoins insusant si le véhicule possède un sonar et un système de vision par exemple. Le simulateur devant fonctionner en temps-réel, ses limites seront très vite atteintes avec ce type de capteurs et un choix devra être fait entre précision des modèles et vitesse de calcul. Cette architecture est donc statique et ne permet pas de répartir la charge de calcul de façon extensive.

Dans [44], les auteurs montrent comment leur système de simulation MVS répartit la charge de calcul sur plusieurs ordinateurs. MVS produit un environnement de simulation auquel plusieurs acteurs peuvent se rattacher via un ou plusieurs processus "d'abonne- ment". Lorsque la charge de calcul devient grande, il est possible de créer d'autres envi-

Chapitre 2 : Synthèse et approfondissement

Fig. 2.7  Vue globale du ROV romeo connecté au système de simulation

Fig. 2.8  Fonctionnement des diérents ordinateurs composant le simulateur d'Ura- shima ; chaque cadre en trait épais, correspond à une unité de calcul

2.3 Approfondissement des critères de classification

ronnement de simulation. De nouveaux mondes sont alors créés et d'autres agents peuvent s'y rattacher. Malheureusement les nouveaux mondes ne partagent pas de données com- munes, et l'intérêt de ce système s'en trouve donc fortement limité.

Toutes ces solutions pour relier les moyens de calculs orent plus ou moins d'avan- tages ; néanmoins, aucun des auteurs n'a soulevé la problématique du découplage temporel entre les diérentes entités constituants ces systèmes. An d'illustrer clairement ce point, prenons l'exemple du découplage temporel de la commande d'un véhicule et du simula- teur de la dynamique de l'engin. Ces systèmes de simulation sont utilisés entre autre, pour vérier le bon fonctionnement de l'architecture de contrôle du véhicule. Admettons que celle-ci présente une défaillance quelconque, et que "pour une fois", la commande mette une seconde à être générée au lieu des 0,1 seconde habituelle. En mode TCP/IP, le simulateur de la dynamique de l'engin, va rester bloqué en attendant que la commande du véhicule lui parvienne. Une fois cette commande arrivée (en retard), il va calculer l'état du véhicule à t+1, et renvoyer ces informations au contrôleur du véhicule. Cela signie que pendant cette seconde, l'engin est resté virtuellement immobile. Et pourtant dans la réalité, cette seconde aurait peut-être sut à lui faire percuter un obstacle. On voit clairement, avec cet exemple, qu'il est nécessaire de s'assurer du découplage temporel de toutes les entités faisant partie du réseau de simulation, si l'on veut pouvoir mettre en évidence des comportements potentiellement divergents ; cela signie qu'il faut abandon- ner le protocole TCP, au prot de l'UDP, qui est un mode de transmission non connecté. Néanmoins, cela ne résout pas entièrement le problème. Il faut également veiller à ne pas créer de blocage (du type "attendre", ou "lire tant que") au niveau de l'implémentation. Globalement, ce découplage temporel peut-être solutionné par un stockage intermédiaire. Dans ce paragraphe, nous avons évoqué la répartition de la charge de calculs sur un réseau. Parmi ces calculs nous n'avons pas évoqué la visualisation 3D, qui constitue un dernier point important pour considérer la coordination de ottille.