简介SECS 是半导体制造中设备与工厂系统之间通信的标准协议定义了设备控制器与工艺设备间的数据交换格式和通信机制是半导体自动化产线中常用的接口标准。这套开源实现整合了 Tcl 与 C 混合编写的核心库适合自动化工程师、嵌入式开发者和半导体设备集成人员快速理解 SECS/HSMS 消息交互。压缩包共 11 个文件以 Tcl 脚本、Tcl 模块、C 源文件、测试用例以及说明文档为主整体仅 39KB体量精简易读适合直接阅读源码和二次修改。包内示例脚本演示了从消息构造到收发的基本流程底层 C 文件揭示了接口驱动逻辑多个测试文件可辅助验证协议实现的正确性便于在开发过程中做回归检查。目前已有 1483 人在 CSDN 学习与查看该资源适合作为 SECS 协议入门、工业通信调试和产线设备集成的轻量参考能帮助团队节省从零实现协议的时间。 搞半导体设备自动化这些年我几乎每天都在跟SECS/GEM打交道。供应商设备要接入MES通讯协议绕不开它但市面上成熟的SECS/GEM商业组件授权费不便宜想快速验证又不想被厂商绑定开源实现就成了很现实的一条路。你抛出的secs-开源这个标题我理解为在找能落地的SECS/GEM开源方案包括协议栈选型、消息解析、设备端与主机端联调以及怎么避开那些文档里不写、但实际会踩的坑。这篇文章就围绕这些展开面向设备端软件工程师、CIM/MES开发者和做工厂自动化的集成商照着做能少走不少弯路。1. 项目概述为什么要在半导体自动化里谈SECS开源1.1 SECS/GEM到底在解决什么问题SECS是SEMI Equipment Communications Standard的缩写GEM是Generic Equipment Model。它们是半导体制造领域设备与主机系统Host之间通信的事实标准。简单说就是设备端软件通过一套约定好的“语言”告诉MES我当前是什么状态、发生了什么事件、完成了一片产品的加工MES也可以通过这套“语言”下发配方、远程指令查询设备实时的运行参数。这套标准被SEMI组织定义成系列标准比如SEMI E4SECS-I、E5SECS-II、E37HSMS、E30GEM。实际项目中你一听到“SECS/GEM”指的是整个协议族而不是某一个单独的文件。从技术形态上看SECS/GEM替代的其实是过去每个设备厂商各自为政的私有通讯协议。没有它之前MES要对接十种设备就要写十套驱动有它之后大家都遵守同一套消息格式和行为模型对接效率明显提高。这也是为什么半导体行业对SECS/GEM的依赖非常深晶圆厂里的刻蚀、薄膜、光刻、清洗设备甚至封测厂的贴片机、测试机基本都要求支持GEM。1.2 开源实现解决了什么核心问题商业化的SECS/GEM开发包比如Cimetrix的SAPPHIRE或者国外厂商的SDK功能很全文档也规范但价格通常不低而且版本授权、技术绑定都是问题。你只是想验证设备样机的通讯逻辑或者做一个内部工具连一下模拟器投入那么多成本并不划算。开源实现的核心价值在于三点。第一零授权成本方便快速验证。你本地起一个设备模拟器再起一个主机模拟器用开源库几分钟就能把一条S1F2报文发出来不用等厂商审批License。第二源码可读便于深度定制。半导体设备的通讯逻辑很多时候要和设备内部状态机联动比如设备处于“正在加工”状态时不允许接收配方切换指令。商业库的黑盒封装反而不方便开源库你可以直接改消息处理逻辑甚至加私有Stream/Function。第三社区演进速度并不慢。这个领域看似小众但这几年半导体设备国产化进程加快国内做设备自动化的工程师越来越多不少开源项目在持续迭代像基于.NET的SecsGem、Python的secsgem、Java的secs4java都有活跃的提交记录。我的建议是不要把开源方案当成一个“玩具”很多量产设备实际就在用这些库跑通讯。关键是你要理解协议本身的语义而不能只停留在“把报文发出去”的层面。这也是这篇文章后面要重点展开的部分。2. 协议栈拆解看不懂SECS/GEM文档也能抓住主干2.1 先分清SECS-I、HSMS、SECS-II和GEM我第一次接触SECS/GEM时翻SEMI标准文档翻得头大因为涉及的标准太多了。其实你可以把它们按OSI模型来归类理解这样就清晰很多。协议对应层级作用实际场景SECS-I物理层/链路层基于RS-232串口通讯老设备、低速传输场景HSMS传输层基于TCP/IP的有连接通讯现代设备几乎都用SECS-II消息层定义消息格式Stream/Function、Item格式所有报文解析GEM行为模型定义设备状态机、报警、配方、远程命令等设备与MES联动的规则现在新建的设备基本不会再用SECS-I走串口绝大多数场景都在用HSMS。HSMS又分HSMS-SS和HSMS-GSSS是单会话通常一个IP端口对应一个设备GS是多会话用于多个设备共享连接。设备端实现以SS为主。SECS-II是消息层的编码规则。一条SECS消息体包含一个Stream和Function编号比如S1F1就是“Are You There”S6F11是“Event Report Send”。消息体内是各种ItemItem可以是List、Binary、ASCII、U4、I4等格式。实际调试时你会看到类似下面这样的报文结构S1F1 W . S1F1 是Stream 1 Function 1含义是查询存在 W表示需要对方回复。2.2 Stream/Function消息模型一小时上手对初学者来说不需要一开始把上百种消息全背下来但几个核心的Stream/Function必须掌握因为日常调试几乎天天用。S1F1/S1F2握手和状态查询设备端上线后第一件事就是响应这条消息。S1F13/S1F14Establish Communications Request / Acknowledge一般用于连接建立后的握手确认主机发S1F13设备回S1F14。S1F3/S1F4查询设备状态S1F3请求设备属性S1F4回复属性列表。S6F11/S6F12事件上报设备主动告诉主机“发生了什么”比如加工完成、报警发生这是联调中最常用的一类消息。S2F17/S2F18时间请求设备向主机请求当前时间和日期。S7F1/S7F2配方管理主机下发配方名或配方体设备执行。实际调试中你可以用一个支持SML格式的编辑器比如SML中定义的文本格式来读写报文这样比直接看十六进制字节流直观很多。不过也要提醒一句SML格式只是给人看的真正在网络上传输的是SECS-II编码后的二进制字节调试工具软件会自动完成字节流和SML文本之间的转换。2.3 GEM行为模型设备端和主机端的分工GEM标准SEMI E30定义了一套设备行为模型核心是“状态机 事件报告 控制指令”。设备状态主要分为OFFLINE、EQUIPMENT_OFFLINE、ONLINE_LOCAL、ONLINE_REMOTE等。ONLINE_REMOTE代表主机可以远程控制设备ONLINE_LOCAL意味着设备旁路操作但主机可以监控OFFLINE就是完全不跟主机交互。设备端要做的事是维护这套状态机在状态切换时上报事件主机端要做的事是根据设备的模型定义下发指令、订阅事件、收集数据。GEM还定义了一些标准状态模型比如Processing、Ready、Idle等。你在设备端实现时最好先把状态机模型画出来再映射到GEM的规定里否则后面联动调试时会出现“设备已经报了完成事件但主机端状态还停留在待机”的尴尬情况。这里有一个常见误解很多工程师以为只要把HSMS连上SECS/GEM就算通了。其实不然HSMS连接的建立只是最底层的第一步GEM状态机和事件上报规范才是真正决定通讯质量的部分。连接明明能通但主机认为设备不在线这种问题大多出在GEM状态机没有正确维护。3. 核心功能实现搭建一个可运行的最小SECS/GEM系统3.1 如何选型Python还是Java还是C#开源SECS/GEM实现语言生态差别挺大。我梳理几个我实际用过或者看过源码的项目供你做技术选型参考。Python阵营最常用的是secsgem。这个库实现了SECS-I、HSMS、SECS-II和GEM模型API相对简洁适合快速搭建模拟器、测试脚本。它的主要定位是“快速验证协议”设备端和主机端都支持文档也比较全。Java阵营secs4java是经典选项实现了HSMS、SECS-II、GEM的核心功能性能稳定被不少设备厂拿来做量产设备端的通讯模块。如果你的设备端软件本身是Java开发的选它没有明显的短板。另外还有hsms4j也提供了基础的HSMS连接能力接口设计更现代化。.NET/C#阵营SecsGem比较活跃在GitHub上可以找到使用Sematech标准库结构封装了SECS-II消息解析、HSMS连接和部分GEM行为。很多Windows上位机项目在用它。选型经验优先考虑你设备端主程序的开发语言不要为了“这个库看着更好”而引入异构语言。如果一个Java后端团队选Python库做设备端通讯后面维护成本会很高。另外关注项目的License类型MIT和Apache-2.0比较宽松LGPL需要留意衍生作品的合规要求。还有一个容易被忽略的指标是最近一年的提交记录一个半年没更新的项目说明要么很稳定要么已停止维护需要你结合Issue区判断。3.2 用secsgem快速搭建一个本地设备模拟器这里我以Python的secsgem库为例带你从零拉起一个设备端和主机端跑通一条S1F13/S1F14握手。第一步安装依赖pip install secsgem第二步写设备端代码。secsgem的设备端类叫SecsGemEquipment你只需要指定一个设备地址和端口然后启动即可。from secsgem.gem import GemEquipmentHandler from secsgem.hsms import HsmsSettings, HsmsConnectionMode from secsgem.hsms import HsmsProtocol settings HsmsSettings( device_id0, address127.0.0.1, port5000, connect_modeHsmsConnectionMode.PASSIVE, # 设备端通常是被动连接 nameeq_simulator ) handler GemEquipmentHandler(settings) handler.enable()注意设备端一般是被动模式PASSIVE也就是监听端口等主机来连接。第三步写主机端代码。主机端用主动模式ACTIVE去连接设备。from secsgem.gem import GemHostHandler from secsgem.hsms import HsmsSettings, HsmsConnectionMode settings HsmsSettings( device_id0, address127.0.0.1, port5000, connect_modeHsmsConnectionMode.ACTIVE, # 主机端主动连接 namehost_simulator ) handler GemHostHandler(settings) handler.enable()运行设备端脚本后再运行主机端脚本。正常情况下主机端会主动发起TCP连接连接建立后发送S1F13设备端返回S1F14。如果你看到两端控制台的日志中都出现了S1F13 W和S1F14的回包就说明SECS/GEM通讯链路已经打通。3.3 自己实现消息解析时必看的数据结构细节如果你不是直接用现成库而是要在老系统里自研一台设备的SECS/GEM模块那最核心的其实是SECS-II消息的字节级解析。我给你整理几个容易出错的细节。消息头项Header共10个字节第1字节是MessageLength高字节第2字节是MessageLength低字节后面依次是DeviceID/Stream、Function、ReplyExpected以及两字节的SessionID。其中ReplyExpected位表示是否需要回复置1表示对方收到后要回一条消息。SECS-II的Item编码是TLV结构Tag类型标识、Length长度、Value数据。不同的数据类型有不同的TypeCode比如List是0x01Binary是0x10ASCII是0x20。实际报文解析时最容易踩的坑是字节序。SECS-II规定整型数据是多字节且高字节在前Big-Endian但很多设备工程师平时写C代码用x86默认是Little-Endian直接转换就出错。比如U4类型数值60000在网络上是0x0000EA60如果按小端方式读就变成了0x60EA0000结果完全不对。另外还要注意消息头的长度字段是对“Header之后的完整数据体”的字节计数计算时不要把Header本身算进去。这个看似简单在自研时经常搞错。4. 实操过程与核心环节实现4.1 设备端实现GEM状态机迁移光有通讯框架还不够设备端必须把GEM状态机“跑起来”。我以secsgem为例看看状态迁移是怎么实现的。secsgem内部定义了状态机的枚举比如EquipmentStates这类。设备刚启动时处于OFFLINE状态当设备端脚本检测到HSMS连接建立后可调用状态切换接口让它进入ONLINE_REMOTE。# 设备端代码片段 from secsgem.common import EquipmentState handler.equipment_state EquipmentState.ONLINE_REMOTE状态迁移的同时要上报事件。GEM标准里模型文件定义了设备支持哪些事件、事件对应哪些数据变量。比如“加工完成”这个事件数据变量可能包括产品的Recipe ID、Process Time等。secsgem里可以通过模型定义或者API直接上报事件。from secsgem.gem import EquipmentEvent event EquipmentEvent(PROCESS_COMPLETE) event.data {RECIPE_ID: RT001, PROCESS_TIME: 123.45} handler.send_event(event)这段代码在真实设备上对应的动作是设备加工完一片晶圆后主动向MES发送S6F11MES收到后回复S6F12确认。我在最初调试时经常犯一个错误事件还没上报就把设备状态切到Online结果MES端认为设备“在线但无事件”数据完全对不上。GEM规范里明确要求状态切换和事件上报需要按顺序来。4.2 主机端订阅事件与远程命令下发主机端要做的第一件事是向设备订阅事件。GEM中通过S2F33Define Report/S2F35Link Event Report等消息来配置数据收集。secsgem里提供了一些高层接口简化了订阅过程。简单场景下主机端可以周期性调用S1F3查询设备状态也可以实现事件响应回调。下面是一个简单的事件回调示例def on_event(event): if event.name PROCESS_COMPLETE: print(f设备上报加工完成配方: {event.data[RECIPE_ID]}) handler.events [on_event] handler.enable()远程命令通过S2F41/S2F42实现。主机下发S2F41Host Command Send命令名比如START、STOP、PAUSE设备端执行后回S2F42Host Command Acknowledge。命令参数按GEM模型定义通常包含一个CommandName和参数列表。设备端需要维护命令的执行结果状态分为Accepted、Rejected、Not Ready等。4.3 联调时如何判断消息链路是否正常联调阶段我习惯先在设备端和主机端分别打印出完整的消息日志然后用Wireshark或者tcpdump抓包做交叉比对。这里有几个判断流量的技巧第一检查TCP连接是否正常建立。HSMS是长连接正常情况下连接不会频繁断开。如果日志里出现反复断开重连优先检查心跳超时设置。第二检查S1F13/S1F14是否成功交换。这是GEM会话的握手层连接建立后必须先完成这个动作后续消息才有意义。第三检查S6F11的ReplyExpected位是否设置正确。如果设备发送S6F11时没有要求回复主机端就不会回S6F12这在调试日志里看起来像“主机没有反应”但实际上是正常的。第四检查消息长度字段与实际字节数是否一致。这个在自研解析时经常出错如果长度字段多算或少算一个字节接收端的消息解析就会直接乱掉。5. 常见问题与排查技巧实录5.1 HSMS连接不稳定总是建立后断开HSMS的TCP连接建立后设备端和主机端要维持心跳。GEM标准定义了多个计时器比如T3Reply timeout、T5Connect separation timeout、T6Control transaction timeout等。连接不稳定的常见原因是T3和T6设置太短消息处理稍微慢一点就被判定超时中断。一个常见的配置经验T3设置为45秒T6设置为5秒T5设置为10秒。如果你的设备业务逻辑里存在耗时超过5秒的操作比如收到远程命令后执行了一次较长的校准流程那么要考虑把T6调大否则命令执行中就会出问题。另外HSMS消息帧有4个字节的消息头长度字段帧类型分为数据消息和信令消息某些实现把心跳控制消息当成了数据消息导致对端解析出错。出现这种情况时可以先检查对端库是否支持HSMS的控制消息Separate、Select、Deselect等很多超轻量实现并不完整支持这些控制消息。5.2 数据值对不上字节序和数据类型设错联调时最经典的一幕设备上报温度值MES端解析出来是个天文数字。原因通常就是字节序不一致或者SECS-II的Item类型定义错了。比如设备把温度当作I4有符号32位整型上报主机端按U4无符号32位整型解析负温度就会变成正的大数。排查方法先在设备端打印出Item的TypeCode和原始字节确认真实编码再在主机端解析逻辑里检查类型定义。如果两端都用的标准SECS-II库一般不会出现这种问题问题常出在“手工解析”的桩代码上。建议任何手工解析从第一步就打印十六进制字节流不要直接看数值。另一个容易出错的是ASCII字符串的长度。SECS-II的ASCII Item长度是实际的字符数不包括结尾空字符。如果从C语言字符串拷贝数据时多带了一个\0报文长度就会多出一个字节对端解析就会出问题。5.3 事件一直没上报主机端收不到S6F11事件上报是GEM最核心的功能之一也是问题最多的环节。收不到S6F11我总结了四个排查方向。先检查事件报告配置。GEM有个概念叫“Report”设备必须先被配置好“什么事件要上报、上报哪些变量”才能发S6F11。如果设备上电后没有做S2F33/S2F35的配置流程那很可能连事件都不会触发。再检查设备状态。很多设备只在ONLINE_REMOTE状态下才允许上报事件OFFLINE状态下事件会被丢弃或者放在本地队列里不发送。还要检查事件发生时机。有些设备的事件在加工完成后由某个业务线程触发如果业务线程异常事件逻辑根本走不到这时就需要写一条手动触发事件的调试代码来排除业务层的问题。最后检查主机端是否回S6F12。如果设备发了S6F11但主机没回确认SECS/GEM底层库会在超时后重发次数超过限制后会直接断连。这时重点排查主机端的消息处理线程是否阻塞。5.4 自研SECS-II解析的几个建议如果决定自研协议解析我给你三个建议。第一统一封装一个“字节流到Item列表”的解析层任何Stream/Function的处理都经过这一层不要在业务代码里直接操作字节否则一旦字节序出错所有处理逻辑都要跟着改。第二对未知类型Item做容错处理某些设备厂商会在标准里加入扩展Item类型解析器遇到未知类型时不要直接throw异常而是打日志跳过保证其他消息还能正常处理。第三写一套基于已知报文样本的单元测试每个消息都配上十六进制样例和SML对照这样后续代码升级的时候回归测试能帮你快速发现问题。根据我个人的经验早期用开源库做SECS/GEM验证时最容易出现的问题不是库本身而是开发者对协议语义理解不够。你让设备发一条S6F11它确实发了但事件数据里缺少关键变量主机端的业务逻辑拿到后只能干瞪眼。建议任何一个设备项目在开发初期就把“事件报告的数据变量清单”和设备业务逻辑放在一起评审而不是把这个工作丢给联调阶段。还有一个小技巧几乎所有SECS/GEM调试工具都支持记录和回放报文。联调时养成“先记录原始报文再对照曲线分析”的习惯。我在处理现场问题时经常靠一段完整报文回放就复现问题了比反复让现场工程师重试高效得多。遇到难缠的问题也可以把报文发到社区讨论附上版本信息和复现步骤这样得到有效回复的可能性会大很多。本文还有配套的精品资源点击获取
