(57)【要約】  試験システムで処理を実行するためのシステムおよび方法を提供する。自動試験を実行する試験プログラムを開発するため、柔軟なプラットフォームを提供する。かかるプラットフォームにおいては、テスタとその計器をテスタオペレーティングシステムから分離することで、どんなテスタオペレーティングシステムでも使用することが可能となる。別の実装例においては、プラットフォームのユーザ層をアーキテクチャの物理層から分離することで、ハードウェアから独立した試験プログラムを作成し、異なる試験ハードウェアおよびソフトウェアを備える異なるテスタで同試験プログラムを使用することが可能となる。別の実装においては、試験プログラムの実行をテスタプラットフォームオペレーティングシステムから分離することで、試験プログラムがテスタプラットフォームから独立して機能することが可能となる。別の実施形態においては、新たなソフトウェア、ハードウェア、および／または機能がプラットフォームに追加される場合でもファンクションを追加するだけで、ファンクションに至る既存のリンクを断絶せずに継続的試験システム動作を保証する機能をプラットフォーム上で実装する。この試験システムには非決定性コンピュータシステムを盛り込むことができる。試験システムの一例においては、非決定性コンピュータシステムによって遂行される１つ以上のコンピュータ命令の実行を、一定の実行時間内に実行するよう強制する。コンピュータ命令の実行を一定の実行時間にわたって遂行するため、必要とあらば決定性エンジンが待機し、この待機時間は可変である。実行時間は一定だから、その実行は決定性であり、決定性の挙動を必要とする用途に使用できる。例えば、自動試験装置（ＡＴＥ）用途でかかる決定性エンジンを使用できる。
2009544012.tif 000002
【特許請求の範囲】
【請求項１】
試験プログラムと、
該試験プログラムからのリクエストに応じて複数のファンクションコールを生成するように構成されるプラットフォームと、
前記複数のファンクションコールを試験ハードウェアで実行される命令にマップするように構成される抽象層とを備える、
システム。
【請求項２】
前記抽象層はさらに、前記プラットフォームに対し仮想計器（「ＶＩ」）インターフェースを備える、請求項１に記載のシステム。
【請求項３】
前記抽象層はさらに、前記プラットフォームに対し仮想マルチサイト（「ＶＭＩ」）インターフェースを備える、請求項２に記載のシステム。
【請求項４】
前記抽象層はさらに、前記プラットフォームに対しシステム物理計器（「システムＰＩ」）インターフェースを備える、請求項１に記載のシステム。
【請求項５】
前記抽象層はさらに、前記プラットフォームに対し物理計器（「ＰＩ」）インターフェースを備える、請求項１に記載のシステム。
【請求項６】
前記抽象層はさらに、仮想計器（「ＶＩ」）対物理計器（「ＰＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項７】
前記抽象層はさらに、システム物理計器（「システムＰＩ」）対仮想計器（「ＶＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項８】
前記抽象層はさらに、システム物理計器（「システムＰＩ」）対物理計器（「ＰＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項９】
前記抽象層はさらに、試験プログラム対仮想計器（「ＶＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項１０】
前記抽象層はさらに、試験プログラム対物理計器（「ＰＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項１１】
前記抽象層はさらに、プラットフォーム対仮想計器（「ＶＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項１２】
前記抽象層はさらに、プラットフォーム対物理計器（「ＰＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項１３】
前記抽象層はさらに、プラットフォーム対仮想マルチサイト計器（「ＶＭＩ」）インターフェースを含む、請求項１に記載のシステム。
【請求項１４】
前記抽象層はさらに、インターフェース生成エンジンを備える、請求項１に記載のシステム。
【請求項１５】
前記インターフェース生成エンジンは、ユーザにインターフェースの生成を案内するように構成されるグラフィカルユーザインターフェースを含む、請求項１に記載のシステム
。
【請求項１６】
前記インターフェース生成エンジンは、前記システムのコンポーネント間の通信を管理するためのインターフェースを生成する、請求項１４に記載のシステム。
【請求項１７】
前記インターフェース生成エンジンは、前記抽象層のコンポーネント間の通信を管理するためのインターフェースを生成する、請求項１４に記載のシステム。
【請求項１８】
前記インターフェース生成エンジンは、前記プラットフォームと前記抽象層との間の通信を管理するためのインターフェースを生成する、請求項１７に記載のシステム。
【請求項１９】
前記プラットフォームと前記抽象層との間の通信を管理することは、試験ハードウェアで実行される命令に前記複数のファンクションコールをマップすることを含む、請求項１８に記載のシステム。
【請求項２０】
前記複数のファンクションコールをマップすることは、前記複数のファンクションコールを仮想計器（「ＶＩ」）モジュールにマップすることを含む、請求項１９に記載のシステム。
【請求項２１】
前記複数のファンクションコールをマップすることは、前記複数のファンクションコールをシステム物理計器（「システムＰＩ」）モジュールにマップすることを含む、請求項１９に記載のシステム。
【請求項２２】
前記複数のファンクションコールをマップすることは、前記複数のファンクションコールを物理計器（「ＰＩ」）モジュールにマップすることを含む、請求項１９に記載のシステム。
【請求項２３】
前記複数のファンクションコールをマップすることは、基本クラスの物理計器ファンクションコールを物理計器（「ＰＩ」）モジュールにマップすることを含む、請求項２２に記載のシステム。
【請求項２４】
前記複数のファンクションコールをマップすることは、基本クラスの物理計器ファンクションコールを物理計器（「ＰＩ」）モジュールにマップすることを含む、請求項２２に記載のシステム。
【請求項２５】
前記抽象層はさらに、ルールチェックエンジンを備える、請求項１４に記載のシステム。
【請求項２６】
前記ルールチェックエンジンは、前記試験ハードウェアの命令へのファンクションコールの前記マッピングを検証するように構成される、請求項２５に記載のシステム。
【請求項２７】
前記ルールチェックエンジンは、前記ファンクションコールのリクエストを模擬することによって前記マッピングを検証する、請求項２６に記載のシステム。
【請求項２８】
前記ルールチェックエンジンは、前記模擬ファンクションコールの結果として応答を所期形式で受け付けることによって前記マッピングを検証する、請求項２７に記載のシステム。
【請求項２９】
前記ルールチェックエンジンは、前記ファンクションコールが正常にマップされたことを伝えるコードを操作プラットフォームに返す、請求項２８に記載のシステム。
【請求項３０】
前記ルールチェックエンジンは、前記模擬ファンクションコールに応じて前記所期形式になっていない戻りコードを受け付けることにより不適切なマッピングを識別する、請求項２９に記載のシステム。
【請求項３１】
前記試験プログラムと前記プラットフォームとの間にインターフェースをさらに備える、請求項１に記載のシステム。
【請求項３２】
前記試験プログラムは、ユーザに対しグラフィカルユーザインターフェースを提供する、請求項１に記載のシステム。
【請求項３３】
前記試験プログラムは、ユーザがデバイスに実行する試験を設定することを可能にする、請求項３２に記載のシステム。
【請求項３４】
前記試験プログラムは、ユーザがデバイスに実行する試験を任意のときに行うよう設定することを可能にする、請求項３２に記載のシステム。
【請求項３５】
前記抽象層はさらに、前記試験システムのハードウェアリソースの機能を表現する物理計器抽象層を備える、請求項１に記載のシステム。
【請求項３６】
前記物理計器抽象層は、ハードウェアリソースにマップする物理計器モジュールを含む、請求項３５に記載のシステム。
【請求項３７】
前記ＰＩモジュールは、リクエストに応じてハードウェアリソース上での命令実行を生起させる、請求項３５に記載のシステム。
【請求項３８】
ハードウェアリソースは、前記試験ハードウェア上で使用できる少なくとも１つのファンクションを含む、請求項３５に記載のシステム。
【請求項３９】
前記ハードウェアリソースは、同期信号の生成を生起させるように構成される、請求項３８に記載のシステム。
【請求項４０】
前記ハードウェアリソースは、デバイス状態クエリを生起させるように構成される、請求項３８に記載のシステム。
【請求項４１】
前記ＰＩモジュールは、デバイス開始状態に応じてデバイスの電力オンおよび／または初期化を生起させるファンクションコールを含む、請求項３５に記載のシステム。
【請求項４２】
前記物理計器モジュールは、基本クラスのＰＩファンクションコールを含む、請求項３５に記載のシステム。
【請求項４３】
前記基本クラスのＰＩファンクションコールは、前記電力オンおよび／または初期化ファンクションを含む、請求項４２に記載のシステム。
【請求項４４】
前記抽象層はさらに、前記試験システムで実行されるハードウェアファンクションの仮想を表現する仮想計器抽象層を備える、請求項１に記載のシステム。
【請求項４５】
前記仮想計器抽象層は、仮想計器（「ＶＩ」）モジュールを含み、少なくとも１つのハードウェアリソースは同ＶＩモジュールにマップされる、請求項４４に記載のシステム。
【請求項４６】
前記ＶＩモジュールは、リクエストに応じてハードウェアリソース上での前記命令実行を生起させるように構成される、請求項４５に記載のシステム。
【請求項４７】
少なくとも１つのリソースに前記マップすることは、少なくとも１つのハードウェアリソースの各々につき少なくとも１つのＰＩモジュールを通じてマップされる、請求項４５に記載のシステム。
【請求項４８】
前記ＶＩモジュールは、ある特定のデバイスの試験に用いる１セットの既定ハードウェアリソースの仮想表現を提示するため、複数のＰＩモジュールにマップされる、請求項４７に記載のシステム。
【請求項４９】
前記ＶＩモジュールは、追加ＰＩモジュールを含むよう修正されるように構成され、この修正により、前記ＶＩモジュールを通じてデバイスを試験するのに利用できる前記１セットのハードウェアリソースを拡張する、請求項４７に記載のシステム。
【請求項５０】
前記ＶＩモジュールは、ＡＴＥテスタに必要な試験ハードウェアリソースにマップする基本クラスのファンクションを含むように構成される、請求項４６に記載のシステム。
【請求項５１】
前記抽象層はさらに、ハードウェアリソースに対するリクエストを管理するように構成されるシステム抽象層を備える、請求項１に記載のシステム。
【請求項５２】
前記システム抽象層はさらに、リクエストに応じてハードウェアリソースにファンクションを実行させるため、物理計器層からのリクエストをマップするように構成される、請求項１に記載のシステム。
【請求項５３】
前記システム抽象層はさらに、前記抽象層の他のコンポーネントで利用できる基本セットのシステムファンクションコールを規定するように構成される、請求項１に記載のシステム。
【請求項５４】
前記システム層はさらに、前記抽象層の前記他のコンポーネントに操作を実行させる基本セットのシステムファンクションコールを規定するように構成されるシステムＰＩモジュールを備える、請求項１に記載のシステム。
【請求項５５】
前記システム抽象層はさらに、前記抽象層のコンポーネントに対しクエリを実行するように構成される、請求項５３に記載のシステム。
【請求項５６】
前記システム抽象層は、システム物理計器モジュールを含む、請求項５１に記載のシステム。
【請求項５７】
前記プラットフォーム層は、「既製」オペレーティングシステムを含む、請求項１に記載のシステム。
【請求項５８】
前記「既製」オペレーティングシステムは、決定的に実行するよう強化される、請求項５７に記載のシステム。
【請求項５９】
前記「既製」オペレーティングシステムは、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰであって、これは、Ｔｅｎａｓｙｓ  ＩＮｔｉｍｅオペレーティングシステムを用いて決定的に作動するよう強化される、請求項５８に記載のシステム。
【請求項６０】
自動試験装置システムであって、
前記自動試験装置システムの抽象層の動作を管理するように構成されるプラットフォーム抽象層と、
ＰＩファンクションコールに応じてハードウェアがファンクションを実行するようＰＩファンクションコールを前記ハードウェアにマップするように構成される物理計器（「ＰＩ」）抽象層と、
前記ＰＩ抽象層にマップするように構成され、実行されるハードウェアファンクションの仮想を表現する仮想計器（「ＶＩ」）抽象層と、
ＰＩファンクションコールに応じて前記ハードウェアがファンクションを実行することを可能にするためシステムファンクションコールをマップするように構成されるシステム抽象層と、
ハードウェア上で実行されるファンクションを起動するため前記仮想計器層とやり取りするように構成される試験プログラム抽象層とを備える、
自動試験装置システム。
【請求項６１】
前記システム抽象層はさらに、システム物理計器（「システムＰＩ」）モジュールに抽象化され、同システムＰＩモジュールは前記ＰＩ抽象層からリクエストを受け、これに応じてハードウェアにそのファンクションを実行させる、請求項６０に記載の自動試験装置システム。
【請求項６２】
前記システムＰＩモジュールはさらに、前記自動試験装置システムの前記他の抽象層によって報告される情報を集約することに適する、請求項６１に記載の自動試験装置システム。
【請求項６３】
前記集約情報は、前記自動試験装置システムの前記他の抽象層で行われるファンクションコールの成否を含む、請求項６２に記載の自動試験装置システム。
【請求項６４】
前記集約情報は、前記自動試験装置システムの前記他の抽象層での操作による報告を含む、請求項６２に記載の自動試験装置システム。
【請求項６５】
システムＰＩモジュールはさらに、前記集約情報に対するクエリを受け付けるように構成される、請求項６２に記載の自動試験装置システム。
【請求項６６】
システムＰＩモジュールはさらに、前記集約情報を報告するように構成される、請求項６２に記載の自動試験装置システム。
【請求項６７】
前記試験プログラム抽象層は、ユーザに対しグラフィカルユーザインターフェースを提示するように構成される試験プログラムを含む、請求項６０に記載の自動試験装置システム。
【請求項６８】
前記試験プログラム層はさらに、ユーザに前記仮想計器層とやり取りさせるように構成される、請求項６７に記載の自動試験装置システム。
【請求項６９】
前記試験プログラム層はさらに、デバイスに実行する試験をユーザに設定させるように構成される、請求項６８に記載の自動試験装置システム。
【請求項７０】
前記試験プログラムはさらに、試験の実行結果を図式的に提示するように構成される、請求項６９に記載の自動試験装置システム。
【請求項７１】
前記試験プログラム層はさらに、デバイスに実行する試験をユーザに設定させるように構成され、ここで実行される前記試験は、スケジュールされたときに行われる、請求項６
９に記載の自動試験装置システム。
【請求項７２】
実行される前記試験は、ユーザによって設定された任意のスケジュールに沿って行うことができる、請求項７１記載の自動試験装置システム。
【請求項７３】
前記仮想計器抽象層は、ＶＩモジュールを含み、ここで前記ＶＩモジュールは、少なくとも１つのハードウェアリソースへのマッピングを含む、請求項６０に記載の自動試験装置システム。
【請求項７４】
前記ＶＩモジュールは、リクエストに応じて前記少なくとも１つのハードウェアリソースにそのファンクションを実行させるように構成される、請求項７３に記載の自動試験装置システム。
【請求項７５】
前記ＶＩモジュールは、前記試験プログラム抽象層からのリクエストに応じて前記少なくとも１つのハードウェアリソースにそのファンクションを実行させる、請求項７４に記載の自動試験装置システム。
【請求項７６】
前記少なくとも１つのハードウェアリソースへの前記マッピングは、前記ＰＩ計器層を通じてマップされる、請求項７３に記載の自動試験装置システム。
【請求項７７】
前記少なくとも１つのハードウェアリソースへの前記マッピングは、ＰＩモジュールを通じてマップされる、請求項７３に記載の自動試験装置システム。
【請求項７８】
前記ＶＩモジュールは、複数のＰＩモジュールにマップされ、その結果ＶＩモジュールは、デバイスの試験に用いる複数のハードウェアリソースの仮想表現を提示する、請求項７３に記載の自動試験装置システム。
【請求項７９】
前記ＶＩモジュールと前記ＰＩモジュールとの間の前記マッピングは、インターフェースによって管理される、請求項７７に記載の自動試験装置システム。
【請求項８０】
前記インターフェースは、グラフィカルユーザインターフェースである、請求項７９に記載の自動試験装置システム。
【請求項８１】
前記インターフェースは、前記ＶＩモジュールと前記ＰＩモジュールとの通信を所定の形式で管理する、請求項７９に記載の自動試験装置システム。
【請求項８２】
前記ＶＩモジュールは、追加ＰＩモジュールへのマッピングを含めるよう修正されるように構成される、請求項７３に記載の自動試験装置システム。
【請求項８３】
前記ＶＩモジュールは、ＡＴＥテスタに必要な試験ハードウェアリソースにマップする基本クラスのファンクションを含むように構成される、請求項７３に記載の自動試験装置システム。
【請求項８４】
前記物理計器抽象層は、ハードウェアリソースの実装詳細を収容するＰＩモジュールを含む、請求項６０に記載の自動試験装置システム。
【請求項８５】
前記物理計器抽象層は、各ハードウェアリソースの前記実装詳細を収容するＰＩモジュールを含む、請求項８４に記載の自動試験装置システム。
【請求項８６】
前記物理計器抽象層は、新規ハードウェアリソースの前記実装詳細を取り入れるように
構成される、請求項８４に記載の自動試験装置システム。
【請求項８７】
前記新規ハードウェアリソースは、新規ＰＩモジュールによってマップされる、請求項８６に記載の自動試験装置システム。
【請求項８８】
前記ＰＩモジュールは、リクエストに応じて前記ハードウェアリソースの機能の実行を生起させる、請求項８４に記載の自動試験装置システム。
【請求項８９】
前記リクエストは、ＶＩモジュールから到来する、請求項８８に記載の自動試験装置システム。
【請求項９０】
前記ハードウェアリソースの機能は、同期信号を含む、請求項８８に記載の自動試験装置システム。
【請求項９１】
前記物理計器モジュールは、ハードウェアリソースの電力オンおよび／または初期化を生起させるファンクションコールを含む、請求項８４に記載の自動試験装置システム。
【請求項９２】
前記ファンクションコールは、前記ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションを含む、請求項９１に記載の自動試験装置システム。
【請求項９３】
前記ＰＩ抽象層は、基本クラスのＰＩファンクションコールを含む、請求項６０に記載の自動試験装置システム。
【請求項９４】
前記基本クラスのＰＩファンクションコールは、ハードウェアリソースの電力オンおよび／または初期化を生起させるように構成される前記ファンクションコールを含む、請求項９３に記載の自動試験装置システム。
【請求項９５】
ハードウェアリソースの電力オンおよび／または初期化を生起させるように構成される前記ファンクションコールは、前記ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションを含む、請求項９４に記載の自動試験装置システム。
【請求項９６】
前記プラットフォーム抽象層は、「既製」オペレーティングシステムを含む、請求項６０に記載の自動試験装置システム。
【請求項９７】
前記「既製」オペレーティングシステムは、決定的に実行するよう強化される、請求項９６に記載の自動試験装置システム。
【請求項９８】
前記「既製」オペレーティングシステムは、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰである、請求項９６に記載の自動試験装置システム。
【請求項９９】
前記オペレーティングシステムは、リアルタイムエクステンションを用いて決定的に実行するよう強化される、請求項９８に記載の自動試験装置システム。
【請求項１００】
前記リアルタイムエクステンションは、「Ｔｅｎａｓｙｓ  ＩＮｔｉｍｅ」オペレーティングシステムを通じて提供される、請求項９９に記載の自動試験装置システム。
【請求項１０１】
前記プラットフォーム抽象層は、決定的に作動する、請求項６０に記載の自動試験装置システム。
【請求項１０２】
前記抽象層間の前記通信を管理するように構成されるインターフェース抽象層をさらに
備える、請求項６０に記載の自動試験装置システム。
【請求項１０３】
前記インターフェース抽象層はさらに、前記抽象層間で規格化された通信を保証するように構成される、請求項６０に記載の自動試験装置システム。
【請求項１０４】
前記インターフェース抽象層は、前記プラットフォーム抽象層と前記ＶＩ抽象層との間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１０５】
前記インターフェース抽象層は、前記プラットフォーム抽象層と前記システム抽象層との間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１０６】
前記インターフェース抽象層は、前記プラットフォーム抽象層と前記物理計器抽象層との間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１０７】
前記インターフェース抽象層は、ＶＩモジュールとＰＩモジュールとの間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１０８】
前記インターフェース抽象層は、システムＰＩモジュールとＶＩモジュールとの間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１０９】
前記インターフェース抽象層は、システムＰＩモジュールとＰＩモジュールとの間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１１０】
前記インターフェース抽象層は、前記プラットフォーム抽象層と前記ＶＩ抽象層との間にインターフェースを含む、請求項１０３に記載の自動試験装置システム。
【請求項１１１】
ユーザにＰＩモジュールとＶＩモジュールのいずれか一方の作成を案内するように構成されるモジュール生成エンジンをさらに備え、これにより前記自動試験システムは、新規試験ハードウェアリソースを取り入れることができる、請求項６０に記載の自動試験装置システム。
【請求項１１２】
ユーザにインターフェースの作成を案内するように構成されるインターフェース生成エンジンをさらに備え、ここで前記インターフェースは、前記自動試験システムで使用する前記ハードウェア、ソフトウェア、またはプラットフォームにかかわりなく前記通信形式を規格化することによってモジュール間通信を管理する、請求項６０に記載の自動試験装置システム。
【請求項１１３】
生成済みモジュールとその生成済みインターフェースとの試験機能を検証するように構成されるルールチェックエンジンをさらに備える、請求項１１２に記載の自動試験装置システム。
【請求項１１４】
前記生成済みモジュールをユーザにインストールさせるように構成されるインストールモジュールをさらに備え、これにより前記試験プログラムは、前記生成済みモジュールへリクエストを差し向け、且つ試験ファンクションを実行させることができる、請求項１１３に記載の自動試験装置システム。
【請求項１１５】
前記生成済みインターフェースをユーザにインストールさせるように構成されるインストールモジュールをさらに備え、これにより前記試験プログラムは、前記生成済みモジュールによってマップされた前記試験ハードウェアリソースへリクエストを差し向け、且つ試験ファンクションを実行させることができる、請求項１１４に記載の自動試験装置シス
テム。
【請求項１１６】
試験プロセスを実行するシステムであって、該システムは、
実行時に１つ以上の試験計器でプロシージャを実行する試験プログラムであって、前記１つ以上の試験計器はそれぞれ１つ以上のドライバプログラムを有する試験プログラムと、
前記１つ以上の試験計器で前記プロシージャを実行するように構成される仮想計器エンティティとを備え、ここで前記仮想計器エンティティは、前記それぞれ１つ以上のドライバプログラムを通じて前記１つ以上の試験計器にアクセスする、
システム。
【請求項１１７】
前記仮想計器エンティティは、１つ以上のファンクションを含む、請求項１１６に記載のシステム。
【請求項１１８】
前記試験プログラムは、前記仮想計器の前記１つ以上のファンクションにアクセスすることにより前記１つ以上の試験計器にアクセスするように構成される、請求項１１７に記載のシステム。
【請求項１１９】
前記試験プログラムは、専ら前記仮想計器を通じて前記１つ以上の計器にアクセスするようプログラムされる、請求項１１８に記載のシステム。
【請求項１２０】
前記試験プログラムは、テスタリソースにアクセスするためシステム物理インターフェースにアクセスするようプログラムされる、請求項１１８に記載のシステム。
【請求項１２１】
前記仮想計器エンティティは、前記１つ以上の試験ハードウェアに特有のプログラミングインターフェースから前記試験プログラムを分離する、請求項１１６に記載のシステム。
【請求項１２２】
前記仮想計器は、仮想計器プログラミングインターフェースを含む、請求項１１６に記載のシステム。
【請求項１２３】
前記１つ以上の試験計器における変化は、前記仮想計器プログラミングインターフェースに相応の変化をもたらさない、請求項１２２に記載のシステム。
【請求項１２４】
前記仮想計器エンティティにおける変化は、前記１つ以上のファンクションに相応の変化をもたらさない、請求項１１７に記載のシステム。
【請求項１２５】
物理テスタリソースにおける変化は、前記１つ以上のファンクションに相応の変化をもたらさない、請求項１１７に記載のシステム。
【請求項１２６】
試験開発プラットフォームにおける変化は、前記試験プラットフォームにおける変化を要求しない、請求項１１６に記載のシステム。
【請求項１２７】
前記１つ以上のファンクションは、コンピュータシステムのメモリ構造にロードされる、請求項１２４に記載のシステム。
【請求項１２８】
前記仮想計器エンティティにおける前記変化は、前記コンピュータシステムの前記メモリ構造に相応の変化をもたらさない、請求項１２７に記載のシステム。
【請求項１２９】
前記１つ以上のファンクションは、前記コンピュータシステムの前記メモリ構造の中で
第１の位置に置かれる、請求項１２８に記載のシステム。
【請求項１３０】
前記仮想計器エンティティにおける前記変化は、１つ以上の追加ファンクションを追加することを含む、請求項１２９に記載のシステム。
【請求項１３１】
前記仮想計器エンティティにおける前記変化は、前記１つ以上のファンクションの内少なくとも１つを修正することを含む、請求項１２９に記載のシステム。
【請求項１３２】
前記１つ以上の追加ファンクションは、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置の後ろに続く第２の位置に追加される、請求項１３０に記載のシステム。
【請求項１３３】
前記１つ以上の追加ファンクションの前記追加は、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置における前記１つ以上のファンクションの前記位置を変えない、請求項１３２に記載のシステム。
【請求項１３４】
前記コンピュータシステムの前記メモリ構造はさらに、ｖテーブルを備える、請求項１３３に記載のシステム。
【請求項１３５】
前記１つ以上の追加ファンクションの前記追加は、前記ｖテーブルにおける前記１つ以上のファンクションの位置を変えない、請求項１３４に記載のシステム。
【請求項１３６】
前記仮想計器エンティティにおける前記変化は、少なくとも１つの修正済みファンクションを追加することを含む、請求項１３１に記載のシステム。
【請求項１３７】
前記少なくとも１つの修正済みファンクションは、前記１つ以上のファンクションの内前記少なくとも１つから修正される、請求項１３６に記載のシステム。
【請求項１３８】
前記少なくとも１つの修正済みファンクションは、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置の後ろに続く第２の位置に追加される、請求項１３７に記載のシステム。
【請求項１３９】
前記少なくとも１つの修正済みファンクションの前記追加は、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置における前記１つ以上のファンクションの前記位置を変えない、請求項１３８に記載のシステム。
【請求項１４０】
前記コンピュータシステムの前記メモリ構造はさらに、ｖテーブルを備える、請求項１３９に記載のシステム。
【請求項１４１】
前記少なくとも１つの修正済みファンクションの前記追加は、前記ｖテーブルにおける前記１つ以上のファンクションの位置を変えない、請求項１４０に記載のシステム。
【請求項１４２】
前記１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、前記基本プログラミングクラスは、前記１つ以上の追加ファンクションを含む拡張クラスのファンクションから継承される、請求項１３０に記載のシステム。
【請求項１４３】
前記１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、前記基本プログラミングクラスは、前記少なくとも１つの修正済みファンクションを含む拡張クラスのファンクションから継承される、請求項１３６に記載のシステム。
【請求項１４４】
前記コンピュータシステムは、汎用コンピュータシステムを含む、請求項１２７に記載のシステム。
【請求項１４５】
前記１つ以上の試験計器は、１つ以上の試験対象デバイスに結合される、請求項１１６に記載のシステム。
【請求項１４６】
前記１つ以上の試験計器の内少なくとも１つは、前記１つ以上の試験対象デバイスの内少なくとも１つに試験信号を適用するよう前記試験プログラムによりプログラムされる、請求項１４５に記載のシステム。
【請求項１４７】
前記システムは、自動試験システムの一部である、請求項１１６に記載のシステム。
【請求項１４８】
試験プロセスを実行するシステムであって、該システムは、
それぞれ１つ以上のドライバプログラムを有する１つ以上の試験計器であって、前記ドライバプログラムの内少なくとも１つは１つ以上のファンクションを含む１つ以上の試験計器と、
実行時に前記１つ以上の試験計器でプロシージャを実行する試験プログラムであって、該試験プログラムは前記１つ以上のドライバプログラムを通じて前記１つ以上の試験計器にアクセスする試験プログラムと、
メモリ構造とを備え、前記ドライバプログラムの内前記少なくとも１つのドライバプログラムの前記１つ以上のファンクションは、前記メモリ構造により固定位置の中に収容される、
システム。
【請求項１４９】
前記メモリ構造は、コンピュータシステムのメモリに含まれ、ここで前記１つ以上のファンクションは、前記コンピュータシステムの前記メモリにロードされる、請求項１４８に記載のシステム。
【請求項１５０】
前記ドライバプログラムの内少なくとも１つにおける変化は、前記メモリ構造に相応の変化をもたらさない、請求項１４８に記載のシステム。
【請求項１５１】
前記１つ以上のファンクションは、前記メモリ構造内の第１の位置に置かれる、請求項１５０に記載のシステム。
【請求項１５２】
前記ドライバプログラムの内の前記少なくとも１つにおける前記変化は、１つ以上の追加ファンクションを追加することを含む、請求項１５１に記載のシステム。
【請求項１５３】
前記ドライバプログラムの内の前記少なくとも１つにおける前記変化は、前記１つ以上のファンクションの内少なくとも１つを修正することを含む、請求項１５１に記載のシステム。
【請求項１５４】
前記１つ以上の追加ファンクションは、前記メモリ構造の中で前記第１の位置の後ろに続く第２の位置に追加される、請求項１５１に記載のシステム。
【請求項１５５】
前記１つ以上の追加ファンクションの前記追加は、前記メモリ構造の中で前記第１の位置における前記１つ以上のファンクションの前記位置を変えない、請求項１５４に記載のシステム。
【請求項１５６】
前記メモリ構造はさらに、ｖテーブルを備える、請求項１５５に記載のシステム。
【請求項１５７】
前記１つ以上の追加ファンクションの前記追加は、前記ｖテーブルにおける前記１つ以上のファンクションの位置を変えない、請求項１５６に記載のシステム。
【請求項１５８】
前記仮想計器エンティティにおける前記変化は、少なくとも１つの修正済みファンクションを追加することを含む、請求項１５３に記載のシステム。
【請求項１５９】
プラットフォームエンティティにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む、請求項１５８に記載のシステム。
【請求項１６０】
物理計器ドライバにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む、請求項１５８に記載のシステム。
【請求項１６１】
前記少なくとも１つの修正済みファンクションは、前記１つ以上のファンクションの内前記少なくとも１つから修正される、請求項１５８に記載のシステム。
【請求項１６２】
前記少なくとも１つの修正済みファンクションは、前記メモリ構造の中で前記第１の位置の後ろに続く第２の位置に追加される、請求項１６１に記載のシステム。
【請求項１６３】
前記少なくとも１つの修正済みファンクションの前記追加は、前記メモリ構造の中で前記第１の位置における前記１つ以上のファンクションの前記位置を変えない、請求項１６２に記載のシステム。
【請求項１６４】
前記メモリ構造はさらに、ｖテーブルを備える、請求項１６３に記載のシステム。
【請求項１６５】
前記少なくとも１つの修正済みファンクションの前記追加は、前記ｖテーブルにおける前記１つ以上のファンクションの位置を変えない、請求項１６４に記載のシステム。
【請求項１６６】
前記１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、前記基本プログラミングクラスは、前記１つ以上の追加ファンクションを含む拡張クラスのファンクションから継承される、請求項１５２に記載のシステム。
【請求項１６７】
前記１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、前記基本プログラミングクラスは、前記少なくとも１つの修正済みファンクションを含む拡張クラスのファンクションから継承される、請求項１６０に記載のシステム。
【請求項１６８】
前記コンピュータシステムは、汎用コンピュータシステムを含む、請求項１４９に記載のシステム。
【請求項１６９】
前記１つ以上の試験計器は、１つ以上の試験対象デバイスに結合される、請求項１４８に記載のシステム。
【請求項１７０】
前記１つ以上の試験計器の内少なくとも１つは、前記１つ以上の試験対象デバイスの内少なくとも１つに試験信号を適用するよう前記試験プログラムによりプログラムされる、請求項１６９に記載のシステム。
【請求項１７１】
前記システムは、自動試験システムの一部である、請求項１４８に記載のシステム。
【請求項１７２】
前記１つ以上の試験計器で前記プロシージャを実行するように構成される仮想計器エンティティをさらに備え、ここで前記仮想計器エンティティは、前記それぞれ１つ以上のドライバプログラムを通じて前記１つ以上の試験計器にアクセスする、請求項１４８に記載
のシステム。
【請求項１７３】
前記仮想計器エンティティは、１つ以上のファンクションを含む、請求項１７２に記載のシステム。
【請求項１７４】
前記試験プログラムは、前記仮想計器の前記１つ以上のファンクションにアクセスすることにより前記１つ以上の試験計器にアクセスするように構成される、請求項１７３に記載のシステム。
【請求項１７５】
前記試験プログラムは、専ら前記仮想計器を通じて前記１つ以上の計器にアクセスするようプログラムされる、請求項１７４に記載のシステム。
【請求項１７６】
前記仮想計器エンティティは、前記１つ以上の試験ハードウェアに特有のプログラミングインターフェースから前記試験プログラムを分離する、請求項１７２に記載のシステム。
【請求項１７７】
前記仮想計器は、仮想計器プログラミングインターフェースを含む、請求項１７２に記載のシステム。
【請求項１７８】
前記１つ以上の試験計器における変化は、前記仮想計器プログラミングインターフェースに相応の変化をもたらさない、請求項１７７に記載のシステム。
【請求項１７９】
前記仮想計器エンティティにおける変化は、前記１つ以上のファンクションに相応の変化をもたらさない、請求項１７３に記載のシステム。
【請求項１８０】
前記１つ以上のファンクションは、コンピュータシステムのメモリ構造にロードされる、請求項１７９に記載のシステム。
【請求項１８１】
前記仮想計器エンティティにおける前記変化は、前記コンピュータシステムの前記メモリ構造に相応の変化をもたらさない、請求項１８０に記載のシステム。
【請求項１８２】
前記１つ以上のファンクションは、前記コンピュータシステムの前記メモリ構造の中で第１の位置に置かれる、請求項１８１に記載のシステム。
【請求項１８３】
前記仮想計器エンティティにおける前記変化は、１つ以上の追加ファンクションを追加することを含む、請求項１８２に記載のシステム。
【請求項１８４】
前記仮想計器エンティティにおける前記変化は、前記１つ以上のファンクションの内少なくとも１つを修正することを含む、請求項１８２に記載のシステム。
【請求項１８５】
前記１つ以上の追加ファンクションは、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置の後ろに続く第２の位置に追加される、請求項１８３に記載のシステム。
【請求項１８６】
前記１つ以上の追加ファンクションの前記追加は、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置における前記１つ以上のファンクションの前記位置を変えない、請求項１８５に記載のシステム。
【請求項１８７】
前記コンピュータシステムの前記メモリ構造はさらに、ｖテーブルを備える、請求項１８６に記載のシステム。
【請求項１８８】
前記１つ以上の追加ファンクションの前記追加は、前記ｖテーブルにおける前記１つ以上のファンクションの位置を変えない、請求項１８７に記載のシステム。
【請求項１８９】
前記仮想計器エンティティにおける前記変化は、少なくとも１つの修正済みファンクションを追加することを含む、請求項１８４に記載のシステム。
【請求項１９０】
前記少なくとも１つの修正済みファンクションは、前記１つ以上のファンクションの内前記少なくとも１つから修正される、請求項１８９に記載のシステム。
【請求項１９１】
前記少なくとも１つの修正済みファンクションは、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置の後ろに続く第２の位置に追加される、請求項１９０に記載のシステム。
【請求項１９２】
前記少なくとも１つの修正済みファンクションの前記追加は、前記コンピュータシステムの前記メモリ構造の中で前記第１の位置における前記１つ以上のファンクションの前記位置を変えない、請求項１９１に記載のシステム。
【請求項１９３】
前記コンピュータシステムの前記メモリ構造はさらに、ｖテーブルを備える、請求項１９２に記載のシステム。
【請求項１９４】
前記少なくとも１つの修正済みファンクションの前記追加は、前記ｖテーブルにおける前記１つ以上のファンクションの位置を変えない、請求項１９３に記載のシステム。
【請求項１９５】
前記仮想計器エンティティにおける前記変化は、１つ以上の追加ファンクションを追加することを含む、請求項１８２に記載のシステム。
【請求項１９６】
前記１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、前記基本プログラミングクラスは、前記１つ以上の追加ファンクションを含む拡張クラスのファンクションから継承される、請求項１８３に記載のシステム。
【請求項１９７】
前記１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、前記基本プログラミングクラスは、前記少なくとも１つの修正済みファンクションを含む拡張クラスのファンクションから継承される、請求項１８９に記載のシステム。
【請求項１９８】
前記コンピュータシステムは、汎用コンピュータシステムを含む、請求項１８０に記載のシステム。
【請求項１９９】
試験プロセスを実行するシステムであって、該システムは、
実行時に複数の試験計器でプロシージャを実行する試験プログラムであって、前記１つ以上の試験計器はそれぞれ１つ以上のドライバプログラムを有する試験プログラムと、
前記複数の試験計器で前記プロシージャを実行するように構成される仮想マルチサイト計器エンティティとを備え、ここで前記仮想計器エンティティは、前記それぞれ１つ以上のドライバプログラムを通じて前記複数の試験計器にアクセスし、前記仮想マルチサイト計器エンティティは、前記試験プログラムに対し透過的に前記複数の試験計器で前記プロシージャを実行するように構成される、
システム。
【請求項２００】
前記仮想マルチサイト計器は、複数の計器サイトを制御する機能を含む、請求項１９９に記載のシステム。
【請求項２０１】
前記仮想マルチサイト計器エンティティは、１つ以上のファンクションを含む、請求項１９９に記載のシステム。
【請求項２０２】
前記試験プログラムは、前記仮想計器の前記１つ以上ファンクションにアクセスすることにより前記複数の計器にアクセスするように構成される、請求項２０１に記載のシステム。
【請求項２０３】
前記試験プログラムは、専ら前記仮想計器を通じて前記複数の計器にアクセスするようプログラムされる、請求項２０２に記載のシステム。
【請求項２０４】
前記仮想マルチサイト計器は、前記複数の計器に特有のプログラミングインターフェースから前記試験プログラムを分離する、請求項１９９に記載のシステム。
【請求項２０５】
前記仮想マルチサイト計器は、仮想マルチサイト計器プログラミングインターフェースを含む、請求項１９９に記載のシステム。
【請求項２０６】
前記複数の試験計器の内少なくとも１つにおける変化は、前記仮想マルチサイト計器プログラミングインターフェースに相応の変化をもたらさない、請求項２０５に記載のシステム。
【請求項２０７】
前記仮想マルチサイト計器エンティティにおける変化は、前記１つ以上のファンクションに相応の変化をもたらさない、請求項２０１に記載のシステム。
【請求項２０８】
前記１つ以上のファンクションは、コンピュータシステムのメモリ構造にロードされる、請求項２０７に記載のシステム。
【請求項２０９】
前記仮想マルチサイト計器エンティティにおける前記変化は、前記コンピュータシステムの前記メモリ構造に相応の変化をもたらさない、請求項２０８に記載のシステム。
【請求項２１０】
前記仮想マルチサイト計器エンティティは、前記複数の試験計器で概ね同時に前記プロシージャを実行するように構成される、請求項１９９に記載のシステム。
【請求項２１１】
試験プロセスを実行するシステムであって、該システムは、
試験システムと、
通信ネットワークによって前記試験システムへ結合された少なくとも１つのクライアントコンピュータとを備え、ここで前記クライアントコンピュータを操作するユーザは、前記試験システムで複数の試験ファンクションを実行できる、
システム。
【請求項２１２】
実行時に１つ以上の試験計器でプロシージャを実行する試験プログラムをさらに備え、前記１つ以上の試験計器は、それぞれ１つ以上のドライバプログラムを有する、請求項２１１に記載のシステム。
【請求項２１３】
クライアントコンピュータから前記通信ネットワークを通じて１つ以上のリクエストを受け取るプロセスをさらに備える、請求項２１１に記載のシステム。
【請求項２１４】
前記少なくとも１つのクライアントコンピュータは、前記試験システムにアクセスするためのユーザインターフェースコンポーネントを含む、請求項２１１に記載のシステム。
【請求項２１５】
前記ユーザインターフェースコンポーネントは、前記少なくとも１つのクライアントコンピュータ上で実行するブラウザプログラムを用いて操作される、請求項２１４に記載のシステム。
【請求項２１６】
前記試験システムはさらに、前記複数の試験計器で前記プロシージャを実行するように構成される仮想マルチサイト計器エンティティを備え、ここで前記仮想計器エンティティは、前記それぞれ１つ以上のドライバプログラムを通じて前記複数の試験計器にアクセスし、前記仮想マルチサイト計器エンティティは、前記試験プログラムに対し透過的に前記複数の試験計器で前記プロシージャを実行するように構成される、請求項２１２に記載のシステム。
【請求項２１７】
前記試験システムはさらに、前記１つ以上の試験計器で前記プロシージャを実行するように構成される仮想計器エンティティを備え、ここで前記仮想計器エンティティは、前記それぞれ１つ以上のドライバプログラムを通じて前記１つ以上の試験計器にアクセスする、請求項２１２に記載のシステム。
【請求項２１８】
前記ユーザインターフェースコンポーネントは、前記クライアントコンピュータを操作する前記ユーザに基づき構成される、請求項２１４に記載のシステム。
【請求項２１９】
前記試験システムは、複数のユーザインターフェースを蓄積するように構成され、且つ前記ユーザに対応するユーザインターフェース構成に基づき少なくとも１つのユーザインターフェースを前記ユーザに提供するように構成される、請求項２１８に記載のシステム。
【請求項２２０】
前記仮想計器エンティティは、１つ以上のファンクションを含む、請求項２１７に記載のシステム。
【請求項２２１】
前記試験プログラムは、前記仮想計器の前記１つ以上のファンクションにアクセスすることにより前記１つ以上の試験計器にアクセスするように構成される、請求項２２０に記載のシステム。
【請求項２２２】
前記試験プログラムは、専ら前記仮想計器を通じて前記１つ以上の計器にアクセスするようプログラムされる、請求項２２１に記載のシステム。
【請求項２２３】
前記仮想計器エンティティは、前記１つ以上の試験ハードウェアに特有のプログラミングインターフェースから前記試験プログラムを分離する、請求項２１７に記載のシステム。
【請求項２２４】
前記仮想計器は、仮想計器プログラミングインターフェースを含む、請求項２１７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
発明の分野
本発明は、一般的には試験システムに関し、より具体的には自動試験装置（ＡＴＥ）分野の試験システムに関する。
【背景技術】
【０００２】
関連技術の説明
今日では、ＡＴＥ分野における殆どの試験装置には１つ以上のコンピュータシステムを伴う。試験ステップを実施するコンピュータシステムは信頼性に優れ、試験ステップを決定的に生成しなければならない。つまりコンピュータシステムは、一貫性のある結果を出すことができなければならない。そのようなコンピュータに伴う１つの問題はコストである。試験での使用に適した完全な計算システム（例えば一貫性のある結果を出すもの）の設計には、ハードウェア設計とメンテナンスに費用がかかるばかりでなく、オペレーティングシステム、ユーザインターフェース、ドライバ、ツール等を含むソフトウェアの設計にも費用がかかる。より具体的に、決定性の実行を達成するには、高価な計算ハードウェアおよびソフトウェアを、ならびに／またはテスタ内分散ハードウェアを、例えば計器内の単独制御プロセッサを、あるいはその他の試験リソースを、使用する。その結果、ＡＴＥに適したコンピュータシステムの購入とメンテナンスは殆どの会社にとって非常に高くつく。
【０００３】
自動試験装置（ＡＴＥ）は、電子デバイスの機能と性能を試験するコンピュータ制御装置である。ＡＴＥデバイスはまた、ヒトとのやり取りを最小限に抑えながらストレス試験を行う。典型的なＡＴＥテスタは、制御ハードウェアと、センサと、試験結果とを収集し解析するソフトウェアとを含む。かかるＡＴＥテスタは、特定の試験計器に依存しながら試験を実行し、制御ソフトウェアに結果を返す。従来のＡＴＥテスタおよび手法が大量試験の場合に限り費用効果的であることは広く認められている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この広く支持された見解は、従来のＡＴＥテスタの設計と運転に部分的に根ざしている。現状、製造業者は新しいデバイスやシステムを作ることができる。新しいデバイスやシステムの設計、構成で鍵を握るのは、デバイスまたはシステムの品質と、機能と、保守性とを試験する能力である。新しいデバイスの試験にあたって最初にすることは、その新しいデバイスに対応するよう設計され機能するテスタが既に存在するか否かを判断することである。存在しないならば、適当なテスタを作ることが唯一の選択肢となる。今日の市場は、新たなテスタを作るか否かの判断に時間がかかるのだから、かかるテスタの実際の製造に着手するまでにはなおのこと時間がかかる。新しいデバイスに対応する新しいテスタに幅広い需要があるか否か、多少なりとも使い回しがきくか否かの判断によって、新しいテスタを作るか否かが最終的に決まる。幅広い需要がなければ、大抵はその時点で新たなテスタの可能性は終わる。幅広い需要があったとしても、新しいテスタの設計と製造が待っている。そのようなプロセスが完了するまでには、平均して数年ほどかかる。例えば、新しいテスタの製作に２年以上かかることは珍しくない。その間、殆どの製造業者の関心は既により新しいデバイスの試験に向けられているから、テスタがその公表を待たずに時代遅れになることすらある。
【課題を解決するための手段】
【０００５】
発明の概要
本発明の一態様によると、かかるＡＴＥシステムが高くつく理由はとりわけ、それらが特別に開発されたシステムで用途に限りがあるからだと理解する。高度に特化されたＡＴＥシステムは大量生産に向いていないか、さもなくば大量生産のハードウェアコンポーネントやソフトウェアコンポーネントを組み込むのに向いていない。本発明の一態様においては、廉価で汎用性の高いコンポーネントを使ってＡＴＥシステムを製作すれば有利と理解する。
【０００６】
さらに本発明の一態様によると、ＡＴＥシステムのトータルコストが高くつく主な原因はソフトウェアとハードウェアとの緊密な結合にあると理解する。より具体的に、ＡＴＥシステムのコンポーネントは、例えばオペレーティングシステムと、試験プラットフォームと、関連アプリケーションと、基礎となる試験ハードウェアは互いに依存しており、いずれか１つのコンポーネントが変更されると、ＡＴＥシステムは変更前と同じように機能しなくなることがある。ＡＴＥシステム等の決定性システムでそのような変更があると、試験プログラムの動作に違いが生じ、非決定的な試験結果に終わることがある。
【０００７】
このため、実際の生産試験環境でユーザ（例えば試験技師）は既存の生産試験システムに新しい機能を導入することに気乗りしない。例えば、ソフトウェア方式の新しい試験ファンクションが既存の試験システムで利用できるようになると、その新しいソフトウェアの導入によって現在のソフトウェアの動作が中断することがある。例えば、あるソフトウェアドライバが後続バージョンのドライバに差し替えられると、試験システムは同じように機能しなくなり、試験結果に支障をきたすおそれがある。同様に、既存のＡＴＥシステムに改良されたハードウェア（例えば試験計器）を追加すると、既存システムのハードウェアおよび／またはソフトウェアが同じように機能しないか、全く機能しなくなることがある。このため試験技師は通常ならば、既存の試験システムに混乱をきたしてまで新しい機能を実装しようとはせず、むしろ新しい試験ファンクションを実行する新しいハードウェアとソフトウェアを購入する。その結果、試験リソースの運用は非効率的なものとなり、試験プラットフォームの再利用には限りが生じる。さらに、試験用ハードウェアおよびソフトウェアの製造元は現場での問題発生を防ぐためコンポーネントのあらゆる組み合わせを厳密に試験しなければならないので、製造費と試験装置の総費用が膨らむ。
【０００８】
さらに、ＡＴＥのハードウェアとソフトウェアを使用する試験プログラムを試験技師が独自に開発することもある。そのプログラムで使用するハードウェアとソフトウェアは緊密に結合されているので、そのプログラムもまた緊密に結合されたシステムに大きく依存することとなり、基礎システムで何か変更があると、試験プログラムが思うように動かなくなることがある。このため試験技師は普通、新たなソフトウェアおよび／またはハードウェアによる既存生産試験環境への変更を検討したがらない。かかる試験装置は、例えば電子デバイスの製造に使われ、かかる装置の故障は製造スケジュールに影響を及ぼすことがある。
【０００９】
本発明の一態様によると、コンポーネント（例えばハードウェア、ソフトウェア）を、他のコンポーネントの動作に支障をきたすことなく変更できるプラットフォームが提供される。例えば試験環境で、試験開発プラットフォームは試験システムソフトウェアと、様々な試験計器との通信に用いるソフトウェアドライバと、オペレーティングシステムソフトウェアとを含み得る。一態様によると、かかるコンポーネントのファンクションを分離することでコンポーネント間の結合を抑えるアーキテクチャを提供する。こうして、１コンポーネントの変更が他のコンポーネントの動作に支障をきたすことはない。
【００１０】
例えばコンポーネントを追加する場合、そのコンポーネントの追加によって他のコンポーネントのファンクションが乱れることはない。１つの具体例として、試験ハードウェア
（例えば試験計器）の一部分が故障し、交換の必要があるとする。ただし利用できるのは新バージョンの試験ハードウェアだけである。この新バージョンのインターフェースは故障した試験ハードウェアと異なるため、新しいハードウェアにアクセスするソフトウェアとアプリケーションは新しいインターフェースに合わせて変更する必要がある。残念ながら、この変更によってハードウェアとソフトウェアとの通信が断絶するため、古いハードウェアを使っていた試験プログラムと試験アプリケーションはすべて変更し、改めて試験する必要があるから、試験システムの維持費は膨らむ。ただし、場合によっては装置製造業者によるハードウェアとソフトウェアの頻繁な変更のためユーザがなす術を失い、システム全体が機能しなくなることもある。
【００１１】
本発明の一態様によると、試験アプリケーションとその関連ソフトウェア（例えばプラットフォームＯＳ、ドライバ）とハードウェアは緊密に結合していると理解する。一実施形態においては、ハードウェアから試験アプリケーションを分離する抽象層を提供する。一実施形態によると、ユーザに対し共通のインターフェースを提示する仮想計器を提供する。一実施形態によると、基礎ハードウェアが変化してもこのインターフェースが変化することはなく、変更が施された場合にアプリケーションが働かなくなる見込みは低くなる。また、一実施形態によると、特定のハードウェアに固有の実装はアプリケーションから抽象化されるため、仮想計器を使って開発されるアプリケーションは、ハードウェアの種類および／またはバージョンが異なるシステムで使用できる。
【００１２】
一実装においては、インターフェースによってリンクされるモジュール方式のシステムアーキテクチャが提供される。一実装においては、特定のインターフェースに機能を追加するだけのアドオンリー（ａｄｄ−ｏｎｌｙ）インターフェースによってモジュールをリンクすることで、既存のコードと試験プログラムの「破綻」をなくす。別の実装において、かかるインターフェースは特に必要なファンクションだけに抽象化される。
【００１３】
さらに本発明の別の態様によると、新しい自動試験ソリューションを速やかに市場に投入すれば大変有利であると理解する。特に、新たなテスタの製作にかかる時間を短縮する自動試験装置プラットフォームは有益であろう。さらに、製造に先立ち幅広い応用範囲がなくともテスタを作ることができれば有益と理解する。また、新たなテスタを設計せずとも新たな機能をテスタに取り入れることができれば有益であろう。
【００１４】
短時間で製造でき、費用効率的で、新しいデバイスに適応できる柔軟なテスタは、市場のニーズを満たすであろう。そのようなテスタの設計は試みられてはいるが、従来のアーキテクチャでは依然として特定のハードウェアに専用のコードがシステムコードと混ざり合うため、コードは特定のハードウェアに依存することとなり、狭い範囲の用途にしか役に立たない。このファンクションとソフトウェアの相互の依存と混合が従来のＡＴＥテスタを制限しているのである。従来の手法で何らかの変更（ハードウェアの追加または削除、場合によっては同一部品の交換）があると、テスタは正常に機能しなくなることがある。変更されたＡＴＥテスタを正常機能に戻すには別途費用がかかり、試験対象デバイスを市場に出すまでの時間も長引く。
【００１５】
融通のきかない従来のＡＴＥテスタはその開発と保守にコストがかかる。従来の方法では、新たなテスタの開発にゼロから取り組む必要があり、既にあるものを活かすことはできない。本発明の一態様で説明する計器開発者プラットフォームは一連のアーキテクチャ規格を定めることにより、事実上どんなデバイスでも試験できる新たなＡＴＥテスタの適時開発を可能にする。このアーキテクチャなら、既存の試験ファンクションと関係ソフトウェアに変更を加えずとも、既存のテスタを修正し新たな計測能力を盛り込むことも可能である。この試験システムアーキテクチャなら、既存のテスタに新たな計測能力を取り入れながら既にあるものを活かすことができる。これは、ＡＴＥテスタで一連の機能を抽象
化することによって達成する。
【００１６】
本発明の一実装においては、ある特定のテスタに組み込まれる計器を機能モジュールに抽象化する。この抽象化されたモジュールは、ＡＴＥテスタの残りの部分から独立した状態を保ちながら当該計器のファンクションを管理する。特に、プラットフォームレベルで設定されるインターフェースによって試験プラットフォームそのものが独立する。この計器の機能を使ってある特定のデバイスを試験するときには、他の独立抽象層によってモジュールがコールされる。そして、コール元の抽象層から独立したこのモジュールが計器のファンクションを管理し、同抽象層に結果を返す。この例のテスタは専ら他の独立抽象層を通じてこのモジュールとやり取りするから、同じアーキテクチャを採用するテスタならどんなテスタでも、モジュールとその関係計器を「プラグイン」できる。例えば、ある１つのテスタからモジュールと関係計器を取り出すことができ、さらにこれらのモジュールと計器を別のテスタ（同じアーキテクチャのもの）に設置することにより、この第２のテスタの機能は強化され、第２のテスタに既にあるファンクションに影響が及ぶことはない。さらにこの例で、モジュールと計器が取り出された第１のテスタはそれに利用可能な残りの計器で機能し続ける。このアーキテクチャ規格に準拠することで既存テスタの柔軟性と、費用効率と、新規テスタ完成までの加速が実現する。
【００１７】
本発明のさらに別の態様においては、ＡＴＥテスタの機能レベルを抽象化することにより、ＡＴＥテスタのファンクションを含む別々の層に一連のファンクションと機能を分けることができる。一実施形態において、ユーザが操作する試験プログラムは視覚化をバンドルし、特定のデバイスで実行済みの試験か実行されようとしている試験から結果やオプションを図式的に表示する。例えばユーザは、ただひとつの試験プログラムや多数の試験プログラムを使ってどんなデバイスでも試験できる。本発明の態様において、試験プログラムから提供されるファンクションおよび機能の抽象化は、ＡＴＥテスタアーキテクチャの最上位層を形成する。
【００１８】
加えて本発明の一態様によると、仮想計器を作成し管理するためのシステムが提供される。一実施形態において、仮想計器の作成にあたっては、特定のハードウェアに固有の実装ではなく、ユーザが望む機能を踏まえた挙動を仮想計器に盛り込む。例えば、ある特定のファンクションが本質的にソフトウェアドライバで実行されない場合でも、その機能は仮想計器に対応するソフトウェアで実行できる。こうして試験ハードウェアとその関連ドライバの能力は標準的な方法で拡張できる。別の実施形態によると、仮想計器はユーザの視点から作成されるため、アプリケーションの作成は容易くなる。
【００１９】
また、テスタとハードウェアの間に結び付きはないから、テスタとアプリケーションは速やかに作成できる。同様に、ソフトウェアとハードウェアの結び付きはさほど堅固でないから、テスタに関連するハードウェアの改良も容易くなり、ハードウェアを追加／変更してもソフトウェアに影響が及ぶことはない（ソフトウェアは容易くハードウェアと連動する）。ソフトウェアとハードウェアを作成し保守するための柔軟なプラットフォームはソフトウェアの開発担当者と保守担当者にとって有益であり、試験プログラムの作成と保守にかかる費用と手間は減少すると理解する。
【００２０】
本発明の別の態様によると、ソフトウェアファンクションを提供する方法が提供され、ソフトウェアバージョンとハードウェアバージョンの互換性が実現する。本発明の一態様によると、ハードウェアファンクションを参照する仮想計器のファンクションはバージョンからバージョンにかけて変化しない。より具体的に、仮想計器にファンクションが追加されても古いファンクションは保たれ、機能は所定のメモリ構造に追加される。ソフトウェアモジュールに機能が追加されても、メモリに予め存在するファンクションのリファレンスは変わらない。ファンクションのリファレンスが変わらないなら、さらなる機能がメ
モリ構造に追加されても既存の結び付きが断絶することはない。試験プログラムを作成する場合、その試験プログラムからアクセスするファンクションは変わらず機能し続け、ユーザが試験プログラムの変更を決定しない限り、プログラムの機能は凍結される。こうして、試験プログラムの作成と維持にかかる開発・維持費は大幅に減少する。
【００２１】
本発明の一実施形態によると、仮想計器のため仮想ファンクションテーブル（例えばＣ＋＋プログラミング言語で周知の仮想メソッドテーブル「ｖテーブル」）を保守する。一実施形態において、１バージョンの仮想計器ｖテーブルでは、基本セットの機能がｖテーブルにおいて所定の位置を占める。後続バージョンの仮想計器テーブルでさらなるファンクションがｖテーブルに追加されても、基本セットの機能はｖテーブルで同じ位置を保つ。このように、さらなるファンクションが追加されても、ファンクションと、他のソフトウェアとファンクションとの結び付きは維持され、既存のプログラムが壊れることはない。
【００２２】
本発明の別の実施形態によると、本明細書で仮想マルチサイト計器と呼ばれるものが提供され、複数試験サイトの管理を促進する。従来の試験環境ではサイトを単独のエンティティとして管理し、特定の試験サイトを構成する場合は、そのサイトで使用する特定の試験ハードウェア向けに試験プログラムを開発することが分かっている。追加の試験を行うため（例えば試験能力の増大に対応するため）複数のサイトが必要となる場合は、追加の試験ハードウェア構成を購入し、追加のサイトに試験プログラムを投入する。本発明の一態様によると、基礎ハードウェアの詳細は抽象層（例えば仮想計器層）によって試験プログラムから抽出されるから、試験プログラムは試験ハードウェアから独立して管理でき、複数のサイトに対する試験プログラムの運営は抽象層で管理できる。一実施形態において、仮想計器は複数の計器サイトへマップする能力を持つ。こうして、複数のサイトに対する試験プログラムの保守と運営にかかる時間は短縮する。
【００２３】
本発明の別の態様によると、試験プログラムソフトウェアは様々な種類のユーザによって利用されることが分かっている。ユーザには試験アプリケーションを開発する者もいれば、開発されたアプリケーションを試験工程の運営管理に役立てる者もいる。ただし種類の異なるこれらのユーザは、実行するファンクションに応じて特定のユーザインターフェース（ＵＩ）を使用する必要がある。テスタには様々な種類があってユーザインターフェースはテスタの種類によって異なり、ユーザは装置の運転にあたって特定の種類のインターフェースを理解しなければならないことが分かっている。また、ＡＴＥ業界ではアプリケーションとドライバが緊密に結合し、ユーザインターフェースはシステムソフトウェアに結合されていることが分かっている。本発明の一態様によると、標準のユーザインターフェースを使って様々な種類のテスタにアクセスすることにより、ユーザに必要なトレーニングの量を減らす。トレーニングの必要量をさらに減らすためユーザ別のインターフェースを提供し、ユーザが自身の役割に関係する試験ファンクションを実行できるようにする。
【００２４】
さらに本発明の別の態様によると、ユーザがどこからでも試験ファンクションを実行できるようにする試験アーキテクチャが提供される。１つの特定の実装においては、ブラウザプログラムを通じてユーザインターフェースにアクセスし、ユーザは、通信ネットワークを通じて試験システムへ結合された任意の場所から試験ファンクションを実行する。従来の環境では通常、ＵＩがマシンに結合されているが、ネットワークを介してＵＩを利用できるようになれば、ユーザは別の場所からでも試験を実行できる。
【００２５】
以下、添付の図面を参照しながら本発明のさらなる特徴および利点、ならびに本発明の様々な実施形態の構造および動作を詳しく説明する。図面において、同様の参照番号は同様の要素を、または機能的に類似する要素を、示す。加えて、参照番号の左端から１また
は２桁目の数字は、その参照番号が最初に現れるところの図面を識別する。
【００２６】
本発明の一態様によると、システムは、試験プログラムと、試験プログラムからのリクエストに応じて複数のファンクションコールを生成するように構成されるプラットフォームと、複数のファンクションコールを試験ハードウェアで実行される命令にマップするように構成される抽象層とを備える。本発明の一実施形態によると、抽象層はさらに、プラットフォームに対し仮想計器（「ＶＩ」）インターフェースを備える。本発明の別の実施形態によると、抽象層はさらに、プラットフォームに対し仮想マルチサイト（「ＶＭＩ」）インターフェースを備える。本発明の別の実施形態によると、抽象層はさらに、プラットフォームに対しシステム物理計器（「システムＰＩ」）インターフェースを備える。本発明の別の実施形態によると、抽象層はさらに、プラットフォームに対し物理計器（「ＰＩ」）インターフェースを備える。本発明の別の実施形態によると、抽象層はさらに、仮想計器（「ＶＩ」）対物理計器（「ＰＩ」）インターフェースを含む。
【００２７】
本発明の一実施形態によると、抽象層はさらに、システム物理計器（「システムＰＩ」）対仮想計器（「ＶＩ」）インターフェースを含む。本発明の別の実施形態によると、抽象層はさらに、システム物理計器（「システムＰＩ」）対物理計器（「ＰＩ」）インターフェースを含む。本発明の別の実施形態によると、抽象層はさらに、試験プログラム対仮想計器（「ＶＩ」）インターフェースを含む。本発明の別の実施形態によると、抽象層はさらに、試験プログラム対物理計器（「ＰＩ」）インターフェースを含む。本発明の別の実施形態によると、抽象層はさらに、プラットフォーム対仮想計器（「ＶＩ」）インターフェースを含む。本発明の別の実施形態によると、抽象層はさらに、プラットフォーム対物理計器（「ＰＩ」）インターフェースを含む。本発明の別の実施形態によると、抽象層はさらに、プラットフォーム対仮想マルチサイト計器（「ＶＭＩ」）インターフェースを含む。
【００２８】
本発明の一実施形態によると、抽象層はさらに、インターフェース生成エンジンを備える。本発明の別の実施形態によると、インターフェース生成エンジンは、ユーザにインターフェースの生成を案内するように構成されるグラフィカルユーザインターフェースを含む。本発明の別の実施形態によると、インターフェース生成エンジンは、システムのコンポーネント間の通信を管理するためのインターフェースを生成する。本発明の別の実施形態によると、インターフェース生成エンジンは、抽象層のコンポーネント間の通信を管理するためのインターフェースを生成する。本発明の別の実施形態によると、インターフェース生成エンジンは、プラットフォームと抽象層との間の通信を管理するためのインターフェースを生成する。本発明の別の実施形態によると、プラットフォームと抽象層との間の通信を管理することは、試験ハードウェアで実行される命令に複数のファンクションコールをマップすることを含む。本発明の別の実施形態によると、複数のファンクションコールをマップすることは、複数のファンクションコールを仮想計器（「ＶＩ」）モジュールにマップすることを含む。本発明の別の実施形態によると、複数のファンクションコールをマップすることは、複数のファンクションコールをシステム物理計器（「システムＰＩ」）モジュールにマップすることを含む。本発明の別の実施形態によると、複数のファンクションコールをマップすることは、複数のファンクションコールを物理計器（「ＰＩ」）モジュールにマップすることを含む。
【００２９】
本発明の一実施形態によると、複数のファンクションコールをマップすることは、基本クラスの物理計器ファンクションコールを物理計器（「ＰＩ」）モジュールにマップすることを含む。本発明の別の実施形態によると、複数のファンクションコールをマップすることは、基本クラスの物理計器ファンクションコールを物理計器（「ＰＩ」）モジュールにマップすることを含む。本発明の別の実施形態によると、抽象層はさらに、ルールチェックエンジンを備える。本発明の別の実施形態によると、ルールチェックエンジンは、試
験ハードウェアの命令へのファンクションコールのマッピングを検証するように構成される。本発明の別の実施形態によると、ルールチェックエンジンは、ファンクションコールのリクエストを模擬することによってマッピングを検証する。本発明の別の実施形態によると、ルールチェックエンジンは、模擬ファンクションコールの結果として応答を所期形式で受け付けることによってマッピングを検証する。本発明の別の実施形態によると、ルールチェックエンジンは、ファンクションコールが正常にマップされたことを伝えるコードを操作プラットフォームに返す。本発明の別の実施形態によると、ルールチェックエンジンは、模擬ファンクションコールに応じて所期形式になっていない戻りコードを受け付けることにより不適切なマッピングを識別する。本発明の別の実施形態によると、システムはさらに、試験プログラムとプラットフォームとの間にインターフェースを備える。
【００３０】
本発明の一実施形態によると、試験プログラムは、ユーザに対しグラフィカルユーザインターフェースを提供する。本発明の別の実施形態によると、試験プログラムは、ユーザがデバイスに実行する試験を設定することを可能にする。本発明の別の実施形態によると、試験プログラムは、ユーザがデバイスに実行する試験を任意のときに行うよう設定することを可能にする。本発明の別の実施形態によると、抽象層はさらに、試験システムのハードウェアリソースの機能を表現する物理計器抽象層を備える。本発明の別の実施形態によると、物理計器抽象層は、ハードウェアリソースにマップする物理計器モジュールを含む。本発明の別の実施形態によると、ＰＩモジュールは、リクエストに応じてハードウェアリソース上での命令実行を生起させる。本発明の別の実施形態によると、ハードウェアリソースは、試験ハードウェア上で使用できる少なくとも１つのファンクションを含む。本発明の別の実施形態によると、ハードウェアリソースは、同期信号の生成を生起させるように構成される。本発明の別の実施形態によると、ハードウェアリソースは、デバイス状態クエリを生起させるように構成される。
【００３１】
本発明の一実施形態によると、ＰＩモジュールは、デバイス開始状態に応じてデバイスの電力オンおよび／または初期化を生起させるファンクションコールを含む。本発明の別の実施形態によると、物理計器モジュールは、基本クラスのＰＩファンクションコールを含む。本発明の別の実施形態によると、基本クラスのＰＩファンクションコールは、電力オン／初期化ファンクションを含む。本発明の別の実施形態によると、抽象層はさらに、試験システムで実行されるハードウェアファンクションの仮想を表現する仮想計器抽象層を備える。本発明の別の実施形態によると、仮想計器抽象層は、仮想計器（「ＶＩ」）モジュールを含み、少なくとも１つのハードウェアリソースは同ＶＩモジュールにマップされる。本発明の別の実施形態によると、ＶＩモジュールは、リクエストに応じてハードウェアリソース上での命令実行を生起させるように構成される。本発明の別の実施形態によると、少なくとも１つのリソースにマップすることは、少なくとも１つのハードウェアリソースの各々につき少なくとも１つのＰＩモジュールを通じてマップされる。本発明の別の実施形態によると、ＶＩモジュールは、ある特定のデバイスの試験に用いる１セットの既定ハードウェアリソースの仮想表現を提示するため、複数のＰＩモジュールにマップされる。
【００３２】
本発明の一実施形態によると、ＶＩモジュールは追加ＰＩモジュールを含むよう修正されるように構成され、この修正により、ＶＩモジュールを通じてデバイスを試験するのに利用できる１セットのハードウェアリソースを拡張する。本発明の別の実施形態によると、ＶＩモジュールは、ＡＴＥテスタに必要な試験ハードウェアリソースにマップする基本クラスのファンクションを含むように構成される。本発明の別の実施形態によると、抽象層はさらに、ハードウェアリソースに対するリクエストを管理するように構成されるシステム抽象層を備える。本発明の別の実施形態によると、システム抽象層はさらに、リクエストに応じてハードウェアリソースにファンクションを実行させるため、物理計器層からのリクエストをマップするように構成される。本発明の別の実施形態によると、システム
抽象層はさらに、抽象層の他のコンポーネントで利用できる基本セットのシステムファンクションコールを規定するように構成される。本発明の別の実施形態によると、システム層はさらに、抽象層の他のコンポーネントに操作を実行させる基本セットのシステムファンクションコールを規定するように構成されるシステムＰＩモジュールを備える。本発明の別の実施形態によると、システム抽象層はさらに、抽象層のコンポーネントに対しクエリを実行するように構成される。
【００３３】
本発明の一実施形態によると、システム抽象層は、システム物理計器モジュールを含む。本発明の別の実施形態によると、プラットフォーム層は、「既製」オペレーティングシステムを含む。本発明の別の実施形態によると、「既製」オペレーティングシステムは、決定的に実行するよう強化される。本発明の別の実施形態によると、「既製」オペレーティングシステムは、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰであって、これは、Ｔｅｎａｓｙｓ  ＩＮｔｉｍｅオペレーティングシステムを用いて決定的に作動するよう強化される。
【００３４】
本発明の一態様によると、自動試験装置システムが提供される。同システムは、自動試験装置システムの抽象層の動作を管理するように構成されるプラットフォーム抽象層と、ＰＩファンクションコールに応じてハードウェアがファンクションを実行するようＰＩファンクションコールをハードウェアにマップするように構成される物理計器（「ＰＩ」）抽象層と、ＰＩ抽象層にマップするように構成され、実行されるハードウェアファンクションの仮想を表現する仮想計器（「ＶＩ」）抽象層と、ＰＩファンクションコールに応じてハードウェアがファンクションを実行することを可能にするためシステムファンクションコールをマップするように構成されるシステム抽象層と、ハードウェア上で実行されるファンクションを起動するため仮想計器層とやり取りするように構成される試験プログラム抽象層とを備える。本発明の別の実施形態によると、システム抽象層はさらに、システム物理計器（「システムＰＩ」）モジュールに抽象化され、同システムＰＩモジュールはＰＩ抽象層からリクエストを受け、これに応じてハードウェアにそのファンクションを実行させる。本発明の別の実施形態によると、システムＰＩモジュールはさらに、自動試験装置システムの他の抽象層によって報告される情報を集約するように構成される。本発明の別の実施形態によると、集約情報は、自動試験装置システムの他の抽象層で行われるファンクションコールの成否を含む。本発明の別の実施形態によると、集約情報は、自動試験装置システムの他の抽象層での操作による報告を含む。本発明の別の実施形態によると、システムＰＩモジュールはさらに、集約情報に対するクエリを受け付けるように構成される。
【００３５】
本発明の一実施形態によると、システムＰＩモジュールはさらに、集約情報を報告するように構成される。本発明の別の実施形態によると、試験プログラム抽象層は、ユーザに対しグラフィカルユーザインターフェースを提示するように構成される試験プログラムを含む。本発明の別の実施形態によると、試験プログラム層はさらに、ユーザに仮想計器層とやり取りさせるように構成される。本発明の別の実施形態によると、試験プログラム層はさらに、デバイスに実行する試験をユーザに設定させるように構成される。本発明の別の実施形態によると、試験プログラムはさらに、試験の実行結果を図式的に提示するように構成される。本発明の別の実施形態によると、試験プログラム層はさらに、デバイスに実行する試験をユーザに設定させるように構成され、ここで実行される試験は、スケジュールされたときに行われる。本発明の別の実施形態によると、実行される試験は、ユーザによって設定された任意のスケジュールに沿って行うことができる。本発明の別の実施形態によると、仮想計器抽象層は、ＶＩモジュールを含み、ここでＶＩモジュールは、少なくとも１つのハードウェアリソースへのマッピングを含む。
【００３６】
本発明の一実施形態によると、ＶＩモジュールは、リクエストに応じて少なくとも１つのハードウェアリソースにそのファンクションを実行させるように構成される。本発明の
別の実施形態によると、ＶＩモジュールは、試験プログラム抽象層からのリクエストに応じて少なくとも１つのハードウェアリソースにそのファンクションを実行させる。本発明の別の実施形態によると、少なくとも１つのハードウェアリソースへのマッピングは、ＰＩ計器層を通じてマップされる。本発明の別の実施形態によると、少なくとも１つのハードウェアリソースへのマッピングは、ＰＩモジュールを通じてマップされる。本発明の別の実施形態によると、ＶＩモジュールは、複数のＰＩモジュールにマップされ、したがってＶＩモジュールは、デバイスの試験に用いる複数のハードウェアリソースの仮想表現を提示する。本発明の別の実施形態によると、ＶＩモジュールとＰＩモジュールとの間のマッピングは、インターフェースによって管理される。本発明の別の実施形態によると、インターフェースは、グラフィカルユーザインターフェースである。本発明の別の実施形態によると、インターフェースは、ＶＩモジュールとＰＩモジュールとの間の通信を所定の形式で管理する。本発明の別の実施形態によると、ＶＩモジュールは、追加ＰＩモジュールへのマッピングを含むよう修正されるように構成される。本発明の別の実施形態によると、ＶＩモジュールは、ＡＴＥテスタに必要な試験ハードウェアリソースにマップする基本クラスのファンクションを含むように構成される。本発明の別の実施形態によると、物理計器抽象層は、ハードウェアリソースの実装詳細を収容するＰＩモジュールを含む。
【００３７】
本発明の一実施形態によると、物理計器抽象層は、各ハードウェアリソースの実装詳細を収容するＰＩモジュールを含む。本発明の別の実施形態によると、物理計器抽象層は、新規ハードウェアリソースの実装詳細を取り入れるように構成される。本発明の別の実施形態によると、新規ハードウェアリソースは、新規ＰＩモジュールによってマップされる。本発明の別の実施形態によると、ＰＩモジュールは、リクエストに応じてハードウェアリソースの機能の実行を生起させる。本発明の別の実施形態によると、リクエストは、ＶＩモジュールから到来する。本発明の別の実施形態によると、ハードウェアリソースの機能は、同期信号を含む。本発明の別の実施形態によると、物理計器モジュールは、ハードウェアリソースの電力オンおよび／または初期化を生起させるファンクションコールを含む。本発明の別の実施形態によると、ファンクションコールは、ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションを含む。本発明の別の実施形態によると、ＰＩ抽象層は、基本クラスのＰＩファンクションコールを含む。本発明の別の実施形態によると、基本クラスのＰＩファンクションコールは、ハードウェアリソースの電力オンおよび／または初期化を生起させるように構成されるファンクションコールを含む。
【００３８】
本発明の一実施形態によると、ハードウェアリソースの電力オンおよび／または初期化を生起させるように構成されるファンクションコールは、ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションを含む。本発明の別の実施形態によると、プラットフォーム抽象層は、「既製」オペレーティングシステムを含む。本発明の別の実施形態によると、「既製」オペレーティングシステムは、決定的に実行するよう強化される。本発明の別の実施形態によると、「既製」オペレーティングシステムは、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰである。本発明の別の実施形態によると、オペレーティングシステムは、リアルタイムエクステンションを用いて決定的に実行するよう強化される。本発明の別の実施形態によると、リアルタイムエクステンションは、「Ｔｅｎａｓｙｓ  ＩＮｔｉｍｅ」オペレーティングシステムを通じて提供される。本発明の別の実施形態によると、プラットフォーム抽象層は、決定的に作動する。
【００３９】
本発明の別の実施形態によると、システムは、抽象層間の通信を管理するように構成されるインターフェース抽象層をさらに備える。本発明の別の実施形態によると、インターフェース抽象層はさらに、抽象層間で規格化された通信を保証するように構成される。本発明の別の実施形態によると、インターフェース抽象層は、プラットフォーム抽象層とＶＩ抽象層との間にインターフェースを含む。本発明の別の実施形態によると、インターフェース抽象層は、プラットフォーム抽象層とシステム抽象層との間にインターフェースを
含む。本発明の一実施形態によると、インターフェース抽象層は、プラットフォーム抽象層と物理計器抽象層との間にインターフェースを含む。
【００４０】
本発明の別の実施形態によると、インターフェース抽象層は、ＶＩモジュールとＰＩモジュールとの間にインターフェースを含む。本発明の別の実施形態によると、インターフェース抽象層は、システムＰＩモジュールとＶＩモジュールとの間にインターフェースを含む。本発明の別の実施形態によると、インターフェース抽象層は、システムＰＩモジュールとＰＩモジュールとの間にインターフェースを含む。本発明の別の実施形態によると、インターフェース抽象層は、プラットフォーム抽象層とＶＩ抽象層との間にインターフェースを含む。本発明の別の実施形態によると、システムはさらに、ユーザにＰＩモジュールとＶＩモジュールのいずれか一方の作成を案内するように構成されるモジュール生成エンジンを備え、これにより自動試験システムは、新規試験ハードウェアリソースを取り入れることができる。本発明の別の実施形態によると、システムはさらに、ユーザにインターフェースの作成を案内するように構成されるインターフェース生成エンジンを備え、ここでインターフェースは、自動試験システムで使用するハードウェア、ソフトウェア、またはプラットフォームにかかわりなく通信形式を規格化することによってモジュール間通信を管理する。
【００４１】
本発明の一実施形態によると、システムはさらに、生成済みモジュールとその生成済みインターフェースとの試験機能を検証するように構成されるルールチェックエンジンを備える。本発明の別の実施形態によると、システムはさらに、生成済みモジュールをユーザにインストールさせるように構成されるインストールモジュールを備え、これにより試験プログラムは、生成済みモジュールへリクエストを差し向け、且つ試験ファンクションを実行させることができる。本発明の別の実施形態によると、システムはさらに、生成済みインターフェースをユーザにインストールさせるように構成されるインストールモジュールを備え、これにより試験プログラムは、生成済みモジュールによってマップされた試験ハードウェアリソースへリクエストを差し向け、且つ試験ファンクションを実行させることができる。本発明の一態様によると、試験プロセスを実行するシステムが提供される。同システムは、実行時に１つ以上の試験計器でプロシージャを実行する試験プログラムを備え、１つ以上の試験計器はそれぞれ１つ以上のドライバプログラムを有し、同システムはさらに１つ以上の試験計器でプロシージャを実行するように構成される仮想計器エンティティを備え、ここで仮想計器エンティティは、それぞれ１つ以上のドライバプログラムを通じて１つ以上の試験計器にアクセスする。本発明の別の実施形態によると、仮想計器エンティティは、１つ以上のファンクションを含む。本発明の別の実施形態によると、試験プログラムは、仮想計器の１つ以上のファンクションにアクセスすることにり１つ以上の試験計器にアクセスするように構成される。本発明の別の実施形態によると、試験プログラムは、専ら仮想計器を通じて１つ以上の計器にアクセスするようプログラムされる。本発明の別の実施形態によると、試験プログラムは、テスタリソースにアクセスするためシステム物理インターフェースにアクセスするようプログラムされる。本発明の別の実施形態によると、仮想計器エンティティは、１つ以上の試験ハードウェアに特有のプログラミングインターフェースから試験プログラムを分離する。本発明の別の実施形態によると、仮想計器は、仮想計器プログラミングインターフェースを含む。本発明の別の実施形態によると、１つ以上の試験計器における変化は、仮想計器プログラミングインターフェースに相応の変化をもたらさない。
【００４２】
本発明の一実施形態によると、仮想計器エンティティにおける変化は、１つ以上のファンクションに相応の変化をもたらさない。本発明の別の実施形態によると、物理テスタリソースにおける変化は、１つ以上のファンクションに相応の変化をもたらさない。本発明の別の実施形態によると、試験開発プラットフォームにおける変化は、試験プラットフォームにおける変化を要求しない。本発明の別の実施形態によると、１つ以上のファンクシ
ョンは、コンピュータシステムのメモリ構造にロードされる。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、コンピュータシステムのメモリ構造に相応の変化をもたらさない。本発明の別の実施形態によると、１つ以上のファンクションは、コンピュータシステムのメモリ構造の中で第１の位置に置かれる。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、１つ以上の追加ファンクションを追加することを含む。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、１つ以上のファンクションの内少なくとも１つを修正することを含む。本発明の別の実施形態によると、１つ以上の追加ファンクションは、コンピュータシステムのメモリ構造の中で第１の位置の後ろに続く第２の位置に追加される。本発明の別の実施形態によると、１つ以上の追加ファンクションの追加は、コンピュータシステムのメモリ構造の中で第１の位置における１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、コンピュータシステムのメモリ構造はさらに、ｖテーブルを備える。本発明の別の実施形態によると、１つ以上の追加ファンクションの追加は、ｖテーブルにおける１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む。
【００４３】
本発明の一実施形態によると、少なくとも１つの修正済みファンクションは、１つ以上のファンクションの内少なくとも１つから修正される。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションは、コンピュータシステムのメモリ構造の中で第１の位置の後ろに続く第２の位置に追加される。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションの追加は、コンピュータシステムのメモリ構造の中で第１の位置における１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、コンピュータシステムのメモリ構造はさらに、ｖテーブルを備える。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションの追加は、ｖテーブルにおける１つ以上のファンクションの位置を変えない。
【００４４】
本発明の別の実施形態によると、１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、基本プログラミングクラスは、１つ以上の追加ファンクションを含む拡張クラスのファンクションから継承される。本発明の別の実施形態によると、１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、基本プログラミングクラスは、少なくとも１つの修正済みファンクションを含む拡張クラスのファンクションから継承される。本発明の別の実施形態によると、コンピュータシステムは、汎用コンピュータシステムを含む。本発明の別の実施形態によると、１つ以上の試験計器は、１つ以上の試験対象デバイスに結合される。本発明の別の実施形態によると、１つ以上の試験計器の内少なくとも１つは、１つ以上の試験対象デバイスの内少なくとも１つに試験信号を適用するよう試験プログラムによりプログラムされる。
【００４５】
本発明の一態様によると、試験プロセスを実行するシステムが提供される。同システムは、それぞれ１つ以上のドライバプログラムを有する１つ以上の試験計器を備え、ここでドライバプログラムの内少なくとも１つは１つ以上のファンクションを含み、同システムはさらに、実行時に１つ以上の試験計器でプロシージャを実行する試験プログラムを備え、試験プログラムは１つ以上のドライバプログラムを通じて１つ以上の試験計器にアクセスし、同システムはさらに、メモリ構造を備え、ここでドライバプログラムの内少なくとも１つの１つ以上のファンクションは、メモリ構造により固定位置の中に収容される。本発明の一実施形態によると、メモリ構造は、コンピュータシステムのメモリに含まれ、ここで１つ以上のファンクションは、コンピュータシステムのメモリにロードされる。本発明の別の実施形態によると、ドライバプログラムの内少なくとも１つにおける変化は、メモリ構造に相応の変化をもたらさない。本発明の別の実施形態によると、１つ以上のファンクションは、メモリ構造内の第１の位置に置かれる。本発明の別の実施形態によると、
ドライバプログラムの内少なくとも１つにおける変化は、１つ以上の追加ファンクションを追加することを含む。本発明の別の実施形態によると、ドライバプログラムの内少なくとも１つにおける変化は、１つ以上のファンクションの内少なくとも１つを修正することを含む。
【００４６】
本発明の一実施形態によると、１つ以上の追加ファンクションは、メモリ構造の中で第１の位置の後ろに続く第２の位置に追加される。本発明の別の実施形態によると、１つ以上の追加ファンクションの追加は、メモリ構造の中で第１の位置における１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、メモリ構造はさらに、ｖテーブルを備える。本発明の別の実施形態によると、１つ以上の追加ファンクションの追加は、ｖテーブルにおける１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む。本発明の別の実施形態によると、プラットフォームエンティティにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む。本発明の別の実施形態によると、物理計器ドライバにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションは、１つ以上のファンクションの内少なくとも１つから修正される。
【００４７】
本発明の一実施形態によると、少なくとも１つの修正済みファンクションは、メモリ構造の中で第１の位置の後ろに続く第２の位置に追加される。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションの追加は、メモリ構造の中で第１の位置における１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、メモリ構造はさらに、ｖテーブルを備える。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションの追加は、ｖテーブルにおける１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、基本プログラミングクラスは、１つ以上の追加ファンクションを含む拡張クラスのファンクションから継承される。本発明の別の実施形態によると、１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、基本プログラミングクラスは、少なくとも１つの修正済みファンクションを含む拡張クラスのファンクションから継承される。本発明の別の実施形態によると、コンピュータシステムは、汎用コンピュータシステムを含む。本発明の別の実施形態によると、１つ以上の試験計器は、１つ以上の試験対象デバイスに結合される。本発明の別の実施形態によると、１つ以上の試験計器の内少なくとも１つは、１つ以上の試験対象デバイスの内少なくとも１つに試験信号を適用するよう試験プログラムによりプログラムされる。
【００４８】
本発明の一実施形態によると、システムは、自動試験システムの一部である。本発明の別の実施形態によると、システムはさらに、１つ以上の試験計器でプロシージャを実行するように構成される仮想計器エンティティを備え、ここで仮想計器エンティティは、それぞれ１つ以上のドライバプログラムを通じて１つ以上の試験計器にアクセスする。本発明の別の実施形態によると、仮想計器エンティティは、１つ以上のファンクションを含む。本発明の別の実施形態によると、試験プログラムは、仮想計器の１つ以上のファンクションにアクセスすることにり１つ以上の試験計器にアクセスするように構成される。本発明の別の実施形態によると、試験プログラムは、専ら仮想計器を通じて１つ以上の計器にアクセスするようプログラムされる。本発明の別の実施形態によると、仮想計器エンティティは、１つ以上の試験ハードウェアに特有のプログラミングインターフェースから試験プログラムを分離する。本発明の別の実施形態によると、仮想計器は、仮想計器プログラミングインターフェースを含む。本発明の別の実施形態によると、１つ以上の試験計器における変化は、仮想計器プログラミングインターフェースに相応の変化をもたらさない。本
発明の別の実施形態によると、仮想計器エンティティにおける変化は、１つ以上のファンクションに相応の変化をもたらさない。本発明の別の実施形態によると、１つ以上のファンクションは、コンピュータシステムのメモリ構造にロードされる。
【００４９】
本発明の一実施形態によると、仮想計器エンティティにおける変化は、コンピュータシステムのメモリ構造に相応の変化をもたらさない。本発明の別の実施形態によると、１つ以上のファンクションは、コンピュータシステムのメモリ構造の中で第１の位置に置かれる。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、１つ以上の追加ファンクションを追加することを含む。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、１つ以上のファンクションの内少なくとも１つを修正することを含む。本発明の別の実施形態によると、１つ以上の追加ファンクションは、コンピュータシステムのメモリ構造の中で第１の位置の後ろに続く第２の位置に追加される。本発明の別の実施形態によると、１つ以上の追加ファンクションの追加は、コンピュータシステムのメモリ構造の中で第１の位置における１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、コンピュータシステムのメモリ構造はさらに、ｖテーブルを備える。本発明の別の実施形態によると、１つ以上の追加ファンクションの追加は、ｖテーブルにおける１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、少なくとも１つの修正済みファンクションを追加することを含む。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションは、１つ以上のファンクションの内少なくとも１つから修正される。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションは、コンピュータシステムのメモリ構造の中で第１の位置の後ろに続く第２の位置に追加される。
【００５０】
本発明の一実施形態によると、少なくとも１つの修正済みファンクションの追加は、コンピュータシステムのメモリ構造の中で第１の位置における１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、コンピュータシステムのメモリ構造はさらに、ｖテーブルを備える。本発明の別の実施形態によると、少なくとも１つの修正済みファンクションの追加は、ｖテーブルにおける１つ以上のファンクションの位置を変えない。本発明の別の実施形態によると、仮想計器エンティティにおける変化は、１つ以上の追加ファンクションを追加することを含む。本発明の別の実施形態によると、１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、基本プログラミングクラスは、１つ以上の追加ファンクションを含む拡張クラスのファンクションから継承される。本発明の別の実施形態によると、１つ以上のファンクションは、基本プログラミングクラスのファンクションに含まれ、基本プログラミングクラスは、少なくとも１つの修正済みファンクションを含む拡張クラスのファンクションから継承される。本発明の別の実施形態によると、コンピュータシステムは、汎用コンピュータシステムを含む。
【００５１】
本発明の一態様によると、試験プロセスを実行するシステムが提供される。同システムは、実行時に複数の試験計器でプロシージャを実行する試験プログラムを備え、１つ以上の試験計器はそれぞれ１つ以上のドライバプログラムを有し、同システムはさらに、複数の試験計器でプロシージャを実行するように構成される仮想マルチサイト計器エンティティを備え、ここで仮想計器エンティティは、それぞれ１つ以上のドライバプログラムを通じて複数の試験計器にアクセスし、仮想マルチサイト計器エンティティは、試験プログラムに対し透過的に複数の試験計器でプロシージャを実行するように構成される。本発明の一実施形態によると、仮想マルチサイト計器は、複数の計器サイトを制御する機能を含む。本発明の別の実施形態によると、仮想マルチサイト計器エンティティは、１つ以上のファンクションを含む。本発明の別の実施形態によると、試験プログラムは、仮想計器の１つ以上ファンクションにアクセスすることにより複数の計器にアクセスするように構成される。本発明の別の実施形態によると、試験プログラムは、専ら仮想計器を通じて複数の
計器にアクセスするようプログラムされる。本発明の別の実施形態によると、仮想マルチサイト計器は、複数の計器に特有のプログラミングインターフェースから試験プログラムを分離する。本発明の別の実施形態によると、仮想マルチサイト計器は、仮想マルチサイト計器プログラミングインターフェースを含む。
【００５２】
本発明の一実施形態によると、複数の試験計器の内少なくとも１つにおける変化は、仮想マルチサイト計器プログラミングインターフェースに相応の変化をもたらさない。本発明の別の実施形態によると、仮想マルチサイト計器エンティティにおける変化は、１つ以上のファンクションに相応の変化をもたらさない。本発明の別の実施形態によると、１つ以上のファンクションは、コンピュータシステムのメモリ構造にロードされる。本発明の別の実施形態によると、仮想マルチサイト計器エンティティにおける変化は、コンピュータシステムのメモリ構造に相応の変化をもたらさない。本発明の別の実施形態によると、仮想マルチサイト計器エンティティは、複数の試験計器で概ね同時にプロシージャを実行するように構成される。
【００５３】
本発明の一態様によると、試験プロセスを実行するシステムが提供される。同システムは、試験システムと、通信ネットワークによって試験システムへ結合された少なくとも１つのクライアントコンピュータとを備え、ここでクライアントコンピュータを操作するユーザは、試験システムで複数の試験ファンクションを実行できる。本発明の一実施形態によると、システムはさらに、実行時に１つ以上の試験計器でプロシージャを実行する試験プログラムを備え、１つ以上の試験計器は、それぞれ１つ以上のドライバプログラムを有する。本発明の別の実施形態によると、システムはさらに、クライアントコンピュータから通信ネットワークを通じて１つ以上のリクエストを受け取るプロセスをさらに備える。本発明の別の実施形態によると、少なくとも１つのクライアントコンピュータは、試験システムにアクセスするためのユーザインターフェースコンポーネントを含む。本発明の別の実施形態によると、ユーザインターフェースコンポーネントは、少なくとも１つのクライアントコンピュータ上で実行するブラウザプログラムを用いて操作される。本発明の別の実施形態によると、試験システムはさらに、複数の試験計器でプロシージャを実行するように構成される仮想マルチサイト計器エンティティを備え、ここで仮想計器エンティティは、それぞれ１つ以上のドライバプログラムを通じて複数の試験計器にアクセスし、仮想マルチサイト計器エンティティは、試験プログラムに対し透過的に複数の試験計器でプロシージャを実行するように構成される。
【００５４】
本発明の一実施形態によると、試験システムはさらに、１つ以上の試験計器でプロシージャを実行するように構成される仮想計器エンティティを備え、ここで仮想計器エンティティは、それぞれ１つ以上のドライバプログラムを通じて１つ以上の試験計器にアクセスする。本発明の別の実施形態によると、ユーザインターフェースコンポーネントは、クライアントコンピュータを操作するユーザに基づき構成される。本発明の別の実施形態によると、試験システムは、複数のユーザインターフェースを蓄積するように構成され、且つユーザに対応するユーザインターフェース構成に基づき少なくとも１つのユーザインターフェースをユーザに提供するように構成される。本発明の別の実施形態によると、仮想計器エンティティは、１つ以上のファンクションを含む。本発明の別の実施形態によると、試験プログラムは、仮想計器の１つ以上のファンクションにアクセスすることにより１つ以上の試験計器にアクセスするように構成される。本発明の別の実施形態によると、試験プログラムは、専ら仮想計器を通じて１つ以上の計器にアクセスするようプログラムされる。本発明の別の実施形態によると、仮想計器エンティティは、１つ以上の試験ハードウェアに特有のプログラミングインターフェースから試験プログラムを分離する。本発明の別の実施形態によると、仮想計器は、仮想計器プログラミングインターフェースを含む。
【図面の簡単な説明】
【００５５】
添付の図面は一定の縮尺で描くことを意図するものではない。これらの図面で、様々な図に描かれた同じかほぼ同じコンポーネントは同様の数字で表示されている。明確を図るため、全ての図面で全てのコンポーネントに標示があるとは限らない。
【図１】従来型試験システムアーキテクチャ例のブロック図を示す。
【図２】別の従来型試験システムアーキテクチャ例のブロック図を示す。
【図３】本発明の一実施形態による試験システムアーキテクチャのブロック図を示す。
【図４】本発明の一実施形態による試験システムアーキテクチャのブロック図である。
【図５】本発明の別の実施形態による試験システムアーキテクチャのブロック図である。
【図６Ａ】本発明の別の実施形態による試験システムアーキテクチャのブロック図である。
【図６Ｂ】本発明の別の実施形態による試験システムアーキテクチャのブロック図である。
【図６Ｃ】本発明の別の実施形態による試験システムアーキテクチャのブロック図である。
【図６Ｄ】本発明の別の実施形態による試験システムアーキテクチャのブロック図である。
【図７】本発明の一実施形態による試験システムプラットフォームのブロック図である。
【図８】本発明の態様を実装するにあたって使用できるメモリ構造のブロック図である。
【図９Ａ】本発明の一実施形態による試験システムアーキテクチャのブロック図である。
【図９Ｂ】本発明の一実施形態によるメモリ構造のブロック図である。
【図９Ｃ】本発明の別の実施形態によるメモリ構造のブロック図である。
【図１０】本発明の別の実施形態によるメモリ構造のブロック図である。
【図１１】本発明の別の実施形態による試験システムアーキテクチャのブロック図である。
【図１２】本発明の様々な態様を実践できる汎用コンピュータシステムのブロック図である。
【図１３】本発明の別の実施形態による試験システム試験システムアーキテクチャのブロック図である。
【図１４Ａ】本発明の一実施形態による試験システムプロセス例の図である。
【図１４Ｂ】本発明の一実施形態による試験システムプロセス例の図である。
【図１５】本発明の一実施形態による警報処理ファンクション例のブロック図である。
【図１６】本発明の一実施形態による電力初期化ファンクション例のフロー図である。
【発明を実施するための形態】
【００５６】
詳細な説明
本発明の応用は、以降の説明に記された、または図面に描かれた、コンポーネントの構成および配置の詳細に限定されない。本発明は他の実施形態にも対応し、様々な方法で実践または実施できる。また、本明細書で使われている言葉遣いと用語は説明を目的とするものであって、制限するものとみなすべきでない。本明細書での「ｉｎｃｌｕｄｉｎｇ」、「ｃｏｍｐｒｉｓｉｎｇ」または「ｈａｖｉｎｇ」、「ｃｏｎｔａｉｎｉｎｇ」、「ｉｎｖｏｌｖｉｎｇ」、ならびにこれらの変化形の使用は、後ろに記された項目とその同等物、ならびに追加的項目を包含することを意図する。
【００５７】
ＡＴＥシステム等の試験システムで処理を実行するシステムおよび方法を提供する。本発明の一態様によると、従来のＡＴＥシステムの総費用が高くつく主な原因はソフトウェアとハードウェアとの緊密な結合にあると理解する。本発明の一態様によると、ＡＴＥシステムで処理を実行する改良方法が提供され、これによりソフトウェアの総費用は抑えられる。例えば、ＡＴＥシステムにおいて汎用のコンピュータシステム、プロセッサ、および／またはソフトウェアを実装し、かかるシステムの所有・維持費を抑えると有益である。一例においては、既製のハードウェアとソフトウェア（例えば汎用コンピュータシステム、商品オペレーティングシステム（例えばＷｉｎｄｏｗｓ（登録商標）  ＮＴ）、その他）を使って本発明の様々な態様を実施する。このためＡＴＥシステムの開発費は、専用に開発されたハードウェアとソフトウェアとを使用する特別に設計されたシステムの何分の１かの費用ですむ。したがって、かかるシステムの総開発費を抑える方法なら何であれ有益である。
【００５８】
図１は、従来型試験システムアーキテクチャ例のブロック図である。例えば従来の試験システム１００は一般的に、１つ以上の試験システムソフトウェア１０１部分と、対応する試験システムハードウェア１０２とを含む。例えば試験システムソフトウェアは、通常ならば専用のオペレーティングシステムであるオペレーティングシステムと、１つ以上の試験システムソフトウェアドライバ（例えば１０４Ａ−１０４Ｂ）と、１つ以上の試験対象デバイス１０６Ａ−１０６Ｂを試験するために開発された試験アプリケーションとを含む。自動試験システム１００の場合、試験システムソフトウェア１０１は、ドライバの通信相手にあたる計器（例えば計器１０５Ａ）に実装専用のソフトウェアドライバ（例えば１０４Ａ）を含む。このため、１つ以上のソフトウェアドライバと通信する試験システムソフトウェア１０１は、かかるドライバ（例えばドライバ１０４Ａ−１０４Ｂ）を通じて試験システムハードウェア１０２と通信するよう限定的にプログラムされる。
【００５９】
本発明の一態様によると、ドライバかこれに対応する計器が変更されると、その都度ドライバおよび／または計器を相応に変更しなければならないと理解する。試験システムソフトウェア１０１、例えばオペレーティングシステム、試験アプリケーション、その他のソフトウェアエンティティなどは、かかるドライバを通じて通信するよう限定的に記述されるから、ドライバかハードウェアに変更があると試験システムソフトウェア１０１の変更が余儀なくされる。このような結合のため、試験システム１００で変更または追加されたソフトウェアドライバおよび／または計器とともに試験システムソフトウェア１０１が作動することを改めて検証しなければならない。さらに、試験システム１００で作動するよう試験プログラムを記述するユーザ１０３は、変更された環境で自身の試験プログラムが作動するようにするため余分な手間をかけなければならない。
【００６０】
別の従来型試験システムアーキテクチャ例のブロック図を示す図２は、従来の試験プログラミング環境における問題をより詳しく説明する。例えば試験システム１００は、１つ以上の試験アプリケーション２０１Ａ−２０１Ｚから構成される試験システムソフトウェア１０１を含み、様々なバージョンは試験アプリケーションによって異なり、１種類以上のソフトウェアおよびハードウェアと連動する。同様に、特定の試験システムには１つ以上のドライバ（例えばドライバＡ  ２０２ＡとドライバＢ  ２０３Ａ）があり、それぞれ関連する１つ以上のバージョンを持つ（例えばドライバＡバージョン２０２Ａ−２０２ＺとドライバＢバージョン２０３Ａ−２０３Ｚ）。さらに複雑なことに、試験システムのオペレーティングシステムそのものにも１つ以上のバージョン２０４Ａ−２０４Ｚがあり、ドライバ、アプリケーション、あるいは他のエンティティ等、他の多数のソフトウェアエンティティと連動するよう構成される。
【００６１】
同様に、試験システムハードウェア１０２にも１つ以上の試験ハードウェアエンティテ
ィ（例えば試験ハードウェアＡ  ２０５Ａ、試験ハードウェアＢ  ２０６Ａ）があり、インターフェースや機能が異なる１つ以上のバージョン（例えば試験ハードウェアＡバージョン２０５Ａ−２０５Ｚ、試験ハードウェアＢバージョン２０６Ａ−２０６Ｚ）を持つ。本発明の一態様によると、これらのエンティティのいずれか１つが修正されると、通信やファンクションの実行に違いが生じ、試験システム１００全体が故障することがある。試験プログラムを決定的に実行する必要があるＡＴＥ環境において、そのような非決定性動作は望ましくない。
【００６２】
本発明の一態様によると、基礎となるドライバやハードウェア（例えば試験計器）からソフトウェアアプリケーションを分離する仮想計器を提供することにより、ドライバや計器における変更がオペレーティングシステム、試験アプリケーション、あるいはその他ソフトウェアエンティティなどを含む、上位層ソフトウェアのファンクションに影響することはない。
【００６３】
図３は、試験システムのエンティティを分離する、本発明の一実施形態による試験システムアーキテクチャのブロック図である。提供されるアーキテクチャ３００で、例えば試験システムアプリケーション、オペレーティングシステム、または他の何らかの種類のソフトウェアエンティティを含むソフトウェアアプリケーション３０１は、仮想計器３０２により、物理計器ドライバ３０３と物理計器３０４の詳細から切り離される。
【００６４】
仮想計器３０２は、例えば抽象層となってソフトウェアアプリケーション３０１層と物理計器ドライバ３０３層とを分離する。仮想計器３０２は、例えば抽象仮想計器インターフェース（図示せず）とファンクションと物理計器ドライバ３０３の中にあるデータとの間でマッピングを実行するコードを含む。
【００６５】
本発明の一実施形態によると、仮想計器によって提示されるインターフェースは基礎ハードウェアから独立した標準計器インターフェースである。代表的システムにおいては、ユーザが一般的に実行を望む機能の観点から仮想計器インターフェースを記述する（例えば試験対象デバイス（ＤＵＴ）のため波形生成）。通常、ハードウェアの具体的詳細にユーザが関心を寄せることはなく、ユーザは専ら予測可能な刺激を提供することと予測可能な結果を得ることに関心を寄せる。そこでユーザに、ハードウェアから独立しユーザの試験プログラムから通常の方法でアクセスできる機能的インターフェースを提示するインターフェースが提供される。このような仮想計器の規格化により、基礎となる物理計器ドライバと対応する計器の追加や差し替えがあっても、上位層ソフトウェアアプリケーション３０１の動作に支障をきたすことはない。
【００６６】
システムプラットフォームアーキテクチャ
本発明の様々な態様は、開発者、装置製造業者、試験装置会社、その他のユーザが様々な試験対象デバイス（ＤＵＴ）の試験に用いる試験プログラムをプログラムできる総合システムアーキテクチャの一部として実装できる。
【００６７】
図４に示す具体的アーキテクチャ４００では、プラットフォームソフトウェア４０１上で作動する１つ以上の試験プログラム４０５Ａ−４０５Ｚが１名以上のユーザによって開発される。具体的に、試験プログラム４０５Ａ−４０５Ｚは、仮想マルチサイト計器層４０４Ａ−４０４Ｚを通じて試験ハードウェアにアクセスするようプログラムされる。仮想マルチサイト計器については後ほど詳しく説明するが、１つ以上のハードウェアデバイスに対し仮想インターフェースを提供するという点では上述した仮想計器の働きに類似する。一実施形態によると、かかるインターフェースは、ＡＴＥシステムにおける試験ファンクションの実行にあたって、ハードウェアから独立したインターフェースを提示することができる。
【００６８】
一実施形態において、物理的ハードウェアに対するソフトウェアインターフェースは、本明細書で「物理計器」（ＰＩ）モジュールと呼ばれるものに実装される。それぞれの計器ハードウェアには、ハードウェアから提供される基礎的機能を実装する関連したＰＩモジュールが付随する。一実施形態によると、ユーザの試験プログラム（ＴＰ）はＰＩ層（４０３Ａ−４０３Ｚ）エンティティ（例えばＰＩモジュール）と直にやり取りしない。ユーザ試験プログラムから見た試験計器とのやり取りは、本明細書で後ほど詳述される「仮想マルチサイト計器」（ＶＭＩ）と呼ばれるものを通じて行われる。一実装において、ＶＭＩは１つ以上のＰＩを使って機能を実装し、１つ以上のＰＩが１つ以上の計器にアクセスする。
【００６９】
本発明の別の実施形態によると、本明細書で仮想マルチサイト計器（ＶＭＩ）と呼ばれるものが提供され、複数試験サイトの管理を促進する。従来の試験環境ではサイトを単独のエンティティとして管理し、特定の試験サイトを構成する場合は、そのサイトで使用する特定の試験ハードウェア向けに試験プログラムを開発することが分かっている。追加の試験を行うため（例えば試験能力の増大に対応するため）複数のサイトが必要となる場合は、追加の試験ハードウェア構成を購入し、追加のサイトに試験プログラムを投入する。
【００７０】
本発明の一態様によると、基礎ハードウェアの詳細は抽象層（例えば仮想計器層）によって試験プログラムから抽出されるから、試験プログラムは試験ハードウェアから独立して管理でき、複数のサイトに対する試験プログラムの運営は抽象層で管理できる。一実施形態において、仮想計器は複数の計器サイトへマップする能力を持つ。こうして、複数のサイトに対する試験プログラムの保守と運営にかかる時間は短縮する。
【００７１】
一例において、ＰＩは、本明細書で「システムＰＩ」と呼ぶ専用のＰＩを通じて試験システムリソースにアクセスできる。一実施形態によると、システムＰＩ層（例えば層４０２Ａ−４０２Ｚ）は、他のＰＩが試験システムリソース、例えばシステムメモリ、システムトリガ、その他リソースなどを、使用するためのインターフェースを提供する。別の実施形態において、システムＰＩは試験システム内の他の計器に通じる通信インターフェースを提供する。
【００７２】
実際には、例えば汎用コンピュータシステムの中でソフトウェアライブラリファンクション（例えばＷｉｎｄｏｗｓ（登録商標）  ＮＴオペレーティングシステムで周知のダイナミックリンクライブラリ（ＤＬＬ））としてＰＩを実装する。試験システムに存在するハードウェアに応じて適切なＰＩモジュールを適宜ロードできる。
【００７３】
一実装においては、それぞれのＰＩが一意な識別子によって一意に識別される。この一意な識別子は一例において、試験システム全体にわたって一意であって、特定のＰＩ実装を一意に識別する。このような識別方法は、例えば試験システム内の他のエンティティがＰＩと通信するにあたって便利である。
【００７４】
一実施形態によると、システム層（例えばシステムドライバとして実装）のインターフェースによりＶＭＩとＰＩをシステム層上で構築する。別の実装において、ＶＭＩ層はハードウェアから抽象層を提供し、これはＰＩとシステムドライバソフトウェアによってカプセル化される。別の実施形態において、システム層はシステム固有リソース（例えば較正計）のための試験プログラムに対しファンクションを公開することもできる。
【００７５】
別の実施形態において、試験プログラムはユーザに対しＶＭＩファンクションを仮想計器として公開し、試験プログラムは、ユーザが望む試験ソリューションの形でこれらのファンクションを影響する。インターフェースはアドオンリーというルールによって指導さ
れ、既存ファンクションの実行機能または性能は変化しない。また、一実装においてはそれぞれのモジュールが相手方のモジュールに対しバージョンチェックを行うことにより、モジュール間の十分なパフォーマンスを保証する。
【００７６】
かかるルールは、例えばモジュールの完全な前方−後方互換性を可能にする。つまりモジュールは個別にバージョン管理でき、どのバージョンでも互換的に機能できる。このため、例えば特定バージョンのＶＭＩにより設計された試験プログラムは、これの作成とコンパイルのときに使われたバージョン以上であればどのＰＩおよびシステムドライバ（同一種類のもの）バージョンでも使用できる。
【００７７】
別の実施形態によると、アーキテクチャ４００はプラットフォームソフトウェア４０１を含む。一実施形態においては、従来のコンピュータオペレーティングシステムから提供される機能をプラットフォームソフトウェア層の一部として抽象化する。後ほど詳述するとおり、一実施形態によると、このプラットフォーム層の抽象化により殆ど全てのオペレーティングシステム、例えば汎用オペレーティングシステムを、ＡＴＥテスタで使用できるようになる。プラットフォームソフトウェア層４０１は一実施形態において、ＡＴＥテスタの各種コンポーネント全体の作動と通信にあたって必要となる基礎的機能を提供する。一実施形態においては、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰまたはＷｉｎｄｏｗｓ（登録商標）  Ｖｉｓｔａオペレーティングシステムを基本オペレーティングシステムとして使用し、このオペレーティングシステムが各種ＡＴＥテスタコンポーネントに必要な基礎的ファンクションを取り仕切る。ただし、他のオペレーティングシステムも使用できることを理解されたい。
【００７８】
図５は、本発明の一実施形態による試験システムアーキテクチャ４００のより詳細な例を示す。説明したとおり、アーキテクチャ５００はプラットフォームソフトウェアエンティティ５０１を含み、これは試験システムプラットフォームの基礎的ファンクションを実行し、汎用オペレーティングシステムによって、例えばＷｉｎｄｏｗｓ（登録商標）  ＸＰまたはＷｉｎｄｏｗｓ（登録商標）  Ｖｉｓｔａオペレーティングシステムによって、支援される。本発明の一実施形態においては特定の試験計器の仮想表現を抽出し、仮想計器のファンクションと機能を試験システムの他の抽象層から分離する。上述したとおり、所定のプログラミングインターフェースで各層を分離し、ＰＩ、ＶＭＩ、その他のバージョンからバージョンにかけてインターフェースを維持し、さらにメモリにおけるファンクションの位置を維持することにより、プラットフォームで開発される試験プログラムは、プラットフォームの要素が修正される場合でも引き続き機能する。
【００７９】
本発明の別の実施形態によると、本明細書で仮想マルチサイト計器（ＶＭＩ）と呼ばれるものが提供されて、複数試験サイトの管理を促進する。従来の試験環境では単独のエンティティとしてサイトを管理し、特定の試験サイトを構成する場合は、そのサイトで使用する特定の試験ハードウェア向けに試験プログラムを開発することが分かっている。追加の試験を行うため（例えば試験能力の増大に対応するため）複数のサイトが必要になる場合は、追加の試験ハードウェア構成を購入し、追加のサイトに試験プログラムを投入する。本発明の一態様によると、基礎ハードウェアの詳細は抽象層（例えば仮想計器層）によって試験プログラムから抽出されるから、試験プログラムは試験ハードウェアから独立して管理でき、複数のサイトに対する試験プログラムの運営は抽象層で管理できる。一実施形態において、仮想計器は複数の計器サイトへマップする能力を持つ。こうして、複数のサイトに対する試験プログラムの保守と運営にかかる時間は短縮する。
【００８０】
アーキテクチャ５００では１つ以上の仮想マルチサイト計器（５０４Ａ、５０４Ｂ）を設定し、仮想マルチサイト計器（ＶＭＩ）にリソース（例えば１つ以上の計器またはサイト（５０５Ａ−５０５Ｃ））をマップできる。仮想計器と同様、仮想マルチサイト計器は
１つ以上の物理計器ドライバプログラム（例えばＰＩ  ５０３Ａ−５０３Ｃ）を通じて計器５０５Ａ−５０５Ｃと通信する。仮想計器と同様、仮想マルチサイト計器は特定のハードウェア実装に限定されるものではなく、機能を抽出し、特定ハードウェアのファンクションにマップする。
【００８１】
一実施形態によると、仮想計器５０４Ａ上での試験プログラムの実行により、例えば複数の計器サイト（計器５０５Ａおよび５０５Ｃ）で試験プログラムを実行できる。一実施形態によると、複数のサイトが単一のエンティティに抽出されるため、試験プログラムに修正があると複数のサイトで試験プログラムが更新される。このため、複数のサイトにおける試験プログラムの管理は簡略化する。
【００８２】
本発明の一実施形態によると、ＡＴＥテスタの機能は図４に示す一連の抽象層で抽象化される。１つの手法によると、試験プログラム層は、ＡＴＥテスタが（通常は試験プログラムを通じて）ユーザとやり取りするためのファンクションと機能を抽象化したものである。本発明の別の態様において、物理計器層は、ＡＴＥテスタの物理的ハードウェア計器との通信に必要なハードウェア実装詳細を抽象化したものである。本発明の別の実施形態においては、ＡＴＥテスタのファンクションが仮想計器層と、システム層と、プラットフォーム層に分解され、仮想計器層は、試験プログラム層から物理計器層にかけて試験リクエストをマップするための機能を抽象化したものであり、システム層は、物理計器層が該当する物理的ハードウェアと通信するための機能を抽象化したものであり、プラットフォーム層は、他の抽象層が作動する基盤を提供するためのファンクションと機能を抽象化したものである。図４に図示されていない別の実施形態においては、ＡＴＥテスタのファンクションがさらにインターフェース層に抽象化され、このインターフェース層は、各種抽象層間の通信を管理し規格化するための機能を抽象化したものである。図４に図示された層については後ほど詳しく説明する。
【００８３】
典型的な実施形態においては、ＡＴＥテスタのファンクションを表現する抽象層を参照しながらＡＴＥテスタを説明する。一実施形態においてはこの抽象層がシステムアーキテクチャの基礎をなす。一例において、試験プログラムは試験プログラム層の一部を形成する。別の実施形態において、ユーザは試験プログラム層を通じて試験結果をやり取りする。別の例において、ユーザは試験プログラム層を通じてＡＴＥテスタの特定の計器で実行する試験リクエストのスケジュールを組む。試験プログラム層に多数の試験プログラムを容易く組み込むことができることは、当業者によって十分に理解されよう。
【００８４】
プラットフォーム抽象層
別の実施形態においては、従来のコンピュータオペレーティングシステムから提供される機能をプラットフォームソフトウェア層の一部として抽象化する。一例においては、このプラットフォーム層の抽象化により殆ど全てのオペレーティングシステムをＡＴＥテスタで使用できるようになる。本発明の一態様によると、プラットフォーム層は、ＡＴＥテスタの各種コンポーネントが作動し通信するための基礎的機能を提供する。図４に示す例においては、プラットフォーム層がアーキテクチャの基礎を形成する。別の実施形態においては、オペレーティングシステムとしてＷｉｎｄｏｗｓ（登録商標）  ＸＰを使用し、プラットフォーム層の一部を形成する。この場合は、各種ＡＴＥテスタコンポーネントで使われる基礎的ファンクションがオペレーティングシステムによって管理される。
【００８５】
別の実施形態においては、Ｃ＋＋クラスとＣルーチンのライブラリがＡＴＥテスタの各種コンポーネントに対しオペレーティングシステムサービスを提供する。一実施形態によると、Ｃ＋＋クラスとＣルーチンのライブラリがプラットフォーム層の一部になることにより、殆ど全ての基本オペレーティングシステムをプラットフォーム層の一部として利用することができる。別の実施形態においては、ＡＴＥテスタで使用する基本機能がＷｉｎ
ｄｏｗｓ（登録商標）  ＸＰオペレーティングシステムとＩＮｔｉｍｅオペレーティングシステムから提供されるが、リアルタイムオペレーティングシステムならどれでも、あるいはリアルタイムエクステンションを備える汎用オペレーティングシステムならどれでも、使用できることは理解されよう。ＡＴＥテスタの各種コンポーネントにシステムサービスを提供するにあたって数多くのプログラミング言語と数多くのクラスライブラリを利用できること、そしてオペレーティングシステムサービスの提供にあたってＣ＋＋クラスとＣルーチンのライブラリにプラットフォーム層が限定されないことは、当業者によって理解されよう。
【００８６】
一例において、プラットフォーム層には決定性ファンクションを提供する能力がある。本発明の一実施形態においては、決定性となるよう強化された「既製」オペレーティングシステムを使って決定性ファンクションを提供する。例えば既製のオペレーティングシステムとしてＷｉｎｄｏｗｓ（登録商標）  ＸＰを使用し、リアルタイムエクステンションを使ってこれを決定性に仕立てる。別の実施形態においては、ＩＮｔｉｍｅオペレーティングシステムはリアルタイムエクステンションで動作を決定性に仕立てるが、どんなリアルタイムエクステンションでも使用できることは理解されよう。
【００８７】
典型的実施形態においては、プラットフォーム層がＡＴＥテスタの他の抽象層の動作を管理する。
【００８８】
仮想計器抽象層
本発明の一実施形態においては、ある特定の試験計器のファンクションを仮想表現に抽象化することにより、それらのファンクションを試験システムの他の抽象層から分離する。例えば、ある１つの計器のファンクションは仮想層で表現でき、他の抽象層は仮想を通じて計器の機能にアクセスできる。本発明の一態様によると、仮想との通信は規格化でき、特定のハードウェア実装詳細に縛られることはない。典型的な実施形態においては、仮想計器層がさらに、デバイスの試験に用いる計器一式の仮想に相当する仮想計器モジュール（「ＶＩモジュール」）に、抽象化される。本発明の一態様によると、１つの仮想計器モジュールでいくつもの物理的ハードウェアを表現できる。一実施形態においては、ＡＴＥテスタの物理的ハードウェアから提供される機能をＶＩモジュールで表現する。別の実施形態において、ユーザは試験プログラムを通じてＶＩモジュールとつながり、いくつもの物理的ハードウェアにそれぞれの試験ファンクションを実行させるためのファンクションとファンクションコールはＶＩモジュールによって管理される。
【００８９】
本発明の一態様によると、仮想計器層は特定のハードウェアに固有の実装詳細を収容しない。むしろ仮想計器層は一例において、特定のハードウェア実装詳細を収容する別の抽象層をコールするための機能を収容する。この例で説明する分離により、追加の計器をＶＩモジュールに組み込むことは容易い。別の実施形態において、新たなハードウェアがテスタに追加される場合は、特定のハードウェア実装詳細を収容する抽象層へマップする新たなファンクションコールの追加により、テスタで新たな機能を利用できるようになる。本発明の別の態様においては、新たな仮想計器モジュールを作成することによって新たな機能を追加する。新たな仮想計器モジュールの作成によって新たな機能が追加されても、ＡＴＥテスタの既存ファンクションに影響がおよばないことは理解されよう。仮想モジュールは、一実施形態において様々なバージョンのソフトウェアに相当し、ＡＴＥテスタでソフトウェアのバージョン管理を行い、古いバージョンと機能には影響しない。一実施形態においては、ダイナミックリンクライブラリとして仮想計器モジュールを実装する。別の実施形態においては、ランタイムシステムライブラリ（ＲＳＬ）として仮想計器モジュールを実装してよい。
物理計器抽象層
物理計器層は、一実施形態において、ＡＴＥ試験システムの特定のハードウェアに固有
の実装詳細を抽象化したものである。別の実施形態において、物理計器層はさらに物理計器モジュール（「ＰＩモジュール」）に抽象化される。一例において、実際のハードウェアにはその基礎的機能を実装するＰＩモジュールが付随する。ある特定のハードウェアから提供される機能はしばしばリソースと呼ばれる。本発明の原理に一致する一実施形態においては、ダイナミックリンクライブラリとしてＰＩモジュールを実装する。代わりに、ＲＳＬとしてＰＩモジュールを実装することもできる。
【００９０】
本発明の一態様によると、仮想計器層は、ＡＴＥテスタに設置された特定のハードウェアに固有の実装詳細にアクセスするため物理計器層をコールする。一実施形態においてはＶＩモジュールがＰＩモジュールをコールし、そのＰＩモジュールによって表現された特定のハードウェアに固有の詳細にアクセスすることによってこれを果たす。ＰＩモジュールは一例において、クロック同期信号をＡＴＥテスタに提供できる物理的ハードウェアの特定のハードウェアに固有の実装詳細を表現する。一実施形態においては、ＶＩモジュールがＰＩモジュールに対するファンクションコールを管理し、このファンクションコールを受けて物理的ハードウェアがクロック同期信号を生成する。
【００９１】
代表的図６Ａおよび図６Ｂを参照し、様々な抽象層間のやり取りを詳しく見ることができる。これらの図が示すとおり、試験プログラム層（ユーザアプリケーション／試験アプリケーション）は仮想計器層（仮想計器／ＶＩ）のＶＩモジュールまでリクエストを導き、ＶＩモジュールは物理計器層（物理計器／ＰＩ）のＰＩモジュールまでリクエストを導く。
【００９２】
図６Ａに示す別のアーキテクチャ例は、本発明の一実施形態による試験システムアーキテクチャの一例を示す。ユーザアプリケーション６０１は１つ以上の仮想計器（例えば仮想計器６０２Ａ−６０２Ｎ）にアクセスする。説明したとおり、仮想計器には物理計器（例えば物理計器６０３Ａ−６０３Ｎ）をいくらでも盛り込むことができる。このため、例えば個々の物理計器に分散するファンクションを試験システムで実装できる。
【００９３】
一実装において、ＶＭＩは実際のハードウェア実装について具体的情報を持たない。この情報は「物理計器モジュール」（ＰＩ、例えば物理計器６０３Ａ−６０３Ｎ）とともにある。一実装例によると、実際のハードウェアには、そのハードウェアの基礎的機能を一通り実装するＰＩモジュールが付随する。ユーザへ提示される機能を実装するため、ＶＭＩは１つ以上のＰＩから提供される機能を使用する。ＶＭＩは別の実施形態において、試験システム開発者および／または用途の要求に応じてある程度の情報を持つことがある。
【００９４】
一実施形態によると、ＰＩモジュールそのものはハードウェアと直接通信せず、「システムＰＩ」エンティティ（例えばシステムＰＩ  ６０４）を通じてハードウェアと通信する。システムＰＩ  ６０４は、試験システムハードウェアのテストヘッドにある計器とＰＩが通信するための機能を実装する。別の実施形態においては、ＶＭＩがシステムＰＩを通じてハードウェアと直接通信する。この実施形態ではＶＭＩが通信の内容をＰＩに知らせるから、ＰＩは必要に応じてハードウェアの状態に整合する。
【００９５】
図６Ａ〜図６Ｂが制限ではなく例証のため提示されていることを理解されたい。図６Ａには、後ほど詳述する物理計器層とシステム層とのやり取りの一例も盛り込まれている。
【００９６】
一実施形態において、図６Ａ〜図６Ｂから見てとれるように、１つのＶＩモジュールにいくつものＰＩモジュールを盛り込むことができ、１つのＶＩモジュールでＰＩモジュールを共有することすらできる。本発明の一態様によると、ハードウェアリソースをＰＩモジュールの形にモジュール化することによって、本発明は、このモデルに基づくテスタに柔軟性と順応性を提供する。本発明の別の態様によると、さらなる試験ニーズに応じて新
たなＰＩモジュールを容易にプログラムでき、新たなテスタの設計と製造にあたっては古いＰＩモジュールを活かすことができる。一実施形態においては、デバイスの試験に通常使われる機能を基本クラスのファンクションコールで表現する。一実施形態においては、これらの基本ファンクションコールをＰＩモジュールに組み込み、ＶＩモジュールを通じて試験プログラムで利用できるようにする。
【００９７】
システム抽象層
本発明の一態様によると、物理計器層は、該当する物理的ハードウェアと直接的には通信しない。ＰＩモジュールは、一実施形態において、リクエスト、ファンクションコール、および／またはデータを、システム層に引き渡す。本発明の一態様によると、システム層は、ＡＴＥテスタに設置された物理的ハードウェア（すなわち計器）とＰＩ層が通信するためのファンクションと機能を抽象化したものである。
【００９８】
図６Ｃの例から見てとれるように、物理計器層（ＰＩと図示）のＰＩモジュールはシステム層（システムＰＩと図示）と通信し、システム層はＡＴＥテスタの物理的ハードウェアにコールをマップする。一実施形態において、システム層はシステムＰＩモジュールを含む。本発明の別の態様によると、システム層は、他の抽象層と情報をやり取りしてプラットフォーム層に報告するための機能を抽象化したものである。
【００９９】
インターフェース
本発明の別の態様によると、ファンクションコールの引き渡しと、リクエストと、抽象層間のデータ転送とを管理する機能も抽象層で抽象化する。本発明の一実施形態において、インターフェース層は、他の抽象層との通信と他の抽象層間の通信を管理するための機能の抽象を含む。インターフェース層は一実施形態において、ファンクションコールの通信と、データの転送と、それぞれの抽象層の中にあるモジュール間で行われるその他の通信とを管理する。本発明の一態様によると、インターフェース層は、ＡＴＥテスタの各種モジュール間通信が所期形式で行われることを保証する。所期形式による通信を徹底することにより、各種モジュールが、特定のテスタに実装されるハードウェアにかかわりなく同じ方法で通信することは理解されよう。
【０１００】
仮想マシン
本発明の一態様によると、テスタシステムの様々なコンポーネントを１つ以上の仮想マシン上に実装すると有益であると理解する。かかる仮想マシンは当技術で公知であり、１つ以上のコンピュータシステムによってサポートされる仮想マシンの一部として実装できる。多くの様々な種類のプラットフォームが仮想化と仮想マシンをサポートしており、本発明は特定のプラットフォームに限定されない。図６Ｃには、仮想化を実装するその種のシステムアーキテクチャが例示されている。
【０１０１】
本発明の一態様によると、ユーザ層（例えばテスタインターフェース）の機能を物理層（例えばＶＭＩおよびＰＩ実装）から分離することにより、ユーザ層のコンポーネントに、あるいは特化されたハードウェアやソフトウェアを必要としない他の何らかの種類のコンポーネントに、汎化されたハードウェアとソフトウェアを使用できる。システムをこのように構築すれば、特化されたコンポーネントの代わりに既製のハードウェア（例えばＰＣ）とソフトウェア（例えばＯＳ）を使用できるから、テスタの製作費は大幅に抑えることができる。
【０１０２】
さらに、ユーザ層のコンポーネント（例えば試験プログラムを含む）を分離することにより、ユーザ層コンポーネントに支障をきたすことなくテスタプラットフォームＯＳと関連テスタコンポーネントを修正できることが分かる。つまり、もしもユーザ層に提示されるテスタインターフェースが保たれるなら、試験プログラムやその他のユーザ層コンポー
ネントは変更を経て変わりなく機能する。その結果、ソフトウェアやハードウェア等、システムコンポーネントが異なる試験システムで試験プログラム等のユーザ層コンポーネントを容易に移動できる。さらに、試験システムに関係する基礎ハードウェアおよびソフトウェアを変更する必要がある場合でも、かかるシステム上で開発された試験プログラムは、書き換えて試験する必要がないから、時間が経っても役に立つ。このため、複数の仮想マシンを用意し、少なくとも１つの仮想マシンはユーザレベルコンポーネントのために用意し、さらにテスタプラットフォームの少なくとも１コンポーネントを実行する別の仮想マシンを用意する。前述したとおり、通常のＡＴＥ実装では、試験システムと、試験プログラムと、関連コンポーネントの開発と保守が単一のエンティティとして行われ、変更がごく僅かでもあると再テストと検証が必要になる。その結果、通常のＡＴＥ実装は柔軟性に乏しく、保守に多大な労力を要し、結果的にさほど有用ではないことが分かる。
【０１０３】
バージョン管理
図７は、物理計器バージョンの変更を示す、本発明の一実施形態による試験システムプラットフォームのブロック図である。例えばユーザは、物理計器バージョン１．０例（項目７０２Ａ）との連動に適した試験アプリケーション７０１を開発するかもしれない。後ほど、先行バージョンとは異なる物理計器バージョンが利用可能になるかもしれない。例えば、後続バージョンのハードウェアで追加された追加機能が物理計器に備わるかもしれない。同様に、新バージョンの物理計器のため異なるインターフェースを含む物理計器ドライバが提供されるかもしれない。
【０１０４】
一例において、物理計器バージョン１．０（７０２Ａ）は試験対象デバイスに対しデフォルトで５ボルトの出力電圧を生成する。物理計器バージョンＺ（項目７０２Ｚ）では出力電圧のデフォルト値が異なる（例えば６４ボルト）。この変更のせいで、試験アプリケーション７０１は示されるように機能しなくなることがある。そこで本発明の一実施形態によると、物理計器のバージョンから独立し、ただし後続のハードウェアとドライバソフトウェアが利用可能になったときに追加の機能をサポートするように設計された、仮想計器エンティティを提供する。
【０１０５】
同様に、新バージョンのソフトウェアプラットフォームが利用可能になる場合は、１つ以上のバージョンの特定の物理計器でかかる新バージョンを利用できると有益である。事実、試験構成によっては、連動するよう構成されていない複数バージョンの物理計器と試験アプリケーションを組み合わせる必要がある。本発明の一実施形態によると、試験ハードウェアを関連ソフトウェアアプリケーション３０１から分離する仮想計器が提供される。
【０１０６】
ファンクションリファレンスの維持
本発明の一態様によると、ソフトウェアファンクションを提供する方法が提供され、この方法によりソフトウェアバージョンとハードウェアバージョンの互換性が実現する。一実施形態においては、バージョンからバージョンにかけて変化しない仮想計器のファンクションが提供される。より具体的に、仮想計器にファンクションが追加されても古いファンクションは保たれ、機能は所定のメモリ構造に追加される。ソフトウェアモジュールに機能が追加されても、メモリに予め存在するファンクションのリファレンスは変わらない。ファンクションのリファレンスが変わらないなら、さらなる機能がメモリ構造に追加されても既存の結び付きが断絶することはない。
【０１０７】
本発明の一実施形態によると、仮想計器のため仮想ファンクションテーブル（例えばＣ＋＋プログラミング言語で周知の仮想メソッドテーブル「ｖテーブル」）を保守する。一実施形態において、１バージョンの仮想計器ｖテーブルでは基本セットの機能がｖテーブルにおいて所定の位置を占める。後続バージョンの仮想計器テーブルでさらなるファンク
ションがｖテーブルに追加されても、基本セットの機能はｖテーブルで同じ位置を保つ。このように、さらなるファンクションが追加されても、ファンクションと、他のソフトウェアエンティティとファンクションとの結び付きは維持され、既存のプログラムが壊れることはない。例えば、基本ｖテーブルの後には追加機能を含む派生ｖテーブルが続く。後述するように、ファンクションリファレンスを維持するためｖテーブルを使用するが、ファンクションリファレンスが壊れないようにするため別の方法（例えばファンクションアービトレーション、トラッキングファンクション）を採ることもできることは理解されよう。
【０１０８】
図８は、本発明の様々な態様の実装に使えるｖテーブルメモリ構図のブロック図を示す。図示されているとおり、ｖテーブル８００は１つ以上のメソッド８０１Ａ−８０１Ｅを含み、これらは特定の計器ドライバに対応するファンクションに相当する。従来のシナリオである特定のファンクション（例えばメソッドＥ（８０１Ｅ））が修正されるとメソッドの挙動が変化し、そのファンクションを使って通信するハードウェアやソフトウェアは先行バージョンで当初予定されたとおりには実行しなくなる。例えば、メソッドＥのコールに誤りがあったり、メソッドＥのデフォルト値が異なったり、メソッドＥから返されるデータの形式が異なると、コールする側のファンクションが思いどおりに実行しなくなる。本発明の一態様によると、既存の結び付きを壊さずにソフトウェア機能を追加できるメモリ構造が提供される。
【０１０９】
バージョン管理アーキテクチャの例
図９Ａは、本発明の一実施形態による１アーキテクチャ９００を示す。具体的に、アプリケーション９０１は１つ以上の仮想計器を使用し、それぞれの仮想計器は、試験システムのソフトウェアモジュール間でソフトウェア互換性を促進する様々な機能群を備える。例えば仮想計器Ｖ１．０（項目９０２Ａ）が提供され、１つ以上の物理計器（ＰＩ）ドライバにマップされる。つまり、ある特定の仮想計器に１つ以上のバージョンの物理計器ドライバへのアクセスが許可される。
【０１１０】
従来、システムに計器が追加されると、その新しい計器に対応するドライバによって旧バージョンの計器ドライバが差し替えられる。本発明の一態様によると、バージョンが異なる計器を同じ試験システムの中で使用し、１つの仮想計器を通じてそれらの計器にアクセスする方法が提供される。
【０１１１】
一例においては、要素［ａ、ｂ、ｃ、ｄ、ｅ］からなるファンクションセットを持つ物理計器ドライバｖ．１．０（項目９０３Ａ）を通じて計器ｖ．１．０（項目９０４Ａ）と通信するよう仮想計器ｖ．１．０（項目９０２Ａ）を構成する。さらに仮想計器ｖ．１．０（項目９０２Ａ）は、物理計器ドライバｖ．ｙ（項目９０３Ｚ）を使用し、ファンクションセット［ａ、ｂ、ｃ、ｄ、ｅ’、ｆ、ｇ］を持つ計器ｖ．ｙ（項目９０４Ｚ）と通信できる。したがってアプリケーション９０１は、用途に応じてどのバージョンの計器およびこれに関連するドライバでも混乱なく使用できる。
【０１１２】
図９Ｂは、本発明の一実施形態によるメモリ構造のブロック図を示す。本発明の一態様に従って説明したとおり、以前のファンクションから修正された１つ以上のファンクションを含む追加のハードウェアを導入できると、あるいは近々導入されるハードウェアやソフトウェアの追加機能を利用できると、有益である。図９Ｂに見られるとおり、物理計器バージョンｖ．１．０に対応するｖテーブル９０１は１つ以上のファンクション［ａ、ｂ、ｃ、ｄ、ｅ］を含む。後ほど後続バージョンの物理計器が利用可能になり、これに対応するｖテーブル９１２はファンクションセット［ａ、ｂ、ｃ、ｄ、ｅ’、ｆ、ｇ］を含む。
【０１１３】
本発明の一態様によると、ある特定のファンクションをコールするソフトウェアが同じファンクションを同じ場所で見つけられるようにするため、物理計器に対応するｖテーブルの後続バージョンでは旧バージョンと同じファンクションリファレンスを維持することを含む。つまり、例えばファンクションＡ（項目９１３Ａ）は次のバージョンのｖテーブルのファンクションＡにマップされ、同じメモリ位置に置かれる。さらに、ある特定のファンクションが後続バージョンで修正される別の例では、既存のファンクション（例えばファンクションＥ（項目９１４Ａ））が後続バージョンのｖテーブルで同じメモリ位置に保たれる。こうして、新バージョンの物理計器をシステムに追加しても、そのバージョンにアクセスする既存のソフトウェアとハードウェアに支障はない。
【０１１４】
本発明の一態様によると、修正および／または追加機能はｖテーブルの後続部分に付け足されるから、古いアプリケーションと新バージョンの物理計器との結び付きは保たれる。一実施形態によると、これらの修正または追加ファンクションは前のバージョンの機能の後ろに付け加えられる。例えば図９Ｂに見られるとおり、修正ファンクション９１５  ｅ’は当初のファンクション９１４Ｂ  ｅの後ろに付け加えられる。さらに図９Ｂに見られるとおり、さらなるファンクションｆおよびｇは追加ファンクション９１６であり、これらはａからｅまでの基本ファンクションの後ろに付け加えることができる。このように、機能の変更や追加があってもｖテーブルの中に予め存在するリファレンスが混乱することはない。このため、古いアプリケーションと新バージョンの物理計器との間にある既存の結び付きが壊れることはない。
【０１１５】
さらに、上述した規約に準拠することにより、後続バージョンのＰＩ  ｖテーブルを使って同一バージョンの特定の計器ハードウェアや旧バージョンの特定の計器ハードウェアにアクセスできることを理解されたい。
【０１１６】
図１０は本発明の別の実施形態によるメモリ構造のブロック図であり、上述したプログラムと規約による後方互換性の維持を示す。具体的に、バージョン２．０のＰＩ  ｖテーブル（項目１００１）は、セット［ａ、ｂ、ｃ、ｄ、ｅ、ｅ’、ｆ、ｇ］を含むいくつかのメソッドを含む。後続バージョンのｖテーブルは旧バージョンＰＩの機能をすべて含み、ＰＩ  ｖテーブルの中での位置は保たれるから、後続バージョンのＰＩは、現行バージョンとそれ以前のバージョンの計器ハードウェアと通信できる。例えば、計器バージョン１．０（項目１００２）と計器バージョン２．０（項目１００３）とによって使用されるメソッドａは同じであり、バージョン２．０  ＰＩ（項目１００１）と旧バージョンの計器とで後方互換性は維持される。
【０１１７】
一実施形態によると、後続バージョンの計器（例えば計器バージョン２．０（項目１００３））において新たなメソッドが追加される場合に、その追加機能は新バージョンのｖテーブルの末尾に付け加えられる。したがって図１０に見られる例で、設定済みのメソッドｅは計器バージョン１．０（項目１００２）にマップし、新バージョンのＰＩ  ｖテーブルとの通信は断絶せず、修正メソッドｅ’は引き続き計器バージョン２．０（項目１００３）との通信に用いることができる。ＶＭＩがコールする対象（例えば、コールしようとするＰＩのバージョン（例えば、抽象クラスで識別されるバージョン番号））を把握している限り、要素間の結び付きは壊れない。
【０１１８】
そのような後方互換性を果たすには、例えば抽象クラスを用意し、修正または追加機能を含む後続クラスでこれを継承する。こうして、ｖテーブルは、基本データ構造と関連メソッドがｖテーブルで同じファンクション位置を占めるよう構成される。
【０１１９】
要するに、ソフトウェアの相継ぐ修正のたびに旧バージョンｖテーブルの構造を維持する標準ｖテーブル構造を使用する。構造が維持されるため、標準ｖテーブル構造を使用す
るアプリケーションやその他のプログラムは、新しいメソッドと古いメソッドにアクセスできるほか、新バージョンのハードウェアや旧バージョンのハードウェアにアクセスできる。ただしファンクションリファレンスを維持するにあたってこれとは別の方法を採ることもできること、そしてｖテーブルが必須でないことを理解されたい。
【０１２０】
同様に、新しい機能を活用するため仮想計器を修正する場合でも、同じプログラミングルールを使用し、旧バージョンのソフトウェア（およびハードウェア）がその仮想計器バージョンと通信できるようにする。例えば仮想計器バージョンＸ（項目９０２Ｚ）を導入する場合、その仮想計器バージョンＸは旧バージョンと同じｖテーブル構造を維持するほか、追加の機能を仮想計器の中に含む。様々なバージョンの仮想計器で提供される所定のファンクションと様々なバージョンの物理インターフェースドライバとの間には前方および後方互換性が成立する。
【０１２１】
図９Ｃに詳しく示すとおり、ＶＩバージョン１．０  ｖテーブル（項目９２１）は様々なバージョンの物理インターフェースドライバによって提供される所定のファンクションにアクセスする。ＶＩで作成される特定のファンクションは、ＶＩの上位層ファンクションを実行する１つ以上のファンクションをＰＩでコールする。図示されたとおり、ファンクションＡ−Ｅ（項目９２５Ａ−９２５Ｅ）は、ＰＩバージョン１．０（項目９２２）かＰＩバージョン２．０（項目９２４）のファンクションａ−ｅを使用する。このようにｖテーブル構造の中ではファンクションリファレンスが維持されるため、物理計器ドライバは、仮想計器のメソッドに適合するものに差し替えることができる。ＶＩとＰＩのファンクションには１対１のマッピングが見られるが、ファンクションにはこれとは別のコールパターンもあり、図示されたマッピングが本発明の様々な態様を例証する一例に過ぎないことを理解されたい。
【０１２２】
仮想計器に対応する後続バージョンのｖテーブルが、先行バージョンの物理計器ドライバと後続バージョンの物理計器ドライバの両方に適合することは説明できる。例えば図９Ｃに見られるとおり、仮想計器のｖテーブルには修正メソッドＥ’（項目９２６Ａ）が追加されており、これはバージョン２．０の物理計器ドライバ（項目９２４）のｅ’ファンクションに対応する。例えば、後続バージョンの物理計器ドライバにおける追加機能を活用するため、新バージョンのＶＩを提供できる。
【０１２３】
さらに、物理計器ドライバに対する変更とほぼ同様、修正および／または追加機能はｖテーブル構造の末尾に付け加えられるため、当初の機能は修正されない。このため、旧バージョンの物理計器ドライバ（例えばＰＩバージョン１．０）は後続バージョンのＶＩ（例えばバージョン２．０）と連動できる。つまり、後続バージョンのＶＩは先行バージョンのＰＩと通信できる。こうして、ＡＴＥシステムの中のソフトウェアエンティティ間で前方互換性と後方互換性の両方が維持される。
【０１２４】
プログラミングの例
本発明の一実施形態によると、計器の独立性は試験システムアーキテクチャの重要要素である。これにより各計器の単独改良または修正が可能となり、組織的な一斉アップグレードは必要はない。この独立性を維持するため、試験システムはシステムＰＩを通じてシステムドライバファンクションを提供することで同期サブシステムとトリガサブシステムを管理する。この方式でシステムＰＩは計器間の媒介役として働く。システムＰＩは、信号ラインの使用とアベイラビリティを管理し、トリガ接続およびモードを設定し、遅延情報を保持し、その他のハウスキーピング機能を果たす。
【０１２５】
ユーザプログラムまたはアプリケーション（例えば９０１）からスタートし、このユーザプログラムは仮想マルチサイト計器（ＶＭＩ）のファンクションをコールし、仮想マル
チサイト計器のファンクションは計器物理ドライバ（またはＰＩ）のファンクションをコールする。作成されたＰＩは、システムレベルファンクションと、較正と、システムリソース（例えばメモリ、トリガサブシステム、その他）の使用のため、システムＰＩにアクセスできる。これより、図１０に示す試験アーキテクチャを通じてハードウェアにアクセスするユーザプログラムの実例を説明する。
【０１２６】
パターンの実行時にパルスを生成する「Ｃｏｎｔｒｏｌ」と呼ばれるＶＭＩにマップされたデジタル計器リソースを検討する。このデジタル計器は「Ｖｃｃ」と呼ばれるＶＭＩにマップされたＶ／Ｉリソースに接続され、これはパターンの中のその地点でＩｄｄ電流を測定する測定用ストロボとして計器を使用する。試験コードは次のような体裁をとる。．
．
．
Ｃｏｎｔｒｏｌ−＞ＣｏｎｎｅｃｔＴｒｉｇｇｅｒ（９，’Ｉｄｄｍｅａｓ’）；
Ｖｃｃ−＞ＳｅｔＭｏｄｅＩＭｅａｓｕｒｅ（１００ｍａ）；
Ｖｃｃ−＞ＣｏｎｎｅｃｔＭｅａｓＳｔｒｏｂｅ（‘Ｉｄｄｍｅａｓ’）；
Ｃｏｎｔｒｏｌ−＞ＲｕｎＰａｔｔｅｒｎ（‘ｍｙｐａｔ’）；
Ｗａｉｔ（１００ｍｓ）；
Ｖｃｃ−＞ＧｅｔＭｅａｓ（＆Ｉｄｄ）；
．
．
．
最初の行Ｃｏｎｔｒｏｌ−＞ＣｏｎｎｅｃｔＴｒｉｇｇｅｒ（９，’Ｉｄｄｍｅａｓ’）；で、まずはＶＭＩが自身にマップされたリソース（ＰＩ内のリソース）に対しコールを行い、Ｐｉは‘Ｉｄｄｍｅａｓ［ｓｉｔｅ］’という各サイトにつき信号ラインに至る固有のトリガラインの接続をシステムＰＩ経由でリクエストする。十分な信号ラインが使用可能なら、信号ラインを（名前により）確保し、接続カウンタを１に設定し、信号ラインが既に存在するなら接続カウンタが増加する。使用できる十分な信号ラインがない場合は警報を発することができる。信号ラインの確保に成功したら、ＶＭＩはパターンビット９を信号‘Ｉｄｄｍｅａｓ［ｓｉｔｅ］’へ接続することを各サイトの計器ＰＩに指示する。
【０１２７】
各ＰＩは使用可能なトリガラインをチェックし、ボード上で接続を果たす。次にＰＩは、選択されたトリガラインを‘Ｉｄｄｍｅａｓ［ｓｉｔｅ］’という信号に接続することをシステムＰＩにリクエストする。計器ＰＩは、その場所と、選択されたトリガラインと、接続の方向と（この場合はＡｓｙｎｃｈｒｏｎｏｕｓ  Ｄｉｖｅ）、接続する信号とに関する情報をシステムＰＩに送ることによってこれを果たす。システムＰＩはクロスポイントファンクションでしかるべき接続を設定し、選択されたトリガラインのモードを設定する。これでパターンビット９は‘Ｉｄｄｍｅａｓ［ｓｉｔｅ］’という信号ラインを駆動する。
【０１２８】
２番目の行では、ＶｃｃというＶＭＩが１００ｍａ範囲の電流測定モードに設定される。３番目の行で、ＶｃｃというＶＭＩは測定用ストロボをトリガモードに設定し、且つストロボを受信モードで信号‘Ｉｄｄｍｅａｓ’という信号へ接続する指示を受ける。これは例えばＶｃｃ  ＶＭＩが信号ラインの確保をシステムＰＩに要請することよって果たすこともできるが、信号ラインは既に確保されているから、接続カウンタが増加するだけでよい。そしてＶｃｃ  ＶＭＩは個々の計器ＰＩに接続を要請する。
【０１２９】
ＶＭＩ計器はボード上で使用可能なトリガラインへストロボを接続し、選択されたトリガラインを非同期受信モードで‘Ｉｄｄｍｅａｓ’へ接続することをシステムＰＩにリク
エストする。
【０１３０】
次にパターンを実行し、測定値をボードに蓄積する。この後に遅延を挟んで測定値を引き出す。接続は永続し、以降の試験で使用できるため、接続が再び必要となる場合は接続を再度プログラムする必要はない。以降の試験で使用できる十分な信号ラインがない状況が発生することもある。この場合は、Ｄｉｓｃｏｎｎｅｃｔファンクションを使って必要でなくなった信号ラインを解放できる。接続カウントはシステムＰＩによって管理され、このカウントがゼロならＶＭＩからの切断ファンクションコールが受け付けられる。この例で‘Ｉｄｄｍｅａｓ’を解放するには以下の行を追加する。
Ｃｏｎｔｒｏｌ−＞ＤｉｓｃｏｎｎｅｃｔＴｒｉｇｇｅｒ（９，’Ｉｄｄｍｅａｓ’）；Ｖｃｃ−＞ＤｉｓｃｏｎｎｅｃｔＭｅａｓＳｔｒｏｂｅ（‘Ｉｄｄｍｅａｓ’）；
上記の１番目の行で、デジタルＶＭＩ「Ｃｏｎｔｒｏｌ」は計器ＰＩに切断を指示し、ＰＩはシステムＰＩから切断をリクエストし、次にＣｏｎｔｒｏｌ  ＶＭＩは‘Ｉｄｄｍｅａｓ’という信号の切断をリクエストする。システムＰＩは接続カウンタを減少させるが、接続は依然として存在するから信号ラインは解放しない。上記の２番目の行で、Ｖｃｃ  ＶＭＩも同様に計器ＰＩに切断を指示し、システムＰＩから切断をリクエストする。この場合、システムＰＩは接続カウンタをゼロまで減らし、信号ラインを後ほど使用するため解放する。
【０１３１】
一実施形態によると、システムＰＩはリソース（信号ライン）を堅固に管理する。例えば、プログラムをロードするときと試験を開始するときには全ての信号ラインを解放できる。また、接続状態はツールでコントロールでき、ユーザはブレイクポイント等で終了できるから、信号ラインが誤ってロックアウトすることはない。
【０１３２】
この例の使用により、２計器間で基礎的接続方式が遂行される。計器ファンクションは、接続先にあたる計器におけるファンクションの実装にまったく左右されない。この方式には、接続にあたって２行のユーザコードが必要になるという欠点がある。ただし、このアーキテクチャなら多数の計器が１つのソースに接続することができる。
【０１３３】
図１１は、本発明の様々な態様の実装に使える試験システムアーキテクチャの別の例を示す。試験アプリケーションで高度な再現性を達成する上で決定性動作は基本条件の１つである。試験アプリケーションで個々の試験の実行時間にかかわる変動を抑えれば、多数のデバイスで行われる測定はより正確で一貫性のあるものになるだろう。ＡＴＥ業界ではこれまで、リアルタイムオペレーティングシステムを実行する専用プロセッサを使って個々の試験を実行することでこの問題を解決してきた。この手法には、決定性動作の達成にあたって非常に高いコストがかかるという欠点がある。
【０１３４】
これは通常、試験環境に関係する全てのタスク（例えばユーザインターフェース、データ記録、試験実行、その他）をただ１つのプロセッサで制御する低コストの試験システムで問題となる。さらに厄介なことに、低コストプラットフォームでリアルタイムオペレーティングシステム（ＲＴＯＳ）を利用できる見込みは比較的低くい上、そのオペレーティングシステムは扱いやすくて「見栄えの良い」ユーザインターフェースをユーザに提供するようにはできていない。通常、これらのＲＴＯＳから提供されるインターフェースはテキスト方式であり、一般ユーザにとっては非常に暗号めいたコマンドに基づくものである。
【０１３５】
図１１はリアルタイムコンポーネントと非リアルタイムコンポーネントの両方を含むアーキテクチャの例を示す。例えばこのアーキテクチャはグラフィカルユーザインターフェース１１０１を含み、ユーザはこれを使って試験プログラムを実行し、管理する。さらにアーキテクチャは、試験対象デバイス（ＤＵＴ）から引き出された試験結果を蓄積するデ
ータ記録プロセス１１０２を含む。さらにシステムは、実行される試験プロシージャに関係するフロー制御を行う非リアルタイムファンクション１１０３を含む。さらにアーキテクチャは、試験に関係するいくつかの非リアルタイムタスク１１０４、例えば報告、警報、その他のタスクを、実行する。
【０１３６】
本発明の一実施形態においては、リアルタイムコンポーネントと非リアルタイムコンポーネントを別々の仮想マシン上で実装できる。当技術で周知のとおり、これらの仮想マシンは、例えば同じプロセッサで実行されることもあれば、異なるプロセッサで実行されることもある。これらの仮想マシンは仮想マシン間通信を行いながら様々な分散機能を実装する。一態様によると、非リアルタイムコンポーネントを単独のシステムエンティティ（例えば単独の仮想マシン）で実装すれば、既製のハードウェアとソフトウェアを使ってかかる非リアルタイムコンポーネントを実装できるから、システムのコストを抑えることができる。
【０１３７】
さらにアーキテクチャは、１つ以上のＤＵＴの試験に関係するファンクションを実行するリアルタイムプロセスを提供する。例えば、１つ以上のＤＵＴに対する試験ファンクションの実行を取り仕切る試験実行制御コンポーネント１１０６を提供できる。このシステムでは予め１つ以上の仮想マルチサイト計器（例えばＶＭＩ  １１０８Ａ−１１０８Ｃ）を設定しておき、これを使って、ユーザから提供される１つ以上の試験プログラムを実装する。アーキテクチャはまた、試験プロシージャを支援するその他補助リアルタイムタスク１１０７を含む。かかるタスクは、例えばシグナリングをはじめとする他の時間に左右されるタスクを含む。
【０１３８】
リアルタイムプロセスと非リアルタイムプロセスとの通信を促進するため、ＯＳ間通信エリア１１０５（個別の仮想マシンを使用する場合は仮想マシン間通信エリア）を設け、リアルタイムタスクが非リアルタイム領域のリソースと通信しこれにアクセスできるようにする。
【０１３９】
Ｗｉｎｄｏｗｓ（登録商標）  ＸＰオペレーティングシステムは周知のグラフィカルユーザインターフェースを具備するが、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰオペレーティングシステムはリアルタイムオペレーティングシステムではない。これは基本的に、ある特定のオペレーティングシステムリクエストが一定の時間内に処理されることをＷｉｎｄｏｗｓ（登録商標）  ＸＰオペレーティングシステムで保証できないことを、あるいはオペレーティングシステムのもとで実行するタスクが所定の期間内に実行する保証がないことを、意味する。一実施形態によると、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰオペレーティングシステムを修正することで、このオペレーティングシステムで（あるいは他の何らかのオペレーティングシステムで）リアルタイム能力を提供できるようにする。
【０１４０】
本発明の一実施形態によると、Ｔｅｎａｓｙｓ社のリアルタイムエクステンション（ＩＮｔｉｍｅエクステンション製品）を使用するが、これとは種類が異なるエクステンションを、または他の何らかのリアルタイムオペレーティングシステム（ＲＴＯＳ）を、使用できることを理解されたい。Ｔｅｎａｓｙｓが提供するソリューションは、２つの全く異なるオペレーティングシステムを１つのプロセッサで実行しながら２つのＯＳ間の通信を可能にする。Ｔｅｎａｓｙｓの技術なら、両方のオペレーティングシステムが干渉を起こさずｘ８６プラットフォームで実行できる。この技術は、一方の環境における不具合（壊滅的不具合をも含む）によって他方の環境に副作用が生じないことをも保証する。これは非常に高度な信頼性を実現する。
【０１４１】
ＩＮｔｉｍｅ製品から提供されるリアルタイム環境では、Ｗｉｎｄｏｗｓ（登録商標）
ＮＴオペレーティングシステムそのものが優先順位の低いタスクとなる。リアルタイム
タスクはどれもＷｉｎｄｏｗｓ（登録商標）  ＮＴオペレーティングシステムより優先するため、Ｗｉｎｄｏｗｓ（登録商標）環境における活動にかかわりなく安定した実行時間を保証できる。試験システムアーキテクチャは、一実施形態によると、時間が重視されるタスクが実行するリアルタイム環境と、優先順位が比較的低いタスクが実行する非リアルタイム環境とに依存する。これらのオペレーティングシステム環境は単一のプロセッサシステムを共用し、必要に応じて互いに通信する。
【０１４２】
本発明の一実施形態によると、参照により開示内容を本明細書に援用する２００５年９月２日に提出された米国特許出願第１１／２１８，９１５号、表題「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＰＥＲＦＯＲＭＩＮＧ  ＤＥＴＥＲＭＩＮＩＳＴＩＣ  ＰＲＯＣＥＳＳＩＮＧ（決定性処理を実行するシステムおよび方法）」で説明されているとおり、決定性処理を実行するように試験アーキテクチャを構成する。ただし、他のオペレーティングシステムをリアルタイム能力と併せて使用できること、そして本発明が特定の種類のオペレーティングシステムに限定されないことを理解されたい。
【０１４３】
汎用コンピュータシステム
本発明の様々な実施形態は１つ以上のコンピュータシステムで実装できる。これらのコンピュータシステムは、例えばＩｎｔｅｌ  ＰＥＮＴＩＵＭ（登録商標）タイププロセッサ、Ｍｏｔｏｒｏｌａ  ＰｏｗｅｒＰＣプロセッサ、ＡＭＤ  ＡｔｈｌｏｎまたはＴｕｒｉｏｎプロセッサ、Ｓｕｎ  ＵｌｔｒａＳＰＡＲＣプロセッサ、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ  ＰＡ−ＲＩＳＣプロセッサ、あるいは他の何らかのプロセッサに基づくものなど、汎用コンピュータシステムであってよい。本発明の様々な実施形態による処理の実行にあたって、どんな種類のコンピュータシステムであれ１つ以上使用できることを理解されたい。さらに、システムは単一のコンピュータ上に位置することもあれば、通信ネットワークによって接続された複数のコンピュータに分散することもある。
【０１４４】
本発明の一実施形態による汎用コンピュータシステムは既述のファンクションのいずれかを実行するように構成され、そのファンクションは、これに限定されないが試験プログラムに関連する処理の実行を含む。システムは他のファンクションでも実行できること、そして本発明が特定のファンクションまたはファンクション一式を具備することに限定されないことを理解されたい。
【０１４５】
図１２は、本発明の様々な態様を実践できる汎用コンピュータおよびネットワークシステムのブロック図である。本発明の様々な態様は、例えば図１２に見られる汎用コンピュータシステム１２０１を含む１つ以上のコンピュータシステムで実行する特化ソフトウェアとして実装できる。コンピュータシステム１２０１は、１つ以上のメモリデバイス１２０５、例えばディスクドライブ、メモリ、またはデータを蓄積するその他のデバイスなどへ、接続するプロセッサ１２０４を含む。メモリ１２０５は通常、コンピュータシステム１２０１の作動中にプログラムとデータを蓄積するために用いられる。コンピュータシステム１２０１のコンポーネントはネットワーク１２１０等の相互接続機構によって結合され、これは１つ以上のバス（例えば同一マシンに内蔵されたコンポーネント間のバス）および／またはネットワーク（例えば別個のマシンに存在するコンポーネント間のネットワーク）を含む。この相互接続機構により、システム１２０１のシステムコンポーネント間で通信（例えばデータ、命令）のやり取りが可能になる。
【０１４６】
コンピュータシステム１２０１はまた、１つ以上の入力／出力（Ｉ／Ｏ）デバイス１２０６、例えばキーボード、マウス、トラックボール、マイクロフォン、タッチスクリーン、印刷デバイス、表示画面、スピーカなどを含む。加えてコンピュータシステム１２０１は、コンピュータシステム１２０１を通信ネットワーク（ネットワーク１２１０に追加されるネットワーク、またはネットワーク１２１０に代わるネットワーク）に接続する１つ
以上のインターフェース（例えばネットワーク通信デバイス１２０８）を含む。
【０１４７】
ストレージシステム１２０９は通常、コンピュータによる読み書きが可能な不揮発性記録媒体を含み、プロセッサによるプログラムの実行を決定する信号や、プログラムによって処理される情報をそこに蓄積する。この媒体は、例えばディスクまたはフラッシュメモリであってよい。プロセッサは通常、作動中に不揮発性記録媒体から、プロセッサが同媒体より速く情報にアクセスできる別のメモリに、データを読み込む。このメモリは通常、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）やスタティックメモリ（ＳＲＡＭ）等の揮発性ランダムアクセスメモリである。メモリは、図示されたストレージシステム１２０９にあってよく、あるいはメモリシステム１０５にあってよい。プロセッサ１０４は通常、集積回路メモリ１０４の中でデータを操作し、処理が完了した後にはストレージ１２０９と連係する媒体へデータをコピーする。媒体と集積回路メモリ素子との間のデータ移動の管理については様々なメカニズムが知られており、本発明はそれらに限定されない。本発明は特定のメモリシステムまたはストレージシステムに限定されない。
【０１４８】
コンピュータシステムは、専用にプログラムされた専用のハードウェアを、例えば特定用途向け集積回路（ＡＳＩＣ）を、含むことがある。本発明の態様は、ソフトウェア、ハードウェアまたはファームウェア、またはこれらの組み合わせで、実装できる。さらに、かかる方法、動作、システム、システム要素、およびこれらのコンポーネントは、上述したコンピュータシステムの一部として実装されることもあれば、単独のコンポーネントとして実装されることもある。
【０１４９】
本発明の様々な態様を実践できる１種類のコンピュータシステムとしてコンピュータシステム１２０１が例示されているが、本発明の態様が図１２に示すコンピュータシステム上での実装に限定されないことを理解されたい。本発明の様々な態様は、図１２に示すものとは異なるアーキテクチャまたはコンポーネントを具備する１つ以上のコンピュータで実践できる。
【０１５０】
コンピュータシステム１２０１は、高水準コンピュータプログラミング言語を使ってプログラムできる汎用コンピュータシステムであってよい。コンピュータシステム１２０１はまた、専用にプログラムされた専用ハードウェアを使って実装できる。コンピュータシステム１２０１におけるプロセッサ１２０４は通常、Ｉｎｔｅｌ  Ｃｏｒｐｏｒａｔｉｏｎから入手できる周知のＰｅｎｔｉｕｍ（登録商標）クラスプロセッサ等、市販のプロセッサである。その他多数のプロセッサを使用できる。
【０１５１】
通常はかかるプロセッサがオペレーティングシステムを実行し、このオペレーティングシステムは数ある中で、例えばＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎから入手できるＷｉｎｄｏｗｓ（登録商標）方式のオペレーティングシステム（例えばＷｉｎｄｏｗｓ（登録商標）  ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）  ２０００（Ｗｉｎｄｏｗｓ（登録商標）  ＭＥ）、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰ、Ｗｉｎｄｏｗｓ（登録商標）  Ｖｉｓｔａオペレーティングシステム）、Ａｐｐｌｅ  Ｃｏｍｐｕｔｅｒから入手できるＭＡＣ  ＯＳ  Ｓｙｓｔｅｍ  Ｘオペレーティングシステム、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓから入手できるＳｏｌａｒｉｓオペレーティングシステム、様々な供給元から入手できるＵＮＩＸ（登録商標）オペレーティングシステム、上述したＩＮｔｉｍｅおよびＴｅｎａｓｙｓであってよい。その他多数のオペレーティングシステムを使用でき、本発明は、様々な実施形態に従いリアルタイムファンクションや非リアルタイムファンクションを実行するにあたり、特定のオペレーティングシステムまたはオペレーティングシステムエクステンションに限定されない。
【０１５２】
プロセッサとオペレーティングシステムによってコンピュータプラットフォームが決ま
り、このコンピュータプラットフォームに向けて高水準プログラミング言語でアプリケーションプログラムを記述する。１つ以上の請求項で指定される場合を除き、特定のコンピュータシステムプラットフォーム、プロセッサ、オペレーティングシステム、またなネットワークに本発明が限定されないことを理解されたい。また、本発明が特定のプログラミング言語またはコンピュータシステムに限定されないことは当業者にとって明白であろう。また、他の適切なプログラミング言語と他の適切なコンピュータシステムも使用できることを理解されたい。
【０１５３】
コンピュータシステムの１つ以上の部分は、通信ネットワークに結合された１つ以上のコンピュータシステムにわたって分散できる。これらのコンピュータシステムもまた汎用コンピュータシステムであってよい。例えば、１つ以上のクライアントコンピュータに対しサービスを提供するように、または全体的タスクを分散システムの一部として実行するように、構成された１つ以上のコンピュータシステム（例えばサーバ）の中で、本発明の様々な態様を分散させることができる。例えば本発明の様々な態様は、１つ以上のサーバシステムに分散するコンポーネントが本発明の様々な実施形態に従って様々なファンクションを実行するクライアント・サーバシステムや多層システムで、実施できる。これらのコンポーネントは、実行可能コード、中間コード（例えばＩＬ）、またはインタープリタ型コード（例えばＪａｖａ（登録商標））であってよく、通信ネットワーク（例えばインターネット）上で通信プロトコル（例えばＴＣＰ／ＩＰ）を使って通信する。
【０１５４】
本発明が特定のシステムまたはシステム群での実行に限定されないことを理解されたい。また、本発明が特定の分散アーキテクチャ、ネットワーク、または通信プロトコルに限定されないことを理解されたい。
【０１５５】
本発明の様々な実施形態はオブジェクト指向プログラミング言語を使って、例えばＳｍａｌｌＴａｌｋ、Ｊａｖａ（登録商標）、Ｃ＋＋、Ａｄａ、またはＣ＃（Ｃシャープ）を使って、プログラムできる。他のオブジェクト指向プログラミング言語を使用することもできる。代わりに、関数型言語、スクリプト言語、アセンブリ言語、および／または論理プログラミング言語を使用することもできる。本発明の様々な態様は非プログラム環境で実装できる（例えばＨＴＭＬ、ＸＭＬ、またはその他の形式で作成された文書は、ブラウザプログラムのウィンドウに表示されるときに、グラフィカルユーザインターフェース（ＧＵＩ）の諸態様を提示したりその他のファンクションを実行する）。本発明の様々な態様は、プログラム要素として、非プログラム要素として、またはこれらの組み合わせとして、実装できる。
【０１５６】
このシステムの様々な態様は、システム１００の中の１つ以上のシステムによって実装できる。例えばシステムは、シングルまたはマルチプロセッサシステムであってよい。システムは一例において、パーソナルコンピュータ（ＰＣ）等のシステムで実行するソフトウェアプロセスを含む。かかるシステムは、例えば試験対象デバイス（ＤＵＴ）を試験する試験システムで１つ以上のファンクションをユーザに実行させる。かかるシステムは、数ある中で例えば試験システムや制御システムを含む。
【０１５７】
クライアント・サーバアーキテクチャの例
本発明の別の態様によると、試験プログラムソフトウェアは様々な種類のユーザによって利用されることが分かっている。ユーザには試験アプリケーションを開発する者もいれば、開発されたアプリケーションを試験工程の運営管理に役立てる者もいる。ただし種類の異なるこれらのユーザは、実行するファンクションに応じて特定のユーザインターフェース（ＵＩ）を使用する必要がある。テスタには様々な種類があってユーザインターフェースはテスタの種類によって異なり、ユーザは装置の運転にあたって特定の種類のインターフェースを理解しなければならないことが分かっている。また、ＡＴＥ業界ではアプリ
ケーションとドライバが緊密に結合し、ユーザインターフェースはシステムソフトウェアに結合されていることが分かっている。本発明の一態様によると、標準のユーザインターフェースを使って様々な種類のテスタにアクセスすることにより、ユーザに必要なトレーニングの量を減らす。トレーニングの必要量をさらに減らすためユーザ別のインターフェースを提供し、ユーザが自身の役割に関係する試験ファンクションを実行できるようにする。
【０１５８】
さらに、本発明の別の態様によると、ユーザがどこからでも試験ファンクションを実行できるようにする試験アーキテクチャが提供される。１つの特定の実装においては、ブラウザプログラムを通じてユーザインターフェースにアクセスし、ユーザは、通信ネットワークを通じて試験システムへ結合された任意の場所から試験ファンクションを実行する。従来の環境では通常、ＵＩがマシンに結合されているが、ネットワークを介してＵＩを利用できるようになれば、ユーザは別の場所からでも試験を実行できる。
【０１５９】
図１３は、本発明の一実施形態によるシステム例１３００のアーキテクチャ図を示すもので、これは試験ファンクションを実行するサーバと、試験ファンクションの実行に用いるユーザインターフェースを提示する１つ以上のクライアントシステムとを含む。図１３は専ら例証を目的とするものであって、本発明の１つ以上の態様を促進するにあたってこれ以外のアーキテクチャを使用できることを理解されたい。
【０１６０】
図１３に見られるとおり、試験システムを実装するためコンピュータシステム２００（例えば図１２を参照しながら上述した汎用コンピュータシステム）を使用する。コンピュータシステム１３０１は、試験システムファンクションと、データベースファンクションと、後述するインターフェースファンクションとを実行する１つ以上のソフトウェアプロセス１３０５を含む。本発明の一実施形態によると、システム１３０１は図１２を参照しながら上述した汎用コンピュータシステムであってよい。このため、システム１３０１はオペレーティングシステムと、１つ以上のプロセッサと、１つ以上のＩ／Ｏコンポーネントとを含む。
【０１６１】
一実施形態によると、システム１３０１は１つ以上のクライアントシステム（例えばシステム１３０７Ａ−１３０７Ｄ）とそれらに関連するユーザ（例えばユーザ１３０８Ａ−１３０８Ｄ）とに試験ファンクションへのアクセスを許可する。一実施形態によると、試験システム１３０１とこれに関連するハードウェアとソフトウェアは、１つ以上の通信ネットワーク１３０４を介して通信する。ネットワーク１３０４は、例えばインターネット、法人企業ネットワーク、またはその他の通信ネットワーク型を含む。とりわけユーザは、通信ネットワーク１３０４を通じて様々な場所で試験システムファンクションにアクセスできる。
【０１６２】
一実施形態において、試験システムのユーザインターフェースは、通信ネットワークを介してダウンロードし閲覧できるウェブ方式のインターフェースである。一実施形態において、クライアント（例えばクライアント１３０７Ｄ）はブラウザプログラム（例えばＭｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒブラウザプログラム）を含む。ユーザは試験システム１３０１にログインし、システム１３０１は１つ以上のソフトウェアプログラムまたはコンポーネント１３０３を提供し、クライアントはこれを使って試験システムファンクションにアクセスする。一実施形態によると、試験システムファンクションはＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎから入手できる周知のＷｉｎｄｏｗｓ（登録商標）形式インターフェースを使って実行され、ブラウザプログラム（例えば１３０９）を通じてアクセスされる。事実クライアントは、既述のユーザインターフェースを提示するため任意のアプリケーションプログラム１３１０ソフトウェアおよび／またはデータベース要素（例えばデータベース１３１１に蓄積される要素）をダウンロードし、
蓄積する。Ｗｉｎｄｏｗｓ（登録商標）形式を使用するが、どんな種類のソフトウェアおよび／または通信方法でも使用でき（例えばＣＧＩ、Ｐｅｒｌ、ＸＭＬ、その他）、本発明が特定の方法に限定されないことを理解されたい。
【０１６３】
特に、ユーザは任意のウェブ対応クライアントから試験ファンクションを実行できる。ユーザは、例えばウェブサービスを利用し、試験システム１３０１へ接続している限りは、任意の場所から任意のテスタをコントロールできる。従来、ユーザインターフェースは試験ハードウェアに結合されその試験ハードウェアに専用のものだから、試験装置で局所的に実行される。本発明の一実施形態によると、ユーザは通信ネットワーク（例えばインターネット）を通じて試験システム１３０１にログインする。
【０１６４】
さらに別の実施形態によると、それぞれのユーザには試験をコントロールするため自分なりのＧＵＩが提示される。試験システム１３０１は、ユーザがそれぞれ異なるファンクション（プログラミング、メンテナンス、その他）を実行する場合に別々のＵＩを蓄積し（例えばデータベース１３０２内のエントリ１３０６として蓄積）、ログインするユーザに応じて異なるＵＩをユーザに提示する。これらのＵＩは１つ以上のプログラム（例えばアプリケーションプログラム１３１０）を含み、局所的に蓄積された１つ以上のコンポーネントを具備する。さらにＵＩは、ＵＩ構成データを蓄積する１つ以上のデータベースを含む。したがってユーザは、ネットワークに接続する場所ならどこでもカスタムＵＩを閲覧でき、それらのカスタムＵＩはユーザの特定の役割に合わせて構成される。
【０１６５】
ＡＴＥテスタにおけるプロセス
本発明の一実施形態において、図１４に示すＰｏｗｅｒＰｏｌｌプロセス１４００は抽象層アーキテクチャの中でのモジュール間のやり取りを例証する。これより、例えば図１５について説明するプロセスフロー１４００を使って実行されるプロセスの例を説明する。以下に説明するプロセスは一例に過ぎず、制限を目的とするものではないことを理解されたい。
【０１６６】
ＰｏｗｅｒＰｏｌｌプロセス１４００は、典型的にはプラットフォーム層で１４０２におけるタイマーの満了によって始まる。任意選択で、時間終了（ＥＯＴ）イベントの有無やプログラムがブレイクポイントに達したか否かをＰｏｗｅｒＰｏｌｌプロセスでチェックすることもできる。電力ポーリングタイマーが満了になっていなければ１４０４（偽）、１４０６でメインスレッドの実行が継続する。電力ポーリングタイマーが満了しているなら、１４０４（真）、プラットフォーム層は２つのプラットフォーム状態変数「Ｓｙｓｔｅｍ  ＰｏｗｅｒＳｔａｔｅ」および「Ｓｙｓｔｅｍ  Ｐｏｗｅｒ  Ｉｎｔｅｒｒｕｐｔｅｄ」を含むコールをシステム層に引き渡す。これに応じてシステム層は１４０８で、システムＰＩモジュールを通じてＵｐｄａｔｅ  ＳｙｓｔｅｍＰｏｗｅｒＳｔａｔｕｓファンクションをコールする。一実施形態においては、データフローが一通り完了した後にシステムＰＩが２ビットのデータをプラットフォーム層に返し、ビット１はＰｏｗｅｒ  Ｉｎｔｅｒｒｕｐｔｅｄを反映し、ビット０はＰｏｗｅｒＳｔａｔｅを反映する。この抽象化により、プラットフォームが実際の電力チェック方法（例えば電力スイッチの状態を判断する、電圧の有無を判断する、その他）を知る必要はなく、このチェックファンクションはシステムＰＩが遂行する。
【０１６７】
任意選択で、プロセスは引き続きプラットフォーム状態変数が「ＰｒｏｇｒａｍＡｔＢｒｅａｋＰｏｉｎｔ」になっているか否かを判断し（図示せず）、なっていなければステップ１４１０でディスパッチャ制御コンポーネントがメールボックスを読み取り、これをクリアする。ディスパッチャ制御コンポーネントはステップ１４１０で最新の構成（存在する場合）を取り、その構成を現在の構成と比較する。異なる構成の存在が確認されると１４１２（真）、ＰＩモジュールが削除されたか否かのチェックを１４１４で行い、ＰＩ
モジュールが削除されていないなら、１４１４（偽）、１４２０で新たなＰＩモジュールをロードし、ＰＩモジュールが削除されていたなら、１４１４（真）、削除された全ＰＩモジュールにつき１４１６でＰｏｗｅｒＯｎＩｎｉｔファンクション（物理計器層内）をコールし、１４１８で削除済みＰＩモジュールをアンロードする。ステップ１４２０では新たなＰＩをロードする。これとは別に、ステップ１４０８のシステムＰＩに対するＵｐｄａｔｅコールの後にプロセスは１４１０へ直行し、ディスパッチャが新たな構成を受け取ったか否かを判断する場合もある。
【０１６８】
このプロセスの二者択一分岐１４１２（真）および１４１２（偽）は再び合流し、ＰＩモジュールに対応するハードウェアで電力の有無を１４２２で判断する。電力がオフなら１４２２（偽）なら１４２８でＰｏｗｅｒＯｎＩｎｉｔファンクションをコールし、電力が使用可能なら１４２２（真）、システムは電力がオフまたは不通になっていたか否かを１４２４でチェックする。電力がオフまたは不通になっていたなら１４２４（真）、１４２８でＰｏｗｅｒＯｎＩｎｉｔファンクションをコールする。電力がオフまたは不通になっていなかったなら１４２４（偽）、引き続き１４２６で構成が異なるか否かをチェックする。以前の分岐は構成検査のところで再び合流する。構成が異ならないなら１４２６（偽）、プロセスは１４３８でメインスレッドの実行に戻る。構成が異なるなら１４２６（真）、任意選択としてシステムはプラットフォーム状態変数「ＳｔａｔｅＲｅｃｉｐｅＱｕａｌｉｆｉｅｄ」を再度審査し、更新する（図示せず）。代わりに、異なる構成の確認を受けて１４２６（真）、プログラムがロードされるか否かを判断するチェックをステップ１４３０で行う。プログラムがロードされないなら１４３０（偽）、１４３８でメインスレッドの実行が継続する。プログラムがロードされるなら１４３０（真）、１４３２で全ＶＭＩに対しファンクションコールＩｓＭａｐｐｉｎｇＯＫ（）を行う。全てのＶＭＩでマッピングがｏｋなら、１４３４（真）、１４３８でメインスレッドの実行が継続する。全てのＶＭＩでマッピングがｏｋでなければ、１４３４（偽）、１４３６で状態変数ＰｒｏｇｒａｍＮｏｔＶａｌｉｄを更新する。
【０１６９】
要するに、このプロセス例はシステムが電力オン状態にあるか否かを判断する。また、電力オン状態にあるなら、試験プログラムとＶＭＩは、ハードウェアで既存のポストパワーサイクルまたは再構成を試験するための所要条件を満たすことができる。このチェックの責任をＶＭＩが担うことで、別の抽象化された責任はプラットフォームからモジュールに移される。
【０１７０】
システムの電力状態を判断したら、次のチェックでシステムの実際の構成を確認する。このプロセスの結果、ハードウェアが不在か不適切な構成済みＰＩモジュールは自身をディスエーブル状態に置き、そのリソースを「ＰｏｗｅｒｅｄＯｆｆ」として公開する。構成済みＰＩモジュールに一致しない追加のハードウェアが検出される場合は、ＶａｌｉｄａｔｅＣｏｎｆｉｇｕｒａｔｉｏｎプロセス（図示せず）が警告メッセージを発行する。この警告メッセージはプラットフォームユーザメッセージングウィンドウかプラットフォームコンフィギュレータへ返され、気の利いた表示名があるならこれを表示し、なければ「不明ハードウェア」メッセージを表示する。
【０１７１】
警報処理
一実施形態の警報処理操作を図解する図１５について様々な層間のやり取りをさらに説明できる。図１５は制限ではなく例証のため提示されている。
【０１７２】
図５の実施形態に見られるとおり、種々の抽象層はさらに、それぞれのモジュールに抽象化されている。この例ではまた、モジュール間通信を管理するための少なくとも１つのインターフェース（１５３４−１５５２）が各モジュールの境界のところに見られる。例えば、システムＰＩ  １５０４モジュールはプラットフォーム層インターフェース１５３
２（ディスパッチャを備えるプラットフォームソフトウェアとして図示）とのインターフェース１５３８を持ち、これはＣｈｅｃｋＡｌａｒｍｓファンクションコールにかかわる双方向通信を管理する。この例のシステムＰＩモジュール１５０４はまた、ＰＩモジュールのインターフェース１５４２とともに通信とファンクションを管理するインターフェース１５４０を持つ。
【０１７３】
本発明の別の態様において、プラットフォーム層は、処理フローの結果を記録するための機能を抽象化したものである。図１５を参照して分かるとおり、処理フローの一部として実行される様々なファンクションコールは一実施形態において、その結果をプラットフォーム層に報告する。プラットフォーム層は一実施形態において、他の抽象層からの各種ファンクションコールの報告結果を記録するための機能を抽象化したものである。
【０１７４】
代表的警報プロセス１５００を参照しながら様々なファンクションコールと機能を説明する。代表的プロセス１５００は制限ではなく例証のため提示されている。警報プロセス１５００は１５０２でシステムＰＩに対するＣｈｅｃｋＡｌａｒｍｓ（）コールで始まる。システムＰＩ  １５０４は一実施形態においてテスタの構成を完全に把握し、全占有ロケーション（ロケーションはプラットフォームコンセプトであり、リストの索引として機能する３２ビット数で表される）のリストを保持する。プラットフォーム／ディスパッチャ１５０８は、警報を発したロケーションのリストがシステムＰＩ  １５０４から返ってくることを期待する。システムＰＩは１５０６で、警報を発したロケーションのリストをプラットフォーム／ディスパッチャ１５０８に返す。このリストは一実施形態において、システムＰＩ  １５０４によって選別される。一例において、選別にあたってはＰＩ  １５１２が管轄内にあるかどうかをシステムＰＩ  １５０４が判断する。別の例では、システムＰＩ  １５０４の管轄内にないＰＩ  １５１２を自動的に返すようシステムを構成する。例証のため、Ｃｅｒｅｓ  Ｎａｔｉｖｅ  ＩｎｓｔｒｕｍｅｎｔはＣｅｒｅｓ  システムＰＩの管轄内にある。
【０１７５】
ここでの重要コンセプトとして、テスタにとってネイティブではない計器は総合試験ソリューションに容易く組み入れることができる。ＰＩモジュールとのプラットフォームインターフェースはハードウェア実装を期待しない。したがって一具体例で、ＧＰＩＢまたはＰＣＩＥｘｐｒｅｓｓベースのソリューションはネイティブ構築ソリューションとして統合でき、ハードウェアから独立したソリューションを可能にする。
【０１７６】
１５１０では、システムＰＩに対するＣｈｅｃｋＡｌａｒｍｓ（）コールで返された各ロケーションに対し（１５０２および１５０６）、ＳｅｒｖｉｃｅＡｌａｒｍｓ（）コールを行う。ＳｅｒｖｉｃｅＡｌａｒｍｓ（）を受け取ったＰＩ  １５１２（またはシステムＰＩ  １５０４（図示せず））は、実際の警報状態の有無を判断するためハードウェアにアクセスする。一実施形態においてはシステムＰＩによる警報の選別が実行時間に貢献し、試験プラットフォームの決定的性質を維持するのに役立つ。別の実施形態においては、測定精度に関係しない警報やハードウェアの有効状態を指摘しない警報は生成しないようシステムを構成する。１５１４では、ＰＩ  １５１２（またはシステムＰＩ  １５０４（図示せず））がハードウェアの警報状態を読み取る。ステップ１５１４はまた、ローカル警報キャッシュをクリアすることを含む場合があり、さらにハードウェアを安全状態に置くことを含む場合がある。
【０１７７】
警報状態を読み取ったＰＩ  １５１２（またはシステムＰＩ  １５０４（図示せず））は、リソース別の警報とＡｌｌＳｉｔｅ警報（グローバル警報）をキャッシュする。一実施形態においては、次のＳｅｒｖｉｃｅＡｌａｒｍｓ（）コールが行われるまでこのキャッシュを維持する。キャッシュにより、ツール表示に警報を使用することが可能となる。
【０１７８】
１５１６では、インスタンス化された各ＶＭＩ  １５１８に対しＲｅｐｏｒｔＡｌａｒｍｓ（）コールを行う。このコールは一実施形態において、１５０２と１５０６におけるシステムＰＩ  １５０４に対するＣｈｅｃｋＡｌａｒｍｓ（）コールでロケーションが返されようが返されまいが行われる。このような独立したＲｅｐｏｒｔＡｌａｒｍｓ（）コールは一例によると、警報がＰＩ（例えば１５１２）によって永続警報として扱われる場合、ハードウェアがシステムＰＩ  １５０４に警報を伝えない場合（これはシステムＰＩが管轄内のＰＩに基づき警報を選別する実施形態において生じる）、あるいはＶＭＩの中かＶＭＩにマップされたリソースでソフトウェアレベルの警報が発生した場合に、有利である。１５２０では、ＶＭＩ  １５１８が警報の有無を判断するためリソース、例えばＰＩ  １５１２を、照会する。ＶＭＩ  １５１８は１つ以上のＰＩとやり取りすることもあり、いくつかのＰＩ相互作用とそれらの関連リソースにＶＭＩを制限するものとして図を解釈するべきではない。
【０１７９】
ＶＭＩの照会に応じ、１５２２でＰＩ  １５１２はリクエストされた警報情報で応答し、警報を報告済みとマークする。ＰＩ  １５１２は、その設計または構成に基づき、報告する警報を選別することがある。ＶＭＩ  １５１８もまた、その設計または構成に基づき、報告された警報を選別することがある。１５２４では、ＶＭＩ  １５１８がそのリソースに関する応答をｍｓ＿ｂｏｏｌを使って提供する。一実施形態においては、マルチサイトディープのブールを使って応答を行う。つまりマルチサイトオブジェクト（例えばｍｓ＿ｂｏｏｌ、ｍｓ＿ｆｌｏａｔ、その他）を作成し、そのサイズは、開発されるプログラムでサポートするサイトの数によって決まる。ＶＭＩオブジェクトはサイトの情報もとに設計されるから、ＶＭＩ  １５１８は警報をサイト別にコンパイルできる。１５３０では、ＲｅｐｏｒｔＡｌａｒｍｓからの応答をデータ記録サービス１５５４に報告する。あるいは、ＲｅｐｏｒｔＡｌａｒｍｓからの応答を他の情報と組み合わせてデータ記録サービス１５５４に報告することもできる。
【０１８０】
１５２６では、インスタンス化された各ＰＩ  １５１２（１つのＰＩが図示されているが、多数のＰＩも可能）とシステムＰＩ  １０５４に対しＧｅｔＵｎｒｅｐｏｒｔｅｄＡｌａｒｍｓ（）コールを行う。ＧｅｔＵｎｒｅｐｏｒｔｅｄＡｌａｒｍｓ（）コールは、ＣｈｅｃｋＡｌａｒｍｓ（）コールで返されるロケーションの有無にかかわりなく（１５０２および１５０６）行われることもあれば、システムＰＩ  １５０４に対して行われることもある（図示せず）。一実施形態においては、システムＰＩとＰＩだけにＧｅｔＵｎＲｅｐｏｒｔｅｄＡｌａｒｍｓ（）コールを行う。ＧｅｔＵｎＲｅｐｏｒｔｅｄＡｌａｒｍｓ（）コールでは、ＶＭＩにマップされていないリソースによる警報の報告が可能である。ＶＭＩに対するＲｅｐｏｒｔＡｌａｒｍｓ（）コールは、永続警報であれ非永続警報であれ、ＶＭＩにマップされたリソースの全ての警報を処理するように構成できる。永続警報またはソフトウェア警報は、たとえシステムＰＩがＣｈｅｃｋＡｌａｒｍｓ（）コールに対し空のロケーションリストを返す場合でもＲｅｐｏｒｔＡｌａｒｍｓとＧｅｔＵｎｒｅｐｏｒｔｅｄＡｌａｒｍｓが依然として実行されるという事実により、処理される。
【０１８１】
一実施形態においては、これに応じて、１５２６でＰＩ  １５１２が２ビット数を返し、そのＭＳＢはＡｌｌＳｉｔｅｓアラームを指示し、ＬＳＢは非報告リソース警報を指示する。１５３２では、ＧｅｔＵｎｒｅｐｏｒｔｅｄＡｌａｒｍｓ（）からの応答をデータ記録サービス１５５４に報告する。あるいは、この報告に他の情報を組み合わせてデータ記録サービス１５５４に報告することもでき、例えばＲｅｐｏｒｔＡｌａｒｍｓとＧｅｔＵｎｒｅｐｏｒｔｅｄＡｌａｒｍｓからの応答を組み合わせ、まとめてデータ記録サービス１５５４へ送ることができる。
【０１８２】
ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅ（ＰＯＩ）ファンクション
本発明の一実施形態において、物理計器層は、システムの電力状態をポーリングするシ
ステムプロセスの一部としてＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションをコールする。本発明の一実施形態においては、ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションが物理計器の基本クラスメソッドに含まれる。本発明の一態様によると、ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションはＰＩモジュールとそのハードウェアを既知の初期電力状態に置く。本発明の別の態様によると、プラットフォーム層が実行している保証はないため、あるいはＰＩモジュールが構成されロードされる保証はないため、試験ハードウェアは既知の安全な電力状態に入ることが重要である。一実施形態において、ＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクションは物理計器抽象層で規定される基本クラスファンクションのメンバーである。
【０１８３】
図１６は、一実施形態のＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚｅファンクション実装例１６００を示す。図１６は代表的なデータフローを説明するものであり、図示された１つのファンクションに、またはこの特定のデータフローに、本発明を制限するものと読解するべきものではない。
【０１８４】
１６０２ではＰｏｗｅｒＯｎＩｎｉｔｉａｌｉｚａｔｉｏｎコールを行う。１６０４では、試験ファンクションの実行にあたってＰＩ／ハードウェアデバイスがシステム電力状態に依拠するか否かを判断する。依拠しないなら１６０４（偽）、１６１２でＰＩローカルキャッシュを初期化状態に設定し、１６１４で公開リソースの状態を更新する。ＰＩ／ハードウェアデバイスがシステム電力状態に依拠するなら１６０４（真）、１６０６でシステムの電力ステータスチェックを行う。一実施形態においてはＧｅｔＰｌａｔｆｏｒｍＳｔａｔｅＩｎｆｏｒｍａｔｉｏｎ（）コールを行ってシステム電力ステータスを入手する。ＧｅｔＰｌａｔｆｏｒｍＳｔａｔｅＩｎｆｏｒｍａｔｉｏｎ（）コールは別の実施形態において、ＰＩ基本クラスファンクションの一部である。システム電力がオンでなければ１６０８（偽）、１６１２でＰＩローカルキャッシュを初期化状態に設定し、１６１４で公開リソースの状態を更新する。システム電力がオンなら１６０８（真）、ＰＩ／ハードウェアデバイスをリセットする。一実施形態においては、試験に向けてＰＩ／ハードウェアデバイスが既知の状態にあることを保証するため、リセットを行う。ＰＩ／ハードウェアデバイスをリセットしたら、１６１２でＰＩローカルキャッシュを初期化状態に設定し、１６１４で公開リソースの状態を更新する。一実施形態においては、ＰｏｗｅｒＯｎ状態かＰｏｗｅｒＯｆｆ状態のいずれかでＰＩリソースの電力状態を識別する。
【０１８５】
別の実施形態において、仮想計器層は、そのファンクションの実行に用いる基礎的機能を規定する基本クラスのファンクションを含む。一例において、ＶＩモジュールはＧｅｔＰｌａｆｏｒｍＩｎｆｏｒｍａｔｉｏｎファンクションをコールしてプラットフォーム状態情報を得る。一実施形態において、仮想計器層は、リソースの警報リストを報告するファンクションを含む。別の実施形態において、この警報報告ファンクションは基本クラスのファンクションに含まれる。
【０１８６】
本発明の別の態様によると、システム層は、そのファンクションの実行に用いる基礎的機能を規定する基本クラスのファンクションを含む。一例において、プラットフォームは図１４に示すＰｏｗｅｒＰｏｌｌプロセスの一部としてＵｐｄａｔｅＳｙｓｔｅｍＰｏｗｅｒＳｔａｔｕｓファンクションをコールする。実施形態において、このＵｐｄａｔｅＳｙｓｔｅｍＰｏｗｅｒＳｔａｔｕｓファンクションはシステム層の基本クラスファンクションに含まれる。別の例で、基本クラスのファンクションは、ロケーションで警報の有無をチェックし警報のリストを返すＣｈｅｃｋＡｌａｒｍファンクションを含む。
【０１８７】
ソフトウェアウィザードとルールチェックエンジン
本発明の一態様によると、機能の抽象化は、種々の抽象層間にインターフェースを生成するソフトウェアウィザードを操作するための機能の抽象化を含む。一実施形態において
、機能の抽象化は生成エンジンを含み、このインターフェース生成エンジンは、種々の抽象層間で通信を管理するインターフェースを生成する。このインターフェース生成エンジンは一実施形態において、システム層のモジュールと物理計器層のモジュールとの間でインターフェースを規定するための機能を抽象化したものである。インターフェース生成エンジンは一実施形態において、仮想計器層のモジュールと物理計器層のモジュールとの間でインターフェースを規定するための機能を抽象化したものである。インターフェース生成エンジンは一実施形態において、仮想計器層のモジュールとシステム層のモジュールとの間でインターフェースを規定するための機能を抽象化したものである。別の実施形態において、インターフェース生成エンジンは、システムＰＩモジュールと、ＰＩモジュールと、ＶＩモジュールと、プラットフォーム層との間でインターフェースを規定するための機能を抽象化したものである。
【０１８８】
別の実施形態において、機能の抽象化は、種々の抽象層のモジュールを生成するソフトウェアウィザードを操作するための機能の抽象化を含む。一実施形態において、機能の抽象化はモジュール生成エンジンを含み、このモジュール生成エンジンは、抽象層のいずれか１つでモジュールを規定する。このモジュール生成エンジンは一実施形態において、ＶＩモジュールを規定するための機能を抽象化したものである。別の実施形態において、モジュール生成エンジンは、ＰＩモジュールを規定するための機能を抽象化したものである。別の実施形態において、モジュール生成エンジンは、システムＰＩモジュールを規定するための機能を抽象化したものである。別の実施形態において、モジュール生成エンジンは、プラットフォームモジュールを規定するための機能を抽象化したものである。
【０１８９】
本発明の一態様によると、種々の抽象層間で適切なマッピングを保証するため、生成されたモジュールを検証する必要がある。本発明の別の態様によると、適切な機能を保証するため、生成されたモジュールを検証しなければならない。ルールチェックエンジンは一実施形態において、生成されたモジュールの適切なマッピングを検証して適切な機能を保証するための機能を抽象化したものである。例えば一実装においてはシステムＰＩとＰＩでルールチェックを行い、好ましくない相互作用を伴うことなくシステムＰＩとＰＩが連動することを検証する。ＶＭＩでルールチェックを行い、リソースのマッピングでルールが守られ正常に機能することを検証することもできる。
【０１９０】
本発明は本明細書で説明した上記の実施形態に限定されず、本発明の様々な実施形態が単独で実践されることもあれば、他の実施形態との組み合わせで実践されることもあることを理解されたい。
【０１９１】
本発明の少なくとも１つの実施形態の態様をいくつか説明してきたが、当業者が様々な変更、修正、および改良に容易く想到することは理解されよう。かかる変更、修正、および改良は本開示の一部であり、本発明の精神と範囲の中にある。したがって、前述の説明と図面は例証に過ぎない。
【図１】
2009544012.tif 000003
【図２】
2009544012.tif 000004
【図３】
2009544012.tif 000005
【図４】
2009544012.tif 000006
【図５】
2009544012.tif 000007
【図６Ａ】
2009544012.tif 000008
【図６Ｂ】
2009544012.tif 000009
【図６Ｃ】
2009544012.tif 000010
【図６Ｄ】
2009544012.tif 000011
【図７】
2009544012.tif 000012
【図８】
2009544012.tif 000013
【図９Ａ】
2009544012.tif 000014
【図９Ｂ】
2009544012.tif 000015
【図９Ｃ】
2009544012.tif 000016
【図１０】
2009544012.tif 000017
【図１１】
2009544012.tif 000018
【図１２】
2009544012.tif 000019
【図１３】
2009544012.tif 000020
【図１４Ａ】
2009544012.tif 000021
【図１４Ｂ】
2009544012.tif 000022
【図１５】
2009544012.tif 000023
【図１６】
2009544012.tif 000024
【国際調査報告】
2009544012.tif 000025
2009544012.tif 000026
2009544012.tif 000027