MDM 故障事件融合
故障事件融合用於審閱多個來源系統記錄是否描述同一個真實事件。當系統用不同描述、時間戳、分類或 ID 上報相似故障時，這個流程可以減少漏合和重複計數。
本頁描述治理模式，具體打分設定取決於實施和來源系統。
目前審閱介面
故障事件審閱介面與主資料實體審閱介面分開：
| 動作 | API 族 |
|---|---|
| 查詢候選 | /api/v1/dfslite/fault-fusion/candidates |
| 批准重複分組 | /api/v1/dfslite/fault-fusion/candidates/{id}/approve |
| 拒絕重複分組 | /api/v1/dfslite/fault-fusion/candidates/{id}/reject |
讀取使用 DFS 讀取權限；批准和拒絕會寫入審閱決策。規劃 API 級整合時，請參考 MDM API Reference。
候選生成邊界
故障事件融合可能產生大量重複事件候選。生產執行中，融合方法應透過受治理的審閱介面建立候選，並返回 persisted 和 skipped candidate 等執行數量。操作人員隨後透過 UI 或 API 審閱候選。
候選是人工決策的證據。下游報表、可靠性分析、AI Agent 證據檢索和維護工作流在需要事件身分時，應使用已確認分組或審閱後的事件資料集。
| 執行輸出 | 含義 | 查看位置 |
|---|---|---|
| Persisted candidate count | 已建立進入審閱的候選分組數量。 | 故障融合候選佇列。 |
| Skipped candidate count | 未寫入的候選數量，通常因為為空、無效、重複或超出範圍。 | 執行歷史和任務日誌。 |
| Approved group | 人工確認多條記錄描述同一事件。 | 審閱後事件輸出和下游資料集。 |
| Rejected group or pair | 人工拒絕重複關係。 | 用於抑制重複誤報的拒絕歷史。 |
已發布規則集視圖
DFS Pro 中的故障融合入口展示目前部署環境已發布的融合規則集。透過該視圖可以查看融合服務實際使用的欄位提取、匹配規則、幸存規則、置信度權重和 AI 輔助設定。某個規則區塊為空，表示對應流程尚未設定。
這樣審閱人員看到的規則與實際融合執行保持一致。培訓和交接材料也應以運行任務使用的已發布規則集為準。
適用場景
- 多個系統上報同一故障或事件。
- 自然鍵無法識別描述或時間略有差異的重複事件。
- 報表重複統計事件。
- 維護、巡檢或可靠性分析需要審閱後的事件身分。
- AI Agent 回答需要引用多個來源系統的證據。
工作流
候選信號
| 信號 | 作用 |
|---|---|
| 已解析實體 ID | 確認記錄指向同一物件。 |
| 時間窗口 | 找到足夠接近的記錄。 |
| 描述相似度 | 識別同一狀態的不同表述。 |
| 分類或嚴重度 | 輔助比較來源系統分類。 |
| 工單或巡檢關聯 | 提供營運證據。 |
確認事件分組前應綜合多個信號。不同資產上的相似描述應按獨立事件處理。
衝突比較範圍
衝突比較應聚焦會改變事件業務含義的欄位，例如受治理身分、時間窗口、狀態、嚴重度、分類、資產類型、批次上下文、設備狀態、維護對象等。自由文字訊息和來源系統專用代碼通常適合作為審閱證據；當多個系統用各自口徑描述同一事件時，把這些欄位直接作為衝突欄位容易放大噪聲。
任務進入常規運行前，應抽樣檢查衝突計數欄位。證據豐富的欄位可以繼續保留在來源證據和審閱視圖中，衝突標記則用於提示真正需要人工關注的差異。
事件分組狀態
用清晰狀態區分原始事件和已審閱事件分組，避免下游誤讀。
| 狀態 | 含義 | 下游使用方式 |
|---|---|---|
| Raw | 來源事件尚未比較。 | 用於來源系統稽核和匯入排錯。 |
| Candidate | Resolver 找到可能重複的分組。 | 僅用於 steward review。 |
| Confirmed group | Steward 確認多筆記錄描述同一事件。 | 用於可靠性分析、事件計數、AI Agent 證據和報表。 |
| Rejected pair | Steward 拒絕候選關係。 | 用於避免同一誤報再次出現。 |
| Split required | 候選分組中包含多個真實事件。 | 發布 reviewed output 前需要拆分。 |
審閱步驟
- 檢查資產或設備身分。
- 比較來源時間戳。
- 比較故障描述、分類和嚴重度。
- 有條件時檢查工單或巡檢證據。
- 判斷是否描述同一事件。
- 拒絕僅表面相似的候選。
審閱時同時檢查事件證據和營運跟進記錄。故障記錄和工單可能使用不同文字描述同一事件；相同告警文字也可能因為資產或運行窗口不同而代表不同事件。
Reviewed output 欄位
審閱後的事件資料集應暴露足夠上下文，便於下游團隊使用：
| 欄位 | 用途 |
|---|---|
| Reviewed event ID | 確認事件分組的穩定標識。 |
| Master entity ID | 將事件連接到受治理的資產或設備身分。 |
| Source event IDs | 保留回溯到原始來源系統記錄的能力。 |
| Primary timestamp | 定義報表使用的事件時間。 |
| Time window | 說明分組包含的來源記錄時間範圍。 |
| Review status | 區分 raw、candidate、confirmed、rejected 和 split-required。 |
| Decision note | 解釋影響可靠性報表或 AI Agent 回答的人工決策。 |
發布 reviewed IDs 時應同時保留 raw source IDs，方便稽核人員把回答或報表追溯到原始系統記錄。
輸出用途
確認後的事件分組可用於：
- 可靠性分析；
- 預測性維護證據；
- 事故或異常複盤；
- 巡檢與工單跟進；
- BI 報表；
- AI Agent 證據解釋。
實施場景
設施或製造環境中的典型設定如下：
- DFS Lite 匯入告警、維修請求、巡檢發現和工單記錄。
- MDM 先解析資產或設備身分，再開始事件分組。
- Resolver 基於 entity ID、時間窗口、文字相似度、分類和工單證據提出候選事件分組。
- Steward 在佇列中確認或拒絕分組。
- DFS Pro 發布包含 raw source IDs 和 reviewed event IDs 的審閱後事件資料集。
- Inspector、可靠性報表或 AI Agent 工作流使用 reviewed event identity，減少重複事件計數，並引用來源系統證據。
當來源系統已經具備較一致的資產身分、事件時間和營運分類時，該場景效果最好。欄位較弱時，應先改善映射，再把 resolver 擴展到更多來源系統。
檢查清單
- 在信任事件分組前，資產或設備身分已經解析。
- 時間窗口符合業務場景。
- 相似度作為審閱信號使用。
- 被拒絕候選已記錄。
- 下游報表說明使用 raw events 還是 reviewed event groups。
- Reviewed event output 包含 raw source IDs，便於稽核。
- Confirmed groups 已抽樣核對工單或巡檢證據。
- Split-required groups 在進入生產報表前已處理。
常見問題
| 現象 | 可能原因 | 處理 |
|---|---|---|
| 重複事件仍然存在 | 時間窗口過窄或資產身分未解析。 | 審閱 entity aliases 和 scoring configuration。 |
| 不同事件被合併 | 時間窗口過寬或描述匹配過鬆。 | 收緊規則並拒絕錯誤分組。 |
| 審閱佇列過大 | 來源資料品質或 match keys 較弱。 | 改善來源映射並增加更強身分信號。 |
| AI 回答引用證據混亂 | Raw events 和 reviewed event sets 混用。 | 明確交付 reviewed dataset 或 grouping status。 |
下一步
繼續閱讀 Industry Recipes。