(57)【特許請求の範囲】
【請求項１】
複数のシミュレータが論理時刻に基づき連携する分散シミュレーションシステムにおける一のシミュレータに含まれる時刻進行制御装置であって、
自シミュレータ及び他のシミュレータの通信開始メッセージを検出する通信開始検出部と、
前記通信開始検出部で検出された通信開始メッセージを登録するメッセージリストと、
前記メッセージリストに前記通信開始メッセージが登録されている場合に、Event Base法を時刻進行方法として選択し、前記メッセージリストに前記通信開始メッセージが登録されていない場合に、Time Step法を時刻進行方法として選択する進行方法選択部と、
前記通信開始メッセージの応答である通信結果メッセージを受信した場合に、当該通信結果メッセージに対応した通信開始メッセージを前記メッセージリストから削除する進行制御部と、
を備えたことを特徴とする時刻進行制御装置。
【請求項２】
自シミュレータの通信開始メッセージを論理時刻に依らない配送形式で他のシミュレータに送信するメッセージ送信部を備えた
ことを特徴とする請求項１に記載の時刻進行制御装置。
【請求項３】
前記通信開始検出部は他のシミュレータから論理時刻に依らない配送形式で送信された通信開始メッセージを受信するメッセージ受信部を備えた
ことを特徴とする請求項１または請求項２のいずれか１項に記載の時刻進行制御装置。
【請求項４】
前記論理時刻に依らない配送形式は、Received Orderedメッセージによる時刻進行通知メッセージであることを特徴とする請求項２または請求項３に記載の時刻進行制御装置。
【請求項５】
模擬対象物体または事象を模擬する模擬処理部と、
分散シミュレーション基盤とのインタフェース処理を行うインタフェース処理部と、
請求項１乃至４のいずれか１項に記載の時刻進行制御装置と、
を備えたことを特徴とするシミュレータ。
【請求項６】
前記他のシミュレータの通信開始メッセージの検出を、High Level ArchitectureのManagement Object Model機能を利用して行うことを特徴とする請求項５に記載のシミュレータ。
【請求項７】
時刻進行をTime Step法またはEvent Base法の間で切り替える請求項５または請求項６に記載のシミュレータと、
Event Base法により時刻進行を行うシミュレータと、
を含むことを特徴とする分散シミュレーションシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、分散シミュレーションシステムにおける時刻進行制御装置及びシミュレータ、及び分散シミュレーションシステムに関する。
【背景技術】
【０００２】
ネットワークによって多数のサブシステムが連接された大規模システムをSoS（System of Systems）システムと呼ぶ。SoSシステムの機能・性能の評価は、対象が大規模かつ複雑なため、ネットワークシミュレータおよびサブシステムシミュレータといった異種・複数のシミュレータを連接した分散シミュレーションシステムとして構築されたSoSシミュレータが用いられることが多い。代表的なSoSシステムには、衛星、レーダサイト、航空機、艦艇、車両、地上設備等がデータリンク等のネットワークで連携する防衛システムが挙げられ、そのSoSシミュレータとしては、非特許文献１に挙げる分散シミュレーションシステムの標準アーキテクチャであるHLA（High Level Architecture）に基づき、レーダシミュレータ、プラットフォームシミュレータ、ネットワークシミュレータ等が連携する防衛システムシミュレータが挙げられる。
【０００３】
SoSシミュレータにおいて、模擬の対象となるSoSシステムの機能・性能を高精度に評価する上で重要な課題は、SoSシミュレータを構成する各シミュレータの時刻同期である。各シミュレータは互いに独立して動作するため、個々のシミュレータが模擬する内容およびシミュレータの入出力データの時刻が同期しないと、正しいシミュレーション結果を得ることができない。このような分散シミュレーションでは、シミュレータ間の同期に実時間の時刻値を用いると、シミュレータを実行している複数計算機の時計誤差や負荷状況の差異等の影響により正しい同期がとれないため、一般的にはシミュレーションの進捗度を変数として表現した論理時刻が用いられる。HLAでは、シミュレータ間の論理時刻を同期する機能としてTime Management Serviceが規定されている。ここでは、背景技術としてHLAによる時刻同期機能について説明する。
【０００４】
まず、HLAによる分散シミュレーションシステムアーキテクチャを図９に示す。HLAでは、シミュレーションシステム全体をフェデレーション（９０１）と呼び、分散実行される模擬処理などのプログラムをフェデレート（９０２）と呼ぶ。そして、シミュレーションの実行中に行われる、フェデレーション全体の実行制御や、フェデレートが他フェデレートに送信するメッセージ通信制御などの共通機能を、Run-Time Infrastructure（RTI）（９０３）という分散シミュレーション基盤が提供する。
【０００５】
HLAのTime Management Serviceは、RTIがフェデレートに対して提供する機能として規定されており、フェデレートの現在時刻を、他フェデレートから送られる時刻付きのTime Stamp Ordered（TSO）メッセージを受信する可能性に基づき制御する機能である。Time Management Serviceでは主に次の２つの機能が規定されている。
（１）フェデレートがRTIに対して要求する時刻進行要求およびRTIがフェデレートに許可する進行時刻許可の制御
（２）フェデレートがRTIに対して時刻進行要求を要求してから進行時刻許可を許可されるまでの間にRTIからそのフェデレートに配送される、他フェデレートからのTSOメッセージの配送制御
【０００６】
HLAでは、この（１）（２）の機能について、Time Step法、Event Base法、Optimistic法の３種類の時刻進行方法を、フェデレートが選択可能としている。なお、１つのフェデレーションの中で、異なる時刻進行方法を用いたフェデレートが混在していても良い。この３種類の時刻進行方法について図１０、図１１、図１２の例を用いて説明する。なお、HLAにおける時刻進行方法では、図１０、図１１、図１２で示されるパラメータの他にLookahead（フェデレートが現在時刻からTSOメッセージを送信しないことを保証する時間：例えば現在時刻が１０かつLookaheadが５の場合、１５未満の時刻のTSOメッセージを送信しないことを保証する）というパラメータを使用するが、図１０、図１１、図１２では簡単化のためにLookaheadが０の場合を例に説明する。
【０００７】
まず、図１０を用いてTime Step法による時刻進行の例を説明する。Time Step法は、フェデレートの時刻進行を模擬周期（ΔT）によって進める方式である。図１０のStep1において、フェデレート1およびフェデレート2の現在時刻はTiでありΔTは10である。フェデレート1は、RTIのインタフェースであるSend Interaction（SI）を用いて、Ti+5のTSOメッセージm1およびTi+15のTSOメッセージm2をフェデレート2に対して送信し、RTIのインタフェースであるTime Advance Request（TAR）を用いて、次周期時刻Ti+10へ時刻進行要求を行っている。このTARによる時刻進行要求により、フェデレート1はTi+10以下のTSOメッセージを送信しないことを保証する。次に、Step2において、フェデレート2が、TARを用いて、次周期時刻Ti+10へ時刻進行要求を行うと、フェデレート2もTi+10以下のTSOメッセージを送信しないことを保証することになるため、RTIは各フェデレートの状態を確認し、TARで時刻進行要求を行った各フェデレートの要求時刻以下のTSOメッセージが、フェデレート1が送信したm1以外に発生する可能性が無くなったことを判定する。この判定結果により、Step3において、RTIのインタフェースであるTime Advance Grant（TAG）により、フェデレート1、フェデレート2に対して、要求時刻であるTi+10への時刻進行許可が通知される。なお、フェデレート2に対しては、TAGが通知される前に、フェデレート1から送信されていたTSOメッセージのうち、TAGによって進行が許可されたTi+10以下のTi+5時刻のTSOメッセージであるm1がRTIのインタフェースであるReceive Interaction（RI）により配送される。TSOメッセージm2は、進行が許可されたTi+10より将来の時刻Ti+15のTSOメッセージのため、フェデレート2の時刻がTi+15以上になるまで配送が保留される。これは、現時点でTi+10より将来のTSOメッセージが発生する可能性が未だ残っており、Ti+10より将来の時刻の他フェデレートからのTSOメッセージが不確定な状態で模擬処理を行うことにより発生する、フェデレート間の矛盾を防ぐためである。以上のように、Time Step法では、フェデレートは時刻進行要求を行った要求時刻で時刻進行許可を得ると共に、許可された時刻よりも将来の時刻のTSOメッセージ受信が保留されることで、フェデレート間の矛盾発生を防止する。
【０００８】
次に、図１１を用いてEvent Base法の時刻進行の例を説明する。Event Base法は、フェデレートの時刻進行を、「他フェデレートの現在時刻／要求時刻」、「受信するTSOメッセージの最小時刻」、「要求時刻」の中の最も小さい時刻によって進める方式である。図１１のStep1、Step2は、フェデレート1およびフェデレート2が時刻進行要求を行う際に、RTIのインタフェースであるNext Message Request（NMR）以外は、図１０のStep1、Step2と同じである。NMRによる時刻進行要求により、フェデレート1、フェデレート2は、時刻進行要求中はTi+10以下のTSOメッセージを送信しないことを保証する。Step3においてRTIは各フェデレートの状態を確認し、フェデレート2はTSOメッセージm1の時刻であるTi+5以下の時刻のTSOメッセージを受信する可能性が無くなったことを判定し、フェデレート2の許可時刻を「受信するTSOメッセージの最小時刻」であるTi+5と判定する。また、フェデレート1は、フェデレート2の許可時刻がTi+5になったことにより、Ti+5以下の時刻のTSOメッセージを受信する可能性が無くなったことを判定し、許可時刻を「他フェデレートの現在時刻」であるTi+5と判定する。この判定結果により、TAGによりフェデレート1、フェデレート2に対して、Ti+5への時刻進行許可が通知される。なお、フェデレート2に対しては、TAGが通知される前に、フェデレート1から送信されていたTSOメッセージのうちm1がRIにより配送される。TSOメッセージm2は、進行が許可されたTi+5より将来の時刻Ti+15のTSOメッセージのため、フェデレート2の時刻がTi+15以上になるまで配送が保留される。以上のように、Event Base法では、フェデレートは「他フェデレートの現在時刻／要求時刻」、「受信するTSOメッセージの最小時刻」、「要求時刻」の中の最も小さい時刻で時刻進行許可を得ると共に、許可された時刻よりも将来の時刻のTSOメッセージ受信が保留されることで、フェデレート間の矛盾発生を防止する。
【０００９】
次に、図１２を用いてEvent Base法の拡張であるOptimistic法の時刻進行の例を説明する。Optimistic法は、Event Base法と同様に、フェデレートの時刻進行を、「他フェデレートの現在時刻／要求時刻」、「受信するTSOメッセージの最小時刻」、「要求時刻」の中の最も小さい時刻によって進める方式であるが、Event Base法と異なり、許可された時刻よりも将来の時刻のTSOメッセージ受信も行われる方式である。図１２のStep1、Step2は、フェデレート1およびフェデレート2が時刻進行要求を行う際に、RTIのインタフェースであるFlush Queue Request（FQR）を用いて時刻進行要求を行う以外は、図１０および図１１のStep1、Step2と同じである。FQRによる時刻進行要求により、フェデレート1、フェデレート2は時刻進行要求中はTi+10以下のTSOメッセージを送信しないことを保証する。Step3においてRTIは各フェデレートの状態を確認し、フェデレート2はm1のTi+5以下の時刻のTSOメッセージを受信する可能性が無くなったことを判定し、フェデレート2の許可時刻を「受信するTSOメッセージの最小時刻」であるTi+5と判定する。また、フェデレート1は、フェデレート2の許可時刻がTi+5になったことにより、Ti+5以下の時刻のTSOメッセージを受信する可能性が無くなったことを判定し、許可時刻を「他フェデレートの現在時刻」であるTi+5と判定する。この判定結果により、TAGによりフェデレート1、フェデレート2に対して、Ti+5への時刻進行許可が通知される。なお、フェデレート2に対しては、TAGが通知される前に、フェデレート1から送信されていたTSOメッセージ全てがRIにより配送される。TSOメッセージm2は、進行が許可されたTi+5より将来の時刻Ti+15のTSOメッセージであり、フェデレート2には他にもTi+5からTi+15までのTSOメッセージがこれから送信される可能性が残っているが、フェデレート2はTSOメッセージm2を入力情報としてTi+15の模擬を投機的に実行することが可能である。もし、TSOメッセージm2によるTi+15の模擬を投機的に実行した後で、他のTi+5からTi+15までのTSOメッセージを受信した場合には、投機的に実行した模擬処理と、その模擬処理によって他フェデレートに送信したTSOメッセージを取り消すことができる。以上のように、Optimistic法では、フェデレートは「他フェデレートの現在時刻／要求時刻」、「受信するTSOメッセージの最小時刻」、「要求時刻」の中の最も小さい時刻で時刻進行許可を得ると共に、許可された時刻よりも将来の時刻のTSOメッセージ受信により投機的な将来時刻の模擬を行うことが可能である。
【００１０】
次に、SoSシミュレータにおけるTime Step法、Event Base法、Event Base法の拡張であるOptimistic法の課題について述べる。Time Step法は、ΔTに基づき模擬処理が固定的に実行されるため、シミュレーションにおいて発生する事象の時間的な精度（以降、時間精度と略す。）がΔTの大きさに依存する。例えばネットワーク通信遅延のような比較的短時間で発生する事象の影響を、ある精度内でシミュレーションするためには、その精度に合わせてΔTを小さくする必要があるが、そのシミュレータで実行する全ての模擬処理がΔTに併せて実行されるため、無駄な処理が多くなりシミュレーション速度が低下する。このため、一般的にTime Step法は、詳細な時間精度が必要なシミュレータでは利用されない。
【００１１】
一方、Event Base法、Optimistic法は、シミュレータが受信するTSOメッセージの最小時刻によって模擬処理の時刻が決定されるため、そのシミュレータの時間精度がΔTで丸められることが無く、高い時間精度で模擬することが可能である。しかし、異なる時刻のTSOメッセージの受信頻度が高いと時刻の進捗が滞るためシミュレーション速度が低下する。このため、一般的にEvent Base法、Optimistic法は、ネットワークシミュレータのような高い時間精度が求められる単機能のシミュレータで利用されるが、複雑な事象を模擬するようなシミュレータではシミュレーション速度が低下するため利用されない。
【００１２】
そこで、シミュレーション速度を向上するため、シミュレータが模擬する内容に合わせてTime Step法、Event Base法、Optimistic法を使い分ける方法が検討されている。特許文献１では、シミュレータが模擬する登場人物（オブジェクト）がTime Step型Event Base型によって時刻進行方法を切り替えるシミュレーション実行方法が記載されている。図１３は、特許文献１に記載の方法によって構成された分散シミュレーションシステムの例である。図１３では、FED1〜FED4の4つのフェデレートがRTIによって制御されており、FED1、FED2、FED3はTime Step型オブジェクトを模擬し、FED3がTime Step型の他に、FED4が模擬する指揮所オブジェクトからの通信の受信によってEvent Base型の模擬を行うことを示している（但し、ここではEvent Base型のオブジェクトに対して、FQRによるOptimistic法の時刻進行を用いている）。すなわち、FED3はEvent Base型のオブジェクトに対して、Time Step法によるΔTよりも詳細な時間精度の模擬を行うために、TARによるTime Step法の時刻進行と、FQRによるOptimistic法の時刻進行を使い分ける。図１４は特許文献１のTARとFQRの使い分けについてのフェデレート及びRTIでの処理フローを示している。図１４のステップ７２１において、フェデレート３は、自分が模擬するオブジェクトにEvent Base型のオブジェクトが存在するかを判定し真の場合、ステップ７２２においてフェデレート３はFQRで時刻進行要求を行う。FQRによる時刻進行の後、ステップ７２３でフェデレート３が時刻進行許可を得た際には、許可時刻より将来のTSOメッセージを受信することが可能なため、ステップ７２４にてフェデレート３はその全ての受信TSOメッセージを管理し、ステップ７２５で対象とする全オブジェクトからTSOメッセージを受信したことを確認できた場合、ステップ７２６でその受信TSOメッセージの最も小さい時刻を次の要求時刻としてTime Step法で時刻進行を行うTime Step型オブジェクトに変更する。この処理はループ処理であり、次の実行ではこのオブジェクトはTime Step型に変更されるため、ステップ７２８においてTARで時刻進行要求が行われる。その後、ステップ７３０において状態に応じてオブジェクトをEvent Base型に変更する。このように、フェデレートにEvent Base法により時刻進行を行うオブジェクトが含まれる場合、Optimistic法によって将来時刻のTSOメッセージを受信した場合で、かつ、そのオブジェクトに対するTSOメッセージを対象とする全オブジェクトから受信したことが判明した時にTime Step型によって時刻進行することで、シミュレーション速度を向上することができる。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】IEEE １５１６.１-２０１０ - Standard for Modeling and Simulation High Level Architecture (HLA) - Federate Interface Specification
【特許文献１】特許第５４１４３３２号
【発明の概要】
【発明が解決しようとする課題】
【００１４】
背景技術で説明したように従来の分散シミュレーション装置では、フェデレーションにEvent Base型オブジェクトに対してOptimistic法またはTime Step法で時刻進行を行うフェデレートが１つだけ存在する場合は、フェデレートの時刻進行法をEvent Base法からTime Step法に変更することでシミュレーション速度を上げることができる。
【００１５】
しかし、フェデレーションにEvent Base法の拡張であるOptimistic法またはTime Step法の切り替え型で時刻進行を行うフェデレートが複数存在する場合、Optimistic法またはTime Step法で時刻進行を行う１つのフェデレートの許可時刻は、Optimistic法またはTime Step法で時刻進行を行う他のフェデレートの現在時刻／要求時刻に応じた時刻に制約される。Optimistic法によるフェデレートの許可時刻は、そのフェデレートに対して許可時刻以下のTSOメッセージを受信する可能性が無いことを保証する時刻であるが、それよりも将来時刻のTSOメッセージが発生するかしないかは確定されない。そのため、図１４のステップ７２５で対象とする全オブジェクトからTSOメッセージを受信したことを確認できる状態とならず、ステップ７２６のタイムステップ型オブジェクトへの変更が行われない。その結果、ステップ７２８以降のTime Step法の処理を実施する状態が発生せず、Time Step法への変更によりシミュレーション速度を向上できる状態を実現できない。このように、従来の分散シミュレーション装置では、フェデレーションにTime Step法とEvent Base法の時間進行を切り替えるフェデレートが複数存在する環境において、各フェデレートの時間進行をEvent Base法からTime Step法へ円滑に切り替えることができず、シミュレーション速度を向上できない課題がある。
【００１６】
本発明はフェデレーションにフェデレートが複数存在する環境において、複数のフェデレートがTime Step法とEvent Base法との時間進行を円滑に切り替えることができる分散シミュレーションシステムにおける時刻進行制御装置及びシミュレータ、及び分散シミュレーションシステムを得ることを目的とする。
【課題を解決するための手段】
【００１７】
この発明に係る時刻進行制御装置は、複数のシミュレータが論理時刻に基づき連携する分散シミュレーションシステムにおける一のシミュレータに含まれる時刻進行制御装置であって、自シミュレータ及び他のシミュレータの通信開始メッセージを検出する通信開始検出部と、前記通信開始検出部で検出された通信開始メッセージを登録するメッセージリストと、前記メッセージリストに前記通信開始メッセージが登録されている場合に、Event Base法を時刻進行方法として選択し、前記メッセージリストに前記通信開始メッセージが登録されていない場合に、Time Step法を時刻進行方法として選択する進行方法選択部と、前記通信開始メッセージの応答である通信結果メッセージを受信した場合に、当該通信結果メッセージに対応した通信開始メッセージを前記メッセージリストから削除する進行制御部と、を備えたことを特徴とする。
【発明の効果】
【００１８】
この発明の時刻進行制御装置によれば、Time Step法とEvent Base法との間で時間進行を切り替えるフェデレートが複数存在する場合でも自シミュレータの時刻進行方法をTime Step法とEvent Base法との間で円滑に切り替えることができる。
【図面の簡単な説明】
【００１９】
【図１】この発明の実施の形態１に係る分散シミュレーションシステムの基本構成図。
【図２】この発明の実施の形態１に係るネットワークシミュレータとサブシステムシミュレータ間のメッセージ通信例。
【図３】この発明の実施の形態１に係るSoSシミュレータの構成図。
【図４】この発明の実施の形態１においてサブシステムシミュレータ３００が時刻進行方法を切り替える動作を示す処理フロー。
【図５】この発明の実施の形態１においてサブシステムシミュレータ３００が時刻進行方法を切り替える動作を示す処理フローの一部。
【図６】この発明の実施の形態１においてサブシステムシミュレータ３００が時刻進行方法を切り替える動作を示す処理フローの一部。
【図７】この発明の実施の形態２に係るネットワークシミュレータとサブシステムシミュレータ間のメッセージ通信例。
【図８】この発明の実施の形態２に係るSoSシミュレータの構成図。
【図９】従来技術における分散シミュレーションシステムアーキテクチャの基本構成図。
【図１０】従来技術におけるTime Step法による時刻進行方法。
【図１１】従来技術におけるEvent Base法による時刻進行方法。
【図１２】従来技術におけるOptimistic法による時刻進行方法。
【図１３】従来技術によって構成された分散シミュレーションシステムの例。
【図１４】従来技術におけるフェデレート及びRTIでの処理フロー。
【発明を実施するための最良の形態】
【００２０】
以下、この発明の実施の形態について、図面を参照しながら詳細に説明する。
実施の形態１．
図１に、この発明の実施の形態１に係る分散シミュレーションシステムであるSoSシミュレータ１０１の構成を示す。ここで、分散シミュレーションシステムは複数のシミュレータが論理時刻に基づき連携する分散シミュレーションシステムである。また、SoSシミュレータ１０１は、それぞれ１つ以上のネットワークシミュレータとサブシステムシミュレータをフェデレートとして、全体をHLAに基づくフェデレーションとして構成する。ここで、ネットワークシミュレータは、時間精度を考慮してEvent Base法により時刻進行を行い、サブシステムシミュレータは、ネットワークシミュレータによって模擬された通信遅延時間等の比較的短時間の事象を入力とする場合にのみEvent Base法により時刻進行を行い、それ以外の場合はTime Step法によって時刻進行を行う。
【００２１】
図２に、説明の簡単化のために時刻進行要求および時刻進行許可の状況を省いた、ネットワークシミュレータとサブシステムシミュレータ間のメッセージ通信の例を示す。図２のStep1において、まずサブシステムシミュレータの時刻Tiにおいてネットワーク通信のきっかけが模擬され、その模擬の結果がネットワークシミュレータに対するTSOメッセージでありメッセージの通信開始を示す通信開始メッセージとして送信される。TSOメッセージの時刻は、フェデレートの時刻進行とTSOメッセージの配送順序の一貫性を保つために、現在時刻より将来の時刻を設定する必要がある。また、ネットワークシミュレータが通信開始メッセージを受信した後に通信遅延時間を計算するため、通信開始メッセージの時刻には、現在時刻にネットワークシミュレータが計算する通信遅延時間よりも小さい時間を加算した時刻を設定しなければならない。そこで、通信開始メッセージの時刻として、現在時刻にHLAで規定されているepsilon（論理時間の最小値であり０では無い値）を加算した時刻を使用する。図２の例では、正の整数値をとり、epsilonの値「１」を使用してTi+1時刻のメッセージとして通信開始メッセージを送信する。ネットワークシミュレータはEvent Base法により時刻進行を行うため、通信開始メッセージを受信したTi+1時刻が現在時刻となる。次にStep2において、Ti+1時刻におけるネットワークシミュレータの模擬が行われ、この例では通信成否判定の結果として通信成功で通信遅延時間Lが計算される。最後にStep3において、ネットワークシミュレータはTi+1時刻の模擬結果として、TSOメッセージである通信結果メッセージを、サブシステムシミュレータに対して送信する。この際、通信結果メッセージの時刻は、ネットワーク通信のきっかけが模擬されたTiに、通信遅延時間であるLを加算した受信時刻であるTi+Lが設定される。なお、通信成否判定の結果として通信失敗の場合は通信遅延時間の計算は必要ないため、通信結果の時刻としては例えばTi+2時刻のように即時的な時刻が設定される。図２は、サブシステムシミュレータとネットワークシミュレータが、それぞれ１つのケースを説明したが、複数の場合、通信開始メッセージと通信結果メッセージは、全てのシミュレータに対して送信されるものとする。
【００２２】
ここで、サブシステムシミュレータは、ネットワークシミュレータからの通信結果メッセージの時刻をEvent Base法で許可時刻として得られれば良い。サブシステムシミュレータは通常はTime Step法で時刻進行を行い、ネットワークシミュレータによる通信結果メッセージ発生のきっかけとなる通信開始メッセージを検出した場合のみ、Event Base法に時刻進行方法を切り替えるようにすれば、必要な場合のみEvent Base法に切り替えることで、全体のシミュレーション速度を改善することができる。また、ネットワークシミュレータによる通信結果メッセージ発生のきっかけとなる通信開始メッセージを検出した場合のみ、Event Base法に時刻進行方法を切り替えるようにすれば、Time Step法とEvent Base法の切り替えを円滑に行うことができる。なお、分散シミュレーションシステム内にTime Step法で動作するシミュレータが別に存在する場合にも、この実施の形態１に記載の発明は同様に適用可能である。
【００２３】
図３は、本発明による分散シミュレーション装置の概要を示したものである。図において、サブシステムシミュレータ３００は、そのサブシステムシミュレータ３００において模擬対象物体または事象を模擬する模擬処理部３０１と、状況に応じて時刻進行方法を切り替える時刻進行制御装置３０２と、RTIに対するインタフェース処理を行うRTIインタフェース処理部３０３で構成される。また、サブシステムシミュレータ３００の時刻進行制御装置３０２は、通信開始メッセージを検出する通信開始検出部３０４と、通信開始検出部３０４が検出した通信開始メッセージを保存するメッセージリスト３０５と、メッセージリスト３０５の内容に応じて時刻進行方法を選択する進行方法選択部３０６と、時刻進行を制御する進行制御部３０７で構成される。
【００２４】
次に動作について説明する。図４、５、６はサブシステムシミュレータ３００が状況に応じて時刻進行方法を切り替える動作を示した処理フローである。図４、５、６では、それぞれフローチャートの最初の部分、最初の部分に続く部分、その次に続く部分を記載している。まず、図４のステップ４０１にて、サブシステムシミュレータ３００の模擬処理部３０１が現在時刻であるTiの模擬を行う。次に、ステップ４０２にて、通信開始検出部３０４において自シミュレータの模擬処理部３０１及び他シミュレータが送信した通信開始メッセージを検出し、メッセージリスト３０５へ登録する。他シミュレータが送信した通信開始メッセージの検出方法については、実施の形態２で説明する。次にステップ４０３にて、進行方法選択部３０６はメッセージリスト３０５に通信開始メッセージが登録されているか否かの判定を行う。
【００２５】
メッセージリスト３０５に通信開始メッセージが登録されていない（ステップ４０３の判定結果がNo）場合、ステップ４０４にて進行方法選択部３０６が自シミュレータの時刻進行方法としてTime Step法を選択する。また、ステップ４０５にてRTIインタフェース部３０３がTARによりTi+ΔTまで時刻進行要求を行い、ステップ４０６にてRTIインタフェース部３０３がTAGによりTi+ΔTへの時刻進行許可を受信する。その後、４２０にて模擬処理部３０１が次周期時刻のTi+ΔTの模擬を行う。このように、ステップ４０３の判定結果がNoの場合、Time Step法で時刻進行を行う。
【００２６】
メッセージリスト３０５に通信開始メッセージが登録されている（ステップ４０３の判定結果がYes）場合、ステップ４０７にて進行方法選択部３０６が自シミュレータの時刻進行方法としてEvent Base法を選択し、図５のステップ４０８にてRTIインタフェース部３０３がNMRによりTi+ΔTまで時刻進行要求を行い、ステップ４０９にてRTIインタフェース部３０３がTAGによりTjへの時刻進行許可を受信する。ここで、TjはEvent Base法による時刻進行許可時刻であるため、Tj≧TiかつTj ≦ Ti+ΔTである。
【００２７】
次に、図５のステップ４１０にて、RTIインタフェース部３０３がステップ４０９でTAGを受信する前に、RTIから通信結果メッセージが配送されたかどうかの判定が進行制御部３０７で行われる。ステップ４１０の判定結果がNoの場合、ステップ４１１にてRTIインタフェース部３０３におけるTj = Ti+ΔTが真か否かの判定が進行制御部３０７で行われる。ステップ４１１の判定結果がYesの場合、ネットワークシミュレータからの通信結果メッセージは、自シミュレータの次周期時刻であるTi+ΔTよりも将来の時刻に送信されると判断されるため、ステップ４２０にて進行制御部３０７が模擬処理部３０１に指示し、模擬処理部３０１が次周期時刻のTi+ΔTの模擬を行う。一方、ステップ４１１の判定結果がNoの場合、ネットワークシミュレータからの通信結果メッセージは、自シミュレータの次周期時刻であるTi+ΔTよりも小さい時刻に送信される可能性が残っていると判断されるため、再びステップ４０８にて進行制御部３０７がRTIインタフェース部３０３に指示し、RTIインタフェース部３０３がNMRによりTi+ΔTまで時刻進行要求を行う。
【００２８】
ステップ４１０の判定結果がYesの場合、まずステップ４１２にて、RTIインタフェース部３０３が、受信した通信結果メッセージの基となった通信開始メッセージを進行制御部３０７がメッセージリスト３０５から削除する。次に、ステップ４１３にて、RTIインタフェース部３０３においてTj = Ti+ΔTが真か否かの判定が進行制御部３０７で行われる。ステップ４１３の判定結果がYesの場合、ネットワークシミュレータからの通信結果メッセージは、自シミュレータの次周期時刻であるTi+ΔTと同時刻に送信されたと判断されるため、ステップ４２０にて進行制御部３０７が模擬処理部３０１に指示し、模擬処理部３０１が次周期時刻のTi+ΔTの模擬を行う。ステップ４１３の判定結果がNoの場合、まずステップ４１４にて進行制御部３０７が模擬処理部３０１に指示し、模擬処理部３０１が次時刻となったTjの模擬を行い、ステップ４１５にて通信開始検出３０４において自シミュレータの模擬処理部３０１及び他シミュレータが送信した通信開始メッセージを検出し、メッセージリスト３０５へ登録する。ただし、ステップ４１５で通信開始メッセージが検出されない場合、新たな通信開始メッセージはメッセージリスト３０５に登録されない。次に、引き続きEvent Base法で時刻進行を行うかどうかを判断するために、ステップ４１６にて、進行方法選択部３０６はメッセージリスト３０５に通信開始メッセージが登録されているかどうかの判定が行う。
【００２９】
ステップ４１６の判定結果がYesの場合、自シミュレータは未だネットワークシミュレータからの通信結果メッセージを受信する可能性が残っていると判断されるため、再びステップ４０８にて進行方法選択部３０６の指示に従いRTIインタフェース部３０３がNMRによりTi+ΔTまで時刻進行要求を行う。
【００３０】
ステップ４１６の判定結果がNoの場合、既にネットワークシミュレータに対して送信された通信開始メッセージに基づく通信結果メッセージは全て受信されており、次周期時刻であるTi+ΔTより小さな時刻の通信結果メッセージを受信する可能性が無くなったと判断される。そこで、図６のステップ４１７にて、進行方法選択部３０６が自シミュレータの時刻進行方法としてTime Step法を選択し、ステップ４１８にて進行方法選択部３０６の指示に従いRTIインタフェース部３０３がTARによりTi+ΔTまで時刻進行要求を行い、ステップ４１９にてRTIインタフェース部３０３がTAGによりTi+ΔTへの時刻進行許可を受信する。その後、ステップ４２０にて模擬処理部３０１が次周期時刻のTi+ΔTの模擬を行う。
【００３１】
以上のように、この発明の実施の形態１では、サブシステムシミュレータ３００の時刻進行制御装置３０２の通信開始検出部３０４が、自サブシステムシミュレータおよび他サブシステムシミュレータの模擬処理部３０１が模擬した通信開始メッセージを検出し、通信開始メッセージを検出した場合は進行方法選択部３０６が時刻進行方法としてEvent Base法を選択し、検出した通信開始メッセージに対応する通信結果メッセージを全て受信するまでEvent Base法で時刻進行を行い、検出した通信開始メッセージに対応する通信結果メッセージを全て受信した後は、進行方法選択部３０６が時刻進行方法としてTime Step法を選択する。以上の動作により、詳細な時間的精度の模擬が必要な通信の受信イベントの模擬はEvent Base法により詳細に実行することができ、それ以外の模擬はTime Step法による時間周期で実行することが可能である。なお、Event Base法とTime Step法の切り替えは、検出した通信開始メッセージに応じて実行するため、従来技術に挙げた特許文献１の方式と異なり、他のフェデレートの状態に基づかないため、Time Step法とEvent Base法との間で時間進行を切り替えるフェデレートが複数存在する場合でも自シミュレータの時刻進行方法をTime Step法とEvent Base法との間で円滑に切り替えることができる。
【００３２】
すなわち、この発明の実施の形態１における時刻進行制御装置３０２は、複数のシミュレータが論理時刻に基づき連携する分散シミュレーションシステムにおける一のシミュレータであるサブシステムシミュレータ３００に含まれる時刻進行制御装置３０２であって、Time Step法により時刻進行を行っている自シミュレータ及び他のシミュレータの通信開始メッセージを検出する通信開始検出部３０４と、通信開始検出部３０４で検出された通信開始メッセージを登録するメッセージリスト３０５と、メッセージリスト３０５に通信開始メッセージが登録されているか否かに基づき、Time Step法またはEvent Base法のいずれかを時刻進行方法として選択する進行方法選択部３０６と、通信開始メッセージの応答である通信結果メッセージを受信した場合に、その通信結果メッセージに対応した通信開始メッセージをメッセージリスト３０５から削除する進行制御部３０７と、を備えたことを特徴とする。このような構成により、Event Base法が必要となる通信開始メッセージが検出される場合のみ、自シミュレータの時刻進行方法をEvent Base法に切り替えることができる。また、従来技術に挙げた特許文献１の方式と異なり、他のフェデレートの状態に基づかないため、Time Step法とEvent Base法との間で時間進行を切り替えるフェデレートが複数存在する場合でも動作することが可能である。
【００３３】
また、この発明の実施の形態１における時刻進行制御装置３０２の進行方法選択部３０６はメッセージリスト３０５に通信開始メッセージが登録されている場合に、Event Base法を時刻進行方法として選択することを特徴とする。時刻進行制御装置３０２の進行方法選択部３０６は、メッセージリストに通信開始メッセージが登録されていない場合に、Time Step法を時刻進行方法として選択することを特徴とする。このような構成により、Event Base法が必要となる通信開始メッセージが送信され、通信開始メッセージに対する処理が終了していない区間のみで、Event Base法を用いることが可能となる。
【００３４】
また、この発明の実施の形態１におけるシミュレータは、模擬対象物体または事象を模擬する模擬処理部３０１と、分散シミュレーション基盤であるRTIとのインタフェース処理を行うインターフェース処理部３０３と、時刻進行制御装置３０２と、を備えたことを特徴とする。このような構成により、複数のシミュレータが論理時刻に基づき連携する分散シミュレーションシステムにおいて、Time Step法とEvent Base法を適宜切り替えて用いることができるシミュレータを得ることができる。
【００３５】
また、この発明の実施の形態１における分散シミュレーションシステムは、時刻進行をTime Step法またはEvent Base法の間で切り替えるシミュレータであるサブシステムシミュレータ３００と、Event Base法により時刻進行を行うシミュレータであるネットワークシステムシミュレータと、を含むことを特徴とする。このような構成により、複数のシミュレータが論理時刻に基づき連携する分散シミュレーションシステムにおいて、複数のシミュレータがEvent Base法を時刻進行に用いる場合にも、Time Step法とEvent Base法を円滑に切り替えて用いることができる分散シミュレーションシステムを得ることができる。
【００３６】
実施の形態２．
実施の形態１では、自シミュレータが送信した通信開始メッセージの検出方法について説明したのに対し、実施の形態２では他シミュレータがネットワークシミュレータに対して送信した通信開始メッセージの検出方法について説明する。
【００３７】
実施の形態２は、サブシステムシミュレータが論理時刻による配送制御を受けないメッセージであるReceived Ordered（RO）メッセージによる通信開始通知メッセージを用いて通信開始メッセージの検出を行う方法について示す。図７に実施の形態２におけるネットワークシミュレータとサブシステムシミュレータ間のメッセージ通信の例を示す。また、図８に本発明の実施の形態２による分散シミュレーション装置の概要を示す。図７の(１)は、通常の通信開始メッセージの配送の例である。他シミュレータであるサブシステムシミュレータ２が現在時刻Tiにおいてネットワーク通信のきっかけを模擬し、その模擬の結果としてTi+1の通信開始メッセージをネットワークシミュレータとサブシステムシミュレータ１に送信する。サブシステムシミュレータ１の現在時刻がTiの場合、通信開始メッセージの時刻が将来の時刻のため、サブシステムシミュレータ１が通信開始メッセージの時刻よりも将来の時刻に時刻進行を行うまで通信開始メッセージの配送は保留される。そのため、図７の(１)のような通常の通信開始メッセージの配送を、サブシステムシミュレータ１の通信開始検出部３０４は時刻進行を行う前に検知することができない。
【００３８】
そこで、本実施の形態では、フェデレートの現在時刻に関わらずに配送が行われるROメッセージを利用して通信開始メッセージが送信されたことを通知する方式を考案した。図７の(２)は、ROメッセージによって通信開始メッセージが送信されたことを通知する処理の例である。まずサブシステムシミュレータ２が現在時刻Tiにおいてネットワーク通信のきっかけを模擬し、その結果としてTi+1の通信開始メッセージをネットワークシミュレータおよびサブシステムシミュレータ１に送信すると共に、通信開始メッセージを送信したことを通知する通信開始通知メッセージをROメッセージとして送信する。通信開始通知メッセージはROメッセージのため、サブシステムシミュレータ１は現在時刻に依らず当メッセージを受信することが可能であり、RTIによって配送される。サブシステムシミュレータ１の通信開始検出部３０４は、通信開始通知メッセージを受信することにより、通信開始メッセージが送信されたことを検出する。なお、検出された通信開始メッセージは、実施の形態１の場合と同様に、その通信開始メッセージに基づく通信結果メッセージがEvent Base法による時刻進行で受信されるまでメッセージリスト３０５に登録される。また、メッセージリスト３０５に登録された通信開始メッセージが無くなった後、サブシステムシミュレータ１はEvent Base法からTime Step法に時刻進行方法を切り替える（図５のステップ４１５、ステップ４１６の処理）。そのため、図７の(２)の状況では、サブシステムシミュレータ１は、現在時刻であるTiから自身の次周期時刻であるTi+ΔTまでの間の時刻の通信開始メッセージを全て検出しなければならない。そこで、サブシステムシミュレータ２が、Ti+ΔTに時刻進行要求を行った際に、ROメッセージの時刻進行要求通知メッセージをサブシステムシミュレータ１に送信することで、サブシステムシミュレータ２がTi+ΔTまで新たなメッセージ送信を行わないことをサブシステムシミュレータ１に通知する。サブシステムシミュレータ１は、時刻進行要求通知メッセージの受信により、これ以上Ti+ΔTまでの時刻の通信開始メッセージが発生しないことを判断する。
【００３９】
以上のように、この発明の実施の形態２では、サブシステムシミュレータの時刻進行制御装置３０２の通信開始検出部３０４が、他サブシステムシミュレータの模擬処理部３０１が模擬した通信開始メッセージを検出する方法として、ROメッセージによる通信開始通知メッセージを用いる方法と、現在時刻+ΔTまでの通信開始メッセージを全て検出したことを判断する方法として、ROメッセージによる時刻進行要求通知メッセージを用いる方法を示した。このような方法は、サブシステムシミュレータ３００がROメッセージの送信を行うメッセージ送信部３０８を備え、通信開始検出部３０４がROメッセージを受信する機能を備えることで可能となる。以上の動作により、通信開始検出部３０４は、現在時刻より将来時刻のTSOメッセージである通信開始メッセージの検出と、現在時刻+ΔTまでの通信開始メッセージを全て検出したことを判断することが可能である。また、実施の形態１と実施の形態２に記載の構成をともに備えたサブシステムシミュレータ３００を用いることで、自シミュレータと他シミュレータの通信開始メッセージをともに検出することが可能となる。
【００４０】
このように、この発明の実施の形態２における時刻進行制御装置３０２は、自シミュレータの通信開始メッセージを論理時刻に依らない配送形式で他のシミュレータに送信するメッセージ送信部３０８を備えたことを特徴とする。このような構成により、論理時刻に依らずに通信開始メッセージを他のシミュレータに通知することができ、複数のシミュレータがTime Step法とEvent Base法の間で進行時刻の切り替えを行う場合にも各シミュレータが円滑にTime Step法とEvent Base法の間で進行時刻の切り替えを行うことが可能となる。
【００４１】
また、この発明の実施の形態２における時刻進行制御装置３０２は、他のシミュレータから論理時刻に依らない配送形式で送信された通信開始メッセージを受信するメッセージ受信部を備えたことを特徴とする。この構成により、論理時刻に依らずに通信開始メッセージを他のシミュレータから受信することができ、複数のシミュレータがTime Step法とEvent Base法の間で進行時刻の切り替えを行う場合にも各シミュレータが円滑にTime Step法とEvent Base法の間で進行時刻の切り替えを行うことが可能となる。
【００４２】
また、この論理時刻に依らない配送形式は、Received Orderedメッセージによる時刻進行通知メッセージであることを特徴とする。この構成により、論理時刻に依らずに通信開始メッセージを他のシミュレータに通知することができる。
【００４３】
実施の形態３．
実施の形態２では、ROメッセージを用いて通信開始メッセージの検出を行う方法を説明したのに対し、実施の形態３では市販品で改造することができないシミュレータにも適用可能なManagement Object Model（MOM）機能を利用して通信開始メッセージの検出を行う方法を説明する。
【００４４】
実施の形態２で説明したROメッセージを用いて通信開始メッセージの検出を行う方法は、サブシステムシミュレータに、シミュレータの実行制御用のメッセージ送信機能を付加する形になるため、例えば市販品で改造することができないシミュレータに適用することができない。そのようなシミュレータでも通信開始メッセージの検出を可能とする方法として、HLA規約においてRTIの機能として規定されているManagement Object Model（MOM）機能を利用した方法を説明する。
【００４５】
MOM機能は、RTIによるフェデレーションの監視と、その監視情報をフェデレートに通知するための機能である。MOM機能として定義されているMOM Interaction ClassのHLAobjectRoot. HLAmanager. HLAfederate. HLAreport. HLAreportServiceInvocation（中間の「.」は、右側のInteraction Classが左側のInteraction Classを継承していることを表す。以降、HLAreportServiceInvocationと略す。）は、監視対象となるフェデレートがRTIのインタフェースを利用した際に、そのインタフェースと引数の情報を、ROメッセージとして監視フェデレートにRIによって配送する機能である。サブシステムシミュレータは、HLAreportServiceInvocationを購読することにより、他のフェデレートがRTIに対して呼び出したり、またRTIから呼び出されるインタフェースを実行状況を知ることができるため、通信開始検出部３０４は他サブシステムシミュレータが送信した通信開始メッセージ送信や時刻進行要求を監視することで、現在時刻より詳細時刻のTSOメッセージである通信開始メッセージの検出と、現在時刻+ΔTへの時刻進行要求による、現在時刻+ΔTまでの全ての通信開始メッセージの検出の判断を行うことが可能でなる。
【００４６】
しかし、MOM機能のHLAreportServiceInvocationは、監視したいフェデレートおよび監視したいHLA機能を限定することは可能だが、監視対象フェデレートが利用したRTIのインタフェースの情報を大量に送信するため、フェデレーション監視専用でない模擬処理を行うフェデレートがHLAreportServiceInvocationを購読すると、フェデレートの処理負荷が高まり、模擬処理の実行速度が低下する弊害がある。そのため、MOM機能を利用した通信開始メッセージ検出は改造することができないシミュレータのみを対象に利用し、その他のシミュレータに対しては通信開始通知メッセージを用いて通信開始メッセージ検出を行うように、両方の方式を併用する方式も考えられる。
【００４７】
この発明の実施の形態３におけるシミュレータは、他のシミュレータの通信開始メッセージの検出を、High Level ArchitectureのManagement Object Model機能を利用して行うことを特徴とする。このような構成により、市販品で改造することができないシミュレータにおいても他のシミュレータの通信開始メッセージの検出を行うことが可能となる。
【００４８】
本発明の実施の形態１から３のいかなる組み合わせも本発明に含まれる。
【符号の説明】
【００４９】
１０１：SoSシミュレータ、３００：サブシステムシミュレータ、３０１：模擬処理部、３０２：時刻進行制御装置、３０３：インタフェース処理部、３０４：通信開始検出部、３０５：メッセージリスト、３０６：進行方法選択部、３０８：メッセージ送信部、９０１：フェデレーション、９０２：フェデレート、９０３：Run-Time Infrastructure
【図１】
0006337760.tif 000002
【図２】
0006337760.tif 000003
【図３】
0006337760.tif 000004
【図４】
0006337760.tif 000005
【図５】
0006337760.tif 000006
【図６】
0006337760.tif 000007
【図７】
0006337760.tif 000008
【図８】
0006337760.tif 000009
【図９】
0006337760.tif 000010
【図１０】
0006337760.tif 000011
【図１１】
0006337760.tif 000012
【図１２】
0006337760.tif 000013
【図１３】
0006337760.tif 000014
【図１４】
0006337760.tif 000015