[TYPE] DGA - Simulation pour les armées

Transcription

MINISTÈRE DE LA DÉFENSE
GUIDE S-CAT
N° 10006
GUIDE HLA
(HIGH LEVEL ARCHITECTURE)
5ème édition
approuvé le 22 octobre 2012
Guide entretenu par DS/CATOD
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.
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
Rédaction
DIRECTION GENERALE DE L'ARMEMENT
© 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
SDS
ISE
Processus niveau 2
Activités
MCT 1
Veille technique et Capitalisation des
connaissances techniques
Réaliser la prestation
RPT 4
Guide S-CAT n° 10006 Ed05
Emplois de référence
Secteurs-clés CMMI
2 / 149
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
4.2
4.3
4.4
LES OUTILS INDISPENSABLES ................................................................................................................ 45
LES OUTILS UTILES................................................................................................................................ 46
LES OUTILS COMPLEMENTAIRES DONT ON PEUT SE PASSER ................................................................... 47
CONCLUSION ........................................................................................................................................ 47
3 / 149
5
LA CERTIFICATION DE CONFORMITE A HLA DES FEDERES ............................................... 48
5.1
5.2
6
PRINCIPES DE LA CERTIFICATION DES FEDERES ..................................................................................... 48
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
AIDE A LA REDACTION DES CAHIERS DES CHARGES ............................................................ 52
6.1
6.2
6.3
6.4
REFERENCES PRINCIPALES A INSERER ................................................................................................... 52
SPECIFICATIONS DU BESOIN .................................................................................................................. 52
NORMES APPLICABLES .......................................................................................................................... 53
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
8.2
8.3
ANNEXE A : DOCUMENTS DE REFERENCE ............................................................................................. 79
ANNEXE B : BIBLIOGRAPHIE ................................................................................................................. 81
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
4 / 149
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
8.7
5 / 149
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 IEEE 1 15162010 (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.42007 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).
6 / 149
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 SISO 2, à 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.
7 / 149
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-2000 3 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.
8 / 149
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és 4 ».
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étique 5"
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és 7)
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.
9 / 149
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 cidessous) 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ères 8 simulations distribuées ont été développées aux ÉtatsUnis, 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.
10 / 149
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 contrainte 11 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’imposer 12 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 HLAEvolved 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-VV 14, 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.
11 / 149
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 3 15. 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".
12 / 149
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éels 18 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.
13 / 149
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-BML 19 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érification 20 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érentes 21 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 APIs 22 dans les langages de programmation courants (tels
Java, C++).
19
Coalition Battle Management Language.
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.
20
14 / 149
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).
15 / 149
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
WSDL 24 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 œuvre 25. 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 dollars 26.
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.
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.
25
16 / 149
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 restaurant 27.
27
La classe racine HLAobject Root a été volontairement omise.
17 / 149
Client (PS)
Employé (S)
Serveur (PS)
Caissier (PS)
Cuisinier (PS)
Addition (PS)
Commande (PS)
Nourriture (S)
Boisson (S)
Vin (PS)
Café (PS)
Eau (PS)
Entrée (S)
Soupe (S)
Poisson (PS)
Légume (PS)
Salade (PS)
Plat Principal (S)
Viande (S)
Cochon (PS)
Boeuf (S)
Onglet (PS)
Côte (PS)
Poisson (S)
Truite (PS)
Thon (PS)
Dessert (S)
Glace (PS)
Gâteau (S)
Fruits (PS)
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 FEDEP 28 [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.
18 / 149
Dans le cadre de la norme IEEE 1516-2010, il a été remplacé par le DSEEP 29 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
publication/abonnement 30 à des données et diffère ainsi radicalement du modèle client-serveur.
de
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
30
Distributed Simulation Engineering and Execution Process.
Publication/subscription en anglais.
19 / 149
signale un message ponctuel 31 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é.
(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
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 classe 32.
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
32
Messages qui peuvent être horodatés.
Messages qui peuvent être horodatés.
20 / 149
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 classes 33.
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.
21 / 149
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 ellemê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
22 / 149
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.
23 / 149
RTI
Fédéré A
Connexion à la RTI
Fédéré B
Connexion à la RTI
Créer la fédération
(Succès)
Créer la fédération
(Échec, fédération existe)
Rejoindre la fédération
Rejoindre la fédération
Déclaration de
publication des attributs
X, Y et Z de la classe
"Vehicle"
Déclaration
d'abonnement aux
attributs X, Y et Z de la
classe "Vehicle"
Créer les instances de la
classe "Vehicle"
Découverte des instances de la
classe "Vehicle"
Mise à jour et diffusion
des nouvelles valeurs de
X, Y et Z
Répercussion des
nouvelles valeurs de X,
Y et Z
Quitter la fédération
Détruire la fédération
(Echec)
Déconnexion de la RTI
Quitter la fédération
Détruire la fédération
(Succès)
Déconnexion de la RTI
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 temporelle 34.
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é.
24 / 149
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 messages 36, 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.
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.
36
25 / 149
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 STANAG 39 (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 Office 40) 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
40
STANdard AGreement.
Remplacé depuis octobre 2006 par le M&S Coordination Office (M&S CO).
26 / 149
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’outreatlantique. 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).
27 / 149
D’autres produits émergent fondés nativement sur HLA (tels que GENESIS 41 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 choix 42,
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 .RID 43 pour la RTI NG 44 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
42
43
44
Article publié à la conférence EuroSIW : 05E-SIW-013, Toulouse, France, Juin 2005.
Cas du domaine de la simulation pour l’analyse, par exemple.
Le fichier RID (RTI Initialisation Data) permet d’ajuster un certain nombre de paramètres de la RTI.
Une des premières RTI développées par le DMSO à la norme US DoD 1.3.
28 / 149
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 suit 45). 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.
29 / 149
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 RTIs 46. 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 !
30 / 149
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ère 47,
•
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.
31 / 149
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 2003 48 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.
32 / 149
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]).
33 / 149
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 admis 50 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 DSEEP 51 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 DSEEP 52 qui fait l’objet d’un PDG 53 à 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.
Dans le contexte HLA.
51
Test and Evaluation Overlay to the DSEEP.
52
Multi-Architecture Overlay to the DSEEP.
53
Product Development Group.
50
34 / 149
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 composants 54 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
simulation 55 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
55
Dans le jargon du DSEEP, un composant est désigné par le terme « member ».
Dans le FEDEP, cette étape produisait le FOM de la fédération.
35 / 149
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 client 56), 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.
36 / 149
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 DIS 57, HLA et TENA 58.
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 PSG 59 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 GRIM 60 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.
Testing and training Enabling Architecture.
59
Product Support Group.
60
Guidance, Rationale, and Interoperability Manual for the Real-time Platform Reference Federation Object
Model.
58
37 / 149
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éexistante 61, 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 SSE 62 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.
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.
62
38 / 149
nation ou un pays partenaire pour la paix de l’OTAN (le Canada, l’Espagne, la France, le RoyaumeUni, 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 DSEEP 65 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.
39 / 149
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 FOM 66. 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ées 67
é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 1516 68. 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.
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.
67
40 / 149
(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 intergiciel 69 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 transition 70, 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
70
Terme français pour désigner la notion de « middleware » en anglo-saxon.
Certains sont même gratuits et livrés avec l’achat d’une RTI commerciale.
41 / 149
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 ».
42 / 149
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.13 72) 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 NSRL 73.
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 FEDEP 74, 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 (AAR 75),
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.
43 / 149
•
L’étude RTP 11.13 s'est achevée en 2003 dans le cadre du CEPA 76 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
particulier 77. 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
Objectives
Perform Conceptual
Analysis
Design
Federation
Develop
Federation
Plan, Integrate, &
Test Federation
Performance
Modeling
Tool
HLA-Specific
Resources
Object Models
And Object Model
Components
Execution
Planning
Tool
Execution
Environment
Description
FOM
Object Model
Development
Tool
Conceptual
Analysis
Tool
FED /
FDD
Federation
Testing
Tool
Federation
Conceptual
Model
Execute Federation &
Prepare Results
Execution
Environment
Runtime
Infrastructure
Runtime
Management
Tool
Runtime
Monitoring
Tool
Data
Collection
Tool
Raw Execution
Outputs
Federation
Scenario(s)
M&S DomainSpecific Tools
After Action
Review Tool
Scenario
Development
Tool
Authoritative
Resources
Scenario
Database
Derived
Outputs
Federation
Objectives
Statement
General Purpose
Tools
Requirements
Definition
Tool
Analyze Data &
Evaluate Results
Data/Statistical
Analysis
Tool
Federation Requirements
Federation Test Criteria
Configuration
Management
Tool
Figure 5
Version Control
Tool
VV&A
Tool
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.
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).
77
44 / 149
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
actuels 78 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 CO 79 (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 IOSB 80. 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.
Modeling and Simulation Coordination Office, qui a succédé au DMSO fin Octobre 2006.
80
Institute for Optronics, System Technologies and Image Exploitation.
79
45 / 149
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.
46 / 149
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.
47 / 149
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 HLA 81. 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 1516 83). A ce jour, chaque capacité de
certification est nationale, mais, sur le plan technique, son activité est pilotée par le NMSG 84 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 (FTMS 85) 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 (FCTT 86), 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.
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.
82
48 / 149
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 :
S éparation géographique
F éd ération H L A
C e n tre d e
ce rtific atio n
S ite C lie n t
F édéré
à certifier
A utre(s)
fédéré(s)
RTI
(R un T im e In frastru cture)
F édéré
FCTT
R éseau local
P ares-feu x
P ares-feu x
In ternet
Figure 7
Certification à distance
F édération H L A
S ite C lien t
F édéré
à certifier
RTI
(R un T im e Infrastructure)
A utre(s)
fédéré(s)
F édéré
FCTT
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.
49 / 149
Etape 1
Etape 2
Etape 3
Etape 4
Inscription
Client
SOM
Validation
Inscription
Fédéré
planning
Exécution
test(s)
CS
.rid **
FED/FDD*
Validation
Environnement
test
Validation
Certification
Validation
* FED pour la norme 1.3, FDD pour la norme IEEE 1516
Figure 9
** pour la norme 1.3
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 FED 87/FDD 88) 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 FUT 89,
•
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
FOM Document Data dans la norme IEEE 1516-2010.
89
Federate Under Test
88
50 / 149
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 RID 90 ….). 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.
51 / 149
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é.
52 / 149
5.3
Normes applicables
Conformément au STANAG 4603, la norme applicable est la norme HLA IEEE 1516 dans sa
version la plus récente 91 (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 correspondants 92. 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 :
91
92
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.
La norme IEEE 1516-2010 à la date de la mise à jour de ce guide.
Certaines RTIs commerciales implémentent déjà les nouvelles fonctionnalités de cette version.
53 / 149
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.
54 / 149
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.
55 / 149
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,
56 / 149

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 AMT 94
(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’intergiciel 95,

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
95
Se référer à [B36] pour la liste de tous les participants.
Version 6.0.1 depuis juin 2010.
57 / 149
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.
58 / 149
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.
59 / 149
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.
60 / 149
Figure 15
Figure 16
Figure 17
Invocation de méthodes distantes (Illustration issue de [B32])
Mise à jour d’attributs (Illustration issue de [B32])
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.
61 / 149
Figure 18
6.1.4
Processus de création d’une application TENA (Illustration issue de [B32])
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
TIDE 96
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,
•
TIDE 97 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 SIMDIS 98 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.
Version 2.0.3 depuis juin 2010.
98
Ensemble d’outils d’analyse et de visualisation de l’US Navy disponibles gratuitement sur demande.
97
62 / 149
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])
63 / 149
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
6.1.7
Plateformes supportées par l’intergiciel TENA (Illustration issue de [B36])
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])
64 / 149
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.
65 / 149
•
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 BOMs 99 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 SISO 100, 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 PDG 101 s’est transformé en PSG 102 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/.
Et non IEEE.
101
Product Development Group.
102
Product Support Group.
100
66 / 149
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.
67 / 149
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.
68 / 149
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.
69 / 149
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.
70 / 149
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
71 / 149
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.
72 / 149
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 SOA 103
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] :
•
103
Conception d’un ensemble de services Web « à l’image » des services offerts par la norme HLA.
Service Oriented Architecture.
73 / 149
•
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 (GIG 104) [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 SG 105 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 simulation 106 (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 NMSG 107 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.
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.
105
74 / 149
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])
75 / 149
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.
76 / 149
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,
77 / 149

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 15162010, 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 XMSF 108 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.
78 / 149
7
7.1
ANNEXES
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
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
High Level Architecture (HLA) - Federate Interface Specification”, September 2000
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
Tutoriel SISO de Mars 2009, par Ed POWELL, TENA Architect (copyright SISO)
SIW
2009,
[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
79 / 149
[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. 2006 109
109
Document disponible sur le site http://www.w3.org/.
80 / 149
7.2
[B1]
Annexe B : Bibliographie
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-MSG005 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
81 / 149
[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",
http://www.april.org/files/economicmodels_ en.pdf, December 2007
white
paper,
[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
82 / 149
[B30] Martin Adelantado, Jean-Baptiste Chaudron, Armand Oyzel, “Using the HLA, Physical
Modeling and Google Earth for Simulating Air Transport Systems Environmental Impact”, 09SSIW-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-01v1.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-0292008, 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
83 / 149
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-2010 110. Les évolutions de la norme US DoD 1.3 vers la norme IEEE 1516-2000 111 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.
84 / 149
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 DIF 112. 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.
85 / 149
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 MOM 113 qui constitue un sous-ensemble de toute FOM,
b) Le MIM 114 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
FDD 115 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.
Management Initialization Module.
115
FOM Document Data.
114
86 / 149
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.
87 / 149
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.
88 / 149
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].
89 / 149
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’interactions 116. 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 objet 117, 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 intergiciel 118 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 DMSO 119, dont l'architecture est illustrée
sur la Figure 40. Notons qu’à ce niveau de description, les architectures de toutes les RTIs sont
semblables.
Fédéré
RTIExec
FEDExec
LibRTI
Fédéré
LibRTI
IPC
116
Se référer au chapitre 11 du document normatif [A2] pour les classes d’interaction de la MOM.
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.
117
90 / 149
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é HLA 120
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.
Code Fédéré
FEDAmbassador
RTI
LRC
RTIAmbassador
Figure 41
120
Echanges entre fédéré et RTI
Toujours en utilisant le vocable du RTI NG ou du CERTI de l’ONERA.
91 / 149
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.
92 / 149
Condition
d’utilisation
Exploité
RTI
par
Objet
Services
la Federation Connect
RTI Commentaires
X
Le fédéré établit une connexion
avec la RTI
X
Le fédéré ferme la connexion
avec la RTI
Create Federation X
Execution
le fédéré lance l'exécution de la
fédération
Destroy Federation X
Execution
le fédéré termine l'exécution de
la fédération nommée
Join
Federation X
Execution
le fédéré rejoint l'exécution de la
fédération en cours
Disconnect
Employé par les
fédérés
Fédéré
Connection Lost
X
List
Federation X
Executions
Report Federation
Executions
Le fédéré demande une liste des
exécutions de fédérations en
cours
X
Resign Federation X
Execution
Pause
Utilisé par
fédérés
les
Confirm
Synchronization
Point Registration
Register
Federation
Synchronization
Point
Resume
Synchronisation
Point Achieved
X
la RTI confirme qu’un Register
Federation
Synchronization
Point a été invoqué par le fédéré
le fédéré demande un point de
synchronisation
X
X
La RTI fournit une liste des
exécutions de fédérations en
cours
le fédéré quitte l'exécution de la
X
Announce
Synchronisation
Point
La RTI annonce que le fédéré
quitte la fédération suite à une
faute
la RTI demande au fédéré de
stopper l'évolution de son état
le fédéré indique qu'il a
correctement stoppé l'évolution
de son état
93 / 149
Federation
Synchronized
X
Request
Federation Save
Initiate
Save
Federate
Federate
Begun
le
fédéré
demande
une
sauvegarde de l'état de la
X
le fédéré indique qu'il a
commencé à sauvegarder son
état
Federation X
Le fédéré demande à suspendre
la sauvegarde en cours
Query Federation X
Save Status
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
sauvegarde est terminée
Federate
Complete
le fédéré indique qu'il a terminé
de sauvegarder son état
Request
X
Federation Restore
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
Initiate
Restore
Federate
Le fédéré demande à suspendre
la restauration en cours
X
Query Federation X
Restore Status
Federation Restore
Status
Federation Restore X
Complete
la
Save X
Abort Federation X
Restore
la RTI demande à un fédéré de
sauvegarder son état courant
Save X
Abort
Save
Restore
X
la RTI indique à un fédéré qu'il
peut poursuivre l'évolution de
son état
la RTI demande à un fédéré de
restaurer un état préalablement
sauvegardé
Le fédéré demande l’état de la
restauration en cours
X
La RTI fournit l’état de la
restauration en cours
la RTI indique que
restauration est terminée
la
94 / 149
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.
Condition
d’utilisation
Objet
Fédérés souhaitant Publish
publier des attributs
de classes d’objets
Fédérés souhaitant Subscrib
souscrire
à
des e
attributs de classes
d’objets
Services
Fédér RTI Commentaires
é
Publish Object X
Class
Attributes
le fédéré déclare son intention de
publier des attributs d’une classe
d’objets
X
Unpublish
Object Class
Attributes
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’objets 121
Stop
Registration
For
Object
Class
X
cesser de créer des instances de la
classe d’objets 122
Publish
Interaction
Class
X
publier une classe d’interaction
Unpublish
Interaction
Class
X
cesser de publier une classe
d’interaction
Turn
Interactions On
X
commencer
à
émettre
des
123
interactions
Turn
Interactions
Off
X
cesser d’émettre des interactions 124
Subscribe
X
Object Class
Attributes
s’abonner à certains attributs d'une
classe d'objet
Unsubscribe
X
Object Class
Attributes
cesser de s’abonner à certains
attributs d'une classe d'objet
Subscribe
Interaction
Class
s’abonner à une classe d'interaction
X
121
Au moins un fédéré vient de s’abonner à un des attributs de la classe.
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.
122
95 / 149
Unsubscribe
Interaction
Class
X
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 Management
Objects
RTI
getObjectClassHandle()
getAttributeHandle()
publishObjectClass()
subscribeObjectClassAttributes()
startRegistrationForObjectClass()
unsubscribeObjectClass()
stopRegistrationForObjectClass()
unpublishObjectClass()
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().
96 / 149
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.
Condition
d’utilisation
Objet
Services
Fédéré RTI Commentaires
Utilisation
et Object
affectation d’objets
Reserve
Object
Instance
Name
X
X
Object
Instance
Name
Reserved
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
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
Delete Object X
Instance
la RTI signale au fédéré que la
réservation a été acceptée
Release
Object
Instance
Name
Multiple
Object
Instance
Names
Reserved
le fédéré demande à réserver un
nom pour une instance de classe
d’objet
X
la RTI informe un fédéré qu'il
dispose de nouveaux objets le
concernant
le fédéré informe la RTI qu'un
objet est retiré
97 / 149
X
Remove
Object
Instance
Manipulation
de Attribute
valeurs d'attributs
Value
et d’interactions
Update
Attribute
Values
X
Request
Object
Attribute
Value
le fédéré fournit à la RTI une mise
à jour des attributs
X
Reflect
Attribute
Values
la RTI informe un fédéré qu'un
objet a été définitivement retiré
X
la RTI fournit à un fédéré les
nouvelles données le concernant
le fédéré demande la mise à jour
d'attributs
Update
Provide
Attribute
Value
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é
Turn Updates
Off
For
Object
Instance
X
certaines valeurs d’attributs d’une
instance de classe d’objet ne sont
plus demandées par aucun fédéré
Update
Interaction
Send
Interaction
X
Receive
Interaction
Modification
des Change
modes de transport
et
d'ordonnancement
des informations
Change
Attribute
le fédéré informe la RTI qu'une
action a été lancée par un objet
X
la RTI informe qu'une action a été
lancée par un objet
X
le fédéré change le type de
transport d'un attribut d'une classe
X
Request
Attribute
Transportatio
n
Type
Change
le fédéré demande à changer le
mode de transport de certains
attribut de l’instance de classe
d’objet 126
Change
Interaction
le fédéré change le type de
transport d'une classe d'interaction
Transport
Type
X
Transport
Type
126
Le type de transport par défaut est précisé dans le document FDD.
98 / 149
X
Confirm
Attribute
Transportatio
n
Type
Change
Query
Attribute
Transportatio
n Type
X
le fédéré demande le mode de
transport courant d’un attribut
d’une instance de classe d’objet
X
Report
Attribute
Transportatio
n Type
la RTI délivre le mode de
transport courant d’un attribut
d’une instance de classe d’objet
le fédéré demande à changer le
mode de transport d’une classe
d’interaction
Request
Interaction
Transportatio
n
Type
Change
Confirm
Interaction
Transportatio
n
Type
Change
Query
Interaction
Transportatio
n Type
Callback en réponse service
Request Attribute Transportation
Type Change
X
X
Callback en réponse service
Request
Interaction
Transportation Type Change
le fédéré demande le mode de
transport courant des paramètres
d’une interaction
X
Report
Interaction
Transportatio
n Type
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.
Condition
d’utilisation
Objet
Souhait acquérir Acquisition
la propriété
Services
Attribute Ownership X
Acquisition
le fédéré demande à la RTI
d’acquérir la propriété de
certains
attributs
d’une
instance de classe d’objet
99 / 149
Attribute Ownership
X
Acquisition
Notification
Acquisition
If
Available
Attribute Ownership
Unavailable
Même chose que pour le
service
« Attribute
Ownership
Acquisition »,
mais seulement si les
attributs
spécifiés
n’ont
aucun propriétair
X
Cancel
Attribute X
Ownership
Acquisition
Confirm Attribute
Ownership
Acquisition
Cancellation
Souhait céder la Divestiture
propriété
le fédéré signale à la RTI
qu’il ne souhaite plus
acquérir la propriété de
certains
attributs
d’une
X
La RTI signale au fédéré que
les attributs spécifiés ne
désirent plus lui céder la
propriété
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 X
Ownership
Divestiture
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é
Confirm Divestiture X
sa demande d’acquisition ne
peu être acceptée
Unconditional
X
Attribute Ownership
Divestiture
Request Divestiture
Confirmation
la RTI indique au fédéré qu'il
est propriétaire de certains
attributs d’une instance de
classe d’objet
X
la RTI signale que des
propriétaires
potentiels
existent dans la fédération
suite à une demande de
cession de la propriété
qu’il souhaite terminer la
négociation de cession de la
propriété de certains attributs
d’une instance de classe
d’objet
100 / 149
Attribute Ownership
X
Divestiture
Notification
la RTI indique au fédéré
qu'il est dégagé du contrôle
des attributs
Divestiture
If
Wanted
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 X
Attribute Ownership
Divestiture
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
Propriété
libérer
à Release
X
la RTI demande la cession de
la propriété des attributs
spécifiés
Information sur le Query
propriétaire
Request
Attribute
Ownership Release
Release Denied
qu’il refuse la cession des
attributs spécifiés
Query
Attribute X
Ownership
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
Is Attribute Owned X
By Federate
X
callback en réponse à une
invocation
du
service
« Query
Attribute
Ownership”
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 :
101 / 149
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-ouvert 127 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égion 128 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égion 129 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 :
Condition
d’utilisation
Gestion
régions
Objet
Services
des Création et Create Region
modification
s
X
de créer une région avec des
dimensions
Commit
Region X
Modifications
le fédéré signale à la RTI des
modifications
dans
les
intervalles spécifiés des
régions spécifiées
Delete Region
X
de détruire une région
Object X
With
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 X
For Updates
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
Unassociate Regions X
For Updates
ce
service
détruit
l’association
entre
les
attributs spécifiés d’une
instance d’objet et les régions
spécifiées
Association Register
avec
les Instance
régions pour Regions
les mises à
jour
d’attributs
127
Appelé « range » dans les spécifications d’interface.
Appelé « region template ».
129
Appelée « region realization ».
128
102 / 149
7.3.6.6
Object X
Gestion des Subscribe
Attributes
regions pour Class
With Regions
les
abonnement
s
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 X
Class
Attributes
With Regions
ce
service
supprime
l’association précédente
Subscribe
X
Interaction
Class
With Regions
ce service informe la RTI de
la classe d’interaction à
laquelle il souhaite s’abonner
en tenant compte des régions
spécifiées
X
Unsubscribe
Interaction
Class
With Regions
ce
service
supprime
l’association précédente
Emission
Send
Interaction X
d’interaction With Regions
s et mises à
jour
d’attributs
Request
Attribute X
Value Update With
Regions
le
fédéré
envoie
une
interaction en limitant les
fédérés receveurs grâce aux
régions
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
Les services support
Ces services support permettent de :





effectuer les associations entre noms (classes, attributs, interactions …) et handles et
réciproquement,
positionner les switchs 130,
manipuler les régions,
acquérir les fréquences de mise à jour (se référer à l’annexe 7.6.4),
gérer les « callbacks 131 »
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
131
Appelés « advisory switchs ».
Services invoqués à l’initiative de la RTI.
103 / 149
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élai 132 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.
104 / 149
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.
Lookahead
Regulating Federate
TR
Time-Stamp-Ordered (TSO) Events
Constrained Federate
TC
Lower Bound Time Constraint (LBTS)
Figure 43
Représentation de l'avance dans le temps d'un fédéré contraint 133
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.
105 / 149
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.
T im e M a n a g e m e n t
T im e S t e p A d v a n c e m e n t
RTI
tim e A d v a n c e R e q u e s t()
tim e A d v a n c e G ra n t()
Figure 44
Exemple d'enchaînement de services de gestion du temps 134
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.
106 / 149
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éthode 135 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.
Condition
d’utilisation
Objet
Recherche
Query
informations sur le
temps
Services
Query Lookahead
X
le fédéré demande la valeur
du lookahead
Query GALT
X
du GALT
Query Logical Time X
de sa date logique
Query LITS
le fédéré demande la date du
prochain
X
message disponible au niveau
RTI
Pas
de
accordé
temps Lookahead Modify Lookahead
X
le fédéré indique une valeur
du lookahead
X
du lookahead
Advance X
le fédéré demande un
avancement du temps à une
date donnée
Query Lookahead
Gestion
temps
avance Advance
Time
Time
Request
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.
107 / 149
Next
Request
Message X
le fédéré demande un
avancement du temps à la
date du prochain message
Flush
Request
Queue X
le fédéré purge les files
d'attentes de messages gérées
par la RTI vers lui même
Time
Grant
Advance
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().
108 / 149
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 XML 137) 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.
109 / 149

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 liens 138 [A15],

Les API Java 139, C++ 140 et les Web services 141 en WSDL 142
138
Dynamic Link Compatibility.
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.
139
110 / 149
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 XML 143. 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
7.4.2.1
Quelques exemples de migration avec l’API C++ 144
Création d’une fédération et participation du fédéré
Le code source à la norme US DoD 1.3 devrait ressembler à ceci 145 :
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.
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.
144
111 / 149

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
RTI 146.

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 :
iHandle = rtiAmbassador->getInteractionClassHandle(L"MyInteraction");
pHandle = rtiAmbassador->getParameterHandle(iHandle, L"MyParameter");
La seule différence réside
« getParameterHandle ».
dans
l’ordre
de
passage
des
paramètres
dans
le
service
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 :
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.
112 / 149
La seule différence réside
« getAttributeHandle ».
dans
l’ordre
de
passage
des
paramètres
dans
le
service
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
« publishObjectClassAttributes ».
7.4.2.3
service
« publishObjectClass »
s’appelle
désormais
Gestion des interactions
Le code pour émettre une interaction à la norme US DoD 1.3 est le suivant :
ParameterHandleValuePairSet* parameters = ParameterSetFactory::create(1);
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";
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,
113 / 149
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és 147. 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 :
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.
114 / 149
Le dual à la norme IEEE 1516-2010 en utilisant un nom réservé d’objet est :
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 :
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";
AttributeHandleValueMap aHandleValueMap;
aHandle = rtiAmbassador->getAttributeHandle(cHandle, L"MyAttribute");
HLAunicodeString unicodeUpdate = HLAunicodeString(update);
115 / 149
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».
116 / 149

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.
117 / 149
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.
118 / 149
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é FDD 148 (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.
119 / 149
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).
120 / 149
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 Services 149, Evoke (Multiple)
Callbacks(s), Enable/Disable Callbacks.
149
Ils ont disparus dans la norme IEEE 1516-2010.
121 / 149
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).
122 / 149
•
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.
123 / 149
•
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.
124 / 149
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
125 / 149
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 :
/***********************************************************
************
126 / 149
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,
127 / 149
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 15162000. 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;
128 / 149
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 cidessous, 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 :
/***********************************************************
************
129 / 149
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
// 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)
130 / 149
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
"RTI_AttributeHandleSet" est définie par "std::set<RTI_AttributeHandle>".
exemple,
la
classe
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
131 / 149
le prototype de la méthode "queryGALT()" de la classe "RTI_RTIambassador", qui dans l'API 15162000 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,
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,
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 :
132 / 149
/***********************************************************
************
File: RTI_Handle.h
************************************************************
***********/
#ifndef RTI_Handle_h
#define RTI_Handle_h
class RTI_bool;
#include <RTI_SpecificConfig.h>
// 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);
133 / 149
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.
134 / 149
7.6
Annexe F : Les apports majeurs de la norme IEEE 1516-2010 à la norme IEEE 1516-2000
La norme IEEE 1516-2010 150 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 (SURR 151), 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
151
Appelée « HLA Evolved » pendant son parcours de normalisation.
Smart Update Rate Reduction.
135 / 149
Figure 45
7.6.1
Les nouvelles fonctionnalités adoptées par la norme IEEE 1516-2010
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é MIM 152. 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.
136 / 149
« 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 HTTPS 153.
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.
137 / 149
Figure 47
RTI avec Services Web
Pour offrir une API de type Services web, une RTI doit disposer d’un composant appelé WSPRC 154
auquel les fédérés peuvent se connecter en utilisant une URL 155.
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
155
Web Services Provider RTI Component.
Uniform Resource Locator.
138 / 149
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 API 156 [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 API 157.
156
157
Dynamic Link Compatibility API.
Evolved DLC API.
139 / 149
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 DLL 158 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.
140 / 149
•
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).
141 / 149
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)-MultiArchitecture 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
142 / 149

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
143 / 149

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
144 / 149
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
145 / 149
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
146 / 149
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 TechnicoOpé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
147 / 149
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
148 / 149
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
149 / 149

[TYPE] DGA - Simulation pour les armées

Transcription

Documents pareils

Middlewares pour les jeux en réseaux

Cliquez ici pour télécharger la présentation

organigramme

Cliquer sur les stations pour afficher les informations - AF

2015-07-02 Osélio - Association Osélio (Les naturistes d`Heliomonde)