2007年度 森基金報告書

研究課題名：高サンプリングレート下でのセンサデータ集約システム

氏名：森 雅智

所属： 政策・メディア研究科 1年

問題意識

　昨今のセンサネットワークアプリケーションで用いられるセンサには，温度センサ，湿度センサ，加速度センサなどの様々なセンサがあるが，それぞれのセンサによってデータをセンシングするサンプリングレートが異なる．環境センシングでは数秒から数時間といった長い周期であるが，加速度，音などのセンサでは通常数ミリ秒程度の周期 でのセンシングが要求される．また，センサを設置する環 境によってセンサノードに要求されるバッテリ寿命が異なる．こうしたセンサ毎の区分を図1 にまとめる．

図１：センサとバッテリ寿命・サンプリングレートの関係

　この中でも，生体センサや音響センサといったセンサノード 自身に与えられたバッテリのみで稼働し続けることを要求され，さらに要求されるサンプリングレートの高いセンサをセンサネットワークアプリケーションは，膨大なセンシングデータを送信する電力コストが大きな問題となる．また，こうした単体で高サンプリングレートを要求するセンサ以外でも，センサの数が膨大になることにより送信データ量が増大する問題が発生し，同様の問題が発生する．本研究では，こうした高サンプリングレートのセンシングにおいて適用可能なデータ集約システムの構築を目指す．

　本研究では以下のシナリオを対象としてシステムの構築を行った．

Live! Commerce Akiba -実世界興味情報収集システム

　Live! Commerce Akibaは，お店で売っている商品にセンサを取り付けることで，顧客が展示品に興味を持って触ったという情報や，複数の同種の製品を比較したという情報を収集することが出来るシステムである．システムの概要は別添付資料にまとめる．

機能要件

　本システムの機能要件を以下にまとめる．

• 多種多様なセンサデバイスを利用可能であること

センサデバイスの進化は著しく，数ヶ月〜数年の間に大きく事情が変化する．そのため一つのセンサデバイスに偏った設計では安定運用は難しい．新しいセンサデバイスについても大きなシステム変更をすることなく，可能であればシステムを停止させずに追加・変更出来ることが求められる．

• 店舗側での運用に必要な人的コストが最小限であること

商品とセンサの対応付けや商品情報登録，電池交換などの仕事を店舗従業員に任せるのは，人件費や教育コストの面から難しい．そのため，可能な限り店舗側での設定の手間を省く必要がある．

• メンテナンス性が確保されていること

センサデバイスの故障や電池切れに伴う設定変更や，サーバの追加・削除といった定期メンテナンスが必要となるため，システム全体の把握ができ，各種設定を一元的にメンテナンス出来る必要がある．

システム設計

　本システムの設計方針は以下の通りである．

• センサデータ収集部のモジュール化による拡張性の確保

生のセンサデータを直接サーバ側で扱うのではなく，クライアントサイドでイベントデータに変換する．これにより，どうしてもセンサデバイスに依存してしまうセンサデータ収集・解析部を別モジュールとして切り分けられる．解析したイベントデータを店舗サーバにイベント処理を依頼することで，異種センサデバイスの同時運用を可能とする．

• システム設定の一元化によるメンテナンス性の確保

システム設定情報をクライアントサイドに置かず，サーバサイドに全てまとめておくことで，店舗側での設定項目を最小限にする．

• クライアント・サーバシステムによるシステム全体の単純化

店舗側をクライアント，Akibaサーバ側をサーバとしたクライアント・サーバシステム構成とすることで各サーバの役割を単純化する．

　また，本システムの物理構成は図2の通りである．

図2：物理構成図

　Akibaサーバは全店舗の設定データ，イベントデータを保存し，外部からのデータ要求に答える．店舗側サーバ群は各店舗毎に用意され，店舗内のセンサデータを収集，データ集約及びイベント解析を行い，Akibaサーバへのデータ送信を行う．

　本システムの論理構成は図3の通りである．

図3：論理構成図

　各モジュール間は図で指定されたプロトコルを用いて相互に通信を行う．

• 店舗イベント管理モジュール

センサデバイスからのデータ取得，イベント解析を担当する．本研究における集約機能はこのモジュールに実装されている．

• イベント転送モジュール

店舗サーバからのイベントデータを転送する．店舗が増加した際の負荷分散のために別モジュールとして切り分けられている．

• データ管理・解析モジュール

イベントデータ，商品データ，センサデバイスの管理・解析を行う．イベントデータはMySQLデータベースに格納されている．

• 設定情報管理モジュール

全店舗サーバの設定情報，センサデバイスの店舗への対応情報などを管理する．

• システム管理モジュール

システム管理者のための管理画面を提供する．

　以上の中で本研究に強く関連するのは店舗イベント管理モジュールである．本モジュールの設計について詳しく解説する．

センサデバイスの選定

　今回，センサデバイスにはTeCO uPartを用いた，uPartを用いた理由は以下の通りである．

• センサデバイスの大きさが切手サイズと店頭商品に取り付け可能な程度に十分小さい．
• ボタン型電池1つでセンシング周期1秒の設定にした状態で数ヶ月という十分な電池寿命を持つ．
• 1ノードの価格がセンサデバイスの中では5000円程度と比較的安く，大量に導入しやすい．

　本デバイスに取り付けられたセンサは照度・温度・振動センサの三種類である．それぞれ8bitの精度を持つ．

店舗イベント管理モジュールの設計

　Live! Commerce Akibaシステムにおいて，店舗イベント管理モジュールの構成は図4の通りである．

図4：店舗イベント管理モジュールの設計

　uPartでは，センサのデータが生データのまま店舗サーバへと送信される．またuPartセンサは設定した周期毎にデータを送信させることができる．今回，センサを展示商品に取り付け，顧客が商品に触れた情報を検出したいため，センシング周期は1秒に設定した．展示商品の数は設置場所にもよるが，センサを取り付けた商品の数は1エリアにつき約10〜30個程度の数となった．

イベント解析エンジンの設計

　イベント解析エンジンは，生データの入力列からイベントデータを抽出する．生データをイベントデータに抽象化することで，センサ毎の違いを吸収し，それぞれの生データ列を顧客の動作イベントとして収集することが出来る．本システムでは，イベントデータは以下のフォーマットで定義した．データタイプはMySQLで用いたデータ型である

• イベント発生日時：timestamp
• イベントタイプ：varchar
• エリアID：integer
• 商品ID：integer
• 拡張領域：text

　イベント発生日時は店舗サーバがそのイベントが発生した時間を記録する．イベントタイプは発生したイベントの種類を表し，uPartを使ったシステムの例ではtouch：触った，hold：持っているといった情報を扱う．エリアIDは店舗毎にユニークな値がセットされる．商品IDはAkibaサーバ側で管理されている商品データベースのIDであり，センサデバイス・商品の対応付け情報はシステム起動時に設定情報管理モジュールから取得される．最後に拡張領域は予約領域として確保してある．これはイベントデータはXMLデータとして送信するため，今後より詳細なデータを格納したくなった場合に利用することを想定している．

イベント解析エンジンの実装

　実装はJavaを用いて行った．これはuPartがJavaを使った開発をサポートしているためで，開発言語についてはセンサデバイスのデータを取得出来るものであれば何でも良い．最終的にイベント転送モジュールに対してXMLイベントデータを送信出来ることが重要である．

　実際にイベント解析エンジンを実装する際には，センサデバイスをどのような商品にどのように取り付けるかによって大きくイベントの生成ルールが異なる．今回のシステムでは，商品として携帯電話とフィギュア，センサはそれぞれ裏面に取り付けた．これによって，携帯電話を商品棚に置いた際にはセンサが棚と携帯電話に挟まれるため，照度が暗くなり照度センサによって携帯電話を手に取ったという情報を検出できる．また，内蔵された振動センサも併せて用いることで，イベント検出の精度を向上させた．

実証実験

　本システムは2007年11月29-30日に開催されたUNS2007にて実証実験を行った．実証実験はUNS2007会場である秋葉原UDX以外にオノデン本店１F，及びカイヨウドウにて実際の店舗でも行った．2日間の実験で取得できたデータから本システムの評価を行った．

データ圧縮率の評価

　本システムはUNS2007開催期間中，店舗の閉店時間以外は常時動作させていた．そのため動作時間は9:00〜22:00までとなる．それまでに発生したイベント数は各エリア毎に表１の通りとなる．

　これらのイベント数から，生データを直接サーバに送っている場合とのデータ量の比較を行う．

　まず，生データの場合であるが，これは以下のデータで構成されている

• センサID：8 バイト
• 照度データ： 1 バイト
• 振動数データ：1 バイト
• 温度データ：1 バイト

　このうち，温度データは本システムでは利用しないため，生データの量はセンシング一回につき10バイトとなる．よって，端末1台辺りの生データ量はタイムスタンプ（14バイト）を加えて

( 14 + 10 ) [バイト] * ( 60 * 60 * 13 ) [秒] = 1,123,200 [バイト]

となる．

　次に，イベントデータは以下のデータで構成されている

• イベント発生日時：14バイト
• イベントタイプ：5〜8バイト
• エリアID：4バイト
• 商品ID：4バイト
• 拡張領域：0バイト

　今回のシステムでは拡張領域は未使用のため0バイトとなる．この際イベント一つあたりのデータ量は

30 [バイト] * イベント数

となるので，各エリア毎のデータ圧縮率は表2の通りである．

　以上から，特にイベント数の少ないエリアにおいては効果的な圧縮が行われていることが分かる．

まとめ

　本研究では高サンプリングレート化でのセンサデータ要約システムの対象として，顧客の興味情報収集システムを構築，データ解析システムを実装，圧縮率の評価を行った．

　今後の課題としては，今回顧客の興味情報抽出システムを対象としてデータ解析エンジンを作成したが，興味情報抽出だけでなく，より汎用的なデータ抽出ロジックを考えていく必要があると感じる．また，本システムの今後の展開としては，uPartだけではなく他の性質の異なるセンサデバイスも実際に混在させていくことで，さらに改良の余地を見いだしていき完成度を高めていきたい．