Les interfaces de programmation

Rappelons ici que, l’impl´ementation du sch´ema de synchronisation ´evoqu´e dans la Figure 3.6

du paragraphe pr´ec´edent, est d´ecrite par les places atomiques ”ReceiveInteractioni” et ”ReflectAttributeValuei”,

d´ecrivant les composantes atomiques de la Figure 3.6c.

A partir des Tableaux 3.2 et 3.1, les param`etres que nous utilisons pour l’envoi des donn´ees multim´edia sont d´ecrites par ”AudioPacket” et ”VideoPacket”. Les attributs qui contrˆolent ces param`etres sont d´ecrits par ”AudiFormat”, ”VideoFormat” et ”Operations”. Ainsi, le moteur d’ex´ecution ”HLA-RTI” peut transmettre le flux audio, le vid´eo et le flux interactif vers les autres simulations, tout en assurant le contrˆole de chaque flux ind´ependamment l’un de l’autre.

L’utilisation des APIs de l’interface de sp´ecification de HLA pour d´efinir les sc´enarios de com- munication entre les f´ed´er´es permet de respecter la r`egle 4 de HLA pour les f´ed´erations (1).

1. During a federation execution, federates shall interact with the run-time infrastructure (RTI) in accordance with the HLA interface specification

(a)

(b)

Figure 3.10: Transfert et de contrˆole de donn´ees sous HLA

La Figure 3.10 illustre le sc´enario de transfert et de contrˆole de donn´ees sous HLA. Selon l’in- terface de sp´ecification de HLA (HLA-IS), sendInteraction() est une fonction de la classe RTIAmbassador, qu’un f´ed´er´e utilise lorsqu’il souhaite envoyer les donn´ees sur le r´eseau. La Figure 3.10a illustre un f´ed´er´e HLA produisant le flux qu’il souhaite envoyer vers les autres simulations au sein de la mˆeme f´ed´eration. La Figure 3.10a illustre ces m´ecanismes de contrˆole et de synchronisation des diff´erents flux. En effet, les APIs UpdateAttributeValues() et reflectAttributeValue() sont les APIs non seulement pour contrˆoler l’avance d’un flux par rapport aux autres mais aussi pour assurer la synchronisation des flux. La Figure 3.10b d´ecrit un f´ed´er´e consommateur qui utilise la m´ethode receiveInteraction(), qui est une fonction de la classe FederateAmbassador, pour recevoir des informations du r´eseau. Le f´ed´er´e doit donc impl´ementer les fonctionnalit´es d´eclar´ees dans le FederateAmbassador.

3.3.5.1 Sc´enario de communication

Ce paragraphe illustre les diff´erents sc´enarios de mise en r´eseau de deux simulateurs Plat- sim QoS conforme avec HLA. En effet, un simulateur producteur initie la cr´eation de la f´ed´e- ration avec le serveur de simulation (le composant RTI). Une fois la f´ed´eration cr´e´ee et que les simulateurs ont pu la rejoindre, le sc´enario de communication commence par l’´echange de messages entre les participants. Enfin, lorsque l’un des simulateurs veut quitter la simulation,

il notifie le RTI et demande quitter la simulation. Sc´enario d’initialisation de la F´ed´eration :

La Figure 3.11 pr´esente le sc´enario d’initialisation de la f´ed´eration Platsim QoS. Lorsque un si- mulateur Platsim QoS d´esire joindre la simulation, il envoie le message ”createFederationExecution ("Platsim", "platsim.fed") ”. Ce message contient le nom de la f´ed´eration `a laquelle le si- mulateur veut participer et le nom du fichier d´ecrivant les diff´erents flux `a ´echanger avec les autres simulateurs (les objets et les interactions). Ainsi, si la f´ed´eration a d´ej`a ´et´e cr´e´ee, une exception (RTI::FederationExecutionAlreadyExists) sera lev´ee pour assurer le simulateur de l’existence de la f´ed´eration. Le simulateur peut alors joindre cette f´ed´eration en envoyant le message ”joinFederationExecution( federateName, "Platsim", platsim_fedamb) ”.

Figure 3.11: initialisation de la F´ed´eration

Ensuite, chaque simulateur associe aux diff´erents ´el´ements du flux applicatif des identifiants uniques (les Handlers des objets et interactions) pendant toute la simulation et les publie vers le

serveur de simulation (RTI) en envoyant le message ”publishObjectClass(this→VehiculeSimule_Handle, ∗theAttributes)”. Comme le fichier OMT suit la mˆeme organisation logique dans tous les si-

mulateurs, les mˆemes noms d’objets et d’interactions ont les mˆemes Handlers.

Une fois ces objets et interactions identifi´es, le simulateur proc`ede `a la pr´eparation de la syn- chronisation avec les autres : cr´eation des diff´erents points de synchronisation rendez-vous syn- chronizationPointAchieved(READY_TO_RUN), l’appel des ”Timers” temps-r´eel et l’ex´ecution de m´ecanismes de synchronisation d´ecrit dans le paragraphe pr´ec´edent.

Sc´enario de communication au sein de la F´ed´eration :

La Figure 3.12 pr´esente un sc´enario de l’interaction entre deux f´ed´er´es (simulateurs Plat- sim QoS) au sein d’un exercice de simulation distribu´ee. Pour simplifier l’illustration de la Figure, un objet (”VehiculeSimule”) et deux interactions (”Global” et ”AudioPacket”) sont pro- duits par le premier simulateur, envoy´es vers le serveur de simulation (RTI) et r´efl´echis vers le simulateur qui va les consommer.

Le sc´enario d´ebute par l’arriv´ee du f´ed´er´e consommateur dans la f´ed´eration. Ce f´ed´er´e d´eclare son souscription de l’objet ”VehiculeSimule” et tous les attributs qu’il contient. Le serveur de

Figure 3.12: Publication et souscription entre deux simulateurs Platsim QoS

simulation notifie le producteur (envoi des ”Handles” des objets) pour qu’il commence l’enregis- trement des instances des objets. Ces instances sont par la suite d´ecouvertes par le simulateur consommateur par le RTI. Si RTI envoie le message turnUpdateOnForObjectInstance() au producteur, c’est pour s’assurer que les valeurs des attributs sp´ecifi´es de l’instance de l’objet sont n´ecessaires `a la simulation et qu’il devra maintenant envoyer les mises `a jours des valeurs de ces attributs (provideAttributeValuesUpdate()) ; d`es lors, ces nouvelles valeurs sont en- voy´ees au serveur de simulation (RTI) par le service updateAttributeValues(objectHandle), qui les distribue aux diff´erents f´ed´er´es via la m´ethode (callback) reflectAttributeValues(). Le flux multimedia ”audio” sur la Figure est aussi envoy´e comme interaction. En effet, le simu- lateur dispose d’une interface qui lui permet de lancer la r´eception de l’audio et de la vid´eo. Il envoie le message subscribeInteractionClass(this→AudioPacketl_Handle) pour sp´eci- fier l’instance des interactions auxquelles il s’abonne. Les identificateurs de ces instances seront alors r´efl´echis par le RTI vers le simulateur producteur. D`es lors, celui-ci commence `a mettre `a

jour les valeurs des param`etres de l’interaction ”AudioPacket”. Sc´enario de terminaison de la F´ed´eration :

La Figure 3.13 pr´esente le sc´enario de terminaison de l’exercice de simulation. Le simulateur informe le serveur de la simulation qu’il souhaite se d´esinscrire de la simulation et arrˆeter de recevoir les instances des objets et des interactions (unsubscribeObjectClass() et unsub- scribeInteractionClass()).

Figure 3.13: Terminaison et Lib´eration de la F´ed´eration entre deux simulateurs Platsim QoS Le f´ed´er´e producteur est notifi´e : il supprime les instances de son cache (deleteObjectInstance (objectHandle, NULL)) et suspend la publication des mises `a jour des valeurs des attributs et des param`etres vers ce consommateur. D`es lors, ce dernier peut sortir de la f´ed´eration : il doit alors notifier le serveur de simulation qu’il quitte la simulation via le message resignFedera- tionExecution (RTI::NO_ACTION). La Figure 3.13 montre aussi le cas o`u les deux simulateurs d´esirent quitter la simulation. Dans ce cas-l`a, le dernier simulateur doit demander la destruction de l’exercice de simulation au serveur (destroyFederationExecution("Platsim")).