4. SECS/GEM消息实战

在EAP与设备的实际对接中,真正决定通信能否跑通的,不是抽象概念,而是对SECS-II消息流(Stream/Function)的准确理解与收发顺序。本节围绕最常用的S1、S2、S5、S6、S7系列消息,结合模拟器完成一次完整的设备上线与事件订阅过程,帮助读者建立“消息—状态—数据”的对应关系。

一、先分清五类消息的职责

SECS-II用Stream(S)和Function(F)编号标识消息类型。S1是通信建立与状态确认,S2是设备控制与参数下发,S5是异常报警,S6是事件与数据采集,S7是工艺配方管理。它们在上线流程中承担不同角色:

  • S1系列:S1F1(Are You There)用于探测设备是否在线,S1F2(On Line Data)返回设备型号、软件版本等;S1F13(Establish Communications Request)发起通信建立,S1F14(Establish Communications Acknowledge)返回建立结果,是上线握手的关键。
  • S2系列:S2F41(Host Command)下发远程命令,如START、STOP、PP-SELECT;S2F42返回命令执行结果,用于控制设备动作。
  • S5系列:S5F1(Alarm Report Send)由设备主动上报报警,S5F2确认;S5F3用于报警使能/禁止,决定哪些报警需要上报。
  • S6系列:S6F11(Event Report Send)是设备事件上报的核心,携带事件ID和报告数据;S6F12确认;S6F15/S6F16用于按需请求事件报告。
  • S7系列:S7F1/S7F2用于配方上传下载请求与确认,S7F3/S7F4传输配方内容,S7F5/S7F6请求配方,S7F17/S7F18删除配方。

理解这些消息的关键,是记住“谁主动、谁确认、带什么数据”。S1F13、S2F41、S6F11通常由主机或设备主动发起,对应的F+1为确认消息;S5F1、S6F11由设备主动上报,主机需回确认。

二、用模拟器完成设备上线

以常见的SECS/GEM模拟器(如Cimetrix、SecsSim或开源模拟工具)为例,设备侧配置好IP、端口(通常5000)、Device ID和Active/Passive模式后,主机侧按以下顺序操作:

  1. 主机发送S1F13,携带MDLN(设备型号)和SOFTREV(软件版本)等建立通信请求。
  2. 设备回复S1F14,其中COMMACK=0表示通信建立成功,非0表示失败,需检查端口、Device ID或协议版本。
  3. 通信建立后,主机可发送S1F1探测设备是否在线,设备回S1F2,返回设备状态数据。
  4. 若设备处于Online Remote状态,主机可发送S2F41下发控制命令,设备回S2F42报告命令结果。

模拟器上通常能看到每条消息的收发日志、消息体结构和时间戳。判断上线是否成功,主要看S1F14的COMMACK是否为0,以及后续S1F2是否正常返回。若COMMACK非0,常见原因是Device ID不匹配、端口被占用或T3超时设置过短。

三、事件订阅与S6F11上报

设备上线后,主机需要订阅关心的事件,才能收到S6F11上报。事件订阅通常通过S2F33(Define Report)和S2F35(Link Event Report)完成:S2F33定义报告包含哪些VID(变量ID),S2F35把报告与事件ID绑定。设备侧收到后回S2F34、S2F36确认。

例如,主机希望订阅“工艺完成”事件(CEID=1001),报告RPTID=1包含VID 1001(温度)和VID 1002(压力)。主机先发S2F33定义RPTID=1对应[1001,1002],再发S2F35将CEID=1001链接到RPTID=1。设备确认后,当工艺完成时,设备主动发送S6F11,携带CEID=1001和报告数据,主机回S6F12确认。

报警订阅类似:主机通过S5F3使能需要上报的报警ID,设备在报警发生时发送S5F1,主机回S5F2。若未使能,设备不会主动上报该报警。

模拟器调试时,建议先只订阅一个事件,确认S6F11能正常收到并解析,再逐步增加报告和VID,避免一次配置过多导致排查困难。

四、消息流与状态对应关系

下面这张图把上线与订阅过程中最关键的几条消息按时间顺序串起来,并标出每条消息的方向、携带的关键数据和判断点,便于对照模拟器日志理解。

设备上线与事件订阅消息流(S1/S2/S5/S6) 主机 Host 设备 Equipment S1F13 Establish Communications Request MDLN / SOFTREV S1F14 Establish Communications Acknowledge COMMACK=0 成功 / 非0 失败 S2F33 Define Report RPTID=1 → VID[1001,1002] S2F34 Define Report Acknowledge DRACK=0 成功 S2F35 Link Event Report CEID=1001 → RPTID=1 S2F36 Link Event Report Acknowledge LRACK=0 成功 S6F11 Event Report Send CEID=1001 + 报告数据(温度/压力) S6F12 Event Report Acknowledge

图中蓝色箭头表示主机发往设备,红色箭头表示设备回主机,紫色箭头表示设备主动上报。可以看到,上线阶段的核心是S1F13/S1F14握手,订阅阶段的核心是S2F33/S2F35定义与链接,运行阶段的核心是S6F11上报。S5F1报警上报与S6F11类似,只是触发条件不同。

五、实操中容易踩的坑

第一,S1F14的COMMACK非0时,不要急着改代码,先核对Device ID和端口是否与设备配置一致。第二,S2F33定义报告时,VID必须在设备侧已定义,否则DRACK会返回非0。第三,S2F35链接事件时,CEID和RPTID都必须已存在,否则LRACK报错。第四,S6F11上报的数据顺序必须与S2F33中定义的VID顺序一致,否则解析会错位。第五,T3超时(通常45秒)内未收到回复,主机会重发,若设备未响应,需检查通信链路或设备状态。

模拟器上调试通过不代表现场一定通过。现场还需确认设备是否处于Online Remote、报警是否使能、事件是否已链接,以及网络是否稳定。建议把S1F14、S2F34、S2F36、S6F11的日志作为上线检查的关键证据。