[標準化動向]

OpenADR 2.0対応製品が登場!

― 日本版DRインタフェース仕様が完成し採用へ ―
2013/06/01
(土)

2012年9月に開催された「第2回スマートハウス・ビル標準・事業促進検討会」は、スマートハウス・ビル市場普及拡大に向けた課題の1つとして、デマンドレスポンス(DR)技術・標準の調査研究を掲げ、DR手法の詳細仕様の策定を加速するため、検討会内にデマンドレスポンスタスクフォース(DR-TF)を設置した。ここでは、我が国のDRのシナリオを整理して評価ユースケースにまとめ、米国OpenADRアライアンスが規定したOpenADR 2.0仕様がその評価ユースケースを実現するうえで支障がないことを確認し、OpenADRをベースとして、日本版DRインタフェース仕様を固めようとしている。
ここでは、国内のDRにも採用されつつあるOpenADR 2.0について、最新動向を紹介する。

なぜOpenADR 2.0なのか?

図1 OpenADR 2.0の中でのOpenADR 2.0プロファイルの位置づけ

図1  OpenADR 2.0の中でのOpenADR 2.0プロファイルの位置づけ

(注)四角がOASISで規定したもの、丸(楕円)はOpenADRアライアンスが規定したもの。
〔出所 インターテックリサーチ作成〕

2009年にOpen ADR(Open Automated Demend Response)1.0通信仕様が公開され、米国ばかりでなく欧州やアジア、オセアニアでもOpenADR 1.0ベースの実装が進みだしているなかで、なぜOpenADR 2.0なのだろうか?

OpenADR 2.0の位置づけは図1に示すが、主な特徴は次のような点が挙げられる。

(1)OpenADR 1.0は、カリフォルニア州でできあがったDRのローカル標準であるのに対して

(2)OpenADR 2.0のベースとなるEI(Energy Interoperation)1.0注1は、国際的な標準策定機関であるOASISが策定したものである。

(3)OpenADR 1.0と異なり、認証制度ができあがり、他社メーカーのDRサーバ/DRクライアントの組み合わせによる相互運用性が担保される。

(4)すでに国際標準としてIECで定義されているCIM(Common Information Model)でも、DRに関連するデータを規定しているが、OASYSのEI1.0同様(それ以上に)、DRはその規定の中のほんの一部に過ぎず、CIMの規格に従ってDRサーバやDRクライアントを別会社が開発した場合、相互運用性が満たされる保証がない。注2

OpenADR 2.0がサポートするプロファイルとその機能

OpenADRアライアンスは、EI1.0をベースとしてOpenADR 2.0の仕様を開発するにあたって、当初は機能範囲を限定し、相互運用性を確保しながら段階的にサポート機能範囲を増やしていくアプローチを採用し、次の3つの機能セット(プロファイル)を定義した。

(1)Aプロファイル:系統の需給逼迫度を4段階表示でDRイベントとして通知し、スマートサーモスタットのような装置が系統逼迫度に応じて動作できるようにする。

(2)Bプロファイル:多種類のDRプログラムのDRイベントに対応し、HEMS/BEMSなど、高度な仕様を実装したシステムへのDRイベント通信を可能とする。

(3)Cプロファイル:系統運用機関や電力会社とDRアグリゲータ間のDRイベント通知や電力取引所への適用を想定。

図2に、これら3つのプロファイルの用途の違いを示す。

図2 OpenADR 2.0の3プロファイルの用途の違い

図2  OpenADR 2.0の3プロファイルの用途の違い

ただし、2013年3月18日に公開された「OpenADR 2.0 Profile Specification B Profile」の最終案では、Cプロファイルの機能範囲は将来定義するものとして、表1の通り機能定義表から削除されている。

表1 AプロファイルとBプロファイルの機能範囲

表1  AプロファイルとBプロファイルの機能範囲

本来OASISは、EI 1.0で11のEiサービスを定義しているが、OpenADRアライアンスでは、そのうち4つのEiサービス(プロファイルAではEiEventサービスのみ)をOpenADR 2.0仕様に採用している。すなわち、

(1)DRイベントの登録・発動・変更・抹消等を行うEiEventサービス

(2)DRクライアント側がDRイベント発動に対してDR資源を提供する(Opt-Inと呼ばれる)か、提供しない(Opt-Outと呼ばれる)かというOpt情報を作成・抹消するEiOptサービス

(3)計測結果やヒストリーデータ等を一度または定期的に報告するためのEiReportサービス

(4)DRクライアントがDRサーバに対して自分を登録・抹消するEiRegister Partyサービス

プロファイルAの機能概要

表1を見ればわかるように、プロファイルAでは、EiEventでかつ、DRプログラムとしては系統の需給ひっ迫度を伝えるDRイベントしか支援せず、他の3つのEiサービスは支援していない。また、表中トランスポートプロトコルとなっているが、OSI参照モデル上アプリケーション層プロトコルとして、プロファイルAでは、HTTP注3プロトコルのサポートを必須、XMPP注4プロトコルはオプションとしている。

なおセキュリティ機能に関しては、TLSを用いた標準レベルのみが許されている。

プロファイルBの機能概要

プロファイルAでのシンプルなDRイベントだけでなく、さまざまなDRプログラムに対応するEiEventサービスをはじめ、他の3つのEiサービスもフルサポートが必須となっている。なお、スマートメーターのように、負荷削減は行わない装置(Report Onlyデバイス)に関しては、EiReportとEiRegisterPartyサービスのみが適用される。

また、アプリケーション層プロトコルとして、DRサーバではHTTP、XMPP両プロトコルのサポートが必須、DRクライアントではどちらか1つあるいは両方を利用してよく、XMPPプロトコルはオプションとしている。

セキュリティ機能に関しては、DRサーバ、DRクライアントとも、TLS注5を用いた標準レベルの支援が必須で、それに加えてXML署名による否認防止が可能なハイレベルをオプションとしている。


▼ 注1
EI1.0:OASIS(オープン標準の開発・統合・採用を推進する国際コンソーシアム)のEI技術委員会が、電力価格情報や系統の安定度に関する情報授受の標準として作成。EI1.0を構成するサービスの中で、OpenADRを実現するための機能セットとしてOpenADR Profile を定義している。

▼ 注2
EI 1.0の仕様書を見ただけでは、そこに規定されたサービスを用いてどのようにDRを実現するシステム設計をすればよいか見当がつかない。OpenADR 2.0は、EI 1.0で規定されたサービスの内容や使い方を、DRを実施するうえで必要最小限に絞り込んだものということができる。CIMをベースとしてDRを実装するには、同様に、もう一段ブレークダウンした規格策定が必要(例えばOpenCIMというようなもの)。ただ、それならば、OpenADR 2.0の中でCIM対応を図るほうがよいと筆者は考えている。

▼ 注3
HTTP:HyperText Transfer Protocol。WWWブラウザとWebサーバ間でHTML(HyperText Markup Language)などのコンテンツのやり取りする際に用いられる通信プロトコル。

▼ 注4
XMPP:EXtensible Messaging and Presence Protocol。インスタントメッセージソフト「Jabber」(Jabber社が開発)のプロトコルを、セキュリティ機能などを追加して改良された、XMLベースのオープンソースプロトコル。

▼ 注5
TLS:Transport Layer Security。情報を暗号化してインターネット上で送受信するプロトコルのひとつ。

ページ

関連記事
新刊情報
5G NR(新無線方式)と5Gコアを徹底解説! 本書は2018年9月に出版された『5G教科書』の続編です。5G NR(新無線方式)や5GC(コア・ネットワーク)などの5G技術とネットワークの進化、5...
攻撃者視点によるハッキング体験! 本書は、IoT機器の開発者や品質保証の担当者が、攻撃者の視点に立ってセキュリティ検証を実践するための手法を、事例とともに詳細に解説したものです。実際のサンプル機器に...
本書は、ブロックチェーン技術の電力・エネルギー分野での応用に焦点を当て、その基本的な概念から、世界と日本の応用事例(実証も含む)、法規制や標準化、ビジネスモデルまで、他書では解説されていないアプリケー...