00-overview
SECS/GEM 기본 개념

SECS/GEM 기본 개념

SECS/GEM 기본 개념

한 문장 설명

SECS/GEM은 공장 상위 시스템과 장비가 서로 같은 언어와 같은 절차로 대화하기 위한 산업 표준입니다.

왜 필요한가

장비마다 독자 통신 방식을 쓰면 Host는 장비가 바뀔 때마다 새로 개발해야 합니다. SECS/GEM은 이 문제를 줄이기 위해, “상태 조회”, “이벤트 보고”, “알람 보고”, “레시피 송수신”, “원격 명령” 같은 공통 기능을 표준 방식으로 맞춥니다.

쉽게 말해, SECS/GEM은 제조 장비용 API 표준에 가깝습니다.

계층

SECS/GEM 인터페이스는 보통 다음 세 층으로 이해하면 됩니다.

계층 역할 대표 요소
전송 연결 수립과 세션 유지 HSMS, TCP/IP
메시지 데이터 구조와 Stream/Function SECS-II
동작 모델 어떤 상황에서 어떤 메시지를 주고받는지 GEM, E87, E90, E94, E40, E116

비유

  • HSMS: 전화선
  • SECS-II: 대화 문장 형식
  • GEM: 업무 절차와 역할 규칙

전화선만 있다고 업무가 되지 않는 것처럼, HSMS만으로는 충분하지 않습니다. 반대로 문장 형식만 있어도 언제 무엇을 말할지 정하지 않으면 자동화가 어렵습니다. GEM은 그 빈칸을 채웁니다.

메시지 구조

SECS-II 메시지는 SxFy 형식으로 표현합니다.

  • S: Stream
  • F: Function
  • 홀수 F는 보통 Primary Message
  • 짝수 F는 보통 Reply Message

예:

  • S1F13 / S1F14: 통신 수립
  • S1F17 / S1F18: Online 전환 요청/응답
  • S2F41 / S2F42: Remote Command 요청/응답
  • S6F11 / S6F12: Event Report 송신/응답

Stream을 기능 묶음으로 보는 법

처음 볼 때는 숫자가 너무 많아 보이지만, 보통 아래처럼 묶어 보면 이해가 쉬워집니다.

Stream 대략적인 의미
S1 연결과 기본 상태
S2 제어, 상수, 이벤트 설정
S5 알람
S6 이벤트와 수집 데이터
S7 레시피/프로그램
S9 오류
S10 터미널/메시지 표시

데이터 타입

SECS-II에서 자주 보이는 데이터 타입은 다음과 같습니다.

타입 의미
A ASCII 문자열
U1, U2, U4 부호 없는 정수
I1, I2, I4 부호 있는 정수
F4, F8 실수
BOOLEAN 논리값
L List
B Binary

실무에서 중요한 포인트

  • 타입이 다르면 같은 의미의 값도 Host가 해석하지 못할 수 있습니다.
  • A와 U*를 혼용하면 파서가 꼬이기 쉽습니다.
  • 배열성 데이터는 L 구조 해석 규칙을 명확히 정해야 합니다.

W-Bit와 응답

  • W-Bit=1이면 Primary Message에 대한 Reply가 필요합니다.
  • W-Bit=0이면 응답 없이 단방향으로 처리할 수 있습니다.
  • 실제 GEM 구현에서는 중요한 상태 변경이나 명령성 메시지는 보통 응답을 요구합니다.

해석 포인트

W-Bit는 “답장 꼭 주세요"에 가깝습니다. 다만 GEM에서는 단순한 답장만 받는 것으로 끝나지 않고, 이후 상태 변화 Event까지 확인해야 하는 경우가 많습니다.

Host와 Equipment의 책임

Host 책임

  • 통신 수립과 연결 유지 정책을 맞춥니다.
  • 필요한 보고서와 이벤트 링크를 정의합니다.
  • Online/Offline, Local/Remote 제어 요청을 보냅니다.
  • Variable, Alarm, Recipe, Job, Carrier 관련 메시지를 표준 절차에 맞게 호출합니다.

Equipment 책임

  • 표준 상태 모델에 맞는 응답과 거절 코드를 돌려줍니다.
  • Event 발생 시 적절한 Report를 생성합니다.
  • 정의된 Variable ID에 대해 일관된 타입과 의미를 유지합니다.
  • 재연결, 스풀링, 시계 동기화 같은 운영성 기능을 안정적으로 지원합니다.

가장 자주 쓰는 대화 패턴

1. 연결 확인

  • S1F13/S1F14
  • S1F1/S1F2

2. 상태 조회

  • S1F3/S1F4
  • S2F13/S2F14

3. 이벤트 설정

  • S2F33~S2F38
  • 이후 S6F11/S6F12

4. 명령 실행

  • S2F41/S2F42
  • 필요 시 추가 Event 확인

5. 알람

  • S5F1/S5F2

식별자 계층

식별자 계층

GEM 데이터 수집에서 핵심 식별자는 다음과 같습니다.

식별자 의미 용도
SVID Status Variable ID 현재 상태 조회
ECID Equipment Constant ID 설정값 조회/변경
DVID Data Variable ID Event Report에 실리는 데이터
CEID Collection Event ID 이벤트 발생 식별
RPTID Report ID DVID 묶음

관계는 보통 CEID -> RPTID -> DVID 순서입니다.

해석

  • CEID: 어떤 일이 일어났는가
  • RPTID: 그 일을 보고할 때 어떤 데이터 묶음을 쓸 것인가
  • DVID: 보고서 안에 들어갈 실제 데이터는 무엇인가
  • SVID: Host가 직접 물어볼 수 있는 현재 상태는 무엇인가
  • ECID: Host가 보고 바꿀 수 있는 설정값은 무엇인가

예시로 보는 전체 그림

예를 들어 장비가 처리 상태를 바꾸면 다음과 같이 볼 수 있습니다.

  1. 내부 상태가 Idle -> Executing으로 바뀝니다.
  2. 해당 변화가 CEID로 식별됩니다.
  3. 그 CEID에 연결된 RPTID가 선택됩니다.
  4. 보고서 안에는 ProcessingState, PreviousProcessingState 같은 DVID가 실립니다.
  5. Host는 S6F11을 받고 상태 변화를 알게 됩니다.

이 흐름을 이해하면 GEM의 절반은 이해한 셈입니다.

SML 관점

두 참고 문서 모두 SML 표기법을 별도 장으로 설명합니다. 구현 문서에서 중요한 점만 요약하면 다음과 같습니다.

  • List 안에 List가 들어가는 구조를 자주 씁니다.
  • 배열성 데이터는 L 또는 반복 아이템으로 표현합니다.
  • Null 또는 빈 값은 길이 0 아이템으로 표현할 수 있습니다.
  • 메시지 예제는 구조를 보여주는 용도로 쓰고, 실제 값은 별도 인터페이스 표로 관리하는 편이 낫습니다.

실무 팁

  • 문서에는 사람이 읽기 쉬운 SML 예제와, 구조를 빠르게 파악할 수 있는 JSON풍 설명을 같이 두는 것이 좋습니다.
  • 처음 읽는 문서에서는 모든 메시지를 SML로 시작하지 말고, 먼저 “누가 누구에게 무엇을 요청하는가"를 문장으로 적는 편이 낫습니다.

실무 해석 팁

  • SECS-II는 “문법”, GEM은 “대화 규칙"으로 보면 이해가 쉽습니다.
  • 상태 조회보다 이벤트 구동 방식이 운영 효율이 높습니다.
  • 장비별 문서의 차이는 대부분 변수명, 이벤트명, Remote Command 목록에서 발생합니다.
  • 핵심 프레임은 거의 동일하므로, 공통 문서를 먼저 만들고 장비별 차이를 덧씌우는 방식이 유지보수에 유리합니다.
범위와 소스표준 모델 지도