Guide utilisateur de la Certification HLA V1certificationhla-france.org/Doc_Certif/CERTIFHLA3_0036_MUT_Guide... · Le service de certification HLA est mis en œuvre en France par

Guide utilisateur de la Certification HLA

Version : V1.3

Date : 07/12/2016

Statut : Validé

Usage : Livrable

Auteur : FRANCE

Type : MUT: Manuel d'utilisation


Version : V1.3

Page : 2/37

SOMMAIRE

1. INTRODUCTION ........................................................................................................................................ 4

1.1 OBJET DU DOCUMENT ................................................................................................................................ 4

1.1.1 A qui s’adresse ce document ?....................................................................................................... 4

1.1.2 A quoi sert-il ? ................................................................................................................................. 4

1.1.3 Comment est-il structuré ? .............................................................................................................. 4

1.1.4 Qui réalise la certification ? ............................................................................................................. 4

1.2 CHAMP D’APPLICATION ............................................................................................................................... 4

1.3 DOCUMENTS DE RÉFÉRENCE ..................................................................................................................... 4

1.4 TERMINOLOGIE ......................................................................................................................................... 5

1.4.1 Sigles .............................................................................................................................................. 5

1.4.2 Définitions ....................................................................................................................................... 7

2. PRINCIPES DE BASE DE LA CERTIFICATION HLA ......... ..................................................................... 8

2.1 CADRE DE LA CERTIFICATION HLA ............................................................................................................. 8

2.1.1 Qu’est-ce que la certification HLA ? ............................................................................................... 8

2.1.2 Quels en sont les objectifs ? ........................................................................................................... 8

2.1.3 A qui la certification est-elle ouverte ? ............................................................................................ 8

2.1.4 Combien cela coûte-t-il ? ................................................................................................................ 8

2.1.5 Qui en sont les intervenants ? ....................................................................................................... 8

2.1.6 Comment se déroule la certification ? ........................................................................................... 8

2.1.7 Qu’est-ce que la certification HLA n’est pas ? ................................................................................ 9

2.2 LA FÉDÉRATION DE TEST ........................................................................................................................... 9

2.3 RÉALISATION DU TEST D’INTERFACE ........................................................................................................ 10

2.4 DÉROULEMENT DU PROCESSUS DE CERTIFICATION ................................................................................... 11

3. ENVIRONNEMENT NÉCESSAIRE À LA CERTIFICATION ....... ............................................................ 12

3.1 CONTRAINTES MATÉRIELLES .................................................................................................................... 12

3.2 CONTRAINTES SUR LES RTI ET LICENCES ASSOCIÉES................................................................................ 12

3.3 CONTRAINTES SUR LES PARE-FEUX .......................................................................................................... 12

3.4 CERTIFICATION DE FÉDÉRÉ CLASSIFIÉ ...................................................................................................... 13

3.5 DURÉE D’UNE CERTIFICATION................................................................................................................... 13

4. DÉROULEMENT DU PROCESSUS DE CERTIFICATION ......... ............................................................ 14

4.1 PRÉSENTATION ....................................................................................................................................... 14

4.2 DONNÉES D’ENTRÉE ................................................................................................................................ 16

4.3 REMARQUES GÉNÉRALES CONCERNANT LA SAISIE DES INFORMATIONS ....................................................... 17

4.4 ETAPE 1 : ENREGISTREMENT DU CANDIDAT ET DE L’APPLICATION (OU DES APPLICATIONS) .......................... 17

4.5 ETAPE 2 : SOUMISSION DES FICHIERS DESCRIPTIFS D’UNE APPLICATION ..................................................... 19

4.6 ETAPE 3 : SOUMISSION DES INFORMATIONS DU TEST D’INTERFACE ............................................................ 21

4.7 ETAPE 4 : RÉALISATION DU TEST D’INTERFACE ET DÉLIVRANCE DU CERTIFICAT. .......................................... 23

4.7.1 Phase de préparation du test par le candidat ............................................................................... 23

4.7.1.1 Informations et recommandations génériques ........................................................................................................... 23

4.7.1.2 Informations et recommandations avant test sur site ................................................................................................. 25

4.7.1.3 Informations et recommandations avant test distant .................................................................................................. 25

4.7.2 Déroulement typique d’un test d’interface .................................................................................... 25

4.7.2.1 Test d’interface sur site ............................................................................................................................................. 25

4.7.2.2 Test d’interface distant .............................................................................................................................................. 26

4.7.3 Description du test d’interface ...................................................................................................... 26

4.7.4 Compte-rendu de certification....................................................................................................... 27


Version : V1.3

Page : 3/37

4.7.5 Délivrance du certificat ................................................................................................................. 27

5. ANNEXES ................................................................................................................................................ 30

5.1 ANNEXE 1 : FORMULAIRE RELATIF À LA CONFIDENTIALITÉ DES DONNÉES DU FÉDÉRÉ ................................... 30

5.2 ANNEXE 2 : PROCESSUS DE CERTIFICATION ............................................................................................. 31

5.3 ANNEXE 3 : FORMULAIRE EN SOUTIEN DE LA PHASE « AFTER ACTION REVIEW » (AAR) .............................. 32

FIGURES

Figure 1 : Certification à distance...................................................................................................................... 9

Figure 2 : Certification en réseau local ............................................................................................................ 10

Figure 3 : Page d’accueil de l’outil FTMS ...................................................................................................... 14

Figure 4 : Suivi de la certification ................................................................................................................... 15

Figure 5 : Les 4 étapes du processus de certification ...................................................................................... 16

Figure 6 : Enregistrement du candidat ............................................................................................................. 18

Figure 7 : Enregistrement d’une application ................................................................................................... 19

Figure 8 : Téléchargement vers le serveur Web des fichiers SOM, CS et FED/FDD ..................................... 20

Figure 9 : Saisie des informations du test ........................................................................................................ 21

Figure 10 : Résultat du test .............................................................................................................................. 22

Figure 11 : Informations pour le certificat ....................................................................................................... 27

Figure 12 : Définition des destinataires ........................................................................................................... 28

Figure 13 : Modèle de certificat ...................................................................................................................... 28


Version : V1.3

Page : 4/37

1. INTRODUCTION

1.1 OBJET DU DOCUMENT

Ce document constitue le guide utilisateur de la certification de conformité au standard HLA.

1.1.1 A qui s’adresse ce document ?

Il est destiné aux personnes souhaitant faire certifier un fédéré HLA (parfois nommé « application » en certification).

1.1.2 A quoi sert-il ?

Il guide les candidats au travers des différentes étapes du processus de certification.

1.1.3 Comment est-il structuré ?

Les principes de base de la certification HLA sont présentés en début de document (chapitre 2). L’environnement associé à la certification HLA est décrit au chapitre 3, puis chacune des différentes étapes du processus de certification est présentée de façon détaillée (chapitre 4), à savoir :

• l’enregistrement du candidat, puis de l’application (ou des applications)

• la soumission des fichiers descriptifs de l’application et la vérification croisée des informations

• la soumission des informations de test d’interface

• la réalisation de ce test (la « vérification dynamique » de la certification) et la délivrance du certificat

Le déroulement du processus de certification s’effectue au travers d’une application Internet dédiée à la certification HLA et appelée FTMS (Federate Test Management System). Cette application sert de plateforme d’échange entre le candidat à la certification et l’agent de certification, pendant le processus de certification.

1.1.4 Qui réalise la certification ?

Le service de certification HLA est mis en œuvre en France par la société Capgemini, à la demande de la DGA. Le centre de certification est situé dans l’établissement de Rennes de la société Capgemini.

1.2 CHAMP D’APPLICATION

Ce document reprend le document HLA-MEC-GDC-01-v4.6.doc produit au titre du marché Certification HLA 2. Il s’applique aux prestations du marché « Prestations de Certification HLA » (« Certification HLA 3 ») [R11] et de son annexe technique [R12].

1.3 DOCUMENTS DE RÉFÉRENCE

N° Référence Nom du document

[R1] Document R&T Organisation

MSG 050 Implementation Plan Final Draft V2 du 15 septembre 2009

MSG-050 Task Group on “Implementation of HLA compliance certification within NATO and NATO/PfP nations”


Version : V1.3

Page : 5/37

N° Référence Nom du document

[R2] Document US DoD

Version 1.3 du 20 avril 1998

High Level Architecture “Framework and Rules “(version 1.3)



High Level Architecture “Interface Specification” (version 1.3)



High Level Architecture “Object Model Template Specification” (version 1.3)

[R5] Document IEEE

Version 1516, septembre 2000

IEEE Std 1516-2000 TM: “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules”

[R6] Document IEEE


IEEE Std 1516.1-2000 TM: “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification”

[R7] Document IEEE


IEEE Std 1516.2-2000 TM: “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification”

[R8] Document IEEE

Août 2010

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

[R9] Document IEEE

Août 2010

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

[R10] Document IEEE

Août 2010

IEEE Std 1516.2-2010 TM: “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification”

[R11] CCAP

Cahier des Clauses Administratives Particulières

Marché n°2012.35.0508.0000.0000

Avenant n°1

[R12] CCTP

Cahier des Clauses Techniques Particulières

Annexé au marché - Avenant n°1

Version C

1.4 TERMINOLOGIE

1.4.1 Sigles

Sigle Signification


Version : V1.3

Page : 6/37

Sigle Signification

AAR After Action Review. Cette revue finale s’appuie sur un questionnaire (composé de questions ouvertes et fermées) pré-rempli par le candidat et finalisé avec l’agent de certification lors d’un entretien (en réunion physique ou téléphonique). L’objectif de la mise en place de ce questionnaire est le recueil d’informations visant à améliorer le processus de certification, une fois le processus achevé

API Application Programming Interface. Spécifications de fonctionnalités décrites sous forme d’interfaces informatiques destinées à être utilisées par les programmeurs dans leurs applications

C++ Langage de programmation utilisé pour le développement d’application

CS Conformance Statement. Document standard à remplir par le candidat sous la forme d’un fichier ASCII reprenant la liste complète des services de HLA avec indication de leur utilisation (ou de leur non-utilisation) par le fédéré à tester FUT

DGA Direction Générale de l’Armement

DMSO Defense and Modeling Simulation Office (US DoD) remplacé depuis 2007 par le MSCO

DIS Distributed Interactive Simulation

e-mail Messagerie électronique

FCTT Federate Compliance Testing Tool : outil utilisé par l’agent de certification afin de pouvoir prcéder aux différents tests.

FDD FOM Document Data (HLA version IEEE 1516)

FED Federation Execution Details (HLA version US DoD 1.3)

FEPW Federation Execution Planner’s Workbook

FOM Federation Object Model

FTMS Federate Test Management System : partie du site web de la certification HLA dédiée au suivi du processus de certification.

FUT Federate Under Test : fédéré soumis au processus de certification

HLA High Level Architecture

HTML HyperText Markup Language : langage de balisage hypertexte utilisé pour écrire des pages Web

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

Java Langage de programmation orienté objet utilisé pour le développement d’application

MÄK RTI Run-Time Infrastructure de la société MÄK Technologies

M&S ou MS Modelling & Simulation

MSCO M&S Coordination Office (US DoD)

MSG Modelling & Simulation Group (OTAN, voir aussi NMSG)

NAT Network Address Translation (mécanisme de transfert d’adresses)

NMSG NATO Modelling & Simulation Group (groupe M&S de l’OTAN)


Version : V1.3

Page : 7/37

Sigle Signification

OMT HLA Object Model Template

OTAN Organisation du Traité de l'Atlantique Nord

pRTI Run-Time Infrastructure de la société Pitch

RID Run-Time Initialization Data : fichier de configuration technique spécifique à chaque RTI

RTI Run-Time Infrastructure

SOM Simulation Object Model

US United States

US DoD United States Department of Defence

WA Web Administrator. Il assure la mise en œuvre et la gestion du site de certification HLA

1.4.2 Définitions

Elément Définition

Agent de certification

Cf. CA.

Application C’est le terme utilisé par l’outil FTMS pour désigner les informations du dossier correspondant au processus de certification d’un fédéré

CA Certification Agent. Il suit tout le processus de certification d’une application. Sa désignation est la responsabilité du WA (voir ci-dessous).

Candidat Personne physique qui veut faire certifier un fédéré

Test d’interface Le test d’interface constitue la « vérification dynamique » de la certification

Web Informations accessibles via Internet, plus précisément World Wide Web ou W3


Version : V1.3

Page : 8/37

2. PRINCIPES DE BASE DE LA CERTIFICATION HLA

2.1 CADRE DE LA CERTIFICATION HLA

2.1.1 Qu’est-ce que la certification HLA ?

La certification HLA est réalisée sous l’autorité d’un organisme d’état (par exemple, la DGA pour la France). Elle conduit à la délivrance d’un certificat de conformité d’applications de simulation ou de simulateurs à l’une des normes HLA (par exemple IEEE 1516-2010).

2.1.2 Quels en sont les objectifs ?

L’objectif est de certifier le fait que le fédéré testé (Federate Under Test ou FUT) permet, grâce à la bonne utilisation du standard HLA, sa réutilisabilité et son interopérabilité. L’objectif est également d’aider le candidat à mieux comprendre ce qu’est le standard HLA, et à quoi il sert.

2.1.3 A qui la certification est-elle ouverte ?

Les services du centre de certification HLA sont ouverts aux industriels français ou européens, ainsi qu’aux établissements du Ministère de la Défense ou des alliés, après acceptation préalable de la candidature par la DGA.

2.1.4 Combien cela coûte-t-il ?

Le service n’est pas facturé si la DGA accepte de parrainer la certification du fédéré sur son contingent de certifications annuel. Dans le cas contraire, un tarif forfaitaire est demandé au candidat à la certification.

2.1.5 Qui en sont les intervenants ?

Le processus met en jeu 3 intervenants :

• le candidat

• l’agent de certification (Certification Agent ou CA), principal interlocuteur du candidat durant tout le processus

• l’administrateur du site de certification (Web Administrator ou WA)

En France, le service du centre de certification HLA est assuré par Capgemini, sous la supervision de la DGA.

2.1.6 Comment se déroule la certification ?

La certification HLA repose sur le déroulement d’un processus formel, avec franchissement d’étapes successives.

Deux outils1 sont utilisés pour réaliser le processus de certification :

• une application Internet (FTMS) présente le processus de certification HLA, et surtout permet au candidat les échanges entre le candidat et le CA durant le processus; le FTMS est accessible par Internet

• un outil de test de fédéré (Federate Compliance Testing Tool ou FCTT) permet de vérifier que le fédéré candidat à la certification utilise correctement les services du RTI, et que les données associées à ces services (production ou consommation des objets et des interactions) respectent les procédures définies dans le standard HLA. Lors du test du FUT, le FCTT effectue les opérations suivantes :

o contrôles syntaxiques des fichiers SOM, CS et FED (norme US DoD 1.3) / FDD (norme IEEE 1516-2000) / FOM (norme IEEE 1516-2010)

1 Ces logiciels sont la propriété du Département de la Défense américain qui en assure la maintenance et l’évolution.


Version : V1.3

Page : 9/37

o contrôles des échanges entre le FUT et le RTI

2.1.7 Qu’est-ce que la certification HLA n’est pas ?

La certification est parfois vécue comme une sanction par les personnes soumettant leur fédéré à ce processus. S’il est vrai que le processus est clairement défini et doit être précisément suivi (l’agent de certification est le garant du respect de ce suivi), la certification doit aussi être l’occasion pour les entités se portant candidates de renforcer ou confirmer leur connaissance de HLA. En effet, certaines informations nouvelles (existence et signification du fichier CS par exemple) seront délivrées au cours du processus par l’agent de certification. Ainsi, l’agent de certification fournit les explications nécessaires au bon déroulement du processus, mais il peut également être sollicité par le candidat pour fournir des explications supplémentaires ou complémentaires lorsque ce dernier en ressent le besoin.

Le but est que le candidat comprenne et adhère à la démarche de la certification, qui est avant tout orientée sur la réutilisabilité du fédéré certifié (l’un des 2 objectifs principaux à l’origine de la norme HLA - même si on peut discuter du fait que HLA ait atteint ou non cet objectif). Pour cela, l’agent de certification fournit les explications nécessaires au bon déroulement du processus, et montre dans quelle perspective s’inscrit ce processus. Le dialogue entre le candidat et l’agent de certification est donc de prime importance ce sur ce sujet.

2.2 LA FÉDÉRATION DE TEST

Le facteur essentiel à l’obtention de la certification HLA est que la 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 façon nominale, le test d’interface est réalisé à distance mais il peut également être effectué sur le site client en cas de contraintes spécifiques (problème d’accès réseau, confidentialité, etc.). Les deux schémas ci-dessous présentent les deux modes de certification, mettant en œuvre le FCTT dans une fédération comprenant le FUT :

RTI ( Run Time Infrastructure)

Fédéré à certifier

Internet

Centre de certification

Fédération HLA

Site Client

Séparation géographique

Fédéré FCTT

Autre(s) fédéré(s)

Réseau local

Pare -feux Pare - feux

Figure 1 : Certification à distance


Version : V1.3

Page : 10/37

RTI (Run Time Infrastructure)

Fédéré à certifier

Fédération HLA

Site Client

Fédéré FCTT

Autre(s) fédéré(s)

Réseau local

Figure 2 : Certification en réseau local

2.3 RÉALISATION DU TEST D’INTERFACE

Avant de réaliser le test d’interface à proprement parler, un travail préparatoire ainsi que des tests « à blanc » sont réalisés pour valider le fait que tous les fédérés de la fédération fonctionnent de façon nominale (aussi bien le FCTT mis en œuvre par l’agent de certification que les autres fédérés mis en œuvre par le candidat, dont le FUT). La durée de ces travaux est très variable (quelques minutes à quelques heures) suivant la complexité de mise en œuvre de la fédération (connexion locale ou distante, environnement classifié ou ouvert).

Lors du test d’interface, le FCTT se comporte comme un fédéré HLA passif qui vient se connecter sur la fédération de test (mise à disposition par le candidat) pour collecter les informations sur le fédéré cible de la certification (FUT).

La fédération utilisée par le candidat pour le test d’interface peut être de deux types :

• une fédération de test mise en place spécifiquement pour la certification

• la fédération nominale dans laquelle fonctionne le FUT

Pour assurer la complétude du test d’interface, la fédération de test doit permettre de valider :

• l’ensemble des informations définies dans le fichier SOM du fédéré à certifier, c’est-à-dire :

o les publications et les souscriptions des classes (classes d’objets et classes d’interactions)

o les envois et les réceptions d’interactions

o les attributs mis à jour et réfléchis

• l’ensemble des appels aux services définis dans le fichier CS

Ainsi, à l’issue du test, l’agent de certification vérifie que les informations déclarées dans les fichiers CS et SOM ont bien été observées au cours de la fédération. Si tel est le cas, le test est terminé avec un avis favorable de l’agent de certification. Dans le cas contraire, l’agent de certification indique au candidat quelles ont été les irrégularités constatées. Le candidat est alors libre de réaliser toute action qu’il juge utile pour corriger ces dysfonctionnements (principalement, correction des fichiers CS et SOM ou correction du fédéré lui-même). Un autre test d’interface être alors réalisé pour satisfaire aux critères exprimés ci-dessus.

La délivrance du certificat est donc conditionnée par la cohérence du comportement du fédéré dans la fédération de test avec le contenu des fichiers SOM et CS.


Version : V1.3

Page : 11/37

2.4 DÉROULEMENT DU PROCESSUS DE CERTIFICATION

Les différentes étapes du processus de certification sont détaillées au chapitre 4. Si une erreur est détectée au cours de ce processus, l’agent de certification est chargé de fournir tous les éléments dont il dispose pour permettre la correction de cette erreur. Cependant, il est de la responsabilité du candidat de définir la réponse à apporter et de procéder à la correction.

Enfin voici les règles du centre de certification concernant l’exploitation des divers éléments fournis par le candidat lors du processus de certification :

- les agents de certification ont accès à toutes les informations fournies par le candidat afin de pouvoir dérouler le processus de certification, et respectent la confidentialité de ces informations ,

- 2 cas doivent être distingués au sujet de l’exploitation des informations par la DGA :

o si le fédéré à certifier est sous maîtrise d’ouvrage de la DGA, celle-ci peut accéder à tous les éléments fournis par le candidat

o si le fédéré à certifier n’est pas sous maîtrise d’ouvrage de la DGA, le centre de certification ne peut diffuser les éléments d’information qui lui sont confiés à la DGA sans un accord préalable du candidat


Version : V1.3

Page : 12/37

3. ENVIRONNEMENT NÉCESSAIRE À LA CERTIFICATION

Avant toute demande de certification le candidat doit s’assurer du respect des contraintes d’environnement suivantes.

3.1 CONTRAINTES MATÉRIELLES

Pour dérouler le processus de certification, le candidat doit disposer des éléments matériels suivant :

• un navigateur et une connexion Internet permettant d’accéder au site de certification

• une adresse e-mail et un numéro de téléphone à fournir à l’agent certificateur permettant d’assurer les échanges tout au long de la certification et en particulier lors du test de l’interface HLA

• une connexion Internet permettant de connecter le fédéré FCTT à la fédération de test

3.2 CONTRAINTES SUR LES RTI ET LICENCES ASSOCIÉES

A ce jour, le FCTT est opérationnel pour les RTI :

• pRTI (Pitch) 1.3 v1.22

• RTI MÄK 1.3, 1516 v2.4.2 et 3.X2

• pRTI (Pitch) 1516 v3.X

• DMSO 1.3 NG v4 et v6

Lors du test de l’interface HLA (4ème étape du processus de certification), les fédérés de la fédération de test ainsi que le fédéré FCTT mis en œuvre par l’agent de certification utilisent les licences fournies par le candidat. A ce jour, le FCTT a besoin d’une licence pour fonctionner avec les RTI suivants :

• pRTI (Pitch) 1.3 v1.22

• RTI MÄK 1.3, 1516 v2.4.2 et 3.X3

• pRTI (Pitch) 1516 v3.X

3.3 CONTRAINTES SUR LES PARE-FEUX

Ce paragraphe concerne les certifications effectuées complètement via l’Internet, et plus particulièrement le test d’interface avec le RTI.

L’une des difficultés majeures rencontrées lors de la mise en œuvre de simulations distribuées sur réseau distant concerne la configuration des pare-feux.

Pour lever cette contrainte, il faut que les pare-feux du côté candidat et du côté centre de certification soient configurés pour laisser passer le flux de données nécessaire à la réalisation du test d’interface (adresse IP de l’équipement distant autorisée à pénétrer, ouverture des numéros de ports). Il faut de plus signaler qu’en présence d’une cascade de pare-feux, il est nécessaire d’ouvrir l’ensemble des pare-feux.

Dans le cas où les contraintes sur les pare-feux ne pourraient être levées (par exemple, dans le cas d’utilisation du mécanisme de transfert d’adresses NAT avec le RTI DMSO 1.3 NG v6), la certification doit alors être réalisée sur le site du candidat.

N.B. : Tous les ports doivent être ouverts pour faire fonctionner le RTI du DMSO. Pour les autres RTIs, la liste des ports à ouvrir sera discuté entre le candidat et l’agent de certification au moment de la préparation du test.

2 Pour ce RTI, une licence propre au CA peut être utilisée. La compatibilité avec les versions 3.3, 3.3.X et 3.4 est en cours de réalisation. 3 Pour ce RTI, une licence propre au CA peut être utilisée. La compatibilité avec les versions 3.3, 3.3.X et 3.4 est en cours de réalisation.


Version : V1.3

Page : 13/37

3.4 CERTIFICATION DE FÉDÉRÉ CLASSIFIÉ

La solution privilégiée par le centre de certification pour certifier un fédéré HLA classifié est la suivante :

• Le candidat met à la disposition de l’agent de certification un PC classifié sur lequel est installé uniquement un système d’exploitation (Windows 2000 ou Windows XP). Ce PC est dédié à faire tourner l’outil de certification et ne doit pas faire fonctionner un autre logiciel pendant la durée du test d’interface

• L’agent de certification utilise un support amovible (par exemple une clé USB) se connectant au PC mis à disposition par le candidat au travers par exemple d’une interface de type USB 2. Le PC doit donc disposer d’une telle interface. Sur ce support se trouve uniquement le logiciel FCTT nécessaire à la réalisation du test d’interface

• Le contenu du support amovible peut être examiné par l’Officier de Sécurité (ou son représentant) avant et après réalisation du test d’interface afin de s’assurer qu’aucune information sensible n’a été récupérée. Si le candidat souhaite que cette clé USB soit détruite, il est demandé qu’il fournisse ce support

• Le matériel mis à disposition par le candidat peut être classifié si nécessaire, et son contenu détruit après l’exécution du test d’interface et une fois les fichiers de résultats du test sauvegardés

L’autre solution possible pour le candidat est d’autoriser l’agent de certification à connecter pour la durée du test d’interface un PC portable non classifié contenant le logiciel nécessaire à la réalisation du test d’interface. Cependant, ce point est soumis à l’autorisation de l’Officier de Sécurité responsable de la plate-forme classifiée.

Les informations sur la classification sont recueillies par l’intermédiaire d’un formulaire descriptif du fédéré (voir Annexe 1 : Formulaire relatif à la confidentialité des données du fédéré).

3.5 DURÉE D’UNE CERTIFICATION

La certification d’un fédéré HLA ne se déroule ni de façon continue ni sur une période de temps fixée, chaque étape pouvant introduire des délais liés à la fourniture de données d’entrées, à la planification des contrôles, à l’activité globale du centre de certification et à la disponibilité des candidats à la certification. Donc, la durée totale d’une certification est variable.

Le tableau ci-après définit un ensemble de délais maximum garantis par le centre de certification lors du traitement d’une demande de certification HLA. Ces engagements ne prennent en compte que les délais imputables au centre, tout retard de la part d’un candidat à la certification dans la fourniture de données d’entrée ne pouvant être imputé au centre de certification.

Type de travaux Délai garanti

Entamer la procédure de certification suite au dépôt d’une demande

1 semaine après réception de l’accord de la DGA

Produire le rapport récapitulatif présentant les résultats des tests et délivrer les certificats de conformité

Moins de 3 semaines après la date du déroulement avec succès des tests d’interface

Si le déroulement d’une certification peut s’étaler sur quelques jours à quelques semaines, il est important de signaler que la charge de travail effective totale demandée au candidat à la certification est estimée en moyenne d’une semaine.


Version : V1.3

Page : 14/37

4. DÉROULEMENT DU PROCESSUS DE CERTIFICATION

Le déroulement du processus repose sur l’utilisation du site FTMS. Actuellement, certaines parties du site - sous responsabilité américaine - ne sont pas traduites de l’anglais à l’exemple de la notice de sécurité4 ou de la librairie de référence. Des évolutions du site Internet seront réalisées à l’avenir pour faire évoluer ces fonctionnalités.

4.1 PRÉSENTATION

La page d’accueil de l’outil FTMS se présente de la façon suivante :

Figure 3 : Page d’accueil de l’outil FTMS

L’accès à cette page se fait par l’adresse Internet http://certificationhla-france.fr/ftms/.

L’accès au site est actuellement suspendu.

4 La notice actuelle correspond aux exigences américaines de sécurité et est en cours de re-définition.


Version : V1.3

Page : 15/37

Cette page présente brièvement les étapes du processus de certification et permet au candidat d’effectuer une demande d’enregistrement, ou de se connecter au service afin de suivre le déroulement de la certification en cours (enregistrement effectué au préalable).

Une fois connecté au service, le candidat peut suivre le déroulement du processus de certification (voir Annexe 2 : Processus de certification) à partir de cette page :

Figure 4 : Suivi de la certification

Le tableau récapitulatif des applications actives permet au candidat ou à un agent de certification de connaître l’avancement de la certification d’un fédéré HLA. Des indicateurs de 3 couleurs sont utilisés :

Vert = action complétée (validée)

Orange = action à réaliser (agent de certification ou candidat) pour compléter l’action (en général, validation des informations soumises)

Rouge = action échouée (correction à apporter pour nouvelle soumission)


Version : V1.3

Page : 16/37

Le processus général de certification se décrit comme l’enchaînement de 4 étapes majeures (cf. [DR1]).

La suite du document est organisée en respectant ce découpage en 4 étapes. Chaque étape ne peut être entamée que lorsque l’étape précédente a été complètement achevée.

SOM

CS

Inscription Client

Validation

Inscription Fédéré

.rid **

Environnement test

planning Exécution

test(s)

Etape 1 Etape 2 Etape 3 Etape 4

Validation

FED/FDD*

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

Validation

Validation

Certification

** pour certaines RTIs

Figure 5 : Les 4 étapes du processus de certificati on

4.2 DONNÉES D’ENTRÉE

Le candidat doit fournir au centre de certification l’ensemble des éléments nécessaires à la réalisation du processus de certification de son fédéré HLA, à savoir :

• le nom du fédéré à certifier

• le fichier SOM de ce fédéré

• le fichier CS (Conformance Statement) de ce fédéré

• le nom de la fédération permettant de valider le fonctionnement du fédéré à certifier

• le fichier FED/FDD de cette fédération

• le fichier RID (pour les RTIs DMSO et MÄK uniquement)

• diverses informations descriptives du candidat, du fédéré et de la fédération

• le fichier FOM de la fédération (non obligatoire mais recommandé)

• toute documentation portant sur le fédéré ou la fédération que le candidat jugera utile de transmettre


Version : V1.3

Page : 17/37

4.3 REMARQUES GÉNÉRALES CONCERNANT LA SAISIE DES IN FORMATIONS

Une zone de saisie d’information (« frame HTML ») est dédiée à chaque étape du processus. Le candidat ne doit saisir que les informations de la zone correspondant à l’étape en cours (par exemple « Informations du Fédéré » pour l’étape 1).

Lors de la saisie des informations, l’utilisation du caractère " est interdite, car elle provoque des dysfonctionnements au niveau du site.

Une fois la zone de saisie renseignée, la mise à jour des données de l’étape au niveau du site s’effectue en cliquant sur le bouton « Update » situé à la fin de chaque cadre.

L’utilisation du bouton « Envoyer un mail au Client » est réservée à l’agent de certification.

4.4 ETAPE 1 : ENREGISTREMENT DU CANDIDAT ET DE L’AP PLICATION (OU DES APPLICATIONS)

Dans le cas où le candidat souhaite être parrainé, l’acceptation d’un candidat à la certification est soumise à deux demandes d’autorisation auprès de la DGA :

• la première après l’enregistrement de la personne physique

• la seconde après l’enregistrement du (des) fédéré(s) à certifier

Enregistrement du candidat :

N.B. : Dans le cas où le candidat est déjà inscrit sur le site (dans la mesure où le processus de certification d’un premier fédéré est en cours ou terminé), le candidat doit utiliser son profil pour accéder au site et ne doit pas procéder à une nouvelle inscription. Si néanmoins une nouvelle inscription est réalisée, elle sera ignorée et l’agent de certification indiquera d’utiliser le profil déjà enregistré.

Cette étape concerne l’enregistrement d’un nouveau candidat. Elle est réalisée à partir de la page d’accueil. Le candidat doit saisir les informations relatives à sa société ou son organisme d’appartenance. L’adresse e-mail constitue le login de l’utilisateu r. Un mot de passe est demandé à l’utilisateur pour les futures connexions. Enfin, la langue dans laquelle vont s’afficher les messages lors des futures connexions doit être choisie (2 choix à ce jour : Anglais ou Français).


Version : V1.3

Page : 18/37

Figure 6 : Enregistrement du candidat

L’administrateur du FTMS voit apparaître le nouveau candidat lors de sa connexion au site. Il doit soit rejeter la candidature, soit l’approuver, selon l’avis de la DGA. Il signale le résultat au candidat par messagerie.

Enregistrement d’un fédéré à certifier :

Le candidat doit attendre un retour positif pour pouvoir se connecter au site. Le candidat se connecte au FTMS grâce à son e-mail et son mot de passe. Il saisit (création) alors les informations générales relatives au fédéré HLA à certifier (application).


Version : V1.3

Page : 19/37

Figure 7 : Enregistrement d’une application

N.B. 1 : l’ajout d’une nouvelle société / organisme à la liste proposée est réalisé par appui sur le bouton « VIEW/ADD Organization ». Une page spécifique permet la saisie des informations. Une fois les informations saisies, l’appui sur le bouton « ADD » provoque le retour à la page précédente.

N.B. 2 : le nom du fédéré fourni par le candidat correspond à l’identifiant utilisé depuis le tableau général des applications pour avoir accès au détail des informations de la certification (voir Figure 4). Ce nom peut être différent du nom utilisé par le fédéré pour se déclarer auprès du RTI.

A nouveau l’administrateur doit soit approuver la candidature, soit la rejeter, après l’accord de la DGA. Il signale sa décision au candidat par messagerie. De plus, l’administrateur du FTMS désigne l’agent de certification qui va réaliser la certification en prenant en charge le déroulement de la suite du processus (passage de relais).

4.5 ETAPE 2 : SOUMISSION DES FICHIERS DESCRIPTIFS D’UNE APPLICATION

Le candidat doit télécharger vers le serveur Web les 3 fichiers (SOM, CS et FED/FDD) nécessaires à la description du fédéré HLA.


Version : V1.3

Page : 20/37

Figure 8 : Téléchargement vers le serveur Web des f ichiers SOM, CS et FED/FDD

Concernant la norme IEEE 1516-2010, plusieurs modules de SOM (chacun correspondant à un fichier distinct) peuvent être nécessaires au fonctionnement du fédéré, alors qu’un seul champ est prévu pour déposer ces fichiers sur le site web. Il en est de même pour les modules de FOM. Dans ce cas, l’utilisateur doit créer un seul fichier Zip (contenant l’ensemble des fichiers nécessaires) et le télécharger dans le champ adéquat.

N.B. : un exemple de fichier CS pour chacune des versions 1.3 et 1516-2000 et 1516-2010 des spécifications HLA est fourni au niveau du site Internet, dans la section « Données sur l’environnement », à côté du champ « Version de la Norme HLA » (cf. Figure 9). Un clic sur le numéro de la norme permet de récupérer le fichier, qui est complété par le candidat en fonction des possibilités offertes par son fédéré. Le candidat doit ensuite déposer ce fichier (qui constitue le CS de son fédéré) sur le site Web de la certification.

Une fois les documents SOM, CS et FED/FDD déposés par le candidat sur le site de certification, l’agent de certification procède à leur analyse à l’aide de l’outil FCTT.

L’analyse réalisée est composée d’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

Ces tests reposent sur des règles (dont des règles d’inférence) de 2 types :

• dépendance entre 2 services (si deux services sont dépendants l’un de l’autre, lorsque l’un des deux est appelé, l’autre doit l’être également)

• croisement des informations présentes dans 2 fichiers (exemple : la publication d’une classe d’objets implique l’utilisation du service de publication correspondant)

Une fois l’étape d’analyse des fichiers réalisée, l’agent de certification indique le résultat du test dans le FTMS et le communique au candidat via la messagerie.

Si les corrections demandées par l’agent de certification ne portent que sur un seul des trois fichiers analysés, le FTMS permet au candidat de transmettre une nouvelle version de ce seul fichier.


Version : V1.3

Page : 21/37

4.6 ETAPE 3 : SOUMISSION DES INFORMATIONS DU TEST D ’INTERFACE

Dans cette étape, le candidat renseigne l’ensemble des informations relatives à l’environnement du test d’interface (en vue de la connexion du fédéré FCTT avec la fédération de test).

Figure 9 : Saisie des informations du test

Le candidat saisit sous le FTMS les informations descriptives de l’environnement de test d’interface. Certaines informations sont obligatoires, d’autres facultatives. A noter que ces informations doivent décrire la plate-forme sur laquelle fonctionne le fédéré à certifier (et la fédération dans laquelle il est inclue), et non pas la plate-forme sur laquelle va fonctionner le fédéré FCTT (cela est la responsabilité de l’agent de certification). Les informations obligatoires sont :

• la version de la norme HLA (cette information peut être déduite à partir du format des fichiers SOM et FOM fournis précédemment, mais elle doit néanmoins être saisie ici5)

• le type et la version du RTI utilisée par la fédération. Exemples : DMSO NG v4, MÄK v3.0.1, Pitch v3.2.1

• l’indication d’un test par Internet6 ou non

• dans la mesure où le test sera réalisé par Internet, l’indication de présence ou d’absence d’un pare-feu

• l’indication d’un essai classifié ou non

• le type d’API utilisée par le fédéré à certifier (C++, Java, etc.)

5 Ce problème sera corrigé avec la prochaine version du FTMS. 6 Il s’agit du mode nominal de réalisation du test d’interface.


Version : V1.3

Page : 22/37

• la description de la plate-forme

• l’identification du système d’exploitation

• l’adresse IP et le nom de l’hôte du processus RTIExec, quelle que soit le RTI utilisée ; cette information devient facultative si le test est réalisé dans un environnement classifié

La fourniture de l’adresse IP et le nom de l’hôte du processus fedex n’est pas obligatoire. De plus, l’information « Nom du fichier FPW » n’est pas nécessaire.

N.B. : Le fedex est la contraction de « Federation Exécution ». Il s’agit d’un programme en charge de la gestion d’une fédération. En théorie, le RTIexec lance un fedex pour chaque nouvelle fédération. Néanmoins, dans la pratique, cela dépend de l’implémentation des RTI, et cette notion de fedex n’apparaît pas à l’utilisateur pour les RTIs MÄK et Pitch (elle existait pour le RTI DMSO). Le fedex (lorsque cette notion est réellement implémentée par le RTI) est par défaut sur la même machine que le RTIexec.

Pour les RTI DMSO et MÄK, le fichier RID7 doit obligatoirement être fourni. En effet, l’agent de certification doit vérifier les valeurs de certains paramètres dans ce fichier afin de s’assurer que l’outil de certification pourra fonctionner nominalement lors de la réalisation du test d’interface.

Par contre, le fichier FOM produit au titre du respect de la norme, le fichier Scénario et le fichier FEPW (produit par l’outil FEPW) ne sont pas obligatoires au niveau du FTMS. Cependant il est recommandé de fournir le fichier FOM pour être en cohérence avec la norme.

N.B. : Pour la version 1.3 de la norme HLA, le fichier FOM (différent du fichier FED) a une extension « .omt ». Pour les versions 1516-2000 et 1516-2010 de la norme HLA, le fichier FOM correspond au fichier FDD et n’a pas besoin d’être fourni de nouveau.

Les fichiers « Nom d’un autre fichier n.1 », « Nom d’un autre fichier n.2 » donnent la possibilité à l’utilisateur de déposer de la documentation complémentaire au niveau du FTMS.

L’agent de certification valide ou non les informations de description de l’environnement de test. Il envoie un message au candidat pour signaler le résultat de cette validation.

Lorsque l’environnement de test est correct, l’agent de certification propose une date et une heure de test dans le champ dédié de la section « Informations du test ».

Figure 10 : Résultat du test

7 Nom du fichier : RTI.rid pour le RTI DMSO et rid.mtl pour le RTI MÄK.


Version : V1.3

Page : 23/37

Il appartient alors au candidat de valider ou non cette date. Si cette date n’est pas acceptée, l’agent de certification propose une nouvelle date jusqu’à ce qu’il y ait accord du candidat.

Un champ de texte libre « Commentaires » permet un échange d’informations entre l’agent de certification et le candidat.

Le nom du fédéré saisi par le candidat à la première étape du processus de certification ne correspond pas obligatoirement au nom réellement utilisé par le fédéré lorsqu’il joint la fédération (par exemple, à cause d’une différence de casse). Même si ces noms sont identiques, le candidat doit à nouveau saisir le nom exact du fédéré à certifier en remplissant la zone d’information dédiée dans la section « Informations du test » du FTMS, ce nom étant utilisé par le FCTT pour identifier le fédéré à observer.

4.7 ETAPE 4 : RÉALISATION DU TEST D’INTERFACE ET DÉ LIVRANCE DU CERTIFICAT.

4.7.1 Phase de préparation du test par le candidat

Avant le test d’interface (la « vérification dynamique » de la certification), le candidat doit prendre connaissance de certaines informations et recommandations. Certaines sont génériques, certaines sont spécifiques aux tests sur site tandis que d’autres sont spécifiques aux tests distants.

4.7.1.1 Informations et recommandations génériques

Action 1

L'outil de test (fédéré FCTT), comme tout fédéré HLA, nécessite une licence du RTI pour fonctionner. Cette licence peut soit être une licence dont dispose l’agent de certification, soit être prêtée par le candidat. Ce point doit être discuté et validé avant de procéder au test.

Action 2

Afin que le FCTT fonctionne, il est nécessaire que :

• pour les fédérés 1.3, dans le fichier FED, l’attribut ReportServiceInvocation soit à la valeur Reliable

• pour les fédérés 1516-2000, dans le fichier FDD, l’attribut ServiceReporting de l’élément switches soit à la valeur Enable

• pour les fédérés 1516-2010, dans le fichier XML, l’attribut serviceReporting de l’élément switches soit à la valeur true

• en cas d’utilisation du RTI MÄK uniquement, dans le fichier RID, le paramétrage suivant est obligatoire pour que l'outil de certification fonctionne :

(setqb RTI_useRtiExec 1) (setqb RTI_internalMsgReliable 1)8 ou (setqb RTI_internalMsgReliableWhenUsingRtiexec 1)9 (setqb RTI_fomDataReliable 1)10 ou (setqb RTI_fomDataReliableWhenUsingRtiexec 1)11 (setqb RTI_timeMgmt 1) (setqb RTI_dataDistMgmt 1) (setqb RTI_momServiceAvailable 1) (setqb RTI_momFederateUpdateInterval 0) (setqb RTI_strictFomChecking 1) (setqb RTI_checkFlag 1) (setqb RTI_enableHlaObjectNamePrefix 1) (setqb RTI_sendDiscoveredClass 1) (setqb RTI_extend13and1516interop 0)12

8 Jusqu’à la v3.2 9 A partir de la v3.3 10 Jusqu’à la v3.2 11 A partir de la v3.3 12 A partir de la v3.4


Version : V1.3

Page : 24/37

(setqb RTI_processUnknownUpdatesForDiscovery 0) (setqb RTI_strictNameReservation 1) (setqb RTI_enableNameReservation 1) (setqb RTI_momServiceReporting 1)

A noter que pour positionner en une seule fois toutes les valeurs de ces paramètres sauf RTI_momServiceReporting, une possibilité est d’activer le flag RTI_forceFullCompliance situé en début de fichier

Action 3

Afin qu’il puisse détecter l’ensemble des services utilisés par le fédéré à certifier, le FCTT doit être le premier fédéré joignant la fédération et le dernier quittant la fédération. En conséquence, il est très fortement recommandé, dans la procédure de lancement de la fédération, de découpler le lancement du RTI et celui des fédérés afin que le lancement du FCTT puisse être réalisé entre les deux.

Action 4

Afin de générer certains callbacks particuliers (attributesInScope, attributesOutOfScope, removeObjectInstance par exemple), il est fortement recommandé que le fédéré à certifier soit le premier fédéré à joindre la fédération (juste après le FCTT) et le dernier à quitter de la fédération (juste avant le FCTT).

Autres points

L’ajout du fédéré FCTT dans la fédération de test peut avoir des impacts importants sur le fonctionnement de la fédération , d’autant plus si cette fédération a pour objectif principal la performance de fonctionnement. Cela est principalement le cas pour les fédérations dites « temps réel dur » avec homme dans la boucle. En effet, de nouveaux échanges entre le FCTT et les autres fédérés de la fédération vont avoir lieu au cours du test, ce qui vient « alourdir » les échanges réalisés au sein de la fédération. En conséquence, le comportement de la fédération peut en être altér é (par exemple, perte d’informations, délai de réaction allongé) un iquement par la présence du FCTT .

Cela s’explique par l’utilisation du mécanisme de Service Reporting utilisé par le FCTT pour collecter les informations sur les actions réalisées par les autres fédérés : à chaque fois qu’un service est appelé ou qu’un callback est reçu par un fédéré, le RTI génère à destination du FCTT une interaction spécifique avec l’ensemble des informations détaillant cet appel (identifiant du fédéré, service / callback utilisé, paramètres du service / callback). Il en résulte donc que le volume des échanges au sein de la fédération va augmenter de manière conséquente, et il est nécessaire que l’infrastructure et les logiciels utilisés soient capables de supporter cette charge supplémentaire.

Le FCTT est un fédéré purement passif, qui ne « stimule » pas le fédéré à certifier, mais qui « espionne » les échanges HLA qui ont lieu entre les fédérés de la fédération. Le candidat doit donc mettre en œuvre le fédéré à certifier au sein d’une fédération complète, dite « fédération de test ». Cette fédération a pour but de démontrer les capacités fonctionnelles HLA du fédéré à certifier, c'est-à-dire :

• publier/souscrire toutes les classes d’objets et d’interactions de son SOM ; créer, mettre à jour et détruire des objets correspondant à toutes les classes d’objets publiées dans son SOM; découvrir, recevoir des mises à jour et recevoir l’ordre de destruction des objets correspondant à toutes les classes d’objets souscrites dans son SOM ; envoyer et recevoir des interactions conformément à toutes les publications / souscription des classes d’interactions de son SOM

• appeler l’ensemble des services listés dans son fichier CS


Version : V1.3

Page : 25/37

4.7.1.2 Informations et recommandations avant test sur site

Action 5

Il sera nécessaire de connecter un PC portable Capgemini sur le réseau où fonctionne le fédéré à certifier. Cela sous entend :

1. qu’il faut s'assurer que cela est compatible de la politique de sécurité du site

2. que cela est possible techniquement (prise de courant disponible, prise Ethernet disponible sur hub/routeur et Adresse IP disponible pour le PC de l’agent de certification)

4.7.1.3 Informations et recommandations avant test distant

Les divers protocoles utilisés par les RTI ne permettent pas l’utilisation du mécanisme de NAT (Network Address Translation) pour séparer le réseau local sur lequel fonctionne la fédération d’Internet. En effet, dans un tel cas, la transformation des adresses, si elle n’est pas gérée à la volée par les routeurs, n’est pas réalisée par le RTI. Cela a pour conséquence qu’un fédéré situé dans un premier réseau local utilisera une adresse locale au second réseau sur lequel fonctionne les autres fédérés de la fédération pour dialoguer avec ces fédérés. Cela aboutira donc à un échec. Pour contourner cette difficulté, deux solutions sont envisageables :

1. L’utilisation par toutes les machines mises en jeu pendant le test d’interface d’adresses IP publiques. Cela est le cas de la machine utilisée par l’agent de certification. Néanmoins, cela peut poser des problèmes de sécurité importants qui peuvent aboutir au rejet de cette solution,

2. La mise en place d’un VPN temporaire entre le site du candidat et celui de l’agent de certification. Cela engendre nécessairement un travail non négligeable de configuration et de test du VPN qui implique les administrateurs réseau de chaque site.

Afin de procéder par étape dans la validation du bon fonctionnement de la liaison distante, les tests suivants seront réalisés (dans cet ordre) :

1. Test du ping (à autoriser au niveau des firewalls),

2. Test d’ouverture des ports par la commande telnet,

3. Test de fonctionnement d’une fédération de démonstration,

4. Test de fonctionnement du RTI avec le FCTT,

5. Test de fonctionnement du RTI, du FCTT et des autres fédérés, dont le fédéré à certifier (test « à blanc »).

4.7.2 Déroulement typique d’un test d’interface

4.7.2.1 Test d’interface sur site

Les différentes étapes sont :

1. Arrivée de l’agent de certification,

2. Présentation des personnes et de l’organisation des étapes du test,

3. Installation du matériel et tests « à blanc » avec pour objectif un fonctionnement nominal de la fédération de test incluant le FCTT,

4. Réalisation du test à proprement parler,

5. Entretien entre le candidat et l’agent de certification pour recueillir le sentiment du candidat sur le déroulement du processus de certification (AAR – After Action Review).

Il est extrêmement difficile de se prononcer sur la durée de l’étape 3), qui est l’étape la plus délicate. La durée au plus court des 5 étapes précédentes est de l’ordre d’une demi-journée. Néanmoins, lorsque des problèmes techniques surviennent (problématique réseau, dysfonctionnement logiciel, …), il est très facile de « perdre » rapidement une demi-journée.

En conclusion, dans le meilleur des cas, le test durera une demi-journée. Dans le pire des cas (cela est déjà arrivé), le test ne peut être mené à terme et nécessite de programmer une nouvelle intervention.


Version : V1.3

Page : 26/37

Afin d’organiser au mieux cette intervention, merci de fournir les informations suivantes :

1. Adresse exacte du site d’intervention,

2. Nom et moyen de contact (téléphone et adresse de messagerie) du point de contact local au site d’intervention,

3. Outre les noms des agents de certification, liste des informations nécessaires à fournir pour accéder au site,

4. Liste des participants avec le nom de leur organisme / société d’appartenance.

4.7.2.2 Test d’interface distant

Les différentes étapes sont :

1. Vérification du bon fonctionnement de la liaison (cf.ci-avant),

2. Réalisation du test à proprement parler,

3. Echange par téléphone ou messagerie entre le candidat et l’agent de certification pour recueillir le sentiment du candidat sur le déroulement du processus de test.

Afin d’organiser au mieux cette intervention, merci de fournir les informations suivantes :

1. Nom et moyen de contact (téléphone obligatoire et adresse de messagerie) du point de contact,

2. Liste des participants avec le nom de leur organisme / société d’appartenance.

4.7.3 Description du test d’interface

Le test d’interface implique la participation à la fois du candidat et de l’agent de certification. C’est l’agent de certification qui dirige le test, puisqu’il est dépendant des contraintes de fonctionnement du FCTT.

Le test d’interface est exécuté par l’agent de certification à l’aide de l’outil FCTT sur la base des informations précédemment enregistrées.

Le test d’interface se déroule de la façon suivante :

• le candidat, dépositaire de la licence, lance le RTI,

• l’agent de certification crée la fédération, et le fédéré FCTT se joint à cette fédération,

• les fédérés constituant la fédération de test joignent à leur tour la fédération,

• lors de l’exécution de la fédération de test, l’agent certificateur vérifie, à l’aide de l’outil FCTT :

o la cohérence des appels aux services effectués avec ceux définis dans le fichier CS,

o la cohérence des publications et des souscriptions des classes effectuées avec celles définies dans le fichier SOM,

o la cohérence des attributs réfléchis et mis à jour avec ceux définis dans le fichier SOM.

• l’agent de certification demande au candidat s’il considère que l’exécution de la fédération de test s’est déroulée de manière nominale, en démontrant toutes les capacités du fédéré sous test.

• quand cette condition est vérifiée, le candidat résilie l’ensemble des fédérés constituant la fédération de test,

• l’agent certificateur résilie le fédéré FCTT de la fédération, et détruit celle-ci,

• le candidat arrête le RTI,

• une restitution des résultats a lieu, le jour du test, entre l’agent de certification et le candidat. Deux possibilités s’offrent alors :

o la cohérence des informations échangées a pu être vérifiée : le test est réussi,


Version : V1.3

Page : 27/37

o la cohérence des informations échangées n’a pas pu être vérifiée : le test a échoué. L’agent certificateur signale les non-conformités observées et le candidat doit procéder aux modifications nécessaires avant la planification d’un nouveau test d’interface.

Après l’adoption d’une position commune sur les résultats du test d’interface entre l’agent de certification et le candidat, le statut officiel du résultat est reporté au niveau du FTMS. Pour cela, l’agent de certification initialise les champs suivants : le succès/l’échec du test, la date et l’heure associées, le numéro de version du test (correspond au nombre de tests nécessaires avant succès). Le candidat est informé de ce résultat par un message envoyé par l’agent de certification.

Si un nouveau test de l’interface doit être réalisé, le processus de certification est repris à l’endroit nécessaire en fonction des modifications apportées au fédéré par le candidat.

4.7.4 Compte-rendu de certification

Une fois le test de l’interface passé avec succès, un compte-rendu de certification est transmis à la DGA et au candidat. Ce compte-rendu contient 4 types d’information :

• des informations sur le fédéré testé (nom, version, développeur),

• la configuration de test (l’API, les fichiers FED/FDD et RID),

• des commentaires sur les résultats des différents tests (vérification des fichiers et test de l’interface),

• les données relatives au fédéré (fichiers SOM et CS).

4.7.5 Délivrance du certificat

Le candidat se connecte au FTMS, et saisit les informations « Nom officiel du fédéré » et « Version du fédéré » qui vont être reportées sur le certificat de conformité HLA.

Figure 11 : Informations pour le certificat


Version : V1.3

Page : 28/37

De plus, le candidat précise les informations sur l’identification de la ou des personnes destinataires du certificat. Pour confirmer sa demande, le candidat coche la case « Demande » correspondant à chaque profil saisi.

Figure 12 : Définition des destinataires

L’agent de certification réalise alors un certificat original pour chaque destinataire, et en fait une copie pour l’archivage.

Figure 13 : Modèle de certificat

N.B. : l’envoi de certificat n’est prévu qu’une seule fois, il est donc inutile d’ajouter de nouveaux destinataires après coup.

En règle générale, 3 certificats originaux maximum sont produits : 1 pour le développeur, 1 pour le candidat et 1 pour l’organisation/la société à qui appartient le fédéré certifié.


Version : V1.3

Page : 29/37

Une fois l’ensemble des certificats envoyés, le processus de certification est terminé. Dans le tableau récapitulatif des fédérés inscrits au processus de certification, les indicateurs sont au vert pour toutes les étapes de la certification de ce fédéré. Il est alors ajouté à la liste des fédérés certifiés.

A l’issue de la certification, l’agent certificateur réalise un bilan avec le candidat (voir Annexe 3 : Formulaire en soutien de la phase « After Action Review » (AAR)) sur :

• la certification effectuée et le processus de certification en général,

• le travail consenti pour le développement du fédéré HLA (adaptation d’une simulation existante à la norme HLA, développement d’un nouveau fédéré, etc.).

A cette occasion, le candidat rempli en présence de l’agent certificateur un questionnaire lié à la confidentialité des informations (cf. Annexe 1 : Formulaire relatif à la confidentialité des données du fédéré).

L’AAR constitue l’étape finale du processus.

Les informations sont ensuite analysées par le centre de certification pour alimenter les statistiques sur la certification HLA, et permettre d’alimenter la réflexion sur l’amélioration du processus de certification.


Version : V1.3

Page : 30/37

5. ANNEXES

5.1 ANNEXE 1 : FORMULAIRE RELATIF À LA CONFIDENTIAL ITÉ DES DONNÉES DU FÉDÉRÉ

INFORMATIONS SUR LE DEMANDEUR :

Nom du client :

Société / Organisme :

Adresse :

Téléphone :

Nom du point de contact pour le fédéré :

INFORMATIONS SUR LE FEDERE :

Nom du fédéré :

INFORMATIONS SUR LA CONFIDENTIALITE APPLIQUEE AU FE DERE : Niveau de classification du fédéré :

Accord pour la publication du fichier SOM du fédéré si demande est faite au centre de certification, après accord de la DGA : Oui - Non

Accord pour la publication du fichier CS du fédéré si demande est faite au centre de certification : Oui - Non

Accord pour la publication des autres éléments documentaires fournis sur le fédéré si demande est faite au centre de certification : Oui - Non

Date : Signature :


Version : V1.3

Page : 31/37

5.2 ANNEXE 2 : PROCESSUS DE CERTIFICATION

Enregis trement d’un nouveau candida t

Candidat ref usé

L’administrateur est a lerté d’une nouve lle demande

Candidat accepté

- Connexion du candidat,

- Créat ion e t édition d’une nouve lle application

Demande de

cert if icat ion

Demande de

cert if icat ion

Complet 1

Incomple t

Approuvé

L’adminis trateur examine la nouvelle applica tion à tes te r

Applica tion

approuvée

Cor rection de l’application par le candidat

ApprouvéOui

Non

Oui

Non

A Le candidat té lécharge les fichiers SOM /CS

S OM/CS Test des f ichiers SOM /CS par l’agent cert if icat eur

Tes t des f ichiers SOM/CS passé avec succès

SOM /CSDéfinition de l’environnement de test , téléchargement des fichie rs complémenta ires 3

Condit ions du t es t

Condit ions du t es t

Complet 4

Incomplet

B

A

BL’agent cer tifica teur définit la da te du tes t d’inte rf ace

Test d’inte rface 2

Date du test

Le c lient rense igne ses disponibilités pour le test d’inte rf ace

Le candida t prend connaissance de la date du test d’inter face

Date du tes t accepté

Date du t es t

Date du testRéalisa tion du test par le candida t et par l’agent cert if ica teur

Test d’inte rface e ffect ué

Tes t d’int er face

Oui

NonC

C Test d’inte rface Destinata iresLe candida t complèt e les inf ormations du cert if ica t e t définit les dest ina ta ires

Certificat envoyé

Destinataires

L’agent cer tificateur transmet les cer tificats au candidat et à l’ensemble des destina taires

Certificat envoyé Processus term iné

S OM/CS

Oui

Non

Oui

Non

Etape passée avec succès et poursuite du processus

Attente d’une action

Echec

Action du candidat

Action de l’agent certificateur



Echec

Action du candidat




Echec

Action du candidat


1. Vérification de la description, du nom et de la version du fédéré, 2. Seulement à partir de la deuxième itération

3. FED/FDD, RID, FPW, FOM, Fichier autre1, Fichier autre 2

4. Vérification de l’API, de la plate-forme, du système d’exploitation, du nom de la machine hôte du RTI, de l’adresse IP du RTI, du nom de la machine hôte du fédéré, de l’adresse IP du fédéré


Version : V1.3

Page : 32/37

5.3 ANNEXE 3 : FORMULAIRE EN SOUTIEN DE LA PHASE « AFTER ACTION REVIEW » (AAR)

Le questionnaire doit être rempli dans un entretien entre le certifié et le CA.

Formulaire After Action Review (AAR) INFORMATION SUR LA SIMULATION Nom de la Simulation :

Nom du Développeur de la Simulation :

Organisation du Développeur de la Simulation :

INFORMATION SUR LE POINT DE CONTACT (POC) Prénom :

Nom :

Email:

Numéro de téléphone :

Notez que les questions marquées du sigle (*) peuvent avoir des réponses multiples.

A. INFORMATIONS DE HAUT NIVEAU SUR LE FEDERE (ET L A FEDERATION) A1 Informations générales sur le Fédéré A11. Quel est le type de votre application de simu lation (par rapport aux types classiques) ?

1. Live Simulation (Simulation impliquant des personnels réels opérant les systèmes réels)

2. Virtual Simulation (Simulation impliquant des personnels réels opérant les systèmes virtuels)

3. Constructive Model or Simulation (Simulation impliquant des personnels simulés opérant les systèmes simulés)

A12. Quel est le domaine d’application de la fédér ation ? (*) 1. Analyse / Expérimentation

2. Acquisition / Test

3. Entrainement / Formation

4. Support opérationnel

A13. Votre fédération est-elle temps réel ?

1. Oui

2. Non

A14. Quelle version du standard HLA utilisez-vous ? 1. US DoD 1.3

2. IEEE 1516-2000

3. IEEE 1516-2010 (Evolved)

A15. Avez-vous planifié ou démarré la transition v ers un standard plus récent ? 1. Oui. Version future :

2. Non

3. N/A


Version : V1.3

Page : 33/37

A16. La fédération est-elle classifiée ? 1. Oui

2. Non

A2 Information sur la réutilisation A21. Le fédéré

1. Existait déjà et a été modifié pour fonctionner dans la fédération cible

2. Etait un nouveau fédéré développé spécifiquement pour la fédération

A3 Conception et développement du fédéré A31. Méthodologies/outils utilisés pour la concept ion et le développement du fédéré ? (*)

1. MDA/MDE 2. UML

3. RUP

4. Autre(s). Précisez :

5. Aucune

A32. Quel est le langage d’implémentation PRINCIPA L du fédéré ? 1. Ada

2. C

3. C++

4. C#

5. FORTRAN

6. Java

7. Autre. Précisez :

A33. Quel est le langage de l’API HLA utilisée ? 1. Ada

2. C++

3. Java

4. WSDL

A34. Avez-vous utilisé un environnement de dévelop pement ? 1. GOTS (Government off the Shelf)

2. COTS (Commercial off the Shelf)

3. Environnement “maison”. Précisez :

4. Aucun (développement « from scratch »)

A35. Avez-vous utilisé un middleware HLA autre que la RTI ? (*) 1. Passerelle de protocoles

2. Middleware indépendant d’un protocole

3. Autre. Précisez :


Version : V1.3

Page : 34/37

A4 Expérience dans le domaine de la simulation A41. Comment caractériseriez-vous votre expérience en programmation ainsi que celle de votre équipe de développement rapport au développement de simulations ?

1. Haute, expérience importante.

2. Modérée, quelques expériences, mais le développement de simulation n’est pas notre métier principal.

B. NIVEAU DE L’EFFORT (RELATIF A HLA) B1. Nombre d’homme(s) / mois (d’homme / jour ?) dé dié à rendre le fédéré conforme à HLA :

1. Nombre d’hommes / mois :

2. Non applicable.

B2. Nombre de personne affectées à ce projet :

B3. Est-ce que le coût de la transition a impliqué des dépenses au-delà de celles spécifiquement nécessaires pour la transition à HLA ? (Les exemples peuvent inclure : réécriture du code de la simulation, achat d’un équipement et/ou mise à jour de l’infrastructure, augmentation des capacités des modèles, etc.)

Veuillez s’il vous plait estimer le niveau de l’effort dédié à HLA exprimé en temps de l’équipe. Essayer de séparer le développement de la simulation de l’intégration HLA.

C. EXPERIENCE EN HLA ET SUPPORT HLA C1. Comment caractériseriez-vous votre niveau d’ex périence par rapport à HLA ?

1. Elevé. Nous nous sommes impliqué dans le programme HLA depuis ces premiers développements.

2. Modéré. Nous connaissons bien les concepts et les principes, mais nous n’avons jamais participé à l’effort de développement de HLA.

3. Peu élevé. Jusqu’à ce que nous ayons à faire ce travail, nous ne nous étions pas impliqués sur HLA.

C2. Avez-vous (vous ou votre équipe de développeme nt) eu accès à un support (aide) extérieur au cours de l’implémentation ? (*)

1. Session de formation dédié à HLA. Précisez :

2. Assistance sur HLA. Précisez :

3. Contact commercial. Précisez :

4. Autre. Préciser :


Version : V1.3

Page : 35/37

D. DETAILS TECHNOLOGIQUES SUR HLA D1. Quelle version du RTI utilisez-vous (soyez pré cis sur la version utilisée)? (*)

1. DMSO RTI 1.3 NG version :

2. MÄK RTI 1.3 version :

3. MÄK RTI 1516 version :

4. Pitch RTI 1.3 version :

5. Pitch RTI 1516 version :

6. Pitch RTI 1516-2010 version :

7. SAIC/VTC RTI 1.3 NG Pro version :

8 Autre : version :

D2. Quels outils de support avez-vous utilisé (en respectant la taxinomie définie par le groupe OTAN MSG-005) ? (*)

1. Outil / environnement de développement de fédérés / fédération (OMDT, environnement de simulation, etc.)

2. Générateur d’environnement naturel

3. Développement de scénario

4. Outil dédié à l’exécution de la fédération (Outil de gestion de la fédération, collecteur de données, etc.)

5. Visualisation

E. PAR RAPPORT AU PROCESSUS DE CERTIFICATION HLA E1. Etes-vous globalement satisfait du processus d e certification ?

1. Oui

2. Non, pourquoi ?

E2. Pensez-vous que le « Guide utilisateur de la C ertification HLA » est : 1. Très bon ?

2. Bon. ?

3. Pauvre ?

4. Très mauvais ?

5. N/A

Veuillez préciser :

E3. Pensez-vous que l’aide fournie par l’Agent de Certification HLA était : 1. Très bonne ?

2. Bonne ?

3. Pauvre ?

4. Très mauvaise ?

5. N/A


E4. Est-ce que la certification HLA a été plus faci le ou plus difficile que ce que vous aviez escompté ?

1. Plus facile

2. Aussi facile qu’escompté

3. Plus difficile



Version : V1.3

Page : 36/37

E5. Quel est le niveau de votre intérêt pour le pro cessus de certification HLA ?

1. Elevé

2. Moyen

3. Peu élevé

4. Pas d’opinion


F. MOYEN ET DUREE F1. Nombre de personnes impliquées dans le processu s de certification HLA :

F2. Nombre total de jours dédiés au processus de ce rtification HLA :

-----Fin du questionnaire pour la candidat------


Version : V1.3

Page : 37/37

(Réponses fournies par l’agent de certification HLA )

F3. Délai (complet = délai dû l’Agent de Certificat ion + délai dû au le candidat) Délai nécessaire pour l’enregistrement (jours) :

Délai nécessaire pour le test CS, SOM, FED/FDD (jours) :

Délai nécessaire pour le test d’interface (jours) :

Délai nécessaire pour la totalité du processus de certification (jours) :

G. EXTRAITS DU FICHIER CS G1. Groupes de services : Federation Management: Oui / Non

Declaration Management: Oui / Non

Object Management: Oui / Non

Ownership Management: Oui / Non

Time Management: Oui / Non

Data Distribution Management: Oui / Non

Support Services: Oui / Non

G2. Liste des services utilisés :

Documents

Guide utilisateur de la Certification HLA V1certificationhla-france.org/Doc_Certif/CERTIFHLA3_0036_MUT_Guide... · Le service de certification HLA est mis en œuvre en France par