Loading article…
ハイレベルアーキテクチャ（HLA）は分散シミュレーションの標準であり、複数のシミュレーションを結合（フェデレーション）してより大きな目的のシミュレーションを構築する際に使用されます。[ 1 ]この標準は、1990年代半ばに米国国防総省[ 2 ]の主導の下、国防高等研究計画局（ DARPA）[ 3 ]と提携して開発され、後に国防モデリングおよびシミュレーションオフィス（DMSO）に移管され、そこでオープンな国際IEEE標準となりました。これは、 STANAG 4603を通じてNATO内で推奨される標準です。[ 4 ]現在、HLAは防衛およびセキュリティや民間アプリケーションを含む多くの分野で使用されています。
HLAの目的は、相互運用性と再利用性を実現することである[ 5 ]。HLAの主な特性は以下のとおりである。
HLAは、例えば航空宇宙や防衛といった様々な分野において、標準化され拡張可能なFOM（機能運用モデル）を開発するための基盤となる。
このアーキテクチャでは、以下の構成要素が規定されています。
上記の構成要素が合わさって連邦を形成します。
HLA規格は3つの部分から構成されています。
HLAは、1994年に米国国防総省の防衛研究工学部長であるアニタ・K・ジョーンズ博士が、幅広いシミュレーション間の相互運用性を促進する技術の作成に関してDARPAのハワード・フランク博士に協力を求めたことから始まりました。ランディ・ギャレット博士[ 13 ]は、米国陸軍のロバート・レディ大佐が率いる先進分散シミュレーションおよび合成戦場（STOW）プログラムの一環としてHLAを作成しました。HLAが発展するにつれて、ジョーンズ博士は国防モデリング・シミュレーション局（DMSO）に「防衛モデルとシミュレーションの相互運用性と再利用性を保証する」という任務を与えました。[ 1 ] 1995年、DMSOはモデリングとシミュレーションのビジョンを策定し、ハイレベルアーキテクチャを含むモデリングとシミュレーションのマスタープランを確立しました。
M&S相互運用性のためのプロトコルは既に2つ存在していた。1つは、固定オブジェクトモデルを使用したリアルタイムプラットフォームレベルのシミュレーションに焦点を当てた分散インタラクティブシミュレーション（DIS）、もう1つは、時間管理、所有権管理、およびコンフェデレーションモデルと呼ばれる柔軟なオブジェクトモデルを使用した集約シミュレーションに焦点を当てた集約レベルシミュレーションプロトコル（ALSP）である。HLAの目的は、米国国防総省のすべての構成要素のシミュレーション相互運用性の要件を満たす統一標準を提供することであった。[ 2 ]
HLA の開発は、プラットフォーム プロトタイプ フェデレーション、統合訓練プロトタイプ フェデレーション、分析プロトタイプ フェデレーション、およびエンジニアリング プロトタイプ フェデレーションの 4 つのプロトタイプ フェデレーションに基づいて行われました。HLA 仕様はプロトタイプ化され、改良が重ねられ、最終的に HLA 1.3 がリリースされました。防衛コミュニティ以外での利用を容易にするため、HLA はその後、シミュレーション相互運用性標準化機構(SISO) が管理する IEEE 標準に移行されました。DIS ユーザーの移行を容易にするため、DIS の固定オブジェクト モデルに対応するフェデレーション オブジェクト モデルも、リアルタイム プラットフォーム リファレンス FOM ( RPR FOM ) として開発されました。
以下のHLAバージョンが存在します。
HLA 1.3は1998年3月にDMSOによって発表されました。内容は以下の通りです。
米国国防総省はHLA 1.3に関する解釈も公表した。
HLA IEEE 1516-2000は、2000年にIEEEによって発行されました。内容は以下のとおりです。
IEEE 1516-2000の主な改良点としては、詳細なデータ型仕様を備えたXMLベースのFOMと、改良されたDDM設計が挙げられる。
IEEE 1516-2000規格には、推奨される開発プロセスと推奨される検証・妥当性確認（VV&A）プロセスも併せて規定されている。
1516-2000規格のAPIは、RTIの実装ごとに若干異なることがすぐに判明した。そこでSISOは、代替となる動的リンク互換（DLC）のC++およびJava APIを定めた規格を作成した。
DLC APIは後にメインの標準規格に統合された。
IEEE 1516-2010規格は、2010年8月にIEEEによって発行され、一般的にHLA Evolvedとして知られています。[ 14 ]この規格は以下で構成されています。
IEEE 1516-2010 の主な改善点には、モジュラー FOM [ 18 ] 、 C++ および Java への DLC API の組み込み、Web サービス API [ 19 ]、フォールト トレランス[ 20 ]などがあります。
このバージョンのHLAの機械可読部分（XMLスキーマ、C++、Java、WSDL API、FOM/SOMサンプルなど）は、IEEEウェブサイトのIEEE 1516ダウンロードエリアからダウンロードできます。規格の全文は、SISO会員は無料で入手できるほか、IEEEショップで購入することもできます。
IEEE 1516-2025 (HLA 4) は、2025年2月にIEEEによって承認され、2025年8月に発行されました。[ 21 ]内容は以下のとおりです。
HLA 4は、セキュリティ、拡張性、拡張性、クラウドおよびコンテナ対応性、そしてライフサイクル全体にわたるサポートを向上させます。
XMLスキーマ、C++、Java、フェデレートプロトコルAPI、FOM/SOMサンプルなど、HLA 4の機械可読部分は、IEEEウェブサイトのIEEE 1516.1-2025ページからダウンロードできます。
HLA規格は3つの部分から構成されています。
RTIサービスはHLAインターフェース仕様で定義されており、7つのサービスグループに分類されています。これらのサービスに加えて、管理オブジェクトモデル（MOM）は、フェデレーションの状態をプログラムによって検査および調整できるサービスを提供します。
ほとんどのRTIは、実行可能な中央RTIコンポーネント（CRC）と、フェデレートが使用するライブラリであるローカルRTIコンポーネント（LRC）で構成されています。サービスは、C++またはJava APIを介して、またWebサービスを使用して提供されます。C++およびJava APIでは、RTI Ambassadorクラスのインスタンスへの呼び出しを使用してサービスが呼び出されます。RTIは、フェデレートAmbassadorクラスのインスタンスへの呼び出しを使用して提供されるコールバックを使用して、フェデレートに情報を提供します。WSDLを使用して定義されたWebサービスAPIでは、フェデレートはWebサービスのリクエストとレスポンスを使用して呼び出しを行い、コールバックを取得します。
以下のサービスグループの説明は、主要なサービスに焦点を当てています。例外事項や勧告事項は含まれていません。
HLAインターフェース仕様の第4章[ 11 ]で説明されているフェデレーション管理サービスの目的は、フェデレーション実行と、同期ポイントや保存/復元などのフェデレーション全体の操作を管理することです。
フェデレーション管理サービス群は、RTIへの接続、フェデレーションの実行、および参加フェデレート群を管理します。主なサービスは以下のとおりです。
もう一つのサービス群は、同期ポイントに関連するものです。これらは、実行を続行する前に、すべてのフェデレート、または選択されたフェデレートがシナリオの初期化などの操作を完了する必要がある、フェデレート全体のイベントです。主なサービスは以下のとおりです。
さらに別のサービス群は、フェデレーション実行の保存と復元に関するものです。保存操作では、RTIと各フェデレートの両方が内部状態の保存を実行する必要があります。復元操作では、RTIと各フェデレートの両方が内部状態の復元を実行する必要があります。主なサービスは以下のとおりです。
保存：
復元する：
HLAインターフェース仕様の第5章[ 11 ]で説明されている宣言管理サービスの目的は、フェデレートがFOM内のオブジェクトクラスとインタラクションクラスに基づいて、公開（送信）および購読（受信）したい情報を宣言できるようにすることです。RTIはこの情報を使用して、更新とインタラクションを購読しているフェデレートにルーティングします。オブジェクトクラスの場合、公開と購読は特定の属性セットに対して実行されます。インタラクションクラスの場合、すべてのパラメータを含むインタラクション全体が公開および購読されます。主なサービスは次のとおりです。
HLAインターフェース仕様の第6章[ 11 ]で説明されているオブジェクト管理サービスの目的は、フェデレートがオブジェクトインスタンスに関する情報を共有し、インタラクションを交換できるようにすることです。
オブジェクトインスタンス名は予約することも、自動生成することもできます。フェデレートは、指定されたオブジェクトクラスのオブジェクトインスタンスを登録でき、登録されたフェデレートはそれを検出できます。これらのオブジェクトインスタンスの属性は更新できます。これらの更新は、登録されたフェデレートに反映されます。インタラクションを送信できます。これらのインタラクションは、登録されたフェデレートに配信されます。主なサービスは次のとおりです。
オブジェクト:
属性:
相互作用:
HLAインターフェース仕様の第7章[ 11 ]で説明されている所有権管理サービスの目的は、オブジェクトインスタンスのどの側面をシミュレートするかを動的に管理することです。HLAでは、特定のオブジェクトインスタンスの特定の属性を更新できるフェデレートは1つだけです。そのフェデレートは属性の所有者とみなされます。新しいオブジェクトインスタンスを登録したフェデレートは、自動的に公開するすべての属性の所有者になります。場合によっては、オブジェクトインスタンスの属性が所有者なし、つまりどのフェデレートにも所有されない状態になることがあります。
所有権管理は、実行時に1つまたは複数の属性の所有権を移転するサービスを提供します。これには、あるフェデレートが属性を放棄し、別のフェデレートが属性を取得することが含まれます。主なパターンは2つあります。取得するフェデレートによって開始される「プル」と、放棄するフェデレートによって開始される「プッシュ」です。
「プル型」所有権を確立するための主要なサービスは以下のとおりです。
「プッシュ型」の所有権を確立するための主要なサービスは以下のとおりです。
すべてのオブジェクトインスタンスには、HLAPrivilegeToDeleteObject という事前定義された属性があります。オブジェクトインスタンスを削除できるのは、そのオブジェクトインスタンスのこの属性の所有者のみです。この属性の所有権は、上記の操作を使用して実行時に移転できます。
HLA フェデレーションにおける情報交換は、HLA タイムマネジメントが有効になっていない限り、メッセージの即時 (受信順序、RO) 配信を伴うリアルタイムで行われます。HLA インターフェース仕様の第 8 章[ 11 ]で説明されている HLA タイムマネジメントの目的は、フェデレーションがリアルタイム、リアルタイムより高速、リアルタイムより低速、または可能な限り高速で実行されるかどうかにかかわらず、タイムスタンプ付きメッセージ (更新と相互作用) のタイムスタンプ順序 (TSO) での因果関係と正確かつ一貫した交換を保証することです。
HLA時間管理における重要な概念には、以下のようなものがあります。
論理時間：HLAにおける時間軸で、ゼロから始まります。論理時間は、時間管理のタイムスタンプや操作に使用されます。論理時間軸は、フェデレーションのシナリオ時間にマッピングできます。このようなマッピングの例として、ゼロを1066年1月1日午前8時00分（シナリオ時間）とし、1刻みでシナリオの1秒を表すように設定できます。
先読み：フェデレートがメッセージを生成する将来の最小時刻を指定する時間間隔。固定時間ステップを持つフェデレートの場合、これは通常、時間ステップの長さになります。
許可：フェデレートは、RTIによって特定の論理時刻までのすべてのタイムスタンプ付きメッセージが配信された時点で、その時刻まで進むことが許可されます。その後、フェデレートは将来のタイムスタンプを持つメッセージの計算を安全に開始できます。このタイムスタンプは、許可された時刻にフェデレートの先読み時間を加えた時刻より前に設定することはできません。
進行：フェデレートが、許可された時間と先読み期間のデータ生成を完了すると、より後の時間への進行を要求することができます。これは、要求された時間と先読み期間より前のタイムスタンプを持つメッセージをこれ以上生成しないことを約束することを意味します。フェデレートは、進行状態になります。
時間調整：タイムスタンプ付きイベントを送信するフェデレートは、他のフェデレートによる時間進行がこれによって調整される可能性があるため、時間調整を行うものとみなされます。
時間制約あり：時間管理イベントを受信するフェデレートは、タイムスタンプ付きメッセージの受信によって時間の進行が制約されるため、時間制約ありとみなされます。
HLAタイムマネジメントの主な原則は以下のとおりです。
先読みの例（付与および進行状況）：
連盟内の少なくとも1つの連盟組織がペーシング（すなわち、時間前進要求をリアルタイムクロックと連動させる）を実行する場合、連盟はリアルタイムまたはスケーリングされたリアルタイムで実行できます。ペーシングがない場合、連盟は可能な限り高速に実行されます（例えば、実行時に人間の操作を必要としない連盟や、リアルタイムクロックに依存するシステムとのインターフェースを持たない連盟は、コンピューティングリソースが許す限り高速に実行できます）。
主なサービス内容は以下のとおりです。
イベント駆動型シミュレーションでは、フェデレートが以下のサービスを使用して次のイベントに進むよう要求することも可能です。
もう一つ重要な概念は、最大利用可能論理時間（GALT）です。各フェデレートに付与できる最大時間は、他のフェデレートに付与されている時間と、それらのフェデレートのルックアヘッドに依存します。フェデレートのGALTは、他のフェデレートの付与を待つことなく、フェデレートに付与できる最大時間を指定します。これは、時間管理型フェデレーションに後から参加するフェデレートにとって特に重要です。
GALTの主なサービスは以下のとおりです。
より高度なサービスには以下が含まれます。
HLAインターフェース仕様の第9章[ 11 ]で説明されているDDMの目的は、クラスと属性のサブスクリプションを超えて、サブスクライブされたデータに追加のフィルタリングを実行することによって、フェデレーションのスケーラビリティを向上させることです。[ 22 ]フィルタリングは、連続値（緯度と経度など）または離散値（自動車ブランドなど）に基づいて行うことができます。
DDMの主要概念は以下のとおりです。
ディメンション：フィルタリングに使用される名前付き区間（0～n）。値は0から始まり、上限nで終わります。シミュレーション領域のデータは、1つ以上のディメンションにマッピングされます。たとえば、地理的フィルタリングのディメンションは、LatitudeDimensionとLongitudeDimensionになります。自動車ブランドに基づくフィルタリングのディメンションは、CarBrandDimensionになります。
正規化関数：入力値を、ディメンションで使用する整数値にマッピングする関数。たとえば、緯度ディメンションの正規化関数では、緯度値（-90.0～+90.0）を0～179の範囲の整数にマッピングできます。自動車ブランドディメンションの正規化関数では、自動車ブランド（Kia、Ford、BMW、Peugeot）のセットを0～3の範囲の整数にマッピングできます。
範囲：次元上の区間であり、下限（含む）と上限（含まない）によって指定されます。
領域：それぞれが特定の次元に関連する範囲の集合。上記の例では、領域は緯度次元の範囲（3～5）、経度次元の範囲（55～65）、および自動車ブランド次元の範囲（0～1）で構成される。実行時には、領域を表すために領域実現（オブジェクト）がインスタンス化される。領域の範囲は、時間の経過とともに変更される可能性がある。
領域の重なり：2つの領域が重なっているとは、それらが共通するすべての次元において、それらの範囲が重なっている状態を指します。
実行時、フェデレートはオブジェクトクラスの属性とインタラクションを購読する際にリージョンを提供できます。リージョンは、属性の更新とインタラクションを送信する際にも使用されます。DDMを使用する場合、リージョンが重複している場合にのみ、属性の更新とインタラクションが配信されます。
地域向けの主要サービスは以下のとおりです。
DDMとの間で属性更新を交換するための主要サービスは以下のとおりです。
DDMとのやり取りを行うための主要サービスは以下のとおりです。
HLAインターフェース仕様書の第10章[ 11 ]に記載されているHLAサポートサービスは、以下のような多数のサポートサービスを提供します。
HLAインターフェース仕様書の第11章[ 11 ]で説明されている管理オブジェクトモデル（MOM）の目的は、フェデレーションを管理するためのサービスを提供することです。これは、MOMオブジェクトとインタラクションクラスを使用して実行されます。MOMオブジェクトは、RTIによって自動的にロードされるMIMと呼ばれる特別なFOMモジュールで定義されます。MOMの主な機能は次のとおりです。
OMTは、フェデレーションオブジェクトモデル（FOM）およびシミュレーションオブジェクトモデル（SOM）を記述するために使用されるテンプレートです。FOMとSOMは、表形式またはXML形式で表現できます。後者の形式は、FOMをRTIにロードする際に使用されます。
HLAの以前のバージョンでは、FOMは単一の構造でしたが、現在の標準規格ではモジュール式のFOMがサポートされており、情報交換のさまざまな側面をカバーする複数のモジュールをRTIに提供できます。
標準規格には、多数の定義済みクラス、データ型、ディメンション、および輸送タイプが用意されています。これらは、HLAstandardMIM.xml FOMモジュールに含まれています。定義済み概念には、HLAobjectRootやHLAunicodeStringのように、HLAという接頭辞が付きます。
OMTには3種類のXMLスキーマがあります。
識別テーブルの目的は、モデルに関するメタデータを提供し、FOM/SOMまたはフェデレートの再利用を容易にすることです。
以下の項目が指定されています。
オブジェクトクラス構造テーブルの目的は、HLAフェデレーションでオブジェクトをインスタンス化するために使用されるオブジェクトクラスのクラス階層（サブクラス/スーパークラス）を指定することです。オブジェクトクラスの属性は、この階層に基づいてスーパークラスからサブクラスに継承されます。オブジェクトクラスツリーのルートはHLAobjectRootと呼ばれます。オブジェクトクラスの完全修飾名の例としては、HLAobjectRoot.Car.ElectricCar があります。
階層構造内のオブジェクトクラスには、以下のフィールドが指定されています。
属性テーブルの目的は、特定のオブジェクトクラスで使用可能な属性を指定することです。属性は継承されるため、オブジェクトクラスは、そのオブジェクトクラスでローカルに定義されている属性、または直接的もしくは間接的なスーパークラスで指定されている属性の集合を持つことになります。
属性には以下のフィールドが指定されています
インタラクション クラス構造テーブルの目的は、HLA フェデレーションでインタラクションを交換するために使用されるインタラクション クラスのクラス階層 (サブクラス/スーパークラス) を指定することです。インタラクション クラスのパラメーターは、この階層に基づいてスーパークラスからサブクラスに継承されます。インタラクション クラス ツリーのルートは HLAinteractionRoot と呼ばれます。インタラクション クラスの完全修飾名の例としては、HLAinteractionRoot.CarCommand.Start があります。
階層構造におけるインタラクションクラスには、以下のフィールドが指定されています。
パラメータテーブルの目的は、特定の相互作用クラスで使用可能なパラメータを指定することです。パラメータは継承されるため、相互作用クラスは、そのクラスでローカルに定義されているパラメータ、または直接的もしくは間接的なスーパークラスで指定されているパラメータの集合を持つことになります。
ディメンションテーブルの目的は、属性と相互作用クラスに使用されるDDMディメンションを指定することです。
時間表現テーブルの目的は、時間管理サービスで使用されるデータ型を指定することです。
特定のHLAサービスを呼び出す際に、ユーザー指定のタグを指定できます。ユーザー指定タグテーブルの目的は、これらのタグのデータ型を指定することです。
同期テーブルの目的は、フェデレーションで使用される同期ポイントを指定することです。
輸送タイプ表の目的は、利用可能な輸送タイプを指定することです。事前定義された輸送タイプは、HLAreliableとHLAbestEffortの2種類です。
更新レート表の目的は、利用可能な最大更新レートを指定することです。
RTIの実行時動作は、あらかじめ定義された複数のスイッチを使用して制御できます。スイッチテーブルの目的は、これらのスイッチの初期値を提供することです。一部のスイッチは、実行時に更新することも可能です。
データ型テーブルの目的は、属性、パラメータ、ディメンション、時間表現、ユーザー指定タグ、および同期ポイントに使用されるデータ型の仕様を提供することです。データ型は6つのカテゴリに分類され、それぞれに個別の表形式が用意されています。
基本データ表現テーブルの目的は、他のテーブルで使用するためのバイナリ表現を提供することです。HLA 標準では、HLAinteger16BE、HLAinteger32BE、HLAinteger64BE、HLAfloat32BE、HLAfloat64BE、HLAoctetPairBE、HLAinteger16LE、HLAinteger32LE、HLAinteger64LE、HLAfloat32LE、HLAfloat64LE、HLAoctetPairLE、HLAoctet など、いくつかの定義済み基本データ型が提供されています。通常、これらの基本データ型セットは、ユーザー定義の基本データ型で拡張されることはありません。
単純データ型テーブルの目的は、単純なスカラーデータ項目を記述することです。HLA規格には、HLAASCIIchar、HLAunicodeChar、HLAbyte、HLAinteger64time、HLAfloat64timeといった、あらかじめ定義された単純データ型が多数用意されています。FOMには、ユーザー定義の単純データ型を含めるのが一般的です。
列挙型データ型表の目的は、有限個の離散的な値をとることができるデータ要素を記述することです。標準規格では、HLAbooleanという定義済みの列挙型データ型が提供されています。FOMには、ユーザー定義の列挙型データ型を含めるのが一般的です。
列挙型データ型テーブルの目的は、データ要素の配列（単純型、列挙型、配列、固定レコード、バリアントレコード）を記述することです。HLA標準では、HLAASCIIstring、HLAunicodeString、HLAopaqueData、HLAtokenなど、いくつかの定義済み単純型データ型が提供されています。FOMには、ユーザー定義の配列データ型を含めるのが一般的です。
固定レコードデータ型テーブルの目的は、固定されたデータ要素セット（単純レコード、列挙型レコード、配列、固定レコード、またはバリアントレコード）を持つレコードを記述することです。
バリアントレコードデータ型テーブルの目的は、異なる事前定義済みのデータ要素セットを含む可能性のあるレコードを記述することです。これらの異なるセットは「代替案」と呼ばれます。特定のバリアントレコードに適用される代替案は、「判別子」と呼ばれるデータ要素によって示されます。
注釈表の目的は、他の表の項目に関する注釈や追加の説明を提供することです。
HLAの規則[ 23 ]は、連盟と参加する連盟メンバーの責任について述べている[ 24 ] 。
IEEE 1516規格は、SISO HLA進化製品開発グループの下で改訂され、2010年3月25日にIEEE標準化活動委員会によって承認されました。改訂されたIEEE 1516-2010規格には、現在の米国国防総省標準の解釈と、SISO DLC APIの拡張版であるEDLC APIが含まれています。その他の主な改善点は以下のとおりです。
シミュレーション間の適切な相互作用を確保するために、フェデレートの適合性をテストする方法が定義されています。これは、特定のフェデレートのSOMにリストされているすべてのクラスと相互作用が、「PublishSubscribe」、「Publish」、「Subscribe」、または「None」という使用方法に従って使用されていることを確認するものです。
HLA（現在のIEEE 1516バージョンと、その前身である「1.3」バージョンの両方）は、モデリングとシミュレーションに関するNATO標準化協定（STANAG 4603）の対象です。モデリングとシミュレーションのアーキテクチャ標準（技術的相互運用性向け）：ハイレベルアーキテクチャ（HLA）。[ 25 ]
ベースオブジェクトモデル（BOM）、SISO-STD-003-2006は、HLAシミュレーションの再利用性と構成性を向上させるためのSISOによる関連規格です。これは、概念モデルを指定し、それらをHLA FOMにマッピングする方法を提供します。[ 26 ]
分散モデリングおよびシミュレーション (DM&S) 業界に関して、軍事プラットフォームのリアルタイム シミュレーションで HLA の代替として最もよく使用されるのは、シミュレーション プロトコルである分散インタラクティブ シミュレーション(DIS)、IEEE 1278.1-2012 です。ほとんどのHLA RTI ベンダーも製品に DIS を搭載しています。パブリッシュおよびサブスクライブ機能 (P&S) など、HLA の機能に最も近いミドルウェア アプリケーションについては、データ配信サービス (DDS)を参照してください。DDS は多くの同じ特性を共有していますが、システム間の相互運用性のためにオープンなオンザワイヤ プロトコルを備えています。[ 27 ]
HLA は、C++またはJava APIによって提供される一連のサービスとして定義されるメッセージ指向ミドルウェアです。標準化された通信プロトコルはありません。フェデレーションの参加者は、同じプロバイダーの RTI ライブラリを使用する必要があり、通常は同じバージョンを使用する必要があり、これは場合によっては欠点と見なされます。[ 28 ]現在のツールのほとんどは、ソケットを介して相互接続も提供します。