2. SECS GEM Alarm模型:S5F1/S5F2消息格式解析、Alarm ID与Alarm Text的映射关系
在SECS/GEM协议体系中,Alarm(报警)是设备向主机报告异常状态的核心机制。本章深入解析Alarm模型的数据结构,重点拆解S5F1(报警发送)与S5F2(报警确认/查询回复)的消息格式,并建立Alarm ID与Alarm Text之间的标准映射关系。
2.1 Alarm模型概述
GEM标准定义的Alarm模型包含三个核心要素:Alarm ID(报警编号)、Alarm Text(报警描述文本)和Alarm Status(报警状态)。设备通过S5F1消息主动上报报警,主机通过S5F2消息进行确认或查询当前报警列表。
关键概念: Alarm ID是设备定义的唯一数字标识(通常为1~65535),Alarm Text是与之对应的可读字符串。两者在设备端必须保持一一映射,主机端通过解析S5F1/S5F2消息获取该映射关系。
2.2 S5F1消息格式解析
S5F1是设备向主机发送报警的主动消息,其消息结构遵循SECS-II数据格式。标准S5F1消息体包含一个List,内部嵌套多个报警数据项。
2.2.1 消息结构定义
| 层级 | SECS-II格式 | 描述 | 示例值 |
|---|---|---|---|
| L, n | List | 报警列表,n为报警数量 | L, 2 |
| ├─ L, 3 | List | 单个报警数据块 | L, 3 |
| │ ├─ ALID | U2 / U4 | Alarm ID,无符号整数 | 101 |
| │ ├─ ALST | B[1] | Alarm Status:0=清除,1=设置 | 1 |
| │ └─ ALTX | A | Alarm Text,ASCII字符串 | "Chamber Temp High" |
| └─ L, 3 | List | 第二个报警数据块 | L, 3 |
工程要点: ALID字段通常使用U2(2字节无符号整数),取值范围1~65535。ALST字段为单字节布尔值,0表示报警已清除,1表示报警激活。ALTX字段长度建议不超过120字节,避免消息超长。
2.2.2 完整消息示例
以下是一个包含两个报警的S5F1消息体二进制表示(SECS-II编码):
// S5F1 消息体示例(包含2个报警)
L, 2
L, 3
U2: 101 // ALID: 报警ID 101
B: 0x01 // ALST: 报警设置 (1)
A: "Chamber Temp High" // ALTX
L, 3
U2: 202 // ALID: 报警ID 202
B: 0x00 // ALST: 报警清除 (0)
A: "Coolant Flow Low" // ALTX
2.3 S5F2消息格式解析
S5F2是主机对S5F1的响应消息,也可用于主机主动查询设备当前报警状态。S5F2的消息体结构与S5F1完全一致,但语义不同:S5F2用于确认收到报警或返回查询结果。
2.3.1 消息结构对比
| 消息 | 方向 | 功能 | 消息体结构 |
|---|---|---|---|
| S5F1 | 设备 → 主机 | 主动上报报警设置/清除 | L, n [L, 3 (ALID, ALST, ALTX)] |
| S5F2 | 主机 → 设备 | 确认S5F1或查询报警列表 | L, n [L, 3 (ALID, ALST, ALTX)] |
常见误区: S5F2并非简单的“收到确认”。当主机发送S5F2时,如果消息体为空(L, 0),表示主机请求设备返回当前所有报警状态;如果消息体包含具体报警ID,则主机查询指定报警的状态。设备收到后应回复S5F2(包含查询结果)。
2.3.2 典型交互流程
- 报警上报流程: 设备检测到异常 → 发送S5F1(ALID=101, ALST=1, ALTX="Chamber Temp High")→ 主机回复S5F2(相同内容,表示确认)
- 报警查询流程: 主机发送S5F2(L, 0)→ 设备回复S5F2(包含当前所有激活报警列表)
- 报警清除流程: 设备检测到异常恢复 → 发送S5F1(ALID=101, ALST=0, ALTX="Chamber Temp High")→ 主机回复S5F2确认
2.4 Alarm ID与Alarm Text的映射关系
Alarm ID与Alarm Text的映射是设备固件中预定义的静态关系表。主机在通信建立阶段(通常通过S1F3/S1F4查询设备属性)或首次收到S5F1时,逐步构建本地的映射缓存。
2.4.1 映射表设计原则
- 唯一性: 每个Alarm ID在设备内必须唯一,不可重复定义。
- 稳定性: 映射关系在设备生命周期内不应变更,固件升级时需保持向后兼容。
- 可读性: Alarm Text应使用英文或数字字符,避免特殊符号导致解析异常。
- 长度限制: 建议Alarm Text不超过120字节,确保单条消息可完整传输。
2.4.2 典型映射表示例
| Alarm ID | Alarm Text | 严重级别 | 可能原因 |
|---|---|---|---|
| 101 | Chamber Temp High | Critical | 加热器失控、冷却失效 |
| 102 | Chamber Temp Low | Warning | 加热器故障、传感器偏差 |
| 201 | Vacuum Pressure Out of Range | Critical | 真空泵故障、密封泄漏 |
| 301 | Door Interlock Open | Error | 安全门未关闭 |
| 401 | Material Load Fail | Warning | 晶圆装载位置偏移 |
2.4.3 主机端映射缓存策略
主机在收到S5F1时,应执行以下映射处理逻辑:
// 伪代码:主机端Alarm映射缓存处理
Map<Integer, String> alarmMap = new HashMap<>();
void onS5F1Received(S5F1Message msg) {
for (AlarmData alarm : msg.getAlarmList()) {
int alid = alarm.getAlid();
String altx = alarm.getAltx();
// 更新本地映射缓存
alarmMap.put(alid, altx);
// 根据ALST判断报警状态
if (alarm.getAlst() == 1) {
// 报警设置:触发告警逻辑
triggerAlarm(alid, altx);
} else {
// 报警清除:清除告警状态
clearAlarm(alid);
}
}
}
工程实践建议: 主机端应维护一个持久化的Alarm映射表(如配置文件或数据库),避免每次重启后重新学习。同时,设备端在S5F1中携带ALTX字段,即使主机映射表缺失,也能通过消息内容直接获取报警描述,增强容错性。
2.5 异常场景处理
在实际工程中,Alarm消息处理可能遇到以下异常情况,需要提前设计应对策略:
| 异常场景 | 现象 | 推荐处理方式 |
|---|---|---|
| Alarm ID重复 | 设备发送相同ALID但不同ALTX | 以最新收到的ALTX为准,记录日志告警 |
| ALTX为空 | 消息中ALTX字段长度为0 | 使用默认文本 "Alarm #" + ALID 替代 |
| ALST值异常 | ALST不为0或1 | 视为无效消息,丢弃并记录错误日志 |
| S5F2超时 | 设备发送S5F1后未收到S5F2 | 设备重发S5F1(最多3次),间隔5秒 |
| 映射表冲突 | 同一ALID对应多个ALTX | 以设备固件版本为准,主机端告警人工介入 |
避坑指南: 某些设备在报警清除时,ALTX字段可能为空字符串或填充空格。主机端解析时应做trim()处理,避免将空格视为有效文本。同时,建议设备端在清除报警时仍然携带完整的ALTX,保持消息一致性。
2.6 本章小结
本章详细解析了SECS GEM Alarm模型的核心数据结构:
- S5F1 是设备主动上报报警的消息,包含ALID、ALST、ALTX三个关键字段。
- S5F2 是主机确认或查询报警的响应消息,结构与S5F1一致。
- Alarm ID与Alarm Text 的映射关系是设备固件预定义的静态表,主机端需建立缓存机制。
- 异常场景处理策略是工程落地的关键保障,需在协议栈实现中提前考虑。
下一阶段准备: 掌握Alarm消息格式后,第3章将深入S6F11/F12(Trace数据采集)的消息结构,进一步扩展SECS/GEM的工程应用能力。