SEP2.0のはなし
IoT がらみの話題で、今回は Smart Energy Profile (SEP) 2.0 のおはなしです。
クリーンエネルギーと SEP 2.0
事の発端は 2005 年頃から流行り出した「スマートグリッド」でした。現代文明を支える電力配送網(パワーグリッド)は複数の発電所・変電所と消費先(都市・工業施設など)が文字通り網目のように絡み合い、常に変動する需要と供給のバランスを多分に熟練のオペレーター操作によって保ってきました。そこにコンピュータ技術を導入して自動化を図るのがスマートグリッドの第一目的ですが、グリッドの自動化によって電力運用はより柔軟になり、発電能力が不安定な風力や太陽発電などの自然エネルギーもより有効に活用できるようになる、と考えられました。
特に 2009 年にアメリカ合衆国大統領に就任したバラク・オバマ氏は化石資源に頼らない「クリーン・エネルギー政策(※註)」を推進、屋根上の太陽電池や工場煙突の排熱発電など小規模発電施設が広く浅く分散する姿が語られ、それをまとめて再配送するためにスマートグリッドは必要不可欠なインフラとして位置づけられました。例によって例のごとく、マスコミには「クリーンエネルギー革命」「スマートグリッド時代のうんたらかんたら」などの見出しが躍ることになります。
※註：「グリーン・ニューディール(Green New Deal)」というキーワードも騒がれましたね。Wikipedia によればこの言いだしっぺはジャーナリストのトーマス・フリードマンで、オバマ大統領就任よりやや早い 2008 年頃から使われ出したようです。
さて、Zigbee Smart Energy Profile 1.0 (SEP 1.0) 仕様は 2009 年 6 月に公開された Zigbee 無線規格の電力制御仕様です。SEP は世帯～集合住宅規模くらいの電力管理を行うフレームワークとして既定されたもので、地域・国家規模の送電制御を行う「スマートグリッド」の通信規格ではありません。しかし電力配送がスマート化するならば受け手たる世帯側もスマート化する必要があると考えられ、SEP はその有力候補となりました。
しかしながら、SEP 1.x はあくまで「Zigbee という製品体系上の規格」であることが問題となりました。アメリカ政府の推進する標準規格として特定の技術ベースに依存しないオープンスタンダードであることが求められ、6LoWPAN を採用し IPv6 ベースで動作するSmart Energy Profile 2.0 (SEP 2.0) の策定が急務となりました。
結果的に SEP 1.x と 2.0 は名前を継承しているだけで、中身は似ても似つかない別物になっています。SEP 2.0 は SEP 1.x を置き換えるものではなく、あくまで同じ目的(電力制御)を別の手段(Zigbee か 6LoWPAN か)で実現する２つの規格、という位置づけになっています。コンシューマ市場には Zigbee・公共インフラ市場には 6LoWPAN という使い分けを意図しているのかも知れません。
IETF の履歴(※註)を見ると、6LoWPAN ワークグループの発足は SEP 2.0 より 5 年も前の 2005 年 3 月となっています。当初は確たる方針もマイルストーンもなくまったりペースで進んでいたようですが、その状況が一変するのは 2007 年になって「IPv6 の 802.15.4 対応」という具体的な目標が掲げられてからでした。6LoWPAN が必ずしも SEP 2.0 のために開発された訳ではなく、しかし SEP 2.0 の制定開始によって制定に向けて加速された雰囲気が伺われます。
※註：https://datatracker.ietf.org/wg/6lowpan/charter/
SEP 2.0 は Zigbee Alliance と HomePlug Alliance 共同提案のようなかたちで制定され、2010 年 5 月に公表されます。制定まもなく北米エネルギー省(DoE)と国立標準技術研究所(NIST)の「お墨付き」を得、ZigBee 陣営にとっては不倶戴天の敵たる Wi-Fi Alliance も採用を表明し、SEP 2.0 は「来るべきスマートグリッド時代の標準」として盤石の地位を固めたかのように思われました。さて、その中身と実態はどのようなものなのでしょうか。
Inside SEP 2.0
SEP 2.0 は前述のように 6LoWPAN/IPv6 上で動作し、サービス／ノードディスカバリは multicast DNS Service Discovery (mDNS-SD) で行うこととなっています。アプリケーション層は HTTP (HTTP over TLS1.2) の上にいわゆる「RESTful」インターフェースとして実装されており、そこを流れるデータフォーマット(プレゼンテーション層)は XML あるいは EXI (Efficient XML Interchange、一種の圧縮 XML)ですが、XML の文法(スキーマ)は IEC 61968 CIM (Common Information Model) に従うことと既定されています。
CIM について本格的に解説すればそれだけで本が一冊書けてしまうので割愛しますが、もともと国際電気標準会議 (IEC:International Electrotechnical Commission）が定めた国際標準規格で、配電管理システムのモデル化記述を行う言語体系です。CIM では UML オブジェクト図と XML への変換規則が既定されており、「図に描けばそれが仕様書(XML/RDF スキーマ)として出力され、それを RDF インタプリタ・パーサに通せば仕様が理解されて実装される」建前になっています(※註)。
※註：90 年代に流行った SNMP も「ASN.1 言語で仕様を書けば MIB データベースが出力され、それを MIB コンパイラに食わせるだけで仕様が理解され実装される」という縦前でしたが、現実にはしょっちゅう仕様変更されるプライベート MIB の山と実装バグに振り回されるのが実態でした。SOAP/XML がブームになった時も「また同じようなこと言い出したよ」と思ったものですが...
この手の「美しく整然と既定された仕様」にはよくあるように、CIM は「辞書(Dictionary)」と渾名される分厚い仕様書にびっしりとキーワード既定とその意味についての定義が並び、CIM に従った XML も <cim:なんとか.かんとか.Container> だとか <cim:なんとか.かんとか.Name> といった長いタグが何段にもネストした代物になります。
そして何度か解説してきたように、6LoWPAN は決して「802.15.4 上で TCP/IP がスイスイ動いちゃう魔法の規格」ではありません。リンク速度 250Kbit/sec でペイロードサイズ 127 バイトという物理層制限は頑として存在し、そこを IPv6 パケットをブツ切りにして無理やり通す道を開いたというだけです。多段タグだらけの CIM-XML なんか素で流せば本文だけでも数キロバイトに達するでしょうし、EXI を使っても１フレーム 127 バイトには到底収まらないでしょう。セキュリティ層のために TLS を被せれば、証明書の交換で更に数キロバイトが上乗せされます。
要するに「台所の照明 ON」というメッセージ一つを発行するためにも <cim:なんとか.かんとか> が何段にもネストした XML 文書が HTTP の上に乗って TLS 証明書のヘッダが付き、それが 6LoWPAN で何十個ものフラグメントぶつ切りにして 802.15.4 上を飛ばす規格が SEP 2.0 だとも言えます。しかも SEP 2.0 はブローカー型ではなく古典的なクライアント・サーバ型の WEB サービスなので、メッセージを投げる前にまず「メッセージの送り先(の IPv6 アドレス)」を探さなければなりません。前述したようにこれは mDNS-SD として既定されていますが、一斉通知ブロードキャストを嫌う(省電力機能が活かせない) 802.15.4 上で一斉通知マルチキャストを乱発する mDNS-SD を使うというのも「一体どういうつもりだ？」と思います。
SEP 2.0 が制定された 2005 年前後は XML と SOAP/WSD が「オープンデータと分散ウェブサービスによる SaaS がもたらす WEB 2.0 革命がうんたらかんたら」ともてはやされていた時期でした。mDNS-SD もマイクロソフトと Appleがそれぞれ似て非なる実装(LLMNR と Bonjour)で IETF ドラフトを提出し RFC 化を狙っていた時期(※註)ですから、「これらが次世代の標準規格になるだろう」という目論見で採用したのではないでしょうか。
SEP 2.0 はこのように、頭の天辺(CIM/XML)から尻尾の先(IPv6/6LoWPAN) に至るまで「国際標準規格」でガチガチに固めた規格になっています。SEP 1.x が「特定ベンダー技術(Zigbee)に依存し国際標準から乖離している」と批判された反動というか、「ハァハァどうだ、これなら文句ないだろ！」と啖呵を切る Zigbee Alliance の血走った目が見えるような気がする...のは私だけでしょうか。
※註：しかし、DNS のマルチキャスト拡張は IETF の強硬な反対に直面して制定はすさまじく遅延します。どのくらい「すさまじい」かというと、マイクロソフトの LLMNR は 2000 年 3 月に作業開始、47 回のドラフト改訂後 2007 年 6 月に RFC4795 として制定。アップルの Bonjour は Zeroconf グループとして 1999 年 9 月に発足、少なくとも 15 回のドラフト改訂後 RFC6762 として制定されるのは実に 2013 年 2 月のことになります。2000 年前後は猫も杓子も自社独自仕様を片端からドラフト化して IETF に投げ付け「あわよくば RFC 標準化」をダメモトで狙うという悪習が横行していた時期だったという弁護の余地はあるものの、DNS のマルチキャスト拡張に 7 年や 14 年もかけるのは如何なものか思います。
SEP 2.0 の現状
さて、そんな SEP 2.0 の現状はどのようなものでしょうか。これが「何だかよくわからない」のです。スマートグリッドに関する話題には関連する標準規格として常に名前は出てくるものの、SEP 2.0 に対応した製品がいったいどれだけリリースされているのか、それらをまとめて「スマホのタッチひとつで電灯やエアコンを自由自在に制御できる」製品が出ているのかどうか、よくわかりません。SEP 2.0 に関してネット検索しても、スマートグリッドの技術動向だとか SEP 2.0 規格自身に関する解説ばかりで、「SEP 2.0 を実装した製品です」とか「SEP 2.0 を使えばこんなことが実現できます！」という話はほとんど出てきません。何だか「規格のための規格」ではないのか、という気もしてきます。
「SEP 2.0 相互接続運用検証コンソーシアム(http://www.csep.org/) という団体もあるようですが、接続検証会(Plugfest)は 2012 年に「第１回」をやったきりのようです。2015 年 6 月には「SEP2 Expo」という展示会もやったようですが、出展 14 社・来場者 100 人強というのは「北米エネルギー省(DoE)のお墨付きを得て」「来るべきスマートグリッド時代の標準として盤石の地位を固めた」規格にしては何とも寂しい規模です。これは一体どうしたことなのでしょう？
IoT と SEP 2.0
「IoT/IoE 市場は 2020 年には年間 500 億台 150 兆円規模」とか、景気の良い取らぬ狸の皮算用がメディアに流れるようになって久しいですが、10 年前にあれだけ騒がれたスマートグリッドは IoT ブームからは取り残されつつあるようです。Google 検索で「smart grid」だと約１７００万件、「internet of things」だと実に２億１７００万件で文字通り桁が違い、「ネタとしての鮮度」の違いを痛感します。
SEP 2.0 はあまりに電力制御に特化しすぎた機能仕様(IEC 61968 CIM ベース)のため、そのままでは体重計だの温度計だの「何でもつなぐ」つもりの IoT には使えません。もちろん拡張性がウリの XML ですからスキーマを増やせば何でも表現可能ではありますが、その次はあまりに標準規格を意識しすぎたプロトコル仕様(XML+HTTP+TLS over 6LoWPAN)が消費メモリ量と通信効率そして消費電力の問題になりそうです。電力線にぶら下がっていることが前提のスマートグリッドと異なり、IoT は最低でもバッテリー駆動・望ましくは光電池や熱電池で半永久的に動き続けるエナジーハーベスト駆動が求められますから、送受信時間の増加＝消費電力の増大を意味する通信データの肥大化には敏感です。時代を逆行したような UDP ベース、可変長バイナリフォーマットの MQTT が急に注目されだしたのは多分にそれが理由でしょう。しかし例によって例のごとく、人類は一体何をやっているんだろうという気になってきますが...。
「良い標準」は顧客の数だけ存在する
以前に紹介した MQTT と比べると、SEP 2.0 はこのように対照的な規格です。私は個人的に「緩い標準」を好み「厳格な標準」を胡散臭い目で見る傾向がありますが、しかしどちらが絶対的に良い・悪いという話でもないのです。
MQTT は確かに実装が容易で実行効率も高いでしょうが、トピック名やメッセージフォーマットが実装依存になっている以上、同じ「MQTT 準拠」でも互換性のない実装系がゴマンと湧いて出てくるリスクがあります。極論すれば、あるシステムでは「台所の照明 ON」を意味するメッセージが、別のシステムでは「全消火栓の開放」を意味するかも知れません。現実には「無効なメッセージ」として弾かれて終了でしょうけれど、そうならない保証は何処にもありません。
一方 SEP 2.0 は標準規格でガチガチに固めてあるため、一旦定義された「台所の照明 ON」は世界のどこのどんなシステムでも「台所のスイッチ ON」として機能し(少なくとも他の機能と混同しないことは保証される)、その互換性は将来にわたって保証されます(少なくとも縦前上は)。
私も長くこの業界に居ますから、この手の「緩い標準」と「厳格な標準」の並存・競争は嫌というほど見てきました。多くの場合、「厳格な標準」が電話帳みたいな仕様書の山をせっせと築いている間にどこかのメーカーが独自仕様を実装した製品を出してベストセラーになり、その安価な互換品が雨後のタケノコみたいな勢いで出荷された結果、最初の製品のバグやらコピー製品の機能拡張も含めた最大公約数みたいな仕様が「デファクトスタンダード」としてなんとなく定着する...というパターンを繰り返し見てきた気がします。
もっともそれは移り気なコンシューマ市場の話で、電力業界だとか航空宇宙産業ではそんないい加減な経緯で仕様を決めることはまず無いでしょう。「どちらが良い・悪い」という話ではなく、その市場において何を価値とするのか・その価値により適したアプローチはどちらかという相対的な話です。そしてコンシューマ市場と公共施設市場では価値の評価基準が異なるため、そこに適した標準規格のかたちも違ってしまうのでしょう。
HEMS と SEP 2.0
日本におけるスマートグリッドを巡る話題には、「クリーン・エネルギー」や「グリーン・ニューディール」よりも HEMS (Home Energy Management System) というキーワードの方がよく使われています。そして日本政府推奨の HEMS 標準プロトコルは SEP ではなく ECHONET Lite とされています。なのでなおさら「米国ローカル標準」である SEP は日本では話題になりにくいのかも知れません。
ECHONET Lite についても詳しい記述は割愛しますが、フォーマットは XML ではなく独自の(旧 ECHONET 規格から引き継がれた)バイナリ形式を採用し、名前空間も EPC (ECHONET Property Code) という 8bit バイナリ値を「クラス」「クラスグループ」の分類ごとに定める形式としています。一般的には UDP ポート 3610 (IPv4/v6) 上に実装されますが、トランスポート層・物理層・セキュリティ層いずれについても ECHONET Lite 自身では厳格には既定せず、必要に応じて既存技術を組み合わせて適用するとされています。
頭から尻尾までタテマエで固めた SEP 2.0 よりは MQTT に近く、しかし何でも丸投げの MQTT とは違って名前空間やデータ表記が既定された規格のような立ち位置です。個人的には、ホンネとタテマエのバランスを上手く取った規格案ではないかと思うのですが、残念ながら日本以外では殆ど話題に取り上げられていないようです...。
まとめ
今回もかなりシニカルな文調になりました。WiFi 陣営に身を置いているから非 WiFi 規格を斜めに見る...という訳ではないつもりですが、SEP 2.0 についてその制定経緯や実装の中身を調べてみると、各種のタテマエ標準に振り回された過去がフラッシュバックして微妙な気持ちになります。
SEP 2.0 は電力業社向けの IEC 規格のサブセットのような格好ですが、このように公共施設向けの「厳密で厳格な規格」の簡易版をコンシューマ版として位置づけるのは、現実にはうまく行かないことが多いと感じます。似たような話は 1990 年代の電話網デジタル化(INS)とインターネット(TCP/IP)の間にもありました。本来は INS によって「卓上から大陸間まで、統一された規格でシームレスにつながるネットワーク」が実現する筈だったのですが、けっきょく末端では INS の S/T 点ではなく DSL や FTTH の上で TCP/IP が動いている(しかも更にそこから Ethernet や WiFi が分岐している)わけで、現実には「統一された規格でシームレス」にはなりませんでした。こういう現実を見るたび、バベルの塔の故事を思い出さずにいられません。
昨今の IoT/IoE ブームについても「全ての製品間で相互接続運用を可能にする統一規格が必要だ」という論調がありますが、それはたぶん実現せず、市場ごと・地域ごと・製品カテゴリごとに違った規格が定着するのではないか、と感じています。