데이터 수집

10-gem-core

데이터 수집

소개

SECS/GEM에서 데이터 수집은 “Host가 장비 상태를 계속 묻는 것"이 아닙니다. 더 중요한 방식은 장비가 의미 있는 일이 일어났을 때 스스로 보고하는 것입니다. 이를 이해하지 못하면 SECS/GEM을 단순 조회 프로토콜로 오해하기 쉽습니다.

개요

GEM 데이터 수집의 핵심은 “무엇을 볼 것인가"보다 “어떤 이벤트에 어떤 데이터 묶음을 실어 보낼 것인가"에 있습니다. 두 참고 문서 모두 Variable, Report, Event, Trace, Limits Monitoring을 한 묶음으로 설명합니다.

구성 요소

요소	역할
`SVID`	현재 상태를 Host가 조회
`ECID`	설정값 조회/변경
`DVID`	Event Report에 포함되는 데이터 아이템
`RPTID`	DVID 묶음
`CEID`	Event 발생 트리거

E53 관점에서 보면

데이터 수집 장은 GEM 일반 기능처럼 보이지만, 그 구조를 더 정확히 설명하는 표준 축은 E53 Event Reporting입니다.
이 관점에서 보면 데이터 수집은 세 가지 계약으로 나뉩니다.

어떤 사건을 보고 대상으로 볼 것인가
그 사건에 어떤 데이터 묶음을 연결할 것인가
Host가 그 보고 구조를 어떻게 설정하고 활성화할 것인가

즉, 데이터 수집은 단순 조회 기능이 아니라 이벤트, 보고서, 데이터 변수를 조합하는 보고 설계입니다.

E134는 그보다 한 단계 위의 관리 축입니다.

현재 문서의 중심은 GEM과 E53 Event Reporting입니다.
하지만 .Reference에는 E134 Data Collection Management도 포함되어 있습니다. 이 표준은 GEM Event Report를 대체하기보다, 더 상위의 데이터 수집 관리 모델로 읽는 편이 자연스럽습니다.

즉, 현재 일반편은 E53 중심으로 설명하고, E134는 확장 가능한 상위 관리 표준로 연결만 해 두는 방식이 적절합니다.

E151은 수집된 데이터의 품질을 보는 축입니다.

데이터를 많이 받는다고 해서 항상 좋은 데이터 수집이 되는 것은 아닙니다.
E151은 이런 관점에서 장비 생성 데이터의 품질을 어떻게 공통 용어로 말할지 정리하는 가이드입니다.

즉, 현재 장은 무엇을 어떻게 수집하는가를 설명하고, E151은 그 다음 단계에서 그 데이터가 얼마나 믿을 만한가를 논의하는 보조 축으로 이해하면 됩니다.

Host가 실제로 하는 일

데이터 수집을 “장비가 알아서 보내는 기능"으로만 보면 절반만 이해한 것입니다. 실제 운영에서는 Host가 먼저 보고 구조를 정하고, 그 뒤에 장비가 그 구조에 맞춰 보고합니다.

Host가 보통 먼저 정하는 것은 다음과 같습니다.

어떤 CEID를 받을 것인가
어떤 DVID를 묶어 어떤 RPTID로 만들 것인가
어떤 이벤트를 활성화할 것인가
어떤 값은 조회로 보고, 어떤 값은 이벤트로 받을 것인가

즉, Event 기반 보고도 설계 없이 저절로 완성되는 기능은 아닙니다.

한 번에 이해하는 구조

처음에는 아래 순서로 이해하면 됩니다.

장비 안에서 어떤 일이 발생합니다.
그 일이 CEID로 식별됩니다.
해당 CEID에 연결된 RPTID가 선택됩니다.
그 보고서 안에 정의된 DVID가 채워집니다.
S6F11으로 Host에 전송됩니다.

이 흐름이 GEM의 Event 기반 데이터 수집입니다.

Event, Report, Variable을 분리해서 봐야 합니다.

문서를 읽을 때 가장 자주 섞이는 개념은 다음 세 가지입니다.

CEID: 어떤 일이 일어났는가
RPTID: 어떤 형식으로 묶어 보낼 것인가
DVID: 실제로 어떤 값을 넣을 것인가

이 셋을 분리하지 않으면 “이벤트를 정의했다"와 “보고서를 정의했다"를 같은 작업으로 오해하기 쉽습니다.
실무에서는 보통 Event보다 Report를 더 오래 재사용하고, Variable은 여러 Report에서 공유합니다.

Event와 상태 전이는 항상 같은 것은 아닙니다.

처음에는 상태 전이가 곧 데이터 수집 이벤트라고 생각하기 쉽습니다. 하지만 실무에서는 두 개를 분리해서 설계하는 경우가 많습니다.

상태 전이 이벤트는 장비 상태가 바뀌었음을 알려 줍니다.
데이터 수집 이벤트는 특정 수준의 데이터가 준비되었음을 알려 줍니다.

예를 들어 어떤 작업이 끝나는 순간에는 상태 전이와 데이터 완료 시점이 거의 같을 수 있지만, 데이터 정리나 묶음 구성이 끝나기 전까지는 별도 완료 이벤트를 두는 편이 더 안전할 수 있습니다.

따라서 일반편에서는 “상태가 바뀌었는가"와 “보고할 데이터가 준비되었는가"를 같은 문제로 취급하지 않는 편이 좋습니다.

대표 메시지

기능	메시지
상태 조회	`S1F3/S1F4`, `S1F11/S1F12`
EC 조회/변경	`S2F13~S2F16`, `S2F29/S2F30`
Report 정의	`S2F33/S2F34`
Event-Report 연결	`S2F35/S2F36`
Event enable/disable	`S2F37/S2F38`
Trace	`S2F23/S2F24`, `S6F1/S6F2`
Event 보고	`S6F11/S6F12`
Limits Monitoring	`S2F45~S2F48`

위 메시지군은 E53.1 관점에서 보면 Event Reporting 구조를 Host가 구성하고 장비가 운용하도록 만드는 핵심 메시지군입니다.

왜 Event 기반이 중요한가

Polling만 사용할 때의 문제

Host 부하 증가
네트워크 트래픽 증가
상태 변화를 놓칠 수 있음
모든 상태를 주기적으로 읽어야 함

Event 기반의 장점

장비가 중요한 변화만 선별해서 보냄
순간 상태 변화를 놓칠 가능성이 줄어듦
운영 기록을 남기기 쉬움
Host 설계를 상태 전이 중심으로 만들 수 있음

Event 기반 수집 흐름

sequenceDiagram
    participant H as Host
    participant E as Equipment
    H->>E: S2F33 Define Report
    E-->>H: S2F34 Ack
    H->>E: S2F35 Link Event Report
    E-->>H: S2F36 Ack
    H->>E: S2F37 Enable Event Report
    E-->>H: S2F38 Ack
    E->>H: S6F11 Event Report Send
    H-->>E: S6F12 Ack

조회 중심과 이벤트 중심

조회 중심

Host가 필요할 때마다 S1F3, S2F13 등을 호출
단순하지만 polling 부하가 크다

이벤트 중심

설비가 상태 변화 시 S6F11 송신
운영 시스템에서 일반적으로 선호
보고서 설계가 품질을 좌우한다

조회와 이벤트를 어떻게 나누는가

실무에서는 모든 값을 이벤트로 보내지도 않고, 모든 값을 조회로 읽지도 않습니다. 보통 아래처럼 나누면 이해가 쉽습니다.

대상	보통 적합한 방식	이유
현재 제어 상태, 현재 통신 상태	조회 + 중요 변화는 이벤트	현재값 확인과 변화 감시가 모두 필요
ProcessingState 전이	이벤트 중심	순간 전이가 중요
포트나 캐리어의 현재 점유 상태	조회 + 주요 변화 이벤트	화면 표시와 추적이 함께 필요
로그성 수치, 추이 데이터	Trace 또는 별도 수집	변화 이력 관찰 목적
설정값	조회/변경	운영 정책 확인 목적

보고 레벨 개념

많은 장비는 데이터를 한 번에 모두 보내지 않고, 의미 있는 단위로 묶어서 보고합니다. 이 묶음 단위를 여기서는 보고 레벨이라고 부릅니다.

범용적으로 보면 보고 레벨은 보통 다음처럼 이해할 수 있습니다.

레벨	의미	예시
Run	한 번의 큰 작업 단위	배치, lot, run 완료
Material	자재 또는 기판 단위	substrate 완료
Group	하위 묶음 단위	영역, 구간, 묶음 완료
Site / Position	더 세부 위치 단위	측정 지점, 위치 완료
Item / Anomaly	가장 세부 항목	개별 결과, 개별 이상 항목

핵심은 상위 레벨로 갈수록 요약성이 높아지고, 하위 레벨로 갈수록 상세성이 높아진다는 점입니다.

왜 보고 레벨이 필요한가

모든 세부 데이터를 매번 다 보내면 통신량이 커집니다.
상위 시스템은 경우에 따라 요약 결과만 필요할 수 있습니다.
상세 데이터는 필요할 때만 더 낮은 레벨에서 받는 편이 효율적입니다.
데이터가 어느 단위에서 완성되는지를 문서화하기 쉬워집니다.

개념 차이

SVID

지금 현재 상태를 Host가 읽고 싶을 때 쓰는 값

DVID

이벤트가 발생했을 때 같이 보내는 값

ECID

설비의 설정값 또는 정책값

CEID

무슨 일이 발생했는지 알려 주는 이벤트 ID

RPTID

이벤트 보고서 템플릿

보고서 설계 원칙

하나의 CEID에는 너무 많은 DVID를 싣지 않습니다.
상태 전이형 Event에는 현재 상태와 이전 상태를 같이 넣는 편이 좋습니다.
식별자형 Event에는 ID, 상태, 원인 정보를 함께 보냅니다.
Job/Carrier/Substrate 이벤트는 상위 ID와 하위 위치 정보를 같이 보냅니다.
Event와 Report를 일대일로 고정하지 말고, 재사용 가능성을 먼저 봅니다.
보고 활성화 정책도 인터페이스 계약으로 문서화합니다.

좋은 보고서/나쁜 보고서 예시

좋은 예

ProcessingStateChanged 이벤트 발생
보고서에 현재 상태, 이전 상태, 시간 포함

Host는 이 한 번의 이벤트만으로 상태 전이를 이해할 수 있습니다.

나쁜 예

이벤트 이름은 StatusChanged
보고서에는 상태값 하나만 있음

이 경우 Host는 무엇이 왜 바뀌었는지 추가 조회를 해야 합니다.

XML에서 확인된 공통 구조

첨부 Reports.xml은 전형적인 GEM 보고서 구조를 보여 줍니다.

RPTID	포함 DVID	해석
`300100`	`300002,300003`	Processing 상태 전이
`300101`	`300000,300001`	Comm/Control 상태
`400001`	`400001,400002`	Process Job 상태
`870001`	포트 상태 계열	Carrier/Port 상태
`900001`	Substrate 상태 계열	Substrate 추적
`940001`	`940001,940002`	Control Job 상태

이벤트 시점 설계 원칙

이벤트는 “언젠가 보내면 되는 신호"가 아닙니다. 어떤 이벤트를 언제 올릴지에 따라 Host가 해석하는 결과가 달라집니다.

일반편에서 권장할 수 있는 원칙은 다음과 같습니다.

데이터 완료 이벤트는 관련 데이터가 실제로 보고 가능한 시점에 맞춥니다.
상태 전이와 밀접한 이벤트는 전이 이전인지 이후인지 문서에서 분명히 합니다.
상위 레벨 완료 이벤트는 하위 레벨 데이터가 충분히 집계된 뒤 보내는 편이 안전합니다.
보고 레벨이 다른 이벤트는 서로 대체 관계인지 누적 관계인지 밝혀 둡니다.

완료 데이터는 너무 늦지 않게 보여야 합니다.

Host 입장에서는 “상태는 끝났다고 보이는데, 결과 데이터는 아직 안 왔다"는 상황이 길어질수록 해석이 어려워집니다. 그래서 일반편에서는 다음 원칙을 권장할 수 있습니다.

요약 결과는 관련 상태 완료 시점 이전 또는 직후에 사용할 수 있어야 합니다.
하위 레벨 상세 데이터가 늦게 도착하더라도, 상위 레벨 요약 데이터는 먼저 해석 가능해야 합니다.
완료 이벤트와 결과 이벤트를 나누는 경우에는 두 이벤트의 관계를 문서에서 분명히 적어야 합니다.

자주 실패하는 설계 패턴

이벤트 이름은 자세한데 보고서 데이터가 너무 적은 경우
반대로 하나의 이벤트에 너무 많은 DVID를 몰아넣는 경우
현재 상태만 보내고 이전 상태를 보내지 않는 경우
동일 의미를 SVID와 DVID에서 서로 다른 타입으로 정의한 경우
Event를 활성화하지 않고 조회만으로 운영하려는 경우

이런 구조는 처음에는 단순해 보여도, 운영 단계에서 추가 조회와 예외 처리가 빠르게 늘어납니다.

Trace Data와 Event Report의 차이

둘 다 데이터를 보내지만 목적이 다릅니다.

항목	Event Report	Trace Data
트리거	이벤트 발생	주기 또는 샘플링
용도	상태 변화 보고	추이 관찰, 진단
대표 메시지	`S6F11/S6F12`	`S6F1/S6F2`

이 구분이 모호하면 Host가 데이터 처리 구조를 잘못 잡기 쉽습니다.

Limits Monitoring

Limits Monitoring은 단순 조회가 아니라, 변수값이 정의된 범위를 벗어날 때 자동으로 알리기 위한 기능입니다.

대상 변수는 수치형이어야 합니다.
상한/하한, deadband, 감시 활성화 조건을 같이 문서화합니다.
실제 설비에서는 장비 특성이 강하므로 장비특화편에서 상세 임계값을 추가하는 것이 적절합니다.

실무 메모

Status 조회용 SVID와 Event용 DVID를 분리하면 변경 영향이 작습니다.
S1F3로 모든 상태를 끌어오게 만들면 Host 의존도가 높아집니다.
이벤트 설계 시 “복구 이벤트"까지 같이 정의해야 운영에서 쓸 수 있습니다.

장비특화편에서 이어서 적을 항목

실제 CEID-RPTID 연결표
Event enable 기본 정책
Trace 수집 대상과 샘플링 조건
Limits Monitoring 실제 임계값과 단위
Host 초기 동기화 시 반드시 조회할 SVID 목록

E160은 데이터 품질을 실제로 전달하는 축입니다.

E151이 데이터 품질을 어떻게 이해할지 설명하는 가이드라면, E160은 그 품질을 통신 가능한 metric으로 표현하는 표준에 가깝습니다.

즉, 다음처럼 나누어 보면 이해가 쉽습니다.

GEM Event/Report/Trace: 무엇을 수집하고 언제 보내는가
E151: 그 데이터 품질을 어떤 관점과 용어로 이해할 것인가
E160: 그 품질 수준을 어떤 metric으로 전달할 것인가

데이터를 많이 주는 것만으로는 충분하지 않고, Host가 그 데이터를 얼마나 신뢰할 수 있는지도 중요할 때 E160의 의미가 커집니다. 현재 일반편에서는 개념 연결만 남기고, 상세 내용은 별도 참고 계층에서 다룹니다.

제어 상태 데이터 수집