JP5179249B2 - 制御装置シミュレーション方法、システム及びプログラム - Google Patents

Description

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

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

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

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

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

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

１９７０年代は、ＥＣＵの主要な用途は、エンジンを効率的に制御することであったが、１９８０年代になると、それだけに限らず、より安全に、快適に自動車を走らせることに、ＥＣＵが使用され始めてきて、現在では、自動車一台に５０個を越えるＥＣＵが搭載されることが多くなってきている。このように多数のＥＣＵが自動車に搭載されると、開発段階で、複数のＥＣＵがきちんと適正に協働して動作するかどうかをテストするのが非常に大変になってくる。

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

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

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

しかし、従来知られているＳＩＬＳは、機能単体のソフトウェア検証を行うだけで、いわゆる、マルチＥＣＵに関するＳＩＬＳを達成することを可能ならしめるものではなかった。

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

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

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

上記従来技術は、ＥＣＵをソフトウェアでシミュレートする技術を開示するが、そのような従来技術は、マルチＥＣＵのソフトウェア・シミュレーションに適用することは非常に困難であるか、事実上不可能である。というのは、ＥＣＵは、個別にマイクロプロセッサをもち、クロックレートもまちまちである。従って、このような個別のＥＣＵを接続したテスト環境全体をソフトウェアでシミュレートするためには、従来技術では教示されない新規な技法が必要である。

従って、この発明の目的は、自動車などに使われるマルチＥＣＵの構成を、ソフトウェアでシミュレートする技術を提供することにある。

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

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

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

本発明によれば、各ＥＣＵエミュレータは、投機的にエミュレートされる。すなわち、各ＥＣＵエミュレータは、個別のクロックで非同期に動作し、独自の投機的時間をインクリメントする。さらに、システム・スケジューラが設けられ、各ＥＣＵエミュレータによって送られた全ての投機的時間を維持し、システム・スケジューラは、「最終」時間を更新する。そうして、ＥＣＵエミュレータが、自分の投機的時間よりも前のタイムスタンプをもつ外部入力を受け取ると、そのＥＣＵエミュレータは、そのタイムスタンプが指し示す過去の時間に自身のクロックを巻き戻し、タスクを再実行する。この目的のために、ＥＣＵエミュレータは、少なくともある一定期間は、その内部状態を、好適にはそのプライベート・メモリに保持しておく。これにより、巻き戻された時間に対応する内部状態をセットすることにより、タスクを再現可能である。

こうして、投機的エミュレーションによって、異種マルチＥＣＵ、さらには好適には、異種マルチＥＣＵからなるフルビークル・ソフトウェア・エミュレーションが可能となる。

また、フルビークル・ソフトウェア・エミュレーションによって、クロック速度を速めることができるので、ＨＩＬＳの場合よりもはるかに高速に、フルビークル・ソフトウェア・エミュレーションを行うことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４は、ＥＣＵのソフトウェア・エミュレータを、所定のクロックで動作させた場合の様子を示す図である。図４に示すように、ソフトウェア・エミュレータは、定期的に入来するクロックに同期して出力信号を供給するが、図示されているように、センサからの入力は、クロックによるサンプリング時間とは非同期で入来する。

実際のＥＣＵが、c_i[1/sec]、サンプリング時間t_i[sec/sample]でセンサ入力に基づいて出力を計算するとする。すると、エミュレーションの換算クロックを、c[1/sec]とすると、実際の動作間隔は、t = t_i*c_i/ c[sec/sample]となる。

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

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

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

次に、図９及び図１０を参照して、ＥＣＵエミュレータの状態リポジトリ更新と利用の処理を説明する。この処理は、典型的には、図７に示すエミュレーション・システム全体を制御するプログラムによって、所定のクロック毎に、行われる。図９のステップ９０２では、ＥＣＵエミュレータの制御ロジック・モジュール８０２が、シナリオ・ジェネレータ７１０の外部入力モジュールから、入力ｕを受け取ったかどうかが判断される。

もし、制御ロジック・モジュール８０２が、入力ｕを受け取ったのでないなら、ステップ９０４で、既に受け取っている最後のデータがセットされる。ステップ９０６では、図１０に示す、ステップ実行と呼ばれるサブルーチンが実行される。

図１０のサブルーチンに移行して、ステップ１００２では、セット済み入力がu_kとされる。ステップ１００４では、現在の内部状態が、ｘ_kとされる。ステップ１００６では、ＥＣＵエミュレータの内部状態を計算する関数をgとすると、ｘ_k+1 = g(u_k,ｘ_k)で、次の内部状態ｘ_k+1が計算される。ステップ１００８では、y_k+1 = f(ｘ_k+1)で、出力y_k+1が計算される。

図１０のサブルーチンは、ここで、図９のステップ９０６に戻る。次のステップ９０８では、現在の先行時刻c_k、ステップ９０６で計算した結果の内部状態ｘ_k（図１０との関連では、次の内部状態ｘ_k+1と計算されたものを、ｘ_kと読み替えている）と、入力u_kと、入力u_kの実際の到着時刻C(u_k)が、状態リポジトリに更新される。

状態リポジトリの内容の例を以下に示す。

ステップ９１０では、先行時刻c_kと、図１０のサブルーチンで計算された出力y_k（図１０との関連では、出力ｘ_k+1と計算されたものを、ｘ_kと読み替えている）が、スケジューラ７０６に送られる。この送り方であるが、共有メモリ方式ならば、特定のメモリのアドレスに書いてシグナルされるし、ＣＡＮエミュレータ方式の場合、送り出すメッセージに、所定の宛先を含むヘッダを付けることになる。このような処理は、図８に示す通信インターフェース・モジュール８０８によって、行われる。

ステップ９０２に戻って、外部入力モジュールからＥＣＵエミュレータに入力ｕが入ってくると、ステップ９０２での判断が肯定的になって、ステップ９１２での判断に移る。ステップ９１２では、投機失敗かどうかの判断が行われる。

投機失敗とは、次のように判断する。すなわち、新しく届いた入力 u に付加された時刻 C(u) に対して、もし、C(u) が最新の先行時刻よりも大きい場合には、入力の時刻のほうが先行時刻よりも新しいということになるので、投機実行には至っておらず、したがって、投機は失敗していないと判断する。もし、状態レポジトリのエントリの中で、c_j <= C(u) < c_j+1 を満たす、j番目のエントリが存在するなら、さらに、そのエントリに記録された入力u_kと新しい入力uとを比較して、両者が等しくなければ、投機失敗とみなす。

投機失敗であると判断されると、ステップ９１４で、時刻がC(u)に巻き戻される。そして、c_j <= C(u) ＜ c_j+1を満たす j番目の状態 x_jに内部状態がセットされて、ステップ９１６で、入力uがセットされる。

投機失敗でないと判断されると、処理は直ちにステップ９１６に進み、入力uがセットされる。こうして処理は、ステップ９０６のステップ実行のルーチンに進む。

図１１は、スケジューラ７０６のより詳細な内部構成を示す論理ブロック図である。スケジューラ７０６は、ＥＣＵエミュレータから出力を受け取っても、直ちにはプラント・シミュレータ７０８にデータを送信することはない。最も処理の遅い、すなわち、最も仕事量が多い、あるいは元のクロックの大きいＥＣＵエミュレータに柔軟に同期するため、まず各ＥＣＵエミュレータの先行時刻を、リリース表１１０２に、記録する処理を行う。

そこで、図１１の論理ブロック図を参照しつつ、図１２のフローチャートに従って、スケジューラ７０６の処理について説明する。図１２において、ステップ１２０２では、スケジューラ７０６が、各ＥＣＵエミュレータの先行時刻を受け取る。また、それと併せて、各ＥＣＵエミュレータから、出力も受け取る。

下記に、リリース表１１０２の内容の例を示す。見て取れるように、リリース表１１０２には、ＥＣＵ毎に、出力のリストと、その先行時間が格納されている。

ステップ１２０４では、ＥＣＵエミュレータから受け取った先行時刻に従い、リリース表１１０２の先行時刻欄が更新される。このとき、先行時刻を更新する際に、それまで記録されていた先行時刻よりも古い時刻が先行時刻として通知されたときに、その時刻以降の（仮りの）出力を捨てる、という処理が行われる。そうして、各ＥＣＵは、先行しすぎているときに、時間の古い入力を受け取ると、そこからやり直しをすることになるので、その時刻より後のつもりで出してしまっていた出力を取り消す必要がある。そのための処理が、ステップ１２０４で行われる。

ステップ１２０６では、最も遅いＥＣＵの時刻が更新されたかどうかが判断され、もしそうなら、ステップ１２０８で、一番遅い先行時刻を、確定時刻として更新する。そして、ステップ１２１０では、確定時刻より古い出力が、データ・リリース・モジュール１１０４によって、リリースされる。リリースされた出力は、通信インターフェース・モジュール１１０６を介して、共有メモリ７０２に送られ、そこからプラント・シミュレータ７０８へと送信される。リリースされた出力は、共有メモリ７０２を介して、ＥＣＵエミュレータにも入力として提供される。例えば、エアコンＥＣＵエミュレータの出力が、エンジンＥＣＵエミュレータの入力に供給される、等である。これによって、送信されるＥＣＵの出力がすべて、投機に成功していたことが保証される。

データ・リリース・モジュール１１０４は、ステップ１２１２で、リリース表１１０２の更新を行う。この更新とは、リリース表１１０２の確定時刻よりも古いエントリを捨てることである。こうして処理は、ステップ１２０２に戻る。

ステップ１２０６で、最も遅いＥＣＵの時刻が更新されていないと判断された場合は、処理は直ちにステップ１２０２に戻る。

ところで、図９に示すＥＣＵエミュレータ７０４の処理、あるいは、図１２に示すスケジューラ７０６の処理だと、場合により更新の遅延が生じることがある。そこで、以下のような処理を行う。

先ず、ＥＣＵエミュレータ７０４側では、ステップ１３０２で、エンプティ（空）メッセージを待つ。このエンプティ・メッセージは、後述するが、スケジューラ７０６から定期的にブロードキャストされる。

ステップ１３０４では、ＥＣＵエミュレータ７０４は、スケジューラ７０６から送られてきたエンプティ・メッセージの時刻を調べて、それがそのＥＣＵエミュレータ７０４の先行時刻より古いかどうかの判断を行う。そして、もし先行時刻より古ければ、その先行時刻を含むメッセージを、スケジューラ７０６に送る。そうでなければ、処理は、直ちにステップ１３０２に戻る。

一方、スケジューラ７０６側では、ステップ１４０２で一定時間Ｔを待って、ステップ１４０４で、時刻付のエンプティ・メッセージを、ＥＣＵエミュレータ全体に向けて、ブロードキャストする。このような仕組みにより、ＥＣＵエミュレータ７０４に定期的に強制的にエンプティ・メッセージが送られるので、更新時刻の停滞が解消される。

なお、図１３及び図１４のフローチャートの処理は、それぞれＥＣＵエミュレータ７０４と、スケジューラ７０６で、好適には個別のスレッドとして起動され、図９及び図１２の処理とは独立に走る。

図７に戻って、シナリオ・ジェネレータ７１０は、操作者の意図をあらわす入力や、エンジン、ブレーキ、エアコンなどのプラントに対する負荷となる入力の時間推移を与える。例えば、停止状態から徐々に速度を上げて時速４０Ｋｍに達したら加速度をゼロして一定速度でしばらく走り、その後さらに加速する、などである。あるいは、積載重量、道路の傾斜の変化の時間推移などである。いずれも、時刻を入力として、対応するパラメータ値を、ＥＣＵエミュレータやプラントに与えるものである。

また、図７のシステムにおけるデバッグについて、説明する。デバッグは例えば、このシミュレーション・システムのどこかで、異常が検出された場合の時点に戻ってテストすることを意図する。デバッグの開始は、スケジューラ７０６によって開始される。すなわち、スケジューラ７０６はまず、リリース表などをリセットし、次に各ＥＣＵエミュレータ７０４に、論理時刻のリセット信号と、その他の初期入力を送る。すると、各ＥＣＵエミュレータ７０４は、論理時刻のリセット信号に応答して、その論理時刻を巻き戻し、ＥＣＵエミュレータ７０４が保持している状態リポジトリの、その論理時刻に対応するエントリを参照して、一連の処理を再開する。

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

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

Claims (8)

1. 複数の電子制御ユニットによって制御される機構システムをシミュレートするためのシステムであって、
   機構システム・シミュレータと、
   時刻付きの入力信号を受け取り、時刻付きの出力信号を与えるように複数の電子制御ユニットの各々を電子的にエミュレートする、複数の電子制御ユニット・エミュレータと、
   前記複数の電子制御ユニット・エミュレータから前記時刻付きの出力信号を受領して、電子制御ユニット・エミュレータ毎に対応して該時刻と該出力信号を保存するとともに、その後の電子制御ユニット・エミュレータからの前記時刻付きの出力信号の受領に応答して前記時刻を変更し、最も遅い前記時刻に対応する電子制御ユニット・エミュレータの前記時刻が変更されたことに応答して、前記時刻より前の時刻の出力信号を、前記機構システム・シミュレータに提供するスケジューラを具備し、
   前記電子制御ユニット・エミュレータは、
   入力信号があった場合は該入力信号を使用して出力信号を計算し、ある期間に入力信号がない場合に以前に入力された入力信号を使用して出力信号を計算する手段と、計算に使用された入力信号を時刻付きで記録する手段と、
   入力信号があった場合に該入力信号の時刻に対応して記録されている入力信号と、該入力された入力信号を比較し、一致しないことに応答して、該入力された入力信号の時刻に内部状態変数を戻す手段とをもつ、
   シミュレーション・システム。
2. 前記電子制御ユニット・エミュレータがさらに、
   内部状態変数を時刻毎に記録する手段と、
   前記状態を戻すことに応答して、戻す時刻に対応する内部状態変数をセットする手段を有する、
   請求項１のシミュレーション・システム。
3. 前記電子制御ユニット・エミュレータと、前記スケジューラは、共通メモリで接続されている、請求項１のシミュレーション・システム。
4. 前記電子制御ユニット・エミュレータと、前記スケジューラは、ＣＡＮエミュレータで接続されている、請求項１のシミュレーション・システム。
5. 複数の電子制御ユニットによって制御される機構システムをコンピュータによりシミュレートするための方法であって、
   時刻付きの入力信号を受け取り、時刻付きの出力信号を与えるように複数の電子制御ユニットの各々を電子的にエミュレートする、複数の電子制御ユニット・エミュレータと、機構システム・シミュレータを、前記コンピュータによって制御可能に、前記コンピュータのメモリにロードするステップと、
   前記複数の電子制御ユニット・エミュレータから前記時刻付きの出力信号を受領して、電子制御ユニット・エミュレータ毎に対応して該時刻と該出力信号を保存するとともに、その後の電子制御ユニット・エミュレータからの前記時刻付きの出力信号の受領に応答して前記時刻を変更し、最も遅い前記時刻に対応する電子制御ユニット・エミュレータの前記時刻が変更されたことに応答して、前記時刻より前の時刻の出力信号を、前記機構システム・シミュレータに提供するステップを有し、
   前記電子制御ユニット・エミュレータは、前記コンピュータに、
   入力信号があった場合は該入力信号を使用して出力信号を計算し、ある期間に入力信号がない場合に以前に入力された入力信号を使用して出力信号を計算するステップと、
   計算に使用された入力信号を時刻付きで記録するステップと、
   入力信号があった場合に該入力信号の時刻に対応して記録されている入力信号と、該入力された入力信号を比較し、一致しないことに応答して、該入力された入力信号の時刻に内部状態変数を戻すステップを実行させる、
   シミュレーション方法。
6. 前記電子制御ユニット・エミュレータがさらに、前記コンピュータに、
   内部状態変数を時刻毎に記録するステップと、
   前記状態を戻すことに応答して、戻す時刻に対応する内部状態変数をセットするステップを実行させる、
   請求項５のシミュレーション方法。
7. 複数の電子制御ユニットによって制御される機構システムをコンピュータによりシミュレートするためのプログラムであって、
   前記コンピュータをして、
   時刻付きの入力信号を受け取り、時刻付きの出力信号を与えるように複数の電子制御ユニットの各々を電子的にエミュレートする、複数の電子制御ユニット・エミュレータと、機構システム・シミュレータを、前記コンピュータによって制御可能に、前記コンピュータのメモリにロードするステップと、
   前記複数の電子制御ユニット・エミュレータから前記時刻付きの出力信号を受領して、電子制御ユニット・エミュレータ毎に対応して該時刻と該出力信号を保存するとともに、その後の電子制御ユニット・エミュレータからの前記時刻付きの出力信号の受領に応答して前記時刻を変更し、最も遅い前記時刻に対応する電子制御ユニット・エミュレータの前記時刻が変更されたことに応答して、前記時刻より前の時刻の出力信号を、前記機構システム・シミュレータに提供するステップを実行させ、
   前記電子制御ユニット・エミュレータは、前記コンピュータに、
   入力信号があった場合は該入力信号を使用して出力信号を計算し、ある期間に入力信号がない場合に以前に入力された入力信号を使用して出力信号を計算するステップと、
   計算に使用された入力信号を時刻付きで記録するステップと、
   入力信号があった場合に該入力信号の時刻に対応して記録されている入力信号と、該入力された入力信号を比較し、一致しないことに応答して、該入力された入力信号の時刻に内部状態変数を戻すステップを実行させる、
   シミュレーション・プログラム。
8. 前記電子制御ユニット・エミュレータがさらに、前記コンピュータに、
   内部状態変数を時刻毎に記録するステップと、
   前記状態を戻すことに応答して、戻す時刻に対応する内部状態変数をセットするステップを実行させる、
   請求項７のシミュレーション・プログラム。

Images