(57)【要約】【課題】複数のシミュレータが、互いにメッセージを送受し、連携しながらシミュレーションを行う分散シミュレーションシステムにおいて、HLAに基づくシステムでは、当該メッセージ送受に伴い、不要な摸擬が発生し、実行性能の低下に繋がる。【解決手段】HLA規格に基づく分散シミュレーションでは、他のシミュレータが発行するメッセージに関して、将来の論理時刻（タイムスタンプ）付きメッセージを先読みできるオプティミスティック方式が実装可能であり、本機能を利用することによって、先読みしたメッセージのタイムスタンプ時刻に対して時刻進行することにより、不必要な模擬を省く。【選択図】図６
2010244459.tif 000002
【特許請求の範囲】
【請求項１】
HLA（High Level Architecture, IEEE1516）に基づき各シミュレーションを実行する分散シミュレーションシステムでの各シミュレータ（フェデレート）において、各フェデレートは自己のフェデレート上に存在するオブジェクトが、自律的に次の摸擬時刻を設定して時刻進行する自律型オブジェクトか、他のオブジェクトからのメッセージを受信するタイミングがトリガとなって時刻進行する他律型オブジェクトかを判定し、両方のオブジェクトが存在する場合は、当該フェデレートは、HLAが提供するイベントベース方式により時刻進行することを特徴とするシミュレーション実行方法。
【請求項２】
各フェデレートは自己のフェデレート上に存在するオブジェクトが、自律的に次の摸擬時刻を設定して時刻進行する自律型オブジェクトか、他のオブジェクトからのメッセージを受信するタイミングがトリガとなって時刻進行する他律型オブジェクトかを判定し、フェデレート上に存在するオブジェクト全てが、自律型オブジェクトの場合は、当該フェデレートは、HLAが提供するタイムステップ方式により時刻進行することを特徴とする請求項１記載のシミュレーション実行方法。
【請求項３】
HLAに基づき各シミュレーションを実行する分散シミュレーションシステムでの各フェデレートにおいて、自律的に次の摸擬時刻を設定して時刻進行する自律型オブジェクトと、他のオブジェクトからのメッセージを受信するタイミングがトリガとなって時刻進行する他律型オブジェクトが、同一のフェデレート上に存在する場合、当該フェデレートは未来時刻のタイムスタンプ付きメッセージを受信することが可能なオプティミスティック方式により時刻進行を行い、当該他律型オブジェクトに対応する未来時刻のタイムスタンプ付きメッセージを受信した場合で、かつその未来時刻までに他のフェデレートから当該他律型オブジェクトに対応するメッセージを受信しないことが判明した時は、当該未来時刻に対して、HLAが提供するタイムステップ方式により時刻進行することを特徴とするシミュレーション実行方法。
【請求項４】
各フェデレートの処理負荷を事前に算出し、他律型オブジェクトに対してメッセージを発行するフェデレートは、他のフェデレートよりも計算負荷の小さいプロセッサに割り付けることを特徴とする請求項１〜３の何れか１項に記載のシミュレーション実行方法。
【請求項５】
シミュレーション実行中に、各プロセッサの処理負荷状況に応じて、他律型オブジェクトに対してメッセージを発行するフェデレートは、他のフェデレートよりも計算負荷状況の小さいプロセッサに割り付けることを特徴とする請求項４記載のシミュレーション実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の計算機を利用して、大規模シミュレーションを実現するための並列・分散シミュレーション技術に関するものである。
【背景技術】
【０００２】
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つである、Time Managementであり、本サービスは、各FEDの時刻進行を調整及び制御するものである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2002-312712号公報「分散シミュレーション制御方法」
【特許文献２】特開2008-204008号公報「論理プロセッサ」
【非特許文献】
【０００７】
【非特許文献１】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.
【非特許文献３】尾崎他, “大規模移動体シミュレーションを対象とした動的タイムステップ制御方式 〜通信モデル及び分散化の実現検討〜,” FIT2007（第6回情報科学技術フォーラム）, B-004, pp.83-85.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来は、実装の容易性や、要求される摸擬精度が高いものでなかったことから、タイムステップ法と称する実装が主流であった。しかし、近年、ネットワーク系を対象としたアプリケーションの重要度が増すとともに、摸擬の品質が重要視されるようになり、高い摸擬精度でシミュレーションを実現することが求められている。
また、HLAに基づく分散シミュレーションシステムでは、FED数の増加に伴い、FED間のデータ送受や時刻管理のためのオーバーヘッド時間が増大するため、大規模数のオブジェクトが登場するアプリケーションを対象とする場合においても、FED数を適度な数に抑える必要がある。即ち、複数のオブジェクトを１つのFEDにマッピングする必要がある。
【０００９】
オブジェクトの摸擬時刻進行方法には、２通りの方法がある。１つは自律的に次の摸擬時刻を設定して時刻進行するタイムステップ法であり、もう１つは他のオブジェクトからのメッセージを受信するタイミングがトリガとなって時刻進行するイベントベース法である。これらの両時刻進行方法は、そのオブジェクト本来の性質に基づいて決まる場合や、その時々の状況に応じて使い分ける場合がある。
このように、時刻進行方法が異なるオブジェクトが同一のFED上に存在する場合において、因果関係の矛盾なく、高い摸擬精度で、効率的に実行するために当該FEDの時刻進行方法を確立する必要がある。
【００１０】
なお、他のオブジェクトからのメッセージを受信するタイミングがトリガとなって時刻進行するイベントベース法は、具体的にはオブジェクト間で通信を高精度に実施する場合等に用いることとなる。更に、FED間で発生する通信の摸擬を高精度に実現する場合は、HLA規格に基づくイベントベース方式で時刻進行を行う実装法を採用する必要がある。しかし、HLAの規格では、１つのFED上に、タイムステップ方式で時刻進行すべきオブジェクトと、通信のようなイベントベース方式で時刻進行すべきオブジェクトが混在している場合でも、当該FEDで設定した１つの時刻進行方式に、当該FED上のオブジェクトは従わざるを得ないという課題がある。即ち、タイムステップ方式で時刻進行すべきオブジェクトも、そのFEDがイベントベース方式で時刻進行要求を発行した場合では、当該オブジェクトもイベントベース方式で動作することとなってしまう。タイムステップ方式で時刻進行すべきオブジェクトと、イベントベース方式で時刻進行すべきオブジェクトが同一のFED上に存在した場合、両者の動作を満足するためには、当該FEDはイベントベース方式で時刻進行をせざるを得ない。
【００１１】
従って、本来、タイムステップ方式で時刻進行すべきオブジェクトも、イベントベース方式で動作することとなるため、他のFEDにおいて当該オブジェクトが更新され、FED間で通信が発生した場合、その都度、当該FEDが起動されることとなる。これはFEDが不必要に起動（摸擬）される頻度が多発する可能性が高くなり、フェデレーション全体としての実行性能が低下してしまう問題が生じることとなる。
【課題を解決するための手段】
【００１２】
本発明のシミュレーション実行方法は、HLA（High Level Architecture, IEEE1516）に基づき各シミュレーションを実行する分散シミュレーションシステムでの各シミュレータ（フェデレート）において、各フェデレートは自己のフェデレート上に存在するオブジェクトが、自律的に次の摸擬時刻を設定して時刻進行する自律型オブジェクトか、他のオブジェクトからのメッセージを受信するタイミングがトリガとなって時刻進行する他律型オブジェクトかを判定し、両方のオブジェクトが存在する場合は、当該フェデレートは、HLAが提供するイベントベース方式により時刻進行する。
【発明の効果】
【００１３】
本発明は、HLA分散シミュレーションにおいて、FEDがRTIに対して時刻進行要求を発行する際、当該FED上にタイムステップ方式で動作するオブジェクトと、イベントベース方式で動作するオブジェクトが存在する場合は、当該FEDはHLAが提供するNMR（Next Message Request）で時刻進行要求を発行することにより、FED間及びFED内のオブジェクトを因果関係に矛盾無く、シミュレーションを実行することができる。
【図面の簡単な説明】
【００１４】
【図１】HLA分散シミュレーションシステム実施例の構成図である。
【図２】HLAが提供するFEDの時刻進行に関するAPI動作例の説明図である。
【図３】タイムステップ方式とイベントベース方式の動作例の説明図である。
【図４】同一FED上でタイムステップ方式とイベントベース方式のオブジェクトが存在した場合のNMRによる時刻進行要求例のタイミングチャート図である。
【図５】同一のFED上にタイムステップ方式のオブジェクトのみが存在した場合のTARによる時刻進行要求例のタイミングチャート図である。
【図６】FQRとTARを使い分ける場合の実施例のタイミングチャート図である。
【図７】本発明に基づく処理フロー図である。
【図８】本発明の更に他の実施例によるプロセッサへの各FEDのマッピング例の説明図である。
【発明を実施するための形態】
【００１５】
実施の形態１． 
図１は、道路交通を対象としたHLA分散シミュレータの実現例を示したものであり、一般車両を摸擬する２つのFED１，２を処理する計算機１ａと２ａ、緊急車両を摸擬するFED３を処理する計算機３ａ、そして指揮所を摸擬するFED４を処理する計算機４ａがネットワーク５により接続され、このネットワーク５にはRTＩ６を処理する計算機６ａが接続され、RTＩ６を処理する計算機６ａにはRTIの入力ファイルとなるFOM７の属性情報定義ファイルFDD７ａが置かれている。
一般車両及び緊急車両を摸擬するFED１〜３は、それぞれ各自の車両の「位置」情報を更新し、この「位置」情報を他のFEDに転送することとなる。また、緊急車両を摸擬するFED３は指揮所を摸擬するFED４から、指揮命令に関する「通信」情報を受け、それに従い当該緊急車両を摸擬することとなる。なお、指揮所は全ての車両の「位置」情報を受信し、その内容に基づいて指揮命令に関する「通信」情報を発行することとなる。従って、図１の実施の形態では、FED間でやり取りされるオブジェクトクラスは「位置」と「通信」情報であり、FOM７に定義されることとなる。
【００１６】
ここで、本発明に係るHLAが提供する時刻進行要求のためAPI(Application Program Interface)について説明する。
FEDがRTIに対して時刻進行要求を発行する際に、タイムステップ方式（型）で動作するオブジェクトと、イベントベース方式（型）で動作するオブジェクトが当該FED上に存在する場合は、当該FEDはHLAが提供するNMR（Next Message Request）で時刻進行要求を発行することにより、FED間及びFED内のオブジェクトを因果関係に矛盾無く、実行することができる。
【００１７】
また、FEDがRTIに対して時刻進行要求を発行する際に、当該FED上に、タイムステップ型で動作するオブジェクトだけしか存在しなかった場合では、HLAが提供するTAR（Time Advance Request）で時刻進行要求を発行することにより、FED間及びFED内のオブジェクトを因果関係に矛盾無く、実行することができる。特に、TARで時刻進行することにより、RTIからの時刻進行許可通知TAG（Time Advance Grant）を不要な時刻で受け取ることが無くなるため、実行性能の低下を防ぐことが可能となる。即ち、シミュレーションの因果関係に矛盾が生じないのであれば、可能な限り、各FEDはTARで時刻進行した方が、効率的な実行が可能となる。
【００１８】
さらに、HLAではTARとNMRを用いた時刻進行方式の他に、FQR（Flush Queue Request）による時刻進行方式が実装可能である。これは、FEDがRTIに対してFQRによる時刻進行要求を発行することにより、RTIに届いている当該FED宛のメッセージを、当該メッセージに付けられたタイムスタンプの時刻とは無関係に、全て受信することができるものである。
例えば、通信イベントに用いるオブジェクトメッセージを受信するFEDは、FQRにより時刻進行要求することにより、当該FED宛のメッセージを、RTIに届いているものは全て取得できることとなるため、通信イベントに対応したオブジェクトメッセージが存在すれば、そのメッセージを先行して受信することが可能となる。即ち、将来発生する通信イベントがどの時刻で発生するかが分かるため、他にそのようなメッセージを受信しないことが保証されれば、当該FEDはその発生時刻に対して、TARによる時刻進行要求を発行できることとなる。
【００１９】
以上のように、各FEDがタイムステップ型やイベントベース型のオブジェクトを複数扱う場合、各FEDは、当該FED上のオブジェクトの状況に応じて、HLAで提供されるTAR、NMR、そしてFQRを使い分け、RTIに対して時刻進行要求を発行することにより、RTIからの不要な時刻進行許可通知TAGを可能な限り受け取らないようにすることができ、フェデレーション全体としての実行性能の低下を防ぐことができる。
【００２０】
図２は、HLAが提供する時刻進行要求のためのAPIであるTARとNMR、そしてFQRの動作例を示したものである。図２（１）では、FED_Aが時刻tiの時点で時刻tjへの時刻進行要求を、TARを用いて実施した場合の例である。この場合、FED＿Aは要求通りの時刻tjでRTIから時刻進行許可通知TAGを受信することができる。また、他のFED（この例の場合、FED_B）から発行された時刻ti〜tjの間のタイムスタンプを持つメッセージを、FED＿Aは自身がTAGを受ける時刻tjの時点で確認することができる。
【００２１】
また、図２（２）は、FED_Aが時刻tiの時点で時刻tkへの時刻進行要求を、NMRを用いて実施した場合の例である。この場合、他のFED（この例の場合、FED_B）が、FED_Aが購読要求している時刻tjのタイムスタンプ付きメッセージを発行した場合は、FED_Aは時刻tjでRTIから時刻進行許可通知TAGを受信することとなる。また、FED＿Aは当該メッセージをTAGを受ける時刻tjの時点で確認することができる。即ち、FED_Aは自身が要求した時刻tkではない時刻tjに起動されることとなる。仮に、この例において、FED_Aが時刻tiの時点で、時刻tjのタイムスタンプ付きメッセージを発行していた場合は、基本的に、このメッセージをキャンセルするためのコマンド“Retract”をFED_AはRTIに対して発行しなければならないこととなる。
【００２２】
最後に、図２（３）は、FED_Aが時刻tiの時点で時刻tlへの時刻進行要求を、FQRを用いて実施した場合の例である。この場合、NMRと同様に、他のFED（この例の場合、FED_B）が時刻tjで、FED_Aが購読要求しているメッセージAを発行した場合は、FED_Aは時刻tjでRTIから時刻進行許可通知TAGを受信することとなる。この際、FED_AはFED_Bが時刻tiで発行したメッセーAだけでなく、この時点でRTIに届いている、FED_Aが購読要求しているメッセージは全て受信し確認することができる。即ち、この例の場合では、FED_Cが発信した時刻tkのタイムスタンプ付きメッセージBを、本来、FED_Aは時刻tlで受信し確認するべきものであるが、FQRを用いた場合は、FED_AはTAGを受け取る時刻tjのタイミングで受け取り、確認することができることとなる。
【００２３】
本来、因果関係の矛盾を発生させないためには、時刻tjの時点でFED_Aは、FED_Cから発信された時刻tkのタイムスタンプ付きメッセージBを受信することはできない。なぜなら、例えば、FED_CがNMRにより時刻進行要求していた場合は、時刻tkのタイムスタンプ付きメッセージBは、前節でNMRを説明したように、キャンセルされる可能性があるためである。仮に、本例において、FED_CがTARで時刻進行要求していた場合は、メッセージBがキャンセルされることはないが、各FEDは受信したメッセージを論理時刻順に実行することが、因果関係の矛盾を引き起こさないために必須であり、FED_Aは時刻tjの時点でメッセージBを受信しても、その後、時刻tkよりも過去時刻のタイムスタンプ付きメッセージを受け取る可能性があれば、メッセージBに基づく摸擬を実施できないこととなる。仮に実施した場合で、後に過去時刻のタイムスタンプ付きメッセージを受け取った時は摸擬の再実行を実施しなければならなくなる。
【００２４】
既にオブジェクトの動作には、タイムステップ型とイベントベース型の２種類あることを説明したが、図３は、「通信」情報等のメッセージを受け取るオブジェクトがタイムステップ型であった場合とイベントベース型であった場合の時間的な精度について説明したものである。
図３（１）は当該メッセージを受信するオブジェクトがタイムステップ型で時刻進行していた場合の例であり、仮に当該メッセージ発信側が時刻tjのタイムスタンプ付きメッセージを送信したとしても、当該受信側オブジェクトは当該メッセージを時刻tkで受信し確認することとなる。この場合、|tk‐tj|の時間的誤差が発生することとなる。即ち、タイムステップ型で時刻進行するオブジェクトは、タイムステップ間隔の時間（Δｔ）で摸擬精度が丸められてしまうこととなる。
他方、図３（２）は当該メッセージを受信するオブジェクトがイベントベース型で時刻進行していた場合の例である。この場合、当該メッセージ発信側が時刻tjのタイムスタンプ付きメッセージを送信した時には、当該受信側オブジェクトは、正にこの時刻tjで当該メッセージを受信することができることとなる。即ち、時間的観点では摸擬精度を劣化させずに実現できることになる。
【００２５】
図４（１）は、図１で示した例をタイミングチャートで示したものである。この例では、図１で説明したように、FED間で「位置」情報と「通信」情報のオブジェクトがやり取りされることとなる。また、「位置」情報は各車両とも、タイムステップ型で更新および（他から届いたものを）確認するものとしている。他方、「通信」情報の受信に関しては、他から届いたメッセージを遅延なく確認するべく、イベントベース型で動作するものとしている。この例では、「通信」情報を発信するのは「指揮所」のみで、受信するのは「緊急車両A」のみとしている。なお、図４（１）は実装イメージを排除した理想的な動作を示したものであるが、オブジェクト間の全てのメッセージ送受を示すと図が煩雑となるため、緊急車両Aを中心としたメッセージしか正確には示していない。また、図中の“Sub”は当該オブジェクトメッセージを他から購読することを示し、“Pub”は自身が公開することを示したもので、“Pub/Sub”は当該オブジェクトメッセージを公開するとともに、購読することを示したものである。
【００２６】
他方、図４（２）は、図４（１）で示したオブジェクトをHLAの4つのFEDにマッピングした場合の例を示したものである。この例では、緊急車両A及び指揮所は、それに係る「位置」と「通信」情報のオブジェクトは関連性が強いため同一のFEDにマッピングしている。この場合の特徴は、FED3上にはタイムステップ型とイベントベース型のオブジェクトが混在しているため、FED3はNMRで時刻進行要求していることである。この場合、前記したように、FED3がNMRで時刻進行要求したことにより、「位置」情報もイベントベース型で動作することとなり、何れかの車両が「位置」情報を更新する度に、FED３にTAGが届くこととなる。
【００２７】
図４では、指揮所からいつ通信メッセージが届くか明確でないため、緊急車両Aの「通信」オブジェクトはイベントベース型で動作させていたが、この通信メッセージが発行される時刻が明確であれば、その時刻に対してタイムステップ型で動作させることが可能となる（図５（１）参照）。この場合、図５（２）に示すように、担当するFED3はTARにより時刻進行要求は発行することができるので、「位置」情報のメッセージ受信による不要なTAGを受けることなく、効率的に実行できることとなる。
【００２８】
図６は、指揮所からいつ通信メッセージが届くか明確でない場合のものである。基本的に、緊急車両Aの「通信」オブジェクトはイベントベース型で動作するが、本実施例は、緊急車Aの摸擬を担当するFED3は、FQRにより時刻進行要求を出す場合のものである。この場合、指揮所が発行した通信メッセージに関して、未来時刻のタイムスタンプ付きメッセージを事前に受け取ることが出来、かつ指揮所側からの当該通信メッセージを扱うオブジェクトがタイムステップ型で動作している場合では、緊急車両A側の当該通信メッセージを扱うオブジェクトはこの未来時刻に対してタイムステップ型で動作すれば良い。即ち、その場合は、FED3上のオブジェクトは全てタイムステップ型となるため、FED3はTARにより時刻進行要求を発行することができる。これにより、他の車両での位置情報更新に伴う不要なTAGを受け取ることがなくなるため、効率的な実行が可能となる。
なお、当該通信メッセージを発行するオブジェクトが複数存在する場合、即ち、緊急車両Aにとって、指揮命令を発行する指揮所が複数存在する場合は、FED3はFQRにより、全ての指揮所からの未来時刻のタイムスタンプを持った通信メッセージを取得した後、最も近い未来の時刻に対して、タイムステップ型で動作することとなる。
【００２９】
図７は、本発明を適用する場合の処理フローを示したもので、（１）がNMRとTARを使い分けて実行する場合であり、（２）がFQRとTARを使い分けて実行する場合の例である。以下にそれぞれについて説明する。
まず、図７（１）では、各FEDは、自身が担当するオブジェクトの中に、イベントベース型で時刻進行要求をしているオブジェクトが有るか無いかをチェックする(711)。当該オブジェクトが有る場合、当該FEDはNMRでRTIに対して時刻進行要求を発行する(712)。他方、イベントベース型で時刻進行要求をしているオブジェクトが無い場合は、TARでRTIに対して時刻進行要求を発行する(713)。RTIから当該FEDに時刻進行許可通知TAGが届くと(714)、当該FEDは自身が担当するオブジェクト及びそれに関連する1ステップ分の摸擬を実施する(715)。本摸擬処理では、各オブジェクトが次のステップで、イベントベース型で時刻進行するか、タイムステップ型で時刻進行するかをも決定することとなる。そして、711の処理に移り、これら一連の処理を繰り返していくこととなる。
【００３０】
次に図７（２）について説明する。まず、各FEDは、自身が担当するオブジェクトの中に、イベントベース型で時刻進行要求をしているオブジェクトが有るか無いかをチェックする(721)。当該オブジェクトが有る場合、当該FEDはFQRでRTIに対して時刻進行要求を発行する(722)。そして、RTIから当該FEDに時刻進行許可通知TAGが届くと(723)、メッセージを受信している場合はメッセージに付加されているタイムスタンプの時刻順に当該メッセージを当該FEDは管理する(724)。なお、「通信」情報等の先読みしたいメッセージが含まれている場合はその未来時刻を記録し、このようなメッセージを全て受信した時には(725)、当該未来時刻の中で最も若い時刻に設定したタイムステップ型に当該オブジェクトを変更する(726)。そして、1ステップ分の摸擬処理を行い、721の処理に移ることとなる。
【００３１】
他方、FEDは、自身が担当するオブジェクトの中に、イベントベース型で時刻進行要求をしているオブジェクトが有るか無いかをチェックするステップ721の判定で、イベントベース型のオブジェクトが存在せず全てタイムステップ型のオブジェクトであった場合は、当該FEDはTARで時刻進行要求を実施する(728)。その後、RTIから当該FEDに時刻進行許可通知TAGを受けた際(729)に、当該FEDは「通信」情報等のメッセージを受けるべく、本来、イベントベース型であるべきオブジェクトが、引き続きタイムステップ型であって良いか否かを判定し、その条件を満足できない場合はイベントベース型に戻す処理を行う(730)。そして、1ステップ分の摸擬処理を行い(727)、721の処理に移ることとなる。
【００３２】
図８は、本発明によるFQRとTARを使い分ける方法において、よりその効果を出すための、各FEDのプロセッサへのマッピングの仕方に関する実施例を示したものである。基本的に、「通信」情報を発信するメッセージ及びそのタイムスタンプの時刻は、その情報を必要とする他のFEDに、早目に通知する方が本発明による方法の効果を発揮できる。即ち、このような「通信」情報を発信するオブジェクトを担当するFEDは、その論理時刻を可能な範囲内で他のFEDよりも先行させてやるのが良いこととなる。そのため、当該FEDを最も処理負荷の軽いプロセッサに割り付けてやることが考えられる。この実施例を示したものが図８であり、各オブジェクト及び各FEDの計算負荷を経験則により定め、プロセッサのトータルの処理負荷が最も小さいプロセッサに、上記「通信」情報を発信するオブジェクトを担当するFEDを割り付けることが考えられる。
また、シミュレーション実行中に、各FEDの負荷状況に応じて、上記「通信」情報を発信するオブジェクトを担当するFEDが最も負荷の小さいプロセッサに割り付けられるように、動的に、FEDとプロセッサのマッピングを変えることも考えられる。
【産業上の利用可能性】
【００３３】
HLAは、大規模シミュレーションの実現を目的に、異なる組織で開発されたシミュレータを統合するための規格として主に活用されおり、本発明は、大規模シミュレーションでの課題である実行性能向上を図るためのオーバーヘッド削減方式であり、HLAを利用した分散シミュレーションシステムで広く活用される可能性がある。
【符号の説明】
【００３４】
１，２；一般車両を摸擬するFED、１ａ、２ａ；FED１，２処理用計算機、３；緊急車両を摸擬するFED、３ａ；FED３処理用計算機、４；指揮所を摸擬するFED、４ａ；FED４処理用計算機、５；ネットワーク、６；RTＩ、６ａ；RTＩ６処理用計算機、７；FOM、FDD７ａ；FOM属性情報定義ファイル。
【図１】
2010244459.tif 000003
【図２】
2010244459.tif 000004
【図３】
2010244459.tif 000005
【図４】
2010244459.tif 000006
【図５】
2010244459.tif 000007
【図６】
2010244459.tif 000008
【図７】
2010244459.tif 000009
【図８】
2010244459.tif 000010