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