简介SECS-GEM规格书SECS版本以Word文档形式整理面向半导体设备工程师、自动化软件开发者及工厂集成人员用于快速掌握设备与主机间标准通讯协议。文档围绕GEM适应性展开系统梳理状态模型、设备处理状态、主机发起场景、事件通知、在线识别、动态事件报告配置、变量与状态数据采集、报警管理、远程控制等核心模块并结合消息摘要、TCP/IP通讯协议、变量与命令实现、消息类型实现等章节帮助读者建立SECS/GEM完整知识框架支撑实际项目中的设备联调、功能开发与异常排查。压缩包内仅含1个doc文件大小约514KB章节划分明确便于按需查阅。目前已有1251人学习下载适合需要接触半导体设备自动化通讯协议的工程人员作为入门指引或规范速查手册使用。1. SECS-GEM规格书 SECS版本设备端与主机端都绕不过的那道协议门上个月在封测厂帮朋友查设备联调设备商的软件交付了MES侧照着一个老项目的代码改了三天结果一拉日志S1F3 能收到回复S1F14 之后直接掉线。我翻出通信记录一看问题出在“系统字节没有原样带回”这种规格书里写得清清楚楚的细节上。这种情况我遇到不止一次多数人都是先把协议跑通翻车了才回头去翻《SECS-GEM规格书 SECS版本.doc》。这份规格书把 SECS-I、SECS-II、HSMS、GEM 四块内容捆在一起对设备开发、MES 集成、中间件维护的工程师来说等于把“设备怎么开口、MES 怎么接话”的标准答案提前摆在你桌上。它解决的是联调现场最耗时的那类问题报文格式对不上、链路反复断、CEID 事件编号各说各话。适合搞设备软件、搞工厂自动化、写通信中间件的人新手能当敲门砖老手能当查错字典。2. 拆开 SECS 和 HSMS传输层与消息层的分工比你想的重要2.1 先分清 SECS-I 和 HSMS联调现场第一步是选对传输层很多现场工程师把“SECS”和“HSMS”混成一个词真到配置界面就卡住。SECS-I 是串口时代的产物基于 RS-232/RS-422消息按块传输一块最多 2KB适合老式单机设备HSMS 是基于 TCP/IP 的新一代传输端口传统上走 5000消息长度用 4 个字节前置定义数据量能上大很多。选型原则不复杂设备端支持 HSMS 就优先用 HSMS不要图省事去走串口转换。现在新出厂的半导体设备基本默认开 HSMS有些设备厂甚至只留 TCP 口串口连上去也没响应。判断方法很简单打开设备的 Service 菜单看有没有“Host Port”或“SECS Comm”相关选项里面若出现端口号就是 HSMS 无疑。维度SECS-IHSMS物理层RS-232 / RS-422 串口TCP/IP 以太网常用端口无直接连串口默认 5000单块消息上限2KB超出要分块消息长度字段用 4 字节上限宽松得多连接管理物理链路通即可需要 select.req/select.rsp 建立会话适用设备老款、单机、无网卡设备当前大部分新设备、需对接 MES 的设备真机上我遇到过一台老款固晶机只支持 SECS-I主机端非要走 HSMS最后加了一个串口服务器才把事情办了。反过来也一样有些一体化设备模块默认 HSMS 但防火墙没开放 5000TCP 连不上。联调前先搞清楚双方各自能跑哪一层能省掉半天无谓的排查时间。2.2 SECS-II 消息结构从 SxFy 到头部字段的直读法SECS-II 是“消息内容”的规范。所有 SECS-I 和 HSMS 传输的数据载荷部分都用 SECS-II 来定义。每条消息有一个编号写成 SxFy 的形式S 是 Stream 流号F 是 Function 功能号。比如 S1F13 表示“建立通信请求”S1F14 是它的应答S2F41 是“远程命令请求”。消息头总计 10 个字节打开规格书里“消息格式”那一节主要看这几个字段字段位置相对头部作用联调时的注意点设备 ID第 0-1 字节标识主机或设备大部分单设备场景用 0两台设备共用一条线时要区分W bit设备 ID 最高位0 表示单向消息1 表示需要回复发请求消息时清掉 W bit主机就不等你回应流/功能号第 2 字节高 4 位流低 4 位功能对应 SxFy 编号消息编号靠这字节定位抓包先看它系统字节第 6-9 字节请求与响应的对应关系必须原样返回这是最容易踩坑的地方这里给一段按字节拆解头部的 Python 代码我在写解析工具时就是这么处理的直接对应规格书里的头部定义import struct def parse_secs2_header(h): h 是从消息缓冲区里截出来的 10 字节 SECS-II 头。 返回 (设备ID, Wbit, Stream, Function, SystemBytes) if len(h) 10: raise ValueError(SECS-II header must be 10 bytes) # 第0字节高1位是W bit低7位是设备ID高7位第1字节是设备ID低8位 wbit (h[0] 7) 0x01 device_id ((h[0] 0x7F) 8) | h[1] # 第2字节高4位是Stream低4位是Function stream (h[2] 4) 0x0F function h[2] 0x0F # 第6-9字节是系统字节请求和响应必须一致 sys_bytes int.from_bytes(h[6:10], byteorderbig) return device_id, wbit, stream, function, sys_bytes这段代码的关键在最后两行规格书里明确要求响应消息把请求消息的系统字节照搬回来很多底层库并不会帮你校验这个得自己在协议层盯。如果 W bit 为 1 而你发了消息后没收到回复第一个要查的就是对端的系统字节是否有跟你消息里一致的值。另外注意字节序标准里系统字节是大端别用本地小端直接读否则数值会倒过来比较。2.3 GEM 把设备“行为”管了起来GEM 是 SEMI E30 里定义的设备模型我把它理解成“设备怎么表现才算合格”。SECS-II 只规定消息格式GEM 规定设备在什么状态做什么事上电后要先做自检自检完进入通信建立再切到空闲随后才能收远程命令。这个状态迁移过程是设备厂家软件和 MES 侧都必须遵守的共同规则。GEM 覆盖五件事状态模型、在线/离线控制、事件报告、报警管理、远程命令与数据收集。联调时很多“设备没反应”的问题其实不是消息格式错而是设备当前状态不允许做这个动作。比如设备还在 DEVICE_INITIALIZATION 阶段主机就发 S2F41 远程命令设备直接忽略。这种情况规格书的 GEM 状态模型章节里写得明明白白但现场很少人愿意翻到那页。3. 打开规格书先读这三块从目录到关键章节的寻路法3.1 规格书里的四层协议对应关系拿到《SECS-GEM规格书 SECS版本.doc》像拿到一张协议地图但别指望从头看到尾。我一般先用五分钟确认四个标准分别是干什么的再去抽自己需要的部分。标准代号规范内容对应实际工作E4SECS-I 传输层定义RS-232 串口通信、块传输、控制字符E5SECS-II 消息内容定义消息编号、数据项格式、各种 SxFy 结构E30GEM 设备模型状态机、事件、报警、远程命令的“行为契约”E37HSMS 高速消息服务TCP 通信、select 握手、链路测试、消息长度封装阅读顺序我的建议是先看 E37 的通信建立部分明白 TCP 连上之后还有一次 select 握手很多人忽略这一步直接发 S1F13设备压根不理再看 E5 的头部定义和数据项格式这是写解析器的基本功最后再啃 E30 的状态模型和事件模型这块直接决定你 MES 侧的设备模型怎么写。3.2 常用消息流“五张牌”覆盖九成联调需求SECS-GEM 消息流很多但实际工程项目里翻来覆去就那几个。我把规格书里最常用的流整理成表联调前逐条确认一遍流号功能范围实际联调常见消息S1设备状态与通信建立S1F13/F14 建立通信S1F3/F4 查询设备信息S2设备控制与数据采集S2F41/F42 远程命令S2F17/F18 时间同步S5报警管理S5F1/F2 报警报告与确认S6事件与追踪数据S6F11/F12 事件上报与确认S10终端显示S10F3/F4 向设备面板发消息这五个流基本能覆盖一条产线从设备上线到正常生产的全过程。比如设备一上线主机发 S1F13 建立通信生产过程中设备报个警走 S5F1批次结束想采集参数通过 S2F41 触发一次数据收集。规格书里每条消息都附了完整的数据项结构照抄即可。3.3 从目录到可执行清单三步建出联调基线读规格书最怕读完就忘。我现在的习惯是先搭一个“通信基线清单”把规格书里的关键信息转成可执行参数具体分三步。第一步列消息清单把设备需要支持的 SxFy 列表抄出来标清每条消息的发起方、数据项、W bit 置位规则。第二步定义事件映射表把设备要上报的 CEID 事件号、对应报告 ID、包含的变量列出来这表是后续 MES 配置的底稿。第三步画状态迁移图用纸笔写清楚设备从上电到生产的必经状态标注哪些状态可由远程命令切换。我一般会把这三样东西合并成一页纸夹在规格书封面内侧。联调现场不翻整本规格书只看这一页纸加对应消息的详细结构就够了。过了两周再看新项目直接翻这一页纸就能恢复记忆。4. 对照规格书看懂报文交互从 HSMS 握手到 GEM 状态迁移4.1 HSMS 握手关键参数与计时器HSMS 连上 TCP 端口不等于通信建立完成它还有一层 select 握手。联调中最常见的翻车现场是TCP 显示“已连接”但主机发 SECS-II 消息石沉大海。原因是设备在等 select.req 报文双方没有建立 HSMS 会话。正确的顺序是 TCP 连通后主机发 select.req设备回 select.rsp状态从 NOT CONNECTED 跳到 CONNECTED之后才能发 S1F13。规格书中还定义了一组计时器现场配置不当会引发“握完手就断线”的怪问题。常见做法是保留这些默认值计时器含义常见默认值实际影响T3等待回复超时45 秒超时未收到回复会话直接判死T5连接重试间隔5 秒断开后重连节奏T6控制消息等待回复5 秒select 和 linktest 超时T7select 握手持超时10 秒超过未完成握手直接断T8网络空闲超时5 秒链路静默太久触发 linktest这些值虽然各家设备软件略有差异但同一工程中主机端和设备端必须一致否则就会出现“主机 45 秒没等到回复就断开设备却还在发呆”的混乱局面。我处理这类问题必做的动作是先 ping 通再看 select 是否成功最后核对计时器参数按这个顺序基本能定位九成链路问题。4.2 一套最简联调报文序列真机联调不要上来就跑业务场景先把通信链路基础打牢。我常用的一套最小序列如下拿到任何一台设备都按这个顺序试步骤报文发起方作用确认要点1TCP Connect主机建立网络连接端口号是否正确防火墙是否放行2select.req / select.rsp主机/设备建立 HSMS 会话回复中的状态码是否为 03S1F13 / S1F14主机/设备建立 SECS 通信设备回复 MDLN 和 SOFTREV4S2F17 / S2F18主机/设备时间同步设备回复时间是否和主机一致5S1F3 / S1F4主机/设备查询设备详细信息数据项是否存在空值6S6F11 / S6F12设备/主机事件上报主机收到后必须回确认这套序列跑通后设备才算是真正纳入 MES 管理后续的远程命令、数据采集、报警上报都建立在这个基础上。序列中任何一步没通过都要先停下排查上一步不要往下带病试。4.3 GEM 状态迁移与在线/离线控制GEM 状态模型是设备行为的总纲。状态在规范里是按一个有限状态机来走的大致关系是设备上电处于禁用状态完成自检后进入通信建立阶段之后到 DEVICE_INITIALIZATION再进入空闲 IDLE最后才能接受业务命令。联调中一个高频错误是:设备还停在 DEVICE_INITIALIZATION,主机已经开始发 S2F41 远程命令设备毫无响应。正确做法是先查设备当前状态如果是初始化未完成等待设备自行完成或通过 S1F13 重新初始化如果设备卡在 DISABLED需要先检查前序条件是否满足。另一个常见操作是主机通过 S1F15/S1F17 这类控制消息切换设备离线/在线但切换前必须确认设备处于 IDLE 状态否则切换命令同样会被忽略。提示状态迁移要以设备回复为准不要以主机发送顺序为准。发控制消息后务必看响应码响应码非 0 就要打开对应规范页查原因。5. 用规格书排查八大联调故障现象、根因与对症处理5.1 现象一HSMS 握完手两分钟后自动断链现象TCP 能连上select 也成功了S1F13 正常回复但每隔一两分钟链路就断日志里报 linktest timeout。原因主机端和设备端的链路测试周期不一致一方按 30 秒发 linktest另一方把超时设得太短网络稍微延迟就判定超时。解决统一双方的 linktest 间隔和超时时间我习惯先把链路测试间隔设成 30 秒超时设成 45 秒跑通后再调优。参数通常在设备软件的通信配置页或主机配置文件的 HSMS 段里找到后两边改成一致即可。5.2 现象二设备回了 S1F14主机却报消息不合法现象设备侧日志显示已发送 S1F14主机侧却提示“消息结构无效”联调卡死在第一步。原因绝大多数情况是系统字节没按规格书要求原样返回或者 W bit 位置被设备软件写错。解决抓包软件抓一条 S1F13 和 S1F14 做对比核对两者第 6 到第 9 字节的系统字节是否完全一致。若不一致找设备厂家改协议栈这不是主机侧能兼容的问题。5.3 现象三事件触发了主机的 CEID 完全不认识现象设备已上报 S6F11主机日志收到数据但提示“未知事件号”。原因设备端 CEID 事件号是由设备厂家自定义的不同厂家同一事件编号可能含义不同主机按另一个项目的表硬解析必然对不上。解决先从设备端导出事件定义表或者在规格书里查该设备的 CEID 映射把事件号、事件名称、关联报告 ID 对应到主机的配置文件里。这里最忌讳拍脑袋猜事件含义一定要以设备实测上报为准。5.4 现象四消息长度算错解析时多读少读现象日志提示长度不足或长度溢出报错信息指向消息尾部。原因SECS 消息的 4 字节长度字段表示的是头部 10 字节加体部字节的总和有的开发习惯只算体部导致接收端等不到完整消息。解决接收时先把 4 字节长度字段读出来加 10 得到总长再按总长收包。分块传输的情况还要处理块拼接注意规格书中分块消息的块序和结束标志。5.5 现象五设备状态卡在 DEVICE_INITIALIZATION 不动现象设备一直显示初始化状态主机发任何业务命令都没反应。原因主机没发送 GEM 要求的在线/离线控制消息或者发送的时机不对设备等不到状态切换指令。解决按规格书状态迁移图先确认设备是否已进入 IDLE 前的最后一个待命状态然后主机发送 S1F15 或 S1F17 让设备切换在线模式收到确认后再操作业务。5.6 现象六W bit 设为 1却不等回复就发下一条现象主机连续发了多条请求消息设备只回了第一条后面全部丢失。原因SECS-II 规定同一时间只能有一个未完成的“需要回复”请求W bit 为 1 时主机必须等对端回包后才能发下一条。原因二主机在发下一条时系统字节里置了新的值导致对端无法对应。解决串行化自己的请求队列每条 W bit1 的消息必须等到响应或超时才放行下一条。6. 把规格书翻译成验收测试矩阵我的最后一关习惯6.1 做一张“消息流×通过条件”的测试矩阵联调不是凭感觉试我习惯把规格书每个功能点翻译成一张测试矩阵每行一条用例每列一个通过标准。这张表同时给设备厂家和 MES 侧用双方按同一张表验收扯皮的事少一半。用例编号场景消息序列通过条件TC01通信建立TCPselect S1F13/141 分钟内完成MDLN 非空TC02时间同步S2F17/18时间差小于 1 秒TC03远程命令S2F41/42 触发某个配方切换设备响应码为 0执行结果一致TC04事件上报人为触发一个重事件验证 S6F11/12事件号和报告内容匹配TC05报警处理断开某个传感器验证 S5F1/2报警码正确主机回确认TC06链路恢复拔掉网线再插回自动重连并重新握手成功这张表填完后联调就是“一行行过”的机械动作出问题直接定位到具体用例。6.2 用模拟器先把主机端跑通再碰真设备跟真实设备联调前我强烈建议先用一个 SECS-GEM 模拟器把主机端逻辑跑一遍。模拟器可以模拟设备端行为建通信、报事件、回报警全都能在一个软件里配出来。这样有两个好处一是把主机端的解析逻辑问题先暴露掉免得把“主机 bug”和“设备 bug”混在一起排查二是可以模拟异常场景比如故意不回系统字节、故意延迟响应检验主机端超时处理是否健壮。用模拟器时我一般会额外做一件事打开抓包工具把所有报文录下来建一个报文数据库后续真机联调时随时对比模拟器跑出的标准报文和真机报文的差异排查效率提升非常明显。6.3 跑真机前的最后十分钟真机联调前我最后十分钟永远是同一套动作打开规格书确认 HSMS 参数一致打开测试矩阵勾选本次要跑的用例启动抓包工具确保端口 5000 的流量都在记录范围内。这套动作成习惯之后几乎没再遇到过那种“连上又断、断了又连”的前半夜。有一次新设备到场对方工程师说他这设备“肯定没问题”我不慌不忙把抓包记录拉出来看到 select 握手后设备发来的响应里系统字节被写成了全零。这种问题不抓包、不对照规格书靠看界面永远查不出来。从那以后我每次联调第一件事都是先确认系统字节规则和计时器参数再谈其他。希望帮到你少走那些我走过的弯路。本文还有配套的精品资源点击获取 SECS-GEM协议联调实战：从规格书到报文排查的完整方法
简介SECS-GEM规格书SECS版本以Word文档形式整理面向半导体设备工程师、自动化软件开发者及工厂集成人员用于快速掌握设备与主机间标准通讯协议。文档围绕GEM适应性展开系统梳理状态模型、设备处理状态、主机发起场景、事件通知、在线识别、动态事件报告配置、变量与状态数据采集、报警管理、远程控制等核心模块并结合消息摘要、TCP/IP通讯协议、变量与命令实现、消息类型实现等章节帮助读者建立SECS/GEM完整知识框架支撑实际项目中的设备联调、功能开发与异常排查。压缩包内仅含1个doc文件大小约514KB章节划分明确便于按需查阅。目前已有1251人学习下载适合需要接触半导体设备自动化通讯协议的工程人员作为入门指引或规范速查手册使用。1. SECS-GEM规格书 SECS版本设备端与主机端都绕不过的那道协议门上个月在封测厂帮朋友查设备联调设备商的软件交付了MES侧照着一个老项目的代码改了三天结果一拉日志S1F3 能收到回复S1F14 之后直接掉线。我翻出通信记录一看问题出在“系统字节没有原样带回”这种规格书里写得清清楚楚的细节上。这种情况我遇到不止一次多数人都是先把协议跑通翻车了才回头去翻《SECS-GEM规格书 SECS版本.doc》。这份规格书把 SECS-I、SECS-II、HSMS、GEM 四块内容捆在一起对设备开发、MES 集成、中间件维护的工程师来说等于把“设备怎么开口、MES 怎么接话”的标准答案提前摆在你桌上。它解决的是联调现场最耗时的那类问题报文格式对不上、链路反复断、CEID 事件编号各说各话。适合搞设备软件、搞工厂自动化、写通信中间件的人新手能当敲门砖老手能当查错字典。2. 拆开 SECS 和 HSMS传输层与消息层的分工比你想的重要2.1 先分清 SECS-I 和 HSMS联调现场第一步是选对传输层很多现场工程师把“SECS”和“HSMS”混成一个词真到配置界面就卡住。SECS-I 是串口时代的产物基于 RS-232/RS-422消息按块传输一块最多 2KB适合老式单机设备HSMS 是基于 TCP/IP 的新一代传输端口传统上走 5000消息长度用 4 个字节前置定义数据量能上大很多。选型原则不复杂设备端支持 HSMS 就优先用 HSMS不要图省事去走串口转换。现在新出厂的半导体设备基本默认开 HSMS有些设备厂甚至只留 TCP 口串口连上去也没响应。判断方法很简单打开设备的 Service 菜单看有没有“Host Port”或“SECS Comm”相关选项里面若出现端口号就是 HSMS 无疑。维度SECS-IHSMS物理层RS-232 / RS-422 串口TCP/IP 以太网常用端口无直接连串口默认 5000单块消息上限2KB超出要分块消息长度字段用 4 字节上限宽松得多连接管理物理链路通即可需要 select.req/select.rsp 建立会话适用设备老款、单机、无网卡设备当前大部分新设备、需对接 MES 的设备真机上我遇到过一台老款固晶机只支持 SECS-I主机端非要走 HSMS最后加了一个串口服务器才把事情办了。反过来也一样有些一体化设备模块默认 HSMS 但防火墙没开放 5000TCP 连不上。联调前先搞清楚双方各自能跑哪一层能省掉半天无谓的排查时间。2.2 SECS-II 消息结构从 SxFy 到头部字段的直读法SECS-II 是“消息内容”的规范。所有 SECS-I 和 HSMS 传输的数据载荷部分都用 SECS-II 来定义。每条消息有一个编号写成 SxFy 的形式S 是 Stream 流号F 是 Function 功能号。比如 S1F13 表示“建立通信请求”S1F14 是它的应答S2F41 是“远程命令请求”。消息头总计 10 个字节打开规格书里“消息格式”那一节主要看这几个字段字段位置相对头部作用联调时的注意点设备 ID第 0-1 字节标识主机或设备大部分单设备场景用 0两台设备共用一条线时要区分W bit设备 ID 最高位0 表示单向消息1 表示需要回复发请求消息时清掉 W bit主机就不等你回应流/功能号第 2 字节高 4 位流低 4 位功能对应 SxFy 编号消息编号靠这字节定位抓包先看它系统字节第 6-9 字节请求与响应的对应关系必须原样返回这是最容易踩坑的地方这里给一段按字节拆解头部的 Python 代码我在写解析工具时就是这么处理的直接对应规格书里的头部定义import struct def parse_secs2_header(h): h 是从消息缓冲区里截出来的 10 字节 SECS-II 头。 返回 (设备ID, Wbit, Stream, Function, SystemBytes) if len(h) 10: raise ValueError(SECS-II header must be 10 bytes) # 第0字节高1位是W bit低7位是设备ID高7位第1字节是设备ID低8位 wbit (h[0] 7) 0x01 device_id ((h[0] 0x7F) 8) | h[1] # 第2字节高4位是Stream低4位是Function stream (h[2] 4) 0x0F function h[2] 0x0F # 第6-9字节是系统字节请求和响应必须一致 sys_bytes int.from_bytes(h[6:10], byteorderbig) return device_id, wbit, stream, function, sys_bytes这段代码的关键在最后两行规格书里明确要求响应消息把请求消息的系统字节照搬回来很多底层库并不会帮你校验这个得自己在协议层盯。如果 W bit 为 1 而你发了消息后没收到回复第一个要查的就是对端的系统字节是否有跟你消息里一致的值。另外注意字节序标准里系统字节是大端别用本地小端直接读否则数值会倒过来比较。2.3 GEM 把设备“行为”管了起来GEM 是 SEMI E30 里定义的设备模型我把它理解成“设备怎么表现才算合格”。SECS-II 只规定消息格式GEM 规定设备在什么状态做什么事上电后要先做自检自检完进入通信建立再切到空闲随后才能收远程命令。这个状态迁移过程是设备厂家软件和 MES 侧都必须遵守的共同规则。GEM 覆盖五件事状态模型、在线/离线控制、事件报告、报警管理、远程命令与数据收集。联调时很多“设备没反应”的问题其实不是消息格式错而是设备当前状态不允许做这个动作。比如设备还在 DEVICE_INITIALIZATION 阶段主机就发 S2F41 远程命令设备直接忽略。这种情况规格书的 GEM 状态模型章节里写得明明白白但现场很少人愿意翻到那页。3. 打开规格书先读这三块从目录到关键章节的寻路法3.1 规格书里的四层协议对应关系拿到《SECS-GEM规格书 SECS版本.doc》像拿到一张协议地图但别指望从头看到尾。我一般先用五分钟确认四个标准分别是干什么的再去抽自己需要的部分。标准代号规范内容对应实际工作E4SECS-I 传输层定义RS-232 串口通信、块传输、控制字符E5SECS-II 消息内容定义消息编号、数据项格式、各种 SxFy 结构E30GEM 设备模型状态机、事件、报警、远程命令的“行为契约”E37HSMS 高速消息服务TCP 通信、select 握手、链路测试、消息长度封装阅读顺序我的建议是先看 E37 的通信建立部分明白 TCP 连上之后还有一次 select 握手很多人忽略这一步直接发 S1F13设备压根不理再看 E5 的头部定义和数据项格式这是写解析器的基本功最后再啃 E30 的状态模型和事件模型这块直接决定你 MES 侧的设备模型怎么写。3.2 常用消息流“五张牌”覆盖九成联调需求SECS-GEM 消息流很多但实际工程项目里翻来覆去就那几个。我把规格书里最常用的流整理成表联调前逐条确认一遍流号功能范围实际联调常见消息S1设备状态与通信建立S1F13/F14 建立通信S1F3/F4 查询设备信息S2设备控制与数据采集S2F41/F42 远程命令S2F17/F18 时间同步S5报警管理S5F1/F2 报警报告与确认S6事件与追踪数据S6F11/F12 事件上报与确认S10终端显示S10F3/F4 向设备面板发消息这五个流基本能覆盖一条产线从设备上线到正常生产的全过程。比如设备一上线主机发 S1F13 建立通信生产过程中设备报个警走 S5F1批次结束想采集参数通过 S2F41 触发一次数据收集。规格书里每条消息都附了完整的数据项结构照抄即可。3.3 从目录到可执行清单三步建出联调基线读规格书最怕读完就忘。我现在的习惯是先搭一个“通信基线清单”把规格书里的关键信息转成可执行参数具体分三步。第一步列消息清单把设备需要支持的 SxFy 列表抄出来标清每条消息的发起方、数据项、W bit 置位规则。第二步定义事件映射表把设备要上报的 CEID 事件号、对应报告 ID、包含的变量列出来这表是后续 MES 配置的底稿。第三步画状态迁移图用纸笔写清楚设备从上电到生产的必经状态标注哪些状态可由远程命令切换。我一般会把这三样东西合并成一页纸夹在规格书封面内侧。联调现场不翻整本规格书只看这一页纸加对应消息的详细结构就够了。过了两周再看新项目直接翻这一页纸就能恢复记忆。4. 对照规格书看懂报文交互从 HSMS 握手到 GEM 状态迁移4.1 HSMS 握手关键参数与计时器HSMS 连上 TCP 端口不等于通信建立完成它还有一层 select 握手。联调中最常见的翻车现场是TCP 显示“已连接”但主机发 SECS-II 消息石沉大海。原因是设备在等 select.req 报文双方没有建立 HSMS 会话。正确的顺序是 TCP 连通后主机发 select.req设备回 select.rsp状态从 NOT CONNECTED 跳到 CONNECTED之后才能发 S1F13。规格书中还定义了一组计时器现场配置不当会引发“握完手就断线”的怪问题。常见做法是保留这些默认值计时器含义常见默认值实际影响T3等待回复超时45 秒超时未收到回复会话直接判死T5连接重试间隔5 秒断开后重连节奏T6控制消息等待回复5 秒select 和 linktest 超时T7select 握手持超时10 秒超过未完成握手直接断T8网络空闲超时5 秒链路静默太久触发 linktest这些值虽然各家设备软件略有差异但同一工程中主机端和设备端必须一致否则就会出现“主机 45 秒没等到回复就断开设备却还在发呆”的混乱局面。我处理这类问题必做的动作是先 ping 通再看 select 是否成功最后核对计时器参数按这个顺序基本能定位九成链路问题。4.2 一套最简联调报文序列真机联调不要上来就跑业务场景先把通信链路基础打牢。我常用的一套最小序列如下拿到任何一台设备都按这个顺序试步骤报文发起方作用确认要点1TCP Connect主机建立网络连接端口号是否正确防火墙是否放行2select.req / select.rsp主机/设备建立 HSMS 会话回复中的状态码是否为 03S1F13 / S1F14主机/设备建立 SECS 通信设备回复 MDLN 和 SOFTREV4S2F17 / S2F18主机/设备时间同步设备回复时间是否和主机一致5S1F3 / S1F4主机/设备查询设备详细信息数据项是否存在空值6S6F11 / S6F12设备/主机事件上报主机收到后必须回确认这套序列跑通后设备才算是真正纳入 MES 管理后续的远程命令、数据采集、报警上报都建立在这个基础上。序列中任何一步没通过都要先停下排查上一步不要往下带病试。4.3 GEM 状态迁移与在线/离线控制GEM 状态模型是设备行为的总纲。状态在规范里是按一个有限状态机来走的大致关系是设备上电处于禁用状态完成自检后进入通信建立阶段之后到 DEVICE_INITIALIZATION再进入空闲 IDLE最后才能接受业务命令。联调中一个高频错误是:设备还停在 DEVICE_INITIALIZATION,主机已经开始发 S2F41 远程命令设备毫无响应。正确做法是先查设备当前状态如果是初始化未完成等待设备自行完成或通过 S1F13 重新初始化如果设备卡在 DISABLED需要先检查前序条件是否满足。另一个常见操作是主机通过 S1F15/S1F17 这类控制消息切换设备离线/在线但切换前必须确认设备处于 IDLE 状态否则切换命令同样会被忽略。提示状态迁移要以设备回复为准不要以主机发送顺序为准。发控制消息后务必看响应码响应码非 0 就要打开对应规范页查原因。5. 用规格书排查八大联调故障现象、根因与对症处理5.1 现象一HSMS 握完手两分钟后自动断链现象TCP 能连上select 也成功了S1F13 正常回复但每隔一两分钟链路就断日志里报 linktest timeout。原因主机端和设备端的链路测试周期不一致一方按 30 秒发 linktest另一方把超时设得太短网络稍微延迟就判定超时。解决统一双方的 linktest 间隔和超时时间我习惯先把链路测试间隔设成 30 秒超时设成 45 秒跑通后再调优。参数通常在设备软件的通信配置页或主机配置文件的 HSMS 段里找到后两边改成一致即可。5.2 现象二设备回了 S1F14主机却报消息不合法现象设备侧日志显示已发送 S1F14主机侧却提示“消息结构无效”联调卡死在第一步。原因绝大多数情况是系统字节没按规格书要求原样返回或者 W bit 位置被设备软件写错。解决抓包软件抓一条 S1F13 和 S1F14 做对比核对两者第 6 到第 9 字节的系统字节是否完全一致。若不一致找设备厂家改协议栈这不是主机侧能兼容的问题。5.3 现象三事件触发了主机的 CEID 完全不认识现象设备已上报 S6F11主机日志收到数据但提示“未知事件号”。原因设备端 CEID 事件号是由设备厂家自定义的不同厂家同一事件编号可能含义不同主机按另一个项目的表硬解析必然对不上。解决先从设备端导出事件定义表或者在规格书里查该设备的 CEID 映射把事件号、事件名称、关联报告 ID 对应到主机的配置文件里。这里最忌讳拍脑袋猜事件含义一定要以设备实测上报为准。5.4 现象四消息长度算错解析时多读少读现象日志提示长度不足或长度溢出报错信息指向消息尾部。原因SECS 消息的 4 字节长度字段表示的是头部 10 字节加体部字节的总和有的开发习惯只算体部导致接收端等不到完整消息。解决接收时先把 4 字节长度字段读出来加 10 得到总长再按总长收包。分块传输的情况还要处理块拼接注意规格书中分块消息的块序和结束标志。5.5 现象五设备状态卡在 DEVICE_INITIALIZATION 不动现象设备一直显示初始化状态主机发任何业务命令都没反应。原因主机没发送 GEM 要求的在线/离线控制消息或者发送的时机不对设备等不到状态切换指令。解决按规格书状态迁移图先确认设备是否已进入 IDLE 前的最后一个待命状态然后主机发送 S1F15 或 S1F17 让设备切换在线模式收到确认后再操作业务。5.6 现象六W bit 设为 1却不等回复就发下一条现象主机连续发了多条请求消息设备只回了第一条后面全部丢失。原因SECS-II 规定同一时间只能有一个未完成的“需要回复”请求W bit 为 1 时主机必须等对端回包后才能发下一条。原因二主机在发下一条时系统字节里置了新的值导致对端无法对应。解决串行化自己的请求队列每条 W bit1 的消息必须等到响应或超时才放行下一条。6. 把规格书翻译成验收测试矩阵我的最后一关习惯6.1 做一张“消息流×通过条件”的测试矩阵联调不是凭感觉试我习惯把规格书每个功能点翻译成一张测试矩阵每行一条用例每列一个通过标准。这张表同时给设备厂家和 MES 侧用双方按同一张表验收扯皮的事少一半。用例编号场景消息序列通过条件TC01通信建立TCPselect S1F13/141 分钟内完成MDLN 非空TC02时间同步S2F17/18时间差小于 1 秒TC03远程命令S2F41/42 触发某个配方切换设备响应码为 0执行结果一致TC04事件上报人为触发一个重事件验证 S6F11/12事件号和报告内容匹配TC05报警处理断开某个传感器验证 S5F1/2报警码正确主机回确认TC06链路恢复拔掉网线再插回自动重连并重新握手成功这张表填完后联调就是“一行行过”的机械动作出问题直接定位到具体用例。6.2 用模拟器先把主机端跑通再碰真设备跟真实设备联调前我强烈建议先用一个 SECS-GEM 模拟器把主机端逻辑跑一遍。模拟器可以模拟设备端行为建通信、报事件、回报警全都能在一个软件里配出来。这样有两个好处一是把主机端的解析逻辑问题先暴露掉免得把“主机 bug”和“设备 bug”混在一起排查二是可以模拟异常场景比如故意不回系统字节、故意延迟响应检验主机端超时处理是否健壮。用模拟器时我一般会额外做一件事打开抓包工具把所有报文录下来建一个报文数据库后续真机联调时随时对比模拟器跑出的标准报文和真机报文的差异排查效率提升非常明显。6.3 跑真机前的最后十分钟真机联调前我最后十分钟永远是同一套动作打开规格书确认 HSMS 参数一致打开测试矩阵勾选本次要跑的用例启动抓包工具确保端口 5000 的流量都在记录范围内。这套动作成习惯之后几乎没再遇到过那种“连上又断、断了又连”的前半夜。有一次新设备到场对方工程师说他这设备“肯定没问题”我不慌不忙把抓包记录拉出来看到 select 握手后设备发来的响应里系统字节被写成了全零。这种问题不抓包、不对照规格书靠看界面永远查不出来。从那以后我每次联调第一件事都是先确认系统字节规则和计时器参数再谈其他。希望帮到你少走那些我走过的弯路。本文还有配套的精品资源点击获取