产线设备综合效率OEE分析与瓶颈识别系统 —— 基于OOP的工业数据实战一条产线每天跑了 24 小时但真正在创造价值的只有 14 小时。剩下的 10 小时去哪了OEE 就是帮你把消失的时间找回来的工具。—— 哈尔滨工程大学《工业过程控制》课程核心思想一、实际应用场景描述在离散制造汽车装配、3C 电子、食品加工和批量流程工业中多条产线并行运行是常态。每条产线由若干设备组成设备状态在不断切换┌──────────────────────────────────────────────────────────────┐│ 车间 MES / SCADA 系统 ││ ││ 产线A (Line_A) 产线B (Line_B) 产线C (Line_C) ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐││ │ 08:00-08:30 │ │ 08:00-08:05 │ │ 08:00-09:00 │││ │ RUN (30min) │ │ DOWN (换模) │ │ RUN (60min) │││ │ 产出: 120件 │ │ 08:05-08:45 │ │ 产出: 95件 │││ │ 良品: 118件 │ │ RUN (40min) │ │ 良品: 90件 │││ │ │ │ 产出: 80件 │ │ │││ │ 09:00-09:10 │ │ 良品: 76件 │ │ 09:00-09:20 │││ │ DOWN (故障) │ │ │ │ DOWN (缺料) │││ └──────────────┘ └──────────────┘ └──────────────┘││ ││ 计划运行时间: 8h/天 × 3条 24h ││ 实际运行时间: ? ││ 合格品数量: ? ││ 理论产能: ? │└──────────────────────────────────────────────────────────────┘哈尔滨工程大学《工业过程控制》课程彭秀艳教授主讲国家级一流本科课程在第六章生产过程性能指标中系统讲解了 OEEOverall Equipment Effectiveness的三要素模型在第八章生产调度与优化中介绍了瓶颈识别方法。课程明确指出OEE 不是三个百分数的简单乘积而是对时间损失→性能损失→质量损失三层浪费的系统量化。世界级制造企业的 OEE 通常在 85% 以上而国内大多数工厂停留在 60% 以下——差距不在设备而在管理。二、引入痛点2.1 现场的真实困境场景 现场发生了什么 根因早会汇报 昨天产线利用率 95% 把开机时间等同于有效生产时间产能规划 加一条产线能翻倍 没算 OEE瓶颈根本不在数量而在效率质量追溯 不良率突然升高 没有按产线/班次拆解质量损失设备采购 这条线太慢了换新的 可能是性能损失小停机/空转而非设备极限绩效考核 班长说设备没问题 没有量化的 OEE 基线做参照2.2 核心矛盾MES 每 1 分钟都在记录设备状态运行/待机/故障/换模但三条产线哪条是真正的瓶颈、损失在哪里、该优先改善哪条从来没人系统算过。- 厂长看到的报表各线开机率都在 90% 以上 → 觉得一切正常- 实际算 OEE可用性 75% × 性能 80% × 质量 95% 57% → 暗藏巨大浪费- 瓶颈产线被平均掩盖A 线 OEE 72%C 线 OEE 41%——整体报 57% 看不出 C 线是短板2.3 我们要解决什么用一段 Python 程序读取多条产线的运行时长和停机记录 CSV 数据自动完成1. OEE 三要素计算 —— 可用性 × 性能 × 质量 OEE2. 六大损失拆解 —— 故障/换模/空转/减速/启动/不良3. 瓶颈识别 —— 基于 OEE 最低 约束理论TOC4. 帕累托分析 —— 停机原因排序找出关键的少数5. 产线对比 —— 雷达图直观展示各线强弱项6. 改善建议 —— 针对每条产线的短板给出具体方向7. 输出 Excel CSV 5 张图表三、核心逻辑讲解3.1 理论依据OEE 三层损失模型本工具算法基于哈工程《工业过程控制》第六章生产过程性能指标① OEE 公式OEE A \times P \times Q要素 英文 公式 含义可用性 Availability 运行时间 / 计划时间 设备在的时候在干活吗性能 Performance 实际产出 / 理论最大产出 干得快不快质量 Quality 良品数 / 总产出 干得好不好② 六大损失分类TPM 框架类别 归属 示例设备故障 可用性损失 电机烧毁、卡料停机换型/换模 可用性损失 产品切换、模具更换空转/小停机 性能损失 传感器误报、供料不畅速度降低 性能损失 设备老化、参数保守启动损失 性能质量损失 暖机废品、参数爬坡过程缺陷 质量损失 尺寸超差、表面划伤③ 瓶颈识别约束理论TOC系统的产出由最弱环节决定。提升非瓶颈产线的效率不会增加总产出——只有改善瓶颈才有意义。3.2 分析流程图原始产线状态日志timestamp, line_id, state, duration_min, planned_qty, actual_qty, defect_qty, reason│▼┌──────────────────┐│ ① 数据加载 编码探测││ 状态映射/缺失率检查 │└────────┬─────────┘▼┌──────────────────┐│ ② 按产线聚合 ★ ││ 计划时间/运行时间 ││ /停机分类/产出 │└────────┬─────────┘▼┌────┬────┬────────┐▼ ▼ ▼ ▼可用性 性能 质量 瓶颈计算 计算 计算 识别│ │ │ │▼ ▼ ▼ ▼A% P% Q% OEE最低│ │ │ │└────┴────┴────────┘▼┌──────────────────┐│ ④ 六大损失拆解 ││ 帕累托排序 │└────────┬─────────┘▼┌──────────────────┐│ ⑤ 综合评级 ││ A/B/C/D 改善建议│└────────┬─────────┘▼Excel CSV 5张图表3.3 为什么 OEE 比开机率更有说服力开机率算法 (误导版):开机率 开机时间 / 总时间Line_C: 开机 22h / 计划 24h 91.7% ← 很好啊!OEE 算法 (真相版):可用性 运行 18h / 计划 24h 75% (有 6h 停机)性能 实际产出 680 / 理论 850 80% (有 170 件的性能损失)质量 良品 646 / 总产出 680 95% (有 34 件报废)OEE 75% × 80% × 95% 57% ← 其实很差!损失的 43% 去哪了?· 6h 停机 (可用性损失) → 25%· 170 件少做 (性能损失) → 20% × 75% 15%· 34 件报废 (质量损失) → 5% × 60% 3%· 合计: ~43%→ 开机率 92% 掩盖了 43% 的效率黑洞这就是为什么世界级制造企业不用开机率考核——OEE 才是真正的效率镜子。四、代码模块化讲解面向对象设计4.1 类结构总览本项目严格采用面向对象编程OOP共设计 6 个核心类 4 个不可变数据类类名 职责 设计模式AppConfig聚合根 聚合 5 个子配置 聚合根模式PlantConfig /OEESettings /AnalysisConfig 各域参数 内聚方法 值对象DataConfig /OutputConfig /LoggingConfig 数据/输出/日志参数 值对象OEEDataLoader CSV 加载、编码探测、状态映射 封装OEEAnalyzer ★ 核心分析引擎 模板方法ReportGenerator 多格式报表输出 模板方法LineOEE /LossBreakdown /BottleneckAnalysis /ImprovementPlan 不可变结果对象 值对象模式4.2 配置层dataclass 聚合根# config_loader.py 核心片段dataclassclass OEESettings:OEE 评级参数 —— 值对象 内聚判定world_class: float 0.85 # ≥85% 世界级good: float 0.70 # ≥70% 良好fair: float 0.55 # ≥55% 一般poor: float 0.0 # 55% 较差def evaluate(self, oee: float) - str:OEE 评级 —— 逻辑内聚在此if oee self.world_class:return A(世界级)elif oee self.good:return B(良好)elif oee self.fair:return C(一般)else:return D(较差)dataclassclass AppConfig:聚合根 —— 持有所有子配置plant: PlantConfig field(default_factoryPlantConfig)oee: OEESettings field(default_factoryOEESettings)analysis: AnalysisConfig field(default_factoryAnalysisConfig)data: DataConfig field(default_factoryDataConfig)output: OutputConfig field(default_factoryOutputConfig)classmethoddef from_yaml(cls, path) - AppConfig:工厂方法: YAML → AppConfigif not os.path.exists(path):return cls()with open(path, r, encodingutf-8) as f:raw yaml.safe_load(f) or {}return cls(plantPlantConfig(**raw.get(plant, {})),oeeOEESettings(**raw.get(oee, {})),analysisAnalysisConfig(**raw.get(analysis, {})),dataDataConfig(**raw.get(data, {})),outputOutputConfig(**raw.get(output, {})),)亮点OEESettings.evaluate() 把评级逻辑内聚在此——换行业标准如半导体 vs 食品只改 YAML 一行。4.3 数据加载层编码自动探测 状态映射# data_loader.py 核心片段class OEEDataLoader:数据加载器 (封装)STATE_MAP {RUN: running,DOWN: downtime,IDLE: idle,SETUP: setup,MAINT: maintenance,}staticmethoddef detect_encoding(filepath: str) - str:依次尝试常见编码candidates [utf-8-sig, utf-8, gbk, gb2312, latin1]for enc in candidates:try:with open(filepath, r, encodingenc) as f:f.read(2048)return encexcept (UnicodeDecodeError, OSError):continuereturn utf-8-sigdef load(self, filepath: str) - pd.DataFrame:加载并标准化enc self.detect_encoding(filepath)df pd.read_csv(filepath, encodingenc, parse_dates[timestamp])# 状态标准化if state in df.columns:df[state_std] df[state].map(self.STATE_MAP).fillna(unknown)return df4.4 核心算法①OEE 三要素计算★ 核心# core_analyzer.py 核心片段def _compute_oee_by_line(self, df) - List[LineOEE]:OEE 三要素计算对应课程 §6.x: 设备综合效率(OEE)的计算与分析A 运行时间 / 计划时间P 实际产出 / 理论最大产出 ( 运行时间 × 设计速率)Q 良品数 / 总产出OEE A × P × Qresults []for line_id, grp in df.groupby(line_id):# 计划时间plan_hours self.cfg.analysis.shift_hours * \self.cfg.analysis.shifts_per_day * \self.cfg.analysis.days_analyzed# 按状态分类汇总states grp.set_index(timestamp)[state_std]running grp[grp[state_std] running]downtime grp[grp[state_std] downtime]# ★ 可用性run_hours running[duration_min].sum() / 60.0availability run_hours / plan_hours if plan_hours 0 else 0# ★ 性能actual_output running[actual_qty].sum()design_rate self.cfg.analysis.design_cycles_per_hour.get(line_id, 100)theoretical_max run_hours * design_rateperformance actual_output / theoretical_max if theoretical_max 0 else 0# ★ 质量total_output running[actual_qty].sum()defects running[defect_qty].sum()quality (total_output - defects) / total_output if total_output 0 else 0# OEEoee availability * performance * qualityresults.append(LineOEE(line_idline_id,availabilityround(availability, 4),performanceround(performance, 4),qualityround(quality, 4),oeeround(oee, 4),planned_hoursround(plan_hours, 2),running_hoursround(run_hours, 2),downtime_hoursround(downtime[duration_min].sum() / 60.0, 2),total_outputint(total_output),defectsint(defects),oee_gradeself.cfg.oee.evaluate(oee),))return results亮点- 三要素公式三行核心代码完成——清晰对应教科书定义- 理论最大产出用run_hours × design_rate 而非简单的计划时间 × 设计速率——排除了停机时间的干扰4.5 核心算法②六大损失拆解 帕累托def _breakdown_losses(self, df) - Dict[str, LossBreakdown]:六大损失拆解对应课程 §6.x: TPM 六大损失分类results {}for line_id, grp in df.groupby(line_id):downtime grp[grp[state_std] downtime]running grp[grp[state_std] running]# 停机分类breakdown downtime.groupby(reason)[duration_min].sum().sort_values(ascendingFalse)top_reasons [(k, round(v/60.0, 2)) for k, v in breakdown.head(5).items()]# 质量损失total_defects running[defect_qty].sum()total_output running[actual_qty].sum()defect_rate total_defects / total_output if total_output 0 else 0results[line_id] LossBreakdown(top_downtime_reasonstuple(top_reasons),total_downtime_hoursround(downtime[duration_min].sum() / 60.0, 2),defect_rateround(defect_rate, 4),small_stop_countint((downtime[duration_min] 10).sum()),long_stop_countint((downtime[duration_min] 30).sum()),)return results4.6 核心算法③瓶颈识别def _identify_bottleneck(self) - BottleneckAnalysis:瓶颈识别 —— 基于约束理论(TOC)对应课程 §8.x: 生产调度与瓶颈管理瓶颈 OEE 最低的产线 (或 产出率最低的产线)if not self._line_oees:return BottleneckAnalysis(bottleneck_lineN/A, bottleneck_oee0, gap_pct0)sorted_lines sorted(self._line_oees, keylambda x: x.oee)bottleneck sorted_lines[0]best sorted_lines[-1]gap (best.oee - bottleneck.oee) / best.oee * 100 if best.oee 0 else 0# 瓶颈约束类型if bottleneck.availability 0.7:constraint 可用性瓶颈 (停机时间过长)elif bottleneck.performance 0.8:constraint 性能瓶颈 (运行速度不足/小停机频繁)elif bottleneck.quality 0.95:constraint 质量瓶颈 (不良率过高)else:constraint 综合瓶颈return BottleneckAnalysis(bottleneck_linebottleneck.line_id,bottleneck_oeebottleneck.oee,gap_pctround(gap, 2),constraint_typeconstraint,all_lines_ranked[(l.line_id, l.oee) for l in sorted_lines],)4.7 实际运行输出$ python main.py --gen-data产线OEE分析与瓶颈识别系统 v1.0.0基于哈尔滨工程大学《工业过程控制》课程理论(OEE三要素 / 六大损失 / 瓶颈识别) 配置摘要:工厂: 某汽车零部件车间产线条数: 3计划时间: 3班次 × 8h × 5天 120h世界级OEE基准: 85% 数据质量评估:· total_records: 156· lines: [Line_A, Line_B, Line_C]· states: [running, downtime, setup] 开始 OEE 分析...✅ 分析完成! 共 3 条产线 分析摘要─────────────────────────────────────【各线 OEE】Line_A: OEE71.8% (A83.3% P91.7% Q94.0%) → B(良好)Line_B: OEE59.1% (A75.0% P83.3% Q94.5%) → C(一般)Line_C: OEE47.3% (A66.7% P75.0% Q94.5%) → D(较差)★ 瓶颈产线: Line_C (OEE47.3%, 落后最佳 34.1%)约束类型: 可用性瓶颈 (停机时间过长)【Line_C 六大损失 TOP3】1. 故障停机: 18.0h2. 换模: 8.0h3. 缺料: 6.0h【改善建议】Line_A: 质量略低, 建议加强首件检验Line_B: 可用性偏低, 建议减少换模时间 (SMED)Line_C: ★ 瓶颈! 可用性严重不足, 建议: 1) 设备预防性维护 2) 供应链改善 3) SMED★ 综合评级: C(一般) 评分: 59.4/100 关键发现:1. Line_C 是明确瓶颈 (OEE 47.3%), 可用性仅 66.7%2. 故障停机是 Line_C 最大损失源 (18h)3. 改善瓶颈可提升整体产能约 34%✅ 分析完成 总耗时: 1.8s关键成果- Line_C OEE 仅 47.3% → 瓶颈一目了然- 约束类型 可用性瓶颈 → 改善方向明确不是买新设备而是减少停机- TOP3 停机原因故障 18h 换模 8h 缺料 6h → 帕累托清晰- 改善瓶颈可释放 34% 产能潜力 → 量化的 ROI五、README 与使用说明5.1 项目结构oee_analyzer/├── config.yaml # 配置文件├── config_loader.py # 配置加载├── generate_sample_data.py # 模拟数据生成3线×5天×156条记录├── data_loader.py # CSV 加载 状态映射├── core_analyzer.py # ★ 核心分析引擎├── report_generator.py # 报表生成├── main.py # 主入口├── requirements.txt # numpy/pandas/matplotlib/pyyaml/openpyxl├── README.md # 本说明├── data/ # 输入 CSV└── output/ # 输出报表├── oee_report.xlsx # 4 Sheets├── oee_by_line.csv├── loss_breakdown.csv├── bottleneck_analysis.csv└── charts/├── 01_oee_waterfall.png├── 02_downtime_pareto.png├── 03_line_radar.png├── 04_bottleneck_gap.png└── 05_dashboard.png5.2 三步上手pip install -r requirements.txtpython generate_sample_data.pypython main.py5.3 使用你自己的数据CSV 格式示例timestamp,line_id,state,duration_min,planned_qty,actual_qty,defect_qty,reason2025-06-01 08:00:00,Line_A,RUN,30,130,120,2,2025-06-01 08:30:00,Line_A,DOWN,10,,,,故障停机2025-06-01 08:00:00,Line_B,SETUP,15,,,,换模放入data/production_log.csv运行python main.py --data data/production_log.csv。5.4 配置说明plant:name: 某汽车零部件车间total_lines: 3oee:world_class: 0.85good: 0.70fair: 0.55analysis:shifts_per_day: 3shift_hours: 8.0days_analyzed: 5design_cycles_per_hour:Line_A: 240Line_B: 200Line_C: 1805.5 命令行参数python main.py --config my.yamlpython main.py --data path.csvpython main.py --gen-datapython main.py --no-charts5.6 输出文件文件 内容oee_report.xlsx 总览/按线OEE/损失拆解/瓶颈分析oee_by_line.csv 各线三要素评级loss_breakdown.csv 六大损失明细bottleneck_analysis.csv 瓶颈识别结果charts/01_oee_waterfall.png ★ OEE 瀑布图计划→可用→性能→质量charts/02_downtime_pareto.png 停机原因帕累托图charts/03_line_radar.png 各线三要素雷达图charts/04_bottleneck_gap.png 瓶颈差距条形图charts/05_dashboard.png 综合仪表盘六、核心知识点卡片 卡片1OEE 三层公式课程§6.xOEE A \times P \times Q要素 分子 分母 典型目标A 可用性 运行时间 计划时间 90%P 性能 实际产出 理论最大产出 95%Q 质量 良品数 总产出 99% 参考《工业过程控制》§6.x 设备综合效率 核心洞察OEE 是乘法关系——任何一项低都会放大损失。A80%、P80%、Q80% → OEE51.2%不是 80%。 卡片2六大损失与 OEE 的映射损失 归属 OEE 影响故障停机 可用性 A↓换模/换型 可用性 A↓空转/小停 性能 P↓速度降低 性能 P↓启动损失 性能质量 P↓ Q↓过程缺陷 质量 Q↓ 改善的优先级可用性 性能 质量——因为可用性损失最容易量化且改善 ROI 最高。 卡片3约束理论TOC在产线中的应用瓶颈 系统中产出率最低的环节改善原则:1. 识别瓶颈2. 挖尽瓶颈 (充分利用)3. 迁就瓶颈 (非瓶颈服从瓶颈节奏)4. 突破瓶颈 (消除约束)5. 回头找下一个瓶颈→ 持续改善的循环 参考《工业过程控制》§8.x 生产调度与优化 卡片4帕累托法则在停机分析中的应用帕累托图: 停机原因按时间排序x轴: 原因 (故障/换模/缺料/...)y轴: 累计时间通常:前 2~3 个原因占了 80% 的停机时间→ 关键的少数改善资源应该集中在这 20% 的原因上 卡片5OEE 评级基准等级 OEE 含义 行动A(世界级) ≥ 85% 精益标杆 维持分享经验B(良好) 70~85% 有改善空间 针对性优化C(一般) 55~70% 问题较多 系统性改善D(较差) 55% 严重浪费 全面诊断 注意不同行业基准不同。半导体 OEE 60% 就算不错汽车装配 85% 才算世界级。 卡片6OOP设计模式速查模式 本项目应用 解决的问题聚合根AppConfig 包含 5 个子配置 外部只需持有一个对象模板方法analyze() 定义 5 步流程 主流程固定步骤可替换值对象LineOEE 不可变 安全传递、可序列化策略模式OEESettings.evaluate() 换评级标准只改 YAML工厂方法AppConfig.from_yaml() 封装创建逻辑七、总结7.1 本工具做了什么步骤 内容 对应课程① 配置加载 YAML → dataclass 聚合根 —② 数据加载 编码探测 状态映射 —③ OEE 计算 A × P × Q 三要素 §6.x OEE④ 损失拆解 六大损失 帕累托 §6.x TPM⑤ 瓶颈识别 约束理论(TOC) §8.x 调度优化⑥ 综合评级 加权平均 短板识别 §6.x 综合评估⑦ 报表输出 Excel CSV 5 图 —7.2 OOP 设计回顾设计决策 好处AppConfig 聚合根 一个对象管全部OEESettings.evaluate() 内聚评级 换标准只改 YAMLLineOEE 不可变 线程安全模板方法analyze() 流程固定步骤可替换7.3 适用与不适用✅ 适用 ❌ 不适用多产线并行制造车间 连续流程工业无离散换模概念有状态日志/MES 数据的工厂 纯手工记录无时间戳月度/周度 OEE 考核 实时秒级监控需不同架构瓶颈产线识别 单设备微观诊断7.4 下一步可以做什么- 接 MES API实时拉取状态数据变成在线 OEE 看板- Andon 集成OEE 低于阈值时自动触发安灯呼叫- SMED 分析专门拆解换模时间量化内外作业分离潜力- 预测性维护结合 OEE 下降趋势预测设备何时需要保养- 多工厂对标不同车间/工厂的 OEE 横向对比- 数字孪生用 OEE 数据驱动产能仿真验证排产方案免责声明本工具仅用于历史数据的离线分析与改善辅助决策不可替代 MES 系统的实时调度功能。OEE 基准值因行业差异较大默认参数适用于离散制造业流程工业需调整。模拟数据仅供演示算法流程实际应用需使用真实 MES/SCADA 数据。利用AI解决实际问题如果你觉得这个工具好用欢迎关注长安牧笛