JPWO2018135171A1 - 保全管理システム及びそれに用いる保全管理確認装置 - Google Patents

保全管理システム及びそれに用いる保全管理確認装置 Download PDF

Info

Publication number
JPWO2018135171A1
JPWO2018135171A1 JP2018563204A JP2018563204A JPWO2018135171A1 JP WO2018135171 A1 JPWO2018135171 A1 JP WO2018135171A1 JP 2018563204 A JP2018563204 A JP 2018563204A JP 2018563204 A JP2018563204 A JP 2018563204A JP WO2018135171 A1 JPWO2018135171 A1 JP WO2018135171A1
Authority
JP
Japan
Prior art keywords
maintenance
diagnosis
unit
automatic diagnosis
failure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018563204A
Other languages
English (en)
Other versions
JP6706693B2 (ja
Inventor
敏明 河野
貴之 内田
英明 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2018135171A1 publication Critical patent/JPWO2018135171A1/ja
Application granted granted Critical
Publication of JP6706693B2 publication Critical patent/JP6706693B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0787Storage of error reports, e.g. persistent data storage, storage using memory protection
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0778Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/903Querying
    • G06F16/9035Filtering based on additional data, e.g. user or group profiles
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q50/40
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C1/00Registering, indicating or recording the time of events or elapsed time, e.g. time-recorders for work people
    • G07C1/10Registering, indicating or recording the time of events or elapsed time, e.g. time-recorders for work people together with the recording, indicating or registering of other data, e.g. of signs of identity
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841Registering performance data

Abstract

保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供する。保全管理システム1は、診断対象アセット毎に少なくとも故障モードを格納する故障情報DB21、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義DB22、センサにより計測される診断対象アセット10の状態を表す計測値及び診断基準に基づき診断対象アセット10の故障モードの発生を検出又は予測する自動診断部4、予め故障モードに対応する保守方法を格納する保全方法DB23、自動診断部4による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部25、及び診断対象アセット10に施された保全作業内容を記録する保全作業ログ記憶部24を備え、保全作業ログ記憶部24に記録された保全作業内容と、保全方法DB23に格納される自動診断部4による診断結果の故障モードに対応する保守方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部27を有する。

Description

本発明は、機器の診断システムと連携して動作する、保全の管理システムに係り、特に、保全管理の対象となる機器に対する自動診断を実行する自動診断部を有する保全管理システム及びそれに用いる保全管理確認装置に関する。
インフラ、鉄道、産業機器、医療機器などの多くの分野では、アセット(各種機器)の導入後は保全を継続的に実施することで、所定の性能を維持する必要がある。保全においては対象アセットの状態を収集し、異常の有無や問題点を分析する診断を適用した上で、適切な保全作業を適用する。
近年の情報技術の発達により、アセットの状態をセンサで収集することで、自動的にアセットの診断あるいは予兆診断を行うシステムの利用が可能となっており、保全管理者は、自動診断部が発報するアラームを参照して保全作業指示をだすことが可能となっている。従って、自動診断部の性能は、保全作業の効率に重大な影響を及ぼす。適切なアラームに基づいて保全作業を行った場合は、作業員による診断の作業を短縮したり、故障の影響がアセットの運用に影響を及ぼしたり、アセットの劣化・破壊が進展することで損害が発生するといった問題を避けることが可能となる。
このような情報技術に基づく診断技術を用いた保全を構築する場合、情報システムを提供する保全IT事業者と、実際に保全作業を行う保全事業者が別組織の場合が多く見られる。この場合、保全IT事業者は開発した情報システム(診断システム)を保全事業者に提供して代価を受け取り、保全事業者は提供された情報システム(診断システム)が出力する診断結果に基づいて保全作業を実施する。
診断システムの提供においては、主に導入時に保全IT事業者は保全事業者から代金の支払いを受け、その後はシステムの保全費用や運用に当たってのサポート費用を受け取ることが一般的であるが、他の形態も考えられる。例えば、運用中に保全事業者が診断技術の利用によって得た利益から、システムの利用料を保全IT事業者に支払うことも考えられる。このような形態をとる場合、保全IT事業者は、より性能の高い自動診断部を有する診断システムやアルゴリズムを提供するインセンティブが働くため、システム性能の改善が可能となり、それを通じて保全事業者は利益を得て、ひいてはアセットの運用状態の改善が可能となる。
自動診断部を有する診断システムの利用によって得た利益の一部を、使用量として支払う技術として、例えば、特許文献1に記載される技術が知られている。特許文献1では、故障診断システムの故障診断プログラムの対価を正当に評価することを可能とするため、携帯情報端末等の故障診断装置に予め故障診断プログラムをインストールし、被故障診断機器であるガス機器(例えば、ガス給湯器)に対して、通信線を接続するなどして通信可能にし、故障診断プログラムに従って表示される故障診断メニューを適宜選択し、プログラムからの質問に応答、或いはプログラムからの指示に対応する操作を被故障診断機器に与えることで、故障原因、故障部品を特定する旨開示されている。
そして、一定期間毎に、従来の故障診断方法による故障診断結果データと、故障診断装置を利用した故障診断方法による故障診断結果データとから、故障診断装置を利用したことによる故障診断のコスト削減効果、すなわち、診断効率がどのように向上したかを演算し、それに所定の係数をかけてメーカ毎、ガス機種毎の故障診断ファイルの課金データを算出する旨記載されている。
特開2002−150423号公報
特許文献1に記載される、保全事業者が得た利益に課金する保全向けの故障診断の場合、保全作業の実施指示あるいは作業員による調査に、自動診断の結果が利用されたかを検出することが必要である。しかしながら、特許文献1の構成では、修理作業員が、現場あるいは営業所にてそれぞれの故障診断結果データを作成するものであり、故障診断結果データを作成するにあたり、自動診断結果を利用したことが記載される確証はなく、例えば修理作業員による調査結果や作業結果だけを記載した報告書(故障診断結果データ)を作成することも可能である。従って、特許文献1では、如何にして自動診断結果を利用したことの確証を得るかについては、何ら考慮されていない。
そこで、本発明は、保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供する。
上記課題を解決するため、本発明に係る保全管理システムは、診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、センサにより計測される前記診断対象アセットの状態を表す計測値及び前記診断基準に基づき当該診断対象アセットの故障モードの発生を検出又は予測する自動診断部と、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも前記自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする。
また、本発明に係る保全管理確認装置は、診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法と、を比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする。
本発明によれば、保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供することが可能となる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
本発明の一実施例に係る保全管理システムの全体概略構成図である。 図1に示す計測値データベースのデータ構造を示す図である。 図1に示す保全管理確認装置を構成する故障情報データベースのデータ構造を示す図である。 図1に示す保全管理確認装置を構成する自動診断定義データベースのデータ構造を示す図である。 図1に示す保全管理確認装置を構成する自動診断結果ログ記憶部のデータ構造を示す図である。 図1に示す保全管理確認装置を構成する作業指示ログ記憶部のデータ構造を示す図である。 図1に示す保全計画データベースのデータ構造を示す図である。 図1に示す保全管理確認装置を構成する保全作業ログ記憶部のデータ構造を示す図である。 図1に示す保全管理確認装置を構成する保全方法データベースのデータ構造を示す図である。 図1に示す保全管理確認装置を構成するタスク実績分析部の処理フロー図である。 図3に示す故障情報データベースに格納される対象コンポーネントの階層構成を示す図である。 図1に示す保全管理確認装置を構成するタスク実績分析部による一致度算出結果を示す図である。 図1に示す課金処理装置を構成する診断課金データベースのデータ構造を示す図である。 図1に示す課金処理装置を構成する課金額推定部の処理フロー図である。 図1に示す課金処理装置を構成する課金額推定部による課金額推定結果を示す図である。 図1に示すHMIを構成する表示装置の画面表示例である。
以下、図面を用いて本発明の実施例について説明する。
図1は、本発明の一実施例に係る保全管理システムの全体概略構成図である。図1に示すように、保全管理システム1は、保全管理確認装置2、計測値データベース3、自動診断部4、保全計画データベース5、タスク計画部6、タスク実施記録部7、課金処理装置8、及びHMI(Human Machine Interface)9を備え、これらは相互にバスにてアクセス可能に接続されている。なお、HMI9は、図示しない、例えば、液晶ディスプレイ(LCD)又は有機ELディスプレイなどの表示装置と、例えば、キーボード及び/又はマウスなどの入力装置を備える。対象アセット10に設置されるセンサ11により計測される各種計測値は保全管理システム1へ入力される。また、自動診断部4は、例えば、図示しないCPU(Central Processing Unit)などのプロセッサ、各種プログラムを格納するROM、演算過程のデータを一時的に格納するRAM、外部記憶装置などの記憶装置にて実現されると共に、CPUなどのプロセッサがROMに格納された各種プログラムを読み出し実行し、実行結果である演算結果をRAM又は外部記憶装置に格納する。
本実施例の保全管理システム1が適用される、アセット10及びセンサ11は、特定のアセット、センサ技術、分析技術に限定されるものではないが、以下では、鉄道車両の軸受け監視とドア監視を一例として説明する。
(計測値データベース)
計測値データベース3は、センサ11により計測される対象アセット10の状態を表す計測値を格納する。センサ11から計測値データベース3へは、無線または有線の通信、あるいはメモリーカードやハードディスクなどにより、計測値が送信又は転送される。 図2に、図1に示す計測値データベース3のデータ構造を示す。図2に示すように、計測値データベース3は、「対象アセット」毎に、「時刻」及び「監視データ」を対応付けて格納している。「対象アセット」欄は、更に、対象アセット10である鉄道車両の「車両番号」欄、及び、軸受ベアリング、ドアなどの「対象コンポーネント」欄に細分化され、また、「監視データ」欄は、振動強度(規格化)、ドア開時間、ドア閉時間などの監視データの「種類」欄、及び当該種類毎の「計測値」欄に細分化され、それぞれ格納されている。ここで、「監視データ」の「種類」欄に格納される“振動強度(規格化)”とは、対象アセット10である鉄道車両の、車輪の軸受けの振動の強度を、平均的な振動強度で規格化した値(平均的な振動強度を「1.0」としたときの値)である。また、“ドア開時間”は、ドアの開動作の所要時間を、ドア開検知センサとドア閉検知センサの動作時刻の差分により算出して、「計測値」欄に保存している。“ドア閉時間”も同様にドア閉検知センサ、ドア開検知センサの動作時刻差分から算出して、「計測値」欄に保存している。また、ドアを開閉させる空気圧の圧力も記録しているものとする。
図2に示す例では、「対象アセット」の「車両番号」が“車両番号1”であり、「対象アセット」の「対象コンポーネント」が“軸受けベアリング1”については、「時刻」が“2016/10/03 08:00”の時、「監視データ」の「種類」である“振動強度(規格化)”が“1.05”として計測され、その1時間後の“2016/10/03 09:00”の時、“振動強度(規格化)”が、“1.18”として計測されたことを示している。
また、「対象アセット」の「車両番号」が“車両番号2”であり、「対象アセット」の「対象コンポーネント」が“ドア1”については、「時刻」が“2016/10/03 10:15”の時、「監視データ」の「種類」である“ドア開時間”が“5.0秒”であり、その18分後の“2016/10/03 10:23”では、“ドア開時間”が、“4.9秒”であったことを示している。
(故障情報データベース)
図3は、図1に示す保全管理確認装置2を構成する故障情報データベース21のデータ構造を示す図である。図3に示すように、故障情報データベース21は、「対象コンポーネント」毎に、「故障ID」、「故障モード」、「症状」、及び「原因」を対応付けて格納している。「対象コンポーネント」欄は、更に、軸受けベアリング、ドアなどの「コンポーネント」欄、及び、コンポーネントの構成を表すために、「上位コンポーネント」欄に細分化され、それぞれ格納されている。ここで、「故障ID」は、「対象コンポーネント」、「故障モード」、「症状」、及び「原因」を一意に対応付けて、ユニークな番号(数値)が設定される。また、「コンポーネント」と「上位コンポーネント」からなるコンポーネントの構成の情報は、装置の物理的構成に基づいた構造展開によるものでも、機能上の構成に基づいた、機能展開によるものでも良い。なお、上位コンポーネントについても、上位コンポーネントの階層で見た場合の機能に合わせて、故障モードが定義されても良い。発生時損害については、故障モードにより、実際に起こった詳細な故障モードに依存している場合は、下位の詳細な階層でのみ定義されても良い。一方で、部品交換の単位が大きい、あるいは運行の都合や契約上、上位の機能で運行損害が定義される場合は、上位のコンポーネント発生時損害が定義されても良く、この場合、下位コンポーネントの損害記述が無い場合もある。
図3に示す例では、「対象コンポーネントアセット」欄の「コンポーネント」が“軸受ベアリング1”であり、その「上位コンポーネント」欄が“台車1”であり、「故障ID」として“1”が割り付けられている場合、「故障モード」欄が“ベアリング内傷”、「症状」欄に“振動、発熱、固着”、「原因」欄に“異物、グリス切れ、衝撃”が格納されている。また、2行目では、「対象コンポーネントアセット」欄の「コンポーネント」が“軸受ベアリング1”であり、その「上位コンポーネント」欄が“台車1”であり、「故障ID」として“2”が割り付けられている場合、「故障モード」欄が“ベアリング内傷(大)”、「症状」欄に“発熱、固着”、「原因」欄に“ベアリング内傷の拡大”が格納されている。
“軸受ベアリング1”の上位コンポーネントである“台車1”が「コンポーネント」欄に格納される行においては、「上位コンポーネント」欄が“客車1”であり、「故障ID」として“31”が割り付けられている場合、「故障モード」欄が“軸受け異常”、「症状」欄に“車輪回転異常”、「原因」欄に“ベアリング異常、ベアリング固定異常”が格納されている。また、“台車1”の上位コンポーネントである“客車1”が「コンポーネント」欄に格納される行においては、「上位コンポーネント」欄が“編成”であり、「故障ID」として“41”が割り付けられている場合、「故障モード」欄が“台車異常”、「症状」欄に“走行に支障”が格納されている。
なお、本実施例では、「対象コンポーネント」欄に「上位コンポーネント」欄を含める場合を示したが、これに限られず、「対象コンポーネント」欄を「コンポーネント」欄のみとしても良い。
(自動診断定義データベース)
自動診断定義データベース22には、ルール(診断基準)に基づいて対象アセット(対象部品)の状態診断を行い、保全作業実施をきたす警報の定義が格納されている。図4に図1に示す保全管理確認装置2を構成する自動診断定義データベース22のデータ構造を示す。図4に示すように、自動診断定義データベース22は、「自動診断ID」、「対象アセット」、診断の種類を示す「診断種類」、警報を発報するセンサデータの条件を示した「診断基準」、診断基準が満たされた場合に、残存寿命予測や故障発生時の影響予測に基づいた適切な保全作業を記載した「保全要求」、及び「故障ID」を格納している。さらに、これらの自動診断定義データベース22に格納される自動診断定義は、故障情報データベース21と故障IDでリンクして保存されること、すなわち、リレーショナルデータベースとすることで、診断に対応するアセット、部品や故障モードが定義されているものとする。
図4に示す例では、「自動診断ID」が“1”では、「対象アセット」欄に“軸受けベアリング1”、「診断種類」欄に“ベアリング異常振動”、「診断基準」欄にルールとして“振動強度(規格化)Vが、V>=1.10となったときに、警報発報”、「保全要求」欄に“10日以内の部品交換”、「故障ID」欄に“1”が格納されている。ここで、「診断基準」欄に格納される“V>=1.10となったとき”とは、Vが1.10以上となったときを示している。
また、「自動診断ID」が“2”では、「対象アセット」欄に“軸受けベアリング2”、「診断種類」欄に“ベアリング異常振動”、「診断基準」欄に“振動強度(規格化)Vが、V>=1.10となったときに、警報発報”、「保全要求」欄に“10日以内の部品交換”、「故障ID」欄に“11”が格納されている。
また、「自動診断ID」が“4”では、「対象アセット」欄に“ドア”、「診断種類」欄に “ドア開時間異常”、「診断基準」欄に“ドア開時間DOTが、DOT>=5.5secとなったときに、警報発報”、「保全要求」欄に“15日以内の部品交換”、「故障ID」欄に“101”が格納されている。
「自動診断ID」が“5”では、「対象アセット」欄に“ドアレール”、「診断種類」欄に“ドアレール抵抗増大”、「診断基準」欄に“ドア開時間DOTがDOT>=5.2sec、かつ、ドア閉時間DCTがDCT>=5.2sec、かつ、ドア空気圧DPSがDPS>=3.0barとなったときに、警報発報”、「保全要求」欄に“15日以内の清掃と注油”、「故障ID」欄に“111”が格納されている。
なお、一旦、ある対象アセットのある故障モードの警報が発報した場合は、連続して発報しないように、診断基準(ルール)が再度満たされない状態にならない限り、新たな警報を連続して発報することはしないものとする。但し、対象アセットの状態が、発報の閾値周辺で揺らいでいるような場合は、繰り返し発報してしまう場合もありうる。このような繰り返し発報に対しては、発報抑制する機構の有無はどちらでも問題ないが、抑制する機構が完全ではない、あるいは故障自体が間欠的に発現することもありうる、実際の故障現象を想定して、繰り返し発報を考慮することが望ましい。これは、対象アセットを構成する各コンポーネントの自動診断の結果、各センサからの計測値に基づきその都度、警報が発報される毎に課金することを防止、また、対象アセットを構成する複数のコンポーネントに関する自動診断結果をまとめた上で、課金の対象とすることが合理的であることによる。
上述のように本実施例では、軸受けベアリング1に対して、「自動診断ID」が“1”の場合において、平均的な振動強度で規格化された振動強度(規格化)に対して、閾値による故障の予兆検知を行う構成としている。すなわち、振動強度(規格化)をVとして、V<1.10では正常、V>=1.10で故障の予兆発生として検知する。なお、故障の予兆が発生した時点でも、ベアリングは劣化が始まっているが機能は正常に維持されており、その後10日間は、交換作業は不要であるとわかっていることから、「保全要求」欄に“10日以内の部品交換”が格納されている。このような診断基準(ルール)の設定は、例えば、ベアリングの劣化の進展を、物理モデルあるいは加速試験や実部品の統計によりモデルを作成すること、あるいはエンジニアの設定数値を用いることで実現される。他の対象アセットとしての、ドアあるいはドアレールなどその他の部品についても同様に、それぞれ診断基準(ルール)が設定される。
(自動診断部)
自動診断部4は、バスを介して計測値データベース3および、保全管理確認装置2を構成する自動診断定義データベース22にアクセスし、計測値データベース3および自動診断定義データベース22に格納される情報に基づいて自動診断を実行する。自動診断の結果、発報があった場合は、自動診断部4は、バスを介して自動診断結果ログ記憶部25に、個々の発報を識別するための警報ID、実施された自動診断を自動診断定義データベース22に格納される対応する自動診断ID、警報が出された対象アセットの識別情報、および発報時刻などを記録する。なお、自動診断部4は、自動診断を実行する場合、知識情報データベースを参照することはない。
(自動診断結果ログ記憶部)
図5は、図1に示す保全管理確認装置2を構成する自動診断結果ログ記憶部25のデータ構造を示す図である。図5に示すように、自動診断結果ログ記憶部25は、「警報ID」、「自動診断ID」、「対象アセット」、および「発報時刻」を格納している。「対象アセット」欄は、更に、警報が出された対象アセットの識別情報として、「対象車両」欄及び「対象コンポーネント」欄に細分化されている。「警報ID」は、個々の発報を識別するため、自動診断部4によりバスを介して記録される。また、「発報時刻」は、自動診断部4によりバスを介して、警報発報時刻が記録される。自動診断部4は、自動診断定義データベース22に格納される「自動診断ID」及び「対象アセット」の情報及び警報発報時刻に対応する「対象車両」及び「対象コンポーネント」を計測値データベース3より読み出す。自動診断部4により読み出された「対象車両」及び「対象コンポーネント」が、それぞれ自動診断結果ログ記憶部25に記録される。
図5に示す例では、「警報ID」が“1”では、「自動診断ID」欄に“1”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“軸受けベアリング1”、「発報時刻」欄に“2016/10/03 09:00”が記録されている。
また、「警報ID」が“2”では、「自動診断ID」欄に“1”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“軸受けベアリング1”、「発報時刻」欄に“2016/10/03 11:00”が記録されている。
「警報ID」が“5”では、「自動診断ID」欄に“2”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“軸受けベアリング2”、「発報時刻」欄に“2016/10/08 11:00”が記録されている。
保全計画者は、対象アセットの運用者や保全作業員からの異常の報告があった場合、あるいは上述の自動診断結果ログ記憶部25の内容を、HMI9を構成する表示装置の画面表示により確認した場合に、タスク計画部6を用いて作業指示書を作成し、保全作業者に作業を依頼する。なお、HMI9を構成する表示装置の画面表示に代えて、HMI9を構成する印字装置(図示せず)にて自動診断結果ログ記憶部25の内容を表形式にてプリントアウトしても良い。このとき保全計画者は、現在の対象アセット10の故障状態、あるいは将来予測される故障状態と、保全計画データベース5に格納される保全可能日や、保全作業リソース状況を勘案して、妥当な保全作業計画を作成して、作業指示ログ記憶部26に記録することで、作業に割り当てられた保全作業者に指示を出す。なお、タスク計画部6は、例えば、図示しないCPU(Central Processing Unit)などのプロセッサ、各種プログラムを格納するROM、演算過程のデータを一時的に格納するRAM、外部記憶装置などの記憶装置にて実現されると共に、CPUなどのプロセッサがROMに格納された各種プログラムを読み出し実行し、実行結果である演算結果をRAM又は外部記憶装置に格納する。以下に、作業指示ログ記憶部26および、保全計画データベース5について説明する。
(作業指示ログ記憶部と保全計画データベース)
図6に図1に示す保全管理確認装置2を構成する作業指示ログ記憶部のデータ構造を示す。また図7に図1に示す保全計画データベース5のデータ構造を示す。
先ず、作業指示が自動診断の結果に基づくものか、そのほかの情報源に基づくものかは、保全作業の実施においては、参考情報として有益ではあるが、必ずしも必須の情報ではないため、保全計画者によって、記録される場合とされない場合があると想定される。自動診断部4により対象アセット10に対し自動診断を実行する場合、自動診断の結果に基づき、警報IDを自動的にあるいは手動で記録して、作成することも考えられる。
また、上述の図5に示した自動診断結果ログ記憶部25のデータ構造の一例に見られるように、「対象車両」が“車両番号1”、「対象コンポーネント」が“軸受けベアリング1”に関する警報については、対象アセットの状態が、図4に示した自動診断定義データベース22に格納される診断基準(ルール)と適合・非適合を繰り返すなど、警報が複数回記録される場合もある。その場合はどの警報IDを記録するか、あるいは記録せずに異常の内容を別途記載するかは、保全計画のルールや、保全計画者の裁量に依存することも考えられる。
また、自動診断部4による対象アセット10に対する自動診断結果を利用したことで、保全事業者が課金される場合は、課金を逃れるために、意図的に診断情報源を書き込まないことで、課金から逃れようとすることも想定される。
また、警報が出ているにもかかわらず、保全計画者が警報を参照していなかったために、保全作業者の報告といった、別の情報源に基づいて作業指示を作成したことで、警報とリンクされずに作業指示が作成されることも考えられる。
図6に示すように、作業指示ログ記憶部26は、「タスクID」毎に、「問題」、「対象アセット」、「故障ID」、「診断情報源」、「依頼日」(指示日)、および「作業予定日」を格納している。「対象アセット」欄は、更に、警報が出された対象アセットの識別情報として、「対象車両」欄および「対象コンポーネント」欄に細分化されている。これら、「問題」、「対象車両」、「対象コンポーネント」、「故障ID」、「診断情報源」、「依頼日」(指示日)、及び「作業予定日」が、各タスクIDに対応する作業指示に関する情報となる。
図6に示す例では、「タスクID」が“1”では、「問題」欄に“ドア開異常”、「対象車両」欄に“車両番号2”、「対象コンポーネント」欄に“ドア1”、「故障ID」欄に“10”、「診断情報源」欄に“NA”、「作業依頼内容」欄に“ドア開異常原因調査と修理”、「依頼日」(指示日)欄に“2016/9/30”、「作業予定日」欄に“2016/10/11”が記録されている。なお、「診断情報源」欄に記録されている“NA”とは、No Assignのことであり、空白(ブランク)を意味する。
「タスクID」が“2”では、「問題」欄に“トイレ詰まり”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“トイレ2”、「故障ID」欄に“200”、「診断情報源」欄に“作業員”、「作業依頼内容」欄に“清掃と点検”、「依頼日」(指示日)欄に“2016/10/1”、「作業予定日」欄に“2016/10/10”が記録されている。
また、「タスクID」が“3”では、「問題」欄に“ベアリング異常”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“軸受けベアリング1”、「故障ID」欄に“1”、「診断情報源」欄に“NA”、「作業依頼内容」欄に“ベアリング交換”、「依頼日」(指示日)欄に“2016/10/3”、「作業予定日」欄に“2016/10/10”が記録されている。
「タスクID」が“4”では、「問題」欄に“ベアリング異常”、「対象車両」欄に“車両番号3”、「対象コンポーネント」欄に“軸受けベアリング10”、「故障ID」欄に“1”、「診断情報源」欄に“警報ID4”、「作業依頼内容」欄に“ベアリング交換”、「依頼日」(指示日)欄に“2016/10/8”、「作業予定日」欄に“2016/10/30”が記録されている。
「タスクID」が“1”および“3”では、警報が発報状態にあるにもかかわらず、「診断情報源」欄は“NA”であり記載が無い。また、「タスクID」が“2”では、「診断情報源」欄は“作業員”であり、「タスクID」が“4”では、「診断情報源」欄は“警報ID4”であり、警報が記載されている。すなわち、実際の警報発報状況にもかかわらず、診断情報源は警報IDの記載があるものと無いものとが混在している。
また、保全計画データベース5は、図7に示されるように、「アセット」毎に、複数の「保全可能日」が格納されている。例えば、「アセット」が“車両番号1”については、「保全可能日」として、“2016/10/10”、“2016/10/30”などが格納されている。上述の図6に示した作業指示ログ記憶部26に格納される、「タスクID」が“3”の場合では、「対象車両」が“車両番号1”であり、かつ、「依頼日」(指示日)が“2016/10/3”であることから、保全計画データベース5に格納される“車両番号1”に対する「保全可能日」のうち、「依頼日」(指示日)“2016/10/3”に直近の“2016/10/10”が、「作業予定日」欄に記録される。
保全作業者は、作業指示ログ記憶部26を参照することで、指示に従って保全作業を実施する。保全作業において保全作業者は、保全指示の内容が正しいものであるか対象アセット10を調査することで確認する。あるいは、作業指示の段階では、詳細な故障モードが判明していない場合も調査によって、問題を引き起こしている故障モードを特定する。
故障モードが確認された後に、詳細後述する、保全管理確認装置2を構成する保全方法データベース23に格納されている保全方法に基づき作業を実施する。作業後に、保全作業者は、調査結果や実施した作業の内容を、タスク実施記録部7を用いて、保全管理確認装置2を構成する保全作業ログ記憶部24に記録する。なお、タスク実施記録部7は、例えば、図示しないCPU(Central Processing Unit)などのプロセッサ、各種プログラムを格納するROM、演算過程のデータを一時的に格納するRAM、外部記憶装置などの記憶装置にて実現されると共に、CPUなどのプロセッサがROMに格納された各種プログラムを読み出し実行し、実行結果である演算結果をRAM又は外部記憶装置に格納する。以下に、保全作業ログ記憶部24および保全方法データベース23について説明する。
(保全作業ログ記憶部と保全方法データベース)
図8は図1に示す保全管理確認装置2を構成する保全作業ログ記憶部24のデータ構造を示す図であり、図9は図1に示す保全管理確認装置2を構成する保全方法データベース23のデータ構造を示す図である。
図9に示すように、保全方法データベース23は、「保全方法ID」毎に、「故障ID」、故障IDにより紐付けられる故障情報データベース21(図3)に格納される「故障モード」に対応して、各故障モードが疑われる場合の検査・診断方法として「検査方法」、および、発生している故障モードが特定された場合の保全タスクとして「処置方法」を格納している。
図9に示す例では、「保全方法ID」が“1000”では、「故障ID」欄に“1”、「検査方法」欄に“センサによる振動強度確認”、「処置方法」欄に“部品交換”が格納されている。
また、「保全方法ID」が“1001”では、「故障ID」欄に“2”、「検査方法」欄に“発熱のチェック、振動強度確認”、「処置方法」欄に“部品交換。必要に応じて周辺部品交換”が格納されている。
「保全方法ID」が“1111”では、「故障ID」欄に“111”、「検査方法」欄に“レール内目視点検”、「処置方法」欄に“清掃・注油”が格納されている。
また、「保全方法ID」が“2001”では、「故障ID」欄に“200”、「検査方法」欄に“上部からの目視または分解検査”、「処置方法」欄に“つまり除去”が格納されている。
作業後に、保全作業者は、調査結果や実施した作業の内容を、タスク実施記録部7を用いて、保全管理確認装置2を構成する保全作業ログ記憶部24に記録する。図8に示すように、保全作業ログ記憶部24は、「タスクID」毎に、「検査」、「運用」、「保全方法ID」、「処置」、「実施日時」、および「作業時間(分)」を記録している。「検査」欄は更に「検査結果」欄と「故障ID」欄に細分化され、「運用」欄は更に「影響有無」欄と対象アセット10の運用停止時刻である「運用停止時刻」欄に細分化され、「処置」欄は更に、「作業内容」欄、「対象車両」欄、および「対象コンポーネント」欄に細分化されている。
図8に示す例では、「タスクID」が“1”では、「検査結果」欄に“ドアレール目視点検。レール内ゴミ発見。空気圧異常なし”、「故障ID」欄に“111”、「影響有無」欄と「運用停止時刻」欄に“なし”、「保全方法ID」欄に“1111”、「作業内容」欄に“清掃”、「対象車両」欄に“車両番号2”、「対象コンポーネント」欄に“ドア1”、「実施日時」欄に“2016/10/11 13:00”、「作業時間(分)」欄に“30”が記録されている。
また、「タスクID」が“2”では、「検査結果」欄に“つまり場所特定”、「故障ID」欄に“200”、「影響有無」欄に“トイレ使用不能”、「運用停止時刻」欄に“2016/10/01 07:00”、「保全方法ID」欄に“2001”、「作業内容」欄に“清掃”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“トイレ2”、「実施日時」欄に“2016/10/10 15:00”、「作業時間(分)」欄に“40”が記録されている。
「タスクID」が“3”では、「検査結果」欄に“ベアリング振動確認”、「故障ID」欄に“1”、「影響有無」欄と「運用停止時刻」欄に“なし”、「保全方法ID」欄に“1000”、「作業内容」欄に“部品交換”、「対象車両」欄に“車両番号1”、「対象コンポーネント」欄に“軸受けベアリング1”、「実施日時」欄に“2016/10/10 16:00”、「作業時間(分)」欄に“200”が記録されている。
また、「タスクID」が“6”では、「検査結果」欄に“ベアリングと周辺部品の破壊を確認”、「故障ID」欄に“2”、「影響有無」欄に“運用不能”、「運用停止時刻」欄に“2016/10/03 12:02”、「保全方法ID」欄に“1001”、「作業内容」欄に“部品交換”、「対象車両」欄に“車両番号4”、「対象コンポーネント」欄に“台車1”、「実施日時」欄に“2016/10/10 21:00”、「作業時間(分)」欄に“500”が記録されている。
一連の保全プロセスによって、自動診断あるいはその他の情報源によって、対象アセット10に問題が見つかった場合の、保全作業の実施が完了する。以下、このような保全プロセスにおいて、保全事業者が自動診断部4による自動診断結果を用いたことを、保全管理確認装置2にて検出する方法について説明する。
(タスク実績分析部)
図10に図1に示す保全管理確認装置2を構成するタスク実績分析部27の処理フローを示す。タスク実績分析部27は、新規に保全作業ログが上述の保全管理確認装置2を構成する保全作業ログ記憶部24に記録された場合、あるいは一定の時間間隔、カレンダー指定日、あるいは保全事業者あるいはIT事業者の指示に基づいて起動され、以下の処理を行う。以下では、新規に保全作業ログが上述の保全管理確認装置2を構成する保全作業ログ記憶部24に記録されたタイミングで、タスク実績分析部27が処理を開始する場合を一例として説明する。なお、タスク実績分析部27は、例えば、図示しないCPU(Central Processing Unit)などのプロセッサ、各種プログラムを格納するROM、演算過程のデータを一時的に格納するRAM、外部記憶装置などの記憶装置にて実現されると共に、CPUなどのプロセッサがROMに格納された各種プログラムを読み出し実行し、実行結果である演算結果をRAM又は外部記憶装置に格納する。
図10に示すように、ステップS101では、タスク実績分析部27が対象保全ログ取得処理を実行する。具体的には、タスク実績分析部27は、バスを介して作業指示ログ記憶部26へアクセスし、タスク実施記録部7を用いて保全管理確認装置2を構成する保全作業ログ記憶部24に記録されたタスクIDと、同じタスクIDをもつ作業指示ログを読み込む。ここでは、説明を解り易くするため一例として「タスクID」が“3”の場合について説明する。作業指示ログ記憶部26より読み出される「タスクID」が“3”の作業指示ログは、図6に示すように、作業指示情報として、「問題」が“ベアリング異常”、「対象車両」が“車両番号1”、「対象コンポーネント」が“軸受けベアリング1”、「故障ID」が“1”、「診断情報源」が“NA”、「作業依頼内容」が“ベアリング交換”、「依頼日」(指示日)が“2016/10/3”、および「作業予定日」が“2016/10/10”であることが読み込まれる。
次にステップS102では、タスク実績分析部27が自動診断結果ログ取得処理を実行する。具体的には、タスク実績分析部27は、バスを介して自動診断結果ログ記憶部25へアクセスし、自動診断結果ログとして、対象アセット10である車両番号1の軸受けベアリング1に関して、作業指示ログ記憶部26から取得した依頼日(指示日:2016/10/3)より以前の一定期間内Dに対象アセット10である車両番号1の軸受けベアリング1について発報された警報を、自動診断結果ログ記憶部25から読み込む。ここで一定期間Dは、保全計画者により時間幅として指定され、例えば30日間が一定期間Dとして指定される。この結果、例えば、図5に示す例では、少なくとも、対象アセット10である車両番号1の軸受けベアリング1に関して発報された警報として、「警報ID」が“1”で「自動診断ID」が“1”、および、「警報ID」が“2”で「自動診断ID」が“1”が読み出される。なお、図5では、説明を解り易くするため「警報ID」が“1”から“6”までの場合を示したが、実際はこれよりも多くの「警報ID」が格納されている。このように、複数の自動診断結果ログが読み込まれることもありうるため、以降はステップS103とステップS106に示すように、ここのログをループして処理する。換言すれば、自動診断部4による自動診断結果に応じてループ処理を行う。
ステップS104では、タスク実績分析部27が故障情報及び保全方法の読み込み処理を実行する。具体的には、タスク実績分析部27は、バスを介して自動診断定義データベース22(図4)へアクセスし、ステップS102で読み込まれた「警報ID」が“1”で「自動診断ID」が“1”のうち、自動診断ID“1”に対応する故障ID“1”を抽出する。その後、タスク実績分析部27は、故障情報データベース21(図3)にアクセスし、上記抽出された故障ID“1”に対応する故障情報を読み込む。ここで、読み込まれる故障情報は、図3に示した、「故障モード」として“ベアリング内傷”、「症状」として“振動、発熱、固着”、および「原因」として“異物、グリス切れ、衝撃”を含む。
また、タスク実績分析部27は、保全方法データベース23(図9)へアクセスし、上記抽出された故障ID“1”に対応する保全方法を読み込む。ここで読み込まれる保全方法は、図9に示した保全方法ID“1000”に対応する、「検査方法」として “センサによる振動強度確認”および「処置方法」として“部品交換”を含む。
ステップS105では、タスク実績分析部27が自動診断・保全ログ一致度算出処理を実行する。具体的には、タスク実績分析部27は、保全管理確認装置2を構成する保全作業ログ記憶部24(図8)へアクセスし、ステップS104で抽出された故障ID“1”に対応する保全作業ログ記憶部24に格納される保全作業ログと、既に取得された自動診結果ログを比較することで、自動診断部4による自動診断結果が、保全作業ログ記憶部24に記録された、検査の結果確定された実際の故障状況とどの程度一致していたかを示す、一致度Mの算出を行う。一致度Mの算出方法としては、例えば次のような要素やその組み合わせにて実現できる。まず、自動診断結果ログ記憶部25に格納される自動診断IDがリンクしている故障IDと、保全作業ログ記憶部24に記録された故障IDが一致している場合は、故障を詳細な精度で確定できているので、一致度MをM=1とする。本実施例の場合においては上述の通り、自動診断結果ログ記憶部25に格納される自動診断IDがリンクしている故障IDは“1”(上記抽出された故障ID“1”)であり、保全作業ログ記憶部24に記録された故障IDが“1”であることから、一致度MはM=1となる。
また、故障IDが一致しない場合でも、近い故障を自動診断部4が出していた場合は、一致度を与えることができる。例えば、本実施例では、図3に示したように、故障情報データベース21は、「対象コンポーネント」として「コンポーネント」と「上位コンポーネント」を格納している。すなわち、コンポーネントの階層関係が与えられているため、これを用いて一致度を算出できる。
図11は、図3に示す故障情報データベース21に格納される対象コンポーネントの階層構成を示す図である。図11に示すように、この対象コンポーネントの階層構成は、「編成」を最上位として、コンポーネントを構造で細分化したネットワークにて定義されており、また、各故障IDは、ネットワーク内のいずれかのコンポーネントに関係して定義されている。このとき、一致度を定義する方法として、ネットワーク上の距離Lを、自動診断部4による自動診断結果、すなわち、自動診断IDにリングした故障IDと、保全作業ログ記憶部24に記録された故障ID間を、最短距離で辿った場合の、間に存在するコンポーネント数で定義することが可能である。例えば、図11に示す軸受けベアリング1に関し、自動診断IDにリンクした故障IDが“1”、保全作業ログ記憶部24に記録された故障IDが“2”の場合を想定すると、これら故障ID“1”および故障ID“2”の間に存在するコンポーネントは軸受けベアリング1のみであることから、ネットワーク上の距離LはL=1となる。また、例えば、軸受けベアリング1に関し、自動診断IDにリンクした故障IDが“1”、保全作業ログ記憶部24に記録された軸受けベアリング2に関する故障IDが“11”の場合を想定すると、これら故障ID“1”および故障ID“11”の間に存在するコンポーネントは、軸受けベアリング1および軸受けベアリング2であることから、ネットワーク上の距離LはL=2となる。そして、これらの場合において一致度として例えば、M=1/(L+1)として定義することができる。一般的には、一致度Mは距離Lの減少関数Fを用いて、M=F(L)となっていれば良い。
また、このようなネットワーク上の距離Lを用いる場合、いくらでも遠いコンポーネントへの警報に一致度Mが定義されないように、距離Lが所定値より大きい場合はM=0としても良い。また、ネットワークを構成するコンポーネント間の接続に重み付けを行い、故障の状況や保全作業の関連性が高いものは距離Lが小さくなるようにする、あるいは、同一のコンポーネントに関連した別の故障IDでは、一致度Mが大きくなるように補正しても良い。センサ11の不備によって、詳細コンポーネントでの診断が困難な場合は、上位コンポーネントに定義された故障情報に関連した警報であっても、一致度Mを大きくするなどの、補正を行うことが可能である。
次に、再びステップS104に戻り、タスク実績分析部27は、バスを介して自動診断定義データベース22(図4)へアクセスし、ステップS102で読み込まれた「警報ID」が“2”で「自動診断ID」が“1”のうち、自動診断ID“1”に対応する故障ID“1”を抽出する。その後、タスク実績分析部27は、故障情報データベース21(図3)にアクセスし、上記抽出された故障ID“1”に対応する故障情報を読み込む。ここで、読み込まれる故障情報は、図3に示した、「故障モード」として“ベアリング内傷”、「症状」として“振動、発熱、固着”、および「原因」として“異物、グリス切れ、衝撃”を含む。また、タスク実績分析部27は、保全方法データベース23(図9)へアクセスし、上記抽出された故障ID“1”に対応する保全方法を読み込む。ここで読み込まれる保全方法は、図9に示した保全方法ID“1000”に対応する、「検査方法」として “センサによる振動強度確認”および「処置方法」として“部品交換”を含む。
また、ステップS105では、タスク実績分析部27が自動診断・保全ログ一致度算出処理を実行する。具体的には、タスク実績分析部27は、保全管理確認装置2を構成する保全作業ログ記憶部24(図8)へアクセスし、ステップS104で抽出された故障ID“1”に対応する保全作業ログ記憶部24に格納される保全作業ログと、既に取得された自動診結果ログを比較することで、自動診断部4による自動診断結果が、保全作業ログ記憶部24に記録された、検査の結果確定された実際の故障状況とどの程度一致していたかを示す、一致度Mの算出を行う。
ここまでの処理により、「タスクID」が“3”の場合についての処理が終了し、タスク実績分析部27は、保全作業ログ記憶部24に記録される「タスクID」が“3”(図8)、作業指示ログ記憶部26に記録されるタスクID“3”に対応する診断情報源“NA”(図6)、自動診断結果ログ記憶部25に記録される警報ID“1”と警報発報時刻“2016/10/03 09:00”および警報ID“2”と警報発報時刻“2016/10/03 11:00”、および、算出した一致度M(M=1)を詳細後述する課金処理装置8へ出力する。
本実施例では、説明を解り易くするため、「タスクID」が“3”の場合についてのみ説明したが、実際には、他のタスクIDについても同様の処理をタスク実績分析部27が実行する。図12に図1に示す保全管理確認装置2を構成するタスク実績分析部27による一致度算出結果を示す。図12に示すように、一致度算出結果は、例えば、「保全作業ログ タスクID」、「診断情報源」、「自動診断結果ログ 警報ID」、「一致度M」、および「発報時刻」からなる一覧(表形式)にて出力される。
図12に示すように、「保全作業ログ タスクID」が“1”については、「診断情報源」欄に“NA”、「自動診断結果ログ 警報ID」欄に“3”、「一致度M」欄に“0.33”、および「発報時刻」欄に“2016/10/03 09:00”が書き込まれる。
また、「保全作業ログ タスクID」が“3”については、「診断情報源」欄に“NA”、「自動診断結果ログ 警報ID」欄に“1”と“2”、「一致度M」欄に“1”、および「発報時刻」欄に“2016/10/03 09:00”と“2016/10/03 11:00”が書き込まれる。
以上の通り、保全管理確認装置2は、自動診断部4による自動診断結果が保全作業に利用された可能性があるかを、自動診断結果ログ記憶部25に記録される自動診断結果と保全作業ログ記憶部24に記録される保全作業ログの間の一致度Mを算出することで、保全作業ログ記憶部24に記録される保全作業ログあるいは作業指示ログ記憶部26に記録される作業指示に自動診断結果利用の有無の記載があるか否かににかかわらず、自動診断結果の利用を適切に検出することが可能となる。
なお、タスク実績分析部27による一致度Mの算出法は、上述の方法に限られるものでは無い。例えば、自動診断結果にリンクした故障情報データベース21(図3)には、コンポーネント、故障モード、症状、および原因が格納されている。これをテキストマッチングにより、保全作業ログ記憶部24(図8)に記録される検査結果(検査内容)と比較することが可能である。一致する単語があった場合、一致数nに応じて一致度Mを、例えばM=1−2-nとして算出しても良い。この場合、テキストマッチングにおいて、一致数nが小さいほど一致度Mの値は1より小さくなり、一致数nがゼロの場合には一致度M=0となる。逆に、一致数nが大きいほど一致度Mは限りなく1に近づく。
また、たとえ特定した故障IDが異なっていても、実際の処置作業が同じで、作業時間や損害拡大防止の効果が同じであれば、一致度Mは高いと考えて、自動診断結果にリンクした故障情報データベース21に対してリンクしている保全方法データベース23と、実際に保全作業ログ記憶部24に記録された保全方法(作業内容)とを比較する方法もある。この場合、双方の保全方法IDが一致するならば一致度MをM=1としても良く、特定した故障IDが異なることに着目して、一致度Mを引き下げて、例えばM=0.5などとしても良い。
次に、自動診断部4による自動診断結果の利用により、保全事業者が得た利益を算出して課金額を定める方法について説明する。
(課金処理装置による課金額の算出)
図1に示す課金処理装置8を構成する課金額推定部81は、保全作業実施により保全事業者が得た利益の推定と、自動診断部4による自動診断結果が保全作業に利用可能性があり、実際に利用されたと推定されるかの判定およびその際の一致度Mを用いることで、保全事業者が得た利益の一部を自動診断結果の利用料金とする、課金額の推定を行う。
はじめに保全事業者が得る利益の推定方法について説明する。本実施例では、保全作業の実施や自動診断部4による自動診断結果の利用によって得られる利益を、早期処置による対象アセット10の破壊・劣化進展の防止、運用への影響防止による機会利益の確保、自動診断結果を用いることで保全作業者による検査が削減されることによる作業コストの削減として、計算する。なお、機会利益確保については、運用事業者と保全事業者が別の業者の場合も、運用事業者が機会利益を損失したときに保全事業者に課すペナルティに置き換えることができる。
また、保全作業実施による安全性確保も、対象故障発生時の事故に関する保険金額を通じた計算などによって、金額に換算することが可能である。あるいは、運用事業者から保全事業者に契約に基づいて課すペナルティ金額を用いることも可能である。
図13に図1に示す課金処理装置8を構成する診断課金データベース83のデータ構造を示す。図13に示すように、診断課金データベース83は、故障情報データベース21(図3)に格納される「故障ID」に関連付けて、「運用障害予防効果[万円]」および「作業コスト削減効果[万円]」を格納している。ここで、運用障害予防効果は、故障に伴う運用障害を予防できた場合に得られる利益を、予防できなかった場合に対象アセット10の破壊・運用停止・保険値上がりなどで受ける損害から推定している。この推定は、過去の統計や、契約記載の値から算出したものとする。また、作業コスト削減効果は、自動診断部4による自動診断結果を用いた場合の作業時間削減効果に対応するコスト削減効果である。本実施例では、診断課金データベース83における「運用障害予防効果[万円]」および「作業コスト削減効果[万円]」を定数として格納しているが、これは過去の故障発生時の損害や、保全作業員による診断の作業時間のコスト換算の統計に基づいてそれぞれ設定しても良い。
図14は、図1に示す課金処理装置8を構成する課金額推定部81の処理フロー図である。課金額推定部81は、新規に保全作業ログが上述の保全管理確認装置2を構成する保全作業ログ記憶部24に記録され、タスク実績分析部27により一致度Mが算出された場合、あるいは一定の時間間隔、保全事業者あるいはIT事業者の指示などに基づき起動される。本実施例では、保全作業ログを一件ごとに処理する場合を一例として説明するが、複数の保全作業ログを纏めて処理する構成としても良い。
図14に示すように、ステップS201では、課金額推定部81が一致度算出結果読み込み処理を実行する。具体的には、課金額推定部81は、バスを介して保全管理確認装置2を構成するタスク実績分析部27により算出された一致度算出結果(図12)を読み込む。
ステップS202では、課金額推定部81が関連データの読み込み処理を実行する。具体的には、課金額推定部81は、バスを介して、故障情報データベース21、保全方法データベース23、保全作業ログ記憶部24、自動診断結果ログ記憶部25、作業指示ログ記憶部26、および保全計画データベース5にアクセスする。そして、課金額推定部81は、ステップS201にて読み込んだ一致度算出結果(図12)中に含まれるタスクID及び警報IDを検索キーとして、故障情報データベース21、保全方法データベース23、保全作業ログ記憶部24、自動診断結果ログ記憶部25、作業指示ログ記憶部26、および保全計画データベース5より以降の作業で用いる関連データを読み込む。
ステップS203では、課金額推定部81が最適警報の抽出処理を実行する。具体的には、課金額推定部81は、警報が保全計画者による作業指示の判断に使われた可能性があるか判定し、かつ、もっとも有益であったと推測される警報を抽出するために、作業指示より以前に発報された警報で、最も一致度Mが高い警報を抽出する。一致度Mが同じ警報があった場合は、最も発報時刻の古い警報を最適警報として抽出する。これは、早期に発報された警報が、故障発生リスクを低減し、保全準備を容易にし、運用への影響も低減できるためである。また、保全事業者とIT事業者間の取り決めの都合や、あるいは警報が使用できた可能性ではなく、実際に使用した警報を重視して課金する場合には、最適警報の抽出処理では、診断情報源に書き込まれた警報IDを用いても良い。
ステップS204では、課金額推定部81が運用障害防止効果算出処理を実行する。具体的には、課金額推定部81は、運用障害の防止効果について、診断課金データベース83に格納される「運用障害予防効果」欄のデータなどを用いて算出する。この処理では、警報発報によって、運用停止を予防できる可能性があったかを判定し、可能であった場合は効果を算入し、不可能の場合は算入しない。すなわち、警報が発報されたとしても、警報発報から次の保全可能タイミングまでが短く、保全作業実施の準備ができなかった場合は、保全可能タイミングを逸してしまい、結果として、さらに次の保全可能タイミングの前に、運行停止せざるを得なくなる可能性があるためである。この判断を行うために、警報発報時刻に、自動診断定義データベース22の「保全要求」欄に格納されている保全作業実施までのリードタイムを加えたものと、保全計画データベース5に格納されている保全可能日を比較する。警報発報時刻からリードタイムのうちに、保全可能日が存在する場合は、運行損害を防止可能であったと推定し、当該警報IDに対応する故障IDを抽出する。診断課金データベース83において抽出された故障IDに対応する「運用障害予防効果」欄に格納されている額を運用障害予防額POとする。しかし、保全可能日が存在しない場合は、次の保全可能日まで運用を停止することになるため、効果を算入せず、運用障害予防額PO=0とする。
なお、作業コスト削減効果額PMについては、作業指示前に警報が発報されていれば、その結果を用いて保全作業可能と推定できることから、ステップS203にて抽出された最適警報であれば、当該最適警報の警報IDに対応する故障IDを抽出する。そして、診断課金データベース83おいて抽出された故障IDに対応する「作業コスト削減効果」欄に格納されている額を作業コスト削減効果額PMとする。
ステップS205では、課金額推定部81が自動診断効果算出処理を実行する。具体的には、課金額推定部81は、バスを介して保全作業ログ記憶部24へアクセスし、検査で明らかになった実際の故障IDを自動診断部4による自動診断結果で特定できた場合に、自動診断結果の利用によって実際に得られた、あるいは得ることが可能であったと見込まれる利益の金額PEを、PE=PO+PMとして算出する。さらに、実際に自動診断結果が特定した故障IDと、保全作業ログ記憶部24に記録されている故障IDの一致度Mに基づき、自動診断結果によって、保全作業者が得たあるいは得ることが可能であった利益Pを、P=PE×Mとして算出する。
ステップS205にて算出した、保全事業者が得た利益Pの一部を保全IT事業者の課金額とするために、ステップS206では、課金額推定部81が課金額算出処理を実行する。具体的には、課金額推定部81は、課金率をRとして、課金額Cを、C=P×Rとして推定する。なお、課金率Rは、保全事業者と保全IT事業者間の取り決めで事前に定めるものであり、例えばR=10%に定められる。また、故障情報ごとに異なる課金率Rを設定しても良い。
以上の処理により、課金額推定部81は、保全事業者が自動診断結果を利用することで、実際に得たあるいは得ることが可能であった利益に対する課金額Cを推定することができる。
図15は、図1に示す課金処理装置8を構成する課金額推定部81による課金額推定結果を示す図である。図15に示すように、課金額推定結果は、「タスクID」、「警報ID」、「一致度M」、「運用損害予防額PO」、「運用損害予防可否」、「作業コスト削減額PM」、「見込み利益PE」、「利益P」、および「課金額C[万円]」からなる一覧(表形式)にて出力される。
図15に示す例では、保全作業ログ記憶部24に記録された、タスクID“1”、タスクID“3”、およびタスクID“4”では、運用障害防止効果が得られていることから「運用損害予防額PO」、「作業コスト削減額PM」が得られている。しかし、タスクID“2”では、警報が発報されていない(警報IDが“なし”)ために、「利益P」、「課金額C[万円]」は共に“0”となる。タスクID“5”およびタスクID“6”では、警報は発報されているものの、直近の保全可能日直前であったために対応できず、次の保全可能日に保全作業が実施されている。そのため、運用停止が発生してしたため、「運用損害予防可否」は“不可能”となっている。
課金額推定部81は、バスを介して課金額決定部82へ課金額推定結果を出力(転送)する。課金額決定部82は、課金額推定部81より推定された課金額を、HMI9を構成する表示装置(図示せず)の画面上に表示し、保全事業者による確認を取ることで、課金額を決定する。このとき、保全事業者による課金の妥当性を詳細に判断可能とするため、警報、保全作業指示、および保全作業の内容を、補助情報として画面上に同時に表示する構成としても良い。
また、この課金の妥当性について、保全事業者と保全IT事業者の間で合意を取ることが考えられるため、保全作業ログ記憶部24に記録されたそれぞれの保全作業ログについて容易に確認を取れるように、個別の確認完了ボタンや、チェックボックスなどを併せて画面上に表示する構成としても良い。また、画面上に課金額Cを修正して入力し得る入力領域を設ける構成としても良い。これにより、計算上は保全事業者が効果を得ており、課金額Cが0以外となっているが、実際上は全く効果が無かった警報に対して、保全事業者がクレームをつけることが可能となる。
例えば、保全作業ログ記憶部24(図8)におけるタスクID“6”については、自動診断結果ログ記憶部25における警報ID“6”に示されるように警報が発報時刻“2016/10/03 12:01”に発報されているものの、運用不能となる直前であったために、車両停止などの措置が間に合わなかったために、台車1が破損して、保全事業者は大きな損害を被っている。これは、例えば、自動診断定義データベース22に格納される自動診断ID“6”のベアリング発熱検知がより早く異常の兆候を見つけて、車両を安全に停止すれば防げたと考えられる。あるいは、ベアリングの劣化は、一般に小さな傷などによる振動の発生から、大きな傷による発熱に進展し、発熱後は短期間で固着など大きな故障に繋がる。そのため、自動診断ID“1”のベアリング異常振動の検知が、先に発報するべきであったにもかかわらず、今回は発報していない。このように、警報が適切に発報されていない、予定の性能を満たしていないと考えられる場合は、保全事業者は課金を承認しないことで、不当な課金をさけ、また、保全IT事業者に自動診断部4の問題点を知らせることができる。あるいは、課金額Cを減額することも考えられる。
一方、逆に、課金額がゼロ推定されても、例えばセンサ11の不良によるものであった場合は、保全IT事業者の責任ではないため、本来は検知可能であったとして、一定の金額を課金することも考えられる。
図16に、図1に示すHMI9を構成する表示装置の画面表示例を示す。図16に示すように、HMI9を構成する表示装置の表示画面91は、第1表示領域92および確認ボタン93より構成される。第1表示領域92には、保全作業ログ記憶部24より抽出された「タスクID」、「検査結果」、および「故障ID」が表示される領域と、自動診断結果ログ記憶部25より抽出された「警報ID」、自動診断定義データベース22より抽出された「診断種類」、およびタスク実績分析部27により算出された「一致度」が表示される領域と、課金額推定部81からの出力をまとめた「保全事業者利益推定[万円]」および「課金額[万円]」が表示される領域と、保全事業者と保全IT事業者の協議に基づき最終的に決定された課金額の入力を可能とする「課金額決定値[万円]」の領域と、例えばマウスによるクリックにて保全事業者と保全IT事業者の「合意」を確定するチェックボックスが表示される。なお、第1表示領域92に表示される内容は、上述の表示内容に限らず、適宜表示内容を変更しても良い。また、上述の各領域、例えば、「タスクID」領域あるいは「故障ID」領域をマウスによるクリックにてアクティブにすることで、関連する個別のデータ、作業指示ログ、保全作業ログ、あるいは自動診断結果ログなどをポップアップウィンドウまたはリンク画面に表示するよう構成しても良い。
「合意」を示すチェックボックスの全項目にチェックマークが入力された場合、あるいは一部の項目にチェックマークが入力された場合、確認ボタン93上にマウスカーソルを移動しマウスによるクリックにて確認ボタン93がアクティブにされると、対応する項目の課金額が確定する。これにより、保全事業者に対し課金額が通知される。
一方、保全IT事業者に対しては、課金額の通知に加えて、自動診断結果ごとの課金額、警報の発報状況、あるいは保全事業者との交渉結果、保全作業ログごとの課金状況を通知する。
これにより保全IT事業者は、適切に警報を発報できずに、課金できていない保全作業ログ、課金額が低い警報などの情報、あるいはそれらにリンクした故障情報を知ることで、自動診断定義データベース22内における診断基準の追加、あるいは診断基準の改善による予防的な警報発報の実現、さらには診断基準の改善による一致度Mを向上することへのインセンティブが働く。また、課金額が高く、すなわち保全事業者にとって、保全業務の改善効果が大きい自動診断部4による自動診断結果については、自動診断部4にて、診断に利用するリソースを増強するといった計画を立案することが可能となる。
特に、本実施例のように、一致度Mを乗じて保全事業者の利益Pを算出することで、一致度Mが大きく、すなわち故障モードの特定精度が高い自動診断を行うことで、保全事業者利益と、課金額を高くすることが可能である。例えば、図16に示すタスクID“1”のドア開異常のケースでは、自動診断ID“4”のドア開時間異常の警報(警報ID“3”)が発報された結果、一致度はM=0.33となっている。しかし、自動診断定義データベース22に格納されている自動診断ID“5”のドアレール抵抗増大の警報が発報されていれば、一致度はM=1となり、保全事業者は検査をより削減でき、保全IT事業者もより大きな課金額を得られた。これは、ドアレール抵抗増大の診断基準に満たなかったためだが、診断基準の改善や、新たなセンサの設置によってより高精度の診断を行えば、ドアレール抵抗増大を発報できた可能性がある。
なお、本実施例では、課金処理装置8を保全管理システム1内に有する構成としたが、必ずしもこれに限られるものでは無い。例えば、課金処理装置8がネットワーク(有線、無線を問わない)を介して保全管理システム1に接続される構成としても良い。
以上の通り本実施例によれば、保全事業者による自動診断結果の利用を適切に検出し得る保全管理システム及びそれに用いる保全管理確認装置を提供することが可能となる。 また、本実施例によれば、保全事業者が自動診断結果に基づく保全作業によって得た利益に対し、保全IT事業者が適切な課金を行うことが可能となる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。
例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
1・・・保全管理システム,2・・・保全管理確認装置,3・・・計測値データベース,4・・・自動診断部,5・・・保全計画データベース,6・・・タスク計画部,7・・・タスク実施記録部,8・・・課金処理装置,9・・・HMI,10・・・対象アセット,11・・・センサ,21・・・故障情報データベース,22・・・自動診断定義データベース,23・・・保全方法データベース,24・・・保全作業ログ記憶部,25・・・自動診断結果ログ記憶部,26・・・作業指示ログ記憶部,27・・・タスク実績分析部,81・・・課金額推定部,82・・・課金額決定部,83・・・診断課金データベース,91・・・表示画面,92・・・第1表示領域,93・・・確認ボタン

Claims (12)

  1. 診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、センサにより計測される前記診断対象アセットの状態を表す計測値及び前記診断基準に基づき当該診断対象アセットの故障モードの発生を検出又は予測する自動診断部と、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも前記自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、
    前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする保全管理システム。
  2. 請求項1に記載の保全管理システムにおいて、
    前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、一致度を算出し、当該算出した一致度に基づいて保全作業に自動診断結果が用いられたことを検出することを特徴とする保全管理システム。
  3. 請求項2に記載の保全管理システムにおいて、
    前記故障情報データベースは、診断対象アセットを構成する複数のコンポーネント間の階層関係を表すネットワークを格納し、
    前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容に対応するコンポーネントと、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法に対応するコンポーネントとのネットワーク上の距離に基づく減少関数を用いて前記一致度を算出することを特徴とする保全管理システム。
  4. 請求項2に記載の保全管理システムにおいて、
    少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を算出する課金処理装置を備えることを特徴とする保全管理システム。
  5. 請求項3に記載の保全管理システムにおいて、
    少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を算出する課金処理装置を備えることを特徴とする保全管理システム。
  6. 請求項4に記載の保全管理システムにおいて、
    前記課金処理装置は、
    少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を推定する課金額推定部と、
    課金額推定部により推定された課金額を表示装置の画面上に表示させると共に、前記画面上に表示された推定された課金額に対する修正入力に基づき、前記自動診断部による診断結果の利用に対する課金額を決定する課金額決定部と、を備えることを特徴とする保全管理システム。
  7. 請求項5に記載の保全管理システムにおいて、
    前記課金処理装置は、
    少なくとも前記タスク実績分析部により算出された一致度に基づき、前記自動診断部による診断結果の利用に対する課金額を推定する課金額推定部と、
    課金額推定部により推定された課金額を表示装置の画面上に表示させると共に、前記画面上に表示された推定された課金額に対する修正入力に基づき、前記自動診断部による診断結果の利用に対する課金額を決定する課金額決定部と、を備えることを特徴とする保全管理システム。
  8. 請求項6に記載の保全管理システムにおいて、
    前記課金額推定部は、前記タスク実績分析部により算出された一致度及び前記自動診断結果ログ記憶部に記録された発報された警報に関する情報並びに保全作業に自動診断結果を用いることで得られる利益に基づき、前記自動診断部による診断結果の利用に対する課金額を推定することを特徴とする保全管理システム。
  9. 請求項7に記載の保全管理システムにおいて、
    前記課金額推定部は、前記タスク実績分析部により算出された一致度及び前記自動診断結果ログ記憶部に記録された発報された警報に関する情報並びに保全作業に自動診断結果を用いることで得られる利益に基づき、前記自動診断部による診断結果の利用に対する課金額を推定することを特徴とする保全管理システム。
  10. 診断対象アセット毎に少なくとも故障モードを格納する故障情報データベースと、診断対象アセットの故障モードを診断するための診断基準を格納する自動診断定義データベースと、予め故障モードに対応する保全方法を格納する保全方法データベースと、少なくとも自動診断部による診断結果及び発報された警報に関する情報を記録する自動診断結果ログ記憶部と、少なくとも前記診断対象アセットに施された保全作業内容を記録する保全作業ログ記憶部と、を備え、
    前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、保全作業に自動診断結果が用いられたことを検出するタスク実績分析部を有することを特徴とする保全管理確認装置。
  11. 請求項10に記載の保全管理確認装置において、
    前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容と、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法とを比較し、一致度を算出し、当該算出した一致度に基づいて保全作業に自動診断結果が用いられたことを検出することを特徴とする保全管理確認装置。
  12. 請求項11に記載の保全管理確認装置において、
    前記故障情報データベースは、診断対象アセットを構成する複数のコンポーネント間の階層関係を表すネットワークを格納し、
    前記タスク実績分析部は、前記保全作業ログ記憶部に記録された保全作業内容に対応するコンポーネントと、前記保全方法データベースに格納される前記自動診断部による診断結果の故障モードに対応する保全方法に対応するコンポーネントとのネットワーク上の距離に基づく減少関数を用いて前記一致度を算出することを特徴とする保全管理確認装置。
JP2018563204A 2017-01-19 2017-12-08 保全管理システム及びそれに用いる保全管理確認装置 Active JP6706693B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017007357 2017-01-19
JP2017007357 2017-01-19
PCT/JP2017/044117 WO2018135171A1 (ja) 2017-01-19 2017-12-08 保全管理システム及びそれに用いる保全管理確認装置

Publications (2)

Publication Number Publication Date
JPWO2018135171A1 true JPWO2018135171A1 (ja) 2019-11-07
JP6706693B2 JP6706693B2 (ja) 2020-06-10

Family

ID=62907953

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018563204A Active JP6706693B2 (ja) 2017-01-19 2017-12-08 保全管理システム及びそれに用いる保全管理確認装置

Country Status (3)

Country Link
US (1) US11221903B2 (ja)
JP (1) JP6706693B2 (ja)
WO (1) WO2018135171A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018110084A1 (de) * 2018-04-26 2019-10-31 Fibro Gmbh Diagnoseeinheit
TW202016743A (zh) * 2018-10-25 2020-05-01 財團法人資訊工業策進會 用於物聯網系統之資料處理裝置及資料處理方法
JP7270449B2 (ja) * 2019-04-23 2023-05-10 株式会社日立製作所 保全リコメンドシステム
US11635298B2 (en) * 2019-06-28 2023-04-25 Lyft, Inc. Systems and methods for routing decisions based on door usage data
JP7430040B2 (ja) * 2019-07-10 2024-02-09 株式会社日立製作所 故障箇所特定支援システム
JP2022127412A (ja) * 2021-02-19 2022-08-31 トヨタ自動車株式会社 情報処理システム、情報処理方法及びプログラム
CN114328147B (zh) * 2021-11-30 2023-12-29 浪潮(山东)计算机科技有限公司 一种测试异常处理方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002269265A (ja) * 2001-03-12 2002-09-20 Toshiba Corp コンピュータ点検申請受付用サーバ、コンピュータ点検サービスメニュー追加登録方法、設備保守申請受付用サーバ、設備保守申請受付方法、およびプログラム
JP2004020477A (ja) * 2002-06-19 2004-01-22 Hitachi Maxell Ltd 車両メンテナンスシステム
JP2008004091A (ja) * 2006-06-20 2008-01-10 Xerox Corp 一体化されたルールベース・システムを用いる自動修理分析
JP2012094044A (ja) * 2010-10-28 2012-05-17 Hitachi Ltd 異常診断装置および産業機械

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4531242B2 (ja) 2000-11-15 2010-08-25 東京瓦斯株式会社 故障診断システムにおける課金方法
US8074103B2 (en) * 2007-10-19 2011-12-06 Oracle International Corporation Data corruption diagnostic engine
US8504874B2 (en) * 2010-09-21 2013-08-06 Microsoft Corporation Repair-policy refinement in distributed systems
US9471452B2 (en) * 2014-12-01 2016-10-18 Uptake Technologies, Inc. Adaptive handling of operating data
US10339601B2 (en) * 2015-08-31 2019-07-02 The Toronto-Dominion Bank Connected device-triggered failure analysis

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002269265A (ja) * 2001-03-12 2002-09-20 Toshiba Corp コンピュータ点検申請受付用サーバ、コンピュータ点検サービスメニュー追加登録方法、設備保守申請受付用サーバ、設備保守申請受付方法、およびプログラム
JP2004020477A (ja) * 2002-06-19 2004-01-22 Hitachi Maxell Ltd 車両メンテナンスシステム
JP2008004091A (ja) * 2006-06-20 2008-01-10 Xerox Corp 一体化されたルールベース・システムを用いる自動修理分析
JP2012094044A (ja) * 2010-10-28 2012-05-17 Hitachi Ltd 異常診断装置および産業機械

Also Published As

Publication number Publication date
US11221903B2 (en) 2022-01-11
JP6706693B2 (ja) 2020-06-10
WO2018135171A1 (ja) 2018-07-26
US20190332462A1 (en) 2019-10-31

Similar Documents

Publication Publication Date Title
WO2018135171A1 (ja) 保全管理システム及びそれに用いる保全管理確認装置
US7496475B2 (en) Maintenance management of a machine
CN103617110B (zh) 服务器设备状态检修系统
Tsang et al. Data management for CBM optimization
Van Horenbeek et al. Quantifying the added value of an imperfectly performing condition monitoring system—Application to a wind turbine gearbox
JP2013092954A (ja) 管理業務支援装置、管理業務支援方法及び管理業務支援システム
JP2002123314A (ja) 設備保全の最適化システム
Shafiee et al. Development of a techno-economic framework for life extension decision making of safety critical installations
CN112651605A (zh) 设备监控与状态分析系统
Xing et al. Dynamic business continuity assessment using condition monitoring data
US20090089112A1 (en) Service Resource Evaluation Method and System
KR100564362B1 (ko) 도시철도차량 유지보수 정보화 예방정비 분석을 이용한예방 정비 시스템 및 방법
Tichý et al. Predictive diagnostics usage for telematic systems maintenance
Vicente Assessing the cost of unreliability in gas plant to have a sustainable operation
Dias et al. Productivity improvement of transmission electron microscopes-A case study
TWI380226B (en) System and method of prognostic analysis and resource planning for apparatu
US20240046224A1 (en) System and Method for Management of Remote Assets with Data Aggregation
Létourneau et al. A domain independent data mining methodology for prognostics
Tichy et al. Failure analysis and data-driven maintenance of road tunnel equipment
CN115883194A (zh) 汽车网络安全管理系统、汽车、管理方法及存储介质
JP5412252B2 (ja) 信頼性解析装置及び方法
CN109087013A (zh) 一种基于技术监督数据的设备诊断方法及系统
CN105656990A (zh) 一种仪表的监控方法及系统
Ning et al. Prognostics and health management's potential benefits to warranty
KR100682509B1 (ko) 도시철도차량 유지보수 정보화 응용시스템

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190521

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200421

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200518

R150 Certificate of patent or registration of utility model

Ref document number: 6706693

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150