スマートメーターとIPにまつわる不都合な真実

© Copyright Peter Trimming and licensed for reuse under this Creative Commons Licence.

前回は、「なぜデマンドレスポンスは誤った考えなのか？」というシニカルなタイトルのSmartgridNews.comの記事をご紹介しましたがいかがだったでしょうか？

自分としては、逆に、「デマンドレスポンスというのは今が旬だ」ということを再認識させられました。
逆説的なテーマを掘り下げることで、対象の真の姿が見えてくるということがあるのではないかと思います。

これに関連して、という訳でもないのですが、偶然、『Smart Meters and IP － an Inconvenient Truth』というタイトルの記事をインターネット上で見つけました。ZigBee SEP2.0の開発が遅れているのは以前から不可解に思っていたのですが、それに対する1つの回答？というか、「足を引っ張っていたのは、実は、Wi-FiアライアンスやPLCのアライアンスが絡んできたからではなくIPv6だった」というストーリーが意外で、一気に読んでしまいました。

自分の専門分野ではないので、事の真偽はこれをお読みいただいている読者諸兄の専門家のご意見を是非伺いたいのですが、それとは別に、今回考えさせられたのは、「トップダウン・アプローチが、末端の思わぬところでボトムアップ・アプローチ製品開発の阻害要因になるケースが存在するのだ－という不都合な真実」です。

どこがどう不都合なのか、少し古い記事ですが、早速ご紹介したいと思います。 例によって、全訳ではないことと、独自の解釈および補足／蛇足が混じっていることをご承知おきください。では、はじめます。

スマートメーターとＩＰにまつわる不都合な真実

CREATIVE CONNECTIVITY　2011年4月14日 Nick Hunn

100年ほど前のジョージ・バーナード・ショーの語録に「米英は共通の言語で隔てられている」というのがあるが、米英でスマートメータリングに採用されている標準を考えると、同様の隔たりが感じられる。
米英は、ZigBeeアライアンスがスマートメーターによる計測と負荷制御およびデマンドレスポンスのためのアプリケーションプロファイルとして策定したZigBee Smart Energy Profileの初版1.0（以降SEP1.0）をスマートメータリング用標準として受け入れた。しかし、下位の通信プロトコルとしてインターネットプロトコルを使うかどうかに関して、隔たりが生まれ、今、その隔たりが広がりつつある。本来、単に意見の違いで、メータリングやスマートグリッドそのものには無関係に見えるが、将来に関するビジョンや、そのビジョンをどのような技術で実現すべきかの考え方の違いが出てきているのだ。

モノのインターネットという新しい世界を標榜する一派は、スマートメータリングに限らず、バッテリー駆動の装置に至るまで、世の中のものすべてがIPでつながるべきだと考えている。そのためにはインターネットに接続される膨大な数の装置を区別するグローバルIPアドレス空間が必要で、現在のIPv4では足りず、IPv6が必要ということになっている。

小電力無線プロトコルを利用したスマートメータリングの実展開を考えた場合、IPv6を使用するのは無理があるように思うのだが、米国では、IPv6ベースのZigBee Smart Energy Profile 2.0（以降SEP2.0）の開発に余念がない。スマートメーターにまつわる全体像を考え、実用的な決定を下すべきだと彼らは主張しているが、自分には、その主張は論理的に破たんを来しているように思えてならない。時間が進むにつれ、巧妙なトリックのベールの裏で、さらなる不都合な真実を秘密にしなければならなくなっているように見える。

問題は、ホーム・エリア・ネットワーク越しに接続されるスマートメーターと個々の家電機器をどのようにアドレス付けするかである。

それには、2つの流派がある：

英国をはじめ、SEP1.0を使用する流派では、家電機器はインターネット上のゲートウェイ装置（HGW）を介して接続されている。これは、HGWにIPアドレスが割り振られていることを意味する。その結果、HGWは他のインターネット装置から見えるが、スマートメーターや、宅内の家電機器には個々のIPアドレスが割り振られていないので、インターネットからは見えない。代わりに、自分に接続されたスマートメーターや家電機器を認識しているHGWが、インターネット側から送られたメッセージやコマンド等をしかるべき装置に送ることになる。

これは、我々の日常と同じ方法である。すなわち、HGWが、我々の家やオフィスに相当し、ユニークなアドレスを持っているので、そのアドレスと、その住所に住む個々人の名前が分かれば、その個人名宛ての手紙が届く。ここで重要なポイントは、人の名前には同姓同名がありうることである。

これに対して、もう1つの流派である米国のIP信奉者は、「それは良くない。すべての装置は、それ自身を識別できるユニークなIPv6アドレスを持つべきである」と主張している。
とりあえず、言いたいことは分かる。しかし、小電力無線装置を動かすために何が必要か考え始めると、その論理の矛盾が見え始める。

バッテリー内蔵無線製品を設計するに当たって大切なことの1つは、バッテリーを長持ちさせることである。そのためには、いろいろな方法が考えられるが、その1つとして、装置をできるだけ消費電力の少ないスリープモードにしておき、何かデータを送りたい時、必要最低限の時間だけ無線でデータを送信し、送り終わったら速やかにスリープモードに戻るという実装が考えられる。また、小電力無線では、データが早く送れるよう、非常に短いパケット長が採用されている。例えば、ZigBeeは、最大127バイト、Bluetoothの低電力版では、47バイト。

このパケットには、送信元と送信先アドレスを含める必要があるが、なるべく送信時間を短く、使用電力量を小さくしたい無線プロトコルにとって、アドレス部分は“必要悪”のようなものである。
ところが、IP信奉者がすべてのモノに対して利用を促進しようとしているIPv6では、アドレス情報として少なくとも、32バイト、多くの場合、その2倍の64バイトを要する。それに引き替え、本当に送付したいデータは数バイトしかない。
したがって、小電力無線装置の通信プロトコルとしてIPv6を使うと、パケット長が一桁大きくなってしまうのである。

例えて言うならば、IPv4が、ラップしたバナナの房そのものだとすると、IPv6は、それを化粧箱に入れ、リボンをかけて、持ち帰り用のキャリーバッグに入れたようなものだ。
有線で常時電力供給される製品にとっては全く問題ないが、小電力無線装置にとっては、厄介者以外の何物でもない。ヘッダ圧縮により通信データ量を減らす6LoWPANは、“超肥満体”を、“小太り”くらいに抑える効果を持っているが、それでもまだ小電力無線通信としては大きすぎる。

それだけではない。

通信上、IPの上位層であるTCPやUDPのプロトコルは、リンク層での送達確認を行わない。小電力無線装置としては、上記の通り、必要最低限のデータを送信して、すぐスリープモードに戻りたいが、多くの場合アプリケーション的には、送信したデータが相手に受け取られたかどうか確認したい。

そこで、TCPまたはUDPの上位のプロトコルスタックで送達確認を行うとすると、リンク層では、送達確認のACKが戻るまで無線の電源を切れないことになる。

これが、無線プロトコル設計者とIP信奉者の決定的な違いである。
効率的な無線プロトコルは、ボトムアップ設計であるのに対して、IP信奉者は“上から目線”でトップダウン的に物事を考える。それが、効率的な無線設計を阻害しているかもしれない等とは考えもせずに。。。

そして、これが冒頭に述べた米英の隔たりをもたらしている。

両国は、ともにZigBee SEP1.0を使い始めたが、米国では、国立標準研究所（NIST）がスマートグリッドに関連するすべての装置でIPv6が使えるようにすることを必須条件と定めたので、産業界は困惑しながらも6LoWPANを使うSEP2.0の開発を開始したのに対して、英国では、SEP 1.1での機能拡充に関わってきた。現在は、SEP1.1の完成を受けて、SEP1.2への機能拡張を行っており、既に、SEP1.3はどうするかという話も始まっている。
英国ばかりでなく、欧州の産業界も、ほとんどすべて英国と歩調を合わせ、二律背反的な技術上の“チャレンジ”騒ぎに加担することなく、スマートメータリングの発展に何が必要かを考えてSEP1.xの開発に従事している。

かように、SEP1.xの開発が順調に進んでいるのに対して、SEP2.0の開発スケジュールはどんどん遅れており、NISTは、最近になって、NISTの要請に従いIPv6ベースのSEP2.0開発に携わっている忠実なメンバーに対して、彼らの偉大なタスクを完成させるため「更に刻苦勉励せよ」との“勅令”を出した。最後の追い込みよろしく、鞭を打ち、拍車を掛けたのである。

ところが、NISTのビジョンを押し進めるに当たって、別のやや不都合な真実が明らかになった。これまで明らかにされていなかったが、SEP1.xの装置はSEP2.0の装置と会話ができないのだ。理由は単純で、それらが異なるネットワーク層を使用するからである。SEP2.0はIPを使用するのに対し、SEP1.xは使用しない（ZigBeeを使う）。

SEP2.0の完成が遅れているので、SEP1.xのスマートメーターを使い始めようか検討していた多くの電力会社にとって、これは非常に大きな問題である。後日SEP2.0完成時に使えなくなるようなスマートメーターを一般家庭に設置したくはない。
ZigBeeアライアンスは、この問題を解決するため、“Over The Air” Upgrade clusterをSEP1.1の定義に追加した。これは、SEP 1.1以上の装置の無線ネットワーク自体を用いて、SEPプロトコルのプログラム（ファームウェア）をセンターから送信し、アップグレードするための仕組みである。これによって、以前インストールされたSEP1.1以上のスマートメーターのファームウェアを、SEP2.0にアップグレードすることができる。

心配なのは、SEP2.0のファームウェアが“成長”していることだ。

“Over The Air”でSEP2.0のファームウェアに入れ替えようとしたSEP1.xの装置に、SEP2.0のファームウェアをすべて格納する余裕がない場合、どうするのか？
事態がどれほど深刻なのか分からないが、現在SEP1.1対応のスマートメーターを導入し、後でSEP2.0に移行する計画を持っている電力会社は、結局“Over The Air”を使ってもSEP1.xにしかアップグレードできない可能性がある。
また、プロトコルスタックが大きくなるということは、より多くのプロセッサー・パワーおよび、より多くのメモリを必要とする。したがって、その実装コストは高価にならざるを得ない。

更に、SEP2.0のテスト機器では、電力消費量が予想より大きく、SEP1.xよりもずっと大きいという報告が入ってきている。
これは、バッテリー駆動型のIHD（家庭内表示装置）や、ガスメーターにとっては死活問題で、IHDやガスメーターではSEP2.0が採用されない可能性がある。
スマートにエネルギーを使うためにSEPを導入するのに、SEP2.0を使うと、SEP1.xより頻繁に電池の入れ替えが必要になる、あるいはコンセントから電気を採る必要があるのでは、本来の省エネ・節電の精神に反するのではないだろうか？

英国では、スマートメータリングにどのような技術を使うかの判断をエネルギー産業とともに行った結果SEP2.0採用を見送ったが、米国では、ベンチャー企業やNISTが産業界をリードしている。問題は、彼等が、必ずしも“スマートエネルギー”の実現を第一義とはしていないことである。
例えば、SEP1.x＋ZigBeeに比べて通信データ量が増えるというSEP2.0+6LoWPANの欠点に気づき、更なるデータ圧縮のため、SEP2.1として6LoWPANに加えてCoAP（Constrained Application Protocolの略。M2Mに特化した簡易HTTP）の使用が提案されている。
しかし、これは単にプロトコルの到達点を移動させただけで、エネルギー業界にとっては、新たな混乱と相互運用性の問題を引き起こす可能性がある。

米国は、英国の実用的なアプローチに従うか、“約束の地”を目指してこのまま歩み続けるか、ここは、一度立ち止まって、じっくり考えてみてはどうだろうか？

CREATIVE CONNECTIVITYというWebサイトは、20年以上モバイルおよび無線通信の世界で製品設計に携わってきた自称「無線通信の伝道者：Wireless Evangelist」Nick Hunn氏のオピニオンサイトです。これまでに、Grey Cell SystemsおよびEZURiOという2つの会社を立ち上げ、それぞれTDK CorporationおよびLaird Technologiesに売却、現在はOnzoというHEMS関連ソリューションベンダーのCTOとのこと。標準化関連作業にも携わっていて、Mobile Data Associationの副議長で、モバイルeHealthの推進や、Bluetooth等の作業グループのリーダーとしても活躍しているようです。

引用やたとえ話も面白く、本当はもっと砕けた表現なのですが、あまり忠実に翻訳すると、インターテックリサーチブログの中で浮いてしまいそうなので、いつもの調子で超訳しました。

文中「米国では、国立標準研究所（NIST）がスマートグリッドに関連するすべての装置でIPv6が使えるようにすることを必須条件と定めた」と訳した部分の原文は「In the US, NIST, who became involved in the smart energy standards, decreed that IPv6 must be supported by every device」なのですが、NISTのスマートグリッド相互運用性フレームワーク2.0で、これに該当する部分は、おそらく、下記部分だと思われます。
「Even though an alternative addressing scheme in conjunction with translation/mapping into IP addresses might work, we encourage the use of Internet Protocol version 6 (IPv6) for new systems to be developed and deployed.」
これらの表現を比較すると、ここは「必須条件」と訳すべきではないと思ったのですが、他の自分では確認が取れない個所でも同様に言い過ぎている部分があるかもしれないので、とりあえず、原文に沿った形で翻訳しています。

今年6月千葉・幕張Wireless Japan 2012が開催され、ZigBee SIG-JブースでZigBeeアライアンスのRyan Maley氏から、ZigBee標準の最新動向（ZigBee Standards Update）が紹介されました。
その中で、同氏はSEP2.0が今年12月には完成するだろうと話していましたが、残念ながら、なぜ開発が遅れたのか質問する時間はありませんでした。
もしこれをお読みくださっている読者諸兄で、ZigBee SIG-Jの方がいらっしゃいましたら、今回ご紹介した内容の真偽に関しましてご意見をいただきたく、よろしくお願いいたします。

なお、今回は絵が少なかったので、上記のWireless Japan 2012のZigBee SIG-Jブースで聞いた内容から、本日の話題に関連しそうな、いくつか面白い絵をピックアップして再掲させていただきます。

　SEP1.xとSEP2.0 （出典： ZigBee SIGジャパン テクニカルWGのプレゼン資料）

 

　SEP1.xとSEP2.0のスタック構成（出典： ZigBee SIGジャパン テクニカルWGのプレゼン資料）

　IEEE802.15.4と周波数・用途の関係（出典：ZigBee SIG ジャパンのプレゼン資料）

　注目が集まる920MHz帯無線に関する法令化動向（出典：ZigBee SIG ジャパンのプレゼン資料）

　Echonet Lite over 920MHz ZigBee IP（出典：ZigBee SIG ジャパンのプレゼン資料）

　Echonet Lite とSEP2.0の共存（出典：ZigBee SIG ジャパンのプレゼン資料）

 

終わり