図面 (/)

技術 複数のエネルギー源のための電力需要管理

出願人 カスタマイズドエナジーソリューションズリミテッド
発明者 ヴァーツラフミードリル
出願日 2016年3月16日 (3年9ヶ月経過) 出願番号 2017-568011
公開日 2018年3月29日 (1年9ヶ月経過) 公開番号 2018-508921
状態 未査定
技術分野
  • -
主要キーワード コントロールベース 総エネルギー使用量 最大平均電力 サブインターバル ワイヤレスネットワークインターフェース ローカル電源 ロジックモジュール ビデオ出力デバイス
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年3月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (12)

課題・解決手段

電力需要を管理するためのコンピュータ実施方法は、コンピュータシステムが、1つまたは複数のローカルエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを含む施設についての電力需要情報を取得するステップを含む。コンピュータシステムは、電力需要情報に基づいて複数の利用可能な需要管理アクションから需要管理アクションを選択する。これらの利用可能な需要管理アクションは、少なくとも1つの電力負荷アクション、および少なくとも1つのエネルギー備蓄デバイスアクションを含む。選択されると、コンピュータシステムは、選択された需要管理アクションを実行する。

概要

背景

関連出願の相互参照
本出願は、2015年3月16日に出願された米国特許仮出願第62/133,852号明細書の優先権の利益を主張するものであり、その全体が、参照によって本明細書に組み込まれている。

ほとんどの電力会社は、総エネルギー使用量(kWh)に関してだけでなく、デビット(debit)期間(たとえば、5、10、15、もしくは60分のインターバル、またはその他の何らかの長さの時間)における平均電力需要(kW)に関しても、工業上および商業上の顧客に課金している。電力需要は、1つまたは複数の電力負荷に関係がある電力使用を含み得る。電力負荷の個別の数および電力負荷の性質は、分析される施設に応じてさまざまであり得る。

電力およびエネルギーを必要とする施設は、コストをコントロールするために電力需要を低減する自動化された電力コントロールシステムから恩恵を受けることができる。負荷コントロールベースの需要管理システムは、寄与している電気負荷の電力を一時的に低減することによって需要をコントロールすることができるが、独立型の負荷コントロールシステムは、ローカル電力源を利用する能力を有していない。エネルギー備蓄ベースの需要管理システムは、全体的に需要が低いデビット期間においてエネルギーを備蓄し、全体的に需要が高いデビット期間においてエネルギーを放出する。このことによって、需要をコントロールすることができる。しかしながら、独立型のエネルギー備蓄システムは、寄与している負荷の需要を低減する能力を有しておらず、これは、高い初期コストおよび継続的な運営コスト(たとえば、バッテリーインバータ効率の制限に関連するコスト)に起因して、それらのシステムの投資収益率ROI)を低減する。

負荷コントロールベースの需要コントロールシステムの利点と、エネルギー備蓄ベースの需要コントロールシステムの利点とを組み合わせて、統合的なシステムにすれば、有用であろう。しかしながら、そのようなシステム同士を組み合わせることの利点を適切に得るためには、生じうる潜在的な矛盾または非効率を回避するための統合されたアプローチが必要とされる。

概要

電力需要を管理するためのコンピュータ実施方法は、コンピュータシステムが、1つまたは複数のローカルエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを含む施設についての電力需要情報を取得するステップを含む。コンピュータシステムは、電力需要情報に基づいて複数の利用可能な需要管理アクションから需要管理アクションを選択する。これらの利用可能な需要管理アクションは、少なくとも1つの電力負荷アクション、および少なくとも1つのエネルギー備蓄デバイスアクションを含む。選択されると、コンピュータシステムは、選択された需要管理アクションを実行する。

目的

本発明の実施形態は、複数のエネルギー源を用いて電力需要を管理する電力需要管理を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

電力需要を管理するためのコンピュータ実施方法であって、コンピュータシステムによって、1つまたは複数のローカルエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを含む施設についての電力需要情報を取得するステップと、前記コンピュータシステムによって、前記電力需要情報に基づいて、複数の利用可能な需要管理アクションから需要管理アクションを選択するステップであって、前記利用可能な需要管理アクションは、少なくとも1つの電力負荷アクションおよび少なくとも1つのエネルギー備蓄デバイスアクションを含む、ステップと、前記コンピュータシステムによって、前記選択された需要管理アクションを実行するステップとを含む方法。

請求項2

前記電力需要情報は、需要限界設定点および予測電力需要値を含む請求項1に記載の方法。

請求項3

前記予測電力需要値と前記需要限界設定点との差として利用可能電力値を計算するステップをさらに含み、前記選択された需要管理アクションは、前記利用可能電力値に少なくとも部分的に基づく請求項2に記載の方法。

請求項4

前記利用可能電力値がマイナスである場合には、前記選択された需要管理アクションは、負荷低減を強めること、充電電力を低減すること、および発電を増やすことを含むグループから選択される請求項3に記載の方法。

請求項5

前記利用可能電力値がプラスである場合には、前記選択された需要管理アクションは、負荷低減を弱めること、エネルギー備蓄デバイスを充電すること、および電力生成を減らすことを含むグループから選択される請求項3に記載の方法。

請求項6

電力需要を管理するためのコンピュータ実施方法であって、コンピュータシステムによって、複数のインターバルを含む時間期間についての電力需要情報を取得するステップであって、前記電力需要情報は、前記時間期間についての需要限界設定点、および前記時間期間についての予測電力需要値を含む、ステップと、前記コンピュータシステムによって、前記予測電力需要値が前記需要限界設定点を超過していると判断するステップと、前記時間期間についての前記電力需要を低減するために、利用可能電力から引き出すステップであって、前記利用可能電力は、1つまたは複数のローカル電源、および電力負荷のうちの1つまたは複数に対する有効な低減を含む、ステップとを含む方法。

請求項7

前記利用可能電力から引き出すステップは、優先度情報に基づく請求項6に記載の方法。

請求項8

前記優先度情報は、前記電力負荷についての優先度情報を含む請求項7に記載の方法。

請求項9

前記電力負荷についての前記優先度情報は、複数の優先順位付けされたセグメントを含む請求項8に記載の方法。

請求項10

前記優先度情報は、前記ローカル電源についての優先度情報を含む請求項7に記載の方法。

請求項11

前記ローカル電源についての前記優先度情報は、複数の優先順位付けされたセグメントを含む請求項10に記載の方法。

請求項12

前記優先度情報は、前記電力負荷および前記ローカル電源についての優先度情報を含む請求項7に記載の方法。

請求項13

前記電力負荷および前記ローカル電源についての前記優先度情報は、複数の優先順位付けされたセグメントを含む請求項12に記載の方法。

請求項14

前記利用可能電力から引き出すステップは、前記インターバルのうちの少なくとも1つについて前記電力負荷のうちの少なくとも1つを低減するステップを含む請求項6に記載の方法。

請求項15

前記少なくとも1つの電力負荷は、制約が課された電力負荷である請求項14に記載の方法。

請求項16

前記利用可能電力から引き出すステップは、前記ローカル電源のうちの少なくとも1つから電力を生成するステップを含む請求項6に記載の方法。

請求項17

前記少なくとも1つのローカル電源は、エネルギー備蓄デバイスを含む請求項16に記載の方法。

請求項18

電力需要を管理するためのシステムであって、1つまたは複数のローカルエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを含む施設についての電力需要情報を取得する1つまたは複数のポートと、前記電力需要情報に基づいて、複数の利用可能な需要管理アクションから、需要管理アクションを選択する1つまたは複数のプロセッサであって、前記利用可能な需要管理アクションは、少なくとも1つの電力負荷アクションおよび少なくとも1つのエネルギー備蓄デバイスアクションを含み、前記選択された需要管理アクションを実行するように構成されている1つまたは複数のプロセッサとを含むシステム。

請求項19

前記電力需要情報は、需要限界設定点および予測電力需要値を含む請求項18に記載のシステム。

請求項20

前記1つまたは複数のプロセッサは、前記予測電力需要値と前記需要限界設定点との差として利用可能電力値を計算するようにさらに構成されており、前記選択された需要管理アクションは、前記利用可能電力値に少なくとも部分的に基づく請求項19に記載のシステム。

技術分野

0001

本発明は一般に、既存の電気負荷の低減、ローカル備蓄されているエネルギー(たとえば、バッテリーの形態で)、ならびに、ローカルに生成されることまたは公共送電網を通じて提供されることが可能な新たに生成されるエネルギー(風力発電太陽光発電、または水力発電などの再生可能エネルギーを含む)など、複数のエネルギー源を用いて電力需要を管理する電力需要管理のための方法、システム、および装置に関する。

背景技術

0002

関連出願の相互参照
本出願は、2015年3月16日に出願された米国特許仮出願第62/133,852号明細書の優先権の利益を主張するものであり、その全体が、参照によって本明細書に組み込まれている。

0003

ほとんどの電力会社は、総エネルギー使用量(kWh)に関してだけでなく、デビット(debit)期間(たとえば、5、10、15、もしくは60分のインターバル、またはその他の何らかの長さの時間)における平均電力需要(kW)に関しても、工業上および商業上の顧客に課金している。電力需要は、1つまたは複数の電力負荷に関係がある電力使用を含み得る。電力負荷の個別の数および電力負荷の性質は、分析される施設に応じてさまざまであり得る。

0004

電力およびエネルギーを必要とする施設は、コストをコントロールするために電力需要を低減する自動化された電力コントロールシステムから恩恵を受けることができる。負荷コントロールベースの需要管理システムは、寄与している電気負荷の電力を一時的に低減することによって需要をコントロールすることができるが、独立型の負荷コントロールシステムは、ローカルの電力源を利用する能力を有していない。エネルギー備蓄ベースの需要管理システムは、全体的に需要が低いデビット期間においてエネルギーを備蓄し、全体的に需要が高いデビット期間においてエネルギーを放出する。このことによって、需要をコントロールすることができる。しかしながら、独立型のエネルギー備蓄システムは、寄与している負荷の需要を低減する能力を有しておらず、これは、高い初期コストおよび継続的な運営コスト(たとえば、バッテリー/インバータ効率の制限に関連するコスト)に起因して、それらのシステムの投資収益率ROI)を低減する。

0005

負荷コントロールベースの需要コントロールシステムの利点と、エネルギー備蓄ベースの需要コントロールシステムの利点とを組み合わせて、統合的なシステムにすれば、有用であろう。しかしながら、そのようなシステム同士を組み合わせることの利点を適切に得るためには、生じうる潜在的な矛盾または非効率を回避するための統合されたアプローチが必要とされる。

先行技術

0006

米国特許出願第12/201,911号明細書

0007

本発明の実施形態は、複数のエネルギー源を用いて電力需要を管理する電力需要管理を提供することによって、上述の短所および欠点のうちの1つまたは複数に対処し克服する。簡潔に言えば、たとえば、負荷を低減することまたは備蓄されているエネルギーを使用することに向けられている優先順位付けされた需要管理アクションを使用することによって、電力需要および出力の変動性を補う統合需要管理システムについて本明細書に記述がある。この統合需要管理システムによって適用可能となる統合されたアプローチは、負荷コントロールの需要管理効果と、エネルギー備蓄コントロールの需要管理効果とをインテリジェントに組み合わせることによって全体的な需要管理の有効性を高める。この統合されたアプローチは、いかなる備蓄容量のエネルギー備蓄デバイスもシステム全体に寄与しうる。

0008

本発明のいくつかの実施形態によれば、電力需要を管理するためのコンピュータ実施方法において、コンピュータシステムが、1つまたは複数のローカルエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを含む施設についての電力需要情報を取得する。コンピュータシステムは、電力需要情報に基づいて、複数の利用可能な需要管理アクションから、需要管理アクションを選択する。これらの利用可能な需要管理アクションは、少なくとも1つの電力負荷アクション、および少なくとも1つのエネルギー備蓄デバイスアクションを含む。選択されると、コンピュータシステムは、選択した需要管理アクションを実行する。

0009

電力需要を管理するための上述の方法のいくつかの実施形態においては、電力需要情報は、需要限界設定点および予測電力需要値を含む。上述の方法は次いで、予測電力需要値と需要限界設定点との差として利用可能電力値を計算するステップをさらに含みうる。計算された利用可能電力値は、需要管理アクションを選択するために使用されうる。利用可能電力値がマイナスである場合には、選択される需要管理アクションは、負荷低減を強めること、充電電力を低減すること、および発電を増やすことを含むグループから選択されうる。利用可能電力値がプラスである場合には、選択された需要管理アクションは、負荷低減を弱めること、エネルギー備蓄デバイスを充電すること、および発電を減らすことを含むグループから選択されうる。

0010

その他の実施形態によれば、電力需要を管理するための第2のコンピュータ実施方法では、コンピュータシステムが、複数のインターバルを含む時間期間についての電力需要情報を取得する。電力需要情報は、その時間期間における需要限界設定点、およびその時間期間についての予測電力需要値を含む。コンピュータシステムは、予測電力需要値が需要限界設定点を超過していることを判断し、それに応じて、その時間期間における電力需要を低減するために、利用可能電力が引き出される(available power is drawn)。利用可能電力は、1つまたは複数のローカル電源、および電力負荷のうちの1つまたは複数に対する有効な低減を含みうる。利用可能電力から引き出すことは、たとえば、インターバルのうちの少なくとも1つについて、電力負荷の少なくとも1つを低減することを含みうる。代替として(または追加として)、引き出すことは、ローカル電源のうちの少なくとも1つ(たとえば、エネルギー備蓄デバイス)から電力を生成することを含みうる。

0011

電力需要を管理するための上述の第2の方法のいくつかの実施形態においては、利用可能電力から引き出すことは、優先度情報に基づく。この優先度情報は、たとえば、電力負荷に関する情報および/またはローカル電源についての情報を含みうる。いくつかの場合においては、優先度情報は、複数の優先順位付けされたセグメント編成されうる。

0012

その他の実施形態においては、電力需要を管理するためのシステムが、1つまたは複数のポートと、1つまたは複数のプロセッサとを含む。それらのポートは、1つまたは複数のローカルエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを含む施設についての電力需要情報を取得するように構成されている。プロセッサは、電力需要情報に基づいて、複数の利用可能な需要管理アクションから、需要管理アクションを選択するように構成されている。これらの利用可能な需要管理アクションは、少なくとも1つの電力負荷アクション、および少なくとも1つのエネルギー備蓄デバイスアクションを含む。プロセッサは、選択された需要管理アクションを実行するようにさらに構成されている。加えて、いくつかの実施形態においては、プロセッサは、予測電力需要値と需要限界設定点との差として利用可能電力値を計算するように構成されていてもよい。選択された需要管理アクションは次いで、利用可能電力値に少なくとも部分的に基づくものでもよい。

0013

本発明のさらなる特徴および利点は、添付の図面を参照しながら進む例示的な実施形態についての以降の詳細な説明から明らかにされるであろう。

図面の簡単な説明

0014

本発明についての前述の態様およびその他の態様は、以降の詳細な説明を添付の図面と関連させて読んだときに、最もよく理解される。本発明を例示する目的で、現時点で好ましい実施形態が図面において示されているが、理解されるように、本発明は、開示されている特定の手段には限定されない。図面に含まれているのは、下記の図である。
いくつかの実施形態に係る、統合需要管理システムによって施設による電力消費が管理されるシステムを例示したブロック図である。
いくつかの実施形態に係る、統合需要管理システムの詳細を例示したブロック図である。
いくつかの実施形態において利用可能である、デビット期間に分割されている課金期間(billing period)のタイミンスケールを示す図である。
いくつかの実施形態に係る、統合需要管理システムが、需要をコントロールするための統合されたアプローチを使用する方法を示す図である。
いくつかの実施形態に係る、統合需要管理システムが、需要をコントロールするための統合されたアプローチを使用するさらなる方法を示す図である。
需要をコントロールするために、より統合されたアプローチが使用される、いくつかの実施形態に係る、統合需要管理システムによって実行される方法の第1の部分を示す図である。
図5Aにおいて示されている方法の第2の部分を示す図である。
5つの電力負荷と、2つのエネルギー備蓄デバイスとを含む施設における電力利用可能度を示す表である。
いくつかの実施形態に係る、本明細書において記述されている需要管理アルゴリズムが負荷および備蓄電力セグメントに対してどのように要求することができるかを示すサブインターバル情報を伴う第2の表である。
本開示の実施形態に係る、使用に適した例示的なコンピューティングデバイスの態様を示すブロック図である。
本開示の実施形態に係る、使用に適した代替コンピューティング環境の態様を示すブロック図である。

実施例

0015

以降の開示は、複数のエネルギー源を用いて電力需要を管理するための方法、システム、および装置に向けられているいくつかの実施形態に沿って本発明についての記述をしている。エネルギー源は、既存の電気負荷の低減、ローカルに備蓄されているエネルギー(たとえば、バッテリーの形態で)、ならびに、ローカルで生成されうるか、公共送電網を通じて提供されることが可能な新たに生成されるエネルギー(たとえば、風力発電、太陽光発電、または水力発電などの再生可能エネルギー)のうちの1つまたは複数を含みうる。いくつかの再生可能エネルギー源(風力発電および太陽光発電など)は、電力出力変動性によって特徴付けられるが、統合需要管理システムが、たとえば、負荷を低減することや、備蓄されているエネルギーを使用することに向けられている優先順位付けされた需要管理アクションを使用することによって、そのような変動性を補うことができる。より広範には、(たとえば、より安価でより効率的な電源を好んで使用し、より高価な電力源の使用頻度を少なくすることによって)需要を管理するような特定の状況において、任意の数の電源を使用可能かどうか、およびどの程度まで使用可能かを判断するための優先順位付けを適用することが可能である。

0016

本明細書において記述されている実施形態は、負荷コントロールの需要管理効果と、エネルギー備蓄コントロールの需要管理効果とをインテリジェントに組み合わせる統合されたアプローチを用いて全体的な需要管理の有効性を高める。この統合されたアプローチは、いかなる備蓄容量のエネルギー備蓄デバイスに対してもシステム全体に寄与しうる。エネルギー備蓄デバイスは典型的に、1つまたは複数のバッテリーと、インバータとを含む。インバータは、バッテリー充電のために交流(AC)電力を直流(DC)電力へ、およびバッテリー放電のためにDC電力をAC電力へ変換する。ただし、エネルギー備蓄デバイスは、バッテリー以外のエネルギー備蓄媒体を使用してもよい。たとえば、フライホイールモータ/発電機に接続されているスピニングホイール)、および水力蓄電設備(たとえば、水がポンプリザーバへくみ上げられ、その後に放出されて発電機からの電力供給を得る)など、機械式のエネルギー備蓄デバイスが使用されてもよい。この統合されたアプローチはまた、需要応答イベントの中での需要管理ポテンシャルを高めて、需要低減を通じたコスト節約の機会に対して迅速で自動化された応答を可能にする。

0017

図1Aは、いくつかの実施形態に係る統合需要管理システム122によって施設120(たとえば、工場倉庫オフィスビル住居、学校もしくは政府建物データセンターもしくはコンピューティングセンター、または、電力を消費するその他の任意の施設)による電力消費を管理する例示的なシステム100Aを示すブロック図である。簡潔に言えば、統合需要管理システム122は、統合需要管理アルゴリズムを複数の利用可能なエネルギー源(たとえば、負荷128の低減、ローカルに備蓄するエネルギー源126、および公益企業の送電網130からの利用可能なエネルギー)に適用することによって、全体的な需要管理の効率を高める。このシステムはまた、個々のエネルギー源向けの需要管理アクションに対する優先順付けや、その抑制の能力によって、全体的な需要管理の効率を高める。

0018

図1Aに示されている例においては、施設120は、送電網130から電力を引き出しうる。送電網130は、電力会社(図示せず)によって少なくとも部分的に維持管理されうる。統合需要管理システム122は、適切にプログラムされたコンピュータまたはマイクロコントローラ図7および図8を参照)など、1つまたは複数のコンピューティングデバイスにおいて実施されうる。統合需要管理システム122は、本明細書において記述されている1つまたは複数の電力需要管理技術から施設120が恩恵を受けることを可能にする方法で特徴付けられる処理を電力需要情報に適用する。電力メータ124は、継続中のエネルギー消費示度(readings of ongoing energy consumption)を、統合需要管理システム122に提供できる。

0019

電力需要情報は、たとえば、需要限界設定点および予測電力需要値を含みうる。需要限界設定点は、目標需要ベルを表し、典型的には、さらなる需要の突出を回避するために、その目標需要レベルは超過されるべきではないが、それは、需要レベルを目標需要レベルよりも低く保つことを、現実的な考慮事項が阻むか、またはその利点を上回る場合には、超過されうる。(需要をコントロールするための技術についてのさらなる情報に関しては、2008年8月29日に出願された「Automated Peak Demand Controller」という名称の特許文献1を参照されたい。その全体が、参照によって本明細書に組み込まれている。)現在の需要が維持されると予測電力需要値が需要限界設定点を超過することになる場合には、以降でさらに記述されるように、寄与している負荷の電力を低減すること、エネルギー備蓄(energy storage)からの電力生成を要求することなどのアクションが取られうる。

0020

統合需要管理システム122に電力需要情報を提供するための異なる方法がある。電力需要情報は、施設120内に(たとえば、統合需要管理システム122内に、もしくはその他の何らかのロケーションに)格納されること、および/またはネットワーク170(たとえば、インターネット)を介して別個のコンピュータシステム(図示せず)によって提供されるようにすることが可能である。たとえば、電力需要情報は、電力会社または需要管理サービスプロバイダによってホストされている1つまたは複数のサーバコンピュータによって提供されるようにしてもよい。そのようなサービスプロバイダは、需要管理に関連したソフトウェア更新ウェブベースソフトウェアアプリケーションリモート処理、またはデータ格納機能(たとえば、クラウドコンピューティング環境における機能)などを(たとえば、ネットワーク170を介して)提供することもできる。

0021

統合需要管理システム122は、負荷128およびローカル電源126の洗練されたコントロールを通じて需要を管理するための統合されたソリューションを提供する。統合需要管理システム122は、施設120に関連付けられている1つまたは複数の電気負荷128および1つまたは複数のローカル電源126(たとえば、エネルギー備蓄デバイス、発電機など)に通信可能に接続されており、このシステムが、需要管理において必要とされるときに負荷および電源のコントロールを可能にする。施設120が送電網から引き出す電力の量は、その需要に基づいて変動し、その需要は、負荷128によって消費される電力およびローカルエネルギー源126によって生成される電力などの要因に基づいて変動する。統合需要管理システム122は、電力需要情報を使用して、(以降で詳細に記述されるように)利用可能な需要管理アクションの中から選択を行い、その需要管理アクションは次いで、需要を管理するために負荷128および/またはローカル電源126に適用されうる。

0022

図1Bは、より詳細なシステム100Bを示すブロック図である。図1Bにおいて示されている例において、統合需要管理システム122は、施設120に関連付けられている負荷128A〜D(たとえば、HVACシステムポンプモータ、炉、プロセスコントロールなど)およびローカル電源126A〜C(たとえば、2つのエネルギー備蓄デバイス、および太陽光発電機)に通信可能に接続されている。図1Bにおいて示されている例において、統合需要管理システム122は、マイクログリッドバス130を介して負荷128A〜Dおよびローカル電源126A−Cに対して通信およびコントロールをする。

0023

例示の目的で図1Aおよび図1Bにおいて特定のアレンジが示されているが、図1Aおよび図1Bにおいて示されているシステムに対する多くの代替形態が可能である。たとえば、これらのシステムは、ローカルに格納されている情報を使用することによって、ネットワーク接続を伴わずに「オフラインで」機能するように設計されてもよい。例示しやすくするために、システム100Aおよび100Bは、1つの施設のみを伴って示されているが、別の例として、そのようなシステムは、複数の施設を伴っていてもよい。別々の施設が、単一の統合需要管理システム122によって、または複数のそのようなシステム(たとえば、施設ごとに1つのシステム)によって管理されてもよい。適切に構成されている統合需要管理システム122が、複数の施設における需要を管理するようにしてもよい。

0024

図1Aおよび図1Bにおいて示されているシステムは、特定のタイミングパラメータ内で機能することができ、それらのタイミングパラメータは、インターバルおよびサブインターバルの観点から記述されうる。ある使用シナリオにおいては、課金期間(たとえば、1カ月)が電力会社によって定義され、デビット期間と呼ばれるインターバルに分割される。デビット期間(たとえば、15、30、または60分)も、典型的には、電力会社によって定義され、統合需要管理システムによって定義されたサブインターバルへと分割されうる。図2は、デビット期間220に分割されている課金期間210の例示的なタイミングスケール200を示しており、それぞれのデビット期間は、サブインターバル230へとさらに分割されている。示されているように、課金期間210は、ある適切な数のデビット期間220へと分割されうるし、デビット期間220は、ある適切な数のサブインターバル230へと分割されうる。システム100Aおよび100Bによって使用されるインターバル(たとえば、デビット期間)およびサブインターバルの長さおよび厳密な数は、公益企業の要件システム設計、またはその他の要因に応じて変わりうることは容易に理解されよう。

0025

図3および図4を参照しながら記述されている例示的な方法300および400においては、統合需要管理システムが、需要をコントロールするための統合されたアプローチを使用する。図3において示されている例では、ステップ310において、統合需要管理システムは、1つまたは複数のローカルのエネルギー備蓄デバイスと、1つまたは複数の電力負荷とを有する施設についての電力需要情報(たとえば、需要限界設定点および予測電力需要値)を取得する。ステップ320において、このシステムは、少なくとも1つの電力負荷アクション(たとえば、電力負荷を低減すること、または電力負荷の前回低減量を減らすこと)および少なくとも1つのエネルギー備蓄デバイスアクション(たとえば、充電すること、または放電すること)を含む複数の利用可能な需要管理アクションから、需要管理アクションを選択する。ステップ330において、このシステムは、選択されたアクションを実行する。

0026

少なくとも1つの実施形態においては、予測電力需要値と需要限界設定点と差として利用可能電力値が計算され、選択されるアクションは、その利用可能電力値に基づくものになる。たとえば、利用可能電力値がマイナスである場合には、選択されるアクションは、負荷を低減すること、充電電力を低減すること、または発電(power generation)を増やすことであり得る。利用可能電力値がプラスである場合には、選択されるアクションは、既存の負荷の低減を弱めること、エネルギー備蓄デバイスを充電すること、または発電を減らすことであり得る。

0027

図4において示されている例においては、ステップ410において、統合需要管理システムは、インターバルを含む時間期間(たとえば、デビット期間)についての需要限界設定点および予測電力需要値を含む電力需要情報を取得する。ステップ420において、このシステムは、予測電力需要値が需要限界設定点を超過していることを特定し、ステップ430において、このシステムは、その時間期間に関する需要を低減するために、利用可能電力から引き出す。この利用可能電力は、1つまたは複数のローカル電源(たとえば、エネルギー備蓄デバイス、太陽光発電機など)、および1つまたは複数の電力負荷の有効な低減を含む。利用可能電力から引き出すことは、電力負荷を低減すること、またはローカル電源から電力を生成することを含みうる。このシステムは、優先度情報に基づいて、利用可能電力から引き出すことができ、その優先度情報は、負荷またはローカル電源についての優先順位付けされたセグメントを含みうる。負荷および電源の優先順位付けは、以降でさらに詳細に論じられる。

0028

詳細な例
以降の例は、図5A図6Bを参照しながら、本明細書において記述されている原理のさらなる詳細を提供する。本明細書において提供されている詳細は、非限定的であり、本明細書において記述されている原理によるその他の実施態様の詳細に応じてさまざまであり得るということを理解されたい。

0029

図5Aおよび図5Bを参照しながら記述されている例示的な方法においては、統合需要管理システムが、需要をコントロールするためのさらなる統合されたアプローチを使用する。この例においては、このシステムは、統合需要管理アルゴリズムを複数のエネルギー源(たとえば、施設の利用可能エネルギー源のうちのいくつかまたはすべて)に適用することによって全体的な需要管理の効率を高める。このシステムは、需要を管理するための所与の時点において個々のエネルギー源が寄与しうる利用可能電力を追跡し続ける。

0030

エネルギー備蓄デバイスの利用可能電力は、備蓄(storage)が所与の時点において供給できる定格電力(もしあれば充電電力をプラスした電力)である。稼働中の電力負荷に対する利用可能電力は、一時的に低減可能な部分である。負荷についての(たとえば、ユーザによって)制約を指定可能であり、利用可能電力の計算には、そのような制約を考慮に入れることができる。たとえば、最低温度まで暖房される必要がある施設においては、特定の指定されたレベルよりも下に暖房負荷を低減することを回避するために暖房負荷に制約が課されうる。需要を管理するために暖房負荷を低減することは可能であり得るが、そのような低減により得られる利用可能電力は、制約によって制限される場合がある。最高温度未満にとどまらなければならない施設における冷房システム負荷に関しても、同様の制約が指定されうる。そのような制約は、負荷についての優先度情報に加えられて適用可能であり、それらの優先度情報は、負荷を、その他の負荷よりも高いまたは低い重要度を有するものとして指定することができる。

0031

このアルゴリズムは、需要限界設定点とともに機能する。この例においては、需要限界設定点は、デビット期間中に許可される最大平均電力を定義する。デビット期間内の任意の所与の時点における実際の平均電力は、ユーティリティーメータエネルギー使用データの示度を取得することによって特定されうる。少なくとも1つの実施形態においては、需要管理アルゴリズムは、設定可能な時間期間において平均された実際の電力需要の勾配を計算し、現在の需要が維持されたときに需要限界が超過するかどうかを計算する。需要限界が超過するとアルゴリズムが判断した場合には、統合需要管理システムは、需要管理アクション、たとえば、寄与している負荷の電力を低減すること、エネルギー備蓄(energy storage)からの電力生成(power generation)を要求すること、またはその他のアクションもしくはアクションの組合せ(負荷を低減することおよび電力を生成することを同時に行うことなど)を実行するためのコマンドを発行できる。この方法においては、このアルゴリズムは、負荷および発電を1つのエネルギープールとして扱うこと(電力生成は逆負荷として扱われる)によって、それらの両方をコントロールすることができる。

0032

このシステムは、個々のエネルギー源向けの需要管理アクションに優先付けしたり、その抑制をしたりする能力によって、全体的な需要管理の効率を高めることもできる。優先度は、(たとえば、オペレータによって)複数の方法で事前に定義されること、または(たとえば、エネルギーの現在のおよび今後のコスト、生産要因、ならびにエネルギー備蓄の効率などの要因を考慮したルールに従って)動的に割り振られうる。エネルギー源に対する優先順位付けは、需要管理アクションにおいて、負荷およびエネルギー備蓄を織り交ぜることを可能にする。たとえば、エネルギー備蓄デバイスからの電力を要求すること、またはより重要な負荷を低減することの前に、施設のオペレーションにとって重要ではない負荷を低減する需要管理アクションを開始することが望ましい場合がある。その他のときには、いくらかの負荷を低減すること、または効率の低いエネルギー源から電力を追加することの前に、効率の高いエネルギー備蓄デバイスから電力を生成することを開始することが有益な場合がある。このシステムはまた、需要を管理するために任意の利用可能な電源が使用されてもよい。

0033

図5Aおよび図5Bにおける流れ図500−Aおよび500−Bを参照しながら示されている例においては、ステップ502において、このシステムは、等しい時間長を有する複数のサブインターバルに分割されているインターバル(たとえば、デビット期間)について処理を開始する。ステップ504において、このシステムは、このインターバル内のサブインターバルに対して需要管理アルゴリズムを適用する。最初に、このシステムは、ステップ506において、次のサブインターバルにおいて利用可能な電力を計算する。たとえば、このシステムは、現在の電力需要、デビット期間の残りの時間内にどれぐらい多くの需要が利用可能であるか、およびデビット期間内にどれぐらい多くの時間が残っているかに基づいて、利用可能電力を計算することができる。利用可能電力は、プラスまたはマイナスの値をとり得る。

0034

利用可能電力がプラスではない場合には(ステップ508)、このシステムは、ステップ510において、(何らかのエネルギー備蓄デバイスが現在充電されている場合には)エネルギー備蓄(energy storage)における充電電力の低減を要求する。たとえば、このシステムは、電力の充電の低減を要求することができる。要求される充電電力の低減量は、たとえば、(マイナスの値の)利用可能電力の絶対値までであってもよい。少なくとも1つの実施形態においては、充電電力は、最大充電電力の0から100%の範囲で調整されうる。これは、充電プロセスが施設の環境において望ましくない電力需要を生み出さないことを保証する上で役立ちうる。

0035

利用可能電力と、充電電力の低減によって節約される電力との合計がプラスである場合には(ステップ512)、このシステムは、ステップ550において、インターバルが完了しているかどうかを判断し、そのインターバル内の新たなサブインターバルを開始する(ステップ552)か、または新たなインターバルを開始する(ステップ554)。利用可能電力と、充電電力の低減によって節約される電力との合計がプラスではない場合には、このシステムは、図5Bにおけるステップ530において、需要低減要求を開始する。需要低減の要求量は、たとえば、利用可能電力と、充電電力の低減によって節約される電力との(マイナスの値の)合計の絶対値までであってもよい。

0036

ステップ532において、このシステムは、調整可能な電力セグメント(たとえば、低減可能な負荷からのセグメント、または発電を増やすことができる電源からのセグメント)の優先順位付けされたリストを得る。ステップ534において、このシステムは、需要低減要求を満たすセグメントを選択する。ステップ536において、このシステムは、負荷低減を強めるためのコマンド、および/または発電を増やすためのコマンドを送信し、それは、施設による商用電力の需要を低減する効果を有する。少なくとも1つの実施形態においては、そのようなコマンドは、要求されている需要低減の量とともに送信される。このシステムは次いで、ステップ550において、インターバルが完了しているかどうかを判断し、そのインターバル内の新たなサブインターバルを開始する(ステップ552)か、または新たなインターバルを開始する(ステップ554)。

0037

引き続き図5Aを参照すると、ステップ508において、利用可能電力がプラスであると判断された場合には、このシステムは、ステップ520において、施設内で負荷が現在低減されているかどうか、または電力が現在生成されているかどうかを判断する。ステップ520において、低減されている電力の量または生成されている電力の量がプラスではないとシステムが判断した場合には、このシステムは、ステップ522において、利用可能なエネルギー備蓄デバイスがフルに充電されているかどうかを判断する。そうでない場合には、このシステムは、ステップ550へ進む前にステップ524において充電プロセスを開始できる。この方法によれば、このシステムは、今後の使用のためにエネルギー備蓄デバイスに充電するための利用可能電力がプラスであるという状況を利用することができる。充電プロセスが開始される場合には、充電電力は、たとえば利用可能電力に等しくなることができ、また、その利用可能電力は、利用可能電力の備蓄値によってオフセットされてもよい。その備蓄値は、ユーザによって設定されてもよく、あるいは、施設内の使用履歴または電力状況などの要因に基づいて自動的に設定されてもよい。

0038

再びステップ520を参照すると、低減されている電力の量またはローカルにおいて生成されている電力の量がプラスである場合には、このシステムは、図5Bにおけるステップ540において、需要増大要求を開始する。要求される需要増大の量は、たとえば、低減/生成される電力の絶対値までであってもよい。ステップ542において、このシステムは、調整可能な電力セグメント、たとえば、現在低減されている負荷からのセグメント、または現在電力を生成している電源からのセグメントについての優先順位付けされたリストを得る。ステップ544において、このシステムは、需要増大要求を満たすセグメントを選択する。ステップ546において、このシステムは、負荷低減を弱めるためのコマンド、および/または発電を減らす(たとえば、エネルギー備蓄デバイスからの放電を減らす)ためのコマンドを送信し、それは、施設における商用電力の需要を増大する効果を有する。充電電力と同様に、エネルギー備蓄の放電も、需要管理アルゴリズムによってコントロールでき、最大放電電力の0〜100%の範囲で調整されうる。少なくとも1つの実施形態においては、そのようなコマンドは、要求されている需要増大の量とともに送信される。このシステムは次いで、ステップ550において、インターバルが完了しているかどうかを判断し、そのインターバル内の新たなサブインターバルを開始する(ステップ552)か、または新たなインターバルを開始する(ステップ554)。

0039

少なくとも1つの実施形態においては、優先順位付けは、階層状の優先順位付けスキーマ(schema)の使用を含む。利用可能電力は、このシステムによっていくつかの電力セグメントに分けることが可能であり、それらの電力セグメントのそれぞれは、このシステムによって(たとえば、層全体、層の部分を構成するセグメント、セグメントの部分などについて)要求されうる。このシステムはまた、個々のセグメントに対する優先順位付けを可能にする。セグメントは、優先順位番号を割り振られてもよく、セグメントは、その優先順位番号に基づいて需要管理アルゴリズムによってアクセス可能にされてもよい。

0040

次いで、図6Aにおいて示されている表600を参照すると、例示的な施設が、5つの電力負荷、および2つのエネルギー備蓄デバイス(たとえば、AC/DCおよびDC/ACインバータを伴うバッテリーベースのエネルギー備蓄デバイス)を含んでいる。それぞれの負荷および備蓄デバイスに関して、10kWの利用可能電力セグメントが5つ、合計で50kW分ある。負荷1、2、および3は重要度が低く、優先度層1〜5におけるセグメントを伴っている。負荷4および5は重要度が高く、優先度層3〜7におけるセグメントを伴っている。一方のエネルギー備蓄デバイス(備蓄1)は効率が高く、優先度層4〜8におけるセグメントを伴っている。他方のエネルギー備蓄デバイス(備蓄2)は効率が低く、優先度層6〜10におけるセグメントを伴っている。セグメント優先度は、事前に定義されうるが、変更可能であってもよい。たとえば、セグメント優先度は、以前に重要が低いと判断されていた負荷が、その後に重要が高いとみなされる場合、またはエネルギー備蓄デバイスの放電の重要度を高めることによってその放電が延期される場合などの外部要因に基づいて動的に変更されうる。たとえば、雲量が太陽光発電に影響を与えると予想される場合には、エネルギー備蓄デバイスは、その時間中にいくらかの電力を補うことが必要になると予測でき、エネルギー備蓄デバイスの放電は、それが必要とされるまで延期されうる。

0041

この例においては、需要管理アルゴリズムは、図6Bにおける表610において示されているように、下記の順序で最初の4つのサブインターバルに関して負荷および備蓄電力セグメント(セグメント全体またはセグメントの部分)を要求することができる。
サブインターバル1: 負荷1〜3のセグメント1
サブインターバル2: 負荷1〜3のセグメント2
サブインターバル3: 負荷1〜3のセグメント3、負荷4〜5のセグメント1
サブインターバル4: 負荷1〜3のセグメント4およびセグメント5の部分、負荷4〜5のセグメント2およびセグメント3の部分、備蓄1のセグメント1およびセグメント2の部分

0042

表610において示されている例においては、サブインターバル4までに、5つすべての負荷と、2つの備蓄デバイスのうちの一方とに要求されるセグメントについていえば、要求される需要低減量の合計は200kWである。提供されている優先度情報に応じて追加されるサブインターバルにおいて、さらにセグメントが要求されてもよい。表610においては、(サブインターバル6を除いて)サブインターバル9までに追加的なセグメントが要求されており、サブインターバル9の時点で、要求される需要低減量の合計は、70kW低減されており、優先度層7〜9のセグメントの放出を可能にしている。サブインターバル12までに、要求される低減量は0であり、それまでに要求されたセグメントはすべて放出されている。

0043

生産上の制約または不十分なバッテリー充電など、何らかの理由で、特定の負荷またはエネルギー備蓄システムが、電力を提供するのに利用できない場合には、そのユニットは、優先順位付けスキーマによって省かれうる。要求される電力は、(たとえば、利用可能電力値がプラスであり、マイナスではない場合には)逆の順序で放出されてもよい。

0044

オペレーティング環境
具体的な例のコンテキストにおいてその他の形で指定されない限り、記述されている技術およびツールは、産業用コンピュータ、ラップトップコンピュータデスクトップコンピュータスマートフォンタブレットコンピュータなどを含むがそれらには限定されない任意の適切なコンピューティングデバイスによって実施されることが可能である。記述されている技術およびツールは、仮想コンピューティング環境において実施されることも可能である。

0045

本明細書において記述されている機能のいくつかは、クライアントサーバ関係のコンテキストにおいて実施されることが可能である。このコンテキストにおいては、サーバデバイスは、本明細書において記述されている情報および/またはサービスを提供するように構成されている適切なコンピューティングデバイスを含むことができる。サーバデバイスは、専用のサーバデバイスなど、任意の適切なコンピューティングデバイスを含むことができる。サーバデバイスによって提供されるサーバ機能は、いくつかのケースにおいては、専用のサーバデバイスではないコンピューティングデバイス上で実行しているソフトウェア(たとえば、仮想化されたコンピューティングインスタンスまたはアプリケーションオブジェクト)によって提供されることが可能である。「クライアント」という用語は、通信リンクを介してサーバによって提供される情報を取得するおよび/またはサービスにアクセスするコンピューティングデバイスを指すために使用されることが可能である。しかしながら、特定のデバイスをクライアントデバイスとして指定することは、サーバの存在を必ずしも必要とするとは限らない。さまざまな時点において、単一のデバイスが、コンテキストおよび構成に応じて、サーバ、クライアント、またはサーバおよびクライアントの両方として機能することができる。クライアントおよびサーバの実際の物理的なロケーションは、必ずしも重要とは限らず、それらのロケーションは、リモートのロケーションにあるサーバによって提供される情報をクライアントが受信しているという一般的な使用シナリオを示すために、クライアントにとっては「ローカル」として、およびサーバにとっては「リモート」として記述されることがある。

0046

図7は、本開示の実施形態による使用に適した例示的なコンピューティングデバイス700の態様を示すブロック図である。以降の説明は、サーバ、パーソナルコンピュータモバイル電話、スマートフォン、タブレットコンピュータ、組み込みコンピューティングデバイス、および、本開示の実施形態に従って使用されることが可能であるその他の現在利用可能な、または今後開発されることになるデバイスに適用可能である。

0047

コンピューティングデバイス700は、その最も基本的な構成において、通信バス706によって接続されている少なくとも1つのプロセッサ702およびシステムメモリ704を含む。デバイスの厳密な構成およびタイプに応じて、システムメモリ704は、揮発性または不揮発性メモリ、たとえば、読み取り専用メモリ(「ROM」)、ランダムアクセスメモリ(「RAM」)、EEPROMフラッシュメモリ、またはその他のメモリテクノロジーであることが可能である。システムメモリ704は典型的に、プロセッサ702にとってすぐにアクセス可能な、および/またはプロセッサ702によって現在操作されているデータモジュールおよび/またはプログラムモジュールを格納するということを当技術分野における標準的な技術者およびその他の技術者なら認識するであろう。この点については、プロセッサ702は、命令の実行をサポートすることによって、コンピューティングデバイス700の計算センターとしての役割を果たすことができる。

0048

図7においてさらに示されているように、コンピューティングデバイス700は、ネットワークを介してその他のデバイスと通信するための1つまたは複数のコンポーネントを含むネットワークインターフェース710を含むことができる。本開示の実施形態は、一般的なネットワークプロトコルを使用して通信を実行するためにネットワークインターフェース710を利用する基本的なサービスにアクセスすることができる。ネットワークインターフェース710は、1つまたは複数のワイヤレス通信プロトコル、たとえば、Wi−Fi、2G、3G、4G、LTE、WiMAX、Bluetooth(登録商標)などを介して通信するように構成されているワイヤレスネットワークインターフェースを含むこともできる。

0049

図7において示されている例示的な実施形態においては、コンピューティングデバイス700はまた、記録媒体708を含む。しかしながら、データをローカル記録媒体存続させる機能を含まないコンピューティングデバイスを使用してサービスがアクセスされることも可能である。したがって、図7において示されている記録媒体708は、任意選択のものである。いずれにしても、記録媒体708は、情報を格納することができる任意のテクノロジーを使用して実施される揮発性または不揮発性で、取り外し可能なまたは取り外し不能なものであることが可能であり、たとえば、ハードドライブソリッドステートドライブ、CD ROM、DVD、またはその他のディスクストレージ磁気テープ磁気ディスクストレージなどであるが、それらには限定されない。

0050

本明細書において使用される際には、「コンピュータ可読媒体」という用語は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納することができる任意の方法またはテクノロジーで実施される揮発性のおよび不揮発性のおよび取り外し可能なおよび取り外し不能な媒体を含む。この点については、図7において示されているシステムメモリ704および記録媒体708は、コンピュータ可読媒体の例である。

0051

例示しやすくするため、および特許請求されている主題の理解にとって重要ではないため、図7は、多くのコンピューティングデバイスの典型的なコンポーネントのうちのいくつかを示していない。この点については、コンピューティングデバイス700は、入力デバイス、たとえば、キーボードキーパッドマウストラックボールマイクロフォンビデオカメラタッチパッドタッチスクリーン電子ペンスタイラスなどを含むことができる。そのような入力デバイスは、RF、赤外線シリアルパラレル、Bluetooth、USB、または、ワイヤレス接続もしくは物理接続を使用するその他の適切な接続プロトコルを含む有線接続またはワイヤレス接続によってコンピューティングデバイス700に結合されることが可能である。

0052

記述されている例のうちのいずれにおいても、入力データは、入力デバイスによって取り込まれること、および処理されること、伝送されること、または(たとえば、今後の処理のために)格納されることが可能である。入力デバイスは、コンピューティングデバイス700(たとえば、クライアントデバイス)とは別個であること、およびコンピューティングデバイス700に通信可能に結合されることが可能であり、またはコンピューティングデバイス700の一体型コンポーネントであることが可能である。いくつかの実施形態においては、複数の入力デバイスが組み合わされて単一の多機能入力デバイス(たとえば、統合されたマイクロフォンを備えたビデオカメラ)になることが可能である。現在知られているまたは今後開発される任意の適切な入力デバイスが、本明細書において記述されているシステムとともに使用されることが可能である。

0053

コンピューティングデバイス700は、出力デバイス、たとえば、ディスプレイスピーカープリンタなどを含むこともできる。出力デバイスは、ディスプレイまたはタッチスクリーンなどのビデオ出力デバイスを含むことができる。出力デバイスはまた、外部スピーカーまたはイヤフォンなどのオーディオ出力デバイスを含むことができる。出力デバイスは、コンピューティングデバイス700とは別個であること、およびコンピューティングデバイス700に通信可能に結合されることが可能であり、またはコンピューティングデバイス700の一体型コンポーネントであることが可能である。いくつかの実施形態においては、複数の出力デバイスが組み合わされて単一のデバイス(たとえば、内蔵スピーカーを備えたディスプレイ)になることが可能である。さらに、いくつかのデバイス(たとえば、タッチスクリーン)は、同じ入力/出力デバイス内に統合された入力および出力の両方の機能を含むことができる。現在知られているまたは今後開発される任意の適切な出力デバイスが、記述されているシステムとともに使用されることが可能である。

0054

一般には、本明細書において記述されているコンピューティングデバイスの機能は、プログラミング言語、たとえば、C、C++、COBOL、JAVA(登録商標)、PHP、Perl、HTML、CSS、JavaScript(登録商標)、VBScript、ASPX、Microsoft .NET(商標)言語、たとえばC#などで書かれることが可能である、ハードウェアに組み込まれているコンピューティングロジックまたはソフトウェア命令で実施されることが可能である。コンピューティングロジックは、実行可能プログラムへとコンパイルされること、またはインタープリタ型プログラミング言語で書かれることが可能である。一般には、本明細書において記述されている機能は、2倍にされてさらに大きな処理能力を提供すること、その他のモジュールとまとめられること、またはサブモジュールへと分割されることが可能であるロジックモジュールとして実施されることが可能である。コンピューティングロジックは、任意のタイプのコンピュータ可読媒体(たとえば、メモリもしくは記録媒体などの非一時的な媒体)またはコンピュータストレージデバイス内に格納され、および1つまたは複数の汎用または専用のプロセッサ上に格納されてそのプロセッサによって実行され、ひいては、本明細書において記述されている機能を提供するように構成されている専用のコンピューティングデバイスを生み出すことが可能である。

0055

図8は、本開示の実施形態による使用に適した代替コンピューティング環境800の態様を示すブロック図である。この例においては、本明細書において記述されているさまざまな統合電力需要管理技術が、プログラマブルロジックコントローラPLC)805上で実施される。当技術分野においてよく理解されているように、PLCは、出力デバイスの状態をコントロールするために入力デバイスの状態に関するデータを継続的に収集するソフトウェアを実行するように構成されている専門化したコンピュータコントロールシステムである。PLCは典型的に、プロセッサ810(複数のプロセッサコアおよび揮発性メモリを含むことができる)と、本明細書において記述されている統合需要管理システムを実行するアプリケーションプログラムを含む記録媒体820とを含む。

0056

PLC805は、オートメーションシステム内のその他のデバイスに接続するための1つまたは複数の入力/出力(I/O)ポート815をさらに含む。これらのポート815を通じて、PLC805は、統合需要管理システムによる処理のために、電力メータ、エネルギー備蓄デバイス、および電力負荷(たとえば、HVACシステム、ポンプモータ、炉、プロセスコントロール等)などの外部源から電力データを収集する。これらの外部源からデータを収集するために使用される厳密な技術は、PLC805のネットワーキング能力に応じてさまざまであろう。たとえば、いくつかの実施形態においては、PLC805は、外部源に直接に有線接続されており、その一方でその他の実施形態においては、PLC805および外部源を接続するために、ワイヤレスネットワーキング機能(たとえば、Wi−Fi、2G、3G、4G、LTE、WiMAX、Bluetoothなど)が使用されることが可能である。

0057

PLC805は、図8においてサーバ835によって表されているクラウドベースのコンピューティング環境へネットワーク825(インターネット)を介して電力需要データを伝送するように構成されている。いくつかの場合においては、PLC805は、サーバ835と直接に通信するように構成されることが可能であるが、一般には、PLC805は、施設のためのさらに大きなコンピューティング環境の一部として機能し、その環境内のその他のデバイスは、施設の外部源との間でデータを転送するための仲介としての役割を果たす。PLC805によって通信される電力需要データは、統合需要管理システムによってPLC805上で収集または生成される任意のデータを含むことができる。したがって、たとえば、伝送される電力需要データは、ローカルの電力メータ、電力負荷、またはローカルエネルギー源からの測定値、ならびに対応する需要限界設定点および予測電力需要値を含むことができる。加えて、いくつかの場合においては、伝送されるデータは、統合需要管理システムによって測定値から導出された情報を含むことができる。

0058

引き続き図8を参照すると、データがサーバ835において受信されると、それは、ローカルに格納されること、およびユーザコンピュータ830上に表示するためにグラフィカルユーザインターフェースGUI)において提示されることが可能である。このデータは、テキスト形式で提示されることが可能であり、またはサーバ835は、その情報を示すために1つもしくは複数のグラフカルプロットを生成することができる。いくつかの実施形態においては、GUIはさらに、ユーザが(ユーザコンピュータ830を介して)統合需要管理システムのパラメータをPLC805上で操作することを可能にする。たとえば、いくつかの実施形態においては、ユーザは、統合需要管理システムにとって利用可能である需要管理アクションを修正するためにGUIを利用することができる。

0059

拡張および代替形態
送電網を介して電力会社によって提供される電力を消費する施設というコンテキストにおいて例示的なシステムおよび技術が記述されているが、本明細書において記述されている原理は、その他の電力消費シナリオにも適用可能であるということが理解されるであろう。たとえば、自前の電力を生成し、公共送電網に接続されていない施設は、それでもなお、本明細書において記述されている統合需要管理システムおよび技術から恩恵を受けることができる。そのようなシナリオにおいては、送電網を利用しない施設は、バッテリーなど、1つまたは複数の2次電源とともに1次電源を有することができる。1次電源は、送電網を利用しない施設の電力ニーズの多くを供給することができるが、異常に高い需要レベルは、電源にダメージを与えるか、またはサービスの混乱につながる可能性がある。そのような施設においては、統合需要管理システムは、その施設が負荷を管理し、2次電源から電力を生成して、望ましくない需要レベルを回避することを可能にすることができる。このシナリオはまた、本明細書において記述されている技術的な解決策は、需要管理の点から技術的な利点を提供するものであり、単に公共料金の形態でのコストを低減する役割を果たすだけのものではないという事実を強調している。施設は、公共料金をまったく有していない可能性があるが、それでもなお、本明細書において記述されている需要管理システムおよび技術から技術的な利点を得ることができる。いくつかの時間期間が、本明細書においては、一般的な使用シナリオを例示するために「課金」期間および「デビット」期間の点から記述されているが、本明細書において記述されているシステムおよび技術は、本質的に金融的な性質のものではなく、本開示の範囲内でその他の形で特徴付けられることが可能であるということが理解されるであろう。

0060

本明細書において記述されているシステムおよびデバイスに対する多くの代替形態が可能である。たとえば、個々のモジュールまたはサブシステムは、分割されてさらなるモジュールもしくはサブシステムになること、または組み合わされてさらに少ないモジュールもしくはサブシステムになることが可能である。別の例として、モジュールまたはサブシステムは、省略されること、またはその他のモジュールもしくはサブシステムで補完されることが可能である。別の例として、特定のデバイス、モジュール、またはサブシステムによって実行されるものとして示されている機能は、代わりに、1つまたは複数のその他のデバイス、モジュール、またはサブシステムによって実行されることが可能である。本開示におけるいくつかの例は、特定のアレンジでの特定のハードウェアコンポーネントを含むデバイスの説明を含むが、本明細書において記述されている技術およびツールは、異なるハードウェアコンポーネント、組合せ、またはアレンジに対応するように修正されることが可能である。さらに、本開示におけるいくつかの例は、特定の使用シナリオの説明を含むが、本明細書において記述されている技術およびツールは、異なる使用シナリオに対応するように修正されることが可能である。ソフトウェアで実施されるものとして記述されている機能は、代わりにハードウェアで実施されることが可能であり、またはその逆もまた同様である。

0061

本明細書において記述されている技術に対する多くの代替形態が可能である。たとえば、さまざまな技術における処理ステージは、分割されてさらなるステージになること、または組み合わされてさらに少ないステージになることが可能である。別の例として、さまざまな技術における処理ステージは、省略されること、またはその他の技術もしくは処理ステージで補完されることが可能である。別の例として、特定の順序で生じるものとして記述されている処理ステージ同士は、代わりに、異なる順序で生じることが可能である。別の例として、一連のステップで実行されるものとして記述されている処理ステージ同士は、代わりに、並列な様式で取り扱われることが可能であり、複数のモジュールまたはソフトウェアプロセスが、示されている処理ステージのうちの1つまたは複数を同時に取り扱う。別の例として、特定のデバイスまたはモジュールによって実行されるものとして示されている処理ステージは、代わりに、1つまたは複数のその他のデバイスまたはモジュールによって実行されることが可能である。

0062

本開示の原理、代表的な実施形態、およびオペレーションのモードが、前述の説明において記述されている。しかしながら、保護されることを意図されている本開示の態様は、開示されている特定の実施形態に限定されるものとして解釈されるべきではない。さらに、本明細書において記述されている実施形態は、限定的ではなく例示的とみなされるべきである。本開示の趣旨から逸脱することなく、他者によって変形形態および変更形態が作成されることが可能であり、均等形態が採用されることが可能であるということが理解されるであろう。したがって、そのような変形形態、変更形態、および均等形態はすべて、特許請求されている主題の趣旨および範囲内に収まるということが明確に意図されている。

0063

本発明は、例示的な実施形態を参照しながら記述されているが、それらには限定されない。本発明の好ましい実施形態に対して多くの変更形態および修正形態が作成されることが可能であるということ、ならびにそのような変更形態および修正形態は、本発明の真の趣旨から逸脱することなく作成されることが可能であるということを当業者なら理解するであろう。したがって、添付の特許請求の範囲は、本発明の真の趣旨および範囲内に収まるすべてのそのような均等な変形形態をカバーするものであると解釈されることが意図されている。

0064

添付の図面に関連して上述されている詳細な説明(同様の数字は、同様の要素を指している)は、開示されている主題のさまざまな実施形態の説明として意図されているものであり、唯一の実施形態を表すことを意図されているものではない。本開示において記述されているそれぞれの実施形態は、例または例示として提供されているにすぎず、その他の実施形態よりも好ましいまたは有利であると解釈されるべきではない。本明細書において提供されている説明例は、網羅的であること、または特許請求の範囲に記載されている主題を、開示されている厳密な形態に限定することを意図されているものではない。

0065

本開示においては、本開示の例示的な実施形態の徹底的な理解を提供するために多くの具体的な詳細が示されている。しかしながら、本開示の多くの実施形態は、それらの具体的な詳細のうちのいくつかまたはすべてを伴わずに実施されることが可能であるということが、当業者にとっては明らかであろう。いくつかの場合においては、本開示のさまざまな態様を不必要にわかりにくくすることのないように、よく知られているプロセスステップは、詳細に記述されていない。さらに、本開示の実施形態は、本明細書において記述されている特徴同士の任意の組合せを採用することができるということが理解されるであろう。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

この 技術と関連性が強い技術

該当するデータがありません

この 技術と関連性が強い法人

該当するデータがありません

この 技術と関連性が強い人物

該当するデータがありません

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ