简介在半导体制造尤其是晶圆、封装测试等环节中MES系统与设备之间常需按SECS II标准通信数据报文格式是否符合客户规范往往成为联调难点。这套调试工具正面向此类场景可模拟服务端或客户端帮助程序开发、测试人员验证自行编制的报文是否满足客户要求尤其适合上位机软件工程师与设备集成工程师使用。压缩包共4个文件包含可执行程序、两个XML配置/样本文档以及txt使用说明整体约90KB轻量便携可快速部署到联调环境。目前已有2848人学习下载。工具自带默认配置与程序样板文件无需从零搭建即可上手配套说明详细讲解使用方式便于理解服务端/客户端的收发流程和参数配置能显著缩短SECS II通信联调前的自测时间对需要快速验证协议实现或排查通信异常的工程师非常实用。1. SECS-II HSMS 调试工具在设备和主机之间扮演“双方”的模拟器做半导体设备上位机或者 AE 的人大概率都经历过这种场景设备端程序写好了但现场的设备还没到或者主机端Host联调时对方工厂的设备在千里之外你手上只有一个 IP 和端口号。这时候你最需要的不是文档而是一个能在电脑上假装自己是设备、又能假装自己是主机的 HSMS 模拟器。所谓 SECS-II HSMS 调试工具就是把 SECS/GEM 通信里的 Host 和 Equipment 两端都装进一个软件里让你在没有真实硬件的情况下把 S1F13、S6F11、S2F13 这些消息提前调通。这套工具的核心价值有两个一是它把 SECS-I 时代依赖串口的调试方式换成 TCP/IP你只要把 IP、端口、设备 ID 填对就能在局域网里模拟完整通信链路二是它自带样板文件S1F13 建连、S5F1 报警、S6F11 事件上报这些高频消息不用从零拼字节直接改参数就能发。适合三类人刚接触 SECS/GEM 的嵌入式工程师、需要写主机端通信模块的软件开发者、以及做设备验收时被对方主机折磨的现场调试人员。下面我按自己的使用习惯从协议原理讲到实际踩坑把这份资源拆开讲清楚。2. 动手前先把协议对齐HSMS 状态机与 SECS-II 消息编码2.1 HSMS 在哪一层从 SECS-I 到 TCP/IP 的迁移逻辑SECS/GEM 协议族里SECS-I 是走 RS-232 串口的物理传输层波特率 9600 是常态半双工、一收一发调试时还要拿串口线两头接。而 HSMSHigh-Speed SECS Message Services是它的 TCP/IP 替代者SEMI E37 标准里定义了它在 OSI 模型里的位置传输层用 TCP报文层用固定的 4 字节长度前缀加 10 字节消息头再往上才是 SECS-II 的消息体。理解这一点很关键因为很多新手把 HSMS 和 SECS-II 当成同一个东西实际它们是两回事。HSMS 只负责“怎么把一段字节可靠地送给对方”SECS-II 负责“这段字节是什么意思”。模拟器的价值就在于它同时实现了这两层底层帮你管 socket、管 Select 握手、管 Linktest上层帮你编码和解码 SECS-II 的 Data Item。你在界面上看到的“S6F11 已发送”背后是它在 TCP 连接上先发了 Select.req等对方回 Select.rsp 进入 Selected 状态然后把 S6F11 的 body 按 SECS-II 格式码编码最后加上长度前缀和 10 字节头发出。我一般会建议初次使用的人先把 HSMS 的状态机画在纸上一条 TCP 连接建立后初始状态是 Not Selected必须先发 Select.req收到 Select.rsp 后进入 Selected之后才能传数据消息SType0。如果没进 Selected 就想发业务消息对方的协议栈会直接断开连接这是第一个高频翻车点后面避坑章节会细说。2.2 10 字节消息头与 SECS-II 格式码看懂报文才能调出问题HSMS 的数据帧格式很固定每一帧都是“4 字节消息长度 消息本体”消息本体里前 10 字节是消息头。这个 10 字节头结构一定要背下来调试时看日志全靠它。我用 Python 的 struct 演示一下标准打包方式import struct def build_hsms_header(device_id, stream, function, trans_id, waitFalse): # Session ID2字节设备ID写在低15位 session_id device_id 0x7FFF # Header Byte 1最高位W位低7位是Function编号 hbyte1 (0x80 if wait else 0x00) | (function 0x7F) # Header Byte 2Stream编号低7位有效 hbyte2 stream 0x7F # PType0表示SECS-IISType0表示数据消息 header struct.pack(HBBBB I, session_id, hbyte1, hbyte2, 0, 0, trans_id) return header def build_frame(body): message build_hsms_header(1, 6, 11, 0x0001, waitFalse) body return struct.pack(I, len(message)) message这里HBBBB I对应 2 字节 Session ID、4 个单字节字段、4 字节 Transaction ID总共 10 字节。注意 PType0 代表后面跟的是 SECS-II 消息SType0 代表这是数据消息而不是 Select.req 之类的控制消息。如果你在日志里看到 SType 不是 0 却当业务消息解析那报文肯定对不上。SECS-II 的消息体由 Data Item 组成每个 Data Item 的第一个字节是格式码。格式码的高两位表示长度字节数00 表示长度占 1 字节01 表示占 2 字节低六位是数据类型。常用的几个0x01是 LIST、0x05是 BINARY、0x09是 BOOLEAN、0x0D是 U4、0x1D是 I4、0x31是 ASCII。举个例子S6F11 事件报告的第一层一定是 LIST里面包一个事件 ID通常 U4和一个值列表编码是这样的def encode_list(*items): body b.join(items) return bytes([0x01]) bytes([len(items)]) body def encode_i4(value): return struct.pack(Bi, 0x1D, value) def encode_ascii(text): data text.encode(ascii) return bytes([0x31, len(data)]) data注意encode_list里的长度字节目前只处理了小于 255 项的情况如果 LIST 里超过 255 个元素格式码就要用0x41并且长度写两字节。样板文件里常见的消息基本都在单字节长度范围内所以这个简化版本够用但你在自己拼报文的工具里要留个扩展位。2.3 样板文件里的 SxFy 编号为什么 S1F13/S6F11 总被当模板SECS-II 的消息编号是 SxFyStream 表示消息大类Function 表示具体功能。高频出现的就那么几个S1F13 是建立通信请求Establish Communications Request对方回 S1F14 确认S2F13 是变量数据读取请求SVS Request回复 S2F14 带一批数值S5F1 是报警上报回复 S5F2S6F11 是事件报告回复 S6F12还有 S9F1 是“无法识别的消息”错误报告。带样板文件的模拟器等于把这些高频消息的 body 结构提前搭好了你不需要去翻 SEMI E5 文档核对每个字节。比如 S1F13 的 body 在实际实现里很多设备是空的或者只带一个版本号列表但协议栈要求它必须是一个合法 SECS-II 消息样板文件直接给你填好一个空 LIST。这里有一个容易混淆的点SxF0 是 Abort所有 Stream 的 Function0 都保留给中止消息如果调试时收到 SxF0说明对方协议栈认为你上一条消息无法处理。样板文件通常不会放 SxF0因为它通常是运行时动态生成的你要能认出它而不是去模板里找。3. 把模拟器跑起来选边、配参数、导样板、发第一条消息3.1 角色选择Host 模式与 Equipment 模式分别模拟谁这套模拟器打开之后第一步不是配 IP而是选角色。Host 模式模拟工厂的主机系统主动发起 TCP 连接连上之后发 Select.reqEquipment 模式模拟设备端监听一个端口等主机来连。两个角色的报文格式完全一样区别只在于谁主动建连、谁被动等待。我自己的习惯是开发设备端程序时模拟器开成 Host 模式让我的设备程序当服务端反过来开发主机端程序时模拟器开成 Equipment 模式。这样做的好处是你的被测程序始终走真实的“被动接收”或“主动发送”路径而不是靠模拟器帮你代答。如果你只是验证模拟器本身能不能跑通那就开一个 Host 一个 Equipment让它俩自己连。有一点要提醒同一个模拟器实例通常只能选一个角色两个角色要开两个实例一个监听端口一个作为客户端去连。别在界面上找“同时模拟双方”的开关这个工具的设计逻辑是每个实例一条连接。3.2 连接参数配置IP、端口、设备 ID、Linktest 间隔连接参数是翻车重灾区尤其设备 ID 这一项。Host 模式下你要填目标 IP、端口典型值是 5000 或 7777SEMI E37 没有强制但现场用的最多是 5000以及本端设备 IDEquipment 模式下只要填监听端口和设备 ID。设备 ID 在 HSMS 里占 Session ID 的低 15 位取值一般是 0 到 327670 是默认的未注册设备。Linktest 间隔也要顺手设置标准建议值是 45 秒。它的作用是保活探测如果 45 秒没有任何消息主动方发一条 SType9 的 Linktest.req对端必须回 SType10 的 Linktest.rsp。这个间隔设得太短比如 5 秒会频繁打断业务消息太长比如 10 分钟又可能被中间防火墙判定空闲断开。现场联调时我一般先设 45 秒等确认链路稳定再调长。3.3 导入样板文件拆解一条 S1F13 从点击到上线的过程样板文件通常在模拟器的“消息模板”面板里以树的形势列出 S1F13、S1F14、S5F1、S6F11 等。双击一条模板会展开它的完整结构包括 Stream、Function、W 位、消息体层级。以 S1F13 为例它的标准流程是你先在 Equipment 模式实例上点击“发送 S1F13”模拟器自动完成 TCP 连接、Select 握手然后发送 S1F13 数据消息对端你的 Host 程序回 S1F14 后模拟器把回执显示在日志里。这一步最容易看错的是 W 位。S1F13 是要求回复的消息所以 W 位必须为 1即 Header Byte 1 的最高位是 1。如果你用自带模板软件会正确处理但如果你是自己新建消息W 位 0/1 搞反对端会认为这是一条不需要回复的消息从而不给你回 S1F14你就永远等不到建连确认。我一般会在导入模板后先看消息头的字节预览确认 W 位状态再点击发送。# 模拟器一般提供消息字节导出的功能 # 导出后的报文文件长这样前缀 10字节头 body # 一个典型 S1F13 帧hex # 00 00 00 0A - 消息长度 10 字节此时 body 为空 # 00 01 - Session ID / Device ID 1 # 8D - W1, Function13 (0x0D) # 01 - Stream1 # 00 - PType0 # 00 - SType0数据消息 # 00 00 00 01 - Transaction ID 1上面这个 10 字节消息头里注意8D这个值最高位是 1 表示 W 位低七位 0x0D 就是 Function 13Stream 是 1所以这条就是 S1F13。你如果哪天在抓包工具里看到00 00 00 0A 00 01 8D 01 00 00 00 00 00 01不用翻协议文档按这个结构拆就能认出来。3.4 日志窗口怎么看从 TCP 帧到 SECS-II 消息的逐级核对模拟器的日志窗口一般分两层一层是 TCP 层显示连接建立、断开、字节数统计一层是 HSMS/SECS-II 层显示已经解析好的消息编号。真正的调试高手只做一件事先看 TCP 层有没有异常连接被拒、半开连接、连接复用再看 HSMS 层状态是否 Selected、Linktest 是否正常最后才看业务消息内容。顺序不能反。很多朋友一上来就盯 SECS-II 的 body结果发现 S6F11 里的数据项都对但对方就是没反应回头看 TCP 层才知道连接根本没进 Selected业务消息压根发不出去。日志窗口还有个细节大部分模拟器在收到无法解析的 SECS-II 消息时会把它当原始字节显示而不是抛错误这是故意设计的为了让你能手工核对长度字段。如果看到日志里 Hex 区有一长串FF FF或者长度异常十有八九是消息长度前缀字节序写反了这在避坑章第一条会细讲。4. 双向调试实战用模拟器把 S2F13 和 S6F11 来回打通4.1 Host 侧发起 S2F13变量读取请求是怎么组织的S2F13 是主机向设备请求变量数据的标准消息常在设备上电初始化时用来同步状态。它的 body 是一个 LIST里面放一堆要读取的变量 IDVID每个 VID 通常是 U4 类型。假设你要读设备的温度和腔体压力两个变量VID 分别是 1001 和 1002那么 S2F13 的 body 编码如下import struct def encode_u4(value): return struct.pack(BI, 0x0D, value) vid_list encode_list( encode_u4(1001), encode_u4(1002) ) body encode_list(vid_list) print(body.hex()) # 输出示例01 01 01 02 0d 00 00 03 e9 0d 00 00 03 ea这里最外层 LIST 只有一项这一项又是一个 LIST里面是两个 U4。之所以套两层是因为 SECS-II 规范里 S2F13 的根节点定义就是 ListList 很多设备的协议栈强制按这个层级解少套一层就可能触发 S9F1。用模拟器发这条消息时直接在模板库找 S2F13把 VID 值改成 1001、1002点击发送然后等待 Equipment 模式的回包 S2F14。S2F14 的 body 结构是 ListVID, Value 的集合每个 ID 对应一个值。调试时注意如果回包里 VID 的顺序和请求不一致很多设备协议栈是按请求顺序回但模拟器并不保证所以你的解析代码不要假设顺序一致按 VID 匹配更稳妥。这点在真实设备上尤其重要某厂商的设备就喜欢把回包里的 VID 排序后返回和请求顺序完全不一样。4.2 Equipment 侧上报 S6F11事件报告的 body 该怎么拼S6F11 是设备主动上报事件的常用消息比如晶圆完成、腔体开门、报警恢复都会触发。它的 body 根节点是 LIST第一项是事件 IDU4第二项是数据值列表LIST。模拟器自带的 S6F11 模板里事件 ID 一般预置成 1000数据列表里放了几个占位变量。把你的事件 ID 替换上去再按实际变量数量增减数据项def build_s6f11_body(event_id, values): # 第一层事件 ID 数据值列表 item_count len(values) value_items [encode_i4(v) for v in values] return encode_list( encode_u4(event_id), encode_list(*value_items) # 注意这里还有一层List )这段代码最容易写错的是把encode_list(*value_items)省略成encode_u4(values[0])。S6F11 规范要求第二项必须是一个数据值列表哪怕只有一个值也要包一层 LIST否则对端协议栈解析到第二项时类型对不上会直接回 S6F12 带错误码或者在更严格的设备上直接报 S9F1。模拟器里发完这条之后Host 模式一侧应该回 S6F12ack 字段一般是 0表示接受。如果你在 Host 模式的回包里看到非 0 的 ack说明对方认为你上报的事件 ID 未定义或者数据项数量不对需要回设备端检查事件报告的配置。4.3 Transaction ID 与回复匹配一次请求对一次应答Transaction ID 是 4 字节整数用来关联请求和回复。规则一句话请求方发出的数据消息带一个事务 ID应答方回消息时必须带着完全相同的事务 ID。用模拟器做双向调试时你会在日志里看到这样的成对记录你发 S2F13 时事务 ID 假设是 5对端回 S2F14 时事务 ID 也必须是 5这个编号在你下一次发起新请求时递增或手工改动。初学者最容易犯的错是打开两个模板同时发送结果把事务 ID 搞混。模拟器通常有个“自动递增”选项建议干掉它改用固定值一条一条地调试。举个例子你先发 S1F13 用事务 ID 1再发 S2F13 时如果还停留在事务 ID 1第一次的 S1F14 回包管它叫 S1F13 的回执还是 S2F13 的回执就看日志右下角的解析结果了。这个状态一旦混乱你只能断开重连因为协议栈对同一事务 ID 的第二次请求很多直接忽略。事务 ID 还有一个坑是符号位。有些协议栈把 Transaction ID 当无符号整数处理有些当有符号如果你的值超过 0x7FFFFFFF对端解析出来可能变成一个负数日志里显示为-123456之类查半天查不到原因。所以我建议调试阶段事务 ID 永远用小于 0x7FFFFFFF 的值优先从 1 开始递增。5. 避坑与常见问题HSMS 调试里六个高频翻车点5.1 Select 握手没完成就发数据对方直接断开现象模拟器显示 TCP 已连接你立刻发了一条 S1F13结果对端端口无响应几秒后日志显示连接被关闭。 原因TCP 连接建立只代表传输层通了HSMS 还要求先完成 Select 握手。对端协议栈在状态机还是 Not Selected 时收到 SType0 的数据消息直接判为非法断开连接。 解决把 Select.req/Select.rsp 的握手当成 TCP 连接的一部分看待发送业务消息前先检查日志里状态是否为 Selected。模拟器菜单里的“自动握手”选项要保持开启如果你是手工发 Select.req注意它的事务 ID 用 0且 SType 要填 1。5.2 消息长度字段算错多一万字节或丢一帧现象对端日志显示收到的消息长度是 65530 或者负值消息体内容完全对不上。 原因HSMS 帧前面的 4 字节长度是按网络字节序大端写的如果按小端发送长度全反了。另一个常见错误是把“消息本体的长度”算成了“包括长度前缀的总长度”常见做法也是导致缓冲溢出。 解决记住长度字段只包含消息头加 body不含那 4 字节本身。写代码时用struct.pack(I, len(header) len(body))别手算。验证时看模拟器日志里“接收字节数”和帧长度是否吻合两者差 4 字节就是前缀算进去了。5.3 Device ID 和 Session ID 混用S9F1 回得莫名其妙现象发出去的消息对端回了一条 S9F1 Unrecognized Device ID但设备 ID 明明在配置里填了。 原因HSMS 头里的 Session ID 确实和 Device ID 相关但不是一回事。Session ID 的低 15 位是设备 ID但有的设备要求高位置 1 表示某个会话语义一些协议栈对此很敏感。 解决先用最简单配置把设备 ID 填成 0 或 1别用超过 32767 的“自定义编号”。同时检查模拟器界面上有没有单独的 Session ID 显示如果它和 Device ID 不一致以 Session ID 的实际字节为准。另一点注意回包里 S9F1 自带一条 ASCII 描述里面的 Stream/Function 编号指的是你发的那条消息不是错误代码本身。5.4 W 位语义搞反把事件通知做成等待回复现象S6F11 事件上报之后对方一直没回 S6F12或者设备端一直卡在等回复状态。 原因W 位1 时表示“本条消息需要回复”W 位0 表示“不需要回复”。如果把 S6F11 的 W 位设成 0对端认为你不需要 ack自然不会回 S6F12反过来把 S6F11 设成 1对端会认为你在等它的回复并开始超时计时。 解决按消息类型而不是业务习惯设置。S6F11 的标准 W 位是 0S1F13、S2F13 是 1。如果你不确定去看样板文件里这条消息的 W 位默认值然后保持一致。调试时最直观的特征如果日志显示你发出去的帧头第一个字节小于 0x80说明 W 位是 0不需要回包如果大于等于 0x80说明需要回包。5.5 Linktest.req 被当 SECS-II 数据消息解析现象模拟器日志里时不时莫名其妙出现一条 Stream/Function 都识别不了的消息而且时间间隔固定。 原因Linktest 消息的 SType 是 9 或 10不是 0。如果你的解析代码把 SType 忽略只按数据消息去解析它的 Header Byte 1 和 Byte 2得到的 Stream/Function 是乱值。 解决解析时先看 10 字节头里的 SType 字段不是 0 就按控制消息处理。模拟器一般会正确显示“Linktest.req”文本而不是数字如果你在日志里看到一条奇怪消息伴随 TCP 连接随后断开优先怀疑对端没实现 Linktest 响应去查对端的保活配置。这一步标准做法是收到 Linktest.req 必须回 Linktest.rsp否则对端会关闭连接。5.6 样板文件占位符没替换日志里全是乱码项现象模板里有几个字符串变量你直接点了发送对方回 S9F1 或者显示的数据和解码表对不上。 原因样板文件里的值经常是占位符比如把设备名写成了“AAAA”、把版本号写成“00.00”。这些数据按 ASCII 发出去对端读到的就是真实字符串“AAAA”如果你的设备名校验逻辑认不出来会直接 reject。 解决发送前养成检查模板变量的习惯。我一般会在导入模板后用“查找替换”把常见占位符批量换掉AAAA/XXXX/00.00这种一律改成真实值。替换完点击“重新编码”按钮看日志里 hex 区的 ASCII 部分是否已经变成你的字符串再发送。6. 把样板文件改成自己的 S6F11 事件模板一套可复用的技法6.1 三步改模板改事件 ID、改数据项、替换格式码样板文件只是起点真实设备的事件各式各样你要学会把它改成自己的。以 S6F11 为例我固定走三步第一步把事件 ID 从模板默认值改成你设备事件表里定义好的编号比如 3001 代表“Process Done”第二步按设备实际需要把数据值列表里的变量改成对应的 VID 和类型温度是 F4压力是 F4计时器是 U4状态标志用 BOOLEAN第三步检查格式码如果模板里某个数据项是 I4 而你的变量是 U4一定要改格式码否则对端按有符号数解析负值会变成巨大正整数。修改格式码的细节SECS-II 里 I4 和 U4 只是格式码不同I4 的格式码是0x1DU4 是0x0D。如果你在模板界面上看到一个数据项类型显示“I4”而你确认设备端定义是“U4”点开它的属性下拉框把它改成“U4”再保存。这步不用改代码但如果你在自研工具里拼消息就得改 struct 的格式符B i变成B I。改完以后保存为新的模板文件命名时加上设备型号前缀比如“某设备_ProcessDone_S6F11”这样后面换了设备不至于找不到原始定义。6.2 用模拟器做回归对比同一个模板发两遍测试模板改完之后我会在模拟器里做一个低成本回归把改好的 S6F11 模板连着发两遍一遍给模拟器自带的 Host 解析器收一遍抓包后用脚本解析。第一遍是验证模拟器本身认不认这条消息第二遍是验证第三方解析器认不认。如果两遍结果一致说明模板结构正确可以拿到真实设备上用。发两遍的目的很直白排除模拟器“过分友好”的解析。有些模拟器在解析 SECS-II 时容忍了格式码不匹配比如把 I4 当 U4 解但真实设备的协议栈很严格这种容错会掩盖模板问题。我踩过一次这样的翻车模拟器里事件上报一切正常拿到现场设备上对方直接拒绝后来逐字节对比才发现是某个数据项格式码写错模拟器给放过了设备没放过。从那以后我每次改完模板都强制走一遍双端验证先看回包 ack 是不是 0再看抓包解析的字节与你预期是不是完全一致最后才写提交记录。希望这个习惯能帮你在联调现场少熬几个夜。本文还有配套的精品资源点击获取
简介在半导体制造尤其是晶圆、封装测试等环节中MES系统与设备之间常需按SECS II标准通信数据报文格式是否符合客户规范往往成为联调难点。这套调试工具正面向此类场景可模拟服务端或客户端帮助程序开发、测试人员验证自行编制的报文是否满足客户要求尤其适合上位机软件工程师与设备集成工程师使用。压缩包共4个文件包含可执行程序、两个XML配置/样本文档以及txt使用说明整体约90KB轻量便携可快速部署到联调环境。目前已有2848人学习下载。工具自带默认配置与程序样板文件无需从零搭建即可上手配套说明详细讲解使用方式便于理解服务端/客户端的收发流程和参数配置能显著缩短SECS II通信联调前的自测时间对需要快速验证协议实现或排查通信异常的工程师非常实用。1. SECS-II HSMS 调试工具在设备和主机之间扮演“双方”的模拟器做半导体设备上位机或者 AE 的人大概率都经历过这种场景设备端程序写好了但现场的设备还没到或者主机端Host联调时对方工厂的设备在千里之外你手上只有一个 IP 和端口号。这时候你最需要的不是文档而是一个能在电脑上假装自己是设备、又能假装自己是主机的 HSMS 模拟器。所谓 SECS-II HSMS 调试工具就是把 SECS/GEM 通信里的 Host 和 Equipment 两端都装进一个软件里让你在没有真实硬件的情况下把 S1F13、S6F11、S2F13 这些消息提前调通。这套工具的核心价值有两个一是它把 SECS-I 时代依赖串口的调试方式换成 TCP/IP你只要把 IP、端口、设备 ID 填对就能在局域网里模拟完整通信链路二是它自带样板文件S1F13 建连、S5F1 报警、S6F11 事件上报这些高频消息不用从零拼字节直接改参数就能发。适合三类人刚接触 SECS/GEM 的嵌入式工程师、需要写主机端通信模块的软件开发者、以及做设备验收时被对方主机折磨的现场调试人员。下面我按自己的使用习惯从协议原理讲到实际踩坑把这份资源拆开讲清楚。2. 动手前先把协议对齐HSMS 状态机与 SECS-II 消息编码2.1 HSMS 在哪一层从 SECS-I 到 TCP/IP 的迁移逻辑SECS/GEM 协议族里SECS-I 是走 RS-232 串口的物理传输层波特率 9600 是常态半双工、一收一发调试时还要拿串口线两头接。而 HSMSHigh-Speed SECS Message Services是它的 TCP/IP 替代者SEMI E37 标准里定义了它在 OSI 模型里的位置传输层用 TCP报文层用固定的 4 字节长度前缀加 10 字节消息头再往上才是 SECS-II 的消息体。理解这一点很关键因为很多新手把 HSMS 和 SECS-II 当成同一个东西实际它们是两回事。HSMS 只负责“怎么把一段字节可靠地送给对方”SECS-II 负责“这段字节是什么意思”。模拟器的价值就在于它同时实现了这两层底层帮你管 socket、管 Select 握手、管 Linktest上层帮你编码和解码 SECS-II 的 Data Item。你在界面上看到的“S6F11 已发送”背后是它在 TCP 连接上先发了 Select.req等对方回 Select.rsp 进入 Selected 状态然后把 S6F11 的 body 按 SECS-II 格式码编码最后加上长度前缀和 10 字节头发出。我一般会建议初次使用的人先把 HSMS 的状态机画在纸上一条 TCP 连接建立后初始状态是 Not Selected必须先发 Select.req收到 Select.rsp 后进入 Selected之后才能传数据消息SType0。如果没进 Selected 就想发业务消息对方的协议栈会直接断开连接这是第一个高频翻车点后面避坑章节会细说。2.2 10 字节消息头与 SECS-II 格式码看懂报文才能调出问题HSMS 的数据帧格式很固定每一帧都是“4 字节消息长度 消息本体”消息本体里前 10 字节是消息头。这个 10 字节头结构一定要背下来调试时看日志全靠它。我用 Python 的 struct 演示一下标准打包方式import struct def build_hsms_header(device_id, stream, function, trans_id, waitFalse): # Session ID2字节设备ID写在低15位 session_id device_id 0x7FFF # Header Byte 1最高位W位低7位是Function编号 hbyte1 (0x80 if wait else 0x00) | (function 0x7F) # Header Byte 2Stream编号低7位有效 hbyte2 stream 0x7F # PType0表示SECS-IISType0表示数据消息 header struct.pack(HBBBB I, session_id, hbyte1, hbyte2, 0, 0, trans_id) return header def build_frame(body): message build_hsms_header(1, 6, 11, 0x0001, waitFalse) body return struct.pack(I, len(message)) message这里HBBBB I对应 2 字节 Session ID、4 个单字节字段、4 字节 Transaction ID总共 10 字节。注意 PType0 代表后面跟的是 SECS-II 消息SType0 代表这是数据消息而不是 Select.req 之类的控制消息。如果你在日志里看到 SType 不是 0 却当业务消息解析那报文肯定对不上。SECS-II 的消息体由 Data Item 组成每个 Data Item 的第一个字节是格式码。格式码的高两位表示长度字节数00 表示长度占 1 字节01 表示占 2 字节低六位是数据类型。常用的几个0x01是 LIST、0x05是 BINARY、0x09是 BOOLEAN、0x0D是 U4、0x1D是 I4、0x31是 ASCII。举个例子S6F11 事件报告的第一层一定是 LIST里面包一个事件 ID通常 U4和一个值列表编码是这样的def encode_list(*items): body b.join(items) return bytes([0x01]) bytes([len(items)]) body def encode_i4(value): return struct.pack(Bi, 0x1D, value) def encode_ascii(text): data text.encode(ascii) return bytes([0x31, len(data)]) data注意encode_list里的长度字节目前只处理了小于 255 项的情况如果 LIST 里超过 255 个元素格式码就要用0x41并且长度写两字节。样板文件里常见的消息基本都在单字节长度范围内所以这个简化版本够用但你在自己拼报文的工具里要留个扩展位。2.3 样板文件里的 SxFy 编号为什么 S1F13/S6F11 总被当模板SECS-II 的消息编号是 SxFyStream 表示消息大类Function 表示具体功能。高频出现的就那么几个S1F13 是建立通信请求Establish Communications Request对方回 S1F14 确认S2F13 是变量数据读取请求SVS Request回复 S2F14 带一批数值S5F1 是报警上报回复 S5F2S6F11 是事件报告回复 S6F12还有 S9F1 是“无法识别的消息”错误报告。带样板文件的模拟器等于把这些高频消息的 body 结构提前搭好了你不需要去翻 SEMI E5 文档核对每个字节。比如 S1F13 的 body 在实际实现里很多设备是空的或者只带一个版本号列表但协议栈要求它必须是一个合法 SECS-II 消息样板文件直接给你填好一个空 LIST。这里有一个容易混淆的点SxF0 是 Abort所有 Stream 的 Function0 都保留给中止消息如果调试时收到 SxF0说明对方协议栈认为你上一条消息无法处理。样板文件通常不会放 SxF0因为它通常是运行时动态生成的你要能认出它而不是去模板里找。3. 把模拟器跑起来选边、配参数、导样板、发第一条消息3.1 角色选择Host 模式与 Equipment 模式分别模拟谁这套模拟器打开之后第一步不是配 IP而是选角色。Host 模式模拟工厂的主机系统主动发起 TCP 连接连上之后发 Select.reqEquipment 模式模拟设备端监听一个端口等主机来连。两个角色的报文格式完全一样区别只在于谁主动建连、谁被动等待。我自己的习惯是开发设备端程序时模拟器开成 Host 模式让我的设备程序当服务端反过来开发主机端程序时模拟器开成 Equipment 模式。这样做的好处是你的被测程序始终走真实的“被动接收”或“主动发送”路径而不是靠模拟器帮你代答。如果你只是验证模拟器本身能不能跑通那就开一个 Host 一个 Equipment让它俩自己连。有一点要提醒同一个模拟器实例通常只能选一个角色两个角色要开两个实例一个监听端口一个作为客户端去连。别在界面上找“同时模拟双方”的开关这个工具的设计逻辑是每个实例一条连接。3.2 连接参数配置IP、端口、设备 ID、Linktest 间隔连接参数是翻车重灾区尤其设备 ID 这一项。Host 模式下你要填目标 IP、端口典型值是 5000 或 7777SEMI E37 没有强制但现场用的最多是 5000以及本端设备 IDEquipment 模式下只要填监听端口和设备 ID。设备 ID 在 HSMS 里占 Session ID 的低 15 位取值一般是 0 到 327670 是默认的未注册设备。Linktest 间隔也要顺手设置标准建议值是 45 秒。它的作用是保活探测如果 45 秒没有任何消息主动方发一条 SType9 的 Linktest.req对端必须回 SType10 的 Linktest.rsp。这个间隔设得太短比如 5 秒会频繁打断业务消息太长比如 10 分钟又可能被中间防火墙判定空闲断开。现场联调时我一般先设 45 秒等确认链路稳定再调长。3.3 导入样板文件拆解一条 S1F13 从点击到上线的过程样板文件通常在模拟器的“消息模板”面板里以树的形势列出 S1F13、S1F14、S5F1、S6F11 等。双击一条模板会展开它的完整结构包括 Stream、Function、W 位、消息体层级。以 S1F13 为例它的标准流程是你先在 Equipment 模式实例上点击“发送 S1F13”模拟器自动完成 TCP 连接、Select 握手然后发送 S1F13 数据消息对端你的 Host 程序回 S1F14 后模拟器把回执显示在日志里。这一步最容易看错的是 W 位。S1F13 是要求回复的消息所以 W 位必须为 1即 Header Byte 1 的最高位是 1。如果你用自带模板软件会正确处理但如果你是自己新建消息W 位 0/1 搞反对端会认为这是一条不需要回复的消息从而不给你回 S1F14你就永远等不到建连确认。我一般会在导入模板后先看消息头的字节预览确认 W 位状态再点击发送。# 模拟器一般提供消息字节导出的功能 # 导出后的报文文件长这样前缀 10字节头 body # 一个典型 S1F13 帧hex # 00 00 00 0A - 消息长度 10 字节此时 body 为空 # 00 01 - Session ID / Device ID 1 # 8D - W1, Function13 (0x0D) # 01 - Stream1 # 00 - PType0 # 00 - SType0数据消息 # 00 00 00 01 - Transaction ID 1上面这个 10 字节消息头里注意8D这个值最高位是 1 表示 W 位低七位 0x0D 就是 Function 13Stream 是 1所以这条就是 S1F13。你如果哪天在抓包工具里看到00 00 00 0A 00 01 8D 01 00 00 00 00 00 01不用翻协议文档按这个结构拆就能认出来。3.4 日志窗口怎么看从 TCP 帧到 SECS-II 消息的逐级核对模拟器的日志窗口一般分两层一层是 TCP 层显示连接建立、断开、字节数统计一层是 HSMS/SECS-II 层显示已经解析好的消息编号。真正的调试高手只做一件事先看 TCP 层有没有异常连接被拒、半开连接、连接复用再看 HSMS 层状态是否 Selected、Linktest 是否正常最后才看业务消息内容。顺序不能反。很多朋友一上来就盯 SECS-II 的 body结果发现 S6F11 里的数据项都对但对方就是没反应回头看 TCP 层才知道连接根本没进 Selected业务消息压根发不出去。日志窗口还有个细节大部分模拟器在收到无法解析的 SECS-II 消息时会把它当原始字节显示而不是抛错误这是故意设计的为了让你能手工核对长度字段。如果看到日志里 Hex 区有一长串FF FF或者长度异常十有八九是消息长度前缀字节序写反了这在避坑章第一条会细讲。4. 双向调试实战用模拟器把 S2F13 和 S6F11 来回打通4.1 Host 侧发起 S2F13变量读取请求是怎么组织的S2F13 是主机向设备请求变量数据的标准消息常在设备上电初始化时用来同步状态。它的 body 是一个 LIST里面放一堆要读取的变量 IDVID每个 VID 通常是 U4 类型。假设你要读设备的温度和腔体压力两个变量VID 分别是 1001 和 1002那么 S2F13 的 body 编码如下import struct def encode_u4(value): return struct.pack(BI, 0x0D, value) vid_list encode_list( encode_u4(1001), encode_u4(1002) ) body encode_list(vid_list) print(body.hex()) # 输出示例01 01 01 02 0d 00 00 03 e9 0d 00 00 03 ea这里最外层 LIST 只有一项这一项又是一个 LIST里面是两个 U4。之所以套两层是因为 SECS-II 规范里 S2F13 的根节点定义就是 ListList 很多设备的协议栈强制按这个层级解少套一层就可能触发 S9F1。用模拟器发这条消息时直接在模板库找 S2F13把 VID 值改成 1001、1002点击发送然后等待 Equipment 模式的回包 S2F14。S2F14 的 body 结构是 ListVID, Value 的集合每个 ID 对应一个值。调试时注意如果回包里 VID 的顺序和请求不一致很多设备协议栈是按请求顺序回但模拟器并不保证所以你的解析代码不要假设顺序一致按 VID 匹配更稳妥。这点在真实设备上尤其重要某厂商的设备就喜欢把回包里的 VID 排序后返回和请求顺序完全不一样。4.2 Equipment 侧上报 S6F11事件报告的 body 该怎么拼S6F11 是设备主动上报事件的常用消息比如晶圆完成、腔体开门、报警恢复都会触发。它的 body 根节点是 LIST第一项是事件 IDU4第二项是数据值列表LIST。模拟器自带的 S6F11 模板里事件 ID 一般预置成 1000数据列表里放了几个占位变量。把你的事件 ID 替换上去再按实际变量数量增减数据项def build_s6f11_body(event_id, values): # 第一层事件 ID 数据值列表 item_count len(values) value_items [encode_i4(v) for v in values] return encode_list( encode_u4(event_id), encode_list(*value_items) # 注意这里还有一层List )这段代码最容易写错的是把encode_list(*value_items)省略成encode_u4(values[0])。S6F11 规范要求第二项必须是一个数据值列表哪怕只有一个值也要包一层 LIST否则对端协议栈解析到第二项时类型对不上会直接回 S6F12 带错误码或者在更严格的设备上直接报 S9F1。模拟器里发完这条之后Host 模式一侧应该回 S6F12ack 字段一般是 0表示接受。如果你在 Host 模式的回包里看到非 0 的 ack说明对方认为你上报的事件 ID 未定义或者数据项数量不对需要回设备端检查事件报告的配置。4.3 Transaction ID 与回复匹配一次请求对一次应答Transaction ID 是 4 字节整数用来关联请求和回复。规则一句话请求方发出的数据消息带一个事务 ID应答方回消息时必须带着完全相同的事务 ID。用模拟器做双向调试时你会在日志里看到这样的成对记录你发 S2F13 时事务 ID 假设是 5对端回 S2F14 时事务 ID 也必须是 5这个编号在你下一次发起新请求时递增或手工改动。初学者最容易犯的错是打开两个模板同时发送结果把事务 ID 搞混。模拟器通常有个“自动递增”选项建议干掉它改用固定值一条一条地调试。举个例子你先发 S1F13 用事务 ID 1再发 S2F13 时如果还停留在事务 ID 1第一次的 S1F14 回包管它叫 S1F13 的回执还是 S2F13 的回执就看日志右下角的解析结果了。这个状态一旦混乱你只能断开重连因为协议栈对同一事务 ID 的第二次请求很多直接忽略。事务 ID 还有一个坑是符号位。有些协议栈把 Transaction ID 当无符号整数处理有些当有符号如果你的值超过 0x7FFFFFFF对端解析出来可能变成一个负数日志里显示为-123456之类查半天查不到原因。所以我建议调试阶段事务 ID 永远用小于 0x7FFFFFFF 的值优先从 1 开始递增。5. 避坑与常见问题HSMS 调试里六个高频翻车点5.1 Select 握手没完成就发数据对方直接断开现象模拟器显示 TCP 已连接你立刻发了一条 S1F13结果对端端口无响应几秒后日志显示连接被关闭。 原因TCP 连接建立只代表传输层通了HSMS 还要求先完成 Select 握手。对端协议栈在状态机还是 Not Selected 时收到 SType0 的数据消息直接判为非法断开连接。 解决把 Select.req/Select.rsp 的握手当成 TCP 连接的一部分看待发送业务消息前先检查日志里状态是否为 Selected。模拟器菜单里的“自动握手”选项要保持开启如果你是手工发 Select.req注意它的事务 ID 用 0且 SType 要填 1。5.2 消息长度字段算错多一万字节或丢一帧现象对端日志显示收到的消息长度是 65530 或者负值消息体内容完全对不上。 原因HSMS 帧前面的 4 字节长度是按网络字节序大端写的如果按小端发送长度全反了。另一个常见错误是把“消息本体的长度”算成了“包括长度前缀的总长度”常见做法也是导致缓冲溢出。 解决记住长度字段只包含消息头加 body不含那 4 字节本身。写代码时用struct.pack(I, len(header) len(body))别手算。验证时看模拟器日志里“接收字节数”和帧长度是否吻合两者差 4 字节就是前缀算进去了。5.3 Device ID 和 Session ID 混用S9F1 回得莫名其妙现象发出去的消息对端回了一条 S9F1 Unrecognized Device ID但设备 ID 明明在配置里填了。 原因HSMS 头里的 Session ID 确实和 Device ID 相关但不是一回事。Session ID 的低 15 位是设备 ID但有的设备要求高位置 1 表示某个会话语义一些协议栈对此很敏感。 解决先用最简单配置把设备 ID 填成 0 或 1别用超过 32767 的“自定义编号”。同时检查模拟器界面上有没有单独的 Session ID 显示如果它和 Device ID 不一致以 Session ID 的实际字节为准。另一点注意回包里 S9F1 自带一条 ASCII 描述里面的 Stream/Function 编号指的是你发的那条消息不是错误代码本身。5.4 W 位语义搞反把事件通知做成等待回复现象S6F11 事件上报之后对方一直没回 S6F12或者设备端一直卡在等回复状态。 原因W 位1 时表示“本条消息需要回复”W 位0 表示“不需要回复”。如果把 S6F11 的 W 位设成 0对端认为你不需要 ack自然不会回 S6F12反过来把 S6F11 设成 1对端会认为你在等它的回复并开始超时计时。 解决按消息类型而不是业务习惯设置。S6F11 的标准 W 位是 0S1F13、S2F13 是 1。如果你不确定去看样板文件里这条消息的 W 位默认值然后保持一致。调试时最直观的特征如果日志显示你发出去的帧头第一个字节小于 0x80说明 W 位是 0不需要回包如果大于等于 0x80说明需要回包。5.5 Linktest.req 被当 SECS-II 数据消息解析现象模拟器日志里时不时莫名其妙出现一条 Stream/Function 都识别不了的消息而且时间间隔固定。 原因Linktest 消息的 SType 是 9 或 10不是 0。如果你的解析代码把 SType 忽略只按数据消息去解析它的 Header Byte 1 和 Byte 2得到的 Stream/Function 是乱值。 解决解析时先看 10 字节头里的 SType 字段不是 0 就按控制消息处理。模拟器一般会正确显示“Linktest.req”文本而不是数字如果你在日志里看到一条奇怪消息伴随 TCP 连接随后断开优先怀疑对端没实现 Linktest 响应去查对端的保活配置。这一步标准做法是收到 Linktest.req 必须回 Linktest.rsp否则对端会关闭连接。5.6 样板文件占位符没替换日志里全是乱码项现象模板里有几个字符串变量你直接点了发送对方回 S9F1 或者显示的数据和解码表对不上。 原因样板文件里的值经常是占位符比如把设备名写成了“AAAA”、把版本号写成“00.00”。这些数据按 ASCII 发出去对端读到的就是真实字符串“AAAA”如果你的设备名校验逻辑认不出来会直接 reject。 解决发送前养成检查模板变量的习惯。我一般会在导入模板后用“查找替换”把常见占位符批量换掉AAAA/XXXX/00.00这种一律改成真实值。替换完点击“重新编码”按钮看日志里 hex 区的 ASCII 部分是否已经变成你的字符串再发送。6. 把样板文件改成自己的 S6F11 事件模板一套可复用的技法6.1 三步改模板改事件 ID、改数据项、替换格式码样板文件只是起点真实设备的事件各式各样你要学会把它改成自己的。以 S6F11 为例我固定走三步第一步把事件 ID 从模板默认值改成你设备事件表里定义好的编号比如 3001 代表“Process Done”第二步按设备实际需要把数据值列表里的变量改成对应的 VID 和类型温度是 F4压力是 F4计时器是 U4状态标志用 BOOLEAN第三步检查格式码如果模板里某个数据项是 I4 而你的变量是 U4一定要改格式码否则对端按有符号数解析负值会变成巨大正整数。修改格式码的细节SECS-II 里 I4 和 U4 只是格式码不同I4 的格式码是0x1DU4 是0x0D。如果你在模板界面上看到一个数据项类型显示“I4”而你确认设备端定义是“U4”点开它的属性下拉框把它改成“U4”再保存。这步不用改代码但如果你在自研工具里拼消息就得改 struct 的格式符B i变成B I。改完以后保存为新的模板文件命名时加上设备型号前缀比如“某设备_ProcessDone_S6F11”这样后面换了设备不至于找不到原始定义。6.2 用模拟器做回归对比同一个模板发两遍测试模板改完之后我会在模拟器里做一个低成本回归把改好的 S6F11 模板连着发两遍一遍给模拟器自带的 Host 解析器收一遍抓包后用脚本解析。第一遍是验证模拟器本身认不认这条消息第二遍是验证第三方解析器认不认。如果两遍结果一致说明模板结构正确可以拿到真实设备上用。发两遍的目的很直白排除模拟器“过分友好”的解析。有些模拟器在解析 SECS-II 时容忍了格式码不匹配比如把 I4 当 U4 解但真实设备的协议栈很严格这种容错会掩盖模板问题。我踩过一次这样的翻车模拟器里事件上报一切正常拿到现场设备上对方直接拒绝后来逐字节对比才发现是某个数据项格式码写错模拟器给放过了设备没放过。从那以后我每次改完模板都强制走一遍双端验证先看回包 ack 是不是 0再看抓包解析的字节与你预期是不是完全一致最后才写提交记录。希望这个习惯能帮你在联调现场少熬几个夜。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
