[粉丝专享] 设备状态模型(E10)：Up/Down时间的正确归类

【摘要】SEMI E10定义的六大设备状态是Fab所有稼动率指标的地基，但绝大多数工厂在落地时都把等料、换靶材、Qual验证这几类时间归错了桶，导致Availability虚高十几个点、瓶颈机台被长期误判。本文完整拆解E10的六状态模型、时间归类的十二处争议点、MES状态机的落地配置方法，以及我们把口径重建后瓶颈识别准确率从58%提升到93%的过程。

分类：MES自动化 | 发布日期：2026-08-13 | 阅读时长：约12分钟

一、背景故事：两个部门算出两个稼动率

事情起于一次产能评审会。市场端拿来一个新订单，问刻蚀区还能不能再吃下每月三千片。设备部门的报表说刻蚀机月度Availability是91.2%，还有近9%的空间；生产部门的报表说同样这批机台的Availability只有79.8%，早就吃紧了。同一批机台、同一个月、同一套MES底层数据，两个部门算出来的数字差了11.4个百分点。会开到一半变成了两个部门互相质疑对方的报表怎么来的，最后订单评审被迫延后一周。

我被指派去把这件事查清楚。查了三天，结论其实很简单：两边的数据都没错，错的是他们把时间装进了不同的桶。设备部门把等料时间算作待机，属于Uptime；生产部门把等料时间算作停机，因为在他们的视角里机台没在产出就是停着。类似的分歧还有十几处：Qual跑片算不算生产、换靶材算不算计划停机、报警自动恢复的两分钟要不要切状态、夜班无排程关机的八小时进不进分母。

这些分歧看起来是统计口径的小事，实际后果非常严重。因为Availability虚高，我们在过去一年半里始终认为刻蚀区不是瓶颈，扩产投资全部押在了薄膜区。直到订单实际压下来，刻蚀区连续三个月排队时间失控，才发现钱花错了地方。事后复盘，那笔投资的错配成本按当年产能损失折算大约在一千二百万人民币量级。这就是时间归类这件小事的真实代价。

SEMI E10标准从上世纪九十年代就存在，几乎每本设备管理教材都会提到，但在国内Fab的落地质量普遍不高。原因不是标准难懂，而是标准只给了六个状态的定义，没有给出上百种现场场景该往哪个桶里放的判据。这篇文章就是把我们踩过的坑和最终定下来的判据完整写出来。

二、技术原理：六状态模型与时间守恒

E10的核心是一个时间守恒等式。一个自然月的总时间（Total Time，30天即720小时）首先被切成两块：Non-Scheduled Time（NST，非排程时间）和Operations Time（运行时间）。NST是工厂主动选择不使用这台设备的时间，比如春节停线、设备尚未安装完成、因无订单而封存的机台。NST的关键特征是不可用状态由管理决策造成，与设备本身的能力无关，所以它被排除在所有稼动率指标的分母之外。

Operations Time再切成Uptime和Downtime。Uptime包含三个子状态：Productive Time（生产时间）、Standby Time（待机时间）、Engineering Time（工程时间）。这三者的共同点是设备处于可以加工的健康状态，区别只在于此刻它在干什么。Downtime包含两个子状态：Scheduled Downtime（SDT，计划停机）和Unscheduled Downtime（UDT，非计划停机），共同点是设备此刻不具备加工能力。

在这个框架下，最重要的两个指标定义就清晰了。Availability（可用率）等于Uptime除以Operations Time，衡量的是设备健康程度，它不关心设备有没有活干，只关心它想干活的时候能不能干。Utilization（稼动率）等于Productive Time除以Operations Time，衡量的是设备被用得充不充分。两者的差值主要由Standby贡献，这个差值本身就是极有价值的管理信号：差值大说明设备是好的但没活干，问题在排产或前站；差值小而Availability低，问题才在设备本身。

很多工厂把这两个指标混着叫稼动率，这是一切混乱的开端。我们现在的做法是在所有报表里强制写全称并标注公式，宁可标题长一点，也不允许出现单独的稼动率三个字。

表1：SEMI E10六大基本设备状态定义与归类判据

E10还有一个常被忽略的概念是Assist Event（辅助介入事件），指的是设备运行中需要人工短暂介入但不构成停机的事件，比如清一次误报、手动确认一次弹窗、扶正一片放歪的晶圆。E10允许工厂设定一个时长阈值，短于阈值不切状态，超过阈值必须切UDT。这个阈值的设定很有讲究：设得太长（比如30分钟），大量真实的小故障会被藏起来，MTBF被严重高估；设得太短（比如1分钟），状态切换过于频繁，MES事件表体积暴涨，而且现场操作员会因为频繁弹出原因码录入框而产生抵触。我们最终定在5分钟，这个值参考了原厂建议并结合了自己三个月的事件时长分布统计。

三、现状分析：多数工厂现在是怎么做的

我调研过十一家不同规模的Fab和封测厂，E10落地质量大致分三档。第一档约占两成，通常是外资背景或有严格客户审核的厂，E10状态在MES里有完整定义，原因码分级到三层，状态切换由EAP根据设备SECS消息自动触发，人工只做原因补录。这类厂的问题通常不在口径，而在原因码颗粒度过细导致操作员乱选，统计出来的根因分布不可信。

第二档约占五成，是最典型的状况：MES里定义了六个状态，但状态切换靠人工在终端上点。人工点状态的必然结果是滞后和遗漏，设备半夜三点报警停了，操作员四点半才想起来点Down，这一个半小时就被算进了Productive。我们统计过一家厂的状态切换延迟分布，中位数是18分钟，P90是1小时47分钟。这种数据做趋势分析是有意义的，但拿来算精确的Availability并对标客户要求，误差大到没法用。

第三档约占三成，根本没有状态模型，只有一张Excel记录停机。每天早班交接时由班长填昨天哪台机停了多久、什么原因，月底汇总成一张停机时间统计表。这类厂通常规模不大或者以成熟制程为主，管理层觉得设备就那么几台，心里有数。问题是心里有数无法沉淀，班长一换，历史数据的可比性立刻中断。

还有一个跨档次的普遍问题：多腔体机台的状态统计。现在主流的刻蚀、薄膜设备都是多腔体架构，一个Mainframe带四到六个Chamber。大部分MES的状态模型建在Mainframe层级，一个腔体故障就把整机切成Down，结果是损失被放大数倍，而且完全看不出到底是哪个腔体在拖后腿。正确做法是状态建在Chamber层级，Mainframe状态由腔体状态按规则聚合，但这需要EAP能解析到腔体粒度的SECS消息，改造成本不低。

四、瓶颈问题：卡在哪里

第一个瓶颈是标准与场景之间的鸿沟。E10给了六个桶，但没告诉你上百种现场情况该往哪个桶放。等待前站来料到底算Standby还是算Down？从设备视角看它完全健康，是Standby；从产出视角看它没在产出，像是Down。E10的答案明确是Standby，因为Downtime的定义前提是设备不具备加工能力。但如果没人把这个判据白纸黑字写下来，每个工程师都会按自己的直觉判断。

第二个瓶颈是责任归属的博弈。时间归类不是纯技术问题，它直接决定谁背锅。等备件的24小时如果归UDT，设备部门的MTTR指标就难看；如果归SDT，就变成了计划内的事，谁也不用负责。我见过好几家厂的设备部门主动把等备件时间往SDT里塞，理由是备件采购周期是已知的，所以属于可预期的计划停机。这个理由听起来自洽，实际上把供应链响应速度的问题彻底藏了起来，一年后没人知道备件体系到底有多糟糕。

第三个瓶颈是采集能力跟不上。要做到状态自动切换，EAP必须能实时收到设备的状态变更消息，通常是SECS-II的S6F11事件报告，携带设备当前的Processing State和Control State。但老设备往往不支持标准的状态上报，或者上报的状态定义与E10不匹配。我们有一台九十年代的扩散炉，只能通过读取三个数字量IO点来推断状态，组合出来的状态只有运行、停止、报警三种，要映射成E10六状态必须结合MES的工单信息和保养计划做联合判断，逻辑相当复杂。

第四个瓶颈是历史数据不可比。口径一改，历史指标全部失效。这是很多厂明知口径有问题也不愿改的核心原因：改了之后Availability从91%掉到85%，怎么向管理层解释？年度KPI已经签了，中途改口径等于自己给自己挖坑。这个顾虑非常真实，也是口径治理项目最大的政治阻力。

五、解决方案：可落地的完整做法

我们最终采用的是判据表加自动切换加双轨过渡的组合方案。第一步是建判据表。我们组织设备、工艺、生产、IT四方，用两周时间把现场所有能想到的时间场景列了出来，一共一百四十七条，逐条讨论归到哪个E10状态，写明判据和责任方。讨论过程中争议最大的十二条单独拉出来做了专项评审，这十二条就是本文表2的内容。判据表最终由厂长签发，作为强制标准执行。

这里有个经验：判据表一定要写反例。只写等料归Standby是不够的，必须补一句但如果等料期间设备同时处于报警状态，则以报警为准归UDT。现场情况经常是多个条件同时成立，没有优先级规则就会各按各的理解来。我们定的优先级是UDT大于SDT大于Engineering大于Productive大于Standby大于NST，即任意时刻多条件命中时，取优先级最高的那个状态。

第二步是自动切换。我们把EAP的状态判定逻辑重写了一遍，输入源有四个：设备SECS上报的Processing State、设备报警字、MES的工单与批次状态、以及保养系统的PM计划表。四个输入通过一张决策表映射到E10状态。举个例子：设备Processing State为IDLE、无报警、MES查到该机台可加工的WIP队列为空，则判定为Standby；同样是IDLE无报警，但WIP队列非空且批次已到位，说明设备可用却没开工，判定仍为Standby但打一个可开工未开工的子标签，这个子标签后来成了我们抓生产调度问题的利器。

第三步是把状态建到腔体层级。我们选了改造投入产出比最高的三十二台多腔体机台，让EAP解析腔体粒度的事件。Mainframe状态由腔体聚合：全部腔体Down则整机Down；部分腔体Down则整机按可用腔体数打折计入，比如四腔机台停一腔，该时段按0.75台次统计。这个改造让我们第一次看清楚了腔体级的可靠性差异，发现同型号机台的四号腔故障率普遍高于其他腔，追下去是排气管路设计导致的积聚差异，这是整机粒度统计永远发现不了的。

图1：同一台机台同一个月，设备部与生产部两套旧口径和E10标准口径的时间构成差异。待机与非计划停机两桶的归类分歧最大，直接导致两个部门算出的Availability相差11.4个百分点。

第四步是双轨过渡。为了化解历史数据不可比的政治阻力，我们做了六个月的双轨运行：新旧两套口径同时出报表，KPI考核在过渡期内仍用旧口径，但所有决策分析用新口径。六个月后新口径积累了足够的历史数据，同时管理层通过每月的双轨对比报告逐渐理解了差异来源，第二年的KPI基线就顺理成章地切到了新口径。这一步是纯管理动作，但它决定了整个项目能不能活下来。

六、实战案例：一台刻蚀机的完整重算

选一台具体机台把过程走完。这是一台四腔的介质层刻蚀机，编号脱敏后叫ETCH-C07，统计月份为某年五月，自然月总时间744小时。按旧的设备部口径，这台机的月度报表是：Uptime 668小时、Downtime 52小时、NST 24小时，Availability等于668除以720，也就是92.8%。

重算过程逐项来。首先是NST，旧口径把五一假期停线的24小时算了NST，这一条正确。但同时发现该机在月底有8小时因为整条产线的动力检修而关机，旧口径把它塞进了SDT，按判据这属于工厂主动停产，应归NST。于是NST从24小时调整为32小时，Operations Time相应从720降到712。

其次是Productive。旧口径的668小时Uptime里，有38小时其实是PM后的Qual验证跑片和一次新Recipe的DOE实验，这两类都应归Engineering。虽然Engineering同属Uptime不影响Availability，但它影响Utilization和良率口径，因为这38小时产出的晶圆是工程片，不该混进量产良率统计。我们回查了这批工程片的数据，发现其中一次DOE的低良率片确实被算进了当月量产良率，拉低了大约0.3个百分点，这个误差在良率例会上曾经被当成异常追查过两周。

第三是等料时间的归类。旧口径把等料的121小时中的96小时算了Standby，另外25小时因为操作员在终端点了Down（他们习惯性认为没活干就点Down）而算进了UDT。按判据这25小时应回归Standby。这一改，UDT从52小时降到26小时，MTTR相应大幅改善，但同时暴露出Standby高达121小时，占Operations Time的17%，这才是真正需要管理层关注的数字。

第四是Assist Event。我们从MES事件表里捞出该月所有人工介入记录，共63次，按5分钟阈值筛选，有9次超过阈值，累计2.4小时，这部分原先完全没统计，现在补记为UDT。虽然绝对时长不大，但它让MTBF从旧口径的虚高值回落到真实水平，这台机的真实MTBF指数从100降到78，可靠性排名从区内第三降到第九，维修资源的分配优先级随之调整。

重算后的最终结果：Operations Time 712小时，Productive 486小时、Standby 121小时、Engineering 38小时、SDT 41小时、UDT 26小时，Availability等于645除以712，即90.6%，比旧口径的92.8%低了2.2个百分点。而Utilization只有68.3%，这个数字第一次被摆到桌面上，直接引出了后续的排产优化专项。

七、实施效果：数据说话

口径治理在全厂两百三十七台机台上推行，历时七个月。最直观的变化是全厂平均Availability从虚高的91.2%回落到84.6%。这个数字变难看了，但它是真的。同期OEE基本持平，从68.4%到67.9%，说明工厂的实际产出能力并没有变化，变的只是我们看它的方式。这一点在向管理层汇报时非常关键：必须明确指出产出没变，只是尺子准了。

真正的收益体现在决策质量上。瓶颈识别准确率是我们定义的一个验证指标：用月初的稼动率数据预测当月哪些工序会出现排队积压，与月末实际情况对比。口径重建前这个准确率只有58%，基本等于抛硬币；重建后达到93%。直接结果是当年的设备投资计划做了重新排序，原计划投在薄膜区的两台设备预算调整到了刻蚀区，按后续实际运行情况看，这次调整避免的产能损失约在年化八百万人民币量级。

MTTR指数从100降到62，这不是维修变快了，而是原先被错误归入UDT的等料时间被清理出去，真实的维修时长浮出水面。有了准确的MTTR，我们才第一次能够按机型、按故障类型做维修效率对标，发现某型号设备的更换某个部件的标准工时比原厂建议长了两倍多，追下去是工具准备流程的问题，优化后单次维修节省47分钟。

跨部门报表争议次数下降了88%。这一项没有直接的经济收益，但参与过口径扯皮会议的人都知道它的价值。现在设备部和生产部拿的是同一张报表、同一套定义，会议时间可以真正花在讨论怎么改善上，而不是花在证明我的数字才是对的。

还有一个意外收获是客户审核。我们的一家国际客户每年做一次供应商产能审核，过去每次都会在稼动率数据的可追溯性上开不符合项，因为我们拿不出状态定义文件和自动采集证据。口径治理完成后的第一次审核，这一项直接通过，审核员在报告里写了一句设备状态管理体系符合SEMI E10要求，这句话对后续争取新项目起了实际作用。

图2：口径重建后Availability从虚高的91.2%回落到真实的84.6%，OEE基本持平说明产出未变，但瓶颈识别准确率从58%跃升至93%，跨部门报表争议下降近九成。

表2：Fab现场十二处最容易归错桶的时间场景对照表

八、延伸补充：判据表维护、指标衍生与常见追问

8.1 判据表如何持续维护

判据表不是一次性交付物。新设备导入、新工艺引入、新的异常类型出现，都会带来判据表覆盖不到的场景。我们的做法是设一个月度增补机制：每月由MES系统自动统计原因码为其他的状态切换记录，如果某类其他的出现频次连续两个月超过二十次，就触发一次判据评审，把这类场景正式收编进判据表并分配专属原因码。一年半下来判据表从一百四十七条增长到一百九十六条，其他类占比从最初的11%降到2.3%。

配套资料与实战工具包

本文涉及的脚本、参数模板、检查清单已整理成配套资料包，可直接用于工厂落地实施，内容随实践持续更新。点击文章上方「VIP资源」下载区免费获取：

SEMI E10六状态判据表完整版（196条场景归类，含优先级规则与反例说明）

EAP设备状态自动判定决策表模板（四输入源映射逻辑，可直接导入配置）

多腔体机台状态聚合规则配置说明（含腔体折算与Mainframe聚合公式）

Availability/Utilization/OEE计算口径对照表（含E79性能与质量维度）

设备状态事件三层存储与聚合脚本包（含建表SQL与增量聚合存储过程）

────────────────────────────────────────

本文首发于博客：半导体智能制造 | MES工程师实战笔记

你在实际项目里遇到过类似情况吗？是怎么处理的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：MES自动化 | 半导体Fab | MES系统 | SPC | 良率提升 | 智能制造