オントロジーに基づいた故障診断システム、フリートケースの再利用とAI技術との融合

機械学習技術 デジタルトランスフォーメーション技術 人工知能技術 セマンティックウェブ技術 オントロジー技術 ウェブ技術 知識情報処理技術 ワークフロー&サービス 異常検知と変化検知技術 本ブログのナビ

フリートケース、故障診断システムとオントロジー

フリートケース（Fleet Case）は、複数の機器や製品を保有する企業が、それらの機器や製品の故障診断やメンテナンスを効率的かつ正確に行うためのシステムで、オントロジーに基づいた知識ベースとして構築され、企業が保有する機器や製品の構造、機能、部品の関係性などの情報を体系的に整理するものとなる。このフリートケースは、以下のような特徴を持つ。

• 大量のデータを扱うことが可能：複数の機器や製品に関する情報を、オントロジーに基づいて統合することができる。
• 故障診断が容易：オントロジーに基づいた知識ベースを利用することにより、故障原因の特定が容易になる。
• メンテナンスが効率的：オントロジーに基づいた知識ベースを利用することにより、メンテナンス作業の計画や手順が効率的に行える。
• 再利用が容易：オントロジーに基づく知識ベースを構築することにより、再利用によるコスト削減やシステムの一元管理が可能になる。
• 分析が可能：複数の機器や製品に関する情報を統合することにより、分析や改善のためのデータを取得することができる。

フリートケースは、製造業やエネルギー産業、交通機関などの分野で活用されており、企業が保有する機器や製品を最適化し、故障診断やメンテナンスを効率的に行うことができるため、生産性の向上やコスト削減につながることが期待されている。

故障診断システムは、製品や機器の故障を自動的に検知し、原因を特定するためのシステムで、センサーデータ、ログデータ、障害情報などから機械学習やデータマイニングなどの手法を用いて故障原因を特定し、修理や交換が必要な部品を特定することができるものとなる。前述のフリートケースは、複数の機器や製品を保有する企業が、それらの機器や製品の故障診断やメンテナンスを効率的かつ正確に行うためのシステムであり、故障診断システムの一種ともいえる。

これらにオントロジーを適用することにより、製品の構造、機能、部品の関係性などの情報を体系的に整理することができ、故障診断やメンテナンスを行うための知識ベースとして利用できると共に各製品ラインの故障診断システムを共有することができ、再利用によるコスト削減や、システムの一元管理が可能となる。

また、オントロジーに基づく故障診断システムやフリートケースは、外部への再利用も可能となる。例えば、同業他社が同様の製品を保有している場合、オントロジーを共有することにより、製品の故障診断やメンテナンスを効率的に行うことができ、他社との共同開発や、製品サポートを提供する新しいビジネスモデルの構築が可能となる。

オントロジーに基づく故障診断システムやフリートケースの再利用を行う際には、以下のようなことを注意する必要がある。

• オントロジーの適用範囲を明確にする必要がある。
• 業界標準のオントロジーを利用することが望ましい。
• オントロジーの更新やメンテナンスを継続的に行う必要がある。
• セキュリティ対策を十分に考慮する必要がある。

これらの注意点を考慮することにより、オントロジーに基づく故障診断システムやフリートケースの再利用を行うことができるようになる。ここでは、この故障診断システムやフリートケースとオントロジーに関して「Ontology Modeling in Physical Asset Management」をベースに述べる。

オントロジーに基づいた故障診断システム、フリートケースの再利用

「物理的資産の整合性は，安全性，環境，およびコストの観点から機器の機能を受容可能なレベルに維持するために，システムエンジニアリングの開発プロセスに基づくライフサイクルの概念である。メンテナンスは，システムの可用性，性能効率，製品品質を向上させることで，このような目的において重要な役割を果たしている（Alsyouf 2007）。メンテナンスを付加価値のあるプロセスとして考えるには、メンテナンス戦略を進化させる必要があります。失敗したら修理する」から「予測したら予防する」アプローチへと、新しい保守スキーマを進化させる必要があります。この新しいビジョンは、状態ベースの保守（CBM+）や予知・健康管理（PHM）の保守戦略の進化によってサポートされている（Iung et al.2009）。しかし、このような先を見越したアプローチにもかかわらず、故障は依然として発生しています。
予期せぬシステム故障の影響を最小限に抑えるためには，故障診断の効率を向上させる必要がある（Lei et al.2008; Zio et al.2008）．古典的な診断技術を考えた場合，予期せぬ事態は局所的な視点，すなわち機器レベルで検出される．しかし，複雑なシステムを考えた場合，システム全体が監視されていない可能性があり，機器と環境の間の相互作用によって性能が変動するため，古典的な手法は役に立たないかもしれない．そのため，保守担当者は次のような原因についての仮説を立てる必要があります．症状の発生に基づいて，故障や性能の異常が発生することがある(Moss et al. 2010)．このような状況では，機械的，電気的，電子的，またはソフトウェア的な性質を持つ複数の技術に基づいて構築された部品の劣化メカニズムに関する知識が必要になります（Verma et al.2010）．性能は、ライフサイクルの段階や使用条件によって変化する可能性があります（Bonissone and Varma 2005）。このような作業は，専門家の知識に依存しているため，特に若手メンテナや専門家にとっては難しいかもしれない．このような知識は、まずエキスパートが学んだ理論的な知識に基づいて構築され、次に実際のケースに診断を適用した経験に基づいて構築されます。エキスパートは人間の性質上、原因の特定に失敗することがあります。
発電所、船舶、航空機などの大規模で複雑なシステムの診断プロセスを保守担当者レベルで改善するためには、「フリート」という次元を活用することが一つの方法です。この次元は，保守担当者を支援するためのより多くのノウハウとデータを提供する（Monnin et al.2011a）．
フリートは、システム、サブシステム、コンポーネントの集合体と見なすことができる。ここでは海軍の領域を対象としているため，以下では，対象物に応じて，フリートのユニットをシステム（船舶など），サブシステム（推進装置や発電装置など），コンポーネント（ディーゼルエンジンやシャフトなど）とみなす．

各ユニットの個々の知識は、ケーススタディで例となる予測診断などのPHM活動を改善するために、活用され再利用される。フリートレベルでの個々の知識を活用するために、オントロジーを用いた海軍領域のPHM活動のセマンティックモデルを提案しています。このアプローチの特徴は、オントロジーが、PHMプロセスや、インターエストのドメイン（海軍ドメイン）から生じる知識を表現し、構造化することにある。通常、PHM領域のオントロジーを使用するアプリケーションは、特定のPHMプロセスや単一のコンポーネントに関する知識（電気モーターの診断に関する知識など）に焦点を当てています。このようにして、コンテキストと呼ばれるPHMおよびシステム・ドメインに関連する複数のカテゴリーの概念がモデル化され、これらの概念間の関係が明示されます。このようなセマンティック・モデルにより、より多くの知識を提供するために、メンテナンス記録、信頼性分析、故障分析、フリート・レベルでのモニタリング・データ分析など、特定のデータを再利用することができる。データが利用可能になると、PHM活動はより多くのコンテキスト情報から恩恵を受けます。」

5.1 Introduction 
　　　　　　　　(はじめに)
5.2 Context of Diagnosis of Complex System 
    (複雑系の診断の背景)
5.3 PHM Vs. Fleet-Wide Approach
    (PHMとフリート・ワイド・アプローチ)
  5.3.1 Fleet Integrated PHM Review
        (艦隊統合型PHMのレビュー)
  5.3.2 Predictive Diagnosis Using Fleet-Wide Knowledge
        (フリートワイドな知識を用いた予測診断)
  5.3.3 Sub-fleet Characterization
        (サブフリートの特性評価)
5.4 Ontology for Fleet-Wide Semantic Knowledge Modeling
    (フリート・ワイド・セマンティック・ナレッジ・モデリングのためのオントロジー)
  5.4.1 Providing Semantic Through Ontology
        (オントロジーによるセマンティックの提供)
  5.4.2 Ontology-Based PHM Knowledge Modeling Rules
        (オントロジーベースのPHM知識モデリングルール)
     5.4.2.1 To Define the Key Concepts of the Domain
             (ドメインのキーコンセプトを定義するために)
     5.4.2.2 To Define a Class Hierarchy (Subsumption)
             (クラス階層を定義するには（サブサンプション)
     5.4.2.3 To Describe and Define Classes
             (クラスを記述・定義する)
     5.4.2.4 To Define Properties of Classes
             (クラスのプロパティを定義するには)
     5.4.2.5 To Define the Value Type, the Cardinality and the Allowed Values of Classes
             (クラスの値の種類、カーディナリティ、許容値を定義するには)
     5.4.2.6 To Create Instances
             (インスタンスを作成するには)
  5.4.3 Ontology for PHM and Marine Domains
        (PHMと海洋領域のオントロジー)
     5.4.3.1 Technical Context
             (テクニカルコンテクスト)
     5.4.3.2 Dysfunctional Context
             (機能不全のコンテクスト)
     5.4.3.3 Operational Context
             (オペレーショナルコンテクスト)
     5.4.3.4 Service Context
             (サービスコンテキスト)
     5.4.3.5 Application Context
             (アプリケーションコンテクスト)
     5.4.3.6 Relations Between the Contexts
             (コンテクスト間の関係)
5.5 Application
    (アプリケーション)
  5.5.1 Fleet-Wide Diagnosis Software
        (フリートワイド診断ソフトウェア)
  5.5.2 Case Study
        (ケーススタディ)
5.6 Conclusions and Perspectives
    (結論と今後の展望)