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 和 steward 工作流中完成。
實施要點：
- 同時提供 entity ID、source IDs、source timestamps 和 lineage。
- 在檢索過濾或交接說明中包含未解決身分問題，避免 Agent 誇大覆蓋範圍。
- merge、split 或 re-point 後刷新面向 Agent 的資料集。
- 將 MDM 狀態和 steward decisions 作為證據中繼資料，而不是生成式結論。
下一步
繼續閱讀 API Reference。