MES 制造执行与质量追溯系统

项目概览

这是一套已经投入生产使用的制造执行与质量追溯系统。系统位于企业计划与现场控制之间，负责把生产计划、工艺版本和质量要求转化为可执行的批次流程，同时持续接收设备、治具、扫码和检测数据，形成从计划下达到结果追溯的闭环。

它不是单纯的管理看板，也不替代 PLC 的实时控制和安全逻辑。系统关注的是跨工位的业务一致性：当前生产什么、使用哪个工艺版本、产品与治具如何关联、每个工序执行到哪里、设备是否具备启动条件、结果是否完整保存，以及异常发生后如何定位上下文。

根据项目实际使用情况，可以确认核心计划执行、现场设备协同、实时监控和质量追溯链路已经在生产环境运行。本文只做定性说明，不公开或推断客户、产量、节拍、良率、设备利用率及稳定性指标。

匿名化与公开边界

案例保留可复用的软件架构和工程方法，但不会公开以下内容：

• 公司、客户、产品、工厂和产线名称；
• 设备品牌、控制器型号、真实工位名称和现场拓扑；
• IP、端口、数据库连接、对象存储地址、账号、密钥和证书；
• PLC 寄存器、扫码协议字段、消息 Topic、实时事件载荷和外部系统接口样本；
• 真实工艺参数、质量阈值、产品码、治具码、订单号和生产数据；
• 截图、配置文件、日志样本、安装目录和第三方 SDK 文件。

下文统一使用“现场控制器”“扫码设备”“外部生产系统”和“对象存储”等抽象名称。架构图描述数据职责，不还原真实网络。

项目目标

多工序生产系统需要同时面对管理数据、现场通信和长时间运行三类约束：

1. 生产计划、订单、批次与工艺版本必须保持明确关联；
2. 产品、治具、工位和执行会话需要在扫码事件中持续映射；
3. 现场控制器的通信速度和失败方式与普通 HTTP 请求不同；
4. 界面、外部系统和设备可能同时关注同一生产状态；
5. 图片与报告需要长期追溯，但不适合全部写入关系数据库；
6. 断线、重启或部分执行失败后，不能只依赖进程内状态恢复上下文。

项目因此把目标确定为：以版本化工艺和执行快照保证业务一致性，以生产会话串联多工位数据，以通信调度层隔离设备差异，以实时事件提升现场可见性，并以数据库和对象存储形成可审计的质量记录。

技术栈与职责

后端和前端分别维护独立工程边界。浏览器不会直接访问现场设备，所有生产动作都必须经过后端的权限、业务校验、执行编排和通信调度。

总体架构

┌────────────────────────────── 操作与管理层 ──────────────────────────────┐
│  计划 / 工艺 / 设备 / 生产 / 质量 / 报表 / 权限 / 可视化               │
│                              React 管理端                                │
└───────────────────────────────┬──────────────────────────────────────────┘
                                │ REST + SignalR
                                ▼
┌──────────────────────── ASP.NET Core 应用入口 ───────────────────────────┐
│  JWT / 权限中间件 / API / 实时 Hub / 依赖注入 / 系统通知                │
└───────────────────────────────┬──────────────────────────────────────────┘
                                ▼
┌──────────────────────────── 业务服务层 ──────────────────────────────────┐
│  计划与批次 │ 工艺版本 │ 生产编排 │ 会话管理 │ 质量追溯 │ 报表与审计    │
└───────────────┬───────────────────────────────┬─────────────────────────┘
                │                               │
                ▼                               ▼
┌──────────────────────────┐       ┌───────────────────────────────────────┐
│ MySQL / EF Core          │       │ 通信调度与后台任务                    │
│ 配置、快照、会话、结果   │       │ 控制器连接、读写、扫码、重连、轮询    │
└──────────────┬───────────┘       └───────────────────┬───────────────────┘
               │                                       ▼
               ▼                           现场控制器 / 扫码设备 / 检测设备
┌──────────────────────────┐
│ MinIO 对象存储           │
│ 图片、附件与报告文件     │
└──────────────────────────┘
                │
                └──────── SignalR / MQTT ────────► 浏览器与外部生产系统

这套分层的核心约束是单向依赖：设备通信不直接决定页面状态，页面也不绕过业务服务修改生产数据。数据库保存可恢复事实，内存状态只用于提高运行时访问效率。

核心领域模型

系统围绕“计划如何被准确执行”组织领域数据。

工艺模板和工艺版本分离，避免修改模板后影响已经下达的批次。执行开始时生成快照，把本次生产需要的工序、参数、设备和质量规则固定下来；后续模板更新不会悄然改变正在运行的计划。

从批次到设备启动的执行链路

生产启动采用分阶段编排，而不是在一个控制器方法里直接写设备：

选择并确认生产批次
  → 加载批次、计划、工艺和基础数据
  → 校验状态、版本、数量与资源完整性
  → 创建或恢复不可变执行快照
  → 检查控制器连接和设备就绪状态
  → 注册产品、治具和生产会话映射
  → 将计划加入运行队列并持久化状态
  → 启动相关现场设备
  → 与外部生产系统同步开始状态
  → 通过实时通道广播执行通知

每一步都有清晰的前置条件。设备未就绪、快照不完整或批次状态不允许执行时，流程应在启动现场动作之前失败。已经发生部分变更时，则依靠持久化状态、错误通知和清理逻辑留下可排查证据。

编排代码以多个阶段表达业务意图，使计划校验、资源准备、入队、设备启动和外部同步可以分别测试和审计。它也暴露了当前需要继续治理的边界：异常传播和失败后的统一补偿必须持续审查，不能假设所有失败都会自然落入同一个外层清理分支。

执行快照与生产会话

执行快照

计划执行前会把必要配置转换为本次运行的快照。快照主要用于：

• 固定执行时使用的工艺版本和步骤顺序；
• 固定质量项、参数和设备关联；
• 支持服务重启后的上下文恢复；
• 保留“当时按什么规则生产”的历史证据；
• 避免后台配置修改直接影响运行中的批次。

生产会话

生产会话管理器维护计划队列以及产品、治具、工位和执行进度之间的运行时关联。扫码事件进入系统后，会先解析业务标识，再定位对应会话和工艺步骤，最后决定当前事件属于进站、加工还是离站。

扫码或设备事件
  → 识别产品与治具上下文
  → 定位活动计划和生产会话
  → 校验当前工序与允许状态
  → 更新工序进度和质量数据
  → 持久化关键结果
  → 推送界面及外部集成事件

运行时映射使用并发集合提高高频查询效率，但数据库和执行快照才是恢复依据。进程内缓存不能成为唯一事实来源。

现场通信与调度

现场通信由后台调度服务统一承载，业务服务不散落连接、轮询和字节解析代码。主要职责包括：

• 根据控制器配置创建和维护连接；
• 串行化同一连接上的 Modbus TCP 访问；
• 按配置处理数据类型、字节序和质量规则；
• 接收扫码设备的 TCP 数据并转换为业务事件；
• 周期采集设备状态和运行数据；
• 断线后记录状态并按策略重连；
• 把设备结果关联到计划、会话、治具和产品；
• 将关键变化发布到实时通道。

解析规则尽量配置化，使不同设备数据可以映射为统一业务结果。配置化并不等于无条件信任配置：数据长度、类型、范围、会话状态和质量规则仍需显式校验。

通信调度服务当前承担了较多现场协议、状态和流程职责。它保障了集中管理，也形成了明显的复杂度热点，后续需要按连接管理、数据解析、生产事件和消息发布进一步拆分。

工序推进与数据闭环

系统把多工位流程抽象为进入、处理和退出三类事件，而不在公开模型中绑定具体设备名称。

1. 进入事件校验计划、产品、治具及当前允许的工序；
2. 处理事件接收设备状态、测量值、配方调用和过程结果；
3. 退出事件完成工序判定并决定是否允许流向下一步；
4. 最终工序完成后汇总生产与质量结论；
5. 数据库保存结构化结果，对象存储保存相关图片和附件；
6. 浏览器与外部生产系统通过实时事件获得状态变化。

业务规则不会仅依赖前端按钮状态。即使请求来自合法界面，后端仍需再次验证批次状态、工序顺序、资源关联和用户权限。

质量追溯与报表

质量追溯以生产会话为主线，把以下信息关联起来：

• 计划、订单、批次和执行快照；
• 产品与治具的虚拟标识；
• 工序、质量项、测量值和综合判定；
• 使用的配方、参数版本及设备上下文；
• 图片、附件和相关对象存储索引；
• 异常、通知、操作日志和时间信息。

关系数据库保存可查询的结构化事实，MinIO 保存体积较大的文件对象。报表服务在此基础上提供批次、工单和质量统计，并支持 CPK、CMK 等过程能力分析。公开案例不展示真实阈值、样本或统计结果。

实时状态与外部集成

系统同时使用 SignalR 和 MQTT，但二者服务的对象不同：

实时消息用于加速状态同步，不替代数据库事务。浏览器重连后必须能够重新查询当前事实，而不能只依赖断线期间可能丢失的推送。

外部生产系统的开始与结束同步属于执行编排的一部分。公开案例只说明集成边界，不展示地址、字段、认证方式或响应样本。

前端管理与可视化

React 管理端围绕业务模块组织菜单和页面，包括：

• 基础数据、组织、用户和权限；
• 计划、订单、批次和生产执行；
• 工艺模板、版本、步骤、质量项和参数；
• 设备、控制器、治具和维护配置；
• 数据采集、实时监控、通知和运行状态；
• 质量追溯、批次/工单报表与可视化分析。

React Query 负责服务端数据的加载与缓存，Zustand 保存跨页面运行状态，SignalR 客户端把现场变化合并到界面。连接指示器和通知中心让操作人员能够区分“当前没有数据”和“实时连接已经中断”。

权限不仅控制菜单是否可见，也需要由后端权限中间件再次校验 API。前端隐藏按钮不能替代服务端授权。

身份、权限与审计

系统使用 JWT Bearer 认证，并以用户、角色、模块/功能权限、部门和团队构建授权上下文。典型控制包括：

• 登录身份与令牌有效期校验；
• 页面菜单和功能按钮的权限过滤；
• 后端 API 的权限或管理员约束；
• 用户活动记录和关键业务操作审计；
• 系统通知和异常事件留痕。

当前前端提供“记住登录信息”的本地保存行为。该策略需要按凭据敏感度重新设计，避免长期保存可复用秘密；生产日志中也不应输出令牌、用户会话或业务敏感值。

后台任务与运行维护

除生产通信外，后台任务还承担设备维护检查、磁盘空间监控和周期性业务工作。Quartz 适合有明确调度周期的任务，Hosted Service 适合伴随应用生命周期持续运行的通信循环。

磁盘、数据库和对象存储必须共同纳入运维检查。只监控 Web API 是否返回 200，无法发现图片积压、磁盘逼近容量或设备连接长期失败。

现场交付方式

前端使用 Vite 生成静态资源，通过 IIS 提供浏览器访问；Inno Setup 工程将静态文件和必要配置打包为 Windows 安装程序。配置文件在升级时保留，避免程序覆盖现场环境参数。

开发与验证
  → 后端 Release 构建
  → 前端 TypeScript / Vite 构建
  → 生成静态站点与后端发布文件
  → 制作带版本号的安装介质
  → 现场备份配置和数据
  → 安装或升级
  → 验证 API、页面、设备连接和生产流程

安装包解决文件交付问题，但不自动等于完整发布系统。版本映射、数据库变更、配置备份、健康检查、回退步骤和现场验收仍需要统一记录。

构建与测试基线

案例编写前对当前功能分支执行了只读构建与测试核验，结果如下：

五个失败用例集中在近期设备扩展后的请求构造和生产执行校验与旧断言不一致。它们不能被“生产正在使用”掩盖，也不能在未修复前描述为测试全绿。1316 条编译警告同样说明可空性、注释和历史代码质量债务需要分批治理。

现有测试覆盖部分请求构造、执行指标、快照、工艺服务、设备摘要和数据校验，但不能覆盖全部 Web 交互、通信调度、断线重连与真实硬件行为。硬件在环验证仍是正式发布不可省略的环节。

生产使用结果

依据已经确认的生产事实，可以做出以下定性结论：

• 系统已经用于多工序生产计划的现场执行；
• 计划、批次、工艺版本、设备资源和生产会话形成了连续业务链路；
• 现场控制器、扫码与检测数据能够进入统一执行和追溯模型；
• Web 管理端能够展示生产、设备、质量和系统通知状态；
• MySQL 与对象存储共同支撑结构化结果和文件数据追溯；
• 安装工程支持前端现场安装和配置保留。

本文不以未记录的数字评价项目性能，也不声称每个源码模块都已经在所有现场场景中启用。

已知边界与风险

后端复杂度与异常处理

• 通信调度服务规模较大，同时承担连接、协议、状态和生产事件职责，修改时容易扩大影响面；
• 生产执行管线的异常传播与补偿路径需要系统审计，避免内部捕获后绕过外层清理；
• 部分实时发布采用异步触发并以日志记录失败，需要明确哪些消息允许丢失、哪些必须可靠补偿；
• 可空性和 XML 注释等编译警告数量较多，真正的风险容易被告警噪声掩盖；
• 当前测试并非全绿，不能作为阻断回归的可靠门禁。

前端安全与质量

• 部分运行日志可能包含令牌、用户或会话信息，应删除敏感输出并建立生产日志规范；
• “记住登录信息”策略需要避免保存可复用密码或其他长期秘密；
• Hook 依赖、显式 any、未使用变量和快速刷新导出规则仍有 lint 问题；
• 图表相关分包体积较大，需要按页面延迟加载并持续分析产物；
• 缺少统一前端自动化测试入口，关键生产页面主要依赖人工回归。

现场与发布

• Mock、单元测试和普通集成测试不能替代真实控制器、扫码设备及安全回路的硬件在环验证；
• 数据库、对象存储、IIS、后端服务与现场配置需要一致的备份和恢复清单；
• 设备协议、工艺配置和外部系统接口变更需要与发布版本同步记录；
• 现场升级仍需完善统一版本索引、自动健康检查和可演练回退流程。

后续路线

后续工作按风险和可验证性排序：

1. 修复当前五个失败测试，确保新增设备能力与测试基线一致；
2. 分类处理编译警告，优先解决可空引用、资源释放和潜在运行时问题；
3. 将前端 lint 纳入门禁，并补充认证、生产执行、实时状态和质量追溯测试；
4. 清理敏感日志，重构凭据记忆策略，审计浏览器持久化数据；
5. 拆分通信调度服务，明确连接、解析、会话、生产事件和消息发布边界；
6. 为执行失败补齐一致的取消、补偿、清理和审计策略；
7. 建立控制器模拟、数据库集成和硬件在环的分层回归环境；
8. 锁定后端、前端和安装工程依赖，生成可追溯的软件物料清单；
9. 统一安装包版本、数据库升级、配置保留、健康检查和回退演练；
10. 为磁盘、数据库、对象存储、设备连接和关键生产异常建立可操作告警。

项目复盘

MES 的难点不在于页面数量，而在于管理数据、长事务式生产流程与非可靠现场通信必须同时成立。这个项目验证了几项重要的工程原则：

• 用工艺版本和执行快照保存“当时的事实”，避免运行计划受配置漂移影响；
• 用生产会话把产品、治具、工位和质量结果串成可追溯链路；
• 用通信调度层隔离设备差异，但必须持续控制该层的职责和复杂度；
• 用实时事件改善可见性，同时坚持数据库才是可恢复事实来源；
• 把权限、审计、备份和发布视为生产功能，而不是项目收尾时的附加项；
• 生产使用证明系统具备业务价值，但不能替代持续构建、测试、静态检查和硬件回归。

下一阶段的重点不是继续扩张功能清单，而是把已投入使用的能力转化为更清晰的模块边界、更可信的质量门禁和更可恢复的现场发布体系。