SEMI E30 (GEM: Generic Equipment Model) Host와 연결이 끊겼을 시, Not Communicating와 Control State와의 관계

 SEMI E30 (GEM: Generic Equipment Model) 표준에서는 Communication State와 Control State가 독립적으로 동작할 수 있습니다. 따라서, Communication State가 Not Communicating으로 변경되더라도 Control State가 자동으로 Offline으로 변경되지 않는 것이 표준 동작일 수 있습니다.

---

📌 SEMI E30의 State 관계

1. Communication State

• Not Communicating
• Attempting to Communicate
• Communicating

2. Control State

• Offline
• Online-Local
• Online-Remote

---

📌 질문 상황 정리

1. 초기 상태:
   • Communication State: Communicating
   • Control State: Online-Remote
   • Host와 연결이 정상적으로 유지됨.
2. Host와 연결이 끊김 → Not Communicating 상태로 변경됨.
   • 하지만 Control State가 Online-Remote에 그대로 남아 있음.
   • Offline으로 자동 변경되지 않음.

---

📌 SEMI E30 표준 동작

1. Communication State 변화가 Control State에 직접적인 영향을 주지 않음
   • Communication State는 SECS/GEM 메시지 송수신 가능 여부를 나타내지만, Control State는 장비의 운영 상태를 의미합니다.
   • Host와 연결이 끊어져도 장비가 내부적으로 Online-Remote 상태를 유지할 수 있습니다.
2. Control State가 Offline으로 변경되지 않는 이유
   • SEMI E30에서는 Control State는 Equipment가 직접 변경하거나 Host가 명시적으로 변경하는 것이 원칙입니다.
   • Not Communicating 상태로 변경되었더라도, 장비가 Offline으로 자동 전환되는 것이 표준이 아닙니다.
   • 일반적으로 Online-Remote 상태를 유지하며, 장비가 특정 조건(예: 재부팅)에서 Offline으로 전환될 수 있습니다.

---

📌 해결 방안

✅ 장비 측에서 Offline으로 자동 변경되도록 구현하는 방법

• Host 연결이 끊어졌을 때, 내부적으로 S6F11 (Event Report) 또는 S1F1 (Are You There) 응답 실패를 감지하여 Offline으로 전환하는 로직 추가.
• 예제 로직:
  pseudo

  복사편집

  If Communication_State == "Not Communicating": If Control_State == "Online-Remote": Set Control_State = "Offline"
• 단, 이 방법은 SEMI E30 표준에 명확히 규정된 사항이 아니므로, 해당 장비 및 Host 간의 명확한 협의가 필요합니다.

✅ Host에서 Control State 변경을 요청

• Host가 주기적으로 S1F1 Ping을 보내거나, S2F17 (Request Control State Change)를 요청할 수 있음.
• 장비가 Not Communicating 상태에서 자동으로 Offline으로 전환하지 않는다면, Host에서 S2F17 (Change to Offline)을 보내는 방식으로 해결 가능.

---

📌 결론

• Communication State가 변경되어도 Control State는 자동으로 변경되지 않는 것이 SEMI E30의 원칙입니다.
• Offline 상태로 변경하려면 장비의 내부 로직을 추가하거나, Host에서 제어하는 방법을 고려해야 합니다.
• 사용자의 장비가 Not Communicating 시에도 Online-Remote 상태를 유지하는 것은 표준 동작이므로, 필요하면 별도로 제어 로직을 추가해야 합니다.

📌 추가 질문이 있으면 장비의 현재 동작 방식과 Host와의 통신 흐름을 알려주시면 더 정확한 해결 방안을 드릴 수 있습니다.

4o

나의 말:

Communicating ->Not Communicating 변경 관련 부분부터 확인 부탁드립니다.

 

ChatGPT의 말:

📌 SEMI E30에서 Communication State 변경 (Communicating → Not Communicating)

---

SEMI E30에서는 Communication State가 Communicating에서 Not Communicating으로 변경되는 트리거(Trigger)가 명확하게 정해져 있습니다.
이 변경은 주로 Host와의 연결 상태 및 SECS/GEM 메시지 흐름에 따라 결정됩니다.

---

✅ 1. Communication State 변화 조건

변경 전 상태변경 후 상태발생 조건

Communicating	Not Communicating	Host와의 연결이 끊어짐 (TCP/IP 단절, SECS 메시지 타임아웃 등)
Communicating	Attempting to Communicate	Host와의 연결이 끊겼지만 재연결 시도 중
Attempting to Communicate	Not Communicating	재연결 실패 (일정 시간 동안 응답 없음)

즉, Communicating → Not Communicating은 아래 조건 중 하나라도 충족되면 발생합니다.

1. TCP/IP 연결 단절 (소켓 연결 끊김)
   • Host 또는 장비에서 소켓이 닫히거나 네트워크 장애 발생 시.
   • S1F1 (Are You There?) 요청에 대한 응답 없음.
2. SECS 메시지 송수신 타임아웃
   • T3 Timeout (Message Response Timeout) 발생 시.
   • T5 Timeout (Inter-Character Timeout) 발생 시.
   • T6 Timeout (Control Transaction Timeout) 발생 시.
3. Host가 명시적으로 연결 해제
   • Host가 S1F15 (Request OFF-LINE) 또는 S1F13 (Establish Communication Request)를 통해 연결 종료 요청.

---

✅ 2. Communicating → Not Communicating 상태 전환 과정

1) 정상 동작 흐름

less

복사편집

[장비] ─────────── [Host] | S1F13 (ECV Request) → 요청 (TCP/IP 세션 연결) | ← S1F14 (ACK) 응답 (연결 수락) | S1F1 (Are You There?) → 상태 확인 | ← S1F2 (Reply) 응답 | (정상 메시지 송수신) | (통신 유지 중 - Communicating 상태)

2) Not Communicating 상태로 변하는 시나리오

• Case 1: Host 응답 없음 (Timeout 발생)
• java
  복사편집
  [장비] ─────────── [Host] | S1F1 (Are You There?) → | (응답 없음: T3 Timeout 발생) | - Communication State = Not Communicating
• Case 2: TCP/IP 연결 단절
• java
  복사편집
  [장비] ─────────── [Host] | (TCP 연결 단절) | - Communication State = Not Communicating
• Case 3: Host에서 OFFLINE 요청
• pgsql
  복사편집
  [장비] ─────────── [Host] | ← S1F15 (Request OFF-LINE) | - Communication State = Not Communicating

---

✅ 3. Not Communicating 상태 시 장비의 동작

• S1F1 (Are You There?) 요청을 보낼 수 없음.
• S2F17 (Change Control State Request) 수신 불가능.
• Host와 통신이 불가능하므로 장비는 내부적으로 Offline으로 변경할 수도 있지만, 이는 SEMI 표준에서 강제되지 않음.

---

📌 정리

• Communicating → Not Communicating은 Host와의 연결이 끊어질 때 자동으로 발생.
• 타임아웃 (T3, T5, T6 등) 또는 TCP 연결 단절이 주요 원인.
• Not Communicating 상태에서는 Host와 메시지를 주고받을 수 없으며, Control State가 자동으로 Offline으로 변경되지 않을 수도 있음.
• Host와 연결이 복구되면 Attempting to Communicate를 거쳐 다시 Communicating으로 변경됨.

👉 다음 단계: Not Communicating 상태에서 Control State (Online-Remote → Offline)가 자동 변경되지 않는 원인 및 해결 방안이 필요하시면 추가 설명드리겠습니다.