JP2010049538A - センサデータ処理装置 - Google Patents

Abstract

【目的】負荷増大に対して、特にクライアント数の増大に伴う負荷増大に対して効果的な負荷軽減を図ったセンサデータ処理装置を提供する。
【構成】リクエスト毎に、当該リクエストに対応するデータ属性をフィルタリング条件とする少なくとも１つのフィルタを設定し、設定されたフィルタの適用順を、該リクエストの全てに亘るフィルタ毎の設定頻度に基づいて決定するフィルタ管理部を含み、フィルタ処理部が該フィルタの適用順に従って該センサデータに該フィルタを適用し、データ配信部が該リクエスト毎にその要求条件を充足するデータ片が抽出されると、これを配信する。
【選択図】図２

Description

本発明は、センサネットワークから出力されたセンサデータを複数のアプリケーションからの要求に応じて配信するセンサデータ処理装置に関する。

センサネットワークから多種多様で膨大な量のセンサデータが各種アプリケーションのためにセンサデータ処理装置に出力されるようになると、センサ利用アルゴリズムが複雑化する問題や、冗長センサデータが増加することによってセンサデータ処理装置の処理能力が圧迫されるという問題がある。

「センサデータ振分配信システムおよびその方法」と題する特許文献１では、クライアント（情報要求者）アプリケーションからの要求に応じてセンサデータを適切なクライアントに対して複製し送信する技術を開示している。ここでは、要求条件の異なる複数のクライアントに対して、センサネットワークで集められたセンサデータのうちでクライアント毎の要求条件に合うセンサデータのみが複製されることでクライアント毎に振り分けた送信がなされる。また、送信が不要なセンサＩＤをクライアント毎に登録することによって、不要なセンサＩＤに対応するセンサデータが破棄されることで、センサデータ処理装置の負担増加を抑えることができる。
特開２００７−１２２４３３号公報

しかながら、従来の技術をもってしてもクライアントアプリケーション数の著しい増加に対しては相当の負荷増大が依然として懸念される。必要なセンサデータのみを送信し不要なセンサデータを破棄する構成もクライアント数の増大に伴う負荷増大に対しては有効ではない。

本発明の目的は、負荷増大に対して、特にクライアント数の増大に伴う負荷増大に対して効果的な負荷軽減を図ったセンサデータ処理装置を提供することである。

本発明によるセンサデータ処理装置は、数種のうちの何れかのデータ属性を各々が有する複数のデータ片からなるセンサデータを集信するデータ集信部と、アプリケーション端末の何れかからのリクエストに応じて、該リクエストの要求条件に対応するデータ属性を有するデータ片を、該センサデータのうちから抽出するフィルタ処理部と、抽出されたデータ片を該リクエストに対応するアプリケーション端末に配信するデータ配信部と、を含むセンサデータ処理装置であって、該リクエスト毎に、当該リクエストに対応するデータ属性をフィルタリング条件とする少なくとも１つのフィルタを設定し、設定されたフィルタの適用順を、該リクエストの全てに亘るフィルタ毎の設定頻度に基づいて決定するフィルタ管理部を含み、該フィルタ処理部は該フィルタの適用順に従って該センサデータに該フィルタを適用し、該データ配信部は該リクエスト毎にその要求条件を充足するデータ片が抽出されると、これを配信することを特徴とする。

本発明によるセンサデータ処理装置によれば、各クライアントの要求条件において共通する要求条件に従ったフィルタリングをまとめて行うことができるので、負荷増大に対して、特にクライアント数の増大に伴う負荷増大に対しても効果的に負荷軽減を図ることができる。

本発明の実施例について添付の図面を参照しつつ詳細に説明する。

図１は、本発明の実施例を示し、センサデータ処理装置を含む全体の構成を示している。本図を参照すると、少なくとも１つのセンサネットワーク１と、センサデータ処理装置２と、複数のアプリケーション端末３とが通信網４を介して接続されている。センサネットワーク１は、通常、１つ以上のセンサノード１１とこれらセンサノードを管理する１つのゲートウェイ１２から成る。センサノード１１は、例えば、温度や湿度等の状態量を計測してセンサデータを生成する。生成されたセンサデータはゲートウェイ１２及び通信網４を介してセンサデータ処理装置２に供給される。アプリケーション端末３は、クライアント毎に設けられてセンサデータに多様な処理を行うアプリケーションの実行を提供するクライアント端末であり複数設けられている。センサデータ処理装置２は、通信網４を介してセンサネットワーク１から供給されたセンサデータを集信する一方、アプリケーション端末３から送信された要求条件に一致したセンサデータをアプリケーション端末３に配信する。

尚、補足的に図示されるように、センサデータは、複数のデータ片がストリーム状に生成され、データ片の各々にはセンサノードを識別するためのセンサＩＤが付与されている。また、アプリケーション端末３とセンサデータ処理装置２に更に上位のサーバ装置（図示せず）が接続されて全体の管理を行ってもよい。

図２は、センサデータ処理装置２の内部構成を示している。センサデータ処理装置２は、データ配信部２１と、フィルタ管理部２２と、フィルタ処理部２３と、センサ管理部２４と、データ集信部２５と、通信インタフェース２６と、リクエストテーブル２７と、フィルタ適用テーブル２８とを含む。センサデータ処理装置２は通常のコンピュータによって実現され、上記した各部２１〜２８はハードウェア又はハードウェア上で実行されるソフトウェアにより実現される。

データ配信部２１は、アプリケーション端末３から送信されるリクエストに応じて、その内容である要求条件に従ってリクエストテーブル２７を作成及び管理し、要求条件を充足するセンサデータをアプリケーション端末３に配信する。フィルタ管理部２２は、複数のフィルタを生成又は準備すると共に、フィルタ適用テーブル２８を作成してフィルタの適用順を決定する。フィルタ処理部２３は、フィルタを適用順にセットし、これに従いセンサデータのフィルタリング及びコピーを行い、得られたセンサデータを配信のためにデータ配信部２１に渡す。

センサ管理部２４は、データ属性を管理し、センサＩＤとデータ属性との対応関係を予め記憶し、センサデータを構成する各データ片のセンサＩＤをデータ属性に結びつける、すなわち解決する。データ集信部２５は、センサネットワーク１から出力されたセンサデータを集信して管理し、センサ管理部２４によって解決されたデータ属性を各データ片に付与する。通信インタフェース２６は、センサデータ処理装置２と通信網４との間でリクエストやセンサデータを送受信するためのインタフェースである。

尚、本実施例におけるセンサデータのコピー処理は、センサデータの全部又は一部を通常の用語例に従った複製を行う方法で実現されても、或いはセンサデータを記憶領域に記憶した後にこれを複数回読み出すことで同一内容を得る方法で実現されてもよい。

図３は、フィルタ管理部２２により作成されるリクエストテーブル２７の例を示している。リクエストテーブル２７は、リクエスト毎にセンサデータに対する要求条件をまとめたものであり、結果的にセンサデータに対して適用するべきフィルタの種別を指定している。フィルタは、要求条件として指定されるデータ属性に合致するセンサデータと合致しないセンサデータとをふるい分ける、すなわちフィルタリングを行う機能を備える。従って、各フィルタがどのデータ片を通過せしめるかのフィルタリング条件はデータ属性の種類によって定まる。

本図を参照すると、リクエストテーブル２７には、３種類のリクエストＡ、Ｂ及びＣと、場所及び種別の２カテゴリに分類されるデータ属性をフィルタリングするフィルタの指定との対応関係が設定されている。例えば、リクエストＡは、場所の要求条件としてデータ属性「部屋Ｚ」を要求すると共に、種別の要求条件としてデータ属性「温度」を要求している。結果的に、リクエストＡは、フィルタ（部屋Ｚ）を指定すると共にフィルタ（温度）を指定していることになる。データ属性は、当該センサデータを生成するセンサノードの種別やセンサノードの設置場所等の数種からなり、センサノードの識別情報であるセンサＩＤと関連付けられる情報である。センサＩＤは、センサデータを構成するストリーム状の複数のデータ片の各々に付されている。従って、センサデータを構成する各データ片は、データ属性とセンサＩＤとの対応関係が解決されれば、データ属性に従ったフィルタリングが可能となる。

尚、複数のリクエストの各々にはＡ〜Ｃの如きリクエストを区別するＩＤが付される。１つのリクエストは、１つのアプリケーション端末３に通常対応するが、２つ以上のアプリケーション端末３に対応させてもよい。また、１つのアプリケーション端末３が同時に複数のリクエストをセンサデータ処理装置２に送信することも可能である。
＜本発明の原理＞
本発明の原理について図４及び図５〜図６を参照して以下説明する。上記した図３のリクエストテーブル２７では、３種類のリクエストに２種類のデータ属性が要求条件として指定されている。この場合、そのままリクエスト毎に別々に処理すると、図４に示されるように３種類のリクエストなのでセンサデータのコピーが２回必要になり、３種類のリクエストにそれぞれ２種類の要求条件があるのでフィルタリングが６回（図面中のボックスの数に相当）必要になる。すなわち、図４に示された状況では、各リクエストの要求条件を突き合わせることなく、同じような要求条件であってもリクエスト毎に個別にコピー（複製）や破棄が行われるため効率的ではないことか分かる。

そこで、場所が同じフィルタ（部屋Ｚ）をまとめると、図５Ａに示されるように、フィルタリングが５回に減る。センサデータをコピーする回数は２回で変わらないが、１回は場所でフィルタリングした後なので、センサデータをそのままコピーする場合よりコピーするセンサデータの量が減り、フィルタリング対象のセンサデータの量も減ることになる。

更に、図３の種別が同じフィルタ（温度＋湿度）をまとめる場合も同様で、図６Ａに示されるように、フィルタリングは５回に減り、センサデータをコピーする回数２回のうちの１回は種別でフィルタリングした後なので、センサデータをそのままコピーする場合よりコピーするセンサデータの量が減り、フィルタリング対象のセンサデータの量も減る。

そして更に、部分的に条件が同じフィルタ（温度）及びフィルタ（温度＋湿度）がある場合は、条件が完全に含まれる方のフィルタ（温度）を、条件を含む方のフィルタ（温度＋湿度）の後にしてフィルタリングすると、図５Ａに示された状況は図５Ｂに示される状況になり、図６Ａに示された状況は図６Ｂに示される状況になって、いっそうコピーするセンサデータの量が減ってフィルタリング対象のセンサデータの量も減ることになる。

図７は、図３に示されたリクエストテーブル２７を基に作成されるフィルタ適用テーブル２８を示している。本図の表を参照すると、複数行に要求条件に対応する４つのフィルタが示され、複数列には３種のリクエストと、第１合計値及び第２合計値とが示されている。各行と各列との交差部分の各々には以下に説明する値ｘ，ｙが設定される。４つのフィルタは図３に示されたリクエストテーブル２７から要求条件が指定するデータ属性の組合せとして抽出されたものである。フィルタの適用順は第１合計値及び第２合計値に基づいて決定される。第１合計値はフィルタ毎の設定頻度を表している。第２合計値は要求条件の条件包含関係の度合いを示し、この値が高い程を他の条件を包含していて優先されるべきことを表している。以下、フィルタ適用テーブル２８内の配列要素である各値ｘ，ｙを計算する手順について説明する。

先ず、表記ｘ，ｙのうちのｘの設定について述べると、図３に示されたリクエストテーブル２７からリクエスト毎に当該リクエストの要求条件に対応するフィルタの使用回数が抽出され、これが対応する交差部分に入れられる。例えば、リクエストＡの場合、フィルタ（部屋Ｘ＋部屋Ｙ）はその使用がないことからｘ＝０であり、フィルタ（部屋Ｚ）はその使用があることからｘ＝１であり、フィルタ（温度）はその使用があることからｘ＝１であり、フィルタ（温度＋湿度）はその使用がないことからｘ＝０である。そして、フィルタ単位、すなわち各行について各値ｘを合計した数がその行の第１合計値に設定される。フィルタ（部屋Ｘ＋部屋Ｙ）について見ると、第１合計値はリクエストＣの１回しかないことから１となる。

次に、表記ｘ，ｙのうちのｙの設定は、リクエスト毎に以下の計算を行う。自身の条件が完全に他のフィルタの条件に含まれる劣後フィルタを抽出する。条件を含むほうの他のフィルタを優先フィルタとする。そして、優先フィルタの値ｘに劣後フィルタの値ｘを加えて得られる値を優先フィルタの値ｙに設定する。一方、劣後フィルタの値ｙには、自身の値ｘが優先フィルタに振り替えたことから値ｘ−値ｘとなって０を設定する。

例を上げて説明すると、フィルタ（温度）の条件はフィルタ（温度＋湿度）の条件に包含される。フィルタ（温度）は劣後フィルタであり、フィルタ（温度＋湿度）は優先フィルタと見做される。図中の破線部分のリクエストＡについて見ると、フィルタ（温度）の値ｘは１であり、フィルタ（温度＋湿度）の値ｘは０である。そこで、フィルタ（温度＋湿度）の値ｘ＝０にフィルタ（温度）の値ｘ＝１を加えて得られる値を、フィルタ（温度＋湿度）の値ｙに設定する、すなわち値ｙ＝１に設定する。一方、フィルタ（温度）の値ｙには０が設定される。以上の計算を全てのリクエストついて行った後に、フィルタ単位、すなわち各行について各値ｙを合計してその行の第２合計値に設定する。

フィルタの適用順は、原則として第１合計値の数が大きい順とし、例外的に第１合計値の数が同じ場合には第２合計値の数が大きい順とする。その理由は、第１合計値の数が大きいほど同じフィルタが多く使用されるということから、第１合計値の数が大きいフィルタを優先フィルタとして先に処理するとフィルタリングの回数を減らすことができるからである。また、第１合計値の数が同じ場合は、第２合計値の数が大きいほど他の条件を含みフィルタリング条件がより広いことから、第２合計値の数が大きいフィルタを先に処理する。これにより、コピーするセンサデータの量やフィルタリング対象のセンサデータの量を減らすことができる。以上のようにして、フィルタ適用テーブル２８が作成される。本図の例では、フィルタの適用順に示されるように、フィルタ（温度＋湿度）、次いでフィルタ（部屋Ｚ）、次いでフィルタ（部屋Ｘ＋部屋Ｙ）、最後にフィルタ（温度）の順に適用すればよいことになる。

図８は、図７に示されたフィルタ適用テーブル２８から得られた適用順でフィルタを適用した場合の状況を示している。図示されるように、フィルタリングの回数は４回に減っている。センサデータをコピーする回数は２回で変わらないものの、１回目は種別でフィルタリングされたセンサデータが対象であり、２回目は更に場所でフィルタリングされたセンサデータが対象である。従って、センサデータをそのままコピーする場合よりコピーするセンサデータの量が減ると共に、フィルタリング対象のセンサデータの量も減っている。

図９はセンサデータ処理装置の全体の動作の流れを示している。本図を参照して、センサデータ処理装置の動作について図２に示された構成要素を適宜参照して以降説明する。

先ず、センサデータ処理装置２は、データ配信部２１でアプリケーション端末３からリクエストを受信してリクエストテーブルを作成する（ステップＳ９１）。リクエストは、リクエストＡ〜Ｃの如くＩＤで管理される。データ配信部２１は、また、アプリケーション端末３毎に配信に必要となるネットワークアドレス等の通信設定情報をそのリクエストと共に管理している。

次に、センサデータ処理装置２は、フィルタ管理部２２でフィルタ適用テーブル２８（図７参照）を作成してフィルタの適用順を決定する（ステップＳ９２）。フィルタ適用テーブル２８を作成してフィルタの適用順を決定する動作は、図７に関連して上記した動作である。

次に、センサデータ処理装置２は、データ集信部２５でセンサネットワーク１から出力されたセンサデータを集信する（ステップＳ９３）。次いで、センサ管理部２４でセンサＩＤとデータ属性の対応を解決する（ステップＳ９４）。すなわち、センサ管理部２４で、予め記憶していたセンサＩＤとデータ属性との対応関係に基づいて、センサデータを構成するデータ片毎のそのセンサＩＤから対応するデータ属性を認識する。次いで、データ集信部２５でセンサデータの各データ片に認識されたデータ属性を付与する（ステップＳ９５）。

次に、センサデータ処理装置２は、データ集信部２５からセンサデータをフィルタ処理部に渡す（ステップＳ９６）。次いで、フィルタ処理部２３でフィルタを適用順にセットする（ステップＳ９７）。次いで、フィルタ処理部２３で、このセットされたフィルタを順次用いてセンサデータをフィルタリングしてデータ配信部２１に渡す（ステップＳ９８）。

次に、センサデータ処理装置２は、データ配信部２１でフィルタリングされたセンサデータを各リクエストに対応するアプリケーション端末３に配信する（ステップＳ９９）。アプリケーション端末３への配信は、データ配信部２１でリクエスト毎に管理していた通信設定情報が参照されてなされる。

図１０は、図９に示されたフィルタリング処理（ステップＳ９８）の詳細な動作を示している。前提として、フィルタ処理部２３でフィルタの適用順がセットされており、センサデータはデータ集信部２５からフィルタ処理部２３に渡されている。

先ず、フィルタ処理部２３は、適用順に先頭の（又は次の）フィルタを参照する（ステップＳ１０１）。次いで、参照したフィルタが全ての（又は残っている）リクエストが要求するデータ属性を含むフィルタであるか否かをチェックする（ステップＳ１０２）。参照したフィルタが何れのリクエストの要求するデータ属性を含まないフィルタであるならば（ステップＳ１０３）、フィルタリング適用前のセンサデータをコピーし（ステップＳ１０４）、次のフィルタを参照するステップＳ１０１に戻る。

一方、フィルタ処理部２３は、参照したフィルタが全て（又は残った）リクエストが要求するデータ属性を含むフィルタであるならば（ステップＳ１０３）、実際にセンサデータをフィルタリングする（ステップＳ１０５）。

次に、フィルタ処理部２３は、要求条件を全て充足したリクエストがあるか否かを判定し（ステップＳ１０６）、充足したリクエストがあれば他のリクエストのためにセンサデータのコピーを取った後にデータ配信部２１に渡し配信に供する（ステップＳ１０７）。これにより当該リクエストは必要な処理が終わったことでフィルタリング処理の対象から外される。一方、充足したリクエストが無い場合には次のフィルタを参照するステップＳ１０１に戻る。

次に、フィルタ処理部２３は、全てのリクエストが各々の要求条件を全て充足したか否かを判定し（ステップＳ１０８）、全て充足した場合にはフィルタリング処理を終了する。全て充足していない場合には、次のフィルタを参照するステップＳ１０１に戻る。

以上の処理手順により、図７のフィルタ適用テーブルに従った適用順でフィルタリングを行いつつ、要求条件が充足されたリクエストを順次外すことで効率的なフィルタリングが達成される。

以上の実施例において、複数のアプリケーションからの要求条件において共通するフィルタリング処理をまとめることによって、センサデータの複製回数や複製量あるいはフィルタリング回数やフィルタリング対象データ量を減らすことができる。よって、アプリケーションからの要求条件が増加しても、処理回数やデータ量の増加を抑えて処理効率化が図られ、クライアント数の増大に伴う負荷増大に対して効果的な負荷軽減が図られる。

本発明の一実施例を示し、センサデータ処理装置を含む全体の構成を示すブロック図である。 センサデータ処理装置の内部構成を示すブロック図である。 フィルタ管理部により作成されるリクエストテーブルの例を示す図である。 リクエストテーブルの設定内容に従ってフィルタリングをリクエスト毎に個別に行う状況を説明する説明図である。 場所でまとめて先に処理する状況を説明する説明図である。 図５Ａに示された状況において、さらに条件が完全に他の条件に包含されるフィルタを先に処理する状況を説明する説明図である。 種別でまとめて先に処理する状況を説明する説明図である。 図６Ａに示された状況において、さらに条件が完全に他の条件に包含されるフィルタを先に処理する状況を説明する説明図である。 リクエストテーブルを基にして作成されるフィルタ適用テーブルの例を示す図である。 フィルタ適用テーブルに基づいてフィルタリングを行った場合の状況を説明する説明図である。 センサデータ処理装置の全体の動作の流れを示すフローチャートである。 図９に示したフィルタリング処理の詳細な動作を示すフローチャートである。

符号の簡単な説明

１ センサネットワーク
２ センサデータ処理装置
３ アプリケーション端末
４ 通信網
１１ センサノード
１２ ゲートウェイ
２１ データ配信部
２２ フィルタ管理部
２３ フィルタ処理部
２４ センサ管理部
２５ データ集信部
２６ 通信インタフェース
２７ リクエストテーブル
２８ フィルタ適用テーブル

Claims (4)

1. 数種のうちの何れかのデータ属性を各々が有する複数のデータ片からなるセンサデータを集信するデータ集信部と、アプリケーション端末の何れかからのリクエストに応じて、前記リクエストの要求条件に対応するデータ属性を有するデータ片を、前記センサデータのうちから抽出するフィルタ処理部と、抽出されたデータ片を前記リクエストに対応するアプリケーション端末に配信するデータ配信部と、を含むセンサデータ処理装置であって、
   前記リクエスト毎に、当該リクエストに対応するデータ属性をフィルタリング条件とする少なくとも１つのフィルタを設定し、設定されたフィルタの適用順を、前記リクエストの全てに亘るフィルタ毎の設定頻度に基づいて決定するフィルタ管理部を含み、前記フィルタ処理部は前記フィルタの適用順に従って前記センサデータに前記フィルタを適用し、前記データ配信部は前記リクエスト毎にその要求条件を充足するデータ片が抽出されると、これを配信することを特徴とするセンサデータ処理装置。
2. 前記フィルタ管理部は、前記適用順の決定において、前記フィルタ毎の設定頻度が高い方を優先フィルタとすることを特徴とする請求項１記載のセンサデータ処理装置。
3. 前記フィルタ管理部は、前記適用順の決定において、前記フィルタ毎の設定頻度が同じ複数のフィルタがある場合、当該フィルタリング条件が広いフィルタを優先フィルタとすることを特徴とする請求項１又は２記載のセンサデータ処理装置。
4. 前記複数のデータ片の各々が有するデータ属性を、前記データ片の各々に付与されているセンサＩＤを基に判別するセンサ管理部を更に含むことを特徴とする請求項１〜３の何れか１項記載のセンサデータ処理装置。

Images