简介面向离散制造现场管控与学习演练场景这套基于C#开发的MES加工装配模拟系统提供了从基础档案、计划管理到实时看板的完整闭环。系统分为服务端与客户端服务端涵盖产品/物料档案、工序工位、工艺路线、加工与装配计划并带有实时监听与标签初始化工具客户端覆盖加工、装配及其搬运过程控制以及质量异常处理核心逻辑可通过数据库存储过程查阅便于二次开发学习。资源共445个文件以175个cs源码文件为主配合dll库、resx资源、txt说明、pdb调试符号及exe可执行程序等rar压缩包约10MB。开发环境为Visual Studio 2010与SQLServer2008R2.NET 4.0DB文件夹中附有可直接附加的数据库文件Doc文件夹内含《SimpleMES加工装配模拟系统》设计说明书适合有一定C#与数据库基础的制造信息化学习者参考。目前已有1457人学习下载。1. 为什么C#成了MES加工装配系统里最“稳”的那块基石做了八年制造业上位机和MES开发我发现一个挺反直觉的现象真正在车间里跑得最久的MES加工装配系统往往不是那些用了最新微服务架构的“云原生”方案而是用C#和.NET写出来的、看起来有点“老派”的Windows服务加WPF客户端组合。原因不复杂——MES加工装配系统的核心诉求从来不是技术多新而是和车间里的PLC、扫码枪、电子秤、老旧数据库的连通性以及一天三班倒连续运转下的稳定性。C#在这两件事上恰好有天然优势Windows生态的原生亲和力加上大量现成的工业通信库。这篇文章要讲的就是一套基于C#的MES生产制造系统到底怎么落地。我会从选型逻辑讲起拆解工单管理、报工、返工返修、设备数据采集这几个核心模块的实现路径再把我在现场踩过的坑一个个列出来。适合谁看准备用C#从零搭MES的团队、被现有MES系统折磨得想换技术栈的工程师以及刚入行想了解MES加工装配系统内部结构的开发者——这篇文章能让你们少走至少半年的弯路。2. C#做MES加工装配系统的选型逻辑不是因为它“高级”而是因为它“周全”MES加工装配系统的开发选型很多团队在第一轮讨论就会吵起来。Java派说生态丰富C#派说Windows下无缝集成还有人说用Python快速原型。我不否定其他技术栈但如果你面对的是传统制造企业的车间C#大概率是那个“下限最高”的选择。2.1 为什么是C#而非Java或Python三个不可回避的现实第一个现实是车间环境。制造业车间里的上位机、工控机、数据采集终端90%以上是Windows系统。C#开发的MES客户端直接跑在Windows上不需要像Java那样额外装JRE也不像Python那样要管理一堆依赖包环境。对于车间里那些配置不高、可能还装着十年前XP系统的老工控机来说一个自包含的.NET Framework 4.8 WinForms程序双击就能跑这是最实际的优点。第二个现实是设备通信。MES加工装配系统必然要和车间设备打交道——PLC、扫码枪、电子秤、Andon灯、LED看板。C#在这块有整个工业领域最成熟的方案西门子PLC可以用S7.NET或Sharp7库OPC UA有官方OPCFoundation的.NET Standard库串口通信有System.IO.PortsTCP/IP自定义协议更是C#的看家本领。这些库用起来是“开箱即用”的级别对比Java在工业通信库上的零散和Python在性能上的不足C#确实是更务实的选择。第三个现实是团队招聘。懂C#的开发者在中国制造业软件这个圈子里实在太多——因为上位机开发、桌面客户端开发、Unity3D开发都用C#。招一个能写业务逻辑又能调PLC的工程师在C#技术栈下远比在Java技术栈下容易。我见过太多MES项目死在“技术栈很酷但没人会写”的坑里C#至少不会让你为招人发愁。2.2 .NET版本选型Framework还是Core这是个问题这可能是C#做MES加工装配系统第一个需要拍板的事。我的建议很简单如果现场设备全是Windows且不需要跨平台用.NET Framework 4.8如果需要部署到Linux服务器或者是全新项目且团队对依赖注入、性能有更高要求用.NET 6或更高版本注意.NET 5已停止支持.NET Core 3.1也已停止支持别选这两个。.NET Framework 4.8的优点是稳定、生态老、第三方工业库兼容性最好——很多PLC通信库至今只提供.NET Framework版本。缺点是Windows Only且没有现代.NET的运行时性能优化。但MES系统本身不是高频计算场景瓶颈通常在外设通信和数据库所以Framework的性能劣势基本无感。我当前项目选的是.NET 6原因是我需要部署到一台Linux服务器上跑WebAPI同时车间工控机跑WPF客户端通过HTTP和它通信。架构上虽然复杂了一点但换来的是服务器端更好的内存管理和容器化便利性。如果你的MES加工装配系统规模不大单机部署或两台服务器就能搞定直接用.NET Framework 4.8反而省心。2.3 架构分层别把MES写成“上帝类”C#开发MES最容易犯的错误就是图快把业务逻辑全塞进窗体后台代码里。一个Form里两千行代码看着能跑实际上三个月后没人敢动。我的习惯是分四层界面层WPF/WinForms只负责展示和用户输入采集不写任何业务判断应用层Application Service处理业务用例比如“提交报工”这个动作的完整流程编排领域层Domain核心业务实体和规则比如工单状态机、返工流程定义基础设施层Infrastructure数据库访问、PLC通信、WebService调用、日志记录这套分层借鉴了DDD领域驱动设计的思想但不需要把DDD的全部概念都套进来——MES加工装配系统的核心是工单、工艺、物料、质量这四个领域先把这四个领域的实体和规则理清楚剩下的就是往框架里填。数据库访问我一般用SqlSugar或EF Core。SqlSugar在中小型MES项目里效率极高学习成本低支持读写分离和分库分表EF Core则适合团队熟悉微软技术栈的情况但复杂查询写起来不如SqlSugar顺手。从MES系统的报表和查询密集度来看SqlSugar在聚合查询和复杂SQL的支持上更灵活。如果让我推荐中小型MES用SqlSugar大型MES或者分布式部署再用EF Core加Dapper混合。3. 从工单到完工MES加工装配系统的核心业务流程拆解了解了选型之后接下来要解决的是MES加工装配系统的“骨架”——业务流程。很多团队做MES失败不是因为技术不行而是业务流程没理清楚就开始写代码。加工装配型企业的MES核心流程我用一句话概括工单下发 → 工序派工 → 领料投产 → 工序报工 → 质量检验 → 完工入库 → 返工返修。下面逐个环节讲怎么用C#实现。3.1 工单状态机设计用一个枚举和一张表管住生命周期工单是MES加工装配系统的灵魂它从创建到关闭要历经多个状态。我最开始做的时候每个状态转换都写if-else判断结果状态多了就乱套。后来改成用状态机模式代码清晰了一个数量级。工单状态我定义为枚举public enum OrderStatus { Created 0, // 已创建待下发 Released 1, // 已下发待投产 InProgress 2, // 生产中 PendingInspect 3, // 待检验 Completed 4, // 已完成 Closed 5, // 已关闭 OnHold 6, // 挂起异常暂停 Reworking 7 // 返工中 }状态流转的合法性校验放在领域层用一个静态类统一管理public static class OrderStatusRules { private static readonly DictionaryOrderStatus, ListOrderStatus _allowedTransitions new DictionaryOrderStatus, ListOrderStatus { { OrderStatus.Created, new ListOrderStatus { OrderStatus.Released, OrderStatus.Closed } }, { OrderStatus.Released, new ListOrderStatus { OrderStatus.InProgress, OrderStatus.OnHold } }, { OrderStatus.InProgress, new ListOrderStatus { OrderStatus.PendingInspect, OrderStatus.OnHold, OrderStatus.Reworking } }, { OrderStatus.PendingInspect, new ListOrderStatus { OrderStatus.Completed, OrderStatus.Reworking, OrderStatus.InProgress } }, { OrderStatus.Reworking, new ListOrderStatus { OrderStatus.PendingInspect, OrderStatus.InProgress } }, { OrderStatus.OnHold, new ListOrderStatus { OrderStatus.InProgress, OrderStatus.Closed } }, { OrderStatus.Completed, new ListOrderStatus { OrderStatus.Closed, OrderStatus.Reworking } } }; public static bool CanTransit(OrderStatus current, OrderStatus target) { return _allowedTransitions.ContainsKey(current) _allowedTransitions[current].Contains(target); } }逻辑说明这段代码把工单状态间允许的流转关系集中定义在一个字典里。比如“已创建”状态只能流转到“已下发”或“已关闭”不能直接跳到“生产中”。这样做的核心价值是所有调用方界面、接口、定时任务在做状态变更前统一走这个方法校验杜绝了非法流转的可能。参数说明字典的Key是当前状态Value是允许流转到的目标状态列表。如果业务上增加新状态比如“待领料”只需要改这个枚举和字典其他代码不用动。实际使用中建议再用一张数据库表记录状态流转历史OrderStatusHistory字段包括工单号、从状态、到状态、操作人、操作时间、备注便于事后追溯和审计。3.2 报工模块事务与并发控制的实战写法报工是MES加工装配系统里最频繁、最并发密集的操作。车间里多个工位同时报工同一张工单如果不加控制会出现超产或数量对不上的问题。这里的核心是数据库事务加行锁而不是靠代码里的lock——因为代码锁只对单机进程有效但MES服务器通常是多实例部署。我用的做法是在数据库层面用UPDLOCK加上ROWLOCK锁住工单行然后更新已完成数量using (var db new SqlSugarClient(connectionString)) { // 开启事务 db.Ado.BeginTran(); try { // 锁定工单行防止并发超产 var orderRow db.Ado.SqlQueryOrderForUpdate( SELECT Id, PlannedQty, CompletedQty FROM mes_order WITH (UPDLOCK, ROWLOCK) WHERE OrderNo OrderNo, new { OrderNo orderNo }).FirstOrDefault(); if (orderRow null) { throw new BusinessException(工单不存在); } if (orderRow.CompletedQty reportQty orderRow.PlannedQty) { throw new BusinessException(报工数量超出计划数量请检查输入); } // 更新完成数量 var affected db.Ado.ExecuteCommand( UPDATE mes_order SET CompletedQty CompletedQty Qty WHERE OrderNo OrderNo, new { Qty reportQty, OrderNo orderNo }); if (affected 0) { throw new BusinessException(工单状态已变化请刷新后重试); } // 插入报工记录 db.Ado.ExecuteCommand( INSERT INTO mes_report_record(OrderNo, ProcessCode, ReportQty, OperatorCode, ReportTime, StationCode) VALUES (OrderNo, ProcessCode, ReportQty, OperatorCode, GETDATE(), StationCode), new { OrderNo orderNo, ProcessCode processCode, ReportQty reportQty, OperatorCode operatorCode, StationCode stationCode }); db.Ado.CommitTran(); } catch { db.Ado.RollbackTran(); throw; } }逻辑说明第一步先查询工单当前完成数量查询语句里加了UPDLOCK和ROWLOCK——这意味着在事务提交前其他事务不能修改这一行从根源上杜绝了并发超产。第二步检查计划数量是否足够不够就抛业务异常。第三步更新完成数量并插入报工流水全部在同一个事务内要么全成功要么全回滚。参数说明UPDLOCK是更新锁ROWLOCK是行级锁。WITH (UPDLOCK, ROWLOCK)是SQL Server的锁提示语法如果是MySQL需要换成SELECT ... FOR UPDATE。事务隔离级别这里用的是默认的Read Committed加上行锁后已经能防住常规并发问题。注意一点报工记录表必须建索引常用查询条件为OrderNo ProcessCode ReportTime的组合索引否则数据量大了之后报表查询会很吃力。3.3 返工返修模块让“坏件”走一条独立的流转通道汽车水冷板这类产品加工过程中出现不良品是常态。返工返修模块如果做得太简单比如只是给工单加个“返工数量”字段后面追责和质量分析会一塌糊涂。我的做法是返工不走原工单流程而是生成一张独立的返工单。核心数据结构是两张表返工单主表ReworkOrder和返工明细表ReworkOrderDetail。主表记录返工原因、责任人、发现工序、返工类型返工/报废/让步接收明细表记录返工经过的工序、每个工序的检验结果、最终判定。在C#里我封装了专门的返工单领域服务public class ReworkService { public string CreateReworkOrder(string originalOrderNo, string processCode, string defectCode, int qty, string operatorCode, string reason) { if (qty 0) { throw new BusinessException(返工数量必须大于0); } // 生成返工单号RWO 日期 流水 string reworkNo $RWO{DateTime.Now:yyyyMMdd}{GetSequence():D4}; // 原工单标记为返工中 UpdateOriginalOrderStatus(originalOrderNo, OrderStatus.Reworking); // 插入返工单主表 // insert into rework_order(ReworkNo, OriginalOrderNo, DefectCode, Qty, OperatorCode, Status, Reason, CreateTime) // 根据产品工艺路线生成返工明细工序 var processList GetReworkRoute(originalOrderNo, defectCode); // insert into rework_order_detail(ReworkNo, ProcessCode, ProcessName, SeqNo, InspectResult, Status) return reworkNo; } private int GetSequence() { // 从数据库获取当天流水号用Redis或表计数均可 return _sequenceRepository.GetDailySequence(ReworkOrder); } }逻辑说明这段代码的核心思路是把返工当成一个“独立订单”来管而不是在原工单上修修补补。创建返工单时先把原工单状态置为“返工中”防止原工单被重复报工或关闭。返工工序路线可以按缺陷编码匹配对应的返工工艺路线。参数说明defectCode是缺陷编码对应质量体系里的缺陷分类比如“划伤”“尺寸超差”“漏工序”。返工工艺路线GetReworkRoute方法里查的是工艺基础数据表记录了每个缺陷码对应的返工工序列表。GetSequence()取的当天流水号要注意高并发环境下用数据库序列或Redis自增别用Guid做单号——车间师傅记不住打印标签也难看。3.4 装配防错与物料追溯BOM展开和批次关联加工装配型MES还有一个必不可少的模块装配防错和物料追溯。简单说就是装了什么物料、哪个批次、谁装的、什么时候装的必须全程可查。一旦终端客户投诉质量问题能在一小时内锁定问题批次范围。物料追溯的C#实现核心是“BOM展开 批次记录”public class BOMService { public ListBomItem ExplodeBom(string productCode, string orderNo null) { var result new ListBomItem(); // 递归展开BOM ExpandBomRecursive(productCode, result, 1, new HashSetstring()); return result; } private void ExpandBomRecursive(string productCode, ListBomItem result, int level, HashSetstring visited) { if (!visited.Add(productCode)) { // 防止BOM循环引用 throw new BusinessException($BOM存在循环引用请检查产品编码: {productCode}); } var childItems _bomRepository.GetChildren(productCode); foreach (var item in childItems) { result.Add(new BomItem { ProductCode item.ChildCode, ProductName item.ChildName, Quantity item.Quantity * (level 1 ? 1 : item.ParentQty), Level level }); // 如果子项也是装配件继续展开 if (item.IsAssembly) { ExpandBomRecursive(item.ChildCode, result, level 1, visited); } } } }逻辑说明ExplodeBom方法是递归展开产品物料清单。visited集合用来防止BOM表里出现循环引用比如A装配体包含BB又包含A这在数据维护错误时会出现不防护会死循环。记录装配批次时每个装配件和它的子件批次做关联绑定查询时通过“正向查子件反向查父件”完成双向追溯。参数说明item.Quantity * (level 1 ? 1 : item.ParentQty)算的是当前层级的实际用量当BOM有多层时逐层乘上去。实际使用中如果产品结构复杂、层级超过十层递归深度会导致性能下降建议增加一层缓存把展开结果存到MemoryCache或Redis里以ProductCode作为缓存键产品BOM变更时主动失效缓存。4. 打通车间最后一公里C#连接西门子PLC、OPC UA与上层系统的三个关键接口MES加工装配系统如果不同车间设备打通就是个“人工录入系统”生产效率数据全靠手输那不叫MES叫电子Excel。我这边把车间数据采集分成三条通路来讲西门子PLC用S7协议直连、OPC UA标准化采集、以及MES和上层ERP/APS的WebService接口对接。4.1 C#连接西门子PLC用Sharp7读写入料、出料信号西门子PLC在汽车零部件加工车间占有率极高。C#连S7系列PLC最成熟的开源库是Sharp7它不需要装Simatic Net走的是S7协议S7-200/300/1200/1500基本都支持。下面这段是封装好的PLC读写服务public class SiemensPlcService : IDisposable { private readonly string _plcIp; private readonly int _rack; private readonly int _slot; private S7Client _client; public SiemensPlcService(string plcIp, int rack 0, int slot 1) { _plcIp plcIp; _rack rack; _slot slot; _client new S7Client(); } public bool Connect() { var result _client.ConnectTo(_plcIp, _rack, _slot); if (result ! 0) { throw new Exception($PLC连接失败错误码: {result}IP: {_plcIp}); } return true; } public string ReadString(int dbNumber, int startByte, int maxLen) { var buffer new byte[maxLen 2]; // 前两个字节是字符串长度信息 var result _client.ReadArea(S7Area.DB, dbNumber, startByte, buffer.Length, buffer); if (result ! 0) { throw new Exception($PLC读取失败错误码: {result}); } return Encoding.ASCII.GetString(buffer, 2, buffer[1]).TrimEnd(\0); } public void WriteBit(int dbNumber, int startByte, int bitIndex, bool value) { var buffer new byte[1]; var result _client.ReadArea(S7Area.DB, dbNumber, startByte, 1, buffer); if (result ! 0) { throw new Exception($PLC读取失败错误码: {result}); } if (value) { buffer[0] (byte)(buffer[0] | (1 bitIndex)); } else { buffer[0] (byte)(buffer[0] ~(1 bitIndex)); } result _client.WriteArea(S7Area.DB, dbNumber, startByte, 1, buffer); if (result ! 0) { throw new Exception($PLC写入失败错误码: {result}); } } public void Dispose() { _client?.Disconnect(); _client?.Dispose(); } }逻辑说明这段代码封装了PLC连接、读取字符串、写入单个Bit三个最常用的操作。ConnectTo方法里第三个参数slot对S7-1200/1500是1对S7-300老机型要按硬件组态填。读字符串时S7的String类型前两个字节分别存储最大长度和当前长度真正数据从第3个字节开始所以代码里Encoding.ASCII.GetString(buffer, 2, buffer[1])是跳过头部取实际内容。参数说明dbNumber是数据块编号startByte是起始字节偏移这两个要和PLC工程师的符号表一一对应。我踩过一个坑PLC侧定义了一个String[20]类型的DB变量我读取时用了maxLen20结果缓冲区长度设为20没加头部的2字节越界读取导致数据乱码。记住String类型的实际存储占用是maxLen 2字节。另外Sharp7的标准缓冲区上限是1024字节超长数据需要分包读取。4.2 通过OPC UA统一采集平台解决“设备品牌多、协议乱”的标配姿势如果你的车间设备来自五六个不同品牌——西门子、三菱、台达、基恩士、还有各种非标设备——每台设备都写一套直连协议不现实。常见做法是部署一个OPC UA网关比如Kepware、KEPServerEX把底层各种协议S7、Modbus、MC Protocol等统一转换成OPC UAC#端只跟OPC UA服务器通信。C#用OPC UA官方库OPCFoundation.NetStandard.Opc.Ua连接的方式// 使用OPCFoundation.NetStandard.Opc.Ua包 public class OpcUaClientService { private readonly string _endpointUrl; private Session _session; private ConfiguredEndpoint _endpoint; public async Task ConnectAsync(string endpointUrl, string userName null, string password null) { _endpointUrl endpointUrl; _endpoint new ConfiguredEndpoint(null, new EndpointDescription { EndpointUrl endpointUrl, SecurityPolicyUri SecurityPolicies.Basic256Sha256, SecurityMode MessageSecurityMode.SignAndEncrypt }); var config ApplicationConfiguration.Create(MES Robots采集客户端); await config.CertificateValidator.Update( CertificateValidationOptions.TrustedPeerCertificates | CertificateValidationOptions.TrustedIssuerCertificates); var session await Session.Create( config, _endpoint, updateBeforeConnect: true, checkDomain: false, sessionName: MES-OpcUa-Session, sessionTimeout: 60000, identity: new UserIdentity(userName, password), preferredLocales: new[] { zh-CN }); _session session; } public async Taskobject ReadNodeValueAsync(string nodeId) { var node new NodeId(nodeId); var dataValue await _session.ReadValueAsync(node); return dataValue.Value; } public async Task WriteNodeValueAsync(string nodeId, object value) { var node new NodeId(nodeId); var dataValue new DataValue(new Variant(value)); await _session.WriteValueAsync(node, dataValue); } }逻辑说明Session.Create是整个连接动作的核心。updateBeforeConnect: true会让客户端先拉取服务器的端点配置自动匹配可用的安全策略。checkDomain: false表示不校验服务器证书的域名这在车间内网环境很实用因为很多工业网关证书常常签的不是IP而是主机名。参数说明nodeId是OPC UA的节点标识格式通常是ns2;sRobot1_Status或ns1;i1001。ns是命名空间索引每个OPC UA服务器可能有多个命名空间必须和服务器端的地址空间配置对应。读取频率方面不建议在循环里高频调用ReadValueAsync——我用200毫秒间隔轮询20个节点CPU占用率就接近20%了。规范做法是使用Subscription订阅机制服务器主动推送变化数据频率可以由SamplingInterval控制这也是OPC UA相对于轮询的最大优势。4.3 MES和ERP/WebService的接口设计异步与补偿别做同步死等MES加工装配系统的数据不是孤岛——生产计划从ERP下来到MES完工数据要回传给ERP。中间用WebService对接是市面上最普遍的做法。但让我反复叮嘱一句接口调用必须做超时控制和重试补偿不能同步死等。用C#做WebService客户端SOAP或REST都适用的超时控制public async TaskApiResultT CallErpApiAsyncT(string url, string requestBody, int timeoutSeconds 10) { using (var httpClient new HttpClient()) { httpClient.Timeout TimeSpan.FromSeconds(timeoutSeconds); var content new StringContent(requestBody, Encoding.UTF8, application/json); try { var response await httpClient.PostAsync(url, content); if (response.IsSuccessStatusCode) { var json await response.Content.ReadAsStringAsync(); return JsonSerializer.DeserializeApiResultT(json); } else { return ApiResultT.Fail($ERP接口返回错误: {(int)response.StatusCode}); } } catch (TaskCanceledException) { return ApiResultT.Fail($ERP接口调用超时{timeoutSeconds}秒); } catch (HttpRequestException ex) { return ApiResultT.Fail($ERP接口连接失败: {ex.Message}); } } }逻辑说明TaskCanceledException要特别注意——HttpClient.Timeout超时后抛出的就是这个异常而不是TimeoutException。这个异常也可能由操作取消比如页面关闭触发所以如果你要严格区分需要配合CancellationTokenSource来判断。我把调用结果封装成ApiResultT统一返回业务层拿到失败结果后决定是重试、记录错误还是转人工处理。参数说明timeoutSeconds我建议设置10秒左右——太短ERP大报表接口会超时太长MES这边事务会堆积。另一个重要参数是重试策略对查询类接口重试2-3次没问题对创建类接口重试务必谨慎因为网络超时可能有两种情况——请求没到达服务器或服务器处理成功但响应丢失。无脑重试会导致ERP里生成两条生产订单这时候宁可记录异常等人工核对也别自动重复提交。5. C# MES系统避坑指南五个让我半夜爬起来修问题的实战踩坑记录MES加工装配系统的坑很多不是写在文档里的是现场环境逼出来的。下面五条全是我自己经历过或者帮别人排查过的高频问题按“现象 → 原因 → 解决”写成每一条都值得你提前避开。5.1 坑一报工并发导致超产数量“对不上账”现象早上车间领班跑过来喊说一张工单计划100件报工数量加起来105件但车间实际没有多做。查数据库发现报工记录表里数量是正确的但工单的CompletedQty字段变成了105。原因没有用事务加行锁。两个人同时提交报工都先读到CompletedQty98都判断985103没超过100也有人为判断逻辑绕过的情况然后分别执行Update mes_order Set CompletedQty CompletedQty 5实际变成了103而此时计划数量是100应被拒绝却通过了。这是典型的并发读写未加锁导致的“丢失更新”。解决使用我前面第三节写的WITH (UPDLOCK, ROWLOCK)事务方案在更新前锁住工单行。另外在更新语句里加上条件CompletedQty Qty PlannedQty作为数据库层面的最终防线双重保险。改完之后跑并发压测100个线程同时报工数据始终正确这条坑算填上了。5.2 坑二OPC UA连接“偶尔断重连不回来”现象MES系统运行几天后采集服务报错“Server not responding”然后无论怎么重试都连不回来必须重启服务才能恢复。原因OPC UA连接超时设置不合理。服务器端保活KeepAlive超时设为30秒客户端却没有正确响应保活请求。车间里网络偶发抖动导致TCP连接在设备端被断开但客户端不知道一直认为连接还在重连逻辑没有触发。还有种情况是服务器证书过期但被缓存了。解决OPC UA客户端要做到三件事。第一开启订阅KeepAlive监听连续两次KeepAlive丢失就主动断开会话。第二设置合理的SessionTimeout和OperationTimeout比如前者30秒后者20秒。第三在掉线时执行完整重连流程先释放旧Session再重新调用Session.Create。我封装了心跳检查定时器每5秒检查一次会话状态确保“掉线即感知、感知即重连、重连必成功”。上线一年多这个问题再没复发过。5.3 坑三PLC读取字符串乱码数据带着“烫烫烫”之类的字样现象从西门子S7-1200读一段字符串型的产品序列号读出来前面有乱码或者空字符赋值给数据库字段后显示异常。原因S7的String类型存储格式和.NET的string不一样。S7的String实际结构是“最大长度1字节 当前长度1字节 数据区”如果数据区没填满剩余部分是0x00或0x20。直接用ReadArea读原始字节数组再用Encoding.ASCII.GetString转换会把头两个字节也转出来或者截取位置不对导致出现乱码和空字符。解决读取时长度的计算必须加上头部的2字节并按照第2个字节当前长度截取真实内容最后用Trim(\0, )清理填充字符。我给的代码示例里已经写清楚了var length buffer[1]; string result Encoding.ASCII.GetString(buffer, 2, length).Trim(\0, );这里还有个细节问题如果PLC侧定义的是WString宽字符串字节长度算法完全不同处理方式要改为Encoding.Unicode并用BitConverter解析长度。5.4 坑四接口重试导致ERP生成重复的生产订单现象MES完工数据传输到ERP后对方发现同一张工单的完工记录出现了两条数量翻倍。车间没有重复报工是接口层出的问题。原因调用ERP接口时网络超时MES端捕获到超时异常后自动重试。但超时的真实情况可能是ERP已经成功处理了请求只是响应在网络上丢了。重试时ERP里第二次写入造成了重复数据。解决对接入类的接口做“幂等控制”。最简单的办法是给每次请求生成一个唯一的RequestId存到ERP侧的接口日志表里。ERP接口处理前先查这个RequestId是否已存在存在则直接返回上一次的处理结果不再重复处理。MES端发送前用Guid.NewGuid().ToString(N)生成请求唯一码随请求体一起发送。这道工序虽然要ERP开发配合改一个查重逻辑但对数据一致性而言非常值得。5.5 坑五用Guid做主键索引碎片化让报表越跑越慢现象MES上线三个月后报表查询从秒级响应退化到十几秒甚至半分钟。查看数据库发现报工记录表、工序流转表的数据量也才几十万行但查询就是慢。原因用Guid作为主键和聚集索引。Guid是随机值插入数据时索引页频繁分裂产生大量碎片。几十万数据量其实不大但由于聚集索引完全随机每次范围查询都要随机IO。这是C#开发MES时最常见的“习惯性错误”——用C#就顺手用Guid.NewGuid()但完全没有考虑它在数据库索引结构下的恶劣表现。解决主键改用数据库自增BIGINT IDENTITY(1,1)工单号、报工单号等业务编号单独建字段并加唯一索引。如果是新项目这是最佳时机如果是老项目需要离线迁移数据并重建聚集索引。我后来团队规范直接定死所有表的主键一律BIGINT自增Guid只允许用于需要跨系统传输的ID比如接口对接的唯一标识。5.6 避坑方法论三个让MES系统少出一半问题的习惯这五条坑背后其实有三个共性方法论先写在这里供参考。第一MES是一个“事务密集型外设密集型”系统凡是涉及数量、状态、批次的操作默认都要考虑并发和事务边界。第二C#连接车间设备的能力很强但每种通信协议都有自己的“小性子”上位机代码写好后要做“断网—恢复”“设备重启—恢复”的专项测试而不是只测功能正常时的路径。第三MySQL、SQL Server性能问题的根源一半以上出在索引设计上MES这种高插入场景尤其要控制随机主键和冗余索引的数量。6. 一个让MES系统更抗用的进阶技巧用C#写一个“数据采集看板”的订阅推送机制到了最后一个部分想给一个不是必须做、但做了之后体验提升极大的进阶方案通过SignalR把MES的实时生产数据推送到车间看板和各工位平板同时用C#写一个系统健康自检的定时服务能在MES“悄悄出问题”之前就发出预警。MES加工装配系统上线初期车间看板的数据刷新方式大多是定时轮询——前端每5秒请求一次接口拿最新产量和状态。轮询的问题是如果MES服务端压力大或网络抖动接口响应变慢甚至会假死而那段时间看板显示的永远是旧数据现场管理人员就可能按错误信息做调度。用SignalR改造之后变成服务端主动推送只有工单状态发生变化、报工提交成功、设备故障报警这些“真正有变化”的时刻看板数据才会被推送更新。SignalR在C#里的实现分两步。第一步在WebAPI项目中注册SignalR服务并配置一个Hub// Program.cs或Startup.cs中注册 builder.Services.AddSignalR(); app.MapHubProductionHub(/productionHub);Hub类定义public class ProductionHub : Hub { // 前端订阅“工单进度”频道 public async Task SubscribeOrderProgress(string orderNo) { await Groups.AddToGroupAsync(Context.ConnectionId, $order-{orderNo}); } // 服务端推送工单进度变化由报工、状态变更业务触发 public async Task PushOrderProgress(string orderNo, OrderProgressDto dto) { await Clients.Group($order-{orderNo}).SendAsync(onOrderProgressChanged, dto); } }业务层在报工成功、工单状态流转、返工单创建时调用PushOrderProgress即可——注意客户端不要自绘进度推送过来的OrderProgressDto里包含工单号、完成数量、计划数量、进度百分比、当前状态。第二步是配套的“系统健康自检服务”。我用BackgroundService写了一个定时任务每30秒检查一次关键依赖数据库连接、OPC UA连接、PLC连接、ERP接口延迟。任何一项异常就直接投递报警——我这边是推送到企业微信机器人也可以换成钉钉或邮件。public class HealthCheckService : BackgroundService { private readonly IServiceProvider _services; private readonly ILoggerHealthCheckService _logger; public HealthCheckService(IServiceProvider services, ILoggerHealthCheckService logger) { _services services; _logger logger; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { try { using (var scope _services.CreateScope()) { var dbHealthy await CheckDatabaseAsync(); var plcHealthy await CheckPlcConnectionAsync(); var opcHealthy await CheckOpcSessionAsync(); if (!dbHealthy || !plcHealthy || !opcHealthy) { await NotifyAdminAsync(new { Database dbHealthy ? OK : FAIL, Plc plcHealthy ? OK : FAIL, OpcUa opcHealthy ? OK : FAIL, Time DateTime.Now }); } } } catch (Exception ex) { _logger.LogError(ex, 健康检查执行失败); } await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken); } } }逻辑说明BackgroundService是.NET内置的后台任务基类非常适合放这种“永远不会结束”的服务。注意CreateScope——因为HealthCheckService是单例注册的但里面用到的数据库上下文是Scoped生命周期直接从构造函数拿会报“Cannot access a disposed context”这种错误必须每次通过CreateScope创建一个新的服务范围。参数说明自检间隔30秒是经验值——太短会给自己服务造成压力太长则掉线感知太慢。CheckPlcConnectionAsync里用前面写的SiemensPlcService的_client.Ping方法OPC UA用会话的KeepAlive状态数据库检查则执行一句最轻量级查询比如SELECT 1。注意Ping是同步方法最好用Task.Run包一层的异步方式避免阻塞后台任务主循环。这个技巧做完后的实际效果是车间里看板数据永远“秒回”报工完成的瞬间进度动画就会更新不再有那几秒钟的“迟滞感”。更关键的是系统出异常之前——比如PLC快断连了、数据库连接池水位高了——维护人员能提前收到预警而不是等操作工报障了才知道。做MES这些年我最大的体会是这个领域没有太多“惊为天人”的技术创新拼的是对业务流程的理解、对现场设备通信的熟悉以及把代码写扎实的耐心。C#在整个链条里恰好是把这几件事串起来最顺手的语言。希望这套从选型到落地的经验能帮你在MES加工装配系统这条路上走得稳一点、快一点。希望帮到你。本文还有配套的精品资源点击获取
