© Copyright Roger Kidd and licensed for reuse under this Creative Commons Licence.

前回は、OpenADR2.0の要求仕様を取り込んだOASISの標準仕様書「Energy Interoperation Version 1.0」(以降、EI1.0と略)の1章から5章の途中まで、EIの定義とアーキテクチャ、およびEIの基礎となる2つの標準WS-CalendarとEMIXを概説し、EIのセマンティクス(アクター、マーケット・コンテキスト、イベントベースのインタラクション)をご紹介しました。

最後の方は、図表のカット&ペーストのみの状態になっていましたので、この「OpenADR2.0-その6」を作成する前に、説明文の挿入や、表現の加筆・訂正を行いました。既に「OpenADR2.0-その5」をご覧いただいている場合は、お手数ですが、再度「OpenADR2.0-その5」もご覧いただければ幸いです。

今回は、EI1.0のOpenADRプロファイルに関連するサービスの説明に入る前段階までを目標にご紹介します。

いつもの通り、全訳ではないことと、場合によっては個人的な解釈が含まれているかもしれないことをご承知おきください。なお、使用した図表で出典の記述のないものは、すべてEI1.0に記載されていたものです。また、文字の細かな図表は、図表名をクリックしていただくと、拡大表示するようにしてあります。

では、はじめます。

 モニター、レポートおよび予測

ReportRequest

DRイベント期間であるかどうかに係らず、あるPartyが他のPartyに対して、電力量や電圧、瞬時値などの計測結果の報告を依頼する場合使われるのが、EiReportRequestである。以下にEiReportRequestの構成と、用語の定義、クラス図を示す。


図.13 EiReportRequestの構成

表.12 ReportRequestで用いられる用語の定義


図.14 EiReportRequestのクラス図

 reportSpecifier

Partyは、ReportRequestもしくはmarketContextの中でreportSpecifierを用いて、どんなReportが欲しいかを指定する。以下にreportSpecifierの構成と、用語の定義を示す。


図.15 reportSpecifierの構成

表.13 reportSpecifierで用いられる用語の定義

表.13のSpecifierPayloadでどのようなReportかが指摘されるが、そのSpecifierPayloadの内容と、更に、その中のReportTypeの内容を表.14および表.15に示す。

表.14 SpecifierPayloadで用いられる用語の定義

表.15 Report-Typeで用いられる用語の定義

  Report Scheduler

reportSchedulerは、どの程度の頻繁で、どれくらいの時間にわたってReportが準備されるかを示す抽象クラスである。


図.16 reportScheduler

表.16 Report Schedulerの用語の定義

以下にReport Schedulerのクラス図を示す。


図.17 ReportSchedulerのクラス図

  レポート(Report)、スナップ(Snap)および予測(Projection

Reportは、レポートの種類を規定するメタデータと、計測値を含むIntervalの集合からなる単純なStreamデータである。レポートの値には、過去のもの、現在のもの、あるいは将来の計画値がある。過去の一連の計測値を含むものをReport、ある一瞬の計測値を含むものをSnap、将来の数値を含むものをProjectionと呼ぶ。

  EIのReport

eiReportのメタデータ部分の定義を以下に示す。

表.17 Reportメタデータの定義

次に、eiReportの構成と、その構成要素の用語の定義、クラス図を示す。


図.18 eiReportの構成

表.18 eiReportで使われる用語の定義

図.19 EiReportのクラス図

次に、eiReportの要素であるreportDescriptionの構成と、その中の要素の用語の定義を示す。

  reportDescription

Reportデータ構造のうち、reportDescriptionは、何がReportに入っているかを示すものである。特に、Targetとして、複数の要素がReportに含まれる場合有用である。

 


図.20 reportDescriptionの構成

表.19 reportDescriptionで使われる用語の定義

  reportPayload

報告書(Report)の各時間間隔(Interval)の詳細は、シグナルと多くの類似点を持つが、報告書は実世界での結果について記述するがゆえに、シグナルより複雑で、様々な追加情報を含む。以下に、reportPayloadの構成と、その中で用いられる用語の定義を示す。


図.21 reportPayloadの構成

表.20 reportPayloadで用いられる用語の定義

このうち、計測タイプ(Reading Type)は、報告書で返された情報について記述したもので、具体的には、ペイロード中の数値がどのように計測されたかを示すものである。Reading TypeはGluonのStreamにあり、Sequence(あるいは、Snap)内の各インターバルに継承される。以下に、ReadingTypeの詳細を示す。

表.21 ReadingTypeで用いられる用語の定義

  レスポンス

  Response

全てのサービスは、共通のレスポンス(Response)を共有する。レスポンスは、共通の拡張可能なコード、判読可能な記述、および、このレスポンスがどのメッセージに応じたものかを示す情報を含んでいる。以下に、EIでのResponseの構成と、用語の定義とクラス図を示す。


図.22 EiResponseの構造

>表.22 EiResponseで使用される用語の定義


図.23 EiResponseのクラス図

   EventResponse

イベントへの応答は状態に依存するので、表.23の要素を保持している。

表.23 EventResponseで用いられる用語の定義

   Availability Behavior

marketContextごとに、VTNによる可用性(Availability)の解釈が異なる。そこで、EiMarketContextの定義の一環として、可用性に関する振る舞いが公開されている。

表.24 Availability Behaviorで用いられる用語の定義


 OpenADR2.0プロファイルとE I サービス

OpenADR2.0プロファイルは、OpenADRを実装するために必要なEIのサービスを規定したものである。以下にサービス一覧を示す。

表.25 OpenADR2.0プロファイルを構成するEIサービス

 

目標の部分までたどり着きましたので、本日はここまでとさせていただきます。

終わり