简介面向半导体设备通讯调试场景的SECS调试工具资源包内含secsemulator商业版1.83.2主程序支持SECS-I、SECS-II与HSMS-SS协议可读取SML档案适合设备工程师、自动化集成人员以及半导体制造相关技术人员用于验证和调试设备与主机之间的通讯逻辑与消息交互。压缩包共15个文件核心为SECSEmulator.exe可执行程序另配备三个DLL动态链接库、两个SML格式样例、一个XML配置文件、一个LIB库以及七份不同日期的EQ/HT通讯日志整体约421KB结构清晰便于直接部署和对照分析。日志记录来自实际测试过程可作为排查HSMS链路异常、理解SECS会话流程的参考素材。该工具能帮助使用者快速熟悉SML格式、掌握HSMS通讯链路搭建方式并通过导入SML样例快速建立通讯测试环境提升半导体设备联机调试效率。已有1300人学习下载适合需要开展SECS协议开发或设备联调工作的工程师作为辅助工具。1. SECS调试工具把封测设备协议对接从黑匣子变成可复现半导体封测设备上线之前SECS/GEM 协议对接是最容易卡进度的环节。做过 EAP 现场实施的人都清楚真实机台没到场、软件版本临时变更、对方工程师只能远程配合的时候联调工作基本处于停滞状态。SECS调试工具和 secsemulator 这类模拟器解决的就是这个问题它能在没有物理设备的条件下用 HSMS/SECS-I 完整模拟设备端行为反复收发 S1F13、S6F11 这些标准报文把 SECS 会话过程变成可回放、可调参数、可自动回归的测试台。对设备软件工程师、EAP 现场实施与运维人员以及想弄懂 SECS 双向会话机制的新手来说这套东西都是切入协议调试最直接的路径。2. SECS/GEM 调试的底层逻辑双向会话、HSMS 与模拟器选型2.1 先分清承载层SECS-I 串口与 HSMS 以太网调试 SECS 工具之前第一个要搞清的问题是对接的承载层是 SECS-I 还是 HSMS。这个判断直接决定你在模拟器里填 IP 和端口还是配置串口参数。SECS-I 走的是 RS-232 串口物理层决定了它传输慢、报文偏小适合老旧设备或对速率不敏感的环节。在 SECS-I 里报文本身是块传输消息被拆成数据块块与块之间靠块号确认调试时你要盯的是串口号、波特率、数据位、停止位和奇偶校验。说实话现在新建的产线已经很少用 SECS-I 做高频交互它更多出现在改造项目的老机台上。HSMS 也就是 SEMI E37 标准走 TCP/IP 以太网是目前封测设备对接的主力承载方式。它的报文头里有一个 4 字节长度字段网络层直接按照长度字段切分消息不需要像串口那样关心字节间时序。连接建立后主机会周期性发送链路测试消息Link Test用来确认连接是否存活。这个链路测试间隔就是调试工具配置文件里的“Link Test Interval”后面避坑章节会提到这个参数不统一连接反复断连就从这来。选型时的判断标准其实很朴素对方设备支持以太网优先走 HSMS对方只有串口才考虑 SECS-I 桥接。调试工具如果两者都支持会在连接信息里明确标注是 HSMS Active/Passive 还是 SECS-I 串口模式照着实际网络拓扑填就行。2.2 主消息与次消息一个双向会话的调试支点很多人搜“SECS 是单向的还是双向的”其实 SECS-II 消息机制是严格双向的一端发出 Primary Message主消息另一端必须回一个 Secondary Message次消息这个一主一次构成一个事务。没有回包对端就会触发 T3 超时重发或者直接报错。调试工具里最常见的操作就是构造 S1F13 主消息请求建立通信对方回 S1F14 次消息表示接受或拒绝。再比如设备发生状态变化设备端主动发 S6F11 事件上报主消息主机回 S6F12 应答。你会发现工具端的“发一条消息”本质上只是事务的一半真正判断失败与否还要看次消息的返回内容。在 SMLSECS Message Language里主消息和次消息的写法很直观S1F13 W L[3] A[8] SECSSIM A[8] 1.0.0 L[1] A[8] SIMULATOR S1F13 W 表示 stream 1、function 13、W 是 Request 的意思表示这是一条主消息。括号里的内容依次是设备型号名、软件版本号和软修订列表。对应工具在收到 S1F14 后会展示对方回传的 COMMACK 值0 表示通信建立成功1 表示拒绝。调试时如果只看到自己发出去的 S1F13却看不到对端应回的 S1F14基本可以断定问题出在对端处理逻辑或连接通道上。所以要记住一点SECS 调试工具的价值不在于“能发消息”而在于能把主消息、次消息之间的配对关系完整呈现出来。这也是为什么模拟器的报文记录里一般都会用事务 ID 把 S1F13 和 S1F14 关联成一对供你检查。2.3 调试工具常见参数设备 ID、超时定时器与连接模式启动调试工具前有三个参数要确认到位它们也是现场实施时配置单上最常见的字段。设备 IDDevice ID是 SECS 报文头里的 16 位标识代表主机与设备之间的逻辑通道常见取值是 0 到 32767。它跟 IP、端口没有任何换算关系主机和设备两端的设备 ID 必须一致。之前我遇到过一例模拟器里填了 10EAP 配置文件里填的是 0结果 HSMS 连接正常但 S1F13 发出去后对方直接忽略查了大半天才意识到是两个 ID 对不上。超时定时器方面T3 是等待主消息重发时间T5 是 HSMS 连接建立尝试间隔T6 是控制事务超时。调试工具里一般都能手动调整。默认值参考 SEMI 标准但不同设备厂商会微调联调前最好先从对方那里拿到实际配置表。连接模式上HSMS 分 Active 和 Passive。Active 模式是调试工具作为客户端主动去连对方端口Passive 模式是工具监听本地端口等待对方连接。模拟器做设备端时通常选 Passive 监听让 EAP 来连它反过来如果你要用模拟器当主机测试设备就要选 Active。3. secsemulator 搭一套可复现的设备环境配置文件、握手与事件上报3.1 搭建最小配置网络参数与设备模型文件secsemulator 这类模拟器的核心价值是“可复现”而复现的第一步是把网络参数和设备模型写进配置文件而不是每次启动都手填。一个典型的 HSMS 配置段长这样hsms: mode: passive local_ip: 0.0.0.0 local_port: 5000 device_id: 0 link_test_interval: 30 t3_timeout: 45 t5_timeout: 15 t6_timeout: 15 equipment: model_name: CMP-SIM-01 software_version: 1.2.0 device_status: RUN这段配置说明模拟器监听 5000 端口设备 ID 为 0链路测试间隔 30 秒。其中 local_ip 写 0.0.0.0 代表监听本机所有网卡地址现场联调时建议改成实际网卡 IP避免多网卡环境下 EAP 连错地址。t3_timeout 是 45 秒这个值最好大于对端 EAP 的重发间隔否则模拟器容易先报超时。我把参数说明列成一张表方便你照着填参数名作用建议值注意点modeHSMS 主动连接还是被动监听passive设备端模拟器用 passivedevice_idSECS 报文头中的设备标识0与 EAP 配置一致否则握手被忽略link_test_interval链路测试消息发送间隔30 秒必须与主机端预期匹配t3_timeout主消息重发控制时间45 秒小于主机超时设置可能触发假失败配置文件加载后模拟器会先进入监听状态不主动发包。这个阶段你可以通过工具自带的连接状态窗口确认 socket 是否正常监听许多联调失败其实是防火墙拦了端口表现就是工具一直在监听但 EAP 侧总是报连接超时。3.2 完成第一次握手S1F13 请求与 S1F14 确认配置加载完下一步是用模拟器与 EAP 或主机侧建立 SECS 连接。手动操作时相当于工具内部走一遍 S1F13 握手# 模拟器以 passive 模式监听本机 5000 端口 secs-sim --config ./hsms.yaml # 连接建立后手动发送建立通信请求 secs-sim --send s1f13这里 secs-sim 可以理解为模拟器提供的命令行入口--config 指定上面那份 YAML 配置--send s1f13 触发主消息。工具在发出 S1F13 后会把整个消息的二进制区块和 SML 文本同时记录到调试日志里这对后续排查非常有用。收到 S1F14 响应后正常日志应该是这样的INFO connected from 192.168.1.100:5001 INFO send S1F13 W INFO recv S1F14 INFO COMMACK 0COMMACK 为 0 表示设备已成功建立通信。如果你在真实设备上联调对方回复的 S1F14 里还有 MDLN、SOFTREV 两个信息项但模拟器场景下值来自 YAML 配置里的 model_name 和 software_version。第一次握手最容易出现的问题不是报文格式而是工具发了 S1F13 后一直没人应答。这种情况不要去改报文先确认两件事对方是否在被动等待你连接以及设备 ID 是否一致。连接状态正常但握手无响应多半是 ID 不对或对方停留在 Passive 模式等连接。3.3 事件上报链路状态模型、CEID 与 S6F11 触发握手只是开始现场实施里真正高频使用的是 S6F11 事件上报。设备把状态变化、批次开始、异常报警等信息通过 S6F11 发给 EAP这也就是 GEM 标准里的 Collection Event 机制。模拟器里配置一个事件上报需要定义事件 IDCEID和事件附带的数据项。以下是一个典型的 S6F11 消息配置S6F11 W L[2] A[7] RUNNING L[1] L[3] U4[1] 1 A[8] STATE A[4] RUN 这个 SML 里第一层列表装的是 CEID“RUNNING”第二层列表是报告数据。报告数据里包含三个元素事件序号 1、变量名 STATE、变量值 RUN。实际调试时一般不会手写这么底层的 SML模拟器会提供事件配置界面填好 CEID 和变量名后自动生成。模拟器里的事件触发方式通常是“动作绑定”比如定义当设备状态模型切换到 RUN 时自动发 S6F11。你可以在模拟器状态模型里加一个状态迁移条件从 IDLE 切到 RUN 就触发事件。这样测试 EAP 的流程逻辑时只需要在模拟器界面点一下“切换状态”S6F11 就会自动发出比手敲命令更接近真实设备行为。这里给一个最直接的验证思路EAP 收到 S6F11 后如果回应了 S6F12且 COMMACK 为 0说明解析正常。如果 EAP 侧没有反应优先查看 S6F11 里 CEID 是否在 EAP 的事件订阅表里注册过。GEM 协议里EAP 一般通过 S5F1/S5F3 订阅事件模拟器如果没有配置订阅应答EAP 可能直接丢弃后续上报。4. 现场实施避坑四个高频 SECS 调试问题的排查记录4.1 现象一EAP 连接后 30 到 40 秒就断连一次现象EAP 与模拟器的 HSMS 连接建立成功S1F13 握手也完成但每隔 30 秒左右连接就被断开日志里出现 Link Test 超时或远端关闭连接。原因链路测试间隔参数不一致。模拟器配置文件里 link_test_interval 设置的是 30 秒但 EAP 侧配置的链路测试超时阈值小于 30 秒EAP 还没等到模拟器的链路测试消息就先判定连接超时并主动断开。反过来如果模拟器的间隔大于 EAP 的等待窗口同样会被判定超时。解决把两端链路测试间隔调成一致通常的做法是统一取 30 秒或 20 秒并在 EAP 侧把链路超时阈值调成间隔的至少两倍。从那次之后我只要发现连接周期性断连第一反应就是找两端配置文件里的 Link Test 参数不再去翻报文内容。4.2 现象二S6F11 报文的长度字段与内容对不上现象模拟器发送 S6F11 后EAP 侧解析报错报文中显示的字节数与实际内容长度不符甚至出现解析到的变量名乱码。原因典型的手改 SML 后没有重新计算长度字段。SECS-II 报文头里的长度字节表示的是从长度字段后到消息结尾的总字节数SML 压缩成二进制区块后长度由工具自动计算。但如果中间环节有人手动改过二进制区块或者把 SML 从一种编码复制到另一种编码比如 GBK 与 UTF-8 混用长度就会错位。解决不要在二进制报文层面手改长度。所有改动都在 SML 文本层面完成然后让模拟器重新生成二进制区块和长度字段。排查时用模拟器的报文导出功能把十六进制报文和 SML 并排对照重点看 A[...] 里的字符串长度标记与实际字符数是否一致。4.3 现象三S1F13 发出去之后对方连 S1F14 都不回现象工具在 Active 模式下成功连上对方端口S1F13 发送显示成功但迟迟等不到 S1F14 回应直到 T3 超时。原因对方很可能也工作在 Active 模式根本没有端口在监听你的连接。还有一种常见原因是设备 ID 不一致对方收到报文后识别不了这是发给自己的消息直接丢弃。解决先用连接探测工具确认对方端口确实在监听再看对方连接模式。比如 EAP 侧如果是 Passive 模式那么模拟器必须用 Active 去连它如果两边都设成了 Active连接建立了但消息通道没有真正打通。设备 ID 方面把模拟器和 EAP 配置放在一起逐字节对比别只比对十进制数字有些工具会显示十六进制。4.4 现象四模拟器自测正常换成真实机台就解析失败现象同一套流程在 secsemulator 里跑得很顺一换到真实机台EAP 解析 S6F11 就出问题或者某些变量值读不出来。原因真实机台往往会在标准 SECS/GEM 消息里附带厂商自定义的附加字段或者在某些情况下不发送标准 SECS-II 头。模拟器默认按标准实现不会主动去模拟这些“非标”行为于是把问题掩盖了。解决把真实机台抓下来的报文导入模拟器作为新用例让模拟器模仿真实机台的带外行为。具体做法是从真实机台导出一份原始报文日志保存为 SML 格式然后在模拟器里绑定到对应事件。从那以后我每次联调都要求现场抓一份真实报文存档再用模拟器复现不再只依赖模拟器默认行为。5. 进阶把模拟器当回归台用 Lua 脚本固化业务场景模拟器除了临时联调更适合做回归验证。设备软件版本更新、EAP 配置调整之后你不可能每次都找一台真机把流程跑一遍但你可以把之前联调过程中积累的测试场景固化成脚本每次改动后自动重放。secsemulator 这类工具一般会提供脚本接口常见的是 Lua。利用 Lua 可以控制消息收发、状态切换和事件触发-- 模拟设备状态切换到 RUN 并触发 S6F11 local event secs.event.new(RUNNING) event:set_data_item(STATE, RUN) secs.conn:on(connected, function() print([sim] connected, sending S1F13) secs.conn:send(S1F13 W, { SECSSIM, 1.0.0, {SIMULATOR} }) end) secs.conn:on(S6F12, function(msg) print([sim] EAP acked S6F11, COMMACK:, msg:get(COMMACK):value()) end) -- 手动触发事件上报 secs.event.trigger(RUNNING)这段脚本里 on(connected) 是连接建立后的回调send 函数发送 S1F13on(S6F12) 用来捕获 EAP 对 S6F11 的应答。事件触发函数 trigger 会自动组装 S6F11 报文发给 EAP不需要脚本里手工拼消息结构。用这套脚本做回归通常我会设计三层验证第一层只验证握手S1F13 发出后必须收到 COMMACK 为 0 的 S1F14否则直接标红第二层验证事件上报状态切换后 S6F11 发出并在超时时间内收到 S6F12第三层验证数据内容检查事件上报里的 STATE 值是否和期待值一致。三层全部通过才算一次完整的回归。从那以后我每拿到一个新设备型号第一件事不是直接连 EAP而是先用模拟器把设备厂商提供的报文样例导入跑通脚本后再上真实机台。这个习惯省下的现场时间远比搭建脚本花掉的多。希望这些参数和排查思路能帮你在 SECS/GEM 对接上少走几个来回。本文还有配套的精品资源点击获取