MDM 行业场景配方
以下配方展示 DFS MDM 如何支持运营工作流。实施时应根据项目的源系统、治理模型和部署范围调整。
配方结构
把一个场景落到客户项目时，建议使用同一结构：
每个配方都应明确要治理的对象、涉及的源系统、steward owner，以及消费治理输出的下游工作流。
设施与公用工程运营
使用 MDM 将物理设备与运营系统连接起来。
| 来源 | 典型身份 |
|---|---|
| 建筑或设施模型 | 设备或资产 ID。 |
| SCADA/BMS | 点位名、tag 或控制器路径。 |
| ERP/EAM | 资产号。 |
| 工单系统 | 维护对象或工单目标。 |
| 巡检系统 | 巡检点或路线对象。 |
流程：
- 为设备或装置创建 entity type。
- 将已知资产加载为 master entities。
- 添加 SCADA、ERP、工单和巡检系统的 aliases。
- 在 steward queue 中审阅不确定 aliases。
- 在 Inspector、维护计划、能源分析或 AI Agent 工作流中使用治理后的 crosswalk。
实施要点：
- 审阅 aliases 前先准备 equipment class 和 location reference data。
- 当一个设备对应多个 BMS 或 SCADA 点位时，区分点位身份和可维护设备身份。
- Orphan tags 应和设施 owner 一起审阅，不应只当作缺失数据处理。
- 记录下游使用场景：巡检路线、维护计划、能源分析或 AI Agent 证据。
预测性维护
使用 MDM 对齐信号、维护历史、巡检发现和资产元数据。
流程：
- 确认目标 entity type，例如 equipment、device 或 component。
- 将传感器历史映射到稳定 aliases。
- 将工单和巡检发现映射到同一 entity IDs。
- 用 reference data 管理状态、严重度、故障分类和单位。
- 构建用于特征准备和模型证据的治理数据集。
- 在模型输出进入运营前审阅未解决身份问题。
实施要点：
- 特征准备前，先把传感器、工单、巡检和资产元数据解析到同一个 master entity。
- 在特征数据集 lineage 中保留 raw source IDs，便于回溯模型证据。
- 将未解决身份问题和普通缺失传感器值分开跟踪。
- 影响目标资产的身份异常未审阅前，不应把预测输出用于运营决策。
可靠性与事件审阅
当多个系统用不同 ID 描述资产、部件、事件或可靠性观察时，使用 MDM。
流程：
- 为需要稳定身份的对象创建 entity types。
- 维护代码和分类 reference data。
- 将 source IDs 解析到 master entities。
- 使用 event fusion 提出重复事件候选。
- 审阅候选和 rejected pairs。
- 发布治理输出用于分析或报表。
实施要点：
- 设计 alias 前先定义主对象是资产、部件、零件还是事件组。
- 用 reference data 管理故障分类、严重度、状态和巡检结果。
- 保留 rejected event pairs，避免错误重复分组每次运行都返回。
- 面向需要审计的用户，同时发布 raw event counts 和 reviewed event counts。
AI Agent 证据
当 AI Agent 需要用源系统证据解释运营状态时，使用 MDM。
流程：
- 定义 Agent 可推理的对象范围。
- 通过 MDM aliases 将源记录解析到该对象。
- 提供包含 entity ID、source IDs、timestamps 和 lineage 的审阅数据。
- 在 Agent 交接中说明未解决身份问题。
- 用源证据验证 Agent 输出。
向 Agent 提供来自 MDM 的已审阅身份依据。身份决策应在 MDM 和 steward 工作流中完成。
实施要点：
- 同时提供 entity ID、source IDs、source timestamps 和 lineage。
- 在检索过滤或交接说明中包含未解决身份问题，避免 Agent 夸大覆盖范围。
- merge、split 或 re-point 后刷新面向 Agent 的数据集。
- 将 MDM 状态和 steward decisions 作为证据元数据，而不是生成式结论。
下一步
继续阅读 API Reference。