4. 集成需求分析与边界定义
在 Hexagon 质量数据平台与 MES 集成的项目中,最容易出问题的往往不是接口技术本身,而是“需求没谈清楚、边界没划明白”。集成需求分析的核心任务,是把业务上模糊的“要把质量数据和 MES 打通”,翻译成一份可设计、可开发、可验收的集成需求规格。本节围绕四条主线展开:识别质量数据流、明确集成范围、定义主数据与业务事件、输出集成需求规格。
一、识别质量数据流:先看清数据从哪来、到哪去
质量数据流识别不是简单罗列接口,而是沿着“产生—采集—处理—消费”的链路,把每个环节的数据对象、触发时机和责任人标清楚。以一条典型离散制造产线为例,质量数据通常有三类来源:
- MES 侧过程数据:工单号、工序号、设备编号、操作员、生产时间、工艺参数(如扭矩、压力、温度)等,由 MES 在生产执行过程中产生。
- 检测设备数据:三坐标测量机、视觉检测、气密测试等设备输出的测量值、判定结果、检测时间,通常经采集网关或设备接口进入平台。
- 人工录入数据:首件检验、巡检、返修确认等由质检员在终端录入的判定与备注。
识别数据流时,建议用“数据对象 + 触发事件 + 方向 + 频率”四要素描述每一条流。例如:测量结果由检测完成事件触发,从检测设备流向Hexagon 平台,频率为每件一次。这样描述后,后续判断实时/批量、推/拉模式就有依据。
二、明确集成范围:用边界把“做什么”和“不做什么”钉死
范围定义的关键是区分“本次集成范围”与“系统自身职责”。上图中红色虚线框住的部分,是本次集成需要交付的接口与映射逻辑;框外的 MES 内部排产、设备内部测量算法、看板展示样式,都不属于集成范围。实践中常用一张范围表来固化:
| 范围项 | 纳入本次集成 | 不纳入(由对应系统负责) |
|---|---|---|
| 工单与工序主数据 | MES → 平台同步 | MES 内部排产逻辑 |
| 测量结果采集 | 设备 → 平台 | 设备内部测量算法 |
| 质量判定回写 | 平台 → MES | MES 放行界面展示 |
| SPC 分析 | 平台内完成 | — |
| 历史数据迁移 | 近 6 个月(示例) | 更早历史归档数据 |
范围一旦确定,任何新增需求都要走变更流程,避免“顺手加一个字段”导致接口反复返工。
三、定义主数据与业务事件:集成的“名词”和“动词”
主数据是集成中相对稳定、被多方引用的“名词”,业务事件是驱动数据流动的“动词”。两者必须分别定义清楚。
主数据通常包括:物料编码、工单号、工序号、设备编号、检验特性(CTQ)、缺陷代码、供应商代码。定义时要明确唯一标识来源(谁生成)、编码规则、同步方向与更新频率。例如工单号由 MES 生成,平台只读;缺陷代码由平台维护,MES 引用。
业务事件是触发数据交换的动作,常见的有:工单开工、工序完工、检测完成、判定放行、返修触发、批次冻结。每个事件要定义事件名、触发条件、携带字段、目标系统、时效要求。例如“检测完成”事件携带工单号、工序号、测量值、判定结果,要求 5 秒内到达平台。
四、输出集成需求规格:一份可设计、可验收的文档
集成需求规格(IRS)是把前三步的结论固化成可交付文档。它不需要写成几百页,但必须让开发和测试都能直接使用。建议包含以下字段:
- 接口编号与名称:如 IF-01 工单主数据同步。
- 数据方向:MES → 平台,或平台 → MES。
- 触发方式:事件驱动 / 定时批量 / 手动触发。
- 数据对象与字段:字段名、类型、是否必填、示例值。
- 频率与时效:实时、准实时(≤5s)、批量(每小时)。
- 异常处理:重试次数、告警方式、人工补偿入口。
- 验收标准:字段完整率、时延、对账一致率。
下面给出一份可直接参考的接口需求规格示例(节选):
接口编号:IF-03
接口名称:检测结果上传
数据方向:检测设备 → Hexagon 平台
触发方式:检测完成事件(事件驱动)
数据对象:MeasurementResult
字段:
workOrderNo string 必填 示例 WO-20240512-001
operationNo string 必填 示例 OP-30
equipmentNo string 必填 示例 CMM-01
characteristic string 必填 示例 孔径
measuredValue decimal 必填 示例 12.03
judgment string 必填 OK / NG
measuredAt datetime 必填 示例 2024-05-12T10:23:45
频率与时效:每件一次,≤5 秒到达平台
异常处理:失败重试 3 次,仍失败则告警并进入人工补录队列
验收标准:字段完整率 100%,时延 P95 ≤ 5s,日对账一致率 ≥ 99.9%
这份规格写完后,开发可以直接据此设计消息结构,测试可以据此编写用例,业务方可以据此确认“这就是我要的”。集成需求分析的价值,正在于把口头共识变成可执行、可验证的契约。
总结来说,集成需求分析与边界定义是一条从业务到技术的翻译链:先沿数据流看清对象与触发,再用边界表锁定范围,接着把主数据和业务事件分别定义清楚,最后固化为带验收标准的接口需求规格。这条链走扎实,后续的接口设计、开发与联调才有稳定的基础。