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

Description

本発明の実施形態は、加入者宅などの需要者側におけるエネルギー消費を管理するエネルギー管理システム、エネルギー管理方法、プログラムおよびサーバ装置に関する。

省エネルギー（省エネ）に向けた取り組みは、近年の社会背景からますます重要になってきている。ビルや工場などの大規模な設備あるいは個別家庭においても、電力を消費するだけの電気機器でなく太陽光発電（Photovoltaic Power Generation：ＰＶ）システムや、蓄電池、燃料電池などといった生産型の電気機器を導入しようとするニーズがある。

電気機器を計画的に稼動させることで省エネルギー化を図ることができる。しかし、ユーザが複数の電気機器の稼動スケジュールを管理するのは大変な労力と手間がかかる。そこで近年、エネルギー需給を統合的に管理するためのエネルギー管理システム（ＥＭＳ： Energy Management System）を導入することが検討されている。例えば、家庭向けの管理システムはＨＥＭＳ（Home Energy Management System）と称して知られている。

ところで、太陽光発電装置と蓄電装置とを含むエネルギー管理システムにあっては、発電量と電力需要量とをそれぞれ予測し、予測発電量と予測需要量とに基づいて、電気機器の稼動スケジュールを計算し、決定することが提案されている。また、制約条件下で評価関数を最小化する最適化計算を行い、その結果に従って各電気機器の使用スケジュールを最適化することも提案されている。

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

電気機器のエネルギー算出には多くの要素が複雑に絡み合うので、一般に計算負荷が高く、計算能力の高い機器が必要とされる。このような機器を電力需要者が個々に用意しなければならないとなれば、電力需要者の負担となる。
目的は、かかる課題を解決し得るエネルギー管理システム、エネルギー管理方法、プログラムおよびサーバ装置を提供することにある。

実施形態によれば、エネルギー管理システムは、複数のクライアント装置と、前記複数のクライアント装置と通信可能なサーバ装置とを具備する。サーバ装置は取得部、予測部、計算部、制御部を備える。取得部は配電網から電力を供給される電気機器に係わるデータを前記クライアント装置から取得する。予測部は前記データに基づいて電気機器のエネルギー需要量を予測する。計算部は予測されたエネルギー需要量に基づいて、前記電機機器に係わるエネルギーを最適化すべく前記電気機器の動作を計算する。制御部は計算された動作に基づいて前記電気機器を制御するための制御情報を前記クライアント装置に送信する。

実施形態に係わるシステムの一例を示す図である。 実施形態に係るエネルギー管理システムの一例を示す図である。 第１の実施形態に係るクラウドコンピューティングシステム３００およびＨＥＭＳの要部を示す機能ブロック図である。 制御対象モデルについて説明するための図である 第１の実施形態における処理手順を示すフローチャートである。 実施形態に係る最適化演算の流れの一例を示すフローチャートである。 一日のなかでの計算負荷の推移を示す模式図である。 第２の実施形態に係わるエネルギー管理システムの作用を説明するための図である。 第３の実施形態に係るクラウドコンピューティングシステム３００およびＨＥＭＳの要部を示す機能ブロック図である。 第５の実施形態に係わるエネルギー管理システムの作用を説明するための図である。 第５の実施形態における作用を説明するための図である。 第５の実施形態における作用を説明するための図である。 第６の実施形態に係るクラウドコンピューティングシステム３００およびＨＥＭＳの要部を示す機能ブロック図である。 第６の実施形態に係わるエネルギー管理システムの作用を説明するための図である。 第６の実施形態において端末１０５に表示される内容の一例を示す図である。 第７の実施形態に係るエネルギー管理システムの特徴を示す機能ブロック図である。 第７の実施形態における作用を説明するための図である。 第７の実施形態における作用を説明するための図である。

図１は、実施形態に係わるシステムの一例を示す図である。図１は、いわゆるスマートグリッドとして知られる電力送配電網の一例を示す。既存の配電ネットワークでは原子力、火力、水力などの既存発電所と、一般家庭や、ビル、工場といった多種多様な需要者とが電力網によって接続される。次世代の配電ネットワークではこれらに加えて新たな電源として太陽光や風力などの再生可能エネルギーと蓄電装置とを組み合わせた分散型電源や、新たな需要として新交通システムや充電スタンドなどが電力送配電網に接続される。これら多種多様な要素は通信ネットワークを介して接続され統括的に制御される。

電力をインテリジェントに分配するシステムは、エネルギーマネジメントシステム（Energy Management System：ＥＭＳ）と総称される。ＥＭＳはその規模などに応じて幾つかに分類される。例えば一般家庭向けのＨＥＭＳ（Home Energy Management System）、ビルディング向けのＢＥＭＳ（Building 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（ｔ）に対してＰ_FC（ｔ）発電し、Ｑ_FC（ｔ）排熱する場合、Ｐ_FC（ｔ）＝ｆ（Ｇ_FC（ｔ））、Ｑ_FC（ｔ）＝ｇ（Ｇ_FC（ｔ））とする。蓄電池１０２の入出力モデルは、充電残量Ｓ（ｔ）の蓄電池は電力Ｐ_ＳＢ（ｔ）で充放電を行うものとし、次式（１）に示される。

電力の需給バランスモデルは例えば式（２）のように表すことができる。ここでＰ_D（ｔ）は電気機器５の消費電力量すなわち電力需要を示す。Ｐ_C（ｔ）は電力系統６からの購入電力もしくは売電電力、Ｐ_PV（ｔ）はＰＶシステム１０１の発電量をを示す。熱の需給バランスモデルは例えば式（３）、（４）のように表すことができる。Ｑ_D（ｔ）は給湯需要、Ｈ（ｔ）は貯湯量を示す。貯湯槽からの給湯Ｑ_ST（ｔ）で賄いきれない給湯需要ＱＢ（ｔ）は補助ボイラから供給されるとする。ガス供給量Ｇ（ｔ）はＧ_FC（ｔ）に補助ボイラへの供給Ｇ_B（ｔ）を加算したものである。

制約条件として、燃料電池１０３と蓄電池１０２からの逆潮流の禁止は例えば式（５）に示される。また蓄電池１０２の容量や燃料電池１０３の貯湯容量の制約を例えば式（６）、（７）のように表すことができる。

図３において、計算部３００ｃは電力・給湯需要量とＰＶ発電量、電気・ガスの料金単価および電力買い取り価格が与えられたとき、光熱費収支（エネルギーコスト）が最小となるように燃料電池１０３の発電Ｐ_FC（ｔ）と蓄電池１０２の充放電Ｐ_SB（ｔ）のスケジュールを求める。最適化アルゴリズムには例えば遺伝的アルゴリズムを用いることができる。

遺伝的アルゴリズムの中で最大化する適合度Ｆｉｔは、例えば式（８）、（９）に示されるように、１日あたりの光熱費収支Ｃのｆ（Ｃ）＞０なる単調増加関数に機器稼動の不連続性にかかるコストを加算したものの逆数が考えられる。ｆ（Ｃ）＞０なる単調増加関数を用いた理由は、家庭の電力需要量を発電量が大きく上回る場合に光熱費収支Ｃが負となる可能性があるからである。

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

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

図５において、予測部３００ｂは所定時間ごとの電力需要量、給湯需要量、ＰＶ発電量をデータベースＤＢから取得する（ステップＳ１−１）。このステップでは過去のデータを取得しても良い。次に予測部３００ｂは、稼動スケジュール算出のため所定時間ごとの電力需要量、給湯需要量、ＰＶ発電量を予測する（ステップＳ１−２）。

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

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

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

図６は、実施形態に係る最適化演算の流れの一例を示すフローチャートである。先に述べたように、計算部３００ｃは遺伝的アルゴリズムにより最適化演算を実施する。
（ステップＳ２−１） 初期個体群の生成
ランダムまたは過去の実績値に基いてｎ個の初期個体を発生させる。時刻ｔの燃料電池１０３の運転・停止、燃料電池１０３の発電量、蓄電池１０２の充放電電力をそれぞれ遺伝子とし、１日２４時間分を遺伝子列とする。さらに燃料電池１０３、蓄電池１０２の各遺伝子列の集合１つの固体とする。

（ステップＳ２−２） 適合度評価
制約条件を満足していない場合は満足するよう遺伝子をビット反転させる。制約条件を満足する個体がｎ個生成できれば、各個体の適合度およびその世代での平均適合度を計算する。適合度については、その世代における平均適合度が前２世代の平均適合度と比較して、あるε（任意に設定する値）以下またはある繰り返し回数以上であれば、アルゴリズムを終了する。

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

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

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

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

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

以上説明したようにこの実施形態によれば、各加入者宅１００ごとのトータルのエネルギーコストを最小または低く抑えられるようにするための、燃料電池の発電スケジュールや蓄電池の充放電スケジュールを効率良く求めることが可能になる。すなわち第１の実施形態では、クラウドコンピューティングシステム３００のサービスを利用する形態で最適スケジューリングを実施するようにしたので、加入者宅１００に設置する情報機器のリソース負荷を低減することが可能になる。

図７は一日のなかでの計算負荷の推移を示す模式図である。負荷の高い最適スケジュール計算は、気象情報の配信を受けた直後のタイミングで１日数回実行されるので、仮に２１時と６時に気象情報が配信されるとすれば、その周辺の時間帯に計算負荷のピークが集中する。従ってこの時間帯の計算負荷をクラウドサービスを利用して負荷分散することで、サービス提供者にとっては、固定された専用サーバコンピュータ資源によってサービスを提供するよりも、設備投資などを格段に抑えることが可能となる。変動する計算負荷に合わせて柔軟に計算資源の増強が可能となるからである。

例えば演算に係わる複数のサーバコンピュータＳＶ１〜ＳＶ５があるとする。このうち１つのサーバコンピュータＳＶ１に、加入者宅１００のうち１００件分の計算を行わせるとする。低負荷の時間帯であればサーバコンピュータＳＶ１の能力で賄えるとしても、気象情報の配信を受けた後の所定期間（例えば、３０分）は負荷が高くなり、サーバコンピュータＳＶ１のリソースが足りなくなる虞がある。そこで、高負荷の時間帯においてはこの計算を他のサーバコンピュータＳＶ２〜ＳＶ５にも分担させ、計算の結果をデータベースＤＢに記憶させるようにすると良い。このようにすれば、後からその計算結果に係るデータに基づいて各加入者の電気機器を制御することができる。

このようなケースでは、サーバコンピュータＳＶ１は先ず他のサーバコンピュータＳＶ２〜ＳＶ５に問い合わせメッセージ信号を送信し、計算のためのリソースが十分にあるか否かを問い合わせる。そして、サーバコンピュータＳＶ１は、分担を了承したことを示す応答メッセージ信号を返送したサーバコンピュータＳＶに処理対象の各種データを送信して、計算の分担を依頼する。

なお、計算に要するデータには加入者を特定可能な識別子（加入者番号など）が付与される。この識別子に基づいて、サーバコンピュータＳＶ１は個別の加入者を特定することが可能であり、加入者の電気機器を個別に制御することが可能になる。

既存の技術では、インターネットアプリケーションサービスプロバイダ（ＡＳＰ）に最適化計算を委ね、データセンタ等に設置されるサーバコンピュータのリソースを用いることで、加入者の計算機リソースを少なくすることも考えられている。しかしながらサービス提供者の視点に立てば、例えば加入者が増大するにつれデータベース容量を増やしたり、計算負荷のピークに合わせて専用サーバコンピュータの最大計算機能力を増強するなど、多大な設備投資が継続的に必要になることが考えられる。

これに対し第１の実施形態によれば、加入者およびサービス提供者の双方にとって、計算負荷やデータベース容量の増大というリスクを解消することが可能になる。よって設備コストを抑えることが可能になる。さらに第１の実施形態によれば、電気機器の省エネルギー化に加入者の意思を反映させることも可能になる。以上から第１の実施形態によれば、演算にかかる負担を軽減し得るエネルギー管理システム、エネルギー管理方法、プログラム、サーバ装置およびクライアント装置を提供することが可能となる。

［第２の実施形態］
図８は、第２の実施形態に係わるエネルギー管理システムの作用を説明するための図である。第２の実施形態におけるシステム構成は、第１の実施形態と同様である。
図５のステップＳ１−４において、スケジュール情報が端末１０５のインタフェースに表示されるのに併せて、第２の実施形態では、図８に示されるようなカレンダーも表示する。加入者は、端末１０５に表示されるカレンダーから過去の任意の特定の日を選択指定する。指定された日付を示す日付指定メッセージ信号はクラウドコンピューティングシステム３００の予測部３００ｂに送信される。

日付指定メッセージ信号を受けた予測部３００ｂは、当該日付の電力需要量および給湯需要量をデータベースＤＢから読み出し、計算部３００ｃに渡す。これにより予測部３００ｂは、需要量予測に係わる演算を実行する代わりにデータベースＤＢから既存のデータを読み出すだけで足りる。従って電力需要量予測と給湯需要量予測にかかる処理を大幅に簡略化することができ、サーバコンピュータＳＶの計算負荷を大きく低減することが可能になる。

［第３の実施形態］
図９は、第３の実施形態に係るクラウドコンピューティングシステム３００およびＨＥＭＳの要部を示す機能ブロック図である。図９において図３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。第３の実施形態において予測部３００ｂは、スケジュールを算出しようとする日の電力需要量および給湯需要量の予測として、データベースＤＢに過去に記憶された、対象とする加入者の１週間前の同じ曜日の同じ時刻の値を読み出して計算部３００ｃに渡す。このようにしても、電力需要量予測と給湯需要量予測にかかる処理を大幅に簡略化することができ、サーバコンピュータＳＶの計算負荷を大きく低減することが可能になる。

加入者が端末１０５を介してクラウドコンピューティングシステムに対して要求することで、このような処理モードを設定することが可能である。処理モードの実行の如何に係わる設定登録情報はデータベースＤＢに記憶される。
具体的には、加入者から端末１０５のインタフェースに設定入力が与えられると、端末１０５は設定内容に係るメッセージ信号を、ＩＰネットワーク２００を介してクラウドコンピューティングシステム３００に送信する。このメッセージ信号を受信したクラウドコンピューティングシステム３００は、データベースＤＢにおける、送信元の加入者に係る記憶領域に設定内容を記憶する。

予測部３００ｂは、モード設定登録を示すフラグ（図示せず）が登録されているか否かを、制御ルーチンのなかで確認する。フラグが登録されていれば、予測部３００ｂは上記のとおり、対象とする加入者の１週間前の同じ曜日の同じ時刻の値をデータベースＤＢから読み出して計算部３００ｃに渡す。

［第４の実施形態］
第４の実施形態において予測部３００ｂは、スケジュールを算出しようとする日の電力需要量および給湯需要量の予測として、データベースＤＢに保持された電力需要量および給湯需要量のうち、一日の電力需要量が最大となる日と最小となる日の２通りの電力需要量および給湯需要量を読み出し、計算部３００ｃに渡す。このとき全てのデータを検索するのでなく、例えば季節（春、夏、秋、冬）に対応する、或る範囲内の期間から該当のデータを読み出すようにすれば計算負荷を軽減できる。

計算部３００ｃは、対象とする加入者宅１００に設置された蓄電池１０２の充放電スケジュール、または燃料電池１０３の発電スケジュールを、これら２通りの需要パターンに対応して２通り計算する。これらの稼動スケジュールはＨＥＭＳに送信され、端末１０５から加入者に通知される。加入者はいずれかの稼動スケジュールを選択指定し、選択したスケジュールの実行許可を制御部３００ｄに与える。このようにすることでエネルギー管理システムと加入者との間に対話環境を形成することができ、加入者の希望に近いスケジュールのもとで電気機器を稼動させることができる。

［第５の実施形態］
図１０は第５の実施形態に係わるエネルギー管理システムの作用を説明するための図である。第５の実施形態におけるシステム構成は、第１の実施形態と同様である。
第５の実施形態において、変更部３００ｆは、予測部３００ｂにて算出された需要量予測と検知部３００ｅにより検知された計算負荷とに基づき、稼動スケジュールの計算に係わるパラメータを変更する。パラメータには例えばスケジュールの時間間隔、つまりスケジュール演算の周期、あるいはスケジュールの対象とする期間などがある。このほかデータベースＤＢに記憶される各データ項目のそれぞれもパラメータとして考慮することが可能である。

第１の実施形態では所定期間ごとに稼動スケジュールを算出した。第５の実施形態では、生活スケジュールが加入者ごとに異なることを考慮し、スケジュール演算の周期を加入者ごとに可変する。例えば、加入者が外出しているとエネルギー需要がほとんど変動しないので、在宅時に比べて演算の周期を長くするようにする。これによりクラウドコンピューティングシステム３００側の負荷、特にサーバコンピュータＳＶの処理負荷を抑えることができ、システム全体としての演算リソースを効率的に利用することが可能になる。

在宅する加入者が多くなると演算の周期が全体として短くなり、クラウドコンピューティングシステム３００側の負荷が大きくなる。そこで、需要変動の大きい加入者の数が既定の閾値以上になれば、演算周期を短いモードから長いモードへと全体として変更する。これによりクラウドコンピューティングシステム３００側の負荷を抑制することが可能になる。

図１１および図１２は第５の実施形態における作用を説明するための図である。図１１に示されるように、予測された電力需要量の一定区間の平均値が既定の閾値以下となった場合は、例えば加入者が外出中であると判断しても良い。そこで変更部３００ｆはスケジュール時間間隔を通常より長くして、計算部３００ｃの計算負荷を低減させる。また、サーバコンピュータＳＶの計算負荷が既定の閾値以上となった場合は、変更部３００ｆは計算負荷を低減させるためにスケジュール時間間隔を長くする。

図１２に示されるように、サーバコンピュータＳＶの計算負荷が既定の閾値以上となった場合は、スケジュール期間を長くすることで変更部３００ｆはスケジュール期間を長くすることで計算部３００ｃの負荷を低減させる。

第５の実施形態によれば、クラウドコンピューティングシステム３００の計算負荷を低減させることが可能になる。また、計算負荷が低減可能となった場合、複数の加入者間の計算負荷の差異を利用して計算タスクを振り分けることで、特定のサーバコンピュータへの負荷集中を避けて平準化を行うこともできる。逆に、特定の加入者の求めに応じて最適化計算のパラメータを変更し、その分計算負荷の増大が起こったとしても、当該加入者の最適化計算を別のサーバコンピュータに振り分けるようにしてもよい。このようにすれば加入者からコストの増加の了承を受けたうえで、サービス品質の向上を図ることが可能になる。

［第６の実施形態］
図１３は、第６の実施形態に係るクラウドコンピューティングシステム３００およびＨＥＭＳの要部を示す機能ブロック図である。図１３において図９と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。
第６の実施形態において予測部３００ｂは、加入者により選択された日付における電力需要量および給湯需要量の予測を、図１４に示すようにデータベースＤＢから複数読み出す。これら複数の需要量予測は通信データ化され、ＩＰネットワーク２００を経由して端末１０５またはホームゲートウェイ７に送られる。

端末１０５は送信された複数の需要量予測を視覚的に表示する。これにより図１５に示すように、複数の需要量予測結果が加入者に提示される。図１５には電力需要量予測について二通りの予測結果が示される。給湯需要量予測についても同様である。加入者はいずれかの需要量予測結果を、例えばラジオボタンをクリックしたりタッチパネル上で指定するなどして選択する。選択の結果はＩＰネットワーク２００を経由してクラウドコンピューティングシステム３００に通知される。

計算部３００ｃはこの通知を受けて、加入者により選択された需要量予測（需要パターン）に対応する、蓄電池１０２の充放電スケジュール、または燃料電池１０３の発電スケジュールを計算する。このようにして算出された稼動スケジュールはＨＥＭＳに送信され、例えば端末１０５による加入者の実行許可を受けてから電気機器５の制御に反映される。

第６の実施形態ではエネルギー需要量予測に加入者の意思を反映させるためのインタフェースを提供できるようにしている。つまり加入者は、システムにより提示された複数のパターンにわたる需要量予測を自ら選択できるようになっている。

加入者の行動には、休日と平日などに区分可能な比較的パターン化された生活行動のほかに、急な外出や突発的な行動など、予測不能な行動もある。通常のパターンから逸脱する行動は電力や給湯の需要に大きく影響し、蓄電池や燃料電池などの稼働スケジュールもこれに応じて変動するが、加入者の行動までもシステム側で予測することは困難である。これはＢＥＭＳやＦＥＭＳに比較して、ＨＥＭＳが家庭向けであることに特有の事情である。

そこで第６の実施形態では、例えば行動パターンに応じて予測される複数の需要パターンを加入者に提示し、いずれかのパターンを加入者に選択させるようにしている。第４の実施形態では既に計算された稼働スケジュールを複数、提示するのに対し、第６の実施形態は計算のもとになる予測パターンを複数、提示する点に特徴を持つ。

例えば、計算結果である蓄電池や燃料電池の稼働スケジュールの適、不適を加入者が判断することは必ずしも容易ではない。これに対し需要ベースの情報であれば外出、在宅などの予定から、電力、給湯のいずれにしても加入者は或る程度その適、不適を判断できるはずである。これにより、加入者の突発的な行動や急な予定変更が生じても、これに追従して最適な稼動スケジュールを算出することが可能になる。
なお電力需要量、給湯需要量を予測する基準は、加入者の行動に限られるものではなく、天気予報や計画停電の要請など、異なる他の基準を適用することももちろん可能である。第７の実施形態では天気予報を利用した電力の需給予測について説明する。

［第７の実施形態］
図１６は、第７の実施形態に係るエネルギー管理システムの特徴を示す機能ブロック図である。第７の実施形態ではエネルギーの需要量に代えて、加入者宅に備わるＰＶシステム１０１によるエネルギーの供給量を予測する。

図１６において予測部３００ｂは、気象情報サーバＷＳから気象情報を取得する。実施形態では気象情報の一例として雲の移動予測情報を採り上げる。雲の移動予測情報は例えば気象レーダや気象衛星により取得された画像を処理して生成することが可能である。

データベースＤＢは、実施形態に係るデータとしてＰＶ発電量モデル３００ｉとマップデータ３００ｊとを記憶する。ＰＶ発電量モデル３００ｉは、ＰＶシステム１０１の特性をモデル化したデータであり、例えば日照（Ｌｕｘ）に対する発電量といったパラメータが記録される。
マップデータ３００ｊは、制御対象とする地域（加入者宅１００がある市町村、県、州など）を例えばメッシュ状に区切ってディジタルマップ化したデータベースであり、雲の移動予測情報と併せて処理可能な程度の解像度を有する。

予測部３００ｂは、雲の移動予測情報を気象情報サーバＷＳから取得し、マップデータ３００ｊを参照して対象地域の雲の移動を予測する。そして予測部３００ｂは、雲に覆われる時間帯と、雲の晴れる時間帯とをメッシュ区域ごとに、時系列的に予測する。その結果に基づいて予測部３００ｂはＰＶシステム１０１の発電量を、ＰＶ発電量モデル３００ｉを参照してメッシュごとに予測する。

図１７は、第７の実施形態における作用を説明するための図である。図１７にはマップデータ３００ｊにより示される地図上に、移動する雲を併せて示す。例えば米国のコロラド州を例に取れば、丁度その東側半分が雲に覆われている。拡大図にはコロラド州を４つの地域Ｃ１〜Ｃ４に分けるメッシュが示される。

雲の有無とＰＶシステム１０１の発電量とは密接に関係するので、雲の移動や形状の変化を予測できれば発電量を時系列で算出できるはずである。例えば地域Ｃ１，Ｃ３における発電量は、地域Ｃ２，Ｃ４における発電量よりも高いことを予測でき、ＰＶ発電量モデル３００ｉを用いれば具体的な数値も算出可能である。

そこで第７の実施形態では雲の移動を予測し、その結果をＰＶ発電量モデル３００ｉに当てはめて発電量を予測するとともに、マップデータ３００ｊも参照して、対象とする加入者宅１００におけるエネルギー供給量を予測するようにしている。なおディジタルマップ上で加入者宅を特定するにはサービス契約時に申請された住所を参照しても良いし、Global Positioning System（ＧＰＳ）などを用いて加入者宅の位置を特定しても良い。

図１８は、第７の実施形態における作用を説明するための図である。図１８は日本の東京都内２３区における港区を一例として示すもので、地理的スケールを変更しても上記と同様の効果を得られることを示す。

港区におけるエリアＭは、Ｍ１〜Ｍ４の４つのメッシュに区切られているとする。このうち雲のかかっている区画Ｍ２，Ｍ４よりも、雲のかかっていない区画Ｍ１，Ｍ３のほうがＰＶシステムの発電量は高い。よって区画Ｍ１における建物Ｈ１の発電量が、区画Ｍ４における建物Ｈ４の発電量よりも高いことを予測できる。雲は時間の経過とともに移動したり、濃くなったり、消えたりするが、気象情報を利用すればこのような変化をも予測できるので、ＰＶの発電量も時系列で予測することが可能になる。

また第７の実施形態では、同じ地域あるいは区画に属する建物におけるＰＶ発電量予測を、地理的領域（地域あるいは区画、またはそれに類する領域）を単位としてまとめて実施することが可能になる。例えば区画Ｍ１においては建物Ｈ１ごとにＰＶ発電量を個別に予測するのでなく、同じ区画に在る複数の建物Ｈ１についてまとめてＰＶ発電量を予測すれば良い。区画Ｍ２，３，４においても同様である。

このような形態は、図３、図９、あるいは図１３に示される予測部３００ｂ、計算部３００ｃを、複数の加入者に対して設けられる機能オブジェクトとしてインプリメントする形態に対応する。これにより計算量を大幅に低減することができ、クラウドコンピューティングシステム３００の負荷を減らすことや、計算リソースの節約を図ることが可能になる。また、クラウドコンピューティングシステム３００に予測計算機能を設けることのメリットを最大限に享受することが可能になる。

以上のようにしたので第７の実施形態によれば、複数の加入者で予測部３００ｂの演算リソースを共用し、例えば既定の地域的エリアにわたる加入者宅１００のエネルギー自給量をも予測することが可能になる。これにより、稼動スケジュールの算出の精度が高まるなどの効果も得られる。

また第７の実施形態では、ＰＶシステム１０１の発電性能をモデル化したＰＶ発電量モデル３００ｉを用いている。このＰＶ発電量モデル３００ｉは複数の加入者にわたって共通に用いることができるので、複数の加入者に対する予測演算をまとめて実行することが可能になる。これにより個々の加入者ごとにＰＶ発電量を予測するのに比べて演算の負荷を飛躍的に軽減することが可能になる。

さらに第７の実施形態では、地理的領域を例えばメッシュ状に区切って特定できるようにしているので、ＰＶ発電量の予測に限ることなく、よりきめ細かな最適制御への応用を図ることも可能になる。
例えば電力供給量に比べて電力需要が上回ることが予測された場合、行政から節電要求や計画停電、あるいは輪番停電を要請されることがある。これらの要請は地域を指定して発令されるので第７の実施形態との親和性が高い。

つまり需要量予測、発電量予測をエリアごとに実施できることから、節電要請を予測のパラメータに取り入れることで、よりきめ細やかな配電最適化制御を実現することが可能になる。例えば計画停電のスケジュールに併せてエリア単位で蓄電し、充電電力を停電エリアに分配するなどの制御が可能になる。さらには、複数の地域メッシュ任意に組み合わせることで、最適制御に係わる地理的領域を時系列で動的に変化させるようにすることも可能である。

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

１００…加入者宅、３００…クラウドコンピューティングシステム、７…ホームゲートウェイ、７ａ…通信部、ＳＶ…サーバコンピュータ、ＤＢ…データベース、６…電力系統、６１…変圧器、１９…電力量計、２０…分電盤、２１…配電線、５…電気機器、１０４…パワーコンディショニングシステム（ＰＣＳ）、１０１…ＰＶシステム、１０２…蓄電池、１０３…燃料電池、ＥＶ…電気自動車、２５…ホームネットワーク、１０５…端末、２００…ＩＰネットワーク、３００ａ…収集部、３００ｂ…予測部、３００ｃ…計算部、３００ｄ…制御部、３００ｅ…検知部、３００ｆ…変更部、３００ｇ…制御対象モデル、３００ｈ…データ、４０…通信回線、ＷＳ…気象情報サーバ、Ｃ１〜Ｃ４…地域、Ｍ１〜Ｍ４…区画、Ｈ１，Ｈ４…建物

Claims (35)

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. 前記計算することは、エネルギー単価および前記予測されたエネルギー需要量に基づいて遺伝的アルゴリズムにより前記稼働スケジュールを計算する、請求項２０に記載のプログラム。
27. クライアント装置と通信可能なサーバ装置において、
    配電網から電力を供給される需要者の電気機器に係わるデータを前記クライアント装置から取得する取得部と、
    雲の移動予測を示す気象情報と、太陽光発電システムの特性をモデル化した太陽光発電モデルと、制御対象とする地域をメッシュ状に区切ってディジタルマップ化したマップデータとに基づいて、前記地域における前記太陽光発電システムの発電量を予測し、前記電気機器に係わるデータに基づいて前記電気機器のエネルギー需要量を予測する予測部と、
    前記予測されたエネルギー需要量および発電量に基づいて、前記需要者におけるエネルギー収支を最適化すべく、前記需要者に備わる蓄電池の充放電スケジュール、または、前記需要者に備わる燃料電池の発電スケジュールの少なくともいずれか一方である稼働スケジュールを計算する計算部と、
    前記計算された稼働スケジュールに基づいて、前記蓄電池または前記燃料電池の少なくともいずれか一方を制御するための制御情報を前記クライアント装置に送信する制御部と、
    前記稼働スケジュールの計算の周期を前記需要者ごとに変更する変更部と、
    前記地域のメッシュの組み合わせを変更して、最適制御に係わる地理的領域を時系列で動的に変化させる手段と
    を備える、サーバ装置。
28. 前記変更部は、前記予測されたエネルギー需要量に基づいて前記稼働スケジュールの計算の周期を変更する、請求項２７に記載のサーバ装置。
29. さらに、
    前記計算部による前記稼働スケジュールの計算に係わる負荷を検知する検知部を備え、
    前記変更部は、
    前記負荷の基準からの逸脱を抑制すべく前記稼働スケジュールの計算の周期を変更する、請求項２７に記載のサーバ装置。
30. 前記予測部は、前記エネルギー需要量を保持するデータベースに保持された過去のエネルギー需要量を読み出して前記エネルギー需要量を予測する、請求項２７に記載のサーバ装置。
31. 前記予測部は、前記エネルギー需要量を異なる基準に基づいて複数予測し、
    前記計算部は、前記予測された複数のエネルギー需要量にそれぞれ対応する複数の前記稼働スケジュールを計算し、
    前記制御部は、前記計算された複数の稼働スケジュールを前記クライアント装置に送信する、請求項２７乃至３０のいずれか１項に記載のサーバ装置。
32. 前記計算部は、前記取得された電気機器に係わるデータと前記電気機器の制御対象モデルとを保持するデータベースに保持されるデータおよび制御対象モデルに基づいて前記稼働スケジュールを計算する、請求項２７に記載のサーバ装置。
33. 前記計算部は、エネルギー単価および前記予測されたエネルギー需要量に基づいて遺伝的アルゴリズムにより前記稼働スケジュールを計算する、請求項２７に記載のサーバ装置。
34. 前記予測部は、前記エネルギー需要量を異なる基準に基づいて複数予測し、
    前記計算部は、前記予測された複数のエネルギー需要量のうちから前記需要者により選択されたエネルギー需要量に基づく前記稼働スケジュールを計算し、
    前記制御部は、前記計算された稼働スケジュールを前記クライアント装置に送信する、請求項３１に記載のサーバ装置。
35. 前記取得部、前記予測部、前記計算部、前記制御部および前記変更部の少なくともいずれか１つは、クラウドコンピューティングシステムに分散配置される機能オブジェクトである、請求項２７に記載のサーバ装置。

Images