© Copyright Colin Smith and licensed for reuse under this Creative Commons Licence.
前回まで、OpenADR1.0の要求仕様に立ち戻って、デマンドレスポンスとは何かを見てきました。
「OpenADR2.0－その１」でご紹介した通り、OpenADR2.0の要求仕様書は、実質的には、OpenADR1.0に対して、高速デマンドレスポンス（FastDR）と分散型電源（DG）のユースケースを加えたものとなっていました。
• OpenADR2.0ビジネス要件21件中10件（OADR BREV-1～OADR BREV-10）がPEVに関するものですが、ユースケースについては米国自動車技術者協会：SAEが作成したユースケースを言及するにとどめて具体的な内容は含まれていませんでした。
• セキュリティに関しては、ビジネス要件として1件（OADR BREV-18）が提示されていたのみで、「関連要求仕様とユースケースについては、SG-Securityチームと共同で検討・作成中」ということで、カバーされていませんでした。
PEVやセキュリティのユースケースも気になるところですが、OpenADRの標準化のその後の動きに戻りたいと思います。
さて、OpenADR2.0というのは、同じく「OpenADR2.0－その１」の冒頭でご紹介した通り、OASISが、2012年2月18日付けで公開した「Energy Interoperation Version 1.0」（以降、EI1.0と略）という、エネルギーの相互運用に関する標準の中で、「OpenADRプロファイル」として規定されています。そこで、今回は、「EI1.0 OpenADRプロファイル－前編」として、EI1.0から、OpenADRプロファイルを理解する上で必要となる道具立ての説明から入ります。
いつもの通り、全訳ではないことと、場合によっては個人的な解釈が含まれているかもしれないことをご承知おきください。なお、使用した図表で出典の記述のないものは、すべてEI1.0に記載されていたものです。また、文字の細かな図表は、図表名をクリックしていただくと、拡大表示するようにしてあります。
では、はじめます。
Energy Interoperation（EI）について
EI（エネルギー利用のための相互運用）は、周波数調整などのアンシラリーサービスや、卸売り電力取引を含めて、電力需給に係る２者間で、電力価格情報や系統の安定度に関する情報／緊急状態などの情報交換について、標準策定機関OASISが定めた標準である。
図．１ EI の通信対象者
EIで取り交わされる情報は、リアルタイム性が要求されるものが多く、市場ベースの需給バランシングなどに利用されることが想定されている。デマンドレスポンスによるピーク削減や、出力変動の大きな再生可能電源の増加に対して、分散電源／蓄電池による電力の過不足調整を行うなど、卸売り電力市場のみならず小売電力市場でもEIが必要とされている。
EIの標準策定に当たっては、時間及びインターバルに関する標準としてWS-Calendar、電力価格と電力取引のための商品定義としてEMIX （Energy Market Information eXchange）をベースとしている。
WS-Calendarは、スマートグリッド及び他のアプリケーション領域でのデータスケジューリング向けの正確で安全なデータ交換のニーズに対処するため、OASIS WS-Calendar 委員会が、IETF iCalendarモデル（RFC5545）とIMIP(RFC5546）、ITIP,CalDAVとの通信をもとに作ったもので、Webサービス向けのヒューマンスケジューリング基準を採用している。XML表現は，xCAL（The XML format for iCalendar）で指定される。
なお、EMIXも、OASIS（エネルギー市場情報交換委員会）が制定した標準である。
EIのアーキテクチャ
EI では、エネルギーの情報交換（以降、インタラクション）を行う2者以上の関係を、2者ごとに切り分けて考え、インタラクションを開始する側のアクターをVTN（Virtual Top Node）、受ける側をVEN（Virtual End Node）と呼ぶ。３者以上にわたってエネルギー情報交換を行う場合も、対する２者間でVTN/VENの関係を持つものと規定している。
図．２は、マルチ階層でDRが行われる場合のEI関係を表している。ここで、ラベルA、B、GおよびLの役割と考えうるアクター名を表．１に示す。
図．２ DRでのEI の通信対象者
表．１ 図．２のアクターA、B、GおよびLの役割と、考えられるアクター名
DRイベントに関連したインタラクションと、EIメッセージを提示すると、下図の通りである。
図．３ DRインタラクションの例
WS-CalendarとEMIX
EI標準は、同じくOASISが制定した2つの標準、WS-CalendarおよびEMIXをベースとしている。以下、この2つの標準について簡単に説明する。
WS-Calendarのコアセマンティクス
WS-Calendarを利用したスケジュール関連メッセージ形式
エネルギーをやり取りする典型的なEMIXのメッセージは、以下のような単位と量の組あわせである。
図．４ EMIXのメッセージ形式
一方、例えばピーク需要時間帯に、特定の時間間隔ごとの電力削減を要求する場合、WS-Calendarでは、例えば12時から5時まで、1時間ごとの負荷削減量を以下の形で指定する。
図．５ WS-Calendarのメッセージ形式
EMIXのコアセマンティクス
WS-Calendarを取り込んだEI メッセージ構造：Streams
図．６ WS-CalendarのGluonとシーケンスからなるStreamの構成
図．７ StreamBaseクラスのクラスダイアグラム
EI のセマンティクス
この節では、WS-CalendarとEMIX以外のEI で用いる用語を定義する。
EIのコアセマンティクス
EIの主要登場人物（Dramatis Personae）
表．５ EIで用いられる下位レベルの用語のセマンティクス定義
marketContext
EMIX（表．３）で定義した通り、marketContextは市場ルールや市場価格等を識別するURIである。
図．８ EIのMatketContextの構成
ここでは、EMIXで定義されたMarketContextをEI用に拡張したコンテキスト情報を定義している。
marketNameには人間が可読な形で市場名が入り、envelopeContentsには、その証明書データが入る。
「緊急度１」のような単純コンテキスト（simpleLevelContext）と、アプリケーションに依存したコンテキスト（applicationSpecificContext）で使われる用語について、以下で説明する。
表．７ アプリケーションに依存したコンテキストで用いられる用語の定義
イベントベースのインタラクション
DRイベントは、デマンドレスポンスを使用するために様式化されたVTNとVENの間で取り交わされるビジネス・インタラクションである。
DRイベントは、DR資源が任務を果たすに当たってのいくつかの期間、デッドラインと、その間の遷移からなる。VTNは、DRイベントを発生させるに当たって、その期間および適用可能性を指定する。ただし、DRプログラムの種類によっては、適用されない期間や、デッドラインが存在する。下図に、３種類のDRプログラムのDRシグナルを含むDRイベントの例と、DRイベントにおける期間／デッドラインの関連を示し、EI1.0でのDRイベントで用いられる用語を定義する。
図．１０ EIイベントの構成
ActivePeriod
Active Periodはイベントの全体スケジュールを記述するシーケンスである。Active PeriodはVcalendarタイプで、1つのシーケンスと（場合によっては）独自のプロパティを持つ。Active Periodのシーケンスは、一般にNotification（通知）、Ramp-up（起動）、 Active（作動）とRecovery（回復）からなる共通のインターバル・パターンで構成される。ただし、イベント情報の授受を行う両方のPartyが了解しているなら、Active Periodにはどのようなシーケンスも含むことができる。
シングル・イベントは同等のパフォーマンス特性で多くのVENにブロードキャストされる。もし全てのVENが一斉にそれに応えると、エネルギー消費のスパイク（あるいは突然の低下）を招き、配電システムに悪影響が出るが、WS-CalendarのToleranceプロパティを用いることで、回避可能である。
イベントシグナル
イベントシグナルは、イベントのスケジュールに関する詳細情報を伝えるものである。1つのDRイベントが異なるmarketContextの異なるDR資源に向けた多数のDRシグナルを含む場合がある。例えば、あるものは価格連動のDRシグナルで、1つは系統の緊急度レベルのDRシグナルといったケースである。ただし、すべてのイベントシグナルは、次図に示す共通形式を採っている。
図．１２ EIイベントシグナルの構成
他のStreamクラス同様、各イベントシグナルはスタート時間とToleranceを持っている（Toleranceについては、表．９参照） 各シグナルは、marketContextと、場合によってはtargetを含む。これらは、VENがどのシグナルに対応すべきかを認識するために使われる。人間が理解しやすいよう、signalNameも付加されている。signalTypeは、そのシグナルがどのような内容を保持しているかを示し、intervalに、当該シグナルタイプの情報が保持される。オプションのcurrentValueには、シグナル生成時点での現在値が保持される。
Opt-in／Opt-out
VENは、marketContextに登録することによって、そのmarketContextで与えられたスケジュールに関するイベントに応答することが可能となる。例えば、可用性スケジュール（Availability schedule）には単純なもの（終日、四六時中）と、複雑なもの（例えば、平日午後と、事前通知付きで週末を含むが、2週間に1回の木曜午前中は含まない）があるが、VENは、それらの可用性スケジュールに応じた場合、絶対そのスケジュールに合わせなければならないのではなく、DRに応じる期間をある程度変更可能である。
その際、実施されるOpt-in、Opt-outと呼ぶ操作に使われるのがOptである。Optの主要な情報は「Vavailability」で、簡単にいうと、Opt-inは、DRに応じる時間帯を増やし、Opt-outでDRに応じる時間帯を減らす。以下にOpt-in／Opt-outで用いられる用語の定義を示す。
表．１１ Opt-in／Opt-outで用いられる用語の定義
長くなりましたので、一旦ここまでとします。
今回は、EI1.0 の1章から5章の途中まで、EIの定義とアーキテクチャ、およびEIの基礎となる2つの標準WS-CalendarとEMIXを概説し、EIのセマンティクス（アクター、marketContext、イベントベースのインタラクション）をご紹介しました。
現時点で全てを消化しきれている訳ではないので、まずはEI1.0の内容をご紹介した後、OpenADRプロファイルについて考えてみたいと思います。
終わり
- 投稿タグ
- Demand Response, Smart Grid, Standard, スマートグリッド, デマンドレスポンス, 標準化
Pingback: OpenADR2.0－その６ | インターテックリサーチブログ