Bell Tor
© Copyright Graham Horn and licensed for reuse under this Creative Commons Licence.
トランザクティブエネルギー（Transactive Energy：TE）に関して、OpenADRアライアンス会員企業のQualityLogic社が作成したレポート『Transactive Control and OpenADR Roles and Relationships』をご紹介してきましたが、今回は、最後のまとめの部分をご紹介しますが、まとめの部分を理解するため、その前に、これまであまり触れてこなかったGridWiseアーキテクチャ協議会（GridWise Architecture Council：GWAC）と、GWACのStackについて補足しようと思います。
では、はじめますが、例によって、全訳ではないこと、本人の思い入れが混じった（文字色が緑の部分）超訳になっていることはお含みおきください。
トランザクティブコントロールとOpenADRの役割と関連 (続き)
７．GWACとGWACスタックに関する補足
この章の内容は、レポート本文にはありません。また、以下、手抜きで申し訳ありませんが、「【Interop Tokyo 2011（Vol.33）】スマートグリッドは世界の優先事項だ……ギド・バーテル氏が基調講演2011年6月11日(土) 15時03分」、および「次世代エネルギーシステムに係る国際標準化に向けて」の付録２としてNISTのスマートグリッド相互運用性関連標準のロードマップリリース1.0に関して経済産業省産業技術環境局基準認証政策課で翻訳された内容等を参照しています。
• GridWiseアライアンス設立の背景：2003年に米国北東部で起きた大停電がきっかけだった。この停電で、5,500万人に影響が出、265ヵ所の発電所がオフラインになった。これにより電気の将来はどうあるべきかが真剣に考えられ、ビジョン“GridWise 2030”が作られた。GridWise Allianceはそれを実行していくための組織となった。
• GridWiseアライアンスの使命：環境性、経済性に優れた先進的なスマートグリッド・ソリューションの普及を促進し、関係者の間で効果的な協力関係を推進する。
• GridWiseアライアンスの設立メンバ：Alstom、IBM、PNNL、PJM、RockPort Capital、Sempra Energy、UAI（Utility Automation Integrators, Inc.）
• 2004年、米国エネルギー省（DOE）は、先進的なスマートグリッド・ソリューションの相互運用性を確保するため、有識者を集めて設立した産学協同の諮問機関がGridWiseアーキテクチャ協会（GridWise Architecture Council：GWAC）。標準化団体に対して、スマートグリッドでの相互運用性確保のための考え方や要件の整理を実施。
• 2008年、スマートグリッドの相互運用性を考えるフレームワーク（GridWise Interoperability Context-Setting Framework）としてGWACスタックを完成。
• 米国国立標準技術研究所（NIST）が編纂したスマートグリッド標準フレームワーク『NIST Framework and Roadmap for Smart Grid Interoperability Standards』に、このGWACスタックが取り込まれた。
GWACスタック
スマートグリッドのような大規模な複合システムでは、物理的なプラグ互換性から、無線接続での互換性、分散したシステム間でビジネス取引を実施するための手順の整備など、様々なレイヤーで相互運用性の確保が必要となる。そこで、GridWiseアーキテクチャ協議会では、スマートグリッド相互運用性の要件の決定と情報交換の定義を8つのレイヤーに分けて考える「GWACスタック」の考え方を提唱した。
図.1 GWACスタック
非常に単純な機能性、例えば物理的機器のレイヤー及びデータのコード化や伝送のためのソフトウェアは、最下位のレイヤーに限定できるであろう。通信プロトコルやアプリケーションは、より高位に属し、最上位はビジネスの機能性のために確保されている。複雑で精巧な機能や能力を得るためには、GWACスタックのより多くのレイヤーの相互運用が要求される。個々のレイヤーは通常ではその下位のレイヤーに依存し、下位のレイヤーによって起動される。
GWACスタックで最も重要な特徴は、1つのレイヤーで相互運用性を確立すると他のレイヤーでの柔軟性が増すことである。この特徴の最も明白な例はインターネットにおいて見られる。共通のネットワークの相互運用性のレイヤーによって、基本的な接続性のレイヤーが、イーサネットからWiFiへ、光やマイクロ波のリンクへと変化でき、しかも異なるネットワークが同じ共通の方法で情報を交換できる。
この図に示すように、8つのレイヤーは、それぞれが異なる相互運用性のレベルを要求する3つの「ドライバー」に分類される。
• 技術的：相互運用の統語的側面を重視し、どのようなデータが交換されるのかに焦点を当てる
• 情報的：相互運用の意味的側面を重視し、どのような情報が交換されるのか、及びその意味に焦点を当てる
• 組織的：相互作用の実用面（ビジネスや政策）を重視し、特に電力の管理に焦点を当てる
８．サマリ
下表は、このレポートで取り上げたそれぞれの技術が、他の技術とどのような関係にあるのかをまとめたものである。また、次の図は、それらの技術の関係をグラフで表したものである。
表.1 本レポートで議論した技術同士の関係性について
図.2 本レポートで議論した技術同士の関係性について
TeMIXとOpenADRは、ともにEI標準の中で定義された特定ドメイン向けのプロファイルであるが、それらはEIで定義された11のサービスの一部（EiEnroll、EiRegisterParty、EiMarketContext、およびEiQuote）を共有しているので、重なっている。
OpenADR2.0は、EI標準のOpenADRプロファイルをベースとしているものの、現時点ではOpenADRプロファイルで定義した8つのEiサービスすべてを実装していず、逆にoadrPollというEI標準にはなかったサービスを導入しているので、OpenADRプロファイルとは重なる部分があるものの、一部EIからもはみ出している。
図中、EMIXから Energy Interop（EI）に出ている矢印は、EIが、EMIXで定義された多くのスキーマ・エレメントを利用していること。また、OpenADRでも、EMIXが利用されていることを示している。すなわち、EMIX標準は、EI標準内の2つのプロファイルへの「入力」となっていることを示している。
OpenADR2.0からトランザクティブコントロールのACS（Advisory Control Signal：監視制御信号)に出ている矢印は、OpenADR2.0が、トランザクティブコントロールのACSの実装に利用できることを示している。
次に、このレポートで取り上げたそれぞれの技術が、他の技術とどのような関係にあるのか、別の角度から見てみよう。
次の表は、これらの技術をGWACスタックの２~５層にマッピングしたものである。ただし、EMIXの成果物はEIに包含されてしまうので、比較評価軸に入っていない。同様に、トランザクティブエネルギー自体は概念的なフレームワークであり即実装に結び付く技術ではないので、次の表の比較評価軸には含まれていない。
表.2 本レポートで議論した技術のGWACスタックへのマッピング
上記表中最も顕著な違いは、トランザクティブコントロール（TC）とTeMIX技術はビジネスコンテキストを包含していることである。これらは、共にトランザクティブエネルギー（TE）の一形態であるが、TCには、エンティティ間でやり取りする取引情報の中にTeMIXが定義している金融取引のようなX概念がなく、TeMIXには、TCにおけるエネルギーの流れに関するフィードバック（Transactive Feedback Signal：TFS）のような概念がない。
また、本レポートで議論したほとんどの技術は、GWACスタックの高い層での役割も担っているが、ビジネス手続きや経営目標のような、高いレベルのGWACスタック層に関しては、筆者は、技術で定義する範疇外ではないかと考えている。
本日はここまでとします。
次の結論までご紹介しようと思いましたが、GridWiseアライアンス、GridWiseアーキテクチャ協会とGWACスタックに関して補足したのと、折角のまとめなので、EIおよびOpenADR2.0に関しては、レポートより踏み込んだ内容にしようとしたため、思いのほか時間がかかってしまいました。
どれほど「超訳」をしてしまったか気になる方のために、以下に原文での比較表およびグラフを掲載しておきますので、見比べてください。
オリジナルの表.1 本レポートで議論した技術同士の関係性について
オリジナルの図.2 本レポートで議論した技術同士の関係性について
オリジナルの表.2 本レポートで議論した技術のGWACスタックへのマッピング
次回は、いよいよ最後の結論（Conclusions）部分と、付録部分をご紹介しようと思います。
終わり
久々に拝読しました。oadrPoll は本来PUSH型の通信モデルであるOpenADRのメッセージを、PULL型のトランスポート上で実現するために導入されたテクニックに過ぎないので、他のEIサービスと同列に扱うべきではないと思います。これをもってOpenADRがEIをはみ出しているというのは言い過ぎのように思いますが、如何でしょう。
コメントいただき、ありがとうございます。確かに、オブジェクトモデルで言うと、論理オブジェクトモデルから物理オブジェクトモデルに変換する上で、実装上の効率を高める等の目的で論理オブジェクトになかった物理オブジェクトを導入するケースに相当するので、それをもってOpenADR2.0がEI1.0をはみ出しているというのは言い過ぎだと思います。
ただ、このブログでは説明していないのですが、OpenADR2.0とEI1.0の非整合で気になっているところがあるのですが、お気づきでしょうか？
心理的には、そちらが気になって、OPENADR2.0がEI1.0からはみ出しているような図にした次第です。
実を言うと、私はEIはあまり実装レベルの仕様と思っていなかったので、OpenADRとの整合性はあまり気にしていませんでした。どの部分を指しておられるか、ご教示頂けると幸いです。
デマンドレスポンスでは、DRイベントの情報が命だと思いますが、実はEI1.0のDRイベントデータの定義と、OpenADR2.0でのDRイベントデータの定義が食い違っています。EI1.0のRamp PeriodとActive Event Periodの関係と、OpenADR2.0のRampup、Active Stateの関係を見比べてください。
もし、EI1.0を要件定義書、OpenADR2.0の仕様書を、要件定義書のOpenADRプロファイル部分を元に段階的にDRイベントを実装するシステム用の論理設計書と考えた場合、この違いは致命的です。
例えばですが、トランザクティブ・コントロールの実装のための標準を策定する「TrxControlアライアンス」が、EI1.0のOpenADRプロファイルとTeMIXプロファイルをカバーする新たなプロトコル「OpenTrxControl」を開発・普及させた場合、OpenADR2.0のVENは、「OpenTrxControl」のVTNからのDRイベント情報を正しく解釈できないことになります。
いかがでしょうか？
お返事が遅くなり済みません。前述のように私はEI1.0の方はあまり真面目に眺めていなかったので、新谷さんのご指摘を確認するのに手間取りました。結論から言えば、OpenADR2.0はEI1.0を逸脱していないのでは、ということになります。
まず、Ramp Up Period については、OpenADR2.0の定義はEI1.0の定義の引用なので、同じ概念であると認識しています。もしかすると、Ramp Up Period と Active Period の関係を示す図がEI1.0とOpenADR2.0で違っているということを仰っているのかもしれませんが、それ自体は duration が正の場合と負の場合の違いなので、問題ありません。
問題は、Active Event Period と Active State です。実は、EI1.0 と OpenADR2.0 にはこれに類する概念として、Active Interval と Active Period という用語が登場します。この中で、最も定義が明確なのは Active Interval です。Acitive Period は概念的には Active Interval と Ramp Up Period や Recovery Period を包含する概念として定義されていますが、duration の観点からみると、Ramp Up Period や Recovery Period の duration は Active Period とは独立に扱われるべきものとして定義されていると認識しています。
では、EI1.0 の Active Event Period は何かと言えば、私は本当は Active Inerval の誤記ではないかと思います(他の場所では出ません)。一方、Active State は単にActive Interval 期間中のイベントの状態を示しているだけであって、これ自体が特定の期間を定義するものではありません。
以上のように、元々Active Period、Active Interval、Ramp Up Period、Recovery Period の関係は誤解を招きやすういものである上に、用語の誤りなどもあって混乱を招いているのではないかという気がします。
少し穿った見方をすれば、OpenADR2.0で図中に Active Period という言葉を使っていないのは、ややこしいので敢えて避けたのではないかという気もしています。
以上が、知人とも議論しながら至った結論なのですが、如何でしょうか。
どうもありがとうございます。こういう議論がなかなかできないので、自分の考え方を確認するうえで非常にありがたいです。
実は、この件に関しては、結構以前（去年の2月）に気づいて、Jim Zuber氏に指摘したところ、彼は私の意見に納得してくれ、OpenADRアライアンスの多分Profile Wordking Groupにかけあってくれたのですが、「今更そんなことを言われても」というような感触だったという話でした。私の方も、OpenADR2.0aの仕様書がすでにできていてOp@enADR2.0bも固まろうとしている段階で、「まぜかえしても。。。」と思い、そのままにしました。
「まず、Ramp Up Period については、OpenADR2.0の定義はEI1.0の定義の引用なので、同じ概念であると認識しています。もしかすると、Ramp Up Period と Active Period の関係を示す図がEI1.0とOpenADR2.0で違っているということを仰っているのかもしれませんが、それ自体は duration が正の場合と負の場合の違いなので、問題ありません。」という点ですが、数学的にはそうでも、運用者の立場からすると、マイナスの立ち上がり時間というのはあり得ません。そのような形でシステム化するのは、運用面からは「問題がある」と思います。
「少し穿った見方をすれば、OpenADR2.0で図中に Active Period という言葉を使っていないのは、ややこしいので敢えて避けたのではないかという気もしています。」というところは、私もその通りだと思いました。
私が「OpenADR2.0はEI1.0を逸脱している」としたのは、30分以内に指定したMW数の負荷削減を行わなければならない予備力をDRイベントとしてたとえば13時から3時間１MW負荷削減させたい場合を考えると：
EI1.0では、Start Time=13時、Active Event Period=3時間、Ramp Period=-30分
OpenADR2.0では、Event Start=13時、Duration=3時間、Rampup=30分
となり、まさに、ご指摘通りマイナスの数字が出てこない分だけ、運用上OpenADR2.0の方がわかりやすいので、あえてこのようにしたのではないかという解釈です。
もしかすると若干誤解があるかもしれませんが、OpenADR2.0b と Ramp Up Period の定義は現時点では EI1.0 からそのまま引用になっています。従って、duration の正負の扱いも同じです。
この修正は昨年5月に”RampUpとRecoveryの正負の解釈が曖昧のため明確化すべき”という形で課題表に挙げられ、6月の版で修正されたので、恐らく新谷さんのご指摘が効いたのではないでしょうか。
負の値が直観的ではないというご指摘はそうかもしれませんが、プロトコルレベルの話なので割り切ったものと思われます。
最新情報ありがとうございました。OpenADRアライアンスからOpenADR2.0b仕様書として公開されたものは参照していたのですが、OpenADRアライアンスのProfileWGでのやり取りはフォローできておりませんでしたので、そのような課題表で取り上げられていたことは知りませんでした。
それと、9/28日からKNXのカンファレンス参加のため、昨日までドバイにいたので、早々といただいたコメントに返信できず、申し訳ありませんでした。
Pingback: トランザクティブ・エネルギーに関する新たな動き | スマートグリッド | インターテックリサーチ株式会社