前几年在半导体封测厂做设备自动化改造几乎每天晚上都要跟SECS协议打交道。设备厂商给的文档厚厚一摞核心却绕不开那几样东西SECS-I/HSMS怎么连SECS-II消息怎么拼怎么解GEM状态机怎么切。后来我们用C#从头写了一套上位机SECS通信框架一路踩了不少坑也沉淀了不少经验。这篇文章就把这些实操中的东西理一理给正准备碰SECS协议、或者想用C#做半导体设备上位机的朋友做一个参考内容覆盖传输层、消息层、GEM状态管理和EAP对接也包括一些调试工具和常见坑点。1. 内容整体设计与思路拆解1.1 SECS协议到底是什么为什么设备非要它SECSSEMI Equipment Communications Standard是半导体设备与工厂管理系统比如MES、EAP之间通信的一组标准协议由SEMI组织定义。它不是一个单层协议而是一组配套标准SECS-I负责物理传输RS-232HSMS负责以太网传输TCP/IPSECS-II定义消息内容和数据项的格式GEM则定义了设备行为的标准模型。为什么半导体行业对它有近乎执念的要求因为一条产线上的设备来自不同厂商光刻机、刻蚀机、清洗机、测试机每家都有自己的指令体系。如果每台设备都用私有协议对接MES系统会被逼疯。SECS/GEM存在的意义就是让大家讲同一种“普通话”——不管设备是谁造的消息格式、通信流程、状态上报方式都遵循同一套规范EAP系统才能统一调度和采集数据。值得注意的是SECS协议并不是一个“很现代”的协议它的设计带着上世纪80年代的痕迹。消息结构简单传输效率不算高但是极其稳定可靠所以在半导体、光伏、面板这些高价值制造领域至今仍是主流。即使新设备也开始支持更多现代接口SECS/GEM依然是工厂自动化的“基本盘”。1.2 为什么选择C#做上位机SECS通信我知道很多人会用C、Python或者LabVIEW做上位机但C#在半导体设备自动化场景里其实非常能打。开发效率高正好适配上位机这类需要频繁迭代的业务逻辑。半导体设备对接涉及大量消息解析、界面显示、配方管理、报警处理C#的语法简洁、内存管理友好写起来比C省太多心。和Windows生态结合紧密。绝大多数Fab里的上位机工控机是Windows系统C#对串口、TCP、多线程、日志、UI框架的支持都很成熟部署也简单装个.NET运行时就行。类库生态丰富。比如开源的Secs4Net已经帮我们封装好了HSMS通信和SECS-II消息模型省去了很多人肉解析字节流的工作。当然也有同行质疑C#在实时性上不如C。实际做下来SECS通信本身不是微秒级实时控制TCP连接的稳定性、消息解析的正确性才是关键。C#的异步编程模型async/await配合高性能Socket完全能撑住几十台设备同时通信。我们场里一台工控机同时管理6台封测设备的SECS连接消息量最大的时候一秒钟处理上百条S6F11报警上报C#依然稳如泰山。1.3 方案选型标准库还是自研所有对接SECS协议的项目第一阶段都会面临一个选择直接用现成库还是自己造轮子。这里没有标准答案关键是评估项目阶段和团队能力。当时的项目情况是设备类型杂有旧设备走SECS-I串口也有新设备走HSMSEAP系统要求自定义的SECS-II消息也很多。开源的Secs4Net虽好但它的消息模型比较“标准”面对各种私有扩展时不够灵活。后来我们决定以开源库为参考自己写一套核心通信层只依赖SEMI标准里的必要规范把消息模型完全交给上层业务。如果是中小型项目、设备相对标准直接用Secs4Net这种成熟库是完全够用的没必要自己从零开始。但如果你需要深度定制、或者想彻底搞清楚协议细节自研通信层其实也是很好的学习路线。后面章节里的代码示例会兼顾两种方式的思路核心逻辑是一样的。2. 核心细节解析与实操要点2.1 传输层SECS-I和HSMS一个都不能忽视SECS-I是古老的RS-232串口通信方式波特率通常9600使用CRC校验数据块长度最大256字节。很多老设备比如90年代的扩散炉、老式清洗机依然只支持SECS-I。用C#做SECS-I上位机时本质就是串口编程区别在于要在字节流里识别“块”的边界——SECS-I的块头有10个字节包含设备ID、块号、是否最后一块等标志。这里特别容易出错的是串口参数配置不匹配常见的有数据位7位、校验位EVEN、停止位1位跟普通Modbus串口的8-N-1完全不同。我第一次对接时就因为数据位没设置对设备一直回NAK排查了整整半天。HSMS则是基于TCP/IP的传输层分主动和被动两种模式。主动模式Active由上位机发起TCP连接被动模式Passive由设备发起连接。实际项目中设备的角色是固定的默认Equipment是PassiveHost是Active但有些老设备只支持主动连接这时候上位机就要监听端口。记住连接建立后还有一套HSMS通讯测试机制T5、T6、T7、T8定时器如果一段时间没消息双方会发送LinkTest请求确认链路存活。这在C#里用定时器就能实现但注意超时时间要按标准设置不是随便填的。说到HSMS消息头格式是固定的10字节Message Length4字节消息总长度包括消息头本身Session ID2字节通常是设备IDMessage Type1字节数据消息Data Message或控制消息Control MessageMessage Status1字节回复状态System Bytes4字节用于匹配请求和响应这个头结构是整个HSMS通信的地基。很多解析问题都出在System Bytes的处理上——例如发送请求后必须通过相同的System Bytes匹配对应的回复如果搞错整个事务就乱了。2.2 SECS-II消息编码从SML到二进制流SECS-II的消息格式是树状的。每个消息由Stream和Function编号唯一确定比如S1F13是“建立通信请求”S6F11是“事件报告发送”。消息内容由数据项Data Item组成数据项有类型、长度、值三要素常见的类型有Boolean、U1/U2/U4/U8、I1/I2/I4/I8、F4/F8、AASCII字符串、Bin二进制、List。这里最容易绕晕的是SECS-II的二进制编码不是简单的“类型长度值”它的格式控制字节里同时编码了数据类型和长度。比如一个ASCII字符串“SUB”编码为格式字节0x20类型A两个bit表示“单字节长度”的扩展方式长度字节0x03数据0x53 0x55 0x42对于List类型它的格式字节是0x01然后长度表示List里元素的个数。而List里的每个元素可能是任意SECS-II类型包括嵌套的List。这就导致消息解析不能按固定偏移量读必须写一个递归解析器按“读一个元素 - 如果是List就递归读里面的内容”这样的逻辑进行。平时我们阅读SECS-II消息时更多使用SMLSECS Message Language格式。举个例子S1F13 W L2 A MDLN A SOFTWARE VERSION 这就是一条S1F13请求建立通信的标准消息。写C#代码时我们一般用SML字符串作为外部接口然后内部解析成二进制流发送。解析器可以用简单的递归下降法也可以用现成库自带的功能。关键是要把“设备ID”“系统字节”“消息方向W位”这些元信息处理清楚。2.3 GEM状态模型设备行为都要符合规矩GEM标准把设备的行为抽象成几个核心模型通信状态模型、控制状态模型、处理状态模型、设备状态模型等。其中最容易让初接触者困惑的是控制状态模型Control State Model它有四个状态OFF设备不参与自动化EAP无法控制。ON-LINE READY设备在自动状态但当前没有正在处理的批次。ON-LINE ACTIVE设备正在自动处理中。OFF-LINE设备离线或手动模式。EAP系统下发指令控制设备的关键就是确认设备当前控制状态。例如设备在OFF-LINE状态时EAP发S2F41定义报告或S2F49扩展报告命令设备通常会回复错误提示“需要先切回ON-LINE状态”。我们做上位机时必须把这一层状态管理好——不是简单转发一下消息而是要维护一个本地状态机的副本根据收到的消息、设备上报的事件实时更新。GEM还定义了大量标准事件比如START_JOB、END_JOB、MACHINE_READY等等每个事件都要能传送给EAP。事件上报的流程通常是设备先上传S6F11事件消息EAP回S6F12确认。这里有一个容易忽略的点S6F11里的“报告数据”必须在发送前通过S2F33定义数据变量和S2F37定义事件提前配置好。否则设备不知道要发哪些数据变量给Host。2.4 C#中的关键数据结构与类设计在C#里实现SECS消息模型时建议用面向对象的方式定义消息类而不是散落的byte[]。我们当时的做法是用SecsMessage类表示一条完整消息包含Stream、Function、ReplyExpected是否期望回复、Data顶层数据项。用SecsItem基类表示数据项派生类包括SecsList、SecsAscii、SecsBinary、SecsU4、SecsI4等。每个派生类负责自己的编码和解码。用HsmsConnection类管理TCP连接和会话内部维护发送队列、超时调度、System Bytes递增器。用GemHandler类处理GEM状态机和标准消息S1F13/S1F14、S2F41/S2F42、S6F11/S6F12等。如果你用的Secs4Net库它已经有类似的设计但你还是应该在业务层再封装一层把设备厂商的私有扩展方法统一收口。比如我们对接某台测试机时消息里会带一个自定义的F4数组表示测试向量长度如果直接在业务里到处写解析代码后期换设备会很痛苦。3. 实操过程与核心环节实现3.1 准备开发环境与基础框架开发环境方面我推荐使用Visual Studio 2022.NET 6/8均可。如果目标工控机是Windows 10/11建议直接用.NET 6兼容性和性能都不错。引用NuGet包的话可以找Secs4Net最新版本支持.NET Standard 2.0老设备工控机也能用。如果是自研那只需要System.IO.Pipelines或System.Net.Sockets即可。搭建基础框架时建议先把日志系统搞好。SECS通信的日志极其重要因为问题往往发生在“报文差异”上。不光要记录发送和接收的原始字节还要记录解析后的SML、时间戳、系统字节、以及当时的状态机快照。日志格式可以采用结构化日志比如Serilog但也可以像我们一样直接写文本文件方便在Exineer级联查看。这里强烈建议打一条“完整日志”和一条“摘要日志”完整日志留档追踪摘要日志用于现场快速定位。3.2 实现HSMS连接管理主动/被动模式主动模式下C#实现大致如下代码var tcpClient new TcpClient(); await tcpClient.ConnectAsync(ip, port); var connection new HsmsConnection( deviceId: 0, isActive: true, socket: tcpClient.Client, messageHandler: OnMessageReceived); connection.Start();被动模式则稍有不同需要先开启一个TcpListener接受设备连接后创建HsmsConnection。注意对于被动模式收到设备连接后上位机需要主动发一条S1F13或者等待设备发S1F13完成“建立通信”。有些设备厂商在连接上来后立刻发S1F13Host只需要回S1F14即可有些则傻等Host先发S1F13这时候就需要我们的状态机去判断连接刚建立时应该由谁发起握手。这个细节如果不看调试日志真的会来回卡死。有关HSMS定时器有几个标准参数需要写在配置里T3回复超时默认45秒T5建立连接后未收到消息可等待时间默认10秒T6控制消息处理超时默认5秒T7连接空闲后未收到数据的时间默认10秒T8连接空闲后未收到LinkTest的时间默认5秒需要留意的是T8和T7是联动关系TCP连接建立后如果在这两个时间内都没有数据交互必须发送HSMS LinkTest控制消息确认链路。我们的经验是T8设置为5秒LinkTest的发送间隔不要超过T8的一半否则就会频繁触发断线。3.3 解析与发送SECS-II消息示例消息层代码最核心的就是解码。我用一段简化版的递归解码逻辑展示思路static SecsItem DecodeItem(ReadOnlySpanbyte buffer, ref int offset) { byte formatByte buffer[offset]; int type (formatByte 0xFC) 2; // 高6位是数据类型 int lengthBytes formatByte 0x03; // 低2位表示长度字段长度 uint len 0; for (int i 0; i lengthBytes; i) { len | (uint)buffer[offset] (8 * (lengthBytes - 1 - i)); } // 根据type决定是List还是Value if (type 0x01) // List { var list new SecsList(len); for (int i 0; i len; i) { list.Items.Add(DecodeItem(buffer, ref offset)); } return list; } else { var data buffer.Slice(offset, (int)len).ToArray(); offset (int)len; return new SecsValueItem(type, data); } }这里需要特别提醒长度字段可能存在“多字节”表示。当数据长度小于256时格式字节低两位为0长度字段占1字节长度在256~65535之间时低两位为1长度字段占2字节更大时低两位为2占4字节。解析时千万不能只按1字节读长度否则长消息一到解析就全乱了。发送SML消息则可以直接调用封装好的库或者自己的解析器// 使用Secs4Net风格 var msg new SecsMessage(1, 13) { ReplyExpected true, Data new SecsList { new SecsAscii(MDLN), new SecsAscii(SOFTWARE VERSION) } }; await connection.SendAsync(msg, cancellationToken);从业务角度看真正困难的是消息模式设计。例如和EAP系统对接时EAP需要发送“晶圆ID”和“产品Recipe名”来实现派工设备在上报S6F11时要把这些信息回传。消息的层级结构一复杂就需要仔细设计SML模板并针对各种异常情况做好FAIL响应。我们的经验是每个S6F11的发送都要带一个唯一的事件IDCollectionEventCEIDEAP侧依赖这个CEID做流程判断CEID一旦重复可能会触发整条产线的误判。3.4 与EAP系统对接的注意事项EAPEquipment Automation Program是厂里的“大脑”上位机是“手脚”。对接EAP时一般有两种数据通道一种是EAP直接通过SECS协议连接设备上位机作为透明代理另一种是上位机作为中间层先把设备数据采集到内存再统一转化成EAP定制格式。我们的项目属于后者原因是设备种类多、私有协议多统一到上位机这一层更方便做数据标准化。与EAP对接时最常被问到的是“实时性”和“可靠性”。EAP下发一个工单WaferStart命令上位机要在几百毫秒内响应ACK并且保证不丢消息。这里不能简单地用“收到即ACK”策略还必须考虑设备反馈的状态是否与命令匹配。比如EAP发S2F41要设备执行某个动作设备回S2F42的DATA里带B1状态为0表示成功状态非0表示失败。上位机要在S2F42返回给EAP之前就做出判断并决定是转发原消息还是中断事务。不要等到EAP侧来检查结果那样流程太慢。还有一点非常现实现场设备多、线程多绝不能把所有消息都挤在主线程里处理。建议用Channel或BlockingCollection构建一个消息队列专门负责接收和发送分流避免Socket接收阻塞后导致T3超时。最关键的消息处理比如S6F11事件上报要独立线程执行且处理时间不能超过T3的剩余时间。如果你在业务代码里不小心做了耗时操作比如数据库查询EAP侧就会看到一堆超时重试场面一度非常难看。4. 常见问题与排查技巧实录4.1 连接不稳定高频断线重连现象设备与上位机TCP连接经常断开日志里出现LinkTest超时或T6超时。排查步骤先看网络层用Wireshark抓包看TCP有没有RST、重传。常见原因是设备侧端口关闭、防火墙干预、或者交换机配置了空闲连接超时。再看HSMS层确认是否按照标准按时发送LinkTest。有些设备厂商对T8的要求很严我们遇到过一台设备要求Host必须以低于3秒的间隔发LinkTest否则它自己主动断开这种只能改成1秒一次。检查系统字节是否混乱如果System Bytes分配器出现问题比如重复使用了之前的System Bytes设备会把新消息当成旧回复导致事务错乱并断开连接。这里建议System Bytes使用一个持续递增的int32不要重启后从0开始否则设备端缓存的历史System Bytes可能会造成混淆。4.2 消息解析错误报“Invalid Header”或“Format Error”现象收到设备消息后解析失败显示“Unknown stream/function”或“Item length overflow”。这是最常见的坑通常原因有三个传输层头部10字节解析时没正确计算Message Length。HSMS的Message Length包含了自己10字节头很多新手解析时只把后面的数据体当长度差10个字节导致所有后续消息全部错位。SECS-II格式字节和长度字节解析不符合规范。尤其当数据长度超过255字节时长度字段位数会变有些库只支持单字节长度长消息就废了。设备厂商在消息里塞了不符合标准的私有数据类型。这时候不能硬解要先抓原始字节人工对照标准一点点剥。建议在代码里增加一个“传输层加密”日志选项记录原始十六进制方便回溯。排查这类问题最好的工具就是SML编辑器。可以用开源工具Secs4Net.SmlEditor把报错的消息日志粘贴进去它会自动格式化显示层级结构。如果自动格式化都失败基本就是消息不符合SECS-II语法。4.3 状态模型不同步设备明明在自动EAP却认为离线现象EAP界面显示设备离线但设备侧面板明明已经切到Remote/On-line。这个问题十有八九出在“S1F13建立通信”和“S1F14确认”阶段。因为GEM规定设备开机后要先和Host完成通信建立之后才进入可控制状态。如果上位机在上电启动后没有主动发S1F13设备就一直处于“Host未就绪”的状态但设备本身的自动化模式已经打开于是产生状态不同步。解决方式上位机启动后主动发S1F13并核查设备返回S1F14中是否带COMMACK0成功。注意极少数设备需要Host等待设备侧发来“响应”后再回S1F14顺序不能颠倒。另外S1F14的消息结构里有一个COMMACK参数和一堆标准设备信息列表。很多设备在COMMACK1时表示“无法建立”后续还会在LS字段里带具体原因。如果你只盯着COMMACK可能会漏掉真实问题。比如一台设备因为配方列表未加载完成拒绝与Host建立通信COMMACK1不读原因根本猜不到。4.4 性能瓶颈消息丢失和CPU飙升现象设备数量多时消息处理延迟越来越高偶发丢消息。首先要明白SECS消息是“有确认机制”的所以丢消息大概率不是因为网络而是业务处理没跟上导致T3超时后设备重发重发又堆积形成雪崩。处理建议使用异步IO避免在Socket发送/接收线程内做阻塞操作。消息处理线程池的大小不能太小建议至少和网络并发数一致。考虑用Channel实现生产者-消费者模式让收发和业务解耦。我们当时用.NET的System.Threading.Channels单条消息平均处理耗时从5ms下降到0.5ms。还要注意不要频繁在日志里输出完整SML尤其是高频率的S6F11事件上报会严重拖慢系统。我们做了动态日志级别切换默认只打印摘要出问题时再开FullLog。4.5 调试工具与模拟器推荐磨刀不误砍柴工。现场调试SECS协议三样工具我离不开SECS模拟器可以用VisualSecs工具或者自己写的简单模拟器配置好设备端行为后可以不分昼夜地测试上位机逻辑。尤其适合做异常场景测试比如突然断开TCP、发送畸形消息、长时间不回复等。Wireshark抓包确认HSMS/TCP层问题。注意Wireshark本身没有完整的HSMS解码器但看到TCP层数据已经够了主要看连接的建立、关闭通知和重传。如果想直接看SECS-II消息可以用Wireshark的增加了私有协议解析的插件也可以抓包后导成字节流再用SML编辑器解析。自己的调试命令行工具。我强烈建议在上位机里内置一个“调试窗口”允许输入SML消息并直接发送同时显示收到的原始消息。这个功能在现场解决“EAP说设备没发报警设备却说发了”这种扯皮问题时有奇效。我们后期甚至把这个调试窗口做成了带权限的保护模式只有工程师能开启。5. 后续扩展方向与个人体会如果你已经把上面的内容都消化得差不多建议接下来可以做两件事一是将协议层和业务层彻底分离封装成独立的CS库以后其他项目直接引用二是在上位机里加入配方管理、设备监控面板、数据统计报表等模块这些功能会让现场操作人员和EAP工程师都省心很多。我个人在实际操作中的体会是SECS协议最大的难度不在语法而在“标准与现实的差距”。你永远不知道设备厂商的“标准实现”里隐藏了多少私有逻辑所以调试日志一定要做足消息比对一定要用工具状态机一定要有可视化的面板。踩过一次坑记下这个坑比背一百遍SEMI规范都管用。最后分享一个小技巧如果你负责多条产线的设备对接建议给每类设备准备一份“报文模板配置”把SML模板、事件ID表、状态机参数都集中在一个配置文件里。这样换设备、换产线时不用改代码只改配置。我们在封测厂里就是靠这套配置化的思路把原本两周才能完成的上位机对接工作压缩到了三天关键是还不容易出错。这就是经验的力量希望这些内容对你有实际帮助。
前几年在半导体封测厂做设备自动化改造几乎每天晚上都要跟SECS协议打交道。设备厂商给的文档厚厚一摞核心却绕不开那几样东西SECS-I/HSMS怎么连SECS-II消息怎么拼怎么解GEM状态机怎么切。后来我们用C#从头写了一套上位机SECS通信框架一路踩了不少坑也沉淀了不少经验。这篇文章就把这些实操中的东西理一理给正准备碰SECS协议、或者想用C#做半导体设备上位机的朋友做一个参考内容覆盖传输层、消息层、GEM状态管理和EAP对接也包括一些调试工具和常见坑点。1. 内容整体设计与思路拆解1.1 SECS协议到底是什么为什么设备非要它SECSSEMI Equipment Communications Standard是半导体设备与工厂管理系统比如MES、EAP之间通信的一组标准协议由SEMI组织定义。它不是一个单层协议而是一组配套标准SECS-I负责物理传输RS-232HSMS负责以太网传输TCP/IPSECS-II定义消息内容和数据项的格式GEM则定义了设备行为的标准模型。为什么半导体行业对它有近乎执念的要求因为一条产线上的设备来自不同厂商光刻机、刻蚀机、清洗机、测试机每家都有自己的指令体系。如果每台设备都用私有协议对接MES系统会被逼疯。SECS/GEM存在的意义就是让大家讲同一种“普通话”——不管设备是谁造的消息格式、通信流程、状态上报方式都遵循同一套规范EAP系统才能统一调度和采集数据。值得注意的是SECS协议并不是一个“很现代”的协议它的设计带着上世纪80年代的痕迹。消息结构简单传输效率不算高但是极其稳定可靠所以在半导体、光伏、面板这些高价值制造领域至今仍是主流。即使新设备也开始支持更多现代接口SECS/GEM依然是工厂自动化的“基本盘”。1.2 为什么选择C#做上位机SECS通信我知道很多人会用C、Python或者LabVIEW做上位机但C#在半导体设备自动化场景里其实非常能打。开发效率高正好适配上位机这类需要频繁迭代的业务逻辑。半导体设备对接涉及大量消息解析、界面显示、配方管理、报警处理C#的语法简洁、内存管理友好写起来比C省太多心。和Windows生态结合紧密。绝大多数Fab里的上位机工控机是Windows系统C#对串口、TCP、多线程、日志、UI框架的支持都很成熟部署也简单装个.NET运行时就行。类库生态丰富。比如开源的Secs4Net已经帮我们封装好了HSMS通信和SECS-II消息模型省去了很多人肉解析字节流的工作。当然也有同行质疑C#在实时性上不如C。实际做下来SECS通信本身不是微秒级实时控制TCP连接的稳定性、消息解析的正确性才是关键。C#的异步编程模型async/await配合高性能Socket完全能撑住几十台设备同时通信。我们场里一台工控机同时管理6台封测设备的SECS连接消息量最大的时候一秒钟处理上百条S6F11报警上报C#依然稳如泰山。1.3 方案选型标准库还是自研所有对接SECS协议的项目第一阶段都会面临一个选择直接用现成库还是自己造轮子。这里没有标准答案关键是评估项目阶段和团队能力。当时的项目情况是设备类型杂有旧设备走SECS-I串口也有新设备走HSMSEAP系统要求自定义的SECS-II消息也很多。开源的Secs4Net虽好但它的消息模型比较“标准”面对各种私有扩展时不够灵活。后来我们决定以开源库为参考自己写一套核心通信层只依赖SEMI标准里的必要规范把消息模型完全交给上层业务。如果是中小型项目、设备相对标准直接用Secs4Net这种成熟库是完全够用的没必要自己从零开始。但如果你需要深度定制、或者想彻底搞清楚协议细节自研通信层其实也是很好的学习路线。后面章节里的代码示例会兼顾两种方式的思路核心逻辑是一样的。2. 核心细节解析与实操要点2.1 传输层SECS-I和HSMS一个都不能忽视SECS-I是古老的RS-232串口通信方式波特率通常9600使用CRC校验数据块长度最大256字节。很多老设备比如90年代的扩散炉、老式清洗机依然只支持SECS-I。用C#做SECS-I上位机时本质就是串口编程区别在于要在字节流里识别“块”的边界——SECS-I的块头有10个字节包含设备ID、块号、是否最后一块等标志。这里特别容易出错的是串口参数配置不匹配常见的有数据位7位、校验位EVEN、停止位1位跟普通Modbus串口的8-N-1完全不同。我第一次对接时就因为数据位没设置对设备一直回NAK排查了整整半天。HSMS则是基于TCP/IP的传输层分主动和被动两种模式。主动模式Active由上位机发起TCP连接被动模式Passive由设备发起连接。实际项目中设备的角色是固定的默认Equipment是PassiveHost是Active但有些老设备只支持主动连接这时候上位机就要监听端口。记住连接建立后还有一套HSMS通讯测试机制T5、T6、T7、T8定时器如果一段时间没消息双方会发送LinkTest请求确认链路存活。这在C#里用定时器就能实现但注意超时时间要按标准设置不是随便填的。说到HSMS消息头格式是固定的10字节Message Length4字节消息总长度包括消息头本身Session ID2字节通常是设备IDMessage Type1字节数据消息Data Message或控制消息Control MessageMessage Status1字节回复状态System Bytes4字节用于匹配请求和响应这个头结构是整个HSMS通信的地基。很多解析问题都出在System Bytes的处理上——例如发送请求后必须通过相同的System Bytes匹配对应的回复如果搞错整个事务就乱了。2.2 SECS-II消息编码从SML到二进制流SECS-II的消息格式是树状的。每个消息由Stream和Function编号唯一确定比如S1F13是“建立通信请求”S6F11是“事件报告发送”。消息内容由数据项Data Item组成数据项有类型、长度、值三要素常见的类型有Boolean、U1/U2/U4/U8、I1/I2/I4/I8、F4/F8、AASCII字符串、Bin二进制、List。这里最容易绕晕的是SECS-II的二进制编码不是简单的“类型长度值”它的格式控制字节里同时编码了数据类型和长度。比如一个ASCII字符串“SUB”编码为格式字节0x20类型A两个bit表示“单字节长度”的扩展方式长度字节0x03数据0x53 0x55 0x42对于List类型它的格式字节是0x01然后长度表示List里元素的个数。而List里的每个元素可能是任意SECS-II类型包括嵌套的List。这就导致消息解析不能按固定偏移量读必须写一个递归解析器按“读一个元素 - 如果是List就递归读里面的内容”这样的逻辑进行。平时我们阅读SECS-II消息时更多使用SMLSECS Message Language格式。举个例子S1F13 W L2 A MDLN A SOFTWARE VERSION 这就是一条S1F13请求建立通信的标准消息。写C#代码时我们一般用SML字符串作为外部接口然后内部解析成二进制流发送。解析器可以用简单的递归下降法也可以用现成库自带的功能。关键是要把“设备ID”“系统字节”“消息方向W位”这些元信息处理清楚。2.3 GEM状态模型设备行为都要符合规矩GEM标准把设备的行为抽象成几个核心模型通信状态模型、控制状态模型、处理状态模型、设备状态模型等。其中最容易让初接触者困惑的是控制状态模型Control State Model它有四个状态OFF设备不参与自动化EAP无法控制。ON-LINE READY设备在自动状态但当前没有正在处理的批次。ON-LINE ACTIVE设备正在自动处理中。OFF-LINE设备离线或手动模式。EAP系统下发指令控制设备的关键就是确认设备当前控制状态。例如设备在OFF-LINE状态时EAP发S2F41定义报告或S2F49扩展报告命令设备通常会回复错误提示“需要先切回ON-LINE状态”。我们做上位机时必须把这一层状态管理好——不是简单转发一下消息而是要维护一个本地状态机的副本根据收到的消息、设备上报的事件实时更新。GEM还定义了大量标准事件比如START_JOB、END_JOB、MACHINE_READY等等每个事件都要能传送给EAP。事件上报的流程通常是设备先上传S6F11事件消息EAP回S6F12确认。这里有一个容易忽略的点S6F11里的“报告数据”必须在发送前通过S2F33定义数据变量和S2F37定义事件提前配置好。否则设备不知道要发哪些数据变量给Host。2.4 C#中的关键数据结构与类设计在C#里实现SECS消息模型时建议用面向对象的方式定义消息类而不是散落的byte[]。我们当时的做法是用SecsMessage类表示一条完整消息包含Stream、Function、ReplyExpected是否期望回复、Data顶层数据项。用SecsItem基类表示数据项派生类包括SecsList、SecsAscii、SecsBinary、SecsU4、SecsI4等。每个派生类负责自己的编码和解码。用HsmsConnection类管理TCP连接和会话内部维护发送队列、超时调度、System Bytes递增器。用GemHandler类处理GEM状态机和标准消息S1F13/S1F14、S2F41/S2F42、S6F11/S6F12等。如果你用的Secs4Net库它已经有类似的设计但你还是应该在业务层再封装一层把设备厂商的私有扩展方法统一收口。比如我们对接某台测试机时消息里会带一个自定义的F4数组表示测试向量长度如果直接在业务里到处写解析代码后期换设备会很痛苦。3. 实操过程与核心环节实现3.1 准备开发环境与基础框架开发环境方面我推荐使用Visual Studio 2022.NET 6/8均可。如果目标工控机是Windows 10/11建议直接用.NET 6兼容性和性能都不错。引用NuGet包的话可以找Secs4Net最新版本支持.NET Standard 2.0老设备工控机也能用。如果是自研那只需要System.IO.Pipelines或System.Net.Sockets即可。搭建基础框架时建议先把日志系统搞好。SECS通信的日志极其重要因为问题往往发生在“报文差异”上。不光要记录发送和接收的原始字节还要记录解析后的SML、时间戳、系统字节、以及当时的状态机快照。日志格式可以采用结构化日志比如Serilog但也可以像我们一样直接写文本文件方便在Exineer级联查看。这里强烈建议打一条“完整日志”和一条“摘要日志”完整日志留档追踪摘要日志用于现场快速定位。3.2 实现HSMS连接管理主动/被动模式主动模式下C#实现大致如下代码var tcpClient new TcpClient(); await tcpClient.ConnectAsync(ip, port); var connection new HsmsConnection( deviceId: 0, isActive: true, socket: tcpClient.Client, messageHandler: OnMessageReceived); connection.Start();被动模式则稍有不同需要先开启一个TcpListener接受设备连接后创建HsmsConnection。注意对于被动模式收到设备连接后上位机需要主动发一条S1F13或者等待设备发S1F13完成“建立通信”。有些设备厂商在连接上来后立刻发S1F13Host只需要回S1F14即可有些则傻等Host先发S1F13这时候就需要我们的状态机去判断连接刚建立时应该由谁发起握手。这个细节如果不看调试日志真的会来回卡死。有关HSMS定时器有几个标准参数需要写在配置里T3回复超时默认45秒T5建立连接后未收到消息可等待时间默认10秒T6控制消息处理超时默认5秒T7连接空闲后未收到数据的时间默认10秒T8连接空闲后未收到LinkTest的时间默认5秒需要留意的是T8和T7是联动关系TCP连接建立后如果在这两个时间内都没有数据交互必须发送HSMS LinkTest控制消息确认链路。我们的经验是T8设置为5秒LinkTest的发送间隔不要超过T8的一半否则就会频繁触发断线。3.3 解析与发送SECS-II消息示例消息层代码最核心的就是解码。我用一段简化版的递归解码逻辑展示思路static SecsItem DecodeItem(ReadOnlySpanbyte buffer, ref int offset) { byte formatByte buffer[offset]; int type (formatByte 0xFC) 2; // 高6位是数据类型 int lengthBytes formatByte 0x03; // 低2位表示长度字段长度 uint len 0; for (int i 0; i lengthBytes; i) { len | (uint)buffer[offset] (8 * (lengthBytes - 1 - i)); } // 根据type决定是List还是Value if (type 0x01) // List { var list new SecsList(len); for (int i 0; i len; i) { list.Items.Add(DecodeItem(buffer, ref offset)); } return list; } else { var data buffer.Slice(offset, (int)len).ToArray(); offset (int)len; return new SecsValueItem(type, data); } }这里需要特别提醒长度字段可能存在“多字节”表示。当数据长度小于256时格式字节低两位为0长度字段占1字节长度在256~65535之间时低两位为1长度字段占2字节更大时低两位为2占4字节。解析时千万不能只按1字节读长度否则长消息一到解析就全乱了。发送SML消息则可以直接调用封装好的库或者自己的解析器// 使用Secs4Net风格 var msg new SecsMessage(1, 13) { ReplyExpected true, Data new SecsList { new SecsAscii(MDLN), new SecsAscii(SOFTWARE VERSION) } }; await connection.SendAsync(msg, cancellationToken);从业务角度看真正困难的是消息模式设计。例如和EAP系统对接时EAP需要发送“晶圆ID”和“产品Recipe名”来实现派工设备在上报S6F11时要把这些信息回传。消息的层级结构一复杂就需要仔细设计SML模板并针对各种异常情况做好FAIL响应。我们的经验是每个S6F11的发送都要带一个唯一的事件IDCollectionEventCEIDEAP侧依赖这个CEID做流程判断CEID一旦重复可能会触发整条产线的误判。3.4 与EAP系统对接的注意事项EAPEquipment Automation Program是厂里的“大脑”上位机是“手脚”。对接EAP时一般有两种数据通道一种是EAP直接通过SECS协议连接设备上位机作为透明代理另一种是上位机作为中间层先把设备数据采集到内存再统一转化成EAP定制格式。我们的项目属于后者原因是设备种类多、私有协议多统一到上位机这一层更方便做数据标准化。与EAP对接时最常被问到的是“实时性”和“可靠性”。EAP下发一个工单WaferStart命令上位机要在几百毫秒内响应ACK并且保证不丢消息。这里不能简单地用“收到即ACK”策略还必须考虑设备反馈的状态是否与命令匹配。比如EAP发S2F41要设备执行某个动作设备回S2F42的DATA里带B1状态为0表示成功状态非0表示失败。上位机要在S2F42返回给EAP之前就做出判断并决定是转发原消息还是中断事务。不要等到EAP侧来检查结果那样流程太慢。还有一点非常现实现场设备多、线程多绝不能把所有消息都挤在主线程里处理。建议用Channel或BlockingCollection构建一个消息队列专门负责接收和发送分流避免Socket接收阻塞后导致T3超时。最关键的消息处理比如S6F11事件上报要独立线程执行且处理时间不能超过T3的剩余时间。如果你在业务代码里不小心做了耗时操作比如数据库查询EAP侧就会看到一堆超时重试场面一度非常难看。4. 常见问题与排查技巧实录4.1 连接不稳定高频断线重连现象设备与上位机TCP连接经常断开日志里出现LinkTest超时或T6超时。排查步骤先看网络层用Wireshark抓包看TCP有没有RST、重传。常见原因是设备侧端口关闭、防火墙干预、或者交换机配置了空闲连接超时。再看HSMS层确认是否按照标准按时发送LinkTest。有些设备厂商对T8的要求很严我们遇到过一台设备要求Host必须以低于3秒的间隔发LinkTest否则它自己主动断开这种只能改成1秒一次。检查系统字节是否混乱如果System Bytes分配器出现问题比如重复使用了之前的System Bytes设备会把新消息当成旧回复导致事务错乱并断开连接。这里建议System Bytes使用一个持续递增的int32不要重启后从0开始否则设备端缓存的历史System Bytes可能会造成混淆。4.2 消息解析错误报“Invalid Header”或“Format Error”现象收到设备消息后解析失败显示“Unknown stream/function”或“Item length overflow”。这是最常见的坑通常原因有三个传输层头部10字节解析时没正确计算Message Length。HSMS的Message Length包含了自己10字节头很多新手解析时只把后面的数据体当长度差10个字节导致所有后续消息全部错位。SECS-II格式字节和长度字节解析不符合规范。尤其当数据长度超过255字节时长度字段位数会变有些库只支持单字节长度长消息就废了。设备厂商在消息里塞了不符合标准的私有数据类型。这时候不能硬解要先抓原始字节人工对照标准一点点剥。建议在代码里增加一个“传输层加密”日志选项记录原始十六进制方便回溯。排查这类问题最好的工具就是SML编辑器。可以用开源工具Secs4Net.SmlEditor把报错的消息日志粘贴进去它会自动格式化显示层级结构。如果自动格式化都失败基本就是消息不符合SECS-II语法。4.3 状态模型不同步设备明明在自动EAP却认为离线现象EAP界面显示设备离线但设备侧面板明明已经切到Remote/On-line。这个问题十有八九出在“S1F13建立通信”和“S1F14确认”阶段。因为GEM规定设备开机后要先和Host完成通信建立之后才进入可控制状态。如果上位机在上电启动后没有主动发S1F13设备就一直处于“Host未就绪”的状态但设备本身的自动化模式已经打开于是产生状态不同步。解决方式上位机启动后主动发S1F13并核查设备返回S1F14中是否带COMMACK0成功。注意极少数设备需要Host等待设备侧发来“响应”后再回S1F14顺序不能颠倒。另外S1F14的消息结构里有一个COMMACK参数和一堆标准设备信息列表。很多设备在COMMACK1时表示“无法建立”后续还会在LS字段里带具体原因。如果你只盯着COMMACK可能会漏掉真实问题。比如一台设备因为配方列表未加载完成拒绝与Host建立通信COMMACK1不读原因根本猜不到。4.4 性能瓶颈消息丢失和CPU飙升现象设备数量多时消息处理延迟越来越高偶发丢消息。首先要明白SECS消息是“有确认机制”的所以丢消息大概率不是因为网络而是业务处理没跟上导致T3超时后设备重发重发又堆积形成雪崩。处理建议使用异步IO避免在Socket发送/接收线程内做阻塞操作。消息处理线程池的大小不能太小建议至少和网络并发数一致。考虑用Channel实现生产者-消费者模式让收发和业务解耦。我们当时用.NET的System.Threading.Channels单条消息平均处理耗时从5ms下降到0.5ms。还要注意不要频繁在日志里输出完整SML尤其是高频率的S6F11事件上报会严重拖慢系统。我们做了动态日志级别切换默认只打印摘要出问题时再开FullLog。4.5 调试工具与模拟器推荐磨刀不误砍柴工。现场调试SECS协议三样工具我离不开SECS模拟器可以用VisualSecs工具或者自己写的简单模拟器配置好设备端行为后可以不分昼夜地测试上位机逻辑。尤其适合做异常场景测试比如突然断开TCP、发送畸形消息、长时间不回复等。Wireshark抓包确认HSMS/TCP层问题。注意Wireshark本身没有完整的HSMS解码器但看到TCP层数据已经够了主要看连接的建立、关闭通知和重传。如果想直接看SECS-II消息可以用Wireshark的增加了私有协议解析的插件也可以抓包后导成字节流再用SML编辑器解析。自己的调试命令行工具。我强烈建议在上位机里内置一个“调试窗口”允许输入SML消息并直接发送同时显示收到的原始消息。这个功能在现场解决“EAP说设备没发报警设备却说发了”这种扯皮问题时有奇效。我们后期甚至把这个调试窗口做成了带权限的保护模式只有工程师能开启。5. 后续扩展方向与个人体会如果你已经把上面的内容都消化得差不多建议接下来可以做两件事一是将协议层和业务层彻底分离封装成独立的CS库以后其他项目直接引用二是在上位机里加入配方管理、设备监控面板、数据统计报表等模块这些功能会让现场操作人员和EAP工程师都省心很多。我个人在实际操作中的体会是SECS协议最大的难度不在语法而在“标准与现实的差距”。你永远不知道设备厂商的“标准实现”里隐藏了多少私有逻辑所以调试日志一定要做足消息比对一定要用工具状态机一定要有可视化的面板。踩过一次坑记下这个坑比背一百遍SEMI规范都管用。最后分享一个小技巧如果你负责多条产线的设备对接建议给每类设备准备一份“报文模板配置”把SML模板、事件ID表、状态机参数都集中在一个配置文件里。这样换设备、换产线时不用改代码只改配置。我们在封测厂里就是靠这套配置化的思路把原本两周才能完成的上位机对接工作压缩到了三天关键是还不容易出错。这就是经验的力量希望这些内容对你有实际帮助。
