2. 配方参数管理程序的范围与边界

在上一节中我们已经明确，配方参数管理程序并不是一个孤立的“参数录入工具”，而是连接工艺知识、设备执行与生产管理的中间层。要让这个中间层真正发挥作用，第一步必须把“管什么”和“不管什么”划清楚。范围与边界不清，往往导致两类典型问题：一是程序被当成万能数据库，把设备实时数据、物料批次、人员权限全部塞进来，最终变成难以维护的“大杂烩”；二是程序被压缩成一张参数表，版本、设备差异、下发状态全部丢失，现场改配方只能靠口头传达。本节围绕四个管理对象和三条外部接口，给出可落地的界定方法。

一、四个核心管理对象及其界定

配方（Recipe）是管理的第一层对象。它不是一个参数集合的别名，而应具备明确的标识：配方编号、产品名称、适用产线、状态（草稿/已发布/已冻结/已作废）、生效日期。配方本身不直接对应设备，它描述的是“生产某产品所需的一组工艺设定”，因此一个配方可以被多条产线引用，但引用时必须绑定具体的设备配置。

参数（Parameter）是配方的组成单元。每个参数至少需要五个属性：参数名、单位、数据类型、目标值、允许偏差。这里要特别强调“目标值”与“设定值”的区别——目标值是工艺要求的中心值，设定值是下发到设备的具体数值，二者在补偿、换算后可能不同。参数还应区分“可调参数”与“锁定参数”，后者在发布后不允许现场修改，例如杀菌温度的上限保护值。

设备（Equipment）是参数的承载对象。同一配方在不同设备上执行时，参数可能需要映射或换算。例如搅拌转速在A设备以“rpm”下发，在B设备以“百分比”下发，程序需要维护设备能力档案：设备编号、设备类型、支持的参数集、量程、通信地址。设备档案是配方与现场之间的“翻译层”，缺少它，配方无法安全下发。

版本（Version）是贯穿前三个对象的控制维度。配方版本、参数集版本、设备配置版本应分别记录并可追溯。建议采用“主版本.次版本”规则：主版本变更表示工艺路线或关键参数限值改变，次版本变更表示非关键参数微调。任何一次下发都必须记录“配方版本+设备配置版本+下发时间+操作人”，这是后续排障和审计的基础。

二、与MES、SCADA、PLM的接口关系

三条接口的方向和职责必须分开定义，否则最容易出现“谁都能改参数”的失控局面。

与PLM的接口是“来源型”接口。PLM负责工艺路线、产品设计和参数初始值的权威定义。配方参数管理程序从PLM接收的是“参数模板”和“设计变更通知”，而不是逐条实时同步。实际做法是：PLM发布某产品的工艺参数清单后，程序按模板生成配方草稿，工艺工程师在此基础上补充设备映射和允许偏差。PLM侧发生设计变更时，程序应能标记受影响的配方版本，提示“需复核”，但不应自动覆盖已发布配方。这条边界保证了设计意图可追溯，同时避免设计变更直接冲击在产批次。

与MES的接口是“调用型”接口。MES在创建工单时，向程序请求“某产品在某产线应使用的配方版本”，程序返回配方编号、版本号和参数集摘要。MES不直接修改参数，只负责把工单与配方版本绑定。这样做的价值在于：当同一产品存在多个配方版本时，MES按工单生效日期选择正确版本，避免现场用错配方。接口字段建议至少包含：工单号、产品编码、产线编码、请求时间、返回的配方版本、校验码。

与SCADA的接口是“执行型”接口。这是唯一真正把参数写入设备的通道。程序向SCADA下发的是“设备编号+参数地址+设定值+数据类型”，SCADA负责协议转换和写入，并把写入结果与实时回读值返回。这里必须明确一条边界：程序只下发设定值，不参与闭环控制；SCADA回读的实时值用于比对和报警，不写回配方目标值。若回读值超出允许偏差，程序记录“下发异常”事件，由操作员决定重试或停机，而不是自动修正目标值。

三、明确不纳入范围的内容

边界同样需要“负面清单”。以下内容不建议纳入配方参数管理程序：设备实时过程数据的历史存储（属于SCADA/ historian）、物料批次与库存（属于MES/ERP）、人员排班与权限审批流（属于MES或独立权限系统）、设备维护工单（属于EAM）。把这些内容排除在外，程序才能保持“配方与参数”这一核心职责的清晰。需要关联时，通过编号引用而非数据复制，例如配方记录中只保存物料编码，不保存物料名称和库存量。

四、一个可执行的边界核对示例

假设某乳品厂要上线配方参数管理程序，工艺工程师整理出如下边界核对表（示例为合理假设，非实测数据）：