이 블로그는 원래 cimetrix.com에 게시되었습니다.
프로토콜 계층의 목적
프로토콜 계층은 데이터를 패킷화하여 공장 호스트와 장비 GEM 인터페이스 간에 안정적으로 전송합니다.
프로토콜 계층 정의
프로토콜 계층은 공장 호스트와 장비 GEM 인터페이스 간에 유선으로 메시지를 전송하는 데 사용되는 전송 기술 및 데이터 패킹 알고리즘을 구현합니다.
SEMI E5 표준인 SEMI 장비 통신 표준 2 메시지 내용(SECS-II)은 데이터로 사용되는 SECS 메시지를 정의하고, 전송을 위해 이들이 이진 버퍼에 어떻게 패킹되는지를 규정합니다.
SEMI E37 및 E37.1 표준인 고속 SECS 메시지 서비스(HSMS)는 TCP/IP 연결을 통해 SECS 메시지를 교환하기 위한 프로토콜을 정의합니다. 이는 SECS/GEM에서 가장 널리 사용되는 전송 기술입니다.
HSMS 프로토콜 스택
SEMI E4 표준인 SEMI 장비 통신 표준 1 메시지 전송(SECS-I)은 RS-232를 통해 SECS 메시지를 교환하는 메커니즘을 정의합니다. 이는 일반적으로 구형 장비나 EFEM 컨트롤러와 같은 장비 내부의 일부 하드웨어에 사용됩니다.
본 문서의 나머지 부분은 HSMS를 통한 SECS 메시지에 초점을 맞출 것입니다.
프로토콜 계층의 이점
GEM의 프로토콜 계층은 연결을 유지하고 연결 손실을 감지하여 양측이 스풀링 활성화와 같은 적절한 조치를 취할 수 있도록 합니다.
프로토콜 계층은 필요한 경우 메시지 전달을 보장하기 위한 핸드셰이킹 메커니즘을 정의한다.
프로토콜 계층 연결은 공장 호스트와 장비 간에 지점 간 연결입니다. 이는 브로드캐스트 기능이 없는 전용 연결입니다. 이로 인해 네트워크 부하를 예측하기가 더 쉬워집니다.
데이터 밀도
SECS/GEM은 오버헤드가 적고 고밀도로 데이터를 전송합니다. 이는 주어진 데이터 세트에 대해 네트워크 대역폭 사용량이 적다는 것을 의미합니다.
설명 목적으로, 이벤트 보고서의 전형적인 예시를 살펴보고 SECS/GEM 메시징을 다소 유사한 XML 및 JSON 메시지와 비교해 보자.
일반적인 GEM 인터페이스를 예로 들면, ID에는 부호 없는 4바이트 정수를 사용하고 이벤트 보고서에는8바이트 부동 소수점 숫자와 4바이트 정수를 포함합니다. 이 메시지의 예시는 아래 표에 E5에 따른 SECS/GEM 형식과 동등한 JSON 및 XML 형식으로 표시되어 있습니다.
이진 SECS/GEM 메시지는 전송 시 58바이트를 차지하며, JSON은 약 206바이트, XML은 175바이트입니다. JSON과 XML의 바이트 수는 키/요소 이름에 따라 다소 변동될 수 있으며, 위 수치는 여러 가능한 표현 방식 중 하나에 불과합니다.
예시 메시지의 데이터 밀도 비교를 보여주는 차트가 아래에 제시됩니다. 실제 데이터 크기는 2개의 4바이트 정수 + 2개의 8바이트 부동 소수점 숫자 + 1개의 4바이트 이벤트 ID + 1개의 4바이트 보고서 ID = 32바이트의 실제 데이터입니다. 오버헤드는 메시지의 총 바이트 수에서 실제 데이터 크기를 빼서 계산됩니다.
예시 메시지의 SECS 데이터 밀도 백분율은 아래 그래프에 표시되어 있습니다. 데이터 밀도 백분율은 (실제 데이터) / 오버헤드 × 100으로 계산됩니다.
이제 예시 메시지를 8바이트 부동소수점 숫자 100개로 변경하면 데이터 밀도 % 그래프가 아래 차트로 바뀝니다. JSON과 XML은 상대적으로 비슷하지만 SECS/GEM 데이터 밀도는 78%로 증가합니다.
SECS/GEM 인코딩은 오버헤드가 매우 적습니다. 메시지의 오버헤드는 메시지를 설명하는 헤더 10바이트에 메시지 본문의 크기(1~4바이트)가 추가됩니다. SECS 메시지 내 4바이트 정수 또는 부동소수점 숫자의 경우, 6바이트가 전송됩니다. 정수 값 4바이트 + 유형 1바이트 + 데이터 길이(바이트 단위) 1바이트입니다. 마찬가지로, 8바이트 정수 또는 부동 소수점 숫자의 경우 10바이트가 전송됩니다. 문자열 값의 경우 길이는 문자 수에 2~4바이트가 추가됩니다. SECS 메시지에 리스트(위 가독성 예시에서 L)가 포함될 때마다 메시지에 2~4바이트가 추가됩니다.
SECS/GEM에서 숫자 배열은 매우 효율적입니다. 배열의 오버헤드는 타입에 대한 1바이트와 배열 길이에 대한 1~4바이트, 그리고 원본 크기의 데이터로 구성됩니다. 예를 들어: 4바이트 정수 10개로 구성된 배열은 42바이트를 차지하며, 이는 95%의 데이터 밀도를 의미합니다!
JSON 예시에서 4바이트 정수는 16바이트 + 정수를 표현하는 데 필요한 문자 수, 즉 17~28바이트가 필요합니다. 부동 소수점 숫자도 동일한 오버헤드를 가지지만, 값을 표현하는 데 더 많은 문자가 필요할 수 있습니다.
XML에서 오버헤드는 XML 요소 이름의 크기에 기반합니다. 위 예시의 요소 이름을 사용하면, 어떤 4바이트 정수든 전송되는 바이트 수는 9바이트에 정수를 표현하는 데 필요한 문자 수를 더한 값, 즉 10바이트에서 21바이트가 됩니다. 부동 소수점 수는 값을 표현하는 데 사용되는 문자열 형식에 따라 달라집니다.
요약하자면, 전송되는 항목별 바이트 크기를 살펴보면 SECS/GEM은 매우 고밀도입니다. 4바이트 정수 예시를 보면 SECS/GEM은 전송 시 6바이트, JSON 예시는 17~28바이트, XML 예시는 10~21바이트이며, 매개변수 수가 증가함에 따라 오버헤드가 실제로 중요해짐을 알 수 있습니다. 300mm 반도체 장비는 공정 모듈당 초당 1000개 매개변수를 호스트로 전송해야 합니다. 2모듈 장비의 경우 데이터만으로도 다음과 같은 바이트 수를 발생시킵니다: SECS/GEM 기준 12K 바이트, JSON 기준 34K~56K 바이트, XML 기준 20K~42K 바이트. 이 수치는 메시지 나머지 부분의 크기를 고려하지 않은 것으로, 오직 매개변수 값과 관련된 실제 부분만을 반영합니다. 만약 해당 데이터가 메시지당 값이 적은 다수의 메시지로 전송된다면 네트워크 부하는 더욱 악화됩니다. 모든 경우에 더 적은 수의 더 큰 메시지가 항상 더 낫습니다.
XML과 JSON은 사용되는 전송 프로토콜에 따라 오버헤드를 추가할 수도 있습니다. 예를 들어, XML은 종종 SOAP을 사용하여 HTTP를 통해 전송되는데, 이는 각 메시지마다 두 개의 추가 오버헤드 계층과 더 많은 바이트를 전송선에 추가합니다. SECS/GEM에 표시된 바이트 수는 TCP/IP 위에 전송선을 통해 전송되는 실제 데이터량입니다.
데이터 번역 없음
SECS/GEM에서는 숫자 데이터가 변환 없이 전송됩니다. 숫자는 원본 형식으로 전송됩니다. 예를 들어: 8바이트 부동 소수점 수는 변환, 절삭 또는 반올림 없이 8바이트 표현 그대로 전송됩니다.
JSON이나 XML과 같은 모든 프로토콜은 해당 8바이트 부동 소수점 숫자를 텍스트 표현으로 변환해야 합니다. 이는 인코딩 및 디코딩을 위한 컴퓨팅 자원을 소모하며, 네트워크를 통해 전송되는 바이트 수를 상당히 증가시킵니다. IEEE754는 8바이트 부동소수점 숫자를 문자열로 정확히 표현하기 위해 17자리 십진수를 요구합니다. 부호, 소수점, 지수, 지수 부호에 대한 문자를 추가하면 총 21자리가 됩니다. 이는 SECS/GEM이 네트워크를 통해 전송하는 바이트 수의 두 배 이상입니다.
회로 보증
HSMS는 링크 테스트(Link Test)라는 회로 보장 메커니즘을 정의합니다. 프로토콜 계층에는 활성 메시지 교환이 없을 경우 시작되는 타이머가 있습니다. 타이머가 만료될 때마다 연결이 여전히 열려 있는지 확인하기 위해 프로토콜 메시지가 교환됩니다.
보안
HSMS는 어떠한 보안도 정의하지 않습니다. 연결 당사자에 대한 검증은 없으며, 연결 시 자격 증명이나 인증서가 필요하지 않습니다. 데이터는 일반적인 암호화 알고리즘으로 암호화되지 않지만, 데이터 패키징 과정을 통해 난독화되어 일반적으로 사람이 읽을 수 없습니다.
보안은 일반적으로 문제가 되지 않는데, 공장 네트워크가 외부 세계와 격리되어 있기 때문이다.
결론
HSMS를 사용하는 SECS/GEM 프로토콜 계층은 공장 호스트와 장비 간에 정확한 데이터를 교환하는 매우 효율적인 수단을 제공합니다.