E90 SubstHistory 可信度验证别让晶圆“穿越时空”摘要SEMI E90 要求设备对 Substrate晶圆的位置、状态及转移路径进行标准化追踪并维护可读的历史记录SubstHistory。但在 FAT/SAT 现场最让 EAP 工程师头皮发麻的不是“没报”而是“报了但不可信”——时间倒流、无中生有、顺序颠倒、漏报异常。文本基于 E90 标准定义结合 PLC 硬信号对账、Host 历史查询、异常场景注入三种手段给出一套可落地的 SubstHistory 可信度验证方法。一、为什么 SubstHistory 不能“报了就行”E90 标准的存在意义就是让 Substrate 的位置、状态、传输路径变得可控、可追溯。设备必须为每片晶圆维护一条有序的位置访问记录包括何时Timestamp、何地Location、何种事件Move / Process / State Change。在 Fab 里这条记录直接服务于Yiele Analysis良率分析哪片晶圆在哪个腔体停留多久对应哪段工艺。Virtual Metrology虚拟量测用历史轨迹训练模型反推工艺结果。Fault Traceability故障回溯出问题时第一时间还原晶圆的物理流转。只要 SubstHistory 里有一条数据是假的上面所有上层应用全部失真。SubstHistory不是上报了就行而是每一条事件都必须有硬件背书。二、SubstHistory 的 4 种典型“造假”场景下面这4类问题是FAT/SAT 阶段最高频的“假历史”造假类型现象真实原因后果时间倒流晶圆时间戳比上一道工序还早设备重启后时间回滚NTP 未同步就上报事件用了 datetime.now而非硬件锁存时间Yield 分析时序错乱整批数据作废无中生有软件上报 Robot Pick 成功但 PLC 真空传感器没信号设备端用“系统时间”代替“硬件锁存时间”没等物理动作完成就上报S6F11Host 以为晶圆到位下发工艺指令可能导致撞片顺序颠倒先报 Place 完成再报 Pick 开始并发操作消息队列乱序没有做顺序校验晶圆轨迹完全错乱追溯失效漏报异常Robot Pick 失败了但没上报S6F11Host以为成功了设备商把 Alarm 做成 Warning甚至直接吞掉异常事件后续工艺全部建立在错误前提上报废风险极高⚠️关键认知E90 标准定义 Substrate 的状态模型包括AT_SOURCE、IN_MOTION、AT_WORK、AT_DESTINATION、LOST、REJECTDE、PROCESSED等。但状态跳转是否真实发生标准管不了只能靠验证。三、验证 SubstHistory 可信度的 3 个硬核手段手段1PLC 硬信号对账最准原理E90 的 SubstHistory 本质上是软件层的记录。要验证它必须拉出设备底层的 PLC IO 信号做交叉对比。操作要求设备商开发 PLC 的 IO 监控权限或提供 IO 日志导出。对每一条 S6F11 SubstrateLocationChange / SubstrateStateChange 事件找到对应的 PLC 硬信号Robot Pick 完成 → 真空传感器Vacuum Sensor信号置位Place 完成 → 腔体到位传感器Presence Sensor信号置位Process Start → 工艺电源 / RF 信号激活时间对齐软件事件时间戳 vs PLC 信号变化时间戳误差必须 ≤ E148 要求的精度窗口通常 ≤ 10ms。合格标准软件事件、PLC信号、时间戳三者完全对齐。没有一条 S6F11 是“无中生有”的。没有一条PLC信号变化是“漏报”的。这一步是FAT阶段最狠的一刀。设备商如果在代码里“默认成功”PLC对账立刻原形必露。手段2Host 历史查询核对S12F / S1F4原理E90 允许 Host 通过 S12F 系列消息Map Data Request或 S1F4Get Attribute主动查询设备的 Substrate History。操作Host → Equipment: S12F3 (Map Data Type 2 Request) -- 请求指定 SubstrateID 的 History Equipment → HostS12F4 (Map Data Type 2 Response) L SubstrateHistory TimeStamp2026-08-04T10:05:12.345Z/TimeStamp EventMOVE/Event FromLocLP1_Slot05/FromLoc ToLocROBOT/ToLoc /SubstrateHistory SubstrateHistory TimeStamp2026-08-04T10:06:01.789Z/TimeStamp EventMOVE/Event FromLocROBOT_ARM1/FromLoc ToLocPM1/ToLoc SubstrateHistory ... /L核心要点时序连续性上一条的ToLoc必须等于下一条的FromLoc不能有跳跃。状态合法性相邻两条记录之间Substrate State 必须符合E90状态机定义如IN_MOTION之后必须是AT_WORK或AT_DESTINATION。时间单调性时间戳必须严格递增不允许出现TimeStamp(n) TimeStamp(n-1)。数量一致性Host 侧 MES 记录的晶圆数量、工序顺序、必须与 E90 上报的历史完全重合差异 ≤ 0.01%。合格标准Host 查询出的 History 与 MES 的批次跟踪记录100% 吻合差异部分必须有合理解释如设备维护导致的异常事件。手段3异常场景注入最狠原理正常流程跑通不代表异常流程可信。必须在 SAT 阶段故意制造异常看 SubstHistory 是否如实上报。操作清单拔掉Robot真空传感器线期望上报SubstrateStateChange → REJECTED或LOST不合格继续上报AT_WORK PM1假装放片成功强制中断工艺Abort期望上报SubstrateProcessComplete事件State ABORTED不合格不上报或上报PROCESSED伪造完成故意让设备时间回滚期望上报S6F11 TimeChange事件通知 Host 时间不连续不合格悄悄用回滚的时间打时间戳造成“时间倒流”双片同时进入RobotDouble Occupancy期望上报Substrate Rejected标记 LOST不合格两片晶圆共用同一个 SubstrateID轨迹纠缠合格标准所有异常都有对应的 S6F11 事件没有漏报、瞒报。E90 标准明确指出对于“Substrate dropped”等情况设备必须标记为LOST并 raise alarm。四、E148时间对齐SubstHistory的“地基”再完美的事件记录如果时间戳是错的整条 History 就是科幻小说。必须满足的 3 个时间条件硬件锁存而非软件生成❌ 错误S6F11上报时用datetime.now()取系统时间✅ 正确Robot Pick 完成的那一瞬间PLC 锁存一个硬件时间戳软件上报时直接读取这个锁存值E148 Accuracy Class 如是申报在TS—Clock对象里上报真实的 Accuracy如 ±10ms达不到精度要求时直接标UNSYNCHRONIZED不要硬撑时间跳变主动通知NTP 大步调整时主动发S6F11 TimeChange事件设备重启后在同步完成前禁止上报E90事件⚠️真实案例模糊处理某12 吋 Fab 项目设备商信誓旦旦说 SubstHistory 没问题。我们用PLC日志对账发现 30% 的 Pick 成功事件是假的——软件上报了成功但真实传感器根本没信号。最后查出来是设备商代码逻辑问题只要 Robot 动作指令下发就默认成功不管物理反馈。如果不是硬要对账这批晶圆跑完工艺报废都不知道原因。五、FAT / SAT 检查清单建议贴在工位PLC对账每一条 S6F11 事件都能在 PLC IO 日志中找到对应的硬信号时间对齐软件事件时间戳与PLC信号变化时间差 ≤ 10ms时序连续History 中商一条 ToLoc 下一条 FromLoc状态合法相邻记录间的 Substrate State 符合 E90 状态机时间单调Timestamp 严格递增无倒流异常覆盖Pick 失败、Process Abort、Double Occupancy 等异常均有 S6F11 上报E148合规Accuracy 如是申报时间跳变主动通知重启后同步完成前禁报事件Host查询S12F3 / S1F4 查询结果与 MES 记录 100% 吻合并发验证多片晶圆同时移动时无事件丢失、无顺序颠倒六、总结SubstHistory 的可信度决定了 Fab 数据资产的底色。报了 ≠ 对了对了 ≠ 真了。验证 SubstHistory 可信度的唯一标准是让软件事件与硬件信号一一对账。PLC 的真空传感器不会撒谎IO 指示灯不会演戏E148的时钟不会”差不多“。愿你的 SubstHistory 里每一片晶圆都走得堂堂正正没有穿越没有造假没有”无中生有“。你在 FAT / SAT 阶段遇到过 SubstHistory 造假的案例吗 是怎样抓出来的 欢迎在评论区分享你的血泪史。