OpenADR2.0－その３

© Copyright Malc McDonald and licensed for reuse under this Creative Commons Licence.

OpenADR2.0というタイトルですが、OpenADR1.0に立ち戻って、デマンドレスポンスとは何かを、今までより深堀りしようとしています。

前回は、「OpenADR1.0のおさらい－前編」として、OpenADR1.0のスコープを確認した後、OpenADRのアーキテクチャーとその論理コンポーネントを確認、更に、自動DRばかりでなく、（米国で）デマンドレスポンスビジネスを行う上でのビジネスフローの概要をご紹介しました。
DRシグナル、DRイベント、DRプログラムがどのようなものか、まず例を示すことで、米国で行われているデマンドレスポンスがどのようなものか、少し身近に感じていただけたでしょうか？
今回は、OpenADR1.0でのDRイベントのデータ構造と使われ方を見ていきたいと思います。

今回ご紹介する内容も、「OpenADR1.0システム要求仕様書：OpenADR 1.0 System Requirements Specification」（全63ページ）、「OpenADR1.0の機能仕様及びユースケース：OpenADR Functional Requirements and Use Case Document　Version1.0」（全53ページ）等からの抜粋ですが、いつも通り、場合によっては、個人的な解釈を含めた超訳になっていることをご承知おきください。

では、はじめます。

　OpenADRに関連するビジネスロール

前回OpenADRに関連する５つの論理コンポーネントを洗い出しているが、ここではOpenADRのデータ・アーキテクチャーを理解するに当たって、OpenADRに関連する役割（Business Role）と実際のアクターの関係を整理しておく。

•  DR設備（DR Asset）：負荷削減を行う。DRイベント（電力価格シグナル、アンシラリーサービス価格シグナルや、電力周波数低下等の系統異常を示すイベント）に応じて負荷の削減や制御が可能なエアコンなどの末端設備。

•  DR資源（DR Resource）：DR設備と同じく負荷削減を行う。DR資源同様、DRイベントに応じて負荷の削減や制御が可能な設備の集合で、例えば、マンションに属する個々の家庭のDR設備を束ねた、マンション単位でのDR資源や、家電機器、太陽光パネル、蓄電池をまとめた同一家庭内のDR資源がある。

•  消費者（Electricity Consumer）：電気を消費する。一般家庭だけでなく、商業ビル顧客や産業顧客を含む。また、電気を使うだけでなく、発電、蓄電していたり、エネルギー利用の管理を行っていたりする場合がある。

•  DRアグリゲーター（DR Aggregator）：消費者の電力負荷削減量を集約する。ARC（Aggregator of Retail Customers）とか、DRP（Demand Response provides）と呼ばれることもある。

•  電力小売事業者LSE（Load Serving Entity）：消費者に電気を提供する。LDC（Local distribution companies）、UDC（Utility Distribution Company）と呼ばれることもある。LSE自体がDRアグリゲーターの役割を兼ねていることもある。

•  ESP（Energy Service Provider）：市場やLDC/UDCへの電力供給の調整を行う。 CSP（Curtailment Service Providers）と呼ばれるESPは、DRアグリゲーターの役割を担っている。

•  系統・市場運用者（System and Market Operator）：需要予測を行い、事前通知（Advance Notification）を含めたDRイベントの発動・解除を行う。市場運用者は、電力取引市場運営を通じて電力価格を決定する。米国では、ISO　New EnglandやPJM等、両方の役割を兼ねた、正にSystem and Market Operatorが存在する。

•  DR制御エンティティ（DR Controlling Entity）：DR資源を管理する。系統・市場運用者、電力小売り事業者、DRアグリゲーターがこれに当たる。

•  仮想終端ノードVEN（Virtual End Node）：DR制御エンティティからDRシグナルを受け、需要削減を行う。DR制御エンティティである系統・市場運用者からDRシグナルを受ける電力会社、電力会社からDRシグナルを受けるDRアグリゲーター、DRアグリゲーターからDRシグナルを受ける消費者（のDR設備）はVENに相当する。

DR資源管理者REC（Resource Energy Controller）から見たDR制御エンティティとVENの関係を図示すると、図．１のようになる。

出典：OpenADR 1.0 System Requirements Specification

図．１　DR制御エンティティとVENのリカーシブ構造

　OpenADRのデータ・アーキテクチャー

以下に、OpenADRのユースケースを検討して洗い出されたOpenADR関連のデータオブジェクトと、それらのオブジェクトが提供するサービスを示す。

• DR顧客オブジェクト：DR Customer Enrollment

1) DRプログラムに参加する顧客の登録：Register Customer for DR Program
2) DRプログラムに参加する顧客情報の更新：Update Customer for DR Program
3) DRプログラムに参加する顧客の登録抹消：Remove Customer from DR Program

• DR設備（末端機器）オブジェクト：DR Asset (End Device)

1) DRプログラムに参加するDR設備の登録：Register Asset for DR Program
2) DRプログラムに参加するDR設備情報の更新：Update Asset for DR Program
3) DRプログラムに参加するDR設備の登録抹消：Remove Asset from DR Program

• DR資源オブジェクト：DR Resource (Device Group)

1) DRプログラムに参加するDR資源の登録：Register Resource for DR Program
2) DRプログラムに参加するDR資源情報の更新：Update Resource for DR Program
3) DRプログラムに参加するDR資源の登録抹消：Remove Resource from DR Program

• 事前通知型DRイベントオブジェクト：Notify Demand Response Event

1) DRイベントの事前通知：Advance Notification
2) DRイベントの事前通知情報の更新：Update Event
3) 事前通知したDRイベントの登録抹消：Cancel Event

• DRイベントオブジェクト：Demand Response Event

1) DRイベントタイプ：Types別に：

・直接負荷制御指令：Direct Load Control Signal
・指名制負荷削減指令：Demand Response Instructions / Objectives (DR Dispatch)
・価格情報メッセージ：Price Signal / Schedule

2) DRイベント情報の更新：Updates
3) DRイベントの登録抹消キャンセル：Cancel

• 需要予測オブジェクト（対象外）：Forecast Demand (out of scope)

• DR設備・DR資源状況オブジェクト：Asset / Resource Status (Monitor Demand Response Event)

1) DRシグナルへの応答：Response to Signal
2) 状況把握：Get Status/State
3) 継続応答：Continuous Response

以下に、これらのOpenADR関連オブジェクトのデータ要件を表で示す。

なお、OpenADR 1.0 System Requirements Specificationには、この表以外に特に説明はないが、表の内容に関して気づいたことを合わせて記載する。

　DRイベントオブジェクトのデータ要件と使われ方

DRイベントオブジェクトのデータ要件

一般家庭向け（Residential）と大口需要家向け（Wholesale）では、DRイベントの内容が異なる。また、DRイベントタイプ（直接負荷制御指令か、指名制負荷削減指令か、価格情報メッセージか）によってもDRイベントのデータ要件は異なる。
表．１では、まずDRイベントとして共通のデータ要件を示し、続いて、個別の場合のデータ要件を記述する。
※　なお、この表は、UCAIug－OpenSG－OpenADRタスクフォースでまとめられたものだが、表中「OpenADR1.0通信仕様との対応」欄には、デマンドレスポンス研究所とAkuacomが、カリフォルニア州で実施されてきたデマンドレスポンスの通信仕様をまとめた「OPEN AUTOMATED DEMAND RESPONSE COMMUNICATIONS SPECIFICATION (Version 1.0)」で対応するデータ項目名が記載されている。

表．１　DRイベントオブジェクトのデータ要件

出典：OpenADR 1.0 System Requirements Specification　　
表の拡大

• 共通データ項目部分を見ると、一般家庭向けと大口需要家向けでDRイベントの情報が異なることが確認できる。

• OpenADR1.0／SEP2.0では、CriticalityLevelというデータ項目が定義されており、１～9の系統の緊急度が指定される。１は正常、2から6に数字が大きくなるほど系統電力の逼迫度が高くなり、7は緊急通告、8は計画停電通知、9は供給切断通知を意味し、このデータ項目の値が7、8または9のDRイベントを受領した場合必ず対応しなければならない（Mandatory）とされている。

• 価格情報DRメッセージ（Price Plus Information Dispatches）に関して、DR Dispatch Typeデータ項目によって、その値が絶対値（PRICE_ABSOLUTE）か、ベースとなる料金表からの相対値（PRICE_RELATIVE）か、あるいは、現在価格の何倍に跳ね上がるかを示す数値（PRICE_MULTIPLE）か使い分けられることがわかる。
また、価格情報の有効時間区分（Price Plus Information Intervals）情報に関しては、米国以外でのDR利用を想定して通貨記号データ項目（Currency）が、また、一般家庭向けと大口需要家向けでのデータ項目共通化を意識してkWhやMWhその他を指定できる電力計測単位のデータ項目（Unit-of-Measure）が用意されているなど、OpenADR1.0では、国際標準に向けてのデータ項目整備が行われていることがわかる。

•指名制負荷削減指令（DR Objective Dispatches）では、3種類タイプがあり、DR Dispatch Typeデータ項目の内容が、

・LOAD_LEVELの場合、Load Level Valueデータ項目にDRとして対応すべき負荷レベル（moderate、high等のように、具体的な数値ではなくレベル）が指定される。対象は一般家庭向けDR。
・LOAD_AMOUNTの場合、Load Amount Valueデータ項目に、負荷削減量がkW単位で指定される。大口需要家向けDRでは、アンシラリーサービスにも適用される。
・LOAD_PERCENTAGEの場合、Load Percent Valueデータ項目に、増減すべき負荷のパーセンテージが指定される。

• 直接負荷制御指令（Direct Load Control Dispatches）は、一般家庭向けDRのみに適用され、指定された時間区分（Direct Load Control Intervals）ごとに、直接負荷制御指令のタイプ（例えば、Set Point、Open/Close、Heating Temperature -offset/setpoint、Cooling Temperature -offset/setpoint、Load adjustment offset）と、そのタイプに応じた直接負荷制御の数値を保持するデータ項目Direct Load Control Valueが用意されている。
面白いのは、Event controlというデータ項目で、その値が１の場合、イベント開始時間、終了時間をランダムにする（Randomize Start time／End time）。これは、すべての直接負荷制御対応機器が同じ時間に一斉にDRイベントに反応することによる系統への悪影響を防ぐための考慮と思われる。

• Device Classデータ項目は、SEP2.0で採用されていた仕様をOpenADR1.0に取り入れたもののようで、表．１にあるようにデフォルトのエアコン（HVAC）を含めて１２種類の装置クラスが、DR対象機器クラスとして定義されている。

価格情報メッセージ（Price Plus Information）タイプのDRイベントオブジェクトの使われ方

DRプログラムにはいろいろな種類があるが、価格情報メッセージタイプのDRイベントは、系統電力の逼迫度に応じて電力価格を上下させ、その電力価格情報をDRメッセージとしてブロードキャストすることで、需要抑制に任意で協力してもらうためのものである。したがって、消費者（のDR資源）は、需要削減に協力する場合も拒否する場合も、このDRメッセージに対して応答する必要はない。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．２　価格情報DRメッセージのシーケンス図

 指名制負荷削減指令（DR Objective Dispatches）タイプのDRイベントオブジェクトの使われ方

あるDRイベントの時間帯に特定の電力削減（例えば100kW削減）が必要な場合、DR制御エンティティが特定のDR資源に対して発行する指令が指名制負荷削減指令である。この指令に対してDR資源はDR設備・DR資源状況オブジェクトを返す。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．３　指名制負荷削減指令のシーケンス図

 直接負荷制御指令（DR Objective Dispatches）タイプのDRイベントオブジェクトの使われ方

あるDRイベントの時間帯に特定のDR設備の負荷を直接制御（例えば電源のon/off）が必要な場合に、DR制御エンティティがDR設備に対して発行する指令が直接負荷制御指令である。この指令に対してDR設備はDR設備・DR資源状況オブジェクトを返す。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．４　直接負荷制御指令のシーケンス図

　事前通知型DRイベントオブジェクトのデータ要件と使われ方

 事前通知型DRイベントオブジェクトのデータ要件

事前通知型のDRとは、系統運用者が需要予測により系統電力逼迫が懸念されたり、送配電線の混雑や発電機の計画停止等事前に系統への影響が予想される場合、当該地域の需要抑制の目的で１日前あるいは時間前にDRイベント通知を行うものである。事前通知型DRオブジェクトは基本的にDRイベントオブジェクトと同じデータ項目を持っている。表．２には、それ以外の事前通知型DRイベントオブジェクト固有のデータ要件が示されている。

表．２　事前通知型DRイベントオブジェクトのデータ要件

出典：OpenADR 1.0 System Requirements Specification
表の拡大

 事前通知型DRイベントオブジェクトの使われ方

以下に、DRイベントの事前通知、更新、キャンセルの流れを示す。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．５　DRイベントの事前通知のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．６　事前通知したDRイベント情報更新のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．７　事前通知したDRイベント情報キャンセルのシーケンス図

　DR設備・DR資源状況オブジェクトのデータ要件

DRイベントまたは事前通知型DRイベントの受信に対して、DR資源オブジェクトからDR制御エンティティに返されるのがDR設備・DR資源状況オブジェクトである。
これは、DRシグナル受信への応答として使用され、DR資源オブジェクトがDRイベント通知に対してどのように応答しようとしているかの情報が含まれる。

表．３　DR設備・DR資源状況オブジェクトのデータ要件

出典：OpenADR 1.0 System Requirements Specification
表の拡大

• DRイベントの指示に応えられない場合、その理由がException Conditionsデータ項目にFaults in deviceやCustomer overrideとして返される。

• DRイベントに従える場合も従えない場合も、Load Control Stateデータ項目に、結果としてどのような負荷状況になる予定かが返されるようである。

• 消費者がOpt outしている場合も、①当該DRプログラムに関して全てOpt outか、②特定の時間帯のすべてのDRイベントに関するOpt outか、③当該DRイベントのみのOpt outかが、Opt in/outデータ項目に指定される。

　DR資源オブジェクトのデータ要件と使われ方

 DR資源オブジェクトのデータ要件

DR資源オブジェクトのデータ要件を下表に示す。

表．４　DR資源オブジェクトのデータ要件

出典：OpenADR 1.0 System Requirements Specification
表の拡大

•  DR Resource Enrollment Transaction Typeデータ項目に、新規登録（REGISTRATION）か、更新（CHANGE）か、登録抹消（RETIREMENT）が指定される。

•  Resource Typeデータ項目には、DR資源のタイプとして負荷削減タイプ（load reduction）か、太陽光発電などの分散電源（generation）か、その組み合わせ（combination）かが指定される。

•  DR Program Identifierデータ項目には、どのDRプログラムに参加するかが指定される。

•  DR Resource Operational Constraintsデータ項目には、DRイベント中の当該DR資源の運用上の制約（①Minimum load、②Maximum load、③Maximum-Duration、④Minimum-Duration等）が指定される。

•  DR Resource Schedule Constraintsデータ項目には、いつ当該DR資源が利用可能か（①Time of day schedule constraints、②Black out dates、③Maximum consecutive days of participation、④Maximum duration of DR event participation、⑤Minimum duration of DR event participation、⑥Max number of times per day the DR Resource may be called、⑦Minimum advanced notification necessary　等）が指定される。

 DR資源オブジェクトの使われ方

以下に、DR資源の登録、更新、登録抹消の流れを示す。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．８　DR資源登録のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．９　DR資源更新のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１０　DR資源登録抹消のシーケンス図

　DR設備オブジェクトのデータ要件と使われ方

 DR設備オブジェクトのデータ要件

DR設備オブジェクトのデータ要件を下表に示す。

表．５　DR設備オブジェクトのデータ要件

出典：OpenADR 1.0 System Requirements Specification
表の拡大

• DR Asset Enrollment Transaction Typeデータ項目に、新規登録（REGISTRATION）か、更新（CHANGE）か、登録抹消（RETIREMENT）が指定される。

• DR Resourcesデータ項目には、当該DR設備が所属しているDR資源が指定される。

• DR Asset Physical Capabilitiesデータ項目には、起動・停止速度（Ramp Up/Down Rate）や、最大負荷削減可能量（Maximum Capacity）が指定される。

• DR Asset Typeデータ項目には、そのDR設備のタイプ（DG, renewable, storage, curtailable or interruptible load）が指定される。

 DR設備オブジェクトの使われ方

以下に、DR設備の登録、更新、登録抹消の流れを示す。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１１　DR設備登録のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１２　DR設備更新のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１３　DR設備登録抹消のシーケンス図

　DR顧客オブジェクトのデータ要件と使われ方

 DR顧客オブジェクトのデータ要件

DR顧客オブジェクトのデータ要件を下表に示す。

表．６　DR顧客オブジェクトのデータ要件

出典：OpenADR 1.0 System Requirements Specification
表の拡大

 DR顧客オブジェクトの使われ方

以下に、あるDRプログラムへDR顧客を登録、更新、登録抹消する場合の流れを示す。

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１４　あるDRプログラムへのDR顧客登録のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１５　あるDRプログラムへ登録したDR顧客情報更新のシーケンス図

出典：OpenADR Functional Requirements and Use Case Document　Version1.0
図の拡大

図．１６　あるDRプログラムへ登録したDR顧客情報抹消のシーケンス図

以上、長くなりましたが、今回は「OpenADR1.0のおさらい－後編」として、OpenADRの主要なオブジェクトのデータ要件と使われ方をご紹介しました。

スマートグリッドに関連してデマンドレスポンスが語られる場合、一般家庭向けの価格情報メッセージをDRシグナルとするデマンドレスポンスを指すことが多く、今回上記で確認した通り、このタイプのDRは強制力がないので、消費者側は需要削減に協力しても協力しなくても良い。直接負荷制御指令か指名制負荷削減指令のタイプのDRでなければ、負荷削減を確実に行えないということが確認できました。

弊社ブログ「DRアグリーゲーション・ビジネスに暗雲か」の後書きで、米国電力中央研究所EPRIが実施した「DRプログラム及び需要家タイプ別ピーク抑制可能電力量比較グラフ：Reported potential peak load reduction by type of program and by customer class」を掲載させていただいていますが、そのグラフで、米国においても、一般家庭向けの価格情報メッセージをDRシグナルとしたDRによる需要削減可能量が非常に少ないことが確認できると思います。
日本でデマンドレスポンスを導入するに当たって、参考にしていただきたいと思います。

なお、３種類のDRイベントタイプについては、そもそも、「OpenADR1.0システム要求仕様書（SRS）」と「OpenADR1.0の機能仕様及びユースケース（FRU）」で表現が異なっていました（下記、青字と緑字）ので、今回、内容から考えてネーミングしたのですが、もっと適切な日本語訳がありましたらコメントでお寄せください。

1) 直接負荷制御指令　（これは、両方同じ）

SRS：Direct Load Control
FRU：Direct Load Control

2) 指名制負荷削減指令

SRS：Demand Response Instructions / Objectives (DR Dispatch)
FRU：Dispatch DR Instructions

3) 価格情報メッセージ

SRS：Price Signal / Schedule
FRU：DR Message (Price Plus)

終わり