简介《锐制数字工厂应用案例分享》是一份聚焦离散制造场景的数字工厂实践资料适合制造业管理者、数字化转型顾问及车间信息化人员参考。内容以数字工厂三大核心系统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老设备、温控器、第三方仪表、部分国产 PLC按寄存器地址轮询设备杂、预算有限最通用的兜底方案OPC UA西门子 1200/1500、倍福、新系统信息模型 证书加密新车间、跨品牌统一接入数据语义清晰S7 协议西门子 S7-300/400/1200/1500直接读写 DB 块和数据块西门子设备占比高速度快、点位灵活FOCAS / MTConnectFANUC、马扎克等 CNC厂商 SDK 读系统数据数控机床需要主轴转速、程序号、坐标常见做法是老设备走 Modbus TCP 加工业网关新建车间尽量上 OPC UA。注意别被集成商带偏OPC UA 确实先进但老设备根本跑不动最后还是要退回寄存器轮询。我之前接过一个项目客户要求全厂 OPC UA结果现场一半是十年前的老仪表最后加了两个 Modbus 转 OPC UA 的网关才收场成本反而更高。2.2 点位表设计把调试期的“玄学”变成书面约定点位表是整个数据底座的图纸。没有点位表就让开发写采集程序十有八九后期返工。一张合格的点位表每一行必须写清楚五个要素点位名、寄存器地址、数据类型、倍率、用途。很多设备侧的数据漂移问题最后查出来不是硬件故障而是倍率填错了。点位名寄存器地址数据类型倍率用途device_status0x1000uint161设备状态字映射运行/待机/报警spindle_speed0x1002uint161当前主轴转速用于待机判定current_temp0x1004float1关键测温点用于工艺监控pressure_value0x1006uint160.01压力值放大 100 倍存储除回来才是 MPatotal_count0x1010uint321PLC 内部累计产量比轮询计数可靠设计时有三个原则。第一不要贪多只采真正要看的参数但设备状态字必须采——没有状态字后面 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, count4, slaveSLAVE_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, portPLC_PORT, timeout3) 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/tagsQoS 设为 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 报工方式设计扫码枪优先自动报工谨慎上产量进了系统还要有人确认“这批料是谁在什么时候干完的”这就是报工。报表上产量对不上的问题一半出在这里。报工方式操作特征准确性适用场景扫码枪报工工人扫工单二维码 物料条码高需工人配合有纸制工单或条码的产线最推荐先上工位屏触摸报工点击屏幕确认数量高但单次操作慢工位旁有操作屏的装配或测试工序自动计数传感器PLC 信号自动计数受工件形状和振动影响适合规则工件建议仅作辅助核对自动报工听上去很省事但翻车概率最高。光电传感器对工件形状敏感堆叠、料架振动、反光都可能导致多计漏计接头处信号抖动更是常见一个脉冲计两件的情况排查起来非常费劲。我的做法是自动计数和人工扫码并行以扫码数为准设备数只做趋势参考两边的差异在日报里单独列出来让车间主任去判断差异原因。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 看板分层老板看趋势车间主任看异常操作工看任务一张看板服务不了所有人看板必须分成三层。看板层级服务对象核心内容刷新频率关键动作厂级看板厂长、生产副总整体 OEE、计划达成、能耗趋势15 分钟识别整体趋势车间级看板车间主任、班组长设备实时状态、异常报警、在制品分布30 秒定位异常设备分派处理工位级看板操作工当班任务、工艺参数、SOP、报工入口实时按标准作业提交报工这里尤其提醒一下车间级看板才是最有价值的。操作工看的是工位屏不是墙上的大屏大屏是给来访客人和领导看趋势的。车间主任最需要的是“哪台设备异常、停了多久、有没有人处理”所以车间级看板必须有异常状态高亮和响应时长统计。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;我现在做数字工厂项目有个习惯一直保留上线后的每个月自己亲自去车间转一圈看采集柜指示灯是不是全绿。有一次发现三号车间一个采集盒被叉车压扁了线缆指示灯偶尔闪黄但系统里数据看起来完整——是本地缓存兜住了。如果不巡检丢数据要等月底对账才发现到那时报表已经错了半个月。数字工厂的价值靠数据和动作闭环体现除了把系统做上线把数据养健康才是它长久有用的关键。希望帮到你。本文还有配套的精品资源点击获取 数字工厂落地实践：从PLC数据采集到OEE看板
简介《锐制数字工厂应用案例分享》是一份聚焦离散制造场景的数字工厂实践资料适合制造业管理者、数字化转型顾问及车间信息化人员参考。内容以数字工厂三大核心系统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老设备、温控器、第三方仪表、部分国产 PLC按寄存器地址轮询设备杂、预算有限最通用的兜底方案OPC UA西门子 1200/1500、倍福、新系统信息模型 证书加密新车间、跨品牌统一接入数据语义清晰S7 协议西门子 S7-300/400/1200/1500直接读写 DB 块和数据块西门子设备占比高速度快、点位灵活FOCAS / MTConnectFANUC、马扎克等 CNC厂商 SDK 读系统数据数控机床需要主轴转速、程序号、坐标常见做法是老设备走 Modbus TCP 加工业网关新建车间尽量上 OPC UA。注意别被集成商带偏OPC UA 确实先进但老设备根本跑不动最后还是要退回寄存器轮询。我之前接过一个项目客户要求全厂 OPC UA结果现场一半是十年前的老仪表最后加了两个 Modbus 转 OPC UA 的网关才收场成本反而更高。2.2 点位表设计把调试期的“玄学”变成书面约定点位表是整个数据底座的图纸。没有点位表就让开发写采集程序十有八九后期返工。一张合格的点位表每一行必须写清楚五个要素点位名、寄存器地址、数据类型、倍率、用途。很多设备侧的数据漂移问题最后查出来不是硬件故障而是倍率填错了。点位名寄存器地址数据类型倍率用途device_status0x1000uint161设备状态字映射运行/待机/报警spindle_speed0x1002uint161当前主轴转速用于待机判定current_temp0x1004float1关键测温点用于工艺监控pressure_value0x1006uint160.01压力值放大 100 倍存储除回来才是 MPatotal_count0x1010uint321PLC 内部累计产量比轮询计数可靠设计时有三个原则。第一不要贪多只采真正要看的参数但设备状态字必须采——没有状态字后面 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, count4, slaveSLAVE_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, portPLC_PORT, timeout3) 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/tagsQoS 设为 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 报工方式设计扫码枪优先自动报工谨慎上产量进了系统还要有人确认“这批料是谁在什么时候干完的”这就是报工。报表上产量对不上的问题一半出在这里。报工方式操作特征准确性适用场景扫码枪报工工人扫工单二维码 物料条码高需工人配合有纸制工单或条码的产线最推荐先上工位屏触摸报工点击屏幕确认数量高但单次操作慢工位旁有操作屏的装配或测试工序自动计数传感器PLC 信号自动计数受工件形状和振动影响适合规则工件建议仅作辅助核对自动报工听上去很省事但翻车概率最高。光电传感器对工件形状敏感堆叠、料架振动、反光都可能导致多计漏计接头处信号抖动更是常见一个脉冲计两件的情况排查起来非常费劲。我的做法是自动计数和人工扫码并行以扫码数为准设备数只做趋势参考两边的差异在日报里单独列出来让车间主任去判断差异原因。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 看板分层老板看趋势车间主任看异常操作工看任务一张看板服务不了所有人看板必须分成三层。看板层级服务对象核心内容刷新频率关键动作厂级看板厂长、生产副总整体 OEE、计划达成、能耗趋势15 分钟识别整体趋势车间级看板车间主任、班组长设备实时状态、异常报警、在制品分布30 秒定位异常设备分派处理工位级看板操作工当班任务、工艺参数、SOP、报工入口实时按标准作业提交报工这里尤其提醒一下车间级看板才是最有价值的。操作工看的是工位屏不是墙上的大屏大屏是给来访客人和领导看趋势的。车间主任最需要的是“哪台设备异常、停了多久、有没有人处理”所以车间级看板必须有异常状态高亮和响应时长统计。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;我现在做数字工厂项目有个习惯一直保留上线后的每个月自己亲自去车间转一圈看采集柜指示灯是不是全绿。有一次发现三号车间一个采集盒被叉车压扁了线缆指示灯偶尔闪黄但系统里数据看起来完整——是本地缓存兜住了。如果不巡检丢数据要等月底对账才发现到那时报表已经错了半个月。数字工厂的价值靠数据和动作闭环体现除了把系统做上线把数据养健康才是它长久有用的关键。希望帮到你。本文还有配套的精品资源点击获取