JP2011134325A - ネットワークにおける需要応答管理方法及びシステム - Google Patents

Abstract

【課題】多数の顧客サイト（１０４）を持つユーティリティ・ネットワークにおける需要事象を制御するための方法及びシステム（１００）を提供する。
【解決手段】需要応答事象を起動するための需要応答パラメータ閾値の値が、利用可能な需要応答事象の数と、利用可能な需要応答事象を発行するために残っている機会の数とに基づいて、計算される。このパラメータは、需要応答プログラムを使用するためのユーティリティ目標（例えば、コスト節約、信頼性、コスト回避）を表す。需要応答パラメータの現在値が閾値と比較され、この比較に基づいて現在の機会のために需要応答事象を呼び出すかどうか又は将来の機会のために該事象を保存するかどうか決定される。
【選択図】図１

Description

本発明は、ネットワークにおける需要応答を管理するための方法及びシステムに関するものである。

需要応答(demand response) は、総ユーティリティ（電気・ガス・水道など）需要を低減するために特定の時間における消費者の需要を削減又はずらすようにユーティリティ消費者に働きかけ／勧誘するために用いられる仕組みを表す。例えば、電気事業者は、電気のピーク需要を低減する需要応答策を採用している。需要応答プログラムは、典型的には、或る特定の時間における消費者の需要を低減することに合意させるための奨励策を消費者に提案している。これらのプログラムの多くは、ユーティリティ事業者が所与の期間内に限られた数（例えば、毎年２０回）の需要応答／削減事象（例えば、臨界的ピーク価格設定(critical peak pricing)事象）を起動できることを規定している。従って、ユーティリティ事業者は、ユーティリティ需要及び生成コストが最大である場合にのみ削減事象を起動したいであろう。しかしながら、天候を含む様々な理由により、ユーティリティ需要は、特に将来の長期間にわたって、確信を持って予測することができない。短期間の（例えば、２４時間以内の）需要は妥当な範囲内で知ることができるが、長期間の（数週間以上の）需要はせいぜい確率分布として推定できるに過ぎない。

従来、ユーティリティ事業者は、典型的には、需要応答又は削減事象を起動するタイミングを決定するために、温度又は予備余裕のような簡単な発見的手法に基づくトリガーを使用している。しかしながら、この方法は、利益、節約量及び／又は他の基準が最適化されるように、経済的な負荷制限又は削減のオプションを行う最良の機会をユーティリティ事業者に与えていない。これらの及び他の理由で、本発明が必要になる。

米国特許第７３５９８７８号

多数の顧客サイトを持つユーティリティ・ネットワークにおける需要事象を制御するための方法及びシステムを提供する。需要応答事象を起動するための需要応答パラメータ閾値の値が、利用可能な需要応答事象の数と、利用可能な需要応答事象を発行するために残っている機会(opportunity) の数とに基づいて、計算される。このパラメータは、需要応答プログラムを使用するためのユーティリティ事業目標（例えば、コスト節約、信頼性、コスト回避）を表す。需要応答パラメータの現在値が閾値と比較され、この比較に基づいて現在の機会のために需要応答事象を呼び出すかどうか又は将来の機会のために該事象を保存するかどうか決定される。

本発明の性質及び様々な追加の特徴は、図面に概略図で示した本発明の実施例を考慮したときより完全に明らかになろう。同様な参照数字は対応する部分を表す。

図１は、本発明の一実施形態に従ったユーティリティ管理システムを例示する。 図２は、本発明の一実施形態に従った、図１に示されたシステムに関連した閾値発生プロセスの流れ図である。 図３は、本発明の一実施形態に従った模範的な需要応答事象決定の流れ図である。

上記の図は選択的な実施形態を示しているが、以下の説明で述べるように、本発明の他の実施形態も考えられる。いかなる場合でも、本開示は、限定ではなく、代表例として、本発明の例示の実施形態を表す。本発明の原理の範囲及び精神に含まれる多数の他の変更及び実施形態が当業者には考案できよう。

本書に述べる実施形態は、ユーティリティ事業者が或る特定の期間中の需要応答又は削減事象の使用を最適化できるようにするエネルギ管理方法及びシステムを対象とする。本発明の実施形態をエネルギ又は電気事業に関連して説明するが、当業者には、本発明の方法及びシステムが他の目的又はユーティリティ事業のために用いることができることが理解されよう。

本書で用いられる用語「モジュール」とは、ソフトウエア、ハードウエア、ファームウエア、又はそれらの任意の組合せ、或いは、任意のシステム、プロセス、又は本書で述べられるプロセスを遂行又は容易化する機能を表す。

本発明の実施形態に従った負荷削減又は需要応答は、ユーティリティ事業者が削減又は臨界的ピーク価格設定事象を呼び出すべきタイミングを決定するのを可能にする。本発明の実施形態によれば、ユーティリティ事業者（又は他の負荷サービス事業者又は需要集積者）は、需要応答事象を起動するかどうか決定するため、先ず、需要応答を使用するための利益／値を最大にする目標を定める。次いで、ユーティリティ事業者は、値パラメータを決定する需要、市場価格、温度などのような将来値に基づくものである値パラメータを特定する。将来における各々の機会のための値パラメータを構成する変数の確率分布を考慮することによって、事象を起動するための判定基準を設定するために用いられるパラメータの値は、削減事象を用いる際の値が、それが現在の機会のために用いられない場合の削減事象の予想される将来値を越える場合にのみ、ユーティリティ事業者が削減事象を起動するように、計算することができる。決定には、顧客を介してユーティリティ事業者に利用可能である削減又は需要応答の数、需要応答事象を呼び出すための機会の数（例えば、利用可能な日数又は時間など）を考慮して、利用可能な事象の新しい値及び機会の数に基づいて各機会の後の値パラメータについての更新閾値を計算し、且つ将来における各機会のための値パラメータを構成する変数の確率分布を計算する。

本発明の実施形態は、ｄ_ｍｎの値、すなわち、ｎ個の機会に対してｍ個の事象が残っている場合の判定基準のための閾値を含む。これらの値は、任意の所与のシナリオについて需要応答事象を開始するかどうか決定するために用いることのできるルックアップ・テーブルに配列することができる。基準は、節約量(savings) 、最高温度、又はユーティリティ事業者のための任意の他の適当な基準であってよい。今日の値が判定基準よりも良好である場合には、事象を呼び出すべきである。そうでない場合、その機会を別の時のために保存すべきである。

図１に、本発明の一実施形態に従った模範的なエネルギ管理システム１００が示されている。システム１００は、エネルギ管理サーバー１０２、顧客サイト１０４、及びユーティリティ事業者１３６を含む。本発明の実施形態の説明を容易にするために、図１には単一のサーバー１０２、単一のユーティリティ顧客１０４、及び単一のユーティリティ供給事業者１３６が示されている。しかしながら、本発明の実施形態はこれらの数に制限されないこと、並びにユーティリティ・ネットワーク内に任意の数のエネルギ管理サーバー、顧客サイト及び制御センタがあってよいことを理解されたい。更に、エネルギ管理サーバー１０２はユーティリティ事業者１３６又は任意の他の事業者の場所に配置し及び／又はそれらによってホスティングすることができる。

各々の顧客サイトは、プロセッサ１０８、メモリ１１０、ユーザーインターフェース１１２、及び表示装置１１４を含む。ユーザーインターフェース１１２は、例えば、キーボード又はタッチスクリーンを含むことができる。プロセッサ１０８は、負荷１１６、センサ１１８、再生可能なエネルギ源１２０、蓄電装置１２２、及びプラグイン型電気車両（ＰＥＶ）又はプラグイン型ハイブリッド電気車両（ＰＨＥＶ）１２４のような様々な顧客装置の動作を監視し制御するためのプログラムを実行する。センサ１１８は、メータ、サーモスタット、居住センサ、湿度計、及び他の適当な装置を含む。再生可能な資源１２０は、例えば、太陽光及び／又は風力装置を含むことができる。プロセッサ１０８は、例えば、Ｚｉｇｂｅｅ、Ｚ−Ｗａｖｅ又はＨｏｍｅｐｌｕｇを含む多数のインターフェース又はプロトコルの内の任意のものを使用して様々な構成要素を制御する。顧客サイト１０４とサーバー１０２とユーティリティ事業者１３６との間の通信は、例えば、ＷＡＮ（例えば、インターネット）１０６、ＷｉＭＡＸ、ブロードバンド、ＡＭＩ、及び／又は電力線搬送波を介して行われる。通信はまた、専用ネットワークを介して行うことができる。通信のための任意の適当な手段を用いることができる。

エネルギ管理サーバー１０２は、需要応答（ＤＲ）モジュール１２６、メモリ１２８、ユーザーインターフェース・モジュール１３０、ネットワーク管理モジュール（ＮＭＳ）１３２、及びデータベース（ＤＢ）１３４を含む。ネットワーク管理モジュール１３２は、ＤＲモジュール１２６、顧客サイト１０４及びユーティリティ事業者１３６のために通信管理及びプロビジョニング(provisioning)を提供する。データベース１３４は、ネットワーク内の各顧客サイトについて履歴データのようなデータを記憶する。履歴データは、例えば、負荷の種類、使用時刻（ＴＯＵ）、使用期間、制限又は需要応答事象を含む顧客のユーティリティ使用法についての情報を含むことができる。データベース１３４に記憶された顧客使用法情報は周期的に（例えば、１時間毎に、毎日）更新することができ、２４時間周期にわたる１時間毎の負荷及び１時間毎の価格を含む負荷データ、気象情報（温度、湿度、風速、暖房温度及び冷房温度）を含む環境データ並びに曜日、季節などのような日付及び時間情報を有する。更に、データベース１３４は、各顧客サイトについての事象データを記憶する。より詳しく述べると、データベース１３４は、顧客サイトが需要応答事象に参加したかどうか、その開始時刻及び終了時刻、曜日、季節などについての履歴情報を記憶する。ユーザーインターフェース・モジュール１３０はオペレータに情報を供給する。

ＤＲモジュール１２６は顧客サイト１０４及びユーティリティ事業者１３６からの情報を利用して、ネットワーク上の負荷を低減するために需要応答事象を呼び出すかどうか決定する。本発明の実施形態によれば、ＤＲモジュール１２６は、利用可能な需要応答事象及び利用可能な機会の数に基づいて少なくとも１つの閾値又は判定基準を計算する。ユーティリティ事業者はこの閾値を利用して、需要応答事象を呼び出すかどうか決定することによって需要応答事象の使用を最適化する。需要応答事象は、ユーティリティ事業者によって直接に制御され、又は顧客サイトに送られた指令を介してユーティリティ事業者によって自動的に制御され、又は顧客サイトで顧客によって実施される。より具体的に述べると、需要応答は、ユーティリティ事業者が契約によって合意した装置（例えば、ＨＶＡＣユニット）を遠隔でオフに切り換えるか又は顧客サイト１０４に負荷制御信号を送ることができるような、直接的又は間接的な負荷制御によって実施することができる。このとき、プロセッサ１０８で実行される家庭エネルギ管理システムにより、ユーティリティ事業者の必要条件／要求を満たすためにどの装置を削減すべきかどうか決定することができる。

本発明の実施形態は、ユーティリティ事業者が、残っている事象の数と、現在の機会のためのシステム状態（例えば、価格、予備余裕、需要など）と、残っている機会の数と、及び残っている機会にわたる（不確定範囲を含む）システム状態についての予測とに基づいて、各機会（この例では、期間）のための閾値又は判定基準（例えば、行使価格、温度など）を更新することによって、各機会における需要応答事象（オプション）を起動するかどうか決定することを可能にする。行動（例えば、ＤＲ事象）を起こすために所与の数の機会のみが利用可能である。各機会中に、事象を呼び出すことによる利益を表す値パラメータが計算される。値パラメータは、コスト、歳入、節約量又は任意のこのような尺度を表すことができる。本発明の実施形態は、値パラメータが最適化されるような行動を起こすタイミングを決定する。本発明の実施形態は、需要応答に適用されると共に、例えば再生可能なエネルギ（例えば、風力又は太陽光）発電機を支持するために蓄電池貯蔵システムを充電／放電するタイミングを決定することを含む他の面のエネルギ管理に適用される。

本発明の模範的な一実施形態によれば、ＤＲモジュール１２６は、所与の計画対象期間の間で、節約量が最大になるように電力事業者が経済的な負荷制限のオプションを実行すべき日にちを決定する。この例では、節約量は電力生成コストの関数であり、従って、コストがより高くなることは、負荷制限による節約量がより大きくなることを示唆している。その決定は、電力生成コストが最大になる日にちを選定することに相当する。この代わりに、毎日生成コストを、その日に経済的な負荷制限又は需要応答事象が実行された場合に実現されるであろう節約量と置き換えることができる。或る特定の日数の計画期間が与えられると、ユーティリティ事業者は計画期間にわたって毎日電力生成コストを予測する。毎日が現れるので、実際の毎日コストが生じる。このコストは、その日の電力生成コストから導き出される。ユーティリティ事業者は、その日の毎日コストが利用可能な負荷制限オプションの１つを実行するのに充分な大きさであるかどうか決定しなければならない。もしそのオプションが実行された場合、或る節約量が実現され、そして将来利用可能であるオプションが１つ少なくなる。もしそのオプションが実行されなかった場合、利用可能なオプションの数は同じだけ残る。そのオプションが実行されるか否かに拘わらず、オプションを実行するために残っている機会の数は１つだけ少なくなり、次の日にこのような次の機会が与えられる。

一般的に云えば、模範的な実施形態では、計画期間内の各々の日について閾値オプション値が作成され、この値はその日に制限オプションを呼び出すためのオプションを実行する能力を持つことから最適な予想節約量を表す。毎日遭遇するので、その日の実際の節約量が閾値に対して測定される。もし節約量が予想節約量よりも大きい場合、低減オプションを実行すべきである。そうではなくて、節約量が閾値よりも低い場合、該オプションは遅らせるべきであり、決定点は次の日に移動し、これは、残っているオプションについての最適な予想節約量及び計画期間を反映するそれ自身の閾値を持つ。毎日閾値を計算する詳細を以下に述べる。

判定基準又は閾値及び事象の合計予想値を計算するための一例を、ピーク価格設定事象を呼び出すべきであった場合の生成コストの節約量に関連して示す。しかしながら、他の規準を用いることができることを理解されたい。

多事象（又は行動）問題について毎日閾値を計算する。まず、
Ｃ_ｎ ＝「期間ｎにおける推定節約量」と定義し、Ｃ_ｎ は確率分布に従う、
Ｅ（Ｃ_ｎ ）＝「Ｃ_ｎ の予想値」と定義し、
Ｐ（Ｃ_ｎ ＞ｘ）＝「Ｃ_ｎ ＞ｘである確率」と定義し、
Ｖ_ｍｎ＝「ｎ個の期間に対してｍ個の行動が許可される場合の合計予想節約量」と定義し、
Ｄ_ｍｎ＝「ｍ個の行動が利用可能である場合の機会ｎのための判定基準」と定義する。

そこで、ｍ＝１の行動を考察すると：
既存の文献から、単一の行動からの予想節約量は、
Ｖ_１１＝Ｅ（Ｃ_１ ）
Ｄ_１１＝０
Ｄ_１ｎ＝Ｖ_{１，ｎ−１}
Ｖ_１ｎ＝Ｐ（Ｃ_ｎ ＞Ｖ_{１，ｎ−１}）＊Ｅ（Ｃ_ｎ ｜Ｃ_ｎ ＞Ｖ_{１，ｎ−１}）
＋［１−Ｐ（Ｃ_ｎ ＞Ｖ_{１，ｎ−１}）］＊Ｖ_{１，ｎ−１}
であるとき、最大になることが知られている。Ｖ_１ｎは、幾つかのよく定義された分布について解析により計算することができ、さもなければ、その推定のためにモンテカルロ・シミュレーション手法を用いることができる。

ｍ＝２以上の行動について、その方策を次のように表すことができる。すなわち、
ｎ≦ｍの場合：
ｎ≦ｍのとき、行動を遅らせると該行動を用いる機会を失うので、行動は各期間内に実行しなければならない。従って、この場合、各々のこのような期間における判定基準は０に設定される。更に、各期間に行動が起こされるので、各期間における節約量はコスト関数の予想値になる。従って、
ｎ＝１，２，．．．，ｍとして、Ｄ_ｍｎ＝０であり、また
ｎ＝１，２，．．．，ｍとして、

である。

ｎ＞ｍの場合：
現在の機会について行動を起こすか起こさないための損益分岐点を推定する。行動を起こさない（すなわち、遅らせる）場合、残りの（ｎ−１）個の機会に対してｍ個の行動が利用可能である。そこで、遅らせた場合の予想節約量はＶ_{ｍ，ｎ−１} である。他方、現在の機会について行動を起こした場合、残りの行動からＶ_{ｍ−１，ｎ−１} の節約量を予想することができる。従って、行動のための損益分岐点は、２つの間の差であって、現在の機会についての判定基準を表す。すなわち、
Ｄ_ｍｎ＝Ｖ_{ｍ，ｎ−１} −Ｖ_{ｍ−１，ｎ−１}
である。

合計予想節約量は、
Ｃ_ｎ ＞Ｄ_ｍｎ（＝Ｖ_{ｍ，ｎ−１} −Ｖ_{ｍ−１，ｎ−１} ）である場合、Ｖ_ｍｎ＝Ｃ_ｎ ＋Ｖ_{ｍ−１，ｎ−１} であり、また、そうでない場合は、Ｖ_ｍｎ＝Ｖ_{ｍ，ｎ−１} であり、
Ｖ_ｍｎ＝Ｐ（Ｃ_ｎ ＞Ｖ_{ｍ，ｎ−１} −Ｖ_{ｍ−１，ｎ−１} ）
＊Ｅ［（Ｃ_ｎ ｜Ｃ_ｎ ＞Ｖ_{ｍ，ｎ−１} −Ｖ_{ｍ−１，ｎ−１} ）＋Ｖ_{ｍ−１，ｎ−１} ］
＋［１−Ｐ（Ｃ_ｎ ＞Ｖ_{ｍ，ｎ−１} −Ｖ_{ｍ−１，ｎ−１} ）］＊Ｖ_{ｍ，ｎ−１}
になる。Ｖ_ｍｎは、幾つかのよく定義された分布について解析により計算することができ、さもなければ、その推定のためにモンテカルロ・シミュレーション手法を用いることができる。

一旦Ｄ_ｍｎが推定されると、ユーティリティ事業者の方策が作成される。より具体的に述べると、表１に示されているようなルックアップ・テーブルが作成される。この模範的な実施形態では、５日の計画期間にわたって３つの需要応答事象が利用可能であり、各日での節約量が範囲［９０，１１０］にわたって一様な分布に従うと仮定する。Ｖ_ｍｎを推定するためにシミュレーション手法が適用され、Ｖ_ｍｎはＤ_ｍｎを計算するために用いられる。

利用可能な５つの機会から開始して、ユーティリティ事業者はその方策に次のように従うことができる。計画された節約量が９８．４（Ｄ_３５）よりも大きい場合、節約を実現するために需要応答事象を実行すべきであり、次の機会では、別の需要応答事象を呼び出すための判定基準が９９．９（Ｄ_２４）になる。他方、利用可能な５つの機会による計画された節約量が９８．４（Ｄ_３５）よりも大きくない場合、需要応答事象は実行されず、需要応答事象を呼び出すための判定基準が９６．２（Ｄ_３４）になる。いずれの場合でも、判定基準は、全ての事象が実行されるまでルックアップ・テーブルを用いて更新され続ける。

図２は、本発明の一実施形態に従って閾値を計算するための流れ図を示す。ＤＲモジュール１２６がユーティリティ事業者１３６及び顧客サイト１０４と情報を交換する。この情報は、需要応答プロセスにおいて需要応答を決定するために使用される。プロセスは自動的に又は事業者によって開始することができる。段階２０２で、ｍ＝１で示されているように、需要応答事象又は行動の数を１に設定する。段階２０４で、ｎ＝１で示されているように、需要応答を呼び出すために残っている機会をまた１に設定する。段階２０６で、需要応答事象を呼び出すための機会の数が、残っている事象の数に等しいか又はそれより小さいかどうか決定する。その答えがイエスである場合、プロセスは段階２０８へ進み、そこで、Ｄ_ｍｎ＝０で示されているように判定基準を０に設定して、Ｖ_ｍｎとして示されているように予想節約量を計算する。次いで、プロセスは段階２１０へ進んで、需要応答を呼び出すために用いられる機会の数を１つ増数する。段階２０６における答えがノーである場合、プロセスは段階２１２へ進んで、そこで、利用可能な需要応答事象から判定基準Ｄ_ｍｎ及び予想される合計値Ｖ_ｍｎを計算する。予想値Ｖ_ｍｎは解析により計算することができ、或いはモンテカルロ・シミュレーション又は他の方法を用いて計算することもできる。段階２１４で、需要応答事象を呼び出すために用いられる機会の数ｎを１つ増数する。段階２１６で、事象を呼び出すための機会の数ｎが、需要応答事象を呼び出すために利用可能である機会の総数Ｔよりも大きいかどうか決定する。その答えがイエスである場合、プロセスは段階２１８へ進み、そこで、需要応答事象の数を１つ増数する。段階２２０で、事象の数が利用可能な事象の総数よりも大きいかどうか決定する。その答えがイエスである場合、プロセスは段階２２２で終了する。段階２１６又は２２０のいずれかにおける答えがノーである場合、プロセスは段階２０６へ戻る。プロセスの出力は、例えば、上記の表１に示されているようなルックアップ・テーブルを作成するために使用され、そのルックアップ・テーブルは、利用可能な事象の数及び事象を呼び出すために残っている機会の数に基づいて、需要応答事象の使用を最適化するために使用することができる。

図３は、トリガーとして生成コストの基準及び需要応答プログラムとして臨界的ピーク価格設定（ＣＰＰ）を求めるプロセスの一例を示す流れ図である。この実施形態によれば、プロセスは毎日繰り返される。段階３０２で、一日先の生成コストを計算する。段階３０４で、ＣＰＰ事象が呼び出された場合の生成コストの節約量を推定する。段階３０６で、残っている事象の数ｍと契約年に残っている日数ｎとを決定する。段階３０８で、図２に示されているプロセスを用いて、ＣＰＰ事象を呼び出すための節約量閾値を決定する。段階３１０で、推定された節約量が節約量閾値よりも大きいかどうか決定する。その答えがイエスである場合、プロセスは段階３１２へ進んで、ＣＰＰ事象を開始し、次いで段階３１４へ進んで、残っている事象の数を減らす。段階３１６で、需要応答事象を呼び出すために残っている日数を１だけ減数する。また、段階３１０での答えがノーである場合、プロセスは段階３１６へ進む。

要約して説明すると、本発明の実施形態は、事象の数及びそれらの事象を使用するための潜在的な機会の数が変化するにつれて動的に変化するトリガー基準を提供する。換言すると、判定基準は、需要応答又はＣＰＰ事象を呼び出すことのできるオプション値を反映する。オプション値は、残っている呼び出し可能な事象の数と、残っている呼び出し機会の数と、各々の残りの機会のための生成コスト又は任意の他の値パラメータの分布との関数である。値パラメータ（又はトリガー尺度）は、ユーティリティ事業者に適合するどんな物にでも変更することができる。この態様では、ユーティリティ事業者は需要応答事象の使用を最適化することができる。

本発明の実施形態を臨界的ピーク価格設定ＤＲプログラムに関連して説明してきたが、当業者には、本方法及びシステムが、例えば、電力配電回路網における偶発事象及びエネルギ節約のための全体的な負荷制御のような他の目的のために用い得ることが理解されよう。

本発明の特定の特徴のみを例示し説明したが、当業者には種々の修正および変更をなし得よう。従って、「特許請求の範囲」の記載が本発明の真の精神および趣旨の範囲内にあるこの様な全ての変更および変形を包含しようとするものであることを理解されたい。

１００ エネルギ管理システム
１０２ エネルギ管理サーバー
１０４ 顧客サイト
１０６ ＷＡＮ（広域ネットワーク）
１０８ プロセッサ

Claims (9)

1. 顧客サイトのユーティリティ・ネットワークにおいて需要応答事象を制御するための方法であって、
   複数の利用可能な需要応答事象を決定する段階と、
   前記利用可能な需要応答事象を発行するために利用可能である複数の機会を決定する段階と、
   前記複数の機会の各々のための需要応答パラメータの確率分布を決定する段階と、
   前記複数の利用可能な需要応答事象と、前記利用可能な需要応答事象を発行するために利用可能である複数の機会と、前記複数の機会の各々のための需要応答パラメータの確率分布とに基づいて、前記需要応答パラメータのための閾値を計算する段階と、
   前記需要応答パラメータの現在値を前記閾値と比較する段階と、
   比較結果に基づいて現在の機会のための需要応答事象を発行するかどうか決定する段階と、
   顧客サイトに制御信号を出力する段階と、
   を有する方法。
2. 更に、前記比較結果が正であるとき現在の機会のための需要応答事象を発行することを決定する段階と、
   利用可能な需要応答事象の数を減らす段階と、
   利用可能な需要応答事象を発行するために利用可能である機会の数を減らす段階と、
   を含んでいる請求項１記載の方法。
3. 更に、前記比較結果が負であるとき現在の機会のための需要応答事象を発行しないことを決定する段階と、
   利用可能な需要応答事象を発行するために利用可能である機会の数を減らす段階と、
   を含んでいる請求項１記載の方法。
4. 需要応答パラメータのための閾値を計算する前記段階は、利用可能な需要応答事象に関連したオプション値を推定する段階を含み、該オプション値は残りの数の機会にわたる需要応答事象の予想値に基づいている、請求項１記載の方法。
5. オプション値を推定する前記段階は、利用可能な需要応答事象の数と、利用可能な需要応答事象を発行するために利用可能である機会の数と、残りの数の機会の各々の間の需要応答パラメータの確率分布とを考慮して、オペレーションズ・リサーチ及び統計的方法の内の少なくとも１つを遂行する段階を含んでいる、請求項４記載の方法。
6. 前記需要応答パラメータはユーティリティ生成コストである、請求項１記載の方法。
7. 前記需要応答パラメータは、温度、総需要、予備余裕又は市場価格の内の１つである、請求項１記載の方法。
8. ユーティリティ・ネットワークにおいて需要応答事象を制御するためのシステムであって、
   ユーティリティ・ネットワークに接続されていて、各々が１つ以上のユーティリティ消費装置を有している複数の顧客サイトと、
   顧客サイト及びユーティリティ事業者に通信結合されたユーティリティ管理サーバーであって、イ）複数の利用可能な需要応答事象を決定し、ロ）前記利用可能な需要応答事象を発行するために利用可能である複数の機会を決定し、ハ）前記複数の機会の各々のための需要応答パラメータの確率分布を決定し、ニ）前記複数の利用可能な需要応答事象と、前記利用可能な需要応答事象を発行するために利用可能である複数の機会と、前記複数の機会の各々のための需要応答パラメータの確率分布とに基づいて、前記需要応答パラメータのための閾値を計算し、ホ）前記需要応答パラメータの現在値を前記閾値と比較し、ヘ）比較結果に基づいて現在の機会のための需要応答事象を発行するかどうか決定するように構成された需要応答モジュールを含んでいる、ユーティリティ管理サーバーと、
   顧客サイトに需要応答制御信号を出力するような構成されたモジュールと、
   を有しているシステム。
9. 更に、需要応答事象情報を記憶するために前記ユーティリティ管理サーバーに結合されたデータベースを含んでいる請求項８記載のシステム。