从“谁负责解释生产”到“生产是如何被执行的”
在复杂制造系统中，真正困难的问题并不在于“设备如何动作”，而在于生产运行语义如何被稳定、可审计地解释。当生产管理系统（ISA-95 or IEC 62264）与过程/批控制系统（ISA-88 or IEC 61512）发生融合时，这一问题尤为突出：
运行状态、执行事实与控制行为混杂在同一技术栈中，极易导致责任不清、语义漂移与不可追溯。
本文中的三张图，正是围绕这一核心问题，从不同抽象层次逐步展开的一组连续性架构说明。
第一张图：责任、状态与接口的“静态边界”
第一张图并不试图描述系统“如何运行”，而是先回答一个更基础的问题：
在一个 S95 × S88 融合架构中，
谁有权定义什么状态？
谁可以发起什么动作？
接口传递的到底是什么语义？
因此，这张图刻意回避了模块实现和技术细节，而聚焦于三件事：
责任主权（Responsibility Ownership）
L3 负责生产运行语义与生命周期解释
L2 负责物理执行事实
L2.5 不拥有任何运行主权
状态归属的纵向分裂
运行状态 ≠ 执行状态
状态不是共享对象，而是责任内语义
接口不是命令，而是被约束的意图
向下传递的是“允许执行的意图”
向上传递的是“已发生的事实”
这张图的作用是划清边界：
如果没有这一步，后续任何时序或状态机讨论都会陷入“谁说了算”的混乱。
第二张图：责任 × 状态 × 事件的逻辑结构
在明确了边界之后，第二张图向前推进一步，回答的是：
在这些边界之内，
各层是通过什么机制协同的？
这时，视角从“接口和状态的归属”转向了逻辑责任结构，因此采用了C4-Logical View的表达方式。
这张图的连续性体现在三个方面：
1. 责任角色被显式化
L3 被明确为Responsibility Owner
L2.5 被限定为Coordinator
L2 被限定为Executor
这一步并不是概念装饰，而是为后续运行时行为设定合法角色范围。
2. 状态被还原为“责任内状态”
逻辑视图中出现了三种状态形态：
运行状态（可审计、可回滚）
映射状态（过渡性、无主权）
物理状态（实时事实、不可回滚）
这正是对第一张图中“状态主权纵向分裂”的一次结构化展开。
3. 事件成为唯一合法的跨层机制
在逻辑层面，事件取代了命令和调用，成为跨层交互的唯一形式：
向下：Execution Intent
向上：Execution Fact
这为第三张图的“运行时展开”提供了唯一合理的动态语言。
第三张图：一次 Production Run 的运行时展开
在前两张图已经明确：
谁负责解释
状态在哪里变化
跨层只能通过事件
之后，第三张图才有意义。
这张Dynamic View不再讨论“结构是否合理”，而是直接回答：
在一次真实的生产运行中，
上述责任和语义是如何被贯彻的？
因此，它选择了完整运行时序作为载体：
Start / Hold / Resume / Complete
每一步都遵循相同的责任路径
每一次状态变化都在 L3 被确认
三张图共同构成的逻辑闭环
从整体上看，这三张图的解释链条：
第一张图：
先回答“谁不能做什么”
——划清责任与语义边界第二张图：
再回答“在边界内如何协同”
——建立责任 × 状态 × 事件的逻辑结构第三张图：
最后回答“运行时是否真的如此”
——用时间验证结构的正确性
只有按这个顺序阅读，读者才能真正理解：
这不是三张不同视角的图，而是一套关于“生产运行如何被解释”的完整工程论证。
