FAT 攻坚战：别让“Demo级接口”骗了你——EAP 验收的4个必杀技
摘要：在 300mm Fab 的 EAP 项目中，最令人头疼的往往不是接口不痛，而是接口“假装能痛”。本文基于 FAT （Factory Acceptance Test）实战经验，总结了断网测试、脏数据注入、极限时序与日志溯源四大必杀技，旨在帮助工程师在验收阶段剔除隐患，确保设备的稳定性和数据的完整性。
一、前言：从“AI 糊弄”到“设备商糊弄”
最近在调试接口时，我被一个“助手”气得够呛。明明做不到的东西，却非要生成一百张假图来糊弄我。
这让我瞬间联想到半导体工厂里的设备商。Demo 跑得飞起，PPT 写得天花乱坠，一到 FAT （Factory Acceptance Test）就原形必露。很多时候，设备端只是“假装干活”——Host 发了指令，它回了ACK，但实际上 PLC 没动作，数据也没落库。
在 Fab 里，Demo 跑通只值 10 分，能抗住 FAT 压力测试才值 100 分。今天不聊虚的，分享几招我在现场用来抓“假接口”的硬核手段。
二、第一招：断网测试（专治假连接）
2.1 痛点直击
设备商往往拍胸脯保证 HSMS 连接稳定。但在 Fab 现场，网线被碰掉、交换机端口老化、甚至清洁工拔错线都是家常便饭。如果设备在网络中断后反应迟钝，或者还在“假装处理”任务，后果不堪设想。
2.2 操作手法
联调时，不要只在理想环境下测试。直接拔掉设备的网线，或者在交换机上禁用端口。这是检验设备健壮性的试金石。
2.3 判定标准（合格 VS 劣质）
| 维度 | 合格接口 | 劣质接口 （“假干活”） |
|---|---|---|
| 响应时间 | 在T7 Timeout内触发Communication Fail。 | 超过 T7 时间反应，或长时间处于WAIT_CRA状态。 |
| 状态机 | 立即回退到OFFLINE或LOCAL状态。 | 状态机僵死，或错误地停留在PROCESSING状态。 |
| 指令处理 | 拒绝接收任何远程指令，并返回Busy或Offline。 | 继续回Command Accepted，误导 Host 下发更多指令。 |
核心逻辑：网络是 EAP 的生命线。断网后设备必须表现出“求生欲”，而不是“假死”。
三、第二招：脏数据注入（专治假逻辑）
3.1 痛点直击
你发标准的S2F41 Remote Command，设备能处理；你发个参数缺胳膊少腿，它也回OK。这种过度的“宽容”在 Fab 里是致命的，它会掩盖工艺配方错误，导致晶圆报废。
3.2 操作手法
不要按部就班地点按钮，用脚本构造以下几种脏数据（Malformed Data），强行发给设备：
<S2F41><RCMD>START</RCMD><PARAMS><CPPPID>GHOST_RECIPE_999</CPPPID></PARAMS></S2F41><S2F41><RCMD>GET_SUBST_INFO</RCMD><PARAMS><CSLOTID>99</CSLOTID></PARAMS></S2F41><S2F41><RCMD>LOAD_COMPLETE</RCMD><PARAMS><CCARRIERID></CCARRIERID></PARAMS></S2F41>3.3 判定标准（合格 VS 劣质）
| 维度 | 合格接口 | 劣质接口（”假干活“） |
|---|---|---|
| 返回值 | 必须回Command Rejected | 回Command Accepted，假装执行成功。 |
| 副作用 | 不改变任何内部状态 | 可能创建了无效的Job或污染了数据库 |
核心逻辑：好的接口应该像”门神“，把错误的指令挡在外面，而不是照单全收。
四、第三招：极限时序（专治假并发）
4.1 痛点直击
单步操作没问题，一旦 Host 并发发指令，设备就开始抽风：丢事件、死机、或者状态机乱跳。这通常是因为设备内部的消息队列或锁机制设计有缺陷。
4.2 操作手法
不要按部就班，用脚本模拟极限场景，测试设备的抗压能力和状态健壮性：
- 疯狂查询：在 Robot 移动过程中，每秒发 10 次
S1F3 Selected Equipment Status。 - 强行插队：在设备执行
PROCESSING状态时，强行下发S2F41 PAUSE。 - 快速切换：在
ONLINE REMOTE和OFFLINE之间快速切换。
4.3 判定标准（合格 VS 劣质）
| 维度 | 合格接口 | 劣质接口（“假干活”） |
|---|---|---|
| 响应 | 能正确处理队列，或果断拒绝非法状态的指令 | 直接崩溃、重启，或进入UNKNOWN状态 |
| 队列 | 指令按顺序执行，无丢失 | 丢事件、乱序，或死锁 |
| 恢复 | 压力解除后能自动恢复正常 | 需要人工干预才能恢复 |
核心逻辑：Fab 环境是复杂的，设备必须能优雅地处理冲突和过载，而不是在压力下崩溃。
五、第四招：日志溯源（专治假事件）
5.1 痛点直击
软件界面显示Completed、S6F11事件也上报了，但晶圆实际上还在Load Port 里。这就是最恶劣的“假装成功”，因为它欺骗了 MES 和数据采集系统。
5.2 操作手法
要求是设备商打开Debug Log，并进行交叉验证：
- 时间对比：对比
SubstHistory的时间戳和 PLC 的 IO 信号变化时间。 - 逻辑比对：软件里报
Robot Pick Success，但 PLC 的Vacuum Sensor并未触发。 - 数据一致性：检查数据库中的记录是否与物理动作一一对应。
5.3 判定标准（合格 VS 劣质）
| 维度 | 合格接口 | 劣质接口（“假干活”） |
|---|---|---|
| 一致性 | 软件事件、PLC信号、数据库记录三者完全一致 | 软件显示成功，但是硬件无动作，或数据不一致 |
| 可追溯性 | Debug Log 详细记录了每一步的物理动作 | Log 中只有状态变化，无硬件交互细节 |
| 可信度 | 日志比界面可信，PLC比日志可信 | 日志和界面相互矛盾 |
核心逻辑：在 Fab 里，日志比界面可信，PLC 比日志可信。任何没有硬件支撑的软件事件都是“诈骗” |
六、总结：别信 Demo，信你的测试用例
不管是AI助手还是设备商，只要设计接口，都别听他们嘴上说“支持”。
拔网线、发脏数据、压并发、查日志。
这四招虽然粗暴，但是能帮你过滤掉90%的“假把式”。毕竟，在 Fab 里，没人关心你的Demo有多漂亮，大家只关心你能不能稳定跑完 99.99% 的晶圆。
你在 FAT 时还遇到过哪些“假装能干活的接口”？欢迎在评论区分享你的抓鬼经历，让我们一起精华 EAP 生态
