Le standard de simulation HLA

HLA (High Level Architecture) est un standard qui fournit des spécifications pour réa-liser des simulations coopératives et distribuées, avec l’objectif de faciliter la réutisabilité, l’interopérabilité et la composabilité des simulations [IEE10a].

2.8.4.1 Un peu d’histoire

Ce standard résulte de travaux menés par le ministère de la défense des USA (US De-fense community) depuis la fin des années 70 jusqu’à la fin des années 80, pour créer et

développer une technologie de simulation distribuée : le projet SIMNET27 (figure 2.19).

Suite à ce projet, le protocole de simulation interactive DIS28 est devenu un standard

in-dustriel IEEE en 1993 : IEEE 1278 Distributed Interactive Simulation Standard Protocol. Ce standard définit les messages et les procédures pour la communication entre les simula-teurs [Oka+16]. Ce standard IEEE 1278 a été retiré en faveur du standard HLA en 1998, et définitivement supprimé en 2010.

Au cours de l’année 1990, la DARPA29 parraine une étude pour agréger des simulations

distribuées entre elles : Aggregate Level Simulation Protocol ALSP30. Ce protocole intègre

la gestion des données, la gestion du temps et la distribution des événements entre ces différentes simulations distribuées [Oka+16].

Les retours d’expériences et des concepts développés pour DIS comme pour ALSP sont à l’origine de la définition d’un cadre de technologies communes pour le développe-ment de simulations distribuées. Il est formalisé par le standard HLA version 1.3 en 1998 [Oka+16] ; [DFW97a] ; [DFW98]. HLA devient un standard IEEE en 2000, nommé "Mo-deling & Simulation (M&S) High Level Architecture IEEE 1516-2000 series (IEEE 2000a, b, c)" [Oka+16]. En 2010, une nouvelle version de HLA est publiée et prend en compte les retours d’expériences des industriels : IEEE 1516-2010 series (IEEE 2010a, b, c) [Oka+16].

2.8.4.2 Quelques fondamentaux de HLA

Le standard HLA est défini par 3 livrets [IEE10a], [IEE10b], [IEE10c]. Le livret HLA Framework and Rules Specification [IEE10a] spécifie les éléments de conception d’un sys-tème et introduit les règles pour la conception de syssys-tèmes de simulation distribuée [Oka+16].

27. Simulation Networking

28. Distributed Interactive Simulation

29. Defense Advanced Research Projects Agency 30. Aggregate Level Simulation Protocol

Figure 2.19 – Histoire de la simulation distribuée [Oka+16] .

Il fait également référence aux deux autres standards HLA : HLA Object Model Template Specification [IEE10b] et HLA Federate Interface specification [IEE10c].

Le deuxième livret [IEE10b] fournit les spécifications des Object Model qui définissent

la structure des informations produites ou demandées (SOM31) par une application de

simulation (Fédéré) [IEE10a], et la structure (FOM32) du référentiel commun de données

à l’ensemble des applications de simulations en interaction (Fédération).

Le troisième livret [IEE10c] spécifie les services nécessaires à la connexion des simu-lations distribuées entre elles. Il définit les opérations, qui doivent être incluses dans une

infrastructure logicielle, dénommée RTI33 (ici, décomposé en "LibRTI et en RTIExec ;

fi-gure 2.20), nécessaire à l’exécution des simulations distribuées [IEE10a]. Le RTI est un processus en tant que tel (RTIExec) [Jud98]. Les échanges de données entre Fédéré passent par le mécanisme de communication inter-processus (IPC). Ce mécanisme est à prendre au sens large : par exemple de la mémoire partagée dans un environnement multiproces-seur, une communication réseau (ex : Internet) pour une simulation géographiquement distribuée.

Définition : Le standard HLA définit le terme Fédéré (Federate) comme étant une appli-cation capable de se connecter au RTI et de rejoindre une fédération en cours d’exécution. Les Fédéré peuvent être des calculateurs dédiés à la simulation (Simulation), des

appli-31. Simulation Object Model 32. Federation Object Model 33. RunTime Infrastructure

Figure 2.20 – Architecture HLA [Jud97] & [DSC12].

cations d’enregistrement et visualisation de paramètres (Data collector / Passive View), tout comme des interfaces en lien direct avec le monde réel (Interface to Live Players) [Jud97]. Si HLA n’impose pas de contraintes particulières quant aux types de simulations pouvant être exécutées par les Fédéré, ce standard impose, toutefois, la nécessité d’inclure les mécanismes permettant aux objets, situés dans les simulations, de communiquer entre eux, via le RTI [Jud97].

Définition : Une Fédération est le nom donné à l’ensemble des Fédéré. À cet ensemble est associé un modèle commun de données FOM, pour atteindre un objectif spécifique de si-mulation [IEE10a] [Jud97]. Cet objectif peut être, par exemple, de s’assurer qu’une voiture autonome réagisse suffisamment rapidement pour éviter la collision avec un piéton traver-sant soudainement la route. Dans un tout autre cadre, cela pourrait être la vérification du bon déroulement (simulé) d’un plan d’intervention en cas de catastrophe naturelle : in-tervention des différents acteurs (préfecture, hôpital, police/gendarmerie, secouriste, etc.), liens de communications fonctionnelles, respect des procédures et vérification de la per-tinence des messages échangés, avec la possibilité d’introduire des difficultés : perte liens radio, panne de véhicules.

2.8.4.3 Le temps dans HLA

La gestion du temps est un des atouts majeurs de HLA. Celui-ci ne possède aucune référence à une date partagée par la fédération. Cela veut dire que chaque fédéré doit posséder sa propre référence de temps logique. À charge pour le fédéré de mettre en place une relation entre son temps logique et tout autre référentiel temporel [DSC12]. Pour avancer dans le temps, chaque fédéré fait une demande auprès du RTI qui retourne une

autorisation immédiate ou après un délai, en prenant en compte les horloges logiques des autres fédérés. De cette manière, les principes de causalité des messages entre fédérés sont respectés. Un fédéré ne peut recevoir un message dans son passé.

Plus précisément, HLA supporte 3 mécanismes d’avance dans le temps des fédérés, par-ticipant à une fédération. Le premier mécanisme concerne le temps coordonné, qui spécifie que l’avance du temps est coordonné avec l’ensemble des autres fédérés de la fédération. Le deuxième mécanisme s’appuie sur les messages. L’avance dans le temps d’un fédéré est cadencée par la réception des messages dont une estampille temporelle est accolée à chaque message. Enfin, le troisième mécanisme, dit optimiste, considère que chaque fédéré avance à sa propre vitesse, indépendamment les uns des autres (cas du temps réel). Cette approche nécessite un mécanisme de rollback pour prendre en compte la réception d’un message avec une estampille temporelle se situant dans le passé du fédéré.

Dans le cas particulier du temps réel, il peut être souhaitable de mettre en place un mécanisme de synchronisation entre l’ensemble des fédérés d’une même fédération.

2.8.4.4 Les avantages et inconvénients

Un des grands avantages de HLA est qu’il intègre, dès sa définition, la notion de simula-tion distribuée. De plus et de par l’emploi du code exécutable dans les fédérés, le standard HLA assure la protection intellectuelle des modèles de simulation. L’autre grand atout est la présence d’un mécanisme de gestion des temps qui prend en compte les différentes possibilités qu’offre la gestion coordonnée, la gestion par les messages pour les événements discrets, comme le temps réel, le tout au sein d’une même fédération. Cela permet d’utiliser des fédérés de natures différentes [DSC12].

Dans une simulation de type distribuée, [DSC12] précise que le manque de performance n’est pas forcement imputable au standard en tant que tel, ici le standard HLA, mais plutôt aux latences introduites par le réseau. À cet effet, il a été montré, en 1998 (projet européen

EDISON, projet OTAN34 « First Wave ») qu’HLA est capable de réaliser des simulations

temps réel, même sur des réseaux longue distance [DSC12].

Parmi les inconvénients, le standard HLA est un standard compliqué à utiliser [DSC12]. HLA demande une adaptation spécifique à chaque modèle. C’est une des raison pour

la-quelle, dans le cadre du projet GENESIS financé par la DGA35, l’ONERA36 a développé

un cadriciel pour concevoir, développer et générer automatiquement des HLA federate [Bou+05]. À cette difficulté consubstantielle au standard HLA, il apparaît que les RTI

34. Organisation du Traité de l’Atlantique Nord 35. Direction Générale de l’Armement

commerciaux (un par fédération, figure 2.20) peuvent être incompatible entre eux, à cause de différences dans la réalisation de l’architecture et protocole de communication entre le RTI et les fédérés. Il en résulte, contrairement à l’objectif initial d’interopérabilité, que des fédérés développés pour un RTI donné peuvent nécessiter une reprise pour fonctionner avec un autre RTI.

Il existe un autre standard de simulation FMI, développé à l’initiative de constructeurs au-tomobiles [FMI14]. À notre connaissance, il n’est pas décrit dans la littérature, les raisons pour lesquelles ce standard a été développé en lieu et place de l’utilisation du standard HLA. Ce standard FMI est décrit dans la section suivante.