IEEE_1888とは - わかりやすく解説 Weblio辞書 (original) (raw)

IEEE1888は、次世代BEMSやスマートグリッド向けに開発され、2011年に国際標準化されたオープンな通信規格である。正式名を UGCCNet (Ubiquitous Green Community Control Network)と呼ぶ。この規格の開発には、日本の東大グリーンICTプロジェクト[1]が関与しており、日本では、FIAP(ふぃあっぷ: Facility Information Access Protocol) と呼ぶこともある。

IEEE1888は、あらゆるセンサ情報をインターネット・オンライン化することだけが目的ではない。BEMSなどに関係する様々な情報システム（アプリケーション・ソフトウェアやクラウド・サービス）をベンダーの枠を超えて連携可能にすることが目的となっている。そのため、IEEE1888には、HTTPとXMLによる通信方式が採用されている。また、データ保管(共有)機能が提供できるように設計されている。

組込みコンピュータへの実装も進んでおり、スマート・シティに関わる各種M2Mクラウド(Machine-to-Machineクラウドコンピューティング)分野への応用も始まっている。

Z-Wave[2]やECHONET[3]などのHEMS規格が家庭内ネットワークを主に想定しているのに対し、IEEE1888は、(1)家庭外との通信、(2)商業施設やオフィスなどの電力・施設管理、をターゲットとしている。

なお、IEEE1888開発において重要な基礎技術（ソフトウェア、開発ツール、マニュアル等）は、積極的に開発・開示されている。

2015年3月 ISO/IECの国際標準としても承認された (ISO/IEC/IEEE 18880[4])。

目次

• 1 アーキテクチャ
  • 1.1 ゲートウェイ（GW）
  • 1.2 ストレージ（Storage）
  • 1.3 アプリケーション（APP）
• 2 通信手順
  • 2.1 WRITE
  • 2.2 FETCH
  • 2.3 TRAP
• 3 既存のM2M規格との関係性
• 4 導入事例
• 5 開発環境
• 6 外部リンク
• 7 参考文献

アーキテクチャ

IEEE1888 システムアーキテクチャ

IEEE1888では、GW(ゲートウェイ)、Storage(ストレージ)、APP(アプリケーション)、Registry(レジストリ)と呼ばれる機能が定義されている。このうち、GW、Storage、APPは、IEEE1888コンポーネントと呼ばれ、WRITE、FETCH、TRAPと呼ぶ3種類の通信手順を実装する。残りのレジストリは、分散配置されたIEEE1888コンポーネントを管理する役割を持ち、REGISTRATION、LOOKUPと呼ぶ2種類の通信手順を実装する。

ゲートウェイ（GW）

GWの配下には、Lonworks[5]、BACnet[6]、Modbus[7]、ZigBee、SNMP、1-Wire、独自回路、CSVファイルなど、センサやアクチュエータへのアクセス網（フィールドバス）が接続される。GWは、このような様々なアクセス網の規格の差異を吸収し、センサデータをIEEE1888の通信方式で、インターネット上で扱えるようにする。

ストレージ（Storage）

Storageは、GWを使ってインターネット・オンライン化されたデータを長期間に渡って蓄積する役割を果たす。これにより、例えば、昨年や一昨年の電力消費状況であっても、後に、他のアプリケーションからIEEE1888の通信手順で参照することができる。また、Storageはデータを共有する場としても使われる。GWから集められたデータの共有、アプリケーションが処理したデータの共有などがStorageによって実現される。すなわち、データベースと似た役割を持つ。

アプリケーション（APP）

APPは、その応用方法によって様々な役割および実装形態がありえる。例えば、見える化アプリケーションの場合、Storageから最新値もしくは特定の履歴データを読み出して表示することがAPPの役割となる。そして，そのようばAPPであれば、Webサーバや表示端末のようなものに実装される。一方、データの加工分析アプリケーションの場合、生データの履歴をStorageから読み出して、それを統計的に処理した後、再びStorageに書き戻す。この場合は、バッチプログラムとして実装されることになる。

通信手順

IEEE1888通信の例

GW、Storage、APPは、それぞれサーバになることもできるし、クライアントになることもできる。例えば、Storageがサーバとなり、GWがクライアントとなって、GWからStorageに(WRITE手順で)データを送り付けるという実現形態がある。

WRITE

WRITE手順は、クライアント側からサーバ側に、データを能動的に送りつける方式である。例えば、NAT下にあるGW(クライアントとして動作)から、グローバル・インターネット上にあるStorage(サーバとして動作)にデータを送り付けるときに使われる。

FETCH

FETCH手順は、クライアント側からサーバ側に問い合わせ、サーバからデータを抜き出してくる方式である。この問い合わせの際には、対象とするデータ範囲を指定する。ここで、指定した範囲のデータ量はしばしば多量になるため、FETCH方式にはデータ量に関するスケール性が備わるような工夫がしてある。例えば、見える化のグラフ画像を生成するソフトウェア(クライアントとして動作)が、Storage(サーバとして動作)からデータを読み出すときに使われる。

TRAP

TRAP手順は、クライアント側からサーバ側に事前に興味対象を登録しておくことで、サーバ側で観測された変化を、クライアント側に通知する方式である。FETCH方式が、蓄積されたデータの読み出しに用いられるのに対し、TRAPは、変化するデータの通知に使われる。一方的に送り付けるWRITE方式と違い、TRAPでは、動的に送り先を設定できるようになっている。

既存のM2M規格との関係性

ビルの設備・エネルギー監視には、1990年代より、Modbus、BACnet、Lonworksなどのローカルな監視制御ネットワーク規格が用いられている。IEEE1888は、これらのローカルな監視制御機能を、リモート（クラウド）に接続することを可能にする。これによって、ビル内の専用コンピュータが組込みシステム化され、オペレータは、場所を問わず、通常のWebブラウザ(スマートフォンやタブレット端末を含む)があれば業務を行うことができるようになる。

既存のM2M規格との比較 (ビル設備管理の分野において)

| | IEEE1888 | Lonworks | BACnet/IP | Modbus | ZigBee | | | | ----------------- | ------------------------------------ | ------------------------------------------ | --------------------------------------------------- | -------------------------------------------------- | -------------------------- | --------------------------------------------------- | | 主要な用途 | 設備・エネルギー管理 | ビルオートメーション | ビルオートメーション | 設備状態監視 | センサ・アクチュエータの無線化 | | | システムの規模 | 地球規模/都市規模の展開 | ◎ | × | × | × | × | | 中/大規模ビル内の展開 | ○ | × | ○ | ○ | × | | | 小規模ビル内の展開 | ○ | ○ | △ | ○ | × | | | フロア/部屋内の展開 | ○ | ○ | △ | ○ | ○ | | | データ蓄積 | データサーバでの蓄積 | ◎ | △(アプリとして各自で開発) | △(アプリとして各自で開発) | △(アプリとして各自で開発) | △(アプリとして各自で開発) | | 末端デバイスでの蓄積 | ○ | × | ○ | × | × | | | 蓄積しない運用 | ○ | ○ | ○ | ○ | ○ | | | 利用する技術(下位層) | HTTP | 2本線(ツイストペア) | UDP | RS485 or TCP | IEEE 802.15.4 | | | 電文形式 | XML | Binary | Binary | Binary | 自由(Binary/Text/XML/etc...) | | | センサアクチュエータ・データモデル | 個別用途向け | 用途ごとに設計・実装（エンジニアリング）する or 用途ごとに標準形式を別途作成する | 標準形式はある程度定義されているが、LonMakerにより用途ごとに別途、詳細を設計・実装する必要あり | 基礎形式はある程度定義されているが、加えて用途ごとに別途、設計・実装（エンジニアリング）する必要あり | 用途ごとに設計・実装（エンジニアリング）する | 用途ごとに設計・実装（エンジニアリング）する or 定義されている用途向けの標準プロファイルを利用する | | 時系列データ | ◎ | × | △ | × | × | | | 通信遅延 | ビル内通信: 1ms～100ms インターネット通信: 100ms～5s | ビル内: 1ms～100ms | ビル内: 1ms～100ms | ビル内通常: 1ms～100ms 通信混雑時: 1～60s | フロア内: 10ms～1s | | | 時刻同期 | 一般的な方式を利用する(NTP, GPS, 3G, ...) | 通常は時刻同期は行わない | 通常は時刻同期は行わない(一部独自の方式により行う) | 通常は時刻同期は行わない | 通常は時刻同期は行わない(一部行う) | |

導入事例

東京大学では、本郷キャンパス、駒場Ⅰキャンパス、駒場Ⅱキャンパス、柏キャンパス、白金キャンパスにIEEE1888のGWをそれぞれ導入し、特別高圧を含む受電設備の計測データを、オンラインでリアルタイムに管理している。電力会社から受電する66kVの他、キャンパス内に張り巡らされた6600Vの電力線が個別に最速1分間隔で計測されている。ビル単位での計測も含めると約400系統の電力線がこのシステムの管理対象になる。上記、5キャンパスの電力需要の合計は、5万キロワットを超える(夏場)。

東京大学の電力見える化サービスは、キャンパス毎の電力消費量を表示しているが、実際には、エリア単位・建物単位での電力消費量も把握できるようになっている(詳細なデータは学外には公開されていない)。

• IoT/M2M情報収集ソリューション
• RemoteOne®～節電・省エネサービス～

開発環境

IEEE1888SDKの構成図

IEEE1888のソフトウェア開発キット(SDK)、実装参照ソースコード、プロトコルテスター が、東大グリーンICTプロジェクトのWebページにて無償で公開されていて、自由にダウンロードすることができる。SDKは、仮想マシン(VMware Player)イメージによって提供されており、インストール方法も詳しく紹介されている。SDKに同梱されているドキュメントには、C#、Java、PHP、C言語によるサンプルプログラムが掲載されており、これらを参照することによって、IEEE1888の通信スタックをどのように実装すればよいかが、事細かにわかるようになっている。

IEEE1888通信ボード

またIEEE1888は、Arduino(+Ethernetシールド)や、mbedプラットフォームのような小型で安価な組込みコンピュータにも実装され、そのライブラリも公開されている[8][9][10]。東京大学で開発された IEEE1888通信ボードは、一般向けに販売されている。

外部リンク

• スマートグリッド対応 IEEE1888プロトコル教科書
• IEEE 1888-2011: Standard for Ubiquitous Green Community Control Network
• スマートグリッド向け新プロトコル「IEEE 1888」の全容と省エネ戦略2011［東大グリーンICTプロジェクトの「IEEE 1888システム」と節電対策の実践］
• デジタルデザインテクノロジ誌 2012年冬 (No.12号)
• 「電力管理に便利なIEEE1888通信規格」の相互接続実験を実施
• IEEE1888を20分で理解する

参考文献

1. ^ 東大グリーンICTプロジェクト ホームページ
2. ^ Z-wave Alliance ホームページ
3. ^ ECHONET コンソーシアム
4. ^ ISO/IEC/IEEE 18880
5. ^ Lonworks: local operating networks for building automations
6. ^ BACnet: a data communication protocol for building automation and control networks
7. ^ Modbus ホームページ
8. ^ 落合秀也，"IEEE 1888対応スマート・タップの設計"、デジタルデザインテクノロジ誌，CQ出版社，vol.12, pp.116-127, 2012年．
9. ^ 落合秀也，井上博之，"ネットワーク温度＆照度計 後編 Ethernetシールド付きArduinoにアップロードのためのライブラリを搭載"，トランジスタ技術，CQ出版社，vol.49, no.2，pp.189--195, 2012年2月．
10. ^ IEEE1888(FIAP)をmbedで使う