KR20070106692A - 테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및시스템 - Google Patents

테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및시스템 Download PDF

Info

Publication number
KR20070106692A
KR20070106692A KR1020077014690A KR20077014690A KR20070106692A KR 20070106692 A KR20070106692 A KR 20070106692A KR 1020077014690 A KR1020077014690 A KR 1020077014690A KR 20077014690 A KR20077014690 A KR 20077014690A KR 20070106692 A KR20070106692 A KR 20070106692A
Authority
KR
South Korea
Prior art keywords
tos
vendor
software
directory
version
Prior art date
Application number
KR1020077014690A
Other languages
English (en)
Inventor
안칸 프라마닉
짐 한라한
마크 엘스톤
토시아키 아다치
레온 엘 첸
Original Assignee
주식회사 아도반테스토
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 주식회사 아도반테스토 filed Critical 주식회사 아도반테스토
Publication of KR20070106692A publication Critical patent/KR20070106692A/ko

Links

Images

Classifications

    • 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
    • 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
    • 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)

Abstract

모듈식 테스트 시스템에 있어서 다수의 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트, 및 테스터 운영 체제(TOS) 버전을 관리하는 방법이 개시된다. 상기 방법은, 아카이브에 상기 모듈식 테스트 시스템과 호환 가능한 상기 TOS 버전을 설치하는 단계 및 아카이브에 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트를 설치하는 단계를 포함한다. 나아가 상기 방법은, 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트 및 TOS 버전을 설명하는 시스템 프로파일을 생성하는 단계, 상기 모듈식 테스트 시스템에 대하여, 특정의 하드웨어 테스트 모듈 버전을 시험하기 위한 한 세트의 호환 가능한 벤더 소프트웨어 컴포넌트 및 선택된 TOS를 포함하는 시스템 프로파일을 선택하는 단계, 및 선택된 TOS를 활성화하는 단계를 포함한다.
모듈식 테스트 시스템, 하드웨어 테스트 모듈 버전, 테스터 운영 체제, 사이트 제어기, 피시험 장치.

Description

테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및 시스템{METHOD AND SYSTEM FOR PERFORMING INSTALLATION AND CONFIGURATION MANAGEMENT OF TESTER INSTRUMENT MODULES}
[관련 출원의 상호 참조]
본 출원은 2004년 12월 9일자 미국 가출원 제60/635,094호 "테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및 시스템"을 우선권 주장의 기초로 한다. 상기 가출원은 본 출원의 출원인에게 양도되었으며, 그 전체가 참조에 의하여 본 명세서에 편입된다.
본 발명은 집적 회로를 테스트하는 기술 분야에 관한 것이다. 구체적으로, 본 발명은 테스터 장치 모듈의 설치와 구성 관리를 수행하는 방법 및 시스템에 관한 것이다.
테스트 장비가 고가인 중요한 이유는, 종래의 테스터 구조가 지닌 특성화된 속성에 있다. 각각의 테스터 제조자는 다수의 테스터 플랫폼을 보유하고 있는데, 이들은 아도반테스토(Advantest), 테러다인(Teredyne), 애질런트(Agilent)와 같은 회사들 간에 서로 호환되지 않을 뿐만 아니라, 아도반테스토 사에 의해 제조된 T3300, T5500, T6600 시리즈 테스터와 같이 한 회사 내의 플랫폼 간에도 서로 호환되지 아니한다. 이러한 비호환성으로 인해, 각각의 테스터는 고유의 특성화된 하드웨어 및 소프트웨어 컴포넌트(component)를 필요로 하고, 이러한 특성화된 하드웨어 및 소프트웨어 컴포넌트는 다른 테스터에는 사용될 수 없다. 또한, 테스트 프로그램을 하나의 테스터로부터 다른 테스터로 이식(移植)하고, 제3자 솔루션(third-party solution)을 개발하기 위해서는 상당한 노력이 요구된다. 하나의 플랫폼에 대하여 제3자 솔루션이 개발된 경우라 하더라도, 그것은 다른 플랫폼에 이식되거나 재사용될 수 없다. 하나의 플랫폼으로부터 다른 플랫폼으로의 이행(移行) 과정은, 일반적으로 복잡하고 오류가 발생하기 쉬우며, 추가적인 노력, 시간 및 증가된 테스트 비용을 야기하게 된다.
특성화된 테스터 구조의 또 다른 문제는, 모든 하드웨어 및 소프트웨어가 주어진 테스터에 대해 고정된 구성으로 유지된다는 점이다. 피시험 디바이스(device-under-test; DUT) 또는 집적회로(integrated circuit; IC)를 시험하기 위하여, DUT의 응답을 수집하고 DUT가 테스트를 통과(pass)하는지 실패(fail)하는지를 결정하는 것뿐만 아니라, 테스트 데이터, 신호, 파형, 전류 및 전압 레벨을 정의하는 상기 테스터 성능(capabilities)의 일부 또는 전부를 사용하는 전용 테스트 프로그램이 개발된다.
개방형 구조 테스트 시스템(open architecture test system)은, 기존의 테스 트 시스템의 상기 문제에 대한 해결 방법을 제공한다. 개방형 구조 테스트 시스템의 일례는 미국 출원 제10/772,434호 "반도체 집적 회로를 위한 테스트 프로그램을 개발하는 방법 및 구조"에 기재되어 있으며, 상기 출원은 참조에 의해 그 전체가 본 명세서에 편입된다. 개방형 구조 테스트 시스템은, 다양한 종류의 벤더(vendor) 하드웨어 테스트 모듈 및 그에 대응하는 DUT를 지원하도록 구성될 수 있다.
그러나, 그러한 개방형 구조 테스트 시스템을 구현하는데 있어서 극복해야 할 과제들 중의 하나는, 테스터 운영 체제(tester operating system; TOS)의 다수의 버전(versions)이 존재할 수 있다는 점이다. 또한, 각각의 벤더 하드웨어 테스트 모듈이 다수의 버전을 가질 수 있고, 상기 벤더 하드웨어 테스트 모듈의 각각의 버전은 그에 대응하는 소프트웨어 컴포넌트의 버전을 가질 수 있다. 상기 테스터 운영 체제, 벤더 하드웨어 테스트 모듈 및 소프트웨어 컴포넌트의 버전들은, 상기 벤더 하드웨어 테스트 모듈에서 테스트를 실행하기 위해, 서로 충돌하지 않고 함께 작동할 필요가 있다. 따라서, 다양하게 변형을 가한 벤더 하드웨어 테스트 모듈을 사용하여 DUT를 테스트하는 다수의 벤더 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트 버전 및 TOS 버전을 관리할 수 있는 모듈식 테스트 시스템에 대한 요구가 존재한다.
일 실시예에서, 모듈식 테스트 시스템에 있어서 다수의 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트 및 테스터 운영 체제(TOS) 버전을 관리하는 방법은, 아카이브(archive)에 모듈식 테스트 시스템과 호환 가능한 TOS 버전을 설치하는 단계 및 아카이브에 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트를 설치하는 단계를 포함한다. 나아가 상기 방법은, 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트 및 TOS 버전을 설명하는 시스템 프로파일(system profile)을 생성하는 단계, 모듈식 테스트 시스템에 대하여, 특정 하드웨어 테스트 모듈 버전을 시험하기 위한 한 세트의 호환 가능한 벤더 소프트웨어 컴포넌트들 및 선택된 TOS를 포함하는 시스템 프로파일을 선택하는 단계, 및, 모듈식 테스트 시스템에서 선택된 TOS를 활성화하는 단계를 포함한다.
다른 실시예에서, 다수의 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트, 및 테스터 운영 체제(TOS) 버전을 관리하는 시스템은, 적어도 하나의 사이트 제어기를 제어하는 시스템 제어기, 적어도 하나의 하드웨어 테스트 모듈을 제어하는 적어도 하나의 사이트 제어기, 모듈식 테스트 시스템과 호환 가능한 테스트 운영 체제 버전, 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트, 및, 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트 및 TOS 버전을 설명하는 시스템 프로파일을 포함한다.
본 발명의 상기 특징 및 이점뿐만 아니라 추가적인 특징 및 이점은, 이하의 도면과 관련된 본 발명의 실시예에 관한 상세한 설명으로부터 더욱 명확하게 이해 될 것이다.
도 1a는, 본 발명의 일 실시예에 따른 개방형 구조 테스트 시스템을 도시한다.
도 1b는, 본 발명의 일 실시예에 따른 모듈식 테스트 시스템에 있어서, 다수의 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트 및 TOS 버전을 관리하는 방법을 도시한다.
도 2a는, 본 발명의 일 실시예에 따른 TOS 제어와 제조 디폴트 디렉터리 구조를 도시한다.
도 2b는, 본 발명의 일 실시예에 따른 개방형 구조 테스트 시스템의 상태도를 도시한다.
도 3은, 본 발명의 일 실시예에 따른 TOS 설치 디렉터리 구조를 도시한다.
도 4는, 본 발명의 일 실시예에 따른 사용자 SDK 설치 디렉터리 구조를 도시한다.
도 5는, 본 발명의 일 실시예에 따른 벤더 SDK 설치 디렉터리 구조를 도시한다.
도 6은, 본 발명의 일 실시예에 따른 TOS 배치 디렉터리 구조를 도시한다.
도 7은, 본 발명의 일 실시예에 따른 사용자 SDK 배치 디렉터리 구조를 도시한다.
도 8은, 본 발명의 일 실시예에 따른 벤더 SDK 배치 디렉터리 구조를 도시한 다.
테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및 시스템이 제공된다. 이하의 기술은 본 발명의 기술 분야에서 숙련된 자가 본 발명을 만들고 이용할 수 있도록 제공된다. 특정 실시예 및 응용에 관한 기술은 단지 예로서 제공된다. 본 발명의 기술 분야에서 숙련된 자에게는 본 명세서에 기술된 예들의 다양한 변경 및 조합이 명백할 것이며, 본 명세서에 정의된 일반적인 원리들은 본 발명의 사상과 범위를 벗어나지 않고 다른 예 및 응용에 적용될 수 있다. 따라서, 본 발명은 기술된 그리고 도시된 예들로 한정되도록 의도되지 아니하며, 본 명세서에 개시된 원리 및 특성과 일치하는 가장 넓은 범위에 합치한다.
도 1a는, 본 발명의 일 실시예에 따른 개방형 구조 시스템을 도시한다. 도 1a에 도시된 바와 같이, 시스템 제어기(system controller; SysC) 102는 다수의 사이트 제어기(site controllers; SiteCs) 104와 연결된다. 상기 시스템 제어기는 또한 파일에 접근(access)하기 위해 네트워크에 연결될 수 있다. 모듈 접속 인에이블러(module connection enabler) 106을 통해, 각 사이트 제어기는 테스트 사이트 110에 위치한 하나 또는 그 이상의 테스트 모듈 108을 제어하기 위해 연결된다. 상기 모듈 접속 인에이블러 106은 접속된 하드웨어 모듈 108의 재구성을 가능하게 하고, 또한 (패턴 데이터의 로딩(loading), 응답 데이터의 수집, 제어 공급 등을 위한) 데이터 전송을 위한 버스로서도 기능한다. 가능한 하드웨어 구현으로서는 전용 접속, 스위치 접속, 버스 접속, 링(ring) 접속, 및 스타(star) 접속이 포함된다. 상기 모듈 접속 인에이블러 106은, 예를 들면, 스위치 행렬(switch matrix)에 의해 구현될 수도 있다. 각 테스트 사이트 110은 피시험 디바이스(DUT) 112와 연관되며, 상기 피시험 디바이스는 로드 보드(loadboard) 114를 통해 대응하는 사이트의 모듈에 접속된다. 본 발명의 일 실시예에 의하면, 단일 사이트 제어기는 다수의 DUT 사이트들과 접속될 수 있다.
상기 시스템 제어기 102는 전체적인 시스템 관리자로서 기능한다. 그것은 사이트 제어기 활동을 조직하고, 시스템 수준의 병렬 테스트 전략을 관리하며, 추가적으로 시스템 수준의 데이터-로깅(data-logging) 및 오류 처리 지원과 함께 핸들러(handler)/프로브(probe) 제어를 제공한다. 동작 설정(operational setting)에 따라, 상기 시스템 제어기 102는 사이트 제어기 104의 동작과 분리된 CPU에 배치될 수 있다. 또는, 공통의 CPU를 상기 시스템 제어기 102와 상기 사이트 제어기 104가 공유할 수도 있다. 이와 유사하게, 각 사이트 제어기 104는 고유의 전용 CPU(중앙 처리 장치)에 배치되거나, 동일 CPU 내의 개별 프로세스 또는 쓰레드(thread)로서 배치될 수도 있다.
상기 시스템 구조는, 개별 시스템 컴포넌트가 집적된 단일 시스템의 논리적인 컴포넌트로서 간주될 수 있고, 반드시 분산형 시스템의 물리적 컴포넌트일 필요는 없다는 점에 대한 이해를 바탕으로, 도 1a에 도시된 바와 같은 분산형 시스템으로서 개념적으로 가시화될 수 있다.
도 1b는, 모듈식 테스트 시스템에 있어서 다수의 하드웨어 테스트 모듈 버 전, 소프트웨어 컴포넌트, 및 TOS 버전을 관리하는 방법을 도시한다. 벤더 드라이버 소프트웨어의 다수의 버전뿐만 아니라, 상기 TOS의 다수의 버전과 그와 연관된 사용자 및 벤더 SDK의 버전은 아카이브(archive)에 저장된다. 개방형 구조 테스트 시스템 설치 및 구성 관리(Installation and Configuration Management; ICM) 시스템의 목적은 벤더(Vendor)들로 하여금 그들의 하드웨어 모듈을 지원하는 드라이버 소프트웨어 컴포넌트를 개발할 수 있도록 하고, 사용자들로 하여금 테스터 또는 개발 플랫폼에서의 동작에 대한 호환성 있는 벤더 드라이버 소프트웨어 및 TOS 버전을 선택할 수 있도록 하는 것에 있다. 상기 ICM 시스템은 또한 테스터 또는 개발 플랫폼에 대한 이러한 선택된 구성의 설치를 관리하고, 선택적으로 상기 선택된 구성의 활성화를 관리한다.
상기 ICM 시스템은 개방형 구조 테스트 시스템의 TOS의 관리를 위한 요구 사항 및 상기 관리에 수반되는 활동(activity)에 대해 기술한다. 개방형 구조 테스트 시스템에 대한 ICM은 4가지의 원칙적인 활동을 포함한다:
1. 설치(Installation)
이는, 이후의 활성화(activation) 또는 배치(deployment)를 위해 개방형 구조 테스트 시스템 컴포넌트를 아카이브에 복사하는 활동을 나타낸다.
2. 구성(Configuration)
이는, 소프트웨어 구성을 시스템 프로파일로서 생성, 저장 및 변경하기 위해, 사용자로 하여금 ICM 시스템과 상호 작용할 수 있도록 하는 활동을 나타내는데, 상기 시스템 프로파일은 활성화를 위해 사용된다.
3. 활성화(Activation)
이는, 선택된 소프트웨어 구성(즉, 프로파일)이 특정 테스터 상에서 활성화되도록 하는, 즉 그것을 배치하는 활동을 나타낸다.
4. 감사(Audit)
이는, 특정 테스트 시스템에서 현재 활성화된 소프트웨어 및 하드웨어 컴포넌트의 목록(listing)을 제공하는 활동을 나타낸다.
본 명세서는 상기 활동들의 각각에 대한 상세한 설명을 제공한다. 이하, 널리 알려진 약어 SW 및 HW는 각각 소프트웨어(software) 및 하드웨어(hardware)를 나타내기 위해 사용된다.
설치 및 구성이 (개념적으로, 특정 테스터에 대해 원격으로 수행될 수 있는) ICM에 특유한(ICM-specific) 활동인 반면에, 활성화 및 감사는 테스터에 특유하며(tester-specific) 어떤 개방형 구조 테스트 시스템의 TOS 구성요소, 원칙적으로는 상기 개방형 구조 테스트 시스템의 테스터 제어 데몬(Tester Control Daemon; TCD)으로부터의 협력을 필요로 함을 주의하여야 한다. 그러므로, 본 명세서는 또한, TCD 그 자체의 설치에 대해서는 물론, 상기 ICM 활동에 수반되는 TCD 및 TOS에 대하여도 기술한다. 이를 위해, 테스터 제어 및 TOS 시동 단락(section)에서 먼저 개방형 구조 테스터 제어 및 TOS 시스템 시동 절차에 대하여 기술한다.
또한, 개방형 구조 테스트 시스템 소프트웨어 "패치(patch)"의 공개(release)는, 더 포괄적인 소프트웨어 공개 중에 개방형 구조 테스트 시스템 소 프트웨어 컴포넌트를 수정하고 강화하는 필수적인 부분임을 주의하여야 한다. 이를 위해, 소프트웨어 패치 릴리스 단락에서, 개방형 구조 테스트 시스템 소프트웨어 패치 릴리스를 생성, 배포 및 이용함에 있어서 수반되는 방법들에 대하여 기술한다.
(테스터 제어 및 TOS 시동)
본 단락에서, 개방형 구조 테스터 제어 및 시동 절차에 대해 기술한다. 본 명세서의 독자는, 개방형 구조 테스터 구조의 기초에 대해 익숙한 자들, 특히, 나타내어진 바와 같이, 개방형 구조 테스트 시스템의 시스템 제어기(SysC)와 사이트 제어기(들)(SiteCs)를 포함하는 일반적인 분산 시스템으로서의 TOS의 체계에 대해 익숙한 자들이라고 가정한다.
(테스터 제어 데몬)
개방형 구조 테스트 시스템의 TOS에 대한 전반적인 제어는 상기 개방형 구조 테스트 시스템의 테스터 제어 데몬(Tester Control Daemon; TCD)에 의해 수행된다. 상기 TCD에 대한 상세한 설명은 아래와 같이 요약된다:
개방형 구조 테스트 시스템의 테스터 제어 데몬은 다음과 같은 기능들을 수행한다:
시스템 부트-업(boot-up)시에 또는 사용자 명령에 따라 개방형 구조 테스트 시스템의 TOS의 시동 및 초기화, 그리고 성공적인 시스템 초기화 후 사용자 정의의 개방형 구조 테스트 시스템 응용 프로그램의 선택적인 시동.
TOS 핵심 서비스에 접속된 개방형 구조 테스트 시스템 응용 프로그램의 종료(shutdown)를 포함하는, 사용자 명령에 따른 개방형 구조 테스트 시스템의 TOS의 종료.
시스템 프로파일에 의해 정의된 바와 같이, 개방형 구조 테스트 시스템에 대한 특정 소프트웨어 구성의 활성화 또는 배치. 여기서, "버전 스위치(version switch)"는 반드시 현재 유효하지 않은 프로파일의 활성화이다.
특정의 개방형 구조 테스트 시스템 소프트웨어 구성을 정의하기 위해 필요한 정보의 전체 집합인, 개방형 구조 테스트 시스템 소프트웨어 구성을 위한 시스템 프로파일(system profile)에 대해 이하 기술한다. 이하의 논의에 있어서, 테스터 제어 데몬은 윈도우즈(Windows) 운영 체제(operating system; OS)에서 사용되는 것을 말하지만, 그 개념은 일반적이고 어떠한 개방형 구조 테스트 시스템에 대하여도 응용될 수 있다.
윈도우즈 시스템에 있어서 TCD는 Win32 서비스(Win32 service)이고(그것은, 윈도우즈 제어 패널(Windows Control Panel)을 통해 이용 가능한 서비스 대화 상자(Services dialog box) 안에 설치된 서비스의 목록에서 보여진다.), 상기 Win32 서비스는 SysC 및 모든 SiteCs 상에 설치되어 자동으로 실행된다. 상기 기능들을 수행하기 위하여 (상기 시스템 제어기 측에서) 인터페이스 메소드(methods)를 제공하는 것은 COM 컴포넌트이다. 그것은 개방형 구조 테스트 시스템 소프트웨어(시스 템 통합 사업자(system integrator)에 의해 제조 과정에서 설치된(factory-installed) 온라인 버전)로부터 분리되어 설치되고, OS 부트(boot)시의 자동(automatic) 시동을 위해 윈도우즈 서비스 제어 관리자(Windows service control manager)에 등록된다. 주(main) TCD는 시스템 제어기에서 구동되는 것인 반면에, 부(auxiliary) TCD는 사이트 제어기들에서 구동되며, 개개의 사이트 제어기들을 브링-업(bring-up)하기 위해 상기 주 TCD의 지원하에서 작동하여야 함을 주의하여야 한다.
(TOS 제어 및 제조 디폴트 디렉터리)
상기 데몬이 설치되고 적절하게 기능하기 위해서, 모든 개방형 구조 테스트 시스템은 TOS 제어 컴포넌트(control components) 및 제조 디폴트(factory defaults) 정보를 수용하는 표준 디렉터리 구조와 함께 미리 설정된다. 이는 이하의 사양으로서 요약된다:
모든 개방형 구조 테스트 시스템의 시스템 제어기 및 사이트 제어기는, 유효(available)한 < MAINTENANCE _ ROOT > 위치에 루트(root)를 두고, 도 2a에서 도시되고 표 1에서 설명되는 바와 같은 구조를 갖는 TOS 제어 및 제조 디폴트 디렉터리 구조를 갖도록 설정된다.
표 1은 도 2a에서 도시된 구조에 대해 기술한다. 첫 번째 열에 있는 디렉터리들은 <MAINTENANCE_ROOT>에 관련되어 있음을 주의하여야 한다.
[표 1] TOS 제어 및 제조 디폴트 디렉터리 내용
디렉터리 설명
./ bin TCD 제어기 응용 프로그램 및 연관된 동적 링크 라이브러리(dynamic link libraries; DLLs)를 포함한다.
./ cfg 테스터에 대한 제조 디폴트 설정을 규정하는 구성 파일을 포함한다.
./ doc TCD 및 제조 디폴트 관련 문서(documentation)를 포함하는데, 이는 개별 문서(document)의 카테고리에 의해 서브 디렉터리로 분류될 수 있다.
./ logs TCD 설치자(installer)가 그것의 동작을 기록한 위치.
<MAINTENANCE_ROOT>/bin에 설치된 TCD 제어기 응용 프로그램(TCD controller application)은 "시작(start)", "정지(stop)", "활성화(activate)" 등과 같은, 기본적인 테스터 시스템 제어 명령들을 TCD에 보낼 수 있는 간단한 명령 라인(command-line) 응용 프로그램이 되도록 의도된다. 아도반테스토 T2000 시스템은 이러한 작업들을 수행하기 위해 응용 프로그램 t2kctrl을 수반한다.
<MAINTENANCE_ROOT>/cfg 디렉터리의 내용은 시스템 통합 사업자마다 다를 수 있는데, 각 경우에 있어서, 대응하는 TCD 또는 그것의 설치자가 기능하기 위해 필요한 테스터 정보를 포함한다. 예를 들면, 상기 아도반테스토 T2000 테스터 시스템은 <SystemDrive>:/T2000Maintenance/cfg에 이하의 정보를 위치시킨다. <SystemDrive>는 윈도우즈에 의해 미리 정의된 환경 변수로서, 디폴트로, Windows 2000에서는 "C:"가 됨을 주의하여야 한다.
특별한 개방형 구조 테스트 시스템 소프트웨어 활성화 프로세스가 그 임무를 수행하도록 하기 위해 필요한 상기 개방형 구조 테스트 시스템 사용자 계정 및 패스워드 정보와 함께, 제조 과정에서 제공되는 모든 사이트 제어기들의 내부 시스템 IP 명칭과 어드레스를 규정하는 (표준 윈도우즈 INI 파일 형식(standard Windows INI file format)으로 된) 사이트 제어기의 제조 구성(factory configuration). 이 파일은 OASISSiteInfo.ini로 명명된다.
온라인 시스템에서 사용자는 이 파일을 수정할 수 없다. 오프라인 시스템에 대해서, 사용자는 만약 요구된다면, 이 파일을 (단일 SiteC를 상기 SysC와 동일한 장치상에 지정하는) 디폴트(default)로부터 수정할 수 있다. 온라인과 오프라인 모두에서 사용되는 시스템에 대해서는, 온라인 모드(mode)는 원래의(original) 온라인 제조 구성 파일(또는, 하드웨어 레이아웃에 있어서의 변경을 반영하기 위해 제조 과정에서 권한이 주어진(factory-authorized) 전문가에 의해 가장 최근에 갱신(update)된 파일)을 사용하여야 한다.
제조 디폴트 사양(factory defaults specification; FDEF) 파일은,
타입(type), 명칭(name), 작동 주파수(operating frequency) 등과 같은 전체적인 테스터 속성에 관한 정보,
제조 과정에서 구성된(factory configured) 하드웨어 모듈 및 그들의 보드에 특유한(board-specific) 세부 사항에 관한 정보,
상기 하드웨어 모듈이 접속되는, 제조 과정에서 구성된 개방형 구조 테스트 시스템 모듈 접속 인에이블러(module connection enabler; MCE) 포트(ports)에 관한 정보,
(만약 존재한다면) 각 하드웨어 모듈로의 상기 개방형 구조 테스트 시스템 동기화 행렬(synchronization matrix) 접속에 관한 정보, 및
상기 하드웨어 모듈에 대한 테스트 헤드 접속에 관한 정보를 포함한 다.
온라인 시스템에서 사용자는 이 파일을 수정할 수 없다 - 수정은, 상기 장치(machine)의 물리적인 구성을 변경하는, 권한이 주어진 유지 관리자(maintenance personnel)에 의하여만 이루어질 수 있다. 오프라인 시스템에 대하여, 제조 디폴트 사양 파일은, 제공되는 테스트 예가 존재하는 경우 상기 테스트 예와 호환 가능한 가상 머신(virtual machine) 구성을 정의하고, 사용자는, 만약 요구된다면, 이를 변경하여 그 또는 그녀 고유의 가상 테스터를 설정할 수 있다. 온라인과 오프라인 모두에서 사용되는 시스템에 대해서는, 온라인 모드는 원래의(original) 온라인 제조 구성 파일(또는 하드웨어 레이아웃에 있어서의 변경을 반영하기 위해 제조 과정에서 권한이 주어진 전문가에 의해 가장 최근에 갱신된 파일)을 사용해야 한다.
(테스터 상태 및 상태 전이)
상기한 바와 같이, TCD는 개방형 구조 테스트 시스템의 TOS를 시작하는 것을 담당한다. TOS 브링-업의 메커니즘(mechanism)을 이해하기 위해서는, 우선 상기 TOS가 될 수 있는 상태들(states) 및 그들 사이에 허용되는 전이(transitions)를 이해할 필요가 있다. 개방형 구조 테스터에 대한 상태 전이 다이어그램(state transition diagram)은 도 2b에서 도시된다.
도 2b에 있어서 상태의 의미는 다음과 같다:
상태 0: 테스터 시스템은 정지한 상태이다: 시스템 제어기 상의 TCD가 작동 하고 있지 아니하며, TOS가 작동하고 있지 않다.
상태 1: TCD는 적어도 시스템 제어기에서 작동하고 있다; 그러나 TOS는 아직 기능하지 않는다.
상태 2: 개방형 구조 테스트 시스템의 시스템 제어기 프로세스가 작동하고 있지만, 아직 초기화되지는 않았다; TCD들은 모든 사이트 제어기에서 작동하고 있을 수도 있고, 그렇지 않을 수도 있다; 오프라인 모드에서, 개방형 구조 테스트 시스템의 테스터 에뮬레이터(tester emulator) 프로세스가 아직 작동하지 있지 않다.
상태 3': (오프라인 모드에서만) 개방형 구조 테스트 시스템의 테스터 에뮬레이터가 (지정된 단일의) 사이트 제어기 컴퓨터에서 작동하고 있다.
상태 3: 적어도 사이트 제어기 1(SITEC-1)이 성공적으로 초기화되었고, 시스템은 디폴트 구획된(default partitioned) 상태에 있다(즉, 모든 하드웨어 모듈이, 상기 MCE를 통해, SITEC-1에 접속되어 있다); 추가적으로, 모든 지정된 사이트 제어기가 또한 성공적으로 초기화되었을 수 있다. 이 때, 상기 시스템은 "준비(ready)", 즉, 테스트 계획(test plan) 로드(load) 요구를 수용하도록 설정된다.
상태 4: 테스트 계획 요건을 만족시키기 위해 (재)구획되었을 수 있는 상기 시스템의 일부로서, 사용자 테스트 계획이 하나 또는 그 이상의 호환 가능한 사이트 제어기에 성공적으로 로드되었다.
도 2b에 도시된 상태 전이를 일으키는 이벤트에 대해 이하 설명한다. 여기서, "t(x, y)"라는 표기는 상태 x로부터 상태 y로의 전이를 나타낸다(이하 언급되 는 클라이언트(client)는 시스템 제어기 TCD의 클라이언트이고, 원격 또는 로컬의, 상기 TCD에서 적절한 인터페이스에 접속하고 이를 이용하는 응용 프로그램이 될 수 있음을 주의하여야 한다.):
t(0, 0) 윈도우즈 부트 프로세스로부터 명령(또는 쌍방향의, 수동 "시작" 요구)을 받고서, 윈도우즈 서비스 제어 관리자는 윈도우즈 부트-업 동안 시스템 제어기에서 TCD를 시작하는 것에 실패한다.
t(0, 1) 윈도우즈 부트 프로세스로부터 명령(또는 쌍방향의, 수동 "시작" 요구)을 받고서, 윈도우즈 서비스 제어 관리자는 시스템 제어기에서, 그리고 가능하다면 사이트 제어기들에서 TCD를 성공적으로 시작한다.
t(1, 1) TOS를 "시작(start)"하라는 클라이언트 명령을 받고서, 시스템 제어기상의 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 시스템 제어기 프로세스가 TOS 사이트 제어기 프로세스를 적어도 SITEC-1에서 (그리고 가능하다면 지정된 모든 사이트 제어기에서) 성공적으로 시작하고 초기화한다.
t(3, 3) 사용자 테스트 계획을 로드(load)하라는 사용자 명령을 받고서, TOS가 규정된 테스트 계획을 로드하는 것에 실패한다.
t(3, 4) 테스트 계획을 로드하라는 사용자 명령을 받고서, TOS가 (만약 필요하다면) 규정된 테스트 계획과 연관되는 소켓(socket)의 요구 사항에 따라서 시스템을 성공적으로 (재)구획한 후, 지정된 사이트 제어기(들)에서 상기 테스트 계획을 성공적으로 로드한다.
t(4, 4) (동일한 또는 별개의) 테스트 계획을 (리)로드((re)load)하라는 사용자 명령을 받고서, TOS가 (만약 필요하다면) 규정된 테스트 계획과 연관되는 소켓의 요구 사항에 따라서 시스템을 성공적으로 (재)구획한 후, 지정된 사이트 제어기(들)에서 상기 테스트 계획을 성공적으로 (리)로드한다.
t(3, 1) TOS를 종료(shutdown)하라는 사용자 명령을 받고서, TCD는 TOS를 정지시킨다.
t(4, 1) TOS를 종료하라는 사용자 명령을 받고서, TCD가, 만약 실행되고 있는 테스트 계획이 존재한다면 상기 계획을 정지한 후 TOS를 정지시킨다.
전이를 나타내는 * 는 사용자로부터 규정된( user - specified ) 응용 프로그램을 시작하려고 시도하면서 TOS 시스템 제어기 프로세스와 함께 진행되는데; 응용 프로그램은 TOS 의 일부가 아니므로, 어떤 또는 모든 이러한 응용 프로그램의 시작이 실패하더라도 성공적인 TOS 초기화가 실패하지는 아니함을 주의하여야 한다.
상기한 전이 외에도, 시스템 제어기에서 실행되는 윈도우즈 "종료" 명령(또는 물리적으로 시스템의 전원을 끄는 것(power-down))은, 테스터가 그 당시에 속한 상태에 무관하게, 상기 테스터를 상태 0으로 재설정(reset)한다.
(TOS 시동 프로세스)
개방형 구조 테스트 시스템의 TOS가 브링-업(bring-up) 되는 프로세스는 다음과 같다(환경 변수 OASIS_INSTALLATION_ROOT, OASIS_ACTIVE_CONFIGS, OASIS_TOS_SETUP_FILE, OASIS_TPL_SETUP_FILE, OASIS_TOOLS_SETUP_FILE, OASIS_MACHINE_DIR, 및, OASIS_TEMP은 이미 올바르게 정의되어 있고, 시스템 프로파일이 선택되어 있다고 가정한다.):
1. 시스템에 전원이 들어왔을 때(power-on)(또는, 부트-업), 윈도우즈 서비스 제어 관리자가 상기 시스템 및 사이트 제어기들에서 TCD를 시작한다.
2. 시스템 제어기 상의 TCD는 시스템 프로파일이 유효함을 검증하고, 사이트 제어기의 프로파일로부터 규정된(profile-specified) 구성 - 즉, $OASIS_ACTIVE_CONFIGS/OASISSys.cfg 파일 - 을 읽고, TOS 시스템 제어기 프로세스를 시작한다.
3. 그 후 상기 TCD는 initialize () 메소드(method)를 상기 TOS 시스템 제어기 프로세스 상에서 호출하는데, 이로써 이하의 동작이 진행된다.
a. 동작 모드가 오프라인(offline)인 경우에 한하여, (지정된 단일의) 사이트 제어기 컴퓨터에서 테스터 에뮬레이터 프로세스가 시작된다;
b. 각 사이트 제어기 상의 TCD가 그것의 TOS 사이트 제어기 프로세스를 시작하도록 요구된다;
c. initialize () 메소드가 각 TOS 사이트 제어기 프로세스에서 호출된다; 그리고
d. 적어도 SITEC-1이 성공적으로 초기화된 후에, 시스템이 디폴트 구획된다(default partitioned)(여기서, 모든 하드웨어 모듈이, MCE를 통해, SITEC-1에 접속된다).
4. 그 후 상기 TCD는, 규정된 순서로, 현재 활성화된 프로파일 내에 자동 시동을 위해 목록에 올려진 사용자 응용 프로그램을 시작하도록 시도한다.
단계 0 0 동안의 실패는, 상기한 바와 같이, 대응하는 시스템 상태 전이가 일어나게 한다. 단계 0 또는 0에서의 실패는 시스템 이벤트 로그에 기록된다. 단계 0에서의 실패는 TOS 시스템 제어기 프로세스와 함께 기록되고, 그것에 접속하는 클라이언트 응용 프로그램에 의한 이후의 검색(retrieval)을 위해 이용될 수 있다.
선택적인 자동 응용 프로그램 시동
상기한 바와 같이, 개방형 구조 테스트 시스템은 사용자가 성공적인 TOS 시동에 이어서 자동으로 시작되어야 하는 응용 프로그램을 추가하는 것을 고려한다. OCTool이 사용자들로 하여금 시스템 프로파일의 일부로서 그러한 응용 프로그램에 대한 그들의 선택을 규정할 수 있도록 한다. 특정 테스터에서 그러한 프로파일이 활성화되는(activated) 때(즉, 상기 프로파일에 의해 규정된 구성이 현재 사용되도록 된 경우), 상기 단계 0은 성공적인 TOS 초기화가 완료된 때 실행된다.
이를 위해, TCD는 OASISVer.cfg 파일의 시동 단락(Startup section)을 읽어들이는데, 상기 파일은 선택된 시스템 프로파일의 속성을 규정하는 데이터 파일이고, 표준 윈도우즈 INI 파일 형식으로 되어 있다. 그것은 새로운 응용 프로그램을 시작하기 위해 상기 단락 내에 있는 각각의 줄(line)을 명령 라인(command-line)으로 취급한다. 응용 프로그램들은 TOS의 일부가 아니므로, 목록에 올려진 어떤 또는 모든 응용 프로그램의 시작이 실패함으로 인해, TOS 브링-업이 실패하는 경우와 같은 정도의 오류 상태가 야기되지는 아니한다. 그러나, 그러한 실패는 주목되고, (응용 프로그램에 의한 이후의 검색을 위해) TOS 시스템 제어기 프로세스에 저장된다.
설치(Installation)
개방형 구조 테스트 시스템에 대한 설치(Installation)는 세 가지의 메인 컴포넌트의 설치로 이루어지는데, 각 컴포넌트는 독립적으로 설치된다:
1. 개방형 구조 테스트 시스템의 테스터 제어 데몬(Tester Control Daemon; TCD, 이는 개방형 구조 테스트 시스템 소프트웨어 활성화 또는 배치의 기능성을 캡슐화(encapsulate)한다).
2. 개방형 구조 테스트 시스템의 구성 도구(OCTool).
3. 개방형 구조 테스트 시스템의 시스템 소프트웨어.
이 단락에서, 설치 프로세스는 상기 컴포넌트들의 각각에 대하여 기술된다.
(TCD 설치)
개방형 구조 테스트 시스템의 TCD 패키지(package)는 다른 개방형 구조 테스트 시스템 컴포넌트와는 독립하여 설치된다. 제조 과정으로부터 신착된(factory-fresh) 온라인 시스템에 있어서, TCD 패키지는 대체로 미리 설치될 수 있다. 일반적인 오프라인 시스템 및 TCD에 대한 갱신(update)을 위해, 설치자(installer)가 시스템 통합 사업자에 의해 제공될 수 있다.
윈도우즈에 있어서, 개방형 구조 테스트 시스템의 <MAINTENANCE_ROOT>는 보통의 윈도우즈의 <SystemDrive> (종종 "C:" 드라이브)에서의 디렉터리로 자연히 변환되는데, 이는 <SystemDrive>의 존재가 보증되기 때문이다. 예를 들면, 개방형 구조 테스트 시스템인 아도반테스토 T2000의 구현은 상기 시스템 및 사이트 제어기들에서 "C:/T2000Maintenance" 디렉터리에 루트를 둔다. 이하, <SystemDrive>는 "C:"임을 가정한다. 상기 TCD 패키지가 설치되는 동안의 단계는 다음과 같다:
1. 상기한 바와 같이, <MAINTENANCE_ROOT>가 SysC 및 SiteCs에 존재하는데, 이는 몇몇의 컴포넌트가 <MAINTENANCE_ROOT>에 설치되기 때문이다.
a. 만약 <MAINTENANCE_ROOT>가 존재하지 않으면, TCD 설치자는 그것을 생성한다.
b. 만약 사이트 제어기 제조 구성 파일(아도반테스토 T2000 시스템에서는 C:/T2000Maintenance/cfg/OASISSiteInfo.ini)이 존재하지 않으면, 상기 설치자는 또한, 설치를 수행하는 자로부터의 입력을 기초로, 그것을 생성한다.
c. 만약 개방형 구조 테스트 시스템 제조 디폴트 사양(FDEF) 파일(아도반테스토 T2000 시스템에서는 C:/T2000Maintenance/cfg/OASISHW.def)이 존재하면,
i. 온라인(online) 시스템에 대하여는, 어떠한 방법으로도 그것은 대체되거나 변경되지 아니한다.
ii. 오프라인 시스템에 대하여, 개방형 구조 테스트 시스템에 제공되는 예(examples)와 호환 가능한 가상 테스터를 모델링하기 위한, <FDEF- name>.<example>로 명명된, 미리 패키지화된 버전을, <MAINTENANCE_ROOT>/cfg로 복사하고, 사용자에게 (만약, 사용자가 상기 개방형 구조 테스트 시스템 예를 사용하여 작업할 것을 원한다면) 기존의 FDEF 파일을 이것으로 대체할 것인지를 확인한다.
d. 만약 FDEF 파일이 존재하지 않으면,
i. 온라인 시스템에 대하여, 표본(sample) FDEF 파일을 설치하고, 사용자에게 설치된 그의 하드웨어와 호환 가능하도록 하기 위해 그것을 갱신하도록 경고한다.
ii. 오프라인 시스템에 대하여, 당해 파일의 미리 패키지화된 버전을 FDEF 파일로서 (개방형 구조 테스트 시스템에 의해 요구되는 것과 같은 표준 이름으로) 설치한다.
2. 상기 설치자는 <SystemRoot>/system32에 TCD 바이너리(binaries)를 설치하고, 요구되는 COM 컴포넌트 등록을 위해 윈도우즈 레지스트리 엔트리(Windows registry entries)를 설정한다.
3. 상기 설치자는 이하의 구성 속성(configuration properties)을 TCD에 대해 설정한다:
a. 자동 시작(AutoStart) : 이는 윈도우즈 시스템 부트가 SysC TCD로 하여금 개방형 구조 테스트 시스템의 TOS를 자동으로 시작하도록 하는지(TRUE), 아닌지(FALSE)를 규정한다. 디폴트는 TRUE이고, 설치를 수행하는 자는 만약 요구된다면 그것을 FALSE로 설정할 수 있다.
b. 모드(Mode) : 이는 TOS가 (온라인 모드가 이용가능하다면) 동작의 온라인 모드에서 시작되어야 하는지, 아니면 오프라인 모드에서 시작되어야 하는지를 규정한다. 디폴트는 온라인이고, 설치를 수행하는 자는 만약 요구된다면 그것을 오프라인으로 설정할 수 있다.
c. 구성(Configuration) : 이는 TOS가 컴포넌트의 디버그(DEBUG) 버전과 함께 시작되어야 하는지 아니면 릴리스(RELEASE) 버전과 함께 시작되어야 하는지를 규정한다. 디폴트는 릴리스이고, 설치를 수행하는 자는 만약 요구된다면 그것을 디버그로 설정할 수 있다.
4. 설치자는 TCD 제어기 응용 프로그램(t2kctrl) 및 그것과 연관된 DLL들을 <MAINTENANCE_ROOT>/bin에 설치한다.
5. 개방형 구조 테스트 시스템에 의해 요구되는 이하의 운영 체제 환경 변수들의 각각에 대하여, 설치자는 (i) 그것이 이미 설정되었는지 여부를 판단하고, (ii) 설정되지 않았다면, 그것을 사용자로부터 규정된(user-specified) 값으로 설정한다:
a. OASIS_INSTALLATION_ROOT
b. OASIS_ACTIVE_CONFIGS
c. OASIS_MACHINE_DIR
d. OASIS_TEMP
6. 설치자는 <MAINTENANCE_ROOT>/bin 및 $OASIS_INSTALLATION_ROOT/bin을 윈도우즈 시스템 경로(PATH) 환경 변수에 추가한다(윈도우즈 규준(Windows convention)에 따라, <SystemRoot>/system32는 이미 시스템 경로 환경 변수에 있다고 가정한다).
상기 단계 0에서 보여진 바와 같이, TCD와 그것이 의존하는 DLL은, 윈도우즈의 <SystemRoot>/system32 디렉터리 (이 디렉터리는, 윈도우즈 2000에서 <SystemDrive>/WINNT/system32 - 대부분의 경우, C:/WINNT/system32 - 가 됨)에 설치되는데, 이는 상기 위치가 윈도우즈 서비스(Windows service)의 적절한 동작을 보증하기 때문임을 주의하여야 한다. 게다가, <MAINTENANCE_ROOT>는 시스템이 올바르게 기능하기 위하여 상기 시스템과 사이트 제어기들 상에 존재할 필요가 있다. 따라서, <MAINTENANCE_ROOT> (및, <SystemRoot>/system32에 있는 TCD 및 그에 관련된 DLL들)는, 만약 이러한 컴포넌트가 존재하는 로컬 디스크를 다시 포맷하기를 원한다면, 주의를 기울여 백업 및 저장되어야 한다. 개방형 구조 테스터에서의 어떤 시스템 프로파일의 활성화는 상기 테스터에 설치되어 이용 가능한 TCD에 의존한다. TCD는 반드시 개방형 구조 테스트 시스템 소프트웨어에 대해 독립적이므로, 개방형 구조 테스트 시스템 소프트웨어의 모든 릴리스와 하위호환 가능하도록 요구된다(required to be backward - compatible).
(OCTool 설치)
개방형 구조 테스트 시스템 구성 도구인 OCTool은, 개방형 구조 테스트 시스템 소프트웨어로부터 분리된 패키지에 분산되어 설치된다.
OCTool에 대한 설치자는 사용자로 하여금 상기 OCTool에 대한 설치 위치를 선택할 수 있도록 한다. 상기 OCTool은 사용자로 하여금 개방형 구조 테스트 시스템의 테스터에 독립적인(tester - independent) 시스템 프로파일(system profiles)을 생성하고 저장할 수 있도록 한다. 그리하여, 그것이 개방형 구조 테스트 시스템 소프트웨어가 설치된 아카이브(archive) 위치에 접근할 수 있는 한, 개념적으로 그것을 테스터로부터 원격인 위치에 설치할 수 있다. 그러나, 현재 활성화된 시스템의 루트인 $OASIS_INSTALLATION_ROOT에 루트를 둔 디렉터리 트리(tree) 내에 놓여진 위치에 그것을 설치하지 않으면, 그것이 그 후에 다른(different) 프로파일에 대응하는 시스템의 활성화로 인해 상실될 수 있으므로, 주의를 필요로 한다.
TCD와 같이, OCTool은 반드시 개방형 구조 테스트 시스템 소프트웨어에 대해 독립적이므로, 개방형 구조 테스트 시스템 소프트웨어의 모든 릴리스와 하위호환 가능(backward - compatible)할 필요가 있다.
(개방형 구조 테스트 시스템 소프트웨어 설치)
개방형 구조 테스트 시스템 소프트웨어의 설치(Installation)란 개방형 구조 테스트 시스템 소프트웨어 컴포넌트(결국, 파일)들을 운영 체제 환경 변수인 OASIS_ARCHIVE_ROOT에 의해 정의되는 위치에 물리적으로 복사하는 활동을 나타낸다. 당해 위치는 이하 아카이브(archive)라고 한다. 아카이브는 시스템의 사용자를 위하여 개방형 구조 테스트 시스템의 벤더들과 시스템 통합 사업자가 제공하는 파일들을 포함한다. 이는 배치(deployment) 또는 런타임(runtime) 위치와는 구분 됨을 주의하여야 한다. 배치 위치와는 반대로, 아카이브 위치는, 소프트웨어가 배치된(deployed) 테스터 시스템에서 작동하는 TCD에 의해 접근될 수 있는 한, 물리적으로 상기 테스터 시스템으로부터 원격일 수 있다.
설치 프로세스는 TOS 및 벤더 컴포넌트에 대한 것과 동일하다. 각각의 설치된 파일은 컴포넌트 구성 기록(Component Configuration Record; CCR)을 갖는데, 이는 각 컴포넌트의 속성(property)들을 규정한다. 따라서, 이하의 두 가지의 요구 사항(requirements)을 통해 설치 프로세스의 사양(specification)을 요약한다:
개방형 구조 테스트 시스템 소프트웨어 설치는 파일들을 정의된 아카이브 위치에 복사한다. 이 위치는 환경 변수 OASIS_ARCHIVE_ROOT에 의해 규정된다.
상기 아카이브에 설치된 각각의 파일은 컴포넌트 구성 기록, 즉 CCR을 수반하는데, 상기 CCR은 상기 파일에 대하여 필요한 기술적인(descriptive) 정보를 포함한다.
따라서, 상기 TOS 및 벤더 파일들은 공통의 루트 아래에 존재한다. 당해 파일들이 시스템 프로파일(profiles)을 통해 관리되기 위해서, 그들은 개방형 구조 테스트 시스템의 파일 명명 요건을 따른다. 이러한 요건을 따름으로써, 상기 시스템에서의 파일들이 관리를 위한 단일 아카이브 디렉터리(single archive directory)에 축적될 수 있다. 이는 TOS 및 벤더의 설치된 파일 양쪽 다에 적용된다. 이러한 요건은 이하에 논의된다.
파일 명명 요건
버전 관리, 스위칭, 및 감사를 가능하도록 하기 위해, 개방형 구조 테스트 시스템에 설치되어야 하는 각 컴포넌트(즉, 각 파일)는, 이하의 파일 명명 형식을 사용하는데, 이는 파일의 이름이, 동일한 또는 상이한 벤더로부터의, 설치된 다른 컴포넌트의 이름과 충돌하는 것을 막는다:
TOS 및 벤더 컴포넌트는 이하의 명명 형식을 사용한다:
VendorID_ComponentName_[D_]VersionIdentifier[.ext].
상기 형식에 대한 기술은 아래와 같다. 여기서, 대괄호([]) 안에 있는 요소들은 선택적인 항목임을 나타낸다:
1. VendorID : 2-3글자의 벤더 식별(vendor identification) 코드. 이 코드는 당해 컴포넌트를 TOS 또는 벤더에 특유한 컴포넌트로서 구분짓고, 파일들을 명확하게 한다. 시스템으로 도입되는 파일들을 관리하는 것은 각 벤더들의 책임임을 주의하여야 한다. 첫번째 글자는 알파벳 등의 문자와 숫자를 조합한 것(alphanumeric)이어야 하며, 밑줄(underscore character)은 될 수 없다. TOS 런타임 컴포넌트는 "OAI"를 식별자(identifier)로서 사용한다. 상기 VenderID 부분 뒤에 밑줄 '_' 가 이어진다.
2. ComponentName : 컴포넌트 공급자에 의해 선택된 것으로서 임의의 명칭. ComponentName 부분 뒤에 밑줄 '_'가 이어진다.
3. D : 이는 선택적이며, 실행 파일(executable) 컴포넌트에 적용될 수 있 다. 그러한 컴포넌트에 대하여, 당해 컴포넌트가 디버그(debug) 동적 링크 라이브러리(dynamic link library; DLL) 또는 실행 파일(EXE)을 나타내는 경우에만, ComponentName 뒤에 'D'가 이어진다. 'D'가 없다는 것은 당해 컴포넌트가 논-디버그(non - debug) 버전(즉, "릴리스(release)" 버전)임을 의미한다. 만약 있다면, 'D' 부분 뒤에 밑줄 '_'가 이어진다.
4. VersionIdentifier : 시스템에 도입된 모든 파일들의 명시적인 버전화(versioning)는 기본적인 요건이다. 다른 운영 체제에 걸쳐서 호환 가능하기 위해서, 상기 버전화는 파일 명칭의 일부, 즉 VersionIdentifier 필드(field)로서 표시된다. 이 필드는 다음과 같은 형식을 갖는다:
major.minor.patch
여기서 각 major, minor, 및 patch는 음수가 아닌 정수 값을 갖고, 각각 컴포넌트의 메이저(major), 마이너(minor), 그리고 패치(patch) 버전을 나타낸다.
5. ext : 확장자는 .dll, .exe, .txt, .doc 등과 같은 (선택적인) OS에 특유한(OS-specific) 식별 보조자이다.
모든 경우에서, 파일들의 이름은 지원되는 모든 플랫폼(윈도우즈, 리눅스 등)에서 적법함을 주의하여야 한다. 몇 가지 예를 들자면 다음과 같다:
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에 도시되고 이하에 기술되는 바와 같다. 이하의 논의에 있어서, 소프트웨어 개발 키트(software development kit)는 종종 간략히 "SDK"라고 한다. 또한, "$ foo"라는 표기는 운영 체제 환경 변수 foo의 값(value)을 나타낸다. 설치 프로세스는 다음과 같다:
모든 개방형 구조 테스트 시스템 소프트웨어 컴포넌트 파일은 도 3, 도 4 및 도 5에 도시되고 표 4에 기술된 바와 같이 $ OASIS _ ARCHIVE _ ROOT 아래 적절한 위치에 설치된다.
설치 (즉, 아카이브) 위치는, 당해 테스트 시스템상에서 TOS가 활성화되기를 원하는 테스터 시스템으로부터 접근될 수 있다.
도 3, 도 4 및 도 5에 있어서, OAI로 명명된 디렉터리들은 개방형 구조 테스트 시스템의 TOS 파일을 포함하는데, 여기서 <vendor>로 명명된 디렉터리는 벤더에 특유한(vendor-specific) 파일을 포함한다. 각 벤더는 고유한 2-3 글자의 식별자(예를 들면, 아도반테스토 벤더 디렉터리는 AT로 이름이 붙여진다)를 나타내는 <vendor>와 함께, 그 자신의 디렉터리를 갖는다. 각각의 벤더에 특유한 디렉터리 내에서, 벤더들은 그들의 파일명이 고유하다는 것을 확인할 책임이 있음을 주의하여야 한다. 또한 파일명에 있어서 명시적인 버전 식별자의 요건을 통해 같은 컴포 넌트의 다른 버전이 같은 위치에 저장될 수 있음을 주의하여야 한다.
나아가 표 2는 상기 도면들에서 약술된 디렉터리 구조를 설명하는데, 첫번째 열에 있는 각 디렉터리는 $OASIS_ARCHIVE_ROOT에 관련된다.
[표 2] 개방형 구조 테스트 시스템 설치 디렉터리 구조
디렉터리 설명
./ bin 실행 파일들(DLLs 및 EXEs)을 저장하는 서브 디렉터리 OAI, <vendor> 및 sys를 포함한다. 상기 sys 서브 디렉터리는, TOS가 필요로 하는 msvcrt70.dll, mfc70.dll 등과 같은 시스템에 특유한 또는 제3자 DLL들을 포함한다.
./ CDB (만약 사용자가 희망한다면) 아카이브 내에 존재하는 모든 CCR들간의 관련성을 보존하는, 개방형 구조 테스트 시스템 컴포넌트 데이터베이스(Component Database)를 저장할 수 있다.
./ cfg 시스템 TOS 또는 벤더 컴포넌트에 의해 사용되는 구성 파일들, 또는 시스템 및 벤더 도구들(tools)을 포함하는데, 후자는 도구에 특유한(tools-specific) ( < tool > ) 서브 디렉터리로 체계화된다. 공통의( common ) 서브 디렉터리는 상기 TOS 및 하나 이상의 벤더의 컴포넌트에 걸쳐서 공유되어야 하는 구성 정보를 두기 위해 벤더들에 의해 사용되기 위한 것이다.
./ doc 개별 문서의 카테고리에 의해 디렉터리 내로 분류되는 문서(documentation)를 포함한다.
./ InstallCCR 원래의(original) CCR이 파일 설치시에 저장되는 위치.
./ logs 설치자가 파일을 아카이브 내로 로딩할 때 그 동작을 기록하는 위치.
./ profiles 프로파일(profiles)을 저장하는 위치. 각 프로파일의 내용은 개별적인, (< profileX >로 나타내어지는) 명명된 디렉터리에 저장된다.
./{ User , Vendor } SDK / bin 도구, 유틸리티, 보조 응용 프로그램 등과 같은 SDK 실행 파일을 포함한다.
./{ User , Vendor } SDK / doc 개별 문서의 카테고리에 의해 디렉터리 내로 분류되는 SDK 문서를 포함한다. 베이스 디렉터리(base directory)는 상기 베이스 디렉터리 아래에 있는 모든 HTML 기반의 문서에 대해서 최상위 수준의(top-level) 색인(index)으로서 기능하는 index.html 파일을 포함하는데, 상기 문서는 < html - dirs > 에서 주제(topic)에 의해 체계화된다.
./{ User , Vendor } SDK / examples SDK 예들을 저장하는 위치.
./{ User , Vendor } SDK / inc 인클루드(include) 파일을 저장하는 위치.
./ UserSDK / inc / STL C++ 표준 템플릿 라이브러리(Standard Template Library; STL) 파일 계층을 저장하는 위치.
디렉터리 설명
./{ User , Vendor } SDK / lib 라이브러리 파일을 저장하는 위치.
./ UserSDK / templates 사용자 SDK가 필요로 하는 템플릿 파일을 저장하는 위치. OAI/OTPL 서브 디렉터리는 개방형 구조 테스트 프로그래밍 언어(open architecture test programming language; OTPL) 컴파일러인 occ가 그 동작을 위해 사용하는 템플릿을 저장하기 위해 사용되다.
./ UserSDK / TestClasses 개방형 구조 테스트 시스템의 테스트 클래스들(test classes)을 저장하는 위치.
설치 로그
디렉터리 로그(log)는 서브 디렉터리 설치자를 포함한다. 당해 위치는 다음의 사양을 지원한다:
개방형 구조 테스트 시스템 소프트웨어에 대한 설치자가 잘 알려진 위치, 즉 $ OASIS _ ARCHIVE _ ROOT / logs / Installer 에 설치 로그를 생성한다.
TOS 설치 로그 파일을 위해 사용되는 명명 규약(naming convention)은 OAI_<version>.log이다. 벤더 설치자는 < vendor >_< vendor >.log 명명 규약을 사용한다. 나아가, 이들의 요건은 다음과 같다:
설치 로그는, 아카이브에 복사된 각각의 그리고 모든 파일의 충분히 권한이 주어진(fully qualified) 경로를 명시적으로 보여주는, 텍스트 파일이다.
만약, 설치자가 컴포넌트를 추가 또는 삭제하기 위해 수차례 실행되면, 설치 로그는 아카이브로부터 복사 또는 삭제된 파일들의 현재 상태를 보여주기 위해 갱신된다.
새로운 컴포넌트 버전 설치
컴포넌트의 새로운 버전이 공개된 때, 컴포넌트 공급자(TOS 또는 벤더)는 상기 새로운 컴포넌트 버전을 위한 CCR을 제공한다. 컴포넌트 구성 요소의 파일명은 상기 파일 명명 요건 단락에서 기술된 바와 같이 상기 컴포넌트의 새로운 버전을 반영하고, 파일 명명 규칙에 따라 기존의 파일을 덮어쓰는(overwrite) 것이 금지된다. 따라서, 컴포넌트 파일 버전은 아카이브 디렉터리 내에 계속하여 축적된다.
(이하 기술되는 릴리스 그룹 CCR들(release group CCRs) 중의 하나, 또는 벤더 직접 공개(direct vendor release)를 위한 벤더 제공의(vendor-provided) 릴리스 CCR에 의해 나타나는 바와 같은) 설치 패키지는 현재 공개된 컴포넌트의 버전을 수정하거나 강화하기 위하여 개개의 컴포넌트를 포함할 수 있음을 주의하여야 한다. 기존의 컴포넌트의 새로운 버전은 기존의 컴포넌트/파일을 대신하지 않으므로, 이미 존재하는 시스템 프로파일은 여전히 작동할 수 있다. 컴포넌트를 위한 패치(patch)에 대한 이하의 요건을 주의하여야 한다:
(상기 major . minor . patch의 세 가지의 버전 식별자 중 패치 컴포넌트에 있어서의 변경에 의해 나타나는 바와 같이) 새로운 패치가 이용 가능하게 된 때, 상기 패치는 TOS 릴리스의 메이저(major)/마이너(minor) 버전과 호환 가능하다.
그러한 "패치(patch)"에 대한 상세한 메커니즘은 이하 릴리스 그룹 CCRs 및 사용자의 시스템 프로파일이 기술된 후에 제공된다.
구성(Configuration)
구성(Configuration)은 개방형 구조 테스트 시스템 소프트웨어 구성을 시스템 프로파일로서 생성, 저장, 및 수정하기 위해, 사용자로 하여금 ICM 시스템과 상호작용할 수 있도록 하는 활동을 나타내는데, 상기 시스템 프로파일은 이후 특정 테스터 시스템에서 특정한 구성의 활성화를 위해 사용된다. 본 단락은 이러한 기능을 수행하기 위해 ICM에 의해 제공되는 메커니즘에 대해 기술한다.
(컴포넌트 및 구성 기록)
개방형 구조 테스트 시스템에 있어서, 컴포넌트(component)란 상기 시스템에서 별개의 모듈을 의미하는 하나 또는 그 이상의 파일, 환경 설정 등이다. 시스템 컴포넌트의 중요한 카테고리는 제1 컴포넌트(Primary components)로서 간주되는 시스템 하드웨어 모듈의 소프트웨어 표시이다. 컴포넌트의 또 다른 카테고리는, 예를 들면, SDK에 대한 인터페이스 정의 파일이다.
단일 컴포넌트 CCRs ( Single Component CCRs )
상기한 바와 같이, 아카이브에 설치된 각각의 개방형 구조 테스트 시스템 소프트웨어 컴포넌트 파일은 당해 파일의 속성을 규정하는 컴포넌트 구성 기록(Component Configuration Record; CCR)을 수반한다. 따라서, 그 구성이 제어되는 TOS 또는 벤더 파일은, 그들이 아카이브 내에 설치될 때 CCR과 연관된다. CCR은 아카이브 내에 설치된 파일에 대한 설명으로, 상기 파일에 대한 정보, 버전 번 호, 연관된 컴포넌트, 종속된 요소들, 비호환성 등을 포함한다. CCR은 OCTool에의 입력으로서 기능하는데, 이는 사용자로 하여금 테스트 시스템에 설치된 모든 컴포넌트를 보고(view), 제어하고(control), 추적하고(track), 관리(manage)할 수 있도록 한다. CCR에 대한 명명 요건은, .ccr의 필수적인 추가 확장(mandatory additional extension)이 요구되는 경우를 제외하고는, 상기 CCR에 의해 설명되는 대응하는 시스템 파일에 대한 명명 요건과 동일하다. 따라서, AT_PinModule_0.5.1.dll 파일에 대한 CCR은 AT_PinModule_0.5.1.dll.ccr로 명명된다. 설치된 CCR은 설치에 대한 원래의 참조로서 변경되지 않은 채 <OASIS_ARCHIVE_ROOT>/InstallCCRs 내에 그대로 유지됨을 주의하여야 한다. CCR 파일은 컴포넌트 파일과 동일하되, InstallCCR 디렉터리에 관련된 디렉터리 위치에(컴포넌트 파일은 아카이브 디렉터리에 관련되어 저장된다) 존재하게 된다.
그룹 CCRs
CCRs은 하나 이상의 CCR을 참조하는 그룹(groups)으로서 표현될 수 있는데 - 실제로, CCRs은 당연히 제품 릴리스 패키지들을 맵핑(mapping)하므로, 이는 CCRs이 종종 시스템 내로 도입되는 주요한 방식이다. 사용자는 또한, 만약 필요하다면, 프로파일 내에 포함하기 위한 전체 CCR 그룹을 선택할 수 있다.
개방형 구조 테스트 시스템 설치에 대한 몇 가지의 중요한 그룹 CCRs이 요구된다. 설치된 각각의 개방형 구조 테스트 시스템 소프트웨어 컴포넌트 파일에 대한 CCRs 외에, 이하의 릴리스 그룹 CCRs이 요구된다:
TOS 공급자/시스템 통합 사업자에 의해 제공되는 개방형 구조 테스트 시스템의 TOS 릴리스 CCR;
시스템 통합 사업자 또는 UserSDK 공급자에 의해 제공되는 개방형 구조 테스트 시스템의 UserSDK 릴리스 CCR;
시스템 통합 사업자 또는 VendorSDK 공급자에 의해 제공되는 개방형 구조 테스트 시스템의 VendorSDK 릴리스 CCR.
상기 그룹 CCRs은 이하의 그룹/파일 명명 형식을 사용한다:
VendorID_GroupType[_UserGivenName]_VersionIdentifier.gccr.
UserGivenName은 선택적이다.
OAI_TOS_<version>.gccr로 명명된 TOS 릴리스 CCR(TOS Release CCR)은, 공칭 "<version>" 릴리스로 이름이 붙여진, 개방형 구조 테스트 시스템 TOS 런타임의 전체적인 공개(overall release)의 내용을 설명하는 그룹 CCR이다. <version>은 상기 정의된 바와 같이 VersionIdentifier임을 주의하여야 한다. 그것은, 개방형 구조 테스트 시스템 TOS 런타임의 "<version>" 릴리스를 집합적으로 정의하는, 모든 개별적인 컴포넌트 CCR들에 대한 참조를 포함한다. 당해 CCR의 타입(type)은 "TOS"이다.
이와 유사하게, UserSDK 및 VendorSDK 릴리스 CCRs은, - 각각 OAI_USER_SDK_<version>.ccr 및 OAI_VENDOR_SDK_<version>.gccr - 상기 개방형 구조 테스트 시스템 사용자 및 벤더 SDK의 전체적인 공개의 내용을 기술하는 그룹 CCR이고, 또한 각각 "USER_SDK" 및 "VENDOR_SDK"의 타입을 갖는다.
상기 요구되는 그룹 CCRs 외에도, 하드웨어 모듈 벤더는 관련된 컴포넌트의 릴리스를 제어하기 위하여 그룹 CCRs을 제공하도록 선택할 수 있다. 이러한 그룹 CCRs은 "VENDOR", "USER" 및 "TOOLS"의 타입을 갖는다.
단일 컴포넌트 CCR 에 있어서의 정보
이미 언급된 바와 같이, 상기 개방형 구조 테스트 시스템에 있어서의 제1 컴포넌트(primary component)는 하드웨어 모듈의 소프트웨어 표시이다. CCR의 정보 내용은 그러한 제1 컴포넌트를 지원하기 위해 필요한 모든 속성들을 규정하도록 되어 있는데, 모든 컴포넌트 카테고리 중 가장 복잡하다. 그러한 속성들은, 그러한 속성들의 값이 정의될 필요가 없는, 더 간단한 다른 컴포넌트의 카테고리에 대해서는 종종 필요하지 않다.
CCR에 포함되는 정보는 표 3에 기술된 바와 같다. CCR이 개방형 구조 테스트 시스템 제1 컴포넌트(primary components)를 지원하기 위해, 이러한 정보를 제공할 책임은 하드웨어 모듈 벤더에게 있다.
[표 3] 단일 컴포넌트 CCR 의 정보 내용
CCR 필드 설명 필수여부
Description 당해 컴포넌트에 대한 짧은 설명을 제공하는 문자열. 아니오
VendorName 당해 컴포넌트의 벤더에 대한 명칭을 제공하는 문자열. 예
VendorID 당해 컴포넌트에 대한 개방형 구조 테스트 시스템의 벤더 식별자. ID는 개방형 구조 테스트 시스템의 테스트 환경 파일에 의해 인식되는 식별자 세트와 매치된다. 예
ModuleName (만약 존재한다면) 당해 컴포넌트와 연관되는 개방형 구조 테스트 시스템의 하드웨어 모듈의 명칭을 제공하는 문자열. 아니오
CCR 필드 설명 필수여부
ModuleID (만약 존재한다면) 당해 컴포넌트와 연관되는 개방형 구조 테스트 시스템의 하드웨어 모듈 식별자. ID는 개방형 구조 테스트 시스템의 테스트 환경 파일에 의해 인식되는 식별자 세트와 매치된다. 아니오
FileParams (만약 존재한다면) 파일이 시스템에 의해 로드된 때, 상기 파일이 (EXE 또는 DLL과 같은) 실행 파일이라면, 당해 CCR에 의해 설명되는 파일에 전달하기 위한 매개 변수(parameter). 아니오
Function 하나 또는 그 이상의 이하의 것에 대한 목록: 드라이버, 교정(calibration), 진단(diagnostic), 에뮬레이터, GPIB, RS232 또는 패턴 컴파일러. 이는, 만약 당해 파일이 하드웨어 모듈의 소프트웨어 제어와 연관되는 실행 파일이라면, 그 파일의 기본 기능(들)을 나타낸다. 상기 교정 기능은 또한 특정한 당해 교정 DLL과 연관되는 교정 프로그램 알고리즘 버전(calibration program algorithm versions) 정보 파일에 관한 경로를 명명하는 매개 변수를 제공하기 위해 요구된다. 아니오
Resource (당해 CCR에 의해 설명되는) 파일이 제어하는, 개방형 구조 테스트 시스템 리소스(resource)들과 함께, 상기 리소스의 유닛 카운트(unit count)가 존재한다면 이들의 목록. 따라서, 당해 필드는 드라이버 또는 에뮬레이터 기능을 가진 파일에 대한 CCR에 대해서 유효하다. 아니오
HardwareRev 드라이버, 교정(calibration), 진단(diagnostic), 에뮬레이터, 또는 패턴 컴파일러 파일이 그와 함께 작동하도록 지정된 하드웨어 컴포넌트 버전(즉, 보드(board) 버전)의 목록. 아니오
DeployTo "SYSC", "SITEC", 또는 "BOTH" 중의 하나로서, 당해 CCR에 의해 설명되는 파일이 활성화된 동안 복사되어야 하는 (반드시 런타임에 있어서 상기 파일이 종료될 수 있는 곳은 아닌) 위치를 나타낸다. 예
Register "Debug", "Release", 또는 "BOTH" 중의 하나로서, 윈도우즈 시스템 레지스트리에의 파일 속성의 등록이 필수적인지 아닌지를 나타낸다. 당해 필드는 실행 파일에 대한 CCR에 적용되며, ("NO"가 아닌 경우에 있어서) 가정되는 표준 등록 메커니즘에 의하면, DLLRegister() 메소드를 제공하는 DLLs과 함께 regsvr32를 사용하고, 반면 EXEs는 "/register" 및 "/unregister" 명령 라인 옵션을 제공한다. 아니오
GroupDependency 종속된 릴리스 그룹 CCRs 명칭의 목록. 유효한 형식은 VendorID_GroupType[_UserGivenName]_<Version>이다. 아니오
CompDependency 종속된 컴포넌트 명칭의 목록. 유효한 형식은 VendorID_ComponentName_<Version>[.ext]이다. 아니오
GroupIncompat 호환되지 않는 릴리스 그룹 CCRs의 목록. 유효한 형식은 VendorID_GroupType[_UserGivenName]([<,<=,>,>=]<Version>)이다. 아니오
CompIncompat 호환되지 않는 컴포넌트 CCRs의 리스트. 유효한 형식은 VendorID_ComponentName[.ext]([<,<=,>,>=]<Version>)이다. 아니오
CompType "Doc", "Src" 또는 "Bin" 중의 하나로서, 컴포넌트가 어떤 타입에 해당하는지를 나타낸다. "Doc"는 문서(documentation) 타입에 해당한다. "Src"는 소스(source) 타입에 해당한다. "Bin"은 바이너리(binary) 타입에 해당한다. 아니오
벤더 디지털 핀 모듈에 대한 드라이버 DLL에 대해서, 간단한 단일 컴포넌트 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;
GroupIncompat OAI_TOS(<0.5.0);
ComIncompat AT_PinModule.dll(<0.5.0);
CompType Bin;
다음은, 동일한 벤더 디지털 핀 모듈에 대한 교정 DLL에 대하여 단일 컴포넌트 CCR 파일의 예시이다:
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은 상기 CCR 기술 언어(description language)의 버전을 규정하고, 반드시 그것이 설명하는 컴포넌트의 버전에 관련된 것은 아님을 주의하여야 한다. 상기 첫번째 예에 있어서 Resource 필드는, (DM250MHz 하드웨어 모듈에 대한) 당해 모듈 드라이버가 4개 유닛의 모듈 트리거(moduletrigger) 리소스 및 32개 유닛의 디핀(dpin) 리소스를 제공하는 하드웨어 모듈을 구동할 수 있다는 것을 나타낸다. (두번째 예시에 있어서 교정(Calibration)으로 지정된 기능(Function )에 대한) 매개 변수 "cfg/AT/AT_Cal_DM250Mhz_0.5.021.algver.ini"는 교정 프로그램 알고리즘 버전 정보를 포함하는 파일의 경로명을 규정한다. 이는 - 구성 데이터베이스(Configuration Database; CDB)로 인입된 후, 교정 묶음 정보(calibration bundle information)를 발생시키기 위해 OCTool에 의해 사용된다. 각 예에 있어서 GroupIncompat 필드에 대한 "OAI_TOS(<0.5.0)"의 값은, CCR이 설명하는 DLL이, 0.5.0보다 낮은 버전 번호를 가진 TOS 릴리스 그룹 CCRs에 포함되는 개방형 구조 테스트 시스템의 TOS 컴포넌트와는 호환되지 않음을 나타낸다.
그룹 CCR 에 있어서의 정보
그룹 CCR(group CCR)은 개별적인 다른 그룹 CCRs 또는 컴포넌트의 집합을 설명하는 CCR이다. 그룹 CCR에 포함된 정보는 표 4에서 기술되는 바와 같다.
[표 4] 그룹 CCR 의 정보 내용
CCR 필드 설명 필수 여부
Description 당해 CCR에 의해 표시되는 컴포넌트들의 그룹에 대한 간략한 설명을 제공하는 문자열. 예
VendorName 당해 그룹의 벤더에 대한 명칭을 제공하는 문자열 예
VendorID 당해 그룹에 대한 개방형 구조 테스트 시스템의 벤더 식별자. ID는 개방형 구조 테스트 시스템의 테스트 환경 파일에 의해 식별되는 식별자 세트와 매치된다. 예
CCR 필드 설명 필수 여부
OAIMCFVersion TOS 릴리스 CCR에 필요한, 컴포넌트들의 당해 집합이 호환 가능한 개방형 구조 테스트 시스템 모듈 구성 파일(module configuration file; MCF)에 대한 파일 사양 언어의 버전(들). 아니오
OAISimVersion TOS 릴리스 CCR에 필요한, 컴포넌트들의 당해 집합이 호환 가능한 개방형 구조 테스트 시스템 시뮬레이션 구성 파일(simulation configuration file; SCF)에 대한 파일 사양 언어의 버전(들). 아니오
OAIOCFVersion TOS 릴리스 CCR에 필요한, 컴포넌트들의 당해 집합이 호환 가능한 개방형 구조 테스트 시스템 오프라인 구성 파일(offline configuration file; OCF)에 대한 파일 사양 언어의 버전(들). 아니오
Component 당해 그룹을 구성하는 개개의 컴포넌트 CCR들의 목록. 예
이하는, 개방형 구조 테스트 시스템의 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 의 인입( Importing )
그룹에 대해 설명함과 함께, 그룹 CCRs은 다른 그룹 CCRs을 인입할 수 있다. 다음은 그룹 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 Pachage";
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 구성 데이터베이스(Configuration Database; CDB)는 설치된 모든 CCR들을 통해 나타내어 지는 시스템 구성 데이터의 집합을 보존한다. CDB는 또한 사용자에 의해 생성된 시스템 프로파일 정보를 보존한다. CDB 내에서 관리되는 정보는 어떤 특정한 테스터 설치로부터 독립적이다.
CDB의 생성(creation) 및 그것에로의 CCR 데이터의 인입(importing)은 개방형 구조 테스트 시스템의 CDBMgr 도구에 의해 다루어진다. 상기 CDBMgr 도구는 테스터에 설치되거나 작동할 필요가 없고, 그것이 처리하는 정보는 특정 테스터에 대해 특유하지 않다. 그러나, 그것은 $OASIS_ARCHIVE_ROOT에 루트를 둔 디렉터리 트리에 접근해야 하는데, 이는 상기 트리 내에 저장된 CCR 파일들을 읽을 필요가 있기 때문이다 (인입(import) 기능).
CDB에 있어서의 정보는 시스템 프로파일을 생성하기 위해 사용되는데, 이는 또한 CDB에 저장되며, 이에 대하여는 이하 설명한다.
(시스템 프로파일)
시스템 프로파일을 특정하기 위해 필요한 요구 사항은 다음과 같다:
사용자에 의해 선택된, 개방형 구조 테스트 시스템의 시스템 프로파일은, 개방형 구조 테스트 시스템에서 작동하기 위해 요구되는 특정 개방형 구조 테스트 시스템 소프트웨어 구성을 정의하기 위해 필요한 정보의 전체적인 집합이다.
시스템 프로파일은 어떤 특정한 테스터에 대해 특유한 정보를 포함하지 않고, 오히려, 모든 필요한 정보 및 테스터에서의 활성화를 위해 사용자에 의해 선택된 이하의 소프트웨어 컴포넌트의 세트 가운데 상호 의존하는 요소를 캡슐화한다.
(드라이버, 에뮬레이터, 교정, 및 진단 컴포넌트와 같은) 하드웨어 모듈 관련 소프트웨어,
개방형 구조 테스트 시스템 런타임 소프트웨어,
(테스트 개발 환경(test development environment)을 위해 필요한) 사용자 SDK 컴포넌트, 및
(모듈 개발 환경(module development environment )을 위해 필요한) 벤더 SDK 컴포넌트.
사용자에 의해 생성된 시스템 프로파일 정보가 CDB에 저장됨에 반해, (상기 OCTool을 통해) 시스템 프로파일을 이출(exporting)하는 활동은 생성되어야 하는 파일이 프로파일을 정의하는 테스터에 독립적인 영구한 모든 정보를 포함하도록 하여, 그에 의해 상기 프로파일이 CDB에 무관하게 이용 가능하도록 만든다는 것을 주의하여야 한다. 이것은, 그 후, 개방형 구조 테스트 시스템의 활성화 프로세스에 의해 사용되어 진다. 상기 프로파일 정보가 저장되는 파일은 OASISVer.cfg라고 명명되는데, 이 파일은 표준 윈도우즈 INI 파일 형식에 의하고, 디폴트로, 대응하는 $OASIS_ARCHIVE_ROOT/profiles/<profile_dir> 디렉터리에 저장된다. 그러나, 상기 프로파일을 이출하는 동안, 사용자는 그가 선택한 위치에 상기 파일을 두도록 선택할 수 있다.
활성화 동안, 사용자 프로파일에 저장된 테스터에 독립적인 정보는 테스터의 활성 구성(active configuration)을 형성하기 위해 테스터에 특유한 정보와 결합되는데, 이는 $OASIS_ACTIVE_CONFIGS에 저장된 한 세트의 테스트 환경 파일을 포함한다. 활성화는 이하의 단락에서 기술되며, 그에 있어서 상기 시스템 프로파일이 재고된다.
(OCTOOL)
개방형 구조 테스트 시스템의 CDB가 CCR 데이터와 함께 자리하고 나면, 구성 도구(OCTool)가 사용자에 의해 생성된 시스템 프로파일을 생성, 저장, 변경, 및 이출(즉, 상기 CDB와 무관하게 이용가능하도록 함)하기 위해 사용된다.
OCTool은 테스터상에 설치되거나 동작할 필요가 없고, 그것이 처리하는 정보는 특정한 테스터에 특유하지 않다. 그러나, 그것은 $OASIS_ARCHIVE_ROOT에 루트를 둔 디렉터리 트리에 대한 접근을 필요로 하는데, 이는 사용자 프로파일 정보를 $OASIS_ARCHIVE_ROOT/profiles/<profile_dir>에 저장할 필요가 있기 때문이다(이출(export) 기능).
활성화
개방형 구조 테스트 시스템의 소프트웨어 시스템 활성화(software system activation)를 규정하기 위해서는 이하의 요건을 필요로 한다. 개방형 구조 테스트 시스템의 소프트웨어 시스템의 활성화란 다음과 같은 동작을 말한다.
1. 선택된 시스템 프로파일에 있어서 테스터에 독립적인 구성 정보를 사용하고,
2. 그것을 $OASIS_ACTIVE_CONFIGS에 있어서 테스터 활성 구성 정보를 생성하기 위해 테스터에 특유한 정보와 결합하고,
3. $OASIS_INSTALLATION_ROOT 아래에 요구되는 모든 소프트웨어 컴포넌트(파일)들을 배치(즉, 위치시키고 등록)하며,
4. 타겟 테스터에서 선택된 구성과 함께, 개방형 구조 테스트 시스템의 TOS를 시작한다.
개방형 구조 테스트 시스템의 소프트웨어 시스템의 활성화는 상기 개방형 구 조 테스트 시스템의 테스터 제어 데몬(tester control daemon; TCD)의 기능이다. 상기한 바와 같이, TCD는 접속된 응용 프로그램으로 하여금 테스터 제어 명령을 보낼 수 있도록 하는 COM 인터페이스 메소드를 제공한다. 상기한 바와 같이, <MAINTENANCE_ROOT>/bin에 설치된 TCD 제어기 응용 프로그램은 "시작(start)", "정지(stop)", "활성화(activate)" 등과 같은 기초적인 테스터 시스템 제어 명령을 상기 TCD로 보낼 수 있는 간단한 명령-라인(command-line) 응용 프로그램이다. 또한 상기한 바와 같이, 이는 아도반테스토 T2000 시스템에 있어서의 t2kctrl 응용 프로그램이다. 당해 단락에 있어서, "활성화" 기능을 수행하기 위해 상기 t2kctrl 응용 프로그램의 사용에 대하여 기술한다.
(필수 요건)
(선택된 프로파일을 통해) 특정 개방형 구조 테스트 시스템 구성을 활성화하도록 시도하기 전에, 다음의 필수 요건이 만족되어야 한다:
1. $OASIS_ARCHIVE_ROOT에 의해 규정되는 위치는 타겟 테스터 장치의 시스템 제어기에서 동작하는 TCD에 접근할 수 있다.
2. 미리 정의된 개방형 구조 테스트 시스템의 시스템 프로파일은 OASISVer.cfg로 이출되었고, $OASIS_ARCHIVE_ROOT/profiles/<profile_dir> 또는 사용자가 선택한 다른 위치(location/)에서 이용 가능하며, 상기 이출된 OASISVer.cfg 파일은 타겟 테스터 장치의 시스템 제어기에서 동작하는 TCD에 접근할 수 있다.
3. 환경 변수 OASIS_INSTALLATION_ROOT 및 OASIS_TEMP가 정의되었다. 만약 개방형 구조 테스트 시스템의 시스템 소프트웨어의 다른 구성이 $OASIS_INSTALLATION_ROOT에 의해 지정된 위치에서 이미 이용 가능하다면, 상기 설치는 ${OASIS_INSTALLATION_ROOT}_BAK에 백업되고, 활성화 프로세스가, 만약 성공적인 경우, 선택된 새로운 구성을 $OASIS_INSTALLATION_ROOT 아래에 위치하게 함을 주의하여야 한다.
4. 환경 변수 $OASIS_ACTIVE_CONFIGS가 정의되었다. 만약 당해 디렉터리가 이미 존재하고, 다른 한 세트의 개방형 구조 테스트 시스템의 시스템 소프트웨어에 대한 활성 구성 정보(active configuration information)가 이미 상기 위치에서 이용 가능하다면, 상기 설치는 ${OASIS_ACTIVE_CONFIGS}_BAK에 백업되고, 활성화 프로세스가, 만약 성공적인 경우, 선택된 새로운 활성 구성(active configuration)에 대응하는 테스트 환경 파일을 $OASIS_ACTIVE_CONFIGS 아래에 생성함을 주의하여야 한다.
5. 환경 변수 OASIS_MACHINE_DIR이 정의되었다*. 만약 당해 디렉터리가 이미 존재한다면, $OASIS_MACHINE_DIR/CD/bundles 디렉터리에서 기존의 교정/진단(calibration/diagnostic; CD) 묶음 설명 파일(bundle description file)을 제거하고, 선택된 프로파일과 연관되는 CD 묶음 설명 파일(들)이 대신 상기 위치에 채택(instate)된다.
6. 테스터 제조 디폴트(factory default; 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와 같거나 2보다 큰 상태(16페이지 참조)이면, 시스템 제어기 TCD는 우선, 궁극적으로 시스템을 상태 1로 가져오는 TOS "종료(shutdown)" 명령을 내린다. 만약 이때 어떤 개방형 구조 테스트 시스템 응용 프로그램이 상기 시스템 제어기에 접속되어 있다면, 접속 종료를 요청하는 메시지를 보내고, 그것의 상태를 정리하고 적절히 종료하기에 충분한 시간을 허여하거나, 그렇지 않으면 강제로 종료시킨다. 이는, 그때에 상기 시스템 제어기에 접속되어 있지 않은 응용 프로그램에는 적용되지 않음을 주의하여야 한다.
2. 상기 시스템이 일단 상태 1에 있으면, $OASIS_INSTALLATION_ROOT에서의 현재의 설치가, 만약 존재한다면, ${OASIS_INSTALLATION_ROOT}_BAK에 백업되고, 윈도우즈 레지스트리에 등록된 모든 개방형 구조 테스트 시스템 실행 파일들(표 7에 있어서 "Register" 필드 참조)이 등록 취소된다. 이는 모든 사이트 제어기에 대해서 뿐만 아니라, 시스템 제어기에 대해서도 행해진다.
3. 그런 후, $OASIS_ACTIVE_CONFIGES 내의 현재의 활성 구성 정보(active configuration information)가, 만약 존재한다면, ${OASIS_ACTIVE_CONFIGS}_BAK에 백업되고, $OASIS_MACHINE_DIR/CD/bundles에 있어서의 CD 묶음 설명 파일(들)이, (만약 존재한다면) 삭제된다.
4. 현재의 설치 및 활성 구성 정보의 백업이 (필요하다면) 성공적으로 완료된 후에, TCD는 선택된 (새로운) 프로파일에 의해 규정된 바와 같이, 보존된(archived) 개방형 구조 테스트 시스템의 소프트웨어 시스템 파일을, 다음 단락 에서 규정될 위치에게로 복사한다. 분산 환경 (분리된 시스템 및 사이트 제어기(들))에 있어서, 사이트 제어기에 설치되도록 요구되는 파일이 또한 상기 장치들에게로 복사된다.
5. 그런 후, TCD는 시스템 및 사이트 제어기(들) 모두에서, 윈도우즈 레지스트리에 등록되도록 요구되는 모든 개방형 구조 테스트 시스템 실행 파일을 등록한다.
6. 그런 후, 선택된 (새로운) 프로파일로부터 얻어지는 테스터 독립적인 정보가, TCD에 의해, (시스템 제어기에서 <MAINTENANCE_ROOT>/cfg 디렉터리에 위치하는) 테스터 제조 디폴트 파일로부터 얻어지는 테스터에 특유한 정보와 결합된다. 이로써, 타겟 테스터 장치에서 새로운 개방형 구조 테스트 시스템 소프트웨어 런타임 설치를 위한 활성 구성(active configuration)을 정의하는 이하의 파일들의 세트가 생성된다:
모듈 구성 파일, OASISModules.cfg.
시뮬레이션 구성 파일, OASISSim.cfg.
시스템 구성 파일, OASISSys.cfg.
오프라인 구성 파일, OASISOffline.cfg
당해 파일들은 TCD에 의해 $OASIS_ACTIVE_CONFIGS내에 자리하게 된다.
7. TCD는 또한, 새로운 프로파일에 따라서 시스템의 내용 및 구성에 대한 기록으로서 기능하기 위해, $OASIS_ACTIVE_CONFIGS 위치 내에 새로운 프로파일 정보 파일인 OASISVer.cfg의 사본을 위치시킨다.
8. 최종적으로, TCD는, 새로운 구성으로 TOS를 시작하기 위해서, TOS 시동 프로세스의 단계 0 - 0 에 있어서 개략적으로 설명된 TOS "시동" 순서를 따르고, 그리하여 활성화 프로세스를 완료한다.
상기 단계들 중 어느 하나라도 성공적으로 수행하는 것에 실패하는 경우, 상기 개방형 구조 테스트 시스템 설치는 활성화 명령이 내려지기 전의 구성으로 돌아가고, TCD는 상기 구성으로 TOS를 재시작함을 주의하여야 한다. 또한, 전체 프로세스에 대한 상세한 로그는 $OASIS_INSTALLATION_ROOT/logs/Deployment 위치에 보존된다. 상기 로그는 Deployment.log로 명명되고, TCD의 "활성화(activate)" 명령이 각각 새롭게 발동될 때마다 덮어써지게 된다.
(배치 디렉터리 구조)
이미 언급된 바와 같이, TCD는, $OASIS_INSTALLATION_ROOT에서, 요구되는 개방형 구조 테스트 시스템의 소프트웨어 파일을 $OASIS_ARCHIVE_ROOT 아래의 상기 파일들이 보존된(archived) 위치로부터, 타겟 테스터에서의 배치 또는 런타임 설치로 복사한다.
테스터에서의 개방형 구조 테스트 시스템 배치에 대한, $OASIS_INSTALLATION_ROOT에 루트를 두는 디렉터리 구조는, 도 6, 도 7 및 도 8에 도시된 바와 같다. 활성화 프로세스는 이하의 과정을 따른다:
테스터 장치에서의 런타임의 활성화를 위해, 모든 개방형 구조 테스트 시스템 소프트웨어 컴포넌트 파일이, 도 6, 도 7 및 도 8에 도시되고 표 8에 기술된 바와 같이 $ OASIS _ INSTALLATION _ ROOT 아래의 적절한 위치에 배치된다.
이하의 그림들에 있어서, OAI로 명명된 디렉터리는 개방형 구조 테스트 시스템의 TOS 파일을 포함하고, 반면 < vendor >로 명명된 디렉터리는 벤더에 특유한 파일을 포함한다. 상기 아카이브 구조에 있어서와 같이, 각각의 벤더는 고유의 2-3 글자의 식별자(예를 들면, 아도반테스토 벤더 디렉터리는 AT로 이름이 붙여진다)를 나타내는 < vendor >와 함께, 그 자신의 디렉터리를 갖는다.
나아가, 표 5는 상기 그림들에 있어서 개략적으로 설명된 디렉터리 구조에 대해 기술하는데, 여기서 첫 번째 열에 있어서의 각 디렉터리는 $OASIS_INSTALLATION_ROOT와 관련된다.
[표 5] 개방형 구조 테스트 시스템 배치 디렉터리 구조
디렉터리 설명
./ bin 런타임에 의해 사용되는 모든 실행 파일(DLL 및 EXE)들을 포함한다. 당해 디렉터리 아래에는 서브 디렉터리가 존재하지 않고, 모든 파일들은 같은 레벨에 위치함을 주의하여야 한다. 시스템 런타임에 있어서 사용자의 시스템 경로 환경 변수를 최소한으로 처리해야 하는데, 이로써 상기 처리를 용이하게 할 수 있다. 또한, $OASIS_ARCHIVE_ROOT/{Vendor,User}SDK/bin 아래에 원래 보존된 모든 실행 파일은 또한 당해 디렉터리에 배치됨을 주의하여야 한다.
./ cache TOS에 필요한 파일들의 런타임 캐시(cache)를 포함한다.
./ cfg 시스템 TOS 또는 벤더 컴포넌트에 의해 사용되는 구성 파일, 또는 시스템 및 벤더 도구들(tools)을 포함하고, 후자는 도구에 특유한 ( < tool > ) 서브 디렉터리로 체계화된다. 공통의( common ) 서브 디렉터리는 벤더가 TOS 및 하나 이상의 벤더 컴포넌트에 걸쳐서 공유되어야 하는 구성 정보를 두기 위해 사용하기 위한 것이다.
./ doc 개별 문서의 카테고리에 의해 디렉터리로 분류되는 문서(documentation)를 포함한다.
디렉터리 설명
./ logs 파일을 아카이브로 로드할 때, 설치자가 그 동작을 기록하는 위치.
./{ User,Vendor } SDK / doc 개별 문서의 카테고리에 의해 디렉터리로 분류되는 SDK 문서를 포함한다. 베이스 디렉터리(base directory)는, 상기 베이스 디렉터리 아래에 있는 HTML을 기반으로 하는 모든 문서에 대한 최상위 수준(top-level)의 색인으로서 기능하는 index.html파일을 포함하는데, 이는 < html - dirs >에 있어서 주제(topic)에 의해 체계화된다.
./{ User , Vendor } SDK / examples SDK 예를 저장하는 위치.
./{ User , Vendor } SDK / inc 인클루드(include) 파일을 저장하는 위치.
./ UserSDK / inc / STL C++ 표준 템플릿 라이브러리(standard template library; STL) 파일 계층을 저장하는 위치.
./{ User , Vendor } SDK / lib 라이브러리 파일을 저장하는 위치.
./ UserSDK / templates 사용자 SDK에 필요한 템플릿 파일을 저장하는 위치. 서브 디렉터리 OAI / OTPL은 OTPL 컴파일러인 occ가 그 동작을 위해 사용하는 템플릿을 저장하기 위해 사용된다.
./ UserSDK / TestClasses 개방형 구조 테스트 시스템의 테스트 클래스를 저장하는 위치.
파일명 변환
활성화된 동안, 파일이 아카이브로부터 런타임 환경에 배치된 때, TCD는 파일명에 포함된 버전 식별자를 떼어낸다. 따라서, 예를 들면, 아카이브에 있어서의 OAI_utils_0.1.2.dll 파일은 런타임 설치에 있어서 OAI_utils.dll 파일로 복사되고, 반면 아카이브에 있어서의 AT_Cal_DM250MHz_D_1.2.3.dll 파일은 런타임 설치에 있어서 AT_Cal_DM250MHz_D.dll로 복사된다.
(활성 테스터 구성(Active Tester Configuration))
상기 활성화 프로세스에 있어서 기술된 바와 같이, 타겟 테스터 장치에서 개방형 구조 테스트 시스템의 배치 동안, 선택된 (새로운) 프로파일로부터 얻어지는 테스터에 독립적인 정보가, TCD에 의해, FDEF 파일로부터 얻어지는 테스터에 특유한 정보와 결합된다. 이로써, 타겟 테스터 장치에서 새로운 개방형 구조 테스트 시스템 소프트웨어 런타임 설치에 대하여 활성 구성(active configuration)을 정의하는 이하의 한 세트의 파일을 생성하게 된다:
모듈 구성 파일, OASISModules.cfg.
시뮬레이션 구성 파일, OASISSim.cfg.
시스템 구성 파일, OASISSys.cfg.
오프라인 구성 파일, OASISOffline.cfg.
이러한 파일들은 TCD에 의해 $OASIS_ACTIVE_CONFIGS에 위치하게 된다. $OASIS_ACTIVE_CONFIGS를 $OASIS_INSTALLATION_ROOT에 루트를 둔 디렉터리 트리 안에 있는 위치로 설정하면 안 된다는 것을 주의하여야 한다.
(개방형 구조 테스트 시스템 장치 데이터)
교정/진단(calibration/diagnostics; CD) 데이터 등과 같은 테스터 장치에 특유한 데이터는, 시스템 제어기에서, 환경 변수 OASIS_MACHINE_DIR에 의해 지정되는 위치 아래에 저장된다. 데이터 외에도, CD 데이터 디렉터리는 서브 디렉터리 CD/bundles를 포함하는데, 이는 현재 배치된 (즉, 활성화된) 프로파일과 연관되는 CD 묶음 설명 파일(CD bundle description file)(들)을 저장하기 위해 사용된다.
$OASIS_MACHINE_DIR 위치에 있는 데이터 세트(data sets)는 전적으로 사용자에 의해 유지되고, 특정 장치에 요구되는 것과 같은 적절한 데이터 세트를 이용 가능하도록 만드는 것은 사용자의 책임임을 주의하여야 한다. 그러나, 상기 활성화 프로세스가 CD 묶음 설명 파일과 관련하여 이하의 활동을 담당한다:
$OASIS_MACHINE_DIR/CD/bundles에 존재하는 CD 묶음 설명 파일(들)이 삭제된다. 새로운, 선택된 프로파일에 대한 CD 묶음 설명 파일(들)이, 그 후, $OASIS_MACHINE_DIR/CD/bundles에 배치된다.
$OASIS_MACHINE_DIR을 $OASIS_INSTALLATION_ROOT에 루트를 둔 디렉터리 트리 안에 있는 위치로 설정하면 안 된다는 것을 주의하여야 한다.
감사(Audit)
개방형 구조 테스트 시스템에 대한 프로파일 감사(profile audit)는 사용자로 하여금 CDB에 저장된 주어진 프로파일의 내용을 검증할 수 있도록 한다. 개방형 구조 테스트 시스템 감사는, 한편, 특정 테스트 시스템에서 현재 활성화된 소프트웨어 및 하드웨어 컴포넌트의 목록을 제공하는 활동을 나타낸다. 이하의 기능들이 이러한 활동을 허용하기 위해 이용가능 하다.
(프로파일 감사)
이는, 테스터에 독립적인 프로파일 정보에 대하여, 두 가지의 별개의 메커니즘을 통해 이용 가능하다:
OCTool 응용 프로그램은 CDB에 저장된 선택된 프로파일의 내용을 디스플레이할 수 있다.
주어진 프로파일을 디폴트 위치인 $OASIS_ARCHIVE_ROOT/profiles/<profile_dir> (또는 사용자가 선택한 다른 위치)로 이출하는 활동(이는, 상기 프로파일의 활동이 완수될 수 있기 전에 수행됨)에 의해 OASISVer.cfg 파일이 생성된다. 상기 파일의 내용은 전적으로 상기 선택된 프로파일에 대해 설명한다. 상기 파일은 단순한 텍스트이고 표준 윈도우즈 INI 파일 형식으로 되어 있으므로, 그 정보는 소기의 감사 기능성을 제공하기 위해 스캔(scan)될 수 있다. 활성화된 배치에 있어서, 당해 파일은 또한 $OASIS_ACTIVE_CONFIGS에서 이용가능하도록 됨을 유념해야 한다.
(시스템 감사)
상시 시스템 감사는 두 부분, 즉 배치된 소프트웨어 감사와 테스터 하드웨어 감사로 나눌 수 있다.
배치된 소프트웨어 감사
배치된 소프트웨어 감사는 개방형 구조 테스트 시스템에서 만족되는 이하의 요건을 통해 용이하게 이루어질 수 있다:
타겟 테스터 장치에서, 개방형 구조 테스트 시스템의 소프트웨어 배치 또는 활성화의 프로세스는 배치된 소프트웨어 컴포넌트의 모든 상세를 제공하는 단순 텍스트의 배치 로그를 생성한다. 당해 로그는 Deployment . log로 명명되고, 시스템 제어기상에서 < MAINTENANCE _ ROOT >/ logs / Deployment 위치에서 이용가능하게 된다.
상기 로그 파일은 단순 텍스트로 되어 있으므로, 그것에 있는 정보는 요구되는 감사 기능성을 제공하기 위해 스캔될 수 있다.
테스터 하드웨어 감사
테스터 하드웨어 감사는 개방형 구조 테스트 시스템에서 TOS에 의해 만족되는 이하의 요건을 통해 용이하게 이루어진다:
모듈 상세 정보가 TOS가 시작될 때마다 개방형 구조 테스트 시스템 하드웨어 인벤토리(hardware Inventory; HWINV) 파일 형식으로 작성된다. 이는 OASISHW.inv 파일에 저장되고, 시스템 제어기상에서 < MAINTENANCE _ ROOT >/ cfg 위치에서 이용가능하게 된다.
하드웨어 목록 파일은 단순 텍스트이므로, 그것에 있는 정보는 요구되는 감사 기능성을 제공하기 위해 스캔될 수 있다.
소프트웨어 패치 릴리스
상기 새로운 컴포넌트 버전 설치 단락에서 기술된 바와 같이, 설치 패키지는 현재 공개된 컴포넌트의 버전을 수정하거나 강화하기 위한 목적으로 별도의 컴포넌트를 포함할 수 있다. 그러한 설치 패키지가 릴리스의 메이저(major)/마이너(minor) 버전과 호환 가능한 때, 상기 패키지(및, 확대하면, 그것이 속하는 릴리 스)를 "패치(patch)"라고 한다. 당해 단락에서, 그러한 패치 릴리스를 제공하는데 있어서 수행되는 단계가 기술된다.
컴포넌트의 새로운 버전이 공개되는 때, 컴포넌트 공급자(TOS 또는 벤더)는 새로운 컴포넌트 버전에 대한 CCR을 제공한다. 컴포넌트 구성 요소의 파일명은, 상기 파일 명명 요건 단락에서 기술된 바와 같이, 컴포넌트의 새로운 버전을 반영하되, 파일 명명 규칙에 따라 기존의 파일을 덮어쓰는 것을 금지한다. 따라서, 컴포넌트 파일 버전은 아카이브 디렉터리에서 계속하여 축적된다. 기존의 컴포넌트의 새로운 버전은 기존의 컴포넌트/파일을 대체하지 않으므로, 이미 존재하는 시스템 프로파일은 여전히 작동할 수 있다.
(패치 릴리스의 제공)
패치 릴리스를 제공하는 단계는 다음과 같다:
1. 공급자(TOS 공급자, 벤더, 또는 시스템 통합 사업자)는 현재의 릴리스를 수정하거나 강화하기 위한 컴포넌트(들)(의 세트)를 식별하고 생성한다. 그 예로서, OAI_core.dll 및 OAI_messages.dll의 갱신된 버전을 포함하는 TOS 패치를 고려해 보자. 여기서, 현재 공개된 버전이 OAI_core_1.2.9.dll 및 OAI_messages.1.2.2.dll이다. 현재의 릴리스에 대한 TOS 릴리스 CCR을 OAI_TOS_1.2.11.ccr이라고 한다.
2. 시스템에 있어서 버전화된 컴포넌트를 식별하는 major.minor.patch의 3개의 패치 필드에 대한 갱신과 함께, 상기 세트에 포함되는 각 컴포넌트의 명칭이 지 정된다. 따라서, 상기 예에 있어서, 갱신된 컴포넌트는 OAI_core.1.2.10.dll 및 OAI_messages.1.2.3.dll로 명명될 수 있다.
3. 새로운 패치 CCR이 갱신된 버전 정보를 반영하여 상기 갱신된 컴포넌트의 각각에 대해 생성된다. 따라서, 상기 예에 있어서, 상기 컴포넌트에 대한 갱신된 CCR은 OAI_core.1.2.10.dll.ccr 및 OAI_messages.1.2.3.dll.ccr이 될 수 있다.
4. 새로운 릴리스 그룹 CCR이 현재의 릴리스에 대해 사용되고 있는 원래의 그룹 CCR을 대신하기 위해 생성된다. 당해 CCR은 상기 갱신된 컴포넌트(본 예에 있어서, OAI_core_1.2.10.dll.ccr 및 OAI_messages.1.2.3.dll.ccr)에 대한 새로운 CCR(들)의 세트에 대한 갱신된 참조를 포함하는 반면, 그룹에 있어서의 다른 모든 컴포넌트에의 참조는 현재의 릴리스에 대한 참조와 동일하게 유지된다. 당해 새로운 그룹 CCR은 또한, 현재 고려되고 있는 패키지의 집합적인 "<version>" 릴리스를 공칭적으로 식별하는, major.minor.patch 세 가지의 필드에 있어서 "패치(patch)" 필드에 대한 갱신을 갖는, <version> 번호가 주어진다. 따라서, 본 예에 있어서, 당해 새로운 릴리스 그룹 CCR은 OAI_TOS_1.2.11.ccr로 명명될 수 있다.
5. 공급자는, 전체적인 패키지에 대하여, 갱신된 컴포넌트, 이들의 갱신된 개별적인 CCRs, 및 새로운 릴리스 그룹 CCR로 구성되는 개방형 구조 테스트 시스템의 아카이브 설치 패키지를 생성한다. 당해 패키지는 식별된 컴포넌트에 대한 통합된 "패치(patch)"로서 전달된다.
(패치 릴리스의 이용)
사용자 편에서, 패치를 설치, 구성, 및 활성화하는 과정은 다음과 같다:
1. 사용자는 패치 패키지의 내용물을 개방형 구조 테스트 시스템 설치 아카이브 위치에 설치한다.
2. 사용자는 먼저 그가 사용하고자 하는 프로파일을 재호출하고, 새로운 릴리스 그룹 CCR을 이용하기 위해(그리고 그로써, 갱신된 컴포넌트에 대한 개별적인 컴포넌트 CCRs을 이용하기 위해) 그것을 수정(또는 그것을 새로운 프로파일에 대한 기초로서 사용)하고, 그 결과로서 만들어지는 수정된 (또는 새로운) 프로파일을 저장함으로써, 상기 패치에 대하여 설정한다.
3. 마지막으로, 사용자는 t2kctrl 도구를 통해 상기 패치를 활성화하기 위해 상기 수정된 (또는 새로운) 프로파일을 사용한다.
(하드웨어만에 대한 패치(Hardware-only Patches))
하드웨어 공급자는 때때로 대응하는 소프트웨어를 갱신할 필요가 없이 하드웨어 버전만을 갱신할 필요가 있다. 그러한 경우 소프트웨어에 대한 기존의 CCR은 새로운 하드웨어 버전에 대한 올바른 호환성 정보를 포함하지 아니한다.
하드웨어만에 대한 패치(hardware-only patch; HOP)는 하드웨어/소프트웨어 호환성 관계를 갱신하기 위한 목적의, 갱신된 CCR의 공개(release)를 말한다. 이러한 CCR이 데이터베이스에 인입되는 때, 프로파일은 새로운 호환성 정보로써 갱신될 수 있다. 그러한 CCR은 종래와 같이 생성되고, 소프트웨어를 포함하지 않는 패키지로서 배포될 수 있다. 사용자가 이러한 새로운 CCR을 받은 경우, 패치를 설 치, 구성 및 활성화하는 과정은 새로운 CCR을 취급하기 위하여 사용되는 과정과 동일하다.
명확성을 위하여 상기 기재는 다른 기능적인 유닛 및 프로세서와 관련한 본 발명의 실시예에 대해 이루어졌음을 이해하여야 할 것이다. 그러나, 본 발명의 개념으로부터 이탈되지 아니한 채 구분되는 기능적인 유닛 또는 프로세서들 사이에 기능의 적절한 배치가 이루어질 수 있음이 명백하다. 예를 들면, 구분되는 프로세서 또는 제어기에 의해 수행되어 지도록 기술된 기능은 하나의 프로세서 또는 제어기에 의해 수행될 수 있다. 따라서, 특정한 기능적 유닛에 대한 참조는 단지 한정된 논리적 또는 물리적 구조나 체계를 나타내는 것이라기보다는, 상기 기술된 기능을 제공하기 위하여 적절한 수단에 대한 참조에 지나지 아니한다.
본 발명은, 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 조합을 포함하는 적절한 형태로 구현될 수 있다. 본 발명은 선택적으로, 하나 또는 그 이상의 데이터 프로세서 및/또는 디지털 시그널 프로세서에서 실행되는 컴퓨터 소프트웨어로서 부분적으로 구현될 수도 있다. 본 발명의 일 실시예의 구성 요소 및 컴포넌트는 물리적으로, 기능적으로, 그리고 논리적으로 적절한 방법으로 구현될 수도 있다. 실제로 기능성은 단일 유닛으로, 복수의 유닛으로, 또는 다른 기능적인 유닛의 일부로서 구현될 수도 있다. 이로써, 본 발명은 단일 유닛으로 구현될 수도 있고, 또는 다른 유닛과 프로세서 사이에 물리적으로 그리고 기능적으로 분산될 수도 있다.
관련 기술 분야에서 숙련된 자는, 기초가 되는 동일한 메커니즘과 방법론을 사용하면서, 개시된 실시예의 많은 가능한 변경과 조합이 사용될 수 있다는 것을 인식할 것이다. 설명의 목적으로, 상기의 기술은 특정 실시예를 참조로 하여 쓰여졌다. 그러나, 상기의 예시적인 논의는 모든 것을 남김없이 규명하거나 또는 본 발명을 개시된 정확한 형태로 제한하고자 의도된 것은 아니다. 많은 변경과 변형이 상기 시사(示唆)의 관점에서 가능하다. 상기 실시예들은 본 발명의 원리와 그 실제 응용을 설명하기 위해 선택되고 기술되었고, 관련 기술 분야의 숙련된 자가 본 발명, 그리고, 고려될 수 있는 특정 사용에 적절한 다양한 변형을 갖는 다양한 실시예를 가장 잘 사용하도록 한다.

Claims (22)

  1. 모듈식 테스트 시스템에서 다수의 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트, 및 테스터 운영 체제(TOS) 버전을 관리하는 방법 - 상기 모듈식 테스트 시스템은 적어도 하나의 사이트 제어기를 제어하는 시스템 제어기를 포함하고, 상기 적어도 하나의 사이트 제어기는 적어도 하나의 하드웨어 테스트 모듈을 제어함 - 에 있어서,
    아카이브(archive)에 상기 모듈식 테스트 시스템과 호환 가능한 상기 TOS 버전을 설치하는 단계;
    상기 아카이브에 상기 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트를 설치하는 단계;
    상기 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트 및 상기 TOS 버전을 설명하는 시스템 프로파일을 생성하는 단계;
    상기 모듈식 테스트 시스템에 대하여, 특정의 하드웨어 테스트 모듈 버전을 시험하기 위한 한 세트의 호환 가능한 벤더 소프트웨어 컴포넌트 및 선택된 TOS를 포함하는 시스템 프로파일을 선택하는 단계; 및
    상기 시스템 제어기와 상기 적어도 하나의 사이트 제어기에서 상기 선택된 TOS를 활성화하는 단계를 포함하는 방법.
  2. 제1항에 있어서,
    상기 벤더 소프트웨어 컴포넌트를 설치하는 단계는,
    상기 TOS 버전의 전반적인 제어를 수행하는 테스트 제어 데몬(TCD)을 설치하는 단계; 및
    TOS 제어 디렉터리를 설치하는 단계를 포함하는 방법.
  3. 제2항에 있어서,
    상기 TOS 제어 디렉터리를 설치하는 단계는,
    TCD 제어기 응용 프로그램 및 이와 연관된 동적 링크 라이브러리를 저장하는 빈(bin) 디렉터리를 설치하는 단계;
    상기 테스터의 제조 디폴트 설정(factory default setting)에 관한 구성 파일을 저장하는 구성 디렉터리를 설치하는 단계;
    TCD와 제조 디폴트 문서(documentation)를 저장하는 문서 디렉터리를 설치하는 단계; 및
    상기 TCD의 동작을 저장하는 설치 로그(log) 디렉터리를 설치하는 단계를 포함하는 방법.
  4. 제3항에 있어서,
    상기 설치 로그 디렉터리는,
    상기 아카이브에 복사된 각각의 파일에 대한 경로; 및
    상기 아카이브에 복사되거나, 상기 아카이브로부터 삭제된 파일의 상태를 포함하는 방법.
  5. 제1항에 있어서,
    상기 벤더 소프트웨어 컴포넌트를 설치하는 단계는,
    단일 컴포넌트 구성 기록을 설치하는 단계; 및
    그룹 컴포넌트 구성 기록을 설치하는 단계를 더 포함하는 방법.
  6. 제5항에 있어서,
    상기 단일 컴포넌트 구성 기록은,
    소프트웨어 컴포넌트의 벤더 명칭; 및
    상기 소프트웨어 컴포넌트의 벤더 식별자를 포함하는 방법.
  7. 제5항에 있어서,
    상기 그룹 컴포넌트 구성 기록은,
    상기 그룹 컴포넌트 구성 기록에 의해 표현되는 상기 컴포넌트의 그룹에 대한 설명;
    상기 그룹 컴포넌트 구성 기록의 벤더 명칭; 및
    상기 그룹 컴포넌트 구성 기록의 벤더 식별자를 포함하는 방법.
  8. 제1항에 있어서,
    상기 시스템 프로파일은,
    상기 하드웨어 테스트 모듈 버전에 특유한 소프트웨어 컴포넌트;
    사용자 소프트웨어 개발 키트; 및
    벤더 소프트웨어 개발 키트를 포함하는 방법.
  9. 제8항에 있어서,
    상기 하드웨어 테스트 모듈 버전에 특유한 소프트웨어 컴포넌트는,
    디바이스 드라이버;
    에뮬레이션 소프트웨어 컴포넌트;
    교정 소프트웨어 컴포넌트; 및
    진단 소프트웨어 컴포넌트를 포함하는 방법.
  10. 제1항에 있어서,
    상기 선택된 TOS를 활성화하는 단계는,
    상기 선택된 TOS를 초기화하는 단계; 및
    상기 모듈식 테스트 시스템의 시스템 프로파일로부터 선택된 소프트웨어 구성을 배치하는 단계를 포함하는 방법.
  11. 제10항에 있어서,
    상기 선택된 TOS를 초기화하는 단계는,
    상기 시스템 제어기를 초기화하는 단계;
    상기 사이트 제어기를 초기화하는 단계; 및
    상기 모듈식 테스트 시스템에 대한 상기 시스템 프로파일에 따라 사용자 응용 프로그램을 초기화하는 단계를 포함하는 방법.
  12. 제10항에 있어서,
    상기 선택된 소프트웨어 구성을 배치하는 단계는,
    테스터 활성 구성 정보를 생성하기 위해, 테스터에 독립적인 구성 정보를 테스트 특유의 정보와 결합하는 단계;
    미리 정의된 디렉터리 위치로부터 소프트웨어 컴포넌트를 배치하는 단계; 및
    상기 특정 하드웨어 테스트 모듈 버전의 상기 선택된 소프트웨어 구성으로 상기 선택된 TOS를 시작하는 단계를 포함하는 방법.
  13. 제1항에 있어서,
    기존의 TOS 버전으로 새로운 벤더 소프트웨어 컴포넌트의 호환성을 검증하는 단계를 더 포함하는 방법.
  14. 다수의 하드웨어 테스트 모듈 버전, 소프트웨어 컴포넌트, 및 테스터 운영 체제(TOS) 버전을 관리하는 모듈식 테스트 시스템에 있어서,
    적어도 하나의 사이트 제어기를 제어하는 시스템 제어기;
    적어도 하나의 하드웨어 테스트 모듈을 제어하는 적어도 하나의 사이트 제어기;
    상기 모듈식 테스트 시스템과 호환 가능한 테스트 운영 체제 버전;
    상기 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트; 및
    상기 하드웨어 테스트 모듈 버전에 대응하는 벤더 소프트웨어 컴포넌트 및 상기 TOS 버전을 설명하는 시스템 프로파일을 포함하는 모듈식 테스트 시스템.
  15. 제14항에 있어서,
    상기 벤더 소프트웨어 컴포넌트는,
    상기 TOS 버전의 전반적인 제어를 수행하는 테스트 제어 데몬(TCD); 및
    TOS 제어 디렉터리를 포함하는 모듈식 테스트 시스템.
  16. 제15항에 있어서,
    상기 TOS 제어 디렉터리는,
    TCD 제어기 응용 프로그램 및 이와 연관된 동적 링크 라이브러리를 저장하는 빈(bin) 디렉터리;
    상기 테스터의 제조 디폴트 설정에 관한 구성 파일을 저장하는 구성 디렉터리;
    TCD와 제조 디폴트 문서를 저장하는 문서 디렉터리; 및
    상기 TCD의 동작을 저장하는 설치 로그 디렉터리를 포함하는 모듈식 테스트 시스템.
  17. 제16항에 있어서,
    상기 설치 로그 디렉터리는,
    아카이브에 복사된 각 파일에 대한 경로; 및
    상기 아카이브에 복사된, 또는 상기 아카이브로부터 삭제된 파일의 상태를 포함하는 모듈식 테스트 시스템.
  18. 제14항에 있어서,
    상기 벤더 소프트웨어 컴포넌트는,
    단일 컴포넌트 구성 기록; 및
    그룹 컴포넌트 구성 기록을 더 포함하는 모듈식 테스트 시스템.
  19. 제18항에 있어서,
    상기 단일 컴포넌트 구성 기록은,
    소프트웨어 컴포넌트의 벤더 명칭; 및
    상기 소프트웨어 컴포넌트의 벤더 식별자를 포함하는 모듈식 테스트 시스템.
  20. 제18항에 있어서,
    상기 그룹 컴포넌트 구성 기록은,
    상기 그룹 컴포넌트 구성 기록에 의해 표현되는 상기 컴포넌트의 그룹에 대 한 설명;
    상기 그룹 컴포넌트 구성 기록의 벤더 명칭; 및
    상기 그룹 컴포넌트 구성 기록의 벤더 식별자를 포함하는 모듈식 테스트 시스템.
  21. 제14항에 있어서,
    상기 시스템 프로파일은,
    상기 하드웨어 테스트 모듈 버전에 특유한 소프트웨어 컴포넌트;
    사용자 소프트웨어 개발 키트; 및
    벤더 소프트웨어 개발 키트를 포함하는 모듈식 테스트 시스템.
  22. 제21항에 있어서,
    상기 하드웨어 테스트 모듈 버전에 특유한 상기 소프트웨어 컴포넌트는,
    디바이스 드라이버;
    에뮬레이션 소프트웨어 컴포넌트;
    교정 소프트웨어 컴포넌트; 및
    진단 소프트웨어 컴포넌트를 포함하는 모듈식 테스트 시스템.
KR1020077014690A 2004-12-09 2005-12-08 테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및시스템 KR20070106692A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US63509404P 2004-12-09 2004-12-09
US60/635,094 2004-12-09
US11/100,109 2005-04-05
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 (1)

Publication Number Publication Date
KR20070106692A true KR20070106692A (ko) 2007-11-05

Family

ID=35911084

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077014690A KR20070106692A (ko) 2004-12-09 2005-12-08 테스터 장치 모듈의 설치 및 구성 관리를 수행하는 방법 및시스템

Country Status (7)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101231746B1 (ko) * 2009-12-18 2013-02-08 한국전자통신연구원 ＳａａＳ 환경에서의 소프트웨어 개발 시스템
KR20210122197A (ko) * 2020-03-31 2021-10-08 주식회사 아도반테스토 향상된 보조 인터페이스 테스트 시스템 및 방법

Families Citing this family (65)

* 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
KR101730513B1 (ko) 2009-02-13 2017-04-26 아브 이니티오 테크놀로지 엘엘시 태스크 실행 관리
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
WO2011159759A1 (en) 2010-06-15 2011-12-22 Ab Initio Technology Llc Dynamically loading graph-based computations
US20120198436A1 (en) * 2011-01-27 2012-08-02 Preimesberger Lee A Compatible Operating System
CN103165405A (zh) * 2011-01-27 2013-06-19 北京确安科技股份有限公司 一种通过gpib接口实时生成多维变量密码方法
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
US9632764B2 (en) * 2012-12-31 2017-04-25 Oracle International Corporation Defining configurable characteristics of a product and associating configuration with enterprise resources
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
CA2932763C (en) 2013-12-05 2022-07-12 Ab Initio Technology Llc Managing interfaces for dataflow graphs 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
US10671669B2 (en) 2015-12-21 2020-06-02 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 立端科技股份有限公司 自动测试主机操作系统的测试方法及其测试系统
TWI760691B (zh) * 2020-02-12 2022-04-11 瑞昱半導體股份有限公司 自動測試軟體相容性的方法、測試裝置與系統
US11650893B2 (en) 2020-03-31 2023-05-16 Advantest Corporation Multiple name space test systems and methods
US11733290B2 (en) 2020-03-31 2023-08-22 Advantest Corporation Flexible sideband support 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
US11821913B2 (en) 2020-11-02 2023-11-21 Advantest Test Solutions, Inc. Shielded socket and carrier for high-volume test of semiconductor devices
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
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 珠海视熙科技有限公司 批量刷机压力测试方法及装置、存储介质、计算机设备

Family Cites Families (20)

* 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
US6182275B1 (en) * 1998-01-26 2001-01-30 Dell Usa, L.P. Generation of a compatible order for a computer system
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 华为技术有限公司 一种跨平台的联合仿真系统
JP2002123562A (ja) * 2000-07-31 2002-04-26 Hitachi Ltd テスタ構築データの生成方法およびテスタの構築方法並びにテスト回路
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
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
US7228326B2 (en) * 2002-01-18 2007-06-05 Bea Systems, Inc. Systems and methods for application deployment
US7437261B2 (en) 2003-02-14 2008-10-14 Advantest Corporation Method and apparatus for testing integrated circuits
US20040194064A1 (en) * 2003-03-31 2004-09-30 Ranjan Mungara Vijay Generic test harness
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
US7197416B2 (en) 2004-05-22 2007-03-27 Advantest America R&D Center, Inc. Supporting calibration and diagnostics in an open architecture 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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101231746B1 (ko) * 2009-12-18 2013-02-08 한국전자통신연구원 ＳａａＳ 환경에서의 소프트웨어 개발 시스템
KR20210122197A (ko) * 2020-03-31 2021-10-08 주식회사 아도반테스토 향상된 보조 인터페이스 테스트 시스템 및 방법
US11899550B2 (en) 2020-03-31 2024-02-13 Advantest Corporation Enhanced auxiliary memory mapped interface test systems and methods

Also Published As

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

Similar Documents

Publication Publication Date Title
US8082541B2 (en) Method and system for performing installation and configuration management of tester instrument modules
US9940330B2 (en) System and method for converting a physical disk to a virtual disk
JP5362974B2 (ja) ソフトウェア製品の出荷用仮想化ソフトウェアの使用方法
US7478385B2 (en) Installing software using programmatic component dependency analysis
US7228541B2 (en) Creation of application system installer
US8132166B2 (en) Methods and systems for provisioning software
US20070204262A1 (en) Facilitating the automated testing of daily builds of software
US20080178143A1 (en) System, Method and Computer Program Product for Developing, Configuring, Installing and Testing Software
US20080320465A1 (en) Methods and systems for porting software packages from one format to another
CZ25397A3 (en) Computer system
CA2016396C (en) Initial program load (ipl) based on an object abstraction for a data processing system
Kraimer et al. EPICS IOC software configuration management
Kuhn et al. Chapter 1 Installing the Oracle Binaries
Hemel NixOS: the Nix based operating system INF/SCR-05-91
Headquarters installDir/product_name/3rd_party_licensor_notice. pdf installDir/legal-notices
NETBEANS Setting Up Rails Projects
Installation et al. H-Sphere Sysadmin Guide
ACES et al. How to Automate and Not Manage under Rhine/Redwood
Kutler et al. Working with Rails Projects
Edition Best Practices
Blades et al. HP-UX 11i v3 Installation and Update guide
Casey Linux on the ARM Integrator Compact Platform (CP)
SERIES Windows Installation and Update Troubleshooting
Alapati Installing the Oracle Database 10 g RDBMS
Oracle Installing the Oracle Database 10g RDBMS

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid