Architecture de haut niveau (HLA) par rapport à la simulation interactive distribuée (DIS)

Question

Y at-il une vue d'ensemble de haut niveau HLA contre DIS de cadres de simulation? Peut-on hôte l'autre et vice-versa?

Answer 1

Je suis actuellement (mais seulement pour une autre semaine ou) travail dans l'industrie de la simulation -. Je présente mes excuses à l'avance pour des erreurs, je les corriger si je me souviens des informations incorrectes

DIS

• La norme spécifie la mise en page des données sur le fil, à savoir vos paquets de données / PDUs sont disposés exactement tel que défini dans les spécifications du DIS

• Repose sur la mise en réseau des meilleurs efforts (à savoir le protocole UDP, la diffusion)

• Les entités doivent rythme cardiaque à certains intervalles (par défaut: 5 secondes) pour informer tout le monde qu'il fait encore partie de l'exercice

• Aucun serveur central gérant les différentes applications jointe à l'exercice

• applications de simulation peuvent se joindre à la simulation à tout moment, le congé à tout moment

HLA

• Utilise un gestionnaire central, appelé la RTI (Run Infrastructure Time), qui reçoit des données provenant de diverses applications et les envoie à d'autres applications dans la simulation (dans le contexte de HLA, ceux-ci sont appelés Fédérés et un ensemble de fédérés est une fédération)

• Tous doivent rejoindre et fédère quitter la simulation en passant par la RTI

• Contrairement à DIS, la spécification HLA ne précise pas la mise en page des paquets de données, mais définit plutôt un ensemble de fonctionnalités API que les applications utilisent. La RTI est ce qui implémente l'API.

• HLA publient des données selon fédère une FOM (Fédération Object Model) qui définit ce que les données dans une simulation représente. Cela permet aux gens de créer de nouveaux GOR qui définissent de nouveaux objets et types d'interaction, à la différence de DIS, où l'ajout de nouveaux types de données PDUs passe par un comité (SISO). Par exemple, la plupart des simulations fonctionnant sous HLA utilisent le RPR FOM, qui reflète à peu près le DIS des entités standards et les interactions.

• HLA ajoute des fonctionnalités supplémentaires DIS ne prend pas en charge, tels que la gestion des données de distribution (DDM), dans laquelle la RTI fédère avisent qu'ils ne sont intéressés que certains types de données.

• services APPUIE, dans laquelle la RTI fédère avisent qu'ils ne sont intéressés à recevoir certaines données d'objet ou d'interaction (à savoir une application ne veut que des données sur les navires)

• Prend en charge la fonction de transfert de propriété, où les objets sous le contrôle d'un fédératif sont donnés à un autre fédératif à gérer.

Can DIS hôte HLA et vice versa?

En raison de ces différences fondamentales, il devrait être clair que DIS et HLA ne peuvent pas accueillir les uns les autres.

Cependant, ce que cela signifie vraiment que pour les simulations de DIS d'interagir avec des simulations HLA est que vous avez besoin un certain type de courtier en réseau qui agit comme un adaptateur entre les deux protocoles. Des exemples de ces courtiers sont MAK VR-échange ou GMU passerelle .

Pour la lecture encore plus loin:

• http://www.mak.com/products/standards.php
• http://www.siaa.asn.au/get/2395379411.pdf
• http://dss.ll.mit. edu / dss.web / 96.14.103.RTI.Introduction.html

Answer 2

Voici un peu d'histoire du bailleur connu en ce qui concerne HLA.

La conception de HLA est en fait basé sur ce qu'on appelle le protocole de simulation au niveau agrégé (DAPS) qui a été mené au début des années 90 par les mêmes personnes qui se sont développées Mitre HLA. DAPS a été conçu pour relier à grande échelle des simulations constructives utilisées pour Corps / Division du poste de commandement de formation. Les exigences d'interopérabilité ALSP impliqués un plus grand nombre d'objets, snchronization temps conservateur et l'échange d'événements de simulation. Nous ne pouvions pas se permettre de mises à jour des entités diffusées périodiquement qui causerait des problèmes d'évolutivité.

Dans mes dernières années d'engagement nous avons atteint jusqu'à 1 million d'objets du champ de bataille par un de l'exercice Mise au point Ulchi Lens. La différence fondamentale entre HLA et DIS est que HLA est conçu pour gérer constructive à grande échelle, la fidélité variable temps conservatrices simulations gérés alors que DIS est né d'un environnement de simulation en réseau et se concentre sur le temps quasi-réel, des simulateurs de niveau plate-forme.

HLA peuvent aider à rendre ces deux classes de simulations interopérer à un degré, mais seront toujours limitées par des différences inhérentes aux types de simulations sont liées.

Par exemple, si une simulation fédératif de gestion du temps conservateur s'enlise avec des calculs de la gestion du temps HLA entraînera la fédération d'arrêter le temps aller de l'avant jusqu'à ce que la plus lente simulation se déplace vers l'avant. DIS ne supporte pas. Pour une plate-forme axée sur DIS, toutes les entités gérées dans le temps semblera se déplacer au ralenti ou arrêter complètement et serait périodiquement semblent se déplacer plus vite que le temps réel que les essais de la fédération pour rattraper son retard en temps réel.

Answer 3

Il n'y a rien dans la spécification HLA qui dit la RTI doit être centralisée, bien que presque tous les IVR sont.

Answer 4

Le HLA 1516 standard définit uniquement l'API entre le simulateur et la RTI. Pas entre IAR. Le protocole utilisé pour échanger des données entre IAR est propriétaire. Par conséquent, seul IAR de la même agence de fournisseur ou de gouvernement peuvent interopérer. Un défaut majeur. Si vous utilisez un autre RTI, vous aurez besoin d'un « pont » pour traduire entre les protocoles propriétaires. Cela peut être coûteux.

Answer 5

Une chose à garder à l'esprit si vous envisagez de combler DIS et HLA est que vous aurez peut-être perdre la fidélité de la simulation des deux côtés selon la façon dont votre FOM est organisé. DIS est simple RPR FOM, mais il y a d'autres GOR là-bas qui ne peuvent pas cartographier bien du tout au DIS. Dans certaines situations, vous pouvez être incapable de traduire un champ de PDU à un attribut de l'objet HLA ou paramètre d'interaction (ou vice versa). Vous devrez utiliser votre meilleur jugement pour quels types de valeurs par défaut à utiliser dans ces situations. D'autres fois, la hiérarchie des objets HLA FOM peuvent être structurés de façon très différente de DIS. Dans ce cas, la traduction peut nécessiter la combinaison des données de plusieurs DIS pour former PDUs un message HLA. Cela signifie que vous devez écrire du code dans le pont pour conserver une certaine forme d'état de message.

En outre, lors de l'exécution, vous obtiendrez votre HLA attribue au coup par coup. Après la découverte d'objets que vous devrez attendre pour traduire une instance d'objet jusqu'à ce que vous avez assez attributs reçus pour illuminer le DIS PDU correctement.

Un autre problème est que HLA peut fournit des services de gestion du temps. Vous auriez beaucoup de problèmes de synchronisation à traiter si vous avez essayé d'intégrer une application DIS dans une fédération HLA en utilisant la gestion du temps.

Si vous avez un budget d'achat mon conseil serait d'aller avec MAK VR-échange.