2007年度 森基金報告書 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
研究課題名:高サンプリングレート下でのセンサデータ集約システム氏名:森 雅智 所属: 政策・メディア研究科 1年 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
高サンプリングレートが要求されるセンサネットワークアプリケーションにおいて,データ量の増加に伴うセンサノードの電力消費量増大の問題は重要な課題である.高サンプリングレートでのセンシングにおいては,センサが取得した生データを全て直接シンクノードやサーバに送るのでは,バッテリ寿命の短命化や無線帯域の圧迫によるデータ損失という問題が発生してしまう.そこで,本研究ではセンサノードが取得したデータをサーバに送る前に要約・圧縮する手法を提案する. 本研究の研究成果はUNS2007実証実験においてデモンストレーションを行った. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
問題意識昨今のセンサネットワークアプリケーションで用いられるセンサには,温度センサ,湿度センサ,加速度センサなどの様々なセンサがあるが,それぞれのセンサによってデータをセンシングするサンプリングレートが異なる.環境センシングでは数秒から数時間といった長い周期であるが,加速度,音などのセンサでは通常数ミリ秒程度の周期 でのセンシングが要求される.また,センサを設置する環 境によってセンサノードに要求されるバッテリ寿命が異なる.こうしたセンサ毎の区分を図1 にまとめる. 図1:センサとバッテリ寿命・サンプリングレートの関係
本研究では以下のシナリオを対象としてシステムの構築を行った. Live! Commerce Akiba -実世界興味情報収集システムLive! Commerce Akibaは,お店で売っている商品にセンサを取り付けることで,顧客が展示品に興味を持って触ったという情報や,複数の同種の製品を比較したという情報を収集することが出来るシステムである.システムの概要は別添付資料にまとめる. 機能要件本システムの機能要件を以下にまとめる.
システム設計本システムの設計方針は以下の通りである.
また,本システムの物理構成は図2の通りである. 図2:物理構成図 Akibaサーバは全店舗の設定データ,イベントデータを保存し,外部からのデータ要求に答える.店舗側サーバ群は各店舗毎に用意され,店舗内のセンサデータを収集,データ集約及びイベント解析を行い,Akibaサーバへのデータ送信を行う. 本システムの論理構成は図3の通りである. 図3:論理構成図 各モジュール間は図で指定されたプロトコルを用いて相互に通信を行う.
以上の中で本研究に強く関連するのは店舗イベント管理モジュールである.本モジュールの設計について詳しく解説する. センサデバイスの選定今回,センサデバイスにはTeCO uPartを用いた,uPartを用いた理由は以下の通りである.
本デバイスに取り付けられたセンサは照度・温度・振動センサの三種類である.それぞれ8bitの精度を持つ. 店舗イベント管理モジュールの設計Live! Commerce Akibaシステムにおいて,店舗イベント管理モジュールの構成は図4の通りである. 図4:店舗イベント管理モジュールの設計 uPartでは,センサのデータが生データのまま店舗サーバへと送信される.またuPartセンサは設定した周期毎にデータを送信させることができる.今回,センサを展示商品に取り付け,顧客が商品に触れた情報を検出したいため,センシング周期は1秒に設定した.展示商品の数は設置場所にもよるが,センサを取り付けた商品の数は1エリアにつき約10〜30個程度の数となった. イベント解析エンジンの設計イベント解析エンジンは,生データの入力列からイベントデータを抽出する.生データをイベントデータに抽象化することで,センサ毎の違いを吸収し,それぞれの生データ列を顧客の動作イベントとして収集することが出来る.本システムでは,イベントデータは以下のフォーマットで定義した.データタイプはMySQLで用いたデータ型である
イベント発生日時は店舗サーバがそのイベントが発生した時間を記録する.イベントタイプは発生したイベントの種類を表し,uPartを使ったシステムの例ではtouch:触った,hold:持っているといった情報を扱う.エリアIDは店舗毎にユニークな値がセットされる.商品IDはAkibaサーバ側で管理されている商品データベースのIDであり,センサデバイス・商品の対応付け情報はシステム起動時に設定情報管理モジュールから取得される.最後に拡張領域は予約領域として確保してある.これはイベントデータはXMLデータとして送信するため,今後より詳細なデータを格納したくなった場合に利用することを想定している. イベント解析エンジンの実装実装はJavaを用いて行った.これはuPartがJavaを使った開発をサポートしているためで,開発言語についてはセンサデバイスのデータを取得出来るものであれば何でも良い.最終的にイベント転送モジュールに対してXMLイベントデータを送信出来ることが重要である. 実際にイベント解析エンジンを実装する際には,センサデバイスをどのような商品にどのように取り付けるかによって大きくイベントの生成ルールが異なる.今回のシステムでは,商品として携帯電話とフィギュア,センサはそれぞれ裏面に取り付けた.これによって,携帯電話を商品棚に置いた際にはセンサが棚と携帯電話に挟まれるため,照度が暗くなり照度センサによって携帯電話を手に取ったという情報を検出できる.また,内蔵された振動センサも併せて用いることで,イベント検出の精度を向上させた. 実証実験本システムは2007年11月29-30日に開催されたUNS2007にて実証実験を行った.実証実験はUNS2007会場である秋葉原UDX以外にオノデン本店1F,及びカイヨウドウにて実際の店舗でも行った.2日間の実験で取得できたデータから本システムの評価を行った. データ圧縮率の評価本システムはUNS2007開催期間中,店舗の閉店時間以外は常時動作させていた.そのため動作時間は9:00〜22:00までとなる.それまでに発生したイベント数は各エリア毎に表1の通りとなる.
これらのイベント数から,生データを直接サーバに送っている場合とのデータ量の比較を行う. まず,生データの場合であるが,これは以下のデータで構成されている
このうち,温度データは本システムでは利用しないため,生データの量はセンシング一回につき10バイトとなる.よって,端末1台辺りの生データ量はタイムスタンプ(14バイト)を加えて ( 14 + 10 ) [バイト] * ( 60 * 60 * 13 ) [秒] = 1,123,200 [バイト] となる. 次に,イベントデータは以下のデータで構成されている
今回のシステムでは拡張領域は未使用のため0バイトとなる.この際イベント一つあたりのデータ量は 30 [バイト] * イベント数 となるので,各エリア毎のデータ圧縮率は表2の通りである.
以上から,特にイベント数の少ないエリアにおいては効果的な圧縮が行われていることが分かる. まとめ本研究では高サンプリングレート化でのセンサデータ要約システムの対象として,顧客の興味情報収集システムを構築,データ解析システムを実装,圧縮率の評価を行った. 今後の課題としては,今回顧客の興味情報抽出システムを対象としてデータ解析エンジンを作成したが,興味情報抽出だけでなく,より汎用的なデータ抽出ロジックを考えていく必要があると感じる.また,本システムの今後の展開としては,uPartだけではなく他の性質の異なるセンサデバイスも実際に混在させていくことで,さらに改良の余地を見いだしていき完成度を高めていきたい.
|