拓冰网站定制 
简介这份PPT资料围绕第四次工业革命背景下的智能工厂与智能制造展开面向制造业从业者、工业工程与自动化相关专业学生及技术管理者帮助系统理解从智慧工厂到智能生产的核心框架。内容涵盖信息物理系统CPS、物联网与互联服务融合、智能物料与智能产品的动态数据存储与感知通信、基于RFID与传感器的车间架构以及多模式人机交互、大数据挖掘与知识发现、增强现实辅助系统等关键议题并延伸至智能装配、协作机器人与面向服务的工厂布局。资源包内含1个PPT文件约30.44MB以图文并茂的幻灯片形式呈现便于课堂讲授、内部培训或自学梳理知识脉络。目前已有220人学习下载适合需要快速建立智能制造整体认知、把握工业4.0两大主题与三个设想的读者参考。1. 智能工厂和智能制造.ppt一份被低估的落地路线图很多制造企业的数字化项目死在“PPT 很漂亮车间不买账”这一步。我见过太多工厂花几十万做的智能工厂和智能制造.ppt 方案汇报时领导点头落地时产线摇头——因为 PPT 里写的是“设备联网率 95%”现场连 PLC 的通讯口在哪都没人说得清。这份标题里的“智能工厂和智能制造.ppt”本质上不是一份汇报材料而是一张需要拆成工位级动作的施工图。它要解决的核心问题是如何把智能制造从概念词变成车间里可执行的采集、传输、分析和反馈闭环。适合谁看适合那些手里已经有一份类似 PPT、但不知道怎么往下走的制造企业 IT/OT 工程师、产线自动化负责人以及需要给老板交落地答卷的项目经理。热搜词“智能工厂数据管理方案”之所以反复出现恰恰说明大家卡在同一个地方数据从哪来、放哪、怎么用。2. 拆解智能工厂和智能制造.ppt 里的四层架构从设备层到决策层怎么落一份能落地的智能工厂 PPT骨架一定是四层设备层、边缘层、平台层、应用层。但 PPT 上通常只画了框和箭头真正动手时每一层都有具体的协议、硬件和参数要选。我一般会先把这四层对应到车间里的物理对象再决定每一层用什么技术栈。2.1 设备层PLC、CNC、传感器怎么接进来设备层是智能制造的“手和脚”也是最脏最累的一层。常见做法是对于西门子 S7-1200/1500 系列 PLC走 S7 协议或 OPC UA对于三菱、欧姆龙走 MC 协议或 FINS对于发那科、西门子 840D 数控系统走 FOCAS 或 OPC UA。传感器如果是 IO-Link 的直接进 IO-Link 主站再转 Profinet 或 EtherNet/IP。这里有一个血泪经验不要一上来就追求“全量采集”。先列一张表把每台设备按“是否影响关键质量特性”分成 A/B/C 三类。A 类设备必须采B 类设备按需采C 类设备先不采。下面是一个设备接入优先级表的示例设备类型通讯方式采集频率优先级典型数据点注塑机OPC UA1sA锁模力、射胶速度、温度装配线 PLCS7500msA节拍、工位状态、报警空压机Modbus TCP10sB压力、运行时长老化测试架人工录入每班C测试结果采集频率不是越高越好。500ms 和 1s 对大多数离散制造够用了再快就是给网络和存储找麻烦。2.2 边缘层数据在进平台之前要做的三件事边缘层是智能工厂和智能制造.ppt 里最容易被画成“一个盒子”的部分但实际要做三件事协议转换、数据清洗、断网缓存。协议转换用软件网关或硬件网关都行。我一般用 Python 写一个轻量级采集服务跑在工控机上配合 pymodbus、python-snap7 这类库。下面是一个最小可用的 Modbus TCP 采集脚本from pymodbus.client import ModbusTcpClient import time import json # 连接 PLCIP 和端口按现场实际改 client ModbusTcpClient(192.168.1.10, port502) client.connect() # 读取保持寄存器地址 0 开始读 10 个 while True: try: rr client.read_holding_registers(address0, count10, slave1) if not rr.isError(): # 假设前两个寄存器是温度和压力缩放系数 0.1 data { temperature: rr.registers[0] * 0.1, pressure: rr.registers[1] * 0.1, ts: int(time.time() * 1000) } # 这里可以发到 MQTT 或写入本地 SQLite print(json.dumps(data)) else: print(Modbus error:, rr) except Exception as e: print(采集异常:, e) time.sleep(1)逻辑说明这个脚本每 1 秒读一次 PLC 的 10 个保持寄存器把前两个按 0.1 缩放后打包成 JSON。参数说明address0是起始寄存器地址不同品牌 PLC 的地址偏移不一样三菱和西门子差很多一定要对着通讯手册改slave1是从站号现场有多个从站时不能搞错count10是一次读多少个寄存器读多了会超时读少了要多次请求。数据清洗主要做三件事去重、去跳变、补缺失。去跳变就是设一个合理范围比如温度不可能在 1 秒内从 20 度跳到 200 度超过就丢弃。断网缓存用 SQLite 或本地文件都行网络恢复后按时间戳补传。2.3 平台层智能工厂数据管理方案的选型逻辑热搜词“智能工厂数据管理方案”指向的就是这一层。平台层选型没有标准答案但有一条铁律不要为了“大数据”而大数据。年产量 100 万件以下的工厂时序数据库用 InfluxDB 或 TDengine 单机版就够了上 Hadoop 就是给自己找运维麻烦。我一般按三个维度选数据量、查询模式、团队能力。数据量小于 10 万点/秒TDengine 或 InfluxDB 都能扛查询模式如果以“最近 1 小时某设备某参数”为主时序数据库最合适如果团队没有专职运维选托管服务或单机版别碰分布式。平台层还要做一件事统一命名规范。设备名、测点名、工单号必须有一套规则。我见过一个厂同一个温度点在三份 PPT 里叫三个名字最后数据对不上查了一周。常见做法是车间_产线_设备_测点比如A1_Line2_Inj3_Temp。2.4 应用层从看板到闭环控制的最后一公里应用层是老板在 PPT 里最关注的部分但也是最容易做成“大屏摆设”的部分。看板谁都会做难的是闭环。比如注塑机温度超限系统不只是报警还要自动降速或停机。这需要应用层和设备层之间有反向控制通道。反向控制要非常谨慎。我一般会设三道保险软件限值、PLC 硬限值、物理急停。软件限值在应用层判断PLC 硬限值在设备层兜底物理急停是最后一道。任何一道触发都必须记录原因和时间戳方便追溯。3. 用 OPC UA 和 MQTT 搭一条最小可跑的数据链路这一章给一个能直接抄作业的最小链路一台西门子 S7-1500 PLC 通过 OPC UA 服务端暴露数据一个 Python 客户端订阅再通过 MQTT 发到 EMQX最后写入 TDengine。整条链路在一台工控机上就能跑通。3.1 在 S7-1500 上启用 OPC UA 服务端在 TIA Portal 里打开 PLC 的设备组态找到“OPC UA”选项勾选“激活 OPC UA 服务器”。然后设置端口号默认 4840。接着在“服务器接口”里添加需要暴露的变量比如DB1.Temperature、DB1.Pressure。安全策略先选“无”等链路通了再上证书。注意S7-1500 的 OPC UA 服务端有连接数限制具体看 CPU 型号一般 5 到 10 个。如果多个客户端要连考虑用 OPC UA 聚合服务器。3.2 Python 客户端订阅 OPC UA 并转发 MQTTfrom opcua import Client import paho.mqtt.client as mqtt import json import time # OPC UA 服务端地址按现场改 opc_url opc.tcp://192.168.1.20:4840 client Client(opc_url) client.connect() # MQTT 代理地址 mqtt_client mqtt.Client() mqtt_client.connect(192.168.1.30, 1883, 60) # 获取节点节点 ID 在 TIA Portal 里能看到 temp_node client.get_node(ns3;s\DB1\.\Temperature\) pressure_node client.get_node(ns3;s\DB1\.\Pressure\) while True: try: temp temp_node.get_value() pressure pressure_node.get_value() payload { device: Inj3, temperature: temp, pressure: pressure, ts: int(time.time() * 1000) } # 发布到 MQTT主题按车间/产线/设备分层 mqtt_client.publish(factory/A1/Line2/Inj3/data, json.dumps(payload)) print(已发送:, payload) except Exception as e: print(OPC UA 读取失败:, e) time.sleep(1)逻辑说明这个脚本每 1 秒从 OPC UA 服务端读两个节点打包成 JSON 后发到 MQTT。参数说明ns3是命名空间索引不同项目的索引可能不同在 UaExpert 里能看到sDB1.Temperature是节点标识符字符串里的引号要转义MQTT 主题用/分层方便后面用通配符订阅。3.3 用 EMQX 规则引擎把数据写入 TDengineEMQX 自带规则引擎不用写代码就能把 MQTT 消息写入 TDengine。在 EMQX Dashboard 里新建一条规则SQL 写SELECT payload.device as device, payload.temperature as temperature, payload.pressure as pressure, payload.ts as ts FROM factory/A1/Line2/Inj3/data然后添加一个“数据转发到 TDengine”的动作填上 TDengine 的地址、数据库名和超级表名。TDengine 里先建好超级表CREATE STABLE factory_data ( ts TIMESTAMP, temperature FLOAT, pressure FLOAT ) TAGS ( device NCHAR(32) );这样每条 MQTT 消息会自动写入 TDengine按设备建子表。查询时用SELECT * FROM factory_data WHERE deviceInj3 AND ts now - 1h就能拿到最近一小时的数据。4. 智能工厂和智能制造.ppt 落地时最容易翻车的五个坑这一章按“现象 → 原因 → 解决”写都是我在现场踩过的。4.1 坑一OPC UA 连上了但读不到数据现象客户端显示连接成功但get_value()返回 None 或报 BadNodeIdUnknown。原因节点 ID 写错了。TIA Portal 里看到的节点 ID 和 OPC UA 客户端里的不完全一样尤其是字符串节点引号和命名空间索引容易搞混。解决用 UaExpert 先连上服务端在地址空间里找到目标节点直接复制 NodeId。不要手写。4.2 坑二MQTT 消息延迟忽高忽低现象大部分消息 1 秒内到偶尔有几条延迟十几秒。原因QoS 设成了 0网络抖动时消息丢了或重传或者 EMQX 的规则引擎处理不过来。解决关键数据用 QoS 1非关键用 QoS 0。EMQX 规则引擎如果压力大加一个缓冲队列或者把规则拆成多条并行。4.3 坑三TDengine 写入报错“table already exists”现象程序跑一段时间后开始报错说子表已存在。原因TDengine 自动建子表时如果设备名有特殊字符或大小写不一致会重复建表。解决统一设备名规范全用大写或全用小写不要混用。特殊字符用下划线代替。4.4 坑四看板数据和生产日报对不上现象看板显示产量 1000日报写 980。原因看板统计的是“设备动作次数”日报统计的是“质检合格数”两个口径不一样。解决在平台层定义清楚每个指标的口径写进数据字典。看板和日报用同一个数据源不要各算各的。4.5 坑五反向控制被 PLC 拒绝现象应用层下发停机指令PLC 不执行。原因PLC 的安全逻辑优先级高于外部指令或者通讯写权限没开。解决先确认 PLC 里有没有硬限值逻辑再检查 OPC UA 或 Modbus 的写权限。反向控制一定要走单独的通道不要和采集通道混用。5. 用历史数据反推设备节拍一个验证智能制造成效的小技巧最后一章给一个具体技巧怎么用采集到的历史数据反推设备真实节拍验证智能工厂和智能制造.ppt 里写的“效率提升 20%”到底有没有发生。方法很简单从 TDengine 里拉一台设备一周的“运行状态”数据找出每次从“运行”变“停止”再变“运行”的时间差去掉异常值后取中位数就是真实节拍。下面是一个查询示例SELECT ts, status, DIFF(ts) / 1000 AS duration_sec FROM ( SELECT ts, status, LAG(status) OVER (ORDER BY ts) AS prev_status FROM factory_data WHERE device Inj3 AND ts now - 7d ) WHERE status RUN AND prev_status STOP ORDER BY ts;逻辑说明先用窗口函数LAG拿到上一条状态再筛选出“上一条是 STOP、当前是 RUN”的记录DIFF(ts)算出两次之间的毫秒数除以 1000 变成秒。参数说明now - 7d是最近 7 天TDengine 支持这种写法device Inj3按设备过滤。拿到这些 duration_sec 后用 Python 算中位数和四分位距import numpy as np durations [12.3, 11.8, 12.1, 45.6, 12.0, 11.9, 12.2] # 从数据库查出来的 q1 np.percentile(durations, 25) q3 np.percentile(durations, 75) iqr q3 - q1 # 去掉超过 1.5 倍四分位距的异常值 clean [d for d in durations if q1 - 1.5 * iqr d q3 1.5 * iqr] median np.median(clean) print(f真实节拍中位数: {median:.2f} 秒)这个中位数就是设备在正常情况下的真实节拍。拿它和 PPT 里写的“目标节拍”对比就能知道差距在哪。如果中位数比目标慢很多先别怪设备查查是不是换模时间太长、来料不及时、或者操作员干预太多。我自己的习惯是每做一个智能工厂项目上线三个月后一定跑一次这个分析。PPT 里的数字可以美化但设备状态跳变的时间戳不会骗人。希望帮到你。本文还有配套的精品资源点击获取 智能工厂和智能制造.ppt落地指南：从设备层到应用层的四层架构与数据链路实战
简介这份PPT资料围绕第四次工业革命背景下的智能工厂与智能制造展开面向制造业从业者、工业工程与自动化相关专业学生及技术管理者帮助系统理解从智慧工厂到智能生产的核心框架。内容涵盖信息物理系统CPS、物联网与互联服务融合、智能物料与智能产品的动态数据存储与感知通信、基于RFID与传感器的车间架构以及多模式人机交互、大数据挖掘与知识发现、增强现实辅助系统等关键议题并延伸至智能装配、协作机器人与面向服务的工厂布局。资源包内含1个PPT文件约30.44MB以图文并茂的幻灯片形式呈现便于课堂讲授、内部培训或自学梳理知识脉络。目前已有220人学习下载适合需要快速建立智能制造整体认知、把握工业4.0两大主题与三个设想的读者参考。1. 智能工厂和智能制造.ppt一份被低估的落地路线图很多制造企业的数字化项目死在“PPT 很漂亮车间不买账”这一步。我见过太多工厂花几十万做的智能工厂和智能制造.ppt 方案汇报时领导点头落地时产线摇头——因为 PPT 里写的是“设备联网率 95%”现场连 PLC 的通讯口在哪都没人说得清。这份标题里的“智能工厂和智能制造.ppt”本质上不是一份汇报材料而是一张需要拆成工位级动作的施工图。它要解决的核心问题是如何把智能制造从概念词变成车间里可执行的采集、传输、分析和反馈闭环。适合谁看适合那些手里已经有一份类似 PPT、但不知道怎么往下走的制造企业 IT/OT 工程师、产线自动化负责人以及需要给老板交落地答卷的项目经理。热搜词“智能工厂数据管理方案”之所以反复出现恰恰说明大家卡在同一个地方数据从哪来、放哪、怎么用。2. 拆解智能工厂和智能制造.ppt 里的四层架构从设备层到决策层怎么落一份能落地的智能工厂 PPT骨架一定是四层设备层、边缘层、平台层、应用层。但 PPT 上通常只画了框和箭头真正动手时每一层都有具体的协议、硬件和参数要选。我一般会先把这四层对应到车间里的物理对象再决定每一层用什么技术栈。2.1 设备层PLC、CNC、传感器怎么接进来设备层是智能制造的“手和脚”也是最脏最累的一层。常见做法是对于西门子 S7-1200/1500 系列 PLC走 S7 协议或 OPC UA对于三菱、欧姆龙走 MC 协议或 FINS对于发那科、西门子 840D 数控系统走 FOCAS 或 OPC UA。传感器如果是 IO-Link 的直接进 IO-Link 主站再转 Profinet 或 EtherNet/IP。这里有一个血泪经验不要一上来就追求“全量采集”。先列一张表把每台设备按“是否影响关键质量特性”分成 A/B/C 三类。A 类设备必须采B 类设备按需采C 类设备先不采。下面是一个设备接入优先级表的示例设备类型通讯方式采集频率优先级典型数据点注塑机OPC UA1sA锁模力、射胶速度、温度装配线 PLCS7500msA节拍、工位状态、报警空压机Modbus TCP10sB压力、运行时长老化测试架人工录入每班C测试结果采集频率不是越高越好。500ms 和 1s 对大多数离散制造够用了再快就是给网络和存储找麻烦。2.2 边缘层数据在进平台之前要做的三件事边缘层是智能工厂和智能制造.ppt 里最容易被画成“一个盒子”的部分但实际要做三件事协议转换、数据清洗、断网缓存。协议转换用软件网关或硬件网关都行。我一般用 Python 写一个轻量级采集服务跑在工控机上配合 pymodbus、python-snap7 这类库。下面是一个最小可用的 Modbus TCP 采集脚本from pymodbus.client import ModbusTcpClient import time import json # 连接 PLCIP 和端口按现场实际改 client ModbusTcpClient(192.168.1.10, port502) client.connect() # 读取保持寄存器地址 0 开始读 10 个 while True: try: rr client.read_holding_registers(address0, count10, slave1) if not rr.isError(): # 假设前两个寄存器是温度和压力缩放系数 0.1 data { temperature: rr.registers[0] * 0.1, pressure: rr.registers[1] * 0.1, ts: int(time.time() * 1000) } # 这里可以发到 MQTT 或写入本地 SQLite print(json.dumps(data)) else: print(Modbus error:, rr) except Exception as e: print(采集异常:, e) time.sleep(1)逻辑说明这个脚本每 1 秒读一次 PLC 的 10 个保持寄存器把前两个按 0.1 缩放后打包成 JSON。参数说明address0是起始寄存器地址不同品牌 PLC 的地址偏移不一样三菱和西门子差很多一定要对着通讯手册改slave1是从站号现场有多个从站时不能搞错count10是一次读多少个寄存器读多了会超时读少了要多次请求。数据清洗主要做三件事去重、去跳变、补缺失。去跳变就是设一个合理范围比如温度不可能在 1 秒内从 20 度跳到 200 度超过就丢弃。断网缓存用 SQLite 或本地文件都行网络恢复后按时间戳补传。2.3 平台层智能工厂数据管理方案的选型逻辑热搜词“智能工厂数据管理方案”指向的就是这一层。平台层选型没有标准答案但有一条铁律不要为了“大数据”而大数据。年产量 100 万件以下的工厂时序数据库用 InfluxDB 或 TDengine 单机版就够了上 Hadoop 就是给自己找运维麻烦。我一般按三个维度选数据量、查询模式、团队能力。数据量小于 10 万点/秒TDengine 或 InfluxDB 都能扛查询模式如果以“最近 1 小时某设备某参数”为主时序数据库最合适如果团队没有专职运维选托管服务或单机版别碰分布式。平台层还要做一件事统一命名规范。设备名、测点名、工单号必须有一套规则。我见过一个厂同一个温度点在三份 PPT 里叫三个名字最后数据对不上查了一周。常见做法是车间_产线_设备_测点比如A1_Line2_Inj3_Temp。2.4 应用层从看板到闭环控制的最后一公里应用层是老板在 PPT 里最关注的部分但也是最容易做成“大屏摆设”的部分。看板谁都会做难的是闭环。比如注塑机温度超限系统不只是报警还要自动降速或停机。这需要应用层和设备层之间有反向控制通道。反向控制要非常谨慎。我一般会设三道保险软件限值、PLC 硬限值、物理急停。软件限值在应用层判断PLC 硬限值在设备层兜底物理急停是最后一道。任何一道触发都必须记录原因和时间戳方便追溯。3. 用 OPC UA 和 MQTT 搭一条最小可跑的数据链路这一章给一个能直接抄作业的最小链路一台西门子 S7-1500 PLC 通过 OPC UA 服务端暴露数据一个 Python 客户端订阅再通过 MQTT 发到 EMQX最后写入 TDengine。整条链路在一台工控机上就能跑通。3.1 在 S7-1500 上启用 OPC UA 服务端在 TIA Portal 里打开 PLC 的设备组态找到“OPC UA”选项勾选“激活 OPC UA 服务器”。然后设置端口号默认 4840。接着在“服务器接口”里添加需要暴露的变量比如DB1.Temperature、DB1.Pressure。安全策略先选“无”等链路通了再上证书。注意S7-1500 的 OPC UA 服务端有连接数限制具体看 CPU 型号一般 5 到 10 个。如果多个客户端要连考虑用 OPC UA 聚合服务器。3.2 Python 客户端订阅 OPC UA 并转发 MQTTfrom opcua import Client import paho.mqtt.client as mqtt import json import time # OPC UA 服务端地址按现场改 opc_url opc.tcp://192.168.1.20:4840 client Client(opc_url) client.connect() # MQTT 代理地址 mqtt_client mqtt.Client() mqtt_client.connect(192.168.1.30, 1883, 60) # 获取节点节点 ID 在 TIA Portal 里能看到 temp_node client.get_node(ns3;s\DB1\.\Temperature\) pressure_node client.get_node(ns3;s\DB1\.\Pressure\) while True: try: temp temp_node.get_value() pressure pressure_node.get_value() payload { device: Inj3, temperature: temp, pressure: pressure, ts: int(time.time() * 1000) } # 发布到 MQTT主题按车间/产线/设备分层 mqtt_client.publish(factory/A1/Line2/Inj3/data, json.dumps(payload)) print(已发送:, payload) except Exception as e: print(OPC UA 读取失败:, e) time.sleep(1)逻辑说明这个脚本每 1 秒从 OPC UA 服务端读两个节点打包成 JSON 后发到 MQTT。参数说明ns3是命名空间索引不同项目的索引可能不同在 UaExpert 里能看到sDB1.Temperature是节点标识符字符串里的引号要转义MQTT 主题用/分层方便后面用通配符订阅。3.3 用 EMQX 规则引擎把数据写入 TDengineEMQX 自带规则引擎不用写代码就能把 MQTT 消息写入 TDengine。在 EMQX Dashboard 里新建一条规则SQL 写SELECT payload.device as device, payload.temperature as temperature, payload.pressure as pressure, payload.ts as ts FROM factory/A1/Line2/Inj3/data然后添加一个“数据转发到 TDengine”的动作填上 TDengine 的地址、数据库名和超级表名。TDengine 里先建好超级表CREATE STABLE factory_data ( ts TIMESTAMP, temperature FLOAT, pressure FLOAT ) TAGS ( device NCHAR(32) );这样每条 MQTT 消息会自动写入 TDengine按设备建子表。查询时用SELECT * FROM factory_data WHERE deviceInj3 AND ts now - 1h就能拿到最近一小时的数据。4. 智能工厂和智能制造.ppt 落地时最容易翻车的五个坑这一章按“现象 → 原因 → 解决”写都是我在现场踩过的。4.1 坑一OPC UA 连上了但读不到数据现象客户端显示连接成功但get_value()返回 None 或报 BadNodeIdUnknown。原因节点 ID 写错了。TIA Portal 里看到的节点 ID 和 OPC UA 客户端里的不完全一样尤其是字符串节点引号和命名空间索引容易搞混。解决用 UaExpert 先连上服务端在地址空间里找到目标节点直接复制 NodeId。不要手写。4.2 坑二MQTT 消息延迟忽高忽低现象大部分消息 1 秒内到偶尔有几条延迟十几秒。原因QoS 设成了 0网络抖动时消息丢了或重传或者 EMQX 的规则引擎处理不过来。解决关键数据用 QoS 1非关键用 QoS 0。EMQX 规则引擎如果压力大加一个缓冲队列或者把规则拆成多条并行。4.3 坑三TDengine 写入报错“table already exists”现象程序跑一段时间后开始报错说子表已存在。原因TDengine 自动建子表时如果设备名有特殊字符或大小写不一致会重复建表。解决统一设备名规范全用大写或全用小写不要混用。特殊字符用下划线代替。4.4 坑四看板数据和生产日报对不上现象看板显示产量 1000日报写 980。原因看板统计的是“设备动作次数”日报统计的是“质检合格数”两个口径不一样。解决在平台层定义清楚每个指标的口径写进数据字典。看板和日报用同一个数据源不要各算各的。4.5 坑五反向控制被 PLC 拒绝现象应用层下发停机指令PLC 不执行。原因PLC 的安全逻辑优先级高于外部指令或者通讯写权限没开。解决先确认 PLC 里有没有硬限值逻辑再检查 OPC UA 或 Modbus 的写权限。反向控制一定要走单独的通道不要和采集通道混用。5. 用历史数据反推设备节拍一个验证智能制造成效的小技巧最后一章给一个具体技巧怎么用采集到的历史数据反推设备真实节拍验证智能工厂和智能制造.ppt 里写的“效率提升 20%”到底有没有发生。方法很简单从 TDengine 里拉一台设备一周的“运行状态”数据找出每次从“运行”变“停止”再变“运行”的时间差去掉异常值后取中位数就是真实节拍。下面是一个查询示例SELECT ts, status, DIFF(ts) / 1000 AS duration_sec FROM ( SELECT ts, status, LAG(status) OVER (ORDER BY ts) AS prev_status FROM factory_data WHERE device Inj3 AND ts now - 7d ) WHERE status RUN AND prev_status STOP ORDER BY ts;逻辑说明先用窗口函数LAG拿到上一条状态再筛选出“上一条是 STOP、当前是 RUN”的记录DIFF(ts)算出两次之间的毫秒数除以 1000 变成秒。参数说明now - 7d是最近 7 天TDengine 支持这种写法device Inj3按设备过滤。拿到这些 duration_sec 后用 Python 算中位数和四分位距import numpy as np durations [12.3, 11.8, 12.1, 45.6, 12.0, 11.9, 12.2] # 从数据库查出来的 q1 np.percentile(durations, 25) q3 np.percentile(durations, 75) iqr q3 - q1 # 去掉超过 1.5 倍四分位距的异常值 clean [d for d in durations if q1 - 1.5 * iqr d q3 1.5 * iqr] median np.median(clean) print(f真实节拍中位数: {median:.2f} 秒)这个中位数就是设备在正常情况下的真实节拍。拿它和 PPT 里写的“目标节拍”对比就能知道差距在哪。如果中位数比目标慢很多先别怪设备查查是不是换模时间太长、来料不及时、或者操作员干预太多。我自己的习惯是每做一个智能工厂项目上线三个月后一定跑一次这个分析。PPT 里的数字可以美化但设备状态跳变的时间戳不会骗人。希望帮到你。本文还有配套的精品资源点击获取