secsgem의 이해 - devpiapds.devpia.com/maeul/781/maeul_addboard/39000/38385/fundamental_rea… ·...

SECSGEM의 이해

한미반도체 시스템제어연구부 S/W팀 편집

2006.05.26

2001002

사각형

2001002

사각형

목 차

1. SECS 프로토콜의 이해

2. SECS-I 프로토콜

3. HSMS 프로토콜

4. SECS II 메시지 프로토콜

5. GEM 요약설명

반도체 장비 인터페이스를 위한 SECS 프로토콜의 이해

반도체 소자의 집적도 증가에 따라 제조 현장의 고도의 청정도 유지 및 제품의 신뢰도 향

상을 위한 제조 공정의 자동화 요구는 날로 증가하고 있다. 또한 기업의 각 업무간을 컴퓨

터를 이용 통합함으로써 경영의 효율화를 도모하려는 CIM 구현의 일단으로서 생산현장의

자동화는 반드시 실현되어야 할 과제인 것이다.

오늘날 선진 반도체 공장에서는 이미 자동반송장치, AGV, 로보트 등을 이용하여 생산현장

의 무인화를 위한 많은 진전이 이루어지고 있으며, 관련 기술개발을 통한 생산성 향상을 도

모하기 위해 노력을 배가하고 있다.

이와같은 내외적인 요구에 따라 관련기술의 표준화를 위해 SEMI(Semiconductor

Equipment and Materials International)의 장비자동화 부문(Equipment Automation Division)

에서 반도체 장비와 외부 컴퓨터간의 인터페이스를 위한 데이타 통신의 표준 규약인

SECS(SEMI Equipment Communications Standard) Protocol을 제창하였고, 반도체 장비 생

산업체에게 이를 옵션으로 적용 하도록 요구하게 됨으로써 대부분의 반도체 생산관련 장비

가 인터페이스 부문에서 이 표준을 따르게 되었다.

그러므로 SECS의 체계를 이해하는 것은 자동화를 위한 인터페이스의 첫 단계에서 필수

사항이며, 자동화에 대한 이해 및 보다 성숙된 시스템 구현을 위해 필요하다고 생각한다.

장비가 제조공정 수행을 위해 호스트로부터 작업지시를 받거나 장비의 가동상태나 공정조건

등의 파라메타 데이타를 호스트로 전송하여 분석/활용될 수 있도록 하는 등 생산자원의 중

앙집중 관리를 위해서는 상호간에 물리적으로 연결된 네트웍이 구성되어야 하며, 전송된 데

이타를 인지하고 응답할 수 있는 통신규약이 필요한데, SECS 프로토콜은 이러한 상호간의

통신을 규정하는 표준 규약으로 메시지 전송체계를 규정하는 SECS-I 및 메시지 내용의 구

조를 규정하는 SECS-II 부문으로 구성된다.

상호 인터페이스를 위해서는 우선 장비에서 지원되는 SECS 메시지의 기능이 정확히 분석

/검증되어야 하며 필요한 자동화 기능을 수행하기 위한 메시지 내용이 포함되어 있지 않을

경우 장비 벤더에게 요청하여 추가토록 해야 할 경우도 발생되며 이를 위해서 자동화 담당

부서와 공정관리, 장비관리, 생산 등 관련 부서간의 긴밀한 협력 관계의 형성이 필요하다.

2001002

노트

2001002에 의해 설정된 Marked

장비와 호스트간 통신절차

반도체 장비와 호스트 컴퓨터간 인터페이스를 위한 기본적인 구성을 보면 아래와 같다.

SFC (Shop Floor Controll) 시스템으로, 생산현장의 생산활동을

관리하고 지원하는 공장 호스트.

장비와 임의의 정보교환을 위한 동작을 만들어 낸다

장비로 하여금 교환되는 정보에 따라 실제의 동작을 수행하도

록 유도하는 프로그램.

장비와 애플리케이션 프로그램 사이에서 메시지 교환을 중계하

는 통신 소프트웨어 (SECS Driver로 SECS 규약을 따름)

호스트에서 요구하는 동작을 수행하며 통신 소프트웨어에 응답

을 전달한다.

- 1 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII

SEMI E4-0699SEMI EQUIPMENT COMMUNICATIONS STANDARD 1 MESSAGETRANSFER (SECS-I)

1. 개 요

1.2 범위 - SECS-I 표준은 반도체 처리 장비와 호스트간의 메시지 교환에 적합한 통신 인터페이스

를 정의한다. 반도체 처리 장비는 웨이퍼 생산, 웨이퍼 처리, 처리 측정, 조립, 포장을 하는 장비

를 포함한다. 호스트는 생산을 수행하기 위해 장비와 정보를 교환하는 컴퓨터 혹은 컴퓨터 네트워

크이다. 이 표준은 물리적 연결자, 신호 수준, 데이터 비율, 시리얼 데이터 경로에서 호스트와 장

비간의 메시지 교환에 필요한 로직 프로토콜의 설명을 포함한다. 이 표준은 메시지 내에 포함된 데

이터는 정의하지 않는다. 메시지의 의미는 SEMI Equipment Communications Standard E5 (SECS-II)

와 같은 어떤 메시지 내용 표준을 통해 정의되어진다.

1.3 목적 - 이 표준은 각각의 특정 지식이 필요없이 연결될 수 있는 장비와 혹은 호스트를 생산하

는 독립된 생산자에게 수단을 제공한다.

1.3.1 프로토콜 레이어 - SECS-I 프로토콜은 포인트-포인트 통신에서 사용되는 프로토콜 레이어

로 생각할 수 있다. SECS-I내 레벨은 물리적 링크, 블록 전송 프로토콜 그리고 메시지 프로토콜

이다. (R1-1.1)

1.3.2 속도 - 이 표준은 모든 가능한 애플리케이션의 통신 요구사양을 만족시키지는 않는다. 예

를 들어, RS-232의 속도는 매우 빠른 기능의 테스트 애플리케이션에서 요구되는 짧은 시간에서

의 프로그램이나 많은 데이터 양을 전송하기에 충분하지 못하다.

1.3.3 네트워크 지원 - 데이터의 블록들이 장비로 전소되거나 적당한 호스트로 되돌아오는 방법

에 대해서 SECS-I에서는 정의하지 않는다. 네트워크에서 호스와 장비의 역할은 네트워크의 어떤

부분으로 가정되어진다. 이 상황에서 통신 링크의 한 끝은 장비의 역할이 되고, 다른 한 끝은

호스트의 역할이 된다.

1.5 SECS-I 개관 - SECS-I 표준은 연결자와 전압에 대해 EIA RS-232-C와 JIS C 6361와 같이 잘 알

려진 국제 표준을 사용한 포인트-포인트 통신을 정의한다. 실제 전송은 1-bit 시작과 1-bit 정지

비트를 갖고 시리얼로 전송되는 8-bit 바이트들로 구성된다. 통신은 양방향이고 비동기이며 한순간

에 한 방향으로만 흐르게 된다. 데이터는 254 바이트이하의 블록으로 전송된다. 각 블록은 10 바이

트 헤더를 갖는다. 메시지는 한 방향 통신에서 완전한 통신 단위이고 1개에서 32,767개 블록들로

구성된다. 각 블록 헤더는 특정 메시지의 일부분으로써 블록을 정의하는 정보를 포함한다. 메시지

는 Transaction이라 불리는 요구와 응답으로 짝지어진다.

- 2 / 17 -


2. 전문 용어

2.1.1 ACK - "정확한 접수" 핸드셰이크 코드 (5.2)

2.1.2 애플리케이션 소프트웨어 - 장비나 호스트의 특정 업무를 수행하는 소프트웨어

2.1.3 블록 - 헤더 + 244 바이트의 데이터 (1.5, 6.7)

2.1.4 블록 길이 - 블록 전송 프로토콜에서 보내지는 바이트 수 (5.6)

2.1.5 블록 번호 - 메시지에서 블록에 번호를 매기는 헤더의 15 비트 필드 (6.7)

2.1.6 문자 - SECS-I 시리얼 라인상에서 전송되는 한 바이트 (4.1)

2.1.7 체크섬 - 전송 오류를 인지하는데 사용하는 16 비트 숫자 (5.7)

2.1.8 통신 실패 - 전송 실패에 의한 통신 링크에서 실패 (5.4)

2.1.9 디바이스 ID - 장비를 특정 짓는데 사용되는 헤더의 15 비트 필드 (6.3)

2.1.10 E-bit - 메시지의 마지막 블록을 나타내는 헤더의 1 비트 (6.6)

2.1.11 ENQ - "전송 요구" 핸드셰이크 코드

2.1.12 EOT - "수신 준비" 핸드셰이크 코드

2.1.13 장비 - 호스트와 통신하는 지능 시스템

2.1.14 기대되는 블록 - 메시지 프로토콜에 의해 기대되는 메시지의 블록 (7.4.4)

2.1.15 헤더 - 메시지와 Transaction 프로토콜에서 사용되는 10 바이트 데이터 요소 (6)

2.1.16 호스트 - 장비와 통신하는 지능 시스템

2.1.17 길이 바이트 - 전송하는 동안 블록 길이를 나타내는데 사용되는 문자 (5.6)

2.1.18 라인 제어 - 블록 전송 프로토콜의 부분 (5.8.2)

2.1.19 마스터 - 장비를 위한 블록 전송 지정 (5.5)

2.1.20 메시지 - 통신의 완전한 단위 (7)

2.1.21 메시지 ID - 메시지 정의 절차에서 사용되는 헤더의 15 비트 필드 (6.5, 7.3.1)

2.1.22 다중 블록 메시지 - 2개 이상의 블록으로 전송되는 메시지 (6.7, 7.2.2)

2.1.23 NAK - "부정확한 접수" 핸드셰이크 코드 (5.2)

2.1.24 열린 메시지 - 블록이 전부 수신되지 않는 다중 블록 메시지 (7.4.4)

2.1.25 열린 Transaction - 처리 중인 Transaction (7.3)

2.1.26 주 메시지 - 메시지 ID가 홀수인 메시지. 또한 Transaction의 첫 메시지이다. (6.5)

2.1.27 주/부 속성 - 블록이 주,부 메시지에 포함되어 있는지는 lower 메시지 ID의 LSB로 판단한다.

2.1.28 R-bit - 메시지 방향을 나타내는 헤더의 1 비트 (6.2)

2.1.29 수신자 - 메시지를 수신하는 SECS-I 링크의 한 끝 (5.8.4)

2.1.30 응답 - 주 메시지에 관련된 특정 부 메시지 (7.3)

2.1.31 응답 링킹 - 주 메시지와 부 메시지로 구성된 Transaction을 형성하는 절차 (7.3.1)

2.1.32 재시도 횟수 - 블록 전송 프로토콜에서 블록을 전송하는데 성공하지 못한 횟수 (5.4)

2.1.33 RTY - 블록 전송 프로토콜이 전송실패를 정의하기 전에 블록을 전송하고자 시도한 횟수의

제한 또는 시간 (5.4)

2.1.34 부 메시지 - 메시지 ID가 짝수인 메시지. 또한 Transaction의 두 번째 메시지이다. (6.5.2)

2.1.35 전송자 - 메시지를 전송하는 SECS-I 링크의 끝 (5.8.3)

2.1.36 슬레이브 - 호스트를 위한 블록 전송 지정 (5.5)

2.1.37 시스템 바이트 - 메시지 정의에 사용되는 4 바이트 필드 (6.8)

2.1.38 T1 - 블록 전송 프로토콜에서 수신 내부-문자 시간초과 (5.3.1)

2.1.39 T2 - 블록 전송 프로토콜에서 프로토콜 시간초과 (5.3.2)

2.1.40 T3 - 메시지 프로토콜에서 응답 시간초과 (5, 7.3.2)

- 3 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII2.1.41 T4 - 메시지 프로토콜에서 내부-블록 시간초과 (7.4.3)

2.1.42 Transaction - 주 메시지와 그와 관련된 부 메시지 (7.3)

2.1.43 W-bit - 응답이 기대되는 것을 나타내는 헤더의 1 비트 (6.4)

- 4 / 17 -


3. 결 합

3.2 전기적 인터페이스 - RS-232-C 인터페이스

3.2.1 연결자 - EIA RS232의 9핀 혹은 25핀 연결자를 사용한다.

3.2.2 신호핀 - 다음 표에서 설명한다.

25 핀 9 핀 RS-232-C 회로 회로 설명

1 - AA 실드

2 3 BA 장비로부터의 데이터

3 2 BB 장비로 가는 데이터

7 5 AB 신호 접지

18 - - +12 ~+15V DC

25 - - -12 ~-15V DC

[ 표 1. 신호 연결 ]

3.2.3 로직 레벨 - 핀2와 핀3에 대해, 로직 1 레벨은 -3V보다 작은 전압이고, 로직 0 레벨은

+3V보다 큰 전압이다. 전압은 ±25V를 넘을 수 없다. 이 값들은 RS-232-C 표준을 따른다.

3.2.4 전원 공급 - 25핀 연결자에서, 핀18과 핀25는 외부 절연 회로를 구동하기 위한 부가적인

전원 공급이다. 공급되면, 적어도 50㎃를 공급할 수 있어야 한다. (R1-2)

3.3 데이터 비율 - 신호 핀에서 지원되는 데이터 비율은 9600, 4800, 2400, 1200, 300 baud이다.

같은 데이터 비율은 데이터를 주고받을 수 있다. 부가적인 19,200과 150 baud는 원한다면 적용할

수 있다.

3.4 물리적 매체 - RS-232-C 전송 매체 사용

- 5 / 17 -


5. 블록 전송 프로토콜

5.1 시리얼 라인을 통해 통신방향을 설명하고 블록 전송 프로토콜이라 불리는 메시지 블록들을 전

달하는 환경을 제공하기 위해 사용되는 절차이다. 프로토콜의 대부분은 신호 바이트의 핸드셰이크

를 수행한다. 라인의 양 끝이 동시에 전송하고자 시도할 때, 라인 경쟁이라 알려진 조건이 존재하

게 된다. 프로토콜은 슬레이브(항상 호스트)로 지정되는 라인의 한 끝을 강요함으로써 경쟁을 해결

하고 전송을 미로며, 수신 모드로 들어가게 한다. 블록의 재전송은 정확한 통신 오류에서 사용된다.

블록 전송 프로토콜은 그림2의 흐름도에서 보여진다. 부가적인 정보는 R-3와 R1-4에서 보여 준다.

5.2 핸드셰이크 바이트 - 블록 전송 프로토콜에서 사용되는 4개의 표준 핸드셰이크 코드는 표2에서

보여 준다.

이름 코드 기능

ENQ 00000101 전송 요구

EOT 00000100 수신 준비

ACK 00000110 정확한 접수

NAK 00010101 부정확한 접수

[ 표 2. 핸드셰이크 코드 ]

5.3 시간초과 파라미터 - 시간초과는 통신 실패를 인지하는데 사용된다. 시간초과는 2개 이벤트간

의 측정된 시간이 미리 정의된 제한을 초과할 때 발생한다. 일반적으로, 오류가 발생했다고 판단할

수 있는 시간의 길이는 포함된 시스템에 의존한다. 한 상황에서 필요한 시간은 또 다른 상황에서보

다 매우 길어질 수도 있다. 그래서, 시간초과 값은 애플리케이션에 따라 조정되어야 한다. 블록 전

송 프로토콜에서, 시간초과 값을 필요로 하는 두 상황이 있다. 두 시간초과 값은 파라미터 T1과 T2

라고 불린다.

5.3.1 내부-문자 시간초과 T1 - 내부-문자 시간초과 T1은 길이 바이트가 수신되고 한 블록내의

문자 접수와 두 번째 체크섬 바이트의 접수까지의 시간을 제한한다.

5.3.2 프로토콜 시간초과 T2 - 프로토콜 시간초과 T2는 ENQ를 보내고 EOT를 받는데 걸린 시간과

EOT를 보내고 길이바이트를 받는데 걸린 시간, 그리고 두 번째 체크섬 바이트를 보내고 어떤 문

자를 받는데 걸린 시간을 제한한다.

5.4 재시도 제한 RTY - 재시도 제한 RTY는 블록 전송 프로토콜이 전송 실패를 정의하기 전에 블록

을 전송하고자 시도한 횟수 제한이다. (5.8.2)

5.5 마스터/슬레이브 - 마스터/슬레이브 파라미터는 경쟁의 해결로 사용된다(5.8.2). 호스트는 슬

레이브로 지정된다. 장비는 마스터로 지정된다. 이 합의는 장비가 호스트보다 더 적은 메시지를 저

장할 수 있다는 가정에 기초한다.

5.6. 블록 길이 - EOT의 접수 후에 보내지는 첫 바이트의 비부화된 정수 값은 보내지는 블록의 길

이다. 길이는 체크섬 2 바이트를 제외한 길이 바이트 이후의 보내지는 모든 바이트를 포함한다.

SECS-I에서 허용하는 최대 블록 길이는 254 바이트이고 최소는 10 바이트이다.

- 6 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII5.7 체크섬 - 체크섬은 한 블록에서 길이 바이트 이후부터 체크섬 전까지의 모든 바이트들의 비부

호화된 이진수의 숫자 합으로 계산된다. 체크섬은 블록 데이터의 마지막 바이트에 이어 2 바이트로

16 비트로써 전송된다. 체크섬의 상위 8 비트가 먼저 보내지고, 하위 8 비트가 뒤에 보내진다. 체

크섬은 전송 오류를 점검하기 위해 수신기에서 사용된다. 수신기는 수신된 헤더와 데이터에 대해

동일한 체크섬 계산을 수행한다.

5.8 알고리즘 - 블록 전송 프로토콜의 동작은 그림2에 잘 설명되어 있다. 이 흐름도는 프로토콜의

5 가지 상태(수신, 대기, 전송, 라인 제어, 완료)를 표현한다. 그림2의 흐름도는 특정 실행이 이

표준에서 요구되어진다는 것을 의미하지 않는다. 어쨋든, 어떤 SECS-I 블록 전송 프로토콜 실행이

라도 그림2에서 보여지는 모든 로직을 포함해야 한다. 동일한 알고리즘이 SECS-I 통신 링크의 각

끝에서 실행되어진다.

5.8.1 대기 상태 - 통신 링크의 양 끝은 대기 상태에서 시작된다고 가정한다. 대기 상태에서 빠

져나가는 2 가지 행동이 있다.

A. 전송(SEND) - 메시지 블록이 보내지려 한다.

B. 수신(RECEIVE) - 통신 링크의 다른 끝이 보내진 메시지 블록을 갖는다.

5.8.2 라인 제어 - 라인 제어는 전송 방향을 설명하고, 경쟁을 해결하며, 재시도를 다룬다. 대

기 상태에서 ENQ가 수신되면 라인 제어는 블록 전송 프로토콜이 수신할 준비가 되어 있다면 EOT

를 응답한다. 블록 전송 프로토콜은 수신 상태가 된다. 만약 메시지 블록을 보내려고 한다면, EN

Q가 보내진다. 만약 EOT가 시간 제한 T2 이내로 응답된다면 블록 전송 프로토콜은 전송 상태로

된다.

5.8.2.1 만약 슬레이브가 ENQ의 응답으로 ENQ를 받았다면, 경쟁이 발생한다. 슬레이브는 마

스터로부터 블록을 수신할 때까지 전송할 블록의 전송을 연기한다. 슬레이브는 들어오는 블

록을 수신할 준비를 하고, EOT를 전송한다. 블록 전송 프로토콜이 대기 상태로 돌아오면, 연

기되었던 블록은 새 전송 요구가 있는 것처럼 보내지게 된다. 마스터는 ENQ를 보내고 난 후,

EOT를 제외한 모든 문자를 무시한다. 슬레이브는 ENQ를 보내고 난 후, ENQ나 EOT를 제외한

모든 문자를 무시할 수 있다.

5.8.2.2 ENQ를 보내고 EOT를 수신하는데 걸린 시간이 T2를 초과하거나, 두 번째 체크섬 바이

트를 보내고 어떤 문자를 수신하는데 걸린 시간이 T2를 초과하거나, 두 번째 체크섬 바이트

를 전송하고 T2 이내에 NAK 문자가 수신되면, 라인 제어는 재시도 횟수를 증가한다.재시도

횟수가 RTY 파라미터 값을 넘지 않으면 블록 전송 프로토콜은 ENQ로 시작하는 블록을 전송하

고자 재시도한다. 재시도 횟수가 RTY 파라미터 값을 넘으면 전송 실패가 발생한다.

5.8.3 전송 상태 - 일단 전송 상태로 설정되면, 첫 바이트는 그 블록의 데이터의 길이 N가 된다.

N개 바이트가 전송되고 난 후, 체크섬 2 바이트가 전송된다. 전송자는 길이 바이트를 제외한 블

록 내 데이터와 블록 헤더를 기초로 체크섬을 계산한다. 전송자가 T2 이내에 ACK를 수신하면,

그 블록은 적절하게 전송되었다고 판단된다. 그러나, 전송자가 T2 이내에 NAK 문자를 수신하거

나, T2 이내에 아무 문자도 못 받는다면, 가능한 재시도로 라인 제어가 돌아가게 된다. 전송 상

태에서, 마지막 체크섬을 보내기 전에 수신된 문자는 무시될 수 있다.

- 7 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII5.8.4 수신 상태 - 일단 수신 상태로 설정되면, 수신되는 첫 바이트는 길이 바이트 N이 된다.

수신자는 이어지는 N+2 바이트를 카운트하고 저장한다. 마지막 2 바이트는 체크섬이다. 수신자

는 자신의 체크섬 계산과 2 바이트의 체크섬 을 비교한다. 정상 블록이면 계산된 것과 수신된

것은 같다.

5.8.5 수신 경쟁 - 한 블록이 정확히 수신된 후, ACK 문자가 전송되어 메시지 프로토콜은 한 블

록이 수신되었다고 알린다. 만약 길이 문자를 기다리는데 T2가 초과되거나, 문자가 수신되는 동

안 T1이 초과된다면, NAK가 전송된다. 만약 길이 바이트가 잘못되거나, 수신된 체크섬이 계산된

체크섬과 일치하지 않는다면, 수신자는 전송자가 전송을 마칠 때까지 모든 문자를 수신한다. 이

것은 내부-문자 시간이 T1을 초과했을 때 발생하고, 수신은 무시되며 NAK가 전송된다. NAK가 전

송되는 경우에, 수신자는 블록으로 수신한 데이터를 버리게 된다. 수신자는 ACK나 NAK를 보낸

후 바로 대기 상태로 들어간다.

5.8.6 전송 경쟁 - 두 번째 체크섬 바이트가 전송된 후, ACK가 T2내에 수신된다면, 메시지 프로

토콜은 전송이 성공했다고 알린다. 만약 전송 실패가 발생하면, 메시지 프로토콜은 실패로 알린

다. 애플리케이션-레벨 소프트웨어는 전송 실패 원인의 가능성을 가져갈 것이다.

- 8 / 17 -


대기

전송 요구?

LISTEN

ENQ ?

EOT 전송

tries=0

ENQ 전송

t=0

LISTEN

t>T2?

SLAVE & ENQ

EOT ?

경쟁

tries= tries+1

tries > RTY

전송실패

t=0

LISTEN

t>T2?

문자수신

ACK ?

전송완료

길이바이트(N)N 바이트

체크섬 2 바이트

t>T2?

t=0

LISTEN

길이바이트수신?

10≤N≤254

t=0

LISTEN

문자 수신?

DONE?

체크섬 OK?

수신완료

ACK 전송 NAK 전송NAK 전송

t>T1?

LISTEN

t=0

문자 수신?

t>T1?

[ 그림 2. 블록 전송 프로토콜 ]

YES

NO

YES

NO

YES

NO

YESNOYES

NO

YES

NO

YES

YES

NO

NO

NO

YES

YES

NO

YES

NOYES

YES

YES

NO

NO

NO

YES

YES

NO

NO

YES

YES

NO

NO

대기 상태로 돌아가기

대기

전송

수신

경쟁

라인 제어

- 9 / 17 -


6. 헤더 구조

6.1 블록 전송 프로토콜상의 모든 통신 기능들의 동작은 헤더라 불리는 10 바이트 데이터 요소에

포함된 정보에서 연결된다. 헤더는 항상 블록 전송 프로토콜에 의해 전송되는 모든 블록의 첫 10

바이트이다. 헤더의 정보는 또한 메시지 프로토콜(7.)에 의해 사용된다. 헤더의 고정된 형식은 이

절에서 설명된다. 일반적인 헤더 구조는 그림3에 보여진다.

주의 : 헤더는 또한 SECS-II에서 요구되는 정보를 포함한다.

8 7 6 5 4 3 2 1

1 R 상위 디바이스 ID

2 하위 디바이스 ID

3 W 상위 메시지 ID 스트림

4 하위 메시지 ID 펑션

5 E 상위 블록 ID

6 하위 블록 ID

7 시스템

8 시스템

9 시스템

10 시스템

[ 그림 3. 블록 헤더 구조 ]

6.2 역순 비트 (R-Bit) - 역순 비트 (R-bit)는 메시지의 방향을 나타낸다. R-bit는 장비로 가는 메

시지는 0으로 설정되고, 호스트로 가는 메시지는 1로 설정된다. R-bit는 메시지의 방향이 모든 블

록에 포함되도록 헤더에 포함된다.

R-bit 디바이스 ID 메시지 설명

0 도착지 호스트에서 장비

1 발신지 장비에서 호스트

[ 표 3. R-bit의 영향 ]

6.3 디바이스 ID - 디바이스 ID는 표3에 보여지는 것처럼 R-bit의 값에 따라 메시지의 발신지나 도

착지를 정의한다. 디바이스 정의는 장비의 정보이고 8절에 따라 설정되어야 한다. 호스트는 장비

내 물리적 장치에 연결되는 로직 정의자로써 디바이스 ID를 볼 수 있다. 호스트는 디바이스 ID가

없다.

6.4 대기 비트 (W-Bit) - 대기 비트 (W-bit)는 주 메시지의 전송자가 응답을 기대함을 나타낸다.

W-bit의 값이 1이면 응답이 기대된다는 것을 의미한다. W-bit의 값이 0이면 응답이 기대되지 않음

을 의미한다. W-bit는 모든 부 메시지에서 0으로 설정되어야 한다. 다중 블록 메시지에 대해서, 전

송자는 W-bit가 메시지의 모든 블록에서 동일하게 해야 한다.

6.5 메시지 ID - 메시지 ID는 전송되는 메시지의 형식과 내용을 정의한다. 정확한 메시지 내용은

장비에 의존한다. 상위 메시지 ID는 ID의 매우 중요한 역할을 한다.

6.5.1 주 메시지 - 주 메시지는 홀수 번호인 메시지로 정의된다. 홀수 번호인 메시지는 하위 메

- 10 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII시지 ID의 비트1이 1로 설정되어 있을 것이다.

6.5.2 부 메시지 - 부 메시지는 짝수 번호인 메시지로 정의된다. 짝수 번호인 메시지는 하위 메

시지 ID의 비트1이 0으로 설정되어 있을 것이다.

주의 : SECS-II에서, 헤더의 세 번째 바이트(W-bit를 제외한)는 스트림으로 알려져 있고, 네 번

째 바이트는 펑션으로 알려져 있다.

6.6 종료 비트 (E-Bit) - 종료 비트(E-bit)는 블록이 메시지의 마지막 블록임을 정의한다. E-bit의

값이 1이면 그 블록은 마지막 블록임을 의미하고, 0이면 뒤이어 다른 블록들이 있음을 의미한다.

6.7 블록 번호 - 한 개 블록 이상의 블록이 전송되는 메시지는 다중 블록 메시지라고 한다. 첫 블

록은 블록 번호 1을 갖고, 그 블록 번호는 전체 메시지가 보내질 때까지 하나씩 증가한다. 다중 블

록 메시지의 블록들은 순서대로 전송된다. 단일 블록 메시지에서, 블록 번호는 항상 0이나 1의 값

을 갖는다. 최대 블록 번호는 32.767이다. 상위 블록 번호는 블록 번호에서 중요한 역할을 한다.

(7.2 참조)

6.8 시스템 바이트 - 주어진 디바이스 ID에 대한 각 메시지의 헤더에서 시스템 바이트는 다음 요구

사항을 만족해야 한다. (R1-5 참조)

6.8.1 구별 - 주 메시지의 시스템 바이트는 현재 모든 열린 Transaction과 구별되어야 하고, 통

신 링크의 동일한 끝과 구별되어야 한다. 가장 최근에 완성된 Transaction과도 구별되어야 한다.

(7.3 참조) 가장 최근에 성공한 블록 전송이 된 이후에 성공하지 못한 블록들의 시스템 바이트

와도 구별되어야 한다.

6.8.2 응답 메시지 - 응답 메시지의 시스템 바이트는 관련된 주 메시지의 시스템 바이트와 동일

하다.

6.8.3 다중 블록 메시지 - 다중 블록 메시지의 모든 블록들의 시스템 바이트는 동일하다.

- 11 / 17 -


7. 메시지 프로토콜

7.1 메시지는 한 방향으로의 완성된 통신 단위이다. 메시지 프로토콜은 메시지를 전송하고 수신하

기 위해 블록 전송 프로토콜의 서비스를 사용한다. 메시지는 헤더에서 다음 정보를 갖는 메시지 데

이터로 구성된다. (R-bit, 디바이스 ID, W-bit, 메시지 ID, 시스템 바이트)

7.2 메시지 전송 - 메시지가 전송될 준비가 되면, 메시지 전송 프로토콜은 아래에 기술된 기능들을

수행한다. 블록 전송 실패는 그 메시지에서 메시지 프로토콜 동작을 종료한다.

7.2.1 메시지 길이 - 메시지에서 블록 하나의 최대 데이터 길이는 244 바이트이다. 다중 블록

메시지에서 전송할 수 있는 최대 블록 개수는 32.767개이고, 하나의 메시지에서 허용될 수 있는

최대 데이터 길이는 244 X 32,767 바이트이다.

7.2.2 메시지 저지 - 메시지 저지는 블록 전송 프로토콜에서 전송되는 블록들의 메시지 데이터

의 구분이다. 전송자는 최대 254 바이트로 마지막 블록을 제외한 다중 블록 메시지의 블록들을

채운다. 다중 블록 메시지의 수신자는 11에서 254 바이트 크기의 어떤 블록도 수용할 수 있고,

연속되는 블록들이 같은 크기일 필요는 없다.

7.2.2.1 어떤 오래된 장비는 들어오는 메시지에 대해 블록 크기가 애플리케이션에 특정 지어

지도록 강요한다. 1988년에 표준에서는 이 강요를 하지 않도록 정하고 있다.

주의 : SECS-II에서, 어떤 메시지는 단일 블록 메시지로 정의되고, SECS-I에서 단일 블록으

로써 전송되어야 한다.

7.2.3 헤더 - 메시지 프로토콜은 6절에의 요구에 따라 각 블록에 헤더를 설정해야만 한다.

7.2.4 끼워 넣는 메시지 - 하나 이상의 열린 Transaction의 지원을 허용한다. (필요하진 않다.)

다른 다중 블록 메시지 의 블록들의 끼워 넣기를 허용한다. (필요하진 않지만..,) (9 참조)

7.3 Transactions - Transaction은 주 메시지와 응답이라 불리는 관련된 부 메시지이다.

Transaction은 주 메시지가 보내질 준비가 되면 열려진다. Transaction은 응답이 요구되지 않는 주

메시지의 마지막 블록이 전송되거나, 응답의 마지막 블록이 수신되면 닫힌다.

7.3.1 응답 링킹 - 응답이 주 메시지에 대해 기대될 때, 메시지 프로토콜은 메시지의 마지막 블

록이 성공적으로 전송된 후 Transaction에 대해 응답 타이머를 가동한다. 주 메시지가 응답을

요구하며 보내지면, 기대되는 블록은 메시지 수신 알고리즘으로 설정된다. (7.4) 기대되는 블록

은 R-bit의 보수를 갖고, 동일한 디바이스 ID를 갖으며 부 메시지의 첫 블록일 것이고, 주어진

주 메시지의 것과 동일한 시스템 바이트를 갖을 것이다.

주의 : SECS-II에서, 응답은 동일한 상위 메시지 ID (스트림)을 갖고, 하위 메시지 ID (펑션)은

관련된 주 메시지의 것보다 하나 크거나 0이 될 것이다.

- 12 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII7.3.2 응답 시간초과 T3 - 응답 시간초과 T3는 메시지 프로토콜이 주 메시지의 마지막 블록이

전송된 후 응답의 첫 블록이 수신되기 전까지의 시간 제한이다. 만약 응답의 첫 블록이 T3 제한

시간 내에 수신되지 않으면, 기대했던 블록은 기대되는 블록 리스트에서 제거되고, Transaction

은 종료된다. 응답 타이머로 불리는 타이머는 주 메시지의 마지막 블록과 그 응답의 첫 블록간

의 시간을 측정한다. 응답이 기대되는 각 열린 Transaction은 구분된 응답 타이머를 갖는다.

7.4 메시지 수신 - 블록 전송 프로토콜에 의해 성공적으로 수신된 각 블록은 메시지 프로토콜로 전

달된다. 블록들을 확인하는 메시지 프로토콜의 역할을 하고 적절한 메시지로 그것들을 조립하는 역

할을 한다.

7.4.1 오류 발송 - 어떤 장비가 자신의 디바이스 ID와 일치하지 않는 디바이스 ID를 갖는 데이

터의 블록을 수신하면, 블록은 오류가 발생했다고 여겨진다.

7.4.2 중복 블록 검사 - 중복 블록은 블록 저송 프로토콜에 의해 수신된 이전 블록과 완전히 동

일한 블록이다. 이것은 수신자가 ACK를 전송할 때 발생할 수 있다. ACK는 전송자에서 제때 도착

하지 않아 재시도를 발생할 수 있다. 중복 블록은 메시지 프로토콜에 의해 검사된 이전에 수신

된 블록의 헤더와 현재 수신된 블록의 헤더를 비교하는 SECS-I 메시지 프로토콜에 의해 검사된

다. 헤더가 일치한다면, 새 블록은 중복되었고 버려질 것이다. 헤더가 다르다면, 새 블록은 중

복되지 않은 것이다. 비중복 블록의 헤더는 블록 전송 프로토콜에 따라 다음 블록과 비교하기

위해 저장되고, 헤더를 포함한 블록은 메시지 수신 알고리즘에 따라 처리될 것이다.

주의 : SECS-I의 1980년 버전을 따르는 어떤 장비들은 중복 블록 검사에 필요한 단일 헤더를 제

공하지 않는다. 중복 블록 검사를 사용하지 않는 옵션은 이들 시스템에 따라 요구될 수 있다.

7.4.3 내부-블록 시간초과 T4 - 다중 블록 메시지에서 한 블록의 성공적인 접수와 동일한 메시

지에서 이어지는 블록의 성공적인 접수 사이의 시간은 T4의 제한을 받는다. 이 시간이 초과되면,

메시지는 취소되고 Transaction은 종료된다. 내부-블록 타이머라 불리는 시간은 메시지 프로토

콜에서 블록 도착 시간을 측정하는데 사용된다. 현재 프로토콜에 의해 열려진 각 다중 블록 메

시지에 대해 하나의 내부-블록 타이머가 존재해야 한다. 메시지의 성공적인 블록이 수신되면,

관련된 내부-블록 타이머는 리셋된다.

7.4.4 알고리즘 - 메시지 프로토콜에서 블록이 수신될 때, 헤더에서 모든 바이트들의 조합은 그

블록이 무엇을 하는지를 정의하는데 사용된다. 메시지 수신 알고리즘의 동작은 그림4의 흐름도

에서 설명된다. 그림4 흐름도와 알고리즘의 설명은 특정 장비가 이 표준을 요구하는 것을 의미

하지 않는다. 어쨌든, SECS-I 메시지 프로토콜 장비는 그림4에 보여지는 모든 로직을 포함해야

한다.

7.4.4.1 메시지 프로토콜의 설명은 기대되는 블록의 개념을 사용한다. 블록이 메시지 프로토

콜에 의해 수신될 때, 그 블록이 기대되는 블록인지 아닌지를 먼저 판단한다. 블록이 기대되

는 블록인지 판단하기 위해, 헤더 정보는 기대되는 블록 리스트에 있는 헤더 정보와 비교되

어 진다.

7.4.4.2 블록이 기대되는 블록이 아니라면, 주 메시지의 첫 블록일 것이고, 아니면 오류로

전송된 것이며 버려질 것이다. 블록이 주 메시지의 첫 블록이고 메시지의 마지막 블록이 아

- 13 / 17 -

SSSSSEEEEECCCCCSSSSS ----- IIIII니라면 (E-bit = 0), 메시지의 내부-블록 타이머는 0으로 설정되고 메시지에 대한 기대되는

블록은 같은 R-bit, 디바이스 ID, 시스템 바이트, W-bit, 메시지 ID, 그리고 수신된 블록보

다 하나 큰 블록 번호를 갖을 것이다.

7.4.4.3 블록이 기대되는 블록이라면, 응답 메시지의 첫 블록이거나 열린 메시지의 부분일

것이다.

7.4.4.4 블록이 응답 메시지의 첫 블록이라면, 메시지의 응답 타이머는 취소된다. 응답 메시

지의 첫 블록에 대해, 기대되는 블록은 블록 번호가 1일 것이고(단일 블록 메시지라면 0일수

도 있다.), 부 메시지가 될 것이다. 하지만, 전체 메시지 ID는 발견되지 않는다. (7.3.1)

7.4.4.5 블록이 메시지의 마지막 블록이라면(E-bit = 1), 메시지는 완료된다. 메시지가 요구

되는 응답의 주 메시지라면(W-bit = 1), 시스템 바이트는 응답 메시지를 보내라고 저장된다.

(7.2.3)

7.4.4.6 블록이 메시지의 마지막 블록이 아니라면(E-bit = 0), 메시지에 대해 내부-블록 타

이머가 리셋되고, 메시지의 기대되는 블록은 같은 R-bit, 디바이스 ID, 시스템 바이트,

W-bit, 메시지 ID, 그리고 수신된 블록보다 하나 큰 블록 번호를 갖는다.

- 14 / 17 -


[ 그림 4. 메시지 수신 알고리즘 ]

블록수신

아는 디바이스?

NO

YES

중복?

기대 블록?

주메시지?

첫블록?

부메시지?

첫블록?

내부-블록타이머취소

주메시지블록더하기

내부-블록타이머취소

부메시지블록더하기

응답타이머취소

부메시지첫블록

마지막블록?

마지막블록?

부메시지완료

내부-블록타이머 설정

기대블록설정

주메시지완료

W-bit=1?

응답으로시스템바이트

저장

블록오류

블록버리기

기대블록설정

내부-블록타이머 설정

주메시지첫블록

YES

YES

YES

YES

YES

YES

YES

YES

YES

NO

NO

NO

NO

NO

NO

NO

NO

NO

다음 블록 기다리기

- 15 / 17 -


8. 파라미터 설정

8.1 8개의 프로토콜 파라미터가 표4에 정리되어 있다. Baud Rate 선택은 시스템 성능에 기초한다.

디바이스 ID 값은 특정 시스템 사양에 의해 결정되고, 일반적으로 한 공장 내에 유일하다. 다음 다

섯 개의 파라미터 값들은 호스트 시스템의 성능 특성과 통신 채널의 Baud Rate에 따라 결정된다.

앞에서 7개의 파라미터들은 사용자에 의해 결정된다. 모든 파라미터는 전원이 꺼지거나 시스템 소

프트웨어가 다시 올려져도 유지될 수 있도록 저장되어야 한다. 프로토콜 파라미터의 범위와 결정은

표4를 따른다. M/S 파라미터는 장비가 마스터이고 호스트가 슬레이브로 설정되어야 한다.

심볼 파라미터 이름 일반적인 기능 일반적인 값 범위 분해능

BAUD Baud Rate 시리얼 라인의 속도 설정 9600 300 ~9600 3.3절

DEVID 디바이스 ID 설비와 관련된 구분자 - 0 ~32767 1

T1 내부-문자 시간초과 문자간 방해를 검사 0.5초 0.1 ~10초 0.1초

T2 프로토콜 시간초과 프로토콜 응답 부족 검사 10초 0.2 ~25초 0.2초

T3 응답 시간초과 응답 메시지 부족 검사 45초 1 ~120초 1초

T4 내부-블록 시간초과 다중 블록 메시지에서 방해 검사 45초 1 ~120초 1초

RTY 재시도 제한 전송 재시도 허용 최대 횟수 3 0 ~31 1

M/S 마스터 슬레이브 경쟁 해결 - - -

[ 표 4. 프로토콜 파라미터 ]

- 16 / 17 -


관련 정보

주의 - 본 관련 정보에 포함된 내용은 SEMI E4(SECS-I)의 공식적인 부분은 아니고, 공식적인 표준은 수

정하려는 것은 아니다. 더욱이, 이 정보는 표준에 기술한대로 프로토콜을 실행하는 가능한 방법을 설명

하는 것이다. 표준은 모든 경우에 참조가 되어진다. SEMI는 어떤 특정 애플리케이션에 대해 내용의 적

합성을 보증하지는 않는다. 이건 사용자의 책임이다.

R1-1. SECS-I의 잡다한 주석

R1-1.1 계층적 프로토콜 (1.3.1) - 국제 표준 기구 (ISO)는 개방 시스템 연결(OSI)에 대해 모델을

발표했다. SECS-I 프로토콜은 ISO/OSI 모델을 모두 선행하고 실제 "개방 시스템"은 아니다. 그래서

정확히 ISO/OSI 모델과 관련이 없다. SECS-I 프로토콜은 네트워크 프로토콜보다 나은 통신 인터페

이스이다. 어쨌든, SECS-I 레벨은 ISO/OSI 모델의 5 계층 중 1 계층과 비교가 된다. ISO/OSI 1 계

층인 물리적 링크 계층은 SECS-I 물리적 링크와 관련있다. ISO/OSI 2 계층인 데이터 링크 계층은

SECS-I 블록 전송 프로토콜과 관련이 있다. ISO/OSI 3 계층인 네트워크 계층은 호스트의 기능이고,

양방향에 대해 SECS-I과 관련있다. ISO/OSI 4 계층인 운송 계층은 SECS-I 블록 전송 프로토콜, 중

복 블록 검사, 메시지 프로토콜과 관련있다. ISO/OSI 5 계층인 세션 계층은 SECS-I 메시지 프로토

콜에 의해 부분적으로 다루어진다.

R1-1.2 T1과 T2에 대한 단일 타이머 (5.3) - 단일 타이머는 내부-문자 타이머와 프로토콜 타이머에

대해 사용된다.

R1-1.3 Stalling (5.8.2) - 블록 전송 프로토콜의 라인 제어 역할은 ENQ를 수신하고 즉시 EOT를 응

답지 않음으로써 데이터 블록의 접수를 지연하는 능력을 가진다. 수신자에 의한 이같은 행동을

"Stalling"이라 한다. 만약 지연이 송신자의 T2 값을 넘으면 송신자는 또 다른 ENQ를 보낼 것이다.

이것은 송신자의 T2와 RTY 설정에 따른다.

R1-1.4 NAK의 원인 정의(5.8.5) - 블록 전송 프로토콜은 송신자가 NAK의 원인을 정의하는 방법을

포함하지 않는다. 만약 이같은 정보가 애플리케이션 목적에 필요하다면, 수신 끝에 모아야 할 것이

다.

R1-1.5 긴 메시지의 마스터 전송(5.8) - 마스터가 긴 메시지를 전송할 때, 슬레이브는 블록을 보낼

수 없다. 슬레이브가 거의 블록을 보낼 기회를 갖지 못하여 마스터가 블록간 충분히 지연을 갖을

수 있는 좋은 방법이다.

R1-1.6 디바이스 정의(6.3) - 디바이스 ID 15비트는 32,767개의 다른 장비를 정의할 수 있음에도

불구하고, 호스트는 spinner 혹은 diffusion furnace 같은 장비의 종류를 구분하는데 상위 7비트를

사용하는 것이 편리할 것이다. 하위 8비트는 그 종류의 특정 장비를 정의하는데 사용한다.

R1-1.7 다중 열린 메시지 전송(7.2.4) - 표준에서 정의된 메시지 프로토콜 알고리즘은 여러 개의

다중 블록 메시지의 블록들을 끼워 넣기가 가능하다. 수신 프로토콜은 수신되는 각 메시지들의 블

록들간 시간에 민감하므로, 전송 알고리즘이 끼워지는 다중 블록 메시지에서 블록들은 보낼 때 메

시지를 선택하는데 적합하다.

- 17 / 17 -


R1-1.8 T3와 T4에 대한 단일 타이머(7.3.2, 7.4.3) - 주어진 Transaction에서 단일 타이머는 내부-

블록 타이머와 응답 타이머에 대해 사용된다. 두 개는 성공적으로 수신된 메시지의 블록간 시간이

며 두 제한은 동시에 영향을 주지 않는다.

R1-2 절연

R1-2.1 3.4절에서 언급했듯이, 표준 RS-232-C 라인은 장비 접지와 중앙 컴퓨터사이에 절연을 제공

하지 않는다. 통신 에러를 줄이고 장비를 보호하기 위해 절연을 제공할 수 있다. 다음 예는

RS-232-C를 사용하는 두 장비간의 절연을 어떻게 제공할 수 있는지를 보여 준다.

R1-5 시스템 바이트

R1-5.2 소스 ID와 Transaction ID - 시스템 바이트는 그림 R1-4와 같이 소스 ID와 Transaction ID

로 나뉜다.

8 7 6 5 4 3 2 1

1 R 상위 디바이스 ID

2 하위 디바이스 ID

3 W 상위 메시지 ID

4 하위 메시지 ID

5 E 상위 블록 ID

6 하위 블록 ID

7 상위 소스 ID

시스템 바이트8 하위 소스 ID

9 상위 Transaction ID

10 하위 Transaction ID

[ 그림 R1-4. 가능한 헤더 구조 ]

R1-5.3 다른 소스 ID들은 호스트 또는 장비에서 주 메시지의 각 애플리케이션 레벨 발생자에 할당

된다. 이것은 부 메시지가 Transaction의 관련된 주 메시지의 소스에 연결되도록 한다.

Transaction ID는 SECS-I 인터페이스를 통해 전송되는 주 메시지에 대해 증가되는 정수이다. 다중

블록 메시지의 블록들에 대해서 동일하다.

R1-5.4 Actions - SECS-II 메시지가 SECS-I 프로토콜로 전송될 때, 하위 메시지 ID의 LSB 비트는

주 메시지(비트1 = 1)인지 부 메시지인지(비트1 = 0)를 정의한다. 메시지가 주 메시지이면,

Transaction ID는 생성되고 시스템 바이트의 Transaction ID 부분에 위치한다. Transaction ID의

생성 방법 중 하나는 초기에 0부터 시작하여 새 Transaction마다 1씩 증가하고 가장 큰

Transaction ID를 사용한 후에는 1부터 시작하도록 하는 것이다. 동시에 애플리케이션 전송자의 소

스 ID는 시스템 바이트의 소스 ID 부분에 위치한다. 메시지가 부 메시지라면, 시스템 바이트는 관

련된 주 메시지의 방법과 동일하다. 응답을 발생하는 애플리케이션은 주 메시지의 시스템 바이트를

저장하여 메시지 프로토콜에서 응답을 정의할 수 있다고 가정한다.

R1-5.5 블록 전송 실패(5.8.2, 6.8.1) - 마지막 성공한 블록 전송 이후에 시스템 바이트는 성공적

으로 전송하지 못한 블록에서 사용한 것과 달라야 하므로, Transaction ID 2바이트의 사용은

65,536개의 연속된 블록 전송 실패를 허용할 수 있게 된다.

HHHHHSSSSSMMMMMSSSSS

- 1 / 25 -

HSMS(High Speed SECS Message Service)

1. Introduction

- Spec : SEMI E37

- HSMS-SS(SEMI E37.1) : HSMS-Single Session - SECS-I 을 대체하기 위해 요구되는 서비스

의 최소 항목들을 포함하는 추가 표준

- HSMS-GS(SEMI E37.2) : HSMS-General Session - cluster tool 또는 track system과 같은

복잡한 다중 시스템을 지원하기 위해 필요한 subset을 제공하는 추가 표준

- 개발 목적 : 독립적인 개발자들이 특정한 지식이 필요없이 기기들을 연결하고 상호동작 될 수 있

도록 고속의 통신 기능을 만들어 낼 수 있는 수단을 제공하고자 한다.

- HSMS는 RS-232를 이용한 SECS-I을 대체하기도 한다.

2. Overview

2.1 HSMS Generic Service

- TCP/IP 네트워크 프로토콜을 사용하여 메시지 교환 절차를 정의함.

- 교환 절차

a. TCP/IP 연결 절차를 사용하여 entity 간의 통신 연결을 설정함

b. entity 들 간의 SECS 메시지 교환을 위해 필요한 프로토콜 협의(convention)를 설정하고 유

지함.

c. TCP/IP를 이용하여 데이터 교환

d. 에러 조건 인식

e. 쌍방의 통신 주체가 더이상 TCP/IP 연결이 필요하지 않음을 확인하기 위한 명시적인 통신

종료

f. 네트워크 매체로부터의 물리적인 단절이 필요없는 논리적인 통신 연결 종료

g. 연결 무결성 목적을 위한 통신 연결 테스트

h. 호환되지 않는 추가 표준으로부터의 연결 시도 거절

- 그외, TCP/IP 환경에서 발생하는 network timeout, 다중 연결 처리 등에 대해 기술함.

- BSD(Berkley Socket Definition) 인터페이스, TLI(Transport Layer Interface)를 사용한 메시지

교환 절차에 대한 정보 제공.

2.2 HSMS-SS(Single Session)

- HSMS의 SubSet(subsidiary standard)

- SECS-I 을 직접 대체 사용 하기 위해 요구되는 최소한의 서비스 집합을 포함

- HSMS-GS 와는 다른 상태 머신을 가짐.

- Limitation of HSMS-SS

a. HSMS-GS의 다중 TCP/IP 연결을 지원하는 구현에 사용되는 많은 부분들을 제거함

b. SECS-I 대체에 의한 특정한 경우에 대한 동작을 단순화 시키기 위해 HSMS-GS 절차를 제

한시킴.

2.3 HSMS-GS(General Session)

- HSMS의 subsidiary standard

- HSMS의 추가 기능

2001002

사각형


- 2 / 25 -

a. TCP/IP 연결을 통하여 외부 entity를 접근할 수 있는 모든 session entity들의 집합을 구성

하는 Session Entity List

b. 주어진 TCP/IP 연결상에서 접근을 위해 현재 선택된 entity들의 목록을 포함하는 Selected

Entity List

c. 현재 선택된 entity ID들의 수에 대응되는 Selection Count

그림 1 SEMI Standards for HSMS

3. HSMS 특징

- Higher speed than RS-232C

- Low cost

- High reliability

- Wide platform choice

2001002

사각형


- 3 / 25 -

4. HSMS Protocol

4.1 Message 형식

HSMS 메세지는 크게 Data Msg와 Control Msg로 나누어지는데 구분은 Msg Header의 6번째 바이트(S

Type)를 보고 판단한다.

1. Msg Format

Byte No. Descrition

4 Bytes Msg Length : Msg Header와 Text를 합한 숫자

10 Bytes Msg Header :

0 ~n BytesMsg Text : P Type을 보면 Text의 종류를 더 자세히

알 수 있다.

1) Msg Length

▶ 형태 및 길이 : Unsinged Integer, 4Bytes

▶ 내용 : Msg Header와 Text를 합한 숫자

2) Msg Header

▶ 형태 및 길이 : 10Bytes

▶ 내용 :

- 0~1 Byte : Session ID(Device ID)

Unsinged Integer. Control Messages(특히 Select와 Deselect Message)와

이에 수반되는 Data Messages사이를 관련성을 참조키 위해 제공함

☞ 메세지별 ID

Msg TypeData

Message

Select

.req

Select

.rsp

Deselect

.req

Deselect

.rsp

Linktest

.req

Linktest

.rsp

Reject

.req

Separate

.req

Sesssion ID * *req와 동

일*

req와 동

일0xFFFF 0xFFFF

거부된

Msg와동일*

* : 보조표준에 의해 향 후 사양을 제공한다.

- 2 Byte : Header Byte 2

IF S Type(5 Byte) = 0 (Data Msg라면)

IF P Type(4 Byte) = 0 (SECS Msg라면)

W-Bit + SECS Stream

ELSE

Special Consideration 참조

ELSE (Control Msg라면)

0 or Status Code를 입력

☞ Control메세지별 Status Code

Msg TypeSelect

.req

Select

.rsp

Deselect

.req

Deselect

.rsp

Linktest

.req

Linktest

.rsp

Reject

.req

Separate

.req

Status Code 0 0 0 0 0 0

*P Type

or

S Type

0

2001002

사각형


- 4 / 25 -

* : 만일 Header Byte 3의 ReasonCode(Reject.req의 Status Code를 뜻함)가

2( P Type Not Supported)이면 P Type이고 그렇지 않으면 S Type의 코드

가 들어간다.

- 3 Byte : Header Byte 3

IF S Type(5 Byte) = 0 (Data Msg라면)

IF P Type(4 Byte) = 0 (SECS Msg라면)

SECS Function

ELSE

Special Consideration 참조

ELSE (Control Msg라면)

0 or Status Code를 입력

☞ Status Code

S Type(5 Byte)의 Control Msg에 따라 아래와 같은 Status를 가진다.

※ SelectStatus(Select.rsp)

Value Description

0 통신 설정. Select가 성공적으로 완료

1 통신이 이미 Active된 상태. 이전의 Select가 이미 통신 설정한 상태

2Connection not Ready. Connection이 Select requests를 받을 준비가

되어 있지않음

3

Connect Exhaust. Connection은 받았으나, Entity가 이미 TCP/IP

Connection을 분리단계에 있고, 주어진 시간에 1회 이상 처리할 수 없

음

4-127 향후 사용

128-255 향후 사용

※ DeselectStatus(Deselect.rsp)

Value Description

0통신 종료.

Deselect가 성공적으로 완료

1통신 설정이 안된 상태.

이전의 Deselect로 이미 HSMS 통신이 종료된 상태

2통신 Busy.

Session이 여전히 응답 Entity로 사용 중에 있어서 끊을 수 없는 상태

3-127 향후 사용

128-255 향후 사용

※ ReasonCode(Reject.req)

Value Description

1

-SType 지원불가.

-SType 값이 HSMS 표준 또는 Entity에 의해 지원되는 특정 부가 표준에

정의되어 있지 않는 Message를 받은 경우

2001002

사각형


- 5 / 25 -

Value Description

2

-PType 지원불가

-PType 값이 HSMS 표준 또는 Entity에 의해 지원되는 특정 부가 표준에

정의되어 있지 않는 Message를 받은 경우

3

-Transaction Open 불가

-부합된 Request Message를 보내지 않았는데, Response Control Message

를 받음.

4-Entity가 선택되지 않음

-SELECTED 상태가 아닐 때, Data Message를 받음

5-127 향후 사용 예정

128-255 향후 사용 예정

- 4 Byte : P Type(Presentation Type)

8 Bit Unsinged Integer.

Presentation Layer Msg Type을 결정하는 Byte로 이것을 보고 Msg Header

와 Msg Text가 어떻게 코딩되었는지를 알 수 있다.

즉 0이면 SECS-II가 Msg로 encoding되었음을 의미하고 나머지의 경우는

Special Consideration참조

Value Descrition

0 SECS-II용

1 - 127 보조 표준용으로 예약됨

128 - 255 사용되지 않음

- 5 Byte : S Type(Session Type)


Data Msg인가 Control Msg인가를 결정한다. 결정하는 방법은 값이 0이면

Data Msg이고 나머지는 Control Msg이다.

Value Descrition 비 고

0 Data Msg

1 Select.req HSMS통신을 진행하기 위한 Initiator

2 Select.rsp Select.req에 대한 응답

3 Deselect.reqHSMS통신을 종료하기 위해 Deselect Procedure의

Initiator로 사용됨

4 deselect.rsp Deselect.req에 대한 응답

5 LinkTest.req HSMS 연결이 완전한 상태인지를 확인하는데 사용

6 LinkTest.rsp LinkTest.req에 대한 응답

7 Reject.req

Msg Receiver에 의해 지원이 되지 않거나 그 시

점에 Valid하지 않은 Msg를 받은 경우에 응답으

로서 사용한다.

8 Not Used

9 Seperate.req HSMS통신을 종료하고자 하는 경우에 사용

2001002

사각형


- 6 / 25 -

10 Not Used

11 - 127 보조표준용예약

128 - 255 사용되지않음

- 6~9 Byte : System Bytes


Uniqueness : Primary Data Msg, Select.req, Deselect.req, LinkTest.req는

반드시 Unique해야 하며 가장 최근에 종료된 것과도 같으면 안된다.

Reply Msg : Primary Data Msg, Select.rsp, Deselect.rsp, LinkTest.rsp는

Reqest Msg(.req)와 동일해야 한다.

3) Msg Text

▶ SECS-II Message

<HSMS Message Format Summary>

Message Header

Message TypeByte 0-1

Session IDByte2 Byte3

Byte 4

PType

Byte 5

SType

Bytes 6-9 System

Bytes

Message

Text

Data Message *

W-bit and

SECS

Stream

SECS

Function 0 0

Primary: Unique

Reply: Same as

primary

Text

Select.req * 0 0 0 1 Unique none

Select.rsp Same as .req 0 Select Status 0 2 Same as .req none

Deselect.req * 0 0 0 3 Unique none

Deselect.rsp Same as .req 0 Deselect Status 0 4 Same as .req none

Linktest.req 0xFFFF 0 0 0 5 Unique none

Linktest.rsp 0xFFFF 0 0 0 6 Same as .req none

Reject.req

Same as

message

rejected

PType or

SType of

message

being

rejected

Reason

Code

0 7 Same as message

being rejected

none

Separate.req * 0 0 0 9 Unique none

* Indicates further specification by subsidiary standards.

2001002

사각형


- 7 / 25 -

4.2 State Machine

Not

Connected

Connected

SelectedNot

Selected

12

3

6

4

5

# Current StateCurrent State

DescriptionTrigger New State Comment

1 ...

TCP/IP

Communication

준비

Not Connected

2 Not Connected

Entity가 받을 준비 및

TCP/IP Connection을 초

기화할 준비는 되어 있으

나, 아직 Connection은

되어 있지 않은 상태

HSMS

Communication

을 위해 TCP/IP

Connection

Establish됨

Connected

Not Selected

3 ConnectedTCP/IP Connection이 되

어 있는 상태

TCP/IP

Connection 끊

어짐

Not Connected

4 Not Selected

Connected상태이지만

,HSMS Session이

Establish 되어 있지 않

는 상태

HSMS Select

Procedure 성공Selected

Data Message

Exchange 허락

상태

5 Selected

Connected 상태이며, 적

어도 한개의 Session이

Establish되어 있는 상태

이고 이상태가 HSMS의

Normal "Operating"상태

이다

HSMS Deselect

또는 Seperate

성공

Not Selected

HSMS

Communication

의 끝이며,

Entity는

TCP/IP

Connection을

끊음

6 Not SelectedT7 Connection

TimeoutNot Connected

4.3 Timer-TimeOut

1) T3

Reply Timeout

2) T5

-Connect Separation Timeout.

2001002

사각형


- 8 / 25 -

-지나친 TCP/IP Connection을 막기 위함.

-Active Connect 진행이 어떤 수단에 의해 끊어진 후에는 그 Entity는 T5 Time이 지나기 전까지는

또다른 Active Connect 진행을 초기화시키면 안됨.

3) T6

-Control Timeout

-Communication Failure이 발생되기 까지 Open된 채로 있을 수 있는 최대 Time

4) T7

-Connection Idle Timeout(NOT SELECTED Timeout)

-TCP/IP Connection 성립과 HSMS Communication Connection 사이에 일어날 수 있는 최대 Time.

즉 Entity가 SELECTED 상태 또는 NOT CONNECTED 상태로 되돌아 오기까지의 NOT SELECTED 상태로 남을

수 있는 시간.

5) T8

-Network Intercharacter Timeout

-연속적인 2개의 Byte사이의 최대 시간

4.4 Procedure

- CONNECT, DISCONNECT, DATA, LINKTEST 의 4가지 Procedure로 구성

- SECS-I과의 공통 Procedure : "DATA" - Primary Msg., Reply Msg.(SECS-II Msg.)

- SECS-I에 추가된 Procedure(TCP/IP 연결관리) : CONNECT, DISCONNECT, LINKTEST

a. "CONNECT" Procedure

- TCP/IP 레벨에서의 연결설정

- 에러 방지를 위한 향상된 연결 절차 제공 : Select.req / .rsp

- ACTIVE entity : TCP "연결"함수를 통해 연결 설정을 초기화 하는 entity

- PASSIVE entity : TCP "수신"함수를 통해 연결 설정을 수신하는 entity

2001002

사각형


- 9 / 25 -

시작

ACTIVE entity:

연결(TCP/IP) 초기화

PASSIVE entity:

연결(TCP/IP) 응답

error

발생?

ACTIVE entity:

Select.req 전송

PASSIVE entity:

wait Select.req

during T7 timeout

Select.req

수신?

PASSIVE entity:

Select.rsp

끝

ACTIVE entity:

wait T5 timeoutRe-try connect

wait T6 timeout

Select.rsp

수신?

disconnect

TCP/IP

Y

N

N

Y

N

Y

2001002

사각형


- 10 / 25 -

b. "SEPARATE" Procedure

- HSMS-SS의 연결을 종료시킴.

- Separate.req 전송 및 수신 후, TCP/IP 레벨에서의 연결 해제가 필요

시작

ACTIVE entity :

Seperate.req 전송

PASSIVE entity :

Seperate.rsp 전송

끝

TCP/IP Close

c. "LINKTEST" Procedure

- HSMS-SS 연결의 상태(active)를 검사

시작

LINKTEST.req 전송

T6 timeout 시작

TCP/IP Disconnection

끝

Responding entity:

LINKTEST.rsp 전송

Y

LINKTEST.

rsp 수신?

T6 timeout?

Y

N

N

2001002

사각형


- 11 / 25 -

4.5 Message Procedure

1) TCP/IP Connection Procedure and Connect Mode

Active Mode EntityPassive Mode Entity

Send Connection RequestReceive and Accept

Connection Request

Receive Accept

TCP/IP Message Activity

2) Select Control Transaction

Initiator Responding Entity

Select.req Message

Select.rsp Message

3) Simultaneous Select Transaction

Entity Entity

Select.req Message

Select.rsp Message

4) Deselect Control Transaction


Deselect.req Message

Deselect.rsp Message

5) Simultaneous Deselect Transaction

Entity Entity



2001002

사각형


- 12 / 25 -

6) Linktest Control Transaction


Linktest.req Message

Linktest.rsp Message

7) Seperate Control Transaction

TCP/IP 끊기전에 HSMS Communication을 Terminate하기 위한 Procedure임.

Procedure이 정상적으로 되면, Selected->Not Selected로 바뀜.


Seperate.req Message

8) Reject Transaction


Inappropriate Message

Reject.req Message

4.6 HSMS Scenarios

1) Begin HSMS Communication


TCP/IP Connect Req Msg(s)

TCP/IP Accept Msg(s)

Select.req Message

Select.rsp Message

HSMS Data Message(hdr)

HSMS Data Message(text)

2) Ending Communication Using Deslect




TCP/IP Disconnect Msg(s)

2001002

사각형


- 13 / 25 -

4.7 Parameter 설정

Implementation of HSMS must provide for installation time setting of the following parameters

Parameter Name Value RangeResolu

tion

Typical

ValueDescription

T3 1-120 sec 1 sec 45 sec Reply Timeout. Entity가 Reply Message를 기다

리는 최대 시간

T5 1-240 sec 1 sec 10 sec Connection Seperation Timeout. Remote Entity

에 연결하기 위해 연속적인 시도 사이의 경과

시간

T6 1-240 sec 1 sec 5 sec Control Transaction Timeout. Control

Transaction이 통신 Failure 전까지 Open된 채

로 있은 수 있는 시간

T7 1-240 sec 1 sec 10 sec Not Selected Timeout. TCP/IP Connection이 통

신 Failure전, NOT SELECTED 상태로 있을 수 있

는 시간

T8 1-120 sec 1 sec 5 sec 통신 Failue전 Expire될 수 있는 Single HSMS

Message의 연속적인 Byte사이의 최대 시간

Connect Mode PASSIVE,

ACTIVE

- - Connect Mode

Local Entity IP

Address and

Port Number

TCP/IP 협약

에 의해 결정

- - PASSIVE Mode에서 Entity 운영을 위해 요구됨

Remote Entity

IP Address and

Port Number

TCP/IP 협약

에 의해 결정

- - ACTIVE Mode에서 Entity 운영을 위해 요구됨

2001002

사각형


- 14 / 25 -

4.8 SECS-I과 HSMS의 비교

특징 SECS-I HSMS

Protocol Base RS-232 TCP/IP

Physical Layer 25-pin connector and 4-wire serial

cable

Physical Layer가 정의되어 있지 않으며,

HSMS는 TCP/IP가 지원되는 매체면 됨.

전형적으로는 Ethernet(IEEE 802.3)과

Thin Coax(10-Base-2)이다.

속도 1KBytes/sec(9600baud) 10MBits/sec

연결 한개의 RS-232 Cable은 한개의 SECS-I

Connection을 지원한다.

한개의 N/W Cable이 여러 HSMS

Connection을 지원할 수 있다

Msg Format -SECS-II.

-Block(256 Bytes) 단위로 전송.

-.1 Byte Block Length

.10 Byte Block Header

.0~244 Byte Text

.2 Byte Checksum

-SECS-II

-TCP/IP Byte Stream으로 전송

-.4 Byte Message Length

.10 Byte Message Header

.Text

.TCP/IP Layer의 Blocking Limit는

사용되는 Physical Layer에 의존되며

따라서 TCP/IP API와 관계있고, HSMS

Scope와는 거리가 멀다.

Header 각 Message Block마다 10 Byte의

Header가 있으며, E-Bit와 Block

Number가 있다.

전 Message에 대해 하나의 10 Byte

Header가 있으며, PType과 SType이 있다.

최대 Msg 크기 7.9 Million Byte(32767 Blocks * 244

Texts)

4 GBytes

Protocol

Parameters(공통)

T3 Reply Timeout Device ID T3 Reply Timeout Session ID (Device

ID와 유사)

Protocol

Parameters(SECS-I

Only)

-Baud Rate

-T1 Inter-Character Timeout

-T2 Block Protocol Timeout

-T4 Inter-Block Timeout

-RTY Retry Count

-Host/Equipment

Protocol

Parameters(HSMS

Only)

-IP Address와 Passive Entity의 Port

-T5 Connect Separation Timeout

-T6 Control Transaction Timeout

-T7 NOT SELECTED Timeout

-T8 N/W Intercharacter Timeout

2001002

사각형


- 15 / 25 -

5. HSMS-SS Protocol

5.1 토폴로지

- 그림 2/3 : SECS-I과 HSMS topology 비교

- SECS-I : cell controller는 2개의 분리된 RS-232 케이블을 가짐.

- HSMS-SS : 하나의 물리적인 이더넷 케이블이 사용됨. 2개의 논리적인 연결을 수행하며, 2개의

장비는 1개의 논리적인 연결이 존재

- 그림 3과 같은 복잡한 시스템에서 SECS-I은 추가의 물리적인 연결이 필요. HSMS-SS는 하나의

추가적인 논리적 연결만이 필요.(물리적 케이블은 기존 유지)

그림 1 SECS-I vs. HSMS Connection 1

그림 2 SECS-I vs. HSMS Connection 2

2001002

사각형


- 16 / 25 -

5.2 Message 형식

그림 3 HSMS-SS Message format

- "TCP Stream" 방법을 이용하여 TCP/IP 접근

- 메시지 구성 :

a. Message Length Field : 4 Bytes, (Msg. Header + Msg. Text)를 나타냄.

b. Message Header : 10 Bytes(그림 3 참조)

- 1st & 2nd bytes Device ID

- 3rd & 4th bytes : S-type에 따라 각각 다른 값을 가짐

Data Msg.의 경우 4th byte가 1 → Primary Msg.

Data Msg.의 경우 4th byte가 0 → Reply Msg.

- 5th byte : P-type, always 0

- 6th byte : S-type, Data Msg.와 Control Msg. 구분

- 7th - 10th bytes : System Bytes

2001002

사각형


- 17 / 25 -

c. Message Text : several megabytes, SECS-II msg.(Data Msg.의 경우)

- <주의점> SECS-I의 경우 SECS-II 메시지를 블록 단위로 전송(Block Length, Block Header 존

재). HSMS-SS는 TCP/IP Stream을 사용하므로 메시지의 블록화는 HSMS-SS가 관여하지 않는다.

즉, SECS-II의 메시지 블록화를 고려할 필요가 없으며, Message Text는 SECS-II 메시지가 원형

그대로 저장됨.

SECS-I HSMS-SS

-SECS-II. Msg 전송

-Block(256 Bytes) 단위로 전송.

-.1 Byte Block Length

.10 Byte Block Header(including Block_Count,

E-Bit)

.0~244 Byte Text

.2 Byte Checksum

-SECS-II. Msg 전송

-TCP/IP Byte Stream으로 전송

-.4 Byte Message Length

.10 Byte Message Header(S-type, P-type)

.Text

5.3 Procedure

- HSMS 와 동일

그림 4 HSMS-SS Procedure

2001002

사각형


- 18 / 25 -

5.4 State Machine

그림 5 HSMS-SS State Machine

(1) State Transtion Table for Passive Mode Connect

Table 1. HSMS-SS Passive Mode Connect State Transitions

# Old State Mew State Trigger Actions

1 -TCP/IP NOT

CONNECTEDInitialization

2TCP/IP NOT

CONNECTED

HSMS NOT

SELECTED

TCP/IP Connect Succeeds:

1. TCP/IP "accecpt" succeeds.Start T7 timeout

3HSMS NOT

SELECTED

HSMS

SELECTED

HSMS Select Succeeds :

1. Receive Select.req and decide to allow it.

1. Cancel T7 timeout;

and

2. Send Select.rsp with zero

Select Starus

4HSMS NOT

SELECTED

TCP/IP NOT

CONNECTED

HSMS Select Fails:

1. T7 Timeout waiting for Select.req:or

2. Receive select.req and decide to

reject it and send Select.rsp with

non-zero Select Status ; or

3. Receive any HSMS message other

than Select.req; or

4. Receive HSMS message length not

equal to 10; or

5. Receive bad HSMS message header;

or

6. T8 timeout waiting for TCP/IP; or

7. Other unrecoverable TCP/IP ERROR

(entity-specific)

1. Close TCP/IP

connection

2001002

사각형


- 19 / 25 -

5HSMS

SELECTED

TCP/IP NOT

CONNECTED

HSMS Connection Terminates:

1.Decide to terminate and send

Separate.req; or

2. Receive Separate.req; or

3. T6 timeout waiting for Linktest.rsp; or

4. Receive HSMS message <10; or

5. Receive HSMS message length >

maximum supported by entity; or


or


8. Other uncorrectable TCP/IP Error

(entity-sepcific)

1. Close TCP/IP

connection

6HSMS

SELECTED

HSMS

SELECTED

T3 Timeout waiting for Data Reply

Message1. Cancel the Data

Transaction as

appropriate

(entity-specific)but do not

terminate the TCP/IP

connection;

and

2. If entity is

EQUIPMENT send

SECS-II S9F9

(2) State Transtion Table for Active Mode Connect

Table 2. HSMS-SS Active Mode Connect State Transitions

# Old State Mew State Trigger Actions

1 -TCP/IP NOT

CONNECTEDInitialization

2TCP/IP NOT

CONNECTED

HSMS NOT

SELECTED

TCP/IP Connect Succeeds:

1. Decides to connect

1.TCP/IP onnect;

and

2.Send elect.req;

and

3. Start T6

timeout

3HSMS NOT

SELECTED

HSMS

SELECTED

HSMS Select Succeeds :

1. Receive Select.rsp with zero

SelecStatus

1. Cancel T6

timeout

2001002

사각형


- 20 / 25 -

4HSMS NOT

SELECTED

TCP/IP NOT

CONNECTED

HSMS Select Fails:

1. T6 Timeout waiting for Select.rsp:or

2. Receive select.rsp with non-zero

Select.Status; or

3. Receive any HSMS message other

than Select.rspor

4. Receive HSMS message length not

equal to 10; or


or


7. Other unrecoverable TCP/IP ERROR

(entity-specific)

1. Close TCP/IP

connection; and

2. Start T5

Timeout

5HSMS

SELECTED

TCP/IP NOT

CONNECTED

HSMS Connection Terminates:

1.Decide to terminate and send

Separate.req; or

2. Receive Separate.req; or

3. T6 timeout waiting for Linktest.rsp; or

4. Receive HSMS message length <10;

or

5. Receive HSMS message length >

maximum supported by entity; or


or


8. Other uncorrectable TCP/IP Error

(entity-sepcific)

1. Close TCP/IP

connection

6HSMS

SELECTED

HSMS

SELECTED

T3 Timeout waiting for Data Reply

Message

1. Cancel the

Data Transaction

as appropriate

(entity-specific)but

do not terminate

the TCP/IP

connection;

and

2. If entity is

EQUIPMENT send

SECS-II S9F9

2001002

사각형


- 21 / 25 -

Table 3. When HSMS Transaction are Allowed

HSMS Transition Allowed in State(s) Who Initiates Transaction?

Select HSMS Not Selected Active Entity

Link Test HSMS Selected Either Entity

Data HSMS Selected Either Entity

Separate HSMS Selected Either Entity

5.5 Timer-TimeOut

5.6 Parameter Setting

그림 6 HSMS Configuration

- 통신 주체를 각각 HOST, EQUIPMENT로 설정

- EQUIPMENT의 SECS Device ID 설정

- ACTIVE / PASSIVE 설정 : 일반적으로 HOST를 ACTIVE로 설정함

- PASSIVE의 IP와 TCP port 설정

2001002

사각형


- 22 / 25 -

- T5(Connect Separation Timeout) : ACTIVE entity가 TCP/IP 연결을 설정하기 위해 시도하는

re-try time 간격

- T6(Control Transaction Timeout) : HSMS Control transaction(Select and LinkTest)에 대해

통신 실패 전까지 open된 상태로 남아 있을 수 있는 최대 시간

- T7(Not Selected Timeout) : 연결 절차동안 PASSIVE entity가 "Select.req"를 수신하기 위해

기다리는 시간

- T8(Network Timeout) : 어플리케이션이 응답하지 않는 TCP/IP 계층을 기다리는 시간

5.7 Protocol Stack(SECS-I과 HSMS 비교)

그림 7 SECS-I .vs. HSMS-SS Protocol

SECS-I HSMS-SS

4-wire serial cable several cable(물리계층은 사용자 선텍)

RS232Ethernet(IEEE 802.3)

Token-Ring(IEEE 802.5)

- TCP/IP

2001002

사각형


- 23 / 25 -

SECS - II

GEM

- 물리 계층을 특정화 시키지 않은 이유 : Fast Ethernet, FDDI와 같은 새로운 TCP/IP를 지원하는

프로토콜을 추후 사용하기 위함.

6. HSMS / HSMS-SS 비교

구분 HSMS HSMS-SS

Msg. Header

(SessionID)

-. Specific 값의 정의는 추가 규격서 정

의를 따름

-. Data Msg.:DeviceID

-. Control Msg. : 0xFFFF

Msg. Header

(Ptype)

-. 0-255까지 값의 범위 정의

-. SECS-II encoding시 0으로 사용

-. SECS-II Msg 만을 전송하므로 "0으로

고정"

Msg. Header

(Stype)

-. HSMS에서 사용하는 Control Msg. 모

두 정의

-. 0-255까지 값의 범위 정의

-. Deselect(.req & .rsp)와 Reject.req의

Stype 값 생략(3, 4, 7)

-. 0-9번까지만 사용

Msg. 길이 -. TCP/IP stream(

-. older SECS-I application과의 호환성

을 위해 SECS-II Msg.는 single

block으로만 정의됨.

-. HSMS msg.는 254바이트(10B

Header+244B text)를 초과하지 않음.

Procedure

-. LinkTest : 반드시 SELECT state에

서 이루어짐

-. Reject Procedure 생략

-. Deselect 천이 상태 없음

State Machine

-. Select → Not Select 단계 없음

-. Not Select → TCP/IP Not Select

단계 없음.

-. Select → TCP/IP Not Select로 천이

(Seperate Procedure)

7. 용어정리

communication failure - SELECTED state로부터 NOT CONNECTED state로의 천이로 인해 통신 연결상의

실패.

confirmed services(HSMS) - 응답 메시지를 요구하는 initiator에서 responding entity로 전송되는 메시지에

의해 요청되는 HSMS service.

connection - 메시지 교환을 목적으로 두 개의 entity간에 TCP/IP LAN상에 설정된 논리적인 연결.

control message - 두 개의 entity간에 HSMS sessions의 관리를 위해 사용되는 HSMS message.

data message - HSMS session 내에서 특정한 어플리케이션의 통신을 위해 사용되는 HSMS message. 데이

터 메시지는 Primary Message 또는 Reply Message가 있다.

2001002

사각형


- 24 / 25 -

entity - TCP/IP 연결의 종단점에 결합되어 있는 응용 프로그램.

header - 모든 HSMS message의 앞에 위치한 10 바이트의 데이터 요소.

initiator(HSMS) - HSMS service를 요구하는 entity. initiator는 적절한 HSMS message를 전송하여 서비스

를 요청한다.

IP Address - Internet Protocol Address. TCP/IP network에 접속된 entity들을 식별하는 논리적인 주소로

서 유일하다.

local entity - 특정한 연결 종단점에 관련되어 있으며, local entity는 종단점에 결합된 entity이다.

local entity-specific - General qualifier to any procedure, option, issue, or other implementation

matter which is not a subject of this standard and left to the discretion of the individual supplier.

message - 한 방향의 통신상에 있어서 완성된 단위. 하나의 HSMS Message는 Message Length, Message

Header, and the Message Text.로 구성되어 있다. 데이터 메시지와 제어 메시지가 될 수 있다.

message length - 바이트로 구성된 메시지의 길이를 나타내는 4 바이트의 부호있는 정수형 필드이다.

open transaction - 진행중인 트랜잭션

port - TCP/IP 연결의 종단점으로서 이것의 완성된 네트워크 주소는 IP Address와 Port number에 의해 표시

된다.

port number - (or TCP port number). TCP/IP 연결의 종단점으로서 제공될 수 있는 TCP/IP 네트워크에 연

결된 포트의 주소.

primary message - 홀수의 Function을 가진 HSMS Data Message. 또한 data transaction에서 첫 번째 메시

지이다.

published port - TCP/IP연결 요구를 수신하는데 사용되는 특정한 entity에 결합된 TCP/IP IP Address와

Port number. entity의 published port는 연결을 초기화할 때, 원격 entity가 알고 있어야 한다.

receiver - 메시지를 수신하는 HSMS Entity.

remote entity - 특정한 연결 종단점에 관련되어 있으며, remote entity는 연결의 상대편 종단점에 결합된

entity이다.

reply - 짝수의 function을 가진 HSMS Data Message. 또한 Primary HSMS 데이터 메시지에 대한 적절한

응답이다.

responding entity (HSMS) - HSMS service의 제공자. responding entity는 서비스를 요청하는 initiator로부

터 메시지를 수신한다. confirmed service에서 responding entity는 적절한 HSMS response message를

initiator로 전송함으로써 요청된 서비스를 종료한다. unconfirmed service에서, responding entity는 응답 메

시지를 전송하지 않는다.

2001002

사각형


- 25 / 25 -

session - HSMS message 교환을 목적으로한 두 entity간에 설정된 관계.

session entity - HSMS session에 참여한 entity.

session ID - 특정한 session entitie 들간의 특정한 session을 식별하는 16 비트의 부호없는 정수형 식별자.

stream (TCP/IP) - 다른 한 쪽 끝단으로의 전송을 위한 TCP/IP 연결의 종단에서 발생하는 바이트의 연속.

TCP/IP는 표시된 stream과 일치하는 연속된 바이트의 전송을 보장한다. HSMS는 stream을 연속된 바이트의

메시지 블록으로 나눈다.

T3 - Reply timeout in the HSMS protocol.

T5 - Connect Separation Timeout in the HSMS protocol used to prevent excessive TCP/IP connect

activity by providing a minimum time between the breaking, by an entity of a TCP/IP connection or a

failed attempt to establish one, and the attempt by that same entity, to initiate a new TCP/IP

connection.

T6 - Control Timeout in the HSMS protocol which defines the maximum time an HSMS control

transaction can remain open before a communications failure is considered to have occurred. A

transaction is considered open from the time the initiator sends the required request message until

the response message is received.

T7 - Connection Idle Timeout in the HSMS protocol which defines the maximum amount of time

which may transpire between the formation of a TCP/IP connection and the use of that connection for

HSMS communications before a communications failure is considered to have occurred.

T8 - Network Intercharacter Timeout in the HSMS protocol which defines the maximum amount of

time which may transpire between amount of time which may transpire between the receipt of any

two successive bytes of a complete HSMS message before a communications failure is considered toe

have occurred.

TCP/IP - Transmission Control Protocol/Internet Protocol. 네트워크 상의 컴퓨터들 간에 신뢰성 있고, 연

결지향적인 메시지 교환을 제공하는 통신 방법.

TLI - Transport Level Interface. 전송계층 프로토콜과 전송 계층 프로토콜 사용시 운영체제 독립적인 정의

를 제공하는 TCP/IP의 이행에 의해 제공되는 하나의 특별한 API.

transaction - Primary Message와 만약 요구된다면, 그에 연관된 Reply message. 또한 request (.rep) 형태

의 HSMS Control Message와 그의 response Control Message (.rep).

unconfirmed service (HSMS) - responding entity로부터 응답을 요구하지 않는 initiator에서 responding

entity로 메시지를 전송하도록 요청된 HSMS service.

2001002

사각형

SECS II Overview

SEMI Equipment Communications Standard 2 Message Content

사용자 주의 필요 : Stream 4를 사용하는 표준을 구현할 때 특허에 걸린 발명품을 사용하게

될 수도 있다.

1. 소개

1) 이 표준의 의도

지능형 장비(EQ)와 Host 사이에 교환되는 message 내용에 대한 세부 사항 정의.

상호 상보적인 message transfer protocol과의 양립을 허용함으로써 SECS-I과 완전 호환.

host 소프트웨어와 조합되도록 세부적으로 message 정의 되는데 이 message 는 개별

장비(EQ)에 대한 매우 적은 지식으로 생성된다. 반대로 장비(EQ)와 조화되는 세부적인

message가 정의될 때는 또한 호스트에 대한 매우 적은 지식으로 생성된다.

SECS2에서 정의하는 메시지는 IC 생산에 요구되는 가장 전형적인 동작들을 지원.

표준 message 에서 지원하지 않는 동작을 요구하는 장비 특화적인 message 정의도 지원.

어떤 동작은 Host 에 있는 범용 소프트웨어에 의해 조정되는 반면, 장비(EQ)의 모든 성능이

제공되려면 장비(EQ) 특화적인 호스트 소프트웨어가 필요하다.

2) 개요

SECS-I 과 같은 message transfer protocol 을 이용해 Host 와 장비(EQ)간에 송수신되는

message 에 형태와 의미를 부여(message 형태의 정보 전달 방법을 정의하는 것). 즉,

Host와 Eq간의 정보전달 방법을 message의 형태로 정의.

이 Message는 Stream과 Function으로 구성됨. Stream은 activity의 category 를 의미하며,

Stream이 가지고 있는 세부 message를 Function이라고 함.

Item 의 list 와 item 이라 불리는 논리적 요소로 이 Message 구조 정의. 이 구조는 메시지의

적절한 해석을 보장하는 자가 설명 데이터 형식을 따름.

메시지 교환은 transaction protocol 이라 불리는 메시지 조정 규칙의 집합에 의해 지배된다.

이 transaction protocol은 SECS2의 구현의 최소 사양으로 바꿔 말할 수 있다.

3) 응용

2001002

사각형

SECS2는 반도체 소자 생산에 사용되는 장비(EQ)와 Host 에 응용., 이 표준에서 제공하는

동작의 예는 제어 프로그램 전송, 재료 이동 정보, 측정 데이터, 요약된 테스트 데이터,

알람(Transfer of control program, material movement information, measurement data,

summarized test data, and alarms)등.

SECS2의 최소 사양은 Section5에서 요약된 매우 미세한 제약을 포함.

SECS2 에 할당된 장비의 부분은 이 표준에서 설명된 function 들의 부분 집합을 요청할

것이다. Function 의 수와 function의 선택은 장비의 성능과 요구사항에 따라 달라질 것이다.

장비의 각 부분, 각 function 을 위한 실제 형식은 Section7 에 요약된 형태에 따라

작성되어야만 한다.

장비(EQ)가 SECS2 의 특정 구현에 사용된 message 를 정의하는 것을 가정하고 Host 는

장비(EQ)의 구현을 제공할 것을 가정.

4) 응용 문서

이 표준은 그것의 사용과 관련된 어떤 것이든 안정성 문제에 대한 접근을 강요하지

않는다. 적절한 안정성과 양호한 동작을 구현하고 사용에 앞서 조절 한계 능력을 정의하는

것은 이 표준 사용자의 의무임.

2. 정의

1)

block – message transfer protocol에 사용되는 message의 물리적 구분 단위

conversation – 연결된 message의 sequence

conversation timeout – conversation일 적절하게 완료되지 않았을 때 발생

device ID – Host 와 통신하는 특정 장치(EQ) 부분의 구별을 위해 사용하는 0 과

32767(16bit)사이의 숫자

equipment – Host 와 통신하는 지능적인 시스템 (EQ)

function – 한 stream 안에서 특정 동작을 위한 특정 message

host - 장치와 통신하는 지능형 시스템

interpreter – primary message를 해석하고 요청될 때 reply를 생성하는 시스템

item – message 안에 있는 데이터

item format – item의 데이터 타입을 구분하는데 사용하는 코드

list – item의 그룹

2001002

사각형

message – 통신의 완전한 단위

message header – message transfer protocol에 의해 전달되는 message에 대한 정보

multi-block message – 한 message가 하나 이상의 block으로 message transfer protocol에

의해 전달

originator – primary message의 생성자.

packet – message transfer protocol에 의해 사용되는 message 의 물리적 구분 단위

primary message – 홀수로 할당된 message. transaction의 첫 번째 message

reply – 한 primary message 에 일치하는 특정 secondary message

secondary message – 짝수로 할당된 message. transaction의 두 번째 message

single-block message - 한 message가 하나의 block 으로 message transfer protocol에 의해

전달

stream – message의 카테고리

transaction – primary message 와 그것과 연결된 secondary message

transaction timeout – transaction 이 적절하게 완료되지 않았을 때 message transfer

protocol로부터 발생

3. Message Transfer Protocol

1) 의도

SECS2 는 SECS-1 에서 정의된 message transfer protocol 과 완전 호환되어야 함.

여기서는 Message transfer protocol 과 SECS2 를 사용하는 어플리케이션 사이의 상호

작용에 대한 요구 사항을 정의. 사용 용어의 경우 SECS1 과는 동일하지만 다른 message

transfer protocol을 사용하는 경우 달라질 것이다.

2) Message

Message transfer protocol은 장비(EQ)와 Host간의 message 전송에 사용.

Message transfer protocol 은 reply 를 요청하는지의 여부를 지시하는 primary message 를

보낼 수 있어야만 하고 만약 reply 를 요청한다면 대응되는 secondary message 연결할 수

있거나 그 요청한 원본 primary message 를 가진 message 로 reply 를 할 수 있어야만

한다.

Originator는 원본 primary message 를 제공.

2001002

사각형

Interpreter 는 그것의 목적지에서 primary message 를 해석하고 reply 가 요청될 때 reply 를

생성하는 도입부를 제공.

3) Blocking Requirement

Message transfer protocol은 SECS2의 message blocking의 요구사항을 제공해야만 함

Single block message – 특정 message 가 한 block 이나 한 packet 안에서만 message

transfer protocol에 의해 전송되기를 SECS2가 요구.

이 메시지는 single block SECS2 message 에 의해 정의. 어플리케이션

소프트웨어에서 Message transfer protocol 에 어떤 메시지가 single block 으로 보내져야만

하는지에 대해서 알리기 위해 사용되는 방법은 cover 되지 않았다. SECS-I 의 호환을 위해

single block SECS2 message 에서 허가된 최대 길이는 244byte 이다. Message transfer

protocol의 최소 사양은 single block SECS2 message를 전송할 수 있는 것이다.

Multi block message – SECS-I의 호환을 위해 244bytes 보다 더 많은 SECS2 message는

multi block message를 지원.

Single block 의 길이를 만족할 지라도 특정 SECS2 message 는 multi block 으로 전송된다.

오래된 구현 중 어떤 것은 특정 입력 메시지에 대한 입력 block 사이즈에 대한

어플리케이션 특화적인 요구 사항을 부과. 이 표준의 1988 revision 이후에는 이러한 요구를

부과할 수 없다.

4) Message Header

message transfer protocol 은 message header 라 불리는 정보를 제공한다. Message

header 의 유일한 내용은 SECS2의 정의에 있다. 어플리케이션과 message transfer protocol

사이에 주고 받는 message header의 실재 형식은 표준의 부분으로서 cover되지 않는다.

Device ID - message transfer protocol은 message 의 발생지 또는 목적지를 지시하는 device

ID로 구별할 수 있어야 한다.

Stream and Function - message transfer protocol 은 Message Identification Code : Minimum

15-bit (Stream 0 ~ 127, 7 bits + Function 0 ~ 255, 8 bits)로 SECS2를 구별(인식) 가능해야 함.

각각의 Stream, Function의 조합을 통해 message ID 구분.

Reply Requested - message transfer protocol은 primary message 에 의해 reply 가 요청되는

지의 여부를 인식할 수 있어야만 한다.

Transaction Timeout - message transfer protocol 은 특정 transaction timeout 기간 동안

예상된 reply message 수신이 실패한 이벤트에서 그 이벤트를 SECS2 가 알릴 것을

추정하고 있어야 함.

2001002

사각형

Multiple Open Transactions – 이 표준은 동시 발생적으로 하나 이상의 transaction 이 생성

되는 것을 지원하는 것이 가능하게 한다. 하지만 요구하지는 않는다.

4. Streams and Functions

1) Streams

비슷하거나 관계된 activities 를 나타내는 message들의 categories.

2) Functions

Stream 에서 특정 activity 를 나타내는 특정 message. SECS2 에서 사용하는 모든

function 은 일치하는 primary 와 secondary 메시지 쌍의 numbering convention 을 따를

것이다.

?? Streams and Functions numbering convention

Primary Message Secondary Message

S : 1 ~ 127

F : Odd number

S : 해당 Primary message 의 것과 동일

F : 해당 Primary message 의 F + 1(Even number)

F = 0 in all Streams : Abort Transaction

Table 4. Streams and Functions numbering convention

3) Stream and Function Allocation

몇몇 Stream/Function code 조합은 SECS-II standard 에 의해 reserved 상태임. 반면

나머지는 사용자 정의가 가능함

아래 Table4. Stream/Function code combinations 참조바람

Reserved Available

In Stream 0, Functions 0 ~ 255

In Streams 1 ~ 63, Functions 0 ~ 63

In Streams 64 ~ 127, Functions 0



Table 5. Stream/Function code combinations

SECS-II 의 Reserved codes 는 Book of SEMI STANDARDS 1997 EQUIPMENT

AUTOMATION/SOFTWARE VOLUME1, SEMI E5-1296, Section 7. Message Detail 참조바람.

2001002

사각형

예약된 code들은 Section7에서 설명.

표준에서 정의된 것보다 더 세부적인 정의가 필요한 사용자의 경우 Section5 에서 요약된

최소한이 지시에 따라 주제화 할 수 있다.

5. Transaction and Conversation Protocols

1) 의도

SECS2 에 따라 설계하기 위해 이 Section 에서 요약된 최소한의 transaction 요구사항을

맞추어야만 한다. Conversation protocol은 transaction 사이의 상호작용과 사용법에 대한 더

많은 정의를 제공한다.

2) Transaction Definition

Transaction은 SECS2에서 상호 교환되는 모든 정보에 대한 기초를 형성

Reply message가 없는 Primary message

Reply 로 Secondary message 를 요구하는 Primary message (Secondary message 의 경우

reply를 요구할 수 없음)와 그에 대한 Secondary message

3) Transaction Level Requirements

Stream/Function code Description

S1F1, S1F2 Eq or Host’s operative status check

S9F1, F3, F5, F7, F11 For any received message that cannot be processed by Eq

Stream9 error 메시지

S9F9 For transaction timeout (장치에서 호스트로… )

S*F0 For abort transaction

Any o ther format Book of SEMI STANDARDS 1997 EQUIPMENT

AUTOMATION/SOFTWARE VOLUME1, SEMI E5-1296, Section 7.

Message Detail 참조

Table 6. Transaction Level Requirements

4) Conversation protocol

Conversation : 특정 작업을 수행하기 위한 일련의 연관된 transactions.

2001002

사각형

Conversation Timeout – conversation이 적절하게 끝나지 않았음을 지시할 때 사용.

conversation timeout 을 발견하는 방법은 어플리케이션에 의존적이고 표준의 한 부분으로서

cover 되지 않는다. Conversation timeout 이 발생하면 conversation 상의 그 뒤 action 들을

끝내고, 모든 제공되었던 resource 들을 깨끗이 한다. 장비(EQ)에서 발생할 경우 S9F13 을

Host로 보낸다.

Types of conversations – SECS2에서 교환되는 모든 정보는 7가지 유형으로 특성화 되어

있다.

하나. Primary message with no reply – 가장 간단.

이 메시지는 반드시 single-block SECS2 메시지이다. Originator 는 interpreter 가

message 에 응답했다고 가정해야만 함. 이 conversation 은 메시지가 거절될 경우

originator가 아무것도 할 수 없을 경우 사용된다.

둘. Request/Data conversation : Originator(Creator of primary message)의 primary

message에 data가 요구되고, interpreter(The system that interprets a primary message

and generates a reply when requested)가 reply message 로 data 를 전송하는

conversation

셋. Send/Acknowledge conversation : Originator 가 single block 으로 data 를 보내고

interpreter로부터 acknowledgment 를 기대하는 conversation

넷. Inquire/grant/send/acknowledge conversation : Multi-block message 의 경우

originator는 interpreter에게 multi-block message를 전송해도 되는지 요청(Inquire)하고,

interpreter 가 이를 허락(Grant)하면 originator 가 data 를 보내고(Send), interpreter 가

적절한 응답(Acknowledge)을 하는 conversation

다섯. Conversation related to the transfer of unformatted data sets between Eq and Host. :

Stream 13 참조

여섯. Conversation related to the handling of material between Eq : Stream 4

일곱. Request/acknowledge/send/acknowledge conversation : Originator가 interpreter로

하여금 얻는데 시간이 좀 걸리는 정보를 요구하는 경우, 첫번째 transaction 에서

originator 가 정보에 대한 request 를 하면 interpreter 가 정보는 얻어질 것이고 다음

transaction 때 전달될 것이라는 응답을 주고, 다음 transaction 이 이루어 지는

conversation. 이때 application에 따라 originator에 의해 conversation timeout 이 설정될

수 있고, timeout 이 발생하면 originator 는 timeout 이 발생한 conversation 을 취소하고,

S9F13(Conversation Timeout) error message 를 전송하며 ‘request’를 가지는 새로운

conversation을 시작한다.

Key word 인 request, data, send, acknowledge, inquire, grant 는 메시지와 conversation

사이의 관계를 이해에 중점을 두는 function name 으로서 사용된다. Single message

transaction은 이 용어들을 사용하지 않는다.

2001002

사각형

6. Data Structure

1) 의도 – 이 표준을 따라 전송되는 모든 정보는 2 개의 데이터 구조(Item 과 list)에 따라

format 된다. Message transfer protocol이 물리적 구분인 것과는 별개로, message의 논리적

구분으로서 정의 된다. 장비(EQ)와 Host 간의 전송되는 message 의 자가 설명적인 내부

구조를 제공한다.

2) Item

Information packet. (Fig7. Item and List Header 참조)

Item의 첫 번째 bytes 와 2 또는 3 또는 4 bytes 에 item의 길이 및 형태가 정의되어 있음.

Item Header(IH)와 Item Body(IB)로 구성.

IH : Format byte와 length byte(s)로 구성.

IB : Item의 실제 Data.

3) List

Ordered set of element. Element 는 item또는 list가 될 수 있음.

List header(LH)는 item header와 같은 형태를 가지고 있음.(Type 0, Table 7. Format code

참조)

Item 1

Item 2

List 1 Item 3

Item 4

Item 8

Item 5

List 3 Item 6

Item 7

List 2

A block of data(One Message)

Fig 6. Logical view of Message

2001002

사각형

8 7 6 5 4 3 2 1

1

2

3

4

No. of

length byte Item format code

Length

Length

Length

MSB

MSB

LSB

LSB

MS byte

LS byte

Format

byte

Length

byte

a. No. of length byte

0=Illegal, data format error

1=One binary length byte(max=255)

2=Two binary length bytes(max=64k)

3=Three binary length bytes(max=7.99M)

b. Length : Item의 경우 item body의 bytes수

List의 경우 list내의 element(items or lists) 수

Fig 7. Item and List Header

2001002

사각형

SECS-II의 message 에는 Item과 List의 두 가지 Data structure 가 있다. (Fig6. Logical view of Message

Structure 참조)

Format Code Meaning

Binary (Bit876543) Octal The data after the heading has the following form

000000 00 LIST(length in elements)

001000 10 Binary

001001 11 Boolean

010000 20 ASCII

010001 21 JIS-8

011000 30 8-byte integer (signed)




100000 40 8-byte floating point

100100 44 4-byte floating point

101000 50 8-byte integer (unsigned)




Table 8. Format code

Example of Data

아래와 같이 정의된 S5F1 Message의 경우 Complete Message의 예는 다음과 같다.

Message : From Device 66 to Host

ID : Stream 5, Function 1

<List>, 3 Items

2001002

사각형

<1. Binary>, Alarm Code for alarm set/reset and alarm category code

<2. Integer>, Alarm ID

<3. ASCII>, Alarm Description

Complete Message

Classification Binary

Format

Description

Length 00011011 Header + Data bytes = 27 bytes

Header Begin 10000000 R = 1 (to the Host)

00101010 Device Code = 66

00000101 Stream 5, W = 0

00000001 Function 1

10000000 E = 1

00000001 Block 1

00000000

00000000

00000000

Header End 00000000

System bytes = 0

List Header Start 00000001 List, 1 byte length byte

List Header End 00000011 3 Elements

First Item Begin 00100001 Binary Item, next one byte is length byte

00000001 1 byte long

First Item End 10000100 Alarm set, category 4 (Data Item

Dictionary 에서 ALCD 참조바람 )

Second Item Begin 01100101 Item, 1-byte integer, next byte is length byte

00000001 1 byte long

Second Item End 00010001 Alarm 17

Third Item Begin 01000001 Item, ASCII, next byte is length byte

00000111 7 characters

2001002

사각형

01010100 ASCII T

00110001 ASCII 1

00100000 ASCII space

01001000 ASCII H

01001001 ASCII I

01000111 ASCII G

Third Item End 01001000 ASCII H

Check Sum(HI) 00000100 Higher order 8 bits (0x04)

Check Sum(LOW) 01011111 Lower order 8 bits (0x5F)

2001002

사각형

반도체 장비간 통신 표준(GEM)

Ⅰ. 시작하기

지난 호에 반도체 장비 사이의 표준 통신 프로토콜인 SECS 프로토콜에 대해 간단히 소개했다. 하지

만 SECS 프로토콜은 통신을 위한 최소한의 규약만을 제공할 뿐 실제 장비에서 발생하는 다양한 기능

에 대한 동작 자체를 표준화하는 것은 아니었다. 모든 반도체 장비가 SECS 프로토콜에 의해 통신을

하지만, 그 동작 방식이나 사용하는 메시지가 모두 다르다면 정말로 복잡한 일이 아닐 수 없다.

이런 이유로 SEMI에서는 장비의 동작에 대한 시나리오와 이때 사용되는 메시지를 묶어서 장비 구동

에 관한 표준을 마련했는데, 이 표준이 E30 Generic Model for Communications and Control of

Manufacturing Equipment이고, 이를 간단히 줄여서 GEM(Generic Equipment Model)이라고 부른다.

GEM에서는 기능에 따른 장비의 동작 시나리오를 지정하고, 이 시나리오에 따라 필요한 SECS-II 메

시지를 선정해서 표준으로 삼고 있다.

GEM은 1990년대 초부터 반도체 산업에 적용되기 시작했는데, 본격적으로 적용되기 시작한 것은

1990년대 중반 이후부터이다.

Ⅱ. GEM Specification

1. GEM 사양서 작성

GEM에 대해 흔히 혼동하고 있는 내용이 GEM 사양서를 누가 작성하느냐 하는 문제다. GEM 통신 사

양서는 장비의 H/W 사양서와 함께 장비 업체가 Chip Maker에게 초기에 제공해야 한다. 다시 말하면,

장비 업체는 H/W 사양 뿐 아니라 내 장비가 어떻게 구동되는지를 기술하는GEM 사양서를 갖추고 있

어야 한다는 말이다.

하지만 아직 GEM에 익숙하지 않은 우리나라 장비 업체의 경우, 국내에서 장비를 적용했던 경험 때문

에 Chip Maker에서 CIM 사양을 주기를 기다리는 경우가 많다. 이것은 잘못된 경우이다. 다시 한 번

말하지만, GEM 사양서는 Chip Maker에게서 받는 것이 아니라 장비 업체에서 만들어서 제출해야 하는

것이다. 실제로 기술력을 가진 우리나라의 장비 업체가 GEM 사양서 작성 때문에 해외에 진출하는 데

어려움을 겪는 경우가 많은데, 이는 우리가 빨리 풀어야 할 숙제 중 하나이다.

2. GEM Compliance Statement

GEM 사양의 구현 여부는 아래와 같은 GEM Compliance Statement로 표시한다.

GEM 사양은 크게 Fundamental Requirements와 Additional Capabilities로 나뉘어진다. Fundamental

Requirements는 GEM을 구현했다면 반드시 지켜져야 하는 부분이고, Additional Capabilities는 추가적

인 기능의 명세이다. 각 기능의 구현 여부에 따라 위의Compliance Statement에 체크를 하게 된다.

체크를 하는 부분은 ‘Implemented’ 영역과 ‘GEM Compliant’ 영역의 두 부분이 있는데, 해당 기능이

구현되어 있으면 ‘Implemented’ 영역의 ‘Yes’에 일단 체크를 하고, 구현한 방법이 GEM 사양을 따랐

으면 다시‘GEM Compliant’ 영역에도 체크를 하게 된다. 따라서 ‘GEM Compliant’ 영역에 체크했다는

것은 ‘ Implemented ’ 영역에도 체크를 했다는 것을 의미한다(결국 GEM을 구현했다는 것은, 이

Compliance Statement에 체크를 잘했다는 것을 의미한다).

위에서도 말했지만, Fundamental Requirements는 반드시 구현해야 GEM을 지켰다고 할 수 있다. 하

지만 Additional Capabilities 부분은 구현할 수도 있고 지원하지 않을 수도 있다. 내 장비에서 지원할

수 없는 기능은 굳이 구현하지 않아도 된다는 의미이다. 하지만, 지금은 GEM이 많이 보편화된 상황

이라서 간단하게라도 GEM의 모든 기능을 다 구현하고 있는 실정이다.

3. GEM의 기능 항목

GEM에는 Fundamental Requirements에 8개, Additional Capabilities에 15개, 총 23개 기능 항목이 있

다. 이제 각 기능 항목의 내용과 시나리오에 대해 소개하기로 한다.

1) State Models

장비의 모든 상태는 State Model로 관리되는데, 각 State Model에 대한 정의가 이루어져 있어야 한다

는 내용이다.

GEM에서는 최소 세 가지의State Model을 정의하고 있는데, Communication State Model, Control

State Model, Equipment Processing State Model이 그것이다. 이 중 Communication State와 Control

State는 SEMI E30에서 표준을 제시하고 있고, 일반적으로 제시된 내용을 그대로 따르고 있다.

State Model은 State Diagram, State Description, State Transition Table의 세 요소로 이루어진다.

State Diagram은 각 State의 관계를 그림으로 표시한 것으로, 전체 State의 위치와 전이 내용을 한눈

에 보여준다. State Description은 각 State가 무엇을 의미하는지, 해당 State에서는 어떤 일이 일어나

는지 등을 기술한 것이다. State Transition Table은 한 State에서 다른 State로 전이될 때, 어떤 조건

에서 전이가 일어나는지, 전이된 후에는 어떤 작업을 해야 하는지 등을 기술한 표이다.

다음은 표준 Communication State의 State Diagram이다.

Communication State는 ‘ Host-Initiated S1, F13/F14 Scenario ’ 기능 항목이나 ‘ Establish

Communications’ 기능 항목과 관련이 있기 때문에 뒤에서 설명하기로 한다.

다음은 표준 Control State의 State Diagram이다.

Control State란 장비제어의 권한이 어디에 있는가에 대한 상태 관리를 의미한다.

Control State는 크게ON-LINE과 OFF-LINE으로 나뉘어지고, ON-LINE은 다시 LOCAL과 REMOTE로,

OFF-LINE은 Equipment OFF-LINE과 Host OFF-LINE으로 나뉘어진다. OFF-LINE 상태는 호스트와

통신을 하지 않고 작업자에 의해서 장비가 제어되는 상태를 의미하고, ON-LINE은 호스트와의 통신에

의해 장비가 제어되는 상태를 의미한다. ON-LINE 상태에서 REMOTE는 호스트의 명령에 의해서 장비

가 구동되는 경우로, 완전한 CIM 제어 상태에 있는 경우를 말한다. 이에 반해 LOCAL은, 호스트와의

통신에 의해 장비는 제어되지만, 장비의 구동과 관련된 명령은 호스트가 제어하지 않고 작업자에 의

해서 이루어지는 경우를 말한다.

2) Equipment Processing State

GEM에서는 장비의 작업 상태를 Equipment Processing State라는 이름으로 관리하도록 요구한다. 다

음은 GEM에서 제시하는 일반적인 Processing State이다.

GEM에서 위와 같은 Processing State를 제시하고 있지만, 각 장비 업체는 자신의 장비에 맞는

Equipment Processing State를 다시 정의해서 사용할 수 있다.

3) Host-Initiated S1, F13/F14 Scenario

이 기능 항목은 Communication State와 관련되어 있는데, 호스트가 S1F13 메시지를 보냄으로써 통

신 상태를 COMMUNICATING 상태로 전환하는 기능을 말한다.

일반적으로 HSMS 사용을 가정할 때, 호스트가 HSMS Active가 되고 장비가 Passive가 된다. 처음

HSMS 연결이 맺어지고 SELECTED 상태가 되면 통신을 위한 준비는 완료되었지만 아직 통신이 성립

(Established)된 상태는 아니다. 이때 호스트가 먼저 통신 성립을 위해서 S1F13 메시지를 보내고 이

에 대해 장비는 S1F14 메시지로 응답함으로써 통신을 성립하게 된다.

4) Event Notification

장비는 장비에서 발생하는 모든 이벤트를 호스트에 알려야 한다는 규칙이다. 여기서 이벤트란 장비의

상태 변화 및 재료의 이동, 작업 환경의 변화 등 모든 상황을 다 포함한다.

이런 이벤트 보고에는 S6F11 메시지가 사용되는데, S6F11 메시지를 통해 이벤트를 보고하려면 각 이

벤트에 대한 CEID(Collection Event ID)와 보고할 데이터로 구성된 리포트가 필요하다. 리포트란 변수

(Variable)의 집합인데, 특정 상황에 해당하는 정보를 지닌 보고서이다. CEID란 어떤 이벤트가 발생했

는지를 나타내는 이벤트 고유의 ID로, 보고할 리포트와 연결(Link)되어 사용된다.

좀 더 자세한 내용은 Dynamic Event Report Configuration에서 다루도록 한다.

5) On-Line Identification

이 기능 항목은 현재 장비의 통신 상태가 COMMUNICATING이고 Control 상태가 ON-LINE인지 확인

하는 목적에서 사용된다. 호스트가 장비의 통신 상태와 Control 상태를 확인하고자 할 때 S1F1 메시

지를 장비로 전송하고, 이를 받은 장비는 S1F2로 응답을 한다.

이 기능은 호스트에 의해서 개시되는 기능으로, 같은 S1F1 메시지라도 장비가 먼저 보낼 경우는 다른

의미(Control State 전환)를 갖는다.

6) Error Messages

이 기능 항목은 장비의 오류가 아니라 통신의 오류를 검출하는 기능으로, 다음과 같은 스트림 9 메시

지를 사용한다.

7) Documentation

이 항목은 GEM 사양서에 기록되어야 할 내용을 정의하고 있는데, 다음의 내용이 포함되어야 한다.

○ Message Documentation

사용되는 모든 메시지의 내용이 SEMI E5 SECS-II 문서에서 설명된 형태로 기술되어야 한다.

○ GEM Compliance Statement

GEM 사양 준수 여부에 관한 내용이 기술되어야 한다.

○ Data Items

장비에서 관리되는 모든 데이터에 대한 내용을 VID와 함께 기술해야 한다. 또한 SML 표기법에

맞게 데이터 포맷에 관한 내용도 기술해야 한다.

이 외에 다음과 같은 내용도 함께 기술되어야 한다.

○ Operation Scenarios

장비의 동작에 관한 시나리오를 기술한다. 여기에는 정상 동작 및 이상 동작에 관한 내용, GEM의

각 기능 항목에 관한 시나리오가 포함된다.

○ Collection Events

장비에서 발생되는 이벤트를 CEID와 함께 기술한다.

○ Alarms

장비의 알람 코드를 기술한다.

8) Control (Operator-Initiated)

장비의 Control State를 작업자가 변경하는 경우, 그 방법에 대해 정의한 기능 항목이다.

OFF-LINE 상태에서 ON-LINE 상태로 전환할 경우, 장비는 S1F1을 호스트로 보내서 ON-LINE 전환

에 대한 허가를 받는다. 만약 호스트가 S1F2로 응답하면, 그때 가서ON-LINE으로 전환한다. ON-LINE

상태에서 OFF-LINE으로 전환할 때에는 호스트의 허가를 얻을 필요 없이 바로 전환한다.

위의 두 경우 모두 Control State를 전환한 후에는 Control State 전환에 대한 이벤트 발생을 호스트에

S6F11 메시지를 이용해서 보고한다.

9) Establish Communications

앞에서 언급했던Communication State의 상태를 COMMUNICATING으로 만들기 위한 확장된 사양을

말한다. Fundamental Requirements에서는 호스트에서S1F13을 먼저 보내는 사양이 있었지만, 여기서

는 장비에서 S1F13을 먼저 보내는 내용이 추가되었다.

장비에서 S1F13을 먼저 보내는 경우에는 S1F13과 S1F14의 메시지 형태가 조금 달라지게 된다.

10) Dynamic Event Report Configuration

이 기능 항목은 이벤트 리포트의 양식을 호스트의 의도대로 자유롭게 변경하는 기능에 관한 내용이다.

앞에서 Event Notification에 관해 설명했는데, 여기서는 그 보고 방법에 관한 확장된 사양을 다룬다.

장비에서 어떤 이벤트가 발생하면 장비는 S6F11 메시지를 이용해서 호스트로 보고를 한다. 이때

S6F11에 들어가는 내용은, 발생한 이벤트의 종류(CEID)와 그에 따른 데이터 보고이다. 데이터 보고는

RPTID라는 보고서 고유 ID로 관리되는데, Dynamic Event Report Configuration에서는 이 보고 방식을

호스트의 의도에 맞도록 자유롭게 변경한다.

먼저 하나의 RPTID에는 하나 이상의 데이터 항목(VID)이 지정된다. 즉, RPTID=1인 보고서는 시각, 현

재의 Control State, 작업자 ID 등의 데이터로 구성되는 식이다. 그리고, 이 보고서를 특정 CEID와 연

결한다. 즉, 어떤 이벤트가 발생하면, 해당 CEID와 연결된 보고서(RPTID 집합)를 묶어서 호스트에 보

고하는 방식이다. 호스트는 여기에서, RPTID를 다시 정의할 수 있고 특정 CEID와 연결되는 RPTID를

다시 선언할 수 있다. 또한, 특정 이벤트가 발생했을 때, 그 이벤트 보고를 받을지 받지 않을지 결정

할 수도 있다. 이것이 Dynamic Event Report Configuration에서 수행하는 작업이다.

이 기능은 호스트의 데이터 관리 기준이 변하거나 특정한 데이터에 대한 보고를 추가하고자 할 때 유

용하게 사용된다.

여기에서는 S2F33/F34, S2F35/F36, S2F37/F38 등의 메시지가 사용된다.

11) Variable Data Collection

이 기능 항목은 호스트가 원할 때 호스트가 지정한 보고서를 제출하는 기능을 제공한다. 호스트가 특

정 RPTID를 S6F19 메시지를 통해서 전달하면, 장비는 지정된 RPTID의 보고서를 S6F20 메시지를 통

해서 전송한다.

이 기능은 누락되거나 문제가 발생한 이벤트 보고를 보완하기 위해서 주로 사용되지만, 데이터가 SV

만 있는 것이 아니라 주로 DVVAL로 구성되기 때문에, 그다지 많이 사용되지는 않는다.

12) Trace Data Collection

이 기능 항목은 주로 Fault Detection 등의 목적으로 특정 SV를 지속적으로 모니터링할 필요가 있는

경우에 사용된다.

호스트는 Trace 고유 ID(TRID), 모니터링할 데이터(SVID), 샘플링 주기(DSPER), 샘플링 회수

(TOTSMP), 그리고 한 번 보고에 포함되는 데이터의 개수(REPGSZ)를 S2F23 메시지를 통해 장비로

전송한다. 그러면 장비는 주어진 조건에 따라 데이터를 수집하기 시작한다. 데이터를 수집하다가 보고

할 개수만큼 수집된 데이터가 쌓이면 수집된 데이터를 S6F1 메시지를 통해서 호스트로 전송한다.

데이터를 한 번 수집할 때마다 보고하지 않고 모아서 한꺼번에 보고하는 이유는 네트워크 트래픽을

줄이기 위해서다.

13) Status Data Collection

이 기능 항목은 호스트가 특정 SV를 확인하고자 할 때 사용된다.

호스트는 확인하고자 하는 SVID를 S1F3 메시지를 통해서 장비에 전송한다. 장비는 호스트가 요청한

SV를 S1F4 메시지를 통해서 호스트에 전달한다.

14) Alarm Management

이 기능 항목은 장비에서 알람이 발생했을 때 이를 호스트에 보고하는 절차를 다룬다.

장비에 알람이 발생하면 장비는 호스트에 S5F1 메시지를 통해서 알람이 발생했음을 알린다. 또한 알

람 발생 역시 하나의 이벤트이기 때문에 알람 발생에 대한 이벤트로 S6F11 메시지를 전송한다. 작업

자에 의해 알람에 대한 조치가 완료되고 알람이 해제되면, 장비는 S5F1 메시지를 통해서 알람의 해제

를 호스트에 알리고 알람 해제 이벤트를 보고한다.

또한 이벤트 보고를 선택적으로 하는 것처럼 알람 보고도 S5F3 메시지를 이용해서 원하는 알람에 대

해서만 보고를 받을 수 있다.

15) Remote Control

이 기능 항목은 호스트가 원격으로 장비를 제어하기 위한 기능으로, 장비의 구동에 관한 명령을 전달

해서 장비를 구동함으로써 자동화 생산을 구현하는 데 목적이 있다.

호스트는 S2F41이나 S2F49 메시지를 이용해서 장비에 원격 명령을 전달한다. 일반적으로 장비는 전

달받은 명령에 대한 타당성을 검사한 후, 명령의 수행 여부를 호스트에 알리고, 명령 수행에 따른 이

벤트를 호스트로 전달하게 된다.

이 기능은 장비의 Control State와 밀접하게 관련되어 있다. Control State가 REMOTE인 경우는 모든

원격 명령을 받아들이지만, LOCAL인 경우는 장비의 구동에 관련한 명령을 제외하고 명령을 수용하게

된다.

기본적으로 START, STOP, PAUSE, RESUME, CANCEL, ABORT의 기능을 제공하도록 명시되어 있지만,

현재 이 모든 기능을 반드시 제공할 필요는 없고 필요한 기능에 대해서만 구현하는 것이 일반적이다.

16) Equipment Constants

장비에는 호스트에 의해 값이 변경될 수 있는 변수인 Equipment Constant가 있는데, 이 기능 항목에

서는 이러한 Equipment Constant를 관리하는 기능을 제공한다.

호스트는 S2F15 메시지로 새로운 Equipment Constant를 설정할 수 있고, S2F13과 S2F29로 등록되

어 있는 Equipment Constant의 값과 내용을 조회할 수 있다. 또한 작업자에 의해서 Equipment

Constant가 변경되었을 경우는, Equipment Constant 변경 이벤트를 S6F11 메시지를 통해서 호스트

에 전달해야 한다.

17) Process Program Management

이 기능 항목은 장비의 구동을 위한 프로세스 프로그램(이하 PP)을 관리하는 기능을 제공한다. 여기

서 관리라 함은 PP를 호스트로 전송하거나 호스트에서 내려 받고, 또 이를 수정하는 것을 의미한다.

PP에는 두 종류가 있는데, Formatted PP와 Unformatted PP가 그것이다. Formatted PP는 PP의 내용

이 SECS-II 메시지 형태로 분리되어 관리되는 것을 의미하고, Unformatted PP는 PP 내용이 장비 자

체의 바이너리 형태로 되어 있어서 PP의 내용을 눈으로 확인할 수 없는 형태를 말한다. 과거에는 단

순히 PP를 일괄로 모아서 관리하는 데 초점이 맞춰져 있어서 Unformatted PP로 관리되는 경우가 많

았지만, 지금은 필요한 항목을 수정해서 관리하려는 경향이 많아서 Formatted PP를 많이 사용하고 있

다.

또한 PP는 경우에 따라 Recipe와 같은 의미로 사용하기도 하는데, 그에 따라 사용되는 SECS-II 메시

지의 종류가 무척 다양하다.

18) Material Movement

이 기능 항목은 장비 내에서 재료(Material)의 이동을 Tracking하는 기능을 제공한다. 여기서 재료란

Wafer가 될 수도 있고, 스트립, 팔레트, 다이(Die) 등이 될 수도 있다.

재료 이동에 대한 보고는 S6F11 메시지를 이용한다.

19) Equipment Terminal Services

이 기능 항목은 작업자와 호스트가 서로 텍스트 형태의 메시지를 주고받는 기능을 제공한다.

호스트는 장비에게S10F3이나 S10F9 메시지를 통해서 텍스트를 전달하고, 장비는 S10F1 메시지를 전

달한다. 하지만, 일반적으로S10F1 메시지를 사용하는 일은 거의 없다.

호스트가 보낸 터미널 메시지는 반드시 화면에 잘 보이도록 표시를 해서 작업자에게 전달되어야 한다.

그리고, 호스트의 터미널 메시지를 작업자가 확인했으면 확인에 대해서 이벤트 보고를 하도록 한다.

만약 작업자가 없어서 확인이 되지 않은 경우는 타임아웃을 발생시켜서 작업자 확인이 되지 않았음을

알리도록 한다.

20) Clock

이 기능 항목은 호스트와 장비의 시각을 동기화하려는 목적이다. 호스트와 장비의 시각이 서로 다르

다면 로그의 분석이나 데이터 업데이트 등의 상황에서 서로의 시각이 달라서 문제를 만들 수 있다.

상대의 현재 시각을 조회하기 위해서 S2F17 메시지를 사용하고, 호스트가 현재 시각을 장비에 지정

하기 위해서는 S2F31 메시지를 사용한다.

21) Limits Monitoring

이 기능 항목은 특정 SV의 변화를 모니터링하다가, 값이 설정된 한계치에 도달했을 때 이를 보고하는

기능을 제공한다.

하지만 Limit Monitoring에서 값을 관리하는 방법은 단순히 값이 설정된 값에 도달했는지를 모니터링

하는 것이 아니라, 값이 정해진 영역을 이동하는 것을 모니터링한다.

다음은 Limit State Model을 보여준다.

Limit Monitoring 기능을 설정하기 위해서 호스트는 S2F45 메시지로 Limit 변수와 데드밴드(Dead

Band)를 설정한다. 또한 호스트는 현재 설정되어 있는 Limit 변수의 내용을 확인하기 위해서 S2F47

메시지를 사용한다.

장비는 설정된 Limit 조건들을 지속적으로 모니터링하다가, Limit State에 변화가 발생하면 그 내용을

S6F11 메시지를 통해서 호스트에 보고한다.

일반적으로 변수(SV, DVVAL, ECV)는 모두 최대값, 최소값, 기본값, 단위 등의 속성을 설정하게 되는

데, Limit Monitoring에서는 이 속성 이외에 UPPERDB, LOWERDB라는 데드밴드와 그에 해당하는

LIMITID를 설정해서 관리한다.

22) Spooling

이 기능 항목은 통신에 문제가 발생해서 데이터 전송이 누락되었을 경우, 이를 장비가 보관하고 있다

가 통신이 복구되었을 때 호스트에게 다시 전송할 수 있는 기능을 제공한다.

다음은 Spooling State Model을 보여준다.

위에서 보면, SPOOL ACTIVE 상태가 SPOOL LOAD와 SPOOL UNLOAD의 두 상태로 나뉘어지는데,

이 두 상태는 각각 독립적으로 운영된다. SPOOL LOAD는 메시지를 스풀 버퍼에 저장하는 상태를 나

타내고, SPOOL UNLOAD는 저장되어 있는 메시지를 삭제하거나 호스트로 전송하는 상태를 나타내는

데, 이 두 상태는 동시에 독립적으로 존재하기 때문에 메시지를 호스트로 전송하면서(TRANSMIT

SPOOL) 동시에 메시지를 저장하는 것이 가능하다.

호스트는 스풀링에 적용할 메시지의 종류를 S2F43 메시지에 정의해서 전송한다. 장비는 이 메시지의

내용대로 스풀링할 메시지를 선별한다. 일반적으로 장비가 Power On되고 ON-LINE으로 전환되면, 호

스트는 스풀링되어 있는 메시지가 있는지 S1F3 메시지를 통해서 확인한다. 만약 스풀링되어 있는 메

시지가 있다면, 호스트는 S6F23 메시지로 스풀링되어 있는 메시지의 전송을 요구하고, 장비는 미리

정해져 있는 개수만큼 메시지를 전송한다. 전송이 완료되면 스풀링 State 변동을 S6F11 메시지로 전

송한다.

여기서 고려해야 할 내용이 두 가지 있다. 하나는 스풀링 메시지를 저장하는 방법인데, 어떤 포맷으로

저장할 것인지를 고려해야 한다. 메시지 스트림 자체를 바이너리로 저장하는 것이 좋을지, 아니면 데

이터를 따로 분리해서 저장하는 것이 좋을지 결정해야 한다. 다른 하나는 네트워크 연결 종료와 T3

타임아웃 등의 상관관계에서 벌어지는 메시지 누락이다. 사실 네트워크 연결이 끊어진 것을 발견하는

데 걸리는 시간이 상황에 따라서 오래 걸리는 경우가 있는데, 이 경우는 통신에 문제가 있는지 없는

지를 판단할 수가 없다. 따라서 통신이 끊어졌는데도 불구하고 스풀링 기능이 제대로 동작하지 않는

경우가 발생하는데, 이에 대한 준비가 필요하다. 가장 쉬운 방법은 모든 메시지에 대해 스풀링을 진행

하고, 응답이 온 경우에 저장된 메시지를 지워가는 방식인데, 이 경우도 관리에 세심한 주의가 필요하

다.

23) Control(Host-Initiated)

호스트 자체의 판단에 의해서 장비의 Control State를 변경할 필요가 있는데, 이 경우에 적용하는 기

능이 ‘Host-Initiated Control’이다.

호스트는 OFF-LINE 전환을 위해서 S1F15 메시지를 사용하고, ON-LINE 전환을 위해서는 S1F17 메

시지를 사용한다. 여기서 주의할 점은 S1F17 메시지는 ON-LINE 전환만을 의미하는 것이지 LOCAL이

나 REMOTE를 지정하는 것이 아니라는 점이다. 호스트에 의해서 ON-LINE으로 전환할 때

LOCAL/REMOTE를 정하는 것은 일반적으로 Equipment Constant에 기록된 내용을 사용한다.

Ⅲ. SEM

GEM을 통해 일반적인 장비의 동작 규약을 정하고는 있지만, GEM만으로 반도체 생산에 투입되는 모

든 장비의 사양을 규정하는 것은 실제로 불가능하다. 특히, 다른 공정 장비와 비교할 때 작업 자체가

색다른 반송장비나 Stocker 등의 경우는 GEM만으로는 부족하다.

이런 이유로 특별한 장비에 적용되는 사양은 따로 SEM(Specific Equipment Model) 사양을 정해서 관

리하고 있다. SEM이 특정 장비에 맞는 모델이라고는 하지만, 그 기본은 GEM을 전제로 하고 있다.

GEM의 각 기능을 기본으로 하고, 거기에 장비의 특성에 맞는 기능이 추가된 형태다. 하지만 만약

GEM의 기능과 SEM의 기능이 서로 충돌하게 되는 경우는, SEM 사양을 따라가도록 하고 있다.

현재 따로 관리되고 있는 SEM 사양의 종류는 다음과 같다.

○ ISEM(Inspection SEM)

○ IBSEM(Interbay/Intrabay AMHS SEM)

○ Stocker SEM(AMHS Storage SEM)

○ PSEM(Prober SEM) or PSEM300

○ TSEM(Tester SEM)

○ HSEM(Handler SEM)

만약 위에서 언급한 장비를 만들고 있다면, GEM 사양뿐 아니라 반드시 SEM 사양을 검토해서 적용해

야 한다.

Ⅳ. 마치면서

이상으로 GEM에 대한 간단한 소개를 마친다. 아직도 300mm 웨이퍼 생산에 관련된 사항이나

Performance Management, Interface A, CEM(Common Equipment Model) 등에 대한 많은 내용이 남

아 있다. 가능하다면, 그리고 반도체 장비 개발과 관련된 일을 하고 있다면, SEMI의 새로운 표준에 대

해 계속적으로 관심을 기울였으면 한다.

secsgem의 이해 - devpiapds.devpia.com/maeul/781/maeul_addboard/39000/38385/fundamental_rea… ·...

Documents