© Copyright Les Hull and licensed for reuse under this Creative Commons Licence

前回は、「OpenADR2.0ビジネス＆ユーザー要求仕様書：OpenADR2.0 Business and User　Requirements 1.0」をご紹介しました。
デマンドレスポンスの対象としてOpenADR2.0で追加された部分のみ。それも追加された4つのうち、下記の3つのビジネス要件とユースケース図だけしか規定されていませんでしたので、ご覧いただいた方は、これだけ？と思われたかもしれません。
• プラグインEV（PEV）
• 高速デマンドレスポンス（FastDR）
• 分散型電源（DG）
※ 4つ目のセキュリティは、要求仕様書中、「SG-Security（旧UtilSec）チームと共同で検討・作成し、この要求仕様書には含まれていない。」とされていたのですが、UCAIug-OpenSGのホームページでSG Security-WGのページを見ると「OpenADR Security Profile (Draft)」として、バージョン0.02が見つかりました。（2011年12月15日作成。　0.02という若いバージョン番号ですが、既に97ページあります）

また、前回のブログにあったユースケース、例えば「DRシグナル受領に対して、家庭内の電気の使用をローカル発電に切り替えて系統に対しての負荷削減に協力するか、系統電力を使い続けるためにOpt-outするかを示すユースケース」をご覧いただいた方は、OpenADRが、そのユースケース中どこまでの実装に対する標準を定義しようとしているのか疑問に思われたのではないでしょうか？

OpenADRは、電力会社またはISOと需要家の間でDRシグナルを授受するための通信データモデルである

と捉えていたのですが、上記のユースケースは、単なる通信データモデルではなく、太陽光パネルや蓄電池を備えたスマートハウスとして、日本でも検討されているようなエネルギー利用最適化モデルのユースケースになっていたので、OpenADRが標準として定義しようとしている機能範囲をもう一度確認しなくてはと思いました。

そのためには、OpenADR1.0に遡ってみなければなりません。

OpenADR2.0のベースとなるOpenADR1.0に関しては、弊社ブログ「デマンドレスポンス－その７　－OpenADRとスマート・インタフェース－」で、ごくごく簡単にご紹介しています。当時（2011年1月。もう1年半前になります）、日本ではOpenADRという言葉がそれほど出回っていなかったので、仕様書の中身をご紹介しても、あまり興味を持っていただけないのではないかと思い、手抜きをしたので、今回は、OpenADR2.0の標準規格であるEI1.0のご紹介に入る前に、OpenADR1.0の仕様を再確認しておこうと思います。

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

では、はじめます。

　OpenADR1.0システム要求仕様書（以降SRS）作成の目的

本SRSは、デマンドレスポンス（DR）の遂行に関連して、電力需給にかかわる系統運用者（ISO）、電力会社、DRアグリゲーター、エネルギーサービスプロバイダ（ESP）と需要家の間で取り交わされるDR関連情報の交換と、そのインタラクションの要件を明らかにするものである。具体的には、DRシグナルや、需要家施設内の分散電源の制御の標準化を目指している。

本SRSの要件は、顧客に対してDRシグナルを発行する側の視点で書かれている点が、顧客側の視点でまとめられたOpenHANやSEPと異なっているが、DRにかかわる情報交換を標準化する必要があるという点で、同じ認識に立っている。

　OpenADR1.0のスコープ

OpenADR1.0では、以下の機能領域を対象とする：
• 直接負荷制御シグナル
• 負荷プロファイルの変更シグナル
• DR関連価格シグナル
• B2G/H2Gにかかわる分散電源対応
• DRシグナルの利用に必要なDRプログラム管理

自動デマンドレスポンス（AutoDR）遂行に必要なネットワークや、ハードウェア基盤、運用、テスト方法論並びに内部処理のアーキテクチャーは本SRSの対象外である。

　OpenADRのアーキテクチャー

OpenADRが目指すオープンで相互運用可能なDRソリューションを開発するためのアーキテクチャーを下図に示す。

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

図．１　OpenADR SRS コンポーネントダイアグラム

DRは、ハードウェア、DR管理システム（DRMS）および、配電管理（DMS）や顧客情報管理（CIS）などの関連システム、データ管理アプリケーション（MDMS）から構成され、メーター、ゲートウェイその他の装置を備えた大口需要家（C&I Customer）のビルや一般家庭の需要家（Residential Customer）の家屋と、通信ネットワークを構成する。この図には表れていないが、第３者企業ESPのシステムとも連携している。
このOpenADRのアーキテクチャーでは、大口需要家は、いわゆるBEMS/HEMSが電力会社（やDRアグリゲーター等）とインタフェースしているが、一般家庭では、HEMSではなく、もっと簡易なESI（Energy Service Interface）と呼ばれる装置（具体的には、スマートサーモスタット等）が、屋外のネットワークとインタフェースするとともに、DRシグナルを受けて、宅内の機器を制御するよう想定されていることがわかる。

　OpenADRのビジネスアーキテクチャー

DRの遂行には様々なステークホルダーが関わってくるが、それぞれが持つビジネス機能で分類すると、以下の5つの論理コンポーネントに集約することができる。

１） 電力顧客：Electricity Consumer

一般家庭、商業／ビル、および産業顧客を含む。場合によっては、太陽光パネルのような発電装置や定置型蓄電池を保有する

２） DR制御エンティティ：DR Controlling Entity

DR資源を管理する役割を担う系統運用者（ISO/RTO）、電力会社（Distribution Company / Load Serving Entity）、DRアグリゲーター等

３） DR設備：AR Asset

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

４） DR資源：DR Resource

1つ以上のDR設備からなる、負荷削減・制御のまとまった単位。例えば、マンションに属する個々の家庭のDR設備を束ねた、マンション単位でのDR資源や、家電機器、太陽光パネル、蓄電池をまとめた同一家庭内のDR資源

５） 系統・市場運用者：System and Market Operator

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

これら5つの論理コンポーネントによる情報交換の関連図と、DRビジネスプロセスフロー図を以下に示す。


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

図．２　OpenADR論理コンポーネントの関連図


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

図．３　論理コンポーネントを用いたデマンドレスポンスのビジネスプロセスフロー

以下、この図に現れた順に、DRのビジネスフローを見ていくが、その前に、デマンドレスポンス自体の定義と、DRイベント、DRシグナル、DRサービス、DRプログラムの関係をまとめておく。

　デマンドレスポンスの定義とDRイベントについて

デマンドレスポンス（DR）とは、系統の需給バランスや電力市場の状況に応じて、一定期間、顧客のエネルギー使用量を一時的に変更することと定義することができる。

そして、そのような、顧客の負荷プロファイル（Load Profile）の変更を促すものをDRイベントと呼ぶ。

下図はDRイベントを時間軸に沿って記述したモデルで、DRイベントは、通知期間（Notification Period）、アクティブイベント期間（Active Event Period）、および回復期間（Recovery Period）から構成されている。

※緊急ピーク時課金（CPP：Critical Peak price）を採用した典型的なDRでは、前日のうちにCPPの通知が行われ、アクティブイベント期間（時間帯）は、例えばCPP料金メニューで「12時から17時の5時間」というようにあらかじめ決められている。

※CPPのDRイベントでは、図中の立ち上がり期間（Ramp Period）および回復期間に関してそれほどセンシティブに考えなくても良いが、OpenADR2.0で追加されたアンシラリーサービスでは、アクティブイベント開始時間から4秒以内（=立ち上がり期間）に指定されたkWの需要削減が行われ、同じくアクティブイベント終了時間から指定時間内（回復期間）に需要量を元に戻す、ピーク需要対応発電機相当のレスポンスが求められている。


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

図．４　DRイベントモデルとDRイベント例

図．４の下部には、3種類のDRイベント例が示されている。

1) 最初の例は、EV充電に関するDRイベントで、風力発電などで系統に大量に電力が流れ込んできているので、通常料金より低い料金設定（$0.12/kW）としてEV充電を促す内容となっている

2) 2番目の例は、ビルに対する需要削減のDRイベントで、ピーク時間帯（Active Event Period）5時間内でも1時間ごとに料金設定を変更している例である。4時間目の料金は、1時間目の倍以上に設定されていることがわかる

3) 3番目は工場などの大口需要家に対する需要削減DRイベントで、不等間隔の時間帯ごとの需要削減量（kW）が指定されているDRイベントの例である

　DRシグナルとDRプログラムについて

DRイベントを発生させるための情報がDRシグナルだが、DRシグナルに関しては、ZigBeeアライアンスのSmart Energy Profile (SEP) 2.0や、国際標準化組織IECのTC57-WGが担当している CIM（IEC 61970 + IEC 61968 + IEC 62325）でも定義されている。また、全米のISO/RTOのDRプログラムは、すでに30GW（「SPRING 2012 PAP Meeting for Wholesale Demand Response Communication Protocol」情報）以上電力需給バランスをとるために貢献しているが、そのDRシグナルも統一されていない。
北米エネルギー規格委員会（North American Energy Standards Board：NAESB）のスマートグリッドタスクフォース（SGTF）は、国立標準技術研究所（NIST）の立てた優先行動計画PAP09「Standard DR+DER Signals」への対応の一環でDRのユースケースから、DRの制御シグナル・価格シグナルの標準策定のための要件整理を実施した結果、一般家庭向けと、大口顧客向けのDRプログラムでは、DRシグナルが異なるとして、以下の2つのドキュメントをNAESBの実行委員会（executive committee）宛てに作成・提出している。

• REQ.17：Specifications for Retail Standard Demand Response Signals
• REQ.18：Specifications for Wholesale Standard Demand Response Signals

これらのDRシグナルに関する要件のまとめは2010年10月に完了しているが、NISTのPAP09自体はまだ完了状態になっていず、DRシグナル自体の標準化の整理は、まだ少し時間を要するようである。

下図は、ISO/RTOのDRプログラムを含め、電力会社／DRアグリゲーターが米国で提供しているDRプログラムをまとめたものである。


出典：OpenADR Functional Requirements and Use Case Document

図．５　米国におけるDRプログラムの体系

例えば、カリフォルニア州の電力会社PG&Eが提供しているDRプログラムを図．５と対応付けると以下のとおりである。

• SmartAC program：セントラル冷暖房装置を所有する一般家庭／中小企業向けの直接負荷制御プログラムで、SmartACプログラムに参加申し込みをすると、PG&EがSmartACスイッチを無償で設置。夏季、電力供給不足が発生すると、PG&Eからの信号でSmartACのスイッチが遠隔操作され、負荷削減が行われる。

• Capacity Bidding Program：夏季11～19時の供給予備力を確保するためのプログラムで、大口需要家は、DRアグリゲーターを通してこのプログラムに参加できる。

• Base Interruptible Program：カリフォルニア州の系統運用者であるCAISOが電力供給に関するエマージェンシーを宣言した場合、PG&Eが需要削減に応じるための大口需要家向けのプログラムで、この契約を行った需要家は、そのようなイベントが発生しなくても月あたり8～9ドル/kWのインセンティブを受ける。その代わり、イベント発生を告知されたら、需要家は30分以内に予め定めたレベル（FSL：Firm Service Level）まで負荷を下げなければならない。

• Demand Bidding Program：系統の安定性を確保するため、CAISOが1日前に警告を出した場合、PG&Eが要求すれば負荷を下げられる大口需要家にインセンティブを与える通年のプログラム。負荷削減量に応じて$0.50/kWが支払われる。

• SmartRate　Summer Pricing Plan：一般家庭向けの、CPP料金メニューで、年間最大15日のSmartDay以外、夏季（6月1日から9月30日）料金として以下の割り引きが受けられる

1)SmartDayに指定された日の14～19時以外、使用電力量に関して$0.02992/kWhの割り引きを受けることができる
2)段階料金区分3～5では、更に使用電力に関して$0.01/kWhの割り引きを受けることができる
ただし、SmartDayに指定された日の14～19時の使用電力量については、$0.60/kWhの高額料金が適用される

以上、OpenADR1.0を理解する上での道具立ての説明を終わったので、DRのビジネスプロセスフローに沿って、OpenADR1.0の内容を紹介する。

　デマンドレスポンスビジネスの基本的な流れ


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

図．６　基本的なデマンドレスポンスの流れ

上図の「1.0 Administrate DR Program」から「5.0 Post DR Event Management」が、デマンドレスポンスビジネスの基本的な流れである。以下、個々のビジネスプロセスについて、その内容を概説する。

 1.0：DRプログラム管理：Administrate DR Program

PG&EのDRプログラムをいくつか紹介したが、DRプログラムは特定のビジネスニーズを満たすために設計され（Create DR program）、DRサービスとして提供されるが、図.７に示すように、途中で内容が変更されたり（Update DR Program）、中止されたり（Remove DR Program）することもある。
DRサービス提供者は、電力会社（Load Service Entity）であったり、DRアグリゲーターその他ESPであったりする。

このビジネスプロセスは、自動化プロセスではないため、詳細は割愛する。内容に興味のある方は、OpenADR1.0 FRUの「4. Administrate DR Program」を参照されたい。

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

図．７　DRプログラム管理

 2.0：DRサービスを受ける顧客の管理：Administrate Customer for DR

DRサービス提供者は、DRプログラムを設計し、パイロットテストを行って期待通りの効果が認められると、必要なら規制機関の認可を得た後、そのDRプログラムに参加するよう需要家を勧誘する。そして、そのDRサービスを受ける顧客を登録（Register / Enroll Customer for DR program）したり、その顧客IDを更新したり（Update Customer Identity）、DRサービスの利用を中止（Remove a Customer from DR program）を行うのが、図.８に示すビジネスプロセスである。

本ビジネスプロセスも、自動化プロセスではないため、詳細は割愛する。内容に興味のある方は、OpenADR1.0 FRUの「5. Administrate Customer for DR」を参照されたい。


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

図．８　DRサービスを受ける顧客の管理

3.0：DR資源の管理：Administrate DR　Resource

DRサービスに参加する顧客は、DRプログラムに参加するに当たってどのようなDR資源／DR設備を保有しているかを登録する。図．９は、DR資源/DR設備の登録（Register DR Resource）、更新（Update DR Resource）、削除（Remove DR Resource）と、DR設備の管理、分散電源（DER）のDR資源としての管理、更に登録したDR資源を利用するための入札（DR Bidding）プロセスを記述したものである。

本ビジネスプロセスも、自動化プロセスではないため、詳細は割愛する。内容に興味のある方は、OpenADR1.0 FRUの「6. Administrate Customer for DR」を参照されたい。


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

図．９　DR資源客の管理

4.0：DRイベントの実行：Execute DR　Event

DRイベントの実行は、実施されるDRプログラムのタイプや実施状況で種々の形態をとる。その中でも典型的な形は以下の4つである：

１．DRイベント実施の事前通知（Notify DR Event）
2.（価格情報その他の）DRメッセージのブロードキャスト（Broadcast DR Message）
3.（発電機への発電指令に相当する）節電指令の発行（Dispatch DR Instructions）
4.直接負荷制御指令の発行（DR Direct Load Control）

また、米国では地域によって卸売電力市場構造が異なっていたり、小売り自由化が行われている州や、小売りは規制料金であったりするので、DRイベントを実行するに当たって、地域に即したコーディネーション（Operational Coordination）を必要とする。

図．１０は、そのようなDRイベント実行のビジネスプロセスについてまとめたものである。


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

図．１０　DRイベントの実行

5.0：DRイベント後の管理：Post DR　Event Management

DRイベント後の管理は、DRイベント期間内にどれほど需要削減ができていたか／できていなかったかを計測・検証（Measurement & Vilification）し、それに対する報酬／罰金はどうするのかを決定（Settlement）するビジネスプロセスである。図．１１では、３種類の電力市場構造それぞれについて、ユースケースを検討している。


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

図．１１　DRイベント後の管理

長くなってきましたので、今回はOpenADR1.0のおさらい（前編）ということにし、残りは次回にまわしたいと思います。

今回のおさらいで再確認したOpenADRの標準が定める機能範囲は、以下の通りです。

１）DRイベントを実行する上で必要となる、オープンで相互運用が可能なDRシグナルのデータ構造と、その通信プロトコルを定義している

２）DRシグナルには、大きく分けて①直接負荷制御シグナル、② 負荷プロファイルの変更シグナル、③ DR関連価格シグナルの3種類がある

３）電力を消費する負荷設備や家電製品の制御だけでなく、 B2G/H2Gにかかわる分散電源を用いた需要調整を視野に入れている

４） DRシグナルの利用に必要なDRプログラム管理に関しても標準化を考えている

すなわち、OpenADRは、発電側ではなく需要側で需給バランスをとるというDRの実施部分だけではなく、デマンドレスポンスビジネス全般を視野に入れ、その利害関係者間の相互運用を保証するための標準策定を目指しているということですね。

終わり

投稿タグ
, , , , , , , , ,