JP2014137709A - 計算機システム - Google Patents

Abstract

【課題】複数の業種のデータが混在した水平統合型のデータ収集システムにおいて、センサから送信されるデータ量の変化に応じて、データ収集サーバの負荷を低減する。
【解決手段】複数のセンサ、複数のサーバ、及びデータ収集サーバを備える計算機システムであって、データ収集サーバは、計算機システムにおける負荷を監視する負荷監視部と、負荷の監視結果に基づいて、複数のサーバにおけるデータの転送処理の内容を決定し、前記決定されたデータの転送処理の内容を送信する管理部とを有し、管理部は、複数のサーバに適用する転送処理の種別を決定し、転送処理の種別に基づいて、データ収集サーバに転送されるデータのうち、当該転送処理が適用されるデータのリストである処理対象データリストを生成し、決定された転送処理の種別、及び生成された処理対象データリストに基づいて、複数のサーバに適用する転送処理の内容を決定する。
【選択図】図１

Description

本発明は、複数の端末から送信される様々な情報を収集するデータ収集システムに関する。

近年、取引に伴う受発注、売上データ、商品情報、及び顧客情報など、企業における様々なデータのデジタル化が進展している。また、センサデバイス、スマートフォン等の様々なデジタル端末の普及及び利用に伴い、世界中に存在するデータ量は、テラバイトからペタバイト、さらに大容量へと大規模化が進んでいる。

大量、かつ、構造化されていないデータ群は「ビッグデータ」と呼ばれ、先進的な技術を用いて、ビッグデータを収集し、分析し、また、活用することが、今後の社会及びビジネスにおいて期待されている。

昨今の変化の著しい市場環境では、多量のデータを蓄積することが課題となる。ここで大量のデータを収集するためのキーワードとして、Ｍ２Ｍが挙げられる。

Ｍ２Ｍとは、Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅの略語であり、人間の手を介さずに、機械と機械との間でネットワークを介して相互に情報交換を行う仕組みを意味する。Ｍ２Ｍの利用によって、効率に大量のデータを自動的に収集することができると期待される。

従来のＭ２Ｍを用いたデータ収集システムは、業種毎にそれぞれ個別に実現される垂直統合型のシステムであり、収集されるデータ規模が大きなシステム以外では構築コストの問題もあり実現困難であった。また、業種毎の要件に合わせてシステムが実装されているために、他の異なる業種への適用には大きな変更が発生するという問題もある。

今後、多種多様な業種を含めたデータ収集システムの実現が必要となる。つまり、業種に捉われない汎用的、かつ、複数業種のデータをまとめて収集可能とする水平統合型のデータ収集システムの実現が求められる。

また、データ収集システムに接続されるセンサデバイスから収集されるデータ量は、リアルタイムな情報収集の要求などによって莫大なものとなっていくと予測され、多量のデータを効率的に収集するシステムの実現が求められる。

本技術分野の背景技術として、例えば、特許文献１がある。特許文献１には、「センサや制御装置といった様々な機器からのデータを、ネットワークにそのまま流通させると、中央部のネットワークが混雑するという課題に対し、端末装置（１０５〜１１０）と処理サーバ（１０１）の間に設けられるノード（１４１〜１４２）において、端末装置から処理サーバへのパケットを当該ノードが処理するか否かを判定する。処理すると判定した場合、当該ノードは、処理サーバの処理を代行することで、ネットワーク中央部の負荷を低減できる。」ことが記載されている。

国際公開第２０１１／０９９３２０号

水平統合型のデータ収集システムを実現するためには、データ収集サーバにおける、複数のセンサから送信される莫大なデータの収集という問題を解決する必要がある。

業種毎に送信されるデータ量が異なるため、データ収集システムとして、収集されるデータ量に偏りが発生する。収集されるデータ量の偏り、すなわち、データ量の最大値にあわせてシステムを構築することは、コスト的に非常に困難なものであるため、一定時間内で収集されるデータ量の平滑化が必要となる。

特許文献１では、ノードが端末装置から受信した情報を処理することによって、処理サーバの負荷の低減を実現している。特許文献１に記載の技術では、個々の業種において発生するデータ量の低減等には適している。また、垂直統合型のデータ収集システムでは、端末装置から送信されるデータ量の変化が事前に予測容易なため、当該データ量の変化に応じて予めデータの平滑化処理を実行することによって、収集されるデータ量の平準化も可能である。

しかし、水平統合型データ収集システムでは、複数の業種からデータが送信されるため、受信するデータ量の変化の予測が非常に困難である。したがって、様々なセンサから送信されるデータ量の変化に応じて、データ収集システム、特にデータ収集サーバの負荷を低減するシステムの実現が課題となる。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、所定のデータ種別のデータを送信する複数のセンサ、前記複数のセンサから送信されるデータを転送する複数のサーバ、及び、前記複数のサーバから転送されたデータを受信し、受信したデータを蓄積するデータ収集サーバを備える計算機システムであって、前記複数のサーバの各々は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のネットワークインタフェースを有し、前記データ収集サーバは、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、及び前記第２のプロセッサに接続される第２のネットワークインタフェースを有し、前記データ収集サーバは、前記計算機システムにおける負荷を監視する負荷監視部と、前記負荷の監視結果に基づいて、前記複数のサーバにおけるデータの転送処理の内容を決定し、前記決定されたデータの転送処理の内容を送信する管理部と、を有し、前記管理部は、前記複数のサーバに適用する転送処理の種別を決定し、前記決定された転送処理の種別に基づいて、前記データ収集サーバに転送されるデータのうち、当該転送処理が適用されるデータのリストである処理対象データリストを生成し、前記決定された転送処理の種別、及び前記生成された処理対象データリストに基づいて、前記複数のサーバに適用する転送処理の内容を決定することを特徴とする。

前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明によれば、計算機システムの負荷に応じて、動的にデータ収集サーバに対するデータの転送処理を制御することによって、データ収集サーバの負荷を低減し、計算機システムにおけるデータ収集効率を向上させることが可能となる。

本発明の実施例１におけるデータ収集システムの構成例を示す説明図である。 本発明の実施例１のサーバのハードウェア構成を示すブロック図である。 本発明の実施例１のデータ収集サーバが保持するデータ管理テーブルの一例を示す説明図である。 本発明の実施例１のデータ収集サーバが保持するフィルタ状態管理テーブルの一例を示す説明図である。 本発明の実施例１のフィルタ状態管理テーブルに含まれるフィルタ条件の一例を示す説明図である。 本発明の実施例１のデータ収集サーバが保持するデータ受信状態テーブルの一例を示す説明図である。 本発明の実施例１のデータ収集サーバが保持する負荷監視テーブルの一例を示す説明図である。 本発明の実施例１のデータ収集サーバが保持するアルゴリズム選択テーブル１１４の一例を示す説明図である。 本発明の実施例１のフィルタ管理部が実行するアルゴリズム選択処理の一例を説明するフローチャートである。 本発明の実施例１のフィルタ管理部がデータ量削減のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。 本発明の実施例１のフィルタ管理部がデータ数削減のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。 本発明の実施例１のフィルタ管理部がデータ集約のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。 本発明の実施例１の中間サーバが保持するデータ振分けテーブルの一例を示す説明図である。 本発明の実施例１の中間サーバが保持する基本フィルタテーブルの一例を示す説明図である。 本発明の実施例１の中間サーバのデータ振分け部が実行するデータ振分け処理の一例を説明するフローチャートである。 本発明の実施例１の中間サーバの基本データフィルタ部が実行するフィルタ処理の一例を説明するフローチャートである。 本発明の実施例１のデータ収集システムにおけるデータ数集約のアルゴリズムにしたがって実行されるフィルタ制御の流れを説明するシーケンス図である。 本発明の実施例２におけるデータ収集システムの構成例を示す説明図である。 本発明の実施例２のデータ収集サーバが保持するリソース管理テーブルの一例を示す説明図である。 本発明の実施例２のフィルタ管理部がデータ集約のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。 本発明の実施例２のステップＳ２００２において実行される処理の詳細を説明するフローチャートである。

以下、実施例を図面を用いて説明する。

まず、水平統合型のデータ収集システムの課題について説明する。

一般的に、データ収集サーバにデータを送信するセンサは、時間帯によって収集されるデータのデータ数又はデータ量がほとんどない変化しない静的センサと、時間帯によって収集されるデータのデータ数又はデータ量が変化する動的センサとに分けられる。

静的センサから送信されるデータは、電力利用量、温度、及び湿度情報等の一定の時間間隔で送信されるデータであり、送信されるデータ数又はデータ量も一日を通して一定となる。一方、動的センサから送信されるデータは、人又はモノの移動に伴って送信される位置情報等であり、送信されるデータ数又はデータ量も一日のうちで変化する。

異なる業種のデータを扱う場合、水平統合型のデータ収集システムでは、複数の業種のデータを処理する必要がある。一方、複数の業種のデータの処理量が平滑化可能な組合せである場合、単位時間あたりのデータ処理数又はデータ処理量は一定となる。しかし、複数の業種のデータの処理量が平準化できない組合せでは、データ収集サーバの負荷が増大する。

また、動的センサを含むようなデータ収集システムでは、センサから送信されるデータのデータ数又はデータ量が変動するため予測することができない。

そこで、本発明では以下で説明するような構成及び処理によって、データ収集サーバの負荷を平滑化し、かつ、動的なデータ数又はデータ量の変化に対応可能なデータ収集システムを実現する。

実施例１では、データ収集システムにおいて、センサから送信されるデータのデータ量又はデータ数の増大に伴って、中間サーバに対してフィルタの設定を行い、データ収集サーバに送信するデータ量を削減することによって、データ収集サーバの負荷を低減する。ここで、フィルタの設定とは、所定のデータにフィルタ処理が実行されるように設定することを意味する。

図１は、本発明の実施例１におけるデータ収集システムの構成例を示す説明図である。

本実施例におけるデータ収集システムは、データ収集サーバ１００、複数の中間サーバ１２０、及び複数のセンサ１３０から構成される。

データ収集サーバ１００は、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、又はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワークを介して、複数の中間サーバ１２０と接続される。なお、データ収集サーバ１００は、複数の中間サーバ１２０と直接接続されてもよい。また、各中間サーバ１２０は、ネットワーク１４０を介して、各センサ１３０と接続される。

なお、ネットワーク１４０は、ＬＡＮ、ＰＬＣ等の有線ネットワーク、ＷｉＦｉ、Ｚｉｇｂｅｅ（Ｚｉｇｂｅｅは登録商標）等の無線ネットワーク、移動体通信事業者のモバイルネットワーク等が考えられる。

データ収集サーバ１００は、センサ１３０から送信されるデータを収集し、また、各中間サーバ１２０のフィルタ機能を管理する計算機である。ここで、データ収集サーバ１００のソフトウェア構成に関して説明する。

データ収集サーバ１００は、機能ブロックとして、データ受信部１０１、データ処理部１０２、中間サーバ管理部１０３、データ管理部１０４、ＤＢデータ送信部１０５、負荷監視部１０６、フィルタ管理部１０７、ＤＢデータ受信部１０８、及びデータベース１０９を備える。図１では、各機能ブロック間の実線はデータの入出力を示し、また、点線は指示の入出力を示す。

また、データ収集サーバ１００は、データテーブルとして、データ管理テーブル１１０、フィルタ状態管理テーブル１１１、データ受信状態テーブル１１２、負荷監視テーブル１１３、及びアルゴリズム選択テーブル１１４を保持する。

データ受信部１０１は、中間サーバ１２０からデータを受信する。

データ処理部１０２は、データベース１０９に依存しない所定のデータ形式に受信したデータを変換する。例えば、データ処理部１０２は、受信したデータの中身から一部のデータを取り出す処理、又は受信したデータをある特定の方式に従って変換する処理を実行する。なお、データ処理部１０２は、受信した全てのデータに対して変換処理を実行してもよいし、受信したデータのうち温度、湿度、及び電力等のデータ種別に応じて、それぞれ異なる変換処理を実行してもよい。

中間サーバ管理部１０３は、中間サーバ１２０に設定された基本フィルタテーブル１２８を管理する。

データ管理部１０４は、センサ１３０から送信されたデータを管理する。具体的には、データ管理部１０４は、データ管理テーブル１１０に従って、中間サーバ１２０毎のデータ破棄に関する設定、中間サーバ１２０から送信されるデータに対する許容遅延時間等を管理する。

負荷監視部１０６は、データ収集システムの負荷を監視する。本実施例では、負荷監視部１０６は、周期的に、データ収集システムの負荷を監視し、監視結果を負荷監視テーブル１１３に反映する。

フィルタ管理部１０７は、データ収集システムの負荷に応じて、中間サーバ１２０に設定するフィルタの処理内容（フィルタ条件）を決定し、決定されたフィルタの処理内容（フィルタ条件）を中間サーバ１２０に反映する。

ＤＢデータ送信部１０５は、データベース１０９にデータを送信する。ＤＢデータ受信部１０８は、ＤＢデータ送信部１０５から受信したデータをデータベース１０９に格納する。図１では、ＤＢデータ送信部１０５及びＤＢデータ受信部１０８は、それぞれ一つであるが、複数あってもよい。この場合、データベース１０９の仕様に応じて、ＤＢデータ送信部１０５及びＤＢデータ受信部１０８が選択される。

データベース１０９は、センサ１３０から送信されたデータを格納する。データベース１０９の構成は格納されるデータに応じてどのような構成であってもよい。

データ管理テーブル１１０は、センサ１３０から送信されるデータを管理するための情報を格納し、データ管理部１０４によって更新される。データ管理テーブル１１０の詳細については、図３を用いて後述する。

フィルタ状態管理テーブル１１１は、各中間サーバ１２０において設定されるフィルタ状態を管理するための情報を格納し、中間サーバ管理部１０３によって更新される。フィルタ状態管理テーブル１１１の詳細については、図４及び図５を用いて後述する。

データ受信状態テーブル１１２は、データ収集サーバ１００が受信したデータに関する情報を格納し、データ管理部１０４によって更新される。データ受信状態テーブル１１２の詳細については、図６を用いて後述する。

負荷監視テーブル１１３は、データ収集システムにおける各種負荷を管理するための情報を格納し、負荷監視部１０６によって更新される。負荷監視テーブル１１３の詳細については、図７を用いて後述する。

アルゴリズム選択テーブル１１４は、負荷低減を実現するために、各中間サーバ１２０のフィルタ機能部に適用されるアルゴリズムの情報を格納し、フィルタ管理部１０７によって更新される。アルゴリズム選択テーブル１１４の詳細については、図８を用いて後述する。

中間サーバ１２０は、センサ１３０から送信されるデータに対して所定の処理を実行し、処理後のデータをデータ収集サーバ１００に送信する計算機である。ここで、中間サーバ１２０のソフトウェア構成に関して説明する。

中間サーバ１２０は、機能ブロックとして、データ送信部１２１、データ振分け部１２２２、センサデータ受信部１２３、基本データフィルタ部１２４、複数の拡張フィルタ部１２５、及びフィルタ制御部１２６を備える。

また、中間サーバ１２０は、データテーブルとして、データ振分けテーブル１２７、及び基本フィルタテーブル１２８を保持する。

センサデータ受信部１２３は、センサ１３０から送信されるデータを受信する。センサデータ受信部１２３は、センサ１３０が利用する通信プロトコルに応じて、データを受信することができる。センサデータ受信部１２３は、センサ１３０から受信したデータをデータ振分け部１２２に送信する。

データ振分け部１２２は、受信したデータがフィルタ処理の対象であるか否かを判定し、フィルタ処理の対象である場合には、受信したデータに対応したフィルタ機能部に当該データを転送する。また、データ振分け部１２２は、フィルタ処理の対象でない場合には、データ送信部１２１に、受信したデータをそのまま転送する。

データ送信部１２１は、データ収集サーバ１００に、センサ１３０から受信したデータを送信する。データ送信部１２１が利用する送信プロトコルとしてはＨＴＴＰ等が用いられる。また、データ送信部１２１は、独自のプロトコルを実装し、当該プロトコルを用いて、データ収集サーバ１００に、受信したデータを転送してもよい。

次に、フィルタ機能部について説明する。中間サーバ１２０は、フィルタ機能部として、基本データフィルタ部１２４及び拡張フィルタ部１２５を備える。

基本データフィルタ部１２４は、一般的なフィルタ処理を実行する。具体的には、基本データフィルタ部１２４は、データ種別毎の受信個数、及び受信データ量等に基づいて、予め定められた条件を満足するまでデータを保持し、その後、データ送信部１２１を介してデータ収集サーバ１００に、保持したデータをまとめて送信する。

なお、基本データフィルタ部１２４は、タイマを用いて一定期間データを蓄積し、その後、データ収集サーバ１００に、一定期間内に蓄積されたデータをまとめて送信してもよい。さらに、基本データフィルタ部１２４は、データをまとめて送信する場合、当該データのうちの一部を破棄した後、残りのデータを送信してもよい。

拡張フィルタ部１２５は、基本データフィルタ部１２４のフィルタ処理とは異なるデータ処理が必要な場合に用いられるフィルタ機能部である。拡張フィルタ部１２５は、例えば、以下のような処理を実行する。

拡張フィルタ部１２５は、複数個の数値データを受信し、受信した複数個の数値データの平均値を算出し、算出された平均値をデータとしてデータ収集サーバ１００に送信する。また、拡張フィルタ部１２５は、データ収集サーバ１００側の処理を高速化するために、受信したデータの事前処理を実行した後、データ収集サーバ１００に処理されたデータを送信する。

なお、本発明は、基本データフィルタ部１２４及び拡張フィルタ部１２５が実行する処理に限定されない。

フィルタ制御部１２６は、中間サーバ１２０におけるフィルタの設定を制御する。具体的には、フィルタ制御部１２６は、データ収集サーバ１００からの指示に従って、基本データフィルタ部１２４等に対するフィルタ条件の設定を変更する。

データ振分けテーブル１２７は、センサ１３０から受信したデータを各フィルタ機能部に振り分けるための情報を格納し、データ振分け部１２２によって参照される。

基本フィルタテーブル１２８は、基本データフィルタ部１２４が実行するフィルタ処理に用いられるフィルタ条件等の情報を格納し、基本データフィルタ部１２４によって参照される。

センサ１３０は、データ収集サーバ１００に、様々なデータを送信する端末である。センサ１３０は、例えば、プロセッサ、メモリ、及びネットワークインタフェースを備える。

＜サーバのハードウェア構成＞
図２は、本発明の実施例１のサーバのハードウェア構成を示すブロック図である。図２では、データ収集サーバ１００及び中間サーバ１２０のハードウェア構成を示す。

サーバ２００は、プロセッサ２０１、メモリ２０２、及びネットワークインタフェース２０３を備える。

プロセッサ２０１は、メモリ２０２に格納されるプログラムを実行する。プロセッサ２０１が、メモリ２０２に格納されるプログラムを実行することによって、データ収集サーバ１００又は中間サーバ１２０が有する機能を実現することができる。

ネットワークインタフェース２０３は、ネットワークを介して他の装置と接続する。

メモリ２０２は、プロセッサ２０１によって実行されるプログラム及び当該プログラムの実行に必要な情報を格納する。

データ収集サーバ１００のメモリ２０２には、データ受信部１０１、データ処理部１０２、中間サーバ管理部１０３、データ管理部１０４、ＤＢデータ送信部１０５、負荷監視部１０６、フィルタ管理部１０７、及びＤＢデータ受信部１０８を実現するプログラムが格納される。また、データ収集サーバ１００のメモリ２０２には、データ管理テーブル１１０、フィルタ状態管理テーブル１１１、データ受信状態テーブル１１２、負荷監視テーブル１１３、及びアルゴリズム選択テーブル１１４が格納される。

一方、中間サーバ１２０のメモリ２０２には、データ送信部１２１、データ振分け部１２２２、センサデータ受信部１２３、基本データフィルタ部１２４、複数の拡張フィルタ部１２５、及びフィルタ制御部１２６を実現するプログラムが格納される。また、中間サーバ１２０のメモリ２０２には、データ振分けテーブル１２７、及び基本フィルタテーブル１２８が格納される。

＜データ収集サーバの説明＞
まず、図３から図８を用いて、データ収集サーバ１００が保持するテーブルについて説明する。

図３は、本発明の実施例１のデータ収集サーバ１００が保持するデータ管理テーブル１１０の一例を示す説明図である。

データ管理テーブル１１０は、データ識別子３０１、データ破棄可否３０２、優先度３０３、及び許容遅延時間３０４を含む。

データ識別子３０１は、センサ１３０から送信されるデータを識別するための識別子を格納するフィールドである。データの識別子としては、センサ１３０毎に予め付与された文字列、センサ１３０の種別毎に予め付与された文字列、データの送信先ＵＲＩを表す文字列、又はデータの送信先ＵＲＩを表す文字列の一部分等が考えられる。

データ破棄可否３０２は、中間サーバ１２０において、受信したデータの破棄を許可するか否かを示す情報を格納するフィールドである。データ破棄可否３０２に格納される情報としては、ＹＥＳ／ＮＯ、可／否、及びＴＲＵＥ／ＦＡＬＳＥ等の文字列、又は、１／０の数値等の２値情報が考えられる。

優先度３０３は、センサ１３０から送信されるデータの重要性を示す情報を格納するフィールドである。優先度３０３には、数値等が格納される。優先度３０３は、例えば、中間サーバ１２０が、センサ１３０から送信されるデータに対してフィルタ処理を実行するか否かを判定する順番を決定する場合に用いられる。

本実施例では、重要性の高いデータには、優先度３０３には小さな値が格納される。例えば、最も重要性が高いデータの優先度３０３には「１」が格納されることとなる。

許容遅延時間３０４は、中間サーバ１２０において、受信したデータの待合せ許容時間を格納するフィールドである。許容遅延時間３０４には、「２００ミリ秒」等の数値が格納される。許容遅延時間３０４は、例えば、受信したデータが中間サーバ１２０に一時蓄積し、その後まとめて送信するフィルタ処理において、フィルタ処理の対象のデータにリアルタイム性が要求される場合に用いられる。具体的には、中間サーバ１２０は、許容遅延時間３０４に格納される数値を超過した場合には、フィルタ条件が満たされていなくても、データ収集サーバ１００にデータを送信する。

図４は、本発明の実施例１のデータ収集サーバ１００が保持するフィルタ状態管理テーブル１１１の一例を示す説明図である。図５は、本発明の実施例１のフィルタ状態管理テーブル１１１に含まれるフィルタ条件４０４の一例を示す説明図である。

フィルタ状態管理テーブル１１１は、データ識別子４０１、及びフィルタ状態４０２を含む。

データ識別子４０１は、センサ１３０から送信されるデータを識別するための識別子を格納するフィールドであり、データ識別子３０１と同一のものである。

フィルタ状態４０２は、センサ１３０から送信されるデータに対するフィルタの設定状態を示す情報を格納するフィールドである。フィルタ状態４０２は、フィルタ有無４０３及びフィルタ条件４０４の二つのフィールドから構成される。

フィルタ有無４０３は、センサ１３０から送信されるデータに対してフィルタが設定されているか否かを示す情報を格納するフィールドである。フィルタ有無４０３に格納される情報としては、例えば、ＹＥＳ／ＮＯ、可／否、ＴＲＵＥ／ＦＡＬＳＥと等の文字列、又は１／０の数値等の２値情報が考えられる。受信したデータに対したフィルタが設定されている場合、フィルタ有無４０３には、ＹＥＳ、可、若しくはＴＲＵＥ等の文字列、又は１が格納される。

フィルタ条件４０４は、センサ１３０から送信されるデータにフィルタが設定されている場合、設定されているフィルタの処理内容を格納するフィールドである。ここで、図５を用いて、フィルタ条件４０４の詳細について説明する。

フィルタ条件４０４は、フィルタ種別５０１、フィルタしきい値５０２、データ破棄率５０３、及び許容遅延時間５０４から構成される。

フィルタ種別５０１は、フィルタ処理の実行時に用いられる値を格納するフィールドである。フィルタ種別５０１に格納される値としては、例えば、データ個数、データ量等の種別を表す識別子が考えられる。

フィルタしきい値５０２は、フィルタ処理におけるしきい値を格納するフィールドである。

例えば、フィルタ種別５０１に「データ個数」が格納される場合、以下のようなフィルタ処理が実行される。中間サーバ１２０は、データ識別子４０１と一致する識別子のデータがフィルタしきい値５０２の値の個数だけ蓄積された場合、データ収集サーバ１００に蓄積されたデータを送信する。

また、フィルタ種別５０１に「データ量」が格納される場合、以下のようなフィルタ処理が実行される。中間サーバ１２０は、データ識別子４０１と一致する識別子のデータがフィルタしきい値５０２の値のデータ量分だけ蓄積された場合、データ収集サーバ１００に蓄積されたデータを送信する。

データ破棄率５０３は、フィルタ条件が満たされ、蓄積されたデータのうち、実際にデータ収集サーバ１００に送信するデータの割合を示す数値を格納するフィールドである。

許容遅延時間５０４は、センサ１３０から送信されるデータを蓄積する場合に、中間サーバ１２０が蓄積可能な許容時間を格納するフィールドである。許容遅延時間５０４は、許容遅延時間３０４に格納される数値以下の値が格納される。許容遅延時間５０４に基づいて、中間サーバ１２０がデータを蓄積し、一定間隔毎に蓄積されたデータをまとめてデータ収集サーバ１００に送信するフィルタ処理が実現できる。

なお、前述したフィルタ条件４０４は一例であって、本発明は、フィルタ条件４０４に限定されない。

図６は、本発明の実施例１のデータ収集サーバ１００が保持するデータ受信状態テーブル１１２の一例を示す説明図である。

データ受信状態テーブル１１２は、データ識別子６０１、受信数６０２、受信量６０３、過去受信数６０４、及び過去受信量６０６を含む。

データ識別子６０１は、センサ１３０から送信されるデータを識別するための識別子を格納するフィールドであり、データ識別子３０１と同一のものである。

受信数６０２は、現時点から一定の時間間隔さかのぼった期間において受信したデータの個数を格納するフィールドである。現時点とは、受信したデータのタイムスタンプのうち、最新のタイムスタンプを表す。また、一定の時間間隔は、予め設定された間隔であるものとする。例えば、最新のタイムスタンプが「２０１２／１２／０１ １２：００：００」で、一定の時間間隔が１分の場合、受信数６０２には、「２０１２／１２／０１ １１：５９：００」から「２０１２／１２／０１ １１：５９：５９」までの間に受信したデータの個数が格納される。

受信量６０３は、現時点から一定期間さかのぼった時間間隔において受信したデータのデータ量を格納するフィールドである。

過去受信数６０４は、現時点までに、一定の時間間隔において受信したデータの個数を格納するフィールドである。例えば、一定の時間間隔が１分の場合、過去受信数６０４には、過去に受信したデータの個数を統計処理することによって算出された、１分間あたりの平均データ数が格納される。

過去受信量６０５は、現時点までに、一定の時間間隔において受信したデータのデータ量を格納するフィールドである。

前述したように、受信数６０２及び受信量６０３は、現在の受信状態を示す情報であり、過去受信数６０４及び過去受信量６０５は、過去の受信状態を示す情報である。したがって、データ受信状態テーブル１１２は、突発的にデータ数、又はデータ量が増加したデータを検索する場合に用いられる。また、データ数、又はデータ量の増加量が多い順に、データにフィルタを設定する場合にも用いられる。

図６に示すデータ受信状態テーブル１１２は一例であって、その他の情報が格納されてもよい。例えば、データ受信状態テーブル１１２には、現時点までに受信したデータの個数の最大値及びその時刻、又はデータ量の最大値及びその時刻の組合せが格納されてもよい。

図７は、本発明の実施例１のデータ収集サーバ１００が保持する負荷監視テーブル１１３の一例を示す説明図である。

負荷監視テーブル１１３は、負荷要素７０１、現在値７０２、及びしきい値７０３を含む。

負荷要素７０１は、データ収集システムの性能に影響を与える要素を格納するフィールドである。本実施例では、データ収集サーバ１００と中間サーバ１２０とを接続するネットワークの帯域利用量、データ収集サーバ１００におけるＣＰＵ使用率、データ収集サーバ１００が受信したパケット数、データベース１０９において処理されるセッション数、データベース１０９に蓄積されるデータ量等が負荷要素として挙げられる。

現在値７０２は、現在のデータ収集システムにおける負荷要素７０１に対応する値を格納するフィールドである。現在値７０２に格納される値は、負荷監視部１０６によって周期的に更新される。

しきい値７０３は、データ収集システムにおける負荷要素７０１に設定されたしきい値を格納するフィールドである。

現在値７０２の値がしきい値７０３の値より大きくなった場合に、中間サーバ１２０にフィルタを設定する処理等のトリガとして用いられる。

図８は、本発明の実施例１のデータ収集サーバ１００が保持するアルゴリズム選択テーブル１１４の一例を示す説明図である。

アルゴリズム選択テーブル１１４は、負荷要素８０１及びフィルタ制御アルゴリズム８０２を含む。

負荷要素８０１は、データ収集システムの性能に影響を与える要素を格納するフィールドであり、負荷要素７０１と同一のものである。

フィルタ制御アルゴリズム８０２は、各負荷要素８０１に対して適用されるアルゴリズムの識別情報を格納するフィールドである。ここで、アルゴリズムは、データ収集システムの負荷を低減するためのフィルタ処理のアルゴリズムであり、設定されるフィルタの種別を表すものである。

図８では、アルゴリズムの一例として、データ量削減、データ数削減、及びデータ数集約を示している。

データ量削減のアルゴリズムは、中間サーバ１２０から送信されるデータのデータ量を削減するためのフィルタを設定するアルゴリズムである。

データ数削減のアルゴリズムは、中間サーバ１２０から送信されるデータの個数を削減するためのフィルタを設定するアルゴリズムである。

また、データ集約のアルゴリズムは、複数のデータを一つのデータに集約して、集約されたデータをデータ収集サーバ１００に送信するためのフィルタを設定するアルゴリズムである。データ集約のアルゴリズムは、中間サーバ１２０から送信されるデータの個数の削減を目的としてフィルタの設定に用いられるものである。

なお、本発明は、使用されるアルゴリズムに限定されない。例えば、図８に示したアルゴリズム以外にも、中間サーバ１２０から送信されるデータのデータ量の削減するために、中間サーバ１２０から送信されるデータを圧縮し、データ収集サーバ１００に圧縮されたデータを送信するアルゴリズム等が用いられてもよい。

次に、図９から図１２を用いて、データ収集サーバ１００が実行する処理について説明する。

図９は、本発明の実施例１のフィルタ管理部１０７が実行するアルゴリズム選択処理の一例を説明するフローチャートである。

アルゴリズム選択処理は、負荷監視部１０６が周期的にデータ収集システムの負荷を監視し、データ収集システムの負荷が増大した場合に実行される。具体的には、負荷監視部１０６は、負荷監視テーブル１１３の所定の負荷要素７０１の現在値７０２の値が、しきい値７０３の値より大きくなった場合、データ収集システムの負荷が増大したと判定し、フィルタ管理部１０７を呼び出す。このとき、負荷監視部１０６は、対応する負荷要素７０１を含む負荷情報をフィルタ管理部１０７に送信する。

まず、フィルタ管理部１０７は、負荷監視部１０６から、負荷情報を受信する（ステップＳ９０１）。

フィルタ管理部１０７は、負荷情報及びアルゴリズム選択テーブル１１４に基づいて、センサ１３０から送信されるデータに適用するフィルタ制御アルゴリズムを選択する（ステップＳ９０２）。具体的には、以下のような処理が実行される。

フィルタ管理部１０７は、負荷情報から負荷要素７０１を取得する。フィルタ管理部１０７は、アルゴリズム選択テーブル１１４を参照し、負荷要素８０１が取得された負荷要素７０１と一致するエントリを検索する。フィルタ管理部１０７は、検索されたエントリのフィルタ制御アルゴリズム８０２を、センサ１３０から送信されるデータに適用するフィルタ制御アルゴリズムとして選択する。

次に、フィルタ管理部１０７は、選択されたフィルタ制御アルゴリズムに対応するフィルタ対象データリストを生成する（ステップＳ９０３）。ここで、フィルタ対象データリストの生成方法としては、以下のようなものが考えられる。

選択されたフィルタ制御アルゴリズムがデータ数削減のアルゴリズム、又はデータ量削減のアルゴリズムである場合、フィルタ管理部１０７は、データ管理テーブル１１０のデータ破棄可否３０２を参照して、データの破棄が許可されているデータのエントリを抽出し、抽出されたエントリをリスト化する方法が考えられる。このとき、フィルタ管理部１０７は、優先度３０３又は許容遅延時間３０４に基づいて、フィルタ対象データリストのエントリを並び替えてもよい。

これによって、破棄が可能なデータ種別のデータに対してフィルタ処理が実行される。すなわち、当該データ種別のデータが破棄される。

選択されたフィルタ制御アルゴリズムがデータ数集約のアルゴリズムである場合、フィルタ管理部１０７は、データ受信状態テーブル１１２の受信数６０２及び過去受信数６０４を参照し、受信データ数の増加幅が大きい順にデータ受信状態テーブル１１２のエントリを抽出し、抽出されたエントリをリスト化する方法が考えられる。このとき、フィルタ管理部１０７は、優先度３０３又は許容遅延時間３０４に基づいて、フィルタ対象データリストのエントリを並び替えてもよい。

この場合、フィルタ処理データリストの上のエントリから順に処理することによって、受信データ数が急激に増加したデータ種別のデータから優先的にフィルタ処理が実行される。すなわち、当該データ種別のデータから優先的に集約される。

さらに、フィルタ管理部１０７は、優先度３０３の値が大きい順に、すなわち、重要性の低い順に、データ受信状態テーブル１１２のエントリを抽出し、抽出されたエントリをリスト化してもよい。また、フィルタ管理部１０７は、許容遅延時間３０４が大きい順にデータ受信状態テーブル１１２のエントリを抽出し、抽出されたエントリをリスト化されてもよい。

この場合、フィルタ処理データリストの上のエントリから順に処理することによって、重要性の低いデータ種別のデータから優先的にフィルタ処理を実行される。例えば、重要性の低いデータ種別のデータを優先的に破棄し、又は、集約することが可能となる。

次に、フィルタ管理部１０７は、生成されたフィルタ対象データリスト及び選択されたフィルタ制御アルゴリズムに基づいて、フィルタ制御処理を実行する（ステップＳ９０４）。すなわち、フィルタ対象データリストに含まれるデータに対して、フィルタ制御アルゴリズムに対応するフィルタが設定される。フィルタ制御処理については、図１０から図１２を用いて後述する。

以上で説明したように、本発明では、データ収集システムの負荷に応じて、センサ１３０から送信されるデータに対して設定されるフィルタを動的に設定することができる。これによって、データ収集システムの負荷の適切な低減が可能となる。

また、データ収集システムの負荷に応じて、フィルタを設定するデータを特定するため、センサ１３０から送信されるデータの安全性、信頼性等を確保しつつ、データ収集システムの負荷の低減が可能となる。

図１０は、本発明の実施例１のフィルタ管理部１０７がデータ量削減のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。

フィルタ管理部１０７は、負荷監視テーブル１１３を参照して、データ収集システムにおいて削減すべきデータ量を算出する（ステップＳ１００１）。

具体的には、フィルタ管理部１０７は、現在値７０２としきい値７０３との差を算出する。例えば、ネットワークの帯域利用量が負荷要素である場合、負荷監視テーブル１１３のネットワークの帯域利用量に対応するエントリの現在値７０２からしきい値７０３を減算することによって、データ収集システムにおいて削減すべきデータ量が算出される。

以下の説明では、ステップＳ１００１において算出された値を必須削減データ量とも記載する。

フィルタ管理部１０７は、必須削減データ量、及びフィルタ対象データリストに基づいて、データ毎の目標削減データ量を算出する（ステップＳ１００２）。このとき、フィルタ管理部１０７は、削減予定データ量を「０」に初期化する。

ここで、目標削減データ量の決定方法としては、以下のような方法が考えられる。一つの方法としては、フィルタ管理部１０７は、算出された必須削減データ量を、フィルタ対象データリストに含まれるデータ種別の数（エントリの数）で除算することによって目標削減データ量を算出する。また、他の方法としては、フィルタ管理部１０７は、算出された必須削減データ量を、フィルタ対象データリストに含まれるデータ種別の数（エントリの数）で除算し、当該値に定数を乗算することによって目標削減データ量を算出する。

前述した決定方法では、全てのデータ種別のデータ量が均等に削減されるフィルタ制御が可能となる。一方、各データ種別の優先度に基づいて、目標削減データ量が決定されてもよい。例えば、フィルタ管理部１０７は、優先度３０３の値に基づいて、データ種別毎の削減データ量の比率を算出し、算出された比率及び必須削減データ量に基づいて、目標削減データ量を算出する。例えば、優先度３０３の値の逆数を削減データ量の比率として用いることが考えられる。

次に、フィルタ管理部１０７は、フィルタ対象データリストから処理対象のデータを選択する（ステップＳ１００３）。

ここで、処理対象のデータの選択方法としては、以下のような方法が考えられる。一つの方法としては、フィルタ管理部１０７は、データ管理テーブル１１０の優先度３０３を参照して、優先度３０３の値が低い順に、フィルタ対象データリストに含まれるデータを選択する。また、他の方法としては、フィルタ管理部１０７は、データ受信状態テーブル１１２の受信量６０３と過去受信量６０５との差を算出し、受信データ量の増加幅が大きい順、すなわち算出された差が大きい順に、フィルタ対象データリストに含まれるデータを選択する。

予め、優先度３０３の値が低い順、又は受信データ量の増加幅の順に、フィルタ対象データリストのエントリが並び替えられている場合には、フィルタ管理部１０７は、フィルタ対象データリストの上のエントリから順に選択する。

フィルタ管理部１０７は、フィルタ対象データリストから選択可能なデータが存在するか否かを判定する（ステップＳ１００４）。すなわち、フィルタ対象データリストの全てのデータに対して処理が実行されたか否かが判定される。

フィルタ対象データリストから選択可能なデータが存在しないと判定された場合、フィルタ管理部１０７は、異常状態が発生したものとしてオペレータに警告メッセージを送信し（ステップＳ１０１０）、処理を終了する。これは、必須削減データ量分のデータ量を削減できず、データ収集システムの負荷を低減できない状態であるためである。

フィルタ対象データリストから選択可能なデータが存在すると判定された場合、フィルタ管理部１０７は、データ受信状態テーブル１１２に基づいて、選択されたデータにおけるデータ破棄率を算出する（ステップＳ１００５）。具体的には、以下のような処理が実行される。

フィルタ管理部１０７は、データ受信状態テーブル１１２を参照し、データ識別子６０１が選択されたデータの識別子と一致するエントリを検索する。フィルタ管理部１０７は、検索されたエントリの受信量６０３から過去受信量６０５を減算することによって、削減可能なデータ量を算出する。フィルタ管理部１０７は、削減可能なデータ量が目標削減データ量より大きいか否かを判定する。

削減可能なデータ量が目標削減データ量より大きいと判定された場合、フィルタ管理部１０７は、目標削減データ量を、選択されたデータの削減量として決定する。一方、削減可能なデータ量が目標削減データ量以下であると判定された場合、フィルタ管理部１０７は、削減可能なデータ量を、選択されたデータの削減量として決定する。

フィルタ管理部１０７は、選択されたデータの削減量を受信量６０３で除算することによって、データ破棄率を算出する。

ここで、選択されたエントリの受信量６０３が「４００」、過去受信量６０５が「２００」、目標削減データ量が「１００」である場合、例えば、以下のような処理が実行される。削減可能なデータ量は「２００」であり、目標削減データ量より大きいため、フィルタ管理部１０７は、目標削減データ量を、選択されたデータの削減量として決定する。また、フィルタ管理部１０７は、目標削減データ量の「１００」を受信量６０３の「４００」で除算することによって、データ破棄率を「２５パーセント」と決定する。

フィルタ管理部１０７は、選択されたデータの識別子、フィルタ種別、フィルタのしきい値、許容遅延時間、及び算出されたデータ破棄率を含むフィルタ条件設定指示を各中間サーバ１２０に送信する（ステップＳ１００６）。

なお、フィルタ種別には負荷要素７０１に関連する情報が用いられる。例えば、負荷要素がネットワークの帯域利用量である場合、フィルタ種別は「データ量」となる。

また、フィルタのしきい値には任意の値が設定される。例えば、中間サーバ１２０にデータを蓄積する必要がないフィルタの場合「０」が設定され、また、蓄積されたデータ量が１０００ＭＢとなった場合に１００ＭＢ分のデータを破棄するフィルタの場合「１００／１０００」が設定される。

また、許容遅延時間にはデータ管理テーブル１１０の許容遅延時間３０４が設定される。

これによって、中間サーバ１２０は、フィルタ条件設定指示にしたがって、選択されたデータに対するフィルタを設定する。具体的には、フィルタ制御部１２６が、基本フィルタテーブル１２８に、受信したフィルタ条件設定指示に含まれる値を格納する。また、フィルタ制御部１２６は、データ振分けテーブル１２７に新たなエントリを追加し、データ識別子１３０１に選択されたデータの識別子を格納し、振分け先１３０２に「基本フィルタ」を格納する。

次に、フィルタ管理部１０７は、選択されたデータに対して設定されたフィルタによって削減されるデータ量、すなわち、選択されたデータの削減量を削減予定データ量に加算する（ステップＳ１００７）。また、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を更新する（ステップＳ１００８）。

具体的には、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を参照して、選択されたデータに対応するエントリを検索する。フィルタ管理部１０７は、検索されたエントリのフィルタ有無４０３にフィルタが設定されている旨を示す情報を格納する。また、フィルタ管理部１０７は、フィルタ条件設定指示に含まれる各値を、検索されたエントリのフィルタ条件４０４に格納する。

フィルタ管理部１０７は、削減予定データ量が必須削減データ量より大きいか否かを判定する（ステップＳ１００９）。

削減予定データ量が必須削減データ量以下であると判定された場合、フィルタ管理部１０７は、ステップ１００３に戻り同様の処理を実行する。

削減予定データ量が必須削減データ量より大きいと判定された場合、フィルタ管理部１０７は、データ収集システムの負荷を低減できるため、処理を終了する。

図１１は、本発明の実施例１のフィルタ管理部１０７がデータ数削減のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。

フィルタ管理部１０７は、負荷監視テーブル１１３を参照して、データ収集システムにおいて削除すべきデータ数を算出する（ステップＳ１１０１）。

具体的には、フィルタ管理部１０７は、現在値７０２としきい値７０３との差を算出する。例えば、サーバの受信パケット数が負荷要素である場合、負荷監視テーブル１１３のサーバの受信パケット数に対応するエントリの現在値７０２からしきい値７０３を減算することによって、削減すべきデータ数が算出される。

以下の説明では、ステップＳ１１０１において算出された値を必須削減データ数とも記載する。

フィルタ管理部１０７は、必須削減データ数、及びフィルタ対象データリストに基づいて、データ毎の目標削減データ数を算出する（ステップＳ１１０２）。このとき、フィルタ管理部１０７は、削除予定データ数を「０」に初期化する。

ここで、目標削減データ数の決定方法としては、以下のような方法が考えられる。一つの方法としては、フィルタ管理部１０７は、算出された必須削減データ数を、フィルタ対象データリストに含まれるデータ種別の数（エントリの数）で除算することによって目標削減データ数を算出する。また、他の方法としては、フィルタ管理部１０７は、算出された必須削減データ数を、フィルタ対象データリストに含まれるデータ種別の数（エントリの数）で除算し、当該値に定数を乗算することによって目標削減データ数を算出する。

前述した決定方法では、全てのデータ種別のデータ数が均等に削減されるフィルタ制御が可能となる。一方、各データ種別の優先度に基づいて、目標削減データ数が決定されてもよい。例えば、フィルタ管理部１０７は、優先度３０３の値に基づいて、データ種別毎の削減データ数の比率を算出し、算出された比率及び必須削減データ数に基づいて、目標削減データ数を算出する。例えば、優先度３０３の値の逆数を削減データ数の比率として用いることが考えられる。

次に、フィルタ管理部１０７は、フィルタ対象データリストから、処理対象のデータを選択する（ステップＳ１１０３）。

ここで、処理対象のデータの選択方法としては、以下のような方法が考えられる。一つの方法としては、フィルタ管理部１０７は、データ管理テーブル１１０の優先度３０３を参考して、優先度３０３の値の低い順に、フィルタ対象データリストに含まれるデータを選択する。また、他の方法としては、フィルタ管理部１０７は、データ受信状態テーブル１１２の受信数６０２と過去受信数６０４との差を算出し、受信データ数の増加幅が大きい順、すなわち算出された差が大きい順に、フィルタ対象データリストに含まれるデータを選択する。

予め、優先度３０３の値が低い順、又は受信データ数の増加幅の順に、フィルタ対象データリストのエントリが並び替えられている場合には、フィルタ管理部１０７は、フィルタ対象データリストの上のエントリから順に選択する。

フィルタ管理部１０７は、フィルタ対象データリストから選択可能なデータが存在するか否かを判定する（ステップＳ１１０４）。すなわち、フィルタ対象データリストの全てのデータに対して処理が実行されたか否かが判定される。

フィルタ対象データリストから選択可能なデータが存在しないと判定された場合、フィルタ管理部１０７は、異常状態が発生したものとしてオペレータに警告メッセージを送信し（ステップＳ１１１０）、処理を終了する。これは、必須削減データ数分のデータ数を削除できず、データ収集システムの負荷を低減できない状態であるためである。

フィルタ対象データリストから選択可能なデータが存在すると判定された場合、フィルタ管理部１０７は、データ受信状態テーブル１１２に基づいて、選択されたデータにおけるデータ破棄率を算出する（ステップＳ１１０５）。具体的には、以下のような処理が実行される。

フィルタ管理部１０７は、データ受信状態テーブル１１２を参照し、データ識別子６０１が選択されたデータの識別子と一致するエントリを検索する。フィルタ管理部１０７は、検索されたエントリの受信数６０２から過去受信数６０４を減算することによって、削減可能なデータ数を算出する。フィルタ管理部１０７は、削減可能なデータ数が目標削減データ数より大きいか否かを判定する。

削減可能なデータ数が目標削減データ数より大きいと判定された場合、フィルタ管理部１０７は、目標削減データ数を、選択されたデータの削減数として決定する。一方、削減可能なデータ数が目標削減データ数以下であると判定された場合、フィルタ管理部１０７は、削減可能なデータ数を、選択されたデータの削減数として決定する。

フィルタ管理部１０７は、選択されたデータの削減数を受信数６０２で除算することによって、データ破棄率を算出する。

ここで、選択されたエントリの受信数６０２が「１００」、過去受信数６０４が「５０」、目標削減データ数が「１００」である場合、例えば、以下のような処理が実行される。削減可能なデータ数は「５０」であり、目標削減データ数より小さいため、フィルタ管理部１０７は、削減可能なデータ数を、選択されたデータの削減数として決定する。また、フィルタ管理部１０７は、削減可能なデータ数の「５０」を受信数６０２の「１００」で除算することによって、データ破棄率を「５０パーセント」と決定する。

フィルタ管理部１０７は、選択されたデータの識別子、フィルタ種別、フィルタのしきい値、及び算出されたデータ破棄率を含むフィルタ条件設定指示を各中間サーバ１２０に送信する（ステップＳ１１０６）。

なお、フィルタ種別には負荷要素７０１に関連する情報が用いられる。例えば、負荷要素がサーバの受信パケット数である場合、フィルタ種別は「データ数」となる。

また、フィルタのしきい値には任意の値が設定される。例えば、中間サーバ１２０にデータを蓄積する必要がないフィルタの場合「０」が設定され、また、蓄積されたデータ数が５個となった場合に１個のデータを破棄するフィルタの場合「１／５」が設定される。

また、許容遅延時間にはデータ管理テーブル１１０の許容遅延時間３０４が設定される。

これによって、中間サーバ１２０は、フィルタ条件設定指示にしたがって、選択されたデータに対するフィルタを設定する。具体的には、フィルタ制御部１２６が、基本フィルタテーブル１２８に、受信したフィルタ条件設定指示に含まれる値を格納する。また、フィルタ制御部１２６は、データ振分けテーブル１２７に新たなエントリを追加し、データ識別子１３０１に選択されたデータの識別子を格納し、振分け先１３０２に「基本フィルタ」を格納する。

フィルタ管理部１０７は、選択されたデータに対して設定されたフィルタによって削減されるデータ数を、すなわち、選択されたデータの削減数を削減予定データ数に加算する（ステップＳ１１０７）。また、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を更新する（ステップＳ１１０８）。

具体的には、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を参照して、選択されたデータに対応するエントリを検索する。フィルタ管理部１０７は、検索されたエントリのフィルタ有無４０３にフィルタが設定されている旨を示す情報を格納する。また、フィルタ管理部１０７は、フィルタ条件設定指示に含まれる各値を、検索されたエントリのフィルタ条件４０４に格納する。

フィルタ管理部１０７は、削減予定データ数が必須削減データ数より大きいか否かを判定する（ステップＳ１１０９）。

削減予定データ数が必須削減データ数以下であると判定された場合、フィルタ管理部１０７は、ステップＳ１１０３に戻り同様の処理を実行する。

削減予定データ数が必須削減データ数より大きいと判定された場合、フィルタ管理部１０７は、データ収集システムの負荷を低減できるため、処理を終了する。

図１２は、本発明の実施例１のフィルタ管理部１０７がデータ集約のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。

フィルタ管理部１０７は、負荷監視テーブル１１３を参照して、削減すべきデータ数を算出する（ステップＳ１２０１）。

具体的には、フィルタ管理部１０７は、現在値７０２としきい値７０３との差を算出する。例えば、データベースの処理セッション数が負荷要素である場合、負荷監視テーブル１１３のデータベースの処理セッション数に対応するエントリの現在値７０２からしきい値７０３を減算することによって、削除すべきデータ数が算出される。

以下の説明では、ステップＳ１２０１において算出された値を必須削減データ数と記載する。

フィルタ管理部１０７は、算出された必須削減データ数、及びフィルタ対象データリストに基づいて、データ毎の目標集約データ数を算出する（ステップＳ１２０２）。このとき、フィルタ管理部１０７は、削減予定データ数を「０」に初期化する。

ここで、目標削減データ数の決定方法としては、以下のような方法が考えられる。一つの方法としては、フィルタ管理部１０７は、算出された必須削減データ数を、フィルタ対象データリストに含まれるデータ種別の数（エントリの数）で除算することによって目標削減データ数を算出する。また、他の方法としては、フィルタ管理部１０７は、算出された必須削減データ数を、フィルタ対象データリストに含まれるデータ種別の数（エントリの数）で除算し、当該値に定数を乗算することによって目標削減データ数を算出する。

次に、フィルタ管理部１０７は、フィルタ対象データリストから処理対象のデータを選択する（ステップＳ１２０３）。

データ集約のアルゴリズムにおけるフィルタ対象データリストは、受信データ数の増加幅が大きい順にエントリが並び替えられているため、フィルタ管理部１０７は、上のエントリから順に選択する。

フィルタ管理部１０７は、フィルタ対象データリストから選択可能なデータが存在するか否かを判定する（ステップＳ１２０４）。すなわち、フィルタ対象データリストの全てのデータに対して処理が実行されたか否かが判定される。

フィルタ対象データリストから選択可能データが存在しないと判定された場合、フィルタ管理部１０７は、異常状態が発生したものとしてオペレータに警告メッセージを送信し（ステップＳ１２１０）、処理を終了する。これは、必須削減データ数分のデータ数を削減できず、データ収集システムの負荷を低減できない状態であるためである。

フィルタ対象データリストから選択可能なデータが存在すると判定された場合、フィルタ管理部１０７は、データ受信状態テーブル１１２に基づいて、選択されたデータにおけるデータ集約数を算出する（ステップＳ１２０５）。具体的には、以下のような処理が実行される。

フィルタ管理部１０７は、データ受信状態テーブル１１２を参照し、データ識別子６０１が選択されたデータの識別子と一致するエントリを検索する。フィルタ管理部１０７は、検索されたエントリの受信数６０２から過去受信数６０４を減算することによって、削減可能なデータ数を算出する。フィルタ管理部１０７は、削減可能なデータ数が目標削減データ数より大きいか否かを判定する。

削減可能なデータ数が目標削減データ数より大きいと判定された場合、フィルタ管理部１０７は、目標削減データ数を、選択されたデータの削減数として決定する。一方、削減可能なデータ数が目標削減データ数以下であると判定された場合、フィルタ管理部１０７は、削減可能なデータ数を、選択されたデータの削減数として決定する。

フィルタ管理部１０７は、受信数６０２から選択されたデータの削減数を減算することによって、受信予定数を算出する。さらに、フィルタ管理部１０７は、受信数６０２を算出された受信予定数で除算することによってデータ集約数を算出する。

ここで、検索されたエントリの受信数６０２が「４００」、過去受信数６０４が「４００」、目標削減データ数が「２００」である場合、例えば、以下のような処理が実行される。削減可能なデータ数は「３００」であり、目標削減データ数より大きいため、フィルタ管理部１０７は、目標削減データ数を、選択されたデータの削減数として決定する。また、フィルタ管理部１０７は、受信数６０２の「４００」から選択されたデータの削減数の「２００」を減算することによって受信予定数として「２００」を算出する。さらに、フィルタ管理部１０７は、受信数６０２の「４００」を受信予定数の「２００」で除算することによって、データ集約数を「２」と決定する。

次に、フィルタ管理部１０７は、選択されたデータの識別子、フィルタ種別、許容遅延時間、及び算出されたデータ集約数を含むフィルタ条件設定指示を各中間サーバ１２０に送信する（ステップＳ１２０６）。

なお、フィルタ種別には負荷要素７０１に関連する情報が用いられる。例えば、負荷要素がデータベースの処理セッション数である場合、フィルタ種別は「セッション数」となる。許容遅延時間にはデータ管理テーブル１１０の許容遅延時間３０４が設定される。また、決定されたデータ集約数はフィルタのしきい値に対応する。

これによって、中間サーバ１２０は、フィルタ条件設定指示にしたがって、選択されたデータに対するフィルタを設定する。具体的には、フィルタ制御部１２６が、基本フィルタテーブル１２８に、受信したフィルタ条件設定指示に含まれる値を格納する。また、フィルタ制御部１２６は、データ振分けテーブル１２７に新たなエントリを追加し、データ識別子１３０１に選択されたデータの識別子を格納し、振分け先１３０２に「基本フィルタ」を格納する。

フィルタ管理部１０７は、選択されたデータに対して設定されたフィルタによって削減されるデータ数、すなわち、選択されたデータの削減数を削減予定データ数に加算する（ステップＳ１２０７）。また、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を更新する（ステップＳ１２０８）。

具体的には、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を参照して、選択されたデータに対応するエントリを検索する。フィルタ管理部１０７は、検索されたエントリのフィルタ有無４０３にフィルタが設定されている旨を示す情報を格納する。また、フィルタ管理部１０７は、フィルタ条件設定指示に含まれる各値を、検索されたエントリのフィルタ条件４０４に格納する。

フィルタ管理部１０７は、削減予定データ数が必須削減データ数より大きいか否かを判定する（ステップＳ１２０９）。

削減予定データ数が必須削減データ数以下であると判定された場合、フィルタ管理部１０７は、ステップＳ１２０３に戻り同様の処理を実行する。

削減予定データ数が必須削減データ数より大きいと判定された場合、フィルタ管理部１０７は、データ収集システムの負荷を低減できるため、処理を終了する。

＜中間サーバの説明＞
まず、図１３及び図１４を用いて、中間サーバ１２０が保持するテーブルについて説明する。

図１３は、本発明の実施例１の中間サーバ１２０が保持するデータ振分けテーブル１２７の一例を示す説明図である。

データ振分けテーブル１２７は、データ識別子１３０１、及び振分け先１３０２を含む。

データ識別子１３０１は、センサ１３０から送信されるデータを識別するための識別子を格納するフィールドであり、データ識別子３０１と同一のものである。振分け先１３０２は、データ識別子１３０１に対応するデータが転送されるフィルタ機能部の識別子を格納するフィールドである。

データ振分け部１２２は、センサ１３０からデータを受信した場合に、データ振分けテーブル１２７を参照して、受信したデータの識別子を検索キーとして一致するエントリを検索し、検索されたエントリの振分け先１３０２に対応するフィルタ機能部に受信したデータを転送する。

図１４は、本発明の実施例１の中間サーバ１２０が保持する基本フィルタテーブル１２８の一例を示す説明図である。

基本フィルタテーブル１２８は、データ識別子１４０１、及びフィルタ条件１４０２を含む。

データ識別子１４０１は、センサ１３０から送信されるデータを識別するための識別子を格納するフィールドであり、データ識別子３０１と同一のものである。フィルタ条件１４０２は、フィルタの処理内容を格納するフィールドであり、フィルタ条件４０４と同一のものである。フィルタ条件１４０２には、フィルタ条件設定指示に含まれる各値が格納される。

なお、本実施例では、データ振分けテーブル１２７、及び基本フィルタテーブル１２８を別々のテーブルとして管理しているが、一つのテーブルにまとめて管理してもよい。この場合、中間サーバ１２０は、データ識別子、振り分け先、及びフィルタ条件を含むテーブルを保持する。

図１５は、本発明の実施例１の中間サーバ１２０のデータ振分け部１２２が実行するデータ振分け処理の一例を説明するフローチャートである。

データ振分け部１２２は、センサデータ受信部１２３からデータを受信し（ステップＳ１５０１）、受信したデータからデータ識別子を取得する（ステップＳ１５０２）。

データ振分け部１２２は、データ振分けテーブル１２７を参照して、取得されたデータ識別子を検索キーとして、当該データ識別子と一致するエントリを検索する（ステップＳ１５０３）。データ振分け部１２２は、検索結果に基づいて、取得されたデータ識別子と一致するエントリがあるか否かを判定する（ステップＳ１５０４）。取得されたデータ識別子と一致するエントリがある場合、当該データに対するフィルタが設定されていることを示す。

取得されたデータ識別子と一致するエントリがあると判定された場合、データ振分け部１２２は、検索されたエントリの振分け先１３０２に対応するフィルタ機能部に当該データを転送し（ステップＳ１５０５）、処理を終了する。

取得されたデータ識別子と一致するエントリがないと判定された場合、データ振分け部１２２は、データ収集サーバ１００に当該データをそのまま送信するために、データ送信部１２１に当該データを転送し（ステップＳ１５０６）、処理を終了する。

図１６は、本発明の実施例１の中間サーバ１２０の基本データフィルタ部１２４が実行するフィルタ処理の一例を説明するフローチャートである。

基本データフィルタ部１２４は、データ振分け部１２２からデータを受信し（ステップＳ１６０１）、受信したデータからデータ識別子を取得する（ステップＳ１６０２）。

基本データフィルタ部１２４は、基本フィルタテーブル１２８を参照して、取得されたデータ識別子を検索キーとして、当該データ識別子と一致するエントリを検索する（ステップＳ１６０３）。

基本データフィルタ部１２４は、受信したデータを一時的に保持するデータ用キューに、受信したデータを追加する（ステップＳ１６０４）。本実施例では、データの種別毎にデータ用キューがあるものとする。この場合、基本データフィルタ部１２４は、データ識別子に対応するデータ用キューに受信したデータを格納する。

基本データフィルタ部１２４は、受信したデータのフィルタ条件を確認し（ステップＳ１６０５）、データ用キューの状態がフィルタ条件を満たすか否かを判定する（ステップＳ１６０６）。

具体的には、基本データフィルタ部１２４は、ステップＳ１６０３において検索されたエントリのフィルタ条件１４０２を確認する。基本データフィルタ部１２４は、データ用キューにおけるデータの蓄積状態に基づいて、当該データ用キューの状態がフィルタ条件１４０２を満たすか否かを判定する。

データ用キューの状態がフィルタ条件を満たさないと判定された場合、基本データフィルタ部１２４は、処理を終了する。

データ用キューの状態がフィルタ条件と満たすと判定された場合、基本データフィルタ部１２４は、フィルタ条件１４０２に格納されたデータ破棄率に基づいて、データ収集サーバ１００に送信するデータを選択する（ステップＳ１６０７）。

具体的には、基本データフィルタ部１２４は、フィルタ条件１４０２に格納されるデータ破棄率にしたがって、データ用キューに格納されるデータから所定数のデータ又は所定量のデータを破棄する。データ用キューに格納されるデータがデータ収集サーバ１００に送信されるデータとなる。

基本データフィルタ部１２４は、データ用キューに格納される複数のデータを一つのデータに集約して、集約されたデータをデータ収集サーバ１００に転送し（ステップＳ１６０８）、処理を終了する。

以下、本発明の具体例を説明する。

図１７は、本発明の実施例１のデータ収集システムにおけるデータ数集約のアルゴリズムにしたがって実行されるフィルタ制御の流れを説明するシーケンス図である。

以下の説明では、データ収集サーバ１００は、センサＡ（１３０−１）からデータ識別子３０１が「Ａ」であるデータを受信しているものとする。また、データ管理テーブル１１０は図２示すようなものになっており、また、アルゴリズム選択テーブル１１４は図８に示すようなものとする。

ステップＳ１７０１の状態では、データ収集サーバ１００は、センサＡ（１３０−１）からしきい値の範囲内のデータを受信している。

ステップＳ１７０２の状態では、受信データ数が増加し、データ受信状態テーブル１１２は図６に示すような状態になっているものとする。また、負荷監視テーブル１１３は図７に示すような状態になっているものとする。

このとき、負荷要素７０１がサーバの受信パケット数に対応するエントリの現在値７０２の値が「１２００」であり、しきい値７０３の値の「９００」を超過している。したがって、ステップＳ１７０３において、負荷監視部１０６は、サーバの受信パケット数がしきい値７０３を超過していることを検出し、フィルタ管理部１０７を呼び出す。このとき、フィルタ管理部１０７には、負荷情報が送信される（ステップＳ９０１）。

ステップＳ１７０４において、フィルタ管理部１０７は、サーバの受信パケット数を検索キーとして、アルゴリズム選択テーブル１１４から適用するフィルタ制御アルゴリズムを選択する（ステップＳ９０２）。ここでは、データ数集約のアルゴリズムが選択される。

フィルタ管理部１０７は、優先度３０３の低いものから順にデータ受信状態テーブル１１２のエントリを並び替えることによってフィルタ対象データリストを生成する（ステップＳ９０３）。

図６に示すデータ管理テーブル１１０では、データ識別子３０１が「Ａ」のデータはデータ識別子３０１が「Ｂ」のデータより優先度が低い、すなわち、優先度３０３の値が大きいため、フィルタ対象データリストの先頭エントリはデータ識別子３０１が「Ａ」のデータのエントリとなる。

フィルタ管理部１０７は、フィルタ対象データリストを用いて、データ数集約のアルゴリズムにしたがったフィルタ制御処理を実行する（ステップ９０４）。具体的には、図１２に示すようなフィルタ制御処理が実行される。

データ数集約のアルゴリズムでは、フィルタ管理部１０７は、サーバの受信パケット数の現在値７０２からしきい値７０３の差を減算することによって、必須削減データ数を「２００」として算出する（ステップＳ１２０１）。また、目標削減データ量は「１００」と算出される（ステップＳ１２０２）。

データ識別子が「Ａ」のデータについては、削減可能なデータ数が「２００」であるため、目標削減データ数より大きい。したがって、フィルタ管理部１０７は、受信予定数を「５０」と算出し、さらに、受信数６０２の「２５０」を受信予定数の「５０」で除算することによって、データ集約数を「５」と決定する（ステップＳ１２０５）。

ステップＳ１７０５において、フィルタ管理部１０７は、中間サーバ１２０にフィルタ条件設定指示を送信し、また、フィルタ状態管理テーブル１２０８を更新する。このとき、フィルタ状態管理テーブル１１１は、図４及び図５に示すように更新される（ステップ１２０８）。

中間サーバ１２０のフィルタ制御部１２６は、フィルタ条件設定指示を受信し、基本フィルタテーブル１２８に新たなエントリを生成する。フィルタ制御部１２６は、生成されたエントリのデータ識別子１４０１が「Ａ」を格納し、フィルタ条件１４０２に図５に示すようなフィルタ条件の値を格納する。

データ識別子Ａに対してフィルタが設定されたため、中間サーバ１２０は、センサＡ（１３０−１）から受信したデータ識別子が「Ａ」のデータがデータ用キューに五つ蓄積された時に、当該五つのデータを一つのデータに集約し、集約されたデータをデータ収集サーバ１００に送信する。

したがって、ステップＳ１７０６のように、データ収集サーバ１００に送信されるデータ数が削減される。本具体例では、データ識別子が「Ａ」のデータのみを受信しているため、この時点でデータ収集システムの負荷の低減が実現される。なお、複数のデータ種別のデータの場合も同様の処理が実行されることとなる。

以上、実施例１によれば、データ収集システムの負荷の増加に応じて、データ収集サーバ１００に送信されるデータのデータ量又はデータ数を削減することによって、データ収集サーバ１００の負荷を低減することが可能となる。

実施例１では、全ての中間サーバ１２０に対して、データの種別毎のフィルタが設定されていたが、実施例２では、中間サーバ１２０毎の負荷の状態に応じて、フィルタを設定する中間サーバ１２０が選択される点が異なる。

以下、実施例１との差異を中心に説明する。

図１８は、本発明の実施例２におけるデータ収集システムの構成例を示す説明図である。

図１８に示す各機能ブロックのうち、図１に示す実施例１のデータ収集システムの構成例と同一の符号を付与したものに関しては、同一の機能を有するものであるため、説明は省略する。

図１８に示すように、本実施例では、中間サーバ１２０が新たに負荷監視部１８１０を備え、また、データ収集サーバ１００が新たにリソース管理テーブル１８００を備える。

負荷監視部１８１０は、周期的に、中間サーバ１２０の負荷、すなわち、リソース使用状態を監視し、データ収集サーバ１００に、監視結果であるリソース使用状態を含む情報を送信する。

リソース管理テーブル１８００は、各中間サーバ１２０のリソース使用状態に関する情報を格納する。データ収集サーバ１００の負荷監視部１０６は、各中間サーバ１２０から監視結果を受信するたびに、リソース管理テーブル１８００を更新する。

本実施例では、データ収集サーバ１００は、中間サーバ１２０毎にフィルタ状態管理テーブル１１１を保持する。これは、中間サーバ１２０のそれぞれに設定されるフィルタが異なるためである。また、データ収集サーバ１００は、中間サーバ１２０毎にデータ受信状態テーブル１１２を保持する。

実施例２のデータ収集サーバ１００、及び中間サーバ１２０のハードウェア構成は実施例１と同一であるため説明を省略する。また、実施例２のデータ収集サーバ１００、及び中間サーバ１２０が保持するテーブルは、実施例１と同一のものであるため説明を省略する。

図１９は、本発明の実施例２のデータ収集サーバ１００が保持するリソース管理テーブル１８００の一例を示す説明図である。

リソース管理テーブル１８００は、中間サーバ識別子１９０１、リソース１９０２、現在値１９０３、及び上限値１９０４を含む。

中間サーバ識別子１９０１は、中間サーバ１２０を識別するための識別子を格納するフィールドである。

リソース１９０２は、中間サーバ１２０が備えるリソースを識別するための情報を格納するフィールドである。中間サーバ１２０が備えるリソースの情報としては、ネットワークの帯域利用率、パケット処理量、ＣＰＵ使用率、及びディスク容量等が考えられる。

現在値１９０３は、現在の中間サーバ１２０におけるリソース１９０２に対応する値を格納するフィールドである。現在値１９０３に格納される値は、負荷監視部１８０１によって周期的に更新される。

上限値１９０４は、中間サーバ１２０におけるリソース１９０２に対して設定された上限値を格納するフィールドである。

実施例２における処理は、負荷削減アルゴリズムにおける処理が実施例１と異なる。その他の処理は実施例１と同一の処理が実行される。

図２０は、本発明の実施例２のフィルタ管理部１０７がデータ集約のアルゴリズムにしたがって実行するフィルタ制御処理の一例を説明するフローチャートである。

実施例２のフィルタ制御処理は実施例１と同様の処理が実行され、図１２と同一の符号が付与された処理ステップは実施例１と同一であるため説明は省略する。

実施例２では、データ集約数が決定された後、リソースに余裕のある中間サーバ１２０に対してフィルタ条件設定指示が送信される点が実施例１と異なる。以下、実施例１のフィルタ制御処理との差異について説明する。

データ集約数の決定後（ステップＳ１２０５）、フィルタ管理部１０７は、選択されたデータを送信する中間サーバ１２０のリストを取得する（ステップＳ２００１）。具体的には、以下のような処理が実行される。

フィルタ管理部１０７は、選択されたデータの識別子を検索キーとして、一つのデータ受信状態テーブル１１２を参照する。さらに、フィルタ管理部１０７は、データ識別子６０１が選択されたデータの識別子と一致するエントリが含まれるか否かを判定する。

データ識別子６０１が選択されたデータの識別子と一致するエントリが含まれていないと判定された場合、フィルタ管理部１０７は、次のデータ受信状態テーブル１１２に対して同一検索処理を繰り返し実行する。

一方、データ識別子６０１が選択されたデータの識別子と一致するエントリが含まれていると判定された場合、フィルタ管理部１０７は、データ受信状態テーブル１１２に対応する中間サーバ１２０をリストに追加する。その後、フィルタ管理部１０７は、次のデータ受信状態テーブル１１２に対して同一の検索処理を繰り返し実行する。

次に、フィルタ管理部１０７は、リソース管理テーブル１８００、及び取得された中間サーバ１２０のリストに基づいて、リソースに余裕がある中間サーバ１２０に対してフィルタ条件設定指示を送信する（ステップＳ２００２）。ステップＳ２００２の具体的な処理については、図２１を用いて後述する。

次に、フィルタ管理部１０７は、中間サーバ１２０にフィルタ条件設定指示を送信することによって削減されるデータの削減数を削減予定データ数に加算する（ステップＳ２００３）。

図２１は、本発明の実施例２のステップＳ２００２において実行される処理の詳細を説明するフローチャートである。

フィルタ管理部１０７は、取得された中間サーバ１２０のリストから、一つの中間サーバ１２０を選択する（ステップＳ２１０１）。ここでは、リストの上のエントリから順に選択されるものとする。なお、中間サーバ１２０毎に重要度等の選択指標を設定しておき、当該選択指標に基づいて、リストから中間サーバ１２０が選択されてもよい。

フィルタ管理部１０７は、中間サーバ１２０のリストから選択可能な中間サーバ１２０が存在するか否かを判定する（ステップＳ２１０２）。

中間サーバ１２０のリストから選択可能な中間サーバ１２０が存在しないと判定された場合、フィルタ管理部１０７は、フィルタ条件設定指示を送信する対象の中間サーバ１２０が存在していないため、処理を終了する。

中間サーバ１２０のリストから選択可能な中間サーバ１２０が存在すると判定された場合、フィルタ管理部１０７は、リソース管理テーブル１８００の選択された中間サーバ１２０に対応するエントリを参照する（ステップＳ２１０３）。

フィルタ管理部１０７は、選択された中間サーバ１２０のリソースに余裕があるか否かを判定する（ステップＳ２１０４）。

例えば、フィルタ管理部１０７は、ＣＰＵ使用率の現在値１９０３及び上限値１９０４を参照し、新たにフィルタが設定された場合におけるＣＰＵ使用率を算出し、算出されたＣＰＵ使用率が上限値１９０４の値より小さい場合に、選択さえた中間サーバ１２０のリソースに余裕があると判定する。なお、新たにフィルタが設定された場合の、ＣＰＵ利用率の上昇値は、フィルタ毎に予め定められた定数を用いること等が考えられる。

また、前述した判定処理では、着目するリソース１９０２がＣＰＵ利用率であったが、フィルタが設定された場合における中間サーバ１２０のメモリ使用量又はストレージ使用容量等を指標としてもよい。この場合、中間サーバ１２０のメモリ使用量又はストレージ使用容量が上限値１９０４の値より小さい場合、選択された中間サーバ１２０のリソースに余裕があると判定される。

選択された中間サーバ１２０のリソースに余裕があると判定された場合、フィルタ管理部１０７は、選択された中間サーバ１２０にフィルタが設定された場合の、選択されたデータの削減数を算出し、算出されたデータの削減数を削除予定データ数に加算する（ステップＳ２１０５）。また、フィルタ管理部１０７は、フィルタ状態管理テーブル１１１を更新する（ステップＳ２１０６）。

具体的には、フィルタ管理部１０７は、選択されたフィルタ状態管理テーブル１１１を検索する。フィルタ管理部１０７は、検索されたフィルタ状態管理テーブル１１１を参照して、選択されたデータに対応するエントリを検索する。フィルタ管理部１０７は、検索されたエントリのフィルタ有無４０３にフィルタが設定されている旨を示す情報を格納する。また、フィルタ管理部１０７は、フィルタ条件設定指示に含まれる各値を、検索されたエントリのフィルタ条件４０４に格納する。

選択された中間サーバ１２０のリソースに余裕がないと判定された場合、フィルタ管理部１０７は、ステップＳ２１０１に戻り同様の処理を実行する。

以上、実施例２によれば、各中間サーバ１２０の負荷を考慮して、フィルタを設定することが可能となるため、より効率的なデータ収集システムの負荷分散が実現可能となる。

なお、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体（例えば、非一時的な記憶媒体）に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。本実施例では、ソフトウェアによる制御を用いた例について説明したが、その一部をハードウェアによって実現することも可能である。

以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。

１００ データ収集サーバ
１０１ データ受信部
１０２ データ処理部
１０３ 中間サーバ管理部
１０４ データ管理部
１０５ ＤＢデータ送信部
１０６ 負荷監視部
１０７ フィルタ管理部
１０８ ＤＢデータ受信部
１０９ データベース
１１０ データ管理テーブル
１１１ フィルタ状態管理テーブル
１１２ データ受信状態テーブル
１１３ 負荷監視テーブル
１１４ アルゴリズム選択テーブル
１２０ 中間サーバ
１２１ データ送信部
１２２ データ振分け部
１２３ センサデータ受信部
１２４ 基本データフィルタ部
１２５ 拡張フィルタ部
１２６ フィルタ制御部
１２７ データ振分けテーブル
１２８ 基本フィルタテーブル
１３０ センサ
１４０ ネットワーク
１８００ リソース管理テーブル
１８１０ 負荷監視部

Claims (7)

1. 所定のデータ種別のデータを送信する複数のセンサ、前記複数のセンサから送信されるデータを転送する複数のサーバ、及び、前記複数のサーバから転送されたデータを受信し、受信したデータを蓄積するデータ収集サーバを備える計算機システムであって、
   前記複数のサーバの各々は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のネットワークインタフェースを有し、
   前記データ収集サーバは、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、及び前記第２のプロセッサに接続される第２のネットワークインタフェースを有し、
   前記データ収集サーバは、
   前記計算機システムにおける負荷を監視する負荷監視部と、
   前記負荷の監視結果に基づいて、前記複数のサーバにおけるデータの転送処理の内容を決定し、前記決定されたデータの転送処理の内容を送信する管理部と、を有し、
   前記管理部は、
   前記複数のサーバに適用する転送処理の種別を決定し、
   前記決定された転送処理の種別に基づいて、前記データ収集サーバに転送されるデータのうち、当該転送処理が適用されるデータのリストである処理対象データリストを生成し、
   前記決定された転送処理の種別、及び前記生成された処理対象データリストに基づいて、前記複数のサーバに適用する転送処理の内容を決定することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記複数のサーバの各々は、
   前記複数のセンサから送信されるデータの中から、前記データ収集サーバに転送するデータを取得するためのフィルタ処理を実行する複数のフィルタ部と、
   前記複数のフィルタ部によって実行される前記フィルタ処理を制御するフィルタ制御部と、
   前記複数のセンサから送信されるデータのデータ種別に基づいて、前記複数のフィルタ部の中から、当該データを処理するフィルタ部を選択するフィルタ振分け部と、
   前記複数のセンサから送信されるデータのデータ種別、フィルタ部の識別情報、及び前記フィルタ処理の種別が対応づけられたフィルタ管理情報と、を有し、
   前記データ収集サーバは、前記計算機システムの負荷の種別毎に、前記複数のサーバにおいて適用される前記フィルタ処理の種別を管理するアルゴリズム選択情報を有し、
   前記管理部は、
   前記負荷の監視結果及び前記アルゴリズム選択情報に基づいて、前記複数のサーバに適用するフィルタ処理の種別を決定し、
   前記決定されたフィルタ処理の種別に基づいて、前記データ収集サーバが蓄積するデータのうち、前記決定されたフィルタ処理の種別に対応するフィルタ処理が適用されるデータを抽出することによって前記処理対象データリストを生成し、
   前記決定されたフィルタ処理の種別、及び前記生成された処理対象データリストに基づいて、前記複数のサーバに適用するフィルタ処理の内容を決定し、
   前記複数のサーバに、前記決定されたフィルタ処理の内容を含む設定指示を送信し、
   前記フィルタ制御部は、受信した前記設定指示に基づいて、前記フィルタ管理情報を更新し、
   前記フィルタ振分け部は、前記複数のセンサから送信されるデータを受信した場合に、前記フィルタ管理情報に基づいて、前記受信したデータを所定の前記フィルタ部に送信し、
   前記複数のフィルタ部の各々は、前記フィルタ管理情報に基づいて、前記受信したデータに対してフィルタ処理を実行することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記管理部は、
   前記フィルタ処理の内容を決定する場合に、前記負荷の監視結果に基づいて、前記計算機システムにおけるデータ削減量又はデータ削減数である第１のデータ削減目標値を算出し、
   前記複数のセンサから送信されるデータのデータ種別毎のデータ削減量又はデータ削減数である第２のデータ削減目標値を算出し、
   前記生成された処理対象リスト、前記算出された第１のデータ削減目標値、及び前記算出された第２のデータ削減目標値に基づいて、前記生成された処理対象データリストに含まれるデータ種別毎の削減値を決定することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記管理部は、前記複数のセンサから送信されるデータの種別、及び当該データの種別に対応するデータの破棄が可能か否かを示す情報が対応づけられたエントリを含むデータ管理情報を保持し、
   前記フィルタ処理が適用されるデータの処理対象リストを生成する場合に、前記データ管理情報を参照し、
   前記データ管理情報から、データの破棄が許可されたデータのエントリを抽出し、前記抽出されたエントリをリスト化することによって前記処理対象データリストを生成することを特徴とする計算機システム。
5. 請求項３に記載の計算機システムであって、
   前記管理部は、前記複数のセンサから送信されるデータのデータ種別、当該データ種別に対応するデータの現在の受信数又は受信量を表す第１の受信値、及び当該データの種別に対応するデータの過去の受信数の平均値又は受信量の平均値である第２の受信値が対応づけられたエントリを含むデータ受信状態情報を保持し、
   前記フィルタ処理が適用されるデータの処理対象リストを生成する場合に、前記データ受信状態情報を参照し、
   所定の時間間隔における受信数又は受信量の増加幅が大きいデータのデータ種別の順に、前記データ受信状態情報に含まれる前記エントリを抽出し、前記抽出されたエントリをリスト化することによって前記処理対象データリストを生成することを特徴とする計算機システム。
6. 請求項３に記載の計算機システムであって、
   前記管理部は、前記複数のセンサから送信されるデータの種別、前記複数のセンサから送信されるデータの種別に対応するデータの重要性を示す優先度、及び前記複数のサーバにおいて当該データ種別のデータを一時的に蓄積可能な時間である許容遅延時間が対応づけられエントリを含むデータ管理情報を保持し、
   前記管理部は、前記データの重要性の高い順、又は前記許容遅延時間が長い順に、前記データ管理情報に含まれるエントリを抽出し、前記抽出されたエントリをリスト化することによって前記処理対象データリストを生成することを特徴とする計算機システム。
7. 請求項２に記載の計算機システムであって、
   前記データ収集サーバは、前記複数のサーバの各々の計算機リソースの負荷を監視するリソース管理情報を保持し、
   前記複数のサーバ毎に、前記複数のセンサから送信されるデータの種別、当該データの種別に対応するデータの現在の受信数、及び当該データの種別に対応するデータの過去の受信数の平均値が対応づけられたエントリを含むデータ受信状態情報を保持し、
   前記管理部は、
   前記データ受信状態情報を参照して、前記処理対象データリストに含まれるエントリに対応するデータを転送するサーバを特定し、
   前記リソース管理情報を参照して、前記特定されたサーバの中から、前記計算機リソースの負荷が小さいサーバを選択し、
   前記選択されたサーバに前記設定指示を送信することを特徴とする計算機システム。

Images