上述したテスト装置は、制御装置開発分野の従来技術から公知であり、研究及び開発において使用される。ここで、適用される頻度の高い分野は、自動車分野及び空中乃至宇宙交通技術である。
仮想制御装置をリアルタイムテストするためのテスト装置は、実制御装置のテストに用いられるテスト装置を基礎としている。こうしたテスト装置は、実制御装置群もしくは複数の実制御装置の結合体について、各制御装置の協働の様子を検査する、いわゆるハードウェアインザループテスト(HILテスト)を実行するために用いられる。実制御装置とは、技術プロセスの制御に用いられる、リアルタイム動作可能な小コンピュータである。したがって、実制御装置には、リアルタイム動作可能なオペレーティングシステムを実行する計算コアが設けられており、これにより、システム理論としては数10年前から知られている、開制御及び/又は閉ループ制御を行うサンプリング装置が実現される。実制御装置は、I/Oインタフェース(入出力インタフェース)を介して制御すべきプロセスに作用する、及び/又は、I/Oインタフェースを介して測定技術的にプロセス情報に関与する。HILシミュレータを用いた実制御装置のテストは、実制御装置が実際の利用環境において使用され始める前の、実制御装置のテストの最終段階である。実制御装置は、例えば、内燃機関の機関制御装置である。
実制御装置をリアルタイムテストするために、実制御装置はI/Oインタフェースを介してテスト装置に接続される。1つもしくは複数の第1のタイプの計算コアが設けられたテスト装置上で、実制御装置の環境を同様にリアルタイムでシミュレート可能なシミュレーション環境が駆動される。機関制御装置の上述した例として、例えば、内燃機関のリアルタイムシミュレーションが挙げられる。上述した事柄から、テスト時のテスト装置のリアルタイム動作性が重要であることがわかる。なぜなら、最終的にはテストに基づいて、制御装置がリアルタイム条件のもとで有効に動作しているか否か、すなわち、例えば構成されているアルゴリズムを要求されたサンプリング間隔で計算可能であるか否か等が判別されるからである。
実制御装置のHILシミュレーションでは、実制御装置の挙動をシミュレートすべき環境において危険なくテストできるという著しい利点が得られる。しかし、この場合、テストを行うために実制御装置そのものを用意しなければならないという欠点がある。これは、連続的に応用される制御装置を開発するにあたって、膨大な手間と費用とに結びつくので、不利である。また、実制御装置のテスト時にはじめて所定の要求が満足されないことがわかった場合、簡単な「事後改善」からはかけ離れた大きな労を要するだけでなく、最悪の場合には制御装置のコンセプトを全く新たに考え直さなければならなくなり、実質的に実制御装置の新たな開発を要する事態となってしまう。結果として、計画された時間目標及び費用目標を遵守できなくなる。
こうした問題に対処するために、検査すべき制御装置の既知のコンポーネントをなるべく早期に機能テストにかけられるよう、いわゆる仮想制御装置のコンセプトが考察されている(Virtual Validation with dSPACE: Early PC-Based Validation of ECU Software, Produktinformation dSPACE, 2013)。この場合、制御装置が物理的に存在している必要はないが、ハードウェアから独立した高水準言語(例えば、C/C++,アセンブラ等)で記述された制御装置コードは存在していなければならない。このケースでは、制御装置コードを第1のタイプの計算コアの第1の命令セットへ変換することにより、第1のタイプの計算コアを有するテスト装置で制御装置コードを実行できるようになる。なお、通常、テスト装置のプロセッサコア/計算コアの構成とテストされる制御装置のプロセッサコア/計算コアの構成とは異なる。PCをベースとするテスト装置では、第1のタイプの計算コアとして、例えば相応の命令セット(例えばインテル社のIA32)を有するインテル社のプロセッサが用いられるのに対して、多くの場合マイクロコントローラをベースとする制御装置では、第1の命令セットを有する第1のタイプの計算コアとは異なる、第2の命令セットを有する第2のタイプの計算コア(例えばC166マイクロコントローラシリーズのC166命令セット)が用いられる。
上述した手段には、オリジナルの制御装置コードが本来第2のタイプの計算コアで動作可能であるためにテスト装置ではテストできず、テスト装置の第1のタイプの計算コアの第1の命令セットへ変換しなければならないという欠点がある。
さらなる問題点として、上述した手段を実現するための高水準言語で記述された制御装置コードが、所定の命令セットへの変換のためにそもそも存在していなければならないことも挙げられる。この前提条件は、例えば構成の詳細が機密であるために多くの適用例において満足されない。
本発明のテスト装置によれば、オリジナルの形態の制御装置コードをテスト装置によって実行でき、高水準言語からテスト装置の要素である第1のタイプの計算コアの第1の命令セットへ翻訳する必要がなくなる。第2の命令セットを有する第2のタイプの計算コア上でのみ動作可能である制御装置コードが、第2のタイプの計算コアをエミュレートするエミュレータを用いて実行可能となり、エミュレータ自体は第1のタイプの計算コア上で実行される。つまり、エミュレータが、テストされる制御装置の第2のタイプの計算コアとテスト装置の第1のタイプの計算コアとの間の結合素子となる。
重要なのは、エミュレータのシミュレーション環境インタフェースを介してシミュレーション環境とのデータ及び/又はイベントの交換が可能となることである。データ及び/又はイベントとは、例えば、エミュレートされた制御装置に基づく、シミュレーション環境の入力量としての、制御装置のI/Oインタフェースのピンの状態や、シミュレーション環境に基づく、エミュレートされた制御装置の入力量としての、インタラプト線路のトリガ信号などである。シミュレーション環境インタフェースは、一方で、制御装置のエミュレーション実行とエミュレータ上での制御装置コードの実行とを同期でき、他方で、シミュレーション環境ひいては仮想制御装置の環境のリアルタイムシミュレーションを実行できるので、特に重要である。つまり、シミュレーション環境インタフェースは、第1のタイプの計算コア上でエミュレータによって制御装置コードをリアルタイムに実行するための前提となっている。
テスト装置は複数の第1のタイプの計算コアを有するので、例えば、或る第1のタイプの計算コアでシミュレーション環境を実行し、別の第1のタイプの計算コアでエミュレータを実行することができる。
本発明の有利な実施形態では、シミュレーション環境は、少なくとも1つのシミュレータと1つのプロセスモデルとを含み、シミュレータがシミュレーション環境インタフェースを介してエミュレータによって呼び出し可能である、及び/又は、(逆に)エミュレータがシミュレーション環境インタフェースを介してシミュレータによって呼び出し可能である。これにより、エミュレータ、乃至、エミュレートされた制御装置コードが、イベント、例えば仮想制御装置の環境のリアルタイムシミュレーションからのイベントに応働できる。こうしたシミュレーション環境と制御装置コードとの結合は、例えばエミュレートされた制御装置の物理コンテクストに基づいて、又は、インタフェースルーチンによって、形成される。ここで、物理コンテクストとは、エミュレートされた制御装置の物理接続部及び物理レジスタ、例えばインタラプト線路等を記述している。インタフェースルーチンが使用される場合、イベントの発生時に制御装置コード内の所定の機能がエミュレータによって実行される。当該機能の決定は、記号テーブルと、制御装置内にどのようなインタフェースルーチンが存在するかを表す記述とによって自動的に行われる。
シミュレーション環境がシミュレータとプロセスモデルとを含む場合、本発明の別の有利な実施形態によれば、シミュレーション環境インタフェースを介してエミュレータとプロセスモデルとの間でデータ及び/又はイベントを交換可能である。言い換えれば、本発明のテスト装置は、有利には、シミュレータによるエミュレータの呼び出し時に、シミュレーション環境インタフェースを介して、エミュレータが、制御装置コードの実行コンテクストを検出し、かつ、制御装置コードのうち呼び出しに関連する部分を実行し、かつ、制御装置コードの実行コンテクストを更新するように構成される。この場合、実行コンテクストは、内部の状態量、及び、エミュレートされた制御装置のインタフェースを記述する状態量(場合によりシミュレーション環境によっても制御される)に加え、エミュレータ上での制御装置コードの実行に関係する境界条件の全てを記述している。
有利には、テスト装置は、制御装置コードが完全であり、特にオペレーティングシステム及びドライバ及び制御装置の全ソフトウェアコンポーネントを含み、これにより上述した実行コンテクストが仮想制御装置の完全な物理コンテクストを含むように構成される。そのための前提として、仮想制御装置のテストでは、実際に、当該仮想制御装置に対応する実制御装置の全ての特徴が検出される。また、この実施形態に代えて、本発明のテスト装置の適用形態として、制御装置コードが不完全であり、特にオペレーティングシステム及びドライバを含まず、このため実行コンテクストが仮想制御装置のソフトウェアコンポーネントのみを含むように構成してもよい。
テスト装置の特に有利な実施形態によれば、エミュレータによる制御装置コードの計算は、エミュレータとシミュレーション環境との間、特にエミュレータとプロセスモデルとの間での、シミュレーション環境インタフェースを介してデータ駆動型で行われる。当該メカニズムにより、エミュレータによる制御装置コードの実行とシミュレーション環境の計算もしくはプロセスモデルの計算とを同期させることができる。
これに代わるテスト装置の構成として、シミュレーション環境が、少なくとも1つのシミュレータと1つのプロセスモデルとを含み、シミュレータがプロセスモデルによって、及び/又は、プロセスモデルがシミュレータによって、呼び出し可能にされる。この場合有利には、プロセスモデルの計算とエミュレータによる制御装置コードの実行とがシミュレータを介して中央制御されることによって所望の同期実行が達成され、特にプロセスモデルの計算と制御装置コードの実行とが時間的に協調されるように、テスト装置が構成される。
プロセスモデルのリアルタイム計算とエミュレータによる制御装置コードの実行との同期を上述した手法のいずれによって行うかにかかわらず、制御装置コードを時間的に最適にエミュレータ上で実行することは重要であるため、サンプリング間隔ごとに行われる計算はいずれの場合にも当該時間内で中断なしに終了することができ、ここで発生するリアルタイム要求に対する制限に衝突しない。ランタイム特性を最適化するために、既知の全ての手段及び技術を使用可能である。さらに、制御装置コードが解釈される場合、メモリリザーブがランタイムで低減されるか又は完全に回避されるように制御される。制御装置コードがバイナリ翻訳される場合の適切な措置は、全てのアトミックなコードブロックをアプリオリに識別し、ランタイム前に翻訳することである。これに代えて、初期化フェーズ後にシミュレーションに必要な全てのコードブロックが翻訳される大きさにブロックキャッシュを選定することもでき、これにより、ブロックキャッシュ内の抑圧が生じない。また、別の措置として、制御装置コードの鎖状参照子を識別解除することが挙げられる。
また、上述した課題は、制御装置コードを有する仮想制御装置の少なくとも一部をリアルタイムテストするための、本発明のテスト装置の動作方法によっても解決される。ここで、テスト装置は、第1の命令セットを有する少なくとも1つの第1のタイプの計算コアと、仮想制御装置の環境をリアルタイムでシミュレートする少なくとも1つのシミュレーション環境とを有している。本発明の方法では、シミュレーション環境と制御装置コードとが少なくとも1つの第1のタイプの計算コアによって計算され、制御装置コードが、第2の命令セットを有する第2のタイプの計算コア上で動作可能であるように構成されている。第2のタイプの計算コアは、通常、テストされるシリアル制御装置の計算コアである。第2のタイプの計算コアの第2の命令セットは、第1のタイプの計算コアの第1の命令セットとは異なる。本発明の方法によれば、第2のタイプの計算コアをエミュレートするエミュレータがテスト装置の第1のタイプの計算コア上で実行され、エミュレータ自体は制御装置コードを実行する。また、本発明の方法によれば、データ及び/又はイベントがエミュレータとシミュレーション環境との間で交換される。ここで、信号流は両方向で形成され、データ及び/又はイベントは、エミュレータからシミュレーション環境へ向かう方向、及び、シミュレーション環境からエミュレータへ向かう方向の双方向で伝達される。本発明の方法により、リアルタイムで実行される仮想制御装置の環境のシミュレーションと制御装置コードのエミュレーションとを同期する汎用的な手段が得られ、制御装置コードをエミュレータによってリアルタイムで実行することができる。
個々には、本発明のテスト装置を構成及び実現する多くの手段が存在する。これらの手段は、一方では請求項1に従属する各請求項に示されており、他方では以下の図示の実施例に即して説明される。
図1のaには、実制御装置2a,2bをリアルタイムテストするための、従来技術から公知のテスト装置1が概略的に示されている。対して、図1のbには、テストされる装置として実制御装置2に加えて仮想制御装置3a,3bを有する、従来技術から公知のテスト装置1が示されている。テスト装置1は、第1の命令セットIS1によって特徴づけられる第1のタイプの計算コア4を有している。図1のa,bに示されている各テスト装置1は、さらに、テストされる各制御装置の環境をリアルタイムでシミュレートするシミュレーション環境5を有する。物理的に存在する実制御装置2は、第2の命令セットIS2によって特徴づけられる第2のタイプの計算コア6を有している。図示の例では、制御装置の第2のタイプの計算コア6の第2の命令セットIS2は、テスト装置1の第1のタイプの計算コア4の第1の命令セットIS1とは異なっている。
図1のa,bでは、テスト装置1はPCベースであり、第1の命令セットIS1は図示の実施例ではインテル社の32ビットx86アーキテクチャ(IA−32)との互換性を有する。第2のタイプの計算コア6はタイプC166の計算コアを含むマイクロコントローラであるので、関連する第2の命令セットIS2はいずれの場合にもテスト装置1の第1のタイプの計算コア4の第1の命令セットIS1とは異なる。実制御装置2は、物理インタフェースを介して、テスト装置1の対応する物理I/Oインタフェースに接続されている。
図1のaの実制御装置2がリアルタイムテストされる場合、制御装置コードECは、本来の形態で、すなわち、第2のタイプの計算コア6の第2の命令セットIS2上で編集された形態で、問題なく実行できる。ただし、実制御装置2の制御装置コードECのテストは、実制御装置2が物理的に実際に存在していることを前提とするので、上述したような欠点を有している。
図1のbのテスト装置1は、仮想制御装置3a,3bと(も)動作する。これらの制御装置は物理的には存在せず、制御装置コードECがテスト装置1の第1のタイプの計算コア4の第1の命令セットIS1へ翻訳され、翻訳された制御装置コードEC’がテスト装置1上で動作可能となることにより実現される。このようにすれば、実制御装置が存在しなくとも制御装置コードの早期のテストが可能となるが、テストされるのがオリジナルの制御装置コードECでなく、制御装置コードの翻訳バージョンEC’である点が不都合である。また、高水準言語で記述された制御装置コードECが用意されていなければ、第1のタイプの計算コア4の第1の命令セットIS1への翻訳は不可能である。
図2のa,bには、本発明のテスト装置1が示されている。この場合にも、テスト装置1は第1の命令セットIS1を有する第1のタイプの計算コア4を含んでおり、また、仮想制御装置3の環境をリアルタイムでシミュレートするシミュレーション環境5が用いられる。この場合も、仮想制御装置3の制御装置コードECは最終的には第1のタイプの計算コア4を用いて計算されるが、本発明は従来技術から公知の(例えば図1のa,bに示されているような)テスト装置とは大きく相違している。すなわち、本発明では、仮想制御装置3の制御装置コードECが、テスト装置1の第1の命令セットIS1を有する第1のタイプの計算コア4とは異なる、第2の命令セットIS2を有する第2のタイプの計算コア6上で動作可能である。つまり、本来第2のタイプの計算コア6に対して考察されている制御装置コードECをテスト装置1によって実行できる。なぜなら、テスト装置1の第1のタイプの計算コア4がエミュレータ7を実行し、このエミュレータ7が第2のタイプの計算コア6をエミュレートして、エミュレートされた第2のタイプの計算コア6が制御装置コードを実行するからである。こうした措置により、制御装置コードECは第2の命令セットIS2を有する第2のタイプの計算コア6上で動作可能であるので、第1の命令セットIS1へ翻訳されなくてよく、また、基本的に、テスト装置1とは別の目標ハードウェアのために形成されたオリジナルの制御装置コードECを実行できる。よって、テスト装置1の第1の命令セットIS1への翻訳のために高水準言語で記述された制御装置コードECを用意する必要もない。
重要なのは、エミュレータ7がシミュレーション環境インタフェース8を有しており、このシミュレーション環境インタフェース8を介してエミュレータ7がシミュレーション環境5とデータ及び/又はイベントを交換できるということである。シミュレーション環境インタフェース8は、仮想制御装置3の環境のリアルタイムシミュレーションとエミュレータ7による第2のタイプの計算コア6のエミュレーションとを同期させることができるので、リアルタイムシミュレーションにおいてエミュレータ7を利用するための本質的な機能を有している。
図2のbには、本発明のテスト装置1が1つもしくは複数の仮想制御装置3をテストすることのみに制限されず、むしろ、テスト装置1と外部の実制御装置2とを一緒に駆動できることが示されている。図2のbに示されている実施例では、仮想制御装置3及び実制御装置2の同時テスト、又は、制御装置混合連結体の同時テストにより、上述したテスト装置1の利用頻度の高い応用ケースが実現される。
図3には、テスト装置1が示されており、ここではシミュレーション環境5がシミュレータ9とプロセスモデル10とを含む。シミュレータ9はシミュレーション環境インタフェース8を介してエミュレータ7によって呼び出し可能であり、逆に、エミュレータ7はシミュレーション環境インタフェース8を介してシミュレータ9によって呼び出し可能である。シミュレータ9は、全体として、リアルタイム条件を考慮してプロセスモデル10を実行するための、リアルタイム動作可能なプラットフォームである。リアルタイム環境に加え、シミュレータ9には、プロセスモデル10を計算可能な適切な数値プロセスも設けられている。よって、シミュレータ9は、プロセスモデル10の種々のタスクの実行を時間的に協調させ、シミュレーションにおける非周期的な複数のイベントを考慮するための手段を提供する。
さらに、図3からは、シミュレーション環境インタフェース8を介してエミュレータ7とプロセスモデル10との間でデータが交換される様子が見て取れる。プロセスモデル10は、エミュレートされた仮想制御装置3のインタフェースを認識しているので、プロセスモデル10とエミュレートされた仮想制御装置3との間のデータ整合が達成される。
図4,図5には本発明のテスト装置1が示されており、ここでは、ブロック回路図によって、テスト装置1の構造だけでなく、テスト装置1内の動作フローも示されている。図4,図5では、シミュレーション環境5とエミュレータ7とがそれぞれシミュレーション環境インタフェース8に接続されており、これを介して相互に作用している様子が見て取れる。なお、シミュレーション環境5にはそれぞれプロセスモデル10を含むシミュレータ9が示されている。
図4には、シミュレーション環境インタフェース8を介してエミュレータ7とプロセスモデル10との間でデータが交換される様子が示されている。このため、図4の実施例は、エミュレータ7による制御装置コードECの実行が、エミュレータ7とプロセスモデル10との間のシミュレーション環境インタフェース8を介してデータ駆動型で行われることを特徴としている。したがって、シミュレーション環境インタフェース8を介して、プロセスモデル10の関連する状態量、例えばインタフェースの所定チャネルでの信号が変更されたか否か、及び、この変更に応じてエミュレータ7において対応する動作がトリガされるか否かが識別される。
シミュレータ9の静止状態901から出発して、プロセスモデル10に対する次の計算ステップがトリガされる。この場合、まず、入力ルーチン902において、エミュレータ7により、計算された関連する制御装置データが読み出される。
エミュレータ7での各計算ステップも同様に静止状態701から開始され、ステップ702でエミュレータ7が実行される。ステータスステップ702は種々のタイプのトリガによって達成可能である。ステータスステップ702は、例えば、静止状態701からのクロックインタラプト又は所定のデータイベントによって達成される。データイベントが起こると、まずステータスステップ802が発生し、これに関連するインタラプトが生じた後にステータスステップ702が達成される。この例として、I/Oピンに関連するピン変更インタラプトが生じるケースが挙げられる。インタラプトがI/Oピンに関連しない場合には、ステップ802は通過され、ステップ702のそれ以降の動作も行われない。ステータスステップ802は、エミュレータ7に対するデータが相応に符号化されていること、つまり、エミュレータ7の実行コンテクストにおいて符号化されていることを保証するためのステップである。
エミュレータ7により、第2の命令セットIS2内の制御装置コードECも実行される。シミュレータ9及びエミュレータ7は実質的に並列動作する。エミュレーションは、上述したように、イベントに関連したインタラプトが生じた場合にのみ中断される。それ以外の場合には、相互に交換されるデータがシミュレーション環境インタフェース8を介して供給され、エミュレータ7又はシミュレータ9によって読み出される。
プロセスモデル10での計算ステップ903の終了後、出力関数ステップ904でプロセスモデル10のその時点の状態量がエミュレータ7へ供給される。これは、シミュレーション環境インタフェース8において、ステップ802で、エミュレータ7の物理コンテクストを単純に記憶することにより、又は、制御装置コードEC内の相応のインタフェース機能を呼び出すことにより行われる。ここで、「物理コンテクストの記憶」とは、例えば、変更されたI/O信号がエミュレータのコンテクストで適切に記憶されてエミュレータへ供給可能となることであると理解されたい。対して、ステップ702における「制御装置コードEC内のインタフェース機能の呼び出し」とは、インタフェース機能の利用が相応に構成されており、制御装置コードEC内のインタラプトがトリガされる場合に行われるものである。インタラプトがない場合には、上述したように、そのことを表す情報のみが供給される。ここで、後者のケースは、信号が物理的に印加されて、適切な記憶によって供給可能となっており、相応の簡単な読み出し過程によって利用可能となることを意味する。ただし、ステップ702はトリガされない。同様のことがプロセスモデル10の計算ステップ903にも当てはまる。
図5の実施例では、シミュレーション環境5とエミュレータ7との同期の様子が示されている。当該同期は、プロセスモデル10の計算とエミュレータ7による制御装置コードECの実行とがシミュレータ9によって中央制御されることによって達成される。これは特に、プロセスモデル10の計算ステップ903と制御装置コードECの実行ステップ702との時間的協調に関連する。図5には、シミュレータ9の静止状態901からプロセスモデル10及びエミュレータ7の実行の双方がシミュレーション環境インタフェース8を介してトリガされ、これにより、時間同期が保証されることが示されている。なお、このことはもちろん、プロセスモデル10がシミュレータ9によって呼び出し可能であることを前提とする。エミュレータ7側では、ステップ810でまず、処理を行うべき制御装置の正常動作性が判別される。続いて、ステップ811で、その時点の全ての入力量、すなわち、プロセスモデル10から供給される入力量と外部ソース11からの他の入力量との双方が読み込まれる。ステップ812で、物理データから実行コンテクストが形成され、エミュレータ7に対する簡単な読み出し動作によって情報が利用可能となる。インタフェースルーチンによって処理が行われる場合、ステップ702で直接に制御装置コードECの対応する機能がエミュレータ7によって処理される。計算が行われた後、ステップ813で、更新データを有する実行コンテクストが再び記憶され、ステップ814で、出力関数の実行により、相応の複数の出力、すなわち、プロセスモデル10に関する各出力と外部データシンク12に関する各出力とが書き込まれる。このようにして、リアルタイムで、プロセスモデル10に関する計算ステップとエミュレータ7上の制御装置コードECに関する計算ステップとが相互に同期して計算される。
図4,図5の実施例では、エミュレータ7は第2の命令セットIS2内の制御装置コードECのうち呼び出された命令のそれぞれをランタイムで解釈し、これらの命令を、第1の命令セットIS1の対応する命令と機能的に同様に、テスト装置1の第1のタイプの計算コア4上で実行する。