1. 配方管理在半导体设备里的真实分量它不是存参数这么简单大概两年多前我在一家半导体设备厂商做前道工艺设备的控制软件改造接手时最先炸掉的问题就是配方管理。车间里几十台同类设备每台设备本地硬盘上都堆着一堆工艺配方文件有的是工程师调的有的是操作员现场改的文件名五花八门什么finnal_v3、final_v3_ok、真的不改了_v2都有。同一款产品在A机台跑得好好的挪到B机台就跑偏最后查下来是B机台当前生效的配方和A机台差了零点几帕的压力参数而且没有任何记录能说清楚这个值是什么时候被谁改掉的。那时候我就意识到配方管理系统在半导体设备里承担的角色远比存几组参数要重得多。半导体工艺设备比如刻蚀机、薄膜沉积设备、离子注入机每一片晶圆经过腔室时都要按照一组精确参数执行工艺这组参数就是配方。温度、压力、气体流量、射频功率、工艺时间每一项都直接影响膜厚均匀性、刻蚀速率、颗粒缺陷率。工艺窗口可能只有几个百分点配方里一个小数点后两位的偏差在批量生产里就是整批报废。所以这套系统的核心需求可以拆成四层第一配方必须能被安全地创建、编辑、存储和下发不能靠人工拷贝文件第二配方从服务器到设备、从装载到生效必须有完整的校验和互锁防止脏参数进工艺第三谁改了什么、什么时候改的、为什么改每一步都要可追溯这是半导体工厂审计的基本要求第四配方数据必须能和上位系统比如MES制造执行系统、EAP设备自动化平台顺畅对接让配方跟着产品流转而不是靠操作员手输。这篇文章讲的就是我们基于TwinCAT平台搭建整套配方管理系统的技术方案。我会把架构设计、数据模型、核心功能实现、权限与追溯、MES对接以及实测中踩过的坑完整梳理一遍。适合正在做半导体设备控制软件、精密制造设备自动化改造或者被配方版本混乱折磨过的工程师参考。2. 架构选型为什么把配方管理的核心压在TwinCAT上先回答一个经常被问的问题配方管理听起来是软件层面的事为什么不能用一台普通的工控机靠文件共享或者数据库系统去管非要扯上TwinCAT这种实时控制平台这个问题的核心在于配方的生命周期和设备的实时状态是深度绑定的。一个配方不是交到设备手里就结束它需要被解析成PLC程序能直接使用的参数结构需要在设备处于特定状态下才能被装载需要在工艺启动前完成校验还需要在工艺执行过程中被监控。如果配方服务跑在一套和实时控制器完全割裂的系统里配方下发后的装载时机、生效确认、失败回滚这些动作就很难和设备的顺序控制、报警互锁协同起来。TwinCAT在这类场景里的优势可以总结成三点。第一TwinCAT的ADS通信协议打通了实时层和非实时层。配方管理服务可以跑在Windows侧的应用程序里比如C#写的后台服务通过ADS和TwinCAT PLC里的配方装载函数块通信。PLC负责状态机互锁和参数生效上位服务负责配方存储、版本管理、权限校验和MES接口两边各干各擅长的事又通过ADS保证低延迟和可靠性。第二TwinCAT 3本身提供了很完整的软件生态环境。除了实时PLC核它还支持TwinCAT HMI做网页可视化、支持TF6420之类的数据库接口、支持OPC UA服务器配方管理服务需要的基础组件基本都能在同一个平台上找到不用把系统拼成一个大杂烩。第三半导体设备很多需要遵循SEMI标准比如配置管理、状态机定义、远程命令接口。TwinCAT的灵活性让这些协议栈可以以软件模块的方式集成进来配方管理和SECS/GEM通信可以用同一套数据源避免了两套系统各存一份配方、同步全靠手工的尴尬局面。我们的最终架构分为三层。最底层是TwinCAT实时控制层跑在专用的嵌入式控制器上负责腔室顺序控制、配方参数装载、工艺过程执行和联锁保护。中间层是配方管理服务层跑在设备的上位工控机或者独立的Edge服务器上基于.NET开发负责配方库管理、版本控制、权限校验、日志审计、和MES/REST接口通信。最上层是交互层用TwinCAT HMI提供配方的浏览、编辑、下发操作界面支持权限分级操作员看到的界面和工程师看到的界面功能完全不一样。ADS通信在中间层和底层的交互中承担了三个关键任务配方参数块的整体下发、装载和激活命令的同步握手、配方运行状态的实时反馈。参数块整体下发我用的是ADS的符号化读写能力把PLC侧定义好的配方结构体作为数据块地址服务端直接把整个结构体写过去然后用一个数据块版本号字段来校验写入是否完整、新旧是否匹配。激活命令的同步握手则是通过PLC侧的状态机完成——服务端发一个装载请求PLC确认当前设备状态允许装载后反馈一个装载完成信号服务端再发激活请求PLC执行激活并返回结果。整个过程有超时保护和失败回滚不会出现服务端以为配方激活了、PLC实际上没加载这种割裂情况。3. 配方数据模型设计一个配方到底该存些什么配方数据模型是整个系统里最需要想清楚的部分。很多老设备把配方做成一个扁平参数列表几百个参数平铺在一个文件里数字靠顺序对应位置。这种设计在只有几十个参数的年代够用但半导体设备的配方参数动辄几百个还分工艺参数、设备参数、控制参数、跟随参数如果不用结构化的方式建模后面做权限、做校验、做版本diff都会很痛苦。我设计的配方模型分为四层配方头、参数分组、参数项、量纲与校验规则。配方头记录元信息包括配方编号、配方名称、产品型号、工艺步骤编号、所属机台型号、配方版本号、创建人、修改人、创建时间、修改时间、状态标记。这里有一个关键设计配方编号不是自增ID而是语义化的编码比如PROD-CARRIER-PREDEP-001这种。配方编号生命周期内不变但版本号会随着每次修改递增旧版本不会被删除而是被标记为已归档。参数分组层解决的是几百个参数的归类问题。一个典型的薄膜沉积配方可以分成热场参数组各温区温度、加热功率、气流参数组各管路流量、气体种类比例、压力控制参数组腔室压力、节流阀开度、射频参数组上电极功率、反射功率保护阈值、时间序列参数组各工艺步骤的持续时间、终点检测参数组光学发射谱检测使能、检测波长。分组的好处是有三层第一配方编辑界面可以按组折叠展开工程师不会面对一屏幕的裸参数第二权限可以细化到参数组比如工艺工程师只能改时间参数设备工程师才能改硬件配置第三不同产品配方的差异对比可以在组级别快速定位。参数项层是配方数据的原子单元。每个参数项必须包含参数标识符、参数名、数据类型浮点、整数、布尔、枚举、字符串、单位、当前值、下限值、上限值、步进值、是否跟随配方切换、是否允许在线修改。这个结构是我特别强调的因为参数不仅仅要有值还要带完整的边界信息和修改策略。下限上限用于下发前的边界校验步进值用于检查参数值是否落在合法的网格上比如某个气体流量步进精度是0.1 sccm工程师填了个0.15 sccm校验就该报错。是否允许在线修改则区分了只能在设备空闲时改和在工艺运行中可以微调的参数后者在半导体设备里很常见比如某些工艺步骤的终点检测阈值需要操作员根据现场情况调整。量纲与校验规则层是容易被忽略但极其重要的设计。配方参数不能只有数字还必须带上单位换算和换算基准。举个例子某个设备的腔室压力可以用Torr也可以用Pa来显示配方存储层统一使用标准单位Pa界面上按操作员的偏好显示Torr下发时再转成PLC侧期望的原始工程量。如果不做这一层早晚会出以为填的是Torr实际按Pa存了的工艺事故。关于配方文件的存储格式我推荐使用结构化的JSON格式作为配方交换格式配以XML Schema或者JSON Schema做结构校验。选JSON而不是自定义二进制最大的好处是版本对比和问题排查容易得多两个版本之间的差异可以用文本diff直接看出来不像二进制文件那样得写专门的解析工具。PLC实时层不直接解析JSON它用的是预先定义好的结构体数据块配方服务负责把JSON转换成结构体二进制。这样既保留了外部格式的可读性又保证了实时层的性能。存储介质上我们的方案是三层存储。运行配方存放在PLC非易失存储区保证断电后设备能恢复到最近一次正常运行的配方状态活动配方库存放在上位机的SQLite数据库里存放当前所有在用配方的最新版本归档配方库放在文件服务器或者MES侧的共享路径里存放所有历史版本。这里的经验是千万不要只依赖数据库做唯一存储一定要保留文件形式的存档副本因为数据库可能崩溃但配方文件拷出来了就是拷贝出来了即使是归档文件也能救急。4. 配方管理核心功能拆解从创建到生效每一步都要卡得住整体功能从使用流程上分可以做这么几个大块配方创建与编辑、配方校验与审批、配方下发与装载、配方激活与运行、配方监控与反馈。每一步都需要把规则和异常考虑进去。配方创建与编辑这块我们支持两种入口。第一是在线编辑工程师在HMI界面上复制一个基础配方修改参数分组里的若干项系统自动更新版本号和修改记录。第二是批量导入工程师把配方参数整理成Excel或者CSV文件通过Web界面上传系统先做格式解析、再逐项做边界校验导入完成后生成一份导入报告。批量导入这个功能在导入初始配方库的时候太关键了几百条配方靠手敲不现实。编辑过程中真正打磨细节的是参数校验反馈的交互设计。用户修改完一个参数项把光标移开时系统立刻做一次该参数项的独立校验包括类型、范围、步进、依赖关系校验不通过该参数项边框标红并给出提示整个配方保存或者提交审批时再做一次全配方级的交叉校验比如工艺总时间不能超过设备最大工艺时间工艺温度必须在腔室材料允许范围内这类涉及多个参数组的规则。交叉校验规则不能hardcode写在界面代码里我用了一个规则配置文件用表达式来描述依赖关系例如IF step_mode PLASMA THEN rf_power_min 50这样新增规则不需要改代码。校验通过之后进入审批环节。半导体产线一般有明确的分级权限工艺工程师编辑的配方需要工艺主管审批后才能下发到生产设备。审批流程我们做成了服务端的软状态机配方状态依次是Draft草稿→Submitted待审批→Approved已批准→Released已发布→Deprecated已废弃。每一个状态转换都写入审计日志并且只有Released状态的配方才能被生产设备下载。这个状态机是整个配方管理的交警没有它所谓权限管理就是摆设因为工程师改完配方直接下发的事会屡禁不止。配方下发与装载这一步是PLC侧协同最紧密的地方。我做了一个三阶段握手协议。第一阶段是数据预下载。配方服务把JSON格式的配方解析成PLC配方结构体通过ADS写入控制器的待装载配方区写完后读回数据块的关键校验字段做回读比对确认数据和预下发一致。这个阶段不会影响设备当前运行状态可以在工艺间隙提前完成。第二阶段是装载确认。操作员或者上位系统发起装载命令PLC状态机检查设备状态是否允许配方便装载比如设备必须在Idle状态、腔门必须关闭、真空度必须达到安全条件。条件满足后PLC把待装载配方区的数据复制到运行配方区复制完成后置位装载完成标志并反馈装载时间和校验结果。这里有一个关键细节装载操作必须设计成幂等操作也就是说用户重复点击装载不会产生叠加效应PLC侧要对重复装载请求做状态判断已有有效配方时返回No Action而不是重复执行。第三阶段是激活执行。装载完成并不等于配方生效真正开始工艺时配方才被激活。这一步通常是由设备的主工艺宏命令触发PLC读取运行配方区数据逐项检查关键工艺参数是否在设备硬件允许的范围内比如射频功率上限不能超过匹配器额定值、气体流量总和不能超过MFC量程全部通过后才允许工艺启动。如果激活失败PLC自动回退到上一个可用配方并上报一条带错误码的报警。我们曾经遇到过一种情况工程师在设备运行中远程修改了配方但PLC侧运行的还是旧配方操作员看到的是新配方实际工艺用的是旧参数这种显示与生效分离的隐患就是靠激活前强制回读运行配方区版本号解决的。配方装载到运行之后还要有运行监控反馈。PLC在工艺执行过程中周期性把当前配方号、配方起始时间、累计运行时间、关键参数当前值和设定值的偏差上报给配方服务服务端把这些数据和设备状态关联存储。一旦参数偏差超过设定阈值服务端会产生偏差报警并记录当时的完整工艺参数快照。这个快照是后期工艺问题回溯的第一手数据比事后补写的报告可靠得多。5. 权限、版本与追溯把谁改了配方变成无法抵赖的事实配方管理系统如果只有功能没有纪律用不了多久就会退回人治状态。我们花了很大精力在权限、版本、追溯三个方向上做严格管控这三个维度又是互相咬合的。权限模型设计成三级加两类的结构。三级是操作员、工艺工程师、系统管理员继承关系是操作员最小、工艺工程师居中、系统管理员最大。两类是功能权限和数据权限。功能权限控制的是能做什么操作比如创建、编辑、删除、审批、下发、导出数据权限控制的是能碰哪些配方比如某个工程师只能编辑负责的产品线配方别的产品线配方只有只读权限或者不可见。操作员的权限通常限定为查看当前配方、切换已发布配方、运行中调整允许在线修改的参数工艺工程师可以创建编辑配方、发起审批、查看版本历史和对比系统管理员负责账号管理、审计日志导出、配方库的备份恢复和系统级配置但有意思的是系统管理员反而不能编辑工艺配方这是半导体行业很常见的职责分离原则管系统的不能碰工艺管工艺的不能动系统防止利用管理员权限掩盖工艺修改记录。权限模型落地的技术细节上我们采用了角色-权限-资源三层映射。用户登录后服务端发放一个安全令牌令牌里包含角色标识和资源范围列表每个API请求都会校验令牌里的角色权限和资源范围。HMI端根据权限动态渲染界面元素没有权限的按钮直接隐藏而不是灰置这样也减少了一部分看着能用但点下去报错的困扰。版本控制这块我们在配方服务端实现了一个类Git的设计思路简化版。每次配方的保存或者状态变更不是覆盖原记录而是生成一个新版本记录存储完整配方数据和变更摘要。变更摘要包括变更人、变更时间、变更类型、变更原因填写框、变更涉及的参数组列表。新增的这个变更原因填写框我们特意设计成了必填项就是为了逼着工程师留下为什么改的信息。版本对比功能允许用户选择任意两个已发布版本并排查看差异差异高亮到参数项级别老值、新值、单位、改动人一次性展示。这里有个实际教训配方版本对比不能只对比数值差异还得对比单位差异和校验规则差异。有一次我们发现某设备新旧两个配方温度参数都是500但新版配方悄悄把单位从摄氏温度换成了设备内部工程量单位数值一样实际物理量差了100倍。所以版本快照必须把参数项的量纲元数据一起存进去对比的时候单位不一致直接标红提示。关于审计追踪我们记录了两种日志。一种是操作日志面向业务流程记录了谁在什么时间对哪个配方做了什么操作结果成功还是失败用于日常问题排查。另一种是合规日志面向审计要求记录了配方在全生命周期中的每一次状态流转和每一次参数值变更这是一套完整的证据链按半导体客户的审计要求通常要保留三年以上或者跟随设备终身。合规日志的内容特意做了防篡改设计日志记录追加了哈希链每条记录的哈希值由上一条记录的哈希值加上本条记录内容计算得到任何人试图修改中间某条记录哈希链的完整性校验就会失败。这个方案不复杂但确实有效我们用三个月后工程师发现再也神不知鬼不觉地改配方了因为每条改动都带着完整的上下文躺在审计日志里。配方备份与灾难恢复方面我们的经验是三级备份、定期演练。第一级每台设备的配方库每天自动备份到本地指定目录保留最近七天第二级每周把全量配方库备份到集中文件服务器保留最近四周第三级每月导出归档快照保存到离线存储保留至少一年。灾难恢复不能只做备份不演练我们每季度做一次恢复演练选取一台设备模拟控制器存储介质损坏然后从备份恢复配方库和运行配方验证恢复后配方的校验结果与备份时完全一致。这里有个容易被忽略的细节备份内容不能只备份配方数据文件还必须包括配方数据模型定义文件也就是参数项的定义、单位、上下限、校验规则等元数据。因为设备软件版本升级后参数结构可能变化如果没有元数据备份旧配方数据即使恢复出来也可能因为参数定义不匹配而无法装载。6. 与MES/SECS/GEM的协同配方跟着产品走而不是靠人喊半导体设备不是孤立运行的它要接受MES的调度和EAP的远程控制。配方管理系统在这里的角色是中间人MES说接下来这片货需要执行配方PROD-ETCH-003版本为当前Released版本配方服务就要把对应的最新已发布配方准备好下发给设备然后回报MES配方已就绪可以开始加工。在这个协同场景里我特别想强调一个设计理念MES不应该直接指定某一个具体版本号要求设备执行而应该指定配方逻辑名版本策略。因为配方版本随时可能因为工艺改进被更新如果MES里写死了版本号每次配方更新都得去改MES的流程配置那是运维噩梦。我们的版本策略支持两种模式固定版本模式用于关键工艺批次控制比如MCU产品要求必须使用版本的配方不允许用更新版最新发布模式用于常规生产MES下任务时只要指定产品名称对应的配方逻辑名配方服务自动解析当前Released状态的最新版本。这个设计让产线上更换配方版本变得灵活又保留了关键产品的版本锁定能力。SECS/GEM是半导体设备通信的常见协议栈对配方管理而言核心是S7F1/S7F2这条动态互操作命令组以及S7F3/S7F4这类处方参数上传下载命令。我们通过一个SECS/GEM协议转换服务把配方服务的能力映射成标准SECS消息EAP通过S7F3远程下载配方、通过S7F4上传设备当前配方、通过S6F11上报配方切换事件等。要做到这套映射协议转换服务自身必须维护一份逻辑配方名→实际配方文件的映射表并且能在收到远程命令前先做EAP侧的权限校验防止产线中控绕过本地权限体系直接改配方。这里有一个我踩过的大坑SECS/GEM的配方传输往往是逐个参数进行的一个几百参数的配方通过S7F3传下来配置不好的话可能要好几秒钟。第一次联调时我们就因为这个跟客户的EAP吵起来对方说你们配方传输太慢了拖慢了产线节奏。后来我们改成先传配方元数据再按参数块批量传并启动了压缩模式传输时间从四秒降到不到一秒才算解决了问题。如果你也在做类似集成提前想清楚配方参数块级别的通信设计能少很多扯皮。离线运行与在线联动的折中方案我觉得值得展开一说。半导体工厂的网络并不总是稳定可靠的有些车间在设备调试阶段根本还没接入MES设备要也能正常运行。我们的设计是在线时以MES/EAP为准离线时以设备本地为准恢复后再比对同步。设备侧永远维护一个最近一次成功执行配方的本地缓存离线时操作员可以在设备本地选择已发布的配方缓存来执行网络恢复后配方服务会做一次状态对账把离线期间执行过的配方、工艺结果和本地版本号重新上报MES并把MES侧更新的配方版本同步到设备。这个对账功能上线后我们产线在MES短暂故障期间的运行基本无缝衔接了不会因为断网就整条线停摆。7. 实测中的关键坑配方切换时机、大数据量下发与多机台一致性这一章不聊理论聊我们真刀真枪跑出来的问题每一个都在现场花过不少时间排查。配方切换时机和设备安全互锁是我见过的导致设备报警最多的一类问题。典型的场景是操作员在设备正在做腔室预清洗的时候点了配方下发或者上位系统在设备状态还没回到Idle时发了装载命令PLC侧如果没有一套完整的状态机保护轻则装载失败报警重则干扰正在进行的工艺步骤。我们的对策是把配方装载动作和设备的授权状态机深度绑定设备只有在Idle、Ready、Paused有限几个状态允许配方装载在Running、Cleaning、Maintenance状态下一律拒绝并返回带状态码的拒绝原因。配方激活则只能在设备状态为Ready、且没有未完成的工艺任务时允许执行。此外任何可能改变配方执行参数的操作在工艺运行中会触发互锁提示——运行中只允许调节标记为允许在线修改的控制参数其他参数一概锁定。大数据量配方的实时性瓶颈这个问题在功能验证阶段没暴露在性能测试阶段才显现。我们有一款设备的配方参数列表做到了一千多个参数项用传统的型号逐个字段写入ADS单次下发要两秒多。半导体设备对配方切换时间的容忍度一般在一秒以内这一度让方案看起来不可行。后来我们换成了结构体批量写入把整个配方数据块作为一个ADS符号一次性写入并且开启了ADS的批量数据模式时间从两秒多降到了一百几十毫秒。这个优化告诉我们一个道理ADS逐字段写入方便调试但投产前一定要做性能摸底批量写入通常能带来数量级的提升。多机台配方一致性管理是产线级部署时冒出来的问题。一套管径上同一型号可能有多台设备理论上配方应该一致但实际中各台设备可能有硬件配置差异比如某台设备的MFC量程不同、加热器分区数量不同直接用同一份配方反而会出错。我处理这个问题的方式是引入配方模板设备实例覆盖概念模板定义这个产品工艺的标准参数设备实例覆盖存储该机台特有的硬件适配参数比如某些阀门的开度补偿、某腔室的压力偏置。下发到具体设备时系统先加载模板配方再合并覆盖参数生成该机台实际执行的物理配方。这个机制上线后多机台配方的维护量大幅下降工程师不需要再维护N份几乎相同的配方文件只需要维护一份模板和少量的覆盖率参数。还有一个容易忽略但严重影响验收的细节是PLC存储空间的限制。老一些的控制器非易失存储区可能只有几百KB存储配方结构体数组时如果设计不当配方区空间不够用会导致装载失败。我们最终采用的方法是在PLC侧只保留当前运行配方和待装载配方两个完整的配方槽其余配方全部存储在配方服务端需要时再下载。这样PLC存储占用是常数级的不随配方总数增长无论配方库有多大控制器本地存储都不会成为瓶颈。最后分享一个跟界面设计相关的经验。配方管理系统的HMI界面最容易做过度花哨。我们早期加了各种动态背景色、图表动画看起来酷炫但在车间里反而被现场工程师反馈看着累找不到功能。后来我们把界面改成了极简的列表详情布局配方列表按产品线分组点开配方直接显示参数分组表格表格上方放版本信息和校验状态所有操作通过明确的按钮触发。改完以后用户的接受度明显提升这也算是一个少即是多的实践认证。如果你正在规划自己的配方管理系统我的建议是先别急着写代码先把参数数据模型和状态机设计清楚把权限模型和审计要求从客户那里逐条问明白再考虑代码层怎么实现。数据模型设计错了后面每修一次都要牵一发动全身。状态机没锁住配方乱改的问题就永远堵不住。至于编程语言和具体平台都是次要的思路和纪律才是这套系统的核心。
