SCADA Things
← 전체 글
언어English한국어
SECS/GEM/약 11분 읽기/— 조회

GEM 된다는 설비에 S3F17을 던지면 왜 아무것도 안 돌아오나

한 소켓에 S1F13, S3F17, S14F1, S16F11을 던진 캡처. GEM은 답하고 GEM300이 쓰는 stream 셋은 SxF0으로 끊겼다.

SECS/GEMMESSCADA문제 해결체크리스트

MES 쪽에서 carrier 하나를 tool에 붙이라고 한다. E87 문서를 펴고 S3F17 Carrier Action을 만들어 보냈다. T3가 만료된다. 아니면 body가 없는 짧은 프레임 하나가 돌아오는데, 그게 S3F0이다.

설비 스펙 시트에는 "SECS/GEM 지원"이라고 적혀 있다. 그 문장은 SEMI E30까지만 말한 것이다. E87, E40, E90은 E30 위에 얹히는 별개의 표준이고, 각각 E30이 쓰지 않는 stream에서 산다. 지원 여부도 따로다.

호스트가 한 소켓으로 S1F13, S3F17, S14F1, S16F11을 보내고 S1F14 하나만 정상 응답으로 받은 뒤 나머지 셋은 SxF0 abort로 돌려받는 교환 호스트설비 S1F13 S1F14 · COMMACK 0 S3F17 S3F0 S14F1 S14F0 S16F11 S16F0 GEM300 stream HSMS SELECTED · SESSION ID 11

소켓 하나에 primary 네 개

캡처는 손으로 쓴 예시가 아니다. 127.0.0.1:5501에서 도는 HSMS passive listener에 소켓을 직접 열고, Select.req부터 Separate.req까지 실제로 흘린 바이트다. session ID는 11. framing은 SEMI E37, item header는 E5의 format code 표를 따른다.

Select가 끝난 직후 첫 primary는 S1F13이다.

TX S1F13   00 00 00 0C 00 0B 81 0D 00 00 00 00 03 E9 01 00
RX S1F14   00 00 00 37 00 0B 01 0E 00 00 00 00 03 E9
           01 02 21 01 00 01 02 41 15 "VX-9000 Plasma Etcher" 41 0D "SECSGEM-1.4.1"

header byte 2가 81이다. 상위 비트가 W-bit, 나머지 7비트가 Stream 1. byte 3은 0D, Function 13. body는 01 00 — 항목이 0개인 List다.

응답 body를 풀면 이렇다.

  • 01 02 — L,2
  • 21 01 00 — B[1] 00. COMMACK 0, 통신 수락.
  • 01 02 — L,2
  • 41 15 — A[21] VX-9000 Plasma Etcher (MDLN)
  • 41 0D — A[13] SECSGEM-1.4.1 (SOFTREV)

여기까지는 E30 그대로다. 이제 stream만 바꾼다.

TX S3F17   00 00 00 0C 00 0B 83 11 00 00 00 00 03 EA 01 00
RX S3F0    00 00 00 0A 00 0B 03 00 00 00 00 00 03 EA

TX S14F1   00 00 00 0C 00 0B 8E 01 00 00 00 00 03 EB 01 00
RX S14F0   00 00 00 0A 00 0B 0E 00 00 00 00 00 03 EB

TX S16F11  00 00 00 0C 00 0B 90 0B 00 00 00 00 03 EC 01 00
RX S16F0   00 00 00 0A 00 0B 10 00 00 00 00 00 03 EC

셋 다 body는 똑같이 빈 List로 보냈다. 설비는 body를 보기 전에 stream에서 끊는다.

SxF0은 "지원 안 함"이라고 말하지 않는다

돌아온 세 프레임은 길이가 전부 00 00 00 0A, header 10바이트가 전부고 body가 없다.

byteS3F0의미
0-100 0BSessionID 11 — 요청과 동일
203Stream 3, W-bit 없음
300Function 0
4-500 00PType 0, SType 0 — data message
6-900 00 03 EASystemBytes, 요청 것 그대로

Function 0이 abort다. stream은 내가 보낸 그대로 돌아오니 어느 요청이 거절됐는지는 알 수 있고, SystemBytes도 그대로라 transaction 테이블에서 짝은 맞는다. 그게 전부다. 이유 코드가 없다. "그 stream을 구현 안 했다"인지, "지금은 안 된다"인지, "본문이 틀렸다"인지 구분할 방법이 프레임 안에 없다.

E5에는 이런 상황을 위한 메시지가 따로 있다. 구현하지 않은 Stream은 S9F3, 구현하지 않은 Function은 S9F5다. 이 리스너는 셋 중 어느 것도 보내지 않았다. 드문 일이 아니고, S9를 기대하고 호스트를 짜면 안 되는 이유를 따로 정리해 뒀다.

호스트 코드에서 실제로 위험한 건 이거다. SxF0을 "응답 없음"으로 처리하면 T3가 끝날 때까지 기다린 뒤 재시도한다. 재시도도 SxF0으로 돌아온다. 로그에는 타임아웃만 쌓이고, 원인은 타임아웃이 아니다.

어느 표준이 어느 stream에 사는가

E30은 SECS-II stream 전부를 쓰지 않는다. GEM300 표준들이 앉은 자리는 E30이 비워 둔 stream이고, 그래서 GEM만 구현한 tool은 그 stream을 통째로 모른다.

표준하는 일stream
E30 GEM통신 확립, 상태 모델, 이벤트, 알람, 원격 명령, 레시피S1, S2, S5, S6, S7
E87 Carrier Managementcarrier와 load portS3 Materials Status
E39 Object Services객체의 속성을 읽고 쓰는 공통 서비스S14 Object Services
E40 Process Job Managementprocess job 생성과 진행S16 Processing Management
E94 Control Job Managementcontrol job — 여러 process job의 묶음S14
E90 Substrate Tracking기판 한 장의 위치와 상태전용 stream 없음

stream 번호 배정은 E5가 정한다. E87이 S3에, E39가 S14에, E40이 S16에 사는 것도 거기서 나온다.

E90이 줄 하나만 비어 있는 게 눈에 걸릴 텐데, 이건 누락이 아니다. E90은 새 stream을 만들지 않는다. 기판마다 객체를 정의하고, 그 상태 변화를 E30이 이미 갖고 있는 수집 이벤트로 흘린다. 호스트 입장에서 E90 지원 여부는 "S90이 되느냐"가 아니라 "그 CEID와 그 변수가 tool에 정의돼 있느냐"다. 수집 이벤트와 보고서를 엮는 순서가 그대로 E90 확인 절차가 된다.

아래 두 가지는 표준 문서 기준으로 적은 것이고, 실제 tool에 물려서 확인하지는 못했다. S3F17은 E87의 carrier action 요청, S16F11은 E40의 process job 생성 쪽 function으로 알고 있다. 내가 캡처로 증명한 건 저 function 번호의 의미가 아니라 stream 3, 14, 16이 이 설비에서 통째로 막혀 있다는 사실뿐이다. CAACK나 ACKA 같은 응답 코드 값은 여기에 적지 않았다. 확인한 적이 없어서다.

통신이 되는지와 stream이 있는지는 다른 질문

호스트 붙일 때 순서가 자꾸 섞인다. 확인해야 할 게 세 겹인데 증상이 비슷하게 생겼다.

  1. HSMS가 SELECTED인가 — 아니면 data message는 아예 나가지도 않는다.
  2. E30 통신이 열렸는가 — S1F13이 COMMACK 0으로 돌아왔는가. 열리기 전에는 S1F13 말고 전부 SxF0이다. 통신 게이트가 S1F13 앞에서 무엇을 막는지는 따로 정리했다.
  3. 그 stream이 구현돼 있는가 — 여기서 걸리면 위 두 개를 아무리 봐도 안 나온다.

세 번째가 이 글의 SxF0이다. 1번과 2번은 멀쩡한데 3번에서 걸린 상태이고, 로그만 보면 2번 실패와 구별이 안 된다. 구별하는 방법은 위 캡처 그대로다. S1F13이 정상 응답으로 돌아온 같은 소켓에서 문제의 stream을 한 번 던져 보면 된다. S1F14는 오는데 S3F0이 오면, 통신은 살아 있고 stream이 없는 것이다.

발주 전에 물어볼 것

"SECS/GEM 지원"은 답이 아니다. 견적서에서 확인할 문장은 이 셋이다.

  • 어느 GEM300 표준을 구현했는가 — E87, E40, E90, E94를 이름으로 하나씩. "GEM300 대응"은 묶음 상표지 사양이 아니다.
  • 구현한 stream과 function 목록 — 보통 벤더의 GEM compliance statement에 표로 들어 있다. 없다고 하면 그게 답이다.
  • 어느 객체를 S14로 노출하는가 — E39의 객체 서비스가 열려 있어야 E94 control job 쪽이 붙는다.

그리고 tool이 들어오기 전에 위 캡처를 한 번 해 보면, 스펙 시트와 실제가 어긋나는 지점이 첫날에 나온다. 여섯 프레임이면 끝난다.

여기 쓴 바이트는 SECS/GEM HSMS 시뮬레이터의 passive listener를 상대로 뽑았다. 같은 순서로 소켓을 열면 같은 프레임이 나온다.