IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ディスペース デジタル シグナル プロセッシング アンド コントロール エンジニアリング ゲゼルシャフト ミット ベシュレンクテル ハフツングの特許一覧

特表2023-507234テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信のシミュレーション
<>
  • 特表-テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信のシミュレーション 図1
  • 特表-テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信のシミュレーション 図2
  • 特表-テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信のシミュレーション 図3
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-02-21
(54)【発明の名称】テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信のシミュレーション
(51)【国際特許分類】
   G06F 11/36 20060101AFI20230214BHJP
【FI】
G06F11/36 164
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2022548248
(86)(22)【出願日】2021-03-08
(85)【翻訳文提出日】2022-08-08
(86)【国際出願番号】 EP2021055749
(87)【国際公開番号】W WO2021185612
(87)【国際公開日】2021-09-23
(31)【優先権主張番号】102020107141.8
(32)【優先日】2020-03-16
(33)【優先権主張国・地域又は機関】DE
(81)【指定国・地域】
(71)【出願人】
【識別番号】506012213
【氏名又は名称】ディスペース ゲー・エム・ベー・ハー
【氏名又は名称原語表記】dSPACE GmbH
【住所又は居所原語表記】Rathenaustr.26,D-33102 Paderborn, Germany
(74)【代理人】
【識別番号】100114890
【弁理士】
【氏名又は名称】アインゼル・フェリックス=ラインハルト
(74)【代理人】
【識別番号】100098501
【弁理士】
【氏名又は名称】森田 拓
(74)【代理人】
【識別番号】100116403
【弁理士】
【氏名又は名称】前川 純一
(74)【代理人】
【識別番号】100134315
【弁理士】
【氏名又は名称】永島 秀郎
(74)【代理人】
【識別番号】100162880
【弁理士】
【氏名又は名称】上島 類
(72)【発明者】
【氏名】マティアス グリース
【テーマコード(参考)】
5B042
【Fターム(参考)】
5B042GB08
5B042HH06
5B042HH07
5B042HH17
5B042HH38
5B042HH49
(57)【要約】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするための方法であって、ここで、テストすべき制御機器(10)は、テストすべき制御機器(10)の送信および受信インタフェースの記述を有し、ここで、本方法は、以下のステップ、すなわち-送信および受信インタフェースの記述を、データベースに転送するステップと、-テストすべき制御機器(10)のインタフェースを、データベースによる記述から識別するステップと、-テストすべき制御機器の識別された各送信インタフェースについて、さらなる制御機器の受信インタフェースとしての受信インタフェース要素を生成するステップと、-テストすべき制御機器の各受信インタフェースについて、さらなる制御機器の送信インタフェースとしての送信インタフェース要素を生成するステップと、-生成されたインタフェース要素(24,26,28,34,48)をデータベースに格納するステップと、-データベースにより、制御機器通信(50)のシミュレーション用の構成を提供するステップであって、ここで、この構成は、生成されたインタフェース要素(24,26,28,34,48)を含むステップと、-当該構成を使用して、制御機器通信(50)用の実行可能なシミュレーションプログラムを生成するステップと、を含む。
【特許請求の範囲】
【請求項1】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするための方法であって、前記テストすべき制御機器(10)は、前記テストすべき制御機器(10)の送信および受信インタフェースの記述を有し、前記方法は、以下のステップ、すなわち
-前記送信および受信インタフェースの記述を、データベースに転送するステップと、
-前記テストすべき制御機器(10)のインタフェースを、前記データベースによる記述から識別するステップと、
-前記テストすべき制御機器の識別された各送信インタフェースについて、少なくとも1つのさらなる制御機器の受信インタフェースとしての受信インタフェース要素を生成するステップと、
-前記テストすべき制御機器の各受信インタフェースについて、少なくとも1つのさらなる制御機器の送信インタフェースとしての送信インタフェース要素を生成するステップと、
-前記生成されたインタフェース要素(24,26,28,34,48)を前記データベースに格納するステップと、
-前記データベースにより、前記テストすべき制御機器(10)と前記少なくとも1つのさらなる制御機器(20,30,40)との間の前記制御機器通信(50)のシミュレーション用の構成を提供するステップであって、前記構成は、前記生成されたインタフェース要素(24,26,28,34,48)を含むステップと、
-前記構成を使用して、前記テストすべき制御機器(10)と前記少なくとも1つのさらなる制御機器(20,30,40)との間の前記制御機器通信(50)用の実行可能なシミュレーションプログラムを生成するステップと、
-前記シミュレーションプログラムを用いて、前記テストすべき制御機器(10)と前記少なくとも1つのさらなる制御機器(20,30,40)との間の前記制御機器通信(50)をシミュレートするステップと、
を含む方法。
【請求項2】
前記インタフェース要素(24,26,28,34,48)は、前記テストすべき制御機器(10)のインタフェース(12,14,16,18)の識別の際に、対向インタフェースが識別されなかったインタフェースについてのみ生成される、
請求項1記載の方法。
【請求項3】
前記生成されたインタフェース要素(24,26,28,34,48)は、前記データベースに格納された後、自動的に生成されたインタフェース要素(24,26,28,34,48)として特徴付けられる、
請求項1または2記載の方法。
【請求項4】
前記方法は、前記インタフェース要素(24,26,28,34,48)を生成する前に、以下のステップ、すなわち
-指名されたインタフェース要素の選択を受信するステップをさらに含み、選択において指名されたインタフェース要素(24,26,28,34,48)のみが生成される、
請求項1から3までのいずれか1項記載の方法。
【請求項5】
前記少なくとも1つのさらなる制御機器(20,30,40)の前記インタフェース要素(24,26,28,34,48)は、HILシミュレーションのための残余バス制御機器のインタフェースとして生成される、
請求項1から4までのいずれか1項記載の方法。
【請求項6】
前記少なくとも1つのさらなる制御機器(20,30,40)の前記インタフェース要素(24,26,28,34,48)は、前記テストすべき制御機器(10)の機能に対するラピッドコントロールプロトタイピングのためのシミュレーションのために生成される、
請求項1から5までのいずれか1項記載の方法。
【請求項7】
前記少なくとも1つのさらなる制御機器(20,30,40)の前記生成されたインタフェース要素(24,26,28,34,48)は、通信技術、特にCAN、LINまたはイーサーネットクラスタに従ってグループ化される、
請求項1から6までのいずれか1項記載の方法。
【請求項8】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするためのシステムであって、前記システムは、
データベースと、
データ処理ユニットと、
バスまたはネットワークと、
を含み、
前記システムは、請求項1から7までのいずれか1項記載の方法を実行するための手段をさらに含んでいることを特徴とする、
システム。
【請求項9】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするためのコンピュータプログラム製品であって、
請求項1から7までのいずれか1項記載の方法を実行するための手段を備え、請求項8記載のシステムによって実行されるように構成されている、
コンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信をシミュレートするための方法、システム、およびコンピュータプログラム製品に関する。
【背景技術】
【0002】
現代社会では、定期的にデータを交換する様々な技術的機器が使用されている。これらの機器相互の通信は、通常、制御機器によって制御される。そのような制御機器は、特定のさらなる機器だけでなく、多くの様々な機器の通信を引き継ぐことができる。機器との通信に対する前提条件は、制御機器が、それぞれの対向機器に対応するインタフェースとプロトコルとを有し、それらを処理することできることである。換言すれば、制御機器は、送信インタフェースを介して他の機器との通信のために、どのようなデータをどのように送信すべきかと、受信インタフェースを介して受信されたデータをどのように評価することができるかと、を自身に設定する命令を有する必要がある。制御機器には、可及的に多くの様々な機器と通信可能であることが望まれる。
【0003】
制御機器を、例えば車両などに搭載して市場に提供する前には、制御機器の仕様に応じて選択した機器との通信が問題なく機能していることを保証する必要がある。そのため、通常、制御機器は、量産前にテストされる。しかしながら、実際のテストは、非常に手間がかかったり、通信参加者がまだ実際には存在しなかったりするため不可能な場合もある。そのため、それに代わって、対象となるすべてのデバイスとの通信がシミュレートされることが多い。このシミュレーションと後の通信とについては、シミュレートされる機器の対応情報が必要になる。これらの必要な情報は、通常、いわゆる通信マトリックスの形態で存在しており、これらには、機器または機器ネットワーク全体のすべての送信および受信インタフェースの記述が含まれる。テストすべき各制御機器について、テストすべき制御機器と他の制御機器との通信のための命令を含む個別の通信マトリックスが(場合によっては通信マトリックス全体の一部として)存在する。
【0004】
通信マトリックスは、車両全体について一部は自動車メーカーによって作成される。しかしながら、例えば、個々の制御機器のテストについては、制御機器サプライヤの場合のように通信マトリックスがまだ完全には存在しないか、テストすべき個々の制御機器のみにしか存在しない可能性があり、そのため、テスト用の制御機器と他の制御機器との通信に関する重要な情報が存在しない。したがって、そのような通信マトリックス用の情報は、通常、個別にユーザーによって、特にいわゆる「ループテスター内のハードウェア」によって地道に作成されるか、もしくは通信マトリックスに挿入される必要がある。その際、テスターに使用されるバスシステムの機器タイプだけでなく、使用されるネットワーク技術や標準的な記述規則にも注意を払う必要がある。通信マトリックスによって記述されるインタフェースもしくはその記述は、様々な標準規格で規定されている。しかしながら、標準規格における変更に基づいて、1つの同じインタフェースでも異なるマッピング規則が存在する可能性がある。
【0005】
その上さらに、テスターは、買収権や契約上の合意に基づき、制御機器の通信マトリックスまたは制御機器ネットワーク全体を変更する権限を与えられていない場合もある。
【発明の概要】
【発明が解決しようとする課題】
【0006】
これに対する客観的な技術的課題は、制御機器通信のシミュレーションを簡素化し、ならびにエラーの影響の受けやすさ、シミュレーション環境の生成の労力を最小限に抑えることである。
【課題を解決するための手段】
【0007】
この課題は、独立請求項によって解決される。好適な実施形態は、従属小項によって記載される。
【0008】
第1の態様では、本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信をシミュレートするための方法に関する。テストすべき制御機器については、テストすべき制御機器の送信および受信インタフェースの記述が存在する。本方法は、以下のステップ、すなわち
-送信および受信インタフェースの記述を、データベースに転送するステップと、
-テストすべき制御機器のインタフェースを、データベースによる記述から識別するステップと、
-テストすべき制御機器の識別された各送信インタフェースについて、少なくとも1つのさらなる制御機器の受信インタフェースとしての受信インタフェース要素を生成するステップと、
-テストすべき制御機器の各受信インタフェースについて、少なくとも1つのさらなる制御機器の送信インタフェースとしての送信インタフェース要素を生成するステップと、
-生成されたインタフェース要素をデータベースに格納するステップと、
-データベースにより、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信のシミュレーション用の構成を提供するステップであって、ここで、この構成は、テストすべき制御機器のインタフェースおよび生成されたインタフェース要素を含むステップと、
-当該構成を使用して、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信用の実行可能なシミュレーションプログラムを生成するステップと、
-シミュレーションプログラムを用いて、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信をシミュレートするステップと、を含む。
【0009】
本発明の枠内では、テストすべき制御機器とさらなる制御機器とが区別される。テストすべき制御機器は、好適には、後の使用において、複数のさらなる機器との通信が意図される自動車制御機器である。例えば、そのような制御機器は、車両に組み込まれ、例えば、車載コンピュータ、ナビゲーション機器、ABSの制動制御部、ライト制御部、燃料ポンプ制御部、または典型的な車両の他の機器内のさらなる機器の通信を制御する。テストすべき制御機器は、現実のものであってもよいし、仮想のものであってもよい。同様に、本発明の枠内で使用されるバスも、現実のものであってもよいし、仮想のものであってもよい。仮想の制御機器は、擬似的にソフトウェアで実装された制御機器の前段階であり、通常は、既に最終的な量産コードを含んでいる。ただし、将来的なオペレーティングシステムが、通常は既にシミュレートされ、現実的な設計特性が、機能性に対して定義された時間およびトリガー情報に基づいてシミュレートされるとはいえ、制御機器の実際のハードウェアはまだ必要なく、そのため、仮想制御機器は、例えば、シミュレートされたバスに接続することができる(https://www.dspace.com/de/gmb/home/news/engineers-insights/blog-virtuals-ecus-1808.cfm)。
【0010】
テストすべき制御機器をテストするために、1つまたは複数のさらなる制御機器との通信は、それらをシミュレートすることでテストされる。それゆえ、少なくとも1つのさらなる制御機器は、1つのさらなる制御機器または複数のさらなる制御機器を含むことができる。
【0011】
本発明の枠内では、インタフェースおよびインタフェース要素、特に生成されたインタフェース要素という用語が使用される。基本的に、インタフェースおよびインタフェース要素は、制御機器が他の制御機器とデータを交換するために使用する通信機能、対応する機能呼び出し、もしくはメッセージ(パケット)などの通信要素の仕様、および/またはそれらの特性、メッセージタイプ、データタイプ、ポートなどである。インタフェース要素および特に生成されたインタフェース要素は、テストすべき制御機器のインタフェースに対する対向物を形成し、それによって、純粋に仮想的に存在させること、すなわち、物理的に存在する制御機器なしで存在させることによってインタフェースと区別される。少なくとも1つの制御機器との通信がシミュレートされ、そのため、制御機器通信のシミュレーションのための少なくとも1つの制御機器が物理的に存在する必要はなくなる。相応にテストすべき制御機器についても、物理的に完全に存在しなければならないわけではないことがいえる。
【0012】
テストすべき制御機器の送信および受信インタフェースの記述は、好適には、通信記述であり、特に好適には、通信マトリックスの形態で存在する。通信マトリックスは、例えば、XMLスキーマの形態で使用することができる。典型的な通信マトリックスは、それぞれの制御機器のインタフェースを記述する10万までの要素またはそれ以上の要素を含むことができる。
【0013】
データベースは、基本的には、標準的な通信記述を読み込むことを可能にするために必要な情報を含んだ任意のデータベースであってもよい。すなわち、これらの情報は、例えば、Autosar規格および/またはその他の通信規格に関する情報である。さらに、データベースには、テストすべき制御機器のための通信記述は、好適には、通信マトリックスとして様々な標準規格や様々なシミュレートすべき機器のために格納可能である。
【0014】
特に、好適には、ロード後に記述が抽象化された形態でデータベースに格納され、それによって、記述は、使用される標準規格のバージョンに依存することなく使用することができる。テストすべき制御機器のインタフェースも、好適には、抽象化された形態でデータベースに格納される。
【0015】
例えばAUTOSARのような標準規格(本明細書では通信技術とも称する)は、年に数回変更および/または更新することができる。例えば、AUTOSAR規格3.1.4に対応する通信マトリックスにおける1つの同じインタフェースは、AUTOSAR規格4.3.1に対応する通信マトリックスにおけるものとは異なってマッピングされている。例えばバージョンに依存しない表示形態など、インタフェース記述の抽象化によって、バージョンに依存しない構成が可能になる。
【0016】
好適には、記述の抽象化と、生成されたインタフェース要素への抽象化された記述のマッピングと、によって、実行可能なシミュレーションプログラムの生成が容易になる。抽象化することにより、すべての可能な通信技術バージョンに対してすべての可能な記述をデータベースに格納する必要がなくなり、このことは、データベースの所要の規模を低減させる。
【0017】
好適には、インタフェースの記述を抽象化し、インタフェース要素を生成し、かつ/または本方法の他のステップを実行するために、処理ユニット、例えばパーソナルコンピュータPCのプロセッサユニットが設けられている。
【0018】
本発明によれば、最初に、テストすべき制御機器の記述がデータベースに転送される。換言すれば、データベースは、テストすべき制御機器についてのすべての情報を、制御機器に通知される対応する記述の形態で受信する。
【0019】
転送された記述は、データベースによって分析され、これには受信した情報とデータベースのエントリとの照合も含まれる。データベースは、受信した情報が1つまたは複数のデータベースエントリに一致しているかどうかを検査し、それによって、テストすべき制御機器のインタフェースを識別する。
【0020】
テストすべき制御機器のインタフェースが既知である場合、データベースは、好適には、自身のエントリから、対向インタフェースについて一致するエントリを検索することができる。テストすべき制御機器の各送信インタフェースについては、それぞれの送信インタフェースに対応する受信インタフェースに関する少なくとも1つのエントリが検索され、テストすべき制御機器の各受信インタフェースについては、それぞれの受信インタフェースに対応する送信インタフェースに関する少なくとも1つのエントリが検索される。次いで、見つけられたこれらのエントリから、少なくとも1つのさらなる制御機器のインタフェースに関するエントリが検索される。
【0021】
ここにおいて残余したままのエントリからは、受信インタフェース要素と送信インタフェース要素とが、インタフェースとして、特に、テストすべき制御機器のインタフェースのための少なくとも1つのさらなる制御機器の対向インタフェースとして生成される。
【0022】
データベースによるインタフェース要素の生成は、そのようなシミュレーションのプロセスを簡素化させる。なぜなら、このステップが自動的に実行されるからである。複雑な通信マトリックスの際にエラーを引き込みかねないユーザーの存在は必要ない。それどころか、インタフェースの自動生成には、理想的なことにユーザーの対話を必要としないため、ひいてはシミュレーションの生成のための人的労力も軽減させる。好適には、通信マトリックスもインタフェース要素の自動生成によって変更されず、むしろインタフェース要素は、データベースの要素として(好適には抽象化されて)直接生成される。
【0023】
さらに、インタフェース要素の生成により、その記述が存在しない、アクセスできない、またはまだ利用可能ではない少なくとも1つのさらなる制御機器もシミュレートすることができる。
【0024】
さらに、ユーザー/検査者は、既に市販されているが新規の制御機器と通信させるべき制御機器の通信もわずかな労力でテストすることができる。
【0025】
生成されたインタフェースを格納することには、好適には、生成されたインタフェースをデータベースのメモリに、好適には一時メモリに記憶することが含まれる。
【0026】
次のステップでは、制御機器通信のシミュレーションのための構成を提供することにより、シミュレーションプログラムの作成が準備される。この構成は、シミュレーションプログラムの作成のために重要であるインタフェース、対向インタフェース、設定値、境界パラメータ、および他の重要な情報を予め設定する。この構成には生成されたインタフェース要素も含まれ、これらはテストすべき制御機器の送信および受信インタフェースの記述に対して固有に生成されたものであるため、この構成は、テストすべき制御機器と少なくとも1つのさらなる制御機器との制御機器通信のシミュレーションのための境界条件を確定する。他の制御機器、例えば、テストすべき他の制御機器および/または他のさらなる制御機器について、提供された構成は、通常は使用できない。提供される構成は、特に、テストすべき制御機器と少なくとも1つのさらなる制御機器とからなる冒頭に確定される組み合わせに適合させているが、拡張させることも可能である。
【0027】
制御機器通信用の実行可能なシミュレーションプログラムを生成することは、通信記述およびそれに含まれるインタフェースおよび他の情報に基づいて、シミュレーションプログラム用の対応するコード発生器を用いてコードを生成することを含む。そのように作成されたシミュレーションプログラムは、ここで、テストすべき制御機器を使用して実行することができ、これによって、テストすべき制御機器と少なくとも1つのさらなる制御機器との通信がシミュレートされる。このシミュレーションは、代替的に、データベースおよび本発明による方法を実施するためのコンピュータプログラムも存在しているコンピュータ(すなわちデータ処理ユニット)上で、またはコンピュータに接続されたシミュレータ上で、例えばHardware-in-the-Loop(HIL)シミュレータ上で行われる。
【0028】
一実施形態では、インタフェース要素は、テストすべき制御機器のインタフェースの識別の際に、対向インタフェースが見つからなかったインタフェースについてのみ生成される。
【0029】
この実施形態では、データベースは、見つかったエントリの少なくとも1つが、一致する対向インタフェースの通信記述に対応するかどうかを検査する。このことが該当する場合、対応するエントリについてインタフェース要素は生成されない。なぜなら、そのようなインタフェースは既に存在しているからである。
【0030】
好適には、インタフェースエントリの一致を検査することにより、構成におけるインタフェースの重複的な記述が回避されることで、構成を提供する労力と構成の複雑さとが軽減される。
【0031】
さらなる実施形態では、生成されたインタフェース要素は、データベースに格納された後、自動的に生成されたインタフェース要素として特徴付けられる。
【0032】
この特徴付けには、例えばそれらに限定されるものではないが、グラフィカルハイライト、特にグラフィカルユーザインタフェース(GUI;graphical user interface)におけるカラーマーキング、生成されたインタフェース要素から特別なリストへのエントリ、生成されたインタフェース要素のグループ化された表示、または生成されたインタフェース要素に結合されたデータベース内のビットの設定によるものが含まれ得る。
【0033】
好適には、ユーザーにとって、構成および/またはデータベースの中でインタフェースのうちのどの記述が自動的に生成されたのか、およびどの記述がテストすべき制御機器から受信されたのかが見分けられるようにされる。それにより、この特徴付けは、構成やシミュレーションの操作性を向上させる。
【0034】
さらなる実施形態では、本方法は、指名されたインタフェース要素の選択を受信するステップをさらに含み、この場合、選択において指名されたインタフェース要素のみが生成される。
【0035】
例えば、ユーザーは、インタフェース要素を生成する前に、どのインタフェース要素が生成されるべきかを確定することができる。テストすべき制御機器は、例えば、1つの通信に対してのみさらなる制御機器の選択によって決定されてもよい。この場合、通信は、制御機器の選択についてのみシミュレートされるだけでよく、そのために、選択に対応する制御機器についてのインタフェース要素のみが生成されるだけでよい。さらなる例では、選択によって確定することができる特定のインタフェースのみがテストされる。
【0036】
好適には、選択の受信および選択に応じたインタフェース要素の生成により、シミュレーションプログラムの生成が簡素化され、構成の複雑さが軽減される。
【0037】
一実施形態では、少なくとも1つのさらなる制御機器のシミュレーションのための少なくとも1つのさらなる制御機器のインタフェース要素は、HILシミュレーションのための残余バス制御機器のインタフェースとして生成される。
【0038】
HIL(Hardware in the Loop)は、テストすべき制御機器が自身の入出力側を介してシミュレータに接続される手法を表し、この場合、シミュレータは、テストすべき制御機器が現実において通信しなければならなくなる制御機器の環境、ならびに物理的に存在しないさらなる制御機器を表現する。
【0039】
さらなる実施形態では、少なくとも1つのさらなる制御機器のインタフェース要素は、テストすべき制御機器の機能に対するラピッドコントロールプロトタイピングのためのシミュレーションのために生成される。
【0040】
ラピッドコントロールプロトタイピングとは、迅速な閉ループおよび開ループ制御開発のためのコンピュータ支援設計手法を表す。
【0041】
さらなる実施形態では、少なくとも1つのさらなる制御機器の生成されたインタフェース要素は、通信技術に従ってグループ化される。この通信技術は、特にCAN、LIN、またはイーサーネットクラスタを含むことができる。好適には、このグループ化は、テストすべき制御機器のシステム、特にバスシステムに一致させて選択されている。
【0042】
特性、プロトコル、ハードウェア部品、接続端子、ならびにプロトコル実装は、通信技術に応じて相互に異なる可能性がある。例えば、制御機器またはシミュレーションプログラムは、イーサネットインタフェース用とは異なる、CANインタフェース用の特性、ハードウェア部品、接続端子、および/またはプロトコル実装が必要になる。
【0043】
さらなる態様では、本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信をシミュレートするためのシステムに関する。本システムは、
-データベースと、
-データ処理ユニットと、
-バスまたはネットワーク(例えば、イーサーネットワーク)と、を含んでいる。
【0044】
さらに、本システムは、上述した実施形態のいずれかに記載の方法を実行するための手段を含んでいる。
【0045】
本システムは、例えば、すべての部品が固定的に組み込まれた閉鎖型システムを含むことができる。代替的に、本システムは、交換可能な部品を有するシステムとして含むことができる。これらの部品は、タスクに応じて、かつ/またはテストすべき制御機器に応じて適合させることができる。
【0046】
本システムは、さらなる制御機器との通信がシミュレートされるだけなのでさらなる制御機器を含まない。このシミュレーションについては、少なくとも1つのさらなる制御機器の物理的存在は不要である。
【0047】
データ処理ユニットは、例えば、ウインドウズ(商標)-PCなどの標準的なデスクトップコンピュータである。制御機器通信のシミュレーションは、データ処理ユニット上で行われるか、あるいは生成されたシミュレーションプログラムがデータ処理ユニットからシミュレータ(例えばHILシミュレータなど)に転送され、そこでシミュレートされる。
【0048】
一実施形態では、本システムは、より多くの記憶容量を有する他の記憶デバイスに対して交換することができる拡張可能なメモリ要素、特に大容量の記憶デバイスを含む。さらに、または代替的に、本システムは、メモリスペースを拡張するために、さらなるメモリ要素を収容するように構成されてもよい。
【0049】
好適には、拡張可能なメモリ要素が、本システムに時間に関して様々な記述を受容かつ/または記憶できるようにさせる。特に、大規模なインタフェースの記述を伴う複数のテストすべき制御機器に対しては、本システムならば、より多くのまたはより複雑な記述に対する所要メモリ領域の増設を可能にさせるという利点が生じる。
【0050】
さらなる態様では、本発明は、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信をシミュレートするためのコンピュータプログラム製品であって、上述の実施形態の1つに記載の方法を実行するための手段を備え、上述のシステムによって実行されるように構成されているコンピュータプログラム製品に関する。
【0051】
以下では、好適な実施形態を図面に基づき説明する。
【図面の簡単な説明】
【0052】
図1】テストすべき制御機器とさらなる制御機器との間のシミュレートされた制御機器通信の概略図である。
図2】テストすべき制御機器と2つのさらなる制御機器との間のシミュレートされたさらなる制御機器通信の概略図である。
図3】制御機器通信を作成し、シミュレートするための方法の概略図である。
【発明を実施するための形態】
【0053】
図1は、テストすべき制御機器10とさらなる制御機器20との間のシミュレートされた制御機器通信50の概略図を示している。
【0054】
テストすべき制御機器10は、4つのインタフェース12,14,16,18を含む。通常、典型的な制御機器は、さらに多くのインタフェースを含んでいる。ここに示されている4つのインタフェース12,14,16,18は、本発明の原理の説明を意図するものであり、網羅的理解を意図したものではない。インタフェース12,14,16,18は、例えば、CANバス用のCANフレームの記述であり得る。
【0055】
4つのインタフェース12,14,16,18は、送信および/または受信インタフェースとして構成されてもよい。例えば、インタフェース12および14は、送信インタフェースであり、インタフェース16および18は受信インタフェースである。例えば、インタフェース14が、CANバス通信用のインタフェース記述によって与えられ、「CAN-Framel_TX」で表されてもよい。この場合、TXは、「送信」を象徴するものであり、そのため、送信インタフェースであることは明確である。
【0056】
さらなる制御機器20は、自身のインタフェースをシミュレートすることでシミュレートされる。制御機器通信50のシミュレーションでは、個々のインタフェースの入出力値がシミュレートされ、このためにインタフェースの記述は必要である。それゆえ、さらなる制御機器20は、制御機器通信50のシミュレーションのために物理的に存在する必要はない。シミュレーションプログラムの作成については、どのインタフェースをさらなる制御機器20が有しているかが分かれば十分である。
【0057】
図1に示されている例では、さらなる制御機器20は、インタフェース要素24,26,28として生成される3つのインタフェースを含む。これらのインタフェース要素24,26,28の作成の際には、インタフェース12、14、16、および18に対する対向インタフェースを形成するインタフェース要素のみが生成される。さらなる制御機器は、図示されていないさらなるインタフェースをさらに有することができる。さらなる制御機器20のさらなるインタフェースは、制御機器通信50のシミュレーションには重要ではない。
【0058】
インタフェース要素24は、インタフェース14に対する対向インタフェースとして生成されたものであり、このことは、同一の陰影線で特徴付けられている。例えば、インタフェース14が、送信インタフェース「CAN-Framel_TX」であるならば、このインタフェース要素24は、受信インタフェースであり、例えば「CAN-Framel_RX」で表され、この場合、「RX」は「受信」を象徴するものであり、したがって受信インタフェースであることが示される。これらのインタフェースでは、CANメッセージの代わりに、例えばイーサネットネットワーク用などのソケット接続を介して伝送されるイーサネットメッセージでもあり得る。
【0059】
インタフェース要素26は、インタフェース16に対する対向インタフェースとして作成されたものである。インタフェース16が、例えば、受信インタフェースであるならば、インタフェース要素26は送信インタフェースである。インタフェース16とインタフェース要素26との対も同様に同一の陰影線で示されている。
【0060】
その他の、図示されているインタフェース14および16ならびにインタフェース要素24および26と同様に、インタフェース18およびインタフェース要素28も通信可能な対を形成している。インタフェース12は、図示の制御機器通信50では不要である。なぜなら、さらなる制御機器20は、インタフェース12との通信用には設計されていないからである。
【0061】
図2に示されているように、制御機器通信50のシミュレーションは、テストすべき制御機器10と、複数のさらなる制御機器と、の通信を含むことができる。図示の実施形態では、テストすべき制御機器10は、さらなる制御機器30およびさらなる制御機器40と通信を行う。
【0062】
さらなる制御機器30は、自身のインタフェースの記述によれば、テストすべき制御機器10と通信可能なインタフェースを含んでいる。それゆえ、インタフェース要素34は、インタフェース14に対する対向インタフェースとして生成される。同様にさらなる制御機器40も、テストすべき制御機器と通信可能な1つのインタフェースのみを含んでいる。したがって、インタフェース要素48は、インタフェース18に対する対向インタフェースとして生成される。
【0063】
図2に示されている実施形態では、インタフェース12,16は、制御機器通信50のシミュレーションでは考慮されない。なぜなら、さらなる制御機器30,40は、インタフェース12,16と通信するようには設計されていないからである。
【0064】
図3は、一実施形態による、実行可能なシミュレーションプログラムを生成し、テストすべき制御機器と少なくとも1つのさらなる制御機器との間の制御機器通信をシミュレートするための方法の概略的フローチャートを示している。
【0065】
第1のステップS02では、テストすべき制御機器のインタフェースの記述をデータベースに転送する。この転送は、特にデジタル伝送を含むことができる。転送された記述において、データベースは、ステップS04において、テストすべき制御機器のインタフェースを識別する。換言すれば、データベースは、テストすべき制御機器が少なくとも1つのさらなる制御機器との通信用に提供するすべてのインタフェースを検索する。
【0066】
次いで、ステップS06では、テストすべき制御機器の識別されたインタフェースに対応する対向インタフェースを、インタフェース要素の形態で生成する。テストすべき制御機器の各受信インタフェースについて、送信インタフェースとしてのインタフェース要素が生成され、テストすべき制御機器の各送信インタフェースについて、受信インタフェースとしてのインタフェース要素が生成される。これらの生成の後、ステップS08では、これらの生成されたインタフェース要素がデータベースに格納される。
【0067】
次のステップS10では、データベースが、生成されたインタフェース要素を含む制御機器通信のシミュレーション用の構成を提供する。提供された構成からは、ステップS12において、実行可能なシミュレーションプログラムが生成される。この実行可能なシミュレーションプログラムの生成は、好適にはコード発生器が受け継ぐ。
【0068】
最後のステップS14では、制御機器通信がシミュレーションプログラムを用いてシミュレートされる。その際には、テストすべき制御機器と少なくとも1つの他の制御機器との間の通信が正常に機能しているかどうか、あるいはテストすべき制御機器のインタフェースを適合させる必要があるかどうかがテストされる。
【符号の説明】
【0069】
10 テストすべき制御機器
12 インタフェース
14 インタフェース
16 インタフェース
18 インタフェース
20 さらなる制御機器
24 インタフェース要素
26 インタフェース要素
28 インタフェース要素
30 さらなる制御機器
34 インタフェース要素
40 さらなる制御機器
48 インタフェース要素
50 制御機器通信
S02 記述を転送する
S04 インタフェースを識別する
S06 インタフェース要素を生成する
S08 インタフェース要素をデータベースに格納する
S10 構成を提供する
S12 シミュレーションプログラムを生成する
S14 制御機器シミュレーションをシミュレートする
図1
図2
図3
【手続補正書】
【提出日】2022-08-08
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするための方法であって、前記テストすべき制御機器(10)は、前記テストすべき制御機器(10)の送信および受信インタフェースの記述を有し、前記少なくとも1つのさらなる制御機器のために、前記少なくとも1つのさらなる制御機器の送信および受信インタフェースの記述が、存在しない、アクセスできないまたは利用可能ではなく、前記方法は、以下のステップ、すなわち
-前記送信および受信インタフェースの記述を、データベースに転送するステップと、
-前記テストすべき制御機器(10)のインタフェースを、前記データベースによる記述から識別するステップと、
-前記テストすべき制御機器の識別された各送信インタフェースについて、少なくとも1つのさらなる制御機器の受信インタフェースとしての受信インタフェース要素を生成するステップと、
-前記テストすべき制御機器の各受信インタフェースについて、少なくとも1つのさらなる制御機器の送信インタフェースとしての送信インタフェース要素を生成するステップであって、受信または送信インタフェース要素は、通信機能、対応する通信機能呼び出し、通信要素の仕様、または、通信要素の特性によって与えられるステップと、
-前記生成されたインタフェース要素(24,26,28,34,48)を前記データベースに格納するステップと、
-前記データベースにより、前記テストすべき制御機器(10)と前記少なくとも1つのさらなる制御機器(20,30,40)との間の前記制御機器通信(50)のシミュレーション用の構成を提供するステップであって、前記構成は、前記生成されたインタフェース要素(24,26,28,34,48)を含むステップと、
-前記構成を使用して、前記テストすべき制御機器(10)と前記少なくとも1つのさらなる制御機器(20,30,40)との間の前記制御機器通信(50)用の実行可能なシミュレーションプログラムを生成するステップと、
-前記シミュレーションプログラムを用いて、前記テストすべき制御機器(10)と前記少なくとも1つのさらなる制御機器(20,30,40)との間の前記制御機器通信(50)をシミュレートするステップと、
を含む方法。
【請求項2】
前記インタフェース要素(24,26,28,34,48)は、前記テストすべき制御機器(10)のインタフェース(12,14,16,18)の識別の際に、対向インタフェースが識別されなかったインタフェースについてのみ生成される、
請求項1記載の方法。
【請求項3】
前記生成されたインタフェース要素(24,26,28,34,48)は、前記データベースに格納された後、自動的に生成されたインタフェース要素(24,26,28,34,48)として特徴付けられる、
請求項1または2記載の方法。
【請求項4】
前記方法は、前記インタフェース要素(24,26,28,34,48)を生成する前に、以下のステップ、すなわち
-指名されたインタフェース要素の選択を受信するステップをさらに含み、選択において指名されたインタフェース要素(24,26,28,34,48)のみが生成される、
請求項1から3までのいずれか1項記載の方法。
【請求項5】
前記少なくとも1つのさらなる制御機器(20,30,40)の前記インタフェース要素(24,26,28,34,48)は、HILシミュレーションのための残余バス制御機器のインタフェースとして生成される、
請求項1から4までのいずれか1項記載の方法。
【請求項6】
前記少なくとも1つのさらなる制御機器(20,30,40)の前記インタフェース要素(24,26,28,34,48)は、前記テストすべき制御機器(10)の機能に対するラピッドコントロールプロトタイピングのためのシミュレーションのために生成される、
請求項1から5までのいずれか1項記載の方法。
【請求項7】
前記少なくとも1つのさらなる制御機器(20,30,40)の前記生成されたインタフェース要素(24,26,28,34,48)は、通信技術、特にCAN、LINまたはイーサーネットクラスタに従ってグループ化される、
請求項1から6までのいずれか1項記載の方法。
【請求項8】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするためのシステムであって、前記システムは、
データベースと、
データ処理ユニットと、
バスまたはネットワークと、
を含み、
前記システムは、請求項1から7までのいずれか1項記載の方法を実行するための手段をさらに含んでいることを特徴とする、
システム。
【請求項9】
実行可能なシミュレーションプログラムを生成し、テストすべき制御機器(10)と少なくとも1つのさらなる制御機器(20,30,40)との間の制御機器通信(50)をシミュレートするためのコンピュータプログラム製品であって、
請求項1から7までのいずれか1項記載の方法を実行するための手段を備え、請求項8記載のシステムによって実行されるように構成されている、
コンピュータプログラム製品。
【国際調査報告】