高レベルアーキテクチャ

高レベルアーキテクチャ（HLA）は、分散シミュレーションの標準であり、複数のシミュレーションを組み合わせて（連合して）より大規模な目的のシミュレーションを構築するときに使用されます。^{[1]この標準は、1990年代に}米国国防総省のリーダーシップの下で開発され、 ^[2]後にオープンな国際IEEE標準に移行しました。これは、STANAG 4603を通じてNATO内で推奨される標準です。 ^[3]今日、HLAは、防衛、セキュリティ、民間アプリケーションなど、さまざまな分野で使用されています。

HLA の目的は相互運用性と再利用を可能にすることです。HLA の主な特性は次のとおりです。

• オペレーティング システムや実装言語に関係なく、ローカルまたは広範囲に分散されたさまざまなコンピューターで実行されているシミュレーションを 1 つのフェデレーションに接続する機能。
• さまざまなアプリケーション ドメインに対して、情報交換データ モデル、フェデレーション オブジェクト モデル (FOM) を指定して使用する機能。
• FOM に基づき、追加のフィルタリング オプションを備えたパブリッシュ/サブスクライブ メカニズムを使用して情報を交換するサービス。
• 論理 (シミュレーション) 時間とタイムスタンプ付きデータ交換を調整するためのサービス。
• 連盟の状態を検査および調整するための管理サービス。

HLA は、航空宇宙や防衛などのさまざまなコミュニティで標準化され拡張可能な FOM を開発するための基盤を形成します。

アーキテクチャでは、次のコンポーネントを指定します。

• さまざまなプログラミング言語を通じて標準化された一連のサービスを提供するランタイムインフラストラクチャ(RTI)。これらのサービスには、情報交換、同期、フェデレーション管理が含まれます。
• RTI サービスを使用する個別のシミュレーション システムであるフェデレート。
• データ交換に使用されるオブジェクト クラスとインタラクション クラスを指定するフェデレーション オブジェクト モデル( FOM)。FOM は任意のドメインの情報を記述できます。

上記のコンポーネントが一緒になって連邦を形成します。

HLA 標準は 3 つの部分で構成されています。

1. IEEE Std 1516-2010フレームワークとルール^[4]では、コンポーネントまたは連合全体が遵守すべき10のアーキテクチャルールを規定しています。
2. IEEE Std 1516.1-2010 Federate Interface Specificaion ^[5]はRTIによって提供されるサービスを指定します。サービスはC++およびJava APIとWebサービスとして提供されます。
3. IEEE Std 1516.2-2010オブジェクトモデルテンプレート仕様^[6]は、FOMなどのHLAオブジェクトモデルが使用する形式を規定しています。

HLAは、1990年代初頭、米国国防総省の防衛研究工学部長であるアニタ・K・ジョーンズ博士が国防モデリング・シミュレーション局（DMSO）に「防衛モデルとシミュレーションの相互運用性と再利用性を保証する」という任務を与えたことから始まりました。^[1] 1995年にDMSOはモデリングとシミュレーションのビジョンを策定し、高レベルアーキテクチャを含むモデリングとシミュレーションのマスタープランを確立しました。

M&S相互運用性のためのプロトコルは既に2つ存在していた。固定オブジェクトモデルによるリアルタイムプラットフォームレベルのシミュレーションに重点を置いた分散インタラクティブシミュレーション（DIS）と、時間管理、所有権管理、連合モデルと呼ばれる柔軟なオブジェクトモデルによる集合体のシミュレーションに重点を置いた集合体レベルシミュレーションプロトコル（ALSP）である。HLAの目的は、米国国防総省のすべてのコンポーネントのシミュレーション相互運用性要件を満たす統一標準を提供することであった。^[2]

HLA の開発は、プラットフォーム プロトタイプ フェデレーション、ジョイント トレーニング プロトタイプ フェデレーション、分析プロトタイプ フェデレーション、エンジニアリング プロトタイプ フェデレーションの 4 つのプロトタイプ フェデレーションに基づいていました。HLA 仕様はプロトタイプ化され、改良され、最終的に HLA 1.3 がリリースされました。防衛コミュニティ以外での使用を容易にするため、HLA は IEEE 標準に移行され、シミュレーション相互運用性標準化機構(SISO) によって管理されました。DIS ユーザーの移行を容易にするため、DIS の固定オブジェクト モデルに対応するフェデレーション オブジェクト モデルも、リアルタイム プラットフォーム参照 FOM ( RPR FOM ) として開発されました。

以下の HLA バージョンが存在します。

HLA 1.3 は 1998 年 3 月に DMSO によって公開されました。次の内容で構成されています。

• 米国国防総省、規則バージョン 1.3
• 米国国防総省、高レベルアーキテクチャインターフェース仕様バージョン 1.3
• 米国国防総省、高レベルアーキテクチャオブジェクトモデルテンプレートバージョン1.3

米国国防総省も HLA 1.3 の解釈を発表しました。

• 米国国防総省、高レベルアーキテクチャインターフェース仕様バージョン1.3、リリース3の解釈

HLA IEEE 1516-2000 は 2000 年に IEEE によって発行されました。内容は次のとおりです。

• IEEE Std 1516–2000 – モデリングおよびシミュレーションの標準、高レベルアーキテクチャ – フレームワークとルール
• IEEE Std 1516.1–2000 – モデリングおよびシミュレーションの高レベルアーキテクチャの標準 – フェデレートインターフェース仕様
• IEEE 1516.1–2000 正誤表 (2003-oct-16)
• IEEE 1516.2-2000 – モデリングおよびシミュレーションの高レベルアーキテクチャの標準 – オブジェクト モデル テンプレート (OMT) 仕様

IEEE 1516-2000 の主な改善点には、詳細なデータ型仕様を備えた XML ベースの FOM と、改善された DDM 設計が含まれています。

IEEE 1516-2000 規格には、推奨される開発プロセスと推奨される VV&A プロセスも追加されました。

• IEEE 1516.3-2003 – 高レベルアーキテクチャフェデレーション開発および実行プロセス (FEDEP) の推奨プラクティス。この標準は後に IEEE Std 1730-2010 分散シミュレーションエンジニアリングおよび実行プロセス ( DSEEP )になりました。
• IEEE 1516.4-2007 – フェデレーションの検証、妥当性確認、認定に関する推奨プラクティス、高レベルアーキテクチャフェデレーション開発および実行プロセスへのオーバーレイ

すぐに、1516-2000 標準には、RTI 実装ごとにわずかに異なる API があることが判明しました。SISO は、代替のダイナミック リンク互換 (DLC) C++ および Java API を備えた標準を作成しました。

• SISO-STD-004.1-2004: ダイナミック リンク互換 HLA API の標準 HLA インターフェイス仕様の標準 (IEEE 1516.1 バージョン)
• SISO-STD-004-2004: ダイナミック リンク互換 HLA API の標準 HLA インターフェイス仕様の標準 (v1.3)

DLC API は後にメイン標準に統合されました。

IEEE 1516-2010規格は2010年8月にIEEEによって発行され、一般にHLA Evolvedとして知られています。^[7]それは以下のもので構成されています。

• IEEE 1516–2010 – モデリングとシミュレーションの高レベルアーキテクチャの標準 – フレームワークとルール^[4]
• IEEE 1516.1–2010 – モデリングおよびシミュレーションの高レベルアーキテクチャの標準 – フェデレートインターフェース仕様^[5]
• IEEE 1516.2-2010 – モデリングおよびシミュレーションの高レベルアーキテクチャの標準 – オブジェクトモデルテンプレート (OMT) 仕様^[6]

IEEE 1516-2010の主な改善点としては、モジュラーFOM、^[8] C++およびJavaでのDLC APIの組み込み、WebサービスAPI ^{[9]およびフォールトトレランス[10]}などがあります。

XML スキーマ、C++、Java、 WSDL APIなどのこのバージョンの HLA の機械可読部分や FOM/SOM サンプルは、IEEE Web サイトの IEEE 1516 ダウンロード エリアからダウンロードできます。完全な標準テキストは、SISO メンバーには無料で提供されますが、IEEE ショップから購入することもできます。

HLA の新バージョンの開発は、SISO によって 2016 年 1 月に開始され、現在も進行中です。

HLA 標準は 3 つの部分で構成されています。

• フレームワークとルール。フェデレーションまたはフェデレーション全体が遵守する必要がある 10 個のアーキテクチャ ルールを指定します。
• Federate Interface 仕様は、RTI によって提供されるサービスを指定します。サービスは、C++ および Java API と Web サービスとして提供されます。
• FOM などの HLA オブジェクト モデルが使用する形式を指定するオブジェクト モデル テンプレート仕様。

• ランタイム インフラストラクチャ (RTI) : HLA フェデレート インターフェイス仕様で指定されている標準化された一連のサービスを提供するソフトウェア。サービス グループは 7 つあります。
• フェデレート: RTI に接続するシミュレーション、ツール、ライブ システムへのインターフェイスなどのシステム。ツールの例としては、データ ロガーや管理ツールなどがあります。フェデレートは、RTI サービスを使用してデータを交換し、他のフェデレートと同期します。
• フェデレーション: 共通の FOM を使用して同じ RTI に接続するフェデレートのセット。
• フェデレーション実行: フェデレートのセットが同じ RTI と FOM を使用して、特定の目的を持つフェデレーションで一緒に実行するセッション。
• フェデレーション オブジェクト モデル (FOM) : フェデレーションでの情報交換に使用されるオブジェクト クラス、インタラクション クラス、データ タイプ、および追加データを指定するドキュメント。FOM は、HLA オブジェクト モデル テンプレートおよび関連する XML スキーマの形式に従う XML ファイルです。異なるアプリケーション ドメインのデータ交換には、異なる FOM が使用されます。参照 FOM と呼ばれる標準化された FOM があり、これは FOM 開発の開始点としてよく使用されます。FOM は、FOM モジュールを使用してモジュール方式で開発および拡張できます。
• シミュレーション オブジェクト モデル (SOM) : 特定のシミュレーションがフェデレーションで公開および/またはサブスクライブするオブジェクト クラス、インタラクション クラス、データ タイプ、および追加データを指定するドキュメント。SOM は、HLA オブジェクト モデル テンプレートおよび関連する XML スキーマの形式に準拠した XML ファイルでもあります。SOM は、SOM モジュールを使用してモジュール方式で開発および拡張することもできます。
• オブジェクト: オブジェクトは、一定期間にわたって永続的であり、更新可能な属性を持つデータを表すために使用されます。これらは、オブジェクト クラスを使用して FOM/SOM で定義されます。
• インタラクション: インタラクションは、パラメータを持つ瞬間的なイベントを表すために使用されます。送信されたインタラクションは更新できません (オブジェクト クラスとは異なります)。これらは、インタラクション クラスを使用して FOM/SOM で定義されます。
• データ型: 属性およびパラメータ データの表現と解釈は、HLA データ型を使用して FOM/SOM で指定されます。
• 公開: 一連の属性を持つオブジェクト クラスを公開するフェデレートは、そのオブジェクト クラスのインスタンスを登録および削除し、その属性値を更新できます。インタラクション クラスを公開するフェデレートは、そのインタラクション クラスのインタラクションを、関連するパラメータ値とともに送信できます。
• サブスクライブ: 属性セットを持つオブジェクト クラスにサブスクライブするフェデレートは、そのオブジェクト クラスのインスタンスの登録と削除を検出し、サブスクライブされた属性の更新を受け取ります。インタラクション クラスにサブスクライブするフェデレートは、そのインタラクション クラスのインタラクションと、関連するパラメータ値を受け取ります。

RTI サービスは、HLA インターフェイス仕様で定義されています。これらは 7 つのサービス グループにグループ化されています。これらのサービスに加えて、管理オブジェクト モデル (MOM) は、フェデレーションの状態をプログラムで検査および調整できるようにするサービスを提供します。

ほとんどの RTI は、実行可能ファイルである中央 RTI コンポーネント (CRC) と、フェデレートによって使用されるライブラリであるローカル RTI コンポーネント (LRC) で構成されます。サービスは、C++またはJava API を通じて提供されるほか、Web サービスを使用しても提供されます。C++ および Java API では、RTI Ambassador クラスのインスタンスの呼び出しを使用してサービスが呼び出されます。RTI は、コールバックを使用してフェデレートに情報を提供します。コールバックは、Federate Ambassador クラスのインスタンスの呼び出しを使用して提供されます。WSDL を使用して定義される Web サービス API では、フェデレートによって Web サービス要求と応答を使用して呼び出しが行われ、コールバックがフェッチされます。

以下のサービス グループの説明は、主要なサービスに重点を置いています。例外や勧告は含まれていません。

^{HLAインターフェース仕様[5]}の第4章で説明されているフェデレーション管理サービスの目的は、フェデレーション実行だけでなく、同期ポイントや保存/復元などのフェデレーション全体の操作を管理することです。

フェデレーション管理サービスの 1 セットは、RTI への接続、フェデレーションの実行、および参加したフェデレーションのセットを管理します。主なサービスは次のとおりです。

• RTI への接続と切断
• CreateFederationExecution と DestroyFederationExecution は、フェデレーション実行の作成と破棄に使用されます。
• フェデレーションがフェデレーション実行に参加および再参加するために使用される JoinFederationExecution および ResignFederationExecution。
• ConnectionLost は、RTI がフェデレーションに障害によりフェデレーション実行への接続が失われたことを通知するために使用されます。
• RTI で利用可能なフェデレーション実行のリストを取得するために使用される ListFederationExecutions

もう 1 つのサービス セットは、同期ポイントに関連しています。同期ポイントは、実行を続行する前に、すべてのフェデレートまたは選択されたフェデレートがシナリオの初期化などの操作を完了する必要があるフェデレーション全体のイベントです。主要なサービスは次のとおりです。

• 同期ポイントを登録するために使用される RegisterFederationSynchronizationPoint
• RTI が同期ポイントが登録されたことをフェデレートに通知するために使用する AnnounceSynchronizationPoint
• SynchronizationPointAchieved は、フェデレートが同期ポイントを達成したことを示すために使用されます。
• FederationSynchronized は、RTI によって使用され、フェデレーションが同期されたこと、つまりすべてのフェデレーションが同期ポイントを達成したことをフェデレーションに通知します。

さらに別のサービス セットは、フェデレーション実行の保存と復元に関係しています。保存操作では、RTI と各フェデレートの両方が内部状態の保存を実行する必要があります。復元操作では、RTI と各フェデレートの両方が内部状態の復元を実行する必要があります。主要なサービスは次のとおりです。

保存：

• フェデレーションの保存を開始するために使用されるRequestFederationSave
• InitiateFederateSave は、RTI がフェデレートに状態の保存を開始するように通知するために使用されます。
• FederateSaveComplete は、フェデレートの状態の保存が完了したときにフェデレートによって呼び出されます。
• FederationSaved は、RTI がフェデレーションが保存されたことをフェデレーションに通知するために使用されます。

復元する：

• フェデレーションの復元を開始するために使用されるRequestFederationRestore
• InitiateFederateRestore は、RTI がフェデレートに状態の復元を開始するように通知するために使用されます。
• FederateRestoreComplete は、フェデレートの状態の復元が完了したときにフェデレートによって呼び出されます。
• FederationRestored は、RTI がフェデレーションが復元されたことをフェデレーションに通知するために使用されます。

HLA インターフェース仕様^[5]の第 5 章で説明されている宣言管理サービスの目的は、 FOM 内のオブジェクト クラスとインタラクション クラスに基づいて、フェデレートが公開 (送信) およびサブスクライブ (受信) したい情報を宣言できるようにすることです。RTI はこの情報を使用して、サブスクライブしているフェデレートに更新とインタラクションをルーティングします。オブジェクト クラスの場合、公開とサブスクライブは特定の属性セットに対して実行されます。インタラクション クラスの場合、すべてのパラメータを含むインタラクション全体が公開およびサブスクライブされます。主なサービスは次のとおりです。

• PublishObjectClassAttributes は、特定のオブジェクト クラスの属性セットを公開するために使用されます。
• 特定のオブジェクト クラスの属性セットをサブスクライブするために使用される SubscribeObjectClassAttributes。
• すべてのパラメータを含むインタラクションクラスを公開するために使用されるPublishInteractionClass
• すべてのパラメータを含むインタラクションクラスをサブスクライブするために使用される SubscribeInteractionClass

^{HLAインターフェース仕様の第6章[5]}で説明されているオブジェクト管理サービスの目的は、フェデレーションがオブジェクトインスタンスに関する情報を共有し、相互作用を交換できるようにすることです。

オブジェクト インスタンス名は予約することも、自動的に生成することもできます。フェデレートは、指定されたオブジェクト クラスのオブジェクト インスタンスを登録できます。登録されたオブジェクト インスタンスは、サブスクライブしているフェデレートによって検出されます。これらのオブジェクト インスタンスの属性は更新できます。これらの更新は、サブスクライブしているフェデレートに反映されます。インタラクションを送信できます。これらのインタラクションは、サブスクライブしているフェデレートに配信されます。主なサービスは次のとおりです。

オブジェクト:

• オブジェクトインスタンスに使用する名前を予約するために使用される ReserveObjectInstanceName
• 特定のオブジェクト クラスのオブジェクト インスタンスを予約名または自動生成された名前で登録するために使用される RegisterObjectInstance。
• RTI が、特定のオブジェクト クラスにサブスクライブしているフェデレートに新しいオブジェクト インスタンスが登録されたことを通知するために使用される DiscoverObjectInstance。
• オブジェクトインスタンスを削除するために使用されるDeleteObjectInstance
• RemoveObjectInstances は、RTI がフェデレートにオブジェクト インスタンスが削除されたことを通知するために使用されます。

属性:

• オブジェクトインスタンスの更新された属性値を提供するために使用されるUpdateAttributeValues
• ReflectAttributeValues は、RTI によって、更新された値の特定の属性をサブスクライブしているフェデレートに通知するために使用されます。

相互作用:

• パラメータ値を含む特定のインタラクション クラスのインタラクションを送信するために使用される SendInteraction。
• RTI が特定のインタラクション クラスにサブスクライブしているフェデレートにパラメータ値を含むインタラクションを配信するために使用する ReceiveInteraction

HLA インターフェース仕様の第 7 章^[5]で説明されている所有権管理サービスの目的は、どのフェデレートがオブジェクト インスタンスのどの側面をシミュレートするかを動的に管理することです。HLA では、特定のオブジェクト インスタンスの特定の属性を更新できるフェデレートは 1 つだけです。そのフェデレートは属性の所有者とみなされます。新しいオブジェクト インスタンスを登録するフェデレートは、自動的に公開するすべての属性の所有者になります。場合によっては、オブジェクト インスタンスの属性が非所有、つまりどのフェデレートにも所有されなくなることがあります。

所有権管理は、実行時に 1 つまたは複数の属性の所有権を転送するサービスを提供します。これには、フェデレートによる属性の譲渡と別のフェデレートによる属性の取得が含まれます。主なパターンは 2 つあります。取得フェデレートによって開始される「プル」と、譲渡フェデレートによって開始される「プッシュ」です。

「プル」所有権を開始するための主要なサービスは次のとおりです。

• 所有されていない属性の所有権を取得したいフェデレーションによって使用される AttributeOwnershipAcquisitionIfAvailable。
• AttributeOwnershipAcquisition は、所有される可能性のある属性の所有権を要求したいフェデレーションによって使用されます。

「プッシュ」所有権を開始するための主要なサービスは次のとおりです。

• AttributeOwnershipDivestitureIfWanted は、これらの属性の所有権を取得するために待機している他のフェデレートがある場合にのみ、属性を売却したいフェデレートによって使用されます。
• NegotiatedAttributeOwnershipDivestiture は類似していますが、RTI が新しい所有者を見つけようとする可能性もあります。
• UnconditionalAttributeOwnershipDivestiture は、新しい所有者が見つからない場合でも、所有権を放棄したいフェデレーションによって使用されます。

すべてのオブジェクト インスタンスには、HLAPrivilegeToDeleteObject と呼ばれる定義済みの属性があります。オブジェクト インスタンスのこの属性の所有者だけが、オブジェクト インスタンスを削除できます。この属性の所有権は、上記の操作を使用して実行時に譲渡できます。

HLA フェデレーションにおける情報交換は、HLA 時間管理が有効になっていない限り、メッセージが即時 (受信順序、RO) 配信され、リアルタイムで行われます。HLA インターフェイス仕様の第 8 章^[5]で説明されている HLA 時間管理の目的は、フェデレーションがリアルタイム、リアルタイムより高速、リアルタイムより低速、または可能な限り高速のいずれで実行されても、タイムスタンプ順序 (TSO) でタイムスタンプ付きメッセージ (更新と対話) の因果関係と正確で一貫した交換を保証することです。

HLA 時間管理における重要な概念は次のとおりです。

論理時間: HLA 内のゼロから始まる時間軸。論理時間は、時間管理のタイムスタンプと操作に使用されます。論理時間軸は、フェデレーションのシナリオ時間にマッピングできます。このようなマッピングの例としては、ゼロを 1066 年 1 月 1 日のシナリオ時間 8:00 として、1 ずつ増分してシナリオの 1 秒を表すことが挙げられます。

先読み: フェデレートがメッセージを生成する将来の最小時間を指定する時間間隔。固定時間ステップを持つフェデレートの場合、これは通常、時間ステップの長さになります。

許可: フェデレートは、その時間までのすべてのタイムスタンプ付きメッセージが配信されると、RTI によって特定の論理時間まで許可されます (進むことが許可されます)。その後、フェデレートは、将来のタイムスタンプを持つメッセージの計算を安全に開始できます。このタイムスタンプは、許可された時間とフェデレートの先読み時間の合計よりも前になることはできません。

前進: フェデレートが、与えられた時間と先読み時間のデータ生成を完了すると、後の時間への前進を要求できます。これは、要求された時間と先読み時間より前のタイムスタンプを持つメッセージをこれ以上生成しないことを約束することも意味します。フェデレートは現在、前進状態にあります。

時間調整: タイムスタンプ付きのイベントを送信するフェデレーションは、他のフェデレーションによる時間の進行がこれによって調整される可能性があるため、時間調整であると見なされます。

時間制約: 時間管理イベントを受信するフェデレーションは、タイムスタンプ付きメッセージの受信によって時間の進行が制約されるため、時間制約があると見なされます。

HLA 時間管理の主な原則は次のとおりです。

• 各時間調整フェデレートは、メッセージ (更新と対話) が送信されるときにタイムスタンプを割り当て、メッセージが有効なシナリオ時間を示します。
• RTI は、時間制限のあるフェデレートへのメッセージの配信を管理し、時間規制フェデレートからのメッセージは、タイムスタンプ順序キューを使用して適切な時間に配信されます。
• 時間制限のあるフェデレーションは、RTI に時​​間を進める許可を要求します。
• RTI は、フェデレートが過去のタイムスタンプを持つメッセージを受信できないことが確実な場合、時間制約のあるフェデレートに時間の前進を許可します。

先読み、許可、前進の例:

1. フェデレートは固定時間ステップ 10 を使用し、Lookahead は 10 です。
2. RTI によってフェデレートに論理時間 50 が付与されます。したがって、RTI は、時間ステップが 50 以下のすべてのメッセージがフェデレートに配信されたことを保証します。
3. これで、フェデレーションは、与えられた時間と先読み時間、つまり 60 の間にメッセージを正しく計算して送信するために必要なすべてのデータを取得しました。
4. フェデレートは、タイムスタンプ 60 のすべてのメッセージを送信すると、時刻を 60 に進めるように要求します。これにより、タイムスタンプが 70 未満のメッセージを送信しないことが約束されます。
5. RTI は、タイムスタンプが 60 以下のすべてのメッセージをフェデレートに配信します。次に、フェデレートに 60 のタイムスタンプを許可します。
6. 等。

フェデレーション内の少なくとも 1 つのフェデレートがペーシングを実行する場合、つまり、時間先行要求をリアルタイム クロックと相関させる場合、フェデレーションはリアルタイムまたはスケールされたリアルタイムで実行されます。ペーシングがない場合、フェデレーションは可能な限り高速に実行されます (たとえば、実行時に人間の介入を必要とせず、リアルタイム クロックに依存するシステムとのインターフェイスも必要としないフェデレーションは、コンピューティング リソースが許す限り高速に実行できます)。

主なサービスは次のとおりです。

• EnableTimeConstrainedとEnableTimeRegulatingは、フェデレートに対してこれらのモードを有効にします
• TimeAdvanceRequest は、フェデレートが指定された論理時間に進むことを要求する。
• TimeAdvancedGrant により、RTI はフェデレーションに指定された論理時間が許可されていることを通知します。
• EnableAsynchronousDelivery は、フェデレートが許可された状態と進行中の状態の両方で、受信注文メッセージの配信を有効にします。

イベント駆動型シミュレーションの場合、フェデレートが次のサービスを使用して次のイベントに進むように要求することもできます。

• NextMessageRequest は、フェデレートが、フェデレートに配信される次のメッセージのタイムスタンプ、または指定された論理時間のいずれか小さい方のタイムスタンプに進むように要求します。

もう 1 つの重要な概念は、最大利用可能論理時間(GALT) です。各フェデレートに付与できる最大時間は、他のフェデレートに付与されている時間と、その先読みによって決まります。フェデレートの GALT は、他のフェデレートに付与されるのを待たずに、フェデレートに付与できる時間を指定します。これは、時間管理フェデレーションに遅れて参加するフェデレートにとって特に重要です。

GALT の主なサービスは次のとおりです。

• 呼び出しフェデレートの GALT を返す QueryGALT。

さらに高度なサービスには以下が含まれます:

• FlushQueueRequest を使用すると、フェデレーションは、タイムスタンプがどれだけ将来であっても、キューに入れられたタイムスタンプ付きメッセージすべての配信を要求できます。
• 撤回。これにより、フェデレートは、すでに送信されたメッセージの撤回を要求できます。これは、楽観的シミュレーションで役立ちます。

^{HLAインターフェース仕様の第9章[5]}で説明されているDDMの目的は、クラスと属性のサブスクリプションを超えて、サブスクライブされたデータの追加フィルタリングを実行することで、フェデレーションのスケーラビリティを向上させることです。^[11]フィルタリングは、連続値（緯度と経度など）または離散値（車のブランドなど）に基づいて行うことができます。

DDM の主要な概念は次のとおりです。

ディメンション: フィルタリングに使用される名前付き間隔 (0..n)。値は 0 から始まり、上限 n で終わります。シミュレーション ドメイン内のデータは、1 つ以上のディメンションにマップされます。たとえば、地理的フィルタリングのディメンションは、LatitudeDimension と LongitudeDimension になります。自動車のブランドに基づいてフィルタリングするディメンションは、CarBrandDimension になります。

正規化関数: 入力値をディメンションで使用する整数値にマッピングする関数。たとえば、LatitudeDimension の正規化関数は、-90.0 ～ +90.0 の範囲の緯度値を 0 ～ 179 の範囲の整数にマッピングできます。CarBrandDimension の正規化関数は、Kia、Ford、BMW、Peugeot の自動車ブランドのセットを 0 ～ 3 の範囲の整数にマッピングできます。

範囲: 下限 (含む) と上限 (含まない) によって指定される次元上の間隔。

リージョン: それぞれが特定のディメンションに関連する範囲のセット。上記の例では、リージョンは LatitudeDimension の (3..5)、LongitudeDimension の (55..65)、および CarBrandDimension の (0..1) の範囲で構成できます。実行時に、リージョン実現 (オブジェクト) がインスタンス化されてリージョンを表します。リージョンの範囲は時間の経過とともに変更される可能性があります。

領域の重複: 2 つの領域が重複するのは、共通するすべての次元の範囲が重複している場合です。

実行時に、フェデレートはオブジェクト クラスの属性とインタラクションをサブスクライブするときにリージョンを提供できます。リージョンは、属性の更新とインタラクションを送信するときにも使用されます。DDM を使用すると、リージョンが重複している場合にのみ、属性の更新とインタラクションが配信されます。

Regions の主なサービスは次のとおりです。

• 指定された一連のディメンションを持つ領域を作成するために使用される CreateRegion。
• 領域を削除するために使用される DeleteRegion。
• リージョンのディメンションの範囲を変更するために使用される CommitRegionModifications。

DDM と属性更新を交換するための主要なサービスは次のとおりです。

• RegisterObjectInstanceWithRegions は、属性に関連付けられた領域を持つオブジェクト インスタンスを登録するために使用されます。
• AssociateRegionsForUpdates は、領域をオブジェクト インスタンスの属性に関連付けるために使用されます。
• SubscribeObjectClassAttributesWithRegions は、サブスクリプションに使用される領域が属性の領域と重複するオブジェクトの属性をサブスクライブするために使用されます。

DDM とのインタラクション交換のための主要なサービスは次のとおりです。

• SubscribeInteractionClassWithRegions は、サブスクリプションに使用される領域がインタラクションの領域と重複するインタラクションにサブスクライブするために使用されます。
• 関連する領域とのインタラクションを送信するために使用される SendInteractionsWithRegions。

HLAインターフェース仕様の第10章^[5]に記載されているHLAサポートサービスは、いくつかのサポートサービスを提供します。これには以下が含まれます。

• 上記のサービス呼び出しで使用されるハンドル (参照) を取得します。
• 特にアドバイザリ (通知) 用のさまざまなランタイム スイッチを設定します。
• コールバックの配信を制御します。

^{HLA インターフェース仕様[5]}の第 11 章で説明されている管理オブジェクト モデルの目的は、フェデレーションを管理するためのサービスを提供することです。これは、MOM オブジェクトとインタラクション クラスを使用して実行されます。MOM オブジェクトは、MIM と呼ばれる特別な FOM モジュールで定義され、RTI によって自動的にロードされます。主な MOM 機能は次のとおりです。

• フェデレートのプロパティを一覧表示して検査します。
• フェデレーションのプロパティを検査します。
• 現在の FOM および FOM モジュールの内容を取得します。
• 時間管理の状態を検査します。
• フェデレートのパブリケーションとサブスクリプションを検査および変更します。
• 特定のパフォーマンス数値を検査します。
• どのフェデレーションがどの HLA サービスを呼び出すかを調べます。
• 同期ポイントのステータスを検査します。

OMT は、フェデレーション オブジェクト モデル (FOM) とシミュレーション オブジェクト モデル (SOM) を記述するために使用されるテンプレートです。FOM と SOM は、表形式または XML を使用して表すことができます。後者の形式は、FOM が RTI にロードされるときに使用されます。

HLA の以前のバージョンでは、FOM はモノリシックでしたが、現在のバージョンの標準ではモジュール式 FOM がサポートされており、情報交換のさまざまな側面をカバーする複数のモジュールを RTI に提供できます。

標準では、多数の定義済みクラス、データ型、ディメンション、およびトランスポート タイプが提供されています。これらは、HLAstandardMIM.xml FOM モジュールで提供されています。定義済み概念には、HLAobjectRoot や HLAunicodeString のように HLA というプレフィックスが付けられます。

OMT には 3 つの異なる XML スキーマがあります。

• OMT DIF XML スキーマは、OMT ドキュメントが基本的な OMT 形式に従っているかどうかを検証しますが、完全であり参照整合性があるかどうかは検証しません。
• OMT FDD XML スキーマは、OMT ドキュメントに RTI で使用できる十分な情報が含まれているかどうかを検証します。このスキーマはインターフェイス仕様で提供されていることに注意してください。
• OMT ドキュメントが完全であり、参照整合性があることを確認する OMT 適合スキーマ。

識別テーブルの目的は、モデルに関するメタデータを提供して、FOM/SOM またはフェデレートの再利用を容易にすることです。

以下のフィールドが指定されます。

• 一般: 名前、タイプ (FOM/SOM)、バージョン、変更日、セキュリティ分類、リリース制限、目的、アプリケーションドメイン、説明、使用制限、使用履歴
• キーワード: 使用されるキーワードの値と分類法
• 連絡先 (POC): タイプ (主な作成者/貢献者/提案者/スポンサー/リリース権限/技術 POC)、POC 名、POC 組織、POC 電話番号、POC 電子メール
• 参照: タイプ (テキスト ドキュメント/スプレッドシート/Powerpoint ファイル/スタンドアロン FOM/依存関係 FOM/FOM から構成)、識別 (ドキュメント名または FOM 名)
• 他の
• グリフ（アイコン）

オブジェクト クラス構造テーブルの目的は、HLA フェデレーションでオブジェクトをインスタンス化するために使用されるオブジェクト クラスのクラス階層 (サブクラス/スーパークラス) を指定することです。オブジェクト クラス属性は、この階層に基づいてスーパークラスからサブクラスに継承されます。オブジェクト クラス ツリーのルートは HLAobjectRoot と呼ばれます。オブジェクト クラスの完全修飾名の例は、HLAobjectRoot.Car.ElectricCar です。

階層内のオブジェクト クラスには次のフィールドが指定されます。

• 名前
• 公開 (Publish/Subscribe/PublishSubscribe/どちらでもない)

属性テーブルの目的は、特定のオブジェクト クラスで使用できる属性を指定することです。属性は継承されるため、オブジェクト クラスには、オブジェクト クラスでローカルに定義されているか、直接または間接のスーパークラスで指定されているすべての属性の結合が含まれます。

属性には以下のフィールドが指定されます

• 定義されているオブジェクトクラス名
• 属性名
• データ型はデータ型表で定義されています（下記参照）
• 更新タイプ (静的/定期的/条件付き/NA)
• 更新条件
• D/A (売却/取得/譲渡不可/売却取得): HLA 所有権サービスを使用して属性を売却または取得できるかどうか
• P/S (Publish/Subscribe/PublishSubscribe/Neither): 属性を公開および/またはサブスクライブできるかどうか。SOM では、この情報は記述されたフェデレートに関連し、FOM ではフェデレーション全体に関連します。
• 利用可能な寸法
• 輸送手段（輸送手段の表に記載されている信頼性/ベストエフォート/その他の輸送手段）
• 注文 (受信/タイムスタンプ): 属性更新の配信順序。

インタラクション クラス構造テーブルの目的は、HLA フェデレーションでインタラクションを交換するために使用されるインタラクション クラスのクラス階層 (サブクラス/スーパークラス) を指定することです。インタラクション クラス パラメータは、この階層に基づいてスーパークラスからサブクラスに継承されます。インタラクション クラス ツリーのルートは、HLAinteractionRoot と呼ばれます。インタラクション クラスの完全修飾名の例は、HLAinteractionRoot.CarCommand.Start です。

階層内のインタラクション クラスには次のフィールドが指定されます。

• 名前
• 公開 (Publish/Subscribe/PublishSubscribe/どちらでもない)

パラメータ テーブルの目的は、特定のインタラクション クラスで使用できるパラメータを指定することです。パラメータは継承されるため、インタラクション クラスには、インタラクション クラスでローカルに定義されているか、直接または間接のスーパークラスで指定されているすべてのパラメータの結合が含まれます。

ディメンション テーブルの目的は、属性と相互作用クラスに使用される 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 には、ユーザー定義のシンプル データ型を含めるのが一般的です。

列挙データ型テーブルの目的は、有限の離散値セットを取ることができるデータ要素を記述することです。標準では、定義済みの列挙データ型の 1 つである HLAboolean が提供されています。FOM には、ユーザー定義の列挙データ型を含めるのが一般的です。

列挙データ型テーブルの目的は、データ要素の配列 (単純、列挙、配列、固定レコード、またはバリアント レコード) を記述することです。HLA 標準では、HLAASCIIstring、HLAunicodeString、HLAopaqueData、および HLAtoken という定義済みの単純データ型が多数提供されています。FOM には、ユーザー定義の配列データ型を含めるのが一般的です。

固定レコード データ型テーブルの目的は、固定されたデータ要素セット (単純レコード、列挙レコード、配列レコード、固定レコード、またはバリアント レコード) を持つレコードを記述することです。

バリアント レコード データ型テーブルの目的は、さまざまな定義済みデータ要素セットを含む可能性のあるレコードを記述することです。さまざまなセットは代替と呼ばれます。特定のバリアント レコードに適用される代替は、判別式と呼ばれるデータ要素によって示されます。

注釈テーブルの目的は、他のテーブル内の項目の注釈と追加の説明を提供することです。

HLAの規則では、連盟とそれに加盟する連盟の責任について規定している。^[12]

1. フェデレーションには、HLA オブジェクト モデル テンプレート (OMT) に従って文書化された HLA フェデレーション オブジェクト モデル (FOM) が必要です。
2. フェデレーションでは、FOM 内のオブジェクトのすべての表現は、ランタイム インフラストラクチャ (RTI) 内ではなく、フェデレート内に存在します。
3. フェデレーションの実行中、フェデレート間の FOM データのすべての交換は RTI を介して行われます。
4. フェデレーションの実行中、フェデレートは HLA インターフェイス仕様に従ってランタイム インフラストラクチャ (RTI) と対話する必要があります。
5. フェデレーションの実行中、オブジェクトのインスタンスの属性は、常に 1 つのフェデレーションによってのみ所有されます。
6. フェデレートは、HLA オブジェクト モデル テンプレート (OMT) に従って文書化された HLA シミュレーション オブジェクト モデル (SOM) を持つ必要があります。
7. フェデレートは、SOM で指定されたとおりに、SOM 内のオブジェクトの属性を更新および/または反映し、SOM オブジェクトのインタラクションを外部に送信および/または受信できるものとします。
8. フェデレーションは、SOM で指定されているように、フェデレーション実行中に属性の所有権を動的に譲渡および/または受け入れることができるものとします。
9. フェデレートは、SOM で指定されているように、オブジェクトの属性の更新を提供する条件を変更できるものとします。
10. フェデレーションは、フェデレーションの他のメンバーとのデータ交換を調整できるように、ローカル時間を管理できる必要があります。

IEEE 1516 規格は、SISO HLA-Evolved Product Development Group によって改訂され、2010 年 3 月 25 日に IEEE Standards Activities Board によって承認されました。改訂された IEEE 1516–2010 規格には、現在の DoD 規格の解釈と、SISO DLC API の拡張バージョンである EDLC API が含まれています。その他の主な改善点は次のとおりです。

• スキーマや拡張性など、FOM/SOM の拡張 XML サポート
• フォールトトレランスサポートサービス
• Web サービス (WSDL) サポート/API
• モジュラーFOM
• 更新レートの削減
• エンコーディングヘルパー
• 追加のトランスポート (QoS、IPv6 など) の拡張サポート
• 標準化された時間表現

シミュレーション間の適切な相互作用を保証するために、フェデレートの適合性をテストする方法が定義されています。これには、特定のフェデレートの SOM にリストされているすべてのクラスと相互作用が、説明されている使用法 (「PublishSubscribe」、「Publish」、「Subscribe」、または「None」) に従って使用されていることを確認することが含まれます。

HLA（現在のIEEE 1516バージョンとその祖先である「1.3」バージョンの両方）は、モデリングとシミュレーションに関するNATO標準化協定（STANAG 4603）の対象です：モデリングとシミュレーションのアーキテクチャ標準、技術的な相互運用性：高レベルアーキテクチャ（HLA）。^[13]

ベースオブジェクトモデル（BOM）SISO-STD-003-2006は、 HLAシミュレーションの再利用性と構成性を向上させるためのSISOの関連標準です。概念モデルを指定し、それをHLA FOMにマッピングする方法を提供します。^[14]

分散モデリングおよびシミュレーション (DM&S) 業界に関して、軍事プラットフォームのリアルタイム シミュレーションに HLA の代替として最もよく使用されるのは、シミュレーション プロトコルである分散インタラクティブ シミュレーション(DIS)、IEEE 1278.1-2012 です。ほとんどのHLA RTI ベンダーも自社製品に DIS を採用しています。パブリッシュ アンド サブスクライブ機能 (P&S) など、HLA 機能に最も近いミドルウェア アプリケーションについては、データ配信サービス (DDS) を参照してください。DDS は、多くの同じ特性を共有していますが、システムの相互運用性のためにオープンなオンザワイヤ プロトコルを備えています。^[15]

HLAは、 C++またはJava APIによって提供される一連のサービスとして定義されるメッセージ指向ミドルウェアです。標準化されたオンザワイヤプロトコルはありません。フェデレーションの参加者は、同じプロバイダーのRTIライブラリを使用する必要があります。通常、同じバージョンであるため、場合によっては欠点と見なされます。^[16]現在のツールのほとんどは、ソケットを介した相互接続も提供しています。

• 商用および非商用RTIのリスト
• コンピュータシミュレーション
• 分散コンピューティング
• シミュレーション相互運用性標準化機構

• HLA チュートリアル: 無料チュートリアル (PDF)

• IEEE モデリングおよびシミュレーション標準 (M&S) 高レベルアーキテクチャ (HLA) の正誤表 - フェデレート インターフェース仕様
• 国防総省 (DoD) IEEE 1516–2000 シリーズ標準の解釈、リリース 2 (2003 年 7 月 1 日)