メインコンテンツまでスキップ

MDM 業界レシピ

以下のレシピは、DFS MDM が運用ワークフローをどのように支援するかを示します。実装時は、プロジェクトのソースシステム、ガバナンスモデル、導入範囲に合わせて調整してください。

レシピ構造​

パターンを顧客実装へ落とし込むときは、同じ構造を使います。

各レシピでは、管理する対象、関係するソースシステム、steward owner、管理済み出力を使う下流ワークフローを明確にします。

施設とユーティリティ運用​

MDM を使い、物理設備と運用システムをつなぎます。

ソース典型的な ID
建物または施設モデル設備または資産 ID。
SCADA/BMSポイント名、tag、コントローラーパス。
ERP/EAM資産番号。
作業指示システム保全対象または作業対象。
点検システム点検ポイントまたはルート対象。

手順：

  1. 設備またはデバイスの entity type を作成します。
  2. 既知の資産を master entities として読み込みます。
  3. SCADA、ERP、作業指示、点検システムの aliases を追加します。
  4. steward queue で不確実な aliases をレビューします。
  5. Inspector、保全計画、エネルギー分析、AI Agent ワークフローで管理済み crosswalk を使います。

実装メモ：

  • aliases をレビューする前に equipment class と location reference data を準備します。
  • 1 つの設備に複数の BMS または SCADA ポイントがある場合、ポイント ID と保全対象設備 ID を分けて扱います。
  • orphan tags は欠損データとしてだけでなく、施設 owner と一緒にレビューします。
  • 下流利用先を記録します。点検ルート、保全計画、エネルギー分析、AI Agent 証跡などです。

予知保全​

MDM で信号、保全履歴、点検所見、資産メタデータを揃えます。

手順：

  1. equipment、device、component などの対象 entity type を確認します。
  2. センサー履歴を安定した aliases にマッピングします。
  3. 作業指示と点検所見を同じ entity IDs にマッピングします。
  4. 状態、重要度、故障カテゴリ、単位を reference data で管理します。
  5. 特徴量準備とモデル証跡に使う管理済みデータセットを作成します。
  6. モデル出力を運用利用する前に、未解決 ID 問題をレビューします。

実装メモ：

  • 特徴量準備の前に、センサー、作業指示、点検、資産メタデータを同じ master entity へ解決します。
  • モデル証跡を追跡できるよう、feature dataset の lineage に raw source IDs を残します。
  • 未解決 ID 問題は、通常のセンサー欠損値とは分けて追跡します。
  • 対象資産に影響する ID 例外が未レビューの場合、予測結果を運用判断に使わないでください。

信頼性とイベントレビュー​

複数システムが資産、部品、イベント、信頼性観測を異なる ID で表す場合に MDM を使います。

手順：

  1. 安定 ID が必要な対象の entity types を作成します。
  2. コードとカテゴリの reference data を管理します。
  3. source IDs を master entities に解決します。
  4. event fusion で重複イベント候補を作成します。
  5. 候補と rejected pairs をレビューします。
  6. 分析またはレポート向けに管理済み出力を公開します。

実装メモ：

  • alias を設計する前に、主対象が資産、コンポーネント、部品、イベントグループのどれかを定義します。
  • 故障カテゴリ、重要度、状態、点検結果コードには reference data を使います。
  • rejected event pairs を保持し、誤った重複候補が毎回戻らないようにします。
  • 監査性が必要な利用者には raw event counts と reviewed event counts の両方を公開します。

正規化エイリアスで信頼性 ID を安定させる​

信頼性ワークフローでは、同じ資産または設備 ID が複数の表記で届くことがあります。あるソースは句読点、接頭辞、ローカル命名規則を含み、別のソースは短縮形を使う場合があります。連携フローで正規化値を計算し、ソース別名と一緒に 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 aliases を通じてソースレコードをその対象へ解決します。
  3. entity ID、source IDs、timestamps、lineage を含むレビュー済みデータを提供します。
  4. Agent 引き渡し時に未解決 ID 問題を明記します。
  5. Agent 出力をソース証跡で検証します。

Agent に名称だけで ID を判断させないでください。ID 判断は MDM と steward ワークフローで行います。

実装メモ：

  • entity ID、source IDs、source timestamps、lineage を一緒に提供します。
  • 未解決 ID 問題を retrieval filters または引き渡しメモに含め、Agent がカバレッジを過大に述べないようにします。
  • merge、split、re-point 後は Agent 向けデータセットを更新します。
  • MDM ステータスと担当者レビューの判断は証跡メタデータとして Agent 向けデータセットに保持します。

次に読む​

API Reference を参照してください。