整线设备厂交付 MES，谁负责工艺、设备和客户系统的边界？

整线交付 MES，最需要先确定的是：谁定义生产规则，谁保证设备执行，谁确认客户系统中的业务结果。

建议的责任分工：客户工艺与质量部门确认业务规则；设备厂负责设备动作、信号及线体联调；MES 供应商负责约定范围内的规则执行、过程记录与接口处理；客户 IT 牵头协调 ERP 等系统的权限和对端改造。整线总包应牵头组织跨方问题闭环，但具体实施、费用与验收责任须写进工作范围，不能由“交钥匙”三个字代替。 以下是一套用于方案评审的建议框架，不是某个客户项目的实施结果，也不代表任何合同的既定责任。对设备厂老板而言，提前把边界写清楚，才能把报价、交期与验收条件放在同一张图上。

---

为什么设备能跑，整线项目仍可能交不了？

设想一次联调：产品完成测试，设备报出合格，MES 也保存了结果，但客户 ERP 没有形成完工记录。设备厂认为信号已发，软件方认为报文已送，客户却认为订单还没完成。

这是假设场景，却能说明一个容易遗漏的验收断点：设备动作、软件记录和业务入账是不同的结果。如果合同只写“对接 ERP”，没有说明以哪种结果作为完成标志，现场就缺少共同判断依据。

ISA 在 2020 年的 ISA-95 回顾中指出，第 1、2 部分讨论企业与控制之间的主要数据交换，第 3、4 部分进一步定义制造运营管理空间。[1] 这些层次有助于划分系统功能，但不能自动决定哪家公司承担项目责任。责任仍需落实到交付物、前提条件和确认人。

工艺、设备、MES 和客户系统，具体怎样分工？

下面的矩阵适合作为项目启动会的讨论底稿。客户内部的工艺、质量、生产和 IT 应分别指定责任人，不能用一个笼统的“客户配合”覆盖所有前提。

事项	客户侧	整线设备厂	MES 供应商	应留下的依据
工艺路线、返修与放行	工艺与质量确认规则及变更	确认线体路径和设备实现条件	实现约定的校验、权限和履历	有版本的路线图、例外规则、确认记录
设备信号与动作	确认生产要求和现场使用条件	定义并验证信号含义、触发时机和设备动作	按约定采集、反馈并记录结果	点位表、握手时序、样本和联调记录
订单、物料和版本	指定权威来源、维护人及生效规则	核对设备配方与产品对应关系	按约定接收、校验和使用主数据	字段映射、版本样例、错误处理清单
ERP 等系统对接	IT 协调对端厂商、测试环境、权限与业务确认	按总包范围协调里程碑和依赖	交付己方接口、重试及对账机制	请求与响应样例、目标单据、失败补偿记录
整线验收	业务代表确认实际业务结果	按约定牵头集成测试和问题闭环	提供软件测试及数据核对证据	测试用例、缺陷关闭记录、遗留项及签收

每项成果都要有明确的确认人。例如，MES 可以执行返修路线，但返修后是否需要重新测试，应由客户工艺和质量部门确认；设备厂需要说明设备能否支持这条回流路径。软件供应商不能根据一个页面按钮，替客户决定质量放行政策。

接口样例里，哪些内容比“支持某协议”更重要？

OPC Foundation 与 OPEN-SCS 的 2022 年 V03b 资料说明，OPC UA 采用 IEC 62541 标准，并强调平台及厂商独立性。[2] 这说明协议能够帮助解决互联问题，却不意味着不同系统天然理解同一个“完工”。该资料主要讨论制药追踪场景，这里仅引用协议背景，不把其行业规则移植到离散制造项目。

整线项目应为关键接口准备一套可执行样例，而不仅是一张字段清单。以“测试结果上报”为例，至少写清以下内容：

• 对应哪件产品：产品序列号、工单、工位以及当前工艺版本怎样关联，未知序列号如何处理。
• 什么时候算一条结果：以测试结束、设备确认还是软件确认作为触发点；复测如何保留历次结果。
• 成功究竟指什么：收到报文、校验通过、数据保存、形成业务单据分别用什么状态表达。
• 失败怎样恢复：网络中断后谁保存待发数据，谁发起重试，重复报文如何防止重复报工。
• 怎样证明双方一致：用同一业务标识串起设备记录、MES 履历和客户系统结果，并指定差异处理人。

例如，同一测试结果因超时被再次发送，期望结果应是保留可审计的接收记录，并按约定避免重复生成业务结果。具体采用什么唯一标识、保存多久、谁能重放，应由项目方案明确；不能把这些决定留给现场临时补丁。

设备验收通过，能否代表 MES 也验收通过？

不能仅凭设备验收结果推定 MES 验收完成。ISA 对 ANSI/ISA-62381-2026／IEC 62381:2024 的公开介绍区分工厂验收测试、现场验收测试与现场集成测试，并明确说明其 FAT/SAT 不覆盖 MES 测试。[3] 该标准面向流程工业，此处引用的是测试范围边界，不将它宣称为所有离散制造 MES 项目的强制验收标准。

对整线项目，建议把验收依据分开约定，再用同一条业务链串起来：

1. 设备层：按约定验证动作、检测结果、信号时序和故障响应。设备安全控制由相应专业方案保障，不应依赖 MES 通信替代。
2. MES 层：验证产品身份、工艺校验、结果记录、异常处置和追溯查询，确认数据与现场行为对应。
3. 业务集成层：从客户系统下达订单，经生产执行、测试和完工反馈，再核对对端业务结果；同步测试重复发送、断网恢复与业务拒绝。

每个用例都应写明前置条件、操作、预期结果、证据位置和确认人。截图可以证明页面显示过什么，但涉及报工、库存或订单状态时，还需要核对相应业务记录。只有接口返回成功，不能证明客户业务已经闭环。

客户系统没准备好，项目该怎样推进？

在报价和排期时，把客户需提供的测试环境、账号权限、样例数据、对端人员及可联调时间列成前提条件。由项目负责人维护依赖清单，明确到期未满足时如何调整测试安排和里程碑。

对端暂时不可用，可以用模拟数据验证己方字段处理和异常逻辑，但报告必须注明模拟范围，并把真实系统联调保留为未完成项。不要把“模拟通过”改写成“ERP 对接完成”。

现场新增返修路径、修改合格判断或更换主数据来源时，应先做影响分析：设备动作是否变化、历史记录怎样解释、接口是否兼容、哪些用例需要复测。三方确认后再变更版本；新增需求和原有缺陷也应分别记录，避免成本与责任混在一起。

---

常见问题

客户只想找设备厂一个窗口，还需要拆责任吗？

需要。对外可以由设备厂统一协调，对内仍须明确各项交付和确认责任。统一窗口方便客户解决问题，责任矩阵帮助总包把问题分配给具备处理条件的人；两者应同时存在。

客户已有厂级 MES，还需要线体 MES 吗？

先核对现有系统能否覆盖工位执行、设备反馈、异常回流和追溯要求，再决定是否补充线体层。若需要增加线体 MES，应明确工单、路线、质量状态各自由哪个系统维护，避免两边都能修改而没有统一生效规则。

签约前最值得一起评审哪些资料？

建议把责任矩阵、关键接口样例与端到端验收用例放在一起评审。矩阵说明谁负责，样例说明交换什么，用例说明怎样才算完成。再核对这些内容是否进入实际工作范围、前提条件和变更流程。

整线交付，需要把软件功能落到共同认可的结果

奥斯坦丁软件（OTD）建议，讨论 OTDMES 与整线设备的协同时，先选择一条明确的业务链：从订单进入，到产品过站、检测，再到结果回传。围绕这条链逐项确认工艺、设备、软件与客户系统的职责，再确定本期交付范围。

对设备厂而言，值得交付的不只是一个可打开的 MES 页面，而是一套客户能使用、问题有人处理、结果有据可验的生产流程。

参考资料

[1] ISA，2020，《The ISA-95 Enterprise-Control System Integration standards》：系统功能层次及数据交换范围。

[2] OPC Foundation / OPEN-SCS，2022，V03b，《Track and Trace: OPC UA in the Pharmaceutical Industry》：OPC UA 与 IEC 62541 协议背景。年份以文档封面为准。

[3] ISA，2026，ISA-105 标准介绍，涉及 ANSI/ISA-62381-2026／IEC 62381:2024：FAT、SAT、SIT 与 MES 测试范围说明。

资料核对日期：2026 年 11 月 6 日。本文责任矩阵与实施建议为方案评审参考，具体适用范围由项目各方确认。