TWI383166B - 執行測試儀器模組安裝與組態管理的方法與系統 - Google Patents

執行測試儀器模組安裝與組態管理的方法與系統 Download PDF

Info

Publication number
TWI383166B
TWI383166B TW094142344A TW94142344A TWI383166B TW I383166 B TWI383166 B TW I383166B TW 094142344 A TW094142344 A TW 094142344A TW 94142344 A TW94142344 A TW 94142344A TW I383166 B TWI383166 B TW I383166B
Authority
TW
Taiwan
Prior art keywords
tos
software
vendor
file
configuration
Prior art date
Application number
TW094142344A
Other languages
English (en)
Other versions
TW200638054A (en
Inventor
Ankan Pramanick
Jim Hanrahan
Mark Elston
Toshiaki Adachi
Leon Lee Chen
Original Assignee
Advantest Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advantest Corp filed Critical Advantest Corp
Publication of TW200638054A publication Critical patent/TW200638054A/zh
Application granted granted Critical
Publication of TWI383166B publication Critical patent/TWI383166B/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318314—Tools, e.g. program interfaces, test suite, test bench, simulation hardware, test compiler, test program languages
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31908—Tester set-up, e.g. configuring the tester to the device under test [DUT], down loading test patterns
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Debugging And Monitoring (AREA)

Description

執行測試儀器模組安裝與組態管理的方法與系統
相關申請案的對照：本專利申請案係以2004年12月9日提出之美國專利臨時申請案第60/635,094號「執行測試儀器模組安裝與組態管理的方法與系統(Method and System for Performing Installation and Configuration Management of Tester Instrument Modules)」一案主張優先權，並具有與本專利申請案相同之受讓人，在此引用為參考文件。
本發明係與測試積體電路的領域有關，更特別的，是與執行測試儀器模組安裝與組態管理的方法與系統有關。
測試儀器的價格居高不下的一個主要原因是傳統測試器架構具專屬的特性，每一個測試器製造商都有數個測試器架構，不僅在廠商如愛德萬(Advantest)、泰瑞達(Teradyne)以及安捷倫(Agilent)之間均不相容，同時在廠商內如愛德萬所推出的T3300、T5500、以及T6600系列之間也不相容。由於彼此不相容，每一種測試器需要自己專屬的硬體與軟體組件，而這些專屬的硬體與軟體組件無法用於其他測試器上，此外，將一個測試程式由一個測試器移植至另一個，以及開發協力廠商解決方案，需要花很大的功夫，即使協力廠商解決方案是為一個平台所開發，它也不能移植或重新使用在另一平台上，而從一個平台轉譯至另一平台的流程通常很複雜也容易出錯，必須付出更多的努力、時間，也使得測試成本增加。
專屬測試器架構的另一個問題是對一個給定的測試器來說，其所有的硬體與軟體均為固定的組態，為了測試一受測裝置(DUT)或IC，必須開發專用的測試程式，採用部份或全埠的測試器功能來定義測試資料、訊號、波型，以及電流和電壓位準，還有收集DUT回應，決定一個DUT是否通過或沒有通過測試。
開放架構測試系統對傳統測試系統發生的上述問題提供了一種解決方案，美國申請案10/772,434「開發用於半導體積體電路的測試程式之方法與結構(Method and Structure to Develop a Test Program for Semicondutor Integrated Circuits)」提出了一個開放架構測試系統的範例，在此並引用為參考文件。開放架構測試系統可被設定以支援廣泛的廠商硬體測試模組與它們對應的DUT。
不過，在實施這種開放架構測試系統時會碰到的一個挑戰，是可能會有多個測試器作業系統(TOS)的版本，此外，每一個廠商硬體測試模組可能具有多個版本，而每個版本可能具有其對應的軟體組件版本，測試器作業系統、廠商硬體測試模組、以及軟體組件的版本必須緊密地配合，以便在廠商硬體測試模組上執行測試。因此，有必要提出一種模組式測試系統，能夠管理多個廠商硬體測試模組版本、軟體組件版本、以及TOS版本，用以採用廣泛的廠商硬體測試模組來測試DUT。
在一個實施例中，一種用以管理一模組式測試系統內的多個硬體測試模組版本、軟體組件、以及測試器作業系統(TOS)版本的方法，包括於一檔案庫中安裝與該模組式測試系統相容之該等TOS版本；於該檔案庫中安裝對應至該等硬體測試模組版本之廠商軟體組件；該方法進一步包括建立系統設定檔，用以描述對應至該等硬體測試模組版本之廠商軟體組件與該等TOS版本；選擇一用於該模組式測試系統的系統設定檔，其中該系統設定檔包括一組相容的廠商軟體組件與一用以測試一特定硬體測試模組版本之被選擇的TOS；並啟動在該系統控制器上之該被選擇的TOS與該至少一現場控制器。
在另一實施例中，一種用以管理多個硬體測試模組版本、軟體組件、以及測試器作業系統(TOS)版本的系統，包括一系統控制器，用以控制至少一個現場控制器；至少一個現場控制器，用以控制至少一個硬體測試模組；與該模組式測試系統相容之測試作業系統版本；對應至該等硬體測試模組版本之廠商軟體組件；以及一系統設定檔，用以描述對應至該等硬體測試模組版本之廠商軟體組件與該等TOS版本。
本發明提出的方法與系統係用以執行測試器儀器模組(tester instrument module)的安裝與組態管理。以下的敘述可使得熟悉此技藝者運用本發明，特定實施例與應用係被提供作為範例，對熟悉此技藝者來說，各種範例的修正與組合將會顯而易見，而在此所述的基本原則也可應用至其他範例與應用，而不悖離本發明的精神與範疇，因此，本發明並不限於在此所示的範例，而是根據在此所述的原則與特點的最寬廣範圍而定。
第1a圖所示為根據本發明的一個實施例之開放架構測試系統，如第1a圖所示，系統控制器(SysC)102係耦接至多個現場控制器(SiteCs)104。系統控制器也可被耦接至網路以存取檔案，每個現場控制器透過模組連線致能器(module connection enabler)106以耦接控制位於測試現場110的一或更多個測試模組108。模組連線致能器106允許重新設定連線的硬體模組108，同時也作為資料傳輸的匯流排(用於載入樣式資料、收集回應資料、提供控制等)。可能的硬體實施方式包括專屬連線、交換器連線、匯流排連線、環狀連線、以及星形連線等。模組連線致能器106也可以，舉例來說，以交換器矩陣來實施。每一個測試現場110係與一受測裝置(DUT)112相關，DUT則是透過負載板(loadboard)114連接至對應現場的模組。在一實施例中，單一現場控制器可連接至多個DUT現場。
系統控制器102擔任整體系統管理者的角色。它協調現場控制器活動、管理系統層級平行測試策略，以及額外地提供處置器(handler)/探針(probe)控制，還有系統層級資料記錄與錯誤處理支援。系統控制器102視操作設定，可被佈署在獨立於現場控制器104的操作設定之一顆中央處理單元(CPU)上。另外，一個通用的CPU可被系統控制器102與現場控制器104所分享。同樣地，每一個現場控制器104可被佈署在它自己專屬的CPU上，或者在同一CPU內的個別程序或穿線(thread)。
系統架構在概念上可視為第1a圖所示的分散式系統，而個別的系統組件可被視為整合的、單石系統的邏輯組件，並不一定要是分散式系統的實體組件。
第1b圖所示為一種用以管理一模組式測試系統內的多個硬體測試模組版本、軟體組件、以及TOS版本的方法。TOS的多個版本與其相關的使用者與廠商SDK版本，還有廠商驅動程式(Vendor Driver)軟體的多個版本，係被儲存於檔案庫(archive)內。安裝與組態管理(Installation and Configuration Management,ICM)系統的開放架構測試系統之目的是讓廠商開發驅動程式軟體組件，以支援它們的硬體模組，並允許使用者在一測試器或開發平台上，選擇相容的廠商驅動程式軟體以及TOS版本。ICM系統同樣會管理在測試器或開發平台上安裝這些被選擇的組態，以及，選擇性地，啟動被選擇的組態。
ICM系統描述了管理開放架構測試系統的TOS之要求與涉及的活動。用於開放架構測試系統之ICM有下列4種基本活動：1.安裝(Installation)係指複製開放架構測試系統組件到檔案庫的動作，用於後續的啟動或佈署。
2.組態設定(Configuration)係指讓使用者與ICM系統互動以建立、儲存和修改軟體組態，作為系統設定檔的動作，其中系統設定檔係用於啟動。
3.啟動(Activation)係指在一特殊測試器上讓被選擇的軟體組態(也就是一個設定檔)成為作動的，也就是佈署它的動作。
4.稽核(Audit)係指在一特定測試系統上提供目前作動的軟體與硬體的清單之動作。
本文件提供每一種活動的規格說明。在底下的討論中，分別以SW以及HW來代表軟體與硬體。
要注意的是，安裝與組態設定為ICM特有的活動(概念上可在一特定測試器的遠端被執行)，啟動與稽核則為測試器特有，而且需要某些開放架構測試系統的TOS組件，基本上是開放架構測試系統的測試器控制精靈(TCD)之配合。因此，本文件中也描述了TCD的各個方面，以及涉及ICM活動的TOS，還有TCD本身的安裝。後續的測試器控制與TOS開始的章節首先提供開放架構測試器控制與TOS系統開始步驟。
同樣要注意的是，發布開放架構測試系統軟體「修正程式(patch)」是在推出較完整的軟體版本之間，用以修正與強化開放架構測試系統軟體組件所不可或缺的部分，在後續的軟體修正程式發布的章節中將提供有關建立、發送、以及使用開放架構測試系統軟體修正程式發布的方法。
測試器控制與TOS開始(Tester Control and TOS Startup)
在這一章節中，我們描述開放架構測試器控制與開始步驟，在此假設讀者熟悉開放架構測試器架構的基礎，特別是組織TOS為包含開放架構測試系統的系統控制器(System Controller,SysC)和現場控制器(Site Controller)(SiteC)的通用分散式系統。
測試器控制精靈(Tester Control Daemon)
開放架構測試系統的TOS的一般控制是由開放架構測試系統的測試器控制精靈(TCD)所執行，TCD的規格如下所述：開放架構測試系統的測試器控制精靈(TCD)負責以下功能：．在系統開機(boot－up)時，開始與啟始開放架構測試系統的TOS，或者在成功的系統啟始後，根據使用者命令以及選擇性開始使用者定義的開放架構測試系統應用程式。
．根據使用者命令，關閉開放架構測試系統的TOS，包括關閉任何連接至TOS核心服務的開放架構測試系統應用程式。
．啟動或佈署一用於開放架構測試系統的特殊軟體組態，如系統設定檔所定義，其中「切換版本(version switch)」實際上是啟動除了目前在實行中的設定檔以外的設定檔。
用於開放架構測試系統軟體組態的系統設定檔如下所述，其為所有需要用來定義一特殊開放架構測試系統軟體組態的資訊的總和，在以下的討論中，測試器控制精靈(TCD)係用於視窗(Windows)作業系統(OS)，而其概念實際上是通用且可應用在任何開放架構測試系統上的。
在Windows系統中的TCD為一個Win32服務(可以在「服務」對話框的已安裝服務清單中看到，可利用Windows的控制台尋找)，其已被安裝並自動在SysC以及所有的SiteCs上執行，它是一個COM組件，提供介面(在系統控制器端)以執行上述功能，它被和開放架構測試系統軟體分開安裝(線上版本是由系統整合者在出廠時安裝)，並被註冊於Windows服務控制管理員，以便在OS開機時自動開始，要注意的是「主要」TCD是在系統控制器上執行的那一個，而輔助的TCD則是在現場控制器上執行，並且負責在主要TCD的主導下啟動個別的現場控制器。
TOS控制與工廠預設目錄
為了讓精靈能被安裝與正確地工作，每一個開放架構測試系統皆以一個標準目錄結構預先組態，用以容納TOS控制組件與工廠預設資訊，如以下規格所述：每一個開放架構測試系統的系統控制器與現場控制器係被設定為具有一TOS控制與工廠預設目錄結構，其根目錄於<MAINTENANCE_ROOT >，如第2a圖的結構所示，並敘述於表1。
安裝於<MAINTENANCE_ROOT>/bin的TCD控制器應用程式係簡單的命令行應用程式，其可傳送基本的測試器系統控制命令，像是「開始(start)」、「停止(stop)」、「啟動(activate)」等給TCD，Advantest T2000系統提供t2kctrl應用程式以執行這些任務。
在<MAINTENANCE_ROOT>/cfg目錄的內容視不同的系統整合者而定，在每一種情況下，它包括對應測試器資訊的TCD或其安裝程式所需的測試器資訊，舉例來說，Advantest T2000測試器系統把以下的資訊放在<SystemDrive>：/T2000Maintenance/cfg。要注意的是<SystemDrive>是由Windows預先定義的環境變數，在Windows 2000上為「C：」。
□ 現場控制器的工廠組態(採用標準的Windows INI檔案格式)，其標示內部系統IP名稱與工廠所提供的所有現場控制器位址，加上任何特殊的開放架構測試系統使用者帳號與密碼資訊，可讓開放架構測試系統軟體啟動程序執行其工作，這個檔案被命名為OASISSiteInfo.ini。
□ 使用者在線上系統上或許不能修改檔案，對於離線系統來說，使用者若有需要可修改預設值(在與SysC同一機器上標示單一SiteC)。對於同時使用線上和離線的系統，線上模式需要使用原始線上工廠組態檔案(或者最近被工廠授權技術人員更新過，以反映硬體佈局的變動)。
□ 工廠預設規格(FDEF)檔案包含以下的資訊：．整體測試器內容，像是類型、名稱、操作頻率等；．工廠設定的硬體模組與它們的機板特有細節；．硬體模組連接的工廠設定的開放架構測試系統模組連線致能器(MCE)埠；．連接至每一硬體模組(若有的話)的開放架構測試系統同步化矩陣連線；以及．用於硬體模組的測試頭連線。
使用者在線上系統上或許不能修改檔案，可能只有可變動機器的實體組態之授權維護人員能夠進行修改。對於離線系統來說，工廠預設規格檔案定義了與測試範例，如果有的話，相容的虛擬機器組態，使用者若有需要可修改它，以設定自己的虛擬測試器，對於一個同時使用線上與離線模式的系統來說，線上模式需要使用原始線上工廠組態檔案(或者最近被工廠授權技術人員更新過，以反映硬體佈局的變動)。
測試器狀態與狀態遷移
如上所述，TCD負責開始開放架構測試系統的TOS，為了解TOS啟動的機制，有必要先了解TOS可處於那些狀態，還有其中可行的遷移，第二B圖所示為開放架構測試器之狀態遷移圖表。
第2b圖所示的狀態的意義如下：狀態0：測試器系統閒置：在系統控制器上的TCD並沒有在執行，而TOS也沒有在執行。
狀態1：TCD至少在系統控制器上執行；不過TOS尚未作用。
狀態2：開放架構測試系統的系統控制器程序正在執行，但還沒有被啟始；TCD可能有或沒有在所有現場控制器上執行；在離線模式中，開放架構測試系統的測試器仿真器(emulator)程序尚未執行。
狀態3’：(僅離線模式)開放架構測試系統的測試器仿真器係於(單一標示的)現場控制器電腦上執行。
狀態3：至少現場控制器一(SITEC－1)已被成功地啟始，而系統係位於預設分割(default partitioned)狀態(也就是所有的硬體模組皆透過MCE連接至SITEC－1)；此外，所有標示的現場控制器也可被成功地啟始，在此時，系統為待命(ready)，也就是被設定為接受測試計畫載入要求(test plan load request)。
狀態4：一使用者測試計畫已被成功地載入一或更多個相容的現場控制器，作為狀態4的一部分，系統也許已被(重新)分割以容納測試計畫要求。
以下敘述第2b圖中造成狀態遷移的事件，其中「t(x,y) 」代表從狀態x遷移至狀態y(要注意的是以下討論所指的用戶端(client)是系統控制器TCD的用戶端，而且可以是任何應用程式，遠端或本地，其連接與使用TCD上的適當介面)：t (0,0)：在接收到Windows開機程序的指令(或者是互動式、手動「開始」要求)時，Windows服務控制管理員在Windows開機時未能啟動系統控制器上的TCD。
t (0,1)：在接收到Windows開機程序的指令(或者是互動式、手動「開始」要求)時，Windows服務控制管理員成功地在Windows開機時啟動系統控制器上的TCD，可能在現場控制器上。
t (1,1)：在收到用戶端「啟動」TOS的命令時，系統控制器上的TCD未能啟動TOS系統控制器程序。
t (1,2)：在收到用戶端「啟動」TOS的命令時，系統控制器上的TCD成功地啟動TOS系統控制器程序。
t (2,2)：在用戶端「啟動」TOS的命令的一部份，TOS系統控制器程序啟始化失敗，也就是，它無法在離線模式中，啟動開放架構測試系統的測試器仿真器程序，或者至少在SITEC－1上，無法開始與啟始TOS現場控制器程序。
t (2,3’)：(僅離線模式)在用戶端「啟動」TOS的命令中的一部份，TOS系統控制器程序成功地在(單一標示的)現場控制器電腦上啟動開放架構測試系統的仿真器程序。
t (3’,3)＊ ：(僅離線模式)在用戶端「啟動」TOS的命令中的一部份，TOS系統控制器程序成功地開始與啟始用於至少SITEC－1(也有可能是所有標示的現場控制器)的TOS現場控制器程序。
t (3’,2)：(僅離線模式)在用戶端「啟動」TOS的命令中的一部份，TOS系統控制器程序未能成功地開始與啟始用於至少SITEC－1的TOS現場控制器程序(仿真器程序被終止)。
t (2,3)＊ ：(僅線上模式)在用戶端「啟動」TOS的命令中的一部份，TOS系統控制器程序成功地開始與啟始用於至少SITEC－1(也有可能是所有標示的現場控制器)的TOS現場控制器程序。
t (3,3)：在收到使用者命令以載入使用者測試計畫時，TOS未能載入所標示的測試計畫。
t (3,4)：在收到使用者命令以載入測試計畫時，TOS根據被標示的測試計畫有關的套接層(socket)之要求，成功地(重新)分割系統後，成功地在標示的現場控制器上載入所標示的測試計畫。
t (4,4)：在收到使用者命令以(重新)載入(相同或不同的)測試計畫時，TOS根據被標示的測試計畫有關的套接層之要求，成功地(重新)分割系統後，成功地在標示的現場控制器上(重新)載入測試計畫。
t (3,1)：在收到用戶端命令以「關閉」TOS時，TCD停止TOS。
t (4,1)：在收到用戶端命令以「關閉」TOS時，TCD停止任何執行中的測試計畫，然後停止TOS。
要注意的是＊ 代表遷移伴隨著TOS系統控制器程序試著去啟動使用者特有的應用程式；啟動任何或所有應用程式失敗並不會讓成功的TOS啟始化失敗，因為應用程式並不屬於TOS的一部分。
除了上述的遷移外，在系統控制器上執行Windows的關機命令(或對系統實際斷電)會重設測試器回到狀態0，而不管當時測試器的狀態為何。
TOS啟動程序
開放架構測試系統的TOS被啟動的程序如下所示(在此假設環境變數OASIS_INSTALLATION_ROOT、OASIS_ACTIVE_CONFIGS、OASIS_TOS_SETUP_FILE、OASIS_TPL_SETIP_FILE、OASIS_TOOLS_SETUP_FILE、OASIS_MACHINE_DIR、以及OASIS_TEMP已經都被正確地定義，而系統設定檔已被選定)：1.在系統電源打開(或開機)時，Windows服務控制管理員啟動系統與現場控制器上的TCD。
2.系統控制器上的TCD證實系統設定檔在實行中，讀取現場控制器上的設定檔特有組態，也就是在$ OASIS_ACTIVE_CONFIGS/OASISSYs.cfg的檔案，並啟動TOS系統控制器程序。
3.接著TCD呼叫TOS系統控制器程序上的一個initialize( )方法，造成a.只有在操作模式為離線的情況下，測試器仿真器程序在(單一標示的)現場控制器電腦上被啟動；b.在每一個現場控制器上的TCD被要求啟動其TOS現場控制器程序；c.在每一個TOS現場控制器程序上呼叫initialize( )方法；以及d.在至少SITEC－1被成功地啟始後，系統被預設分割(也就是所有的硬體模組皆透過MCE連接至SITEC－1)。
4.接著TCD試著以被標示的次序啟動在現行作動中設定檔所列，需自動啟動的任何使用者應用。
在步驟1－3任一個發生失敗會導致上述對應的系統狀態遷移，在步驟1或2所發生的失敗被記錄於Windows 事件記錄，在步驟3所發生的失敗被記錄於TOS系統控制器程序，並且讓後續任何連接的用戶端應用程式都可以取得。
選擇性自動啟動應用程式
如上所述，開放架構測試系統讓使用者可選擇加入應用程式，在TOS啟動成功後可被自動地啟動，OCTool讓使用者可選擇應用程式，作為系統設定檔的一部分，當此類設定檔在一特殊測試器上被啟動時(也就是設定檔所標示的組態為現行的組態)，上述的步驟4則在TOS被成功地啟始完成後會被執行。
為此，TCD讀取檔案OASISVer.cfg的啟動(Startup)章節，其為標示所選系統設定檔的屬性之資料檔案，並採用標準的Windows INI檔案格式，它處理在該章節中的每一行作為命令行，以開啟新應用程式。如果開啟任何或所有被列出的應用程式的工作失敗並不會對於TOS啟動造成錯誤情況，因為應用程式並非TOS的一部分。不過，所有此類失敗都會被提出與儲存(以便後續讓應用程式取得)於TOS系統控制器程序中。
安裝
開放架構測試系統的安裝包含安裝3種主要組件，每一個需獨立安裝：1.開放架構測試系統的測試器控制精靈(TCD，其中包含開放架構測試系統軟體啟動或佈署的功能)。
2.開放架構測試系統的組態設定工具(OCTool)。
3.開放架構測試系統的系統軟體。
在此章節中，將分別敘述這些組件的安裝程序。
安裝TCD
開放架構測試系統的TCD套件係與任何其他開放架構測試系統組件分開安裝。對於剛出廠的線上系統而言，TCD套件一般可被預先安裝。對於離線系統或需要更新的TCD來說，安裝程式可由系統整合者提供。
在Windows中，開放架構測試系統<MAINTENANCE_ROOT>自然轉譯至Windows<SystemDrive>(一般是“C：”磁碟機)的一目錄，因為<SystemDrive>一定會存在，舉例來說，開放架構測試系統的Advantest T2000把根目錄放在系統與現場控制器的“C：/T2000Maintenance”目錄下。在以下的討論中，假設<SystemDrive>為“C：”，安裝TCD套件的過程中所產生的步驟如下：1.如上所述，<MAINTENANCE_ROOT>存在於SysC以及SiteCs，因為有些組件被安裝於<MAINTENANCE ROOT>。
a.如果<MAINTENANCE_ROOT>不存在，則TCD安裝程式會建立它。
b.如果現場控制器工廠組態檔案(在Advantest T2000系統內的C：/T2000Maintenance/cfg/OASISSitemfo.ini)不存在，安裝程式也會根據安裝者的輸入建立它
c.如果開放架構測試系統工廠設定規格(FDEF)檔案(在Advantest T2000系統內的C：/T2000Maintenance/cfg/OASISHW.def)存在，i.對於線上系統來說，無論如何它都不會被更換或更改；ii.對於離線系統來說，預先包裝的版本，名為<FDEF－name>.<example>，係用以模型化與開放架構測試系統所提供的範例相容之虛擬測試器，被複製於<MAINTENANCE_ROOT>/cfg，而使用者會被提醒用這個檔案替代現有的FDEF檔案(如果他想要採用這個開放架構測試系統範例)。
d.如果FDEF檔案不存在，i.對於線上系統來說，會安裝一個範例的FDEF檔，而使用者會被警告需將其更新以與他安裝的硬體相容；ii.對於離線系統來說，此一檔案的預先包裝版本會被安裝為FDEF檔案(並採用開放架構測試系統所要求的標準名稱)。file(with the standard name as required by the open architecture test system)
2.安裝程式安裝TCD二進位檔於<SystemRoot>/system32，並在Windows登錄檔內註冊任何所需的COM組件。
3.安裝程式為TCD設定以下的組態內容：a.自動啟動(AutoStart)：此為標示Windows系統開機是否造成SysC TCD自動啟動開放架構測試系統的TOS(真)或否(假)，預設為真，不過安裝者若有需要可設定為假。
b.模式：此為標示TOS應該在線上(如果可行的話)或離線操作模式下被啟動，預設為線上，不過安裝者若有需要可設定為離線。
c.組態：此為標示TOS應該以除錯(DEBUG)或發布(RELEASE)的組件版本啟動，預設為RELEASE，不過安裝者若有需要可設定為DEBUG。
4.安裝程式安裝TCD控制器應用程式(t2kctr8 )，以及其相關的DLL於<MAINTENANCE ROOT>/bin。
5.對於開放架構測試系統所要求的每一個作業系統環境變數來說，安裝程式(i)決定它是否已被設定，以及(ii)若否，則將它設為使用者標示數值：a. OASIS_INSTALLATION_ROOT b. OASIS_ACTIVE_CONFIGS c. OASIS_MACHINE_DIR d. OASIS_TEMP
6.安裝程式把<MAINTENANCE_ROOT>/bin以及$OASISJNSTALLATION_ROOT/bin增加至Windows系統的PATH環境變數(假設對於Windows慣例來說，<SystemRoot/system32>已經位於系統的PATH環境變數中)。
要注意的是，如上述步驟1.d.ii所述，TCD與DLL係安裝於Windows的<SystemRoot>/system32目錄(其為<SystemDrive>/WINNT/system32，在Windows 2000中最常見為C：/WINNT/system32)，因為這個位置可確保Windows服務會正確地操作，此外，<MAINTENANCE_ROOT>也需要在系統與現場控制器上使得系統能夠正確地工作，因此，如果有人想要重新格式化存在這些組件的本地磁碟機時，<MAINTENANCE_ROOT>(以及在<SystemRoot>/system32內的TCD與其相關的DLL)應被小心地備份與恢復，在開放架構測試器上啟動任何系統設定檔需要TCD已被安裝並且在測試器上可用，由於TCD實際上是獨立於開放架構測試系統軟體，因此它必須可回溯相容所有發布過的開放架構測試系統軟體。
安裝OCTool
開放架構測試系統組態設定工具OCTool，是被分送並安裝於與開放架構測試系統軟體不同的套件中。
OCTool的安裝程式讓使用者可選擇OCTool的安裝位置。OCTool讓使用者可建立與儲存開放架構測試系統的系統設定檔，而設定檔是與測試器無關。因此，概念上使用者可以把它安裝在任何特定測試器的遠端，只要它能夠存取開放架構測試系統軟體被安裝的檔案庫位置。不過，需要小心別把它安裝在位於$OASIS_NSTALLATION_ROOT之目錄樹的位置中，其為現行作動的系統的根目錄，因為如果啟動了對應至另一個設定檔的系統，就有可能會被遺失。
由於OCTool和TCD一樣，實際上是獨立於開放架構測試系統軟體，因此它必須可回溯相容所有發布過的開放架構測試系統軟體。
安裝開放架構測試系統軟體
安裝開放架構測試系統軟體係指實體地複製開放架構測試系統軟體組件(也就是檔案)至作業系統環境變數OASIS_ARCHIVE ROOT所定義的位置，以下將稱之為檔案庫(archive)，檔案庫包含開放架構測試系統與系統整合者提供給系統使用者的檔案，要注意的是它有別於部署或執行時間(runtime)的位置，檔案庫位置可實體地位於測試器系統的遠端，只要能被軟體所在的測試器系統上之TCD存取即可，這點和部署位置不同。
安裝過程與安裝TOS以及廠商組件一樣。每個被安裝檔案具有一個組件組態記錄(Component Configuration－Record,CCR)，其標示組件的特性。因此，以下2個要求概括了安裝程序的規格：□ 開放架構測試系統軟體安裝過程會複製檔案進一個被定義的檔案庫位置，這個位址係由環境變數OASIS_ARCHIVE ROOT所定義。
□ 每一個安裝至檔案庫的檔案係附帶一個組件組態記錄(CCR)，其包含檔案所要求的描述資訊。
因此，TOS與廠商檔案係位於同一根目錄，為了要透過系統設定檔來管理這些檔案，所以它們必須遵循開放架構測試系統檔案命名要求，藉著遵循這些要求，在系統上的檔案可被累積在單一檔案庫目錄以便管理，這可適用於TOS與廠商的被安裝檔案，而以下將討論這些要求。
檔案命名要求
為了能夠管理、切換與稽核版本，每一個被安裝於開放架構測試系統內的元件(檔案)需採用以下的檔案命名格式，用以避免與其他來自同一或不同廠商的被安裝元件有名稱衝突的可能。
□ TOS與廠商組件採用以下命名格式：VendorID_ComponentName_[D_]VersionIdentifier[.ext]
有關格式的敘述如下，其中方括號([ ])中的元件代表選擇性的項目：1. VendorID：2或3個字幕的廠商識別碼，用以識別組件為TOS或廠商特有組件，用以清楚劃分檔案，要注意的是每一個廠商需自行管理它引進系統的檔案，第一個字元應是字母或數字，不可以是劃底線的字元，TOS執行時間組件採用"OAI"作為識別碼，VendorID部分之後會跟著一個底線字元'＿'。
2. ComponentName：任意名稱，由組件供應者選擇，ComponentName部分之後會跟著一個底線字元'＿'。
3. D：這是選擇性的項目，並可用於可執行組件，對此類組件來說，如果組件代表一除錯動態聯結程式庫(DLL)或可執行組件，ComponentName之後會跟著一個'D'，如果沒有'D'的話，隱含著組件為非除錯版本(也就是一個「發布」版本)的意義，如果'D'存在的話，其後會跟著一個底線字元'＿'。
4. Versionldentifier：對所有引入系統中的檔案標註版本為基本要求。為了能夠在不同的作業系統上能夠相容，標註版本的欄位Versionldentifier成為檔名的一部分。這個欄位具有以下的格式：主要、次要、修正(major.minor.patch)其中每一個主要、次要、修正皆為非負數整數值，代表組件的主要、次要與修正版本。
5. ext：延伸檔名(Extension)為選擇性的OS特有識別方式，比如.dll、.exe、.txt、.doc等。
要注意的是，在所有情況下，檔名在所有支援平台(像是Windows、Linux)上皆為合法的，以下列舉一些例子：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的目錄結構如第3圖、第4圖、以及第5圖所示，並於表2中進一步描述，在以下的討論中，軟體開發套件通常以縮寫SDK表示，同時，"$foo"所指為作業系統環境變數foo的數值，安裝程序符合以下情形：□ 所有開放架構測試系統軟體組件檔案係安裝於$OASIS_ARCHIVEJROOT下的合適位置，如第3圖、第4圖、以及第5圖所示，並於表2中描述。
□ 安裝(即檔案庫)位置可自使用者想要啟動TOS的測試系統上存取。
在第3圖、第4圖、以及第5圖中，名為OAI的目錄包含開放架構測試系統的TOS檔案，而名為<vendor>的目錄包含廠商特有檔案，每一個廠商具有它自己的目錄，<vendor>代表一個獨特的2到3個字元的識別碼(例如Advantest廠商目錄被標示為AT)，要注意的是在每個廠商特有目錄下，廠商係負責確定它們的檔名是唯一的，同樣要注意的是，檔名具明確版本識別碼可以讓不同版本的相同組件被儲存在同一位置。
表2進一步描述在上述圖表中的目錄結構，其中在第一行中的每一個目錄係與$OASIS_ARCHIVE_ROOT有關。
安裝記錄檔
目錄記錄檔(directory log)包含子目錄安裝程式，這個位置支援以下的規格：□ 開放架構測試系統軟體的安裝程式在以下熟知的位置建立安裝記錄檔，也就是$OASIS_ARCHIVE_ROOT/logs/Installer。
TOS安裝記錄檔的命名慣例為OAI_<version>.log，廠商安裝程式採用<vendor>_<version>.log的命名慣例。以下為2個進一步的要求：□ 安裝記錄檔為純文字檔案，清楚地顯示出每一個檔案複製至檔案庫的完全合法路徑。
□ 如果有個安裝程式被執行多次以增加或移除組件，安裝記錄檔會被更新以顯示被複製至或自檔案庫被移除的檔案現行狀態。
安裝新組件版本
當組件的新版本被發布時，組件供應者(TOS或廠商)會提供用於新組件版本的CCR。組件成份的檔名反映組件的新版本，如同在檔名要求一節中所述；遵循檔名命名規則可預防現行檔案被覆蓋。因此，組件檔案版本可繼續在檔案庫目錄內累積。
要注意的是，安裝套件(由以下所述的發布群組(release group)CCR之一，或用於直接廠商發布的任何廠商提供發布CCR來表示)可包含用來修補或加強現行已發布版本的個別組件。由於現行組件的新版本不會取代現行組件/檔案，任何預先存在的系統設定檔仍可繼續執行，請注意以下用於組件的修正程式：當新的修正程式問世時(可藉由改變major.minor.patch三重版本識別碼的修正程式組件來表示)，它會與TOS發布的主要/次要(major/minor)版本相容。
在描述過發布群組CCR以及使用者的系統設定檔案後將描述提供此種修正程式的詳細機制。
組態設定
組態設定係指讓使用者與ICM系統互動以建立、儲存和修改軟體組態，作為系統設定檔的動作，其中系統設定檔係用於後續啟動特定測試器系統的特殊組態。本節中描述ICM所提供、用以執行功能的機制。
組件與組態記錄
在一開放架構測試系統中，組件是一或多個檔案、環境設定等，用以表示系統中的不同模組。一個重要的系統組件種類為系統硬體模組的軟體表示法，可視為主要組件，另一個組件的種類，舉例來說，是用於SDK的介面定義檔案。
單一組件CCR(Single Component CCRs)
如上所述，每一個被安裝在檔案庫的開放架構測試系統軟體組件檔案係附有組件組態記錄(CCR)，用以標示檔案的特性。因此，在組態控制下的TOS或廠商檔案在被安裝至檔案庫時，會與CCR相關，CCR係安裝於檔案庫的檔案之描述，其中包含有關檔案的資訊，其版本號碼、相關組件、其依存性、其不相容性等，CCR係作為OCTool的輸入，讓使用者可觀看、控制、追蹤與管理所有安裝在測試系統的組件。除了必須加上強制的額外延伸檔名.ccr以外，CCR的命名要求與其描述的對應系統檔案相容，因此，檔案AT_PinModule_0.5.1.dll的CCR係命名為AT_PinModule_0.5.1.dll.ccr，要注意的是，被安裝的CCR會被原封不動的保存，作為安裝的原始參考。放在<OASIS_ARCHIVE_ROOT>/InstallCCRs內，CCR檔案被放置在和組態檔案(組態檔案被儲存位置與檔案庫目錄有關)相同的目錄位置，不過與InstallCCR目錄有關。
群組CCR(Group CCRs)
CCR可以用群組方式表示，用以參考一個以上的CCR，實際上，這是CCR被用於系統的主要方法，因為它們通常映對至產品發布套件，若有需要，使用者也可選擇整個CCR群組，用以納入設定檔中。
對於安裝開放架構測試系統來說，有一些重要、必須的群組CCR，除了用於每個被安裝的開放架構測試系統軟體組態檔案的CCR外，以下的發布群組CCR也是必須的：□ 開放架構測試系統的TOS發布CCR，由TOS供應商/系統整合者提供；□ 開放架構測試系統的UserSDK發布CCR，由系統整合者或UserSDK供應商提供；□ 開放架構測試系統的VendorSDK發布CCR，由系統整合者或VendorSDK供應商提供。
群組CCR採用以下的群組/檔案命名格式：□ VendorID_GroupType[_UserGivenName]_VersionIdentifier.gccr□ UserGivenName為非必須的。
TOS發布CCR，名為OAI_TOS_<version>.gccr，是一群組CCR，用以描述開放架構測試系統TOS執行時間的所有發布的內容，標稱為"<version>"發布，要注意的是<version>為Versionldentifier，如上述所定義，它包含對所有個別組件CCR的參考，而所有個別組件CCR的總和定義了開放架構測試系統TOS執行時間的"<version>"發布，此一CCR的類型為”TOS”。
同樣地，UserSDK與VendorSDK發布CCR－－分別為OAI_USER_SDK_<version>.ccr以及OAI_VENDOR_SDK_<version>.gccr－－為描述開放架構測試系統使用者與廠商SDK的所有發布的內容之群組CCR，其分別屬於"USER_SDK"與"VENDOR_SDK"類型。
除了上述必須的群組CCR，硬體模組廠商可選擇提供群組CCR以控制相關組件的發布，這些群組CCR屬於"VENDOR"、"USER"、以及"TOOLS"等類型。
單一組件CCR內的資訊
如稍早所述，開放架構測試系統的一個主要組件為硬體模組的軟體表示法，CCR的資訊內容係被導向以標示所有需要用來支援此類主要組件的屬性，而這類主要組件為所有組件種類中最複雜的，此種屬性通常對其他較簡單的組件種類並非必須，而此種屬性中的數值也不用被定義。
CCR中所包含的資訊如表3所示，對於支援開放架構測試系統主要組件的CCR來說，硬體模組廠商有責任提供是項資訊。
用於一個廠商的數位針腳模組之驅動程式的簡易單一組件CCR檔案範例如下：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.0.1.0； Grouplncompat OAI_TOS(<0.5.0)； Complncompat AT_PinModule.dll(<0.5.0)； CompType Bin； 接下來為用於同一廠商的數位針腳模組之校準DLL的單一組件CCR檔案範例：Version 1.0； Description "Advantest Digital Pin Module Calibration DLL"； VendorName AT； VendorlD 1； ModuleName DM250MHz； ModuleID 4； FileParams “”； Function Calibration [cfg/AT/AT_Cal_DM250MHz_0.5.0 21.algver.ini]； HardwareRev 1095188784； DeployTo SYSC； Register "N"； Grouplncompat OAI_TOS(<0.5.0)； 要注意的是版本(Version)標示CCR描述語言的版本，並不一定與它描述的任何組件的版本有關，在第一個範例中的資源(Resource)欄位顯示這個模組驅動程式(用於DM250MHz硬體模組)可用來驅動提供4個單元的模組觸發資源(moduletrigger resource)的硬體模組，以及32個單元的dpin資源。參數"cfg/AT/AT_Cal_DM250MHz_0.5.021.algver.ini"(在第二範例中標示為校準的功能)標示包含校準程式演算法版本資訊的檔案之路徑名稱。在匯入組態資料庫(CDB)後，OCTool用來產生校準捆束資訊(bundle information)。在每一個範例中Grouplncompat欄位的數值"OAI_TOS(<0.5.0)"顯示，CCR所描述的DLL係與開放架構測試系統內，包含於TOS發布族群CCR、版本號碼低於0 5的TOS組件不相容。
群組CCR的資訊
群組CCR為描述個別組件的集合、或其他群組CCR的CCR，群組CCR所包含的資訊如表4所示。
以下為用於開放架構測試系統的TOS發布之之群組CCR的範例：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； ... } }
匯入群組CCR
群組CCR除了描述群組外，還可匯入其他的群組CCR，以下為匯入群組CCR的範例。
Version 1.0； Import OAI_USERSDK_1.0.0.1； 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； ... } }
組態資料庫
ICM組態資料庫(CDB)維護透過所有已安裝的CCR所代表的系統組態資料的集合，在CDB中所管理的資訊係與任何特殊測試器安裝無關。
建立CDB與匯入CCR資料的工作是由開放架構測試系統的CDBMgr工具所負責，CDBMgr工具不需要被安裝或在測試器上執行，而它所操縱的資訊並非特殊測試器所特有，不過它需要能夠存取$OASIS_ARCHIVE_ROOT底下的目錄，因為它需要讀取儲存在該樹狀結構內的CCR檔案(匯入功能)。
CDB的資訊係用來建立同樣儲存在CDB中的系統設定檔，以下將進行敘述。
系統設定檔
系統設定檔由以下的要求所標示：□ 開放架構測試系統的系統設定檔，出使用者所選擇，係用以定義特殊開放架構測試系統軟體組態所需的資訊的總和，而該軟體組態則為必須用於開放架構測試系統上。
系統設定檔並不包含任何測試器所特有的資訊，它涵蓋了所有必要的資訊以及由使用者選擇的一組軟體組件之間的互相依賴性，用以在一測試器上進行啟動。
□ 與硬體模組相關的軟體(像是驅動程式、仿真、校準以及診斷組件)；□ 開放架構測試系統執行時間軟體；□ 使用者SDK組件(測試開發環境所需)；以及□ 廠商SDK組件(模組開發環境所需)
要注意的是，儘管使用者建立的系統設定檔資訊係儲存於CDB，透過OCTool匯出系統設定檔則會產生一個檔案，其包含所有相關的測試器無關資訊，用以定義設定檔，藉此讓設定檔可以在CDB外部使用，然後開放架構測試系統的啟動程序即可使用，這個儲存設定檔資訊的檔案被稱為OASISVer.cfg，其為標準的Windows INI檔案格式，並且預設是儲存在對應的$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>目錄，不過，在匯出設定檔時，使用者可選擇把檔案放在別的位置。
在啟動中，在使用者設定檔中與測試器無關的資訊係與測試器特有資訊結合，以形成測試器的作動組態(active configuration)，其中包含一組儲存於$OASIS_ACTIVE_CONFIGS的測試環境檔案，啟動(Activation)會在下一節中敘述，其中會再提到系統設定檔。
OCTool
一旦開放架構測試系統的CDB已被載入CCR資料，組態設定工具(OCTool)會被用來建立、儲存、修改與匯出(也就是在CDB外也可使用)使用者所建立的系統設定檔。
OCTool不一定要被安裝或在測試器上執行，而它所操縱的資訊也非特殊測試器所特有，不過，它需要能夠存取位於$OASIS_ARCHIVE_ROOT的目錄，因為它需要在$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>的目錄下儲存使用者設定檔資訊(匯出功能)。
啟動
以下的要求標示了開放架構測試系統的軟體系統啟動，啟動開放架構測試系統的軟體系統的動作為：1.利用在一被選擇的系統設定檔中的與測試器無關組態的資訊，2.將它與測試器特有資訊相結合，在$OASIS_ACTIVE_CONFIGS創造測試器作動組態資訊，3.在$OASIS_INSTALLATION_ROOT目錄下佈署(也就是放置與註冊)所有必須的軟體組件(檔案)，4.然後在目標測試器上啟動開放架構測試系統的TOS與被選擇的組態。
啟動開放架構測試系統的軟體系統是開放架構測試系統的測試器控制精靈(TCD)的一個功能，如上所述，TCD提供COM介面方法，讓已連線的應用程式可以傳送測試器控制命令，承上述，安裝於<MAINTENANCE_ROOT>/bin的TCD控制器應用程式是簡單的命令行應用程式，可以傳送基本的測試器系統控制命令給TCD，像是「開始(start)」、「停止(stop)」、「啟動(activate)」等，同時在Advantest T2000系統中，這是t2kctrl應用程式。在本節中，將敘述如何使用t2kctrl應用程式以執行「啟動(activate)」的功能。
必要條件
在嘗試啟動一特殊開放架構測試系統組態(透過被選擇的設定檔)，必須滿足以下的必要條件：1.$OASIS_ARCHIVE_ROOT所標示的位置可被在目標測試器機器的系統控制器上執行的TCD所存取。
2.先前已定義的開放架構測試系統的系統設定檔已被匯出至OASISVer.cfg，並且可以在$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>或使用者選擇的另一個位置可用到，而匯出的檔案OASISVer.cfg可被在目標測試器機器的系統控制器上執行的TCD所存取。
3.環境變數OASIS_INSTALLATION_ROOT以及OASIS_TEMP已被定義，要注意的是如果在$OASIS_INSTALLATION_ROOT所指向的位置已經有開放架構測試系統的軟體系統的另一個組態，而此安裝已被備份至${OASIS_INSTALLATION_ROOT}_BAK，而啟動程序如果成功的話，會把所選擇的新組態放在$OASIS_INSTALLATION_ROOT底下。
4.環境變數OASIS_ACTIVE_CONFIGS已被定義，要注意的是如果在$OASIS_INSTALLATION_ROOT所指向的位置已經有開放架構測試系統的軟體系統的另一個組態，而此安裝已被備份至${OASIS_ACTIVE_ROOT}_BAK，而啟動程序如果成功的話，會把所選擇的新組態放在$OASIS_ACTIVE_ROOT底下。
5.環境變數OASIS_MACHINE_DIR已被定義，要注意的是如果目錄已經存在的話，目錄$OASIS_MACHINE_DIR/CD/bundles的任何現有的校準/診斷(CD)捆束描述檔案都會被清除，而與被選擇的設定檔有關的CD捆束描述檔案會被安裝在該位置。
6.測試器工廠預設(FDEF)檔案<MAINTENANCE_ROOT>/cfg/OASISHW.def存在於系統控制器上。這個檔案是在提供測試器特有資訊給啟動程式時必要的檔案。
7.開放架構測試系統位於狀態n，n>0，也就是至少在目標機器的系統控制器上的TCD是在執行中，若否，使用者應利用命令"net start T2000Svc"加以啟動。
使用t2kctrl應用程式
以下的命令可被用來引發來自目標機器的系統控制器上的啟動程序。
t2kctrl switch<config><archive－location><profile－directory－name>其中<組態(config)>應該是除錯(DEBUG)或發布(RELEASE)的其中之一，指示應被安裝的軟體的建構模式(build mode)。
<檔案庫位置(archive－location)>應標示環境變數OASIS_ARCHIVE_ROOT所指向的位置的完整路徑名稱。
<設定檔目錄名稱(profile－directory－name)>應該標示匯入設定檔資訊所在的設定檔目錄之完整路徑名稱。
啟動程序
一旦下達適當的命令後，啟動的程序如下：1.如果測試器係位於狀態2(見第8頁)，系統控制器TCD先發出TOS「關閉」命令，讓系統回到狀態State 1，如果有任何開放架構測試系統應用程式在當時係連接至系統控制器，它會傳送訊息要求應用程式斷線，並且給予足夠時間以清除狀態並從容離開，否則就強制終止。要注意的是，這並不適用於在當時沒有連接至系統控制器的應用程式。
2.當系統係位於狀態1，目前在$OASIS_INSTALLATION_ROOT的安裝，會被備份至${OASIS_INSTALLATION_ROOT}_BAK，而所有已經被註冊至Windows登錄檔的開放架構測試系統可執行檔(見表3的”Register”欄位)會被反註冊(de_registered)，這個步驟會用於系統控制器，以及現場控制器。
3.如果在$OASIS_ACTIVE_CONFIGS之中有現行作動組態資訊，會被備份至${OASIS_ACTIVE_CONFIG'S}_BAK，而位於$OASIS_MACHINE_DIR/CD/bundles內的CD捆束描述檔案(如果有的話)，會被刪除。
4.當完成現行安裝與作動組態資訊的備份(若有需要的話)後，TCD會備份被選擇(新)的設定檔所示之已存檔的開放架構測試系統的軟體系統檔案，至下一節中所標示的位置，在一分散式環境(分散的系統與現場控制器)，要被安裝在現場控制器上的檔案會被同時複製至那些機器上。
5.接著TCD在系統與現場控制器上，註冊所有需要註冊在Windows登錄檔的開放架構測試系統可執行檔。
6.接著TCD會把來自被選擇(新的)設定檔之與測試器無關的資訊與來自測試器工廠預設檔案(位於系統控制器的<MAINTENANCE_ROOT>/cfg目錄)的測試器特有資訊結合，這會產生以下的檔案組，用以定義作動組態，以便用於在目標測試器機器上安裝新的架構測試系統軟體執行時間：i.模組組態檔案，OASISModules.cfg。
ii.模擬組態檔案，OASISSim.cfg。
iii.系統組態檔案，OASISSys.cfg。
iv.離線組態檔案，OASISOffline.cfg。
這些檔案係由TCD放在$OASIS_ACTIVE_CONFIGS目錄下。
7. TCD同樣會把新設定檔資訊檔案OASISVer.cfg的一份複製放在$OASIS_ACTIVE_CONFIGS的位置，以便作為系統用於新設定檔的內容與組態之記錄。
8.最後，TCD會遵循在TOS啟動程序的步驟2至4所標示的TOS啟動序列，將TOS啟動為新的配置，藉此完成啟動程序。
要注意的是，若執行上述任一步驟失敗的話會使得開放架構測試系統回復到發出啟動命令的組態，而TCD會重新以該組態啟動TOS，整個流程的完整記錄檔會在$OASIS_INSTALLATION_ROOT/logs/Deployment的位置，檔名為Deployment.log，而每次TCD有新的「啟動」命令時會被覆寫。
佈署目錄結構
如前所述，TCD從存檔的位置$OASIS_ARCHIVE_ROOT複製要求的開放架構測試系統的軟體檔案至目標測試器的佈署或執行時間安裝目錄$OASIS_INSTALLATION ROOT。
在測試器上的開放架構測試系統佈署的目錄結構$OASIS_INSTALLATION_ROOT如第6圖、第7圖、以及第8圖所示，啟動程序符合以下描述：□ 為了在測試器機器上啟動執行時間，所有開放架構測試系統軟體組件檔案係被佈署至適當的位置$OASIS_INSTALLATION_ROOT，如第6圖、第7圖、以及第8圖所示，並於表5中敘述。
在以下的圖表中，名為OAI的目錄包含開放架構測試系統的TOS檔案，其中名為<vendor>的目錄包含廠商特有檔案，在檔案庫結構中，每一個廠商有它自己的目錄，而<vendor>代表一個獨特的2到3個字元的識別碼(例如Advantest廠商目錄被標示為AT)。
表5進一步描述在上述圖表中的目錄結構，其中在第一行中的每一個目錄係與$OASIS_INSTALLATION _ROOT有關。
變換檔名
在啟動中，當檔案被佈署至來自檔案庫的執行時間環境，TCD會把內嵌於檔名的版本識別碼拿掉，因此，舉例來說，在檔案庫的OAI_utils_0.1.2.dll被複製至在執行時間安裝內的OAI_utils.dll，而在檔案庫的AT_Cal_DM250MHz_D_1.2.3.dll會被複製至在執行時間安裝內的AT_Cal_DM250MHz D.dll。
作動測試器組態
如啟動程序中所述，在目標測試器機器上佈署開放架構測試器系統時，來自被選擇(新的)設定檔之與測試器無關的資訊與TCD所用的FDEF檔案結合，這會產生以下的檔案組，用以定義作動組態，以便用於在目標測試器機器上安裝新的架構測試系統軟體執行時間：模組組態檔案，OASISModules.cfg。
模擬組態檔案，OASISSim.cfg。
系統組態檔案，OASISSys.cfg。
離線組態檔案，OASISOffline.cfg。
這些檔案係由TCD放在$OASIS_ACTIVE_CONFIGS目錄下。
這些檔案被TCD放置在$OASIS_ACTIVE_CONFIGS，要注意不可把$OASIS_ACTIVE_CONFIGS設定於$OASIS_INSTALLATION_ROOT樹狀目錄底下的位置。
開放架構測試系統機器資料
測試器機器特有資料，像是校準/診斷(CD)資料等，係被儲存在系統控制器中，位於環境變數OASIS_MACHINE_DIR所指向的位置，除了資料以外，CDdata目錄包含子目錄CD/bundles，用以儲存CD與現行被佈署(也就是作動的)設定檔有關的捆束資料。
要注意在$OASIS_MACHINE_DIR位置的資料組(data set)係完全由使用者維護，使用者有責任提供特殊機器所要求的資料組，不過啟動程序會負責以下與CD捆束描述檔案有關的動作：□ 目錄$OASIS_MACHINE_DIR/CD/bundles的任何現有的校準/診斷(CD)捆束描述檔案都會被清除，而與新的、被選擇的設定檔有關的CD捆束描述檔案會被安裝至$OASIS_MACHINE DIR/CD/bundles。
要注意不可把$OASIS_MACHINE_DIR設定於$OASIS_INSTALLATION_ROOT樹狀目錄底下的位置。
稽核
用於開放架構測試系統的設定檔稽核A可以讓使用者驗證儲存於CDB中的給定設定檔之內容，而另一方面，開放架構測試系統稽核係指提供在特殊測試系統上的現行作動軟體與硬體組件的清單，以下的措施係用以達成此項動作。
設定檔稽核
對於與測試器無關的設定檔資訊來說，設定檔稽核可透過2種不同的機制來進行：□ OCTool應用程式可顯示儲存於CDB的被選擇設定檔的內容。
□ 匯出一給定設定檔(在啟動該設定檔尚未完成前執行)至預設的位置$OASIS_ARCHIVE_ROOT/profiles/<profile_dir>(或由使用者所建立的另一個位置)的動作會產生OASISVer.cfg檔案，此檔案的內容完整描述被選擇的設定檔，由於此檔案是純文字，並採用Windows INI檔案格式，所以資訊可被掃瞄以提供所需的稽核功能。要注意的是在一作動的佈署中，此檔案同時也可在$OASIS_ACTIVE CONFIGS找到。
系統稽核
系統稽核可被分為2個部份：被佈署軟體的稽核，以及測試器硬體的稽核。
被佈署軟體稽核
透過滿足下列要求的開放架構測試系統，可促進被佈署軟體的稽核：□ 在一目標測試器機器上的開放架構測試系統的軟體佈署或啟動建立一純文字佈署記錄，用以提供被佈署軟體的完整細節，此記錄檔會被命名為Deployment.log，並且被放在系統控制器上的位置：<MAINTENANCE_ROOT>/logs/Deployment。
由於記錄檔為純文字，所以它的資訊可被掃瞄以提供所需的稽核功能。
測試器硬體稽核
藉由在開放架構測試系統上的TOS滿足以下要求，可促進測試器硬體的稽核：□ 每一次當TOS被啟動時，模組細節資訊被寫成開放架構測試系統硬體庫存(HWINV)檔案格式，而檔案會被儲存於OASISHW.inv，放在系統控制器上的位置：<MAINTENANCE_ROOT>/cfg。
由於硬體庫存檔案(hardWare inventory file)為純文字，所以它的資訊可被掃瞄以提供所需的稽核功能。
軟體修正發布
如上述新組件版本安裝一節中所討論，安裝套件可包含個別組件，用以修正或加強一組件的現行被發布版本，當此一安裝套件係與擬欲修正的主要/次要之發布版本相容時，該套件(還有，藉由延伸檔名，與其有關的發布)係被稱為是一「修正程式(patch)」，在此節中，將描述提供這類修正程式發布的步驟。
當一組件的新版本被發布時，組件供應商(TOS或廠商)提供用於此一新組件版本的CCR，組件成分的檔名反映組件的新版本，如檔案命名要求一節所述，遵循該檔案命名規則可預防覆寫現行檔案，因此，組件檔案版本會持續在檔案庫目錄下累積，由於現行組件的新版本並不會更新現有組件/檔案，任何先前存在的系統設定檔仍可持續執行。
提供修正程式發布
以下為提供修正程式發布(patch release)的步驟：1.供應者(TOS供應商、廠商或系統整合者)識別與建立(一組)組件，用以修改或加強現行發布版本，舉例來說，考慮包含OAI_core.dll與OAI_messages.dll的被更新版本之TOS修正程式，其中現行發布版本為OAI_core 1 2 9 dll以及OAI_messages_l .2.2.dll，讓現行發布的TOS發布CCR為OAI_TOS_1.2.11.ccr。
2.在上述集合中的每一組件被指定一個名稱，其中在major.minor.patch三重格式中的"patch"欄位會被更新以識別系統中的版本組件，因此，在以上的範例中被更新的組件可被命名為OAI_core_1.2.10.dll以及OAI_messages_1.2.3.dll。
3.被建立的新修正程式CCR係被用於每一個被更新組件，反映出被更新版本資訊，因此，在上述範例中，用於組件的被更新CCR可以是OAI_core_1.2.10.dll.ccr以及OAImessages_1.2.3.dll.ccr。
4.新的發布群組CCR被建立以取代用於現行發布的原始群組CCR，該CCR包含用於新的一組CCR之被更新的參考，以用於被更新組件(在我們的範例中，是OAI_core_1.2.10.dll.ccr以及OAI_messages_1.2.3.dll.ccr)，而在此群組中所有其他組件的參考則維持與現行發布者相同，此一新的群組CCR會被賦予一個<version>號碼，在major.minor.patch的"patch"欄位會被更新，以便在名稱上識別被考慮的套件之集合的<version>發布，因此，在我們的範例中，新的發布群組CCR可被命名為OAI_TOS_1.2.11.ccr。
5.供應商建立一開放架構測試系統的檔案庫安裝套件，由用於整個套件的被更新組件、它們的被更新個別CCR、以及新的發布群組CCR所組成，這個套件係以整合的「修正程式」的方式遞送，以用於被識別的組件。
使用修正程式發布
對於使用者來說，用以安裝、設定與啟動修正程式的步驟如下：1.使用者安裝修正程式套件的內容於開放架構測試系統安裝檔案庫位置。
2.使用者設定修正程式的方法，是先找出他想要使用的設定檔，然後修改它(或者是以它作為新設定檔的基礎)以使用新的發布群組CCR(以及藉此，將個別組件CCR用於被更新組件)以及儲存修正過後(或新的)設定檔。
3.最後，使用者利用t2kctrl工具，採用上述被修改(或新的)設定檔來啟動修正程式。
僅限硬體的修正程式
硬體供應商有時需更新硬體版本，而不用更新對應的軟體，在此類情況中，軟體所用的現行CCR並不包含正確的新硬體版本之相容性資訊。
僅限硬體的修正程式(Hardware－Only Patch,HOP)係指發布一被更新的CCR，其目的在於更新硬體/軟體相容性關係，當這些CCR被匯入資料庫，設定檔可利用新的相容性資訊加以更新，這類CCR係照往例被建立，並可採套件方式，不用任何軟體而被發送。
當使用者收到這類新的CCR，用以安裝、組態設定、以及啟動修正程式的步驟，如同使用者用來處理新的CCR一般。
應當了解的是，以上已參考不同的功能單元以及處理器說明本發明的實施例，不過，任何適合在不同功能單元或處理器之間分配功能的方式，可在不違背本發明的情況下進行，舉例來說，由個別處理器或控制器所執行的功能可被同一處理器或控制器所執行，因此，對於特定功能單元的參考只是當作用以提供所述功能的適當手段的參考，而非精確的邏輯或實體結構或組織。
本發明可藉由任何合適的硬體、軟體或軟硬體的任意組合加以實施，本發明可選擇性地與被部份地實施為在一或更多個資料處理器以及/或者數位訊號處理器上執行的電腦軟體，本發明的實施例之元件與組件可實體地工作，並邏輯地以任何適當方式實施。事實上本發明的功能可用單一單元、複數個單元，或其他功能單元的一部分加以實施，因此，本發明可以一單一單元加以實施，或可被實體地與功能地分配在不同的單元以及處理器。
熟悉此技藝者應可了解，在運用同一基本機制與方法的情況下，本發明還有各種可能的修正以及實施例的組合，先前用以解釋本發明的敘述，係參考特定實施例而撰寫，不過，以上的示範討論並非用以窮舉或限制本發明在所揭示的精確形式內，根據上述的說明，各種修正與變化都是有可能的，而在此所選擇與描述的實施例係用以解釋本發明的原則及其實際應用，並且讓熟悉此技藝者能夠善用本發明，並根據所考量的特殊用途進行各種實施例的修正。
102．．．系統控制器
104．．．現場控制器
106．．．模組連線致能器
108．．．測試模組
110．．．測試現場
112．．．受測裝置
114．．．負載板
上述有關本發明的特色與優點，以及其他額外的特色與優點，將在以下有關本發明的實施例的詳細說明中，配合附屬的圖表加以敘述。
第1a圖所示為根據本發明的一個實施例之開放架構測試系統；第1b圖所示為根據本發明的一個實施例，一種用以管理一模組式測試系統內的多個硬體測試模組版本、軟體組件、以及測試器作業系統(TOS)版本的方法；第2a圖所示為根據本發明的一個實施例，一TOS控制與工廠預設目錄結構；第2b圖所示為根據本發明的一個實施例，開放架構測試系統之狀態圖；第3圖所示為根據本發明的一個實施例，一TOS安裝目錄結構；第4圖所示為根據本發明的一個實施例，一使用者軟體開發套件(SDK)安裝目錄結構；第5圖所示為根據本發明的一個實施例，一廠商軟體開發套件(SDK)安裝目錄結構；第6圖所示為根據本發明的一個實施例，一TOS佈署目錄結構；第7圖所示為根據本發明的一個實施例，一使用者SDK佈署目錄結構；以及第8圖所示為根據本發明的一個實施例，一廠商SDK佈署目錄結構。

Claims (22)

  1. 一種用以管理一模組式測試系統內的多個硬體測試模組版本、軟體組件、以及測試器作業系統(TOS)版本的方法，其中該模組式測試系統包含一用以控制至少一個現場控制器之系統控制器，且其中該至少一個現場控制器控制至少一個硬體測試模組，該方法包含以下步驟：於一檔案庫中安裝與該模組式測試系統相容之該等TOS版本；於該檔案庫中安裝對應至該等硬體測試模組版本之廠商軟體組件；建立系統設定檔，用以描述對應至該等硬體測試模組版本與該等TOS版本之廠商軟體組件作為不包含針對特定測試系統的資訊的測試器無關資訊，各個系統設定檔涵蓋廠商軟體組件間之互相依賴性；選擇一系統設定檔，該系統設定檔包括一組相容的廠商軟體組件與一選擇TOS，用以測試該測試系統的一特定硬體測試模組版本；藉由組合該選擇系統設定檔與特定測試資訊，建立測試器作動組態；及根據該建立的測試器作動組態，啟動在該系統控制器上與該至少一現場控制器之該被選擇的TOS。
  2. 如申請專利範圍第1項之方法，其中安裝廠商軟體 組件包含：安裝一測試控制精靈(TCD)，用以執行該等TOS版本的一般控制；以及安裝TOS控制目錄。
  3. 如申請專利範圍第2項之方法，其中安裝TOS控制目錄包含：安裝一箱目錄，用以儲存TCD控制器應用程式與其相關的動態連結程式庫；安裝一組態目錄，用以儲存與該測試器的工廠預設設定相關的組態檔案；安裝一文件目錄，用以儲存TCD與工廠預設文件；以及安裝一安裝日誌目錄，用以儲存該TCD的操作。
  4. 如申請專利範圍第3項之方法，其中該安裝日誌目錄包含：一用以將每一個檔案拷貝至該檔案庫之路徑；以及被拷貝至或從該檔案庫被移除之檔案的狀態。
  5. 如申請專利範圍第1項之方法，其中安裝廠商軟體組件進一步包含：安裝一單一組件組態記錄(單一CCR)；以及安裝一群組組件組態記錄(群組CCR)。
  6. 如申請專利範圍第5項之方法，其中該單一組件組態記錄包含：一軟體組件之廠商名稱；以及 該軟體組件之廠商識別碼。
  7. 如申請專利範圍第5項之方法，其中該群組組件組態記錄包含：被該群組組件組態記錄代表的該群組的組件之描述；該群組組件組態記錄之廠商名稱；以及該群組組件組態記錄之廠商識別碼。
  8. 如申請專利範圍第1項之方法，其中該系統設定檔包含：該等硬體測試模組版本所特有的軟體組件；使用者軟體開發套件(使用者SDK)；以及廠商軟體開發套件(廠商SDK)。
  9. 如申請專利範圍第8項之方法，其中該等硬體測試模組版本所特有的該等軟體組件包含：裝置驅動程式；仿真軟體組件；校準軟體組件；以及診斷軟體組件。
  10. 如申請專利範圍第1項之方法，其中啟動該被選擇的TOS包含：啟始該被選擇的TOS；以及佈署一自該模組式測試系統的該系統設定檔挑選的軟體組態。
  11. 如申請專利範圍第10項之方法，其中啟始該被選擇的TOS包含： 啟始該系統控制器；啟始該現場控制器；以及根據用於該模組式測試系統之該系統設定檔，啟始使用者應用程式。
  12. 如申請專利範圍第10項之方法，其中佈署一被挑選的軟體組態包含：結合與測試器無關的組態資訊與測試特有的資訊，以創造一測試器作動組態資訊；從預先定義的目錄位置佈署軟體組件；以及由該特定硬體測試模組版本的該被挑選的軟體組態，開始該被選擇的TOS。
  13. 如申請專利範圍第1項之方法，進一步包含：確認一新廠商軟體版本與現有TOS版本的相容性。
  14. 一種用以管理多個硬體測試模組版本、軟體組件、以及測試器作業系統(TOS)版本的模組式測試系統，包含：一系統控制器，用以控制至少一個現場控制器；至少一現場控制器，用以控制至少一個硬體測試模組；一程式庫，用以儲存與該模組式測試系統相容之測試作業系統版本及對應至該等硬體測試模組版本之廠商軟體組件；建立與儲存手段，用以建立及儲存一系統設定檔，用以描述對應至該等硬體測試模組版本與該等TOS版本之 廠商軟體組件成為不包含針對特定測試系統的資訊的測試器無關資訊，該系統設定檔涵蓋在該等廠商軟體組件間之互相依賴性；以及選擇手段，用以選擇包含一組相容廠商軟體組件與選擇TOS的該系統設定檔，用以一特定硬體測試模組版本，其中該系統控制器及該至少一現場控制器藉由組合該選擇系統設定檔與特定測試器資訊而建立測試器作動組態，及根據所建立測試器主動組態，啟動該被選擇的TOS。
  15. 如申請專利範圍第14項之系統，其中該等廠商軟體組件包含：測試控制精靈(TCD)，用以執行該等TOS版本的一般控制；以及TOS控制目錄。
  16. 如申請專利範圍第15項之系統，其中該等TOS控制目錄包含：一箱目錄，用以儲存TCD控制器應用程式與其相關的動態連結程式庫；一組態目錄，用以儲存與該測試器的工廠預設設定相關的組態檔案；一文件目錄，用以儲存TCD與工廠預設文件；以及一安裝日誌目錄，用以儲存該TCD的操作。
  17. 如申請專利範圍第16項之系統，其中該安裝日誌目錄包含： 用以將每一個檔案拷貝至一檔案庫之路徑；以及被拷貝至或從該檔案庫被移除之檔案的狀態。
  18. 如申請專利範圍第14項之系統，其中該等廠商軟體組件進一步包含：一單一組件組態記錄(單一CCR)；以及一群組組件組態記錄(群組CCR)。
  19. 如申請專利範圍第18項之系統，其中該單一組件組態記錄包含：一軟體組件之廠商名稱；以及該軟體組件之廠商識別碼。
  20. 如申請專利範圍第18項之系統，其中該群組組件組態記錄包含：被該群組組件組態記錄代表的該群組的組件之描述；該群組組件組態記錄之廠商名稱；以及該群組組件組態記錄之廠商識別碼。
  21. 如申請專利範圍第14項之系統，其中該系統設定檔包含：該等硬體測試模組版本所特有的軟體組件；使用者軟體開發套件(使用者SDK)；以及廠商軟體開發套件(廠商SDK)。
  22. 如申請專利範圍第21項之系統，其中該等硬體測試模組版本所特有的該等軟體組件包含：裝置驅動程式；仿真軟體組件； 校準軟體組件；以及診斷軟體組件。
TW094142344A 2004-12-09 2005-12-01 執行測試儀器模組安裝與組態管理的方法與系統 TWI383166B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US63509404P 2004-12-09 2004-12-09
US11/100,109 US8082541B2 (en) 2004-12-09 2005-04-05 Method and system for performing installation and configuration management of tester instrument modules

Publications (2)

Publication Number Publication Date
TW200638054A TW200638054A (en) 2006-11-01
TWI383166B true TWI383166B (zh) 2013-01-21

Family

ID=35911084

Family Applications (1)

Application Number Title Priority Date Filing Date
TW094142344A TWI383166B (zh) 2004-12-09 2005-12-01 執行測試儀器模組安裝與組態管理的方法與系統

Country Status (7)

Country Link
US (1) US8082541B2 (zh)
EP (1) EP1820036A1 (zh)
JP (2) JP4302736B2 (zh)
KR (1) KR20070106692A (zh)
CN (1) CN101073016B (zh)
TW (1) TWI383166B (zh)
WO (1) WO2006062252A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI760691B (zh) * 2020-02-12 2022-04-11 瑞昱半導體股份有限公司 自動測試軟體相容性的方法、測試裝置與系統

Families Citing this family (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8214800B2 (en) * 2005-03-02 2012-07-03 Advantest Corporation Compact representation of vendor hardware module revisions in an open architecture test system
US7930693B2 (en) * 2005-04-04 2011-04-19 Cisco Technology, Inc. Method and system for accessing and launching a java based applet as a locally installed application
US7877350B2 (en) 2005-06-27 2011-01-25 Ab Initio Technology Llc Managing metadata for graph-based computations
US20070074202A1 (en) * 2005-09-27 2007-03-29 International Business Machines Corporation Program product installation
US7730452B1 (en) * 2005-11-01 2010-06-01 Hewlett-Packard Development Company, L.P. Testing a component of a distributed system
US7849362B2 (en) * 2005-12-09 2010-12-07 International Business Machines Corporation Method and system of coherent design verification of inter-cluster interactions
US20070156641A1 (en) * 2005-12-30 2007-07-05 Thomas Mueller System and method to provide system independent configuration references
US7877680B2 (en) * 2007-03-20 2011-01-25 International Business Machines Corporation Auto-generation and auto-versioning of a multi-sourced dynamic document
US8423831B2 (en) * 2006-07-11 2013-04-16 Oracle America, Inc. System and method for performing auditing and correction
US20080172655A1 (en) * 2007-01-15 2008-07-17 Microsoft Corporation Saving Code Coverage Data for Analysis
US20080172651A1 (en) * 2007-01-15 2008-07-17 Microsoft Corporation Applying Function Level Ownership to Test Metrics
US20080172580A1 (en) * 2007-01-15 2008-07-17 Microsoft Corporation Collecting and Reporting Code Coverage Data
US20080172652A1 (en) * 2007-01-15 2008-07-17 Microsoft Corporation Identifying Redundant Test Cases
US7844602B2 (en) * 2007-01-19 2010-11-30 Healthline Networks, Inc. Method and system for establishing document relevance
CN101441595B (zh) * 2007-11-21 2010-11-03 英业达股份有限公司 负载监控装置及测试装置及负载监控方法及测试方法
US8219349B1 (en) * 2007-12-21 2012-07-10 Intermolecular, Inc. Test management system
US7680615B2 (en) * 2008-01-25 2010-03-16 Azurewave Technologies, Inc. Parallel testing system with shared golden calibration table and method thereof
US9886319B2 (en) 2009-02-13 2018-02-06 Ab Initio Technology Llc Task managing application for performing tasks based on messages received from a data processing application initiated by the task managing application
US8812451B2 (en) 2009-03-11 2014-08-19 Microsoft Corporation Programming model for synchronizing browser caches across devices and web services
US8413139B2 (en) * 2009-03-11 2013-04-02 Microsoft Corporation Programming model for application and data access and synchronization within virtual environments
US9680964B2 (en) * 2009-03-11 2017-06-13 Microsoft Technology Licensing, Llc Programming model for installing and distributing occasionally connected applications
EP2237125A1 (en) * 2009-03-31 2010-10-06 Siemens Aktiengesellschaft Method of monitoring an analyser connected to a communications network in an industrial automation system and industrial automation system
KR101231746B1 (ko) * 2009-12-18 2013-02-08 한국전자통신연구원 ＳａａＳ 환경에서의 소프트웨어 개발 시스템
KR101687213B1 (ko) 2010-06-15 2016-12-16 아브 이니티오 테크놀로지 엘엘시 동적으로 로딩하는 그래프 기반 계산
CN103165405A (zh) * 2011-01-27 2013-06-19 北京确安科技股份有限公司 一种通过gpib接口实时生成多维变量密码方法
US20120198436A1 (en) * 2011-01-27 2012-08-02 Preimesberger Lee A Compatible Operating System
US8839057B2 (en) * 2011-02-03 2014-09-16 Arm Limited Integrated circuit and method for testing memory on the integrated circuit
US9116725B1 (en) * 2011-03-15 2015-08-25 Symantec Corporation Systems and methods for using virtualization of operating-system-level components to facilitate software testing
KR101056682B1 (ko) 2011-04-08 2011-08-12 국방과학연구소 컴포넌트 기반의 무기체계 시뮬레이션 시스템 및 시뮬레이션 방법
US8745590B2 (en) * 2011-05-19 2014-06-03 Verizon Patent And Licensing Inc. Testing an application
TWI476586B (zh) * 2011-07-13 2015-03-11 Inst Information Industry 以雲端技術為基礎之測試系統、方法以及其電腦可讀取記錄媒體
US8756595B2 (en) * 2011-07-28 2014-06-17 Yahoo! Inc. Method and system for distributed application stack deployment
TW201324354A (zh) * 2011-12-12 2013-06-16 Wistron Corp 自動化連續安裝作業系統的方法
JP5816144B2 (ja) * 2012-08-30 2015-11-18 株式会社アドバンテスト テストプログラムおよび試験システム
CN102866348A (zh) * 2012-09-23 2013-01-09 成都市中州半导体科技有限公司 集成电路测试数据查询系统及查询方法
US10108521B2 (en) 2012-11-16 2018-10-23 Ab Initio Technology Llc Dynamic component performance monitoring
US9507682B2 (en) 2012-11-16 2016-11-29 Ab Initio Technology Llc Dynamic graph performance monitoring
US20140189136A1 (en) 2012-12-31 2014-07-03 Oracle International Corporation Enforcing web service policies attached to clients operating in restricted footprint platforms
US9274926B2 (en) * 2013-01-03 2016-03-01 Ab Initio Technology Llc Configurable testing of computer programs
US9218273B2 (en) 2013-05-20 2015-12-22 International Business Machines Corporation Automatic generation of a resource reconfiguring test
CA3114544A1 (en) 2013-12-05 2015-06-11 Ab Initio Technology Llc Managing interfaces for dataflow composed of sub-graphs
CN105527940A (zh) * 2014-10-27 2016-04-27 北京确安科技股份有限公司 用ini文件实现测试管理系统流程控制
US9292423B1 (en) * 2015-03-11 2016-03-22 Amazon Technologies, Inc. Monitoring applications for compatibility issues
JP6561555B2 (ja) 2015-04-20 2019-08-21 富士通株式会社 情報処理装置、動作検証方法及び動作検証プログラム
US10657134B2 (en) 2015-08-05 2020-05-19 Ab Initio Technology Llc Selecting queries for execution on a stream of real-time data
WO2017112654A2 (en) 2015-12-21 2017-06-29 Ab Initio Technology Llc Sub-graph interface generation
CN105786562A (zh) * 2016-02-04 2016-07-20 百度在线网络技术（北京）有限公司 一种集成插件的方法和装置
CN107577570A (zh) * 2017-09-19 2018-01-12 郑州云海信息技术有限公司 一种应用设备的测试方法及装置
JP6960873B2 (ja) * 2018-03-16 2021-11-05 東京エレクトロン株式会社 半導体製造システム及びサーバ装置
US10320625B1 (en) 2018-08-21 2019-06-11 Capital One Services, Llc Managing service deployment in a cloud computing environment
US10430321B1 (en) 2018-08-21 2019-10-01 International Business Machines Corporation White box code concurrency testing for transaction processing
CN109376048A (zh) * 2018-12-25 2019-02-22 上海创功通讯技术有限公司 一种触摸屏的测试方法及设备
CN111913869B (zh) * 2019-05-08 2024-02-13 立端科技股份有限公司 自动测试主机操作系统的测试方法及其测试系统
US11899550B2 (en) 2020-03-31 2024-02-13 Advantest Corporation Enhanced auxiliary memory mapped interface test systems and methods
US11733290B2 (en) 2020-03-31 2023-08-22 Advantest Corporation Flexible sideband support systems and methods
US11650893B2 (en) 2020-03-31 2023-05-16 Advantest Corporation Multiple name space test systems and methods
US11493551B2 (en) 2020-06-22 2022-11-08 Advantest Test Solutions, Inc. Integrated test cell using active thermal interposer (ATI) with parallel socket actuation
US11549981B2 (en) 2020-10-01 2023-01-10 Advantest Test Solutions, Inc. Thermal solution for massively parallel testing
US11808812B2 (en) 2020-11-02 2023-11-07 Advantest Test Solutions, Inc. Passive carrier-based device delivery for slot-based high-volume semiconductor test system
US11821913B2 (en) 2020-11-02 2023-11-21 Advantest Test Solutions, Inc. Shielded socket and carrier for high-volume test of semiconductor devices
US20220155364A1 (en) 2020-11-19 2022-05-19 Advantest Test Solutions, Inc. Wafer scale active thermal interposer for device testing
US11609266B2 (en) 2020-12-04 2023-03-21 Advantest Test Solutions, Inc. Active thermal interposer device
US11573262B2 (en) 2020-12-31 2023-02-07 Advantest Test Solutions, Inc. Multi-input multi-zone thermal control for device testing
US11587640B2 (en) 2021-03-08 2023-02-21 Advantest Test Solutions, Inc. Carrier based high volume system level testing of devices with pop structures
US11656273B1 (en) 2021-11-05 2023-05-23 Advantest Test Solutions, Inc. High current device testing apparatus and systems
CN115033466B (zh) * 2022-05-23 2023-04-07 珠海视熙科技有限公司 批量刷机压力测试方法及装置、存储介质、计算机设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6182275B1 (en) * 1998-01-26 2001-01-30 Dell Usa, L.P. Generation of a compatible order for a computer system
TW535082B (en) * 2001-06-01 2003-06-01 Chroma Ate Inc Processing method for control and access of data with devices of automatic testing system
US20030192031A1 (en) * 2002-01-18 2003-10-09 Sriram Srinivasan Systems and methods for application deployment
US20040194064A1 (en) * 2003-03-31 2004-09-30 Ranjan Mungara Vijay Generic test harness
TWI221614B (en) * 2000-07-31 2004-10-01 Hitachi Ltd Tester architecture construction data generating method, tester architecture constructing method and test circuit

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5450586A (en) * 1991-08-14 1995-09-12 Hewlett-Packard Company System for analyzing and debugging embedded software through dynamic and interactive use of code markers
US5903758A (en) * 1997-02-24 1999-05-11 Sun Microsystems, Inc. Method and apparatus for auditing dynamically linked procedure calls
US5960198A (en) * 1997-03-19 1999-09-28 International Business Machines Corporation Software profiler with runtime control to enable and disable instrumented executable
US6954922B2 (en) * 1998-04-29 2005-10-11 Sun Microsystems, Inc. Method apparatus and article of manufacture for time profiling multi-threaded programs
US6381735B1 (en) * 1998-10-02 2002-04-30 Microsoft Corporation Dynamic classification of sections of software
US6895578B1 (en) * 1999-01-06 2005-05-17 Parasoft Corporation Modularizing a computer program for testing and debugging
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6331770B1 (en) * 2000-04-12 2001-12-18 Advantest Corp. Application specific event based semiconductor test system
CN1154045C (zh) * 2000-07-25 2004-06-16 华为技术有限公司 一种跨平台的联合仿真系统
US7111282B2 (en) * 2001-06-12 2006-09-19 Hewlett-Packard Development Company, L.P. Instrumenting a software program and collecting data from the instrumented software program by type
US20040225459A1 (en) * 2003-02-14 2004-11-11 Advantest Corporation Method and structure to develop a test program for semiconductor integrated circuits
US7197416B2 (en) * 2004-05-22 2007-03-27 Advantest America R&D Center, Inc. Supporting calibration and diagnostics in an open architecture test system
US7430486B2 (en) * 2004-05-22 2008-09-30 Advantest America R&D Center, Inc. Datalog support in a modular test system
US7210087B2 (en) * 2004-05-22 2007-04-24 Advantest America R&D Center, Inc. Method and system for simulating a modular test system
US20060130001A1 (en) * 2004-11-30 2006-06-15 International Business Machines Corporation Apparatus and method for call stack profiling for a software application

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6182275B1 (en) * 1998-01-26 2001-01-30 Dell Usa, L.P. Generation of a compatible order for a computer system
TWI221614B (en) * 2000-07-31 2004-10-01 Hitachi Ltd Tester architecture construction data generating method, tester architecture constructing method and test circuit
TW535082B (en) * 2001-06-01 2003-06-01 Chroma Ate Inc Processing method for control and access of data with devices of automatic testing system
US20030192031A1 (en) * 2002-01-18 2003-10-09 Sriram Srinivasan Systems and methods for application deployment
US20040194064A1 (en) * 2003-03-31 2004-09-30 Ranjan Mungara Vijay Generic test harness

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Rochit Rajsuman, "An Overview of the Open Architecture Test System," Second IEEE International Workshop on Electronic Design, Test and Applications, 2004, pp. 341 - 346 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI760691B (zh) * 2020-02-12 2022-04-11 瑞昱半導體股份有限公司 自動測試軟體相容性的方法、測試裝置與系統

Also Published As

Publication number Publication date
TW200638054A (en) 2006-11-01
JP2008533542A (ja) 2008-08-21
US20060130041A1 (en) 2006-06-15
JP4302736B2 (ja) 2009-07-29
CN101073016A (zh) 2007-11-14
US8082541B2 (en) 2011-12-20
JP2009064425A (ja) 2009-03-26
KR20070106692A (ko) 2007-11-05
CN101073016B (zh) 2010-09-01
EP1820036A1 (en) 2007-08-22
WO2006062252A1 (en) 2006-06-15

Similar Documents

Publication Publication Date Title
TWI383166B (zh) 執行測試儀器模組安裝與組態管理的方法與系統
JP5362974B2 (ja) ソフトウェア製品の出荷用仮想化ソフトウェアの使用方法
US10114637B1 (en) Automatically updating a shared project build platform
US7392148B2 (en) Heterogeneous multipath path network test system
US20070204262A1 (en) Facilitating the automated testing of daily builds of software
US6598223B1 (en) Method and system for installing and testing build-to-order components in a defined configuration computer system
US8225309B2 (en) Method and process for using common preinstallation environment for heterogeneous operating systems
JP5863818B2 (ja) ソフトウェア製品のあらかじめ必要なソフトウェアをインストールするための方法、システム、およびコンピュータ・プログラム
US20080178143A1 (en) System, Method and Computer Program Product for Developing, Configuring, Installing and Testing Software
US20040181790A1 (en) System and method for maintaining installed software compliance with build standards
US20120216181A1 (en) Automatic upgrade of virtual appliances
US20040255291A1 (en) Installing software using programmatic component dependency analysis
KR20020035570A (ko) 자동적인 장치 드라이버 구성을 위한 방법, 시스템 및컴퓨터 판독 가능 저장 매체
WO2022151853A1 (zh) 一种切换操作系统执行测试任务的方法、系统及介质
US8839231B2 (en) Method and system for software installation
US20040254777A1 (en) Method, apparatus and computer program product for simulating a storage configuration for a computer system
US6021276A (en) Method and apparatus for microcode downloading
US20060168564A1 (en) Integrated chaining process for continuous software integration and validation
US20090282402A1 (en) Multi-component software application installation facility
US7277810B2 (en) Method and apparatus for automating calibration of test instruments
Blaas et al. Stateless provisioning: Modern practice in hpc
WO2001093021A2 (en) A virtual system configurator for client systems
Patrão vSphere Lifecycle Manager
Muehlbach et al. Concurrent driver upgrade: Method to eliminate scheduled system outages for new function releases
ACES et al. How to Automate and Not Manage under Rhine/Redwood

Legal Events

Date Code Title Description
MM4A Annulment or lapse of patent due to non-payment of fees