JP2018022372A - メンテナンス方法、メンテナンスシステム及びプログラム - Google Patents

Abstract

【課題】コストが低くより精度が高い方法で機械の異常を検知し、機械の迅速なメンテナンスを可能とする。【解決手段】分析装置１がストリーム処理によって異常が疑われるデータを検知し、異常検知情報をセンタ装置２へ送信し、センタ装置２は異常疑いルールと異常検知情報に基づいて故障予測を行い、交換部品を発注する発注データを生成する。これにより、リアルタイムで故障傾向を検知し、迅速なメンテナンスが可能となる。また、センタ装置２が分析装置１の収集した全センシングデータを取得し、全センシングデータを用いて詳細に分析して故障予測を行うことで、より精度を高く故障予測を行うことが可能となる。【選択図】図２

Description

本発明は、機械のメンテナンスを行う技術に関する。

近年、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）の技術が進展している。ＩｏＴの適用範囲は多岐に渡るが、その中でも、製造分野及びメンテナンス分野が適用先として有力視されている。工場、機械、製品等の情報をセンサにより収集、分析することで、それらの状態を可視化し、生産把握、計画反映、物流制御、不良物品交換等のサプライチェーンの自動化、ビジネスの加速が期待されている。

ＩｏＴデータを用いたＩｏＴアプリケーションを開発、運営するためのＩｏＴプラットフォームも存在する。

非特許文献１のＡＷＳ ＩｏＴ プラットフォームは、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅの各種機能をＩｏＴで統合利用可能にするプラットフォームである。例えば、Ａｍａｚｏｎ Ｋｉｎｅｓｉｓを用いて、ＭＱＴＴ（Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ）プロトコルでデータを収集し、収集したデータをＡｍａｚｏｎ Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇの機械学習機能により回帰やクラス分類の多彩な分析等が可能である。

ＮＴＴドコモとＧＥ社は、ＧＥの産業用機器向けワイヤレスルーターＯｒｂｉｔと、ＮＴＴドコモの通信モジュールを連携させたＩｏＴソリューションを発表している（非特許文献２）。企業は、遠隔地の設備にＮＴＴドコモの通信モジュールを内蔵したＯｒｂｉｔを設置することで、設備の稼働データを収集することができる。さらに、ＮＴＴドコモが提供するＴｏａｍｉ上でＩｏＴアプリケーションを開発可能であり、取得データの可視化等を容易にしている。

製造業の取り組みとしては、ＧＥ社を中心としたＩｎｄｕｓｔｒｉａｌ Ｉｎｔｅｒｎｅｔ、ドイツ政府のＩｎｄｕｓｔｒｙ ４．０が著名である。これらの取り組みでは、センシング系技術で収集したデータを分析系ソフトウェアで事前に定義したルールに基づき流通手配に繋げることが議論されている。

日本では、製造のソリューション普及活動を行っている団体としてＶＥＣ（Ｖｉｒｔｕａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｍｍｕｎｉｔｙ）があり、ＩｏＴの適用が盛んに議論されている（非特許文献３）。ＶＥＣでは、製造やビル等の機器の故障をセンシングデータから、事前に定義されたルールや閾値により、自動で検出することを目指しており、復旧サポートや現場への改善提案への利用が検討されている。

"ＡＷＳ ＩｏＴ プラットフォームの仕組み"、[online], 2016, Amazon Web Service, Inc., インターネット〈 URL：https://aws.amazon.com/jp/iot/how-it-works/?nc1=h_ls 〉 "GE and NTT DOCOMO Sign MoU Toward Business Alliance to Provide Industrial Equipment for IoT Solutions", [online], July 8, 2015, NTT DOCOMO, INC., インターネット〈 URL：https://www.nttdocomo.co.jp/english/info/media_center/pr/2015/0708_00.html 〉 "Virtual Engineering Community", [online], Virtual Engineering Community, インターネット〈 URL：https://www.vec-community.com/en/ 〉

しかしながら、従来の技術をメンテナンスに利用する際には、以下に示す３つの課題があると考える。

第１に、現場状況をリアルタイムに分析できていないという問題があった。非特許文献１は、集約データのバッチ処理による可視化が中心であり、リアルタイムな分析に基づく部品手配などの迅速なアクションには繋がっていない。

第２に、センシングデータ収集のコストが高いという問題があった。ＡＷＳ ＩｏＴでは分析のために全データをクラウドに集めるが、多くの機械のセンシングデータを各地から収集するためのネットワークが必要である。例えば、ＩｏＴによるメンテナンス事例として、移動機械のデータ収集に衛星通信を使う例があるが、コストが大きく、さらに、全てのデータを送らずにデータを間引いて送信している。

第３に、故障検知のためのルール設定のコストが高いという問題があった。様々なセンシングデータから故障を検知するために、分析アプリケーション側でルールや閾値を設定し判定することが主流である。例えば、ＰＳＰＰ等の統計解析ソフトウェアを用いて、その判定ルールを抽出する方法があるが、ルールや閾値の抽出、設定は高度な知識が必要であり、その設定コストは高い。

本発明は、上記に鑑みてなされたものであり、コストが低くより精度が高い方法で機械の異常を検知し、機械の迅速なメンテナンスを可能とすることを目的とする。

第１の本発明に係るメンテナンス方法は、機械のメンテナンスを手配するメンテナンス方法であって、分析装置による、前記機械に取り付けられたセンサが取得したセンシングデータを収集するステップと、前記分析装置による、前記センシングデータを学習モデルを用いたストリーム処理で分析し、異常の度合いを示すアノマリースコアを算出するステップと、前記分析装置による、前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータを含む異常検知情報をセンタ装置へ送信するステップと、前記センタ装置による、前記異常検知情報を受信した場合に、異常な事象を検出するための異常疑いルールと前記異常検知情報を用いて前記機械のメンテナンスの要否を判断するステップと、前記センタ装置による、前記分析装置が収集したセンシングデータを記憶手段に格納するステップと、前記センタ装置による、所定のタイミングで、前記記憶手段に格納された前記センシングデータを分析して前記機械のメンテナンスの要否を判断するステップと、前記センタ装置による、前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信するステップと、を有することを特徴とする。

第２の本発明に係るメンテナンスシステムは、機械のメンテナンスを手配するメンテナンスシステムであって、前記機械に取り付けられたセンサと分析装置とセンタ装置を備え、前記分析装置は、前記センサが取得したセンシングデータを収集する収集手段と、前記センシングデータを学習モデルを用いたストリーム処理で分析し、異常の度合いを示すアノマリースコアを算出する分析手段と、前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータを含む異常検知情報をセンタ装置へ送信する送信手段と、を有し、前記センタ装置は、前記異常検知情報を受信した場合に、異常な事象を検出するための異常疑いルールと前記異常検知情報を用いて前記機械のメンテナンスの要否を判断する第１解析手段と、前記分析装置が収集したセンシングデータを蓄積する記憶手段と、所定のタイミングで、前記記憶手段に格納された前記センシングデータを分析して前記機械のメンテナンスの要否を判断する第２解析手段と、前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信する手配手段と、を有することを特徴とする。

第３の本発明に係るプログラムは、上記メンテナンスシステムの分析装置又はセンタ装置としてコンピュータを動作させることを特徴とする。

本発明によれば、コストが低くより精度が高い方法で機械の異常を検知し、機械の迅速なメンテナンスを可能とすることができる。

ラムダアーキテクチャを適用したメンテナンスプラットフォームの概要を示す図である。 本実施の形態におけるメンテナンスの全体構成図である。 本実施の形態におけるメンテナンスシステムのスピードレイヤーでの異常検知処理の流れを示すシーケンス図である。 本実施の形態におけるメンテナンスシステムのバッチレイヤーでの学習モデルの更新処理の流れを示すフローチャートである。

以下、図面を参照して本発明の実施の形態について説明する。

本実施の形態では、ラムダアーキテクチャのコンセプトを用いたメンテナンスプラットフォームを提案する。ラムダアーキテクチャは、スピードレイヤー及びバッチレイヤーの両方で分析した分析結果をユーザに提供することで、細やかな分析結果と速報性の必要な分析結果を実現するアーキテクチャである（N. Marz and J. Warren, "Big Data: Principles and best practices of scalable realtime data systems," Manning Publications Co., 2015）。

図１は、ラムダアーキテクチャを適用したメンテナンスプラットフォームの概要を示す図である。図１に示すメンテナンスプラットフォームは、スピードレイヤーとバッチレイヤーに分けられる。スピードレイヤーは、メンテナンス対象の機器が設置されたエッジ側にリアルタイム分析機能を持ち、クラウド側にＣＥＰ（Ｃｏｍｐｌｅｘ Ｅｖｅｎｔ Ｐｒｏｃｅｓｓｉｎｇ）機能を持つ。バッチレイヤーは、エッジ側にローカルストレージを持ち、クラウド側にデータベースを持つ。メンテナンスプラットフォームは、スピードレイヤーとバッチレイヤーのそれぞれの機能を利用してメンテナンスを行うメンテナンス機能を持つ。

メンテナンス対象の機器に取り付けられたセンサで収集されたセンシングデータは、スピードレイヤーのリアルタイム分析機能とバッチレイヤーのローカルストレージに送信される（ステップＳ１１）。

スピードレイヤーでは、エッジ側のリアルタイム分析機能が、センシングデータをストリーム処理し、異常が疑われるデータを検知した場合は、クラウド側のＣＥＰ機能にそのデータを送信する（ステップＳ１２）。ＣＥＰ機能は、エッジ側から受信した異常が疑われるデータをメンテナンス機能に送信する（ステップＳ１３）。メンテナンス機能は、異常疑いルール及び異常が疑われるデータを用いて故障予測等の分析をして、必要に応じて外部システム（ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）等）と連携する（ステップＳ１４）。外部システムによってメンテナンスに必要なリソースが手配されて機器のメンテナンスが行われる。

また、リアルタイム分析機能は、機械学習を通じて現場状況に応じたルールや閾値（異常疑いルール）を抽出してメンテナンス機能に送信する（ステップＳ１５）。メンテナンス機能は、定期的に、受信した異常疑いルールをマージして、メンテナンス機能側の異常疑いルールをより改善する。

バッチレイヤーでは、ローカルストレージに蓄積されたセンシングデータが、夜間等のコストが安い時間に、クラウド側のデータベースに送信される（ステップＳ１６）。メンテナンス機能は、データベースに蓄積された全データを用いて、スピードレイヤーでは対象外の詳細な分析を行う（ステップＳ１７）。さらに、分析者が、定期的にデータベースに蓄積されたデータを分析し、より精度の高い機械学習モデルを抽出する（ステップＳ１８）。機械学習モデルは、エッジ側のリアルタイム分析機能に配信される（ステップＳ１９）。

このように、本実施の形態では、リアルタイム分析機能のストリーム処理によって異常が疑われるデータを検知し、交換部品発注等の即時のアクションに繋げることができる。また、本実施の形態では、バッチレイヤーで、全センシングデータを用いて詳細な分析を行うことで、リアルタイム分析機能で誤ってフィルタリングしてしまった故障を検知することができる。

さらに、リアルタイム分析機能が機械学習により現場環境に応じたルールや閾値を抽出し、クラウド側へ送信し、メンテナンス機能に反映するので、ルールや閾値を設定するための技術者の稼働を低減でき、クラウド側の分析精度を向上することが可能となる。また、メンテナンス機能が全センシングデータを用いて学習モデルを更新し、エッジ側へ送信し、リアルタイム分析機能に反映するので、エッジ側の分析精度を向上することが可能となる。

次に、本実施の形態におけるメンテナンスシステムについて説明する。

図２は、本実施の形態におけるメンテナンスの全体構成図である。図２に示すメンテナンスシステムは、エッジ側の分析装置１、メンテナンス対象機器５に取り付けられたセンサ１５、及びクラウド側のセンタ装置２を備える。分析装置１とセンタ装置２は、セキュアなＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を介して接続される。センタ装置２は、部品事業者サーバ３と通信可能に接続される。以下、分析装置１及びセンタ装置２について説明する。

分析装置１は、収集部１１、分析部１２、送信部１３、及び記憶部１４を備える。分析装置１が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムは分析装置１が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。

収集部１１は、センサ１５からメンテナンス対象機器５のセンシングデータ収集する。

分析部１２は、センシングデータをストリーム処理で分析し、通常時とは異なる異常を検知する。より具体的には、分析部１２は、センシングデータをストリーム処理で逐次分析して異常の度合いを示すアノマリースコアを算出し、アノマリースコアが閾値以上の場合に異常と判断する。また、分析部１２は、異常が疑われるデータと過去の故障時のデータとを照合し、類似する過去の故障時のグループ（事例）のラベルを付与する。過去に類似するセンシングデータのグループが無い場合は、当該事象を検出するための新たな異常疑いルールを抽出する。ラベルは、故障の種別を示すものである。

ストリーム処理は、大量に発生するデータを逐次に時系列処理する技術であり、データ発生時に、あらかじめ登録したシナリオ（学習モデルなど）にしたがってデータを分析する。本実施の形態では、ストリームデータの逐次処理に適しているＪｕｂａｔｕｓ（S. Hido, S. Tokui, S. Oda, "Jubatus: An Open Source Platform for Distributed Online Machine Learning," NIPS 2013 Workshop on Big Learning, 2013）の学習モデルを用いてセンシングデータを分析し、異常が疑われるデータを抽出する。Ｊｕｂａｔｕｓは、オンライン機械学習フレームワークであり、通常のデータ値と異なる場合を検知するアノマリー検知や分類のアルゴリズムが利用できる。アノマリー検知は、センシングデータの多次元空間上で、通常のデータからの外れ度が大きい場合に高いアノマリースコアを付けるアルゴリズムである。ＶＥＣで必要な細かいルールや閾値の設定が不要である。例えば、ＬＯＦ（Ｌｏｃａｌ Ｏｕｔｌｉｅｒ Ｆａｃｔｏｒ）等のアノマリー検知アルゴリズムを用いることができる（Markus M. Breunig, Hans-Peter Kriegel, Raymond T. Ng, and Jorg Sander, "LOF: Identifying Density-based Local Outliers," Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data (SIGMOD), pp.93-104, 2000）。

送信部１３は、分析部１２が異常を検知したときに、異常検知情報をセンタ装置２へ送信する。異常検知情報は、例えば、アノマリースコア、異常が疑われるデータ、ラベル、及びメンテナンス対象機器５の識別情報を含む。また、送信部１３は、分析部１２が抽出した異常疑いルールをセンタ装置２へ送信する。

記憶部１４は、分析部１２が分析に用いる学習モデル、収集部１１が収集したセンシングデータ、及びメンテナンス対象機器５の識別情報などが記憶される。記憶部１４に蓄積されたセンシングデータは、夜間や物理的輸送などの低コストな手段でセンタ装置２に移される。

センサ１５は、メンテナンス対象機器５に取り付けられて、収集したセンシングデータを分析装置１へ送信する。分析装置１とセンサ１５は、有線により通信可能に接続されてもよいし、Ｗｉ−Ｆｉ（登録商標）やＺｉｇＢｅｅ（登録商標）などの無線により通信可能に接続されてもよい。各種の複数のセンサ１５をメンテナンス対象機器５に取り付けてもよい。

センタ装置２は、イベント処理部２１、統計解析部２２、メンテナンス制御部２３、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）部２４、データベース２５、通信部２６、モデル更新部２７、及び記憶部２８を備える。センタ装置２が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムはセンタ装置２が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。センタ装置２をクラウドサービスを利用して構成してもよい。

まず、スピードレイヤーで用いられる各部について説明する。

イベント処理部２１は、分析装置１から異常検知情報を受信し、異常検知情報をメンテナンス制御部２３に受け渡すとともに、データベース２５に異常検知情報を格納する。また、分析装置１から新たな異常疑いルールを受信したときは、データベース２５に格納された異常疑いルールにマージする。

統計解析部２２は、メンテナンス制御部２３の指示により、異常疑いルール及び異常検知情報を用いてメンテナンス対象機器５の故障を予測する。具体的には、統計解析部２２は、異常検知情報に含まれる識別情報から故障が疑われるメンテナンス対象機器５を特定し、異常疑いルール及び異常検知情報に含まれるアノマリースコア、ラベル、異常が疑われるデータから部品の交換が必要であるか否か、及び交換すべき部品を判定する。統計解析には、ＰＳＰＰ等の統計解析ソフトウェアを用いることができる。

メンテナンス制御部２３は、異常検知情報を受信すると統計解析部２２に故障箇所の予測を指示し、統計解析部２２の予測結果に基づいてメンテナンスの要否を判別し、メンテナンスが必要なときは発注データを生成する。メンテナンスが必要であると判別した場合、メンテナンス制御部２３は、発注データを生成し、データベース２５に登録する。例えば部品の交換が必要な場合は、交換部品用の発注データを生成する。メンテナンス制御部２３は、ＯｐｅｎＳｔａｃｋ、Ｃｌｏｕｄ Ｆｏｕｎｄｒｙなどのプラットフォームを利用して構成できる。

ＥＲＰ部２４は、データベース２５に登録された交換部品用の発注データを読み出し、発注データを含む発注要求を部品事業者サーバ３へ送信する。なお、基幹系部品管理システムを介して交換部品の在庫を確認し、在庫が無い場合に部品事業者サーバ３へ発注要求を送信してもよい。

データベース２５は、統計解析部２２、メンテナンス制御部２３、及びＥＲＰ部２４から参照可能なデータベースであり、異常検知情報、異常疑いルール、交換部品用の発注データ、及び学習モデルなどを格納する。複数のシステム連携に関して、ＩｏＴ等での可視化アプリケーションは情報系と呼ばれ、勘定・発注等の基幹系システムとデータベースが別であり、情報系と基幹系のデータのやり取りはデータベースの性能ネックのためバッチ処理が基本である。本実施の形態では、ＩｏＴのデータ分析結果を即時に基幹系（ＥＲＰ部２４）の発注等に反映するために、情報系と基幹系でデータベースを統合して双方から参照可能に、高速のインメモリＤＢ（ＶｏｌｔＤＢ等）を用いて構築する。データベース２５を介することで、発注データ等を処理するＥＲＰ部２４にも、メンテナンス制御部２３のＩｏＴデータ分析結果を即時に流通させることができる。なお、データベース２５は、物理サーバとしてセンタ装置２の外部に配置してもよい。

図２には図示していないが、センタ装置２は、メンテナンススタッフを手配する基幹系のシステムに対してスタッフの確保を要求するスタッフ管理手段を備えてもよい。この場合、交換部品の発注と同様に、メンテナンス制御部２３がスタッフ用発注データをデータベース２５に登録し、スタッフ管理手段がスタッフ用発注データを参照して外部のメンテナンス事業者にスタッフの確保を要求する。

続いて、バッチレイヤーで用いられる各部について説明する。

メンテナンス制御部２３は、統計解析部２２に指示して、記憶部２８に格納された全センシングデータを用いて故障箇所を予測する。全センシングデータを用いた故障箇所の予測は、速報性は不要であるが、詳細な故障予測を行いたい場合に行う。例えば、定期的に行ってもよいし、オペレータからの指示により行ってもよい。全センシングデータを用いた故障予測の結果、故障の発生が予測される場合、メンテナンス制御部２３は、メンテナンスの要否を判別し、メンテナンスが必要なときは発注データを生成する。

通信部２６は、分析装置１との間で、即座に対応する必要の無いデータを送受信する。例えば、通信部２６は、分析装置１の記憶部１４に蓄積された全センシングデータを受信して記憶部２８に格納する。あるいは、通信部２６は、モデル更新部２７によって更新された学習モデルを分析装置１へ送信する。通信部２６は通信プロトコルとしてＭＱＴＴを用いてもよいし、ＨＴＴＰを用いてもよい。

モデル更新部２７は、記憶部２８に格納された全センシングデータを用いて、より精度の高い検知ができるように学習モデルを更新する。本実施の形態では、モデル更新部２７にＪｕｂａｔｕｓを用いる。更新された学習モデルは通信部２６によって分析装置１に配信される。

記憶部２８は、分析装置１が収集した全センシングデータを蓄積する。記憶部２８が蓄積する全センシングデータは、通信部２６が分析装置１から受信してもよいし、物理的な記録媒体から取得してもよい。

部品事業者サーバ３は、メンテナンス対象機器５の各種部品を供給する部品事業者が運営するサーバである。部品事業者サーバ３は、センタ装置２から部品の発注要求を受信する。部品事業者は、部品事業者サーバ３が受信した発注要求に従って部品を用意して指定の場所に配送する。

次に、本実施の形態におけるメンテナンスシステムのスピードレイヤーでの異常検知処理について説明する。

図３は、本実施の形態におけるメンテナンスシステムのスピードレイヤーでの異常検知処理の流れを示すシーケンス図である。

分析装置１は、各センサ１５が出力するセンシングデータを収集する（ステップＳ２１）。収集したセンシングデータは、分析装置１が備える記憶部１４に蓄積される。

分析装置１は、収集したセンシングデータをストリーム処理により分析する（ステップＳ２２）。

分析装置１は、センシングデータの分析結果が異常を示す場合、アノマリースコア、ラベル、異常が疑われるデータを含む異常検知情報をセンタ装置２へ送信する（ステップＳ２３）。分析装置１は、収集したセンシングデータを過去に発生した異常時のセンシングデータと比較して分類を行い、過去の最も類似するグループのラベルを異常検知情報に含める。

イベント処理部２１は、受信した異常検知情報をデータベース２５に格納するとともに、異常検知情報をメンテナンス制御部２３に送信する（ステップＳ２４）。

メンテナンス制御部２３は、統計解析部２２に故障予測を指示し、異常疑いルール及び異常検知情報を用いてメンテナンス対象機器５の故障を予測する（ステップＳ２５）。

メンテナンス制御部２３は、統計解析部２２の故障予測結果に基づいてメンテナンスが必要であると判定した場合、交換部品を注文する発注データを生成し、データベース２５に登録する（ステップＳ２６）。発注データは、交換部品に関する情報（例えば、部品の識別情報など）を含む。

メンテナンス制御部２３は、発注データをデータベース２５に登録したことを通知する発注通知をＥＲＰ部２４へ送信する（ステップＳ２７）。メンテナンス制御部２３はオペレータに対してアラートを通知し、発注処理を進める了承を得た後に、発注通知を送信してもよい。

ＥＲＰ部２４は、データベース２５に登録された発注データを取得し、必要な部品を部品事業者に発注する（ステップＳ２８）。

部品事業者は、発注された部品を準備してメンテナンス対象機器５の設置場所または指定された場所に配送する（ステップＳ２９）。

以上のスピードレイヤーでの処理により、分析装置１で検知された異常に基づいて、部品の発注が迅速に行われる。

なお、ステップＳ２３において分析装置１が異常を検知し、検知した異常が過去の事象とは異なる場合、分析装置１は当該事象を検出するための新たな異常疑いルールを抽出し、異常疑いルールをセンタ装置２へ送信する。センタ装置２は、定期的に、抽出された異常疑いルールをセンタ装置２が保持する異常疑いルールにマージする。

バッチレイヤーでは、メンテナンス制御部２３は、所定のタイミングで、記憶部２８に格納された全センシングデータを用いて、スピードレイヤーでは対象外の詳細な分析を行って故障箇所を予測する。

次に、本実施の形態におけるメンテナンスシステムのバッチレイヤーでの学習モデルの更新処理について説明する。

図４は、本実施の形態におけるメンテナンスシステムのバッチレイヤーでの学習モデルの更新処理の流れを示すフローチャートである。

分析装置１は、各センサ１５が出力するセンシングデータを収集し、記憶部１４に蓄積する（ステップＳ３１）。記憶部１４には、センサ１５が出力した全てのセンシングデータが蓄積される。

記憶部１４に蓄積されたセンシングデータは、センタ装置２の記憶部２８に送信される（ステップＳ３２）。

モデル更新部２７は、記憶部２８に蓄積された全センシングデータを分析し、より精度の高い検知ができるように学習モデルを更新する（ステップＳ３３）。

通信部２６は、モデル更新部２７が更新した学習モデルを分析装置１へ配信する（ステップＳ３４）。分析装置１は分析部１２で用いる学習モデルを更新する。

以上説明したように、本実施の形態によれば、分析装置１がストリーム処理によって異常が疑われるデータを検知し、異常検知情報をセンタ装置２へ送信し、センタ装置２は異常疑いルールと異常検知情報に基づいて故障予測を行い、交換部品を発注する発注データを生成することにより、リアルタイムで故障傾向を検知し、迅速なメンテナンスが可能となる。また、センタ装置２が分析装置１の収集した全センシングデータを取得し、全センシングデータを用いて詳細に分析して故障予測を行うことで、より精度を高く故障予測を行うことが可能となる。

本実施の形態によれば、分析装置１が異常が疑われるデータを学習に用いて、新たな異常疑いルールを抽出してセンタ装置２へ送信し、センタ装置２が全センシングデータを用いて学習モデルを更新して分析装置１へ送信することにより、エッジ側とクラウド側の分析精度を向上することが可能となる。

１…分析装置
１１…収集部
１２…分析部
１３…送信部
１４…記憶部
１５…センサ
２…センタ装置
２１…イベント処理部
２２…統計解析部
２３…メンテナンス制御部
２４…ＥＲＰ部
２５…データベース
２６…通信部
２７…モデル更新部
２８…記憶部
３…部品事業者サーバ
５…メンテナンス対象機器

Claims (7)

1. 機械のメンテナンスを手配するメンテナンス方法であって、
   分析装置による、前記機械に取り付けられたセンサが取得したセンシングデータを収集するステップと、
   前記分析装置による、前記センシングデータを学習モデルを用いたストリーム処理で分析し、異常の度合いを示すアノマリースコアを算出するステップと、
   前記分析装置による、前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータを含む異常検知情報をセンタ装置へ送信するステップと、
   前記センタ装置による、前記異常検知情報を受信した場合に、異常な事象を検出するための異常疑いルールと前記異常検知情報を用いて前記機械のメンテナンスの要否を判断するステップと、
   前記センタ装置による、前記分析装置が収集したセンシングデータを記憶手段に格納するステップと、
   前記センタ装置による、所定のタイミングで、前記記憶手段に格納された前記センシングデータを分析して前記機械のメンテナンスの要否を判断するステップと、
   前記センタ装置による、前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信するステップと、
   を有することを特徴とするメンテナンス方法。
2. 前記分析装置による、前記アノマリースコアが閾値以上の場合に前記センシングデータを分類し、分類結果が過去の事象に当てはまらない場合、当該事象を検出するための異常疑いルールを抽出して前記センタ装置へ送信するステップを有することを特徴とする請求項１に記載のメンテナンス方法。
3. 前記センタ装置による、前記記憶手段に格納された前記センシングデータを用いて前記学習モデルを更新し、当該学習モデルを前記分析装置へ配信するステップを有することを特徴とする請求項１又は２に記載のメンテナンス方法。
4. 機械のメンテナンスを手配するメンテナンスシステムであって、
   前記機械に取り付けられたセンサと分析装置とセンタ装置を備え、
   前記分析装置は、
   前記センサが取得したセンシングデータを収集する収集手段と、
   前記センシングデータを学習モデルを用いたストリーム処理で分析し、異常の度合いを示すアノマリースコアを算出する分析手段と、
   前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータを含む異常検知情報をセンタ装置へ送信する送信手段と、を有し、
   前記センタ装置は、
   前記異常検知情報を受信した場合に、異常な事象を検出するための異常疑いルールと前記異常検知情報を用いて前記機械のメンテナンスの要否を判断する第１解析手段と、
   前記分析装置が収集したセンシングデータを蓄積する記憶手段と、
   所定のタイミングで、前記記憶手段に格納された前記センシングデータを分析して前記機械のメンテナンスの要否を判断する第２解析手段と、
   前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信する手配手段と、
   を有することを特徴とするメンテナンスシステム。
5. 前記分析装置は、前記アノマリースコアが閾値以上の場合に前記センシングデータを分類し、分類結果が過去の事象に当てはまらない場合、当該事象を検出するための異常疑いルールを抽出して前記センタ装置へ送信するルール抽出手段を有することを特徴とする請求項４に記載のメンテナンスシステム。
6. 前記センタ装置は、前記記憶手段に格納された前記センシングデータを用いて前記学習モデルを更新し、当該学習モデルを前記分析装置へ配信する学習モデル更新手段を有することを特徴とする請求項４又は５に記載のメンテナンスシステム。
7. 請求項４乃至６のいずれかに記載のメンテナンスシステムの分析装置又はセンタ装置としてコンピュータを動作させることを特徴とするプログラム。

Images