JP2017142654A - メンテナンス方法、メンテナンスシステム、および、メンテナンスプログラム - Google Patents

Abstract

【課題】機械の動作中にリアルタイムに異常を検知し、機器の迅速なメンテナンスを可能とする。【解決手段】分析装置１１が、機械１の動作中においてセンサ１２からセンシングデータを収集する収集ステップと、センシングデータを、ストリーム処理で分析し、異常の度合を示すアノマリースコアを算出する分析ステップと、アノマリースコアが閾値以上の場合に、アノマリースコアとセンシングデータとを含む異常検知情報をセンタ装置２に送信する送信ステップとを行い、センタ装置２は、受信した異常検知情報を用いて機械１のメンテナンスの要否を判別する判別ステップと、メンテナンスが必要であると判別した場合、交換部品の発注要求を部品事業者サーバ３に送信するとともに、メンテナンスを行うスタッフの手配要求をメンテナンス事業者サーバ４に送信する要求送信ステップとを行う。【選択図】図１

Description

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

近年、IoT（Internet of Things）の技術が進展しており、適用事例が増えている。IoTとは、世の中に存在する様々な物体に通信機能を持たせ、ネットワークに接続し、データを処理分析することで、自動認識や自動制御等を行うためのテクノロジーである。IoTの適用範囲は多岐に渡り、医療、交通、スマートシティ、農業、スポーツ、製造、メンテナンス等が検討されている。その中でも、ドイツのIndustry 4.0構想で進められている、製造やメンテナンスが適用先として有力視されている。

IoT技術を用いて、機械などセンシングデータを収集し、収集したセンシングデータから故障を予測する技術として、非特許文献１から４の技術がある。

Amazon Kinesis website, https://aws.amazon.com/kinesis/ Amazon Machine Learning website, https://aws.amazon.com/machine-learning/ NTT Docomo press release website, https://www.nttdocomo.co.jp/english/info/media_center/pr/2015/0708_00.html Virtual Engineering Community website, https://www.vec-community.com/en/

しかしながら、上述の非特許文献には以下のような問題がある。

すなわち、非特許文献１では、IoTデータは基本的にはインターネット等の広域網を介して送信されるため、膨大なセンシングデータをクラウド側に送信するためのネットワークコストが高い。

また、多地点から収集されたセンシングデータを分析する処理は、非特許文献２を用いてクラウド上で行われるが、Hadoop等を用いたバッチでの分析処理が中心であるため、機械の動作中のリアルタイムなセンシングデータから異常を発見し、対処することは考慮されていない。

また、非特許文献３では、Orbit（産業用機器向けワイヤレスルータのプラットフォーム）の堅牢さが特徴の一つであり、セキュアなデータ収集を可能としているが、連携されるIoTアプリケーションは、Toami （IoTクラウドプラットフォーム）を用いた、集約データを可視化するアプリケーションであり、分析結果に基づいたリアルタイムな対応は想定されていない。

また、非特許文献４は、製造やビル等の機器故障をセンシングデータから、事前に定義されたルールや閾値により、自動で検出することを目指している。しかしながら、非特許文献４では、そのルールや閾値の定義に難航しており、更に環境、季節等の条件で適切な閾値が変わる現場状況に対応することは困難であるため、リアルタイムに機器等の異常を自動検知するには至っていない。

例えば、航空機などの輸送機械は、精密機械の一つであり、安全な運行のため、多くの部品の正常性が定期的にチェックされる仕組みを備えている。例えば、航空機は、航空中の安全性を保つために、エンジン稼働状態等様々なデータがセンシングされ、１回のフライトでセンシングデータは数TBに及ぶ。しかし、そのデータは、重大な支障発生のイベント以外は、殆ど無視され捨てられているのが現状であって、使われるとしても何か問題が生じた際に後からバッチ処理で分析される程度である。その結果、重大な飛行事故には繋がらなくても、航空機到着後の整備時に不具合が発見され、統計として1000便に2-3便は、航空機が大幅な遅延、欠便となり、乗客の不便や代替機手配のコスト増加につながっている。

本発明は上記課題に鑑みてなされたものであって、本発明の目的は、機械の動作中にリアルタイムに異常を検知し、機器の迅速なメンテナンスを可能とする技術を提供することにある。

上記目的を達成するため、本発明は、機械のメンテナンスを行うメンテナンス方法であって、前記機械に設置された分析装置が、前記機械の動作中において、少なくとも１つのセンサからセンシングデータを収集する収集ステップと、前記センシングデータを、ストリーム処理で分析し、異常の度合を示すアノマリースコアを算出する分析ステップと、前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータとを含む異常検知情報を、センタ装置に送信する送信ステップと、を行い、前記センタ装置は、前記異常検知情報を受信すると、前記異常検知情報を用いて前記機械のメンテナンスの要否を判別する判別ステップと、メンテナンスが必要であると判別した場合、交換部品の発注要求を部品事業者サーバに送信するとともに、メンテナンスを行うスタッフの手配要求を、メンテナンス事業者サーバに送信する要求送信ステップと、を行う。

本発明は、機械のメンテナンスを行うメンテナンスシステムであって、前記機械に設置された分析装置と、センタ装置とを含み、前記分析装置は、前記機械の動作中において、少なくとも１つのセンサからセンシングデータを収集する収集部と、前記センシングデータを、ストリーム処理で分析し、異常の度合を示すアノマリースコアを算出する分析部と、前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータとを含む異常検知情報を、前記センタ装置に送信する送信部と、を備え、前記センタ装置は、前記異常検知情報を受信すると、前記異常検知情報を用いて前記機械のメンテナンスの要否を判別する制御部と、メンテナンスが必要であると判別した場合、交換部品の発注要求を部品事業者サーバに送信する部品管理部と、メンテナンスが必要であると判別した場合、メンテナンスを行うスタッフの手配要求を、メンテナンス事業者サーバに送信するスタッフ管理部と、を備える。

本発明は、上記メンテナンス方法を、コンピュータシステムに実行させるためのメンテナンスプログラムである。

本発明によれば、機械の動作中にリアルタイムに異常を検知し、機器の迅速なメンテナンスを可能とする技術を提供することができる。

本発明の実施形態に係るメンテナンスシステムの全体構成図である。 本実施形態の分析装置およびセンタ装置の構成を示すブロック図である。 分析装置が異常を検知した場合の動作を示すシーケンス図である。 異常検知時におけるデータの流れを示す図である。 学習モデルを更新する動作を示す図である。

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

図１は、本実施形態における、リアルタイムなIoTデータ分析によるメンテナンスシステムの全体構成図である。

なお、本実施形態では、メンテナンス対象の機械として、航空機（輸送機械、乗り物）を例として以下に説明するが、本発明は、航空機、自動車、新幹線などの輸送機械に限定されるものではなく、他の機械（例えば、工作機械、建設機械、プラント施設などの産業機械）、装置、機器などにも適用することができる。

図１に示すメンテナンスシステムでは、メンテナンス対象の航空機１内に設置される分析装置１１と、少なくとも１つのセンサ１２とを備える。また、メンテナンスシステムは、センタ装置２（センタシステム）と、部品事業者サーバ３と、メンテナンス事業者サーバ４と、3Dプリンタ５とを備える。

センサ１２（例えば、圧力計など）は、航空機１の各部品の状態をセンシング（測定、検知など）し、センシングデータを分析装置１１に送信する。本実施形態の航空機１には、様々な種類のセンサ１２が、数十個程設置されるものとする。

分析装置１１は、小型コンピュータであって、航空機１の動作中（航空中）に各センサ１２から出力されるセンシングデータを、リアルタイムに分析する（Ｓ１）。そして、センシングデータが所定の閾値を超えた場合、通常動作時のセンシングデータからの乖離が大きい場合など、異常（アノマリー）を検知する。なお、重大な事故（支障）に繋がるイベントについては、人手を介した緊急処理が行われる。

分析装置１１は、異常を検知した場合、異常と判別したセンシングデータを、セキュアな無線ネットワークを経由して、地上のセンタ装置２に送信する（Ｓ２）。

センタ装置２は、クラウドシステムであって、航空機１の異常個所を特定、交換部品の手配、航空機１の整備を行うメンテナンススタッフの確保・手配を行う。すなわち、センタ装置２は、交換部品の発注要求を部品事業者サーバ３に送信し（Ｓ３）、メンテナンススタッフの手配要求を、メンテナンス事業者サーバ４に送信する（Ｓ４）。

部品事業者サーバ３は、航空機１の各種部品を供給する部品事業者のサーバである。メンテナンス事業者サーバ４は、航空機１のメンテナンス（保守）を行う事業者が運営するサーバであって、メンテナンススタッフを管理する。

また、航空機１の部品は種類が膨大であるため、交換部品の発注を受けてから3Dプリンタ５が交換部品を製造することとしてもよい。この場合、部品事業者サーバ３は、センタ装置２から発注要求を受信すると、航空機１の行先（目的地、到着地）の空港近くのメンテナンス拠点にある3Dプリンタ５に、交換部品の3Dデータを送信する。3Dプリンタ５は、送信された3Dデータに基づいて部品を作成する。作成された部品は、航空機１の行先の空港に配達される。

また、センタ装置２は、交換部品およびメンテナンススタッフを手配したことなどのメンテナンス計画を、分析装置１１に送信（フィードバック）してもよい。

このように本実施形態では、移動中の航空機１にセンサ１２を取り付けて、逐次センシングデータを航空機１内の分析装置１１でリアルタイムに分析を行い、異常を検知した場合は、地上のセンタ装置２に通知する。また、通知を受けたセンタ装置２では、航空機１の故障個所を特定し、交換部品およびメンテナンススタッフの手配を行う。

これにより、本実施形態では、部品の手配およびスタッフの手配は、航空機１が航空中に行われるため、航空機１が行先の空港に到着後、即時に故障個所に対象を絞った整備が可能となり、整備の遅れによる航空機１の遅延、欠便などを、抑制または回避することができる。

次に、本実施形態の分析装置１１およびセンタ装置２の構成について説明する。

図２は、分析装置１１および、センタ装置の機能ブロックを示す図である。

航空機１内に設置される分析装置１１は、センシングデータをセンタ装置２に送信するためのゲートウェイ装置などであって、例えば、RaspberryPi等の小型コンピュータを想定している。RaspberryPiは、ARMプロセッサを搭載したシングルボードコンピュータである。本実施形態の分析装置１１は、センシングデータをストリーム処理し、即時のアクションに繋げるため、オンライン機械学習フレームワークを用いる。

ストリーム処理は、大量に発生するデータを逐次に時系列処理する技術である。データ発生時に、あらかじめ登録したシナリオ（学習モデルなど）にしたがってデータを分析し、処理する。

本実施形態では、オンライン機械学習フレームワークとしてJubatusを用い、分析装置１１（エッジ側）とセンタ装置２（クラウド側）の両方にインストールする。分析装置１１のJubatusは、学習モデルを用いて、アノマリースコアを算出し、異常が疑われるセンシングデータを抽出する。また、分析装置１１のJubatusは、抽出したセンシングデータと、過去の故障時のセンシングデータとを照合することで、抽出したセンシングデータを分類し、当該センシングデータに故障の種別を示すラベルを付与する。センタ装置２のJubatusは、学習モデルの更新、および更新した学習モデルを分析装置１１へ配信する。

Jubatusは１件１件のイベントに対して、判定又は学習を行うフレームワークで、ツイッターの投稿等、ストリームデータの処理に向いている。Jubatusについては、下記文献に記載されている。

S. Hido, S. Tokui, S. Oda, "Jubatus: An Open Source Platform for Distributed Online Machine Learning," NIPS 2013 Workshop on Big Learning, Lake Tahoe, 2013.
http://jubat.us/ja/
図示する、分析装置１１は、収集部１１１と、分析部１１２と、送信部１１３と、記憶部１１４とを備える。収集部１１１は、航空機１の動作中（飛行中）において、少なくとも１つのセンサ１２から当該航空機１（または、航空機１の部品）のセンシングデータを収集する。

分析部１１２は、オンライン機械学習フレームワーク（Jubatus）の学習モデルを用いて、収集部１１１が収集したセンシングデータを、ストリーム処理で分析し、異常の度合を示すアノマリースコアを算出する。また、分析部１１２は、収集したセンシングデータと、過去の故障時のセンシングデータとを照合することで、センシングデータを分類し、類似する過去の故障時のグループのラベルを付与する。

送信部１１３は、アノマリースコアが所定の閾値以上の場合に、アノマリースコアと、ラベルと、センシングデータと、航空機１の識別情報とを含む異常検知情報を、センタ装置２に送信する。

分析装置１１とセンタ装置２との通信は、閉域VPN網で、インターネットを経由せずに行われる。航空機１における異常検知情報等の業務情報を、インターネットを介して通信すると、様々なセキュリティ上の脅威に晒されてしまう。このため、本実施形態では、守秘性が高い異常検知情報（IoTデータ）をセンタ装置２へ送信する際には、UNO(Universal One)、UNOモバイルM2M等の閉域VPN網を用いるものとする。また、通信プロトコルにはMQTT(MQ Telemetry Transport)のセンサ向け軽量プロトコルを用いることとする。

記憶部１１４には、分析部１１２が分析に用いる学習モデル、収集部１１１が収集したセンシングデータ、航空機１の識別情報などが記憶される。

図２に示すセンタ装置２（クラウドシステム）は、分析装置１１が検知した異常に応じた制御を行う。図示するセンタ装置２は、メンテナンス制御部２１と、ERP部２２ (Enterprise Resource Planning：統合業務部パッケージ)と、スタッフ管理部２３と、インメモリDB２４と、記憶部２５と、モデル更新部２６と、通信部２７とを備える。

メンテナンス制御部２１は、航空機１内の分析装置１１から異常検知情報を受信すると、当該異常検知情報を用いて、航空機１の故障個所の特定し、メンテナンスの要否を判別する。メンテナンスが必要であると判別した場合、メンテナンス制御部２１は、発注データを生成し、インメモリDB２４に登録する。発注データには、交換部品用の発注データと、メンテナンススタッフ用の発注データとがある。

また、メンテナンス制御部２１は、異常検知情報に含まれる識別情報を用いて、航空機１の行先情報を取得する。インメモリDB２４には、航空機１の識別情報と行先情報とが対応付けて記憶された行先情報テーブルが記憶されているものとする。メンテナンス制御部２１は、行先情報テーブル参照し、航空機１の行先情報を取得する。発注データには、行先情報が含まれている。

なお、メンテナンス制御部２１のアプリケーションを作る際には、OpenStack（オープンソースのIaaSソフトウェア）、Cloud Foundry（オープンソースのPaaSソフトウェア）等を、アプリケーション開発の基盤として利用しても良い。

ERP部２２（部品管理部）は、メンテナンスが必要であると判別した場合、インメモリDB２４に登録された交換部品用の発注データを読み出し、当該発注データを含む発注要求を部品事業者サーバ３に送信する。

これにより、部品事業者サーバ３は、発注要求（発注データ）に含まれる行先情報に対応するメンテナンス拠点における、交換部品の在庫の有無を判別し、交換部品の在庫がない場合、行先情報に対応するメンテナンス拠点に設置された3Dプリンタ５に、交換部品の3Dデータを送信する。

スタッフ管理部２３は、メンテナンスが必要であると判別した場合、インメモリDB２４に登録されたスタッフ用の発注データを読み出し、当該発注データを含むスタッフの手配要求を、メンテナンス事業者サーバ４に送信する。これにより、メンテナンス事業者サーバ４は、手配要求（発注データ）に含まれる行先情報に対応するメンテナンス拠点に派遣するスタッフを割り当て、割り当てたスタッフを行先情報のメンテナンス拠点に派遣する。

インメモリDB２４は、メンテナンス制御部２１と、ERP部２２およびスタッフ管理部２３とを連携させるためのデータベースである。すなわち、インメモリDB２４は、メンテナンス制御部２１と、ERP部２２およびスタッフ管理部２３の両方から参照可能なデータベースである。

複数のシステム連携に関して、従来は、IoT等での可視化アプリケーションは情報系と呼ばれ、勘定・発注等の基幹系システムとデータベースが別であり、情報系と基幹系のデータのやり取りはデータベースの性能ネックのためバッチ処理が基本である。本実施形態では、IoTのデータ分析結果を即時に基幹系（ERP部２２、スタッフ管理部２３）の発注等に反映するために、情報系と基幹系でデータベースが統合され、高速処理が可能なMySQL ClusterのようなインメモリDB２４を用いる。

インメモリDB２４を介することで、発注データ等を処理するERP部２２およびスタッフ管理部２３にも、メンテナンス制御部２１のIoTデータ分析結果を即時に流通させることができる。なお、インメモリDB２４は、物理サーバとしてセンタ装置２の外部に配置することとしてもよい。

図示するインメモリDB２４には、分析装置１１から送信された異常検知情報、交換部品用の発注データ、メンテナンススタッフ用の発注データ、行先情報テーブルなどが記憶される。

記憶部２５には、分析装置１１から送信された異常検知情報のうち、センシングデータ（生データ）が格納される。

モデル更新部２６は、複数の航空機１の分析装置１１から送信された異常検知情報に基づいて、各分析装置１１が使用する学習モデルを更新する。更新された学習モデルは、メンテナンス制御部２１が各航空機１の分析装置１１に配信する。

通信部２７は、分析装置１１とデータを送受信する。ここでは、通信部２７は、通信プロトコルとしてMQTTを用いる。

上記説明した、分析装置１１およびセンタ装置２は、例えば、ＣＰＵと、メモリと、ハードディスク等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、分析装置１１およびセンタ装置２の各機能は、分析装置１１用のプログラムの場合は分析装置１１のＣＰＵが、そして、センタ装置２用のプログラムの場合はセンタ装置２のＣＰＵがそれぞれ実行することにより実現される。また、分析装置１１用のプログラムおよびセンタ装置２用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。なお、センタ装置２は、複数のサーバから構成されるセンタシステムであってもよい。

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

図３は、航空機１が異常を検知した場合の動作を示すシーケンス図である。

航空機１に取り付けられた複数のセンサ１２の各々は、航空機１または航空機１の各部品に対してそれぞれセンシングを行い、センシングデータを分析装置１１に出力する。

分析装置１１は、各センサ１２が出力するセンシングデータを収集する（Ｓ１１）。なお、分析装置１１とセンサ１２との間の通信には、有線であっても無線（例えば、wify、zigbeeなど）であってもよい。

そして、分析装置１１は、Jubatus（オンライン機械学習フレームワーク）を用いて、各センサからのセンシングデータをストリーム処理により分析する（Ｓ１２）。具体的には、分析装置１１は、異常検知アルゴリズム（例えば、Local outlier factor等）により、アノマリースコアを算出する。そして、アノマリースコアが所定の閾値よりも大きい場合、または、通常の動作時におけるアノマリースコアと大きく乖離する場合は、異常が発生したと判別する。すなわち、分析装置１１は、異常を検知する。

異常検知アルゴリズムは、複数の種類のセンサ１２のセンシングデータの多次元空間上で、通常の動作時のセンシングデータからの外れ度合いが大きい場合に、アノマリースコアが大きな値となるように算出するアルゴリズムである。異常検知アルゴリズムは、細かなルールおよび閾値の設定を行うことなく、容易に異常検知が可能である。

また、異常を検知した場合、分析装置１１は、Jubatus のClassifierアルゴリズム（Support Vector Regression 等）を用いて、収集したセンシングデータを、過去に発生した故障時（異常時）のセンシングデータと比較して分類を行い、過去の最も類似するグループのラベルを、収集したセンシングデータに付与する。ラベルは、故障の種別を示すものである。過去に類似するセンシングデータのグループ（事例）が無い場合は、ラベルは無くても良い。

そして、分析装置１１は、異常を検知した場合、異常検知情報をセンタ装置２に送信する（Ｓ１３）。異常検知情報には、アノマリースコア、センシングデータ、ラベル、航空機１の識別情報が含まれる。

分析装置１１とセンタ装置２との間の通信には、UNOモバイルM2M等のVPNを用いる。UNOモバイルM2Mは、専用のSIMカードをセットした通信モジュールが、閉域VPN網Arcstar Universal One経由で、データセンタと通信するソリューションである。

また、本実施形態では、分析装置１１とセンタ装置２との間の通信プロトコルには、MQTTを用いる。MQTTは、publish-subscribeモデルのセンサ用軽量メッセージキュープロトコルである。MQTTを用いて、キューを介してやり取りすることで、分析装置１１とセンタ装置２では、独立して動作が可能である。

センタ装置２のメンテナンス制御部２１は、通信部２７を介して異常検知情報を受信すると、当該異常検知情報を、故障が疑われるデータ（故障傾向データ）であるとして、インメモリDB２４に記憶する。

そして、メンテナンス制御部２１は、受信した異常検知情報（アノマリースコア、ラベル、センシングデータ）に応じて、何日以内にどの程度の障害になるかの確率（故障予測）、障害が起きた際にどの程度の被害額となるか、どの部品を交換すべきかなどを解析し、航空機１に対するメンテナンスの要否（障害影響）を判別する（Ｓ１４）。このような故障予測などの解析には、PSPP等のフリーの統計解析ソフトウェアを用いてもよい。

なお、異常検知情報にラベルが無く、故障原因を特定できない場合は、メンテナンスセンタのオペレータに通知を行い、オペレータが人手で解析しても良い。

そして、メンテナンスが必要であると判別した場合、メンテナンス制御部２１は、メンテナンスのリソース（部品、スタッフ）を自動で手配するために、発注データを生成し、インメモリDB２４に登録する（Ｓ１５）。

メンテナンスには、一般的に、航空機１の行先（到着空港）での交換部品の手配と、メンテナンススタッフ（整備スタッフ）の手配の両方が必要となる。このため、メンテナンス制御部２１は、交換部品の発注データと、スタッフを確保するための発注データとを生成する。

なお、部品用の発注データには、交換部品に関する情報（例えば、部品の識別情報など）と、行先情報などが含まれる。行先情報については、メンテナンス制御部２１は、インメモリDB２４の行先情報テーブルを参照して取得する。また、行先情報テーブルに、航空機１の行先（到着空港）での到着時刻が設定されている場合は、発注データに到着時刻も含めても良い。

また、スタッフ用の発注データには、メンテナンス箇所、メンテナンスの内容など、適切なスタッフを手配するために必要なスタッフに関する情報が含まれる。また、部品用の発注データと同様に、スタッフ用の発注データには、行先情報、到着時刻などが含まれる。

そして、メンテナンス制御部２１は、発注データをインメモリDB２４に登録したこと通知するための発注通知を、ERP部２２およびスタッフ管理部２３に送出する（Ｓ１６、Ｓ１７）。

センタ装置２のERP部２２は、発注通知を受け付けると、インメモリDB２４に登録された部品交換用の発注データを読み出し、交換部品の発注処理を行う。具体的には、ERP部２２は、交換部品の発注データを含む発注要求を、ビジネス向けネットワークを介して、部品事業者サーバ３に送信する（Ｓ１８）。

部品事業者サーバ３は、発注要求（発注データ）を受信すると、当該部品事業者サーバ３が備える部品DBを参照して、行先情報の近傍に位置するメンテナンス拠点（事業所）における交換部品の在庫確認を行う（Ｓ１９）。部品在庫が無い場合は、部品事業者サーバ３は、行先情報の近傍のメンテナンス拠点に配備された3Dプリンタ５に、交換部品の3Dデータを送信する（Ｓ２０）。

行先近傍の3Dプリンタ５は、3Dデータを受信し、当該3Dデータを用いて交換部品を作成する（Ｓ２１）。在庫にある交換部品または3Dプリンタ５で作成された交換部品は、発注データの到着時刻までに届くように、航空機１の行先（到着空港）に配達、発送される。

また、スタッフ管理部２３は、発注通知を受け付けると、インメモリDB２４に登録されたスタッフ用の発注データを読み出し、メンテナンススタッフの手配処理を行う。具体的には、スタッフ管理部２３は、メンテナンススタッフを確保・割り当てるための発注データ含む手配要求を、ビジネス向けネットワークを介して、メンテナンス事業者サーバ４に送信する（Ｓ２２）。

メンテナンス事業者サーバ４は、手配要求（発注データ）を受信し、当該メンテナンス事業者サーバ４が備えるスタッフ管理DBを参照して、行先情報の行先（到着空港）に派遣し、メンテナンスを行うメンテナンススタッフを割当て、スタッフを手配する（Ｓ２３）。割当てられたスタッフは、発注データの到着時刻までに行先に到着する。

これにより、航空機１の行先（到着空港）では、飛行機が到着する前に、交換部品およびスタッフが手配されているため、航空機１の到着後、直ちにメンテナンスを実施することができる。

なお、部品交換が不要なメンテナンスの場合は、Ｓ１５では、スタッフを確保するための発注データのみが生成され、Ｓ１６、Ｓ１８〜Ｓ２１の処理は行われない。また、常に航空機１の行先（到着空港）でスタッフが常駐している場合など、スタッフの確保が不要な場合は、Ｓ１５において、部品交換用の発注データのみが生成され、Ｓ１７、Ｓ２２、Ｓ２３の処理は行われない。

図４は、図３で説明した異常検知時におけるデータの流れを示す図である。

航空機１の分析装置１１は、センサ１２から収集したセンシングデータにおいて、異常を検知した場合、異常検知情報（センシングデータ、アノマリースコア、ラベル、航空機１の識別情報等）を、VPNを経由してセンタ装置２に送信する（Ｓ３１）。ここでは、MQTTの通信プロトコルを用いる。

センタ装置２において、通信部２７は、分析装置１１から送信された異常検知情報を、メンテナンス制御部２１に出力する（Ｓ３２）。また、通信部２７は、分析装置１１から送信された異常検知情報のうち、センシングデータを、Jubatusとは独立した記憶部２５に格納する（Ｓ３３）。

メンテナンス制御部２１は、異常検知情報を用いて、航空機１のメンテナンスの要否を判別し、メンテナンスが必要と判別した場合は、発注データを生成し、異常検知情報とともにインメモリDB２４に登録する（Ｓ３４）。なお、メンテナンス制御部２１は、メンテナンスが不要と判断した場合は、異常検知情報のみを、インメモリDB２４に格納する。

また、メンテナンス制御部２１は、メンテナンスが必要と判別した場合、発注データをインメモリDB２４に登録したことを通知するための発注通知をERP部２２およびスタッフ管理部２３に送出する（Ｓ３５）。

ERP部２２は、発注要求を受け付けると、インメモリDB２４から交換部品用の発注データを読み出し（Ｓ３６）、当該発注データを部品事業者サーバ３に送信する（Ｓ３７）。また、スタッフ管理部２３は、発注通知を受け付けると、インメモリDB２４からスタッフ用の発注データを読み出し（Ｓ３８）、当該発注データをメンテナンス事業者サーバ４に送信する（Ｓ３９）。

図５は、分析装置１１で用いられる学習モデルを更新する動作を示す図である。

学習モデルの更新は、センタ装置２の運営者（クラウドサービス運営者）が行う場合と、航空機運用者（輸送機械の運用者）が自ら行う場合の両方が想定される。クラウドサービスの運営ポリシー、利用料金、航空機運用者の機械学習知識などに応じて、どちらかを選択すればよい。

学習モデルの更新を行う管理者（センタ装置２の運営者、または、航空機運用者）は、ＰＣなどの端末装置６を用いて、センタ装置２にアクセスし、インメモリDB２４に格納された過去のアノマリースコア、ラベルなどの異常検知情報、および、記憶部２５に格納されたセンシングデータを閲覧し、分析装置１１が行った異常の判定の妥当性、ラベルの妥当性を検証する。

センタ装置２は、端末装置６とのユーザインタフェース（モデル作成用ＧＵＩ）として、分析用アプリ２１１を備えるものとする。なお、分析用アプリ２１１は、メンテナンス制御部２１の一部の機能である。

端末装置６は、センタ装置２の分析用アプリ２１１を介してメンテナンス制御部２１にインメモリDB２４のデータおよび記憶部のデータを要求し、要求したデータを管理者に提示する（Ｓ５１）。また、端末装置６は、管理者の指示にしたがって、分析装置１１に配信する学習モデルの更新指示を、分析用アプリ２１１を介して、メンテナンス制御部２１に送信する（Ｓ５２）。

メンテナンス制御部２１は、モデル変更指示を受けると、モデル更新API（Application Programming Interface）を介してモデル更新部２６に、学習モデルの更新を要求する。モデル更新部２６（Jubatus）は、更新要求にしたがって、学習モデルを更新し、更新後の学習モデルをメンテナンス制御部２１に送出する（Ｓ５３）。メンテナンス制御部２１は、更新された学習モデルを通信部２７を介して、複数の航空機１の分析装置１１に、それぞれ配信する（Ｓ５４、Ｓ５５）。なお、メンテナンス制御部２１から各分析装置１１への学習モデルの配信には、MQTTなどの通信プロトコルが用いられる。

センタ装置２には、多数の航空機１の分析装置１１からのデータ（異常検知情報）が集まるため、それらのデータを用いて、より高い精度となるように学習モデルを更新し、各航空機１の分析装置１１に配信することができる。

以上説明した本実施形態では、機械（航空機１）に設置された分析装置１１が、機械の動作中において、センサ１２からセンシングデータを収集し、ストリーム処理で分析し、異常の度合を示すアノマリースコアが閾値以上の場合に、異常検知情報をセンタ装置２に送信する。

このように、本実施形態では、分析装置１１が動作中の機械の異常をリアルタイムに検知してセンタ装置２に通知することで、センタ装置２は、機械の動作中にメンテナンスに必要な的確な手配・準備を行うことができ、機器の動作停止後、直ちに機器のメンテナンスを行うことができる。すなわち、機械のメンテナンスに要する時間を短縮することができる。

また、本実施形態では、分析装置１１が機械の動作中にリアルタイムに異常を検知し、センタ装置２は検知された異常に基づいて、動作中の機械の交換部品およびメンテナンススタッフの手配を行うため、迅速で低コストなメンテナンスを行うことができる。

また、本実施形態の機械は、航空機１（輸送機械）であって、飛行中にはメンテナンスを行うことができず、行先に到着してからメンテナンスが可能となる。本実施形態では、航空機１の飛行中に分析装置１１において、リアルタイムに異常が検知され、センタ装置２に通知される。このため、センタ装置２では、航空機１の飛行中に、航空機１の到着空港での交換部品およびメンテナンススタッフの手配を行うことができるため、航空機１が行先の空港に到着した後、短い時間で的確なメンテナンスが行えるため、航空機１の回転率を上げることができる。

すなわち、航空機１が行先空港に到着してから、航空機１の整備を行い、異常を検出し、交換部品およびメンテナンススタッフの手配を行う場合に比べて、大幅にメンテナンス時間を短縮することができる。したがって、航空機１の大幅な遅延、欠便となどを極力抑制することができるとともに、乗客の利便性を向上し、代替機の手配などのコストを削減することができる。

また、本実施形態では、航空機１の行先空港の近傍のメンテナンス拠点に配備された3Dプリンタに3Dデータを送信することで、交換部品を生成する。これにより、部品の在庫を持たずに、交換部品の発注に応じて部品を作成し、配達手配すれば良いため、在庫コストを低減できる。

とくに、航空機１やロケットなどは、ロット数は出ないが、多くの部品からなる製品であり、メンテナンス用に部品を長期間確保することによる在庫管理コストが大きい。また、航空機１、新幹線などの長距離の移動を行う輸送機械に対しては、交換部品は移動先で交換する必要があるため、膨大な種類の交換部品を、多数の空港または駅等で在庫を保持する場合、在庫管理コストが高くなってしまう。これに対して、本実施形態では、3Dプリンタ５がその都度、交換部品を生成するため。在庫管理コストを大幅に低減することができる。

また、本実施形態では、オンライン機械学習フレームワーク（Jubatus）の処理を、航空機１内の分析装置１１（エッジ側）とセンタ装置２（クラウド側）で分担する。これにより、分析装置１１では、異常検知および分類のシンプルな処理だけを行うため、RaspberryPi等の軽量なコンピュータで処理が可能である。また、分析装置１１は、異常を検知した時だけセンタ装置２にデータを送信するためネットワークコストが低減できる。また、センタ装置２側では、多数の航空機１（拠点）からの異常に関するデータ（異常検知情報）を収集することができるため、多数のデータ（事例）に基づいて高い精度の学習モデルを生成し、航空機１の分析装置１１に配信することができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１ ：輸送機械（航空機）
１１：分析装置
１２：センサ
２ ：センタ装置
２１：メンテナンス制御部
２２：ERP部
２３：スタッフ管理部
２４：インメモリDB
２５：記憶部
２６：モデル更新部
２７：通信部
３ ：部品事業者サーバ
４ ：メンテナンス事業者サーバ
５ ：3Dプリンタ

Claims (7)

1. 機械のメンテナンスを行うメンテナンス方法であって、
   前記機械に設置された分析装置が、
   前記機械の動作中において、少なくとも１つのセンサからセンシングデータを収集する収集ステップと、
   前記センシングデータを、ストリーム処理で分析し、異常の度合を示すアノマリースコアを算出する分析ステップと、
   前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータとを含む異常検知情報を、センタ装置に送信する送信ステップと、を行い、
   前記センタ装置は、
   前記異常検知情報を受信すると、前記異常検知情報を用いて前記機械のメンテナンスの要否を判別する判別ステップと、
   メンテナンスが必要であると判別した場合、交換部品の発注要求を部品事業者サーバに送信するとともに、メンテナンスを行うスタッフの手配要求を、メンテナンス事業者サーバに送信する要求送信ステップと、を行うこと
   を特徴とするメンテナンス方法。
2. 請求項１記載のメンテナンス方法であって、
   前記機械は、人または物の輸送機械であって、
   前記分析装置の前記送信ステップは、前記アノマリースコアが閾値以上の場合に、前記輸送機械の識別情報を含む前記異常検知情報を、前記センタ装置に送信し、
   前記センタ装置は、
   前記異常検知情報に含まれる識別情報を用いて、前記輸送機械の行先情報を取得する行先取得ステップをさらに行い、
   前記要求送信ステップは、前記行先情報を含む前記交換部品の発注要求を前記部品事業者サーバに送信するとともに、前記行先情報を含む前記手配要求を前記メンテナンス事業者サーバに送信すること
   を特徴とするメンテナンス方法。
3. 請求項２記載のメンテナンス方法であって、
   前記部品事業者サーバは、
   前記発注要求を受信し、当該発注要求に含まれる前記行先情報に対応するメンテナンス拠点における、前記交換部品の在庫の有無を判別する判別ステップと
   前記交換部品の在庫がない場合、前記メンテナンス拠点に設置された3Dプリンタに、前記交換部品の3Dデータを送信すること
   を特徴とするメンテナンス方法。
4. 請求項１から３のいずれか１項に記載のメンテナンス方法であって、
   前記分析装置の前記分析ステップは、前記アノマリースコアが閾値以上の場合に、前記センシングデータと、過去の異常時のセンシングデータとを照合することで、当該センシングデータを分類し、当該センシングデータに故障の種別を示すラベルを設定し、
   前記送信ステップは、前記ラベルを含む前記異常検知情報を、前記センタ装置に送信すること
   を特徴とするメンテナンス方法。
5. 請求項１から４のいずれか１項に記載のメンテナンス方法であって、
   前記センタ装置は、
   前記分析装置が前記分析ステップで使用する学習モデルを更新する更新ステップと、
   前記更新後の学習モデルを前記分析装置に配信する配信ステップと、をさらに行い、
   前記分析装置の前記分析ステップは、前記更新後の学習モデルを用いて、前記センシングデータをストリーム処理で分析し、前記アノマリースコアを算出すること
   を特徴とするメンテナンス方法。
6. 機械のメンテナンスを行うメンテナンスシステムであって、
   前記機械に設置された分析装置と、センタ装置とを含み、
   前記分析装置は、
   前記機械の動作中において、少なくとも１つのセンサからセンシングデータを収集する収集部と、
   前記センシングデータを、ストリーム処理で分析し、異常の度合を示すアノマリースコアを算出する分析部と、
   前記アノマリースコアが閾値以上の場合に、前記アノマリースコアと前記センシングデータとを含む異常検知情報を、前記センタ装置に送信する送信部と、を備え、
   前記センタ装置は、
   前記異常検知情報を受信すると、前記異常検知情報を用いて前記機械のメンテナンスの要否を判別する制御部と、
   メンテナンスが必要であると判別した場合、交換部品の発注要求を部品事業者サーバに送信する部品管理部と、
   メンテナンスが必要であると判別した場合、メンテナンスを行うスタッフの手配要求を、メンテナンス事業者サーバに送信するスタッフ管理部と、を備えること
   を特徴とするメンテナンスシステム。
7. 請求項１から５のいずれか１項に記載のメンテナンス方法を、コンピュータシステムに実行させるためのメンテナンスプログラム。

Images