OpenADR2.0－その４

© Copyright Oast House Archive and licensed for reuse under this Creative Commons Licence.

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

前回は、「OpenADR1.0のおさらい－後編」として、OpenADR1.0でのDRに関連するオブジェクトのデータ要件と使われ方をご紹介しました。
「OpenADR2.0 － その２」の「デマンドレスポンスビジネスの基本的な流れ」の図と照らし合わせると、「1.0：DRプログラム管理：Administrate DR Program」および「5.0：DRイベント後の管理：Post DR　Event Management」に関連するデータ構造とユースケースの説明が見当たりませんが、「OpenADR1.0システム要求仕様書：OpenADR 1.0 System Requirements Specification（SRSと略）」の「1.2　Scope」に、以下のような断り書きがありました。

Furthermore this SRS does not cover many of the administrative aspects of managing a DR program such as measurement and verification and settlement. The SRS is focused on only those aspects of DR management that is required to facilitate the exchange of DR signals with their customers.

また、DRイベントを起動するかどうかを判断するためには、事前に系統運用状況がどうなるか需要予測を行う必要がありますが、その部分もOpenADRの対象外とされていることは、前回の「OpenADRのデータ・アーキテクチャー」で「 需要予測オブジェクト（対象外）：Forecast Demand (out of scope)」となっていたことを思い出していただければと思います。

ということで、OpenADR1.0 SRSに関して主な部分はカバーできたと思ったのですが、「OpenADR1.0の機能仕様及びユースケース：OpenADR 1.0 System Requirements Specification」（FRUと略）に関していうと、まだカバーしきれていません。

FRUには、DRプログラムのユースケース（①Create DR Program、②Update DR Program、③Remove DR Program）が記載されており、「The items that　should be considered include, but are not limited to」という控えめな表現でDRプログラムの大まかなデータ構造も規定されていますが、自動DRとしてM2Mインタフェースで取り扱われる部分ではないので、上記のSRSの考え（英文部分）に従い、今回は取り扱いませんでした。興味のある方は、FRUの「4. Administrate DR Program」をご覧ください。FRUの「8. Post DR Event Management」も、同様の理由で、割愛させていただいています。

ただ、FRUの「4.8 DR Event Execution」の部分は、自動DRの一番肝心な部分ですので、これをご紹介しない訳にはいきません。

SRSでDRイベントオブジェクト及び事前通知型DRイベントオブジェクトのデータ要件と、それらのオブジェクトの使われ方（Register/Notify、Update、Cancel）まではカバーしましたので、今回は、「OpenADR1.0のおさらい－後編の補足」というか、むしろ、「OpenADR1.0のおさらい－本編」ということで、「DRイベントの実行：Execute DR　Event」のユースケースに関してご紹介したいと思います。

いつも通り（というか、FRUの「4.8 DR Event Execution」の部分は直訳しただけではわかりづらいので、いつも以上に個人的な解釈を付加した）超訳になっていることをご承知おきください。

では、はじめます。

　DRイベントの実行

今後、DRが広く普及した場合、注意しなければならないことがある。
それは、DRが従来の電力供給計画プロセスに及ぼす影響についてである。DRによる需要削減可能量が、発電設備容量に対して無視できない規模になると、DRによる需要削減量が送配電系統の運用・信頼性維持に大きく影響を及ぼす可能性があるからである。したがって、DRのユースケースやDRシグナルの標準を開発するに当たっては、系統レベルで運用上何が必要となるかを考慮しなければならない。DRがそれほど広く普及していない段階では系統への影響は無視できるが、ここでは、将来DRが広く普及した場合を想定して、スケーラビリティや拡張性を考慮したユースケースを検討した。

よく言われることだが、今日の技術では、まだ大量の電力を保存するのは難しいので、電力系統は、瞬時、瞬時に電力需給バランスをとる必要がある。そして、経済的に電力供給バランスをとるためには、正確な需要予測が不可欠である。

これまでは、従来の消費パターンと天気予報その他の情報を基にして、需要予測が行われてきた。しかし、DRが広く普及するようになると、需要予測のパラメーターとして、あらかじめ計画されたDRレベルの掌握、あるいはDRレベル自体の予測が必要となる。

例えば、従来の需要予測に基づいた翌日の電力需要予測値が、あらかじめ把握している電力供給計画を大幅に上回ることが分かったとする。そのままにしておくと系統に悪影響が出るので、系統運用者は、ピーク需要削減のためのDRイベントを発動することを決定し、CPP（Critical Peak Pricing）として、通常のピーク時間帯の電力価格の10倍の価格とすることをアナウンスしたとする。その結果、予想以上の消費者が“デマンドに対してレスポンス”してピーク時間帯の電力利用を控えたため、系統運用者はCPP当日の当該時間帯、発電計画通りフル運転で電力供給を行っていた発電機に稼働停止の指示を出さなければならなかった－というような事態が起こり得るからである。

また、OpenADR2.0では、需要削減だけでなく、系統に不測の事態・緊急事態が発生した場合に備えて待機する発電機相当の、アンシラリー・サービスにも利用されることが想定されている。

例えば、大型発電機の故障で電力供給が急に落ち込んだり、将来電気自動車が普及して夜間大挙して充電を開始したため特定地域の配電系統のトランスに過負荷がかかったりした場合への対応である。このようなアンシラリー・サービスとしてのDRをうまく機能させるには、DRの適切なスケジューリング／モニタリングが不可欠となる。

更に、DRイベントが発動された結果、特定地点で配電線の混雑が発生し、系統に悪影響を与えるといった事態にならないような考慮も必要となるだろう。

以下では、3つの代表的な自動DR実行のユースケースを取り上げる。

１）事前通知型DR（Slow-DR）の実行
２）リアルタイムDR（Real-Time DR）の実行
３）高速DR（Fast-DR）の実行

その前に、電力系統に対するこれらのDRの位置づけを下図で確認しておこう。

出典：BONVILLE POWER ADMINISTRATION －Demand Response in the Pacific Northwest

図．１　電力系統における各種DRの位置づけ

　事前通知型DR（Slow-DR）の実行

事前通知型DRは、1日前あるいは1時間前の情報に基づいて経済的な電力需給バランスを実施するために行われるものがほとんどだが、系統運用者が、送配電網の混雑や発電機の計画停止に備えて需要を削減したいような場合にも用いられる。現時点では、DRのビジネスプロセスは標準化されていないので、以下に示すものは、事前通知型DRの実行に関連する、主要アクター間の典型的なインタラクション例である。
なお、このタイプのDRは、Slow-DRと呼ばれることもある。

冒頭で述べたように、DRが広く普及した暁には、一日前DR（Day-Ahead DR）や時間前DR（Hour-Ahead DR）は、系統運用・供給計画策定プロセスとのコーディネーションが不可欠である。

そこで、事前通知型DRの実行の前準備として、以下が行われる。

•  電力小売事業者（LSE）は、自社の顧客の翌日／1時間後の需要予測（Load Forecast）を行い、系統・市場運用者に報告するとともに、配電事業者（UDC）に対しては、配電線ごとの需要予測（Load Forecast By Circuit）情報を提供する

•  DRプロバイダーは、地点別に最新のDR実施可能先の候補と需要削減可能量を把握し、系統・市場運用者（SMO）に通知する。

•  一方、消費者は、あらかじめどの程度DRでの需要削減に応じられるかDRプロバイダーに登録しておくとともに、需要削減可能量に変更があれば登録情報の更新を行う。

•  DRプロバイダーは、消費者のDRによる需要削減可能量を集約し、SMOおよびLSEに通知する。

以下は、それ以降の、典型的な一日前／時間前の事前通知型DRの実行のユースケースである。

•  最新のDR需要削減可能量情報（DR Nomination）と、同じく発電事業者の最新の供給計画を利用して、SMOは翌日／1時間後の総合的な需給計画を立て、発電事業者やDRプロバイダーに翌日／1時間後の発電指令／DR指令（Dispatch Instruction）を出す。
同じDR指令は、LSEに対しても出される。

•  DRプロバイダーは、SMOから受けたDR指令の実行が配電網の信頼度低下や電力品質低下（例えば、過度のインバランス、電圧異常、あるいは過負荷）を来さないか、UDCに問い合わせる（DR Schedule by Circuit）。

•  UDCは、それに対して配電系統に問題が生じないかどうか確認し、OKあるいはNG（と、DRスケジュールの変更提案）を返す。
LSEとUDCの両機能を併せ持つ垂直統合型の公益事業会社がDRのサービスを展開する場合、このプロセスはDRMS、DMS等の社内システム内で実施されるかもしれないが、新たなDRスケジューリング・アプリケーションで実施する場合も考えられる。

•  DRプロバイダーは、UDCの回答を受けて、SMOに最終的なDRスケジュール情報（Final DR Schedule）を報告するとともに、LSEに対しても同じ情報を提供する

•  これら一連のプロセスの後、DRプロバイダーは、消費者にDRイベントの事前通知を行う。

以上の事前通知型DR実行までの流れを図．２に示す。

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

図．２　事前通知型DRの実行

 

　リアルタイムDR（Real-Time DR）の実行

従来、電気料金としては、一律料金か、使用総量に応じた段階的な従量料金制、せいぜい、TOU（利用時間帯ごとに従量料金が異なる固定料金制）が採用されてきた程度である。これに対して、リアルタイム料金制：RTP（Real time or dynamic pricing）では、経済的なインセンティブで需要を制御するために電気料金が、30分あるいは１時間といった時間区分ごとに変化する。
この料金制を機能させるためには、時間で変動する電気料金に基づいて正確に料金計算をするためのインターバル・メータリング（時間区分ごとの電力使用量計測）が必要となるが、現在米国では、すでに多くの州で大口需要家向けにRTPが適用されており、今後、スマートメーターの普及により、全国的／全面的に採用される可能性もある。
現時点では、DRのビジネスプロセスは標準化されていないので、以下に示すものは、リアルタイムDRの実行に関連する、主要アクター間の典型的なインタラクション例である。

• エネルギーサービスプロバイダー（ESP）/LSEは、時間区分ごとのリアルタイム価格決定に当たって、市場運用者からアナウンスされる地点別限界価格LMP（Locational Marginal Price）をベースとして、地点ごとに独立した価格計算を行い、消費者に公開する。
なお、RTPには、配電線／サービス使用料や停電補償チャージ等（Aggregation and Distribution Uplift Addition）も含まれる。

• 更に、リアルタイムDRの実行に当たっては、系統運用上の考慮も重要である。例えば、LMP（RTP）の値が低い（すなわち電気代が安い）夜間、一斉に電気自動車への充電が行われると、配電線混雑が発生してしまう可能性がある。これでは、電力供給コストは最適化されたとしても、系統運用上問題である。そこで、ローカルな配電線混雑／過負荷軽減のため、地点ごと、時間帯ごとの混雑緩和価格（Congestion Relief Incentive Price）も消費者に公開し、混雑緩和を促すように考えられている。

以上を考慮したリアルタイムDR実行の流れを図．３に示す。

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

図．３　リアルタイムDRの実行

　高速DR（Fast-DR）の実行

高速DRは、系統の不測の事態・緊急事態への対応や、電力需給バランシング（アンシラリーサービス）で系統信頼性の確保に資するためのものである。
従来は（今も）、火力発電所（の部分負荷運転中の発電機や、起動してタービンは回転しているが発電はしない状況で待機中の発電機）や待機中の水力発電所で対応されていた。これらは運転予備力（Spinning Reserve）と呼ばれているが、火力発電の場合は、待機中もCO2が発生しており決して環境にやさしい方法ではなかった。DR資源がこのような火力発電所の代替となることができれば、より環境にやさしい対応策となる。ただし、系統の信頼性を確保するためには即時応答（例えば、5分以内に登録したKWだけ需要を削減する）が要求されるため、事実上、直接負荷制御DLC（Direct-Load Control）型DRでしか対応できない。
※DLC自体は、その他に、ピーク削減／ピークシフトを行うために、温水器をピーク時間帯以外で作動させるべく直接負荷制御を行う－というような使われ方もある。

以下では、まずDLC型DRのユースケースを考え、その後で、Fast-DRとしてDLCを実行するための前処理であるDR資源の入札（DR　Bidding）について紹介する。

なお、現時点では、DRのビジネスプロセスは標準化されていないので、以下に示すものは、DLC型DRを実行するに当たって、関連する主要アクター間の典型的なインタラクション例である。

• あらかじめ個々の消費者がどの程度需要削減できるかの情報が地点ごとに集約（DR capability Aggregated By Location）され、配電事業者（UDC）、電力小売事業者（LSE）や系統・市場運用者（SMO）に通知される。通知される内容（DR Capability）には、需要削減が行える地点情報だけでなく、直接負荷制御型DRイベントが起動されてからのDR応答時間（例えば、4秒以内、5分以内、30分以内等）ごとにDRで需要削減できる量が含まれている。
※このプロセスは、Fast-DRの実行に関しては、後述のDR資源入札プロセスで代替される

• 系統運用者（あるいは、送配電網運用者）が、DLC型DRを実行するため、DRプロバイダー宛てに指名制負荷削減指令（DR Dispatch Instruction）を出す。
リアルタイム市場運用者がアンシラリー・サービスのために指名制負荷削減指令を出したり、DRプロバイダーやLSEが需給バランスの経済性を考えて指名制負荷削減指令を出したりすることもある。

• DRプロバイダーは、配電線ごとの直接負荷制御スケジュール（DR Control Schedule by Circuit）をUDCに通告する。

• UDCは、それに対して配電系統に問題が生じないかどうか確認し、OKあるいはNG（実行内容変更案）を返す。
垂直統合した公益事業会社がDLC型DRサービスを展開する場合、このような調整は、社内のDRおよび配電管理システムの内で遂行されるかもしれない。

• DRプロバイダーは、UDCの回答を受けて、SMOに最終的なDRスケジュール情報（Final DR Schedule）を報告するとともに、消費者に対して直接負荷制御のための制御信号（Control Signal）を送付し、指令通り負荷制御が行われたかどうかを確認（Telemetry Data）する

• SMOは、DRプロバイダーが、最終DRスケジュール情報通りに負荷削減が行われたかどうかを確認（Aggregated DR Telemetry）する。

以上、DLC型DR実行までの流れを図．４に示す。

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

図．４　直接負荷制御型DRの実行

　DR資源の入札（DR Bidding）

• DR設備やDR資源の保持者は、登録したDR設備やDR資源をDR入札にかけることができる。

• DR入札プログラムの実施主体は、参加者（入札者）から入札情報を受け取る。

• 入札者が消費者の場合、入札先は、エネルギー小売業者（例えばLSEやESP）、DRアグリゲーター（例えばCSPやDRP）、あるいはパワーマーケター（卸売電力市場参加者）。入札者がDRアグリゲーターの場合、入札先は、LSEまたはパワーマーケターである。

• 入札者は、入札用のガイドラインに沿って、定められた時間内に入札を行う。

• 入札の選考基準はここでは定めないが、入札選考結果が入札者に知らされる。

• 小売DR入札プログラムの例として、以下がある:

・ 需要削減量としてのDR入札
・ 運転予備力としてのDR入札

•  また、系統運用者がDR入札によって市場調達しているものとしては、以下のようなものがある:

・ 設備容量
・ 一日前の電力
・ リアルタイム・インバランス電力
・ 運用予備力
・ レギュレーション（しわ取り）

• DRアグリゲーター等、小売DR入札の入札先は、小売DR入札されたものを集約して上記のような大口入札先に入札することがある。

• 小売りDR入札と系統運用者のDR入札プログラムの連携については、現在検討が進められているが、本要求仕様の対象外である。

以下に、DR資源入札の流れを示す。

出典：OpenADR Functional Requirements and Use Case Document Version1.0

図．５　供給側のDR入札

出典：OpenADR Functional Requirements and Use Case Document Version1.0

図．６　DR入札によるDR資源／設備調達

 

以上、今回は、「OpenADR1.0のおさらい－本編」をお届けしました。

3回にわたって、SRSおよびFRUの2つの仕様書をベースとして、これらの仕様書の記載順ではなく、なるべくデマンドレスポンスの仕組みが順序立ててわかるようにご紹介したつもりですが、ご理解いただけたでしょうか？

日本とステークホルダー（アクター）の構成が異なるので、日本でデマンドレスポンス（特に自動ADR）を導入するに当たっては、まず日本版のユースケースを検討していかなければなりません。その際、「将来DRが広く普及した場合を想定して、スケーラビリティや拡張性を考慮したユースケースを考案」するというFRUのアプローチが大事だと思います。

現在、電力会社が行っている需給計画策定のプロセスを含め、デマンドレスポンス（自動DR）の導入は系統運用を中心にいろいろなところに影響が出そうです。

例えば、事前通知型DRですが、これまでは、従来方式の前日の需要予測と発電計画のプロセスを踏襲してCPPなりRTPなりの価格を決定するだけだと思っていました。ところが、DRによる需要削減量が発電量に対して無視できない状況では、あまりDRが効きすぎると大型発電所がいくつも緊急停止したのと同じ状況になってしまうので、あらかじめDRによる需要削減量の把握・予測のプロセスが必要となるということです。

リアルタイムDRを日本で実現させる場合、LMPは誰が計算するのか？現在の9電力会社の管内を1つのLMPの計算粒度とするならば、日本卸電力取引所のスポット価格が一応の目安となりますが30分単位なので、本当のリアルタイムDRには使えません。また、沖縄以外を9つの「地点」としてLMP（地点別限界価格）を計算するのは、粒度として大まかすぎる気がします。

Fast-DRに至っては、現在の電力会社の系統運用部門、日本卸電力取引所、電力系統利用協議会や新電力（特定規模電気事業者）、更には今後出現するBEMSアグリゲーターを含めて、役割分担／運用ルールの見直しが必要だと思います。

なお、FRUは、OpenADR1.0　SRSと同時期に公開されたので、OpenADR1.0用のユースケースしかカバーされていないものと思っていましたが、OpenADR2.0の要件であるFast-DRまでカバーされていることがわかりました。

また、今回は、自動DR内容を理解していただくために、SRS、FRUの記載不足をいろいろ補足したのですが、「補足」ではなくて「蛇足」になっていないか、更に、自分の理解不足／誤解から誤った記述になっていないか懸念しています。
このブログをお読みくださっている専門家諸兄のご意見、ご指摘をいただければ幸いです。

終わり