(57)【要約】【課題】  従来、ビックデータの分析に際して、適切なクレンジング処理を行える仕組みが無かった。【解決手段】  ネットワークを介して収集されたネットワーク機器に関する大量のデータをデータベースで蓄積して、管理するデータ活用システムであって、前記第１のデータベースで蓄積された大量のデータに含まれる、時系列で連続性のあるデータを特定するためのルールに対応する種類のデータの中で、当該ルールに従い連続性があると判定されたデータに対して同じ識別情報を付与することを特徴とする。【選択図】  図４
2016024486.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して収集されたネットワーク機器に関する大量のデータを第１のデータベースで蓄積して、管理するデータ活用システムであって、
時系列で連続性のあるデータを特定するためのルールを管理する第２のデータベースと、
前記第１のデータベースで蓄積された大量のデータに含まれる前記第２のデータベースで管理されたルールに対応する種類のデータの中で、当該ルールに従い連続性があると判定されたデータに対して同じ識別情報を付与する付与手段と、
前記付与手段により識別情報が付与されたデータを管理する第３のデータベースと、を有することを特徴とするデータ活用システム。
【請求項２】
前記付与手段は、前記ルールに従い連続性があると判定される複数のデータ群が存在する場合には、それらデータ群の間では異なる識別情報を付与することを特徴とする請求項１に記載のデータ活用システム。
【請求項３】
前記ルールでは、対象のデータの種類と、連続性を検証するためのデータの受信間隔が定義されていることを特徴とする請求項１または２に記載のデータ活用システム。
【請求項４】
前記ルールでは、さらに、前記受信間隔に対して許容できる誤差の範囲が定義されていることを特徴とする請求項３に記載のデータ活用システム。
【請求項５】
前記データ活用システムに対して、前記付与手段により付与された識別情報を用いたデータの要求があった場合に、当該識別情報を用いて抽出されるデータを応答する応答手段をさらに有することを特徴とする請求項１乃至４の何れか１項に記載のデータ活用システム。
【請求項６】
ネットワークを介して収集されたネットワーク機器に関する大量のデータを第１のデータベースで蓄積して、管理するデータ活用システムにおける制御方法であって、
前記第１のデータベースで蓄積された大量のデータに含まれる、時系列で連続性のあるデータを特定するためのルールに対応する種類のデータの中で、当該ルールに従い連続性があると判定されたデータに対して同じ識別情報を付与する付与工程を有することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビックデータの中から、分析のために、連続する時系列データを容易に抽出するための技術に関する。
【背景技術】
【０００２】
近年、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）の処理能力の向上やサーバー仮想化技術の発展が著しい。これにより、アプリケーションのログデータや画像形成装置などのネットワーク機器に取り付けられたセンサーデータのような様々データが含まれる、いわゆるビッグデータを積極的に分析・活用しようとする動きが活発化している。
【０００３】
ビッグデータ分析は、１つの部門のみが単一のユースケースで全データを利用するだけでなく、複数の部門がそれぞれ異なるユースケースのために分析を行うケースも多い。従って、各部門で参照するテーブル・分析期間・分析間隔はそれぞれ異なる。ここでの分析期間・分析間隔とは、それぞれ例えば、時系列データをグラフ化する際の時系列の範囲・明細の度合いのことである。加えて、各ユースケース内でも分析期間・分析間隔を変化させることで、最適な分析手法を確立していくことが必要である。例えば、ビッグデータを用いて機械学習を行う場合は、最も高精度な手法が最適な分析手法ということになる。最適な分析手法を確立することが、効率的にデータを活用することにつながる。さらに、機械学習によって精度向上を図るようなユースケースの場合は、学習に用いるデータの取捨選択を繰り返しながら、試行錯誤する必要がある。この試行錯誤において、学習データを作りなおす必要があるため、その度に元データを格納しているデータベースに対してクエリしなくてはならない。
【０００４】
ここで、分析に利用するデータを画像形成装置が定期的に出力するセンサーデータの場合を想定し、このセンサーデータに対して時系列分析を行う場合を考える。センサーデータを出力している画像形成装置の電源がオフであった場合や、ネットワークの瞬断等でセンサーデータを正常に送信できなかった場合は、時系列で見るとデータに欠損が発生する。例えば、時系列分析を機械学習の手法を用いて行う場合に、このように時系列的にデータが欠損したデータは利用できない。
【０００５】
特許文献１では、欠損データの前後少なくともいずれか一方のデータを入力とする補間関数を用いて、欠損データを補間する方法を開示している。これにより、時系列データに欠損がある場合でも、指定した分析期間で必ず連続したデータを取得することができる。
【０００６】
特許文献２では、サンプリング間隔ΔＴ０の時系列データから、ΔＴ０よりも長い間隔のΔＴ１〜ΔＴｍの時系列データを抽出し、ΔＴ０〜ΔＴｍの全データを保持する方法を開示している。これにより、分析間隔を変えたデータを比較的容易に取得することができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−３１３７８号公報
【特許文献２】特開２０００−４８０４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載の方法において、補間関数を利用するということは補間された時系列データには誤差が含まれるため、データの信頼性が低下する。すなわち、分析精度（例えば、機械学習を行う場合には学習精度）が低下するという課題がある。また、連続してデータが欠損した場合は、補間の誤差も大きくなる可能性が高いため、その場合はデータの信頼性の低下も大きいと考えられる。
【０００９】
また、特許文献２に記載の方法において、容易に分析間隔を変えて時系列データを取得することができるが、時系列的に連続するデータを容易に抽出することができない。ここで、表Ａ、表Ｂを用いて、時系列データの分析のために時系列的に連続するデータのみを抽出する方法を具体的に説明し、さらに抽出が容易にできない理由を説明する。
【００１０】
表Ａは、画像形成装置にとりつけられたセンサーＭ、Ｎ、Ｏの値を１時間毎に収集した際の各センサーデータの例である。表Ａの「データ取得日時」カラムは、画像形成装置からセンサーデータを取得した日時である。表Ａの「機種」カラムは画像形成装置の機種名を表す。表Ａの「機種番号」カラムは、画像形成装置の機種番号を表し、各画像形成装置に対してユニークな値である。表Ａの「センサーＭ」「センサーＮ」「センサーＯ」カラムは、「機種番号」で一意に特定される画像形成装置の「データ取得日時時点」の各センサー値を表す。センサー値とは、例えば画像形成装置内の温度、湿度、部品にかかる電圧などがある。例えば、機種番号がＡＢ００１で表される画像処理装置は、センサーＭ、Ｎ、Ｏの値を１時間ごとに取得しており、またデータ取得日時が「２０１４／３／３  １：００」「２０１４／３／３  １０：００」のデータについては欠損していることを表す。ただし、表Ａ中では欠損データについて（データ欠損）というように擬似的に表しているが、実際には表Ａ中には存在しない行である。
【００１１】
また、表Ｂは画像形成装置で発生したエラー情報の例を表す。表Ｂの「機種」「機種番号」カラムは表Ａの「機種」「機種番号」と同意である。表Ｂの「エラーコード」カラムは発生したエラーの各現象に対して一意になるように定義したコードである。表Ｂの「エラー発生日時」カラムは「機種番号」で特定される画像形成装置が「エラーコード」で表されるエラーを発生させた日時を表す。
【００１２】
【表１】
2016024486.tif 000003
【００１３】
【表２】
2016024486.tif 000004
【００１４】
ここで、表Ｂのエラーコードの値が１００１０で表されるエラーの発生原因を、表Ａにおけるエラー発生前６時間のセンサーＭ、Ｎ、Ｏのデータから時系列分析する場合を想定する。すなわち、時系列分析に用いるデータはエラーコードが１００１０で表されるエラーが発生した画像形成装置の、エラー発生直前６時間分のセンサーＭ、Ｎ、Ｏのうち、１時間間隔で欠損なく取得できているデータ群である。表Ｂのエラー発生日時「２０１４／３／３  ９：２２」のエラーに対応する直前６時間分のセンサーＭ、Ｎ、Ｏのデータは、表Ａの「２０１４／３／３  ４：００」から「２０１４／３／３  ９：００」までのデータであり、欠損なく取得できている。しかし、表Ｂのエラー発生日時「２０１４／３／３  ２：１１」のエラーに対応する直前６時間分のセンサーＭ、Ｎ、Ｏのデータは、表Ａの「２０１４／３／２  ２１：００」から「２０１４／３／３  ２：００」までのデータであるが、「２０１４／３／３  １：００」のデータが欠損している。すなわち、時系列分析に利用できるデータは、時系列的に欠損なく取得できている前者データであり、欠損のある後者のデータは利用できない。
【００１５】
ここで、想定する時系列分析を行うためには、表Ｂのエラーコードが１００１０のエラー全てに対して、表Ａのエラー発生直前６時間のセンサーＭ、Ｎ、Ｏの値から、連続するデータのみを抽出する必要がある。ここで、収集したデータから分析に必要なデータを抽出したり、補完したりするといった処理をクレンジング処理と呼ぶ。本発明では、とくに、分析に必要なデータを抽出する処理をクレンジング処理と呼んでいる。
【００１６】
このクレンジング処理を行うためには、まず第１の処理として表Ｂのエラーコードが１００１０であるエラー全てに対して発生直前１時間前のセンサーＭ、Ｎ、Ｏの値のデータが存在するかどうかを表Ａに対してクエリする。次に、第２の処理として、前記第１の処理にてセンサーＭ、Ｎ、Ｏの値のデータが表Ａ中に存在した各エラーに対して発生２時間前のセンサーＭ、Ｎ、Ｏの値のデータが存在するかどうかを表Ａに対してクエリする。この第１、第２のような処理を計６回繰り返す、すなわち表Ａのエラー発生直前１、２、…、６時間分のセンサーＭ、Ｎ、Ｏの値のデータが表Ｂ中に存在するかどうかを全てクエリして確認することで、抽出すべきデータを確定することができる。
【００１７】
以上の例はクレンジング処理方法の一例であるが、特許文献２に記載の方法については、何度もクエリする必要があるため非常に非効率である。また、ビッグデータを扱う場合はデータ量も膨大であるためクレンジング処理にかかる時間も膨大になる。
【００１８】
本発明は、上記課題を考慮し、より効率的にクレンジング処理を行える仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１９】
上記課題を解決するための、本発明におけるデータ活用システムは、ネットワークを介して収集されたネットワーク機器に関する大量のデータを第１のデータベースで蓄積して、管理するデータ活用システムであって、時系列で連続性のあるデータを特定するためのルールを管理する第２のデータベースと、前記第１のデータベースで蓄積された大量のデータに含まれる前記第２のデータベースで管理されたルールに対応する種類のデータの中で、当該ルールに従い連続性があると判定されたデータに対して同じ識別情報を付与する付与手段と、前記付与手段により識別情報が付与されたデータを管理する第３のデータベースと、を有することを特徴とする。
【発明の効果】
【００２０】
本発明によれば、効率的なクレンジング処理を行える仕組みを提供できる。
【図面の簡単な説明】
【００２１】
【図１】実施例１におけるデータ活用システムの全体構成の例を表す。
【図２】実施例１におけるサーバーコンピュータ、クライアント端末の構成例を示す図である。
【図３】実施例１におけるデータ蓄積装置のソフトウェア構成図である。
【図４】実施例１におけるシーケンスＩＤを付与する処理の流れを表すフローチャートである。
【図５】本発明を適用した場合のクエリの例を示す。
【発明を実施するための形態】
【００２２】
以下、本発明を実施するための形態について図面を用いて説明する。
【００２３】
（実施例１）
図１は、ビッグデータの蓄積、管理、クレンジング、分析、提供を行うためのデータ活用システムの全体構成の例を示す図である。
【００２４】
図１において、クライアント端末１１０、１１１、データ分析装置１１５、１１６、デバイス管理装置１３１、データ蓄積装置１３２、画像形成装置１２１〜１２３はネットワーク１０１〜１０６を介して接続されている。ネットワーク１０１〜１０６としては、例えば、インターネットやＬＡＮ、ＷＡＮ、電話回線等が適用できる。ネットワーク１０１〜１０６は、データの送受信が可能であればよい。本発明では、例えば、ネットワーク１０６はインターネット、ネットワーク１０１〜１０５は企業内ネットワークやサービスプロバイダーのネットワークを示す。デバイス管理装置１３１、データ蓄積装置１３２、データ分析装置１１５、１１６はサーバーコンピュータとして実現される。
【００２５】
デバイス管理装置１３１は、画像形成装置１２１〜１２３で発生するエラー履歴情報や、各種カウンタ情報などを収集し、収集した各種情報をデータ蓄積装置１３２に対して提供する。また、画像形成装置１２１〜１２３は、自身に設置されたセンサー値を取得し、データ蓄積装置１３２に対して、直接送信することができる。データ蓄積装置１３２は、デバイス管理装置１３１から取得した情報及び画像形成装置１２１〜１２３から受信した情報を蓄積する。データ分析装置１１５、１１６は、データ蓄積装置１３２から各ユースケースに必要なデータのみを取得し、必要なＥＴＬ（Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄ）処理、クレンジング処理を行うことで、データを分析しやすい形に整形し、保存する。以降、本発明のサーバーコンピュータのそれぞれの機能は、単体のサーバー又は単体の仮想サーバーによって実現しても構わないし、複数のサーバー又は複数の仮想サーバーによって実現しても構わない。あるいは複数の仮想サーバーが単体のサーバー上で実行されていても構わない。
【００２６】
クライアント端末１１０、１１１は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータアシスタント）等から成るが、プログラムの実行環境が内蔵された携帯電話、タブレット端末であってもよい。クライアント端末１１０、１１１は、データ分析ツール等のプログラムを実行する環境が内蔵されている。ビッグデータ活用を行うユーザは、クライアント端末１１０、１１１にインストールされたデータ分析ツールを用いて、データ分析装置１１５、１１６に保存されているデータを取得し、分析する。
【００２７】
図２（Ａ）は、本発明に係るクライアント端末１１０、１１１やサーバーコンピュータのハードウェア構成図である。
【００２８】
図２（Ａ）において、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）２０２は装置全体の制御を行う。ＣＰＵ２０２はＨａｒｄ  Ｄｉｓｃ  Ｄｒｉｖｅ（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、Ｒａｎｄａｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービスサーバー群のプログラム、ＯＳ、関連プログラム等を格納している。ＨＤＤ２０５には、後述する図４で示す処理を実現するための本発明に特有なプログラムをも格納している。ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０８は外部装置Ｉ／Ｆであり、プリンタ、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ（ＮＩＣ）２０９は、該インターフェース２０９、ネットワーク１１０〜１１２を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２（Ａ）の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。
【００２９】
加えて、ＣＰＵ２０２がＨＤＤ２０５に記憶されているプログラムに基づき処理を実行することによって、図３等に示されるようなソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。
【００３０】
図２（Ｂ）は、本発明の実施形態に係るクライアント端末１１０、１１１のソフトウェア構成図である。データ分析を行うユーザは、図２（Ｂ）におけるデータ分析ツール２１１を利用することで、データ分析装置１１５、１１６へのデータ取得リクエスト等の送信を行い、レスポンスの表示等を行うことでデータを分析する。
【００３１】
図３、４を用いて、データ蓄積装置１３２について説明する。
【００３２】
図３は、本発明に係るデータ蓄積装置１３２のソフトウェアに基づくモジュールの構成の例を示す図である。データ蓄積装置１３２は、データ収集部３０１、データ受付部３０２、データ取得部３０３及びバックグラウンド部３０４、データベース部３０５、ＲＡＷデータ格納部３０６から構成される。データ収集部３０１、データ受付部３０２、データ取得部３０３がバックグラウンド部３０４やデータベース部３０５、ＲＡＷデータ格納部３０６へアクセスすることで、データ蓄積装置１３２が動作する。
【００３３】
データ収集部３０１は、定期的にデバイス管理装置１３１から画像形成装置１２１〜１２３のカウンタデータやエラー履歴データなどのデータを取得する機能を持つ。また、データ受付部３０２は、画像形成装置１２１〜１２３から画像形成装置１２１〜１２３内に設置されているセンサーデータなどを受信する機能を持つ。
【００３４】
データ収集部３０１が、デバイス管理装置１３１からデータを取得した後の処理と、データ受付部３０２が画像形成装置１２１〜１２３からデータを受信した後の処理は共通である。また、本発明では、データ収集部３０１及びデータ受付部３０２を介して受信したデータをオリジナルデータと呼ぶことにする。上記データ収集部３０１とデータ受付部３０２とで共通の処理については後述する。
【００３５】
ＲＡＷデータ管理ＤＢ部３３１は、オリジナルデータを管理するデータベースである。ＲＡＷデータ管理ＤＢ部３３１にて管理するデータ、すなわちオリジナルデータは、例えば、前述の表Ａで示したセンサーデータ及び表Ｂで示したエラー履歴データ、及び、以下の表Ｃのカウンタデータなどである。
【００３６】
【表３】
2016024486.tif 000005
【００３７】
表Ｃの「データ取得日時」カラムは、画像形成装置１２１〜１２３からカウンタデータを取得した日時である。表Ｃの「機種」「機種番号」カラムは、表Ａ、表Ｂの「機種」「機種番号」と同意である。表Ｃの「カウンタＸ」「カウンタＹ」「カウンタＺ」カラムは、「機種番号」で一意に特定される画像形成装置１２１〜１２３の「データ取得日時」時点の各カウンタ値を表す。カウンタ値とは、例えば画像形成装置１２１〜１２３おける印刷枚数、スキャン枚数、部品の回転数などである。例えば表Ｃは、機種番号がＡＢ００１で表される画像処理装置は、カウンタＸ、Ｙ、Ｚの値を１日ごとに取得しており、またデータ取得日時が「２０１４／３／４  ０：００」「２０１４／３／１３  ０：００」のデータについては欠損していることを表す。ただし、表Ｃ中では欠損データについて（データ欠損）というように擬似的に表しているが、実際にＲＡＷデータ管理ＤＢ部３３１には格納されない。
【００３８】
ここでは、ＲＡＷデータ管理ＤＢ部３３１で管理するデータは、オリジナルデータと記載したが、オリジナルデータに対して、何らかのクレンジング処理を行ったデータでもよい。
【００３９】
データ取得部３０３は、データ分析装置１１５、１１６からのデータ取得リクエストを受けつけ、ＲＡＷデータ管理ＤＢ部３３１にて管理されている各種データをデータ取得リクエストの内容に応じて返却する機能を持つ。各機能で実行される処理については後述する。
【００４０】
シーケンスＩＤ管理ＤＢ部３３２は、ＲＡＷデータ管理ＤＢ部３３１に格納されている時系列データが連続しているかどうかを管理するデータベースである。表Ａで表される時系列データ（センサーデータ）に対応する、シーケンスＩＤ管理ＤＢ部３３２にて管理するデータの例を表Ｄに示す。
【００４１】
【表４】
2016024486.tif 000006
【００４２】
表Ｄの「データ取得日時」カラムは、画像形成装置１２１〜１２３からセンサーデータを取得した日時を表し、表Ａの「データ取得日時」カラムと対応する。また表Ｄの「機種」カラムは、表Ａの「機種」と同意である。「ＳｅｑｕｅｎｃｅＩＤ＿１ｈｏｕｒ」、「ＳｅｑｕｅｎｃｅＩＤ＿１ｄａｙ」、「ＳｅｑｕｅｎｃｅＩＤ＿７ｄａｙ」カラム（以降、まとめて「ＳｅｑｕｅｎｃｅＩＤ＿ＸＸ」カラムと呼ぶ）は、時系列データが連続しているかどうかを示すカラムである。「ＳｅｑｕｅｎｃｅＩＤ＿ＸＸ」カラムに格納する値を総称して、本発明ではシーケンスＩＤと呼ぶ。ここで、ＩＤとは識別情報のことである。
【００４３】
「ＳｅｑｕｅｎｃｅＩＤ＿１ｈｏｕｒ」カラムは、データが１時間間隔で連続して取得できていれば同一のシーケンスＩＤを付与する。例えば、表Ａにおいて、データ取得日時が２０１４／３／３  ２：００〜２０１４／３／３  ９：００の間は１時間間隔で欠損なくセンサーＭ、Ｎ、Ｏのデータを取得できているので、同じシーケンスＩＤ（１ｈ−００１０２）を付与している。一方、表Ａにおいて、データ取得日時が２０１４／３／３  １０：００のデータは欠損しているため、表Ｃにおけるデータ取得日時が２０１４／３／３  ９：００のデータと２０１４／３／３  １１：００のデータは「ＳｅｑｕｅｎｃｅＩＤ＿１ｈｏｕｒ」カラムの値は異なる。よって、オリジナルデータの中に、複数の連続性のあるデータ群が存在する場合には、それらのデータ群の間では異なるシーケンスＩＤが付与されていることになる。
【００４４】
「ＳｅｑｕｅｎｃｅＩＤ＿１ｄａｙ」カラムは、データが１日間隔で連続して取得できていれば同一のシーケンスＩＤを付与する。例えば、表Ａにおいて、データ取得日時が２０１４／３／１  １：００〜２０１４／３／２  １：００の間は１日間隔で欠損なくセンサーＭ、Ｎ、Ｏのデータを取得できているので、同じシーケンスＩＤ（１ｄ０１−０００５６）を付与している。一方、表Ａにおいて、データ取得日時が２０１４／３／３  １：００のデータは欠損しているため、表Ｃにおけるデータ取得日時が２０１４／３／２  １：００のデータと２０１４／３／４  １：００のデータは「ＳｅｑｕｅｎｃｅＩＤ＿１ｄａｙ」カラムの値は異なる。同様に「ＳｅｑｕｅｎｃｅＩＤ＿７ｄａｙ」カラムは、データが７日間隔で連続して取得できていれば同一のシーケンスＩＤを付与する。シーケンスＩＤ付与の流れについては後述する。
【００４５】
ルール管理ＤＢ部３３３は、ＲＡＷデータ管理ＤＢ部３３１にて管理しているオリジナルデータのうち、時系列データに対して、シーケンスＩＤの付与ルールを管理するデータベースである。すなわち、「ＳｅｑｕｅｎｃｅＩＤ＿ＸＸ」カラムの種類を管理する。ルール管理ＤＢ部３３３で管理するデータを表Ｅに示す。ネットワークを介して収集された、画像形成装置などのネットワーク機器に関する大量のデータに対する様々な分析のそれぞれにおいて、必要となるデータを容易に抽出できるように、本ルールに従い、シーケンスＩＤの付与が行われることになる。ルールに定義されるデータ種に対して当該ルールが検証され、連続性が確認された場合に、同じシーケンスＩＤの付与が行われる。
【００４６】
【表５】
2016024486.tif 000007
【００４７】
表Ｅの「ＩＤ」カラムはシーケンスＩＤの付与ルールを一意に識別するルールＩＤを表す。表Ｅの「データ種」カラムはＲＡＷデータ管理ＤＢ部３３１で管理する時系列データに対応する。ここでは、表Ａのセンサーテーブルが、表Ｅの「データ種」がセンサーテーブルＡに対応し、表Ｃのカウンタテーブルが、表Ｅの「データ種」がカウンタテーブルＣに対応するとする。表Ｅの「データ種」カラムで規定される各データに対して、「受信間隔」「単位」で規定される間隔で時系列的に受信できているかを検証する。本検証処理は、後述するシーケンスＩＤ付与処理部３２６が行う。例えば、表Ｅの「データ種」がセンサーテーブルＡで規定される時系列データは、「１時間」「１日」「７日」の間隔で受信出来ているかどうかを検証し、シーケンスＩＤを付与する。すなわち、これが表Ｄの「ＳｅｑｕｅｎｃｅＩＤ＿１ｈｏｕｒ」「ＳｅｑｕｅｎｃｅＩＤ＿１ｄａｙ」「ＳｅｑｕｅｎｃｅＩＤ＿７ｄａｙ」に対応する。
【００４８】
データ種管理ＤＢ部３３４は、データ収集部３０１またはデータ受付部３０２を介して受信するオリジナルデータの種類とその取得方法を管理するデータベースである。データ種管理ＤＢ部３３４で管理するデータの例を表Ｈに示す。
【００４９】
【表６】
2016024486.tif 000008
【００５０】
表Ｈの「ＩＤ」カラムは、データ種を一意に識別するＩＤを表す。表Ｈの「管理データ種」カラムは、オリジナルデータの種類を表し、データ収集部３０１及びデータ受付部３０２を介してオリジナルデータは時系列データ、非時系列データを含め全て記載される。表Ｈの「取得方法」カラムは、どのようにして「管理データ種」カラムに記載するデータを取得するかどうかを表している。「取得方法」カラムが「Ｐｕｌｌ」のデータは、データ収集部３０１がデバイス管理装置１３１に対して問い合わせて取得し、「取得方法」カラムが「Ｐｕｓｈ」のデータは、データ受付部３０２が画像形成装置１２１〜１２３から直接受信する。表Ｈの「ファイル名Ｐｒｅｆｉｘ」カラムは、データ収集部３０１又はデータ受付部３０２を介して受信したオリジナルデータのファイル名のＰｒｅｆｉｘを表す。
【００５１】
ＲＡＷデータ格納部３０６は、オリジナルデータをファイルで保存するストレージ領域である。ここで、ＲＡＷデータ格納部３０６は、オリジナルデータに対してクレンジング処理を行ったデータでもよい。
【００５２】
続いて、データ蓄積装置１３２に対してデータを保存する処理の流れについて説明する。
【００５３】
データ収集部３０１は、定期的にデータ種管理ＤＢ部３３４に対して問い合わせを行い、取得方法がＰｕｌｌのデータを取得する。次に、データ収集部３０１は、取得方法がＰｕｌｌの各データについて、順次デバイス管理装置１３１に問い合わせることで対応するデータを受信し、データ保存処理部３２１に対して受信したデータの保存リクエストを行う。同様に、データ受付部は、画像形成装置１２１〜１２３から直接各種情報を受信すると、データ保存処理部３２１に対してデータ保存リクエストを行う。
【００５４】
データ保存リクエスト受けたデータ保存処理部３２１は、クレンジング処理部３２５に対してデータのクレンジング処理リクエストを行う。クレンジング処理とは、例えば、指定されたフォーマットに従っていないデータなどを除外して必要なデータを抽出したり、データ自体を修正したりする処理である。クレンジング処理部３２５は、クレンジング処理が完了したら、データ保存処理部３２１に対してクレンジング済データを返却する。管理対象のデータの種類によっては、クレンジング処理が不要なデータも存在する。
【００５５】
続いて、データ保存処理部３２１は、ＲＡＷデータ書込処理部３２３に対して、クレンジング済データの保存処理リクエストを行う。ＲＡＷデータ書込処理部３２３は、クレンジング済データをＲＡＷデータ格納部３０６、及びＲＡＷデータ管理ＤＢ部３３１に保存し、保存処理が完了したらデータ保存処理部３２１に応答する。
【００５６】
最後に、データ保存処理部３２１は、ＲＡＷデータ管理ＤＢ部３３１に格納したデータに対するシーケンスＩＤ付与をシーケンスＩＤ付与処理部３２６へ依頼する。
【００５７】
図４は、データ蓄積装置１３２のシーケンスＩＤ付与処理部３２６がシーケンスＩＤを付与する処理を説明するためのフローチャートである。この処理は、データ蓄積装置１３２内のＣＰＵ２０２が本処理のためのプログラムを実行することで実現される。
【００５８】
Ｓ４０１で、シーケンスＩＤ付与処理部３２６は、シーケンスＩＤの付与対象となるデータの種類を判定する。データ種の判定は、シーケンスＩＤ付与処理部３２６がデータ種管理ＤＢ部３３４に対して、対象データのファイル名のＰｒｅｆｉｘからデータ種を問い合わせることで行う。次に、Ｓ４０２にて、シーケンスＩＤ付与処理部３２６は、ルール管理ＤＢ部３３３からデータ種に対応するシーケンスＩＤ付与ルールを全て取得する。
【００５９】
以降、Ｓ４０３からＳ４１４までのループでシーケンスＩＤ付与対象データの各行に対して処理を行う。また、Ｓ４０６からＳ４１２までのループで、Ｓ４０２で取得した全ルールに対して処理を行う。本ループは、表Ｄの「ＳｅｑｕｅｎｃｅＩＤ＿ＸＸ」カラムに指定するシーケンスＩＤを１つずつ決定するループである。
【００６０】
Ｓ４０６にて、シーケンスＩＤ付与処理部３２６は、シーケンスＩＤ管理ＤＢ部３３２から、シーケンスＩＤ付与対象データの現在、処理対象としている行のデータの、現在のシーケンスＩＤ付与ルールに合致する前回データを取得する。例えば、データ種が「センサーテーブルＡ」、処理対象としている行のデータのデータ取得日時が「２０１４／３／４  ０：００」かつ機種番号「ＡＢ０００１」、シーケンスＩＤ付与ルールが表Ｅの「ＩＤ」カラムが２の場合を想定する。この時、前回データは、シーケンスＩＤ管理ＤＢ部３３２における機種番号「ＡＢ０００１」「２０１４／３／３  ０：００」のデータである。
【００６１】
続いて、Ｓ４０７にて、シーケンスＩＤ付与処理部３２６は前回データが存在するかどうかを判定する。ここで、前回データが存在する場合には、Ｓ４１０にて、処理対象としている行に対して付与すべきシーケンスＩＤを、前回データのシーケンスＩＤとする。一方、Ｓ４０７にて前回データが存在しないと判定された場合には、Ｓ４０９にて処理対象としている行に対して付与すべきシーケンスＩＤとして新しいシーケンスＩＤを発行する。次に、Ｓ４１１にて、シーケンスＩＤ付与処理部３２６は、付与すべきシーケンスＩＤを時系列データに対して付与する。全シーケンスＩＤ付与ルールに対応するシーケンスＩＤが決定したら、Ｓ４１３にて、現在行の時系列データに対応するシーケンスＩＤをシーケンスＩＤ管理ＤＢ部３３２に挿入する。
【００６２】
次に、データ蓄積装置１３２からデータを取得する処理について説明する。
【００６３】
データ取得部３０３は、データ分析装置１１５、１１６からデータ取得要求を受け取ると、データ取得処理部３２２に対してデータ取得リクエストを送信する。データ取得リクエストを受け付けたデータ取得処理部３２２は、取得リクエストに応じてＲＡＷデータ読込処理部３２４を介してＲＡＷデータ管理ＤＢ部３３１に格納されているデータを取得し、データ取得処理部３２２に返却する。データ取得部３０３は、データ取得処理部３２２を介して取得したデータを、データ分析装置１１５、１１６に対して返却する。
【００６４】
上述した例では、データ蓄積装置１３２がオリジナルデータを受信したタイミングでシーケンスＩＤの付与を行った。しかし、データ分析装置１１５、１１６が図３に示すようなデータ蓄積装置１３２と同様のソフトウェア構成を持つことで、データ分析装置１１５、１１６がデータ蓄積装置１３２からデータを取得したタイミングでシーケンスＩＤの付与を行ってもよい。
【００６５】
本実施例における効果は、データ分析装置１１５、１１６からデータ蓄積装置１３２内のＲＡＷデータ管理ＤＢ部３３１に格納されている連続する時系列データを、１回のクエリで効率的に取得でき、またクエリ条件を簡単に変えることが出来る点である。
【００６６】
例えば、図５（ａ）は、表Ｂの画像形成装置１２１〜１２３におけるエラー発生前の「期間６時間」分の表Ａのセンサーの連続データを「間隔１時間」で取得するクエリを示す。また、図５（ｂ）は、表Ｂの画像形成装置１２１〜１２３におけるエラー発生前の「期間１週間」分の表Ａのセンサーの連続データを「間隔１日」で取得するクエリを示す。このようなクエリ（要求）があった場合には、付与されたシーケンスＩＤを用いて抽出されたデータが応答されることになる。
【００６７】
なお、図５で示す２つのクエリの例では、ｓｅｎｓｏｒ＿ｔａｂｌｅを表Ａのテーブルを表す変数、ｅｒｒｏｒ＿ｔａｂｌｅを表Ｂのテーブルを表す変数とする。
【００６８】
（実施例２）
実施例１において、表Ａの画像形成装置１２１〜１２３でのセンサー情報は、データ取得日時が毎正時になっている。しかし、実際の画像形成装置１２１〜１２３では、例えば印刷ジョブのようにセンサーデータの取得処理以外の処理に優先的にＣＰＵの処理が割り当てられる場合などがあるため、データ取得日時が毎正時から前後することが考えられる。表Ｆは、表Ａの画像形成装置１２１〜１２３でのセンサー情報のデータ取得日時を、実際の画像形成装置１２１〜１２３に合わせたもの（「データ取得日時」カラムが毎正時からずれているもの）である。
【００６９】
【表７】
2016024486.tif 000009
【００７０】
例えば「データ取得日時」カラムが「２０１４／３／３  ５：０８：１０」のセンサーデータは、「２０１４／３／３  ３：５９：５６」のセンサーデータ１時間後に本来は取得されるべきデータが、１時間８分１４秒後に取得されている。このように、本来想定されている間隔からのずれをどの程度、許容するかどうかはデータ活用（または、分析）を行うユースケース次第である。言い換えれば、ユースケースによっては、実施例１で説明したような連続するデータのみを抽出するだけではなく、データ取得日時に大きな誤差を含む不要なデータをクレンジングする必要がある。
【００７１】
そこで、本実施例では、シーケンスＩＤ付与処理部３２６の処理と、ルール管理ＤＢ部３３３とが実施例１とは異なる。
【００７２】
本実施例における、ルール管理ＤＢ部３３３に格納されているデータの例を表Ｇに示す。
【００７３】
【表８】
2016024486.tif 000010
【００７４】
本実施例では、シーケンスＩＤ付与処理部３２６が前述の図４のＳ４０７での処理で、表Ｇで示すルール管理ＤＢ部３３３を参照して判定を行う。具体的には、表Ｇの「データ種」カラムで規定される各データが「受信間隔」「単位」で規定される間隔かつ「許容誤差範囲」「誤差単位」で規定される誤差以内で時系列的に受信できている場合に、前回データが存在すると判定されることになる。
【００７５】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【００７６】
ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【図１】
2016024486.tif 000011
【図２】
2016024486.tif 000012
【図３】
2016024486.tif 000013
【図４】
2016024486.tif 000014
【図５】
2016024486.tif 000015