メディア

ZigBeeネットワークでワイヤレスセンサーを実現（2/3 ページ）

» 2006年07月01日 00時00分公開

[Dan Strassberg，EDN]

メッセージの到達

　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プラットフォームモジュールの開発が進められている。これらのモジュールには、最終デバイスのアプリケーション固有の部分を試作できる機能を持つものもあれば、試作できない量産向けのものもある。

ワイヤレスセンサーネットワークでのソフトウエアのダウンロード

　ワイヤレスセンサーネットワークの特徴は、センサー/アクチュエータとネットワークとの間に物理的接続（配線）が存在しないことだ。配線しにくい場所にもハードウエアを設置できるという利点はあるが、ソフトウエアをアップグレードしなければならなくなったときに新しいコードをダウンロードしようと思っても配線を利用することはできない。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社のやり方は管理されたクライアント-サーバー手法を利用する。管理ツールが各プラットフォーム上のコードバージョンを判断し、クライアントとサーバーに役割を割り当てる。この際、プラットフォームの場所とコードを使えるかどうかが決め手となる。コードを受信するターゲットプラットフォームが増えるほど新しいコードの浸透率が上がる。アップグレードされた各クライアントが別のクライアントのサーバーとなるからだ。管理ツールがこれらの役割を瞬時に割り当てる。この手法がうまくいく理由は、こうしたネットワークは大規模であることが多いものの十分に定義されていて安定しているからだ。このような環境では管理ツールを使うのが合理的といえる。