企业官网建设流程全解析

简介：《锐制数字工厂应用案例分享》是一份聚焦离散制造场景的数字工厂实践资料，适合制造业管理者、数字化转型顾问及车间信息化人员参考。内容以数字工厂三大核心系统CPS、DCS与MES为主线，先讲清信息物理系统、数据采集控制与制造执行系统之间的关系，再通过电子元器件、PCB、覆铜板、轴承等多个真实工厂案例，展示设备联网率提升，以及SMT电子货架、智能物料柜、AGV仓库、自动化立体仓库等物流设备联网场景，并详细展示MES现场无纸化与透明化实施路径。资源为1个PDF文件，大小约9.35MB，图文并茂便于按章节查阅；目前已有39人学习浏览。案例中既区分了老旧设备网关联网与支持TCP/IP设备直联两种方式，也拆解了工单接收、图纸SOP接收、标签发行、首检巡检、设备点检、防错检查、AGV拉动等无纸化工作场景，能帮助读者理解数字工厂从设备层、执行层到管理层如何逐步协同，为生产改造提供一套可借鉴的实施参考。

1. 数字工厂是什么：从“问出来的产量”到“算出来的产量”

车间里最贵的仪器往往不是检测设备，而是一张手写的排产表。数字工厂在各家方案商那里叫法不太一样，锐制这类《数字工厂应用案例分享》PDF我拿到手会先翻到最后一页，看客户上线前后的对比数据——因为数字工厂真正要解决的，是把设备状态、工单进度、良率从“问出来的”变成“算出来的”。

它不是买一套软件就完事。它需要把 PLC、CNC、传感器数据汇到平台层，再跟工单、报工、报表串成一条完整落地链，适合设备已经上了量、经常被客户审厂要求追溯、或者月底核算成本还在靠拍脑袋的制造企业。最反直觉的一点是：最容易卡住项目进度的往往不是服务端代码，而是车间那根网线。

2. 数字工厂的数据底座：PLC 数据采集与点位设计怎么做

不管案例 PPT 画得多漂亮，数字工厂的数据源头都在车间那台设备上。这一步最容易被低估：很多项目把预算大头花在软件平台上，进现场才发现两三台关键设备连网口都没有，或者 PLC 型号太老，通讯协议根本不支持。做数字工厂项目，我一般会先把至少一周时间砸在“摸底”上，把每台设备的品牌、PLC 型号、通讯接口、是否支持以太网登记成一张表，再谈采集方案。

2.1 工业协议选型：Modbus TCP、OPC UA、西门子 S7、CNC 私有 SDK

现场设备五花八门，协议选型直接决定采集能不能落地。我按设备年代、PLC 品牌、是否需要下写参数三个标准判断，不迷信某一种协议。

常见做法是老设备走 Modbus TCP 加工业网关，新建车间尽量上 OPC UA。注意别被集成商带偏：OPC UA 确实先进，但老设备根本跑不动，最后还是要退回寄存器轮询。我之前接过一个项目，客户要求全厂 OPC UA，结果现场一半是十年前的老仪表，最后加了两个 Modbus 转 OPC UA 的网关才收场，成本反而更高。

2.2 点位表设计：把调试期的“玄学”变成书面约定

点位表是整个数据底座的图纸。没有点位表就让开发写采集程序，十有八九后期返工。一张合格的点位表，每一行必须写清楚五个要素：点位名、寄存器地址、数据类型、倍率、用途。很多设备侧的数据漂移问题，最后查出来不是硬件故障，而是倍率填错了。

设计时有三个原则。第一，不要贪多，只采真正要看的参数，但设备状态字必须采——没有状态字，后面 OEE 可用率根本算不出来。第二，数据类型和倍率必须在表里写死并签字确认，因为西门子和三菱的寄存器字节序不一样，读出来对不上是常态。第三，点位表留 10% 的空余地址，方便后续加采集项，否则改一次点位表就要动一次程序。

2.3 最小采集链路：用 Python 从 PLC 读到数据库

有了点位表，下一步就是打通一条最小采集链路。我习惯用 Python 先做验证，跑通了再交给网关程序固化。下面这段代码可以让你在工位上验证“PLC 里的数据能不能读出来”。

import time import struct from pymodbus.client import ModbusTcpClient # PLC 以太网模块的 IP 和端口 PLC_HOST = "192.168.1.10" PLC_PORT = 502 SLAVE_ID = 1 # 点位表：[点位名, 寄存器地址, 数据类型, 倍率] POINT_TABLE = [ ("device_status", 0x1000, "uint16", 1), # 设备状态字 ("spindle_speed", 0x1002, "uint16", 1), # 主轴转速 ("total_count", 0x1010, "uint32", 1), # 累计产量 ] def read_point(client, addr, dtype): # 一次读 4 个寄存器，兼容 16 位和 32 位数据 rr = client.read_holding_registers(addr, count=4, slave=SLAVE_ID) if dtype == "uint16": return rr.registers[0] elif dtype == "uint32": # 高 16 位在前，低 16 位在后 return (rr.registers[0] << 16) | rr.registers[1] return None def main(): client = ModbusTcpClient(PLC_HOST, port=PLC_PORT, timeout=3) if not client.connect(): print("连接失败，检查 PLC 地址和车间网络") return while True: for name, addr, dtype, ratio in POINT_TABLE: try: val = read_point(client, addr, dtype) * ratio print(f"{time.strftime('%Y-%m-%d %H:%M:%S')} {name}={val}") except Exception as e: print(f"读取 {name} 失败: {e}") time.sleep(5) if __name__ == "__main__": main()

这段代码的逻辑不复杂：用 pymodbus 建立 Modbus TCP 连接，按点位表循环读寄存器，再乘倍率输出。几个参数值得记一下：SLAVE_ID默认是 1，如果 PLC 带了多个远程从站，需要按从站地址分配；timeout设 3 秒，低于 1 秒会频繁超时，高于 10 秒会让故障发现变得迟钝；采集周期 5 秒适合产量和设备状态，如果是温度这种慢变量，15 秒都行，高速冲压计数则要直接读 PLC 内部累计值，不能靠轮询。

读出来的数据要落到后续平台里，常见做法是走 MQTT 转发。用 paho-mqtt 把每条采集记录发到主题odf/site01/line02/device03/tags，QoS 设为 1，本地上线缓存，断线重连后再补发。这一步解决的是“数据到了平台但没存下来”的问题，现场调试时经常出现采集程序没死、数据却被丢弃的情况，就是因为缺了缓存机制。

3. 生产执行层：工单、报工与设备集成的落地顺序

数据底座通了，只是“能看见设备了”，离数字工厂还差一整层：生产执行。案例分享里重点讲的通常就是这部分——工单怎么下达、干了多少怎么记、进度怎么透明。很多项目死在报表好看但车间不用，原因往往是工单环节和作业现场脱节。

3.1 先打通工单下发：ERP 和 MES 的接口别硬怼

工单是数字工厂的业务主线。没有工单，产量数据只是一堆数字，没法归集到产品、批次和责任人。到这一步最常见的坑是：开发直接连 ERP 数据库读视图，结果被 IT 部门叫停——大多数 ERP 不允许第三方直接读业务表。我一般用中间表方案，ERP 侧导出视图，MES 侧只认中间表，两边解耦。

-- 检查 ERP 中间表中待下发的生产工单 SELECT order_no, material_code, plan_qty, DATE_FORMAT(start_time, '%Y-%m-%d %H:%i') AS start_time, DATE_FORMAT(due_time, '%Y-%m-%d %H:%i') AS due_time FROM mes_order_interface WHERE status = 0 -- 0 表示待下发 AND sync_time IS NULL -- 还没被 MES 同步过 ORDER BY start_time LIMIT 50;

这个查询只做两件事：筛选“待下发”的工单，限定前 50 条。status和sync_time两个字段是防重复同步的关键——只用status不足以覆盖失败重试场景，加上sync_time后，MES 同步成功就写回时间戳，即使回调失败也能通过时间戳判断是否已处理。字段一开始不要贪多，工单号、物料编码、计划数量、计划开始结束时间就够了，先跑通再扩充。

3.2 报工方式设计：扫码枪优先，自动报工谨慎上

产量进了系统，还要有人确认“这批料是谁在什么时候干完的”，这就是报工。报表上产量对不上的问题，一半出在这里。

自动报工听上去很省事，但翻车概率最高。光电传感器对工件形状敏感，堆叠、料架振动、反光都可能导致多计漏计；接头处信号抖动更是常见，一个脉冲计两件的情况排查起来非常费劲。我的做法是自动计数和人工扫码并行，以扫码数为准，设备数只做趋势参考，两边的差异在日报里单独列出来，让车间主任去判断差异原因。

3.3 设备状态判定：从 PLC 信号到 OEE 可用率

设备采集上来的状态信号，往往只有“运行、停止、报警”三态，但数字工厂算 OEE 需要的是“运行、待机、停机、维修”四态，中间差着状态机映射。最朴素的映射逻辑是：运行信号为 1 且无报警，判定为运行；运行信号为 0 但主轴转速大于 0，说明还在降速或换料，判定为待机；运行信号为 0 且主轴转速为 0，再持续 5 分钟以上，才判定为停机。

5 分钟延迟是血泪经验换来的。如果停机判定阈值设太短，换料、首检、清废料都会被打成停机，OEE 难看不说，车间主任还会天天打电话问你为什么系统乱报。阈值设 5 到 8 分钟比较合理，既能过滤短暂停，又不会让真正的故障被淹没。维修状态则从维修工单触发——设备停了但已有维修单在履行，就归为维修，用来统计 MTTR。这段映射逻辑是整个设备层最核心的部分，建议单独做成一张配置表，让车间主任能根据现场节奏调阈值，不要写死在代码里。

4. 报表与看板：让数字工厂的数据真正被车间用起来

很多数字工厂死在最后一步：数据有了，没人看。原因不是数据没用，而是报表设计用的是 IT 思维——一张大屏塞十几个图表，生产经理打开三分钟就关掉，不知道下一步该干啥。做报表，我坚持一个逻辑：先定动作，再定指标，最后画界面。

4.1 指标别贪多：先盯 OEE 和计划达成率

OEE 和计划达成率是数字工厂投产第一个月就该上墙的两个指标。OEE 拆开是三率的乘积：可用率等于设备实际运行时间除以计划生产时间，性能等于理论节拍乘实际产量再除以实际运行时间，质量等于良品数除以总产量。三者的数据来源和采集链路一一对应：可用率来自第三章的状态判定，性能来自 PLC 产量计数和工单里的理论节拍，质量来自报工检验结果。

常见误用是把台账里的“实际产量/计划产量”直接当 OEE，那只是计划达成率，完全不同的两个东西。OEE 低于 60% 的车间，先看可用率还是先看性能，我建议先看可用率——大量低 OEE 瓶颈是等料、待修、换型时间过长，性能再高也被可用率拖死。把这两个指标分开展示，管理层看到的是“设备时间去哪了”，而不是一团模糊的数字。

4.2 看板分层：老板看趋势，车间主任看异常，操作工看任务

一张看板服务不了所有人，看板必须分成三层。

这里尤其提醒一下：车间级看板才是最有价值的。操作工看的是工位屏，不是墙上的大屏；大屏是给来访客人和领导看趋势的。车间主任最需要的是“哪台设备异常、停了多久、有没有人处理”，所以车间级看板必须有异常状态高亮和响应时长统计。

4.3 报表 SQL 示例：按工单聚合产出与合格率

看板显示实时值，日报和周报靠查询。下面这条 SQL 是报工表最常见的聚合逻辑，用于按月统计每个工单的产量、合格率和实际工时。

SELECT wo.work_order_no, wo.machine_code, SUM(wr.report_qty) AS total_qty, SUM(CASE WHEN wr.is_ok = 1 THEN wr.report_qty ELSE 0 END) AS ok_qty, ROUND( SUM(CASE WHEN wr.is_ok = 1 THEN wr.report_qty ELSE 0 END) / SUM(wr.report_qty) * 100, 2 ) AS pass_rate, TIMESTAMPDIFF(MINUTE, MIN(wr.start_time), MAX(wr.end_time)) AS work_minutes FROM work_report wr LEFT JOIN work_order wo ON wr.order_id = wo.id WHERE wr.report_date >= '2025-01-01' AND wr.report_date < '2025-02-01' AND wo.work_order_no IS NOT NULL GROUP BY wo.work_order_no, wo.machine_code HAVING ok_qty > 0 ORDER BY work_minutes DESC;

日期过滤用>=和<，不要用BETWEEN，避免月初月末边界数据重复计入。HAVING ok_qty > 0的作用是过滤掉没有产出记录的异常工单，否则报表里会混入空跑工单。实际项目中，这张报表还要带上工序名称和不良原因字段，生产经理按“不良原因”列钻取，才能知道质量损失到底出在哪个环节。

4.4 异常推送：别等班组上报，让系统主动找人

报表做得再好，人不会天天打开看。数字工厂要真正见效，必须把“人找数据”翻过来变成“数据找人”，也就是异常主动推送。最简单的落地方式是 webhook 机器人推送到企业微信群。

from datetime import datetime # 阈值做成配置，不要写死在代码里 STOP_THRESHOLD_MIN = 15 device_status = get_device_status("A03") # 从采集层获取状态 now = datetime.now() if device_status == "stop": if last_stop_start is None: last_stop_start = now stop_minutes = (now - last_stop_start).total_seconds() / 60 if stop_minutes >= STOP_THRESHOLD_MIN and not alarm_sent: send_webhook(f"设备 A03 已停机 {stop_minutes:.0f} 分钟，请确认") alarm_sent = True else: last_stop_start = None alarm_sent = False

这段逻辑简单，但值得注意两个参数。停机阈值设 15 分钟而不是 5 分钟，因为 5 到 15 分钟往往只是换料和短暂中断，频繁推送会让班组把消息当垃圾忽略；15 分钟以上大概率是故障，值得人工介入。alarm_sent标志位是必须的，否则系统每分钟重复推送，群消息会变成灾难。这类规则我建议控制在 5 条以内，先推停机、推超时未报工、推关键质量参数超差分位，跑一两个月再增加规则，贪多必乱。

5. 数字工厂实施避坑：五个最常翻车的现场问题

做了几年数字工厂项目，踩过的坑比看过的案例多。这一章直接给你结论，每条都是“现象—原因—解决”的结构，对照着查就行。

5.1 设备能 ping 通，采集却偶发断线

现象：PLC 地址能 ping 通，采集程序运行也正常，但每隔几小时就出现一次批量超时，恢复后数据又正常。

原因：车间网络和办公网共用一个交换机，办公区有人大量下载或视频会议，广播流量挤占链路；另一个常见原因是现场用了环形拓扑，STP 生成树协议重新收敛要几十秒，期间所有报文中断。

解决：采集网络单独划分 VLAN，关键设备接工业交换机，禁止办公室电脑接入采集网段。网络布线这种事，没有后悔药，布线时图省事省下的钱，后期都会在排查问题上加倍还回去。

5.2 点位数据读出来是负数或放大几十倍的数

现象：温度显示 1200℃，压力显示 -5，产量一会儿 300 一会儿 3。

原因：数据类型和倍率没对上号。最常见的是 PLC 里存的是放大 100 倍的整形，采集程序没乘倍率直接当成整数读；另一个是字节序问题，西门子高字在前，三菱低字在前，同样的地址读出来的数完全不一样。

解决：把点位表签字版贴在采集柜里，对照点位表逐点校验。用“已知值校验法”——让现场师傅手动操作设备，比如把温度加热到 80℃，看系统读出来是不是 80 或 8000，一次性就能暴露倍率和字节序问题。

5.3 自动报工数量永远对不上

现象：传感器显示生产了 500 件，工人扫码只报了 480 件，月底差异越滚越大。

原因：光电传感器计数受工件形状、料架振动、重叠遮挡影响；工件在传感器前来回抖动可能触发多次计数。自动计数适合规则、单列通过的工件，不适合散装、堆叠的工件。

解决：自动计数只做设备产量参考，报工以人工扫码为准，两侧差异在日报里单列出来让车间核对。不要试图让两边完全一致——采集层和业务层天然存在语义差异，你要做的是承认差异并管理差异。

5.4 看板上线三个月，车间没人看

现象：大屏挂车间三个月，领导来看时开一下，平时是黑屏。

原因：报表是 IT 思维做出来的，一堆折线图和饼图，但没有回答车间主任最关心的问题——“现在哪台设备有问题，该谁去处理”。看板上没有 actionable 信息，自然没人看。

解决：砍掉一半图表，把设备异常红色高亮、停机时长、响应责任人放最显眼的位置。把被动看板改成主动推送，异常直接找到人头上，看板才不会被当摆设。

5.5 工单产量和设备采集产量对不上

现象：MES 里报工完成 500 件，设备采集显示产出 480 件，两边都没错但数对不上。

原因：两者口径不一致。设备采集的是加工完成数，包含首检废品、调试件和中途报废；报工数是作业员确认的合格品入库数。同一个“产量”在两个系统里定义不一样，数字当然对不上。

解决：统一口径，定义好“成品计数点”——以哪道工序的设备信号为准，什么状态的工件算一件。口径定义清楚后，在集成文档里明确写死：设备产量用于效率分析，报工数量用于入库核算，两边的差值作为废品和调试损耗单独统计展示。

6. 应用案例复盘：从上线到迭代，如何验证数字工厂真的见效

6.1 上线前后怎么对比：四个维度，别凭感觉

数字工厂上线一个月后，最该做的事是拉出上线前后的对比数据，验证投入有没有产生回报。我常用四个维度对比，每个维度都要有可量化的口径：日报生成时长，原来靠人工统计要两小时，系统上线后应该是分钟级；异常响应时长，从故障发生到有人到场处理的间隔，看异常推送记录；计划达成率，对比上线前人工跟踪和上线后系统跟踪的偏差；在制品周转天数，这个数据要从 ERP 或库存报表取，反映车间流动效率。

注意一点：别只用上线第一周的数据当“效果”。第一周大家新鲜感还在，异常处理快、报工及时是必然的。取上线后第 3 到 6 周的平均值，和上线前三个月的平均水平比，才是真实改善。

6.2 迭代路线：从能看到能控，再到能排

数字工厂不是一次性工程，而是层层递进。第一个台阶是采集加看板，一到两个月就能完成，解决“看见”问题，验证设备数据的准确性；第二个台阶是工单执行加异常推送，再花一个月，解决“受控”问题，让系统主动找人；第三个台阶才是和 ERP 深度联动、自动排产，这一步按需推进，基础不牢很容易翻车。前两个台阶没走稳，别急着上高级排产——排产模型需要准确的标准工时和可靠的状态数据，否则输出结果没人敢信。

6.3 数据健康度检查：每月一次，让系统不“腐烂”

系统上线后最大的风险是慢慢长草。采集程序没人维护、点位漂移没人校正、报工不及时，三个月后报表又开始不准。我的习惯是每月底做一次数据健康度检查，看三个指标：采集覆盖率，当天有数据的点位占全部接入点位的比例，低于 98% 就要查原因；断线点位清单，连续 24 小时没有数据的设备列表；报工及时率，当班工单在班次结束前完成报工的比例，低于 90% 说明作业员根本没在用系统。

检查方法很简单，一条 SQL 搞定：

SELECT device_code, COUNT(*) AS total_points, SUM(CASE WHEN last_time >= NOW() - INTERVAL 1 DAY THEN 1 ELSE 0 END) AS active_points, ROUND(SUM(CASE WHEN last_time >= NOW() - INTERVAL 1 DAY THEN 1 ELSE 0 END) / COUNT(*) * 100, 1) AS coverage_rate FROM tag_daily_snapshot WHERE stat_date = CURDATE() - INTERVAL 1 DAY GROUP BY device_code ORDER BY coverage_rate ASC;

我现在做数字工厂项目，有个习惯一直保留：上线后的每个月，自己亲自去车间转一圈，看采集柜指示灯是不是全绿。有一次发现三号车间一个采集盒被叉车压扁了线缆，指示灯偶尔闪黄，但系统里数据看起来完整——是本地缓存兜住了。如果不巡检，丢数据要等月底对账才发现，到那时报表已经错了半个月。数字工厂的价值靠数据和动作闭环体现，除了把系统做上线，把数据养健康才是它长久有用的关键。希望帮到你。

本文还有配套的精品资源，点击获取