4. Alarm 列表管理：S5F3 / S5F4 消息详解

在 SECS/GEM 异常处理体系中，Alarm 列表管理是设备与主机之间同步报警状态的核心机制。当设备内部发生报警条件变化（如温度超限、气压不足、门锁打开）时，主机需要及时获取当前所有处于激活状态的 Alarm 列表，以便进行集中监控、日志记录和决策调度。S5F3（请求当前 Alarm 列表）与 S5F4（返回 Alarm 列表数据）正是为此场景设计的标准消息对。

4.1 消息结构定义

S5F3 消息体极为简洁，仅包含一个 DATAID（数据 ID）字段，用于标识请求的上下文。S5F4 则返回一个包含多个 Alarm 条目的列表，每个条目由 ALID（报警 ID）、ALCD（报警代码）和 ALTX（报警文本）组成。

4.2 消息交互流程

下图展示了主机通过 S5F3/S5F4 获取 Alarm 列表的完整交互过程，包括正常响应和超时重试机制。

4.3 数据模型与编码示例

设备内部维护一张 Alarm 状态表，用于记录所有已定义 Alarm 的当前状态。当 S5F3 请求到达时，设备遍历该表，筛选出状态为“激活”的条目，组装成 S5F4 响应消息。

以下是一个典型的 S5F4 消息编码示例（使用 SECS-II 格式）：

S5F4 W
  <B 0x01>          // DATAID = 1
  <L 3>             // 列表包含 3 个 Alarm 条目
    <L 3>           // 第 1 个 Alarm
      <U4 101>      // ALID = 101
      <A "02">      // ALCD = 设备报警
      <A "Chamber Temp High">  // ALTX
    <L 3>           // 第 2 个 Alarm
      <U4 102>      // ALID = 102
      <A "01">      // ALCD = 个人安全报警
      <A "Door Interlock Open">
    <L 3>           // 第 3 个 Alarm
      <U4 104>      // ALID = 104
      <A "02">
      <A "Robot Timeout">

4.4 工程实现要点

在半导体设备软件中实现 S5F3/S5F4 处理时，以下架构设计原则可显著提升系统的健壮性和可维护性：

• Alarm 状态表独立管理： 使用独立的数据结构（如哈希表或有序数组）维护所有 Alarm 的当前状态，与 S5F1/S5F2 的单条上报共享同一数据源，确保状态一致性。
• 响应生成性能优化： 当 Alarm 数量较大（如超过 100 个）时，S5F4 的序列化可能占用较多 CPU 时间。建议在 Alarm 状态变更时预计算序列化缓冲区，或使用增量更新策略。
• T3 超时处理： 主机端在发送 S5F3 后必须启动 T3 计时器（通常 45 秒）。若超时未收到 S5F4，应重试请求并记录通信异常日志，避免无限等待。
• 并发安全： Alarm 状态表可能被多个线程（如硬件中断处理线程、通信线程）同时访问。必须使用互斥锁或读写锁保护，防止 S5F4 生成过程中状态表被修改导致数据不一致。

4.5 异常场景处理

下表列出了 S5F3/S5F4 交互过程中可能出现的异常场景及推荐处理策略：

4.6 架构设计建议

从软件架构角度，推荐将 Alarm 列表管理设计为独立的 Alarm Manager 模块，与通信层、硬件抽象层解耦。下图展示了推荐的模块划分与数据流关系：

该架构的核心优势在于：

• 关注点分离： 通信层只负责消息编解码，不关心 Alarm 业务逻辑；Alarm Manager 专注于状态管理和查询；硬件抽象层屏蔽底层差异。
• 可测试性： 每个模块可独立进行单元测试，Alarm Manager 可通过模拟状态表验证 S5F4 生成逻辑的正确性。
• 可扩展性： 新增报警类型或修改报警处理策略时，只需修改 Alarm Manager 内部逻辑，不影响通信层和硬件层。