guide hla (high level...

MINISTÈRE DE LA DÉFENSE

DIRECTION GENERALE DE L'ARMEMENT

© DGA 2012 - Tous droits réservés

GUIDE S-CAT N° 10006

GUIDE HLA (HIGH LEVEL ARCHITECTURE)

5ème édition

approuvé le 22 octobre 2012

Guide entretenu par DS/CATOD

Rédaction Martin ADELANTADO ONERA-CT/DTIM/SER

Vérification Pascal CANTOT (RM ISE) DS/CATOD

Vérification Erik INGLOT (CCF SRO) DS/CATOD

Vérification Corinne MARGEZ DT/SDSP/MR Gestionnaire du référentiel

Vérification Hervé MORAILLON DT/ST/SDCT Responsable du processus MCT

Vérification Nathalie GUILLOU DT/SDP Responsable du processus RPT

Approbation Alain DOHET DT/SDCT RP SDS

L’édition en vigueur de ce document est celle accessible via l’intranet Totem, sur le site SIRIUS. S’assurer de la validité de toute copie avant usage.

Guide S-CAT n° 10006 Ed05 2 / 149 © DGA 2012 - Tous droits réservés

ÉVOLUTIONS

Edition Date Nature de l’évolution

1ière 19/12/2005 Création du document

2 ième 15/11/2006 Nouvelle version du document en annexe

3 ième 03/03/2008 Mise à jour 2007 du guide HLA produit par le consortium Cap Gemini ONERA dans le cadre du PEA ARCOSIM HLA

4 ième 18/02/2010 Mis à jour de la réorganisation DGA de fin 2009

5ième 22/10/2012 Prise en compte de la réorganisation de la DGA et du métier (changement sigles)

DOCUMENTS ABROGES PAR LA PRESENTE EDITION

Référence Date Objet

RATTACHEMENTS DE LA PRESENTE EDITION (griser les cases si non remplies)

Pôle Métier Emplois de référence

SDS ISE

Processus niveau 2 Activités Secteurs-clés CMMI

MCT 1

RPT 4

Veille technique et Capitalisation des connaissances techniques

Réaliser la prestation


TABLE DES MATIÈRES

1 INTRODUCTION : OBJECTIF DU DOCUMENT............................................................................... 8

2 GENERALITES SUR HLA...................................................................................................................... 9

2.1 HISTORIQUE ET PRINCIPES DE LA SIMULATION DISTRIBUEE HLA............................................................ 9 2.1.1 Un peu d’histoire ........................................................................................................................... 9 2.1.2 Principe de la HLA ...................................................................................................................... 11

2.2 DESCRIPTION FONCTIONNELLE ET VOCABULAIRE ................................................................................. 12 2.2.1 Les fédérés ................................................................................................................................... 13 2.2.2 L’infrastructure d’exécution ou Run-Time Infrastructure ........................................................... 14 2.2.3 L'interface normalisée ................................................................................................................. 14

2.3 LA NORME HLA.................................................................................................................................... 15 2.4 LES COMPOSANTS DE LA NORME HLA.................................................................................................. 16

2.4.1 Les règles..................................................................................................................................... 16 2.4.2 Les spécifications de l'interface de programmation (API)........................................................... 16 2.4.3 L'OMT (Object Model Template)................................................................................................. 17 2.4.4 L’Overlay VV&A ......................................................................................................................... 18 2.4.5 Le DSEEP (Distributed Simulation Engineering and Execution Process) .................................. 19

2.5 LES MECANISMES DE BASE DE HLA...................................................................................................... 19 2.5.1 Le modèle objet de HLA et le support de communication ........................................................... 19 2.5.2 Les services fondamentaux offerts par HLA ................................................................................ 21 2.5.3 Schéma classique du déroulement de l'exécution d'une fédération ............................................. 22 2.5.4 Principes de base de la gestion du temps .................................................................................... 24

2.6 LES NORMES HLA ................................................................................................................................ 26 2.6.1 La norme US DoD 1.3 (obsolète, mais encore présente)............................................................. 26 2.6.2 La version 2000 de IEEE 1516 de HLA (encore bien présente) .................................................. 26 2.6.3 La version 2010 de IEEE 1516 de HLA (version actuelle) .......................................................... 26

2.7 LES MALENTENDUS SUR HLA............................................................................................................... 27 2.7.1 Le "miracle" HLA ........................................................................................................................ 27 2.7.2 HLA comme aide à la conception et le développement des simulations ...................................... 27 2.7.3 Les performances des simulations distribuées sous HLA ............................................................ 28 2.7.4 La HLA, norme du Département de la Défense US ou norme "civile"? ...................................... 28 2.7.5 Le coût de la HLA........................................................................................................................ 29 2.7.6 Les limites de la HLA liées aux infrastructures d’exécution (RTIs) ............................................ 30

2.8 L’INTERET DE LA NORME HLA ............................................................................................................. 30 2.8.1 De l'intérêt d'utiliser des normes et HLA, en particulier ............................................................. 30 2.8.2 Les avantages techniques de la HLA ........................................................................................... 31 2.8.3 La HLA et la promotion des bonnes pratiques ............................................................................ 32 2.8.4 La HLA, modèle de norme ........................................................................................................... 33

3 METHODOLOGIES DE CONCEPTION SOUS HLA ....................................................................... 34

3.1 CONCEPTION DE SIMULATIONS DISTRIBUEES ........................................................................................ 34 3.1.1 Le DSEEP.................................................................................................................................... 34 3.1.2 Le RPR-FOM............................................................................................................................... 37

3.2 CONCEPTION DE SIMULATIONS CONFORMES A HLA ............................................................................. 37 3.2.1 Développer de nouvelles simulations conformes à HLA.............................................................. 38 3.2.2 Adapter une simulation préexistante à HLA................................................................................ 39

4 LES OUTILS HLA.................................................................................................................................. 43

4.1 LES OUTILS INDISPENSABLES ................................................................................................................ 45 4.2 LES OUTILS UTILES................................................................................................................................ 46 4.3 LES OUTILS COMPLEMENTAIRES DONT ON PEUT SE PASSER................................................................... 47 4.4 CONCLUSION ........................................................................................................................................ 47


5 LA CERTIFICATION DE CONFORMITE A HLA DES FEDERES ............................................... 48

5.1 PRINCIPES DE LA CERTIFICATION DES FEDERES ..................................................................................... 48 5.2 LE PROCESSUS DE CERTIFICATION DES FEDERES ................................................................................... 49

5.2.1 Remarques générales................................................................................................................... 49 5.2.2 Les étapes du processus de certification...................................................................................... 49

6 AIDE A LA REDACTION DES CAHIERS DES CHARGES ............................................................ 52

6.1 REFERENCES PRINCIPALES A INSERER ................................................................................................... 52 6.2 SPECIFICATIONS DU BESOIN .................................................................................................................. 52 6.3 NORMES APPLICABLES .......................................................................................................................... 53 6.4 EXIGENCES ET/OU INFORMATIONS A PRECISER...................................................................................... 53

6.4.1 Exigences communes ................................................................................................................... 53 6.4.2 Exigences particulières................................................................................................................ 54

6.5 OUTILS DE SOUTIEN .............................................................................................................................. 54 6.6 CERTIFICATION DE CONFORMITE A LA NORME ...................................................................................... 55 6.7 FOURNITURES ....................................................................................................................................... 55

7 LES PERSPECTIVES AUTOUR DE HLA .......................................................................................... 56

7.1 L'ARCHITECTURE TENA (TEST & TRAINING ENABLING ARCHITECTURE)............................................ 56 7.1.1 Contexte et objectif ...................................................................................................................... 56 7.1.2 Architecture et applications TENA .............................................................................................. 57 7.1.3 Principes fondamentaux de TENA : modèles et applications ...................................................... 59 7.1.4 Le TENA repository et les outils .................................................................................................. 62 7.1.5 TENA et les normes DIS et HLA.................................................................................................. 63 7.1.6 Les plateformes supportées par l’intergiciel TENA version 6.0.1 ............................................... 64 7.1.7 Exemples d’utilisation de l’architecture TENA ........................................................................... 64 7.1.8 Conclusion ................................................................................................................................... 65

7.2 LES HLA BOMS (BASE OBJECT MODELS) ........................................................................................... 66 7.3 BOMS ET MODULES FOM.................................................................................................................... 73 7.4 SOA...................................................................................................................................................... 73 7.5 LVC AR (LIVE VIRTUAL CONSTRUCTIVE ARCHITECTURE ROADMAP)................................................. 74

7.5.1 Bref historique ............................................................................................................................. 74 7.5.2 Conclusions et recommandations ................................................................................................ 75

7.6 CONCLUSIONS....................................................................................................................................... 78

8 ANNEXES ................................................................................................................................................ 79

8.1 ANNEXE A : DOCUMENTS DE REFERENCE ............................................................................................. 79 8.2 ANNEXE B : BIBLIOGRAPHIE................................................................................................................. 81 8.3 ANNEXE C : COMPLEMENTS SUR L'ARCHITECTURE HLA...................................................................... 84

8.3.1 Les règles HLA [A1].................................................................................................................... 84 8.3.2 L'object model template (OMT) et ses composants [A3] ............................................................. 85 8.3.3 L'architecture de la RTI............................................................................................................... 90 8.3.4 Les composants d'un fédéré HLA................................................................................................. 91 8.3.5 La sémantique des données échangées au sein d'une fédération................................................. 92 8.3.6 Les services fondamentaux offerts par la norme HLA IEEE 1516-2010[A2].............................. 92 8.3.7 La gestion du temps ................................................................................................................... 104 8.3.8 Gestion des callbacks ................................................................................................................ 108 8.3.9 Le document FDD...................................................................................................................... 109 8.3.10 Déclinaison des spécifications d’interface sur les langages de programmation ....................... 109

8.4 ANNEXE D : MIGRATION DE FEDERES US DOD 1.3 VERS LA NORME IEEE 1516-2010....................... 111 8.4.1 Introduction ............................................................................................................................... 111 8.4.2 Quelques exemples de migration avec l’API C++ .................................................................... 111

8.5 ANNEXE E : LES DIFFERENCES ENTRE LA NORME IEEE 1516-2000 ET LA NORME US DOD 1.3.......... 118 8.5.1 Introduction ............................................................................................................................... 118 8.5.2 Evolution des spécifications d'interface (document IEEE 1516.1-2000)................................... 118 8.5.3 Evolution du modèle objet OMT (document IEEE 1516.2-2000) .............................................. 122 8.5.4 Evolution du modèle d'exécution ............................................................................................... 125 8.5.5 Evolution de l'API C++ de la RTI ............................................................................................. 126

8.6 ANNEXE F : LES APPORTS MAJEURS DE LA NORME IEEE 1516-2010 A LA NORME IEEE 1516-2000 .. 135


8.7 ANNEXE G : SITUATION DES GROUPES DE NORMALISATION A LA SISO (MARS 2011) ......................... 142 8.7.1 Product Support Groups (PSG)................................................................................................. 142 8.7.2 Product Development Groups (PDG)........................................................................................ 142 8.7.3 Study Groups (SG)..................................................................................................................... 142 8.7.4 Standing Study Groups (SSG).................................................................................................... 143

8.8 ANNEXE H : TERMINOLOGIE ............................................................................................................... 144


Avant-propos Ce document est destiné à trois catégories de lecteurs :

• Les directeurs de programme, directeurs de centre, etc. que nous appelons dans la suite les « managers de haut niveau » ; ils souhaitent disposer d’un aperçu rapide et relativement neutre de ce qu’est l’architecture de haut niveau (désignée dans le document par l’acronyme anglo-saxon HLA, pour « High Level Architecture »), comprendre quels bénéfices on peut en attendre en terme de coût et d’efficacité des systèmes de simulation, en général,

• les « demandeurs » de systèmes de simulation et les chefs de projet (les architectes), que nous appelons globalement « chefs de projet » qui doivent avoir une vision plus approfondie de ce qu’apporte la HLA, des bénéfices qu’elle procure, mais aussi des contraintes qu’elle impose, en terme de délais et coûts,

• les analystes, les concepteurs et développeurs de systèmes de simulation qui doivent connaître de façon précise la norme HLA ainsi que la méthodologie et les outils qui permettent de la mettre en œuvre. Nous les appellerons globalement les « développeurs ». Ils doivent être capables de comprendre la HLA en profondeur, c’est-à-dire connaître les interprétations courantes de la norme, la mise en œuvre des concepts et des outils associés.

Les managers de haut niveau peuvent se contenter de lire le chapitre 2 "Généralités sur HLA", en particulier les paragraphes 2.1, 2.2, 2.7 et 2.8.

Les chefs de projet doivent impérativement lire les chapitres 1 à 5, et aussi 6, de ce guide et en avoir une compréhension claire.

Enfin, les développeurs doivent être capables de comprendre et d'utiliser la totalité de ce guide. Pour eux, ce document n’a pas l’ambition de remplacer une formation approfondie à la HLA (avec exercices pratiques), ni la pratique, qui sont seules susceptibles de former des "experts HLA". Il ne dispense pas non plus d’acquérir et d’étudier les 3 documents décrivant la norme HLA IEEE1 1516-2010 (références [A1] à [A4]), celui décrivant la norme "DSEEP", "Distributed Simulation Engineering and Execution Process" (référence [A16]), ainsi que le document normatif IEEE 1516.4-2007 accompagnant la norme HLA 1516-2010 en ce qui concerne les pratiques recommandées dans le domaine de la VV&A (référence [A4]). Ces derniers constituent une documentation indispensable aux équipes de développement. Ce guide doit être considéré comme un facilitateur à l'appréhension de la norme qui, comme tous les documents normatifs, n’a pas vocation didactique. En outre, les documents décrivant la HLA donnent peu d’informations pratiques sur son utilisation, en général.

Les premières versions de ce guide ont été réalisées dans le cadre du marché « Etude, mise en œuvre et maintien d'une capacité de certification HLA », n° 02.34.032.00.470.75.65 en coopération entre l’ONERA et Capgemini, sous la responsabilité de la DGA. Ce marché a pris fin en juillet 2007.

Ce guide a ensuite été maintenu jusqu’en 2009 par Jean-Louis IGARZA (DGA, CAD) et Martin ADELANTADO (ONERA, Centre de Toulouse) en dehors de tout contexte contractuel. La mise à jour actuelle est réalisée dans le cadre du marché « INTERVAL : Expertise ONERA sur les Normes d’Interopérabilité des Simulations et la VV&A », n° 2009 04 054 00 470 9150, par Martin ADELANTADO et Jean-Louis IGARZA (ANTYCIP SIMULATION).

1 Institute of Electrical and Electronical Engineers : organisme savant à vocation internationale qui a une activité importante de normalisation (www.ieee.org).


Dans le cadre de ce marché, il est prévu de mettre à jour ce guide annuellement, en fonction des évolutions de l’état de l’art, des leçons tirées de la pratique de la norme, des suggestions et des critiques envoyées à l’auteur. Il faut également souligner que la présente mise à jour couvre la période allant de janvier 2009 à avril 2011, date des ateliers SIW de printemps qui ont eu lieu à Boston du 4 au 8 avril 2011.

Ce guide a été élaboré grâce aux nombreuses informations collectées au cours des ateliers SISO2, à la connaissance et la pratique de l’architecture HLA, à l’expérience des auteurs dans l’enseignement de HLA, leur participation à l'élaboration de la norme au sein de la SISO et dans le suivi des certifications de conformité à la norme. Jusqu’en juillet 2007, il a également bénéficié des nombreuses relectures et contributions diverses de Claude Hervé et Régis Mauget, de Capgemini ainsi que de celles d’autres relecteurs ou contributeurs de la DGA ou de l’industrie.

2 "Simulation Interoperabilty Standards Organization", société internationale qui développe les normes HLA au profit de l'IEEE.


1 INTRODUCTION : OBJECTIF DU DOCUMENT

L'objectif de ce guide est de fournir les éléments de compréhension non seulement de l'architecture HLA, mais également des aspects méthodologiques liés à la conception de « fédérés » et de « fédérations » (termes HLA définis précisément au paragraphe 2.1), et enfin de présenter un certain nombre d'outils classés d'indispensables ou complémentaires facilitant la conception, l'exécution ou l'exploitation des résultats des simulations HLA. Ce guide n'est pas un manuel de référence de HLA, mais un document dont la principale vocation est de clarifier ce qu'est HLA, ce qu'elle permet de faire, mais également de lever certains malentendus sur ses capacités. En 2009, il a été complété par un chapitre donnant des recommandations pour la rédaction de cahiers des charges où l'emploi de HLA est demandé. Ce guide est organisé en 7 chapitres et des annexes :

Le chapitre suivant présente les généralités sur HLA, c'est-à-dire les fondamentaux permettant de comprendre les atouts de l'architecture ainsi que de lever les malentendus les plus répandus.

Dans le troisième chapitre, nous présenterons les méthodologies de conception des systèmes de simulation HLA.

Le quatrième chapitre est consacré à une description des principaux outils actuellement disponibles autour de la HLA.

Le cinquième chapitre aborde les aspects de la certification de fédérés HLA.

Le sixième chapitre donne des recommandations pour la rédaction de cahier des charges pour des prestations où HLA est demandé,

Enfin, dans le dernier chapitre, un certain nombre de perspectives autour de la norme HLA sont proposées.

En dehors des 2 annexes fournissant les documents de référence et la bibliographie (Annexes 7.1 et 7.2), les autres annexes abordent les sujets suivants :

L’annexe 7.3 fournit des compléments plus techniques de l’architecture HLA,

L’annexe 7.4 présente des recommandations pour migrer des fédérés US DoD 1.3 vers la norme IEEE 1516-2010,

L’annexe 0 récapitule les apports de la norme IEEE 1516-2000 à la norme US DoD 1.3. Cette annexe est intéressante pour ceux qui souhaiteraient évaluer le travail de migration de fédérés US DoD 1.3 à la norme IEEE 1516-20003 ou IEEE 1516 2010.

L’annexe 0 présente les nouvelles fonctionnalités disponibles dans la norme IEEE 1516-2010 par rapport à la norme IEEE 1516-2000,

Enfin, les annexes 7.7et 7.8 décrivent respectivement la situation des groupes de normalisation à la SISO en mars 2011 et la terminologie utilisée dans ce guide.

3 C’est ce passage à la norme IEEE 1516-2000 qui constitue un véritable « saut technologique », la norme IEEE 1516-2010 se distinguant de la norme précédente presque exclusivement par l’ajout de nouvelles fonctionnalités bien identifiées, sans toutefois remettre en cause le cœur de l’architecture.


2 GENERALITES SUR HLA

2.1 Historique et principes de la simulation distribuée HLA

2.1.1 Un peu d’histoire

2.1.1.1 La « simulation distribuée » HLA est une norme pour le développement de « systèmes de simulation distribués4 ».

Les termes « système de simulation distribué » ou « simulation distribuée » désignent un ensemble de composants interagissant sur un réseau (local ou distant) constituant un système de simulation. Ces composants peuvent être :

• des applications de simulation numérique (appelées « simulations constructives » dans le jargon actuel),

• des simulateurs pilotés (avec homme dans la boucle mettant en œuvre du matériel simulé en totalité, généralement "temps réel", (appelés "simulations virtuelles" dans le jargon actuel),

• des simulations "vivantes et/ou instrumentées" (exercices ou expériences avec des hommes dans la boucle mettant en œuvre du matériel réel ou en partie simulé, évidemment "temps réel"),

• des outils divers, généralement logiciels, pour gérer le système et ses données, visualiser, superviser, etc.

Pour approfondir cette définition, on notera qu’on utilise souvent l’expression "simulation interactive distribuée" qui rappelle l’importance des opérateurs (appelés quelquefois "joueurs") dans la mise en œuvre du système, et souligne le fait qu’ils en font partie intégrante. Le réseau et les logiciels utilitaires divers qui permettent aux composants de fonctionner ensemble font également partie du système de simulation. Opérateurs, réseau et logiciels de servitudes constituent une part importante du système de simulation et contribuent fortement à sa complexité.

D’autres termes plus ou moins synonymes de "système de simulation distribué" sont utilisés par tout ou partie de la communauté de la simulation :

• Les Britanniques et les Canadiens utilisent largement l’expression "Environnement Synthétique5" au lieu de "système de simulation distribué6". Ces deux termes ne sont pourtant pas exactement synonymes : "système de simulation distribué" ou "simulation interactive distribuée" sont des termes plutôt utilisés par les développeurs. Le terme "environnement synthétique » correspond plus une vision du client/utilisateur du système à des fins d’entraînement, d’études, etc. On trouve également quelquefois le terme synonyme "environnement virtuel" utilisé alors par opposition au terme "monde réel". Plus récemment, les américains ont introduit un nouveau terme: "environnement de simulation", aussi vague que le terme "environnement synthétique".

• La HLA a introduit le terme de « fédération » pour désigner un « système de simulation distribué »; les composants d’une fédération HLA (simulations, simulateurs, systèmes réels et outils divers) sont appelés de façon générique « fédérés ». Ces deux termes (fédération et fédérés7) sont ceux utilisés exclusivement dans le contexte HLA.

4 On notera que « distribué » est accordé avec « système » : il s’agit bien d’un système distribué de simulation. On trouvera aussi dans ce document l’expression « simulation distribuée ». 5 Synthetic Environment (SE). Cette expression est aussi utilisée par d’autres membres de la profession (surtout américains) pour parler de la représentation de l’environnement naturel et humain. 6 Chez les Britanniques et les Canadiens, les expressions « simulation distribuée » ou « simulation interactive distribuée » font souvent référence à un ensemble de technologies plutôt qu’à un système de simulation. 7 On trouve parfois le terme générique « Federated Simulation Systems » pour désigner les simulations distribuées.


Dès 1998, le Département de la Défense américain (US DoD) s’est engagé résolument et officiellement dans la direction de la simulation distribuée sous l’hypothèse que la simulation, comme toute l’activité informatique actuelle et future, ne pouvait être que fondée sur des architectures distribuées. Ceci explique l’importance de la HLA dans la "communauté" Modèles & Simulations (M&S).

De fait, la naissance de la « simulation distribuée » est bien antérieure à 1998 et les États-Unis s’y intéressaient dès les années 80. Pour des raisons de commodité, on situe le début réel de la simulation distribuée en 1987, qui correspond à la capacité opérationnelle initiale du projet SIMNET (voir ci-dessous) et au début de la promotion du concept de la simulation distribuée par l'US DoD.

2.1.1.2 La montée en puissance des systèmes de simulation distribués

Historiquement on considère que les premières8 simulations distribuées ont été développées aux États-Unis, vers la fin des années 80. La première application notable avait comme objectif principal d’améliorer l’entraînement collectif d’unités de l’US Army (chars et hélicoptères, au niveau tactique). Cette expérience a été appelée SIMNET pour « SIMulators NETworking ».

SIMNET a permis de démontrer :

• l’intérêt du concept de la simulation distribuée (pour l’entraînement, en particulier) et sa faisabilité,

• l’importance de définir des normes d’interopérabilité9 des simulations/simulateurs pour pouvoir construire des systèmes de simulation distribués en réutilisant des systèmes existants et en minimisant ainsi le besoin de développer constamment de nouveaux systèmes.

A la suite de SIMNET, différentes normes d’interopérabilité des simulations ont vu le jour. On en citera deux :

• ALSP : pour interconnecter des simulations constructives événementielles (début des années 90), essentiellement aux Etats-Unis (quelques expériences à l’OTAN et en France dans le cadre de l'OTAN, vers 1995).

• DIS : pour interconnecter des simulateurs pilotés « temps réel » (norme IEEE 1278 de 1995) dérivée de SIMNET et qui a eu un succès indéniable en Europe et au Royaume-Uni, en particulier.

En parallèle à ces efforts de la communauté de la simulation, des efforts industriels ont conduit au développement de CORBA, norme « orientée objet » pour les systèmes distribués. CORBA n’est pas spécifiquement dédié à la simulation mais est toujours utilisé aujourd’hui dans le domaine de la simulation distribuée. CORBA est cité ici car il a eu une influence dans la conception de HLA.

2.1.1.3 L'apparition de la HLA et sa normalisation

Vers le milieu des années 90, dans le but de rationaliser et d’accompagner les efforts de développement de normes diverses, le Département de la Défense des États-Unis (US DoD) décida de développer sa propre norme : la HLA. La HLA était alors sensée remplacer toutes les autres technologies ou normes (telles que DIS ou ALSP).

La version préliminaire de la HLA fut publiée en 1996 et la première version stabilisée et réellement opérationnelle de l'architecture apparut en 1998 (version 1.3 de l’US DoD). Le développement de la HLA a été inspiré par les efforts précédents (un peu par DIS, fortement par ALSP et aussi par CORBA). Ce faisant, l’émergence de la HLA a interrompu les efforts de normalisation précédents (DIS et ALSP), mais pas celle de CORBA qui avait un spectre plus étendu et était soutenu par la large communauté du logiciel.

8 Au sens de celles qui ont été fortement médiatisées ! Il est difficile de dire de quelle époque exacte date « la première simulation distribuée », mais c’est probablement antérieur aux premières médiatisations. 9 La simulation distribuée nécessitant la mise en place de mécanismes permettant aux simulations/simulateurs d'échanger des informations structurées.


Afin de garantir la pérennité de HLA, le DoD a favorisé le développement d’une version civile de la norme (norme IEEE 1516-2000 approuvée en septembre 2000, (références [A5] à [A7])10.

Parallèlement au développement de normes, le DoD a recherché constamment de nouveaux utilisateurs : ces efforts ont été couronnés de succès avec une large acceptation de la norme à l’OTAN, en Europe, en Australie et Asie et, également, dans d’autres domaines plus ou moins proches du domaine militaire (médecine, sécurité civile, énergie, aviation civile et espace). La mise à disposition gratuite et sans contrainte11 par le DoD d’outils de conception, de développement et de mise en œuvre de la HLA a aidé cette diffusion à la communauté internationale, cet élargissement ayant favorisé, dans un premier temps, l’adoption de la version 1.3 (US DoD) de la HLA. La norme "civile" IEEE 1516 a été plus lente à s’imposer12 compte tenu du temps nécessaire à la mise sur le marché d’outils commerciaux associés à la nouvelle version. L’année 2004 peut être considérée comme la première année du véritable déploiement industriel de la norme IEEE bien que, aux US,13 la norme US DoD 1.3 ait curieusement survécu.

Récemment, la norme IEEE 1516-2000 a évoluée vers la norme IEEE 1516-2010 (appelée HLA-Evolved pendant la phase de normalisation) (références [A1] à [A3]).

Pour plus de détails sur l'historique de la normalisation de HLA, on se reportera à la section 2.6.

2.1.2 Principe de la HLA

2.1.2.1 Les objectifs

La HLA est une norme qui a 2 objectifs principaux :

• l’interopérabilité des simulations/simulateurs,

• leur réutilisation dans des applications pour lesquelles elles /ils n’ont pas toujours été conçus au départ.

Ce deuxième objectif sous-entend des problèmes de validation et re-validation des simulations, aspects qui sont peu abordés dans ce guide dont ce n’est pas l’objectif principal. L’importance du processus de validation des simulations n’est pas sous-estimée et de nombreux travaux sur ce thème ont eu lieu, certains soutenus par la DGA et l'ONERA, se déroulant dans un contexte international (guides OTAN, ITOP, IEEE et SISO parus ou en cours de rédaction). En 2007, la norme IEEE 1516 a été complétée par un guide sur la VV&A des fédérations HLA ("VV&A Overlay to the FEDEP", IEEE Std 1516.4-2007, référence [A4]). A l’heure de la mise à jour de ce guide, une méthodologie générique pour la VV des simulations/simulateurs, baptisée GM-VV14, est en cours de normalisation à la SISO (référence [A17]).

Il est clair que la réutilisation doit se comprendre dans le contexte de systèmes de simulation distribués : il s’agit de réutiliser des simulations/simulateurs intégralement. D’autres concepts de réutilisation existent tels que les "structures d’accueil" de simulations ou les "environnements de développement et d'exploitation de simulations" (EDES: LIGASE ou DirectSim de la DGA en sont des exemples).

10 Pour ce faire le DoD a promu la création d’un organisme de soutien à l’IEEE spécialisé dans la simulation : la SISO (Simulation Interoperability Standards Organization). La SISO a développé la norme HLA 1516 au profit de l’IEEE. Depuis sa création en 1997, la SISO est devenue indépendante du DoD. Elle est largement ouverte à la communauté internationale et ne coopère pas uniquement avec l’IEEE : par exemple, elle soutient l’ISO pour le développement de SEDRIS (Synthetic Environment Data Representation and Interchange Standard) et travaille aussi avec la SCS (Société Internationale pour la Modélisation et la Simulation). 11 Mais cela s'est arrêté en 2002 et l'on ne trouve plus aujourd'hui que des produits commerciaux et quelques produits libres. 12 A l’exception notable de la Suède qui a été la nation pilote de la norme IEEE 1516-2000 et IEEE 1516-2010. 13 Paradoxalement l’Europe l’a adoptée plus rapidement et utilisée effectivement en 2003 (toujours sous l’impulsion de la Suède). 14 Generic Methodology for Verification and Validation.


Ces EDES proposent de réutiliser des composants (des modèles, des outils ou plus généralement des "morceaux" de simulation) dans un environnement particulier de développement et d’exploitation, et n’ont pas le caractère supposé « d’universalité » d'une norme telle que la HLA.

Il faut toutefois noter que l’utilisation de la norme HLA, seule, n’est pas suffisante pour garantir la réalisation complète de ses 2 objectifs principaux : par exemple, aucune réutilisation ne peut intervenir sans la création, le peuplement et le maintien de bibliothèque(s) de ressources de simulation (la "capitalisation").

HLA offre des conditions minimales, compte tenu de l'état de l'art, pour assurer l’interopérabilité technique des simulations : concernant l’interopérabilité des systèmes informatiques en général, une échelle a été publiée par la SISO pour caractériser les niveaux d’interopérabilité des systèmes. Elle va de 0 (pas d’interopérabilité possible) à 5 : HLA y apparaît dans les niveaux 1 et 2, voire 315. C’est reconnaître qu’il y a encore des progrès à faire pour aller au-delà de la norme HLA. Toutefois un large consensus s’est établi à propos de la HLA pour reconnaître que, bien que cette norme ne satisfasse pas complètement un objectif très ambitieux d'interopérabilité16, elle contribue fortement à la satisfaction de ses 2 objectifs et que, en tant que norme d'interconnexion de simulations, c’est la meilleure solution technique actuelle.

2.1.2.2 « Architecture » et « haut niveau »

Le terme « architecture » désigne ici :

« Les éléments fonctionnels principaux, les interfaces et les règles de conception applicables à toutes applications de simulation. Ces éléments constituent la définition d’une infrastructure commune générique à partir de laquelle on peut définir des architectures spécifiques de systèmes»17.

Cette définition est inspirée de la définition IEEE d’une architecture.

On notera que cette définition ne fait pas référence à la façon d’implémenter les concepts : on verra que la norme HLA ne donne ni indication, ni contrainte sur la façon d’implémenter l’architecture. Elle laisse aux développeurs la liberté de choisir les solutions matérielles et logicielles (y compris les aspects communication et réseau) les plus adaptées à leur problème et à leur environnement habituel de travail.

Dans les textes de la norme HLA, on ne fait jamais référence à l’utilisation de plates-formes de développement particulières : ni système d’exploitation, ni environnement particulier de développement (EDES), ni protocole réseau, etc. C’est en ce sens que la HLA peut être qualifiée de « haut niveau ». Cela implique également que la norme HLA en elle-même n’apporte aucune infrastructure technique pour le développement de modèles et de simulations : une fois le choix de HLA fait, il appartient aux développeurs de choisir leur infrastructure de développement propre en fonction de leurs objectifs et contraintes, dans le respect de la norme.

2.2 Description fonctionnelle et vocabulaire

Une fédération HLA désigne un système de simulation distribué faisant intervenir un ensemble de simulations élémentaires s'échangeant des informations et appelées fédérés. Un fédéré HLA n’est pas obligatoirement une simulation : ce terme désigne tout participant matériel ou logiciel d’une fédération.

15 La norme DIS est citée au niveau 1, comme un « patch manuel » le serait. Le gros reproche fait à DIS est surtout son insuffisance en tant que norme qui oblige chaque nouvelle application à réinventer ses propres messages et donc à s’éloigner de la norme ! 16 Voir le sous-chapitre 2.6. 17 D’après le docteur Judith DAHMANN reconnue comme la principale inventrice de la HLA : “major functional elements, interfaces, and design rules, pertaining as feasible to all simulation applications, and providing a common framework within which specific system architectures can be defined".


Figure 1 Fédération HLA

La norme HLA décrit un système de simulation distribué (une « fédération ») comme un ensemble de 3 composants :

1. les « fédérés »,

2. l’infrastructure d’exécution,

3. l’interface normalisée.

Ces 3 composants sont classiquement représentés dans le schéma précédent (Figure 1) dans l’ordre (1), (3), (2) du haut vers le bas.

2.2.1 Les fédérés

Comme on l’a dit plus haut les fédérés peuvent être de nature très différente et, pour démontrer cette possibilité, lors des débuts de HLA, des fédérations prototypes ont été développées dans des domaines d’application très différents :

• interconnexion de simulateurs pilotés pour soutenir l’entraînement collectif des équipes de pilotes/opérateurs,

• fédération de simulations numériques air-terre-mer en soutien d’entraînement d’état-major interarmées,

• plates-formes d’évaluation avec du matériel dans la boucle,

• simulations d’études,

• etc.

Le rôle principal des fédérés dans un système de simulation distribué est de représenter les systèmes réels à simuler. Les fédérés peuvent être quelquefois les vrais systèmes réels18 et non pas des simulations/simulateurs. C'est pour ces systèmes réels que l'on parle de "simulations vivantes" ("Live").

Parmi les "fédérés" candidats dits "vivants" (réels), il faut mentionner les "systèmes d’information opérationnels et de communication" (SIOC). On leur a accordé une priorité particulière dès la conception de la HLA, considérant l'importance des besoins d’interopérabilité entre SIOCs et simulations à des fins d’entraînement des états-majors.

18 Il peut s'agir de systèmes réellement opérationnels et, dans ce cas, le « fédéré » interagira avec la fédération via une interface logicielle.


Ces systèmes posent des problèmes spécifiques, dus (entre autres) à la diversité de leurs implémentations : la HLA seule ne répond aujourd’hui que très partiellement aux besoins d’interopérabilité entre SIOCs et simulations. Comme pour la validation, ce problème est traité dans beaucoup d’instances (à l’OTAN et à la SISO, par exemple). Ils font l'objet d'efforts de standardisation, tels C-BML19 qui sont de nature très différente de celle de HLA.

2.2.2 L’infrastructure d’exécution ou Run-Time Infrastructure

La Run-Time Infrastructure (appelée RTI dans la suite) constitue une implémentation informatique des spécifications d'interface de la HLA. Il s'agit d'un ensemble de processus informatiques écrit dans un langage de programmation donné, qui joue le rôle d'un système d'exploitation distribué réduit. Ce logiciel permet à plusieurs fédérés constituant une fédération de s'échanger des données pendant la simulation, au travers d'un réseau local ou longue distance. Les mécanismes de base supportant la communication entre fédérés ainsi que les services offerts par la RTI seront présentés dans la suite.

La RTI est donc un logiciel qui permet aux fédérés de communiquer des informations de façon "propre" et de synchroniser les échanges entre fédérés. Ce logiciel distribué cache, en particulier, les aspects « bas niveau » (réseau et communication) aux utilisateurs. La RTI a aussi le rôle difficile d’assurer la synchronisation temporelle entre les fédérés permettant par exemple d’assurer un fonctionnement correct entre des simulateurs « temps réel » et des simulations constructives « non temps réel » (qu’on appelle quelquefois « aussi vite que possible »). Le paragraphe suivant décrit de façon plus détaillée le fonctionnement et le rôle spécifique de la RTI.

Contrairement à une pensée courante mais erronée, la RTI n’est pas un logiciel "standard". Il en existe plusieurs implémentations, d’origine étatique, universitaire ou commerciale. Elles ont des qualités, des performances et des coûts différents, mais doivent toujours respecter les spécifications de la norme.

Le DoD a mis en place un service de vérification20 de conformité des RTIs à la norme HLA : à ce jour, seul un petit nombre de RTIs sont certifiées. Lorsqu’une RTI est certifiée, c’est une garantie qu’elle soutient la totalité des services décrits dans la norme. Il est évidemment recommandé de n’acquérir que des RTIs certifiées.

Les différentes RTIs du marché peuvent être implantées sur des plates-formes différentes21 et utilisent quelquefois des protocoles réseaux différents. Leur implantation peut reposer sur des technologies différentes (par exemple, Java ou CORBA), ce qui implique que l’on ne peut mettre en œuvre deux fédérés utilisant 2 RTIs différentes (même si des travaux en ce sens ont été entrepris qui devraient aboutir très bientôt). Mais, elles ont toutes en commun les services qu’elles offrent et qu’elles sont capables d’exploiter dans un système de simulation distribué. Dans tous les cas, tous les services sont offerts ou accédés via une interface normalisée.

2.2.3 L'interface normalisée

La RTI n’est donc pas un logiciel unique, ni standard, mais son interface avec les fédérés est, elle, normalisée. C’est cette normalisation qui assure l’interopérabilité des simulations et leur capacité à évoluer d’une fédération HLA à une autre. C’est aussi ce qui assure qu’on peut choisir différentes RTIs dans différentes applications (pour des raisons de disponibilité, de performance, de coût ou de meilleure adaptation à un type d’application particulier, etc.) sans modifier l’interface entre un fédéré et la RTI.

Les spécifications d’interface ne dépendent pas d’une implémentation particulière : la norme correspondante est décrite dans un méta-langage compréhensible par les développeurs quel que soit leur dialecte. Il existe bien évidemment des APIs22 dans les langages de programmation courants (tels Java, C++).

19 Coalition Battle Management Language. 20 Bien que l’on puisse parler de « RTI certifié », il est à distinguer de la certification HLA des fédérés. 21 PC/Windows, et dérivés d’Unix : PC/Linux , SGI/Irix, SUN/Solaris. 22 Application Programming Interface.


2.3 La norme HLA

Elle est constituée de 3 documents normatifs (références [A1] à [A3] et de deux guides méthodologiques (références [A4] et [A16]) qui soutiennent d’une part la conception, le développement et la mise en œuvre des fédérations HLA, d’autre part, proposent des pratiques recommandées en matière de VV&A.

Les 3 premiers documents qui constituent la norme proprement dite sont appelés :

• L’architecture et les règles HLA.

• Les « trames » de modèle objet HLA (OMT, pour “Object Model Template”23).

• Les « spécifications d’interface » (la description des interfaces entre les fédérés et la RTI).

La norme est décrite de façon plus détaillée en section 2.4 et en annexe 7.3. On n’en donne ici que les grandes caractéristiques.

1) Le premier document (l’architecture et les règles) est le plus court : il décrit en quelques pages les concepts exposés au paragraphe précédent (2.2) et résume sous la forme de 10 règles comment doivent fonctionner les fédérés (5 règles) et les fédérations (5 règles). La compréhension fine de ces règles, au-delà de leur interprétation immédiate, nécessite d’assimiler les documents décrivant l'OMT et les spécifications d’interface. Il faut en retenir les 2 grands principes essentiels déjà évoqués :

• toute la modélisation (la représentation des systèmes réels) a lieu dans les fédérés et pas dans la RTI qui a pour seule fonctionnalité de transporter l'information, de faire interagir et, si nécessaire, de synchroniser les fédérés,

• tout échange d’information, et la synchronisation entre les fédérés, ne peuvent se faire que via la RTI (pas de "back door").

2) Le deuxième document décrit l’OMT.

Il s’agit d’un ensemble de tables normalisées et d’un format de description des "objets" des fédérations et des interactions entre fédérés.

Au sens de la HLA, les concepts "objet" diffèrent des concepts habituels utilisés largement en informatique : il existe quelques différences significatives qui sont explicitées au paragraphe 2.5.1. La norme est très claire sur cet aspect (voir référence [A1] ou [A3]) et permet d’éviter, en principe, tout malentendu. La raison de ces différences provient du fait que le concept « objet » selon HLA ne concerne que l’aspect communication, et non l’aspect représentation du monde réel.

3) Le troisième document de la norme est constitué des "spécifications d’interface".

On y trouve la description des services fournis par les RTIs et de ceux que les différentes RTIs s’attendent à voir fournis par les fédérés. Ce document volumineux (mais tous les services ne sont pas utilisés dans toutes les fédérations) décrit chaque service particulier en précisant quelles sont :

• les pré-conditions d’utilisation,

• les variables d’entrée,

• les variables de sortie,

• les post-conditions après l’achèvement du service appelé ou fourni,

• les exceptions au fonctionnement nominal.

23 On notera au passage que la HLA est dite « orientée objet ». Ne pas confondre le sigle OMT de HLA avec la méthode OMT de génie logiciel (Object Modeling Technique).


L’enchaînement logique des traitements est explicité quand c’est nécessaire. Enfin, des APIs dans les langages usuels sont annexées à la norme. Avec la version IEEE 1516-2010, les APIs Java, C++ et WSDL24 font partie de la norme. Ce n’est pas le cas pour les APIs d’autres langages comme Ada 95, C# ou Python.

La compréhension de la norme nécessite une étude approfondie de ces 3 documents ainsi qu’un apprentissage de sa mise en œuvre25. Il est généralement reconnu que si les principes généraux de la norme sont relativement simples à assimiler, son utilisation requiert un haut niveau de technicité. C’est pour cette raison que la norme a été complétée par un guide méthodologique dont une nouvelle version a été publiée en 2010 (voir la référence [A16]).

Les quatre documents constituant la norme IEEE HLA sont disponibles via le site de l’IEEE (www.ieee.org). Ils sont payants, mais leurs coûts n’excèdent pas quelques centaines de dollars26.

2.4 Les composants de la norme HLA

De la norme US DoD 1.3 de HLA à la norme IEEE 1516-2010, un certain nombre d'évolutions et d'améliorations ont été apportées. Dans ce paragraphe, nous introduirons l’essentiel du contenu des documents normatifs IEEE 1516-2010. Pour plus de détails, le lecteur est invité à consulter l’annexe 7.3.

2.4.1 Les règles

Le premier document normatif « IEEE 1516-2010 HLA – Framework and Rules » fournit une description haut niveau de l’architecture, donne l’interprétation de tous les termes utilisés dans la norme, enfin, définit les règles de l’architecture [A1].

Les règles définissent les responsabilités des fédérés et des fédérations. Il existe 5 règles pour les fédérés et 5 règles pour les fédérations. Un exemple de règle pour les fédérés est "Tout fédéré doit être décrit par un SOM (Simulation Object Model) documenté selon l'OMT (Object Model Template) de HLA". La règle duale pour les fédérations est "Toute fédération doit être décrite par un FOM (Federation Object Model) documenté selon l'OMT (Object Model Template) de HLA". Nous verrons par la suite que ces 2 règles imposent de documenter à la fois les fédérés et les fédérations selon un formalisme normalisé par l'OMT.

2.4.2 Les spécifications de l'interface de programmation (API)

Le second document normatif « IEEE 1516.1-2010 HLA – Federate Interface Specification » décrit les spécifications de l’interface de programmation [A2]. Ces spécifications définissent les services permettant à un ensemble de fédérés de dialoguer par échange de données, au sein d'une même fédération. Ces services sont classés en 4 familles fondamentales (gestion de la fédération, des déclarations, des objets et du temps), auxquelles s'ajoutent 2 familles d'optimisation (gestion de la propriété et de la distribution des données) et une dernière famille de services auxiliaires.

Il est important de comprendre que la norme HLA ne fournit que les spécifications de ces services et en aucun cas des règles d'implémentation dans un langage de programmation donné.

Les implémentations des spécifications HLA sont assurées par la conception et le développement d'une RTI (Run-Time Infrastructure) qui constitue un ensemble de processus informatiques capable d'offrir les services définis par les spécifications à un ensemble de fédérés participant à une même fédération. L'architecture d'une RTI peut varier énormément d'une implémentation à l'autre.

24 Web Service Definition Language. 25 Il existe des formations payantes proposées par les différents vendeurs de RTIs et quelques organismes spécialisés. La DGA organise des journées de sensibilisation et on trouve dans quelques grandes conférences des tutoriels. 26 Les documents normatifs sont gratuits pour les membres de la SISO.

http://www.ieee.org/�


2.4.3 L'OMT (Object Model Template)

Le troisième document normatif « IEEE 1516.2-2010 HLA – Object Model Template (OMT) Specification » définit une structure commune normalisée et des formats communs pour documenter le modèle objet de HLA [A3]. Nous verrons que ce modèle objet est uniquement relatif à la communication entre les fédérés au sein d'une même fédération, et en aucun cas à la modélisation des entités physiques, interne à chaque fédéré. L'OMT permet pratiquement de renseigner le SOM d'un fédéré et le FOM d'une fédération.

Le SOM (Simulation Object Model) d'un fédéré décrit les échanges de données entre ce fédéré et le monde extérieur (le reste de la fédération). Il s'agit des données que le fédéré gère au profit d'une fédération et des données qu'il doit recevoir. En ce sens, le SOM constitue une méta-donnée fondamentale pour la réutilisation d'un fédéré comme composant d'une fédération donnée. En outre, le SOM d'un fédéré sera utilisé lors du processus de certification HLA d'un fédéré (voir paragraphe 4.5 à distinguer de la vérification d'une RTI évoquée au paragraphe 2.2.2).

Le FOM (Federation Object Model) d'une fédération permet d'établir une compréhension commune des données échangées entre les fédérés membres d'une fédération. Contrairement aux SOMs des fédérés, le FOM décrit les données échangées entre les fédérés au sein d'une même fédération. En ce sens, le FOM constitue une condition nécessaire mais non suffisante d'interopérabilité entre fédérés appartenant à une même fédération. Une nouveauté intéressante de la norme IEEE HLA 1516-2010 réside dans la notion de SOMs et FOMs modulaires qui seront abordées dans la suite de ce guide.

SOMs et FOM sont constitués de suites ordonnées de tables. Pratiquement, écrire un SOM ou un FOM consiste à renseigner les composants de l'OMT, les principales tables étant la table d'identification et les tables liées aux données échangées. Il existe des outils offrant une interface graphique permettant au concepteur de faciliter l'écriture des SOMs et des FOMs.

A titre d'illustration, la table suivante schématise la table des classes d'objets d'un SOM d'une simulation imaginaire, représentant le fonctionnement d'un restaurant27.

27 La classe racine HLAobject Root a été volontairement omise.


Client (PS)

Employé (S) Serveur (PS)

Caissier (PS)

Cuisinier (PS)

Addition (PS)

Commande (PS)

Vin (PS)

Café (PS)

Boisson (S)

Eau (PS)

Poisson (PS) Soupe (S)

Légume (PS)

Entrée (S)

Salade (PS)

Cochon (PS)

Onglet (PS)

Viande (S)

Boeuf (S)

Côte (PS)

Truite (PS)

Plat Principal (S)

Poisson (S)

Thon (PS)

Glace (PS)

Fruits (PS)

Nourriture (S)

Dessert (S)

Gâteau (S)

Viennoise (PS)

La lecture de cette table est très simple : chaque colonne exprime une spécialisation, c'est-à-dire un cas particulier de l'entité de la colonne précédente. Par exemple, un Plat Principal peut être soit une Viande, soit un Poisson. Une Viande peut être soit du Cochon, soit du Bœuf, et ainsi de suite. La signification des lettres P et S est abordée au paragraphe 2.5.

L’OMT ne décrit les données qu’au niveau des classes d’objets et des classes d’interactions (cf. paragraphe 2.5.1). En conséquence, même si le FOM d’une fédération est défini, il n’est pas possible de connaître a priori à la seule lecture du FOM la quantité des données qui vont être échangées.

2.4.4 L’Overlay VV&A

Le troisième document normatif « IEEE 1516.4-2007 HLA – Recommended Practices for Verification, Validation and Accreditation of a Federation – An overlay to the High Level Architecture Federation and Development Process» définit un ensemble de processus et procédures qui devraient être respectées pendant les phases de spécifications, conception et exploitation des résultats d’une fédération HLA respectant le FEDEP28 [A4]. Le FEDEP constitue un guide normatif décrivant des pratiques recommandées pour concevoir et exécuter des fédérations HLA (IEEE Std 1516.3-2003) [A7]. Formellement, il est référencé par l’intitulé “IEEE Std 1516.3-2000 TM: IEEE Recommended Practice for High Level Architecture Federation Development and Execution Process (FEDEP)”.

28 Federation Development and Execution Process.


Dans le cadre de la norme IEEE 1516-2010, il a été remplacé par le DSEEP29 sous la nomination d’IEEE P1730 [A16].

A l’heure de la mise à jour de ce guide, une révision du document normatif « IEEE 1516.4-2007 HLA – Recommended Practices for Verification, Validation and Accreditation of a Federation – An overlay to the High Level Architecture Federation and Development Process» est à l’étude afin de prendre en compte les spécificités du DSEEP.

2.4.5 Le DSEEP (Distributed Simulation Engineering and Execution Process)

Le DSEEP constitue, entre autres, un guide méthodologique de pratiques recommandées pour l’ingénierie et l’exécution des simulations distribuées (référence [A16]). Il décrit un processus d'ingénierie dédié à la simulation distribuée sous structuré en 7 étapes, couvrant le cycle de vie complet d'une simulation distribuée, depuis la définition des exigences et des objectifs à l'exploitation des résultats de simulation, en passant par la conception de la simulation. Il est indispensable de l'utiliser comme support de gestion d'un projet de simulation distribuée, pour les applications complexes. Bien qu’un recours rigoureux à cette méthodologie ne s'impose pas pour des applications de petite taille, l’utilisation de ses principes est fortement recommandée. Le DSEEP sera abordé plus en détails dans le chapitre 3, consacré aux méthodologies de conception.

Le DSEEP remplace et étend le FEDEP aux simulations distribuées autres que celles utilisant la HLA. Alors que le FEDEP ne faisait que compléter l'architecture HLA sous la norme US DoD 1.3, il avait été introduit dans la norme IEEE 1516-2000 sous la référence 1516.3, après des améliorations sensibles. Le fait que le FEDEP soit ou non partie intégrante de la norme fut longtemps discuté : en fait, puisqu'il s'agissait d'un guide (une pratique recommandée), il n'était pas normatif. Par contre le DSEEP qui accompagne la norme IEEE 1516-2010 fait partie intégrante de la norme sous le titre IEEE P1730-2010.

2.5 Les mécanismes de base de HLA

Dans ce paragraphe nous proposons d'introduire les mécanismes de base permettant à des fédérés participant à une fédération HLA de communiquer entre eux par échange de données. Rappelons que c'est la RTI, implémentation des spécifications de l'interface de programmation, qui est responsable de la gestion de cette communication, en offrant les services HLA aux fédérés.

Le modèle général de la communication HLA repose sur des mécanismes de publication/abonnement30 à des données et diffère ainsi radicalement du modèle client-serveur.

L'attention du lecteur est attirée sur le fait que la compréhension des mécanismes de base nécessite une connaissance minimale des concepts "orientés objet".

2.5.1 Le modèle objet de HLA et le support de communication

Le modèle objet de HLA ne concerne que la communication et les échanges de données entre fédérés, au sein d'une fédération.

Même s'il est souhaitable que la conception du ou des modèles abrités par les fédérés soit orientée objet, le choix de cette approche n'est en aucun cas imposé par HLA.

Il est important de comprendre que ce modèle objet ne se préoccupe pas des données internes aux fédérés, qui sont utilisées pour l'implémentation du modèle comportemental des entités simulées.

La communication dans HLA est fondée sur 2 concepts, les objets et les interactions. Un objet représente en général une entité du monde réel, par exemple un véhicule. Au contraire, une interaction

29 Distributed Simulation Engineering and Execution Process. 30 Publication/subscription en anglais.


signale un message ponctuel31 qui peut avoir un effet sur un ou plusieurs objets modélisés par des fédérés différents, par exemple une collision entre véhicules ou une explosion.

Conformément à toute conception orientée objet, les objets et les interactions sont structurées en classes. Par définition, une classe d'objets est décrite par un ensemble d'attributs et une classe d'interactions par un ensemble de paramètres. A titre d'illustration, la Figure 2 présente un exemple de classe d'objets et de classe d'interactions. Cet exemple servira de support pour expliquer les mécanismes de base de HLA.

Il est important de souligner que la syntaxe utilisée pour définir les classes de communication (objets ou interactions), est celle du FOM de la fédération, qui est utilisée par la RTI lors de l'exécution de la fédération. Ce point sera détaillé par la suite. Rappelons néanmoins que le modèle objet HLA ne concerne que la communication entre fédérés et ne préjuge donc ni de l'approche de modélisation utilisée en interne du fédéré, ni du langage de programmation utilisé.

Figure 2 Exemple de classes HLA

La classe d'objets HLA dénommée Vehicle est décrite par 3 attributs, X, Y et Z. La classe Aircraft est une classe dérivée de Vehicle qui hérite donc des attributs X, Y et Z. Elle spécialise la classe Vehicle par adjonction de l'attribut Type.

La classe d'interactions Collision est décrite par 3 paramètres DX, DY et DZ.

Souvent un objet représente une entité du monde réel, par exemple un véhicule. Dans la plupart des cas, la modélisation de cette entité est de la responsabilité d'un fédéré. Le mécanisme de publication évoqué précédemment, repose sur la capacité du fédéré à mettre à jour des attributs d'une classe32. Réciproquement, le mécanisme d'abonnement repose sur l'intérêt d'un fédéré à recevoir les mises à jour de ces attributs, via la RTI.

Le déclenchement d'une interaction est de la responsabilité d'un fédéré selon sa logique interne. C'est le fédéré qui reçoit une interaction qui a la responsabilité de modifier le ou les objets concernés par l'interaction. Les mécanismes de publication/abonnement à des interactions sont similaires à ceux évoqués pour les objets.

Une première différence fondamentale entre les 2 concepts de communication HLA est la suivante : lorsqu'un fédéré met à jour les attributs d'une instance de classe d'objets, il peut envoyer à la fédération un sous-ensemble des attributs de la classe et non nécessairement tous les attributs ; par contre, pour les interactions, tous les paramètres sont nécessairement envoyés à la fédération.

Une seconde différence entre classes d'objets et classes d'interactions est la suivante : pour toute classe d'objets, un fédéré doit créer des instances de la classe, de façon analogue à l’approche objet « classique », alors que la création d'instances de classe d'interactions n’est pas autorisée, puisqu’il

31 Messages qui peuvent être horodatés. 32 Messages qui peuvent être horodatés.

(class Vehicle (attribute X) (attribute Y) (attribute Z) (class Aircraft (attribute Type) ) ) // Classe d'objet

(class Collision (parameter DX) (parameter DY) (parameter DZ) ) // Classe d'interaction


s’agit d’informations fugaces. Bien entendu, les créations d'instances de classe d'objets sont assurées par des services des spécifications d'interface, qui devront être invoqués par le fédéré. Il est de même pour la destruction des instances de classes d’objets.

Ces 2 différences entre les classes d'objets et les classes d'interactions, sont justifiées par les cas d'utilisation de l'un ou de l'autre des concepts de communication. Sur ce point, les spécifications HLA ne fournissent que la recommandation suivante :

Les objets sont utilisés pour échanger des informations persistantes, alors que les interactions sont utilisées pour échanger des informations fugaces.

Le modèle objet de HLA diffère des approches objet conventionnelles sur les 2 points essentiels suivants :

• Les classes d’objet et d’interaction ne sont pas décrites par leur comportement, c'est-à-dire qu'il n'existe pas de méthodes associées à ces classes. Ce point est conforme avec l'esprit HLA qui impose que le comportement des entités simulées par un fédéré doit être masqué au sein du fédéré et ne doit en aucun cas apparaître au niveau de la communication.

• Il n'existe pas d'héritage multiple sur les classes33.

La norme HLA fournit plus de détails sur les différences entre l’approche orientée objet classique et celle offerte par HLA (voir la référence [A1]).

2.5.2 Les services fondamentaux offerts par HLA

Ces services offerts par la RTI correspondent à l'implémentation des spécifications de l'interface de programmation. Dans ce paragraphe, il ne s'agit pas de fournir une description exhaustive de tous les services HLA, mais d'insister sur les mécanismes fondamentaux de la gestion d'une fédération et de la gestion des communications. Un paragraphe particulier (paragraphe 2.5.4) est consacré aux services de gestion du temps, services qui constituent un atout majeur de HLA par rapport à d'autres architectures comme CORBA.

Nous décrirons brièvement les principaux services de HLA en nous appuyant sur 3 fondamentaux de l'architecture.

a) Gestion de la fédération : le premier principe remarquable de HLA est que la gestion de la fédération est à la charge des fédérés eux-mêmes. Cela signifie que la HLA n’impose aucune règle pour la création d’une fédération, l’intégration ou le retrait de fédérés participant à une fédération. Par contre, l’architecture offre tous les services permettant de répondre à ces besoins.

Par exemple, certains fédérés ont la capacité de créer des fédérations nommées. Par contre tous doivent être capables de rejoindre une fédération quand ils le souhaitent, même longtemps après le début de la création de la fédération. Tout fédéré peut également quitter une fédération quand il le souhaite. La destruction d'une fédération est également à la charge des fédérés, en sachant qu'une demande de destruction n'est effective que lorsque celle-ci est invoquée par le dernier fédéré participant à la fédération. La plupart des implémentations des services gèrent un mécanisme d'exception pour faire face aux cas d'erreur ou d'inconsistance dans les invocations de service. L'ensemble de ces services est regroupé dans la famille des services de gestion de la fédération. Une nouveauté dans la norme IEEE 1516-2010 est la nécessité pour chaque fédéré d’établir une connexion avec la RTI (Service Connect) avant de créer une fédération et/ou de la rejoindre. Lorsque le fédéré a quitté une fédération et n’a plus l’intention d’en créer ni d’en rejoindre une autre, il doit se déconnecter de la RTI (Service Disconnect).

b) Gestion des déclarations et des objets : le second principe concerne le modèle de communication. Contrairement à un modèle Client – Serveur, la HLA propose un modèle de publication et d'abonnement. Ainsi, tout fédéré qui souhaite recevoir les nouvelles valeurs d'une classe d'objets ou

33 Même si ce mécanisme n'est pas présent dans toutes les approches objet.


d'interactions, doit demander un abonnement (ou souscription). Le principe d'abonnement diffère selon qu'il s'agit d'une classe d'objets ou d'une classe d'interactions.

• Pour une classe d'objets, un fédéré peut s'abonner à un sous-ensemble de ses attributs. Par exemple, pour la classe d'objets Vehicle représentée sur la Figure 2, le fédéré peut s'abonner uniquement aux attributs X et Y, si les nouvelles valeurs de Z ne l'intéressent pas pour poursuivre la simulation.

• Par contre, un abonnement à une classe d'interactions, implique nécessairement l'abonnement à tous ses paramètres. Réciproquement, un fédéré qui souhaite communiquer à la fédération des informations, doit préalablement déclarer son intention de publier soit un ensemble d'attributs d'une classe d'objets donnée, soit une classe d'interactions.

Ces demandes de publication et d'abonnement ne constituent que des intentions déclarées à la RTI, intentions qui ne sont pas nécessairement figées au cours de la simulation. Ainsi, tout fédéré peut modifier ses intentions de publication et d'abonnement aussi souvent qu'il le souhaite au cours de la simulation.

Lorsqu'un fédéré déclare son intention de publier un sous-ensemble d'attributs d'une classe d'objets, il doit ensuite créer une ou plusieurs instances de cette classe. Ainsi, si un fédéré A gère et publie les attributs X, Y et Z de la classe Vehicle, il doit créer des instances de cette classe grâce à l'invocation d'un service HLA. Cette création (on parle d'enregistrement dans le vocabulaire HLA) permet au fédéré de simuler un nombre quelconque d'entités de la même classe. Réciproquement, si un fédéré B s'abonne à des attributs de la classe Vehicle, il sera prévenu par la RTI de toute création d'une instance de cette classe effectuée par le fédéré A.

Après la déclaration des intentions de publication et l’enregistrement des objets, le fédéré A peut mettre à jour les attributs X, Y et Z de toute instance de la classe Vehicle, selon les besoins de sa propre simulation. Le rôle de la RTI est alors de transmettre ces nouvelles valeurs à tous les fédérés qui sont abonnés aux attributs X, Y et/ou Z.

L'exploitation de ces nouvelles valeurs d'attribut pour une instance de classe est bien évidemment à la charge du fédéré abonné, puisque la RTI ne dispose d'aucune connaissance sur la modélisation elle-même. Le rôle de la RTI est donc simplement de répercuter toute nouvelle valeur d'un attribut d'un objet à tous les fédérés qui sont abonnés à cet attribut. Les publications et abonnements à des classes d'interactions sont gérés de manière similaire par la RTI, à la différence près que l'ensemble des paramètres d'une interaction sont concernés, et qu'il n'existe pas de notion d'enregistrement d'une instance d'interaction.

L'ensemble de ces services est regroupé dans les familles de services de gestion des déclarations et des objets.

c) La sémantique des données échangées : par définition, la RTI n'a aucune connaissance de la sémantique des données communiquées. Ainsi, vue de la RTI, toute donnée échangée est une suite d'octets sans aucune signification.

2.5.3 Schéma classique du déroulement de l'exécution d'une fédération

Dans ce paragraphe, nous proposons d'illustrer l'utilisation des principaux services HLA sur un exemple d'exécution d'une fédération, à laquelle participent 2 fédérés. Nous supposerons pour simplifier l'explication que le fédéré A publie tous les attributs de la classe Vehicle et que le fédéré B s'y abonne. Sous ces hypothèses, le déroulement type de l'exécution d'une fédération est représenté sur la Figure 3.

Sur cette figure, les flèches pleines en gris représentent des services HLA initiés par la RTI alors que les flèches normales figurent des appels de service HLA invoqués par les fédérés.

Il est clair que les opérations de diffusion des nouvelles valeurs de X, Y et Z de la part du fédéré A ainsi que les répercussions de ces valeurs vers le fédéré B, constituent généralement un processus


répétitif de la boucle de simulation. De même, les créations d'instances de classe d'objets ne sont pas nécessairement effectuées au même moment.


Figure 3 Déroulement type de l'exécution d'une fédération

2.5.4 Principes de base de la gestion du temps

Les mécanismes de gestion du temps offerts par HLA constituent sans aucun doute un des atouts majeurs de cette architecture de simulation. Sur cet aspect, le premier fondement de HLA est qu'il n'existe aucune référence à une date partagée par la fédération. Par contre, chaque fédéré doit avoir sa propre référence temporelle34.

34 Appelée "temps logique du fédéré". Toute correspondance entre ce temps logique et tout autre référentiel temporel, est à la charge du fédéré.

Fédéré A Fédéré B RTI

Créer la fédération (Succès)

Rejoindre la fédération

Déclaration de publication des attributs

X, Y et Z de la classe "Vehicle"

Créer les instances de la classe "Vehicle"

Mise à jour et diffusion des nouvelles valeurs de

X, Y et Z

Quitter la fédération

Détruire la fédération (Echec)

Créer la fédération (Échec, fédération existe)

Rejoindre la fédération

Déclaration d'abonnement aux

attributs X, Y et Z de la classe "Vehicle"

Découverte des instances de la classe "Vehicle"

Répercussion des nouvelles valeurs de X,

Y et Z

Quitter la fédération

Détruire la fédération (Succès)

Connexion à la RTI

Déconnexion de la RTI

Déconnexion de la RTI

Connexion à la RTI


Lorsque les services de gestion du temps sont utilisés par une fédération, l'avance dans le temps de chaque fédéré est demandée par le fédéré lui-même et autorisée (immédiatement ou après un délai) par la RTI.

Les services de gestion du temps permettent à tout fédéré de contrôler son avance dans le temps logique, vis-à-vis des horloges logiques des autres fédérés participant à la fédération. Les mécanismes de gestion du temps assurent notamment une avance dans le temps qui respecte les principes de causalité35 des messages36, lorsque le concepteur de la simulation le souhaite. Dans ce cas, la RTI garantit qu'un fédéré ne peut pas recevoir des messages (mises à jour d'attribut ou envois d'interaction) à traiter dans son passé.

Une règle de l'architecture HLA impose à chaque fédéré d’assurer sa propre gestion du temps en interne.

L'architecture HLA supporte 3 mécanismes d'avance dans le temps des fédérés participant à une fédération :

• En temps coordonné, lorsque l'avance dans le temps de chaque fédéré est coordonnée avec celle des autres fédérés.

• Sur message, lorsque l'avance dans le temps d'un fédéré est rythmée par la réception d'un message (répercussion de valeurs d'attribut ou de paramètres). Dans ce cas, l'avance dans le temps du fédéré est donnée par l'estampille temporelle du message reçu.

• Enfin, de manière optimiste, lorsque chaque fédéré avance dans le temps à sa vitesse propre indépendamment de celle des autres fédérés. C’est souvent le cas des fédérations où tous les fédérés sont « temps réel ». Dans le cas d’une simulation « non temps réel », la réception de messages dans le passé du fédéré, doit provoquer des mécanismes de "rollback"37 afin de revenir à un état de la simulation cohérent avec la date de traitement du message.

Pour mettre en œuvre la garantie du principe de causalité, tout fédéré peut se déclarer vis-à-vis de l'avance dans le temps, comme régulateur, contraint, régulateur et contraint ou ni l'un ni l'autre, avec les définitions suivantes :

• un fédéré régulateur conditionne l'avance dans le temps de tous les fédérés contraints participant à la fédération, selon un mécanisme géré par la RTI (voir annexe 7.3, paragraphe 7.3.7),

• réciproquement, l'avance dans le temps d'un fédéré contraint est conditionnée par celle de tous les fédérés régulateurs participant à la fédération, toujours selon un mécanisme géré par la RTI,

• si un fédéré n'est ni régulateur, ni contraint, alors il s'agit en général d'un fédéré "temps réel" qui avance dans le temps indépendamment des autres fédérés. Lorsque la fédération est "temps réel"38, il peut être utile de mettre en place un mécanisme de synchronisation des horloges pour établir une référence commune fiable,

• enfin, toute avance dans le temps est d'abord demandée par le fédéré lui-même, puis accordée par la RTI lorsqu'un certain nombre de conditions sont remplies. Ces conditions dépendent de la politique de gestion du temps (voir annexe 7.3, paragraphe 7.3.7).

Le rôle d'un fédéré vis-à-vis de l'avance dans le temps (régulateur ou contraint) est déclaré de sa propre initiative, par invocation de services des spécifications d'interface. Conformément à l'esprit HLA, tout fédéré peut changer son rôle vis-à-vis de la gestion du temps aussi souvent qu'il le souhaite au cours de l'exécution d'une fédération.

35 L'effet ne doit pas précéder la cause. 36 Le terme « message » remplace le terme « événement » depuis la norme HLA IEEE 1516-2000. 37 Terme désignant un retour de l’état de la simulation à une date antérieure. 38 Tous les fédérés sont ni contraints ni régulateurs.


2.6 Les normes HLA

Actuellement coexistent 3 versions de la norme : 1.3 de l’US DoD (obsolète et de moins en moins utilisée), une norme IEEE 1516-2000. HLA 1516 est désormais la seule norme recommandée pour tout nouveau développement de simulation distribuée au sein de l’OTAN (voir paragraphe suivant), et aussi en national, par exemple, aux Etats-Unis (position adoptée en octobre 2004), en France et en Suède. La norme en vigueur à ce jour est la norme IEEE 1516-2010 publiée en 2010. La norme US DoD est citée dans ce document, car elle est encore utilisée dans des systèmes existants. Les premières applications de la norme IEEE 1516-2000 datent de 2003 et ont été développées d’abord en Suède.

L’OTAN a, pour sa part, établi un STANAG39 (4603) promulgué en juillet 2008 et ratifié par 12 pays : cette norme militaire mentionne les 2 versions de HLA tout en recommandant en priorité l’utilisation de la version IEEE 1516-2000 sauf dans de rares exceptions liées à des exigences économiques ou de délais. Ce STANAG fait de la HLA une norme incontournable pour la France dans un contexte international.

On peut également signaler que la version HLA US DoD 1.3 avait été adoptée en 1999 par le groupement industriel OMG (Object Management Group, en charge en particulier de CORBA).

2.6.1 La norme US DoD 1.3 (obsolète, mais encore présente)

Elle a été développée sous financement de l’US DoD. L’organisation responsable était le DMSO (Defense Modeling & Simulation Office40) qui disposait d’un « directeur de programme HLA ». Le DMSO avait mis en place un organisme chargé de superviser le développement et le suivi de HLA appelé AMG (Architecture Management Group, une quinzaine de personnes) et présidé par le directeur de programme HLA.

2.6.2 La version 2000 de IEEE 1516 de HLA (encore bien présente)

A la différence des premières versions de l’US DoD, elle n’a pas été développée directement par le DMSO. Elle a été développée par une organisation internationale civile et à but non lucratif appelée SISO (Simulation Interoperability Standards Organisation) qui, bien que développant généralement ses propres standards, a développé la norme HLA au profit de l’IEEE. Cette version de la norme a été élaborée avec une participation importante des alliés et a tiré les leçons des 4 premières années d’utilisation de la norme US DoD 1.3. Cette version IEEE évite toute référence aux applications militaires pour favoriser l’ouverture vers d’autres communautés d’utilisateurs.

2.6.3 La version 2010 de IEEE 1516 de HLA (version actuelle)

La règle à l’IEEE est de réaffirmer une norme ou de la réviser tous les 5 ans. La SISO avait décidé de mettre en révision les 3 documents de base de la norme au printemps 2004 pour une nouvelle version à paraître en 2010. Le principal objectif de cette révision était de clarifier certains points des spécifications tout en levant certaines ambiguïtés. L’avis des experts est que l’écart entre la norme 1516-2010 et la norme 1516-2000 est moins important que celui observé entre la norme US DoD 1.3 et la norme 1516-2000, la plupart des défauts de 1.3 ayant été corrigés avec la version IEEE (voir les références [A1] à [A3]).

En parallèle à ces efforts, la SISO développe des extensions à HLA (voir le paragraphe 6.2sur les BOMs ou Base Object Models) et sur les APIs des RTIs afin d’améliorer encore l’interopérabilité au sens de HLA. De nouveaux concepts plus ou moins différents de HLA sont également à l’étude : il est peu probable qu’ils débouchent sur des normes complètes utilisables à court terme (voir le chapitre 6) même si les concepts et les technologies envisagés sont intéressants dans l'absolu.

39 STANdard AGreement. 40 Remplacé depuis octobre 2006 par le M&S Coordination Office (M&S CO).


2.7 Les malentendus sur HLA

La HLA a fait l’objet d’une énorme promotion de la part du DoD dans les années 1990. Elle a donc suscitée beaucoup d’intérêt en Europe ou en Asie, comme d’autres innovations venant d’outre-atlantique. L’apparition de la HLA est arrivée alors que la communauté mondiale de simulation venait d’enregistrer un certains nombres d’échecs (ou de demi-succès), dans une décennie qui a vu les "merveilles" d’Internet se répandre et proliférer. Il y avait une véritable attente d’un saut technologique par la communauté M&S. Apparemment aucune des nouveautés du domaine de la simulation (tel DIS apparu vers 1993) ne semblait vraiment satisfaire cette attente. Un discours fortement enthousiaste, associé aux différences culturelles entre les US et les autres nations et à l’attente des experts M&S a fait que la HLA a été l’objet d’un certain nombre de malentendus qu’il convient de clarifier.

2.7.1 Le "miracle" HLA

Même lorsque HLA a été comprise comme une norme d’interconnexion de simulations, ses possibilités ont été surestimées : HLA ne résout pas tous les problèmes d’interopérabilité. HLA se focalise sur les problèmes de connexion "technique" : l’architecture ne traite pas des problèmes sémantiques. Il ne suffit pas d’être capable de faire communiquer 2 simulations pour leur permettre de fonctionner ensemble avec une compréhension commune de la sémantique des informations échangées.

En 2002, dans un discours connu, le président de la SISO a dit que les normes actuelles ne permettaient de résoudre que 10 à 15% des problèmes d’interopérabilité. Ce pourcentage peut sembler pessimiste mais doit être médité. La HLA seule ne peut pas tout faire. Son efficacité doit être complétée par des normes d’échanges de données (par exemple : SEDRIS pour l’environnement naturel ou urbain), des formats d’échanges de messages, etc. Les travaux actuels sur la VV&A des fédérations doivent aussi permettre de progresser dans la recherche du Graal de l’interopérabilité. On a trop dit et trop écrit que HLA (et DIS !) étaient des normes « Plug and Play ». On est loin de cela et il est douteux que de telles normes émergent dans un futur proche!

Une autre limite de HLA est sa complexité. Compte tenu de son ambition première d’interopérabilité entre divers types de simulations, HLA ne saurait être simple : on veut, par exemple, associer différentes gestions du temps (temps réel/temps logique), faire de la distribution de données intelligente, etc. Tout cela a un prix fort à payer en termes de complexité et éloigne la norme du "plug and play". De fait, la HLA hérite des problèmes inhérents à une solution distribuée en termes de complexité et de gestion. Il n’y a pas de miracle.

2.7.2 HLA comme aide à la conception et le développement des simulations

Dès son apparition, la HLA a été considérée comme un environnement universel de conception et de développement de simulations dans certaines communautés. C’est sans doute le résultat de différences culturelles : alors que le DoD dans sa politique de simulation annonçait que "toute nouvelle simulation devait être développée en conformité avec HLA", d’autres communautés comprenaient "toute nouvelle simulation doit être développée sous HLA". La première phrase signifie que toute simulation doit être capable de communiquer avec d'autres simulations sous HLA, alors que la seconde laisse entendre que HLA constitue une architecture de conception et de développement de simulation. Il est vrai que l’on trouve dans les spécifications de la norme des termes tels que "gestion des objets, gestion du temps, distribution des données, etc." termes qui peuvent faire penser aux services fournis par des outils de développement de simulation, mais il ne s’agit dans HLA que de fonctionnalités pour la communication entre simulations et pas d’outils pour implémenter des modèles, ni les faire fonctionner ensemble !

Cette partie du malentendu est en grande partie levée : il existe maintenant des environnements de développement commerciaux ou gouvernementaux (environnements de développement et d'exploitation de simulation, EDES) qui offrent des fonctionnalités HLA (exemples : DirectSim, développement conjoint de la DGA et de la Marine, STAGE de Presagis ou SIMplicity de Calytrix).


D’autres produits émergent fondés nativement sur HLA (tels que GENESIS41 de l’ONERA) qui permettent de développer directement des fédérés HLA. La HLA n’offre pas de facilités nouvelles pour la conception et le développement des simulations. C’est plutôt l’inverse : HLA crée des contraintes supplémentaires aux concepteurs et aux développeurs tout en leur apportant des fonctionnalités intéressantes en termes d’interopérabilité. Ces contraintes sont relativement bien résolues par l’utilisation des EDES offrant des fonctionnalités HLA : leur usage est fortement recommandé (voir le paragraphe 3.2 sur le développement de simulations conformes à HLA).

D’autres contraintes de développement de la fédération ont pour origine l’approche choisie pour passer de la modélisation à l’implémentation via le FOM. En effet, certains environnements de développement favorisent l’approche de génération de code d’après un FOM ou un SOM, alors que d’autres favorisent la description technique via un code informatique qui sera à l’origine d’un FOM généré.

2.7.3 Les performances des simulations distribuées sous HLA

Dans les années 1990 et 2000, la HLA a souvent été rejetée par certains sous le prétexte de son « manque de performances, en particulier pour le temps réel ». Ce défaut est quelquefois stigmatisé aujourd’hui (souvent à tord), alors que des expérimentations ont montré, dès 1998, que la HLA est utilisable pour des applications temps réel, même sur des réseaux longue distance : projet européen EDISON (EADS en France) ou expérimentation OTAN « First Wave » (deux exemples de mise en œuvre sur des réseaux distants). Si l’on doit parler de réduction de performance, ce n’est pas spécifiquement lié à l’utilisation de telle ou telle norme : c’est inhérent à la simulation distribuée et à la présence d'un réseau d'interconnexion. Le manque de performances peut être le résultat de la distribution, pas nécessairement celui du choix de telle ou telle norme d’interopérabilité. A titre d’exemple, les mesures de performances montrent que les latences des dernières versions de RTIs sont inférieures à la milliseconde, alors que celles introduites par le réseau longue distance peuvent atteindre des dizaines voir des centaines de millisecondes.

En fait, il est clair que si l’on veut de la performance (traduire vitesse d’exécution) et si on a le choix42, il faut développer des simulations monolithiques que des simulations distribuées. Si l’on doit travailler en distribué, il vaut mieux travailler sur un réseau local que sur un réseau distant (quand on le peut évidemment). La guerre entre DIS et HLA (sur ce point particulier) a tourné court avec la mise au point de fédérations temps réel sur réseaux distants (WANs). La perte de performance des applications distribuées n’est pas spécifique du domaine de la simulation mais plutôt des aspects réseaux. C’est la raison pour laquelle les développeurs de fédérations HLA font toujours appel à des spécialistes des réseaux.

De manière générale, l’architecture réseau, et le choix de la RTI, dont l’implémentation joue alors paradoxalement un rôle important, sont des éléments essentiels dans la recherche de performances. Les outils d’analyse réseau au niveau trame et à plus haut niveau sont alors essentiels. Il en est de même pour le paramétrage de la RTI (fichier .RID43 pour la RTI NG44 et d'autres versions commerciales de RTIs). Il faut enfin noter que le choix et le paramétrage du système d’exploitation lui-même, jouent également un rôle crucial.

2.7.4 La HLA, norme du Département de la Défense US ou norme "civile"?

Il est vrai que l’origine de la HLA est le DoD. Mais la dernière version militaire de la norme date de février 1998 (version 1.3 US DoD)! Depuis, la HLA est devenue une norme IEEE (d’abord en 2000, puis en 2010). Une autre norme, la HLA IEEE 1516-2010 a été publiée en 2010 ce qui montre bien la vitalité de la norme. Cette volonté de sortir du strict domaine militaire vient du DoD lui-même à qui il semblait important d’obtenir un large consensus pour l’utilisation, le développement et l’évolution de cette norme. Le texte de la norme IEEE 1516-2000 puis IEEE 1516-2010 a été rédigé en prenant garde

41 Article publié à la conférence EuroSIW : 05E-SIW-013, Toulouse, France, Juin 2005. 42 Cas du domaine de la simulation pour l’analyse, par exemple. 43 Le fichier RID (RTI Initialisation Data) permet d’ajuster un certain nombre de paramètres de la RTI. 44 Une des premières RTI développées par le DMSO à la norme US DoD 1.3.


d’éviter les références typiques du domaine militaire (ce qui n’était pas le cas de la norme US DoD 1.3 évidemment).

Il est difficile de faire un bilan de l’utilisation de la HLA hors défense, mais il est clair que cet usage existe. Parmi les domaines d’application connus, on peut citer les transports (aériens, en particulier), l’espace (la NASA l'utilise), la médecine (voir les publications SISO), l’off-shore, etc. Le pays Européen le plus avancé dans cette utilisation civile de la norme est la Suède et des sites Internet privés suédois font la promotion de cette activité. Enfin, la norme HLA est enseignée dans beaucoup d’universités dans le monde : on signale depuis quelques années une forte activité en Chine.

2.7.5 Le coût de la HLA

Beaucoup de questions sont posées sur le coût lié à l’utilisation de la HLA : elles n’ont pas de réponse unique et on ne peut y répondre que dans un contexte d’utilisation donné. Les questions typiques sont les suivantes.

Question 1 : Si je veux rendre conforme à HLA ma simulation (resp. mon simulateur) combien cela va-t-il me coûter ?

Réponse : Cela dépend de la qualité de sa conception et de son développement ! Si elle/il a été conçu(e) et développé(e) dans le respect des grands principes du génie logiciel tels qu’ils sont généralement connus et admis aujourd’hui : séparation de services et des modèles, « orientation objet », séparation des services entre eux (gestion des objets, gestion du temps, encapsulation, etc.), il est probable que l’intégration de nouvelles fonctionnalités se fera facilement et sans effet de bord, donc à moindre frais. Si l’on a, de plus, utilisé un environnement de développement et d'exploitation de simulation (EDES) offrant des fonctionnalités HLA, la mise en conformité d’une application se fera en quelques jours de travail voire quelques heures. Pour donner un exemple de l’utilité de tels environnements, en France, la mise en conformité l'EDES ESCADRE de la DGA à la norme HLA a duré 2 ans pour un coût de 600 k€ environ. Depuis, ESCADRE dans sa version HLA a permis de développer de nombreuses simulations conformes à HLA avec un investissement minimal, sans surcoût lié à la plate-forme elle-même. En règle générale, en fonction du niveau des besoins HLA, la mise à niveau d’une application peut s’étaler de quelques jours à quelques mois. Il est impossible de donner un coût sans expertise approfondie de l’application et des besoins en termes d’interopérabilité.

La mise en conformité d’applications anciennes, quand elles ne remplissent pas la plupart des critères de conception et de développement exposés au paragraphe précédent, peut se révéler coûteuse. Même quand le financement est disponible, il y a un risque que les capacités HLA obtenues soient faibles et ne puissent pas garantir l’interopérabilité du produit dans des fédérations HLA ambitieuses. Typiquement, l’utilisation de services HLA comme la gestion du temps coordonné ne sera peut-être pas disponible. Il est donc important de faire une étude de faisabilité, de risque et de coût avant de se lancer dans une telle évolution. Il peut coûter moins cher de réécrire certaines applications sous des EDES évolués supportant HLA.

Question 2 : Tel industriel prétend que l’utilisation de HLA dans mon projet va être coûteuse alors qu’il dispose gratuitement de son produit sur étagère ?

Cette affirmation des industriels est très courante et s’applique aussi à d’autres normes que HLA. La réponse à cette question dépasse le cadre de HLA. Le prix à payer pour cette gratuité est la dépendance d’un industriel particulier, l’asservissement à sa politique interne concernant la simulation, à sa capacité de suivi des évolutions des normes (s'il en suit45). Les surcoûts potentiels seront liés au manque d’interopérabilité avec d’autres applications venant d’autres industriels et avec celles issues de nos alliés. Toutes ces conséquences peuvent ne pas apparaître à court terme et sont difficiles à évaluer en termes financiers.

Il est clair cependant que l’utilisation de HLA peut nécessiter l’acquisition de logiciels spécialisés (voir le chapitre 4, sur les outils HLA). A titre d’information une licence pour une RTI peut valoir de

45 Dans ce cas, il doit en fournir la preuve, car suivre la norme 1516 ne veut pas dire être certifié conforme à la norme IEEE 1516.


1000 € HT à 2000 € HT suivant les vendeurs et le nombre de licences achetées (il en faut au moins une par fédéré, plus quelques autres pour certains outils de gestion et de visualisation, par exemple). Un kit de développement vaut environ 5000 € HT.

Question 3 : Comment apprécier l’intérêt de se lancer sur du « tout HLA » ?

Il ne faut pas examiner le coût et l’efficacité d’utilisation de la norme HLA sur le court terme ni sur un projet particulier. Les 2 objectifs de la HLA sont l’interopérabilité mais aussi la réutilisation des simulations. La satisfaction du deuxième objectif ne peut être appréciée qu’à long terme avec la mise en place de banques de données de ressources en simulation et de la mise à disposition de ces ressources auprès des utilisateurs potentiels. Un préalable concerne la clarté des droits de propriété des applications disponibles. Il ne semble pas actuellement que toutes ces conditions sont clairement réunies.

Conclusion sur les aspects Coût : Le coût de la HLA comme le retour sur investissement ne sont pas clairement identifiés à ce jour. Il convient de se lancer dans la conception de fédérations HLA que lorsque de réels besoins d’interopérabilité et/ou de réutilisation existent, et qu’une étude de la valeur a montré qu’aucun autre moyen plus économique ne permet de répondre aux besoins attendus. Lorsque la décision de développer un fédéré HLA est prise, il faut le faire sous un EDES qui fournit des fonctionnalités HLA natives (voir le paragraphe 3.2). Si l’on veut mettre à niveau une simulation préexistante il vaut mieux évaluer les risques et les coûts d’une telle opération avant de se lancer dans ce projet ou bien décider de la réécrire dans un environnement mieux adapté.

2.7.6 Les limites de la HLA liées aux infrastructures d’exécution (RTIs)

Jusqu’en 2002, les fédérations HLA ont utilisé une RTI gratuite, mise à la disposition de la communauté internationale par l’US DoD. A partir de 2003, les nouveaux projets ont donc dû se tourner vers des versions commerciales de la RTI ou dans quelques cas sur des produits libres tels le CERTI de l'ONERA. La politique commerciale des vendeurs présents sur ce marché, impose l’acquisition d’une licence par fédéré. En général, une fédération donnée utilise une RTI commerciale distribuée par un vendeur donné et unique. Malheureusement, les choix d’architecture et de protocole de communication ne sont pas identiques d'un vendeur à l'autre et parfois même, conduisent à une incompatibilité entre les RTIs46. Ainsi, la capacité de réutilisation des fédérés promue par HLA, est fortement limitée. A ceci s’ajoute également un surcoût lié à l’acquisition d’une nouvelle licence, et à l’adaptation du fédéré, en cas de sa réutilisation dans une nouvelle fédération utilisant une RTI différente.

2.8 L’intérêt de la norme HLA

Le paragraphe précédent peut sembler pessimiste. Les bénéfices de l’approche HLA sont pourtant bien réels. Ils sont largement reconnus par la communauté internationale de la simulation. Il convient de les lister et les commenter.

2.8.1 De l'intérêt d'utiliser des normes et HLA, en particulier

Le paragraphe précédent a évoqué les défauts des approches propriétaires. S’il est vrai que de nombreuses solutions techniques coexistent pour interconnecter des simulations au sein des entreprises ou des organisations gouvernementales, peu d’entre elles ont une large audience ni font l’objet d’un consensus auprès des experts et des politiques. Généralement, les enjeux commerciaux, les querelles partisanes et politiques masquent les bénéfices techniques de telle ou telle approche particulière. Un bon exemple de querelle stérile tiré du domaine du logiciel est celle des langages de programmation, dits « de haut niveau », qui ont évolué au grès des modes et des intérêts commerciaux des sociétés informatiques.

La mise au point de normes d’interopérabilité par des organisations indépendantes (comme la SISO) ou, au moins, rassemblant beaucoup d’intérêts divers (comme l’OMG ou le consortium SEDRIS) est

46 Il est toutefois possible que cette incompatibilité entre RTIs commerciales disparaisse ou soit plus rare, à court terme, suite aux efforts des vendeurs pressés par leurs principaux clients !


une bonne façon de capitaliser des savoirs et des technologies différents, d’obtenir des consensus sur des paradigmes d' « architectures de haut niveau » tels que HLA, CORBA ou MDA (Model Driven Architecture). Cette approche permet de laisser aux vendeurs le soin de fournir des outils permettant l’implantation des normes et donc la capacité d'exploiter commercialement ces normes sans imposer leur propre politique ou philosophie. Elle permet à ces mêmes sociétés commerciales de participer à l’évolution des normes préservant ainsi leur intérêt particulier sans mettre en danger l’intérêt général. On peut remarquer que beaucoup de « petites » sociétés vivent de leur adhérence à la norme HLA à l’ombre des grandes organisations qui ont souvent la tentation d’imposer leur propre technologie.

HLA est un très bon exemple de développement de norme : développée au départ par une organisation forte (le Département de la Défense des US) la HLA a bénéficié d’un financement suffisant. Par la suite, la maturité venant, à l’initiative même du DoD, la HLA a été ouverte à une plus large communauté (via la SISO travaillant en soutien de l’IEEE). Au cours des années, la HLA a ainsi acquis une large audience et a bénéficié des derniers développements de l’état de l’art : l’utilisation de XML dans la norme IEEE 1516 en est un exemple.

La HLA est donc issue d’une politique volontariste au départ pour parvenir à une approche plus classique et plus ouverte par la normalisation IEEE. De ces origines US DoD, HLA a hérité d’une capacité de certification de conformité qui bien que généralement préconisée pour toutes les normes par l’IEEE n’existe pas pour les autres normes (voir le chapitre 0).

L’intérêt de la HLA en tant que norme est multiple :

• Elle est maintenant une norme civile (IEEE) et est donc beaucoup plus largement acceptée hors défense ; il est ainsi permis à tous de participer à son évolution via la SISO,

• Elle évolue continûment pour intégrer l’évolution de l’état de l’art (tous les 5 ans environ) : c’est une garantie de pérennité et d’évolutivité,

• Elle est « haut niveau » : elle ne préconise ni langage de programmation particulier, ni plate-forme informatique particulière47,

• Elle est ainsi multi plates-formes et laisse donc aux développeurs de simulations (de fédérés HLA), le choix de l’environnement de développement qu’ils préfèrent ou qui leur est accessible,

• Le principe de la HLA de garder dans les fédérés la modélisation des systèmes réels est une garantie pour la protection des informations « métier » pour les industriels qui ont une spécialité marquée (protection des acquis technologiques) : cet aspect protection de l’information est renforcé par les mécanismes de publication et d’abonnement aux informations échangées qui permettent, dans leur principe, de contrôler la nature des échanges et de les tracer. Cet avantage de la HLA permet de la préconiser dans des développements multi industriels là où des normes comme DIS diffuseraient l’information largement et sans contrôle. Il renforce ainsi le besoin de ne pas dépendre d’un industriel unique pour certaines applications ouvertes.

2.8.2 Les avantages techniques de la HLA

Quelques uns des bénéfices soulignés au paragraphe précédent résultent des mécanismes mondiaux de la normalisation et de la philosophie générale de la HLA. Certains des arguments développés avaient un aspect technique. Dans ce second paragraphe, il s’agit maintenant de discuter d’aspects plus spécifiques ou de progrès techniques fournis par la HLA par comparaison avec ses prédécesseurs ou concurrents. Il faudra bien sûr que les normes qui succéderont à la HLA offrent un niveau au moins égal de fonctionnalité.

2.8.2.1 La gestion du temps

Les prédécesseurs de la HLA ne permettaient pas d’interconnecter des simulateurs/simulations avec des gestions du temps différentes : limitation aux simulations constructives à événements discrets pour

47 Matériel et système d’exploitation.


ALSP, aux simulateurs « temps réel » pour DIS (sans possibilité de contrôle et de coordination des temps locaux). La HLA permet de faire fonctionner différents types de gestion du temps dans une même fédération favorisant ainsi les possibilités de réutilisation de différents fédérés dans des applications de nature différente. La présence de mécanismes de gestion du temps constitue un des avantages majeurs de la HLA par rapport à CORBA.

2.8.2.2 Le transfert de propriété des attributs d’objets

La possibilité de transférer la propriété de certains attributs d’objets d’un fédéré à l’autre est une spécificité de la HLA. Cette capacité permet de transférer la responsabilité de modéliser différents attributs d’objets d’une représentation du monde réel aux fédérés les mieux à même de le faire sur une période donnée. C’est une méthode efficace et élégante de résoudre les problèmes de modélisation multi-niveau dans un système de simulation distribué. Elle peut permettre également des gains en performances lorsque des modèles simplifiés sont suffisants pour représenter des systèmes complexes, tout en permettant, lorsque c'est nécessaire, d'avoir recours à des modèles détaillés. Cette capacité de transfert de propriété est actuellement unique à la HLA.

2.8.2.3 La distribution optimisée des données

La norme DIS n’avait qu’un seul mode de diffusion : le mode « broadcast ». Il en résultait un manque de contrôle et une perte de performance éventuelle en cas de saturation des réseaux informatiques. Bien que la famille de services de distribution des données de la HLA n’ait été que peu utilisée jusqu’ici, on peut penser que cette caractéristique unique de la HLA prouvera son utilité avec le développement et la croissance des exercices distribués.

2.8.3 La HLA et la promotion des bonnes pratiques

En dehors des avantages nombreux évoqués dans les paragraphes précédents, la HLA a permis de faire la promotion des bonnes pratiques dans le domaine de la simulation alors qu’elles étaient souvent ignorées par une partie de la communauté de la simulation. Ces avancées ne sont pas directement issues de la HLA mais l’influence de la norme sur ces progrès est indéniable (voir la référence [B11]).

Le premier progrès est la promotion des concepts « orientés objet ». Avant la HLA, les ateliers d’interopérabilité ne comportaient qu’un seul forum sur la « simulation distribuée orientée objet » et il était peu fréquenté. Il est patent que, depuis 1997, un large pourcentage des travaux publiés dans le domaine de la simulation font référence aux concepts « orientés objet » alors qu’avant cette date peu de praticiens du domaine de la simulation avaient réalisé les avantages de ce paradigme. Ce progrès est quelque peu paradoxal puisque la HLA n’a pas adopté une vision très pure des concepts courants. On notera d’ailleurs qu’une simulation peut être compatible avec la HLA sans être « orientée objet » (voir paragraphe 2.5.1), mais il semble que la communauté M&S ait réalisé l’avantage de cette approche par rapport à des approches différentes depuis l’apparition de la norme HLA à laquelle revient donc une part du crédit.

On reconnaît généralement que la HLA a fait la promotion des meilleures pratiques du développement logiciel, parce que ses inventeurs s’en sont largement inspirés :

• Séparation des services et des modèles (exemples de la RTI assurant la communication et des fédérés qui contiennent les modèles) ; cette séparation n’était pas toujours clairement assurée dans les développements passés.

• Déclaration et enregistrement des entités, modularité, encapsulation, séparation entre parties publique et privée, sauvegarde et restauration, etc.

Plus globalement, la HLA a assuré la promotion d’une approche structurée et d’une méthodologie adaptée. Les premières expérimentations de la HLA (en 1996) ont montré l’importance d’une telle démarche. La norme HLA IEEE 1516-2000 a été complétée en 200348 par un guide méthodologique, le FEDEP, puis la norme HLA IEEE 1516-2010 a été complétée par un autre guide méthodologique, le

48 Même si une version du FEDEP existait dans la version 1.3 mais ne faisait pas partie de la norme.


DSEEP qui étend ses recommandations aux simulations distribuées, et pas simplement sous HLA (voir paragraphe 2.4.5). En parallèle, de nombreux outils pour soutenir ce processus d’ingénierie ont été développés (voir chapitre 4). Sous cet aspect méthodologique, la HLA a vraiment eu une influence bénéfique. Elle a d’ailleurs favorisé l’adoption d’approches structurées telle que la MDA (Model Driven Architecture) ou des langages de description tels que XML (eXtensible Mark-up Language) et UML (Unified Modeling Language) par la communauté M&S.

L’objectif de la HLA de réutiliser des simulations a eu également un effet indirect. Cette réutilisation a montré à une partie de la communauté américaine l’intérêt de s’intéresser à la construction des simulations par composition. Cette approche est non seulement compatible avec la HLA mais permet de simplifier le processus d’évolution des simulations. Cette approche par composition est typique des EDES : c’est la base de produits comme DirectSim qui permet d’étendre les capacités d’une application soit en monolithique par intégration de nouveaux composants, soit en distribué par interconnexion via la HLA. Des travaux sont actuellement en cours pour mieux intégrer cet aspect dans la HLA (voir le paragraphe 6.2sur les BOMs, Base Object Models).

2.8.4 La HLA, modèle de norme

Tous les experts étaient d’accord pour reconnaître quelques imprécisions et lacunes dans la rédaction des versions précédentes de la norme HLA (on parlait quelquefois de « sous spécification »). Ce défaut est d’ailleurs largement partagé par les normes du domaine du développement logiciel. Il n’a pas épargné la HLA, mais l’architecture a largement bénéficiée des apports de la dernière révision de la norme, la HLA IEEE 1516-2010 : les normes HLA successives ont toujours su tirer profit des expérimentations passées. La politique de l’US DoD a toujours été de n’accepter des modifications de la norme HLA qu’après leur expérimentation : il en résulte une grande maturité de cette norme sans que son évolution n’ait été trop freinée.

Un des défauts attribués à la norme DIS était son manque de souplesse lié à la rigidité des formats d’échanges : cette norme DIS a donc été largement contournée et finalement peu respectée. Grâce à la possibilité de définir des formats d’échange des informations (via l’OMT), la HLA offre une plus grande souplesse et donc une plus grande aptitude à respecter la norme.

En outre, la HLA offre des possibilités de vérifier la conformité à la norme. Cette vérification se situe à deux niveaux :

• contrôle exercé sur l’outil principal de la HLA : la RTI. Un processus de vérification de conformité des RTIs à la norme HLA a été établi par l'US DoD et est toujours en place aujourd’hui. Ce contrôle garantit la conformité des RTIs à la norme.

• Un autre contrôle est exercé sur la conformité des fédérés à la norme : cet aspect est traité au chapitre 0 de ce guide.

Enfin, peu de normes sont accompagnées par des guides de pratiques recommandées. C’est le cas de la HLA avec le DSEEP déjà mentionné (voir référence [A16]).


3 METHODOLOGIES DE CONCEPTION SOUS HLA

Dans le chapitre 2, nous avons montré que l'architecture HLA offre les services minima permettant la réutilisation de fédérés existant et leur interopérabilité au sein d'une fédération. Ce caractère minimaliste des spécifications HLA tient à une volonté d'éviter les écueils de la précédente norme de simulation distribuée DIS, dont l'approche trop protocolaire, fondée sur un ensemble figé de PDUs 49 de communication, constitua un frein à son adoption.

En conséquence, il est extrêmement difficile de concevoir soit des fédérés HLA, soit des fédérations HLA sans le soutien d'outils méthodologiques formels ou pour le moins de recommandations. Dans ce chapitre, nous proposons donc de présenter brièvement les méthodes et les outils permettant d'assister les concepteurs d'applications de simulation distribuée, aussi bien en ce qui concerne les fédérations que les fédérés.

3.1 Conception de simulations distribuées

3.1.1 Le DSEEP

Avant 2010, le HLA FEDEP (Federation Development and Execution Process) constituait l'outil méthodologique de base pour la conception de fédérations HLA. La première version du FEDEP, publiée en septembre 1996, regroupait un ensemble de recommandations issues des discussions du OMT-WG (Object Model Template – Working Group du DoD). Entre 1996 et 1999, le DMSO finança l'élaboration et la publication de cinq nouvelles versions prenant en compte l'expérience des utilisateurs en matière de conception et développement de fédérations HLA.

En septembre 2000, HLA devint la norme IEEE 1516-2000 de simulation distribuée. En décembre 2000, la certitude que l'architecture HLA devait être accompagnée de supports méthodologiques rigoureux, conduisit à l’introduction du FEDEP dans la série de la norme IEEE 1516 elle-même. Après de nombreuses discussions dans les groupes de travail concernés, une version améliorée du FEDEP fut adoptée an avril 2003, sous forme de "pratique recommandée", en tant que document IEEE 1516.3-2000.

L'importance du FEDEP résidait non seulement sur le fait qu'il s'agissait d'un véritable processus d'ingénierie, mais également sur le fait qu'il constituait un référentiel largement admis50 dans plusieurs activités de normalisation ou de standardisation menées autour de la HLA et de la simulation distribuée, notamment le processus de VV&A (Validation, Vérification et Accréditation/Acceptation). En outre, il constituait également un guide très utile (voire indispensable) à la gestion de projet, l'analyse des exigences et des besoins, et la conception d'applications de simulation.

Avec la publication de la norme HLA IEEE 1516-2010, approuvé en mars 2010, le FEDEP fut remplacé par le DSEEP comme évoqué précédemment [A16]. Il s’agit du document normatif IEEE Std P1730-2010, publié en janvier 2011. Ce guide méthodologique étend son précurseur aux simulations distribuées et pas seulement celles utilisant la HLA.

A la date de la mise à jour de ce guide HLA, 2 initiatives sont en cours autour du DSEEP. La première, le TEO DSEEP51 fait l’objet d’un groupe de travail à la SISO qui s’est réuni la première fois en septembre 2010 pendant les ateliers SIW d’automne. L’objectif de cette initiative est de complémenter le DSEEP par un overlay permettant de prendre en compte les spécificités des simulations distribuées pour les Essais et l’Evaluation (T&E). La seconde initiative autour du DSEEP est le DMAO DSEEP52 qui fait l’objet d’un PDG53 à la SISO. La première réunion a eu lieu en septembre 2010 à Orlando (FL) pendant les ateliers SIW d’automne. L’objectif de cette initiative est de complémenter le DSEEP par un overlay permettant de prendre en compte les spécificités des 49 Protocole Data Unit. 50 Dans le contexte HLA. 51 Test and Evaluation Overlay to the DSEEP. 52 Multi-Architecture Overlay to the DSEEP. 53 Product Development Group.


simulations distribuées supportant plusieurs architectures différentes (HLA, DIS, TENA …). Le premier tour de commentaires a débuté en février 2011 afin que leur résolution puisse être étudiée pendant les ateliers SIW de printemps, en avril 2011 à Boston.

Au niveau d'abstraction le plus élevé, les étapes du DSEEP sont représentées par la Figure 4. On remarquera que tous les termes spécifiques de l’architecture HLA (Fédération, Fédérés, RTI …) qui étaient présents dans le FEDEP ont été supprimés pour rester en cohérence avec l’objectif de généralisation de la méthodologie à toutes les simulations distribuées.

Pour chaque étape du processus, un certain nombre de recommandations sont fournies. A ce niveau d'abstraction, les étapes du DSEEP correspondent aux différentes phases du cycle de développement et d'exécution d'une simulation distribuée :

Etape 1 : identification des objectifs de la simulation.

L'équipe projet et les utilisateurs analysent conjointement les besoins et les objectifs de la simulation ainsi que les documents capitalisant les résultats de cette étape.

Etape 2 : Développement d'un modèle conceptuel.

Cette étape consiste à développer une représentation pertinente du monde à simuler, identifier des scénarios génériques, traduire les objectifs en activités sous forme d'entités et d'actions sur ces entités, enfin à identifier les exigences de la simulation.

Etape 3 : Conception de l’environnement de simulation.

Cette étape consiste à sélectionner les composants54 de l’environnement de simulation et définir leur rôle à la lumière des scénarios élaborés, afin de préparer un projet de simulation sous forme de guide au développement, au test et à l'exécution de la simulation.

Etape 4 : Développement de l’environnement de simulation.

Cette étape a pour objectif de définir les données qui seront échangées par les composants de la simulation55 pendant son exécution. Cette étape permet également de vérifier l'adéquation des composants au rôle qu'ils doivent jouer au sein de la simulation. Enfin, le cas échéant, cette étape concerne également les modifications des composants participant à la simulation et le développement des composants nouveaux si nécessaire.

Etape 5 : Intégration et test de l’environnement de simulation.

Cette étape rassemble les phases d'intégration et de test conventionnelles dans tout projet de développement logiciel. La phase de test se décline en trois niveaux :

• les tests des composants afin de vérifier que leur implémentation est correcte et conforme aux exigences ;

les tests d'intégration permettant de vérifier que les composants communiquent convenablement avec l’infrastructure de simulation ;

enfin, les tests d’interopérabilité, pour vérifier que les données échangées entre les composants de la simulation permettent d’atteindre les objectifs d’interopérabilité fixées par les exigences de la simulation.

54 Dans le jargon du DSEEP, un composant est désigné par le terme « member ». 55 Dans le FEDEP, cette étape produisait le FOM de la fédération.


Figure 4 Les étapes du DSEEP (version IEEE P1730-2010)

Reproduit avec permission de l’IEEE

Etape 6 : Exécution de la simulation et préparation des résultats.

Au cours de cette étape, la simulation est exécutée et les résultats collectés pour analyse. Au cours de cette étape, tous les participants du projet, concepteurs et utilisateurs, sont réunis afin de statuer sur la validation de la simulation par rapport aux besoins et objectifs identifiés. Comme le FEDEP, le DSEEP est un processus itératif intégrant des actions correctives permettant de revenir aux étapes précédentes.

Etape 7 : Analyse des résultats de la simulation.

Cette étape consiste à post-traiter les résultats de l'exécution afin de les analyser et les évaluer. Cette évaluation est restituée à l'utilisateur final (le client56), pour qu'il statue sur la capacité de la simulation à répondre au problème posé.

Chaque étape du DSEEP correspond donc à un ensemble d'activités reliées entre elles et donnant lieu à la publication et/ou la mise à jour d'un ensemble de documents. En outre, le DSEEP peut constituer un référentiel permettant de structurer les outils accompagnant les simulations distribuées en classes, chacune d'elle étant relative à une étape du DSEEP. Le FEDEP avait été complété, en 2007, avec un processus standard de VV&A. Le document s’intitule « Recommended Practices for Verification, Validation and Accreditation of Federation, an overlay to the HLA FEDEP », IEEE 1516.4 (référence [A4]). De même, une évolution de ce document de pratiques recommandées pour la VV&A est en cours pour accompagner le DSEEP.

56 User/Sponsor.


Le DSEEP reste évidemment très inspiré du HLA FEDEP, même si toutes les références directes à la HLA ont été supprimées : il comporte maintenant 3 annexes, donnant le vocabulaire et les spécificités correspondant à 3 architectures ou protocoles DIS57, HLA et TENA58.

Malheureusement, la décision de généralisation du FEDEP a pour effet de rendre un peu abstraits les termes et concepts utilisés : ainsi, le terme "fédération", jugé trop marqué HLA, a été remplacé par "environnement de simulation", ce qui est fort imprécis et prête à confusion, et le terme "fédéré" a été remplacé par le terme "membre" qui est aussi très général et imprécis. Dans ce contexte, le DSEEP, tel qu'il est actuellement, semble moins "sexy" que le FEDEP, même s'il a hérité des principales qualités de son prédécesseur.

3.1.2 Le RPR-FOM

Le RPR-FOM (Real-time Platform Reference Federation Object Model) ne constitue pas véritablement un outil méthodologique pour guider la conception de fédérations HLA (référence [A12]). Il s'agit en premier lieu, d'un outil de migration des simulations distribuées DIS vers des fédérations HLA. Rappelons que la communication entre nœuds de simulation DIS est supportée par un ensemble de messages au format normalisé, appelés PDU (Protocol Data Unit).

Le RPR-FOM fut développé pour répondre à 3 exigences principales :

• guider la migration de simulations DIS vers HLA,

• fournir un référentiel commun à tous les utilisateurs du RPR-FOM en normalisant une hiérarchie des classes du modèle objet HLA,

• enfin, faciliter le développement de nouveaux fédérés HLA.

La version 1.0 du RPR-FOM concerne la migration de la norme DIS approuvée comme norme IEEE 1278.1-1995, alors que la version 2.0 concerne la norme IEEE 1278.1A-1998 de DIS et supporte la norme HLA 1516. Ces deux versions sont malheureusement incompatibles.

Le RPR-FOM fut développé en utilisant les conventions de nommage proposées dans OMDD (Object Model Data Dictionary), permettant ainsi une compréhension commune des termes et du vocabulaire employés.

Le RPR-FOM fournit une correspondance entre les PDU DIS et les classes d'objets et d'interactions HLA. Il est illusoire dans ce document de présenter l'ensemble des transitions. Le lecteur est invité à consulter le document de référence. En outre, il procure des correspondances pour migrer certains mécanismes de DIS qui font intégralement partie de cette norme, vers HLA. Ainsi, il présente les mécanismes permettant d'implémenter sous HLA les mécanismes d'extrapolation appelés dead reckoning. Enfin, il propose une hiérarchie de classes d'objets et d'interactions normalisée pour le modèle objet HLA. A la date de rédaction de ce document, le groupe en charge de la rédaction du document normatif a été dissous par manque de volontaires. La dernière version disponible du RPR FOM (version 2.0, draft 17) restera probablement la dernière. A la date d’aujourd’hui, une migration du PDG vers un PSG59 est en cours.

Le RPR FOM est le FOM de référence le plus utilisé dans le monde. Le compagnon indispensable du RPR FOM est le GRIM60 qui propose une description des composants des FOM et des relations entre les PDUs DIS et le RPR-FOM de la HLA (référence [A13]).

3.2 Conception de simulations conformes à HLA

Normalement la conception et le développement d’un nouveau fédéré ne se conçoivent que dans le contexte d’une fédération donnée (étape 3 et 4 du DSEEP), lorsqu'aucun(e) simulateur/simulation 57 Standard IEEE 1278. 58 Testing and training Enabling Architecture. 59 Product Support Group. 60 Guidance, Rationale, and Interoperability Manual for the Real-time Platform Reference Federation Object Model.


connu(e) et conforme à la HLA ne satisfait un besoin identifié. Dans ce cas, des spécifications de développement sont établies et les besoins d’interconnexion avec les autres fédérés permettent de guider les concepteurs et développeurs du nouveau fédéré sur les capacités à développer.

Ce paragraphe traite surtout des cas ou l’on veut :

• Soit développer ex nihilo une nouvelle simulation en conformité avec la HLA sans qu’un besoin particulier d’intégration au sein d’une fédération donnée n’ait été exprimé ; dans ce cas on souhaite d’abord l’utiliser seule, et, ensuite, pouvoir la réutiliser dans une fédération HLA en anticipant des besoins futurs,

• Soit mettre en conformité une simulation préexistante61, c'est-à-dire lui conférer des capacités de communication en conformité avec la norme HLA sans objectif précis d’intégration à une fédération donnée.

3.2.1 Développer de nouvelles simulations conformes à HLA

Dans un contexte HLA ou pas, il est toujours fortement déconseillé de développer une simulation en partant de rien. Il est généralement admis que 30 à 60% du code des simulations constructives est consacré aux services courants qui soutiennent la mise en œuvre et l’exploitation des simulations. Par exemple,

• La gestion des entités et de leurs interactions,

• La gestion des données et des scénarios,

• L’affichage graphique,

• Etc.

La conception et le développement de nouvelles simulations doivent donc se faire en utilisant un environnement de développement et d'exploitation de simulation existant (EDES ou SSE62 en anglais). Si l’on a le choix, l'EDES sélectionné devra être soutenu par une méthodologie de conception et de développement adaptée. Concernant la HLA, il est clair qu’il vaudrait mieux que l'EDES choisi soit « dans l’esprit » de la norme : de préférence « Orienté Objet », il est aussi important qu’il sépare clairement services et modèles. Il devra fournir nativement des services de haut niveau HLA évitant aux développeurs de s’interfacer directement avec une RTI, leur facilitant un certain nombre de tâches d’implémentation laissées par la norme sous la responsabilité des développeurs : le « data marshalling »63 est un exemple courant. Il vaut mieux également s’assurer qu’il peut s’adapter à différentes RTI existantes dans l’impossibilité de prévoir celle qu'il devra utiliser. Par exemple en France, ESCADRE (développé par la DGA) et Ductor (développé par la Marine) répondent à ces critères. Leur successeur DirectSim dispose d'une capacité HLA 1516. GENESIS développé par l’ONERA fournit une autre voie. Enfin, il est aussi souhaitable que l'EDES choisi permette d’utiliser la nouvelle simulation seule ("stand-alone") comme à l’intérieur d’une fédération.

Parallèlement aux solutions étatiques permettant le développement de fédérés HLA, des solutions commerciales coexistent telles que Stage de Presagis, S-mission de CAE (Canada)64, Flames de Ternion (US), VR Forces de VT MÂK ou SIMplicity de Calytrix (Australie). Il y en a certainement d’autres. Le jeu sérieux VBS2 de Bohemia Interactive Simulations dispose également d'une capacité HLA dans sa version 2010. Les capacités exactes en termes de HLA de ces produits commerciaux restent à évaluer. La documentation commerciale existante donne peu d’informations précises sur leur capacité HLA exacte… Aucune recommandation ferme relative à ces produits ne peut être donnée tant qu’un fédéré développé sous ces environnements n’aura subi une certification HLA officielle via une

61 Les anglo-saxons parlent de « legacy » simulation. 62 Acronyme anglais pour « Simulation Support Environment ». 63 Il s'agit des conventions de codage des nombres sous forme de "big endian" ou "little endian", qui diffèrent selon les machines, ainsi que de la représentation des types complexes. 64 Qui dispose d’une RTI incomplète et non certifiée, à usage interne.


nation ou un pays partenaire pour la paix de l’OTAN (le Canada, l’Espagne, la France, le Royaume-Uni, la Suède et les US disposent ou disposeront bientôt de cette capacité de certification).

3.2.2 Adapter une simulation préexistante à HLA

Malgré sa qualité, le DSEEP65 donne peu de conseils sur la mise en conformité de simulations préexistantes à la norme HLA ou sur l’évolution de fédérés existants dans le cadre d’une nouvelle fédération : ce n’est pas son objectif premier. Il n’est également d’aucune utilité dans le cadre plus abstrait de développement de capacités HLA d’une simulation sans objectif précis d’intégration à une fédération non spécifiée !

Un seul document dédié à ce sujet existe (référence [B10]) : « Cookbook to Adapting Simulations for the HLA ». Ce document canadien (en langue anglaise) est remarquable. Il ne traite malheureusement que de la version US DoD 1.3, mais pourrait être facilement mis à jour pour la version actuelle de la norme. Cela dit tous les principes exposés restent valables et les paragraphes qui suivent sont largement inspirés par ce document dont la lecture est indispensable aux chefs de projets.

Le processus d’adaptation comporte 5 étapes :

1. évaluer votre simulation en termes de réutilisation et d’interopérabilité,

2. développer un SOM,

3. identifier les services de la RTI requis, en cohérence avec le SOM produit,

4. implémenter le fédéré (ou plus exactement ses modifications),

5. documenter le fédéré et prévoir les éventuelles améliorations.

3.2.2.1 Etape 1 : évaluation du potentiel de la simulation comme futur fédéré

Cette phase consiste à essayer d’identifier quels sont les points forts de la simulation : quels sont les aspects qu’elle modélise le mieux et qui pourraient faire souhaiter son intégration dans un système de simulation distribué. Par exemple, la simulation Janus est connue pour bien modéliser le combat terrestre : il est vraisemblable qu’elle offre un fort potentiel dans ce domaine.

Il faut dans une perspective d’intégration future, identifier également les points faibles d’une simulation : ceux pour lesquels des modélisations extérieures permettraient d’enrichir la crédibilité du système dans un domaine d’utilisation plus large que le domaine habituel. Par exemple, toujours pour Janus, les aspects senseurs ou aériens ne sont pas finement modélisés parce que cela n’était pas nécessaire dans les applications envisagées jusqu’ici. On voit que dans le cas où l'on envisage une utilisation de Janus dans un contexte plus large, il vaudrait mieux s’abonner à des informations issues de modèles plus détaillés de plates-formes aériennes ou de senseurs. Il faudrait ainsi spécifier des attributs et des paramètres au niveau utilisable par Janus pour les classes d’objet et les interactions auxquelles on s’abonnerait. On voit qu’il est difficile de généraliser cette approche, chaque simulation étant un cas particulier.

Enfin, il faut également s’interroger sur des aspects plus techniques relatifs à la HLA tels la capacité d’utiliser les services HLA de gestion du temps, de fonctionner en mode régulateur ou contraint, par exemple, qui dépend fortement de la façon dont est géré le temps en interne dans le futur fédéré. Tout ceci nécessite une bonne connaissance de HLA comme des capacités de la simulation à faire évoluer et des services fournis par son moteur de simulation. Il est vraisemblable que cette analyse permettra d’établir des limites et d’identifier le type de fédérations auquel le futur fédéré pourra participer.

Cette étape devra également permettre d’évaluer le niveau de l’effort à fournir pour mettre à niveau la simulation et conduira peut-être à limiter les évolutions de la simulation si les ressources sont limitées.

65 Son prédécesseur, le FEDEP, non plus.


3.2.2.2 Etape 2 : développement du SOM de la simulation

Dans cette étape il est préférable de considérer la simulation comme une boîte noire et la constitution du SOM pourra être considérée comme l’identification des entrées et sorties de cette boîte. Ne devront apparaître que les données publiques de la simulation et non les données privées (celles qui sont utiles aux modèles sous-jacents).

La première étape de la conception du SOM est la construction d’un modèle abstrait "orienté objet" de la simulation. Si l’application est orientée objet, ce modèle existe déjà. Sinon il s’agira d’un exercice purement intellectuel et qui n’aura pas d’incidence sur la façon dont votre application a été conçue et implantée.

Cet exercice d’abstraction des classes d’objet et d’interaction peut être difficile et il est bon d’utiliser des références quand elles existent. Actuellement il n’existe qu’un FOM de référence très général et largement disponible : le RPR FOM66. L’utilisation de ce FOM de référence est recommandée : c’est pratiquement le seul accessible librement à ce jour et comme beaucoup de fédérations existantes l’utilisent, il pourrait bien faciliter l’intégration de votre futur fédéré dans une fédération.

Les tables constituant le SOM fournissent une documentation de plus en plus détaillée lorsque l’on avance dans la liste des tables et vers l’implémentation. On commence par les tables d’objets et d’interactions, puis on passe aux tables d’attributs et de paramètres, etc. Les formats de données67 échangées, les unités physiques peuvent être provisoirement ceux de l’application : de toute façon dans le cas d’intégration à une fédération, ces formats et unités échangés devront être négociés. Les mécanismes de spécialisation sous-jacents (mécanisme d’héritage entre classes) doivent faciliter une démarche progressive (à condition qu’un effort d’abstraction soit bien fait si la simulation n’est pas nativement orientée objet). Même si c’est le cas, il est recommandé de se concentrer sur cet effort d’abstraction en se souvenant que le SOM ne représente pas forcément la structure interne de la simulation mais une vision idéalisée de ce qu’elle pourrait être.

Le processus de développement du SOM est décrit en détail dans la référence [B10] à laquelle on se reportera. Ce document s’appuie sur la version 1.3 de la norme HLA et on devra donc le généraliser quand on utilise une des versions 151668. Mais les principes décrits restent valables.

3.2.2.3 Etape 3 : identification des services de la RTI pour soutenir le SOM de la simulation

Ces services sont décrits au paragraphe 2.5 de la référence [B10]. Il est obligatoire de s’intéresser aux trois premiers groupes de services, à savoir :

• la gestion des fédérations,

• la gestion des déclarations,

• la gestion des objets.

On pourra se référer au paragraphe 2.5.3 de la référence [B10] pour plus de détails sur ces 3 groupes de services. L’utilisation des services principaux de ces 3 groupes constituent un minimum pour la conformité d’une simulation à la HLA et sa capacité à échanger des informations avec d’autres fédérés.

Un quatrième groupe de services doit encore être examiné : celui de la gestion du temps. Si la simulation n’est pas capable d’utiliser ces services, il est clair qu’elle ne pourra pas participer à des fédérations avec coordination du temps et pourra donc uniquement participer à des exercices en « temps réel » au sens plus ou moins strict. Si elle n’est pas « temps réel » et n’est pas capable d’utiliser les services HLA de gestion du temps, la validité de son utilisation en distribué doit être sévèrement remise en question. Concernant l’utilisation de ces services, il faut rappeler une chose importante qui est de s’assurer que la simulation ne recevra jamais des messages datés dans son passé 66 Real Platform Reference FOM (standard SISO). Prononcer “Reaper FOM”. Voir paragraphe 3.1.2. 67 A partir de la norme IEEE 1516-2000, ces formats sont rigoureusement définis, dans la table des types de base. 68 Les principales différences entre 1.3 et 1516-2000 concernent principalement l’OMT.


(respect du principe de causalité). C’est ce principe qui doit guider la conception et le développement dans son utilisation des services HLA de la gestion du temps.

Les 2 autres groupes de services que sont la « gestion de la propriété » et la « distribution optimisée des données » ne peuvent être considérés que dans le cadre d’une fédération donnée : il est difficile de s’y intéresser dans un cadre plus abstrait. On ne discutera donc pas ces groupes de services au niveau d’un fédéré particulier.

Le dernier groupe de services de la RTI regroupe des utilitaires variés et il est bien difficile de donner un avis sur leur utilisation dans le cas d’un fédéré s’il n’est pas destiné à être intégré dans une fédération spécifiée.

3.2.2.4 Etape 4 : implémentation des évolutions HLA de la simulation

Cette étape est abondamment décrite dans la référence [B10] à laquelle il convient de se référer. En fournir les détails dépasse le contexte de ce guide.

Il faut en retenir les grandes lignes suivantes, fondées sur trois approches alternatives :

• Intégration directe avec une RTI (via une API adaptée),

• Intégration via un intergiciel69 compatible avec la RTI utilisée,

• Intégration via un environnement de développement et d'exploitation de simulation (EDES ou SSE).

La troisième solution est difficile à envisager pour des simulations existantes et peut conduire à davantage de problèmes que de solutions correctes aux problèmes à traiter. Elle n’est à recommander que pour le développement de nouveaux fédérés (voir le paragraphe 3.2.1).

La seconde solution semble la meilleure à condition que le produit choisi soit indépendant d’une RTI spécifique et d’un FOM donné. Il évitera aux développeurs de résoudre un certain nombre de problèmes tels que le « data marshalling » ou l’extrapolation (« dead reckoning ») par exemple. Cette solution est généralement préférable malgré un relatif manque d’expérience dans la plupart des cas. Elle s’impose en tout cas quand il s’agit de faire évoluer une application compatible de DIS vers HLA. De nombreux produits commerciaux existent pour faciliter cette transition70, mais il est vraisemblable que, si l'on choisit cette solution, on sera limité au RPR FOM et aux trois premiers groupes des services HLA. On n’aura vraisemblablement pas d’aide pour la gestion du temps.

La première solution nécessite un très bon niveau de programmation, de connaissance et d’expérience pratique de la HLA, de connaissance de l’architecture de la simulation à faire évoluer et de son noyau. Elle est donc réservée aux équipes expérimentées. Ses bénéfices possibles sont une meilleure adaptation aux spécificités de l’application concernée et une indépendance vis à vis de solutions propriétaires. Un certain nombre de précautions méthodologiques et les conseils de la référence [B10] (paragraphes 2.5.2 et 2.5.3) devraient être utiles aux intrépides s’engageant dans cette voie difficile. Les experts en simulation y reconnaîtront des solutions d’implémentation qu’ils utilisent sans doute déjà.

La référence [B10] fournit des conseils pour l’intégration et le test des évolutions HLA implantées (paragraphe 2.5.4). On peut compléter ce qui est dit dans ce document en conseillant aux développeurs de passer une certification de conformité à la HLA (voir chapitre 0 du présent guide). Le dernier paragraphe du chapitre 2.5 de la référence [B10] traite des aspects « validation » du fédéré. Ce sujet n’est pas traité en profondeur mais ce qu’il exprime est sensé.

3.2.2.5 Etape 5 : documenter le fédéré et prévoir les éventuelles améliorations

Cette dernière étape traite des aspects documentation et archivage du fédéré. Comme on le sait, le SOM du fédéré est insuffisant pour fournir toute l’information nécessaire à sa réutilisation. Il est

69 Terme français pour désigner la notion de « middleware » en anglo-saxon. 70 Certains sont même gratuits et livrés avec l’achat d’une RTI commerciale.


conseillé de développer une documentation adaptée en parallèle de la conception et du développement des fédérés : un « modèle conceptuel » du fédéré et un guide d’utilisation sont un minimum. Ces documents accompagnés du SOM et du « Conformance Statement » (CS)71 du fédéré doivent être archivés dans une bibliothèque accessible aux personnes ayant la possibilité de le réutiliser.

Il est vraisemblable que le fédéré ainsi développé ne sera jamais parfaitement adapté à une fédération spécifiée. Il est donc conseillé d’accompagner la documentation avec un document renseignant les limites de l’implémentation actuelle (quelles qu’en soient leurs causes), les améliorations non retenues mais jugées possibles et la façon de les implémenter. Il s’agira donc d’un « guide de maintenance » ou d’un nouveau chapitre de ce guide s’il existait déjà.

71 Déclaration (sous forme d’une liste) des services HLA utilisables par le fédéré (voir chapitre 0 de ce guide), document qui fait partie de l’OMT de la norme IEEE 1516-2010 sous l’appellation « Interface specification services usage table ».


4 LES OUTILS HLA

Compte tenu de la complexité de HLA, les développeurs de la norme ont admis très vite l’importance d’un processus d’ingénierie logiciel pour sa mise en œuvre (le HLA FEDEP d’abord, le DSEEP ensuite, voir paragraphe 3.1.1) et d’outils pour soutenir ce processus. Un certain nombre d’études de définition et d’exploration de ces outils ont été faites dans les cadres OTAN, WEAG (RTP 11.1372) et nationaux. On peut citer dans l’ordre chronologique :

• Les études OTAN du NIAG (NATO Industry Advisory Group) de 1998 et 2000 : ces études listaient un nombre important d’outils ; l’intérêt pratique et économique de beaucoup d’entre eux reste à démontrer,

• L’étude OTAN du NMSG (NATO M&S Group) MSG-005 “Des outils d’aide au processus de développement et d’exécution de fédérations (FEDEP) », parue mi-2003. Cette étude liste les outils disponibles à cette époque sans en préconiser un usage intensif. L’étude fut poursuivie dans le cadre du « Working Group » MSG-038, puis MSG-050 [A18]. Un des résultats intéressants de ces études fut la publication d’un schéma XML normalisant les champs permettant de décrire les outils. Ce schéma XML est disponible sur le NSRL73.

Le schéma (page suivante, Figure 5) est extrait du rapport du « Working Group » MSG-005. On notera qu’il met en évidence peu d’outils spécifiques à la HLA : il rappelle que l’on n’est pas dispensé d'utiliser les outils habituels du développement de simulations ou de logiciels en général, dans le développement des fédérations HLA. Les outils présentés dans cette étude sont soit reliés aux 7 étapes du FEDEP74, soit reliés à 7 catégories tirées des rapports NIAG rappelées ci-dessous :

o Développement de fédérations HLA (étapes 4 et 5 du FEDEP), en particulier, des outils de création et édition des modèles objet HLA (SOM et FOM),

o Outils de création, d’édition, de visualisation de bases de données d’environnement (étapes 4 à 7 du FEDEP),

o Outils de développement de scénarios (étapes 2 à 5 du FEDEP),

o Outil de soutien à l’exécution de fédérations (dont les RTIs, étapes 5 et 6),

o Outils, de visualisation (2D ou 3D) utilisés pendant les étapes 4 à 7 du FEDEP,

o Outils pour l’analyse après l’exploitation des fédérations (AAR75),

o Outils génériques d’interfaçage vers les systèmes d’information opérationnels,

o Outils de soutien pour la validation et la vérification des fédérations HLA.

• On notera (sans surprise) que pas ou peu d’outils des 2 dernières catégories existent. Les outils proposés par le RTP 11.13 (voir plus loin) ne figuraient pas dans cette étude, le RTP 11.13 étant achevé postérieurement.

• En France, l’étude ARCOSIM HLA a été achevée début 2004. Elle comporte une partie consacrée aux outils HLA. Cette étude décrit une série raisonnable d’outils et fournit des références à des outils commerciaux disponibles. Elle apparaît très complémentaire à l’étude OTAN MSG-005. Ces 2 études ont en commun de présenter un inventaire des outils disponibles à une époque donnée (mi-2003 et début 2004). Les paragraphes 4.1 et 4.2 de ce guide utilisent les catégories d’outils identifiés dans ces 2 études.

72 RTP (Research and Technology Program) numéro 11.13 : programme en coopération impliquant 13 pays du Groupe Armement de l’Europe Occidentale (WEAG). 73 NATO Simulation Resource Library. 74 Le DSEEP n’existant pas à cette date. 75 After Action Review.


• L’étude RTP 11.13 s'est achevée en 2003 dans le cadre du CEPA76 11. Le thème du RTP 11.13 était “Realising the Potential of Synthetic Environments in Europe”. Cette étude a été l’occasion de développer une version spécifique du FEDEP (le SEDEP pour Synthetic Environment Development and Execution Process) et a identifié 24 outils pour soutenir ce processus particulier77. Des prototypes de ces outils ont été développés. Ils étaient disponibles pour les nations et les industriels participants au programme. Actuellement leur intérêt est divers et leur degré d’achèvement ne permet pas d’en recommander l’usage général. Ces remarques sur les outils ne remettent pas en cause l’intérêt général du RTP 11.13 et la qualité du travail effectué qui sont incontestables.

Define Federation

ObjectivesPerform Conceptual

AnalysisDesign

FederationDevelop

FederationPlan, Integrate, &Test Federation

Execute Federation &Prepare Results

Analyze Data &Evaluate Results

HLA-SpecificResources

M&S Domain-Specific Tools

General PurposeTools

ConfigurationManagement

Tool

Version ControlTool

VV&ATool

ScenarioDevelopment

Tool

ConceptualAnalysis

Tool

ExecutionPlanning

Tool

PerformanceModeling

Tool

FederationTesting

Tool

RuntimeInfrastructure

RuntimeManagement

Tool

RuntimeMonitoring

Tool

DataCollection

Tool

ExecutionEnvironment

RequirementsDefinition

Tool

Data/StatisticalAnalysis

Tool

FederationObjectivesStatement

FederationConceptualModel

FederationScenario(s)

After ActionReview Tool

Federation Requirements

Federation Test Criteria

Object ModelDevelopment

Tool

ExecutionEnvironmentDescription

FOM

FED /FDD

Raw ExecutionOutputs

DerivedOutputs

ScenarioDatabase

AuthoritativeResources

Object ModelsAnd Object Model

Components

Figure 5 Association des outils HLA aux étapes du FEDEP (Extrait du rapport OTAN MSG-005)

La Figure 5 distingue horizontalement (du bas vers le haut) 3 catégories d’outils :

• Des outils généraux non spécifiques du domaine M&S,

• Des outils spécifiques du domaine M&S,

• Des outils spécifiques à HLA et les bibliothèques associées.

L'interopérabilité entre ces outils est assurée par la définition de formats d’échanges normalisés. Les normes HLA IEEE 1516-2000 et IEEE-1516-2010 sont fondées sur l’utilisation du standard industriel XML de description de données.

76 CEPA (Common European Priority Area) numéro 11, on Defence Modelling & Simulation Technologies. 77 Le SEDEP a depuis été déclaré obsolète par ses gestionnaires britanniques, l'essentiel de ses caractéristiques ayant été repris par le DSEEP (voir section 3.1.1).


4.1 Les outils indispensables

A priori (en considérant uniquement la définition fonctionnelle de la norme HLA) un seul outil apparaît indispensable : la RTI ou « Run Time Infrastructure ». On notera en outre que les vendeurs actuels78 intègrent de nombreux outils à leur offre de RTIs qui permettent de se passer de nombreux outils listés aux paragraphes 4.2 et 4.3 :

• Outils de gestion et de supervision de la fédération,

• Passerelles vers d’autres normes (vers DIS ou de l’US DoD 1.3 vers HLA IEEE 1516-2000 ou IEEE 1516-2010), etc.

Il serait illusoire de penser à développer une RTI pour une application particulière : ce type de middleware est délicat à concevoir et à développer. Le temps nécessaire serait prohibitif et les risques d’échecs importants. Le coût des RTIs est important mais l'outil est indispensable. Quelques produits libres existent mais peu ont subi une vérification de conformité par l’US DoD M&S CO79 (vérification que quelques outils du commerce ont déjà subie avec succès). Parmi, les produits libres et/ou gratuits on peut citer :

Le CERTI développé par l’ONERA et dont une étude de migration vers la norme IEEE 1516-2010 est en cours. Il s’agit d’une RTI « open source » téléchargeable à partir du site https://savannah.nongnu.org/projects/certi,

GERTICO développé en Allemagne par le Fraunhofer IOSB80. Cette RTI téléchargeable à partir du site http://www.iosb.fraunhofer.de/servlet/is/2920/, est gratuite mais pas « open source »,

PORTICO développée par des Australiens de la Société Calytrix. Il s’agit d’une RTI « open source » téléchargeable à partir du site http://porticoproject.org/index.php. Cette RTI offre une API Java à la norme IEEE 1516-2000.

L’expérience acquise sur HLA depuis 1997 montre qu’un autre type d’outil peut également être considéré comme indispensable : un outil pour développer et maintenir les modèles objet HLA (FOM et SOM) selon le format HLA OMT. Les « modèles objets HLA » sont décrits comme une suite de tables et, au début de la HLA, on pouvait penser qu’il suffisait d’un tableur tel qu'EXCEL pour les construire et les gérer. L’expérience a montré que l’utilisation d’un outil spécialisé (OMDT ou « Object Model Development Tool ») présentait les avantages suivants :

• Performance, confort d’utilisation, facilité d’apprentissage,

• Coût d’acquisition faible et rapidement amorti grâce au gain de temps et aux erreurs évitées par sa mise en œuvre,

• Existence de modèles de tables OMT HLA préétablies (schémas XML) et aides spécialisées pour les remplir, ce qui permet d’avoir un recours continuel au document décrivant la norme OMT,

• Vérification de la complétude et de la cohérence des informations,

• Importation/Exportation de tables existantes vers de nouvelles applications sous le format d’échanges normalisé (DIF ou « Data Interchange Format », basé sur la notation BNF ou « Bacchus Naur Form » pour la norme US DoD 1.3, et XML pour les versions IEEE 1516-2000 et IEEE 1516-2010),

• Plus généralement, transition des FOM/SOM d'une version HLA précédente vers la version suivante,

• Etc.

78 Notamment Pitch et Mäk Technologies. 79 Modeling and Simulation Coordination Office, qui a succédé au DMSO fin Octobre 2006. 80 Institute for Optronics, System Technologies and Image Exploitation.

https://savannah.nongnu.org/projects/certi�

http://www.iosb.fraunhofer.de/servlet/is/2920/�

http://porticoproject.org/index.php�


Les « Repositories » ou « Bibliothèques de ressources HLA » : un des objectifs de la HLA est la réutilisation des moyens de simulation : scénarios, bases de données, FOMs, SOMs, modèles, fédérés, etc.

De telles bibliothèques devraient exister au niveau de l’OTAN, en national et, en interne, dans les grandes organisations industrielles et étatiques. C’est un des intérêts de l’étude RTP 11.13 d’avoir mis ce point en évidence : le plein bénéfice de l’utilisation de HLA ne sera atteint qu’avec la mise à disposition de ressources partagées.

4.2 Les outils utiles

La Figure 5 ci-dessus extrait de l’étude OTAN MSG-005 décrit un certain nombre d’outils de soutien au FEDEP, bien que d’autres outils utiles n’y figurent pas. On notera qu’ils sont peu nombreux à la différence avec d’autres études où la praticabilité et l’aspect économique semblent avoir été ignorés :

• Outils de développement rapide des fédérés : on ne peut pas espérer, lors du développement d’une fédération HLA, que tous les modèles ou objets à modéliser existeront au niveau souhaité dans les bibliothèques disponibles ; il faut donc avoir recours à des outils de développement rapide et économique pour pallier ces manques, par exemple l'outil de génération de code GENESIS développé par l'ONERA, en France.

• Outils de gestion et de contrôle du déroulement des fédérations : ils sont quelquefois fournis avec les RTIs du commerce mais les outils élaborés ont quelquefois des coûts additionnels.

• Outils de test : la certification de conformité à HLA fournit quelques garanties du fonctionnement d’un fédéré ; cela ne dispense pas de vérifier en interne l’aptitude des fédérés en terme d’interopérabilité.

• Outils de visualisation 2D (« Plan View Display » ou PVD).

• Outils de visualisation 3D (« Stealth »).

• Outils d’enregistrement (« data logger »).

Concernant ces 3 derniers outils, utiles pour l’introspection du déroulement d’une fédération et les aspects « démonstration et commerce », il faut se souvenir qu’ils sont « branchés » sur les RTIs. Ils ne permettent de visualiser que les informations échangées via la RTI (conformément à la FOM). Ils ne dispensent donc pas d’utiliser les moyens de visualisation et d’enregistrement locaux aux fédérés à moins de prévoir de publier des informations uniquement à des fins d’utilisation par ces outils, bien entendu. De manière générale, soit on considère l’outil comme un fédéré et alors celui-ci peut participer à n’importe quelle fédération au prix d’un certain nombre d’adaptations, soit on utilise d’autres outils qui dépendent de la RTI. Dans le dernier cas, bien entendu, on s’impose une dépendance forte avec la RTI.


Figure 6 Utilisation de passerelles et ponts divers (d’après Pascal CANTOT, DGA)

Une dernière classe d’outils utiles est celle qui permet d’interfacer des fédérés relevant de normes différentes (DIS ou version HLA antérieure). Ils sont appelés « ponts » (bridges) ou « passerelle » ou « passage » (gateway). La Figure 6 ci-dessus décrit ces outils.

4.3 Les outils complémentaires dont on peut se passer

On en trouvera la liste dans les études du NIAG et les 3 autres études précitées. Certains ne sont même pas définis clairement : par exemple, les outils de création et de gestion des scénarios, les outils « d’analyse conceptuelle », etc.

A la différence des outils précédents qui relèvent de vœux pieux, d’autres outils (non cités dans ces études) pourraient être utiles. Certains existent tel que les « Outils de gestion de configuration des fédérations » qui sont d’ailleurs fournis gratuitement avec les RTIs commerciales.

4.4 Conclusion

L’utilisation de la norme d’interopérabilité nécessite l’utilisation d’outils pour sa mise en œuvre dont certains sont aussi indispensables que l’utilisation d’un processus de développement adapté (dérivé ou inspiré du HLA FEDEP puis du HLA DSEEP). Le coût des fédérations HLA en est clairement augmenté et doit être évalué par rapport aux services rendus par la mise en œuvre de ce paradigme et la réutilisation des moyens de simulation qu’il permet d’obtenir. Il est vraisemblable que de nouveaux outils commerciaux ou libres vont apparaître à l’avenir. Tous ne seront pas spécifiques de la HLA : on peut penser, par exemple, au développement de modèles conceptuels et au soutien des processus de VV&A. Dans tous les cas, la HLA ne peut que tirer profit des méthodes et des outils développés, de façon générale, dans le monde de la simulation et de l’ingénierie du logiciel dans son ensemble.


La certification de conformite a hla des fédérés

La mise en place de la norme HLA a été accompagnée de celle de moyens de vérification et de certification des composants d’une fédération : les fédérés et la RTI. Concernant la vérification de conformité des RTIs (dont le nombre n’est pas très grand) elle est de la responsabilité d’un organisme unique, l’US DoD M&S CO, qui est l’organisme pilote de la HLA81. En revanche, la certification des fédérés est un service disponible dans différents pays. On notera que la certification individuelle des fédérés et de la RTI est une condition nécessaire mais pas suffisante de conformité de la fédération à la norme HLA. Elle est toutefois largement acceptée comme une contribution importante à cette conformité.

Ce chapitre aborde les grandes lignes du processus de certification de fédérés HLA. La description détaillée des exigences et contraintes liées à la certification d'un fédéré est fournie dans un guide de certification disponible sur le site http://certificationhla-france.capgemini.fr/principesdebase.html [B12]. Des statistiques liées à la certification de fédérés HLA sont également disponibles à partir de ce site ([B35]82 pour la période allant de 2006 à 2007 et [B34] pour la période allant de 2008 à 2010).

4.5 Principes de la certification des fédérés

La certification HLA est réalisée sous l’autorité d’un organisme d’état (par exemple, l’US DoD M&S CO pour les Etats-Unis ou la DGA pour la France) et a pour objectif la délivrance d’un certificat de conformité à l’une des normes HLA (US DoD 1.3 ou IEEE 151683). A ce jour, chaque capacité de certification est nationale, mais, sur le plan technique, son activité est pilotée par le NMSG84 de l’OTAN en ce qui concerne la mise en place et l’évolution de ce processus et des logiciels qui le soutiennent. En outre, l’activité de certification est identique dans tous les pays puisqu’elle repose sur un processus unique et les mêmes outils.

Le principe de la certification repose sur le suivi d’un processus existant (défini par les Etats-Unis), avec franchissement d’étapes successives. Ce processus met en jeu 3 personnes : le client, l’administrateur du site de certification (WA) et l’agent de certification (CA).

Afin de conduire le déroulement du processus de certification, 2 outils ont été développés par les Etats-Unis :

• une application Internet dédiée à la certification (FTMS85) qui présente l’activité de certification HLA et déroule le processus de certification,

• un outil de test dynamique du fédéré HLA (FCTT86), qui permet de procéder à la vérification concernant l’appel des services de la RTI et la gestion des données (production et consommation) par le fédéré candidat à la certification.

Ces outils peuvent être utilisés par les différents pays de l’OTAN et les pays partenaires qui souhaitent mettre en œuvre une capacité de certification HLA.

Le FTMS est une application hébergée sur un serveur Web et accessible par n’importe quel poste client ayant accès à Internet. Le démarrage du processus de certification commence par l’enregistrement du client sur le site, et se poursuit par des échanges d’informations entre le client et l’agent de certification (CA) pour assurer un ensemble de contrôles. Une validation est réalisée à la fin de chaque étape du processus de certification.

Le FCTT est une application utilisée pour des contrôles syntaxiques et dynamiques lors des étapes du processus de certification. Il s’agit d’un fédéré HLA, mis en œuvre par l’agent de certification, qui participe à la fédération de test (mise à disposition par le client) pour collecter les informations sur le 81 http://www.msco.mil/RTIVerificationService.html. 82 Exclusivement pour les fédérés à la norme IEEE 1516-2000. 83 La norme IEEE 1516-2010 n’est pas encore disponible. 84 NATO M&S Group. 85 Federate Test Management System. 86 Federate Compliance Testing Tool.

http://certificationhla-france.capgemini.fr/principesdebase.html�


fédéré cible de la certification. Le FCTT est aujourd’hui opérationnel pour les RTI DMSO 1.3 NG v4 et v6, pRTI (PITCH) 1.3 v1.22, MÄK RTI 1.3 v2.4.2, PITCH (Pitch) 1516 v3 et Raytheon VTC and SAIC RTI NG Pro V4.0. A terme, il devrait accepter toute RTI certifiée.

4.6 Le processus de certification des fédérés

4.6.1 Remarques générales

Lors du test de l’interface, le FCTT est un fédéré HLA qui vient se connecter sur la fédération (mise à disposition par le candidat) pour collecter les informations sur le fédéré cible de la certification. La fédération utilisée par le client pour ce test peut-être soit la fédération nominale dans laquelle fonctionne le fédéré, soit une fédération de test mise en place spécifiquement pour la certification. L’important étant que cette fédération doit permettre de démontrer les capacités du fédéré à respecter ses engagements vis à vis de la norme HLA.

De manière nominale, ce test est réalisé à distance mais il peut être également effectué sur le site client en cas de contraintes spécifiques (réseau, confidentialité, etc.).

Les deux schémas ci-dessous présentent les deux types de certification :

R T I (R un Tim e Infrastructure)

Fédéré à certifier

Internet

Centre de certification

Fédération H LA

Site C lient

Séparation géographique

Fédéré FC TT

A utre(s) fédéré(s)

R éseau local

Pares-feux Pares-feux

Figure 7 Certification à distance

R TI (Run Time Infrastructure)

Fédéré à certifier

Fédération H LA

Site C lient

Fédéré FC T T

A utre(s) fédéré(s)

R éseau local

Figure 8 Certification en réseau local

4.6.2 Les étapes du processus de certification

Le processus général de certification est plus traditionnellement décrit comme l’enchaînement de 4 étapes principales, chacune d'elles ne pouvant être entamée que lorsque l’étape précédente a été complètement achevée avec succès. Ces 4 étapes sont représentées sur la figure suivante.


SOM

CS

Inscription Client

Validation

Inscription Fédéré

.rid **

Environnementtest

planningExécution

test(s)

Etape 1 Etape 2 Etape 3 Etape 4

Validation

FED/FDD*

* FED pour la norme 1.3, FDD pour la norme IEEE 1516

Validation

Validation

Certification

** pour la norme 1.3

Figure 9 Les 4 étapes du processus de certification

4.6.2.1 Etape 1 : enregistrement du client et de son application

Elle concerne l’enregistrement d’un nouveau client et consiste à saisir les informations relatives à la société ou l’organisme candidat, puis celles relatives au(x) fédéré(s) HLA à certifier.

L’administrateur du FTMS doit soit approuver, soit rejeter la candidature, après avis de l’autorité responsable.

4.6.2.2 Etape 2 : soumission des fichiers descriptifs de l'application

Le client doit ensuite télécharger les 3 fichiers (SOM, CS et FED87/FDD88) nécessaires à la définition et au fonctionnement du fédéré HLA.

• Le fichier SOM est le Simulation Object Model décrit conformément à l'OMT de HLA,

• Le CS est le Conformance Statement. Il s'agit d'un fichier ASCII reprenant la liste complète des services HLA avec indication de leur utilisation par le FUT89,

• Le fichier FED (norme US DoD 1.3) décrit une partie de la FOM. Ce fichier est nécessaire à la RTI et aux fédérés lors de l'exécution de la fédération. Le document FDD (norme IEEE 1516-2000 et IEEE 1516-2010) contient le FOM et des informations techniques sur les méthodes d’échange utilisées pour transporter les données HLA.

Une fois les documents SOM, CS et FED/FDD fournis par le client, l’agent de certification procède à leur analyse à l’aide de l’outil FCTT. Cette analyse comporte une suite de 4 tests :

• analyse syntaxique du fichier FED/FDD,

• analyse syntaxique des fichiers CS et SOM,

• vérification croisée (cohérence) des fichiers CS et SOM,

• vérification croisée (cohérence) des fichiers SOM et FED/FDD.

87 Federation Execution Data 88 FOM Document Data dans la norme IEEE 1516-2010. 89 Federate Under Test


4.6.2.3 Etape 3 : soumission des informations pour le test dynamique

Le client saisit sous le FTMS les informations descriptives de l’environnement de test dynamique (type d’API, description de la plateforme, fichier RID90 ….). Lorsque l’environnement de test est correct, l’agent de certification propose une date et une heure de test qu'il doit valider avec le candidat.

4.6.2.4 Etape 4 : réalisation du test dynamique et délivrance du certificat de conformité du fédéré

Le test dynamique implique la participation à la fois du client et de l’agent de certification. Cependant, c’est l’agent de certification qui dirige le test, puisqu’il est dépendant des contraintes de fonctionnement du FCTT. Ce test est exécuté par l’agent de certification à l’aide de l’outil FCTT sur la base des informations précédemment renseignées.

Une restitution des résultats a lieu entre l’agent de certification et le client, après terminaison du test dynamique. Si un nouveau test dynamique doit être réalisé, la présente étape est reprise au moment où il est nécessaire de fixer la date du test.

Lorsque le processus de certification est terminé avec succès, un certificat de conformité est délivré au client. Le processus de certification est terminé après remplissage d'un questionnaire (After Action Review) dans le cadre d'un entretien entre l'agent certificateur et le client.

Pour plus d’informations sur les tests dynamiques, le lecteur est invité à se référer au guide [B12].

90 Fichier de configuration utilisé par certaines RTIs.


5 AIDE A LA REDACTION DES CAHIERS DES CHARGES

Le but de ce chapitre est d’aider les rédacteurs de cahiers de charges à spécifier l’élaboration de systèmes de simulation ou de "fédérés" conformes à la norme d’interopérabilité HLA. Ce document ne fournit pas un texte type à insérer dans un cahier des charges (en mode « copier-coller ») : il est quasiment impossible de proposer cela compte tenu du fait que tout projet de simulation à des spécificités particulières. On ne trouve dans cette section que ce qui est spécifique à la HLA : les exigences en termes de documentation et de validation par exemple sont celles habituelles à l'élaboration de systèmes de simulation. Les indications qui suivent viennent s'y ajouter.

5.1 Références principales à insérer Tout cahier des charges doit s’appuyer sur ce guide HLA (référence N°1 à introduire) qui fournit une connaissance minimale sur la norme aux chefs de projet. Le besoin de conformité à la norme HLA doit être apprécié conformément à la Politique Technique Sectorielle de la DGA (référence N°2 à introduire) et à l’accord de standardisation OTAN sur la HLA (STANAG 4603, promulgué le 2 juillet 2008, référence N°3 à introduire), en particulier quand il s’agit d’un système de simulation susceptible d’être utilisé dans une fédération alliée. La référence N°4 à insérer est bien évidemment la norme HLA elle-même (3 documents, références [A5] à [A7] de ce guide ou bien [A1] à [A3] suivant les cas, voir section 5.3) accompagnés du document méthodologique correspondant (FEDEP ou DSEEP, références [A7] ou [A16] de ce guide).

5.2 Spécifications du besoin

On peut distinguer 4 cas (A, B, C et D) de besoins différents dans une demande d’élaboration d’un système de simulation sous HLA :

A. Développement d’une nouvelle fédération HLA (dans ce cas, il y aura certainement la nécessité d’intégrer des simulations existantes qui devront bien évidemment être décrites avec les documents de référence correspondants),

B. Développement d’un (de) nouveau(x) fédéré(s) HLA, pour s’intégrer à une fédération existante,

C. Développement d’un (de) nouveau(x) fédéré(s) HLA, sans cible d’intégration à une fédération précise (il s’agit donc d’exiger d’être conforme à la norme HLA à titre de précaution).

D. Mise en conformité HLA d'une simulation existante, pour intégration à une nouvelle ou ancienne fédération.

Tout cahier des charges doit comporter une section précisant le besoin relatif à HLA. Elaborer de nouveaux produits en appliquant la norme a un coût non négligeable et doit donc être soigneusement justifié.


5.3 Normes applicables

Conformément au STANAG 4603, la norme applicable est la norme HLA IEEE 1516 dans sa version la plus récente91 (voir références en section 5.1). Elle comprend un guide de pratique recommandée appelé FEDEP (dans la version 2000) et DSEEP (dans la version 2010 avec l’annexe HLA) qui est également applicable après adaptation au besoin spécifique.

La nouvelle norme IEEE 1516-2010 a été publiée en 2010 (HLA Evolved) : elle est applicable dès disponibilité des outils commerciaux correspondants92. En cas de doute sur le choix d’une norme, le texte du STANAG 4603 (publié en juillet 2008) est à observer. Pour les fédérations existantes (cas B) il préconise l’utilisation de la norme HLA la plus économiquement rentable (décision des chefs de projet). En règle générale, le fait de retenir la version la plus récente de la norme est sans incident notable, des passerelles existant pour les fédérés préexistants conformes aux versions antérieures de la norme. Par contre, il n'existe pas de passerelles des nouvelles normes vers les anciennes.

5.4 Exigences et/ou informations à préciser

5.4.1 Exigences communes

Dans tous les cas (A, B, C ou D), on précisera les points suivants :

Les exigences de sécurité liées à la distribution,

Les contraintes temps réel, s’il en existe,

Quelques éléments de performances, si nécessaire, comme les fréquences de mise à jour des attributs,

La nécessité de faire certifier le (ou les) fédéré(s) développé(s) ou modifié(s) pour le projet,

Les exigences techniques spécifiques quand elles sont connues, par exemple :

o Les services (ou groupe de services) HLA à utiliser (ex : gestion du temps, DDM, sauvegarde et reprise ...), en spécifiant éventuellement l'utilisation des services (ex : diagramme de séquences UML),

o Si nécessaire quelques conseils de mise en œuvre (ex : les mises à jour des attributs en mode tiré devront être utilisées avec parcimonie),

o Les mécanismes de gestion des exceptions HLA,

o La gestion des fichiers de configuration de la fédération.

91 La norme IEEE 1516-2010 à la date de la mise à jour de ce guide. 92 Certaines RTIs commerciales implémentent déjà les nouvelles fonctionnalités de cette version.


5.4.2 Exigences particulières

Cas A (développement d'une nouvelle fédération) :

La justification du choix de la RTI, du FOM de référence utilisée, du choix des APIs utilisées,

Le besoin d'agilité FOM, c'est-à-dire la capacité à changer de FOM (à titre conservatoire),

Cas B (développement de nouveaux fédérés pour une fédération existante) :

L’architecture préexistante dans le cas d'élaboration de fédéré(s) à intégrer dans une fédération existante,

La RTI et le FOM (ou FOM de référence) à utiliser,

La justification du choix de l’API utilisée,

La capacité du fédéré à s'exécuter au sein d’une fédération et/ou en "standalone".

Cas C (développement de nouveaux fédérés sans besoin d'intégration) :

La justification du choix de la RTI et de l'API (si elles ne sont pas imposées),

le FOM de référence à utiliser,

Le besoin d'agilité FOM, c'est-à-dire la capacité de changer de FOM pour s'intégrer à de nouvelles fédérations,

La capacité du fédéré à s'exécuter au sein d’une fédération et/ou en "standalone".

Cas D (Mise en conformité HLA d'une simulation existante)

L’architecture préexistante dans le cas d'élaboration de fédéré(s) à intégrer dans une fédération existante,

Si nécessaire, les justifications des choix de RTI, de FOM ou de FOM de référence utilisé, du choix de l'API utilisée,

Le besoin d'agilité FOM, c'est-à-dire la capacité de changer de FOM (à titre conservatoire).

5.5 Outils de soutien

Le guide HLA liste les outils nécessaires au développement et à l’exploitation des fédérations HLA (voir chapitre 4).

Le choix le plus important est celui d’une RTI HLA. Il est recommandé d’utiliser une RTI certifiée par le Département de la Défense américain.


Le plus souvent on fera le choix de RTIs du commerce, mais le recours à des produits libres est possible et offre des opportunités d'économie substantielles. Le choix d'une RTI libre doit être fait sur deux critères :

La version de la norme supportée (malheureusement, beaucoup de RTIs "open source" ne supportent que la norme US DoD 1.3 de la HLA).

La possibilité de soutien du produit par une organisation tierce, si le futur titulaire n'est pas capable de maintenir (et quelquefois même de faire évoluer) le produit par lui même.

Dans le cas d’intégration d'un fédéré à une fédération existante, l’état de l’art actuel (manque d'interopérabilité des différentes RTIs) ne laisse guère de liberté pour le choix de la RTI à acquérir et le chef de projet devra préciser quelle RTI il conviendra d’utiliser.

Le nombre de licences à acquérir devra être précisé (en général une par fédéré, simulation/simulateur ou outil de soutien). Il n'est pas inutile de prévoir une ou quelques licences supplémentaires pour faire face aux imprévus (le prix des licences commerciales est plus intéressant en cas d'achat groupé). Concernant les outils de soutien, on se référera au chapitre 4. On notera que l'offre d'outils commerciaux est abondante : il est important de ne pas aller au-delà du raisonnable. Mais, il est clair que les fédérations avec un grand nombre de fédérés et sur des réseaux distants demanderont l'utilisation d'outillages plus importants qu’une fédération limitée à 2 ou 3 fédérés s’exécutant sur la même machine.

5.6 Certification de conformité à la norme Tous les fédérés fournis doivent être certifiés conformes à la norme HLA, le coût de ce travail pouvant être évalué à environ 5 jours*hommes par fédéré.

5.7 Fournitures

D'une manière générale, la documentation sera définie par référence à celle suggérée dans le FEDEP ou le DSEEP avec annexe HLA.

Dans tous les cas, on demandera les rapports de certification HLA et les SOM des fédérés développés ou modifiés.

Pour les versions antérieures à la norme IEEE 1516-2010, les listes des services utilisés/fournis par les fédérés et/ou la fédération doivent être fournies (sous la forme de "Conformance Statements", voir chapitre 0)93.

Le cas échéant, le FDD de la fédération devra être fourni ainsi que les fichiers de configuration éventuels. D'une manière générale toutes les licences des logiciels utilisés doivent être fournies au client.

93 Dans la version IEEE 1516-2010, le Conformance Statement est intégré dans le SOM.


6 LES PERSPECTIVES AUTOUR DE HLA Aujourd'hui, on peut penser qu'à court terme, les perspectives autour de l'architecture HLA dépendent essentiellement de la réponse à la question posée par sa pérennité. Suite à l'adoption de HLA comme norme IEEE, on observe un intérêt persistant de la part de la communauté de la simulation, notamment dans le domaine civil, ce qui constitue un élément encourageant. Néanmoins, malgré tous les efforts de l’US DoD pour véritablement imposer la norme de manière pérenne, le succès de l’adoption de HLA est conditionné par les réponses apportées à trois problèmes majeurs liés à :

• l'outillage,

• la sécurité,

• et enfin, les performances. Des prédictions à plus long terme constituent un exercice plus périlleux, surtout après l'expérience DIS. Cette perception est confirmée par le fait que plusieurs initiatives d'ampleur ont vu le jour récemment dans des périmètres proches de ceux couverts par HLA. Dans ce chapitre, nous proposons de présenter très brièvement les principales initiatives qui pourraient avoir des répercussions sur le devenir de HLA à moyen et long terme. En 2006, l’US DoD a revu complètement son organisation en matière de simulation. Le DMSO, en charge du soutien de la HLA, a été remplacé par une nouvelle organisation qui conserve la responsabilité des activités de normalisation. En parallèle, l’US DoD a lancé une initiative de grande ampleur sur les architectures d’interopérabilité (voir paragraphe 6.5). Même s'il reste quelques interrogations sur les résultats de cette initiative, elle ne devrait certainement pas déboucher sur une nouvelle norme avant la fin de la validité de la norme HLA IEEE 1516-2010 (pas avant 2015 - 2016).

6.1 L'architecture TENA (Test & Training Enabling Architecture)

6.1.1 Contexte et objectif

TENA est un projet de l’US Army dont l’objectif est de développer une architecture de simulation destinée à l’origine à ses centres d’essai, puis plus tard étendue aux besoins de l’entraînement. Le développement de TENA, qui constitue un volet du projet Foundation Initiative 2010 (FI 2010) est financé par le CTEIP (Central Test & Evaluation Investment Program), piloté par l’US JFCOM et implique le JNTC (Joint National Training Capability), un ensemble de sites d’entraînement interopérables. Depuis 2003, date de la première présentation du projet à l’EuroSIW de Stockholm, TENA fait l’objet de nombreux papiers et tutoriaux en particulier dans le cadre des ateliers semestriels de la SISO [A8], [B36]. A l’heure actuelle, TENA participe également à la feuille de route des architectures LVC aux côtés de HLA et DIS (se référer au paragraphe 6.5). Par contre, les responsables du projet ont jusqu’à présent refusé d’ouvrir les spécifications TENA à un processus de normalisation.

Les objectifs du projet sont toujours de faciliter l’interopérabilité et la réutilisation, mais également la composition des simulations en insistant davantage sur les aspects partage et archivage des modèles objets et des applications. Plus précisément, il s’agit de définir une architecture fonctionnelle commune permettant de :

Résoudre certains problèmes liés aux normes HLA et DIS en utilisant en particulier des RMI (Remote Method Invocation),

Définir des modèles objets standards communs à la communauté des utilisateurs. Ces modèles objets sont appelés LROM (Logical Range Object Model),

Concevoir et développer un intergiciel et un outillage complémentaire, en particulier des outils de génération de code, qui utilisent ces modèles objets,


Archiver et partager les modèles objet et les applications.

D’un point de vue plus « opérationnel », l’objectif de TENA est d’identifier et d’offrir des outils permettant de préparer, configurer et conduire des exercices d’entraînement et/ou d’essais dans un environnement synthétique distribué incluant des équipements réels.

TENA est une architecture ouverte au sens du SEI (Software Engeenering Institute) : “ A collection of interacting software, hardware, and human components designed to satisfy stated needs with interface specifications of its components that are fully defined, available to the public, maintained according to group consensus, in which the implementations of the components conform to the interface specifications.”.

L’architecture évolue par consensus des utilisateurs au sein d’une équipe de gestion appelée AMT94 (Architecture Management Team) qui se réunit tous les 3 mois. Pratiquement, les produits TENA sont publics et disponibles sur le Web (https://www.tena-sda.org/display/intro/Home). Ils comprennent :

Les spécifications de l’architecture,

Les spécifications de l’API pour l’utilisation de l’intergiciel95,

Les modèles objets disponibles et modifiables par les concepteurs d’un nouvel « événement » selon leurs exigences propres.

6.1.2 Architecture et applications TENA

L’architecture de TENA est décrite par la Figure 10.

Dans la terminologie TENA, un « Logical Range » désigne un ensemble de ressources qui se partagent un modèle objet commun, appelé LROM et partagé par les applications d’un même Logical Range. Chaque Logical Range comprend un service de nommage, un gestionnaire d’exécution et des applications.

L’architecture TENA est de type « peer-to-peer » dans lequel les applications peuvent être à la fois des clients et des serveurs. En tant que serveurs, les applications publient des objets TENA appelés « Servants » et en tant que clients, les applications obtiennent des « Proxies » représentant des servants d’autres applications.

94 Se référer à [B36] pour la liste de tous les participants. 95 Version 6.0.1 depuis juin 2010.


Figure 10 Architecture TENA (Illustration issue de [B36])

Figure 11 Applications TENA (Illustration issue de [B36])

L’intergiciel, les objets TENA et le code des applications utilisateurs sont compilés et édités ensemble (voir Figure 11). Le processus de développement d’applications TENA est synthétisé sur la Figure 12.


Figure 12 Processus de création d’applications TENA (Illustration issue de [B32])

Une application TENA est composée de codes issus de 3 sources différentes : le code TENA de l’intergiciel, le code des modèles objet (Servants et Proxies) et le code de l’application elle-même.

6.1.3 Principes fondamentaux de TENA : modèles et applications

Un méta modèle définit un langage abstrait permettant d’exprimer d’autres modèles. Le méta modèle TENA décrit les caractéristiques des objets définis dans un LROM. Le méta modèle TENA est représenté par un formalisme de type UML. Il est fondé sur la combinaison de 2 concepts : la notion d’objets distribués chère à CORBA et les notions de publication/abonnement suivies par l’architecture HLA. Dans le vocabulaire TENA, cette combinaison porte le nom de SDO (Stateful Distributed Object).

Le méta-modèle TENA définit les règles que doivent suivre les modèles de données (TENA Object Model) réalisés lors du développement d’applications TENA. Il spécifie les règles d’un modèle objet utilisé par le Logical Range et les capacités supportées par le middleware TENA. Un modèle objet TENA définit les objets utilisés pour une exécution donnée et correspondant aux besoins des applications. Le langage pour définir ces modèles de données TENA est TDL (TENA Definition Language). Il existe un ensemble de modèles standard identifiés par la figure 7.2.4.


Figure 13 Modèles objets standard (Illustration issue de [B36])

Le méta modèle TENA (Release 5.2.2) est représenté sur la Figure 14.

Figure 14 Méta modèle TENA Release 5.2.2 (Illustration issue de [B32])

Ce méta modèle inclut la notion de classes locales (Local Classes) qui peuvent migrer dans leur totalité (identité, état et comportement) d’un serveur vers un client. Un message désigne une classe locale qui peut être envoyée par une application qui la publie vers une application qui s’y est abonné.

Les applications communiquent entre elles soit par invocation de méthodes distantes (RMI), soit par mise à jour d’attributs soit par invocation de méthodes locales.


Figure 15 Invocation de méthodes distantes (Illustration issue de [B32])

Figure 16 Mise à jour d’attributs (Illustration issue de [B32])

Figure 17 Invocation de méthodes locales (Illustration issue de [B32])

Un résumé du processus de création d’une application TENA est illustré sur la Figure 18.


Figure 18 Processus de création d’une application TENA (Illustration issue de [B32])

6.1.4 Le TENA repository et les outils

Le repository conserve toutes les informations de TENA qui ne sont pas spécifiques d’un Logical Range donné (méta modèle de son contenu, modèles objets, logiciels, intergiciel, documentation et comptes rendus d’exécutions de Logical Ranges). Il est accessible par un explorateur grâce à l’IDE TIDE96

Il existe un certain nombre d’outils autour de TENA, gratuits si l’inscription sur le site est acceptée :

• Le plugin MagicDraw qui permet de générer du code TDL à partir de diagrammes de classes TENA,

• TIDE97 permettant d’abord d’assister les concepteurs dans le développement, les tests et le déploiement d’applications TENA, ensuite d’explorer le repository, enfin de télécharger l’intergiciel,

• Le Gateway Builder permettant de construire des applications gateway,

• Un plugin pour SIMDIS98 permettant la visualisation 3D d’instances de la classe TENAPlatform,

• Application Management Object (AMO) Monitor,

• Execution Manager GUI (EMgui)

• Interface Verification Tool (IVT) / LROM Tool

• TENA Network Analysis Tool (T-NAT)

96 TENA Integrated Development Environment. 97 Version 2.0.3 depuis juin 2010. 98 Ensemble d’outils d’analyse et de visualisation de l’US Navy disponibles gratuitement sur demande.


6.1.5 TENA et les normes DIS et HLA

Un tableau récapitulatif et comparatif entre TENA, DIS et HLA est donné sur la Figure 19.

Figure 19 Comparaison TENA – DIS - HLA (Illustration issue de [B32])

Une autre différence entre TENA et HLA réside dans la notion de processus. Dans HLA, le référentiel est donné par le FEDEP ou DSEEP qui établissent des recommandations sur le processus de développement et d’exécution de fédérations. Au contraire, le processus TENA s’attache à la notion d’événement (exercice) et comporte 5 étapes conformément à la Figure 20.

Figure 20 Le processus selon TENA (Illustration issue de [B32])


6.1.6 Les plateformes supportées par l’intergiciel TENA version 6.0.1

La liste des plateformes supportées par TENA est fournie par la Figure 21

Figure 21 Plateformes supportées par l’intergiciel TENA (Illustration issue de [B36])

6.1.7 Exemples d’utilisation de l’architecture TENA

Des exemples d’utilisation de l’architecture TENA sont fournis par la Figure 22.

Figure 22 Exemples d’utilisation de TENA (Illustration issue de [B36])


Des exemples d’utilisation de l’architecture TENA par l’US DoD dans le cadre de campagnes d’essais, entraînement et expérimentations, sont listés dans la Figure 23.

Figure 23 Exemples d’utilisation de TENA par l’US DoD (Illustration issue de [B36])

Pour des informations complémentaires concernant l’utilisation de TENA, le lecteur est invité à se référer à la présentation [B36].

6.1.8 Conclusion TENA a souvent été présenté comme supérieur à HLA et son remplaçant potentiel. En fait, les 2 approches montrent des différences importantes sur le plan technique, sans vouloir occulter des aspects politiques et organisationnels importants (internes au DoD).

• TENA est un produit plus ou moins disponible librement sur la scène internationale ; HLA est une norme internationale payante mais disponible pour tous. HLA est soutenu par des produits commerciaux qui ne font pas partie de la norme mais doivent s’y conformer. Il ne semble pas que les promoteurs de TENA aient l’envie, ni les moyens de l’ouvrir à une normalisation. En revanche, les tenants de TENA font de gros efforts de promotion, y compris hors des US, clamant la supériorité de TENA sur les initiatives concurrentes et plus anciennes (DIS et HLA).

• Il est vrai que TENA va plus loin que HLA en proposant une implémentation et une approche orientée objet pour la conception et le développement de modèles : mais il ne semble pas que les outils disponibles s’appuient sur une approche industrielle structurée. HLA a toujours été concentrée sur les concepts d’interopérabilité et de réutilisation des simulations, et non sur la conception et le développement des modèles. La politique sur HLA consiste à confier au marché le soin de développer des outils de soutien à cette architecture. C’est un choix de politique technique et les opinions sur ce point peuvent varier.


• Concernant les applications, HLA est plus ambitieux puisqu’elle est sensée s’appliquer à tous les types de simulation (constructive, virtuelle et vivante), temps réel et non temps réel. TENA clame sa versatilité mais ne fournit pas encore de mécanisme de gestion du temps ce qui limite fortement son champ d’application. La gestion du temps reste une spécificité et un point fort de HLA.

• La pérennité de HLA est liée au marché de la simulation : à l’adhérence des utilisateurs (civils et militaires) à ses concepts et à la confiance des vendeurs sur l’avenir de ce marché. Actuellement la pérennité de TENA est liée à la volonté du DoD (et surtout de l’US Army) à financer son développement et son soutien.

6.2 Les HLA BOMs (Base Object Models) L'idée des BOMs99 qui remonte à 1998, est née de la difficulté de concevoir des FOMs et de la difficulté à réutiliser des composants de FOMs. C’est également une tentative d’extension des concepts HLA (inter-fédérés) à un niveau inférieur de composition (à l’intérieur des fédérés). Depuis quelques années, un PDG (Product Development Group) de la SISO était chargé de produire une version de norme associée. Cette norme SISO100, approuvée au printemps 2006, comprend 2 documents, un guide pour l’utilisation et l’implémentation des BOMs, et un document de spécifications [A9], [A10]. Depuis septembre 2006, le PDG101 s’est transformé en PSG102 dont la mission est de promouvoir cette norme, assister les utilisateurs, capitaliser les retours d’expérience et gérer les améliorations proposées par la communauté ([B37]. Depuis 2010, un nouveau schéma expérimental est disponible. Il pourrait servir de base à une révision de la norme. Un BOM est défini comme "un paquetage réutilisable d'informations représentant un modèle d'interactions entre entités au sein d'une simulation". Un BOM permet d'être réutilisé comme composant de base dans la conception d'une simulation ou d'une fédération de simulations. De manière plus abstraite, un BOM capture un élément du modèle conceptuel. Il s’agit donc d’un concept de base pour la composition de simulations. Le concept de BOM doit permettre de faciliter :

• l'interopérabilité, par une meilleure compréhension de la sémantique des données échangées grâce à l'adoption de XML,

• la réutilisation, grâce aux méta-données associées aux BOMs,

• la composition de simulations aussi bien de manière statique que dynamique,

• l'agrégation et la multi-résolution.

•

La Figure 24 (copyright SISO) représente le domaine de la simulation en couches, afin de capturer l'impact des BOMs sur la communauté de la simulation HLA. La « vue communication », qui inclut la RTI, est chargée de la communication des données échangées par les fédérés au cours de l'exécution d'une fédération. La couche supérieure, la « vue fédération », représentée par un FOM HLA, identifie les données échangées entre les composants de la fédération au travers de la couche communication. C’est à ce niveau que les BOMs peuvent être assemblées pour concevoir un FOM. Enfin, la vue supérieure constitue la « vue fédéré ». Elle révèle les capacités dont chaque fédéré dispose pour répondre aux exigences de la fédération. La « vue fédéré » est découpée en « vue conceptuelle/interface » et « vue implémentation ». Au niveau de la vue conceptuelle/interface, les BOMs peuvent être utilisés pour modéliser une entité conceptuelle au sein d’un fédéré. Chaque entité conceptuelle peut être associée à une ou plusieurs classes d’objets ou d’interactions, ainsi qu’aux attributs et paramètres correspondants. La vue implémentation 99 Site officiel : http://www.boms.info/. 100 Et non IEEE. 101 Product Development Group. 102 Product Support Group.


concerne le code exécutable du fédéré. A droite de la figure, une librairie de réutilisation peut être utilisée pour identifier et sélectionner les modèles objets pertinents, y compris les BOMs, selon les besoins d’une fédération donnée.

Figure 24 Architecture BOM (copyright SISO)

Ce qu'il faut retenir des BOMs, c’est qu'il s'agit d'un ensemble de tables conformes à la sémantique et la syntaxe de l'OMT de HLA décrivant des méta-données de composants de fédérations ou de fédérés. De manière très simplifiée, alors que les fédérés sont des composants (simulations) d'une fédération, les BOMs permettent de composer des comportements ou des "jeux" d'interactions entre entités, afin de construire des "jeux" d'interactions de plus en plus complexes. En d’autres termes, un BOM est constitué d’un ensemble d’éléments constitués de méta données, d’informations sur le modèle conceptuel, ainsi que de la correspondance entre le modèle conceptuel et l’interface. La Figure 25 (copyright SISO) illustre la « trame » d’un BOM, constituée à l’heure actuelle de 4 composants : l’identification du modèle, le modèle conceptuel, la description de la correspondance et le modèle objet HLA.


Figure 25 Composants d’un BOM (copyright SISO)

L’ensemble des tables composant un BOM est listé sur la Figure 26 (copyright SISO). Le format normalisé des tables communes avec HLA respecte le format normalisé OMT (future version IEEE 1516). C’est le cas par exemple, de la table des classes d’objets ou d’interactions, ainsi que des tables des attributs et des paramètres. C’est la raison pour laquelle ces tables ne seront pas décrites dans la suite du document. Dans la suite, on insistera sur les tables spécifiques aux BOMs.


Figure 26 Liste des tables composant un BOM (copyright SISO)

L’objet de ce document n’est pas de décrire les détails de chacune des descriptions. Pour cela, le lecteur intéressé est invité à consulter le document de référence [A10]. Nous allons brièvement décrire les tables constituant le cœur des BOMs. Par contre, les tables des notes ou du lexique du modèle objet ne sont pas évoquées. La table de description des modèles (Pattern Description Table) décrit les interactions entre 2 entités. Ces interactions sont capturées sous forme d’actions incluant les notions de variation et d’exception. Une exception est une action imprévue qui conduit à abandonner la suite des actions du modèle. Une variation décrit une manière de décliner une action sous différentes formes. La Figure 27 (copyright SISO) donne un exemple de table de description de modèles, représentant le paiement d’une note de restaurant.


Figure 27 Exemple de table de description de modèle (copyright SISO)

A titre d’illustration, une variation de l’action de payer la note (CustomerPays), est de payer soit en liquide (BillPayed_Cash), soit par carte de crédit (BillPayed_Credit). Il faut remarquer que tout modèle peut référencer un autre modèle. Par exemple, l’action de payer en liquide référence le BOM « CashPaymentBOM ». La table de description de la machine à états, décrit le comportement d’une entité conceptuelle sous forme d’états. Un exemple est illustré par la Figure 28 (copyright SISO). Il s’agit de la machine à états associée aux employés d’un restaurant. Dans cette description, 6 états sont identifiés en référence aux 3 modèles d’interaction : entrée dans le restaurant, paiement de la note et commande du menu. Les transitions d’un état vers un autre sont capturées par les conditions de sortie (exit conditions). Chaque condition est reliée à une action déclenchée soit par un événement, soit par un BOM spécifique.


Figure 28 Exemple de table de description d’une machine à états (copyright SISO)

La table des types des entités décrit les types des entités engagées dans un modèle d’interaction. Un exemple est donné par la Figure 29 (copyright SISO).

Figure 29 Exemple de table des types des entités (copyright SISO)

Le type des événements identifie la nature des événements qui au niveau conceptuel, déclenchent les actions, variations ou exceptions. Il existe 2 types d’événements, les déclencheurs BOM et les


messages BOM. Un déclencheur identifie la notion de réaction d’une entité à un changement d’état. Un déclencheur est identifié par la source, la condition de déclenchement, mais pas l’entité cible. Un message, au contraire, est un événement entre 2 entités du modèle conceptuel. La Figure 30 (copyright SISO) donne un exemple de table des types d’événements incluant à la fois des déclencheurs et des messages.

Figure 30 Exemple de table des types d’événements (copyright SISO)

Dans cette table, lorsque l’entité cible est identifiée, il s’agit d’un message (exemple « CheckRequest »), et lorsque la cible est remplacée par une condition de déclenchement, il s’agit d’un événement de type déclencheur (exemple « NonPayingCustomer »). La table de correspondance des types d’entités établit la correspondance entre les types d’entités du modèle conceptuel et la description dans l’espace des objets HLA. La Figure 31 (copyright SISO) donne un exemple de cette table.

Figure 31 Exemple de table de correspondance des types d’entités (copyright SISO)

Enfin, la table de correspondance des types d’événements, établit la correspondance entre les types d’événements du modèle conceptuel et la description dans l’espace des objets HLA. La Figure 32 (copyright SISO) illustre cette table par un exemple.


Figure 32 Exemple de table de correspondance des types d’événements

6.3 BOMs et Modules FOM Il est nécessaire d’apporter quelques éléments de clarification concernant les relations entre les notions de BOM et de modules FOM. Comme nous l’avons vu précédemment, un BOM est défini comme "un paquetage réutilisable d'informations représentant un modèle d'interactions entre entités au sein d'une simulation". Un module FOM quant à lui, fournit une description normalisée des données partagées entre les fédérés au sein d’une fédération. Ainsi, même s’il y a des recoupements (ou des complémentarités) entre les 2 notions, un BOM est un outil davantage orienté vers la conception et la réutilisation de connaissances conceptuelles dans des domaines métiers particuliers, et ceci, indépendamment d’une quelconque allocation fonctionnelle des compétences métier à des fédérés HLA. Au contraire, un module FOM décrit les données partagées par les fédérés au sein d’une fédération donnée. En ce sens, la réutilisation des modules FOM se situe à un niveau plus en aval du processus de conception de fédérations. Les BOM’s adressent donc en priorité l’étape 2 (développement d’un modèle conceptuel) du DSEEP, alors que les modules FOM adressent en priorité l’étape 4 (Conception d’une simulation) du DSEEP. Cependant, il est important de souligner que les BOMs constituent un élément d’assemblage des modules FOM en fournissant des modèles élémentaires d’interactions entre les entités. En ce sens, les BOMs ont vocation à faciliter la conception de modules FOM par réutilisation et assemblage de modèles conceptuels. En ce sens, les 2 notions convergent et deviennent complémentaires à l’étape 3 (Conception d’une simulation) du DSEEP.

6.4 SOA103 Une architecture « orientée services » est capable d’offrir un ensemble de services souvent orientés vers un domaine d’expertise particulier. Les premières architectures orientées services furent fondées sur CORBA ou DCOM. A l’heure actuelle, les architectures SOA sont fondées sur les Web services et les technologies XML/SOAP. Une telle architecture est composée d’un serveur offrant des services sur requête de clients conformément à un schéma de type navigateur Web. L’intégration de HLA et de SOA répond à un besoin d’amélioration de l’interopérabilité des simulations selon une approche « système de systèmes ». Pour parvenir à cette association, plusieurs approches sont possibles [B17] :

• Conception d’un ensemble de services Web « à l’image » des services offerts par la norme HLA.

103 Service Oriented Architecture.


• Conception de passerelles permettant de faire inter opérer des systèmes orientés services natifs avec des fédérés HLA.

• Concevoir une architecture unifiée selon une unique vision conceptuelle des mondes HLA et SOA [B17].

Plus généralement, et au-delà de la HLA, on assiste actuellement à un effort de convergence entre les normes de simulation distribuée (DIS, HLA) ou architectures (TENA) avec les architectures de type SOA, dans le cadre de la Grille Globale d’Information (GIG104) [B18].

6.5 LVC AR (Live Virtual Constructive Architecture Roadmap) Il s’agit d’une étude pilotée par le Joint Forces Command (JFCOM) des USA et lancée au printemps 2007. L’étude a été achevée fin 2008 [B38]. Cette étude s’effectua en parallèle avec l’étude LVC menée par un SG105 de la SISO dont l’objectif est d’explorer les besoin en termes d’interopérabilité entre les simulations L, V et C.

6.5.1 Bref historique Les objectifs de LVC AR étaient d’évaluer les besoins en architecture de simulation supportant les 3 grands types de simulation (L, V et C) et de proposer des solutions techniques dont la faisabilité était à évaluer. Partant du constat que, en dépit d’une politique très dirigiste de l’US DoD de 1995 à 2002 souhaitant imposer HLA comme l’architecture unique, trois normes ou produits principaux se partagent le marché US de la simulation distribuée : DIS, HLA et TENA. Il était donc clair qu’aucun des trois ne satisfait toutes les classes d’utilisateurs. Il fallait donc réfléchir à de nouveaux concepts pour voir si on pouvait définir : une nouvelle architecture unique cumulant les avantages (et pas les défauts) des précédentes (ce

qui paraissait difficile), des architectures adaptées à divers types d’utilisation de la simulation106 (mais avec quelques

craintes de perte d’interopérabilité). A la différence des efforts initiaux sur HLA et TENA qui étaient réservés à une population limitée et uniquement américaine, l’étude LVC AR a été ouverte aux alliés (industrie comprise) : elle bénéficie d’une première ouverture via la SISO (création d’un groupe de travail en décembre

2006, première réunion en Mars 2007), elle a une liaison avec l’OTAN par un groupe de travail NMSG107 appelé MSG-052 qui est chargé

de collecter des retours d'expérience auprès des nations de l’OTAN et des nations partenaires. La Figure 33 présente les statistiques d’utilisation des principales architectures (CTIA signifie Common Training Instrumentation Architecture).

104 Global Information Grid. 105 Study Group. 106 Depuis sa réorganisation fin 2006, la communauté US M&S reconnaît six utilisations principales de la simulation : « Analysis, Planning, Training, Acquisition, Testing, Experimentation ». 107 NATO M&S Group, Groupe OTAN pour la Modélisation et la Simulation.


Figure 33 Statistiques d'utilisation des principales Architectures/ Protocoles (étude LVC AR, août 2008)

En France, le suivi de cette étude fut assuré par le groupe ADIS qui créa un groupe de travail sur ce sujet : de nombreux membres du groupe ADIS industriels et étatiques furent acceptés comme membres du groupe technique US LVC AR. La DGA assura en outre la représentation française au groupe OTAN MSG-052 et l’industrie fut invitée à participer aux ateliers organisés par ce groupe.

6.5.2 Conclusions et recommandations

La première conclusion de l’étude fut la production d’une feuille de route représentée sur la Figure 34.

Figure 34 Feuille de route (issue de [B38])


La Figure 35 présente une vue schématique de la capacité actuelle et souhaitable (en vert) de 4 dimensions de la M&S (intégration, applications de normes …) à couvrir les besoins des simulations L, V et C.

Figure 35 Couverture des besoins des simulations L, V et C (issue de [B38])

La Figure 36 présente un tableau de recommandations concernant les investissements et efforts à consacrer pour répondre aux besoins de ces simulations.


Figure 36 Investissements recommandés (issue de [B38])

D’autres conclusions de cet effort sont les suivantes:

il ne faut pas développer de nouvelle architecture générale et unique qui n'aurait aucune chance de satisfaire l'ensemble des utilisateurs potentiels,

des efforts de convergence doivent toutefois être faits avec pour objectif de bénéficier d’une

meilleure interopérabilité entre les architectures existantes : des études sur des points particuliers (par exemple, la convergence des méta-modèles de données des différentes architectures) ont été lancées par le DoD,


la plupart des problèmes actuels dans le domaine de la simulation distribuée ne sont pas liés aux architectures adoptées, mais plutôt à la gestion et à l'organisation interne des projets.

6.6 Conclusions Au travers des différents efforts finalisés aujourd’hui par la publication de la norme HLA IEEE 1516-2010, intégrant une API Web Service ou en dehors de HLA (TENA…), il apparaît que l’utilisation des technologies issues du Web, représente une tendance d’intérêt pour le domaine de la simulation distribuée. Ces Web services sont déjà disponibles dans certaines RTIs, même si les résultats en termes de performances sont très moyens. Toutefois, cette convergence de HLA et des nouvelles technologies semble naturelle car elle combine à la fois la disponibilité des importants moyens de communication (existant et à venir) liés à l’essor de l’Internet et l’objectif même de HLA, norme dédiée à la réutilisation et à l’interopérabilité (sur réseau local mais également à distance). Des efforts de normalisation à côté de HLA tels XMSF108 et les ateliers WebSIM ont été stoppés en 2004/2005. Ces arrêts sont dus au manque de maturité des technologies concernées et/ou à un manque de soutien de leurs promoteurs. Un des efforts de normalisation à côté de HLA pour l’interconnexion des simulations, effort actif et structuré, est le SRML (Simulation Reference Markup Language, basé sur XML et développé par la SISO). Ses objectifs en termes d’interopérabilité sont relativement modestes, mais à ne pas négliger. Dans une autre direction, il ne semble pas que les tenants de TENA aient le désir ou la volonté d’en faire une norme et les avantages techniques de cette architecture ne sont pas évidents. En outre, le "modèle d'affaire" de TENA qui n'offre pas la possibilité de développer des outils commerciaux ou "open source" empêche de le recommander pour une utilisation professionnelle. Enfin, on observe à l’heure actuelle, un effort de réflexion sur la notion d’interopérabilité sous une perspective plus amont, au niveau architecture. Cet effort piloté par l’US DoD, est largement ouvert à la communauté internationale via la SISO et l’OTAN. Ces efforts ne semblent pas devoir déboucher sur de nouvelles architectures normalisées.

En conclusion, si l’on considère les efforts actuels en termes de normalisation et de mise sur le marché de produits et outils liés à cette norme, HLA qui a déjà été capable d’intégrer pleinement les capacités de XML (dès la version IEEE 1516-2000 et encore mieux dans la version IEEE 1516-2010), mais aussi d’utiliser les Web Services (de façon limitée) devrait rester la norme de choix à court et moyen terme. D’autres évolutions intéressantes comme les BOMs (normalisés en 2006) et les modules de FOM/SOM confirment la vitalité de HLA. Sa maturité industrielle est certaine et la pérennité de la norme semble assurée au moins jusqu’en 2015 et probablement plus loin.

108 Extensible M&S Framework profile.


7 ANNEXES

7.1 Annexe A : Documents de référence

[A1] IEEE Std 1516-2010 TM: “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules”, August 2010

[A2] IEEE Std 1516.1-2010 TM: “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification”, August 2010

[A3] IEEE Std 1516.2-2010 TM: “IEEE Standard for Modeling and Simulation (M&S)

High Level Architecture (HLA) - Object Model Template (OMT) Specification”, August 2010 [A4] IEEE Std 1516.4-2007 TM: “IEEE Recommended Practice for Verification, Validation and

Accreditation of a Federation: An Overlay to the High Level Architecture Federation Development and Execution Process”, December 2007

[A5] IEEE Std 1516.1-2000 TM: “IEEE Standard for Modeling and Simulation (M&S)

High Level Architecture (HLA) - Federate Interface Specification”, September 2000 [A6] IEEE Std 1516.2-2000 TM: “IEEE Standard for Modeling and Simulation (M&S)

High Level Architecture (HLA) - Object Model Template (OMT) Specification”, September 2000 [A7] IEEE Std 1516.3-2000 TM: “IEEE Recommended Practice for High Level Architecture

Federation Development and Execution Process (FEDEP)”, April 2003 [A8] "TENA: The Test and Training Enabling Architecture", Spring SIW 2009,

Tutoriel SISO de Mars 2009, par Ed POWELL, TENA Architect (copyright SISO) [A9] Guide for Base Object Model (BOM) Use and Implementation, SISO-STD-003.1-2006,

approved Draft, SISO BOM PDG, March 2006 [A10] Base Object Model (BOM) Template Specification, SISO-STD-003-2006, SISO BOM PDG,

March 2006 [A11] “Implementation Plan for NATO/PfP HLA Certification”, version 2, 15 septembre 2009,

rapport technique élaboré par le groupe OTAN MSG-050 "NATO HLA Working Group" [A12] “RPR – FOM”, Version 1.0, SISO-STD-001.1-1999, Août 1999 et "Version 2, draft 17"

version la plus récente, mais non officiellement approuvée du RPR FOM correspondant à IEEE 1516 de HLA

[A13] “GRIM - Guidance, Rationale, and Interoperability Manual for the Real-time Platform

Reference Federation Object Model (RPR FOM), Version 2.0D17v4, The RPR FOM Product Development Group (PDG), 03 Octobre 2006

[A14] “Selecting an HLA Run-Time Infrastructure: Overview of critical issues affecting the

decision process for Wae-In-a-box, M. Imbrogno, W. Robbins and G. Pieris, Defense R&D Canada – Ottawa, TM 2004-111, July 2004


[A15] SISO: “Dynamic Link Compatible HLA API Standard for the HLA Interface Specification”, (IEEE 1516.1 Version), (SISO-STD-004.1-2004), April 2006

[A16] IEEE P1730™ : "IEEE Recommended Practices for Distributed Simulation Engineering and

Execution Process (DSEEP)" (September 2010) [A17] “GM-VV Vol.1: Introduction and Overview – Draft”, Février 2011 [A18] “Final Report for NATO MSG-050, HLA Working Group”, 2010

[A19] REC-XML-20060816, Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C

Recommendation, Aug. 2006109

109 Document disponible sur le site http://www.w3.org/.


7.2 Annexe B : Bibliographie

[B1] US Department of Defense, “High Level Architecture Rules Version 1.3,” 20 April 1998. [B2] US Department of Defense, “High Level Architecture Interface Specification Version 1.3,”

20 April 1998. [B3] US Department of Defense, “High Level Architecture Object Model Template Specification

Version 1.3,” 20 April 1998 [B4] Rapport OTAN du groupe MSG-005 (référence: AC/323(MSG-005) TP/08-RTO-TR-MSG-

005 May 2004) “Federation Development and Execution Process (FEDEP) Tools in support of NATO Modeling & Simulation (M&S) Programmes”

[B5] High Level Architecture, Run-time Infrastructure, RTI 1.3 Next generation, Version 5,

DMSO, Department of Defense [B6] E. T. Powell, K. Lessmann, J. Lucas, G. J. Rumford, "The Test and Training Enabling

Architecture (TENA) 2002 : Overview and Meta-Model, EuroSIW Workshop, Stockholm (Sweden), June 2003

[B7] S. Murphy, J. Labin, R. Lutz, "Experiences using the Six Services of the IEEE 1516.1

Specification: A 1516 Tutorial", (04S-SIW-056), Spring Interoperability Workshop, Arlington (VA), April 18 – 23, 2004

[B8] D. Campbell, T. Mclean, "Federate Compliance and Federation verification testing under

IEEE 1516" (04S- SIW-137), Spring Interoperability Workshop, Arlington (VA), April 18 – 23, 2004

[B9] Department of Defense, Under Secretary of Defense (Acquisition and technology) (USD

(A&T)), DoD Modeling and Simulation (M&S) Master Plan, Washington, DC, October 1995 [B10] "Cookbook to Adapting Simulations for the High Level Architecture", The HFE Group,

Technical Report, March 25, 2002 [B11] Jean-Louis Igarza, Christian Sautereau, "Distribution Use and Reuse: Questioning the cost

effectiveness of re-using simulations with and without HLA", papier SISO, 01F-SIW-002 [B12] Lionel Lucas, Régis Mauget, "Guide Utilisateur de la Certification HLA", Document

HLA/MEC/GDC/01, version 3, octobre 2007 [B13] Katherine L. Morse, ”XMSF Profile Study Group Final Report”, (05F-SIW-013), Fall

Simulation Interoperability Workshop, Orlando (FL), 18-23 septembre 2005 [B14] Ryan P. Z. Brunton, “Documenting the Web Enabled RTI – An XMSF Profile Prototype”,

(05F-SIW-093), Fall Simulation Interoperability Workshop, Orlando (FL), 18-23 septembre 2005 [B15] Katherine L. Morse, Ryan Brunton, David Drake, « WMDOA Integration Employing Web

Services for Federate Communication – an XMSF Exemplar », Proceedings of the Spring 2003 Simulation Interoperability Workshop, March 2003


[B16] Ryan Burton, Justin Busch, David Drake, Katherine L. Morse, Erik Jilson, « Enhanced Distance Learning for DVTE : Real Time Feedback in an Integrated SCORM Environment », Proceedings of the 2005 Spring Simulation Interoperability Workshop, San Diego, CA, April 3 – 8, 2005

[B17] B. Möller, S. Löf, “Mixing Service Oriented and High Level Architecture in Support of the

GIG”, 05S-SIW-064, Spring Simulation Interoperability Workshop, San Diego (CA) April 3-8, 2005

[B18] Scott Holben, “Applying SOA Net-Centric Enterprise Security Services to Distributes M&S”,

07S-SIW-019, Spring Simulation Interoperabilty Workshop, Norfolk (VA), March 25-30, 2007 [B19] B. Möller, B. Löfstrand, M. Karlsson, „An overview of the HLA Evolved Modular FOMs“,

07S-SIW-108, Spring Simulation Interoperabilty Workshop, Norfolk (VA), March 25-30, 2007 [B20] B. Möller, B. Löfstrand, « Use Cases for the HLA Evolved Modular FOMs », 07E-SIW-040,

European Simulation Interoperabilty Workshop, Grand Miramare Hotel Genoa, Italy, June 18-20, 2007

[B21] Björn Möller, Katherine L Morse, Mike Lightner, Reed Little, Robert Lutz, « HLA Evolved –

A Summary of Major Technical Improvements », 08F-SIW-O64, Fall Simulation Interoperability Workshop, Orlando, Florida, 15-19 September 2008

[B22] Eric Noulard, Jean-Yves Rousselot, Pierre Siron, “CERTI, an Open Source RTI, Why and

How », 09S-SIW-015, Spring Simulation Interoperability Workshop, San Diego, California, 23-27 March 2009

[B23] APRIL: "The Economic Models of Free Software", white paper,

http://www.april.org/files/economicmodels_ en.pdf, December 2007 [B24] Wikipedia: “Run-Time Infrastructure" http://en.wikipedia.org/wiki/Run-Time_Infrastructure

(Simulation), Février 2009 [B25] Bruno d’Ausbourg, Eric Noulard, Pierre Siron, “Running Real Time Distributed Simulations

under Linux and CERTI », 08E-SIW-061, International Simulation Multi-conference, Edinburg, Scotland, June 16-19 2008

[B26] H. Zhao and N. D. Georganas. ”HLA Real-time Extension”. In Proceedings of Fifth

International Workshop on Distributed Simulations and Real-Time Applications, pages 12-21, 2001.

[B27] Azzedine Boukerche, Ahmad Shadid, Ming Zhang, « Efficient Load Balancing Schemes for

Large-Scale Real-Time HLA/RTI Based Distributed Simulations », Proceedings of the 11th IEEE International Symposium on Distributed Simulation and Real-Time Applications, 2007

[B28] Pascal Cantot, Dominique Luzeaux, Jean-Louis Igarza, Roland Rabeau "Simulation et

modélisation des Systèmes de Systèmes, vers la maîtrise de la complexité", Hermès Lavoisier, 2009,ISBN : 978-2-7462-2146-8

[B29] Vijdan Kizilay, Okan Topçu, Halit Oğuztüzün, Feza Buzluca, "RTI-related Behavior

Verification of HLA Federates Using Pre- and Post-conditions", 09F-SIW-079, Fall Simulation Interoperability Workshop, San Diego, California, Septembre 2009

http://www.april.org/files/economicmodels_�

http://en.wikipedia.org/wiki/Run-Time_Infrastructure�


[B30] Martin Adelantado, Jean-Baptiste Chaudron, Armand Oyzel, “Using the HLA, Physical Modeling and Google Earth for Simulating Air Transport Systems Environmental Impact”, 09S-SIW-045, Spring Simulation Interoperabilty Workshop (SIW), San Diego (CA), 23-27 March 2009

[B31] “Test and Training Enabling Architecture (TENA): Technical Overview Course”, K.

Lessmann, 19 September 2004 [B32] “Test and Training Enabling Architecture (TENA)”, L. Prignac, R. Mauget, Présentation

reunion ADIS du 24 novembre 2009 [B33] Jean-Baptiste Chaudron, Eric Noulard, Pierre Siron, “Design and modeling techniques for

real-time RTI time management », 11S-SIW-045, Spring Simulation Interoperabilty Workshop (SIW), Boston (MA), 4 - 8 April 2011

[B34] A. Nguyen, “Statistiques Françaises de Certification HLA (période 2008 – 2010)”, Document

HLA/MEC/STA/03, 21 décembre 2010

[B35] « French HLA Certification Statistics (Period 2006 – 2007), Report HLA-MEC-STA-01-v1.1_en, 9 december 2010

[B36] « The Test and Training Enabling Architecture (TENA)», Overview Briefing, 22 November

2010 [B37] Paul Gustavson, Robert Lutz, Jane Bachman, “PSG BOMs Annual report”, SISO-REF-029-

2008, 16 décembre 2008 [B38] Amy E. Henninger, Dannie Cutts, Margaret Loper, Robert Lutz, Robert Richbourg, Randy

Saunders, Steve Swenson, « Live Virtual Constructive Architecture Roadmap (LVCAR) », Final Report, September 2008

[B39] J. Hollenbach, « Live Virtual Constructive Architecture Roadmap (LVCAR) Execution

Management », September 2008

[B40] “Migrating a Federate from HLA 1.3 to HLA Evolved”, Pitch Report, November 2010


7.3 Annexe C : Compléments sur l'architecture HLA

Dans cette annexe, nous présentons les éléments essentiels permettant à un concepteur de fédérés ou de fédérations HLA de développer ses simulations. Nous baserons cette présentation sur la norme IEEE 1516-2010110. Les évolutions de la norme US DoD 1.3 vers la norme IEEE 1516-2000111 font l'objet de l’annexe 0. Un guide de migration de fédérés à la norme US DoD V1.3 vers la norme IEEE 1516-2010 est proposé dans l’annexe 7.4. La compréhension de la présente annexe nécessite la lecture préalable du corps de ce guide.

7.3.1 Les règles HLA [A1]

Rappelons que ces règles définissent les rôles et responsabilités des fédérés.

Dix règles de base doivent être respectées pour qu’une application de simulation respecte les spécifications HLA. 5 règles concernent la fédération et 5 règles les fédérés.

a) Règles pour la fédération :

N°1 : Obligation du respect du formalisme OMT de HLA pour décrire les fédérations :

Les fédérations auront un modèle objet (FOM), documenté conformément à l'OMT.

N°2 : Représentation des objets au niveau des fédérés et non de la RTI :

Au sein d'une fédération, toutes les représentations d'objets se situeront au niveau des fédérés, et non au niveau de la RTI.

N°3 : Passage par la RTI pour les échanges de données publiques entre les fédérés :

Pendant l'exécution d'une fédération, tous les échanges de données figurant dans la FOM et partagées entre les fédérés devront s'effectuer via la RTI.

N°4 : Respect de la spécification d'interface pour l'utilisation de la RTI :

Pendant l'exécution d'une fédération, les fédérés devront interagir avec l'infrastructure d'exécution (RTI) en accord avec les spécifications d'interfaces de HLA.

N°5 : A tout moment pendant l'exécution d’une fédération, un attribut n’appartient qu’à un fédéré :

Pendant l'exécution d'une fédération, un attribut d'un objet ne sera la propriété que d'un seul fédéré, à un instant donné.

b) Règles pour les fédérés :

N°6 : Obligation du respect du formalisme OMT de HLA pour décrire les fédérés :

Les fédérés auront un modèle objet de simulation (SOM), documenté conformément à l'OMT.

N°7 : Transparence des attributs contrôlés par un fédéré et capacité d'interactions d’après leur SOM :

Les fédérés seront capables de publier et/ou répercuter n'importe quel attribut des objets de leur SOM, et d'envoyer et recevoir des interactions issues d'objets extérieurs dont la description est fournie dans le SOM.

N°8 : Capacité des fédérés à transférer et/ou à accepter le contrôle d'attributs d’après leur SOM :

Les fédérés seront capables de transférer ou d'accepter le contrôle d'attributs dynamiquement pendant l'exécution de la fédération, conformément au modèle objet de simulation (SOM). 110 Même si certaines figures sont issues de documents relatifs à la norme US DoD V1.3. Lorsque c’est le cas, ces figures demeurent conformes aux normes IEEE 1516-2000 et IEEE 1516-2010. 111 Afin que les utilisateurs de la norme US DoD V1.3 mesurent les différences avec la norme IEEE 1516-2000 sans se préoccuper des nouvelles fonctionnalités apportées par la norme en cours, l’IEEE 1516-2010.


N°9 : Faculté des fédérés à faire varier les conditions de mise à jour des attributs d’après leur SOM :

Les fédérés seront capables de faire varier les conditions (exemple : seuil) sous lesquelles ils fournissent des mises à jour des attributs publics des objets conformément à leur modèle objet de simulation (SOM).

N°10 : Aptitude des fédérés à gérer un temps local, selon les principes décrits dans HLA :

Les fédérés seront capables de gérer un temps local de telle sorte que cela leur permette de coordonner les données échangées avec les autres membres d'une fédération.

7.3.2 L'object model template (OMT) et ses composants [A3]

7.3.2.1 Rappels et constituants de l'OMT

Rappelons que L’OMT fournit la syntaxe et le format des modèles orientés objets génériques qui permettent de définir les communications au sein d'une simulation HLA. Rappelons également que la communication sous HLA est supportée soit par des instances de classe d'objets (instances caractérisées par les valeurs de leurs attributs), soit par des classes d'interactions (classes caractérisées par les valeurs de leurs paramètres).

L’OMT définit deux types de modèles relatifs soit aux échanges d'un fédéré avec le monde extérieur, soit aux échanges entre fédérés au sein d'une fédération :

a) Les modules SOM (Simulation Object Model) permet de décrire l'ensemble des données échangées entre un fédéré et le monde extérieur.

b) Les modules FOM (Fédération Object Model) permet de décrire l'ensemble des données échangées au sein d'une fédération, c'est-à-dire partagées par les fédérés.

L'un des objectifs principaux de l’OMT est de rendre interopérables les simulations et de faciliter la réutilisation des simulations existantes en exploitant les modules SOMs.

La notion de module SOM et FOM est apparue avec la norme IEEE 1516-2010 (se référer à l’annexe 7.6.1). Les modules FOM et SOM se combinent au cours de l’exécution d’une fédération en respectant des règles très strictes énoncées dans l’annexe C de [A3].

Les modules FOMs et SOMs sont constitués d'un ensemble de tableaux qui doivent être renseignés par les concepteurs de fédérés ou de fédérations. Il existe bien évidemment des outils offrant une interface graphique permettant de remplir ces tables. Tous les modules SOMs et FOMs doivent pouvoir être présentés au format DIF112. Les tables de l'OMT, dans la norme IEEE 1516-2010, sont les suivantes :

Table d’identification du modèle objet : définit les caractéristiques d’une application de simulation sous HLA (Point de contact, nom, adresse, version …).

Table des classes d'objets : décrit les classes d’objets, leurs classes dérivées dans une simulation ou une fédération.

Table des classes d’interactions : décrit les classes d’interactions, leurs classes dérivées dans une simulation ou une fédération.

Table des attributs : spécifie les caractéristiques des attributs des classes d'objets dans une simulation ou une fédération.

Table des paramètres : spécifie les caractéristiques des paramètres des classes d’interaction dans une simulation ou une fédération.

Table des espaces de routage : spécifie une zone d’échange protégée pour les attributs des classes d’objets et d’interactions dans une fédération. Ce tableau n'est nécessaire que lorsque la simulation utilise les services de gestion de la distribution des données (DDM).

112 Data Interchange Format.


Table de représentation du temps : décrit la politique de gestion du temps.

Table des tags utilisateur : définit la signification des tags utilisateurs passés en paramètre de certains services.

Table des synchronisations : décrit les types des données utilisées dans les services de synchronisation.

Table des types de transport : décrit les types de transport des attributs et paramètres.

Table des fréquences de mise à jour : donne les fréquences de mise à jour des attributs ou paramètres.

Table des « switchs » : donne les valeurs par défaut de certaines variables utilisées par la RTI.

Table des types de données : décrit les types des données utilisées.

Table des notes : permet de fournir des informations complémentaires sur n’importe quel item de toute table de l’OMT.

Table d’utilisation des spécifications d’interface : spécifie les services HLA utilisés par un fédéré ou au sein d’une fédération.

Lexique FOM/SOM : définit tous les termes utilisés dans les tables.

L’objectif du FOM est de fournir une spécification des échanges de données publiques entre fédérés, grâce à :

• Une énumération de toutes les classes d’objets participant à une fédération.

• Une description des attributs de ces classes d’objets.

• Une description des classes d'interactions.

• Une description des paramètres des classes d'interactions.

Le SOM décrit les classes d'objets et d'interactions que le fédéré partage avec le monde extérieur. La conception du FOM d'une fédération s’appuie donc sur l’intégration des parties des SOM de tous les fédérés qui participent à la fédération.

L’OMT de la norme IEEE 1516-2010 inclut 2 entités supplémentaires :

a) Le MOM113 qui constitue un sous-ensemble de toute FOM,

b) Le MIM114 qui contient des renseignements complémentaires sur les types de données et de transport. La HLA offre un MIM par défaut qui est automatiquement incorporé au document FDD115 par la RTI.

Dans ce qui suit, nous donnons un exemple de SOM pour un fédéré imaginaire simulant le comportement d'un restaurant.

7.3.2.2 Table des classes d'objets

Il s'agit d'une table décrivant la filiation des classes d’objets et leurs classes dérivées.

113 Management Object Model. 114 Management Initialization Module. 115 FOM Document Data.


Figure 37 Exemple de table de classes d’objets (Reproduit avec permission de l’IEEE

La signification des annotations P, S et N est la suivante :

PS (PublishSubscribe) : Le fédéré publie et s'abonne à au moins un attribut de la classe.

S (Subscribe) : Le fédéré s'abonne à au moins un attribut de la classe.

P (Publish) : Le fédéré publie au moins un des attributs de la classe.

N (Neither) : Le fédéré ne publie aucun attribut d’aucune classe et ne s’abonne à aucun attribut d’aucune classe (classe abstraite en général).

7.3.2.3 Table des classes d’interactions

Il s'agit d'une table décrivant la filiation des classes d’interaction et leurs classes dérivées.


Figure 38 Exemple de table de classes d’interaction (Reproduit avec permission de l’IEEE)

Les annotations P/S/N ont la même signification que pour la table des classes d’objets.

7.3.2.4 Table des attributs

Il s'agit de tables décrivant les attributs des classes d'objets et les paramètres des classes d'interactions. La Figure 37 représente un exemple de table des attributs des classes d'objets.

La signification des annotations de la colonne 6 de cette table (D/A) varie selon qu’il s’agit d’un FOM ou d’un SOM.

Dans un FOM ou un module FOM, ces annotations indiquent comment sont utilisés les attributs par la fédération :

D (Divest) : au moins un fédéré participant à la fédération est capable de publier la classe d’attributs et de renoncer à la propriété d’une instance de cet attribut en invoquant les services de gestion de la propriété.

A (Acquire) : au moins un fédéré participant à la fédération est capable de publier la classe d’attributs et d’acquérir la propriété d’une instance de cet attribut en invoquant les services de gestion de la propriété.

N (NoTransfer) : la propriété d’une instance de cette classe d’attributs n’est pas transférable pendant l’exécution de la fédération.

DA (DivestAcquire) : un fédéré participant à la fédération est capable de renoncer à la propriété d’instances de cette classe d’attributs, et un autre fédéré est capable d’acquérir la propriété d’instances de cette classe d’attributs.


Figure 39 Exemple de table de description des attributs (Reproduit avec permission de l’IEEE)

Dans un SOM ou un module SOM, la signification des annotations précédentes se déclinent sur le fédéré considéré de la manière suivante :

D (Divest) : le fédéré est capable de publier la classe d’attributs et de renoncer à la propriété d’une instance de cet attribut en invoquant les services de gestion de la propriété.

A (Acquire) : le fédéré est capable de publier la classe d’attributs et d’acquérir la propriété d’une instance de cet attribut en invoquant les services de gestion de la propriété.

N (NoTransfer) : la propriété d’une instance de cette classe d’attributs n’est pas transférable pendant par ce fédéré (il ne peut ni renoncer à la propriété ni l’acquérir).

DA (DivestAcquire) : le fédéré est capable de renoncer à la propriété d’instances de cette classe d’attributs, et un autre fédéré est capable d’acquérir la propriété d’instances de cette classe d’attributs.

Les annotations (P/S) de la colonne 7 ont la même signification que pour la table des classes d’objets.

Pour la signification du contenu des autres colonnes de cette table et celles des autres tables de l’OMT, le lecteur est invité à se référer au document normatif [A3].


IPC

7.3.2.5 Management Object Model (MOM)

Le MOM est un composant documenté selon l'OMT. Ce modèle objet peut être utilisé par les fédérés pour obtenir des informations sur la fédération à laquelle ils participent. Le MOM est un modèle objet figé par les spécifications HLA, dans le sens où il n'a pas à être renseigné par le concepteur de fédérés ou de fédérations.

Le MOM est constitué d’un ensemble prédéfini de classes d’objets et d’interactions permettant aux fédérés de recueillir des informations sur son comportement et celui des fédérés participant à une fédération. L’implémentation normative de la MOM est décrite dans le document normatif IEEE 1516.1-2020 [A2].

La MOM est structurée en 2 classes d’objets et plusieurs classes d’interactions116. Les 2 classes d’objet sont :

La classe d’objet « HLAmanager.HLAfederate » dont les attributs décrivent l’état du fédéré. La RTI publie les attributs de cette classe et enregistre une seule instance pour chaque fédéré. Il met ensuite à jour périodiquement les attributs de cet objet117, mises à jour répércutées vers le fédéré,

La classe d’objet « HLAmanager.HLAfederation » dont les attributs décrivent l’état de la fédération.

7.3.2.6 Conformité des outils de gestion des modèles objets

Un outil de gestion des modèles objets est qualifié de conforme lorsqu’il est capable de gérer un modèle objet en XML conformément aux spécifications décrites dans [A19].

7.3.3 L'architecture de la RTI

La RTI constitue une implémentation des spécifications d'interface de la norme IEEE 1516-2010. Il s'agit d'un intergiciel118 distribué offrant les services HLA aux fédérés. Bien entendu, il n'existe pas d'implémentation unique des spécifications HLA, et chaque RTI peut présenter ses propres particularités tout en restant conforme à HLA.

Ce guide n’ayant pas pour objet de s’appuyer sur l’architecture d’une RTI commercialisée par un vendeur particulier, nous nous appuierons sur la RTI NG du DMSO119, dont l'architecture est illustrée sur la Figure 40. Notons qu’à ce niveau de description, les architectures de toutes les RTIs sont semblables.

116 Se référer au chapitre 11 du document normatif [A2] pour les classes d’interaction de la MOM. 117 La période est donnée par l’interaction HLAmanager.HLAfederate.HLAadjust. 118 Le terme désigne ici un « middleware » de communication. 119 La version V6 du RTI NG (norme US DoD 1.3) fut la dernière à être offerte gratuitement par le DMSO.

RTIExec FEDExec

Fédéré

LibRTI

Fédéré

LibRTI


LRC RTIAmbassador

Code Fédéré FEDAmbassador

Figure 40 Les composants de la RTI

La RTI est composée de trois éléments :

• Le RTI Executive (RTIExec) : il s'agit d'un processus informatique qui gère les fédérations au travers du réseau (la création et la suppression des fédérations).

• Le Federation Executive process (FEDExec) : il s'agit d'un processus informatique, créé par le RTIExec lorsqu'un fédéré crée une fédération. Il existe un processus FEDExec par fédération. Ce processus gère les échanges de données entre fédérés participants à une même fédération.

• La RTI Library (LibRTI) qui implémente les services des spécifications d'interface. Cette librairie est liée avec le code de chaque fédéré.

A l'exécution, la RTI se compose donc des processus RTIExec et FEDExec, ainsi que d'un composant local, appelé LRC (Local RTI Component) qui sert d'interface de communication entre son fédéré et les 2 autres processus. Les invocations des services HLA par le fédéré passent donc toujours par le LRC. Réciproquement, c'est le LRC qui est responsable de la diffusion des données en provenance de la fédération, vers son propre fédéré. Les échanges entre ces composants sont assurés par l’IPC (Interprocess Communication) qui propose des services de communication de messages entre différents processus aussi bien sur un site distant avec le protocole TCP/IP que sur un site local. Certains RTIs comme celui de Mäk, fonctionnent sous le mode lightweight, sans processus RTIexec. De manière générale, l’implémentation des RTIs n’étant pas normalisée, il peut y avoir des différences importantes, voir des incompatibilités, dans les choix d’implémentation des RTIs.

7.3.4 Les composants d'un fédéré HLA120

Les échanges entre fédérés et RTI sont représentés sur la figure Figure 41. Ils sont assurés par 2 classes fournies par la libRTI : la classe RTIAmbassador et la classe FEDAmbassador, dont les méthodes implémentent les services des spécifications d'interface [A2]. Les services de la classe RTIAmbassador sont invoqués par le fédéré pour diffuser des informations à la fédération par l'intermédiaire du LRC. Les services de la classe FEDAmbassador sont au contraire invoqués par le LRC pour diffuser des informations à son fédéré. Ces derniers services sont communément appelés callbacks.

Figure 41 Echanges entre fédéré et RTI

120 Toujours en utilisant le vocable du RTI NG ou du CERTI de l’ONERA.

RTI


Un fédéré est d'abord composé de sa boucle de simulation qui abrite l'aspect métier de la simulation et donc le modèle des entités simulées.

Ensuite, pour pouvoir invoquer les services de la RTI, tout fédéré doit créer une instance de la classe RTIAmbassador et une instance de la classe FEDAmbassador.

Les services de la classe RTIAmbassador constituent la librairie fournie par la distribution de la RTI. Ils n'ont pas à être codés par le concepteur. En contrepartie, les services de la classe FEDAmbassador doivent être renseignés par le concepteur du fédéré, puisque la RTI n'a aucune connaissance du traitement des informations reçues par un fédéré.

7.3.5 La sémantique des données échangées au sein d'une fédération

Comme précisé dans le corps du guide, la RTI n'a aucune connaissance de la sémantique des données échangées au sein d'une fédération. Ainsi, vue de la RTI, toute donnée échangée est une suite d'octets sans aucune signification. Cette vision est importante à double titre.

D'abord, parce qu’avant toute utilisation du nom d'une classe d'objets ou d'interactions, du nom d'un attribut ou de celui d'un paramètre, tout fédéré doit demander à la RTI une référence (appelé handle dans le vocabulaire HLA). Cette demande s'effectue par invocation de services auxiliaires de la classe RTIAmbassador. Par exemple, avant publication de l'attribut X de la classe Vehicle, le fédéré doit demander la référence de la chaîne de caractères "Vehicle", et celle de la chaîne de caractères "X". La RTI assure bien évidemment l'unicité des références au sein d'une même fédération. C'est sans doute l'une des exigences les plus troublantes pour un concepteur de fédérés HLA. Notons que ce choix améliore les performances de la RTI de manière significative.

Ensuite, parce que des règles d'encodage des valeurs numériques comme le "data marshalling" ne sont pas traitées par la RTI, bien que l'une des hypothèses fortes de HLA soit l'interopérabilité entre fédérés s'exécutant sur des plates-formes hétérogènes. En conséquence, ce problème lorsqu'il se pose, doit être résolu par le ou les concepteurs eux-mêmes.

7.3.6 Les services fondamentaux offerts par la norme HLA IEEE 1516-2010[A2]

Dans ce paragraphe, nous proposons de décrire les principaux services offerts par la norme. Nous n'aborderons pas la description des paramètres des services. Pour une description rigoureuse de chaque service, le lecteur est invité à consulter le document normatif [A2]ainsi que les manuels de référence et d'utilisation de sa RTI.

Rappelons que ces services sont classés en 6 familles plus 1 famille de services auxiliaires. Ces 6 familles sont :

Gestion des fédérations

Gestion des déclarations

Gestion des objets

Gestion de la propriété

Gestion du temps

Gestion de la distribution

Dans ce paragraphe, nous n'aborderons pas la famille de services consacrée à la gestion du temps qui fera l'objet d'un paragraphe particulier.

7.3.6.1 Gestion des Fédérations

Cette famille de services permet la création, le contrôle, la modification et la destruction de l’exécution d’une fédération. Le contrôle de l’exécution d'une fédération regroupe des services de synchronisation entre fédérés et des services de pause et de reprise de l'exécution d'une fédération. Les principaux services sont résumés dans le tableau suivant.


Condition d’utilisation

Objet Services Fédéré RTI Commentaires

Connect X Le fédéré établit une connexion avec la RTI

Disconnect X Le fédéré ferme la connexion avec la RTI

Exploité par la RTI

Create Federation Execution

X le fédéré lance l'exécution de la fédération

Destroy Federation Execution

X le fédéré termine l'exécution de la fédération nommée

Join Federation Execution

X le fédéré rejoint l'exécution de la fédération en cours

Connection Lost X La RTI annonce que le fédéré quitte la fédération suite à une faute

List Federation Executions

X Le fédéré demande une liste des exécutions de fédérations en cours

Report Federation Executions

X La RTI fournit une liste des exécutions de fédérations en cours

Employé par les fédérés

Federation

Resign Federation Execution

X le fédéré quitte l'exécution de la fédération en cours

Confirm Synchronization Point Registration

X la RTI confirme qu’un Register Federation Synchronization Point a été invoqué par le fédéré

Register Federation Synchronization Point

X le fédéré demande un point de synchronisation

Pause

Announce Synchronisation Point

X la RTI demande au fédéré de stopper l'évolution de son état

Utilisé par les fédérés

Resume Synchronisation Point Achieved

X le fédéré indique qu'il a correctement stoppé l'évolution de son état


Federation Synchronized

X la RTI indique à un fédéré qu'il peut poursuivre l'évolution de son état

Request Federation Save

X le fédéré demande une sauvegarde de l'état de la fédération en cours

Initiate Federate Save

X la RTI demande à un fédéré de sauvegarder son état courant

Federate Save Begun

X le fédéré indique qu'il a commencé à sauvegarder son état

Abort Federation Save

X Le fédéré demande à suspendre la sauvegarde en cours

Query Federation Save Status

X Le fédéré demande l’état de la sauvegarde en cours

Federation Save Status Response

X La RTI délivre l’état de la sauvegarde en cours

Federation Saved X La RTI signale que la sauvegarde est terminée

Federate Save Complete

X le fédéré indique qu'il a terminé de sauvegarder son état

Request Federation Restore

X le fédéré demande de restaurer un état de la fédération préalablement sauvegardé

Confirm Federation Restoration Request

X la RTI indique au fédéré l’état de la restauration en cours

Federation Restore Begun

X La RTI signale au fédéré que la restauration est imminente

Abort Federation Restore

X Le fédéré demande à suspendre la restauration en cours

Initiate Federate Restore

X la RTI demande à un fédéré de restaurer un état préalablement sauvegardé

Query Federation Restore Status

X Le fédéré demande l’état de la restauration en cours

Federation Restore Status

X La RTI fournit l’état de la restauration en cours

Restore

Federation Restore Complete

X la RTI indique que la restauration est terminée


7.3.6.2 Gestion des Déclarations (DM)

Ces services permettent à un fédéré de spécifier les types d’objets, d’interactions et d’attributs qu’il souhaite fournir (publication) ou qu’il souhaite recevoir (abonnement) pendant l’exécution de la fédération. Les principaux services sont résumés dans la table suivante.


Objet Services Fédéré

RTI Commentaires

Publish Object Class Attributes

X le fédéré déclare son intention de publier des attributs d’une classe d’objets

Unpublish Object Class Attributes

X Le fédéré déclare son intention de cesser de publier des attributs d’une classe d’objets

Start Registration For Object Class

X La RTI signale au fédéré qu’il peut commencer à créer des instances de la classe d’objets121

Stop Registration For Object Class

X La RTI signale au fédéré qu’il peut cesser de créer des instances de la classe d’objets122

Publish Interaction Class

X le fédéré déclare son intention de publier une classe d’interaction

Unpublish Interaction Class

X le fédéré déclare son intention de cesser de publier une classe d’interaction

Turn Interactions On

X La RTI signale au fédéré qu’il peut commencer à émettre des interactions123

Fédérés souhaitant publier des attributs de classes d’objets

Publish

Turn Interactions Off

X La RTI signale au fédéré qu’il peut cesser d’émettre des interactions124

Subscribe Object Class Attributes

X le fédéré déclare son intention de s’abonner à certains attributs d'une classe d'objet

Unsubscribe Object Class Attributes

X le fédéré déclare son intention de cesser de s’abonner à certains attributs d'une classe d'objet

Fédérés souhaitant souscrire à des attributs de classes d’objets

Subscribe

Subscribe Interaction Class

X le fédéré déclare son intention de s’abonner à une classe d'interaction

121 Au moins un fédéré vient de s’abonner à un des attributs de la classe. 122 Aucun fédéré n’est abonné à des attributs de la classe. 123 Au moins un fédéré vient de s’abonner à la classe d’interaction. 124 Aucun fédéré n’est abonné à la classe d’interactions.


Unsubscribe Interaction Class

X le fédéré déclare son intention de cesser de s’abonner à une classe d'interaction

A titre d'illustration, la Figure 42 donne un exemple de l'enchaînement des services de la famille de gestion des déclarations. Ce schéma d'enchaînement se généralise à toutes les familles de services.

Dans cet exemple, le fédéré "blanc" s'abonne à un certain nombre d'attributs d'une classe d'objets, et le fédéré "vert" souscrit au même ensemble d'attributs de la classe. Pour simplifier le schéma, les services invoqués sont dépourvus des paramètres d'appel. Enfin, les services en jaune correspondent à des méthodes de la classe RTIAmbassador, alors que les services en bleu sont des callbacks de la classe FEDAmbassador, invoqués par la RTI.

Comme évoqué précédemment, les services GetObjectClassHandle() et GetAttributeHandle() permettent d'acquérir respectivement la référence de la classe et la référence de chaque attribut, références appelées handles. Le fédéré "vert" est tenu d'effectuer les mêmes opérations, bien que ces invocations ne soient pas représentées sur la figure. Ensuite, le fédéré "blanc" signale son intention de publier les attributs de la classe par invocation du service PublishObjectClassAttributes (). Réciproquement, le fédéré "vert" signale son intention de s'abonner aux attributs de la classe d'objets par invocation du service SubscribeObjectClassAttributes(). A partir de cet instant, toute mise à jour des attributs d'une instance de la classe, effectuée par le fédéré "blanc", pourra être répercutée, à sa demande (c’est-à-dire quand le fédéré « donne la main » au RTI par invocation à un service de gestion des « callbacks » - se référer au paragraphe 7.3.8), au fédéré "vert".

Declaration ManagementObjects

RTI

getObjectClassHandle()

subscribeObjectClassAttributes()

unsubscribeObjectClass()

publishObjectClass()

unpublishObjectClass()

getAttributeHandle()

startRegistrationForObjectClass()

stopRegistrationForObjectClass()

Figure 42 Exemple d'enchaînement de services de la famille "Gestion des Déclarations"125

Notons, que l'invocation du service SubscribeObjectClassAttributes() par le fédéré "vert" conduit la RTI à invoquer le callback StartRegistrationForObjectClass() afin de prévenir le fédéré capable de publier ces attributs, que compte tenu de la présence au sein de la fédération d'un fédéré intéressé par

125 Cette figure est une capture d’écran d’un document concernant la norme US DoD 1.3. A partir de la norme IEEE 1516-2000, certains noms de services ont changé. Par exemple, le service PublishObjectClass() a été remplacé par PublishObjectClassAttributes(). De même, le unsubscribeObjectClass() a été remplacé par le UnsubscribeObjectClassAttributes().


ces attributs, il peut commencer à les mettre à jour. Enfin, comme nous l'avons signalé précédemment, tout fédéré peut se désabonner d'une liste d'attributs (service UnsubscribeObjectClassAttributes()) ou interrompre son intention de publier ces attributs (service UnpublishObjectClassAttributes()) quand il le désire.

HLA multiplie les mécanismes de ce type qui, même s'ils ne sont pas nécessairement exploités par les fédérés, permettent néanmoins d'optimiser la charge du réseau.

7.3.6.3 Gestion des Objets

Cette famille de services permet aux fédérés de créer, modifier et détruire des objets ou bien d'envoyer ou recevoir des interactions. Les principaux services sont décrits dans le tableau suivant.



Reserve Object Instance Name

X le fédéré demande à réserver un nom pour une instance de classe d’objet

Object Instance Name Reserved

X la RTI signale au fédéré que la réservation a été acceptée

Release Object Instance Name

X le fédéré renonce à la réservation d’un nom pour une instance de classe d’objet

Reserve Multiple Object Instance Names

X le fédéré demande à réserver plusieurs noms pour des instances de classe d’objet

Multiple Object Instance Names Reserved

X la RTI signale au fédéré que la réservation a été acceptée

Release Multiple Object Instance Names

X le fédéré renonce à la réservation de plusieurs noms d’instances de classe d’objet

Register Object Instance

X association d'un objet à son ID unique préalablement demandé

Discover Object Instance

X la RTI informe un fédéré qu'il dispose de nouveaux objets le concernant

Utilisation et affectation d’objets

Object

Delete Object Instance

X le fédéré informe la RTI qu'un objet est retiré


Remove Object Instance

X la RTI informe un fédéré qu'un objet a été définitivement retiré

Update Attribute Values

X le fédéré fournit à la RTI une mise à jour des attributs

Reflect Attribute Values

X la RTI fournit à un fédéré les nouvelles données le concernant

Request Object Attribute Value

Update

X le fédéré demande la mise à jour d'attributs

Provide Attribute Value

Update

X la RTI fournit la mise à jour d'attributs

Turn Updates On For Object Instance

X la RTI informe le fédéré que certaines valeurs d’attributs d’une instance de classe d’objet est sont demandées par un fédéré

Attribute

Value

Turn Updates Off For Object Instance

X la RTI informe le fédéré que certaines valeurs d’attributs d’une instance de classe d’objet ne sont plus demandées par aucun fédéré

Send Interaction

X le fédéré informe la RTI qu'une action a été lancée par un objet

Receive Interaction

X la RTI informe qu'une action a été lancée par un objet

Manipulation de valeurs d'attributs et d’interactions

Interaction

Change Attribute

Transport Type

X le fédéré change le type de transport d'un attribut d'une classe

Request Attribute Transportation Type Change

X le fédéré demande à changer le mode de transport de certains attribut de l’instance de classe d’objet126

Modification des modes de transport et d'ordonnancement des informations

Change

Change Interaction

Transport Type

X le fédéré change le type de transport d'une classe d'interaction

126 Le type de transport par défaut est précisé dans le document FDD.


Confirm Attribute Transportation Type Change

X Callback en réponse service Request Attribute Transportation Type Change

Query Attribute Transportation Type

X le fédéré demande le mode de transport courant d’un attribut d’une instance de classe d’objet

Report Attribute Transportation Type

X la RTI délivre le mode de transport courant d’un attribut d’une instance de classe d’objet

Request Interaction Transportation Type Change

le fédéré demande à changer le mode de transport d’une classe d’interaction

Confirm Interaction Transportation Type Change

X Callback en réponse service Request Interaction Transportation Type Change

Query Interaction Transportation Type

X le fédéré demande le mode de transport courant des paramètres d’une interaction

Report Interaction Transportation Type

X la RTI délivre le mode de transport courant des paramètres d’une classe d’interaction

7.3.6.4 Gestion de la Propriété

Cette famille de services permet de transférer le droit de propriété d’un attribut d’un objet d'un fédéré à un autre, ou au contraire d’en prendre possession. Ce droit de propriété permet à un fédéré de fournir des mises à jour de la valeur de l’attribut. Comme à tout instant, un seul fédéré est propriétaire d’un attribut d’un objet, chaque attribut ne peut être mis à jour que par un seul fédéré à chaque instant, ce qui règle les problèmes d’inconsistance de valeurs d’une même variable qui se posent dans certains systèmes distribués.



Souhait acquérir la propriété

Acquisition Attribute Ownership Acquisition

X le fédéré demande à la RTI d’acquérir la propriété de certains attributs d’une instance de classe d’objet


Attribute Ownership

Acquisition Notification

X la RTI indique au fédéré qu'il est propriétaire de certains attributs d’une instance de classe d’objet

Attribute Ownership Acquisition If Available

X Même chose que pour le service « Attribute Ownership Acquisition », mais seulement si les attributs spécifiés n’ont aucun propriétair

Attribute Ownership Unavailable

X la RTI informe le fédéré que sa demande d’acquisition ne peu être acceptée

Cancel Attribute Ownership Acquisition

X le fédéré signale à la RTI qu’il ne souhaite plus acquérir la propriété de certains attributs d’une instance de classe d’objet

Confirm Attribute Ownership Acquisition Cancellation

X La RTI signale au fédéré que les attributs spécifiés ne désirent plus lui céder la propriété

Unconditional Attribute Ownership Divestiture

X le fédéré signale qu’il souhaite céder la propriété de certains attributs d’une instance de classe d’objet. Pendant un certain temps, ces attributs peuvent n’appartenir à aucun fédéré

Negotiated Attribute Ownership Divestiture

X le fédéré signale qu’il souhaite céder la propriété de certains attributs d’une instance de classe d’objet. Cette cession ne sera effective que si un fédéré accepte d’acquérir cette propriété

Request Divestiture Confirmation

X la RTI signale que des propriétaires potentiels existent dans la fédération suite à une demande de cession de la propriété

Souhait céder la propriété

Divestiture

Confirm Divestiture X le fédéré signale à la RTI qu’il souhaite terminer la négociation de cession de la propriété de certains attributs d’une instance de classe d’objet


Attribute Ownership

Divestiture Notification

X la RTI indique au fédéré qu'il est dégagé du contrôle des attributs

Attribute Ownership Divestiture If Wanted

X le fédéré signale à la RTI qu’il est prêt à céder la propriété d’un certain nombre d’attributs d’une instance de classe d’objet si un autre fédéré tente de l’acquérir

Cancel Negotiated Attribute Ownership Divestiture

X le fédéré signale qu’il ne souhaite plus céder la propriété de certains attributs d’une instance de classe d’objet.

Propriété à prendre

Assumption Request Attribute Ownership Assumption

X la RTI informe le fédéré qu’il peut acquérir la propriété de certains attributs d’une instance de classe d’objet

Request Attribute Ownership Release

X la RTI demande la cession de la propriété des attributs spécifiés

Propriété à libérer

Release

Attribute Ownership Release Denied

X le fédéré signale à la RTI qu’il refuse la cession des attributs spécifiés

Query Attribute Ownership

X le fédéré demande l’identité du fédéré qui possède la propriété des attributs spécifiés d’une instance de classe d’objet

Inform Attribute Ownership

X callback en réponse à une invocation du service « Query Attribute Ownership”

Information sur le propriétaire

Query

Is Attribute Owned By Federate

X le fédéré demande si un fédéré est propriétaire d’un attribut d’une instance de classe d’objet

7.3.6.5 Gestion de la Distribution des données (DDM)

Cette famille de services permet de mettre en place une politique de filtrage, afin de limiter les échanges d’informations entre fédérés en définissant des critères lors de l'utilisation des services de publication et de souscription. Ces services permettent ainsi d'optimiser la bande passante du réseau.

Le mécanisme de base de ces services consiste à définir des intervalles de valeurs pour les attributs afin qu'un fédéré qui s'abonne à cet attribut ne reçoive que les valeurs appartenant à cet intervalle. La compréhension de ces services nécessite la connaissance de quelques définitions :


a) Une dimension est un intervalle d’entiers non négatifs défini par 2 entiers dont le premier est 0. Le second est spécifié dans le document FDD,

b) Un intervalle semi-ouvert127 peut être défini sur une dimension. 2 bornes (inférieure et supérieure) délimitent cet intervalle,

c) Une spécification de région est un ensemble d’intervalles, d) Un modèle de région128 est une spécification de région incomplète pour laquelle une

ou plusieurs dimensions ne possèdent pas d’intervalles assignés, e) Une réalisation de région129 est une spécification de région qui est associée soit à une

instance d’attribut (lorsqu’il s’agit d’une mise à jour) ou à l’émission d’une interaction, soit à un attribut de classe d’objet ou d’interaction (lorsqu’il s’agit d’un abonnement à ces classes),

f) La RTI fournie des régions par défaut qui sont définies par un intervalle [0, borne supérieure[ pour chaque dimension définie dans le document FDD.

Avec ces définitions, la description des services majeurs de gestion de la distribution des données est fournie dans le tableau suivant :



Create Region X le fédéré demande à la RTI de créer une région avec des dimensions

Commit Region Modifications

X le fédéré signale à la RTI des modifications dans les intervalles spécifiés des régions spécifiées

Création et modifications

Delete Region X le fédéré demande à la RTI de détruire une région

Register Object Instance With Regions

X ce service permet de créer une instance de la classe spécifiée en associant à chacun de ses attributs des régions qui seront utilisé lors de leur mise à jour

Associate Regions For Updates

X ce service permet d’associer à chacun des attributs d’une instance de classe d’objet des régions qui seront utilisé lors de leur mise à jour

Gestion des régions

Association avec les régions pour les mises à jour d’attributs

Unassociate Regions For Updates

X ce service détruit l’association entre les attributs spécifiés d’une instance d’objet et les régions spécifiées

127 Appelé « range » dans les spécifications d’interface. 128 Appelé « region template ». 129 Appelée « region realization ».


Subscribe Object Class Attributes With Regions

X ce service est équivalent au service « Subscribe Object Class Attributes » mais en demandant à la RTI de ne découvrir que les instances de la classe d’objet spécifiée dont au moins 1 attribut est associé aux régions spécifiées

Unsubscribe Object Class Attributes With Regions

X ce service supprime l’association précédente

Subscribe Interaction Class With Regions

X ce service informe la RTI de la classe d’interaction à laquelle il souhaite s’abonner en tenant compte des régions spécifiées

Gestion des regions pour les abonnements

Unsubscribe Interaction Class With Regions

X ce service supprime l’association précédente

Send Interaction With Regions

X le fédéré envoie une interaction en limitant les fédérés receveurs grâce aux régions

Request Attribute Value Update With Regions

X le fédéré demande des mises à jour des attributs spécifiés de toutes les instances de la classe spécifiée qui sont enregistrées dans la fédération

Emission d’interactions et mises à jour d’attributs

7.3.6.6 Les services support

Ces services support permettent de : effectuer les associations entre noms (classes, attributs, interactions …) et handles et

réciproquement, positionner les switchs130, manipuler les régions, acquérir les fréquences de mise à jour (se référer à l’annexe 7.6.4), gérer les « callbacks131 » Pour illustrer l’utilisation de ces services, nous allons décrire 3 exemples. Le lecteur est invité à se référer au chapitre 10 du document normatif [A2] pour une description exhaustive de cette famille de services.

130 Appelés « advisory switchs ». 131 Services invoqués à l’initiative de la RTI.


1. Acquisition des handles associés au nommage des entités

La RTI ne gérant que des identificateurs (entiers), tout fédéré doit acquérir un handle pour identifier tout nom (de classe, d’attribut, de paramètre …) partagé par la fédération. Ainsi le service « Get Object Class Handle » returne le handle associé au nom de la classe passé en paramètre.

2. Gestion de la fréquence de mise à jour d’attributs

La norme IEEE 1516-2010 introduit cette nouvelle fonctionnalité (se référer au paragraphe 7.6.4 de l’annexe. A titre d’illustration, le service « Get Update Rate Value For Attribute » retourne la valeur maximale de la fréquence de mise à jour de l’attribut spécifié appartenant à l’instance de classe d’objet spécifié.

3. Gestion des « callbacks »

Les services de gestion des « callbacks » sont étroitement associés à la gestion du temps (voir les paragraphes 7.3.7 et 7.3.8. Le service « Evoke Callback » informe la RTI que le fédéré est prêt à recevoir un seul « callback ». Si un « callback » est disponible, il est délivré au fédéré. Dans le cas contraire, la RTI retourne le contrôle au fédéré après expiration d’un délai132 spécifié en paramètre. L’invocation du service « Evoke Multiple Callbacks » nécessite le passage d’un intervalle temporel défini par 2 paramètres (min, max). Après invocation de ce service, le fédéré va recevoir tous les « callbacks » disponibles jusqu’à la date min. A partir de cette date, il continuera à recevoir des « callbacks » jusqu’à la date max, s’ils sont disponibles. Dans le cas contraire, le contrôle est rendu au fédéré à la date min.

7.3.7 La gestion du temps

Rappelons que HLA propose 3 mécanismes d'avance dans le temps des fédérés participant à une fédération :

• en temps coordonné, lorsque l'avance dans le temps de chaque fédéré est coordonnée avec celle des autres fédérés,

• sur message, lorsque l'avance dans le temps d'un fédéré est conditionnée par la répercussion d'un message,

• enfin, de manière optimiste, lorsque chaque fédéré avance dans le temps à sa vitesse propre indépendamment de celle des autres fédérés. C’est aussi le cas des fédérations où tous les fédérés sont « temps réel ». Dans le cas de simulation « non temps réel », la réception de messages dans le passé du fédéré, doit provoquer des mécanismes de "rollback" afin que la simulation puisse revenir à un état cohérent avec la date de traitement du message.

Dans un premier temps, nous proposons de nous concentrer sur les mécanismes permettant une avance coordonnée dans le temps, afin de simplifier la présentation de la gestion du temps. Pour cela, il est nécessaire de revenir sur la notion de message, qui est définit par la répercussion soit de nouvelles valeurs pour un ou plusieurs attributs d'une instance de classe d'objets, soit de nouvelles valeurs pour tous les paramètres d'une interaction. Tout attribut de classe d'objets est caractérisé par un descripteur de gestion du temps dans le document FDD. Il en est de même pour toute classe d'interactions. Lorsque ce descripteur a la valeur timestamp, cela signifie qu'une estampille temporelle peut être associée par le fédéré à la valeur de l'attribut, lorsque le fédéré diffuse cette valeur à la fédération par l'intermédiaire de la RTI. Par définition, cette estampille temporelle correspond à la date logique de validité du message par le fédéré qui s'abonne à cet attribut. Dès lors, les services de gestion du temps

132 Précision de 1 ms.


en mode coordonné assurent que, si la date logique d'un fédéré est égale à T, celui-ci ne pourra pas recevoir des messages estampillés avec une date inférieure à T (c'est-à-dire devant être traités dans le passé du fédéré). Par définition, tout message estampillé est appelé TSO (Time-Stamp-Ordered) dans le vocabulaire HLA.

Figure 43 Représentation de l'avance dans le temps d'un fédéré contraint133

Pour mettre en œuvre cette garantie du principe de causalité, tout fédéré peut se déclarer vis-à-vis de l'avance dans le temps, comme régulateur, contraint, régulateur et contraint ou ni l'un ni l'autre, avec les définitions que nous rappelons :

• un fédéré régulateur régule l'avance dans le temps de tous les fédérés contraints participant à la fédération,

• l'avance dans le temps d'un fédéré contraint est régulée par celle de tous les fédérés régulateurs participant à la fédération,

• si un fédéré n'est ni régulateur, ni contraint, alors il s'agit d'un fédéré « temps réel » qui avance dans le temps indépendamment des autres fédérés, et à sa propre vitesse.

Lorsqu'un fédéré est à la fois régulateur et contraint, il régule l'avance dans le temps de tous les fédérés contraints, et sa propre avance dans le temps dépend de celle de tous les fédérés régulateurs.

Le rôle d'un fédéré vis-à-vis de l'avance dans le temps (régulateur ou contraint) est déclaré de sa propre initiative, par invocation de services particuliers de la classe RTIAmbassador. Conformément à l'esprit HLA, tout fédéré peut changer son rôle vis-à-vis de la gestion du temps aussi souvent qu'il le souhaite au cours de l'exécution d'une fédération. Par défaut, un fédéré n'est ni régulateur, ni contraint.

133 Cette figure est une capture d’écran extraite d’un document relatif à la norme US DoD 1.3. Depuis la norme IEEE 1516-2000, le terme LBTS a été remplacé par le terme GALT (Greatest Available Logical Time) mais garde la même sémantique.

Regulating Federate

Constrained Federate

Lookahead

Lower Bound Time Constraint (LBTS)

Time-Stamp-Ordered (TSO) Events

TR

TC


Ces concepts de base suffisent pour comprendre comment la RTI peut garantir l'avance dans le temps d'un fédéré contraint de manière à ce qu'il n'y ait aucune violation du principe de causalité. L'algorithme mis en œuvre est celui de Chandy et Misra (1979). Ces mécanismes sont représentés sur la Figure 43.

Figure 44 Exemple d'enchaînement de services de gestion du temps134

Cet exemple suppose l'existence de 2 fédérés, l'un contraint et l'autre régulateur. Tout fédéré régulateur doit déclarer une durée temporelle, appelée "lookahead", par invocation d'une méthode particulière de la classe RTIAmbassador. Etant donné L, le lookahead du fédéré régulateur, et TR sa date logique courante, celui-ci s'engage à ne pas diffuser des messages avec une estampille temporelle inférieure à TR + L. Dès lors, étant donnée TC la date logique du fédéré contraint, et le LBTS désignant la date TR + L, supposons que le fédéré contraint demande à avancer à la date logique T. Deux cas de figure sont alors possibles :

• la date T est supérieure au GALT. Etant donnée la valeur du lookahead du fédéré régulateur, cette demande ne peut pas être immédiatement accordée par la RTI, car le fédéré régulateur peut encore diffuser des messages avec une estampille temporelle inférieure à T. Dès lors, le fédérateur contraint pourrait recevoir des messages à traiter dans son passé,

• la date T est inférieure ou égale au GALT. Alors compte tenu de l'engagement du fédéré régulateur, celui-ci ne peut plus diffuser des messages avec une estampille temporelle inférieure à T. Dès lors, la RTI peut accorder immédiatement l'avance dans le temps au fédéré contraint.

Ce mécanisme d'avance dans le temps se généralise sans difficulté lorsque plusieurs fédérés régulateurs participent à une même fédération, en considérant que le LBTS est défini par le minimum des Ti + Li de tous les fédérés régulateurs. Remarquons enfin que toute avance dans le temps d'un fédéré qui n'est pas contraint, est immédiatement accordée par la RTI.

Les enchaînements des services invoqués par les fédérés dans un mode d'avance en temps coordonné, sont représentés sur la Figure 44.

Toute demande d'avance dans le temps d'un fédéré, quel que soit son rôle vis-à-vis de la gestion du temps, passe par une invocation du service TimeAdvanceRequest() de la classe RTIAmbassador.

134 Cette figure est une capture d’écran issue d’un document relatif à la norme US DoD 1.3. Les noms des services demeurent cependant les mêmes dans la norme IEEE 1516-2010.

T im e M a n a g e m e n tT im e S te p A d v a n c e m e n t

R T I

t im e A d v a n c e R e q u e s t()

t im e A d v a n c e G ra n t()


Conformément aux mécanismes de communication HLA, la RTI accorde cette avance dans le temps en invoquant la méthode TimeAdvanceGrant() de la classe FEDAmbassador.

Un mode d'avance dans le temps sur message est assez proche de celui évoqué précédemment, à la différence près suivante :

Lorsqu'un fédéré évoque le service TimeAdvanceRequest(T) sa prochaine date logique sera nécessairement égale à T, la date demandée. Une avance dans le temps sur message nécessite l'invocation du service NextMessageRequest(T). Dans ce cas, l'avance dans le temps accordée par la RTI peut être inférieure à la date T demandée. Ce sera la date correspondant à l'estampille temporelle du ou des prochains messages TSO répercutés par la RTI.

Enfin, notons que pour qu'un message soit qualifié de TSO, il faut que 4 conditions soient remplies :

• le fédéré qui publie le message (attribut ou classe d'interaction) soit régulateur,

• le fédéré qui s'abonne au message (attribut ou classe d'interaction) soit contraint,

• le fédéré qui offre à la fédération de nouvelles valeurs d'un attribut ou des paramètres d'une interaction invoque la méthode135 UpdateAttributesValues() ou SendInteraction() avec un paramètre d'estampille,

• enfin, que l'attribut ou la classe d'interactions ait été déclarée avec le descripteur timestamp dans le document FDD. Nous verrons par la suite comment le concepteur définit ce descripteur.

Dans tous les autres cas le message sera répercuté par la RTI comme un message RO (Received Order).

Le tableau suivant récapitule les principaux services de gestion du temps.



Query Lookahead X le fédéré demande la valeur du lookahead

Query GALT X le fédéré demande la valeur du GALT

Query Logical Time X le fédéré demande la valeur de sa date logique

Recherche informations sur le temps

Query

Query LITS X le fédéré demande la date du prochain

message disponible au niveau RTI

Modify Lookahead X le fédéré indique une valeur du lookahead

Pas de temps accordé

Lookahead

Query Lookahead X le fédéré demande la valeur

du lookahead

Gestion avance temps

Advance Time

Time Advance Request

X le fédéré demande un avancement du temps à une date donnée

135 En effet, plusieurs méthodes de l’API sont polymorphes, c'est-à-dire qu’elles apparaissent sous deux versions, l’une avec un paramètre d’estampille temporelle, l’autre sans.


Next Message Request

X le fédéré demande un avancement du temps à la date du prochain message

Flush Queue Request

X le fédéré purge les files d'attentes de messages gérées par la RTI vers lui même

Time Advance Grant

X La RTI accorde au fédéré

l'avancement du temps demandé

Le tableau ci-dessous récapitule les règles d’avance dans le temps respectées par la RTI selon l’état temporel du fédéré (figure reproduite avec la permission de l’IEEE).

7.3.8 Gestion des callbacks

Pour maîtriser les fondements de HLA, il est nécessaire d'aborder les mécanismes permettant à un fédéré de gérer les callbacks c'est-à-dire les méthodes de la classe FEDAmbassador invoquées par la RTI. Ces mécanismes sont fondés sur l'utilisation d'un service particulier de la classe RTAmbassador, appelé EvokeCallback() ou EvokeMultipleCallbacks (). Ces services sont spécifiés dans la famille des services supprt.

En simplifiant, lorsqu'un fédéré invoque le service EvokeCallback()136, il donne la main à la RTI qui peut alors invoquer les callbacks selon les abonnements déclarés du fédéré.

136 Pour simplifier, nous n’aborderons pas le service EvokeMultipleCallbacks().


Cependant, lorsqu'un fédéré utilise les services de gestion du temps en mode coordonné, les spécifications sont très claires. En supposant que le fédéré demande une avance dans le temps à une date T par invocation du service TimeAdvanceRequest(T), les spécifications assurent que lorsque la RTI accordera cette avance en invoquant le callback TimeAdvanceGrant(), tous les messages intéressant le fédéré auront été préalablement répercutés par la RTI. Et c'est notamment le cas pour les messages TSO. Ainsi, l'avance dans le temps est toujours précédée par le traitement des messages qui intéressent le fédéré. L'utilisation du service EvokeCallback() ne pose alors aucune difficulté. Elle est illustrée par l'algorithme suivant :

Tant que (non fin_simulation)

{

avance = FAUX ;

TimeAdvanceRequest(date_courante + STEP) ;

Tant que (avance = FAUX)

EvokeCallback();

Poursuivre la simulation ;

}

L'algorithme du callback TimeAdvanceGrant() est alors évident :

TimeAdvanceGrant()

{

avance = VRAI ;

}

Un dernier point important concernant la gestion des callbacks et l'avance dans le temps est énoncé par la règle suivante : les messages RO ne peuvent être délivrés que pendant une demande d'avance dans le temps du fédéré, par un TimeAdvanceRequest() ou un NextMessageRequest(). Dans certains cas, ce mécanisme peut s'avérer problématique. Il est alors indispensable pour le fédéré d'invoquer la méthode EnableAsynchronousDelivery() afin que la RTI répercute les messages RO même en l'absence d'une demande d'avance dans le temps.

7.3.9 Le document FDD

Il s’agit en fait d’un document (schéma XML137) constituant le sous ensemble minimum du FOM indispensable pour exécuter une fédération et devant être interprété par toute RTI (close normative).

C'est dans ce document que sont définies la politique de transport (reliable ou best_effort) et la méthode d'ordonnancement par défaut, soit de chaque attribut d'une classe d'objets, soit de tous les paramètres d'une classe d'interactions (receive ou timestamp). Ce fichier est utilisé par la RTI pour vérifier la cohérence du nommage des données partagées par la fédération. Ainsi, chaque fois qu'un fédéré demande le handle d'une classe, d'un paramètre ou d'un attribut, la RTI vérifie l'existence du nom dans le document FDD.

7.3.10 Déclinaison des spécifications d’interface sur les langages de programmation

Les services HLA sont spécifiés dans les documents normatifs de manière indépendante à tout langage de programmation. Le chapitre 12 du document normatif [A2] fournit néanmoins des règles d’implémentation pour :

137 Schéma disponible sur http://standards.ieee.org/downloads/1516/1516.1-2010/IEEE1516-FDD-2010.xsd.


la représentation et la sémantique des temps logique, lookahead et estampilles temporelles,

les types de données,

le service « Connect »,

la concurrence et la réentrance,

La compatibilité dynamique à l’édition de liens138 [A15],

Les API Java139, C++140 et les Web services141 en WSDL142

138 Dynamic Link Compatibility. 139 http://standards.ieee.org/downloads/1516/1516.1-2010/IEEE1516-2010_Java_API.zip. 140 http://standards.ieee.org/downloads/1516/1516.1-2010/IEEE1516-2010_C++_API.zip. 141 http://standards.ieee.org/downloads/1516/1516.1-2010/hla1516e.wsdl. 142 Web Service Definition Language.


7.4 Annexe D : Migration de fédérés US DoD 1.3 vers la norme IEEE 1516-2010

7.4.1 Introduction Cette annexe constitue une synthèse d’un document rédigé par l’équipe de Pitch [B40]. Sa lecture nécessite la connaissance préalable du corps du guide ainsi que des annexes 0 (différences entre la norme IEEE 1516-2000 et la norme US DoD 1.3) et 0 (apports de la norme IEEE 1516-2010 à la norme IEEE 1516-2000). La première étape de cette migration consiste à savoir si certaines nouvelles fonctionnalités des normes IEEE 1516-(2000 et 2010) sont intéressantes (annexes 0 et 0). Au cours de la seconde étape, le format du FOM doit être traduit en XML143. Le FOM peut ensuite si nécessaire, constituer un module FOM. La 3ème étape consiste à migrer le code source vers la nouvelle API, en vérifiant sa compatibilité avec la sémantique des services à la norme IEEE 1516-2010. Enfin, la dernière étape évidente consiste à tester le bon fonctionnement de la fédération en utilisant une RTI compatible avec la norme.

7.4.2 Quelques exemples de migration avec l’API C++144

7.4.2.1 Création d’une fédération et participation du fédéré

Le code source à la norme US DoD 1.3 devrait ressembler à ceci145 :

RTIambassador rtiAmbassador; rtiAmbassador = getRTIambassador("localhost", 8989); rtiAmbassador.createFederationExecution("MyFederation", "MyFDD.fed"); FederateHandle federateHandle = rtiAmbassador.joinFederationExecution(

"MyFederateType", "MyFederation", this);

Le code source à la nome IEEE 1516-2010 devient :

auto_ptr<RTIambassador> rtiAmbassador; auto_ptr<RTIambassadorFactory> rtiAmbassadorFactory( new RTIambassadorFactory()); rtiAmbassador = rtiAmbassadorFactory->createRTIambassador(); wstring localSettingsDesignator(L"crcHost="+ host + L"\n" + L"crcPort="+ port); rtiAmbassador->connect(*this, HLA_IMMEDIATE, localSettingsDesignator); vector<wstring> FOMmoduleUrls; FOMmoduleUrls.push_back(L"MyEvolvedFOM.xml"); rtiAmbassador->createFederationExecution(L"MyFederation", FOMmoduleUrls); FederateHandle federateHandle = rtiAmbassador->joinFederationExecution(

L"MyFederateName", L"MyFederateType", L"MyFederation");

Les différences entre les 2 versions du même code sont les suivantes : 143 Des outils automatiques de traduction existent comme Pitch Visual OMTTM 2 existent. 144 Des exemples avec l’API Java sont décrits dans [B40]. 145 En supposant que la classe qui contient ce code spécialise la classe FederateAmbassador.


Le RTIambassadorFactory est utilisé pour créer l’instance RTIambassador.

Utilisation du type wstring au lieu de string.

Lors de l’invocation du Connect, une chaîne de caractères appelée Local Settings Designator est passé en paramètres. Cette chaîne décrit les valeurs par défaut utilisées à la connexion avec la RTI146.

Le Connect reçoit en argument une valeur positionnée dans l’exemple à HLA_IMMEDIATE qui signale que les « callbacks » vont être reçus immédiatement sans évocation du service EvokeMultipleCallbacks. Dans le cas contraire, il faut positionner l’argument à la valeur HLA_EVOKED.

Le service «createFederationExecution» reçoit en argument un tableau (vector) de FOMs.

7.4.2.2 Publications, abonnements et gestion des handles

L’obtention du handle d’une classe d’interaction à la norme US DoD 1.3 nécessite le code C++ suivant :

InteractionClassHandle iHandle; ParameterHandle pHandle; iHandle = rtiAmbassador.getInteractionClassHandle("MyInteraction"); pHandle = rtiAmbassador.getParameterHandle("MyParameter", iHandle);

A la norme IEEE 1516-2010, ce code devient :

InteractionClassHandle iHandle; ParameterHandle pHandle; iHandle = rtiAmbassador->getInteractionClassHandle(L"MyInteraction"); pHandle = rtiAmbassador->getParameterHandle(iHandle, L"MyParameter");

La seule différence réside dans l’ordre de passage des paramètres dans le service « getParameterHandle ». Pour des handles de classes d’objets et d’attributs, le code à la norme US DoD 1.3 est :

ObjectClassHandle cHandle; AttributeHandle aHandle; cHandle = rtiAmbassador.getObjectClassHandle("MyObject"); aHandle = rtiAmbassador.getAttributeHandle("MyAttribute", cHandle);

Le code correspondant à la norme IEEE 1516-2010 est :

ObjectClassHandle cHandle; AttributeHandle aHandle; cHandle = rtiAmbassador->getObjectClassHandle("MyObject"); aHandle = rtiAmbassador->getAttributeHandle(cHandle, L"MyAttribute");

146 La valeur crcHost=192.168.1.20\ncrcPort=8989 est spécifique de la RTI pRTI de Pitch.


La seule différence réside dans l’ordre de passage des paramètres dans le service « getAttributeHandle ». Le code suivant permet de réaliser les publications et abonnements à la norme US DoD 1.3 :

AttributeHandleSet* attributeList = AttributeHandleSetFactory::create(1); attributeList->add(aHandle); rtiAmbassador.publishObjectClass(cHandle, attributeList); rtiAmbassador.subscribeObjectClassAttributes(cHandle, attributeList);


AttributeHandleSet attributeList; attributeList.insert(aHandle); rtiAmbassador->publishObjectClassAttributes(cHandle, attributeList); rtiAmbassador->subscribeObjectClassAttributes(cHandle, attributeList);

On notera que le service « publishObjectClass » s’appelle désormais « publishObjectClassAttributes ».

7.4.2.3 Gestion des interactions Le code pour émettre une interaction à la norme US DoD 1.3 est le suivant :

ParameterHandleValuePairSet* parameters = ParameterSetFactory::create(1); ParameterHandle pHandle; InteractionClassHandle iHandle; char msg[256] = "message to send"; iHandle = rtiAmbassador.getInteractionClassHandle("MyInteraction"); pHandle = rtiAmbassador.getParameterHandle("MyParameter", iHandle); parameters->add(pHandle, msg, strlen(msg) + 1); rtiAmbassador.sendInteraction(iHandle, *parameters, 0);


wstring wmsg = L"message to send"; InteractionClassHandle iHandle; ParameterHandle pHandle; ParameterHandleValueMap pHandleValueMap; iHandle = rtiAmbassador->getInteractionClassHandle(L"MyInteraction"); pHandle = rtiAmbassador->getParameterHandle(iHandle, L"MyParameter"); HLAunicodeString unicodeMessage = HLAunicodeString(wmsg); pHandleValueMap[pHandle] = unicodeMessage.encode(); rtiAmbassador->sendInteraction(iHandle, pHandleValueMap, VariableLengthData());

Le type « HLAunicodeString » permet d’encoder la valeur du paramètre en tableau d’octets. Le code suivant permet au fédéré de recevoir une interaction à la norme US DoD 1.3 :

void receiveInteraction (InteractionClassHandle theInteraction, const ParameterHandleValuePairSet& theParameters,


const char *theTag) { if (theInteraction == iHandle) {

char* message = ""; ULong length; for (unsigned int i = 0; i < theParameters.size(); ++i) {

if (theParameters.getHandle(i) == pHandle) { message = theParameters.getValuePointer(i, length);

} cout << "Message: " << message << endl;

} }

Ce qui, à la norme IEEE 1516-2010, devient :

virtual void receiveInteraction (InteractionClassHandle theInteraction,

ParameterHandleValueMap const & theParameterValues, VariableLengthData const & theUserSuppliedTag, OrderType sentOrder, TransportationType theType, SupplementalReceiveInfo theReceiveInfo) {

if (theInteraction == iHandle) { HLAunicodeString message; for (ParameterHandleValueMap::const_iterator i =

theParameterValues.begin(); i != theParameterValues.end(); ++i) {

ParameterHandle const & handle = i->first; VariableLengthData const & value = i->second; if (handle == pHandle) {

message.decode(value); }

} wcout << "Message: " << wstring(message) << endl;

} }

On notera que le callback admet des paramètres supplémentaires comme le type de transport. L’argument «SupplementalReceiveInfo » permet d’avoir des informations sur le fédéré qui émet l’interaction et sur les régions si les services de la DDM sont utilisés147. Le type « ParameterHandleValueMap » issue de la STL standard est un iterateur. La méthode « decode » permet de transformer un « HLAunicodeString » en un « wstring ».

7.4.2.4 Gestion des objets

Le code suivant permet d’enregistrer une instance de classe d’objet à la norme US DoD 1.3 :

ObjectClassHandle cHandle; char objectName[32] = "myObjectInstance"; cHandle = rtiAmbassador.getObjectClassHandle("MyObject"); rtiAmbassador.registerObjectInstance(cHandle, objectName);

147 Ce paramètre est à NULL si la DDM n’est pas utilisée.


Le dual à la norme IEEE 1516-2010 en utilisant un nom réservé d’objet est :

ObjectClassHandle cHandle; wstring objectName = L"myObjectInstance"; rtiAmbassador->reserveObjectInstanceName(objectName); /* Waiting for objectInstanceNameReservationSucceeded or objectInstanceNameReservationFailed callbacks and setting the nameReservation flag to true or false */ wait(nameReservation); if (nameReservation) {

cHandle = rtiAmbassador->getObjectClassHandle(L"MyObject"); rtiAmbassador->registerObjectInstance(cHandle, objectName);

} Les différences entre les 2 versions de code sont les suivantes : Dans la norme US DoD 1.3, le service « registerObjectInstance » est synchrone (bloquant) alors

que dans la norme IEEE 1516-2010, il est asynchrone. Il est possible de réserver un nom ou bien de laisser cette opération à la charge de la RTI. Dans ce

cas, le code pour enregistrer une instance de classe d’objet devient :

cHandle = rtiAmbassador->getObjectClassHandle(L"MyObject"); rtiAmbassador->registerObjectInstance(cHandle);

A la norme US DoD 1.3 la signature du callback est :

void discoverObjectInstance (ObjectHandle theObject, ObjectClassHandle theObjectClass, const char * theObjectName)

ce qui devient avec la norme IEEE 1516-2010 :

void discoverObjectInstance (ObjectInstanceHandle theObject, ObjectClassHandle theObjectClass, std::wstring const & theObjectInstanceName)

Pour mettre à jour un attribut à la norme US DoD 1.3, on utilise le code suivant :

AttributeHandeValuePairSet* attrValueList = AttributeSetFactory().create(1); char update[256] = "new value"; attrValueList.add(aHandle, update, sizeof(update) + 1); updateAttributeValues(objectInstanceId, attrValueList, 0);

ce qui devient : wstring update = L"new value"; ObjectClassHandle cHandle; AttributeHandle aHandle; AttributeHandleValueMap aHandleValueMap; cHandle = rtiAmbassador->getObjectClassHandle(L"MyObject"); aHandle = rtiAmbassador->getAttributeHandle(cHandle, L"MyAttribute"); HLAunicodeString unicodeUpdate = HLAunicodeString(update);


aHandleValueMap[aHandle] = unicodeUpdate.encode(); rtiAmbassador->updateAttributeValues(objectInstanceHandle, aHandleValueMap, VariableLengthData());

Dans cette version, il faut noter l’utilisation du type « HLAUnicodeString » au lieu d’une simple chaîne de caractères. Le callback « reflectAttributeValues » et le service « provideAttributeValueUpdate » s’écrivent comme suit avec la norme US DoD 1.3 :

Void reflectAttributeValues (ObjectHandle theObject, const AttributeHandleValuePairSet& theAttributes, const char *theTag)

provideAttributeValueUpdate (ObjectHandle theObject,

const AttributeHandleSet& theAttributes)

ce qui devient à la norme IEEE 1516-2010 :

void reflectAttributeValues (ObjectInstanceHandle theObject, AttributeHandleValueMap const & theAttributeValues, VariableLengthData const & theUserSuppliedTag, OrderType sentOrder, TransportationType theType, SupplementalReflectInfo theReflectInfo)

void provideAttributeValueUpdate (ObjectInstanceHandle theObject, AttributeHandleSet const & theAttributes, VariableLengthData const & theUserSuppliedTag)

Notons la présence de paramètres supplémentaires dans le callback « reflectAttributeValues » et la présence d’un tag dans le service «provideAttributeValueUpdate ».

7.4.2.5 Abandon de la fédération par le fédéré et destruction de la fédération

A la norme US DoD 1.3, le code est : rtiAmbassador.resignFederationExecution(

DELETE_OBJECTS_AND_RELEASE_ATTRIBUTES); rtiAmbassador.destroyFederationExecution("MyFederation");


rtiAmbassador->resignFederationExecution( CANCEL_THEN_DELETE_THEN_DIVEST);

rtiAmbassador->destroyFederationExecution(L"MyFederation"); rtiAmbassador->disconnect();

7.4.2.6 Modifications supplémentaires

On notera les modifications suivantes entre les 2 normes : Le service « tick() » devient « EvokeCallback » ou « EvokeMultipleCallbacks».


Les exceptions ont changé. Il existe en particulier une exception « NotConnected » indiquant au fédéré qu’il a perdu la connexion avec la fédération. Dans ce cas, la RTI a également invoqué le callback « ConnectionLost»

7.4.2.7 Conclusion

Au cours de la migration d’un fédéré US DoD 1.3 vers la norme IEEE 1516-2010, il faut d’abord se préoccuper des modifications dans la sémantique de certains services. En particulier, les abonnements et publications sont additifs, la DDM a subi d’importantes révisions et la nouvelle norme offre des services de tolérance aux fautes. Enfin, les API C++ et Java à la norme IEEE 1516-2010 sont compatibles à l’édition des liens ce qui résout la plupart des problèmes de compatibilité d’un fédéré à des RTI différents.


7.5 Annexe E : Les différences entre la norme IEEE 1516-2000 et la norme US DoD 1.3

Dans ce chapitre, nous proposons de présenter les différences majeures entre la norme US DoD 1.3 et la norme IEEE 1516-2000.

7.5.1 Introduction

Rappelons que la norme HLA US DoD 1.3 décrit les responsabilités des fédérés et des fédérations par un ensemble de règles, 5 pour les fédérés et 5 pour les fédérations. Ces règles furent rapidement considérées comme claires, valides et nécessaires, et restent donc inchangées dans la norme IEEE 1516-2000, puis la norme IEEE 1516-2010. En contrepartie, un effort important fût nécessaire pour clarifier la description textuelle de l'architecture HLA, afin de supprimer les ambiguïtés et les contresens, et plus généralement de produire une description correcte et cohérente de l'architecture HLA. La plus importante évolution fût d'associer une sémantique propre aux définitions et aux acronymes communs à l'ensemble des spécifications HLA (architecture et règles, spécifications d'interface et OMT). En ce qui concerne les règles, par exemple, une annexe (Rationale Annex) a été introduite, afin de décrire avec une plus grande précision, tous les termes permettant de comprendre la signification et la portée de chacune des règles.

Toujours dans un souci de clarification et de cohérence terminologique, une attention particulière fût portée dans la description textuelle de l'architecture. A titre d'illustration, les termes RTI (Runtime Infrastructure) et Spécifications d'Interface étaient indifféremment référencés dans la description. L'utilisation abusive de ces termes ne permettait donc pas de clairement distinguer les aspects spécifications, des aspects implémentation. Un autre exemple est l'utilisation du terme "fédéré" pour décrire certains aspects des spécifications. A partir de la norme IEEE 1516-2000, un fédéré est défini comme l'implémentation d'une simulation, alors que le terme "simulation" est exclusivement utilisé lorsqu'il s'agit de décrire une spécification.

Finalement, un effort soutenu fût engagé pour améliorer la clarté et la concision des documents décrivant l'architecture et les règles HLA. En particulier, une clarification des différences entre l'approche orientée objet soutenue par HLA, et l'approche orientée objet traditionnelle, fût rajoutée dans les spécifications. Rappelons à ce propos que dans les spécifications HLA, l'approche orientée objet ne concerne que l'interface des simulations avec le monde extérieur. En ce sens, aucune hypothèse n'est faite sur les méthodologies de programmation utilisées lors d'une implémentation. En outre, au niveau de la description orientée objet des spécifications d'interface, il existe une différence de fond avec une approche orientée objet conventionnelle, à savoir que dans HLA, les classes d'objets ou d'interactions n'ont pas de comportement (absence de méthodes). Cette particularité est cohérente avec l’esprit de l’architecture, puisque les classes HLA ne concernent que la communication. Les classes « métier » dont le comportement est décrit par un ensemble de méthodes, sont internes au fédéré.

Tous ces efforts de clarification des termes, de concision des descriptions textuelles, et de positionnement des concepts HLA par rapport à des concepts plus traditionnels, proches mais différents, ont permis de produire une documentation mieux structurée et donc mieux adaptée pour faciliter la compréhension de l'architecture elle-même.

7.5.2 Evolution des spécifications d'interface (document IEEE 1516.1-2000)

En ce qui concerne les spécifications d'interface, l'évolution vers la norme IEEE 1516 (2000 ou 2010) se situe davantage sur des améliorations significatives plutôt que sur des bouleversements. Ainsi, les mécanismes de base supportant les communications entre simulations restent inchangés. Il en est ainsi pour les mécanismes de publication/abonnement, enregistrement et découverte d'objets ou d'interactions, et les services de diffusion et de réception de données. Dans la suite de ce paragraphe, nous citons les principales évolutions, classées par familles conformément à la structure du document décrivant les spécifications d'interface.


7.5.2.1 Gestion de la fédération

Trois évolutions sont à retenir au niveau des services de gestion de la fédération :

• L'introduction de 2 nouveaux services permettant à une simulation joignant tardivement une fédération, de prendre connaissance des actions de sauvegarde et/ou de restauration de l'état de la simulation. Ces services Query Federation Save Status et Query Federation Restore Status sont respectivement associés aux callbacks Federation Save Status Response et Federation Restore Status Response.

• Une description plus claire des mécanismes de synchronisation entre fédérés.

• Enfin, une évolution du concept de fichier FED (Federation Execution Data), vers un désignateur de FOM, appelé FDD148 (FOM Document Designator). De ce fait, le service de création d'une fédération nécessite la désignation d'un FOM au lieu d'un fichier FED. Notons également que le format des FOMs et SOMs à partir de la norme IEEE 1516-2000, adopte une description XML.

7.5.2.2 Gestion des déclarations

La principale évolution provient de l'adoption d'une sémantique additive aux services de publication et d'abonnement. Dans la norme HLA US DoD 1.3, toute opération de publication ou d'abonnement à des attributs de classes d'objets ou à des paramètres de classes d'interactions remplace les précédentes opérations. A partir de la norme IEEE 1516-2000, toute publication/abonnement à un ou plusieurs attributs ou paramètres s'ajoute aux opérations de publication ou d'abonnement déjà invoquées. Ainsi les normes IEEE 1516-(2000 et 2010) rendent les 2 opérations séquentielles :

Publication à l'attribut X de la classe C ;

Publication à l'attribut Y de la classe C ;

et l'opération :

Publication aux attributs X et Y de la classe C ;

strictement équivalentes.

Dans la norme US DoD 1.3, l'invocation de manière séquentielle aux services de publication ci-dessus conduit à remplacer la publication de l'attribut X par la celle de l'attribut Y. Cette modification sémantique améliore la réutilisation des simulations en permettant de faire évoluer les publications et abonnements selon les besoins, sans détruire ceux déjà existants. Par souci de cohérence avec cette sémantique, les opérations d'abonnement à des attributs de classes, avec régions, opérations utilisées pour les services de la DDM (Data Distribution Management), sont également additives.

7.5.2.3 Gestion des objets

Une évolution majeure consiste à rendre toute référence (handle ou nom) à une instance de classe, unique pendant l'exécution d'une fédération. Ce point est très important car les spécifications de la norme US DoD 1.3 manquaient de clarté sur ce point, l'unicité n'étant garantie qu'au niveau d'un fédéré. Ainsi, certaines implémentations sous forme de RTI fournissaient pour le même objet, des handles différents à des fédérés différents. Plus précisément, le handle délivré au fédéré F1 lors de l'enregistrement d'une instance de classe pouvait être différent de celui délivré au fédéré F2 lors de la découverte du même objet. La cohérence des handles était néanmoins assurée au sein d'un même fédéré. Par contre, il était impossible d'échanger le handle d'un objet d'un fédéré vers un autre (au travers de la valeur d'un paramètre d'interaction, par exemple), pour désigner une action à réaliser sur un objet particulier.

148 FOM Document Data pour la norme IEEE 1516-2010.


A partir de la norme IEEE 1516-2000, toute implémentation de HLA doit garantir l'unicité du handle d'une instance de classe, mais également de son nom sous forme de chaîne de caractères, lorsque ce nom n'est pas explicitement délivré par le fédéré. Dans le cas où le fédéré fixe un nom à un objet, toute implémentation de HLA doit également vérifier son unicité, et délivrer une exception si cette unicité n'est pas respectée.

7.5.2.4 Gestion de la propriété

Rappelons tout d'abord que la gestion de la propriété ne porte que sur les attributs d'instance d'objets, et non sur les paramètres des classes d'interactions.

Des modifications ont été apportées dans les services de gestion de la propriété des attributs, pour rendre plus symétrique le mécanisme de relâchement de la propriété d'un attribut avec celui de son acquisition. Le principal impact de ces modifications réside dans le renommage du service Attribute Ownership Release Response en Attribute Ownership Divestiture If Wanted. Rappelons que ce service permet à une simulation S1 de confirmer la perte de la propriété d'un ensemble d'attributs d'une instance de classe, suite à la requête Attribute Ownership Acquisition, émise par une simulation distante S2. Cette requête émise par S2 est communiquée à la simulation S1 par le callback Request Attribute Ownership Release.

En outre, le service (callback) Attribute Ownership Divestiture Notification a été remplacé par un protocole en 2 étapes, comprenant le service (callback) Request Divestiture Confirmation et Confirm Divestiture. Rappelons que dans la norme US DoD 1.3, une simulation est prévenue de la perte de propriété d'un ensemble d'attributs par le service Attribute Ownership Divestiture Notification. Dans la norme IEEE 1516-2000, la simulation doit également confirmer la perte de la propriété des attributs concernés.

Enfin, un argument supplémentaire, de type chaîne de caractères, a été ajouté aux services Confirm Divestiture et Attribute Ownership Acquisition Notification. Rappelons que cet argument est offert à l'utilisateur pour ses besoins propres, dans de très nombreux services, et aussi bien dans la norme US DoD 1.3 que dans la norme IEEE 1516-2000. Rappelons également que, quel que soit l'implémentation des spécifications, cet argument de type chaîne de caractères ne doit pas être interprété par la RTI.

7.5.2.5 Gestion du temps

La principale modification consiste à conserver l'estampille temporelle des messages RO (Receive Ordered). Cette estampille est passée en argument du service (callback) notifiant une mise à jour d'une liste d'attributs d'un objet ou de l'ensemble des paramètres d'une interaction. Rappelons, que dans la norme US DoD 1.3, un fédéré régulateur peut envoyer un message estampillé temporellement.

Si le fédéré qui reçoit ce message (après abonnement) est contraint, alors le message est de type TSO (Time Stamp Ordered). Dans le cas contraire, le fédéré destinataire reçoit un message de type RO (Receive Ordered). Dans une implémentation des spécifications, la RTI invoque un service polymorphe (avec ou sans argument véhiculant l'estampille temporelle), selon qu'il s'agit d'un message estampillé ou non. Dans la norme IEEE 1516-2000, l'estampille temporelle est diffusée même dans le cas d'un message RO, c'est-à-dire lorsque le fédéré destinataire n'est pas contraint.

Cette évolution revient à pouvoir diffuser des messages estampillés temporellement, même lorsque les services de gestion du temps ne sont pas utilisés par la simulation. Notons que dans la norme US DoD 1.3, il est toujours possible de communiquer une estampille temporelle associée à un message, même en l'absence de politique de gestion du temps. Il suffit pour cela d'utiliser un attribut de classe ou un paramètre d'interaction supplémentaire.

Une évolution qui impacte sur les simulations HLA existantes, est que les fédérations doivent fournir leurs propres types de données abstraites pour représenter les informations temporelles (estampilles associées aux messages et pas de temps). Les spécifications présentent des exemples de types de données abstraites pour chacun des langages supportés (C++, Java et Ada).


Pour terminer, la sémantique liée à un certain nombre de concepts de nature temporelle a été largement clarifiée, d'un point de vue de sa description textuelle. Cette clarification n'impacte cependant pas les simulations existantes. De même, une dénomination plus riche et plus explicite a été associée à certains termes :

• Le terme LBTS (Lower Bound Time Stamp) a été remplacé par le terme GALT (Greatest Available Logical Time).

• Le terme MNET (Minimum Next Event Time) a été remplacé par le terme LITS (Least Incoming Time Stamp).

• Le terme "événement" a été remplacé par le terme "message".

• Le terme "date de la fédération" a été remplacé par le terme "date logique". Ce dernier point lève une ambiguïté sur l'existence ou non d'une horloge commune à toute la fédération.

7.5.2.6 Gestion de la distribution des données (DDM)

C'est cette famille de services qui a connu le plus grand nombre de modifications et d’améliorations, ce qui ne constitue pas une surprise étant donné la complexité et le manque de clarté de ses spécifications dans la norme US DoD 1.3.

La principale évolution et simplification consiste à n'accepter qu'un seul espace de routage avec un nombre quelconque de dimensions. En outre, le typage des bornes qui permettent de définir les intervalles de valeurs permises, passe d'une représentation flottante à une représentation de type entier fournie par l'utilisateur. Cette évolution du typage des bornes fournit une indication à la RTI sur le nombre de valeurs permises qu'il devra utiliser pour gérer les routages.

L'impact pour les simulations existantes utilisant les services de la DDM consiste à combiner les espaces de routage multiples en un seul et unique espace de routage.

7.5.2.7 Gestion du modèle objet (MOM)

Rappelons que la MOM est constituée d'un ensemble de classes d'objets et de classes d'interactions présentes dans la FOM et le fichier FED, et nécessaires à la RTI. Ces classes supportent les mécanismes de communication permettant aux fédérés d'acquérir des informations sur la fédération par l'intermédiaire de la RTI, ou plus exactement des composants locaux de la RTI, les LRCs (Local RTI Component).

Les évolutions sur la MOM sont à relier aux modifications sur le modèle objet lui-même (OMT) qui sont introduites dans le paragraphe suivant. En outre, un certain nombre d'interactions et d'exceptions ont été rajoutées. Par exemple, l'interaction HLAfederate.HLAreport.HLAMOMalert est envoyée par la RTI pour signaler qu'un fédéré a émis une interaction appartenant à la MOM, avec une erreur sur le nombre de paramètres. Une modification supplémentaire réside dans la possibilité d'utiliser conjointement les services de la DDM et la MOM, ce qui permet de mieux contrôler les échanges des données de la MOM.

7.5.2.8 Services support

Les modifications sur les spécifications des services support portent essentiellement sur une clarification des fonctionnalités offertes par ces services, et le rajout ou la modification de certains services liés à l'évolution des spécifications de la DDM (Data Distribution Management). En ce qui concerne la DDM, les services Get Dimension Upper Bound, Get Dimension Handle Set et Get/Set Range Bounds ont été modifiés ou rajoutés. Enfin, de nouveaux services ont été introduits pour supporter les opérations d'initialisation/terminaison des fédérés, ainsi que les interactions entre les fédérés et la RTI. Ces services sont Initialize RTI Services, Finalize RTI Services149, Evoke (Multiple) Callbacks(s), Enable/Disable Callbacks.

149 Ils ont disparus dans la norme IEEE 1516-2010.


7.5.2.9 Evolutions générales supplémentaires

Quelques modifications générales ponctuelles, mais sans impact majeur sur les applications à la norme US DoD 1.3, ont également été introduites : par exemple, un argument supplémentaire de type chaîne de caractères a été introduit dans le service Request Attribute Value Update et le callback associé Provide Attribute Value Update.

7.5.3 Evolution du modèle objet OMT (document IEEE 1516.2-2000)

Rappelons que l'OMT normalise la structure et le format de description des informations contenues dans les SOMs et FOMs HLA. En ce sens, il facilite une compréhension commune des échanges de données entre un fédéré et le monde extérieur, ainsi que les échanges de données au sein d'une même fédération.

Pratiquement, l'OMT de HLA fournit une structuration des informations contenues dans les SOMs et FOMs, sous la forme d'un ensemble de tables et d'un lexique. Rappelons enfin qu'il existe un outil d'édition de ces tables sous une forme graphique qui est OMDT (Object Model Development Tool). Cet outil, développé par la société AEgis, existe sous la norme US DoD 1.3, sous SunOS et Windows, ainsi que sous la norme IEEE 1516-2000, sous Windows uniquement. Ces 2 versions d’OMDT sont gratuites, alors que la version OMDTPro est un outil commercial offrant également des fonctionnalités de génération de code.

C'est bien l'OMT qui a subi les modifications les plus profondes lors du passage à la norme IEEE 1516-2000 de HLA. En outre, il n'est pas exclu que ce processus de normalisation ne soit pas définitivement terminé, et que l'on s'oriente à terme vers des normes comme UML ou XML.

L'évolution de l'OMT de la norme US DoD 1.3 vers la norme 1516-2000 se traduit par des modifications, des suppressions ou l'introduction de nouvelles tables.

7.5.3.1 Modifications de tables existantes

Les modifications concernent les tables suivantes :

• La table d'identification du modèle objet qui décrit les informations générales relatives au fédéré ou à la fédération (Nom, Version, Point de Contact, …) a été modifiée par ajout de 2 nouvelles lignes contenant des références éventuelles et toute information utile à la réutilisation.

• La classe racine (HLAobjectRoot) de toute hiérarchie de classes d'objets HLA apparaît maintenant de manière explicite dans la table de la structure des classes. Dans la norme US DoD 1.3, cette classe racine apparaissait dans le fichier FED, mais pas dans les SOMs ou FOMs.

• Dans la table des attributs, l'attribut HLAprivilegeToDeleteObject de la classe racine HLAobjectRoot apparaît également de manière explicite. Les colonnes "Cardinality", "Units", "Resolution", et "Accuracy" ont été supprimées. Ces informations sont consignées maintenant dans de nouvelles tables décrivant les types de données. De même, la colonne "Accuracy Condition" a été supprimée. Pour assurer la cohérence avec l'évolution des spécifications d'interface, la colonne "Routing Space" a été remplacée par la colonne "Available Dimensions" (évolution de la DDM), la colonne "T/A" (Transfert/Accept) a été remplacée par "D/A" (Divest/Acquire), et la colonne "U/R" (Updatable/Reflectable) a été remplacée par la colonne "P/S" (Published/Subscribed). Pour terminer, 2 nouvelles colonnes apparaissent dans la table, la première décrivant le mode de transport des attributs (reliable ou best-effort), et la seconde l'ordre de diffusion des nouvelles valeurs des attributs au fédéré (TSO ou RO).

• De même que pour les attributs de classes d'objets, la classe racine HLAinteractionRoot apparaît explicitement dans la première colonne de la table des classes d'interactions. Dans cette même table, les désignateurs I/S/R (Initiates/Senses/React) ont été remplacés par P/S (Publish/Subscribe).


• Les modifications effectuées dans la table des paramètres sont analogues à celles décrites pour la table des attributs. Les colonnes "Cardinality", "Units", "Resolution", "Accuracy" et "Accuracy Condition" ont été supprimées. La colonne "Routing Space" a été remplacée par la colonne "Available Dimensions". Enfin, 2 nouvelles colonnes, "Transportation" et "Order", ont été introduites pour décrire le mode de transport des paramètres (reliable ou best-effort), et l'ordre de diffusion des valeurs (TSO ou RO).

7.5.3.2 Introduction de nouvelles tables

Les nouvelles tables introduites dans l'OMT sous sa version normalisée concernent essentiellement le typage des données des objets HLA, en rappelant que ces types de données ne doivent pas être nécessairement utilisés dans les applications elles-mêmes, c'est-à-dire dans l'implémentation même d'un modèle au sein d'un fédéré.

• La table de représentation des données de base permet de décrire les types de base à partir desquels tous les autres types seront décrits. Cette table est composée de 5 colonnes décrivant respectivement, le nom du type, sa taille en bits, son interprétation, sa représentation (Big ou Little Endian), et enfin son encodage. A titre d'illustration, on peut décrire le type HLAinteger16BE, dont la taille est de 16 bits, son interprétation est un entier appartenant à l'intervalle [-215, 215-1], représenté en "Big Endian" et dont l'encodage est du type entier signé 16 bits en complément à 2 (le bit de poids fort représentant le signe). Bien entendu, la plupart des types de base concernant les entiers, flottants et caractères, sont pré chargés, et n'ont pas à être définis par l'utilisateur. La nouveauté intéressante de cette table réside dans l'apparition du "data marshalling". Ainsi, même si cet aspect continue d'être ignoré du point de vue des spécifications d'interface, le concepteur d'une fédération sait, lors de la réutilisation d'un fédéré, si une donnée est codée en "Big Endian" ou en "Little Endian".

• La table des types de données simples permet d'associer un ensemble d'informations aux données de base définies dans la table précédente. Dans cette table, chaque type est défini par son nom, sa représentation (une entrée dans la table de représentation des données de base), les unités, la résolution, la correction, et la sémantique. Par exemple, on peut définir le type simple HLAASCIIchar dont la représentation de base est HLAoctet, et dont la sémantique est du type caractère ASCII Standard (ANSI Std. X3.4-1986). Cette table permet donc de définir des types utilisateur à partir des types de base définis dans la table précédente.

• La table des types énumérés permet de décrire toutes les données dont l'ensemble des valeurs discrètes est fini. Dans cette table, chaque type énuméré est décrit par son nom, sa représentation (une entrée dans la table de représentation des données de base), l'ensemble des valeurs possibles (symboliques et numériques), et enfin sa sémantique. Par exemple, on peut décrire le type énuméré HLAboolean, représenté par un HLAinteger32BE, dont les valeurs possibles sont HLAfalse (0) ou HLAtrue (1), et dont la sémantique est le type booléen normalisé.

• La table des types de données tableaux capture la description des types de données contenant un ensemble indexé de valeurs de même type. Chaque entrée dans la table est décrite par le type des éléments, l'arité, le type d'encodage et la sémantique. On peut par exemple, définir le type HLAASCIIstring, dont le type des éléments est HLAASCIIchar, l'arité n'est pas fixe, mais dynamique, et dont la sémantique correspond à une chaîne de caractères ASCII.


• 2 tables permettent ensuite de décrire les types de données complexes composées de plusieurs champs (structures). La première est relative aux types dont le nombre de champs et leur type sont fixes, et la seconde aux types de données complexes, dont les types des champs peuvent dépendre de la valeur d'un discriminant. Pour chaque table, la sémantique du type de données complexes ainsi que celle du type de chaque champ doivent être décrites. Il en est de même pour le nom de chaque champ, son type et sa sémantique. Pour la table des types de données complexes à types de champs variables, il faut également décrire le discriminant (nom, type et liste des énumérations), ainsi que la liste des alternatives (nom, type et sémantique), une alternative étant associée à chaque énumérateur.

Outre ces nouvelles tables permettant de décrire les types des données HLA, 6 tables supplémentaires ont été introduites :

• La table des dimensions décrit les caractéristiques des dimensions associées aux interactions ou aux attributs lorsque les services de la DDM (Data Distribution Management) sont utilisés.

• La table de représentation du temps décrit le type de données et la sémantique associés aux estampilles temporelles accompagnant (éventuellement) les messages, ainsi qu'au lookahead.

• La table du type de transport des données (paramètres ou attributs). Il existe 2 types de transport prédéfinis (HLAreliable et HLAbestEffort), mais d'autres types de transport peuvent être introduits par le concepteur. A chaque type de transport est associé une description. Par exemple, utilisation de TCP/IP pour HLAreliable, et d’UDP pour HLAbestEffort. L'objectif de cette table est d'ouvrir HLA vers d'autres protocoles de communication des données.

• La table des "tag" utilisateur qui décrit le type et la sémantique des "tag" utilisateurs lorsque ceux-ci existent. Chaque entrée de cette table (une ligne) correspond à un couple service de la RTI/callback auquel est associé un "tag". Par exemple, le couple Update/Reflect pour la communication d'attributs d'objets, ou bien le couple Send/Receive pour la communication d'interactions. Rappelons que dans la norme US DoD 1.3, un "tag" utilisateur de type chaîne de caractères peut être associé à un certain nombre de services. Ce "tag" n'était pas, et n'est toujours pas interprété par la RTI. La nouveauté, mise à part l'existence même de cette table, est que les "tags" sont maintenant typés par des types utilisateur. Ce ne sont pas nécessairement des chaînes de caractères.

• La table des points de synchronisation qui décrit certains éléments des points de synchronisation. Chaque entrée dans cette table est un label utilisé dans la synchronisation en question. 3 colonnes décrivent ensuite chaque label et donc chaque point de synchronisation, par le type du "tag" utilisateur, s'il existe, les capacités du fédéré par rapport à ce point de synchronisation, et enfin, sa sémantique, c'est-à-dire la signification de ce point de synchronisation. La colonne "capacités" n'est applicable que pour les fédérés et donc pour les SOMs.

• La table des "switch" qui décrit la valeur initiale de chaque "switch", en général armé ou désarmé. Rappelons que les "switch" permettent de contrôler certaines fonctions de la RTI. La valeur de chaque "switch" peut être modifiée pendant l'exécution d'une fédération, par une interaction de la MOM appelée HLAmanager.HLAfederation.HLAadjust.HLAset Switches. Ces "switchs" sont surtout utiles lorsqu'un fédéré fait appel aux services de la MOM.

7.5.3.3 Suppression de tables existantes

3 tables de l'OMT de la norme US DoD 1.3 ont été supprimées. Les informations contenues dans les 2 premières, la table des types énumérés et des types complexes, se retrouvent dans la table des types des données. La table des espaces de routage a été remplacée par la table des dimensions, l'espace de routage étant unique dans les spécifications d'interface IEEE 1516-2000.


7.5.3.4 Conclusion

Mise à part une structuration plus claire de l'ensemble des tables, l'évolution majeure de l'OMT de la norme IEEE 1516-2000 réside dans un typage plus libre et plus fort des données HLA. Un élément important est l'apparition du "data marshalling" des données, qui facilite la réutilisation des fédérés sur des plates-formes hétérogènes. Dans la conception d'une fédération, cette information permet de faire appel aux fonctions de conversion adéquates offertes par le langage d'implémentation des fédérés.

7.5.4 Evolution du modèle d'exécution

Le terme "modèle d'exécution" désigne ici les mécanismes de partage des ressources entre les différents processus informatiques participant à l'exécution d'une fédération HLA, essentiellement les fédérés et les composants de la RTI. Au niveau des spécifications HLA, il n'existe aucune référence au modèle d'exécution, puisque les caractéristiques de ce modèle dépendent étroitement des choix d'implémentation des spécifications HLA, sous forme de RTIs. De même, le modèle d'exécution n'est pas caractérisé par l'API d'un langage cible. Cependant, certaines spécifications peuvent avoir un impact sur le modèle d'exécution sous-jacent, et donc sur les fédérés déjà existants.

Ainsi, dans la norme US DoD 1.3, le service tick() avec ou sans paramètres ne figure pas dans la liste des spécifications HLA. Cependant, il joue un rôle majeur dans le modèle d'exécution d'une simulation. En effet, il permet de relâcher la ressource CPU allouée au fédéré au service du composant local de la RTI (LRC). Dans la norme US DoD 1.3, un fédéré invoque le service tick() chaque fois qu'il souhaite recevoir des callbacks de la part de son LRC. Soulignons que dans la documentation accompagnant les versions successives des RTIs 1.3 ou NG du DMSO, l'utilisation du service tick() n'est éclairée par aucune considération méthodologique. La seule recommandation formulée est qu'un fédéré doit invoquer ce service aussi souvent que possible, et chaque fois qu'il désire recevoir des messages par l'invocation de ses callbacks par le LRC. De même, le choix entre l'utilisation du service tick() avec ou sans paramètres ne peut se faire qu'à partir d'une caractérisation précise des applications et d'une étude d'évaluation de performances.

Le modèle d'exécution supporté par le service tick() de la norme US DOD 1.3 et les recommandations de son utilisation souffrent d'un certain nombre d'inconvénients :

• La combinaison des 2 fonctions (relâchement de la ressource CPU et nécessité de recevoir des callbacks) dans un même et unique service est discutable. En effet, le rôle du composant local de la RTI (LRC) est à la fois d'invoquer les callbacks de son fédéré, mais également de recevoir des informations issues des autres LRCs de la fédération, et de les traiter (par exemple, trier les messages estampillés). Ainsi, il peut être intéressant pour un fédéré d'accorder de la ressource de calcul à son LRC, sans pour autant être disposé à recevoir des callbacks.

• Le service tick() sous-tend un modèle de type "polling", dans lequel le fédéré est incapable de savoir à quel moment son LRC nécessite la ressource d'exécution.

La norme IEEE 1516-2000 sépare les 2 fonctions accordées au tick() de la norme US DoD 1.3 grâce au service Evoke Callback, qui existe également sous les 2 formes du tick(), c'est-à-dire avec et sans paramètres temporels. Ce service permet au fédéré de demander l'invocation de callbacks de la part de son LRC lorsque le fédéré est prêt à les recevoir. Le modèle d'exécution supporte également la notion de fédéré "multi-threaded", dans lequel un flot d'exécution (ou thread) est créé afin de permettre l'appel asynchrone de callbacks. Par contre, il faut insister sur le fait qu'aucune caractérisation du modèle d'exécution n'apparaît au niveau des spécifications elles-mêmes. Il s'agit d'un problème d'implémentation qui doit être considéré lors de la conception de la RTI.

Dans le cas où le modèle d'exécution accepte des fédérés "multi-threaded", l'impact de la norme IEEE 1516-2000 sur les fédérés existants est le suivant : toute invocation au service tick() destiné à recevoir des callbacks doit être remplacé par un appel au service Evoke Callback ; toute invocation au service tick() destiné au contraire à fournir de la ressource de calcul à la RTI locale, peut être supprimée.

Un exemple typique d'appel au service tick() destiné à recevoir des callbacks est donné par l'invocation du service Time Advance Request lorsque le fédéré demande à la RTI l'autorisation d'avancer sa date


logique. Dans les simulations traditionnelles, le fédéré déroule ensuite une attente active sur la réception du callback Time Advance Grant, et n'effectue aucune opération tant que sa demande n'a pas été accordée. Dans ce cas, le service Evoke Callback doit remplacer le service tick().

7.5.5 Evolution de l'API C++ de la RTI

De nombreuses modifications ont été apportées au niveau de l'API de la RTI dans les 3 langages cibles (C++, Java et Ada), en sachant que l'API IDL a été supprimée. Dans ce paragraphe nous aborderons exclusivement l'API C++.

A titre d'information préliminaire, la première implémentation des spécifications HLA 1516-2000, sous forme de RTI, fût le pRTI 1516 développé par la société Pitch AB (http://www.pitch.se/). Il s'agit d'une RTI écrite en langage Java avec une API Java, pour plate-formes Windows NT/2000/XP/Vista, Red Hat Linux et Sun Solaris. Une API C++ (sous forme de binding) sous Windows et Linux fût également élaborée.

7.5.5.1 Le fichier "header file" et les fichiers "include"

La première modification d'importance est le fichier RTI.hh qui a été remplacé par le fichier RTI_1516.h. Dans l'API C++ 1516, il n'est pas nécessaire d'inclure au niveau applicatif l'ensemble de l'API. Par contre, pour faciliter la migration des applications existantes, le fichier RTI_1516.h, équivalent du fichier RTI.hh, a été conservé.

Dans la version à la norme US DoD 1.3 de ce fichier, on définit une classe RTI, au sein de laquelle sont définies 2 classes, la classe FederateAmbassador et la classe RTIambassador. Dans la version 1516, le "header file" est plus clair, puisqu'il inclut directement un fichier appelé "RTI_FederateAmbassador.h" définissant l'interface abstraite de la classe RTI_federateAmbassador, et un fichier appelé "RTI_RTIambassador.h" définissant l'interface avec la RTI par la classe RTI_RTIambassador.

N'étant plus nécessaire d'inclure la totalité de l'API, il existe un plus grand nombre de fichiers ".h" dans le catalogue "include". Tous les fichiers qui contiennent le terme "Specific" dans leur nom ont un contenu qui est spécifique de l'implémentation des spécifications d'interface. Il en est ainsi, par exemple, pour les types définis dans le fichier "RTI_SpecificTypedefs.h". Pratiquement, cela signifie que le type FederateHandle de la version à la norme US DoD 1.3, qui est devenu le type RTI_FederateHandle dans la version IEEE 1516-2000, n'est plus nécessairement défini à partir du type C++ "long".

Finalement, les extensions ".hh" des fichiers "include" ont été changées en extensions ".h" car les environnements de développement d'applications Microsoft Visual C++ ne reconnaissent pas toujours les fichiers de type ".hh" comme des fichiers source C++.

7.5.5.2 La classe RTIambassador

En plus des prototypes des méthodes de l'API et des typages des arguments, la principale différence entre la norme US DoD 1.3 et la norme IEEE 1516-2000 réside dans la manière d'instancier la classe RTIambassador.

Dans la norme US DoD 1.3, il suffit de déclarer soit une instance, soit un pointeur sur une instance de la classe RTI_RTIambassador, puis d'invoquer directement les méthodes de cette classe.

Dans l'API 1516, au contraire, il faut d'abord créer une instance de la classe RTI_RTIambassadorFactory, puis invoquer la méthode createRTIambassador de cette classe. Le contenu du fichier RTI_RTIambassadorFactory.h qui définit la classe RTI_RTIambassadorFactory est présenté ci après :

/***********************************************************************

http://www.pitch.se/�


IEEE 1516.1 High Level Architecture Interface Specification C++ API File: RTI_RTIambassador.h ***********************************************************************/ #ifndef RTI_RTIambassadorFactory_h #define RTI_RTIambassadorFactory_h #include <RTI_memory> #include <RTI_vector> #include <RTI_string> class RTI_RTIinternalError; class RTI_RTIambassador; class RTI_RTIambassadorFactory { public: RTI_RTIambassadorFactory(); virtual ~RTI_RTIambassadorFactory() throw (); // 10.35 RTI_auto_ptr< RTI_RTIambassador > createRTIambassador(RTI_vector< RTI_wstring, RTI___STL_DEFAULT_ALLOCATOR(RTI_wstring) > & args) throw (RTI_RTIinternalError); }; #endif // RTI_RTIambassadorFactory_h

Cette approche permet de prendre en compte les spécificités de l'implémentation de la RTI. En particulier, la méthode de création d'un ambassadeur de la RTI au travers de la méthode "createRTIambassador" permet de prendre en compte une implémentation du fédéré avec un seul ou plusieurs flots d'exécution.

7.5.5.3 Les services de l'API C++

Les évolutions ou modifications de la norme IEEE 1516-2000 des spécifications d'interface induisent directement des modifications plus ou moins importantes dans les prototypes des services de l'API.

Par exemple, dans la norme US DoD 1.3, le service de création d'une fédération de la classe RTI_RTIambassador est défini par :

void createFederationExecution ( const char *executionName, // supplied C4 const char *FED) // supplied C4 throw ( FederationExecutionAlreadyExists, CouldNotOpenFED, ErrorReadingFED, ConcurrentAccessAttempted,


RTIinternalError);

Ce même service devient dans le contexte de la norme IEEE 1516-2000 (classe RTI_RTIambassador) :

virtual void createFederationExecution (RTI_wstring const & federationExecutionName, RTI_wstring const & fullPathNameToTheFDDfile) throw (RTI_FederationExecutionAlreadyExists, RTI_CouldNotOpenFDD, RTI_ErrorReadingFDD, RTI_RTIinternalError) = 0;

Même si les noms des services restent inchangés, le typage des arguments a évolué de manière significative, conformément à l'évolution des possibilités de typage introduites dans la norme IEEE 1516-2000. En outre, pour ce service, le nom du fichier FED a été remplacé par le chemin d'accès au fichier FDD qui désigne la FOM de la fédération.

L'exemple suivant illustre davantage les modifications induites par le passage à la norme IEEE 1516-2000. Dans la norme US DoD 1.3, le callback "reflectAttributeValues()" de la classe RTI_RTIfederateAmbassador est défini de manière polymorphe par :

virtual void reflectAttributeValues ( ObjectHandle theObject, // supplied C1 const AttributeHandleValuePairSet& theAttributes, // supplied C4 const FedTime& theTime, // supplied C1 const char *theTag, // supplied C4 EventRetractionHandle theHandle) // supplied C1 throw ( ObjectNotKnown, AttributeNotKnown, FederateOwnsAttributes, InvalidFederationTime, FederateInternalError) = 0; virtual void reflectAttributeValues ( ObjectHandle theObject, // supplied C1 const AttributeHandleValuePairSet& theAttributes, // supplied C4 const char *theTag) // supplied C4 throw ( ObjectNotKnown, AttributeNotKnown, FederateOwnsAttributes, FederateInternalError) = 0;


La différence entre les 2 versions du callback provient de l'existence ou non d'une estampille temporelle associée à la mise à jour d'attributs.

Dans la norme IEEE 1516-2000, les 2 versions du service, dont les prototypes sont présentés ci-dessous, possèdent l'argument "sentOrder" ce qui permet d'offrir l'estampille temporelle qui est toujours présente, conformément à la norme IEEE 1516-2000 des spécifications d'interface.

virtual void reflectAttributeValues (RTI_ObjectInstanceHandle const & theObject, RTI_auto_ptr< RTI_AttributeHandleValueMap > theAttributeValues, RTI_UserSuppliedTag const & theUserSuppliedTag, RTI_OrderType const & sentOrder, RTI_TransportationType const & theType) throw (RTI_ObjectInstanceNotKnown, RTI_AttributeNotRecognized, RTI_AttributeNotSubscribed, RTI_FederateInternalError) = 0; virtual void reflectAttributeValues (RTI_ObjectInstanceHandle const & theObject, RTI_auto_ptr< RTI_AttributeHandleValueMap > theAttributeValues, RTI_UserSuppliedTag const & theUserSuppliedTag, RTI_OrderType const & sentOrder, RTI_TransportationType const & theType, RTI_RegionHandleSet const & theSentRegionHandleSet) throw (RTI_ObjectInstanceNotKnown, RTI_AttributeNotRecognized, RTI_AttributeNotSubscribed, RTI_FederateInternalError) = 0;

La différence entre les 2 versions du callback provient de l'existence ou non de l'argument "theSentRegionHandleSet" qui est relatif à l'utilisation ou non de la DDM.

Le type "RTI_OrderType" qui remplace le type " FedTime" de la norme US DoD 1.3 est défini dans le fichier RTI_OrderType.h, donné ci dessous :

/***********************************************************************


IEEE 1516.1 High Level Architecture Interface Specification C++ API File: RTI_OrderType.h ***********************************************************************/ #ifndef RTI_OrderType_h #define RTI_OrderType_h class RTI_bool; #include <RTI_SpecificConfig.h> #include <RTI_SpecificTypedefs.h> // for RTI_EncodedData #include <RTI_string> // Type safe class used to represent type of data order. class RTI_EXPORT RTI_OrderType { public: RTI_OrderType(RTI_EncodedData const & theEncodedOrderType); RTI_OrderType(RTI_OrderType const & rhs) throw(); static RTI_OrderType const receive() throw(); static RTI_OrderType const timestamp() throw(); RTI_OrderType & operator=(RTI_OrderType const & rhs) throw (); RTI_bool operator==(RTI_OrderType const & rhs) const throw(); RTI_bool operator!=(RTI_OrderType const & rhs) const throw(); RTI_wstring const toString() const; RTI_EncodedData encode() const throw(); private: RTI_OrderType(unsigned orderType)


throw(); unsigned _orderType; }; // These constants save a little typing for users. // They can be used much like a enum, but in a type-safe way RTI_OrderType const RTI_RECEIVE = RTI_OrderType::receive(); RTI_OrderType const RTI_TIMESTAMP = RTI_OrderType::timestamp(); #ifdef RTI_USE_INLINE #include "RTI_OrderType.i" #endif // RTI_USE_INLINE #endif // RTI_OrderType_h

L'estampille temporelle est récupérable par la méthode RTI_OrderType::timestamp(). A la fin du fichier ".h", apparaît une inclusion du fichier "RTI_OrderType.i". Les fichiers suffixés par ".i" contiennent les définitions des méthodes "inline" qui sont développées dans le corps du programme.

7.5.5.4 La librairie C++ standard et son utilisation dans l'API C++, compatible IEEE 1516-2000

L'API C++ a été pensée de manière à pouvoir utiliser la librairie standard C++, par exemple les classes std::wstring, std::vector, std::set. Compte tenu du fait qu'au moment de la réalisation de l'API, tous les compilateurs C++ n'utilisaient pas les librairies standard, les classes de cette librairie standard ont été renommées dans l'API C++, et utilisent le préfixe "RTI_" au lieu de "std::". Le comportement de chaque classe renommée dans l'API C++ est le même que celui de la classe équivalente dans la librairie standard C++. L'objectif est, à court ou moyen termes, de supprimer toutes les classes de l'API préfixées par "RTI_" par les classes équivalentes préfixées par "std::". La migration complète des classes de l'API C++, vers celles de la librairie C++ standard, dépend donc de l'évolution des compilateurs C++.

La STL (Standard Template Library) constitue un sous ensemble important de la librairie standard C++, qui est largement utilisée dans l'API C++. Cette librairie est composée de classes de type "template", classées en 3 types différents : les containers, les itérateurs et les fonctions.

Les containers sont très souvent utilisés dans l'API C++. Par exemple, la classe "RTI_AttributeHandleSet" est définie par "std::set<RTI_AttributeHandle>".

La classe "std::auto_ptr" de la librairie standard C++ est utilisée dans l'API pour la gestion de l'allocation dynamique de la mémoire partagée par les fédérés et la RTI. Cette classe permet de transférer la propriété d'une zone mémoire par affectation ou copie. Ainsi, lors d'une affectation du type :

auto_ptr1 = auto_ptr2

auto_ptr1 acquiert la propriété de la zone mémoire pointée, et auto_ptr2 reçoit la valeur NULL. De même, la libération de l'espace mémoire est gérée par la classe "std::auto_ptr" elle-même, lorsque l'objet devient "hors de portée".

Les mécanismes d'échange et de libération de mémoire partagée entre la RTI et les fédérés sont donc gérés automatiquement par la classe "std::auto_ptr". Un exemple de ce fonctionnement est donné par


le prototype de la méthode "queryGALT()" de la classe "RTI_RTIambassador", qui dans l'API 1516-2000 remplace la méthode "queryLBTS()" de l'API de la norme US DoD 1.3.

virtual RTI_auto_ptr< RTI_LogicalTime > queryGALT () throw (RTI_FederateNotExecutionMember, RTI_SaveInProgress, RTI_RestoreInProgress, RTI_RTIinternalError) = 0;

7.5.5.5 Typage des arguments des méthodes

De manière générale, l'API C++ de la norme IEEE 1516-2000 adopte un typage plus strict des arguments des services de l'API. Par exemple, dans la norme US DoD 1.3, tous les "handles" sont de type identique. Dans l'API C++ de la norme IEEE 1516-2000, tous les arguments sont des instances de classes C++ dotées d'une interface abstraite qui permet au compilateur de détecter des erreurs de typage, au niveau des arguments d'un service, par exemple.

Pour illustrer cette philosophie de typage, prenons l'exemple du service "getAttributeHandle()" qui délivre un "handle" à un attribut d'objet.

Dans la norme US DoD 1.3, le prototype du service est la suivante : AttributeHandle // returned C3 getAttributeHandle ( const char *theName, // supplied C4 ObjectClassHandle whichClass) // supplied C1 throw ( ObjectClassNotDefined, NameNotFound, FederateNotExecutionMember, ConcurrentAccessAttempted, RTIinternalError);

La méthode retourne un handle de type "AttributeHandle", qui est un typedef sur un type "Handle" défini par un "Ulong" dans le fichier "RTItypes.hh".

Dans la norme IEEE 1516, le prototype de cette méthode devient :

Virtual RTI_AttributeHandle const & getAttributeHandle (RTI_ObjectClassHandle const & whichClass, RTI_wstring const & theAttributeName) throw (RTI_InvalidObjectClassHandle, RTI_NameNotFound, RTI_FederateNotExecutionMember, RTI_RTIinternalError) = 0;

Dans ce cas, la méthode retourne un objet de la classe "RTI_AttributeHandle" défini dans le fichier "RTI_SpecificTypedefs.h", par :

typedef RTI_Handle< long, RTI_EncodedData, RTI_AttributeHandleFactory, 5 > RTI_AttributeHandle;

La classe "RTI_Handle" est définie dans le fichier "RTI_Handle.h" par :


/*********************************************************************** IEEE 1516.1 High Level Architecture Interface Specification C++ API File: RTI_Handle.h ***********************************************************************/ #ifndef RTI_Handle_h #define RTI_Handle_h class RTI_bool; #include <RTI_SpecificConfig.h> #include <RTI_string> // The RTIhandle class is used to provide the common interface to the different // RTI handle types used in the API. This interface includes a constructor, // assignment, equality, inequality, and less than operators. The encode method // returns a type safe EncodedHandleClass instance that can be used to exchange // handles between federates as attributes and parameters. The constructor takes // a EncodedHandleClass which enables the type safe creation of a RTIhandle from // encoded data passed to a federate. The template parameter class // ImplementationSpecificHandleClass provides RTI implementations the ability // to customize a private class member for their particular implementation. The // int template type parameter provides the ability to support strong typing. template<class ImplementationSpecificHandleClass, class EncodedHandleClass, class ImplementationSpecificHandleClassFriend, int i> class RTI_EXPORT RTI_Handle { public: explicit RTI_Handle(EncodedHandleClass encodedHandle); ~RTI_Handle() throw(); RTI_Handle(RTI_Handle const & rhs); RTI_Handle & operator=(RTI_Handle const & rhs);


RTI_bool operator==(RTI_Handle const & rhs) const; RTI_bool operator!=(RTI_Handle const & rhs) const; RTI_bool operator< (RTI_Handle const & rhs) const; EncodedHandleClass encode() const; RTI_wstring const toString() const; private: ImplementationSpecificHandleClass _impl; // // This class is the only class which can construct an RTI_Handle // friend ImplementationSpecificHandleClassFriend; RTI_Handle(ImplementationSpecificHandleClass const & impl); }; #ifdef RTI_USE_INLINE #include "RTI_Handle.i" #endif // RTI_USE_INLINE #ifdef RTI_TEMPLATES_REQUIRE_SOURCE #include "RTI_Handle.cpp" #endif // RTI_TEMPLATES_REQUIRE_SOURCE #endif // RTI_Handle_h

Remarquons pour terminer, que l'ordre d'apparition des arguments "whichClass" et "theName" de la méthode "getAttributeHandle()" a également changé lors du passage à la norme IEEE 1516-2000.

7.5.5.6 Implémentations spécifiques des RTIs

Un des principaux objectifs de l'API C++ de la norme IEEE 1516-2000 est de permettre des implémentations spécifiques à chaque RTI pour les classes offertes (RTI_Handle, RTI_AttributeHandle, …). Pour atteindre cet objectif, le langage C++ offre 2 alternatives :

• Les classes abstraites qui doivent être redéfinies lors de la conception d'une RTI spécifique.

• Les classes paramétrées qui utilisent un "template", et qui doivent être redéfinies par spécialisation des arguments.

C'est la seconde approche qui a été préférée pour définir l'API C++. Son inconvénient est que la redéfinition des "template" pour une implémentation donnée nécessite la recompilation des fédérés, ce qui ne constitue pas un problème, sauf dans le cas où l'on ne dispose pas du code source.


7.6 Annexe F : Les apports majeurs de la norme IEEE 1516-2010 à la norme IEEE 1516-2000

La norme IEEE 1516-2010150 constitue une mise à jour des spécifications IEEE 1516-2000 de HLA, conformément à la règle imposant une révision tous les 5 ans de tous les produits IEEE. Tous les documents de la norme IEEE 1516-2000 devaient être révisés, à l’exception du document IEEE Std 1516.3-2003 (HLA Federation Development and Execution Process), dont la revue a été initiée un peu plus tard, à partir de 2007.

Cette révision, effectuée dans le cadre d’un PDG (Product Development Group) de la SISO, s’appuie sur un document d’interprétations du DoD, sur l’API DLC (Dynamic Link Compatible), ainsi que sur les nombreux retours d’expériences formulées par les utilisateurs.

Les mises à jour effectuées dans la norme IEEE 1516-2010 ne concernent pas la sémantique de l’architecture HLA qui demeure inchangée. En outre, La norme IEEE 1516-2010 ne propose que des ajouts à la norme 1516-2000. Parmi les mises à jour, on peut noter des centaines de révisions qualifiées de mineures, et quelques propositions majeures. Les mises à jour mineures concernent principalement des précisions sur certaines interprétations, la prise en compte de la qualité de service (QoS) et IPv6 dans le type de transport, les schémas XML dans les modèles objet et la compatibilité à l’édition de liens.

Parmi les mises à jour majeures, on notera des mécanismes de tolérance aux fautes, la réduction de la fréquence de mise à jour (SURR151), une API pour les services du Web et les FOMs modulaires. Quelques évolutions ont également été discutées au cours du processus d’élaboration de la norme, sans toutefois avoir été retenues.

La norme IEEE 1516-2010 a été approuvée en mars 2010. Comme pour la norme 1516-2000, cette nouvelle norme est une norme IEEE. Cela implique un coût d’achat de la norme. Cependant, la SISO a négocié avec l’IEEE pour assouplir les conditions d’utilisation de la nouvelle norme par les vendeurs de logiciels HLA. En outre, les membres de la SISO peuvent acquérir gratuitement ces documents normatifs.

Björn Möller et al. avaient présenté les principales évolutions adoptées par la norme IEEE 1516-2010 en les classant par catégories conformément à la Figure 45 (Illustration issue de [B19]).

Les catégories définissent le niveau impacté par chaque nouvelle fonctionnalité :

Développement : Ces évolutions facilitent le développement de fédérés et/ou fédérations tout en diminuant le risque d’introduire des erreurs.

Déploiement : Les évolutions facilitent le déploiement des fédérés et des fédérations (où ? et quand ?).

Centrées Réseau : Les évolutions facilitent l’intégration des fédérations dans des applications Centrées Réseau.

Qualité de la conception : Elles permettent d’améliorer la qualité de la norme notamment en levant les ambiguïtés, ou bien elles facilitent la conception de fédérés de meilleure qualité.

150 Appelée « HLA Evolved » pendant son parcours de normalisation. 151 Smart Update Rate Reduction.


Figure 45 Les nouvelles fonctionnalités adoptées par la norme IEEE 1516-2010

7.6.1 Les FOMs modulaires

L’introduction de la modularité dans les FOMs constitue une solution facilitant la réutilisation et l’évolution des FOMs et des SOMs qui constituaient des opérations difficiles à cause de l’approche monolithique adoptée par les normes US DoD 1.3 et IEEE 1516-2000.

Tous les composants du FOM prédéfinis par la norme (MOM et typage des données) font l’objet d’un module séparé appelé MIM152. La Figure 46 (Illustration issue de [B19]) illustre la hiérarchie capturée par un FOM composé du MIM, d’un FOM de référence normalisée (Real time Platform Reference FOM, RPR FOM), d’une extension au FOM de référence (Local RPR Extension), d’un module destiné à la gestion de la fédération et enfin, d’un module attribué à un Data Logger.

Figure 46 Illustration de la hiérarchie dans un FOM modulaire

Un FOM modulaire est un FOM au sens traditionnel de l’architecture HLA, mais composé de modules. Chaque module peut être construit à partir de modules élémentaires ou bien étendre d’autres modules, en ajoutant de nouvelles classes d’interaction ou d’objets. Cette notion de FOM modulaire répond à un besoin de séparer le processus de développement d’une fédération selon différentes

152 MOM and Initialization Module.


« préoccupations » (capteurs, gestion de la fédération …). A l’exécution de la fédération, chaque fédéré doit être capable de faire appel à tous les modules du FOM qui l’intéressent [B19], [B20].

L’objectif de la mise en place des FOMs modulaires est de faciliter le travail de prise en compte de spécialisation du FOM réalisé par chaque fédéré pour son besoin propre. En effet, en partant d’un FOM racine et non modifiable, chaque participant à la fédération peut créer de nouvelles classes, mais seulement en tant que classes spécialisées du FOM racine. Chaque fédéré participe alors à la fédération avec son FOM (modulaire), qui correspond au FOM racine enrichi de ses classes spécialisées.

Il existe bien évidemment des règles strictes permettant de combiner plusieurs modules FOM pour obtenir un nouveau FOM enrichi. A titre d’illustration, un module FOM ne peut pas rajouter de nouveaux attributs à une classe déjà définie. En contrepartie, un module peut effectuer une opération analogue en définissant une sous classe (spécialisation) de la classe déjà définie.

Deux manières de charger les FOM, c'est-à-dire les fichiers FDD associés, pendant l’exécution d’une fédération, sont offertes par la norme IEEE 1516-2010 :

• Lors de l’invocation du service « Create Federation Execution », une liste de modules FOM peut être passée en arguments. Il faut noter également qu’en l’absence d’une référence à la MOM, la RTI dispose d’une MOM par défaut.

• Le service « Joint Federation Execution » admet également une liste de modules FOM que le fédéré souhaite faire partager à l’ensemble de la fédération.

Ces opérations de combinaison dynamique de modules sont atomiques, dans le sens où toute incohérence élémentaire conduit à l’échec de l’ensemble des opérations. Enfin, un module FOM demeure disponible pour la fédération jusqu’à invocation avec succès du service « Destroy Federation Execution ».

7.6.2 Une API pour des services du Web

Une API utilisant le langage WSDL (Web Service Definition Language) a été ajoutée à la norme IEEE 1516-2010, de manière à ce que les fédérés puissent être développés et déployés en utilisant un nombre important d’environnements de services Web disponibles. Cette approche consiste à promouvoir l’idée de composants de simulation comme services offerts par le Web.

Même si le langage WSDL décrit un protocole, il offre néanmoins des fonctionnalités équivalentes à celles des langages Java ou C++. Il s’agit en fait d’un protocole offert par de nombreux langages comme C++ ou Java, mais également Fortran, C, ADA et Perl. Un fédéré HLA peut ainsi se connecter à une fédération au travers d’un LAN ou d’un WAN en utilisant si nécessaire le protocole de codage et d’authentification HTTPS153.

La Figure 47 (Illustration issue de [B19]) illustre la manière dont un serveur peut offrir des services HLA de type services Web, à des clients géographiquement distants.

153 Hypertext Transfer Protocol Secured.


Figure 47 RTI avec Services Web

Pour offrir une API de type Services web, une RTI doit disposer d’un composant appelé WSPRC154 auquel les fédérés peuvent se connecter en utilisant une URL155.

Il faut cependant noter un certain nombre de limitations en termes de performances. Ainsi, les langages Java et C++ sont capables d’assurer au maximum 100 000 mises à jour par seconde, en moyenne 10 000 mises à jour par seconde. De même, l’API WSDL ne peut offrir que 2000 mises à jour par seconde au maximum et 200 mises à jour par seconde en moyenne.

7.6.3 Principes de tolérance aux fautes

Ces principes ont été adoptés pour permettre qu’un fédéré en état d’erreur à l’exécution puisse quitter proprement une fédération. Les fautes sont diffusées aussi bien à la fédération qui perd 1 ou plusieurs fédérés qu’au fédéré qui perd sa connexion à la fédération (voir Figure 48).

Figure 48 Illustration des mécanismes tolérants aux fautes

Une faute est ici définie comme tout événement qui empêche une fédération dans son ensemble de s’exécuter de manière normale dans le sens de HLA. Deux types de fautes sont répertoriés, la perte d’un fédéré et la perte d’un lien de communication.

154 Web Services Provider RTI Component. 155 Uniform Resource Locator.


La première faute a pour origine une erreur interne au fédéré, par exemple une exception non levée. Dans ce cas, la tolérance aux fautes est à la charge de la RTI qui doit forcer le fédéré à quitter la fédération grâce à la directive « Automatic Resign ».

La seconde faute, perte d’un lien de communication, ne peut être identifiée que par un élément externe à la fédération en cours d’exécution. La RTI doit tenter de signaler la faute au fédéré concerné, tentative qui peut réussir ou échouer selon la nature du problème de communication, car le fédéré peut ne plus exister.

7.6.4 Réduction de la fréquence des mises à jour

Dans certaines fédérations on souhaiterait que des fédérés reçoivent la même information mais à des fréquences de mise à jour différentes, selon l’illustration suivante.

Figure 49 Contrôle de la fréquence des mises à jour

Pour illustrer la problématique, l’exemple suivant est souvent décrit : un simulateur de vol effectue des mises à jour des positions d’un avion à la fréquence de 30 Hz. Un composant C4I s’abonnant à la position de l’avion, nécessite une nouvelle valeur de cet attribut à la fréquence de 1 Hz. Un autre composant de la fédération ne peut supporter qu’une fréquence de mise à jour inférieure ou égale à 5Hz. Une fréquence de mise à jour de 30 Hz conduit à une saturation. Enfin, un dernier composant souhaite recevoir les mises à jour à 30 Hz pour les threads actifs et des mises à jour à 5 Hz pour le reste. Ainsi, les divers composants de la fédération intéressés par les mises à jour de la position de l’avion, souhaitent recevoir ces mises à jour à des fréquences différentes.

La solution proposée par le mécanisme de réduction de la fréquence des mises à jour (SURR– Smart Update Rate Reduction), consiste à permettre à tout abonné de définir la fréquence de mise à jour maximale à laquelle il souhaite recevoir les mises à jour d’un attribut, au moment même où il se déclare abonné. Dans ce mécanisme, c’est la RTI qui doit diffuser les mises à jour à la fréquence désirée par les abonnés.

7.6.5 Compatibilité dynamique des fédérés aux RTIs

L’objectif est de mettre en œuvre des mécanismes permettant de réutiliser des fédérés indépendamment des RTIs utilisées. La solution retenue est fondée sur un mécanisme plus ancien adopté par la SISO appelé DLC API156 [A15]. Pour distinguer cette nouvelle version illustrée par la Figure 50 de l’ancienne proposée par la SISO, le terme utilisé est EDLC API157.

156 Dynamic Link Compatibility API. 157 Evolved DLC API.


Figure 50 Compatibilité dynamique des fédérés aux RTIs

Un fédéré développé et compilé pour une RTI donnée (fournie par le vendeur A) peut être immédiatement réutilisé dans une fédération utilisant une autre RTI (fournie par un vendeur B ou C), grâce aux DLL158 RTIlib.dll fournies par les vendeurs.

7.6.6 Autres évolutions de la norme IEEE 1516-2010 pour l’API

De très nombreuses évolutions ont été introduites dans la norme IEEE 1516-2010 parmi lesquelles :

• Des supports à la gestion « du data marshalling »,

• La réutilisation du nommage des objets,

• L’amélioration de la gestion des synchronisations entre fédérés,

• La clarification des mécanismes de réentrance. En outre dans la nouvelle norme, un plus grand nombre de services de l’API peuvent être invoqués de manière réentrante à partir d’un « callback »,

• 210 interprétations du DoD qui avaient été collectées pour la norme HLA 1516-2000 ont également été introduites dans la norme IEEE 1516-2010.

7.6.7 Evolutions de l’OMT

L’impact majeur sur l’OMT découle de l’introduction des FOM modulaires et de la nécessité d’établir des règles pour combiner les modules de la FOM (Union par exemple).

Trois nouveaux schémas XML ont également été introduits pour les besoins des tests de conformité à la norme :

• Le schéma DIF utilisé pour les tests de syntaxe,

• Le schéma FDD utilisé pour vérifier que le fichier FDD partie de la FOM, peut être chargé par la RTI. Ce schéma fait plutôt partie des spécifications d’interface car il concerne la RTI.

158 Dynamic Link Library.


• Le schéma OMT qui vérifie que le contenu des tables de l’OMT est correct et cohérent.

Il faut remarquer qu’un module FOM doit uniquement adhérer au schéma DIF à cause des dépendances avec d’autres modules, alors qu’un FOM assemblé doit au moins adhérer au schéma FDD pour qu’il puisse être utilisé par une RTI, puis au schéma OMT pour qu’il puisse être considéré comme un FOM à part entière.

En ce qui concerne les tables de l’OMT, la table d’identification prévoit de nouvelles métas données.

7.6.8 Evolutions non retenues

Quelques demandes d’évolutions de la norme ont été présentées mais n’ont pas été intégrées, les discussions et/ou votes qui ont eu lieu au sein du groupe de travail ayant abouti à ces décisions. Ces demandes concernent :

• les RTI « partielles » (une RTI « partielle » est une RTI n’offrant qu’une liste réduite de l’ensemble des services HLA),

• la suppression du MOM (Management Object Model),

• les interactions dirigées (une interaction est dirigée lorsqu’elle est associée à une liste des fédérés devant recevoir cette interaction).


7.7 Annexe G : Situation des groupes de normalisation à la SISO (mars 2011)

7.7.1 Product Support Groups (PSG) BOM Base Object Model DIS DistributedInteractive Simulation EDRS EnvironmentalData RepresentationStandards HLA-Evolved High LevelArchitecture (HLA) –Evolved TADIL TALES TacticalDigital Information Link –TechnicalAdvice& Lexiconfor

EnablingSimulation VV&A Verification, Validation & AccreditationOverlay to Federation

7.7.2 Product Development Groups (PDG) C-BML Coalition-Battle Management Language CMSD CoreManufacturingSimulation Data CSPI COTS Simulation Package Interoperability DIS DistributedInteractive Simulation DSEEP DistributedSimulation Engineering and ExecutionProcess DSEEP-DMAO DistributedSimulation Engineering and ExecutionProcess(DSEEP)-Multi-

Architecture Overlay (DMAO) EPLRS/SADL EnhancedPosition Location ReportingSystem includingSituation AwarenessData

Link FEAT FederationEngineering AgreementsTemplate GM-VV GenericMethodologyfor VV&A Link 11 A/B Link 11 A/B Simulation Standard MSDL MilitaryScenario DefinitionLanguage SRML Simulation ReferenceMarkupLanguage

7.7.3 Study Groups (SG) DDCP DistributedDebriefControl Protocol


GAMETECH/SIM Game TechnologyAppliedto Modeling& Simulation HSCBMS Human Social Culture Behavior (HSCB) Modeling Standards LMS Landscapeof Modeling& Simulation Challenges LVC Live, Virtual, Constructive (LVC) Architecture Interoperability MODE 5/S IFF Mode 5/Mode S Identification Friendor Foe MSDBP Modeling& Simulation DevelopmentBest Practices OOHLA Object-OrientedHigh LevelArchitecture RIEDP Reuseand Interoperationof EnvironmentalData and Processes SCORM-SIM SharableContent Object ReferenceModel (SCORM)-Simulation Interface

Standards TDTP Target Data Transfer Protocol TEO-DSEEP Test & Evaluation Overlay to the DistributedSimulation Engineering and

ExecutionProcess UCATT UrbanCombat Advanced Training Technologies

7.7.4 Standing Study Groups (SSG) CIGI Common Image GeneratorInterface ECON Economicsof Modeling& Simulation PDMS Paralleland DistributedModeling& Simulation SCM Simulation ConceptualModeling

http://www.sisostds.org/StandardsActivities/StudyGroups/HSCBModelingStandardsSG.aspx�


7.8 Annexe H : Terminologie AAR After Action Review ALSP Aggregate Level Simulation Protocol AMG Architecture Management Group AMO Application Management (TENA) API Application Programming Interface ARCOSIM Projet d’Etudes Amont réalisé par la DGA sur la norme HLA pour les simulations distribuées et le développement d’outils logiciels ASCII American Standard Code for Information Interchange BNF Bacchus Naur Form BOM Base Object Model C4I Command Control Communication Computer Intelligence CA Certification Agent CAD Centre d’Analyse de la Défense CEPA Common European Priority Area CMSE Composable Mission Space Environment CORBA Common Object Request Broker Architecture CS Conformance Statement. Fichier précisant les services HLA utilisés par un fédéré CSS Cascading Style Sheets CTEIP Central Test & Evaluation Investment Program CTIA Common Training Instrumentation Architecture C-BML Coalition Battle Management Language DGA Délégation Générale de l’Armement DIF Data Interchange Format DIS Distributed Interactive Simulation DLC Dynamic Link Compatible


DMAO DSEEP Multi-Architecture Overlay to the DSEEP DMSO Defense Modeling and Simulation Office (voir M&S CO) DSEEP Distributed Simulation Engineering and Execution Process DoD Department of Defense DoDAF DoD Architecture Framework DTD XML Document Type Declaration DTRA Defense Threat Reduction Agency EDES Environnements de Développement et d'Exploitation de

Simulations EUCLID EUropean Cooperation for the Long-term In Defence FCTT Federate Compliance Testing Tool FDD FOM Document Data FED Federation Execution Data FEDEP FEderation Development and Execution Process FI2010 Foundation Initiative 2010 FOM Federation Object Model FTMS Federate Test Management System FUT Federate Under Test GALT Greatest Available Logical Time GIG Global Information Grid GM-VV Generic Methodology for Verification and Validation GRIM Guidance, Rationale, and Interoperability Manual for the Real-time Platform Reference Federation Object Model HLA High Level Architecture HTML HyperText Markup Language Hz Hertz IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force


IP Internet Protocol IPC Inter Process Communication IPv6 Internet protocol version 6 ISO International Organization for Standardization ITCS Infrastructure Technique Commune de Simulation ITOP International Test Operations Procedures JFCOM Joint Forces COMmand JNTC Joint National Training Capability LBTS Lower Bound Time Constraint LITS Least Incoming Timestamp LRC Local RTI Component LRDA Logical Range Data Archive LROM Logical Range Object Model MoU Memorandum of Understanding MDA Model Driven Architecture MIM Management Initialization Module MOM Management Object Model MONOD Modèles et Outils Nouveaux pour la SACOD M&S Modeling & Simulation M&S CO Modeling and Simulation Coordination Office (successeur du DMSO) MSG M&S Group NAVMSMO Navy Modeling and Simulation Management Office NIAG NATO Industry Advisory Group NMSG NATO M&S Group NPS Naval Postgraduate School NSRL NATO Simulation Resource Library


OASIS Organization for the Advancement of Structured Information Standards ODF Open Document Format OGC Open Geographic Information System Consortium (ou Open Geospatial Consortium) OMDD Object Model Data Dictionary OMDT Object Model Development Tool OMG Object Management Group OMT Object Model Template OMT-WG Object Model Template – Working Group OS Operating System. Système d’exploitation OTAN Organisation du Traité de l'Atlantique Nord OWL Web Ontology Language PfP Partners for Peace PDG Product Development Group PDU Protocol Data Unit PSG Product Support Group PVD Plan View Display QoS Quality of Service RAMBUTO Rationalisation des Modèles de Base à Usage Technico- Opérationel RDF Resource description Framework RID RTI Initialisation Data RO Received Ordered Event RPR FOM Real-time Platform Reference – Federation Object Model RTI Run-Time Infrastructure RTP Research and Technology Project SAC Standards Activity Committee


SACOD Simulation pour l'Analyse et la Conception de l'Outil de Défense SCS Society for Modeling & Simulation International SDO Stateful Distributed Objects SEDEP Synthetic Environment Development and Execution Process SEDRIS Synthetic Environment Data Representation and Interchange Standard SEI Software Engineering Institute SG Study Group SIMNET SIMulators NETworking SIC Systèmes d’Information et Communication SIOC Système d’Information Opérationnel et de Communication SISO Simulation Interoperability Standard Organization SIW Simulation Interoperability Workshop SOA Service Oriented Architecture SOAP Simple Object Access Protocol SOM Simulation Object Model SSE Simulation Support Environment SSG Standing Study Group STANAG STANdard AGreement SURR Smart Update Rate Reduction TCP/IP Transmission Control Protocol / Internet Protocol TDL TENA Definition Language TENA Test and Training Enabling Architecture TEO DSEEP Test and Evaluation Overlay to the DSEEP TIDE TENA Integrated Development Environment ToR Terms of Reference TSO Time-Stamp-Ordered Event


UDP User Datagram Protocol UML Unified Modeling Language US United States V&V Validation & Vérification VV&A Validation, Vérification et Accréditation W3C World Wide Web Consortium WA Website Administrator WAN Wide Area Network WEAG Western European union Armament Group WERTI Web Enabled RTI WSDL Web Service Definition Language WSIM Web Services Interest Management XBML eXtensible Battle Management Language XHTML eXtensible HTML XML eXtensible Markup Language XMSF eXtensible Modeling and Simulation Framework XSBC XML Schema based Binary Compression