跳到主要内容

MDM 行业场景配方

以下配方展示 DFS MDM 如何支持运营工作流。实施时应根据项目的源系统、治理模型和部署范围调整。

配方结构​

把一个场景落到客户项目时，建议使用同一结构：

每个配方都应明确要治理的对象、涉及的源系统、数据责任人，以及消费治理输出的下游工作流。

设施与公用工程运营​

使用 MDM 将物理设备与运营系统连接起来。

来源典型身份
建筑或设施模型设备或资产 ID。
SCADA/BMS点位名、标签或控制器路径。
ERP/EAM资产号。
工单系统维护对象或工单目标。
巡检系统巡检点或路线对象。

流程：

  1. 为设备或装置创建实体类型。
  2. 将已知资产加载为主数据实体。
  3. 添加 SCADA、ERP、工单和巡检系统的别名。
  4. 在人工审阅队列中处理不确定别名。
  5. 在 Inspector、维护计划、能源分析或 AI Agent 工作流中使用治理后的身份对照表。

实施要点：

  • 审阅别名前先准备设备类别和位置参考数据。
  • 当一个设备对应多个 BMS 或 SCADA 点位时，区分点位身份和可维护设备身份。
  • 孤立点位应和设施 owner 一起审阅，不应只当作缺失数据处理。
  • 记录下游使用场景：巡检路线、维护计划、能源分析或 AI Agent 证据。

HeatOps 与公用工程设备主数据​

对供热、园区公用工程和设施运营场景，可以用 MDM device 主记录表示设备主数据。每个物理设备可以同时携带来自 SCADA、ERP、工单和巡检系统的别名。

当运营页面需要以“一个物理设备一行”的方式展示多源身份时，可采用这个模式：

MDM 概念设施运营中的用途
device 实体可维护的物理设备，例如换热站设备、水泵、空调机组或仪表。
SCADA 别名运行点位或控制器侧标识。
ERP 别名财务或资产管理系统中的资产号。
工单别名工单目标或维护对象 ID。
巡检别名巡检路线对象或点检点 ID。

这样运营人员可以看到一个受治理的设备身份，同时保留实时读数、维修记录、巡检证据和 AI Agent 检索所需的源系统 ID。

预测性维护​

使用 MDM 对齐信号、维护历史、巡检发现和资产元数据。

流程：

  1. 确认目标实体类型，例如设备、装置或部件。
  2. 将传感器历史映射到稳定别名。
  3. 将工单和巡检发现映射到同一实体 ID。
  4. 用参考数据管理状态、严重度、故障分类和单位。
  5. 构建用于特征准备和模型证据的治理数据集。
  6. 在模型输出进入运营前审阅未解决身份问题。

当预测性维护使用 MDM 输出时，应把身份解析视为模型上线准备的一部分。即使模型管线本身健康，如果传感器历史、工单、巡检和资产元数据分别指向同一资产的不同版本，结果仍然不可靠。

实施要点：

  • 特征准备前，先把传感器、工单、巡检和资产元数据解析到同一个主数据实体。
  • 在特征数据集 lineage 中保留原始源 ID，便于回溯模型证据。
  • 将未解决身份问题和普通缺失传感器值分开跟踪。
  • 影响目标资产的身份异常未审阅前，不应把预测输出用于运营决策。

可靠性与事件审阅​

当多个系统用不同 ID 描述资产、部件、事件或可靠性观察时，使用 MDM。

流程：

  1. 为需要稳定身份的对象创建实体类型。
  2. 维护代码和分类参考数据。
  3. 将源 ID 解析到主数据实体。
  4. 使用事件融合提出重复事件候选。
  5. 审阅候选和已拒绝关系。
  6. 发布治理输出用于分析或报表。

实施要点：

  • 设计别名前先定义主对象是资产、部件、零件还是事件组。
  • 用参考数据管理故障分类、严重度、状态和巡检结果。
  • 保留已拒绝事件关系，避免错误重复分组每次运行都返回。
  • 面向需要审计的用户，同时发布原始事件计数和已审阅事件计数。

使用归一化别名稳定可靠性身份​

可靠性工作流经常会收到同一资产或设备身份的多种写法。一个源系统可能带有标点、前缀或本地命名规则，另一个源系统则使用缩写形式。集成流程可以先计算归一化值，把它随源系统别名写入 MDM，再由 MDM 通过别名台账解析。

当融合数据集需要稳定实体 ID 时，可以采用这个模式：

  1. 保留原始源 ID，作为审计线索。
  2. 在生效的 MDM 交叉引用记录上保存来源侧归一化别名。
  3. 在融合输出过程中解析该归一化键。
  4. 将 MDM 实体 ID 写入融合事件或可靠性记录。
  5. 无法解析或存在歧义的记录进入人工审阅。

这样报表、AI Agent 证据和可靠性分析可以基于受治理实体 ID 关联数据，同时仍保留审计所需的源 ID 和字段证据。

AI Agent 证据​

当 AI Agent 需要用源系统证据解释运营状态时，使用 MDM。

流程：

  1. 定义 Agent 可推理的对象范围。
  2. 通过 MDM 别名将源记录解析到该对象。
  3. 提供包含实体 ID、源 ID、时间戳和 lineage 的审阅数据。
  4. 在 Agent 交接中说明未解决身份问题。
  5. 用源证据验证 Agent 输出。

向 Agent 提供来自 MDM 的已审阅身份依据。身份决策应在 MDM 和 steward 工作流中完成。

实施要点：

  • 同时提供实体 ID、源 ID、源时间戳和 lineage。
  • 在检索过滤或交接说明中包含未解决身份问题，避免 Agent 夸大覆盖范围。
  • 合并、拆分或重定向后刷新面向 Agent 的数据集。
  • 将 MDM 状态和人工审阅决策作为证据元数据，供 Agent 引用和追溯。

下一步​

继续阅读 API 参考。