JP6009976B2 - エネルギー管理システム、エネルギー管理方法、プログラムおよびサーバ - Google Patents

Description

本発明の実施形態は、需要家側におけるエネルギー収支を管理するエネルギー管理システム、エネルギー管理方法、プログラムおよびサーバに関する。

近年の環境保全意識の高まりと電力不足への不安を背景として、ゼロエネルギー住宅（Zero Energy Home：ＺＥＨ）、あるいはネット・ゼロエネルギー住宅に注目が集まっている。ネット・ゼロエネルギー住宅は、年間の一次エネルギー消費量がネット（正味）で概ねゼロとなる住宅を意味する。これらを実現するために不可欠なのが、太陽光発電（Photovoltaic Power Generation：ＰＶ）システム、蓄電池、あるいは燃料電池（Fuel Cell：ＦＣ）などの分散電源と、家庭エネルギー管理システム（Home Energy Management System：ＨＥＭＳ）である。

ＦＣは、昼夜、天候を問わず安定して発電ができることと、排熱を利用して熱エネルギーを供給できることから、分散電源のなかでも特に有望視されている。しかしながらＦＣから商用電力系統（grid）への逆潮流は、電力会社との契約上、許されていない。そこで、ＦＣにより発電された電力の逆潮流を防止するための技術が幾つか提案されている。

特開２００９−２９６０９７号公報 特開２００２−４８００５号公報 特開２０１０−２７３４０７号公報 特開２０１１−１８１３７７号公報 特開２００５−３０４１１８号公報 特開２０１２−１１５００３号公報

逆潮流を防止するための対策として、ＦＣによる余剰電力をダミー負荷やヒータで消費するという技術がある。これではエネルギーが無駄に消費される。余剰電力を蓄電池に充電するという技術もあるが、充電の必要が生じたときに既に満充電であり、充電できないことも考えられる。

ヒータと蓄電池とを併用しても、ＦＣの出力を変化させるには長い時間を要するので、電力需要（デマンド）の少ない時間が長期に渡ると余剰電力の発生量が蓄電池容量を上回ってしまう。このようなケースではＦＣの運転を停止するか、ヒータで余剰電力を消費せざるを得ない。リレーにより系統から解列することで逆潮流を防止するにしても、生じた余剰電力は無駄に消費されているのが現状である。

その一方で、太陽熱や地中熱などの熱源を有効に利用すれば、余剰電力を系統に売電してコストメリットを得られる可能性がある。このように、直接、熱エネルギーとして利用可能な再生可能エネルギーをも考慮して余剰電力の無駄な消費を抑えようとする技術は知られていない。

目的は、余剰電力が無駄に消費されることを防止可能なエネルギー管理システム、エネルギー管理方法、プログラムおよびサーバを提供することにある。

実施形態によれば、エネルギー管理システムは、再生可能エネルギーを熱源とする給湯器を備える需要家のエネルギーを管理する。このエネルギー管理システムは、取得部と、予測部と、作成部と、制御部とを具備する。取得部は、給湯器、発電装置、蓄電装置およびエネルギー消費機器を含むエネルギー関連機器に係わるデータを需要家から取得する。予測部は、取得されたデータに基づいて需要家におけるエネルギーデマンドおよびエネルギー供給量を予測する。作成部は、蓄電装置の満充電に伴い破棄される余剰電力を最小化する条件下で、需要家におけるエネルギーコストを最小化すべく、予測されたエネルギーデマンドおよびエネルギー供給量に基づいてエネルギー関連機器の運転スケジュールを作成する。制御部は、作成された運転スケジュールに基づいてエネルギー関連機器を制御する。

図１は、実施形態に係わるシステムの一例を示す図である。 図２は、実施形態に係るエネルギー管理システムの一例を示す図である。 図３は、第１の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。 図４は、第１の実施形態に係わる制御対象モデル３００ｇについて説明するための図である。 図５は、第１の実施形態における処理手順の一例を示すフローチャートである。 図６は、第１の実施形態に係る遺伝的アルゴリズムの遺伝子設計の一例を示す概念図である。 図７は、第１の実施形態に係る最適化演算の流れの一例を示すフローチャートである。 図８は、第１の実施形態により得られる効果を説明するための図である。 図９は、第２の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。 図１０は、第２の実施形態に係わる制御対象モデル３００ｇについて説明するための図である。

図１は、実施形態に係わるシステムの一例を示す図である。図１は、いわゆるスマートグリッドとして知られるシステムの一例を示す。既存の電力網（grid）では原子力、火力、水力などの既存発電所と、一般家庭や、ビル、工場といった多種多様な需要家とが電力網によって接続される。次世代の電力系統（Power grid）ではこれらに加えて太陽光発電（Photovoltaic Power Generation：ＰＶ）システムや風力発電装置などの分散型電源や蓄電装置、新交通システムや充電スタンドなどが電力系統に接続される。これら多種多様な要素は通信グリッドを介して通信することが可能である。

エネルギーを管理するシステムは、エネルギーマネジメントシステム（Energy Management System：ＥＭＳ）と総称される。ＥＭＳはその規模などに応じて幾つかに分類される。例えば一般家庭向けのＨＥＭＳのほか、ビルディング向けのＢＥＭＳ（Building Energy Management System）などがある。このほか、集合住宅向けのＭＥＭＳ（Mansion Energy Management System）、コミュニティ向けのＣＥＭＳ（Community Energy Management System）、工場向けのＦＥＭＳ（Factory Energy Management System）などがある。これらのシステムが連携することできめ細かなエネルギー最適化制御が実現される。

これらのシステムによれば既存の発電所、分散型電源、太陽光や風力などの再生可能エネルギー源、および需要家の相互間で高度な協調運用が可能になる。これにより再生可能エネルギーを主体とするエネルギー供給システムや、需要家と事業者との双方向連携による需要家参加型のエネルギー需給といった、新規かつスマートな形態の電力供給サービスが生み出される。

図２は、実施形態に係るエネルギー管理システムの一例を示す図である。ＨＥＭＳは、クライアントシステムと、クライアントシステムと通信可能なサーバシステムとしてのクラウドコンピューティングシステム（以下、クラウドと略称する）３００とを備える。

クライアントシステムは、クライアント装置としてのホームゲートウェイ（Home Gateway：ＨＧＷ）７を備える。ホームゲートウェイ７はホーム１００に設置される通信装置であり、クラウド３００から各種のサービスの提供を受けることができる。

クラウド３００は、サーバコンピュータＳＶとデータベースＤＢとを備える。サーバコンピュータＳＶは単体でも複数でも良い。データベースＤＢは一つのサーバコンピュータＳＶに備えられていても、複数のサーバコンピュータＳＶに分散配置されていてもよい。

図２において、電力グリッド６から供給される電力（交流電圧）は、電柱の変圧器６１などを経て各家庭に分配され、電力量計（スマートメータ）１９を経てホーム１００の分電盤２０に供給される。電力量計１９は、ホーム１００に備わるエネルギー生産機器の発電量、ホーム１００の消費電力量、電力グリッド６から流れ込む電力量、あるいは電力グリッド６に逆潮流する電力量などを計測する機能を備える。周知のように、再生可能エネルギーに基づいて発電された電力は、電力グリッド６に逆潮流することを許される。

分電盤２０は、この分電盤２０に接続される電気機器（照明、エアコンなど）５やパワーコンディショニングシステム（ＰＣＳ）１０４に配電線２１を介して電力を供給する。また分電盤２０は、フィーダごとの電力量を計測する計測装置を備える。

電気機器５はホーム１００内の配電線２１に接続されることの可能な機器である。電気機器５はコンセント（図示せず）を介して配電線２１に着脱可能に接続され、配電線２１を介して分電盤２０に接続される。電気機器５により電力が消費される。

ホーム１００の屋根や外壁にはＰＶユニット１０１が設置される。ＰＶユニット１０１は、再生可能エネルギーから電気機器５を稼動させるためのエネルギーを生産する創エネルギー機器であり、風力発電システムなどもその範疇に入る。ＦＣユニット１０３は、非再生可能エネルギー源である都市ガスやＬＰガス（液化プロパンガス）から電力を生産する発電ユニットである。ＦＣユニット１０３により生成された電力は電力グリッド６に逆潮流することを禁止されているので、余剰電力を生じることがある。余剰電力は蓄電池１０２に充電されることが可能である。

ＰＣＳ１０４はインバータ（図示せず）を備え、ＰＶユニット１０１、蓄電池１０２あるいはＦＣユニット１０３から供給される直流電力を交流電力に変換して配電線２１に供給する。これにより、電気機器はＰＣＳ１０４を介して、蓄電池１０２やＦＣユニット１０３からも電力の供給を受けることができる。また、ＰＣＳ１０４はコンバータ（図示せず）を備え、配電線２１からの交流電力を直流電力に変換して蓄電池１０２に供給する。

要するにＰＣＳ１０４は、蓄電池１０２、ＦＣユニット１０３と配電線２１との間でエネルギーを授受するための電力変換器としての機能を備える。ＰＣＳ１０４は蓄電池１０２やＦＣユニット１０３を安定に制御する機能も備える。なおＰＣＳ１０４は、ＰＶユニット１０１、蓄電池１０２およびＦＣユニット１０３のそれぞれに、個別に設けられても良い。

さらに、ホーム１００の屋根には太陽熱温水器１０６が設置される。太陽熱温水器１０６は、再生可能エネルギーである太陽熱を熱源として温水を生成する、創エネルギー機器である。生成された温水はホーム１００の給湯配管（図示せず）に供給される。ホーム１００のエネルギー収支を最適化するために、太陽熱温水器１０６により得られた熱エネルギーを利用することが可能である。

ホーム１００には無線ＬＡＮ（Local Area Network）などのホームネットワーク２５が形成される。ホームゲートウェイ７はホームネットワーク２５とＩＰネットワーク２００との双方に、コネクタ（図示せず）などを介して着脱可能に接続される。これによりホームゲートウェイ７は、ホームネットワーク２５に接続される電力量計１９、分電盤２０、ＰＣＳ１０４、および電気機器５と相互に通信可能である。なおホームネットワーク２５は無線、あるいは有線のいずれでも良い。

ホームゲートウェイ７は、実施形態に係る処理機能として通信部７ａを備える。通信部７ａは、クラウド３００に各種のデータを送信し、またクラウド３００から各種のデータを受信する、ネットワークインタフェースである。

ホームゲートウェイ７はCentral Processing Unit（ＣＰＵ）とメモリ（図示せず）を備えるコンピュータである。メモリは、このコンピュータを制御するプログラムを記憶する。プログラムは、クラウド３００と通信したり、電気機器５や蓄電池１０２、ＦＣユニット１０３の運転スケジュールの計算をクラウド３００に要求したり、システムの制御に需要家の意思を反映させたりするための命令を含む。ＣＰＵが各種のプログラムに基づいて機能することで、ホームゲートウェイ７に係る諸機能が実現される。

すなわちホームゲートウェイ７は、クラウド３００に各種のデータを送信し、またクラウド３００から各種のデータを受信する。ホームゲートウェイ７は、クラウド３００、サーバコンピュータＳＶと通信可能なクライアント装置である。ホームゲートウェイ７から送信される各種データには、クラウド３００に各種の演算を要求するための要求信号が含まれる。

ホームゲートウェイ７は有線回線または無線回線を介して端末１０５に接続される。ホームゲートウェイ７と端末１０５とを合わせてローカルサーバとしての機能を実現することも可能である。端末１０５はいわゆるタッチパネルなどのほか、例えば汎用的な携帯情報機器やパーソナルコンピュータなどでもよい。

端末１０５は電気機器５、ＰＶユニット１０１、蓄電池１０２、ＦＣユニット１０３の稼働状況や消費電力量を例えばＬＣＤ（Liquid Crystal Display）に表示したり、音声ガイダンスなどで需要家（ユーザ）に報知する。また端末１０５は操作パネルを備え、需要家による各種の操作や設定入力を受け付ける。

ＩＰネットワーク２００は、いわゆるインターネット、あるいはシステムベンダのＶＰＮ（Virtual Private Network）などである。ホームゲートウェイ７は、ＩＰネットワーク２００を経由してサーバコンピュータＳＶと通信したり、データベースＤＢとデータを授受したりできる。なおＩＰネットワーク２００は、ホームゲートウェイ７とクラウド３００との間に双方向の通信環境を形成するための、無線または有線の通信インフラストラクチャを含んで良い。

クラウド３００は、収集部３００ａ、予測部３００ｂ、作成部３００ｃ、および制御部３００ｄを備える。また、蓄電池１０２、ＦＣユニット１０３および太陽熱温水器１０６の制御対象モデル３００ｇ、および各種のデータ３００ｈがクラウド３００のデータベースＤＢに記憶される。収集部３００ａ、予測部３００ｂ、作成部３００ｃ、および制御部３００ｄは、単体のサーバコンピュータＳＶ、あるいは、クラウド３００に分散配置される機能オブジェクトである。これらの機能オブジェクトを如何にしてシステムにインプリメントするかは、当業者によれば容易に理解されるであろう。

例えば収集部３００ａ、予測部３００ｂ、作成部３００ｃ、および制御部３００ｄは、クラウド３００のサーバコンピュータＳＶにより実行されるプログラムとして実現される。このプログラムは単体のコンピュータにより実行されることもできるし、複数のコンピュータを備えるシステムにより実行されることも可能である。プログラムに記載される命令が実行されることで、実施形態に係わる諸機能が実現される。

収集部３００ａは、ホーム１００の電気機器５、ＰＶユニット１０１、蓄電池１０２、ＦＣユニット１０３および太陽熱温水器１０６などの機器、要するにエネルギー関連機器に係わるデータを、各ホーム１００のホームゲートウェイ７から定期的、あるいは不定期に取得する。また収集部３００ａは、端末１０５におけるユーザの操作履歴などを端末１０５から取得する。なお収集部３００ａと端末１０５とが通信回線４０を介して直接通信することも可能である。

取得されたデータはデータベースＤＢにデータ３００ｈとして保持される。データ３００ｈは、各ホーム１００の電力デマンド、各電気機器５の消費電力量、給湯量、稼動状態、蓄電池１０２の充電残量や充放電電力、ＰＶユニット１０１の発電量などを含む。加えて、気象庁などから提供される気象データなどもデータ３００ｈに含めることが可能である。

予測部３００ｂは、収集部３００ａにより取得されたデータ３００ｈに基づいて、ホーム１００におけるエネルギーデマンド（energy demand）を予測する。エネルギーデマンドは、例えば電力デマンドや給湯デマンドである。また予測部３００ｂは、データ３００ｈに基づいてホーム１００におけるエネルギー供給量（energy supply）を予測する。エネルギー供給量は、ＰＶユニット１０１およびＦＣユニット１０３の発電量（電力ベース）に加え、太陽熱温水器１０６からの給湯量（熱量ベース）も含む。

作成部３００ｃは、制御対象モデル３００ｇと、予測されたエネルギーデマンドおよびエネルギー供給量に基づいて、蓄電池１０２、ＦＣユニット１０３の運転スケジュールを作成する。つまり作成部３００ｃは、例えば電力デマンド、給湯デマンド、給湯量、およびＰＶ発電量に基づいて、例えば蓄電池１０２の充放電スケジュール、またはＦＣユニット１０３の発電スケジュール（ＦＣ発電スケジュール）を計算する。

すなわち作成部３００ｃは、ホーム１００におけるエネルギー収支を最適化すべく、蓄電池１０２、ＦＣユニット１０３の運転スケジュールを決定する。この処理を最適スケジューリングと称する。エネルギー収支とは例えば光熱費収支であり、電気機器５により消費される電力エネルギーのコストと、主にＰＶユニット１０１により生成されるエネルギーの売電料金とのバランスにより評価される。実施形態ではさらに、太陽熱温水器１０６から供給される熱エネルギーを利用することを考える。計算された蓄電池１０２、ＦＣユニット１０３の時系列の運転スケジュールはデータベースＤＢに記憶される。

制御部３００ｄは、計算された運転スケジュールに基づいて上記エネルギー関連機器を制御する。より具体的には、制御部３００ｄは蓄電池１０２、ＦＣユニット１０３を制御するための制御情報を生成する。すなわち制御部３００ｄは、最適スケジューリングの結果から蓄電池１０２の充放電、稼動、またはＦＣユニット１０３の発電のための運転・停止指示、出力目標値などを生成する。これらの制御情報は、通信回線４０を介して端末１０５やホームゲートウェイ７に送信される。

ホーム１００の端末１０５は、制御部３００ｄから送信された制御情報に基づく電気機器５の制御に、需要家の意思を反映させるためのインタフェース部（図３のユーザインタフェース１０５ａ）を備える。ユーザインタフェース１０５ａは、蓄電池１０２の充放電スケジュールやＦＣユニット１０３の発電スケジュールを表示するために表示器を備える。ユーザは、表示器に表示された内容を見てスケジュールを確認したり、表示されたスケジュールの実行の許可または拒否を選択したりすることができる。これによりスケジュールの実行にユーザの意思を反映させることができる。

また、需要家は、クラウド３００にスケジュールの再計算を要求したり、そのために必要になる情報をシステムに与えたりするための指示（コマンド）を、ユーザインタフェース１０５ａを介して入力することができる。以上の構成を基礎として、以下に、複数の実施形態を説明する。

［第１の実施形態］
図３は、第１の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。図３において、ホーム１００のＰＣＳ１０４、電気機器５、蓄電池１０２、ＦＣユニット１０３、電力量計１９、および分電盤２０から各電気機器５の所定時間ごとの消費電力量、稼動状態、蓄電池１０２の充電残量や充放電電力量、ホーム１００の電力デマンド、給湯デマンド、ＰＶ発電量、太陽熱温水量（太陽熱温水器１０６により供給される温水の量）などのデータが、ホームゲートウェイ７を介して定期的、あるいは不定期にクラウド３００に送信される。

需要家によりユーザインタフェース１０５ａを介して設定された量に対して実際のデータが上回る、あるいは下回る状態になると、ホームゲートウェイ７は、上記データをクラウド３００に送信する。不定期とは、このようなタイミングでの送信を意味する。また端末１０５のユーザの操作履歴なども、クラウド３００に送信される。これらのデータや情報はデータベースＤＢ群に格納される。

需要家ごとに設けられる予測部３００ｂは、収集したデータのうち電力デマンド、給湯デマンド、ＰＶ発電量に加えて天気予報などの気象データなども用いて、対象とする日の所定時間ごとの電力デマンド、給湯デマンドおよびＰＶ発電量を予測する。気象データは１日数回のタイミングで他のサーバ（気象庁など）から配信される。この気象データを受信したタイミングに合わせて予測計算を実行してもよい。

デマンドは、気象情報と過去の需要データからニューラルネットワークにより予測したり（特開平０６−２７６６８１号公報に開示）、複数の需要家の過去の需要データをグループ化し、グループごとの平均な需要変動モデルによって予測する（特開２００４−１１２８６９号公報に開示）ことが可能である。

給湯デマンドは、例えばカレンダ情報から予測する（特開２０１１−８３０８４号公報に開示）ことができる。ＰＶ発電量は、過去データにおける異なる時刻の間の統計的相関、あるいは異なる設置位置の間の統計的相関に基づいて予測する（特開２０１１−２０００４０号公報）ことが可能である。太陽熱温水についても同様にして予測可能である。
需要家ごとに設けられる作成部３００ｃは、予測計算により算出された所定時間ごとのエネルギーデマンド、エネルギー供給量、エネルギー単価、および制御対象モデル３００ｇなどに基づいて、電気機器５の動作制御に係わる最適スケジューリングを実行する。

予測部３００ｂ、作成部３００ｃは、例えば需要家ごとに専用に設けられる機能オブジェクトとしてインプリメントされることが可能である。つまり予測部３００ｂ、作成部３００ｃの機能を需要家ごとに設けることが可能である。例えばプログラムの実行過程においてスレッドを複数立てることで、このような形態が可能である。このような形態によればセキュリティを確保し易いなどのメリットがある。

あるいは、予測部３００ｂ、作成部３００ｃを、複数の需要家に対して設けられる機能オブジェクトとしてインプリメントすることも可能である。つまり予測部３００ｂ、作成部３００ｃによる演算を、複数の需要家をまとめた単位で実行することも可能である。このような形態によれば計算リソースの節約などのメリットを得ることが可能である。

図４は、第１の実施形態に係わる制御対象モデル３００ｇについて説明するための図である。制御対象モデル３００ｇは、電力系統６、ＦＣユニット１０３、太陽熱温水器１０６、蓄電池１０２、ＰＶシステム１０１および負荷（家電）２０５を要素として含む。ＦＣユニット１０３は、ＦＣ本体２２０、補助ボイラ２２１、逆潮流防止ヒータ２２２、および貯湯槽２２３を要素として含む。図４に示される変量を次の表に示す。

制御対象モデル３００ｇは、それぞれの要素の間の入出力関係と、要素間の入力変数、あるいは出力変数の間の関係式を示す。例えば次式（１）〜（１１）により制御対象モデル３００ｇを表現することが可能である。

式（１）において、ガス供給量Ｆ（ｔ）は、ＦＣへの供給量Ｆ_FC（ｔ）と補助ボイラへの供給量Ｆ_B（ｔ）との和として示される。ＦＣ本体２２０は、Ｆ_FC（ｔ）のガス供給量に対してＰ_FC（ｔ）だけ発電し、Ｑ_FC（ｔ）だけ排熱するとする。このＦＣ本体２２０の入出力特性、すなわちＦＣ本体２２０におけるガス供給量、発電量、および排熱量の関係を、式（２）、（３）のように近似して示す。

逆潮流防止ヒータ２２２は、余剰電力Ｐ_H（ｔ）を熱量Ｑ_H（ｔ）の熱に変換にして消費させる、つまり廃棄することで、余剰電力が電力系統６に逆潮流しないように制御する。補助ボイラ２２１は、給湯デマンドのうち貯湯槽２２３からの給湯Ｑ_ST（ｔ）で賄いきれない分の給湯Ｑ_B（ｔ）を供給する。

貯湯槽２２３の貯湯量Ｈ（ｔ）は、式（４）に示されるように、ＦＣ本体２２０の排熱Ｑ_FC（ｔ）、逆潮流防止ヒータ２２２の発熱量Ｑ_H（ｔ）および給湯Ｑ_ST（ｔ）により増減する。式（４）の左辺は貯湯槽２２３に入る熱量を湯量ベースで表すもので、左辺第１項はｒ・Ｈ（ｔ−１）＝残存率×前回貯湯量＝放熱後に残る湯量である。ここで貯湯効率（残存率）ｒは、時間ｔ−１からｔの間で、放熱による減少後に残る熱の割合を示す係数である。左辺第２項はＦＣ排熱の回収量であり、第３項は逆潮流防止ヒータの発熱量であり、いずれも湯量換算値である。なお太陽熱温水器１０６からの給湯配管が貯湯槽２２３に接続されているケースでは、式（４）の左辺にＱ_S（ｔ）が加算され、後述する式（１１）の右辺のＱ_S（ｔ）は削除することになる。

式（４）の右辺は貯湯槽２２３から出る熱量との残りの熱量とを湯量ベースで表すもので、第１項は今回の貯湯量、第２項は今回の給湯量（厳密にはｔ−１からｔの間での給湯量）を示す。式（５）は貯湯槽２２３の容量制約を示す。

蓄電池１０２は、充放電電力Ｐ_SB（ｔ）により充電残量Ｓ（ｔ）が増減するモデルとしてモデル化することが可能である。式（６）は、電力の需給バランスを示す。Ｐ_D（ｔ）はホーム１００の電力需要（デマンド）を示し、Ｐ_C（ｔ）は購入電力または売電電力を示し、Ｐ_PV（ｔ）はＰＶユニット１０１の発電量を示す。式（７）、（８）はＦＣ本体２２０と蓄電池１０２からの逆潮流を禁止するという制約条件を示す。式（９）は蓄電池１０２の容量の制約条件を示す。

式（１０）は、ＦＣユニット１０３（ＦＣ本体２２０）の、発電量の時間に対する変化を既定の範囲内に制限するという制約条件を示す。つまり式（１０）は、或る時刻ｔ−１から次の時刻ｔにおけるＦＣ本体２２０発電量の変化量を、ＦＣ発電量の減少速度の下限である−Ｐ_{FC_DOWN}とＦＣ発電量の増加速度の上限であるＰ_{FC_UP}との間に制限するという制約条件である。

なお、給湯デマンドＱ_D（ｔ）は、式（１１）に示されるように貯湯槽２２３からの給湯量Ｑ_ST（ｔ）と、補助ボイラからの給湯量Ｑ_B（ｔ）と、太陽熱温水器１０６からの給湯Ｑ_S（ｔ）とで賄われる。

作成部３００ｃ（図２、図３）は、以上のような条件のもとで、電力デマンド、給湯デマンドとＰＶ発電量、太陽熱温水器１０６からの温水量、電気・ガスの料金単価および電力買い取り価格が与えられたとき、蓄電池１０２の満充電に伴い破棄される余剰電力を最小化するという制約条件下で、光熱費（エネルギーコスト）が最小となるように、ＦＣユニット１０３の発電Ｐ_FC（ｔ）、蓄電池１０２の充放電Ｐ_SB（ｔ）のスケジュールを求める。最適化アルゴリズムには例えば遺伝的アルゴリズムを用いることができる。次に、上記構成における作用を説明する。

図５は、第１の実施形態における処理手順の一例を示すフローチャートである。最適化演算には電力デマンド予測、給湯デマンド予測、ＰＶ発電量予測などが必要であり、この最適化演算は予測計算が実行される１日数回のタイミングに合わせて実行される。

図５において、予測部３００ｂは所定時間ごとの電力デマンド、給湯デマンド、ＰＶ発電量および太陽熱温水量に係わる各データをデータベースＤＢから取得する（ステップＳ１−１）。このステップでは現在のデータだけでなく、例えば前年同日のデータなど過去のデータを取得しても良い。次に予測部３００ｂは、運転スケジュールの算出のため所定時間ごとの電力デマンド、給湯デマンド、ＰＶ発電量および太陽熱温水量を予測する（ステップＳ１−２）。

次に作成部３００ｃは、光熱費収支を最小とすべくＦＣユニット１０３の発電量と蓄電池１０２の充放電量の所定時間ごとのスケジュールを算出する（ステップＳ１−３）。算出されたスケジュールはデータベースＤＢに記憶される。

次にシステムは、蓄電池１０２の充放電量スケジュールまたはＦＣユニット１０３の発電量のスケジュールを示すメッセージ信号を、ＩＰネットワーク２００を介して端末１０５に送信する。端末１０５はメッセージ信号を解読して各種スケジュールをインタフェースに表示する（ステップＳ１−４）。メッセージ信号の送信から表示に係わるルーチンは定期的に、あるいはユーザからの要求に応じて実行される。

次に、クラウド３００は、運転スケジュールの実行がユーザにより許可されたことを示す許可メッセージ信号の到来を待ち受ける（ステップＳ１−５）。許可されれば、機器運転スケジューラ（制御部３００ｄ）は、作成されたスケジュールに沿ってホーム１００の電気機器５を制御するための制御情報を、ＩＰネットワーク２００経由でホーム１００のホームゲートウェイ７に送信する（ステップＳ１−６）。制御情報は、例えば蓄電池１０２の充放電、ＦＣユニット１０３の発電のための運転・停止指示、出力目標値などを含む。以上の手順はスケジュールの時間間隔ごとに繰り返される。

制御部（機器運転スケジューラ）３００ｄは、最適スケジューリングの結果から蓄電池１０２の充放電、またはＦＣユニット１０３の発電のための運転・停止指示、出力目標値などをスケジュールの時間間隔ごとに生成し、ホーム１００のホームゲートウェイ７に送信する。ユーザは送信された制御情報に基づく制御の可否を、ユーザインタフェース１０５ａを介してシステムに指示する。

またユーザインタフェース１０５ａは、太陽熱温水器１０６の現在の状態や、状態の予測データを表示する。このほか貯湯の温度、体積、熱量、生成に必要な燃料や電力に換算した値、あるいはそれらの使用量などを表示してもよい。

図６は、第１の実施形態に係る遺伝的アルゴリズムの遺伝子設計の一例を示す概念図である。第１の実施形態では、遺伝子にＦＣユニット１０３の発電量Ｐ_FC（ｔ）と蓄電池１０２の充放電電力Ｐ_SB（ｔ）とを組み込むようにした。１日分の蓄電池１０２およびＦＣユニット１０３の運転スケジュールを個体とし、複数の個体から世代を形成する。

式（１２）に、最大化すべき適合度Ｆｉｔを示す。このＦｉｔを目的関数として最適化することにより、運転スケジュールを算出することができる。光熱費収支Ｃを式（１３）に示し、機器稼動の不連続性に掛かるコストｇ（Ｐ_FC、Ｐ_SB）を式（１４）に示す。光熱費収支Ｃにおけるｔ＝０〜ｔ＝２３までの総和は２４時間に渡る和を求めることに対応する。

式（１２）において、適合度Ｆｉｔを、１日あたりの光熱費収支Ｃを変数とする単調増加関数ｆ（Ｃ）に機器稼動の不連続性に掛かるコストｇ（Ｐ_FC、Ｐ_SB）＞０を加算し、その逆数として表す。これは、ホーム１００のデマンドをＰＶ発電量が大きく上回ると光熱費収支Ｃが負になる可能性を考慮し、光熱費収支Ｃの減少と適合度Ｆｉｔの増加とを対応させるためである。第１の実施形態ではｆ（Ｃ）＞０となる関数を用いる。

以上の式に、電力デマンド、給湯デマンド、ＰＶ発電量、太陽熱温水量、電気料金単価、ガス料金単価、およびＰＶ買取価格を与え、突然変異、交差、淘汰など、遺伝的操作を繰り返してＦｉｔを最大化することにより、光熱費収支Ｃが小さくなるようにＦＣユニット１０３の発電量Ｐ_FC（ｔ）と蓄電池１０２の充放電Ｐ_SB（ｔ）の系列を求めることが可能になる。

図７は、第１の実施形態に係る最適化演算の流れの一例を示すフローチャートである。先に述べたように、作成部３００ｃは遺伝的アルゴリズムにより最適化演算を実施する。

（ステップＳ２−１） 初期個体群の生成
ランダムまたは過去の実績値に基づいて、制約条件を満足するｎ個の初期個体を発生させる。制約条件を満足しない固体は遺伝子をビット反転させて、制約条件を満足させるように改変する。

（ステップＳ２−２） 終了判定処理
ステップＳ２−３〜Ｓ２−６の処理を繰り返す処理である。各個体の適合度およびその世代での平均適合度を計算する。ステップＳ２−２のループが規定回数になればアルゴリズム演算を終了する。または、その世代における平均適応度を前２世代の平均適応度と比較し、その結果が任意に設定した値ε以下であればアルゴリズムを終了する。

（ステップＳ２−３） 淘汰
制約条件を満足しない個体を淘汰する。また、予め定義した個体数以上の個体が存在する場合は適応度の悪い（適応度の小さい）個体をその個数まで淘汰する。

（ステップＳ２−４） 増殖
個体数が予め定義した個体数より少ない場合、適応度が最良の個体を増殖させる。

（ステップＳ２−５） 交叉
ランダムにペアリングを行う。ペアリングは全個体数に対する割合（交叉率）分だけ行い、ペアごとにランダムに遺伝子座を選び、一点交叉させる。

（ステップＳ２−６） 突然変異
全個体数に対する割合（突然変異率）分だけランダムに個体を選び、各個体の任意（ランダムに決定する）の遺伝子座の遺伝子をビット反転させる。

（ステップＳ２−２）〜（ステップＳ２−６）の手順は、世代数＜最大世代数の条件が満たされるまで、世代数をインクリメントしつつ繰り返される。この条件が満たされれば結果出力（ステップＳ２−７）ののち終了となる。

図８は、第１の実施形態により得られる効果を説明するための図である。図８はホーム１００の１日の電力デマンドと給湯デマンドの予測結果に基づき算出された、蓄電池１０２およびＦＣユニット１０３の１日分の運転スケジュールの一例を示す。電気料金単価は７：００から２３：００までが２８円／ｋＷｈ、２３：００から翌日７：００までが９円／ｋＷｈの昼夜別料金を想定した。図８においては売電による光熱費収支の改善については想定せず、電力デマンド、給湯デマンドと電気、ガスの料金単価のみを用いた計算結果を示す。

蓄電池１０２の運転スケジュールは、電気料金単価の安い時間帯（０：００〜６：００）に充電し、電気料金単価の高い時間帯（７：００〜１０：００、１３：００〜２２：００）に放電するようになっている。これにより、電気料金単価の高い時間帯の購入電力が減るので電気代を減らすことできる。

ＦＣユニット１０３は最大出力で運転し、発電量がデマンドを上回る時間（１２：００〜１４：００）は余剰発電量が蓄電池１０２に充電される。よって発電された電力が逆潮流防止ヒータ２２２で無駄に消費（廃棄）されることを防止でき、ガス代も削減することが可能になる。逆潮流防止ヒータ２２２は、２４時間に渡って稼働することなく推移していることが分かる。

また図８には、時間ごとの総貯湯量の推移をカロリーベースで示すグラフが示される。このグラフは、貯湯槽２２３における例えば４５°Ｃ以上の湯量と、太陽熱温水器１０６に保持される同温度の湯量との合計を示す。このグラフは基本的にはＰＶ発電量と同様の日内変動を示すが、ＦＣユニット１０３の稼動状態と給湯デマンドの変化に応じても変化する。

以上述べたように第１の実施形態では、ホーム１００におけるＰＶ発電量、電力デマンド、給湯デマンドおよび太陽熱温水量を予測する。そして、予測値に基づいて、設定した制約条件下で評価関数を最小化する最適化計算を実行し、エネルギーコストを最小化すべくエネルギー管理を行う。つまり、ＦＣユニット１０３の発電量を可変とし、太陽熱温水量を組み込んだ制御モデルに基づいて、ＦＣユニット１０３の運転スケジュールおよび蓄電池１０２の充放電スケジュールを最適化するようにしている。これにより逆潮流防止ヒータ２２２を無駄に稼動させず、光熱費を安くすることの可能なスケジュールを作成することが可能になる。

また第１の実施形態では、式（１２）、（１３）に示すように、最大化すべき適合度Ｆｉｔを示す関数に、ＦＣユニット１０３の稼働に要するガス料金を含めるようにしている。これにより、可能解が存在するという条件下で、逆潮流防止ヒータ２２２を無駄に動作させるようなスケジュールは最適化計算の過程で淘汰される方向に作用する。

また、或る時刻ｔ−１から次の時刻ｔにおけるＦＣユニット１０３の発電量の変化量を、ＦＣユニット１０３の発電量の減少速度の下限−Ｐ_{FC_DOWN}からＦＣユニット１０３の発電量の増加速度の上限Ｐ_{FC_UP}の範囲に収める制約条件（式（１０））を設けたので、ＦＣユニット１０３の発電量の変化量がデマンドへの追従能力を超えないような発電スケジュールを生成することが可能となる。つまり上記制約条件により、デマンドへの追従能力を超えない範囲で、ＦＣユニット１０３の発電スケジュールを生成することが可能になる。つまり、ＨＥＭＳの立てた発電スケジュールに応じてＦＣユニット１０３を稼働させることが可能になる。

特に、ステップＳ１−２の予測手順と、ステップＳ１−３の最適スケジューリング（図５）とを組み合せることで、一日分程度のまとまった期間のデマンド予測、給湯デマンド予測、ＰＶ発電予測および太陽熱温水量予測に応じて、ＦＣユニット１０３の発電スケジュールや蓄電池１０２の充放電スケジュールといった需給計画を、全体のバランスを考慮したうえで作成できるようになる。
従って、蓄電池１０２が満充電になり、ＦＣユニット１０３の余剰電力を充電できないケースや、蓄電池１０２から放電すべきときに充電残量が足りないといったケースを回避することが可能になる。

以上から第１の実施形態によれば、商用電力系統に逆潮流できない余剰電力を無駄に消費することなく、有効に利用することが可能になる。これらのことから、余剰電力が無駄に消費されることを防止可能なエネルギー管理システム、エネルギー管理方法、プログラムおよびサーバを提供することが可能になる。

［第２の実施形態］
図９は、第２の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。図９において図３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。第２の実施形態では、ＦＣユニット１０３に代えて、地中熱エネルギーを利用するヒートポンプ式給湯器（ＨＰ）１１０を併用するケースを想定する。ヒートポンプ式給湯器１１０は、最適化された運転スケジュールに基づいて制御部３００ｄにより制御される。

図１０は、第２の実施形態に係る制御対象モデル３００ｇについて説明するための図である。図４と比較して、ＦＣ本体２２０がヒートポンプ式給湯器１１０に置き換わる。ヒートポンプ式給湯器１１０はＦＣユニット１０３に比べて制御の応答性に優れるので、逆潮流防止ヒータ２２２を排除することが可能である。次式（１５）〜（２２）に、図１０における各変量の関係が示される。

新たな変量Ｐ_HP（ｔ）、Ｑ_HP（ｔ）は次に示される量である。

図１０に示される制御対象モデルを用い、上記各変量を用いて第１の実施形態と同様に最適化を実行することで運転スケジュールを算出することが可能である。その詳細については第１の実施形態と同様であるので、煩雑を避けるために説明を省略する。

第２の実施形態ではヒートポンプ式給湯器１０７を最適化計算に組み入れる。すなわち作成部３００ｃは、ホーム１００の電力デマンド予測および給湯デマンド予測と、地中熱エネルギーとに基づいて評価関数を最小化すべく最適化計算を実施し、運転スケジュールを作成する。第２の実施形態によれば、ＦＣユニット１０３の燃料が不要になるので、さらなるコストメリットを得ることが可能になる。

なお本発明は上記実施形態に限定されるものではない。例えば実施形態では遺伝的アルゴリズムを利用することについて説明したが、運転スケジュールを算出するための解法として遺伝的アルゴリズムは唯一のものではない。他の種々のアルゴリズムを用いて最適な運転スケジュールを算出することが可能である。

また実施形態では、太陽熱温水器から給湯配管に直接、給湯するケースを説明した。これに限らず、太陽熱温水器からの温水をヒートポンプ式給湯器に給水するルートを設けても良い。このような構成は日射量の少ない冬季や寒冷地においては有利である。

さらに、熱交換器により浴槽の残り湯から熱を回収し、太陽熱温水器からの温水、あるいはヒートポンプ式給湯器からの温水を加温するようにしても良い。このように、給湯器から供給される温水と浴槽内の温水との間で熱エネルギーを交換する熱交換器をホーム１００に備えるようにしてもよい。このケースでは、作成部３００ｃは、予測されたエネルギーデマンド、エネルギー供給量、および熱エネルギーに基づいて運転スケジュールを作成する。

さらに、ユーザインタフェース１０５ａに、太陽熱エネルギーや地中熱エネルギーなどの、外部からの熱収支に関する情報を表示するようにしてもよい。このようにすれば、電力エネルギーだけに着目しがちなユーザにも、熱エネルギーを意識させることが可能になる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

３００…クラウドコンピューティングシステム、７…ホームゲートウェイ、１００…ホーム、ＳＶ…サーバコンピュータ、ＤＢ…データベース、６…電力グリッド、６１…変圧器、１９…電力量計（スマートメータ）、２０…分電盤、５…電気機器、１０４…パワーコンディショニングシステム（ＰＣＳ）、２１…配電線、１０１…ＰＶユニット、１０３…ＦＣユニット、１０２…蓄電池、１０６…太陽熱温水器、２５…ホームネットワーク、２００…ＩＰネットワーク、７ａ…通信部、１０５…端末、３００ａ…収集部、３００ｂ…予測部、３００ｃ…作成部、３００ｄ…制御部、３００ｇ…制御対象モデル、３００ｈ…データ、４０…通信回線、１０５ａ…ユーザインタフェース、２０５…負荷（家電）、２２０…ＦＣ本体、２２１…補助ボイラ、２２２…逆潮流防止ヒータ、２２３…貯湯槽、１１０…ヒートポンプ式給湯器

Claims (26)

1. 需要家のエネルギーを管理するエネルギー管理システムであって、
   再生可能エネルギーを熱源とする給湯器、燃料電池、蓄電装置およびエネルギー消費機器に係わるデータを前記需要家から取得する取得部と、
   電力デマンドおよび給湯デマンドを含む前記需要家におけるエネルギーデマンドと、前記給湯器の給湯量および前記燃料電池の発電量を含む前記需要家におけるエネルギー供給量とを、前記取得されたデータに基づいて予測する予測部と、
   前記予測されたエネルギーデマンドおよびエネルギー供給量に基づいて、前記蓄電装置の満充電に伴い破棄される余剰電力を制限する制約条件下で、前記需要家におけるエネルギーコストを最小化すべく最適化演算を実施する作成部と、
   前記最適化演算の結果に基づいて、前記燃料電池および前記蓄電装置の少なくともいずれかを制御する制御部とを具備する、エネルギー管理システム。
2. 前記作成部は、前記給湯器を含む前記需要家の制御対象モデルに基づいて前記最適化演算を実施する、請求項１に記載のエネルギー管理システム。
3. 前記制御対象モデルは、さらに、電力系統、前記燃料電池、補助ボイラ、逆潮流防止ヒータ、前記蓄電装置、貯湯槽の少なくともいずれか１つを含み、
   前記作成部は、前記制御対象モデルに係わる変量を含む目的関数を最適化する、請求項２に記載のエネルギー管理システム。
4. 前記目的関数は、電気料金、ガス料金および売電価格を変数として含む、請求項３に記載のエネルギー管理システム。
5. 前記作成部は、前記目的関数を遺伝的アルゴリズムにより最適化する、請求項３および４のいずれか１項に記載のエネルギー管理システム。
6. 前記作成部は、前記燃料電池の発電量の時間に対する変化を既定の範囲内に制限することも含む条件下で前記最適化演算を実施する、請求項１に記載のエネルギー管理システム。
7. 前記給湯器から供給される温水と浴槽内の温水との間で熱エネルギーを交換する熱交換器を前記需要家が備える場合に、
   前記作成部は、前記予測されたエネルギーデマンドとエネルギー供給量、および前記熱エネルギーに基づいて前記最適化演算を実施する、請求項１に記載のエネルギー管理システム。
8. 前記給湯器は、地中熱エネルギーを利用するヒートポンプ式給湯器であり、
   前記作成部は、前記予測されたエネルギーデマンドとエネルギー供給量、および前記地中熱エネルギーに基づいて前記最適化演算を実施する、請求項１に記載のエネルギー管理システム。
9. さらに、前記制御にユーザの意思を反映させるためのインタフェース部を備える、請求項１に記載のエネルギー管理システム。
10. 前記取得部、前記予測部、前記作成部、および前記制御部の少なくともいずれか１つは、クラウドコンピューティングシステムに配置される機能オブジェクトである、請求項１に記載のエネルギー管理システム。
11. 需要家のエネルギーを管理するエネルギー管理方法であって、
    再生可能エネルギーを熱源とする給湯器、燃料電池、蓄電装置およびエネルギー消費機器に係わるデータを前記需要家から取得し、
    電力デマンドおよび給湯デマンドを含む前記需要家におけるエネルギーデマンドと、前記給湯器の給湯量および前記燃料電池の発電量を含む前記需要家におけるエネルギー供給量とを、前記取得されたデータに基づいて予測し、
    前記予測されたエネルギーデマンドおよびエネルギー供給量に基づいて、前記蓄電装置の満充電に伴い破棄される余剰電力を制限する制約条件下で、前記需要家におけるエネルギーコストを最小化すべく最適化演算を実施し、
    前記最適化演算の結果に基づいて、前記燃料電池および前記蓄電装置の少なくともいずれかを制御する、エネルギー管理方法。
12. 前記給湯器を含む前記需要家の制御対象モデルに基づいて前記最適化演算を実施する、請求項１１に記載のエネルギー管理方法。
13. 前記制御対象モデルは、さらに、電力系統、前記燃料電池、補助ボイラ、逆潮流防止ヒータ、前記蓄電装置、貯湯槽の少なくともいずれか１つを含み、
    前記制御対象モデルに係わる変量を含む目的関数を最適化する、請求項１２に記載のエネルギー管理方法。
14. 前記目的関数は、電気料金、ガス料金および売電価格を変数として含む、請求項１３に記載のエネルギー管理方法。
15. 前記目的関数を遺伝的アルゴリズムにより最適化する、請求項１３および１４のいずれか１項に記載のエネルギー管理方法。
16. 前記燃料電池の発電量の時間に対する変化を既定の範囲内に制限することも含む条件下で前記最適化演算を実施する、請求項１１に記載のエネルギー管理方法。
17. 前記給湯器から供給される温水と浴槽内の温水との間で熱エネルギーを交換する熱交換器を前記需要家が備える場合に、前記予測されたエネルギーデマンドとエネルギー供給量、および前記熱エネルギーに基づいて前記最適化演算を実施する、請求項１１に記載のエネルギー管理方法。
18. 前記給湯器は、地中熱エネルギーを利用するヒートポンプ式給湯器であり、
    前記予測されたエネルギーデマンドとエネルギー供給量、および前記地中熱エネルギーに基づいて前記最適化演算を実施する、請求項１１に記載のエネルギー管理方法。
19. 請求項１１乃至１８のいずれか１項に記載の方法をコンピュータに実行させるための命令を含む、プログラム。
20. 需要家のクライアント装置と通信可能なサーバであって、
    再生可能エネルギーを熱源とする給湯器、燃料電池、蓄電装置およびエネルギー消費機器に係わるデータを前記需要家から取得する取得部と、
    電力デマンドおよび給湯デマンドを含む前記需要家におけるエネルギーデマンドと、前記給湯器の給湯量および前記燃料電池の発電量を含む前記需要家におけるエネルギー供給量とを、前記取得されたデータに基づいて予測する予測部と、
    前記予測されたエネルギーデマンドおよびエネルギー供給量に基づいて、前記蓄電装置の満充電に伴い破棄される余剰電力を制限する制約条件下で、前記需要家におけるエネルギーコストを最小化すべく最適化演算を実施する作成部と、
    前記最適化演算の結果に基づいて、前記燃料電池および前記蓄電装置の少なくともいずれかを制御するための制御情報を前記クライアント装置に送信する制御部とを具備する、サーバ。
21. 前記作成部は、前記給湯器を含む前記需要家の制御対象モデルに基づいて前記最適化演算を実施する、請求項２０に記載のサーバ。
22. 前記制御対象モデルは、さらに、電力系統、前記燃料電池、補助ボイラ、逆潮流防止ヒータ、前記蓄電装置、貯湯槽の少なくともいずれか１つを含み、
    前記作成部は、前記制御対象モデルに係わる変量を含む目的関数を最適化する、請求項２１に記載のサーバ。
23. 前記作成部は、前記目的関数を遺伝的アルゴリズムにより最適化する、請求項２２に記載のサーバ。
24. 前記作成部は、前記燃料電池の発電量の時間に対する変化を既定の範囲内に制限することも含む条件下で前記最適化演算を実施する、請求項２０に記載のサーバ。
25. 前記給湯器から供給される温水と浴槽内の温水との間で熱エネルギーを交換する熱交換器を前記需要家が備える場合に、
    前記作成部は、前記予測されたエネルギーデマンドとエネルギー供給量、および前記熱エネルギーに基づいて前記最適化演算を実施する、請求項２０に記載のサーバ。
26. 前記給湯器は、地中熱エネルギーを利用するヒートポンプ式給湯器であり、
    前記作成部は、前記予測されたエネルギーデマンドとエネルギー供給量、および前記地中熱エネルギーに基づいて前記最適化演算を実施する、請求項２０に記載のサーバ。

Images