WO2014034391A1

WO2014034391A1 - エネルギー管理システム、サーバ、エネルギー管理方法および記憶媒体

Info

Publication number: WO2014034391A1
Application number: PCT/JP2013/071266
Authority: WO
Inventors: 恭介片山; 谷本　智彦; 和人久保田; 卓久和田; 清高松江; 博司平
Original assignee: 株式会社東芝
Priority date: 2012-09-03
Filing date: 2013-08-06
Publication date: 2014-03-06
Also published as: EP2894747A1; US9824409B2; EP2894747A4; US20140142774A1

Abstract

　実施形態によれば、エネルギー管理システムは、クライアントと、クライアントと通信可能なサーバとを具備する。サーバは取得部、予測部、計算部、制御部を備える。取得部は、蓄電池を含む建物の電気機器に係わるデータをクライアントから取得する。予測部は、建物におけるエネルギーデマンドおよびエネルギー生産量を、データに基づいて予測する。計算部は、蓄電池の満充電に伴い破棄される余剰電力を最小化する条件下で、建物におけるエネルギー収支を最適化すべく、エネルギーデマンドおよびエネルギー生産量に基づいて電気機器の運転計画を計算する。制御部は、計算された運転計画に基づいて、電気機器を制御するための制御情報を作成する。

Description

エネルギー管理システム、サーバ、エネルギー管理方法および記憶媒体

　本発明の実施形態は、エネルギーを管理する技術に関する。

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

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

　電気自動車（Electric Vehicle）に関する技術開発も盛んである。この種の車両に搭載されるバッテリーは旧来のものに比べて著しく進歩しており、その性能を生かして、例えば停電時などにその電力を家庭に供給することが考えられている。

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

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

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

　一方、電気自動車の車載バッテリーとＨＥＭＳとを組み合わせた技術は未だ発展の途上にある。特に、家庭内の電気機器と車載バッテリーとを総合的に考慮したエネルギー管理の手法が要望されている。

　目的は、エネルギーの有効活用を図り得るエネルギー管理システム、サーバ、エネルギー管理方法および記憶媒体を提供することにある。

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

　図１は、実施形態に係わるシステムの一例を示す図である。図１は、いわゆるスマートグリッドとして知られるシステムの一例を示す。既存の電力網（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）などである。ホームゲートウェイ７は、ＩＰネットワーク２００を経由してサーバコンピュータＳＶと通信したり、データベースＤＢとデータを授受したりできる。なおＩＰネットワーク２００は、ホームゲートウェイ７とクラウド３００との間に双方向の通信環境を形成するための、無線または有線の通信インフラストラクチャを含んで良い。

　クラウド３００は、収集部３００ａ、予測部３００ｂ、計算部３００ｃ、および制御部３００ｄを備える。クラウド３００のデータベースＤＢは、制御対象モデル３００ｇ、および各種のデータ３００ｈを記憶する。収集部３００ａ、予測部３００ｂ、計算部３００ｃ、および制御部３００ｄは、単体のサーバコンピュータＳＶ、あるいは、クラウド３００に配置される機能オブジェクトである。これらの機能オブジェクトを如何にしてシステムにインプリメントするかは、当業者によれば容易に理解されるであろう。

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

　収集部３００ａは、ホーム１００の電気機器に係わる各種データを各ホーム１００のホームゲートウェイ７から定期的、あるいは不定期に取得する。また収集部３００ａは、端末１０５におけるユーザの操作履歴などを端末１０５から取得する。なお収集部３００ａと端末１０５とが通信回線４０を介して直接通信することも可能である。

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

　予測部３００ｂは、収集部３００ａにより取得されたデータ３００ｈに基づいて、各家電機器５の時間ごとのエネルギーデマンド、ホーム１００のトータルでの時間ごとのエネルギーデマンド、あるいはエネルギー生産量などを予測する。すなわち予測部３００は、ホーム１００の電力デマンド、給湯デマンド、ＰＶ発電量などを予測する。

　計算部３００ｃは、ホーム１００の蓄電池１０２およびＦＣユニット１０３を含む制御対象モデル３００ｇと、予測した電力デマンド、給湯デマンド、およびＰＶ発電量に基づいて、電気機器の運転計画を計算する。つまり計算部３００ｃは、電力デマンド、給湯デマンド、およびＰＶ発電量に基づいて蓄電池１０２の充放電スケジュール、およびＦＣユニット１０３の発電スケジュールを計算する。

　つまり計算部３００ｃは、予測されたエネルギーデマンドに基づいてホーム１００におけるエネルギー収支を最適化可能な、電気機器の動作に係わる運転計画を計算する。この処理を最適スケジューリングと称する。

　エネルギー収支とは例えば光熱費収支であり、家電機器５により消費される電力のコストと、主にＰＶシステム１０１により生成される電力の売電料金とのバランスにより評価される量である。計算された電気機器の時系列の運転計画はデータベースＤＢに記憶される。　
　さらに計算部３００ｃは、既定の制約条件に従って運転計画を算出する。この第１の実施形態では、計算部３００ｃは、蓄電池１０２の満充電に伴い破棄される余剰電力を最小化する、という条件に基づいて運転計画を算出する。

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

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

　また、需要家は、クラウド３００にスケジュールの再計算を要求したり、そのために必要になる情報をシステムに与えたりするための指示（コマンド）を、ユーザインタフェース１０５ａを介して入力することができる。以上の構成において、サーバコンピュータＳＶは主装置としての位置付けにあり、ホームゲートウェイ７は主装置からの制御信号を受信する従装置としての位置付けにあると理解することが可能である。

　図３は、第１の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。図３において、ホーム１００の家電機器５の所定時間ごとの電力消費量、稼動状態、蓄電池１０２の充電残量や充放電電力量、ホーム１００の電力デマンド、給湯デマンド、ＰＶ発電量などのデータが、ホームゲートウェイ７を介して定期的、あるいは不定期にクラウド３００に送信される。

　ＥＣＨＯＮＥＴ（登録商標）やＥＣＨＯＮＥＴＬｉｔｅ（登録商標）などが、ホーム１００における宅内通信プロトコルとして知られている。ホームゲートウェイ７は、例えばこの種の通信機能を実装する電気機器から、ホームネットワーク２５を介して各種データを収集する。収集された各種データはクラウド３００に送信される。

　分電盤２０に通信機能を備える計測装置を設置することにより、ホームゲートウェイ７は、電気機器の消費電力や稼働状態を収集することが可能である。ＰＶシステム１０１、蓄電池１０２、ＦＣユニット１０３などの直流機器については、ＰＣＳ１０４を介してデータを収集することも可能である。

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

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

　そして、需要家ごとに設けられる計算部３００ｃは、予測計算により算出された所定時間ごとのエネルギーデマンド、エネルギー供給量、エネルギー単価、および制御対象モデル３００ｇなどに基づいて、電気機器の動作制御に係わる最適スケジューリングを実行する。

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

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

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

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

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

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

　貯湯槽２２３の貯湯量Ｈ（ｔ）は、式（４）に示されるように、ＦＣ本体２２０の排熱Ｑ_FC（ｔ）、逆潮流防止ヒータ２２２の発熱量Ｑ_H（ｔ）、および給湯Ｑ_ST（ｔ）により増減する。　
　式（４）の左辺は貯湯槽２２３に入る熱量を湯量ベースで表すもので、左辺第１項はｒ・Ｈ（ｔ－１）＝残存率×前回貯湯量＝放熱後に残る湯量である。ここで貯湯効率（残存率）ｒは、時間ｔ－１からｔの間で、放熱による減少後に残る熱の割合を示す係数である。左辺第２項はＦＣ排熱の回収量であり、第３項は逆潮流防止ヒータの発熱量であり、いずれも湯量換算値である。

　式（５）は貯湯槽２２３の容量制約を示す。蓄電池１０２は、充放電電力Ｐ_SB（ｔ）により充電残量Ｓ（ｔ）が増減するモデルとしてモデル化されることが可能である。

　式（６）は、電力の需給バランスを示す。Ｐ_D（ｔ）はホーム１００の電力デマンドを示し、Ｐ_C（ｔ）は購入電力または売電電力を示し、Ｐ_PV（ｔ）はＰＶ１０１の発電量を示す。式（７）、（８）はＦＣ本体２２０と蓄電池１０２からの逆潮流を禁止するという制約条件を示す。式（９）は蓄電池１０２の容量の制約条件を示す。

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

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

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

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

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

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

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

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

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

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

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

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

　図７は、第１の実施形態に係る最適化演算の流れの一例を示すフローチャートである。最適化アルゴリズムの一例として遺伝的アルゴリズムを採りあげる。以下、遺伝的アルゴリズムに基づく処理手順につき説明する。　
　（ステップＳ２－１）　初期個体群の生成
　このステップにおいて、計算部３００ｃは、ｎ個の初期個体を発生させる。個体の遺伝子は、例えば時刻ｔでのＦＣユニット１０３の運転・停止、ＦＣユニット１０３の発電量、蓄電池１０２の充放電電力などである。遺伝子列として例えば１日分（２４時間分）を設けることができる。それぞれの個体は、ＦＣユニット１０３、蓄電池１０２の各遺伝子列の集合である。制約条件を満足しない固体は遺伝子をビット反転させて、制約条件を満足させるように改変する。

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

（ステップＳ２－３）　淘汰
　このステップにおいて、計算部３００ｃは、制約条件を満足しない個体を排除する。よって、制約条件を満足しない個体は淘汰される。既定数以上の個体が存在する場合には適応度の悪い（適応度の小さい）個体を排除して、個体の数を既定数以下に保つようにする。

（ステップＳ２－４）　増殖
　このステップにおいて、個体数が予め定義した個体数より少ない場合には、計算部３００ｃは、適応度が最良の個体を増殖させる。

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

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

　（ステップＳ２－３）～（ステップＳ２－６）の手順は、世代数＜最大世代数の条件が満たされるまで、世代数をインクリメントしつつ繰り返される（ステップＳ２－２のループ）。この条件が満たされれば、計算部３００ｃは結果を出力し（ステップＳ２－７）、計算手順を終了する。

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

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

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

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

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

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

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

　以上から第１の実施形態によれば、商用電力系統に逆潮流できない余剰電力を無駄に消費することなく、有効に利用することが可能になる。これらのことから、余剰電力が無駄に消費されることを防止可能なエネルギー管理システム、サーバ、エネルギー管理方法および記憶媒体を提供することが可能になる。　
　［第２の実施形態］
　図９は、第２の実施形態に係るエネルギー管理システムの一例を示す図である。図９において図２と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。ホーム１００の配電線２１には、電気自動車（以下、車両と表記する）ＥＶが接続される。　
　ホーム１００において生じた余剰電力は蓄電池１０２や車両ＥＶの車載バッテリー１０６に充電されることが可能であるが、限度を超えて充電することはできない。第２の実施形態ではこのような事態を回避可能な技術について説明する。

　ホーム１００に据え置かれる蓄電池１０２の蓄電容量は、普通、固定的である。車載バッテリー１０６も同様であり、これらは単体で見れば容量固定型の蓄電池として捉えられる。しかしこれらの蓄電池は総体的に、容量の変化する蓄電池（蓄電池システム）として理解されることができる。この蓄電池システムの容量は、車両ＥＶがホーム１００の配電線２１に接続されているか否かに応じて増減するし、車両ＥＶの数や車載バッテリー１０６の性能によっても変化する。第２の実施形態ではこのように、蓄電池システムの容量が変化することを想定する。

　ＰＣＳ１０４は、車両ＥＶに接続可能なコネクタ１０８に、配電線２１を介して接続される。ＰＣＳ１０４は配電線２１からの交流電力を直流電力に変換して車両ＥＶに供給する。ＰＣＳ１０４は車載バッテリー１０６から供給される直流電力を交流電力に変換して配電線２１に供給する。これにより、配電線２１を介して車載バッテリー１０６を充放電することが可能になる。

　データ３００ｈは、各ホーム１００の電力デマンド、各家電機器５の電力消費量、ＦＣユニット１０３の給湯量や稼動状態、蓄電池１０２および車載バッテリー１０６の充電残量や充放電電力、ＰＶシステム１０１の発電量などを含む。

　計算部３００ｃは、ホーム１００の蓄電池１０２、車載バッテリー１０６およびＦＣユニット１０３を含む制御対象モデル３００ｇと、予測した電力デマンド、給湯デマンド、およびＰＶ発電量に基づいて、蓄電池１０２、車載バッテリー１０６の充放電スケジュール、およびＦＣユニット１０３の発電スケジュールを計算する。

　制御部３００ｄは、計算部３００ｃによる最適スケジューリングの結果に基づいて、蓄電池１０２および車載バッテリー１０６の充放電、稼動、およびＦＣユニット１０３の発電のための運転・停止指示、出力目標値などを作成する。

　図１０は、第２の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。図１０において図３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。

　図１０において、車載バッテリー１０６の充電残量や充放電電力量などのデータが、ホームゲートウェイ７を介して定期的、あるいは不定期にクラウド３００に送信される。ＰＶシステム１０１、車載バッテリー１０６、蓄電池１０２、ＦＣユニット１０３などの直流機器については、ＰＣＳ１０４を介してデータを収集することも可能である。

　図１１は、第２の実施形態に係る制御対象モデル３００ｇの一例について説明するための図である。図１１において図４と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。　
　制御対象モデル３００ｇは、電力系統６、ＦＣユニット１０３、蓄電池１０２、車載バッテリー１０６、ＰＶシステム１０１、および家電機器５（負荷）の各構成要素を含む。ＦＣユニット１０３は、ＦＣ本体２２０、補助ボイラ２２１、逆潮流防止ヒータ２２２、および貯湯槽２２３の各構成要素を含む。図１１における変量は表２に示される。

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

　蓄電池システム（蓄電池１０２、車載バッテリー１０６）は、充放電電力Ｐ_SB（ｔ）により充電残量Ｓ（ｔ）の増減するモデルとしてモデル化することが可能である。第２の実施形態では特に、表２に示されるように、蓄電池１０２と車載バッテリー１０６とが個別にモデル化される。　
　式（２２）は蓄電池システムの容量（蓄電池１０２の容量と車載バッテリー１０６の容量との和）に対する制約条件を示す。

　制御部３００ｄは、最適スケジューリングの結果に基づいて、蓄電池１０２、車載バッテリー１０６の充放電スケジュール、および、またはＦＣユニット１０３の発電のための運転・停止指示、出力目標値を、既定の時間間隔（例えば１時間）ごとにホーム１００のホームゲートウェイ７に送信する。

　ユーザインタフェース１０５ａは、クラウド３００から受信した各スケジュールや各種情報を、確認メッセージとともに表示してユーザに通知する。確認メッセージに対して許可／不許可を選択することで、ユーザは、計算されたスケジュールを実行するか否かを選択できる。またユーザインタフェース１０５ａを用いて、ユーザは、スケジュールの修正をクラウド３００に要求することも可能である。

　さらに、ユーザインタフェース１０５ａを用いて、車両ＥＶの使用予定時間帯、出発時の最低充電残量、走行予定距離などの情報を設定することが可能である。車両ＥＶの動作に関する条件は式（２２）に関係し、例えば式（２２）′のように表される。

　式（２２）′は、蓄電池システムの充電残量Ｓ（ｔ）が蓄電池１０２の充電残量Ｓ_BAT（ｔ）と車載バッテリー１０６の充電残量Ｓ_EV（ｔ）との和として表現されることを示す。さらに、Ｓ_BAT（ｔ）および充電残量Ｓ_EV（ｔ）にそれぞれ容量制約が課せられる。つまりＳ_BAT（ｔ）には最低値Ｓ_{BAT_min}以上、最大値Ｓ_{BAT_max}以下であるとの条件が課せられる。Ｓ_EV（ｔ）には最低値Ｓ_{EV_min}以上、最大値Ｓ_{EV_max}以下であるとの条件が課せられる。　

　ただし車両ＥＶの使用開始時刻において、Ｓ_EVは、設定した最低充電残量以上でなくてはならない。車両ＥＶの使用終了時刻においては、Ｓ_EVは、走行予定距離に見合った量だけ低下した値とする。

　計算部３００ｃ（図９、図１０）は、以上のような条件のもとで、電力・給湯デマンド、ＰＶ発電量、電気・ガスの料金単価、および電力買い取り価格が与えられたとき、光熱費収支（エネルギーコスト）が最小になるＦＣユニット１０３の発電量Ｐ_FC（ｔ）のスケジュール、および蓄電池システム（蓄電池１０２および車載バッテリー１０６を含む）の充放電量Ｐ_SB（ｔ）のスケジュールを算出する。最適化アルゴリズムには例えば遺伝的アルゴリズムを用いることができる。

　各スケジュールが算出されると、図５に示される処理手順と同様の処理手順が実行される。ここでも、ユーザに各スケジュールが示され、その承認（許可）が得られたのちにＦＣユニット１０３、および蓄電池システムの制御が実行される。

　図１２は、第２の実施形態に係る遺伝的アルゴリズムの遺伝子設計の一例を示す概念図である。図１２において図６と同じ部分には同じ符号を付して示す。第２の実施形態では遺伝子に、ＦＣ本体２２０ユニット１０３の発電量Ｐ_FC（ｔ）と、蓄電池１０２の充放電電力Ｐ_SB（ｔ）と、車載バッテリー１０６の充放電電力Ｐ_EV（ｔ）とが組み込まれる。蓄電池１０２、車載バッテリー１０６およびＦＣユニット１０３の、１日分の運転計画が、個体である。複数の個体により世代が形成される。

　式（２３）は、最大化すべき適合度Ｆｉｔを示す。このＦｉｔを目的関数として最適化することで、第１の実施形態と同様に運転計画を算出することができる。光熱費収支Ｃは式（２４）に示され、機器稼動の不連続性に掛かるコストｇ（Ｐ_FC，Ｐ_SB）は式（２５）に示される。光熱費収支Ｃにおけるｔ＝０～ｔ＝２３までの総和は、２４時間にわたる和を求めることに対応する。　

　式（２３）におけるＦｉｔは、第１の実施形態と同様の理由により、単調増加関数であるｆ（Ｃ）＞０とコストｇ（Ｐ_FC，Ｐ_SB）＞０との和の逆数として表される。式（２３）～（２５）の各式に電力デマンド、給湯デマンド、ＰＶ発電量、電気料金単価、ガス料金単価、およびＰＶ買取価格を与え、遺伝的アルゴリズムを用いた最適化処理により最大のＦｉｔが算出される。このような操作により、ＦＣユニット１０３の発電量Ｐ_FC（ｔ）と、蓄電池システムの充放電Ｐ_SB（ｔ）すなわちＰ_BAT（ｔ）およびＰ_EV（ｔ）の、光熱費収支Ｃを最小とする系列が求められる。

　以上述べたように第２の実施形態でも、ＰＶ発電量、電力デマンド、および給湯デマンドの各予測値に基づいて、予め設定された制約条件下で評価関数を最小化する最適化計算、が実行される。特に第２の実施形態では、蓄電池１０２と車載バッテリー１０６とを含む蓄電池システムが、最適化計算の対象とされる。これによりホーム１００におけるエネルギーコスト（光熱費）を最小化可能な、ＦＣユニット１０３の運転計画、蓄電池１０２の充放電スケジュール、および車載バッテリー１０６の充放電スケジュールが算出される。従って、逆潮流防止ヒータ２２２を無駄に稼動させず、光熱費を安くすることが可能になる。

　蓄電池１０２および車載バッテリー１０６が満充電になると余剰電力は熱などに変換されて破棄されるので、エネルギーやコスト（ガス料金など）に無駄を生じる。第２の実施形態によればこのような事態を回避しうる。

　第２の実施形態においても図５と同様の処理手順が実行される。ステップＳ１－２の予測手順と、ステップＳ１－３の最適スケジューリングとを組み合せることで、一日分程度のまとまった期間の電力デマンド予測、給湯デマンド予測、ＰＶ発電予測に応じて、ＦＣの発電スケジュールや蓄電池１０２の充放電スケジュール、および車載バッテリー１０６の充放電スケジュールといったエネルギー需給計画を、全体のバランスを考慮したうえで作成できるようになる。

　従って、蓄電池１０２および車載バッテリー１０６の双方が満充電であるためにＦＣユニット１０３の余剰電力を充電できないケースや、蓄電池１０２および車載バッテリー１０６の充電残量が足りないために電力を自給したいときに放電できないといったケースを回避することが可能になる。

　これらのことから第２の実施形態によれば、第１の実施形態で得られたのと同様の効果に加えて、車載バッテリーを有効に活用することが可能になる。よって、商用電力系統に逆潮流できない余剰電力を無駄に消費することなく、有効に利用することが可能になる。以上から第２の実施形態によっても、エネルギーが無駄に消費されることを防止可能なエネルギー管理システム、サーバ、エネルギー管理方法および記憶媒体を提供することが可能になる。

　［第３の実施形態］
　図１３は、第３の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。図１３において図１０と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。

　第３の実施形態では、複数の車両ＥＶがホーム１００の配電線２１に接続されることが想定される。図１３には、２台の車両ＥＶの車載バッテリー（符号を１０６ａ、１０６ｂとする）が示される。ＥＶ１とＥＶ２は、２台の車両ＥＶを区別して示すための参照符号である。計算部３００ｃは、各車載バッテリー１０６ａ、１０６ｂの動作スケジュールを、蓄電池１０２やその他の電気機器をも含む総合的な与条件、のもとで算出する。

　図１４は、第３の実施形態に係る制御対象モデル３００ｇについて説明するための図である。第３の実施形態では、制御対象モデル３００ｇに、車載バッテリー１０６ａの充電残量Ｓ_EV1（ｔ）と、車載バッテリー１０６ｂの充電残量Ｓ_EV2（ｔ）とが組み込まれる。

　図１５は、第３の実施形態に係る遺伝子設計の一例を示す概念図である。第３の実施形態では、第２の実施形態に比べて車載バッテリーの数の増えたことに伴って、個体を特徴付ける要素の数が増える。よって遺伝子の多様性も増す。従って第３の実施形態によれば、蓄電池システムの容量が増えることにより停電時の給電時間を長くできるだけでなく、通常時に２台の車両ＥＶ間で電力を融通することが可能となる。従って第３の実施形態によれば、第２の実施形態で得られる効果に加えて、システム運用の柔軟性を向上させることが可能になるというメリットを得られる。

　［第４の実施形態］
　図１６は、第４の実施形態に係るＨＥＭＳの要部を示す機能ブロック図である。図１６において図１３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。第４の実施形態では、ＦＣユニット１０３に代えて、原動機を用いたガスエンジン発電機（以下、ＧＥと表記する）１０７が、エネルギー生産機器として用いられる。

　図１７は、第４の実施形態に係る制御対象モデル３００ｇについて説明するための図である。図１１と比較して、ＦＣ本体２２０が発電機本体２２４に置き換えられ、ＦＣユニット１０３がＧＥユニット１０７に置き換えられる。

　ガスエンジン発電機は、燃料電池に比べて応答性が良いという特徴を備える。つまり発電指令を与えられてから電力を得られるまでの時間が短い。この特徴を活かせば、例えば、車両ＥＶでの急な外出時に車載バッテリー１０６の電力が不足していても、その時点からの最適スケジュールに大きな影響を与えることなく、不足分の電力を補うことができる。これはガスエンジン発電機を用いることに特有の利点といえる。つまり第４の実施形態によれば、第１～第３の実施形態により得られる効果はもとより、不測の事態にも柔軟に対処可能なシステムを構築することが可能になる。

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

　また、第１の実施形態～第４の実施形態に係わるエネルギー管理方法を実行するためのプログラムは、メモリカードや光学ディスク（ＣＤ－ＲやＤＶＤ－Ｒなどを含む）などの記憶媒体によりサーバコンピュータＳＶに供給されてもよい。この種の記憶媒体は、コンピュータにより実行されるプログラムを格納する、コンピュータ読み取り可能な記憶媒体である。また、プログラムは、インターネットや無線通信などの通信回線を介してサーバコンピュータＳＶに供給されてもよい。

　また、電気機器の運転計画は図８に示されるグラフに限らず、種々のパターンのグラフが算出され得る。図１８および図１９は、電気機器の運転パターンの他の例を示すグラフである。これらの図は、車両ＥＶの存在と、車載バッテリーを利用可能であることとを考慮して計算されたグラフの例を示す。つまり車載バッテリーの充放電量や、車載バッテリーの容量を考慮した購入電力量などが計算される。

　図１８は、車両ＥＶが一日中在宅していたことを想定して作成されたグラフである。つまりこのグラフは、車載バッテリーが一日中配電線２１に接続されていたこと、を想定して作成された。　
　蓄電池充電電力のグラフ、および車両ＥＶの充放電量のグラフによれば、午前中の（７：００～１１：００）の時間帯は蓄電池１０２から給電され、夕方から夜間（１７：００～２２：００）にかけては車載バッテリー１０６から給電されていることが分かる。また、蓄電池１０２および車載バッテリー１０６が深夜から明け方の時間帯（２２：００～５：００）に充電されることが分かる。

　図１９は、日中に車両ＥＶが外出したことを想定して作成されたグラフである。つまりこのグラフは、車載バッテリーが配電線２１から離脱したことを想定して作成された。車両ＥＶが外出し車載バッテリー１０６を使えない時間帯（８：００～１９：００）には、家電機器５は蓄電池１０２の電力に頼って運転せざるを得ない。しかし、車両ＥＶが帰宅して車載バッテリーが配電線２１に再接続されると、直ちに運転計画が再計算される。また図１９のグラフによれば、車載バッテリー１０６が夜間（２２：００～６：００）に充電されていることが分かる。

　そして図１８、図１９のいずれのグラフにおいても、逆潮流防止ヒータ２２２の消費電力は０のまま推移している。従って、電力が無駄に消費されていないことが分かる。

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

Claims

　クライアントと、前記クライアントと通信可能なサーバとを具備するエネルギー管理システムにおいて、
　　前記サーバは、
　蓄電池を含む建物の電気機器に係わるデータを前記クライアントから取得する取得部と、
　前記建物におけるエネルギーデマンドおよびエネルギー生産量を、前記データに基づいて予測する予測部と、
　前記蓄電池の満充電に伴い破棄される余剰電力を最小化する条件下で、前記建物におけるエネルギー収支を最適化すべく、前記エネルギーデマンドおよびエネルギー生産量に基づいて前記電気機器の運転計画を計算する計算部と、
　前記計算された運転計画に基づいて、前記電気機器を制御するための制御情報を作成する制御部とを備えることを特徴とする、エネルギー管理システム。
　前記蓄電池は、前記建物に据え置かれる据置型蓄電池と、前記据置型蓄電池に電気的に接続可能な車載バッテリーとを含むことを特徴とする、請求項１に記載のエネルギー管理システム。
　さらに、前記電気機器の制御対象モデルを保持するデータベースを具備し、
　前記計算部は、前記制御対象モデルに基づいて前記運転計画を計算することを特徴とする、請求項１に記載のエネルギー管理システム。
　前記電気機器は燃料電池を含み、
　前記燃料電池は、本体、補助ボイラ、逆潮流防止ヒータ、および貯湯槽を含み、
　前記制御対象モデルは、系統、前記蓄電池、前記本体、前記補助ボイラ、前記逆潮流防止ヒータおよび前記貯湯槽を含み、
　前記計算部は、前記系統、前記蓄電池、前記本体、前記補助ボイラ、前記逆潮流防止ヒータおよび前記貯湯槽に係わる変量を含む目的関数を最適化して、前記運転計画を計算することを特徴とする、請求項３に記載のエネルギー管理システム。
　前記目的関数は、電気料金単価、ガス料金単価、および売電価格を変数として含むことを特徴とする、請求項４に記載のエネルギー管理システム。
　前記計算部は、前記目的関数を遺伝的アルゴリズムにより最適化することを特徴とする、請求項４に記載のエネルギー管理システム。
　前記電気機器は燃料電池を含み、
　前記計算部は、前記燃料電池の発電量の時間に対する変化を既定の範囲内に制限することも含む条件下で前記運転計画を計算することを特徴とする、請求項１に記載のエネルギー管理システム。
　前記電気機器は原動機を用いた発電機を含むことを特徴とする、請求項１に記載のエネルギー管理システム。
　前記クライアントは、前記制御部から送信された制御情報に前記電力の需要家の意思を反映させるためのインタフェース部を備えることを特徴とする、請求項１に記載のエネルギー管理システム。
　前記取得部、前記予測部、前記計算部、および前記制御部の少なくともいずれか１つは、クラウドコンピューティングシステムに配置される機能オブジェクトであることを特徴とする、請求項１に記載のエネルギー管理システム。
　蓄電池を含む電気機器を備える建物におけるエネルギーを管理するサーバであって、
　前記電気機器に係わるデータを取得する取得部と、
　前記建物におけるエネルギーデマンドおよびエネルギー生産量を、前記データに基づいて予測する予測部と、
　前記蓄電池の満充電に伴い破棄される余剰電力を最小化する条件下で、前記建物におけるエネルギー収支を最適化すべく、前記エネルギーデマンドおよびエネルギー生産量に基づいて前記電気機器の運転計画を計算する計算部と、
　前記計算された運転計画に基づいて、前記電気機器を制御するための制御情報を作成する制御部とを具備することを特徴とする、サーバ。
　前記蓄電池は、前記建物に据え置かれる据置型蓄電池と、前記据置型蓄電池に電気的に接続可能な車載バッテリーとを含むことを特徴とする、請求項１１に記載のサーバ。
　さらに、前記電気機器の制御対象モデルを保持するデータベースを具備し、
　前記計算部は、前記制御対象モデルに基づいて前記運転計画を計算することを特徴とする、請求項１１に記載のサーバ。
　前記電気機器は燃料電池を含み、
　前記燃料電池は、本体、補助ボイラ、逆潮流防止ヒータ、および貯湯槽を含み、
　前記制御対象モデルは、系統、前記蓄電池、前記本体、前記補助ボイラ、前記逆潮流防止ヒータおよび前記貯湯槽を含み、
　前記計算部は、前記系統、前記蓄電池、前記本体、前記補助ボイラ、前記逆潮流防止ヒータおよび前記貯湯槽に係わる変量を含む目的関数を最適化して、前記運転計画を計算することを特徴とする、請求項１３に記載のサーバ。
　前記目的関数は、電気料金単価、ガス料金単価、および売電価格を変数として含むことを特徴とする、請求項１４に記載のサーバ。
　前記計算部は、前記目的関数を遺伝的アルゴリズムにより最適化することを特徴とする、請求項１４に記載のサーバ。
　前記電気機器は燃料電池を含み、
　前記計算部は、前記燃料電池の発電量の時間に対する変化を既定の範囲内に制限することも含む条件下で前記運転計画を計算することを特徴とする、請求項１１に記載のサーバ。
　クライアントと、前記クライアントと通信可能なサーバとを具備するエネルギー管理システムに適用可能なエネルギー管理方法であって、
　　前記サーバは、
　蓄電池を含む建物の電気機器に係わるデータを前記クライアントから取得し、
　前記建物におけるエネルギーデマンドおよびエネルギー生産量を、前記データに基づいて予測し、
　前記蓄電池の満充電に伴い破棄される余剰電力を最小化する条件下で、前記建物におけるエネルギー収支を最適化すべく、前記エネルギーデマンドおよびエネルギー生産量に基づいて前記電気機器の運転計画を計算し、
　前記計算された運転計画に基づいて、前記電気機器を制御するための制御情報を作成することを特徴とする、エネルギー管理方法。
　前記蓄電池は、前記建物に据え置かれる据置型蓄電池と、前記据置型蓄電池に電気的に接続可能な車載バッテリーとを含むことを特徴とする、請求項１８に記載のエネルギー管理方法。
　前記計算することは、前記電気機器の制御対象モデルに基づいて前記運転計画を計算することを特徴とする、請求項１８に記載のエネルギー管理方法。
　前記電気機器は燃料電池を含み、
　前記燃料電池は、本体、補助ボイラ、逆潮流防止ヒータ、および貯湯槽を含み、
　前記制御対象モデルは、系統、前記蓄電池、前記本体、前記補助ボイラ、前記逆潮流防止ヒータおよび前記貯湯槽を含み、
　前記計算することは、前記系統、前記蓄電池、前記本体、前記補助ボイラ、前記逆潮流防止ヒータおよび前記貯湯槽に係わる変量を含む目的関数を最適化して、前記運転計画を計算することを特徴とする、請求項２０に記載のエネルギー管理方法。
　前記目的関数は、電気料金単価、ガス料金単価、および売電価格を変数として含むことを特徴とする、請求項２１に記載のエネルギー管理方法。
　前記計算することは、前記目的関数を遺伝的アルゴリズムにより最適化することを特徴とする、請求項２１に記載のエネルギー管理方法。
　前記電気機器は燃料電池を含み、
　前記計算することは、前記燃料電池の発電量の時間に対する変化を既定の範囲内に制限することも含む条件下で前記運転計画を計算することを特徴とする、請求項１８に記載のエネルギー管理方法。
　コンピュータにより実行されるプログラムを格納するコンピュータ読み取り可能な記憶媒体であって、前記プログラムは、請求項１８乃至２４のいずれか１項に記載のエネルギー管理方法をコンピュータに実行させるための命令を含むことを特徴とする、記憶媒体。