conception d'une architecture est un passage obligé. Elles sont caractérisées par la quantité de calculs à eectuer, qu'ils découlent de la nesse des modèles employés ou du nombre de véhicules à simuler, mais également du temps autorisé pour que ces calculs soient accom- plis : c'est la notion de temps-réel et au-delà de déterminisme et de respect de causalité. L'absence d'architecture ou une architecture mal conçue peut se révéler être un facteur limitant dans le meilleur des cas (c'est-à-dire qu'il n'est pas possible d'étendre la charge de calcul sans devoir dégrader la nesse des modèles) ou un motif d'invalidation des résul- tats (surcharge processeur, protocole inadéquat, ...) dans le pire des cas. Par ailleurs une architecture mal pensée ne permettra pas de faire évoluer a posteriori les fonctionnalités oertes. Même si ce dernier point n'est pas crucial et ne remet pas en question une simu- lation faite dans le cadre expérimental pour lequel le simulateur a été créé, il est évident que pouvoir faire évoluer les fonctionnalités et changer les modèles constitue un but à rechercher. En n, concevoir un simulateur monolithique (c'est-à-dire un simulateur créé sur mesure pour une application particulière) va à l'encontre du concept de préparation de mission de coordination. En eet, ce type d'expérimentation nécessite généralement l'intervention de plusieurs acteurs et dans ce contexte un simulateur monolithique ne peut pas être une solution satisfaisante. Une architecture est donc nécessaire pour per- mettre à tous de collaborer à la conception de la simulation.
Il sera donc nécessaire de créer une architecture répondant à un ensemble de critères que nous allons exposer et qui font défaut (au moins partiellement) dans les simulateurs que nous avons étudiés. Il est à noter que nous considérons cette architecture comme un outil de recherche opérationnel qui satisfait, au moins partiellement, nos besoins et qui sera amené à évoluer au l du temps.
3.2 Une architecture ouverte
Nous avons évoqué dans le paragraphe précédent, la notion de collaboration des acteurs autour de l'architecture, a n de créer des simulations. Cet aspect revêt une importance capitale dans le contexte du multi-véhicule. Le terme "ouvert" est assez vague et il est nécessaire de préciser les points qui permettent de quali er de telle architecture :
Le code de l'architecture dans laquelle seront implémentés les modèles doit être source-ouverte, au moins pour certaines de ces parties. Les membres d'une petite équipe ne su sent pas pour développer un projet à la frontière d'autant de domaines diérents, et créer une architecture qui ne peut pas évoluer, la rendra à coup sûr incompatible avec certains modèles. Chacun doit donc être en mesure de proposer des ajouts, des extensions, ou des modi cations permettant à l'architecture d'évoluer pour en améliorer le fonctionnement ou ajouter de nouvelles fonctionnalités.
Qui dit source-ouverte, dit documentation des sources. En eet, proposer le code source ne su t pas, il faut produire une documentation, a n de permettre aux contributeurs de participer et d'intégrer correctement leur travail. Cette documen- tation ne doit pas se résumer à commenter du code source. Il existe des systèmes de production de documentation automatiques (tel que Doxygen par exemple), favori- sant la diusion des informations au sein de la communauté. Cette diusion, peut éventuellement être accompagnée d'un système d'échange et de thésaurisation des savoirs tel qu'un forum par exemple.
Chapitre 3 : Positionnement des travaux cette approche permet à une personne ou un groupe de personnes de travailler spé- ci quement sur une partie de l'architecture, sans nécessairement en connaître tout le fonctionnement. Une description précise des fonctionnalités du module facilite, là aussi, le travail collaboratif.
Pour cela l'architecture doit être correctement segmentée. Cela signi e que les dif- férents domaines (dynamique des véhicules, simulation des capteurs, ...) doivent transparaître au travers de l'architecture. L'architecture doit orir, à un spécialiste en acoustique par exemple, la possibilité de travailler uniquement sur la partie du code qui l'intéresse, sans nécessairement avoir besoin d'une vue détaillée de l'en- semble du système.
Ouvrir la majorité du code à plusieurs contributeurs ne va pas sans poser certains problèmes inhérents au développement collaboratif. Pour assurer la cohérence du développement et le suivi des versions, de nombreux outils existent (on citera CVS par exemple) et il est nécessaire de recourir à ce type d'outils pour ce projet. Par ailleurs, une architecture bien conçue permettra à tous de personnaliser une partie du code sans compromettre la structure de l'ensemble. Cela se traduit concrètement par une approche modulaire (c'est-à-dire que l'on peut utiliser, remplacer, ajouter des portions de code dans l'architecture) et par la distributivité du système (un élément requérant une grosse puissance de calcul doit pouvoir facilement être déporté sur une autre machine pour éviter de perturber l'ensemble de l'architecture).
La possibilité de changer les paramètres de la simulation sans avoir à re-compiler à chaque modi cation est un aspect pratique important. Pour cela il est possible d'utiliser des chiers de con guration qui sont lus dynamiquement pendant la phase d'initialisation d'une simulation.
La description des caractéristiques des entités participantes, telles que les AUVs, les modèles, ... repose généralement sur des chiers au format propriétaire, le plus souvent sous forme de chiers de données non formatées. L'usage de format pro- priétaire, le plus souvent sous forme de chier texte, est à prohiber. Cela rend peu compréhensible le contenu de ces chiers et il est di cile de les faire évoluer. Un exemple de ce genre de chier est donné gure 3.1 ; de même dans [38], les auteurs font mention de chiers texte de con guration pour leur simulateur. Il sera donc nécessaire de développer un formalisme permettant de décrire les éléments du si- mulateur de façon plus universelle. Ce formalisme devra pouvoir évoluer avec la pluralité des systèmes connectés au simulateur tout en restant compatible avec les diérents modules existants. Il faudra donc favoriser une approche incrémentale. Ce type de simulateur doit donc être ouvert et envisagé dans l'optique d'un travail collaboratif . Cela permet de pouvoir exploiter les avancées des diérentes com- munautés en intégrant par exemple leurs modèles au sein du simulateur. En eet, le nombre de domaines diérents est important, et il est peu probable qu'une seule équipe regroupe des connaissances dans l'ensemble de ces domaines (hydrodynamique, propaga- tion des ondes acoustiques ou électromagnétiques, traitement du signal,...). Force est de constater que l'ensemble des simulateurs étudiés ne présente pas l'ouverture nécessaire à un tel projet. Seul le simulateur CADCON propose de télécharger les exécutables des clients pour leur simulateur (pas de code source disponible), qui par ailleurs n'est que très rarement "online", ce qui ne permet pas de lancer des simulations quand on le souhaite. Un gros eort doit donc être fait si l'on souhaite que "la compétence de chacun au service