(57)【要約】【課題】同一の指示子を一貫して使用することにより概観性が良好になる一方で、周辺モデルのコンパイル時に生成された記述は、該周辺モデルに比類する似たような静的特性を有するという欠点があるため、テスト構成体全体では指示子を動的に使用するための方法を提供する。【解決手段】第１のオブジェクトと同種類または同様の種類の第２の種類のオブジェクトを生成し、第１の種類のオブジェクトおよび第２の種類のオブジェクトを管理装置によって、該システムのうち少なくとも１つに対して供給する方法。【選択図】図４
2008159058.tif 000002
【特許請求の範囲】
【請求項１】
テスト構成体においてオブジェクトを動的に処理する方法であって、
該テスト構成体は、双方向交換を行う少なくとも２つのシステムと、テスト対象である少なくとも１つの別のシステムとから成り、
第１の種類のオブジェクトは、第１のシステムで実行される周辺モデルに所属し、
該第１のオブジェクトをテストモデルによって処理する形式の方法において、
該第１のオブジェクトに対して同種類または同様の種類の第２の種類のオブジェクトを生成し、
該第１の種類のオブジェクトおよび第２の種類のオブジェクトを管理装置によって、該システムのうち少なくとも１つに対して供給することを特徴とする方法。
【請求項２】
前記第２の種類のオブジェクトの生成を、前記テストモデルおよび／または該テストモデルの機能的構成部分によって開始および／または実行する、請求項１記載の方法。
【請求項３】
前記第２の種類のオブジェクトの生成を、前記テストモデルおよび／または該テストモデルの機能的構成部分によって、該テストモデルの開始時または該テストモデルの実行中に開始および／または実行する、請求項１または２記載の方法。
【請求項４】
前記第２の種類のオブジェクトを前記テストモデルの終了とともに消去する、請求項１から３までのいずれか１項記載の方法。
【請求項５】
前記第２の種類のオブジェクトを前記テストモデルによって消去するかまたは変更する、請求項１から４までのいずれか１項記載の方法。
【請求項６】
第２の種類のオブジェクトの適用または変化または消去を、前記管理装置によって別のシステムに対して提供する、請求項１から５までのいずれか１項記載の方法。
【請求項７】
第２の種類のオブジェクトを第２の種類の別のオブジェクトおよび／または第１の種類の別のオブジェクトと結合する、請求項１から６までのいずれか１項記載の方法。
【請求項８】
第２の種類のオブジェクトを計算規則および／または関数の形態でインプリメントする、請求項１から７までのいずれか１項記載の方法。
【請求項９】
前記第２のシステムは、実験ソフトウェアを実行するのに適した標準的ＰＣである、請求項１から８までのいずれか１項記載の方法。
【請求項１０】
管理装置が、前記第１の種類のオブジェクトおよび第２の種類のオブジェクトに関する情報の供給をアクティブまたはパッシブに行う、請求項１から９までのいずれか１項記載の方法。
【請求項１１】
前記管理装置の呼び出しおよび終了は、前記テストモデルの開始および終了に結びつけられている、請求項１から１０までのいずれか１項記載の管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テスト構成体においてオブジェクトを動的に処理するための次のような方法に関する。すなわち、テスト構成体は、双方向交換を行う少なくとも２つのシステムと、テスト対象である少なくとも１つの別のシステムとから成り、第１の種類のオブジェクトは、第１のシステム上で実行される周辺モデルに所属し、これらのオブジェクトをテストモデルによって処理する方法に関する。さらに本発明は、オブジェクトを処理するための管理装置にも関する。
【背景技術】
【０００２】
システムをテストするためのテスト構成の方法および装置は、実用的に種々の形態で公知になっており、とりわけ、電子システム開発の幅広い分野における応用研究および産業的な開発と電子システムの使用とにおいて使用される。これらは、非常に幅広い意味でプロセス制御タスクを解決しなければならないすべての場所で、幅広く普及されて適用される。「制御システム」という概念は以下では、基本的に測定タスク、制御タスク、調整タスク、較正タスクに使用される技術的な装置を表す総称として使用される。最も広い意味では一般的に、プログラミング可能な電子的システムを指す。プログラミング可能な電子的システムは、たとえば自動車アプリケーションの領域では制御回路と称される。「制御システム」という概念は、システム理論上の意味で狭義に開ループ制御として定義されるものには限定されず、通常は閉ループ制御が制御システム上で実行される。
【０００３】
より良く理解できるようにするため、本発明の基礎となる思想を、自動車関連で使用される制御装置に基づいて説明する。これは、本発明の思想がこの適用分野に限定されることを意味しない。
【０００４】
このようなテスト構成の重要な特徴は、少なくとも２つの類似する個別システムと、通常は双方向のデータ接続とが存在し、該システム間に、システムに起因する固有の依存性が存在することである。これらの個別システムは独立して応答および作業できることが多いが、強制的ではない。システムに起因するこのような依存性はたとえば、分散されたテスト装置上における複雑な周辺モデルの動作によって生じ、複数のテスト装置上で実行される全体モデルはコンテキスト上の（システムに起因する）関連性を有することが明らかになる。別の依存関係の形態、たとえば実行を監視する実験システム（以下では実験ＰＣと称する）と、実行に適したテストシステム（以下ではテスト装置と称する）も考えられる。
【０００５】
周辺モデルは以下では、専用のアルゴリズムを成す次のようなプログラムを指す。すなわち、特別に設けられたコンテキストで機能性を呈し、適切なシミュレーションソフトウェアによって、たとえば制御システムである別のシステムと、該制御システムの機能を識別できるように相互作用するプログラムを指す。公知の一例に、たとえば自動車のエンジン制御装置をテストするための周辺モデルがある。この例では周辺モデルは、制御装置の機能に必要な詳細忠実性で、該制御装置によって制御されるエンジンを表す。周辺モデルは制御装置のセンサ系を操作して、該制御装置のアクチュエータ系に対して（仮想的に）応答する。必ずしも、周辺モデルは制御システムと直接相互作用しなくてもよく、上記の例の拡大解釈では、エンジン制御装置をテスト対象のエンジンに接続し、このエンジンも、車両の拡張された周辺モデルに接続することも考えられる。この周辺モデルはたとえば、センサ系およびアクチュエータ系および機能が所属するトランスミッションまたはシャシを表す。
【０００６】
最後に大量生産で使用される制御システムの開発は、たいていは以下のステップで行われる。関数開発では、数学的なモデリングツールを使用してまずは、後のターゲットハードウェアおよびターゲット環境から抽象化された制御回路構想を行う。このようにして開発された制御回路は、同様に数学的モデルとして存在するだけのプロセスイメージによるシミュレーションでのみ検査される。
【０００７】
いわゆるラピッドコントロールプロトタイピング（ＲＣＰ）である次のステップでは、抽象的な前記制御回路構想は符号発生器によって、実行可能なプログラムに変換される。この実行可能なプログラムは、通常は非常に高性能であり、最終的に使用されるシリアル制御システムとは比較できないほどであるリアルタイム可能な制御システム上で動作する。このようなＲＣＰ制御システムは、適切なＩ／Ｏインタフェースを介して、影響すべき対象である実際のプロセスと相互作用する。この結果が十分である場合、適切に構成された符号発生器を介して、制御回路の数学的モデルから実行可能な符号がシリアル制御システムに対して発生され、シリアルアプリケーションで実際に使用される制御システムには、シリアルアプリケーションでも備えなければならない機能を設けることができる。
【０００８】
しかし、シリアル制御システムを実際のプロセスに関連して検査する前に、いわゆるハードウェア・イン・ループテスト（ＨＩＬ）である詳細なテストをシリアル制御システムに施す。ＨＩＬテストでは、（シリアル）制御システムをテスト装置に接続し、該テスト装置上で周辺モデルを使用して、テストすべき制御システムの機能的な周辺をシミュレートする。すなわち、テスト装置を介して周辺モデルデータを制御システムへ出力し、該制御システムからデータチャネルを介して制御システムデータを取り込むことによって、周辺モデルとテスト装置とを接続することにより、制御システムは仮想的な周辺と相互作用する。
【０００９】
制御システムは、たとえば自動車アプリケーションの領域ではエンジン制御装置とすることができる。その際にはエンジン制御装置の周辺モデルは、テスト装置上でリアルタイムで動作するエンジンモデルである。また、仮想的な環境で移動される車両全体の走行ダイナミクスモデルおよびエンジンダイナミクスモデルとすることができる。周辺モデルは基本的に、テストすべき制御システムのすべてのインタフェースをカバーする必要はなく、むしろ、周辺の任意の部分を実際のコンポーネントによってインプリメントすることもできる。前記の例ではこのことは、テストすべき制御システムは実際には、実際の内燃機関に接続されるのに対し、エンジンの周辺（たとえばトランスミッション、駆動系統、シャシおよび道路）は、テスト装置上で動作する周辺モデルによってシミュレートされることを意味することができる。すなわち、周辺モデルは完全な周辺モデルである必要はなく、テストすべき制御システムに直接接続および／または間接接続することができる。
【００１０】
このような周辺モデルの開発の枠内では現在、このようなモデルをモデリング環境で作成することが普通である。このためにはたとえば、ＭａｔＬａｂ／Ｓｉｍｕｌｉｎｋ（TheMathworks Inc.: "Simulink 6.5 (R2006b)"、２００６年９月）を使用することが広く知られている。このようなモデリング環境では、いわゆる「ブロック」によって周辺モデルの機能が表記され、接続要素は制御フローおよび／またはデータフローを表す。作成されたモデルをテスト構成体で有意に使用できるようにするためには、モデルを翻訳された状態で、適切なシステム上で実行しなければならない。このような周辺モデルの通常の大きさは数千個のブロックであることにより、コンパイル時間は数時間に及ぶことがあるため、とりわけ比較的大きな周辺モデルのフレキシビリティは、パラメータ化の手法は別として、不足することが欠点であると考えられる。
【００１１】
たとえばモニタまたはキーボード等のユーザに適したインタフェースなしで電子技術的システム／メカトロニックシステムで使用されることが多い計算システム上で実行するためにプログラムコードを翻訳するためには、通常は、ターゲット計算システムのへり条件およびフレーム条件の特性を正確に記述しなければならない。というのも、生成されたプログラムはターゲット計算システムで直接実行されることが多く、従来のパーソナルコンピュータ上でのプログラム実行によって知られているように、オペレーションシステムにおいてサポートされる周辺では実行されないからである。通常は、周辺モデルの実行に適したシステムはこのような計算システムに相応し、たとえばセンサ系またはアクチュエータ系のための端子等である専用のハードウェア要素を有しシミュレーションに特別に適したシステムであることが多い。
【００１２】
ターゲット計算システムの固定的なフレーム条件と、該ターゲットシステムのコンピュータアーキテクチャと、実行すべきプログラムコードのプロセッサ近傍のコンパイル‐ここでは周辺モデル‐とに起因して、このようなターゲット計算システムにおける実行は一般的には決定論的と見なされる。すなわち、実行の再現性が保証されており、かつ、システムのどのコンポーネントを考慮して実行が行われるかが実行前にすでに決定することができる。
【００１３】
ここに記載されたテスト構成の枠内では、実験ＰＣと適切なソフトウェアとによって、たとえば ControlDesk（dSPACE GmbH："ControlDesk 3.0"; ２００６年１２月１４日の Release 5.2）によって、テスト対象である制御装置の応答を監視することが広く知れ渡っている。また、別の適切なソフトウェアによって、たとえば AutomationDesk（dSPACE GmbH: "Automation-Desk 1.4", ２００６年１２月１４日の Release 5.2）によって、テスト対象である制御装置の応答を、子細に及ぶ幅で検出できるように、周辺モデルに所期のように影響することも考えられる。周辺モデルにこのように所期のように影響するためには、周辺モデルの構造の十分な知識が必要とされ、とりわけ周辺モデルの個々の変数の記憶位置の十分な知識が必要とされる。
【００１４】
実行のこのような決定論主義によって、周辺モデルを特定のターゲット計算システム上で‐テスト装置上で‐実行する前にすでに、前記記憶位置の知識を得ることができる。こうするためには、モデルブロックも含めたモデルの記述のコンパイル時点で、所属の物理的記憶位置を有する出力と、場合によっては入力と、場合によっては別の情報も生成する。本発明の拡大された意味では、この記述の個々のエントリは以下で、一部の箇所では第１の種類のオブジェクトと称される。
【００１５】
理想的には記述は、モデリング環境で使用される個々の構成部分（ブロック）の名称に相応し、モデル構造（とりわけ、たとえばサブシステム）を再現する。このことにより、このような記述がたとえば上記のプログラム（Control- Desk, AutomationDesk 等）で使用される場合には、理想的または少なくともほぼ比肩する名称により、再識別が改善される。
【００１６】
例として、２つの入力と１つの加算ブロックと１つの出力ブロックとから成る単純なブロックモデルに対する記述の可能な形態を挙げる。この制御フローは、入力ブロックに与えられた値が乗算ブロックで乗算され、その後、出力ブロックへ出力されるように構成されている。以下の記述の構文は単なる一例である。
【００１７】
このような記述の個々の要素は、ここでは中括弧によって相互に区切られており、明瞭にするため、個々のオブジェクトの属性が添付されている。
【００１８】
{simple.mod
{ in_01: int//0x00004314 }
{ in_02: int(const[1])//0x00004324 }
{ op_block_01: int//0x00004346
: method=multiply }
{ out_01: int//0x00004628 }
}
【００１９】
ここに挙げられた記述では４つのオブジェクトが存在し、各オブジェクトはモデルにおける１つのブロックを表す。テスト装置上でこのモデルが実行される場合、この記述で参照されるブロック指示子が既知である上で、たとえば "simple.mod.in 01" が既知である上でこの指示子が使用され、所属の物理的記憶領域はコンピュータ支援によって解決され、その後、タスク提示に応じて読み出されるかまたは修正される。通常の手順は、たとえば較正のタスク複合体から取り出され、ここでは、実験装置に存在する偽のスライドレギュレータ‐たとえば固定的な値領域を有しコンピュータマウスによって制御されるスライドレギュレータ‐が、記述から知られるオブジェクトである "simple.mod.in 02" と結合され、種類 "integer" の定数が初期値１と結合され、実際の物理的記憶アドレスの解がこの実験システムを引き継ぐ。
【００２０】
この手法は、従来技術において以前から比較的長い間、十分に公知になっており、記録されている。以下で、これらの情報の使用を一例によって言及する。
【００２１】
たとえばテスト時に、このような記述を使用して、監視ソフトウェアまたは実験ソフトウェア‐たとえば ControlDesk または AutomationDesk‐によって、周辺モデルの変数の物理的記憶位置が既知である上で、これを所期のように上書きによって影響するか読み出して、テスト対象であるユニット‐たとえば制御装置‐の所望の応答を検出する場合がある。実験全体のコンテクストでのテストモデルの開発または別のタスクの解決は、一貫して同一の指示子を使用することによって格段に簡略化される。
【００２２】
実際には、このような指示子を含む記述をモデルと別個に形成することが有利であることが判明している。
【００２３】
Leinfellner et al. は欧州特許出願ＥＰ０６／０１８．９４５．３において、上記の影響を実験ＰＣによって行うのではなく、テスト装置上で直接行う手法を記載している。とりわけこのような手法で特徴的なのは、周辺モデルの他に少なくとも１つのテストモデルもテスト装置上で実行され、何らかの機能的な独立性が存在し、テストモード時にはテストモデルは、ここに記載された手法では周辺モデルと同期して実行されることである。
【００２４】
ここに記載された、テスト装置上での２つのモデルの同期実行を実施するためには、仕様化された計算周波数およびサンプリング周波数を基礎とする１つの実験構成例では、同期制御モデルを必要とするか、ないしは、両モデルの実行を制御する上位のメカニズムを必要とする。このようなメカニズムはたとえばタイミング発生器を有することができ、このタイミング発生器は、計算周波数およびサンプリング周波数に基づく時間単位の開始時に、該時間単位に関連する周辺モデル部分およびテストモデル部分の実行を開始させる。さらに、このようなメカニズムは次のような手段を有することもできる。すなわち、リアルタイム基準の遵守を検査し、たとえば許容範囲の時間単位を超える場合にはエラーエントリを行うか、または仕様化すべき別の作業を実行する手段を有することもできる。とりわけ、リアルタイム条件および同期性に関して非常に厳密な要求を課すタスク提示は、このような手順で、テスト装置を実験ＰＣから操作する従来の手法より格段に正確に解決することができる。
【００２５】
たとえば従来のプログラミング言語または（たとえば Simulink ソフトウェアの実行による）グラフィック表記によるテストモデルの開発は、上記のモデルの記述を使用することによって格段に簡略化される。通常の開発プロセスでは、記述で挙げられた個別の周辺モデル構成部分（ブロック）の指示子を使用することにより、‐物理的記憶アドレスの具体的な使用と比較して‐より良好に読み出し可能なテストモデルを作成することができる。このようにして作成されたテストモデルの実行時点（またはコンパイル時）で初めて、使用される指示子は相応の物理的記憶アドレスに変換される。
【００２６】
とりわけ、テスト過程において非常に異なるタスクで同一の指示子を一貫して使用することにより、概観性が良好になる。それに対して、周辺モデルのコンパイル時に生成された記述は、該周辺モデルに比類する似たような静的特性を有するという欠点がある。したがって、テスト構成体全体では指示子を動的に使用するのが望ましい。
【特許文献１】欧州特許出願ＥＰ０６／０１８．９４５．３
【発明の開示】
【発明が解決しようとする課題】
【００２７】
したがって本発明の基礎となる課題および目的は、上記の欠点を少なくとも部分的に回避するオブジェクトの動的処理方法および動的処理装置を提供することである。
【課題を解決するための手段】
【００２８】
前記課題は本発明では、本発明の第１の思想によれば、テスト構成体においてオブジェクトを動的に処理する方法において、次のような方法によって解決される。すなわち、テスト構成体は、双方向交換を行う少なくとも２つのシステムと、テスト対象である少なくとも１つの別のシステムとから成り、第１の種類のオブジェクトは第１のシステムで実行される周辺モデルに所属し、該オブジェクトはテストモデルによって処理され、第１のオブジェクトと同種類または同様の種類の第２の種類のオブジェクトを生成し、第１の種類のオブジェクトおよび第２の種類のオブジェクトを管理装置によって、該システムのうち少なくとも１つに対して供給する方法によって解決される。
【発明を実施するための最良の形態】
【００２９】
このような本発明による方法は、従来技術から公知となっており記載されている方法と比較して、様々な観点で有利であることが証明されている。静的な記述ないしは静的な第１の種類のオブジェクトでダイナミクスが欠けているという欠点は、第１の思想によれば同種類または同様の種類の第２の種類のオブジェクトを動的に生成することによって解消される。
【００３０】
第２の種類のオブジェクトは本発明の第１の思想によれば、第１の種類のオブジェクトに少なくとも構造的に相応する。本発明の思想の基礎となる通常の適用例では、上記のように物理的記憶アドレスは、オブジェクトをコンピュータ支援によって解決することにより求められる。Leinfellner et al. によって記載された手法では、第１の種類のオブジェクトのこのようなコンピュータ支援による解決は、テスト装置自体でも行うことができる。本発明では、第２の種類のオブジェクトを生成する。
【００３１】
このことを、虚構的な例に基づいて例解する。この例のタスクは、冒頭に挙げられた単純なモデルにおいて修正を行うことにより、乗算の出力値を調整可能な率だけ変化することである。
【００３２】
Leinfellner et al. によって使用される手法に相応する解決手段はたとえば、次のようなテストモデルを構想することである。すなわち、モデル関連のリアルタイム基準にしたがって周期的に呼び出されて、乗算ブロックの出力値である "simple.mod.op block 01" を読み出して係数を乗算し、出力ブロック "simple.mod.out 01" において結果を出力するテストモデルを構想することである。しかし上記のタスクでは、係数を制御可能に構成することが望ましい。
【００３３】
こうするためには、従来技術から公知であるような実験ソフトウェアを使用するのが適している。これは、第１の種類のオブジェクトを使用して、所属の物理的記憶アドレスを求めて、該物理的記憶アドレスに（新規の）値を割り当てることができる。これでは、テストモデルで形成された係数へのアクセスは不可能である。
【００３４】
本発明において前記課題は、テストモデルではたとえば、次のような第２の種類のオブジェクトが生成されること、すなわち、指示子 "simple.mod.gain block 01" を介して呼び出され、"faktor" パラメータを有する第２の種類のオブジェクトが生成されることによって解決される。この "faktor" パラメータは、たとえば１の初期値を有する。１つの実施例では、管理装置によってこのオブジェクトは実験ＰＣに供給される。ここで上記のように、オブジェクト指示子が既知であることで、係数の‐ここではたとえばゲインブロックすなわち増幅器（乗算器）の‐所属の物理的アドレスが検出され、たとえばスライドレギュレータによって修正される。テストモデルに設けられた、乗算ブロック "simple.mod.op block 01" の出力値に係数を乗算して結果を出力するという指示は、上記の方法によって補足されて維持される。
【００３５】
本発明による方法の別の構成に、第２の種類のオブジェクトはとりわけテストモデルまたは該テストモデルの一部によって生成されるか、これらによって第２の種類のオブジェクトの生成が開始されることを特徴とする構成がある。上記のテスト構成体では、テストモデルはテスト装置上で実行されるが、‐この構成とは異なって‐新規のオブジェクトの生成を別の実験システムまたは別のシステムによって行うかまたは開始することも考えられる。
【００３６】
本発明の方法の特に有利な構成では、第２の種類のオブジェクトの存在がテストモデルないしはテストモデルの一部の実行ないしは開始に結びつけられており、その後、特に有利な別の構成では第２の種類のオブジェクトをテストモデルの終了時または終了後に消去される。さらに、テストモデルが第２の種類のオブジェクトの変更も行うことができるように構成されている。
【００３７】
第２の種類のオブジェクトは通常、‐本発明の基礎となる手法によれば‐任意に形成された規則による別の処理に結びつけられており、理想的には、テストモデルによって表される制御工学的なコンテキストから導き出されるタスク提示に結びつけられている。すなわち、この規則が実験全体でもはや存在しなくなった場合には、第２の種類のオブジェクトは本発明では消去される。
【００３８】
別の有利な構成では、第２の種類のオブジェクトは別のオブジェクトに、第１の種類および／または第２の種類の別のオブジェクトに結合される。本発明において有利なのは、周辺モデルの機能をテストモデルの機能によって調整することである。たとえば上記の例を参照すると、乗算ブロック "simple.mod.op block 01" を別の計算規則に置き換えることができる。こうするためには、修正された計算規則とタスク提示にしたがって結びつけられている第２の種類のオブジェクトを生成する。その後、このオブジェクトは計算規則またはそれとは異なる手法で、所望の出力ブロック‐ここではたとえば第１の種類のオブジェクト "simple.mod.out 01" ‐に結合されることにより、値引継が、理想的には Leinfellner et al. によって記載されたスケジューリング手法を考慮して周期的に行われる。第１の種類のオブジェクトおよび第２の種類のオブジェクトから成る別の任意の双方向の組み合わせを、可能な計算規則の制限内で行うことも考えられる。
【００３９】
また、より大きな結果量の実験準備または後処理を行うために、生成された第２の種類のオブジェクトを後続処理および／または検査に使用できるようにする実施形態も考えられる。
【００４０】
本発明による方法の別の有利な実施形態によれば、第１の種類のオブジェクトおよび第２の種類のオブジェクトに関する情報と、第２の種類のオブジェクトの修正とが管理装置によって管理され、テスト構成体における別のシステムへ供給される。
【００４１】
１つの有利な実施形態にしたがってテスト装置上に配置された管理装置は、第１の種類のオブジェクトおよび第２の種類のオブジェクトを別の使用のために供給する。管理装置は特に有利な実施形態では、直接的または間接的に、テストモデルないしは該テストモデルを実行するメカニズムによって検査され、このメカニズムまたはテストモデルは、第２の種類のオブジェクトに関する情報を管理装置に格納する。管理装置はこの実施形態では、この情報および／または情報の存在を別のシステムに対して、たとえばトリガ信号によってアクティブに通知する。別の実施形態では、管理装置が周期的に別のシステムによって問い合わせされる構成、すなわち要求に応じて初めて通知する構成も考えられ、択一的に、管理装置はメッセージないしは情報をメモリに記憶する構成も考えられる。
【００４２】
本発明による方法および装置は、別の有利な実施例ではさらに、本発明の枠内で記載されたステップが実施されるように構成されている。
【００４３】
ここでは詳細には、本発明による方法および管理装置を構成および発展する手段が数多く存在する。ここで、請求項１および１０に従属する請求項と、図面に示された本発明の方法の実施例の説明とを参照されたい。
【実施例】
【００４４】
図１〜４は、異なる実施例に基づいて、それぞれ規定された本発明の方法および本発明の装置の側面を示す。概観しやすくするため、各図および各図に関する説明において、良好に理解しやすくするために、有利な実施例は削減されて示されている。
【００４５】
図１は、簡単なモデルをグラフィック表記で概略的に示している。制御フローおよびデータフローで最初に示されている要素０１５１，０１５２‐たとえばデータソース‐は、得られた値を次の要素０１５４‐たとえば上記の例のように乗算ブロック‐へ伝送する。この乗算ブロックは、組み込まれた演算を‐ここではすなわち、要素０１５１，０１５２から得られた値の乗算を‐実行し、得られた結果を出力要素０１５５‐たとえばデータシンク‐へ出力する。
【００４６】
図２は、本発明による思想にしたがって、上記のように図示された第２の種類のオブジェクトに相応する実際には存在しないブロック０２６１‐たとえば上記の例のように増幅器として構成されたブロック‐がアプリケータから見てどのように既存の周辺モデル（０２５１，０２５２，０２５４，０２５５から成る）に組み込まれるかを、概略的に示している。この実施例ではたとえば、実際には存在しないブロック０２６１は、ブロック０２５４の乗算の結果に影響してこの影響された新規の結果をブロック０２５５に出力する計算規則を有する。図示されていない本発明の別の特徴的な構成では、たとえば虚構的なブロック０２６１に、定数の形態で増幅器の係数を有するブロックである第２の種類の別のオブジェクトが含まれる。この別のオブジェクトはたとえば、使用される指示子が既知であることにより、実験ソフトウェアから影響され‐また、テストモデルの別のコンポーネントによって影響を行うことも考えられる。
【００４７】
図３に、ここで提案されている本発明でのテスト構成が示されている。テスト対象であるユニット０３２１はデータ転送手段０３０９を介してテスト装置０３０２に双方向接続されており、このテスト装置０３０２はデータ転送手段０３０８を介して別のシステム０３０１とも相互作用し、有利には実験ＰＣと相互作用する。テスト構成においてテスト装置０３０２と実験ＰＣ０３０１とが相互に相互作用すると、本発明の特別な付加価値が得られる。とりわけ、特に有利なのは、指示子によってアドレシングされる第２の種類のオブジェクトの物理的記憶位置は、Leinfellner et al. によって提案された構成のように実験ソフトウェアおよび／またはテストソフトウェアおよび／または別のテストモデルによって、使用される。
【００４８】
図４に、テスト構成の種々の詳細と、テスト構成の重要な基礎となる別の構成部分とが概略的に示されている。とりわけここに示されているのは、ここでは実験システム０４０１であるシステムと、物理的メモリ０４０５を有するテスト装置０４０２と、実行される周辺モデル０４０３と、実行されるテストモデル０４０６と、第１の種類のオブジェクトおよび第２の種類のオブジェクトを処理するための管理装置０４０７である。前記システムには、この例では別個のファイルとして設けられた記述０４０４ａが供給され、図４にはさらに、記述０４０４ａの内容を再現する相応の記述０４０４ｂが示されており、これは管理装置へ供給される。さらに、（詳細ではないが）テスト装置０４０２内部で実行されるオブジェクト間の種々のデータフローが記載されている。
【図面の簡単な説明】
【００４９】
【図１】簡単なモデルの概略図である。
【図２】第２の種類のオブジェクトに相応するコンポーネントだけ拡張された簡単なモデルの概略図であり、これはとりわけ請求項１〜９に関する。
【図３】本発明の思想の基礎となるテスト構成の概略図であり、このテスト構成は、２つの双方向動作するシステムとテスト対象である別のシステムとを有する。
【図４】請求項に記載された管理装置を考慮した本発明によるテスト装置の概略図であり、これはとりわけ、請求項１記載の方法に関する。
【符号の説明】
【００５０】
０１５１  入力ブロックの概略図
０１５２  入力ブロックの概略図
０１５４  入力ブロックの概略図
０１５５  出力ブロックの概略図
０２５１  入力ブロックの概略図
０２５２  入力ブロックの概略図
０２５４  演算ブロックの概略図
０２５５  出力ブロックの概略図
０２６１  第２の種類によるオブジェクトに関するブロックの概略図
０３０１  実験システム
０３０２  テスト装置
０３０８  請求項１に記載の実験システムとテスト装置との間のデータ転送手段
０３０９  テスト装置とテスト対象であるシステムとの間のデータ転送手段
０３２１  テスト対象のシステム
０４０１  実験システム
０４０２  テスト装置
０４０３  実行される周辺モデル
０４０４ａ  別個のファイルとしての第１の種類のオブジェクトの記述
０４０４ｂ  テスト装置上の呼び出し可能なデータソースである第１の種類のオブジェクトの記述
０４０５  テスト装置上の物理的メモリ
０４０６  実行されるテストモデル
０４０７  本発明による管理装置
０４０８  請求項１１によるアクティブないしはパッシブな供給
【図１】
2008159058.tif 000003
【図２】
2008159058.tif 000004
【図３】
2008159058.tif 000005
【図４】
2008159058.tif 000006