简介这是一份面向制造企业技术管理者、车间规划人员及智能制造方向学习者的PPT资料围绕数字化、智能化车间的规划与建设展开系统梳理数字化转型、工业互联网、车间布局规划与智能制造四条主线。内容涵盖数据采集与数据挖掘驱动的业务流程优化、设备互联与数据共享、机器学习与边缘计算等关键技术的落地路径并延伸到生产流程与供应链的实时监控和优化适合用于企业内训、项目立项汇报或个人知识体系搭建。压缩包内为1个pptx文件约21.13MB以演示文稿形式按章节组织页面结构清晰便于直接引用或二次修改。该资料已有2230人学习可作为理解智能车间整体架构、梳理技术要点与规划思路的参考素材。1. 数字化车间和智能化车间规划阶段的三条分水岭车间改造立项会上最常见的一幕是把《数字化、智能化车间规划与建设》翻开第一页上面写着三年建成无人化智能工厂可真到排预算时钱基本砸在设备联网、点表梳理和 MES 补课上。这不是方案写错了而是两个阶段的边界没分清。数字化车间解决的是看得见设备状态、工单进度、质量数据实时在线报表不再靠班组长手填。智能化车间解决的是算得准、调得动排产可执行、工艺参数可寻优、设备劣化可提前预警。分水岭有三条——数据是否自动采集而非人工填报、模型输出是否有闭环执行通道、投入产出是否有可核算口径。这三条决定了规划书里哪些内容能落地哪些只能留在汇报页上。往下按 ISA-95 分层盘家底、搭采集链路、接 MES 与算法、分阶段验收是大多数离散制造车间走得通的一条路径。2. 数字化车间规划第一步用 ISA-95 分层盘清家底与 KPI 基线规划最容易出问题的地方是拿着一张产线布局图就开始画系统架构。设备有哪些型号、哪些能联网、点表全不全、班次怎么排这些没盘清楚后面所有方案都是空中楼阁。数字化车间的规划顺序应该是分层建模 → 现状盘点 → KPI 基线 → 投资测算顺序反了就要返工。2.1 用 ISA-95 五层模型给车间画一张资产地图ISA-95 把制造企业分成五层车间的规划边界通常落在 L0 到 L3 之间。分层的作用不是画得好看而是明确每一层的责任主体、数据时间尺度和采购归属避免 MES 厂商和自动化厂商互相甩锅。层级名称典型系统时间尺度规划中的落点L4企业资源层ERP天/周订单、BOM、成本口径L3制造运营层MES/MOM、WMS、QMS秒~班次派工、追溯、SPCL2监控层SCADA、HMI、组态100ms~秒画面、报警、手自动切换L1控制层PLC、CNC、机器人1~100ms联锁逻辑、运动控制L0现场层传感器、仪表、执行器ms 级物理量采集与动作执行关键判断是L2 到 L3 之间是数字化的主战场也是钱花得最多的一层。L0/L1 通常随设备采购已经带上了改造成本高、收益小能不动的尽量不动L3 是价值放大的地方工单、物料、质量、设备四类对象在这里汇聚。规划书里把设备改造清单和系统集成清单分开列评审时就不会被一句让设备厂商配合带过去。2.2 设备联网率与点表完整度现状盘点的两张底表盘点要用可量化的口径不然就是走一圈看看。我一般只做两张表一张按设备维度统计联网能力一张按点位维度统计可采集性。盘点项统计口径合格线离散车间常见实况设备联网率可稳定上传数据的设备数 / 关键设备总数≥85%30%~50%点表完整度有量纲与缩放系数的点 / 全部采集点≥95%大量裸寄存器数据完整率实际入库点数 / 应入库点数≥99%断连无人知工单在线率MES 工单数 / 实际生产工单数100%纸质派工并行点表是重灾区。很多老设备的通信手册只给寄存器地址不给量纲、不给缩放比例、不给异常值定义采上来的数字在数据库里躺一年也没人敢用。盘点阶段就要把点表按设备型号 寄存器地址 数据类型 缩放系数 工程量纲 采样周期六列固化下来签字确认后再开发。2.3 OEE 基线测算与投资回收期立项论证的代码立项评审时最有力的论据不是行业都在做而是当前 OEE 的损失结构。下面这段脚本把三类损失折算成分钟直接看出该先改哪一块。def oee_loss_breakdown(planned_min, downtime_min, ideal_cycle_s, total_pcs, good_pcs): planned_min : 班次计划运行时间分钟如 8h 班扣掉休息 450 downtime_min : 故障 换型 待料等非计划停机分钟 ideal_cycle_s : 设备铭牌理论节拍秒/件 total_pcs : 实际加工总数 good_pcs : 合格品数 run_min planned_min - downtime_min availability run_min / planned_min performance (ideal_cycle_s * total_pcs / 60.0) / run_min quality good_pcs / total_pcs oee availability * performance * quality # 三类损失折算成分钟用于排序改进优先级 loss_downtime planned_min - run_min loss_speed run_min - ideal_cycle_s * total_pcs / 60.0 loss_quality (total_pcs - good_pcs) * ideal_cycle_s / 60.0 return { availability: round(availability, 4), performance: round(performance, 4), quality: round(quality, 4), oee: round(oee, 4), loss_minutes: { 停机损失: round(loss_downtime, 1), 速度损失: round(loss_speed, 1), 质量损失: round(loss_quality, 1), }, } print(oee_loss_breakdown(450, 62, 38, 520, 498))参数说明上有一条硬规矩ideal_cycle_s必须取设备铭牌或工艺文件的理论节拍不能拿历史最好成绩当基准否则性能开动率会被人为压低指标也就失去对标意义。回收期测算里停机损失的分钟数乘以单位时间毛利就是数字化改造能直接撬动的收益上限如果算出来回收期超过 36 个月通常说明该项目应该先做精益改善而不是上系统。3. 从 PLC 到边缘网关数字化车间的数据采集链路怎么搭采集链路是数字化车间里最容易低估工作量的一段。协议对接往往只占三成时间剩下七成花在点表核对、网络分区、断线补传和数据对齐上。链路设计的核心目标是设备侧尽量不改动网关侧可远程维护数据侧带时间戳和质量码。3.1 现场层协议选型Modbus、OPC UA 与工业以太网的边界选协议先看设备年代和建模需求不要一上来就追求最先进的那一个。协议典型场景单点延迟建模能力采集侧代价Modbus TCP/RTU老机床、仪表、电表10~100ms无纯地址低OPC UA新 PLC、CNC、机器人10~50ms强带信息模型中PROFINET / EtherNet-IP产线内实时控制10ms弱高需专用协议栈MQTT网关到平台回传秒级无低实践中的组合是现场用 Modbus 或 OPC UA 采网关内部统一成一套点位命名再以 MQTT 或 OPC UA 上行。产线实时控制那层不要碰采集只读、不写控制量这个边界在方案评审时就要写死。注意采集链路里任何写操作都要单独审批。见过因为采集程序误写保持寄存器导致产线停机的案例恢复靠的是一份三个月前的 PLC 备份。3.2 Modbus TCP 采集的最小可跑脚本先用一段最小脚本把单台设备跑通再谈规模化。下面这段覆盖了地址偏移、缩放和异常处理三个最容易踩的点。import time from pymodbus.client import ModbusTcpClient # 点表名称 - (4xxxx 地址, 缩放系数, 单位) POINTS { spindle_rpm: (40001, 0.1, r/min), feed_override: (40003, 1.0, %), run_state: (40010, 1.0, ), # 0停机 1待机 2运行 3报警 } def read_points(host192.168.10.31, port502, unit1, timeout1.0): client ModbusTcpClient(host, portport, timeouttimeout) if not client.connect(): raise ConnectionError(f无法连接 {host}:{port}) payload {} try: for name, (addr, scale, unit_str) in POINTS.items(): # Modbus 协议地址从 0 开始点表里的 4xxxx 要减 40001 rr client.read_holding_registers(addressaddr - 40001, count1, slaveunit) if rr.isError(): payload[name] None # 保留空值不要丢点 continue payload[name] round(rr.registers[0] * scale, 3) return payload finally: client.close() # 必须关闭否则长跑会耗尽连接 if __name__ __main__: while True: print(int(time.time()), read_points()) time.sleep(1)逻辑说明address 点表地址 - 40001是最常见的错误来源差一位就是隔壁设备的转速。count1表示单寄存器读32 位浮点要改成count2并做字序拼接字序ABCD/CDAB必须查设备手册猜不得。slave参数在不同版本的库里有unit/device_id的差异升级依赖前先在测试机上验证。参数说明里采样周期要和数据用途匹配用于 OEE 计算的运行状态位1 秒采一次足够用于振动分析的模拟量需要 1kHz 以上的高频采集那就不是 Modbus 能承担的得走单独的采集卡。3.3 OPC UA 统一命名空间与点位建模新设备优先走 OPC UA因为它的地址空间本身就是信息模型可以按设备.部件.变量组织而不是一堆裸地址。import asyncio from asyncua import Client NODES { spindle_rpm: ns2;sCNC01.Spindle.Speed, run_state: ns2;sCNC01.Status.State, alarm_code: ns2;i10231, # 厂商预定义节点数字型 NodeId } async def main(): async with Client(urlopc.tcp://192.168.10.31:4840) as client: # 有账号时改用 client.set_user(user) / client.set_password(pwd) for name, node_id in NODES.items(): node client.get_node(node_id) value await node.read_value() print(name, value) asyncio.run(main())统一命名空间的做法是网关侧维护一份映射表把各家设备的私有命名统一映射成车间.产线.设备.点位五段式MES 和算法侧只认这一套名字。这样换设备或加产线时改的是映射表而不是上层系统的代码。映射表要纳入版本管理和点表一起冻结。3.4 边缘网关落库MQTT 上报与时序库建表网关往上的数据建议落到时序库因为设备数据是典型的写多读少、按时间窗口查的形态。建表时把设备属性放在 TAGS 里把测量值放在列里。CREATE DATABASE IF NOT EXISTS shopfloor KEEP 3650; USE shopfloor; -- 一张超级表管所有设备的测点TAGS 存维度列存数值 CREATE STABLE IF NOT EXISTS machine_metric ( ts TIMESTAMP, value DOUBLE, quality TINYINT -- 0正常 1可疑 2失效 ) TAGS ( workshop BINARY(32), line BINARY(32), asset_id BINARY(64), point BINARY(64) );网关侧的配置用 YAML 描述比较直观采集周期、上报周期、断线缓存策略分开写gateway: device_id: GW-LINE03-01 mqtt: host: 10.20.30.11 port: 1883 topic: shopfloor/line03/{asset_id}/metric qos: 1 # 至少一次配合去重 buffer_when_offline: true buffer_max_points: 200000 collectors: - name: cnc01 protocol: modbus_tcp host: 192.168.10.31 port: 502 unit: 1 poll_interval_ms: 1000 points: /etc/gateway/points/cnc01.csv - name: robot02 protocol: opcua endpoint: opc.tcp://192.168.10.42:4840 subscription_interval_ms: 200 points: /etc/gateway/points/robot02.csvqos: 1意味着可能重复投递所以消费端要按(asset_id, point, ts)做幂等写入。buffer_when_offline是断网续传的关键缓存上限按最长断网时长 × 每秒点数估算一个车间 2000 个点、每秒 1 次、断网 8 小时需要预留约 5800 万点的空间一般网关扛不住得压缩或降频这个容量在方案里要算清楚。4. MES 与智能化应用的集成工单、OEE 与预测性维护的数据闭环数据采上来只是原料。数字化车间真正产生效率提升是在 MES 把工单、物料、设备、质量四类对象关联起来之后。这一步做不好采集链路就成了一个昂贵的电子看板。4.1 ISA-95 对象模型工单、物料、设备、人员怎么串MES 的数据模型底座可以按 ISA-95 的四个对象来设计规划阶段就要确定主键怎么生成避免后期对不齐。对象主键关键属性来源系统工单work_order_id产品、数量、计划起止、状态ERP 下发物料material_lot_id批次、供应商、炉号WMS / ERP设备asset_id型号、所在工位、能力节拍设备台账人员operator_id班组、资质、班次HR / 排班系统四条线通过工单-设备-人员-批次的关联表串起来形成追溯链。实际的难点是时间对齐设备的运行状态按秒采工单按班次切两者要在 MES 侧做时间窗归集。常见做法是设备侧不打工单号MES 侧按设备 时间窗 产品反查工单前提是排产计划准确否则 OEE 会算到隔壁工单头上。4.2 MES 与 SCADA/PLC 的接口设计接口选型要看数据流向和时延要求不要全用一种方式。对接方式方向时延适用数据注意事项OPC UA 订阅MES 读设备100ms 级状态、计数、报警需统一命名空间REST/JSONMES 下发网关秒级工单、配方、参数必须幂等数据库直读网关写 MES 库分钟级历史统计表结构强耦合MQTT 主题设备上报秒级高频状态流QoS 与去重接口设计里有一条铁律MES 不直连 PLC。中间必须有网关或 SCADA 做缓冲原因是一旦 MES 侧网络抖动或重启直连会把请求打到 PLC 通信模块上轻则超时、重则停机。下发类接口要做幂等同一个工单号重复下发只生效一次用work_order_id version做唯一约束。// MES 向网关下发工单的幂等处理示意 app.post(/api/workorder/dispatch, async (req, res) { const { work_order_id, version, product_code, qty } req.body; // 唯一键工单号 版本号重复请求直接返回上次结果 const existing await db.query( SELECT result FROM dispatch_log WHERE work_order_id ? AND version ?, [work_order_id, version] ); if (existing.length 0) { return res.json({ ok: true, idempotent: true, result: existing[0].result }); } const result await gateway.dispatch({ product_code, qty }); await db.insert(dispatch_log, { work_order_id, version, result }); res.json({ ok: true, result }); });这段逻辑的重点是dispatch_log表承担了幂等去重和审计两个职责。参数version由 MES 在每次工单变更时自增网关侧也能据此判断是不是过期指令。4.3 OEE 实时计算的 SQL 与停机归因OEE 的实时计算建议在时序库或数仓侧用窗口聚合完成MES 只负责取结果展示。先按 10 分钟窗口把设备状态压成分钟数再和产量数据关联。-- 第一步状态按窗口聚合每个点代表一个采样周期示例为 10 秒一点 WITH state_agg AS ( SELECT asset_id, _wstart AS window_start, SUM(CASE WHEN run_state 2 THEN 1 ELSE 0 END) * 10 / 60.0 AS run_minutes, SUM(CASE WHEN run_state 0 THEN 1 ELSE 0 END) * 10 / 60.0 AS idle_minutes, SUM(CASE WHEN run_state 3 THEN 1 ELSE 0 END) * 10 / 60.0 AS alarm_minutes FROM machine_status WHERE ts NOW - 8h INTERVAL(10m) GROUP BY asset_id ), -- 第二步产量按同一窗口对齐 count_agg AS ( SELECT asset_id, window_start, SUM(total_count) AS total_count, SUM(good_count) AS good_count, MAX(ideal_cycle_s) AS ideal_cycle_s FROM production_count_10m GROUP BY asset_id, window_start ) SELECT s.asset_id, s.window_start, ROUND(s.run_minutes / NULLIF(s.run_minutes s.idle_minutes, 0), 4) AS availability, ROUND(c.ideal_cycle_s * c.total_count / 60.0 / NULLIF(s.run_minutes, 0), 4) AS performance, ROUND(c.good_count * 1.0 / NULLIF(c.total_count, 0), 4) AS quality, ROUND((s.run_minutes / NULLIF(s.run_minutes s.idle_minutes, 0)) * (c.ideal_cycle_s * c.total_count / 60.0 / NULLIF(s.run_minutes, 0)) * (c.good_count * 1.0 / NULLIF(c.total_count, 0)), 4) AS oee FROM state_agg s JOIN count_agg c ON s.asset_id c.asset_id AND s.window_start c.window_start;停机归因的关键在于状态位要分得够细。停机一个状态对应不了改善动作至少要拆成换型、待料、故障、保养、无排产五类前四类才计入 OEE 分母的扣减项。状态位切换频繁会导致窗口内混状态解决办法是取窗口内占比最大的状态或者把窗口缩到 1 分钟。4.4 智能排产与预测性维护的数据前提这两类智能化应用能不能做取决于数据积累够不够不是取决于算法选得先不先进。预测性维护的最低数据要求是目标设备有连续 3 个月以上的状态与报警记录且至少发生过 5 次同类故障每次故障有可查的时间点和维修记录。达不到这个门槛任何模型都是在拟合噪声。工程上通常先从阈值规则起步——主轴电流持续超过额定值 110%、时长超过 30 秒即报警——跑半年积累标注再考虑上模型。智能排产的前提是节拍数据可信。排产引擎要的是每个产品在每个设备上的实际节拍分布而不是一个平均值。这要求 MES 侧按产品 × 设备 × 班次维度统计节拍并且能识别换型时间。数据没到这个颗粒度排出来的计划车间不会执行最后还是回到 Excel 手工排。5. 智能化车间分阶段落地验收口径与影子模式并行验证规划书里最容易被忽略的一章是怎么算做完了。设备联上网不算MES 上线也不算只有指标口径双方签字、数据能自证这一期才算交付。5.1 三期路线与里程碑常见的节奏是三年三期每期都有可独立验收的产出避免大爆炸式上线。阶段周期核心任务可验收产出一期看得见6~9 个月关键设备联网、点表治理、SCADA 与看板数据完整率 ≥99%OEE 可自动生成二期管得住9~12 个月MES 工单闭环、质量追溯、WMS 联动工单在线率 100%批次追溯 ≤2 分钟三期算得准12 个月以上排产优化、预测性维护、参数寻优排产计划执行率提升、非计划停机下降一期不要碰算法先把数据质量做扎实。二期上 MES 时要同步冻结 OEE 口径因为 MES 上线后数据来源变了前后指标不可比必须在切换时做一次并行对标。5.2 验收指标与常见返工点验收争议大多集中在三个地方数据完整率的统计口径、OEE 的计划时间怎么算、断网期间的数据算不算。这三个都要在合同附件里写清楚公式和排除项。返工点里排第一的是点表变更没有走版本管理。设备厂商升级固件后寄存器地址变了网关还在读老地址采上来的数据全错但不报错因为地址合法、值也合法。应对办法是给关键点位加合理性校验比如主轴转速超过 20000 r/min 直接标记为可疑。第二个是网络分区没做。办公网、MES 网、设备网混在一张网里一次广播风暴就能让产线通信全断。规划阶段就要按三层划分 VLAN网关跨层做单向数据流。5.3 影子模式让新采集链路和老台账并行跑两周我一般在切换前用影子模式验证一遍新采集链路照常运行但结果不进入正式 KPI先和老的人工台账并行两周每天做偏差比对。import pandas as pd # 新链路自动统计与人工台账比对输出偏差率 new pd.read_csv(auto_oee_daily.csv) # asset_id, date, oee_auto old pd.read_csv(manual_oee_daily.csv) # asset_id, date, oee_manual merged new.merge(old, on[asset_id, date], howinner) merged[abs_gap] (merged[oee_auto] - merged[oee_manual]).abs() merged[gap_rate] merged[abs_gap] / merged[oee_manual] # 偏差超过 5 个百分点的记录单独列出逐条回溯 suspicious merged[merged[gap_rate] 0.05].sort_values(abs_gap, ascendingFalse) print(f总记录 {len(merged)} 条偏差超阈值 {len(suspicious)} 条) print(suspicious.head(20))两周并行能暴露的问题非常具体某台设备的计数点少采了、某个班次的计划时间口径不一致、跨零点工单归属错误。这些问题在上线前修掉成本是上线后修的十分之一。影子模式还有一个附带作用——让班组长参与校验他们对哪台设备的数据不准往往比系统日志更早发现。本文还有配套的精品资源点击获取 数字化车间到智能化车间：ISA-95规划、数据采集与MES闭环
简介这是一份面向制造企业技术管理者、车间规划人员及智能制造方向学习者的PPT资料围绕数字化、智能化车间的规划与建设展开系统梳理数字化转型、工业互联网、车间布局规划与智能制造四条主线。内容涵盖数据采集与数据挖掘驱动的业务流程优化、设备互联与数据共享、机器学习与边缘计算等关键技术的落地路径并延伸到生产流程与供应链的实时监控和优化适合用于企业内训、项目立项汇报或个人知识体系搭建。压缩包内为1个pptx文件约21.13MB以演示文稿形式按章节组织页面结构清晰便于直接引用或二次修改。该资料已有2230人学习可作为理解智能车间整体架构、梳理技术要点与规划思路的参考素材。1. 数字化车间和智能化车间规划阶段的三条分水岭车间改造立项会上最常见的一幕是把《数字化、智能化车间规划与建设》翻开第一页上面写着三年建成无人化智能工厂可真到排预算时钱基本砸在设备联网、点表梳理和 MES 补课上。这不是方案写错了而是两个阶段的边界没分清。数字化车间解决的是看得见设备状态、工单进度、质量数据实时在线报表不再靠班组长手填。智能化车间解决的是算得准、调得动排产可执行、工艺参数可寻优、设备劣化可提前预警。分水岭有三条——数据是否自动采集而非人工填报、模型输出是否有闭环执行通道、投入产出是否有可核算口径。这三条决定了规划书里哪些内容能落地哪些只能留在汇报页上。往下按 ISA-95 分层盘家底、搭采集链路、接 MES 与算法、分阶段验收是大多数离散制造车间走得通的一条路径。2. 数字化车间规划第一步用 ISA-95 分层盘清家底与 KPI 基线规划最容易出问题的地方是拿着一张产线布局图就开始画系统架构。设备有哪些型号、哪些能联网、点表全不全、班次怎么排这些没盘清楚后面所有方案都是空中楼阁。数字化车间的规划顺序应该是分层建模 → 现状盘点 → KPI 基线 → 投资测算顺序反了就要返工。2.1 用 ISA-95 五层模型给车间画一张资产地图ISA-95 把制造企业分成五层车间的规划边界通常落在 L0 到 L3 之间。分层的作用不是画得好看而是明确每一层的责任主体、数据时间尺度和采购归属避免 MES 厂商和自动化厂商互相甩锅。层级名称典型系统时间尺度规划中的落点L4企业资源层ERP天/周订单、BOM、成本口径L3制造运营层MES/MOM、WMS、QMS秒~班次派工、追溯、SPCL2监控层SCADA、HMI、组态100ms~秒画面、报警、手自动切换L1控制层PLC、CNC、机器人1~100ms联锁逻辑、运动控制L0现场层传感器、仪表、执行器ms 级物理量采集与动作执行关键判断是L2 到 L3 之间是数字化的主战场也是钱花得最多的一层。L0/L1 通常随设备采购已经带上了改造成本高、收益小能不动的尽量不动L3 是价值放大的地方工单、物料、质量、设备四类对象在这里汇聚。规划书里把设备改造清单和系统集成清单分开列评审时就不会被一句让设备厂商配合带过去。2.2 设备联网率与点表完整度现状盘点的两张底表盘点要用可量化的口径不然就是走一圈看看。我一般只做两张表一张按设备维度统计联网能力一张按点位维度统计可采集性。盘点项统计口径合格线离散车间常见实况设备联网率可稳定上传数据的设备数 / 关键设备总数≥85%30%~50%点表完整度有量纲与缩放系数的点 / 全部采集点≥95%大量裸寄存器数据完整率实际入库点数 / 应入库点数≥99%断连无人知工单在线率MES 工单数 / 实际生产工单数100%纸质派工并行点表是重灾区。很多老设备的通信手册只给寄存器地址不给量纲、不给缩放比例、不给异常值定义采上来的数字在数据库里躺一年也没人敢用。盘点阶段就要把点表按设备型号 寄存器地址 数据类型 缩放系数 工程量纲 采样周期六列固化下来签字确认后再开发。2.3 OEE 基线测算与投资回收期立项论证的代码立项评审时最有力的论据不是行业都在做而是当前 OEE 的损失结构。下面这段脚本把三类损失折算成分钟直接看出该先改哪一块。def oee_loss_breakdown(planned_min, downtime_min, ideal_cycle_s, total_pcs, good_pcs): planned_min : 班次计划运行时间分钟如 8h 班扣掉休息 450 downtime_min : 故障 换型 待料等非计划停机分钟 ideal_cycle_s : 设备铭牌理论节拍秒/件 total_pcs : 实际加工总数 good_pcs : 合格品数 run_min planned_min - downtime_min availability run_min / planned_min performance (ideal_cycle_s * total_pcs / 60.0) / run_min quality good_pcs / total_pcs oee availability * performance * quality # 三类损失折算成分钟用于排序改进优先级 loss_downtime planned_min - run_min loss_speed run_min - ideal_cycle_s * total_pcs / 60.0 loss_quality (total_pcs - good_pcs) * ideal_cycle_s / 60.0 return { availability: round(availability, 4), performance: round(performance, 4), quality: round(quality, 4), oee: round(oee, 4), loss_minutes: { 停机损失: round(loss_downtime, 1), 速度损失: round(loss_speed, 1), 质量损失: round(loss_quality, 1), }, } print(oee_loss_breakdown(450, 62, 38, 520, 498))参数说明上有一条硬规矩ideal_cycle_s必须取设备铭牌或工艺文件的理论节拍不能拿历史最好成绩当基准否则性能开动率会被人为压低指标也就失去对标意义。回收期测算里停机损失的分钟数乘以单位时间毛利就是数字化改造能直接撬动的收益上限如果算出来回收期超过 36 个月通常说明该项目应该先做精益改善而不是上系统。3. 从 PLC 到边缘网关数字化车间的数据采集链路怎么搭采集链路是数字化车间里最容易低估工作量的一段。协议对接往往只占三成时间剩下七成花在点表核对、网络分区、断线补传和数据对齐上。链路设计的核心目标是设备侧尽量不改动网关侧可远程维护数据侧带时间戳和质量码。3.1 现场层协议选型Modbus、OPC UA 与工业以太网的边界选协议先看设备年代和建模需求不要一上来就追求最先进的那一个。协议典型场景单点延迟建模能力采集侧代价Modbus TCP/RTU老机床、仪表、电表10~100ms无纯地址低OPC UA新 PLC、CNC、机器人10~50ms强带信息模型中PROFINET / EtherNet-IP产线内实时控制10ms弱高需专用协议栈MQTT网关到平台回传秒级无低实践中的组合是现场用 Modbus 或 OPC UA 采网关内部统一成一套点位命名再以 MQTT 或 OPC UA 上行。产线实时控制那层不要碰采集只读、不写控制量这个边界在方案评审时就要写死。注意采集链路里任何写操作都要单独审批。见过因为采集程序误写保持寄存器导致产线停机的案例恢复靠的是一份三个月前的 PLC 备份。3.2 Modbus TCP 采集的最小可跑脚本先用一段最小脚本把单台设备跑通再谈规模化。下面这段覆盖了地址偏移、缩放和异常处理三个最容易踩的点。import time from pymodbus.client import ModbusTcpClient # 点表名称 - (4xxxx 地址, 缩放系数, 单位) POINTS { spindle_rpm: (40001, 0.1, r/min), feed_override: (40003, 1.0, %), run_state: (40010, 1.0, ), # 0停机 1待机 2运行 3报警 } def read_points(host192.168.10.31, port502, unit1, timeout1.0): client ModbusTcpClient(host, portport, timeouttimeout) if not client.connect(): raise ConnectionError(f无法连接 {host}:{port}) payload {} try: for name, (addr, scale, unit_str) in POINTS.items(): # Modbus 协议地址从 0 开始点表里的 4xxxx 要减 40001 rr client.read_holding_registers(addressaddr - 40001, count1, slaveunit) if rr.isError(): payload[name] None # 保留空值不要丢点 continue payload[name] round(rr.registers[0] * scale, 3) return payload finally: client.close() # 必须关闭否则长跑会耗尽连接 if __name__ __main__: while True: print(int(time.time()), read_points()) time.sleep(1)逻辑说明address 点表地址 - 40001是最常见的错误来源差一位就是隔壁设备的转速。count1表示单寄存器读32 位浮点要改成count2并做字序拼接字序ABCD/CDAB必须查设备手册猜不得。slave参数在不同版本的库里有unit/device_id的差异升级依赖前先在测试机上验证。参数说明里采样周期要和数据用途匹配用于 OEE 计算的运行状态位1 秒采一次足够用于振动分析的模拟量需要 1kHz 以上的高频采集那就不是 Modbus 能承担的得走单独的采集卡。3.3 OPC UA 统一命名空间与点位建模新设备优先走 OPC UA因为它的地址空间本身就是信息模型可以按设备.部件.变量组织而不是一堆裸地址。import asyncio from asyncua import Client NODES { spindle_rpm: ns2;sCNC01.Spindle.Speed, run_state: ns2;sCNC01.Status.State, alarm_code: ns2;i10231, # 厂商预定义节点数字型 NodeId } async def main(): async with Client(urlopc.tcp://192.168.10.31:4840) as client: # 有账号时改用 client.set_user(user) / client.set_password(pwd) for name, node_id in NODES.items(): node client.get_node(node_id) value await node.read_value() print(name, value) asyncio.run(main())统一命名空间的做法是网关侧维护一份映射表把各家设备的私有命名统一映射成车间.产线.设备.点位五段式MES 和算法侧只认这一套名字。这样换设备或加产线时改的是映射表而不是上层系统的代码。映射表要纳入版本管理和点表一起冻结。3.4 边缘网关落库MQTT 上报与时序库建表网关往上的数据建议落到时序库因为设备数据是典型的写多读少、按时间窗口查的形态。建表时把设备属性放在 TAGS 里把测量值放在列里。CREATE DATABASE IF NOT EXISTS shopfloor KEEP 3650; USE shopfloor; -- 一张超级表管所有设备的测点TAGS 存维度列存数值 CREATE STABLE IF NOT EXISTS machine_metric ( ts TIMESTAMP, value DOUBLE, quality TINYINT -- 0正常 1可疑 2失效 ) TAGS ( workshop BINARY(32), line BINARY(32), asset_id BINARY(64), point BINARY(64) );网关侧的配置用 YAML 描述比较直观采集周期、上报周期、断线缓存策略分开写gateway: device_id: GW-LINE03-01 mqtt: host: 10.20.30.11 port: 1883 topic: shopfloor/line03/{asset_id}/metric qos: 1 # 至少一次配合去重 buffer_when_offline: true buffer_max_points: 200000 collectors: - name: cnc01 protocol: modbus_tcp host: 192.168.10.31 port: 502 unit: 1 poll_interval_ms: 1000 points: /etc/gateway/points/cnc01.csv - name: robot02 protocol: opcua endpoint: opc.tcp://192.168.10.42:4840 subscription_interval_ms: 200 points: /etc/gateway/points/robot02.csvqos: 1意味着可能重复投递所以消费端要按(asset_id, point, ts)做幂等写入。buffer_when_offline是断网续传的关键缓存上限按最长断网时长 × 每秒点数估算一个车间 2000 个点、每秒 1 次、断网 8 小时需要预留约 5800 万点的空间一般网关扛不住得压缩或降频这个容量在方案里要算清楚。4. MES 与智能化应用的集成工单、OEE 与预测性维护的数据闭环数据采上来只是原料。数字化车间真正产生效率提升是在 MES 把工单、物料、设备、质量四类对象关联起来之后。这一步做不好采集链路就成了一个昂贵的电子看板。4.1 ISA-95 对象模型工单、物料、设备、人员怎么串MES 的数据模型底座可以按 ISA-95 的四个对象来设计规划阶段就要确定主键怎么生成避免后期对不齐。对象主键关键属性来源系统工单work_order_id产品、数量、计划起止、状态ERP 下发物料material_lot_id批次、供应商、炉号WMS / ERP设备asset_id型号、所在工位、能力节拍设备台账人员operator_id班组、资质、班次HR / 排班系统四条线通过工单-设备-人员-批次的关联表串起来形成追溯链。实际的难点是时间对齐设备的运行状态按秒采工单按班次切两者要在 MES 侧做时间窗归集。常见做法是设备侧不打工单号MES 侧按设备 时间窗 产品反查工单前提是排产计划准确否则 OEE 会算到隔壁工单头上。4.2 MES 与 SCADA/PLC 的接口设计接口选型要看数据流向和时延要求不要全用一种方式。对接方式方向时延适用数据注意事项OPC UA 订阅MES 读设备100ms 级状态、计数、报警需统一命名空间REST/JSONMES 下发网关秒级工单、配方、参数必须幂等数据库直读网关写 MES 库分钟级历史统计表结构强耦合MQTT 主题设备上报秒级高频状态流QoS 与去重接口设计里有一条铁律MES 不直连 PLC。中间必须有网关或 SCADA 做缓冲原因是一旦 MES 侧网络抖动或重启直连会把请求打到 PLC 通信模块上轻则超时、重则停机。下发类接口要做幂等同一个工单号重复下发只生效一次用work_order_id version做唯一约束。// MES 向网关下发工单的幂等处理示意 app.post(/api/workorder/dispatch, async (req, res) { const { work_order_id, version, product_code, qty } req.body; // 唯一键工单号 版本号重复请求直接返回上次结果 const existing await db.query( SELECT result FROM dispatch_log WHERE work_order_id ? AND version ?, [work_order_id, version] ); if (existing.length 0) { return res.json({ ok: true, idempotent: true, result: existing[0].result }); } const result await gateway.dispatch({ product_code, qty }); await db.insert(dispatch_log, { work_order_id, version, result }); res.json({ ok: true, result }); });这段逻辑的重点是dispatch_log表承担了幂等去重和审计两个职责。参数version由 MES 在每次工单变更时自增网关侧也能据此判断是不是过期指令。4.3 OEE 实时计算的 SQL 与停机归因OEE 的实时计算建议在时序库或数仓侧用窗口聚合完成MES 只负责取结果展示。先按 10 分钟窗口把设备状态压成分钟数再和产量数据关联。-- 第一步状态按窗口聚合每个点代表一个采样周期示例为 10 秒一点 WITH state_agg AS ( SELECT asset_id, _wstart AS window_start, SUM(CASE WHEN run_state 2 THEN 1 ELSE 0 END) * 10 / 60.0 AS run_minutes, SUM(CASE WHEN run_state 0 THEN 1 ELSE 0 END) * 10 / 60.0 AS idle_minutes, SUM(CASE WHEN run_state 3 THEN 1 ELSE 0 END) * 10 / 60.0 AS alarm_minutes FROM machine_status WHERE ts NOW - 8h INTERVAL(10m) GROUP BY asset_id ), -- 第二步产量按同一窗口对齐 count_agg AS ( SELECT asset_id, window_start, SUM(total_count) AS total_count, SUM(good_count) AS good_count, MAX(ideal_cycle_s) AS ideal_cycle_s FROM production_count_10m GROUP BY asset_id, window_start ) SELECT s.asset_id, s.window_start, ROUND(s.run_minutes / NULLIF(s.run_minutes s.idle_minutes, 0), 4) AS availability, ROUND(c.ideal_cycle_s * c.total_count / 60.0 / NULLIF(s.run_minutes, 0), 4) AS performance, ROUND(c.good_count * 1.0 / NULLIF(c.total_count, 0), 4) AS quality, ROUND((s.run_minutes / NULLIF(s.run_minutes s.idle_minutes, 0)) * (c.ideal_cycle_s * c.total_count / 60.0 / NULLIF(s.run_minutes, 0)) * (c.good_count * 1.0 / NULLIF(c.total_count, 0)), 4) AS oee FROM state_agg s JOIN count_agg c ON s.asset_id c.asset_id AND s.window_start c.window_start;停机归因的关键在于状态位要分得够细。停机一个状态对应不了改善动作至少要拆成换型、待料、故障、保养、无排产五类前四类才计入 OEE 分母的扣减项。状态位切换频繁会导致窗口内混状态解决办法是取窗口内占比最大的状态或者把窗口缩到 1 分钟。4.4 智能排产与预测性维护的数据前提这两类智能化应用能不能做取决于数据积累够不够不是取决于算法选得先不先进。预测性维护的最低数据要求是目标设备有连续 3 个月以上的状态与报警记录且至少发生过 5 次同类故障每次故障有可查的时间点和维修记录。达不到这个门槛任何模型都是在拟合噪声。工程上通常先从阈值规则起步——主轴电流持续超过额定值 110%、时长超过 30 秒即报警——跑半年积累标注再考虑上模型。智能排产的前提是节拍数据可信。排产引擎要的是每个产品在每个设备上的实际节拍分布而不是一个平均值。这要求 MES 侧按产品 × 设备 × 班次维度统计节拍并且能识别换型时间。数据没到这个颗粒度排出来的计划车间不会执行最后还是回到 Excel 手工排。5. 智能化车间分阶段落地验收口径与影子模式并行验证规划书里最容易被忽略的一章是怎么算做完了。设备联上网不算MES 上线也不算只有指标口径双方签字、数据能自证这一期才算交付。5.1 三期路线与里程碑常见的节奏是三年三期每期都有可独立验收的产出避免大爆炸式上线。阶段周期核心任务可验收产出一期看得见6~9 个月关键设备联网、点表治理、SCADA 与看板数据完整率 ≥99%OEE 可自动生成二期管得住9~12 个月MES 工单闭环、质量追溯、WMS 联动工单在线率 100%批次追溯 ≤2 分钟三期算得准12 个月以上排产优化、预测性维护、参数寻优排产计划执行率提升、非计划停机下降一期不要碰算法先把数据质量做扎实。二期上 MES 时要同步冻结 OEE 口径因为 MES 上线后数据来源变了前后指标不可比必须在切换时做一次并行对标。5.2 验收指标与常见返工点验收争议大多集中在三个地方数据完整率的统计口径、OEE 的计划时间怎么算、断网期间的数据算不算。这三个都要在合同附件里写清楚公式和排除项。返工点里排第一的是点表变更没有走版本管理。设备厂商升级固件后寄存器地址变了网关还在读老地址采上来的数据全错但不报错因为地址合法、值也合法。应对办法是给关键点位加合理性校验比如主轴转速超过 20000 r/min 直接标记为可疑。第二个是网络分区没做。办公网、MES 网、设备网混在一张网里一次广播风暴就能让产线通信全断。规划阶段就要按三层划分 VLAN网关跨层做单向数据流。5.3 影子模式让新采集链路和老台账并行跑两周我一般在切换前用影子模式验证一遍新采集链路照常运行但结果不进入正式 KPI先和老的人工台账并行两周每天做偏差比对。import pandas as pd # 新链路自动统计与人工台账比对输出偏差率 new pd.read_csv(auto_oee_daily.csv) # asset_id, date, oee_auto old pd.read_csv(manual_oee_daily.csv) # asset_id, date, oee_manual merged new.merge(old, on[asset_id, date], howinner) merged[abs_gap] (merged[oee_auto] - merged[oee_manual]).abs() merged[gap_rate] merged[abs_gap] / merged[oee_manual] # 偏差超过 5 个百分点的记录单独列出逐条回溯 suspicious merged[merged[gap_rate] 0.05].sort_values(abs_gap, ascendingFalse) print(f总记录 {len(merged)} 条偏差超阈值 {len(suspicious)} 条) print(suspicious.head(20))两周并行能暴露的问题非常具体某台设备的计数点少采了、某个班次的计划时间口径不一致、跨零点工单归属错误。这些问题在上线前修掉成本是上线后修的十分之一。影子模式还有一个附带作用——让班组长参与校验他们对哪台设备的数据不准往往比系统日志更早发现。本文还有配套的精品资源点击获取