「Lite」で普及の兆しを見せる「ECHONET」、波乱万丈の20年史と今後の課題:IoT観測所(18)(3/4 ページ)
国内HEMSの標準プロトコルとなり電力自由化の後押しもあって、普及の兆しが見える「ECHONET Lite」だが、前身のECHONETを含めると苦難の連続といえる。その歴史を振り返り、現状の課題を確認する。
実態に即していなかった仕様
また、全般的にプロトコルも、今から見ると重厚な構成だった(Photo04)。特にIoT向けの場合、消費電力を抑えるためにパケットサイズをどこまで抑えるかも課題になっているのだが、この当時想定されていた対応機器は、基本外部電源が利用できる事を考えていたのか、あまりパケットサイズを削減する事は考えていなかったように思われる。
Photo04:ECHONET SPECIFICATION Version 3.21の"第2部 ECHONET通信ミドルウェア仕様"の図4.1-1より抜粋。昔の通信プロトコルはこんな感じが一般的であったが...ちなみにこの形式IIが、ECHONET Liteでは形式Iになった
また、当時は考えうる全ての仕様を取り込もうと考えたのだろう。オブジェクトもスゴいことになっている。例えばAPPENDIXで定義されている機器オブジェクト詳細規定を見てみると、センサー関連オブジェクトだけで44種類が定義されており、このうち43種類には詳細規定まで定義されている(なぜか昼光センサーのみ、詳細規定がない)。
同様に空調関連機器クラスは8種類、住宅・設備関連機器が16種類、調理・家電関連機器クラスは6種類と重厚な割に、健康関連機器クラスは体重計のみ(なぜか活動量計はセンサークラスに含まれている一方、体脂肪計や血圧計などは含まれていない)とか、調理・家電関連機器に掃除機がない(つまりルンバの様な自動掃除ロボットを扱う方法がない)とか、実装に手間がかかりそうな一方で、ヌケも多いのが実情である。
プロトコルが重いとかいう以前に、そもそもこれでアプリケーションを作ろうとすると大変というのが実情であった。仕様を定めるのに時間がかかりすぎ、その間に仕様が陳腐化してしまったというべきであろうか。
現実に即して生まれ変わった「ECHONET Lite」
こうした反省を踏まえて、ECHONETをベースにもう少し現実に即したものを、ということで2011年から仕様策定が始まったのが「ECHONET Lite」である。
このECHONET Liteの構成は「ECHONET Lite 開発の目的」(リンク先PDF)の中で「MACアドレスなどの固定アドレスを持ったメディアやIP対応機器の普及により冗長となったECHONETアドレスと、実装実績が少ない機能である通信定義オブジェクト、プロファイルオブジェクト、サービスオブジェクト、ECHONETルータ、NetIDサーバなどを削除するとともに、電文構成をシンプルにした、ECHONET Lite規格を開発することとしました。」と記されている。
要するに冗長性を排除して軽量化を図ったというワケだ。実際、ネットワーク構成(Photo05)を見ると、一応IPがベースという事になっているが、事実上何も規定していないも同然で、ここはNetwork層にお任せである。
これはブロック図(Photo06)からも明らかで、OSIのモデルで言うところの第4層以下はノータッチとなっている。
Photo06:ECHONET Lite SPECIFICATION Version 1.12の"第1部 ECHONET Liteの概要"の図3-1より抜粋。OSIレイヤーの説明がある意味すがすがしいというか……
これにあわせて、ECHONETの時代には「Full_Device」(ECHONET用のI/Fを内蔵し、単独でECHONETに接続できる機器)、「Flex_Device」(ECHONET通信処理部以上の機能を内包し、ECHONETアダプターと組み合わせてECHONETに接続できる機器)、「Ready_Deivce」(ECHONET通信処理部との共通APIにのみ準拠した機能を持ち、通信処理部以下の機能を持つECHONETアダプターと組み合わせてECHONETに接続できる機器)の3種類が定義されていたのが変更された。
ECHONET LiteではFlex_Deviceに相当するものがFull_Deviceとされ、Flex_Deviceの定義がなくなる(Ready_Deviceはそのまま)といった形に変更されている。そんなわけで、根っこの部分では同じECHONETとECHONET Liteであるが、実際に運用する際の互換性はない(ECHONET対応機器やネットワークがほとんど存在しない状態だったから、問題にはならないと思うが)。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 日本発の無線規格「Wi-SUN」、国際展開への飛躍を阻む4つの問題
IoTにまつわる標準化規格で数少ない日本発の規格が「Wi-SUN」だ。家庭向けに低消費電力でメッシュネットワークを構築できるWi-SUNの特徴と、国際的なデファクトスタンダード化を阻む問題について解説する。 - IoT団体によるUPnP(Universal Plug and Play)吸収を読み解く
インテルやサムスンらが主導するIoT標準化団体「OIC」が、UPnP(Universal Plug and Play)Forumを吸収した。UPnPの推進する“挿すだけで使える”をIoTに持ち込むことは理にかなっているように思えるが、AppleのHomeKitや、GoogleのProject Brilloに対する競争力はあるだろうか。 - 出遅れた老舗「oneM2M」、Alljoyn連携で巻き返しなるか
通信関係の標準化団体が組織した「oneM2M」は、M2Mプラットフォームの水平化を狙うが、IoTを取り巻くスピードは速く、実装までを考えると遅きに失する感が否めない。Alljoynとの連携での巻き返しを狙う。 - アマゾン「AWS IoT」は何が衝撃的なのか
米Amazonが発表したIoTサービス「AWS IoT」は業界に大きなインパクトを与えた。一企業の発表した取り組みがなぜ、IoTを取り巻く各社に大きな影響を及ぼすのかを考察する。 - ARM「mbed OS」の現在地
ARMが発表したIoT向けOS「mbed OS」は2015年10月のリリースを目指して作業が進められており、その意図するものもある程度は見えてきた。Bluemix連携やMUCの55mmシフトなどトピックの多いmbed OSの「いま」を解説する。