JP2009229304A - 試験システム及びモジュール制御方法 - Google Patents

Abstract

【課題】マスタ・スレーブ方式のモジュール制御において、モジュール制御ドライバ等が、リソースとポート番号との関係を含むスレーブ・モジュールのリソース定義を特定可能な試験システムを提供する。
【解決手段】被試験デバイス１１２に試験信号を供給可能な複数のモジュール１０８と、複数のモジュール１０８それぞれのリソースとポート番号に関する情報を含むモジュール設定ファイル１３０と、モジュール設定ファイル１３０に含まれる情報に基づいて複数のモジュール１０８のリソースとポート番号との関係を特定し、ポート番号を利用して、複数のモジュール１０８の各々のリソースを個別に制御することのできるモジュール制御ドライバ１０５と、を備える。
【選択図】図７

Description

本発明は自動試験装置の技術分野に関する。特に、本発明は、自動試験装置におけるスレーブ・モジュールの制御技術に関する。

従来、自動試験装置（以下「ＡＴＥ」という。）は、ＡＴＥメーカー各社各様の仕様で提供されていたため、ピン構成や測定ユニット等の構成の自由度が低く、また、試験プログラム資産の再利用が困難であった。このような背景から、デバイスの機能に応じて最適な構成にシステムを変更できるようなスケーラブルで柔軟なＡＴＥを実現すべく、標準化されたインタフェースを持つオープン・アーキテクチャＡＴＥが提案されている。

例えば、ＯＰＥＮＳＴＡＲ（登録商標）は、このようなオープン・アーキテクチャＡＴＥの規格の一つである（非特許文献１参照）。ＯＰＥＮＳＴＡＲシステムは、スケーラブルでかつ柔軟なモジュラー構造のＡＴＥプラットフォームを提供することを目的とし、そのための標準規格を定めている。サード・ベンダ等が提供する計測機器（モジュール）は、ＯＰＥＮＳＴＡＲ標準が定めるハードウェアとソフトウェアの要件を満たすことで、ＯＰＥＮＳＴＡＲシステムに組み込むことが可能である。
「Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｔｅｓｔ Ｃｏｎｓｏｒｔｉｕｍ」、［online］、［平成２０年３月２４日検索］、インターネット＜ＵＲＬ：http://www.semitest.org/jp/home＞

ところで、従来のＯＰＥＮＳＴＡＲシステムの標準規格では、モジュール毎にモジュール制御ドライバを備えることが前提とされている。しかし、複数の共通モジュールをシステムに組み込んだとき、これら複数の共通モジュールをそれぞれ別のモジュール制御ドライバで制御するのはオーバースペックの場合がある。そこで、複数の共通モジュールのうち一つをマスタ・モジュールとし、残りをスレーブ・モジュールとして、マスタ・モジュールが備えるモジュール制御ドライバによって、複数の共通モジュールを全て制御するマスタ・スレーブ方式によるモジュール制御手法が知られている。

図１０は、従来のモジュール制御手法を示すブロック図である。図１０（Ａ）は、従来のＯＰＥＮＳＴＡＲシステムの標準規格に基づいて、モジュール毎にモジュール制御ドライバを備える一例を示すブロック図である。このとき、各モジュール１０８はそれぞれモジュール制御ドライバ１０５を備え、各モジュール１０８は、それぞれ対応するモジュール制御ドライバ１０５によって制御される。

また、図１０（Ｂ）は、従来のマスタ・スレーブ方式によるモジュール制御手法の一例を示すブロック図である。同図では、モジュールＡがモジュール制御ドライバ１０５を備え、マスタ・モジュール１０８Ｍとして機能する。そして、モジュールＢはスレーブ・モジュール１０８Ｓとして機能するものであり、モジュール制御ドライバを備えない。そして、モジュール制御ドライバＡによって、モジュールＢも制御される。

マスタ・スレーブ方式では、ハードウェアの側面から見ると、スレーブ・モジュール１０８Ｓは、後述するモジュール接続イネーブラ１０６の一つのバスポートに接続された通常のモジュールの実体である。しかし、ソフトウェアの側面から見ると、スレーブ・モジュール１０８Ｓは、マスタ・モジュール１０８Ｍの背後に隠れる形になっている。すなわち、スレーブ・モジュール１０８Ｓは、モジュール制御ドライバを保有しないで、マスタ・モジュール１０８Ｍのモジュール制御ドライバ１０５に、スレーブ・モジュール１０８Ｓの制御を委ねている。

図１１は、従来のマスタ・スレーブ方式によるモジュール制御における、リソースとポート番号との関係の一例を示す概略図である。同図に示す例では、一つのマスタ・モジュール１０８Ｍが一つのスレーブ・モジュール１０８Ｓを備え、各モジュールは、ロードボード１１４に接続されるピン１２８を備える。また、各モジュールは、システム内でのアドレスとして使用されるポート番号を備え、マスタ・モジュール１０８Ｍのポート番号は「１０」であり、スレーブ・モジュール１０８Ｓのポート番号は「１１」であるものとする。

このとき、従来のマスタ・スレーブ方式によるモジュール制御では、スレーブ・モジュール１０８Ｓのリソース（ポート番号とチャネルの組）は、マスタ・モジュール１０８Ｍのポート番号「１０」に基づいて、Ｐ１０．９、Ｐ１０．１０、・・・、Ｐ１０．１６と表される。このように、実際はスレーブ・モジュール１０８Ｓによって提供されるリソースであっても、従来のモジュール制御モデルでは、スレーブ・モジュール１０８Ｓが自身のポート番号（この例では「１１」）に基づいてリソースを定義することが許されていない。その結果、ソフトウェア的には、モジュール制御ドライバ１０５及びサイトコントローラ１０４のいずれからも、スレーブ・モジュール１０８Ｓは存在しないものとして扱われる。すなわち、従来のモジュール制御モデルでは、スレーブ・モジュール１０８Ｓをマスタ・モジュール１０８Ｍと明確に区別して制御することができない。

また、リソースの設定は固定的なものではなく、システム・インテグレータはリソースを任意に割り当てることができる。例えば、図１１では、ポート番号が「１０」のモジュールをマスタ・モジュール１０８Ｍとしたが、ポート番号「１１」のモジュールがモジュール制御ドライバ１０５を備えるものとして、マスタとスレーブの関係を、図１１の例とは逆に設定することも可能である。このとき、各モジュールのリソースは、Ｐ１１．１、Ｐ１１．９などと表されることになる。

以上のように、従来のマスタ・スレーブ方式によるモジュール制御では、スレーブ・モジュール１０８Ｓがマスタ・モジュール１０８Ｍとソフトウェア的に区別されることなく扱われ、かつ、リソースの割り当ても任意に行われる。このため、モジュール制御ドライバ１０５は、リソースとモジュールのポート番号との関係が分からないと、所望のモジュールを制御することができない。つまり、図１１に示す例において、モジュール制御ドライバ１０５は、リソースＰ１０．１からＰ１０．１６の各リソースに関係するモジュールのポート番号を知り得ない限り、それぞれのリソースを制御できない。しかし、各リソースとモジュールのポート番号との関係は、システム・インテグレータのみが知り得るものである。そのため、ＡＴＥに何らかの形でリソースとポート番号との関係が提供されない限り、モジュール制御ドライバ１０５とサイトコントローラ１０４のいずれも、リソースとポート番号との関係を知ることができない。

本発明は、かかる事情に鑑みてなされたものであり、マスタ・スレーブ方式のモジュール制御において、モジュール制御ドライバ又はサイトコントローラが、リソースとポート番号との関係を含むスレーブ・モジュールのリソース定義を特定することのできる試験システムを提供することを目的とする。

本発明に係る試験システムの幾つかの態様は、被試験デバイスに試験信号を供給可能な複数のモジュールと、複数のモジュールそれぞれのリソースとポート番号に関する情報を含むモジュール設定ファイルと、モジュール設定ファイルに含まれる情報に基づいて複数のモジュールのリソースとポート番号との関係を特定し、ポート番号を利用して、複数のモジュールの各々のリソースを個別に制御することのできるモジュール制御ドライバと、を備える。

好適には、複数のモジュールは、一つのマスタ・モジュールと、一以上のスレーブ・モジュールとを含み、モジュール制御ドライバは、一つのマスタ・モジュールと一以上のスレーブ・モジュールとを制御する、

また、好適には、モジュール設定ファイルは、各モジュールのポート番号と、各モジュールがマスタ・モジュール又はスレーブ・モジュールのいずれであるかに関する情報と、モジュールがスレーブ・モジュールの場合には、当該モジュールのマスタ・モジュールに関する情報と、を含む。

さらに好適には、ポート番号に換えて、複数のモジュールのそれぞれを識別可能な任意の識別子を利用する。また、試験システムは、オープン・アーキテクチャに基づくシステムであり、二以上のモジュールは、オープン・アーキテクチャの標準仕様に準拠するものであることが好ましい。

また、本発明に係る試験システムのモジュール制御方法の幾つかの態様は、被試験デバイスに試験信号を供給可能な複数のモジュールと、複数のモジュールを制御可能なモジュール制御ドライバとを備える試験システムを用いて、複数のモジュールそれぞれのリソースとポート番号に関する情報を含むモジュール設定ファイルを読み出すステップと、モジュール設定ファイルに規定された内容に基づいて、複数のモジュールのリソース定義を特定して、モジュール制御ドライバに実装するステップと、モジュール設定ドライバが、ポート番号を利用して、複数のモジュールの各々のリソースを個別に制御するステップと、を備える。

本発明のプログラムは、本発明のモジュール間通信方法の各処理ステップをコンピュータに実行させることを特徴とする。本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。

なお、本明細書等において、「手段」又は「部」とは、単に物理的手段を意味するものではなく、その手段又は部が有する機能をソフトウェアによって実現する場合も含む。また、１つの手段又は部が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段又は部の機能が１つの物理的手段により実現されてもよい。

また、本明細書等において、ベンダ等が提供する計測機器のハードウェアを「モジュール」といい、そのハードウェアを対象とするベンダ等のソフトウェアを「モジュール・ソフトウェア」と呼ぶ。

さらに、再構成可能なオープン・アーキテクチャＡＴＥは、試験システムに対する操作の統一だけでなく、目的の試験に最適なモジュールを、モジュール・ソフトウェアとともに、ユーザ自身が既存のシステムにプラグ・アンド・プレイ方式で導入可能なプラットフォームを提供する。また、モジュールのベンダに対しては、そのようなモジュール・ソフトウェアの開発を可能にする開発環境を提供する。

本発明によると、マスタ・スレーブ方式のモジュール制御において、モジュール制御ドライバ又はサイトコントローラが、リソースとポート番号との関係を含むスレーブ・モジュールのリソース定義を特定できるように、試験システムのフレームワークを拡張している。これにより、スレーブ・モジュールのポート番号に基づいたリソース定義の設定ができるようになる。また、本発明では、従来からリソース記述に用いられているモジュール設定ファイルを使用して、スレーブ・モジュールのポート番号とリソースとの関係を記述しているので、従来のリソース記述を承継でき、直感的でリーズナブルである。

以下、本発明の実施の形態について詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。また、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。さらに、本発明は、その要旨を逸脱しない限り、さまざまな変形及び応用が可能である。

図１は、本発明の一実施形態による試験システム１００のシステムアーキテクチャを示す。試験システム１００は、試験信号を生成して被試験デバイス（Device under Test。以下「ＤＵＴ」という。）１１２に供給し、ＤＵＴ１１２が試験信号に基づいて動作した結果出力する結果信号が期待値と一致するか否かに基づいてＤＵＴ１１２の良否を判断する。なお、本実施形態に係る試験システム１００は、オープン・アーキテクチャにより実現されるものとして説明するが、本発明は、オープン・アーキテクチャの試験システムに限定されるものではない。

本実施形態では、システムコントローラ（ＳｙｓＣ）１０２がネットワークを介して複数のサイトコントローラ（ＳｉｔｅＣ）１０４に接続される。システムコントローラ１０２は、エンド・ユーザが通常作業を行うホストコンピュータであり、試験システム１００全体を管理する役割を果たす。また、システムコントローラ１０２は、サイトコントローラ１０４に対する処理の要求の発行や、サイトコントローラ１０４間の処理の調停を行う。ユーザのアプリケーションや標準のＧＵＩツールは、システムコントローラ１０２上で動作し、サイトコントローラ１０４と通信を行って機能を実現する。

また、システムコントローラ１０２は、サイトコントローラ１０４上でモジュール１０８の制御を行うモジュール・ソフトウェアや、ユーザの試験プログラムやパターン・プログラムなどを保管するストレージを備える。これらは、必要に応じてサイトコントローラ１０４に送られ、実行される。

各サイトコントローラ１０４は、試験サイト１１０に配置される１つ又は複数のモジュール１０８を制御して試験を実行するために、モジュール接続イネーブラ１０６を通して、モジュール１０８に接続される。この試験は、ユーザの作成する試験プログラムに基づいて実行される。なお、サイトコントローラ１０４は、一つのＤＵＴ１１２を試験する試験サイト１１０を複数個、同時に制御するようにしてもよい。

サイトコントローラ１０４の主な役割として、次の３つが挙げられる。まず、試験プログラムが指定する試験サイト１１０の構成に従い、モジュール接続イネーブラ１０６を構成し、サイトコントローラ１０４とモジュール１０８間のバス１０７の接続を確立する。また、試験サイト１１０内のモジュール１０８の制御を行うモジュールソフトウェアを実行する。さらに、試験プログラムを実行し、各試験サイト１１０のＤＵＴ１１２の試験を実行する。

なお、動作環境によっては、システムコントローラ１０２は、サイトコントローラ１０４の動作とは別のＣＰＵ（中央演算装置）上に配置することができる。別法では、システムコントローラ１０２及びサイトコントローラ１０４は、共通のＣＰＵを共有することができる。同様に、各サイトコントローラ１０４は、その専用のＣＰＵ上に配置することができるし、また、同じＣＰＵ内の別個のプロセス又はスレッドとして配置することもできる。

モジュール接続イネーブラ１０６は、サイトコントローラ１０４とモジュール１０８とのバス１０７の接続を任意に構成することのできるスイッチである。モジュール接続イネーブラ１０６は、接続されるハードウェアモジュール１０８の構成を変更できるようにするとともに、データ転送用（パターンデータのロード用、応答データの収集用、制御用等）のバスとしての役割も果たす。実現可能なハードウェアの実装形態は、専用接続、交換接続、バス接続、リング接続及びスター接続を含む。モジュール接続イネーブラ１０６は、たとえばスイッチマトリクスとして実装することができる。

モジュール１０８は、ＤＵＴ１１２に試験信号を供給する計測機器のハードウェアである。本実施形態においては、モジュール１０８として、オープン・アーキテクチャに基づく各種のモジュールを用いることができる。また、モジュール・ハードウェア１０８を動作させるためのソフトウェアをモジュール・ソフトウェアという。モジュール・ソフトウェアは、デバイス測定時にモジュール１０８の制御をつかさどるモジュール・ドライバ、モジュール１０８の校正と診断を行う校正診断ソフトウェア、モジュール１０８の動作をソフトウェアでエミュレートするエミュレーション・ソフトウェア、モジュール１０８固有のパターン・コンパイラ、およびＧＵＩツールなどを含む。

各試験サイト１１０は、それぞれ一つのＤＵＴ１１２に関連付けられる。ＤＵＴ１１２は、ロードボード１１４を通して、対応する試験サイト１１０のモジュール１０８に接続される。

図２は、試験サイト１１０及びロードボード１１４のハードウェアの概略構成と各種設定用ファイルとの関係の一例を示す図である。図２に示すように、モジュール１０８は、試験システム１００のテストヘッド１３２内のモジュール・スロットに差し込まれる。

試験サイト１１０の構成は、テキスト形式で記述されるソケットファイル１１８で指定される。このソケットファイル１１８には、ＤＵＴ１１２ごとに、ＤＵＴソケット１２０のＤＵＴピン１２２とロードボード１１４上のコネクタピン１２４との接続が記述される。コネクタピン１２４は、ブロック番号とコネクタ番号が付けられており、例えば、「１２．３」のように、「（ブロック番号）．（コネクタ番号）」の形式で表記される。ロードボード１１４のコネクタピン１２４は、テスタ・インタフェース・ユニット（Tester Interface Unit。以下「ＴＩＵ」という。）１２６を介してモジュール１０８のピン１２８と接続される。

一方、ロードボード１１４は試験対象となるデバイスによって異なる場合が多い。そのため、モジュール・ソフトウェアが個々のロードボード１１４の実装に依存しないようにするためには、試験システム１００において、モジュール１０８が実装するピン１２８そのものを定義できるようにし、それをもとにモジュール１０８の制御ができるようにしなければならない。本試験システム１００では、これはモジュール設定ファイル（Module Configuration File。以下「ＭＣＦ」という。）１３０によって達成される。

ＭＣＦ１３０には、モジュール１０８のリソースとロードボード１１４のコネクタピン１２４との接続関係が指定される。これにより、論理的なピンの表現であるリソースと、モジュール１０８の物理ピン１２８、さらにはそれが接続されているロードボード１１４のコネクタピン１２４との関係が定められる。ＭＣＦ１３０は、システムだけが設定可能であることが望ましい。

なお、本実施形態において、モジュール１０８の機能は、主にモジュール１０８の全体的な制御に関わる機能を提供するモジュール・オブジェクトと、モジュールのピン毎の機能を提供するリソース・オブジェクトによって表現される。本実施形態に係る試験システム１００では、これらは全て、ＭＣＦ１３０に記述される内容に従って、実際のハードウェアのエンティティと対称に結び付けられる。なお、これらのソフトウェアのオブジェクトを提供するモジュール・ソフトウェアを、ここではモジュール・ドライバと呼ぶ。

また、本実施形態において、リソースとは、試験システム１００のモジュール１０８が備える物理的なピン１２８とその機能とを、オブジェクトで抽象化して表現したものである。モジュール１０８の一つの物理ピン１２８は、一つのリソースとして表現されてもよいし、機能的に分割された複数のリソースとして表現されてもよい。

リソースの機能的な分類はリソース・タイプと呼ばれ、その機能の定義はモジュール１０８のベンダが提供するリソース定義ファイルによって示される。論理的なピンを指すリソースは、リソース・タイプと、モジュール１０８内でピン１２８を特定する番号（リソースＩＤ）と、試験システム１００内でモジュール１０８を特定するバス１０７のポート番号との３つ組で表現される。リソース・タイプとリソースＩＤの組と、それに対応するモジュール１０８内の物理ピン１２８の関係は固定的であるため、リソースが与えられたときに、それを物理的なピン１２８に対応付けることが可能となる。なお、リソースが物理ピン１２８と対応付けられることはアーキテクチャ上必須ではなく、モジュール１０８の持つ機能を仮想的なピンに見立てて表現し、制御することも可能である。

図３は、試験システム１００のソフトウェア・アーキテクチャ２００の一例を示す。ソフトウェア・アーキテクチャ２００は分散オペレーティングシステムを表しており、関連するハードウェアシステム要素１０２、１０４、１０８に対応する、システムコントローラ・ソフトウェア２２０（以下、単に「システムコントローラ２２０」ともいう。）、少なくとも１つのサイトコントローラ・ソフトウェア２４０（以下、単に「サイトコントローラ２４０」ともいう。）及び少なくとも１つのモジュールを含むテストヘッド・ソフトウェア２６０（以下、単に「テストヘッド２６０」ともいう。）のための構成要素を有する。

一つの例示的な選択として、試験システム１００は、ソフトウェアのプラットフォームとしてＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）を使用し、実装言語としてＡＮＳＩ／ＩＳＯ標準Ｃ＋＋を使用することができる。プラットフォームの全てのシステム・インタフェースもまた、Ｃ＋＋のクラスまたはインタフェースとして提供され、ユーザの試験プログラムやモジュール・ソフトウェアはＣ＋＋で実装することができる。

システムコントローラ２２０は、ユーザのための一次的なインタラクションポイントであり、サイトコントローラ２４０へのゲートウェイと、マルチサイト／ＤＵＴ環境におけるサイトコントローラ２４０の同期とを提供する。ユーザアプリケーション及びツールは、グラフィカルユーザインターフェース（ＧＵＩ）に基づくものでも、そうでないものでも、システムコントローラ２２０上で実行される。

また、システムコントローラ２２０は、テストプラン、試験パターン及び試験パラメータファイルを含む、全てのテストプラン関連情報のためのリポジトリとしての役割も果たす。これらのファイルを記憶するメモリは、システムコントローラ２２０に対してローカルに存在することができるか、又は、ネットワークを介してシステムコントローラ２２０に接続されることができる。

さらに、システムコントローラ２２０は、フレームワーククラス２２１と、システムツール２２２と、外部ツール２２３と、サイトコントローラへの標準インタフェース２２４と、通信ライブラリ２３０とを含む。

システムコントローラ２２０に関連するフレームワーククラス２２１は、オブジェクトと対話するための仕組みを提供し、標準インタフェース２２４の参照インプリメンテーションを提供する。また、サイトコントローラ２４０へのゲートウェイを提供し、且つマルチサイト／ＤＵＴ環境におけるサイトコントローラ２４０の同期を提供するソフトウェア構成要素を構成する。実効的には、フレームワーククラス２２１は、システムコントローラ２２０をサポートするＯＳとしての役割を果たすことができる。

第三者の開発者は、標準システムツール２２２に加えて、又は、標準システムツール２２２に換えて、一以上のツール２２３を提供することができる。システムコントローラ２２０上の標準インタフェース２２４は、テスタ及び試験オブジェクトにアクセスするためにそれらのツールが用いるインタフェースを含む。ツール（アプリケーション）２２２、２２３によって、テスタ及び試験オブジェクトをインタラクティブに、且つバッチで制御できる。また、標準インタフェース２２４は、システムコントローラ２２０上で実行されるフレームワークオブジェクトへのオープンインタフェースや、サイトコントローラ２４０に基づくモジュール・ソフトウェアがパターンデータにアクセスし、それらを検索できるようにするインタフェース等を含む。

システムコントローラ２２０上に存在する通信ライブラリ２３０は、ユーザアプリケーション及び試験プログラムに対してトランスペアレントであるように、サイトコントローラ２４０と通信するための仕組みを提供する。

サイトコントローラ２４０は、試験機能の大部分が提供される。サイトコントローラ２４０は、テストプラン（試験プログラム）２４１と、試験クラス２４２と、サイトコントローラフレームワーククラス２４３と、特定モジュール拡張インタフェース２４４と、標準インタフェース２４５と、モジュール・ソフトウェア・インプリメンテーション２４６と、バックプレーン通信ライブラリ２４７と、バックプレーンドライバ２４８とを含む。

テストプラン２４１はユーザによって記述される。テストプランプログラムは、Ｃ＋＋のようなオブジェクト指向コンポーネントを用いて、標準的なコンピュータ言語において直に記述するか、又は、Ｃ＋＋コードを生成するための、さらに高いレベルの試験プログラミング言語において記述することができ、後に実行可能な試験プログラムにコンパイルすることができる。

テストプラン２４１は、標準的な又はユーザによって供給される試験クラス２４２及び／又はそのサイトコントローラ２４０に関連するフレームワーククラス２４３を用いることにより試験オブジェクトを作成し、標準インタフェース２４５を用いてハードウェアを構成し、テストプランフローを規定する。テストプランはいくつかの基本的なサービスをサポートし、デバッグサービス（たとえば、ブレークポイント生成）のような、下層のオブジェクトのサービスへのインタフェースを提供し、下層のフレームワーク及び標準クラスにアクセスできるようにする。

試験クラス２４２は、標準試験インタフェースの１つのインプリメンテーションであり、テストプランプログラムにおいて指定される。各試験クラスは通常、特定のタイプのデバイス試験、又はデバイス試験のための設定を実装する。

フレームワーククラス２４３は、共通の試験関連動作を実装する１組のクラス及びメソッドである。フレームワーククラス２４３は、実効的には、各サイトコントローラ２４０をサポートするローカルＯＳとしての役割を果たすことができる。

モジュール・ソフトウェアは、テストの実行時に必要に応じて動的に試験システム１００のプロセスにロードできるように、ＤＬＬ（Dynamic Link Library）形式であることが望ましい。これは、テストプラン２４１が指定する試験サイト１１０の構成に応じて、試験システム１００が実行時に動的に制御対象のモジュール２６１を決定するからである。また、全てのモジュール・ソフトウェアは、モジュール２６１の機能に応じて、システムＯＳが規定するモジュール・ソフトウェアの標準インタフェース２４５を実装することが求められる。

特定モジュール拡張インタフェース２４４は、必要に応じてモジュール固有のより複雑で専門的な機能を持つインタフェース階層をモジュール・ソフトウェアに付加して実装する。例えば、Ｃ＋＋では、標準インタフェース２４５を継承するインタフェースクラスをモジュール・ソフトウェアで定義することによって、インタフェースを拡張することができる。

標準インタフェース２４５は、システムフレームワークが規定する必要最小限の、一般的で普遍的に適用可能なインタフェースである。標準インタフェース２４５を用いて、全てのオブジェクトを画一的に扱うことができる。これにより、システムＯＳを変更することなく、新しいモジュールのソフトウェアをシームレスに、プラグ・アンド・プレイ方式でシステムに導入することが可能となる。

一例として、標準インタフェース２４５は、Ｃ＋＋の純粋仮想インタフェースクラスとして定義される。このとき、ユーザ向けの機能を定義するサブクラスと、システムだけが使用する機能を定義するサブクラスと、リソースの機能を定義するサブクラスとによって構成されることが好ましい。また、標準インタフェース２４５の階層は、モジュールの最も基本的な機能を定義する階層、パターン・プログラムを実行する機能を持つモジュールを表現する階層、複数のピン間で共有されるテスト周期という概念を導入する階層、デジタル・モジュール特有の機能を加える階層、の４階層により構成されることが好ましい。このとき、各モジュール・ドライバは、モジュールの機能に応じて、４階層のインタフェースのいずれかを実装する。しかし、標準インタフェース２４５の構成は、これらの構成に限定されるものではない。

バックプレーン通信ライブラリ２４７は、バックプレーンにわたる標準的な通信のためのインタフェースを提供し、それによりテストヘッド２６０内のモジュール１０８と通信するために必要な機能を提供する。これにより、ベンダ固有のモジュール・ソフトウェアが、バックプレーンドライバ２４８を用いて、対応するモジュール１０８と通信できる。バックプレーン通信プロトコルはパケットに基づくフォーマットを用いることができる。

テストヘッド２６０は、デバイスに対する測定機能が提供される。テストヘッド２６０は、モジュール２６１と、ＴＩＵ２６２と、ロードボード２６３と、ＤＵＴ２６４とを含む。

また、ソフトウェア・アーキテクチャ２００は、ソフトウェアの名目的な供給元に基づいて、システムフレームワーク２９０、ユーザコンポーネント２９２、テスタオペレーティングシステム２９４、モジュール・ハードウェア・ベンダコンポーネント２９６、及び、ツール・ソフトウェア・ベンダコンポーネント２９８に分類することができる。

システムフレームワーク２９０は、試験システム１００の開発ベンダにより供給され、フレームワーククラス２２１と、標準インタフェース２２４と、フレームワーククラス２４３と、標準インタフェース２４５と、バックプレーン通信ライブラリ２４７とを含む。

ユーザコンポーネント２９２は、試験を実施するユーザによって供給され、テストプラン２４１と、テストクラス２４２と、ロードボード２６３と、ＤＵＴ２６４とを含む。

テスタオペレーティングシステム２９４は、基本的な接続性及び通信のためのソフトウェアインフラストラクチャとして供給され、システムツール２２２と、通信ライブラリ２３０と、バックプレーンドライバ２４８とを含む。

モジュール・ハードウェア・ベンダコンポーネント２９６は、モジュール１０８の開発元によって供給され、特定モジュール拡張インタフェース２４４と、モジュール・ソフトウェア・インプリメンテーション２４６と、モジュール２６１と、ＴＩＵ２６２を含む。

ツール・ソフトウェア・ベンダコンポーネント２９８は、外部ツールの開発元によって供給され、外部ツール２２３を含む。

次に、図２に示すハードウェアの概略構成に基づいて、各種設定ファイルについて具体的に説明する。

図４は、ＭＣＦ１３０の一例を示す図である。図４に示すＭＣＦ１３０は、図２に示すハードウェア概略構成を記述した場合の例である。「Resource」キーワードの後に続く「OAI.Digital.dpin」はリソース・タイプの名前である。また、バス１０７のポート番号とリソースＩＤの組は、「Ｐ（ポート番号）．（リソースＩＤ）」という形式（例えば、「Ｐ８．１」）で表記される。

図５は、ソケットファイル１１８の一例を示す図である。図５に示すように、本実施形態における試験システム１００では、ソケットファイル１１８によって各サイトコントローラ１０４に接続するモジュール１０８と各試験サイト１１０の構成が決定され、それに従ってモジュール接続イネーブラ１０６を再構成することで、サイトコントローラ１０４とモジュール１０８間のバス１０７の接続とモジュール１０８の制御が確立される。このようなモジュール構成の表現方式とバス構成の自由度の高さは、システムのモジュラリティとスケーラビリティの確保に大きく貢献し、モジュール１０８のプラグ・アンド・プレイの実現を支える。

図６は、リソース定義ファイルの一例として、図２に示すリソース・タイプ「ＯＡＩ．Ｄｉｇｉｔａｌ．ｄｐｉｎ」の定義の一部を示す図である。図６に示すように、リソースの属性は、型と属性名の対で指定される。例えば、図６において、「ＶＩＨ」という属性は、「Ｖｏｌｔａｇｅ」という型を持つ。リソースの属性に対する設定値は、例えば、「属性名＝値」という形で指定される。このように、モジュール１０８のハードウェアに強く依存するリソースの機能を、名前と型という極めて一般性のある表現形式で扱うことにより、ベンダは自由にリソースの機能を表現することができ、また、システムフレームワークは、モジュール１０８の機能に依存せずにリソースを画一的に扱うことが可能になる。これにより、システムの高い適用性と柔軟性が実現される。

次に、以上のように構成される試験システム１００を用いたマスタ・スレーブ方式によるモジュール制御手法について説明する。

図７は、本発明に係るマスタ・スレーブ方式によるモジュール制御を実現する概略構成の一例を示すブロック図である。同図は、マスタ・モジュールとして機能するモジュールＡ １０８Ｍと、スレーブ・モジュールとして機能するモジュールＢ １０８Ｓとを備える場合の一例である。本発明においては、モジュール制御ドライバ１０５によって、マスタ・モジュール１０８Ｍとスレーブ・モジュール１０８Ｓが制御される。そのため、マスタ・モジュール１０８Ｍが提供するリソースのみならず、スレーブ・モジュール１０８Ｓによって提供されるリソースも、モジュール制御ドライバ１０５によって定義され、実装される。

このとき、本発明では、ＭＣＦ１３０内に新たにマスタ・スレーブ定義部１４０を設け、このマスタ・スレーブ定義部１４０において、マスタ・モジュール１０８Ｍのリソース定義とスレーブ・モジュール１０８Ｓのリソース定義とが記述される点に特徴を有する。モジュール制御ドライバ１０５は、このＭＣＦ１３０内のマスタ・スレーブ定義部１４０を読み込んで、マスタ・モジュール１０８Ｍ及びスレーブ・モジュール１０８Ｓの備えるリソース定義を特定し、実装する。ここで、スレーブ・モジュール１０８Ｓのリソース定義は、スレーブ・モジュール１０８Ｓのポート番号とスレーブ・モジュール１０８Ｓの提供するリソース（ピン１２８等）との関係を含む。

このように、モジュール制御ドライバ１０５は、ＭＣＦ１３０を読み込んで、マスタ・スレーブ定義部１４０の内容を参照することによって、どのモジュールがスレーブ・モジュール１０８Ｓであって制御可能であるか、制御可能なスレーブ・モジュール１０８Ｓがどのような種類のリソースを提供しているか、また、スレーブ・モジュール１０８Ｓの制御法などを、特定することができる

なお、従来のＡＴＥでは、本実施形態のＭＣＦ１３０に対応するモジュール設定ファイルを備えているが、当該ファイルにおいて、スレーブ・モジュールのリソースをマスタ・モジュールのリソースと区別して定義することができないため、ＡＴＥは、スレーブ・モジュールのポート番号とリソースとの関係を特定することができない。

具体的には、マスタ・スレーブ定義部１４０は、例えば、各モジュールのポート番号と当該モジュールがスレーブ・モジュールであるか否かが記述される。また、スレーブ・モジュールの場合には、当該スレーブ・モジュールのマスタ・モジュールとして機能するモジュールのポート番号が対応付けられている。これにより、スレーブ・モジュール１０８Ｓのポート番号とスレーブ・モジュール１０８Ｓの提供するリソースとの関係を特定することができるようになる。

例えば、図７に示す例では、ＭＣＦ１３０内のマスタ・スレーブ定義部１４０において、モジュールＡのポート番号が１０であること（１行目）、並びに、モジュールＢのポート番号が１１であること（２行目）、モジュールＢがスレーブ・モジュールとして機能すること（３行目）、及び、モジュールＢのマスタ・モジュールはポート番号１０で表されるモジュールであること（４行目）が定義されている。

なお、試験システム１００がサポートする全てのリソースの種類は、マスタ・スレーブ定義部１４０で特定されることが好ましい。

図８は、本発明に係るマスタ・スレーブ方式によるモジュール制御における、リソースとポート番号との関係の一例を示す概略図である。同図に示す例では、図１１の例と同様に、一つのマスタ・モジュール１０８Ｍが一つのスレーブ・モジュール１０８Ｓを備え、各モジュールは、ロードボード１１４に接続されるピン１２８を備える。また、各モジュールは、システム内でのアドレスとして使用されるポート番号を備え、マスタ・モジュール１０８Ｍのポート番号は「１０」であり、スレーブ・モジュール１０８Ｓのポート番号は「１１」であるものとする。

このとき、本発明に係るマスタ・スレーブ方式によるモジュール制御では、スレーブ・モジュール１０８Ｓのリソース（ポート番号とチャネルの組）は、スレーブ・モジュール１０８Ｓ自身のポート番号「１１」に基づいて、Ｐ１１．１、Ｐ１１．２、・・・、Ｐ１１．８と表される。このように、本発明に係るモジュール制御モデルでは、スレーブ・モジュール１０８Ｓのリソースを、マスタ・モジュール１０８Ｍのポート番号に拘束されることなく、スレーブ・モジュール１０８Ｓ自身のポート番号に基づいて定義することができる。スレーブ・モジュール１０８Ｓのリソースが、スレーブ・モジュール１０８Ｓのポート番号に基づいて表現されるので、マスタ・モジュール１０８Ｍは、リソースを参照すれば、制御対象のスレーブ・モジュール１０８Ｓのポート番号を特定することができるようになる。このため、モジュール制御ドライバ１０５又はサイトコントローラ１０４は、スレーブ・モジュール１０８Ｓをマスタ・モジュール１０８Ｍと明確に区別して制御できる。

図９は、本実施形態に係るマスタ・スレーブ方式によるモジュール制御処理の流れを示すフローチャートである。まず、システム・インテグレータ等によって、試験システム１００に新たにモジュール１０８が組み込まれると（Ｓ３０１）、システム・インテグレータ等は、組み込んだモジュール１０８のポート番号、及び、スレーブ・モジュールか否か等のモジュール情報を、ＭＣＦ１３０内のマスタ・スレーブ定義部１４０に、新たに書き加える（Ｓ３０２）。その後、サイトコントローラ１０４は、所定の時点でＭＣＦ１３０を読み出して（Ｓ３０３）、マスタ・スレーブ定義部１４０に定義された内容に基づいて、モジュール制御ドライバ１０５にリソース定義を実装する（Ｓ３０４）。こうして、モジュール制御ドライバ１０５は、スレーブ・モジュールのリソースとポート番号との関係等を特定できるようになる。

以上のように、本試験システム１００では、ＭＣＦ１３０内のマスタ・スレーブ定義部１４０にモジュールのリソース定義を規定しておき、サイトコントローラ１０４は、ＭＣＦ１３０を読み込んで、当該マスタ・スレーブ定義部１４０に規定された内容に基づいて、モジュール制御ドライバ１０５に、スレーブ・モジュールを制御するためのリソース定義を実装する。これにより、モジュール制御ドライバ１０５は、マスタ・モジュールのみならず、スレーブ・モジュールのリソースとポート番号との関係等を特定できるようになる。

なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。

例えば、本実施形態では、スレーブ・モジュールのリソース定義として、リソースとポート番号との関係を例示したが、ポート番号に換えて、当該スレーブ・モジュールを一意に識別可能な任意の識別子を利用可能であることは言うまでもない。

本発明の一実施形態による試験システム１００のシステムアーキテクチャを示す。 試験サイト１１０及びロードボード１１４のハードウェアの概略構成と各種設定用ファイルとの関係の一例を示す図である。 試験システム１００のソフトウェア・アーキテクチャ２００の一例を示す。 モジュール設定ファイル（ＭＣＦ）１３０の一例を示す図である。 ソケットファイル１１８の一例を示す図である。 リソース定義ファイルの一例として、図２に示すリソース・タイプ「ＯＡＩ．Ｄｉｇｉｔａｌ．ｄｐｉｎ」の定義の一部を示す図である。 マスタ・スレーブ方式によるモジュール制御を実現する概略構成の一例を示すブロック図である。 マスタ・スレーブ方式によるモジュール制御における、リソースとポート番号との関係の一例を示す概略図である。 マスタ・スレーブ方式によるモジュール制御処理の流れを示すフローチャートである。 従来のモジュール制御手法を示すブロック図である。（Ａ）は、モジュール毎にモジュール制御ドライバを備える一例を示すブロック図である。（Ｂ）は、従来のマスタ・スレーブ方式によるモジュール制御手法の一例を示すブロック図である。 従来のマスタ・スレーブ方式によるモジュール制御における、リソースとポート番号との関係の一例を示す概略図である。

符号の説明

１００ 試験システム
１０２ システムコントローラ
１０４ サイトコントローラ
１０５ モジュール制御ドライバ
１０６ モジュール接続イネーブラ
１０７ バス
１０８ モジュール
１０８Ｍ マスタ・モジュール
１０８Ｓ スレーブ・モジュール
１１０ 試験サイト
１１２ 被試験デバイス（ＤＵＴ）
１１４ ロードボード
１１８ ソケットファイル
１２０ ソケット
１２２ ピン
１２４ コネクタピン
１２６ テスタ・インタフェース・ユニット（ＴＩＵ）
１２８ ピン
１３０ モジュール設定ファイル（ＭＣＦ）
１３２ テストヘッド

Claims (8)

1. 被試験デバイスに試験信号を供給可能な複数のモジュールと、
   前記複数のモジュールそれぞれのリソースとポート番号に関する情報を含むモジュール設定ファイルと、
   前記モジュール設定ファイルに含まれる情報に基づいて前記複数のモジュールのリソースとポート番号との関係を特定し、ポート番号を利用して、前記複数のモジュールの各々のリソースを個別に制御することのできるモジュール制御ドライバと、
   を備える試験システム。
2. 前記複数のモジュールは、一つのマスタ・モジュールと、一以上のスレーブ・モジュールとを含み、
   前記モジュール制御ドライバは、前記一つのマスタ・モジュールと前記一以上のスレーブ・モジュールとを制御する、
   ことを特徴とする請求項１記載の試験システム。
3. 前記モジュール設定ファイルは、
   各モジュールのポート番号と、
   各モジュールがマスタ・モジュール又はスレーブ・モジュールのいずれであるかに関する情報と、
   モジュールがスレーブ・モジュールの場合には、当該モジュールのマスタ・モジュールに関する情報と、
   を含むことを特徴とする請求項２記載の試験システム。
4. 前記ポート番号に換えて、前記複数のモジュールのそれぞれを識別可能な任意の識別子を利用することを特徴とする請求項１乃至３のいずれかに記載の試験システム。
5. 前記試験システムは、オープン・アーキテクチャに基づくシステムであり、
   前記二以上のモジュールは、前記オープン・アーキテクチャの標準仕様に準拠するものである、
   ことを特徴とする請求項１乃至４のいずれかに記載の試験システム。
6. 被試験デバイスに試験信号を供給可能な複数のモジュールと、前記複数のモジュールを制御可能なモジュール制御ドライバとを備える試験システムにおいて、前記複数のモジュールの各々のリソースを個別に制御する方法であって、
   前記複数のモジュールそれぞれのリソースとポート番号に関する情報を含むモジュール設定ファイルを読み出すステップと、
   前記モジュール設定ファイルに規定された内容に基づいて、前記複数のモジュールのリソース定義を特定して、前記モジュール制御ドライバに実装するステップと、
   前記モジュール設定ドライバが、ポート番号を利用して、前記複数のモジュールの各々のリソースを個別に制御するステップと、
   を備える試験システムのモジュール制御方法。
7. 請求項６に記載のモジュール制御方法をコンピュータに実行させるためのプログラム。
8. 請求項７に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images