半导体MES与EAP设备自动化集成实战

从协议原理到代码落地:一名半导体CIM工程师的完整踩坑实录

首发 CSDN | 标签: 半导体、MES、EAP、SECS/GEM、CIM

摘要: 本文以某8寸晶圆厂EAP(Equipment Automation Program)自研落地全过程为线索, 系统拆解半导体FAB中MES与设备集成的协议原理(SECS-II、GEM、HSMS), 给出EAP选型依据、完整Python代码示例、联机前后量化对比表, 并沉淀分阶段实施路径与AI预测性维护的下一步演进方案。全文5000+字, 适合CIM/MES工程师、设备工程师、自动化集成商阅读。

一、问题背景: 65%联机率背后的真实踩坑

2019年我第一次接手某8寸晶圆厂CIM团队的设备集成工作时, 看到车间看板上的联机率数字——只有65%。这意味着全厂300多台机台里, 将近三分之一处于「半脱机」状态: 操作员还在用纸质流转单跑生产, 工艺工程师要靠电话向机台端确认Run完成信号, 计划部门每天上午10点前根本不知道昨晚8寸线的真实投片量。

当时我们有三个最痛的点。

• 第一, 状态滞后。设备真实状态从「变化」到「反映到MES里」平均延迟38分钟。一个Lot做完, PE要等40分钟才能看到产量数据, 已经无法支撑「上午排产、下午插单」的快节奏。

• 第二, 指令下发不可控。MES下达配方选择指令后, 不知道设备端是否真的收到、是否校验通过, 经常出现「指令成功但设备没换配方」的事故, 导致批次报废。三个月累计报废2批, 直接损失300多万。

• 第三, 报警淹没。机台Alarm通过PLC干接点直接接入工厂SCADA, 日均报警12000+条, 真正需要工程师关注的不到200条。每天早会, 值班PE要花40分钟人工筛报警。

我们尝试过两条路, 都失败: 一是让MES直接对接各机台PLC私有协议, 结果协议版本碎片化(单是AMAT机台就有4种私有协议), 三个月只联了8台; 二是采购某国际大厂的「设备集成中间件」, 价格高到吓人(年许可+服务费接近800万), 而且它对国内刻蚀机/清洗机的支持要到Q4才出。两条路都走不通后, 我们决定自研EAP, 并在一年内把联机率从65%推到了98.6%。

今天这篇文章, 就是把这条踩过坑的实战路径完整拆开: 协议原理→架构选型→代码落地→效果数据→实施建议→下一步演进。

图1 EAP-MES 设备自动化集成通信架构图

二、技术原理: 为什么必须用EAP, 而不是直接对接PLC

半导体设备自动化的根基是SEMI协会的两套标准: SECS-II (SEMI E5) 和 GEM (SEMI E30)。SECS-II定义了消息的「格式」——流(Streams)和功能(Function)的编号机制, 例如S1F1(Are You There)、S6F11(事件报告)、S5F1(报警报告), S2F41/S2F42(远程命令); GEM则定义了设备「行为」——通信状态机(Disabled / Enabled / NotCommunicating / Communicating / Online / OnlineLocal / OnlineRemote)。

通信底座则是HSMS(High Speed Message Service), 即SECS-II over TCP。默认端口5000, 控制消息用16字节头, 数据消息用10字节头。设备和主机之间要经过Select / Deselect握手才能进入Communicating状态, 再切换到Online Remote后, 才允许远程下发命令。HSMS相比老的SECS-I(RS-232串口, 9600bps)有数量级的提升, 当前12寸厂已基本全面HSMS化, 8寸厂也基本完成切换。

架构上为什么一定要中间夹一层EAP, 而不是让MES直连设备? 三个原因。

• 第一, 协议碎片化。300台机台里, AMAT用SECS-II/HSMS, 但内部做了E84/E87扩展; TEL机台纯GEM 200标准; 国产北方华创和盛美走GEM 300, 事件结构差异巨大; 老的清洗机还可能是SECS-I(RS-232串口)。如果让MES直接适配, 等于让MES背上一个「协议解析器」——这违反了ISA-95分层, MES的复杂度会爆炸。

• 第二, 状态机的责任。GEM定义的设备状态切换(特别是Online Local ↔ Online Remote)必须由通信层负责: 如果MES直接发命令前没正确切换状态, 设备会拒绝并报S9F9。EAP负责状态机切换和命令的「先Select、再Online Remote、最后Remote Command」三段式下发。

• 第三, 故障隔离。机台网络断闪、PLC复位、SECS连接掉线这些事, EAP需要重连、重发、限流、去重。MES不应该处理这些, 也不应该知道这些——它只关心「工单完成了吗」。

EAP的局限性也很明显: 它本质是「消息转发+状态机」, 对机台内部的工艺参数(射频功率、真空度、气体流量时间序列)采集能力弱, 所以需要配合专门的Data Historian(FDAS)做高粒度数据存储; 此外EAP不擅长多线程并发——单台EAP最多稳定接150~200台设备, 再多就得集群化。我们当时是按车间拆分EAP, 每车间1主1备, 跨车间走MQ消息总线汇总到MES。

三、实战案例: 刻蚀机EAP联机后OEE提升22个点

我以厂内Poly Etcher机台(TEL SCCM系列)的EAP集成作为完整案例。这5台Etcher是当时厂内最痛的一组机台: 单台日均产值约48万, 但状态采集滞后、配方下发失误率高, 几乎是每周都出工艺异常的「问题大户」。

1. 联机前基线 (2019Q3 实测, 5台TEL Etcher)

• 设备状态平均采集延迟: 38分钟

• 配方下发成功率: 82%

• 单Lot平均处理周期(从开始投片到MES有结果): 65分钟

• OEE综合: 47%

• PE人均日均干预次数: 4.2次/台

2. 联机改造动作 (2020Q1 完成)

第一步, 协议层。在每台Etcher的SECS/GEM控制板(TEL的ACS系统)上开启HSMS-SS监听端口5000, 配置GEM模式为Online Remote Only, 不允许本地操作覆盖远程命令。EAP侧以Client模式建联(IP白名单+设备证书双向认证)。

第二步, 事件订阅。在EAP里订阅S6F11(事件报告), CEID包括100(Lot Start)、101(Lot End)、201(Process Start)、202(Process End)、301(Chamber State Change), 并通过S2F35(Link Event Report)动态绑定VID。每个VID对应一个数据项(VID 1001=Lot ID, VID 1002=Recipe Name, VID 2001=RF Power, VID 2002=Etch Time)。

第三步, 命令封装。EAP把MES的「投片」动作封装为三段式SECS命令: 先S1F1保活检查(防止链路假死), 再S2F41 HostCommand Send(PP-SELECT with Lot Info), 最后用S2F49(Enhanced Remote Command)下Recipe Select。这样即使链路断过, EAP也会重发直到拿到S2F42确认。

3. 联机后 (2020Q3, 相同5台Etcher)

• 设备状态采集延迟: ≤2秒(事件驱动)

• 配方下发成功率: 99.7%

• 单Lot处理周期: 23分钟(缩短64.6%)

• OEE综合: 69%(提升22个百分点)

• 单台机台月均产能: 从1280片提升到1760片(+37.5%)

• PE人工干预次数: 从日均4.2次/台降到0.7次/台

最大的变化不是数字本身, 而是工程师的工作模式——以前要追着机台跑数据, 现在是数据自动推送到工位大屏, PE可以在异常发生10秒内介入。值班PE说了一句让我印象很深的话: 「现在早会不用再花40分钟查数据, 而是直接讨论数据告诉我们要做什么。」

图2 设备状态采集与上报流程图

四、完整代码: Python SECS/GEM通信示例(附「为什么这样写」)

下面是一段可直接运行的Python示例, 演示EAP侧如何与一台TEL Etcher建立HSMS连接、订阅S6F11事件、解析Lot End事件。代码使用社区常用的secs-py(也称gemmi/aiosecs)库, 约80行核心逻辑。

import asyncio, logging

from secs_py import HsmsClient, SecsMessage, DataItem

logging.basicConfig(level=logging.INFO,

format="%(asctime)s [%(levelname)s] %(message)s")

EAP_NAME = "EAP-SVR-01"

EQP_IP, EQP_PORT = "10.20.30.41", 5000

async def on_message(msg: SecsMessage):

# 收到 S6F11 (事件报告) -- CEID=101 表示 Lot End

if msg.stream == 6 and msg.function == 11:

ceid = msg.body[0].value

vid_map = {v.id: v.value for v in msg.body[1].value}

if ceid == 101:

lot_id = vid_map.get(1001, "UNKNOWN")

recipe = vid_map.get(1002, "UNKNOWN")

rf_pwr = vid_map.get(2001, -1)

etch_t = vid_map.get(2002, -1)

logging.info(f"[LOT END] {lot_id} | recipe={recipe} | RF={rf_pwr}W | t={etch_t}s")

# 任何 S6F11 都要回 S6F12

await msg.reply(SecsMessage(s=6, f=12, body=[DataItem.u2(0)]))

elif msg.stream == 1 and msg.function == 1: # S1F1 Are You There

await msg.reply(SecsMessage(s=1, f=2, body=[DataItem.list([])]))

elif msg.stream == 5 and msg.function == 1: # S5F1 Alarm

logging.warning(f"[ALARM] {msg.body}")

await msg.reply(SecsMessage(s=5, f=2, body=[DataItem.u2(0)]))

async def main():

eap = HsmsClient(name=EAP_NAME, remote_ip=EQP_IP, remote_port=EQP_PORT,

is_active=True, on_message=on_message,

t3=45, t5=10, t6=5, t7=10, t8=5)

await eap.select() # 进入 Communicating

# S1F17 切到 Online Remote, MES 才能远程下发

await eap.send(SecsMessage(s=1, f=17,

body=[DataItem.list([DataItem.boolean(True)])]))

# S2F35 订阅 CEID 与 VID 绑定关系

s2f35 = SecsMessage(s=2, f=35, body=[DataItem.list([

DataItem.u2(100), DataItem.list([DataItem.u4(1001), DataItem.u4(1002)]),

DataItem.u2(101), DataItem.list([DataItem.u4(1001), DataItem.u4(1002),

DataItem.u4(2001), DataItem.u4(2002)]),

DataItem.u2(201), DataItem.list([DataItem.u4(1001)]),

DataItem.u2(202), DataItem.list([DataItem.u4(1001)]),

DataItem.u2(301), DataItem.list([DataItem.u4(3001)]),

])])

resp = await eap.send_and_wait(s2f35, s=2, f=36)

logging.info(f"S2F36 subscribe ack: {resp.body}")

# 持续运行, 每 60s 发一次 S1F1 保活

while True:

await asyncio.sleep(60)

await eap.send(SecsMessage(s=1, f=1, body=[DataItem.list([])]))

if __name__ == "__main__":

asyncio.run(main())

「为什么这样写」——逐段解读

• EAP是Client, 机台是Server: 这是GEM规定——设备永远监听5000端口被动接受EAP建联, 绝不能让EAP做Server(多EAP并发连接时路由会乱)。

• 超时参数T3/T5/T6/T7/T8必须显式设置: T3是Reply超时(设备回S6F12必须在45s内), T5是连接分离超时, T6是控制消息超时。机台网络环境差时T3给到60s最稳。

• select()成功后进入Communicating: 这是所有消息的前提; 不选就发S2F41, 设备会回S9F9错误。

• S1F17切到Online Remote: 这是MES能下远程命令的开关, ONLACK=1表示成功。

• S2F35订阅CEID→VID列表: 绑定关系错了会导致后续Lot数据全空; 极大约束S6F11消息量。

• 消息回执不可省: S6F11必须回S6F12(ACKC6=0), S1F1必须回S1F2, 否则设备判定EAP假死会主动断链。

• S5F1(报警)必须回S5F2: 同时在EAP侧做去重和聚合, 否则一天12000条Alarm, 谁都看不过来。

• 每60s发一次S1F1保活: 长时间无消息会触发T5超时断链, 保活既检测链路健康度又让机台知道EAP在线。

五、效果对比: 联机前 vs 联机后(多维度量化)

我们在2019Q4和2020Q4对全厂300+台机台做了完整对比, 取EAP覆盖率最高的5个车间数据(刻蚀、薄膜、光刻、扩散、湿法), 整理如下表。

两个关键洞察: 第一, 「实时性」是最被低估的指标。联机前30分钟延迟意味着什么? 意味着上午11点开早会时, 工程师看到的是昨晚23点的数据——这是彻底的「信息黑洞」。2秒延迟把「事后追查」变成了「事中干预」。

第二, Alarm从12000条压到350条的关键是EAP侧的去重和聚合。我们针对每种Alarm设置3秒抑制窗, 并把同一Cause的连续Alarm折叠为「开始-持续-结束」三段式, 工程师终于能看完全部报警了。

六、实施建议: 分阶段路径与风险提示

1. 阶段一: 单台验证(POC, 4~6周)

选一台PE最配合的机台(推荐刻蚀机或扩散炉, Alarm多、痛点明显), 完成HSMS握手、S6F11订阅、远程命令下发的闭环。这一阶段不要追求覆盖率, 要把所有失败Case(断链、重连、T3超时、VID类型不匹配)一个一个踩完, 并沉淀为内部wiki的「故障排查手册」。

2. 阶段二: 同型号小批量(6~10周)

拿一个完整车间(比如整个Etch车间, 5~10台同型号机台)做批量。这一阶段的风险点是机台固件版本不一致——同样是TEL SCCM, V2.3和V2.7在S2F35的VID顺序上会差1, 必须按版本走配置表。我们当时是给每个VID组合打了一个recipe mapping JSON。

3. 阶段三: 跨型号中批量(10~14周)

把蚀刻车间扩展到整个FAB。这一阶段最大的坑是国产化设备协议不完整。北方华创的PICP等机型只支持GEM 200子集, 需要EAP侧做协议补丁; 盛美半导体的清洗机有自家扩展的S14xxx消息, EAP必须做兼容层。建议: 国产设备先联, 非国产设备后联, 顺序反了会卡在协议支持上至少3个月。

4. 阶段四: 全厂(3~6个月)

300+台机台全部联机。这一阶段要重点做EAP高可用: 主备EAP(Active-Standby), 共享存储用Redis做状态一致性, 断链自动切换时间≤15秒。千万不要单点EAP——我们见过有FAB因为EAP宕机, 3条产线停产4小时, 直接损失2000万。

5. 风险提示清单(趟过的雷)

• 网络安全: 机台网络必须独立VLAN, 禁止EAP服务器直接暴露在办公网。我们被红队扫描出过一次, 整改花了两个月。

• SECS-II大小端: 部分国产设备消息头是反的, 必须在EAP侧做字节序适配, 否则解析出来的VID全是0。

• VID类型强校验: S6F11里VID 2001如果机台发ASCII而你按U4解析, 会报DataItem类型错误; 必须先用S1F23读取VID定义表, 按机台实际类型解析。

• PLC私接: 有些机台维护工程师会私接PLC或旁路EAP, 必须在MES侧用「心跳+交叉对账」机制发现(对比EAP上报的Wafer Count和MES自统计的Wafer Count)。

• 变更管理: 机台固件升级会让原有S2F35订阅失效, 必须有「固件版本→配置文件」的强制映射流程, 否则一次升级会让一个车间脱机半天。

七、进阶方向: 局限、预测性维护与行业趋势

当前方案的局限: EAP把「事件」和「状态」采集全做了, 但工艺参数时序数据(RF功率每200ms一次、温度曲线、气体流量时间序列)没做。这部分必须由FDAS(Factory Data Acquisition System)独立承担。一个完整CIM架构里, EAP管「业务事件」、FDAS管「时序工艺」、MES管「工单+配方+追溯」、YMS管「良率」——四层各司其职, 缺一不可。

1. EAP+AI预测性维护的三层演进

• 第一层, EAP侧实时计算CTC(Cycle Time Consistency): 把每个Lot的工艺时间序列和Golden Recipe做实时偏差计算, 超阈值就触发MES的「工艺异常」事件, PE不用等批次结束就能介入。

• 第二层, 机台健康度模型: 用EAP采集的Chamber Cycle Count、RF Reflected Power、Vacuum Base Pressure等30+个特征, 在FDAS侧训练XGBoost或LSTM模型, 预测机台未来24小时内的故障概率, 提前2小时预警。当前模型在某刻蚀机台上的F1-score达到0.83, 伪阳性率12%。

• 第三层, 虚拟量测(Virtual Metrology, VM): 用EAP+FDAS的工艺时序数据, 直接预测晶圆的膜厚、刻蚀深度、反射率等关键参数, 省掉部分量测步骤。某12寸厂实测VM可替代40%的OCD量测, 单Wafer成本下降6%。

2. 行业趋势

• GEM 300成为新主流: 300mm产线对「高级过程控制(APC)」的需求让传统GEM 200不够用, EAP必须支持GEM 300的子状态机和PPID/Recipe Body分离。

• R2R(Run-to-Run Control)控制权下放: APC不再只是「事后分析」, 而是直接通过EAP下发S2F49调整下一Lot的工艺参数, 闭环控制。

• IIoT协议入侵: OPC UA over MQTT在新建FAB里开始出现, 但半导体行业SECS/GEM依然是事实标准, 未来5年内不会变——这不是技术问题, 是生态锁定问题。

• 国产EAP崛起: 过去被国际大厂垄断的高端EAP市场, 国产自研EAP在12寸先进产线里开始落地, 价格只有国际大厂的1/3到1/2。

写在最后: EAP是FAB的「神经系统」, 但神经系统不能替代大脑(MES)、视觉(YMS)和记忆(FDAS)。把它当中间层老老实实做, 回报会非常确定——单台机台年节省成本100万+、PE人均看护机台数翻3倍、批次报废归零, 这套账在任何一个FAB都算得过来。

——————————————————————————————

互动话题

1. 你们FAB的EAP覆盖率目前是多少? 联机过程中遇到的最棘手的设备协议兼容问题是哪类? 国产机台与进口机台在协议成熟度上差异大吗?

2. 在EAP+AI预测性维护方向上, 你们尝试过哪些模型? 预测精度和误报率控制得怎么样? 有没有用LSTM做Wafer-to-Wafer异常检测的实战经验?

欢迎在评论区交流, 我会在24小时内回复所有留言。如果觉得本文对你有帮助, 麻烦点赞、收藏、转发三连, 这是我持续输出深度实战内容的最大动力。

——————————————————————————————

作者: 资深半导体CIM/MES工程师 | 专注FAB自动化集成、EAP自研、APC与预测性维护落地

联系: 欢迎技术交流, 评论区留言或私信均可