(57)【特許請求の範囲】
【請求項１】
診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、センサにより計測される前記診断対象アセットの状態を表す計測値及び前記診断基準に基づき当該診断対象アセットの故障モードの発生を検出又は予測する自動診断部と、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも前記自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、
前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする保全管理システム。
【請求項２】
請求項１に記載の保全管理システムにおいて、
前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、一致度を算出し、当該算出した一致度に基づいて保全作業に自動診断結果が用いられたことを検出することを特徴とする保全管理システム。
【請求項３】
請求項２に記載の保全管理システムにおいて、
前記故障情報データベースは、診断対象アセットを構成する複数のコンポーネント間の階層関係を表すネットワークを格納し、
前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容に対応するコンポーネントと、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法に対応するコンポーネントとのネットワーク上の距離に基づく減少関数を用いて前記一致度を算出することを特徴とする保全管理システム。
【請求項４】
請求項２に記載の保全管理システムにおいて、
少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を算出する課金処理装置を備えることを特徴とする保全管理システム。
【請求項５】
請求項３に記載の保全管理システムにおいて、
少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を算出する課金処理装置を備えることを特徴とする保全管理システム。
【請求項６】
請求項４に記載の保全管理システムにおいて、
前記課金処理装置は、
少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を推定する課金額推定部と、
課金額推定部により推定された課金額を表示装置の画面上に表示させると共に、前記画面上に表示された推定された課金額に対する修正入力に基づき、前記自動診断部による診断結果の利用に対する課金額を決定する課金額決定部と、を備えることを特徴とする保全管理システム。
【請求項７】
請求項５に記載の保全管理システムにおいて、
前記課金処理装置は、
少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を推定する課金額推定部と、
課金額推定部により推定された課金額を表示装置の画面上に表示させると共に、前記画面上に表示された推定された課金額に対する修正入力に基づき、前記自動診断部による診断結果の利用に対する課金額を決定する課金額決定部と、を備えることを特徴とする保全管理システム。
【請求項８】
請求項６に記載の保全管理システムにおいて、
前記課金額推定部は、前記タスク実績分析部により算出された一致度及び前記自動診断結果ログ記憶部に記録された発報された警報に関する情報並びに保全作業に自動診断結果を用いることで得られる利益に基づき、前記自動診断部による診断結果の利用に対する課金額を推定することを特徴とする保全管理システム。
【請求項９】
請求項７に記載の保全管理システムにおいて、
前記課金額推定部は、前記タスク実績分析部により算出された一致度及び前記自動診断結果ログ記憶部に記録された発報された警報に関する情報並びに保全作業に自動診断結果を用いることで得られる利益に基づき、前記自動診断部による診断結果の利用に対する課金額を推定することを特徴とする保全管理システム。
【請求項１０】
診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、
前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする保全管理確認装置。
【請求項１１】
請求項１０に記載の保全管理確認装置において、
前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、一致度を算出し、当該算出した一致度に基づいて保全作業に自動診断結果が用いられたことを検出することを特徴とする保全管理確認装置。
【請求項１２】
請求項１１に記載の保全管理確認装置において、
前記故障情報データベースは、診断対象アセットを構成する複数のコンポーネント間の階層関係を表すネットワークを格納し、
前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容に対応するコンポーネントと、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法に対応するコンポーネントとのネットワーク上の距離に基づく減少関数を用いて前記一致度を算出することを特徴とする保全管理確認装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器の診断システムと連携して動作する、保全の管理システムに係り、特に、保全管理の対象となる機器に対する自動診断を実行する自動診断部を有する保全管理システム及びそれに用いる保全管理確認装置に関する。
【背景技術】
【０００２】
インフラ、鉄道、産業機器、医療機器などの多くの分野では、アセット（各種機器）の導入後は保全を継続的に実施することで、所定の性能を維持する必要がある。保全においては対象アセットの状態を収集し、異常の有無や問題点を分析する診断を適用した上で、適切な保全作業を適用する。  
近年の情報技術の発達により、アセットの状態をセンサで収集することで、自動的にアセットの診断あるいは予兆診断を行うシステムの利用が可能となっており、保全管理者は、自動診断部が発報するアラームを参照して保全作業指示をだすことが可能となっている。従って、自動診断部の性能は、保全作業の効率に重大な影響を及ぼす。適切なアラームに基づいて保全作業を行った場合は、作業員による診断の作業を短縮したり、故障の影響がアセットの運用に影響を及ぼしたり、アセットの劣化・破壊が進展することで損害が発生するといった問題を避けることが可能となる。  
このような情報技術に基づく診断技術を用いた保全を構築する場合、情報システムを提供する保全ＩＴ事業者と、実際に保全作業を行う保全事業者が別組織の場合が多く見られる。この場合、保全ＩＴ事業者は開発した情報システム（診断システム）を保全事業者に提供して代価を受け取り、保全事業者は提供された情報システム（診断システム）が出力する診断結果に基づいて保全作業を実施する。【０００３】
診断システムの提供においては、主に導入時に保全ＩＴ事業者は保全事業者から代金の支払いを受け、その後はシステムの保全費用や運用に当たってのサポート費用を受け取ることが一般的であるが、他の形態も考えられる。例えば、運用中に保全事業者が診断技術の利用によって得た利益から、システムの利用料を保全ＩＴ事業者に支払うことも考えられる。このような形態をとる場合、保全ＩＴ事業者は、より性能の高い自動診断部を有する診断システムやアルゴリズムを提供するインセンティブが働くため、システム性能の改善が可能となり、それを通じて保全事業者は利益を得て、ひいてはアセットの運用状態の改善が可能となる。  
自動診断部を有する診断システムの利用によって得た利益の一部を、使用量として支払う技術として、例えば、特許文献１に記載される技術が知られている。特許文献１では、故障診断システムの故障診断プログラムの対価を正当に評価することを可能とするため、携帯情報端末等の故障診断装置に予め故障診断プログラムをインストールし、被故障診断機器であるガス機器（例えば、ガス給湯器）に対して、通信線を接続するなどして通信可能にし、故障診断プログラムに従って表示される故障診断メニューを適宜選択し、プログラムからの質問に応答、或いはプログラムからの指示に対応する操作を被故障診断機器に与えることで、故障原因、故障部品を特定する旨開示されている。  
そして、一定期間毎に、従来の故障診断方法による故障診断結果データと、故障診断装置を利用した故障診断方法による故障診断結果データとから、故障診断装置を利用したことによる故障診断のコスト削減効果、すなわち、診断効率がどのように向上したかを演算し、それに所定の係数をかけてメーカ毎、ガス機種毎の故障診断ファイルの課金データを算出する旨記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−１５０４２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載される、保全事業者が得た利益に課金する保全向けの故障診断の場合、保全作業の実施指示あるいは作業員による調査に、自動診断の結果が利用されたかを検出することが必要である。しかしながら、特許文献１の構成では、修理作業員が、現場あるいは営業所にてそれぞれの故障診断結果データを作成するものであり、故障診断結果データを作成するにあたり、自動診断結果を利用したことが記載される確証はなく、例えば修理作業員による調査結果や作業結果だけを記載した報告書（故障診断結果データ）を作成することも可能である。従って、特許文献１では、如何にして自動診断結果を利用したことの確証を得るかについては、何ら考慮されていない。  
そこで、本発明は、保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供する。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、本発明に係る保全管理システムは、診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、センサにより計測される前記診断対象アセットの状態を表す計測値及び前記診断基準に基づき当該診断対象アセットの故障モードの発生を検出又は予測する自動診断部と、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも前記自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする。  
また、本発明に係る保全管理確認装置は、診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法と、を比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供することが可能となる。  
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施例に係る保全管理システムの全体概略構成図である。
【図２】図１に示す計測値データベースのデータ構造を示す図である。
【図３】図１に示す保全管理確認装置を構成する故障情報データベースのデータ構造を示す図である。
【図４】図１に示す保全管理確認装置を構成する自動診断定義データベースのデータ構造を示す図である。
【図５】図１に示す保全管理確認装置を構成する自動診断結果ログ記憶部のデータ構造を示す図である。
【図６】図１に示す保全管理確認装置を構成する作業指示ログ記憶部のデータ構造を示す図である。
【図７】図１に示す保全計画データベースのデータ構造を示す図である。
【図８】図１に示す保全管理確認装置を構成する保全作業ログ記憶部のデータ構造を示す図である。
【図９】図１に示す保全管理確認装置を構成する保全方法データベースのデータ構造を示す図である。
【図１０】図１に示す保全管理確認装置を構成するタスク実績分析部の処理フロー図である。
【図１１】図３に示す故障情報データベースに格納される対象コンポーネントの階層構成を示す図である。
【図１２】図１に示す保全管理確認装置を構成するタスク実績分析部による一致度算出結果を示す図である。
【図１３】図１に示す課金処理装置を構成する診断課金データベースのデータ構造を示す図である。
【図１４】図１に示す課金処理装置を構成する課金額推定部の処理フロー図である。
【図１５】図１に示す課金処理装置を構成する課金額推定部による課金額推定結果を示す図である。
【図１６】図１に示すＨＭＩを構成する表示装置の画面表示例である。
【発明を実施するための形態】
【０００９】
以下、図面を用いて本発明の実施例について説明する。
【実施例１】
【００１０】
図１は、本発明の一実施例に係る保全管理システムの全体概略構成図である。図１に示すように、保全管理システム１は、保全管理確認装置２、計測値データベース３、自動診断部４、保全計画データベース５、タスク計画部６、タスク実施記録部７、課金処理装置８、及びＨＭＩ（Ｈｕｍａｎ  Ｍａｃｈｉｎｅ  Ｉｎｔｅｒｆａｃｅ）９を備え、これらは相互にバスにてアクセス可能に接続されている。なお、ＨＭＩ９は、図示しない、例えば、液晶ディスプレイ（ＬＣＤ）又は有機ＥＬディスプレイなどの表示装置と、例えば、キーボード及び／又はマウスなどの入力装置を備える。対象アセット１０に設置されるセンサ１１により計測される各種計測値は保全管理システム１へ入力される。また、自動診断部４は、例えば、図示しないＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などのプロセッサ、各種プログラムを格納するＲＯＭ、演算過程のデータを一時的に格納するＲＡＭ、外部記憶装置などの記憶装置にて実現されると共に、ＣＰＵなどのプロセッサがＲＯＭに格納された各種プログラムを読み出し実行し、実行結果である演算結果をＲＡＭ又は外部記憶装置に格納する。【００１１】
本実施例の保全管理システム１が適用される、アセット１０及びセンサ１１は、特定のアセット、センサ技術、分析技術に限定されるものではないが、以下では、鉄道車両の軸受け監視とドア監視を一例として説明する。
（計測値データベース）  
計測値データベース３は、センサ１１により計測される対象アセット１０の状態を表す計測値を格納する。センサ１１から計測値データベース３へは、無線または有線の通信、あるいはメモリーカードやハードディスクなどにより、計測値が送信又は転送される。    図２に、図１に示す計測値データベース３のデータ構造を示す。図２に示すように、計測値データベース３は、「対象アセット」毎に、「時刻」及び「監視データ」を対応付けて格納している。「対象アセット」欄は、更に、対象アセット１０である鉄道車両の「車両番号」欄、及び、軸受ベアリング、ドアなどの「対象コンポーネント」欄に細分化され、また、「監視データ」欄は、振動強度（規格化）、ドア開時間、ドア閉時間などの監視データの「種類」欄、及び当該種類毎の「計測値」欄に細分化され、それぞれ格納されている。ここで、「監視データ」の「種類」欄に格納される“振動強度（規格化）”とは、対象アセット１０である鉄道車両の、車輪の軸受けの振動の強度を、平均的な振動強度で規格化した値（平均的な振動強度を「１．０」としたときの値）である。また、“ドア開時間”は、ドアの開動作の所要時間を、ドア開検知センサとドア閉検知センサの動作時刻の差分により算出して、「計測値」欄に保存している。“ドア閉時間”も同様にドア閉検知センサ、ドア開検知センサの動作時刻差分から算出して、「計測値」欄に保存している。また、ドアを開閉させる空気圧の圧力も記録しているものとする。【００１２】
図２に示す例では、「対象アセット」の「車両番号」が“車両番号１”であり、「対象アセット」の「対象コンポーネント」が“軸受けベアリング１”については、「時刻」が“２０１６／１０／０３  ０８：００”の時、「監視データ」の「種類」である“振動強度（規格化）”が“１.０５”として計測され、その１時間後の“２０１６／１０／０３  ０９：００”の時、“振動強度（規格化）”が、“１.１８”として計測されたことを示している。  
また、「対象アセット」の「車両番号」が“車両番号２”であり、「対象アセット」の「対象コンポーネント」が“ドア１”については、「時刻」が“２０１６／１０／０３  １０：１５”の時、「監視データ」の「種類」である“ドア開時間”が“５.０秒”であり、その１８分後の“２０１６／１０／０３  １０：２３”では、“ドア開時間”が、“４.９秒”であったことを示している。
（故障情報データベース）  
図３は、図１に示す保全管理確認装置２を構成する故障情報データベース２１のデータ構造を示す図である。図３に示すように、故障情報データベース２１は、「対象コンポーネント」毎に、「故障ＩＤ」、「故障モード」、「症状」、及び「原因」を対応付けて格納している。「対象コンポーネント」欄は、更に、軸受けベアリング、ドアなどの「コンポーネント」欄、及び、コンポーネントの構成を表すために、「上位コンポーネント」欄に細分化され、それぞれ格納されている。ここで、「故障ＩＤ」は、「対象コンポーネント」、「故障モード」、「症状」、及び「原因」を一意に対応付けて、ユニークな番号（数値）が設定される。また、「コンポーネント」と「上位コンポーネント」からなるコンポーネントの構成の情報は、装置の物理的構成に基づいた構造展開によるものでも、機能上の構成に基づいた、機能展開によるものでも良い。なお、上位コンポーネントについても、上位コンポーネントの階層で見た場合の機能に合わせて、故障モードが定義されても良い。発生時損害については、故障モードにより、実際に起こった詳細な故障モードに依存している場合は、下位の詳細な階層でのみ定義されても良い。一方で、部品交換の単位が大きい、あるいは運行の都合や契約上、上位の機能で運行損害が定義される場合は、上位のコンポーネント発生時損害が定義されても良く、この場合、下位コンポーネントの損害記述が無い場合もある。【００１３】
図３に示す例では、「対象コンポーネントアセット」欄の「コンポーネント」が“軸受ベアリング１”であり、その「上位コンポーネント」欄が“台車１”であり、「故障ＩＤ」として“１”が割り付けられている場合、「故障モード」欄が“ベアリング内傷”、「症状」欄に“振動、発熱、固着”、「原因」欄に“異物、グリス切れ、衝撃”が格納されている。また、２行目では、「対象コンポーネントアセット」欄の「コンポーネント」が“軸受ベアリング１”であり、その「上位コンポーネント」欄が“台車１”であり、「故障ＩＤ」として“２”が割り付けられている場合、「故障モード」欄が“ベアリング内傷（大）”、「症状」欄に“発熱、固着”、「原因」欄に“ベアリング内傷の拡大”が格納されている。  
“軸受ベアリング１”の上位コンポーネントである“台車１”が「コンポーネント」欄に格納される行においては、「上位コンポーネント」欄が“客車１”であり、「故障ＩＤ」として“３１”が割り付けられている場合、「故障モード」欄が“軸受け異常”、「症状」欄に“車輪回転異常”、「原因」欄に“ベアリング異常、ベアリング固定異常”が格納されている。また、“台車１”の上位コンポーネントである“客車１”が「コンポーネント」欄に格納される行においては、「上位コンポーネント」欄が“編成”であり、「故障ＩＤ」として“４１”が割り付けられている場合、「故障モード」欄が“台車異常”、「症状」欄に“走行に支障”が格納されている。  
なお、本実施例では、「対象コンポーネント」欄に「上位コンポーネント」欄を含める場合を示したが、これに限られず、「対象コンポーネント」欄を「コンポーネント」欄のみとしても良い。
（自動診断定義データベース）  
自動診断定義データベース２２には、ルール（診断基準）に基づいて対象アセット（対象部品）の状態診断を行い、保全作業実施をきたす警報の定義が格納されている。図４に図１に示す保全管理確認装置２を構成する自動診断定義データベース２２のデータ構造を示す。図４に示すように、自動診断定義データベース２２は、「自動診断ＩＤ」、「対象アセット」、診断の種類を示す「診断種類」、警報を発報するセンサデータの条件を示した「診断基準」、診断基準が満たされた場合に、残存寿命予測や故障発生時の影響予測に基づいた適切な保全作業を記載した「保全要求」、及び「故障ＩＤ」を格納している。さらに、これらの自動診断定義データベース２２に格納される自動診断定義は、故障情報データベース２１と故障ＩＤでリンクして保存されること、すなわち、リレーショナルデータベースとすることで、診断に対応するアセット、部品や故障モードが定義されているものとする。【００１４】
図４に示す例では、「自動診断ＩＤ」が“１”では、「対象アセット」欄に“軸受けベアリング１”、「診断種類」欄に“ベアリング異常振動”、「診断基準」欄にルールとして“振動強度（規格化）Ｖが、Ｖ＞＝１．１０となったときに、警報発報”、「保全要求」欄に“１０日以内の部品交換”、「故障ＩＤ」欄に“１”が格納されている。ここで、「診断基準」欄に格納される“Ｖ＞＝１．１０となったとき”とは、Ｖが１．１０以上となったときを示している。  
また、「自動診断ＩＤ」が“２”では、「対象アセット」欄に“軸受けベアリング２”、「診断種類」欄に“ベアリング異常振動”、「診断基準」欄に“振動強度（規格化）Ｖが、Ｖ＞＝１．１０となったときに、警報発報”、「保全要求」欄に“１０日以内の部品交換”、「故障ＩＤ」欄に“１１”が格納されている。  
また、「自動診断ＩＤ」が“４”では、「対象アセット」欄に“ドア”、「診断種類」欄に “ドア開時間異常”、「診断基準」欄に“ドア開時間ＤＯＴが、ＤＯＴ＞＝５．５ｓｅｃとなったときに、警報発報”、「保全要求」欄に“１５日以内の部品交換”、「故障ＩＤ」欄に“１０１”が格納されている。  
「自動診断ＩＤ」が“５”では、「対象アセット」欄に“ドアレール”、「診断種類」欄に“ドアレール抵抗増大”、「診断基準」欄に“ドア開時間ＤＯＴがＤＯＴ＞＝５．２ｓｅｃ、かつ、ドア閉時間ＤＣＴがＤＣＴ＞＝５．２ｓｅｃ、かつ、ドア空気圧ＤＰＳがＤＰＳ＞＝３．０ｂａｒとなったときに、警報発報”、「保全要求」欄に“１５日以内の清掃と注油”、「故障ＩＤ」欄に“１１１”が格納されている。【００１５】
なお、一旦、ある対象アセットのある故障モードの警報が発報した場合は、連続して発報しないように、診断基準（ルール）が再度満たされない状態にならない限り、新たな警報を連続して発報することはしないものとする。但し、対象アセットの状態が、発報の閾値周辺で揺らいでいるような場合は、繰り返し発報してしまう場合もありうる。このような繰り返し発報に対しては、発報抑制する機構の有無はどちらでも問題ないが、抑制する機構が完全ではない、あるいは故障自体が間欠的に発現することもありうる、実際の故障現象を想定して、繰り返し発報を考慮することが望ましい。これは、対象アセットを構成する各コンポーネントの自動診断の結果、各センサからの計測値に基づきその都度、警報が発報される毎に課金することを防止、また、対象アセットを構成する複数のコンポーネントに関する自動診断結果をまとめた上で、課金の対象とすることが合理的であることによる。【００１６】
上述のように本実施例では、軸受けベアリング１に対して、「自動診断ＩＤ」が“１”の場合において、平均的な振動強度で規格化された振動強度（規格化）に対して、閾値による故障の予兆検知を行う構成としている。すなわち、振動強度（規格化）をＶとして、Ｖ＜１．１０では正常、Ｖ＞＝１．１０で故障の予兆発生として検知する。なお、故障の予兆が発生した時点でも、ベアリングは劣化が始まっているが機能は正常に維持されており、その後１０日間は、交換作業は不要であるとわかっていることから、「保全要求」欄に“１０日以内の部品交換”が格納されている。このような診断基準（ルール）の設定は、例えば、ベアリングの劣化の進展を、物理モデルあるいは加速試験や実部品の統計によりモデルを作成すること、あるいはエンジニアの設定数値を用いることで実現される。他の対象アセットとしての、ドアあるいはドアレールなどその他の部品についても同様に、それぞれ診断基準（ルール）が設定される。
（自動診断部）  
自動診断部４は、バスを介して計測値データベース３および、保全管理確認装置２を構成する自動診断定義データベース２２にアクセスし、計測値データベース３および自動診断定義データベース２２に格納される情報に基づいて自動診断を実行する。自動診断の結果、発報があった場合は、自動診断部４は、バスを介して自動診断結果ログ記憶部２５に、個々の発報を識別するための警報ＩＤ、実施された自動診断を自動診断定義データベース２２に格納される対応する自動診断ＩＤ、警報が出された対象アセットの識別情報、および発報時刻などを記録する。なお、自動診断部４は、自動診断を実行する場合、知識情報データベースを参照することはない。
（自動診断結果ログ記憶部）  
図５は、図１に示す保全管理確認装置２を構成する自動診断結果ログ記憶部２５のデータ構造を示す図である。図５に示すように、自動診断結果ログ記憶部２５は、「警報ＩＤ」、「自動診断ＩＤ」、「対象アセット」、および「発報時刻」を格納している。「対象アセット」欄は、更に、警報が出された対象アセットの識別情報として、「対象車両」欄及び「対象コンポーネント」欄に細分化されている。「警報ＩＤ」は、個々の発報を識別するため、自動診断部４によりバスを介して記録される。また、「発報時刻」は、自動診断部４によりバスを介して、警報発報時刻が記録される。自動診断部４は、自動診断定義データベース２２に格納される「自動診断ＩＤ」及び「対象アセット」の情報及び警報発報時刻に対応する「対象車両」及び「対象コンポーネント」を計測値データベース３より読み出す。自動診断部４により読み出された「対象車両」及び「対象コンポーネント」が、それぞれ自動診断結果ログ記憶部２５に記録される。【００１７】
図５に示す例では、「警報ＩＤ」が“１”では、「自動診断ＩＤ」欄に“１”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“軸受けベアリング１”、「発報時刻」欄に“２０１６／１０／０３  ０９：００”が記録されている。  
また、「警報ＩＤ」が“２”では、「自動診断ＩＤ」欄に“１”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“軸受けベアリング１”、「発報時刻」欄に“２０１６／１０／０３  １１：００”が記録されている。  
「警報ＩＤ」が“５”では、「自動診断ＩＤ」欄に“２”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“軸受けベアリング２”、「発報時刻」欄に“２０１６／１０／０８  １１：００”が記録されている。【００１８】
保全計画者は、対象アセットの運用者や保全作業員からの異常の報告があった場合、あるいは上述の自動診断結果ログ記憶部２５の内容を、ＨＭＩ９を構成する表示装置の画面表示により確認した場合に、タスク計画部６を用いて作業指示書を作成し、保全作業者に作業を依頼する。なお、ＨＭＩ９を構成する表示装置の画面表示に代えて、ＨＭＩ９を構成する印字装置（図示せず）にて自動診断結果ログ記憶部２５の内容を表形式にてプリントアウトしても良い。このとき保全計画者は、現在の対象アセット１０の故障状態、あるいは将来予測される故障状態と、保全計画データベース５に格納される保全可能日や、保全作業リソース状況を勘案して、妥当な保全作業計画を作成して、作業指示ログ記憶部２６に記録することで、作業に割り当てられた保全作業者に指示を出す。なお、タスク計画部６は、例えば、図示しないＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などのプロセッサ、各種プログラムを格納するＲＯＭ、演算過程のデータを一時的に格納するＲＡＭ、外部記憶装置などの記憶装置にて実現されると共に、ＣＰＵなどのプロセッサがＲＯＭに格納された各種プログラムを読み出し実行し、実行結果である演算結果をＲＡＭ又は外部記憶装置に格納する。以下に、作業指示ログ記憶部２６および、保全計画データベース５について説明する。
（作業指示ログ記憶部と保全計画データベース）  
図６に図１に示す保全管理確認装置２を構成する作業指示ログ記憶部のデータ構造を示す。また図７に図１に示す保全計画データベース５のデータ構造を示す。  
先ず、作業指示が自動診断の結果に基づくものか、そのほかの情報源に基づくものかは、保全作業の実施においては、参考情報として有益ではあるが、必ずしも必須の情報ではないため、保全計画者によって、記録される場合とされない場合があると想定される。自動診断部４により対象アセット１０に対し自動診断を実行する場合、自動診断の結果に基づき、警報ＩＤを自動的にあるいは手動で記録して、作成することも考えられる。【００１９】
また、上述の図５に示した自動診断結果ログ記憶部２５のデータ構造の一例に見られるように、「対象車両」が“車両番号１”、「対象コンポーネント」が“軸受けベアリング１”に関する警報については、対象アセットの状態が、図４に示した自動診断定義データベース２２に格納される診断基準（ルール）と適合・非適合を繰り返すなど、警報が複数回記録される場合もある。その場合はどの警報ＩＤを記録するか、あるいは記録せずに異常の内容を別途記載するかは、保全計画のルールや、保全計画者の裁量に依存することも考えられる。【００２０】
また、自動診断部４による対象アセット１０に対する自動診断結果を利用したことで、保全事業者が課金される場合は、課金を逃れるために、意図的に診断情報源を書き込まないことで、課金から逃れようとすることも想定される。  
また、警報が出ているにもかかわらず、保全計画者が警報を参照していなかったために、保全作業者の報告といった、別の情報源に基づいて作業指示を作成したことで、警報とリンクされずに作業指示が作成されることも考えられる。【００２１】
図６に示すように、作業指示ログ記憶部２６は、「タスクＩＤ」毎に、「問題」、「対象アセット」、「故障ＩＤ」、「診断情報源」、「依頼日」（指示日）、および「作業予定日」を格納している。「対象アセット」欄は、更に、警報が出された対象アセットの識別情報として、「対象車両」欄および「対象コンポーネント」欄に細分化されている。これら、「問題」、「対象車両」、「対象コンポーネント」、「故障ＩＤ」、「診断情報源」、「依頼日」（指示日）、及び「作業予定日」が、各タスクＩＤに対応する作業指示に関する情報となる。  
図６に示す例では、「タスクＩＤ」が“１”では、「問題」欄に“ドア開異常”、「対象車両」欄に“車両番号２”、「対象コンポーネント」欄に“ドア１”、「故障ＩＤ」欄に“１０”、「診断情報源」欄に“ＮＡ”、「作業依頼内容」欄に“ドア開異常原因調査と修理”、「依頼日」（指示日）欄に“２０１６／９／３０”、「作業予定日」欄に“２０１６／１０／１１”が記録されている。なお、「診断情報源」欄に記録されている“ＮＡ”とは、Ｎｏ  Ａｓｓｉｇｎのことであり、空白（ブランク）を意味する。【００２２】
「タスクＩＤ」が“２”では、「問題」欄に“トイレ詰まり”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“トイレ２”、「故障ＩＤ」欄に“２００”、「診断情報源」欄に“作業員”、「作業依頼内容」欄に“清掃と点検”、「依頼日」（指示日）欄に“２０１６／１０／１”、「作業予定日」欄に“２０１６／１０／１０”が記録されている。【００２３】
また、「タスクＩＤ」が“３”では、「問題」欄に“ベアリング異常”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“軸受けベアリング１”、「故障ＩＤ」欄に“１”、「診断情報源」欄に“ＮＡ”、「作業依頼内容」欄に“ベアリング交換”、「依頼日」（指示日）欄に“２０１６／１０／３”、「作業予定日」欄に“２０１６／１０／１０”が記録されている。  
「タスクＩＤ」が“４”では、「問題」欄に“ベアリング異常”、「対象車両」欄に“車両番号３”、「対象コンポーネント」欄に“軸受けベアリング１０”、「故障ＩＤ」欄に“１”、「診断情報源」欄に“警報ＩＤ４”、「作業依頼内容」欄に“ベアリング交換”、「依頼日」（指示日）欄に“２０１６／１０／８”、「作業予定日」欄に“２０１６／１０／３０”が記録されている。【００２４】
「タスクＩＤ」が“１”および“３”では、警報が発報状態にあるにもかかわらず、「診断情報源」欄は“ＮＡ”であり記載が無い。また、「タスクＩＤ」が“２”では、「診断情報源」欄は“作業員”であり、「タスクＩＤ」が“４”では、「診断情報源」欄は“警報ＩＤ４”であり、警報が記載されている。すなわち、実際の警報発報状況にもかかわらず、診断情報源は警報ＩＤの記載があるものと無いものとが混在している。【００２５】
また、保全計画データベース５は、図７に示されるように、「アセット」毎に、複数の「保全可能日」が格納されている。例えば、「アセット」が“車両番号１”については、「保全可能日」として、“２０１６／１０／１０”、“２０１６／１０／３０”などが格納されている。上述の図６に示した作業指示ログ記憶部２６に格納される、「タスクＩＤ」が“３”の場合では、「対象車両」が“車両番号１”であり、かつ、「依頼日」（指示日）が“２０１６／１０／３”であることから、保全計画データベース５に格納される“車両番号１”に対する「保全可能日」のうち、「依頼日」（指示日）“２０１６／１０／３”に直近の“２０１６／１０／１０”が、「作業予定日」欄に記録される。【００２６】
保全作業者は、作業指示ログ記憶部２６を参照することで、指示に従って保全作業を実施する。保全作業において保全作業者は、保全指示の内容が正しいものであるか対象アセット１０を調査することで確認する。あるいは、作業指示の段階では、詳細な故障モードが判明していない場合も調査によって、問題を引き起こしている故障モードを特定する。
故障モードが確認された後に、詳細後述する、保全管理確認装置２を構成する保全方法データベース２３に格納されている保全方法に基づき作業を実施する。作業後に、保全作業者は、調査結果や実施した作業の内容を、タスク実施記録部７を用いて、保全管理確認装置２を構成する保全作業ログ記憶部２４に記録する。なお、タスク実施記録部７は、例えば、図示しないＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などのプロセッサ、各種プログラムを格納するＲＯＭ、演算過程のデータを一時的に格納するＲＡＭ、外部記憶装置などの記憶装置にて実現されると共に、ＣＰＵなどのプロセッサがＲＯＭに格納された各種プログラムを読み出し実行し、実行結果である演算結果をＲＡＭ又は外部記憶装置に格納する。以下に、保全作業ログ記憶部２４および保全方法データベース２３について説明する。
（保全作業ログ記憶部と保全方法データベース）  
図８は図１に示す保全管理確認装置２を構成する保全作業ログ記憶部２４のデータ構造を示す図であり、図９は図１に示す保全管理確認装置２を構成する保全方法データベース２３のデータ構造を示す図である。  
図９に示すように、保全方法データベース２３は、「保全方法ＩＤ」毎に、「故障ＩＤ」、故障ＩＤにより紐付けられる故障情報データベース２１（図３）に格納される「故障モード」に対応して、各故障モードが疑われる場合の検査・診断方法として「検査方法」、および、発生している故障モードが特定された場合の保全タスクとして「処置方法」を格納している。【００２７】
図９に示す例では、「保全方法ＩＤ」が“１０００”では、「故障ＩＤ」欄に“１”、「検査方法」欄に“センサによる振動強度確認”、「処置方法」欄に“部品交換”が格納されている。  
また、「保全方法ＩＤ」が“１００１”では、「故障ＩＤ」欄に“２”、「検査方法」欄に“発熱のチェック、振動強度確認”、「処置方法」欄に“部品交換。必要に応じて周辺部品交換”が格納されている。【００２８】
「保全方法ＩＤ」が“１１１１”では、「故障ＩＤ」欄に“１１１”、「検査方法」欄に“レール内目視点検”、「処置方法」欄に“清掃・注油”が格納されている。  
また、「保全方法ＩＤ」が“２００１”では、「故障ＩＤ」欄に“２００”、「検査方法」欄に“上部からの目視または分解検査”、「処置方法」欄に“つまり除去”が格納されている。【００２９】
作業後に、保全作業者は、調査結果や実施した作業の内容を、タスク実施記録部７を用いて、保全管理確認装置２を構成する保全作業ログ記憶部２４に記録する。図８に示すように、保全作業ログ記憶部２４は、「タスクＩＤ」毎に、「検査」、「運用」、「保全方法ＩＤ」、「処置」、「実施日時」、および「作業時間（分）」を記録している。「検査」欄は更に「検査結果」欄と「故障ＩＤ」欄に細分化され、「運用」欄は更に「影響有無」欄と対象アセット１０の運用停止時刻である「運用停止時刻」欄に細分化され、「処置」欄は更に、「作業内容」欄、「対象車両」欄、および「対象コンポーネント」欄に細分化されている。【００３０】
図８に示す例では、「タスクＩＤ」が“１”では、「検査結果」欄に“ドアレール目視点検。レール内ゴミ発見。空気圧異常なし”、「故障ＩＤ」欄に“１１１”、「影響有無」欄と「運用停止時刻」欄に“なし”、「保全方法ＩＤ」欄に“１１１１”、「作業内容」欄に“清掃”、「対象車両」欄に“車両番号２”、「対象コンポーネント」欄に“ドア１”、「実施日時」欄に“２０１６／１０／１１  １３：００”、「作業時間（分）」欄に“３０”が記録されている。  
また、「タスクＩＤ」が“２”では、「検査結果」欄に“つまり場所特定”、「故障ＩＤ」欄に“２００”、「影響有無」欄に“トイレ使用不能”、「運用停止時刻」欄に“２０１６／１０／０１  ０７：００”、「保全方法ＩＤ」欄に“２００１”、「作業内容」欄に“清掃”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“トイレ２”、「実施日時」欄に“２０１６／１０／１０  １５：００”、「作業時間（分）」欄に“４０”が記録されている。【００３１】
「タスクＩＤ」が“３”では、「検査結果」欄に“ベアリング振動確認”、「故障ＩＤ」欄に“１”、「影響有無」欄と「運用停止時刻」欄に“なし”、「保全方法ＩＤ」欄に“１０００”、「作業内容」欄に“部品交換”、「対象車両」欄に“車両番号１”、「対象コンポーネント」欄に“軸受けベアリング１”、「実施日時」欄に“２０１６／１０／１０  １６：００”、「作業時間（分）」欄に“２００”が記録されている。  
また、「タスクＩＤ」が“６”では、「検査結果」欄に“ベアリングと周辺部品の破壊を確認”、「故障ＩＤ」欄に“２”、「影響有無」欄に“運用不能”、「運用停止時刻」欄に“２０１６／１０／０３  １２：０２”、「保全方法ＩＤ」欄に“１００１”、「作業内容」欄に“部品交換”、「対象車両」欄に“車両番号４”、「対象コンポーネント」欄に“台車１”、「実施日時」欄に“２０１６／１０／１０  ２１：００”、「作業時間（分）」欄に“５００”が記録されている。【００３２】
一連の保全プロセスによって、自動診断あるいはその他の情報源によって、対象アセット１０に問題が見つかった場合の、保全作業の実施が完了する。以下、このような保全プロセスにおいて、保全事業者が自動診断部４による自動診断結果を用いたことを、保全管理確認装置２にて検出する方法について説明する。
（タスク実績分析部）  
図１０に図１に示す保全管理確認装置２を構成するタスク実績分析部２７の処理フローを示す。タスク実績分析部２７は、新規に保全作業ログが上述の保全管理確認装置２を構成する保全作業ログ記憶部２４に記録された場合、あるいは一定の時間間隔、カレンダー指定日、あるいは保全事業者あるいはＩＴ事業者の指示に基づいて起動され、以下の処理を行う。以下では、新規に保全作業ログが上述の保全管理確認装置２を構成する保全作業ログ記憶部２４に記録されたタイミングで、タスク実績分析部２７が処理を開始する場合を一例として説明する。なお、タスク実績分析部２７は、例えば、図示しないＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などのプロセッサ、各種プログラムを格納するＲＯＭ、演算過程のデータを一時的に格納するＲＡＭ、外部記憶装置などの記憶装置にて実現されると共に、ＣＰＵなどのプロセッサがＲＯＭに格納された各種プログラムを読み出し実行し、実行結果である演算結果をＲＡＭ又は外部記憶装置に格納する。【００３３】
図１０に示すように、ステップＳ１０１では、タスク実績分析部２７が対象保全ログ取得処理を実行する。具体的には、タスク実績分析部２７は、バスを介して作業指示ログ記憶部２６へアクセスし、タスク実施記録部７を用いて保全管理確認装置２を構成する保全作業ログ記憶部２４に記録されたタスクＩＤと、同じタスクＩＤをもつ作業指示ログを読み込む。ここでは、説明を解り易くするため一例として「タスクＩＤ」が“３”の場合について説明する。作業指示ログ記憶部２６より読み出される「タスクＩＤ」が“３”の作業指示ログは、図６に示すように、作業指示情報として、「問題」が“ベアリング異常”、「対象車両」が“車両番号１”、「対象コンポーネント」が“軸受けベアリング１”、「故障ＩＤ」が“１”、「診断情報源」が“ＮＡ”、「作業依頼内容」が“ベアリング交換”、「依頼日」（指示日）が“２０１６／１０／３”、および「作業予定日」が“２０１６／１０／１０”であることが読み込まれる。【００３４】
次にステップＳ１０２では、タスク実績分析部２７が自動診断結果ログ取得処理を実行する。具体的には、タスク実績分析部２７は、バスを介して自動診断結果ログ記憶部２５へアクセスし、自動診断結果ログとして、対象アセット１０である車両番号１の軸受けベアリング１に関して、作業指示ログ記憶部２６から取得した依頼日（指示日：２０１６／１０／３）より以前の一定期間内Ｄに対象アセット１０である車両番号１の軸受けベアリング１について発報された警報を、自動診断結果ログ記憶部２５から読み込む。ここで一定期間Ｄは、保全計画者により時間幅として指定され、例えば３０日間が一定期間Ｄとして指定される。この結果、例えば、図５に示す例では、少なくとも、対象アセット１０である車両番号１の軸受けベアリング１に関して発報された警報として、「警報ＩＤ」が“１”で「自動診断ＩＤ」が“１”、および、「警報ＩＤ」が“２”で「自動診断ＩＤ」が“１”が読み出される。なお、図５では、説明を解り易くするため「警報ＩＤ」が“１”から“６”までの場合を示したが、実際はこれよりも多くの「警報ＩＤ」が格納されている。このように、複数の自動診断結果ログが読み込まれることもありうるため、以降はステップＳ１０３とステップＳ１０６に示すように、ここのログをループして処理する。換言すれば、自動診断部４による自動診断結果に応じてループ処理を行う。【００３５】
ステップＳ１０４では、タスク実績分析部２７が故障情報及び保全方法の読み込み処理を実行する。具体的には、タスク実績分析部２７は、バスを介して自動診断定義データベース２２（図４）へアクセスし、ステップＳ１０２で読み込まれた「警報ＩＤ」が“１”で「自動診断ＩＤ」が“１”のうち、自動診断ＩＤ“１”に対応する故障ＩＤ“１”を抽出する。その後、タスク実績分析部２７は、故障情報データベース２１（図３）にアクセスし、上記抽出された故障ＩＤ“１”に対応する故障情報を読み込む。ここで、読み込まれる故障情報は、図３に示した、「故障モード」として“ベアリング内傷”、「症状」として“振動、発熱、固着”、および「原因」として“異物、グリス切れ、衝撃”を含む。
また、タスク実績分析部２７は、保全方法データベース２３（図９）へアクセスし、上記抽出された故障ＩＤ“１”に対応する保全方法を読み込む。ここで読み込まれる保全方法は、図９に示した保全方法ＩＤ“１０００”に対応する、「検査方法」として “センサによる振動強度確認”および「処置方法」として“部品交換”を含む。【００３６】
ステップＳ１０５では、タスク実績分析部２７が自動診断・保全ログ一致度算出処理を実行する。具体的には、タスク実績分析部２７は、保全管理確認装置２を構成する保全作業ログ記憶部２４（図８）へアクセスし、ステップＳ１０４で抽出された故障ＩＤ“１”に対応する保全作業ログ記憶部２４に格納される保全作業ログと、既に取得された自動診結果ログを比較することで、自動診断部４による自動診断結果が、保全作業ログ記憶部２４に記録された、検査の結果確定された実際の故障状況とどの程度一致していたかを示す、一致度Ｍの算出を行う。一致度Ｍの算出方法としては、例えば次のような要素やその組み合わせにて実現できる。まず、自動診断結果ログ記憶部２５に格納される自動診断ＩＤがリンクしている故障ＩＤと、保全作業ログ記憶部２４に記録された故障ＩＤが一致している場合は、故障を詳細な精度で確定できているので、一致度ＭをＭ＝１とする。本実施例の場合においては上述の通り、自動診断結果ログ記憶部２５に格納される自動診断ＩＤがリンクしている故障ＩＤは“１”（上記抽出された故障ＩＤ“１”）であり、保全作業ログ記憶部２４に記録された故障ＩＤが“１”であることから、一致度ＭはＭ＝１となる。【００３７】
また、故障ＩＤが一致しない場合でも、近い故障を自動診断部４が出していた場合は、一致度を与えることができる。例えば、本実施例では、図３に示したように、故障情報データベース２１は、「対象コンポーネント」として「コンポーネント」と「上位コンポーネント」を格納している。すなわち、コンポーネントの階層関係が与えられているため、これを用いて一致度を算出できる。  
図１１は、図３に示す故障情報データベース２１に格納される対象コンポーネントの階層構成を示す図である。図１１に示すように、この対象コンポーネントの階層構成は、「編成」を最上位として、コンポーネントを構造で細分化したネットワークにて定義されており、また、各故障ＩＤは、ネットワーク内のいずれかのコンポーネントに関係して定義されている。このとき、一致度を定義する方法として、ネットワーク上の距離Ｌを、自動診断部４による自動診断結果、すなわち、自動診断ＩＤにリングした故障ＩＤと、保全作業ログ記憶部２４に記録された故障ＩＤ間を、最短距離で辿った場合の、間に存在するコンポーネント数で定義することが可能である。例えば、図１１に示す軸受けベアリング１に関し、自動診断ＩＤにリンクした故障ＩＤが“１”、保全作業ログ記憶部２４に記録された故障ＩＤが“２”の場合を想定すると、これら故障ＩＤ“１”および故障ＩＤ“２”の間に存在するコンポーネントは軸受けベアリング１のみであることから、ネットワーク上の距離ＬはＬ＝１となる。また、例えば、軸受けベアリング１に関し、自動診断ＩＤにリンクした故障ＩＤが“１”、保全作業ログ記憶部２４に記録された軸受けベアリング２に関する故障ＩＤが“１１”の場合を想定すると、これら故障ＩＤ“１”および故障ＩＤ“１１”の間に存在するコンポーネントは、軸受けベアリング１および軸受けベアリング２であることから、ネットワーク上の距離ＬはＬ＝２となる。そして、これらの場合において一致度として例えば、Ｍ＝１／（Ｌ＋１）として定義することができる。一般的には、一致度Ｍは距離Ｌの減少関数Ｆを用いて、Ｍ＝Ｆ（Ｌ）となっていれば良い。【００３８】
また、このようなネットワーク上の距離Ｌを用いる場合、いくらでも遠いコンポーネントへの警報に一致度Ｍが定義されないように、距離Ｌが所定値より大きい場合はＭ＝０としても良い。また、ネットワークを構成するコンポーネント間の接続に重み付けを行い、故障の状況や保全作業の関連性が高いものは距離Ｌが小さくなるようにする、あるいは、同一のコンポーネントに関連した別の故障ＩＤでは、一致度Ｍが大きくなるように補正しても良い。センサ１１の不備によって、詳細コンポーネントでの診断が困難な場合は、上位コンポーネントに定義された故障情報に関連した警報であっても、一致度Ｍを大きくするなどの、補正を行うことが可能である。【００３９】
次に、再びステップＳ１０４に戻り、タスク実績分析部２７は、バスを介して自動診断定義データベース２２（図４）へアクセスし、ステップＳ１０２で読み込まれた「警報ＩＤ」が“２”で「自動診断ＩＤ」が“１”のうち、自動診断ＩＤ“１”に対応する故障ＩＤ“１”を抽出する。その後、タスク実績分析部２７は、故障情報データベース２１（図３）にアクセスし、上記抽出された故障ＩＤ“１”に対応する故障情報を読み込む。ここで、読み込まれる故障情報は、図３に示した、「故障モード」として“ベアリング内傷”、「症状」として“振動、発熱、固着”、および「原因」として“異物、グリス切れ、衝撃”を含む。また、タスク実績分析部２７は、保全方法データベース２３（図９）へアクセスし、上記抽出された故障ＩＤ“１”に対応する保全方法を読み込む。ここで読み込まれる保全方法は、図９に示した保全方法ＩＤ“１０００”に対応する、「検査方法」として “センサによる振動強度確認”および「処置方法」として“部品交換”を含む。【００４０】
また、ステップＳ１０５では、タスク実績分析部２７が自動診断・保全ログ一致度算出処理を実行する。具体的には、タスク実績分析部２７は、保全管理確認装置２を構成する保全作業ログ記憶部２４（図８）へアクセスし、ステップＳ１０４で抽出された故障ＩＤ“１”に対応する保全作業ログ記憶部２４に格納される保全作業ログと、既に取得された自動診結果ログを比較することで、自動診断部４による自動診断結果が、保全作業ログ記憶部２４に記録された、検査の結果確定された実際の故障状況とどの程度一致していたかを示す、一致度Ｍの算出を行う。【００４１】
ここまでの処理により、「タスクＩＤ」が“３”の場合についての処理が終了し、タスク実績分析部２７は、保全作業ログ記憶部２４に記録される「タスクＩＤ」が“３”（図８）、作業指示ログ記憶部２６に記録されるタスクＩＤ“３”に対応する診断情報源“ＮＡ”（図６）、自動診断結果ログ記憶部２５に記録される警報ＩＤ“１”と警報発報時刻“２０１６／１０／０３  ０９：００”および警報ＩＤ“２”と警報発報時刻“２０１６／１０／０３  １１：００”、および、算出した一致度Ｍ（Ｍ＝１）を詳細後述する課金処理装置８へ出力する。【００４２】
本実施例では、説明を解り易くするため、「タスクＩＤ」が“３”の場合についてのみ説明したが、実際には、他のタスクＩＤについても同様の処理をタスク実績分析部２７が実行する。図１２に図１に示す保全管理確認装置２を構成するタスク実績分析部２７による一致度算出結果を示す。図１２に示すように、一致度算出結果は、例えば、「保全作業ログ  タスクＩＤ」、「診断情報源」、「自動診断結果ログ  警報ＩＤ」、「一致度Ｍ」、および「発報時刻」からなる一覧（表形式）にて出力される。  
図１２に示すように、「保全作業ログ  タスクＩＤ」が“１”については、「診断情報源」欄に“ＮＡ”、「自動診断結果ログ  警報ＩＤ」欄に“３”、「一致度Ｍ」欄に“０．３３”、および「発報時刻」欄に“２０１６／１０／０３  ０９：００”が書き込まれる。【００４３】
また、「保全作業ログ  タスクＩＤ」が“３”については、「診断情報源」欄に“ＮＡ”、「自動診断結果ログ  警報ＩＤ」欄に“１”と“２”、「一致度Ｍ」欄に“１”、および「発報時刻」欄に“２０１６／１０／０３  ０９：００”と“２０１６／１０／０３  １１：００”が書き込まれる。【００４４】
以上の通り、保全管理確認装置２は、自動診断部４による自動診断結果が保全作業に利用された可能性があるかを、自動診断結果ログ記憶部２５に記録される自動診断結果と保全作業ログ記憶部２４に記録される保全作業ログの間の一致度Ｍを算出することで、保全作業ログ記憶部２４に記録される保全作業ログあるいは作業指示ログ記憶部２６に記録される作業指示に自動診断結果利用の有無の記載があるか否かににかかわらず、自動診断結果の利用を適切に検出することが可能となる。【００４５】
なお、タスク実績分析部２７による一致度Ｍの算出法は、上述の方法に限られるものでは無い。例えば、自動診断結果にリンクした故障情報データベース２１（図３）には、コンポーネント、故障モード、症状、および原因が格納されている。これをテキストマッチングにより、保全作業ログ記憶部２４（図８）に記録される検査結果（検査内容）と比較することが可能である。一致する単語があった場合、一致数ｎに応じて一致度Ｍを、例えばＭ＝１−２-ｎとして算出しても良い。この場合、テキストマッチングにおいて、一致数ｎが小さいほど一致度Ｍの値は１より小さくなり、一致数ｎがゼロの場合には一致度Ｍ＝０となる。逆に、一致数ｎが大きいほど一致度Ｍは限りなく１に近づく。  
また、たとえ特定した故障ＩＤが異なっていても、実際の処置作業が同じで、作業時間や損害拡大防止の効果が同じであれば、一致度Ｍは高いと考えて、自動診断結果にリンクした故障情報データベース２１に対してリンクしている保全方法データベース２３と、実際に保全作業ログ記憶部２４に記録された保全方法（作業内容）とを比較する方法もある。この場合、双方の保全方法ＩＤが一致するならば一致度ＭをＭ＝１としても良く、特定した故障ＩＤが異なることに着目して、一致度Ｍを引き下げて、例えばＭ＝０．５などとしても良い。【００４６】
次に、自動診断部４による自動診断結果の利用により、保全事業者が得た利益を算出して課金額を定める方法について説明する。  
（課金処理装置による課金額の算出）  
図１に示す課金処理装置８を構成する課金額推定部８１は、保全作業実施により保全事業者が得た利益の推定と、自動診断部４による自動診断結果が保全作業に利用可能性があり、実際に利用されたと推定されるかの判定およびその際の一致度Ｍを用いることで、保全事業者が得た利益の一部を自動診断結果の利用料金とする、課金額の推定を行う。【００４７】
はじめに保全事業者が得る利益の推定方法について説明する。本実施例では、保全作業の実施や自動診断部４による自動診断結果の利用によって得られる利益を、早期処置による対象アセット１０の破壊・劣化進展の防止、運用への影響防止による機会利益の確保、自動診断結果を用いることで保全作業者による検査が削減されることによる作業コストの削減として、計算する。なお、機会利益確保については、運用事業者と保全事業者が別の業者の場合も、運用事業者が機会利益を損失したときに保全事業者に課すペナルティに置き換えることができる。  
また、保全作業実施による安全性確保も、対象故障発生時の事故に関する保険金額を通じた計算などによって、金額に換算することが可能である。あるいは、運用事業者から保全事業者に契約に基づいて課すペナルティ金額を用いることも可能である。【００４８】
図１３に図１に示す課金処理装置８を構成する診断課金データベース８３のデータ構造を示す。図１３に示すように、診断課金データベース８３は、故障情報データベース２１（図３）に格納される「故障ＩＤ」に関連付けて、「運用障害予防効果［万円］」および「作業コスト削減効果［万円］」を格納している。ここで、運用障害予防効果は、故障に伴う運用障害を予防できた場合に得られる利益を、予防できなかった場合に対象アセット１０の破壊・運用停止・保険値上がりなどで受ける損害から推定している。この推定は、過去の統計や、契約記載の値から算出したものとする。また、作業コスト削減効果は、自動診断部４による自動診断結果を用いた場合の作業時間削減効果に対応するコスト削減効果である。本実施例では、診断課金データベース８３における「運用障害予防効果［万円］」および「作業コスト削減効果［万円］」を定数として格納しているが、これは過去の故障発生時の損害や、保全作業員による診断の作業時間のコスト換算の統計に基づいてそれぞれ設定しても良い。【００４９】
図１４は、図１に示す課金処理装置８を構成する課金額推定部８１の処理フロー図である。課金額推定部８１は、新規に保全作業ログが上述の保全管理確認装置２を構成する保全作業ログ記憶部２４に記録され、タスク実績分析部２７により一致度Ｍが算出された場合、あるいは一定の時間間隔、保全事業者あるいはＩＴ事業者の指示などに基づき起動される。本実施例では、保全作業ログを一件ごとに処理する場合を一例として説明するが、複数の保全作業ログを纏めて処理する構成としても良い。【００５０】
図１４に示すように、ステップＳ２０１では、課金額推定部８１が一致度算出結果読み込み処理を実行する。具体的には、課金額推定部８１は、バスを介して保全管理確認装置２を構成するタスク実績分析部２７により算出された一致度算出結果（図１２）を読み込む。  
ステップＳ２０２では、課金額推定部８１が関連データの読み込み処理を実行する。具体的には、課金額推定部８１は、バスを介して、故障情報データベース２１、保全方法データベース２３、保全作業ログ記憶部２４、自動診断結果ログ記憶部２５、作業指示ログ記憶部２６、および保全計画データベース５にアクセスする。そして、課金額推定部８１は、ステップＳ２０１にて読み込んだ一致度算出結果（図１２）中に含まれるタスクＩＤ及び警報ＩＤを検索キーとして、故障情報データベース２１、保全方法データベース２３、保全作業ログ記憶部２４、自動診断結果ログ記憶部２５、作業指示ログ記憶部２６、および保全計画データベース５より以降の作業で用いる関連データを読み込む。【００５１】
ステップＳ２０３では、課金額推定部８１が最適警報の抽出処理を実行する。具体的には、課金額推定部８１は、警報が保全計画者による作業指示の判断に使われた可能性があるか判定し、かつ、もっとも有益であったと推測される警報を抽出するために、作業指示より以前に発報された警報で、最も一致度Ｍが高い警報を抽出する。一致度Ｍが同じ警報があった場合は、最も発報時刻の古い警報を最適警報として抽出する。これは、早期に発報された警報が、故障発生リスクを低減し、保全準備を容易にし、運用への影響も低減できるためである。また、保全事業者とＩＴ事業者間の取り決めの都合や、あるいは警報が使用できた可能性ではなく、実際に使用した警報を重視して課金する場合には、最適警報の抽出処理では、診断情報源に書き込まれた警報ＩＤを用いても良い。【００５２】
ステップＳ２０４では、課金額推定部８１が運用障害防止効果算出処理を実行する。具体的には、課金額推定部８１は、運用障害の防止効果について、診断課金データベース８３に格納される「運用障害予防効果」欄のデータなどを用いて算出する。この処理では、警報発報によって、運用停止を予防できる可能性があったかを判定し、可能であった場合は効果を算入し、不可能の場合は算入しない。すなわち、警報が発報されたとしても、警報発報から次の保全可能タイミングまでが短く、保全作業実施の準備ができなかった場合は、保全可能タイミングを逸してしまい、結果として、さらに次の保全可能タイミングの前に、運行停止せざるを得なくなる可能性があるためである。この判断を行うために、警報発報時刻に、自動診断定義データベース２２の「保全要求」欄に格納されている保全作業実施までのリードタイムを加えたものと、保全計画データベース５に格納されている保全可能日を比較する。警報発報時刻からリードタイムのうちに、保全可能日が存在する場合は、運行損害を防止可能であったと推定し、当該警報ＩＤに対応する故障ＩＤを抽出する。診断課金データベース８３において抽出された故障ＩＤに対応する「運用障害予防効果」欄に格納されている額を運用障害予防額ＰＯとする。しかし、保全可能日が存在しない場合は、次の保全可能日まで運用を停止することになるため、効果を算入せず、運用障害予防額ＰＯ＝０とする。  
なお、作業コスト削減効果額ＰＭについては、作業指示前に警報が発報されていれば、その結果を用いて保全作業可能と推定できることから、ステップＳ２０３にて抽出された最適警報であれば、当該最適警報の警報ＩＤに対応する故障ＩＤを抽出する。そして、診断課金データベース８３おいて抽出された故障ＩＤに対応する「作業コスト削減効果」欄に格納されている額を作業コスト削減効果額ＰＭとする。【００５３】
ステップＳ２０５では、課金額推定部８１が自動診断効果算出処理を実行する。具体的には、課金額推定部８１は、バスを介して保全作業ログ記憶部２４へアクセスし、検査で明らかになった実際の故障ＩＤを自動診断部４による自動診断結果で特定できた場合に、自動診断結果の利用によって実際に得られた、あるいは得ることが可能であったと見込まれる利益の金額ＰＥを、ＰＥ＝ＰＯ＋ＰＭとして算出する。さらに、実際に自動診断結果が特定した故障ＩＤと、保全作業ログ記憶部２４に記録されている故障ＩＤの一致度Ｍに基づき、自動診断結果によって、保全作業者が得たあるいは得ることが可能であった利益Ｐを、Ｐ＝ＰＥ×Ｍとして算出する。【００５４】
ステップＳ２０５にて算出した、保全事業者が得た利益Ｐの一部を保全ＩＴ事業者の課金額とするために、ステップＳ２０６では、課金額推定部８１が課金額算出処理を実行する。具体的には、課金額推定部８１は、課金率をＲとして、課金額Ｃを、Ｃ＝Ｐ×Ｒとして推定する。なお、課金率Ｒは、保全事業者と保全ＩＴ事業者間の取り決めで事前に定めるものであり、例えばＲ＝１０％に定められる。また、故障情報ごとに異なる課金率Ｒを設定しても良い。  
以上の処理により、課金額推定部８１は、保全事業者が自動診断結果を利用することで、実際に得たあるいは得ることが可能であった利益に対する課金額Ｃを推定することができる。【００５５】
図１５は、図１に示す課金処理装置８を構成する課金額推定部８１による課金額推定結果を示す図である。図１５に示すように、課金額推定結果は、「タスクＩＤ」、「警報ＩＤ」、「一致度Ｍ」、「運用損害予防額ＰＯ」、「運用損害予防可否」、「作業コスト削減額ＰＭ」、「見込み利益ＰＥ」、「利益Ｐ」、および「課金額Ｃ［万円］」からなる一覧（表形式）にて出力される。  
図１５に示す例では、保全作業ログ記憶部２４に記録された、タスクＩＤ“１”、タスクＩＤ“３”、およびタスクＩＤ“４”では、運用障害防止効果が得られていることから「運用損害予防額ＰＯ」、「作業コスト削減額ＰＭ」が得られている。しかし、タスクＩＤ“２”では、警報が発報されていない（警報ＩＤが“なし”）ために、「利益Ｐ」、「課金額Ｃ［万円］」は共に“０”となる。タスクＩＤ“５”およびタスクＩＤ“６”では、警報は発報されているものの、直近の保全可能日直前であったために対応できず、次の保全可能日に保全作業が実施されている。そのため、運用停止が発生してしたため、「運用損害予防可否」は“不可能”となっている。【００５６】
課金額推定部８１は、バスを介して課金額決定部８２へ課金額推定結果を出力（転送）する。課金額決定部８２は、課金額推定部８１より推定された課金額を、ＨＭＩ９を構成する表示装置（図示せず）の画面上に表示し、保全事業者による確認を取ることで、課金額を決定する。このとき、保全事業者による課金の妥当性を詳細に判断可能とするため、警報、保全作業指示、および保全作業の内容を、補助情報として画面上に同時に表示する構成としても良い。  
また、この課金の妥当性について、保全事業者と保全ＩＴ事業者の間で合意を取ることが考えられるため、保全作業ログ記憶部２４に記録されたそれぞれの保全作業ログについて容易に確認を取れるように、個別の確認完了ボタンや、チェックボックスなどを併せて画面上に表示する構成としても良い。また、画面上に課金額Ｃを修正して入力し得る入力領域を設ける構成としても良い。これにより、計算上は保全事業者が効果を得ており、課金額Ｃが０以外となっているが、実際上は全く効果が無かった警報に対して、保全事業者がクレームをつけることが可能となる。【００５７】
例えば、保全作業ログ記憶部２４（図８）におけるタスクＩＤ“６”については、自動診断結果ログ記憶部２５における警報ＩＤ“６”に示されるように警報が発報時刻“２０１６／１０／０３  １２：０１”に発報されているものの、運用不能となる直前であったために、車両停止などの措置が間に合わなかったために、台車１が破損して、保全事業者は大きな損害を被っている。これは、例えば、自動診断定義データベース２２に格納される自動診断ＩＤ“６”のベアリング発熱検知がより早く異常の兆候を見つけて、車両を安全に停止すれば防げたと考えられる。あるいは、ベアリングの劣化は、一般に小さな傷などによる振動の発生から、大きな傷による発熱に進展し、発熱後は短期間で固着など大きな故障に繋がる。そのため、自動診断ＩＤ“１”のベアリング異常振動の検知が、先に発報するべきであったにもかかわらず、今回は発報していない。このように、警報が適切に発報されていない、予定の性能を満たしていないと考えられる場合は、保全事業者は課金を承認しないことで、不当な課金をさけ、また、保全ＩＴ事業者に自動診断部４の問題点を知らせることができる。あるいは、課金額Ｃを減額することも考えられる。  
一方、逆に、課金額がゼロ推定されても、例えばセンサ１１の不良によるものであった場合は、保全ＩＴ事業者の責任ではないため、本来は検知可能であったとして、一定の金額を課金することも考えられる。【００５８】
図１６に、図１に示すＨＭＩ９を構成する表示装置の画面表示例を示す。図１６に示すように、ＨＭＩ９を構成する表示装置の表示画面９１は、第１表示領域９２および確認ボタン９３より構成される。第１表示領域９２には、保全作業ログ記憶部２４より抽出された「タスクＩＤ」、「検査結果」、および「故障ＩＤ」が表示される領域と、自動診断結果ログ記憶部２５より抽出された「警報ＩＤ」、自動診断定義データベース２２より抽出された「診断種類」、およびタスク実績分析部２７により算出された「一致度」が表示される領域と、課金額推定部８１からの出力をまとめた「保全事業者利益推定［万円］」および「課金額［万円］」が表示される領域と、保全事業者と保全ＩＴ事業者の協議に基づき最終的に決定された課金額の入力を可能とする「課金額決定値［万円］」の領域と、例えばマウスによるクリックにて保全事業者と保全ＩＴ事業者の「合意」を確定するチェックボックスが表示される。なお、第１表示領域９２に表示される内容は、上述の表示内容に限らず、適宜表示内容を変更しても良い。また、上述の各領域、例えば、「タスクＩＤ」領域あるいは「故障ＩＤ」領域をマウスによるクリックにてアクティブにすることで、関連する個別のデータ、作業指示ログ、保全作業ログ、あるいは自動診断結果ログなどをポップアップウィンドウまたはリンク画面に表示するよう構成しても良い。【００５９】
「合意」を示すチェックボックスの全項目にチェックマークが入力された場合、あるいは一部の項目にチェックマークが入力された場合、確認ボタン９３上にマウスカーソルを移動しマウスによるクリックにて確認ボタン９３がアクティブにされると、対応する項目の課金額が確定する。これにより、保全事業者に対し課金額が通知される。  
一方、保全ＩＴ事業者に対しては、課金額の通知に加えて、自動診断結果ごとの課金額、警報の発報状況、あるいは保全事業者との交渉結果、保全作業ログごとの課金状況を通知する。【００６０】
これにより保全ＩＴ事業者は、適切に警報を発報できずに、課金できていない保全作業ログ、課金額が低い警報などの情報、あるいはそれらにリンクした故障情報を知ることで、自動診断定義データベース２２内における診断基準の追加、あるいは診断基準の改善による予防的な警報発報の実現、さらには診断基準の改善による一致度Ｍを向上することへのインセンティブが働く。また、課金額が高く、すなわち保全事業者にとって、保全業務の改善効果が大きい自動診断部４による自動診断結果については、自動診断部４にて、診断に利用するリソースを増強するといった計画を立案することが可能となる。  
特に、本実施例のように、一致度Ｍを乗じて保全事業者の利益Ｐを算出することで、一致度Ｍが大きく、すなわち故障モードの特定精度が高い自動診断を行うことで、保全事業者利益と、課金額を高くすることが可能である。例えば、図１６に示すタスクＩＤ“１”のドア開異常のケースでは、自動診断ＩＤ“４”のドア開時間異常の警報（警報ＩＤ“３”）が発報された結果、一致度はＭ＝０．３３となっている。しかし、自動診断定義データベース２２に格納されている自動診断ＩＤ“５”のドアレール抵抗増大の警報が発報されていれば、一致度はＭ＝１となり、保全事業者は検査をより削減でき、保全ＩＴ事業者もより大きな課金額を得られた。これは、ドアレール抵抗増大の診断基準に満たなかったためだが、診断基準の改善や、新たなセンサの設置によってより高精度の診断を行えば、ドアレール抵抗増大を発報できた可能性がある。【００６１】
なお、本実施例では、課金処理装置８を保全管理システム１内に有する構成としたが、必ずしもこれに限られるものでは無い。例えば、課金処理装置８がネットワーク（有線、無線を問わない）を介して保全管理システム１に接続される構成としても良い。【００６２】
以上の通り本実施例によれば、保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供することが可能となる。    また、本実施例によれば、保全事業者が自動診断結果に基づく保全作業によって得た利益に対し、保全ＩＴ事業者が適切な課金を行うことが可能となる。【００６３】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。
例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【符号の説明】
【００６４】
１・・・保全管理システム，２・・・保全管理確認装置，３・・・計測値データベース，４・・・自動診断部，５・・・保全計画データベース，６・・・タスク計画部，７・・・タスク実施記録部，８・・・課金処理装置，９・・・ＨＭＩ，１０・・・対象アセット，１１・・・センサ，２１・・・故障情報データベース，２２・・・自動診断定義データベース，２３・・・保全方法データベース，２４・・・保全作業ログ記憶部，２５・・・自動診断結果ログ記憶部，２６・・・作業指示ログ記憶部，２７・・・タスク実績分析部，８１・・・課金額推定部，８２・・・課金額決定部，８３・・・診断課金データベース，９１・・・表示画面，９２・・・第１表示領域，９３・・・確認ボタン
【図１】
0006706693.tif 000002
【図２】
0006706693.tif 000003
【図３】
0006706693.tif 000004
【図４】
0006706693.tif 000005
【図５】
0006706693.tif 000006
【図６】
0006706693.tif 000007
【図７】
0006706693.tif 000008
【図８】
0006706693.tif 000009
【図９】
0006706693.tif 000010
【図１０】
0006706693.tif 000011
【図１１】
0006706693.tif 000012
【図１２】
0006706693.tif 000013
【図１３】
0006706693.tif 000014
【図１４】
0006706693.tif 000015
【図１５】
0006706693.tif 000016
【図１６】
0006706693.tif 000017