简介这份PDF资料面向生产制造领域的设备管理、工艺工程与精益改善人员系统讲解设备稼动率OEE的计算逻辑与落地方法帮助读者掌握从可用率、性能率到质量率的完整测算思路。资源共1个PDF文件压缩包约56KB内容紧凑适合作为现场培训或自学速查手册。资料围绕OEE可用率×性能率×质量率展开逐一给出三项子指标的计算公式并结合实际产线案例演示以实际生产时间400分钟、理论速度25件/分钟等数据算出可用率0.86、性能率0.8、质量率0.98最终OEE为96.87%让抽象公式变得可验证。同时引入TPM总体生产维护理念说明设备维护保养对稼动率的影响并给出OEE计算的三步流程与结果分析建议。目前已有347人学习适合需要快速建立设备效率评估框架、优化产线效能的从业者参考。1. 设备稼动率如何计算从车间日报到 OEE 的真实距离很多工厂的日报表上设备稼动率一栏常年写着 92%、95%但老板到现场一看机器停着人也不在。问题不在统计员偷懒而在于「稼动率」这三个字被不同岗位理解成了不同的东西。有人拿开机时长除以日历时长有人拿实际产出除以理论产能还有人把计划停机也算进分子里。设备稼动率如何计算本质上不是一道算术题而是一次对「什么算停机、什么算有效时间」的定义谈判。这篇笔记面向的是需要自己动手搭统计口径的设备工程师、生产主管和刚接手 OEE 报表的工艺人员。我会把稼动率的定义边界、数据采集方式、计算公式和常见翻车点拆开讲让你能照着在自己的产线上跑通一套可复现的计算逻辑而不是继续抄一份来路不明的 Excel 模板。2. 稼动率、可动率、OEE先把三个口径掰开2.1 稼动率到底在算哪段时间稼动率最容易被混淆的地方是「时间」这个分母怎么取。常见做法有三种日历时间、负荷时间、计划运行时间。日历时间是 24 小时乘以天数适合连续生产流程行业负荷时间是日历时间减去计划停机比如交接班、计划保养、无排产时段计划运行时间则再减去非计划停机。你选哪个分母算出来的数字能差出 20 个百分点。我一般建议先明确一个基准稼动率 实际运行时间 / 计划运行时间 × 100%。这里的计划运行时间等于负荷时间减去计划内停机。计划内停机包括班前会、计划保养、换型调机、无订单待机。非计划停机包括故障、缺料、缺人、质量异常停线。这个口径的好处是它把「管理可控」和「管理不可控」分开了后续做改善时能直接定位到责任部门。如果你所在工厂的日报只写「开机 8 小时」那这个 8 小时里可能包含了换型 40 分钟、等料 30 分钟、故障 20 分钟。直接拿 8 除以 8 得到 100%没有任何意义。所以第一步不是套公式而是把停机原因分类表先定下来让班组长在交接班时能勾选。2.2 可动率与稼动率的区别在哪可动率衡量的是设备「想开就能开」的能力分母通常是负荷时间分子是设备可运行时间不扣除计划停机。它反映的是设备维护水平。稼动率衡量的是设备「实际开了多久」扣除计划停机后看实际运行占比反映的是生产组织水平。两者混用会导致一个后果设备明明没故障但因为没订单没开可动率很高稼动率很低报表上却写成同一个数。一个简单的判断方法如果停机是因为「没排产」那影响的是稼动率不影响可动率如果停机是因为「坏了」那两者都受影响。做设备管理的看可动率做生产计划的看稼动率做整体效率的看 OEE。2.3 OEE 与稼动率的乘法关系OEE 时间稼动率 × 性能稼动率 × 良品率。这里的「时间稼动率」就是前面说的稼动率。性能稼动率 实际产出 / 理论产出反映的是设备速度有没有跑满。良品率 良品数 / 总产出数。很多工厂只算时间稼动率然后把它当成 OEE 汇报这是典型的偷换概念。一台设备可能 95% 的时间在运行但速度只有额定值的 60%良品率 90%实际 OEE 只有 51%。所以当你看到「稼动率 95%」时先问一句这是时间稼动率还是 OEE如果是时间稼动率那另外两个乘数去哪了提示在日报表上建议把三个乘数分列不要只写一个合计数。合计数好看但找不到改善点。3. 用 Python 从设备日志算出真实稼动率3.1 数据准备需要哪几列字段假设你从 PLC 或 MES 导出了一份设备状态日志常见字段包括设备编号、状态开始时间、状态结束时间、状态代码。状态代码一般有RUN运行、IDLE待机、FAULT故障、SETUP换型、MAINT保养、OFF关机。你需要先把状态代码映射到「计划停机」「非计划停机」「运行」三类。这个映射表不要写死在代码里单独放一个字典方便后续调整。# 状态分类映射根据工厂实际口径调整 STATUS_MAP { RUN: run, # 运行 IDLE: unplanned, # 待机通常算非计划停机 FAULT: unplanned, # 故障 SETUP: planned, # 换型计划内 MAINT: planned, # 保养计划内 OFF: planned, # 关机计划内 }逻辑说明这个映射决定了最终数字的走向。比如「IDLE」到底算计划还是非计划不同工厂有不同定义。如果待机是因为计划排产不足应该算计划停机如果是因为上工序断料算非计划。我一般建议先按「原因是否可提前预知」来分能提前排进计划的算 planned突发算 unplanned。参数说明STATUS_MAP 的 key 必须和日志里的状态代码完全一致大小写敏感。如果日志里是中文「运行」就改成中文 key。3.2 按时间段聚合计算稼动率有了分类之后核心逻辑是把每条状态记录的时间跨度算出来按分类累加最后用 run 时间除以run unplanned时间。注意planned 时间不进分母因为它已经被排除在计划运行时间之外。import pandas as pd def calc_utilization(log_df, status_map): # 确保时间列是 datetime 类型 log_df[start] pd.to_datetime(log_df[start]) log_df[end] pd.to_datetime(log_df[end]) # 计算每条记录的持续秒数 log_df[duration] (log_df[end] - log_df[start]).dt.total_seconds() # 映射分类 log_df[category] log_df[status].map(status_map) # 按分类汇总时长 summary log_df.groupby(category)[duration].sum() run_sec summary.get(run, 0) unplanned_sec summary.get(unplanned, 0) planned_sec summary.get(planned, 0) # 计划运行时间 运行 非计划停机 planned_run_sec run_sec unplanned_sec if planned_run_sec 0: return 0.0, summary utilization run_sec / planned_run_sec * 100 return round(utilization, 2), summary逻辑说明分母用 run unplanned而不是 run unplanned planned是因为 planned 时间已经被视为「不安排生产」的时间不应该拉低稼动率。如果你所在工厂把换型也算作损失那就把 SETUP 从 planned 挪到 unplanned数字会立刻下降但更真实。参数说明log_df 至少要有 start、end、status 三列。duration 单位是秒如果日志时间跨度大注意时区问题建议统一转成 UTC 再计算。3.3 按班次和设备维度拆分单台设备一天一个总数不够用你需要按班次看才能发现「白班高、夜班低」这种玄学现象。做法是在日志里增加班次字段或者用开始时间判断落在哪个班次区间。def assign_shift(ts): hour ts.hour if 8 hour 20: return day else: return night log_df[shift] log_df[start].apply(assign_shift) # 按设备和班次分组计算 results [] for (eq, shift), group in log_df.groupby([equipment_id, shift]): util, _ calc_utilization(group, STATUS_MAP) results.append({equipment_id: eq, shift: shift, utilization: util}) result_df pd.DataFrame(results)逻辑说明按班次拆分后你会发现同一台设备白班稼动率 88%、夜班 72%差距往往来自夜班缺人、缺料或故障响应慢。这个信息比一个日平均数有用得多。参数说明班次边界按工厂实际调整有的工厂三班倒需要改成三段。equipment_id 是设备唯一编号不要用设备名称名称可能重复。4. 稼动率统计的避坑与排查清单4.1 现象稼动率超过 100%原因分母取错了。常见情况是把计划运行时间算成了「实际运行时间减去停机时间」或者把重叠的状态记录重复累加。还有一种可能是日志里同一时间段有两条记录一条 RUN 一条 FAULT时间重叠导致 run 时间被重复计算。解决先检查日志有没有时间重叠。用排序后比较上一条的 end 和下一条的 start如果 start 小于上一条 end说明有重叠。处理方式是取并集或者按优先级保留一条。另外确认分母公式计划运行时间必须大于等于运行时间不可能出现分子大于分母。4.2 现象换型时间被算进稼动率分子原因状态映射把 SETUP 归到了 run 类。换型时设备可能仍在运转但不出合格品如果日志只记录「运行/停止」换型会被误判为运行。解决在 PLC 或 MES 里增加换型状态信号或者在映射表里把 SETUP 单独归类。如果无法增加信号至少要在日报里手工扣除换型时间。我见过最离谱的案例是一台压铸机换模 2 小时日志显示 RUN稼动率算出来 96%实际有效产出时间只有 70%。4.3 现象短停机被忽略稼动率虚高原因日志采集频率太低比如 5 分钟采一次30 秒的卡料停机根本记不上。或者班组长嫌麻烦只记录 10 分钟以上的停机。解决把采集频率降到 10 秒级至少对关键设备。如果硬件不支持用电流互感器加边缘网关做辅助判断电流低于阈值持续 30 秒即视为停机。短停机累积起来很可怕一台设备一天 20 次 1 分钟停机就是 20 分钟占一个班的 4%。4.4 现象不同车间稼动率无法横向对比原因各车间对「计划停机」的定义不同。A 车间把保养算计划B 车间把保养算非计划两个数字放一起没有可比性。解决由工艺或 IE 部门出一份全厂统一的停机分类标准明确每一类停机的归属。标准发布后在 MES 里做成下拉选项不允许手工输入。对比之前先对齐口径否则就是自欺欺人。4.5 现象稼动率改善后 OEE 没变化原因只提升了时间稼动率性能稼动率或良品率拖了后腿。比如设备运行时间长了但速度没提上来或者运行中产出的废品多了。解决把三个乘数一起看。如果时间稼动率从 80% 提到 90%但性能稼动率从 85% 降到 75%OEE 可能原地踏步。改善动作要针对瓶颈乘数而不是只盯着开机时长。注意稼动率是一个管理指标不是财务指标。不要用它直接算成本除非你同时确认了性能稼动率和良品率。5. 从日报到实时看板稼动率计算的进阶用法5.1 用滑动窗口做实时稼动率日报的滞后性太强等看到数字时停机已经发生了。进阶做法是用滑动窗口算最近 2 小时的稼动率每 5 分钟刷新一次。实现方式是在边缘网关或服务器上维护一个时间窗口只保留窗口内的状态记录重新计算。from collections import deque from datetime import datetime, timedelta class SlidingUtilization: def __init__(self, window_minutes120): self.window timedelta(minuteswindow_minutes) self.records deque() def add_record(self, start, end, category): self.records.append((start, end, category)) self._evict(datetime.now()) def _evict(self, now): cutoff now - self.window while self.records and self.records[0][1] cutoff: self.records.popleft() def current(self): run unplanned 0 for start, end, cat in self.records: dur (end - start).total_seconds() if cat run: run dur elif cat unplanned: unplanned dur total run unplanned return round(run / total * 100, 2) if total else 0.0逻辑说明滑动窗口的好处是能反映「当下」的设备状态而不是昨天的事。窗口长度一般取 1 到 4 小时太短会抖动太长反应慢。evict 方法负责清理过期记录避免内存无限增长。参数说明window_minutes 根据设备节拍调整高速冲压可以取 60 分钟注塑机可以取 240 分钟。add_record 的 category 必须和前面 STATUS_MAP 的输出一致。5.2 用稼动率数据反推瓶颈工序单台设备的稼动率只能看自己把整条线的设备稼动率按工序排开就能找到瓶颈。做法是拉取同一时间段内各设备的稼动率画成柱状图最低的那台通常就是瓶颈。但要注意瓶颈不一定是稼动率最低的还要看它的下游是否在等它。我一般会做一个简单的矩阵横轴是设备纵轴是稼动率再叠加一个「下游待机时长」字段。如果某台设备稼动率 70%同时下游待机 30%那它就是瓶颈。如果它稼动率 70%但下游稼动率 95%说明它不是瓶颈只是排产不满。5.3 稼动率报表的验证方法算出来的数字对不对不能只看公式。我习惯用三种方式交叉验证第一拿一个班次的原始日志手工算一遍和脚本结果对比第二和班组长确认当天有没有明显异常比如「昨天下午停了 2 小时」第三看稼动率曲线和设备电流曲线是否吻合电流持续为零的时间段应该对应停机。如果三种方式都对不上优先怀疑日志时间戳的时区或格式问题。我踩过一次坑PLC 导出的时间没有时区脚本按本地时间解析结果夜班数据整体偏移了 8 小时稼动率算出来完全对不上。后来统一在导出时加 UTC 标记才解决。5.4 一个具体技巧把停机原因做成帕累托图稼动率告诉你「停了多少」但不告诉你「为什么停」。进阶用法是把非计划停机按原因分类做帕累托图。前 3 个原因通常占 70% 以上集中解决这几个稼动率提升最快。# 假设 log_df 里有 reason 列记录停机原因 unplanned_df log_df[log_df[category] unplanned] reason_summary unplanned_df.groupby(reason)[duration].sum().sort_values(ascendingFalse) reason_summary[cum_pct] reason_summary[duration].cumsum() / reason_summary[duration].sum() * 100 print(reason_summary.head(10))逻辑说明按停机时长降序排列累计百分比到 80% 左右的原因就是重点改善对象。不要试图一次解决所有原因先打前三个。参数说明reason 列需要班组长在交接班时填写建议在 MES 里做成必填项否则数据质量无法保证。如果实在填不准至少区分「设备故障」「缺料」「缺人」「质量异常」四大类。我做了这么多年设备统计最大的教训是稼动率不是算出来的是管出来的。公式再漂亮如果停机原因没人填、状态信号没人校准算出来的数字只是安慰剂。先花两周把数据采集和分类标准跑顺再谈改善。希望帮到你。本文还有配套的精品资源点击获取
