设备进入产线后，Recipe管理往往是设备厂和工厂之间最容易产生分歧的地方。设备厂通常把Recipe作为本地文件存在设备里，工厂则要求集中管理、版本可追溯、认证状态可查。换一个客户，上传下载的口径、版本选择的规则、权限控制的做法又不一样，设备厂每接一个工厂就要定制一套接口。这些问题和 Recipe 本身的内容无关，根源是Recipe 作为一个对象，在设备和工厂之间缺少统一的标识、状态和流转约定。
SEMI E42就是为这一层制定的标准，全称为Recipe Management Standard: Concepts, Behavior, and Message Services，从概念（Concepts）、行为（Behavior）、消息服务（Message Services）三个层面，规定 Recipe 对象如何定义、管理与执行服务如何划分、各类操作如何在消息层承载。E42主体定义概念与行为，子标准E42.1（Standard for SECS-II Protocol for Recipe Management）规定这些服务在SECS-II协议上的消息映射。E42主体在引用文件中列出了几个相互配合的标准：工厂侧集成对接E30（GEM），对象服务遵循E39（OSS），事件报告遵循E53。
图1 RMS 的主要对象
（图源：SEMI E42-0704）
图2 Recipe 超类型属性
（图源：SEMI E42-0704）
在产线上，用错版本的代价很高，同一份 Name 下参数差一个版本，可能造成整批晶圆的工艺偏差。E42让所有版本同时存在、被管理和访问，并设置默认选取规则：不指定版本时，选取该 Class 与 Name 下审批级别最高的Recipe，审批级别相同时取版本最高者。具体用哪个版本，由审批级别和版本号共同决定，不靠人工记忆，也不简单取最新。版本本身是一个至少含一个字符的文本字符串，可由用户指定或由Namespace自动生成。标准对数字版本（只含数字与一个小数点、可换算为纯数字的版本号）规定了格式约束：不带小数点的整数不得以0后接其他数字开头，如“09”不允许，应写为“9”；带小数点的版本不得以小数点开头或结尾，也不得以小数点后的0结尾，如“1.”“.5”“1.670”均不允许，对应正确形式为“1”“0.5”“1.67”；版本可以是“0”但不能是“00”。由系统自动分配的版本进一步限定为不含小数点的整数，最小值为1，并按现有最高版本递增。标准只规定版本号的格式与选取规则，并不规定各段数字的工艺含义；至于以分段编号区分编辑器版本、参数变更性质等做法，属于设备厂在标准之外自行约定的版本管理策略。
集中管理和本地执行对 Recipe 的要求不同。管理侧要处理版本、审批和追溯，执行侧要保证当前这台设备能直接运行。E42 在存储与执行两个阶段，把 Recipe 区分为 Managed Recipe（受管 Recipe）与 Execution Recipe（执行 Recipe）。Managed Recipe存储在服务器Namespace（命名空间）中，处于集中管理状态；Execution Recipe存储在设备执行区（Execution Area），通常由Managed Recipe下发转换而来。Namespace是对Recipe进行管理与永久保存的逻辑概念，类似文件系统的文件夹结构，但Namespace本身不具备对外功能，只提供存储空间，权限也不在此设置。围绕Namespace，E42把操作划分为两类服务：服务端的Recipe Namespace Manager（命名空间管理器）负责Namespace与Recipe的集中管理，设备端的Recipe Executor（Recipe执行器）负责Recipe的下载、校验、执行与上传。两类服务的划分，使集中管理与本地执行在逻辑上解耦。
图3 Recipe Namespace 模型
（图源：SEMI E42-0704）
Managed Recipe 到 Execution Recipe是一次带属性映射的转换。同一份 Recipe下到不同设备，因硬件状态、校准结果不同，参数本就该有差异，这部分差异不能进入集中管理的Recipe。E42用Agent-Specific Dataset（设备专属参数集）承载这部分差异，它是与特定设备相关的一组参数，只在面向该设备转换时才带入。下发时，Namespace Manager把Managed Recipe转换为Execution Recipe，将目标设备对应的Agent-Specific Dataset带入，Body不做改变；上传时反向转换。两种形态的属性差异有明确规定：Managed Recipe的Link Param与Agent-Specific Link Param合并为单一属性ExecLinkParam；Agent-Specific Dataset的其余属性吸收为Execution Recipe属性；新增ExecAttrLength与ExecAttrChgTime记录执行侧属性长度与变更时间；在执行端具备改写Body或新建Recipe能力时，新增ChangedBody属性。此外，已验证Managed Recipe中用于链接的ExtRef与Parameters不被Executor使用、不保留在Execution Recipe中。这套转换规则保证同一份受管Recipe能够正确适配不同设备，同时使执行端的变更能够被准确记录和回传。
E42本身不能直接作为成品交付，它提供的是一套判断框架。它界定对象模型、服务行为与消息接口，不涉及 Recipe Body 的具体编辑，也不规定设备特有工况。离线程序创建、跨编辑器版本迁移、设备注册与分组、具体的权限与运维策略，都需要设备厂在标准之外实现，分布式 Recipe Namespace 等方向也预留了扩展空间。对设备厂的工程师来说，这套框架有两个实际用处。一是面对工厂的 Recipe 管理需求时，可以判断哪些内容在标准内、按标准实现，哪些在标准外、需要自行设计并承担后果，减少一次性定制。二是在实现 Recipe 管理时区分主次，文件上传下载只是表层部分，五个并行状态、版本与审批的选取、设备专属参数的转换，决定设备能否真正进入产线。标准本身不包含这些具体实现，它的作用是让设备、工厂主机和上层系统采用同一套对象、服务与消息语言对接，减少这一层的反复沟通和定制。
E42主体是协议无关的，对象模型和状态机可以承载在任何通信协议上，SECS-II 只是其中一种。把服务落到SECS-II上的是子标准E42.1，它把上述服务映射到S15流，F3至F36成对承载请求与应答，完成通知经 S6F25事件报告传递。消息可以换，对象和状态的语义不能换，所以不能把E42简单理解为S15消息表。具体而言：Namespace创建/删除为F3/F4、重命名为F5/F6、空间查询为F7/F8、状态查询为F9/F10、版本查询为F11/F12、创建/更新为F13/F14、Store为F15/F16、Retrieve为F17/F18、Copy/Rename为F19/F20、通用动作为F21/F22、获取描述符为F23/F24、可变参数为F25/F26、下载为F27/F28、Verify为F29/F30、上传为F31/F32、Select为F33/F34、Deselect与删除为F35/F36。更早的S7流仅覆盖过程程序文件的上传下载，不具备完整管理语义，需要与S15并存。看消息层时，把每一对F消息对应到行为层的一项服务，异步完成事件统一通过S6F25汇集。
标准把对象、行为和消息界定清楚，具体落地则由设备控制软件承载。鼎格的半导体设备控制软件体系以设备软件平台SEPlat为运行底座，以其上的开发框架SOF固化SEMI标准的交互逻辑，Recipe管理是其中的一个组成部分，与设备控制、数据采集、物料跟踪等能力在同一平台内协同。对应E42的部分按标准的对象模型、并行状态与服务划分实现，覆盖Managed Recipe与Execution Recipe的区分、版本与审批的自动选取、设备专属参数的转换以及异步操作的完成通知，使设备侧和工厂侧对同一Recipe对象的标识和状态保持一致。整个体系的通信与集成遵循SEMI的SECS/GEM、GEM300与EDA标准集，面向半导体制程与检测设备的软件开发和工厂导入。
图5 带完成通知的消息流
（图源：SEMI E42-0704）
针对一组Recipe的长耗时操作，标准采用异步链路，以Operation ID标识在途或队列中的动作，以Link ID标识操作是否全部完成，全部完成事件发送后置为零，否则非零，逐Recipe执行后发送完成事件。标准还定义了两类默认事件：Namespace Change（Namespace的创建、删除、重命名）与Recipe Change（Recipe的创建、删除、复制、重命名、编辑）。在比对能力上，标准支持不同版本之间、以及与基准Recipe（Golden Recipe）之间的结构化比较，以呈现参数差异。
图4 Recipe Available 状态模型
（图源：SEMI E42-0704）
状态模型最能看出设备厂对E42的实现程度。有不少Recipe管理只做了文件上传下载，再给对象加几个布尔标志，没有把状态做完整。E42用 Harel状态图把一个已存在Recipe的可用状态（Recipe Available）刻画为五个并行（AND）子状态，分别对应验证、审批、保护、链接、认证五个维度，各由相应属性承载，五个维度同时成立、缺一不可。验证维度由Verified标识，Verify操作由Recipe Executor读取Recipe内容、确认其语法正确，并识别需要对外公开的元素；与之不同，Validate发生在执行前，检查参数类型与取值范围对当前设备配置是否有效。审批维度由ApprovalLevel标识授权用户赋予的审批级别。保护维度没有独立的写保护开关。ApprovalLevel与Namespace属性 RecipeReadOnlyLevel 共同决定保护状态：审批级别达到RecipeReadOnlyLevel时，Recipe进入只读状态，不能再改动。链接维度由Linked标识，main recipe经link操作收集全部外部引用、形成linked recipe set后置为已链接。认证维度由Certified标识，认证针对特定执行Agent。Certified定义在Agent-Specific Dataset中，记录该 Recipe 在特定设备上的认证级别，修改设备相关参数约束或解除链接都会使认证失效。
上海鼎格信息科技有限公司（简称：鼎格工业软件）成立于2013年，是国家高新技术企业、上海市“专精特新”企业，总部位于上海市浦东新区张江国家高科技园区。
鼎格工业软件致力于中国工业自动化与智能化的融合，专注为高端装备制造业提供设备控制软件以及围绕设计、装配、试验、维保等关键业务领域的智能化解决方案。经过多年积淀，鼎格工业软件形成了三大平台：半导体设备控制软件平台、基于数字孪生技术的智能制造平台、以及基于3D可视化技术的内容管理平台。三个平台自底到顶，在半导体、航空航天、汽车、新能源等多个领域构筑起智能制造所需较为完整的工业软件产品体系。
