(57)【要約】      （修正有）【課題】シミュレーションの速度を向上させる。【解決手段】先読みディスパッチャ８０６は、エントリ点における入力の状態を監視し、入力の状態が安定であると、適応的実行モジュール８１４を呼び出す。適応的実行モジュール８１４は、複数タイム・スタンプの処理を一気に実行する。先読みディスパッチャ８０６は、離散系システムが入力イベントを受け取ることに応答して、回復実行モジュール８１８を呼び出す。回復実行モジュール８１８は、そのときの入力イベントと、タイム・スタンプと、状態ベクトルに保存されている値に基づき、処理を再開する。【選択図】図８
2010282291.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータの動作によって、シミュレーションを行なうシステムであって、
入力状態が安定かどうか判別する手段と、
入力状態が安定であるとの判断に応答して、一度に複数ステップを実行する適応処理ルーチンを実行する手段と、
入力状態が安定でないとの判断に応答して、一度に一ステップを実行する通常処理ルーチンを実行する手段と、
イベントの入力に応答して、イベントの入力に基づき復元すべき状態を決し、該復元すべき状態を用いて該イベントの入力時点から処理を再開する回復ルーチンを実行する手段とを有する、
シミュレーション・システム。
【請求項２】
前記適応処理ルーチンが、前記複数ステップの個々のステップ毎にタイムスタンプとともに状態を順次記憶し、前記回復ルーチンを実行する手段が、前記イベントのタイムスタンプに基づき、前記記憶されている状態を参照し、前記復元すべき状態とする、請求項１に記載のシミュレーション・システム。
【請求項３】
イベントの入力値を順次記憶する手段と、該記憶されている入力値と、現在の状態の値に基づき前記復元すべき状態を計算する手段をさらに有する、請求項１に記載のシミュレーション・システム。
【請求項４】
前記適応処理ルーチンの出力を時間的に補間して出力する手段をさらに有する、請求項１に記載のシミュレーション・システム。
【請求項５】
コンピュータの動作によって、シミュレーションを行なう方法であって、
入力状態が安定かどうか判別するステップと、
入力状態が安定であるとの判断に応答して、一度に複数ステップを実行する適応処理ルーチンを実行するステップと、
入力状態が安定でないとの判断に応答して、一度に一ステップを実行する通常処理ルーチンを実行するステップと、
イベントの入力に応答して、イベントの入力に基づき復元すべき状態を決し、該復元すべき状態を用いて該イベントの入力時点から処理を再開する回復ルーチンを実行するステップとを有する、
シミュレーション方法。
【請求項６】
前記適応処理ルーチンが、前記複数ステップの個々のステップ毎にタイムスタンプとともに状態を順次記憶し、前記回復ルーチンを実行するステップが、前記イベントのタイムスタンプに基づき、前記記憶されている状態を参照し、前記復元すべき状態とする、請求項５に記載のシミュレーション方法。
【請求項７】
イベントの入力値を順次記憶するステップと、該記憶されている入力値と、現在の状態の値に基づき前記復元すべき状態を計算するステップをさらに有する、請求項５に記載のシミュレーション方法。
【請求項８】
前記適応処理ルーチンの出力を時間的に補間して出力するステップをさらに有する、請求項５に記載のシミュレーション方法。
【請求項９】
コンピュータの動作によって、シミュレーションを行なうプログラムであって、
前記コンピュータに、
入力状態が安定かどうか判別するステップと、
入力状態が安定であるとの判断に応答して、一度に複数ステップを実行する適応処理ルーチンを実行するステップと、
入力状態が安定でないとの判断に応答して、一度に一ステップを実行する通常処理ルーチンを実行するステップと、
イベントの入力に応答して、イベントの入力に基づき復元すべき状態を決し、該復元すべき状態を用いて該イベントの入力時点から処理を再開する回復ルーチンを実行するステップを実行させる、
シミュレーション・プログラム。
【請求項１０】
前記適応処理ルーチンが、前記複数ステップの個々のステップ毎にタイムスタンプとともに状態を順次記憶し、前記回復ルーチンを実行するステップが、前記イベントのタイムスタンプに基づき、前記記憶されている状態を参照し、前記復元すべき状態とする、請求項９に記載のシミュレーション・プログラム。
【請求項１１】
イベントの入力値を順次記憶するステップと、該記憶されている入力値と、現在の状態の値に基づき前記復元すべき状態を計算するステップをさらに有する、請求項９に記載のシミュレーション・プログラム。
【請求項１２】
前記適応処理ルーチンの出力を時間的に補間して出力するステップをさらに有する、請求項９に記載のシミュレーション・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コンピュータによるシミュレーション技術に関し、より詳しくは、自動車のエンジンのような物理装置をソフトウェア・ベースでシミュレーションするためのシステム、方法及びプログラムに関するものである。
【背景技術】
【０００２】
自動車は、その初期の時代の２０世紀初頭は、動力としてのエンジンと、ブレーキ、アクセル、ハンドル、トランスミッション、サスペンジョンを含む、機構部品からなっていたが、エンジンのプラグの点火、ヘッドライト以外は、電気的な仕組みはほとんど利用していなかった。
【０００３】
ところが、１９７０年代頃から、大気汚染、石油危機などに備えて、エンジンを効率的に制御する必要性が生じ、このためエンジンの制御に、ＥＣＵが使用されるようになってきた。ＥＣＵは、一般的に、センサからの入力信号を、例えばＡ／Ｄ変換する入力インターフェースと、決められた論理に従ってディジタル入力信号を処理する論理演算部（マイクロコンピュータ）と、その処理結果を、アクチュエータ作動信号に変換する出力インターフェースとから構成される。
【０００４】
いまや、エンジンやトランスミッションなどの制御システム、Anti-lock Breaking System （ＡＢＳ）、Electronic Stability Control （ＥＳＣ）、パワーステアリングだけでなく、ワイパー制御やセキュリティ・モニタリング・システムなどに至るまで、最近の自動車では、機構部品だけでなく、エレクトロニクス部品やソフトウエアが重要な比率を占める。後者に関する開発費は全体の２５％とも４０％とも言われ、ハイブリッド型の自動車では７０％を占める。
【０００５】
電子制御は、ＥＣＵを複数、配置して行われる。ＥＣＵ間は車載ネットワーク、例えば、Controller Area Network （ＣＡＮ） で相互に接続される。また、制御の対象である、エンジンやトランスミッションなどには、それぞれのＥＣＵから直接ワイヤ接続する。
【０００６】
ＥＣＵは、小さなコンピュータであり、センサ入力などからの割り込みに応じて動作する。一方、エンジンなどは連続的に機械的動作を行っている。すなわち、コンピュータ系のディジタル・システムと、機械系の物理システムが、自動車という単一システムにおいて、並列に協調動作を行っている。当然、これを支えるソフトウエアは複雑さがますます増大しており、ＥＣＵ単体で動作を検証するだけでなく、複数を同時に検証する仕組みの実現が要望されている。
【０００７】
一方、ＥＣＵの出力信号によって駆動されるアクチュエータには、電磁ソレノイド及びモータ等がある。ソレノイドは例えば、エンジンのインジェクタ、トランスミッションのシフト・コントロール、ブレーキのバルブ制御、ドアロックなどに使用される。
【０００８】
このような装置のテストのために従来行われている技法として、ＨＩＬＳ(Hardware In the Loop Simulation)がある。特に、自動車全体のＥＣＵをテストする環境は、ホールビークルＨＩＬＳ(Whole Vehicle Hardware In the Loop Simulation)と呼ばれる。ホールビークルＨＩＬＳにおいては、実験室内で、本物のＥＣＵが、エンジン、トランスミッション機構などをエミュレーションする専用のハードウェア装置に接続され、所定のシナリオに従って、テストが行われる。ＥＣＵからの出力は、監視用のコンピュータに入力され、さらにはディスプレイに表示されて、テスト担当者がディスプレイを眺めながら、異常動作がないかどうか、チェックする。
【０００９】
しかし、ＨＩＬＳは、専用のハードウェア装置を使い、それと本物のＥＣＵの間を物理的に配線しなくてはならないので、準備が大変である。また、別のＥＣＵに取り替えてのテストも、物理的に接続し直さなくてはならないので、手間がかかる。さらに、本物のＥＣＵを用いたテストであるため、テストに実時間を要する。従って、多くのシナリオをテストすると、膨大な時間がかかる。また、ＨＩＬＳのエミュレーション用のハードウェア装置は、一般に、非常に高価である。
【００１０】
そこで近年、高価なエミュレーション用ハードウェア装置を使うことなく、ソフトウェアで構成する手法が採用されつつある。この手法は、ＳＩＬＳ(Software In the Loop Simulation)と呼ばれ、ＥＣＵに搭載されるマイクロコンピュータ、入出力回路、制御のシナリオなどを全て、ソフトウェア・シミュレータで構成する技法である。これによれば、ＥＣＵのハードウェアが存在しなくても、テストを実行可能である。
【００１１】
ところで、自動車用シミュレーション・システムは、連続系シミュレータと、離散系シミュレータを有する。連続系シミュレータの例として、エンジンの機械系部分をシミュレートするシミュレータがある。離散イベント系シミュレータの例として、エンジン回転のパルスのタイミングで動作し、燃料噴射や点火のタイミングを制御するＥＣＵのシミュレータがある。
【００１２】
４ＷＤのシミュレーションをする場合においては、連続系シミュレータの例として、各タイヤへのトルク配分から車の動作を繰り返し計算するシミュレータがあり、離散イベント系シミュレータの例として、10ミリ秒ごとの定期パルス信号で動作し、車のヨーレートなどのセンサ入力から各タイヤへのトルク配分を決定するＥＣＵをシミュレートするシミュレータがある。
【００１３】
このようなシステムにおいて、特定のテスト・シナリオに沿ってテストを行うことは非常に時間を要するので、全体にかかる時間を短縮するために、常に処理速度の向上への要望がある。
【００１４】
特開２００１−２９０８６０号公報は、シミュレータ間の不要な同期処理をシミュレータで求め、その同期処理を削減することにより、シミュレーション速度の向上を図ったハードウエア／ソフトウエア協調シミュレータを提供することを目的とするものであって、ＣＰＵシミュレーション手段と周辺回路シミュレーション手段を同期させるシミュレーション協調手段と、シミュレーション協調手段での同期を抑制するかどうかを決定する判断手段を備え、判断手段に基づいて前記シミュレーション協調手段での同期を抑制することを開示する。
【００１５】
特開平８−２２７３６７号公報は、設計エラーが予期されるシステム動作を除く全てのシステム動作を無視する高速シミュレータを使用してデバッグ速度を増加させるデバッガを得ることを目的とするものであって、各シミュレータを相互接続するための、バスサイクルに対応する信号を提供するバスのバスシミュレータとシミュレーションに不必要なバスサイクルを省略する手段を備え、シミュレーションに無関係なＣＰＵバスサイクルを省略し、または、周期的クロック信号を明示的にシミュレートしないでクロック信号のスケジュールのみを発生するようにすることを開示する。
【００１６】
特開２００４−３０２２８号公報は、ＣＰＵシミュレータと、１以上の周辺マクロシミュレータと、これらの同期実行を制御する同期実行制御処理部とを備え、周辺マクロシミュレータが、ＣＰＵシミュレータでのシミュレーションに基づいて端子に入力される信号が変化したときに当該端子信号に基づくシミュレーションを実行すし、さらに周辺マクロシミュレータは、入力された端子信号の変化を検出し、変化した端子信号を端子信号リスト２２に登録し、登録された端子信号についてのみシミュレーションを実行するようにすることを開示する。
【００１７】
特開２００６−６５７５８号公報は、回路シミュレーション手法において、回路データから作成された第１離散時間モデルに応答関数を与えて第２離散時間モデルを生成し、クロックのエッジタイミングおよびこのタイミングでのクロック同期回路に入出力される信号の実効的信号値を、第２離散モデルを用いて計算し、これによってシミュレーションを実行することを開示する。
【００１８】
これらの従来技術は、一般的なシミュレーション・システムの実行速度向上に貢献することができるが、ＥＣＵエミュレータなどの、イベント・ベースで駆動される離散系システムに適用することは困難である。
【００１９】
そこで、本願発明者を含む発明者らは、特願２００８−１５１０４７号明細書において、通常は物理装置シミュレータを高速で投機的に連続実行させ、実際の入力が入ってきたときのみ、投機的な入力と実際の入力を比較し、それらが不一致であることに応答して、実際の入力の時点に一番近い時点に物理装置シミュレータを戻し、実際の入力の時点まで可変ステップさせ、実際の入力の時点まで辿り着いたら、そこから高速連続実行に戻すことにより、シミュレータの処理速度を向上することができる技法を提示した。
【先行技術文献】
【特許文献】
【００２０】
【特許文献１】特開２００１−２９０８６０号公報
【特許文献２】特開平８−２２７３６７号公報
【特許文献３】特開２００４−３０２２８号公報
【特許文献４】特開２００６−６５７５８号公報
【特許文献５】特願２００８−１５１０４７号明細書
【発明の概要】
【発明が解決しようとする課題】
【００２１】
上記特願２００８−１５１０４７号明細書に記載されている技法では、投機失敗時の回復処理のコストが比較的大きい。
【００２２】
従って、この発明の目的は、投機的な入力と実際の入力が異なる場合に、比較的小さいコストで、シミュレーションをやり直すことを可能ならしめる技法を提供することにある。
【課題を解決するための手段】
【００２３】
この発明は、好適には、シミュレーションの処理プログラムが、相互に連結された、複数の機能ブロックからなることを想定する。そのような機能ブロックは、例えば、Matlab(R)/Smulink(R)などのシミュレーション・ツールにより作成することができる。
【００２４】
すると、本発明に従う技法は先ず、コンピュータの自動的な処理によって、内部状態をもつ機能ブロックが広い範囲をカバーするように、エントリ点を見出す。すると、本発明に従う処理系は、エントリ点のところで、好適には、通常実行モジュールと、適応的実行モジュールと、回復実行モジュールと、アイドル実行モジュールのどれかに処理を振り分ける先読み(lookahead)ディスパッチャのコードを配置する。
【００２５】
先読みディスパッチャは、エントリ点における入力の状態を監視し、入力の状態が安定状態にあるかどうかを判定する。その判定は例えば、ある一定時間の間に入ってくる入力の値の頻度または変化の検出により、行なうことができる。
【００２６】
入力の状態が安定であると、先読みディスパッチャは、ある頻度で適応的実行モジュールを呼び出し、それ以外の場合に、アイドル実行モジュールを呼び出す。適応的実行モジュールは、入力の状態が一定であるとの想定の下に、複数タイム・スタンプの処理を一気に実行する。このとき、一気に実行されるステップ数は、任意の値を取りえるが、好適には、４乃至８である。適応的実行モジュールの内部状態は、状態ベクトルに順次保存される。状態ベクトルは、好適には主記憶上に確保された領域に配置された変数の列であり、その次元数は、好適には、適応的実行モジュールが一気に実行されるステップ数と等しくされる。
【００２７】
アイドル実行モジュールは、出力値の履歴に基づき、補間的な出力を与える。
【００２８】
先読みディスパッチャは、安定でない入力の状態であると判定すると、通常実行モジュールを呼び出す。通常実行モジュールは、１タイム・スタンプ毎に、順次処理を実行する。
【００２９】
先読みディスパッチャは、離散系システムが入力イベントを受け取ることに応答して、回復実行モジュールを呼び出す。回復実行モジュールは、そのときの入力イベントと、タイム・スタンプと、状態ベクトルに保存されている値に基づき、回復を実行するための状態を計算し、その状態に基づき処理自体を再開する。
【発明の効果】
【００３０】
この発明によれば、定常状態を検出することによって複数タイム・スタンプの処理を一気に進めることにより、処理速度を向上することができるとともに、状態ベクトルへの順次的な状態の保存によって、突然の状態に入力に応答して直ちに回復処理を起動して、入力の変化に対応することが可能である。
【００３１】
また、この発明の技法は、既存の機能ブロックのシミュレーション・システムに対して、コンパイラなどの処理系レベルでコードを変換し追加することによって、比較的容易に実現可能である。
【図面の簡単な説明】
【００３２】
【図１】シミュレーション・システムの入力の状態の推移を示す図である。
【図２】シミュレーション・システムの入力、出力及び内部状態を示す模式的なブロック図である。
【図３】本発明を実施するためのハードウェア構成のブロック図である。
【図４】機能ブロックのブロック線図である。
【図５】機能ブロックの強連結成分を示す図である。
【図６】機能モジュールの論理ブロック図である。
【図７】エントリ点を確定するための処理のフローチャートを示す図である。
【図８】エントリ点付近でのコードの変換と追加を示す図である。
【図９】離散系システムと、連続系システムの連携を示す概要ブロック図である。
【図１０】先読みディスパッチャの動作のフローチャートを示す図である。
【図１１】活動状態と安定状態を判別するための処理のフローチャートを示す図である。
【図１２】適応ステップ・プログラムの処理のフローチャートを示す図である。
【図１３】アイドル状態での補間処理を示す図である。
【図１４】回復処理のフローチャートを示す図である。
【発明を実施するための形態】
【００３３】
以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。
【００３４】
本発明を実現するための具体的な構成を説明する前に、本発明の背景及び原理について説明する。図１は、本発明が適用されるシミュレーション・システムに対する入力の時間変化を示す図である。特に、自動車シミュレーション・システムにおけるエンジン用ＥＣＵエミュレータなどの離散系システムにおいては、その入力信号について、入力信号の値が大きく時間変化する、比較的短い活動状態の期間と、入力信号の値があまり変化しない、比較的長い安定状態からなる。
【００３５】
そこで本願発明者は、この入力信号の変化に着目し、入力信号の活動状態の期間では通常の比較的細かいステップでシミュレーション・システムを動作させ、入力信号の安定状態では、比較的粗いステップでシミュレーション・システムを動作させ、これによって全体の動作速度を向上させることを意図した。
【００３６】
図２は、シミュレーション・システム２０２の動作を模式的に示すブロック図である。システム２０２は、参照番号２０４で示すように、一般的に内部状態xをもち、システム２０２への入力をu、出力をyとすると、一般的に下記のような式であらわされる。
x = Ax + Bu
y = Cx + Du
ここで、A, B. C, Dは、ある係数である。
【００３７】
uをinputと表記し、xをstateと表記し、yをoutputと表記し、
x = Ax + Buという式を、関数f()として表記すると、
statek+1 = f(statek,input)と表される。
ここで、statekは、k番目のタイムスタンプにおける内部状態をあらわす。
【００３８】
同様に、y = Cx + Duという式を、関数g()として表記すると、
output = g(statek,input) と表される。
【００３９】
さて、状態statekの下で、inputという入力を受け取ってoutputを出力する処理の反復は、次のような擬似コードで記述することができる。
while simulation == true
statek+1 := f(statek,input)
output := g(statek,input)
endwhile
ここで、simulationは、それがtrueの間はシミュレーション動作を継続し、シミュレーション動作を停止する場合はfalseにセットされる論理変数であるとする。
【００４０】
上記のコードは、次のようなコードとほぼ等価である。
while simulation == true
statek+1 := f(statek,input1)
output1 := g(statek+1,input1)
statek+2 := f(statek+1,input2)
output2 := g(statek+2,input2)
endwhile
このような処理は、input1、input2・・などの入来を待って順次statek+1、output1などの計算するので、処理に時間がかかる。
【００４１】
ところが、図１に示すような安定状態の期間では、inputはほとんど変化しないと仮定することができる。すると、上記のコードは、次のように書き直せる。
while simulation == true
statek+1 := f(statek,input)
statek+2 := f(statek+1,input)
output2 := g(statek+2,input)
endwhile
ここで、output1 = g(statek+1,input)が省略されているのは、input一定の下ではoutputはほぼ線形に変化するので、改めて計算することなく、途中で線形補間で簡単に計算できる、と想定している。このことはあとで、詳しく説明する。
【００４２】
上記のコードを更に拡張して、次のようにする。
while simulation == true
statek+1 := f(statek,input)
statek+2 := f(statek+1,input)
statek+3 := f(statek+2,input)
...
outputn := g(statek+n,input)
endwhile
ここで、nを、この実施例では、先読み(lookahead)因子と呼ぶことにする。ここに示すように、本発明では、安定状態の期間に、一定の入力inputを想定して、一気に先読み因子n分のタイムスタンプを実行することによって、安定状態の期間の処理が高速化される。
【００４３】
本発明によれば、先読み因子の好適な数nは、4乃至8程度である。さらに本発明によれば、シミュレーション・システムにおいて、一気に先読み因子n個分のエントリをもつ状態ベクトルが、好適にはメモリ上に用意され、ここに順次、計算された状態が保存される。後で詳しく説明するが、ここに保存された状態は、後の回復実行処理によって使用される。
【００４４】
次に、図３を参照して、本発明を実施するために使用されるコンピュータのハードウェアについて説明する。図３において、ホスト・バス３０２には、複数のＣＰＵ０  ３０４ａ、ＣＰＵ１  ３０４ｂ、ＣＰＵ２  ３０４ｃ、ＣＰＵ３  ３０４ｄが接続されている。ホスト・バス３０２にはさらに、ＣＰＵ０  ３０４ａ、ＣＰＵ１  ３０４ｂ、ＣＰＵ２  ３０４ｃ、ＣＰＵ３  ３０４ｄの演算処理のためのメイン・メモリ３０６が接続されている。
【００４５】
一方、Ｉ／Ｏバス３０８には、キーボード３１０、マウス３１２、ディスプレイ３１４及びハードティスク・ドライブ３１６が接続されている。Ｉ／Ｏバス３０８は、Ｉ／Ｏブリッジ３１８を介して、ホスト・バス３０２に接続されている。キーボード３１０及びマウス３１２は、オペレータが、コマンドを打ち込んだり、メニューをクリックするなどして、操作するために使用される。ディスプレイ３１４は、後述する本発明に係るプログラムをＧＵＩで操作するための画面イメージを表示するために使用される。
【００４６】
この目的のために使用される好適なコンピュータ・システムのハードウェアとして、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ  Ｘがある。その際、ＣＰＵ０  ３０４ａ、ＣＰＵ１  ３０４ｂ、ＣＰＵ２  ３０４ｃ、ＣＰＵ３  ３０４ｄは、例えば、インテル（Ｒ）Ｃｏｒｅ  ２  ＤＵＯであり、オペレーティング・システムは、Ｗｉｎｄｏｗｓ（商標）Ｓｅｒｖｅｒ  ２００３である。オペレーティング・システムは、ハードティスク・ドライブ３１６に格納され、コンピュータ・システムの起動時に、ハードティスク・ドライブ３１６からメイン・メモリ３０６に読み込まれる。
【００４７】
尚、本発明を実施するために使用可能なコンピュータ・システムのハードウェアは、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ  Ｘに限定されず、ＥＣＵエミュレータ・プログラム及び物理装置シミュレータ・プログラムを走らせることができるものであれば、任意のコンピュータ・システムを使用することができる。オペレーティング・システムも、Ｗｉｎｄｏｗｓ（Ｒ）に限定されず、Ｌｉｎｕｘ（Ｒ）、Ｍａｃ  ＯＳ（Ｒ）など、任意のオペレーティング・システムを使用することができる。さらに、ＥＣＵエミュレータ・プログラム及び物理装置シミュレータ・プログラムを高速で動作させるために、ＰＯＷＥＲ（商標）６ベースで、オペレーティング・システムがＡＩＸ（商標）のＩＢＭ（Ｒ）Ｓｙｓｔｅｍ  Ｐなどのコンピュータ・システムを使用してもよい。
【００４８】
ハードディスク・ドライブ３１６にはさらに、複数のＥＣＵエミュレータ・プログラム、複数の物理装置シミュレータ・プログラム、及び、それら複数のＥＣＵエミュレータ・プログラム及び物理装置シミュレータ・プログラムを協働させてテストするための、本発明に係るプログラムが格納され、キーボード３１０及びマウス３１２によって起動操作可能である。
【００４９】
好適には、フルビークルＳＩＬＳを実現するために、１台の自動車で使われるすべてのＥＣＵのエミュレータ・プログラム及び物理装置シミュレータ・プログラムが、ハードティスク・ドライブ３１６に保存されている。
【００５０】
尚、ここでの「エミュレータ」と、「シミュレータ」の用語の使い分けであるが、もともとの、別のプロセッサで動くことを想定して書かれていたＥＣＵのコードを、ＣＰＵ０〜ＣＰＵ３などをターゲットとして動くようにすることを、エミュレーションと呼び、それを行うプログラムを、エミュレータと呼ぶ。一方、エンジンなどの物理的システムの動作を仮想計算するシステムを、シミュレータと呼ぶ。
【００５１】
ハードティスク・ドライブ３１６にはまた、MathWorks社が開発したシミュレーション・モデリング・システムである、MATLAB(R)/Simulink(R)によって作成された機能ブロックのブロック線図が所定のデータ形式で保存されている。すなわち、MATLAB(R)/Simulink(R)を使用すると、図４に示すように、画面上にグラフィカル・インターフェースによって、機能ブロックA,B,...,Mを配置し、矢印のようにその処理の流れを指定することによって、シミュレーション・プログラムを作成することができる。一般に、MATLAB(R)/Simulink(R)におけるブロック線図は、シミュレーション対象となるシステムの１タイムステップの挙動を記述したもので、これを規定時間分繰り返し計算することで、システムの時系列での挙動を得る。
【００５２】
図６は、本発明に従い、シミュレーション・プログラムを処理するためのツールのブロック図である。図６において、シミュレーション・モデリング・ツール６０２は、MATLAB(R)/Simulink(R)、Scilab/Scicosなどの既存の任意のツールでよい。シミュレーション・モデリング・ツール６０２は、基本的には、オペレータが、ディスプレイ３１４上でＧＵＩ的に機能ブロックを配置し、数式など必要な属性を記述し、必要に応じて、機能ブロック間を関連付けてブロック線図を記述することを可能とする機能をもつ。シミュレーション・モデリング・ツール６０２はさらに、記述されたブロック線図に等価な機能を記述するＣのソースコードを出力する機能をもつ。Ｃ以外にも、Ｃ＋＋、ＦＯＲＴＲＡＮなどを使用することができる。さらに、ＭＤＬファイルとして、Simulink(R)独自のフォーマットであり、機能ブロック間の依存関係を記述するためのファイルを生成することもできる。
【００５３】
シミュレーション・モデリング・ツールは、別のパーソナル・コンピュータに導入して、そこで生成されたソース・コードを、ネットワークなどを経由して、ハードティスク・ドライブ３１６にダウンロードするようにすることもできる。
【００５４】
こうして出力されたソース・コード６０４は、ハードティスク・ドライブ３１６に保存される。ソース・コード６０４は、解析モジュール６０６で解析される。本発明に関連する、この解析の主要な目的は、ソース・コード６０４で示されるプログラムのエントリ点を見出すことにある。
【００５５】
図７にそのための処理を示す。図７の処理を開始する前に、解析モジュール６０６は、ソース・コード６０４を、図５に示すようなコンパイル単位としての強連結成分に分割する。図５において、領域５０２、５０４、５０６、５０８及び５１０が、強連結成分の領域の例である。ここで強連結であるとは、ソース・コード６０４をコントロール・フローとみなし、コントロール・フローを有向グラフとみたとき、グラフ上の任意の２点間に有向路が存在することをいう。なお、コントロール・フローにおいて強連結成分を見出す技法については、例えば、本出願人に係る特開平９−３１９７２２号公報、及び特開２００４−２７２８２６号公報などを参照されたい。
【００５６】
図７において、ステップ７０２では、解析モジュール６０６は、強連結成分であるコンパイル単位を取り出す。
【００５７】
ステップ７０４では、解析モジュール６０６は、コンパイル単位の入口から出口までで見つかった、内部状態をもつ全ての機能ブロックの集合をつくる。ステップ７０６では、解析モジュール６０６は、交わる集合をマージする。ここで、「交わる」とは、互いに接続されていることを意味する。
【００５８】
ステップ７０８では、解析モジュール６０６は、コンパイル単位がまだあるかどうか判断し、まだあるなら、ステップ７０２に行って処理を繰り返す。
【００５９】
ステップ７０８で、解析モジュール６０６が、処理していないコンパイル単位がもうないと判断すると、ステップ７１０で解析モジュール６０６は、最大の要素数をもつ集合を選ぶ。その集合への入口が、求めるエントリ点となる。
【００６０】
図６に戻って、エントリ点を見出すと、解析モジュール６０６は、そのエントリ点の情報を、コード生成モジュール６０８に渡す。
【００６１】
コード生成モジュール６０８は、エントリ点を基点として、元のコードを基にコードを生成する。その様子を図８に示す。
【００６２】
図８(a)に、元のコードを示す。元のコードは、エントリ点８０２とそれに続く領域８０４とからなる。
【００６３】
コード生成モジュール６０８は、この元のコードから、図８(b)に示すように、４種類のコードを生成する。その１つは、エントリ点８０８と領域８１０からなるコードで、これは、実質的に元のコードと同じである。エントリ点８０８から領域８１０を実行することを、通常実行モードと呼ぶ。
【００６４】
第２は、エントリ点８１２と領域８１４からなるコードで、領域８１４は、先読み(Lookahead)領域とも呼ばれる。先読み領域８１４は、入力がほぼ一定であると想定して通常実行モードよりも高速で実行する機能をもつ。エントリ点８１２から領域８１４を実行することを、適応ステップ・モードと呼ぶ。適応ステップ・モードについては、後でフローチャートを参照して、より詳細に説明する。
【００６５】
第３は、エントリ点８１６と領域８１８からなるコードで、領域８１８は、遡及(Lookback)領域とも呼ばれる。遡及領域８１８は、入力が入ってきたときに、その時点に戻って実行する機能を有する。エントリ点８１６から領域８１８を実行することを、回復(recovery)モードと呼ぶ。回復モードについては、後でフローチャートを参照して、より詳細に説明する。
【００６６】
第４は、適応ステップの出力に基づき補間出力を与えるモードで、アイドル・モードと呼ぶ。
【００６７】
コード生成モジュール６０８は、これら４種類のコードの先頭に、先読みディスパッチャ８０６というコードを配置する。先読みディスパッチャ８０６は、入来信号の条件に応じて、上記４つのモードのどれかに処理を割り振る機能をもつ。先読みディスパッチャ８０６については、後でフローチャートを参照して、より詳細に説明する。
【００６８】
コード生成モジュール６０８はさらに、これら４種類のコードの末尾に、アジャスタ８２０のコードを追加する。アジャスタ８２０は、特にアイドル・モードの期間に、時系列に沿った出力値を補間した出力を生成する機能を有する。この補間は、一般的な線形補間でよい。
【００６９】
図６に戻って、このようにして生成されたコードは、コンパイラ６１０で実行可能バイナリコードにコンパイルされ、好適には一旦ハードディスク・ドライブ３１６に保存され、実行環境６１２において、オペレーティング・システムによってメイン・メモリ３０６にロードされ、実行される。
【００７０】
尚、図６の解析モジュール６０６、コード生成モジュール６０８、コンパイラ６１０は、好適には、ハードディスク・ドライブ３１６に格納され、ユーザの操作に応答して、オペレーティング・システムによってメイン・メモリ３０６にロードされ、実行される。
【００７１】
図９は、シミュレーション・システムの一部を示す図である。シミュレーション・システムは、ＳＩＬＳであり、シミュレーションの全ての構成要素を、メイン・メモリ３０６上で実行する。そのような構成要素の例として、図９に示すような、典型的にはエンジン・シミュレータである、連続系シミュレータ９０２と、連続系シミュレータ９０２と協働する、典型的にはＥＣＵエミュレータである、離散系シミュレータ９０４がある。連続系シミュレータ９０２は、連続パルスに応答して駆動され、共有メモリ、ＣＡＮエミュレータなどの通信経路９０６を介して、イベント・メッセージを離散系シミュレータ９０４に送る。離散系シミュレータ９０４は、離散的なイベント・メッセージとして、通信経路９０６を介して、連続系シミュレータ９０２に応答する。
【００７２】
図６の処理によって作成されるプログラムは、図９でいう離散系シミュレータ９０４として動作するものである。
【００７３】
図１０は、図８における先読みディスパッチャ８０６の処理を示すフローチャートである。図１０において、ステップ１００２では、図６の処理によって作成されるプログラム（以下、本実施例に係る離散系シミュレータと呼ぶ）が、イベントが来たかどうかを判断する。ここでイベントが来るとは、図９で、離散系シミュレータ９０４が連続系シミュレータ９０６からイベント・メッセージを受け取ることに相当する。
【００７４】
ステップ１００２でイベントが来ていないと、ステップ１００４に進み、そこで、安定状態かどうかが判断される。ここで、安定状態かどうかは、例えば、図１１のフローチャートで示すような処理で実行することができる。
【００７５】
すなわち、図１１のステップ１１０２では、今回の入力であるInが、前回の入力であるlastに等しいかどうかが、判断される。等しくないと判断されると、ステップ１１０４に行って、counter値が0にセットされ、ステップ１１０６で状態が活動状態と決定され、ステップ１１０８でlastにInが代入されて、判断処理は終わる。
【００７６】
ステップ１１０２で、今回の入力であるInが、前回の入力であるlastに等しいと判断されると、ステップ１１１０で、counter値が1だけ増分される。
【００７７】
ステップ１１１２では、counter値が4以上かどうかが判断され、もしそうなら、所定期間以上同一の入力値が続いたことを意味するので、ステップ１１１４で、状態が安定状態と決定され、ステップ１１０８でlastにInが代入されて、判断処理は終わる。なお、安定状態を決定するためのcounterの4という閾値は、例示的なものであり、システムの環境に応じて、より大きい任意の数字など、適宜選ぶことができる。
【００７８】
ステップ１１１２で、counter値が4以上でないと判断されたなら、同一の入力がまだあまり続いていないことを意味するので、ステップ１１１６で、状態が活動状態と決定され、ステップ１１０８でlastにInが代入されて、判断処理は終わる。
【００７９】
図１０に戻って、このようにしてステップ１００４で状態が活動状態と決定されると、先読みディスパッチャ８０６は、通常実行モードで、図８に領域８１０で示したプログラムを実行する。この場合は、実行速度はもとのプログラムと同一なので、プログラムの実行速度は、特に加速されない。
【００８０】
ステップ１００４で、状態が安定状態と決定されると、ステップ１００６で、
timestamp % Nが0かどうか、すなわち、timestampをNで割った余りが0かどうかが判断される。ここでNは、2以上の適当な整数である。このような判断により、timestampの値に応じて、先読みディスパッチャ８０６は、N回に1回、適応ステップ・プログラムを実行するステップ１００８を呼ぶことになる。
【００８１】
ステップ１００４から、いきなりステップ１００８を呼ばない理由は、一般的に、適応ステップ・プログラムを実行するステップ１００８が比較的重い処理であるので、計算リソースを節約するためである。そこで、ステップ１００６の判断により、ステップ１００８の呼び出しを、N回に1回にしている。但し、実施例によっては、安定状態の決定に応じて毎回ステップ１００８を呼ぶようにしてもよい。
【００８２】
さて、ステップ１００８の適応ステップ・プログラムとは、図８で適応ステップ・モードとして、先読み領域８１４で示したプログラムであり、図１０に示されているように、状態ベクトル１０１０への値を書込みを伴う。状態ベクトル１０１０は、典型的には、メイン・メモリ３０６内にアロケートされた所定のメモリ区画であり、Ｃ言語では、構造体の配列として表記される。ステップ１００８の適応ステップ・プログラムのより詳細な処理を、図１２のフローチャートを参照して説明する。
【００８３】
図１２に示すように、適応ステップ・プログラムは、入力データInと、タイムスタンプtimestampと、状態ベクトル１０１０の次数Mと、状態ベクトルへのポインタを引数とするルーチンまたは関数である。
【００８４】
図１２において、ステップ１２０２では、変数iが0にセットされる。変数iは、構造体の配列である状態ベクトルの要素にアクセスするために使用される。
【００８５】
ステップ１２０４では、iが、状態ベクトル１０１０の次数Mより小さいどうかが判断される。もしそうなら、ステップ１２０６で、次のような処理を行う。
StateVector[i].timestamp = timestamp + i
StateVector[i].state = f(StateVector[i-1].state, In)
【００８６】
上記に見て取れるように、StateVectorは、timestampとstateの変数をもつ構造体の配列である。
【００８７】
ステップ１２０８でiを1だけ増分しつつ、iがMに到達するまで、ステップ１２０６は繰り返し実行される。
【００８８】
iがMに到達すると、ステップ１２０４での判断により、そこで、処理はステップ１２１０に進み、下記の式で、resultが計算される。
result = g(StateVector[M-1].state, In)
【００８９】
ステップ１２１２で、ステップ１２１０での計算の結果得られたresultの値を出力して、処理は終了する。
【００９０】
図１０のフローチャートのステップ１００６に戻って、timestamp % Nが0でないと判断されると、ステップ１０１２に移行して、アイドル・ステップが実行される。
【００９１】
アイドル・ステップ１０１２の基本的な動作は、アジャスタ８２０と協働して、適応ステップ・プログラムの出力に基づき、補間出力を与えることである。
【００９２】
図１３を参照すると、アイドル・ステップにおけるアジャスタ８２０の動作がよりよく理解される。すなわち、適応ステップ１００８は、この実施例では、４タイムススタンプ毎に出力を与える。図１３において、それは、丸印１３０２ａ、１３０２ｂ及び１３０２ｃで示されている。
【００９３】
アジャスタ８２０は、適応ステップ・プログラムの出力を順次記録して、アイドル・ステップ１０１２が呼ばれるタイミングで、記録されている適応ステップ・プログラムの出力の値に基づき、三角で示すように補間出力１３０４を与える。この補間の計算は、線形補間、ラグランジュ補間、最小二乗法補間など、既知の任意の方法で行なうことができる。
【００９４】
図１に示す安定状態においては、このような補間出力１３０４で、実際の出力を代替しても、あまり大きい誤差を生じることはない、と妥当に想定できる。また、補間出力の計算のコストは、適応ステップの出力計算（すなわち、前述のg(StateVector[M-1].state, In)のような計算）よりもコストは小さいので、この点でも処理速度の向上の効果がある。
【００９５】
図１０のフローチャートのステップ１００２に戻って、先読みディスパッチャ８０６が、イベントが来たことを検出すると、ステップ１０１４に行って、そこで、図８で、回復モードとして示されている、遡及領域８１８で示したプログラムを呼び出す。図示されているように、回復プログラム実行のステップ１０１４は、状態ベクトル１０１０の値を参照する。ステップ１０１４の回復プログラムのより詳細な処理を、図１４のフローチャートを参照して説明する。
【００９６】
図１４に示すように、回復プログラムは、入来したイベントのデータの値Inと、タイムスタンプtimestampと、状態ベクトル１０１０の次数Mと、状態ベクトルへのポインタを引数とするルーチンまたは関数である。
【００９７】
ステップ１４０２では、入来したイベントのデータのもつtimestampで以って、状態ベクトルの要素が、関数Lookupによって、ルックアップされる。Lookup(timestamp, StateVector)は、状態ベクトルのエントリの、timestampと等しいかまたは、その前でtimestampに最も近い値をもつ状態ベクトルの要素に格納されている状態の値を返す。それを、RecoveredStateとすると、ステップ１４０４で、次の式によって、新たな内部状態stateが計算される。
state = f(RecoveredState,In)
このf()は、図１２のフローチャートで示したf()と同じものである。
【００９８】
ステップ１４０６では、次の式によって、結果の値resultを得る。
result = g(state, In)
このg()は、図１２のフローチャートで示したg()と同じものである。
【００９９】
ステップ１４０８では、結果の値resultを出力して、処理が終わる。
【０１００】
次に、状態ベクトルに依存しない、回復プログラムの別の実施例について説明する。
現在の状態をstatecurとし、直前の状態をstateprev、直前の入力値をInprevとすると、今までの説明から、下記のような式が成立するのが分かる。
statecur = f(stateprev, Inprev)
これは、次のように書き直すことができる。
stateprev = f-1(statecur, Inprev)
ただし、f-1()は、f()の逆関数である。
【０１０１】
そこで、図１０のフローチャートに戻って、ステップ１００２で新たなイベントが来たと判断されたとき、その新たなイベントの入力値をIn、そのときの状態をstatecurとすると、新たなイベントの入力は最早有効でなくなっている。
【０１０２】
そこで、stateprev = f-1(statecur, In)によって、一旦、１つ前のstateprevを求め、次に、
statecur = f(stateprev, In)によってstatecurを計算しなおすと、statecurは、現在のInに対する適切な状態の値になっている。
【０１０３】
そこで、result = g(statecur,In)を計算することにより、適切なresultが得られる。
【０１０４】
以上、この発明を、特定の実施例に基づき説明してきたが、この発明は、この特定の実施例に限定されず、この技術分野の当業者が自明に思いつく様々な変形、置換などの構成、技法適用可能であることを理解されたい。例えば、特定のプロセッサのアーキテクチャやコンピュータ・システムのプラット・フォームなどに限定されない。
【０１０５】
さらに、上記実施例は、主として、自動車のＳＩＬＳのシミュレーション・システムにおける高速化に関連するものであったが、このような例には限定されず、航空機、ロボットその他の物理システムのシミュレーション・システムに広く適用可能であることも、この技術分野の当業者には明らかであろう。
【符号の説明】
【０１０６】
８０６・・・先読みディスプッチャ
８０８、８１０・・・通常実行モジュール
８１２、８１４・・・適応ステップ・モジュール
８１６、８１８・・・回復モジュール
８２０・・・アジャスタ
【図１】
2010282291.tif 000003
【図２】
2010282291.tif 000004
【図３】
2010282291.tif 000005
【図４】
2010282291.tif 000006
【図５】
2010282291.tif 000007
【図６】
2010282291.tif 000008
【図７】
2010282291.tif 000009
【図８】
2010282291.tif 000010
【図９】
2010282291.tif 000011
【図１０】
2010282291.tif 000012
【図１１】
2010282291.tif 000013
【図１２】
2010282291.tif 000014
【図１３】
2010282291.tif 000015
【図１４】
2010282291.tif 000016