JP2016146020A - データ分析システム及び分析方法 - Google Patents

Abstract

【課題】世界中に存在する大量のデバイスに対してリアルタイムに故障予測をすると、データの受信部に負荷が集中してしまう。更に、デバイスからのデータ受信の頻度が上がれば上がるほど故障予測の頻度も上がるが、それに伴い受信部の負荷は更に増大する。
【解決手段】１以上の情報処理装置を含む分析システムは、第１の分析の結果に基づいて複数のネットワークデバイスの中から、第２の分析のために必要なデータを収集する対象とするネットワークデバイスを決定し、第１の分析におけるデータ収集の頻度より高い頻度で、決定されたネットワークデバイスから第２の分析に必要なデータが収集されるよう制御し、決定されたネットワークデバイスから収集されたデータを用いて第２の分析を実行する。
【選択図】図８

Description

本発明は、画像形成装置の故障を事前に予測する故障予測システムにおける、システムの低負荷化に関するものである。

近年、ビッグデータを積極的に分析、活用しようとする動きが活発化している。画像形成装置の分野でも、大量のデバイスからのセンサー情報と故障履歴から故障予測モデルを作成し、世界中のデバイスの故障予測をリアルタイムに行うことが検討されている。このシステムは、画像形成装置からセンサーデータを定期的に収集し、収集したデータに対して故障予測モデルを適用する。そして適用の結果、異常値が出た場合に、画像形成装置の保守必要個所に対して部品交換や清掃を行うようにサービスマンに依頼するというものである。これにより、その個所における故障の発生を未然に防ぐことができる。

このようなシステムにおいて更に効率的なメンテナンスを行うための先行技術として、例えば特許文献１がある。特許文献１では、デバイスの故障予測に対して、いずれかのデバイスで異常が検出された場合には、そのデバイスと同じ地域に設置されている他のデバイスを特定する。そして特定したデバイスのそれぞれについて、判定基準をより厳しくして異常の有無を判定する基準引き上げ判定処理を行う。同じ地域で同じようなデバイスの異常が見つかることはよくあるため、特許文献１の技術により、効率的なメンテナンス作業を行うことができる。

特開２００７−４９３４９号公報

特許文献１に記載の技術では、世界中に存在する大量の画像形成装置からデータを取得する場合に、データの受信部に負荷が集中してしまう。更に、デバイスからのデータ受信の頻度が上がれば上がるほど故障予測の頻度も上がるが、それに伴い受信部の負荷は更に増大する。

上記課題を解決するため、本発明は、１以上の情報処理装置を含み、複数のネットワークデバイスから収集したデータを分析する分析システムであって、第１の分析の結果に基づいて、前記ネットワークデバイスの中から、第２の分析のために必要なデータを収集する対象とするネットワークデバイスを決定する決定手段と、第１の分析におけるデータ収集の頻度より高い頻度で、前記決定されたネットワークデバイスから第２の分析に必要なデータが収集されるよう制御する制御手段と、前記決定されたネットワークデバイスから収集されたデータを用いて第２の分析を実行する実行手段とを有することを特徴とする分析システムを提供する。

本発明では、通常時には低頻度でデバイスからデータを受信しているため、データ受信部の負荷を抑えることができる。低頻度データを用いた故障予測において異常を判定したら高頻度でデータを送信するようにデバイスに指示を出し高頻度データを用いて故障予測を行うため、故障予測の精度をあまり下げることなく負荷を抑えることができる。

データ活用システムの全体構成 サーバコンピュータハード構成 データ蓄積装置ソフト構成 データ分析装置ソフト構成 デバイス管理装置ソフト構成 画像形成装置ハード構成 画像形成装置ソフト構成 低負荷故障予測フローチャート 高頻度送信履歴ＤＢ状態管理フローチャート サービスマン定期出動予定を考慮した高頻度送信履歴ＤＢ状態管理フローチャート データ活用システムの全体シーケンス データ収集装置ソフト構成 分析者端末ソフト構成

以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、フローチャート中の「Ｓ」はステップを表す。

＜実施例１＞
図１は、本発明の実施例１に係る、故障予測システムの全体構成を示す図である。図１において、デバイス管理装置１１１、データ蓄積装置１１２、データ分析装置１１３、複数のネットワークデバイス（１２１〜１２３）、データ収集装置１１４および分析者端末１１５はネットワーク１０１〜１０５を介して接続される。なお、図１のデータ蓄積装置１１２、データ分析装置１１３およびデータ収集装置１１４は、分析システムに含まれ、それぞれが仮想マシンとして実現されるようにしても良い。また、それら仮想マシンは、１以上の情報処理装置上で実行される。

ネットワークデバイスは、本明細書では画像形成装置として記述するが、本発明はデジタル医療機器、ネットワークカメラ、ロボット、車載端末、または空調にも適用可能である。また、ネットワークデバイスの数を３個として記述するが、３個に限定されるものではない。ネットワーク１０１〜１０５は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線またはデータ放送用無線回線等である。または、これらの組合せにより実現される、いわゆる通信ネットワークである。ネットワーク１０１〜１０５はデータの送受信が可能であればよい。本明細書では、ネットワーク１０４はインターネット、ネットワーク１０１〜１０３と１０５は企業内ネットワークやサービスプロバイダーのネットワークを想定するが、他のネットワークでも構わない。

デバイス管理装置１１１、データ蓄積装置１１２、データ分析装置１１３はサーバコンピュータ（情報処理装置）により実行される。デバイス管理装置１１１は、画像形成装置１２１〜１２３に対して、センサー情報送信頻度、センサー情報送信期間を設定し、センサー情報送信の指示や、センサー情報送信停止の指示を行うことができる。なお、センサー情報に関しては、後ほど図３を参照して説明する。また、画像形成装置１２１〜１２３は、自身に設置されたセンサー値を取得し、データ蓄積装置１１２に対して送信することができる。データ蓄積装置１１２は、画像形成装置１２１〜１２３から受信した情報を蓄積し、故障予測に必要なデータをデータ分析装置１１３に送信することができる。当該データには、センサーデータ、カウンタ情報、ログ情報の少なくとも１つが含まれる。

データ分析装置１１３は、データ蓄積装置１１２から、故障予測に必要なデータを取得し、あらかじめデータ分析装置１１３内に実装されている故障予測モデルを適用して、その判定結果をデバイス管理装置１１１に通知することができる。データ分析装置１１３内の故障予測モデルは、分析者が分析者端末１１５を通してあらかじめ実装する。データ収集装置１１４は、分析者による故障予測モデルの作成に必要なデータを、データ蓄積装置１１２から取得し、分析者端末１１５からいつでもアクセスできるようにデータを蓄積しておくことができる。

分析者端末１１５は、分析者によって操作される。分析者は、分析者端末１１５内で、一定期間のセンサーデータや故障履歴を用いて、機械学習または単純な数式等によって画像形成装置の故障予測モデルを作成する。センサーデータや故障履歴は、データ収集装置１１４から取得することができる。作成した故障予測モデルは、データ分析装置１１３内に実装することができる。

以降、本明細書で説明するサーバのそれぞれの機能は、単体のサーバ又は単体の仮想サーバによって実現しても構わないし、複数のサーバ又は複数の仮想サーバによって実現しても構わない。あるいは複数の仮想サーバが単体のサーバ上で実行されても構わない。

図１１は、本発明の全体的シーケンスを表したものである。本発明は、故障予測モデルを作成する「モデル作成フェーズ」、低頻度でセンサーデータを取得し故障予測を行う「低精度故障予測フェーズ」、高頻度でセンサーデータを取得し故障予測を行う「高精度故障予測フェーズ」の３つのフェーズによって成り立つ。

モデル作成フェーズでは、まず分析者が、分析者端末１１５を通して、データ分析装置１１３にセンサーデータの送信指示依頼Ｍ１１０１を通知する。データ分析装置１１３は送信指示依頼Ｍ１１０１を受けて、デバイス管理装置１１１にセンサーデータの送信指示依頼Ｍ１１０２を通知する。デバイス管理装置１１１は、送信指示依頼Ｍ１１０２を受けて、画像形成装置１２１〜１２３にセンサーデータの送信指示Ｍ１１０３を通知する。画像形成装置１２１〜１２３は、送信指示Ｍ１１０３で指示されたセンサーデータ送信頻度や送信期間に沿って、データ蓄積装置１１２にセンサーデータを送信する（Ｍ１１０４）。また、画像形成装置１２１〜１２３内で故障が起こったときには、画像形成装置１２１〜１２３からデバイス管理装置１１１に故障通知Ｍ１１０５を通知する。また、任意のタイミングで、データ収集装置１１４はデータ蓄積装置１１２に対してセンサーデータ取得Ｍ１１０６を通知してセンサーデータを取得し、またデバイス管理装置１１１に対して故障履歴取得Ｍ１１０７を通知して故障履歴を取得する。

分析者は、モデル作成に必要なセンサーデータと故障履歴がデータ収集装置１１４に蓄積されていたら、分析者端末１１５を通してデータ収集装置１１４に対して、センサーデータ取得Ｍ１１０８を通知してセンサーデータを取得する。そして、分析者は分析者端末１１５を通して、データ収集装置１１４に対して故障履歴取得Ｍ１１０９を通知し、故障履歴を取得する。分析者は分析者端末１１５内で、取得したセンサーデータ、故障履歴から、機械学習または単純な数式などにより故障予測モデルを作成する（Ｍ１１１０）。そして、分析者は分析者端末１１５を通して、作成したモデルをデータ分析装置１１３に実装する（Ｍ１１１１）。

以上のプロセスを経てデータ分析装置１１３内にモデルが１つ以上実装されたら、低精度故障予測フェーズに移行できる。低精度故障予測フェーズでは、まず分析者は分析者端末１１５を通して、データ分析装置１１３に故障予測開始Ｍ１１２１を通知する。一度故障予測開始Ｍ１１２１が通知されたら、低精度故障予測フェーズまたは高精度故障予測フェーズ内の処理が繰り返し実行される。データ分析装置１１３は故障予測開始Ｍ１１２１の通知を受けて、故障予測に必要なセンサーデータを取得するために、デバイス管理装置１１１に低頻度送信指示依頼Ｍ１１２２を通知する。「低頻度送信指示」とは、引数として指定できる送信頻度を低く設定した送信指示のことである。デバイス管理装置１１１は低頻度送信指示依頼Ｍ１１２２の通知を受けて、画像形成装置１２１〜１２３に低頻度送信指示Ｍ１１２３を通知する。画像形成装置１２１〜１２３は低頻度送信指示Ｍ１１２３で指示されたセンサーデータ送信頻度や送信期間に沿って、データ蓄積装置１１２にセンサーデータを送信する（Ｍ１１２４）。

データ分析装置１１３はデータ蓄積装置１１２を定期的に監視する。その結果、データ分析装置１１３が持つ故障予測モデルが適用できるだけのセンサーデータが蓄積されていたら、データ蓄積装置１１２に対してセンサーデータ取得Ｍ１１２５を通知してセンサーデータを取得する。データ分析装置１１３は、取得したセンサーデータを用いて故障予測Ｍ１１２６を行う。その結果、異常と判定された場合は、高頻度故障予測フェーズであるａｌｔ［異常と判定されたら］内に移行する。

高頻度故障予測フェーズでは、データ分析装置１１３は、高精度故障予測モデルの適用に必要なセンサーデータを取得するため、デバイス管理装置１１１に高頻度送信指示依頼Ｍ１１４１を通知する。「高頻度送信指示」とは、引数として指定できる送信頻度を高く設定した送信指示のことである。デバイス管理装置１１１は高頻度送信指示依頼Ｍ１１４１の通知を受けて、画像形成装置１２１〜１２３に高頻度送信指示Ｍ１１４２を通知する。画像形成装置１２１〜１２３は送信指示Ｍ１１４２で指示されたセンサーデータ送信頻度や送信期間に沿って、データ蓄積装置１１２にセンサーデータを送信する（Ｍ１１４３）。

データ分析装置１１３はデータ蓄積装置１１２を定期的に監視する。その結果、データ分析装置１１３が持つ故障予測モデルが適用できるだけのセンサーデータが蓄積されていたら、データ蓄積装置１１２に対してセンサーデータ取得Ｍ１１４４を通知してセンサーデータを取得する。データ分析装置１１３は、取得したセンサーデータを用いて故障予測Ｍ１１４５を行う。その結果、異常と判定された場合は、高頻度故障予測フェーズであるａｌｔ［異常と判定されたら］内に移行し、データ分析装置１１３は、デバイス管理装置１１１に対してセンサーエラー通知Ｍ１１４６を通知する。

図２は、実施例１に係るデバイス管理装置１１１、データ蓄積装置１１２、データ分析装置１１３、データ収集装置１１４、分析者端末１１５のハードウェア構成図である。図２において、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（以下「ＣＰＵ」）２０２は装置全体の制御を行う。具体的には、ＣＰＵ２０２はＨａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ（以下「ＨＤＤ」）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行する。また、ＣＰＵ２０２はＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（以下「ＲＡＭ」）２０３に、プログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（以下「ＲＯＭ」）２０４は記憶手段であり、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービスサーバー群のプログラム、ＯＳ、関連プログラム等を格納する。

ディスプレイ２０８は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０９は外部装置インターフェースであり、プリンタ、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ（以下「ＮＩＣ」）２０６は、ネットワーク１０１〜１０５を介して外部装置とのデータのやり取りを行う。

なお、上記コンピュータの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。加えて、ＣＰＵ２０２がＨＤＤ２０５に記憶されているプログラムに基づき処理を実行することによって、図３等に示されるようなソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。

図３は、実施例１に係るデータ蓄積装置１１２のソフトウェア構成図である。データ蓄積装置１１２は、データ受付部３０１、データ取得部３０２及びセンサーデータ管理ＤＢ３０３から構成される。データ受付部３０１は、画像形成装置１２１〜１２３から送信されるセンサー情報を受信し、センサーデータ管理ＤＢ３０３に保存する機能を持つ。ここで受信する「センサー情報」とは、センサーデータの取得日時と各センサーのセンサーデータの事であり、例えば下記表Ａの１行分にあたる。

データ取得部３０２は、データ分析装置１１３またはデータ収集装置１１４からのデータ取得リクエストを受けて、センサーデータ管理ＤＢ３０３で管理されているセンサーデータの値を返却値として返す機能を持つ。センサーデータ管理ＤＢ３０３は、画像形成装置から受信したセンサーデータを管理するデータベースである。センサーデータ管理ＤＢ３０３で管理するデータは、例えば下記表Ａのようなセンサーデータである。

表Ａは、画像形成装置にとりつけられたセンサーＭ、Ｎ、Ｏの値を１時間毎に収集した際の各センサーデータの例である。表Ａの「データ取得日時」カラムは、画像形成装置からセンサーデータを取得した日時である。「機種」カラムは画像形成装置の機種名を表す。「機種番号」カラムは、画像形成装置の機種番号を表し、各画像形成装置に対してユニークな値である。「センサーＭ」、「センサーＮ」、「センサーＯ」カラムは、「機種番号」で一意に特定される画像形成装置の「データ取得日時時点」の各センサー値を表す。センサー値とは、例えば画像形成装置内の温度、湿度、部品にかかる電圧などである。

図４は、実施例１に係るデータ分析装置１１３のソフトウェア構成図である。データ分析装置１１３は、図中上段に示すように、故障予測部４０１、外部データ取得部４０２、センサーデータ送信指示部４０３、センサーエラー通知部４０４を含む。また、下段に示すように、故障予測モデル一覧管理ＤＢ４０５、高頻度送信履歴ＤＢ４０６、高頻度送信履歴管理部４０７及び、センサーデータ送信指示依頼受付部４０８を含む。

故障予測部４０１は、データ蓄積装置１１２から取得したデータに対して、故障予測モデルを適用する機能を持つ。故障予測モデルは、分析者によって分析者端末１１５を通して故障予測部４０１内に実装することができる。故障予測部４０１内に、ある故障予測モデルが実装されたら、故障予測モデル一覧管理ＤＢ４０５も更新し、新たな故障予測モデルを登録する。故障予測の処理については図４の説明の最後に記載する。また分析者からの指示で、故障予測の開始、停止を制御することも故障予測部４０１で行う。

外部データ取得部４０２は、データ蓄積装置１１２に蓄積されているセンサーデータを取得する機能を持つ。センサーデータ送信指示部４０３は、指定した（対象となる）画像形成装置（例えば１２１）に対して指定した頻度、期間のセンサーデータを送信するように、デバイス管理装置１１１に通知する機能を持つ。引数の設定の仕方により、送信停止の指示も可能である。

センサーエラー通知部４０４は、指定した画像形成装置（例えば１２１）が、故障予測の結果センサー異常と判定されたことをデバイス管理装置１１１に通知する機能を持つ。故障予測モデル一覧管理ＤＢ４０５は、故障予測をするための故障予測モデルの一覧を管理するデータベースである。故障予測モデル一覧管理ＤＢ４０５で管理するデータは、例えば下記表Ｂのようなデータで、分析者によって故障予測部４０１内に実装された故障予測モデルに対応する。

表Ｂの「モデル名」カラムは、故障予測モデル毎にユニークな故障予測モデルの名前である。「機種」カラムは表Ａの「機種」カラムと同意である。「入力センサー」カラムは、モデルを適用するために必要なセンサーデータの種類の事で、このカラムに書かれた種類のセンサーデータが、故障予測モデルへの入力になる。「入力頻度」カラムは、故障予測モデルに入力するセンサーデータの入力頻度である。「入力期間」カラムは、故障予測モデルに入力するセンサーデータの入力期間である。「モデルグループ」カラムは、故障予測モデルが所属するモデルグループを表す。「高頻度レベル」カラムは、同モデルグループにおいて高頻度出力になったときに次にどの故障予測モデルを適用するかを管理するためのものである。「通知内容」カラムは、ある故障予測モデルを適用して異常を判定したときに、デバイス管理装置に通知する内容を表しており、「高頻度送信指示」か「センサーエラー」（故障通知）のいずれかとなる。「高頻度送信指示」とは、同グループかつ次のレベルのモデルを適用するために、デバイス管理装置１１１に対して今より高い頻度のセンサーデータ送信を要求する指示のことである。「適用続行」カラムは、ある故障予測モデルを適用して異常を判定した後にもそのモデルの適用を続けるかどうかを表す。

表Ｂでは、ＭｏｄｅｌＡ、Ｂ、Ｃが同じモデルグループＡに所属し、高頻度レベルが順に０、１、２となっており、初めはレベル０のモデルであるＭｏｄｅｌＡが適用される。その結果、異常を判定した場合、次に同じモデルグループＡのレベル１であるＭｏｄｅｌＢが適用される。この場合、ＭｏｄｅｌＡの「適用続行」がＴＲＵＥなので、その後においてもＭｏｄｅｌＡの適用は続行される。ＭｏｄｅｌＢを適用した結果、異常を判定した場合、次は同じモデルグループＡのレベル２のモデルであるＭｏｄｅｌＣが適用される。ＭｏｄｅｌＣで異常を判定した場合、ＭｏｄｅｌＣの「通知内容」がセンサーエラーなので、故障予測部４０１はセンサーエラー通知部４０４に、デバイス管理装置１１１へのセンサーエラー通知を依頼する。

高頻度送信履歴ＤＢ４０６は、デバイス管理装置１１１に高頻度送信指示を通知した履歴を管理するデータベースである。高頻度送信管理ＤＢ４０６で管理するデータは、例えば下記表Ｃのようなデータである。故障予測部４０１が故障予測を行った結果、異常を示し、センサーデータ送信指示部４０３に高頻度送信指示を通知するときに新たな行が更新される。

表Ｃの「機種番号」カラムは、表Ａの「機種番号」カラムと同意である。「適用高頻度用モデル」カラムは、デバイスが適用している高頻度用モデルのモデル名を表す。「高頻度用モデル」とは、高頻度レベルが１以上のモデルを指しており、低頻度用モデルは高頻度レベルが０のモデルを指す。「状態」カラムは、機種番号に対応する画像形成装置の状態を表しており、「高頻度送信済」もしくは「高頻度送信中」の状態をとる。「高頻度開始」カラムは、デバイスが高頻度送信指示を受けて高頻度送信を開始する時間を表す。「高頻度停止予定」カラムは、デバイスが高頻度送信を停止する予定の日時を表す。

高頻度送信履歴管理部４０７は、高頻度送信履歴ＤＢ４０６で管理している表Ｃのデータを監視する機能を持つ。高頻度送信履歴を一定周期で常に監視し、現在日時が高頻度送信履歴の高頻度停止予定日時を超えていたら、その履歴に対応する機種番号の画像形成装置に高頻度送信停止指示を、センサーデータ送信指示部４０３に通知する。更に、その履歴の状態を「高頻度送信中」から「高頻度送信済」に変更する。センサーデータ送信指示依頼受付部４０８は、外部から送信指示依頼を受け付け、受け付けた送信指示をセンサーデータ送信指示部４０３に通知する機能を持つ。

故障予測部４０１における低負荷故障予測の処理フローについて、図８のフローチャートを用いて説明する。この処理フローは、図１１のシーケンス図の低精度故障予測フェーズ、高精度故障予測フェーズでの、データ分析装置１１３が通知するメッセージに対応する。

故障予測部４０１は、Ｓ８０１にてデータ蓄積装置から必要なセンサーデータを取得する。センサーデータの取得は、故障予測部４０１が外部データ取得部４０２に問い合わせることで行う。次に故障予測部４０１は、Ｓ８０２にて適用する故障予測モデルの決定を行う。故障予測モデル一覧管理ＤＢ４０５で管理している故障予測モデル一覧から、前のステップで取得したセンサーデータに対して適用するモデルを決定する。

適用モデルの決定はＳ８１１〜Ｓ８１３にて行う。まずＳ８１１にて、高頻度送信履歴ＤＢ４０６に登録されている「適用高頻度用モデル」を適用モデルに決定する。Ｓ８０１で取得したセンサーデータに対応する機種番号の行を、高頻度送信履歴ＤＢ４０６が持つ表Ｃのようなリストの中から探し、見つかったらその行の「適用高頻度用モデル」を適用モデルに決定する。次にＳ８１２にて、「適用続行」がＴＲＵＥのモデルを適用モデルに決定する。Ｓ８１１で決定した全ての適用モデルに対して、適用モデルと同じ「モデルグループ」かつ適用モデルより低い「高頻度レベル」のモデルを全て抽出し、抽出したモデルの中で、「適用続行」がＴＲＵＥのモデルを全て適用モデルに決定する。次にＳ８１３にて高頻度レベルが０のモデルを適用モデルに決定する。Ｓ８１１、Ｓ８１２で決定した全ての適用モデルを確認し、まだ１つもモデルが適用となっていないモデルグループを全て抽出する。そして抽出したモデルグループに関して高頻度レベルが０のモデルを、全て適用モデルに決定する。

Ｓ８０３からＳ８０９までのループで、Ｓ８０２で決定した全てのモデルを適用し、それぞれ処理を行う。まずＳ８０４にて、Ｓ８０１で取得したセンサーデータに対して故障予測モデルを適用する。Ｓ８０５にて、モデル適用の判定結果によって処理を分岐し、異常値を示した場合はＳ８０６に進み、正常値を示したか、もしくはモデルに必要なセンサー情報が不足している場合はＳ８０９に進む。

Ｓ８０６では、適用モデルの「通知内容」の項目を確認し、その内容によって処理を分岐する。通知内容の項目が「高頻度送信指示」の場合はＳ８０７に進み、また「センサーエラー」の場合はＳ８０８に進む。Ｓ８０７では高頻度送信指示を行う。高頻度送信指示は、故障予測部４０１がセンサーデータ送信指示部４０３に依頼することで、センサーデータ送信指示部４０３がデバイス管理装置１１１に直接、高頻度送信指示を依頼する。またこの時、故障予測部４０１はセンサーデータ送信指示部４０３に送信指示を通知する。ここでの送信指示に指定する頻度は、適用モデルに対応する表Ｂの「入力頻度」の値を用い、送信指示に指定する期間は適用モデルに対応する表Ｂの「入力期間」の値を用いる。

Ｓ８０８では、センサーエラーを通知し、高頻度送信停止を指示する。センサーエラーの通知は、故障予測部４０１がセンサーエラー通知部４０４に問い合わせることで、センサーエラー通知部４０４がデバイス管理装置１１１に直接、センサーエラーを通知する。高頻度送信停止の指示は、故障予測部４０１がセンサーデータ送信指示部４０３に対して依頼することで、センサーデータ送信指示部がデバイス管理装置１１１に直接、高頻度送信停止の指示を依頼する。

図５は、実施例１に係るデバイス管理装置１１１のソフトウェア構成図である。デバイス管理装置１１１は、送信指示受付部５０１、センサーエラー通知受付部５０２、デバイス送信指示部５０３、サービスマン指示部５０４、故障通知受付部５０５、故障履歴取得部５０６、故障履歴管理ＤＢ５０７から構成される。

送信指示受付部５０１は、データ分析装置１１３からの高頻度送信指示を受け付ける機能を持つ。データ分析装置１１３からの指示の内容を解釈し、指定された画像形成装置に高頻度送信指示をするように、デバイス送信指示部５０３に依頼することができる。センサーエラー通知受付部５０２は、データ分析装置１１３からのセンサーエラー通知を受け付ける機能を持つ。データ分析装置１１３からの通知の内容を解釈し、サービスマン指示部５０４にセンサーエラーの内容を通知し、高頻度送信の停止指示をデバイス送信指示部５０３に通知することができる。

デバイス送信指示部５０３は、送信指示受付部５０１またはセンサーエラー通知受付部５０２からの指示を受けて、指定された画像形成装置（例えば１２１）に指定された指示を直接通知する機能を持つ。画像形成装置への指示内容は、センサーデータ送信頻度、送信期間、センサーデータ送信停止指示を含む。サービスマン指示部５０４は、センサーエラー通知受付部５０２からの通知を受けて、センサーエラーの内容をサービスマンに直接通知する機能を持つ。

故障通知受付部５０５は、画像形成装置１２１〜１２３から送信される故障履歴を受け付けて、故障履歴管理ＤＢ５０７に登録する機能を持つ。故障履歴取得部５０６は、外部からの故障履歴取得依頼を受け付けて、故障履歴管理ＤＢ５０７に登録されている故障履歴データを返す機能を持つ。故障履歴管理ＤＢ５０７で管理するデータは、例えば下記表Ｄのようなデータである。故障通知受付部５０５が取得した画像形成装置１２１〜１２３からの故障履歴を管理する。

表Ｄの「故障発生日時」カラムは、故障が発生した日時を表す。「機種」カラムは、表Ｂの「機種」カラムと同義である。「機種番号」カラムは、表Ｃの「機種番号」カラムと同義である。「故障コード」カラムは、発生した故障の種類に１対１に対応したコードナンバーである。

図６は、実施例１に係る画像形成装置１２１〜１２３のハードウェア構成図である。コントローラ６０１は画像形成装置全体の制御を行う。具体的には、コントローラ６０１は、センサー群６０３からセンサーデータを獲得し、その値をＨＤＤ６０４に格納する。センサー群６０３は、ここでは画像形成装置内の様々なセンサーの集合を表す。例えば、温感センサーや電圧センサーなどが含まれる。ＨＤＤ６０４はセンサー群６０３から得られるセンサーデータを全て蓄積しておくことができる。Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ（ＮＩＣ）６０２は、ネットワーク１０１〜１０５を介して外部装置とのデータのやり取りを行う。

図７は、実施例１に係る画像形成装置１２１〜１２３のソフトウェア構成図である。画像形成装置１２１〜１２３は、送信指示受付部７０１、センサーデータ送信部７０２、デバイス内センサーデータ管理ＤＢ７０３、故障通知部７０４から構成される。送信指示受付部７０１は、デバイス管理装置１１１からのセンサーデータ送信指示を受け付ける機能を持つ。デバイス管理装置１１１からの指示内容は、センサーデータ送信頻度、センサーデータ送信期間、センサーデータ送信停止指示を含み、指示内容によってセンサーデータ送信部７０２に指示を出す。

センサーデータ送信部７０２は、データ蓄積装置１１２にセンサーデータを直接送信する機能を持つ。送信指示受付部７０１からの指示に応じて、デバイス内センサーデータ管理ＤＢ７０３が持つデータを、データ蓄積装置１１２に直接送信することができる。デバイス内センサーデータ管理ＤＢ７０３で管理するデータは、例えば下記表Ｅのようなデータである。画像形成装置内のセンサー群６０３によって取得されるセンサーデータが記録される。故障通知部７０４は、画像形成装置１２１〜１２３内で発生した各種故障を検知して、デバイス管理装置１１１に通知する機能を持つ。

表Ｅの「データ取得日時」カラム、「センサーＭ」〜「センサーＯ」カラムは、表Ａの「データ取得日時」カラム、「センサーＭ」〜「センサーＯ」カラムと同意である。

図１２は、実施例１に係るデータ収集装置１１４のソフトウェア構成図である。データ収集装置１１４は、外部データ取得部１２０１、データ取得依頼受付部１２０２、センサーデータ管理ＤＢ１２０３、故障履歴管理ＤＢ１２０４から構成される。外部データ取得部１２０１は、データ蓄積装置１１２またはデータ管理装置１１１からセンサーデータまたは故障履歴を取得する機能を持つ。センサーデータを取得した場合はセンサーデータ管理ＤＢ１２０３に、故障履歴を取得した場合は故障履歴管理ＤＢ１２０４に取得データを登録する。

データ取得依頼受付部１２０２は、分析者端末１１５からデータ取得依頼を受け付け、センサーデータ管理ＤＢ１２０３または故障履歴管理ＤＢ１２０４に登録されているデータを返す機能を持つ。センサーデータ管理ＤＢ１２０３は、表Ｅと同じような、データ取得日時と各センサーの値を管理する。故障履歴管理ＤＢ１２０４は、表Ｄと同じような、「故障発生日時」、「機種」、「機種番号」、「故障コード」の値を管理する。

図１３は、実施例１に係る分析者端末１１５のソフトウェア構成図である。分析者端末１１５は、外部データ取得部１３０１、送信指示依頼部１３０２、故障予測モデル作成ツール１３０３及び故障予測モデル実装ツール１３０４から構成される。外部データ取得部１３０１は、データ収集装置１１４からセンサーデータまたは故障履歴を取得する機能を持つ。送信指示依頼部１３０２は、故障予測モデルを作成するに辺り必要なセンサーデータを取得するために、データ分析装置１１３に対してセンサーデータ送信指示を依頼する機能を持つ。

故障予測モデル作成ツール１３０３は、分析者によって、外部データ取得部１３０１を用いて取得したセンサーデータまたは故障履歴を用いて故障予測モデルを作成することができるツールである。作成方法は、機械学習による作成か、単純な数式での表現か、またはそれ以外の方法でも構わない。故障予測モデル実装ツール１３０４は、故障予測モデル作成ツール１３０３で作成した故障予測モデルを、データ分析装置１１３内に実装するためのツールである。例えば、分析者は故障予測モデル作成ツール１３０３で故障予測モデルを作成し、その後分析者は作成したモデルを故障予測モデル実装ツール１３０４を使用して、データ分析装置１１３に実装することができる。ここで述べる実装というのは、例えばプログラムを記述することである。

以上、実施例１により、世界中に存在する大量の画像形成装置からデータを取得する際のデータ受信部負荷を軽減することが出来る。

＜実施例２＞
実施例１で説明したデータ分析装置１１３で適用する故障予測モデルは、必ずしも精度が高いとは限らない。世界中の大量の画像形成装置から得られたセンサー情報に対して、ある故障予測モデルを適用したときに、モデル実装者の予想に反してその故障予測モデルが容易に異常判定を示してしまう場合がある。すると、大量の画像形成装置に対して高頻度送信指示を通知することになり、データ蓄積装置１１２の受信帯域や、記憶領域を圧迫するという課題がある。

上記課題を解決するため、実施例２では、同時に高頻度送信が可能な画像形成装置の総数（台数）の上限値を設けるシステムについて説明する。所定の上限値を超えた分の画像形成装置を待ち状態として記憶しておき、あるタイミングで待ち状態から「高頻度送信中状態」に遷移させることで、上記課題を解決する。なお、以降に記述する事項以外は実施例１と同様の構成を有する。

図４の高頻度送信履歴ＤＢ４０６が管理するデータは、実施例１で説明した表Ｃを拡張した、下記表Ｆを持つことになる。

表Ｃから拡張されたのは、「状態」カラムに「待ち」状態が追加された点と、新たに「待ち開始」カラムが追加された点であり、あとは表Ｃと同じ構成である。表Ｆの「状態」カラムは、機種番号に対応する画像形成装置の状態を表しており、「高頻度送信済」、「高頻度送信中」、「待ち」状態をとる。「待ち開始」カラムは、高頻度送信中の画像形成装置の総数が上限値を超えたときに待ち状態になった画像形成装置が、待ち状態になった時点の開始日時を表す。

センサーデータ送信指示部４０３は以下の機能を拡張する。センサーデータ送信指示部４０３は、実施例１で説明した機能に加え、同時に高頻度送信が可能な画像形成装置の総数の上限値を持つ。故障予測部４０１から送信指示を通知されたときに、その送信指示によって高頻度送信履歴ＤＢ４０６に登録されている高頻度送信中の画像形成装置の総数が上限値を超えてしまう場合に、その画像形成装置を待ち状態にして、高頻度送信履歴ＤＢ４０６に登録する。

高頻度送信履歴管理部４０７は以下のように拡張される。高頻度送信履歴管理部４０７は、実施例１で説明した機能に加え、同時に高頻度送信が可能な画像形成装置の総数の上限値を持つ。高頻度送信履歴管理部４０７が高頻度送信履歴ＤＢ４０６に登録されている画像形成装置の状態を遷移させるフローに関して、図９のフローチャートを用いて説明する。

図９は、高頻度送信履歴管理部４０７が高頻度送信履歴ＤＢ４０６に登録されている画像形成装置の状態を遷移させる処理フローのフローチャートである。高頻度送信履歴管理部４０７は、図９で示すフローのＳｔａｒｔからＥｎｄまでを、短い周期で常に繰り返し実行する。図１１のシーケンス図との対応で述べると、低精度故障予測フェーズ、高精度故障予測フェーズ内の任意のタイミングで、図９のフローチャートが短い周期で繰り返し実行される。

まずＳ９０１にて、高頻度送信履歴管理部４０７は高頻度送信履歴ＤＢ４０６で管理している表Ｆの中で、現在日時が高頻度停止予定を超えた画像形成装置が存在するかどうかを判定する。判定の結果、該当する画像形成装置が存在する場合はＳ９０２に進み、存在しない場合はフローを終了する。Ｓ９０２では、現在日時が高頻度停止予定の日時を超えている画像形成装置の状態を高頻度送信済に遷移させる。表Ｆの項目「状態」の更新を行い、その画像形成装置への高頻度送信停止指示を、センサーデータ送信指示部４０３に通知する。次にＳ９０３にて、待ち状態の画像形成装置が存在するかどうかを判定し、存在する場合はステップＳ９０４に進み、存在しない場合はフローを終了する。Ｓ９０４では、待ち状態の画像形成装置の中で最も「待ち開始日時」が古い画像形成装置の状態を、高頻度送信中に遷移させる。表Ｆの項目「状態」の項目を更新し、その画像形成装置への高頻度送信指示を、センサーデータ送信指示部４０３に通知する。

以上、実施例２により、設定した上限値以上数の画像形成装置からの高頻度送信を防止することができ、データ蓄積装置１１２の受信帯域や記憶領域の圧迫を軽減することができる。

＜実施例３＞
背景として、故障予測システムと、サービスマンの保守、点検作業のための定期出動の関係について述べておく。図４の故障予測部４０１での故障予測の結果、センサーエラーと判定されたら、データ分析装置１１３からデバイス管理装置１１１にセンサーエラーを通知し、図５のサービスマン指示部５０４がサービスマンに直接センサーエラーを通知する。しかしサービスマンにセンサーエラーを通知した時点で、必ずしもセンサーが故障しているとは限らないため、センサーエラーを通知されたサービスマンが即座に該当する画像形成装置の設置場所へ出動するとは限らない。サービスマンは各画像形成装置の設置場所へ定期的に出動することがあり、その際に前記センサーエラー通知情報を基に、近い将来故障する可能性が高い個所に対して、部品交換や清掃を行う。この事から、サービスマンが定期出動する前に出動先の画像形成装置に対する故障予測を完了していることが望ましい。

実施例２では、高頻度送信履歴管理部４０７が表Ｆに登録されている高頻度送信中状態の画像形成装置を高頻度送信済状態に遷移させるタイミングで、待ち状態の画像形成装置を高頻度送信中状態に遷移させる処理を行う。この時、どの待ち状態の画像形成装置を高頻度送信中状態に遷移させるかの選択を、「待ち開始日時」のみを参考に行っているため、サービスマンの定期出動に間に合うかという観点で考えたときに、上記選択が最適なものになるとは限らない。

上記課題を解決するため、実施例３では、高頻度送信履歴管理部４０７が画像形成装置を待ち状態から高頻度送信中に遷移させる際、「待ち開始日時」に加えて「サービスマンの定期出動予定」（保守スケジュール）も選択の基準とするシステムについて説明する。実施例２との違いは、図９のフローチャートにのみあるので、図９のフローチャートを拡張した図１０について説明する。

図１０は、サービスマンの定期出動予定も考慮した、高頻度送信履歴管理部４０７が高頻度送信履歴ＤＢ４０６に登録されている画像形成装置の状態を遷移させるフローのフローチャートである。高頻度送信履歴管理部４０７は、図１０で示すフローのＳｔａｒｔからＥｎｄまでを、短い周期で常に繰り返し実行する。図１１のシーケンス図との対応で述べると、図９と同様、低精度故障予測フェーズ、高精度故障予測フェーズ内の任意のタイミングで、図１０のフローチャートが短い周期で繰り返し実行される。

まずＳ１００１にて、高頻度送信履歴管理部４０７は高頻度送信履歴ＤＢ４０６で管理している表Ｆの中で、現在日時が高頻度停止予定を超えた画像形成装置が存在するかどうかを判定する。判定の結果、該当する画像形成装置が存在する場合はＳ１００２に進み、存在しない場合はフローを終了する。Ｓ１００２では、現在日時が高頻度停止予定の日時を超えている画像形成装置の状態を高頻度送信済に遷移させる。表Ｆの項目「状態」の更新を行い、その画像形成装置への高頻度送信停止指示をセンサーデータ送信指示部４０３に通知する。次にＳ１００３にて、待ち状態の画像形成装置が存在するかどうかを判定し、存在する場合はＳ１００４に進み、存在しない場合はフローを終了する。

Ｓ１００４では、待ち状態の画像形成装置の中で、次にサービスマンが定期出動するまでに高頻度送信が完了する画像形成装置を抽出する。そしてＳ１００５にて、Ｓ１００４で抽出した画像形成装置の中で、最も「待ち開始日時」が古い画像形成装置の状態を、高頻度送信中に遷移させる。また表Ｆの項目「状態」の項目を更新し、その画像形成装置への高頻度送信指示を、センサーデータ送信指示部４０３に通知する。

以上、実施例３により、サービスマンが定期出動する前に出動先の画像形成装置に対する故障予測が完了する可能性が増加し、サービスマンが定期出動した際に部品交換や清掃を行うかどうかの判断が可能となる可能性が増加する。

実施例３では、どの待ち状態の画像形成装置を高頻度送信中状態に遷移させるかの選択を、「サービスマンの定期出動予定」、「待ち開始日時」を考慮して実行するという説明をした。何の情報を考慮して選択するかということは、他の視点でも色々と考えることができる。例えばモデル作成者の視点で考えると、適用の少ない高頻度モデルがあると、その高頻度モデルの適用に対するフィードバックが得られない。この課題を解決するために、適用モデルの適用数が均一になるように、待ち状態から高頻度送信中状態に遷移させる方法も考えられる。

＜実施例４＞
画像形成装置１２１〜１２３は、デバイス管理装置１１１から送信指示を受けてデータ蓄積装置１１２にセンサーデータを送信する。実施例１〜３において、デバイス管理装置１１１からの送信指示は送信頻度と送信期間を指定するのみなので、画像形成装置１２１〜１２３は、データ分析装置１１３で適用する故障予測モデルに必要なデータ以外にもセンサーデータを送信する可能性がある。その場合、データ蓄積装置の回線の帯域や、記憶容量を圧迫するという課題がある。

上記課題を解決するため、実施例４では、デバイス管理装置１１１が通知する送信指示に関して、送信するセンサー種類も指定できるようなシステムについて説明する。ここでの送信指示とは、デバイス管理装置１１１から画像形成装置１２１〜１２３への送信指示、デバイス管理装置１１１からデータ分析装置１１３への送信指示を含む。以下、実施例１〜３と異なる構成について説明する。

図４のセンサーデータ送信指示部４０３は、指定した画像形成装置（例えば１２１）に対して指定した頻度、期間に加え、指定したセンサー種類のセンサーデータを送信するよう、デバイス管理装置１１１に通知する機能を持つ。引数の設定の仕方により、送信停止の指示も可能である。図５の送信指示受付部５０１は、センサーデータ送信指示部４０３から指定された頻度、期間、センサー種類の内容を解釈し、指定された画像形成装置に高頻度送信指示をするようにデバイス送信指示部５０３に依頼することができる。デバイス送信指示部５０３は、送信指示受付部５０１またはセンサーエラー通知受付部５０２からの指示を受けて、指定された画像形成装置（例えば１２１）に指定された指示を直接通知することができる。画像形成装置への指示内容は、センサーデータ送信頻度、センサーデータ送信期間、送信センサー種類、センサーデータ送信停止指示を含む。

図７の送信指示受付部７０１は、デバイス管理装置１１１からのセンサーデータ送信指示を受け付ける機能を持つ。デバイス管理装置１１１からの指示内容は、センサーデータ送信頻度、センサーデータ送信期間、送信センサー種類、センサーデータ送信停止指示を含み、指示内容によってセンサーデータ送信部７０２に指示を出す。センサーデータ送信部７０２は、データ蓄積装置１１２にセンサーデータを直接送信する機能を持つ。送信指示受付部７０１からの指示に応じて、デバイス内センサーデータ管理ＤＢ７０３が持つデータをデータ蓄積装置１１２に直接送信することができる。送信指示受付部７０１からの指示で通知されたセンサー種類に従って、デバイス内センサーデータ管理ＤＢ７０３が持つデータの中から指定されたセンサー種類のデータのみを抽出し、データ蓄積装置１１２に送信する。

図８のフローチャート中、Ｓ８０７のみ拡張部分がある。Ｓ８０７では高頻度送信指示を行う。高頻度送信指示は、図４の故障予測部４０１がセンサーデータ送信指示部４０３に対して依頼することで、センサーデータ送信指示部４０３がデバイス管理装置１１１に直接、高頻度送信指示を依頼する。またこの時、故障予測部４０１はセンサーデータ送信指示部４０３に送信指示を通知する。ここでの送信指示に指定する頻度は、適用モデルに対応する表Ｂの「入力頻度」の値を用い、送信指示に指定する期間は、適用モデルに対応する表Ｂの「入力期間」の値を用いる。また、送信指示に指定するセンサー種類は、適用モデルに対応する表Ｂの「入力センサー」の値を用いる。

以上、説明した個所の拡張を行うことで、センサー種類も指定した送信指示を行うことができ、データ蓄積装置の回線帯域や、記憶領域の圧迫を軽減することができる。

＜その他の実施例＞
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

Claims (6)

1. １以上の情報処理装置を含み、複数のネットワークデバイスから収集したデータを分析する分析システムであって、
   第１の分析の結果に基づいて、前記複数のネットワークデバイスの中から、第２の分析のために必要なデータを収集する対象とするネットワークデバイスを決定する決定手段と、
   前記第１の分析におけるデータ収集の頻度より高い頻度で、前記決定されたネットワークデバイスから前記第２の分析に必要なデータが収集されるよう制御する制御手段と、
   前記決定されたネットワークデバイスから収集されたデータを用いて前記第２の分析を実行する実行手段と、を有することを特徴とする分析システム。
2. 前記第１の分析の結果に従い、前記決定されたネットワークデバイスの数が所定の上限に達する頻度に応じて、前記第１の分析のためのモデルに対する変更を促す通知を行う通知手段をさらに有することを特徴とする、請求項１に記載の分析システム。
3. 前記決定手段は、前記ネットワークデバイスの保守のスケジュールに従い、前記第２の分析のために必要なデータを収集する対象とするネットワークデバイスを決定することを特徴とする、請求項１または２に記載のシステム。
4. 前記ネットワークデバイスは、画像形成装置、デジタル医療機器、ネットワークカメラ、ロボット、車載端末、空調を含むことを特徴とする、請求項１乃至３のいずれか１項に記載の分析システム。
5. 前記データは、センサーデータ、カウンタ情報、ログ情報の少なくとも１つを含むことを特徴とする、請求項１乃至４のいずれか１項に記載の分析システム。
6. １以上の情報処理装置を含み、複数のネットワークデバイスから収集したデータを分析する分析システムにおける分析方法であって、
   第１の分析の結果に基づいて、前記複数のネットワークデバイスの中から、第２の分析のために必要なデータを収集する対象とするネットワークデバイスを決定するステップと、
   前記第１の分析におけるデータ収集の頻度より高い頻度で、前記決定されたネットワークデバイスから前記第２の分析に必要なデータが収集されるよう制御するステップと、
   前記決定されたネットワークデバイスから収集されたデータを用いて前記第２の分析を実行するステップと、を有することを特徴とする分析方法。

Images