JP2015202022A - エネルギー管理システム - Google Patents

Abstract

【課題】各家のエネルギー機器の運転計画を繰り返し作成する技術において、サーバの負荷の上昇を抑えつつも、機敏な運転計画作成を実現する。【解決手段】エネルギー管理端末は、設置先の家のエネルギー機器の動作状態を監視する。そして、設置先の家のエネルギー機器がイベント通知条件を満たす状態になったことに基づいて、イベント通知コマンド３２５および設置先の家のエネルギー機器によるエネルギー需給の実績データ３３５を、地域サーバに送信する。地域サーバは受信した実績データに基づいて、エネルギー管理端末が設置された家の機器運転計画３４０を作成してエネルギー管理端末に送信する。エネルギー管理端末は受信した機器運転計画３４０に基づいて設置先の需要家のエネルギー機器の制御を行う３４２。【選択図】図８

Description

本発明は、エネルギー管理システムに関するものである。

従来、地域単位でエネルギー消費量を管理するシステムとしてＣＥＭＳ（Ｃｌｕｓｔｅｒ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ ＳｙｓｔｅｍまたはＣｏｍｍｕｎｉｔｙ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）が提案されている。

このようなＣＥＭＳの一例として、特許文献１に記載の技術が知られている。特許文献１に記載の技術では、エネルギーネットワーク監視装置（以下、サーバという）が、複数の家（需要家、供給家）のエネルギー使用実績情報およびエネルギー供給情報を取得する。そして、サーバは、取得した情報に基づいて、これら家が使用するエネルギー需給量を予測し、予測の結果に基づいて、各家のエネルギー機器の運転計画を繰り返し計算する。

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

上記のような技術では、サーバが各家から繰り返し情報を取得して繰り返し運転計画を修正するが、各家が情報を送信する頻度が高い場合は、サーバが運転計画を修正する頻度も高くなってしまい、サーバの負荷が高くなり過ぎてしまう可能性が高くなる。かといって、各家が情報を送信する頻度を低くすれば、サーバによって作成される運転計画のリアルタイム性が損なわれてしまうおそれがある。

本発明は上記点に鑑み、各家のエネルギー機器の運転計画を繰り返し作成する技術において、サーバの負荷の上昇を抑えつつも、機敏な運転計画作成を実現することを目的とする。

上記目的を達成するための請求項１に記載の発明は、サーバ（１）と、複数の家（３ａ〜３ｃ）にそれぞれ設けられた複数のエネルギー管理端末（５ａ〜５ｃ）と、を備え、前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器（６１ａ〜６１ｃ、６２ａ〜６２ｃ、６３ａ〜６３ｃ）の動作状態を監視し、設置先の家のエネルギー機器がイベント通知条件を満たす動作状態になったことに基づいて、イベント通知コマンドを前記サーバに送信し、前記サーバは、前記複数のエネルギー管理端末のうち１つからイベント通知コマンドを受信すると、前記複数のエネルギー管理端末が設置された家のエネルギー機器の運転計画を作成して前記複数のエネルギー管理端末に送信し、前記複数のエネルギー管理端末の各々は、前記サーバから設置先の家のエネルギー機器の運転計画を受信すると、受信した運転計画に基づいて設置先の家のエネルギー機器の制御を行うことを特徴とするエネルギー管理システムである。

このように、複数のエネルギー管理端末の各々が、設置先の家のエネルギー機器の動作状態がイベント通知条件として設定された状態になったことに基づいて、イベント通知コマンドをサーバに送信する。そして、サーバは、イベント通知コマンドを受信すると、複数のエネルギー管理端末が設置された家のエネルギー機器の運転計画を作成して前記複数のエネルギー管理端末に送信する。

このように、設定によってあらかじめ定められた状態に遷移した場合を選んで、イベント通知コマンドの送信および運転計画の作成を行うので、運転計画の作成が必要なときを選んで送信することが可能になる。各家のエネルギー機器の運転計画を繰り返し作成する技術において、サーバの負荷の上昇を抑えつつも、機敏な運転計画作成を実現することができる。

本発明の実施形態に係るエネルギー管理システムの構成図である。 地域サーバの構成図である。 エネルギー管理端末の構成図である。 計画処理のフローチャートである。 イベント通知条件設定処理のフローチャートである。 イベント通知条件管理処理のフローチャートである。 通知処理のフローチャートである。 エネルギー管理システムの作動例のシーケンス図である。 消費電力の推移とイベント発動の関係を示す図である。 本発明の実施形態に係るエネルギー管理システムの構成図である。 エネルギー管理システムにおけるイベント通知処理の処理シーケンスを示す図である。 エネルギー管理システムにおけるイベント通知条件設定処理の処理シーケンスを示す図である。 既存のＨＥＭＳシステムの内部構成図である。 ＨＥＭＳシステムの新規内部構成図である。 電力閾値超過イベント通知の流れの図である。 イベント通知における各エネルギー機器間の通信の流れの図である。 イベント通知における通信シーケンスの図である。 イベント設定コマンド（地域サーバ → ＨＥＭＳ）の表である。 イベント設定コマンド（地域サーバ → ＨＥＭＳ）の表である。 イベント設定コマンド（地域サーバ → ＨＥＭＳ）の表である。 イベント設定コマンド（地域サーバ → ＨＥＭＳ）の表である。 イベント設定コマンド（ＨＥＭＳ → 地域サーバ）の表である。 イベント設定コマンド（ＨＥＭＳ → 地域サーバ）の表である。 イベント設定コマンド（ＨＥＭＳ → 地域サーバ）の表である。 各エネルギー機器間の電力実績情報の収集周期を示す図である。 ピークカット機能の動作の流れを示す図である。

（第１実施形態）
以下、本発明の第１実施形態について説明する。図１に示す本実施形態に係るエネルギー管理システム１００は、ＣＥＭＳ（Ｃｌｕｓｔｅｒ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ ＳｙｓｔｅｍまたはＣｏｍｍｕｎｉｔｙ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）を実現するためのものである。このエネルギー管理システム１００は図１に示すように、地域サーバ１と、系統電力供給側端末２を備えると共に、複数の需要家３ａ〜３ｃを含んでいる。

エネルギー管理システム１００に含まれる需要家は、同じ地域内に建てられている。エネルギー管理システム１００に含まれる需要家の数は、１０戸程度でもよいし、１００個程度でもよいし、１０００個程度でもよいが、本実施形態では、一例として３つの需要家３ａ〜３ｃがエネルギー管理システム１００に含まれている。なお、本実施形態においては、需要家３ａ〜３ｃは、それぞれ、発電機が設置された供給家でもある。

需要家３ａ〜３ｃは、それぞれ、ゲートウェイ４ａ〜４ｃ、エネルギー管理端末５ａ〜５ｃ、およびエネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃを有している。需要家３ａを例に取ると、需要家３ａは、ゲートウェイ４ａ、エネルギー管理端末５ａ、エネルギー機器６１ａ、６２ａ、６３ａを有している。

地域サーバ１は、ゲートウェイ４ａ〜４ｃを介してエネルギー管理端末５ａ〜５ｃと通信することで、エネルギー管理システム１００全体のエネルギー需給のピークシフトもしくは平準化を行う装置である。

図２に示すように、地域サーバ１は、通信部１１、メモリ１２、演算部１３を有している。通信部１１は、系統電力供給側端末２と通信し、ゲートウェイ４ａ〜４ｃを介してエネルギー管理端末５ａ〜５ｃと通信するためのネットワークインターフェースである。メモリ１２は、演算部１３が実行するプログラムおよび各種パラメータが記録された記憶媒体である。演算部１３は、メモリ１２に記録されたプログラムを実行することで、後述する計画処理１３ａ、イベント通知条件設定処理１３ｂ等を実行する演算回路である。演算部１３は、計画処理１３ａ、イベント通知条件設定処理１３ｂを、同時並行的にマルチタスクで実行する。

系統電力供給側端末２は、需要家３ａ〜３ｃの各装置４ａ〜４ｃ、５ａ〜５ｃ、６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃに電力を供給する系統電力供給源（発電所等）の電力供給情報（供給可能電力の上限値等）を繰り返し定期的に作成して地域サーバ１に送信する装置である。

ゲートウェイ４ａ〜４ｃは、設置先の需要家（自機が設置された需要家）内のエネルギー管理端末５ａ〜５ｃと地域サーバ１との通信を媒介する装置（例えば宅内ルータ）である。

エネルギー管理端末５ａ〜５ｃは、地域サーバ１から受信する設置先の需要家における各エネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃの動作を制御すると共に、当該各エネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃの動作状態を監視する。

エネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃは、例えば、室内空調装置、照明機器、電気床暖房装置等の、電力を消費して動作する電気エネルギー機器を含んでいてもよい。また更に、電力を供給する発電機（例えば太陽光発電機、ガスを燃料として発電するガス発電機、水素を燃料として発電する水素発電機）を含んでいてもよい。また更に、貯湯装置を含む給湯器（例えば電力で湯を沸かすＣＯ_２サイクル給湯器）を含んでいてもよいし、電力を蓄積する蓄電装置を含んでいてもよいし、水素発電機で使用される水素を蓄積する水素蓄積装置を含んでいてもよい。

図３に示すように、エネルギー管理端末５ａ〜５ｃの各々（以下、単にエネルギー管理端末５と記す）は、通信部５１、メモリ５２、操作部５３、制御部５４を有している。

通信部５１は、ゲートウェイ４ａ〜４ｃのうち同じ家に設置されたゲートウェイを介して地域サーバ１と通信するための宅外通信インターフェースを備えて、更に、エネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃのうち同じ家に設置されたエネルギー機器と通信するための宅内通信インターフェースを備えている。

メモリ５２は、後述するイベント通知条件５２１、カウンタ値５２２等を記録するための不揮発性メモリ（例えばフラッシュメモリ）である。操作部５３は、ユーザの操作を直接受け付ける装置である。制御部５４は、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備えたマイクロコンピュータであり、ＣＰＵがＲＯＭに記録されたプログラムを実行し、その実行の際にＲＡＭを作業領域として使用する。ＣＰＵがＲＯＭに記録されたプログラムを実行することで実現する処理には、エネルギー需給測定処理５４１、通知処理５４２、エネルギー機器制御処理５４３、通知条件管理処理５４４が含まれる。制御部５４は、これら処理５４１〜５４４をマルチタスクで同時並列的に実行する。

以下、上記のような構成のエネルギー管理システム１００の作動について詳細に説明する。この作動においては、エネルギー管理端末５のメモリ５２には、イベント通知条件５２１として、以下のような条件のすべてがｏｒ条件として記録されている。なお、他の例として、複数の条件がａｎｄ条件として記録されていてもよいし、ｏｒとａｎｄの複合条件で記録されていてもよい。
（ａ）設置先の需要家内の総消費電力が上限値Ｐｍａｘ（閾値）より大きくなったという条件
（ｂ）設置先の需要家内の総消費電力が下限値Ｐｍｉｎ（閾値）より小さくなったという条件
（ｃ）設置先の需要家の貯湯装置の貯湯量が下限値Ｃｍｉｎ（閾値）より小さくなったという条件
（ｄ）設置先の需要家のエネルギー機器が故障したという条件
（ｅ）操作部５３に対して設置先の需要家のエネルギー機器の作動を変更するユーザ操作が発生したという条件
なお、上記（ｃ）の貯湯装置は、電力で湯を沸かす給湯器から湯が供給されるものに限定されてもよい。

まず、エネルギー管理端末５の制御部５４が実行するエネルギー需給測定処理５４１、機器制御処理５４３について説明する。制御部５４は、エネルギー需給測定処理５４１を常時実行することで、設置先の需要家に設置された各エネルギー機器の動作状態を逐次（例えば繰り返し定期的に１秒に１回）監視する。

監視される各エネルギー機器の動作状態には、各エネルギー機器のエネルギー需給の量、蓄電池の蓄電量、貯湯装置の貯湯量、各エネルギー機器の故障の有無、需要家内の操作部５３に対するユーザ操作による各エネルギー機器の動作の変化等が含まれる。このように、制御部５４は、エネルギー需給測定処理５４１を実行することで、エネルギー需給測定部として機能する。これら動作状態は、通信部５１を介して各エネルギー機器から受信してもよい。また、各エネルギー機器のエネルギー需給の量については、図示しない分電盤からの信号に基づいて特定してもよい。

なお、本実施形態におけるエネルギー機器のエネルギー需給の量は、当該エネルギー機器に供給される電力をＡとし、当該エネルギー機器から外部に供給される電力をＢとすると、Ａ−Ｂである。例えば、空調装置、照明機器のように電力を専ら消費するエネルギー機器の場合は、消費電力がエネルギー需給の量となる。また、発電装置の発電電力に−１を乗算した値が、発電装置のエネルギー需給の量となる。また、蓄電装置が逐電している場合は、エネルギー需給の量が正となり、放電している場合は、エネルギー需給の量が負となる。

また制御部５４は、エネルギー機器制御処理５４３を常時実行することで、設置先の需要家のエネルギー機器の作動を制御する（すなわち、運転する）。より具体的には、地域サーバ１から後述する運転計画を受信したことに基づいて、設置先の需要家のエネルギー機器を、当該運転計画に指定されたスケジュールの通りに作動するよう制御する。また、操作部５３に対して設置先の需要家のエネルギー機器の作動を変更するユーザ操作が発生した場合、そのユーザ操作の内容に従って、当該エネルギー機器の作動を制御する。例えば、操作部５３に対するユーザ操作に応じて、蓄電装置の充電と放電を切り替える。

次に、地域サーバ１の作動について説明する。地域サーバ１の演算部１３は、常時実行している計画処理１３ａにおいて、図４に示すように、ステップ１０５で、一定時間（具体的には３０分）間隔で訪れる定期通信タイミングが訪れたか否かを判定し、訪れていない場合はステップ１１０に進む。ステップ１１０では、イベント通知コマンドをエネルギー管理端末５ａ〜５ｃのいずれかから新たに受信したか否かを判定し、受信していないなら、ステップ１０５に戻る。つまり、地域サーバ１の演算部１３は、計画処理１３ａにおいて、定期通信タイミングが訪れるか、イベント通知コマンドを受信するまで、ステップ１０５、１１０のループを繰り返す。

また、地域サーバ１の演算部１３は、常時実行しているイベント通知条件設定処理１３ｂにおいて、図５に示すように、まずステップ１６０で、エネルギー管理端末５ａ〜５ｃのいずれか１つ以上に対してイベント通知条件またはカウンタ値の設定変更を行うことが必要か否かを判定する。

イベント通知条件もカウンタ値も設定変更を行うことが必要でないと判定した場合は、再度ステップ１６０を実行する。つまり演算部１３は、イベント通知条件を設定変更する必要があると判定するか、カウンタ値を設定変更する必要があると判定するまで、ステップ１６０の判定を繰り返す。

イベント通知条件またはカウンタ値の設定変更を行うことが必要であると判定する場合の例としては、以下の（例１）〜（例３）がある。

（例１）演算部１３は、季節の変わり目に相当する日の所定時刻が訪れたときに、エネルギー管理端末５ａ〜５ｃのすべてに対してイベント通知条件の設定変更を行うことが必要であると判定し、ステップ１７０に進む。季節の変わり目に相当する日の所定時刻としては、例えば、４月１日の０時０分０秒、７月１日の０時０分０秒、９月１日の０時０分０秒、１２月１日の０時０分０秒がある。このようにするのは、季節によって、各需要家の電力消費量が大きく異なるからである。

（例２）演算部１３は、日中（例えば８時０分０秒から４時０分０秒まで）に、需要家３ａ〜３ｃの所在する地域の天候が晴れから曇りまたは雨に、または逆に変化した場合、設置先の需要家に太陽光発電装置が取り付けられているいないに関わらずすべてのエネルギー管理端末５ａ〜５ｃに対してイベント通知条件の設定変更を行うことが必要であると判定し、ステップ１７０に進む。このようにするのは、天候が曇りまたは雨の場合は、晴れの場合に比べて、太陽光発電装置の発電量が大きく低下するから、系統電力源から得られる電力が逼迫する可能性が高くなるからである。なお、演算部１３は、需要家３ａ〜３ｃの所在する地域の天候は、例えば、通信部１１を用いて図示しない天候サーバから繰り返し（例えば定期的に１０分に１回）取得するようになっていてもよい。

（例３）演算部１３は、ある需要家のエネルギー管理端末５から後述するイベント通知コマンドを連続して上限回数以上受信したことに基づいて、当該エネルギー管理端末５に対してカウンタ値の設定変更を行うことが必要であると判定し、ステップ１７０に進む。

（例１）〜（例３）のようにステップ１７０に進むと、ステップ１７０では、ステップ１６０で必要であると判定された場合にイベント通知条件を更新する。上記（例３）に該当する場合は、イベント通知条件を更新しない。

上記（例１）に該当する場合は、すべてのエネルギー管理端末５ａ〜５ｃに対するイベント通知条件のうち、各需要家における総電力消費量の上限値および下限値を変化させる。例えば、春から夏に季節が変化した場合は、後述する各需要家における総電力消費の上限値Ｐｍａｘおよび下限値Ｐｍｉｎを低下させる。また例えば、夏から秋に季節が変化した場合は、後述する各需要家における総電力消費の上限値Ｐｍａｘおよび下限値Ｐｍｉｎを上昇させる。なお、上限値Ｐｍａｘおよび下限値Ｐｍｉｎは、後述するイベント通知条件の判定に用いられると共に、後述するテンプレートの選択にも用いられる。

上記（例２）に該当する場合でも、すべてのエネルギー管理端末５ａ〜５ｃに対するイベント通知条件のうち、各需要家における総電力消費の上限値および下限値を変化させる。例えば、晴れから曇りまたは雨に天候が変化した場合は、各需要家における総電力消費の上限値Ｐｍａｘおよび下限値Ｐｍｉｎを低下させる。また例えば、曇または雨から晴れに天候が変化した場合は、各需要家における総電力消費の上限値Ｐｍａｘおよび下限値Ｐｍｉｎを上昇させる。

続くステップ１８０では、ステップ１６０で必要であると判定された場合にカウンタ値を更新する。上記（例１）、（例２）に該当する場合は、カウンタ値を更新しない。上記（例３）に該当する場合は、カウンタ値をそれまでよりも増加させる。例えば１から５に上昇させる。なお、カウンタ値が５以上の状態が所定期間続いた場合には、カウンタ値を１に戻してもよい。

続いてステップ１９０では、通信部１１を用いてイベント設定コマンドをエネルギー管理端末５ａ〜５ｃに送信する。

このイベント設定コマンドには、更新されたイベント通知条件も更新されていないイベント通知条件も含んだすべてのイベント通知条件が含まれていてもよいし、更新されたイベント通知条件のみが含まれていてもよい。また、このイベント設定コマンドには、更新されていてもいなくても、カウンタ値が含まれるようになっていてもよいし、更新された場合にのみカウンタ値が含まれるようになっていてもよい。

また、送信先のエネルギー管理端末５毎に、イベント設定コマンドに含まれるイベント通知条件の内容は異なっていてもよいし、同じでもよい。また、送信先のエネルギー管理端末５毎に、カウンタ値の内容は異なっていてもよいし、同じでもよい。また、イベント設定コマンドは、更新が必要なエネルギー管理端末５のみに送信されてもよいし、毎回すべてのエネルギー管理端末５ａ〜５ｃに送信されてもよい。なお、イベント設定コマンドの内容については、後述の（追加構成）で説明する通りになっていてもよい。ステップ１９０の後、ステップ１５０に戻る。

上記図８に示す作動例では、時点ｔ１において、上記（例１）〜（例３）のいずれかに該当し、その結果、イベント設定コマンド３０５が地域サーバ１からエネルギー管理端末５に送信される。エネルギー管理端末５では、制御部５４が図６に示す通知条件管理処理５４４を常時実行しており、そのステップ２６０において、通信部５１を介して地域サーバ１からイベント設定コマンドを受信したか否かを判定し、受信したと判定するまでは、ステップ２６０を繰り返す。そして、受信したと判定すると、ステップ２７０に進み、受信したイベント設定コマンドの内容をメモリ５２に記録する（図８のステップ３０７）。具体的には、受信したイベント設定コマンドに含まれるすべてのイベント通知条件およびカウンタ値をメモリ５２内に上書きする。なお、図８の例では、ステップ３０７の記録により、エネルギー管理端末５ａ〜５ｃのカウンタ値５２２がすべて１になったとする。

なお、図８では、簡単のためにエネルギー管理端末を１つのみ記載しているが、実際に地域サーバ１と通信するのは複数個のエネルギー管理端末５ａ〜５ｃである。

また、制御部５４は、常時実行する通知処理５４２において、図７に示すように、まずステップ２１０で、通信部５１を介して後述する実績データ要求を地域サーバ１から受信したか否かを判定し、受信していない場合はステップ２２０に進む。そしてステップ２０では、イベントが発動したか否かを判定し、発動していなければステップ２２０に戻る。イベントが発動するのは、メモリ５２中のイベント通知条件５２１のいずれかが満たされた状態がカウンタ値５２２の回数だけ連続した場合のみである。なお、ステップ２２０をＮ回実行したうちの、連続したＭ回でイベント通知条件５２１のいずれかが満たされた場合が、イベント通知条件５２１のいずれかが満たされた状態がＭ回続いたことになる。このようになっているので、制御部５４は、実績データ要求を受信するか、イベントが発動するまで、ステップ２１０、２２０の判定を繰り返す。

なお、演算部１３は、後述するステップ２３０、２４０を実行するしないに関わらず、ステップ２２０を実行してから次にステップ２２０を実行するまでの期間は一定（例えば１分）である。

図８の時点ｔ１の後は、次の定期通信タイミングである時点ｔ２が訪れるまで、エネルギー管理端末５でイベントは発動せず、地域サーバ１でイベント通知コマンドは送信されず、地域サーバ１で実績データ要求も送信されず、設定変更が必要にもならなかったとする。

この場合、時点ｔ１より後かつ時点ｔ２より前の期間においては、地域サーバ１の演算部１３は、計画処理１３ａでステップ１０５、１１０の判定（ＮＯ）を繰り返し、イベント通知条件設定処理１３ｂでステップ１６０の判定（ＮＯ）を繰り返す。また、エネルギー管理端末５の制御部５４は、通知条件管理処理５４４でステップ２６０の判定（ＮＯ）を繰り返し、通知処理５４２でステップ２１０、２２０の判定（ＮＯ）を繰り返す。また制御部５４は、エネルギー需給測定処理５４１で設置先の需要家に設置された各エネルギー機器の動作状態を逐次（例えば繰り返し定期的に１秒に１回）監視する。また制御部５４は、機器制御処理５４３で、時点ｔ１よりも前に地域サーバ１から受信した機器運転計画に従って、設置先の需要家のエネルギー機器の作動を制御する。

時点ｔ２になると、前回の定期通信タイミングから一定時間（例えば３０分）が経過し、それと同時に、演算部１３が、計画処理１３ａのステップ１０５で定期通信タイミングであると判定し、ステップ１１５に進む。ステップ１１５では、通信部１１を用いてエネルギー管理端末５ａ〜５ｃへ実績データ要求３１０を送信し、続いてステップ１２０に進み、所定時間（例えば５分）実績データの受信を待つ。

すると、エネルギー管理端末５の制御部５４は、通信部５１を介してこの実績データ要求３１０を受信し、通知処理５４２のステップ２１０で実績データ要求を受信したと判定し、ステップ２３０に進む。ステップ２３０では、実績データ３１５を作成して地域サーバ１に送信し、その後ステップ２２０に進む。実績データは、現在から過去の所定期間（例えば直近３０分でもよいし、実績データを前回送信した時点から現在までの期間でもよい）においてエネルギー需給測定処理５４１によって得た各エネルギー機器の動作状態に基づいて作成する。

作成される実績データには、エネルギー管理端末５の設置先の需要家における、全エネルギー機器の現在から過去の所定期間のエネルギ需給の量、貯湯装置の貯湯量、蓄電装置の蓄電量が含まれる。更に、作成される実績データには、エネルギー管理端末５の設置先の需要家の各エネルギー機器における、現時点の故障の有無、および、現時点の動作状態が含まれる。動作状態には、例えば、空調装置の設定温度、床暖房装置の設定温度等が含まれる。

地域サーバ１の演算部１３は、計画処理１３ａのステップ１２０で、上記所定期間（例えば５分）内に、エネルギー管理端末５ａ〜５ｃから送信された実績データを通信部１１を介して受信する。

続いてステップ１２５では、受信した実績データに基づいて、現時点より後の期間における需要家３ａ〜３ｃ全体のエネルギー需給の量を予測する。具体的には、受信した実績データに適合するテンプレートをあらかじめ定められた複数個のテンプレートから選び出し、選び出したテンプレートに対応付けられたエネルギー需給の量の経時変化を、実績データの送信元の需要家のエネルギー需給の量の経時変化の予測として採用する。そして、このようにして決められた各需要家のエネルギー需給の量の経時変化の予測から、需要家３ａ〜３ｃ全体のエネルギー需給の量の予測とする。なお、テンプレートに対応付けられるエネルギー需給の量の経時変化は、テンプレート毎に異なっている。

ここで、当該実績データの送信元の需要家に設置された全エネルギー機器全体の、最新のエネルギー需給の量Ｐ、すなわち、当該需要家の最新の総消費電力Ｐは、当該実績データから算出できるが、この総消費電力Ｐの大小によって、選び出されるテンプレートが異なる。

より具体的には、この総消費電力Ｐと、当該需要家についての上述のイベント通知条件（ａ）、（ｂ）中の上限値Ｐｍａｘおよび下限値Ｐｍｉｎとの関係に応じて、選び出されるテンプレートが異なる。つまり、（１）この総消費電力Ｐが上限値Ｐｍａｘよりも大きい場合、（２）上限値Ｐｍａｘ以下かつ下限値Ｐｍｉｎ以上の場合、（３）下限値Ｐｍｉｎ未満の場合の３つの場合では、それぞれ、選ばれるテンプレートが異なる。したがって、これら３つの場合では、それぞれ、エネルギー需給の量の経時変化の予測も異なる。

また、当該実績データに含まれる貯湯装置の貯湯量Ｃの最新値の大小によって、選び出されるテンプレートが異なる。より具体的には、この貯湯量Ｃが、当該需要家についての上述のイベント通知条件（ｃ）中の下限値Ｃｍｉｎ以上の場合と、下限値Ｃｍｉｎ未満の場合の２つの場合では、それぞれ、選ばれるテンプレートが異なる。したがって、これら２つの場合では、それぞれ、エネルギー需給の量の経時変化の予測も異なる。

また、当該実績データに含まれるエネルギー機器の故障の有無の違いによって選び出されるテンプレートが異なる。したがって、エネルギー機器の故障の有無の違いによって、エネルギー需給の量の経時変化の予測も異なる。

また、当該実績データに含まれる各エネルギー機器の作動内容が、機器運転計画通りであるか否かで、選び出されるテンプレートが異なる。したがって、各エネルギー機器の作動内容が機器運転計画通りであるか否かで、エネルギー需給の量の経時変化の予測も異なる。

ステップ１２５では更に、系統電力供給側端末２から受信した系統電力供給源（発電所等）の電力供給情報に基づいて、現時点より後の期間における系統電力供給源のエネルギー供給量を予測する。

更にステップ１２５では、算出した需要家３ａ〜３ｃ全体のエネルギー需給量の予測結果、および、系統電力供給源のエネルギー供給量の予測結果に基づいて、エネルギー管理システム１００全体の現時点より後の期間におけるエネルギー需給のピークシフトもしくは平準化を行うため、需要家３ａ〜３ｃのエネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃの運転計画（以下、機器運転計画という）を作成する（ステップ３１７）。

機器運転計画は、エネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃの作動をどの時間帯にどのように制御するかについてのスケジュール（タイムテーブル）である。例えば、発電機に発電させるか否か、貯湯装置の貯湯量を増加させるか減少させるか、蓄電池に充電させるか放電させるか、空調装置の設定温度、テレビの輝度等についての計画が、機器運転計画に該当する。

エネルギー需給量の予測結果等に基づいて、エネルギー需給のピークシフトもしくは平準化を行うために機器運転計画をどのように作成するかについては、例えば特許文献１に記載されているように周知である。例えば、需要家３ａ〜３ｃ全体の消費電力の予測値が基準値を超えると予測された時間帯では、需要家３ａ〜３ｃ内のすべての充電池に放電させ、基準値以下となる時間帯では、当該充電池に充電させるように計画を作成してもよい。また例えば、需要家３ａ〜３ｃ全体の消費電力の予測値が基準値以下となる時間帯では、電力によって湯を沸かす給湯装置から湯が供給される貯湯装置の貯湯量を増加させるように計画を作成してもよい。

続いてステップ１３０では、通信部１１を用いて、ステップ１２５で作成した機器運転計画を、エネルギー管理端末５ａ〜５ｃに送信する。エネルギー管理端末５ａ〜５ｃの各々に送信する機器運転計画３２０は、ステップ１２５で作成した機器運転計画のうち、当該エネルギー管理端末５の設置先の需要家のエネルギー機器についての計画のみとしてもよい。

エネルギー管理端末５ａ〜５ｃにおいては、制御部５４が、通信部５１を介してこの機器運転計画３２０を受信すると、機器制御処理５４３において、この新たな機器運転計画３２０中のスケジュールに設置先の需要家のエネルギー機器が従うよう、当該エネルギー機器の作動を制御し始める（ステップ３２２）。

図８のステップ３２２の実行時点の後は、時点ｔ３が訪れるまで、エネルギー管理端末５でイベントは発動せず、地域サーバ１でイベント通知コマンドは送信されず、地域サーバ１で実績データ要求も送信されず、設定変更が必要にもならなかったとする。この場合、ステップ３２２実行時点より後かつ時点ｔ３より前の期間においては、時点ｔ１より後かつ時点ｔ２より前の期間と同様の作動となる。

時点ｔ３になると、あるエネルギー管理端末５において、自機のメモリ５２に記録されているイベント通知条件５２１のうち１つ（上記（ａ）、（ｂ）、（ｃ）、（ｄ）、（ｅ）のうちどれでもよい）が満たされていると判定する。制御部５４は、通知処理５４２のステップ２２０において、イベント通知条件５２１のうち１つが満たされ、かつ、イベント通知条件５２１のうち同じ１つが連続して満たされる回数がカウンタ値５２２以上となった場合に限り、イベントが発動したと判定する。本事例では、イベント通知条件５２１の値が１なので、イベント通知条件５２１のうち１つが初めて満たされた場合に、ステップ２２０でイベントが発動したと判定される。

制御部５４は、ステップ２２０でイベントが発動したと判定すると、ステップ２４０に進み、通信部５１を用いてイベント通知コマンド３２５を地域サーバ１に送信し、ステップ２１０に進む。イベント通知コマンド３２５には、送信元のエネルギー管理端末５を特定する識別コードが含まれているので、地域サーバ１では、受信したイベント通知コマンド３２５がどのエネルギー管理端末５から送信されたかがわかる。イベント通知コマンドの内容については、後述の（追加構成）で説明する通りになっていてもよい。

地域サーバ１の演算部１３は、通信部１１を介してこのイベント通知コマンド３２５を受信すると、計画処理１３ａのステップ１１０で、イベント通知コマンドを受信したと判定し、ステップ１１５に進む。

ステップ１１５からステップ１３０までの処理内容およびエネルギー管理システム１００全体の作動は、ステップ１０５からステップ１１５に進んだ場合（既に説明済み）と、以下で説明する違いを除いて同様である。

簡単に説明すると、ステップ１１５では、エネルギー管理端末５へ実績データ要求３３０を送信し、続いてステップ１２０に進み、所定時間（例えば５分）実績データの受信を待つ。ただし、実績データ要求３３０の送信先のエネルギー管理端末５は、イベント通知コマンド３２５の送信元のエネルギー管理端末５のみである点が、ステップ１０５からステップ１１５に進んだ場合と異なる。

すると、当該エネルギー管理端末５の制御部５４は、この実績データ要求３３０を受信し、通知処理５４２のステップ２１０で実績データ要求を受信したと判定し、ステップ２３０に進む。ステップ２３０では、実績データ３３５を作成して地域サーバ１に送信し、その後ステップ２２０に進む。そして、時点ｔ３のイベント発動後にはイベントが発動していないので、ステップ２２０から２１０に戻る。

地域サーバ１の演算部１３は、計画処理１３ａのステップ１２０で、上記所定期間（例えば５分）内に、当該エネルギー管理端末５から送信された実績データ３３５を受信する。

続いてステップ１２５では、受信した実績データ３３５に基づいて、現時点より後の期間における需要家３ａ〜３ｃ全体のエネルギー需給の量を予測する。ここで作成される予測は、それまでのエネルギー需給の量の予測と異なっている。なぜなら、ある需要家で上述のイベント通知条件（ａ）〜（ｅ）のいずれかが満たされたということは、ステップ１２５において当該需要家について選択されるテンプレートがそれまでとは違うものになるからである。

更に、系統電力供給側端末２から受信した系統電力供給源（発電所等）の電力供給情報に基づいて、現時点より後の期間における系統電力供給源のエネルギー供給量を予測する。更にステップ１２５では、これら予測結果に基づいて、エネルギー管理システム１００全体の現時点より後の期間におけるエネルギー需給のピークシフトもしくは平準化を行うため、需要家３ａ〜３ｃのエネルギー機器６１ａ〜６３ａ、６１ｂ〜６３ｂ、６１ｃ〜６３ｃの機器運転計画を作成する（ステップ３３７）。

ここで作成された機器運転計画は、それまでの機器運転計画と異なっている。それは、需要家３ａ〜３ｃ全体のエネルギー需給の量の予測が今までとは違うものになったからである。

続いてステップ１３０では、ステップ１２５で作成した機器運転計画３４０を、エネルギー管理端末５ａ〜５ｃに送信する。エネルギー管理端末５ａ〜５ｃの各々に送信する機器運転計画３２０は、ステップ１２５で作成した機器運転計画のうち、当該エネルギー管理端末５の設置先の需要家のエネルギー機器についての計画のみとしてもよい。

エネルギー管理端末５ａ〜５ｃにおいては、制御部５４がこの機器運転計画３４０を受信すると、機器制御処理５４３において、この新たな機器運転計画３４０の内容に設置先の需要家のエネルギー機器が従うよう、当該エネルギー機器の作動を制御し始める（ステップ３４２）。

なお、ある需要家において上記（ａ）、（ｂ）のようなイベント通知条件が満たされたときは、消費電力が通常想定される範囲から外れてしまうことになるので、それよりも前に地域サーバ１の演算部１３が計画処理１３ａのステップ１２５で行った予測が著しく不正確になる可能性が高い。したがって、そのような場合にイベント通知コマンド３２５および実績データ３３５を地域サーバ１に送信すれば、ステップ１２５が再度実行され、予測の不正確性が緩和され、ひいては、機器運転計画が適切なものになる。

また、ある需要家において上記（ｃ）のようなイベント通知条件が満たされたときは、貯湯量が通常想定される範囲から外れてしまうことになるので、それよりも前に地域サーバ１の演算部１３が計画処理１３ａのステップ１２５で行った予測が著しく不正確になる可能性が高い。したがって、そのような場合にイベント通知コマンド３２５および実績データ３３５を地域サーバ１に送信すれば、ステップ１２５が再度実行され、予測の不正確性が緩和され、ひいては、機器運転計画が適切なものになる。

また、ある需要家において上記（ｄ）のようなイベント通知条件が満たされたときは、故障したエネルギー機器（例えば発電機）が使用不能になるので、それよりも前に地域サーバ１の演算部１３が計画処理１３ａのステップ１２５で行った予測が著しく不正確になる可能性が高い。したがって、そのような場合にイベント通知コマンド３２５および実績データ３３５を地域サーバ１に送信すれば、ステップ１２５が再度実行され、予測の不正確性が緩和され、ひいては、機器運転計画が適切なものになる。

また、ある需要家において上記（ｅ）のようなイベント通知条件が満たされたときは、故障したエネルギー機器（例えば発電機）が使用不能になるので、それよりも前に地域サーバ１の演算部１３が計画処理１３ａのステップ１２５で作成した機器運転計画が実現しなくなる可能性が高い。したがって、そのような場合にイベント通知コマンド３２５および実績データ３３５を地域サーバ１に送信すれば、ステップ１２５が再度実行され、機器運転計画をユーザ操作と矛盾しないものに変更することができる。

図８のステップ３４２の実行時点の後は、時点ｔ４が訪れるまで、エネルギー管理端末５でイベントは発動せず、地域サーバ１でイベント通知コマンドは送信されず、地域サーバ１で実績データ要求も送信されず、設定変更が必要にもならなかったとする。この場合、ステップ３４２実行時点より後かつ時点ｔ４より前の期間においては、ステップ３２２実行時点より後かつ時点ｔ３より前の期間と同様の作動となる。

時点ｔ４になると、前回の定期通信タイミング（時点ｔ２）から一定時間（例えば３０分）が経過し、それと同時に、演算部１３が、計画処理１３ａのステップ１０５で定期通信タイミングであると判定し、ステップ１１５に進む。これ以降のエネルギー管理システム１００の作動は、時点ｔ２以降かつ時点ｔ３より前における作動の説明において、実績データ要求３１０、実績データ３１５、ステップ３１７、機器運転計画３２０、ステップ３２２を、それぞれ、実績データ要求３４５、実績データ３５０、ステップ３５２、機器運転計画３５５、ステップ３５７に読み替えたものと同じである。

以上が、図８の例の説明である。なお、図８の例では、カウンタ値５２２がすべて１であったので、エネルギー管理端末５ａ〜５ｃの制御部５４は通知処理５４２のステップ２２０で、イベント通知条件が満たされるだけでイベントが発動したと判定している。

例えば、ある需要家内において演算部１３のエネルギー需給測定処理５４１によって検出される総消費電力の推移が、図９の実線７０のようになっているとする。そして、時点ｔ１１において上述のｔ１と同様の作動によってカウンタ値５２２が１から５に変化し、
時点ｔ１２において上述のｔ１と同様の作動によってイベント通知条件５２１に含まれる設置先の需要家内の総消費電力の上限値７１が上昇したとする。実線７０中の黒丸印が、ステップ２２０でイベント発動の有無が判定されたタイミング（すなわち、ステップ２２０でイベント通知条件が満たされたか否かが判定されたタイミング）に相当する。

図９の例では、時点ｔ１１の前は、総消費電力７１が上限値を超える度にイベントが発動したと判定されていたのに対し、時点ｔ１１でカウンタ値が５に増加して以降は、総消費電力７１が上限値を連続して５回超えて初めてイベントが発動するようになっている。このように、カウンタ値を２以上にすることで、同じイベント通知条件に基づくイベント通知コマンド、実績データ送信、および図４のステップ１２５の処理が過度に頻繁に行われてしまう可能性が低減される。

以上説明した通り、エネルギー管理端末５ａ〜５ｃの各々は、設置先の家のエネルギー機器６１ａ〜６１ｃ、６２ａ〜６２ｃ、６３ａ〜６３ｃの動作状態を監視する。そして、設置先の家のエネルギー機器がイベント通知条件を満たす状態になったことに基づいて、イベント通知コマンド３２５および設置先の家のエネルギー機器によるエネルギー需給の実績データ３３５を、地域サーバ１に送信する。

そして地域サーバ１は、エネルギー管理端末５ａ〜５ｃのうち１つから、当該１つのエネルギー管理端末が設置された家のエネルギー機器によるエネルギー需給の実績データ３３５を受信すると、受信した実績データ３３５に基づいて、エネルギー管理端末５ａ〜５ｃ（イベント通知コマンド３２５および実績データ３３５の送信元も含む）が設置された家の機器運転計画３４０を作成してエネルギー管理端末５ａ〜５ｃに送信する。

そしてエネルギー管理端末５ａ〜５ｃの各々は、地域サーバ１から設置先の家のエネルギー機器の機器運転計画３４０を受信すると、受信した機器運転計画３４０に基づいて設置先の家のエネルギー機器の制御を行う。

このように、複数のエネルギー管理端末の各々が、設置先の家のエネルギー機器の動作状態がイベント通知条件として設定された状態に遷移したことに基づいて、エネルギー需給の実績データをサーバに送信する。そして、サーバは、エネルギー需給の実績データを受信すると、受信した実績データに基づいて、複数のエネルギー管理端末が設置された家のエネルギー機器の運転計画を作成して前記複数のエネルギー管理端末に送信する。

このように、設定によってあらかじめ定められた状態に遷移した場合を選んで、エネルギー需給の実績データの送信および運転計画の作成を行うので、過度に頻繁にエネルギー需給の実績データを送信しなくても、運転計画の作成が必要なときを選んで送信することが可能になる。したがって、各家からエネルギー使用実績情報等を繰り返し受信し、受信した情報に基づいて各家のエネルギー機器の運転計画を繰り返し作成する技術において、サーバの負荷の上昇を抑えつつも、機敏な運転計画作成を実現することができる。

なお、エネルギー管理端末５ａ〜５ｃの制御部５４は、エネルギー需給測定処理５４１および通知処理５４２のステップ２２０を実行することで、エネルギー需給の閾値を管理するエネルギー閾値管理部、設定されたエネルギー需給の閾値（上限値および下限値）に対して測定値が超過していないか監視するエネルギー需給監視部として機能する。また制御部５４は、通知処理５４２のステップ２３０、２４０を実行することで、地域サーバ１に対して需要家内で発生したイベントを通知するイベント通知部として機能する。そして、イベント通知コマンド３２５および実績データ３３０が、閾値超過情報に相当する。

（第２実施形態）
次に、本発明の第２実施形態について説明するが、その内容は、多くが第１実施形態と重複している。

本実施形態に係るエネルギー管理システムは、図１０に示すように、地域サーバ（もしくはアグリゲータ）と需要家Ａ、Ｂ、Ｃ、…のエネルギー管理端末Ａ、Ｂ、Ｃ…が通信ネットワークおよび複数のゲートウェイを介して接続された構成となっている。

地域サーバは、各需要家や発電施設等のエネルギー情報（具体的には、消費電力量、発電電力量等のエネルギー測定値）を収集しエネルギー需給状況を監視するエネルギー需給監視部、地域のエネルギー需給予測演算を行うエネルギー需給予測部、各需要家の機器運転計画を演算する計画演算部を有している。

需要家側のエネルギー管理端末Ａ、Ｂ、Ｃ、…は、各需要家に設置された機器（例えば機器１〜３）の電力や熱量などのエネルギー需給状況を測定しているエネルギー需給測定部、エネルギー需給の閾値を管理するエネルギー閾値管理部、設定されたエネルギー需給の閾値（上限値および下限値）に対して測定値が超過していないか監視するエネルギー需給監視部、地域サーバに対して需要家内で発生したイベントを通知するイベント通知部を有している。

図１１に示すように、地域サーバは、エネルギー需給監視部が収集した各需要家や発電施設等のエネルギー情報およびエネルギー需給状況に基づいて、需要家Ａ、Ｂ、Ｃ、…を含む地域のエネルギー需給予測演算を行い、各需要家の機器運転計画を演算（または再演算）する。そして、演算（または再演算）の結果に基づいて、需要家Ａ、Ｂ、Ｃ、…の機器制御部（エネルギー管理端末の一部）に機器運転計画（目標消費電力量等）を配信する。

機器制御部は、受信した機器運転計画に基づいて、機器（例えば機器１〜３）を制御する。

また、図１２に示すように、地域サーバは、通信ネットワークおよびゲートウェイを介した通信により、需要家Ａ、Ｂ、Ｃ、…のエネルギー管理端末Ａ、Ｂ、Ｃ、…のエネルギー閾値管理部に対して、イベントの通知条件を送信することで、エネルギー需給の上限および下限の閾値を設定する。そしてエネルギー管理端末Ａ、Ｂ、Ｃ、…の各々は、受信したイベントの通知条件を記憶する。

また、図１１に示すように、エネルギー管理端末Ａ、Ｂ、Ｃ、…のエネルギー需給監視部は、常時（または繰り返し定期的に）エネルギー測定値を監視し、エネルギー測定値が閾値超過を検知したら地域サーバへ閾値超過情報を通知する（すなわちイベント通知する）。このイベント通知を受信した地域サーバは、受信した閾値超過情報に基づいて、イベント通知元の需要家の機器運転計画の再計算を行い、再計算結果の機器運転計画をイベント通知元の需要家の機器制御部に配信する。

また、地域サーバから需要家Ａ、Ｂ、Ｃ、…のエネルギー管理端末Ａ、Ｂ、Ｃ、…のエネルギー閾値管理部に対して、取得したい機器の動作状態を設定する。そして、需要家Ａ、Ｂ、Ｃ、…のエネルギー管理端末Ａ、Ｂ、Ｃ、…のエネルギー需給監視部が常時（または繰り返し）機器の動作状態を監視し、機器が設定された動作状態に遷移した事を検知したら地域サーバへ閾値超過情報（すなわちイベント通知する）を通知する。このイベント通知を受信した地域サーバは、受信した閾値超過情報に基づいて、イベント通知元の需要家の機器運転計画の再計算を行い、再計算結果の機器運転計画をイベント通知元の需要家の機器制御部に配信する。

（他の実施形態）
なお、本発明は上記した実施形態に限定されるものではなく、特許請求の範囲に記載した範囲内において適宜変更が可能である。また、上記各実施形態は、互いに無関係なものではなく、組み合わせが明らかに不可な場合を除き、適宜組み合わせが可能である。また、上記各実施形態において、実施形態を構成する要素は、特に必須であると明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、上記各実施形態において、実施形態の構成要素の個数、数値、量、範囲等の数値が言及されている場合、特に必須であると明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではない。また、上記各実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に特定の形状、位置関係等に限定される場合等を除き、その形状、位置関係等に限定されるものではない。また、以下の変形例のうち任意の部分を、上記実施形態に適用することができる
（追加構成）
以下、上記の実施形態に対する追加構成について説明する。近年、地域全体で使う電力や熱などのエネルギーの最適化を図る方法として、”デマンドレスポンス”が挙げられる。デマンドレスポンスの定義は「卸市場価格の高騰時または系統信頼性の低下時において、電気料金価格の設定またはインセンティブの支払に応じて、需要家側が電力の使用を抑制するよう電力消費パターンを変化させること」（※１）とされている。つまり、地域全体のエネルギー管理を行う地域サーバが、電力料金を、例えば夏期の昼間などの需要がピークのときに高く、夜間のときに安くするように変動させる事で、地域全体として省エネルギーを実現しつつ電力消費を平滑化する仕組みである。これを実現するためには需要家であるＨＥＭＳ（Ｈｏｍｅ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）やＢＥＭＳ（Ｂｕｉｌｄｉｎｇ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）との連携が不可欠である。そこで、地域全体のエネルギー最適化への貢献にも対応できるＨＥＭＳとして、地域サーバと連携できる仕組みが作り上げられてきた。

デマンドレスポンスの種類として、おおまかに、（１）時間帯別料金等の電気料金ベースのもの、（２）需給調整契約等のインセンティブのもの、に分けられる（※１）。（１）の電気料金ベースのものは、地域サーバを初めとした電気事業者が時間帯別に電気料金を設定する事で、需要家側の判断で、割高な料金が設定された高負荷時に需要抑制、割安な料金が設定された低負荷時に需要をシフトを促す仕組みである。一方、（２）のインセンティブベースは、卸電力価格が高騰または電力需給が逼迫した際に、負荷抑制・遮断を要請または実施する仕組みである。

（２）は、豊田市実証にて、２つのアプローチが行われている。一つは電力料金単価をユーザに掲示し、家庭での電気の使い方、暮らし方を電力需給に合わせてシフトさせようとする取組みであり、地域サーバが本実証を検証している。もう一つは、地域サーバの電力単価の設定にＨＥＭＳを連動させ、ＨＥＭＳがエコキュートや定置用蓄電池などを自動制御する仕組みであり、自動デマンドレスポンス（ＡＤＲ）に相当したものである。本検証については高学習機能付きＨＥＭＳとして検証している
（２）への取り組みとして、地域連携電力制御システムが２０１２年度より構築されており、検証が進められている。この地域連携電力制御システムとは、国際標準規格であるＯｐｅｎＡＤＲで定義されている「Ｄｉｒｅｃｔ Ｌｏａｄ Ｃｏｎｔｒｏｌ」というイベントオブジェクトに相当し、地域の電力逼迫状況に応じて地域サーバから遠隔でエネルギー機器制御するシステムである。

また、制御対象エネルギー機器を定置蓄電池と車（充電スタンド）として、地域サーバから直接制御できる仕組みを構築し、実機が地域サーバの制御要求できる事までを確認してきた。

しかしながら、ここで２つ課題が残っていた。一つはエネルギー機器毎に異なった制御制約が存在していた事から、コントローラ側での制御ロジックが複雑になってしまう事であった。本問題に対しては、制御ルールを統一化する事で解決する事とした。二つ目に、直接制御による負荷増加によって、需要家の契約アンペア数を超えて停電させてしまう危険性がある事であった。例えば、蓄電池の充電を実施した場合、家庭内負荷の視点で考えると、負荷増加の方向に流れるため、停電させてしまう可能性がある。これを解決するためには、事前に需要家の電力使用状況を監視しておき、契約アンペア数を超過しないような仕組みが必要である。なお、ＯｐｅｎＡＤＲでは、基本的に負荷抑制を目的としたものであるため、このようなケースについては言及されていない。一方、「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」では、エネルギー機器の状態が変化した際にコントローラに通知する「ｉｎｆ」というオブジェクトが定義されている。この「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」の考え方を参考に、ＨＥＭＳ内のエネルギー機器の状態が変化した際に地域サーバに通知する仕組み（イベント通知機能）が構築される。

（＊１） 「デマンドレスポンス（Ｄｅｍａｎｄ Ｒｅｓｐｏｎｓｅ）について」（経済産業省資料）を引用。

従来の地域連携制御におけるシステム全体の構成および通知の流れを図１３に示し、新規なシステム全体の構成および通知の流れを図１４に示す。地域連携制御の制御対象である蓄電池と充電スタンドの大きな違いは、ＨＥＭＳのタイマー制御コントローラの有無であった。

従来のＨＥＭＳでは、充電スタンドにのみタイマー機能があり、充電開始時刻（ｈｈ：ｍｍ）と充電終了（ｈｈ：ｍｍ）の１セットをユーザが設定できるようになっている。なお、日付の指定はできない。ユーザの設定された充電開始時刻になったら充電を開始し、充電終了時刻になったら終了するようになっている。一方、蓄電池にはタイマー機能のようなものは存在しない。従って、地域サーバから計画運転制御を取得したときの仕組みとして、以下のように構築してもよい。ここで、ＰＣ−ＨＥＭＳは、ＨＥＭＳの一部であり、ＨＥＭＳの機能のうち主に通信およびデータ変換の機能を担うコンピュータであり、例えばパーソナルコンピュータで実現可能である。ＰＣ−ＨＥＭＳのＰＣは、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｙｕｔｅｒの略である。

蓄電池について：
（１）ＰＣ−ＨＥＭＳが地域サーバから取得した運転計画値を保持
（２）保持している運転計画値に基づいて、動作すべき時刻を迎えたら、ＰＣ−ＨＥＭＳがＨＥＭを経由してエネルギー機器に対して強制制御要求を実施
充電スタンドについて：
（１）ＰＣ−ＨＥＭＳが地域サーバから取得した運転計画値を保持
（２）保持している運転計画値をＨＥＭＳのタイマー制御コントローラに通知し、タイマー時刻に地域サーバから取得した運転計画を反映
（３）タイマー機能に基づいて、動作すべき時刻を迎えたら、ＨＥＭＳがエネルギー機器に対して制御要求を実施
タイマー機能も計画運転の一種である事から、充電スタンドの計画制御はこのタイマー制御を活用する事にした。そのため、充電スタンドの計画運転制御は、保持できる計画が”充電”−”停止”の１セットのみ、日付の指定ができない、といった従来のタイマー機能の制約が残っていた。

そこで、地域サーバからの計画運転制御に対して充電スタンドのタイマー機能を無効化し、蓄電池とまったく同じ仕組みになるように再構築するようにした。

また、地域連携制御による計画運転制御の仕組みを以下の要件で再定義した。

ＰＣ−ＨＥＭＳの作動：
（１）地域サーバから運転計画を取得し、ＰＣ−ＨＥＭＳ内の所定ＤＢに登録する
（２）計画の時刻に計画値の制御要求をＨＥＭＳの強制制御コントローラに送信する
ＨＥＭＳの作動：
（１）地域連携制御の実行中は充電スタンドのタイマー制御を無効化する
（２）地域連携制御の実行中はエネルギー機器のフェールセーフによる制御（蓄電池のリフレッシュ充電など）を除き、エネルギー機器の判断で動作しない
また、地域サーバからＨＥＭＳ内のエネルギー機器を直接制御できる仕組みが構築された。しかしながら、実証宅に導入する上で、一つ課題が残されていた。それは、直接制御によるエネルギー機器の電力負荷増加によって、需要家の契約アンペア数を超えてしまう可能性がある事であった。

本実証での地域連携制御の対象エネルギー機器は蓄電池と車であり、地域サーバからそれぞれのエネルギー機器の充電、放電、停止を行う事ができるようになった。この際に注意しなければならないのが、充電を実施する場合である。充電を実施する場合には家庭内負荷が増加する方向に促される。もし、いずれのエネルギー機器もしくは両エネルギー機器が充電する事で家庭内負荷を押し上げ、各住宅が契約しているアンペア数を超過してしまう可能性がある。各エネルギー機器の動作仕様によると、蓄電池の瞬間の最大充電電力は２０００Ｗ（最大電流１０Ａ）、車の瞬間の最大充電電力は２４００Ｗ（最大電流１２Ａ）であり、合算すると４４００Ｗ（２２Ａ）である。豊田市実証宅の契約アンペアは５０Ａもしくは７５Ａである事から、蓄電池と車だけでも、契約アンペアの３０〜４５％近くを占める事になり、問題がある。したがって、地域サーバ側では、常時、各住宅の電力需要状況を監視しておく必要がある。しかしながら、現状は電力需要等の実績情報をＨＥＭＳから地域サーバへ提供する周期は３０分周期であり、常時監視できる状態ではない。通信トラフィック、ＨＥＭＳや地域サーバの処理負荷を考慮すると、実績情報の提供頻度を短縮する事も難しい。そこで、地域サーバからの地域連携制御によって住宅で停電を起こさぬよう、地域サーバが常時監視できる仕組みを構築する必要がある。

また、他に懸念されている事として、地域サーバが保持している運転計画と、ＨＥＭＳの保持している運転計画が異なる可能性があった。ＨＥＭＳが地域連携制御をできるモードになっているとき、ＨＥＭＳはエネルギー機器が従来持っているスケジュール運転を無効化し、地域サーバから配信される計画に基づいてエネルギー機器を動作させる。しかしながら、ＨＥＭＳ側の例外的な処理（たとえば、エネルギー機器のメンテナンスなど）によってＨＥＭＳ側で計画を変更する事がある。現状、ＨＥＭＳが保持しているエネルギー機器計画情報を地域サーバへ１５分周期で提供しているため、地域サーバ−ＨＥＭＳ間で最大１５分の不一致が発生する可能性がある。また、地域サーバのサービス内容によると、地域サーバが作成したエネルギー機器運転計画は随時、地域サーバフォトフレームを通して、ユーザに掲示する事になっているため、ＨＥＭＳ画面上の計画と地域サーバフォトフレーム上の計画が一致しておらず、ユーザが混乱する恐れがある。計画情報を短周期で送信する事は先に述べた通り、現実的な対策ではないため、ＨＥＭＳが運転計画を変更した場合に随時地域サーバへ通知する仕組みが必要である。

地域サーバと需要家との間の通信プロトコルについて、国際標準化されているＯｐｅｎＡＤＲでは、エネルギー機器の直接制御は「需要家の電力負荷抑制」を目的とした制御であるため、今回のようにエネルギー機器制御によって電力負荷が増加する場合についての言及はなされていない。一方、コントローラとエネルギー機器の間の通信プロトコルについて、日本で規格化されている「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」では、コントローラからエネルギー機器に対してエネルギー機器の状態を取得する「Ｇｅｔ」、コントローラからエネルギー機器に対してエネルギー機器の制御要求をする「Ｓｅｔ」、エネルギー機器からコントローラに対してエネルギー機器の状態変化を通知する「Ｉｎｆ」が定義されている。この「Ｉｎｆ」の考え方を流用し、ＨＥＭＳの中の状態が変化し、電力負荷がある閾値を超過して停電の危険性がある場合に地域サーバへ通知する仕組みを採用する事で、地域サーバ側で制御計画の修正等の停電未然防止の対策ができる。

なお、「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」は地域サーバとＨＥＭＳの間の通信を想定した規格ではないが、地域サーバからＨＥＭＳを経由してエネルギー機器に制御要求を実施している構造から、地域サーバを“コントローラ”と見立てる事で「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」の考え方を採用しても差し支えないと考える。また、既に構築している、実績データの提供方法が地域サーバからＨＥＭＳへＧｅｔする仕組みである事、エネルギー機器制御要求を地域サーバからＨＥＭＳへＰｏｓｔする仕組みである事、からも「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」と同等の通信を実現している。ただし、プロトコルの観点では、当初ＪＩＰＤＥＣ共通仕様に基づいて通信プロトコルを定義していた事から、「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」のプロトコルを導入する事は難しい
従って、今回「Ｅｃｈｏｎｅｔ Ｌｉｔｅ」の「ｉｎｆ」に相当する「イベント通知」の仕組みを、既存のプロトコルに準じた形で新たに定義し、イベント通知インターフェースを新規に考案した。

機能仕様：
Ａ１：課題へのアプローチ
克服すべき課題は以下の２つである。
課題１．
地域連携制御によって、住宅が停電が発生しないように、地域サーバが各住宅の電力需要状態を常時監視できる仕組みの構築
課題２．
地域サーバが保有する宅内エネルギー機器の運転計画と、ＨＥＭＳが保有する運転計画の間で不一致にならないように、宅内エネルギー機器の運転計画の変化を常時把握できる仕組みの構築
各々の課題について、地域サーバが特に必要な情報を整理し、解決方法を検討した。課題１．では、蓄電池や充電スタンドを操作する事で、宅内の消費電力量、特に系統からの買電電力量が契約アンペア数を超えるような状態であるかを地域サーバが把握できれば良い。この解決手段として、ＨＥＭＳ側で任意の電力閾値を保有し、閾値を超過した場合に随時地域サーバへ通知できれば解決できると考えられる。

課題２．では、地域サーバが配信された計画は地域サーバが把握できている事から、ＨＥＭＳ側で運転計画を変更したケースのみを地域サーバに通知する事で、地域サーバ側は変更した事を把握でき、リアルタイムに最新計画を反映できると考えられる。

これらをまとめると、“電力閾値を超過した”、“運転計画が変更された”といったＨＥＭＳ内の各種イベントを地域サーバへリアルタイムに通知する事で解決できると考え、イベント通知インターフェースを開発する事とした。

Ａ２：機能要件
イベント通知機能として、以下の要件を定義した。

イベント通知（ＨＥＭＳ→地域サーバ）：
・閾値超過通知
地域サーバより設定された各種閾値を連続して指定回数（１分毎の測定）を超えた場合に地域サーバに対してイベント発生通知を行う。
・運転計画変更通知
ＰＣ−ＨＥＭＳ側による運転計画に変更が発生した場合にＨＥＭＳから地域サーバにイベント発生通知を行う。
・ＰＣ−ＨＥＭＳリセット通知
ＰＣ−ＨＥＭＳダウン後の復旧時にＰＣ−ＨＥＭＳから地域サーバにイベント発生通知を行う。

イベント設定（地域サーバ→ＨＥＭＳ）：
・条件設定
地域サーバから閾値の値および適用する時間帯についてＨＥＭＳに対して閾値設定を行う。ＨＥＭＳは、閾値設定値に基づいて閾値監視を行う。
電力閾値超過通知の流れは、図１５の通りとする。

Ａ３：イベント通知における通信シーケンスの定義
これまでに実現している、ＨＥＭＳから地域サーバへの実証データ提供、地域サーバからＨＥＭＳへエネルギー機器制御する地域連携制御といった地域サーバ−ＨＥＭＳ間の通信は、地域サーバからＨＥＭＳへの片方向の通信を前提とした通信基盤を構築してきた。しかしながら、今回実現を予定しているイベント通知は、ＨＥＭＳから地域サーバに対して通信する仕組みが必要であり、双方向に通信できる基盤に拡張する必要があった。通信基盤を拡張するにあたっての検討事項を以下に記す。宅内ではゲートウェイの役割を持っている通信ＩＦエネルギー機器が宅内と宅外との通信を制御している事から、ＨＥＭＳ−通信ＩＦエネルギー機器間、通信ＩＦ−地域サーバ間で切り分けて考えた。

通信ＩＦエネルギー機器 〜 ＨＥＭＳ間
・ＳＳＬ相互認証によるＨＴＴＰＳ ＰＯＳＴ通信
ＨＥＭＳ−通信ＩＦエネルギー機器間の通信は、すでにＳＳＬの相互認証通信を双方向で実現していた。従って、ＨＥＭＳ−通信ＩＦエネルギー機器間は、既存のＳＳＬ通信を流用する事とした。
なおＨＡＮ（家内通信：Ｈｏｍｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）内はＫＤＤＩの独自認証局によるＳＳＬ証明書で通信している。

地域サーバ 〜 通信ＩＦエネルギー機器間
・ＳＳＬ認証とＢａｓｉｃ認証の組み合わせによるＨＴＴＰＳ ＰＯＳＴ通信
通信ＩＦ−地域サーバ間での通信は、前述の通り、現状は地域サーバから通信ＩＦエネルギー機器への片方向の相互認証によるＳＳＬ通信のみ実現できているが、逆方向へは対応できていない。通信ＩＦエネルギー機器の制約、地域サーバ側のクライアント認証の仕組みの簡素化などの観点から、ＳＳＬによるサーバ認証とＢａｓｉｃ認証を組み合わせた通信の仕組みを採用した。
イベント通知における各エネルギー機器間の通信の流れは、図１６の通りである。通信シーケンスは、図１７の通りである。

Ａ４：コマンドの定義
機能要件に基づいて、イベント設定コマンドとイベント通知コマンドを新規に定義した。

［イベント設定コマンド］
閾値判定で利用する測定値および判定条件は１種類とする。ただし、コマンド仕様としては、「ＡＮＤ」「ＯＲ」構文を用いた複数条件の組み合わせ、複数の測定値（買電電力以外の情報）も対応可能とする。イベント発動までのカウンタ値（Ｃｏｕｎｔ）を指定可能なものとする。

［イベント通知コマンド］
閾値超過イベントのイベント通知コマンドについては、指定された時間帯に設定された閾値を一定回数超過した場合に、イベントの通知を行う。通知内容は、閾値を超えた回数分のデータを送信する。今回の実装においては、系統電力の買電の閾値のみを対象とする。ただし、コマンド仕様としては、将来の拡張性を考慮して、分電盤や各エネルギー機器ごとについても利用可能な仕様とする。

運転計画イベントのイベント通知コマンドについては、ＰＣ−ＨＥＭＳ側により各エネルギー機器の運転計画が更新された場合に、地域サーバに対して運転計画のリストを送信する。今回の実装では、対象エネルギー機器は、蓄電池（ａｃｃｕｍｕｌａｔｏｒ）・電気自動車（ｖｅｈｉｃｌｅ）のみとする。ただし、コマンド仕様としては、各種エネルギー機器に対応可能なものとする。地域サーバ側からのｐｏｓｔ＿ｔａｒｇｅｔ＿ｄａｔａによる運転計画更新時は本イベントを送信しない。

ＰＣ−ＨＥＭＳリセットイベントのイベント通知コマンドは、ＰＣ−ＨＥＭＳダウン後の復旧時にイベントの通知を行うためのものである。

イベント設定コマンド（地域サーバ → ＨＥＭＳ）を、図１８〜図２１に記す。また、イベント通知コマンド（ＨＥＭＳ → 地域サーバ）を、図２２〜図２４に示す。

Ｂ：ＨＥＭＳ側での契約アンペア数超過に対する停電対策
Ｂ１：課題抽出
イベント通知機能を実現する事によって、地域サーバ側で作成するエネルギー機器の運転計画を修正し、事前に停電を防止する事が可能になった。しかしながら、各エネルギー機器間の通信のタイムラグ等により、リアルタイムな監視ができず瞬時の対応ができない懸念が残っている。そのため、リアルタイムで電力使用状態を監視して、契約アンペア数を超過しないようにエネルギー機器を制御する必要がある。

Ｂ２：機能仕様
Ｂ２．１：課題へのアプローチ
契約アンペア数超過による停電対策の課題は、リアルタイムで電力使用状態を監視し、超過しないようにエネルギー機器を制御する事である。現状のシステムでの各エネルギー機器の収集周期は図２５の通りである。イベント通知では、ＰＣ−ＨＥＭＳが６０秒周期にＨＥＭＳから収集した電力実績値から閾値超過を判定し、地域サーバに通知するものであるため、目安にはなるが瞬時の対応には難しい。一方、ＨＥＭＳは分電盤から数秒周期で収集している事から、ＨＥＭＳで常に電力使用状況を監視し、必要に応じてエネルギー機器制御する事が望ましい。

そこで、（１）電力使用状況を監視し、（２）ある閾値を超過した場合にエネルギー機器を強制的に制御する、「ピークカット機能」をＨＥＭＳの新機能として、新たに構築する事とした。

Ｂ２．２：機能要件
ピークカット機能として、以下の要件を定義した。
・分電盤から取得できる使用電力が閾値を超えた場合に車および蓄電池の充電を停止し、使用電力が低下して充電可能と判断された場合に充電を再開する。
ピークカット機能の動作の流れは図２６の通りである。エネルギー機器の切断優先順位は、蓄電池＞車とした。

Claims (8)

1. サーバ（１）と、
   複数の家（３ａ〜３ｃ）にそれぞれ設けられた複数のエネルギー管理端末（５ａ〜５ｃ）と、を備え、
   前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器（６１ａ〜６１ｃ、６２ａ〜６２ｃ、６３ａ〜６３ｃ）の動作状態を監視し、設置先の家のエネルギー機器がイベント通知条件を満たす動作状態になったことに基づいて、イベント通知コマンドを前記サーバに送信し、
   前記サーバは、前記複数のエネルギー管理端末のうち１つからイベント通知コマンドを受信すると、前記複数のエネルギー管理端末が設置された家のエネルギー機器の運転計画を作成して前記複数のエネルギー管理端末に送信し、
   前記複数のエネルギー管理端末の各々は、前記サーバから設置先の家のエネルギー機器の運転計画を受信すると、受信した運転計画に基づいて設置先の家のエネルギー機器の制御を行うことを特徴とするエネルギー管理システム。
2. 前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器（６１ａ〜６１ｃ、６２ａ〜６２ｃ、６３ａ〜６３ｃ）の動作状態を監視し、設置先の家のエネルギー機器がイベント通知条件を満たす動作状態になったことに基づいて、イベント通知コマンド、および、設置先の家のエネルギー機器によるエネルギー需給の実績データを、前記サーバに送信し、
   前記サーバは、前記複数のエネルギー管理端末のうち１つから、イベント通知コマンド、および、設置先の家のエネルギー機器によるエネルギー需給の実績データを受信すると、受信した実績データに基づいて、前記複数のエネルギー管理端末が設置された家のエネルギー機器の運転計画を作成して前記複数のエネルギー管理端末に送信することを特徴とする請求項１に記載のエネルギー管理システム。
3. 前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器の動作状態として設置先の家のエネルギー機器によるエネルギー需給の量を監視し、前記エネルギー需給の量が設定された閾値を超えていることに基づいて、設置先の家のエネルギー機器によるエネルギー需給の実績データを前記サーバに送信することを特徴とする請求項２に記載のエネルギー管理システム。
4. 前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器の動作状態として貯湯装置の貯湯量を監視し、前記貯湯量が設定された下限値を下回っていることに基づいて、設置先の家のエネルギー機器によるエネルギー需給の実績データを前記サーバに送信することを特徴とする請求項２または３に記載のエネルギー管理システム。
5. 前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器の動作状態として設置先の家のエネルギー機器の故障の有無を監視し、設置先の家のエネルギー機器に故障が発生したことに基づいて、設置先の家のエネルギー機器によるエネルギー需給の実績データを前記サーバに送信することを特徴とする請求項２ないし４のいずれか１つに記載のエネルギー管理システム。
6. 前記複数のエネルギー管理端末の各々は、設置先の家のエネルギー機器の動作状態として設置先の家のエネルギー機器に対する当該家内のユーザ操作の有無を監視し、当該ユーザ操作が発生したことに基づいて、設置先の家のエネルギー機器によるエネルギー需給の実績データを前記サーバに送信することを特徴とする請求項２ないし５のいずれか１つに記載のエネルギー管理システム。
7. 前記サーバは、前記複数のエネルギー管理端末のうち少なくとも１つに、イベント通知条件を含むイベント設定コマンドを送信し、
   前記少なくとも１つのエネルギー管理端末の各々は、前記サーバから前記イベント設定コマンドを受信すると、受信した前記イベント設定コマンドに含まれる前記イベント通知条件を、設置先の家のエネルギー機器のイベント通知条件として記録することを特徴とする請求項２ないし６のいずれか１つに記載のエネルギー管理システム。
8. 前記サーバは、前記複数のエネルギー管理端末のうち少なくとも１つに、イベント通知条件とカウンタ値を含むイベント設定コマンドを送信し、
   前記少なくとも１つのエネルギー管理端末の各々は、前記サーバから前記イベント設定コマンドを受信すると、受信した前記イベント設定コマンドに含まれる前記イベント通知条件を、設置先の家のエネルギー機器のイベント通知条件として記録すると共に、受信した前記イベント設定コマンドに含まれる前記カウンタ値を記録し、
   前記少なくとも１つのエネルギー管理端末の各々は、設置先の家のエネルギー機器の動作状態を監視し、設置先の家のエネルギー機器がイベント通知条件として設定された状態に遷移して以降、設置先の家のエネルギー機器が前記状態であることを、記録された前記カウンタ値以上の回数連続して検出した場合に、設置先の家のエネルギー機器によるエネルギー需給の実績データを前記サーバに送信することを特徴とする請求項２ないし６のいずれか１つに記載のエネルギー管理システム。

Images