简介面向半导体行业的C#上位机与设备集成开发人员一份成套的SECS/GEM通信集成方案围绕WinForm平台下的协议实现展开针对设备联机效率低、SECS消息交互复杂等核心问题提供可直接借鉴的快速开发路径适用于设备自动化、MES对接、工厂数据采集等场景。压缩包大小约为31.32MB内容以完整的C#源代码为主同时附有对接SECS的资料明细与实战例子代码中已集成大量业务逻辑和典型应用场景可直接复用或二次修改显著减少重复开发工作。目前已有630人学习浏览无论是刚接触SECS协议的新手还是需要优化现有通信平台的资深工程师都能从中获取可用经验。方案整合了多个工厂稳定运行过的集成经验宣称可将软件开发时间缩短80%对设备状态上报、消息处理、异常恢复等实际需求给出了明确的实现路径整体结构清晰便于对照学习与工程落地。1. 半导体设备通信从不上云SECS/GEM 是 C# 上位机绕不开的河半导体工厂里的刻蚀机、镀膜机、清洗机本质上都是设备厂商的闭环黑匣子但生产管理系统必须知道它们的状态、报警和批次进度。这个「设备 ⇋ 上位机」的通信标准就是半导体行业默认的 SECS/GEM。C# 配合 WinForm 做设备上位机在封装、清洗、后道测试环节非常常见所以「C# 上位机 SECS 协议」这个组合是很多转行半导体集成的工程师遇到的第一道坎——它不复杂但报文是十六进制、规范要收费、资料又碎很容易卡住你一两周。这篇按我实际踩过的路径把选型、握手、业务消息、避坑和自测一次讲透。2. 先看懂报文再谈集成E4/E5/E30/E37 到底约束了什么2.1 HSMS 报文长什么样一条十六进制消息拆开看SECS 家族里有四份标准经常被放在一起提E4SECS-IRS-232 物理层、E5SECS-II消息内容和编码、E30GEM设备行为模型、E37HSMSTCP/IP 上的传输层。现在新设备基本都是 HSMS也就是走 TCPE4 基本只有老设备还在用。你要写的 C# 上位机本质上是把 E5 的消息按 E37 的帧格式塞进 TCP 流。HSMS 的链路帧分两段前 4 字节是大端序的数据长度后面跟着 10 字节固定头加消息体。固定头里的关键字段是 Session ID两字节、Stream、Function、PType 和 SType。PType0 表示这是 SECS-II 数据消息SType0 表示正规数据帧SType1/2 是 HSMS 自己的选择握手Select.req / Select.rsp。举个例子设备识别请求 S1F13 的裸报文就是00 00 00 0A 00 00 01 0D 00 00拆开读就是长度 10只有头没有 body、Session ID 0、Stream1、Function13、PType0、SType0。C# 侧解析时不依赖任何协议库直接读字节就行。public readonly record struct HsmsHeader( uint Length, ushort SessionId, byte Stream, byte Function, byte PType, byte SType); public static HsmsHeader ParseHsmsHeader(byte[] frame) { // 前 4 字节是完整帧长度 header(10) body不包含这 4 字节本身 uint length (uint)((frame[0] 24) | (frame[1] 16) | (frame[2] 8) | frame[3]); ushort sessionId (ushort)((frame[4] 8) | frame[5]); return new HsmsHeader( length, sessionId, frame[6], frame[7], frame[8], frame[9]); }代码逻辑很直白重点在注释里说的「长度不包含长度字段自身」——这是 HSMS 和很多自定义协议不一样的地方写接收缓冲时要按 length 4 去等完整帧否则半包处理会错位。参数上记住两个默认值T3 是 45 秒的应答超时T6 是 5 秒的控制消息超时后文避坑会反复提到它们。2.2 SECS-II 的数据类型SML 和 C# 类型怎么对应E5 标准里消息内容用一种叫 SML 的写法描述最常见的是嵌套的尖括号列表。比如设备识别响应 S1F14 的规范写法是S1F14 W L A ETCH_01 A ETCHER-X L A SECS-II A 1.0 .SML 只是给人看的格式真实线上传输的是编码后的字节——每个数据项由一个头字节开头高四位是类型低四位是长度字段占几个字节。这门语言的核心类型不多L 是列表A 是 ASCII 字符串B 是二进制U4/U8 是无符号整数I4/I8 是有符号整数F4/F8 是浮点。对应到 C#A 就是 string。SECS-II 类型头字节高四位C# 类型说明L0x0List递归结构几乎每个消息最外层都是 LA0x4string只放 ASCII别塞中文B0x1byte[]配方等二进制大块U40xAuint大端序最常见的 ID 字段I40xDint有符号使用频率低于 U4F80xFdouble部分量测数据上报用上面那个 S1F14 编码成 hex 是01 03 41 07 45 54 43 48 5F 30 31 41 08 45 54 43 48 45 52 2D 58 01 02 41 07 53 45 43 53 2D 49 49 41 03 31 2E 30第一行01 03是 L 类型、长度区 1 字节、子项数 3然后是两个 A 字段分别携带设备名和型号再一个内层 L 带两个 A 字段装协议版本。你能看到每个 A 字段都是41开头、1 字节长度、跟着原始 ASCII 码。凡是报文解析出乱码先回来对照这里。提示SECS 报文整条链路都是大端序。C# 的 BitConverter 默认小端直接把字节数组转 int 是必翻车点之一习惯上我会手写字节拼接而不是依赖系统转换。2.3 选开源库还是自研三条路线与我的判断标准C# 侧做 SECS/GEM 的落地方式大致分成三类直接用开源协议库、把设备商提供的 C/C 动态库包一层、完全自研协议栈。网上很多「C# 与 SECS 集成资料大全 / 源码下载」打包资源拆开看基本也是这三类的变体。我的建议是先看对接设备的 GEM 手册再决定路线而不是先下代码。用开源库最省事库能覆盖 HSMS 收发、SML 解析和一部分 GEM 状态机但坑在版本和文档参差。下载回来的资料第一件事不是看界面长什么样而是先找它有没有独立的 HSMS 传输层和 SML 编码器只有这两块跑通了才谈得上业务。自研路线的工作量主要在长度字段处理和半包粘包真写起来也就是这两章的代码量级但你要有把握处理 E37 的控制消息时序否则联调时会非常被动。还有一条隐藏选择团队里偶尔会有人问上位机软件为什么不用 QT答案在存量产线——半导体后道环节的既有软件栈、操作员习惯和权限管理模型很多年前就定在 Windows 上了WinForm 就是主力。你在这个领域做 C# 上位机不用纠结框架把 SECS/GEM 这条链路啃通比换一个更时髦的 UI 框架有用得多。提示SEMI 标准原文在官网是收费的。很多设备厂商在招标配套资料里会给一份 GEM 手册摘录里面通常包含设备支持的 S/F 列表、数据项 ID 和默认超时配置。这份手册比任何二手资料都重要联调时它就是合同级别的依据。3. WinForm 跑通 SECS/GEM 最小闭环HSMS 握手与设备识别3.1 部署结构C# 侧做主动客户端还是被动服务端SECS/GEM 的通信模型里没有「客户端/服务端」的说法只有主动与被动主动方负责发起 TCP 连接被动方监听端口。设备厂商在 GEM 手册里会写明设备是主动还是被动。常见的是设备做被动方、上位机做主动方去连接也有部分设备在开机后反向向上位机发起连接这时 C# 侧反而要开 TcpListener。判断办法很简单问明设备 IP 和端口后先抓包看谁先连谁。实在没有环境就两边都实现把主动/被动做成配置项。WinForm 上位机在半导体项目里常驻操作员站一个配置文件控制模式切换比改代码优雅得多。// appsettings 风格配置节实际项目里我会放到独立配置类 public sealed class HsmsOptions { public string Mode { get; set; } Active; // Active / Passive public string DeviceIp { get; set; } 192.168.0.10; public int Port { get; set; } 5000; public ushort SessionId { get; set; } 0; public int T3 { get; set; } 45; // 应答超时秒 public int T6 { get; set; } 5; // 控制消息超时秒 }Mode 决定启动时执行主动连接还是被动监听。Session ID 在多数单设备场景下是 0只有在一条连接里跑多会话或者对端设备严格要求时才需要改。T3/T6 先按标准默认值联调时以设备方为准——有些老设备实际超时只有 15 秒C# 侧还按 45 秒等就会出现「这边还在等、那边已经断开」的假死现象。3.2 握手全流程TCP 连接、Select 握手和数据消息分开处理HSMS 的链路建立分两层先是 TCP 三次握手然后是 HSMS 自己的 Select 握手。很多第一次做的人拿到 TCP 连接成功就觉得链路通了直接在连接事件里发 S1F13结果设备不回——因为 HSMS 层还没确立链路。正确的顺序是TCP 建连 → 主动侧发 Select.req → 对端回 Select.rsp → 之后才能收发 S1/S2/S5/S6/S7 这类业务消息。// 主动模式建连后先发 Select.req再等 Select.rsp private async Task EstablishHsmsSessionAsync(TcpClient client, CancellationToken ct) { // Select.reqSType1Session ID 固定 0xFFFF无 body长度10 byte[] selectReq { 0x00, 0x00, 0x00, 0x0A, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x01 }; await client.GetStream().WriteAsync(selectReq, ct); var header await ReadHsmsHeaderAsync(client.GetStream(), ct); if (header.SType ! 2 || header.Length ! 11) throw new InvalidOperationException(Select.rsp 格式不对或超时); // 头之后还有 1 字节状态字0 表示接受 int status await ReadByteAsync(client.GetStream(), ct); if (status ! 0) throw new InvalidOperationException(设备拒绝这条 HSMS 会话); }这段代码的要点在 SType 判断收到 SType2 才说明对方接受了会话而不是拿业务消息的 PType 判断。状态字只有 0 才是接受非 0 基本是设备侧配置不允许这个 IP 或 Session ID。注意 Select.rsp 的 length 是 11比普通数据帧多出 1 字节的 body读头之后还要再补读一个字节漏读会让后续所有帧全部错位。业务消息的收发在这之后典型的设备上线流程是上位机发 S1F13 查询设备标识设备回 S1F14随后上位机发 S1F17 请求设备上线设备回 S1F18。S1F13 本身没有 bodyS1F14 的 body 就是上一章那个多层 L 结构。把这几个消息走通最小闭环就算立住了。3.3 UI 不卡的收包模型通信线程与 WinForm 界面分离WinForm 集成 SECS 最常见的坏味道是把报文接收写在窗体代码里、直接在回调里刷新控件。设备上报频繁时UI 线程被塞满不说通信线程一阻塞T3 超时设备就断链。我的做法是三层分离通信线程只负责读帧、解帧、入队UI 定时器每隔一小段批量取队列真正的业务处理放在消息路由那里。public partial class MainForm : Form { private readonly ConcurrentQueueHsmsMessage _inbox new(); private readonly CancellationTokenSource _cts new(); protected override void OnLoad(EventArgs e) { base.OnLoad(e); Task.Run(() ComLoopAsync(_cts.Token), _cts.Token); var timer new System.Windows.Forms.Timer { Interval 100 }; timer.Tick (_, _) DrainInbox(); timer.Start(); } private void DrainInbox() { while (_inbox.TryDequeue(out var msg)) { // 统一在这里转 UI通信线程绝不碰控件 AppendLog(${msg.Hdr.Stream}/{msg.Hdr.Function}); } } private void AppendLog(string line) { txtLog.AppendText(line \r\n); } }ConcurrentQueue 保证跨线程安全定时器批量消费降低 UI 刷新频率。日志区超过一定行数就裁剪防止操作员站跑几天后界面卡顿——这算是 WinForm 界面美化里最实用的一条先保证不卡再去谈配色和控件样式。通信线程里的具体收发循环不需要把每个消息都抛给 UI界面只关心人要看的状态其余走业务路由。注意通信循环里不要做任何同步等待 UI 的操作尤其是 MessageBox。SECS 的 T3 是 45 秒你一个弹窗卡住 1 分钟设备直接断开会话这是联调现场最常出现又最难查的「灵异断链」。4. 把报文变成业务动作事件上报、远程命令与配方的 C# 实现4.1 消息路由一张 S/F 分发表处理九成场景SECS 消息的种类由 Stream 和 Function 两个字节决定但设备能支持的 S/F 组合就那几十个GEM 手册里会全部列出来。C# 侧我会建一个路由表把 (Stream, Function) 映射到处理方法再处理「应答」配对的问题。SECS 没有请求 ID靠的是 Function 号惯例——请求通常是奇数、应答是偶数比如 S1F13 的应答是 S1F14。public sealed class SecsRouter { // Pending 表发请求时登记期望的应答 Function收到后取出回调 private readonly ConcurrentDictionary(byte, byte), FuncSecsMessage, HsmsSender, Task _pending new(); private readonly Dictionary(byte, byte), FuncSecsMessage, HsmsSender, Task _routes new(); public void Register(byte s, byte f, FuncSecsMessage, HsmsSender, Task handler) _routes[(s, f)] handler; public ValueTask DispatchAsync(SecsMessage msg, HsmsSender sender) { var sf (msg.Hdr.Stream, msg.Hdr.Function); if (_routes.TryGetValue(sf, out var route)) return new ValueTask(route(msg, sender)); return ValueTask.CompletedTask; } public void ExpectReply(byte s, byte f, FuncSecsMessage, HsmsSender, Task onReply) _pending[(s, f)] onReply; }路由表是顺手的写法核心逻辑在注释里主动下发的命令走 ExpectReply设备主动上抛的事件和报警走 Register。业务层不需要关心字节解析拿到的是已经解包好的 SecsMessage 对象。S2F41、S7F3 这类上位机主动动作全部用同一个模式代码量能控制得住。4.2 事件上报 S6F11/S6F12设备告诉我们发生了什么设备报警、批次完成、腔室状态变化都会以事件方式主动上报消息是 S6F11上位机必须回 S6F12 确认。这个机制是 GEM 的核心也是很多产线追溯数据的来源。S6F11 的 body 结构是一个列表先是 Report ID 的 U4 数据项再是数据值的列表具体哪些值会被上报由上位机在此之前用 S2F33/S2F34 等定义数据变量与事件集这部分在联调时配置代码里往往只留接口。// 组一个 S6F11 上报字节流ReportId 一组 U4 数据点 public static byte[] BuildS6F11(uint reportId, IReadOnlyListuint values) { var body new Listbyte { // 外层 L两个子项ReportId 和 内层数据列表 BuildItem(0x0, [2]), BuildItem(0xA, ToBe(reportId)), BuildItem(0x0, [(byte)values.Count]) }; foreach (var v in values) body.AddRange(BuildItem(0xA, ToBe(v))); return body.ToArray(); } private static byte[] BuildItem(byte formatHigh, byte[] data) { // 低 4 位 1表示长度区占 1 字节后面紧跟数据 var header (byte)((formatHigh 4) | 0x1); return [header, (byte)data.Length, .. data]; } private static byte[] ToBe(uint v) [(byte)(v 24), (byte)(v 16), (byte)(v 8), (byte)v];BuildItem 的第一个参数是高四位格式码0x0 是列表0xA 是 U40x4 是 ASCII。所有数值按大端序写入和 2.2 的编码表完全一致。这里有个实用的细节列表子项数量那个字节如果值超过 255低四位长度区必须改成 2 字节否则报文错位。实际设备一次上报的数据点很少超几百个但写代码时仍然要留这个分支。收到 S6F11 的回执是 S6F12body 是一个 U4 的确认码0 表示接受非 0 表示设备应该重发或做错误处理。回执要快别在 UI 线程里做数据库写入再回确认——设备端在等 Ack你慢一秒T3 就可能超时。4.3 配方下载与远程命令S7F3、S2F41 的典型调用方式配方Process Program是半导体设备的核心数据C# 上位机常用 S7F3 把配方内容发给设备。S7F3 的 body 是两层列表A 类型的配方 ID加上 B 类型的配方二进制内容。配方 ID 注意只能 ASCII设备端的配方命名规范通常带版本号拼 ID 的规则要和工艺工程师确认。public static byte[] BuildS7F3(string ppId, byte[] ppBody) { var body new Listbyte(); body.AddRange(BuildItem(0x0, [2])); // 外层 L2 个子项 body.AddRange(BuildItem(0x4, System.Text.Encoding.ASCII.GetBytes(ppId))); // PPID body.AddRange(BuildItem(0x1, ppBody)); // 配方内容 return body.ToArray(); }配方内容走 B 类型原样传送不进字符串解码。收发两边的配方格式完全是黑匣子C# 上位机只负责搬运和做校验和比如把配方文件哈希值放进 S7F5 的查询应答里具体内容解析是设备厂商的事。S2F41 远程命令和 S7F3 结构类似命令 ID 用 A 类型参数列表用 L 包一组数据项应答 S2F42 的结果码要先解析再决定界面上弹的是成功还是失败。提示配方内容如果很长S7F3 会变成一个大帧HSMS 长度字段本身有 4 字节、能表达 4GB但中间路由器和设备缓冲区往往有限。超大配方要按设备 GEM 手册要求分块不能靠 TCP 帮你拆——TCP 拆了设备侧的协议层也拼不回来。4.4 GEM 状态机上位机界面上的三态怎么体现GEM 把设备通信状态分成三大类OFF-LINE 表示设备手动维护、不参与自动生产ON-LINE / LOCAL 表示设备在线但在本地操作ON-LINE / REMOTE 表示接受远程自动化控制。C# 上位机界面上常见的就是这三个状态的颜色块。设备状态切换通过 S1F15/S1F16 和 S1F17/S1F18 这类消息配对完成上位机发起的上线请求是 S1F17设备同意后进入 ONLINE。设备状态含义上位机界面表现OFF-LINE设备本地维护不受控灰色禁用远程操作按钮ON-LINE LOCAL在线但人在设备端操作黄色可以发起 S1F17ON-LINE REMOTE完全由上位机/EAP 控制绿色正常发命令和配方界面状态要和消息闭环绑定收到 S1F18 的确认码为 0 才切到 ONLINE收到 S1F16 才切回 OFF-LINE。不要用设备上报的事件去猜状态会出「界面显示绿色、设备实际在维护」的乌龙。状态机在 C# 里用一个枚举加属性变化通知就能撑起来重点是消息与状态的对应关系要按 GEM 手册来这是这一章最容易理解错的部分。5. SECS/GEM 集成避坑从握手失败到数据错乱最磨人的 5 个坑做 SECS 集成最让人暴躁的是协议本身不难、但排错成本高报文肉眼不可读设备端又是一个黑匣子。下面这几条都是我实际踩过、或者带人联调时反复出现的按现象到解决写清楚能帮你省掉至少一周的加班。坑一TCP 连上了S1F13 发出去却石沉大海现象C# 侧 TcpClient 连接成功立刻发送 S1F13设备端没有任何回应T3 超时后链路断开。原因HSMS 的 Select 握手没有完成就把业务消息发出去了。TCP 建连只是第一步HSMS 层要求主动侧先发 Select.req、被动侧回 Select.rsp链路才算建立。很多人被「连接成功」误导跳过了这一步设备端的协议栈直接丢弃后续业务消息。解决按 3.2 的流程走先完成 Select 握手再发业务消息。抓包确认Select.req 的 SType1Select.rsp 的 SType2 且状态字为 0。这个问题在联调第一天出现频率最高确认顺序后就再也不会犯。坑二收到的 U4 数值变成十几亿的大数现象设备上报的数据点在 C# 侧读出来是 4294967295 这类离谱值报文看着却正常。原因字节序。SECS 协议全链路大端而 BitConverter 默认按小端读。比如报文里的00 00 01 2C表示十进制 300直接BitConverter.ToUInt32(byteArray, 0)会读成 0x2C010000自然变成天文数字。解决所有数值类型统一走大端 API比如BinaryPrimitives.ReadUInt32BigEndian和对应的大端写入方法禁止用默认小端转换。把这个规则写进团队代码规范里字节序问题一次就能根除。坑三设备名和配方 ID 显示成乱码现象S1F14 返回的设备名在界面上变成ECH_01或者配方列表里出现问号。原因A 类型只允许 ASCII有人用了 UTF-8 或直接把 C# string 的 Unicode 字节塞进报文。设备端按单字节 ASCII 解析多字节字符的每一个字节都被当独立字符乱码是必然。解决所有 A 类型字段统一用Encoding.ASCII.GetBytes写入解析时也用 ASCII。配方 ID、设备名、命令名这些字段写入前做一次 ASCII 范围检查超出 0x7F 的字符直接报错而不是默默截断。中文内容不允许出现在 A 字段里工艺备注走数据库不走 SECS 报文。坑四UI 弹窗把通信线程堵死设备主动断开现象设备上报异常后工程人员在收到报文的事件回调里直接弹出 MessageBox 确认结果消息发不出去、T3 超时设备把连接断掉连锁反应一大堆。原因WinForm 的 MessageBox 会阻塞调用线程。如果这个调用就是通信线程整个收发循环停摆。SECS 的 T3 短的话只有十几秒人点个确定绝对不止十几秒。解决通信线程里绝对不做任何阻塞 UI 的操作。上报的报警内容放进队列UI 定时器消费后弹窗确认结果再通过另一个命令通道回发。规矩定成一条通信线程只能碰 ConcurrentQueue 和日志缓冲违反这条的人自己值班。坑五列表子项数写死报文错位对端解析全乱现象S6F11 上报后设备回的错误码总在变或者对端解析出来的 Report ID 是对的、数据值全错位。原因SML 里 L 类型的子项数如果写死成固定值实际填入的数据项数量不一致整个报文的数据边界就从那个字节开始错位。比如外层 L 写死 2 个子项实际只填了 1 个后面所有解析都会偏移一个字节。解决组包时子项数从实际集合动态计算。列出数据点集合后先 Count 再写长度字节不要沿用历史代码里的幻数。这个坑在配方下载这类动态数据量大的场景最突出统一封装 BuildItem 后基本能免疫。6. 把模拟器做进调试闭环没有真机也能验证 SECS 链路开发阶段不一定拿得到设备尤其半导体设备动辄几百万一台等设备到场再联调时间根本不够。我一般会做两套模拟一套模拟设备方被动监听、回 S1F14一套模拟上位机主动连接、发 S1F13两边都跑通才敢说自己写的代码能见真机。最简单的设备模拟器就是前面代码的回放版TcpListener 监听设备端口收到 Select.req 回 Select.rsp收到 S1F13 回 S1F14收到 S6F11 就回 S6F12。逻辑不复杂但很重要——它能验证你上位机的完整握手链路、消息编码和 UI 响应。再进一步把你联调时抓到的真实报文存成 txt 文件模拟器按帧重放能复现很多只在特定设备版本上才会出现的问题。Wireshark 是 SECS 集成里最值得花时间学的排查工具。过滤条件用tcp.port 5000 and tcp.len 0就能看到完整的 HSMS 帧。排查顺序固定为先看 Select.req 有没有发出、再看 Select.rsp 状态字、最后看业务消息的 PType 和数据类型。一次真实的联调记录胜过十遍协议文档——我后来带人做 C# 上位机面试时也常问能不能画出一条 SECS 消息从发到回的完整时序。现在我的习惯是所有上位机代码上线前必须过一遍模拟器的双向自测再拿着报文记录去和工艺工程师核对消息内容。希望帮到你。本文还有配套的精品资源点击获取