简介：这份PDF资料聚焦离散型制造企业的数字工厂构建，面向制造业信息化从业者、MES/APS实施人员及生产管理学习者，系统讲解数字工厂从架构设计到落地应用的完整思路。内容围绕接口层、应用层、控制层、物理层与展示层五层架构展开，涵盖任务派工、数据采集、过程控制与质量管理等关键环节，并深入工厂建模、工艺建模及EBOM、PBOM、MBOM的构建逻辑，同时涉及APS高级排程、PMC计划物控、WMS电子仓储与CPS工业互联等模块，帮助读者理解生产资源整合与数字化转型路径。资源包共1个PDF文件，大小约15.41MB，内容以图文方案形式呈现，结构清晰，便于按总体架构、基础建设、生产控制、现场采集、数据应用及案例等模块查阅。目前已有76人学习，适合需要系统了解离散制造数字工厂整体方案与实施要点的读者参考。
1. 离散型制造企业数字工厂构建：从工单到设备数据闭环的最小落地路径
很多离散制造企业的数字化项目死在“大屏很好看，车间不买账”这一步。ERP 里有工单，MES 里有报工，设备侧却还在靠人抄表、靠微信群喊缺料，最后老板看到的 OEE 是三天前手工汇总的 Excel。离散型制造企业数字工厂构建，要解决的不是买一套系统，而是让工单、物料、设备、质量四类数据在同一个节拍里流动起来。它适合年产值几千万到几个亿、多品种小批量、已经有 ERP 但车间执行靠纸单的工厂。这篇笔记按“先立数据模型、再打通采集、最后做闭环”的顺序，把最小可行路径拆开讲，能照着复现，也能看清边界。
2. 先想清楚离散制造和流程制造的数据模型差在哪
离散制造的数字工厂之所以难做，根子在数据模型和流程行业完全不同。流程行业是连续投料、管道流动，一个反应釜的温度曲线就是核心；离散行业是 BOM 拆成零件、零件排成工序、工序分配到工位，同一台设备今天做 A 产品明天做 B 产品，换型时间比加工时间还长。如果直接套用流程行业的 SCADA 加实时数据库思路，会发现数据全是断点，工单和工序对不上。
2.1 工单-工序-工位三层模型是离散数字工厂的骨架
离散制造的最小数据单元不是设备测点，而是“某张工单的某道工序在某台设备上由谁在什么时间完成”。常见做法是建三层模型：工单层记录订单号、产品编码、计划数量、交期；工序层记录工序号、工序名称、标准工时、设备组；工位层记录实际设备、操作员、开始结束时间、合格数、报废数。这三层用工单号加工序号做联合主键，后续所有采集数据都挂在这个主键上。
-- 离散制造工单工序执行表（最小可用结构） CREATE TABLE work_order_operation ( wo_no VARCHAR(32) NOT NULL, -- 工单号，关联 ERP op_no INT NOT NULL, -- 工序号，10/20/30 递增 product_code VARCHAR(64) NOT NULL, -- 产品编码 plan_qty DECIMAL(12,2) DEFAULT 0, -- 计划数量 device_code VARCHAR(32), -- 实际加工设备编码 operator_id VARCHAR(32), -- 操作员 start_time DATETIME, -- 实际开始 end_time DATETIME, -- 实际结束 ok_qty DECIMAL(12,2) DEFAULT 0, -- 合格数 ng_qty DECIMAL(12,2) DEFAULT 0, -- 不合格数 status TINYINT DEFAULT 0, -- 0待开工 1加工中 2已完工 PRIMARY KEY (wo_no, op_no) );这段建表语句的关键在联合主键和状态字段。联合主键保证同一工单同一工序只有一条执行记录，避免报工重复；status 字段是后续设备数据回写的锚点，设备采集程序只更新 status=1 的记录。plan_qty 和 ok_qty 分开存，是为了算工序达成率，不要合并成一个字段。device_code 允许为空，因为有些工序是人工装配，没有设备数据，强行要求设备编码会让模型跑不通。
2.2 为什么不要一上来就做全厂设备联网
我见过太多项目第一步就铺设备网关，把几十台机床全接进来，结果数据有了，没人知道这些振动值对应哪张工单。离散制造的设备数据只有挂到工单工序上才有业务含义。正确顺序是先把工单工序模型跑通，哪怕手工报工，再选一条产线做设备采集试点。选试点产线的标准是：产品相对固定、设备有 PLC 或可加装传感器、班组长愿意配合。常见做法是先接 3 到 5 台关键设备，跑一个月，验证数据准确率再推广。
提示：设备联网的投入产出比取决于工单数据是否已经电子化。工单还在纸上的工厂，先做报工电子化，别碰设备采集。
3. 用 OPC UA 加边缘网关把设备数据接进工单
设备数据接入是离散数字工厂里最容易翻车的环节。不同品牌 PLC 协议不同，老设备没有网口，车间电磁干扰导致丢包。这一章讲一条我实际用过的路径：边缘网关做协议转换和缓存，OPC UA 做统一语义层，MQTT 把数据推到工单服务。
3.1 边缘网关选型和 OPC UA 地址空间设计
边缘网关常见选型分两类：软件网关跑在工控机上，适合有现成 IPC 的产线；硬件网关直接 DIN 导轨安装，适合空间紧张的机柜。选型看三个参数：支持的协议数量（至少 Modbus TCP、Profinet、OPC UA）、本地缓存时长（断网时能存多久）、工作温度范围（车间夏天能到 45 度）。我一般会选支持 OPC UA 服务端和客户端双角色的网关，这样既能向下采 PLC，又能向上被 MES 订阅。
OPC UA 地址空间设计要按设备-工单维度组织，不要按 PLC 寄存器地址裸暴露。比如一台加工中心，地址空间建ns=2;s=CNC01/SpindleSpeed、ns=2;s=CNC01/ProgramName、ns=2;s=CNC01/Status。ProgramName 这个节点特别有用，它对应加工程序号，可以和工单工序里的产品编码做映射，自动判断当前设备在做哪张工单。
# 边缘网关侧：用 asyncua 读取 CNC 状态并映射到工单 import asyncio from asyncua import Client # 工单工序映射表：程序号 -> 工单号+工序号 PROGRAM_TO_WO = { "O1023": ("WO20240501001", 20), "O1024": ("WO20240501002", 10), } async def poll_cnc(): async with Client(url="opc.tcp://192.168.1.50:4840") as client: node = client.get_node("ns=2;s=CNC01/ProgramName") status = client.get_node("ns=2;s=CNC01/Status") while True: prog = await node.read_value() # 当前程序号 st = await status.read_value() # 0停机 1运行 2报警 if prog in PROGRAM_TO_WO and st == 1: wo_no, op_no = PROGRAM_TO_WO[prog] # 推送到工单服务，更新 status=1 和 start_time await push_to_mes(wo_no, op_no, "START") await asyncio.sleep(2) # 2 秒轮询一次 asyncio.run(poll_cnc())这段代码的逻辑是：网关每 2 秒读一次程序号和设备状态，当程序号命中映射表且设备在运行，就通知 MES 该工单工序开工。参数上，轮询周期 2 秒是折中值，太快增加 PLC 负载，太慢会漏掉短工序。PROGRAM_TO_WO 映射表建议放在数据库或配置文件里，不要硬编码在代码中，换产品时改配置即可。push_to_mes 要做幂等，同一工单工序重复收到 START 只更新一次 start_time。
3.2 MQTT 主题设计和断网续传
设备数据上云用 MQTT 是常见做法，主题设计要带设备编码和数据类型，比如factory/cnc01/status、factory/cnc01/count。QoS 设 1，保证至少送达一次，配合业务侧幂等去重。断网续传靠网关本地缓存，缓存策略选“环形缓冲区加时间戳”，恢复后按时间顺序补发。这里有个血泪经验：补发数据的时间戳要用采集时刻，不能用补发时刻，否则工单的 start_time 会错乱，OEE 算出来全是负数。
# 用 mosquitto_sub 验证网关是否正常推送 mosquitto_sub -h 192.168.1.100 -t "factory/+/status" -q 1 -v # 输出示例：factory/cnc01/status {"prog":"O1023","st":1,"ts":1715000000}验证命令里-q 1对应 QoS 1，-v显示主题名。如果订阅不到消息，先查网关的 MQTT broker 地址和端口，再查主题通配符是否匹配。常见问题是网关配了factory/cnc01/status，订阅时写成factory/cnc01/status/，多了斜杠就收不到。
4. 数字工厂构建避坑：五条车间里踩出来的经验
这一章不讲原理，只讲现象、原因和解决。每条都是我在不同工厂真实遇到过的，按发生频率排序。
4.1 报工数据比设备数据晚一天
现象：MES 里工单状态还是“加工中”，设备明明已经停了。原因：操作员习惯下班前统一报工，设备数据实时但没人确认。解决：在工位终端加“完工确认”按钮，设备停机信号触发弹窗，操作员点一下即完成报工。如果操作员不点，系统在停机 30 分钟后自动按设备数据预报工，班组长次日复核。这个“自动预报工加人工复核”的折中方案，比强制实时报工更容易落地。
4.2 OEE 算出来超过 100%
现象：设备运行时间大于计划生产时间，OEE 分母被算小。原因：计划生产时间取自排班表，但实际设备在非排班时间也在跑，采集程序把这段时间也算进运行。解决：在采集侧加时间窗过滤，只统计工单工序 start_time 到 end_time 之间的设备状态。另外检查设备状态定义，待机、报警、运行要互斥，不能同时为真。
4.3 同一台设备被两张工单同时占用
现象：两张工单的工序都显示在 CNC01 上加工。原因：程序号映射表里一个程序号对应了多个工单，或者上一张工单没关单，新工单又开工。解决：在工单服务加设备占用锁，同一设备同一时刻只允许一个 status=1 的工序。程序号映射表要保证唯一性，一个程序号只对应一个产品编码。换型时先关旧工单再开新工单。
4.4 网关频繁掉线导致数据断点
现象：MQTT 消息时有时无，网关日志显示 TCP 连接重置。原因：车间电磁干扰，或者网关和 broker 跨网段走路由器，NAT 超时。解决：网关和 broker 放同一网段，用有线连接不用 WiFi。网关开启心跳保活，间隔 30 秒。如果必须跨网段，在路由器上给 MQTT 连接设长连接保持。另外检查网关电源，车间电压波动会导致网关重启，加个稳压电源。
4.5 操作员抵触扫码报工
现象：上了扫码枪，操作员还是手写纸单。原因：扫码步骤太多，或者扫码后系统响应慢。解决：把扫码步骤压到两步以内，扫工单码自动带出工序和数量，操作员只确认。系统响应要在一秒内，超过两秒操作员就会放弃。另外把报工和绩效挂钩，报工准确率高的班组给奖励，比罚款有效。
注意：避坑的核心不是技术，是让车间觉得这套系统帮他们省事而不是添事。任何增加操作员负担的设计，最后都会被绕过。
5. 用历史数据反推标准工时和瓶颈工序
数字工厂跑起来之后，最有价值的不是大屏，是积累的工单工序执行数据。这些数据能反推标准工时、识别瓶颈工序，比 IE 拿秒表测的准。这一章讲一个具体技巧：用 SQL 从工单工序表里算实际工时分布，找出偏差最大的工序。
-- 按产品+工序统计实际工时，对比标准工时 SELECT product_code, op_no, COUNT(*) AS done_times, AVG(TIMESTAMPDIFF(MINUTE, start_time, end_time)) AS avg_actual_min, MAX(std_min) AS std_min, AVG(TIMESTAMPDIFF(MINUTE, start_time, end_time)) - MAX(std_min) AS diff_min FROM work_order_operation WHERE status = 2 AND start_time >= DATE_SUB(NOW(), INTERVAL 90 DAY) GROUP BY product_code, op_no HAVING done_times >= 20 ORDER BY diff_min DESC;这段查询的逻辑是：取最近 90 天已完工的工序，按产品和工序分组，算平均实际工时和标准工时的差值。done_times >= 20是为了保证样本量，少于 20 次的统计不可信。diff_min为正说明实际比标准慢，可能是标准定太紧或工序有异常；为负说明标准太松。我一般会挑 diff_min 最大的前三个工序去现场看，通常能发现物料等待、换型时间长、或者设备参数没调好。
参数上，90 天窗口是经验值，太短样本不够，太长会混入工艺变更前的数据。如果产品换型频繁，可以按产品编码加版本号分组。这个查询在 MySQL 和 PostgreSQL 里都能跑，TIMESTAMPDIFF 在 PostgreSQL 里换成 EXTRACT(EPOCH FROM (end_time - start_time))/60。
拿到结果后，不要直接改标准工时，先和车间确认。有些偏差是数据采集问题，比如操作员忘记点完工，end_time 被自动预报工填成停机时间，实际工时被拉长。先清洗数据，再谈优化。我自己习惯每季度跑一次这个查询，把 diff_min 超过 30 分钟的工序列出来，和工艺、生产一起过一遍。坚持两年，标准工时的准确率能从 60% 提到 85% 以上，排产计划的可执行性明显变好。数字工厂的价值不在大屏，在这些能反哺业务的数据闭环里。希望帮到你。
本文还有配套的精品资源，点击获取
