3. 制造数据集成需求分析与集成蓝图设计

制造数据集成项目失败，往往不是败在接口技术，而是败在需求没有落到“数据流”上。业务部门说“我要实时看到设备状态”，IT 部门听到的是“要接 PLC”，于是直接开接口，最后发现真正需要的是“按工单维度统计停机时长”，而 PLC 只提供点位信号，缺少工单上下文。需求分析的核心任务，就是把模糊的业务诉求翻译成可设计、可验证的数据流定义。

一、从业务痛点推导数据需求

需求分析的第一步不是问“要接哪些系统”，而是问“哪个业务决策因为缺数据而做不好”。以某离散装配车间为例，典型痛点可以归纳为三类：

• 过程不透明：班组长无法知道当前工单在哪个工位、已投入多少件、还有多少在制，只能靠人工巡线记录。
• 异常响应慢：设备停机后，维修班组平均 25 分钟才到场，因为停机信号只在本机指示灯上，没有推送到维修看板。
• 质量追溯断链：客户投诉某批次扭矩不合格，需要 4 小时人工翻纸质记录才能定位到具体设备与班次。

把痛点转成数据需求时，要明确四个要素：决策对象（谁在什么场景下用）、数据对象（需要哪些实体与属性）、时效要求（实时、准实时还是 T+1）、精度与粒度（按秒、按件还是按班次）。例如“异常响应慢”对应的数据需求是：设备停机事件需在 5 秒内到达维修看板，事件需携带设备编号、停机开始时间、当前工单号、停机代码，粒度到单次停机事件。

二、定义端到端数据流

数据流定义要回答“数据从哪来、经过谁、变成什么、到哪去”。制造场景中常见的数据源包括 PLC/SCADA、MES、QMS、WMS、ERP 以及手工录入终端。以“停机事件推送”为例，一条完整数据流是：PLC 检测到设备由运行转停机 → SCADA 打上时间戳与设备编号 → 边缘网关按停机代码规则过滤抖动 → 集成平台补充工单上下文（从 MES 查询当前工单）→ 写入消息队列 → 维修看板订阅并告警。

这条链路里，PLC 提供的是原始信号，SCADA 提供的是带时间戳的状态，集成平台完成的是“信号 + 业务上下文”的富化。如果跳过富化直接推送，维修人员看到的只是“3 号机停了”，无法判断影响哪张工单、是否影响交付。因此数据流图必须标出富化节点和关联键，本例的关联键是“设备编号 + 时间窗口”，用于匹配 MES 中该设备当前正在执行的工单。

三、集成优先级排序

需求清单往往有几十条，不可能一次全做。排序要同时看业务价值和实现成本，而不是只看技术难度。可以用一个简单的评分表：业务价值按“影响交付/质量/成本”打分 1–5，实现成本按“接口改造量、数据质量、协调难度”打分 1–5，优先级得分 = 业务价值 ÷ 实现成本，得分高者先做。

第一批选择“停机事件”和“工单进度”，是因为它们共用设备编号、工单号两个主数据，接口复用度高，且能快速让车间看到变化，为后续批次争取资源。第二批的扭矩追溯需要打通 QMS 与设备参数，涉及历史数据补录，成本高但质量价值大，适合在第一批稳定后启动。

四、目标架构设计

目标架构要能支撑上述数据流，同时避免点对点接口爆炸。推荐采用“边缘层—集成层—应用层”三层结构：边缘层负责协议转换与本地缓存，断网时数据不丢；集成层负责消息路由、数据富化、格式统一与主数据映射；应用层通过订阅方式获取数据，不直接访问源系统。这样新增一个看板只需订阅 Topic，不需要再动 PLC 或 MES。

架构设计还要明确主数据归属：设备主数据以 EAM 为准，工单主数据以 MES 为准，物料主数据以 ERP 为准。集成平台只做映射与分发，不产生新的主数据副本，避免“同一台设备三个编号”的追溯混乱。对于停机代码这类枚举值，需在集成层建立统一字典，把不同厂商的代码映射为标准停机原因分类，否则 OEE 统计口径无法一致。

最后，蓝图需要配套一份可验收的集成需求说明，至少包含：数据流名称、源系统与目标系统、触发方式、字段清单与关联键、时效指标、异常处理策略（重试、告警、人工补录）。以停机事件为例，异常策略可定义为：消息队列写入失败重试 3 次，仍失败则写入死信队列并通知集成运维；MES 工单查询超时则先推送不带工单号的停机事件，由看板标记“待关联”。这些细节决定了集成上线后能否稳定运行，也是需求分析阶段最容易被忽略、却最值得投入的部分。