2006.7

ZigBeeネットワークでワイヤレスセンサーを実現 ZigBeeのような適切なプロトコルを使えば、情報のやりとりが少ないセンサーの消費電力を節約できる。アルカリ電池1個で10年間の電力を賄える場合もある。 Dan Strassberg

Advertisement 　ZigBee WPAN（wireless personal area network）技術を推進する業界団体「ZigBeeアライアンス」のメンバーは、似たような技術のBluetoothの支持者が犯した過ちから貴重な教訓を得たという。Bluetoothは今や確立された技術として、少なくとも携帯電話機や携帯機器などの無線ヘッドセット市場では広く採用されるようになった。しかし、初期のころに支持者たちが犯した失敗によってこの規格は危うく消え去るところだった。しばらくフォーマット策定の段階にあり、普及するまでに時間がかかった。ここでの教訓は、このワイヤレス時代に、すべての人々のニーズに応えようとすればほぼ間違いなく失敗の道をたどるということだ。 　ZigBeeの発案者たちはこの技術にIEEE 802.15.4ワイヤレス通信規格を利用した。ZigBeeという名前は、ミツバチが蜜のある場所とそこまでの距離を仲間に伝えるためにジグザグに飛行することから付けられた。蜜のある場所を知る技術である。しかもすべてのセンサーを対象としているわけではない。せいぜい1秒当たり1回しかデータを送信する必要がない低速デバイスでよい。このようにセンサーを限定している理由はいくつかある。センサーがワイヤレスなら、電源配線も信号配線もワイヤレスにしなければ意味がない。そのため少なくとも最初は、ZigBee対応センサーのほとんどはバッテリ駆動式となるだろう。大半のセンサーは小さいため、バッテリ駆動式センサーもあまり大きくできない。このためバッテリも小さくしなければならないが、小さいバッテリではわずかなエネルギーしか蓄えられない。 　バッテリ寿命をできるだけ長くもたせるためには、センサーと通信回路で消費される電力を節約する必要がある。最も簡単な方法はデューティ比――この場合はデバイスが送信している時間の割合――を最小限に抑えることである。通信していないときはデバイスは低電力スリープモードに入る。2.4GHz〜2.48GHzで、ほとんどのセンサーは802.15.4のデータレート250kビット/秒で数msだけメッセージを発信する。902MHz〜928MHz、868MHz〜870MHzでのデータレートはそれぞれ40kビット/秒と20kビット/秒である。スリープモードからデータ伝送モードへの遷移には約15msかかるため、平均して1秒当たり1メッセージを送信するセンサーの2.4GHz帯域におけるデューティ比は2％未満であり、868〜915MHz帯域ではそれを少し上回る程度だ。一般にメッセージを送る頻度はそれほど多くない。このようなセンサーのデューティ比は非常に低いため、バッテリ寿命は事実上バッテリの品質保持期間と考えられる。アルカリ電池では最長10年間だ。 ワイヤレスが不可欠な理由 図1　規格そのものにふさわしく、すぐ目に付くZigBeeロゴはシンプルで分かりやすいメッセージをユーザーに伝えている。このバージョンは、2.4GHz帯で動作するデジタル家電製品のパッケージに貼付される。1GHz未満で動作する製品向けのバージョンもある（ZigBeeアライアンス提供）。 　ワイヤレスセンサーネットワークの規格策定の根拠となっているものは、「最近は何でもワイヤレスになっているのだからセンサーも」というようなたぐいではない。もっと現実的な理由による。いろいろな応用システムに無数のセンサーが使われているからだ。センサーの取り付けと配線にかかるコストはセンサーそのもののコストをはるかに上回る。もちろん、センサーを設置したい場所にセンサーを飛ばして設置するいう冗談ともつかない問題をZigBeeで解決できるわけではない。センサーの取り付けにかかるコストの一部はワイヤレスセンサーの場合と同じである。 　ZigBeeは、ビルオートメーション、産業、医療、住宅向けの幅広い管理・監視などの応用を狙っている。IEEE 802.15.4で規定されている相互運用性やRF特性を要件とする応用ではZigBeeを採用することで得られる利点は多い。用途の例としては、照明制御、電気・ガス・水道メーターの遠隔測定、ワイヤレス煙・一酸化炭素検知器、HVAC（暖房、換気、空調）・環境管理、ホームセキュリティ、侵入検知器、ブラインド・カーテンのシェード制御、医療用センシング・モニタリング、ホームコントロール機能内蔵セットトップボックスのリモート制御、産業・ビルオートメーションなどがある。ZigBeeに対応した世界初のホームコントロール、ホームセキュリティ製品は2006年中ごろに発売される。これらの製品のパッケージにはZigBeeロゴが貼付される（図1）。 図2　ZigBeeはレイヤー構造のプロトコルである。IEEE 802.15.4では一番下（緑）の層が規定されている。ZigBeeの仕様では中間（オレンジ）層が規定されている。ユーザーは一番上のアプリケーション層（黄色）をコントロールする。オレンジ色は、ZigBeeプラットフォームICに組み込まれるスタックを形成する層を表している（ZigBeeアライアンス提供）。 　ZigBeeの仕様では、ネットワーク、セキュリティ、アプリケーションフレームワーク、アプリケーションプロファイルの層を802.15.4のPHY（物理）層とMAC（メディアアクセス制御）層の上に位置づけている（図2）。802.15.4規格の2.4GHz帯は免許の要らない世界中で使える。802.15.4規格は、ハーフサインパルス整形を用いたO-QPSK（offset quadrature phase shift keying）変調方式を規定しており、1シンボルが2ビットを伝送する。実質的にはMSK（minimum shift keying）方式に近い。チャンネル間隔が5MHzであり、最大16本のチャンネルを使用できる。デバイスによってチャンネル間の周波数ホッピングが行われなくても、通常はチャンネルを選択することで受信状態が最適化される。ネットワーク接続されたデバイス間の干渉を最小限に抑え、かつデータセキュリティを強化するため他の手法を組み合わせる。例えば2.4GHz帯には2Mチップ/秒のDSSS（direct sequence spread spectrum：スペクトラム拡散方式の一つ）を使い、1GHz未満の帯域ではルートコサインパルス波形整形を使用するBPSK（binary phase-shift keying）を使う。915MHz帯では2MHzのチャンネル間隔を使う（868MHz帯域には1チャンネル分の空きしかない）。BPSKでは1シンボルにつき1ビットしか伝送されない。868MHz帯（主にヨーロッパ）と915MHz帯（南北アメリカ大陸とオーストラリア）のデータレートはそれぞれ20kビット/秒と40kビット/秒で、DSSSのチップレートは300kチップ/秒と600kチップ/秒である。 　3つの帯域すべてにおいて、802.15.4準拠のMAC層にはCSMA/CA（carrier sense multiple access with collision avoidance）方式が採用されている。メカニズムは基本的にイーサーネットで使用されている方式と同じである。データを伝送しようとするデバイスはスリープモードから起動し、まずチャンネル上で通信が行われていないかどうかを確認する。通信を検出すると再びスリープモードに入り、ランダムな長さの待ち時間が経過した後にもう一度起動して通信の有無を確認する。そしてチャンネルが空いていればメッセージを送信する。もちろん、データを送信しようと複数のデバイスが同時に問い合わせすることもある。いくつかのデバイスが誤ってチャンネルが空いていると判断し、同時に送信を開始する可能性もある。 メッセージの到達 　ZigBeeアライアンスのメンバーによると、DSSSコーディングにより、干渉があってもメッセージが到達する可能性は高いという。しかし送信側は通信許可を受信できなければスリープモードに入り、ランダムな時間が経過した後に再びメッセージの送信を試みようとする。CSMA/CAの明らかな問題点は、遅延時間が決まっていないことだ。つまりシステム設計者は、メッセージが受信側に届くまでにどれくらいの時間がかかるのかを規定できない。しかし、イーサーネットが今日よりもずっと遅かった数10年前の段階で証明していたように、大抵の場合はこの方式でうまくいく。また、システムの応答待ち時間が長いほど、要件を満たせる可能性が高まる。 　しかし、遅延時間を決めておきたいというユーザーに対して、802.15.4規格では上記の方式のほかに、厳密な許容誤差範囲内で遅延時間を保証するための2つの方式を規定している。ビーコンはある特定のZigBeeネットワーク構成で許可されている特殊なメッセージである。ビーコンがデバイスを起動するとデバイスは自らのアドレスを問い合わせ、アドレスを受信できなければ再びスリープモードに入る。デバイスがビーコンに問い合わせしなくてはならない場合には、15.38msの倍数の時間（最長252秒）を指定できる。ビーコンはスーパーフレームを通知できる。これはもう1つ別の特殊なメッセージで、ビーコン間に16個のタイムスロットを挿入する。このスロット間で、指定されたデバイスは競合することなくネットワークにアクセスできる。 　ZigBeeアライアンスのスローガンは「本当に使えるワイヤレスコントロールを提供すること」である。今の段階でもZigBeeがこのスローガンに賭けていることがうかがい知れるが、ワイヤレスコントロールを「本当に使える」ものにするには多くの労力と技術を必要とした。アライアンスのWebサイトから無料でダウンロードできるZigBee仕様書1.0＊1）は426ページに及び、そのPDFファイルのサイズは8Mバイトもある。ちなみにこの仕様書には、5Mバイトある679ページのIEEE 802.15.4-2003規格で触れられているPHYとMACについての項目がない＊2）。言い換えれば、たとえZigBeeが範囲を限定した低電力・低速プロトコルであったとしても、その開発者たちはユーザーがすんなりとこの規格を受け入れられるようにかなりの労力を費やしたことがわかる。 　ワイヤレス通信プロトコルに関してユーザーが懸念することの1つにデータセキュリティがある。例えば、侵入者が家の中のサーモスタットを見つけてその設定を変更できたとしても、どれほどの被害があるだろうかと思うかもしれないが、それが産業用あるいは商用のアプリケーションであれば深刻な問題となる。そして、仮に家庭用サーモスタットの場合であっても、水道管が凍結するなどの大きな被害がでないとも限らない。 　ZigBeeのDSSSコーディングによって基本的なセキュリティは守られているが、ZigBeeではさらにセキュリティツールボックス手法を用いて信頼性の高いセキュアネットワークを実現している。アクセス制御リスト、パケット有効タイマー、そしてNIST（米国標準技術局）が認定するAES（Advanced Encryption Standard）に基づいた128ビット暗号化方式によりデータ伝送とZigBeeネットワーク自体が保護されている。 ZigBeeのプロファイル 　ZigBeeの特徴はそのプロファイルにある。照明のホームコントロールがその一例だ。このプロファイルの初期バージョンでは、コントロールメッセージを交換してワイヤレスホームオートメーションを実現する6つのデバイスタイプが規定されている。これらのデバイスは既知のメッセージを交換することで、効率よく制御する。例えば、照明のオン/オフを切り替えたり、光センサーの測定値を照明コントローラに送信したり、監視センサーが何らかの動きを検出すると警告メッセージを送信したりする。もう1つの例としては、ZigBee対応デバイスに共通の動作を定義するデバイスプロファイルがある。例えば、ワイヤレスネットワークでは、デバイスが自律的にネットワークに参加して、ネットワークに接続されている他のデバイスを検出し、それぞれのデバイスが持つ機能を認識する。つまりデバイスプロファイルはデバイスとその機能を素早く検出するためのものである。 　ZigBeeの仕様では、デバイスメーカーは他社の製品にはない機能を定義した独自のプロファイルを作成できる。しかしアライアンスは、そうした独自機能によってメーカーの異なるデバイスをネットワーク内で相互運用できないということがあってはならないと考えている。従って、独自プロファイルに基づくデバイスは、その固有の機能を実現するために必要な性能を他のデバイスが備えていない場合でも、基本的な機能は実行できるようにしておかなくてはならない。 図3 1GHz未満で動作するデバイスに使用されているこのプラットフォームは典型的なシングルチップZigBeeプラットフォームである。ZigBeeプラットフォームは左側にある。右側のブロックにはアプリケーション固有の機能が含まれている（ZMD提供）。 　ZigBee対応デバイスのZigBeeプラットフォーム部分にはRF/ベースバンド通信機能が実装されている。現在はマルチチップのZigBeeプラットフォームが一般的だが、しばらくすれば1チップのプラットフォームが普及するようになるだろう。すべてのプラットフォームの設計が同じというわけではないが、すでにいくつかのサプライヤから1チップのものが提供されている（図 3）。プラットフォームチップの単価は量産時で1個5米ドルほどになるだろう。メーカーによって仕様は異なり、対応帯域も2.4GHzのものと868/915MHzのものがある。ただ、いくつかの違いはあっても、これらのICチップはZigBeeに関連するすべての機能を備えており、用途に制限はない。RF機能のほか、これらのチップにはプロセッサとZigBeeソフトウエアスタックを記憶できる十分な容量の不揮発性書き換え型フラッシュメモリーが組み込まれている。 　言うまでもなくソフトウエアはZigBeeの中心的役割を担っており、ソフトウエアアップグレードを行わずしてソフトウエアに依存するプロトコルを実装することはできない。しかしワイヤレス環境では、ソフトウエアアップグレードは別の問題も出てくる（別掲記事「ワイヤレスセンサーネットワークでのソフトウエアのダウンロード」を参照）。 　アプリケーション固有の機能をZigBeeプラットフォーム機能に統合するほうが都合の良い汎用アプリケーションを除けば、アプリケーション固有の機能は別のチップに搭載すべきである。プラットフォームチップのほかに、チップをサポートするためのクロック用水晶発振器をはじめとする別の回路を搭載したZigBeeプラットフォームモジュールの開発が進められている。これらのモジュールには、最終デバイスのアプリケーション固有の部分を試作できる機能を持つものもあれば、試作できない量産向けのものもある。 難題 　ZigBeeについてよく聞かれるのは、「通信距離はどれくらいか」という質問である。端的に言えば10m〜100mだが、この質問に答えるのはそう簡単ではない。なぜなら、ネットワークの動作周波数が2.4GHzか1GHz未満かということだけでなく、ネットワークに接続されたデバイスが屋内にあるか屋外にあるかでも答えが違うからだ。出力がZigBeeチップでサポートされている0dBmかそれ以上かということも影響する。最大出力は20dBmだが、それにはZigBeeチップ外部の増幅器が必要となる。最も重要な要因は、データがその目的地に到着するまでに何回のホップが行われるかということである。 　2.4GHz帯のデータレートは868MHz帯や915MHz帯よりも高いが、独ZMD社（www.zmd.biz）など1GHz未満の周波数を支持する企業は、低い周波数を使った伝送の方が信頼性は高いと主張する。1GHz未満で干渉波を発生させるユーザーは少なく、信号の吸収と反射の問題も低い周波数ではさほど深刻ではないというのがその理由だ。従って、より低い周波数で動作するデバイスは低電力で動作できることが多い。 図4　ZigBeeにはメッシュ構成が関係していることが多いが、ZigBee仕様にはほかに2つのトポロジがあり、それぞれのトポロジで使用できるZigBee機能が規定されている。ZigBeeでは、メッセージが目的地に到着するまでに複数回ホッピングし得ることに注意する必要がある（ZigBeeアライアンス提供）。 　ZigBee NWK（ネットワーク層）では、「スター」、「ツリー」、「メッシュ」の3つのネットワーク構成がサポートされている（図4）。ネットワークデバイスは他のネットワークデバイスからのメッセージを中継できる。スター構成では、ZigBeeコーディネータがネットワークを制御する。このコーディネータがネットワークデバイスを始動させ、他のすべてのデバイスはコーディネータと直接通信するエンドデバイスとなる。メッシュ構成とツリー構成では、コーディネータがネットワークを始動させて特定の主要ネットワークパラメータを選択する。ネットワークはZigBeeルーターによって拡張できる。ツリーネットワークでは、ルーターが階層ルーティング方式によってネットワークを介してデータを移動し、メッセージを制御する。ツリーネットワークではビーコン方式の通信を利用できる。メッシュネットワークでは完全なピアツーピア方式の通信が可能となる。 　棚卸しの時に資産を追跡するという用途では、よく言われるRFID（無線ICタグ）技術よりもZigBeeの方が有用かもしれない。RFIDタグは受動的で、RF信号からの問い合わせ信号に応答するためにエネルギーを消費する。問題は、問い合わせ信号を送信するデバイスが、それに応答するRFIDタグから約3m以内に存在しなくてはならないということだ。例えば、大きな研究開発施設や製造工場などで試験装置の場所を決めようとしても、探そうとするものの場所が分かっていなくてはならないようでは意味がない。しかしZigBeeネットワークならば、広大なキャンパスの中でも装置の場所を追跡できる。各装置にはRFIDタグよりも高価なZigBeeプラットフォームが必要になるが、棚卸しや装置を探し回るのにかかる人件費を考えれば、1年以内にZigBeeプラットフォームにかかるコストを回収できる。 ウサギとカメ 　産業分野へのZigBeeの導入は遅れているものの、ウサギとカメの話のように、この技術は競合技術に勝てそうだ。ただし、ゆっくりと着実に。例えば、多くの産業用途に求められる「ファイブ・ナイン（99.999％）」の稼働率を実証できるまでにはまだ時間がかかると思われる。その主な理由は、開発者の意図どおりにユーザーが適用した場合のプロトコルのスピードが遅いからだ。トランザクションベースの用途では、ZigBeeの速度は1秒当たり、1分当たり、1時間当たり、あるいは1カ月当たりのトランザクション数では測定されない。さらに、実際の用途の信頼性を予測するには、統計と確率に頼らなくてはならない。そのため、1カ月に1回のエラーも発生しないという高い信頼性を実証するには数カ月かかる可能性がある。テスト関係者の中には、ビットエラー率やフレームエラー率に基づく検証方法はZigBeeには不適切で、EVM（エラーベクトルの大きさ）に基づく試験の方がより早く正確な結果を出せるという考えも出ている。 　ただし、ZigBee技術が最初から暖かく業界に迎え入れられたことがアライアンスのメンバーを今も勇気付けている。ZigBeeの仕様書が公開された最初の1年でダウンロードされた件数は1万8000件を超えた。 　ZigBeeの潜在ユーザーは、ZigBeeデバイスがバッテリで動くということを懸念する。開発ツールのサプライヤがZigBeeスタックに組み込むために提供しているものの一つにZigBeeチップがある。このチップは、バッテリの充電状態を測定して、バッテリ交換が必要になる直前に警告メッセージを伝える。しかし、たとえZigBeeセンサーが適切な場所に置かれていてもそれを探すのにかなりの労力を必要とするなら、ユーザーはバッテリが壊れて高価な修理費用のかかるようになるまでバッテリの交換を先延ばしにするだろう。 　バッテリ寿命を延ばしたり、バッテリを使わずに済む方法もある。センサーをもっと賢くするなら、つまり電力をそれほど消費することなく、リモートシステムを使わなくてもデータに関係する決定を独自に行えるようにできるのなら、センサーはあまり通信する必要がなく、通信にかかる消費電力を節約できる。しかし、そのようなスマートセンサーは回路設計が難しいだけでなく、ソフトウエア設計もかなり難しい＊3）。 　もう一つの手として、さまざまな手法を使って環境から少量のエネルギーを集める「エネルギーの寄せ集め」というアプローチがある＊4）。例えば、常に照明がついている工場やオフィスでは、太陽電池でZigBeeデバイスを駆動できる。ZigBee対応の照明スイッチは、トグル動作から電力を集め、それを大容量キャパシタに蓄積できるかもしれない（交流電源を必要としない照明スイッチならば可能である。配線にかかるコストを節約できるだけでなく、オフィスレイアウトの変更も簡単になる）。メーカーは、モーターやオフィス機器に電力を供給する配線周りの寄生交流磁場から電力を集めることがおそらくできる。また生産機械の振動から電力を集めることもできるだろう。

ワイヤレスセンサーネットワークでの ソフトウエアのダウンロード 　ワイヤレスセンサーネットワークの特徴は、センサー/アクチュエータとネットワークとの間に物理的接続（配線）が存在しないことだ。配線しにくい場所にもハードウエアを設置できるという利点はあるが、ソフトウエアをアップグレードしなければならなくなったときに新しいコードをダウンロードしようと思っても配線を利用することはできない。OAD（over-air downloading）ならこの問題を解決できるが、OADを実現するにもいくつかの課題がある。米Texas Instruments社はOADをサポートする製品Chipcon Wireless OADを持っている。 　ZigBee/802.15.4など階層構造の伝送アーキテクチャでは、OADなどの方式をサポートすることにはアプリケーションを書かなければならないという問題がある。このアプリケーションをどの層に位置付けるかは設計時の選択によるが、その選択にはさまざまな意味合いがある。例えば、OADサポートをZigBeeアプリケーションとして記述すれば、マルチホップルーティングをサポートするインフラとしてスタック全体を使用できるため、ソースとターゲットを近接させる必要はない。MAC（media-access control）層をアプリケーションとして使えば、このネットワークルーティングがサポートされない代わりに、ファイル転送サポートコードのサイズを縮小できる。どの方法でも、ダウンロードコードを格納しておけるサイズのリポジトリが必要となる。 　OADサポートはフェイルセーフでなくてはならない。伝送エラー、ファイル転送障害、コード更新の中断にも耐えうる頑強さが必要である。どの段階で失敗しても、デバイスに残っているソフトウエアを復元できなくてはならない。ファイル転送そのもののセキュリティも確保する必要がある。 　割り込み転送に対処するためには、2つの要件を満たす必要がある。1つは、ターゲット上の転送をサポートするソフトウエアそのものが、転送が成功するまでそのまま保持される必要があること。もう1つは、転送された部分を転送完了まで動作させてはならないこと。この2つの要件が持つ意味はこういうことだ。つまり、ダウンロードコードのメモリーが新しいコードの転送部分も記憶している必要があり、この転送部分が転送実行コードを妨害してはならない。これらの要件が満たされていれば、転送障害をサポートするコードによって転送を再試行できる。 エラーの軽減 　伝送エラーはZigBeeスタックのフレームチェックシーケンスによって緩和できる。各層はこのシーケンスを使い、それ自身のレベルで保証した配信レポートを提供する。さらに、転送ファイルの最終チェックとしてCRC（巡回冗長検査）のようなメカニズムを利用すれば、不完全なダウンロードを直ちに検出できる。ファイル転送のセキュリティはZigBeeと802.15.4準拠のMAC層、PHY（物理）層両方ともサポートされている。 　ファイルアップグレード配信アーキテクチャは、アップグレードが必要なことをターゲットプラットフォームがどのように「知る」のかを定義したものだ。TI社のやり方は管理されたクライアント-サーバー手法を利用する。管理ツールが各プラットフォーム上のコードバージョンを判断し、クライアントとサーバーに役割を割り当てる。この際、プラットフォームの場所とコードを使えるかどうかが決め手となる。コードを受信するターゲットプラットフォームが増えるほど新しいコードの浸透率が上がる。アップグレードされた各クライアントが別のクライアントのサーバーとなるからだ。管理ツールがこれらの役割を瞬時に割り当てる。この手法がうまくいく理由は、こうしたネットワークは大規模であることが多いものの十分に定義されていて安定しているからだ。このような環境では管理ツールを使うのが合理的といえる。 ▲本文へ戻る 用語解説 / 会社情報 ＊1） ZigBee 1.0 specification-download request: www.zigbee.org/en/spec_ download/download_request.asp. ▲本文へ戻る ＊2） IEEE 802.15.4-2003 standard: http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf. ▲本文へ戻る ＊3） National Instruments, white paper, The real issue limiting wireless-sensor networks, 2006, http://digital.ni.com/express.nsf/bycode/sensors. ▲本文へ戻る ＊4） Conner, Margery, ﾒEnergy harvesters extract power from light, vibrations,ﾓ EDN, Oct 27, 2005, pg 45, www.edn.com/article/CA6275407. ▲本文へ戻る