テスタ機器モジュールのインストール及び構成管理を実行する方法及びシステム
【課題】モジュール式試験システムにおいて、複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント、及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理する。
【解決手段】モジュール式試験システムと互換性のあるＴＯＳバージョン、及びハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントをアーカイブにインストールする。次に、ハードウェア試験モジュールバージョン及びＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルを作成し、モジュール式試験システムに対しシステムプロファイルを選択する。システムプロファイルは、１組の互換性のあるベンダソフトウェアコンポーネントと、特定のハードウェア試験モジュールバージョンを試験する選択されたＴＯＳとを含む。
【解決手段】モジュール式試験システムと互換性のあるＴＯＳバージョン、及びハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントをアーカイブにインストールする。次に、ハードウェア試験モジュールバージョン及びＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルを作成し、モジュール式試験システムに対しシステムプロファイルを選択する。システムプロファイルは、１組の互換性のあるベンダソフトウェアコンポーネントと、特定のハードウェア試験モジュールバージョンを試験する選択されたＴＯＳとを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、集積回路を試験する分野に関する。特に、本発明は、テスタ機器モジュールのインストール及び構成管理を実行する方法及びシステムに関する。
【０００２】
本出願は、本出願の譲受人に譲渡され且つ参照により全体として本明細書に援用される、２００４年１２月９日に出願された「Method and System for Performing Installation and Configuration Management of Tester Instrument Modules」と題する米国仮特許出願第６０／６３５，０９４号の利益を主張する。
【背景技術】
【０００３】
試験装置のコストが高い主な理由は、従来のテスタアーキテクチャが特殊化した性質を有するということである。各テスタ製造業者は、アドバンテスト、テラダイン（Teradyne）及びアジレント（Agilent）等の会社間で互換性がないだけでなく、アドバンテストが製造するＴ３３００、Ｔ５５００及びＴ６６００シリーズのテスタ等、一会社内のプラットフォーム間でも互換性がない多数のテスタプラットフォームを有する。これら非互換性のために、各テスタは、独自の特殊なハードウェアコンポーネント及びソフトウェアコンポーネントを必要とし、これら特殊なハードウェアコンポーネント及びソフトウェアコンポーネントは他のテスタで使用することができない。さらに、試験プログラムを１つのテスタから別のテスタに移植するため、且つサードパーティソリューションを開発するために著しい労力が必要である。或るプラットフォームに対してサードパーティソリューションが開発される場合であっても、それを異なるプラットフォームに移植し又はそこで再使用することはできない。１つのプラットフォームから別のプラットフォームへの変換プロセスは、一般に複雑で且つ誤りが発生しやすく、その結果、労力及び時間が追加され試験コストが増大する。
【０００４】
特殊化したテスタアーキテクチャの別の問題は、所与のテスタに対し、すべてのハードウェア及びソフトウェアが固定の構成のままであるということである。被試験デバイス（ＤＵＴ）又はＩＣを試験するために、試験データ、信号、波形、並びに電流レベル及び電圧レベルを定義するテスタ機能とともに、ＤＵＴ応答を収集しＤＵＴに試験を合格したか又は不合格であったかを確定するテスタ機能のうちのいくつか又はすべてを使用する専用試験プログラムが開発されている。
【０００５】
オープンアーキテクチャ試験システムは、従来の試験システムの上記問題に対する解決法を提供する。オープンアーキテクチャ試験システムの一例は、参照により全体として本明細書に援用される「Method and Structure to Develop a Test Program for Semiconductor Integragated Circuits」と題する米国特許出願第１０／７７２，４３４号に記載されている。オープンアーキテクチャ試験システムを、多種多様のベンダハードウェア試験モジュール及びそれらの対応するＤＵＴをサポートするように構成することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、かかるオープンアーキテクチャ試験システムを実施する際の難題のうちの１つは、テスタオペレーティングシステム（ＴＯＳ）に多数のバージョンがある可能性があるということである。さらに、各ベンダハードウェア試験モジュールには複数のバージョンがある可能性があり、ベンダハードウェア試験モジュールの各バージョンには、その対応するソフトウェアコンポーネントのバージョンがある可能性がある。テスタオペレーティングシステム、ベンダハードウェア試験モジュール及びソフトウェアコンポーネントのバージョンは、ベンダハードウェア試験モジュールにおいて試験を実行するために互いにシームレスに作業する必要がある。したがって、複数のベンダハードウェア試験モジュールバージョン、ソフトウェアコンポーネントバージョン、及び多種多様のベンダハードウェア試験モジュールを使用してＤＵＴを試験するＴＯＳバージョンを管理することができるモジュール式試験システムが必要とされている。
【課題を解決するための手段】
【０００７】
一つの実施の形態において、モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理する方法は、モジュール式試験システムと互換性のあるＴＯＳバージョンをアーカイブにインストールすること、及び、ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントをアーカイブにインストールすることを含む。本方法はさらに、ハードウェア試験モジュールバージョン及びＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルを作成すること、モジュール式試験システムに対しシステムプロファイルを選択することであって、システムプロファイルは、１組の互換性のあるベンダソフトウェアコンポーネントと、特定のハードウェア試験モジュールバージョンを試験する選択されたＴＯＳとを含む、選択すること、及びモジュール式試験システムにおいて選択されたＴＯＳを起動することを含む。
【０００８】
別の実施の形態において、複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理するシステムは、
少なくとも１つのサイトコントローラを制御するシステムコントローラと、
少なくとも１つのハードウェア試験モジュールを制御する少なくとも１つのサイトコントローラと、
モジュール式試験システムと互換性のあるテストオペレーティングシステムバージョンと、
ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントと、
ハードウェア試験モジュールバージョン及びＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルと、
を具備する。
【０００９】
本発明の上述した特徴及び利点とともにその追加の特徴及び利点について、添付の図面と共に本発明の実施形態の詳細な説明を読んだ後により明確に理解され得るであろう。
【発明を実施するための最良の形態】
【００１０】
テスタ機器モジュールのインストール及び構成管理を実行する方法及びシステムを提供する。以下の説明を、当業者が本発明を作成し使用することができるように提示する。特定の実施形態及び応用形態の説明は、単に例として提供する。本明細書で説明する例に対するさまざまな変更及び組合せは、当業者には容易に明らかになるであろう。また、本明細書で定義する一般原理を、本発明の精神及び範囲から逸脱することなく他の例及び適用に応用してもよい。このため、本発明は、説明され且つ示される例に限定されるように意図されておらず、本明細書で開示する原理及び特徴に一致する最も広い範囲を付与される。
【００１１】
図１ａは、本発明の一実施形態によるオープンアーキテクチャシステムを示す。図１aに示すように、システムコントローラ（ＳｙｓＣ）１０２は、複数のサイトコントローラ（ＳｉｔｅＣ）１０４に結合される。システムコントローラを、ファイルにアクセスするためにネットワークに結合してもよい。各サイトコントローラは、モジュール接続イネーブラ１０６を通して、試験サイト１１０に位置する１つ又は複数の試験モジュール１０８を制御するように結合される。モジュール接続イネーブラ１０６は、接続されたハードウェアモジュール１０８の再構成を可能にし、また、データ転送用のバスとしての役割を果たす（パターンデータをロードする、応答データを収集する、制御を提供する等）。あり得るハードウェアインプリメンテーションには、専用接続、スイッチ接続、バス接続、リング接続及びスター接続が含まれる。モジュール接続イネーブラ１０６を、たとえばスイッチマトリクスによって実施してもよい。各試験サイト１１０は、被試験デバイス（ＤＵＴ）１１２に関連し、ＤＵＴ１１２は、ロードボード１１４を介して対応するサイトのモジュールに接続される。一実施形態では、単一サイトコントローラを複数のＤＵＴサイトに接続してもよい。
【００１２】
システムコントローラ１０２は、全体的なシステムマネージャとしての役割を果たす。システムコントローラ１０２は、サイトコントローラアクティビティを調整し、システムレベルの並列試験戦略を管理し、さらにシステムレベルのデータロギング及びエラー処理サポートとともにハンドラ／プローブ制御を提供する。動作設定に応じて、システムコントローラ１０２を、サイトコントローラ１０４の動作とは別のＣＰＵに配置してもよい。別法として、システムコントローラ１０２とサイトコントローラ１０４とにより共通のＣＰＵを共有してもよい。同様に、各サイトコントローラ１０４を、それ自体の専用ＣＰＵ（中央処理装置）に配置してもよく、又は同じＣＰＵ内の別個のプロセス又はスレッドとして配置してもよい。
【００１３】
個々のシステムコンポーネントを、統合されたモノリシックシステムの論理コンポーネントとみなしてもよく、必ずしも分散システムの物理コンポーネントとしてみなさなくてもよいということを理解して、システムアーキテクチャを、概念的に図１ａに示す分散システムとして想定してもよい。
【００１４】
図１ｂは、モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法を示す。ＴＯＳの複数のバージョンと、ユーザＳＤＫ及びベンダＳＤＫのその関連するバージョンとが、ベンダドライバソフトウェアの複数のバージョンとともにアーカイブに格納される。オープンアーキテクチャ試験システムのインストール及び構成管理（Installation and Configuration Management）（ＩＣＭ）システムの目的は、ベンダが、自身のハードウェアモジュールをサポートするようにドライバソフトウェアコンポーネントを開発することができるようにすること、及び、ユーザが、テスタ又は開発プラットフォームで動作する互換性のあるベンダドライバソフトウェア及びＴＯＳバージョンを選択することができるようにすることである。ＩＣＭシステムはまた、テスタ又は開発プラットフォームにこれらの選択された構成をインストールすること、及び任意に、選択された構成を起動することを管理する。
【００１５】
ＩＣＭシステムは、オープンアーキテクチャ試験システムのＴＯＳを管理するための要件及び管理することに関与するアクティビティについて説明する。オープンアーキテクチャ試験システムのＩＣＭには、４つの原則アクティビティが含まれる。
１．インストール
これは、オープンアーキテクチャ試験システムコンポーネントを、後に起動するか又は配備するためにアーカイブにコピーする行為を言う。
２．構成
これは、ユーザが、ＩＣＭシステムと対話することによって、ソフトウェア構成を起動に使用されるシステムプロファイルとして作成し、保存し、変更することができるようにする行為を言う。
３．起動
これは、選択されたソフトウェア構成（すなわちプロファイル）を、特定のテスタにおいてアクティブなものにする、すなわちそれを配備する行為を言う。
４．監査
これは、特定の試験システムにおいて目下アクティブなソフトウェアコンポーネント及びハードウェアコンポーネントのリストを提供する行為を言う。
【００１６】
本文書は、これらのアクティビティの各々に対する仕様を提供する。以下の論考において、ソフトウェア及びハードウェアそれぞれを指して、既知の略語ＳＷ及びＨＷを使用する。
【００１７】
なお、インストール及び構成はＩＣＭ特有のアクティビティ（概念的には特定のテスタに対してリモートに実行することができる）であるが、起動及び監査はテスタ特有であり、一定のオープンアーキテクチャ試験システムのＴＯＳコンポーネント、主にオープンアーキテクチャ試験システムのテスタ制御デーモン（Tester Control Daemon）（ＴＣＤ）からの支援を必要とする。このため、本文書はまた、ＩＣＭアクティビティに関与するＴＣＤ及びＴＯＳのいくつかの面とともに、ＴＣＤ自体のインストールについても説明する。この目的のために、テスタ制御及びＴＯＳスタートアップセクションがまず、オープンアーキテクチャテスタ制御及びＴＯＳシステムのスタートアップ手続きの説明を提供する。
【００１８】
また、オープンアーキテクチャ試験システムソフトウェア「パッチ」のリリースは、オープンアーキテクチャ試験システムソフトウェアコンポーネントを、より総合的なソフトウェアリリースの合間に修正し強化することの必須部分である。この目的のために、ソフトウェアパッチリリースセクションは、まず、オープンアーキテクチャ試験システムソフトウェアパッチリリースを作成し、配布し、使用する際に従う方法の説明を提供する。
【００１９】
（テスタ制御及びＴＯＳスタートアップ）
このセクションでは、オープンアーキテクチャテスタ制御及びスタートアップ手続きについて説明する。読者は、特に、オープンアーキテクチャ試験システムのシステムコントローラ（ＳｙｓＣ）及びサイトコントローラ（複数可）（ＳｉｔｅＣ）を備える汎用分散システムとしてのＴＯＳの編成に提示されるようなオープンアーキテクチャテスタアーキテクチャの基本に熟知しているものと想定する。
【００２０】
（テスタ制御デーモン）
オープンアーキテクチャ試験システムのＴＯＳの全般的な制御は、オープンアーキテクチャ試験システムのテスタ制御デーモン（ＴＣＤ）によって実行される。ＴＣＤに対する仕様は、以下のように要約される。
【００２１】
オープンアーキテクチャ試験システムのテスタ制御デーモンは、以下の機能に関与する。
システムブートアップ時の、若しくはユーザコマンドに基づく、オープンアーキテクチャ試験システムのＴＯＳのスタートアップ及び初期化、並びにシステム初期化が成功した後の、ユーザ定義オープンアーキテクチャ試験システムアプリケーションの任意のスタートアップ。
ＴＯＳコアサービスに接続された任意のオープンアーキテクチャ試験システムアプリケーションのシャットダウンを含む、ユーザコマンドに基づく任意のオープンアーキテクチャ試験システムのＴＯＳのシャットダウン。
システムプロファイルによって定義されるようなオープンアーキテクチャ試験システムの特定のソフトウェア構成の起動又は配備。ここで、「バージョン切替」は、本質的に目下有効なプロファイル以外のプロファイルの起動である。
【００２２】
オープンアーキテクチャ試験システムソフトウェア構成のシステムプロファイルについて以下に説明する。これは、特定のオープンアーキテクチャ試験システムソフトウェア構成を定義するために必要な情報の集まり全体である。論考の残りの部分では、テスタ制御デーモンを、Ｗｉｎｄｏｗｓオペレーティングシステム（ＯＳ）で使用されるものとして言及するが、概念は一般的であり、あらゆるオープンアーキテクチャ試験システムに適用可能である。
【００２３】
ＷｉｎｄｏｗｓシステムのＴＣＤは、ＳｙｓＣ及び全ＳｉｔｅＣにインストールされ且つそこで自動的に実行されるＷｉｎ３２サービス（それは、Ｗｉｎｄｏｗｓコントロールパネルを使用して利用可能なサービスダイアログボックスにおけるインストール済みサービスのリストに現れる）である。それは、上記機能を実行する（システムコントローラ側における）インタフェースメソッドを提供するＣＯＭコンポーネントである。それは、オープンアーキテクチャ試験システムソフトウェア（オンラインバージョンは、システムインテグレータによって工場出荷時にインストールされている）とは別個にインストールされ、ＯＳブート時における自動スタートアップのためにＷｉｎｄｏｗｓサービスコントロールマネージャに登録される。なお、主ＴＣＤは、システムコントローラで実行しているものであるが、補助ＴＣＤは、サイトコントローラで実行し、主ＴＣＤの後援のもとに個々のサイトコントローラを立ち上げるように作業することに関与する。
【００２４】
（ＴＯＳ制御及び工場出荷時ディレクトリ）
デーモンを適当にインストールし機能させるために、すべてのオープンアーキテクチャ試験システムは、ＴＯＳ制御コンポーネント及び工場出荷時情報を収容する標準ディレクトリ構造を有するように事前構成される。これを、以下の仕様として要約する。
すべてのオープンアーキテクチャ試験システムのシステムコントローラ及びサイトコントローラは、利用可能な場所<MAINTENANCE_ROOT>をルートとする、且つ図２ａに示し表１に説明するような構造を有する、ＴＯＳ制御及び工場出荷時ディレクトリ構造を有するように構成される。
【００２５】
表１は、図２ａに示す構造について説明する。なお、第１列に列挙するディレクトリは、<MAINTENANCE_ROOT>に関連している。
【００２６】
【表１】
【００２７】
<MAINTENANCE_ROOT>/binにインストールされるＴＣＤコントローラアプリケーションは、「start（開始）」、「stop（停止）」、「activate（起動）」等の基本テスタシステム制御コマンドをＴＣＤに送ることができる単純なコマンドラインアプリケーションであるように意図されている。Ａｄｖａｎｔｅｓｔ Ｔ２０００システムには、これらのタスクを実行するアプリケーションt2kctrlが搭載されている。
【００２８】
<MAINTENANCE_ROOT>/cfgディレクトリの内容は、システムインテグレータによって異なる可能性があり、いずれの場合にも、それは、対応するＴＣＤ又はそのインストーラが機能するために必要なテスタ情報を含む。たとえば、Ａｄｖａｎｔｅｓｔ Ｔ２０００テスタシステムは、<SystemDrive>:/T2000Maintenance/cfgに以下の情報を配置する。なお、<SystemDrive>は、Ｗｉｎｄｏｗｓによって事前定義される環境変数であり、デフォルトとして、Ｗｉｎｄｏｗｓ２０００では「C:」である。
【００２９】
工場で提供されるすべてのサイトコントローラの内部システムＩＰ名及びアドレスとともに、オープンアーキテクチャ試験システムソフトウェア起動プロセスがその義務を遂行するために必要な任意の特別なオープンアーキテクチャ試験システムのユーザアカウント及びパスワード情報を指定する、サイトコントローラの工場出荷時構成（標準Ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマット）。このファイルは、OASISSiteInfo.iniと命名される。
【００３０】
ユーザは、このファイルをオンラインシステムで変更してはならない。オフラインシステムの場合、ユーザは、必要な場合、デフォルト（ＳｙｓＣと同じマシンにおいて単一ＳｉｔｅＣを指定する）からこれを変更してもよい。オンライン及びオフライン両方で使用されるシステムの場合、オンラインモードは、最初のオンライン工場出荷時構成ファイル（又は工場認可技術者がハードウェアレイアウトの変更を反映するように最も最近更新した構成ファイル）を使用する必要がある。
タイプ、名前、動作周波数等、全テスタ特性と、
工場において構成されたハードウェアモジュール及びそれらのボード特有の詳細と、
ハードウェアモジュールが接続される工場において構成されたオープンアーキテクチャ試験システムモジュール接続イネーブラ（ＭＣＥ）ポートと、
各ハードウェアモジュール（ある場合）へのオープンアーキテクチャ試験システム同期化マトリクス接続と、
ハードウェアモジュールに対するテストヘッド接続と
に関する情報を含む工場出荷時仕様書（ＦＤＥＦ）ファイル。
【００３１】
ユーザは、このファイルをオンラインシステムで変更することはできず、変更は、マシンの物理構成を変更する認可された保守要員のみが行うことができる。オフラインシステムの場合、工場出荷時仕様書ファイルは、ある場合は提供される試験例と一貫する仮想マシン構成を定義し、ユーザは、必要な場合、自身の仮想テスタを構成するようにこれを変更してもよい。オンライン及びオフラインの両方で使用されるシステムの場合、オンラインモードは、最初のオンライン工場出荷時構成ファイル（又は、工場認可技術者がハードウェアレイアウトの変更を反映するように最も最近更新した構成ファイル）を使用する必要がある。
【００３２】
（テスタ状態及び状態遷移）
上述したように、ＴＣＤは、オープンアーキテクチャ試験システムのＴＯＳを開始することに関与する。ＴＯＳ立上げのメカニズムを理解するために、まずＴＯＳがとり得る状態と、それらの間で可能な遷移とを理解することが必要である。オープンアーキテクチャテスタの状態遷移図を図２ｂに示す。
【００３３】
図２ｂの状態の意味は以下の通りである。
状態０：テスタシステムはアイドル状態である。システムコントローラのＴＣＤは実行しておらず、ＴＯＳは実行していない。
状態１：少なくともシステムコントローラにおいてＴＣＤは実行しているが、ＴＯＳはまだ機能していない。
状態２：オープンアーキテクチャ試験システムのシステムコントローラプロセスは実行しているが、まだ初期化されておらず、ＴＣＤはすべてのサイトコントローラにおいて実行していてもいなくてもよく、オフラインモードでは、オープンアーキテクチャ試験システムのテスタエミュレータプロセスはまだ実行していない。
状態３'：（オフラインモードのみ）オープンアーキテクチャ試験システムのテスタエミュレータは、（単一の指定された）サイトコントローラコンピュータにおいて実行している。
状態３：少なくともサイトコントローラ１（ＳＩＴＥＣ−１）は、正しく初期化されており、システムはデフォルトパーティション化状態であり（すなわち、すべてのハードウェアモジュールがＭＣＥを介してＳＩＴＥＣ−１に接続されている）、さらに、すべての指定されたサイトコントローラもまた正しく初期化されてもよい。この時点で、システムは「準備完了」状態である、すなわちテストプランロード要求を受け入れるように構成されている。
状態４：ユーザテストプランは、１つ又は複数の互換性のあるサイトコントローラに正しくロードされており、その一部として、システムはテストプラン要件に適応するように（再）パーティション化されている可能性がある。
【００３４】
図２ｂに示す状態遷移をもたらすイベントについて後述する。ここでは、表記「t(x,y)」は、状態ｘから状態ｙへの遷移を指定する（なお、後の論考において言及するクライアントは、システムコントローラＴＣＤのクライアントであり、ＴＣＤにおいて適当なインタフェースを接続し且つ使用する、リモート又はローカルの任意のアプリケーションであってもよい）。
t(0,0) Ｗｉｎｄｏｗｓブートプロセスからのコマンド（又は対話式の手動「開始」要求）を受け取っても、Ｗｉｎｄｏｗｓサービスコントロールマネージャは、Ｗｉｎｄｏｗｓブートアップ中にシステムコントローラにおいてＴＣＤを始動できない。
t(0,1) Ｗｉｎｄｏｗｓブートプロセスからのコマンド（又は対話式の手動「開始」要求）を受け取ると、Ｗｉｎｄｏｗｓサービスコントロールマネージャは、システムコントローラにおいて、且つ恐らくはサイトコントローラにおいてＴＣＤを正しく始動する。
t(1,1) ＴＯＳを「始動する」クライアントコマンドを受け取っても、システムコントローラのＴＣＤは、ＴＯＳシステムコントローラプロセスを始動できない。
t(1,2) ＴＯＳを「始動する」クライアントコマンドを受け取ると、システムコントローラのＴＣＤは、ＴＯＳシステムコントローラプロセスを正しく始動する。
t(2,2) ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスの初期化が失敗する、すなわち、ＴＯＳシステムコントローラプロセスは、オフラインモードでオープンアーキテクチャ試験システムのテスタエミュレータプロセスを始動できず、又は少なくともＳＩＴＥＣ−１においてＴＯＳサイトコントローラプロセスを始動し初期化することができない。
t(2,3') （オフラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、（単一の指定された）サイトコントローラコンピュータにおいてオープンアーキテクチャ試験システムのエミュレータプロセスを正しく始動する。
t(3',3)* （オフラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、少なくともＳＩＴＥＣ−１に対するＴＯＳサイトコントローラプロセス（及び恐らくはすべての指定されたサイトコントローラのプロセス）を正しく始動し初期化する。
t(3',2) （オフラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、少なくともＳＩＴＥＣ−１に対するＴＯＳサイトコントローラプロセスを始動し初期化できない（エミュレータプロセスは終了する）。
t(2,3)* （オンラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、少なくともＳＩＴＥＣ−１において（且つ恐らくはすべての指定されたサイトコントローラにおいて）ＴＯＳサイトコントローラプロセスを正しく始動し初期化する。
t(3,3) ユーザテストプランをロードするユーザコマンドを受け取っても、ＴＯＳは指定されたテストプランをロードできない。
t(3,4) テストプランをロードするユーザコマンドを受け取ると、ＴＯＳは、指定されたテストプランに関連するソケットの要件により（必要な場合）システムを正しく（再）パーティション化した後、指定されたサイトコントローラ（複数可）にテストプランを正しくロードする。
t(4,4) （同じか又は異なる）テストプランを（リ）ロードするユーザコマンドを受け取ると、ＴＯＳは、指定されたテストプランに関連するソケットの要件により（必要な場合）システムを正しく（再）パーティション化した後、指定されたサイトコントローラ（複数可）にテストプランを正しく（リ）ロードする。
t(3,1) ＴＯＳを「シャットダウン」するクライアントコマンドを受け取ると、ＴＣＤはＴＯＳを停止する。
t(4,1) ＴＯＳを「シャットダウン」するクライアントコマンドを受け取ると、ＴＣＤは、ある場合は実行中のテストプランを停止した後にＴＯＳを停止する。
なお、*は、その遷移に、ユーザ指定アプリケーションを始動しようと試みるＴＯＳシステムコントローラプロセスが付随することを示し、アプリケーションはＴＯＳの一部でないため、これらのアプリケーションのうちのいずれか又はすべてを始動できないことが正しいＴＯＳ初期化の失敗の要素とはならない。
【００３５】
上に示した遷移に加えて、システムコントローラで実行されるＷｉｎｄｏｗｓ「シャットダウン」コマンド（又はシステムの物理的なパワーダウン）により、テスタは、その時点での状態に係りなく状態０にリセットされる。
【００３６】
オープンアーキテクチャ試験システムのＴＯＳが立ち上げられるプロセスは以下の通りである（環境変数OASIS_INSTALLATION_ROOT、OASIS_ACTIVE_CONFIGS、OASIS_TOS_SETUP_FILE、OASIS_TPL_SETUP_FILE、OASIS_TOOLS_SETUP_FILE、OASIS_MACHINE_DIR及びOASIS_TEMPはすでに正しく定義されており、システムプロファイルは選択されているものと想定する）。
１．システムパワーオン（又はブートアップ）時、Ｗｉｎｄｏｗｓサービスコントロールマネージャはシステムコントローラ及びサイトコントローラにおいてＴＣＤを始動する。
２．システムコントローラのＴＣＤは、システムプロファイルが有効であることを検証し、サイトコントローラのプロファイル指定構成、すなわちファイル$OASIS_ACTIVE_CONFIGS/OAISSys.cfgを読み出し、ＴＯＳシステムコントローラプロセスを始動する。
３．そして、ＴＣＤは、ＴＯＳシステムコントローラプロセスにおいてinitialize()メソッドを呼び出す。これにより、
ａ．動作モードがオフラインである場合にのみ、テスタエミュレータプロセスが（単一の指定された）サイトコントローラコンピュータにおいて始動し、
ｂ．要求される各サイトコントローラのＴＣＤがそのＴＯＳサイトコントローラプロセスを始動し、
ｃ．各ＴＯＳコントローラプロセスにおいてinitialize()メソッドが呼び出され、
ｄ．少なくともＳＩＴＥＣ−１が正しく初期化された後、システムがデフォルトパーティション化される（すべてのハードウェアモジュールがＭＣＥを介してＳＩＴＥＣ−１に接続される）。
４．そして、ＴＣＤは、目下アクティブなプロファイルにおいて自動セットアップのためにリスト化された任意のユーザアプリケーションを指定された順序で始動しようと試みる。
【００３７】
ステップ００のうちのいずれかの間の失敗により、上述したような対応するシステム状態遷移をもたらす。ステップ０又は０における失敗は、Ｗｉｎｄｏｗｓイベントログに記録される。ステップ０における失敗は、ＴＯＳシステムコントローラプロセスとともにログとして記録され、それに接続するあらゆるクライアントアプリケーションが後に検索するために利用することができるようになる。
【００３８】
任意の自動アプリケーションスタートアップ
上述したように、オープンアーキテクチャ試験システムは、ユーザが、正しいＴＯＳスタートアップに続いて自動的にスタートアップされるべきアプリケーションを追加することができるようにする。ＯＣＴｏｏｌによって、ユーザは、自身の選択したかかるアプリケーションをシステムプロファイルの一部として指定することができる。かかるプロファイルが特定のテスタで起動されると（すなわち、そのプロファイルによって指定された構成が最新になると）、正しいＴＯＳ初期化の完了時にステップ０上のが実行される。
【００３９】
これを行うために、ＴＣＤは、ファイルOASISVer.cfgのスタートアップセクションを読み出す。これは、選択されたシステムプロファイルの属性を指定するデータファイルであり、標準Ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマットである。それは、そのセクションにおける各ラインを、新たなアプリケーションを立ち上げるコマンドラインとして扱う。アプリケーションはＴＯＳの一部でないため、リスト化されたアプリケーションのいずれか又はすべてを立ち上げることができないことは、ＴＯＳ立上げに関する限りエラー状態の要素とはならない。しかしながら、任意のかかる失敗は、ＴＯＳシステムコントローラプロセスに注記され格納される（アプリケーションが後に取り出すため）。
【００４０】
インストール
オープンアーキテクチャ試験システムのインストールは、３つの主要コンポーネントのインストールを含み、これらのコンポーネントの各々は独立してインストールされる。
１．オープンアーキテクチャ試験システムのテスタ制御デーモン（ＴＣＤ、オープンアーキテクチャ試験システムのソフトウェア起動又は配備の機能をカプセル化する）。
２．オープンアーキテクチャ試験システムの構成ツール（ＯＣＴｏｏｌ）。
３．オープンアーキテクチャ試験システムのシステムソフトウェア。
【００４１】
このセクションでは、これらのコンポーネントの各々に対してインストールプロセスを説明する。
【００４２】
（ＴＣＤインストール）
オープンアーキテクチャ試験システムのＴＣＤパッケージは、他のいかなるオープンアーキテクチャ試験システムコンポーネントからも独立してインストールされる。工場出荷状態の（factory-fresh）オンラインシステムの場合、ＴＣＤパッケージは通常プリインストールされる可能性がある。オフラインシステムの場合、且つＴＣＤに対する更新全般の場合、インストーラは、システムインテグレータによって提供される可能性がある。
【００４３】
Ｗｉｎｄｏｗｓでは、オープンアーキテクチャ試験システム<MNAINTENANCE_ROOT>は、必然的に、通常のＷｉｎｄｏｗｓ<SytemDrive>（「C:」ドライブであることが多い）のディレクトリとなる。それは、<SytemDrive>が、存在することが保証されているためである。たとえば、オープンアーキテクチャ試験システムのＡｄｖａｎｔｅｓｔ Ｔ２０００インプリメンテーションは、システムコントローラ及びサイトコントローラのディレクトリ「C:/T2000Maintenance」にルートを配置する。以下の論考では、<SystemDrive>は「C:」であるものとする。ＴＣＤパッケージのインストール中に辿るステップは以下の通りである。
１．上述したように、いくつかのコンポーネントが<MAINTENANCE_ROOT>にインストールされるため、<MAINTENANCE_ROOT>はＳｙｓＣ及びＳｉｔｅＣに存在する。
ａ．<MAINTENANCE_ROOT>が存在しない場合、ＴＣＤインストーラがそれを生成する。
ｂ．サイトコントローラ工場出荷時構成ファイル（Ａｄｖａｎｔｅｓｔ Ｔ２０００システムにおけるC:/T2000Maintenance/cfg/OASISSiteInfo.ini）が存在しない場合、インストーラがまた、インストールを実行している人からの入力に基づいてそれを生成する。
ｃ．オープンアーキテクチャ試験システム工場出荷時仕様書（ＦＤＥＦ）ファイル（Ａｄｖａｎｔｅｓｔ Ｔ２０００システムにおけるC:/T2000Maintenance/cfg/OASISHW.def）が存在する場合、
ｉ．オンラインシステムの場合、それはまったく置換も変更もされず、
ｉｉ．オフラインシステムの場合、オープンアーキテクチャ試験システムで提供される例と互換性のある仮想テスタをモデル化するように意図された<FDEF-name>.<example>と命名されたプリパッケージバージョンが、<MAINTENANCE_ROOT>/cfgにコピーされ、ユーザは、既存のＦＤＥＦファイルをこのファイルと置き換えるように通知される（ユーザがオープンアーキテクチャ試験システム例で作業したい場合）。
ｄ．ＦＤＥＦファイルが存在しない場合、
ｉ．オンラインシステムの場合、サンプルＦＤＥＦファイルがインストールされ、ユーザに対し、ユーザがインストールしたハードウェアと互換性があるようにそれを更新するよう警告される。
ｉｉ．オフラインシステムの場合、このファイルのプリパッケージバージョンが、ＦＤＥＦファイルとしてインストールされる（オープンアーキテクチャ試験システムによって必要とされる標準名で）。
２．インストーラは、<SystemRoot>/system32にＴＣＤバイナリをインストールし、あらゆる必要なＣＯＭコンポーネント登録のためにＷｉｎｄｏｗｓレジストリエントリを設定する。
３．インストーラは、ＴＣＤに対し以下の構成特性を設定する。
ａ．AutoStart（自動始動）：これは、ＷｉｎｄｏｗｓシステムブートによってＳｙｓＣ ＴＣＤがオープンアーキテクチャ試験システムのＴＯＳを自動的に始動するか（TRUE（真））又は始動しないか（FALSE（偽））を指定する。デフォルトはTRUEであり、インストールを実行している人は、必要な場合、それをFALSEに設定してもよい。
ｂ．Mode（モード）：これは、ＴＯＳがONLINE（オンライン）動作モード（適用可能な場合）で始動されるべきか又はOFFLINE（オフライン）動作モードで始動されるべきかを指定する。デフォルトはONLINEであり、インストールを実行している人は、必要な場合、それをOFFLINEに設定してもよい。
ｃ．Configuration（構成）：これは、ＴＯＳがコンポーネントのDEBUG（デバッグ）バージョンで始動されるべきか又はRELEASE（リリース）バージョンで始動されるべきかを指定する。デフォルトはRELEASEであり、インストールを実行している人は、必要な場合、それをDEBUGに設定してもよい。
４．インストーラは、ＴＣＤコントローラアプリケーション（t2kctrl）とその関連するＤＬＬを<MAINTENANCE_ROOT>/binにインストールする。
５．オープンアーキテクチャ試験システムによって要求される以下のオペレーティングシステム環境変数の各々に対し、インストーラは、（ｉ）それがすでに設定されているかを判断し、（ｉｉ）設定されていない場合、それをユーザ指定値に設定する。
ａ．OASIS_INSTALLATION_ROOT
ｂ．OASIS_ACTIVE_CONFIGS
ｃ．OASIS_MACHINE_DIR
ｄ．OASIS_TEMP
６．インストーラは、<MAINTENANCE_ROOT>/bin及び$OASIS_INSTALLATION_ROOT/binをＷｉｎｄｏｗｓシステムＰＡＴＨ環境変数に追加する（Ｗｉｎｄｏｗｓの規約により、<SystemRoot>/system32はすでにシステムＰＡＴＨ環境変数にあると想定する）。
【００４４】
なお、ステップ０上のに示すように、ＴＣＤ及びそれが依存するＤＬＬは、Ｗｉｎｄｏｗｓ<SystemRoot>/system32ディレクトリ（Ｗｉｎｄｏｗｓ２０００における<SystemDrive>/WINNT/system32であり、C:/WINNT/system32であることが最も多い）にインストールされる。それはその場所がＷｉｎｄｏｗｓサービスの適当な動作を保証するためである。さらに、<MAINTENANCE_ROOT>は、システムが適当に機能するためにシステムコントローラ及びサイトコントローラに存在する必要がある。このため、<MAINTENANCE_ROOT>（並びに<SystemRoot>/system32のＴＣＤ及びその関連するＤＬＬ）は、これらのコンポーネントが存在するローカルディスクを再フォーマットすることが望まれる場合、注意深くバックアップがとられ且つ復元されなければならない。オープンアーキテクチャテスタの任意のシステムプロファイルの起動は、インストールされ且つテスタで利用可能であるＴＣＤによって決まる。ＴＣＤは、本質的に、オープンアーキテクチャ試験システムソフトウェアから独立しているため、オープンアーキテクチャ試験システムソフトウェアのすべてのリリースと後方互換性があることが必要である。
【００４５】
（ＯＣＴｏｏｌインストール）
オープンアーキテクチャ試験システムの構成ツールＯＣＴｏｏｌは、オープンアーキテクチャ試験システムソフトウェアとは別個のパッケージで配布されインストールされる。
【００４６】
ＯＣＴｏｏｌのインストーラによって、ユーザは、ＯＣＴｏｏｌに対しインストール場所を選択することができる。ＯＣＴｏｏｌによって、ユーザは、テスタから独立したオープンアーキテクチャ試験システムのシステムプロファイルを作成し保存することができる。このため、オープンアーキテクチャ試験システムソフトウェアがインストールされるアーカイブ場所に任意の特定のテスタがアクセスすることができる限り、そのテスタに対してリモートの場所にそれを概念的にインストールすることができる。しかしながら、目下アクティブなシステムのルートである$OASIS_INSTALLATION_ROOTをルートとするディレクトリツリー内にある場所にそれをインストールしないように注意する必要がある。それは、後に、異なるプロファイルに対応するシステムを起動する結果、喪失する可能性があるためである。
【００４７】
ＴＣＤのように、ＯＣＴｏｏｌは本質的にオープンアーキテクチャ試験システムソフトウェアから独立しているため、オープンアーキテクチャ試験システムソフトウェアのすべてのリリースと後方互換性があることが必要である。
【００４８】
（オープンアーキテクチャ試験システムソフトウェアのインストール）
オープンアーキテクチャ試験システムソフトウェアのインストールとは、オープンアーキテクチャ試験システムソフトウェアコンポーネント（最終的にはファイル）を、オペレーティングシステム環境変数OASIS_ARCHIVE_ROOTによって定義される場所に物理的にコピーする行為を言う。この場所を、以下アーカイブと呼ぶ。アーカイブは、システムのユーザのためにオープンアーキテクチャ試験システムのベンダ及びシステムインテグレータが提供するファイルを含む。なお、これは、配備場所又はランタイム場所とは別個である。配備場所とは対照的に、アーカイブ場所は、ソフトウェアが配備されるテスタシステムで実行するＴＣＤがアクセス可能である限り、テスタシステムから物理的にリモートであってもよい。
【００４９】
インストールプロセスは、ＴＯＳコンポーネント及びベンダコンポーネントに対して同一である。各インストールされたファイルは、コンポーネントの特性を指定するコンポーネント構成レコード（Component Configuration Record）（ＣＣＲ）を有する。このため、以下の２つの要件は、インストールプロセスの仕様を要約する。
オープンアーキテクチャ試験システムソフトウェアのインストールは、定義されたアーカイブ場所にファイルをコピーする。この場所は、環境変数OASIS_ARCHIVE_ROOTによって指定される。
アーカイブにインストールされる各ファイルには、そのファイルに必要な記述的情報を含むコンポーネント構成レコードすなわちＣＣＲが付随する。
【００５０】
このため、ＴＯＳファイル及びベンダファイルは、共通のルート下に存在する。これらのファイルは、システムプロファイルを介して管理されるためには、オープンアーキテクチャ試験システムファイル命名要件に従う。これらの要件に従うことにより、システムのファイルを、管理するために単一アーカイブディレクトリに蓄積してもよい。これは、ＴＯＳファイルとベンダがインストールしたファイルとの両方に対して当てはまる。これらの要件については次に論考する。
【００５１】
ファイル命名要件
バージョン管理、切替及び監査を可能にするために、オープンアーキテクチャ試験システムにインストールされる各コンポーネント（すなわち各ファイル）は、以下のファイル命名フォーマットを使用し、それにより、名前が、同じベンダか又は異なるベンダからの他のインストールされたコンポーネントの名前と抵触することを防ぐ。
ＴＯＳコンポーネント及びベンダコンポーネントは、以下の命名フォーマットを使用する。
VendorID_ComponentName_[D_]VersionIdentifier[.ext]
【００５２】
フォーマットの説明は以下の通りであり、角括弧（[]）内の要素は任意の項目を表す。
１．VendorID：２〜３文字のベンダ識別コード。このコードは、コンポーネントをＴＯＳコンポーネント又はベンダ特有のコンポーネントとして識別し、ファイルの明確化を可能にする。なお、ベンダがシステムに導入するファイルを管理するのは各ベンダの責任であることに留意する。先頭文字は英数字であるべきであり、下線文字であってはならない。ＴＯＳランタイムコンポーネントは、「ＯＡＩ」を識別子として使用する。VenderID部の後に下線文字「_」が続く。
２．ComponentName：コンポーネントサプライヤが選択する任意の名前。ComponentName部の後に下線文字「_」が続く。
３．D：これは任意であり、実行可能コンポーネントに適用可能である。かかるコンポーネントの場合、そのコンポーネントがデバッグダイナミックリンクライブラリ（ＤＬＬ）又は実行ファイル（ＥＸＥ）を表す場合にのみ、ComponentNameの後に「D」が続く。「D」がない場合は、そのコンポーネントが非デバッグバージョン（すなわち「リリース」バージョン）であることを意味する。存在する場合、「D」部の後に下線文字「_」が続く。
４．VersionIdentifier：システムに導入されるすべてのファイルの明示的なバージョニングは基本要件である。異なるオペレーティングシステム間で互換性があるように、バージョニングは、VersionIdentifierフィールドとして、ファイル名の一部として表される。このフィールドは以下のフォーマットを有する。
major.minor.patch
ここで、major、minor及びpatchの各々は、コンポーネントのそれぞれメジャーバージョン、マイナーバージョン及びパッチバージョンを表す非負整数値である。
５．ext：拡張子は、.dll、.exe、.txt、.doc等、（任意の）ＯＳ特有の識別支援である。
【００５３】
なお、すべての場合において、ファイルの名前はサポートされるすべてのプラットフォーム（Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ等）において適法であることに留意する。いくつかの例は、以下の通りである。
AT_PinModule_10.01.008.dll
AT_PinModule_10.01.008_D.dll
AT_HCPowerSupplyModule_09.45.003.dll
OAI_utils_00.03.000.dll
【００５４】
（インストールディレクトリ構造）
OASIS_ARCHIVE_ROOTをルートとするディレクトリ構造は、図３、図４及び図５に示す通りであり、以下のようにさらに説明する。以下の論考において、ソフトウェア開発キットを、多くの場合その略語で「ＳＤＫ」と呼ぶ。また、表記「$foo」は、オペレーティングシステム環境変数fooの値を指す。インストールプロセスは以下に従う。
図３、図４及び図５に示し且つ表４において説明するように、すべてのオープンアーキテクチャ試験システムソフトウェアコンポーネントファイルは、$OASIS_ARCHIVE_ROOTの下の適当な場所にインストールされる。
インストール（すなわちアーカイブ）場所は、ＴＯＳを起動することが望まれるテスタシステムからアクセス可能である。
【００５５】
図３、図４及び図５において、OAIと命名されたディレクトリは、オープンアーキテクチャ試験システムのＴＯＳファイルを含み、<vendor>と命名されたディレクトリはベンダ特有のファイルを含む。各ベンダは独自のディレクトリを有し、<vendor>は一意の２〜３文字の識別子を示す（たとえば、アドバンテストのベンダディレクトリにはATが付される）。なお、各ベンダ特有のディレクトリ内で、ベンダは、それらのファイル名が一意であることを確実にする責任があることに留意する。また、ファイル名の明示的なバージョン識別子が要求されることにより、同じコンポーネントの異なるバージョンを同じ場所に格納することができることにも留意する。
【００５６】
表２は、上記図で概説されるディレクトリ構造についてさらに説明する。ここでは、第１列の各ディレクトリは$OASIS_ARCHIVE_ROOTに関連する。
【００５７】
【表２】
【００５８】
インストールログ
ディレクトリリログはサブディレクトリインストーラを含む。この場所は以下の仕様をサポートする。
オープンアーキテクチャ試験システムソフトウェアのためのインストーラは、既知の場所、すなわち$OASIS_ARCHIVE_ROOT/logs/Installerにおいてインストールログを作成する。
【００５９】
ＴＯＳインストールログファイルに対して使用される命名規則は、OAI_<version>.logである。ベンダインストーラは、命名規則<vendor>_<version>.logを使用する。２つのさらなる要件は以下の通りである。
インストールログは、アーカイブにコピーされる１つ１つのファイルの完全修飾パスを明示的に示すテキストファイルである。
インストーラが、コンポーネントを追加又は除去するために複数回実行される場合、インストールログは、アーカイブにコピーされるか又はアーカイブから除去されるファイルの現ステータスを示すように更新される。
【００６０】
新たなコンポーネントバージョンのインストール
コンポーネントの新たなバージョンがリリースされると、コンポーネントサプライヤ（ＴＯＳ又はベンダ）は、その新たなコンポーネントバージョンに対してＣＣＲを提供する。コンポーネント構成要素のファイル名は、ファイル命名要件セクションで説明したようにコンポーネントの新たなバージョンを反映し、ファイル命名規則に従うことにより既存のファイルに上書きすることが防止される。このため、コンポーネントファイルバージョンは、アーカイブディレクトリに蓄積し続ける。
【００６１】
なお、インストールパッケージ（後述するリリースグループＣＣＲのうちの１つ、又は直接ベンダリリースに対する任意のベンダ提供リリースＣＣＲによって示される）は、コンポーネントの現リリースバージョンを修正し又は拡張するように意図された個々のコンポーネントを含んでもよい。既存のコンポーネントの新たなバージョンは既存のコンポーネント／ファイルに置き換わらないため、いかなる既存のシステムプロファイルも実行し続けることができる。コンポーネントのパッチに対する以下の要件に留意する。
新たなパッチが利用可能となると（major.minor.patchトリプレットバージョン識別子のパッチコンポーネントにおける変更によって示されるように）、それは、ＴＯＳリリースのメジャー／マイナーバージョンと互換性がある。
【００６２】
かかる「パッチ」に対する詳細なメカニズムについて、リリースグループＣＣＲ及びユーザのシステムプロファイルについて説明した後に後述する。
【００６３】
構成
構成とは、ユーザがＩＣＭシステムと対話することによりオープンアーキテクチャ試験システムソフトウェア構成をシステムプロファイルとして作成し、保存し、変更することができるようにする行為であり、かかるシステムプロファイルは、後に特定のテスタシステムにおいて特定の構成を起動するために使用される。このセクションは、この機能を実行するためにＩＣＭによって提供されるメカニズムについて説明する。
【００６４】
（コンポーネント及び構成レコード）
オープンアーキテクチャ試験システムでは、コンポーネントは、システムの別個のモジュールを表す１つ又は複数のファイル、環境設定等である。システムコンポーネントの重要なカテゴリは、システムハードウェアモジュールのソフトウェア表現であり、それらは主要コンポーネントとしてみなされる。コンポーネントの別のカテゴリは、たとえば、ＳＤＫのためのインタフェース定義ファイルである。
【００６５】
単一コンポーネントＣＣＲ
上述したように、アーカイブにインストールされる各オープンアーキテクチャ試験システムソフトウェアコンポーネントには、ファイルの特性を指定するコンポーネント構成レコード（ＣＣＲ）が付随する。このため、構成制御下にあるＴＯＳファイル又はベンダファイルは、アーカイブにインストールされる時にＣＣＲに関連付けられる。ＣＣＲは、アーカイブにインストールされるファイルの記述であり、そのファイル、そのバージョン番号、その関連コンポーネント、その従属性、その非互換性等に関する情報を含む。ＣＣＲは、ＯＣＴｏｏｌへの入力としての役割を果たし、ユーザが試験システムにインストールされたコンポーネントのすべてを見て、制御し、追跡し、管理することができるようにする。ＣＣＲに対する命名要件は、.ccrという必須の追加の拡張子が必要であることを除き、それが記述する対応するシステムファイルに対するものと同一である。このため、ファイルAT_PinModule_0.5.1.dllのＣＣＲは、AT_PinModule_0.5.1.dll.ccrと命名される。なお、インストールされるＣＣＲは、インストールの最初の参照として<OASIS_ARCHIVE_ROOT>/InstallCCRにそのまま維持されることに留意する。ＣＣＲファイルは、コンポーネントファイルと同じディレクトリ場所に配置される（コンポーネントファイルはアーカイブディレクトリに関連して格納される）が、InsallCCRディレクトリに関連する。
【００６６】
グループＣＣＲ
ＣＣＲを、複数のＣＣＲを参照するグループとして表すことができる。実際には、これは、ＣＣＲは必然的に製品リリースパッケージにマップするため、それらが多くの場合にシステムに導入される主な方法である。ユーザはまた、必要な場合、プロファイルに含めるためにＣＣＲグループ全体を選択することも可能である。
【００６７】
オープンアーキテクチャ試験システムのインストールのためにいくつかの重要な必要なグループＣＣＲがある。インストールされた各オープンアーキテクチャ試験システムソフトウェアコンポーネントファイルに対するＣＣＲのほかに、以下のリリースグループＣＣＲが必要である。
ＴＯＳサプライヤ／システムインテグレータによって提供されるオープンアーキテクチャ試験システムのＴＯＳリリースＣＣＲ、
システムインテグレータ又はUserSDKサプライヤによって提供されるオープンアーキテクチャ試験システムのUserSDKリリースＣＣＲ、
システムインテグレータ又はVendorSDKサプライヤによって提供されるオープンアーキテクチャ試験システムのVendorSDKリリースＣＣＲ。
【００６８】
グループＣＣＲは、以下のグループ／ファイル命名フォーマットを使用する。
VendoerID_GroupType[_UserGivenName]_VersionIdentifier.gccr
UserGivenNameは任意である。
【００６９】
OAI_TOS_<version>.gccrと命名されたＴＯＳリリースＣＣＲは、名目的に「<version>」リリースと名称が付されたオープンアーキテクチャ試験システムＴＯＳランタイムの全リリースの内容を記述するグループＣＣＲである。なお、上で定義したように、<version>はVersionIdentifierである。それは、オープンアーキテクチャ試験システムＴＯＳランタイムの「<version>」リリースをまとめて定義する個々のコンポーネントＣＣＲすべてに対する参照を含む。このＣＣＲのタイプは「TOS」である。
【００７０】
同様に、UserSDKリリースＣＣＲ及びVenderSDKリリースＣＣＲ（それぞれOAI_USER_SDK_<version>.ccr及びOAI_VENDOR_SDK_<version>.gccr）は、オープンアーキテクチャ試験システムのユーザＳＤＫ及びベンダＳＤＫの全リリースの内容を記述するグループＣＣＲであり、それぞれタイプ「USER_SDK」及び「VENDER_SDK」である。
【００７１】
上記必要なグループＣＣＲに加えて、ハードウェアモジュールベンダは、関連コンポーネントのリリースを制御するグループＣＣＲを提供するように選択してもよい。これらのグループＣＣＲは、タイプ「VENDOR」、「USER」及び「TOOLS」である。
【００７２】
単一コンポーネントＣＣＲにおける情報
上述したように、オープンアーキテクチャ試験システムの主要コンポーネントは、ハードウェアモジュールのソフトウェア表現である。ＣＣＲの情報内容は、すべてのコンポーネントカテゴリの最も複雑なものである、かかる主要コンポーネントをサポートするために必要な属性のすべてを指定することに向けられている。かかる属性は、コンポーネントの他のより単純なカテゴリには必要でない場合が多く、そのようなカテゴリにはかかる属性の値を定義する必要はない。
【００７３】
ＣＣＲに含まれる情報は表３に示すようなものである。オープンアーキテクチャ試験システム主要コンポーネントをサポートするＣＣＲに対し、この情報を提供するのはハードウェアモジュールベンダの責任である。
【００７４】
【表３】
【００７５】
ベンダデジタルピンモジュールのためのドライバＤＬＬに対し、単純な単一コンポーネントＣＣＲファイルの例を以下に示す。
【００７６】
Version 1.0;
Description "Advantest Digital Pin Module Driver";
VendorName AT;
VendorID 1;
ModuleName DM250MHz;
ModuleID 4;
FileParams "";
Function Driver;
Resource "moduletrigger{MaxAvailable = 4;}",
"dpin{MaxAvailable=32;}";
HardwareRev 1095188784;
DeployTo SYSC;
Register "N";
GroupDependency AT_VENDOR_Modules_1.0.1.0,
AT_Tools_GemTools_1.01.0;
GroupIncompat OAI_TOS(<0.5.0);
GompIncompat AT_PinModule.dll(<0.5.0);
CompType Bin;
【００７７】
次は、同じベンダデジタルピンモジュールに対する較正ＤＬＬのための単一コンポーネントＣＣＲファイルの一例である。
【００７８】
Version 1.0;
Description "Advantest Digital Pin Module Calibration DLL";
VendorName AT;
VendorID 1;
ModuleName DM250MHz;
ModuleID 4;
FileParams "";
Function Calibration
[cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini];
HardwareRev 1095188784;
DeployTo SYSC;
Register "N";
GroupIncompat OAI_TOS(<0.5.0);
【００７９】
なお、Versionは、ＣＣＲ記述言語のバージョンを指定し、必ずしもそれが記述する任意のコンポーネントのバージョン（複数可）に関連しない。上記第１の例のResourceフィールドは、このモジュールドライバ（ＤＭ２５０ＭＨｚハードウェアモジュールの場合）が、４ユニットのモジュールトリガリソースと３２ユニットのｄｐｉｎリソースを提供するハードウェアモジュールを駆動することができることを示す。パラメータ「cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini」（第２の例においてCalibrationとして指定されるFunctionの場合）は、較正プログラムアルゴリズムバージョン情報を含むファイルのパス名を指定する。これは、構成データベース（ＣＤＢ）へのインポート後、ＯＣＴｏｏｌにより較正バンドル情報を生成するために使用される。各例におけるGroupIncompatフィールドに対する「OAI_TOS(<0.5.0)」の値は、ＣＣＲが記述するＤＬＬが、バージョン番号が０．５．０未満であるＴＯＳリリースグループＣＣＲに含まれるオープンアーキテクチャ試験システムのＴＯＳコンポーネントと互換性がないことを示す。
【００８０】
グループＣＣＲの情報
グループＣＣＲは、個々のコンポーネントの集まりを記述するＣＣＲか又は他のグループＣＣＲである。グループＣＣＲに含まれる情報を表４に示す。
【００８１】
【表４】
【００８２】
以下は、オープンアーキテクチャ試験システムのＴＯＳリリースのグループＣＣＲの一例である。
【００８３】
Version 1.0;
ComponentGroup OAI_TOS_1.1.0.029
{
Description "Open architecture test system TOS Release Package";
VendorName AT;
VendorId 1;
OAIMCFVersion "＞=1.0";
OAISimVersion "＞=0.9.5";
OAIOCFVersion "＞=1.0.1";
Component
{
bin/OAI/OAI_Core_0.4.9.dll.ccr;
bin/OAI/OAI_StdProxy_0.3.7.dll.ccr;
...
}
}
【００８４】
グループＣＣＲのインポート
グループについて記述することに加えて、グループＣＣＲは他のグループＣＣＲをインポートすることができる。以下はグループＣＣＲをインポートする一例である。
【００８５】
Version 1.0;
Import OAI_USERSDK_1.0.0.1;
ComponentGroup OAI_TOS_1.1.0.029
{
Description "Open architecture test system's TOS Release Package";
VendorName AT;
VendorId 1;
OAIMCFVersion "＞=1.0";
OAISimVersion "＞=0.9.5";
OAIOCFVersion "＞=1.0.1";
Component
{
bin/OAI/OAI_Core_0.4.9.dll.ccr;
bin/OAI/OAI_StdProxy_0.3.7.dll.ccr;
...
}
}
【００８６】
（構成データベース）
ＩＣＭ構成データベース（ＣＤＢ）は、インストールされたすべてのＣＣＲを通して表されるシステム構成データの集まりを保持する。ＣＤＢはまた、ユーザ作成システムプロファイル情報も保持する。ＣＤＢにおいて管理される情報は、いかなる特定のテスタインストールからも独立している。
【００８７】
ＣＤＢの作成とＣＣＲデータをそれにインポートすることとは、オープンアーキテクチャ試験システムのCDBMrgツールによって処理される。CDBMgrツールは、テスタにインストールされる必要もテスタで実行される必要もなく、それが操作する情報は特定のテスタに特化していない。しかしながら、それは、$OASIS_ARCHIVE_ROOTをルートとするディレクトリツリー内に格納されたＣＣＲファイルを読み出す必要があるため（インポート機能）、そのディレクトリツリーにアクセスする必要がある。
【００８８】
ＣＤＢの情報を使用してシステムプロファイルが作成され、それもまたＣＤＢに格納される。これについては次に説明する。
【００８９】
（システムプロファイル）
以下の要件はシステムプロファイルを指定する。
ユーザが選択するオープンアーキテクチャ試験システムのシステムプロファイルは、オープンアーキテクチャ試験システムで作業するために要求される特定のオープンアーキテクチャ試験システムソフトウェア構成を定義するために必要な情報の全体の集まりである。
【００９０】
システムプロファイルは、いかなる特定のテスタに特化した情報も含まず、むしろ、すべての必要な情報と、テスタで起動するためにユーザが選択するソフトウェアコンポーネントの以下のセット間の相互依存性とをカプセル化する。
ハードウェアモジュール関連ソフトウェア（ドライバ、エミュレーション、較正及び診断コンポーネント）、
オープンアーキテクチャ試験システムランタイムソフトウェア、
ユーザＳＤＫコンポーネント（試験開発環境に必要）及び
ベンダＳＤＫコンポーネント（モジュール開発環境に必要）。
【００９１】
なお、ユーザ作成システムプロファイル情報はＣＤＢに格納されるが、システムプロファイルを（ＯＣＴｏｏｌを介して）エクスポートする行為により、プロファイルを定義するすべての関係するテスタ独立情報を含むファイルを作成することができ、それによりプロファイルをＣＤＢの外部で利用することができるようになる。そして、これを、オープンアーキテクチャ試験システムの起動プロセスによって使用することができる。プロファイル情報が格納されるファイルはOASISVer.cfgと命名され、それは標準ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマットであり、且つデフォルトとして対応する$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>ディレクトリに格納される。しかしながら、プロファイルをエクスポートしている間、ユーザは、自身が選択した任意の場所にファイルを配置するように選択することができる。
【００９２】
起動中、ユーザプロファイルに格納されたテスタ独立情報は、テスタ特有情報と結合されることによりテスタのアクティブ構成を形成する。これは、$OASIS_ACTIVE_CONFIGSに格納された１組の試験環境ファイルを含む。起動については以下のセクションで説明し、そこではシステムプロファイルについて再び取り上げる。
【００９３】
（ＯＣＴｏｏｌ）
オープンアーキテクチャ試験システムのＣＤＢにＣＣＲデータが取り込まれると、構成ツール（ＯＣＴｏｏｌ）を使用して、ユーザが作成したシステムプロファイルが作成され、保存され、変更されエクスポートされる（すなわち、ＣＤＢの外部で利用可能にされる）。
【００９４】
ＯＣＴｏｏｌは、テスタにインストールされる必要もテスタで実行される必要もなく、それが操作する情報は特定のテスタに特化しない。しかしながら、それは、ユーザプロファイル情報を$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>に保存する必要があるため（エクスポート機能）、$OASIS_ARCHIVE_ROOTをルートとするディレクトリツリーにアクセスする必要がある。
【００９５】
起動
以下の要件は、オープンアーキテクチャ試験システムのソフトウェアシステム起動を指定する。オープンアーキテクチャ試験システムのソフトウェアシステムの起動は
１．選択されたシステムプロファイルにおけるテスタ独立構成情報を使用し、
２．それをテスタ特有情報と結合することにより$OASIS_ACTIVE_CONFIGSにテスタアクティブ構成情報を作成し、
３．$OASIS_INSTALLATION_ROOTの下にすべてに必要なソフトウェアコンポーネント（ファイル）を配備し（すなわち、配置し登録し）、
４．ターゲットテスタにおける選択された構成によりオープンアーキテクチャ試験システムのＴＯＳを開始する
行為である。
【００９６】
オープンアーキテクチャ試験システムのソフトウェアシステムの起動は、オープンアーキテクチャ試験システムのテスタ制御デーモン（ＴＣＤ）の機能である。上述したように、ＴＣＤは、接続されたアプリケーションがテスタ制御コマンドを送出することができるようにするＣＯＭインタフェースメソッドを提供する。<MAINTENANCE_ROOT>/binにインストールされるＴＣＤコントローラアプリケーションは、「start」、「stop」、「activate」等の基本テスタシステム制御コマンドをＴＣＤに送出することができる単純なコマンドラインアプリケーションであることを想起されたい。また、これは、Ａｄｖａｎｔｅｓｔ Ｔ２０００システムにおけるt2kctrlアプリケーションであることも想起されたい。このセクションでは、t2kctrlアプリケーションを使用して「起動」機能を実行することについて説明する。
【００９７】
（前提条件）
特定のオープンアーキテクチャ試験システム構成を（選択されたプロファイルを介して）起動しようと試みる前に、以下の前提条件が満足されなければならない。
１．$OASIS_ARCHIVE_ROOTによって指定される場所は、ターゲットテスタマシンのシステムコントローラで実行しているＴＣＤによってアクセス可能である。
２．先に定義されたオープンアーキテクチャ試験システムのシステムプロファイルは、OASISVer.cfgにエクスポートされており、$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>又はユーザが選択した別の場所のいずれかにおいて入手可能であり、エクスポートされたファイルOASISVer.cfgは、ターゲットテスタマシンのシステムコントローラで実行しているＴＣＤによってアクセス可能である。
３．環境変数OASIS_INSTALLATION_ROOT及びOASIS_TEMPが定義されている。なお、$OASIS_INSTALLATION_ROOTによって示される場所において、オープンアーキテクチャ試験システムのシステムソフトウェアの別の構成がすでに入手可能である場合、そのインストールは${OASIS_INSTALLATION_ROOT}_BAKにバックアップされ、起動プロセスは、成功した場合、$OASIS_INSTALLATION_ROOTの下に選択された新たな構成を配置することに留意する。
４．環境変数OASIS_ACTIVE_CONFIGSが定義されている。なお、このディレクトリがすでに存在し、オープンアーキテクチャ試験システムのシステムソフトウェアに対するアクティブ構成情報の別のセットがその場所ですでに入手可能である場合、そのインストールは${OASIS_ACTIVE_CONFIGS}_BAKにバックアップされ、起動プロセスは、成功した場合、$OASIS_ACTIVE_CONFIGSの下に選択された新たなアクティブな構成に対応する試験環境ファイルを作成することに留意する。
５．環境変数OASIS_MACHINE_DIRが定義されている＊。なお、このディレクトリがすでに存在する場合、ディレクトリ$OASIS_MACHINE_DIR/CD/bundlesが任意の既存の較正／診断（ＣＤ）バンドル記述ファイルから消去され、選択されたプロファイルに関連するＣＤバンドル記述ファイル（複数可）がその場所にインストールされることに留意する。
６．テスタ工場出荷時（ＦＤＥＦ）ファイル<MAINTENANCE_ROOT>/cfg/OASISSHW.defがシステムコントローラに存在する。このファイルは、起動プロセスに対しテスタ特有情報を提供するために必須である。
７．オープンアーキテクチャ試験システムが状態ｎ、ｎ＞０にある、すなわち、少なくともターゲットマシンのシステムコントローラにおけるＴＣＤが実行されている。そうでない場合、コマンド「net start T2000Svc」を発行することによりそれを始動しなければならない。
【００９８】
（t2kctrlアプリケーションの使用）
以下のコマンドを使用して、ターゲットマシンのシステムコントローラから起動プロセスを呼び出してもよい。
t2kctrl switch<config><archive_location><profile-directory-name>
ここで、
<config>はDEBUG又はRELEASEのうちの一方であるべきであり、インストールされるべきソフトウェアのビルドモードを示す。
<archive_location>は、環境変数OASIS_ARCHIVE_ROOTによって示される場所のフルパス名を指定するべきである。
<profile-directory-name>は、エクスポートされたプロファイル情報が位置するプロファイルディレクトリのフルパス名を指定するべきである。
【００９９】
（起動プロセス）
適当なコマンドが発行されると、起動のプロセスは以下の通りである。
１．テスタが状態≧２（１０ページ参照）である場合、システムコントローラＴＣＤはまず、システムを最終的に状態１にするＴＯＳ「シャットダウン」コマンドを発行する。この時点でいずれかのオープンアーキテクチャ試験システムアプリケーションがシステムコントローラに接続されている場合、それに対して切断するよう要求するメッセージが送出され、その状態をクリーンアップし適切に（gracefully）終了するために十分な時間が与えられるか、又は強制終了される。なお、これは、その時点でシステムコントローラに接続されていないアプリケーションに対しては適用されないことに留意する。
２．システムが状態１にになると、ある場合は$OASIS_INSTALLATION_ROOTにおける現インストールが${OASIS_INSTALLATION_ROOT}_BAKにバックアップされ、Ｗｉｎｄｏｗｓレジストリに登録されたオープンアーキテクチャ試験システム実行ファイルのすべて（表７の「Register」フィールド参照）の登録が取り消される。これは、システムコントローラとすべてのサイトコントローラとに対して行われる。
３．その後、ある場合は、$OASIS_ACTIVE_CONFIGSの現アクティブ構成情報が${OASIS_ACTIVE_CONFIGS}_BAKにバックアップされ、$OASIS_MACHINE_DIR/CD/bundles（ある場合）のＣＤバンドル記述ファイル（複数可）が削除される。
４．現インストール情報及びアクティブ構成情報のバックアップ（必要な場合）が正しく完了した後、ＴＣＤは、選択された（新たな）ファイルによって指定されるように、次のセクションで指定される場所に、アーカイブされたオープンアーキテクチャ試験システムのソフトウェアシステムファイルをコピーする。分散環境（別々のシステムコントローラ及びサイトコントローラ（複数可））では、サイトコントローラにインストールされる必要のあるファイルもまたそれらのマシンにコピーされる。
５．そして、ＴＣＤは、システムコントローラ及びサイトコントローラ（複数可）の両方に、Ｗｉｎｄｏｗｓレジストリに登録される必要のあるすべてのオープンアーキテクチャ試験システム実行ファイルを登録する。
６．そして、選択された（新たな）プロファイルからのテスタ独立情報は、ＴＣＤにより、テスタ工場出荷時ファイル（システムコントローラの<MAINTENANCE_ROOT>/cfgディレクトリに位置する）からのテスタ特有情報と結合される。これにより、ターゲットテスタマシンにおいて新たなオープンアーキテクチャ試験システムソフトウェアランタイムインストールのためにアクティブ構成を定義するファイルの以下のセットが生成される。
モジュール構成ファイル, OASISModules.cfg.
シミュレーション構成ファイル, OASISSim.cfg.
システム構成ファイル, OASISSys.cfg.
オフライン構成ファイル, OASISOffline.cfg.
これらのファイルは、ＴＣＤにより$OASIS_ACTIVE_CONFIGSに配置される。
７．ＴＣＤはまた、新たなプロファイルによりシステムの内容及び構成の記録としての役割を果たす、新たなプロファイル情報ファイルOASISVer.cfgのコピーを$OASIS_ACTIVE_CONFIGSの場所に配置する。
８．最後に、ＴＣＤは、ＴＯＳスタートアッププロセスのステップ０〜０において概説されたＴＯＳ「スタートアップ」シーケンスに従うことにより、新たな構成においてＴＯＳを始動し、それにより起動プロセスを完了する。
【０１００】
なお、上記ステップのうちのいずれかを正しく実行できないことにより、オープンアーキテクチャ試験システムインストールは、起動コマンドが発行される前の構成に戻り、ＴＣＤはその構成においてＴＯＳを再始動することに留意する。さらに、プロセス全体の詳細なログは、場所$OASIS_INSTALLATION_ROOT/logs/Deploymentに保持される。そのログはDeployment.logと命名され、ＴＣＤの「activate」コマンドが新たに呼び出される度に上書きされる。
【０１０１】
（配備ディレクトリ構造）
上述したように、ＴＣＤは、要求されたオープンアーキテクチャ試験システムのソフトウェアファイルを、$OASIS_ARCHIVE_ROOT下のそれらのアーカイブされた場所から、ターゲットテスタの$OASIS_INSTALLATION_ROOTにおける配備又はランタイムインストールにコピーする。
【０１０２】
$OASIS_INSTALLATION_ROOTをルートとする、テスタのオープンアーキテクチャ試験システム配備のディレクトリ構造は、図６、図７及び図８に示す通りである。起動プロセスは以下に従う。
すべてのオープンアーキテクチャ試験システムソフトウェアコンポーネントファイルが、テスタマシンのランタイムの起動のために、図６、図７及び図８に示され表８において説明されるように$OASIS_INSTALLATION_ROOT下の適当な場所に配備される。
【０１０３】
以下の図において、OAIと命名されたディレクトリは、オープンアーキテクチャ試験システムのＴＯＳファイルを含み、<vendor>と命名されたディレクトリはベンダ特有ファイルを含む。アーカイブ構造におけるように、各ベンダはそれ自体のディレクトリを有し、<vendor>は一意の２〜３文字識別子を示す（たとえば、ＡｄｖａｎｔｅｓｔベンダディレクトリにはATが付される）。
【０１０４】
表５は、上記図で概説されるディレクトリ構造についてさらに説明する。ここでは、第１列の各ディレクトリは$OASIS_INSTALLATION_ROOTに関連する。
【０１０５】
【表５】
【０１０６】
ファイル名変換
起動中、ファイルがアーカイブからランタイム環境に配備されると、ＴＣＤは、ファイル名に埋め込まれたバージョン識別子を取り除く。このため、たとえば、アーカイブのファイルOAI_utils_0.1.2.dllが、ランタイムインストールのファイルOAI_utils.dllにコピーされ、アーカイブのファイルAT_Cal_DM250MHz_D_1.2.3.dllが、ランタイムインストールのファイルAT_Cal_DM250MHz_D.dllにコピーされる。
【０１０７】
（アクティブテスタ構成）
起動プロセスで説明したように、ターゲットテスタマシンのオープンアーキテクチャ試験システムの配備中、選択された（新たな）プロファイルからのテスタ独立情報は、ＴＣＤにより、ＦＤＥＦファイルからのテスタ特有情報と併合される。これにより、ターゲットテスタマシンにおける新たなオープンアーキテクチャ試験システムソフトウェアランタイムインストールのためにアクティブ構成を定義する以下のファイルのセットが作成される。
【０１０８】
The Module Configuration File, OASISModules.cfg.
The Simulation Configuration File, OASISSim.cfg.
The System Configuration File, OASISSys.cfg.
The Offline Configuration File, OASISOffline.cfg.
【０１０９】
これらのファイルは、ＴＣＤにより$OASIS_ACTIVE_CONFIGSに配置される。なお、$OASIS_ACTIVE_CONFIGSを、$OASIS_INSTALLATION_ROOTをルートとするディレクトリツリー内の場所に設定してはならないことに留意する。
【０１１０】
（オープンアーキテクチャ試験システムマシンデータ）
較正／診断（ＣＤ）データ等のテスタマシン特有データは、システムコントローラにおいて環境変数OASIS_MACHINE_DIRによって示される場所の下に格納される。データのほかに、CDdataディレクトリは、サブディレクトリCD/bundlesを含み、これは、目下配備されている（すなわちアクティブな）プロファイルに関連するＣＤバンドル記述ファイル（複数可）を格納するために使用される。
【０１１１】
なお、$OASIS_MACHINE_DIRの場所のデータセットは、ユーザによって完全に保持され、特定のマシンが要求するように適当なデータセットを利用可能にするのはユーザの責任であることに留意する。しかしながら、起動プロセスは、ＣＤバンドル記述ファイル（複数可）に関して以下の動作に関与する。
$OASIS_MACHINE_DIR/CD/bundlesの任意の既存のＣＤバンドル記述ファイル（複数可）が削除される。そして、新たな選択されたプロファイルのＣＤバンドル記述ファイル（複数可）が$OASIS_MACHINE_DIR/CD/bundlesに配備される。
【０１１２】
なお、$OASIS_MACHINE_DIRを、$OASIS_INSTALLATION_ROOTをルートとするディレクトリツリー内部の場所に設定してはならないことに留意する。
【０１１３】
監査
オープンアーキテクチャ試験システムのプロファイル監査により、ユーザは、ＣＤＢに格納された所与のプロファイルの内容を検証することができる。一方、オープンアーキテクチャ試験システム監査は、特定の試験システムにおける目下アクティブなソフトウェアコンポーネント及びハードウェアコンポーネントのリスト化を提供する行為を言う。このアクティビティを可能にするために以下の機能が利用できる。
【０１１４】
（プロファイル監査）
これは、テスタ独立プロファイル情報に対し、２つの異なるメカニズムを通して利用可能である。
ＯＣＴｏｏｌアプリケーションは、ＣＤＢに格納された選択されたプロファイルの内容を表示することができる。
所与のプロファイルをデフォルト場所$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>（又はユーザが選択する別の場所）にエクスポートする行為（そのプロファイルの起動を達成することができる前に実行される）により、ファイルOASISVer.cfgが作成される。ファイルの内容は、選択されたプロファイルを完全に記述する。ファイルがプレーンテキストであり、且つ標準Ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマットであるため、情報をスキャンして所望の監査機能を提供することができる。なお、アクティブな配備において、このファイルはまた、$OASIS_ACTIVE_CONFIGSにおいても利用可能となることに留意する。
【０１１５】
（システム監査）
システム監査を、２つの部分、すなわち配備ソフトウェア監査とテスタハードウェア監査とに分割することができる。
【０１１６】
配備ソフトウェア監査
配備ソフトウェア監査は、オープンアーキテクチャ試験システムにおいて満足される以下の要件を通して容易になる。
ターゲットテスタマシンにおけるオープンアーキテクチャ試験システムのソフトウェア配備又は起動のプロセスにより、配備されるソフトウェアコンポーネントの完全な詳細を提供するプレーンテキスト配備ログが作成される。このログは、Deployment.logと命名され、システムコントローラにおいて場所<MAINTENANCE_ROOT>/log/Deploymentで入手可能となる。
【０１１７】
ログファイルがプレーンテキストであるため、その中の情報をスキャンして要求される監査機能を提供することができる。
【０１１８】
テスタハードウェア監査
テスタハードウェア監査は、オープンアーキテクチャ試験システムにおいてＴＯＳによって満足される以下の要件を通して容易になる。
モジュール詳細情報が、ＴＯＳが始動される度にオープンアーキテクチャ試験システムハードウェアインベントリ（ＨＷＩＮＶ）ファイルフォーマットに書き込まれる。これは、システムコントローラにおいて場所<MAINTENANCE_ROOT>/cfgで入手可能となるファイルOASISHW.invに格納される。
【０１１９】
ハードウェアインベントリファイルがプレーンテキストであるため、その中の情報をスキャンすることにより要求される監査機能を提供することができる。
【０１２０】
ソフトウェアパッチリリース
上記新コンポーネントバージョンのインストールセクションにおいて説明したように、インストールパッケージは、コンポーネントの目下リリースされているバージョンを修正し又は強化するようじ意図された個々のコンポーネントを含んでもよい。かかるインストールパッケージが、それが修正するように意図されているリリースのメジャー／マイナーバージョンと互換性がある場合、そのパッケージ（ひいてはそれが関連するリリース）を「パッチ」と呼ぶ。このセクションでは、かかるパッチリリースを提供する際に実行されるステップについて説明する。
【０１２１】
コンポーネントの新たなバージョンがリリースされると、コンポーネントサプライヤ（ＴＯＳ又はベンダ）は、その新たなコンポーネントバージョンのためのＣＣＲを提供する。コンポーネント構成要素のファイル名は、ファイル命名要件セクションで説明したようにコンポーネントの新たなバージョンを反映し、ファイル命名規則に従うことにより、既存のファイルに上書きすることが防止される。このため、コンポーネントファイルバージョンは、アーカイブディレクトリに蓄積し続ける。既存のコンポーネントの新たなバージョンが既存のコンポーネント／ファイルに置き換わらないため、いかなる既存システムプロファイルも実行し続けることができる。
【０１２２】
（パッチリリースの提供）
パッチリリースを提供するステップは以下の通りである。
１．提供者（ＴＯＳサプライヤ、ベンダ又はシステムインテグレータ）は、現リリースを修正し又は強化するように意図されているコンポーネント（複数可）（のセット）を特定し作成する。一例として、OAI_core.dll及びOAI_messages.dllの更新されたバージョンを含むＴＯＳパッチを考慮する。この場合、目下リリースされているバージョンはOAI_core_1.2.9.dll及びOAI_messages_1.2.2.dllである。現リリースに対するＴＯＳリリースＣＣＲをOAI_TOS_1.2.11.ccrであるとする。
２．上記セットの各コンポーネントに、システムのバージョニングされるコンポーネントを特定するmajor.minor.patchトライアドの「patch」フィールドを更新して、名前が割り当てられる。これにより、本明細書の上記例における更新されたコンポーネントを、OAI_core_1.2.10.dll及びOAI_messages_1.2.3.dllと命名してもよい。
３．更新されたバージョン情報を反映して、更新されたコンポーネントの各々に対し新たなパッチＣＣＲが作成される。これにより、本明細書の上記例におけるコンポーネントに対する更新されたＣＣＲは、OAI_core_1.2.10.dll.ccr及びOAI_messages_1.2.3.dll.ccrであってもよい。
４．現リリースに対して使用されている最初のグループＣＣＲに置き換わるために新たなリリースグループＣＣＲが作成される。このＣＣＲは、更新されたコンポーネントに対する新たなＣＣＲ（複数可）のセットに対して更新された参照（本明細書の例では、OAI_core_1.2.10.dll.ccr及びOAI_messages_1.2.3.dll.ccr）を含み、グループの他のすべてのコンポーネントに対する参照は、現リリースに対するものと同じままである。この新たなグループＣＣＲに対しても、検討中のパッケージの集合的な「<version>」リリースを名目的に特定するmajor.minor.patchトライアドにおける「patch」フィールドに対して更新を有する<version>番号が与えられる。このため、本明細書の例では、この新たなリリースグループＣＣＲをOAI_TOS_1.2.11.ccrと命名してもよい。
５．サプライヤは、更新されたコンポーネントと、それらの更新された個々のＣＣＲと、パッケージ全体に対する新たなリリースグループＣＣＲとからなるオープンアーキテクチャ試験システムのアーカイブインストールパッケージを作成する。このパッケージは、特定されたコンポーネントに対する総合パッチとして配信される。
【０１２３】
（パッチリリースの使用）
ユーザ側において、パッチをインストールし、構成し、且つ起動する手続きは以下の通りである。
１．ユーザは、パッチパッケージの内容をオープンアーキテクチャ試験システムインストールアーカイブ場所にインストールする。
２．ユーザは、まず使用するつもりであるプロファイルを呼び戻し、それを、新たなリリースグループＣＣＲ（及び、それにより、更新されたコンポーネントに対する個々のコンポーネントＣＣＲ）を使用するように変更し（又はそれを新たなプロファイルの基礎として使用し）、結果としての変更された（又は新たな）プロファイルを保存することによって、パッチを構成する。
３．最後に、ユーザは、上記変更された（又は新たな）プロファイルを採用して、t2kctrlツールを使用してパッチを起動する。
【０１２４】
（ハードウェアのみの（Hardware-Only）パッチ）
ハードウェアサプライヤは、対応するソフトウェアを更新する必要なく、ハードウェアバージョンを更新する必要がある場合がある。かかる場合、ソフトウェアに対する既存のＣＣＲは、新たなハードウェアバージョンに対する正しい互換性情報を含まない。
【０１２５】
ハードウェアのみのパッチ（ＨＯＰ）とは、ハードウェア／ソフトウェア互換性関係を更新することを目的とする、更新されたＣＣＲのリリースを言う。これらのＣＣＲがデータベースにインポートされると、プロファイルは新たな互換性情報で更新される場合がある。かかるＣＣＲは通常通り作成され、いかなるソフトウェアもなしにパッケージとして配布されてもよい。ユーザがこれらの新たなＣＣＲを受け取ると、新たなＣＣＲを処理するためにパッチをインストールし、構成し、起動する手続きが使用される。
【０１２６】
上記説明では、明確にするために異なる機能ユニット及びプロセッサに関して本発明の実施形態について説明した、ということが理解されよう。しかしながら、本発明から逸脱することなく、異なる機能ユニット又はプロセッサ間の機能の任意の適当な分散を使用してもよい、ということが明らかとなろう。たとえば、別々のプロセッサ又はコントローラによって実行されるように示される機能を、同じプロセッサ又はコントローラによって実行してもよい。このため、特定の機能ユニットについて言及する場合、それは、厳密な論理的又は物理的な構造又は編成を示すのではなく、単に説明した機能を提供するための適当な手段を言及するものとして判断されるべきである。
【産業上の利用可能性】
【０１２７】
本発明を、ハードウェア、ソフトウェア、ファームウェア又はこれらの任意の組合せを含む任意の適当な形態で実施することができる。本発明を任意で、部分的に、１つ又は複数のデータプロセッサ及び／又はデジタル信号プロセッサで実行するコンピュータソフトウェアとして実施してもよい。本発明の実施形態の要素及びコンポーネントを、任意の適当な方法で物理的に、機能的に、且つ論理的に実施してもよい。実際に、機能を、単一ユニットで、複数のユニットで、又は他の機能ユニットの一部として実施してもよい。したがって、本発明を、単一ユニットで実施してもよく、又は異なるユニット及びプロセッサ間で物理的に且つ機能的に分散させてもよい。
【０１２８】
当業者は、依然として同じ基本の根本的なメカニズム及び方法を採用しながら、開示された実施形態の多くのあり得る変更及び組合せを使用してもよい、ということを認識するであろう。上述した記述は、説明の目的のために、特定の実施形態に関して述べたものである。しかしながら、上記例示的な論考は、網羅的であるように、又は本発明を開示した正確な形態に限定するようにも意図されていない。上記教示に鑑みて、多くの変更及び変形が可能である。本発明の原理とその実際的な適用とを説明するように、且つ当業者が、企図される特定の使用に適するよう、本発明及びさまざまな実施形態をさまざまな変更態様で最もよく利用することができるように、実施形態を選択し述べた。
【図面の簡単な説明】
【０１２９】
【図１ａ】本発明の一実施形態によるオープンアーキテクチャ試験システムを示す図である。
【図１ｂ】本発明の一実施形態によるモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法を示す図である。
【図２ａ】本発明の一実施形態によるＴＯＳ制御及び工場出荷時ディレクトリ構造を示す図である。
【図２ｂ】本発明の一実施形態によるオープンアーキテクチャ試験システムの状態図を示す図である。
【図３】本発明の一実施形態によるＴＯＳインストールディレクトリ構造を示す図である。
【図４】本発明の一実施形態によるユーザＳＤＫインストールディレクトリ構造を示す図である。
【図５】本発明の一実施形態によるベンダＳＤＫインストールディレクトリ構造を示す図である。
【図６】本発明の一実施形態によるＴＯＳ配備ディレクトリ構造を示す図である。
【図７】本発明の一実施形態によるユーザＳＤＫ配備ディレクトリ構造を示す図である。
【図８】本発明の一実施形態によるベンダＳＤＫ配備ディレクトリ構造を示す図である。
【技術分野】
【０００１】
本発明は、集積回路を試験する分野に関する。特に、本発明は、テスタ機器モジュールのインストール及び構成管理を実行する方法及びシステムに関する。
【０００２】
本出願は、本出願の譲受人に譲渡され且つ参照により全体として本明細書に援用される、２００４年１２月９日に出願された「Method and System for Performing Installation and Configuration Management of Tester Instrument Modules」と題する米国仮特許出願第６０／６３５，０９４号の利益を主張する。
【背景技術】
【０００３】
試験装置のコストが高い主な理由は、従来のテスタアーキテクチャが特殊化した性質を有するということである。各テスタ製造業者は、アドバンテスト、テラダイン（Teradyne）及びアジレント（Agilent）等の会社間で互換性がないだけでなく、アドバンテストが製造するＴ３３００、Ｔ５５００及びＴ６６００シリーズのテスタ等、一会社内のプラットフォーム間でも互換性がない多数のテスタプラットフォームを有する。これら非互換性のために、各テスタは、独自の特殊なハードウェアコンポーネント及びソフトウェアコンポーネントを必要とし、これら特殊なハードウェアコンポーネント及びソフトウェアコンポーネントは他のテスタで使用することができない。さらに、試験プログラムを１つのテスタから別のテスタに移植するため、且つサードパーティソリューションを開発するために著しい労力が必要である。或るプラットフォームに対してサードパーティソリューションが開発される場合であっても、それを異なるプラットフォームに移植し又はそこで再使用することはできない。１つのプラットフォームから別のプラットフォームへの変換プロセスは、一般に複雑で且つ誤りが発生しやすく、その結果、労力及び時間が追加され試験コストが増大する。
【０００４】
特殊化したテスタアーキテクチャの別の問題は、所与のテスタに対し、すべてのハードウェア及びソフトウェアが固定の構成のままであるということである。被試験デバイス（ＤＵＴ）又はＩＣを試験するために、試験データ、信号、波形、並びに電流レベル及び電圧レベルを定義するテスタ機能とともに、ＤＵＴ応答を収集しＤＵＴに試験を合格したか又は不合格であったかを確定するテスタ機能のうちのいくつか又はすべてを使用する専用試験プログラムが開発されている。
【０００５】
オープンアーキテクチャ試験システムは、従来の試験システムの上記問題に対する解決法を提供する。オープンアーキテクチャ試験システムの一例は、参照により全体として本明細書に援用される「Method and Structure to Develop a Test Program for Semiconductor Integragated Circuits」と題する米国特許出願第１０／７７２，４３４号に記載されている。オープンアーキテクチャ試験システムを、多種多様のベンダハードウェア試験モジュール及びそれらの対応するＤＵＴをサポートするように構成することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、かかるオープンアーキテクチャ試験システムを実施する際の難題のうちの１つは、テスタオペレーティングシステム（ＴＯＳ）に多数のバージョンがある可能性があるということである。さらに、各ベンダハードウェア試験モジュールには複数のバージョンがある可能性があり、ベンダハードウェア試験モジュールの各バージョンには、その対応するソフトウェアコンポーネントのバージョンがある可能性がある。テスタオペレーティングシステム、ベンダハードウェア試験モジュール及びソフトウェアコンポーネントのバージョンは、ベンダハードウェア試験モジュールにおいて試験を実行するために互いにシームレスに作業する必要がある。したがって、複数のベンダハードウェア試験モジュールバージョン、ソフトウェアコンポーネントバージョン、及び多種多様のベンダハードウェア試験モジュールを使用してＤＵＴを試験するＴＯＳバージョンを管理することができるモジュール式試験システムが必要とされている。
【課題を解決するための手段】
【０００７】
一つの実施の形態において、モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理する方法は、モジュール式試験システムと互換性のあるＴＯＳバージョンをアーカイブにインストールすること、及び、ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントをアーカイブにインストールすることを含む。本方法はさらに、ハードウェア試験モジュールバージョン及びＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルを作成すること、モジュール式試験システムに対しシステムプロファイルを選択することであって、システムプロファイルは、１組の互換性のあるベンダソフトウェアコンポーネントと、特定のハードウェア試験モジュールバージョンを試験する選択されたＴＯＳとを含む、選択すること、及びモジュール式試験システムにおいて選択されたＴＯＳを起動することを含む。
【０００８】
別の実施の形態において、複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理するシステムは、
少なくとも１つのサイトコントローラを制御するシステムコントローラと、
少なくとも１つのハードウェア試験モジュールを制御する少なくとも１つのサイトコントローラと、
モジュール式試験システムと互換性のあるテストオペレーティングシステムバージョンと、
ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントと、
ハードウェア試験モジュールバージョン及びＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルと、
を具備する。
【０００９】
本発明の上述した特徴及び利点とともにその追加の特徴及び利点について、添付の図面と共に本発明の実施形態の詳細な説明を読んだ後により明確に理解され得るであろう。
【発明を実施するための最良の形態】
【００１０】
テスタ機器モジュールのインストール及び構成管理を実行する方法及びシステムを提供する。以下の説明を、当業者が本発明を作成し使用することができるように提示する。特定の実施形態及び応用形態の説明は、単に例として提供する。本明細書で説明する例に対するさまざまな変更及び組合せは、当業者には容易に明らかになるであろう。また、本明細書で定義する一般原理を、本発明の精神及び範囲から逸脱することなく他の例及び適用に応用してもよい。このため、本発明は、説明され且つ示される例に限定されるように意図されておらず、本明細書で開示する原理及び特徴に一致する最も広い範囲を付与される。
【００１１】
図１ａは、本発明の一実施形態によるオープンアーキテクチャシステムを示す。図１aに示すように、システムコントローラ（ＳｙｓＣ）１０２は、複数のサイトコントローラ（ＳｉｔｅＣ）１０４に結合される。システムコントローラを、ファイルにアクセスするためにネットワークに結合してもよい。各サイトコントローラは、モジュール接続イネーブラ１０６を通して、試験サイト１１０に位置する１つ又は複数の試験モジュール１０８を制御するように結合される。モジュール接続イネーブラ１０６は、接続されたハードウェアモジュール１０８の再構成を可能にし、また、データ転送用のバスとしての役割を果たす（パターンデータをロードする、応答データを収集する、制御を提供する等）。あり得るハードウェアインプリメンテーションには、専用接続、スイッチ接続、バス接続、リング接続及びスター接続が含まれる。モジュール接続イネーブラ１０６を、たとえばスイッチマトリクスによって実施してもよい。各試験サイト１１０は、被試験デバイス（ＤＵＴ）１１２に関連し、ＤＵＴ１１２は、ロードボード１１４を介して対応するサイトのモジュールに接続される。一実施形態では、単一サイトコントローラを複数のＤＵＴサイトに接続してもよい。
【００１２】
システムコントローラ１０２は、全体的なシステムマネージャとしての役割を果たす。システムコントローラ１０２は、サイトコントローラアクティビティを調整し、システムレベルの並列試験戦略を管理し、さらにシステムレベルのデータロギング及びエラー処理サポートとともにハンドラ／プローブ制御を提供する。動作設定に応じて、システムコントローラ１０２を、サイトコントローラ１０４の動作とは別のＣＰＵに配置してもよい。別法として、システムコントローラ１０２とサイトコントローラ１０４とにより共通のＣＰＵを共有してもよい。同様に、各サイトコントローラ１０４を、それ自体の専用ＣＰＵ（中央処理装置）に配置してもよく、又は同じＣＰＵ内の別個のプロセス又はスレッドとして配置してもよい。
【００１３】
個々のシステムコンポーネントを、統合されたモノリシックシステムの論理コンポーネントとみなしてもよく、必ずしも分散システムの物理コンポーネントとしてみなさなくてもよいということを理解して、システムアーキテクチャを、概念的に図１ａに示す分散システムとして想定してもよい。
【００１４】
図１ｂは、モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法を示す。ＴＯＳの複数のバージョンと、ユーザＳＤＫ及びベンダＳＤＫのその関連するバージョンとが、ベンダドライバソフトウェアの複数のバージョンとともにアーカイブに格納される。オープンアーキテクチャ試験システムのインストール及び構成管理（Installation and Configuration Management）（ＩＣＭ）システムの目的は、ベンダが、自身のハードウェアモジュールをサポートするようにドライバソフトウェアコンポーネントを開発することができるようにすること、及び、ユーザが、テスタ又は開発プラットフォームで動作する互換性のあるベンダドライバソフトウェア及びＴＯＳバージョンを選択することができるようにすることである。ＩＣＭシステムはまた、テスタ又は開発プラットフォームにこれらの選択された構成をインストールすること、及び任意に、選択された構成を起動することを管理する。
【００１５】
ＩＣＭシステムは、オープンアーキテクチャ試験システムのＴＯＳを管理するための要件及び管理することに関与するアクティビティについて説明する。オープンアーキテクチャ試験システムのＩＣＭには、４つの原則アクティビティが含まれる。
１．インストール
これは、オープンアーキテクチャ試験システムコンポーネントを、後に起動するか又は配備するためにアーカイブにコピーする行為を言う。
２．構成
これは、ユーザが、ＩＣＭシステムと対話することによって、ソフトウェア構成を起動に使用されるシステムプロファイルとして作成し、保存し、変更することができるようにする行為を言う。
３．起動
これは、選択されたソフトウェア構成（すなわちプロファイル）を、特定のテスタにおいてアクティブなものにする、すなわちそれを配備する行為を言う。
４．監査
これは、特定の試験システムにおいて目下アクティブなソフトウェアコンポーネント及びハードウェアコンポーネントのリストを提供する行為を言う。
【００１６】
本文書は、これらのアクティビティの各々に対する仕様を提供する。以下の論考において、ソフトウェア及びハードウェアそれぞれを指して、既知の略語ＳＷ及びＨＷを使用する。
【００１７】
なお、インストール及び構成はＩＣＭ特有のアクティビティ（概念的には特定のテスタに対してリモートに実行することができる）であるが、起動及び監査はテスタ特有であり、一定のオープンアーキテクチャ試験システムのＴＯＳコンポーネント、主にオープンアーキテクチャ試験システムのテスタ制御デーモン（Tester Control Daemon）（ＴＣＤ）からの支援を必要とする。このため、本文書はまた、ＩＣＭアクティビティに関与するＴＣＤ及びＴＯＳのいくつかの面とともに、ＴＣＤ自体のインストールについても説明する。この目的のために、テスタ制御及びＴＯＳスタートアップセクションがまず、オープンアーキテクチャテスタ制御及びＴＯＳシステムのスタートアップ手続きの説明を提供する。
【００１８】
また、オープンアーキテクチャ試験システムソフトウェア「パッチ」のリリースは、オープンアーキテクチャ試験システムソフトウェアコンポーネントを、より総合的なソフトウェアリリースの合間に修正し強化することの必須部分である。この目的のために、ソフトウェアパッチリリースセクションは、まず、オープンアーキテクチャ試験システムソフトウェアパッチリリースを作成し、配布し、使用する際に従う方法の説明を提供する。
【００１９】
（テスタ制御及びＴＯＳスタートアップ）
このセクションでは、オープンアーキテクチャテスタ制御及びスタートアップ手続きについて説明する。読者は、特に、オープンアーキテクチャ試験システムのシステムコントローラ（ＳｙｓＣ）及びサイトコントローラ（複数可）（ＳｉｔｅＣ）を備える汎用分散システムとしてのＴＯＳの編成に提示されるようなオープンアーキテクチャテスタアーキテクチャの基本に熟知しているものと想定する。
【００２０】
（テスタ制御デーモン）
オープンアーキテクチャ試験システムのＴＯＳの全般的な制御は、オープンアーキテクチャ試験システムのテスタ制御デーモン（ＴＣＤ）によって実行される。ＴＣＤに対する仕様は、以下のように要約される。
【００２１】
オープンアーキテクチャ試験システムのテスタ制御デーモンは、以下の機能に関与する。
システムブートアップ時の、若しくはユーザコマンドに基づく、オープンアーキテクチャ試験システムのＴＯＳのスタートアップ及び初期化、並びにシステム初期化が成功した後の、ユーザ定義オープンアーキテクチャ試験システムアプリケーションの任意のスタートアップ。
ＴＯＳコアサービスに接続された任意のオープンアーキテクチャ試験システムアプリケーションのシャットダウンを含む、ユーザコマンドに基づく任意のオープンアーキテクチャ試験システムのＴＯＳのシャットダウン。
システムプロファイルによって定義されるようなオープンアーキテクチャ試験システムの特定のソフトウェア構成の起動又は配備。ここで、「バージョン切替」は、本質的に目下有効なプロファイル以外のプロファイルの起動である。
【００２２】
オープンアーキテクチャ試験システムソフトウェア構成のシステムプロファイルについて以下に説明する。これは、特定のオープンアーキテクチャ試験システムソフトウェア構成を定義するために必要な情報の集まり全体である。論考の残りの部分では、テスタ制御デーモンを、Ｗｉｎｄｏｗｓオペレーティングシステム（ＯＳ）で使用されるものとして言及するが、概念は一般的であり、あらゆるオープンアーキテクチャ試験システムに適用可能である。
【００２３】
ＷｉｎｄｏｗｓシステムのＴＣＤは、ＳｙｓＣ及び全ＳｉｔｅＣにインストールされ且つそこで自動的に実行されるＷｉｎ３２サービス（それは、Ｗｉｎｄｏｗｓコントロールパネルを使用して利用可能なサービスダイアログボックスにおけるインストール済みサービスのリストに現れる）である。それは、上記機能を実行する（システムコントローラ側における）インタフェースメソッドを提供するＣＯＭコンポーネントである。それは、オープンアーキテクチャ試験システムソフトウェア（オンラインバージョンは、システムインテグレータによって工場出荷時にインストールされている）とは別個にインストールされ、ＯＳブート時における自動スタートアップのためにＷｉｎｄｏｗｓサービスコントロールマネージャに登録される。なお、主ＴＣＤは、システムコントローラで実行しているものであるが、補助ＴＣＤは、サイトコントローラで実行し、主ＴＣＤの後援のもとに個々のサイトコントローラを立ち上げるように作業することに関与する。
【００２４】
（ＴＯＳ制御及び工場出荷時ディレクトリ）
デーモンを適当にインストールし機能させるために、すべてのオープンアーキテクチャ試験システムは、ＴＯＳ制御コンポーネント及び工場出荷時情報を収容する標準ディレクトリ構造を有するように事前構成される。これを、以下の仕様として要約する。
すべてのオープンアーキテクチャ試験システムのシステムコントローラ及びサイトコントローラは、利用可能な場所<MAINTENANCE_ROOT>をルートとする、且つ図２ａに示し表１に説明するような構造を有する、ＴＯＳ制御及び工場出荷時ディレクトリ構造を有するように構成される。
【００２５】
表１は、図２ａに示す構造について説明する。なお、第１列に列挙するディレクトリは、<MAINTENANCE_ROOT>に関連している。
【００２６】
【表１】
【００２７】
<MAINTENANCE_ROOT>/binにインストールされるＴＣＤコントローラアプリケーションは、「start（開始）」、「stop（停止）」、「activate（起動）」等の基本テスタシステム制御コマンドをＴＣＤに送ることができる単純なコマンドラインアプリケーションであるように意図されている。Ａｄｖａｎｔｅｓｔ Ｔ２０００システムには、これらのタスクを実行するアプリケーションt2kctrlが搭載されている。
【００２８】
<MAINTENANCE_ROOT>/cfgディレクトリの内容は、システムインテグレータによって異なる可能性があり、いずれの場合にも、それは、対応するＴＣＤ又はそのインストーラが機能するために必要なテスタ情報を含む。たとえば、Ａｄｖａｎｔｅｓｔ Ｔ２０００テスタシステムは、<SystemDrive>:/T2000Maintenance/cfgに以下の情報を配置する。なお、<SystemDrive>は、Ｗｉｎｄｏｗｓによって事前定義される環境変数であり、デフォルトとして、Ｗｉｎｄｏｗｓ２０００では「C:」である。
【００２９】
工場で提供されるすべてのサイトコントローラの内部システムＩＰ名及びアドレスとともに、オープンアーキテクチャ試験システムソフトウェア起動プロセスがその義務を遂行するために必要な任意の特別なオープンアーキテクチャ試験システムのユーザアカウント及びパスワード情報を指定する、サイトコントローラの工場出荷時構成（標準Ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマット）。このファイルは、OASISSiteInfo.iniと命名される。
【００３０】
ユーザは、このファイルをオンラインシステムで変更してはならない。オフラインシステムの場合、ユーザは、必要な場合、デフォルト（ＳｙｓＣと同じマシンにおいて単一ＳｉｔｅＣを指定する）からこれを変更してもよい。オンライン及びオフライン両方で使用されるシステムの場合、オンラインモードは、最初のオンライン工場出荷時構成ファイル（又は工場認可技術者がハードウェアレイアウトの変更を反映するように最も最近更新した構成ファイル）を使用する必要がある。
タイプ、名前、動作周波数等、全テスタ特性と、
工場において構成されたハードウェアモジュール及びそれらのボード特有の詳細と、
ハードウェアモジュールが接続される工場において構成されたオープンアーキテクチャ試験システムモジュール接続イネーブラ（ＭＣＥ）ポートと、
各ハードウェアモジュール（ある場合）へのオープンアーキテクチャ試験システム同期化マトリクス接続と、
ハードウェアモジュールに対するテストヘッド接続と
に関する情報を含む工場出荷時仕様書（ＦＤＥＦ）ファイル。
【００３１】
ユーザは、このファイルをオンラインシステムで変更することはできず、変更は、マシンの物理構成を変更する認可された保守要員のみが行うことができる。オフラインシステムの場合、工場出荷時仕様書ファイルは、ある場合は提供される試験例と一貫する仮想マシン構成を定義し、ユーザは、必要な場合、自身の仮想テスタを構成するようにこれを変更してもよい。オンライン及びオフラインの両方で使用されるシステムの場合、オンラインモードは、最初のオンライン工場出荷時構成ファイル（又は、工場認可技術者がハードウェアレイアウトの変更を反映するように最も最近更新した構成ファイル）を使用する必要がある。
【００３２】
（テスタ状態及び状態遷移）
上述したように、ＴＣＤは、オープンアーキテクチャ試験システムのＴＯＳを開始することに関与する。ＴＯＳ立上げのメカニズムを理解するために、まずＴＯＳがとり得る状態と、それらの間で可能な遷移とを理解することが必要である。オープンアーキテクチャテスタの状態遷移図を図２ｂに示す。
【００３３】
図２ｂの状態の意味は以下の通りである。
状態０：テスタシステムはアイドル状態である。システムコントローラのＴＣＤは実行しておらず、ＴＯＳは実行していない。
状態１：少なくともシステムコントローラにおいてＴＣＤは実行しているが、ＴＯＳはまだ機能していない。
状態２：オープンアーキテクチャ試験システムのシステムコントローラプロセスは実行しているが、まだ初期化されておらず、ＴＣＤはすべてのサイトコントローラにおいて実行していてもいなくてもよく、オフラインモードでは、オープンアーキテクチャ試験システムのテスタエミュレータプロセスはまだ実行していない。
状態３'：（オフラインモードのみ）オープンアーキテクチャ試験システムのテスタエミュレータは、（単一の指定された）サイトコントローラコンピュータにおいて実行している。
状態３：少なくともサイトコントローラ１（ＳＩＴＥＣ−１）は、正しく初期化されており、システムはデフォルトパーティション化状態であり（すなわち、すべてのハードウェアモジュールがＭＣＥを介してＳＩＴＥＣ−１に接続されている）、さらに、すべての指定されたサイトコントローラもまた正しく初期化されてもよい。この時点で、システムは「準備完了」状態である、すなわちテストプランロード要求を受け入れるように構成されている。
状態４：ユーザテストプランは、１つ又は複数の互換性のあるサイトコントローラに正しくロードされており、その一部として、システムはテストプラン要件に適応するように（再）パーティション化されている可能性がある。
【００３４】
図２ｂに示す状態遷移をもたらすイベントについて後述する。ここでは、表記「t(x,y)」は、状態ｘから状態ｙへの遷移を指定する（なお、後の論考において言及するクライアントは、システムコントローラＴＣＤのクライアントであり、ＴＣＤにおいて適当なインタフェースを接続し且つ使用する、リモート又はローカルの任意のアプリケーションであってもよい）。
t(0,0) Ｗｉｎｄｏｗｓブートプロセスからのコマンド（又は対話式の手動「開始」要求）を受け取っても、Ｗｉｎｄｏｗｓサービスコントロールマネージャは、Ｗｉｎｄｏｗｓブートアップ中にシステムコントローラにおいてＴＣＤを始動できない。
t(0,1) Ｗｉｎｄｏｗｓブートプロセスからのコマンド（又は対話式の手動「開始」要求）を受け取ると、Ｗｉｎｄｏｗｓサービスコントロールマネージャは、システムコントローラにおいて、且つ恐らくはサイトコントローラにおいてＴＣＤを正しく始動する。
t(1,1) ＴＯＳを「始動する」クライアントコマンドを受け取っても、システムコントローラのＴＣＤは、ＴＯＳシステムコントローラプロセスを始動できない。
t(1,2) ＴＯＳを「始動する」クライアントコマンドを受け取ると、システムコントローラのＴＣＤは、ＴＯＳシステムコントローラプロセスを正しく始動する。
t(2,2) ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスの初期化が失敗する、すなわち、ＴＯＳシステムコントローラプロセスは、オフラインモードでオープンアーキテクチャ試験システムのテスタエミュレータプロセスを始動できず、又は少なくともＳＩＴＥＣ−１においてＴＯＳサイトコントローラプロセスを始動し初期化することができない。
t(2,3') （オフラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、（単一の指定された）サイトコントローラコンピュータにおいてオープンアーキテクチャ試験システムのエミュレータプロセスを正しく始動する。
t(3',3)* （オフラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、少なくともＳＩＴＥＣ−１に対するＴＯＳサイトコントローラプロセス（及び恐らくはすべての指定されたサイトコントローラのプロセス）を正しく始動し初期化する。
t(3',2) （オフラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、少なくともＳＩＴＥＣ−１に対するＴＯＳサイトコントローラプロセスを始動し初期化できない（エミュレータプロセスは終了する）。
t(2,3)* （オンラインモードのみ）ＴＯＳを「始動する」クライアントコマンドの一部として、ＴＯＳシステムコントローラプロセスは、少なくともＳＩＴＥＣ−１において（且つ恐らくはすべての指定されたサイトコントローラにおいて）ＴＯＳサイトコントローラプロセスを正しく始動し初期化する。
t(3,3) ユーザテストプランをロードするユーザコマンドを受け取っても、ＴＯＳは指定されたテストプランをロードできない。
t(3,4) テストプランをロードするユーザコマンドを受け取ると、ＴＯＳは、指定されたテストプランに関連するソケットの要件により（必要な場合）システムを正しく（再）パーティション化した後、指定されたサイトコントローラ（複数可）にテストプランを正しくロードする。
t(4,4) （同じか又は異なる）テストプランを（リ）ロードするユーザコマンドを受け取ると、ＴＯＳは、指定されたテストプランに関連するソケットの要件により（必要な場合）システムを正しく（再）パーティション化した後、指定されたサイトコントローラ（複数可）にテストプランを正しく（リ）ロードする。
t(3,1) ＴＯＳを「シャットダウン」するクライアントコマンドを受け取ると、ＴＣＤはＴＯＳを停止する。
t(4,1) ＴＯＳを「シャットダウン」するクライアントコマンドを受け取ると、ＴＣＤは、ある場合は実行中のテストプランを停止した後にＴＯＳを停止する。
なお、*は、その遷移に、ユーザ指定アプリケーションを始動しようと試みるＴＯＳシステムコントローラプロセスが付随することを示し、アプリケーションはＴＯＳの一部でないため、これらのアプリケーションのうちのいずれか又はすべてを始動できないことが正しいＴＯＳ初期化の失敗の要素とはならない。
【００３５】
上に示した遷移に加えて、システムコントローラで実行されるＷｉｎｄｏｗｓ「シャットダウン」コマンド（又はシステムの物理的なパワーダウン）により、テスタは、その時点での状態に係りなく状態０にリセットされる。
【００３６】
オープンアーキテクチャ試験システムのＴＯＳが立ち上げられるプロセスは以下の通りである（環境変数OASIS_INSTALLATION_ROOT、OASIS_ACTIVE_CONFIGS、OASIS_TOS_SETUP_FILE、OASIS_TPL_SETUP_FILE、OASIS_TOOLS_SETUP_FILE、OASIS_MACHINE_DIR及びOASIS_TEMPはすでに正しく定義されており、システムプロファイルは選択されているものと想定する）。
１．システムパワーオン（又はブートアップ）時、Ｗｉｎｄｏｗｓサービスコントロールマネージャはシステムコントローラ及びサイトコントローラにおいてＴＣＤを始動する。
２．システムコントローラのＴＣＤは、システムプロファイルが有効であることを検証し、サイトコントローラのプロファイル指定構成、すなわちファイル$OASIS_ACTIVE_CONFIGS/OAISSys.cfgを読み出し、ＴＯＳシステムコントローラプロセスを始動する。
３．そして、ＴＣＤは、ＴＯＳシステムコントローラプロセスにおいてinitialize()メソッドを呼び出す。これにより、
ａ．動作モードがオフラインである場合にのみ、テスタエミュレータプロセスが（単一の指定された）サイトコントローラコンピュータにおいて始動し、
ｂ．要求される各サイトコントローラのＴＣＤがそのＴＯＳサイトコントローラプロセスを始動し、
ｃ．各ＴＯＳコントローラプロセスにおいてinitialize()メソッドが呼び出され、
ｄ．少なくともＳＩＴＥＣ−１が正しく初期化された後、システムがデフォルトパーティション化される（すべてのハードウェアモジュールがＭＣＥを介してＳＩＴＥＣ−１に接続される）。
４．そして、ＴＣＤは、目下アクティブなプロファイルにおいて自動セットアップのためにリスト化された任意のユーザアプリケーションを指定された順序で始動しようと試みる。
【００３７】
ステップ００のうちのいずれかの間の失敗により、上述したような対応するシステム状態遷移をもたらす。ステップ０又は０における失敗は、Ｗｉｎｄｏｗｓイベントログに記録される。ステップ０における失敗は、ＴＯＳシステムコントローラプロセスとともにログとして記録され、それに接続するあらゆるクライアントアプリケーションが後に検索するために利用することができるようになる。
【００３８】
任意の自動アプリケーションスタートアップ
上述したように、オープンアーキテクチャ試験システムは、ユーザが、正しいＴＯＳスタートアップに続いて自動的にスタートアップされるべきアプリケーションを追加することができるようにする。ＯＣＴｏｏｌによって、ユーザは、自身の選択したかかるアプリケーションをシステムプロファイルの一部として指定することができる。かかるプロファイルが特定のテスタで起動されると（すなわち、そのプロファイルによって指定された構成が最新になると）、正しいＴＯＳ初期化の完了時にステップ０上のが実行される。
【００３９】
これを行うために、ＴＣＤは、ファイルOASISVer.cfgのスタートアップセクションを読み出す。これは、選択されたシステムプロファイルの属性を指定するデータファイルであり、標準Ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマットである。それは、そのセクションにおける各ラインを、新たなアプリケーションを立ち上げるコマンドラインとして扱う。アプリケーションはＴＯＳの一部でないため、リスト化されたアプリケーションのいずれか又はすべてを立ち上げることができないことは、ＴＯＳ立上げに関する限りエラー状態の要素とはならない。しかしながら、任意のかかる失敗は、ＴＯＳシステムコントローラプロセスに注記され格納される（アプリケーションが後に取り出すため）。
【００４０】
インストール
オープンアーキテクチャ試験システムのインストールは、３つの主要コンポーネントのインストールを含み、これらのコンポーネントの各々は独立してインストールされる。
１．オープンアーキテクチャ試験システムのテスタ制御デーモン（ＴＣＤ、オープンアーキテクチャ試験システムのソフトウェア起動又は配備の機能をカプセル化する）。
２．オープンアーキテクチャ試験システムの構成ツール（ＯＣＴｏｏｌ）。
３．オープンアーキテクチャ試験システムのシステムソフトウェア。
【００４１】
このセクションでは、これらのコンポーネントの各々に対してインストールプロセスを説明する。
【００４２】
（ＴＣＤインストール）
オープンアーキテクチャ試験システムのＴＣＤパッケージは、他のいかなるオープンアーキテクチャ試験システムコンポーネントからも独立してインストールされる。工場出荷状態の（factory-fresh）オンラインシステムの場合、ＴＣＤパッケージは通常プリインストールされる可能性がある。オフラインシステムの場合、且つＴＣＤに対する更新全般の場合、インストーラは、システムインテグレータによって提供される可能性がある。
【００４３】
Ｗｉｎｄｏｗｓでは、オープンアーキテクチャ試験システム<MNAINTENANCE_ROOT>は、必然的に、通常のＷｉｎｄｏｗｓ<SytemDrive>（「C:」ドライブであることが多い）のディレクトリとなる。それは、<SytemDrive>が、存在することが保証されているためである。たとえば、オープンアーキテクチャ試験システムのＡｄｖａｎｔｅｓｔ Ｔ２０００インプリメンテーションは、システムコントローラ及びサイトコントローラのディレクトリ「C:/T2000Maintenance」にルートを配置する。以下の論考では、<SystemDrive>は「C:」であるものとする。ＴＣＤパッケージのインストール中に辿るステップは以下の通りである。
１．上述したように、いくつかのコンポーネントが<MAINTENANCE_ROOT>にインストールされるため、<MAINTENANCE_ROOT>はＳｙｓＣ及びＳｉｔｅＣに存在する。
ａ．<MAINTENANCE_ROOT>が存在しない場合、ＴＣＤインストーラがそれを生成する。
ｂ．サイトコントローラ工場出荷時構成ファイル（Ａｄｖａｎｔｅｓｔ Ｔ２０００システムにおけるC:/T2000Maintenance/cfg/OASISSiteInfo.ini）が存在しない場合、インストーラがまた、インストールを実行している人からの入力に基づいてそれを生成する。
ｃ．オープンアーキテクチャ試験システム工場出荷時仕様書（ＦＤＥＦ）ファイル（Ａｄｖａｎｔｅｓｔ Ｔ２０００システムにおけるC:/T2000Maintenance/cfg/OASISHW.def）が存在する場合、
ｉ．オンラインシステムの場合、それはまったく置換も変更もされず、
ｉｉ．オフラインシステムの場合、オープンアーキテクチャ試験システムで提供される例と互換性のある仮想テスタをモデル化するように意図された<FDEF-name>.<example>と命名されたプリパッケージバージョンが、<MAINTENANCE_ROOT>/cfgにコピーされ、ユーザは、既存のＦＤＥＦファイルをこのファイルと置き換えるように通知される（ユーザがオープンアーキテクチャ試験システム例で作業したい場合）。
ｄ．ＦＤＥＦファイルが存在しない場合、
ｉ．オンラインシステムの場合、サンプルＦＤＥＦファイルがインストールされ、ユーザに対し、ユーザがインストールしたハードウェアと互換性があるようにそれを更新するよう警告される。
ｉｉ．オフラインシステムの場合、このファイルのプリパッケージバージョンが、ＦＤＥＦファイルとしてインストールされる（オープンアーキテクチャ試験システムによって必要とされる標準名で）。
２．インストーラは、<SystemRoot>/system32にＴＣＤバイナリをインストールし、あらゆる必要なＣＯＭコンポーネント登録のためにＷｉｎｄｏｗｓレジストリエントリを設定する。
３．インストーラは、ＴＣＤに対し以下の構成特性を設定する。
ａ．AutoStart（自動始動）：これは、ＷｉｎｄｏｗｓシステムブートによってＳｙｓＣ ＴＣＤがオープンアーキテクチャ試験システムのＴＯＳを自動的に始動するか（TRUE（真））又は始動しないか（FALSE（偽））を指定する。デフォルトはTRUEであり、インストールを実行している人は、必要な場合、それをFALSEに設定してもよい。
ｂ．Mode（モード）：これは、ＴＯＳがONLINE（オンライン）動作モード（適用可能な場合）で始動されるべきか又はOFFLINE（オフライン）動作モードで始動されるべきかを指定する。デフォルトはONLINEであり、インストールを実行している人は、必要な場合、それをOFFLINEに設定してもよい。
ｃ．Configuration（構成）：これは、ＴＯＳがコンポーネントのDEBUG（デバッグ）バージョンで始動されるべきか又はRELEASE（リリース）バージョンで始動されるべきかを指定する。デフォルトはRELEASEであり、インストールを実行している人は、必要な場合、それをDEBUGに設定してもよい。
４．インストーラは、ＴＣＤコントローラアプリケーション（t2kctrl）とその関連するＤＬＬを<MAINTENANCE_ROOT>/binにインストールする。
５．オープンアーキテクチャ試験システムによって要求される以下のオペレーティングシステム環境変数の各々に対し、インストーラは、（ｉ）それがすでに設定されているかを判断し、（ｉｉ）設定されていない場合、それをユーザ指定値に設定する。
ａ．OASIS_INSTALLATION_ROOT
ｂ．OASIS_ACTIVE_CONFIGS
ｃ．OASIS_MACHINE_DIR
ｄ．OASIS_TEMP
６．インストーラは、<MAINTENANCE_ROOT>/bin及び$OASIS_INSTALLATION_ROOT/binをＷｉｎｄｏｗｓシステムＰＡＴＨ環境変数に追加する（Ｗｉｎｄｏｗｓの規約により、<SystemRoot>/system32はすでにシステムＰＡＴＨ環境変数にあると想定する）。
【００４４】
なお、ステップ０上のに示すように、ＴＣＤ及びそれが依存するＤＬＬは、Ｗｉｎｄｏｗｓ<SystemRoot>/system32ディレクトリ（Ｗｉｎｄｏｗｓ２０００における<SystemDrive>/WINNT/system32であり、C:/WINNT/system32であることが最も多い）にインストールされる。それはその場所がＷｉｎｄｏｗｓサービスの適当な動作を保証するためである。さらに、<MAINTENANCE_ROOT>は、システムが適当に機能するためにシステムコントローラ及びサイトコントローラに存在する必要がある。このため、<MAINTENANCE_ROOT>（並びに<SystemRoot>/system32のＴＣＤ及びその関連するＤＬＬ）は、これらのコンポーネントが存在するローカルディスクを再フォーマットすることが望まれる場合、注意深くバックアップがとられ且つ復元されなければならない。オープンアーキテクチャテスタの任意のシステムプロファイルの起動は、インストールされ且つテスタで利用可能であるＴＣＤによって決まる。ＴＣＤは、本質的に、オープンアーキテクチャ試験システムソフトウェアから独立しているため、オープンアーキテクチャ試験システムソフトウェアのすべてのリリースと後方互換性があることが必要である。
【００４５】
（ＯＣＴｏｏｌインストール）
オープンアーキテクチャ試験システムの構成ツールＯＣＴｏｏｌは、オープンアーキテクチャ試験システムソフトウェアとは別個のパッケージで配布されインストールされる。
【００４６】
ＯＣＴｏｏｌのインストーラによって、ユーザは、ＯＣＴｏｏｌに対しインストール場所を選択することができる。ＯＣＴｏｏｌによって、ユーザは、テスタから独立したオープンアーキテクチャ試験システムのシステムプロファイルを作成し保存することができる。このため、オープンアーキテクチャ試験システムソフトウェアがインストールされるアーカイブ場所に任意の特定のテスタがアクセスすることができる限り、そのテスタに対してリモートの場所にそれを概念的にインストールすることができる。しかしながら、目下アクティブなシステムのルートである$OASIS_INSTALLATION_ROOTをルートとするディレクトリツリー内にある場所にそれをインストールしないように注意する必要がある。それは、後に、異なるプロファイルに対応するシステムを起動する結果、喪失する可能性があるためである。
【００４７】
ＴＣＤのように、ＯＣＴｏｏｌは本質的にオープンアーキテクチャ試験システムソフトウェアから独立しているため、オープンアーキテクチャ試験システムソフトウェアのすべてのリリースと後方互換性があることが必要である。
【００４８】
（オープンアーキテクチャ試験システムソフトウェアのインストール）
オープンアーキテクチャ試験システムソフトウェアのインストールとは、オープンアーキテクチャ試験システムソフトウェアコンポーネント（最終的にはファイル）を、オペレーティングシステム環境変数OASIS_ARCHIVE_ROOTによって定義される場所に物理的にコピーする行為を言う。この場所を、以下アーカイブと呼ぶ。アーカイブは、システムのユーザのためにオープンアーキテクチャ試験システムのベンダ及びシステムインテグレータが提供するファイルを含む。なお、これは、配備場所又はランタイム場所とは別個である。配備場所とは対照的に、アーカイブ場所は、ソフトウェアが配備されるテスタシステムで実行するＴＣＤがアクセス可能である限り、テスタシステムから物理的にリモートであってもよい。
【００４９】
インストールプロセスは、ＴＯＳコンポーネント及びベンダコンポーネントに対して同一である。各インストールされたファイルは、コンポーネントの特性を指定するコンポーネント構成レコード（Component Configuration Record）（ＣＣＲ）を有する。このため、以下の２つの要件は、インストールプロセスの仕様を要約する。
オープンアーキテクチャ試験システムソフトウェアのインストールは、定義されたアーカイブ場所にファイルをコピーする。この場所は、環境変数OASIS_ARCHIVE_ROOTによって指定される。
アーカイブにインストールされる各ファイルには、そのファイルに必要な記述的情報を含むコンポーネント構成レコードすなわちＣＣＲが付随する。
【００５０】
このため、ＴＯＳファイル及びベンダファイルは、共通のルート下に存在する。これらのファイルは、システムプロファイルを介して管理されるためには、オープンアーキテクチャ試験システムファイル命名要件に従う。これらの要件に従うことにより、システムのファイルを、管理するために単一アーカイブディレクトリに蓄積してもよい。これは、ＴＯＳファイルとベンダがインストールしたファイルとの両方に対して当てはまる。これらの要件については次に論考する。
【００５１】
ファイル命名要件
バージョン管理、切替及び監査を可能にするために、オープンアーキテクチャ試験システムにインストールされる各コンポーネント（すなわち各ファイル）は、以下のファイル命名フォーマットを使用し、それにより、名前が、同じベンダか又は異なるベンダからの他のインストールされたコンポーネントの名前と抵触することを防ぐ。
ＴＯＳコンポーネント及びベンダコンポーネントは、以下の命名フォーマットを使用する。
VendorID_ComponentName_[D_]VersionIdentifier[.ext]
【００５２】
フォーマットの説明は以下の通りであり、角括弧（[]）内の要素は任意の項目を表す。
１．VendorID：２〜３文字のベンダ識別コード。このコードは、コンポーネントをＴＯＳコンポーネント又はベンダ特有のコンポーネントとして識別し、ファイルの明確化を可能にする。なお、ベンダがシステムに導入するファイルを管理するのは各ベンダの責任であることに留意する。先頭文字は英数字であるべきであり、下線文字であってはならない。ＴＯＳランタイムコンポーネントは、「ＯＡＩ」を識別子として使用する。VenderID部の後に下線文字「_」が続く。
２．ComponentName：コンポーネントサプライヤが選択する任意の名前。ComponentName部の後に下線文字「_」が続く。
３．D：これは任意であり、実行可能コンポーネントに適用可能である。かかるコンポーネントの場合、そのコンポーネントがデバッグダイナミックリンクライブラリ（ＤＬＬ）又は実行ファイル（ＥＸＥ）を表す場合にのみ、ComponentNameの後に「D」が続く。「D」がない場合は、そのコンポーネントが非デバッグバージョン（すなわち「リリース」バージョン）であることを意味する。存在する場合、「D」部の後に下線文字「_」が続く。
４．VersionIdentifier：システムに導入されるすべてのファイルの明示的なバージョニングは基本要件である。異なるオペレーティングシステム間で互換性があるように、バージョニングは、VersionIdentifierフィールドとして、ファイル名の一部として表される。このフィールドは以下のフォーマットを有する。
major.minor.patch
ここで、major、minor及びpatchの各々は、コンポーネントのそれぞれメジャーバージョン、マイナーバージョン及びパッチバージョンを表す非負整数値である。
５．ext：拡張子は、.dll、.exe、.txt、.doc等、（任意の）ＯＳ特有の識別支援である。
【００５３】
なお、すべての場合において、ファイルの名前はサポートされるすべてのプラットフォーム（Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ等）において適法であることに留意する。いくつかの例は、以下の通りである。
AT_PinModule_10.01.008.dll
AT_PinModule_10.01.008_D.dll
AT_HCPowerSupplyModule_09.45.003.dll
OAI_utils_00.03.000.dll
【００５４】
（インストールディレクトリ構造）
OASIS_ARCHIVE_ROOTをルートとするディレクトリ構造は、図３、図４及び図５に示す通りであり、以下のようにさらに説明する。以下の論考において、ソフトウェア開発キットを、多くの場合その略語で「ＳＤＫ」と呼ぶ。また、表記「$foo」は、オペレーティングシステム環境変数fooの値を指す。インストールプロセスは以下に従う。
図３、図４及び図５に示し且つ表４において説明するように、すべてのオープンアーキテクチャ試験システムソフトウェアコンポーネントファイルは、$OASIS_ARCHIVE_ROOTの下の適当な場所にインストールされる。
インストール（すなわちアーカイブ）場所は、ＴＯＳを起動することが望まれるテスタシステムからアクセス可能である。
【００５５】
図３、図４及び図５において、OAIと命名されたディレクトリは、オープンアーキテクチャ試験システムのＴＯＳファイルを含み、<vendor>と命名されたディレクトリはベンダ特有のファイルを含む。各ベンダは独自のディレクトリを有し、<vendor>は一意の２〜３文字の識別子を示す（たとえば、アドバンテストのベンダディレクトリにはATが付される）。なお、各ベンダ特有のディレクトリ内で、ベンダは、それらのファイル名が一意であることを確実にする責任があることに留意する。また、ファイル名の明示的なバージョン識別子が要求されることにより、同じコンポーネントの異なるバージョンを同じ場所に格納することができることにも留意する。
【００５６】
表２は、上記図で概説されるディレクトリ構造についてさらに説明する。ここでは、第１列の各ディレクトリは$OASIS_ARCHIVE_ROOTに関連する。
【００５７】
【表２】
【００５８】
インストールログ
ディレクトリリログはサブディレクトリインストーラを含む。この場所は以下の仕様をサポートする。
オープンアーキテクチャ試験システムソフトウェアのためのインストーラは、既知の場所、すなわち$OASIS_ARCHIVE_ROOT/logs/Installerにおいてインストールログを作成する。
【００５９】
ＴＯＳインストールログファイルに対して使用される命名規則は、OAI_<version>.logである。ベンダインストーラは、命名規則<vendor>_<version>.logを使用する。２つのさらなる要件は以下の通りである。
インストールログは、アーカイブにコピーされる１つ１つのファイルの完全修飾パスを明示的に示すテキストファイルである。
インストーラが、コンポーネントを追加又は除去するために複数回実行される場合、インストールログは、アーカイブにコピーされるか又はアーカイブから除去されるファイルの現ステータスを示すように更新される。
【００６０】
新たなコンポーネントバージョンのインストール
コンポーネントの新たなバージョンがリリースされると、コンポーネントサプライヤ（ＴＯＳ又はベンダ）は、その新たなコンポーネントバージョンに対してＣＣＲを提供する。コンポーネント構成要素のファイル名は、ファイル命名要件セクションで説明したようにコンポーネントの新たなバージョンを反映し、ファイル命名規則に従うことにより既存のファイルに上書きすることが防止される。このため、コンポーネントファイルバージョンは、アーカイブディレクトリに蓄積し続ける。
【００６１】
なお、インストールパッケージ（後述するリリースグループＣＣＲのうちの１つ、又は直接ベンダリリースに対する任意のベンダ提供リリースＣＣＲによって示される）は、コンポーネントの現リリースバージョンを修正し又は拡張するように意図された個々のコンポーネントを含んでもよい。既存のコンポーネントの新たなバージョンは既存のコンポーネント／ファイルに置き換わらないため、いかなる既存のシステムプロファイルも実行し続けることができる。コンポーネントのパッチに対する以下の要件に留意する。
新たなパッチが利用可能となると（major.minor.patchトリプレットバージョン識別子のパッチコンポーネントにおける変更によって示されるように）、それは、ＴＯＳリリースのメジャー／マイナーバージョンと互換性がある。
【００６２】
かかる「パッチ」に対する詳細なメカニズムについて、リリースグループＣＣＲ及びユーザのシステムプロファイルについて説明した後に後述する。
【００６３】
構成
構成とは、ユーザがＩＣＭシステムと対話することによりオープンアーキテクチャ試験システムソフトウェア構成をシステムプロファイルとして作成し、保存し、変更することができるようにする行為であり、かかるシステムプロファイルは、後に特定のテスタシステムにおいて特定の構成を起動するために使用される。このセクションは、この機能を実行するためにＩＣＭによって提供されるメカニズムについて説明する。
【００６４】
（コンポーネント及び構成レコード）
オープンアーキテクチャ試験システムでは、コンポーネントは、システムの別個のモジュールを表す１つ又は複数のファイル、環境設定等である。システムコンポーネントの重要なカテゴリは、システムハードウェアモジュールのソフトウェア表現であり、それらは主要コンポーネントとしてみなされる。コンポーネントの別のカテゴリは、たとえば、ＳＤＫのためのインタフェース定義ファイルである。
【００６５】
単一コンポーネントＣＣＲ
上述したように、アーカイブにインストールされる各オープンアーキテクチャ試験システムソフトウェアコンポーネントには、ファイルの特性を指定するコンポーネント構成レコード（ＣＣＲ）が付随する。このため、構成制御下にあるＴＯＳファイル又はベンダファイルは、アーカイブにインストールされる時にＣＣＲに関連付けられる。ＣＣＲは、アーカイブにインストールされるファイルの記述であり、そのファイル、そのバージョン番号、その関連コンポーネント、その従属性、その非互換性等に関する情報を含む。ＣＣＲは、ＯＣＴｏｏｌへの入力としての役割を果たし、ユーザが試験システムにインストールされたコンポーネントのすべてを見て、制御し、追跡し、管理することができるようにする。ＣＣＲに対する命名要件は、.ccrという必須の追加の拡張子が必要であることを除き、それが記述する対応するシステムファイルに対するものと同一である。このため、ファイルAT_PinModule_0.5.1.dllのＣＣＲは、AT_PinModule_0.5.1.dll.ccrと命名される。なお、インストールされるＣＣＲは、インストールの最初の参照として<OASIS_ARCHIVE_ROOT>/InstallCCRにそのまま維持されることに留意する。ＣＣＲファイルは、コンポーネントファイルと同じディレクトリ場所に配置される（コンポーネントファイルはアーカイブディレクトリに関連して格納される）が、InsallCCRディレクトリに関連する。
【００６６】
グループＣＣＲ
ＣＣＲを、複数のＣＣＲを参照するグループとして表すことができる。実際には、これは、ＣＣＲは必然的に製品リリースパッケージにマップするため、それらが多くの場合にシステムに導入される主な方法である。ユーザはまた、必要な場合、プロファイルに含めるためにＣＣＲグループ全体を選択することも可能である。
【００６７】
オープンアーキテクチャ試験システムのインストールのためにいくつかの重要な必要なグループＣＣＲがある。インストールされた各オープンアーキテクチャ試験システムソフトウェアコンポーネントファイルに対するＣＣＲのほかに、以下のリリースグループＣＣＲが必要である。
ＴＯＳサプライヤ／システムインテグレータによって提供されるオープンアーキテクチャ試験システムのＴＯＳリリースＣＣＲ、
システムインテグレータ又はUserSDKサプライヤによって提供されるオープンアーキテクチャ試験システムのUserSDKリリースＣＣＲ、
システムインテグレータ又はVendorSDKサプライヤによって提供されるオープンアーキテクチャ試験システムのVendorSDKリリースＣＣＲ。
【００６８】
グループＣＣＲは、以下のグループ／ファイル命名フォーマットを使用する。
VendoerID_GroupType[_UserGivenName]_VersionIdentifier.gccr
UserGivenNameは任意である。
【００６９】
OAI_TOS_<version>.gccrと命名されたＴＯＳリリースＣＣＲは、名目的に「<version>」リリースと名称が付されたオープンアーキテクチャ試験システムＴＯＳランタイムの全リリースの内容を記述するグループＣＣＲである。なお、上で定義したように、<version>はVersionIdentifierである。それは、オープンアーキテクチャ試験システムＴＯＳランタイムの「<version>」リリースをまとめて定義する個々のコンポーネントＣＣＲすべてに対する参照を含む。このＣＣＲのタイプは「TOS」である。
【００７０】
同様に、UserSDKリリースＣＣＲ及びVenderSDKリリースＣＣＲ（それぞれOAI_USER_SDK_<version>.ccr及びOAI_VENDOR_SDK_<version>.gccr）は、オープンアーキテクチャ試験システムのユーザＳＤＫ及びベンダＳＤＫの全リリースの内容を記述するグループＣＣＲであり、それぞれタイプ「USER_SDK」及び「VENDER_SDK」である。
【００７１】
上記必要なグループＣＣＲに加えて、ハードウェアモジュールベンダは、関連コンポーネントのリリースを制御するグループＣＣＲを提供するように選択してもよい。これらのグループＣＣＲは、タイプ「VENDOR」、「USER」及び「TOOLS」である。
【００７２】
単一コンポーネントＣＣＲにおける情報
上述したように、オープンアーキテクチャ試験システムの主要コンポーネントは、ハードウェアモジュールのソフトウェア表現である。ＣＣＲの情報内容は、すべてのコンポーネントカテゴリの最も複雑なものである、かかる主要コンポーネントをサポートするために必要な属性のすべてを指定することに向けられている。かかる属性は、コンポーネントの他のより単純なカテゴリには必要でない場合が多く、そのようなカテゴリにはかかる属性の値を定義する必要はない。
【００７３】
ＣＣＲに含まれる情報は表３に示すようなものである。オープンアーキテクチャ試験システム主要コンポーネントをサポートするＣＣＲに対し、この情報を提供するのはハードウェアモジュールベンダの責任である。
【００７４】
【表３】
【００７５】
ベンダデジタルピンモジュールのためのドライバＤＬＬに対し、単純な単一コンポーネントＣＣＲファイルの例を以下に示す。
【００７６】
Version 1.0;
Description "Advantest Digital Pin Module Driver";
VendorName AT;
VendorID 1;
ModuleName DM250MHz;
ModuleID 4;
FileParams "";
Function Driver;
Resource "moduletrigger{MaxAvailable = 4;}",
"dpin{MaxAvailable=32;}";
HardwareRev 1095188784;
DeployTo SYSC;
Register "N";
GroupDependency AT_VENDOR_Modules_1.0.1.0,
AT_Tools_GemTools_1.01.0;
GroupIncompat OAI_TOS(<0.5.0);
GompIncompat AT_PinModule.dll(<0.5.0);
CompType Bin;
【００７７】
次は、同じベンダデジタルピンモジュールに対する較正ＤＬＬのための単一コンポーネントＣＣＲファイルの一例である。
【００７８】
Version 1.0;
Description "Advantest Digital Pin Module Calibration DLL";
VendorName AT;
VendorID 1;
ModuleName DM250MHz;
ModuleID 4;
FileParams "";
Function Calibration
[cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini];
HardwareRev 1095188784;
DeployTo SYSC;
Register "N";
GroupIncompat OAI_TOS(<0.5.0);
【００７９】
なお、Versionは、ＣＣＲ記述言語のバージョンを指定し、必ずしもそれが記述する任意のコンポーネントのバージョン（複数可）に関連しない。上記第１の例のResourceフィールドは、このモジュールドライバ（ＤＭ２５０ＭＨｚハードウェアモジュールの場合）が、４ユニットのモジュールトリガリソースと３２ユニットのｄｐｉｎリソースを提供するハードウェアモジュールを駆動することができることを示す。パラメータ「cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini」（第２の例においてCalibrationとして指定されるFunctionの場合）は、較正プログラムアルゴリズムバージョン情報を含むファイルのパス名を指定する。これは、構成データベース（ＣＤＢ）へのインポート後、ＯＣＴｏｏｌにより較正バンドル情報を生成するために使用される。各例におけるGroupIncompatフィールドに対する「OAI_TOS(<0.5.0)」の値は、ＣＣＲが記述するＤＬＬが、バージョン番号が０．５．０未満であるＴＯＳリリースグループＣＣＲに含まれるオープンアーキテクチャ試験システムのＴＯＳコンポーネントと互換性がないことを示す。
【００８０】
グループＣＣＲの情報
グループＣＣＲは、個々のコンポーネントの集まりを記述するＣＣＲか又は他のグループＣＣＲである。グループＣＣＲに含まれる情報を表４に示す。
【００８１】
【表４】
【００８２】
以下は、オープンアーキテクチャ試験システムのＴＯＳリリースのグループＣＣＲの一例である。
【００８３】
Version 1.0;
ComponentGroup OAI_TOS_1.1.0.029
{
Description "Open architecture test system TOS Release Package";
VendorName AT;
VendorId 1;
OAIMCFVersion "＞=1.0";
OAISimVersion "＞=0.9.5";
OAIOCFVersion "＞=1.0.1";
Component
{
bin/OAI/OAI_Core_0.4.9.dll.ccr;
bin/OAI/OAI_StdProxy_0.3.7.dll.ccr;
...
}
}
【００８４】
グループＣＣＲのインポート
グループについて記述することに加えて、グループＣＣＲは他のグループＣＣＲをインポートすることができる。以下はグループＣＣＲをインポートする一例である。
【００８５】
Version 1.0;
Import OAI_USERSDK_1.0.0.1;
ComponentGroup OAI_TOS_1.1.0.029
{
Description "Open architecture test system's TOS Release Package";
VendorName AT;
VendorId 1;
OAIMCFVersion "＞=1.0";
OAISimVersion "＞=0.9.5";
OAIOCFVersion "＞=1.0.1";
Component
{
bin/OAI/OAI_Core_0.4.9.dll.ccr;
bin/OAI/OAI_StdProxy_0.3.7.dll.ccr;
...
}
}
【００８６】
（構成データベース）
ＩＣＭ構成データベース（ＣＤＢ）は、インストールされたすべてのＣＣＲを通して表されるシステム構成データの集まりを保持する。ＣＤＢはまた、ユーザ作成システムプロファイル情報も保持する。ＣＤＢにおいて管理される情報は、いかなる特定のテスタインストールからも独立している。
【００８７】
ＣＤＢの作成とＣＣＲデータをそれにインポートすることとは、オープンアーキテクチャ試験システムのCDBMrgツールによって処理される。CDBMgrツールは、テスタにインストールされる必要もテスタで実行される必要もなく、それが操作する情報は特定のテスタに特化していない。しかしながら、それは、$OASIS_ARCHIVE_ROOTをルートとするディレクトリツリー内に格納されたＣＣＲファイルを読み出す必要があるため（インポート機能）、そのディレクトリツリーにアクセスする必要がある。
【００８８】
ＣＤＢの情報を使用してシステムプロファイルが作成され、それもまたＣＤＢに格納される。これについては次に説明する。
【００８９】
（システムプロファイル）
以下の要件はシステムプロファイルを指定する。
ユーザが選択するオープンアーキテクチャ試験システムのシステムプロファイルは、オープンアーキテクチャ試験システムで作業するために要求される特定のオープンアーキテクチャ試験システムソフトウェア構成を定義するために必要な情報の全体の集まりである。
【００９０】
システムプロファイルは、いかなる特定のテスタに特化した情報も含まず、むしろ、すべての必要な情報と、テスタで起動するためにユーザが選択するソフトウェアコンポーネントの以下のセット間の相互依存性とをカプセル化する。
ハードウェアモジュール関連ソフトウェア（ドライバ、エミュレーション、較正及び診断コンポーネント）、
オープンアーキテクチャ試験システムランタイムソフトウェア、
ユーザＳＤＫコンポーネント（試験開発環境に必要）及び
ベンダＳＤＫコンポーネント（モジュール開発環境に必要）。
【００９１】
なお、ユーザ作成システムプロファイル情報はＣＤＢに格納されるが、システムプロファイルを（ＯＣＴｏｏｌを介して）エクスポートする行為により、プロファイルを定義するすべての関係するテスタ独立情報を含むファイルを作成することができ、それによりプロファイルをＣＤＢの外部で利用することができるようになる。そして、これを、オープンアーキテクチャ試験システムの起動プロセスによって使用することができる。プロファイル情報が格納されるファイルはOASISVer.cfgと命名され、それは標準ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマットであり、且つデフォルトとして対応する$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>ディレクトリに格納される。しかしながら、プロファイルをエクスポートしている間、ユーザは、自身が選択した任意の場所にファイルを配置するように選択することができる。
【００９２】
起動中、ユーザプロファイルに格納されたテスタ独立情報は、テスタ特有情報と結合されることによりテスタのアクティブ構成を形成する。これは、$OASIS_ACTIVE_CONFIGSに格納された１組の試験環境ファイルを含む。起動については以下のセクションで説明し、そこではシステムプロファイルについて再び取り上げる。
【００９３】
（ＯＣＴｏｏｌ）
オープンアーキテクチャ試験システムのＣＤＢにＣＣＲデータが取り込まれると、構成ツール（ＯＣＴｏｏｌ）を使用して、ユーザが作成したシステムプロファイルが作成され、保存され、変更されエクスポートされる（すなわち、ＣＤＢの外部で利用可能にされる）。
【００９４】
ＯＣＴｏｏｌは、テスタにインストールされる必要もテスタで実行される必要もなく、それが操作する情報は特定のテスタに特化しない。しかしながら、それは、ユーザプロファイル情報を$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>に保存する必要があるため（エクスポート機能）、$OASIS_ARCHIVE_ROOTをルートとするディレクトリツリーにアクセスする必要がある。
【００９５】
起動
以下の要件は、オープンアーキテクチャ試験システムのソフトウェアシステム起動を指定する。オープンアーキテクチャ試験システムのソフトウェアシステムの起動は
１．選択されたシステムプロファイルにおけるテスタ独立構成情報を使用し、
２．それをテスタ特有情報と結合することにより$OASIS_ACTIVE_CONFIGSにテスタアクティブ構成情報を作成し、
３．$OASIS_INSTALLATION_ROOTの下にすべてに必要なソフトウェアコンポーネント（ファイル）を配備し（すなわち、配置し登録し）、
４．ターゲットテスタにおける選択された構成によりオープンアーキテクチャ試験システムのＴＯＳを開始する
行為である。
【００９６】
オープンアーキテクチャ試験システムのソフトウェアシステムの起動は、オープンアーキテクチャ試験システムのテスタ制御デーモン（ＴＣＤ）の機能である。上述したように、ＴＣＤは、接続されたアプリケーションがテスタ制御コマンドを送出することができるようにするＣＯＭインタフェースメソッドを提供する。<MAINTENANCE_ROOT>/binにインストールされるＴＣＤコントローラアプリケーションは、「start」、「stop」、「activate」等の基本テスタシステム制御コマンドをＴＣＤに送出することができる単純なコマンドラインアプリケーションであることを想起されたい。また、これは、Ａｄｖａｎｔｅｓｔ Ｔ２０００システムにおけるt2kctrlアプリケーションであることも想起されたい。このセクションでは、t2kctrlアプリケーションを使用して「起動」機能を実行することについて説明する。
【００９７】
（前提条件）
特定のオープンアーキテクチャ試験システム構成を（選択されたプロファイルを介して）起動しようと試みる前に、以下の前提条件が満足されなければならない。
１．$OASIS_ARCHIVE_ROOTによって指定される場所は、ターゲットテスタマシンのシステムコントローラで実行しているＴＣＤによってアクセス可能である。
２．先に定義されたオープンアーキテクチャ試験システムのシステムプロファイルは、OASISVer.cfgにエクスポートされており、$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>又はユーザが選択した別の場所のいずれかにおいて入手可能であり、エクスポートされたファイルOASISVer.cfgは、ターゲットテスタマシンのシステムコントローラで実行しているＴＣＤによってアクセス可能である。
３．環境変数OASIS_INSTALLATION_ROOT及びOASIS_TEMPが定義されている。なお、$OASIS_INSTALLATION_ROOTによって示される場所において、オープンアーキテクチャ試験システムのシステムソフトウェアの別の構成がすでに入手可能である場合、そのインストールは${OASIS_INSTALLATION_ROOT}_BAKにバックアップされ、起動プロセスは、成功した場合、$OASIS_INSTALLATION_ROOTの下に選択された新たな構成を配置することに留意する。
４．環境変数OASIS_ACTIVE_CONFIGSが定義されている。なお、このディレクトリがすでに存在し、オープンアーキテクチャ試験システムのシステムソフトウェアに対するアクティブ構成情報の別のセットがその場所ですでに入手可能である場合、そのインストールは${OASIS_ACTIVE_CONFIGS}_BAKにバックアップされ、起動プロセスは、成功した場合、$OASIS_ACTIVE_CONFIGSの下に選択された新たなアクティブな構成に対応する試験環境ファイルを作成することに留意する。
５．環境変数OASIS_MACHINE_DIRが定義されている＊。なお、このディレクトリがすでに存在する場合、ディレクトリ$OASIS_MACHINE_DIR/CD/bundlesが任意の既存の較正／診断（ＣＤ）バンドル記述ファイルから消去され、選択されたプロファイルに関連するＣＤバンドル記述ファイル（複数可）がその場所にインストールされることに留意する。
６．テスタ工場出荷時（ＦＤＥＦ）ファイル<MAINTENANCE_ROOT>/cfg/OASISSHW.defがシステムコントローラに存在する。このファイルは、起動プロセスに対しテスタ特有情報を提供するために必須である。
７．オープンアーキテクチャ試験システムが状態ｎ、ｎ＞０にある、すなわち、少なくともターゲットマシンのシステムコントローラにおけるＴＣＤが実行されている。そうでない場合、コマンド「net start T2000Svc」を発行することによりそれを始動しなければならない。
【００９８】
（t2kctrlアプリケーションの使用）
以下のコマンドを使用して、ターゲットマシンのシステムコントローラから起動プロセスを呼び出してもよい。
t2kctrl switch<config><archive_location><profile-directory-name>
ここで、
<config>はDEBUG又はRELEASEのうちの一方であるべきであり、インストールされるべきソフトウェアのビルドモードを示す。
<archive_location>は、環境変数OASIS_ARCHIVE_ROOTによって示される場所のフルパス名を指定するべきである。
<profile-directory-name>は、エクスポートされたプロファイル情報が位置するプロファイルディレクトリのフルパス名を指定するべきである。
【００９９】
（起動プロセス）
適当なコマンドが発行されると、起動のプロセスは以下の通りである。
１．テスタが状態≧２（１０ページ参照）である場合、システムコントローラＴＣＤはまず、システムを最終的に状態１にするＴＯＳ「シャットダウン」コマンドを発行する。この時点でいずれかのオープンアーキテクチャ試験システムアプリケーションがシステムコントローラに接続されている場合、それに対して切断するよう要求するメッセージが送出され、その状態をクリーンアップし適切に（gracefully）終了するために十分な時間が与えられるか、又は強制終了される。なお、これは、その時点でシステムコントローラに接続されていないアプリケーションに対しては適用されないことに留意する。
２．システムが状態１にになると、ある場合は$OASIS_INSTALLATION_ROOTにおける現インストールが${OASIS_INSTALLATION_ROOT}_BAKにバックアップされ、Ｗｉｎｄｏｗｓレジストリに登録されたオープンアーキテクチャ試験システム実行ファイルのすべて（表７の「Register」フィールド参照）の登録が取り消される。これは、システムコントローラとすべてのサイトコントローラとに対して行われる。
３．その後、ある場合は、$OASIS_ACTIVE_CONFIGSの現アクティブ構成情報が${OASIS_ACTIVE_CONFIGS}_BAKにバックアップされ、$OASIS_MACHINE_DIR/CD/bundles（ある場合）のＣＤバンドル記述ファイル（複数可）が削除される。
４．現インストール情報及びアクティブ構成情報のバックアップ（必要な場合）が正しく完了した後、ＴＣＤは、選択された（新たな）ファイルによって指定されるように、次のセクションで指定される場所に、アーカイブされたオープンアーキテクチャ試験システムのソフトウェアシステムファイルをコピーする。分散環境（別々のシステムコントローラ及びサイトコントローラ（複数可））では、サイトコントローラにインストールされる必要のあるファイルもまたそれらのマシンにコピーされる。
５．そして、ＴＣＤは、システムコントローラ及びサイトコントローラ（複数可）の両方に、Ｗｉｎｄｏｗｓレジストリに登録される必要のあるすべてのオープンアーキテクチャ試験システム実行ファイルを登録する。
６．そして、選択された（新たな）プロファイルからのテスタ独立情報は、ＴＣＤにより、テスタ工場出荷時ファイル（システムコントローラの<MAINTENANCE_ROOT>/cfgディレクトリに位置する）からのテスタ特有情報と結合される。これにより、ターゲットテスタマシンにおいて新たなオープンアーキテクチャ試験システムソフトウェアランタイムインストールのためにアクティブ構成を定義するファイルの以下のセットが生成される。
モジュール構成ファイル, OASISModules.cfg.
シミュレーション構成ファイル, OASISSim.cfg.
システム構成ファイル, OASISSys.cfg.
オフライン構成ファイル, OASISOffline.cfg.
これらのファイルは、ＴＣＤにより$OASIS_ACTIVE_CONFIGSに配置される。
７．ＴＣＤはまた、新たなプロファイルによりシステムの内容及び構成の記録としての役割を果たす、新たなプロファイル情報ファイルOASISVer.cfgのコピーを$OASIS_ACTIVE_CONFIGSの場所に配置する。
８．最後に、ＴＣＤは、ＴＯＳスタートアッププロセスのステップ０〜０において概説されたＴＯＳ「スタートアップ」シーケンスに従うことにより、新たな構成においてＴＯＳを始動し、それにより起動プロセスを完了する。
【０１００】
なお、上記ステップのうちのいずれかを正しく実行できないことにより、オープンアーキテクチャ試験システムインストールは、起動コマンドが発行される前の構成に戻り、ＴＣＤはその構成においてＴＯＳを再始動することに留意する。さらに、プロセス全体の詳細なログは、場所$OASIS_INSTALLATION_ROOT/logs/Deploymentに保持される。そのログはDeployment.logと命名され、ＴＣＤの「activate」コマンドが新たに呼び出される度に上書きされる。
【０１０１】
（配備ディレクトリ構造）
上述したように、ＴＣＤは、要求されたオープンアーキテクチャ試験システムのソフトウェアファイルを、$OASIS_ARCHIVE_ROOT下のそれらのアーカイブされた場所から、ターゲットテスタの$OASIS_INSTALLATION_ROOTにおける配備又はランタイムインストールにコピーする。
【０１０２】
$OASIS_INSTALLATION_ROOTをルートとする、テスタのオープンアーキテクチャ試験システム配備のディレクトリ構造は、図６、図７及び図８に示す通りである。起動プロセスは以下に従う。
すべてのオープンアーキテクチャ試験システムソフトウェアコンポーネントファイルが、テスタマシンのランタイムの起動のために、図６、図７及び図８に示され表８において説明されるように$OASIS_INSTALLATION_ROOT下の適当な場所に配備される。
【０１０３】
以下の図において、OAIと命名されたディレクトリは、オープンアーキテクチャ試験システムのＴＯＳファイルを含み、<vendor>と命名されたディレクトリはベンダ特有ファイルを含む。アーカイブ構造におけるように、各ベンダはそれ自体のディレクトリを有し、<vendor>は一意の２〜３文字識別子を示す（たとえば、ＡｄｖａｎｔｅｓｔベンダディレクトリにはATが付される）。
【０１０４】
表５は、上記図で概説されるディレクトリ構造についてさらに説明する。ここでは、第１列の各ディレクトリは$OASIS_INSTALLATION_ROOTに関連する。
【０１０５】
【表５】
【０１０６】
ファイル名変換
起動中、ファイルがアーカイブからランタイム環境に配備されると、ＴＣＤは、ファイル名に埋め込まれたバージョン識別子を取り除く。このため、たとえば、アーカイブのファイルOAI_utils_0.1.2.dllが、ランタイムインストールのファイルOAI_utils.dllにコピーされ、アーカイブのファイルAT_Cal_DM250MHz_D_1.2.3.dllが、ランタイムインストールのファイルAT_Cal_DM250MHz_D.dllにコピーされる。
【０１０７】
（アクティブテスタ構成）
起動プロセスで説明したように、ターゲットテスタマシンのオープンアーキテクチャ試験システムの配備中、選択された（新たな）プロファイルからのテスタ独立情報は、ＴＣＤにより、ＦＤＥＦファイルからのテスタ特有情報と併合される。これにより、ターゲットテスタマシンにおける新たなオープンアーキテクチャ試験システムソフトウェアランタイムインストールのためにアクティブ構成を定義する以下のファイルのセットが作成される。
【０１０８】
The Module Configuration File, OASISModules.cfg.
The Simulation Configuration File, OASISSim.cfg.
The System Configuration File, OASISSys.cfg.
The Offline Configuration File, OASISOffline.cfg.
【０１０９】
これらのファイルは、ＴＣＤにより$OASIS_ACTIVE_CONFIGSに配置される。なお、$OASIS_ACTIVE_CONFIGSを、$OASIS_INSTALLATION_ROOTをルートとするディレクトリツリー内の場所に設定してはならないことに留意する。
【０１１０】
（オープンアーキテクチャ試験システムマシンデータ）
較正／診断（ＣＤ）データ等のテスタマシン特有データは、システムコントローラにおいて環境変数OASIS_MACHINE_DIRによって示される場所の下に格納される。データのほかに、CDdataディレクトリは、サブディレクトリCD/bundlesを含み、これは、目下配備されている（すなわちアクティブな）プロファイルに関連するＣＤバンドル記述ファイル（複数可）を格納するために使用される。
【０１１１】
なお、$OASIS_MACHINE_DIRの場所のデータセットは、ユーザによって完全に保持され、特定のマシンが要求するように適当なデータセットを利用可能にするのはユーザの責任であることに留意する。しかしながら、起動プロセスは、ＣＤバンドル記述ファイル（複数可）に関して以下の動作に関与する。
$OASIS_MACHINE_DIR/CD/bundlesの任意の既存のＣＤバンドル記述ファイル（複数可）が削除される。そして、新たな選択されたプロファイルのＣＤバンドル記述ファイル（複数可）が$OASIS_MACHINE_DIR/CD/bundlesに配備される。
【０１１２】
なお、$OASIS_MACHINE_DIRを、$OASIS_INSTALLATION_ROOTをルートとするディレクトリツリー内部の場所に設定してはならないことに留意する。
【０１１３】
監査
オープンアーキテクチャ試験システムのプロファイル監査により、ユーザは、ＣＤＢに格納された所与のプロファイルの内容を検証することができる。一方、オープンアーキテクチャ試験システム監査は、特定の試験システムにおける目下アクティブなソフトウェアコンポーネント及びハードウェアコンポーネントのリスト化を提供する行為を言う。このアクティビティを可能にするために以下の機能が利用できる。
【０１１４】
（プロファイル監査）
これは、テスタ独立プロファイル情報に対し、２つの異なるメカニズムを通して利用可能である。
ＯＣＴｏｏｌアプリケーションは、ＣＤＢに格納された選択されたプロファイルの内容を表示することができる。
所与のプロファイルをデフォルト場所$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>（又はユーザが選択する別の場所）にエクスポートする行為（そのプロファイルの起動を達成することができる前に実行される）により、ファイルOASISVer.cfgが作成される。ファイルの内容は、選択されたプロファイルを完全に記述する。ファイルがプレーンテキストであり、且つ標準Ｗｉｎｄｏｗｓ ＩＮＩファイルフォーマットであるため、情報をスキャンして所望の監査機能を提供することができる。なお、アクティブな配備において、このファイルはまた、$OASIS_ACTIVE_CONFIGSにおいても利用可能となることに留意する。
【０１１５】
（システム監査）
システム監査を、２つの部分、すなわち配備ソフトウェア監査とテスタハードウェア監査とに分割することができる。
【０１１６】
配備ソフトウェア監査
配備ソフトウェア監査は、オープンアーキテクチャ試験システムにおいて満足される以下の要件を通して容易になる。
ターゲットテスタマシンにおけるオープンアーキテクチャ試験システムのソフトウェア配備又は起動のプロセスにより、配備されるソフトウェアコンポーネントの完全な詳細を提供するプレーンテキスト配備ログが作成される。このログは、Deployment.logと命名され、システムコントローラにおいて場所<MAINTENANCE_ROOT>/log/Deploymentで入手可能となる。
【０１１７】
ログファイルがプレーンテキストであるため、その中の情報をスキャンして要求される監査機能を提供することができる。
【０１１８】
テスタハードウェア監査
テスタハードウェア監査は、オープンアーキテクチャ試験システムにおいてＴＯＳによって満足される以下の要件を通して容易になる。
モジュール詳細情報が、ＴＯＳが始動される度にオープンアーキテクチャ試験システムハードウェアインベントリ（ＨＷＩＮＶ）ファイルフォーマットに書き込まれる。これは、システムコントローラにおいて場所<MAINTENANCE_ROOT>/cfgで入手可能となるファイルOASISHW.invに格納される。
【０１１９】
ハードウェアインベントリファイルがプレーンテキストであるため、その中の情報をスキャンすることにより要求される監査機能を提供することができる。
【０１２０】
ソフトウェアパッチリリース
上記新コンポーネントバージョンのインストールセクションにおいて説明したように、インストールパッケージは、コンポーネントの目下リリースされているバージョンを修正し又は強化するようじ意図された個々のコンポーネントを含んでもよい。かかるインストールパッケージが、それが修正するように意図されているリリースのメジャー／マイナーバージョンと互換性がある場合、そのパッケージ（ひいてはそれが関連するリリース）を「パッチ」と呼ぶ。このセクションでは、かかるパッチリリースを提供する際に実行されるステップについて説明する。
【０１２１】
コンポーネントの新たなバージョンがリリースされると、コンポーネントサプライヤ（ＴＯＳ又はベンダ）は、その新たなコンポーネントバージョンのためのＣＣＲを提供する。コンポーネント構成要素のファイル名は、ファイル命名要件セクションで説明したようにコンポーネントの新たなバージョンを反映し、ファイル命名規則に従うことにより、既存のファイルに上書きすることが防止される。このため、コンポーネントファイルバージョンは、アーカイブディレクトリに蓄積し続ける。既存のコンポーネントの新たなバージョンが既存のコンポーネント／ファイルに置き換わらないため、いかなる既存システムプロファイルも実行し続けることができる。
【０１２２】
（パッチリリースの提供）
パッチリリースを提供するステップは以下の通りである。
１．提供者（ＴＯＳサプライヤ、ベンダ又はシステムインテグレータ）は、現リリースを修正し又は強化するように意図されているコンポーネント（複数可）（のセット）を特定し作成する。一例として、OAI_core.dll及びOAI_messages.dllの更新されたバージョンを含むＴＯＳパッチを考慮する。この場合、目下リリースされているバージョンはOAI_core_1.2.9.dll及びOAI_messages_1.2.2.dllである。現リリースに対するＴＯＳリリースＣＣＲをOAI_TOS_1.2.11.ccrであるとする。
２．上記セットの各コンポーネントに、システムのバージョニングされるコンポーネントを特定するmajor.minor.patchトライアドの「patch」フィールドを更新して、名前が割り当てられる。これにより、本明細書の上記例における更新されたコンポーネントを、OAI_core_1.2.10.dll及びOAI_messages_1.2.3.dllと命名してもよい。
３．更新されたバージョン情報を反映して、更新されたコンポーネントの各々に対し新たなパッチＣＣＲが作成される。これにより、本明細書の上記例におけるコンポーネントに対する更新されたＣＣＲは、OAI_core_1.2.10.dll.ccr及びOAI_messages_1.2.3.dll.ccrであってもよい。
４．現リリースに対して使用されている最初のグループＣＣＲに置き換わるために新たなリリースグループＣＣＲが作成される。このＣＣＲは、更新されたコンポーネントに対する新たなＣＣＲ（複数可）のセットに対して更新された参照（本明細書の例では、OAI_core_1.2.10.dll.ccr及びOAI_messages_1.2.3.dll.ccr）を含み、グループの他のすべてのコンポーネントに対する参照は、現リリースに対するものと同じままである。この新たなグループＣＣＲに対しても、検討中のパッケージの集合的な「<version>」リリースを名目的に特定するmajor.minor.patchトライアドにおける「patch」フィールドに対して更新を有する<version>番号が与えられる。このため、本明細書の例では、この新たなリリースグループＣＣＲをOAI_TOS_1.2.11.ccrと命名してもよい。
５．サプライヤは、更新されたコンポーネントと、それらの更新された個々のＣＣＲと、パッケージ全体に対する新たなリリースグループＣＣＲとからなるオープンアーキテクチャ試験システムのアーカイブインストールパッケージを作成する。このパッケージは、特定されたコンポーネントに対する総合パッチとして配信される。
【０１２３】
（パッチリリースの使用）
ユーザ側において、パッチをインストールし、構成し、且つ起動する手続きは以下の通りである。
１．ユーザは、パッチパッケージの内容をオープンアーキテクチャ試験システムインストールアーカイブ場所にインストールする。
２．ユーザは、まず使用するつもりであるプロファイルを呼び戻し、それを、新たなリリースグループＣＣＲ（及び、それにより、更新されたコンポーネントに対する個々のコンポーネントＣＣＲ）を使用するように変更し（又はそれを新たなプロファイルの基礎として使用し）、結果としての変更された（又は新たな）プロファイルを保存することによって、パッチを構成する。
３．最後に、ユーザは、上記変更された（又は新たな）プロファイルを採用して、t2kctrlツールを使用してパッチを起動する。
【０１２４】
（ハードウェアのみの（Hardware-Only）パッチ）
ハードウェアサプライヤは、対応するソフトウェアを更新する必要なく、ハードウェアバージョンを更新する必要がある場合がある。かかる場合、ソフトウェアに対する既存のＣＣＲは、新たなハードウェアバージョンに対する正しい互換性情報を含まない。
【０１２５】
ハードウェアのみのパッチ（ＨＯＰ）とは、ハードウェア／ソフトウェア互換性関係を更新することを目的とする、更新されたＣＣＲのリリースを言う。これらのＣＣＲがデータベースにインポートされると、プロファイルは新たな互換性情報で更新される場合がある。かかるＣＣＲは通常通り作成され、いかなるソフトウェアもなしにパッケージとして配布されてもよい。ユーザがこれらの新たなＣＣＲを受け取ると、新たなＣＣＲを処理するためにパッチをインストールし、構成し、起動する手続きが使用される。
【０１２６】
上記説明では、明確にするために異なる機能ユニット及びプロセッサに関して本発明の実施形態について説明した、ということが理解されよう。しかしながら、本発明から逸脱することなく、異なる機能ユニット又はプロセッサ間の機能の任意の適当な分散を使用してもよい、ということが明らかとなろう。たとえば、別々のプロセッサ又はコントローラによって実行されるように示される機能を、同じプロセッサ又はコントローラによって実行してもよい。このため、特定の機能ユニットについて言及する場合、それは、厳密な論理的又は物理的な構造又は編成を示すのではなく、単に説明した機能を提供するための適当な手段を言及するものとして判断されるべきである。
【産業上の利用可能性】
【０１２７】
本発明を、ハードウェア、ソフトウェア、ファームウェア又はこれらの任意の組合せを含む任意の適当な形態で実施することができる。本発明を任意で、部分的に、１つ又は複数のデータプロセッサ及び／又はデジタル信号プロセッサで実行するコンピュータソフトウェアとして実施してもよい。本発明の実施形態の要素及びコンポーネントを、任意の適当な方法で物理的に、機能的に、且つ論理的に実施してもよい。実際に、機能を、単一ユニットで、複数のユニットで、又は他の機能ユニットの一部として実施してもよい。したがって、本発明を、単一ユニットで実施してもよく、又は異なるユニット及びプロセッサ間で物理的に且つ機能的に分散させてもよい。
【０１２８】
当業者は、依然として同じ基本の根本的なメカニズム及び方法を採用しながら、開示された実施形態の多くのあり得る変更及び組合せを使用してもよい、ということを認識するであろう。上述した記述は、説明の目的のために、特定の実施形態に関して述べたものである。しかしながら、上記例示的な論考は、網羅的であるように、又は本発明を開示した正確な形態に限定するようにも意図されていない。上記教示に鑑みて、多くの変更及び変形が可能である。本発明の原理とその実際的な適用とを説明するように、且つ当業者が、企図される特定の使用に適するよう、本発明及びさまざまな実施形態をさまざまな変更態様で最もよく利用することができるように、実施形態を選択し述べた。
【図面の簡単な説明】
【０１２９】
【図１ａ】本発明の一実施形態によるオープンアーキテクチャ試験システムを示す図である。
【図１ｂ】本発明の一実施形態によるモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法を示す図である。
【図２ａ】本発明の一実施形態によるＴＯＳ制御及び工場出荷時ディレクトリ構造を示す図である。
【図２ｂ】本発明の一実施形態によるオープンアーキテクチャ試験システムの状態図を示す図である。
【図３】本発明の一実施形態によるＴＯＳインストールディレクトリ構造を示す図である。
【図４】本発明の一実施形態によるユーザＳＤＫインストールディレクトリ構造を示す図である。
【図５】本発明の一実施形態によるベンダＳＤＫインストールディレクトリ構造を示す図である。
【図６】本発明の一実施形態によるＴＯＳ配備ディレクトリ構造を示す図である。
【図７】本発明の一実施形態によるユーザＳＤＫ配備ディレクトリ構造を示す図である。
【図８】本発明の一実施形態によるベンダＳＤＫ配備ディレクトリ構造を示す図である。
【特許請求の範囲】
【請求項１】
モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理する方法であって、前記モジュール式試験システムは、少なくとも１つのサイトコントローラを制御するシステムコントローラを備え、該少なくとも１つのサイトコントローラは少なくとも１つのハードウェア試験モジュールを制御し、該方法は、
前記モジュール式試験システムと互換性のある前記ＴＯＳバージョンをアーカイブにインストールすること、
前記ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントを前記アーカイブにインストールすること、
前記ハードウェア試験モジュールバージョン及び前記ＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルを作成すること、
前記モジュール式試験システムに対しシステムプロファイルを選択することであって、該システムプロファイルは、１組の互換性のあるベンダソフトウェアコンポーネントと、特定のハードウェア試験モジュールバージョンを試験する選択されたＴＯＳとを含む、選択すること、及び
前記システムコントローラと前記少なくとも１つのサイトコントローラとにおいて前記選択されたＴＯＳを起動すること
を含む、モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項２】
ベンダソフトウェアコンポーネントをインストールすることは、
前記ＴＯＳバージョンの全般的な制御を実行する試験制御デーモン（ＴＣＤ）をインストールすること、及び
ＴＯＳ制御ディレクトリをインストールすること
を含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項３】
ＴＯＳ制御ディレクトリをインストールすることは、
ＴＣＤコントローラアプリケーションとそれらの関連するダイナミックリンクライブラリとを格納するビンディレクトリをインストールすること、
前記テスタの工場出荷時設定に関連する構成ファイルを格納する構成ディレクトリをインストールすること、
ＴＣＤ及び工場出荷時ドキュメンテーションを格納するドキュメンテーションディレクトリをインストールすること、及び
前記ＴＣＤの動作を格納するインストールログディレクトリをインストールすること
を含む、請求項２に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項４】
前記インストールログディレクトリは、
前記アーカイブにコピーされる各ファイルに対するパスと、
前記アーカイブにコピーされるか又は該アーカイブから除去されるファイルのステータスと、
を含む、請求項３に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項５】
ベンダソフトウェアコンポーネントをインストールすることは、
単一コンポーネント構成レコード（単一ＣＣＲ）をインストールすること、及び
グループコンポーネント構成レコード（グループＣＣＲ）をインストールすること
をさらに含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項６】
前記単一ＣＣＲは、
ソフトウェアコンポーネントのベンダ名と、
該ソフトウェアコンポーネントのベンダ識別子と
を含む、請求項５に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項７】
前記グループＣＣＲは、
該グループＣＣＲによって表される前記コンポーネントのグループの記述と、
前記グループＣＣＲのベンダ名と、
前記グループＣＣＲのベンダ識別子と
を含む、請求項５に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項８】
前記システムプロファイルは、
前記ハードウェア試験モジュールバージョンに特有のソフトウェアコンポーネントと、
ユーザソフトウェア配備キット（ユーザＳＤＫ）と、
ベンダソフトウェア配備キット（ベンダＳＤＫ）と
を含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項９】
前記ハードウェア試験モジュールバージョンに特有の前記ソフトウェアコンポーネントは、
デバイスドライバと、
エミュレーションソフトウェアコンポーネントと、
較正ソフトウェアコンポーネントと、
診断ソフトウェアコンポーネントと
を含む、請求項８に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１０】
前記選択されたＴＯＳを起動することは、
該選択されたＴＯＳを初期化すること、及び
前記モジュール式試験システムの前記システムプロファイルから選択されたソフトウェア構成を配備すること
を含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１１】
前記選択されたＴＯＳを初期化することは、
前記システムコントローラを初期化すること、
前記サイトコントローラを初期化すること、及び
前記モジュール式試験システムのための前記システムプロファイルに従ってユーザアプリケーションを初期化すること
を含む、請求項１０に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１２】
選択されたソフトウェア構成を配備することは、
テスタ独立構成情報をテスタ特有情報と結合することであって、それによってテスタアクティブ構成情報を作成する、結合すること、
所定ディレクトリ場所からソフトウェアコンポーネントを配備すること、及び
前記特定のハードウェア試験モジュールバージョンの前記選択されたソフトウェア構成を用いて前記選択されたＴＯＳを始動すること
を含む、請求項１０に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１３】
新たなベンダソフトウェアコンポーネントバージョンの既存のＴＯＳバージョンとの互換性を検証すること
をさらに含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１４】
複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理するモジュール式試験システムであって、
少なくとも１つのサイトコントローラを制御するシステムコントローラと、
少なくとも１つのハードウェア試験モジュールを制御する少なくとも１つのサイトコントローラと、
前記モジュール式試験システムと互換性のあるテストオペレーティングシステムバージョンと、
前記ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントと、
前記ハードウェア試験モジュールバージョン及び前記ＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルと、
を具備する、複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１５】
ベンダソフトウェアコンポーネントは、
前記ＴＯＳバージョンの全般的な制御を実行する試験制御デーモン（ＴＣＤ）と、
ＴＯＳ制御ディレクトリと
を含む、請求項１４に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１６】
前記ＴＯＳ制御ディレクトリは、
ＴＣＤコントローラアプリケーションとそれらの関連するダイナミックリンクライブラリとを格納するビンディレクトリと、
前記テスタの工場出荷時設定に関連する構成ファイルを格納する構成ディレクトリと、
ＴＣＤ及び工場出荷時ドキュメンテーションを格納するドキュメンテーションディレクトリと、
前記ＴＣＤの動作を格納するインストールログディレクトリと
を含む、請求項１５に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１７】
前記インストールログディレクトリは、
アーカイブにコピーされる各ファイルに対するパスと、
前記アーカイブにコピーされるか又は該アーカイブから除去されるファイルのステータスと、
を含む、請求項１６に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１８】
前記ベンダソフトウェアコンポーネントは、
単一コンポーネント構成レコード（単一ＣＣＲ）と、
グループコンポーネント構成レコード（グループＣＣＲ）と
をさらに含む、請求項１４に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１９】
前記単一ＣＣＲは、
ソフトウェアコンポーネントのベンダ名と、
該ソフトウェアコンポーネントのベンダ識別子と
を含む、請求項１８に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項２０】
前記グループＣＣＲは、
該グループＣＣＲによって表される前記コンポーネントのグループの記述と、
前記グループＣＣＲのベンダ名と、
前記グループＣＣＲのベンダ識別子と
を含む、請求項１８に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項２１】
前記システムプロファイルは、
前記ハードウェア試験モジュールバージョンに特有のソフトウェアコンポーネントと、
ユーザソフトウェア配備キット（ユーザＳＤＫ）と、
ベンダソフトウェア配備キット（ベンダＳＤＫ）と
を含む、請求項１４に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項２２】
前記ハードウェア試験モジュールバージョンに特有の前記ソフトウェアコンポーネントは、
デバイスドライバと、
エミュレーションソフトウェアコンポーネントと、
較正ソフトウェアコンポーネントと、
診断ソフトウェアコンポーネントと
を含む、請求項２１に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１】
モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理する方法であって、前記モジュール式試験システムは、少なくとも１つのサイトコントローラを制御するシステムコントローラを備え、該少なくとも１つのサイトコントローラは少なくとも１つのハードウェア試験モジュールを制御し、該方法は、
前記モジュール式試験システムと互換性のある前記ＴＯＳバージョンをアーカイブにインストールすること、
前記ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントを前記アーカイブにインストールすること、
前記ハードウェア試験モジュールバージョン及び前記ＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルを作成すること、
前記モジュール式試験システムに対しシステムプロファイルを選択することであって、該システムプロファイルは、１組の互換性のあるベンダソフトウェアコンポーネントと、特定のハードウェア試験モジュールバージョンを試験する選択されたＴＯＳとを含む、選択すること、及び
前記システムコントローラと前記少なくとも１つのサイトコントローラとにおいて前記選択されたＴＯＳを起動すること
を含む、モジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項２】
ベンダソフトウェアコンポーネントをインストールすることは、
前記ＴＯＳバージョンの全般的な制御を実行する試験制御デーモン（ＴＣＤ）をインストールすること、及び
ＴＯＳ制御ディレクトリをインストールすること
を含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項３】
ＴＯＳ制御ディレクトリをインストールすることは、
ＴＣＤコントローラアプリケーションとそれらの関連するダイナミックリンクライブラリとを格納するビンディレクトリをインストールすること、
前記テスタの工場出荷時設定に関連する構成ファイルを格納する構成ディレクトリをインストールすること、
ＴＣＤ及び工場出荷時ドキュメンテーションを格納するドキュメンテーションディレクトリをインストールすること、及び
前記ＴＣＤの動作を格納するインストールログディレクトリをインストールすること
を含む、請求項２に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項４】
前記インストールログディレクトリは、
前記アーカイブにコピーされる各ファイルに対するパスと、
前記アーカイブにコピーされるか又は該アーカイブから除去されるファイルのステータスと、
を含む、請求項３に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項５】
ベンダソフトウェアコンポーネントをインストールすることは、
単一コンポーネント構成レコード（単一ＣＣＲ）をインストールすること、及び
グループコンポーネント構成レコード（グループＣＣＲ）をインストールすること
をさらに含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項６】
前記単一ＣＣＲは、
ソフトウェアコンポーネントのベンダ名と、
該ソフトウェアコンポーネントのベンダ識別子と
を含む、請求項５に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項７】
前記グループＣＣＲは、
該グループＣＣＲによって表される前記コンポーネントのグループの記述と、
前記グループＣＣＲのベンダ名と、
前記グループＣＣＲのベンダ識別子と
を含む、請求項５に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項８】
前記システムプロファイルは、
前記ハードウェア試験モジュールバージョンに特有のソフトウェアコンポーネントと、
ユーザソフトウェア配備キット（ユーザＳＤＫ）と、
ベンダソフトウェア配備キット（ベンダＳＤＫ）と
を含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項９】
前記ハードウェア試験モジュールバージョンに特有の前記ソフトウェアコンポーネントは、
デバイスドライバと、
エミュレーションソフトウェアコンポーネントと、
較正ソフトウェアコンポーネントと、
診断ソフトウェアコンポーネントと
を含む、請求項８に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１０】
前記選択されたＴＯＳを起動することは、
該選択されたＴＯＳを初期化すること、及び
前記モジュール式試験システムの前記システムプロファイルから選択されたソフトウェア構成を配備すること
を含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１１】
前記選択されたＴＯＳを初期化することは、
前記システムコントローラを初期化すること、
前記サイトコントローラを初期化すること、及び
前記モジュール式試験システムのための前記システムプロファイルに従ってユーザアプリケーションを初期化すること
を含む、請求項１０に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１２】
選択されたソフトウェア構成を配備することは、
テスタ独立構成情報をテスタ特有情報と結合することであって、それによってテスタアクティブ構成情報を作成する、結合すること、
所定ディレクトリ場所からソフトウェアコンポーネントを配備すること、及び
前記特定のハードウェア試験モジュールバージョンの前記選択されたソフトウェア構成を用いて前記選択されたＴＯＳを始動すること
を含む、請求項１０に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１３】
新たなベンダソフトウェアコンポーネントバージョンの既存のＴＯＳバージョンとの互換性を検証すること
をさらに含む、請求項１に記載のモジュール式試験システムにおいて複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理する方法。
【請求項１４】
複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びテスタオペレーティングシステム（ＴＯＳ）バージョンを管理するモジュール式試験システムであって、
少なくとも１つのサイトコントローラを制御するシステムコントローラと、
少なくとも１つのハードウェア試験モジュールを制御する少なくとも１つのサイトコントローラと、
前記モジュール式試験システムと互換性のあるテストオペレーティングシステムバージョンと、
前記ハードウェア試験モジュールバージョンに対応するベンダソフトウェアコンポーネントと、
前記ハードウェア試験モジュールバージョン及び前記ＴＯＳバージョンに対応するベンダソフトウェアコンポーネントについて記述するシステムプロファイルと、
を具備する、複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１５】
ベンダソフトウェアコンポーネントは、
前記ＴＯＳバージョンの全般的な制御を実行する試験制御デーモン（ＴＣＤ）と、
ＴＯＳ制御ディレクトリと
を含む、請求項１４に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１６】
前記ＴＯＳ制御ディレクトリは、
ＴＣＤコントローラアプリケーションとそれらの関連するダイナミックリンクライブラリとを格納するビンディレクトリと、
前記テスタの工場出荷時設定に関連する構成ファイルを格納する構成ディレクトリと、
ＴＣＤ及び工場出荷時ドキュメンテーションを格納するドキュメンテーションディレクトリと、
前記ＴＣＤの動作を格納するインストールログディレクトリと
を含む、請求項１５に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１７】
前記インストールログディレクトリは、
アーカイブにコピーされる各ファイルに対するパスと、
前記アーカイブにコピーされるか又は該アーカイブから除去されるファイルのステータスと、
を含む、請求項１６に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１８】
前記ベンダソフトウェアコンポーネントは、
単一コンポーネント構成レコード（単一ＣＣＲ）と、
グループコンポーネント構成レコード（グループＣＣＲ）と
をさらに含む、請求項１４に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項１９】
前記単一ＣＣＲは、
ソフトウェアコンポーネントのベンダ名と、
該ソフトウェアコンポーネントのベンダ識別子と
を含む、請求項１８に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項２０】
前記グループＣＣＲは、
該グループＣＣＲによって表される前記コンポーネントのグループの記述と、
前記グループＣＣＲのベンダ名と、
前記グループＣＣＲのベンダ識別子と
を含む、請求項１８に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項２１】
前記システムプロファイルは、
前記ハードウェア試験モジュールバージョンに特有のソフトウェアコンポーネントと、
ユーザソフトウェア配備キット（ユーザＳＤＫ）と、
ベンダソフトウェア配備キット（ベンダＳＤＫ）と
を含む、請求項１４に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【請求項２２】
前記ハードウェア試験モジュールバージョンに特有の前記ソフトウェアコンポーネントは、
デバイスドライバと、
エミュレーションソフトウェアコンポーネントと、
較正ソフトウェアコンポーネントと、
診断ソフトウェアコンポーネントと
を含む、請求項２１に記載の複数のハードウェア試験モジュールバージョン、ソフトウェアコンポーネント及びＴＯＳバージョンを管理するモジュール式試験システム。
【図１ａ】
【図１ｂ】
【図２ａ】
【図２ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１ｂ】
【図２ａ】
【図２ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００９−６４４２５（Ｐ２００９−６４４２５Ａ）
【公開日】平成２１年３月２６日（２００９．３．２６）
【国際特許分類】
【外国語出願】
【出願番号】特願２００８−２０３８１７（Ｐ２００８−２０３８１７）
【出願日】平成２０年８月７日（２００８．８．７）
【分割の表示】特願２００６−５１５５１８（Ｐ２００６−５１５５１８）の分割
【原出願日】平成１７年１２月８日（２００５．１２．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
２．Ｌｉｎｕｘ
【出願人】（３９０００５１７５）株式会社アドバンテスト (1,005)
【Ｆターム（参考）】
【公開日】平成２１年３月２６日（２００９．３．２６）
【国際特許分類】
【出願番号】特願２００８−２０３８１７（Ｐ２００８−２０３８１７）
【出願日】平成２０年８月７日（２００８．８．７）
【分割の表示】特願２００６−５１５５１８（Ｐ２００６−５１５５１８）の分割
【原出願日】平成１７年１２月８日（２００５．１２．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
２．Ｌｉｎｕｘ
【出願人】（３９０００５１７５）株式会社アドバンテスト (1,005)
【Ｆターム（参考）】
[ Back to top ]