このガイドの対象読者は、OpenADR 2.0を利用してユーティリティとダウンストリームエンティティ間でDRイベント関連メッセージを通信するデマンドレスポンス（DR）プログラムの展開を計画しているユーティリティと、その通信交換を容易にする機器のメーカーです。読者は、デマンドレスポンスとOpenADR 2.0（以降、単にOpenADRと呼びます）の両方について基本的な概念を理解していることを前提としています。

OpenADRプロfile 仕様では、DRイベント関連の情報を交換するときに予想される動作が明確に定義されていますが、OpenADRには十分なオプションがあるため、ユーティリティでのサーバー（VTN）とダウンストリームサイトでのクライアント（VEN）の展開はプラグアンドプレイエクスペリエンスではありません。イベント信号、レポート形式、ターゲティングなどのOpenADRの特性は、DRプログラムごとに指定する必要があります。

標準化されたDRプログラムのようなものはありません。各DRプログラムの設計は一意である傾向があり、展開先の地理的地域の構造要件および規制要件に適合します。各DRプログラムには、さまざまなアクターが関与する可能性のある展開シナリオが多数あります。

DRプログラムの設計、展開シナリオ、およびOpenADRの特性のばらつきは、DRの展開の拡大とOpenADRの使用を妨げるものです。この変動性は、ほとんどの場合、スマートグリッドの断片化された複雑な性質を反映しています。

ユーティリティには元が必要ですamp独自のDRプログラム実装のモデルとして使用できるようにするための典型的なDRプログラムのファイル。機器メーカーは、DRプログラムの展開固有の基準ではなく、開発プロセスの一部として相互運用性を検証できるように、一般的なDRプログラムの使用モデルを理解する必要があります。このガイドの目的は、次のようにこれらの両方の目標を達成することです。

これまでに実装された最も人気のあるDRプログラムの共通の特性をモデルにした標準のDRプログラムテンプレートの小さなセットを定義します
アクターと役割が明確に識別された、実際の展開をモデルにした展開シナリオの小さなセットを定義します

各DRプログラムテンプレートに固有のOpenADR特性のベストプラクティスの推奨事項を定義します
公益事業者がビジネスニーズに基づいて有用なDRプログラムテンプレートと展開シナリオを特定するために使用できる決定木を提供する

このガイドでは、一般的なDRプログラムの展開に必要な詳細の大部分に対応する明確な推奨事項の小さなセットを提供することで物事をシンプルに保ち、この推奨事項を使用してプログラムに展開された機器の相互運用性テストを可能にすることに重点を置きます。ガイド。

参考文献

OpenADR プロfile 仕様とスキーマ– www.openadr.org

用語と定義

このドキュメントでは、次の用語と定義が使用されています。

需要応答：価格や可用性信号などの供給条件に応じて顧客の負荷需要を管理するメカニズム

アグリゲーターパーティー –これは、複数のリソースをまとめて、DRプログラム内の単一のリソースとしてDRプログラムパーティに提示するパーティです。
アグリゲーター中間インフラストラクチャ –これは、リソースとグリッド側のエンティティの両方と対話するためにアグリゲーター仲介者によって使用されるデマンド側インフラストラクチャとは別のインフラストラクチャです。
合意：責任と補償の概要を示すDRプログラムで役割を果たす当事者間の契約上の合意

資産 –物理的負荷の特定のコレクションを表すリソースのタイプ。リソースはアセットで構成でき、アセットはリソースの場合もありますが、アセットを複数のアセットまたはリソースにさらに分解することはできません。
関連する：データベースのデバイスの構成を通じて、XNUMXつのエンティティ間のプログラムによる関連付けを提供します。たとえば、VENに関連付けられたリソース
ベースライン：サイトでの調査、検査、および/または計測によって決定された、イベント前の機器またはサイトによる計算または測定されたエネルギー使用量（需要）。

ＢＭＳ –これは、リソースの制御に使用できるビル管理システムです。これは、エネルギー管理システムと呼ばれることもあります。
複合リソース –これは、それぞれが独自の負荷制御手段を持つ複数の物理資産の集合体である特殊なタイプのリソースです。
顧客インセンティブ：DRプログラムに参加するために、需要側のリソースの所有者/集約者に提供されるインセンティブ。

デマンドサイドインフラストラクチャ –これは、DRプログラムに登録されているリソースを収容するインフラストラクチャです。
DRロジック：DR信号を実用的な負荷制御に変換するアルゴリズムまたはロジック。 DR Logicは多くの異なる場所に実装され、場合によっては複数のサブシステムに分散されることに注意してください。
DRプログラムパーティー –これは、グリッドインフラストラクチャを担当し、さらにグリッドの問題を軽減するために使用されるDRプログラムの管理を担当するエンティティです。これは通常、ユーティリティまたはISOです。

登録済み：需要側リソースの所有者/集約者は、DRプログラムへの参加を選択し、DRイベントの対象となる可能性のある特定のリソースに関する情報を提供する場合があります。
イベント活動期間：は、負荷プロの変化が発生する期間です。file DRイベントの一部としてリクエストされています
イベントの制約：顧客がイベントおよび関連する制約（週末または連続した日にイベントがないなど）を受け取ることを期待できる時間枠

イベント日：DRイベントが発生する日。ほとんどのプログラムには、特定のカレンダー期間に許可されるイベント日数に関して制限があります
イベント記述子：プログラム名やイベントの優先度など、イベントに関するメタデータを記述するOpenADRイベントオブジェクトの一部
イベント期間：イベントの長さ。ほとんどのプログラムは、イベントの長さ、およびイベントが発生する可能性のあるXNUMX日の時間に関する制約を定義します。

イベント信号：電気料金や特定のレベルの負荷制限などのイベントに含まれる実用的な情報は、通常、イベントの受信者によって事前にプログラムされた負荷制限の動作をトリガーします。 DRプログラム定義では、使用するイベント信号のタイプを指定する必要があります
イベントターゲティング：DRイベントの対象となる受信者である負荷制限リソース。は、地理的領域、特定のクラスのデバイス、グループ識別子、リソースID、またはその他の識別子である可能性があります。 DRプログラム定義では、特定のリソースをどのようにターゲットにするかを指定する必要があります。
イベント：イベントは、特定の時間に、指定された期間にわたって、ロードシェッドを要求するサイドリソースを要求するユーティリティからの通知であり、イベントに参加する必要がある特定のリソースを指定するターゲティング情報が含まれる場合があります。

ファシリテーター中間インフラストラクチャ –これは、リソース側エンティティとグリッド側エンティティの両方と対話するためにファシリテーター仲介者によって使用されるデマンド側インフラストラクチャとは別のインフラストラクチャです。
ファシリテーター：ユーティリティに代わってDRプログラムの実行の一部またはすべてを管理するサードパーティ
グリッドインフラストラクチャ –これは、DRプログラム関係者が所有または管理するインフラストラクチャです。このインフラストラクチャには、DRプログラムに登録されているリソースにDR信号を送信するために使用されるOpenADRVTNの実装が含まれています。

仲介者 –これは通常、リソースパーティに代わって、DRプログラムへの参加を促進するために機能するパーティです。
負荷制御 –これは、リソースを実際に制御し、特定のロードプロを生成する責任があるリソースに関連するインフラストラクチャです。file.
ロードプロfile 客観的：DRプログラムの開発とイベントの発行の背後にあるこの動機。ピーク負荷を削りたいなど。

通知：イベントの開始時刻より前の期間で、需要側のリソース所有者に保留中のイベントが通知されます
最適な動作：イベントの受信時に需要側のリソース所有者から期待される応答。この応答は、リソースがイベントに参加するかどうかを示すOptInまたはOptOutの形式をとることがあります。
最適な応答：特定のプログラムがイベントに応答して需要側のリソースからの応答を必要とするかどうか、およびそれらの応答は通常何ですか。

オプトサービス：イベントに参加するためのリソースの可用性の一時的な変更を示すために、OpenADRを介して通信されるスケジュール。
前提条件：需要側のリソース所有者がDRプログラムに登録するために満たす必要のある基準。これには、インターバルミーティングの可用性または最小負荷制限容量が含まれる場合があります
プライマリドライバー：DRプログラムを作成し、イベントを発行するためのユーティリティ側の主な動機。「ピーク需要の削減とリソースの適切性」など

プログラム –これらは、リソースが登録されているDRプログラムです。
プログラムの説明：プログラムがどのように機能するかについての説明。このドキュメントで定義されているDRプログラムテンプレートの一部
プログラムの時間枠：DRプログラムを使用している期間は、通常、アクティブです。

レート設計：需要側のリソース所有者がプログラムに参加するように動機付けるために支払われる料金体系またはインセンティブに対する特定の変更
登録サービス：VTNとVENの間の基本的な相互運用性を確立し、VENがユーティリティ顧客アカウントに関連付けられていることを検証するためにOpenADRプロトコルによって使用されるサービス。
レポートサービス：VENがVENにレポートを提供できるようにするためにOpenADRによって使用されるサービス。 DRプログラムは、プログラムのレポート要件を指定する必要があります。

リソースパーティー –これは、DRプログラムに登録される可能性のある需要側のリソースを所有する当事者です。
リソース –これは、DRプログラムに登録されており、ロードプロに何らかの変更を加えることができるエンティティです。file VTNからDR信号を受信したことに応答して。
ターゲットとなる顧客：プロfile 住宅用、工業用、またはおそらく電力消費のレベルに基づいて、特定のDRプログラムに登録する可能性のある需要側のリソースの割合。

ターゲット負荷：受信時に負荷を変更する必要がある需要側のリソース
ヴェン –これは、VTNとの対話に使用されるOpenADR仮想エンドノードです。
ベトナム –これは、DRプログラムに登録されているリソースと対話するために使用されるOpenADR仮想トップノードです。

略語

ＢＭＳ：建物管理システム
C＆I：商業および工業
通信：XNUMXつのエンティティ間の通信
DR：デマンドレスポンス
EMS：エネルギー管理システム
OpenADR：自動デマンドレスポンスを開く
プログラム：デマンドレスポンスプログラムへの参照
ヴェン：仮想エンドノード
ベトナム：仮想トップノード

デマンドレスポンスプログラムの種類

このドキュメントには、以下に示すDRプログラムのテンプレートが含まれています。

1. クリティカルピーク価格：限られた日数または時間に事前に指定された高レートまたは価格を課すことにより、卸売市場価格またはシステムの不測の事態が高い期間中の消費の削減を促進するように設計されたレートおよび/または価格構造。

2. 容量入札プログラム：小売および卸売市場の需要リソースが、ある価格で負荷を削減できるようにするプログラム、または特定の価格でどれだけの負荷を削減できるかを特定できるプログラム。

3. 住宅用サーモスタットプログラム/直接負荷制御：プログラムスポンサーが顧客の電気機器（エアコンなど）を急な通知でリモート制御するデマンドレスポンスアクティビティ。これらのプログラムは、主に住宅または小規模の商業顧客に提供されます。

4. 高速DRディスパッチ/補助サービスプログラム：緊急デマンドレスポンスイベント中の負荷応答に対して顧客にインセンティブ支払いを提供するデマンドレスポンスプログラム。異常なシステム状態（例：ampバルク電気システムの信頼性に悪影響を与える可能性のある送電設備または発電供給の障害を防止または制限するために、自動または即時の手動アクションを必要とするファイル、システムの制約およびローカル容量の制約）。これらのタイプのプログラムは、「補助サービス」と呼ばれることもあります。

5. 電気自動車（EV）DRプログラム：消費者に消費パターンをシフトさせるために電気自動車の充電コストを変更するデマンドレスポンス活動。

6. 分散型エネルギー資源（DER）DRプログラム：分散型エネルギー資源のスマートグリッドへの統合を円滑にするために利用されるデマンドレスポンス活動。

展開シナリオ

DRプログラムを展開する方法は、DRプログラム自体の特性とは多少異なります。次の図は、DRプログラムを展開するさまざまな方法を示しています。次のセクションでは、展開シナリオと、それらが使用される可能性が最も高いDRプログラムとの間の相互参照を提供します。

このセクションの図は、さまざまなシナリオでのエンティティ間の関係を示しています。

ダイレクト1

これは、DRプログラムパーティとリソースパーティの間に直接的な関係がある単純なシナリオです。リソースパーティは、独自のリソースをDRプログラムに登録する責任があり、グリッドインフラストラクチャは、デマンドサイドインフラストラクチャ内にあるVENを介してリソースと直接対話します。さらに、VENはリソースパーティによって所有されており、リソースおよびそのコントローラーから分離されています。 DR信号がVENによって受信されると、通常、負荷制御ロジックは実装されませんが、適切なアクションを実行する負荷コントローラーに信号が転送されるだけです。元ampこのシナリオのファイルには、OpenADR VENを含むゲートウェイをインストールする可能性のあるC＆Iビルが含まれ、そのゲートウェイが信号を受信すると、それを他のプロトコルに変換して、ロードコントローラー自体に転送します。

ダイレクト2

これは、Direct1のシナリオと非常によく似ています。主な違いは、VENがインスタンス化される方法と、VTNとの相互作用が容易になることです。 VENは、DRロジックを実装し、より集中化された場所から複合リソースおよびそれらの多くの異なるロードコントローラーと対話できる集中化されたBMSのようなエンティティでインスタンス化されます。元ampファイルには、建物内のさまざまな負荷（照明、HVAC、産業プロセスなど）を制御するBMSを備えた大きな建物が含まれます。amp集中制御システムを備えた複数の設備を備えている可能性のある用途。

ダイレクト3

このシナリオは、Direct1シナリオと非常によく似ています。主な違いは、VENがリソースとそのロードコントローラーで直接インスタンス化されることです。この場合、DR信号はリソースとそのロードコントローラーに直接送信されます。いわゆる「デバイスへの価格」シナリオは、このカテゴリに分類されます。元ampファイルには、グリッド側のエンティティVTNと直接対話できるVENが組み込まれたHVAC（つまりサーモスタット）などのあらゆる種類の負荷コントローラーが含まれます。

ダイレクト4

これは、Direct1とDirect2のシナリオの種類を組み合わせたものです。主な違いは、複数のVENが、独自のロードコントローラーを持つ複数のアセットで構成される単一の複合リソースに関連付けられていることです。複合リソースを構成する各ロードコントローラは、異なるVENに関連付けることができます。すべてのVENは、複合リソースを所有する同じリソースパーティの管理下にあることに注意してください。このシナリオは、複合リソースを備えているが、Direct2シナリオのような集中型BMSを備えていないデマンドサイドインフラストラクチャを促進するために存在します。元ampファイルには、各フロアに異なる負荷コントローラーがあるが、集中型BMSがない建物が含まれる場合があります。amp各建物の異なるコントローラーで使用しますが、cは使用しませんamp私たちワイドコントローラー。 DRプログラムパーティの観点からは、DR信号をリソースに送信するときにプログラムに登録されているリソースはXNUMXつだけなので、リソースに関連付けられている指定されたVENのそれぞれに同じ信号を送信するだけで済みます。

ファシリテーター1

このシナリオでは、DRプログラムパーティとリソース間の相互作用を促進する仲介者がいます。通常、仲介者はリソースパーティに代わって、リソースの管理を支援します。リソースパーティはDRプログラムパーティと直接的な関係があり、独自のリソースをDRプログラムに登録します。したがって、DRプログラムパーティー view■各リソースパーティは個別のリソースとして機能し、個別にやり取りできます。仲介者の役割は、OpenADRに関連するすべての対話の仲介役として機能することです。したがって、VENはファシリテーター仲介インフラストラクチャ内でインスタンス化されます。このようなインフラストラクチャは多くの場合クラウドベースであり、サービスとしてのソフトウェア（SaaS）としてリソースパーティに提供されます。ファシリテーターのVENがDR信号を受信すると、DR信号を適切なリソースに転送したり、ある種のDRロジックを実装したり、各リソースの負荷コントローラーに負荷制御コマンドを送信したりするなど、さまざまなアクションが発生する可能性があります。元ampこのシナリオのファイルは次のとおりです。

ロードサイド小売店などの大規模な商業チェーンの施設を管理するベンダー。
産業用制御仲介業者。
エネルギーサービス会社（ESCO）
新興のスマート通信サーモスタットベンダーなどのクラウドベースのアプライアンスおよびデバイス管理システム。

アグリゲーター1

このシナリオは、ファシリテーターのシナリオに似ています。主な違いは、アグリゲーターパーティは、リソースパーティではなく、DRプログラムパーティと関係があることです。アグリゲーターパーティは、複数の顧客資産をXNUMXつのリソースに集約し、DRプログラムに登録します。 DRプログラムパーティは、アグリゲータが管理している個々の資産を可視化できません。ファシリテーターと同様に、アグリゲーターにはVENがインスタンス化される独自のインフラストラクチャがあります。違いは、DRシグナルを受信すると、単一のリソースを参照し、アグリゲーターがポートフォリオ内のすべてのアセットに何らかのDRロジックを実装して、DRシグナルで指定された目的を達成することです。

展開シナリオとDRプログラムのマッピング

次の表は、特定のDRプログラムで最も一般的な展開シナリオを示しています。

	展開シナリオ
DRテンプレート	直接1、2、3、4	ファシリテーター1	アグリゲーター1
CPPプログラム	∆	∆
容量入札プログラム			∆
住宅用サーモスタットプログラム		∆
高速DRディスパッチ			∆
電気自動車（EV）DRプログラム	∆	∆
分散型エネルギー資源（DER）DRプログラム	∆	∆

DRプログラムテンプレートの選択

以下は、新しいDRプログラムを実装しようとしているユーティリティに関連する一連の質問です。これは包括的であることを意味するものではありませんが、より適切な問題のいくつかを表しています。これらの質問の目的は、ユーティリティを適切なDRプログラムテンプレートのセットに導くのに役立つことです。

Q：なぜDRをしたいのですか？ DRで軽減しようとしているグリッドの状態または運用上の問題は何ですか？

これは断然最も重要な質問であり、DRプログラムが達成することになっていることの全体的な要件と目的の基礎を形成します。この質問への答えは、需要側がどのようにプロをロードするかを定義しますfile DRプログラムによって形成されることになっています。他のすべての要件は、この質問への回答から流れます。

ピークを剃ろうとしていますか？
アヒルの腹を満たしたいですか？
電気のスポット価格をヘッジしようとしていますか？
グリッドの信頼性に関心がありますか？
グリッド資産を保持しようとしていますか？
などなど。

以下の表は、DRプログラムを開発したいという動機の背景を示しています。

グリッドの信頼性と安全性	頻度と巻tage安定性
	リソースの適切性
	ピーク容量
	Ramping
	不測の事態
エネルギーの調達	スポット市場価格
エネルギーの調達	価格裁定取引
資産運用管理	被害防止
	メンテナンスの削減
	寿命延長
キャパシティ管理	経済的利益
キャパシティ管理	緊急管理
環境	ネガワット
環境	クリーンエネルギー

Q：このプログラムには既存のDRプログラムまたは料金がすでに設定されていますか？

多くの場合、プログラムのルールは料金表に明示的に記載されています。

Q：このプログラムでターゲットにしている需要側の市場セグメントは何ですか？

これは、イベント内のリソースのターゲティングとシグナルのタイプを決定するのに役立つ場合があります。

居住の
大規模なC＆I
小さなC＆I
農業
水管理
電気自動車
などなど

Q：特定のタイプの負荷をターゲットにしようとしていますか？

サーモスタット
電気自動車
Agポンプ
等

Q：展開モデルは何ですか？

この質問への回答は、プログラム内でリソースがどのように定義されるかに影響を与え、それらのリソースがイベント内でどのようにターゲットにされるかを決定する可能性があります。

顧客に直接
アグリゲーターやファシリテーターなどの仲介者を通じて
お客様は、独自のVEN機器の調達と展開に責任がありますか？
等

Q：需要側の負荷とどのレベルの特異性で相互作用したいですか？

この質問は、展開モデルにいくらか関連しており、プログラム内のリソースをどのように定義して対象にするかを決定します。これは、最も重要で、おそらく複雑な質問のXNUMXつです。

個々のリソースと対話する
ファシリテーターまたはアグリゲーターを介して、背後にあるリソースを指定せずに対話します
ファシリテーターまたはアグリゲーターを介して対話し、その背後にあるリソースをディスパッチする必要があることを指定します
リソースを指定するための属性として場所を使用する
ある種のユーティリティ定義のグループ化メカニズムを使用して、リソースを指定します
サーモスタットなどの個々の資産をターゲットにする
リソースをまったく使用せずに対話し、DRイベントをブロードキャストするだけです
等

Q：顧客のロードプロに影響を与えるためにどのようなインタラクションパターンを採用しますかfiles?

この質問は、プログラムの参加者に送信されるDR信号のタイプを決定します。

インセンティブ（動的価格設定など）
ロードディスパッチ（例：補助サービス）
直接負荷制御
一般的なイベント信号
等

Q：プログラムの一般的なリソーススケジューリング属性は何ですか？

イベントが呼び出される可能性のある日時
イベントの頻度
イベントの期間
イベントの伝播に許容される待機時間
等

Q：プログラム内のリソースの可用性はどのように決定されますか？

厳格なプログラムルールによる
リソースによって行われるいくつかの指名または入札プロセスの一部として
オプトイン/オプトアウトは許可されていますか？
等

Q：リソースのパフォーマンスにはどのような種類の可視性が必要ですか？

これは非常に幅広い質問であり、DRプログラムのリソースからどのタイプの情報がフィードバックされるかを決定します。一般に、これにより、必要なレポートのタイプが決まります。

オンライン/オフライン
使用法（現在および/または過去）
負荷応答の可能性
負荷の可用性
負荷/資産の状態（現在および/または履歴）
などなど。

デマンドレスポンスプログラムテンプレート

クリティカルピーク価格設定プログラム（CPP）

CPPDRプログラムの特徴


ロードプロfile 客観的	-ピーク需要の削減
プライマリドライバー	-設備投資の削減とエネルギーコストの削減
プログラムの説明	電力会社が卸売市場の高値や電力システムの緊急事態を観察または予測すると、指定された期間（たとえば、暑い夏の平日の午後3時から午後6時）に重大なイベントが発生する可能性があります。上げた。
顧客インセンティブ	プログラムに参加するインセンティブとして、ピーク時以外の時間帯に割引エネルギー価格が顧客に提供される場合があります。
レート設計	CPPは、エネルギー消費の重要なピーク時に料金が上昇する価格プログラムです。通常、CPPレートは、フラット、ティアード、またはTOUの基本レートへの加算または乗数です。
ターゲットとなる顧客	-住宅またはC＆I
目標荷重	-どれか
前提条件	-顧客はインターバルメータリングを持っている必要があります -C＆Iの顧客は需要基準を満たさなければならない場合があります
プログラムの時間枠	-場合によっては一年中かもしれませんが、通常、ピークエネルギー消費が発生する年の月にまたがります。
イベントの制約	-通常、休日を除く月曜日から金曜日まで、連続した日のイベントが通常許可されます
イベント日	-通常、年間9〜15
イベント期間	-通常、4日の最大エネルギー消費時間中の6〜XNUMX時間の範囲のすべてのイベントについて、一定の時間枠内。
通知	-通常、前日
最適な動作	-通常、顧客はイベントに参加する必要はありません
認証イベント	-通常はありません

CPPプログラムのOpenADR特性

イベント信号	–CPPイベントの価格設定への影響にマッピングされたレベル1から3のSIMPLEシグナル。 CPPプログラムに単一の価格設定コンポーネントがある場合は、レベル1にマップする必要があります。複数の価格設定コンポーネントがあるCPPプログラムの場合、最小の価格コンポーネントをレベル1にマップし、他の価格コンポーネントをレベル2および3に段階的にマップする必要があります。価格への影響の。 -展開がBプロをサポートしている場合file VEN、 SIMPLE信号に加えて、ELECTRICITY_PRICE信号が含まれる場合がありますプログラムの性質に応じて、priceRelative、priceAbsolute、またはpriceMultiplierのタイプのペイロード内。例については付録Aを参照してくださいampレ。
最適な応答	-イベントを送信するVTN oadrResponseRequired要素を「always」に設定する必要があります、VENにoptInまたはoptOutで応答するように要求する -CPPプログラムへの参加は「ベストエフォート」の演習であるため、参加の意思を示す礼儀の可用性を超えて、オプトインまたはオプトアウトする正式な意味はありません。私たちはそれをお勧めしますお客様が特定のオーバーライドアクションを実行していない限り、VENはoptInで応答します. -oadrCreateOptペイロードは、通常、イベントに参加しているリソースを限定するために使用されません。
イベント記述子	-行事優先度は1に設定する必要がありますプログラムルールまたはVTN構成で特に指定されていない限り、 –テストイベントは通常使用されません CPPプログラムで。ただし、許可されている場合は、testEvent要素を「true」に設定してテストイベントを示す必要があります。この要素で追加のパラメーター化された情報が必要な場合は、この追加情報をスペースで区切って「true」を続けることができます。
イベント活動期間	– EIRampUp、eiRecovery、tolerance要素は通常使用されません
ベースライン	–ベースラインは通常、イベントペイロードに含まれていません
イベントターゲティング	-CPPプログラムは通常、特定の顧客のリソースを区別しません。ターゲティングは通常、venIDを指定します、VENに関連するすべてのリソースが参加する必要があることを示します。またはすべてのresourceIDのリスト VENに関連付けられています。
レポートサービス	–テレメトリレポートは通常使用されません CPPプログラムには絶対に必要というわけではないからです。例については付録Bを参照してくださいampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。

オプトサービス	–Optサービスの使用一時的な可用性のスケジュールを伝達する通常は使用されません CPPプログラムの一部として。ただし、一部の展開では、このサービスを使用して、可用性の欠如を示す顧客が利用可能なイベント日を保持することができます。
登録サービス	ポーリング間隔典型的な前日CPPプログラムのためにVTNによって要求された XNUMX時間にXNUMX回以上の頻度である必要はありません。ただし、ハートビート検出にポーリングを使用するには、より頻繁なポーリングが必要になる場合があります。

容量入札プログラム

容量入札DRプログラムの特徴

ロードプロfile 客観的	-ピーク需要の削減とリソースの適切性
プライマリドライバー	-設備投資の削減とエネルギーコストの削減
プログラムの説明	容量入札プログラムは、ISO /ユーティリティによって使用され、アグリゲーターまたは自己集約された顧客から事前にコミットされた負荷制限容量を取得します。この事前にコミットされた負荷制限容量は、ISO /ユーティリティが高い卸売市場価格、電力システムの緊急事態を観察または予測するとき、または指定された期間中にDRイベントを呼び出すことによって通常のエネルギーリソース使用率の一部として使用されます。各アグリゲーターは通常、このプログラムの一部として行われた容量のコミットメントを満たすために、独自のデマンドレスポンスプログラム、顧客獲得、およびイベント通知を設計する責任があることに注意してください。
顧客インセンティブ	アグリゲーター/顧客はXNUMX種類のインセンティブを受け取ります。まず、将来の時間枠でDRイベントに使用できる特定の負荷制限容量を保持するための容量支払いを受け取ります。第XNUMXに、将来の時間枠内にイベントが呼び出された場合、イベントの期間中の負荷制限に対してエネルギー支払いが行われる可能性があります。
レート設計	プログラムの参加者は、将来の時間枠の間に利用可能として保持することをいとわない負荷制限容量を示す「容量指名」入札を行います。入札には、アグリゲーター/顧客がベースライン値を下回る負荷削減に対して受け入れる意思のあるインセンティブも含まれる場合があります。ユーティリティ市場では、容量のコミットメントは通常、翌暦月のものですが、ISO市場でははるかに長い時間枠が使用されます。容量指定の一部として、お客様は、通知の前日または当日、およびイベント期間ウィンドウ（1〜4時間、2〜6時間など）を含むいくつかの特性から選択できる場合があります。時間枠内に呼び出されたイベントがない場合でも、この事前コミットメントに対して容量の支払いが顧客に行われます。時間枠内にイベントが呼び出された場合、顧客はベースラインに関連してロードシェッドのエネルギー支払いを受け取ることがありますが、イベントが呼び出されたときに事前にコミットされたロードシェッド容量より少ない場合はペナルティが適用される場合があります。
ターゲットとなる顧客	-アグリゲーターと自己集約型C＆Iの顧客
ターゲット負荷	- どれか

前提条件	-顧客はインターバルメータリングを持っている必要があります -C＆Iの顧客は、需要または入札基準を満たさなければならない場合があります
プログラムの時間枠	-どんなときも
イベントの制約	-通常、休日を除く月曜日から金曜日まで、連続した日のイベントが通常許可されます
イベント日	-通常、30か月あたり最大XNUMX時間
イベント期間	-通常、1日のエネルギー消費量が最も多い時間帯のすべてのイベントについて、一定の時間枠内にあります。）イベントの期間は、8〜XNUMX時間の範囲の設定、またはプログラムの設計で指定された顧客のキャパシティコミットメントによって異なります。
通知	-顧客のキャパシティコミットメントの好みまたはプログラムの設計に応じて、前日または前日
最適な動作	-通常、顧客は、事前にコミットされた負荷制限容量があるため、イベントにオプトインします。
認証イベント	-通常はXNUMX年にXNUMX回（テスト）

容量入札プログラムのOpenADR特性

イベント信号	–負荷制限の量にマップされたレベル1から3のSIMPLE信号。プログラムが単一レベルのロードシェッドのみをサポートする場合は、レベル1にマップする必要があります。複数レベルのロードシェッドを持つプログラムの場合、通常の操作からの最小の変更をレベル1にマップし、ロードシェッド値を負荷制限の程度が増加するレベル2および3。 -展開がBプロをサポートしている場合file VEN、 SIMPLE信号に加えて、BID_LOADおよび/またはBID_PRICE信号が含まれる場合があります。セットポイントと価格の信号タイプ、およびそれぞれpowerRealとcurrencyPerKWの単位を持つペイロード内。 BID_LOADは、アグリゲーター/顧客によって入札された容量量までの要求された負荷を反映し、BID_PRICEは、アグリゲーター/顧客によるインセンティブ入札を反映します。例については付録Aを参照してくださいampレ。
最適な応答	-イベントを送信するVTN oadrResponseRequired要素を「always」に設定する必要があります、VENにoptInまたはoptOutで応答するように要求する -アグリゲーター/顧客には事前にコミットされた容量があるため VENはoptInで応答する必要があります。イベントに応じてオプトアウトが送信される場合がありますが、これは非公式の可用性の表示であり、イベントの正式なオプトアウトではありません。 -の oadrCreateOptペイロードは通常使用されません通常、負荷は単一の集約されたエンティティであるため、イベントに参加しているリソースを限定します。
イベント記述子	-行事優先度は1に設定する必要がありますプログラムルールまたはVTN構成で特に指定されていない限り、 –テストイベントを使用できますキャパシティビッディングプログラムで。それらが許可されている場合は、testEvent要素を「true」に設定してテストイベントを示す必要があります。この要素で追加のパラメーター化された情報が必要な場合は、この追加情報をスペースで区切って「true」を続けることができます。
イベント活動期間	– EIRampUp、eiRecovery、tolerance要素は通常使用されません
ベースライン	–ベースラインは通常、イベントペイロードに含まれていませんこのデータは通常、イベントの開始時には利用できないためです。ただし、ユーティリティとアグリゲータ/顧客の両方が view 有用なものとしてイベントにベースライン情報を含めること。
イベントターゲティング	-容量入札プログラムは通常、特定の顧客のリソースを区別しません。ターゲティングは通常、venIDを指定します、VENに関連するすべてのリソースが参加する必要があることを示します。または、集約された負荷を表すresourceIDが含まれています VENに関連付けられています。
レポートサービス	ISO容量入札プログラムには通常、TELEMETRY_USAGEレポートが必要です powerRealデータポイントを使用します。 exを参照してくださいamp付録Aのファイル。ユーティリティキャパシティビッディングのテレメトリレポートは通常必要ありません. テレメトリレポートにはBプロが必要であることに注意してくださいfile VEN。例については付録Bを参照してくださいampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。
オプトサービス	–Optサービスの使用一時的な可用性のスケジュールを伝達する通常は使用されません顧客が可用性を事前に確約しているため、容量入札プログラムの一部として。ただし、このサービスは、参加者が機器の故障などの酌量すべき理由で可用性の欠如を示すための非公式な方法として役立つ場合があります。
登録サービス	ポーリング間隔典型的な前日プログラムのためにVTNによって要求された XNUMX時間にXNUMX回以上の頻度である必要はありません。ただし、ハートビート検出または当日プログラムにポーリングを使用するには、より頻繁なポーリングが必要になる場合があります。

住宅用サーモスタットプログラム

このプログラムは、デマンドレスポンス信号が信号の受信と実行される特定の負荷制限アクションの間に抽象化レイヤーを使用せずに、負荷制限リソースの動作を直接変更する直接負荷制御（DLC）を表しています。

住宅用サーモスタットDRプログラムの特徴

ロードプロfile 客観的	-ピーク需要の削減
プライマリドライバー	-設備投資の削減とエネルギーコストの削減
プログラムの説明	-電力会社が高い卸売市場価格または電力システムの緊急状態を観察または予測すると、指定された期間（たとえば、暑い場所で午後3時から午後6時）にわたって顧客のプログラム可能な通信サーモスタット（PCT）の動作を変更するイベントを開始する場合があります。夏の平日）エネルギー消費を削減するために。 -イベントに応じたPCT動作の変更は、イベント期間中の温度設定値の単純な変更、またはイベントの顧客の快適性への影響を最小限に抑える、予冷を含むより複雑な一連の変更である可能性があります。レベル。
顧客インセンティブ	-インセンティブにはXNUMXつの一般的な形式があります。まず、DRプログラムに登録するインセンティブとして、顧客に無料のPCTが提供されるか、顧客が購入したPCTに対して割引/リベートが提供される場合があります。第二に、顧客は、プログラムへの継続的な登録に対して継続的な年次給付金を受け取る場合があります。あまり一般的ではないのは、イベント中の実際のエネルギー削減に基づいて顧客に支払われる継続的なインセンティブです。
レート設計	-主にインセンティブプログラム。顧客は、DRプログラムに登録するための割引または無料のPCTを受け取ります。一部のプログラムでは、イベント中のエネルギー削減に基づいて、定期的な給付金またはインセンティブの支払いを行う場合があります。
ターゲットとなる顧客	-居住の
目標荷重	-空調設備
前提条件	-顧客はプログラム登録の一部としてPCTを受け取るため、通常はありません
プログラムの時間枠	-場合によっては一年中かもしれませんが、通常、ピークエネルギー消費が発生する年の月にまたがります。
イベントの制約	-通常、休日を除く月曜日から金曜日まで、連続した日のイベントが通常許可されます。
イベント日	-通常、年間9〜15
イベント期間	-イベントはいつでも発生する可能性があり、期間は2〜4時間ですが、通常、イベントはXNUMX日のエネルギー消費量が最も多い時間帯に発生します。
通知	-通常は10日先ですが、一部のプログラムでは通知時間がXNUMX分と短い場合があります。
最適な動作	-お客様はイベントに参加する必要はありませんが、イベントを無効にするアクションを実行したり、イベント中に温度を手動で調整したりしない限り、イベントに自動的にオプトインされます。
認証イベント	-通常はありません

住宅用サーモスタットプログラムのOpenADR特性

イベント信号	–PCT温度設定値オフセットまたはサーモスタットサイクリングパーセンの変化にマッピングされたレベル1〜3のSIMPLE信号tage . 住宅用サーモスタットプログラムに単一のオフセット/サイクリングコンポーネントがある場合は、レベル1にマッピングする必要があります。複数のオフセット/サイクリングコンポーネントがあるプログラムの場合、通常の操作からの最小の変化をレベル1にマッピングし、他のオフセット/サイクリング値を設定する必要があります。負荷制限の影響の程度が増加するレベル2および3にマップされます。 -展開がBプロをサポートしている場合file VEN、 SIMPLE信号に加えて、LOAD_CONTROL信号を含めることができます。ペイロードでタイプの x-loadControlLevelOffsetまたはx-loadControlCapacity 希望の温度設定値オフセットまたはサーモスタットサイクリングパーセンを指定しますtageそれぞれ。が x-loadControlLevelOffsetsignalTypeを利用するペイロードで使用される「温度」のユニットタイプオフセットの摂氏または華氏を示します。例については付録Aを参照してくださいampレ。
最適な応答	-イベントを送信するVTN oadrResponseRequired要素を「always」に設定する必要があります、VENにoptInまたはoptOutで応答するように要求する – お客様が特定のオーバーライドアクションを実行していない限り、VENはoptInで応答する必要があります. -の oadrCreateOptペイロードはVENによって使用される場合がありますイベントへのリソースの参加を認定するため。たとえば、イベントは、別々のHVACシステムを制御するXNUMXつのサーモスタットのresourceIDをターゲットにする場合があります。お客様がHVACシステムのXNUMXつのみがイベントに参加できると決定した場合、これはoadrCreateOptペイロードを使用してVTNに伝達されます。 oadrCreateOptペイロードはBproでのみサポートされていることに注意してくださいfile VEN
イベント記述子	-行事優先度は1に設定する必要がありますプログラムルールまたはVTN構成で特に指定されていない限り、 –テストイベントは通常使用されません住宅用サーモスタットプログラムで。ただし、許可されている場合は、testEvent要素を「true」に設定してテストイベントを示す必要があります。この要素で追加のパラメーター化された情報が必要な場合は、この追加情報をスペースで区切って「true」を続けることができます。
イベント活動期間	–ランダム化は通常、公差要素を使用した住宅用サーモスタットイベントに使用されます – EIRampUp要素とeiRecovery要素は通常使用されません
ベースライン	–ベースラインは通常、イベントペイロードに含まれていません
イベントターゲティング	-住宅用サーモスタットプログラムは、PCTによって制御されるHVACリソースを対象としています。ターゲティングは通常、resourceIDを指定します VENに関連するHVACシステム（つまりサーモスタット）のまたは、イベント信号デバイスクラスターゲットがサーモスタットに設定されたvenID
レポートサービス	–テレメトリレポートは通常使用されません住宅用サーモスタットプログラムには絶対に必要というわけではないので例については付録Bを参照してくださいampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。
オプトサービス	–Optサービスの使用一時的な可用性のスケジュールを伝達する通常は使用されません CPPプログラムの一部として。
登録サービス	ポーリング間隔典型的な前日住宅用サーモスタットプログラムについてVTNから要求された XNUMX時間にXNUMX回以上の頻度である必要はありません。ただし、心拍検出にポーリングを使用すると、通知時間が大幅に短い住宅用サーモスタットプログラムと同様に、より頻繁なポーリングが必要になる場合があります。

高速DRディスパッチ

高速DRディスパッチプログラムの特徴

ロードプロfile 客観的	-「リアルタイム」で負荷応答を実現するためにリソースをディスパッチします
プライマリドライバー	-グリッドの信頼性と補助サービス
プログラムの説明	高速DRは、ISO /ユーティリティによって使用され、「リアルタイム」で事前にコミットされた負荷応答を取得します。この事前にコミットされた負荷応答は、グリッドの安定性と整合性を維持するために即時のアクションを必要とする条件を観察するときに、ISO /ユーティリティによって利用されます。リアルタイムとは、通常、リソースが予約として使用されるリソースの10分から、規制目的で使用されるリソースの2秒までの範囲の遅延でディスパッチされることを意味します。負荷応答のサイズは、グリッド状態の緩和に違いをもたらすのに十分な大きさである必要があります。したがって、リソースは通常非常に大きく、集約されたリソースの一部としてアグリゲーターによって管理されることがよくあります。補助サービスに参加する資格を得るリソースの負荷応答の最小サイズは、通常、約500 kWですが、一部のプログラムでは100kWまで低くすることができます。リソースが予備として使用される場合、通常は負荷を減らす（つまり、流す）ように求められますが、規制目的で使用されている場合は、負荷を増やすまたは減らすためにディスパッチされる場合があります。
顧客インセンティブ	アグリゲーター/顧客は通常、XNUMX種類のインセンティブを受け取ります。まず、将来の時間枠の間にDRイベントで利用可能な特定の量の負荷応答をコミットして利用可能にするための支払いを受け取ります。負荷応答の量、可用性の時間枠、および支払われる金額は、通常、アグリゲーター/顧客によって設定されます。次に、将来の時間枠内にイベントが呼び出された場合、イベント期間中の負荷応答の量に基づいて支払いが行われます。
レート設計	プログラムの参加者は、将来の時間枠の間に利用可能にすることをいとわない負荷応答を示す入札を提出します。入札には通常、アグリゲーター/顧客が負荷応答に対して受け入れる意思のある支払いも含まれます。ユーティリティ/ ISO市場では、入札は通常、前日またはコミットメントが行われている期間のいずれかの日に提出されます。市場での認定と登録の一環として、さまざまなパフォーマンスエンベロープパラメータがrなどのリソースに関連付けられています。amp レートと最小および最大動作限界。このようなパラメータは、それがどのようにディスパッチされるかを決定します。参加者の入札が受け入れられた場合、時間枠内に呼び出されたイベントがない場合でも、事前コミットメントの支払いが顧客に行われる場合があります。時間枠内にイベントが呼び出された場合、顧客はイベント中のパフォーマンスに対して追加の支払いを受け取る場合があります。このようなパフォーマンスベースの支払いは、エネルギー量、電力、リソースがディスパッチ指示にどれだけ厳密に従うか、および負荷プロの量を反映する「マイレージ」支払いを含む多くの要因に基づく場合があります。file イベント中に変更する必要がありました。エネルギーや電力などのこれらのパラメータの一部は、ベースラインを基準にしている場合があります。
ターゲットとなる顧客	-アグリゲーターと自己集約型C＆Iの顧客
ターゲット負荷	–リアルタイムのディスパッチに対応できるもの。

前提条件	-顧客はインターバルメータリングを持っている必要があります -負荷応答の最小サイズ要件を満たす必要があります -リアルタイムのディスパッチに応答できる必要があります -通常、現在の負荷応答を示すリアルタイムテレメトリを提供する必要があります
プログラムの時間枠	-どんなときも
イベントの制約	-なし
イベント日	-なし
イベント期間	-通常は短い（30分未満）が、いずれの場合も、参加者が入札を送信したときにリソースを利用可能にした時間枠を超えることはありません。
通知	-なし
最適な動作	-事前にコミットされた負荷応答がある場合、顧客はデフォルトでイベントにオプトインします
認証イベント	-通常はXNUMX年にXNUMX回（テスト）

容量入札プログラムのOpenADR特性

イベント信号	–負荷応答の量にマップされたレベル1〜3のSIMPLE信号。プログラムが単一レベルの負荷応答のみをサポートする場合は、レベル1にマップする必要があります。複数レベルの負荷応答があるプログラムの場合、通常の操作からの最小の変化をレベル1にマップし、負荷制限値をにマップする必要があります。負荷応答の程度が増加するレベル2および3。 -展開がBプロをサポートしている場合file VEN、 SIMPLE信号に加えて、LOAD_DISPATCH信号の形式のディスパッチが含まれる場合があります。セットポイントまたはデルタの信号タイプ、およびpowerRealの単位を持つペイロード内。この信号は、負荷の目的の「動作点」を表し、リソースの現在の動作点からのmWの絶対量（つまり設定値）またはmWの相対数（つまりデルタ）として表すことができます。例については付録Aを参照してくださいampレ。
最適な応答	-イベントを送信するVTN oadrResponseRequired要素を「always」に設定する必要があります、VENにoptInまたはoptOutで応答するように要求する -アグリゲーター/顧客には事前にコミットされた容量があるため VENはoptInで応答する必要があります。イベントに応じてオプトアウトが送信される場合がありますが、これは非公式の可用性の表示であり、イベントの正式なオプトアウトではありません。 -の oadrCreateOptペイロードは通常使用されません通常、負荷は単一の集約されたエンティティであるため、イベントに参加しているリソースを限定します。
イベント記述子	-行事優先度は1に設定する必要がありますプログラムルールまたはVTN構成で特に指定されていない限り、 –テストイベントを使用できます、特にリソースの登録および認定中。それらが許可されている場合は、testEvent要素を「true」に設定してテストイベントを示す必要があります。この要素で追加のパラメーター化された情報が必要な場合は、この追加情報をスペースで区切って「true」を続けることができます。
イベント活動期間	– 公差要素は使用されません。 eiRampUp期間とeiRecovery期間は、通常、登録時にリソースのパラメーターの一部であり、使用できます。ディスパッチの性質上、オープンエンドである可能性があり、したがってイベントの終了時間がない場合があります。
ベースライン	–ベースラインは通常、イベントペイロードに含まれていませんこのデータは通常、イベントの開始時には利用できないためです。ただし、ユーティリティとアグリゲータ/顧客の両方が view 有用なものとしてイベントにベースライン情報を含めること。
イベントターゲティング	-容量入札プログラムは通常、特定の顧客のリソースを区別しません。ターゲティングは通常、venIDを指定します、VENに関連するすべてのリソースが参加する必要があることを示します。または、集約された負荷を表すresourceIDが含まれています VENに関連付けられています。
レポートサービス	高速DRプログラムには通常、TELEMETRY_USAGEレポートが必要です powerRealデータポイントを使用します。使用状況レポートは、リソースの現在の動作点を示し、ユーティリティ/ ISOが使用して、送信されたディスパッチ命令にリソースがどれだけ厳密に従っているかを判断します。場合によっては、テレメトリにvolなどの他のデータポイントが含まれることがあります。tageリソースが何らかの形のストレージである場合の読み取り値と充電状態（つまりエネルギー）。場合によっては、レポートの頻度が2秒ごとに高くなることがあります。テレメトリレポートにはBプロが必要であることに注意してくださいfile VEN。例については付録Aを参照してくださいampレ。例については、付録Bも参照してください。ampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。
オプトサービス	–Optサービスを使用して一時的な可用性を伝達するスケジュール通常は使用されません顧客が可用性を事前にコミットしているため。ただし、このサービスは、参加者が機器の故障などの酌量すべき理由で可用性の欠如を示すための非公式な方法として役立つ場合があります。
登録サービス	リアルタイムディスパッチのレイテンシ要件が低いためプッシュインタラクションパターンのみが使用されます.

住宅用電気自動車（EV）使用時間（TOU）プログラム

住宅用EVTOUプログラムの特徴

ロードプロfile 客観的	電気自動車の充電コストを変更して、消費者に消費パターンをシフトさせる料金体系。
プライマリドライバー	住宅のエネルギー使用量は夕方にピークに達します。 EVの充電には4〜8時間かかるため、負荷のピークをシフトするために数時間遅れることがあります。
プログラムの説明	電気自動車をお持ちのお客様は、電気自動車の使用時間（EV-TOU）レートにサインアップして、深夜から午前5時までのようなオフピーク時に車両を充電するためのより低いレートを受け取ることができます。EV-TOUレートは次のとおりです。電力需要が最も高い日中の電力使用を制限するよう顧客に奨励するために提供されます。
顧客インセンティブ	EVのより安価な充電。
レート設計	正午のピーク、朝と夕方のミッドピーク、午前12時から午前5時のオフピークのTOU
ターゲットとなる顧客	ロードプロのEVオーナーfile それは夕方にピークに達します。
ターゲット負荷	EV充電器
前提条件	お客様はスマートメーターとEVを持っている必要があります
プログラムの時間枠	通年
イベントの制約	なし
イベント日	毎日、または平日のみ
イベント期間	5～8時間
通知	顧客には毎月の請求書で価格帯が通知され、VTNは前日にイベント信号を送信します。
最適な動作	料金支払者は、ユーティリティで通常行うように料金プランを変更できます。
認証イベント

住宅用EVTOUプログラムのOpenADR特性

イベント信号	ELECTRICITY_PRICEシグナルと実際の価格階層、および2.0aVENによる参加を可能にするSIMPLEシグナル例については付録Aを参照してくださいampレ。
最適な応答	常にVENによるオプトイン
イベント記述子	週にXNUMXつのイベント、各価格帯のイベント間隔
イベント活動期間	少なくとも24時間の通知を使用する必要があります。各イベント間隔は、TOUレート階層をキャプチャする必要があります
ベースライン	該当なし
イベントターゲティング	高度なターゲティングは必要ありません。VENレベルのターゲティングのみです。
レポートサービス	レポートは必要ありません。すべてのデータはメーターから取得できます。例については付録Bを参照してくださいampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。
オプトサービス	Optサービスは、このプログラムタイプには関係ありません。
登録サービス	消費者は、価格設定シグナルを受信するためのユーティリティをVENに事前にプロビジョニングします。

公共ステーション電気自動車（EV）リアルタイム価格設定プログラム

公共ステーションEVRTPプログラムの特徴

ロードプロfile 客観的	電気自動車の充電コストを変更して、ピーク価格の現実を消費者にシフトするデマンドレスポンス活動。
プライマリドライバー	電気の価格はXNUMX日で変動します。このプログラムは、充電料金と電気料金をより効率的に一致させることを目的としています。
プログラムの説明	公共の充電器は、職場、公共の駐車場、小売店に存在する可能性があります。このプログラムは、潜在的な充電器がプラグインする前にリアルタイムの価格を中継するため、充電器が車を充電するかどうかについて情報に基づいた決定を下すことができます。
顧客インセンティブ	オフピーク時のより安価な充電。
レート設計	価格はhoを変えることができますurly、ただし、顧客が車のプラグを差し込むことを選択すると、充電期間中の料金が設定されます。
ターゲットとなる顧客	家から離れている間に充電する必要があるEVを持っている人。
ターゲット負荷	公共EV充電器
前提条件	EV充電器は、インターネットに接続され、OpenADR2.0b認定を受けているか、OpenADR2.0bVENゲートウェイに接続されている必要があります。
プログラムの時間枠	通年
イベントの制約	なし
イベント日	毎日、または平日のみ
イベント期間	1時間以上
通知	車を接続することを選択すると、顧客に実勢レートが通知されます。
最適な動作	お客様は、請求しないことを決定することでオプトアウトすることができます。
認証イベント

公共ステーションEVRTPプログラムのOpenADR特性

イベント信号	ELECTRICITY_PRICEは価格でシグナルを送ります。例については付録Aを参照してくださいampレ。
最適な応答	常にVENによるオプトイン
イベント記述子	イベントは連続している必要があり、XNUMXつの間隔が含まれている必要があります。
イベント活動期間	少なくとも1時間の通知を使用する必要がありますが、ユーティリティは前日の通知を使用することを選択できます。
ベースライン	該当なし
イベントターゲティング	高度なターゲティングは必要ありませんが、ターゲティングを使用して、特定の変圧器、フィーダー、または地理的領域に価格を送信できます。
レポートサービス	レポートは必要ありませんが、必要に応じて使用できます。例については付録Bを参照してくださいampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。
オプトサービス	Optサービスは、このプログラムタイプには関係ありません。
登録サービス	充電ステーションのベンダーは、ユーティリティのVTNを使用してデバイスをプロビジョニングします。

分散型エネルギー資源（DER）DRプログラム

以下のプログラムの説明は架空のものであり、ユーティリティの顧客がDERストレージリソースを利用してリアルタイム価格設定（RTP）プログラムなどのDRプログラムに参加する方法を説明する研究論文（Rishの論文を参照）に基づいています。

分散型エネルギー資源（DER）プログラムの特徴

ロードプロfile 客観的	分散型エネルギー資源のスマートグリッドへの統合を円滑にするために利用されるデマンドレスポンス活動。
プライマリドライバー	-設備投資の削減とエネルギーコストの削減
プログラムの説明	エネルギーを収穫して貯蔵できるDERリソースをお持ちのお客様は、最初に貯蔵されたエネルギーリソースを利用し、次に負荷制限戦略を実装することで、高価格期間中にグリッドから電力を購入するコストを最小限に抑えることができます。
顧客インセンティブ	PVまたはその他の手段で生成された蓄積エネルギーを活用し、負荷制限戦略を実装することにより、電気料金が高いときにコストを管理する機能
レート設計	電気料金は、卸売市場の価格や、時間帯、季節、気温の関数として変化する料金によって異なります。
ターゲットとなる顧客	エネルギー貯蔵資源をお持ちのお客様
ターゲット負荷	どれでも
前提条件	エネルギー貯蔵資源
プログラムの時間枠	いつでも
イベントの制約	なし
イベント日	毎日
イベント期間	24時間
通知	先日
最適な動作	N / A –ベストエフォートプログラム
認証イベント	なし

分散型エネルギー資源（DER）のOpenADR特性

イベント信号	ELECTRICITY_PRICEは、24時間にわたって24のXNUMX時間間隔の価格でシグナルを送信します。この信号にはBプロが必要ですfile。このプログラムは、AプロのSIMPLEシグナリングには適していません。file VEN。例については付録Aを参照してくださいampレ。
最適な応答	-イベントを送信するVTN oadrResponseRequired要素を「never」に設定する必要があります、VENが応答するのを防ぎます。
イベント記述子	-行事優先度は1に設定する必要がありますプログラムルールまたはVTN構成で特に指定されていない限り、
イベント活動期間	24時間間隔で1時間、前日通知
ベースライン	該当なし
イベントターゲティング	venID以外の高度なターゲティングは必要ありません
レポートサービス	レポートは必要ありません例については付録Bを参照してくださいampこのタイプのプログラムに適用できる可能性のあるユーティリティパイロットからのレポートのファイル。
オプトサービス	未使用
登録サービス	ポーリング間隔典型的な前日tプログラムのためにVTNによって要求された XNUMX時間にXNUMX回以上の頻度である必要はありません。ただし、心拍検出にポーリングを使用すると、通知時間が大幅に短い住宅用サーモスタットプログラムと同様に、より頻繁なポーリングが必要になる場合があります。

– Sampファイルデータとペイロードテンプレート

次の表とXMLペイロードamplesは実装者に具体的な例を提供しますampこのドキュメントのDRテンプレートの実装方法のファイル。次の名前空間プレフィックスがペイロードexで使用されますampレ：

xmlns：oadr =” http://openadr.org/oadr-2.0b/2012/07″
xmlns：pyld =” http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
xmlns：ei =” http://docs.oasis-open.org/ns/energyinterop/201110″
xmlns：scale =” http://docs.oasis-open.org/ns/emix/2011/06/siscale”
xmlns：emix =” http://docs.oasis-open.org/ns/emix/2011/06″
xmlns：strm =” urn：ietf：params：xml：ns：icalendar-2.0：stream”
xmlns：xcal =” urn：ietf：params：xml：ns：icalendar-2.0”
xmlns：power =” http://docs.oasis-open.org/ns/emix/2011/06/power”

クリティカルピーク価格設定プログラム（CPP）

CPPシナリオ1-単純なユースケース、AまたはB Profile

イベント
- 通知：イベントの前日
- 開始時間: 午後1時
- 所要時間:4時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：1
- 信号名：SIMPLE
  - 信号タイプ：レベル
  - 単位：N / A
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：1
  - シグナルターゲット：N / A
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

CPPシナリオ2–典型的なユースケース、Bプロfile

イベント
- 通知：イベントの前日
- 開始時間：1pm
- 所要時間: 4 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0、1、2、3
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：1または2
  - 信号ターゲット：なし
- 信号名：ELECTRICITY_PRICE
  - シグナルタイプ：価格
  - 単位：XNUMXキロワット時あたりの米ドル
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：$ 0.10から$ 1.00
  - 信号ターゲット：なし
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

CPPシナリオ3–複雑なユースケース

イベント
- 通知：イベントの前日
- 開始時間: 午後2時
- 所要時間: 6 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX）
  - 間隔の数3
  - 間隔期間：1時間、4時間、1時間
  - 一般的な間隔値：1、2、1（それぞれ間隔ごと）
  - 信号ターゲット：なし
- 信号名：ELECTRICITY_PRICE
  - シグナルタイプ：価格
  - 単位：XNUMXキロワット時あたりの米ドル
  - 間隔の数3
  - インターバル時間：1時間、4時間、1時間
  - 一般的な間隔値：$ 0.50、$ 0.75、$ 0.50（それぞれ間隔ごと）
  - 信号ターゲット：なし
- イベントターゲット：Resource_1、Resource_2、Resource_3
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

CPPSampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT24H

PT4H

2.0

シンプル

レベル

SIG_01

0.0

PT4H

0.75

ELECTRICITY_PRICE

価格

SIG_02

通貨PerKWh

米ドル

無し

0.0

venID_1234

常に

容量入札プログラム（CBP）

CBPシナリオ1-単純なユースケース、AまたはBプロfile

イベント
- 通知：イベントの前日
- 開始時間: 午後1時
- 所要時間:4時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：1
- 信号名：SIMPLE
  - 信号タイプ：レベル
  - 単位：N / A
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：1
  - シグナルターゲット：N / A
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

CBPシナリオ2–典型的なユースケース、Bプロfile

イベント
- 通知：イベントの前日
- 開始時間：1pm
- 所要時間: 4 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：1または2
  - 信号ターゲット：なし
- 信号名：BID_LOAD
  - 信号タイプ：セットポイント
  - 単位：powerReal
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：20kWから100kW
  - 信号ターゲット：なし
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

CBPシナリオ3–複雑なユースケース

イベント
- 通知：イベントの日（何時間？）
- 開始時間: 午後1時
- 所要時間: 6 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：3
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX）
  - 間隔の数：2
  - インターバル時間：3時間、3時間
  - 一般的な間隔値：1、2（それぞれ間隔ごと）
  - 信号ターゲット：なし
- 信号名：BID_LOAD
  - 信号タイプ：セットポイント
  - 単位：powerReal
  - 間隔の数2
  - インターバル時間：3時間、3時間
  - 典型的な間隔値：40kW、80kW（それぞれ間隔ごと）
  - 信号ターゲット：なし
- シグナル名：BID_PRICE
  - シグナルタイプ：価格
  - 単位：currencyPerKW
  - 間隔の数1
  - インターバル時間：6時間
  - 典型的な間隔値：$ 3.10
  - 信号ターゲット：なし
- イベントターゲット：Resource_1、Resource_2、Resource_3
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- レポート名：TELEMETRY_USAGE
- レポートタイプ：使用法
- 単位：powerReal
- 読み取りタイプ：直接読み取り
- レポートの頻度：1時間ごと

CBP Sampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT24H

PT4H

2.0

シンプル

レベル

SIG_01

0.0

PT4H

80.0

BID_LOAD

セットポイント

SIG_02

RealPower

60.0

<パワー:ボリュームtage> 220.0tage>

true

0.0

venID_1234

常に

住宅用サーモスタットプログラム

住宅用サーモスタットシナリオ1-単純な使用例、AまたはB Profile

イベント
- 通知：イベントの前日
- 開始時間: 午後1時
- 所要時間:4時間
- ランダム化：10分
- Ramp 上：なし
- 回復：なし
- 信号数：1
- 信号名：SIMPLE
  - 信号タイプ：レベル
  - 単位：N / A
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：1
  - シグナルターゲット：N / A
- イベントターゲット：Resource_1
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

住宅用サーモスタットシナリオ2–典型的な使用例、Bプロfile

イベント
- 通知：イベントの前日
- 開始時間：1pm
- 所要時間: 4 時間
- ランダム化：10分
- Ramp 上：なし
- 回復：なし
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：1または2
  - 信号ターゲット：なし
- 信号名：LOAD_CONTROL
  - 信号タイプ：x-loadControlLevelOffset
  - 単位：温度
  - 間隔の数1
  - インターバル時間：4時間
  - 典型的な間隔値：華氏2〜6度
  - 信号ターゲット：なし
- イベントターゲット：Resource_1、Resource_2
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される応答：optIn、Possible outOut（oadrCreateOpt）
レポート
- なし

住宅用サーモスタットシナリオ3–複雑な使用例

イベント
- 通知：イベントの日
- 開始時間: 午後1時
- 所要時間: 6 時間
- ランダム化：10分
- Ramp 上：なし
- 回復：なし
- 信号数：3
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX）
  - 間隔の数：2
  - インターバル時間：3時間、3時間
  - 一般的な間隔値：1、2（それぞれ間隔ごと）
  - 信号ターゲット：なし
- 信号名：BID_LOAD
  - 信号タイプ：x-loadControlCapacity
  - 単位：なし
  - 間隔の数2
  - インターバル時間：3時間、3時間
  - 一般的な間隔値：0.9、0.8（それぞれ間隔ごと）
  - 信号ターゲット：なし
- イベントターゲット：Resource_1、Resource_2、Resource_3
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される応答：optIn、Possible outOut（oadrCreateOpt）
レポート
- なし

住宅用サーモスタットSampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT10M

PT24H

PT4H

2.0

シンプル

レベル

SIG_01

0.0

PT4H

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

温度

華氏

無し

0.0

resource_1

resource_2

常に

高速DRディスパッチ

高速DRシナリオ1–単純なユースケース、AまたはB Profile

イベント
- 通知：10分
- 開始時間: 午後1時
- 期間：0（オープンエンド）
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：1
- 信号名：SIMPLE
  - 信号タイプ：レベル
  - 単位：N / A
  - 間隔の数1
  - インターバル期間：0（オープンエンド）
  - 典型的な間隔値：1
  - シグナルターゲット：N / A
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

高速DRシナリオ2–典型的なユースケース、Bプロfile

イベント
- 通知：10分
- 開始時間：1pm
- 所要時間: 30分
- ランダム化：なし
- Ramp 上：5分
- 回復：5分
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX
  - 間隔の数1
  - インターバル時間：30分
  - 典型的な間隔値：1または2
  - 信号ターゲット：なし
- 信号名：LOAD_DISPATCH
  - 信号タイプ：デルタ
  - 単位：powerReal
  - 間隔の数1
  - インターバル時間：30分
  - 典型的な間隔値：500 kW〜2mW
  - 信号ターゲット：なし
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- レポート名：TELEMETRY_USAGE
- レポートタイプ：使用法
- 単位：powerReal
- 読み取りタイプ：直接読み取り
- レポートの頻度：1分ごと

高速DRシナリオ3–複雑なユースケース

イベント
- 通知：10分
- 開始時間: 午後1時
- 所要時間: 30分
- ランダム化：なし
- Ramp 上：5分
- 回復：5分
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0,1、2、3、XNUMX）
  - 間隔の数：2
  - インターバル時間：15分、15分
  - 一般的な間隔値：1、2（それぞれ間隔ごと）
  - 信号ターゲット：なし
- 信号名：LOAD_DISPATCH
  - 信号タイプ：セットポイント
  - 単位：powerReal
  - 間隔の数2
  - インターバル時間：15分、15分
  - 典型的な間隔値：800kW、900kW（それぞれ間隔ごと）
  - 信号ターゲット：なし
- イベントターゲット：Resource_1
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- レポート名：TELEMETRY_USAGE
- レポートタイプ：使用法
- 単位：powerRealおよびvoltage
- 読み取りタイプ：直接読み取り
- レポートの頻度：5秒ごと

高速DRSampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT10M

<ei:x-eiRamp上>

PT5M

</ei:x-eiRamp上>

PT5M

PT10M

2.0

シンプル

レベル

SIG_01

0.0

PT10M

500.0

LOAD_DISPATCH

デルタ

SIG_02

RealPower

60.0

<パワー:ボリュームtage> 220.0tage>

true

0.0

venID_1234

常に

高速DRSampleレポートメタデータペイロード–典型的なBプロfile 使用事例

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

resource1

使用法

RealEnergy

直接読み取り

http：// MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

false

</oadr:oadrSamplingRate>

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>

ec27de207837e1048fd3

高速DRSample Report Request Payload –典型的なBプロfile 使用事例

ReportReqID130615_192625_230

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

PT1M

<xcal:date-time>2015-06-14T13:00:00Z</xcal:date-time>

PT10M

rID120615_122512_981_0

x-該当なし

VEN130615_192312_582

高速DRSampleレポートデータペイロード–典型的なBプロfile 使用事例

ReportUpdReqID130615_192730_445

<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>

rID120615_122512_981_0

100

0.0

500.0

品質良好–非特定

RP_54321

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

TELEMETRY_USAGE

<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>

VEN130615_192312_582

住宅用電気自動車（EV）使用時間（TOU）プログラム

プログラムはかなり構造化された形式でレート階層を伝達するため、単純で典型的なユースケースのみが示されていることに注意してください。

住宅用EVシナリオ1-単純なユースケース、AまたはB Profile

イベント
- 通知：イベントの前日
- 開始時間: 午後1時
- 所要時間:24時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：1
- 信号名：SIMPLE
  - 信号タイプ：レベル
  - 単位：N / A
  - 間隔の数; 24時間で等しいTOU階層の変更（2〜6）
  - 間隔期間：TOU層のアクティブな時間枠（つまり6時間）
  - 一般的な間隔値：0〜4がTOU層にマップされます
  - シグナルターゲット：N / A
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

住宅用EVシナリオ2–典型的なユースケース、Bプロfile

イベント
- 通知：イベントの前日
- 開始時間：深夜
- 所要時間: 24 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：2
- 信号名：シンプル
  - 信号タイプ：レベル
  - 単位：レベル0、1、2、3
  - 間隔の数：24時間での等しいTOU層の変更（2 – 6）
  - 間隔期間：TOU層のアクティブな時間枠（つまり6時間）
  - 一般的な間隔値：0〜4がTOU層にマップされます（0〜最も安い層）
  - 信号ターゲット：なし
- 信号名：ELECTRICITY_PRICE
  - シグナルタイプ：価格
  - 単位：XNUMXキロワット時あたりの米ドル
  - 間隔の数：24時間で等しいTOU層の変更（2 – 6）
  - 間隔期間：TOU層のアクティブな時間枠（つまり6時間）
  - 通常の間隔値：$ 0.10から$ 1.00（現在のティアレート）
  - 信号ターゲット：なし
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

住宅用EVSampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>

PT24H

PT5H

0.0

PT7H

1.0

PT47H

2.0

PT5H

1.0

シンプル

レベル

SIG_01

0.0

PT5H

0.35

PT7H

0.55

PT7H

0.75

PT5H

0.55

ELECTRICITY_PRICE

価格

SIG_02

通貨PerKWh

米ドル

無し

0.0

venID_1234

常に

公共ステーション電気自動車（EV）リアルタイム価格設定プログラム

これはリアルタイムの価格設定プログラムであるため、単純なユースケース、一般的なユースケース、複雑なユースケースを区別することはできません。したがって、ampファイルデータは、一般的な使用例についてのみ表示されます。

公共ステーションEVシナリオ1-典型的なユースケース、Bプロfile

イベント
- 通知：1時間先
- 開始時間：1pm
- 所要時間: 1 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：1
- 信号名：ELECTRICITY_PRICE
  - シグナルタイプ：価格
  - 単位：XNUMXキロワット時あたりの米ドル
  - 間隔の数1
  - インターバル時間：1時間
  - 典型的な間隔値：$ 0.10から$ 1.00
  - 信号ターゲット：なし
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：常に
- VEN期待される反応：オプトイン
レポート
- なし

公共駅EVSampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT1H

0.75

ELECTRICITY_PRICE

価格

SIG_01

通貨PerKWh

米ドル

無し

0.0

venID_1234

常に

分散型エネルギー資源（DER）DRプログラム

公共ステーションEVシナリオ1-典型的なユースケース、Bプロfile

イベント
- 通知：前日
- 開始時間：深夜
- 所要時間: 24 時間
- ランダム化：なし
- Ramp 上：なし
- 回復：なし
- 信号数：24
- 信号名：ELECTRICITY_PRICE
  - シグナルタイプ：価格
  - 単位：XNUMXキロワット時あたりの米ドル
  - 間隔の数1
  - インターバル時間：1時間
  - 典型的な間隔値：$ 0.10から$ 1.00
  - 信号ターゲット：なし
- イベントターゲット：venID_1234
- 優先度: 1
- 必要なVEN応答：決して
- VEN期待される応答：該当なし
レポート
- なし

公共駅EVSampルイベントペイロード–典型的なBプロfile 使用事例

OadrDisReq091214_043740_513

TH_VTN

イベント091214_043741_028_0

http：// MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

はるかに

<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>

PT24H

PT1H

0.75

PT1H

0.80

ELECTRICITY_PRICE

価格

SIG_01

通貨PerKWh

米ドル

無し

0.0

venID_1234

決して

- 元ampユーティリティパイロットからのレポート

OpenADR Allianceメンバーは、次のBProを提供しましたfile oadrUpdateReportペイロードampVENが展開されたユーティリティパイロットプログラムからのファイル。次の注記は、XNUMXつのペイロードに付随しています。amp提供されるファイル：

サーモスタットペイロードの目的：

サーモスタットのステータス（温度、設定値、ファン、モードの状態）を知る必要があります
オプトインした場合、顧客がサーモスタット設定を変更したかどうか（手動オーバーライドメッセージ）

リベートペイロードのM＆V目的：

オプトインの場合のリソースのステータスと手動オーバーライド
KWHの総エネルギーとKWの瞬間需要に関するKYZパルスカウンターまたはエネルギーモニターからの間隔データ

スマートメーター/ AMI間隔データペイロードの目的：

AMIメーターの読み取り間隔は約15分から1時間です。便利ですが、ほぼリアルタイムの請求見積もりには十分な粒度ではありません
KWHでの総エネルギー、KWHでのデルタエネルギー、KWでの瞬間需要

次の名前空間プレフィックスがペイロードexで使用されますampレ：

xmlns：oadr =” http://openadr.org/oadr-2.0b/2012/07″
xmlns：pyld =” http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
xmlns：ei =” http://docs.oasis-open.org/ns/energyinterop/201110″
xmlns：scale =” http://docs.oasis-open.org/ns/emix/2011/06/siscale”
xmlns：emix =” http://docs.oasis-open.org/ns/emix/2011/06″
xmlns：strm =” urn：ietf：params：xml：ns：icalendar-2.0：stream”
xmlns：xcal =” urn：ietf：params：xml：ns：icalendar-2.0”
xmlns：power =” http://docs.oasis-open.org/ns/emix/2011/06/power”

サーモスタットレポートペイロードSample

RUP-18

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

状態

true

false

新しい値なし–以前の値が使用されました

現在の温度

77.000000

新しい値なし–以前の値が使用されました

熱温度設定

64.000000

新しい値なし–以前の値が使用されました

涼しい温度設定

86.000000

新しい値なし–以前の値が使用されました

HVACモード設定

新しい値なし–以前の値が使用されました

現在のHVACモード

0.000000

品質なし–価値なし

ファンモード設定

新しい値なし–以前の値が使用されました

現在のホールドモード

新しい値なし–以前の値が使用されました

現在の退席中モード

新しい値なし–以前の値が使用されました

現在の湿度

0.000000

品質なし–価値なし

RP21

REQ：RReq：1395368583267

0013A20040980FAE

TELEMETRY_STATUS

<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>

VEN.ID：1395090780716

M＆VforリベートレポートペイロードSample

RUP-10

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

状態

true

false

品質良好–非特定

脈拍数

34750.000000

品質良好–非特定

エネルギー

33985.500000

品質良好–非特定

力

1.26

品質良好–非特定

RP15

REQ：RReq：10453335019195698

0000000000522613 60

TELEMETRY_USAGE

<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>

VEN.ID：1439831430142

スマートメーター/ AMI間隔データレポートペイロードSample

RUP-4096

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT1M

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT15S

インスタントデマンド

6.167000

新しい値なし–以前の値が使用されました

intervalDataDelivered

0.051000

新しい値なし–以前の値が使用されました

currSumDelivered

12172.052000

新しい値なし–以前の値が使用されました

<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>

PT15S

インスタントデマンド

6.114000

新しい値なし–以前の値が使用されました

intervalDataDelivered

0.051000

新しい値なし–以前の値が使用されました

currSumDelivered

12172.052000

新しい値なし–以前の値が使用されました

<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>

PT15S

インスタントデマンド

6.113000

新しい値なし–以前の値が使用されました

intervalDataDelivered

0.051000

新しい値なし–以前の値が使用されました

currSumDelivered

12172.142000

新しい値なし–以前の値が使用されました

<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>

PT15S

インスタントデマンド

6.112000

新しい値なし–以前の値が使用されました

intervalDataDelivered

0.051000

新しい値なし–以前の値が使用されました

currSumDelivered

12172.142000

新しい値なし–以前の値が使用されました

RP4101

<ei:reportRequestID>d5f88bf0-1a8d-0132-eab3-0a5317f1edaa</ei:reportRequestID>

<ei:reportSpecifierID>00:21:b9:00:f2:a9</ei:reportSpecifierID>

TELEMETRY_USAGE

<ei:createdDateTime>2014-09-10T06:27:53Z</ei:createdDateTime>

<ei:venID>2b2159c0-19cd-0132-eaa3-0a5317f1edaa</ei:venID>

–サービス

Open ADRは、次のサービスをサポートしています。

EiEventサービス – VTNがデマンドレスポンスイベントをVENに送信するために使用し、リソースがイベントに参加するかどうかを示すためにVENによって使用されます。 Aプロがサポートする唯一のサービスfile EiEventです
EiReportサービス – VENおよびVTNが、履歴、テレメトリ、および予測レポートを交換するために使用します
EiOptサービス – VENは、一時的な可用性スケジュールをVTNに伝達したり、イベントに参加しているリソースを認定したりするために使用します
EiRegisterPartyサービス – VENによって開始され、ペイロードの相互運用可能な交換を保証するために必要な情報を交換するためにVENとVTNの両方によって使用されます
OadrPollサービス –他のサービスからのペイロードについてVTNをポーリングするためにVENによって使用されます

AとBプロfile サービス操作は、すべてのB proで使用されるoadrPayloadラッパーとoadrSignedObjectラッパーを除いて、各ペイロードのルート要素によって定義されます。file ペイロード。

–ペイロードの定義

EiEventペイロード

oadrRequestイベント – VENによるプル交換モデルで使用され、VTNから関連するすべてのイベントを取得します。 Aプロの主要なポーリングメカニズムとして使用されますfile VEN。ただし、VTNと同期するためにBVENでのみ使用されます。
oadrDistributeEvent –VTNがデマンドレスポンスイベントをVENに配信するために使用します
oadrCreatedイベント – VENが、オプトインまたはオプトアウトしてイベントに参加する予定があるかどうかを伝えるために使用します
oadr応答 –VTNがVENからのoptInまたはoptOutの受信を確認するために使用します

EiReportペイロード

VENとVTNはどちらも、レポートプロデューサーとレポートリクエスターの両方になることができるため、以下のすべてのペイロードはどちらの当事者でも開始できることに注意してください。

oadr登録レポート –メタデータレポートでレポート機能を公開するために使用されます
oadr登録済みレポート -oadrRegisterReportの受信を確認し、オプションで提供されたレポートのXNUMXつを要求します
oadrレポートの作成 –以前にVENまたはVTNによって提供されたレポートを要求するために使用されます
oadr作成されたレポート –レポートリクエストの受信を確認します
oadrUpdateReport -間隔データを含む要求されたレポートを配信します
oadr更新レポート –配信されたレポートの受信を確認します
oadrキャンセルレポート –以前に要求された定期レポートをキャンセルする
oadrキャンセル報告 –定期的なレポートのキャンセルを確認する
oadr応答 –アプリケーション層の応答がトランスポート層の要求で配信されるときに、一部のプル交換パターンでプレースホルダー応答として使用されます。

EiOptペイロード

oadrCreateOpt –XNUMXつの明確に異なる目的に使用されます
- VENがDRイベントに参加する能力に関して、一時的な可用性スケジュールをVTNに伝達するため
- VENがイベントに参加しているリソースを認定するために
oadrCreatedOpt –oadrCreateOptペイロードの受信を確認します
oadrCancelOpt -一時的な可用性スケジュールをキャンセルします
oadrキャンセルオプト –一時的な可用性レポートのキャンセルを確認します

EiRegisterPartyペイロード

oadrQuery登録 –VENが実際に登録せずにVTN登録情報を照会する方法。
oadrCreatePartyRegistration –VENからVTNへの登録要求。 VENの機能に関する情報が含まれています。
oadr作成者登録 –oadrQueryRegistrationまたはoadrCreatePartyRegistrationのいずれかへの応答。 VENが相互運用するために必要なVTN機能と登録情報が含まれています
oadrキャンセルパーティー登録 –登録をキャンセルするためにVENまたはVTNのいずれかによって使用されます
oadrキャンセルされたパーティー登録 –oadrCancelPartyRegistrationに応答します。登録キャンセルの受領を確認します
oadrRequest再登録 –このペイロードは、プル交換モデルのVTNによって使用され、登録シーケンスを再開するようにVENに信号を送ります。
oadr応答 –アプリケーション層の応答がトランスポート層の要求で配信されるときに、一部のプル交換パターンでプレースホルダー応答として使用されます。

OadrPollペイロード

oadrPoll –Bプロの一般的なポーリングメカニズムfile これは、新規または更新された他のサービスのペイロードを返します。
oadr応答 –使用可能な新しいペイロードまたは更新されたペイロードがないことを示すために使用されます

–スキーマペイロード要素の用語集

以下は、OpenADR2.0ペイロードで使用されるスキーマ要素のアルファベット順のリストです。ナラティブは、OpenADRに関連する使用法と、ペイロードでの使用法を説明します。要素定義が含まれているペイロードまたはその使用状況に基づいて変更される場合、これはナラティブに記載されます。付録Cで定義されているため、ルートペイロードの定義は除外されています。

ac –電力積が交流であるかどうかを示すブール値
正確さ - 数値は、間隔のペイロード変数と同じ単位です。信頼度が存在する場合、予測の変動の可能性を示します。 ReadingTypeとともに存在する場合、Readingのエラーの可能性を示します。
AggregatedPnode – 集約価格設定ノードは、システムゾーン、デフォルト価格ゾーン、カスタム価格ゾーン、コントロールエリア、集約生成、集約参加負荷、集約非参加負荷、トレーディングハブ、DCAゾーンなどのアイテムをモデル化するために使用される特殊なタイプの価格設定ノードです。
利用可能 –EiOpt可用性スケジュールの日時と期間を含むオブジェクト
ベースラインID– 特定のベースラインの一意のID
ベースライン名– ベースラインの説明的な名前
コンポーネント –
自信 –報告されたデータポイントが正確であるという統計的確率
作成日時 – ペイロードが作成された日時
通貨 –
通貨PerKW –
通貨PerKWh –
通貨PerThm –
現在 –
現在の価値 - 現在実行中のイベント間隔のpayloadFloat値。
カスタムユニット –カスタムレポートのカスタム測定単位を定義するために使用されます
日付時刻 –
dtstart – アクティビティ、データ、または状態変更の開始時間
間隔 –イベント、レポート、または可用性の時間間隔の期間
デュレーション– アクティビティ、データ、または状態の期間
eiActivePeriod – イベント全体に関連する時間枠
eiCreatedEvent – optInまたはoptOutを使用してDRイベントに応答する
eiイベント -XNUMXつのイベントのすべての情報を含むオブジェクト
eiEventBaseline – Bプロfile
eiイベント信号 –イベント内の単一信号のすべての情報を含むオブジェクト
eiEventSignals – XNUMXつ以上のイベント信号および/またはベースラインの間隔データ
eiマーケットコンテキスト –デマンドレスポンスプログラムを一意に識別するURI
eiレポートID – レポートの参照ID
eiRequestイベント – プルモードでVTNからイベントを要求する
eiResponse – 受信したペイロードが受け入れ可能かどうかを示します
eiターゲット – 論理VENインターフェースに関連付けられているリソースを識別します。イベントの場合、指定された値がイベントのターゲットになります
エンドデバイスアセット – EndDeviceAssetsは、XNUMXつまたは複数の物理デバイスであり、メーターまたはその他のタイプのデバイスである可能性があります。
energyAppparent – 見かけのエネルギー、ボルトで測定-ampere hours（VAh）
エネルギーアイテム –
エネルギー反応性 – 反応エネルギー、ボルト-amperes反応時間（VARh）
エナジーリアル – 実エネルギー、ワット時（Wh）
イベント記述子 – イベントに関する情報
イベントID – 特定のDRイベントインスタンスを識別するID値。
イベント応答 –イベントへの参加リクエストに対するVENの応答を含むオブジェクト
イベント応答 – 受信したイベントに対するoptInまたはoptOutの応答
イベントステータス –イベントの現在のステータス（遠い、近い、アクティブなど）
FeatureCollection / location / Polygon / external / LinearRing
頻度 –
粒度 –これはs間の時間間隔ですampレポートリクエストのLEDデータ。
グループID -このタイプのターゲットは、イベント、レポート、およびオプトスケジュールに使用されます。値は通常、DRプログラムへの登録時にユーティリティによって割り当てられます
グループ名 –このタイプのターゲットは、イベント、レポート、およびオプトスケジュールに使用されます。値は通常、DRプログラムへの登録時にユーティリティによって割り当てられます
ヘルツ –
間隔 –データ時間および/または期間、およびイベントの場合はアクション可能な値、レポートの場合はデータを含むオブジェクト
間隔– DRイベントがアクティブであるか、レポートデータが利用可能なXNUMXつ以上の時間間隔
アイテム説明 - レポートの測定単位の説明
アイテム単位 – レポートデータポイントの基本測定単位
市場コンテキスト – DRプログラムを識別するURI
MeterAsset – MeterAssetは、メーターの役割を果たすXNUMXつまたは複数の物理デバイスです。
modifyDateTime – イベントが変更されたとき
modifyNumber – イベントが変更されるたびに増分されます。
modifyReason – イベントが変更された理由
中 - mRIDは、CustomerMeterまたは他のタイプのEndDeviceである可能性のある物理デバイスを識別します。
ノード– ノードは、グリッド上で何かが変更されたり（多くの場合所有権）接続されたりする場所です。多くのノードがメーターに関連付けられていますが、すべてが関連付けられているわけではありません。
データソース数 –
oadr容量 –
oadr電流 –
oadrDataQuality –
oadrDeviceClass – デバイスクラスターゲット–endDeviceAssetのみを使用します。
oadrイベント – デマンドレスポンスイベントを含むオブジェクト
oadr拡張子 –
oadrExtensionName –
oadr拡張機能 –
oadrHttpPullModel – VENがプル交換モデルを使用するかどうかを示すブール値
oadr情報 – サービス固有の登録情報のキーと値のペア
oadrKey –
oadrLevelOffset –
oadrLoadControlState –
oadrManualOverride – trueの場合、負荷の制御は手動でオーバーライドされています
oadrMax –
oadrMaxPeriod – 最大sampリン期間
oadrMin –
oadrMinPeriod – 最小sampリン期間
oadr通常 –
oadrOnChange – trueの場合、データは変更されたときに記録されますが、minPeriodで指定された頻度よりも高い頻度ではありません。
oadrオンライン – trueの場合、リソース/アセットはオンラインであり、falseの場合、オフラインです。
oadrペイロード –
oadrPayloadResourceStatus – 現在のリソースステータス情報
oadr保留中レポート –まだアクティブな定期レポートのリスト
oadrパーセントオフセット –
oadrProfile - プロfile VENまたはVTNでサポート
oadrProfile名前 - OpenADRプロfile 2.0aや2.0bなどの名前。
oadrProfiles – OpenADRプロfiles実装によってサポートされています
oadrレポート -XNUMXつのレポートのすべての情報を含むオブジェクト
oadrレポートの説明 –レポート作成者によって提供されるレポート特性の説明。メタデータレポートに含まれています
oadrレポートのみ – レポートのみデバイスフラグ
oadrReportPayload – レポートのデータポイント値
oadrRequestedOadrPollFreq – VENは、この要素で指定された期間ごとに、最大でXNUMX回はoadrPollペイロードをVTNに送信します。
oadrResponse必須 – optIn / optOut応答が必要な場合を制御します。常にまたは決してすることはできません
オーダスampリングレート – Sampテレメトリタイプのデータのリングレート
oadrService –
oadrサービス名 –このタイプのターゲットは、イベント、レポート、およびオプトスケジュールに使用されます。値は通常、DRプログラムへの登録時にユーティリティによって割り当てられます
oadrServiceSpecificInfo – サービス固有の登録情報
oadrSetPoint –
oadrSignedObject –
oadrトランスポート –VENまたはVTNでサポートされているトランスポート名
oadrTransportAddress – 相手との通信に使用されるルートアドレス。必要に応じてポートを含める必要があります
oadrTransportName – simpleHttpやxmppなどのOpenADRトランスポート名
oadrTransports – 実装によってサポートされるOpenADRトランスポート
oadrUpdatedReport – レポートの受信を確認します
oadrUpdateReport – 以前にリクエストしたレポートを送信する
oadr値 –
oadrVenName – VENの名前。 VTNGUIで使用できます
oadrXml署名 – 実装はXML署名をサポートします
オプトID – optインタラクションの識別子
オプトリーズン – x-scheduleなどの選択理由の列挙値
オプトタイプ – イベントのoptInまたはoptOut、またはEiOptサービスのvavailablityObjectで定義されたオプトスケジュールのタイプを示すために使用されます
パーティーID –このタイプのターゲットは、イベント、レポート、およびオプトスケジュールに使用されます。値は通常、DRプログラムへの登録時にユーティリティによって割り当てられます
ペイロードフロート– イベント信号のデータポイント値、または現在または過去の値を報告するためのデータポイント値。
p ノード – 価格設定ノードは、接続ノードに直接関連付けられています。これは、市場参加者がビッド、オファー、CRRの売買、および決済を行うための価格設定場所です。
ポイントオブデリバリー –
ポイントオブレシート –
posList –
powerAppparent – ボルトで測定された見かけの電力-ampエレス（VA）
パワー属性
パワーアイテム
パワーリアクティブ – ボルトで測定された無効電力-amperes反応性（VAR）
パワーリアル – ワット（W）またはジュール/秒（J / s）で測定された有効電力
優先度 - 他のイベントに対するイベントの優先度（数値が小さいほど優先度が高くなります。値がゼロ（0）の場合、優先度がないことを示します。これはデフォルトで最も低い優先度です）。
プロパティ –
パルスカウント –レポートデータポイント
パルスファクター – カウントあたりのkWh
修飾されたイベントID –イベントの一意のID
リーディングタイプ – 平均値や派生値など、測定値に関するメタデータ
登録ID– 登録トランザクションの識別子。すでに登録されていない限り、クエリ登録への応答には含まれません
返信制限 –oadrDistributeEventペイロードで返されるイベントの最大数
レポートバック期間 – この期間が経過するたびに、Report-To-Dateを使用してレポートを返します。
レポートデータソース – このレポートのデータのソース。元ampファイルには、メートルまたはサブメーターが含まれます。例ampつまり、メーターがXNUMXつの異なるタイプの測定を提供できる場合、各測定ストリームは個別に識別されます。
レポート間隔 – これは、レポートの全体的な期間です。
レポート名 – レポートのオプションの名前。
レポートリクエストID – 特定のレポートリクエストの識別子
レポート指定子 – 特定のレポートインスタンスで必要なデータポイントを指定します
レポート指定子ID – 特定のメタデータレポート仕様の識別子
レポート件名 – デバイスクラスターゲット–endDeviceAssetのみを使用します。
レポートしてフォローする – レポートのキャンセル後にレポート（UpdateReportの形式）を返すかどうかを示します
レポートタイプ –使用量や価格などのレポートの種類
リクエストID – 論理トランザクションの要求と応答を照合するために使用されるID
リソースID –このタイプのターゲットは、イベント、レポート、およびオプトスケジュールに使用されます。値は通常、DRプログラムへの登録時にユーティリティによって割り当てられます
応答 –
レスポンスコード – 3桁の応答コード
応答説明 – 応答ステータスの説明
回答 –
取り除く - このデータポイントのReferenceID
サービスエリア –このタイプのターゲットは、イベント、レポート、およびオプトスケジュールに使用されます。値は通常、DRプログラムへの登録時にユーティリティによって割り当てられます
サービスデリバリーポイント – サービスの所有権が変更されるネットワーク上の論理ポイント。これは、ServiceLocation内の潜在的に多くのサービスポイントのXNUMXつであり、CustomerAgreementに従ってサービスを提供します。メーターが設置される可能性のある場所で使用されます。
サービスの場所 – 顧客のServiceLocationにはXNUMXつ以上のServiceDeliveryPointがあり、これらはメーターに関連しています。場所は、特定の状況に応じて、ポイントまたはポリゴンになります。配布の場合、ServiceLocationは通常、ユーティリティの顧客の施設の場所です。
シグナルID – 特定のイベント信号の一意の識別子
信号名 –SIMPLEなどの信号の名前
信号ペイロード – イベントとベースラインの信号値
siScaleコード –レポートの基本測定単位の倍率
指定子ペイロード –オープン
開始後 –イベント開始のランダム化ウィンドウ
ステータス日付時刻 – このアーティファクトが参照する日時。
温度 –
テストイベント – false以外は、テストイベントを示します
文章 –
サーム –
許容範囲– イベントのランダム化要件を含むサブオブジェクト
許容する –イベントのランダム化要件を含むオブジェクト
トランスポートインターフェース – トランスポートインターフェイスは、トランスポートセグメントの両端のエッジを示します。
UID – 間隔を識別するためのインデックスとして使用されます。一意の識別子
価値 –
可用性– DRイベントに参加するためのデバイスの可用性を反映するスケジュール
ベンダーID –VENの一意の識別子
巻tage –
vtnコメント – 任意のテキスト
vtnID –VTNの一意の識別子
x-ei通知 – VENは、dtstartからこの期間を引いた前にDRイベントペイロードを受信する必要があります。
エックスエイアールamp上 - ロードシェッドが通過するイベント開始時間の前後の期間。
x-eiリカバリ – ロードシェッドが通過するイベント終了時間の前後の期間。

列挙値の用語集

イベントステータス

アクティブ –イベントが開始され、現在アクティブです。
キャンセル –イベントはキャンセルされました。
完了 –イベントが完了しました。
遠い –遠い将来に保留中のイベント。これが参照する将来の正確な定義は、市場の状況によって異なりますが、通常は翌日を意味します。
近く –近い将来保留中のイベント。保留中のイベントがアクティブになる将来の正確な定義は、市場の状況によって異なります。。イベントx-eiRの効果的な開始と同時に開始しますamp稼働時間。 x-eiRの場合ampイベントにUpが定義されていないため、このステータスはイベントに使用されません。
なし –保留中のイベントはありません

item単位

通貨
- 米ドル –米ドル
- ここにリストする多くの人にとって、スキーマを参照してください
パワーリアル
- J/秒 –ジュール秒
- W –ワット
温度
- 摂氏 –
- 華氏 –

oadrDataQuality

新しい値なし–以前の値が使用されました –
品質なし–価値なし –
品質が悪い–通信障害 –
品質不良–構成エラー –
品質不良–デバイス障害 –
品質が悪い–最後の既知の値 –
品質が悪い–非特定 –
品質が悪い–接続されていません –
品質が悪い–サービス停止 –
品質不良–センサー障害 –
品質良好–ローカルオーバーライド –
品質良好–非特定 –
品質制限–フィールド/定数 –
品質制限–フィールド/高 –
品質制限–フィールド/低 –
品質制限–フィールド/ –
品質が不確実–EU単位を超えています –
品質が不確実–最後に使用可能な値 –
品質が不確実–非特定 –
品質が不確か–センサーが正確ではない –
品質が不確か–通常以下 –

oadrResponse必須

いつも –受信したすべてのイベントに対して常に応答を送信します。
一度もない –応答しないでください。

オプト理由

選択する理由の列挙。

経済的 –
緊急 –
走らなければならない –
参加していない –
outageRunステータス –
オーバーライドステータスs –
参加する –
xスケジュール –

oadrトランスポート名

シンプルなHttp –
xmp –

オプトタイプ

オプトイン – VENがイベントに参加することを示す、またはEiOptサービスの場合は、リソースが利用可能になることを示す一種のスケジュール
身を引く – VENがイベントに参加しないことを示す、またはEiOptサービスの場合は、リソースが利用できないことを示す一種のスケジュール

読み取りタイプ

割り当て済み – Meterはいくつかの[リソース]をカバーし、使用量はある種のプロデータ計算によって推測されます。
契約 –読み取りがプロフォーマであること、つまり合意されたレートで報告されることを示します
派生 –使用状況は、実行時、通常の操作などの知識から推測されます。
直接読み取り –読み取り値は単調に増加するデバイスから読み取られ、使用量は開始読み取り値と停止読み取り値のペアから計算する必要があります。
推定 –ほとんどの読み取り値が存在するシリーズに読み取り値がない場合に使用されます。
ハイブリッド –集計されている場合、集計番号のさまざまな読み取りタイプを参照します。
平均 –読み取り値は、粒度で示される期間の平均値です。
ネット –メーターまたは[リソース]は、時間の経過に伴う総使用量の独自の計算を準備します。
ピーク –読み取り値は、粒度で示された期間のピーク（最高）値です。一部の測定では、最小値としてより意味がある場合があります。集計値と一致しない場合があります。流量アイテムベース、つまりエネルギーではなく電力にのみ有効です。
予測 –読み取り値が将来であり、まだ測定されていないことを示します。
合計 –数メートル一緒に、この[リソース]の読み取り値を提供します。これは特に、同じペイロード内の複数の[リソース]を参照する集約とは異なります。ハイブリッドも参照してください。
x-該当なし - 適用できません
x-RMS - 二乗平均平方根

レポート名

HISTORY_GREENBTON –アトムフィードスキーマ構造に緑色のボタンデータを含むレポート
HISTORY_USAGE –過去のエネルギー使用量データを含むレポート
METADATA_HISTORY_GREENBTON –HISTORY_GREENBUTTONレポートのレポート機能を定義するメタデータレポート
METADATA_HISTORY_USAGE –HISTORY_USAGEレポートのレポート機能を定義するメタデータレポート
METADATA_TELEMETRY_STATUS –TELEMETRY_STATUSレポートのレポート機能を定義するメタデータレポート
METADATA_TELEMETRY_USAGE –TELEMETRY_USAGEレポートのレポート機能を定義するメタデータレポート
TELEMETRY_STATUS –オンライン状態などのリアルタイムのリソースステータス情報を含むレポート
TELEMETRY_USAGE –リアルタイムのエネルギー使用情報を含むレポート

レポートタイプ

提供されているレポートのタイプを示す列挙値。

利用可能なエネルギー貯蔵 –おそらくターゲットエネルギー貯蔵に到達するために、さらなるエネルギー貯蔵に利用可能な容量
平均需要 –粒度で示される期間の平均使用量。詳細については、需要を参照してください。
平均使用量 –粒度で示される期間の平均使用量。詳細については、使用法を参照してください。
ベースライン – ItemBaseで示されているように、需要または使用法である可能性があります。イベントまたは規制がない場合の[測定]がどうなるかを示します。レポートの形式はベースラインです。
デルタデマンド –ベースラインと比較した需要の変化。詳細については需要をご覧ください
デルタセットポイント –以前のスケジュールからの設定値の変更。
デルタ使用量 –ベースラインと比較した使用量の変化。詳細については、使用法を参照してください
要求 –レポートは、ユニットの量を示します（ItemBaseまたはEMIX製品で表示されます）。ペイロードタイプは数量です。典型的なItemBaseはRealPowerです。
偏差 –いくつかの指示と実際の状態の違い。
ダウン規制容量利用可能 – EMIX Real Powerで表される、ディスパッチに利用可能なダウンレギュレーション容量。ペイロードは常に正の数量として表されます。
レベル –各間隔での市場からの単純なレベル。
OperatingState –オン/オフ、建物の占有率など、リソースの一般化された状態。ItemBaseは関係ありません。アプリケーション固有のペイロード拡張が必要です。
パーセントデマンド –パーセンtag需要のe
パーセント使用量 –パーセンtag使用法のe
力率 –リソースの力率
価格 –各間隔でのItemBaseあたりの価格
読む –レポートは、メーターからの読み取り値を示します。読み取り値は時間の瞬間です-時間の経過に伴う変化は、連続する読み取り値の差から計算できます。ペイロードタイプはフロートです
規制設定値 –規制サービスの一部として指示された規制設定値
セットポイント –レポートは、現在設定されている金額（ItemBaseまたはEMIX製品で表示）を示します。 VTNから送信された設定値制御値の確認/戻りである可能性があります。ペイロードタイプは数量です。典型的なItemBaseはRealPowerです。
StoredEnergy –蓄積エネルギーは実エネルギーとして表され、ペイロードは数量として表されます。
ターゲットエネルギーストレージ –目標エネルギーは実エネルギーとして表され、ペイロードは数量として表されます。
アップ規制容量利用可能 – EMIX Real Powerで表される、ディスパッチに利用可能なアップレギュレーション容量。ペイロードは常に正の数量として表されます。
使用法 –レポートは、期間中のユニット数（ItemBaseまたはEMIX製品で表示）を示します。ペイロードタイプは数量です。典型的なItemBaseはRealEnergyです
x-resourceStatus –パーセンtag需要のe

スケールコード

p –ピコ10 ** -12
n –ナノ10 **-9
マイクロ –マイクロ10 **-6
m –ミリ10 **-3
c –センチ10 **-2
d –デシ10 **-1
k –キロ10 ** 3
M –メガ10 ** 6
G –ギガ10 ** 9
T –テラ10 ** 12
なし –ネイティブスケール

信号名

BID_ENERGY –これは、プログラムに入札されたリソースからのエネルギー量です。
BID_LOAD –これは、リソースによってプログラムに入札された負荷の量です。
入札価格 –これはリソースによって入札された価格です
CHARGE_STATE –エネルギー貯蔵資源の状態
デマンドチャージ –これはデマンドチャージです
電気料金_PRICE –これは電気代です
ENERGY_PRICE –これはエネルギーのコストです
LOAD_CONTROL -負荷出力を相対値に設定します
LOAD_DISPATCH –これは負荷をディスパッチするために使用されます
単純 –減価償却–Aプロとの下位互換性のためfile
単純 –単純なレベル（OpenADR 2.0a準拠）

信号タイプ

レベルや価格などのシグナルのタイプを説明する列挙値

デルタ –シグナルは、シグナルなしで使用したものから変化する量を示します。
レベル –信号はプログラムレベルを示します。
掛け算するr –シグナルは、シグナルなしで使用したであろう現在の配信または使用率に適用される乗数を示します。
価格 –シグナルは価格を示します。
価格倍率r –シグナルは価格乗数を示します。拡張価格は、計算された価格値にユニット数を掛けたものです。
価格相対 –シグナルは相対価格を示します。
セットポイント –信号はユニットの目標量を示します。
x-loadControlCapacity –これは、負荷コントローラーがある程度のレベルで動作するように指示するものです。tagその最大負荷消費容量のe。これを特定のロードコントローラーにマッピングして、デューティサイクルなどを実行できます。 1.0は100％の消費を指すことに注意してください。単純なON / OFFタイプのデバイスの場合、0 = OFFおよび1 = ONです。
x-loadControlLevelOffset –通常の操作に関連する離散整数レベル。0は通常の操作です。
x-loadControlPercentOffset –パーセンtage通常の負荷制御操作からの変更。
x-loadControlSetpoint –コントローラーの設定値をロードします。

– OpenADRAおよびBProfile 違い

Aプロがサポートする唯一のサービスfile EiEventサービスです。 EiEventオブジェクトはAプロで簡略化されていますfile 次の制約があります。

イベントごとに許可されるシグナルはXNUMXつだけであり、そのシグナルはOpenADRの既知のシグナルSIMPLEである必要があります。
venID、groupID、resourceID、およびpartyIDのみがサポートされている限定的なイベントターゲティングがあります（eiEvent：eiTarget）。
デバイスクラスを使用した信号レベルでのターゲティングはサポートされていません（eiEventSignal：eiTarget：endDeviceAsset）。
ベースラインはサポートされていません（eiEvent：eiEventSignals：eiEventBaseline）。
modifyDateTimeとmodificationReasonはサポートされていません。
エンドポイント URL 2.0bの単純なHTTPの場合は次のとおりです。
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Aプロで必要とされたいくつかのペイロード要素file Bプロではオプションになりましたfile、含む：

現在の価値

–OpenADRセキュリティ証明書

OpenADR適合規則には、以下が必要です。

X.1.2証明書の交換にはTLSバージョン509が使用されます
VTNには、SHA256ECC証明書とRSA証明書の両方が必要です
VENは、SHA256 ECC証明書とRSA証明書のいずれかをサポートし、両方をサポートする場合があります
VTNとVENの両方が、トランスポートサーバーの役割を果たす場合（つまり、相手からの要求に応答する場合）、クライアント証明書を要求するように構成する必要があります。
VTNとVENの両方が、TLSネゴシエーションプロセスの一部として相手方から要求されたときにクライアント証明書を提供する必要があります

NetworkFXによって提供される証明書は、RSAまたはECCに固有のものになります。これらの証明書の作成は、NetworkFXのフォームに記入した結果として発生する可能性があります web テスト証明書を要求するサイト、または証明書署名要求（CSR）を介して本番証明書を要求した結果である可能性があります。方法に関係なく、以下の fileが提供されます（例ampファイルが表示されます）：

ルート証明書
中間ルート証明書
デバイス証明書
秘密鍵

一般に、秘密鍵は、VENまたはVTNによって送信されるペイロードを暗号化するために使用されます。デバイス証明書は、認証局によって作成され、秘密鍵を使用して暗号化されたVENまたはVTNに関する一意の識別情報のセットです。ルートと中間 filesは、デバイス証明書を復号化し、証明書が信頼できる機関からのものであることを検証するために使用されます。

JSSEを利用するJava環境には、XNUMXつの証明書ストアがあります。 XNUMXつはトラストストアと呼ばれ、ルート証明書を保持するために使用されます。 XNUMXつ目はキーストアと呼ばれ、デバイス証明書の中間証明書と秘密鍵で構成される証明書チェーンを格納するために使用されます

XMPPトランスポートを使用する場合、VENはXMPPサーバーと通信し、VTNとは直接通信しないことに注意してください。したがって、XMPPサーバーの証明書の構成はVTNの構成と同等である必要があります。 VTN自体とXMPPサーバー間の通信は、VENに対して透過的であり、基本的にプライベートリンクです。それでも、ほとんどのベンダーは、XMPPサーバーと通信するときにVTNで一連のVEN証明書を使用していました。

XMPPサーバーとしてOpenFireを使用している場合は、考慮しなければならない別の制約があります。 OpenFireでは、クライアントデバイス証明書で使用されているCN名が、XMPPサーバーで構成されているデバイスのXMPPユーザー名と一致している必要があります。これにより、VEN証明書のCN名にMACのようなアドレスが使用されるため、クライアント名が奇妙になる可能性があります（OpenADRセキュリティ要件の一部）

最後に、トランスポートクライアントの役割を果たす場合、ほとんどのVENおよびVTNは、トランスポートサーバーによって提供された証明書のCNフィールドが、証明書を提供したエンティティのホスト名と一致するCN名を持っていることを検証しようとします。これは、証明書を交換する際の相互運用性の問題のもうXNUMXつの原因である可能性があります。ホスト名の検証は通常、プログラムで無効にして、これらの種類の問題を切り分けることができます。

OpenADR 2.0デマンドレスポンスプログラムガイド– ダウンロード[最適化]
OpenADR 2.0デマンドレスポンスプログラムガイド– ダウンロード

参考文献

ユーザーマニュアル

導入

参考文献

用語と定義

略語

デマンドレスポンスプログラムの種類

展開シナリオ

ダイレクト1

ダイレクト2

ダイレクト3

ダイレクト4

ファシリテーター1

アグリゲーター1

展開シナリオとDRプログラムのマッピング

DRプログラムテンプレートの選択

デマンドレスポンスプログラムテンプレート

クリティカルピーク価格設定プログラム（CPP）

CPPDRプログラムの特徴

CPPプログラムのOpenADR特性

容量入札プログラム

容量入札DRプログラムの特徴

容量入札プログラムのOpenADR特性

住宅用サーモスタットプログラム

住宅用サーモスタットDRプログラムの特徴

住宅用サーモスタットプログラムのOpenADR特性

高速DRディスパッチ

高速DRディスパッチプログラムの特徴

容量入札プログラムのOpenADR特性

住宅用電気自動車（EV）使用時間（TOU）プログラム

住宅用EVTOUプログラムの特徴

住宅用EVTOUプログラムのOpenADR特性

公共ステーション電気自動車（EV）リアルタイム価格設定プログラム

公共ステーションEVRTPプログラムの特徴

公共ステーションEVRTPプログラムのOpenADR特性

分散型エネルギー資源（DER）DRプログラム

分散型エネルギー資源（DER）プログラムの特徴

分散型エネルギー資源（DER）のOpenADR特性

参考文献

コメントを残す

返信をキャンセル