ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • SEMI E30 (GEM: Generic Equipment Model) Host와 연결이 끊겼을 시, Not Communicating와 Control State와의 관계
    프로그램(C++ etc.) 2025. 3. 20. 13:35

     SEMI E30 (GEM: Generic Equipment Model) 표준에서는 Communication StateControl 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)가 자동 변경되지 않는 원인 및 해결 방안이 필요하시면 추가 설명드리겠습니다.

    '프로그램(C++ etc.)' 카테고리의 다른 글

    mfc서 thread의 핵심  (0) 2024.10.09
Designed by Tistory.