(57)【要約】【課題】ユーザサイトにおける電力の使用予定を収集して発電すべき量を決定する装置または方法において、その使用予定とは異なる態様で電力を使用するユーザサイトの増加に適切に対応する。【解決手段】制御装置１００は、どの使用パターンで電力を使用する予定であるかに関する電力予定情報をネットワークを介して取得する電力予定情報取得部１１２と、電力予定情報に基づいて予定発電量を演算する予定発電量演算部１１４と、使用パターンの切り替わりを示す切替情報をネットワークを介して取得する切替情報取得部１１８と、切替情報が取得されるか否かに基づき決定される実際の使用パターンと、電力予定情報が示す予定としての使用パターンと、の異同を判定するパターン異同判定部１２０と、その判定結果に基づいて、予定発電量を変更すべきか否かを判定する発電変更判定部１２２と、を備える。【選択図】図２
2014095947.tif 000002
【特許請求の範囲】
【請求項１】
ユーザサイトにおける異なる複数の電力の使用パターンのうちのどの使用パターンで電力を使用する予定であるかに関する電力予定情報をネットワークを介して取得する電力予定情報取得部と、
前記電力予定情報取得部によって取得された電力予定情報に基づいて、ユーザサイトに電力を供給する発電所が発電すべき量である予定発電量を演算する予定発電量演算部と、
ユーザサイトにおける電力の使用パターンの切り替わりを示す切替情報をネットワークを介して取得する切替情報取得部と、
前記切替情報取得部によって切替情報が取得されるか否かに基づき決定される実際の使用パターンと、前記電力予定情報取得部によって取得される電力予定情報が示す予定としての使用パターンと、の異同を判定するパターン判定部と、
前記パターン判定部における判定結果に基づいて、前記予定発電量演算部によって演算された予定発電量を変更すべきか否かを判定する発電変更判定部と、を備えることを特徴とする制御装置。
【請求項２】
前記パターン判定部は複数のユーザサイトに亘って実際の使用パターンと予定としての使用パターンとの異同を判定し、
前記発電変更判定部は、前記パターン判定部において使用パターンが異なると判定されたユーザサイトの割合がしきい値を上回る場合、予定発電量を変更すべきであると判定することを特徴とする請求項１に記載の制御装置。
【請求項３】
ユーザサイトにおける異なる複数の電力の使用パターンは、第１使用パターンと、第１使用パターンよりも電力の平均使用量が少ない第２使用パターンと、を含み、
前記発電変更判定部は、予定としての使用パターンが第２使用パターンでありながら実際の使用パターンが第１使用パターンであるユーザサイトの割合がしきい値を上回る場合、予定発電量を増やすべきであると判定することを特徴とする請求項２に記載の制御装置。
【請求項４】
実際の使用パターンが第２使用パターンであることを条件のひとつとして、対応するユーザサイトの電気機器をネットワークを介して制御するサイト機器制御部をさらに備えることを特徴とする請求項３に記載の制御装置。
【請求項５】
切替情報は、ユーザサイトに関連するユーザ端末に対するユーザの入力に基づきユーザ端末において生成されることを特徴とする請求項１から４のいずれかに記載の制御装置。
【請求項６】
請求項１から５のいずれかに記載の制御装置によって提供されるサービスに関連するコンピュータプログラムであって、本コンピュータプログラムはネットワークを介して表示部を有する携帯端末に送信され、
本コンピュータプログラムは、
使用パターンの切り替わりに対応するイベントの発生の通知をユーザから受け付ける通知受付画面を前記表示部に表示させる機能と、
ユーザから受け付けた通知に基づいて生成された切替情報を、ネットワークを介して前記制御装置に送信する機能と、を前記携帯端末に実現させることを特徴とするコンピュータプログラム。
【請求項７】
通知受付画面は広告を表示する広告表示領域を含むことを特徴とする請求項６に記載のコンピュータプログラム。
【請求項８】
ユーザサイトにおける異なる複数の電力の使用パターンのうちのどの使用パターンで電力を使用する予定であるかに関する電力予定情報をネットワークを介して取得することと、
取得された電力予定情報に基づいて、ユーザサイトに電力を供給する発電所が発電すべき量である予定発電量を演算することと、
ユーザサイトにおける電力の使用パターンの切り替わりを示す切替情報をネットワークを介して取得することと、
切替情報が取得されるか否かに基づき決定される実際の使用パターンと、取得される電力予定情報が示す予定としての使用パターンと、の異同を判定することと、
判定結果に基づいて、演算された予定発電量を変更すべきか否かを判定することと、を含むことを特徴とする制御方法。
【請求項９】
ユーザサイトにおける異なる複数の電力の使用パターンのうちのどの使用パターンで電力を使用する予定であるかに関する電力予定情報をネットワークを介して取得する機能と、
取得された電力予定情報に基づいて、ユーザサイトに電力を供給する発電所が発電すべき量である予定発電量を演算する機能と、
ユーザサイトにおける電力の使用パターンの切り替わりを示す切替情報をネットワークを介して取得する機能と、
切替情報が取得されるか否かに基づき決定される実際の使用パターンと、取得される電力予定情報が示す予定としての使用パターンと、の異同を判定する機能と、
判定結果に基づいて、演算された予定発電量を変更すべきか否かを判定する機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御装置、制御方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
電力会社は、自己が運営する原子力発電所、水力発電所、火力発電所等において発電された電力をユーザサイトに供給する。電力会社は通常、円滑な電力供給を目指して、発電所にユーザサイトでの最終需要量以上に発電させている。この発電量は一般には最終需要量の３〜４割増しと言われている。平時ではこの約３割分が発電ロスとなっている。
【０００３】
現在、我が国電力会社において発電／配電／給電にかかる年間総コストはおよそ１３兆円と見積もることができる。この約３割すなわち約４兆円分が上記の発電ロスに相当する。見方を変えると、約４兆円分の発電ロス・マーケットが存在する。
【０００４】
一方、ラミネート型リチウムイオンバッテリなどの蓄電装置や太陽光発電装置、風力発電装置などの発電装置のユーザサイトへの普及が進んでいる。このような蓄電装置や発電装置を効率的に利用しようとする試みが提案されている（例えば、特許文献１参照）。
【０００５】
特許文献１に記載のシステムでは、電力の需要と供給とが逼迫する期間においてユーザサイトの蓄電装置に放電させることで、発電量のマージンを低減可能としている。また、電力の需要予測を得るために各ユーザサイトから電力の使用予定を収集している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−９５４５５号公報
【非特許文献】
【０００７】
【非特許文献１】佐藤仁人、滝雄二朗、「米国におけるデマンドレスポンスアグリゲータの現状と今後」、ＮＲＩ  ＫＮＯＷＬＥＤＧＥ  ＩＮＳＩＧＨＴ、２０１２年３月、Ｖｏｌ．２３
【非特許文献２】ＷｏｒｄＰｒｅｓｓ、インターテックリサーチブログ、ＤＲアグリゲーションビジネスで勝ち残るのはだれか？、［online］、［２０１２年１０月２６日検索］、インターネット＜URL：http://www.itrco.jp/wordpress/?p=3383＞
【非特許文献３】パワーアカデミー、世界一の電気はこうしてつくられる！、株式会社  オーム社、2009年11月20日
【非特許文献４】ライフリサーチプロジェクト「編」、日本の電力  そんな秘密があったのか！、株式会社  青春出版社、2011年7月20日
【非特許文献５】自然エネルギー革命研究会、自然エネルギーが日本経済復活の起爆剤になる、株式会社  洋泉社、2011年9月9日
【非特許文献６】飯田哲也、「エネルギー進化論」（第４の革命）が日本を変える、ちくま新書、2011年12月10日
【非特許文献７】飯田哲也、古賀茂明、大島堅一、原発がなくても電力は足りる！、株式会社  宝島社、2011年9月31日
【非特許文献８】岸  宣仁、（電池）で負ければ日本は終わる、株式会社  早川書房、2012年6月20日
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ユーザサイトにおける電力の使用が予定通りであれば、特許文献１に記載される技術によって、発電所における発電量をより平準化または低減することができる。しかしながら、基本的にユーザには予定通りに電力を使用する義務はないので、予定とは異なる態様で電力を使用するユーザサイトが少なからず存在する。そのようなユーザサイトの割合が大きくなるほど、特許文献１に記載される技術では対応が困難になってくる。
【０００９】
本発明はこうした課題に鑑みてなされたものであり、その目的は、ユーザサイトにおける電力の使用予定を収集して発電すべき量を決定する装置または方法において、その使用予定とは異なる態様で電力を使用するユーザサイトの増加に適切に対応できる制御技術の提供にある。
【課題を解決するための手段】
【００１０】
本発明のある態様は、制御装置に関する。この制御装置は、ユーザサイトにおける異なる複数の電力の使用パターンのうちのどの使用パターンで電力を使用する予定であるかに関する電力予定情報をネットワークを介して取得する電力予定情報取得部と、電力予定情報取得部によって取得された電力予定情報に基づいて、ユーザサイトに電力を供給する発電所が発電すべき量である予定発電量を演算する予定発電量演算部と、ユーザサイトにおける電力の使用パターンの切り替わりを示す切替情報をネットワークを介して取得する切替情報取得部と、切替情報取得部によって切替情報が取得されるか否かに基づき決定される実際の使用パターンと、電力予定情報取得部によって取得される電力予定情報が示す予定としての使用パターンと、の異同を判定するパターン判定部と、パターン判定部における判定結果に基づいて、予定発電量演算部によって演算された予定発電量を変更すべきか否かを判定する発電変更判定部と、を備える。
【００１１】
本発明の別の態様は、コンピュータプログラムである。このコンピュータプログラムは、上記の制御装置によって提供されるサービスに関連するコンピュータプログラムであって、本コンピュータプログラムはネットワークを介して表示部を有する携帯端末に送信され、本コンピュータプログラムは、使用パターンの切り替わりに対応するイベントの発生の通知をユーザから受け付ける通知受付画面を表示部に表示させる機能と、ユーザから受け付けた通知に基づいて生成された切替情報を、ネットワークを介して制御装置に送信する機能と、を携帯端末に実現させる。
【００１２】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１３】
本発明によれば、ユーザサイトにおける電力の使用予定を収集して発電すべき量を決定する装置または方法において、その使用予定とは異なる態様で電力を使用するユーザサイトの増加に適切に対応できる。
【図面の簡単な説明】
【００１４】
【図１】電力供給システムの構成を示す模式図である。
【図２】実施の形態に係る制御装置の機能および構成を示すブロック図である。
【図３】図２のユーザ情報保持部の一例を示すデータ構造図である。
【図４】図２の予定情報保持部の一例を示すデータ構造図である。
【図５】図２の予定発電量保持部の一例を示すデータ構造図である。
【図６】図２の制御装置におけるリアルタイム制御を説明するための模式図である。
【図７】通知用アプリケーションプログラムを実行する携帯端末のタッチパネルに表示されるログイン画面の代表画面図である。
【図８】メニュー画面の代表画面図である。
【図９】電気予約受付画面の代表画面図である。
【図１０】通知受付画面の代表画面図である。
【図１１】図２の制御装置における事前処理に係る一連の処理を示すフローチャートである。
【図１２】図２の制御装置におけるリアルタイム処理に係る一連の処理を示すフローチャートである。
【図１３】ユーザサイトにおける各種時刻とＲＴＯ／ＲＰＯの概念との対応を説明する説明図である。
【発明を実施するための形態】
【００１５】
以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１６】
本発明者は以下の認識を有する。
現状、我が国の国内には火力発電所、原子力発電所、水力発電所、揚水発電所をはじめとする大型発電所が各地にあり、多くの発電機を保有している。これらの発電機は工場や各家庭の需要家の負荷（電気の需要）に応じて、発電量を増やしたり、減らしたりしてバランスを取っている。一部の発電機に何らかの障害が発生したり、送電網のネットワークに許容以上の負荷が生じたりすると需要と供給のバランスが崩れ、停電を引き起こす要因になりえる。したがって、我が国の国内にある発電所や送配電網は本来の需要発電容量を超えた余剰発電設備（十分なバッファ）を多く保有することで、万が一の停電リスクを減らしている。
【００１７】
また稼働中の発電機についても、繊細な周波数変動に対応するため、発電機の出力を２４時間コントロールしているが、発電機の制御以上に燃焼室の制御は非常にデリケートである。原子力発電所は発動／停止制御が不得手であるが故、常に高い変動稼働率を維持しなければならない。石油、石炭をエネルギ資源とする発電所は細かい制御が比較的苦手である（石炭など、一度燃焼を開始した１次エネルギは消火できない）。
【００１８】
そして、往々にしてこれら大型発電所は需要家から遠く離れた拠点で発電している。電力会社は送電ロスを回避するために交流方式を採用し超高圧に昇華させて高圧送電を行い、需要家が近づいてくると減圧して低圧需要家へ配電を行っているが、そもそも原子力、石油、石炭、天然ガス等の１次エネルギは、電気という２次エネルギに変換する（つまり発電）際に、元々のエネルギの約２／３をロストするという本質的な問題点を抱えており、省エネ・節約という観点から高効率性を達成しているとは言えない。昨今注目度が高いコンバインドガスタービン発電機は５０％以上の発電効率を誇るものの、それでも半分近い発送電ロスがあるという課題は残されている。
【００１９】
一方で、電力利用に関しては、需要家サイドもこれまでの垂れ流し的電力運用を改める時期にきている。常に省エネ・節電を意識したエコ運用が求められており、発電所側の無駄を厳しく追求するばかりではなく、自らの過剰な電気利用についても自己評価を行う姿勢が求められ、資源には限りがあるという意識を持つことが要請されている。
【００２０】
したがって、先般の大震災にかかる諸般の事情や影響、また本質的に内在するこれらのレガシー発電システムの問題点を踏まえると、今後は、大型発電所が持つ役割や性格が次第にダウングレードしていき、中小型・マイクロ化していくことが予想される。また今後は従来の１次エネルギ変換型ではなく、再生可能エネルギを利用した発電所もさらに出現するであろうし、さらなるエネルギ利用効率を求め、余剰電気はいつでもバッファとして再活用できるよう頻繁な蓄電行為が各要所、要所で行われていく可能性が高い。従来の大型発電所による大規模で緩やかな制御ではなく、高効率性を求めた中小型の発電所がダイナミックにネットワーク連動して、需要家の電力ニーズにキメ細かく対応していくことが必要になる。もちろん、それら制御の新しい担い手としてＩＣＴ（Information and Communication Technology）技術も採用されていくであろう。
【００２１】
需要家が参画できる省エネ・節電行為にはいろいろタイプがあるが、新しい有効な省エネ・節電行為としては「需要家側における電力の予約」という概念が上げられる（例えば、特許文献１参照）。発電所側の細かい運用を支援するには、需要家側の「いつ何時、どれくらい電気を使うか」という情報を発電所側が常時取得出来ることは繊細な省エネを実現する上で大変有効な運用であると思われる。各需要家の細かい運用計画報告が発電所側に届くことで発電所側は需要に合わせた最善のスペックで最小限の発電を行うことが出来るようになる。ＤＲ（Demand Response）アグリゲータ（例えば、非特許文献１、２参照）等はまさにこのような役割を達成するために、需要家サイドからレポートされる詳細情報をダイナミックにフル活用して無駄がない発送電を担っていくことになるであろう。
【００２２】
しかしながら、予約システムだけでは実運用では十分でない可能性が認められる。きめ細かいマイクロ発電や細分化された蓄電池の放電ロスを最小限にするためには、実際のサービスにおいて予約通りに運用しているか否かを判断する各需要家における電力運用のリアルタイム監視と制御が必要となる。そのような運用を実現するために、需要家の電気を使う状況は今どうなっているか、本当に予約通りに運用しようとしているのか、等の動きを供給側がリアルタイムに把握することが重要になってくる。
【００２３】
また、中小型の発電所が各地に設置されるようになれば、従来以上に需要レスポンスに対して繊細な電圧・周波数制御が必要になってくる。需要家との接点距離が近くなることは、その分供給運用もクリティカルなものになっていくことを意味しており、電力変動因子の情報におけるリアルタイム性とインタラクティブ性の確保は必須になるであろう。
【００２４】
すなわち、電力予約システムに加え、需要家が外出したか、帰宅したか、就寝したかという電力使用変動幅が大きくなる需要家サイドの直近情報をダイレクトに取得し、電力供給側にシームレスに通知する実施の形態に係るシステムがあって、はじめて分散化された発電機における起動や細分化された蓄電池の放電を正しいタイミングで起動することが可能になる。場合によっては需要家側に設置された蓄電池の放電・充電制御を行う省エネ・節電運用がなされてもよい。
【００２５】
一方、電気を利用した実績データはスマートメータから取得出来る、という考え方もある。しかしながら、スマートメータから取得された実績データでは需要家側における「電気を利用する直近の都合や予定」を正確に認識することは出来ない。実績データはあくまで結果情報である。供給側は、需要家における大きな電力使用変動が生じるタイミングの際に、電圧や周波数調整に必要なスタンバイ、アイドリング状態を適切に維持するためには予約通りに電力使用変動が行われるか否かの「生の」信号が欲しいところである。例えば、需要家による予約システムはスマートメータからの実績データを参照して、需要家側の電力利用状況をある程度可視化することは可能である。しかしながら、実績データを参照するだけでは直近の需要家側の最終需要動向が正確に見えないので、従来通りの余力マージンを意識した、供給側の供給設備スタンバイ、アイドリング状態に余裕を持ったルーズな対応（発電供給、周波数制御）に陥りやすい。
【００２６】
具体的な例を挙げると、需要家における予定された外出時間が訪れたにもかかわらず、需要家が相変わらず在宅して電力を利用している（本来ならば「予約」情報では待機電源モード時間帯に突入になっている）場合を考える。すなわち、「電力予約」とは異なる実運用がなされた場合を考える。ＤＲアグリゲータ等の電力調整・供給側は、需要家に対して電力供給せざるを得ない立場にあり、需要家に求められる実際の電力ニーズに応じて継続して供給維持されることになる。
【００２７】
このとき供給側が判断に困る事例としては、需要家が外出予定時間を大幅に遅れて外出することになった場合である。外出したことが分からない電力調整・供給側は、スマートメータからの実績データは電力使用量が減少（待機電源モード）を示していても、「もしかしたら未だ在宅しており、またすぐに使い出すかもしれない」と考え、いつ使い出すか分からない電気に対して余力マージンを維持した発電側設備の制御を迫られるであろう。
【００２８】
また別な事例を挙げれば、休日で“終日外出”と予約したにもかかわらず、急遽予定が変更されて自宅に残り電気を使う場合がある。これではスマートメータからの需要データを供給側が取得出来ても、いつまで継続利用されるのか判断が出来ない。この他にも、帰宅予定時刻より早く帰宅した時、帰宅予定時刻よりも遅れて帰宅してきた時などにも、供給側は常にアドバンテージを考慮した供給運用を強制される可能性が認められる。法人による場合はさらに深刻となりうる。各一般家庭よりも電力使用容量が大きい各企業における生産活動に伴う工場等の就業開始、休憩、就業停止、休日に関する電力予約と実運用の誤差の影響は大きい。
【００２９】
このように、ユーザ側の行動の不確定性が入り込むと、何のための予約なのか曖昧になって予約定義の意味が薄れる可能性がある。予約とスマートメータから取得された実績データとの差分によって、却って発電所側、ＤＲアグリゲータ側に混乱が生じる可能性がある。結果的に発電ロスが多い、従来のレガシー発送電システムと大差なくなる虞がある。そこで、予約システムには、需要家が予約通り、本当に実行しようとしているのかどうか、まさにその姿勢や状態を知ることが重要なのである。
【００３０】
これらのことを踏まえ、一例では電力予約システムを補完するため、需要家からの電力利用変動幅が生じるタイミング（リアルタイム在宅情報）を取得することを目的としたのが実施の形態に係る制御装置を備えるシステムである。
【００３１】
図１は、電力供給システム２の構成を示す模式図である。電力供給システム２は、データセンタ４と、発電所６と、第１ユーザサイト８と、第２ユーザサイト１０と、第３ユーザサイト１２と、第４ユーザサイト１４と、インターネットなどのネットワーク１６と、配電網１８と、を備える。
【００３２】
発電所６は電力会社によって運営され、原子力発電、火力発電、水力発電、揚水発電、地熱発電、風力発電等により発電した電力を配電網１８を介して各ユーザサイト８、１０、１２、１４に供給する。
【００３３】
ユーザサイトは電力供給の契約の１単位である。ユーザサイトは戸建てやマンションやビルや工場等であってもよい。各ユーザサイト８、１０、１２、１４は電力会社との契約に基づき発電所６から電力の供給を受けている。ユーザサイトの数は図１に示される例に限られないことは当業者には理解される。
【００３４】
電力供給システム２では、ユーザサイトに対して異なる複数の電力の使用パターンが規定される。例えば、ユーザサイトが戸建てやマンションなどの一般家庭である場合、以下の３つの使用パターンが規定される。
（１）家人が在宅しておりかつ就寝していないときの電力の使用パターンである在宅非就寝パターン。
（２）家人が不在にしているときの電力の使用パターンである不在パターン。
（３）家人が在宅しているが就寝しているときの電力の使用パターンである就寝パターン。
なお、電力の平均使用量について、在宅非就寝パターン＞＞就寝パターン≧不在パターンとなる。
【００３５】
ユーザサイトがビルや工場である場合、以下の３つの使用パターンが規定される。
（１）工場やビルのオフィスが操業しているときの電力の使用パターンである操業パターン。
（２）工場やビルのオフィスが休業しているときの電力の使用パターンである休業パターン。
（３）工場やビルのオフィスの休憩期間における電力の使用パターンである休憩パターン。
【００３６】
以下、ユーザサイトは一般家庭である場合について説明するが、ユーザサイトが他の形態のサイトを追加的にまたは代替的に含む場合にも本実施の形態に係る技術的思想を適用できることは、本明細書に触れた当業者には理解される。
【００３７】
データセンタ４は実施の形態に係る制御装置（図１では不図示）を有する。制御装置はサーバ等であってもよく、ＤＲアグリゲータによって管理、運用される。制御装置は、発電計画を立てる対象の日（以下、対象日と称す）に発電所６が発電すべき量（以下、予定発電量と称す）を、対象日より前に決定して発電所６に通知する。この際、制御装置は各ユーザサイトのユーザから対象日における電力の使用パターンの予定を収集し、収集された予定に基づき予定発電量を計算する。
【００３８】
制御装置は、対象日当日、各ユーザサイトのユーザから使用パターンの切り替わりを示す通知を受ける。制御装置は、通知の有無等から決定されるユーザサイトの実際の使用パターンと、予定上の使用パターンと、の異同をリアルタイムで判定する。制御装置は、実際の使用パターンと予定上の使用パターンとが異なるユーザサイトの数が基準以上に増大すると、数分から数時間後の予定発電量を変更すべきであると判定する。そのように判定されると、制御装置は予定発電量を適切に修正し、修正された予定発電量を速やかに発電所６に通知する。
【００３９】
ユーザサイト８、１０、１２、１４はそれぞれ、太陽光発電装置８ａ、１０ａ、１２ａ、１４ａと蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂとを有する。太陽光発電装置８ａ、１０ａ、１２ａ、１４ａは、公知の太陽光発電技術により構成される発電装置である。蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂはそれぞれ、太陽光発電装置８ａ、１０ａ、１２ａ、１４ａから連続的に充電される。すなわち蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂは自家発電によって充電される。蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂ自体またはそれに接続される不図示のホームサーバやスマートメータは、データセンタ４に設置された制御装置とネットワーク１６を介して接続される。
【００４０】
蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂはそれぞれ配電網１８と接続され、放電の指示があると、蓄えられた電力を自己が属するユーザサイトおよびそのユーザサイトと配電網１８で接続される他のユーザサイトに供給する。また蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂは、放電禁止の指示があると、指示された期間中放電を行わない。蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂまたはホームサーバやスマートメータは、制御装置からネットワーク１６を介して受信する指令情報に基づいて蓄電装置８ｂ、１０ｂ、１２ｂ、１４ｂに放電または放電禁止の指示を出す。
【００４１】
図２は、実施の形態に係る制御装置１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解される。
【００４２】
制御装置１００は、対象日より前に対象日における電力の需要予測から予定発電量を演算する事前処理部１０２と、対象日当日にユーザサイトにおけるユーザの動向をリアルタイムに収集して電力需要が予定通りか否かを判定するリアルタイム処理部１０４と、ユーザ情報保持部１０６と、予定情報保持部１０８と、予定発電量保持部１１０と、ポイント処理部１３０と、を備える。リアルタイム処理部１０４は、予定通りでないと判定された場合、予定発電量を修正して発電所６に通知する。
【００４３】
図３は、ユーザ情報保持部１０６の一例を示すデータ構造図である。ユーザ情報保持部１０６は、ユーザサイトを特定するユーザサイトＩＤと、そのユーザサイトが備えるホームサーバ、スマートメータまたは蓄電装置のＩＰアドレスと、そのユーザサイトのユーザを特定するユーザＩＤと、パスワードと、そのユーザサイトにおける現時点での実際の使用パターンと、エコポイントと、を対応付けて保持する。
【００４４】
図４は、予定情報保持部１０８の一例を示すデータ構造図である。予定情報保持部１０８は、ユーザサイトＩＤと、ユーザサイトＩＤによって特定されるユーザサイトのユーザが対象日において起床する予定の時刻である起床予定時刻と、そのユーザが対象日において外出する予定の時刻である外出予定時刻と、そのユーザが対象日において帰宅する予定の時刻である帰宅予定時刻と、そのユーザが対象日において就寝する予定の時刻である就寝予定時刻と、を対応付けて保持する。
【００４５】
なお、１日に外出が複数回ある場合も想定して、外出予定時刻と帰宅予定時刻との複数の組を予定情報保持部に登録できるよう構成してもよい。本実施の形態では説明をより分かりやすくするため、予定情報保持部１０８にそのような組がひとつ登録されるものとする。しかしながら、予定情報保持部にそのような組を複数登録する場合にも本実施の形態に係る技術的思想を適用できることは、本明細書に触れた当業者には理解される。
【００４６】
また、ユーザサイトに複数のユーザが関連付けられている場合（例えば、複数人構成の家庭が住む一戸建て）、起床予定時刻は一番早起きのユーザの起床予定時刻であってもよく、外出予定時刻は最も遅く家を出るユーザ（最終退出者）の外出予定時刻であってもよく、帰宅予定時刻は最も早く家に帰るユーザ（初回入室者）の帰宅予定時刻であってもよく、就寝予定時刻は最も遅く就寝するユーザ（最終就寝者）の就寝予定時刻であってもよい。しかしながら複数のユーザのうちのだれを基準に各時刻を設定するかは基本的に任意であり、適宜設定されればよい。
【００４７】
図５は、予定発電量保持部１１０の一例を示すデータ構造図である。予定発電量保持部１１０は、対象日における時間帯と、その時間帯の予定発電量と、を対応付けて保持する。なお、図５に示される予定発電量の単位は任意の適切な単位である。
【００４８】
図２に戻り、事前処理部１０２は、電力予定情報取得部１１２と、予定発電量演算部１１４と、予定発電量通知部１１６と、を含む。
電力予定情報取得部１１２は、各ユーザサイトについて、３つの使用パターン（すなわち、在宅非就寝パターン、不在パターンおよび就寝パターン）のうちのどの使用パターンで電力を使用する予定であるかに関する電力予定情報をネットワーク１６を介して取得する。電力予定情報は対象日についての予定を示す情報であり、電力予定情報取得部１１２は対象日の前の日までに電力予定情報を取得する。特に電力予定情報は起床予定時刻と外出予定時刻と帰宅予定時刻と就寝予定時刻とを含む。電力予定情報は、ユーザサイトのユーザが使用するユーザ端末に対するユーザの入力に基づきユーザ端末において生成される。ユーザ端末は例えばホームサーバやスマートメータや予定通知用専用端末やパーソナルコンピュータやラップトップコンピュータや携帯端末である。ユーザ端末はネットワーク１６を介して制御装置１００と通信可能に構成される。ユーザ端末が携帯端末である場合の例が図７、図８、図９、図１０を参照して後述される。
【００４９】
電力予定情報取得部１１２は、ユーザ端末から取得された電力予定情報に含まれる各時刻を、そのユーザ端末を使用するユーザのユーザサイトのユーザサイトＩＤに対応付けて予定情報保持部１０８に登録する。
【００５０】
予定発電量演算部１１４は、予定情報保持部１０８に保持される対象日についての電力予定情報に基づいて、対象日における予定発電量を演算する。予定発電量演算部１１４は、予定情報保持部１０８を参照し、対象日の各時間帯における各ユーザサイトの予定としての使用パターンを決定する。特に、予定発電量演算部１１４は、起床予定時刻から外出予定時刻までの期間の使用パターンを在宅非就寝パターン、外出予定時刻から帰宅予定時刻までの期間の使用パターンを不在パターン、帰宅予定時刻から就寝予定時刻までの期間の使用パターンを在宅非就寝パターン、それ以外の期間の使用パターンを就寝パターン、として決定する。図４に示される予定情報保持部１０８の例では、予定発電量演算部１１４は、時間帯「２２：３０〜２３：００」におけるユーザサイト「Ａ」の予定としての使用パターンを「在宅非就寝パターン」に決定し、ユーザサイト「Ｂ」、「Ｃ」、「Ｄ」の予定としての使用パターンを「就寝パターン」に決定する。
【００５１】
予定発電量演算部１１４は、決定された予定としての使用パターンに基づいて対象日の各時間帯における予定発電量を演算する。ある時間帯において在宅非就寝パターンを予定しているユーザサイトの割合が大きいと、その時間帯における予定発電量は大きくなる。また不在パターンを予定しているユーザサイトの割合が大きい時間帯の予定発電量は小さくなる。各使用パターンの割合に基づく予定発電量の演算は、公知の発電計画の技術を使用して実現されてもよい。また、予定発電量演算部１１４は、特許文献１に示されるように各ユーザサイトの蓄電装置の充放電を制御する前提で予定発電量を演算してもよい。
【００５２】
予定発電量演算部１１４は演算により得られた予定発電量を予定発電量保持部１１０に登録する。
予定発電量通知部１１６は、予定発電量保持部１１０を参照して対象日の各時間帯の予定発電量を含む予定発電量情報を生成し、生成された予定発電量情報をネットワーク１６を介して発電所６に送信する。発電所６は、受信した予定発電量情報に基づき対象日の発電計画を作成してもよい。
【００５３】
リアルタイム処理部１０４は、切替情報取得部１１８と、パターン異同判定部１２０と、発電変更判定部１２２と、予定発電量修正部１２４と、修正通知部１２６と、サイト機器制御部１２８と、を含む。
【００５４】
切替情報取得部１１８は、各ユーザサイトについて、ユーザサイトにおける電力の使用パターンの切り替わりを示す切替情報をネットワーク１６を介して随時取得する。切替情報は、対象日当日の使用パターンの切り替わりをリアルタイムで示す情報である。特に切替情報はユーザの起床を示す情報、ユーザの外出を示す情報、ユーザの帰宅を示す情報、またはユーザの就寝を示す情報のいずれかひとつを含む。切替情報は、ユーザサイトのユーザが使用するユーザ端末に対するユーザの入力に基づきユーザ端末において生成される。そのようなユーザ端末の例は上記したものの他に、起床／在宅／不在／就寝通知用専用端末や電子鍵や人感センサなどである。これらの装置はネットワーク１６を介して制御装置１００と通信可能に構成される。ユーザ端末が携帯端末である場合の例が図７、図８、図９、図１０を参照して後述される。
【００５５】
切替情報取得部１１８は、取得された切替情報に基づいてユーザ情報保持部１０６に登録されているユーザサイトの実際の使用パターンを更新する。特に切替情報取得部１１８は以下の表に示される規則にしたがって実際の使用パターンを更新する。
【表１】
2014095947.tif 000003
なお、実際の使用パターンは切替情報が取得されると変更されるので、実際の使用パターンは、少なくとも切替情報取得部１１８によって切替情報が取得されるか否かに基づき決定されるものである。
【００５６】
パターン異同判定部１２０は、対象日当日に所定の時間間隔、例えば１０分間隔で、各ユーザサイトの実際の使用パターンと予定としての使用パターンとの異同を判定する。パターン異同判定部１２０は予定情報保持部１０８を参照し、各ユーザサイトの現時点での予定としての使用パターンを決定する。パターン異同判定部１２０は、予定発電量演算部１１４において使用される各時刻と使用パターンとの関係と同様の関係を使用して使用パターンを決定してもよい。パターン異同判定部１２０は、各ユーザサイトについて、決定された現時点での予定としての使用パターンと、ユーザ情報保持部１０６によって保持される現時点での実際の使用パターンと、の異同を判定する。
【００５７】
パターン異同判定部１２０は、登録されている複数の、例えば全てのユーザサイトに亘って実際の使用パターンと予定としての使用パターンとの異同を判定することによって、以下の４つの割合を算出する。
（１）予定としての使用パターンと実際の使用パターンとが異なるユーザサイトの割合（以下、第１割合と称す）。なお、この第１割合は、（予定としての使用パターンと実際の使用パターンとが異なるユーザサイトの数）／（ユーザサイトの総数）として定義される。以下に示される割合も同様である。
（２）予定としての使用パターンの電力の平均使用量が実際の使用パターンの電力の平均使用量よりも小さいユーザサイトの割合（以下、第２割合と称す）。そのようなユーザサイトは、例えば予定としての使用パターンが就寝パターンでありながら実際の使用パターンが在宅非就寝パターンであるユーザサイトである。
（３）予定としての使用パターンの電力の平均使用量が実際の使用パターンの電力の平均使用量よりも大きいユーザサイトの割合（以下、第３割合と称す）。そのようなユーザサイトは、例えば予定としての使用パターンが在宅非就寝パターンでありながら実際の使用パターンが不在パターンであるユーザサイトである。
【００５８】
発電変更判定部１２２は、パターン異同判定部１２０における判定結果に基づいて、予定発電量保持部１１０によって保持される予定発電量を変更すべきか否かを判定する。特に発電変更判定部１２２は、パターン異同判定部１２０によって算出される第１割合、第２割合または第３割合が所定のしきい値を上回る場合、対象日における現時点より先の時間帯の予定発電量を変更すべきであると判定する。
【００５９】
予定発電量の変更の態様は、少なくとも以下の２つを含む。
（１）パターン異同判定部１２０によって算出される第２割合が第１しきい値を上回る場合、発電変更判定部１２２は先の時間帯の予定発電量を増やすべきであると判定する。予定発電量修正部１２４は、発電変更判定部１２２においてそのように判定されると、先の時間帯に対応する予定発電量が増えるように予定発電量保持部１１０を更新する。
（２）パターン異同判定部１２０によって算出される第３割合が第２しきい値を上回る場合、発電変更判定部１２２は先の時間帯の予定発電量を減らすべきであると判定する。予定発電量修正部１２４は、発電変更判定部１２２においてそのように判定されると、先の時間帯に対応する予定発電量が減るように予定発電量保持部１１０を更新する。
【００６０】
修正通知部１２６は、予定発電量修正部１２４において予定発電量の修正が発生した場合、予定発電量保持部１１０を参照して修正内容を含む発電量修正情報を生成する。修正通知部１２６は、生成された発電量修正情報をネットワーク１６を介して発電所６に送信する。発電所６は、修正された予定発電量に基づき発電を行ってもよい。
【００６１】
サイト機器制御部１２８は、制御装置１００を使用して提供されるＤＲアグリゲーションサービスにおける、ユーザサイトに設置されている各種電気機器の制御を担当する。特許文献１に示されるように各ユーザサイトの蓄電装置の充放電を制御する前提で予定発電量が演算されている場合、サイト機器制御部１２８は適切な指令情報を生成し、生成された指令情報をネットワーク１６を介して対象の蓄電装置やホームサーバやスマートメータに送信する。この際、サイト機器制御部１２８はユーザ情報保持部１０６に登録されているＩＰアドレスを利用してもよい。
【００６２】
サイト機器制御部１２８は、修正された予定発電量に基づいて、ユーザサイトの蓄電装置の充放電を制御してもよい。例えば、サイト機器制御部１２８は、修正の結果予定発電量が増える場合は、増分を蓄電装置からの放電で補うよう制御してもよい。
【００６３】
サイト機器制御部１２８は、制御対象の電気機器を備えているユーザサイトの実際の使用パターンをユーザ情報保持部１０６から抽出する。サイト機器制御部１２８は、抽出された実際の使用パターンが不在パターンであることを条件のひとつとして、制御対象の電気機器をネットワーク１６を介して制御する。制御対象の電気機器がエアコンや照明である場合、発電所６側から電力需給の逼迫が伝えられると、サイト機器制御部１２８は不在パターンとなっているユーザサイトのエアコンや照明の電源が入っていればそれをオフにする制御を実行する。このように、ユーザが不在のときには電気機器の制御権をＤＲアグリゲータ側に渡すことによって、ユーザに過度の不便さを感じさせることなく適切な電力需要制御を実現できる。
【００６４】
ポイント処理部１３０は、ユーザ情報保持部１０６によって保持される各ユーザサイト（各ユーザ）のエコポイントの増減処理を行う。エコポイントは、ユーザサイトのユーザがどの程度予定通りに電力を使用しているかを示す指標である。ポイント処理部１３０は、パターン異同判定部１２０において使用パターンが異なると判定されたユーザサイトのエコポイントを減算処理し、使用パターンが同じであると判定されたユーザサイトのエコポイントを増加処理する。これにより、ユーザが予定通りに電力を使用するほどエコポイントが増えていく。このエコポイントは金銭や物品と適切な交換レートで交換可能とされてもよい。この場合、ユーザに予定通りに電力を消費するよう促すことができ、発電計画と実態との乖離を抑制することができる。
【００６５】
図６は、制御装置１００におけるリアルタイム制御を説明するための模式図である。ユーザサイト「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」における予定としての使用パターンは図４に示される各時刻に対応する。右下がりの斜線はユーザサイトの電力の使用パターンが在宅非就寝パターンである期間を示し、左下がりの斜線はユーザサイトの電力の使用パターンが不在パターンである期間を示し、横線はユーザサイトの電力の使用パターンが就寝パターンである期間を示す。
【００６６】
現時点「２２：３０」（図６中では太い縦線で示される）におけるパターン異同判定部１２０の判定結果は、ユーザサイト「Ａ」、「Ｄ」については「同じ」、ユーザサイト「Ｂ」、「Ｃ」については「異なる、実際の方が平均使用量が多い」となる。そしてユーザサイト「Ｂ」、「Ｃ」と同様の判定結果を示すユーザサイトの割合が第１しきい値を上回る場合、発電変更判定部１２２および予定発電量修正部１２４の作用により時間帯「２３：００〜２３：３０」の予定発電量が増やされる。
【００６７】
ＤＲアグリゲーションサービスを運営するＤＲアグリゲータは、インターネット上のダウンロードサイトや自己のウェブサイトに通知用アプリケーションプログラムをアップロードする。ユーザは自己の携帯端末に通知用アプリケーションプログラムをダウンロードする。通知用アプリケーションプログラムは携帯端末にインストールされる。通知用アプリケーションプログラムは、電力予定情報を生成して制御装置１００にネットワーク１６を介して送信する機能と、切替情報を生成して制御装置１００にネットワーク１６を介して送信する機能と、を携帯端末に実現させる。
【００６８】
図７は、通知用アプリケーションプログラムを実行する携帯端末のタッチパネルに表示されるログイン画面２００の代表画面図である。ログイン画面２００は、ユーザＩＤの入力を受け付けるユーザＩＤ入力領域２０２と、パスワードの入力を受け付けるパスワード入力領域２０４と、送信ボタン２０６と、を有する。ユーザはユーザＩＤ入力領域２０２に自己のユーザＩＤを入力し、パスワード入力領域２０４に対応するパスワードを入力する。ユーザが送信ボタン２０６をタップすると、携帯端末は、ユーザＩＤ入力領域２０２に入力されたユーザＩＤとパスワード入力領域２０４に入力されたパスワードとを含むログイン認証情報を生成する。携帯端末は、生成されたログイン認証情報をネットワーク１６を介して制御装置１００に送信する。事前処理部１０２は、受信したログイン認証情報に含まれるユーザＩＤおよびパスワードと、ユーザ情報保持部１０６に登録されているユーザＩＤおよびパスワードと、を照合することにより所定の認証処理を行う。事前処理部１０２は、認証結果をネットワーク１６を介して携帯端末に送信する。携帯端末は、認証結果が失敗である場合、エラーを示す画面をタッチパネルに表示させる。携帯端末は、認証結果が成功である場合、メニュー画面２０８をタッチパネルに表示させる。
【００６９】
図８は、メニュー画面２０８の代表画面図である。メニュー画面２０８は、電力予定情報を生成、送信するためのメニューの指定を受け付ける明日の電気予約指定領域２１０と、切替情報を生成、送信するためのメニューの指定を受け付けるチェックイン指定領域２１２と、広告を表示する広告表示領域２１４と、を有する。
【００７０】
ユーザが明日の電気予約指定領域２１０をタップすると、携帯端末は電気予約受付画面２１６をタッチパネルに表示させる。
図９は、電気予約受付画面２１６の代表画面図である。電気予約受付画面２１６は、起床予定時刻の入力を受け付ける起床予定時刻入力領域２１８と、外出予定時刻の入力を受け付ける外出予定時刻入力領域２２０と、帰宅予定時刻の入力を受け付ける帰宅予定時刻入力領域２２２と、就寝予定時刻の入力を受け付ける就寝予定時刻入力領域２２４と、送信ボタン２２６と、広告表示領域２１４と、を有する。
【００７１】
ユーザは、起床予定時刻入力領域２１８、外出予定時刻入力領域２２０、帰宅予定時刻入力領域２２２、就寝予定時刻入力領域２２４のそれぞれに、対象日である明日の起床予定時、外出予定時刻、帰宅予定時刻、就寝予定時刻を入力する。この入力は３０分単位のプルダウン形式で行われてもよい。ユーザが送信ボタン２２６をタップすると、携帯端末は、起床予定時刻入力領域２１８、外出予定時刻入力領域２２０、帰宅予定時刻入力領域２２２および就寝予定時刻入力領域２２４に入力された情報を含む電力予定情報を生成する。携帯端末は、生成された電力予定情報をネットワーク１６を介して制御装置１００に送信する。電力予定情報取得部１１２はこの電力予定情報を取得する。
【００７２】
メニュー画面２０８においてユーザがチェックイン指定領域２１２をタップすると、携帯端末は、ユーザサイトにおける使用パターンの切り替わりに対応するイベントの発生の通知をユーザから受け付ける通知受付画面２２８をタッチパネルに表示させる。そのようなイベントは例えばユーザの起床や外出や帰宅や就寝である。
【００７３】
図１０は、通知受付画面２２８の代表画面図である。通知受付画面２２８は、ユーザの起床の通知に対応する起床ボタン２３０と、ユーザの外出の通知に対応する外出ボタン２３２と、ユーザの帰宅の通知に対応する帰宅ボタン２３４と、ユーザの就寝の通知に対応する就寝ボタン２３６と、広告表示領域２１４と、を有する。ユーザが起床ボタン２３０をタップすると、携帯端末はユーザの起床を示す情報を含む切替情報を生成する。携帯端末は、生成された切替情報をネットワーク１６を介して制御装置１００に送信する。切替情報取得部１１８はこの切替情報を取得する。外出ボタン２３２、帰宅ボタン２３４、就寝ボタン２３６についても同様である。
【００７４】
以上の構成による制御装置１００の動作を説明する。
図１１は、制御装置１００における事前処理に係る一連の処理を示すフローチャートである。制御装置１００は、各ユーザサイトのユーザから電力予定情報を取得する（Ｓ３０２。制御装置１００は、取得された電力予定情報に基づいて、対象日における予定発電量を演算する（Ｓ３０４）。制御装置１００は、演算の結果得られた予定発電量を発電所６にネットワーク１６を介して通知する（Ｓ３０６）。
【００７５】
図１２は、制御装置１００におけるリアルタイム処理に係る一連の処理を示すフローチャートである。制御装置１００は、対象日において使用パターンのチェックを行うべき時刻が到来する前に切替情報を取得した場合（Ｓ３０８のＹ）、取得された切替情報に基づいて、ユーザ情報保持部１０６に登録されている実際の使用パターンを更新する（Ｓ３１０）。そのような切替情報を取得せずにチェックを行うべき時刻が到来した場合（Ｓ３０８のＮ）または実際の使用パターンの更新後にその時刻が到来した場合、制御装置１００は、各ユーザサイトについて、現時点での実際の使用パターンと予定としての使用パターンとの異同を判定する（Ｓ３１２）。制御装置１００は、それらが異なると判定されたユーザサイトの割合がしきい値以上である場合（Ｓ３１４のＹ）、将来の時間帯における予定発電量を修正する（Ｓ３１６）。制御装置１００は、修正された予定発電量をネットワーク１６を介して発電所６に通知する（Ｓ３１８）。制御装置１００は、異なると判定されたユーザサイトの割合がしきい値より小さい場合（Ｓ３１４のＮ）、上記修正処理を行わない。
【００７６】
上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【００７７】
本実施の形態に係る制御装置１００によると、ユーザからの電力使用量の予約に基づいて発電計画を作成するサービスにおいて、ユーザサイトにおける実際の使用パターンと予定としての使用パターンとの乖離を監視することができる。そしてこの乖離が大きい場合、発電計画はリアルタイムで修正される。したがって、予約に基づく発電計画の最適化を実現しつつ、ユーザの行動の不確定性に起因する電力需要の予定からの乖離にも適切に対応できるサービスが提供される。
【００７８】
例えば、予定よりも多く電力を使用するユーザサイトが多い場合、制御装置１００は予定発電量を増やすことができるし、逆もまたしかりである。したがって、ユーザサイト側のリアルタイムの状況に応じて発電所６における発電量をきめ細かく調整できる。特に、無駄な発電や蓄電池からの放電を抑制できる。
【００７９】
また、本実施の形態に係る制御装置１００ではユーザから得られる情報に基づき実際の使用パターンを決定する。ここで現在どの使用パターンであるかについてユーザに逐一報告を求めることとすると、ユーザ側の負担が大きくなる可能性がある。そこで本実施の形態に係る制御装置１００では、リアルタイム処理においてユーザから切替情報を受け付けて実際の使用パターンを更新し、この実際の使用パターンと予定としての使用パターンとの異同を判定する構成とされている。したがって、ユーザは使用パターンそのものではなくその切り替わりに関する切替情報を制御装置１００に通知するので、通知の回数を低減することができ、ユーザ側の負担を低減できる。
【００８０】
一般に、発電計画において重要なことのひとつに、電力需要量が電力供給量を上回らないことがある。電力需要量が電力供給量を上回ると、配電網１８や発電所６に予期せぬ負担が発生し、電力の安定的な供給に支障が出る虞がある。そこで本実施の形態に係る制御装置１００は、予定よりも多く電力を使用するユーザサイトの割合が大きい場合、予定発電量を増やすように修正する。これにより、電力需要量が電力供給量を上回らないことをより確実にすることができる。
【００８１】
また、本実施の形態に係る制御装置１００によって提供されるサービスでは、切替情報や電力予定情報は、ユーザの携帯端末にインストールされる通知用アプリケーションプログラムによって生成、送信される。したがって、ユーザサイトに通知用の専用端末を設けたりスマートメータに通知機能を組み込む場合よりも、ユーザによる通知作業を簡易化、低コスト化することができる。その結果、ユーザは本サービスに参加しやすくなる。
【００８２】
また、通知用アプリケーションプログラムは通知受付画面２２８に広告表示領域２１４を含める。通知受付画面２２８はその性質上ユーザが一日に何回も開く画面であるから、広告表示領域２１４に表示される広告の広告効果を高めることができる。
【００８３】
以上、実施の形態に係る制御装置１００の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００８４】
実施の形態では、電力予定情報および切替情報を同じ携帯端末が生成する場合について説明したが、これに限られず、例えば電力予定情報はスマートメータで生成、送信される一方、切替情報は携帯端末によって生成、送信されてもよい。電力予定情報、切替情報はいずれもユーザサイトのユーザが使用する何らかの端末からユーザの入力によって生成、送信されてもよいし、人感センサなどのように自動的に生成、送信されてもよい。
【００８５】
実施の形態において、リアルタイム処理部１０４は、ユーザに対して各時刻の到来に関連する通知を実行してもよい。例えば、リアルタイム処理部１０４は、ユーザの外出予定時刻の数分前にユーザの携帯端末のアラームを起動したり、ユーザの携帯端末にアラートメールを送信してもよい。この場合、ユーザに予定通りの行動を促すことで、予約と実際との乖離をさらに抑えることができる。
【００８６】
実施の形態において、予定情報保持部１０８によって保持される各時刻は随時更新可能であってもよい。制御装置１００は、対象日より前であっても対象日当日であっても、予定情報保持部１０８に保持される各時刻の変更をユーザから受け付け可能に構成されてもよい。このような予約変更機能が実装されている場合、実施の形態に係るリアルタイム在宅情報は予約変更機能を補完する位置づけであってもよい。
【００８７】
実施の形態では、通知用アプリケーションプログラムはユーザＩＤおよびパスワードによる認証が成功した場合に電気予約やチェックインを可能とする場合について説明したが、これに限られない。例えば、ＱＲコード（登録商標）などの二次元バーコードを使用した認証が用いられてもよい。
【００８８】
本発明者は、制御装置１００に切替情報を通知するための手段について、以下の認識を有する。スマートメータには、ルート・セグメントが存在する。Ａルートは家の外の電力会社とやりとりするルートであり、電力等通信ネットワーク、Ｗｅｂ経由で取得するものである。Ｂルートは家の中を司るルートであり、メータから直接取得するものである。Ｃルートは第三者を介して取得するルートであり、インターネット経由になる。（なお、Ａルートは電力会社が集約した電力情報をインターネット経由で家庭などが受け取るルートであり、Ｂルートはメータに直接ＨＥＭＳを接続して電力情報を受け取れるルートであり、Ｃルートは第三者経由で電力情報を受け取るルートである、という考え方もある。）
【００８９】
Ａルートに流れる情報はパブリック・アプリケーションが中心であり、公共性・公益性が高いものになる。現状、住宅内にかかる諸情報等はＨＥＭＳを介したＢルートに包含されて検討されているようであるが、本来リアルタイム在宅情報は、最適化発電に有益となる重要な情報なので、Ａルートによるダイナミックな情報取得が望ましい。ＤＲアグリゲータや発電所はそれらデータを集めて、ダイナミック管理することにより発電効率を向上させることができる。
【００９０】
また、現状、スマートメータのスペックや通信ネットワークの容量を考慮して、３０分刻みでローカル情報を吸い上げる仕様が検討されているが、携帯電話やスマートフォンを介したパケット通信なら、スマートグリッド系通信ネットワークに縛られることのない、自由闊達な情報の伝授が可能である。
【００９１】
実施の形態では、主に契約者とサービス提供者との合意の下での、契約者による自発的な情報伝達方法について説明したが、これに限られない。例えば、契約者の生活上、無意識な行動の中での物理的な情報取得と情報伝達方法が用いられてもよい。この場合、ＧＰＳ機能を使って、自宅や会社をマーキングしておき、レジストリされているマークと一致したら、通知するシステムを構築してもよい。これにより、主に出発と帰宅の２種類の信号を得ることができる。これに関し、例えば株式会社野村総合研究所が提供する「全力案内」というサービスを利用して、シームレスに自動通知する機能を実現してもよい。
【００９２】
以下、実施の形態についての本発明者の発想の根拠を説明する。
バッテリ（電池）には２つの定義がある。一つは、アクティブに作動するものであり、それはジェネレータ的運用を指す。もう一つは、パッシブに作動するものであり、それはバッファ的運用を指す。
【００９３】
基本的にバッファとして活用される場合、そのバッテリは化学反応を生じないモデルが多い。なぜなら、すぐ欲しい、と即効性が求められる運用によるからである。若干の電気の猶予があればバッファとしての運用は満たされる。キャパシタなどは、電荷のまま保持しているので化学反応を行わない。
【００９４】
一方、ジェネレータとして作動する運用の場合、例えば、ＮＡＳ（ナトリウム・硫黄電池）などは化学反応を要する性格を持っている場合が多い。大きな発電量を求められるが即効性に関しては高い要求はない。
【００９５】
上記は、例えば、携帯電話の電源供給方式にもマッピングが可能と思われる。一口に携帯電話の電源といってもその電力供給構造モデルは、利用するタイミング、頻度、使用量に応じてタイプが分かれている。
【００９６】
最初の入り口となる電源口は充電器が備えられ、ここにはその利用容量に応じた電解コンデンサ（携帯電話の電源供給装置としてはもっとも大型）が搭載されている。
次に、携帯電話の電池の電力供給は、その使用電力量に応じで、バッファされた供給電力源（中型コンデンサ）を持っている。
携帯電話コンポーネントの最小部位としては、数十を超える多くのマイコンや、メモリが搭載されており、マイコンの中にある小さなクオーツは最小電力により且つ高周波で動いている。これらマイコンは、逐次電源を主電源に取りに行くのではなく（電源供給が間に合わない）、マイコンの脇に設置された（小型）タンタルコンデンサから供給されている。
【００９７】
すなわち、スマートグリッドも上記と同様の利用するタイミング、頻度、使用量に応じたきめ細かい電力供給運用が求められるのではないか、と思われる。
【００９８】
さらに、ストレージの世界にも同様の概念・運用モデルがある。ＲＰＯ（目標復旧ポイント）やＲＴＯ（目標復旧時間）である。
図１３は、ユーザサイトにおける各種時刻とＲＴＯ／ＲＰＯの概念との対応を説明する説明図である。図１３において、「バッファ」は電力使用量が変化する調整帯域を表しており、例えば「インバーター」が動くような場合が相当する。「アイドリング」は「バッファ」状態が間延びしている状態であり、いつ使われるか分からない電気を発電しているか、または１次エネルギとして燃焼しているが、２次エネルギ（電気）に変えていない期間を表す。例えば、発電機エンジンは起動中であるが、トランスミッションはニュートラルの状態が相当する。
【００９９】
ＲＰＯは、需要家における起床時、外出時、帰宅時、就寝時に電力利用量の大幅変動が発生する電力変動の予定時刻に対応する。ＲＰＯは、電力を供給するにあたり、大きな電力使用変動が生じる時刻の指標（いつの時点に発生するか）であってもよい。ディザスターが発生するタイミングは、実際の電源スイッチのオン・オフが発動するトリガーやフラグとして、つまり外出から帰宅したタイミング、出かけるタイミングというリアルな実績時刻に対応する。
【０１００】
ＲＴＯは、電力需要の変動に対する供給側の適応所要時間に対応する。例えば、需要家の電力需要拡大が生じた場合、細分化された各々蓄電池から放電を行う運用が考えられるが、ＮＡＳや燃料電池のような化学反応タイプであると電気が生成されるまで時間が必要になる。また、ＲＴＯは、電力を供給するにあたり、使用電力ピークや待機電力モードに合わせた発電機や蓄電池のオン／オフなど、電力供給最適化調整に要する最大の期間の長さに対応してもよい。
【０１０１】
さらに、携帯電話にマッピングすれば、需要家（携帯電話ユーザ）による電源スイッチのオンオフ行為がディザスター・タイミングとなり、フル充電が終了した時刻がＲＰＯとなる。充電時間はＲＴＯに対応する。
【０１０２】
このように、電力需要家による予約情報を取得するだけでなく、需要家から予約に基づいたこれから始まる電力利用変動が生じるタイミング、言い換えれば、供給側が需要家の外出／帰宅の所在通知をリアルタイムに入手することは、繊細な電力供給制御に大変役立つ。
【０１０３】
また、ＲＰＯ的フラグ、またはディザスター・タイミング的トリガーに相当するのは、１日２４時間のうち少なくとも４度認められる。
１．  （第１起床者）起床時
２．  （最終外出者）外出時、または工場・オフィス操業開始時
３．  （第一帰宅者）帰宅時、または工場・オフィス操業停止時
４．  （最終就眠者）就眠時、または工場・オフィス休憩時、休業時
【０１０４】
発電所側、ＤＲアグリゲータへの通知方法についてさらに説明する。
一般的に、これら通知手段としてはＨＥＭＳ（home energy management system）を利用するのが望ましい。需要家サイドに設置されたＨＥＭＳのディススプレイ端末から、その他の省エネ・節電を促進する各種監視情報と併用して送ることができる。さらには、需要家サイドにローカルな蓄電池が設置されている場合は、そのＨＥＭＳ経由で蓄電池連動制御も可能なのでシステム運用上効率がよい。しかしながら、ＨＥＭＳは本格的な普及がこれからであり、現状の導入に当たってはそのハードウェア費用が大きな足かせになっている。
【０１０５】
また、スマートメータから実績データ送信時に付けて送信する方法もあるが、現在、スマートメータはそのような仕様には至っていない。
【０１０６】
各企業においてはＢＥＭＳ（Building and Energy Management System）を使ってエスカレーションを行うという運用が考えられるが、混在している各ＢＥＭＳのプレーヤの情報を収集・集約して、全体としての最適化マネジメントを図る動きはまだない。
【０１０７】
したがって、現状では、需要家側に既に広く遍く普及しているネットワーク網を活用するのがもっとも早道であり、それらを実現するインフラがスマートフォンなどの携帯電話、並びに携帯電話網である。携帯電話を活用するメリットとしては、既に社会インフラとして各需要家サイドに認知されており、運用上、その取り扱いや操作性において混乱を生じさせるリスクは少ない。また、通知に必要なアプリケーションをダウンロート゛する（させる）ことで、直ちにサービス参加出来る気軽さも兼ねている。アプリケーション費用やダウンロード費用について、広告媒体や協賛広告会社をサービスに参画させることで、需要家側の負担を削減もしくは無くすことができる。
【０１０８】
さらに、携帯電話を採用すれば、在宅通知だけでなく、予約行為そのものも行うことが可能だし、場合によっては、あながち発生しやすいスケジュール変更に伴う予約変更等をダイナミックにできるツールである。将来的には、フェリカ（登録商標）のような非接触型カード、カード型自宅鍵、警備会社カード（ＢＥＭＳ経由）等で信号を発信することは可能だが、まずは今直ちに立ち上がるソリューションとして携帯電話を活用することが最も速く確実である。
【０１０９】
需要家に向けた説明、参画へのモチベートについて説明する。
実施の形態に係るモデルにおける実際の運用は、需要家側の新たな報告負担を求めるものであるが、省エネ・節約が人類の社会的責務になりつつある昨今、それら供給側の省エネ運用に需要家自ら寄与することは彼らに取っても望ましいことであるし、さらには、それら通知というアクション行為に別途省エネ貢献ポイント（もしくは低廉電気料金）が付与・提供されるなど、需要家の新たな利益に繋がるサービス設計が施されるのであれば、十分理解されうる運用である。
【０１１０】
近年、ＨＥＭＳ通信のプロトコルの標準化（例えば、Econet lite）が進んでいる。２０１２年２月に国内標準化プロトコルとして合意され、各ＨＥＭＳ関連メーカが相互動作保証を行うおおよその規格が決まった。コンソーシアム全体的には、需要家にさらに運用負担をかけるという発想ではなく、エンドユーザにあまり負担をかけない自動監視、自動制御の方向を進展させるという流れで進んでいるようである。無論、完全自動化が出来ればそれが望ましい。しかしながら、本発明者は、自由気ままに勝手に動く需要家のニーズに合わせて発送電するのはかなり困難であると考える。
【０１１１】
ストレージのＲＰＯは最終的にはエンドユーザが取り決める事柄であり、システム側が勝手に決めることではない。つまり、ストレージの世界でもＲＰＯを自動化することは困難である。それと同じことがスマートグリッドの世界にも言える。エネルギ効率を考えた場合、需要家が供給システムに、予約や帰ってきた／出掛けたフラグを通知するのはあってしかるべきマナーであるという考え方もある。交通規則に赤や青があるように、電気にもそれ相当の運用が求められる。
【０１１２】
スマートメータは基本的には早くて３０分毎に情報収集が出来るが、これは発電側と需要家側でおおよそ３０分の誤差が生じる可能性があることを意味している。例えば、共働きの家庭が自宅へ帰宅するのは１８：００〜２０：００の間が多い。そして、寝るのはだいたい２２：００〜翌１：００の間である。そして、この５時間の間に１日の電力需要が最大値になるのが一般的な共働き家庭である。約３０分の誤差が帰宅時、就寝時で発生した場合、最大１時間の供給ロスが生じる計算になる。これは比較的大きなロス・マージンである。
【０１１３】
また、電力予約と実際の運用との差分を「予約変更受付」という形で、最小化する方法も考えられる。しかしながら、変更が非定期的であるので需要家サイドに運用を徹底するのは困難であろう。また、予約変更のクオリティ感覚も需要家によってまちまちである。例えば１０分単位や１時間単位など人によってまちまちである。したがって、予約情報と実際の運用差分を、予約変更機能だけで穴埋めしようとするのは難しいと思われる。
【０１１４】
そこで、実施の形態は、帰ってきたら、玄関の照明を付けるのと同じ感覚で「これから予約通り、電気を使いますよ」と携帯端末の帰宅ボタンを押して切替情報を送信する運用を採用する。これはより自然な行為であり、習慣づけば、毎日、どの家庭からでも情報を取得することが可能となる。
【０１１５】
より望ましいのは、ホテルの鍵の運用と同様に、帰宅や出勤時に、キーを差し込んだり抜いたりすることで待機電源から５０Ａや６０Ａに変更する仕組みである。これは、需要家側にキーを差し込んだり抜いたりするアクションを要請して、電力使用制限を強要する運用であるといえる。スマートメータをそのようなキーの抜き差しに対応できるよう変更してもよい。または、玄関の出入り口にボタンを設置しておくことも考えられる。また、予約開始時間が来たら、送電圧を強制的に待機電源分まで落として、その後、ユーザに自分で復旧させるという運用も可能である。例えば、６０Ａを１０Ａに落としてもよい。
【０１１６】
また、部屋に赤外線センサのような人体反応センサを設置する運用も考えられる。しかしながらこの場合、犬や猫などのペットを飼っている場合、無人なのにセンサが反応してしまう状況が発生しうる。また、睡眠中や病気等で寝込んでいる場合など需要家の動作が少ない場合、有人なのにセンサが反応しないことも生じうる。人が在宅なのにリモートで勝手に制御する方式はこれらの点で改善が必要である。実施の形態では、「いる、いない」はユーザからの申告に基づき登録される。したがって、より安全かつ確実である。なお、警備会社のセキュリティも「警備セット」はユーザが行う申告制となっていることからも、この安全性、確実性が推認される。
【符号の説明】
【０１１７】
２  電力供給システム、  ４  データセンタ、  ６  発電所、  １６  ネットワーク、  １８  配電網、  １００  制御装置、  １０２  事前処理部、  １０４  リアルタイム処理部、  １１２  電力予定情報取得部、  １１４  予定発電量演算部、  １１８  切替情報取得部、  １２２  発電変更判定部、  １２８  サイト機器制御部。
【図１】
2014095947.tif 000004
【図２】
2014095947.tif 000005
【図３】
2014095947.tif 000006
【図４】
2014095947.tif 000007
【図５】
2014095947.tif 000008
【図６】
2014095947.tif 000009
【図７】
2014095947.tif 000010
【図８】
2014095947.tif 000011
【図９】
2014095947.tif 000012
【図１０】
2014095947.tif 000013
【図１１】
2014095947.tif 000014
【図１２】
2014095947.tif 000015
【図１３】
2014095947.tif 000016