设备状态模型(E10)：Up/Down时间的正确归类

一、背景故事两个部门算出两个稼动率事情起于一次产能评审会。市场端拿来一个新订单问刻蚀区还能不能再吃下每月三千片。设备部门的报表说刻蚀机月度Availability是91.2%还有近9%的空间生产部门的报表说同样这批机台的Availability只有79.8%早就吃紧了。同一批机台、同一个月、同一套MES底层数据两个部门算出来的数字差了11.4个百分点。会开到一半变成了两个部门互相质疑对方的报表怎么来的最后订单评审被迫延后一周。我被指派去把这件事查清楚。查了三天结论其实很简单两边的数据都没错错的是他们把时间装进了不同的桶。设备部门把等料时间算作待机属于Uptime生产部门把等料时间算作停机因为在他们的视角里机台没在产出就是停着。类似的分歧还有十几处Qual跑片算不算生产、换靶材算不算计划停机、报警自动恢复的两分钟要不要切状态、夜班无排程关机的八小时进不进分母。这些分歧看起来是统计口径的小事实际后果非常严重。因为Availability虚高我们在过去一年半里始终认为刻蚀区不是瓶颈扩产投资全部押在了薄膜区。直到订单实际压下来刻蚀区连续三个月排队时间失控才发现钱花错了地方。事后复盘那笔投资的错配成本按当年产能损失折算大约在一千二百万人民币量级。这就是时间归类这件小事的真实代价。SEMI E10标准从上世纪九十年代就存在几乎每本设备管理教材都会提到但在国内Fab的落地质量普遍不高。原因不是标准难懂而是标准只给了六个状态的定义没有给出上百种现场场景该往哪个桶里放的判据。这篇文章就是把我们踩过的坑和最终定下来的判据完整写出来。二、技术原理六状态模型与时间守恒E10的核心是一个时间守恒等式。一个自然月的总时间Total Time30天即720小时首先被切成两块Non-Scheduled TimeNST非排程时间和Operations Time运行时间。NST是工厂主动选择不使用这台设备的时间比如春节停线、设备尚未安装完成、因无订单而封存的机台。NST的关键特征是不可用状态由管理决策造成与设备本身的能力无关所以它被排除在所有稼动率指标的分母之外。Operations Time再切成Uptime和Downtime。Uptime包含三个子状态Productive Time生产时间、Standby Time待机时间、Engineering Time工程时间。这三者的共同点是设备处于可以加工的健康状态区别只在于此刻它在干什么。Downtime包含两个子状态Scheduled DowntimeSDT计划停机和Unscheduled DowntimeUDT非计划停机共同点是设备此刻不具备加工能力。在这个框架下最重要的两个指标定义就清晰了。Availability可用率等于Uptime除以Operations Time衡量的是设备健康程度它不关心设备有没有活干只关心它想干活的时候能不能干。Utilization稼动率等于Productive Time除以Operations Time衡量的是设备被用得充不充分。两者的差值主要由Standby贡献这个差值本身就是极有价值的管理信号差值大说明设备是好的但没活干问题在排产或前站差值小而Availability低问题才在设备本身。很多工厂把这两个指标混着叫稼动率这是一切混乱的开端。我们现在的做法是在所有报表里强制写全称并标注公式宁可标题长一点也不允许出现单独的稼动率三个字。表1SEMI E10六大基本设备状态定义与归类判据状态英文名中文名计入Uptime判定要点与典型场景Productive Time生产时间是机台正在加工产品晶圆、Rework片或可交付的工程片产出计入WIPStandby Time待机时间是机台具备加工能力但无活可干等料、等人、等前站、无排程但设备可用Engineering Time工程时间是机台被工程活动占用Qual跑片、Recipe调试、DOE实验、设备特性验证Scheduled Downtime计划停机否事先排入计划的不可用PM保养、预定改机、计划性换件、定期校准Unscheduled Downtime非计划停机否突发不可用故障报警、异常停机、等备件、等工程师、修复后验证Non-Scheduled Time非排程时间不计入工厂主动不排产停线放假、设备未安装、封存机台、无订单关机(衍生)Assist Event辅助介入事件视时长短于阈值(通常5分钟)的人工介入不切状态超阈值必须切UDTE10还有一个常被忽略的概念是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%跨部门报表争议下降近九成。表2Fab现场十二处最容易归错桶的时间场景对照表争议场景常见错误归类E10正确归类错误归类造成的后果等待前站来料归UDT或不统计Standby待机设备被误判为故障多发维修资源错配等待操作员上料归ProductiveStandby待机掩盖人力配置不足产能瓶颈定位到错误环节Qual验证跑片归ProductiveEngineering生产良率被工程片污染良率口径失真PM后的验证跑片归ProductiveEngineeringPM实际占用时长被低估保养窗口排不准换靶材/换膜/换气瓶归StandbySDT(计划内)耗材更换频次无法量化备件计划失去依据等备件到货归SDTUDT非计划停机供应链响应问题被藏进计划停机无人问责报警后自动恢复不切状态超阈值切UDTMTBF被严重高估可靠性趋势看不出恶化夜班无排程关机归StandbyNST非排程Availability分母被撑大稼动率虚低设备待安装/搬迁中计入总时间NST非排程新机导入期拖累全厂稼动率指标软件升级/系统重启不统计SDT或UDTIT变更对产能的影响完全不可见腔体在线清洗(WAC)归UDTSDT计划内工艺必需的清洗被当成故障误导设备评价多腔体机台部分腔停整机切Down按腔体分别统计一腔故障拖累整机指标损失被放大数倍八、延伸补充判据表维护、指标衍生与常见追问8.1判据表如何持续维护判据表不是一次性交付物。新设备导入、新工艺引入、新的异常类型出现都会带来判据表覆盖不到的场景。我们的做法是设一个月度增补机制每月由MES系统自动统计原因码为其他的状态切换记录如果某类其他的出现频次连续两个月超过二十次就触发一次判据评审把这类场景正式收编进判据表并分配专属原因码。一年半下来判据表从一百四十七条增长到一百九十六条其他类占比从最初的11%降到2.3%。配套资料与实战工具包本文涉及的脚本、参数模板、检查清单已整理成配套资料包可直接用于工厂落地实施内容随实践持续更新。点击文章上方「VIP资源」下载区免费获取SEMI E10六状态判据表完整版196条场景归类含优先级规则与反例说明EAP设备状态自动判定决策表模板四输入源映射逻辑可直接导入配置多腔体机台状态聚合规则配置说明含腔体折算与Mainframe聚合公式Availability/Utilization/OEE计算口径对照表含E79性能与质量维度设备状态事件三层存储与聚合脚本包含建表SQL与增量聚合存储过程────────────────────────────────────────本文首发于博客半导体智能制造| MES工程师实战笔记你在实际项目里遇到过类似情况吗是怎么处理的欢迎在评论区分享你的实战经验一起交流进步。标签MES自动化|半导体Fab | MES系统| SPC |良率提升|智能制造