3. MOM总体架构方法论

MOM（制造运营管理）平台横跨计划、排产、执行、质量、设备、仓储、能源等多个业务域，又必须与ERP、PLM、SCADA、自动化设备形成稳定的数据闭环。如果只按“功能清单”堆叠系统，很容易出现同一物料编码在ERP与MES中不一致、工单状态在多个系统间反复对账、接口随业务变化频繁返工等问题。因此，MOM总体架构需要一套可复用的方法论：用TOGAF提供架构开发与治理的“过程骨架”，用ISA-95提供制造领域的“分层与对象语义”，再以业务、应用、数据、技术四个视图把架构落到可评审、可实施、可治理的粒度。

一、TOGAF与ISA-95的分工与融合点

TOGAF的核心价值在于ADM（架构开发方法）循环：从架构愿景、业务架构、信息系统架构（应用+数据）、技术架构，到机会与解决方案、迁移规划、实施治理、变更管理。它回答的是“架构工作怎么组织、怎么评审、怎么演进”。ISA-95则给出制造企业的功能层级模型（Level 0现场设备、Level 1控制、Level 2监控、Level 3制造运营、Level 4经营计划）和对象模型（设备、物料、人员、工艺段、生产计划、工单等），回答的是“制造域里有哪些对象、它们分属哪一层、层间交换什么信息”。

两者融合的关键在于：把ISA-95的层级与对象作为TOGAF各阶段架构内容的“领域约束”。例如在业务架构阶段，用ISA-95的Level 3/4边界界定MOM与ERP的职责；在数据架构阶段，用ISA-95的对象模型统一工单、物料、设备、人员的主数据定义；在技术架构阶段，用层级模型确定边缘侧与中心侧的部署边界。这样TOGAF不会变成空泛的流程文档，ISA-95也不会停留在静态分层图上。

二、四视图的落地内容与依赖关系

四个视图不是并列的四份文档，而是有依赖顺序的架构切片。业务架构先确定“做什么、谁负责、按什么规则流转”，它输出业务能力地图和业务对象清单；应用架构据此划分组件边界，明确哪些能力由MOM自建、哪些调用ERP或WMS；数据架构再把业务对象固化为数据实体、编码规则和流转关系；技术架构最后决定这些组件和数据部署在哪里、用什么中间件、满足什么时延与可用性指标。

以“工单执行”为例：业务架构定义工单从ERP下达、MOM排产、车间派工、工序报工到完工入库的流程与责任岗位；应用架构确定排产组件、派工组件、报工组件及与ERP的工单同步接口；数据架构定义工单主数据字段（工单号、物料编码、计划数量、工艺路线、状态机）和报工事务数据；技术架构则确定工单同步走API网关、报工数据经边缘节点缓存后批量上传、时序数据入时序库。四视图之间任何一处变更，都要评估对其他三视图的影响。

三、架构原则与治理机制

架构原则是治理的判断依据，必须可检验、可裁决，而不是口号。MOM总体架构建议明确以下原则：

• 分层解耦原则：L3制造运营与L2监控之间通过标准接口交互，MOM不直接读写PLC内部寄存器；边缘侧负责协议转换与断网缓存。
• 主数据单一来源原则：物料、BOM、工艺路线以PLM/ERP为源，MOM只做制造域扩展属性，禁止在MOM内私建物料主数据。
• 接口标准化原则：跨系统集成优先采用API与消息，接口需登记在集成矩阵中，包含版本、频率、数据量、失败重试策略。
• 数据可追溯原则：工单、批次、设备、人员四类关键对象必须支持正反向追溯，追溯链路在数据架构中显式建模。
• 非功能可度量原则：关键接口时延、系统可用性、数据同步延迟需设定目标值并纳入监控。

治理机制则把这些原则变成可执行的关卡。建议设置三层治理：架构评审委员会负责重大架构决策与例外审批；架构师团队负责维护四视图基线、集成矩阵和数据标准；项目组在需求、设计、上线三个节点接受架构合规检查。变更控制上，任何新增接口、新增数据实体或跨层直连，都必须提交架构变更申请，评估对四视图的影响并更新基线。评审门禁可量化为检查项，例如：接口是否登记、主数据来源是否合规、是否绕过边缘层直连设备、追溯字段是否完整。

综上，TOGAF提供架构开发与治理的过程框架，ISA-95提供制造域的分层与对象语义，四视图把二者落到业务、应用、数据、技术的具体内容上，架构原则与治理机制则保证架构在项目推进和业务变化中不失控。三者结合，才能让MOM总体架构既有方法论支撑，又能在车间现场真正落地。