C# MES源码实战：工单状态机与报工事务落地

简介这份资源是面向工业信息化开发者与.NET学习者的C# MES制造执行系统源码适合具备一定C#基础、希望理解工厂生产流程数字化实现方式的读者可用于学习系统架构设计、二次开发或项目定制参考。压缩包共95个文件约1.81MB以54个cs源文件为核心配合24个resx界面资源、5个dll第三方组件、3个sql建库脚本及sln解决方案、csproj工程与config配置等覆盖基础资料、数据采集、数据报表等模块目录按功能分层组织。已有3222人学习下载具备一定参考热度。源码中可看到三层架构划分、实体类数据建模、基于NPOI的报表导出、串口与网络通信采集、工作流与权限控制等实现思路并附有概要说明与基础模块文档便于读者对照理解MES从数据采集到报表呈现的完整链路为后续系统优化与功能扩展提供可复用的代码基础。1. 从一份 C# MES 源码说起车间数据采集与工单流转到底怎么落地车间里最怕的不是设备停机而是停机之后没人说得清这批料走到哪道工序了。纸质流转单靠人填批次追溯靠翻本子良率统计靠月底 Excel 拼表——这套流程在订单量小的时候还能撑订单一多就全是窟窿。这份 C# MES 系统源码解决的正是这个问题把工单下发、工序报工、批次追溯、设备状态采集这几件事收进一个桌面端管理系统里用 C# 把车间现场的数据流串起来。它适合两类人一类是想给中小制造场景搭一套轻量 MES 的开发者另一类是手里已经有源码、想搞清楚工单状态机和生产数据表怎么设计的二次开发人员。整套系统是典型的 C# 桌面应用形态服务端与客户端在同一套解决方案里数据库用关系型库承载工单、工序、报工记录读下去你会看到一条工单从创建到完工的完整链路是怎么被代码管住的。2. 技术栈与工程结构一套 C# 解决方案里装了什么2.1 技术选型为什么是 WinForms/WPF ADO.NET 这套组合中小制造现场的 MES 有个很现实的前提车间电脑配置一般操作工不需要浏览器双击就能开断网了本地还能继续报工。所以这类 C# MES 源码常见做法是桌面端客户端加本地或局域网数据库而不是一上来就搞前后端分离。技术栈大致落在这么几层层次常见技术选型在 MES 里承担的角色表现层WinForms 或 WPF工单列表、报工界面、看板业务层C# 类库BLL工单状态流转、报工校验、追溯查询数据访问层ADO.NET / Dapper / 轻量 ORM工单、工序、报工记录读写数据库SQL Server / SQLite / MySQL主数据与生产事务数据设备采集串口 / TCP Socket / 文件监听设备状态、产量计数我一般会先看解决方案里的项目划分而不是急着跑。因为 MES 这类系统的复杂度不在界面在业务层对状态和事务的处理。如果源码里 BLL 和 DAL 是分开的说明作者有分层意识二次开发时改业务规则不用动界面如果所有 SQL 都写在窗体事件里那改造前得先做一轮抽取否则加一个工序校验就要改五个界面。提示不同源码的具体 ORM 和数据库可能不同先看App.config或appsettings.json里的连接字符串再决定装哪个数据库。2.2 目录结构从解决方案文件往下看一份典型的 C# MES 源码解决方案.sln下通常挂这么几个项目MesSolution/ ├── Mes.sln ├── Mes.UI/ # 桌面客户端窗体与用户控件 │ ├── Forms/ │ │ ├── FrmWorkOrder.cs # 工单管理 │ │ ├── FrmReportWork.cs # 工序报工 │ │ └── FrmTrace.cs # 批次追溯 │ └── Program.cs ├── Mes.BLL/ # 业务逻辑状态机、校验、事务 │ ├── WorkOrderService.cs │ ├── ReportService.cs │ └── TraceService.cs ├── Mes.DAL/ # 数据访问SQL 与实体映射 │ ├── WorkOrderRepository.cs │ └── DbHelper.cs ├── Mes.Model/ # 实体类工单、工序、报工记录 │ ├── WorkOrder.cs │ ├── ProcessStep.cs │ └── ReportRecord.cs └── Mes.Common/ # 工具类日志、配置、枚举 ├── Logger.cs └── Enums.cs这个结构的关键在于Mes.Model里的实体和Mes.BLL里的服务。工单状态、工序顺序、报工合法性这些规则正常都收在 BLL 里UI 只负责收集输入和展示结果。拿到源码后先确认这一点如果FrmReportWork.cs里直接拼 SQL 更新工单状态那这套代码的维护成本会比较高二次开发前建议先把数据访问抽到 DAL。2.3 数据库表工单、工序、报工三张核心表的关系MES 的数据模型绕不开三张表工单表、工序表、报工记录表。工单是生产任务的主线工序定义这道工单要经过哪些步骤报工记录则是每次实际发生的生产动作。常见设计如下-- 工单主表一条工单对应一个生产批次 CREATE TABLE WorkOrder ( OrderId VARCHAR(32) PRIMARY KEY, -- 工单号 ProductCode VARCHAR(32) NOT NULL, -- 产品编码 PlanQty INT NOT NULL, -- 计划数量 FinishedQty INT DEFAULT 0, -- 已完工数量 Status INT DEFAULT 0, -- 0待生产 1生产中 2已完工 CreateTime DATETIME DEFAULT GETDATE() ); -- 工序表工单与工序的一对多关系 CREATE TABLE ProcessStep ( StepId INT IDENTITY PRIMARY KEY, OrderId VARCHAR(32) NOT NULL, -- 所属工单 StepNo INT NOT NULL, -- 工序顺序号 StepName VARCHAR(64) NOT NULL, -- 工序名称 Status INT DEFAULT 0 -- 工序状态 ); -- 报工记录每次报工一条用于追溯和良率统计 CREATE TABLE ReportRecord ( ReportId BIGINT IDENTITY PRIMARY KEY, OrderId VARCHAR(32) NOT NULL, StepNo INT NOT NULL, GoodQty INT NOT NULL, -- 良品数 BadQty INT DEFAULT 0, -- 不良数 Operator VARCHAR(32), -- 操作工 ReportTime DATETIME DEFAULT GETDATE() );WorkOrder.Status和ProcessStep.Status是两个独立的状态维度工单整体状态由所有工序的完成情况推导工序状态则由报工记录驱动。二次开发时最容易踩的坑就是只更新工单状态、忘了同步工序状态导致看板上工单显示完工但工序还挂着“生产中”。追溯查询本质上就是按OrderId把三张表串起来从报工记录反查工序、再反查工单和产品。3. 核心链路拆解工单状态机与报工事务怎么写3.1 工单状态流转一个枚举管住所有非法跳转工单状态如果散落在各个窗体的if里早晚会出现“已完工的工单还能再报工”这种脏数据。合格的做法是把状态定义成枚举把合法跳转收进一个方法里统一判断public enum OrderStatus { Pending 0, // 待生产 InProcess 1, // 生产中 Completed 2, // 已完工 Closed 3 // 已关闭 } public class WorkOrderService { // 状态流转白名单只允许这些跳转 private static readonly DictionaryOrderStatus, OrderStatus[] Allowed new DictionaryOrderStatus, OrderStatus[] { { OrderStatus.Pending, new[] { OrderStatus.InProcess, OrderStatus.Closed } }, { OrderStatus.InProcess, new[] { OrderStatus.Completed, OrderStatus.Closed } }, { OrderStatus.Completed, new OrderStatus[0] }, { OrderStatus.Closed, new OrderStatus[0] } }; public void ChangeStatus(string orderId, OrderStatus target) { var order _repo.GetById(orderId); if (order null) throw new Exception(工单不存在); // 不在白名单里的跳转直接拒绝避免脏状态 if (!Allowed[order.Status].Contains(target)) throw new Exception($非法状态跳转{order.Status} - {target}); _repo.UpdateStatus(orderId, target); } }这段代码的价值在于把“什么状态能变成什么状态”变成一张可读的表。Allowed字典就是状态机的边集ChangeStatus是唯一的入口。参数orderId定位工单target是目标状态。二次开发要加“暂停”状态时只需要在枚举和字典里各加一项不用去翻每个窗体。我见过不少源码把状态判断写成if (status 0 || status 1)这种加一个状态就要全局搜索血泪经验就是状态机一定要收口。3.2 报工事务良品数、不良数与工单完工量必须一起提交报工是 MES 里最频繁的写操作也是最容易出数据不一致的地方。一次报工至少要动三处插入报工记录、累加工单完工数、判断是否触发工序或工单完工。这三步必须在一个事务里否则中途失败就会出现“报了工但工单数量没加”的黑匣子数据public void ReportWork(string orderId, int stepNo, int goodQty, int badQty, string op) { if (goodQty 0 || badQty 0) throw new Exception(报工数量不能为负); using (var conn DbHelper.CreateConnection()) using (var tran conn.BeginTransaction()) { try { // 1. 写报工记录 _reportRepo.Insert(conn, tran, new ReportRecord { OrderId orderId, StepNo stepNo, GoodQty goodQty, BadQty badQty, Operator op }); // 2. 累加工单完工数只加良品 _orderRepo.AddFinishedQty(conn, tran, orderId, goodQty); // 3. 判断工单是否全部工序完成完成则置为已完工 if (_orderRepo.IsAllStepsDone(conn, tran, orderId)) _orderRepo.UpdateStatus(conn, tran, orderId, OrderStatus.Completed); tran.Commit(); } catch { tran.Rollback(); throw; } } }参数含义很直白goodQty进完工数badQty只进报工记录用于良率统计不参与完工判断。IsAllStepsDone是判断完工的关键它按OrderId查工序表确认每道工序的累计良品数都达到计划数。这里有个容易忽略的点完工判断要放在事务内、累加之后否则并发报工时两个线程可能都判断“未完工”导致工单永远停在生产中。常见做法是在AddFinishedQty里用UPDATE ... SET FinishedQty FinishedQty qty的原子写法再配合行锁。3.3 批次追溯查询一条 SQL 串起工单到报工的全链路追溯功能是 MES 的门面客户审核时第一个问的就是“这批货用了哪些料、经过哪些工序、谁做的”。追溯查询不需要复杂逻辑核心是把三张表按工单号关联起来按工序顺序和报工时间排序public ListTraceItem GetTrace(string orderId) { const string sql SELECT w.OrderId, w.ProductCode, p.StepNo, p.StepName, r.GoodQty, r.BadQty, r.Operator, r.ReportTime FROM WorkOrder w JOIN ProcessStep p ON p.OrderId w.OrderId LEFT JOIN ReportRecord r ON r.OrderId p.OrderId AND r.StepNo p.StepNo WHERE w.OrderId orderId ORDER BY p.StepNo, r.ReportTime; using (var conn DbHelper.CreateConnection()) return conn.QueryTraceItem(sql, new { orderId }).ToList(); }LEFT JOIN报工记录是有意为之某道工序还没开始报工时追溯结果里也要显示这道工序只是报工字段为空这样界面能看出“卡在哪道工序”。ORDER BY p.StepNo, r.ReportTime保证同一工序多次报工按时间排列。参数只有一个orderId如果要做产品级追溯同一产品多个工单把WHERE换成ProductCode即可。翻车点在于报工记录表数据量大之后这个查询会慢常见做法是给ReportRecord(OrderId, StepNo)建联合索引追溯页面再加个时间范围过滤。4. 跑起来环境准备、数据库初始化与首次登录4.1 环境与依赖装对 .NET 版本比什么都重要C# 桌面项目的第一个坑往往不是代码是运行时版本对不上。拿到源码先看.csproj里的TargetFramework如果是net48需要装 .NET Framework 4.8如果是net6.0-windows或net8.0-windows需要对应的 .NET 桌面运行时。用 Visual Studio 打开.sln最省事它会提示缺哪个组件。命令行方式可以先还原依赖# 还原 NuGet 包在解决方案目录执行 dotnet restore Mes.sln # 编译整个解决方案 dotnet build Mes.sln -c Debug如果项目是老式.csproj格式dotnet build可能不认那就直接用 Visual Studio 的“生成解决方案”。数据库方面看连接字符串决定装 SQL Server Express 还是直接用 SQLite 文件。SQLite 的好处是零安装适合先跑通再换正式库。4.2 数据库初始化建表脚本与初始账号源码里一般会带一个Database或Sql目录里面是建表脚本和初始数据。执行顺序通常是先建库、再建表、最后插基础数据用户、产品、工序模板。以 SQL Server 为例-- 1. 建库 CREATE DATABASE MesDb; GO USE MesDb; GO -- 2. 执行源码里的建表脚本WorkOrder / ProcessStep / ReportRecord 等 -- 3. 插入初始管理员账号 INSERT INTO SysUser (UserName, Password, Role) VALUES (admin, 初始密码哈希, Admin);初始密码如果是明文存储第一次登录后务必改掉二次开发时建议顺手把密码改成哈希存储。连接字符串在App.config的connectionStrings节点或appsettings.json里改成你本机的实例名和账号密码。这一步翻车最多的情况是实例名写错比如默认实例和SQLEXPRESS实例混淆报错通常是“无法连接到服务器”先确认 SQL Server 服务已启动、TCP/IP 协议已启用。4.3 首次运行与冒烟验证走一遍工单到报工编译通过、数据库连上之后别急着看所有功能先走一条最小链路验证系统是活的新建一张工单 → 给工单配两道工序 → 对第一道工序报工 → 看工单状态是否变成生产中 → 两道工序都报满 → 看工单是否自动完工。这条链路走通说明状态机、事务、完工判断三块核心逻辑都是好的。操作路径示例 工单管理 - 新建工单产品编码、计划数量 工序配置 - 为该工单添加工序 10/20 工序报工 - 选工序 10良品数 计划数提交 工单列表 - 确认状态 生产中 工序报工 - 选工序 20良品数 计划数提交 工单列表 - 确认状态 已完工如果报工后状态没变先查ReportRecord有没有插入成功再查WorkOrder.FinishedQty有没有累加最后查IsAllStepsDone的判断条件是不是要求“每道工序良品数等于计划数”——有些源码写的是大于等于有些写的是严格相等报工数量超计划时行为会不一样。5. 避坑与排查这套 MES 源码最容易翻车的五个地方5.1 报工后工单状态不更新现象报工记录插进去了工单列表刷新后状态还是“待生产”。原因多半是完工判断或状态更新没放在同一个事务里或者IsAllStepsDone查的是工序表但工序状态从来没被更新过。解决先手动查ProcessStep的Status字段确认报工时有没有同步更新工序状态再检查ChangeStatus的白名单里是否允许Pending - InProcess。如果工序状态一直是 0说明报工逻辑漏了更新工序这一步补上即可。5.2 并发报工导致完工数翻倍或丢失现象两个操作工同时报同一张工单完工数比实际多或者少。原因是用“先查再改”的写法var qty GetQty(); UpdateQty(qty goodQty);两个线程读到同一个旧值。解决改成数据库端原子累加UPDATE WorkOrder SET FinishedQty FinishedQty qty WHERE OrderId id并在事务里对工单行加锁SQL Server 可用WITH (UPDLOCK)。这是并发场景下的经典坑单机测试永远测不出来。5.3 追溯查询查不到未报工的工序现象追溯页面只显示已报工的工序没开始的工序直接消失看不出卡在哪。原因是用了INNER JOIN ReportRecord。解决改成LEFT JOIN并在界面上对报工字段为空的工序标注“未开始”。这个改动很小但对生产排障的价值很大车间主任最关心的就是“这批货现在停在哪”。5.4 数据库连接字符串写死导致换环境就崩现象本机跑得好好的拷到车间电脑上就报连接失败。原因是连接字符串硬编码在代码里或者用了Data Source.这种依赖本机实例的写法。解决统一收到配置文件用ConfigurationManager.ConnectionStrings或IConfiguration读取车间机器上装 SQL Server Express 时注意实例名是.\SQLEXPRESS而不是默认实例。二次开发时顺手把连接字符串做成可配置项能省掉大量现场支持。5.5 界面线程直接跑长查询导致卡死现象点追溯或报表按钮后界面白屏几秒操作工以为死机反复点。原因是查询在 UI 线程同步执行。解决把查询放到Task.Run或BackgroundWorker里查询完再回 UI 线程更新控件。WinForms 里用async/await配合Invoke更新界面即可。MES 的报表查询动辄扫几万条报工记录这个坑几乎每个桌面 MES 都会踩一次。6. 二次开发从加一道工序校验到扩展设备采集拿到这套源码之后最常见的改造需求不是重写而是在现有链路上加规则。我一般按“先加校验、再加字段、最后加采集”的顺序推进每一步都能独立验证不会一次改崩。第一步是加工序校验。比如要求“上一道工序未完工下一道工序不允许报工”。改动点只在ReportService.ReportWork开头加一段前置检查查ProcessStep里StepNo小于当前工序的记录确认累计良品数达到计划数// 报工前校验前道工序必须完工 private void CheckPrevStepDone(string orderId, int stepNo) { var prev _stepRepo.GetPrevStep(orderId, stepNo); if (prev null) return; // 首道工序无需校验 var doneQty _reportRepo.SumGoodQty(orderId, prev.StepNo); if (doneQty prev.PlanQty) throw new Exception($工序 {prev.StepName} 未完工不能报工当前工序); }这段校验放在事务外做快速失败事务内再查一次防止并发绕过。参数stepNo是当前报工工序GetPrevStep按StepNo倒序取最近一道。加完这个规则报工界面的错误提示要同步改否则操作工只看到一句“操作失败”会来问。第二步是加字段。MES 现场经常要补“设备编号”“班次”“工位”这类信息。加字段的路径是固定的数据库表加列 →Mes.Model实体加属性 → DAL 的INSERT和查询 SQL 补字段 → 报工界面加输入控件。这条路径走一遍你就摸清了这套源码的数据流。注意加列时给默认值否则历史数据查询会出空值异常。第三步是设备采集。轻量 MES 常见的做法是串口或 TCP 读设备产量计数定时写进报工记录。我一般会单独起一个采集服务不和 UI 混在一起// 采集服务定时读设备计数并写入报工伪代码结构 public class DeviceCollector { private readonly Timer _timer new Timer(5000); // 5 秒采集一次 public void Start() { _timer.Elapsed (s, e) { var count ReadDeviceCounter(); // 串口/TCP 读取 var delta count - _lastCount; // 增量 if (delta 0) { _reportService.ReportWork(_orderId, _stepNo, delta, 0, AUTO); _lastCount count; } }; _timer.Start(); } }采集服务的关键是“增量报工”和“幂等”设备计数是累计值每次只报增量服务重启后要先读一次当前计数作为基线否则会把历史产量重复报一遍。这个基线逻辑我吃过亏第一次上线时服务重启导致工单完工数直接翻倍后来每次改采集逻辑都强制先跑一遍“重启不重复报工”的验证。改造完怎么验证我的习惯是固定三条冒烟用例正常报工链路走通、非法状态跳转被拒绝、并发报工数量不丢不重。三条都过再上现场。从那以后我每次动这套 MES 的状态机或报工事务都强制把这三条用例跑一遍比看代码靠谱。希望帮到你。本文还有配套的精品资源点击获取