JP2014071901A - 需要応答管理のための方法およびシステム - Google Patents

Abstract

【課題】利用可能な需要応答事象の数、および利用可能な需要応答事象を発行するために利用可能な機会の数を決定するステップを含む、需要応答管理のための方法を提供する。
【解決手段】需要応答事象ごとの優先順位が提供され、需要応答事象ごとのしきい値が決定される。選択された需要応答トリガの観測値よりしきい値の方が低い、利用可能な需要応答事象の中から優先順位の最も高い需要応答事象が選択されて、現在の機会の選択された需要応答事象を利用するための制御信号が顧客サイトに送信される。
【選択図】図１

Description

本システムの実施形態は一般的に電力システムに関し、より具体的には、ピーク負荷状態の間の電力需要の管理に関する。

送電および配電ネットワークにとって、システムの信頼性は重要である。負荷および非線形エネルギー需要の変動は、システムの信頼性を損なう要因となる。ユーティリティ事業者は負荷予測モデルおよび技法を維持するが、実際のシステム負荷は可変であり頻繁な変動を受ける傾向がある。負荷の変化またはシステムの不測の事態に対応するためにユーティリティ事業者が使用できる技法およびツールは、現在のところ限られている。送電または配電の不測の事態に対応するための方法は、一般的に特定の回路を開くことを含み、これは無秩序な電力平均分配につながる。

ピーク負荷条件に応じてエネルギー需要の削減を可能にする需要応答ソリューションが利用可能である。電力システムの不測の事態に対応するための需要側のリソースの使用は、一般的に大容量電力平均分配スキーム（たとえば、輪番停電）に限られる。より具体的には、大容量電力平均分配および／または電圧低減（電圧低下）は、過負荷の回路または変圧器に対処するための現在の方法である。どちらの場合も、影響を受ける領域の顧客にとって重大な影響がある。さらに、過負荷状態を緩和するためにすぐさま負荷を軽減する意思のある大規模な工業および商業の顧客のための需要応答プログラムは限られている。

特に住宅地における不測の事態のための需要応答ソリューションは、ネットワーク構造が動的に変化するために管理が困難である。これにより、特定の不測の事態に対応できる顧客の識別が困難になる。ユーティリティ事業者は、暖房または冷房装置、プールポンプ等の、特定の負荷の直接制御装置をいくつかの顧客に提供しているが、特定のユーティリティ事業者が、ネットワークニーズに対応するために、ユーティリティネットワークを介して効率的かつ効果的にこれらのデバイスを管理することはできない。さらに、ユーティリティ事業者は一般的に、需要応答または削減事象を呼び出すタイミングを決定するために、温度や予備マージンのような、単純なヒューリスティックベースのトリガを使用する。しかしこの手法は、利益、節約量、および／または他の基準が最適化されるような経済的な電力平均分配または削減のオプションを行使するための最良の機会をユーティリティ事業者に提供しない。

これらおよび他の理由から、改良されたエネルギー需要応答管理が必要である。

米国特許出願公開第２０１１／０２５８０１８号明細書

本発明の実施形態によれば、需要応答管理の方法が提供される。本方法は、利用可能な需要応答事象の数を決定するステップと、利用可能な需要応答事象を発行するために利用可能な機会の数を決定するステップと、需要応答事象ごとに優先順位を提供するステップとを含む。本方法は、選択された需要応答トリガの観測値よりしきい値の方が低い、利用可能な需要応答事象の中から優先順位の最も高い需要応答事象を選択するステップと、現在の機会のために選択された需要応答事象を利用するために、通信ネットワークを介して制御信号を顧客サイトに送信するステップとをさらに含む。

本発明の他の実施形態によれば、ユーティリティネットワークにおける需要応答事象を制御するためのシステムが提供される。本システムは、需要応答リソースを制御するためのローカルコントローラ、ローカルコントローラおよびユーティリティ事業者と通信可能に結合されたリモートロケーションコントローラを含む。リモートロケーションコントローラは、利用可能な需要応答事象の数を決定して、利用可能な需要応答事象を発行するために利用可能な機会の数を決定して、需要応答事象ごとに優先順位を提供するように構成された需要応答モジュールを含む。需要応答モジュールは、需要応答事象ごとにしきい値を決定して、選択された需要応答トリガの観測値よりしきい値の方が低い、利用可能な需要応答事象の中から優先順位の最も高い需要応答事象を決定するようにさらに構成される。

本発明の他の実施形態によれば、少なくとも１つのプロセッサによって実行されると、顧客サイトのユーティリティネットワークにおける需要応答事象を制御するための方法をプロセッサに実行させる、コンピュータプログラムのコンピュータ可読命令を備える持続性コンピュータ可読媒体が提供される。本方法は、利用可能な需要応答事象の数を決定するステップと、利用可能な需要応答事象を発行するために利用可能な機会の数を決定するステップと、需要応答事象ごとに優先順位を提供するステップとを含む。本方法は、選択された需要応答トリガの観測値よりしきい値の方が低い、利用可能な需要応答事象の中から優先順位の最も高い需要応答事象を選択するステップと、現在の機会のために選択された需要応答事象を利用するために、通信ネットワークを介して制御信号を顧客サイトに出力するステップとをさらに含む。

本発明のこれらおよび他の特徴、態様、および利点は、添付の図面を参照して以下の詳細な説明を読めば、より良く理解されるだろう。図面を通じて、同様の記号は同様の部分を表す。

本システムの実施形態による、ユーティリティ事業者の電力分配システムの概略図である。 本発明の実施形態による、図１のリモートロケーションコントローラの概略図である。 本発明の実施形態による、需要応答事象の割当て方法に関わるステップを表す流れ図である。 本発明の実施形態による、利用可能な需要応答事象の数を決定する方法に関わるステップを表す流れ図である。

本明細書に記載の実施形態は、エネルギー管理システム、およびユーティリティ事業者が一定期間の間に需要応答事象の使用を最適化することを可能にする方法を対象とする。本発明の実施形態は需要応答の関連で記述されるが、当業者には、本方法およびシステムは、再生可能な（たとえば、風力または太陽光）発電機もサポートするためにバッテリストレージシステムを充電／放電するタイミングを決定することを含む、エネルギー管理の他の態様のために使用されうることが理解されよう。

本明細書で使用されるように、「モジュール」、または「コントローラ」という用語は、ソフトウェア、ハードウェア、またはファームウェア、あるいはこれらの任意の組合せ、若しくは任意のシステム、あるいは本明細書に記載の処理を実行する、または容易にする機能を指す。

需要応答または負荷削減は、一般的に、需要を減らすか、または負荷を削減して、それによって電力のピーク需要を減らすことを消費者に奨励するために使用されるメカニズムを指すために使用される。発電および送電システムは、一般的にピーク需要（ならびに予測許容誤差および予測不能事象）に対応するように大きさを決められるため、ピーク需要を低下させることによって、全体的なプラントおよび資本コスト要件を減らすことができる。ユーティリティ事業者が、参加している顧客について需要応答事象のタイミング、頻度、および期間についての契約上の義務を指定するプログラムの例には、緊急ピーク時課金（ＣＰＰ）、可変ピーク時課金（ＶＰＰ）および他の様々なインセンティブプログラムなどの需要応答プログラムがある。たとえば、契約は、ユーティリティ事業者が年間に最大１５の事象を呼び出すことができ、それぞれの事象は午後１２時から午後６時の間に、年間に最大で合計６０時間発生することを指定しうる。一実施形態では、ユーティリティ事業者は、負荷のバランスを取るために、それぞれ６時間の事象を１０個、またはそれぞれ４時間の事象を１５個、あるいは顧客ごとに１５個の事象および６０時間の制限内になるように他の任意のこのような事象および時間の組合せを使用することを選択できる。

顧客が需要応答（ＤＲ）プログラムに加入すると、一般的にユーティリティ事業者は、所与の時間内に事象を呼び出すための限られた数の機会、たとえば年間１５個の事象を有する。これらの事象は、そうすることが最も有益であるときに呼び出されることが所望される。エネルギー管理システムの実施形態によれば、ユーティリティ事業者（あるいは他の付加サービスエンティティまたは需要アグリゲータ）は、ＤＲプログラムからの節約量が最大になるようにピーク時の電力需要を削減する／ずらすために顧客に割り当てられた利用可能な数の需要応答（ＤＲ）事象を最適に管理する。

図１は、本システムの実施形態による、ユーティリティ事業者の電力分配システム３０を示している。たとえ本明細書に電力分配システムが示されていても、実施形態は電力伝送システムなどの他のシステムに均等に適用可能である点に留意されたい。電力分配システム３０は、配電変電所３２、それぞれのローカルコントローラ３６を備えた複数の需要応答（ＤＲ）リソースまたは負荷３４、およびリモートロケーションコントローラ３８を含む。配電変電所３２は、フィーダー３５を通じて住宅、工業、または商業負荷を含みうるＤＲリソース３４に電力を供給する。ローカルコントローラ３６は、中央コントローラ３８との通信に基づいて、フィーダー３５からＤＲリソース３４を切断または再接続する、中継回路または他の類似の回路を含みうる。本システムの実施形態の記述を容易にするために、図１には単一のフィーダー３５、単一のリモートロケーションコントローラ３８、および配電変電所３２が示されている。しかし、実施形態はこれらの数に限定されず、ユーティリティネットワーク内に任意の数のフィーダー、リモートロケーションコントローラ、および配電変電所があってよいことが理解されるべきである。さらに、リモートロケーションコントローラ３８は、ユーティリティ事業者によって、または他の任意の当事者によって構成および／またはホストされうる。

リモートロケーションコントローラ３８は、需要応答リソース３４を制御するためにローカルコントローラ３６と通信する。前述のように、需要応答リソース３４を所有する顧客は、ユーティリティ事業者、またはエネルギー小売業者などの類似の当事者を備える１つまたは他の需要リソースプログラムに加入している。一実施形態では、加入した需要応答プログラムのタイプに基づいて、顧客を様々なグループに分割できる。したがって、リモートロケーションコントローラ３８からローカルコントローラ３６への通信は、フィーダー３５、または一般的に電力網上の全体的な負荷需要、および顧客が加入したＤＲプログラムに基づいて決定される。リモートロケーションコントローラ３８は、分散システム３０の動作および維持のために利用される監視制御データ収集（ＳＣＡＤＡ）システム（図示せず）などの他のコントローラの一部でもよい。一実施形態では、ローカルコントローラ３６は、負荷３４とリモートロケーションコントローラ３８との間の通信を容易にするスマートメーターでよい。リモートロケーションコントローラ３８とローカルコントローラ３６との間の通信モードは、光ファイバー、電力線搬送システム、および様々な無線技術を含みうる。他の実施形態では、ローカルコントローラ３６は第３のロケーションで顧客によって保持される場合があり、次いで、リモートロケーションコントローラ３８からの制御信号に応じて、顧客は１つまたは他の通信技法によって負荷３４を移動させることができる。

一実施形態では、リモートロケーションコントローラ３８およびローカルコントローラ３６は、これに限定されないが、少なくとも１つのマイクロプロセッサ、マイクロコントローラ、グラフィックプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、または他の何らかのタイプのプロセッサまたは処理回路などのプロセッサ（図示せず）を含みうる。プロセッサは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリなどのメモリ、１つまたは複数のハードドライブ、ならびに／またはリムーバブルメディアやディスプレイを操作する１つまたは複数のドライブさらに含みうる。

図２は、図１のリモートロケーションコントローラ３８の一例のブロック図を示している。リモートロケーションコントローラ３８は、需要応答（ＤＲ）モジュール４０、メモリ４２、ユーザインターフェースモジュール４４、ネットワーク管理モジュール（ＮＭＳ）４６、およびデータベース（ＤＢ）４８を含む。ネットワーク管理モジュール４６は、ＤＲモジュール４０、顧客サイト（ＤＲリソース３６）、およびユーティリティ事業者のために通信管理およびプロビジョニングを提供する。データベース４８は、ネットワーク内のいくつかの顧客サイトについて履歴データなどのデータを格納する。履歴データは、たとえば負荷のタイプ、使用時刻（ＴＯＵ）、使用期間、削減および需要応答事象を含む顧客のユーティリティ利用法についての情報を含みうる。データベース４８に格納された顧客利用法情報は、２４時間周期にわたる１時間ごとの負荷および１時間ごとの価格データを含む負荷データ、気象情報（温度、湿度、風速、暖房温度および冷房温度）を含む環境データ、ならびに曜日、季節等の日付および時間情報を周期的に（たとえば、毎時、毎日）更新できる。さらに、データベース４８は各顧客サイトについての事象データを格納する。より具体的には、データベース４８は、顧客サイトが需要応答事象に参加したかどうか、その開始時刻および終了時刻、曜日、季節等についての履歴情報を格納する。ユーザインターフェースモジュール４４は情報をオペレータに提供する。ユーザインターフェースモジュール４４は、たとえばキーボードまたはタッチスクリーンを含みうる。

ＤＲモジュール４０は、全てのＤＲプログラムを格納して、所与の期間のネットワーク上の負荷を減らすために需要応答事象を呼び出すかどうかを決定するために顧客サイトおよびユーティリティ事業者からの情報を利用する。一実施形態によれば、ＤＲモジュール４０は、利用可能な需要応答事象などの合計数、利用可能な機会の数（すなわち、需要応答事象を利用するためのピーク負荷状態の将来の期間）、および需要応答事象を利用することのコストおよび利点などの要素の数に基づいて、少なくとも１つのしきい値または決定基準を計算する。たとえば、しきい値は温度値でもよく電気の市場価格でもよい。他の実施形態では、複数の需要応答事象について複数のしきい値が決定される。言い換えれば、顧客は様々な需要応答プログラムに加入でき、それぞれの需要応答プログラムに関連する需要応答事象のグループごとにしきい値が決定される。需要応答プログラムの例には、一定期間緊急ピーク時価格（ＣＰＰ−Ｆ）プログラム、可変ピーク時価格（ＶＰＰ）プログラム、可変期間緊急ピーク時価格（ＣＰＰ−Ｖ）プログラム、複数グループ緊急ピーク時価格（ＣＰＰ−Ｇ）プログラム、および複数の需要応答（ＭＤＲ）プログラムがある。

ＣＰＰ−Ｆプログラムでは、ユーティリティ事業者が緊急ピーク時負荷またはＣＰＰ事象を呼び出して、エネルギーの利用に対してより高い価格を課金する機会と引き換えに、年間を通じて割引料金を提供する。通常の日には、顧客は標準的な均一料金表よりも低い料金を支払う。ＣＰＰ事象の日には、ユーティリティ事業者は通常１日前に顧客に通知して、事象時間帯の間はより高いレート（通常レートの３〜１０倍）を課金する。顧客は事象の間のエネルギー利用を削減するかずらすことによって節約量を最大にすることができるので、ほとんどの顧客にとって有益である。同時に、ユーティリティ事業者はピーク低減という目標を達成できる。ＣＰＰプログラムの特徴は、一般的に契約期間に応じてユーティリティ事業者が１年／季節につき呼び出すことができる事象の数は限られているということである。たとえば、サウザンカリフォルニアエジソン（ＳＣＥ）によって提供されるＣＰＰプログラムは、事象の数を夏の季節につき１５以下に限定する。このプログラムの下で、参加者はＣＰＰ事象が引き起こされる１日前の午後３時までに通知される。ＣＰＰ事象の日には、平日の午後２時から午後６時の間に発生する全ての電気利用に対してより高い「緊急ピーク時」エネルギー課金が課される。

ＶＰＰプログラムでは、ユーティリティ事業者は、ピーク時負荷および発電コストの重大度に応じて、事象の日にいくつかの異なる価格を課金しうる。たとえば、任意の１つの季節において、ユーティリティ事業者は５つの緊急ピーク時事象、５つの高ピーク事象、および１０の低ピーク事象を呼び出すことができ、これらの事象の価格はそれに応じて異なる。ＣＰＰ−Ｖでは、１年につき最大１５回、２時間から６時間の範囲の時間にわたって１つの事象が呼び出されうる。さらに、合計事象回数は、たとえば１つの季節につき６０時間を超えることができず、これらの６０時間の価格はあらかじめ定められている。さらに、ＣＰＰ−Ｇ住宅顧客を同じ大きさの複数のグループに分割でき、それぞれの事象をグループの１つのサブセットについてのみ呼び出すことができる。全てのグループの事象の合計数は定められている。トリガされると、各グループは１つの事象内に同じ期間を有するが、グループを送出できるより大きい事象時間帯がある。１つの事象の間により多くのグループを呼び出すと、通常は先に選択したグループが既にピーク負荷を減らしているため、後から選択したグループからの利益を損なうことになる。さらに、ＭＤＲプログラムでは、異なるタイプの顧客（たとえば、住宅、商業、および工業）について異なるプログラムがある。このような場合の目的は、どれだけ多くの各顧客タイプを送出するべきかを決定することである。

一実施形態では、ＤＲモジュール４０は、これらのＤＲプログラムに関連するＤＲ事象タイプごとにしきい値を決定する。たとえばＶＰＰでは、ＤＲモジュールは、３つの可変ピーク時価格がある場合、３つのしきい値を決定できる。ユーティリティ事業者はこれらのしきい値を利用して、全体的なコスト利点を最適化できるように、需要応答事象を呼び出すタイミングを決定する。需要応答事象は、切換えを通じてユーティリティ事業者によって直接制御されるか、顧客サイトに送信されたコマンドを介してユーティリティ事業者によって自動的に制御されるか、あるいはローカルコントローラ３６を介して顧客サイトで顧客によって実施される。より具体的には、需要応答は、ユーティリティ事業者が契約によって合意したデバイス（たとえば、ＨＶＡＣユニット）を遠隔でオフに切り換えるか、負荷制御信号をローカルコントローラ３６に送信できるような、直接的または間接的な負荷制御によって実施することができる。

図３は、本技法の実施形態による、需要応答事象の割当て方法を示す流れ図６０である。一実施形態では、本方法はＤＲモジュール４０によって実施されうる。流れ図６０内のステップは、ユーティリティ事業者が遭遇する需要応答の機会ごとに繰り返されうる点に留意されたい。６２で、利用可能な需要応答事象の数が、顧客が加入した複数の需要応答プログラムに基づいて決定される。一実施形態では、ＤＲ事象期間が固定されている場合、利用可能なＤＲ事象の数を事前に知ることができ、またデータベースから読み出すことができる。しかし、さらなる実施形態では、ＣＰＰ−ＶまたはＣＰＰ−ＧなどのＤＲプログラムが利用される場合、ＤＲ事象の期間は異なる場合があり、したがって利用可能な需要応答事象の数を事前に知ることができない。このような場合、利用可能な需要応答事象の数は履歴データに基づいて導き出すことができ、その詳細を本明細書で提供する。

６４で、利用可能な需要応答事象を発行するために利用可能な機会の数が、選択されたＤＲトリガの確率分布に基づいて決定される。選択されたＤＲトリガは温度でもよく、市場価格でもよい。選択されたＤＲトリガの確率分布は、履歴データ、または選択されたＤＲトリガの任意の予測方法、あるいはそれらの任意の組合せに基づいて決定されうる。機会の発生は一定ではない点に留意されたい。たとえば、１日に２つの機会がある場合もあり、１週間に２つの機会がある場合もある。６６では、需要応答事象ごとの優先順位が提供される。一実施形態では、優先順位はＤＲ事象ごとの価格レベルに基づき、たとえば、価格レベルが高ければそれだけ優先順位が高い。

６８で、需要応答事象ごとのしきい値が、利用可能な需要応答事象の数、利用可能な需要応答事象を発行するために利用可能な機会の数、および選択された需要応答トリガの確率分布に基づいて決定される。７０で、現在の機会のために選択されたＤＲトリガの観測値よりしきい値の方が低い、利用可能な需要応答事象の中で優先順位が最も高い需要応答事象が選択される。最後に、７２で、選択された需要応答事象を利用するために、通信ネットワークなどを介して顧客サイトに制御信号が送信される。制御信号は、需要応答事象を利用するために、直接負荷を制御するための負荷信号を含んでもよく、負荷が直接制御されない場合、顧客を示す他の任意の信号を含んでもよい。本方法の処理のシーケンスは交換可能でよく、いくつかのステップが並列に処理されてもよい点に留意されたい。

一実施形態では、需要応答事象または事象の優先順位ごとのしきい値は、以下の式によって与えられる最適ポリシー関数（ｏｐｔｉｍａｌ ｐｏｌｉｃｙ ｆｕｎｃｔｉｏｎ）σ^* _m,nによって定義されうる。

上式で、ｍおよびｎは、それぞれセットＭ＝｛１，．．．，Ｍ｝、およびＮ＝｛１，．．．，Ｎ｝に属する。一般的に、本明細書では、現在の決定ポイントでは、ユーティリティ事業者はＮ日の範囲（ｈｏｒｉｚｏｎ）を介して実行するべきＭ個の合計事象を有し、Ｖ_m,nは提供されたＭとＮの値を有するユーティリティ事業者への集約節約量を表すと仮定される。この式では、ｃ_nは選択されたＤＲトリガ（温度または市場価格）によって決定された節約量の値である。ＤＲトリガが市場価格の場合、ｃ_nは、決定範囲にｎ日が残っている場合、高温の日または低温の日のピーク価格分散に基づく。高温日の分散から節約量の値ｃ_nを取るか、低温日の分散から節約量の値ｃ_nを取るかの決定は、温度のしきい値に基づく。一実施形態では、温度しきい値は華氏８０度でよく、華氏８０度を下回る日と華氏８０度を超える日との間の価格における平均差は統計的に有意であることを示している。したがって、現在の日の温度が８０度よりも高い場合、節約量の値ｃ_nはより高温日の分散から選択されてよく、８０度よりも低い場合、より低温日の分散からの節約量の値ｃ_nが選択される。

一実施形態では、再帰に基づいて、需要応答事象ごとのしきい値の数学的特性を導き出すことができる。ｃ_nの三角分布について、最適しきい値σ^* _m,nが分析的に計算されうる。ｃ_nの通常分布について、Ｖ_m,nおよびσ^* _m,nを推定するためにモンテカルロシミュレーションが使用されうる。次いで、ダイナミックプログラミング再帰が後方誘導によって解決される。

図４は、本技法の実施形態による、利用可能な需要応答事象の数を決定する一方法を表す流れ図８０である。本明細書に記載されるように、場合によっては利用可能な需要応答事象の数は事前に知ることができるが、ＶＰＰプログラムなどの他の場合では需要応答事象の数を導き出す必要がある。８２で、考慮されているＤＲプログラムのタイプごとの利用可能な需要応答事象の数が事前に知られているかどうかがまず決定される。数が事前に知られている場合、９０で、タイプごとの需要応答事象の数が出力される。ＤＲプログラムのタイプごとの利用可能な需要応答事象の数が知られていない場合、方法は８４に移動して新しい数を決定する。８４で、最適なＤＲ事象スケジューリングの２進整数プログラムが形成されて、８６で、前年のデータなどの履歴を使用して２進整数プログラムが解決される。最後に、８８で、ＤＲプログラムの合計タイプの数、およびタイプごとの利用可能な需要応答事象の数が決定されて、９０で、２進整数プログラムの制約を満たすために、いくつかの四捨五入および／または調整で前年の最適な数を平均化することによって出力される。

一実施形態では、ＤＲプログラムタイプがＣＰＰ−Ｖの場合、最適なＤＲ事象スケジューリングの２進整数プログラムの数学的モデルは以下のように与えられうる。

以下の制約を受ける。

上式で、ｋはセットＫ＝｛１，．．．，Ｋ｝に属し、ｎはセットＮ＝｛１，．．．，Ｎ｝に属し、それぞれ優先順位の数のセットおよび日の数のセットを表している。上式で、ｄ_kは優先順位ｋの事象のグループの期間または数であり、ｃ_k,nは、任意の優先順位ｋの事象がｎの日にトリガされる場合の最大累積節約量であり、ｔは利用可能な事象の合計数であり、ｈは利用可能な時間の合計数である。さらに、ｘ_k,nは２進決定変数であり、優先順位ｋの事象がｎの日に割り当てられる場合は１であり、そうでない場合は０である。一実施形態では、ｋの値が高ければそれだけ優先順位が高い。ここでの制約は、全ての利用可能な事象の合計は事象ｔの合計数を決して超えてはならず、利用可能な事象の合計にそれらの時間をかけたものは、利用可能な時間の合計数を超えてはならないことを示している。他の実施形態では、制約のうちのいくつかが省略されてもよく、および／または新しい制約が追加されてもよい。

他の実施形態では、ＤＲプログラムタイプがＣＰＰ−Ｇの場合、最適なＤＲ事象スケジューリングの２進整数プログラムの数学的モデルは以下のように与えられうる。

以下の制約を受ける。

上式で、αはｌ−１グループからのｌグループの節約量の割引係数である。以前の場合のように、ここでの制約は、全ての利用可能な事象の合計は事象ｔの合計数を決して超えてはならず、またさらに、利用可能な事象の合計にグループのそれぞれの数をかけたものが、事象ｔの合計数とグループの合計数との積を超えてはならないことを示している。

式（３）のある例示的ソリューションを以下の表１に表す。表１では、２００９年の利用可能な需要応答事象の数は、２００４年から２００８年の履歴データから決定される。

したがって、タイプごとの利用可能な需要応答事象の数を決定でき、それらのしきい値とともに、利用可能な需要応答事象の数を利用して需要応答を最適に管理できる。

本明細書では本発明の一定の特徴だけを図示および記述してきたが、当業者には多くの修正および変更が想起されるであろう。したがって、添付の特許請求の範囲は、こうした修正や変更の全てを本発明の真の精神の範囲に属するものとして包含することを意図していることが理解されるべきである。

３０ 電力分散システム
３２ 配電変電所
３４ 需要応答（ＤＲ）リソースまたは負荷
３５ フィーダー
３６ ローカルコントローラ
３８ リモートロケーションコントローラ
３８ 中央コントローラ
４０ 需要応答（ＤＲ）モジュール
４２ メモリ
４４ ユーザインターフェースモジュール
４６ ネットワーク管理モジュール（ＮＭＳ）
４８ データベース（ＤＢ）
６０ 流れ図
８０ 流れ図

Claims (20)

1. 利用可能な需要応答事象の数を決定するステップと、
   前記利用可能な需要応答事象を発行するために利用可能な機会の数を決定するステップと、
   需要応答事象ごとに優先順位を提供するステップと、
   需要応答事象ごとにしきい値を決定するステップと、
   選択された需要応答トリガの観測値よりしきい値の方が低い、前記利用可能な需要応答事象の中から優先順位の最も高い需要応答事象を選択するステップと、
   現在の機会のために前記選択された需要応答事象を利用するために、通信ネットワークを介して制御信号を顧客サイトに送信するステップとを備える、需要応答管理のための方法。
2. 前記利用可能な需要応答事象が、顧客が加入している複数の需要応答プログラムを備える、請求項１記載の方法。
3. 前記複数の需要応答プログラムが、一定期間緊急ピーク時価格（ＣＰＰ−Ｆ）プログラム、可変ピーク時価格（ＶＰＰ）プログラム、可変期間ＣＰＰ（ＣＰＰ−Ｖ）プログラム、複数グループＣＰＰ（ＣＰＰ−Ｇ）プログラム、および複数の需要応答（ＭＤＲ）プログラムのうちの少なくとも１つを備える、請求項２記載の方法。
4. 利用可能な需要応答事象の前記数を決定するステップが、データベースから知られている数を取得するステップ、または履歴データに基づいて新しい数を導き出すステップを備える、請求項１記載の方法。
5. 前記新しい数を導き出すステップが、
   最適な需要応答事象スケジューリングの２進整数プログラムを形成するステップと、
   前年のデータを使用して前記２進整数プログラムを解決するステップと、
   タイプごとに、需要応答プログラムおよび利用可能な需要応答事象の合計タイプを決定するステップと、
   タイプごとに前記新しい数の需要応答事象を出力するステップとを備える、請求項４記載の方法。
6. 前記最適な需要応答事象スケジューリングの前記２進整数プログラムが、複数の制約を備える累積的な節約量を最大にする最適化モデルを備える、請求項５記載の方法。
7. 前記複数の制約が、
   全ての利用可能な事象の合計が事象の前記合計数以下であることと、
   利用可能な事象の合計にそれらの期間をかけたものが、利用可能な時間の前記合計数以下であることと、
   利用可能な事象の合計にグループのそれぞれの数をかけたものが、グループの前記合計数を備える事象の前記合計数の積以下であることのうちの少なくとも１つを備える、請求項６記載の方法。
8. 前記利用可能な需要応答事象を発行するために利用可能な機会の前記数が、選択された需要応答トリガの確率分布に基づく、請求項１記載の方法。
9. 前記選択された需要応答トリガが、温度値、電気の市場価格値、またはそれらの組合せを備える、請求項８記載の方法。
10. 前記選択された需要応答トリガの前記確率分布が、履歴データ、または前記選択された需要応答トリガの予測方法、あるいはそれらの任意の組合せに基づいて決定される、請求項８記載の方法。
11. 需要応答事象ごとの前記優先順位が価格レベルに基づく、請求項１記載の方法。
12. 需要応答事象ごとの前記しきい値が、利用可能な需要応答事象の前記数、前記利用可能な需要応答事象を発行するために利用可能な機会の前記数、および前記選択された需要応答トリガの確率分布に基づく、請求項１記載の方法。
13. 需要応答リソースを制御するためのローカルコントローラと、
    前記ローカルコントローラおよびユーティリティ事業者と通信可能に結合されたリモートロケーションコントローラとを備え、前記リモートロケーションコントローラが、
    利用可能な需要応答事象の数を決定して、
    前記利用可能な需要応答事象を発行するために利用可能な機会の数を決定して、
    需要応答事象ごとに優先順位を提供して、
    需要応答事象ごとにしきい値を決定して、
    選択された需要応答トリガの観測値よりしきい値の方が低い、前記利用可能な需要応答事象の中から優先順位の最も高い需要応答事象を決定するように構成された需要応答モジュールを備える、ユーティリティネットワークにおける需要応答事象を制御するためのシステム。
14. 前記利用可能な需要応答事象が、顧客が加入している複数の需要応答プログラムに対応する需要応答事象を備える、請求項１３記載のシステム。
15. 前記複数の需要応答プログラムが、一定期間緊急ピーク時価格（ＣＰＰ−Ｆ）プログラム、可変ピーク時価格（ＶＰＰ）プログラム、可変期間ＣＰＰ（ＣＰＰ−Ｖ）プログラム、複数グループＣＰＰ（ＣＰＰ−Ｇ）プログラム、および複数の需要応答（ＭＤＲ）プログラムのうちの少なくとも１つを備える、請求項１４記載のシステム。
16. 利用可能な需要応答事象の前記数を決定するステップが、履歴データに基づいて新しい数を導き出すステップを備える、請求項１３記載のシステム。
17. 前記新しい数を導き出すステップが、
    最適な需要応答事象スケジューリングの２進整数プログラムを形成するステップと、
    前年のデータを使用して前記２進整数プログラムを解決するステップと、
    タイプごとに、需要応答プログラムおよび利用可能な需要応答事象の合計タイプを決定するステップと、
    タイプごとに前記新しい数の需要応答事象を出力するステップとを備える、請求項１６記載のシステム。
18. 前記利用可能な需要応答事象を発行するために利用可能な機会の前記数が、選択された需要応答トリガの確率分布に基づく、請求項１３記載のシステム。
19. 前記選択された需要応答トリガが、温度値、電気の市場価格値、またはそれらの組合せを備える、請求項１８記載のシステム。
20. 少なくとも１つのプロセッサによって実行されると、顧客サイトのユーティリティネットワークにおける需要応答事象を制御するための方法を前記プロセッサに実行させる、コンピュータプログラムのコンピュータ可読命令を備える持続性コンピュータ可読媒体であって、前記方法が、
    利用可能な需要応答事象の数を決定するステップと、
    前記利用可能な需要応答事象を発行するために利用可能な機会の数を決定するステップと、
    需要応答事象ごとに優先順位を提供するステップと、
    需要応答事象ごとにしきい値を決定するステップと、
    選択された需要応答トリガの観測値よりしきい値の方が低い、前記利用可能な需要応答事象の中から優先順位の最も高い需要応答事象を選択するステップと、
    現在の機会のために前記選択された需要応答事象を利用するために、通信ネットワークを介して制御信号を顧客サイトに出力するステップとを備える、持続性コンピュータ可読媒体。