3. Alarm上报流程：设备端触发Alarm → 发送S5F1 → Host回复S5F2的完整握手流程

Alarm上报是SECS/GEM协议中设备向Host主动报告异常状态的核心机制。当设备检测到硬件故障、工艺参数越限或安全门打开等异常事件时，必须按照标准握手流程完成Alarm上报，确保Host端准确记录并响应。本章详细拆解从设备触发Alarm到Host确认的完整交互过程。

3.1 Alarm上报的触发条件与消息结构

设备端Alarm的触发通常由设备内部的状态机或硬件中断驱动。触发后，设备需要构造一条标准的S5F1消息（Alarm Report Send），该消息包含Alarm的标识符、严重等级以及当前状态。

S5F1消息的SECS-II数据格式如下：

<L 3>          -- 列表长度3
  <U2 123>      -- ALID: Alarm唯一标识符 (0-65535)
  <U1 1>        -- ALCD: Alarm等级 (1=Critical, 2=Major, 3=Minor)
  <BOOLEAN TRUE> -- ALST: Alarm状态 (TRUE=Set, FALSE=Clear)

3.2 完整握手流程步骤

Alarm上报的握手流程遵循“请求-确认”模式，确保消息的可靠传递。以下为设备端触发Alarm到Host回复S5F2的完整步骤：

1. 设备内部检测异常：设备传感器或状态机检测到异常条件（如温度超限、门互锁打开）。
2. 构造S5F1消息：设备根据异常类型填充ALID、ALCD、ALST字段，并将消息放入发送队列。
3. 发送S5F1：设备通过底层TCP/IP或RS-232连接将消息发送至Host。
4. Host接收并解析：Host的SECS/GEM通信层接收S5F1，解析ALID并查找对应的告警配置。
5. Host处理Alarm：Host应用层记录告警、触发UI显示或执行自动响应逻辑。
6. Host回复S5F2：Host构造S5F2消息，包含ACKC6（确认码）字段，返回给设备。
7. 设备接收S5F2：设备检查ACKC6值，确认Host已成功接收Alarm。

3.3 S5F2确认码(ACKC6)详解

Host在S5F2消息中返回的ACKC6字段决定了设备下一步的行为。ACKC6是一个单字节无符号整数，其定义如下：

3.4 Alarm Set与Alarm Clear的区别

Alarm状态（ALST）分为Set和Clear两种，设备在触发和解除Alarm时都需要上报。两者的处理逻辑存在差异：

• Alarm Set (ALST=TRUE)：设备检测到异常首次发生，立即发送S5F1。Host收到后应触发告警通知（如声光报警、E-mail通知）。
• Alarm Clear (ALST=FALSE)：设备检测到异常条件消失（如温度恢复正常），发送S5F1通知Host告警解除。Host收到后应清除告警状态，关闭通知。

设备必须确保Alarm Set和Clear成对出现，避免出现“只Set不Clear”导致Host端告警堆积。

3.5 超时与重试机制

网络抖动或Host繁忙可能导致S5F2丢失。设备端必须实现超时重试逻辑，保证Alarm上报的可靠性。

3.6 常见异常场景与处理策略

在实际部署中，Alarm上报可能遇到多种异常情况。以下列出典型场景及推荐处理策略：

• 场景一：S5F2超时未收到 → 设备重发S5F1，最多3次；若仍失败，将Alarm写入本地非易失存储，待连接恢复后补报。
• 场景二：Host返回ACKC6=1 (ALID未知) → 设备立即停止该ALID的上报，并触发配置同步流程，请求Host下发最新的ALID映射表。
• 场景三：设备与Host连接中断 → 设备缓存所有Alarm事件，连接恢复后按时间戳顺序补报，避免丢失关键告警。
• 场景四：Alarm风暴（短时间内大量Alarm触发） → 设备端实现Alarm去重与限流，相同ALID在1秒内只上报一次，防止消息队列溢出。

3.7 工程最佳实践总结

• ALID管理：在设备固件中固化ALID与告警文本的映射表，并通过S2F43/F44（动态事件配置）与Host同步，避免硬编码。
• 日志记录：每次Alarm上报（包括重试）都记录时间戳、ALID、ALCD、ALST、ACKC6及重试次数，便于事后审计。
• 测试验证：使用SECS/GEM模拟器（如SECSMon或自研工具）模拟Host返回各种ACKC6值，验证设备端的异常处理逻辑是否健壮。
• 性能考量：Alarm上报应使用独立的通信线程或队列，避免阻塞正常的设备状态上报（如S6F11数据收集）。