© 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－その６」を作成する前に、説明文の挿入や、表現の加筆・訂正を行いました。既に「OpenADR2.0－その５」をご覧いただいている場合は、お手数ですが、再度「OpenADR2.0－その５」もご覧いただければ幸いです。
今回は、EI1.0のOpenADRプロファイルに関連するサービスの説明に入る前段階までを目標にご紹介します。
いつもの通り、全訳ではないことと、場合によっては個人的な解釈が含まれているかもしれないことをご承知おきください。なお、使用した図表で出典の記述のないものは、すべてEI1.0に記載されていたものです。また、文字の細かな図表は、図表名をクリックしていただくと、拡大表示するようにしてあります。
では、はじめます。
モニター、レポートおよび予測
ReportRequest
DRイベント期間であるかどうかに係らず、あるPartyが他のPartyに対して、電力量や電圧、瞬時値などの計測結果の報告を依頼する場合使われるのが、EiReportRequestである。以下にEiReportRequestの構成と、用語の定義、クラス図を示す。
図．１３ EiReportRequestの構成
reportSpecifier
Partyは、ReportRequestもしくはmarketContextの中でreportSpecifierを用いて、どんなReportが欲しいかを指定する。以下にreportSpecifierの構成と、用語の定義を示す。
図．１５ reportSpecifierの構成
表．１３ reportSpecifierで用いられる用語の定義
表．１３のSpecifierPayloadでどのようなReportかが指摘されるが、そのSpecifierPayloadの内容と、更に、その中のReportTypeの内容を表．１４および表．１５に示す。
表．１４ SpecifierPayloadで用いられる用語の定義
Report Scheduler
reportSchedulerは、どの程度の頻繁で、どれくらいの時間にわたってReportが準備されるかを示す抽象クラスである。
図．１６ reportScheduler
以下にReport Schedulerのクラス図を示す。
レポート（Report）、スナップ（Snap）および予測（Projection）
Reportは、レポートの種類を規定するメタデータと、計測値を含むIntervalの集合からなる単純なStreamデータである。レポートの値には、過去のもの、現在のもの、あるいは将来の計画値がある。過去の一連の計測値を含むものをReport、ある一瞬の計測値を含むものをSnap、将来の数値を含むものをProjectionと呼ぶ。
EIのReport
eiReportのメタデータ部分の定義を以下に示す。
次に、eiReportの構成と、その構成要素の用語の定義、クラス図を示す。
図．１８ eiReportの構成
次に、eiReportの要素であるreportDescriptionの構成と、その中の要素の用語の定義を示す。
reportDescription
Reportデータ構造のうち、reportDescriptionは、何がReportに入っているかを示すものである。特に、Targetとして、複数の要素がReportに含まれる場合有用である。
図．２０ reportDescriptionの構成
表．１９ reportDescriptionで使われる用語の定義
reportPayload
報告書(Report）の各時間間隔（Interval）の詳細は、シグナルと多くの類似点を持つが、報告書は実世界での結果について記述するがゆえに、シグナルより複雑で、様々な追加情報を含む。以下に、reportPayloadの構成と、その中で用いられる用語の定義を示す。
図．２１ reportPayloadの構成
このうち、計測タイプ（Reading Type）は、報告書で返された情報について記述したもので、具体的には、ペイロード中の数値がどのように計測されたかを示すものである。Reading TypeはGluonのStreamにあり、Sequence（あるいは、Snap）内の各インターバルに継承される。以下に、ReadingTypeの詳細を示す。
レスポンス
Response
全てのサービスは、共通のレスポンス（Response）を共有する。レスポンスは、共通の拡張可能なコード、判読可能な記述、および、このレスポンスがどのメッセージに応じたものかを示す情報を含んでいる。以下に、EIでのResponseの構成と、用語の定義とクラス図を示す。
>表．２２ EiResponseで使用される用語の定義
EventResponse
イベントへの応答は状態に依存するので、表．２３の要素を保持している。
Availability Behavior
marketContextごとに、VTNによる可用性（Availability）の解釈が異なる。そこで、EiMarketContextの定義の一環として、可用性に関する振る舞いが公開されている。
表．２４ Availability Behaviorで用いられる用語の定義
OpenADR2.0プロファイルとE Ｉ サービス
OpenADR2.0プロファイルは、OpenADRを実装するために必要なEIのサービスを規定したものである。以下にサービス一覧を示す。
表．２５ OpenADR2.0プロファイルを構成するEIサービス
目標の部分までたどり着きましたので、本日はここまでとさせていただきます。
終わり
- 投稿タグ
- Demand Response, Smart Grid, Standard, スマートグリッド, デマンドレスポンス, 標準化
Pingback: 新谷 隆之