4. TEL Recipe开发环境与工具链
在 TEL（Tokyo Electron）涂胶显影、清洗、热处理等机台上，Recipe 不是一份孤立的文本文件，而是由机台控制软件、离线编辑工具、仿真验证工具、数据采集系统以及工厂级 MES/EAP 共同支撑起来的一套工程对象。理解这套工具链的边界与接口，是 Recipe 开发能否顺利从"离线编辑"走到"量产验证"的前提。本节围绕机台操作界面、Recipe 编辑软件、离线仿真工具、数据采集与 MES/EAP 接口、版本管理与权限控制五个部分展开，重点说明它们各自承担什么职责、彼此之间传递什么数据，以及在实际开发中如何配合使用。
一、机台操作界面：Recipe 的最终执行与现场确认入口
TEL 机台的操作界面（通常称为 OUI 或机台 HMI）是 Recipe 真正被加载、执行和观察的场所。它一般提供几个关键区域：Recipe 选择与加载区、单元状态监视区、报警与事件区、手动操作区。开发人员在离线工具中编辑好的 Recipe，最终要通过机台界面加载到对应单元（如涂胶单元、显影单元、热板单元）并执行。
机台界面上的 Recipe 通常以"程序号 + 名称 + 版本"的形式呈现。加载时需要注意：同一 Recipe 可能包含多个单元的子配方（例如涂胶单元的转速曲线、热板的温度曲线），机台界面会按单元分别显示其参数摘要。现场确认时，开发人员应重点核对三类信息：一是 Recipe 版本号是否与预期一致；二是各单元参数是否被正确解析（例如转速、温度、时间是否落在合理范围）；三是执行过程中报警区是否出现与 Recipe 相关的异常代码。机台界面本身一般不作为主要编辑工具，它的价值在于"执行确认"和"现场微调"。
二、Recipe 编辑软件：离线开发的主战场
Recipe 编辑软件（如 TEL 提供的离线编辑环境）是开发人员主要的工作界面。它通常以工程（Project）为单位管理 Recipe，支持参数编辑、步骤编排、单元配置和注释填写。与机台界面相比，编辑软件的优势在于：可以批量修改、可以对比不同版本、可以在不占用机台的情况下完成大部分编辑工作。
在实际使用中，编辑软件一般会区分"参数层"和"步骤层"。参数层定义具体数值，例如涂胶转速 1500 rpm、热板温度 110 ℃、显影时间 60 s；步骤层定义这些参数按什么顺序、在哪个单元、持续多长时间执行。开发时应遵循一个基本原则：参数值尽量通过变量或配方表引用，而不是在步骤中硬编码，这样后续调整时只需改一处。编辑完成后，Recipe 通常导出为机台可识别的格式（如特定扩展名的配方文件或通过接口下发），再导入机台。
三、离线仿真工具：在不上机的前提下验证逻辑
离线仿真工具的作用，是在 Recipe 真正下发到机台之前，对步骤顺序、参数范围、单元依赖关系进行静态或半动态检查。它不能替代真实工艺验证，但可以提前发现明显的逻辑错误，例如：某一步骤引用了不存在的单元、温度设定超出该单元允许范围、步骤之间的等待时间与机械传输时间冲突等。
使用仿真工具时，通常需要提供三类输入：Recipe 文件本身、机台配置模型（单元数量、类型、能力范围）、以及可选的工艺约束文件（如温度上下限、转速上下限）。仿真输出一般包括：步骤序列检查结果、参数越界清单、单元占用冲突提示。开发人员应根据这些提示回到编辑软件修改，而不是直接上机试错。需要强调的是，仿真通过不等于工艺合格，它只解决"逻辑与范围"问题，不解决"实际膜厚、均匀性、缺陷"问题。
四、数据采集与 MES/EAP 接口：Recipe 与工厂系统的连接
在量产环境中，Recipe 并不是由工程师手动在机台上逐个加载的，而是通过 MES/EAP 系统进行调度和下发。EAP（Equipment Automation Program）负责机台与工厂系统之间的通信，MES 负责工单、批次和 Recipe 的绑定关系。典型的数据流是：MES 根据产品与工序确定应使用的 Recipe 名称或 ID，通过 EAP 下发给机台；机台执行后，将执行结果、报警、关键参数实际值回传给 EAP，再汇总到数据采集系统。
数据采集系统通常记录以下几类与 Recipe 相关的数据：Recipe 加载记录（谁、何时、加载了哪个版本）、执行过程中的关键参数实际曲线（如实际温度、实际转速）、报警与事件日志、以及批次与 Recipe 的对应关系。这些数据既是量产追溯的依据，也是后续 Recipe 优化的重要输入。开发人员在调试阶段就应关注这些数据是否被正确采集，避免量产时出现"Recipe 用了但查不到记录"的情况。
五、版本管理与权限控制：让 Recipe 可追溯、可回退
Recipe 一旦进入量产，任何修改都必须可追溯。版本管理的基本要求是：每次修改生成新版本号，保留旧版本，记录修改人、修改时间、修改内容和审批状态。常见的做法是采用"主版本 + 次版本"编号，例如 COAT-001 V2.3，其中 V2 表示工艺路线发生变更，V3 表示仅参数微调。版本号应同时体现在编辑软件、机台加载界面和 MES 绑定记录中，三者一致才能避免"机台上跑的是旧版本"这类问题。
权限控制则解决"谁能改、谁能审、谁能下发"的问题。典型角色划分如下：
- 工艺工程师：可创建和编辑 Recipe，可提交审核，但不能直接下发到量产机台。
- 工艺主管 / 审核人：可审核 Recipe 变更，批准后方可进入下发流程。
- 设备工程师：可查看 Recipe 与执行记录，可执行机台侧的加载操作，但一般不具备修改工艺参数的权限。
- 操作员：只能按 MES 工单调用已批准的 Recipe，不能编辑或删除。
权限控制通常与账号系统绑定，所有编辑、审核、下发动作都会写入日志。开发阶段就应养成"先建版本、再改内容、后提交审核"的习惯，避免直接在机台上修改参数而不留记录。对于调试用的临时 Recipe，应使用独立的命名前缀（如 TMP-）并在调试结束后及时归档或删除，防止与正式 Recipe 混淆。
六、工具链协同的典型工作顺序
把上述工具串起来，一个完整的 Recipe 开发闭环通常是：在编辑软件中创建或修改 Recipe → 用离线仿真工具检查步骤与参数范围 → 提交审核并生成受控版本 → 通过 EAP/MES 下发到目标机台 → 在机台界面加载并执行 → 数据采集系统记录执行数据 → 根据数据判断是否需要下一轮修改。这个顺序中，任何一步的缺失都可能导致量产风险：没有仿真，逻辑错误可能直接上机；没有版本控制，改了什么说不清；没有数据采集，出了问题无法回溯。
总体来看，TEL Recipe 开发环境与工具链的核心不是某一个软件，而是"离线编辑—仿真检查—版本受控—系统下发—机台执行—数据回传"这条链路的完整性。开发人员需要清楚每个环节的输入输出和边界条件，才能在量产验证阶段快速定位问题，而不是在机台前反复试错。