📚 课程目录第2章 EAP通信协议基础

2. EAP通信协议基础

在半导体与泛半导体制造场景中，EAP（Equipment Automation Program）要完成配方下发、批次放行、状态采集、报警上报、远程控制等任务，必须依赖一套设备与主机之间稳定、可解析、可追溯的通信协议。这套协议的核心就是 SECS/GEM 体系，而 HSMS 与 TCP/IP 则负责把它承载到现代以太网环境中。理解三者的分工，是后续日志分析与故障诊断的基础。

一、三层分工：语义、会话与传输

可以把设备通信理解为三层协作：SECS 定义消息的语义与格式，HSMS 定义消息在 TCP 连接上的会话与事务规则，TCP/IP 提供可靠的字节流传输。设备日志中看到的每一条报文，实际上都同时携带这三层信息。

SECS 分为两部分：SECS-I 定义消息结构，SECS-II 定义消息内容。SECS-II 消息由 Stream 和 Function 组成，写作 SxFy，例如 S1F13 表示“建立通信请求”，S2F41 表示“远程命令”，S6F11 表示“事件报告”。消息体由数据项（Data Item）构成，常见类型包括 L（列表）、A（ASCII）、U4（4 字节无符号整数）、BOOLEAN 等。日志中若出现 L,3 A "EQP01" U4 1001 BOOLEAN T，就表示一个含三个元素的列表。

HSMS 则解决“消息怎么在 TCP 上可靠地一问一答”。它定义了会话状态、事务标识、超时与重传。每条 HSMS 消息都有 SessionID、SystemBytes、PType、SType 等字段。其中 SystemBytes 是事务匹配的关键：主机发出请求时分配一个值，设备回复时必须原样带回，EAP 才能把回复与请求对应起来。若日志中出现“回复的 SystemBytes 与请求不一致”，通常意味着设备端事务管理异常或存在重复消息。

二、消息类型：数据消息与控制消息

HSMS 消息分为两大类。第一类是数据消息，其 SType=0，承载真正的 SECS-II 内容，如 S1F13、S2F41、S6F11。第二类是控制消息，不携带 SECS-II 数据，用于管理链路本身，常见的有：

Select.req（SType=1）：请求建立 HSMS 会话；
Deselect.req（SType=2）：请求断开会话；
Linktest.req（SType=5）：链路心跳检测；
Separate.req（SType=9）：异常或主动断开通知。

在日志分析中，控制消息往往比数据消息更能说明“链路是否健康”。例如设备每隔 30 秒发送一次 Linktest.req，若主机连续多次未回 Linktest.rsp，则链路可能已半开，此时即使 TCP 连接仍显示 ESTABLISHED，业务消息也无法送达。

判断链路是否真正可用，不能只看 TCP 连接状态，还要看 HSMS 的 Select 是否成功、Linktest 是否持续得到响应。

三、事务流程：一次远程命令的完整生命周期

以主机向设备下发远程命令 S2F41 为例，一次典型事务包含以下阶段：主机先确保 HSMS 处于 Selected 状态；然后构造 S2F41，分配 SystemBytes=0x00001234，通过 TCP 发送；设备收到后执行命令，并回复 S2F42，其中 SystemBytes 必须仍为 0x00001234；主机收到回复后，根据 S2F42 中的 HCACK 判断命令是否被接受，例如 0 表示成功，1 表示命令不存在，2 表示参数错误。若主机在超时时间内未收到回复，则触发重试或报错。

下面这张图展示了从 TCP 连接到 SECS-II 事务完成的完整信号链，重点标出了 HSMS 控制消息与数据消息的交替关系，以及 SystemBytes 在请求与回复之间的匹配作用。

四、日志中如何识别与判断

在 EAP 日志中，一条典型的 HSMS 报文可能长这样：

[2024-06-11 10:23:41.512] HSMS <-- S2F41 W SystemBytes=0x00001234
  L,2
    A "START"
    L,1
      A "LOT001"
[2024-06-11 10:23:41.678] HSMS --> S2F42 W SystemBytes=0x00001234
  L,2
    B 0x00
    L,0

分析时可按以下顺序判断：先看 TCP 是否连接、端口是否为设备配置的 HSMS 端口；再看 HSMS 是否处于 Selected 状态；然后核对 SystemBytes 是否成对出现；最后解析 SECS-II 内容，确认 HCACK 或 ACKC6 等返回码。若请求有发出但无回复，优先怀疑设备端事务处理阻塞或链路半开；若回复的 SystemBytes 不匹配，则可能是设备端事务表错乱或存在重复发送。

不要把 TCP 连接成功等同于通信正常。HSMS 的 Select 失败、Linktest 无响应、SystemBytes 不匹配，都会导致业务消息无法完成，而 TCP 层可能仍显示连接正常。

五、GEM 在其中的角色

GEM 建立在 SECS-II 之上，规定了设备应支持哪些标准消息、状态模型、报警模型、事件报告和变量采集方式。例如设备通过 S6F11 主动上报事件，主机通过 S1F3 查询状态变量，通过 S2F33 建立报告定义。EAP 日志分析时，若发现 S6F11 频繁上报但主机未正确关联到对应 CEID，问题往往不在 TCP 或 HSMS，而在 GEM 层的事件配置与报告映射。

因此，排查通信故障时应遵循“自下而上”的顺序：先确认 TCP 可达，再确认 HSMS 会话已 Selected 且心跳正常，然后检查 SECS-II 消息的 Stream/Function 与 SystemBytes 匹配，最后核对 GEM 层的事件、报告与变量定义。只有把三层分开看，才能从日志中快速定位问题究竟出在传输、会话还是语义层。