試験システム及びモジュール間通信方法
【課題】モジュール同士が安全かつ信頼できる方法で通信するための仕組みを提供する。
【解決手段】被試験デバイスに試験信号を供給可能なモジュール１０８を複数組み込み可能な試験システム１００は、所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器１５０を備える。この配送器１５０は、所定の二つのモジュールのうち一のモジュールＡから受信した信号を、他のモジュールＢへ配送する機能を備える。また、この試験システム１００は、モジュール１０８の接続関係を設定するためのモジュール設定ファイル１３０を備え、試験システム１００は、モジュール設定ファイル１３０に規定された内容に基づいて、配送器１５０を生成する。
【解決手段】被試験デバイスに試験信号を供給可能なモジュール１０８を複数組み込み可能な試験システム１００は、所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器１５０を備える。この配送器１５０は、所定の二つのモジュールのうち一のモジュールＡから受信した信号を、他のモジュールＢへ配送する機能を備える。また、この試験システム１００は、モジュール１０８の接続関係を設定するためのモジュール設定ファイル１３０を備え、試験システム１００は、モジュール設定ファイル１３０に規定された内容に基づいて、配送器１５０を生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は自動試験装置の技術分野に関する。特に、本発明は、各モジュールが独立に制御されることを前提とする自動試験装置におけるモジュール間通信技術に関する。
【背景技術】
【０００２】
従来、自動試験装置（以下「ＡＴＥ」という。）は、ＡＴＥメーカー各社各様の仕様で提供されていたため、ピン構成や測定ユニット等の構成の自由度が低く、また、試験プログラム資産の再利用が困難であった。このような背景から、デバイスの機能に応じて最適な構成にシステムを変更できるようなスケーラブルで柔軟なＡＴＥを実現すべく、標準化されたインタフェースを持つオープン・アーキテクチャＡＴＥが提案されている。
【０００３】
例えば、ＯＰＥＮＳＴＡＲ（登録商標）は、このようなオープン・アーキテクチャＡＴＥの規格の一つである（非特許文献１参照）。ＯＰＥＮＳＴＡＲシステムは、スケーラブルでかつ柔軟なモジュラー構造のＡＴＥプラットフォームを提供することを目的とし、そのための標準規格を定めている。サード・ベンダ等が提供する計測機器（モジュール）は、ＯＰＥＮＳＴＡＲ標準が定めるハードウェアとソフトウェアの要件を満たすことで、ＯＰＥＮＳＴＡＲシステムに組み込むことが可能である。
【非特許文献１】「Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｔｅｓｔ Ｃｏｎｓｏｒｔｉｕｍ」、［online］、［平成２０年３月２４日検索］、インターネット＜ＵＲＬ：http://www.semitest.org/jp/home＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、オープン・アーキテクチャの定める標準規格（仕様）では、ＡＴＥのプラットフォームやモジュールの実装に必要な全てを規定しているわけではなく、必要最小限の要件を定めている。しかし、実際にモジュールを設計してＡＴＥシステム内に組み込むには、モジュールの実装に依存した標準ではない機能が必要となる場合がある。とりわけ、異なるベンダのモジュール同士が専用のバスで接続されるような関係を持つ場合には、モジュール単位で区切り、独立に制御されることを前提とするＯＰＥＮＳＴＡＲ規格のようなオープン・アーキテクチャでは解決できない問題が発現する。
【０００５】
例えば、デジタル・モジュール間の同期を実現するモジュール（以下「Ｓｙｎｃモジュール」という。）は、デジタル・モジュールと専用のバスで接続される。しかし、Ｓｙｎｃモジュールの実装手法はベンダにより異なり、その専用バスの制御のためにはハードウェアの実装に依存した機能が必要となる。例えば、システム全体のデジタル・ピンのタイミングの同期をとるために、異なるデジタル・モジュール間の伝播遅延量（Ｔｐｄ）の差の吸収する機能を持つようなＳｙｎｃモジュールでは、それを機能させるには各モジュールからＴｐｄ値を収集する必要がある。そのためには、Ｓｙｎｃモジュールの制御ソフトウェアは、デジタル・モジュールの制御ソフトウェアと通信する必要がある。しかし、この機能はＳｙｎｃモジュールの実装に依存するところであり、その制御のためのソフトウェアのインタフェースは、ＯＰＥＮＳＴＡＲ規格のように各モジュールが独立に制御されることを前提とする仕様のＡＴＥでは扱えない。
【０００６】
本発明は、かかる事情に鑑みてなされたものであり、本発明に係る幾つかの態様は、モジュール同士が安全かつ信頼できる方法で通信するための仕組みを提供することを目的とする。特に、各モジュールが独立に制御されることを前提とするＡＴＥの定める標準仕様では扱えないモジュールの実装依存の領域に対しても高い拡張性と柔軟性を備える試験システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明による試験システムは、被試験デバイスに試験信号を供給可能なモジュールを複数組み込み可能な試験システムであって、所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を備える。この配送器は、所定の二つのモジュールのうち一のモジュールから受信した信号を、所定の二つのモジュールのうち他のモジュールへ配送する機能を備える。
【０００８】
また、好適には、試験システムは、モジュールの接続関係を設定するためのモジュール設定ファイルを備え、試験システムは、モジュール設定ファイルに規定された内容に基づいて、配送器を生成する。
【０００９】
さらに好適には、モジュール設定ファイルは、所定の二つのモジュール間の通信方法及び依存関係を設定するモジュール間通信設定部を含み、試験システムは、モジュール間通信設定部に規定された通信方法及び依存関係に基づいて、所定の二つのモジュール間の通信インタフェースとして機能する配送器を生成する。
【００１０】
また、好適には、モジュールは、通信可能な相手先モジュールの情報を備え試験システムは、モジュールが試験システムに組み込まれたときに、情報に基づいて、モジュール間通信設定部に規定される内容を書き換える。
【００１１】
さらに好適には、試験システムは、二以上のモジュールの各々を独立に制御することを前提とするものである。また、試験システムは、オープン・アーキテクチャに基づくシステムであり、二以上のモジュールは、オープン・アーキテクチャの標準仕様に準拠するものであることが好ましい。
【００１２】
また、本発明に係るモジュール間通信方法は、被試験デバイスに試験信号を供給可能なモジュールを二以上組み込み可能な試験システムにおいて、所定の二つのモジュール間で通信を行う方法である。そして、モジュールの接続関係を設定するためのモジュール設定ファイルに規定された内容に基づいて、所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を生成するステップと、配送器を介して、所定の二つのモジュールのうち一のモジュールから受信した信号を、所定の二つのモジュールのうち他のモジュールへ配送することにより、モジュール間通信を行うステップと、を備える。
【００１３】
本発明のプログラムは、本発明のモジュール間通信方法の各処理ステップをコンピュータに実行させることを特徴とする。本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
【００１４】
なお、本明細書等において、「手段」又は「部」とは、単に物理的手段を意味するものではなく、その手段又は部が有する機能をソフトウェアによって実現する場合も含む。また、１つの手段又は部が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段又は部の機能が１つの物理的手段により実現されてもよい。
【００１５】
また、本明細書等において、ベンダ等が提供する計測機器のハードウェアを「モジュール」といい、そのハードウェアを対象とするベンダ等のソフトウェアを「モジュール・ソフトウェア」と呼ぶ。
【００１６】
さらに、再構成可能なオープン・アーキテクチャＡＴＥは、試験システムに対する操作の統一だけでなく、目的の試験に最適なモジュールを、モジュール・ソフトウェアとともに、ユーザ自身が既存のシステムにプラグ・アンド・プレイ方式で導入可能なプラットフォームを提供する。また、モジュールのベンダに対しては、そのようなモジュール・ソフトウェアを開発するための開発環境を提供する。
【発明の効果】
【００１７】
本発明の試験システムによれば、モジュール・ソフトウェア同士が安全かつ信頼できる方法で通信するための仕組みを提供することができる。特に、各モジュールが独立に制御されることを前提とするＡＴＥの定める標準仕様では扱えないモジュールの実装依存の領域に対しても高い拡張性と柔軟性を備える試験システムを提供することができる。
【００１８】
例えば、本発明により、Ｓｙｎｃモジュールがデジタル・モジュールに対して、必要な通信のインタフェースを規定することができる。本発明に係る試験システムでは、モジュールの実装依存の問題をベンダ自身で解決できる仕組みを提供することで、このような問題がある場合にも、システムＯＳ（オペレーティング・システム）を変更することなくモジュールをシステムに組み込むことが可能になる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態について詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。また、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。さらに、本発明は、その要旨を逸脱しない限り、さまざまな変形及び応用が可能である。
【００２０】
図１は、本発明の一実施形態による試験システム１００のシステムアーキテクチャを示す。試験システム１００は、試験信号を生成して被試験デバイス（Device under Test。以下「ＤＵＴ」という。）１１２に供給し、ＤＵＴ１１２が試験信号に基づいて動作した結果出力する結果信号が期待値と一致するか否かに基づいてＤＵＴ１１２の良否を判断する。なお、本実施形態に係る試験システム１００は、オープン・アーキテクチャにより実現されるものとして説明するが、本発明は、オープン・アーキテクチャの試験システムに限定されるものではない。
【００２１】
本実施形態では、システムコントローラ（ＳｙｓＣ）１０２がネットワークを介して複数のサイトコントローラ（ＳｉｔｅＣ）１０４に接続される。システムコントローラ１０２は、エンド・ユーザが通常作業を行うホストコンピュータであり、試験システム１００全体を管理する役割を果たす。また、システムコントローラ１０２は、サイトコントローラ１０４に対する処理の要求の発行や、サイトコントローラ１０４間の処理の調停を行う。ユーザのアプリケーションや標準のＧＵＩツールは、システムコントローラ１０２上で動作し、サイトコントローラ１０４と通信を行って機能を実現する。
【００２２】
また、システムコントローラ１０２は、サイトコントローラ１０４上でモジュール１０８の制御を行うモジュール・ソフトウェアや、ユーザの試験プログラムやパターン・プログラムなどを保管するストレージを備える。これらは、必要に応じてサイトコントローラ１０４に送られ、実行される。
【００２３】
各サイトコントローラ１０４は、試験サイト１１０に配置される１つ又は複数のモジュール１０８を制御して試験を実行するために、モジュール接続イネーブラ１０６を通して、モジュール１０８に接続される。この試験は、ユーザの作成する試験プログラムに基づいて実行される。なお、サイトコントローラ１０４は、一つのＤＵＴ１１２を試験する試験サイト１１０を複数個、同時に制御するようにしてもよい。
【００２４】
サイトコントローラ１０４の主な役割として、次の３つが挙げられる。まず、試験プログラムが指定する試験サイト１１０の構成に従い、モジュール接続イネーブラ１０６を構成し、サイトコントローラ１０４とモジュール１０８間のバス１０７の接続を確立する。また、試験サイト１１０内のモジュール１０８の制御を行うモジュールソフトウェアを実行する。さらに、試験プログラムを実行し、各試験サイト１１０のＤＵＴ１１２の試験を実行する。
【００２５】
なお、動作環境によっては、システムコントローラ１０２は、サイトコントローラ１０４の動作とは別のＣＰＵ（中央演算装置）上に配置することができる。別法では、システムコントローラ１０２及びサイトコントローラ１０４は、共通のＣＰＵを共有することができる。同様に、各サイトコントローラ１０４は、その専用のＣＰＵ上に配置することができるし、また、同じＣＰＵ内の別個のプロセス又はスレッドとして配置することもできる。
【００２６】
モジュール接続イネーブラ１０６は、サイトコントローラ１０４とモジュール１０８とのバス１０７の接続を任意に構成することのできるスイッチである。モジュール接続イネーブラ１０６は、接続されるハードウェアモジュール１０８の構成を変更できるようにするとともに、データ転送用（パターンデータのロード用、応答データの収集用、制御用等）のバスとしての役割も果たす。実現可能なハードウェアの実装形態は、専用接続、交換接続、バス接続、リング接続及びスター接続を含む。モジュール接続イネーブラ１０６は、たとえばスイッチマトリクスとして実装することができる。
【００２７】
モジュール１０８は、ＤＵＴ１１２に試験信号を供給する計測機器のハードウェアである。本実施形態においては、モジュール１０８として、オープン・アーキテクチャに基づく各種のモジュールを用いることができる。また、モジュール・ハードウェア１０８を動作させるためのソフトウェアをモジュール・ソフトウェアという。モジュール・ソフトウェアは、デバイス測定時にモジュール１０８の制御をつかさどるモジュール・ドライバ、モジュール１０８の校正と診断を行う校正診断ソフトウェア、モジュール１０８の動作をソフトウェアでエミュレートするエミュレーション・ソフトウェア、モジュール１０８固有のパターン・コンパイラ、およびＧＵＩツールなどを含む。
【００２８】
各試験サイト１１０は、それぞれ一つのＤＵＴ１１２に関連付けられる。ＤＵＴ１１２は、ロードボード１１４を通して、対応する試験サイト１１０のモジュール１０８に接続される。
【００２９】
図２は、試験サイト１１０及びロードボード１１４のハードウェアの概略構成と各種設定用ファイルとの関係の一例を示す図である。図２に示すように、モジュール１０８は、試験システム１００のテストヘッド１３２内のモジュール・スロットに差し込まれる。
【００３０】
試験サイト１１０の構成は、テキスト形式で記述されるソケットファイル１１８で指定される。このソケットファイル１１８には、ＤＵＴ１１２ごとに、ＤＵＴソケット１２０のＤＵＴピン１２２とロードボード１１４上のコネクタピン１２４との接続が記述される。コネクタピン１２４は、ブロック番号とコネクタ番号が付けられており、例えば、「１２．３」のように、「（ブロック番号）．（コネクタ番号）」の形式で表記される。ロードボード１１４のコネクタピン１２４は、テスタ・インタフェース・ユニット（Tester Interface Unit。以下「ＴＩＵ」という。）１２６を介してモジュール１０８のピン１２８と接続される。
【００３１】
一方、ロードボード１１４は試験対象となるデバイスによって異なる場合が多い。そのため、モジュール・ソフトウェアが個々のロードボード１１４の実装に依存しないようにするためには、試験システム１００において、モジュール１０８が実装するピン１２８そのものを定義できるようにし、それをもとにモジュール１０８の制御ができるようにしなければならない。本試験システム１００では、これはモジュール設定ファイル（Module Configuration File。以下「ＭＣＦ」という。）１３０によって達成される。
【００３２】
ＭＣＦ１３０には、モジュール１０８のリソースとロードボード１１４のコネクタピン１２４との接続関係が指定される。これにより、論理的なピンの表現であるリソースと、モジュール１０８の物理ピン１２８、さらにはそれが接続されているロードボード１１４のコネクタピン１２４との関係が定められる。ＭＣＦ１３０は、システムだけが設定可能であることが望ましい。
【００３３】
なお、本実施形態において、モジュール１０８の機能は、主にモジュール１０８の全体的な制御に関わる機能を提供するモジュール・オブジェクトと、モジュールのピン毎の機能を提供するリソース・オブジェクトによって表現される。本実施形態に係る試験システム１００では、これらは全て、ＭＣＦ１３０に記述される内容に従って、実際のハードウェアのエンティティと対称に結び付けられる。なお、これらのソフトウェアのオブジェクトを提供するモジュール・ソフトウェアを、ここではモジュール・ドライバと呼ぶ。
【００３４】
また、本実施形態において、リソースとは、試験システム１００のモジュール１０８が備える物理的なピン１２８とその機能とを、オブジェクトで抽象化して表現したものである。モジュール１０８の一つの物理ピン１２８は、一つのリソースとして表現されてもよいし、機能的に分割された複数のリソースとして表現されてもよい。
【００３５】
リソースの機能的な分類はリソース・タイプと呼ばれ、その機能の定義はモジュール１０８のベンダが提供するリソース定義ファイルによって示される。論理的なピンを指すリソースは、リソース・タイプと、モジュール１０８内でピン１２８を特定する番号（リソースＩＤ）と、試験システム１００内でモジュール１０８を特定するバス１０７のポート番号との３つ組で表現される。リソース・タイプとリソースＩＤの組と、それに対応するモジュール１０８内の物理ピン１２８の関係は固定的であるため、リソースが与えられたときに、それを物理的なピン１２８に対応付けることが可能となる。なお、リソースが物理ピン１２８と対応付けられることはアーキテクチャ上必須ではなく、モジュール１０８の持つ機能を仮想的なピンに見立てて表現し、制御することも可能である。
【００３６】
図３は、試験システム１００のソフトウェア・アーキテクチャ２００の一例を示す。ソフトウェア・アーキテクチャ２００は分散オペレーティングシステムを表しており、関連するハードウェアシステム要素１０２、１０４、１０８に対応する、システムコントローラ・ソフトウェア２２０（以下、単に「システムコントローラ２２０」ともいう。）、少なくとも１つのサイトコントローラ・ソフトウェア２４０（以下、単に「サイトコントローラ２４０」ともいう。）及び少なくとも１つのモジュールを含むテストヘッド・ソフトウェア２６０（以下、単に「テストヘッド２６０」ともいう。）のための構成要素を有する。
【００３７】
一つの例示的な選択として、試験システム１００は、ソフトウェアのプラットフォームとしてＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）を使用し、実装言語としてＡＮＳＩ／ＩＳＯ標準Ｃ＋＋を使用することができる。プラットフォームの全てのシステム・インタフェースもまた、Ｃ＋＋のクラスまたはインタフェースとして提供され、ユーザの試験プログラムやモジュール・ソフトウェアはＣ＋＋で実装することができる。
【００３８】
システムコントローラ２２０は、ユーザのための一次的なインタラクションポイントであり、サイトコントローラ２４０へのゲートウェイと、マルチサイト／ＤＵＴ環境におけるサイトコントローラ２４０の同期とを提供する。ユーザアプリケーション及びツールは、グラフィカルユーザインターフェース（ＧＵＩ）に基づくものでも、そうでないものでも、システムコントローラ２２０上で実行される。
【００３９】
また、システムコントローラ２２０は、テストプラン、試験パターン及び試験パラメータファイルを含む、全てのテストプラン関連情報のためのリポジトリとしての役割も果たす。これらのファイルを記憶するメモリは、システムコントローラ２２０に対してローカルに存在することができるか、又は、ネットワークを介してシステムコントローラ２２０に接続されることができる。
【００４０】
さらに、システムコントローラ２２０は、フレームワーククラス２２１と、システムツール２２２と、外部ツール２２３と、サイトコントローラへの標準インタフェース２２４と、通信ライブラリ２３０とを含む。
【００４１】
システムコントローラ２２０に関連するフレームワーククラス２２１は、オブジェクトと対話するための仕組みを提供し、標準インタフェース２２４の参照インプリメンテーションを提供する。また、サイトコントローラ２４０へのゲートウェイを提供し、且つマルチサイト／ＤＵＴ環境におけるサイトコントローラ２４０の同期を提供するソフトウェア構成要素を構成する。実効的には、フレームワーククラス２２１は、システムコントローラ２２０をサポートするＯＳとしての役割を果たすことができる。
【００４２】
第三者の開発者は、標準システムツール２２２に加えて、又は、標準システムツール２２２に換えて、一以上のツール２２３を提供することができる。システムコントローラ２２０上の標準インタフェース２２４は、テスタ及び試験オブジェクトにアクセスするためにそれらのツールが用いるインタフェースを含む。ツール（アプリケーション）２２２、２２３によって、テスタ及び試験オブジェクトをインタラクティブに、且つバッチで制御できる。また、標準インタフェース２２４は、システムコントローラ２２０上で実行されるフレームワークオブジェクトへのオープンインタフェースや、サイトコントローラ２４０に基づくモジュール・ソフトウェアがパターンデータにアクセスし、それらを検索できるようにするインタフェース等を含む。
【００４３】
システムコントローラ２２０上に存在する通信ライブラリ２３０は、ユーザアプリケーション及び試験プログラムに対してトランスペアレントであるように、サイトコントローラ２４０と通信するための仕組みを提供する。
【００４４】
サイトコントローラ２４０は、試験機能の大部分が提供される。サイトコントローラ２４０は、テストプラン（試験プログラム）２４１と、試験クラス２４２と、サイトコントローラフレームワーククラス２４３と、特定モジュール拡張インタフェース２４４と、標準インタフェース２４５と、モジュール・ソフトウェア・インプリメンテーション２４６と、バックプレーン通信ライブラリ２４７と、バックプレーンドライバ２４８とを含む。
【００４５】
テストプラン２４１はユーザによって記述される。テストプランプログラムは、Ｃ＋＋のようなオブジェクト指向コンポーネントを用いて、標準的なコンピュータ言語において直に記述するか、又は、Ｃ＋＋コードを生成するための、さらに高いレベルの試験プログラミング言語において記述することができ、後に実行可能な試験プログラムにコンパイルすることができる。
【００４６】
テストプラン２４１は、標準的な又はユーザによって供給される試験クラス２４２及び／又はそのサイトコントローラ２４０に関連するフレームワーククラス２４３を用いることにより試験オブジェクトを作成し、標準インタフェース２４５を用いてハードウェアを構成し、テストプランフローを規定する。テストプランはいくつかの基本的なサービスをサポートし、デバッグサービス（たとえば、ブレークポイント生成）のような、下層のオブジェクトのサービスへのインタフェースを提供し、下層のフレームワーク及び標準クラスにアクセスできるようにする。
【００４７】
試験クラス２４２は、標準試験インタフェースの１つのインプリメンテーションであり、テストプランプログラムにおいて指定される。各試験クラスは通常、特定のタイプのデバイス試験、又はデバイス試験のための設定を実装する。
【００４８】
フレームワーククラス２４３は、共通の試験関連動作を実装する１組のクラス及びメソッドである。フレームワーククラス２４３は、実効的には、各サイトコントローラ２４０をサポートするローカルＯＳとしての役割を果たすことができる。
【００４９】
モジュール・ソフトウェアは、テストの実行時に必要に応じて動的に試験システム１００のプロセスにロードできるように、ＤＬＬ（Dynamic Link Library）形式であることが望ましい。これは、テストプラン２４１が指定する試験サイト１１０の構成に応じて、試験システム１００が実行時に動的に制御対象のモジュール２６１を決定するからである。また、全てのモジュール・ソフトウェアは、モジュール２６１の機能に応じて、システムＯＳが規定するモジュール・ソフトウェアの標準インタフェース２４５を実装することが求められる。
【００５０】
特定モジュール拡張インタフェース２４４は、必要に応じてモジュール固有のより複雑で専門的な機能を持つインタフェース階層をモジュール・ソフトウェアに付加して実装する。例えば、Ｃ＋＋では、標準インタフェース２４５を継承するインタフェースクラスをモジュール・ソフトウェアで定義することによって、インタフェースを拡張することができる。
【００５１】
標準インタフェース２４５は、システムフレームワークが規定する必要最小限の、一般的で普遍的に適用可能なインタフェースである。標準インタフェース２４５を用いて、全てのオブジェクトを画一的に扱うことができる。これにより、システムＯＳを変更することなく、新しいモジュールのソフトウェアをシームレスに、プラグ・アンド・プレイ方式でシステムに導入することが可能となる。
【００５２】
一例として、標準インタフェース２４５は、Ｃ＋＋の純粋仮想インタフェースクラスとして定義される。このとき、ユーザ向けの機能を定義するサブクラスと、システムだけが使用する機能を定義するサブクラスと、リソースの機能を定義するサブクラスとによって構成されることが好ましい。また、標準インタフェース２４５の階層は、モジュールの最も基本的な機能を定義する階層、パターン・プログラムを実行する機能を持つモジュールを表現する階層、複数のピン間で共有されるテスト周期という概念を導入する階層、デジタル・モジュール特有の機能を加える階層、の４階層により構成されることが好ましい。このとき、各モジュール・ドライバは、モジュールの機能に応じて、４階層のインタフェースのいずれかを実装する。しかし、標準インタフェース２４５の構成は、これらの構成に限定されるものではない。
【００５３】
バックプレーン通信ライブラリ２４７は、バックプレーンにわたる標準的な通信のためのインタフェースを提供し、それによりテストヘッド２６０内のモジュール１０８と通信するために必要な機能を提供する。これにより、ベンダ固有のモジュール・ソフトウェアが、バックプレーンドライバ２４８を用いて、対応するモジュール１０８と通信できる。バックプレーン通信プロトコルはパケットに基づくフォーマットを用いることができる。
【００５４】
テストヘッド２６０は、デバイスに対する測定機能が提供される。テストヘッド２６０は、モジュール２６１と、ＴＩＵ２６２と、ロードボード２６３と、ＤＵＴ２６４とを含む。
【００５５】
また、ソフトウェア・アーキテクチャ２００は、ソフトウェアの名目的な供給元に基づいて、システムフレームワーク２９０、ユーザコンポーネント２９２、テスタオペレーティングシステム２９４、モジュール・ハードウェア・ベンダコンポーネント２９６、及び、ツール・ソフトウェア・ベンダコンポーネント２９８に分類することができる。
【００５６】
システムフレームワーク２９０は、試験システム１００の開発ベンダにより供給され、フレームワーククラス２２１と、標準インタフェース２２４と、フレームワーククラス２４３と、標準インタフェース２４５と、バックプレーン通信ライブラリ２４７とを含む。
【００５７】
ユーザコンポーネント２９２は、試験を実施するユーザによって供給され、テストプラン２４１と、テストクラス２４２と、ロードボード２６３と、ＤＵＴ２６４とを含む。
【００５８】
テスタオペレーティングシステム２９４は、基本的な接続性及び通信のためのソフトウェアインフラストラクチャとして供給され、システムツール２２２と、通信ライブラリ２３０と、バックプレーンドライバ２４８とを含む。
【００５９】
モジュール・ハードウェア・ベンダコンポーネント２９６は、モジュール１０８の開発元によって供給され、特定モジュール拡張インタフェース２４４と、モジュール・ソフトウェア・インプリメンテーション２４６と、モジュール２６１と、ＴＩＵ２６２を含む。
【００６０】
ツール・ソフトウェア・ベンダコンポーネント２９８は、外部ツールの開発元によって供給され、外部ツール２２３を含む。
【００６１】
次に、図２に示すハードウェアの概略構成に基づいて、各種設定ファイルについて具体的に説明する。
【００６２】
図４は、ＭＣＦ１３０の一例を示す図である。図４に示すＭＣＦ１３０は、図２に示すハードウェア概略構成を記述した場合の例である。「Resource」キーワードの後に続く「OAI.Digital.dpin」はリソース・タイプの名前である。また、バス１０７のポート番号とリソースＩＤの組は、「Ｐ（ポート番号）．（リソースＩＤ）」という形式（例えば、「P8.1」）で表記される。
【００６３】
図５は、ソケットファイル１１８の一例を示す図である。図５に示すように、本実施形態における試験システム１００では、ソケットファイル１１８によって各サイトコントローラ１０４に接続するモジュール１０８と各試験サイト１１０の構成が決定され、それに従ってモジュール接続イネーブラ１０６を再構成することで、サイトコントローラ１０４とモジュール１０８間のバス１０７の接続とモジュール１０８の制御が確立される。このようなモジュール構成の表現方式とバス構成の自由度の高さは、システムのモジュラリティとスケーラビリティの確保に大きく貢献し、モジュール１０８のプラグ・アンド・プレイの実現を支える。
【００６４】
図６は、リソース定義ファイルの一例として、図２に示すリソース・タイプ「ＯＡＩ．Ｄｉｇｉｔａｌ．ｄｐｉｎ」の定義の一部を示す図である。図６に示すように、リソースの属性は、型と属性名の対で指定される。例えば、図６において、「ＶＩＨ」という属性は、「Ｖｏｌｔａｇｅ」という型を持つ。リソースの属性に対する設定値は、例えば、「属性名＝値」という形で指定される。このように、モジュール１０８のハードウェアに強く依存するリソースの機能を、名前と型という極めて一般性のある表現形式で扱うことにより、ベンダは自由にリソースの機能を表現することができ、また、システムフレームワークは、モジュール１０８の機能に依存せずにリソースを画一的に扱うことが可能になる。これにより、システムの高い適用性と柔軟性が実現される。
【００６５】
次に、以上のように構成される試験システム１００を用いたモジュール間通信について説明する。
【００６６】
本試験システム１００は、各モジュール１０８が独立に制御されることを前提に仕様が構成されていて、モジュール間の横のつながりには対応していない。しかし、他のモジュールが存在して初めて機能するモジュールもある。このようなモジュールは他のモジュールに依存しているということができる。例えば、あるモジュールＡが他のモジュールと同期して機能する必要があり、この同期が特定のモジュールＢが提供する機能によって実現されるとき、このモジュールＸの同期は、モジュールＹに依存しているといえる。また、新たに開発したモジュールＺが、既存のモジュールＷの提供するコマンドやライブラリを利用するとき、このモジュールＺは、モジュールＷに依存しているといえる。
【００６７】
このように、あるモジュール（依存モジュール）が別のモジュール（被依存モジュール）に依存している場合に対応するためには、試験システム１００において、モジュール間でコマンド等を通信できるような仕組みが必要となる。このとき、モジュール間で任意に通信を認める仕様も考えられるが、あるモジュールが別のモジュールに悪影響を与える可能性もあるため、無限定にモジュール間通信を行うと、システムの安全性を担保できない。これに対して、本試験システム１００では、モジュール間通信にシステムを介在させることにより、安全性を担保している。すなわち、本試験システム１００では、システムとして許されたモジュール間でのみ通信できるように制限することによって、システム全体としての動きを保証している。
【００６８】
図７は、本実施形態に係るモジュール間通信処理を行う際の概略構成を示すブロック図である。同図は、ベンダＡが提供するモジュールＡ １０８ａと、ベンダＢが提供するモジュールＢ １０８ｂとの間で、モジュール間通信を行う場合を例示する。
【００６９】
図７に示すように、本試験システム１００においてモジュール間通信を行う場合には、ＭＣＦ１３０内に、モジュール間通信設定部１４０を加える。このモジュール間通信設定部１４０で定義された内容に基づいて、モジュール間の通信方法とモジュール間の依存関係とが設定される。図７に示す例では、モジュール間通信設定部１４０にて、モジュールＡとモジュールＢとの間で通信が行われ、かつ、モジュールＡがモジュールＢに依存することが定義されている。
【００７０】
一方、サイトコントローラ１０４は、ＭＣＦ１３０内にモジュール間通信設定部１４０が含まれるとき、ＭＣＦ解釈部が、モジュール間通信設定部１４０で定義された内容に基づいて、配送器１５０を生成する。この配送器１５０は、モジュール間通信用のインタフェース１５２を提供するものであり、例えば、モジュール間通信専用のオブジェクトとして構成される。そして、配送器１５０を利用することにより、モジュール間でダイレクトなピア・トゥ・ピアによる通信が、ソフトウェア的に実現される。図７に示す例では、モジュールＡ １０８ａから配送器１５０にコマンド等を送信すると、配送器１５０からモジュールＢ １０８ｂに当該コマンド等が配送される。こうして、モジュールＡ １０８ａとモジュールＢ １０８ｂとの間で、高速な通信インタフェース１５２が提供される。
【００７１】
なお、各モジュール１０８は、通信可能な相手先モジュールの情報（以下「通信可能相手情報」という。）を保有している。例えば、モジュールＡ １０８ａは、ベンダＢのモジュールＢ １０８ｂと通信可能である、といった通信可能相手情報を保有している。モジュール１０８を試験システム１００に組み込む（インテグレーション）と、モジュール１０８が有する通信可能相手情報に基づいて、ＭＣＦ１３０に、モジュール間の通信方法及び依存関係等が書き加えられる。また、依存関係は一方向であることが好ましい。双方向にすると、システムの動作が保証されない。
【００７２】
図８は、本実施形態に係るモジュール間通信処理の流れを示すフローチャートである。まず、試験システム１００に新たにモジュール１０８が組み込まれると（Ｓ３０１）、モジュール１０８の通信可能相手情報に基づいて、試験システム１００は、ＭＣＦ１３０内のモジュール間通信設定部１４０に、新たに追加されたモジュールに関する通信方法及び依存関係を書き加える（Ｓ３０２）。さらに、試験システム１００は、ＭＣＦ１３０が変更された後、ＭＣＦ１３０内のモジュール間通信設定部１４０に定義された内容に基づいて、モジュール間通信を行うための配送器１５０を生成する（Ｓ３０３）。
【００７３】
この配送器１５０がモジュール間通信を行う際のインタフェースを提供する。これにより、配送器１５０が生成された後、モジュール１０８は、配送器１５０を介して他のモジュールとの間で通信を行うことにより、ソフトウェア的にダイレクトに通信をおこなうことができる（Ｓ３０４）。
【００７４】
次に、モジュール間通信処理を実装するための具体的な実施例を示す。
【００７５】
試験システム１００は、モジュール間通信のために、ＩＭＣ（IModuleCommunication）とＩＭＣＤ（IModuleCommunicationDispatcher）の二つのインタフェースを提供する。ＩＭＣは、モジュール１０８が他のモジュールに対して所定の機能を提供する必要のあるときに、モジュール１０８が実装する必要のあるインタフェースクラスである。ＩＭＣＤは、モジュール間通信を実現するために、システム実装をモジュールに公表するためのインタフェースクラスである。
【００７６】
図９は、ＩＭＣ及びＩＭＣＤインタフェースクラスの関係を示す図である。同図において、「コマンド」は、モジュール・ソフトウェアＸ（以下、単に「モジュールＸ」という。）からモジュール・ソフトウェアＹ（以下、単に「モジュールＹ」という。）への要求を表す。モジュールＹはコマンドを提供し、このコマンドはモジュールＹによって提供される特定の機能を表す。モジュールＸがモジュールＹの機能を実行しようとする場合、モジュールＸは、ＩＭＣＤを通して、この機能に対応するコマンドをモジュールＹに送る。モジュールＹは要求されたコマンドを受信し、サービスとしてこのコマンドに対応する機能を実行し、この機能の結果を返す。
【００７７】
なお、ＩＭＣに関して、モジュールは、一つのインスタンスだけを実装可能であり、複数のインスタンスを実装できない。また、他のモジュールからコマンドを受け取らないモジュールはＩＭＣを実装しなくてよい。フレームワークは、所定のヘッダファイル内でＩＭＣインタフェースの定義を提供する。このインタフェースの実装は、クライアントモジュールに過度の依存関係を強制することになるので、具体的なクラスや構造が定義された如何なる実装にも依存しないことが好ましい。例えば、モジュールが内部データの表現の定義を変更した場合、当該モジュールに依存する全てのモジュールは、リコンパイルして新しくリリースする必要がある。
【００７８】
また、ＩＭＣＤは、所定のモジュールからコマンドを受信し、適切なモジュールにそのコマンドを送るという配送器１５０としての機能を提供するものであり、通信の方向が認められるか否かを認証する。フレームワークは、所定のヘッダファイルの中で、ＩＭＣＤインタフェースの定義を提供する。
【００７９】
図１０は、ＩＭＣ及びＩＭＣＤインタフェースクラスを利用したモジュール間通信処理の流れを示すフローチャートである。ここでは、二つのモジュールＸとモジュールＹを想定する。図９に示すように、モジュールＸはモジュールＹとの通信を要する。このとき、モジュールＸ用のドライバは、フレームワークによって生成されたモジュールＸと通信するための所定のオブジェクトとデータを取得する。ここで、フレームワークは、モジュール間通信を確立するために、次のようにモジュール間を仲介する。
【００８０】
まず、全てのモジュール・ドライバのＤＬＬがサイトコントローラ１０４にロードされた後、フレームワークはモジュール・ドライバによって生成された全てのモジュールからＩＭＣオブジェクトを検索する（Ｓ３１１）。
【００８１】
その後、全てのＩＭＣオブジェクトは、フレームワークによって生成されたモジュール間通信管理部に登録され、全てのＩＭＣオブジェクトに対して、各ＩＭＣオブジェクトを一意に識別可能な識別番号が付与される（Ｓ３１２）。
【００８２】
それから、フレームワークは、ＭＣＦ１３０に記述されたモジュール間通信方法及び依存関係に従って、ＩＭＣＤポインタと各モジュールを一意に識別可能な識別子とを割り当てる（Ｓ３１３）。ＩＭＣＤは、フレームワークによって生成されるものであり、モジュールがフレームワークを介して他のモジュールと通信できるようにするためのインタフェースである。そして、ＩＭＣＤは、所定のモジュールが他のモジュールと通信する際に、フレームワークによって所定のモジュールに配送される（Ｓ３１４）。
【００８３】
図１１は、割り当てるメソッドの一例を示す図である。同図において、「ｓｅｎｄｅｒ」は、コマンドを送ったモジュールを区別するためにフレームワークによって決定されるＩＤである。「ｒｅｃｅｉｖｅｒｓ」は、他のモジュールと通信するためのＩＤである。
【００８４】
また、所定のモジュール（例えば、モジュールＸ）において、当該モジュールＸと通信できるよう設定されている他の全てのモジュールとの通信を認めるためのキーワードを備えることが好ましい。すなわち、モジュールは、他のモジュールによって提供されるモジュール特有の通信オブジェクトを利用可能である。
【００８５】
以上のように、本試験システム１００では、ＭＣＦ１３０内のモジュール間通信設定部１４０にモジュール間の通信方法及び依存関係を規定し、当該モジュール間通信設定部１４０に規定された内容に基づいて、モジュール間通信を行うための配送器１５０を生成することにより、依存関係のあるモジュール間通信を実現している。
【００８６】
また、本試験システム１００では、任意モジュール間での通信を認めず、システムにより認められたモジュール間でのみ通信できることに特徴を有する。これにより、システム全体の安全性を担保している。さらに、本試験システム１００では、モジュール間通信の設定情報をＭＣＦ１３０内で定義している。このように、モジュール間通信の設定情報をシステムＯＳの外部に持たせることにより、モジュール間通信の設定のためのリコンパイル等が不要になり、柔軟にシステムを運用できる。加えて、他のベンダのモジュールに依存しなくても、開発やシステムへの組み込みができる環境を提供することにより、開発環境でも独立性を維持できる。さらに、ソフトウェア的にダイレクトなモジュール間通信を行うことにより、高速な通信を実現している。これらの特徴は、特に、オープン・アーキテクチャＡＴＥの場合に有効である。
【００８７】
なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【図面の簡単な説明】
【００８８】
【図１】本発明の一実施形態による試験システム１００のシステムアーキテクチャを示す。
【図２】試験サイト１１０及びロードボード１１４のハードウェアの概略構成と各種設定用ファイルとの関係の一例を示す図である。
【図３】試験システム１００のソフトウェア・アーキテクチャ２００の一例を示す。
【図４】モジュール設定ファイル（ＭＣＦ）１３０の一例を示す図である。
【図５】ソケットファイル１１８の一例を示す図である。
【図６】リソース定義ファイルの一例として、図２に示すリソース・タイプ「ＯＡＩ．Ｄｉｇｉｔａｌ．ｄｐｉｎ」の定義の一部を示す図である。
【図７】モジュール間通信処理を行う際の概略構成を示すブロック図である。
【図８】本実施形態に係るモジュール間通信処理の流れを示すフローチャートである。
【図９】ＩＭＣ及びＩＭＣＤインタフェースクラスの関係を示す図である。
【図１０】ＩＭＣ及びＩＭＣＤインタフェースクラスを利用したモジュール間通信処理の流れを示すフローチャートである。
【図１１】割り当てるメソッドの一例を示す図である。
【符号の説明】
【００８９】
１００ 試験システム
１０２ システムコントローラ
１０４ サイトコントローラ
１０６ モジュール接続イネーブラ
１０７ バス
１０８ モジュール
１１０ 試験サイト
１１２ 被試験デバイス（ＤＵＴ）
１１４ ロードボード
１１８ ソケットファイル
１２０ ソケット
１２２ ピン
１２４ コネクタピン
１２６ テスタ・インタフェース・ユニット（ＴＩＵ）
１２８ ピン
１３０ モジュール設定ファイル（ＭＣＦ）
１３２ テストヘッド
１４０ モジュール間通信設定部
１５０ 配送器
【技術分野】
【０００１】
本発明は自動試験装置の技術分野に関する。特に、本発明は、各モジュールが独立に制御されることを前提とする自動試験装置におけるモジュール間通信技術に関する。
【背景技術】
【０００２】
従来、自動試験装置（以下「ＡＴＥ」という。）は、ＡＴＥメーカー各社各様の仕様で提供されていたため、ピン構成や測定ユニット等の構成の自由度が低く、また、試験プログラム資産の再利用が困難であった。このような背景から、デバイスの機能に応じて最適な構成にシステムを変更できるようなスケーラブルで柔軟なＡＴＥを実現すべく、標準化されたインタフェースを持つオープン・アーキテクチャＡＴＥが提案されている。
【０００３】
例えば、ＯＰＥＮＳＴＡＲ（登録商標）は、このようなオープン・アーキテクチャＡＴＥの規格の一つである（非特許文献１参照）。ＯＰＥＮＳＴＡＲシステムは、スケーラブルでかつ柔軟なモジュラー構造のＡＴＥプラットフォームを提供することを目的とし、そのための標準規格を定めている。サード・ベンダ等が提供する計測機器（モジュール）は、ＯＰＥＮＳＴＡＲ標準が定めるハードウェアとソフトウェアの要件を満たすことで、ＯＰＥＮＳＴＡＲシステムに組み込むことが可能である。
【非特許文献１】「Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｔｅｓｔ Ｃｏｎｓｏｒｔｉｕｍ」、［online］、［平成２０年３月２４日検索］、インターネット＜ＵＲＬ：http://www.semitest.org/jp/home＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、オープン・アーキテクチャの定める標準規格（仕様）では、ＡＴＥのプラットフォームやモジュールの実装に必要な全てを規定しているわけではなく、必要最小限の要件を定めている。しかし、実際にモジュールを設計してＡＴＥシステム内に組み込むには、モジュールの実装に依存した標準ではない機能が必要となる場合がある。とりわけ、異なるベンダのモジュール同士が専用のバスで接続されるような関係を持つ場合には、モジュール単位で区切り、独立に制御されることを前提とするＯＰＥＮＳＴＡＲ規格のようなオープン・アーキテクチャでは解決できない問題が発現する。
【０００５】
例えば、デジタル・モジュール間の同期を実現するモジュール（以下「Ｓｙｎｃモジュール」という。）は、デジタル・モジュールと専用のバスで接続される。しかし、Ｓｙｎｃモジュールの実装手法はベンダにより異なり、その専用バスの制御のためにはハードウェアの実装に依存した機能が必要となる。例えば、システム全体のデジタル・ピンのタイミングの同期をとるために、異なるデジタル・モジュール間の伝播遅延量（Ｔｐｄ）の差の吸収する機能を持つようなＳｙｎｃモジュールでは、それを機能させるには各モジュールからＴｐｄ値を収集する必要がある。そのためには、Ｓｙｎｃモジュールの制御ソフトウェアは、デジタル・モジュールの制御ソフトウェアと通信する必要がある。しかし、この機能はＳｙｎｃモジュールの実装に依存するところであり、その制御のためのソフトウェアのインタフェースは、ＯＰＥＮＳＴＡＲ規格のように各モジュールが独立に制御されることを前提とする仕様のＡＴＥでは扱えない。
【０００６】
本発明は、かかる事情に鑑みてなされたものであり、本発明に係る幾つかの態様は、モジュール同士が安全かつ信頼できる方法で通信するための仕組みを提供することを目的とする。特に、各モジュールが独立に制御されることを前提とするＡＴＥの定める標準仕様では扱えないモジュールの実装依存の領域に対しても高い拡張性と柔軟性を備える試験システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明による試験システムは、被試験デバイスに試験信号を供給可能なモジュールを複数組み込み可能な試験システムであって、所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を備える。この配送器は、所定の二つのモジュールのうち一のモジュールから受信した信号を、所定の二つのモジュールのうち他のモジュールへ配送する機能を備える。
【０００８】
また、好適には、試験システムは、モジュールの接続関係を設定するためのモジュール設定ファイルを備え、試験システムは、モジュール設定ファイルに規定された内容に基づいて、配送器を生成する。
【０００９】
さらに好適には、モジュール設定ファイルは、所定の二つのモジュール間の通信方法及び依存関係を設定するモジュール間通信設定部を含み、試験システムは、モジュール間通信設定部に規定された通信方法及び依存関係に基づいて、所定の二つのモジュール間の通信インタフェースとして機能する配送器を生成する。
【００１０】
また、好適には、モジュールは、通信可能な相手先モジュールの情報を備え試験システムは、モジュールが試験システムに組み込まれたときに、情報に基づいて、モジュール間通信設定部に規定される内容を書き換える。
【００１１】
さらに好適には、試験システムは、二以上のモジュールの各々を独立に制御することを前提とするものである。また、試験システムは、オープン・アーキテクチャに基づくシステムであり、二以上のモジュールは、オープン・アーキテクチャの標準仕様に準拠するものであることが好ましい。
【００１２】
また、本発明に係るモジュール間通信方法は、被試験デバイスに試験信号を供給可能なモジュールを二以上組み込み可能な試験システムにおいて、所定の二つのモジュール間で通信を行う方法である。そして、モジュールの接続関係を設定するためのモジュール設定ファイルに規定された内容に基づいて、所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を生成するステップと、配送器を介して、所定の二つのモジュールのうち一のモジュールから受信した信号を、所定の二つのモジュールのうち他のモジュールへ配送することにより、モジュール間通信を行うステップと、を備える。
【００１３】
本発明のプログラムは、本発明のモジュール間通信方法の各処理ステップをコンピュータに実行させることを特徴とする。本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
【００１４】
なお、本明細書等において、「手段」又は「部」とは、単に物理的手段を意味するものではなく、その手段又は部が有する機能をソフトウェアによって実現する場合も含む。また、１つの手段又は部が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段又は部の機能が１つの物理的手段により実現されてもよい。
【００１５】
また、本明細書等において、ベンダ等が提供する計測機器のハードウェアを「モジュール」といい、そのハードウェアを対象とするベンダ等のソフトウェアを「モジュール・ソフトウェア」と呼ぶ。
【００１６】
さらに、再構成可能なオープン・アーキテクチャＡＴＥは、試験システムに対する操作の統一だけでなく、目的の試験に最適なモジュールを、モジュール・ソフトウェアとともに、ユーザ自身が既存のシステムにプラグ・アンド・プレイ方式で導入可能なプラットフォームを提供する。また、モジュールのベンダに対しては、そのようなモジュール・ソフトウェアを開発するための開発環境を提供する。
【発明の効果】
【００１７】
本発明の試験システムによれば、モジュール・ソフトウェア同士が安全かつ信頼できる方法で通信するための仕組みを提供することができる。特に、各モジュールが独立に制御されることを前提とするＡＴＥの定める標準仕様では扱えないモジュールの実装依存の領域に対しても高い拡張性と柔軟性を備える試験システムを提供することができる。
【００１８】
例えば、本発明により、Ｓｙｎｃモジュールがデジタル・モジュールに対して、必要な通信のインタフェースを規定することができる。本発明に係る試験システムでは、モジュールの実装依存の問題をベンダ自身で解決できる仕組みを提供することで、このような問題がある場合にも、システムＯＳ（オペレーティング・システム）を変更することなくモジュールをシステムに組み込むことが可能になる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態について詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。また、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。さらに、本発明は、その要旨を逸脱しない限り、さまざまな変形及び応用が可能である。
【００２０】
図１は、本発明の一実施形態による試験システム１００のシステムアーキテクチャを示す。試験システム１００は、試験信号を生成して被試験デバイス（Device under Test。以下「ＤＵＴ」という。）１１２に供給し、ＤＵＴ１１２が試験信号に基づいて動作した結果出力する結果信号が期待値と一致するか否かに基づいてＤＵＴ１１２の良否を判断する。なお、本実施形態に係る試験システム１００は、オープン・アーキテクチャにより実現されるものとして説明するが、本発明は、オープン・アーキテクチャの試験システムに限定されるものではない。
【００２１】
本実施形態では、システムコントローラ（ＳｙｓＣ）１０２がネットワークを介して複数のサイトコントローラ（ＳｉｔｅＣ）１０４に接続される。システムコントローラ１０２は、エンド・ユーザが通常作業を行うホストコンピュータであり、試験システム１００全体を管理する役割を果たす。また、システムコントローラ１０２は、サイトコントローラ１０４に対する処理の要求の発行や、サイトコントローラ１０４間の処理の調停を行う。ユーザのアプリケーションや標準のＧＵＩツールは、システムコントローラ１０２上で動作し、サイトコントローラ１０４と通信を行って機能を実現する。
【００２２】
また、システムコントローラ１０２は、サイトコントローラ１０４上でモジュール１０８の制御を行うモジュール・ソフトウェアや、ユーザの試験プログラムやパターン・プログラムなどを保管するストレージを備える。これらは、必要に応じてサイトコントローラ１０４に送られ、実行される。
【００２３】
各サイトコントローラ１０４は、試験サイト１１０に配置される１つ又は複数のモジュール１０８を制御して試験を実行するために、モジュール接続イネーブラ１０６を通して、モジュール１０８に接続される。この試験は、ユーザの作成する試験プログラムに基づいて実行される。なお、サイトコントローラ１０４は、一つのＤＵＴ１１２を試験する試験サイト１１０を複数個、同時に制御するようにしてもよい。
【００２４】
サイトコントローラ１０４の主な役割として、次の３つが挙げられる。まず、試験プログラムが指定する試験サイト１１０の構成に従い、モジュール接続イネーブラ１０６を構成し、サイトコントローラ１０４とモジュール１０８間のバス１０７の接続を確立する。また、試験サイト１１０内のモジュール１０８の制御を行うモジュールソフトウェアを実行する。さらに、試験プログラムを実行し、各試験サイト１１０のＤＵＴ１１２の試験を実行する。
【００２５】
なお、動作環境によっては、システムコントローラ１０２は、サイトコントローラ１０４の動作とは別のＣＰＵ（中央演算装置）上に配置することができる。別法では、システムコントローラ１０２及びサイトコントローラ１０４は、共通のＣＰＵを共有することができる。同様に、各サイトコントローラ１０４は、その専用のＣＰＵ上に配置することができるし、また、同じＣＰＵ内の別個のプロセス又はスレッドとして配置することもできる。
【００２６】
モジュール接続イネーブラ１０６は、サイトコントローラ１０４とモジュール１０８とのバス１０７の接続を任意に構成することのできるスイッチである。モジュール接続イネーブラ１０６は、接続されるハードウェアモジュール１０８の構成を変更できるようにするとともに、データ転送用（パターンデータのロード用、応答データの収集用、制御用等）のバスとしての役割も果たす。実現可能なハードウェアの実装形態は、専用接続、交換接続、バス接続、リング接続及びスター接続を含む。モジュール接続イネーブラ１０６は、たとえばスイッチマトリクスとして実装することができる。
【００２７】
モジュール１０８は、ＤＵＴ１１２に試験信号を供給する計測機器のハードウェアである。本実施形態においては、モジュール１０８として、オープン・アーキテクチャに基づく各種のモジュールを用いることができる。また、モジュール・ハードウェア１０８を動作させるためのソフトウェアをモジュール・ソフトウェアという。モジュール・ソフトウェアは、デバイス測定時にモジュール１０８の制御をつかさどるモジュール・ドライバ、モジュール１０８の校正と診断を行う校正診断ソフトウェア、モジュール１０８の動作をソフトウェアでエミュレートするエミュレーション・ソフトウェア、モジュール１０８固有のパターン・コンパイラ、およびＧＵＩツールなどを含む。
【００２８】
各試験サイト１１０は、それぞれ一つのＤＵＴ１１２に関連付けられる。ＤＵＴ１１２は、ロードボード１１４を通して、対応する試験サイト１１０のモジュール１０８に接続される。
【００２９】
図２は、試験サイト１１０及びロードボード１１４のハードウェアの概略構成と各種設定用ファイルとの関係の一例を示す図である。図２に示すように、モジュール１０８は、試験システム１００のテストヘッド１３２内のモジュール・スロットに差し込まれる。
【００３０】
試験サイト１１０の構成は、テキスト形式で記述されるソケットファイル１１８で指定される。このソケットファイル１１８には、ＤＵＴ１１２ごとに、ＤＵＴソケット１２０のＤＵＴピン１２２とロードボード１１４上のコネクタピン１２４との接続が記述される。コネクタピン１２４は、ブロック番号とコネクタ番号が付けられており、例えば、「１２．３」のように、「（ブロック番号）．（コネクタ番号）」の形式で表記される。ロードボード１１４のコネクタピン１２４は、テスタ・インタフェース・ユニット（Tester Interface Unit。以下「ＴＩＵ」という。）１２６を介してモジュール１０８のピン１２８と接続される。
【００３１】
一方、ロードボード１１４は試験対象となるデバイスによって異なる場合が多い。そのため、モジュール・ソフトウェアが個々のロードボード１１４の実装に依存しないようにするためには、試験システム１００において、モジュール１０８が実装するピン１２８そのものを定義できるようにし、それをもとにモジュール１０８の制御ができるようにしなければならない。本試験システム１００では、これはモジュール設定ファイル（Module Configuration File。以下「ＭＣＦ」という。）１３０によって達成される。
【００３２】
ＭＣＦ１３０には、モジュール１０８のリソースとロードボード１１４のコネクタピン１２４との接続関係が指定される。これにより、論理的なピンの表現であるリソースと、モジュール１０８の物理ピン１２８、さらにはそれが接続されているロードボード１１４のコネクタピン１２４との関係が定められる。ＭＣＦ１３０は、システムだけが設定可能であることが望ましい。
【００３３】
なお、本実施形態において、モジュール１０８の機能は、主にモジュール１０８の全体的な制御に関わる機能を提供するモジュール・オブジェクトと、モジュールのピン毎の機能を提供するリソース・オブジェクトによって表現される。本実施形態に係る試験システム１００では、これらは全て、ＭＣＦ１３０に記述される内容に従って、実際のハードウェアのエンティティと対称に結び付けられる。なお、これらのソフトウェアのオブジェクトを提供するモジュール・ソフトウェアを、ここではモジュール・ドライバと呼ぶ。
【００３４】
また、本実施形態において、リソースとは、試験システム１００のモジュール１０８が備える物理的なピン１２８とその機能とを、オブジェクトで抽象化して表現したものである。モジュール１０８の一つの物理ピン１２８は、一つのリソースとして表現されてもよいし、機能的に分割された複数のリソースとして表現されてもよい。
【００３５】
リソースの機能的な分類はリソース・タイプと呼ばれ、その機能の定義はモジュール１０８のベンダが提供するリソース定義ファイルによって示される。論理的なピンを指すリソースは、リソース・タイプと、モジュール１０８内でピン１２８を特定する番号（リソースＩＤ）と、試験システム１００内でモジュール１０８を特定するバス１０７のポート番号との３つ組で表現される。リソース・タイプとリソースＩＤの組と、それに対応するモジュール１０８内の物理ピン１２８の関係は固定的であるため、リソースが与えられたときに、それを物理的なピン１２８に対応付けることが可能となる。なお、リソースが物理ピン１２８と対応付けられることはアーキテクチャ上必須ではなく、モジュール１０８の持つ機能を仮想的なピンに見立てて表現し、制御することも可能である。
【００３６】
図３は、試験システム１００のソフトウェア・アーキテクチャ２００の一例を示す。ソフトウェア・アーキテクチャ２００は分散オペレーティングシステムを表しており、関連するハードウェアシステム要素１０２、１０４、１０８に対応する、システムコントローラ・ソフトウェア２２０（以下、単に「システムコントローラ２２０」ともいう。）、少なくとも１つのサイトコントローラ・ソフトウェア２４０（以下、単に「サイトコントローラ２４０」ともいう。）及び少なくとも１つのモジュールを含むテストヘッド・ソフトウェア２６０（以下、単に「テストヘッド２６０」ともいう。）のための構成要素を有する。
【００３７】
一つの例示的な選択として、試験システム１００は、ソフトウェアのプラットフォームとしてＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）を使用し、実装言語としてＡＮＳＩ／ＩＳＯ標準Ｃ＋＋を使用することができる。プラットフォームの全てのシステム・インタフェースもまた、Ｃ＋＋のクラスまたはインタフェースとして提供され、ユーザの試験プログラムやモジュール・ソフトウェアはＣ＋＋で実装することができる。
【００３８】
システムコントローラ２２０は、ユーザのための一次的なインタラクションポイントであり、サイトコントローラ２４０へのゲートウェイと、マルチサイト／ＤＵＴ環境におけるサイトコントローラ２４０の同期とを提供する。ユーザアプリケーション及びツールは、グラフィカルユーザインターフェース（ＧＵＩ）に基づくものでも、そうでないものでも、システムコントローラ２２０上で実行される。
【００３９】
また、システムコントローラ２２０は、テストプラン、試験パターン及び試験パラメータファイルを含む、全てのテストプラン関連情報のためのリポジトリとしての役割も果たす。これらのファイルを記憶するメモリは、システムコントローラ２２０に対してローカルに存在することができるか、又は、ネットワークを介してシステムコントローラ２２０に接続されることができる。
【００４０】
さらに、システムコントローラ２２０は、フレームワーククラス２２１と、システムツール２２２と、外部ツール２２３と、サイトコントローラへの標準インタフェース２２４と、通信ライブラリ２３０とを含む。
【００４１】
システムコントローラ２２０に関連するフレームワーククラス２２１は、オブジェクトと対話するための仕組みを提供し、標準インタフェース２２４の参照インプリメンテーションを提供する。また、サイトコントローラ２４０へのゲートウェイを提供し、且つマルチサイト／ＤＵＴ環境におけるサイトコントローラ２４０の同期を提供するソフトウェア構成要素を構成する。実効的には、フレームワーククラス２２１は、システムコントローラ２２０をサポートするＯＳとしての役割を果たすことができる。
【００４２】
第三者の開発者は、標準システムツール２２２に加えて、又は、標準システムツール２２２に換えて、一以上のツール２２３を提供することができる。システムコントローラ２２０上の標準インタフェース２２４は、テスタ及び試験オブジェクトにアクセスするためにそれらのツールが用いるインタフェースを含む。ツール（アプリケーション）２２２、２２３によって、テスタ及び試験オブジェクトをインタラクティブに、且つバッチで制御できる。また、標準インタフェース２２４は、システムコントローラ２２０上で実行されるフレームワークオブジェクトへのオープンインタフェースや、サイトコントローラ２４０に基づくモジュール・ソフトウェアがパターンデータにアクセスし、それらを検索できるようにするインタフェース等を含む。
【００４３】
システムコントローラ２２０上に存在する通信ライブラリ２３０は、ユーザアプリケーション及び試験プログラムに対してトランスペアレントであるように、サイトコントローラ２４０と通信するための仕組みを提供する。
【００４４】
サイトコントローラ２４０は、試験機能の大部分が提供される。サイトコントローラ２４０は、テストプラン（試験プログラム）２４１と、試験クラス２４２と、サイトコントローラフレームワーククラス２４３と、特定モジュール拡張インタフェース２４４と、標準インタフェース２４５と、モジュール・ソフトウェア・インプリメンテーション２４６と、バックプレーン通信ライブラリ２４７と、バックプレーンドライバ２４８とを含む。
【００４５】
テストプラン２４１はユーザによって記述される。テストプランプログラムは、Ｃ＋＋のようなオブジェクト指向コンポーネントを用いて、標準的なコンピュータ言語において直に記述するか、又は、Ｃ＋＋コードを生成するための、さらに高いレベルの試験プログラミング言語において記述することができ、後に実行可能な試験プログラムにコンパイルすることができる。
【００４６】
テストプラン２４１は、標準的な又はユーザによって供給される試験クラス２４２及び／又はそのサイトコントローラ２４０に関連するフレームワーククラス２４３を用いることにより試験オブジェクトを作成し、標準インタフェース２４５を用いてハードウェアを構成し、テストプランフローを規定する。テストプランはいくつかの基本的なサービスをサポートし、デバッグサービス（たとえば、ブレークポイント生成）のような、下層のオブジェクトのサービスへのインタフェースを提供し、下層のフレームワーク及び標準クラスにアクセスできるようにする。
【００４７】
試験クラス２４２は、標準試験インタフェースの１つのインプリメンテーションであり、テストプランプログラムにおいて指定される。各試験クラスは通常、特定のタイプのデバイス試験、又はデバイス試験のための設定を実装する。
【００４８】
フレームワーククラス２４３は、共通の試験関連動作を実装する１組のクラス及びメソッドである。フレームワーククラス２４３は、実効的には、各サイトコントローラ２４０をサポートするローカルＯＳとしての役割を果たすことができる。
【００４９】
モジュール・ソフトウェアは、テストの実行時に必要に応じて動的に試験システム１００のプロセスにロードできるように、ＤＬＬ（Dynamic Link Library）形式であることが望ましい。これは、テストプラン２４１が指定する試験サイト１１０の構成に応じて、試験システム１００が実行時に動的に制御対象のモジュール２６１を決定するからである。また、全てのモジュール・ソフトウェアは、モジュール２６１の機能に応じて、システムＯＳが規定するモジュール・ソフトウェアの標準インタフェース２４５を実装することが求められる。
【００５０】
特定モジュール拡張インタフェース２４４は、必要に応じてモジュール固有のより複雑で専門的な機能を持つインタフェース階層をモジュール・ソフトウェアに付加して実装する。例えば、Ｃ＋＋では、標準インタフェース２４５を継承するインタフェースクラスをモジュール・ソフトウェアで定義することによって、インタフェースを拡張することができる。
【００５１】
標準インタフェース２４５は、システムフレームワークが規定する必要最小限の、一般的で普遍的に適用可能なインタフェースである。標準インタフェース２４５を用いて、全てのオブジェクトを画一的に扱うことができる。これにより、システムＯＳを変更することなく、新しいモジュールのソフトウェアをシームレスに、プラグ・アンド・プレイ方式でシステムに導入することが可能となる。
【００５２】
一例として、標準インタフェース２４５は、Ｃ＋＋の純粋仮想インタフェースクラスとして定義される。このとき、ユーザ向けの機能を定義するサブクラスと、システムだけが使用する機能を定義するサブクラスと、リソースの機能を定義するサブクラスとによって構成されることが好ましい。また、標準インタフェース２４５の階層は、モジュールの最も基本的な機能を定義する階層、パターン・プログラムを実行する機能を持つモジュールを表現する階層、複数のピン間で共有されるテスト周期という概念を導入する階層、デジタル・モジュール特有の機能を加える階層、の４階層により構成されることが好ましい。このとき、各モジュール・ドライバは、モジュールの機能に応じて、４階層のインタフェースのいずれかを実装する。しかし、標準インタフェース２４５の構成は、これらの構成に限定されるものではない。
【００５３】
バックプレーン通信ライブラリ２４７は、バックプレーンにわたる標準的な通信のためのインタフェースを提供し、それによりテストヘッド２６０内のモジュール１０８と通信するために必要な機能を提供する。これにより、ベンダ固有のモジュール・ソフトウェアが、バックプレーンドライバ２４８を用いて、対応するモジュール１０８と通信できる。バックプレーン通信プロトコルはパケットに基づくフォーマットを用いることができる。
【００５４】
テストヘッド２６０は、デバイスに対する測定機能が提供される。テストヘッド２６０は、モジュール２６１と、ＴＩＵ２６２と、ロードボード２６３と、ＤＵＴ２６４とを含む。
【００５５】
また、ソフトウェア・アーキテクチャ２００は、ソフトウェアの名目的な供給元に基づいて、システムフレームワーク２９０、ユーザコンポーネント２９２、テスタオペレーティングシステム２９４、モジュール・ハードウェア・ベンダコンポーネント２９６、及び、ツール・ソフトウェア・ベンダコンポーネント２９８に分類することができる。
【００５６】
システムフレームワーク２９０は、試験システム１００の開発ベンダにより供給され、フレームワーククラス２２１と、標準インタフェース２２４と、フレームワーククラス２４３と、標準インタフェース２４５と、バックプレーン通信ライブラリ２４７とを含む。
【００５７】
ユーザコンポーネント２９２は、試験を実施するユーザによって供給され、テストプラン２４１と、テストクラス２４２と、ロードボード２６３と、ＤＵＴ２６４とを含む。
【００５８】
テスタオペレーティングシステム２９４は、基本的な接続性及び通信のためのソフトウェアインフラストラクチャとして供給され、システムツール２２２と、通信ライブラリ２３０と、バックプレーンドライバ２４８とを含む。
【００５９】
モジュール・ハードウェア・ベンダコンポーネント２９６は、モジュール１０８の開発元によって供給され、特定モジュール拡張インタフェース２４４と、モジュール・ソフトウェア・インプリメンテーション２４６と、モジュール２６１と、ＴＩＵ２６２を含む。
【００６０】
ツール・ソフトウェア・ベンダコンポーネント２９８は、外部ツールの開発元によって供給され、外部ツール２２３を含む。
【００６１】
次に、図２に示すハードウェアの概略構成に基づいて、各種設定ファイルについて具体的に説明する。
【００６２】
図４は、ＭＣＦ１３０の一例を示す図である。図４に示すＭＣＦ１３０は、図２に示すハードウェア概略構成を記述した場合の例である。「Resource」キーワードの後に続く「OAI.Digital.dpin」はリソース・タイプの名前である。また、バス１０７のポート番号とリソースＩＤの組は、「Ｐ（ポート番号）．（リソースＩＤ）」という形式（例えば、「P8.1」）で表記される。
【００６３】
図５は、ソケットファイル１１８の一例を示す図である。図５に示すように、本実施形態における試験システム１００では、ソケットファイル１１８によって各サイトコントローラ１０４に接続するモジュール１０８と各試験サイト１１０の構成が決定され、それに従ってモジュール接続イネーブラ１０６を再構成することで、サイトコントローラ１０４とモジュール１０８間のバス１０７の接続とモジュール１０８の制御が確立される。このようなモジュール構成の表現方式とバス構成の自由度の高さは、システムのモジュラリティとスケーラビリティの確保に大きく貢献し、モジュール１０８のプラグ・アンド・プレイの実現を支える。
【００６４】
図６は、リソース定義ファイルの一例として、図２に示すリソース・タイプ「ＯＡＩ．Ｄｉｇｉｔａｌ．ｄｐｉｎ」の定義の一部を示す図である。図６に示すように、リソースの属性は、型と属性名の対で指定される。例えば、図６において、「ＶＩＨ」という属性は、「Ｖｏｌｔａｇｅ」という型を持つ。リソースの属性に対する設定値は、例えば、「属性名＝値」という形で指定される。このように、モジュール１０８のハードウェアに強く依存するリソースの機能を、名前と型という極めて一般性のある表現形式で扱うことにより、ベンダは自由にリソースの機能を表現することができ、また、システムフレームワークは、モジュール１０８の機能に依存せずにリソースを画一的に扱うことが可能になる。これにより、システムの高い適用性と柔軟性が実現される。
【００６５】
次に、以上のように構成される試験システム１００を用いたモジュール間通信について説明する。
【００６６】
本試験システム１００は、各モジュール１０８が独立に制御されることを前提に仕様が構成されていて、モジュール間の横のつながりには対応していない。しかし、他のモジュールが存在して初めて機能するモジュールもある。このようなモジュールは他のモジュールに依存しているということができる。例えば、あるモジュールＡが他のモジュールと同期して機能する必要があり、この同期が特定のモジュールＢが提供する機能によって実現されるとき、このモジュールＸの同期は、モジュールＹに依存しているといえる。また、新たに開発したモジュールＺが、既存のモジュールＷの提供するコマンドやライブラリを利用するとき、このモジュールＺは、モジュールＷに依存しているといえる。
【００６７】
このように、あるモジュール（依存モジュール）が別のモジュール（被依存モジュール）に依存している場合に対応するためには、試験システム１００において、モジュール間でコマンド等を通信できるような仕組みが必要となる。このとき、モジュール間で任意に通信を認める仕様も考えられるが、あるモジュールが別のモジュールに悪影響を与える可能性もあるため、無限定にモジュール間通信を行うと、システムの安全性を担保できない。これに対して、本試験システム１００では、モジュール間通信にシステムを介在させることにより、安全性を担保している。すなわち、本試験システム１００では、システムとして許されたモジュール間でのみ通信できるように制限することによって、システム全体としての動きを保証している。
【００６８】
図７は、本実施形態に係るモジュール間通信処理を行う際の概略構成を示すブロック図である。同図は、ベンダＡが提供するモジュールＡ １０８ａと、ベンダＢが提供するモジュールＢ １０８ｂとの間で、モジュール間通信を行う場合を例示する。
【００６９】
図７に示すように、本試験システム１００においてモジュール間通信を行う場合には、ＭＣＦ１３０内に、モジュール間通信設定部１４０を加える。このモジュール間通信設定部１４０で定義された内容に基づいて、モジュール間の通信方法とモジュール間の依存関係とが設定される。図７に示す例では、モジュール間通信設定部１４０にて、モジュールＡとモジュールＢとの間で通信が行われ、かつ、モジュールＡがモジュールＢに依存することが定義されている。
【００７０】
一方、サイトコントローラ１０４は、ＭＣＦ１３０内にモジュール間通信設定部１４０が含まれるとき、ＭＣＦ解釈部が、モジュール間通信設定部１４０で定義された内容に基づいて、配送器１５０を生成する。この配送器１５０は、モジュール間通信用のインタフェース１５２を提供するものであり、例えば、モジュール間通信専用のオブジェクトとして構成される。そして、配送器１５０を利用することにより、モジュール間でダイレクトなピア・トゥ・ピアによる通信が、ソフトウェア的に実現される。図７に示す例では、モジュールＡ １０８ａから配送器１５０にコマンド等を送信すると、配送器１５０からモジュールＢ １０８ｂに当該コマンド等が配送される。こうして、モジュールＡ １０８ａとモジュールＢ １０８ｂとの間で、高速な通信インタフェース１５２が提供される。
【００７１】
なお、各モジュール１０８は、通信可能な相手先モジュールの情報（以下「通信可能相手情報」という。）を保有している。例えば、モジュールＡ １０８ａは、ベンダＢのモジュールＢ １０８ｂと通信可能である、といった通信可能相手情報を保有している。モジュール１０８を試験システム１００に組み込む（インテグレーション）と、モジュール１０８が有する通信可能相手情報に基づいて、ＭＣＦ１３０に、モジュール間の通信方法及び依存関係等が書き加えられる。また、依存関係は一方向であることが好ましい。双方向にすると、システムの動作が保証されない。
【００７２】
図８は、本実施形態に係るモジュール間通信処理の流れを示すフローチャートである。まず、試験システム１００に新たにモジュール１０８が組み込まれると（Ｓ３０１）、モジュール１０８の通信可能相手情報に基づいて、試験システム１００は、ＭＣＦ１３０内のモジュール間通信設定部１４０に、新たに追加されたモジュールに関する通信方法及び依存関係を書き加える（Ｓ３０２）。さらに、試験システム１００は、ＭＣＦ１３０が変更された後、ＭＣＦ１３０内のモジュール間通信設定部１４０に定義された内容に基づいて、モジュール間通信を行うための配送器１５０を生成する（Ｓ３０３）。
【００７３】
この配送器１５０がモジュール間通信を行う際のインタフェースを提供する。これにより、配送器１５０が生成された後、モジュール１０８は、配送器１５０を介して他のモジュールとの間で通信を行うことにより、ソフトウェア的にダイレクトに通信をおこなうことができる（Ｓ３０４）。
【００７４】
次に、モジュール間通信処理を実装するための具体的な実施例を示す。
【００７５】
試験システム１００は、モジュール間通信のために、ＩＭＣ（IModuleCommunication）とＩＭＣＤ（IModuleCommunicationDispatcher）の二つのインタフェースを提供する。ＩＭＣは、モジュール１０８が他のモジュールに対して所定の機能を提供する必要のあるときに、モジュール１０８が実装する必要のあるインタフェースクラスである。ＩＭＣＤは、モジュール間通信を実現するために、システム実装をモジュールに公表するためのインタフェースクラスである。
【００７６】
図９は、ＩＭＣ及びＩＭＣＤインタフェースクラスの関係を示す図である。同図において、「コマンド」は、モジュール・ソフトウェアＸ（以下、単に「モジュールＸ」という。）からモジュール・ソフトウェアＹ（以下、単に「モジュールＹ」という。）への要求を表す。モジュールＹはコマンドを提供し、このコマンドはモジュールＹによって提供される特定の機能を表す。モジュールＸがモジュールＹの機能を実行しようとする場合、モジュールＸは、ＩＭＣＤを通して、この機能に対応するコマンドをモジュールＹに送る。モジュールＹは要求されたコマンドを受信し、サービスとしてこのコマンドに対応する機能を実行し、この機能の結果を返す。
【００７７】
なお、ＩＭＣに関して、モジュールは、一つのインスタンスだけを実装可能であり、複数のインスタンスを実装できない。また、他のモジュールからコマンドを受け取らないモジュールはＩＭＣを実装しなくてよい。フレームワークは、所定のヘッダファイル内でＩＭＣインタフェースの定義を提供する。このインタフェースの実装は、クライアントモジュールに過度の依存関係を強制することになるので、具体的なクラスや構造が定義された如何なる実装にも依存しないことが好ましい。例えば、モジュールが内部データの表現の定義を変更した場合、当該モジュールに依存する全てのモジュールは、リコンパイルして新しくリリースする必要がある。
【００７８】
また、ＩＭＣＤは、所定のモジュールからコマンドを受信し、適切なモジュールにそのコマンドを送るという配送器１５０としての機能を提供するものであり、通信の方向が認められるか否かを認証する。フレームワークは、所定のヘッダファイルの中で、ＩＭＣＤインタフェースの定義を提供する。
【００７９】
図１０は、ＩＭＣ及びＩＭＣＤインタフェースクラスを利用したモジュール間通信処理の流れを示すフローチャートである。ここでは、二つのモジュールＸとモジュールＹを想定する。図９に示すように、モジュールＸはモジュールＹとの通信を要する。このとき、モジュールＸ用のドライバは、フレームワークによって生成されたモジュールＸと通信するための所定のオブジェクトとデータを取得する。ここで、フレームワークは、モジュール間通信を確立するために、次のようにモジュール間を仲介する。
【００８０】
まず、全てのモジュール・ドライバのＤＬＬがサイトコントローラ１０４にロードされた後、フレームワークはモジュール・ドライバによって生成された全てのモジュールからＩＭＣオブジェクトを検索する（Ｓ３１１）。
【００８１】
その後、全てのＩＭＣオブジェクトは、フレームワークによって生成されたモジュール間通信管理部に登録され、全てのＩＭＣオブジェクトに対して、各ＩＭＣオブジェクトを一意に識別可能な識別番号が付与される（Ｓ３１２）。
【００８２】
それから、フレームワークは、ＭＣＦ１３０に記述されたモジュール間通信方法及び依存関係に従って、ＩＭＣＤポインタと各モジュールを一意に識別可能な識別子とを割り当てる（Ｓ３１３）。ＩＭＣＤは、フレームワークによって生成されるものであり、モジュールがフレームワークを介して他のモジュールと通信できるようにするためのインタフェースである。そして、ＩＭＣＤは、所定のモジュールが他のモジュールと通信する際に、フレームワークによって所定のモジュールに配送される（Ｓ３１４）。
【００８３】
図１１は、割り当てるメソッドの一例を示す図である。同図において、「ｓｅｎｄｅｒ」は、コマンドを送ったモジュールを区別するためにフレームワークによって決定されるＩＤである。「ｒｅｃｅｉｖｅｒｓ」は、他のモジュールと通信するためのＩＤである。
【００８４】
また、所定のモジュール（例えば、モジュールＸ）において、当該モジュールＸと通信できるよう設定されている他の全てのモジュールとの通信を認めるためのキーワードを備えることが好ましい。すなわち、モジュールは、他のモジュールによって提供されるモジュール特有の通信オブジェクトを利用可能である。
【００８５】
以上のように、本試験システム１００では、ＭＣＦ１３０内のモジュール間通信設定部１４０にモジュール間の通信方法及び依存関係を規定し、当該モジュール間通信設定部１４０に規定された内容に基づいて、モジュール間通信を行うための配送器１５０を生成することにより、依存関係のあるモジュール間通信を実現している。
【００８６】
また、本試験システム１００では、任意モジュール間での通信を認めず、システムにより認められたモジュール間でのみ通信できることに特徴を有する。これにより、システム全体の安全性を担保している。さらに、本試験システム１００では、モジュール間通信の設定情報をＭＣＦ１３０内で定義している。このように、モジュール間通信の設定情報をシステムＯＳの外部に持たせることにより、モジュール間通信の設定のためのリコンパイル等が不要になり、柔軟にシステムを運用できる。加えて、他のベンダのモジュールに依存しなくても、開発やシステムへの組み込みができる環境を提供することにより、開発環境でも独立性を維持できる。さらに、ソフトウェア的にダイレクトなモジュール間通信を行うことにより、高速な通信を実現している。これらの特徴は、特に、オープン・アーキテクチャＡＴＥの場合に有効である。
【００８７】
なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【図面の簡単な説明】
【００８８】
【図１】本発明の一実施形態による試験システム１００のシステムアーキテクチャを示す。
【図２】試験サイト１１０及びロードボード１１４のハードウェアの概略構成と各種設定用ファイルとの関係の一例を示す図である。
【図３】試験システム１００のソフトウェア・アーキテクチャ２００の一例を示す。
【図４】モジュール設定ファイル（ＭＣＦ）１３０の一例を示す図である。
【図５】ソケットファイル１１８の一例を示す図である。
【図６】リソース定義ファイルの一例として、図２に示すリソース・タイプ「ＯＡＩ．Ｄｉｇｉｔａｌ．ｄｐｉｎ」の定義の一部を示す図である。
【図７】モジュール間通信処理を行う際の概略構成を示すブロック図である。
【図８】本実施形態に係るモジュール間通信処理の流れを示すフローチャートである。
【図９】ＩＭＣ及びＩＭＣＤインタフェースクラスの関係を示す図である。
【図１０】ＩＭＣ及びＩＭＣＤインタフェースクラスを利用したモジュール間通信処理の流れを示すフローチャートである。
【図１１】割り当てるメソッドの一例を示す図である。
【符号の説明】
【００８９】
１００ 試験システム
１０２ システムコントローラ
１０４ サイトコントローラ
１０６ モジュール接続イネーブラ
１０７ バス
１０８ モジュール
１１０ 試験サイト
１１２ 被試験デバイス（ＤＵＴ）
１１４ ロードボード
１１８ ソケットファイル
１２０ ソケット
１２２ ピン
１２４ コネクタピン
１２６ テスタ・インタフェース・ユニット（ＴＩＵ）
１２８ ピン
１３０ モジュール設定ファイル（ＭＣＦ）
１３２ テストヘッド
１４０ モジュール間通信設定部
１５０ 配送器
【特許請求の範囲】
【請求項１】
被試験デバイスに試験信号を供給可能なモジュールを複数組み込み可能な試験システムであって、
前記試験システムは、
所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を備え、当該配送器は、前記所定の二つのモジュールのうち一のモジュールから受信した信号を、前記所定の二つのモジュールのうち他のモジュールへ配送する機能を備える、
ことを特徴とする試験システム。
【請求項２】
前記試験システムは、
モジュールの接続関係を設定するためのモジュール設定ファイルを備え、
前記試験システムは、前記モジュール設定ファイルに規定された内容に基づいて、前記配送器を生成する、
ことを特徴とする請求項１記載の試験システム。
【請求項３】
前記モジュール設定ファイルは、所定の二つのモジュール間の通信方法及び依存関係を設定するモジュール間通信設定部を含み、
前記試験システムは、前記モジュール間通信設定部に規定された前記通信方法及び依存関係に基づいて、前記所定の二つのモジュール間の通信インタフェースとして機能する配送器を生成する、
ことを特徴とする請求項２記載の試験システム。
【請求項４】
前記モジュールは、通信可能な相手先モジュールの情報を備え
前記試験システムは、前記モジュールが前記試験システムに組み込まれたときに、前記情報に基づいて、前記モジュール間通信設定部に規定される内容を書き換える、
ことを特徴とする請求項３記載の試験システム。
【請求項５】
前記試験システムは、前記二以上のモジュールの各々を独立に制御することを前提とするものである、
ことを特徴とする請求項１乃至４のいずれかに記載の試験システム。
【請求項６】
前記試験システムは、オープン・アーキテクチャに基づくシステムであり、
前記二以上のモジュールは、前記オープン・アーキテクチャの標準仕様に準拠するものである、
ことを特徴とする請求項１乃至５のいずれかに記載の試験システム。
【請求項７】
被試験デバイスに試験信号を供給可能なモジュールを二以上組み込み可能な試験システムにおいて、所定の二つのモジュール間で通信を行う方法であって、
モジュールの接続関係を設定するためのモジュール設定ファイルに規定された内容に基づいて、前記所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を生成するステップと、
前記配送器を介して、前記所定の二つのモジュールのうち一のモジュールから受信した信号を、前記所定の二つのモジュールのうち他のモジュールへ配送することにより、モジュール間通信を行うステップと、
を備えるモジュール間通信方法。
【請求項８】
請求項７に記載のモジュール間通信方法をコンピュータに実行させるためのプログラム。
【請求項９】
請求項８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
被試験デバイスに試験信号を供給可能なモジュールを複数組み込み可能な試験システムであって、
前記試験システムは、
所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を備え、当該配送器は、前記所定の二つのモジュールのうち一のモジュールから受信した信号を、前記所定の二つのモジュールのうち他のモジュールへ配送する機能を備える、
ことを特徴とする試験システム。
【請求項２】
前記試験システムは、
モジュールの接続関係を設定するためのモジュール設定ファイルを備え、
前記試験システムは、前記モジュール設定ファイルに規定された内容に基づいて、前記配送器を生成する、
ことを特徴とする請求項１記載の試験システム。
【請求項３】
前記モジュール設定ファイルは、所定の二つのモジュール間の通信方法及び依存関係を設定するモジュール間通信設定部を含み、
前記試験システムは、前記モジュール間通信設定部に規定された前記通信方法及び依存関係に基づいて、前記所定の二つのモジュール間の通信インタフェースとして機能する配送器を生成する、
ことを特徴とする請求項２記載の試験システム。
【請求項４】
前記モジュールは、通信可能な相手先モジュールの情報を備え
前記試験システムは、前記モジュールが前記試験システムに組み込まれたときに、前記情報に基づいて、前記モジュール間通信設定部に規定される内容を書き換える、
ことを特徴とする請求項３記載の試験システム。
【請求項５】
前記試験システムは、前記二以上のモジュールの各々を独立に制御することを前提とするものである、
ことを特徴とする請求項１乃至４のいずれかに記載の試験システム。
【請求項６】
前記試験システムは、オープン・アーキテクチャに基づくシステムであり、
前記二以上のモジュールは、前記オープン・アーキテクチャの標準仕様に準拠するものである、
ことを特徴とする請求項１乃至５のいずれかに記載の試験システム。
【請求項７】
被試験デバイスに試験信号を供給可能なモジュールを二以上組み込み可能な試験システムにおいて、所定の二つのモジュール間で通信を行う方法であって、
モジュールの接続関係を設定するためのモジュール設定ファイルに規定された内容に基づいて、前記所定の二つのモジュール間で通信を行う際のインタフェースとして機能する配送器を生成するステップと、
前記配送器を介して、前記所定の二つのモジュールのうち一のモジュールから受信した信号を、前記所定の二つのモジュールのうち他のモジュールへ配送することにより、モジュール間通信を行うステップと、
を備えるモジュール間通信方法。
【請求項８】
請求項７に記載のモジュール間通信方法をコンピュータに実行させるためのプログラム。
【請求項９】
請求項８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−２２９３０５（Ｐ２００９−２２９３０５Ａ）
【公開日】平成２１年１０月８日（２００９．１０．８）
【国際特許分類】
【出願番号】特願２００８−７６５３７（Ｐ２００８−７６５３７）
【出願日】平成２０年３月２４日（２００８．３．２４）
【出願人】（３９０００５１７５）株式会社アドバンテスト (1,005)
【Ｆターム（参考）】
【公開日】平成２１年１０月８日（２００９．１０．８）
【国際特許分類】
【出願日】平成２０年３月２４日（２００８．３．２４）
【出願人】（３９０００５１７５）株式会社アドバンテスト (1,005)
【Ｆターム（参考）】
[ Back to top ]