なぜ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プロファイルの用途の違い
ただし、2013年3月18日に公開された「OpenADR 2.0 Profile Specification B Profile」の最終案では、Cプロファイルの機能範囲は将来定義するものとして、表1の通り機能定義表から削除されている。
表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。情報を暗号化してインターネット上で送受信するプロトコルのひとつ。
