2. SECS/GEM协议基础回顾

在进入配方上传下载与版本管理之前，需要把 SECS/GEM 的底层通信模型重新梳理一遍。配方管理本质上是“用消息把文件内容从一端搬到另一端，并让两端对版本达成一致”，因此对 SECS-II 消息结构、HSMS 连接状态、常用 Stream/Function 以及事务超时机制的理解，直接决定了后续实现能否稳定运行。

SECS-II 消息结构

SECS-II 消息是设备与主机之间交换数据的基本单元。一条消息由消息头（Header）和消息体（Body）组成。消息头固定 10 字节，包含：

• Device ID（2 字节）：标识设备，主机侧通常为 0xFFFF。
• Stream/Function（各 1 字节）：如 S7F19 表示 Stream 7、Function 19。
• W-Bit（Wait Bit）：置 1 表示需要对方回复，置 0 表示单向通知。
• System Bytes（4 字节）：事务标识，用于把请求与回复配对。

消息体由若干数据项（Data Item）组成，每个数据项以格式字节开头，格式字节高 6 位表示格式码，低 2 位表示长度字节数。常见格式码包括：

例如，一条 S7F19 请求“查询配方列表”的消息体通常是一个空列表 L,0；而回复 S7F20 的消息体是 L,n，其中每个元素是一个 A 类型字符串，表示配方名。理解格式码与长度字节的对应关系，是解析配方消息的前提。

HSMS 连接管理

HSMS（High-Speed SECS Message Services）是当前主流的传输层协议，基于 TCP/IP。它定义了连接状态机，核心状态包括：

• NOT-CONNECTED：未建立 TCP 连接。
• CONNECTED：TCP 已连接，但尚未完成 HSMS 选择。
• SELECTED：通过 Select.req/Select.rsp 完成角色协商，可以收发数据消息。

连接建立后，双方通过 Linktest.req/rsp 维持心跳，检测链路是否存活。若在 T7 时间内未收到 Linktest 回复，则判定链路异常并断开重连。对于配方传输，必须确保连接处于 SELECTED 状态，否则 S7F3/S7F5 等消息无法送达。

常用 Stream/Function

配方管理涉及的消息主要集中在 S7 和 S2：

其中 S7F3 的消息体通常为 L,3：<PPID>、<PPBODY>、<PPARM>，分别表示配方 ID、配方正文和参数列表。PPBODY 是 A 类型或 B 类型，长度可达数 MB，因此实际传输时需要关注消息分片与超时设置。

事务与超时机制

SECS 采用“请求-回复”事务模型。发送方发出 W-Bit=1 的消息后，启动 T3 定时器等待回复。若 T3 超时，则重发或报错。接收方收到消息后，需在 T2 时间内发出回复。此外还有：

• T3：回复超时，默认 45 秒，配方大文件传输时需适当增大。
• T5：连接分离超时，默认 10 秒。
• T6：控制事务超时，默认 5 秒。
• T7：NOT-SELECTED 状态超时，默认 10 秒。
• T8：网络字符间超时，默认 5 秒。

System Bytes 是事务配对的唯一依据。同一时刻可以存在多个未完成事务，但每个事务的 System Bytes 必须不同。配方上传时，若 PPBODY 较大，建议将 T3 设置为 120 秒以上，并配合分片传输策略。

配方管理相关消息概览

从工程视角看，配方管理消息可分为四类：查询类（S7F19）、上传类（S7F3、S7F5）、删除类（S7F17）、通知类（S7F23）。每类消息的回复都携带 ACK 或 NAK 状态，用于判断操作是否成功。例如 S7F4 回复中若包含 ACKC7 表示上传成功，NAKC7 表示失败。理解这些状态码，是后续实现版本比对与回滚的基础。

把上述结构串起来看：主机在 SELECTED 状态下发出 S7F3，携带 PPID 与 PPBODY，设备在 T3 内回复 S7F4 并给出 ACKC7；若 PPBODY 较大，则需在 T3 内完成分片与重组。版本管理正是建立在这条消息链路之上——通过 S7F19 获取当前配方列表，通过 S7F5/S7F6 拉取设备侧配方正文，再与主机侧版本比对，最终用 S7F3 下发新版本或用 S2F41 触发切换。理解这些基础机制，后续的版本比对、回滚与审计才有可靠的落点。