很多初次接触半导体设备自动化的人听到“SECS/GEM”这四个字母就已经头皮发麻更别提要在一个叫 SecsExpress 的测试工具里把消息报文、设备模型、事件上报全部跑通。我当年第一次调试设备端 SECS/GEM 通讯的时候手头只有一台几乎没有界面可言的模拟器连 S1F1 该回什么格式都靠翻标准文档硬生生折腾了两个通宵。后来换到 SecsExpress 做配置和联调整个效率完全不一样——它既能模拟 Host 也能模拟 Equipment可以在没有真实 EAP/MES 的情况下把整套 SECS/GEM 通讯链路搭起来消息收发、原始报文查看、数据项定义、异常场景复现都能在界面上完成。这篇文章我会把 SecsExpress 的配置逻辑、连接参数、消息定义和现场踩坑排查链路全部写清楚适合设备软件工程师、EAP 开发人员、半导体自动化项目调试人员也适合刚入行想搞懂 SECS/GEM 到底在说什么的初学者。1. 为什么我最终选定了 SecsExpress 作为 SECS/GEM 联调工具1.1 SECS/GEM 协议调试的真实痛点SECS/GEM 是半导体设备与上位机之间的标准通信协议族核心分成两块底层传输用 SECS-I串口或 HSMS以太网上层消息用 SECS-II。协议本身定义了丰富的消息类型比如 S1F1 是建立通信请求S2F41 是主机发送命令S6F11 是设备上报数据S5F1 是设备报警。逻辑链路不长但实际调试时极其痛苦。痛苦点主要有三个。第一报文是二进制格式。设备端发出的一串字节包含了消息头、系统字节、SECS-II 数据区如果没有工具做解码光靠肉眼对 hex 去猜“这一段是不是 List”“那一段是不是 ASCII”效率极低。第二SECS/GEM 有严格的状态模型和超时机制。设备处于什么状态、收到什么消息该回什么消息、超时多久要重试或断开这些都是协议规定的。我在项目里见过太多“连上了但互相不搭理”的情况两边都觉得自己发了消息实际是消息头里的 Device ID 对不上或者响应 Bit 没置位接收端直接丢弃。第三现场调试验收时往往上位机环境不完整。要么 MES 还没部署要么 EAP 没开发完设备程序却已经要开始测试了。这时候如果有一个能灵活模拟对端的测试工具整个项目进度都不会被卡死。所以选测试工具的核心逻辑很简单能不能同时充当 Host 和 Equipment能不能完整解析和构造 SECS-II 消息能不能看清原始字节流以及能不能用脚本或配置实现自动响应。SecsExpress 在这几条上的表现都不错。1.2 SecsExpress 的核心能力与同类工具对比SecsExpress 本质上是一个图形化的 SECS/GEM 消息测试平台。它不是库不需要你写代码去调 API而是通过界面配置连接参数、消息内容、变量映射和响应脚本然后在 PC 上模拟整条通讯链路。它的亮点功能我列一下支持 HSMS 和 SECS-I 两类传输方式TCP/IP 连接和串口连接都能测。可以以 Host 模式运行主动连接设备也可以以 Equipment 模式运行监听端口等待上位机接入。支持完整的 SECS-I/II 消息编辑提供 SMLSECS Message Language文本编辑和树形结构编辑两种方式。能实时查看会话状态、消息收发记录和原始 hex 数据。可以定义设备变量Vid、状态变量SV、数据值DV和事件Event模拟设备主动上报的场景。内置自动回复脚本收到某个消息后按规则自动回响应。同类的工具有 SEMI 标准组织出品的 SecsTester、商业软件 SECS/GEM Communicator以及一些设备厂商自己封装的模拟器。我没有贬低它们的意思但实际用下来的对比很直观。SecsTester 更像协议库适合二次开发纯手工测试反而要写很多辅助代码。SECS/GEM Communicator 功能很全可价格不便宜而且配置项非常多入门曲线陡峭。SecsExpress 的最大优势是轻量和直观界面右侧是消息树左侧是会话控制中间是收发日志刚接触协议的人也能在半小时内把第一条消息发出去。当然它也有短板比如在压力测试和大批量消息自动生成的场景下性能不如脚本化工具但作为日常联调和问题诊断完全够用。2. 装环境前必须先想清楚的连接模型与参数2.1 HSMS 连接中的角色与端口分配不少人在 SecsExpress 里卡住不是因为工具不会用而是因为没搞懂 HSMS 连接模型。HSMS 是全双工 TCP/IP 通信两端的角色分为 Active 和 Passive。Active 端主动发起 TCP 连接Passive 端被动监听端口。按照半导体工厂的惯例Host 通常是 Active 端Equipment 通常是 Passive 端。设备上电后开启监听Host 侧启动后发起连接。用 SecsExpress 联调时连接模型建议这样分配端角色IP端口HostSecsExpress Host 模式Active192.168.0.100随机或指定本地端口EquipmentSecsExpress Equipment 模式Passive192.168.0.1105000端口本身没有硬性规定但行业内比较常见的是 5000、5001、9999 这些。关键是要提前和上位机、IT 或网络工程师对齐IP 是否在同一网段端口号是否被防火墙拦截被动端监听时是否允许外部连接。我曾经在现场遇到过设备端把 HSMS 端口设成了 5000上位机侧默认连 5001两边都在“正常工作”就是通信不上查了一个多小时才发现是端口不匹配。还有一个容易忽略的点如果你在同一台电脑上同时跑两个 SecsExpress 实例一个模拟 Host一个模拟 Equipment那么 Rockwell 的 IP 建议用 127.0.0.1但端口必须不同。因为 TCP 连接的四元组要求唯一如果两个实例都监听同一个端口第二个实例会启动失败而且失败信息常常不是那么明显只会在会话日志里提示 bind error。2.2 Equipment ID、Device ID 和消息路由的关系SECS/GEM 消息头的第一段是系统字节之外的关键字段其中 Device ID 是最容易配置错的东西。Device ID 用来在 Host 和设备之间标识消息归属。规范里它实质是 10 bit 字段常见取值是 0 到 32600 左右实际项目里通常分配一个整数比如 0、1、10、100。很多人把“Equipment ID”和“Device ID”混为一谈其实它们在工具配置里是两个不同的概念。Equipment ID 通常指设备识别码是 S1F2 返回的设备信息里的 ID 字段偏业务属性Device ID 是 SECS-II 消息头里的路由字段偏通信属性。在 SecsExpress 中如果你用 Equipment 模式需要在连接配置里填写本设备的 Device ID表示“我是设备我的设备号为 X”如果你用 Host 模式连接配置里要填的是目标设备的 Device ID表示“我要跟设备号为 X 的设备通信”。两边必须一致否则消息发出后被对端识别为不是发给自己的直接就丢了而且不会有任何报错。我在实测中还遇到过一种情况SecsExpress 模拟 Host 时如果 Device ID 填 0有些设备端协议栈会认为这是全局广播消息能够正常响应但换成真实 EAP 后EAP 下发的 Device ID 是它在配置里指定的值设备端加了校验导致连接正常但消息无响应。这个问题在 SecsExpress 上根本复现不出来所以建议大家从一开始就约定一个明确的 Device ID不要靠“填 0 也能通”这种侥幸。2.3 时钟与超时参数为什么必须提前对齐SECS/GEM 协议里有一组 T 超时参数说它们是调试最大的坑也不为过。最常用的是 T3、T5、T6、T7、T8。T3 是等待响应消息的超时单位秒一般设 5 秒到 45 秒T5 是连接请求之间的间隔单位秒T6 是控制消息响应超时T7 是连接建立后到收到第一条消息的时间限制T8 是接收缓冲区网络字符间隔限制。SecsExpress 允许你在连接设置中修改这些值。有一次我把设备端的 T3 设成了 10 秒Host 侧 SecsExpress 的 T3 用默认 5 秒。结果就是设备发了一条需要 Host 回执的消息Host 等了 5 秒没等到其实设备还在处理业务逻辑直接把连接断开了。表面上看起来像程序 bug实际就是超时参数不一致。联调之前建议建立一个参数确认表把 T3、T5、T6、T7、T8 的值、Device ID、端口号、IP 地址、消息日志等级全部列清楚设备端、Host 端各留一份。这个表我已经在多个项目里用了能省掉至少一半“莫名其妙断连”的排查时间。3. 用 SecsExpress 配置一台虚拟设备并完成首次通讯3.1 以 Equipment 模式创建并启动服务先在 SecsExpress 里新建一个连接配置选择 Equipment 模式传输方式选 HSMS本地监听地址设为本机局域网 IP 或 127.0.0.1端口设好Device ID 按实际填入。保存后点击启动监听面板上会显示正在监听状态。然后我们需要一个对端。最简单的方式是在本机再启动第二个 SecsExpress 实例新建 Host 模式连接把远程地址指向刚才的 IP 和端口点击连接。如果配置正确两边会话日志会打出 Link Established这个就是 HSMS 链路建立成功的标志。这里有个小细节SecsExpress 的会话状态显示逻辑在不同版本里略有不同有的版本显示“Connected”有的版本显示“Link Established”还有的版本在建立 T3 连接和建立通信会话之间会有几条 S 消息往来。只要日志区出现“Link Established”说明 TCP 和 HSMS 都已经通了。3.2 从第一条 S1F1 开始验证会话链路通了以后第一个要发的消息一定是 S1F1。S1F1 是“建立通信请求”名字叫 Are You There它的数据项为空消息结构很简单S1F1 W .在 SecsExpress 里你可以用 SML 编辑器直接输入这段内容也可以利用消息树模板选择 S1F1工具会自动把消息头、系统字节和响应要求生成好。这里要注意 W 的含义W 表示消息发送后要等待对端响应消息数据区结束后以 . 结束。S1F1 W 会让 Host 发送后进入等待状态设备收到后必须回一个 S1F2。S1F2 的响应体不是空的规范要求携带 MDLN 和 SOFTREV也就是设备型号和软件版本。标准回复长这样S1F2 W L A SecsExpress A 1.0 .在 SecsExpress 模拟设备时你可以手动发送这条 S1F2也可以在消息配置里启用自动回复让工具收到 S1F1 后自动生成 S1F2。我第一次用的时候踩过坑手动模式下设备端收到 S1F1但没有人去点“发送 S1F2”Host 侧一直等直到 T3 超时。所以如果你只是做链路验证强烈建议先在设备模拟端配置好 S1F1 的自动回复再发起会话。3.3 数据项与 Collection Plan 的定义S1F1/S1F2 跑通只是敲门砖真实调试中更常用的是状态变量上报和事件上报。SECS/GEM 里有一整套数据收集机制设备端维护状态变量SV每个状态变量有 Vid 和值也可以把若干状态变量打包成数据集DV事件Event触发后通过 S6F11 上报给 HostHost 回复 S6F12 确认。在 SecsExpress 里定义这些不需要写代码界面操作就行。流程是在变量定义界面里新建一个 Vid指定数据类型比如 U4、F4、ASCII。把 Vid 关联到某个状态变量上并赋予初始值。新建一个事件绑定一个或多个状态变量。再定义一个数据集把刚才的事件变量包含进去配置上报数量。事件触发条件设置为“手动”或“脚本”。配置完以后模拟设备端点击触发事件的按钮Host 端就能收到 S6F11内容就是数据集里所有变量的值。很多人忽略的一点是数据量REPORTID必须和事件上报的数据集 ID 一致Host 侧如果是用固定 REPORTID 来匹配消息的设备端上报了别的 IDHost 可能直接不处理。4. 实际踩坑连接不上、消息无回应的排查链路4.1 连接级别的排查TCP 能通HSMS 却失败先说一个我重复遇到无数次的场景SecsExpress 点击连接后状态槽一直停在 Not Connected既不报错也没有更多日志。这种问题别急着改消息内容先按链路顺序排查。第一步用 ping 看 IP 通不通。如果通继续如果不通查网线、交换机、双端 IP 网段。第二步验证端口通不通。Windows 下可以直接在命令行用 telnet IP 端口如果端口被防火墙挡掉telnet 会直接失败。这时候去检查被动端的 Windows 防火墙是否放行了该端口尤其是专用网络和公用网络的配置要一起看。第三步确认角色是否正确。Host 是 ActiveEquipment 是 Passive如果你把 SecsExpress 设成 Host 去监听端口那当然等不到连接。第四步用 netstat -ano 看这个端口是否被其他程序占用我遇到过设备端程序和 SecsExpress 同时绑定了同一个端口后者监听失败日志却只提示链接未建立。HSMS 建立后还有一个常见坑设备端是被动监听方如果 Host 侧先启动并完成连接然后设备端程序重启了那么原 TCP 连接会被断开Host 不会自动重连。很多时候不是协议错误而是时序问题。工作流应该是先启动设备端监听稳定后再启动 Host 连接。SecsExpress 如果支持自动重连也要把重连间隔设成和 T5 一致否则频繁重试会导致对端来不及响应。4.2 消息级别的排查连接正常但发出 S1F1 后无响应链路已建立消息也发出去了但对方就是不回这是最让人抓狂的情况。根据我的经验按优先级查这四类原因。第一检查消息头的 Device ID。这个话题我在前面强调过如果 Host 发送的 Device ID 和设备端配置不一致设备端协议栈可能直接丢弃消息。有些实现比较严格会发 S9F1格式错误甚至直接断开连接。第二检查系统字节是否合法。SECS/GEM 要求请求消息的系统字节不能为全 0响应消息的系统字节必须和请求一致。如果你在用 SecsExpress 手动编辑消息时不小心把系统字节置 0部分对端不会回复。解决方法是让工具自动生成系统字节不要自己填。第三检查响应 Bit 设置。S1F1 的消息头里响应 Bit 为 1 代表需要对方回复如果这个消息格式是 W工具会自动把响应位置 1但如果你手动改过消息头就可能把响应位改没了。第四检查自动回复配置。SecsExpress 模拟设备时它默认更像一个“空壳”不会主动对收到的任何消息都回响应。你必须在配置里为 S1F1 编写自动回复或者收到消息后手动回复。否则数据链路没有任何问题但对方会一直等到 T3 超时。我曾经拿 SecsExpress 模拟设备给 EAP 测试EAP 发 S1F1设备端日志里能看到消息到达但 EAP 一直没有收到 S1F2。最后发现是我建了连接配置但忘了给 S1F1 绑定自动回复脚本这个错误非常隐蔽因为从报文上看一切都是正常的就是“没人回话”。4.3 数据格式类问题解析失败和数据类型不匹配消息通了响应也了但数据内容和预期不一致这类问题通常出在 SECS-II 数据格式上。SECS-II 的数据项类型很多ASCIIA、二进制B、无符号整型U1、U2、U4、U8、浮点F4、F8、布尔Boolean、列表List等等。每个数据项在消息里都带有类型和长度信息长度不匹配或者类型错误对端工具就会解析失败在消息日志里把对应位置标红或者直接丢弃整条消息。我在实际项目里遇到最多的是三种情况。一是 List 嵌套层级不对。S6F11 的正文是一个大的 List里面套着数据项。如果你手写 SML 时少写了一层L和导致数据结构错位对端解析时就会报错。二是长度溢出。定义了一个 U1 变量却往里面塞了超过 255 的数或者定义 F4 却用整数字面量工具会自动转换但精度已经丢失。三是字符串编码问题。SECS/GEM 的 ASCII 数据项通常按单字节 ASCII 处理如果数据里有中文或特殊字符不同实现的处理完全不同。SecsExpress 用 SML 编辑时字符编码是 UTF-8但设备端程序可能用的是本地编码两边一拼接就会变成乱码。遇到这类问题我的排查方法是先看工具里的 hex 原始报文把 SECS-II 头和数据区逐字节对一下确认类型和长度都正确再打开 SML 视图检查 List 括号是否配对。如果问题是偶发性的比如跑了几百条数据后偶尔解析失败一次优先检查变长数组和动态 List 的构建逻辑绝对不要靠肉眼看日志。5. 与 MES/上位机联调时的实战技巧5.1 同时开两个 SecsExpress 实例做 MES 仿真现场联调的一个高价值操作是同时启动两个 SecsExpress 实例一个模拟 Host一个模拟 Equipment先把两端在工具层面打通再逐步替换成真实系统。这个做法特别适合定位边界问题。举个例子某个设备程序接入真实 MES 后出现了报警上报不成功的现象。我们做了三步测试第一步用 SecsExpress 模拟 Host连接设备验证设备 S5F1 发出来Host 回 S5F2报警链路通第二步用 SecsExpress 模拟设备连接真实 EAP验证 EAP 能正常接收 S5F1 并回复第三步如果第一步通、第二步不通问题就在 EAP 的消息解析上如果两步都不通则要检查设备程序的协议栈实现。这样一来问题边界一下子就清楚了很多。还有一个容易被忽略的点SecsExpress 在模拟两个实例时可以保存历史日志。我会把关键消息序列导出粘贴到问题单或开发文档里。截图加报文文字比单纯描述“发不出来”要有说服力得多。5.2 用脚本和手动注入构造异常场景测试工具的价值不只是把正常场景跑通更重要的是能构造异常场景验证对端程序的容错能力。SecsExpress 在这方面很灵活你可以编辑任何一条消息后发送也可以故意不回响应或者修改消息头字节。我常用的异常注入方法有这么几类超时异常发出请求后故意不回复观察对端是否按预期在 T3 超时后进行重试或报错。重复消息同一个系统字节的请求连续发两次看对端是否能正确处理幂等性而不是把第二次当成新请求。非法数据往数值型数据项里传入超范围的值或者往固定长度数组里塞超出长度的数据测试协议栈对异常数据的防御。错误顺序在设备未就绪时发送 S2F41 命令看状态模型是否正确拒绝。这些异常测试在日常工作中很容易被覆盖跑掉但上线后往往因为这些场景出问题。我的习惯是每次联调都留一个小时专门做异常注入把工具里的消息日志导成测试记录作为验收附件。5.3 与设备底层通信的联动SecsExpress 验证的是 SECS/GEM 协议层但在真实设备里SECS/GEM 协议栈只是最上层下面还连着 PLC、传感器、伺服、机械臂等底层系统。设备收到 S2F41 命令后要先执行对应动作再把执行结果封装成 S2F42 回给 Host。这个过程中最容易出的问题是消息层状态和底层状态不同步。我见过一个案例设备端程序收到了 S2F41 的“搬送指令”底层机械手也动作了但由于状态模型没有从“待机”切到“运行”紧接着上位机下发另一条命令时设备端直接拒绝执行。这种问题在 SecsExpress 上单测时不会暴露因为你只测了一条命令联调时要把整条业务链路从头到尾执行一遍观察每一条消息前后设备状态的变化。另外建议在设备程序的调试日志里同步输出底层 PLC 的执行状态。SecsExpress 的报文日志解决“SECS/GEM 消息是否正确”设备程序的日志解决“消息是否真正驱动了设备动作”两者对照起来才能完整还原一条业务指令从 Host 到设备底层再返回的完整链路。6. 最后再聊几点个人使用体会工具再好用也不能替代对协议原理的理解。我用 SecsExpress 这一年多下来最大的体会是它帮我省掉的是“时间”不是“思考”。它能让我在五分钟之内把消息发出去、把报文看清但如果我不知道状态模型、超时机制、Device ID 这些概念我可能连错误日志都读不懂。有一点要提醒大家SecsExpress 的配置文件和环境版本记得随项目做备份。不同版本的 SECS/GEM 工具对消息库的定义可能有差异老项目如果换了电脑、装了新版本可能连 S1F1 的模板都不太一样。我在两个项目之间切换时就遇到过版本不一致导致消息模板对不上的情况。把配置文件导出到项目代码库里联调环境保持一致能少很多麻烦。如果你正准备进入半导体设备自动化领域或者正在被 SECS/GEM 调试折磨我建议你下载 SecsExpress按照上面说的方法先把 S1F1/S1F2 跑通再试着构造一条 S6F11 的事件上报然后用异常注入的方法看看对端怎么反应。这套流程走完你对 SECS/GEM 的认识会比单纯看文档要扎实得多。调试工具解决的是“可见性”问题把看不见的字节流变成看得懂的消息剩下的判断和决策还是得靠人对协议本身的理解。这也是我一直认为测试工具该有的定位——它不应该替你思考而是让你思考得更准确。