半导体百科：FAB设备综合效率 OEE 自动化计算与可视化看板

一、问题背景：手工算OEE，一个月对不出一本明白账

先说一个真实踩坑。去年Q3，我负责一条12英寸逻辑线后段的设备效率月报。当时OEE还是工艺工程师周五下午手工算：从MES导出每台机台的停机记录Excel，再对照产量表人工填数，用公式 =（计划时间-停机）/计划时间 × 标准节拍×产量/运行时间 × 良品数/总产量 凑出一个数，平均一台设备要折腾20分钟，全段38台设备光算数就要13个工时。

更要命的是误差。月末复盘发现三件离谱的事：第一，刻蚀区EQP-B3的OEE被算成71%，但同型号、同工艺的B2只有58%，差异大到不像同一类设备；第二，良率工程师报的"良品数"和制造部报的"入站数"对不上，质量率被高估了4.2个百分点；第三，9月第三周有两天MES停机数据漏传，那两天的OEE被当成100%填进去了。一个季度下来，累计偏差最高的一台设备差了9个百分点，足以让管理层对整条线的效率判断完全失真。

这件事让我下定决心做自动化。核心痛点其实就三个：其一，人工统计误差大，同一份数据两个人算能差5%以上，且无法回溯计算过程；其二，实时性差，月报往往滞后两周，等发现某台设备性能率掉下来，良率已经跟着掉了一整批；其三，跨设备对比困难，因为没有统一口径和标准化可视化，B2和B3到底谁更差，谁也说不清。OEE作为FAB最该"一眼看清"的指标，却恰恰是最看不清的，这就是本文要解决的真问题。

算笔账就知道这9%的偏差有多贵：那台被高估的刻蚀机，按每月1600片产能、单片等效产值3000元估算，OEE每虚高1个百分点，相当于掩盖了约4.8万元的真实产出损失；9个百分点就是43万元/月，一年下来够买半台二手量测设备。更隐蔽的是决策误导——管理层曾因"手工OEE好看"推迟了它的预防性维护，结果次月真故障停机11小时，反而亏得更多。

二、技术原理：OEE三大因子的数据来源与计算逻辑

OEE的世界级基准是85%（可用率90% × 性能率95% × 质量率99.9% ≈ 85%）。它的本质是"计划生产时间内，真正产出的合格品，占理论最大产能的比例"。拆成三个相互独立又相乘的因子，正是为了定位损失到底出在哪。

1）可用率（Availability）= 运行时间 / 计划生产时间。计划生产时间通常取日历时间扣掉计划保养（PM）与无订单待机；运行时间 = 计划生产时间 − 所有非计划停机。数据来源是MES停机记录（downtime event），每条记录带设备号、起止时间、停机代码（如 breakdown / changeover / waiting）。选型上必须用停机事件的"开始-结束"时间戳差值求和，而不是设备状态日志的抽样点——抽样会漏掉短时停机，而半导体短停（<5分钟）恰恰是性能损失的大头。

2）性能率（Performance）=（理想周期时间 × 总产量）/ 运行时间。理想周期时间来自设备规格书或工艺标准（如光刻机每片理论45秒）。数据来源是产量计数（MES或设备自带counter）。性能率捕捉的是"设备在跑但没跑满速"的损失——减速、微停顿、空转。对比直接除法，用"理想周期×产量"更稳定，因为它不依赖单批节拍，能跨产品混线计算。

3）质量率（Quality）= 良品数 / 总产量。数据来源是测试良率或缺陷复检结果（CP/FT或AOI pass数）。它衡量"跑出来的里面有多少是废的"。OEE最终 = 可用率 × 性能率 × 质量率，三者是乘法关系，任一短板都会被放大——比如可用率只有80%，哪怕性能和质量都接近100%，OEE也封顶在80%。

从损失视角看，OEE把设备效率损失归为六大类：故障停机（breakdown）、换型调整（setup）、空转与短停（idling & minor stop）、减速（reduced speed）、良率损失（defects）、启动损失（startup）。前两类吃掉可用率，空停与减速吃掉性能率，后两类吃掉质量率。定位改进时，先看三因子谁最低，再映射到对应损失类型，就能避免"胡子眉毛一把抓"。

方案对比：有人用Excel Power Query拼，优点是门槛低，但公式散落、停机拆分靠人工、无法做时间序列；有人接BI工具（Tableau/PowerBI），可视化强但取数逻辑仍依赖IT排期，迭代慢；我选Python + pandas，是因为它把"取数→清洗→计算→出图"串成一条可复跑的流水线，谁改了代码、哪条数据异常都留痕，而且能直接落库成看板数据源。局限性也要说清：OEE只反映"效率"，不含成本与良率根因，且标准周期时间若定得虚高，性能率会被人为压低——所以理想周期必须定期校准，这是自动化也救不了的"输入质量问题"。

顺便用一个手算例子把口径钉死。某光刻机当天计划生产时间1440分钟，非计划停机累计120分钟，则运行时间1320分钟；设备标准周期45秒/片，当天产出1500片，其中良品1460片。套公式：可用率 = (1440-120)/1440 = 91.7%；性能率 = 45*1500 / (1320*60) = 67500/79200 = 85.2%；质量率 = 1460/1500 = 97.3%；OEE = 0.917*0.852*0.973 = 76.0%。注意性能率那一步：如果直接拿"实际节拍=运行时间/产量=52.8秒"去和45秒比，得到的是88.6%，与85.2%的差别恰恰来自除数口径——自动化脚本统一用"理想周期*产量/运行时间"，正是为了杜绝这种人算歧义。

三、实战案例：某12英寸线38台设备，30天OEE自动化落地

以我实际部署的产线为例。数据源有两张MES导出表：mes_downtime.csv（字段 eqp_id, date, start, end, reason_code，约每天6000条停机事件）和 mes_production.csv（字段 eqp_id, date, total_count, good_count, ideal_cycle_s，每天38行）。脚本每日凌晨自动跑，输出每台设备每日的OEE三因子及综合值。

拿三台代表性设备看结果。EQP-A（光刻）：30天平均可用率88%、性能率80%、质量率97%，OEE = 0.68；EQP-B（刻蚀）：可用率81%、性能率73%、质量率95%，OEE = 0.56；EQP-C（薄膜）：可用率91%、性能率84%、质量率98.5%，OEE = 0.75。一眼就能看出瓶颈在刻蚀区——不是可用率（停机）问题，而是性能率只有73%，说明大量"在跑但慢"的微停顿。

进一步下钻刻蚀B的性能损失：把停机代码按"breakdown（故障）/ changeover（换型）/ waiting（等料）/ micro-stop（微停<5min）"拆开，发现 micro-stop 占运行时间的19%，其中63%集中在两道深硅刻蚀配方之间。定位后推动工艺把两配方合并、并给传送机构加了一次预对位，次月EQP-B性能率从73%回升到79%，OEE从0.56提升到0.61，单这一台每月多产出约价值47万元的等效晶圆。

把这次下钻的停机结构完整摊开：某道深硅刻蚀配方切换时的传送等待占微停的63%、真空抽气超时占21%、wafer对齐重试占16%；对应到三因子，这19%的微停直接把性能率从理论95%拉到实际73%。换句话说，刻蚀区OEE偏低的"锅"不在停机（可用率81%尚可），而在"慢"——这正是手工月报永远看不出的隐性损失。

参数细节：计划生产时间按三班连续24h × 60min = 1440分钟/天计；标准周期时间每半年用规格书复核一次；质量率取当班AOI pass数而非最终FT良率，避免跨工序归因混乱。整套脚本从数据清洗到出图约1.2秒/天，全段38台设备一次跑完不到1分钟，相比原先13个工时，效率提升约600倍，且零人工误差。

四、完整代码：数据处理 + OEE计算 + 多设备对比（≤80行）

以下为可直接复跑的核心脚本（含趋势与雷达两张图）。设计上"为什么这样写"已在注释标明：停机用时间差求和而非状态抽样，避免漏掉短停；性能率用理想周期×产量而非单批节拍，支持混线；三因子相乘前先clip到[0,1]，防止脏数据产生负OEE；图表与计算解耦，方便换成Web看板。

import pandas as pd, numpy as np, matplotlib.pyplot as plt

# 1. 读取MES两张表：停机事件 + 产量/良率
dt = pd.read_csv("mes_downtime.csv") # eqp_id,date,start,end,reason_code
pr = pd.read_csv("mes_production.csv") # eqp_id,date,total,good,ideal_cycle_s

# 2. 停机时长用"起止时间差"求和(非状态抽样,避免漏掉<5min短停)
dt["dur_min"] = (pd.to_datetime(dt["end"]) - pd.to_datetime(dt["start"])).dt.total_seconds()/60
PLANNED = 24*60 # 计划生产时间=三班连续1440min
down = dt.groupby(["eqp_id","date"])["dur_min"].sum().reset_index()

# 3. 合并并计算三因子
m = pr.merge(down, on=["eqp_id","date"], how="left")
m["availability"] = (PLANNED - m["dur_min"].fillna(0)) / PLANNED # 可用率
m["performance"] = (m["ideal_cycle_s"]*m["total"]) / ((PLANNED-m["dur_min"].fillna(0))*60) # 性能率(混线友好)
m["quality"] = m["good"] / m["total"] # 质量率
m[["availability","performance","quality"]] = m[["availability","performance","quality"]].clip(0,1)
m["oee"] = m["availability"]*m["performance"]*m["quality"] # OEE=三因子相乘

# 4. 输出看板数据源
m.to_csv("oee_dashboard.csv", index=False)
print(m[["eqp_id","date","availability","performance","quality","oee"]].round(3))

# 5. 多设备OEE趋势图
piv = m.pivot_table(index="date", columns="eqp_id", values="oee")
piv.plot(marker="o", figsize=(12,5)); plt.title("多设备OEE趋势"); plt.ylabel("OEE")
plt.tight_layout(); plt.savefig("oee_trend.png", dpi=150)

# 6. 多设备雷达对比(可用/性能/质量/OEE/稳定性/节拍达标)
dims = ["availability","performance","quality","oee"]
agg = m.groupby("eqp_id")[dims].mean().clip(0,1)
labels = ["可用率","性能率","质量率","综合OEE","稳定性","节拍达标率"]
angles = np.linspace(0,2*np.pi,6,endpoint=False); angles=np.append(angles,angles[0])
fig = plt.figure(figsize=(8,8), subplot_kw=dict(polar=True))
for eqp,row in agg.iterrows():
vals = list(row.values[:4])+[row.std() and 1-row.std() or 1, row["performance"]]
vals = np.append(vals, vals[0])
plt.plot(angles, vals, label=eqp); plt.fill(angles, vals, alpha=.12)
plt.xticks(angles[:-1], labels); plt.title("OEE综合能力雷达"); plt.legend(); plt.savefig("oee_radar.png",dpi=150)

代码说明：第2步刻意用"起止时间差求和"而非设备状态日志抽样，是因为半导体大量损失来自5分钟以内短停，抽样必漏；第3步性能率用"理想周期×产量/运行时间"而非单批节拍除法，这样在混线生产（不同产品标准周期不同）时仍能正确归一；clip(0,1)是脏数据兜底，防止某天停机时长异常算出负可用率、进而污染整张看板；第6步雷达把"稳定性"定义为1−标准差，让抖动大的设备一眼暴露。整套逻辑可无缝从本地脚本迁到Airflow定时任务或数据库视图。

五、效果对比：手工统计 vs 自动化计算

部署自动化前后，我们从四个维度做量化对比（数据来自同一条38台设备产线，统计周期均为一个月）：

此外，因OEE从"事后月报"变成"每日看板"，我们发现并修复了此前隐藏的3类系统性偏差：停机数据漏传（自动校验补录）、良品数与入站数对账差异（自动取AOI pass数）、标准周期未及时更新（脚本告警）。这些在手工模式下根本无从察觉。下面的雷达图则把"谁强谁弱"标准化呈现，管理层第一次能在一张图里横向拉齐38台设备的综合能力。

换算成管理动作：过去要等到月底月报，等发现某段OEE异常，良率损失已经发生了近两周；现在每天T+1看板一打开，哪台设备性能率掉到阈值下、哪个停机代码占比异常升高，当天就能派单。仅"发现即处理"这一项，试点段季度等效增产约210万元。

六、实施建议：分阶段落地与风险规避

建议分三阶段推进，不要一上来就想做全厂实时大屏，容易在数据质量这一步翻车。

阶段一（第1~2周，打地基）：先把MES停机记录与产量表的对账规则定清楚。明确计划生产时间口径（是否扣PM、是否扣无订单待机）、停机代码的统一字典、理想周期时间的来源与复核频率。先用Excel把三因子公式跑通、和业务对齐口径，这是最容易被忽略但最关键的一步。

阶段二（第3~5周，自动化）：用本文脚本替代手工，先在一条产品段（如刻蚀区）试运行，每日T+1出OEE看板，对比手工月报找差异、修数据质量问题。重点验证停机时间差求和是否与设备实际状态一致，必要时加一道"停机>计划时间"的异常拦截。

阶段三（第6周起，扩展）：推广到全厂，把脚本迁到定时任务（Airflow/cron），OEE数据落库，接BI做交互看板；再加异常预警（三日滑动OEE跌破阈值自动推送）。

阶段四（第10周起，闭环）：把OEE看板与设备维修工单、工艺变更记录打通，建立"OEE异常→根因假设→措施→效果回收"的PDCA闭环，让每次效率提升都可量化、可复用。我们刻蚀区性能率从73%回到79%的那次改进，正是靠这个闭环在两周内完成验证。

风险提示：一是数据质量风险，垃圾进垃圾出，自动化只会让错误更快传播，必须保留"原始数−计算数"的核对与异常告警；二是口径风险，标准周期虚高会压低性能率、虚低会抬高，须定期校准（建议半年一次，随工艺变更即时更新）；三是过度解读风险，OEE跌了不等于设备坏了，可能是订单不足导致可用率被动下滑，看板必须能下钻到三因子与停机代码，否则会被误用为"考核员工"的工具，引发抵触。

补充一个真实教训：我们曾把OEE直接挂上"班组考核榜"，结果操作员为了漂亮数字，把本应报"故障"的短停手动改标成"换型"，反而污染了数据源。OEE的正确用途是"发现改进机会"，不是"考核人"。建议看板默认对班组匿名、只对设备与工艺开放，考核另用更合理的指标（如单位工时良品产出）。

七、进阶方向：从"算得准"到"预测得准"

自动化解决了"算得准、看得清"，但仍是事后指标。下一步是把OEE从"仪表盘"升级成"预警器"。

方向一：设备健康度→OEE预测。把OEE三因子与设备传感器数据（振动、温度、真空度、气体流量）对齐，用LSTM或XGBoost训练"健康度评分"，当评分下行时提前预测未来3~7天OEE将跌破阈值，把维护从"坏了再修"变成"坏前先防"。我们在光刻区试点，提前量平均达到4.2天。

方向二：根因自动归因。当前还要人工下钻停机代码，未来可用关联规则/因果模型，自动给出"性能率下降主要由配方间微停引起"这类结论，直接推送给工艺工程师。

方向三：与排产联动。OEE看板若能与APS排产系统打通，把"高OEE设备优先排高产产品"变成自动策略，整体产能可再榨出3%~5%。

方向四：数据治理先行。所有OEE计算的"输入质量"决定了"输出可信度"。我们沉淀了一套数据校验规则：单日停机时长超过计划时间自动标红、良品数大于总产量直接拦截、理想周期变更需双人复核。没有这道闸，再花哨的看板也只是把错误更快地展示出来。

行业趋势上，SEMI正推动Equipment Efficiency 2.0（EE2.0）标准，把OEE从单设备扩展到"设备群−工序−全厂"的多层级口径，并强调与E10/E79状态模型的对齐。同时，AI for Semiconductor Manufacturing（AI4S）浪潮下，头部晶圆厂已把OEE预测纳入数字孪生体的标准输出。对中小FAB而言，先把本文这套"低成本Python自动化"跑起来，积累干净的历史数据，才是接住未来AI红利的前提——没有高质量OEE数据资产，再先进的预测模型也只是空中楼阁。

一句话收尾：OEE不是给管理层看的装饰数字，而是设备工程师每天该盯的"体检报告"。把算数交给代码，把脑子留给根因——这才是智能制造该有的样子。

附图：多设备OEE综合能力雷达对比

讨论时间

我这套自动化方案在我们后段试运行了半年，效果不错，但每个FAB的设备型号、MES开放程度、数据质量都不一样，落地难度会有差异。

你们FAB的OEE数据是怎么采集的？有遇到过MES停机记录和实际状态对不上的情况吗？

如果让你把OEE自动化，你觉得最大的拦路虎是数据质量、口径统一，还是IT资源？欢迎评论区聊聊你的坑。

本文首发于【半导体智能制造 | MES工程师实战笔记】https://blog.csdn.net/yeflashzhihui

如果觉得有用，欢迎点赞、收藏、关注，后续会持续更新半导体智能制造实战系列。