(57)【特許請求の範囲】
【請求項１】
ネットワークを介してサーバと接続され、負荷装置の電力需要の制御を行う制御装置であって、
前記サーバと前記制御装置とが通信可能であるか否かを判定する判定部と、
予め定められたスケジュールに従って前記負荷装置の電力需要を制御する第一モード、及び、前記サーバからの指令信号に従って前記負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する制御部とを備え、
前記制御部は、
前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定部が判定した場合に、前記動作モードを前記第一モードに切り替えて前記制御を行い、
前記電力需要の制御は、前記電力需要を抑制することを終了する復帰制御を含み、
前記制御部は、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定部が判定した場合であっても、前記指令信号である復帰信号であって前記復帰制御を行う旨を示す信号である復帰信号を受信する時刻を予測可能である場合に、前記第二モードを維持して前記負荷装置を制御する
制御装置。
【請求項２】
前記制御部は、
前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能であると前記判定部が判定した場合に、前記第二モードを維持して前記制御を行う
請求項１に記載の制御装置。
【請求項３】
前記電力需要の制御は、さらに、
前記電力需要を抑制することを開始する開始制御を含む
請求項１又は２に記載の制御装置。
【請求項４】
前記判定部は、
前記サーバとの通信可否を確認するための確認信号を前記サーバに送信し、前記確認信号に応じて前記サーバが送信した応答信号を受信した場合に、前記サーバとの通信が可能
であると判定する
請求項１〜３のいずれか１項に記載の制御装置。
【請求項５】
前記制御装置は、さらに、
前記第一モードで前記制御を行う場合のスケジュールであって、前記電力需要を抑制することを開始する開始時刻と、前記電力需要を抑制することを終了する復帰時刻とを含むスケジュールを、前記制御を行う前に前記サーバから前記スケジュールとして取得する取得部を備える
請求項１〜４のいずれか１項に記載の制御装置。
【請求項６】
前記制御部は、さらに、
前記第二モードから前記第一モードへ切り替えた後に、前記サーバとの通信が可能であると前記判定部が判定した場合に、前記指令信号の１つである復帰信号を前記サーバが送信済みか否かを前記サーバに問い合わせ、
前記サーバが前記復帰信号を既に送信済みである場合には、前記動作モードを前記第二モードに切り替えて前記制御を行う
請求項１〜５のいずれか１項に記載の制御装置。
【請求項７】
前記制御装置は、さらに、
予め定められたスケジュールに従って前記制御装置が前記制御を行う第一電力サービス、及び、前記サーバからの指令信号に従って前記制御装置が前記制御を行う第二電力サービスのいずれか一方を、ユーザからの指示に基づいて選択するサービス選択部を備え、
前記制御部は、
前記サービス選択部が前記第一電力サービスを選択した場合に前記第一モードで前記制御を行い、前記サービス選択部が前記第二電力サービスを選択した場合に前記第二モードで前記制御を行う
請求項１〜６のいずれか１項に記載の制御装置。
【請求項８】
前記第一電力サービスは、予め定められた時間帯に負荷装置の電力需要を抑制するサービスであるピークカット供給であり、
前記第二電力サービスは、前記サーバからの指令信号に従ったタイミングに負荷装置の電力需要を抑制するサービスである予備力供給、又は、前記サーバからの指令信号に従ったタイミングに前記指令信号に従った電力需要値によって負荷装置の電力需要を制御するサービスである周波数制御である
請求項７に記載の制御装置。
【請求項９】
前記負荷装置は、家庭電化製品、電気自動車、蓄電池、充電器、温水暖房機、冷凍圧縮機、食器洗い機、衣類乾燥機、製氷機、及びスイミングプールポンプのいずれかを含む
請求項１〜８のいずれか１項に記載の制御装置。
【請求項１０】
前記制御部は、さらに、
第二モードにおける前記電力需要の抑制の開始時刻、及び、終了時刻の少なくとも一方を前記サーバから取得した場合に、前記第一モードで前記制御を行うように前記制御を切り替えるとともに、前記少なくとも一方に従って前記負荷装置の電力需要を制御する
請求項１〜９のいずれか１項に記載の制御装置。
【請求項１１】
ネットワークを介してサーバと接続され、負荷装置の電力需要の制御を行う制御装置における制御方法であって、
前記サーバと前記制御装置とが通信可能であるか否かを判定する判定ステップと、
予め定められたスケジュールに従って前記負荷装置の電力需要を制御する第一モード、及び、前記サーバからの指令信号に従って前記負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する制御ステップとを含み、
前記制御ステップでは、
前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定ステップで判定した場合に、前記動作モードを前記第一モードに切り替えて前記制御を行い、
前記電力需要の制御は、前記電力需要を抑制することを終了する復帰制御を含み、
前記制御ステップでは、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定ステップで判定した場合であっても、前記指令信号である復帰信号であって前記復帰制御を行う旨を示す信号である復帰信号を受信する時刻を予測可能である場合に、前記第二モードを維持して前記負荷装置を制御する
制御方法。
【請求項１２】
請求項１〜１０のいずれか１項に記載の制御装置と、サーバとを備える制御システムであって、
前記制御装置の判定部は、前記サーバと通信可能であるか否かを判定する
制御システム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷装置を制御する制御装置、制御方法、及び、制御システムに関する。
【背景技術】
【０００２】
スマートグリッドの発展に伴い、より多くのデマンドレスポンス（ＤＲ（Ｄｅｍａｎｄ  Ｒｅｓｐｏｎｓｅ））リソースがエネルギーシステムにおいて使用されるようになっている（例えば、特許文献１）。そこでは、ＤＲ動作の規模、開始時刻、及び、終了時刻が重要である。したがって、アグリゲータのサーバとローカルＤＲコントローラとの間の通信は、ＤＲの制御の成功に欠かせないものである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第２００８／０２３８７１０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の通信を実現する通信手段に不具合が生ずる可能性がある。通信手段に不具合が生じた場合、適切にＤＲの制御が行われないという問題がある。【０００５】
そこで、本発明は、通信手段に不具合が生じた場合にも適切にＤＲを制御することができる制御装置を提供する。
【課題を解決するための手段】
【０００６】
本発明の一態様に係る制御装置は、ネットワークを介してサーバと接続され、負荷装置の電力需要の制御を行う制御装置であって、前記サーバと前記制御装置とが通信可能であるか否かを判定する判定部と、予め定められたスケジュールに従って前記負荷装置の電力需要を制御する第一モード、及び、前記サーバからの指令信号に従って前記負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する制御部とを備え、前記制御部は、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定部が判定した場合に、前記動作モードを前記第一モードに切り替えて前記制御を行う。【０００７】
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【０００８】
本発明によれば、通信手段に不具合が生じた場合にも適切にＤＲを制御することができる。
【図面の簡単な説明】
【０００９】
【図１Ａ】図１Ａは、実施の形態に基づく制御システムの構成図である。
【図１Ｂ】図１Ｂは、実施の形態に基づく、アグリゲータのサーバとＤＲコントローラとの関係を示す図である。
【図２】図２は、実施の形態に基づく、通信要求によるＤＲ分類を示す図である。
【図３】図３は、実施の形態に基づく、独立運用モードでのＤＲタイプ運用時における通信損失タイミングの一例である。
【図４】図４は、実施の形態に基づく、サーバとＤＲコントローラとのブロック図である。
【図５】図５は、実施の形態に基づく、異なるタイムステップにおける、アグリゲータ及びＤＲコントローラがＤＲコントローラの独立運用を可能にするのに必要な動作を示す図である。
【図６Ａ】図６Ａは、実施の形態に基づく、事前運用動作のシーケンス図である。
【図６Ｂ】図６Ｂは、実施の形態に基づく、サーバのＤＲタイプ変更許可テーブルの一例である。
【図７】図７は、実施の形態に基づく、サーバによる事前運用動作のフローチャートである。
【図８】図８は、実施の形態に基づく、運用時間内のＤＲコントローラによる運用タイプ選択のシーケンス図である。
【図９】図９は、実施の形態に基づく、運用時間内のＤＲコントローラによる運用タイプ選択のフローチャートである。
【図１０】図１０は、実施の形態に基づく、元のＤＲタイプが継続可能な場合における、独立運用モードのＤＲコントローラによる運用時間動作のシーケンス図である。
【図１１Ａ】図１１Ａは、実施の形態に基づく、独立運用モードのＤＲコントローラによる運用時間動作のシーケンス図である。
【図１１Ｂ】図１１Ｂは、実施の形態に基づく、ＤＲコントローラのＤＲタイプ変更許可テーブルの一例である。
【図１１Ｃ】図１１Ｃは、実施の形態に基づく、負荷装置のＤＲタイプ変更許可テーブルの一例である。
【図１２】図１２は、実施の形態に基づく、ＤＲコントローラによる独立ＤＲ運用管理のフローチャートである。
【図１３】図１３は、実施の形態に基づく、ＤＲタイプ変更許可テーブルの作成に関するフローチャートである。
【図１４】図１４は、実施の形態に基づく、ＤＲコントローラ用及び各負荷装置用の「ＤＲタイプ変更許可テーブル」の説明図である。
【図１５】図１５は、実施の形態に基づく、通信復旧時における独立ＤＲ運用管理のフローチャートである。
【図１６】図１６は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第一の説明図である。
【図１７】図１７は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第二の説明図である。
【図１８】図１８は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第三の説明図である。
【図１９】図１９は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第四の説明図である。
【図２０】図２０は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第五の説明図である。
【図２１】図２１は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第六の説明図である。
【図２２】図２２は、実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第七の説明図である。
【図２３】図２３は、関連技術に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第一の説明図である。
【図２４】図２４は、関連技術に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第二の説明図である。
【発明を実施するための形態】
【００１０】
（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、ＤＲの制御方法に関し、以下の問題が生じることを見出した。
【００１１】
上記の通り、アグリゲータのサーバとローカルＤＲコントローラとの間の通信は、ＤＲの制御の成功に欠かせないものである。
【００１２】
しかしながら、上記の通信を実現する通信手段にも不具合があるかもしれない。ＤＲコントローラとアグリゲータのサーバとの間で通信手段が遮断されれば、それにより、ＤＲサービスが中断される。ＤＲサービスの中断は、金銭的な損失をもたらし、信頼性の問題の原因にもなる。
【００１３】
以下、本発明に関連する関連技術を用いて上記の問題について説明する。この説明において、開始信号とは、サーバがＤＲコントローラに送信する信号であって、ＤＲコントローラが負荷装置の電力需要を抑制する制御を開始することを指示するための信号のことである。また、復帰信号とは、サーバがＤＲコントローラに送信する信号であって、ＤＲコントローラが負荷装置の電力需要の抑制を終了し、電力需要を復帰させることを指示するための信号のことである。
【００１４】
図２３は、関連技術に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第一の説明図である。
【００１５】
図２３は、サーバとＤＲコントローラとの通信ができなくなった後に、サーバがＤＲコントローラに開始信号を送信した場合を示す。なお、図においてハッチングで示した部分は、通信が不可能であることを示している。他の図でも同様の表現を用いる場合がある。
【００１６】
この場合、ＤＲコントローラは、サーバからの開始信号を受信することができないので、負荷装置の電力需要を抑制する制御を開始することができない。よって、負荷装置の電力需要が抑制されず、ＤＲの制御が失敗する。
【００１７】
図２４は、関連技術に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第二の説明図である。
【００１８】
図２４は、サーバがＤＲコントローラに開始信号を送信した後に、サーバとＤＲコントローラとの通信ができなくなり、その後、通信ができないときにサーバがＤＲコントローラに復帰信号を送信した場合を示す。
【００１９】
この場合、ＤＲコントローラは、サーバからの開始信号を受信して負荷装置の電力を抑制する制御を開始することができる。しかし、サーバからの復帰信号を受信することがないので、ＤＲコントローラは、負荷装置の電力の抑制を復帰させることができない。よって、ＤＲの制御が失敗し、また、制御後に負荷装置が適切に利用されることができない結果となる。
【００２０】
本発明の一実施の形態では、アグリゲータのサーバ（ＳＯＡ（Ｓｅｒｖｅｒ  ｏｆ  Ａｇｇｒｅｇａｔｏｒ））とＤＲコントローラ（ＤＲＣ（Ｄｅｍａｎｄ  Ｒｅｓｐｏｎｓｅ）  Ｃｏｎｔｒｏｌｌｅｒ）の場合を考える。ＤＲＣは、１構内における複数の負荷装置の運用を制御する。ＤＲＣは、アグリゲータのサーバと通信する。通信が成功すれば、ＤＲＣはアグリゲータのサーバの命令に従う。
【００２１】
しかしながら、通信が失敗すれば、ＤＲＣは単独でＤＲ決定をしなければならない。その決定は、アグリゲータのサーバから命令されるＤＲ運用と、通信せずに行われたＤＲ決定とでその違いが最も小さくなるように行われる。
【００２２】
ＤＲＣが、通信せずに行うタイプのＤＲを続けることができないと判断する場合もある。このような場合には、ＤＲＣは、重要なパラメータを考慮しながら行っていたＤＲタイプを変更する。また、アグリゲータのサーバは、ＤＲ推定データを用意し、それを事前にＤＲＣへ転送しておくべきである。通信が失敗した場合にＤＲＣが行う単独での運用をサポートするため、これは行われるべきである。
【００２３】
つまり、上記の通信を実現する通信手段に不具合が生ずる可能性がある。通信手段に不具合が生じた場合、適切にＤＲの制御が行われないという問題がある。
【００２４】
そこで、本発明は、通信手段に不具合が生じた場合にも適切にＤＲを制御することができる制御装置を提供する。
【００２５】
このような問題を解決するために、本発明の一態様に係る制御装置は、ネットワークを介してサーバと接続され、負荷装置の電力需要の制御を行う制御装置であって、前記サーバと前記制御装置とが通信可能であるか否かを判定する判定部と、予め定められたスケジュールに従って前記負荷装置の電力需要を制御する第一モード、及び、前記サーバからの指令信号に従って前記負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する制御部とを備え、前記制御部は、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定部が判定した場合に、前記動作モードを前記第一モードに切り替えて前記制御を行う。
【００２６】
これによれば、制御装置は、第二モードで負荷装置を制御しているときにサーバとの通信が不可能となった場合に第一モードで制御することができる。制御装置は、第二モードで負荷装置を制御するにはサーバからの指令信号が不可欠であるが、第一モードではサーバからの指令信号なしで負荷装置を制御することができる。つまり、制御装置は、通信が不可能となった場合に、指令信号なしで負荷装置を制御するように変更することで負荷装置の制御を継続することができる。よって、制御装置は、通信手段に不具合が生じた場合にも適切にＤＲを制御することができる。
【００２７】
例えば、前記制御部は、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能であると前記判定部が判定した場合に、前記第二モードを維持して前記制御を行う。
【００２８】
これによれば、制御装置は、サーバとの通信が可能である場合には第二モードを維持して負荷装置を制御することができる。一般に、第一モードで負荷装置を制御するより、第二モードで負荷装置を制御するほうが系統電源を安定させる効果が大きい。よって、制御装置が第一モード及び第二モードのどちらでも負荷装置を制御することができる場合には、第二モードを選択して負荷装置を制御することが望ましい。上記のように制御装置が第二モードを維持して負荷装置を制御するのはこのためである。
【００２９】
なお、第二モードで負荷装置を制御するほうが、ユーザが得られる対価（インセンティブ）も高い。よって、上記のような場合には、第二モードを選択して負荷装置を制御することで、ユーザが得られる対価を多くする効果もある。
【００３０】
例えば、前記電力需要の制御は、前記電力需要を抑制することを開始する開始制御と、前記電力需要を抑制することを終了する復帰制御との少なくとも一方を含む。
【００３１】
これによれば、制御装置は、通信手段に不具合が生じた場合にも適切に電力需要を抑制することを開始又は終了させることができる。
【００３２】
例えば、前記制御部は、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定部が判定した場合であっても、前記指令信号である復帰信号であって前記復帰制御を行う旨を示す信号である復帰信号を受信する時刻を予測可能である場合に、前記第二モードを維持して前記負荷装置を制御する。
【００３３】
これによれば、制御装置は、制御装置は、第二モードで制御しているときにサーバとの通信が不可能となった場合であっても、第二モードでの制御を維持する。そして、制御部が予測した時刻に負荷装置の電力需要の制御を終了（復帰）させることができる。これにより、系統電源を安定化させる効果が大きい第二モードを選択する機会を多くすること、又は、第二モードで制御する時間長を長くすることができる。
【００３４】
例えば、前記判定部は、前記サーバとの通信可否を確認するための確認信号を前記サーバに送信し、前記確認信号に応じて前記サーバが送信した応答信号を受信した場合に、前記サーバとの通信が可能であると判定する。
【００３５】
これによれば、通信部は、確認信号及び応答信号を用いた通信を実際に行うことにより、高い確度でサーバとの通信可否を判定することができる。
【００３６】
例えば、前記制御装置は、さらに、前記第一モードで前記制御を行う場合のスケジュールであって、前記電力需要を抑制することを開始する開始時刻と、前記電力需要を抑制することを終了する復帰時刻とを含むスケジュールを、前記制御を行う前に前記サーバから前記スケジュールとして取得する取得部を備える。
【００３７】
これによれば、制御装置は、第一モードで制御するときの負荷装置の電力需要の開始時刻又は終了時刻をサーバから取得し、それに基づいて制御を行うことができる。
【００３８】
例えば、前記制御部は、さらに、前記第二モードから前記第一モードへ切り替えた後に、前記サーバとの通信が可能であると前記判定部が判定した場合に、前記指令信号の１つである復帰信号を前記サーバが送信済みか否かを前記サーバに問い合わせ、前記サーバが前記復帰信号を既に送信済みである場合には、前記動作モードを前記第二モードに切り替えて前記制御を行う。
【００３９】
これによれば、制御装置がサーバとの通信が不可能であることに基づいて第二モードから第一モードへ制御を切り替えた後、通信が復旧した場合に、制御装置は、サーバにおける制御状態に基づいて適切な制御状態をとることができる。
【００４０】
例えば、前記制御装置は、さらに、予め定められたスケジュールに従って前記制御装置が前記制御を行う第一電力サービス、及び、前記サーバからの指令信号に従って前記制御装置が前記制御を行う第二電力サービスのいずれか一方を、ユーザからの指示に基づいて選択するサービス選択部を備え、前記制御部は、前記サービス選択部が前記第一電力サービスを選択した場合に前記第一モードで前記制御を行い、前記サービス選択部が前記第二電力サービスを選択した場合に前記第二モードで前記制御を行う。
【００４１】
これによれば、第一電力サービス又は第二電力サービスのうち、ユーザがアグリゲータとの契約に基づいて選択する一方に対応して、制御装置は、第一モード又は第二モードのうちの一方を選択する。その結果、制御装置が選択するモードは、ユーザによる契約に基づいたものとなる。よって、制御装置は、ユーザによるアグリゲータとの契約に基づいて第一モード又は第二モードで負荷装置を制御することができる。
【００４２】
例えば、前記第一電力サービスは、予め定められた時間帯に負荷装置の電力需要を抑制するサービスであるピークカット供給であり、前記第二電力サービスは、前記サーバからの指令信号に従ったタイミングに負荷装置の電力需要を抑制するサービスである予備力供給、又は、前記サーバからの指令信号に従ったタイミングに前記指令信号に従った電力需要値によって負荷装置の電力需要を制御するサービスである周波数制御である。
【００４３】
これによれば、制御装置は、ピークカット供給、予備力供給、又は、周波数制御の電力サービスを、サーバとの通信可否に基づいて適切に切り替えながら負荷装置を制御することができる。
【００４４】
例えば、前記負荷装置は、家庭電化製品、電気自動車、蓄電池、充電器、温水暖房機、冷凍圧縮機、食器洗い機、衣類乾燥機、製氷機、及びスイミングプールポンプのいずれかを含む。
【００４５】
これによれば、制御装置は、家庭電化製品、電気自動車、蓄電池、充電器、温水暖房機、冷凍圧縮機、食器洗い機、衣類乾燥機、製氷機、及びスイミングプールポンプを制御することができる。
【００４６】
例えば、前記制御部は、さらに、第二モードにおける前記電力需要の抑制の開始時刻、及び、終了時刻の少なくとも一方を前記サーバから取得した場合に、前記第一モードで前記制御を行うように前記制御を切り替えるとともに、前記少なくとも一方に従って前記負荷装置の電力需要を制御する。
【００４７】
これによれば、制御装置は、取得した第二モードの開始時刻又は終了時刻に従って第二モードで負荷装置の電力需要を制御することができる。
【００４８】
また、本発明の一態様に係る制御方法は、ネットワークを介してサーバと接続され、負荷装置の電力需要の制御を行う制御装置における制御方法であって、前記サーバと前記制御装置とが通信可能であるか否かを判定する判定ステップと、予め定められたスケジュールに従って前記負荷装置の電力需要を制御する第一モード、及び、前記サーバからの指令信号に従って前記負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する制御ステップとを含み、前記制御ステップでは、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定ステップで判定した場合に、前記動作モードを前記第一モードに切り替えて前記制御を行う。
【００４９】
これにより、上記の制御装置と同様の効果を奏する。
【００５０】
また、本発明の一態様に係る制御方法は、上記に記載の制御装置と、サーバとを備える制御システムであって、前記制御装置の判定部は、前記サーバと通信可能であるか否かを判定する。
【００５１】
これにより、上記の制御装置と同様の効果を奏する。
【００５２】
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
【００５３】
以下、実施の形態について、図面を参照しながら具体的に説明する。
【００５４】
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
【００５５】
（実施の形態）
本実施の形態では、アグリゲータとＤＲコントローラとの間の通信損失時におけるデマンドレスポンス制御システムについて説明する。また、電気エネルギーシステム、電気負荷制御システム、及び、それらシステムの特性及び制約を考慮して集約リソースを管理及び制御する方法について説明する。
【００５６】
図１Ａは、本実施の形態に基づく制御システム１の構成図である。図１Ｂは、本実施の形態に基づくデマンドレスポンスサービスの基本的なシステム構造を示す図である。本実施の形態では、サーバ１００とＤＲコントローラ２００の場合を考える。サーバ１００を、第１運用決定システムとし、ＤＲコントローラ２００を、第２運用決定システムとしてもよい。なお、ＤＲコントローラ２００は、制御装置に相当する。
【００５７】
図１Ａ及び図１Ｂに示されるように、制御システム１は、サーバ１００と、ＤＲコントローラ２００と、負荷装置２０１とを備える。
【００５８】
サーバ１００は、アグリゲータのサーバである。サーバ１００は、通信１０１によってＤＲコントローラ２００に対してＤＲの制御に関する命令（指令信号）を送信する。
【００５９】
ＤＲコントローラ２００は、１構内における複数の負荷装置２０１の運用を制御する。ＤＲコントローラ２００は、サーバ１００と通信する。通信１０１は、ＤＲ動作に必要なデータ１０２と命令１０３とを伝送する。ＤＲコントローラ２００は、その複数の負荷装置２０１の運用を制御可能である。なお、ＤＲコントローラのことをＤＲＣと表記することもある。
【００６０】
通信１０１は、例えば、有線又は無線ネットワーク、電力線通信（ＰＬＣ）などにより実現される。
【００６１】
負荷装置（ＬＲ（Ｌｏａｄ  Ｒｅｓｏｕｒｓｅ））２０１とは、例えば、家庭電化製品（ＨＡ（Ｈｏｍｅ  Ａｐｐｌｉａｎｃｅ））、電気自動車、蓄電池、充電器、温水暖房機、冷凍圧縮機、食器洗い機、衣類乾燥機、製氷機、スイミングプールポンプなどのことである。
【００６２】
命令１０３の例として、起動時刻、復旧時刻、需要増加量又は需要減少量などがある。データ１０２の例として、ＤＲ契約、ＤＲスケジュール又はＤＲインセンティブ価格などが利用可能である。このデータおよび命令を用いて、ＤＲコントローラ２００は、負荷装置２０１を制御して、ＤＲサービス２０３を提供することができる。
【００６３】
図２は、実施の形態に基づく、通信要求によるＤＲ分類を示す図である。図２に基づいて、ＤＲは、（１）スケジュールベースのＤＲ、（２）命令ベースのＤＲ、（３）継続的ＤＲの３タイプを少なくとも含むタイプのいずれかに分類されることを示す図である。この分類は、通信要求に基づくものである。
【００６４】
「スケジュールベースのＤＲ」のタイプでは、削減／増加すべき負荷量（つまり、電力需要量）、開始時刻２０４、及び、復帰時刻２０５は、ＤＲコントローラ２００に事前に通知されている。そして、開始時刻２０４において、電力需要を抑制することを開始する開始制御を行い、復帰時刻２０５において、電力需要を抑制することを終了する復帰制御を行う。開始制御と復帰制御とをまとめて制御ともよぶ。このタイプのＤＲの例は、「ピークカット供給」又は「ネガワット」である。なお、「スケジュールベースのＤＲ」を、タイプ１のＤＲと呼ぶこともある。
【００６５】
「命令ベースのＤＲ」のタイプでは、負荷増加量／負荷減少量データ又は開始時刻及び復旧時刻データは事前には分かっていない。このようなデータは、命令（指令信号とも記載する）を用いてＤＲ運用時間内に通信１０１を介してＤＲコントローラ２００へ送信される。そして、指令信号の１つである開始信号を受信した場合に、電力需要を抑制することを開始する開始制御を行い、指令信号の別の１つである復帰信号を受信した場合に、電力需要を抑制することを終了する復帰制御を行う。このタイプでは、起動と復旧との間で他の命令は必要とされない。このタイプのＤＲの例は、「予備力供給」である。なお、「命令ベースのＤＲ」を、タイプ２のＤＲと呼ぶこともある。
【００６６】
「継続的ＤＲ」のタイプでは、負荷増加量／負荷減少量データとタイミングデータとが、ＤＲ運用時間内に通信１０１を介してＤＲコントローラ２００へ送信される。このタイプの例は、「周波数調整（ＦＲ（Ｆｒｅｑｕｅｎｃｙ  Ｒｅｇｕｌａｔｉｏｎ））」である。なお、「継続的ＤＲ」を、タイプ３のＤＲと呼ぶこともある。
【００６７】
なお、タイプ１は、第一モードに相当する。また、タイプ２及びタイプ３のそれぞれは、第二モードに相当する。
【００６８】
なお、一般に、スケジュールベースのＤＲ（タイプ１）より命令ベースのＤＲの方が、ユーザが実行したときに得られる対価（インセンティブ）が高い。また、同様に、命令ベースのＤＲより継続的ＤＲの方が、インセンティブが高い。
【００６９】
なお、図２は、単なる説明目的のものであり、本願においてＤＲの種類およびＤＲの数を限定するものではない。
【００７０】
（ＤＲタイプ変更の概念）
通信要求に基づき、様々な「ＤＲタイプ」が存在する。サーバ１００とＤＲコントローラ２００との間の通信が失敗した場合、ＤＲコントローラ２００の主な目標は、元のＤＲスケジュールを続け、サーバ１００から受信したタイプのＤＲの制御を継続することである。しかしながら、通信ができなくなることにより、あるタイプのＤＲを継続できなくなることもある。このような場合、ＤＲコントローラ２００は、状況に応じて、いずれの要求にも反することなくＤＲタイプを変更する。
【００７１】
本実施の形態に基づいた概念について理解を容易にするため、以下の例を挙げる。図３は、本実施の形態に基づく、独立運用モードでのＤＲタイプ運用時における通信損失タイミングの一例である。
【００７２】
（例Ａ）
１．ＤＲコントローラ２００は、１３：００から１６：００の間に予備力供給（元のＤＲスケジュール）を行うように計画されていた。
【００７３】
２．ＤＲコントローラ２００は、１３：１５に予備力提供信号を受信した。
【００７４】
３．ＤＲコントローラ２００は、１３：１５にＤＲ動作を開始した。
【００７５】
４．ＤＲコントローラ２００とサーバ１００との間の通信が１３：４５にできなくなった。
【００７６】
５．ＤＲコントローラ２００は、予備力復旧指令をまだ受信していない。
【００７７】
６．サーバ１００は、１３：００より前に予備力の供給期間情報をＤＲコントローラ２００へ送信済みであった。
【００７８】
この例では、予備力の供給期間が事前に提供されているので、ＤＲコントローラ２００は、供給期間が経過するまで「予備力供給」を継続する。ＤＲの制御を行っている間、ＤＲコントローラ２００は、通信が復旧したか否かを確認し、復旧された場合、サーバ１００から命令された通りに動作する。
【００７９】
（例Ｂ）
以下の状況を考える。
【００８０】
１．ＤＲコントローラ２００は、１３：００から１６：００の間（ピーク時間）に予備力供給（元のＤＲスケジュール）を行うように計画されていた。
【００８１】
２．ＤＲコントローラ２００とサーバ１００との間の通信が１２：５５に通信１０１ができなくなった。
【００８２】
３．市場ルール、アグリゲータ契約、ＤＲコントローラ２００契約、及び、負荷装置２０１に基づき、ＤＲコントローラ２００は、１３：００から１４：００まで「ピークカット」を行うことが可能である。なお、以降において、「ＤＲコントローラ２００契約」とは、ＤＲコントローラ２００と負荷装置２０１とを制御する権限があるユーザとサーバ１００との間のＤＲ契約のことを意味する。
【００８３】
「提供指令」より前に通信１０１ができなくなったので、ＤＲコントローラ２００は「予備力供給」を行うことができない。その理由は、ＤＲコントローラ２００が負荷削減をいつ開始すればよいのか把握できないからである。今回、ＤＲコントローラ２００は、「予備力供給」（元のＤＲ計画）から「ピークカット供給」へ「ＤＲタイプを変更する」と決定することができる。これは、いずれのＤＲも行わない場合と比べ、ユーザとアグリゲータとの双方にとって経済的に有益である。
【００８４】
（ブロック図及び内部処理）
図４は、本実施の形態に基づく、サーバとＤＲコントローラとのブロック図である。本実施の形態では、ＤＲコントローラ２００は、通信部２１０と、制御部２１１とを備える。通信部２１０は、通信判定部２２０を備える。制御部２１１は、通常運用管理部２３１と、独立運用管理部２３２と、メモリ２４０とを備える。また、ＤＲコントローラ２００は、さらに、インターフェース２５０を備えていてもよい。
【００８５】
通信部２１０は、ＤＲコントローラ２００と負荷装置２０１との間の通信２０２及び通信１０１を担っている。
【００８６】
通信判定部２２０は、サーバ１００とＤＲコントローラ２００とが通信可能であるか否かを判定する。なお、通信判定部２２０は、判定部に相当する。通信判定部２２０は、サーバ１００との通信可否を確認するための確認信号をサーバ１００に送信し、確認信号に応じてサーバ１００が送信した応答信号を受信した場合に、サーバ１００との通信が可能であると判定する。
【００８７】
制御部２１１は、予め定められたスケジュールに従って負荷装置２０１の電力需要を制御する第一モード、及び、サーバ１００からの指令信号に従って負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する。また、第二モードで制御を行っている場合であって、サーバ１００との通信が可能でないと通信判定部２２０が判定した場合に、動作モードを第一モードに切り替えて制御を行う。また、制御部２１１は、第二モードで制御を行っている場合であって、サーバ１００との通信が可能であると通信判定部２２０が判定した場合に、第二モードを維持して制御を行う。
【００８８】
つまり、通信１０１が成功すれば、通常運用管理部２３１がＤＲ運用を扱う。一方、通信１０１が失敗すれば、独立運用管理部２３２がＤＲ運用を管理する。
【００８９】
なお、ＤＲコントローラ２００は、さらに、第一モードで制御を行う場合のスケジュールであって、電力需要を抑制することを開始する開始時刻と、電力需要を抑制することを終了する復帰時刻とを含むスケジュールを、制御を行う前にサーバ１００から取得する取得部（不図示）を備えてもよい。
【００９０】
また、第二モードで制御を行っている場合であって、サーバ１００との通信が可能でないと通信判定部２２０が判定した場合であっても、指令信号である復帰信号であって復帰制御を行う旨を示す信号である復帰信号を受信する時刻を予測可能である場合に、第二モードを維持して負荷装置２０１を制御するとしてもよい。
【００９１】
また、第二モードから第一モードへ切り替えた後に、サーバ１００との通信が可能であると通信判定部が判定した場合に、指令信号の１つである復帰信号をサーバ１００が送信済みか否かをサーバ１００に問い合わせ、サーバ１００が復帰信号を既に送信済みである場合には、動作モードを第二モードに切り替えて制御を行い、サーバが復帰信号を未だ送信していない場合には、第一モードを維持して制御を行うとしてもよい。
【００９２】
また、制御部２１１は、さらに、第二モードにおける電力需要の抑制の開始時刻、及び、終了時刻の少なくとも一方をサーバ１００から取得した場合に、第一モードで制御を行うように制御を切り替えるとともに、少なくとも一方に従って負荷装置の電力需要を制御するとしてもよい。
【００９３】
なお、ＤＲコントローラ２００は、さらに、予め定められたスケジュールに従って制御を行う第一電力サービス、及び、サーバ１００からの指令信号に従って制御を行う第二電力サービスのいずれか一方を、ユーザからの指示に基づいて選択するサービス選択部（不図示）を備え、制御部２１１は、サービス選択部が第一電力サービスを選択した場合に第一モードで制御を行い、サービス選択部が第二電力サービスを選択した場合に第二モードで制御を行うとしてもよい。
【００９４】
メモリ２４０には、ＤＲデータ２４１と、ユーザデータ２４２と、負荷装置データ２４３とが含まれる。
【００９５】
インターフェース２５０は、ユーザ２０３ｕからの入力操作を受け付けるインターフェースである。
【００９６】
図４では、サーバ１００の内部ブロックが示されている。サーバ１００は、単一／複数のＤＲ契約者３００へＤＲサービスを提供する。また、ＤＲ契約者３００もアグリゲータ（サーバ１００）と同じであってもよい。
【００９７】
図４に示されるように、サーバ１００は、通信部１１０と、プロセス管理部１２０と、メモリ１３０と、独立運用サポート部１４０とを備える。
【００９８】
通信部１１０は、データの送受信及び各ＤＲコントローラ２００へのＤＲ命令／信号送信を担う。
【００９９】
プロセス管理部１２０は、ＤＲアグリゲーションの運用面及び操作を扱うプロセス管理部１２０を備える。
【０１００】
メモリ１３０は、例えば、ＤＲデータ、ユーザデータ、又は負荷装置データを格納する。
【０１０１】
ＤＲデータは、例えば、ＤＲ契約、前回のＤＲ性能、負荷装置をどのように異なるＤＲに割り当てるかなどを含むデータである。
【０１０２】
ユーザデータは、例えば、負荷装置のユーザ設定ポイント、ユーザＤＲ設定、ユーザＤＲ性能データなどを含むデータである。
【０１０３】
負荷装置データは、例えば、負荷装置のコンテキストデータ、エネルギー残量、温度、運用ポイントなどを含むデータである。
【０１０４】
独立運用サポート部１４０は、通信１０１が失敗した場合にＤＲコントローラ２００が独立運用モードで運用できるようにするための補足データを作成する。独立運用サポート部１４０は、詳細には、ＤＲ事前スケジュール抽出部１４１と、ＤＲタイプ変更抽出部１４２と、ＤＲ期間予測部１４３とを備える。
【０１０５】
ＤＲ事前スケジュール抽出部１４１は、「スケジュールベースのＤＲ」のリソース用にＤＲスケジュールを事前に推定しておく。このデータは、市場情報、ＤＲＣ情報、及び、アグリゲータ情報に基づき、作成される。この「事前スケジュール」とは、通信１０１が失敗した場合に、ＤＲコントローラ２００が実行するであろう実際のＤＲスケジュールを単に予測したものである。通信状態が通常の場合は、「事前スケジュール」は使用されない。
【０１０６】
ＤＲタイプ変更抽出部１４２は「アグリゲータのＤＲタイプ変更テーブル」を作成する。
【０１０７】
ＤＲ期間予測部１４３は、各タイプのＤＲ動作が続く期間を予測したものを抽出する。
【０１０８】
当該システムにおける他の実施の形態によれば、ＤＲ事前スケジュール抽出部１４１、ＤＲタイプ変更抽出部１４２、及び、ＤＲ期間予測部１４３のシステムデータは定期的に更新され、実際の運用時間よりも前にＤＲコントローラ２００へ送信される。
【０１０９】
当該システムにおける他の実施の形態によれば、サーバ１００は、ソースコード／ソフトウェア／データベースなどをＤＲコントローラ２００にアップロードして、ＤＲコントローラ２００が、独立運用モード時に単独でこのようなデータを算出できるようにする。サーバ１００は、必要な場合に、ソースコード／ソフトウェア／データベースを更新する。
【０１１０】
図５は、実施の形態に基づく、異なるタイムステップにおける、アグリゲータ及びＤＲコントローラがＤＲコントローラの独立運用を可能にするのに必要な動作を示す図である。理解を容易にするため、図５に、本実施の形態に基づいた例において必要な動作の時間シーケンス図を示す。
【０１１１】
図６Ａは、実施の形態に基づく、事前運用動作のシーケンス図である。図６Ａに運用時間より前にアグリゲータのサーバ１００がとる、以下のような動作のシーケンス図を示す。
【０１１２】
サーバ１００は、独立運用モードのＤＲＣに有用なデータを作成する（ステップＳ６０１）。
【０１１３】
サーバ（アグリゲータ）のＤＲタイプ変更許可テーブルは、サーバが変更を許可するＤＲタイプを定義するテーブルである。後で詳細に説明する。
【０１１４】
各ＤＲタイプ用事前スケジュールは、１〜３の各ＤＲタイプにおけるＤＲの事前スケジュールである。具体的には、タイプ１のＤＲについては、電力需要を削減することを予め定められた時間帯を示すスケジュールである。また、タイプ２又はタイプ３のＤＲについては、サーバからの指令信号を受信して電力需要を制御することができる時間帯を示すスケジュールである。なお、各ＤＲタイプ用事前スケジュールを、ＤＲタイプ用想定期間とよぶ場合もある。各ＤＲタイプのＤＲが実行されることが想定される期間であるからである。
【０１１５】
通信損失期間閾値は、通常運用モードから独立運用モードに切り替えるときに用いる閾値であり、後で詳細に説明する。
【０１１６】
サーバ１００は、ステップＳ６０１で作成したデータをＤＲコントローラに送信する（ステップＳ６０２）。
【０１１７】
図６Ｂは、本実施の形態に基づく、サーバのＤＲタイプ変更許可テーブルの一例である。
【０１１８】
図６Ｂには、変更前に選択されていたＤＲタイプ（タイプ１、２及び３）のそれぞれに対して、変更後に選択されることがサーバにより許可されるＤＲタイプが「Ｙ」により示されている。また、上記以外のＤＲタイプが「Ｎ」で表されている。例えば、図６Ｂによれば、変更前にＤＲタイプ１である場合に、ＤＲタイプ変更により、タイプ１及び２に変更することが可能である一方、タイプ３に変更することは不可能である。なお、上記の説明において、変更前のＤＲタイプと変更後のＤＲタイプとが同一の場合も「変更する」という文言を用いたが、これは、当該ＤＲタイプを維持するという意味である。つまり、「ＤＲタイプ１からＤＲタイプ１へ変更する」という記載は、「ＤＲタイプ１を維持する」という意味である。
【０１１９】
図７は、実施の形態に基づく、サーバによる事前運用動作のフローチャートである。図７に、運用時間より前にサーバ１００がとる動作のフローチャートを示す。
【０１２０】
サーバ１００は、ＤＲコントローラ２００データと、アグリゲータポートフォリオデータと、アグリゲータ契約データと、市場データと、通信性能データとを取得する（ステップＳ７０１）。
【０１２１】
サーバ１００は、ステップＳ７０１で取得したデータの任意の組み合わせを分析して（ステップＳ７０２）、以下のデータの任意の組み合わせを作成する（ステップＳ７０３）。
【０１２２】
１．どんなＤＲタイプ変更がアグリゲータのサーバ１００の条件を満たすのかＤＲコントローラ２００が理解できるようにする「アグリゲータのＤＲタイプ許可」データ。
【０１２３】
例えば、（１）サーバ１００が、「ピークカット供給」と「予備力供給」との両方をシステム運用者に売却する契約を有し、（２）市場ルールに基づき、すでに入札した量以上のピークカットを行ってもよい、という条件がある場合におけるサーバ１００の判断を考える。
【０１２４】
上記（１）及び（２）の両方の条件が成立する場合、サーバ１００は、通信１０１が失敗した場合、ＤＲコントローラ２００が「予備力供給」から「ピークカット供給」へ変更してもかまわない。一方、条件（１）と条件（２）とのうちいずれかが満たされなかった場合は、サーバ１００は、「ピークカット供給」と「予備力供給」とのＤＲタイプ変更を受け入れることができない。この「アグリゲータのＤＲタイプ変更許可」は、通信１０１を介して事前にＤＲコントローラ２００へ送信されるものである。
【０１２５】
２．各ＤＲタイプ用の事前スケジュール。
【０１２６】
３．ＤＲコントローラ２００を通常運用モードから独立運用モードに移行させる「通信損失期間」。
【０１２７】
本実施の形態によれば、上記データは、確率的／曖昧でもよく、ＤＲコントローラ２００に転送されるものである。ＤＲコントローラ２００は最終的な値を決定する。本実施の形態によれば、サーバ１００は、上記データの最終的な値を決定し、その値をＤＲコントローラ２００に転送する（ステップＳ７０４）。
【０１２８】
本発明の他の実施の形態によれば、サーバ１００は、このようなデータを算出するＤＲコントローラ２００の機能／ソフトウェアを更新する。
【０１２９】
図８は、本実施の形態に基づく、運用時間内のＤＲコントローラ２００による運用タイプ選択のシーケンス図である。図９は、本実施の形態に基づく、運用時間内のＤＲコントローラによる運用タイプ選択のフローチャートである。
【０１３０】
まず、サーバ１００は、ＤＲ命令をＤＲコントローラ２００に送信し、ＤＲコントローラ２００は、通信状態を確認する（ステップＳ９０１）。
【０１３１】
そして、通信判定部２２０により、通信１０１が成功したかどうかが判断される（ステップＳ９０２）。
【０１３２】
通信１０１が成功すれば（ステップＳ９０２でＹｅｓ）、通常運用管理部２３１により通常運用が行われる（ステップＳ９０３）。通信１０１が失敗だった場合は（ステップＳ９０２でＮｏ）、独立運用モードに入るための特定期間、すなわち、独立運用モードに入るための通信損失期間閾値（ステップＳ６０１の（Ｄ））をＤＲコントローラ２００によって確認する。通信損失期間閾値（ステップＳ６０１の（Ｄ））の最後まで通信１０１が失敗だった場合、独立運用管理部２３２が、独立運用モードで運用を行う（ステップＳ９０５）。
【０１３３】
図１０は、本実施の形態に基づく、元のＤＲスケジュールが継続可能な場合の独立運用モードのＤＲコントローラによる運用時間動作のシーケンス図である。図１１Ａは、本実施の形態に基づく、独立運用モードのＤＲコントローラによる運用時間動作のシーケンス図である。図１２は、本実施の形態に基づく、ＤＲコントローラによる独立ＤＲ運用管理のフローチャートである。図１０及び図１１Ａに示されるシーケンス図は、ＤＲコントローラが図１２に示されるフローチャートに従った動作を行うことで実現される。
【０１３４】
ＤＲコントローラ２００は、独立運用をサポートするためにステップＳ６０２（図６Ａ）でサーバ１００から提供されたデータを含む更新データであるＤＲデータ２４１、ユーザデータ２４２及び負荷装置データ２４３等を確認する（ステップＳ１００１、ステップＳ１２０１）。
【０１３５】
ＤＲコントローラは、ＤＲタイプを変更すべきかどうか判断する（ステップＳ１００２、ステップＳ１２０２）。通信を行わずにＤＲイベントを運用するためのサポートデータ（ステップＳ６０１で出力されるデータ）が十分にある場合、ＤＲコントローラは、ＤＲタイプを変更しないと決定する。
【０１３６】
ＤＲコントローラがＤＲタイプを変更する必要はないと決定した場合、ＤＲコントローラは、各負荷装置のＤＲ動作のスケジュールを立てる（ステップＳ１００３、ステップＳ１２０４）。ここで、例えば、ＤＲコントローラは、図３の例Ａのように、サーバ１００から提供される「想定ＤＲ期間」に基づいてＤＲの終了時刻を決定する。
【０１３７】
ＤＲコントローラは、その独立運用スケジュール（ステップＳ１００３の出力）に基づいて、ＤＲ動作を管理する（ステップＳ１００４、ステップＳ１２０５）。
【０１３８】
同時に、ＤＲコントローラは、通信を利用できるかどうかも確認する（ステップＳ１００５、ステップＳ１２０６）。
【０１３９】
ＤＲコントローラ２００は、ステップ１００５で確認した通信の利用可否と、ステップ１００３で立てたスケジュールに基づき、ＤＲの復旧を管理する（ステップＳ１００６、ステップＳ１２０７）。
【０１４０】
ＤＲコントローラ２００は、ＤＲデータ２４１、ユーザデータ２４２、及び負荷装置データ２４３を更新する（ステップＳ１００７、ステップＳ１２０８）。
【０１４１】
なお、この場合には、運用中のＤＲコントローラ２００をサポートするためにサーバ１００から提供されるデータのおかげで、ＤＲコントローラ２００は、元のＤＲスケジュールにかなり近いＤＲ性能を維持することができる。
【０１４２】
次に、図１１Ａを参照しながら、ＤＲタイプ変更を避けられない場合の独立運用モードについて説明する。
【０１４３】
ＤＲコントローラ２００は、独立運用をサポートするためにステップＳ６０１でサーバ１００から提供されたデータを含む更新データであるＤＲデータ２４１、ユーザデータ２４２、及び負荷装置データ２４３を確認する（ステップＳ１００１、ステップＳ１２０１）。
【０１４４】
ＤＲコントローラ２００は、ＤＲタイプを変更すべきかどうか、つまり、元のＤＲタイプを継続することができるかどうか判断する（ステップＳ１００２、ステップＳ１２０２）。通信を行わずにＤＲイベントを運用するためのサポートデータ（ステップ６０１で出力されるデータ）が十分にない場合、ＤＲコントローラ２００は、ＤＲタイプを変更すると決定する。
【０１４５】
ＤＲコントローラ２００は、ＤＲデータ２４１、ユーザデータ２４２、及び負荷装置データ２４３に基づいて、「ＤＲＣのＤＲタイプ変更許可テーブル」を作成する（ステップＳ１１０１、ステップＳ１２０３）。ＤＲＣのＤＲタイプ変更許可テーブルは、どんなタイプのＤＲタイプ変更が、ＤＲコントローラ２００で可能なのかを示している。
【０１４６】
ＤＲコントローラ２００は、ステップＳ１１０１で作成した「ＤＲＣのＤＲタイプ変更許可テーブル」、並びに、ＤＲデータ２４１、ユーザデータ２４２、及び、負荷装置データ２４３に基づいて、利用可能な負荷装置ごとに「負荷装置のＤＲタイプ変更許可テーブル」を作成する（ステップＳ１１０２、ステップＳ１２０３）。「負荷装置のＤＲタイプ変更許可テーブル」は、どんなタイプのＤＲタイプ変更が、各負荷装置で可能なのかを示している。
【０１４７】
ＤＲコントローラ２００は、ステップＳ１１０１で作成した「ＤＲＣのＤＲタイプ変更許可テーブル」、ステップＳ１１０２で作成した「負荷装置のＤＲタイプ変更許可テーブル」、並びに、ＤＲデータ２４１、ユーザデータ２４２、及び、負荷装置データ２４３に基づいて、負荷装置ごとにＤＲスケジュールを決定する（ステップＳ１１０３、ステップＳ１２０４）。
【０１４８】
ＤＲコントローラ２００は、ステップＳ１１０３で決定したスケジュールに基づいてＤＲリソース（負荷装置）の運用を開始した後（ステップＳ１１０４）、運用を管理する（ステップＳ１１０５、ステップＳ１２０５）。
【０１４９】
ＤＲコントローラ２００は、通信を利用できるか確認する（ステップＳ１１０６、ステップＳ１２０６）。
【０１５０】
ＤＲコントローラ２００は、ステップＳ１１０４の出力と、ステップＳ１１０２の出力と、ＤＲデータ２４１、ユーザデータ２４２、及び、負荷装置データ２４３との結果を考慮して、各負荷装置の復旧を管理する（ステップＳ１１０７、ステップＳ１２０７）。
【０１５１】
ＤＲコントローラ２００は、ＤＲデータ２４１、ユーザデータ２４２、及び、負荷装置データ２４３を更新する（ステップＳ１１０８、ステップＳ１２０８）。
【０１５２】
図１１Ｂは、本実施の形態に基づく、ＤＲコントローラのＤＲタイプ変更許可テーブルの一例である。
【０１５３】
図１１Ｂには、変更前に選択されていたＤＲタイプ（タイプ１、２及び３）のそれぞれに対して、変更後に選択されることがＤＲコントローラにより許可されるＤＲタイプが「Ｙ」により示されている。また、上記以外のＤＲタイプが「Ｎ」で表されている。図６Ｂとの違いは、図６Ｂでは許可する主体がサーバであったのに対し、図１１ＢではＤＲコントローラであることである。
【０１５４】
図１１Ｃは、本実施の形態に基づく、負荷装置のＤＲタイプ変更許可テーブルの一例である。
【０１５５】
図１１Ｃには、変更前に選択されていたＤＲタイプ（タイプ１、２及び３）のそれぞれに対して、変更後に選択されることが負荷装置により許可されるＤＲタイプが「Ｙ」により示されている。また、上記以外のＤＲタイプが「Ｎ」で表されている。図６Ｂとの違いは、図６Ｂでは制御の対象が１つのＤＲコントローラに制御される負荷装置すべてであったのに対し、図１１Ｃでは１つの負荷装置であることである。
【０１５６】
図１３は、本実施の形態に基づく、ＤＲタイプ変更許可テーブルの作成に関するフローチャートである。具体的には、図１３は、ＤＲコントローラ２００が、「ＤＲＣのＤＲタイプ変更許可テーブル」と「負荷装置のＤＲタイプ変更許可テーブル」とを作成する処理を示す図である。
【０１５７】
ＤＲコントローラ２００は、アグリゲータのＤＲタイプ、ＤＲコントローラとサーバ１００との契約の契約タイプを含むＤＲデータ、ＤＲコントローラ２００のユーザデータ、負荷装置２０１データなどを含むデータを取得する（ステップＳ１３０１）。
【０１５８】
ＤＲコントローラ２００は、ステップＳ１３０１で取得したデータを分析する（ステップＳ１３０２）。
【０１５９】
ＤＲコントローラ２００は、ＤＲコントローラのＤＲタイプ変更許可テーブルと、各負荷装置のＤＲタイプ変更許可テーブルとを作成する（ステップＳ１３０３）。このステップでは、タイプＸからタイプＹへのＤＲタイプの変更により、ＤＲデータ２４１で利用可能ないずれのＤＲ契約も破られないように、かつ、ユーザデータ２４２で利用可能なユーザ設定が無視されないようにすべきであり、負荷装置データ２４３で利用可能な各負荷装置機能も壊されないようにすべきである。
【０１６０】
ＤＲコントローラ２００は、ステップＳ１３０３で上記のテーブルを作成すると、ＤＲコントローラと各負荷装置との新たなＤＲタイプ変更許可がＤＲデータ２４１で更新する（ステップＳ１３０４）。例えば、ＤＲコントローラ２００のユーザがアグリゲータとの間で「ピークカット供給」契約をしていない場合、「予備力供給」から「ピークカット供給」へのＤＲタイプ変更を、ＤＲコントローラ２００は受け入れることができない。なぜなら、ＤＲコントローラ２００のユーザは、それに対して何のインセンティブも得られないからである。
【０１６１】
ステップ１１０２において、「負荷装置のＤＲタイプ変更許可テーブル」は、ＤＲコントローラ２００が制御して、負荷装置２０１ごとに作成される。本実施の形態によれば、「負荷装置のＤＲタイプ変更許可テーブル」は、負荷装置２０１ごとにＤＲタイプ変更許可を定義する。一例として、「負荷装置のＤＲタイプ変更許可」は、各負荷装置のコンテキストデータ、履歴性能データ、ユーザ設定、及び、各ＤＲの契約コンテキストを用いて作成される。
【０１６２】
以下に例を示す。
【０１６３】
１．「予備力供給」から「ピークカット供給」へ変更する「ＤＲＣのＤＲタイプ変更許可テーブル」データを、ＤＲＣは１３：００から１４：００まで受け入れることができる。
【０１６４】
２．また、空調機器（負荷装置１）は、「予備力供給」から「ピークカット供給」へのＤＲタイプ変更を受け入れることができる。
【０１６５】
３．バッテリー（負荷装置ｎ）は、充電状態（ＳＯＣ（Ｓｔａｔｅ  ｏｆ  Ｃｈａｒｇｅ））によって制限されるため、１３：００から１４：００まではピークカットを行うことができない。
【０１６６】
この場合、「予備力供給」から「ピークカット供給」への「負荷装置のＤＲタイプ変更許可」は、負荷装置ｎに対して発行されない。
【０１６７】
図１４は、本実施の形態に基づく、ＤＲコントローラ用及び各負荷装置用の「ＤＲタイプ変更許可テーブル」の説明図である。図１４は、本実施の形態に基づく、ＤＲＣのＤＲタイプ変更許可テーブル１４０１と、負荷装置のＤＲタイプ変更許可テーブル１４０２Ａ及び１４０２Ｂとの概念例を示す図である。なお、「負荷装置のＤＲタイプ変更許可テーブル」は、負荷装置ごとに違っていてもかまわない。例えば、負荷装置１（バッテリーなど）が、スケジュールベースのＤＲ（タイプ１）と、命令ベースのＤＲ（タイプ２）と、継続的ＤＲ（タイプ３）とを実行可能とする。また、負荷装置Ｎ（長時間制限を許可しないユーザ設定のためにピークカットができない空調機器など）は、スケジュールベースのＤＲ、又は、継続的ＤＲを提供できない。ここで、各「負荷装置のＤＲタイプ変更許可テーブル」とは、「ＤＲコントローラのＤＲタイプ変更許可テーブル」のサブ機能である。
【０１６８】
他の実施の形態によれば、負荷装置のＤＲタイプ変更テーブルには、ＤＲタイプを変更可能な各負荷装置の許容量が定義される。
【０１６９】
図１５は、実施の形態に基づく、通信復旧時における独立ＤＲ運用管理のフローチャートである。図１５は、通信１０１が通常状態に戻った場合の運用決定プロセスを示す図である。負荷装置２０１が、サーバ１００から命令された元のＤＲとは違うＤＲ動作にかかわる場合がある。なぜなら、ＤＲタイプを変更したり、実際のＤＲ命令よりも事前スケジュール及び／又は推定ＤＲ期間データを用いたりするためである。復旧及び／又は通常運用管理への制御受け渡しは、独立運用管理部２３２で扱われるべきである。本実施の形態によれば、独立運用管理部２３２は、以下のデータの任意の組み合わせを取得する（ステップＳ１５０１）。
【０１７０】
−ＤＲデータ２４１
−ユーザデータ２４２
−負荷装置データ２４３
−ＤＲコントローラ２００によって実行されている実際のＤＲスケジュール
−サーバ１００によりスケジュールされている元のＤＲタイプ
−元のＤＲスケジュールの命令条件、及び、時間系列
−通信復旧タイミング
【０１７１】
このようなデータを分析した後、復旧を決定し、復旧させる（ステップＳ１５０２）。その後、ＤＲデータ２４１と負荷装置データ２４３とのデータ状態を更新する（ステップＳ１５０３）。そして、制御の権限を通常運用管理部２３１に渡して（ステップＳ１５０４）、負荷装置２０１の復旧及び／又は通常運用管理部２３１への制御受け渡し方法を管理する。
【０１７２】
理解を容易にするため、以下の例を挙げる。
【０１７３】
例えば、以下の条件を考える。
【０１７４】
１．負荷装置１は、１３：００から１４：００まで予備力供給を行うように本来計画されていた。
【０１７５】
２．１２：５５に通信できなくなったため、ＤＲタイプが「ピークカット供給」に変更された。
【０１７６】
３．「ピークカット供給」条件のため、ＤＲ期間を少なくとも３０分間継続しなければならない。すぐに復旧されると、ＤＲ動作として条件を満たさない可能性がある（すなわち、ピークカット供給が１３：００に開始されれば、１３：３０まで続けなければならない。そうでなければ、この「ピークカット動作」は条件を満たさない。）。
【０１７７】
４．時刻１３：２０に、通信が復旧される。
【０１７８】
５．サーバ１００の元のＤＲスケジュールは予備力供給であった。サーバ１００は、１３：１０に、予備力供給の「提供信号」を送信した。しかし、サーバ１００とＤＲコントローラ２００との通信ができなかったので、ＤＲコントローラ２００は、上記の提供信号を受信できなかった。
【０１７９】
上記条件を考えると、１３：２０に負荷装置１を復旧させれば、「ピークカット」動作はＤＲＣの条件を満たさない。また、予備力供給はすでに提供されており、負荷装置１は予備力供給のＤＲにももはや参入できない。したがって、独立運用管理部２３２が、１３：３０まで負荷装置１を「ピークカット動作」状態に保つことを決定する。独立運用管理部２３２は、ＤＲタイプ、復旧時刻、及び、ＤＲＣデータベース内の可制御性を更新する。そして、他の負荷装置の制御を通常運用管理部２３１へ引き渡す。通常運用管理部２３１は、更新データを確認し、指定時刻に負荷装置１を復旧させる。
【０１８０】
すなわち、通常運用管理部２３１は、通信を復旧させた場合に運用復旧にかかるコストとペナルティを最小限にする。しかしながら、ＤＲ契約情報又は機器コンテキストデータにより元のＤＲ命令に従って動作することができない場合を除き、サーバからの元のＤＲ命令が優先される。
【０１８１】
以降において、サーバとＤＲコントローラとの通信状況、及び指令信号の送信タイミングのさまざまな場合についての、ＤＲコントローラによる負荷装置の電力需要の制御について説明する。
【０１８２】
図１６は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第一の説明図である。
【０１８３】
図１６は、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなった後に、サーバ１００がＤＲコントローラ２００に開始信号を送信した場合を示す。なお、図においてハッチングで示した部分は、通信が不可能であることを示している。他の図でも同様の表現を用いる場合がある。
【０１８４】
この場合、ＤＲコントローラ２００は、通信１０１ができなくなったことを検出したときに、ＤＲタイプをタイプ２からタイプ１に変更する。そして、ＤＲコントローラ２００は、タイプ２における電力スケジュールに従い電力抑制開始時刻（Ｓｓｃ）に負荷装置による電力需要を抑制し、かつ、当該電力スケジュールに従い電力抑制復帰時刻（Ｒｓｃ）に負荷装置による電力需要を復帰させる。ＤＲコントローラ２００は、タイプ１のＤＲを実行したことになり、ユーザはタイプ１のＤＲのインセンティブを得る。
【０１８５】
図１７は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第二の説明図である。
【０１８６】
図１７は、サーバ１００がＤＲコントローラ２００に開始信号を送信した後に、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなった場合を示す。
【０１８７】
この場合、ＤＲコントローラ２００は、サーバ１００から開始信号を受信したとき（Ｓｓｇ）に電力抑制を開始する。そして、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなったことを時刻Ｃ１２に検出したら、ＤＲタイプをタイプ２からタイプ１に変更する。そして、タイプ１のＤＲの電力スケジュールに従い電力抑制復旧時刻（Ｒｓｃ）に負荷装置による電力需要を復帰させる。ＤＲコントローラ２００は、タイプ１のＤＲをＣ１２からＲｓｃまでの期間だけ実行したことになるので、ユーザは、当該一部に対応するタイプ１のＤＲのインセンティブを得る。
【０１８８】
図１８は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第三の説明図である。
【０１８９】
図１８は、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなった後に、サーバ１００がＤＲコントローラ２００に開始信号を送信し、また、通信１０１が復旧した後にサーバ１００がＤＲコントローラ２００に復帰信号を送信した場合を示す。
【０１９０】
この場合、ＤＲコントローラ２００は、通信１０１ができなくなったことを検出したときにＤＲタイプをタイプ２からタイプ１に変更する。そして、ＤＲコントローラ２００は、タイプ２における電力スケジュールに従い電力抑制開始時刻（Ｓｓｃ）に負荷装置による電力需要を抑制する。その後、ＤＲコントローラ２００は、通信１０１が復旧したことを検出すると、サーバ１００に現在の電力抑制状況を問い合わせる。ここでは、サーバ１００が未だ復帰信号を送信していない旨をＤＲコントローラ２００に通知する。ＤＲコントローラ２００は、上記の通知を受けたら、時刻Ｃ１２にＤＲタイプをタイプ１からタイプ２に変更し、かつ、電力需要の抑制状態を維持する。そして、サーバ１００からの復帰信号を受信した時刻（Ｒｓｇ）に電力需要を復旧させる。ＤＲコントローラ２００は、タイプ１のＤＲを、ＳｓｃからＣ１２までの期間だけ実行したことになるので、ユーザは、当該期間に対応するタイプ１のＤＲのインセンティブを得る。
【０１９１】
図１９は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第四の説明図である。
【０１９２】
図１９は、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなった後に、サーバ１００がＤＲコントローラ２００に開始信号を送信後、さらに、復帰信号を送信し、その後、通信１０１が復旧した場合を示す。
【０１９３】
この場合、通信１０１が復旧するまでの動作は図１８における場合と同様である。その後、ＤＲコントローラ２００は、通信１０１が復旧したことを検出すると、サーバ１００に現在の電力抑制状況を問い合わせる。ここで、サーバ１００が既に復帰信号を送信した旨をＤＲコントローラ２００に通知する。ＤＲコントローラ２００は、上記の通知を受けたら、時刻ＲｃｆにＤＲタイプをタイプ１からタイプ２に変更し、かつ、電力需要を復旧させる。ＤＲコントローラ２００は、タイプ１のＤＲを、ＳｓｃからＲｃｆまでの期間だけ実行したことになるので、ユーザは、当該期間に対応するタイプ１のＤＲのインセンティブを得る。
【０１９４】
図２０は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第五の説明図である。
【０１９５】
図２０は、サーバ１００がＤＲコントローラ２００に開始信号を送信した後に、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなった後に、サーバ１００が復帰信号を送信し、その後、通信１０１が復旧した場合を示す。
【０１９６】
この場合、通信１０１が復旧するまでの動作は図１７における場合と同様である。その後、ＤＲコントローラ２００は、通信１０１が復旧したことを検出すると、サーバ１００に現在の電力抑制状況を問い合わせる。ここで、サーバ１００が既に復帰信号を送信した旨をＤＲコントローラ２００に通知する。ＤＲコントローラ２００は、上記の通知を受けたら、時刻ＲｃｆにＤＲタイプをタイプ１からタイプ２に変更し、かつ、電力需要を復旧させる。ＤＲコントローラ２００は、タイプ１のＤＲを、Ｃ２１からＲｃｆまでの期間だけ実行したことになるので、ユーザは、当該期間に対応するタイプ１のＤＲのインセンティブを得る。
【０１９７】
図２１は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第六の説明図である。
【０１９８】
図２１は、サーバ１００がＤＲコントローラ２００に開始信号を送信した後に、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなり、通信１０１が復旧後に、サーバ１００が復帰信号を送信した場合を示す。
【０１９９】
この場合、通信１０１が復旧するまでの動作は図１７における場合と同様である。その後、ＤＲコントローラ２００は、通信１０１が復旧したことを検出すると、サーバ１００に現在の電力抑制状況を問い合わせる。ここで、サーバ１００が未だ復帰信号を送信していない旨をＤＲコントローラ２００に通知する。ＤＲコントローラ２００は、上記の通知を受けたら、時刻Ｃ１２にＤＲタイプをタイプ１からタイプ２に変更し、かつ、電力需要の抑制状態を維持する。ＤＲコントローラ２００は、ＳｓｇからＲｓｇまでの期間だけタイプ２のＤＲを実行したことになるので、ユーザは、タイプ２のＤＲのインセンティブを得る。ここで、ＤＲコントローラ２００は、Ｃ２１からＣ１２までの期間にはタイプ１のＤＲを実行していたのであるが、タイプ２のＤＲを実行していたのと実質的には変わらないので、ユーザはタイプ２のインセンティブを得ることができるのである。
【０２００】
図２２は、本実施の形態に基づく、サーバとＤＲコントローラとの通信状況、及び、ＤＲコントローラによる電力制御の第七の説明図である。
【０２０１】
図２２は、サーバ１００がＤＲコントローラ２００に開始信号を送信した後、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなり、その後、サーバ１００が復帰信号を送信した後、通信１０１が復旧した場合を示す。ここで、ＤＲコントローラ２００のＤＲ期間予測部１４３は、サーバ１００が復帰信号を送信する時刻を予測できるとする。
【０２０２】
この場合、ＤＲコントローラ２００は、サーバ１００から開始信号を受信したとき（Ｓｓｇ）に電力抑制を開始する。そして、サーバ１００とＤＲコントローラ２００との通信１０１ができなくなったことを時刻Ｃ１２に検出したら、サーバ１００が復帰信号を送信する時刻Ｒｅｓを予測する。そして、時刻Ｒｅｓに負荷装置による電力需要を復旧させる。ＤＲコントローラ２００は、タイプ２のＤＲを実行したことになるので、ユーザは、タイプ２のＤＲのインセンティブを得る。
【０２０３】
以上のように、本実施の形態における制御装置によれば、制御装置は、第二モードで負荷装置を制御しているときにサーバとの通信が不可能となった場合に第一モードで制御することができる。制御装置は、第二モードで負荷装置を制御するにはサーバからの指令信号が不可欠であるが、第一モードではサーバからの指令信号なしで負荷装置を制御することができる。つまり、制御装置は、通信が不可能となった場合に、指令信号なしで負荷装置を制御するように変更することで負荷装置の制御を継続することができる。よって、制御装置は、通信手段に不具合が生じた場合にも適切にＤＲを制御することができる。
【０２０４】
また、制御装置は、サーバとの通信が可能である場合には第二モードを維持して負荷装置を制御することができる。一般に、第一モードで負荷装置を制御するより、第二モードで負荷装置を制御するほうが系統電源を安定させる効果が大きい。よって、制御装置が第一モード及び第二モードのどちらでも負荷装置を制御することができる場合には、第二モードを選択して負荷装置を制御することが望ましい。上記のように制御装置が第二モードを維持して負荷装置を制御するのはこのためである。
【０２０５】
また、制御装置は、通信手段に不具合が生じた場合にも適切に電力需要を抑制することを開始又は終了させることができる。
【０２０６】
また、制御装置は、制御装置は、第二モードで制御しているときにサーバとの通信が不可能となった場合であっても、第二モードでの制御を維持する。そして、制御部が予測した時刻に負荷装置の電力需要の制御を終了（復帰）させることができる。これにより、系統電源を安定化させる効果が大きい第二モードを選択する機会を多くすること、又は、第二モードで制御する時間長を長くすることができる。
【０２０７】
また、通信部は、確認信号及び応答信号を用いた通信を実際に行うことにより、高い確度でサーバとの通信可否を判定することができる。
【０２０８】
また、制御装置は、第一モードで制御するときの負荷装置の電力需要の開始時刻又は終了時刻をサーバから取得し、それに基づいて制御を行うことができる。
【０２０９】
また、制御装置がサーバとの通信が不可能であることに基づいて第二モードから第一モードへ制御を切り替えた後、通信が復旧した場合に、制御装置は、サーバにおける制御状態に基づいて適切な制御状態をとることができる。
【０２１０】
また、第一電力サービス又は第二電力サービスのうち、ユーザがアグリゲータとの契約に基づいて選択する一方に対応して、制御装置は、第一モード又は第二モードのうちの一方を選択する。その結果、制御装置が選択するモードは、ユーザによる契約に基づいたものとなる。よって、制御装置は、ユーザによるアグリゲータとの契約に基づいて第一モード又は第二モードで負荷装置を制御することができる。
【０２１１】
また、制御装置は、ピークカット、予備力供給、又は、周波数制御の電力サービスを、サーバとの通信可否に基づいて適切に切り替えながら負荷装置を制御することができる。
【０２１２】
また、制御装置は、家庭電化製品、電気自動車、蓄電池、充電器、温水暖房機、冷凍圧縮機、食器洗い機、衣類乾燥機、製氷機、及びスイミングプールポンプを制御することができる。
【０２１３】
また、制御装置は、取得した第二モードの開始時刻又は終了時刻に従って第二モードで負荷装置の電力需要を制御することができる。
【０２１４】
なお、上記の実施の形態の一部又は全部は、以下の付記のようにも記載されうるが、以下の記載に限定されない。
【０２１５】
［付記１］
複数の負荷装置を制御する制御装置であって、
ユーザがサービスプロバイダに提供できる電力サービスのタイプを特定するための識別子と、複数の電力サービスのうち第１タイプの電力サービスを開始させるサービス開始信号とを受信する第１通信モジュールと、
前記負荷と通信する第２通信モジュールと、
電力サービス期間中、前記識別子によって特定された第１タイプの電力サービスに基づいて、前記第２通信部を介して前記複数の負荷装置を制御するコントローラとを備え、
前記第１通信モジュールが前記サービス開始信号を受信できないために、前記コントローラが前記第１タイプの電力サービスに従って前記複数の負荷装置を制御できない場合には、前記コントローラは、前記第１タイプの電力サービスから、前記識別子によって特定され、かつ、前記サービス開始信号を受信しなくとも実施可能な第２タイプの電力サービスに切り替え、
前記電力サービス期間中、前記コントローラは前記第２タイプの電力サービスに従って前記複数の負荷装置を制御する
制御装置。
【０２１６】
［付記２］
前記サービスは、価格信号、電気システムの特性の変化、サービスアグリゲーターによるイベントトリガー、デマンドレスポンス起動信号によって、制御されている複数の負荷装置の電力消費を変更する活動を含むデマンドレスポンス活動であって、
ピークカット、遮断可能な負荷、予備力ＤＲ、バランシングＤＲ、緊急バックアップＤＲ、周波数調整など一例であるがこれらに限定されないデマンドレスポンス活動である
付記１記載の制御装置。
【０２１７】
［付記３］
前記第１通信部が前記サービス開始信号を受信できなくても、前記制御装置が少なくとも電力サービスの開始時刻を予測できる場合には、前記コントローラは、前記電力サービス期間中、前記第１タイプの電力サービスに従って前記複数の負荷装置を制御する
付記１記載の制御装置。
【０２１８】
［付記４］
前記第１通信モジュールが前記サービス開始信号を受信した後、前記第１通信モジュールが通信できない場合に、前記コントローラが前記電力サービスの終了条件を予測できるのであれば、前記コントローラは、前記第１タイプの電力サービスに従って前記複数の負荷装置を制御し続ける
付記１記載の制御装置。
【０２１９】
［付記５］
前記コントローラが前記電力サービス期間の終了条件を予測できないのであれば、前記コントローラは、前記第１タイプの電力サービスから前記第２タイプの電力サービスへ切り替える
付記４記載の制御装置。
【０２２０】
［付記６］
前記第１通信モジュールは、前記電力サービス期間の電力サービス開始時刻と終了時刻とを含む、特定された複数の電力サービスのうちいずれかの予測スケジュールを事前に受信する
付記１記載の制御装置。
【０２２１】
［付記７］
前記コントローラは、前記第１通信モジュールを介して、関数、ソフトウェア、及び／又は、データを事前に受信して、前記識別子によって特定された複数の電力サービスのうちいずれかの電力サービススケジュールを予測する
付記１記載の制御装置。
【０２２２】
［付記８］
前記第１タイプの電力サービスは、予備力供給や調整供給などの非決定性ＤＲであり、前記第２タイプのデマンドレスポンスは、ピークカットなどの決定性ＤＲである
付記３記載の制御装置。
【０２２３】
［付記９］
前記複数の負荷装置は、電気エネルギー又は熱エネルギーを使用する装置、電気エネルギー又は熱エネルギーを生成する装置、及び／又は、電気エネルギー又は熱エネルギーを蓄積する装置を含む
付記１記載の制御装置。
【０２２４】
［付記１０］
前記第１通信モジュールが、前記第１タイプの電力サービスの開始時刻及び／又は終了時刻を取得できた場合に、前記コントローラは、前記第２タイプのサービスを開始させた一方で、前記コントローラは、前記複数の負荷装置に対して前記第１タイプの電力サービスを行うタイミングを決定する
付記１記載の制御装置。
【０２２５】
［付記１１］
複数の負荷装置を制御する制御方法であって、
ユーザがサービスプロバイダに提供できる電力サービスのタイプを特定するための識別子を、第１通信部を介して受信し、
特定された複数のサービスタイプの中から、所定の電力サービス期間に電力サービスを行う第１タイプの電力サービスを決定し、
前記第１タイプのサービスを行うための開始信号を第２通信部が受信できない場合、前記第１タイプのサービスから、前記開始信号を受信しなくとも実施可能な第２タイプの電力サービスに切り替え、前記電力サービス期間中、前記第２タイプの電力サービスに従って前記複数の負荷装置を制御する
制御方法。
【０２２６】
［付記１２］
前記サービスは、価格信号、電気システムの特性の変化、サービスアグリゲーターによるイベントトリガー、デマンドレスポンス起動信号によって、制御されている負荷リソースの電力負荷を変更する活動を含むデマンドレスポンス活動であって、ピークカット、遮断可能な負荷、予備力ＤＲ、バランシングＤＲ、緊急バックアップＤＲ、周波数調整などの様々なデマンドレスポンス活動である
付記１記載の制御装置。
【０２２７】
なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の制御装置などを実現するソフトウェアは、次のようなプログラムである。
【０２２８】
すなわち、このプログラムは、コンピュータに、ネットワークを介してサーバと接続され、負荷装置の電力需要の制御を行う制御装置における制御方法であって、前記サーバと前記制御装置とが通信可能であるか否かを判定する判定ステップと、予め定められたスケジュールに従って前記負荷装置の電力需要を制御する第一モード、及び、前記サーバからの指令信号に従って前記負荷装置の電力需要を制御する第二モードのいずれか一方の動作モードを実行する制御ステップとを含み、前記制御ステップでは、前記第二モードで前記制御を行っている場合であって、前記サーバとの通信が可能でないと前記判定ステップで判定した場合に、前記動作モードを前記第一モードに切り替えて前記制御を行う制御方法を実行させる。
【０２２９】
以上、一つまたは複数の態様に係る制御装置について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
【産業上の利用可能性】
【０２３０】
本発明は、通信手段に不具合が生じた場合にも適切にＤＲを制御することができる制御装置に利用可能である。
【符号の説明】
【０２３１】
１    制御システム
１００    サーバ
１０１、２０２    通信
１０２    データ
１０３    命令
１１０、２１０    通信部
１２０    プロセス管理部
１３０、２４０    メモリ
１４０    独立運用サポート部
１４１    ＤＲ事前スケジュール抽出部
１４２    ＤＲタイプ変更抽出部
１４３    ＤＲ期間予測部
２００    ＤＲコントローラ
２０１    負荷装置
２０３    ＤＲサービス
２０３ｕ    ユーザ
２０４    開始時刻
２０５    復帰時刻
２１１    制御部
２１４    開始信号
２１５    復帰信号
２２０    通信判定部
２３１    通常運用管理部
２３２    独立運用管理部
２４１    ＤＲデータ
２４２    ユーザデータ
２４３    負荷装置データ
２５０    インターフェース
３００    ＤＲ契約者
【図１Ａ】
0005979515.tif 000002
【図１Ｂ】
0005979515.tif 000003
【図２】
0005979515.tif 000004
【図３】
0005979515.tif 000005
【図４】
0005979515.tif 000006
【図５】
0005979515.tif 000007
【図６Ａ】
0005979515.tif 000008
【図６Ｂ】
0005979515.tif 000009
【図７】
0005979515.tif 000010
【図８】
0005979515.tif 000011
【図９】
0005979515.tif 000012
【図１０】
0005979515.tif 000013
【図１１Ａ】
0005979515.tif 000014
【図１１Ｂ】
0005979515.tif 000015
【図１１Ｃ】
0005979515.tif 000016
【図１２】
0005979515.tif 000017
【図１３】
0005979515.tif 000018
【図１４】
0005979515.tif 000019
【図１５】
0005979515.tif 000020
【図１６】
0005979515.tif 000021
【図１７】
0005979515.tif 000022
【図１８】
0005979515.tif 000023
【図１９】
0005979515.tif 000024
【図２０】
0005979515.tif 000025
【図２１】
0005979515.tif 000026
【図２２】
0005979515.tif 000027
【図２３】
0005979515.tif 000028
【図２４】
0005979515.tif 000029