Bridgnorth Cliff Railway

© Copyright Gordon Griffiths and licensed for reuse under this Creative Commons Licence.

 前回は、PJMが2017年6月末公開したペーパー「Demand Response Strategy」の「Markets and Operations」から、これまでのPJMの容量市場の説明部分をご紹介しました。と言っても、PJMの容量市場で採用しているRPM(信頼性プライシングモデル)の内容/オークションの仕組み、PRDなど、原文では、それらを理解しているうえでの文章だったので、理解しづらかったかもしれません。PRDに関してのみ弊ブログで参考箇所をお知らせしていますが、他の部分も、最低限のことは、弊ブログのどこかで触れていると思いますので、試しに「サイト内検索」の欄に疑問に思った言葉を入れて弊ブログ内検索していただければ幸いです。

今回は、同ペーパーから、「Markets and Operations」の続きで「Future State of DR in the Capacity Market」、すなわち、今後PJMでは容量市場の中でDRをどのように扱おうとしているのかーという、今回のブログシリーズの本題部分についてご紹介します。 いつもどおり、全訳ではないこと、著者本人の思い込みの入った超訳になってしまっていることをお含みおきください。
でははじめます。

http://www.itrco.jp/images/line085.gif

 PJMの市場と系統運用(続き)

容量市場(続き)

【容量市場における今後のDRの取り扱い】

容量市場に導入したCP要件は、DRの容量市場への参加に重大な影響をもたらす可能性がある。というのは、これまで州政府が促進してきた、住宅用エアコンのサイクリング(オン/オフ)で夏場ピーク時間帯の負荷削減を目論むDRプログラムは、年間を通して何度も資源提供を行なえることを条件とするCP要件を満たせず、容量市場へ参加できなくなるからである。
そこで、PJMは、季節限定のDR資源も有効に活用できるように、CP要件に対して以下のような改定を行なった:
(1)年間を通した資源提供が難しいDR資源について、夏場用資源と冬場用資源を組み合わせるオークションクリアリングプロセスを実施する。
(2)ローカル配電地域(Locational Delivery Area :LDA)を越えて夏と冬の資源を集約することも許可する。(例:PJM管内西側の余剰風力と東側の夏場用DR資源の組み合わせ)。
(3)冬場用資源の測定と検証ルールを改定し、夏場用DR資源の測定と検証アプローチと一貫性を持たせる。

PJMは、CP要件を満たすDR資源の容量市場参入機会を増やすため、引き続き検討を行っていく-としている。

ところで、PJMは、これまで容量市場においてRPMオークションで資源調達を行なう上で、エンドユーザのピーク負荷削減行為を考慮に入れていなかった。すなわち、ゾーン/LDAごとの容量オークション実行時、調達量(MW)とMW・日当たりの価格($/MW-Day)で構成されるPJMとしての需要曲線:VRR(Variable Resource Requirement Curve)作成時、価格が高騰するとエンドユーザがピーク負荷を削減する行為(=PRD)を考慮に入れていなかったのである。
2015年に開催された2018/19実運用年向け初期容量オークションでの実施を目標にPJMが考案したWLR(wholesale load responsibility)プロポーザルは、この点を改良したもので、容量資源調達コストに応じてVRRカーブが左にずれることで、容量調達量/容量取引価格ともに以前より少ない量/低い価格で市場決済量/価格が定まる-とした。(下図参照)


図.PRDを考慮したPJM容量市場のVRR曲線
出典:PJMマニュアルNo.18

WLRは、DRを通常の電源と同等に扱うべきだとしたFERCオーダー745に関して米国高裁が無効判決を下した結果に基づき、卸売市場からDRが締め出された(上図でRPM Supplyで示される供給側リソースにDR資源が含まれない)場合を仮定して考案されたものであるが、基本的な部分でまだ矛盾を孕んでおり、将来的に、DR、PRD、WLRをフレキシブルで整合性のある物とするため見直しが必要と考えている。
下表は、現時点でのDRとPRDの特徴をまとめたものである。

表.DR資源対PRD資源の特徴比較

 DR、PRDともに、エンドユーザの負荷削減が、システムの信頼性に同じ影響を及ぼすが、DRとPRDでは測定方法が異なっていて、PRDでは一年中資源提供確度(firm service level:FSL)が用いられるのに対して、DRは夏場がFSL、冬場はエンドユーザの負荷パターンに応じたベースライン(Customer Base Line:CBL)が用いられている。

過去において、DRの実績は非常に良好だったが、DRイベント発動の頻度は多くなかった。PJMは2015年4月22日以降DRを発動しておらず、作動確認のためのコンプライアンスイベントも実施していない。2013年9月11日以降、CSPにDR資源を提供予定していたエンドユーザがそれ以前と同じだけのDR資源を提供できるかどうかわからず、作動確認テストをしてみると、テストをパスしない可能性がある。
さらに、現在のDRテスト要件は、電源のテスト要件を元に作成されたもので、実際の負荷管理イベントの状況を適切にカバーするものとはなっていない。かつ、現在は、CSPによって1年に1時間テストされるにすぎない。 PRDに関していうと、理想的には、PJMは、季節、場所、日時、イベントの頻度に基づいて、エネルギーと容量の削減を予測できる必要がある。 予測性を向上させるためにも、しっかりテストを実施して、DR資源をより頻繁に使用することが理想的である。

【DRイベントの発動の将来の形】

系統運用者から見ると、DRリソースを適用するのは、DRリソースの提供価格が電源その他のリソースより経済的かどうかで決まる(経済的発動シナリオと呼ぶ)。一方、DRリソース提供者は、そもそも電気を使いたいから使っているのであり、系統運用上必要とされた場合でも、本来は自分の負荷を軽減したくないので、現状では、DRリソースの提供価格は、DR資源を提供することによる機会費用を勘案し高めとなっている(ほとんどの場合、DRの機会費用は数値化するのが非常に難しく、また、発動の時間、日、頻度、以前のDR発動からの間隔によっても大きく異なるので、入札上限値ぎりぎりの価格となっている)。
したがって、DRリソースに関しても、リアルタイム市場で稼動するプログラムSCED(Security Constrained Economic Dispatch)が経済的な観点から発動するDRリソースを選択するのが理想的だが、現状では、多くのDRリソース価格が同じか類似していることが多く、どのDRリソースにいつ発動をかけるかの決定はタイ・ブレーク・ルールの処理に委ねられ、結果的に同一価格で複数のDRリソースが集約された形で1つの大きなブロックのリソースとして利用されている。

それでも、以前のDRリソースに比べると、DR発動に関して柔軟性がある。 DRリソースタイプとして、リードタイム(30,60,120分)、地理的な位置(ゾーンまたはサブゾーン)、発動頻度といったパラメタで区別できるからである。しかも、サブゾーンは1日前に定義して翌日のDR発動単位として利用することができる。 ただ、現在これらのパラメタが有効に利用されていないので、これらのパラメタを有効利用したDR発動最適化ツールを開発・実装する必要がある。それにより、DR発動の柔軟性が強化され、ゾーンごとに特定量のDR発動が可能になるとともに、地理的位置(郵便番号)ではなく負荷経路(ロードバス)で定義したサブゾーン毎のDR発動も可能になる。

今後、緊急時DRだけでなく、経済的DRも増えてくることを考えると、PJMで実施する需要予測結果の実需要との乖離が、需要予測アルゴリズムの欠陥なのか、DRリソースへの発動の結果なのか判別できることが望ましい。そのために考慮すべき点として以下をあげることができる:

  • ゾーン別にPJMのリアルタイム負荷を予測する。その方が、DRの影響がよくわかる
  • CSP毎のパフォーマンス履歴の分析に基づいて、CSPから報告される予想負荷軽減量を調整できる
  • CSPおよびDRリソースを提供するエンドユーザからリアルタイム(またはほぼリアルタイム)に負荷データを収集し、資源提供確度(firm service level:FSL)を確認する

【DRリソースの測定と検証の将来の形】

電源とDRリソースの主な違いの1つは、提供される容量の定量化にある。 電源であれば、単にユニットの出力値を測定すれば良い。それに対して、DRの場合、現在のアプローチは、資源提供確度(FSL)を信じるしかない。
実際にどの程度DRリソースとして提供されるかは、EDC(配電会社)が契約容量を見積るプロセスに基づいているが、将来的には、EDCに頼らずエンドユーザの容量を決定する一貫性のある堅牢なアプローチを考え出すことが望ましい。

本日は以上です。

DRとPRDの比較表については、まだ消化不良なので、読み進んで理解が深まったところで、表の内容を入れ替えようと思います。

 今回で、容量市場の部分をすべてカバーしましたので、一旦終わりとします

終わり