JP5186290B2 - シミュレーション方法、システム及びプログラム - Google Patents

Description

本発明は、自動車などに使用される電子制御ユニット（ＥＣＵ）のテストに関し、より詳しくは、ソフトウェア・ベースでの複数ＥＣＵのテスト及びエミュレーションに関するものである。

自動車は、その初期の時代の２０世紀初頭は、動力としてのエンジンと、ブレーキ、アクセル、ハンドル、トランスミッション、サスペンジョンを含む、機構部品からなっていたが、エンジンのプラグの点火、ヘッドライト以外は、電気的な仕組みはほとんど利用していなかった。

ところが、１９７０年代頃から、大気汚染、石油危機などに備えて、エンジンを効率的に制御する必要性が生じ、このためエンジンの制御に、ＥＣＵが使用されるようになってきた。ＥＣＵは、一般的に、センサからの入力信号を、例えばＡ／Ｄ変換する入力インターフェースと、決められた論理に従ってディジタル入力信号を処理する論理演算部（マイクロコンピュータ）と、その処理結果を、アクチュエータ作動信号に変換する出力インターフェースとから構成される。

いまや、エンジンやトランスミッションなどの制御システム、Anti-lock Breaking System （ＡＢＳ）、Electronic Stability Control （ＥＳＣ）、パワーステアリングだけでなく、ワイパー制御やセキュリティ・モニタリング・システムなどに至るまで、最近の自動車では、機構部品だけでなく、エレクトロニクス部品やソフトウエアが重要な比率を占める。後者に関する開発費は全体の２５％とも４０％とも言われ、ハイブリッド型の自動車では７０％を占める。

電子制御は、ＥＣＵを複数、配置して行われる。ＥＣＵ間は車載ネットワーク、例えば、Controller Area Network （ＣＡＮ） で相互に接続される。また、制御の対象である、エンジンやトランスミッションなどには、それぞれのＥＣＵから直接ワイヤリングして接続する。

ＥＣＵは、小さなコンピュータであり、センサ入力などからの割り込みに応じて動作する。一方、エンジンなどは連続的に機械的動作を行っている。すなわち、コンピュータ系のディジタル・システムと、機械系の物理システムが、自動車という単一システムにおいて、並列に協調動作を行っている。当然、これを支えるソフトウエアは複雑さがますます増大しており、ＥＣＵ単体で動作を検証するだけでなく、複数を同時に検証する仕組みの実現が急務である。

ここで、ＥＣＵに信号を入力するセンサには、エンジンの温度などを計測する温度センサ、エンジンに吸入される圧力を推定するための圧力センサ、アクセスペダルの踏み量を測定するスロットル・ポジション・センサ、ステアリング舵角センサ、車高センサ、回転速度センサ、ノックセンサ、加速度センサ、流量センサ、酸素センサ、希薄空燃比センサなどがある。

一方、ＥＣＵの出力信号によって駆動されるアクチュエータには、電磁ソレノイド及びモータ等がある。ソレノイドは例えば、エンジンのインジェクタ、トランスミッションのシフト・コントロール、ブレーキのバルブ制御、ドアロックなどに使用される。

モータは、主としてサーボ機構として、エンジンのスタータ、エンジンのフューエル・コントロール、ブレーキの油圧ポンプ、舵角制御、ステアリング、ワイパ、パワーウインドウ、シートベルト、エアバックなどに使用される。

このようなテストにために従来行われている技法として、ＨＩＬＳ(Hardware In the Loop Simulation)がある。特に、自動車全体のＥＣＵをテストする環境は、フルビークルＨＩＬＳと呼ばれる。フルビークルＨＩＬＳにおいては、実験室内で、本物のＥＣＵが、エンジン、トランスミッション機構などをエミュレーションする専用のハードウェア装置に接続され、所定のシナリオに従って、テストが行われる。ＥＣＵからの出力は、監視用のコンピュータに入力され、さらにはディスプレイに表示されて、テスト担当者がディスプレイを眺めながら、異常動作がないかどうか、チェックする。

しかし、ＨＩＬＳは、専用のハードウェア装置を使い、それと本物のＥＣＵの間を物理的に配線しなくてはならないので、準備が大変である。また、別のＥＣＵに取り替えてのテストも、物理的に接続し直さなくてはならないので、手間がかかる。さらに、本物のＥＣＵを用いたテストであるため、テストに実時間を要する。従って、多くのシナリオをテストすると、膨大な時間がかかる。また、ＨＩＬＳのエミュレーション用のハードウェア装置は、一般に、非常に高価である。

そこで近年、高価なエミュレーション用ハードウェア装置を使うことなく、ソフトウェアで構成する手法が存在する。この手法は、ＳＩＬＳ(Software In the Loop Simulation)と呼ばれ、ＥＣＵに搭載されるマイクロコンピュータ、入出力回路、制御のシナリオなどを全て、ソフトウェア・シミュレータで構成する技法である。これによれば、ＥＣＵのハードウェアが存在しなくても、テストを実行可能である。

ここで、ＥＣＵエミュレータと、物理装置シミュレータ、特にエンジン・シミュレータとが協働する例について説明する。なお、以下、便宜上、ＥＣＵエミュレータとエンジン・シミュレータではなく、実際のＥＣＵとエンジンの間の動作として説明する。先ず、クランクシャフトの回転にあわせてピストンが上死点に達する３０度前のタイミングで、エンジンは、ＥＣＵに割り込みを引き起こす。その割り込みを受けたＥＣＵは、燃料噴射のタイミングを計算して、その時刻に噴射の指示を出す。それを受けたエンジンは、燃料を噴射して、引き続き、惰性で回転するクランクの動作を計算する。そして、ピストンが再び上死点の３０度前に達したら、エンジンは、ＥＣＵに割り込みを引き起して、ＥＣＵに知らせる。すると、ＥＣＵは、点火のタイミングを計算して、その時刻にエンジンに指示を出す。これに応じて、エンジンは、シリンダー内の燃料を爆発させて、新たな回転の動作を計算し始める。このような動作が繰り返し行われる。

このように、エンジンとＥＣＵが交互に動く動作は、クリティカル・パスとして捉えられる。従って、自動車の離散イベントを並列にシミュレーションする場合には、このようなクリティカル・パスの存在によって、計算性能の観点からみて、並列性を十分に発揮しえない。従って、マルチプロセッサ・システムのコンピュータを用いたフルビークルＨＩＬＳにおいて、複数のＥＣＵエミュレータにそれぞれ、個別のＣＰＵを割り当てたとしても、最悪の場合、１個のＣＰＵで、複数のＥＣＵエミュレータ及びエンジン・エミュレータをシリアルに計算する程度の性能しかでないことがある。

複数の論理プロセスを並列に矛盾なく動作させるための、もっとも簡単な方法は、全体の号令にあわせて各論理プロセスを動作させることである。しかし、この方法では、割り込みなどのイベントが発生しない時刻でもすべて同期処理を行う必要があるため、処理の負荷が大きく、また、処理が遅くなる。

複数の論理プロセスを非同期的に並列に動作させる、離散イベントのシミュレーションでは、プロセス間の通信は、タイム・スタンプの付いたイベントを、メッセージとして送受信することによって行われる。このとき、タイム・スタンプは、シミュレーション・システム全体で共通の時刻が記録される。このような時刻をシミュレーション時計と呼ぶことにすると、シミュレーション時計のどの時点で処理を行うかは、各論理プロセスで独立で、必ずしも一致する必要はない。但し、各論理プロセスが協働して処理を行う場合は、必ずタイム・スタンプの順序で行う必要がある。そのように処理を進める限り、全体をシリアルに処理する場合と同じように処理を進めることができる。

非同期処理の１つに、保守的同期(conservative synchronization)がある。この方法では、必ず、タイム・スタンプの古い順位のイベントを処理する。

保守的同期の例を説明すると、ある論理プロセスに、２つの上流プロセスからのキューがあり、その一方に、時間t₁をもつイベントと、時間t₂をもつイベントが届いているとする。時間t₁の方が時間t₂よりも古いとする。また、他方のキューには何も届いていないとする。すると、その論理プロセスは、時間t₁をもつイベントから順に処理していけばよさそうなものだが、時間t₁よりも古い時間をもつイベントが上流から、他方のキューに届く可能性があり、すなわち、時間t₁が最古であることが保証されないため、処理を進めることができない。特に、論理プロセス間に送受信のループがある構成では、このような構成ではデッドロックを引き起こすことがある。

このような状況を回避するために、空メッセージ(null message)を利用した方法が知られている。この方法では、上流の論理プロセスが、ある時刻まではイベントを発生することがないことを示すために、その時刻をもつ空メッセージを、下流の論理プロセスに送る。そのような時刻は、タイム・スタンプ上の下位境界(lower bound on the timestamp:LBTS)と呼ばれる。このような空メッセージを受け取った下流の論理プロセスは、届いているイベントのタイムスタンプと、そのLBTSとを比較し、それより古いタイム・スタンプのイベントを確定とみなして処理することができる。

空メッセージを利用しない方法として、楽観的同期(optimistic synchronization)と呼ばれる手法が考え出された。この方法では、ある論理プロセスに、２つの上流プロセスからのキューがあり、時間t₁をもつイベントと、時間t₂をもつイベントが届いていて、時間t₁の方が時間t₂よりも古いとするとき、且つ他方のキューに何も届いていないときに、とりあえず時間t₁をもつイベントを最も古いと仮定して処理を進める。その後で、時間t₁よりも古い時刻をもつイベントが他方のキューに届いたら、先の時間t₁のイベントを発端とする一連の処理を、遡及メッセージ(reverse message)を送ることによって順に取り消してから、新たに、時間t₁よりも古い時刻をもつイベントを処理する。この方法では、論理プロセスから出力されるイベントは、一時的に必ずしもタイム・スタンプどおりではないが、ロールバックにより、最終的には、タイム・スタンプどおりになることが保証される。

このような方法で、デッドロックを回避しつつ、正しい順序でイベントが送り出されるようにすることができる。しかし、このような方法では、依然として処理の直列化は回避できず、よって処理はやはり、高速化できない。

特開平６−１６１９８７号公報は、ＥＣＵハードウェアを擬似的に実現して、ソフトウェアによる実機評価を可能ならしめることを目的とするものであって、マトリックス・スイッチを切り替えることによって、所望の機能のハードウェアをシミュレートすることを開示する。

特開平１１−１４５０７号公報は、車両全体のロジックを机上で検証できるようにすることを課題とするものであり、エンジン制御模擬装置（ＥＣＵ）と、車両制御模擬装置からなる車両シミュレーション装置を開示する。ＥＣＵは、エンジンモデルの制御パラメータを演算し、その演算結果を車両制御模擬装置に送信する。車両制御模擬装置は、ＥＣＵから送られてくる制御パラメータを用いて車両モデルの各部の状態量を演算してその演算結果をＥＣＵに返送する。車両モデルは、ドライバモデル、吸気系モデル、燃料系モデル、燃焼系モデル、エンジン温推定モデル、駆動系モデル、触媒モデル、Ａ／Ｆセンサモデル、リアＯ₂ センサモデルから構成されている。ドライバモデルは、目標車速の変化パターンを入力する車速パターン入力手段を有する。

しかし、これらの文献には、論理プロセス間で同期をとる技術には言及はない。

特開平６−１６１９８７号公報 特開平１１−１４５０７号公報

以上のように、上記従来技術を組みあわせても、フルビークルＳＩＬＳで、動作の直列性に拘束されて、高速にシミュレーションを行うことは困難である。

従って、この発明の目的は、フルビークルＳＩＬＳなどのシミュレーション・システムを高速化することにある。

この発明の別の目的は、フルビークルＳＩＬＳなどのシミュレーション・システムで、マルチプロセッサ・システムなどの高性能のコンピュータの能力を効率的に利用することを可能ならしめることにある。

本発明によれば、必須ではないが、好適にはマルチＣＰＵのワークステーションが用意される。また、各ＥＣＵのソフトウェア・エミュレータが用意される。一般的には、ＥＣＵのソフトウェア・エミュレータは、そのＥＣＵのメーカから入手可能である。

各ＥＣＵのソフトウェア・エミュレータは、好適には、マルチＣＰＵのワークステーション上で走るように、ワークステーションのオペレーティング・システムの所定のレイヤとインターフェースする。各ＥＣＵのソフトウェア・エミュレータには、好適には、マルチＣＰＵのうちの各々のＣＰＵが割り当てられ、以って、各ＣＰＵによって、各ＥＣＵエミュレータは独立に動作可能である。ＥＣＵの数よりもＣＰＵの数が少ない場合は、１つのＣＰＵに、複数のＥＣＵエミュレータが割り当てられる。いずれにしても、オペレーティング・システムは、各ＥＣＵエミュレータ毎に１つのプロセスを割り当て、以って、各ＥＣＵエミュレータは、固有の異なるクロックで動作しているように、エミュレーションを行うことができる。すなわち、各ＥＣＵエミュレータは、異種ＥＣＵであってよい。

各ＥＣＵエミュレータには、ワークステーションのメモリの一部が、内部処理用のプライベート・メモリとして割り当てられる。さらに、ＥＣＵエミュレータは、ワークステーションの共用メモリとして割り当てられた箇所にもアクセス可能であり、この共用メモリを介して、各ＥＣＵエミュレータは、互いにデータをやりとりしたり、同期したり、通信したりすることが可能である。あるいは、ＥＣＵエミュレータは、ＣＡＮ(controller area network)エミュレータで接続してもよい。

これらのＥＣＵエミュレータから入力を受け取る、エンジン・シミュレータ、トランスミッション・シミュレータなどの、物理装置シミュレータが用意され、やはりワークステーションの共用メモリ、またはＣＡＮ(controller area network)エミュレータで、ＥＣＵエミュレータと接続される。

本発明によれば、各ＥＣＵエミュレータは、投機的にエミュレートされる。すなわち、ここで、ＥＣＵエミュレータや各物理装置シミュレータを論理プロセスと呼ぶことにすると、本発明によれば、クリティカル・パスを作らずに、各論理プロセスをできるだけ並列に実行させるために、各論理プロセスにおいて、入力イベントが届いていない場合でも、入力を予測して処理が進められる。例えば、タイム・スタンプt₁のイベントと、タイム・スタンプt₂のイベントを処理した後は、今までの入力から、タイム・スタンプt₃のイベントが来ると予測して、その処理を先行投機的に実行する。

このような投機的実行により、他の論理プロセスの出力を待つことなく、先行して処理を行うことにより、処理の並列性が高められる。そうして、もし遅れて受信する実際の入力と、予測して投機実行したときの入力が一致していない場合には、投機実行が失敗だったとして、その前の時刻に状態が戻され、その実際の入力に基づき、処理が再実行される。

尚、このような投機実行は、入力の予測が容易である、自動車などの離散イベント・シミュレーションに特に有効である。

この発明によれば、投機的シミュレーションの技法により、特に自動車などの離散イベント・シミュレーションを高速化できる、という効果が得られる。

以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。

本発明を実現するための構成を説明する前に、その前提として、ＥＣＵについて説明する。ＥＣＵは、一般的に、センサからの入力信号を、例えばＡ／Ｄ変換する入力インターフェースと、決められた論理に従ってディジタル入力信号を処理する論理演算部（マイクロコンピュータ）と、その処理結果を、アクチュエータ作動信号に変換する出力インターフェースとから構成されるものである。

この発明は、説明の便宜上、以下では、自動車のＥＣＵに関連して説明するが、それには限定されず、航空機、ロボットなどその他のＥＣＵをもつメカトロニクス機構全般に適用可能であることを理解されたい。

ＥＣＵは、周辺や環境状態、エンジンなどの駆動機構の状態、及び人間による指示操作の内容をセンサで検出して、信号として入力する。具体的には、水温センサ、吸気温センサ、過給圧センサ、ポンプ角センサ、クランク角センサ、車速センサ、アクセル位置センサ、Ａ／Ｔシフト・ポジション、スタータ・スイッチ、エアコンＥＣＵなどからの信号がある。

ＥＣＵは、これらの信号を入力して、電磁スピル弁、フュエル・カット・ソレノイド、タイミング・コントロール・バルブ、吸気絞りＶＳＶ、グロー・プラグ・リレー、タコメータ及びエアコン・リレーなどを駆動する信号を出力しする。

１つのＥＣＵが複数の異なる機構を制御するための駆動信号を出力するようにすることは不可能ではないが、例えば、エンジンとエアコンのように、応答性やその制御の厳密性が異なるものを単一のＥＣＵで制御することは合理的でなく、従って、一般的に自動車にＥＣＵは複数個設けられる。

図１は、ＥＣＵの典型的な制御である、フィードバック閉ループ系の例を示す図である。すなわち、図１において、ある目標の信号が、ＥＣＵであるコントローラ１０２に入力され、ＥＣＵは、目標の信号を内部処理することによって、駆動信号を出力し、制御対象モデルである、エンジンなどのプラント１０４を駆動し、プラント１０４の出力は、センサ１０６を介して、コントローラ１０２の入力にフィードバックされる。

ここで目標信号として与えられるのは、例えば、スロットル開度、アイドル・コントロール、ブレーキ力、シフト、スタータＯＮ・ＯＦＦ、バッテリ電圧、インジェクション通電時間、インジェクション通電回数、デポジット、ドウェル角、進角値、吸気完了フラグ、点火完了フラグ、大気圧、車両重量、転がり抵抗係数、道路勾配、粘着係数、吸気温、などのパラメータである。

また、センサ信号としてフィードバックされるのは、スロットル開度、吸気圧力、吸入空気量、シフト、エンジン回転数、車速、排気温、Ｏ_２、冷却水温、空燃比、ノック、点火異常、などである。

ＥＣＵが制御する対象は、ニュートンの力学方程式で解かれる、機構系システムであったり、電気回路の応答方程式で解かれる、電気駆動回路であったり、それらの組み合わせであったりする。これらは、基本的に微分方程式であり、制御工学によれば、ラプラス変換によって応答関数に変換されて、記述することができる。

図２は、そのような応答関数による記述の例である。図２で破線２０２で囲った箇所が、図１のコントローラ１０２に対応し、破線２０４で囲った箇所が、図１の制御対象モデル１０４に対応し、センサ１０６が、ブロック２０６に対応する。なお、図２は、応答関数による表現の一例であって、特に本発明を限定する意図はないことを理解されたい。

さて、例えば、ＥＣＵが制御する対象が、ニュートンの力学方程式で解かれる、機構系システムであるとする。すると、ある時点のＥＣＵの制御出力は、その機構系システムの可動部分の位置及び速度という内部状態変数をもち、その時点の入力だけでは決まらない。そのことは、電気回路にもあてはまり、電気回路のキャパシタに残っている電荷の量や、コイルのインダクタンスによる磁力などの内部状態変数がやはりある。

従って、ＥＣＵは、図３に示すように、入力ｕに対して、その内部状態ｘを勘案した値ｙを出力することになる。

さて、前述したＳＩＬＳのようなテストの目的で、自動車部品メーカーは、自社が提供する機器のＥＣＵのソフトウェア・エミュレータを提供する。すなわち、図２に示すような機能を、アセンブラまたはＣなどの言語が書かれたコードをアセンブリまたはコンパイルした実行可能プログラムにより、純粋にソフトウェア的に実現する。

さて、本発明では、ＥＣＵのソフトウェア・エミュレータの内部状態を取り出して利用する。ソフトウェア・エミュレータによっては、内部状態が取り出し可能である場合と、そのままでは、内部状態が取り出し可能でない場合がある。

そこで、ＥＣＵのソフトウェア・エミュレータの内部状態がそのままでは、内部状態が取り出し可能でない場合、ソースコード解析ツールによって、次のような処理を行う。

もし、ＥＣＵのソフトウェア・エミュレータのソースコードが入手可能であるならそれをそのまま利用し、実行可能バイナリ・ファイルしかなければ、所定のツールで、逆アセンブルまたは逆コンパイルする。そうして、ＥＣＵのソフトウェア・エミュレータのソースコードに対して、データーフロー解析という技法を適用して、ソースコードを基本ブロックに分割する。基本ブロックとは、ソースコードを、複数の制御が合流するところ、または、制御が複数に分岐するところで分断した、各々の部分のことである。このような基本ブロックをノードとして、その分岐の制御の流れのリンクで接続すると、有向グラフ構造になる。これは特に、制御フローグラフとも呼ばれる。制御フローグラフは、始点ノードと終点ノードをもち、プログラムで実行され得るノードは全て、始点ノードからの有効エッジをもつ。基本ブロックのうち、exit()やreturnなどのステートメントを含む制御の末端ノードは全て、終点ノードへの有効エッジをもつ。

次に、制御フローグラフの始点ノードと終点ノードの可能な全てのパスに対して、Use/Def解析を行う。ここで、Useとは、ある変数が、別の変数に値をストアするために使用される場合をいう。典型的には、代入式の右辺である。Defとは、ある変数に、値がストアされる場合をいう。典型的には、代入式の左辺である。

この場合、個々のパス毎に、Defの前あるいは、DefなしでUseされている変数、すなわち未定義参照変数があるかどうかがチェックされ、もし未定義参照変数があると、その変数名は一旦保存される。

こうして、全てのパスがスキャンされた後に保存されている変数名を用いて、後述するように、ラッパ(wrapper)コードが生成される。

ところで、実行フローのスキャンと、Use/Def解析は、データーフロー解析という技法を用いることによって、より効率的に実行することができるので、以下、それについて説明する。

その第１ステップは、各基本ブロックにおけるdefリストの計算である。具体的にはプログラム全体で使用される変数のリストを１ビットで表現し、各基本ブロックごとに定義される変数を１されないものを０としたビットベクタで表現する。

その第２ステップは、プログラム全体の到達可能なdefリストの計算である。すなわち、各基本ブロックでは、複数の入力がある場合には論理積（ＡＮＤ）してから，自身への入力とする。自身からの出力は、その入力と、自身で定義したdefリストの論理和（ＯＲ）をとり、後続の基本ブロックに渡す。実行していく順番は、制御フローグラフ上での深さ優先順序が効率的である。

第３ステップは、クロージャ解析アルゴリズムにより、到達可能なdefリストのクロージャを求めることである。そして、上記第２ステップを、全ての基本ブロックの出力defリストが変化しなくなるまで、繰り返す。ここで、クロージャとは、環境と結び付けられた値のことである。

第４ステップは、未定義変数の使用の発見である。すなわち、各基本ブロックの入力defリストが０として表現された変数が、useとして使用されているものを検出する。

なお、データフロー解析のより詳しい説明については、Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman, "Compilers Principles, Technologies, and Tools", Addison-Wesley Publishing Company, 1986, p. 608-633などを参照されたい。

さて、例えば、元のＥＣＵシミュレーション・ソースコードが、関数 Func(x,y,z) であらわされるとする。また、未定義参照変数として、a, bが登録されていたとする。

すると、例えば、_Func(x,y,z,_a,_b)という関数が用意され、
_Func(x,y,z,_a,_b)
{
a = _a;
b = _b;
Func(x,y,z);
_a = a;
_b = b;
return;
}

_Func(x,y,z,_a,_b)
{
a = _a;
b = _b;
の部分のところを、入力用ラッパコードと呼び、
_a = a;
_b = b;
return;
}
の部分のところを、出力用ラッパコードと呼ぶ。

なお、 Func(x,y,z); のところは、関数呼び出しではなく、インライン展開でもよい。このような関数_Func(x,y,z,_a,_b)を、_a,_bに適当な値を入れて呼び出すことにより、Func(x,y,z)の内部状態をセットすることができ、また、_Func(x,y,z,_a,_b)を呼び出した結果、_a,_bに、処理後の内部状態の値がセットされるので、必要に応じて、それらの値を別途保存するなど、利用可能である。このようにラッパコードが付されたソースコードは、実行可能プログラムを生成するために、コンパイルまたはアセンブルされる。

また、Ｃ＋＋など、特定の処理言語の仕様によっては、_Func(x,y,z,_a,_b)でなく、_Func(x,y,z,&_a,&_b)のように、参照演算子&をつけて関数に引数として与える必要があることもある。

こうして、内部状態あるいは、内部変数を取り出すことができるようになった後のＥＣＵのソフトウェア・エミュレータを図式的に、図４に示す。そこに示すように、ＥＣＵのソフトウェア・エミュレータ５０２は、内部ロジックfを示す部分と、内部状態または状態変数ｘとに好都合に分離される。

すると、内部ロジックfを用いて、出力y = f(t,x,u, ...) と記述することができる。ここでtは、時間である。また、状態変数ｘに係るコードが分離されたことによって、任意の時点、すなわち典型的には出力がなされるタイミングで、状態変数ｘと、好ましくは入力uも、状態リポジトリ５０４として、ハードディスクドライブに書き出すことができる。

状態変数ｘに係るコードを分離した効果はこれだけではない。すなわち、矢印５０６で示すように、ソフトウェア・エミュレータ５０２には、任意の時点で、状態変数ｘをセットすることができる。これによって、状態リポジトリ５０４から入力と状態変数ｘを選んでセットすることにより、ＥＣＵのソフトウェア・エミュレータ５０２を、その状態変数ｘが状態リポジトリ５０４に書き出された任意の時点の状態に戻して、そこから計算をやり直させることができる。

次に、図５を参照して、本発明を実施するために使用されるコンピュータのハードウェアについて説明する。図５において、ホスト・バス６０２には、複数のＣＰＵ０ ６０４ａ、ＣＰＵ１ ６０４ｂ、ＣＰＵ２ ６０４ｃ、ＣＰＵ３ ６０４ｄが接続されている。ホスト・バス６０２にはさらに、ＣＰＵ０ ６０４ａ、ＣＰＵ１ ６０４ｂ、ＣＰＵ２ ６０４ｃ、ＣＰＵ３ ６０４ｄの演算処理のためのメイン・メモリ６０６が接続されている。

一方、Ｉ／Ｏバス６０８には、キーボード６１０、マウス６１２、ディスプレイ６１４及びハードティスク・ドライブ６１６が接続されている。Ｉ／Ｏバス６０８は、Ｉ／Ｏブリッジ６１８を介して、ホスト・バス６０２に接続されている。キーボード６１０及びマウス６１２は、オペレータが、コマンドを打ち込んだり、メニューをクリックするなどして、操作するために使用される。ディスプレイ６１４は、後述する本発明に係るプログラムをＧＵＩで操作するための画面イメージを表示するために使用される。

この目的のために使用される好適なコンピュータ・システムのハードウェアとして、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｘがある。その際、ＣＰＵ０ ６０４ａ、ＣＰＵ１ ６０４ｂ、ＣＰＵ２ ６０４ｃ、ＣＰＵ３ ６０４ｄは、例えば、インテル（Ｒ）Ｃｏｒｅ ２ ＤＵＯであり、オペレーティング・システムは、Ｗｉｎｄｏｗｓ（商標）Ｓｅｒｖｅｒ ２００３である。オペレーティング・システムは、ハードティスク・ドライブ６１６に格納され、コンピュータ・システムの起動時に、ハードティスク・ドライブ６１６からメイン・メモリ６０６に読み込まれる。

なお、本発明を実施するために使用可能なコンピュータ・システムのハードウェアは、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｘに限定されず、ＥＣＵエミュレータ・プログラムを走らせることができるものであれば、任意のコンピュータ・システムを使用することができる。オペレーティング・システムも、Ｗｉｎｄｏｗｓ（Ｒ）に限定されず、Ｌｉｎｕｘ（Ｒ）、Ｍａｃ ＯＳ（Ｒ）など、任意のオペレーティング・システムを使用することができる。さらに、ＥＣＵエミュレータ・プログラムを高速で動作させるために、ＰＯＷＥＲ（商標）６ベースで、オペレーティング・システムがＡＩＸ（商標）のＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｐなどのコンピュータ・システムを使用してもよい。

ハードディスク・ドライブ６１６にはさらに、テストするための複数のＥＣＵエミュレータ・プログラム、及び、それら複数のＥＣＵエミュレータ・プログラムを協働させてテストするための、本発明に係るプログラムが格納され、キーボード６１０及びマウス６１２によって起動操作可能である。

好適には、フルビークルＳＩＬＳを実現するために、１台の自動車で使われるすべてのＥＣＵのエミュレータ・プログラムが、ハードティスク・ドライブ６１６に保存されている。そのＥＣＵのエミュレータ・プログラムが、そのままでは内部の状態変数を取り出せないものてある場合は、上述したラッパコードを被せることにより、予め、状態変数をセット及び取り出し可能としておくものとする。

ハードティスク・ドライブ６１６にはさらに、後述するＥＣＵエミュレータ・プログラムのためのスケジューラ、エンジン、トランスミッション、ステアリング、ワイパなどの物理装置シミュレータ・プログラム、全体のシステムの入力を同期させるためのグローバル・スケジューラ及び、登り坂道、高速道路、つづら折道などの様々な、テストのためのシナリオを格納したシナリオ・ジェネレータのプログラムも格納されている。

なお、ここでの「エミュレータ」と、「シミュレータ」の用語の使い分けであるが、もともとの、別のプロセッサで動くことを想定して書かれていたＥＣＵのコードを、ＣＰＵ０〜ＣＰＵ３などをターゲットとして動くようにすることを、エミュレーションと呼び、それを行うプログラムを、エミュレータと呼ぶ。一方、エンジンなどの物理的システムの動作を仮想計算するシステムを、シミュレータと呼ぶ。

次に、図６を参照して、本発明のシミュレーション・システムの機能論理ブロック図を説明する。図６において、共有メモリ７０２は、実際は、図５に示すメイン・メモリ６０６の一部であってよい。共有メモリ７０２には、ＥＣＵエミュレータ・プログラム７０４ａ、７０４ｂ、・・・７０４ｎと、スケジューラ７０６と、物理装置シミュレータ・プログラム７０６ａ、・・・７０６ｍが論理的に結合されている。

グローバル・スケジューラ７０８は、ＥＣＵエミュレータ・プログラム７０４ａ、７０４ｂ、・・・７０４ｎ及び物理装置シミュレータ・プログラム７０６ａ、・・・７０６ｍの間のイベントのタイム・スタンプに基づき、それらのイベントの間の一貫性を維持するように動作する。グローバル・スケジューラ７０８のより詳しい動作は、後述する。

ＥＣＵのエミュレータ・プログラム７０４ａ、７０４ｂ、・・・７０４ｎは、それぞれ、エンジン、ブレーキ、トランスミッション、ステアリングなど、車の異なる部分の制御に対応するもので、それぞれが異なる速度のクロックで動作するので、対応するＥＣＵのエミュレータ・プログラムも、それに比例するクロック比で動作するものとする。

一例として、スレッドを作成いることにより、複数のＣＰＵに、ＥＣＵのエミュレータ・プログラムを割り当てるコードを、Ｃ言語を例にとって示す。
void* ecu_wrapper(void* parm)
{
...
/* define state_repository */
...
LOOP_BEGIN:
...
/* ECUのユニット処理を行う */
LOOP_END:
...
}

上記のようなコードを用意しておいて、
pthread_t thread_id;
pthread_attr_t thread_attr;
pthread_attr_init(&thread_attr);
pthread_create(&thread_id, thread_attr, ecu_wrapper, NULL);
pthread_attr_destroy(&thread_attr);
とすると、オペレーティング・システムがスレッドを生成して、それをＥＣＵのエミュレータ・プログラムに割り当てる。物理的には、そのスレッドは、ＣＰＵ０〜ＣＰＵ１のどれかに割り当てられるが、それはオペレーティング・システムに任され、エミュレータ・プログラムにとっては、透過的である。
このような割り当て処理は、ＥＣＵエミュレータ・プログラム７０４ａ、７０４ｂ、・・・７０４ｎ各々に個別に行われる。

なお、図６に示した論理構成では、ＥＣＵエミュレータ・プログラム７０４ａ、７０４ｂ、・・・７０４ｎ、物理装置シミュレータ・プログラム７０６ａ、・・・７０６ｍ及びグローバル・スケジューラ７０８は、共有メモリ７０２を使用してデータを交換するが、代わりに、ＣＡＮ(controller area network)エミュレータを使用してもよい。

図示しないが、図６の構成には、登り坂道、高速道路、つづら折道などの様々な、テストのためのシナリオを格納したシナリオ・ジェネレータも接続される。

図７は、ＥＣＵエミュレータ・プログラム７０４の内部の、より詳細な論理ブロック図を示す。ここでは、ＥＣＵエミュレータ・プログラム７０４ａ、７０４ｂ、・・・７０４ｎなどを、総称的に、ＥＣＵエミュレータ・プログラム７０４として説明する。

制御ロジック・モジュール８０２は、いわゆるＥＣＵエミュレータの本来のロジックを含む本体である。

論理状態リポジトリ８０４は、前述したラッパコード付加の方法で、制御ロジック・モジュール８０２から取り出した内部状態変数を順次保存する機能をもつ。

ローカル・スケジューラ８０６は、論理状態リポジトリ８０４に保存されている内部状態変数を、制御ロジック・モジュール８０２に書き戻すことにより、ＥＣＵエミュレータ・プログラム７０４を所望の状態に戻す機能を持つ。論理状態リポジトリ８０４及びローカル・スケジューラ８０６は、前述した、ＥＣＵエミュレータに付加されたラッパコード中に含ませることができる。

なお、制御ロジック・モジュール８０２には、共有メモリ７０２から、通信インターフェース・モジュール８０８を介して、イベント入力が提供される。

図示しないが、図７のＥＣＵエミュレータ７０４は、入力イベントを一旦格納するためのキューをもつ。キューは、制御ロジック・モジュール８０２内に設けてもよいし、メイン・メモリ６０６内の専用のプライベート・メモリ領域内に設けてもよい。

例えば、エアコンＥＣＵの出力は、エンジンＥＣＵに入力される。エアコンの駆動状態に応じて、エンジンの回転数を変え、以って発電量を調整する必要があるからである。

通信インターフェース・モジュール８０８は、制御ロジック・モジュール８０２からの出力を、共有メモリ７０２または、ＣＡＮ(controller area network)エミュレータ（図示しない）に送出する。

次に、図８のフローチャートを参照して、ＥＣＵエミュレータの処理について処理を説明する。ここでの処理の大部分は、図７に示すローカル・スケジューラ８０６によって、主に行われる。図８のステップ９０２では、キューに、他の論理プロセスからイベントが到来しているかどうかが判断される。もしキューにイベントがあると、ステップ９０４では、最も古いイベントeが取り出される。このイベントeのタイム・スタンプをtとする。

ステップ９０６では、t = t_kをもつエントリが、ロールバック表中にあるかどうかが判断される。ロールバック表とは、図９に示すように、タイム・スタンプ、入力イベント、出力イベント、内部状態、及び確定フラグからなり、後述する処理により、論理状態リポジトリ・モジュール８０４によって、好適にはそのＥＣＵエミュレータに割り当てられた、メイン・メモリ６０６中の領域に書かれる。メイン・メモリ６０６ではなく、ハードディスク・ドライブ６１６に書かれてもよい。

また、図９から見て取れるように、ロールバック表は、２通りのエントリをもつ。１つは、入力イベントのエントリであり、タイム・スタンプの欄と、入力イベントの欄のみが有効である。

もう１つは、出力イベントのエントリであり、出力のタイム・スタンプの欄と、出力イベント、そのときの内部状態、及び確定フラグである。ロールバック表に内部状態を保持することは、途中から計算を再開するために有利である。なお、前述したラッパ・コードの技法により、もともと内部状態を暗にもつエミュレータの論理を、内部状態を状態変数として外部に取り出した論理に変更することができる。

ロールバック表中に、t = t_kをもつエントリがあると、そのエントリをe_kとすると、e = e_kであるかどうかが、ステップ９０８で判断される。この比較は、eやe_kが浮動小数点数であるとすると、ある桁以下を切り捨てて、概数で比較するようにしてもよい。ステップ９０８での判断が肯定的である、ということは、先の投機的実行が成功であった、ということを意味をする。そこで、処理は、最初のステップ９０２に戻る。

ステップ９０６で、t = t_kをもつエントリが、ロールバック表中にないと判断されると、ステップ９１０で、確定時間Ｔに戻って、それ以降の時間をもつロールバック表中のエントリが削除される。図９では、点線以下のエントリである。尚、確定時間Ｔは、後述するグローバル・スケジューラ７０８の処理によって通知されたものである。

ステップ９１２では、時刻tとイベントeから、新しいエントリが作成され、それがロールバック表中に挿入される。

ステップ９１４では、確定エントリの内部状態を使って、制御ロジック・モジュール８０２によって、新たなイベント処理が行われる。ここでいう内部状態とは、図５に、状態変数として示されているものである。

ステップ９１６では、そのイベント処理の結果として生成された出力イベントが、ロールバック表に挿入される。ステップ９１８では、その出力イベントが、通信インターフェース・モジュール８０８を介して、それは、所定の物理装置シミュレータに送られる。この送り方であるが、共有メモリ方式ならば、特定のメモリのアドレスに書いてシグナルされるし、ＣＡＮエミュレータ方式の場合、送り出すメッセージに、所定の宛先を含むヘッダを付けることになる。このような処理は、図７に示す通信インターフェース・モジュール８０８によって、行われる。そうして処理は、ステップ９０２に戻る。

ステップ９０２で、キューにイベントがないと判断されると、ステップ９２０では、新しい入力イベントが予測される。例えば、エンジン・シミュレータ用のＥＣＵエミュレータの場合、ほぼ周期的にイベントが入来すると予測されるので、その予測に従って、ステップ９２２で、その予測された新しいイベントをキューに入れ、処理がステップ９０２に戻る。

尚、キューにイベントが到着しない間に、連続して予測に基づく処理を進めると、確定しないエントリがロールバック表を占めて、そのサイズが巨大になることがある。それを防止するために、ロールバック表中の未確定のエントリの数に上限を設けて、それを超えないようにシステム的に調節する。また、確定したエントリは、最後の一つを除いて破棄することにより、不要なエントリが、ロールバック表のサイズを圧迫することがないようにする。

図１０に示すように、グローバル・スケジューラ７０８は、論理プロセスＬＰ＃１〜ＬＰ＃Ｎ毎にキューＱ１〜Ｑｎをもつ。論理プロセスとは各々、図６に示すＥＣＵエミュレータ＃１〜＃ｎ、物理装置シミュレータ＃１〜＃ｍ、のどれかである。

キューＱ１〜Ｑｎには、対応する論理プロセスＬＰ＃１〜ＬＰ＃Ｎから、随時にイベントが入来し、入来したイベントは、キューに一旦格納される。グローバル・スケジューラ７０８は、キューＱ１〜Ｑｎに格納されているイベントに基づき、確定イベントと、確定時間を出力する。

図１１は、そのためのグローバル・スケジューラ７０８の処理を示すフローチャートである。ステップ１２０２で、グローバル・スケジューラ７０８は、どれかのキューＱ１〜Ｑｎ（図１０）に、新しいイベントが到来するのを待つ。

ステップ１２０４では、空のキューにイベントが届いたかどうかが判断され、そうでなければ、処理は、ステップ１２０２に戻る。

ステップ１２０４で、空のキューにイベントが届いたと判断されると、ステップ１２０６に行って、そこで、すべてのキューＱ１〜Ｑｎが少なくとも１つのイベントをもつかどうかが判断される。そうでなければ、やはり処理は、ステップ１２０２に戻る。

ステップ１２０６で、すべてのキューＱ１〜Ｑｎが少なくとも１つのイベントをもつと判断されると、ステップ１２０８では、すべてのキューＱ１〜Ｑｎの中で、最も古いイベントが見出される。このことは、すべてのイベントには、タイム・スタンプがつけられていることにより可能である。

ステップ１２１０では、見つけられた最も古いイベントが、確定イベントとされ、論理プロセスＬＰ＃１〜ＬＰ＃Ｎに通知される。

ステップ１２１２では、確定イベントがキューから取り除かれる。そして、ステップ１２０２に戻り、グローバル・スケジューラ７０８は、次のイベントの到着を待つ。

以上、自動車用の複数のＥＣＵエミュレータを含むテスト・システムに関連して、本発明の特定の実施例を説明してきたが、本発明はこのような特定の実施例に限定されず、飛行機用のＥＣＵエミュレータを含むテスト・システムなど、一般的な電子機械制御系システムのテスト・システムに適用可能であることを、この分野の当業者であるなら、理解するであろう。

ＥＣＵの典型的な制御である、フィードバック閉ループ系の例を示す図である。 フィードバック閉ループ系の、応答関数による記述の例である。 ＥＣＵソフトウェア・エミュレータのクロック応答の時間推移を示す図である。 内部変数を取り出すことができるようになった後のＥＣＵのソフトウェア・エミュレータのブロック図である。 本発明を実施するために使用されるコンピュータのハードウェアのブロック図である。 本発明のシミュレーション・システムの機能論理ブロック図である。 ＥＣＵエミュレータ・プログラムの内部の、より詳細な論理ブロック図である。 ＥＣＵエミュレータの処理のフローチャートを示す図である。 ＥＣＵエミュレータのロールバック表のエントリを示す図である。 グローバル・スケジューラのキューを示す図である。 グローバル・スケジューラの処理のフローチャートである。

Claims (11)

1. 複数の電子制御ユニットによって制御される物理装置システムをシミュレートするためのシステムであって、
   物理装置システム・シミュレータと、
   時刻付きの入力イベントを受け取り、前記物理装置システム・シミュレータに入力される、時刻付きの出力イベントを与えるように複数の電子制御ユニットの各々を電子的にエミュレートする、複数の電子制御ユニット・エミュレータとを有し、
   前記電子制御ユニット・エミュレータは、前記入力イベントを格納するためのキューをもち、
   前記電子制御ユニット・エミュレータの前記入力イベント、そのタイム・スタンプ及び前記出力イベントを順次ロールバック表として記録する手段と、
   前記電子制御ユニット・エミュレータからの出力と、前記物理装置シミュレータからの出力を保持し、そのうちの最も古い出力の時刻を、確定時刻として、前記電子制御ユニット・エミュレータと、前記物理装置シミュレータに通知する、グローバル・スケジューラと、
   前記キューに入力イベントがあるかどうか判断し、入力イベントがないことに応答して、予測された入力イベントを生成して、前記キューに入れ、入力イベントがあることに応答して該入力イベントを取り出し、該入力イベントのタイム・スタンプに一致するエントリが前記ロールバック表にあるかどうかを判断し、ないことに応答して、前記確定時刻に戻って、それ以降の時間をもつ前記ロールバック表中のエントリを削除し、該エントリの時刻とイベントから新しいエントリを作成して前記ロールバック表に挿入し、前記ロールバック表中の確定イベントの内部状態を使用してイベント処理する手段を有し、
   前記ロールバック表における確定されたとみなされているエントリは、前記グローバル・スケジューラによる、前記確定時刻の通知により決定される、
   シミュレーション・システム。
2. 前記電子制御ユニット・エミュレータ及び前記物理装置シミュレータと、前記グローバル・スケジューラは、共通メモリで接続されている、請求項１に記載のシミュレーション・システム。
3. 前記電子制御ユニット・エミュレータ及び前記物理装置シミュレータと、前記グローバル・スケジューラは、ＣＡＮエミュレータで接続されている、請求項１に記載のシミュレーション・システム。
4. 複数の電子制御ユニットによって制御される物理装置システムをコンピュータによって、シミュレートするための方法であって、
   物理装置システム・シミュレータを前記コンピュータによって実行可能にロードするステップと、
   時刻付きの入力イベントを受け取り、前記入力イベントを格納するためのキューをもち、前記物理装置システム・シミュレータに入力される、時刻付きの出力イベントを与えるように複数の電子制御ユニットの各々を電子的にエミュレートする、複数の電子制御ユニット・エミュレータを前記コンピュータによって実行可能にロードするステップと
   前記電子制御ユニット・エミュレータの前記入力イベント、そのタイム・スタンプ及び前記出力イベントを順次ロールバック表として記録するステップと、
   前記電子制御ユニット・エミュレータからの出力と、前記物理装置シミュレータからの出力を保持し、そのうちの最も古い出力の時刻を、確定時刻として、前記電子制御ユニット・エミュレータと、前記物理装置シミュレータに通知するステップと、
   前記キューに入力イベントがあるかどうか判断し、入力イベントがないことに応答して、予測された入力イベントを生成して、前記キューに入れ、入力イベントがあることに応答して該入力イベントを取り出し、該入力イベントのタイム・スタンプに一致するエントリが前記ロールバック表にあるかどうかを判断し、ないことに応答して、前記確定時刻に戻って、それ以降の時間をもつ前記ロールバック表中のエントリを削除し、該エントリの時刻とイベントから新しいエントリを作成して前記ロールバック表に挿入し、前記ロールバック表中の確定イベントの内部状態を使用してイベント処理するステップを有し、
   前記ロールバック表における確定されたとみなされているエントリは、前記確定時刻の通知により決定される、
   シミュレーション方法。
5. 前記キューに入力イベントがあり、該入力イベントのタイム・スタンプに一致するエントリが前記ロールバック表にあることに応答して、前記キューに入力イベントがあるかどうか判断するステップに戻るステップをさらに有する、請求項４に記載のシミュレーション方法。
6. 前記電子制御ユニット・エミュレータと前記物理装置シミュレータは、共通メモリで接続されている、請求項４に記載のシミュレーション方法。
7. 前記電子制御ユニット・エミュレータと前記物理装置シミュレータは、ＣＡＮエミュレータで接続されている、請求項４のシミュレーション方法。
8. 複数の電子制御ユニットによって制御される物理装置システムをコンピュータによって、シミュレートするためのプログラムであって、
   前記コンピュータをして、
   物理装置システム・シミュレータを前記コンピュータによって実行可能にロードするステップと、
   時刻付きの入力イベントを受け取り、前記入力イベントを格納するためのキューをもち、前記物理装置システム・シミュレータに入力される、時刻付きの出力イベントを与えるように複数の電子制御ユニットの各々を電子的にエミュレートする、複数の電子制御ユニット・エミュレータを前記コンピュータによって実行可能にロードするステップと
   前記電子制御ユニット・エミュレータの前記入力イベント、そのタイム・スタンプ及び前記出力イベントを順次ロールバック表として記録するステップと、
   前記電子制御ユニット・エミュレータからの出力と、前記物理装置シミュレータからの出力を保持し、そのうちの最も古い出力の時刻を、確定時刻として、前記電子制御ユニット・エミュレータと、前記物理装置シミュレータに通知するステップと、
   前記キューに入力イベントがあるかどうか判断し、入力イベントがないことに応答して、予測された入力イベントを生成して、前記キューに入れ、入力イベントがあることに応答して該入力イベントを取り出し、該入力イベントのタイム・スタンプに一致するエントリが前記ロールバック表にあるかどうかを判断し、ないことに応答して、前記確定時刻に戻って、それ以降の時間をもつ前記ロールバック表中のエントリを削除し、該エントリの時刻とイベントから新しいエントリを作成して前記ロールバック表に挿入し、前記ロールバック表中の確定イベントの内部状態を使用してイベント処理するステップを実行させ、
   前記ロールバック表における確定されたとみなされているエントリは、前記確定時刻の通知により決定される、
   シミュレーション・プログラム。
9. 前記キューに入力イベントがあり、該入力イベントのタイム・スタンプに一致するエントリが前記ロールバック表にあることに応答して、前記キューに入力イベントがあるかどうか判断するステップに戻るステップをさらに前記コンピュータに実行させる、請求項８に記載のシミュレーション・プログラム。
10. 前記電子制御ユニット・エミュレータと前記物理装置シミュレータは、共通メモリで接続されている、請求項８のシミュレーション・プログラム。
11. 前記電子制御ユニット・エミュレータと前記物理装置シミュレータは、ＣＡＮエミュレータで接続されている、請求項８のシミュレーション・プログラム。

Images