4. 配方上传流程设计（上）：上传触发条件、S7F1/S7F3 消息结构解析、数据格式（PPBody）
配方上传是 SECS/GEM 通信中最重要的数据交换场景之一。设备端将当前使用的工艺配方（Process Program）上传至主机端，用于配方管理、工艺追溯或批量复制。本章聚焦上传流程的触发机制、核心消息结构以及配方体（PPBody）的编码规范。
4.1 上传触发条件
配方上传并非由设备主动发起，而是由主机（Host）通过特定消息请求触发。根据 SEMI E5 标准，上传触发分为以下三种典型场景：
| 触发场景 | 主机动作 | 设备响应 | 典型消息流 |
|---|---|---|---|
| 单配方查询 | 发送 S7F1（PPID 请求） | 返回 S7F2（PPBody） | S7F1 → S7F2 |
| 配方列表查询 | 发送 S7F3（PPID 列表请求） | 返回 S7F4（PPBody 列表） | S7F3 → S7F4 |
| 主动上报（较少用） | 设备通过 S6F11 上报配方变更 | 主机可随后发起 S7F1 获取完整数据 | S6F11 → S6F12 → S7F1 → S7F2 |
工程提示： 实际产线中，单配方查询（S7F1/S7F2）是最常用的上传模式。主机在配方比对、工艺恢复或设备初始化阶段频繁调用此流程。配方列表查询（S7F3/S7F4）多用于主机首次连接设备时同步全部配方清单。
4.2 S7F1 消息结构解析
S7F1 是主机向设备请求单个配方的标准消息。其消息结构遵循 SECS-II 的 L（List）嵌套规则，格式固定：
S7F1 (Request PPID)
<L [1]
<A [PPID]>
>| 层级 | 数据类型 | 长度 | 说明 |
|---|---|---|---|
| L[1] | List | 1 个元素 | 最外层列表，固定包含 1 个元素 |
| A[PPID] | ASCII | ≤ 40 字节 | 配方 ID，例如 "RECIPE_001" |
关键约束： PPID 必须与设备内部存储的配方名称完全一致（区分大小写）。主机发送不存在的 PPID 时，设备应返回 S7F2 并携带
DATAID = 0 或错误代码。
4.3 S7F3 消息结构解析
S7F3 用于主机请求多个配方，消息体是一个 PPID 列表：
S7F3 (Request PPID List)
<L [n]
<A [PPID_1]>
<A [PPID_2]>
...
<A [PPID_n]>
>| 参数 | 说明 | 限制 |
|---|---|---|
| n | 请求的配方数量 | 1 ≤ n ≤ 255（受 S7F3 消息长度限制） |
| PPID_i | 第 i 个配方 ID | 每个 PPID 长度 ≤ 40 字节 |
异常场景： 当主机请求的 PPID 列表中包含设备不存在的配方时，设备应在 S7F4 响应中对应位置填充空数据（
<L[0]>），而非中断整个上传流程。这是 SEMI E5 标准推荐的“部分失败”处理策略。
4.4 数据格式：PPBody 结构详解
PPBody 是配方上传的核心数据载体，其格式由设备制造商定义，但必须遵循 SECS-II 的数据类型规范。PPBody 本质上是一个 二进制或 ASCII 编码的数据块，封装在 S7F2 或 S7F4 的消息体中。
4.4.1 PPBody 的通用结构
S7F2 (PPBody Response)
<L [2]
<A [PPID]>
<B [PPBody]>
>| 字段 | 数据类型 | 说明 |
|---|---|---|
| PPID | ASCII | 配方 ID，与请求中的 PPID 一致 |
| PPBody | Binary (B) | 配方数据体，长度由设备定义 |
4.4.2 PPBody 内部编码方式
PPBody 的编码方式因设备类型和工艺复杂度而异，常见以下三种：
| 编码类型 | 适用场景 | 示例 | 解析难度 |
|---|---|---|---|
| 纯文本 (ASCII) | 简单参数配方（如温度、压力设定值） | TEMP=150.0\nPRES=2.5\n |
低 |
| 结构化二进制 | 复杂工艺步骤（如刻蚀、沉积） | 固定偏移 + 字段长度 + 校验和 | 高 |
| SECS-II 嵌套 | 需要与主机深度交互的配方 | <L[3]><A[STEP]><F4[VAL]> |
中 |
工程建议： 推荐使用 结构化二进制 格式，因为它兼具紧凑性和可扩展性。在 PPBody 头部预留 4 字节的版本号和 2 字节的校验和字段，便于后续版本升级和数据完整性校验。
4.5 上传流程状态图
下图展示了从主机发起 S7F1 请求到设备返回 S7F2 的完整状态流转，包含正常路径和异常处理分支：
4.6 上传流程中的关键设计考量
- 超时管理： 主机发送 S7F1 后，应设置 T3 超时（典型值 45 秒）。设备在超时前未响应，主机应重试或标记设备通信异常。
- 数据完整性： PPBody 建议包含 CRC32 或 MD5 校验值，主机在接收后应校验，防止传输过程中数据损坏。
- 大配方分片： 当 PPBody 长度超过 4KB 时，建议使用 S7F31/S7F32（大消息传输）进行分片上传，避免单帧溢出。
- 并发控制： 设备在处理 S7F1 时，应锁定对应配方，防止同时被修改或删除，保证数据一致性。
最佳实践： 在设备端实现配方上传时，建议将 PPBody 的编码与设备内部配方存储格式解耦。内部使用结构化数据库存储，上传时动态生成 SECS-II 兼容的二进制流，这样既能保持内部灵活性，又能满足主机通信标准。