回归继续更新C# 关于半导体协议相关知识这个系列断更了大半年一直有读者私信问还写不写。说实话不是不想写是去年下半年接了一个晶圆检测设备的通信模块改造几乎把所有业余时间都搭进去了。趁着这阵子项目收尾、手上有点余量把这次用C#重做SECS/GEM通信层的经验和教训整理出来算是兑现当时的承诺。在C#社区里聊半导体协议的人确实不多。大家平时接触的更多是Modbus、OPC UA这类通用工控协议而半导体行业里真正的主角——SECS/GEM资料少、门槛高、术语又特别劝退。但其实这套协议本身并不复杂复杂的是它背后的行业规范和历史包袱。这篇先起个头把协议族谱、技术选型、传输层实现、消息解析、状态机设计以及联调踩坑这几块完整串一遍给准备入坑或者已经在坑里的C#开发者一条能直接走通的路径。1. 这个系列为什么断更半年又回来写C#在半导体设备通信里的实际位置先聊点实在的。很多人以为半导体设备通信是高不可攀的东西只有用C/C写固件的人才能碰。但实际去半导体工厂转一圈就会发现设备端Equipment确实大量用C/C因为要跑在嵌入式控制器上资源受限。可到了主机端Host就不一样了——MES、EAP、RMS这些系统尤其是工厂侧的应用层软件很多跑在Windows服务器上用C#做上位机开发的团队比比皆是。我自己这次的项目就是一个典型场景。设备端是一台薄膜厚度测量仪控制器里跑的是厂商自己的固件对外只提供SECS/GEM接口。工厂的MES系统需要通过这个接口下发测量配方、获取测量结果、监控设备状态。原来的通信模块是设备厂商用C写的但工厂这边要把它集成进一套C#的EAP平台跨语言调用特别别扭而且原来那个模块的报文解析逻辑写得很死加一个新消息就要动一次底层代码。后来干脆决定用C#重写一个通信层把协议解析和业务逻辑彻底分开。这里顺便澄清一个误区SECS/GEM是纯软件层的通讯协议和硬件平台无关。它不要求你必须用什么语言只要你能跑TCP/IP、能做字节流的编解码就能实现。C#在异步IO、内存管理、调试工具链上的优势反而比C更适合做上位机侧的协议栈。还有一点很实际——行业内会写SECS/GEM的人太少了。半导体设备商有自己的协议栈团队但工厂端和应用集成商通常没有招聘市场上懂C#又懂SECS/GEM的人凤毛麟角。这个技能不是说多高深而是信息差太大会的人闷声发大财不会的人想学找不到门路。我这个系列就是想把这层窗户纸捅破。在正式开始之前先给新手一个整体认知。下面的表是我给团队新人的入门速查表也贴在这里缩写全称作用常见载体SECS-ISEMI Equipment Communications Standard 1基于RS-232的物理传输层串口已基本淘汰SECS-IISEMI E5消息内容和数据项的标准格式字节流中的消息体HSMSHigh-Speed Message Service基于TCP/IP的传输层网口当前主流GEMGeneric Equipment Model设备的行为模型和通信场景规范业务逻辑层一句话概括HSMS负责把字节流可靠地从A传到BSECS-II规定这些字节流里每条消息长什么样GEM定义设备在什么情况下应该发哪条消息。三者配合才形成一套完整的设备通信解决方案。2. 先把协议家族理清楚SECS-II管内容、HSMS管传输、GEM管行为很多初学者最困惑的一件事就是SECS/GEM到底是一套协议还是好几套协议答案是——它是一整套协议族由SEMI标准组织发布核心标准是E4SECS-I、E5SECS-II、E30GEM、E37HSMS。每一层解决不同的问题。2.1 SECS-II用Stream和Function给消息编号SECS-II规定了消息的编号方式每个消息用一个二元组SxFy标识S是Stream流F是Function功能号。比如 S1F13 表示建立通信请求S6F11 表示事件报告S5F1 表示报警上报。这套编号不是随便定的Stream大致按功能域划分S1是设备通信、S2是设备控制、S5是报警、S6是数据报告、S7是配方管理、S10是终端服务。Function的奇偶也有讲究——奇数通常是主动发出的请求Primary Message偶数是对方的应答Reply Message。比如 S1F13奇是设备端或Host端发出的建立通信请求S1F14偶是对方的应答。消息体则是一棵Item树。SECS-II定义了一组基础数据类型List、Binary、Boolean、ASCII、I8/I4/I2/I1、U8/U4/U2/U1、F8/F4。每个Item由格式码和长度描述组成可以嵌套组合最终构成任意复杂的消息结构。SMLSECS Message Language是这套结构的文本表示形式长这样S1F13 W L A MDLN A SOFTREV .含义是设备名和软件版本。这条消息在联调时几乎天天用是建立通信的第一步。2.2 HSMS把SECS-II塞进TCP/IPHSMS是当前最主流的传输载体默认端口是5000也可以由双方约定。它定义了一个10字节的报文头加上变长的消息体。报文头里最关键的几个字段是Session ID会话标识、SType消息类型区分数据消息和控制消息、Stream/Function/W位、System Bytes用于配对请求和应答。HSMS还有一组控制消息最常见的是Select.req/Select.rsp建立逻辑会话、Linktest.req/Linktest.rsp链路保活、Separate.req主动断链。控制消息和普通SECS-II数据消息走同一条TCP连接靠SType字段区分。这里有个关键概念HSMS的链接和TCP连接不是一回事。TCP连接建立起来之后还要通过Select会话协商设备才进入可通信状态。后面很多联调问题都出在TCP通着但HSMS逻辑会话没建立成功这种半吊子状态上。2.3 GEM给设备立规矩GEM是三层里最软的一层它定义设备应该有哪几种状态离线、在线本地、在线远程、状态怎么迁移、每个迁移事件发什么消息、报警怎么报、配方怎么管理、远程命令怎么处理。打个比方如果把SECS-II比作一套语法规则HSMS比作邮件系统那GEM就是业务流程SOP——什么时候该发邮件、邮件里该写什么、收到邮件后该怎么回。只实现前面两层设备能说话实现GEM设备才会干活。2.4 为什么这个系列用C#重写而不是调现成库市面上有成熟的SECS/GEM协议栈C/C和Java居多C#的成熟商业库也有但价格不菲。自己实现一套的好处有三点第一完全掌控协议细节出问题能直接定位到字节级第二可以针对项目需求裁剪不需要把整个GEM规范都实现一遍第三方便和业务深度集成把消息解析直接映射成C#的强类型模型而不是在XML和Dictionary里打转。缺点也很明显协议实现工作量大踩坑成本高。但掌握了核心原理之后这套东西可以沉淀成团队的通用组件后续接任何设备都能复用。我个人觉得这笔投入非常值得。3. 用C#落地HSMS传输层报文头、半包粘包与心跳保活HSMS传输层是整个协议栈的地基。这一步出错上面再漂亮的业务代码都是空中楼阁。这一节直接上C#实现的关键设计。3.1 HSMS报文头的字节结构先看报文头。HSMS的一条完整报文由四字节长度前缀、10字节报文头、以及可选的SECS-II消息体组成。用C#定义结构如下// HSMS 报文头固定10字节 // 偏移 长度 说明 // 0 2 Session ID会话标识 // 2 1 PType高2位 保留位低6位PType恒为0 // 3 1 SType消息类型 // 0x00 数据消息 // 0x01 Select.req // 0x02 Select.rsp // 0x03 Deselect.req // 0x04 Deselect.rsp // 0x05 Linktest.req // 0x06 Linktest.rsp // 0x07 Separate.req // 4 1 Stream数据消息有效 // 5 1 Function数据消息有效 // 6 1 W位0x00 或 0x80 // 7 3 System Bytes3字节用于事务配对 public sealed class HsmsHeader { public ushort SessionId; public byte PType; public byte SType; public byte Stream; public byte Function; public bool WBit; public byte[] SystemBytes new byte[3]; public byte[] ToBytes() { var buf new byte[10]; buf[0] (byte)(SessionId 8); buf[1] (byte)(SessionId 0xFF); buf[2] (byte)((PType 6) 0xC0); // 保留位填0 buf[3] SType; buf[4] Stream; buf[5] Function; buf[6] WBit ? (byte)0x80 : (byte)0x00; buf[7] SystemBytes[0]; buf[8] SystemBytes[1]; buf[9] SystemBytes[2]; return buf; } public static HsmsHeader FromBytes(byte[] buf, int offset) { var h new HsmsHeader(); h.SessionId (ushort)((buf[offset] 8) | buf[offset 1]); h.PType (byte)((buf[offset 2] 6) 0x03); h.SType buf[offset 3]; h.Stream buf[offset 4]; h.Function buf[offset 5]; h.WBit buf[offset 6] 0x80; h.SystemBytes new[] { buf[offset 7], buf[offset 8], buf[offset 9] }; return h; } }这套结构我用了很久稳定可靠。需要注意的一点是大端字节序问题。HSMS统一使用网络字节序大端而C#原生是适配小端环境的。直接用BitConverter转int的时候必须手动反转上面代码里写成移位运算就是为了规避这个问题。3.2 不坑死人不罢休的粘包与半包TCP是流式协议没有消息边界。你会收到任意切分的字节块可能一次来半个消息也可能一次来五个消息。处理方式只有一种维护一个接收缓冲区先读4字节长度再根据长度读完整消息。代码框架如下private readonly byte[] _recvBuffer new byte[16 * 1024]; private int _recvOffset; private readonly MemoryStream _frameStream new MemoryStream(); private void OnDataReceived(ReadOnlySpanbyte data) { _frameStream.Write(data); while (TryExtractFrame(_frameStream, out var frame)) { ProcessFrame(frame); } } private static bool TryExtractFrame(MemoryStream ms, out byte[] frame) { var lengthPrefixSpan ms.GetBuffer().AsSpan(0, (int)ms.Length - 4); if (ms.Length 4) { frame null; return false; } int totalLength (ms.GetBuffer()[0] 24) | (ms.GetBuffer()[1] 16) | (ms.GetBuffer()[2] 8) | ms.GetBuffer()[3]; // totalLength 是整个报文头部消息体的长度不含这4字节前缀 int fullFrameLength totalLength 4; if (ms.Length fullFrameLength) { frame null; return false; } frame ms.ToArray()[..fullFrameLength]; // 移除已消费的帧 var remain ms.ToArray()[fullFrameLength..]; ms.SetLength(0); ms.Write(remain); return true; }这段代码虽然能跑但用MemoryStream频繁ToArray其实是有性能浪费的。更好的方案是用链表缓冲或者环形缓冲。真正项目的并发量和消息量没那么大图省事用MemoryStream完全够但如果你要做一个面向多设备的高性能网关建议改成环形缓冲区。3.3 连接管理主动方、被动方与心跳保活HSMS通信双方分主动方Active/Initiator和被动方Passive/Target。主动方负责发起TCP连接、发起Select会话协商被动方监听端口接受连接。设备端通常是被动方等Host连它但有些场景反过来所以代码里建议把主动/被动做成配置项。Select会话协商的流程是主动方发Select.req被动方返回Select.rsp。这个协商可以理解为TCP连接之上再加一道业务握手。握手没完成之前即使TCP通着对方也不会处理你的SECS-II数据消息。握手完成后双方还要定期发Linktest.req来保活。半导体行业对通信稳定性要求极高一条链路静默太久设备可能已经死机或者网络已经中断所以HSMS规定了T7定时器连接空闲超时默认120秒——超过这个时间没有任何消息往来就发一个Linktest.req探活。在C#里用System.Threading.Timer做心跳最简单。每次收发消息时刷新看门狗时间超时则触发Linktestprivate Timer _linktestTimer; private void ResetLinktestTimer() { _linktestTimer?.Dispose(); _linktestTimer new Timer(OnLinktestTimeout, null, TimeSpan.FromSeconds(120), Timeout.InfiniteTimeSpan); } private void OnLinktestTimeout(object state) { SendControlMessage(HsmsSType.LinktestReq); ResetLinktestTimer(); }重连逻辑也要做好分层TCP断开后主动方应该在T5定时器连接重试间隔默认10秒的节奏下循环重连。这里有个经验之谈——不要用Thread.Sleep写死重连间隔要记录设备的状态机避免多个线程同时触发重连。用async/await实现循环重连比定时器更直观private async Task RunReconnectLoopAsync(CancellationToken ct) { while (!ct.IsCancellationRequested) { try { await ConnectAsync(ct); await RunSessionAsync(ct); // 阻塞直到连接断开 } catch (OperationCanceledException) { break; } catch { // 连接失败等待T5间隔后重试 } try { await Task.Delay(TimeSpan.FromSeconds(10), ct); } catch (OperationCanceledException) { break; } } }这套循环重连模型我在Windows服务里跑过几个月稳定性很好异常恢复后能自动回到正常通信状态。4. SECS-II消息体解析器的设计从字节流到Item树再到SML传输层跑通之后接下来是协议栈里最有意思的部分——SECS-II消息体的编解码。这一节讲清楚Item树的编码规则和一个C#解析器的核心设计。4.1 Item的二进制编码规则SECS-II的消息体是一棵Item树每个Item在字节流里由三部分构成格式码长度描述数据体。最关键的规则第一个字节的高4位是格式码Format Code低4位表示长度字段占用几个字节。长度字段紧跟在第一个字节后面使用大端字节序。List类型的长度字段表示子Item的个数其他类型表示数据体的字节数。数据体对于List是各子Item的连续编码对于其他类型是原始数据。举例说明SML文本A MDLN编码成二进制就是0x31 0x04 4D 44 4C 4E第一个字节0x31高4位是0x3ASCII低4位是0x1长度用1字节0x04表示4个字节数据后面跟着ASCII字符MDLN。再看一个嵌套例子S1F13 W L A MDLN A SOFTREV .编码后的Item就是一个ListList头的长度字段表示它有两个子Item0x01 0x02 0x31 0x04 4D 44 4C 4E 0x31 0x07 53 4F 46 54 52 45 56注这里List格式码是0x0加低4位长度字节数1所以是0x01。4.2 用C#定义Item模型递归完事C#这边我用下面这组类型来建模public abstract class SecsItem { public SecsFormat Format { get; protected set; } } public sealed class SecsList : SecsItem { public ListSecsItem Items { get; } new(); } public sealed class SecsAscii : SecsItem { public string Value { get; set; } } public sealed class SecsU4 : SecsItem { public uint Value { get; set; } } // 其他类型同理I4, U8, I8, F8, F4, Boolean, Binary...解析器就是一个递归下降的过程。每解析一个Item根据格式码判断是List还是基本类型如果是List就递归解析子Item直到叶子节点。这是面试级别的递归题但协议的坑在于处理长度字段的字节数、大端转换、还有List的嵌套边界。解析器的核心方法长这样简化版private static SecsItem ParseItem(ReadOnlySpanbyte buffer, ref int offset) { byte header buffer[offset]; int formatCode header 4; int lengthBytes header 0x0F; int length 0; for (int i 0; i lengthBytes; i) { length (length 8) | buffer[offset]; } // 根据格式码读取数据 switch ((SecsFormat)formatCode) { case SecsFormat.List: var list new SecsList(); for (int i 0; i length; i) { list.Items.Add(ParseItem(buffer, ref offset)); } return list; case SecsFormat.Ascii: var asciiStr Encoding.ASCII.GetString(buffer.Slice(offset, length)); offset length; return new SecsAscii { Value asciiStr }; // 其他类型同理... default: offset length; return new SecsBinary { RawData buffer.Slice(offset - length, length).ToArray() }; } }这里有个非常容易出错的地方lengthBytes的取值范围是1、2、3、4、8实际最常用的是1。当写编码器时需要根据数据长度动态决定用几个字节。比如一个字符串长度是3001个长度字节放不下就必须把低4位设为2并用2字节存长度。很多半路出家的实现只处理了lengthBytes1的情况遇到长payload直接崩。4.3 为什么这套编码叫应用到应用的旅行用这套模型发一条S1F13请求的完整过程就是var msg new SecsMessage(stream: 1, function: 13, wBit: true) { Body new SecsList { Items { new SecsAscii { Value _equipmentId }, new SecsAscii { Value _softwareVersion } } } }; var bytes EncodeMessage(msg); await _hsmsConnection.SendAsync(bytes);收到对端回复S1F14时解析出Item树直接把值取出来用。这套模型最爽的地方在于业务逻辑完全不碰字节流永远操作强类型对象。配合SML文本互转的工具方法联调时从报文日志里复制出来的SML可以直接变成C#对象反向也能把对象打印成SML格式来核对效率提升非常明显。4.4 消息日志和SML打印调试半导体协议日志必须要做到人能看懂。存原始字节的十六进制日志只是最后手段日常联调看的是SML文本。我给消息模型加了一个ToSml()方法递归输出消息文本比如S6F11 W L U4 123456 L U4 1 A WAFER_COMPLETE .有了这种日志和对方的软件工程师对接时往聊天记录里一贴人家立刻明白你发的是什么。比发一堆 hex 字符串效率高出一个量级。5. 状态机与事务管理让设备通信从能通变成合规传输层和解码层都有了两台机器之间确实能发消息了。但离真正的可用还差一步让这些消息的往来符合GEM定义的业务规范。这一节说事务管理和状态机设计。5.1 W位与事务配对SECS-II消息分两类带W位Wait bit的和不带W位的。带W位的消息是Primary Message发送方期待一个Reply不带W位的类似于通知发送完就完事。带W位的请求发出后靠System Bytes来配对回复。发请求时生成一个全局递增的System Bytes存进待回复字典收到回复时比对报文头里的System Bytes找到对应的等待任务并释放。用一个ConcurrentDictionary管理private readonly ConcurrentDictionaryint, TaskCompletionSourceSecsMessage _pendingTransactions new(); private async TaskSecsMessage SendPrimaryAsync(SecsMessage msg, int timeoutMs) { int sysBytes Interlocked.Increment(ref _sysBytesCounter) 0xFFFFFF; msg.Header.SystemBytes new[] { (byte)((sysBytes 16) 0xFF), (byte)((sysBytes 8) 0xFF), (byte)(sysBytes 0xFF) }; var tcs new TaskCompletionSourceSecsMessage( TaskCreationOptions.RunContinuationsAsynchronously); _pendingTransactions.TryAdd(sysBytes, tcs); sender.Post(msg); if (await Task.WhenAny(tcs.Task, Task.Delay(timeoutMs)) ! tcs.Task) { _pendingTransactions.TryRemove(sysBytes, out _); throw new TimeoutException($消息 {msg.Stream}/{msg.Function} 等待回复超时); } return tcs.Task.Result; } // 收到消息时按System Bytes匹配 private void HandleReply(HsmsHeader header, SecsMessage body) { int sysBytes (header.SystemBytes[0] 16) | (header.SystemBytes[1] 8) | header.SystemBytes[2]; if (_pendingTransactions.TryRemove(sysBytes, out var tcs)) { tcs.TrySetResult(body); } }这套设计里有一个细节很容易忽略回复消息本身也可能带W位。比如S1F14虽然是S1F13的回复但某些定义下它还需要对方再回一条S1F0来确认。处理这种情况时要判断收到的消息是回复还是新的主请求不能一股脑全当作回复去配对System Bytes。5.2 定时器家族T3、T5、T6、T7、T8GEM协议栈里有名目繁多的定时器每个都有自己管辖的范围。我把常用几个整理成表格定时器默认值作用T345秒等待Reply消息的超时时间T510秒主动方重连间隔T65秒等待控制消息响应的超时时间T7120秒连接空闲超时触发LinktestT85秒网络字符间超时用于检测半包残帧真正项目里这些值都建议做成可配置项。半导体行业对通信实时性要求高但不同厂商设备的默认值差异很大硬编码只会让联调时一地鸡毛。5.3 设备状态机GEM行为的最小实现GEM定义了设备的Control State离线/在线本地/在线远程和状态迁移事件。节流一下最小可用状态机至少要覆盖几个关键迁移设备开机启动后自动处于Off-line状态。收到Host的S1F13建立通信请求并成功应答后进入Online状态。Online状态下还可以细分Local和RemoteRemote状态下Host才能下发远程命令。设备发生故障时上报S5F1报警Host回复S5F2确认。我在项目里用了一个简单的状态枚举加状态转换表public enum ControlState { Offline, OnlineLocal, OnlineRemote } private ControlState _controlState ControlState.Offline; private void TransitTo(ControlState newState) { if (_controlState newState) return; var oldState _controlState; _controlState newState; // 状态变化时上报事件通知S6F11 _eventNotifier.NotifyStateChanged(oldState, newState); }这里有一个新手很难体会的经验GEM规范本身很庞大但你不需要一开始就全部实现。多数设备的实际需求场景就那么几种——建连、心跳、查状态、报警上报、配方下发、数据采集。先把这些主链路的状态机跑通剩下那些冷门的GEM行为等真遇到需求再按规范补就好。协议栈和业务之间保持清晰边界以后扩展不会伤筋动骨。5.4 远程命令与事件上报的套路远程命令的典型链路是Host发S2F41下发命令比如开始测量设备执行S2F42返回执行结果。事件上报的链路是设备检测到某事件比如一片晶圆测完主动发S6F11通知HostHost回S6F12确认。这两条链路几乎是所有SECS/GEM项目的核心做扎实了后面接什么设备都顺手。我在封装业务接口时把这两条链路抽象成事件委托public event FuncRemoteCommandInfo, CancellationToken, TaskRemoteCommandResult RemoteCommandReceived; public event ActionEquipmentEventInfo EquipmentEventOccurred;上层业务只需订阅事件、执行逻辑、返回结果协议栈内部的编解码、状态机流转全部被屏蔽掉了。这套抽象在接不同设备时非常省力——设备厂商的逻辑再千奇百怪到协议栈这一层都能归一到这几类交互上。6. 联调踩坑实录四个最隐蔽问题与排查链路这一节写点只有真刀真枪联调过才会遇到的东西。每个问题我都给出根因、排查过程和最终解法希望能帮后来人少走几个星期弯路。6.1 System Bytes被清零导致所有回复配不上对联调第一天就翻车。设备端接入后Host发S1F13过去对面回了S1F14但代码里怎么都匹配不上——请求发的System Bytes是0x00400001回复里带回的却是0x00000000。排查链路先在抓包工具里看完整报文确认回复确实带着数据。然后对比双方对报文头的解析——问题出在对端设备固件的一个老逻辑上它对回复消息的System Bytes做了强制清零只保留了低字节。这不是我们代码的问题是设备固件的兼容性设计。解法是在匹配时退化为如果System Bytes全零则匹配最近一条未完成的同Stream/Function请求并在配置里加开关控制是否启用这种宽松匹配。这个坑提醒我协议栈的容错设计非常重要。你以为规范是铁板一块但实际设备千奇百怪必须留出兼容策略。6.2 半包残留导致整帧错位一百多字节某次联调时通信在运行一段时间后突然全部消息解析失败日志里全是格式码不合法。排查后发现是接收缓冲区在解析完一帧后没有把残留的半帧数据正确拼入下一轮解析导致后续所有字节偏移了两个字节报文头里的长度字段全部错位。这类问题的排查思路很固定把原始收发字节流完整dump下来用十六进制视图逐帧核对边界。一旦发现长度前缀值和实际报文长度对不上基本可以断定是拼帧逻辑出了问题。后来我把帧提取逻辑重写为基于游标的纯增量解析彻底避免了残留数据二次拷贝造成的边界丢失。这也算是用一次事故教训换来的重构动力。6.3 控制消息和业务消息共用发送管道引发的优先级阻塞协议栈里Linktest.req是控制消息理论上应该优先发送——如果业务数据量大把TCP发送队列塞满心跳探活迟迟发不出去对端会认为链路已死并主动断开。第一次遇到这个问题现象是设备时不时掉线但TCP连接还在。抓包发现掉线前几分钟里全是大块的数据采集消息Linktest.req一直被堵在后面。解法是把控制消息和业务消息拆成两个发送队列控制消息走优先级通道。C#里用两层的Channel或者两个独立的写锁队列都能解决核心原则就一条心跳和控制指令永远不能被业务流量饿死。6.4 状态机响应乱序引发的重复建连最后一个是状态机设计的问题。主动方重连逻辑里如果没有等上一次连接的所有资源完全释放就开始下一次重连会出现两个TCP socket同时存在、两个Select.req来回交叉握手的情况设备端直接拒绝连接。排查链路查设备端日志发现同一时间收到了两个Socket的Select.req而设备端一次只允许一个HSMS会话。根因是Host端重连前没有完整取消旧的通信Task旧的读写循环还在跑。修复方法是给重连循环加一个会话Generation计数器每次重连递增旧循环发现Generation不匹配就自动退出。这个设计后来也用在其他多设备管理场景里效果很好。联调这一个月下来我最大的体会是写协议栈代码只要认真读规范、小心调字节序大部分基础功能都能一次写对。真正让人崩溃的永远是边缘场景——对方设备固件不按规范出牌、网络异常导致的半包错位、自己的状态机不够严谨。所以后面我做协议组件时都会把容错、熔断、兼容模式这些东西内置进去而不是等出了问题再去补救。如果你正打算用C#做半导体相关的设备通信项目建议从一个小而全的Demo入手实现HSMS的Select和Linktest再实现S1F13/S1F14、S6F11/S6F12、S2F41/S2F42这几个最常用的消息配合开源的SECS模拟器做联调。等这条链路完全走通你对整个协议族的理解会比看十遍规范都深。这个系列后续我准备再写两篇一篇专门讲SML和报表定义S2F33/S2F35一篇讲多设备网关的性能优化和监控设计到时候会把这次项目里沉淀的实践经验都拿上来聊。