3. SECS GEM 连接建立流程:主动连接与被动连接模式、T3/T5/T6/T7/T8 定时器的作用

SECS GEM 通信的基石是 TCP Socket 连接。在连接建立阶段,设备(Equipment)与主机(Host)必须明确各自的角色——谁是主动发起方,谁是被动监听方。同时,为了保障连接过程的可靠性与异常可诊断性,SEMI 标准定义了多个关键定时器(T3、T5、T6、T7、T8)。本章将深入剖析这两种连接模式以及每个定时器的具体作用与诊断价值。

3.1 主动连接模式(Active Mode)

在主动连接模式下,设备作为 TCP 客户端,主动向主机(服务器)发起 Socket 连接请求。这是半导体工厂中最常见的部署方式,因为设备通常位于防火墙之后,由设备主动外联主机更为安全可控。

关键特征:
  • 设备调用 connect() 系统调用,向主机的 IP:Port 发起 SYN 握手。
  • 设备必须预先配置主机的 IP 地址和端口号(通常为 5000 或 5001)。
  • 连接建立后,设备立即发送 Logon 请求(S1F13),进入通信协商阶段。
  • 主机侧只需被动监听,无需主动寻址设备。
诊断要点: 如果设备日志显示 connect() 超时或返回 ECONNREFUSED,应优先检查主机 IP 可达性、端口是否开放、主机侧防火墙规则以及主机 GEM 服务是否已启动。

3.2 被动连接模式(Passive Mode)

在被动连接模式下,设备作为 TCP 服务器,监听一个本地端口(通常为 5000 或 5001),等待主机主动发起连接。这种模式适用于主机需要主动轮询设备状态或设备 IP 不固定的场景。

关键特征:
  • 设备调用 bind() 和 listen(),进入监听状态。
  • 主机作为客户端,主动向设备的 IP:Port 发起 SYN 握手。
  • 连接建立后,主机发送 Logon 请求(S1F13),设备响应。
  • 设备必须拥有固定的 IP 地址或主机可通过 DNS 解析到设备。
常见陷阱: 被动模式下,如果设备侧存在多个网卡或防火墙,务必确认监听端口绑定在正确的网络接口上(0.0.0.0 或特定 IP)。否则主机将无法建立 TCP 连接,且设备日志中可能仅显示 SYN_RECV 状态而无进一步进展。

3.3 主动 vs 被动模式对比

对比维度 主动模式(设备为客户端) 被动模式(设备为服务器)
TCP 角色 设备 = Client,主机 = Server 设备 = Server,主机 = Client
连接发起方 设备 主机
设备配置要求 需配置主机 IP:Port 需配置本地监听端口,固定 IP
防火墙友好度 高(设备主动出站) 低(需开放设备入站端口)
典型应用场景 300mm 晶圆厂、老旧设备改造 测试环境、主机主动轮询场景
Logon 发起方 设备(S1F13) 主机(S1F13)

3.4 SECS GEM 连接建立流程(含定时器)

无论采用哪种模式,连接建立后的逻辑流程是一致的。下图展示了从 TCP 连接到通信就绪的完整状态机,并标注了各定时器的介入点。

SECS GEM 连接建立流程与定时器介入点 TCP 连接建立 (SYN/SYN-ACK/ACK) T7 超时检测 (连接建立超时) 发送 Logon (S1F13) (主动/被动模式发起方) T3 超时检测 (等待回复超时) 接收 Logon Ack (S1F14) (通信能力协商) T5 超时检测 (连接建立总超时) 通信就绪 (可收发数据消息) T6 超时检测 (控制事务超时) T8 超时检测 (网络保活/心跳超时) 定时器作用说明: • T3:等待回复超时(Reply Timeout),用于单条消息的响应等待,默认 45s。 • T5:连接建立总超时(Connect Timeout),从 TCP 连接到 Logon 完成的总时限,默认 10s。 • T6:控制事务超时(Control Transaction Timeout),用于控制类消息(如 S1F13/S1F14)的事务完成时限,默认 5s。 • T7:连接建立超时(TCP Connect Timeout),TCP 三次握手阶段超时,默认 10s。 • T8:网络保活超时(Network Keep-Alive Timeout),无数据活动时发送心跳包检测连接活性,默认 5s。

3.5 五大定时器详解

SECS GEM 标准定义了多个定时器来管理连接生命周期的不同阶段。理解这些定时器的含义和默认值,是诊断连接异常的基础。

3.5.1 T3 — 等待回复超时(Reply Timeout)

  • 作用: 发送方发送一条需要回复的消息(如 S1F13)后,等待接收方回复的最大时间。
  • 默认值: 45 秒(可配置,通常为 10-120 秒)。
  • 超时后果: 发送方认为消息丢失,触发重传或断开连接。
  • 诊断价值: 如果频繁出现 T3 超时,说明网络延迟高、对端处理慢或消息丢失。

3.5.2 T5 — 连接建立总超时(Connect Timeout)

  • 作用: 从 TCP 连接建立开始,到完成 Logon 协商(S1F13/S1F14)的总时间限制。
  • 默认值: 10 秒(可配置)。
  • 超时后果: 设备或主机放弃本次连接尝试,关闭 Socket。
  • 诊断价值: T5 超时通常意味着 Logon 消息交互缓慢或对端无响应,需检查应用层处理逻辑。

3.5.3 T6 — 控制事务超时(Control Transaction Timeout)

  • 作用: 用于控制类事务(如 S1F13/S1F14、S1F1/S1F2)的完成时限,比 T3 更严格。
  • 默认值: 5 秒(可配置)。
  • 超时后果: 控制事务失败,可能导致连接断开。
  • 诊断价值: T6 超时通常指示对端 GEM 协议栈处理控制消息过慢或死锁。

3.5.4 T7 — 连接建立超时(TCP Connect Timeout)

  • 作用: TCP 三次握手阶段的超时时间,即从发送 SYN 到收到 SYN-ACK 的最大等待时间。
  • 默认值: 10 秒(通常由操作系统 TCP 栈控制,可配置)。
  • 超时后果: TCP 连接失败,返回 ETIMEDOUT 错误。
  • 诊断价值: T7 超时几乎总是网络层问题:路由不可达、防火墙丢包、对端主机宕机。

3.5.5 T8 — 网络保活超时(Network Keep-Alive Timeout)

  • 作用: 在连接空闲(无数据收发)时,发送心跳包(S9F9)检测连接是否仍然存活。
  • 默认值: 5 秒(可配置)。
  • 超时后果: 连续多次心跳无响应后,断开 TCP 连接。
  • 诊断价值: T8 超时通常指示网络链路中断或对端进程崩溃,但 TCP 连接尚未被操作系统检测到。

3.6 定时器配置与诊断对照表

定时器 默认值 触发阶段 超时典型原因 诊断命令/方法
T3 45s 消息等待回复 网络延迟、对端处理慢、丢包 tcpdump 抓包分析重传
T5 10s 连接建立总时限 Logon 交互缓慢、对端无响应 检查应用日志 S1F13/S1F14 时序
T6 5s 控制事务 协议栈死锁、处理线程阻塞 检查 GEM 协议栈线程状态
T7 10s TCP 三次握手 路由不可达、防火墙拦截、主机宕机 ping、telnet、ss -t
T8 5s 连接空闲保活 链路中断、对端进程崩溃 tcpdump 观察心跳包 S9F9

3.7 连接建立阶段的异常诊断思路

诊断步骤(按时间顺序):
  1. 检查 T7: 使用 ping 和 telnet <IP> <Port> 确认网络层可达性和端口开放性。如果 T7 超时,问题在 TCP/IP 层。
  2. 检查 T5: 如果 TCP 连接已建立但 Logon 失败,查看设备/主机日志中 S1F13 是否发出、S1F14 是否回复。T5 超时说明应用层协商失败。
  3. 检查 T3/T6: 如果 Logon 成功但后续消息交互异常,关注 T3(普通消息)和 T6(控制消息)的超时记录。抓包分析消息往返时间(RTT)。
  4. 检查 T8: 如果连接在空闲一段时间后断开,查看是否触发了 T8 保活超时。检查心跳包是否正常收发。
重要提示: 不要盲目修改定时器默认值。增大 T3/T5 可能掩盖网络问题,导致故障发现延迟。应先定位根因,再考虑调整定时器作为临时缓解措施。

3.8 连接建立代码示例(主动模式,含定时器配置)

以下是一个简化的 SECS GEM 主动连接建立代码片段,展示了定时器配置和超时处理逻辑:

// 伪代码:SECS GEM 主动连接建立(C 风格)
int secs_gem_connect(const char* host_ip, int port) {
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    struct timeval t7_timeout = {10, 0}; // T7: 10s TCP 连接超时
    setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, &t7_timeout, sizeof(t7_timeout));

    // 发起 TCP 连接(T7 开始计时)
    if (connect(sock, ...) < 0) {
        // T7 超时或连接失败
        log_error("T7 timeout or connection refused");
        close(sock);
        return -1;
    }

    // T5 开始计时(连接建立总时限)
    alarm(10); // 简化示意,实际使用定时器

    // 发送 Logon (S1F13)
    send_secs_message(sock, S1F13);
    
    // 等待 Logon Ack (S1F14),使用 T3 超时
    struct timeval t3_timeout = {45, 0};
    setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, &t3_timeout, sizeof(t3_timeout));
    
    SECSMessage* reply = receive_secs_message(sock);
    if (reply == NULL) {
        // T3 超时
        log_error("T3 timeout waiting for S1F14");
        close(sock);
        return -1;
    }

    // Logon 成功,取消 T5 定时器
    alarm(0);
    
    // 设置 T8 保活(5s 空闲后发送心跳)
    enable_keepalive(sock, 5);
    
    return sock;
}
代码要点:
  • T7 通过 Socket 的 SO_SNDTIMEO 控制 TCP 连接超时。
  • T5 使用 alarm() 或独立定时器线程实现,覆盖整个 Logon 过程。
  • T3 通过 SO_RCVTIMEO 控制单条消息的接收等待时间。
  • T8 通过 Socket 的 SO_KEEPALIVE 选项或应用层心跳实现。

掌握主动/被动连接模式的区别以及 T3/T5/T6/T7/T8 定时器的精确作用,是诊断 SECS GEM 连接异常的第一步。在实际故障排查中,结合抓包工具(如 Wireshark、tcpdump)和 GEM 协议栈日志,可以快速定位是网络层问题还是应用层协商失败。