4、S1F1与S1F2消息：Are You There请求与响应、设备ID与状态报告

4.1 消息概述：通信的“心跳”与“握手”

S1F1（Are You There, R）与 S1F2（Are You There, D）是 SECS/GEM 协议中最基础、最核心的一对握手消息。它们用于验证主机（Host）与设备（Equipment）之间的通信链路是否正常，以及设备是否处于可响应状态。任何一次完整的会话建立或通信恢复，几乎都以 S1F1/S1F2 交换作为起点。

4.2 消息结构详解

4.2.1 S1F1：Are You There 请求（Primary Message）

S1F1 由主机（Host）主动发起，询问设备是否在线。其消息结构极为简单，通常只包含一个空的 L（List）或一个 B（Boolean）数据项，但在标准实现中，S1F1 的 Stream 1, Function 1 固定为 W（Wait Bit = 1），表示需要设备回复。

4.2.2 S1F2：Are You There 响应（Secondary Message）

设备收到 S1F1 后，必须回复 S1F2。S1F2 不仅确认“在线”，还携带了设备的 MDLN（Model Number） 和 SOFTREV（Software Revision） 两个关键状态参数，用于主机识别设备型号与固件版本。

4.3 设备 ID（Device ID）在消息中的作用

在 SECS/GEM 协议中，Device ID 是每条消息头部的固定字段，用于标识消息的目标设备。对于 S1F1/S1F2 消息，Device ID 的取值决定了消息的寻址范围：

• Device ID = 0：广播或默认设备，通常用于单设备连接场景。
• Device ID > 0：多设备共享同一物理链路时，用于区分不同设备。

4.4 状态报告：MDLN 与 SOFTREV 的工程意义

S1F2 返回的 MDLN 和 SOFTREV 不仅仅是标识信息，更是设备状态管理的基础：

4.5 消息交互流程与状态机

下图展示了 S1F1/S1F2 在设备状态机中的典型交互流程，以及 Device ID 的传递路径：

4.6 日志解析实战：S1F1/S1F2 报文示例

以下是一段真实的 SECS-II 日志片段，展示了 S1F1 请求与 S1F2 响应的原始报文格式：

# 主机发送 S1F1 (Are You There Request)
S1F1 W
<L></L>
.
# 设备回复 S1F2 (Are You There Response)
S1F2
<L>
  <A>ETCH-3000</A>   <!-- MDLN -->
  <A>V2.1.3</A>      <!-- SOFTREV -->
</L>
.

4.7 工程案例：联调中的 S1F1 超时处理

在某次 300mm 晶圆设备的联调中，主机连续发送 3 次 S1F1 均未收到 S1F2 响应。日志分析发现：

• 物理层 TCP 连接正常（三次握手成功）。
• 设备端 SECS 驱动未启动，导致消息队列阻塞。
• 主机侧超时时间设置为 10 秒，3 次重试后标记设备为“离线”。

解决方案：在设备端增加 SECS 驱动启动后的 “就绪通知” 机制，确保设备在进入 ONLINE 状态前主动发送 S1F2 或 S1F14（Establish Communications Request）。

4.8 本章小结