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 真空传感器没信号 | 设备端用“系统时间”代替“硬件锁存时间”，没等物理动作完成就上报S6F11 | Host 以为晶圆到位，下发工艺指令，可能导致撞片 |
| 顺序颠倒 | 先报 Place 完成，再报 Pick 开始 | 并发操作消息队列乱序，没有做顺序校验 | 晶圆轨迹完全错乱，追溯失效 |
| 漏报异常 | Robot Pick 失败了，但没上报S6F11，Host以为成功了 | 设备商把 Alarm 做成 Warning，甚至直接吞掉异常事件 | 后续工艺全部建立在错误前提上，报废风险极高 |
⚠️关键认知：E90 标准定义 Substrate 的状态模型包括
AT_SOURCE、IN_MOTION、AT_WORK、AT_DESTINATION、LOST、REJECTDE、PROCESSED等。但状态跳转是否真实发生，标准管不了，只能靠验证。
三、验证 SubstHistory 可信度的 3 个硬核手段
手段1：PLC 硬信号对账（最准）
原理：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对账立刻原形必露。
手段2：Host 历史查询核对（S12F / S1F4）
原理：E90 允许 Host 通过 S12F 系列消息（Map Data Request）或 S1F4（Get Attribute）主动查询设备的 Substrate History。
操作：
Host → Equipment: S12F3 (Map Data Type 2 Request) --> 请求指定 SubstrateID 的 History Equipment → Host：S12F4 (Map Data Type 2 Response) <L> <SubstrateHistory> <TimeStamp>2026-08-04T10:05:12.345Z</TimeStamp> <Event>MOVE</Event> <FromLoc>LP1_Slot05</FromLoc> <ToLoc>ROBOT</ToLoc> </SubstrateHistory> <SubstrateHistory> <TimeStamp>2026-08-04T10:06:01.789Z</TimeStamp> <Event>MOVE</Event> <FromLoc>ROBOT_ARM1</FromLoc> <ToLoc>PM1</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 时间不连续 - 不合格：悄悄用回滚的时间打时间戳，造成“时间倒流”
- 期望：上报
双片同时进入Robot（Double 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事件
- NTP 大步调整时，主动发
⚠️真实案例（模糊处理）：某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 造假的案例吗？ 是怎样抓出来的？ 欢迎在评论区分享你的血泪史。
