(57)【要約】【課題】複数のシミュレータが、互いにメッセージを送受し、連携しながらシミュレーションを行う分散シミュレーションシステムにおいて、HLAでは、不要メッセージ送受の削除フィルタリング機能が提供されているが、当該フィルタをシミュレーション実行中に変更した場合、その変更処理の実施及び完了時刻の保証がないため、解析型論理時刻シミュレーションでは、因果関係に矛盾が発じる可能性があり、当該フィルタの動的変更は実施できない。【解決手段】HLAが提供するフィルタリング機能において、シミュレーション実行中に当該フィルタを変更する場合、当該変更が完了するまでは、当該フィルタを利用しないでメッセージを送ることにより、解析型の論理時刻シミュレーションでも、問題（因果関係の矛盾発生）無く利用できる方法に関するものである。【選択図】図４
2010250684.tif 000002
【特許請求の範囲】
【請求項１】
対象物をシミュレーションするシミュレータ（フェデレート）がネットワークにより複数接続され、各フェデレート間の情報の送受通信は同じくネットワークに接続されたRTI（Run Time Infrastructure）を介し、HLA（High Level Architecture, IEEE1516）に基づき、かつ通信フィルタリング機能を用いて行われる分散シミュレーションシステムにおいて、通信フィルタリングを適用してデータを発信するフェデレートが、シミュレーション実行中に当該フィルタを再設定する場合は、当該再設定をRTIに指示してから、RTIから当該再設定完了通知が届くまでの期間は、通信フィルタリングを適用しないデータを、当該データを受信要求しているフェデレートに対して発信することを特徴とするシミュレーション実行方法。
【請求項２】
対象物をシミュレーションするフェデレートがネットワークにより複数接続され、各フェデレート間の情報の送受通信は同じくネットワークに接続されたRTIを介し、HLAに基づき、かつ通信フィルタリング機能を用いて行われる分散シミュレーションシステムにおいて、通信フィルタリングを適用してデータを受信するフェデレートが、シミュレーション実行中に当該フィルタを再設定する場合は、当該再設定をRTIに指示するとともに、当該データを発信するフェデレートに対して、フィルタを変更したことを伝えるメッセージを発行し、フィルタ変更メッセージを受信したデータ発信フェデレートは、次のデータ発信時刻から、RTIから当該フィルタの再設定完了通知が届くまでの期間、通信フィルタリングを適用しないデータを、当該データの受信要求フェデレートに対して発信することを特徴とするシミュレーション実行方法。
【請求項３】
対象物をシミュレーションするフェデレートがネットワークにより複数接続され、各フェデレート間の情報の送受通信は同じくネットワークに接続されたRTIを介し、HLAに基づき、かつ通信フィルタリング機能を用いて行われる分散シミュレーションシステムにおいて、通信フィルタリングを適用してデータを発信するフェデレートが、シミュレーション実行中に当該フィルタを再設定する場合は、当該再設定をRTIに指示した直後から、RTIからの当該再設定完了通知を受け取るまでの間、当該フェデレートは微小（論理）時間毎に当該完了通知を受け取るためのRTIへの問い合わせ処理を続け、受け取った後に当該データを発信することを特徴とするシミュレーション実行方法。
【請求項４】
対象物をシミュレーションするフェデレートがネットワークにより複数接続され、各フェデレート間の情報の送受通信は同じくネットワークに接続されたRTIを介し、HLAに基づき、かつ通信フィルタリング機能を用いて行われる分散シミュレーションシステムにおいて、シミュレーション実行中に当該フィルタを再設定する場合、データを発信するフェデレートは当該再設定をRTIに指示した直後から、RTIからの当該再設定完了通知を受け取るまでの許容誤差時間（τ）をシミュレーションする対象物に応じて設定し、τの時間内だけ当該フェデレートは微小（論理）時間毎に当該完了通知を受け取るためのRTIへの問い合わせ処理を続け、受け取った後にデータを発信するフェデレートは当該データを受信要求しているフェデレートに対して発信し、τ時間内に当該完了通知を受け取れない場合は、τ時間経過後、データを発信するフェデレートは、RTIから当該再設定完了通知が届くまでの期間、通信フィルタリングを適用しないデータを、当該データを受信要求しているフェデレートに対して発信することを特徴とするシミュレーション実行方法。
【請求項５】
対象物をシミュレーションするフェデレートがネットワークにより複数接続され、各フェデレート間の情報の送受通信は同じくネットワークに接続されたRTIを介し、HLAに基づき、かつ通信フィルタリング機能を用いて行われる分散シミュレーションシステムにおいて、通信フィルタリングを適用して、シミュレーション実行中に当該フィルタを再設定する場合、当該再設定をRTIに指示してから、RTIから当該再設定完了通知が届くまでの期間は、データを発信するフェデレートは通信フィルタリングを適用しないデータを、当該データを受信要求しているフェデレートに対して発信し、当該データを受け取ったフェデレートが不要な摸擬を実施するコストの総和と、当該フェデレートは微小（論理）時間毎に当該完了通知を受け取るためのRTIへの問い合わせ処理を続け、受け取った後に当該データを発信することによりフェデレーション全体の実行性能が低下するコストとを比べ、低コストの方法を採用することを特徴とするシミュレーション実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機を利用して、大規模シミュレーションを高性能かつ高精度で実現するためのHLA（High Level Architecture、IEEE1516）を基本とした並列・分散シミュレーション技術に関するものである。
【背景技術】
【０００２】
1980年代から、米国の防衛分野を中心に、訓練用、作戦立案用、そして解析用などのシミュレーションシステムが研究開発され、実用化に至っている。実際の状態を想定した、戦闘・戦術訓練やフィールド演習は、膨大な人員・コストを要することから、計算機シミュレーション技術の導入が効率的である。特に、防災や防衛分野では、現実に近い大規模な環境や組織を対象にする必要があり、またコスト・パフォーマンスの観点からも、並列分散シミュレーション技術の利用が必須となる。
しかし、いざ、大規模シミュレーションを構築すべく、各組織（例：各軍）におけるシミュレーションシステムの統合を試みても、各々のシステムは独自仕様で構築されているために、統合化は非常に困難なものであった。結局、統合化のために、システムを一から作り直すといったことも多々発生していた。
【０００３】
このような苦い経験から、米国防総省が中心となって、シミュレーションシステムの仕様を共通化するための標準化作業に力を入れるようになった。今まで、SIMNET（SIMulator NETwork: 1985年〜1989年）、DIS（Distributed Interactive Simulation: 1989年〜）、そしてALSP（Aggregate Level Simulation Protocol: 1989年〜）などが規格化されたが、2000年にこれらの規格を包括したHLA（High Level Architecture、IEEE1516）が登場した。
HLAの仕様は、米国防総省の旧組織であったDMSO（Defense Modeling and Simulation Office）が1995年に提案したもので、標準化団体SISO（Simulation Interoperability Standard Organization）が中心となって標準化を進めており、2000年9月にIEEE1516としてIEEE標準となり、その後も改良のための改定作業が続いている。HLAは、DISタイプのリアルタイム型シミュレータ、ウォーゲームタイプの解析型の論理時刻シミュレータなど、同機種または異機種のシミュレータを相互接続するための接続仕様である。なお、米国防総省は、シミュレータ間の相互接続性の確保だけでなく、再利用性を推進する目的もあり、2001年以降、全てのシミュレーションシステムをHLA化する方針をとっている。
HLAでは、共通の目的のために連携して動作する1つの分散シミュレーションシステムをフェデレーションと呼び、その中の個々のシミュレータに相当するものをフェデレート（FED）と呼ぶ。FEDはLP（Logical Process：論理時刻進行の単位）に対応するものである。
【０００４】
また、FED間で、送受されるオブジェクト（FOM：Federation Object Model）の属性情報を定義するファイルとして、FDD（FOM Document Data）が存在する。このファイルはシステム設計時にアプリケーション構築者が定義するものである。本通信では、オブジェクトの属性情報を各FEDがRTI（Run Time Infrastructure）に対して「公開」及び「購読」を宣言することにより、その情報が更新された時点で、公開側から購読側へRTIの介在により定期的に送信されることとなる。その他、本通信以外に、インタラクションクラスと称する、FED間で非定期に通信する方法もある。
【０００５】
ここで、RTI（Run Time Infrastructure）とは、HLA規格に準拠したシステムでの中核となるソフトウェアで、HLAの規格に基づいて、FED間のデータ送受や同期処理を司るものである。RTIとFED間のHLAサービスには６種類存在するが、本発明で関係するのは、この内の1つである、DDM（Data Distribution Management）である。DDMはFED間の通信をフィルタリングする機能を有するものであり、無駄な通信を排除し、実行性能の低下を防ぐために用いるものである。更に、もう1つ関係するものがTM（Time Management）であり、本発明において、TMは各FEDの時刻進行を調整及び制御するものである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2007-72678号公報「シミュレーション実行方法」
【非特許文献】
【０００７】
【非特許文献１】IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)-Federate Interface Specification,IEEE STd 1516.1-2000
【非特許文献２】A.Ozaki, et al, “Event-Aware Dynamic Time Step Synchronization Method for Distributed Moving Object Simulation,” IEICE Trans. Vol. E89-A No.11 pp.3175-3184, Nov 2006.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
現在のHLAの仕様では、各FEDが論理時刻に基づいてシミュレーションを進めている際に、或るFEDがDDMによる通信フィルタ変更指示をRTIにした場合、その変更処理が、どの時刻に完了するかが保証されていない。このため、従来、解析用途の論理時刻シミュレーションでは、シミュレーション実行中にDDMによる通信フィルタを変更することが無いように、当該フィルタを充分大きく設定して用いるのが一般的な利用形態であった。
このような利用形態では、殆どフィルタリングの効果が無いような場合が多く、性能向上のための機能としては充分なものでは無かった。
本発明は、解析用途の論理時刻シミュレーションにおいて、HLA-DDMを利用する方法に関するもので、FEDがシミュレーション実行中にDDMによる通信フィルタを変更したとしても、送信データ未達の問題が発生しないように効率的にシミュレーションを実行するためのものである。
【課題を解決するための手段】
【０００９】
本課題を解決するための1つの実行方法（方法１）は、通信フィルタの変更要求を発行した時点から、実際に当該変更処理が完了するまでの期間は、DDMに基づいてデータを発信するFEDはフィルタリングをかけずにデータ配信する方法である。本方法では、送信するデータが論理時間に基づいて確実に配達されることとなるが、状況に応じては、当該データを不要とするFEDにまで配達してしまう場合がある。しかし、配達されなければならないデータが未達であれば、シミュレーション結果が変わってしまうこととなり問題となるが、余計に届く場合には、不要な処理／摸擬が発生するが結果は変わらないため問題は生じない。
【００１０】
本課題解決のための他の実行方法（方法２）は、FEDはRTIからフィルタ再設定完了通知が届くまでデータ配信を待つという方法である。本方法では、上記方法１での「当該データを不要とするFEDにまで配達してしまう」ことは生じないが、RTIから当該通知を受け取るための問い合わせ処理を、当該データを発信するFEDは実施し続けなければならず、そのためにフェデレーション全体の実行性能が低下してしまう可能性がある。更に、HLAでは本問い合わせ処理のために、当該FEDは微小なりとも時刻進行せざるを得なく、摸擬精度が劣化する問題が生じる。従って、方法２では、許容可能な論理時間幅が設定可能であれば、当該時間幅の間だけ本方法が適用できることとなる。
その他、上記方法１と２の折衷案が考えられる。即ち、どちらが低コストで実施できるかで、状況に応じて適応的に方法１か２を選択するというものである。
【発明の効果】
【００１１】
通信フィルタの変更要求を発行した時点から、実際に当該変更処理が完了するまでの期間は、DDMに基づいてデータを発信するFEDはフィルタリングをかけずにデータ配信する実行方法１では、状況に応じては当該データを不要とするFEDにまでデータを配達してしまう場合があり、不要な処理／摸擬が発生するが、送信するデータが論理時間に基づいて確実に配達されることとなる。
【００１２】
また、RTIからフィルタ再設定完了通知が届くまでFEDはデータ配信を待つという実行方法２では、当該データを発信するFEDはRTIから当該通知を受け取るための問い合わせ処理を、実施し続けなければならず、フェデレーション全体の実行性能が低下してしまう可能性があり、更に、HLAでは本問い合わせ処理のために、当該FEDは微小なりとも時刻進行せざるを得なく、摸擬精度が劣化する問題が生じるが、当該データを不要とするFEDにまで配達することは生じずに送信するデータが論理時間に基づいて確実に配達されることとなる。
これ等の方法により、FED間の通信コストを低減できると共に、不要なデータ受信を削減できるためFED内の不要な処理も削減できることになり、シミュレーション全体としての実行性能向上に大きく寄与できるものである。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態１によるHLA分散シミュレーションシステムの構成図である。
【図２】実施の形態１によるHLA分散シミュレーションシステムにおけるDDMの機能説明図である。
【図３】（１）はDDMの問題点を説明用の図、（２）従来のRegion設定法の説明図である。
【図４】本発明によるRegionを変更する場合の処理フロー図であり、（１）はPublisher側が変更する場合、（２）はSubscriber側が変更する場合を示す。
【図５】Publisher側がRegionを変更し、Regionの重なり「無し」状態から「有り」状態になる場合のタイミングチャートである。
【図６】Publisher側がRegionを変更し、)Regionの重なり「有り」状態から「無し」状態になる場合のタイミングチャートである。
【図７】Publisher側がRegionを変更し、Regionの重なり「無し」の状態のままである場合のタイミングチャートである。
【図８】Publisher側がRegionを変更し、Regionの重なり「有り」の状態のままである場合のタイミングチャートである。
【図９】Subscriber側がRegionを変更し、Region重なり「無し」状態から「有り」の状態になる場合のタイミングチャートである。
【図１０】Subscriber側がRegionを変更し、Region重なり「有り」状態から「無し」状態になる場合のタイミングチャートである。
【図１１】Subscriber側がRegionを変更し、Regionの重なり「有り」の状態から「無し」の状態になる場合のタイミングチャートである。
【図１２】Subscriber側がRegionを変更し、Region重なり「有り」状態のままである場合のタイミングチャートである。
【図１３】FEDとRTIの信号授受例を示したタイミングチャートである。
【発明を実施するための形態】
【００１４】
実施の形態１． 
図１は、航空機、船舶等の移動物体を主対象としたHLAに基づく分散シミュレータの実現の形態を示した構成図であり、レーダ１ａ、航空機２ａ、船舶３ａをそれぞれ1つのFED１，２，３に割り当てた構成となっている。それぞれのFED１，２，３を処理する計算機は、ネットワーク４により接続され、このネットワーク４にはRTＩ５を処理する計算機が接続され、RTI５を処理する計算機にはRTI５の入力ファイルとなるFOM６の属性情報定義ファイルFDD６ａが置かれている。
航空機２ａと船舶３ａを摸擬するそれぞれのFED２，３は、「位置」情報を更新し、ネットワークを介して他のFEDに転送することとなる。また、レーダ１ａを摸擬するFED１は、これらのFED２、３から「位置」情報を購読することとなる。従って、図１の実施の形態では、FED間でやり取りされるオブジェクトクラスは「位置」情報のみであり、FOM６に定義されることとなる。
【００１５】
図２は、DDMの機能を説明したものである。DDMでは、各FEDは、購読及び公開するオブジェクトの、興味の対象となる、シミュレーション空間中の部分領域（Region）をRTI５に対して指定することができる。このRegionはシミュレーション構築者が定義したシミュレーション空間における一次元以上の部分領域（空間）であり、各FEDにて指定されたRegionは正規化されているものである。
【００１６】
図２の例では、このRegionを二次元空間で表現したものである。RTI５では、同一オブジェクトに対する公開FED（Publisher）と購読FED（Subscriber）を検知するとともに、両者のRegionの重なりを調べる。そして重なっている場合に、当該オブジェクトをPublisherが更新した時は、Subscriberへ当該オブジェクトデータが転送されることとなる。
図２の例では、当該オブジェクトデータ（「位置」情報）に関するPublisherがFED2であり、SubscriberがFED１である。そして、FED2が指定した部分領域（RegionＢ）とFED１が指定した部分領域（RegionＡ）の両者が重なっていため、FED2からFED１へ「位置」情報が伝達されることとなる。この場合、FED３も「位置」情報のPublisherであるが、FED３が指定した部分領域（RegionＣ）と、SubscriberであるFED1が指定した部分領域（RegionＡ）とのRegionが重なっていないため、情報が伝達されないこととなる。このように、DDMを利用することにより、FED間の不要な通信を排除し、通信コストの低減及び実行性能の向上を図ることができる。特に、移動体シミュレーションでは、各移動物体が「探知」模擬と「運動」摸擬を繰り返しながら、シミュレーションを進めるが、この「探知」摸擬では、自身と他の全ての移動物体間で、自身が備えるレーダ／センサでの覆域内外判定を行うこととなり、その前段では距離計算等を実施する必要がある。
【００１７】
移動物体数がnである場合、全体のFED間の通信コストのオーダーはO(n2)となる。DDMでは、この移動物体数(n)を低減できるとともに、FED内においても、覆域内外判定を実施する移動物体が絞り込まれているため、計算量が低減できることとなる。従って、DDMの適用により、FED間の通信コスト及びFED内の計算コストが低減できるため、大幅な実行性能向上が期待できることとなる。
【００１８】
図３（１）は、DDMの問題点の例を示したものである。HLA規格のDDMでは、論理時刻に基づいてシミュレーションを実施する場合において、シミュレーション実行中（論理時刻を進めている状態）において、DDMのRegionを変更した場合、どの論理時刻でその変更処理が完了するか保証されていない。即ち、同じ論理時刻シミュレーションでも、状況に応じて、結果が異なってしまうという大きな問題がある。例えば、図３（１）に示すように、論理時刻T=tiの時点では、実際にRadarの覆域にFlightが入っていないため、DDMによりFlightの位置情報がRadarに配達されないよう、Regionが重なっていない状態であり、この状態が実現できているので通信コストを削減でき、かつ問題も生じない。
【００１９】
他方、時刻tiのΔt後に、Flightが進行し、当該Radarの覆域に入ったとすると、Flightの位置情報がRadarに配達されるように、当該Flightの進行に伴ってRegionの空間的な位置も変更させ、T=ti+Δtの時点では両Regionが重なっていなければならない。しかし、上述したように、Regionの変更指示がRTIによっていつ完了するかは保証されていないため、本来、当該Radarによって探知される筈のFlightが探知されずに、摸擬結果が異なってしまう可能性がある。このため、現状では、HLA-DDMは論理時刻シミュレーションにおいて、動的にRegionを変更することができないこととなる。
【００２０】
このため、HLA-DDMでの一般的な利用形態は、シミュレーション実行中はRegionを変更しない。即ち、上記のような問題が発生しないように、Regionを大き目に設定しておくというものである。従って、図３（２）に示すように、因果関係が一切生じない遠方地であればRegionを分けることも可能となるが、そうでなければ、Radarは、Flightが動きうる可能性のある広大な領域をRegion指定することとなり、通信フィルタリングが、実質上無意味な状態となる。このため、論理時刻シミュレーションにおいて、DDMを有効活用するためには、動的にRegionを変更しても問題が生じないような仕組みが必要となる。
【００２１】
図４は上記問題を解決するための本発明の処理フローを示したものである。図４（１）はオブジェクトデータを更新するPublisher側がRegionを変更する場合の処理フローを示したものである。まず、Publisher側でRegionを変更する場合(411)、HLA規格に基づいたRegion変更指示をRTIに発行する(412)。同じタイミングで、今まで「Region指定有り」で更新していたオブジェクトデータを「Region指定無し」に変更して当該データを発信する(413)。そして、当該FEDは時刻進行に伴うRTIとのやり取りを通して、RTIからRegion変更完了通知が届いた場合(414)は、当該データを再び「Region指定有り」に変更し、データ発信(415)を行う。
【００２２】
他方、図４（２）は、オブジェクトデータを受信するSubscriber側がRegionを変更する場合の処理フローを示したものである。まず、Subscriber側でRegionを変更する場合(421)、HLA規格に基づいたRegion変更指示をRTIに発行する(422)と共に、Regionを変更したことを伝えるメッセージ（例えば、HLAのインタラクションクラスによるメッセージを利用）を、当該オブジェクトデータを発信しているFED（Publisher）に伝達する(423)。当該メッセージを受信(424)したFED（Publisher）は、即時、更新データを「Region指定無し」に変更して当該データを発信する(425)。そして、当該FED（Publisher）は時刻進行に伴うRTIとのやり取りを通して、RTIからRegion変更完了通知が届いた場合(426)は、当該データを再び「Region指定有り」に変更し、データ発信(427)を行うというものである。
【００２３】
図５〜８は、図４（１）のオブジェクトデータを更新するPublisher側がRegionを変更する場合のタイミングチャート例であり、(a)Regionの重なり「無し」の状態から「有り」の状態になる場合（図５）、(b)Regionの重なり「有り」の状態から「無し」の状態になる場合（図６）、(c)Regionの重なり「無し」の状態のままである場合（図７）、そして(d)Regionの重なり「有り」の状態のままである場合（図８）の４通りを示したものである。
【００２４】
まず、図５について説明する。FED２（Publisher）及びFED１（Subscriber）にて初期化処理の1つとして、それぞれが興味あるシミュレーション中の部分空間（Region）をRTIに対して指定する(51)。これに伴い、RTI内では同一のオブジェクトデータ（位置情報）に関するPublisherとSubscriberを検出すると共に、両者が指定したRegionの重なりを計算する(52)。そして一連の初期化処理が終わり、シミュレーションが開始されると共に、「Region指定有り」でFED２から位置情報のデータが更新及び発信される(53)。本ケースでは、現状がRegionの重なりが無い場合であるため、本データはFED１へ配達されない状態である。その後、FED２がRegion変更(54)の指示をRTIに発信する（この時点では、当該変更処理は完了していない）と共に、当該データをRegion指定無しに切り替えて発信する(55)ことを、RTIからの変更完了通知(57)が届くまで実施する。そして、当該通知が届いた後は、再び、Region指定有りとして、当該データを更新及び発信することとなる(58)。FED２側がこのような処理を行うことにより、FED１は、RTIでのRegion変更処理に遅延が生じたとしても、論理時間的に切れ目無く、当該データを受信することができる(59)。
【００２５】
図６はオブジェクトデータを更新するPublisher側がRegionを変更する場合において、Regionの重なりが有りの状態から無しの状態になるケースの例である。本ケースでは、図に示すように、FED２（Publisher）及びFED１（Subscriber）にて初期化処理の1つとして、それぞれが興味あるシミュレーション中の部分空間（Region）をRTIに対して指定する(61)。これに伴い、RTI内では同一のオブジェクトデータ（位置情報）に関するPublisherとSubscriberを検出すると共に、両者が指定したRegionの重なりを計算する(62)。そして一連の初期化処理が終わり、シミュレーションが開始されると共に、「Region指定有り」でFED２から位置情報のデータが更新及び発信される(63)。そして、FED２がRegion変更を指示(64) すると共に、当該データをRegion指定無しに切り替えて発信する(65)ことを、当該変更処理が完了(67)するまでの間、FED１は不要なデータ（FED２がRegion指定無しで更新したデータ）を受け取る(69)こととなる。FED１ではこの不要なデータを受信することにより不要な処理が発生(69)してしまうこととなるが、摸擬結果自体は変わらないので問題は生じないこととなる。
【００２６】
図７はオブジェクトデータを更新するPublisher側がRegionを変更する場合において、Regionの重なりが変更後も無い状態のままであるケースの例である。本ケースで処理(71)から処理(73)は、図５に示す処理(51)から処理(53)及び図６に示す処理(61)から処理(63) の処理と同様である。図に示すように、FED２がRegion変更を指示して(74)から、当該変更処理が完了(77)するまでの間、FED１は不要なデータ（FED２がRegion指定無しで更新したデータ）を受け取る(79)こととなる。FED１ではこの不要なデータを受信することにより不要な処理が発生(79)してしまうこととなるが、摸擬結果自体は変わらないので問題は生じないこととなる。
なお、上述以外の処理も図５及び図６に示す処理(と同様の処理をする。
【００２７】
図８はオブジェクトデータを更新するPublisher側がRegionを変更する場合において、Regionの重なりが変更後も有る状態のままであるケースの例である。本ケースで、FED２（Publisher）及びFED１（Subscriber）にて初期化処理の1つとして、それぞれがシミュレーション中の部分空間（Region）をRTIに対して指定する(81)。RTI内では同一のオブジェクトデータ（位置情報）に関するPublisherとSubscriberを検出すると共に、両者が指定したRegionの重なりを計算する(82)。一連の初期化処理が終わり、シミュレーションが開始されると共に、「Region指定有り」でFED２から位置情報のデータが更新及び発信される(83)。本ケースでは、現状がRegionの重なりが有る場合であるため、本データはFED１へ配達される。その後、FED２がRegion変更(84)の指示をRTIに発信すると共に当該データをRegion指定無しに切り替えて発信する(85)ことを、RTIからの変更完了通知(87)が届くまで実施する。そして、当該通知が届いた後は、再び、Region指定有りとして、当該データを更新及び発信することとなる(88)。FED１は、Regionが変更される(87)までの間は、Region指定無しのデータを受け取る(89)こととなるが、論理時間的に途切れなくデータを受け取ることができるので問題は発生しない。
【００２８】
次に、図９〜１２は、図４（２）のオブジェクトデータを受信するSubscriber側がRegionを変更する場合のタイミングチャート例であり、(a)Regionの重なり「無し」の状態から「有り」の状態になる場合（図９）、(b)Regionの重なり「有り」の状態から「無し」の状態になる場合（図１０）、(c)Regionの重なり「無し」の状態のままである場合（図１１）、そして(d)Regionの重なり「有り」の状態のままである場合（図１２）の４通りを示したものである。
【００２９】
まず、図９はオブジェクトデータを購読するSubscriber側がRegionを変更する場合において、Regionの重なりが「無し」の状態から「有り」の状態に変わるケースの例である。
まず、FED２（Publisher）及びFED１（Subscriber）にて初期化処理の1つとして、それぞれが興味あるシミュレーション中の部分空間（Region）をRTIに対して指定する(91)。これに伴い、RTI内では同一のオブジェクトデータ（位置情報）に関するPublisherとSubscriberを検出すると共に、両者が指定したRegionの重なりを計算する(92)。そして一連の初期化処理が終わり、シミュレーションが開始されると共に、「Region指定有り」でFED２から位置情報のデータが更新及び発信される(93)。本ケースでは、現状がRegionの重なりが無い場合であるため、本データはFED１へ配達されない状態である。その後、FED１がRTIに対してRegion変更を指示(94)すると同時に、FED２に対して、Regionを変更したことを知らせるメッセージ（例えば、インタラクションクラスによるメッセージ）を発行(95)する。FED２は当該メッセージを受けると同時に、「Region指定有り」で発行していたオブジェクトデータ（「位置」情報）を、「Region指定無し」に変更し発行する(96)こととなる。そして、RTIからRegion変更完了通知が届く(97)と、FED２は再び、当該データを「Region指定有り」に設定し、発行する(98)。この一連の処理により、図に示すように、RTIでの当該Region変更処理が遅延したとしても、問題無く、FED１は当該データを受け取ることができることとなる。
【００３０】
図１０はオブジェクトデータを購読するSubscriber側がRegionを変更する場合において、Regionの重なりが「有り」の状態から「無し」の状態に変わるケースの例である。本ケースでは、図に示すように、Regionの重なりが「無し」の状態から「有り」の状態に変わるケースの場合と同様に、FED２（Publisher）及びFED１（Subscriber）にて初期化処理の1つとして、それぞれが興味あるシミュレーション中の部分空間（Region）をRTIに対して指定する(101)。これに伴い、RTI内では同一のオブジェクトデータ（位置情報）に関するPublisherとSubscriberを検出すると共に、両者が指定したRegionの重なりを計算する(102)。そして一連の初期化処理が終わり、シミュレーションが開始されると共に、「Region指定有り」でFED２から位置情報のデータが更新及び発信され (103)、本データはFED１へ配達される。その後、FED１がRTIに対してRegion変更を指示する(104)と同時に、FED２に対して、Regionを変更したことを知らせるメッセージ（例えば、インタラクションクラスによるメッセージ）を発行する(105)。FED２は当該メッセージを受けると同時に、「Region指定有り」で発行していたオブジェクトデータ（「位置」情報）を、「Region指定無し」に変更し発行する(106)こととなる。そして、RTIからRegion変更完了通知が届く(107)と、FED２は再び、当該データを「Region指定有り」に設定し、発行する(108)。本ケースでは、図に示すように、FED１はが不要なデータ（FED２がRegion指定無しで更新したデータ）を受け取ることとなる。FED１ではこの不要なデータを受信することにより不要な処理が発生してしまう(109)こととなるが、摸擬結果自体は変わらないので問題は生じないこととなる。
【００３１】
図１１はオブジェクトデータを購読するSubscriber側がRegionを変更する場合において、Regionの重なりが変更後も無い状態のままであるケースの例である。本ケースで、処理(111)と (112)の初期化処理及び処理(113)のFED２から位置情報のデータが更新及び発信されることは図９及び図１０の処理と同様である。本ケースでは、図に示すように、FED１がRTIに対してRegion変更を指示する(114)と同時に、FED２に対して、Regionを変更したことを知らせるメッセージ（例えば、インタラクションクラスによるメッセージ）を発行する(115)。FED２は当該メッセージを受けると同時に、「Region指定有り」で発行していたオブジェクトデータ（「位置」情報）を、「Region指定無し」に変更し発行する(116)こととなる。そして、RTIからRegion変更完了通知が届く(117)と、FED２は再び、当該データを「Region指定有り」に設定し、発行する(118)。本ケースでは、図に示すように、FED１はが不要なデータ（FED２がRegion指定無しで更新したデータ）を受け取ることとなる。FED2ではこの不要なデータを受信することにより不要な処理が発生してしまう(119)こととなるが、摸擬結果自体は変わらないので問題は生じないこととなる。
【００３２】
図１２はオブジェクトデータを購読するSubscriber側がRegionを変更する場合において、Regionの重なりが変更後も有る状態のままであるケースの例である。本ケースで、処理(121)と (122)の初期化処理及び処理(123)のFED２から位置情報のデータが更新及び発信されることは図９〜図１１の処理と同様である。本ケースでは、図に示すように、FED１がRTIに対してRegion変更を指示する(124)と同時に、FED２に対して、Regionを変更したことを知らせるメッセージ（例えば、インタラクションクラスによるメッセージ）を発行する(125)。FED２は当該メッセージを受けると同時に、「Region指定有り」で発行していたオブジェクトデータ（「位置」情報）を、「Region指定無し」に変更し発行する(126)こととなる。そして、RTIからRegion変更完了通知が届く(127)と、FED２は再び、当該データを「Region指定有り」に設定し、発行する(128)。本ケースでは、FED１は、Regionが変更されるまでの間は、Region指定無しのデータを受け取ることとなるが、論理時間的に途切れなくデータを受け取ることができるので問題は発生しない。
【００３３】
図４〜１２で示した本発明の方法１では、シミュレーションにおける因果関係の矛盾を引き起こす可能性は無いが、状況に応じて、不要なデータを受信することにより不要な処理を実施することとなるFEDが存在してしまう場合がある。これに対して、Regionを変更した際には、その変更が完了するまでデータを送信しないという方法２が考えられる。但し、RTIからのRegion変更完了通知をFEDが貰うためには、当該FEDは時刻進行要求をRTIに出しながら問い合わせをしなければならない。このため、微小時刻（ε）毎に時刻を進めながら当該問い合わせを実施することとなり、RTIが直ぐに当該Region変更処理を完了しなければ、フェデレーション全体としての実行性能低下に繋がると共に、摸擬精度もε×nだけ劣化することとなる（ここで、nは当該問い合わせ回数）。但し、方法２は、RTIにおいて直ぐにRegion変更処理が完了されれば、多少の模擬精度劣化は伴うが、不要なデータ配信及び摸擬を発生させないため、効率的に実行できる可能性も高い。なお、方法２は、データを発信するFED側で実施する必要がある。何故なら、データを受信するFED側で本方法を実施してしまうと、εの間に、データが発信されてしまう可能性があり、受け取るべきデータを受け取れない場合があるためである。
【００３４】
なお、図１３はFEDとRTIのやり取りの例を参考までに示したものである。図に示すようにFED内の処理には、RTI側主体の処理が実行される「Time Advancing State(TAS)」とFED側主体の処理が実行される「Time Granted State(TGS)」の２つの状態がある。この二つの状態が一組となり当該FEDの１ステップ分の処理となる。なお、図１３では、本発明に係るサービスしか示していない。ここでは、“RAV/Receive Interaction”はオブジェクトおよびインタラクションクラスの受信、“TAG”は時刻進行許可、“Commit Region Modifications”はRegion変更指示、“UAV/Send Int.” オブジェクトおよびインタラクションクラスの更新及び発信、“TAR/NMR”は時刻進行要求、“EMC”は当該FEDがRTIからの複数のコールバックを受信可能であることを通知する処理、“Turn Updates On/Off”はRTIからのアドバイス通信（例えば、Region変更完了通知の送信）、そして“Attributes In Scope/Out of Scope”もRTIからのアドバイス通信（Region内か外か）に関するものである。
また、方法２において、対象とするアプリケーションに応じた許容誤差時間（τ）をデータを発信するFED側で設定できれば、方法１を適用する前に、式（１）を満足するｎ回だけ、方法２を適用することも考えられる。
【００３５】
τ  ≧  ε×n  ・・・式（１）
ここで、ε；微小時刻、n；FEDからRTIへの問い合わせ回数である。
【００３６】
また、Regionを変更するFEDにおいて、方法１を適用するコストと、方法２を適用するコストをデータを発信するFED側で見積もり、低コストで実行できる方法を採用することも考えられる。但し、対象とするアプリケーションに許容誤差時間（τ）が設けられている場合は、方法２を選択したとしても、τ以内で完了できなければ、その後、方法１を選択せざるを得ないこととなる。
【産業上の利用可能性】
【００３７】
大規模シミュレーションでは、その実行性能が課題であり、本発明はHLA分散シミュレータを対象に、不要な通信を削減することによる実行性能向上を図る方式であるため、HLAを利用した分散シミュレーションシステムで広く活用される可能性がある。
【符号の説明】
【００３８】
１〜３；FED、１ａ；レーダ、２ａ；航空機、３ａ；船舶、４；ネットワーク、５；RTＩ、６；FOM、６ａ；FDD。
【図１】
2010250684.tif 000003
【図２】
2010250684.tif 000004
【図３】
2010250684.tif 000005
【図４】
2010250684.tif 000006
【図５】
2010250684.tif 000007
【図６】
2010250684.tif 000008
【図７】
2010250684.tif 000009
【図８】
2010250684.tif 000010
【図９】
2010250684.tif 000011
【図１０】
2010250684.tif 000012
【図１１】
2010250684.tif 000013
【図１２】
2010250684.tif 000014
【図１３】
2010250684.tif 000015