JP2018022371A - メンテナンス方法、メンテナンスシステム及びプログラム - 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/ 〉

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

第１に、従来のセンシング手法が案件毎にワンオフである。言い換えると、機械や工場毎に、異なるセンサや設定、分析手法が必要である。ＶＥＣでは、故障を判断するためのルールや閾値の定義に難航している。さらに、環境、季節等の条件で適切な閾値が変化する現場状況に対応することも解決されていない。

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

第３に、メンテナンス自動化が不十分である。非特許文献２は、集約データの可視化が中心であり、分析結果に基づいた交換部品の手配等のリアルタイムなアクションに繋がっていない。

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

第１の本発明に係るメンテナンス方法は、機械のメンテナンスを手配するメンテナンス方法であって、マイクによる、前記機械の発する音を収集するステップと、分析装置による、前記マイクが収集した音データを分析して前記機械の異常を検知するステップと、前記分析装置による、前記機械の異常を検知した場合に、異常を検知したときの前記音データを含む異常検知情報をセンタ装置へ送信するステップと、前記センタ装置による、前記異常検知情報を受信した場合に、前記異常検知情報を用いて前記機械のメンテナンスの要否を判断するステップと、前記センタ装置による、前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信するステップと、を有することを特徴とする。

第２の本発明に係るメンテナンスシステムは、機械のメンテナンスを手配するメンテナンスシステムであって、前記機械の発する音を収集するマイクと分析装置とセンタ装置を備え、前記分析装置は、前記マイクが収集した音データを分析して前記機械の異常を検知する分析手段と、前記機械の異常を検知した場合に、異常を検知したときの前記音データを含む異常検知情報を前記センタ装置へ送信する送信手段と、を有し、前記センタ装置は、前記異常検知情報を受信した場合に、前記異常検知情報を用いて前記機械のメンテナンスの要否を判断する解析手段と、前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信する手配手段と、を有することを特徴とする。

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

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

本実施の形態におけるメンテナンスシステムの全体構成図である。 分析装置がメンテナンス対象機器の異常を検知した場合の動作を示すシーケンス図である。 オペレータにメンテナンス対象機器の異常を通知する画面の例を示す図である。

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

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

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

収集部１１は、マイク１５からメンテナンス対象機器５の発する音データを収集する。例えば、メンテナンス対象機器５のファンの近くにマイク１５を取り付けて、ファンの音を収集する。

分析部１２は、音データをストリーム処理で分析し、通常時とは異なる異常を検知する。ストリーム処理は、大量に発生するデータを逐次に時系列処理する技術であり、データ発生時に、あらかじめ登録したシナリオ（学習モデルなど）にしたがってデータを分析する。本実施の形態では、ストリームデータの逐次処理に適しているＪｕｂａｔｕｓ（S. Hido, S. Tokui, S. Oda, "Jubatus: An Open Source Platform for Distributed Online Machine Learning," NIPS 2013 Workshop on Big Learning, 2013）の学習モデルを用いて音の周波数データを分析し、異常が疑われる音データを抽出する。多くの機器は発する音の周波数が決まっている。音の周波数を分析することで、通常時とは異なる異常の検知ができる。例えば、分析部１２は、メンテナンス対象機器５のファンの音データを高速フーリエ変換して１００次元の周波数データを得て、その周波数データをストリーム処理で逐次分析し、異常の度合いを示すアノマリースコアを算出する。アノマリースコアが閾値以上の場合に異常と判断する。

Ｊｕｂａｔｕｓは、オンライン機械学習フレームワークである。Ｊｕｂａｔｕｓは、通常のデータ値と異なる場合を検知するアノマリー検知や分類のアルゴリズムが利用できる。アノマリー検知は、通常のデータからの外れ度が大きい場合に高いアノマリースコアを付けるアルゴリズムであり、ＶＥＣで必要な細かいルールや閾値の設定が不要である。分析装置１での処理は簡易なアノマリー検知や分類である。異常が疑われる音データの分析及び異常に対する対処はセンタ装置２が行うので、分析装置１として、例えばＲａｓｐｂｅｒｒｙ Ｐｉなどの小型コンピュータを用いることが可能であり、コストの低減が期待できる。

また、分析部１２は、異常が疑われる音データを分類し、類似する過去の故障時のグループのラベルを付与する。類似する過去の故障時の音データのグループが無い場合はラベルを付与しなくてもよい。

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

記憶部１４は、分析部１２が分析に用いる学習モデル、収集部１１が収集した音データ、メンテナンス対象機器５の識別情報などが記憶される。

マイク１５は、メンテナンス対象機器５の発する音を随時収集し、収集した音データを分析装置１へ送信する。分析装置１とマイク１５は、有線により通信可能に接続されてもよいし、Ｗｉ−Ｆｉ（登録商標）やＺｉｇＢｅｅ（登録商標）などの無線により通信可能に接続されてもよい。複数のマイク１５を配置してもよい。

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

通信部２１は、分析装置１との間でデータを送受信する。通信部２１は、分析装置１から受信した異常検知情報をインメモリＤＢ２６に登録するとともに、異常検知情報に含まれる異常が疑われる音データ（生データ）を記憶部２８に格納する。本実施の形態では、通信プロトコルとしてセンサ用軽量メッセージキュープロトコルであるＭＱＴＴを用い、通信部２１はＭＱＴＴ Ｂｒｏｋｅｒとして機能する。

統計解析部２２は、異常検知情報を用いて、メンテナンス対象機器５の故障箇所を予測する。具体的には、統計解析部２２は、異常検知情報に含まれる識別情報から故障が疑われるメンテナンス対象機器５を特定し、異常検知情報に含まれるアノマリースコア、ラベル、異常が疑われる音データから部品の交換が必要であるか否か、及び交換すべき部品を判定する。統計解析には、ＰＳＰＰ等の統計解析ソフトウェアを用いることができる。例えば、異常検知情報にラベルが含まれておらず、故障原因を特定できない場合は、オペレータに通知を行い、オペレータが人手で解析しても良い。オペレータが解析して得られたラベル等の解析結果は分析装置１に反映する。

メンテナンス制御部２３は、統計解析部２２の予測結果に基づいてメンテナンスの要否を判別する。メンテナンスが必要であると判別した場合、メンテナンス制御部２３は、発注データを生成し、インメモリＤＢ２６に登録する。発注データには、交換部品用の発注データと、メンテナンススタッフ用の発注データとがある。部品の交換が必要な場合は、交換部品用の発注データを生成する。メンテナンススタッフの対応が必要な場合は、メンテナンススタッフ用の発注データを生成する。メンテナンス制御部２３は、ＯｐｅｎＳｔａｃｋ、Ｃｌｏｕｄ Ｆｏｕｎｄｒｙなどのプラットフォームを利用して構成できる。

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

スタッフ管理部２５は、インメモリＤＢ２６に登録されたスタッフ用の発注データを読み出し、発注データを含むスタッフの手配要求を、メンテナンス事業者サーバ４へ送信する。

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

モデル更新部２７は、定期的に記憶部２８に格納された異常が疑われる音データを分析し、必要に応じて機械学習モデルを更新する。本実施の形態では、モデル更新部２７にＪｕｂａｔｕｓを用いる。更新された機械学習モデルは通信部２１によって分析装置１に配信される。これにより、分析装置１での分析の精度を高めることができる。

記憶部２８は、分析装置１から受信した異常検知情報に含まれる異常が疑われる音データを格納する。

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

メンテナンス事業者サーバ４は、メンテナンス対象機器５のメンテナンスを行う事業者が運営するサーバであり、メンテナンススタッフを管理する。メンテナンス事業者サーバ４は、センタ装置２からスタッフの手配要求を受信する。メンテナンス事業者は、メンテナンス事業者サーバ４が受信した手配要求に従ってスタッフを割り当てる。

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

図２は、メンテナンス対象機器の異常を検知した場合の動作を示すシーケンス図である。

分析装置１は、マイク１５が取得したメンテナンス対象機器５の発する音を収集する（ステップＳ１１）。

分析装置１は、音データをストリーム処理により分析する（ステップＳ１２）。

分析装置１は、音データの分析結果が異常を示す場合、異常が疑われる音データを含む異常検知情報をセンタ装置２へ送信する（ステップＳ１３）。異常検知情報はインメモリＤＢ２６に格納され、異常が疑われる音データは記憶部２８に格納される。

メンテナンス制御部２３は、異常検知情報の通知を受けると（ステップＳ１４）、統計解析部２２に故障予測を指示して、異常検知情報をより深く分析して故障箇所を予測する（ステップＳ１５）。

メンテナンス制御部２３は、統計解析部２２の故障予測結果に基づいてメンテナンスが必要であると判定した場合、交換部品を注文する発注データ、スタッフを手配する発注データを生成し、インメモリＤＢ２６に登録する（ステップＳ１６，Ｓ１７）部品用の発注データは、交換部品に関する情報（例えば、部品の識別情報など）を含む。スタッフ用の発注データは、メンテナンス箇所、メンテナンス内容など、適切なスタッフを手配するために必要なスタッフに関する情報を含む。

メンテナンス制御部２３がメンテナンス対象機器５のメンテナンスが必要であると判定し、発注データを生成したときに、オペレータに対してアラートを通知して、発注処理を進める了承を得てもよい。図３は、オペレータにアラートを通知する画面の例を示す図である。図３の例では、異常が検知されたメンテナンス対象機器５の場所が地図上で示され、異常の発生時刻、発生場所、メンテナンス対象機器５の名称、ステータス情報、及びメンテナンスボタンが表示される。オペレータがメンテナンスボタンをクリックすると、故障原因や故障部位の詳細が表示されるとともに、部品用の発注データ及びスタッフ用の発注データが表示される。オペレータがこれらの発注を了承するとステップＳ１８以降の処理が行われる。なお、メンテナンス制御部２３は、発注データを生成後に、オペレータからの了承を待たずに、ステップＳ１８以降の処理を続けてもよい。

メンテナンス制御部２３は、発注データをインメモリＤＢ２６に登録したことを通知する発注通知をＥＲＰ部２４及びスタッフ管理部２５へ送信する（ステップＳ１８，Ｓ１９）。

ＥＲＰ部２４は、インメモリＤＢ２６に登録された部品用の発注データを取得し、必要な部品を部品事業者に発注する（ステップＳ２０，Ｓ２１）。

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

また、スタッフ管理部２５は、インメモリＤＢ２６に登録されたスタッフ用の発注データを取得し、メンテナンスに必要なスタッフをメンテナンス事業者に発注する（ステップＳ２３，Ｓ２４）。

メンテナンス事業者は、発注された内容に適したスタッフを割り当て、スタッフを手配する（ステップＳ２５）。割り当てられたスタッフは、メンテナンス対象機器５の設置場所に向かい、メンテナンスを行う。

以上の処理により、分析装置１で検知された異常に基づいて、部品の発注及びスタッフの手配が行われる。

以上説明したように、本実施の形態によれば、マイク１５がメンテナンス対象機器５の発する音を収集し、分析装置１がマイク１５で収集した音データをストリーム処理によって周波数パワースペクトル分析し、異常の度合いを示すアノマリースコアを算出し、算出したアノマリースコアが閾値以上の場合に、異常を検知したときの音データを含む異常検知情報をセンタ装置２へ送信し、センタ装置２が受信した異常検知情報に基づいてメンテナンスの要否を判断し、メンテナンスが必要な場合に、交換部品の発注及びスタッフの手配を要求することにより、より簡易にメンテナンス対象機器５の異常を監視し、リアルタイムで故障傾向を検知し、必要な場合は迅速で的確なメンテナンスを実行することができる。また、メンテナンス対象機器５側では、異常の検知が行えればよいので、分析装置１を安価な機器で構成できる。さらに、メンテナンス対象機器５側でメンテナンス対象機器５の発する音を分析し、異常時のみ音データを送信するので、ネットワークコストの低減を図ることができる。

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

Claims (7)

1. 機械のメンテナンスを手配するメンテナンス方法であって、
   マイクによる、前記機械の発する音を収集するステップと、
   分析装置による、前記マイクが収集した音データを分析して前記機械の異常を検知するステップと、
   前記分析装置による、前記機械の異常を検知した場合に、異常を検知したときの前記音データを含む異常検知情報をセンタ装置へ送信するステップと、
   前記センタ装置による、前記異常検知情報を受信した場合に、前記異常検知情報を用いて前記機械のメンテナンスの要否を判断するステップと、
   前記センタ装置による、前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信するステップと、
   を有することを特徴とするメンテナンス方法。
2. 前記分析装置は前記機械の近傍に配置されており、
   前記機械の異常を検知するステップは、機械学習モデルを用いたストリーム処理により前記音データの周波数パワースペクトル分析を行って異常の度合いを示すアノマリースコアを算出し、前記アノマリースコアが閾値以上の場合に、前記機械に異常があると判断し、前記異常検知情報は前記アノマリースコアを含むことを特徴とする請求項１に記載のメンテナンス方法。
3. 前記機械の異常を検知するステップは、異常を検知したときに過去の異常時の音データに基づいて前記異常を検知したときの音データを分類して故障の種別を示すラベルを設定し、前記異常検知情報は前記ラベルを含むことを特徴とする請求項１又は２に記載のメンテナンス方法。
4. 機械のメンテナンスを手配するメンテナンスシステムであって、
   前記機械の発する音を収集するマイクと分析装置とセンタ装置を備え、
   前記分析装置は、
   前記マイクが収集した音データを分析して前記機械の異常を検知する分析手段と、
   前記機械の異常を検知した場合に、異常を検知したときの前記音データを含む異常検知情報を前記センタ装置へ送信する送信手段と、を有し、
   前記センタ装置は、
   前記異常検知情報を受信した場合に、前記異常検知情報を用いて前記機械のメンテナンスの要否を判断する解析手段と、
   前記機械のメンテナンスが必要な場合に、当該メンテナンスに必要なリソースを手配する要求を送信する手配手段と、
   を有することを特徴とするメンテナンスシステム。
5. 前記分析装置は前記機械の近傍に配置されており、
   前記分析手段は、機械学習モデルを用いたストリーム処理により前記音データの周波数パワースペクトル分析を行って異常の度合いを示すアノマリースコアを算出し、前記アノマリースコアが閾値以上の場合に、前記機械に異常があると判断し、前記異常検知情報は前記アノマリースコアを含むことを特徴とする請求項４に記載のメンテナンスシステム。
6. 前記分析手段は、異常を検知したときに過去の異常時の音データに基づいて前記異常を検知したときの音データを分類して故障の種別を示すラベルを設定し、前記異常検知情報は前記ラベルを含むことを特徴とする請求項４又は５に記載のメンテナンスシステム。
7. 請求項４乃至６のいずれかに記載のメンテナンスシステムの分析装置又はセンタ装置としてコンピュータを動作させることを特徴とするプログラム。

Images