★ FEATURED ARTICLE 简介SECS GEM SDK 2022.7.14 试用版是一套面向半导体设备软件工程师的通信开发工具帮助开发者按照SECS/GEM标准快速构建与fab自动化系统交互的应用程序适用于设备控制、数据采集、事件报告等场景。压缩包共237个文件总大小约29.53MB包含70个dll、38个cs、33个h、27个cpp等库文件与源码同时配备csv配置、ini设置、PDF手册及示例工程覆盖从协议封装到界面集成的完整链路。资源已有158人学习适合具备基础通信知识的工程师评估试用版功能或借鉴代码结构。通过源码与API文档可以掌握SECS消息打包解包、GEM事件处理、错误码调试等核心机制借助配套模拟器和演示程序还能在无实际设备的情况下验证通信流程为正式采购或自研通信模块提供参考。1. 为什么 SECS/GEM SDK 值得先跑通试用版设备通讯联调的第一道门槛一条新设备导入产线EAP 系统一直报“连接超时”设备端日志里全是“S1F13 无应答”这种情况在 SECS/GEM 联调里太常见了。SECS/GEM 是半导体设备与工厂主机之间的标准通讯协议很多设备软件工程师第一次接触时面对 HSMS、SML、SECS-II 这些词根本摸不到边。这套 2022.7.14 版本的 SECS GEM SDK 试用版把底层的收发、解析、会话管理封装成了可以直接调用的 API适合在无硬件条件下先验证协议逻辑。如果你正在评估设备端通讯模块、写 EAP 适配层或者被厂商的协议文档折腾得头疼这份资源能让你把协议跑通的时间从两周压缩到两天。2. 拆解协议栈HSMS 连接角色与消息传输格式2.1 HSMS 连接建立主动模式与被动模式怎么选SECS/GEM 的底层传输有两种老式的 SECS-I 走串口新的 HSMS 走 TCP/IP。现在设备基本都走 HSMS所以你要先搞清楚自己是主动连接方还是被动等待方。这个角色选错后面全白搭。连接建立时发起方叫 Active被动监听方叫 Passive。设备通常是 Passive主机 EAP 是 Active但有些老设备正好反过来。HSMS 规范里有个 Select TimerT5Active 方发出 Select Request 后要等待对方回应 Select Response。如果 T5 设得太短对方还没处理完Active 方就判定超时连接就会反复断开。常见做法是先把设备端模拟器设为 Passive主机端用 Active 连接端口默认 5000。SDK 里对应的配置参数一般长这样var config new HsmsConnectionConfig { IpAddress 127.0.0.1, // 设备模拟器所在 IP Port 5000, // HSMS 默认端口 Mode HsmsMode.Active, // Active 主动连接Passive 被动监听 DeviceId 0, // 设备 ID由 SECS-II 会话约定 SelectTimeout 10000, // T510 秒等待 Select 确认 ReplyTimeout 45000, // T345 秒等待消息响应 HeartbeatInterval 10000, // T710 秒链路保活心跳 NetworkTimeout 60000 // T860 秒判定网络错误 };DeviceId 是一个整数范围是 0 到 32767对应 SECS-II 消息头里的 Session ID 低 15 位。多台设备共用同一主机时DeviceId 必须不同否则消息就串了。T5 和 T3 我一般按 SEMI E37 的推荐值设不随便改这两个参数后期调起来很容易变成“玄学”。2.2 SECS-II 消息结构Stream、Function 与 W-Bit 的约定连接建立后真正的业务数据走 SECS-II。SECS-II 消息由 Stream 和 Function 编号组成比如 S1F13 是建立通信请求S1F14 是它的回应S2F41 是主机远程命令S6F11 是设备事件上报。每个消息都带一个 W-Bit表示是否期望对方回复。设置 W-Bit 后SDK 会自动匹配同一个 Transaction ID 的响应。SDK 通常会提供 SMLSECS Message Language解析器可以直接用文本描述消息结构。SML 文件的好处是改起来不用重新编译数据格式一眼能看明白。比如 S1F13 的 SML 长这样S1F13 W L L A MDLN-SIM A SW-1.0 L A APP-TYPE A 1.0 这段 SML 表示 S1F13 携带一个 List里面有两个 List一个描述设备型号和软件版本另一个描述应用类型和版本。W 表示期望主机回 S1F14。实际传输时SDK 会把 List、ASCII 字符串按 SECS-II 的 Item 编码规则转成二进制字节流。SECS-II 的数据格式我在调试时经常遇到对不上的情况。Item 类型包括 Binary、Boolean、ASCII、U1 到 U8、I1 到 I8、F4/F8 等。字段类型不对比如设备上报的是 U4主机按 I4 解析数值就会变成负数。这种问题日志里不一定报错看起来像正常收发了但数据全是错的属于最容易“翻车”的黑匣子。3. 在模拟环境跑通试用版从连接到事件上报的完整流程3.1 启动设备模拟器并确认基础参数这套 SDK 试用版自带一个设备模拟器不需要真实机台就能验证主机和设备之间的交互。打开模拟器后把端口设成 5000设备 ID 设成 0通讯模式选 Passive。保存配置后启动模拟器会在本机 5000 端口监听。试用版一般会有运行时长或消息条数限制但这个限制只影响压力测试不影响功能验证。启动模拟器后先用netstat确认端口处于监听状态netstat -an | grep 5000注意看输出是 LISTENING 而不是 TIME_WAIT。TIME_WAIT 说明之前有连接被异常断开端口还没释放。如果遇到这种情况等两分钟或者换一个端口重启模拟器别直接硬连。3.2 主机端建立 HSMS 连接并完成 S1F13 握手模拟器起来后写一个控制台程序模拟 EAP 主机。先用 SDK 的连接类建立到 127.0.0.1:5000 的连接然后发送 S1F13 握手请求using var connection new HsmsConnection(config); connection.Open(); var request new SecsMessage(1, 13, true); // Stream1, Function13, Wtrue request.AddList() .AddList() .AddAscii(MDLN-SIM) .AddAscii(SW-1.0); var reply connection.Request(request, config.ReplyTimeout); if (reply ! null) { Console.WriteLine($收到 S{reply.Stream}F{reply.Function}); Console.WriteLine(reply.ToSml()); } else { Console.WriteLine(S1F13 超时无响应); }connection.Request是同步方法第二个参数是 T3 超时单位毫秒。我习惯把 T3 和配置文件里的 ReplyTimeout 绑在一起避免代码里写死数字。收到 S1F14 后把返回的 SML 打印出来能看到设备型号和软件版本。很多人第一次跑通这一步就以为完事了但后面还有事件上报。3.3 注册 S2F41 远程命令与 S6F11 事件上报S1F13 只是握手GEM 里真正干活的是远程命令和事件上报。S2F41 是主机给设备下发命令比如开始加工、暂停、结束。设备支持哪些命令要先从模拟器支持的命令列表里查别自己编。用 S2F41 执行一个“StartProcess”命令参数 PPID 要填设备上存在的 Process 程序名var cmd new SecsMessage(2, 41, true); // S2F41 cmd.AddList() .AddList() .AddAscii(StartProcess) // COMMAND 名 .AddList() .AddList() .AddAscii(PPID) // 参数名 .AddAscii(RECIPE_001); // 参数值 var reply connection.Request(cmd, config.ReplyTimeout); Console.WriteLine(reply?.ToSml());设备会回 S2F42里面带一个完成码HCACK0 表示接受非 0 表示命令被拒绝。如果不先看设备支持的命令列表就乱发设备会一直回错误码状态机还容易卡在 BUSY。事件上报更关键S6F11 是设备主动发给主机的比如“加工完成”“温度超限”。上报前要配置好事件和报告的关系var report new Report(1000, new int[] { 1, 2, 3 }); // RPTID1000采集 VID 1/2/3 var ce new CollectionEvent(2000); // CEID2000对应加工完成 ce.AddReportId(1000); equipment.ConfigureEvent(ce);这里的 CEID 是事件 IDRPTID 是报告 IDVID 是数据变量 ID。三者必须先定义好设备才知道触发 2000 事件时要把哪些变量塞进报告。映射关系搞错主机收到的数据就不是想要的。3.4 完整联调回路从触发事件到主机确认配置完成后让设备模拟器触发一次“加工完成”事件主机会收到 S6F11。收到后主机必须回 S6F12 确认否则设备会认为事件上报失败后续事件可能会被冻结。var reply connection.Request(eventMessage, config.ReplyTimeout); var ack reply.Items[0].GetAscii(); if (ack 0) Console.WriteLine(事件上报成功);S6F12 的 ACKC6 为 0 表示接受非 0 表示设备端需要重发。到这里一轮完整的“握手 命令 事件”闭环就通了。新手很容易卡在事件上报这一步因为 S6F11 是设备主动发起的不是主机发起的代码结构的写法跟前面的同步请求不一样需要提前把事件消息处理函数挂到连接对象上。4. 超时参数与日志追踪让通讯状态可观测4.1 T3/T5/T7/T8四个超时参数的定位与调优SECS/GEM 联调里超时参数是排查问题的第一现场。SEMI E37 定义了 T3 到 T8 五个计时器每个的用途不一样调错了反而会把小问题放大。参数名称推荐值作用常见误区T3Reply Timeout45 秒等待消息响应设太短慢设备总超时T5Connect Timeout10 秒等待 Select 响应设太短握手会断T6Control Timeout5 秒等待控制消息响应很少碰别乱改T7Link Test10 秒心跳间隔设成 0 禁用心跳链路被防火墙断开T8Network Timeout60 秒网络异常判定必须大于 T7否则误判断链T3 和 T7 最容易出问题。有一次我排查现场问题设备总在空闲 15 分钟后掉线最后发现主机把 T7 设成了 0禁用心跳防火墙直接把空闲连接回收了。把 T7 设成 10 秒后问题消失。调整方式很简单改配置文件里的值然后重启连接即可。注意 T8 一定要大于 T7这是一个硬约束。如果单位不统一毫秒和秒混着写网络会一直误报断链。4.2 消息追踪抓包工具与日志分级协议联调不能只靠肉眼。SDK 一般会提供消息跟踪工具可以在发送和接收时把所有 SECS-II 消息打印成 SML 格式。打开跟踪开关后日志里能看到每条消息的方向、Stream/Function、Transaction ID 和完整数据。我习惯把日志分成几个级别FATAL - 程序无法恢复必须重启 ERROR - 通讯异常需要人工介入 WARN - 超时重传但不影响主流程 INFO - 连接建立/断开、事件收发 DEBUG - 每条消息的 SML 内容生产环境我建议只开 INFO把 DEBUG 的 SML 落盘到独立文件按天滚动。线上问题排查时打开当天的 DEBUG 日志直接搜 transaction ID 就能定位到消息。日志里最关键的字段是事务 ID。每一次带 W 位的请求都会生成一个唯一事务号响应消息会带上同一个事务号。如果你在日志里看到请求的事务号和响应对不上说明双方的 Session 或事务管理逻辑有 bug这种问题不是调参数能解决的。5. 避坑指南试用版最常见的五个问题与排查思路5.1 现象连接建立后立刻断开刚启动的模拟器主机连接成功后还来不及发送 S1F13链路就断了。原因T5 设置的时间小于设备端 Select Timer 的等待时间。主动方发出 Select 请求后被动方如果没在 T5 时间内响应主动方会直接断开。多数 SDK 默认 T5 是 2000 毫秒某些模拟器注册过程比较慢2 秒根本不够。解决把 T5 调整到 10 秒再试。同时看设备端的连接日志如果 Select 请求根本没到设备端就是 IP 或端口配错了如果到了但响应慢就是 T5 太短。5.2 现象S1F13 收不到 S1F14一直超时连接没断但主机发的 S1F13 石沉大海。原因设备端没有处于 ONLINE 状态。GEM 规定设备只有在 Remote 模式下才接受主机的通讯请求如果模拟器还停在 OFFLINE它不会回应 S1F13。另外S1F13 的 W 位如果设成 false设备不会回消息。解决先把模拟器切换到 Online 模式确认状态机允许主机通讯再用 SDK 的跟踪功能看发出的 S1F13 消息头W 位必须是 1。5.3 现象S6F11 事件收到了但数据解析出来是负数或乱码主机端收到的 S6F11 数据跟设备端定义的值对不上。原因报告里配置的 VID 和实际数据变量的类型不匹配。设备端定义的温度变量是 U2 类型主机端按 I2 类型解析数值超过 32767 就变成负数。SECS-II 不同整数类型的编码长度不同U2 是 16 位无符号I2 是 16 位有符号。解决用 SDK 的数据项查看工具逐字节核对设备端上报的 Item 类型。找出报告定义里 VID 对应的变量类型把主机端解析类型改成一致。这个坑日志里不报错属于协议规范没对齐只能靠抓包对比。5.4 现象多个设备同时连接时消息路由混乱一台主机连多台设备发出去的 S2F41 响应到了错误的设备上。原因DeviceId 重复。SECS-II 消息头里的 Session ID 低位用于路由如果两台设备都配了同一个 DeviceId消息就无法区分。解决给每台设备分配唯一的 DeviceId。检查连接配置时把 DeviceId 和设备实际配置逐台比对不要想当然认为“0”是唯一的。5.5 现象试用版用了几天后连接拒绝建立之前一直正常某天开始连接时直接报“license expired”。原因试用版安装包带有运行期限检查通常是发布日起 30 天或固定累积运行时间。时间到期后连接模块直接拒绝启动。解决如果是评估用途卸载后重新安装或者在虚拟机里保留快照到快照点重新验证。如果是项目交付用途需要在试用到期前切换到正式授权版本。别在生产环境用试用版这个问题不是玄学是硬限制。6. 进阶验证技巧状态机检查与日志回归脚本SECS/GEM 联调到这里基本流程已经能跑通了。但真正到了多设备接入阶段你还需要一个自动化的回归验证手段。最让我受益的一个习惯是跑完手动流程后把日志文件用脚本扫描一遍自动检查关键交互。我不需要人工看一遍 SML只关心几个硬指标S1F13 有没有对应的 S1F14、每个 S6F11 有没有 S6F12 回执、S2F42 的 HCACK 是不是 0。import re from collections import defaultdict def check_secs_flow(log_path): requests defaultdict(list) events_acked 0 events_total 0 with open(log_path, encodingutf-8) as f: for line in f: m re.search(rS(\d)F(\d)\sTID(\d), line) if not m: continue stream, func, tid m.groups() if stream 1 and func 13: requests[s1f13].append(tid) if stream 1 and func 14: requests[s1f14].append(tid) if stream 6 and func 11: events_total 1 if stream 6 and func 12 and ACK0 in line: events_acked 1 print(fS1F13: {len(requests[s1f13])}, S1F14: {len(requests[s1f14])}) print(fS6F11 已确认: {events_acked}/{events_total})把这个脚本接在 CI 或日常联调流程后面每次改动协议配置后跑一遍能快速知道哪些链路断了。从那以后我每次接入新设备都强制走一遍“S1F13 握手、S2F41 远程命令、S6F11 事件上报”的回归脚本确认三个指标全绿再交给现场联调返工率明显下降。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
