PR

図1●センサー・ネットワークの構成
複数のセンサーやアクチュエータを連携させるには,二つの方法がある。ノード間の通信をサーバーが仲介する方法と,ノード同士が直接通信し合う方法だ。
図2●管理者がセンサーを制御
アイピースクエアが公開しているデモ。すべてのセンサーやアクチュエータに,TCP/IPのプロトコル・スタックをワンチップ化した「Agent Processor」が取り付けられている。管理用のパソコンで各センサーの状態を監視し,アクチュエータを制御する。例えば温度センサーは,一定以上の値を検知したら管理者にレポートする。報告を受けた管理者は,ファンを回す。TCP/IPネットワークに接続された機器をネットワーク経由で監視/制御するプロトコルであるSNMPを使っている。
 センサー・ネットワーク──。数年前に登場したこの言葉に,未来のコンピューティング形態が隠れている。

 一見複数のセンサーが連動したシステムにすぎないようだが,実際は違う。無数の多様なセンサーをあらゆる場所に設置して,環境やヒトの動向をリアルタイムに取得する。その情報を基に,これまでとは一線を画したきめ細かなサービスを提供する。だから大量のセンサー同士がつながり,互いに連携しなければならない。ヒトの動きやモノの流れに応じて,動的につながり方が変わる。それがセンサー・ネットワークだ。

 センサー・ネットワークにおける課題が,アプリケーションが必要とするセンサーをどうやって選び出し,システムとして統合するか,である。あらかじめ固定されたセンサーを組み合わせる既存のシステムと異なり,動的に再構成する仕組みが必要となる。方向性は大きく二つ(図1[拡大表示])。一つは,ノード間の通信を仲介するサーバーを用意すること。連携させるノードをサーバーが決定し,両者のやり取りに介在する。もう一つは,各ノードが直接通信し合う方法。直に情報をやり取りしながら自分自身の状態を変えていく。ここでは前者をサーバー方式,後者を直接方式と呼ぶ。

 サーバー方式は現実的な解だ。すべての情報をサーバーが把握するので,ネットワーク全体の状況を管理しやすい。また各ノードはサーバーとの通信機能だけ持てばよい。実装をシンプルにできる。

 一方で,すべての通信にサーバーが介在することによるデメリットもある。まず,悪意ある攻撃者の標的になりやすい。そのサーバーを乗っ取れば,ネットワーク全体を支配できてしまう。ノードの数が増えると,サーバーにトラフィックが集中しすぎる懸念もある。

 直接方式の特性はサーバー方式の正反対である。通信の負荷はネットワーク全体に分散するし,明らかな攻撃対象もない(別掲記事「データを集約して通信負荷を減らす」参照)。半面,ネットワークの状況を把握しにくい。管理者にとっては扱いにくいシステムだ。またサーバーが持っていた役割を各ノードが分担するので,ノードの実装が複雑になる。

サーバーが通信を仲介する

 まず,サーバー方式について見てみよう。この方式なら,既存の標準的な技術であるSNMP(Simple Network Management Protocol)を使える。センサーやアクチュエータをTCP/IPネットワークに接続しておき,SNMPを使って監視/制御する。

 SNMPは,TCP/IPネットワークに接続されたネットワーク機器を管理するために作られた。マネージャと呼ばれるサーバーが管理者となって,ルーターやパソコンなどの機器(エージェント)を管理する。マネージャはエージェントの動作が正常かどうかをチェックしたり,設定を変更したりできる。逆にエージェントは,障害の発生時やあるイベントが発生したときなどに,自分の状況をマネージャにレポートする機能を持っている。

 したがって,各センサーやアクチュエータをエージェントにすれば,パソコンなどでそれらを一元管理できる。例えば,温度が一定以上になった場合にレポートするように温度センサーを設定する。そのレポートを受け取ったらファンに対して回転するよう命令を出す,といったプログラムをマネージャで動かしておく。こうして,複数のセンサーやアクチュエータの連携を実現する。

 この方法を採用した製品に,アイピースクエアの「Agent Processor」がある(図2[拡大表示])。TCP/IPのプロトコル・スタックや,SNMPのエージェント機能をワンチップ化したものだ。これを家庭内の機器やセンサーに取り付ければ「インターネット経由で,遠隔地から家の状態を把握し,機器を制御するといったことが可能になる」(アイピースクエアの小川哲男代表取締役)。


図●TinyDB
TinyDBは,同じくカリフォルニア大学バークレイ校が開発する「Mote」チップ向けの問い合わせの仕組み。Moteは,木構造のネットワークをアドホックに形成する仕組みを備える。TinyDBは,木構造のネットワークの特性を生かしてデータを集める。例えば図は,温度(Temp)を10で割った値でグループ分けをし,それぞれについて照度(Light)の値の平均(AVG)を取るというクエリーを発行している。クエリーは,親から子へ,さらにその子へとすべてのノードに送られる。クエリーに合わせて,末端の子ノードは親ノードに自分の情報を報告する。親ノードはそれを集約し,さらに自分の親ノードへと報告する。

データを集約して通信負荷を減らす

 大量のセンサーからデータを集約するとき,個々のセンサーが集約ノードにデータを送ってしまうと通信の負荷が1カ所に集中してしまう。この問題を避けるには,データの送信方法を工夫して通信負荷を減らす必要がある。米カリフォルニア大学バークレイ校が開発するデータベース・システム「TinyDB」は,データを中継するノードがデータを集約することで通信量を減らしている。

 TinyDBは,同大学が開発したセンサーノード「Mote」と,センサーノード用OS「TinyOS」のうえで動作する。Moteは,農場など屋外の広い範囲にばらまいて,監視や管理に使う。

 TinyDBは,Moteが構築するネットワークの構造に基づいて効率的にデータを集約する。Moteは,木構造のマルチホップ無線ネットワークをアドホックに構築する仕組みを備えている。ルートとなる一つのノードがメッセージを発信し,それを受け取ったノードがそのノードの子となる。そのノードもさらに別のノードにメッセージを発信し,それらの親となる。

 ユーザーからTinyDBに対してクエリーが発行されると,まず親から子へ,さらにその子へとすべてのノードにクエリーを伝達する。クエリーが末端の子ノードまで行きわたると,末端の子ノードは自分が持っている情報の中からクエリーが求めているものを親ノードに報告する([拡大表示])。親ノードが単純にこれらをすべて自分の親に転送してしまっては,通信量が増えるし負荷も集中しやすい。そこで各親ノードは,子ノードからの報告がすべて集まるのを待つ。報告を集約し,クエリーに合わせて加工してから,自分の親ノードへと伝える。その結果はさらに上位の親ノードへと報告され,そこでもまた集約と加工が働く。最終的に,最上位にあるノードでクエリーに対する回答を生成する。