© Copyright Ken Grainger and licensed for reuse under this Creative Commons Licence.
前２回で、OASISの標準仕様書「Energy Interoperation Version 1.0」（以降、EI1.0と略）のOpenADRプロファイルを構成する道具立てを一通りご紹介しました。
といっても、途中からは、EI1.0標準仕様書に定義されているOpenADRプロファイルに関連しそうなクラスを抜き出して、個別に説明しただけでしたので、非常にわかりづらかったと思います。
ボリュームも多かったので、それぞれのクラスがデマンドレスポンスの中でどういう位置付けにあるのかは後で考えることにして、とりあえず、「表．２５ OpenADRプロファイルを構成するEIサービス一覧」にたどり着くまで頑張ったのですが、EiRegisterParty、EiQuote、EiAvail、EiEnrollなど、まだカバーしていないものも多数あります。
ただ、この調子で単にEI1.0の記述内容を多少日本語に置き換えながらご紹介していくだけでは、消化不良が募るだけですので、どうしたものかと思っていた矢先、関連する最新情報を見つけました。
北米エネルギー規格委員会（NAESB）のSGTF（Smart Grid Task Force）から7月15日付で「Retail DR Use Cases DRAFT1.1」が公開されています。内容を見ると、UCAIugのOpenADR-TFが作成した「OpenADR Functional Requirements and Use Case Document Version1.0(FUD)」をベースにしていることがわかりますが、 OpenADR2.0－その２でご紹介したFUDの「基本的なデマンドレスポンスの流れ」よりも詳しいユースケース概要図(下図)となっています。
そこで、この流れ（1.0：DRプログラム管理 ~ 5.0：DRイベント後の管理）に沿って、EI1.0 OpenADRプロファイルを構成するEIのクラス／サービスを見ていきたいと思います。
出典：NAESB 「Retail DR Use Cases DRAFT1.1」
例によって、ＥＩ１．０当該部分の全訳ではないことと、場合によっては、勝手な解釈や蛇足があるかもしれないことをご承知おきください。なお、出典の記載のない図表は、EI1.0に記載されていたものです。また、文字の細かな図表は、図表名をクリックしていただくと、拡大表示するようにしてあります。
では、はじめます。
最初に、今回カバーするEI1.0 OpenADRプロファイルを構成するEIサービスを一覧した表．２５を再掲しておきます。
表．２５ OpenADR2.0プロファイルを構成するEIサービス一覧
1.0：DRプログラム管理：Administrate DR Program
UCAIugのOpenADR-TFで作成されたOpenADR1.0 SRSでもDR Program管理は規定されていなかったが、EI1.0でも規定されていない。
そもそも、DR Programという用語は、EI1.0の中で一度出現するのみで、用語集（Appendix B. Glossary）にも入っていない
※DR Program管理に関して、EI1.0では何も触れられていないが、OpenADR1.0 SRSの断り書きは以下の通り
this SRS does not cover many of the administrative aspects of managing a DR program 中略The SRS is focused on only those aspects of DR management that is required to facilitate the exchange of DR signals with their customers.
2.0：DRサービスを受ける顧客の管理：Administrate Customer for DR
EI1.0では、DRシグナルの授受をVTNとVEN２者間の相対的な関係と捉え、両者ともにPartyと位置付けている。一般に顧客というと、消費者（Electricity Consumer）ということになるが、電力会社がVTNの場合、VENのDRアグリゲーターは電力会社の「顧客」と考えられる。
EI1.0のEiRegisterPartyサービスは、OpenADR SRSが定義した「顧客の管理」を拡大し、あるVENがインタラクションする相手のVTNに対して自分の登録・更新・削除を行うためのサービスと思われる。
以下に、EiregisterPartyのサービス一覧と、そのサービスシーケンスを示す。
EiRegisterPartyサービス
図．２５ EiRegisterPartyサービスのシーケンス図
表．２６では、３つのサービスは、サービスの呼び出し側も受け側も単に「Party」となっているが、図．２５を見ればわかるとおり、顧客登録される側のPartyが、登録する側のPartyに対して実行するものである。
以下に、EiPartyクラスと、PartyのCreate/Request/CancelのEiRegisterPartyサービス実行時（OperationおよびResponse）のペイロードを示す。
図．２６ EiPartyクラスとEiRegisterPartyサービスのペイロード
なお、EI1.0自体には、partyIDとして用いられるactorＩＤの定義は記載されていない。EI1.0の冒頭に、EI1.0に関連する作業（Related work）として、「NAESB Actors for DR」と記されており、actorIDにはNAESBが定義したものを利用することを前提としているものと思われる。
3.0：DR資源の管理：Administrate DR Resource
実際に電力会社等が提供するデマンドレスポンス・サービスの利用を申し込むのは電力顧客かもしれないが、登録するものは、その電力顧客のDR設備やDR資源である。したがって、EI1.0のOpenADRプロファイルに含まれるEiEnrollサービスは、顧客管理ではなく、DR資源管理用のサービスと考えられる。
以下に、EiEnrollのサービス一覧と、そのサービスシーケンスを示す。
EiEnrollサービス
図．２７ EiEnrollサービスのシーケンス図
表．２７の３つのサービスも、サービスの呼び出し側、受け側とも、単に「Party」となっているが、図．２７を見ればわかるとおり、申し込み側のPartyが、申し込みを管理する登録する側のPartyに対して実行するものである。
以下に、EiEnRollサービスの情報モデルと、EnRollのCreate/Request/CancelのEiEnRollサービス実行時（OperationおよびResponse）のペイロードを示す。
「EiCreateEnroll」は、他のEIサービスの「create」操作とは異なり、特定のVTN/VEN２者間で今後インタラクションを採れるように関係を構築するものである。「EiCreateEnroll」操作実行時に、自動的にDR資源の登録が行われる場合がある。
※ OpenADR SRSでは、DR資源の登録／更新／削除、DR設備の登録／更新／削除のユースケースが定義されていたが、EI1.0の仕様書を見る限り、上記赤文字での表現箇所以外でDR資源の登録／更新／削除に触れている部分は見当たらない。
※ また、EI1.0の6章脚注に、Resourceに関する以下の説明があり、EI1.0ではOpenADR SRSでのDR設備（DR Asset）は、取り扱い対象外であることがわかる。
A finer level of granularity is sometimes called an asset. Assets are not in scope for this specification.
4.0：DRイベントの実行：Execute DR Event
4.1：電力需要抑制のDRイベント通知：Notify DR Event （Bulk Power） および
4.2：配電のDRイベント通知：Notify DR Event（Distribution）
DRイベントには、いろいろなタイプがあるが、それらはDRイベントのパラメーターとイベント情報によって区別される。以下に、EiEventクラスと、サービス一覧、および、そのサービスシーケンスを示す。
• EiEventサービス
再掲：図．１０ EiEventの構成
図．３０ EiEventサービスのシーケンス図（PUSH型）
表．２８にある通り、EiEventサービスは、基本的にVTNからVENに対して実行されるサービスである。EI1.0の中では説明されていないが、DRイベントの事前通知（Create）、通知内容変更（Change）、DRイベントの実施取りやめ（cancel）の他に、Distribute（EiDistributeEvent）とあるのは、事前通知したイベントの実施を促すものと考えられる。
なお、図．３０は、VTNからVEN側にPUSH型でEiEventサービスを実行する場合のシーケンス図で、PULL型で実行する場合を図．３１に示す。
図．３１ EiEventサービスのシーケンス図（PULL型）
以下に、EiEventサービスの情報モデルと、EiEventサービス実行時（OperationおよびResponse）のペイロードを示す。
4.3：卸売電力市場向けDR目的の価格通知：Broadcast Pricing （Wholesale） for DR Purpose および
4.4：小売り向けDR目的の価格通知：Broadcast Pricing （Retail） for DR Purpose
EI1.0の9章「Event Services」によると、EI1.0では価格イベントについてはEiEventサービスではなく、EiQuoteサービスの1つであるEiSendQuote操作を用いるとの説明があったので、以下に、EiQuoteのサービス一覧と、そのサービスシーケンスを示す。
※ただし、EI1.0のEiQuoteの節では、EiSendQuoteではなく、EiDistributeQuoteとなっている。
• EiQuoteサービス
図.３４ EiQuoteサービスのシーケンス図
なお、図．３４中では、EiDistributeQuote操作もPartyからCounterPartyに対して実行されるように記載されているが、DR目的の価格通知に限定すれば、EiDistributeQuote操作はVTNからVENに対してPUSH型で実行されると考えて良い。
以下に、EiQuoteサービスの情報モデルと、サービス実行時（OperationおよびResponse）のペイロードを示す。
4.5：Dispatch DR Instruction（Bulk Power）
以下に、NAESBの最新版「Retail DR Use Cases」の「4.5.1 Monitor DR Event (Bulk)」に記載されたシーケンス図を示す。
出典：NAESB「Retail DR Use Cases」4.5.1
図．３６ Dispatch DR Instruction（Bulk Power）のシーケンス図
このシーケンス図では、系統・市場運用者（SMO）は、すべてのDR資源から５分間隔で電力使用量を計測しており、ある規定に達した段階でディスパッチ指令（Dispatch-instruction-Message）を出している。この指令は、個々のDR Program Participant宛てに負荷削減量を指定した指名制負荷削減指令（OpenADR2.0－その３参照）と思われ、Target指定のEiDistributeEventと考えられる。また、その前の5分間隔の電力量計測に関しては、EiReportサービスに該当するものがある。
それは、eiUpdateReportで、表．３０ EiReportサービス一覧のNotes欄を見ると、Used to update the Report e.g. periodic responses とあり、図．３６のシーケンス図通り、５分ごとの計量値がeiUpdatedReportで返される。
以下に、EiReportサービス一覧と、そのサービスシーケンス図を示す。
• EiReportサービス
図．３７ EiReportサービスのシーケンス図
以下にEiReportサービスの情報モデルと、サービス実行時（OperationおよびResponse）のペイロードを示す。
4.6：Dispatch DR Instruction（Distribution）
NAESBの最新版「Retail DR Use Cases」の「4.6 Dispatch DR Instructions (Distribution)」によると、このDR指令は、特定のDR資源に対して「100kWの負荷削減」などの指示を出すときに用いられるもので、サービスシーケンスは下図のとおりである。
出典：NAESB「Retail DR Use Cases」4.6
図．４０ Dispatch DR Instruction（Distribution）のシーケンス図
表．２８ EiEventサービスのEiDistributeEventの操作にはレスポンスがないので、上図のDR dispatch instructionsには該当しない。
どちらかというと、EiCreateEvent操作に対して、EiCreatedEventレスポンスが返されるシーケンスに似ているが、実際、EI1.0のどのサービス／操作に該当するかは不明である。
4.7 DR Direct Load Control （Distribution）
NAESBの最新版「Retail DR Use Cases」の「4.7 DR Direct Load Control (Distribution)」によると、このDR指令は、特定のDR設備に対して「100kWの負荷削減」などの指示を出すときに用いられるもので、サービスシーケンスは下図のとおりである。
出典：NAESB「Retail DR Use Cases」4.7
図．４１ DR Direct Load Control （Distribution）のシーケンス図
元来、DR設備（DR Asset）は、EI1.0の取り扱い対象外なので、このDR指令に相当するEIサービスは存在しないものと思われる。
4.8：DR Event Execution
「4.8 DR Event Execution」に関しては、NAESBの最新版「Retail DR Use Cases」より、OpenADR-TFが作成した「OpenADR Functional Requirements and Use Case Document（FUD）」の方が詳細にユースケースを検討している。
以下に、リアルタイム価格ベースのDR（RTP）実施の場合、事前通知型DR（Slow-DR）実施の場合、および直接負荷制御のDR（DLC）実施の場合のシーケンス図を示す。
出典：FUD 4.8.1
上図で、Publish Locational RTPのメッセージがESP/LSEからConsumerに出されるところがDR Event Executionに相当すると思われるが、これはEiQuoteサービスのEiDistributeQuote操作に相当すると思われる。
出典：FUD 4.8.2
上図で、DR Dispatch Instructionの出されている部分がDR Event Executionに相当すると思われるが、これはEiEventサービスのEiDistributeEvent操作に相当すると思われる。
出典：FUD 4.8.2
上図で、系統・市場運用者の出しているDR Dispatch InstructionがDR Event Executionに相当すると思われるが、これはEiEventサービスのEiDistributeEvent操作に相当すると思われる。
4.9：Operational Coordinations
本来ここに登場させるべきかどうか不明だが、EI1.0 OpenADRプロファイルに指定された３つのサービスをここで説明する。
• EiAvailサービス
VENは、自分が保有するDR設備／DR資源が、あるmarketContextの中で、いつDRイベントに応じられるかEiAvailサービスを用いて指定し、VTNに通知する。
以下に、EiAvailのサービス一覧と、そのサービスシーケンス、情報モデルと、サービス実行時（OperationおよびResponse）のペイロードを示す。
図．４５ EiAvailサービスのシーケンス図
図．４６ EiAvailサービスの情報モデルとEiAvailサービスのペイロード
• EiOptサービス
VENは、自分が保有するDR設備／DR資源について、事前にEiAvailサービスで設定したDRイベント対応スケジュールをOpt-In、Opt-outスケジュールを作成しVTNに通知することで変更することができる。
すでにOptスケジュールがあった場合にも、新たなOptで指定したDR対応スケジュールは最優先される。
以下に、EiOptサービス一覧と、そのサービスシーケンス、情報モデルと、サービス実行時（OperationおよびResponse）のペイロードを示す。
図．４７ EiOptサービスのシーケンス図
図．４８ EiOptサービスの情報モデルとサービス実行時のペイロード
• EiMarketContextサービス
DRイベントや、DRサービス内容は、国や州の電力市場制度によって大きく異なっている。DRサービスに参加するためには、それが属する市場で使われる専門用語や取引製品その他に対する予備知識を仕入れておく必要がある。marketContextとは、そのような、市場環境での各Partyの振る舞い等が記述されているものである。
EIサービスにおけるmarketContextは、EMIX標準のmarketContextをベースとしたスーパーセットになっており、DRサービスに携わる各Partyは、EiMarketContextサービスを用いることで、その市場の情報を得ることができる
以下に、EiMarketContextサービス一覧と、そのサービスシーケンス、情報モデルと、サービス実行時（OperationおよびResponse）のペイロードを示す。
図．４９ EiMarketContextサービスのシーケンス図
図.５０ EiMarketContextの情報モデルとサービス実行時のペイロード
5.0：DRイベント後の管理：Post DR Event Management
UCAIugのOpenADR-TFで作成されたOpenADR1.0 SRSでもDRイベント後の管理は規定されていなかったが、EI1.0でも同様に、規定されていない
※この件に関して、EI1.0の2章「Overview of Energy Interoperation」の断り書きは以下の通り
Version 1.0 of Energy Interoperation does not define the critical fifth market activity, measurement and verification (M&V). A NAESB task force (Demand Side Management and Energy Efficiency Working Groups) is continuing work to define the business requirements for M&V.
以上、EI1.0 OpenADRプロファイルとして提示されたEIサービスをご紹介しました。
EI1.0だけを眺めていると、これでOpenADR2.0をすべてカバーしているのかどうかが良くわからなかったのですが、DRの基本的な流れのユースケースとマッチングさせることにより、以下が判明しました。
• DR資源管理の部分は、OpenADR2.0の仕様が含まれていない
• DR設備（DR Asset）を取り扱っていないので、一般家庭のエアコンなどの直接負荷制御（DLC）にも対応していない
• OpenADRアライアンスの公開ドキュメント『The OpenADR Primer』は、「EI1.0の中で、OpenADR2.0がOpenADRプロファイルとして規定されている」としているが、今回EI1.0を見渡した限り、Fast-DRやPEV対応を含めて、本当にOpenADR2.0対応なのか疑問
• EI1.0の「1.4 Contributions」の中でも、OpenADRに関しては、以下の3種類のドキュメントしか言及していない
1) OpenADR 1.0 System Requirements Specification v1.0
2) OpenADR 1.0 Service Definition － Common Version :R0.91
3) OpenADR 1.0 Service Definition － Web Services Implementation Profile Version: v0.91
ということで、とりあえず、OpenADR2.0の紹介シリーズは、これで終わりにしたいと思います。
いろいろ見落としや誤解している個所があるかもしれません。
このブログをお読みくださっている専門家諸兄のご意見、ご指摘をいただければ幸いです。
終わり
- 投稿タグ
- Demand Response, Smart Grid, Standard, スマートグリッド, デマンドレスポンス, 標準化
Pingback: 新谷 隆之