2. 从业务到控制的分层逻辑

ISA-95 的核心价值，不在于把系统切成几块，而在于回答一个工程问题：一笔订单从客户需求变成设备动作，中间要经过哪些层、每层各自决定什么、又向上下层传递什么。如果这个链条不清楚，就会出现两种典型病症：企业层直接下发工艺参数给 PLC，导致生产现场被业务变更频繁扰动；或者控制层把大量原始数据直接抛给 ERP，导致业务系统被秒级数据淹没。分层逻辑正是用来划定"谁决策、谁执行、谁提供数据"的边界。

三层职责的本质区别

ISA-95 通常把制造相关活动划分为四层（Level 0～3）加上企业层（Level 4）。工程上最常讨论的是三个决策主体：

• 企业层（Level 4，ERP）：面向经营与供应链，时间尺度是天到周。它关心"做什么、做多少、什么时候要"，输出的是订单、物料需求、成本目标。它不关心某台设备当前是自动还是手动。
• 制造运行层（Level 3，MES/MOM）：面向生产执行，时间尺度是班次到分钟。它把订单拆成工单、把工单排到工序、把工序绑定到设备与人员，并采集实际产出、消耗、质量结果。它是"翻译层"，把业务语言翻译成设备可执行的作业指令。
• 控制层（Level 0～2，PLC/DCS/SCADA）：面向设备与过程，时间尺度是毫秒到秒。它执行闭环控制、联锁保护、顺序逻辑，输出的是阀门开度、电机启停、设定值。它只对"当前这一秒"负责。

三层的分界不是按软件产品划分，而是按决策的时间尺度与责任范围划分。一个常见的误判是：把 SCADA 的报表功能当成 MES 的统计功能。区别在于，SCADA 报表描述"设备发生了什么"，MES 统计回答"这批工单是否按计划完成、偏差原因是什么"。

信息流与决策流的方向差异

理解分层，必须把"信息流"和"决策流"分开看。它们方向相反，且内容粒度不同。

决策流自上而下：企业层下达生产订单（如"本周生产 A 产品 5000 件"）→ 制造运行层分解为工单与工序排程（如"3 号线 8:00–16:00 生产 A，批量 500，使用配方 R-A-02"）→ 控制层接收作业指令与配方参数，转化为设备动作序列。每一层都在缩小范围、提高时间分辨率。

信息流自下而上：控制层上报设备状态、过程值、报警、批次事件 → 制造运行层汇总为工单实绩、物料消耗、质量判定、OEE 构成 → 企业层接收库存变动、完工入库、成本归集。每一层都在做聚合、过滤和语义提升，而不是简单转发。

这里有一个关键工程约束：越靠近控制层，数据越密、越原始；越靠近企业层，数据越稀、越语义化。如果让 ERP 直接订阅 PLC 的 100ms 标签，系统必然崩溃；如果让 MES 只拿手工录入的班报，就失去了实时调度能力。合理的做法是在 Level 2/3 边界设置数据采集与聚合机制，按事件或分钟级批量上传。

分层设计的核心原则

从工程落地角度看，分层设计要守住四条原则，它们直接决定系统是否可维护、可扩展。

第一，职责单一，不越层决策。企业层不应直接修改控制层的工艺参数。如果业务需要调整配方，正确路径是：ERP 更新物料/BOM → MES 生成新版本配方并下发 → 控制层按新配方执行。这样变更可追溯、可审批、可回滚。反过来，控制层不应自行决定"这批产品是否放行"，它只提供质量数据，判定权在 MES 或 QMS。

第二，接口标准化，语义明确。层与层之间的交互应基于明确定义的对象模型，而不是临时拼凑的数据库表。ISA-95 定义了生产订单、工单、物料、设备、人员等标准对象。例如，MES 向 ERP 上报完工时，应携带工单号、物料号、数量、单位、批次、时间戳，而不是一句"生产完了"。

第三，时间尺度匹配。每层的数据更新频率应与其决策周期一致。控制层 100ms 采集，MES 按分钟或事件聚合，ERP 按班次或天接收。强行拉平时间尺度，要么浪费资源，要么丢失关键细节。

第四，故障隔离与降级运行。当 ERP 不可用时，MES 应能基于本地工单继续驱动生产；当 MES 不可用时，控制层应能维持当前批次的安全执行与基本联锁。分层不仅是逻辑划分，也是可用性设计。

一个可对照的职责划分示例

假设某饮料厂要生产 24000 瓶橙汁，可以按层拆解如下（示例参数，用于说明分层逻辑）：

这个例子说明：每一层只处理自己尺度内的信息，并通过标准对象向上或向下传递。ERP 不需要知道灌装阀的开度，PLC 也不需要知道这批货卖给谁。分层的意义，就是让每一层都能独立演进，同时通过清晰的接口保持整体协同。