Cette section décrit brièvement la norme HLA (High Level Architecture[23]), qui a été developpée par DMSO14 pour le département Américain de la défense DoD15. Elle
représente un outil industriel de co-simulation distribuée qui se compose globalement d’un ensemble de composants à base de modèles événementiels.
Le principal objectif de HLA est de développer une plate-forme distribuée facilitant l’interopérabilité et la réutilisabilité de simulateurs hétérogènes dans des applications. Pour réaliser une co-simulation type HLA, nous devons avoir trois éléments importants qui se résument comme suit :
— Federate : Dans la terminologie de la norme HLA, chaque modèle de simulation ou un système réel individuel est encapsulé dans un composant dit federate16.
Ces participants (federates) interagissent entre eux par l’intermédiaire du bus de co-simulation (RTI) ; un federate peut être de nature très différente des autres
federatesse trouvant dans le même système.
— Run-Time Infrastructure (RTI) : Les federates communiquent entre eux par des envois d’événements, à travers un bus de co-simulation dit Run-Time Infra-
structure. Autrement dit, les requêtes émises par ces federates seront routées vers
leurs destinations grâce à une interface de communication RTI, qui représente un point central. Ce bus de communication assure le contrôle de l’ensemble des fede-
rates, et garantit le bon fonctionnement de la co-simulation globale. Le RTI de la
norme HLA permet à la fois de faire communiquer et de synchroniser les différents
federatesdu système.
— La fédération regroupe et fait communiquer un ensemble de federates par un bus de communication RTI.
La figure 8 ci-dessous illustre l’architecture globale d’une co-simulation de type HLA qui
14. Defense Modeling and Simulation Office 15. Department of Defence
contient trois simulateurs sous forme de federates interconnectés entre eux par le bus d’événements RT I.
Figure 8 – Exemple d’une fédération HLA contenant trois simulateurs
Spécification de la norme HLA
Afin que l’ensemble des federates puissent s’interfacer avec le bus RTI, l’architecture HLA définit trois principaux composants permettant de garantir la correspondance sé- mantique de la co-simulation ; ces derniers sont présentés ci-après (d’après Okan Topçu et al [73] dans le chapitre 3) :
— Un ensemble de règles décrit les spécifications d’une fédération HLA, et les condi- tions pour ses participants (federates).
— Un modèle objet dit Object Model Template (OMT) spécifie l’ensemble des objets communs utilisés par une fédération afin de garantir l’interopérabilité de toutes les données du système. Notons que les fédérations doivent disposer d’un modèle d’objet (FOM)17de la fédération HLA pour définir les données du modèle
qui sont conformes au modèle objet (OMT).
— Interface Specification (IFSpec) représente une API. Elle fournit les différents services pour interfacer le bus d’événements (RTI) avec l’ensemble des federates.
Gestion du temps
La gestion du temps est ancrée dans le bus d’événements RTI qui permet à l’ensemble des federates de progresser dans le temps. Ce bus RTI définit une horloge logique globale et il s’appuie soit sur une méthode conservative, soit sur une méthode optimiste qui viole la contrainte de causalité (voir la section 2 de ce chapitre). De manière générale, dans une fédération, l’avancement du temps se réalisera selon les mécanismes ci-dessous :
•
Chaque federate a sa propre horloge locale interne appelée temps logique du fede-rate, et les différents federates sont enchaînés entre eux par un temps coordonné [28].
•
Généralement, la progression du temps d’un federate est définie par l’estampille du messagereçu.•
Si le bus RTI utilise une méthode optimiste, la simulation progresse plus vite mais un ou plusieurs federates peuvent recevoir des messages dans le passé, cela provo- quera des rollbacks pour que les federates reviennent à leur état cohérent. Ce type de méthode est peu utilisé dans la communauté HLA, car sa mise en œuvre devient rapidement complexe.•
On trouve, le plus souvent dans la littérature, des RTI qui s’appuient sur des méthodes conservatives qui n’acceptent pas de revenir en arrière et d’effectuer unrollback.
Limites de la norme HLA
Malgré sa capacité à traiter des systèmes complexes, plusieurs limitations pénalisent l’utilisation de cette norme.
1. La qualité du bus RTI : les spécificités se trouvant dans ce bus à événements sont souvent liées à son prix (les RTI libres sont les plus simples).
2. L’incompatibilité de cette norme avec d’autres simulateurs : On doit utiliser des simulateurs qui sont compatibles avec la norme HLA, or ce n’est pas tous les simu- lateurs existants qui peuvent fonctionner avec cette norme.
Il existe dans la littérature un formalisme qui est très utilisé dans les systèmes complexes, appelé le formalisme DEVS. DEVS ou Discrete EVent System specification a été introduit par B.P. Zeigler [79] pour modéliser un système quelconque. Il représente un formalisme modulaire qui permet de construire des modèles élémentaires ou composés. DEVS est un formalisme à événements qui considère que les informations échangées sont sous forme d’événements. Afin de reproduire le comportement exact du système, ce formalisme per- met de décrire son modèle structurel. Il permet en fait d’interconnecter différents modèles atomiques entre eux. Le modèle DEVS est un 7-uplet de la forme suivante :
M =< X, Y, S, ta, δext, δint, λ > (1.1)
•
X, Y représentent l’ensemble des événements entrants et sortants.•
ta(time advance) désigne la durée de vie d’un état si.•
δextreprésente la transition d’un état externe, c’est-à-dire une transition qui décrit la modification de l’état du système par un événement à son entrée.•
δint est la transition d’état interne qui révèle le changement de l’état du système pendant la durée de vie de l’état ta.•
λdésigne la fonction de sortie (les sorties du système).La figure 9 illustre un schéma du DEVS. Il existe des extensions de ce formalisme, et
Figure 9 – Schéma du principe du formalisme DEVS
on trouve : DESS (Differential Equation System Specification) [79] pour les systèmes dynamiques à temps continu, DEVS&DESS (Discrete EVent and Differential Equation
Specified Systems) [80] pour les modèles hybrides, G-DEVS (Generalized Discrete EVent System Specification) [78] pour résoudre les équations différentielles, etc.
5
Types de synchronisation pour la co-simulation
Cette section synthétise les trois principales techniques de synchronisation connues et adoptées par les différentes plates-formes de co-simulation présentées dans la sec- tion 6 [49].
1. Approche maître-esclave :
Les composants du système sont des esclaves. Un programme dit « maître » contrôle et orchestre l’ensemble des communications de toute la co-simulation. Dans la fi- gure 10-a, le programme qui supervise tous ces échanges se trouve dans le simulateur de réseau de télécom, comme dans l’article [51]. Notons que les nombres sur cette figure reflète l’ordre d’exécution des parties de la co-simulation globale.
2. Approche de Time-stepped :
Les simulateurs individuels du système global exécutent leurs simulations de ma- nière indépendante, mais ils arrêtent leurs simulations à des instants prédéterminés, i.e. des points de synchronisation. Ces points de rendez-vous représentent les ins- tants auxquels tous les simulateurs peuvent échanger des données entre eux, comme l’indique la Fig. 10-b. Ce mécanisme peut engendrer des erreurs cumulées dans le
système. Ce phénomène d’accumulation intervient en particulier lorsque le pas de temps est trop important par rapport à la dynamique du système. Ce mécanisme est aussi une source d’imprécision si l’application nécessite des interactions impré- vues et urgentes. Pour cette raison, la plupart des plate-formes ont renforcé cette méthode par l’ajout d’autres mécanismes (middlware), comme dans le cas de la solution présentée dans l’article [50].
3. Approche Global event-driven :
L’idée de ce mécanisme est de créer une liste globale qui sauvegarde à la fois les pas de temps venant des composants physiques, et les événements produits par des composants événementiels. Cette approche permet de traiter l’ensemble de ces données (requêtes) de manière séquentielle. Elle ne peut traiter qu’une seule requête à la fois, comme l’illustre la figure 10-c. Les autres requêtes placées en file d’attente doivent attendre la fin de l’exécution pour être traitées par ordre chronologique. Ce mécanisme évite les erreurs engendrées par la méthode Time-stepped, mais reste relativement limité par sa nature séquentielle et l’impossibilité de passer à l’échelle, comme c’est notamment le cas de la plate-forme [52].
Figure 10 – Types de synchronisation : (a) Approche de Maître-esclave (b) Méthode de Time-
6
Solutions pour la question du temps dans une co-simulation
Les difficultés majeures d’une co-simulation sont l’interopérabilité et l’interfaçage des composants hétérogènes entre eux, afin de les présenter comme un seul environnement de co-simulation. Néanmoins, cette intégration des composants hétérogènes s’appuie sur des modèles hybrides qui font progresser l’ensemble de la co-simulation. Dans cette section, nous nous sommes intéressés à la gestion du temps des premières solutions présentées dans la littérature. Pour cela, nous avons classifié ces différentes solutions en quatre catégories : celles fondées sur la norme HLA, celles fondées sur la norme FMI, celles fondées sur les deux normes (HLA et FMI), ou encore les solutions de type Ad Hoc fondés sur leurs propres modèles de temps (voir la figure 11). Notons que les performances de ces solutions sont rarement évoquées et décrites dans la littérature. C’est pourquoi nous avons développé une solution open source de co-simulation orientée performances, reposant sur le standard FMI (DACCOSIM).Figure 11 – Solutions de co-simulation