IEEE1888を20分で理解する
Wikipediaの記事を読んでもよくわからなかった人のために。
「5分で理解する」というタイトルにしようと思ったんですが書いているうちに5分は無理だなと悟りました。20分ください。
IEEE1888とはなんなのか
IEEE1888は建物のエネルギー管理機器類がデータをやりとりするために作られた共通規格です。しかしその中身は時刻ラベルつきのデータ（文字列）を書き込むか読み取るかするだけというシンプルなもので、時系列のデータを扱うのならエネルギー管理でなくてもなんでもいいという柔軟なものです。金融情報にも渋滞情報にも使えてしまうんです。
BEMS
でもエネルギー管理の話に戻って。
ネット越しに温度いじれるスマートな空調機器ですとかネット越しに電力を見られるスマートな電力計ですとかをビル内に配置してシステムで集中管理してビルの電力消費を最適化しようじゃないか的なソリューションはいろいろなところが作っていまして、そういうのをまとめてBEMS（ビルエネルギー管理システム）と呼びます。
省エネ大事ですよね。
ところがそのBEMSをいろいろなところが作っているというのがまずくて、そのスマートな機器類の通信規格が乱立状態になってしまっているわけです。統一規格がないと機器の選定自由度も下がるし新規参入も阻まれるしコスト高止まるしでBEMSそのものが普及しない、統一規格を作ろうじゃないか、という発想で立ち上げられたのがこのIEEE1888になります。
しかし、BEMSの歴史をひもといてもらいますとね、どの規格もみんな同じ目標をぶちあげてきてるんですよ。「統一規格で相互接続性を！」って。2000年代のLonWorksもそうだし、1990年代のKNXも1980年代のBACNetもそう。その文脈で行くと、IEEE1888も規格乱立の歴史に1ページを加えるだけのものと思ってもよろしかろうとは存じます。
とは言え、2010年代ならではの特徴はないのか。やっぱりクラウド対応が特徴ですね。どういう風にクラウド対応かというと、
- HTTPベース、もっと具体的には実体がSOAP Webサービスです。JSONPとかじゃないのかって？ うーん、あと3年遅く立ち上がっていればJSONPだったんでしょうねえ…
- 識別子がワールドユニークになるように、URIとなっています。
ただまあ、BEMSってクラウドサービスにする必要があるの？ って疑問はあまり持たないでください… 悲しくなってしまうので…
ポイント、ポイントID
BEMS方面に詳しくない人がIEEE1888の文書を読み始めていきなりつまづくのが「ポイント」ですね。計測点と制御点をあわせたものなのですが、その計測点と制御点とは何かです。
まず計測点。直観とちょっと違うと思います。例えばスマート電力計のことではありません。スマート電力計ならば、その表示値が計測点に当たります。細かい違いと思うなかれ。計測点は時間とともにに変化する値のことです。変数といっても差し支えありません。変数だから、
- 計測点がIPアドレスのようなアクセス先を持っているわけではありません。
これ大事。
ところがです。ここがややこしさの2点目なのですが、前の節で書いたとおり、ワールドユニークにするためにポイントにはIDとしてURIを振るのです。URIだから通信先っぽい雰囲気あるんですが、これはあくまで識別子。あくまで変数名なんです。このURIにブラウザでアクセスしたら何か読み出せるのかというとそういうものじゃありません。ブラウザさんは404 Not Foundいただくことになります*1。
さて制御点を飛ばしてしまいました。制御点は書き込み可能な変数です。例えばエアコンの設定温度。書き込み可能ですね。設定温度だって時系列で変化する値なんだから、計測点でもあるのではないか。それは正しいです。大抵の制御点はそういう意味で計測点でもあります。
コンポーネント
というわけで概念だけの存在のポイントでしたが実際に通信する機器がコンポーネントです。SOAP Webサービスなので機器同士の通信アクセス先はやっぱりURIになります。これが紛らわしい。電力メーターの表示値を読み出したいときは
要求するという通信をするわけです。紛らわしいでしょ？
この電力メーターのようなポイントデータの一次情報源になるコンポーネント、またはエアコンのように制御点への実際の書き込みを受け付けるコンポーネントを特にゲートウェイ(GW)と呼んでいます。ゲートウェイというと他規格ネットワークだとか別セグメントとの接合点のようなものを想像しがちでしょうかね。しかしそういう意味ではありません。IEEE1888ネットワークの内と外をつなぐ機器がゲートウェイです。電力メーターならば、IEEE1888ネットワークと実世界とを結んでいます。で、そういう意味では他規格ネットワークとの接合点も内と外を結んでいるので結局ゲートウェイだったりします。
ゲートウェイ以外に特に名前のあるコンポーネント類型には、ストレージとAPPがあります。ポイントデータを憶えておく役目をするのがストレージ、GWやストレージを利用して何か機能を実現するのがAPPです。
コンポーネント同士の通信は以下の3通り。
レジストリ
さてここまでの概念と役者はいいとして。
実際にスマート電力メーター設置しました、スマート電力メーターにIPアドレス割り振ってアクセスURIが決まったし、表示値を表すポイントIDも決めて電力メーターに教え込みました。そしたらこのアクセスURIとポイントIDは集中管理システムにどう教え込めばいいのか。
電力メーターにアクセスしたいAPPすべてについて、設定ファイルなんかにビル一棟分ばーっと電力メーターのURIを書いてあげてもいいんです。でもそういうのだと、新しいAPPを入れるたびに新入りさんに設定ファイルを書いてあげなくてはいけなかったり、電力メーターの出入りがあったら全部のAPPの設定ファイル書き換えてあげないといけなかったり、要はやってらんないです。
ポイントIDとアクセスURIがどこかで集中管理されていていつでも引けないかという話、それがレジストリです。
レジストリには
の2種類の問い合わせが可能です。どちらもLOOKUPと呼ばれる操作なので区別のためにコンポーネントLOOKUP、ポイントLOOKUPと呼びましょう。
前者のコンポーネントLOOKUPはとてもわかりやすいですね。以上。問題は後者の方。「条件を指定して」とはなんぞや。
ポイント属性
レジストリの頭の中では、ポイントがいろいろ属性つきで覚え込まれています。key=value形式の属性がポイントに複数くっついているというかたちです。
条件を指定するとは、「○○(key)が××(value)であるもの」という形式で問い合わせることを意味します。ANDやORも可。「typeがpower_meterであるもの」なんて指定すると建物中の電力計測点のポイントIDがごそっと取れたり。
で、ここからが大事。
ポイント属性は面倒です。いま"type"とか"power_meter"とか書きましたが、こういう文字列はIEEE1888ではまったく規定されていないんです。"type"も"power_meter"も、たった今でっちあげました。
これはつまり、こう言わざるを得ません。
- ポイントを検索する機能はレジストリに規定されているが、実際に探す方法はない。
だってそうなんです。「電力計を探したい」と思ったとしてもレジストリに問い合わせるのにどんなkey,valueを指定すればいいか、そこから決まっていないんですから。
レジストリは事実上、コンポーネントLOOKUPという機能だけを提供しています。ポイントIDからアクセスURIを引けます。
ちなみにレジストリへアクセスするためのURIはどこで教えてもらえばいいのか。…それもう、最初から機器に教えておいてあげてください。ブロードキャストでアドバタイズとかそういうのは規定されていません。
実際のコーディング
コーディング例はちょっとずつ書いていきます。
または、本買えばコード載ってます。
