JP7288150B2 - テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信のシミュレーション - Google Patents

Description

本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信をシミュレートするための方法、システム、およびコンピュータプログラム製品に関する。

現代社会では、定期的にデータを交換する様々な技術的機器が使用されている。これらの機器相互の通信は、通常、制御機器によって制御される。そのような制御機器は、特定のさらなる機器だけでなく、多くの様々な機器の通信を引き継ぐことができる。機器との通信に対する前提条件は、制御機器が、それぞれの対向機器に対応するインタフェースとプロトコルとを有し、それらを処理することできることである。換言すれば、制御機器は、送信インタフェースを介して他の機器との通信のために、どのようなデータをどのように送信すべきかと、受信インタフェースを介して受信されたデータをどのように評価することができるかと、を自身に設定する命令を有する必要がある。制御機器には、可及的に多くの様々な機器と通信可能であることが望まれる。

制御機器を、例えば車両などに搭載して市場に提供する前には、制御機器の仕様に応じて選択した機器との通信が問題なく機能していることを保証する必要がある。そのため、通常、制御機器は、量産前にテストされる。しかしながら、実際のテストは、非常に手間がかかったり、通信参加者がまだ実際には存在しなかったりするため不可能な場合もある。そのため、それに代わって、対象となるすべてのデバイスとの通信がシミュレートされることが多い。このシミュレーションと後の通信とについては、シミュレートされる機器の対応情報が必要になる。これらの必要な情報は、通常、いわゆる通信マトリックスの形態で存在しており、これらには、機器または機器ネットワーク全体のすべての送信および受信インタフェースの記述が含まれる。テストすべき各制御機器について、テストすべき制御機器と他の制御機器との通信のための命令を含む個別の通信マトリックスが（場合によっては通信マトリックス全体の一部として）存在する。

通信マトリックスは、車両全体について一部は自動車メーカーによって作成される。しかしながら、例えば、個々の制御機器のテストについては、制御機器サプライヤの場合のように通信マトリックスがまだ完全には存在しないか、テストすべき個々の制御機器のみにしか存在しない可能性があり、そのため、テスト用の制御機器と他の制御機器との通信に関する重要な情報が存在しない。したがって、そのような通信マトリックス用の情報は、通常、個別にユーザーによって、特にいわゆる「ループテスター内のハードウェア」によって地道に作成されるか、もしくは通信マトリックスに挿入される必要がある。その際、テスターに使用されるバスシステムの機器タイプだけでなく、使用されるネットワーク技術や標準的な記述規則にも注意を払う必要がある。通信マトリックスによって記述されるインタフェースもしくはその記述は、様々な標準規格で規定されている。しかしながら、標準規格における変更に基づいて、１つの同じインタフェースでも異なるマッピング規則が存在する可能性がある。

その上さらに、テスターは、買収権や契約上の合意に基づき、制御機器の通信マトリックスまたは制御機器ネットワーク全体を変更する権限を与えられていない場合もある。

これに対する客観的な技術的課題は、制御機器通信のシミュレーションを簡素化し、ならびにエラーの影響の受けやすさ、シミュレーション環境の生成の労力を最小限に抑えることである。

この課題は、独立請求項によって解決される。好適な実施形態は、従属小項によって記載される。

第１の態様では、本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信をシミュレートするための方法に関する。テストすべき制御機器については、テストすべき制御機器の送信および受信インタフェースの記述が存在する。本方法は、以下のステップ、すなわち
－送信および受信インタフェースの記述を、データベースに転送するステップと、
－テストすべき制御機器のインタフェースを、データベースによる記述から識別するステップと、
－テストすべき制御機器の識別された各送信インタフェースについて、少なくとも１つのさらなる制御機器の受信インタフェースとしての受信インタフェース要素を生成するステップと、
－テストすべき制御機器の各受信インタフェースについて、少なくとも１つのさらなる制御機器の送信インタフェースとしての送信インタフェース要素を生成するステップと、
－生成されたインタフェース要素をデータベースに格納するステップと、
－データベースにより、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信のシミュレーション用の構成を提供するステップであって、ここで、この構成は、テストすべき制御機器のインタフェースおよび生成されたインタフェース要素を含むステップと、
－当該構成を使用して、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信用の実行可能なシミュレーションプログラムを生成するステップと、
－シミュレーションプログラムを用いて、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信をシミュレートするステップと、を含む。

本発明の枠内では、テストすべき制御機器とさらなる制御機器とが区別される。テストすべき制御機器は、好適には、後の使用において、複数のさらなる機器との通信が意図される自動車制御機器である。例えば、そのような制御機器は、車両に組み込まれ、例えば、車載コンピュータ、ナビゲーション機器、ＡＢＳの制動制御部、ライト制御部、燃料ポンプ制御部、または典型的な車両の他の機器内のさらなる機器の通信を制御する。テストすべき制御機器は、現実のものであってもよいし、仮想のものであってもよい。同様に、本発明の枠内で使用されるバスも、現実のものであってもよいし、仮想のものであってもよい。仮想の制御機器は、擬似的にソフトウェアで実装された制御機器の前段階であり、通常は、既に最終的な量産コードを含んでいる。ただし、将来的なオペレーティングシステムが、通常は既にシミュレートされ、現実的な設計特性が、機能性に対して定義された時間およびトリガー情報に基づいてシミュレートされるとはいえ、制御機器の実際のハードウェアはまだ必要なく、そのため、仮想制御機器は、例えば、シミュレートされたバスに接続することができる（ｈｔｔｐｓ：／／ｗｗｗ．ｄｓｐａｃｅ．ｃｏｍ／ｄｅ／ｇｍｂ／ｈｏｍｅ／ｎｅｗｓ／ｅｎｇｉｎｅｅｒｓ－ｉｎｓｉｇｈｔｓ／ｂｌｏｇ－ｖｉｒｔｕａｌｓ－ｅｃｕｓ－１８０８．ｃｆｍ）。

テストすべき制御機器をテストするために、１つまたは複数のさらなる制御機器との通信は、それらをシミュレートすることでテストされる。それゆえ、少なくとも１つのさらなる制御機器は、１つのさらなる制御機器または複数のさらなる制御機器を含むことができる。

本発明の枠内では、インタフェースおよびインタフェース要素、特に生成されたインタフェース要素という用語が使用される。基本的に、インタフェースおよびインタフェース要素は、制御機器が他の制御機器とデータを交換するために使用する通信機能、対応する機能呼び出し、もしくはメッセージ（パケット）などの通信要素の仕様、および／またはそれらの特性、メッセージタイプ、データタイプ、ポートなどである。インタフェース要素および特に生成されたインタフェース要素は、テストすべき制御機器のインタフェースに対する対向物を形成し、それによって、純粋に仮想的に存在させること、すなわち、物理的に存在する制御機器なしで存在させることによってインタフェースと区別される。少なくとも１つの制御機器との通信がシミュレートされ、そのため、制御機器通信のシミュレーションのための少なくとも１つの制御機器が物理的に存在する必要はなくなる。相応にテストすべき制御機器についても、物理的に完全に存在しなければならないわけではないことがいえる。

テストすべき制御機器の送信および受信インタフェースの記述は、好適には、通信記述であり、特に好適には、通信マトリックスの形態で存在する。通信マトリックスは、例えば、ＸＭＬスキーマの形態で使用することができる。典型的な通信マトリックスは、それぞれの制御機器のインタフェースを記述する１０万までの要素またはそれ以上の要素を含むことができる。

データベースは、基本的には、標準的な通信記述を読み込むことを可能にするために必要な情報を含んだ任意のデータベースであってもよい。すなわち、これらの情報は、例えば、Ａｕｔｏｓａｒ規格および／またはその他の通信規格に関する情報である。さらに、データベースには、テストすべき制御機器のための通信記述は、好適には、通信マトリックスとして様々な標準規格や様々なシミュレートすべき機器のために格納可能である。

特に、好適には、ロード後に記述が抽象化された形態でデータベースに格納され、それによって、記述は、使用される標準規格のバージョンに依存することなく使用することができる。テストすべき制御機器のインタフェースも、好適には、抽象化された形態でデータベースに格納される。

例えばＡＵＴＯＳＡＲのような標準規格（本明細書では通信技術とも称する）は、年に数回変更および／または更新することができる。例えば、ＡＵＴＯＳＡＲ規格３．１．４に対応する通信マトリックスにおける１つの同じインタフェースは、ＡＵＴＯＳＡＲ規格４．３．１に対応する通信マトリックスにおけるものとは異なってマッピングされている。例えばバージョンに依存しない表示形態など、インタフェース記述の抽象化によって、バージョンに依存しない構成が可能になる。

好適には、記述の抽象化と、生成されたインタフェース要素への抽象化された記述のマッピングと、によって、実行可能なシミュレーションプログラムの生成が容易になる。抽象化することにより、すべての可能な通信技術バージョンに対してすべての可能な記述をデータベースに格納する必要がなくなり、このことは、データベースの所要の規模を低減させる。

好適には、インタフェースの記述を抽象化し、インタフェース要素を生成し、かつ／または本方法の他のステップを実行するために、処理ユニット、例えばパーソナルコンピュータＰＣのプロセッサユニットが設けられている。

本発明によれば、最初に、テストすべき制御機器の記述がデータベースに転送される。換言すれば、データベースは、テストすべき制御機器についてのすべての情報を、制御機器に通知される対応する記述の形態で受信する。

転送された記述は、データベースによって分析され、これには受信した情報とデータベースのエントリとの照合も含まれる。データベースは、受信した情報が１つまたは複数のデータベースエントリに一致しているかどうかを検査し、それによって、テストすべき制御機器のインタフェースを識別する。

テストすべき制御機器のインタフェースが既知である場合、データベースは、好適には、自身のエントリから、対向インタフェースについて一致するエントリを検索することができる。テストすべき制御機器の各送信インタフェースについては、それぞれの送信インタフェースに対応する受信インタフェースに関する少なくとも１つのエントリが検索され、テストすべき制御機器の各受信インタフェースについては、それぞれの受信インタフェースに対応する送信インタフェースに関する少なくとも１つのエントリが検索される。次いで、見つけられたこれらのエントリから、少なくとも１つのさらなる制御機器のインタフェースに関するエントリが検索される。

ここにおいて残余したままのエントリからは、受信インタフェース要素と送信インタフェース要素とが、インタフェースとして、特に、テストすべき制御機器のインタフェースのための少なくとも１つのさらなる制御機器の対向インタフェースとして生成される。

データベースによるインタフェース要素の生成は、そのようなシミュレーションのプロセスを簡素化させる。なぜなら、このステップが自動的に実行されるからである。複雑な通信マトリックスの際にエラーを引き込みかねないユーザーの存在は必要ない。それどころか、インタフェースの自動生成には、理想的なことにユーザーの対話を必要としないため、ひいてはシミュレーションの生成のための人的労力も軽減させる。好適には、通信マトリックスもインタフェース要素の自動生成によって変更されず、むしろインタフェース要素は、データベースの要素として（好適には抽象化されて）直接生成される。

さらに、インタフェース要素の生成により、その記述が存在しない、アクセスできない、またはまだ利用可能ではない少なくとも１つのさらなる制御機器もシミュレートすることができる。

さらに、ユーザー／検査者は、既に市販されているが新規の制御機器と通信させるべき制御機器の通信もわずかな労力でテストすることができる。

生成されたインタフェースを格納することには、好適には、生成されたインタフェースをデータベースのメモリに、好適には一時メモリに記憶することが含まれる。

次のステップでは、制御機器通信のシミュレーションのための構成を提供することにより、シミュレーションプログラムの作成が準備される。この構成は、シミュレーションプログラムの作成のために重要であるインタフェース、対向インタフェース、設定値、境界パラメータ、および他の重要な情報を予め設定する。この構成には生成されたインタフェース要素も含まれ、これらはテストすべき制御機器の送信および受信インタフェースの記述に対して固有に生成されたものであるため、この構成は、テストすべき制御機器と少なくとも１つのさらなる制御機器との制御機器通信のシミュレーションのための境界条件を確定する。他の制御機器、例えば、テストすべき他の制御機器および／または他のさらなる制御機器について、提供された構成は、通常は使用できない。提供される構成は、特に、テストすべき制御機器と少なくとも１つのさらなる制御機器とからなる冒頭に確定される組み合わせに適合させているが、拡張させることも可能である。

制御機器通信用の実行可能なシミュレーションプログラムを生成することは、通信記述およびそれに含まれるインタフェースおよび他の情報に基づいて、シミュレーションプログラム用の対応するコード発生器を用いてコードを生成することを含む。そのように作成されたシミュレーションプログラムは、ここで、テストすべき制御機器を使用して実行することができ、これによって、テストすべき制御機器と少なくとも１つのさらなる制御機器との通信がシミュレートされる。このシミュレーションは、代替的に、データベースおよび本発明による方法を実施するためのコンピュータプログラムも存在しているコンピュータ（すなわちデータ処理ユニット）上で、またはコンピュータに接続されたシミュレータ上で、例えばHardware-in-the-Loop（ＨＩＬ）シミュレータ上で行われる。

一実施形態では、インタフェース要素は、テストすべき制御機器のインタフェースの識別の際に、対向インタフェースが見つからなかったインタフェースについてのみ生成される。

この実施形態では、データベースは、見つかったエントリの少なくとも１つが、一致する対向インタフェースの通信記述に対応するかどうかを検査する。このことが該当する場合、対応するエントリについてインタフェース要素は生成されない。なぜなら、そのようなインタフェースは既に存在しているからである。

好適には、インタフェースエントリの一致を検査することにより、構成におけるインタフェースの重複的な記述が回避されることで、構成を提供する労力と構成の複雑さとが軽減される。

さらなる実施形態では、生成されたインタフェース要素は、データベースに格納された後、自動的に生成されたインタフェース要素として特徴付けられる。

この特徴付けには、例えばそれらに限定されるものではないが、グラフィカルハイライト、特にグラフィカルユーザインタフェース（ＧＵＩ；graphical user interface）におけるカラーマーキング、生成されたインタフェース要素から特別なリストへのエントリ、生成されたインタフェース要素のグループ化された表示、または生成されたインタフェース要素に結合されたデータベース内のビットの設定によるものが含まれ得る。

好適には、ユーザーにとって、構成および／またはデータベースの中でインタフェースのうちのどの記述が自動的に生成されたのか、およびどの記述がテストすべき制御機器から受信されたのかが見分けられるようにされる。それにより、この特徴付けは、構成やシミュレーションの操作性を向上させる。

さらなる実施形態では、本方法は、指名されたインタフェース要素の選択を受信するステップをさらに含み、この場合、選択において指名されたインタフェース要素のみが生成される。

例えば、ユーザーは、インタフェース要素を生成する前に、どのインタフェース要素が生成されるべきかを確定することができる。テストすべき制御機器は、例えば、１つの通信に対してのみさらなる制御機器の選択によって決定されてもよい。この場合、通信は、制御機器の選択についてのみシミュレートされるだけでよく、そのために、選択に対応する制御機器についてのインタフェース要素のみが生成されるだけでよい。さらなる例では、選択によって確定することができる特定のインタフェースのみがテストされる。

好適には、選択の受信および選択に応じたインタフェース要素の生成により、シミュレーションプログラムの生成が簡素化され、構成の複雑さが軽減される。

一実施形態では、少なくとも１つのさらなる制御機器のシミュレーションのための少なくとも１つのさらなる制御機器のインタフェース要素は、ＨＩＬシミュレーションのための残余バス制御機器のインタフェースとして生成される。

ＨＩＬ（Hardware in the Loop）は、テストすべき制御機器が自身の入出力側を介してシミュレータに接続される手法を表し、この場合、シミュレータは、テストすべき制御機器が現実において通信しなければならなくなる制御機器の環境、ならびに物理的に存在しないさらなる制御機器を表現する。

さらなる実施形態では、少なくとも１つのさらなる制御機器のインタフェース要素は、テストすべき制御機器の機能に対するラピッドコントロールプロトタイピングのためのシミュレーションのために生成される。

ラピッドコントロールプロトタイピングとは、迅速な閉ループおよび開ループ制御開発のためのコンピュータ支援設計手法を表す。

さらなる実施形態では、少なくとも１つのさらなる制御機器の生成されたインタフェース要素は、通信技術に従ってグループ化される。この通信技術は、特にＣＡＮ、ＬＩＮ、またはイーサーネットクラスタを含むことができる。好適には、このグループ化は、テストすべき制御機器のシステム、特にバスシステムに一致させて選択されている。

特性、プロトコル、ハードウェア部品、接続端子、ならびにプロトコル実装は、通信技術に応じて相互に異なる可能性がある。例えば、制御機器またはシミュレーションプログラムは、イーサネットインタフェース用とは異なる、ＣＡＮインタフェース用の特性、ハードウェア部品、接続端子、および／またはプロトコル実装が必要になる。

さらなる態様では、本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信をシミュレートするためのシステムに関する。本システムは、
－データベースと、
－データ処理ユニットと、
－バスまたはネットワーク（例えば、イーサーネットワーク）と、を含んでいる。

さらに、本システムは、上述した実施形態のいずれかに記載の方法を実行するための手段を含んでいる。

本システムは、例えば、すべての部品が固定的に組み込まれた閉鎖型システムを含むことができる。代替的に、本システムは、交換可能な部品を有するシステムとして含むことができる。これらの部品は、タスクに応じて、かつ／またはテストすべき制御機器に応じて適合させることができる。

本システムは、さらなる制御機器との通信がシミュレートされるだけなのでさらなる制御機器を含まない。このシミュレーションについては、少なくとも１つのさらなる制御機器の物理的存在は不要である。

データ処理ユニットは、例えば、ウインドウズ（商標）－ＰＣなどの標準的なデスクトップコンピュータである。制御機器通信のシミュレーションは、データ処理ユニット上で行われるか、あるいは生成されたシミュレーションプログラムがデータ処理ユニットからシミュレータ（例えばＨＩＬシミュレータなど）に転送され、そこでシミュレートされる。

一実施形態では、本システムは、より多くの記憶容量を有する他の記憶デバイスに対して交換することができる拡張可能なメモリ要素、特に大容量の記憶デバイスを含む。さらに、または代替的に、本システムは、メモリスペースを拡張するために、さらなるメモリ要素を収容するように構成されてもよい。

好適には、拡張可能なメモリ要素が、本システムに時間に関して様々な記述を受容かつ／または記憶できるようにさせる。特に、大規模なインタフェースの記述を伴う複数のテストすべき制御機器に対しては、本システムならば、より多くのまたはより複雑な記述に対する所要メモリ領域の増設を可能にさせるという利点が生じる。

さらなる態様では、本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信をシミュレートするためのコンピュータプログラム製品であって、上述の実施形態の１つに記載の方法を実行するための手段を備え、上述のシステムによって実行されるように構成されているコンピュータプログラム製品に関する。

以下では、好適な実施形態を図面に基づき説明する。

テストすべき制御機器とさらなる制御機器との間のシミュレートされた制御機器通信の概略図である。 テストすべき制御機器と２つのさらなる制御機器との間のシミュレートされたさらなる制御機器通信の概略図である。 制御機器通信を作成し、シミュレートするための方法の概略図である。

図１は、テストすべき制御機器１０とさらなる制御機器２０との間のシミュレートされた制御機器通信５０の概略図を示している。

テストすべき制御機器１０は、４つのインタフェース１２，１４，１６，１８を含む。通常、典型的な制御機器は、さらに多くのインタフェースを含んでいる。ここに示されている４つのインタフェース１２，１４，１６，１８は、本発明の原理の説明を意図するものであり、網羅的理解を意図したものではない。インタフェース１２，１４，１６，１８は、例えば、ＣＡＮバス用のＣＡＮフレームの記述であり得る。

４つのインタフェース１２，１４，１６，１８は、送信および／または受信インタフェースとして構成されてもよい。例えば、インタフェース１２および１４は、送信インタフェースであり、インタフェース１６および１８は受信インタフェースである。例えば、インタフェース１４が、ＣＡＮバス通信用のインタフェース記述によって与えられ、「ＣＡＮ－Ｆｒａｍｅｌ＿ＴＸ」で表されてもよい。この場合、ＴＸは、「送信」を象徴するものであり、そのため、送信インタフェースであることは明確である。

さらなる制御機器２０は、自身のインタフェースをシミュレートすることでシミュレートされる。制御機器通信５０のシミュレーションでは、個々のインタフェースの入出力値がシミュレートされ、このためにインタフェースの記述は必要である。それゆえ、さらなる制御機器２０は、制御機器通信５０のシミュレーションのために物理的に存在する必要はない。シミュレーションプログラムの作成については、どのインタフェースをさらなる制御機器２０が有しているかが分かれば十分である。

図１に示されている例では、さらなる制御機器２０は、インタフェース要素２４，２６，２８として生成される３つのインタフェースを含む。これらのインタフェース要素２４，２６，２８の作成の際には、インタフェース１２、１４、１６、および１８に対する対向インタフェースを形成するインタフェース要素のみが生成される。さらなる制御機器は、図示されていないさらなるインタフェースをさらに有することができる。さらなる制御機器２０のさらなるインタフェースは、制御機器通信５０のシミュレーションには重要ではない。

インタフェース要素２４は、インタフェース１４に対する対向インタフェースとして生成されたものであり、このことは、同一の陰影線で特徴付けられている。例えば、インタフェース１４が、送信インタフェース「ＣＡＮ－Ｆｒａｍｅｌ＿ＴＸ」であるならば、このインタフェース要素２４は、受信インタフェースであり、例えば「ＣＡＮ－Ｆｒａｍｅｌ＿ＲＸ」で表され、この場合、「ＲＸ」は「受信」を象徴するものであり、したがって受信インタフェースであることが示される。これらのインタフェースでは、ＣＡＮメッセージの代わりに、例えばイーサネットネットワーク用などのソケット接続を介して伝送されるイーサネットメッセージでもあり得る。

インタフェース要素２６は、インタフェース１６に対する対向インタフェースとして作成されたものである。インタフェース１６が、例えば、受信インタフェースであるならば、インタフェース要素２６は送信インタフェースである。インタフェース１６とインタフェース要素２６との対も同様に同一の陰影線で示されている。

その他の、図示されているインタフェース１４および１６ならびにインタフェース要素２４および２６と同様に、インタフェース１８およびインタフェース要素２８も通信可能な対を形成している。インタフェース１２は、図示の制御機器通信５０では不要である。なぜなら、さらなる制御機器２０は、インタフェース１２との通信用には設計されていないからである。

図２に示されているように、制御機器通信５０のシミュレーションは、テストすべき制御機器１０と、複数のさらなる制御機器と、の通信を含むことができる。図示の実施形態では、テストすべき制御機器１０は、さらなる制御機器３０およびさらなる制御機器４０と通信を行う。

さらなる制御機器３０は、自身のインタフェースの記述によれば、テストすべき制御機器１０と通信可能なインタフェースを含んでいる。それゆえ、インタフェース要素３４は、インタフェース１４に対する対向インタフェースとして生成される。同様にさらなる制御機器４０も、テストすべき制御機器と通信可能な１つのインタフェースのみを含んでいる。したがって、インタフェース要素４８は、インタフェース１８に対する対向インタフェースとして生成される。

図２に示されている実施形態では、インタフェース１２，１６は、制御機器通信５０のシミュレーションでは考慮されない。なぜなら、さらなる制御機器３０，４０は、インタフェース１２，１６と通信するようには設計されていないからである。

図３は、一実施形態による、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも１つのさらなる制御機器との間の制御機器通信をシミュレートするための方法の概略的フローチャートを示している。

第１のステップＳ０２では、テストすべき制御機器のインタフェースの記述をデータベースに転送する。この転送は、特にデジタル伝送を含むことができる。転送された記述において、データベースは、ステップＳ０４において、テストすべき制御機器のインタフェースを識別する。換言すれば、データベースは、テストすべき制御機器が少なくとも１つのさらなる制御機器との通信用に提供するすべてのインタフェースを検索する。

次いで、ステップＳ０６では、テストすべき制御機器の識別されたインタフェースに対応する対向インタフェースを、インタフェース要素の形態で生成する。テストすべき制御機器の各受信インタフェースについて、送信インタフェースとしてのインタフェース要素が生成され、テストすべき制御機器の各送信インタフェースについて、受信インタフェースとしてのインタフェース要素が生成される。これらの生成の後、ステップＳ０８では、これらの生成されたインタフェース要素がデータベースに格納される。

次のステップＳ１０では、データベースが、生成されたインタフェース要素を含む制御機器通信のシミュレーション用の構成を提供する。提供された構成からは、ステップＳ１２において、実行可能なシミュレーションプログラムが生成される。この実行可能なシミュレーションプログラムの生成は、好適にはコード発生器が受け継ぐ。

最後のステップＳ１４では、制御機器通信がシミュレーションプログラムを用いてシミュレートされる。その際には、テストすべき制御機器と少なくとも１つの他の制御機器との間の通信が正常に機能しているかどうか、あるいはテストすべき制御機器のインタフェースを適合させる必要があるかどうかがテストされる。

１０ テストすべき制御機器
１２ インタフェース
１４ インタフェース
１６ インタフェース
１８ インタフェース
２０ さらなる制御機器
２４ インタフェース要素
２６ インタフェース要素
２８ インタフェース要素
３０ さらなる制御機器
３４ インタフェース要素
４０ さらなる制御機器
４８ インタフェース要素
５０ 制御機器通信
Ｓ０２ 記述を転送する
Ｓ０４ インタフェースを識別する
Ｓ０６ インタフェース要素を生成する
Ｓ０８ インタフェース要素をデータベースに格納する
Ｓ１０ 構成を提供する
Ｓ１２ シミュレーションプログラムを生成する
Ｓ１４ 制御機器シミュレーションをシミュレートする

Claims (10)

1. 実行可能なシミュレーションプログラムを生成し、テストすべき制御機器（１０）と少なくとも１つのさらなる制御機器（２０，３０，４０）との間の制御機器通信（５０）をシミュレートするための方法であって、前記テストすべき制御機器（１０）は、前記テストすべき制御機器（１０）の送信および受信インタフェースの記述を有し、前記少なくとも１つのさらなる制御機器のために、前記少なくとも１つのさらなる制御機器の送信および受信インタフェースの記述が、存在しない、アクセスできないまたは利用可能ではなく、前記方法は、以下のステップ、すなわち
   －前記送信および受信インタフェースの記述を、データベースに転送するステップと、
   －前記テストすべき制御機器（１０）のインタフェースを、前記データベースによる記述から識別するステップと、
   －前記テストすべき制御機器の識別された各送信インタフェースについて、少なくとも１つのさらなる制御機器の受信インタフェースとしての受信インタフェース要素を生成するステップと、
   －前記テストすべき制御機器の各受信インタフェースについて、少なくとも１つのさらなる制御機器の送信インタフェースとしての送信インタフェース要素を生成するステップであって、受信または送信インタフェース要素は、通信機能、対応する通信機能呼び出し、通信要素の仕様、または、通信要素の特性によって与えられるステップと、
   －前記生成されたインタフェース要素（２４，２６，２８，３４，４８）を前記データベースに格納するステップと、
   －前記データベースにより、前記テストすべき制御機器（１０）と前記少なくとも１つのさらなる制御機器（２０，３０，４０）との間の前記制御機器通信（５０）のシミュレーション用の構成を提供するステップであって、前記構成は、前記生成されたインタフェース要素（２４，２６，２８，３４，４８）を含むステップと、
   －前記構成を使用して、前記テストすべき制御機器（１０）と前記少なくとも１つのさらなる制御機器（２０，３０，４０）との間の前記制御機器通信（５０）用の実行可能なシミュレーションプログラムを生成するステップと、
   －前記シミュレーションプログラムを用いて、前記テストすべき制御機器（１０）と前記少なくとも１つのさらなる制御機器（２０，３０，４０）との間の前記制御機器通信（５０）をシミュレートするステップと、
   を含む方法。
2. 前記インタフェース要素（２４，２６，２８，３４，４８）は、前記テストすべき制御機器（１０）のインタフェース（１２，１４，１６，１８）の識別の際に、対向インタフェースが識別されなかったインタフェースについてのみ生成される、
   請求項１記載の方法。
3. 前記生成されたインタフェース要素（２４，２６，２８，３４，４８）は、前記データベースに格納された後、自動的に生成されたインタフェース要素（２４，２６，２８，３４，４８）として特徴付けられる、
   請求項１または２記載の方法。
4. 前記方法は、前記インタフェース要素（２４，２６，２８，３４，４８）を生成する前に、以下のステップ、すなわち
   －指名されたインタフェース要素の選択を受信するステップをさらに含み、選択において指名されたインタフェース要素（２４，２６，２８，３４，４８）のみが生成される、
   請求項１から３までのいずれか１項記載の方法。
5. 前記少なくとも１つのさらなる制御機器（２０，３０，４０）の前記インタフェース要素（２４，２６，２８，３４，４８）は、ＨＩＬシミュレーションのための残余バス制御機器のインタフェースとして生成される、
   請求項１から４までのいずれか１項記載の方法。
6. 前記少なくとも１つのさらなる制御機器（２０，３０，４０）の前記インタフェース要素（２４，２６，２８，３４，４８）は、前記テストすべき制御機器（１０）の機能に対するラピッドコントロールプロトタイピングのためのシミュレーションのために生成される、
   請求項１から５までのいずれか１項記載の方法。
7. 前記少なくとも１つのさらなる制御機器（２０，３０，４０）の前記生成されたインタフェース要素（２４，２６，２８，３４，４８）は、通信技術に従ってグループ化される、
   請求項１から６までのいずれか１項記載の方法。
8. 前記通信技術は、ＣＡＮ、ＬＩＮまたはイーサーネットクラスタを含む、
   請求項７記載の方法。
9. 実行可能なシミュレーションプログラムを生成し、テストすべき制御機器（１０）と少なくとも１つのさらなる制御機器（２０，３０，４０）との間の制御機器通信（５０）をシミュレートするためのシステムであって、前記システムは、
   データベースと、
   データ処理ユニットと、
   バスまたはネットワークと、
   を含み、
   前記システムは、請求項１から８までのいずれか１項記載の方法を実行するための手段をさらに含んでいることを特徴とする、
   システム。
10. 実行可能なシミュレーションプログラムを生成し、テストすべき制御機器（１０）と少なくとも１つのさらなる制御機器（２０，３０，４０）との間の制御機器通信（５０）をシミュレートするためのコンピュータプログラムであって、
    請求項１から８までのいずれか１項記載の方法を実行するための手段を備え、請求項９記載のシステムによって実行されるように構成されている、
    コンピュータプログラム。

Images