異常と保全提案は、モデル出力を運用アクションに変換します。保全オーナーが、何が起きたか、証拠はどこから来たか、何が不足しているか、現場確認または作業指示が必要かを判断できる状態にします。
レビューフロー
前提条件
| 要件 | 内容 |
|---|
| 設備コンテキスト | equipment、location、class、owner、source aliases。 |
| 信号証拠 | 異常前後の key readings、quality status、time window。 |
| 保全履歴 | 最近の作業指示、点検、部品交換、現場メモ。 |
| 判断担当者 | 提案を承認、延期、却下できる担当者。 |
| 作業指示経路 | 作業を作成、接続、同期する方法。 |
異常レビュー
| 項目 | 質問 |
|---|
| Severity | safety、production、service、critical asset に影響するか。 |
| Time window | いつ始まり、現在も継続しているか。 |
| Equipment state | running、stopped、maintenance、abnormal condition のどれか。 |
| Signal evidence | どの信号が baseline から外れ、品質は信頼できるか。 |
| Recent work | 修理、交換、点検、設定変更が説明できるか。 |
| Nearby assets | 同じ system または上下流設備に変化があるか。 |
保全提案レビュー
異常から管理対象の Finding 詳細を開く場合、対応前に standard、設備 baseline、model、data-quality evidence を分けてレビューします。タスクと権限の詳細は Finding をレビューしてフィードバックを記録する を参照します。
| Field | 内容 |
|---|
| Proposed action | 点検、清掃、校正、部品交換、監視、エスカレーション。 |
| Evidence | 異常、信号傾向、点検記録、文書、最近の作業指示。 |
| Priority | impact、criticality、duration、safety requirement に基づく。 |
| Missing information | 現場確認、追加 readings、文書、担当者判断。 |
| Owner | 保全、運用、データ、contractor。 |
判断経路
| 判断 | 記録 |
|---|
| 承認 | 作業指示を作成または接続し、証拠と action を保持。 |
| 延期 | 再確認時期、待ち条件、owner を記録。 |
| 却下 | 誤検知、data issue、運転条件説明、duplicate を記録。 |
| データ修正 | asset mapping、unit、timestamp、不足信号を data owner に戻す。 |
期待される出力
- レビュー済み異常記録；
- 提案を支持または弱める証拠；
- 承認、延期、却下、データ修正判断；
- 作成または接続済み作業指示；
- モデルとルール改善に使える feedback。
検証チェックリスト
- 異常に equipment、time、signal、quality context がある。
- proposed action が evidence と整合している。
- 判断 owner が追跡できる。
- 却下と延期に理由がある。
- 承認済み提案が作業指示ループに入っている。
トラブルシューティング
| 症状 | 対応 |
|---|
| 異常に証拠がない | signal history、inspection、data quality に戻ります。 |
| 提案が一般的すぎる | equipment class、failure mode、SOP、recent work context を追加します。 |
| 同じ提案が繰り返される | 未完了の作業指示または未回収の結果フィードバックを確認します。 |
| 誤検知が多い | baseline window、running-state filter、threshold strategy を確認します。 |
関連ドキュメント