高レベルのアーキテクチャ（HLA）対分散インタラクティブシミュレーション（DIS）

Question

の高レベルの概要はありますか HLA 対 dis シミュレーションフレームワーク？一方が他方をホストし、その逆もできますか？

Answer 1

私は現在（さらに1週間ほどですが）シミュレーション業界での作業です。どんなエラーでも事前に謝罪します。誤った情報を覚えている場合は修正します。

dis

• 標準は、ワイヤー上のデータのレイアウトを指定します。つまり、パケット/データPDUはDIS仕様で定義されているとまったく同じようにレイアウトされています

• Best-Effort Networking（つまり、UDPプロトコル、放送）に依存しています

• エンティティは、特定の間隔で鼓動する必要があります（デフォルト：5秒）。

• エクササイズに参加するさまざまなアプリケーションを管理するセントラルサーバーはありません

• シミュレーションアプリケーションはいつでもシミュレーションに参加でき、いつでも出発できます

HLA

• さまざまなアプリケーションからデータを受信し、シミュレーション内の他のアプリケーションに送信するRTI（実行時間インフラストラクチャ）と呼ばれるセントラルマネージャーを使用します（HLAのコンテキストでは、これらはフェデレートと呼ばれ、連合系のセットはフェデレーションです）

• すべての連合国は、RTIを通過してシミュレーションを辞める必要があります

• DISとは異なり、HLA仕様はデータパケットのレイアウトを指定するのではなく、アプリケーションを使用するAPI機能のセットを定義します。 RTIはAPIを実装するものです。

• HLA Federatesは、シミュレーション内のデータが表すものを定義するFOM（フェデレーションオブジェクトモデル）に従ってデータを公開します。これにより、人々は、新しいタイプのデータPDUを追加するDISとは異なり、新しいオブジェクトとインタラクションタイプを定義する新しいFOMを作成できます。たとえば、HLAで実行されるほとんどのシミュレーションは、DIS標準エンティティとインタラクションをほとんど反映しているRPR FOMを利用しています。

• HLAは、DISがサポートしていない追加機能を追加します。これは、データ分布管理（DDM）など、特定の種類のデータのみに関心があることをRTIに通知します。

• サブスクリプションサービスをサポートしているサブスクリプションサービスでは、フェデレートが特定のオブジェクトまたは相互作用データの受信のみに関心があることをRTIに通知するサブスクリプションサービス（つまり、アプリケーションはSIPに関するデータのみを必要とします）

• 1つのフェデレートの制御下にあるオブジェクトが別の連邦政府に管理するために与えられる所有権転送の特徴をサポートします。

DISホストHLAとその逆も同様ですか？

これらの基本的な違いにより、DISとHLAがお互いをホストできないことは明らかです。

ただし、これが本当に意味するのは、DISのシミュレーションにHLAのシミュレーションと対話するには、2つのプロトコル間のアダプターとして機能する何らかのネットワークブローカーが必要であることです。そのようなブローカーの例はそうです Mak VR-Exchange また GMUゲートウェイ.

さらに読むために：

• 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

HLAに関するいくつかの少そうな歴史を以下に示します。

HLAの設計は、実際には、HLAを開発したのと同じMiterの人々によって90年代初頭に導かれた集計レベルシミュレーションプロトコル（ALSP）と呼ばれるものに基づいています。 ALSPは、軍団/部門コマンドポストトレーニングに使用される大規模な建設的なシミュレーションをリンクするように設計されています。 ALSPの相互運用性の要件には、より多くのオブジェクト、保守的な時間のスヌー化、シミュレーションイベントの交換が含まれていました。スケーラビリティの問題を引き起こすため、エンティティの更新を定期的に放送する余裕はありませんでした。

私の晩年の関与では、ウルチフォーカスレンズエクササイズの1つにつき100万件もの戦場オブジェクトに到達しました。 HLAとDISの根本的な違いは、HLAが建設的な大規模で可変の忠実度、保守的な時間管理シミュレーションを処理するように設計されているのに対し、DISはネットワーク化されたシミュレーター環境から生まれ、ほぼリアルのプラットフォームレベルのシミュレーターに焦点を当てていることです。

HLAは、これらの2つのクラスのシミュレーションをある程度相互運用するのに役立ちますが、リンクされているシミュレーションのタイプの固有の違いによって常に制限されます。

たとえば、保守的な時間管理シミュレーションフェデレートが計算で停止すると、HLA時間管理により、最も遅いシミュレーションが前進するまで連邦が前進するのを止めます。 DISはこれをサポートしていません。 DIS駆動型のプラットフォームにとって、すべての時間管理エンティティは、スローモーションで移動するか、完全に停止し、定期的に連邦がリアルタイムに追いつくとリアルタイムよりも速く動いているように見えます。

Answer 3

HLA仕様には、RTIを集中化する必要があると言うものは何もありませんが、ほとんどすべてのRTIはありません。

Answer 4

HLA 1516標準は、シミュレーターとRTIの間のAPIのみを定義します。 RTIの間ではありません。 RTI間のデータを交換するために使用されるプロトコルは独自のものです。したがって、同じベンダーまたは政府機関からのRTIのみが相互運用できます。大きな欠陥。別のRTIを使用している場合は、独自のプロトコル間を翻訳するには「ブリッジ」が必要です。これは高価になる可能性があります。

Answer 5

DISとHLAを橋渡しすることを計画している場合に留意すべきことの1つは、FOMの整理方法に応じて、両側でシミュレーションの忠実度を失う可能性があることです。 RPR FOMへのDISは簡単ですが、他のFOMがあります。状況によっては、PDUフィールドをHLAオブジェクト属性または相互作用パラメーターに変換できない場合があります（またはその逆）。これらの状況で使用するデフォルト値の種類について、最善の判断を使用する必要があります。また、HLA FOMオブジェクトの階層がDISとは非常に異なって構造化される場合があります。この場合、翻訳では、複数のDIS PDUからのデータを組み合わせて1つのHLAメッセージを形成する必要があります。これは、何らかの形のメッセージ状態を保存するために、ブリッジにコードを書く必要があることを意味します。

また、実行時には、HLA属性が断片的になります。オブジェクトの発見の後、DIS PDUを適切に入力するのに十分な属性を受け取るまで、オブジェクトインスタンスを翻訳するのを待つ必要があります。

別の問題は、HLAが時間管理サービスを提供できることです。時間管理を使用してDISアプリケーションをHLA連合に統合しようとした場合、対処するための多くの同期問題があります。

購入予算がある場合は、Mak VR-Exchangeを使用することです。