技術 電力制御ネットワークシステム、制御装置および制御プログラム

0001

本発明は電力供給を制御する技術に関する。

0002

電力の流れを供給側・消費側の両方から制御し、最適化できる送電ネットワークとして、スマートグリッドが提案されている（例えば、特許文献１〜４等を参照。）。

0003

図１Ａおよび図１Ｂは従来のスマートグリッドにおける制御の概要を示す図である。図１Ａにおいて、コントロールサーバ（中央サーバ）は、管理する所定の領域において、スマートグリッドに含まれる発電所、太陽光パネル、ＥＶ（Electric Vehicle）、エアコン等について、発電量（供給量）と消費量（需要量）を同時同量となるように制御する。

0004

図１Ｂに示すように、ちょうどスマートグリッドが１つのプールのような存在であり、発電量が大きければプールの水位は上がり、消費量が多くなればプールの水位は低下する。ここで、プールの水位は、スマートグリッド上では電圧や周波数に相当する。

0005

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

0006

図１Ａに示したコントロールサーバは発電と消費の総量をコントロールするが、その際、必要な発電のうち、最もコストが低く、さらに消費の地点に近い発電設備（電源）をオンにすることが効率の観点からは望まれる。発電規模が小さい電源から長距離の送電を行ってしまうと、長距離送電による電力ロスが発生してしまうからである。

0007

ただし、そのような制御を行うためには、各消費がどの地点（位置）で、どのくらいの時間にわたって行われるのか、さらに、発電側についても、どの地点で、いくらで、どのくらいの時間にわたって供給可能であるのかを把握し、集中制御しなければならない。そのため、制御のための通信が膨大となり、制御が複雑になりすぎるため、実現が困難であり、現在は総量のみの制御に留まっている。

0008

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、個々の電力消費に対して分散的に電力供給を行うことができる仕組を提供することにある。

0009

上記の課題を解決するため、本発明にあっては、複数の電力供給源と複数の電力消費源とが送電ネットワークで接続され、前記送電ネットワークにオーバーレイされた制御ネットワークを備えたシステムであって、前記制御ネットワークにおける前記電力消費源に対応するノードは、当該ノードで電力消費が必要となった場合に、周辺ノードに対して必要な電力供給を要求するクエリパケットを送信するクエリパケット送信手段と、前記クエリパケットへの応答であるリプライパケットを受信するリプライパケット受信手段と、受信したリプライパケットに基づいて電力消費を賄う電力供給源を選択する消費管理手段とを備える。

0010

本発明にあっては、個々の電力消費に対して分散的に電力供給を行うことができる仕組を提供することができる。

0011

従来のスマートグリッドにおける制御の概要を示す図（その１）である。
従来のスマートグリッドにおける制御の概要を示す図（その２）である。
第１の実施形態にかかるシステムの構成例を示す図である。
ＨＥＭＳコントローラの構成例を示す図である。
第１の実施形態における処理例を示すフローチャートである。
ホップ数によりクエリパケットを送信する範囲を規定する例を示す図である。
ＩＰアドレスによりクエリパケットを送信する範囲を規定する例を示す図である。
クエリパケットとリプライパケットの例を示す図（その１）である。
クエリパケットとリプライパケットの例を示す図（その２）である。
クエリパケットとリプライパケットの例を示す図（その３）である。
第２の実施形態における処理例を示すフローチャートである。
交換クエリパケットの例を示す図である。
ペア交換の判断の例を示す図である。
第３の実施形態にかかるシステムの構成例を示す図である。
第３の実施形態における処理例を示すフローチャートである。
第４の実施形態にかかるシステムの構成例を示す図である。
第５の実施形態における仮想ネットワークのシャッフルの例を示す図である。
第６の実施形態における処理例を示すフローチャートである。
第６の実施形態における交換クエリの送信の例を示す図である。
第７の実施形態における処理例を示すフローチャートである。
プライオリティカーブの例を示す図（その１）である。
プライオリティカーブの例を示す図（その２）である。
プライオリティカーブの例を示す図（その３）である。
第８の実施形態における処理例を示すフローチャートである。
プライオリティカーブの変更の例を示す図である。
第９の実施形態における処理例を示すフローチャートである。
第１０の実施形態にかかるシステムの構成例を示す図である。

0012

以下、本発明の好適な実施形態につき説明する。

0013

＜第１の実施形態＞
図２は第１の実施形態にかかるシステムの構成例を示す図である。

0014

図２において、複数の家庭１Ａ、１Ｂ、１Ｃ、・・をカバーする電力配電ネットワーク２にオーバレイする形で制御ネットワーク３が構築されており、各家庭１Ａ、１Ｂ、１Ｃ、・・に対応するノードとしてＨＥＭＳ（Home Energy Management System）コントローラ４Ａ、４Ｂ、４Ｃ、・・が設けられている。なお、家庭１Ａ、１Ｂ、１Ｃ、・・には、常に電力消費源になるものと、常に電力供給源になるものと、状況に応じて電力消費源になったり電力供給源になったりするものとがある。また、家庭１Ａ、１Ｂ、１Ｃ、・・には、個人の家庭に限らず、発電を行う事業者の事業所が含まれていてもよい。

0015

図３はＨＥＭＳコントローラ４（４Ａ、４Ｂ、４Ｃ、・・）の構成例を示す図である。

0016

図３において、ＨＥＭＳコントローラ４は、情報表示部４１と情報入力部４２と消費管理部４３と供給管理部４４とパケット送受信部４５とを備えている。

0017

情報表示部４１は、ユーザに対して各種の情報の表示を行う機能を有している。情報入力部４２は、ユーザから各種の情報の入力を行う機能を有している。

0018

消費管理部４３は、ＨＥＭＳコントローラ４が設置された家庭１内の電化製品の電力消費を管理する機能を有している。特に、電化製品の使用開始または使用予約が行われた場合に、電力需要を賄う電力供給源を探索するためのクエリパケットの送信をパケット送受信部４５により行い、それに応答するリプライパケットが受信された場合に、電力供給源を選択する。また、電化製品が対応していれば、使用開始時間や消費電力の調整も行う。

0019

供給管理部４４は、ＨＥＭＳコントローラ４に発電設備が接続されていて、自ノードが電力供給源になる場合に、他への電力供給（売電）を管理する機能を有している。特に、電力供給源を探索するためのクエリパケットをパケット送受信部４５により受信した場合に、電力コストや距離指標（電力消費源と電力供給源の間の距離を示す情報）を含めたリプライパケットをパケット送受信部４５により送信する。

0020

パケット送受信部４５は、各種のパケットを周辺ノードとの間で送受信する機能を有している。

0021

図４は第１の実施形態における処理例を示すフローチャートである。

0022

図４において、消費側のＨＥＭＳコントローラ４の消費管理部４３は、消費（予定も含む）の発生を待機し（ステップＳ１０１）、消費が発生すると（ステップＳ１０１のＹＥＳ）、必要とする電力、使用時間等の情報を取得し（ステップＳ１０２）、必要な電力供給を要求するクエリパケットをブロードキャストの形式で送信する（ステップＳ１０３）。

0023

周辺の他のノードのＨＥＭＳコントローラ４は、クエリパケットの受信を待機し（ステップＳ１０４）、クエリパケットを受信すると（ステップＳ１０４のＹＥＳ）、ブロードキャストによる所定範囲に到達したか否か判断し（ステップＳ１０５）、到達していない場合（ステップＳ１０５のＮＯ）は周辺の他のノードにクエリパケットを転送する（ステップＳ１０６）。

0024

図５はホップ数によりクエリパケットを送信する範囲を規定する例を示す図であり、ホップ数を「２」とした例である。すなわち、電力消費源Ｓからクエリパケットをブロードキャストする場合、ホップ数が「２」に達するノードＡ２１、Ａ２２、Ａ２３、Ｂ２１、Ｃ２１、Ｃ２２、Ｄ２１までクエリパケットが送信される。

0025

図６はＩＰアドレスによりクエリパケットを送信する範囲を規定する例を示す図であり、より高度に隣接関係を決めるため、発電所からの送電網の構造を考えてアドレスを付与し、そのアドレスに基づいて範囲を決めている。各配電ネットワークの分岐部分で、例えば、８ｂｉｔずつに区切られたアドレスを階層的に付与する。この方法では、電力消費源Ｓを例えば「１２８．２５．４８．７」とすると、隣接ノードは「１２８．２５．４８．＊＊」すべてのノードとなる。また、もう１段階だけ離れたノードは「１２８．２５．＊＊．＊＊」のノード群となる。

0026

図４に戻り、ＨＥＭＳコントローラ４の供給管理部４４は、自ノードでの供給可能電力、コスト（売電価格）等の情報を取得し（ステップＳ１０７）、クエリパケットに応答するか否か判断し（ステップＳ１０８）、応答する場合（ステップＳ１０８のＹＥＳ）、リプライパケットを返信する（ステップＳ１０９）。

0027

最初にクエリパケットを送信したＨＥＭＳコントローラ４の消費管理部４３は、リプライパケットの受信を待機し（ステップＳ１１０）、リプライパケットを受信すると（ステップＳ１１０のＹＥＳ）、そのリプライパケットに含まれる電力コストおよび距離指標に基づいて電力を受け入れるか否か判断する（ステップＳ１１１）。複数のリプライパケットを受信した場合には、その中から最適な電力供給源を選択することになる。

0028

電力を受け入れる場合（ステップＳ１１１のＹＥＳ）、電力供給源のノードに対して受入パケットを送信し（ステップＳ１１２）、内部的に、電力、電力コスト、電力供給源等を記録する（ステップＳ１１３）。

0029

他のノードのＨＥＭＳコントローラ４の供給管理部４４は、受入パケットの受信を待機し（ステップＳ１１４）、受入パケットを受信すると（ステップＳ１１４のＹＥＳ）、電力、電力コスト、電力消費源等を記録する（ステップＳ１１５）。

0030

図７〜図９はクエリパケットとリプライパケットの例を示す図である。

0031

図７は、クエリパケットに、必要とする電力と使用時間とを含めた例である。このクエリパケットに対し、リプライパケットには、供給する電力とコスト（売電コスト）とホップ数（電力消費源と自己の電力供給源との距離指標）とを含めている。この例では、クエリパケットで要求する電力と使用時間を満たすことのできるノードだけがリプライパケットを返すことを想定している。そして、電力消費源はコストとホップ数に基づいて最適な電力供給源を選択する。例えば、Ｃｏｓｔをコスト、Ｋを定数（例えば、５円）、ｈｏｐをホップ数として、
Ｃ ＝ Ｃｏｓｔ ＋ Ｋ・ｈｏｐ
を計算し、Ｃが最も小さい電力供給源を選択する。これにより、地消地産のために、ホップ数が短く、かつ、低価格の売電ノードを自動選択することができる。

0032

図８は、クエリパケットに、必要とする電力と使用時間とコスト（購入コスト）を含めた例である。このクエリパケットに対し、リプライパケットには、供給する電力とコスト（売電コスト）とホップ数とを含めている。この例では、クエリパケットで要求する電力を満たせない場合でも、リプライパケットを返すことができるものとしている。すなわち、あいまいな答えを返すことを許容している。図示の例のリプライパケットでは、上段は、電力は要求を満たせないが、コストは要求と同等である。下段は、電力は要求を満たせるが、コストは高い。このリプライパケットを受信した電力消費源では、コストは高くても要求した電力を満たす電力供給源を選択することもできるし、消費電力を抑えて（エアコンであればパワーを下げて）安い電力を使用することもできる。

0033

図９は、クエリパケットに、必要とする電力と使用時間とコスト（購入コスト）を含めた例である。このクエリパケットに対し、リプライパケットには、供給する電力とコスト（売電コスト）と使用時間とホップ数とを含めている。使用時間としては、図示のような「２時間後から」とか「１０ｍｉｎのみ」とかという時間条件を入れることができる。すなわち、時間に対して、あいまいな回答を行うことを許容している。このリプライパケットを受信した電力消費源では、時間的に変更が可能な消費の場合は、より安い電力供給源を選択することができる。

0034

＜第２の実施形態＞
第２の実施形態は、上述した第１の実施形態の処理により個々の消費電力について電力消費源と電力供給源とを対応付けてペアを形成した後に、より最適なペアを形成するために、他のノードで形成されているペアと交換を行うようにしている。

0035

ネットワーク構成およびＨＥＭＳコントローラ４の構成は図２および図３に示したのと同様であるが、ＨＥＭＳコントローラ４の消費管理部４３には交換クエリパケットを用いてペア交換を行う機能が付加される。なお、ペア交換の機能は供給管理部４４が担ってもよいし、消費管理部４３と供給管理部４４で担ってもよい。

0036

電力消費（予定を含む）が発生し、その電力消費について最初のペアが形成されるまでの処理は図４に示したのと同様である。

0037

図１０は第２の実施形態における処理例を示すフローチャートである。

0038

図１０において、既にペアを形成している消費側のＨＥＭＳコントローラ４の消費管理部４３は、定期的またはランダムな時間経過によりタイミングの到来を待機し（ステップＳ２０１）、タイミングが到来すると（ステップＳ２０１のＹＥＳ）、既に形成しているペアについての電力、電力コスト、電力消費源（自ノード）、電力供給源等の情報を取得し（ステップＳ２０２）、ペア交換を要求する交換クエリパケットをブロードキャストの形式で送信する（ステップＳ２０３）。図１１は交換クエリパケットの例を示す図であり、「消費位置（電力消費源）」「供給位置（電力供給源）」「電力」「ホップ数」等を含んでいる。なお、更に電力コストや使用時間を交換クエリパケットに含ませてもよい。

0039

図１０に戻り、他のノードのＨＥＭＳコントローラ４の消費管理部４３は、交換クエリパケットの受信を待機し（ステップＳ２０４）、交換クエリパケットを受信すると（ステップＳ２０４のＹＥＳ）、ブロードキャストによる所定範囲に到達したか否か判断し（ステップＳ２０５）、到達していない場合（ステップＳ２０５のＮＯ）は周辺の他のノードにクエリパケットを転送する（ステップＳ２０６）。

0040

次いで、ＨＥＭＳコントローラ４は、自ノードで形成しているペアがあれば、そのペア（複数のペアでも可）についての電力、電力コスト、電力消費源（自ノード）、電力供給源等の情報を取得し（ステップＳ２０７）、交換クエリパケットの示すペアと自ノードに存在するペアとを比較し、距離指標が少なくなることを考慮してペア交換の可否を判断する（ステップＳ２０８）。

0041

図１２はペア交換の判断の例を示す図であり、ノードＡＳ（消費）とノードＡＤ（供給）の間でペアが形成され、ノードＢＳ（消費）とノードＢＤ（供給）の間でペアが形成され、ノードＣＳ（消費）とノードＣＤ（供給）の間でペアが形成されているものとしている。なお、ノード間の数字はホップ数を示している。

0042

ここで、ノードＡＳ（消費）から交換クエリパケットを送信し、それをノードＢＳ（消費）が受信したとすると、それまでのホップ数の合計が１０＋１０＝２０であるのに対し、ペア交換をしたとした場合（ノードＡＳ（消費）とノードＢＤ（供給）のペアと、ノードＢＳ（消費）とノードＡＤ（供給）のペアに組み替え）のホップ数の合計は３＋３＝６となり、距離指標が少なくなるため、ペア交換すると判断される。

0043

また、ノードＡＳ（消費）から送信された交換クエリパケットをノードＣＳ（消費）が受信したとすると、それまでのホップ数の合計が１０＋１０＝２０であるのに対し、ペア交換をしたとした場合（ノードＡＳ（消費）とノードＣＤ（供給）のペアと、ノードＣＳ（消費）とノードＡＤ（供給）のペアに組み替え）のホップ数の合計は３＋２５＝２８となり、距離指標が大きくなるため、ペア交換しないと判断される。

0044

図１０に戻り、ペア交換すると判断された場合（ステップＳ２０８のＹＥＳ）、自ノードの電力供給の記録を新たなペアについてのものに変更し、元のペアの相手ノードに対してもペア交換を通知して記録を変更させる（ステップＳ２０９）。そして、交換クエリパケットの送信元のノードにペア交換についての情報を含む交換実行パケットを返送する（ステップＳ２１０）。

0045

交換クエリパケットの送信元のノードは、交換実行パケットの受信を待機し（ステップＳ２１１）、交換実行パケットを受信すると（ステップＳ２１１のＹＥＳ）、電力消費の記録を新たなペアについてのものに変更し、元のペアの相手ノードに対してもペア交換を通知して記録を変更させる（ステップＳ２１２）。

0046

このように、たまたま形成されているペアについても、常に距離が短くなるように、自動的なマッチングが非同期かつ分散で行なわれる。

0047

＜第３の実施形態＞
上述した第２の実施形態では、ペア交換により理想的な組み合わせに導いていくことができるが、各ノードがブロードキャストクエリを頻繁に送ることになるため、制御パケット量が極めて大きくなることが想定される。また、そのブロードキャストパケットはフラッティングするので、ホップリミット（Hop Limit）を小さくしないと、やはり非常に大量のクエリが発生する。そのため、小さな範囲のみの探索しかできず、限られたところでペア交換が行なわれ、ペア交換の効果が限定的になる。

0048

そこで、第３の実施形態では、ペア交換のためにマッチングサーバを設け、ペア交換についての通信はマッチングサーバとの間だけで済むようにして、ペア交換の対象範囲を拡大しても通信量が膨大にならないようにしている。

0049

図１３は第３の実施形態にかかるシステムの構成例を示す図であり、図２に示した構成に加え、制御ネットワーク３上にマッチングサーバ５を設けている。

0050

図１４は第３の実施形態における処理例を示すフローチャートである。

0051

図１４において、既にペアを形成している消費側のＨＥＭＳコントローラ４の消費管理部４３は、定期的またはランダムな時間経過によりタイミングの到来を待機し（ステップＳ３０１）、タイミングが到来すると（ステップＳ３０１のＹＥＳ）、ペアについての電力、電力コスト、電力消費源（自ノード）、電力供給源等の情報を取得し（ステップＳ３０２）、ペア情報をマッチングサーバ５に送信する（ステップＳ３０３）。

0052

マッチングサーバ５はペア情報の受信を待機し（ステップＳ３０４）、ペア情報を受信すると（ステップＳ３０４のＹＥＳ）、受信したペア情報を一時的に保持する（ステップＳ３０５）。

0053

次いで、マッチングサーバ５は、一時的に保持している複数のペア情報について、ペア交換により距離指標が少なくなるか等の観点からペア間のマッチングを行い（ステップＳ３０６）、マッチングが成立した場合（ステップＳ３０７のＹＥＳ）、ペア交換する２組のペアのノードに対して交換指示を送信する（ステップＳ３０８）。

0054

ペア情報の送信元のノードは、交換指示の受信を待機し（ステップＳ３０９）、交換指示を受信すると（ステップＳ３０９のＹＥＳ）、電力消費の記録を新たなペアについてのものに変更し、元のペアの相手ノードに対してもペア交換を通知して記録を変更させる（ステップＳ３１０）。

0055

各ノードは、定期的またはランダムに自分のペア情報をマッチングサーバ５に登録するので、たまたまマッチングサーバ５上で出会ったペアを交換させることによって、トータルホップ（Total hop）値を削減できる方向に導くことができる。ペア交換できる可能性は、マッチングサーバ５でのペア情報の短期記憶時間ｔ１と、ノードからの情報登録の周期ｔ２によって決まる。つまり、ｔ１を長くｔ２を短くすると、交換できる可能性が向上する。

0056

＜第４の実施形態＞
第２の実施形態について、制御パケット量が極めて大きくなる可能性がある点については前述した通りである。第３の実施形態では、ペア交換のためにマッチングサーバを設けることで通信量を低減している。しかし、マッチングサーバとの間での通信量についても無視できない場合が考えられ、更なる低減が求められる。

0057

そこで、第４の実施形態では、ネットワーク（クラウド）上に各ＨＥＭＳコントローラと同期した仮想エージェントを設け、仮想エージェント間あるいは仮想エージェントとマッチングサーバとの間で通信を行うことで、実ネットワーク上での通信量を低減している。制御パケットのフラッティング等が実ネットワークでは行わないため、ＤＯＳ攻撃のように、ネットワークを制御パケットにより満杯にしてしまうようなことがなくなる。

0058

図１５は第４の実施形態にかかるシステムの構成例を示す図であり、図２に示した構成または図１３に示した構成に加え、新たなサーバまたはマッチングサーバ５の上に、任意数の仮想ネットワーク６を設け、その中に、ＨＥＭＳコントローラ４Ａ、４Ｂ、４Ｃ、・・の状態と同期する仮想エージェント７Ａ、７Ｂ、７Ｃ、・・を収容するようにしている。ＨＥＭＳコントローラ４Ａ、４Ｂ、４Ｃ、・・で状態の変化があった場合、対応する仮想エージェント７Ａ、７Ｂ、７Ｃ、・・に反映され、仮想エージェント７Ａ、７Ｂ、７Ｃ、・・で状態の変化があった場合もＨＥＭＳコントローラ４Ａ、４Ｂ、４Ｃ、・・に反映される。なお、仮想ネットワーク６が複数となる場合、電力の供給と受入のペアは仮想ネットワークの中に閉じたものとする。

0059

他の処理として、消費の発生時におけるペア形成のための処理は、図４に示したものと同様である。ペア交換の処理については、図１０における消費側および他ノードの処理が仮想エージェント７により代わりに行われ、結果の状態が各ＨＥＭＳコントローラ４に反映される。また、マッチングサーバ５を用いたペア交換の処理については、図１４における消費側および新旧の相手方ノードの処理が仮想エージェント７により代わりに行われ、結果の状態が各ＨＥＭＳコントローラ４に反映される。

0060

＜第５の実施形態＞
第５の実施形態は、第４の実施形態を拡張し、ある距離（地域内）のペアに関して特定のデマンドの多いユーザの影響を緩和するために、仮想ネットワークを所定のタイミングでランダムにシャッフルし、この地域内でのペアが固定しないようにしたものである。

0061

図１６は第５の実施形態における仮想ネットワークのシャッフルの例を示す図であり、上段に示すように、ある仮想ネットワークに収容された、ある地域の仮想エージェントをランダムにシャッフルし、異なる仮想ネットワークに収容した状態を示している。電力の供給と受入のペアを同一の仮想ネットワークの中に閉じたものとすることで、ペアを組む相手ノードの対象範囲が変化するため、特定のユーザにデマンドへの対応が偏在することを防止することができる。

0062

なお、シャッフル前に形成されていたペアは、電力の供給と受入が終了するか、ペア交換が行われるまで継続する。また、ペア交換や新たなペア形成は、新たに収容された仮想ネットワーク内で行われる。

0063

＜第６の実施形態＞
上述した第３の実施形態では、第２の実施形態における制御パケットの増加を、マッチングサーバを設けることにより解決しているが、この第６の実施形態ではマッチングサーバを用いずに、Ｐ２Ｐ（Point To Point）技術により解決している。すなわち、交換クエリパケットをブロードキャストにより入口以外の全方向に送信（転送）するのではなく、ホップリミットに到達するまで、自ノードでペア交換しない場合は入口以外のランダムな１方向に送信（転送）するようにすることで、制御パケットの増加を抑えている。

0064

図１７は第６の実施形態における処理例を示すフローチャートである。

0065

図１７において、既にペアを形成している消費側のＨＥＭＳコントローラ４の消費管理部４３は、定期的またはランダムな時間経過によりタイミングの到来を待機し（ステップＳ４０１）、タイミングが到来すると（ステップＳ４０１のＹＥＳ）、ペアについての電力、電力コスト、電力消費源（自ノード）、電力供給源等の情報を取得し（ステップＳ４０２）、ペア交換を要求する交換クエリパケットをランダムな１方向に送信する（ステップＳ４０３）。

0066

他のノードのＨＥＭＳコントローラ４の消費管理部４３は、交換クエリパケットの受信を待機し（ステップＳ４０４）、交換クエリパケットを受信すると（ステップＳ４０４のＹＥＳ）、自ノードで形成しているペアがあれば、そのペア（複数のペアでも可）についての電力、電力コスト、電力消費源（自ノード）、電力供給源等の情報を取得する（ステップＳ４０５）。

0067

次いで、交換クエリパケットの示すペアと自ノードに存在するペアとを比較し、距離指標が少なくなることを考慮してペア交換の可否を判断する（ステップＳ４０６）。

0068

ペア交換しないと判断された場合（ステップＳ４０６のＮＯ）、ホップリミット等による所定範囲に到達したか否か判断し（ステップＳ４０７）、到達していない場合（ステップＳ４０７のＮＯ）は入口以外のランダムな１方向にクエリパケットを転送する（ステップＳ４０８）。

0069

また、ペア交換すると判断された場合（ステップＳ４０６のＹＥＳ）、自ノードの電力供給の記録を新たなペアについてのものに変更し、元のペアの相手ノードに対してもペア交換を通知して記録を変更させる（ステップＳ４０９）。そして、交換クエリパケットの送信元のノードにペア交換についての情報を含む交換実行パケットを返送する（ステップＳ４１０）。

0070

交換クエリパケットの送信元のノードは、交換実行パケットの受信を待機し（ステップＳ４１１）、交換実行パケットを受信すると（ステップＳ４１１のＹＥＳ）、電力消費の記録を新たなペアについてのものに変更し、元のペアの相手ノードに対してもペア交換を通知して記録を変更させる（ステップＳ４１２）。

0071

図１８は第６の実施形態における交換クエリの送信の例を示す図であり、例としてマンハッタンネットワーク（碁盤目状のネットワーク）を示している。比較的大きいマンハッタンネットワークを考えた場合、交換クエリパケットの転送先は、各交差点で戻ることなくランダムウォークをする。図示の例では、電力消費源Ｓから送信された交換クエリパケットは、最初にノードＡに出会うが、ペア交換によるコスト削減効果がない場合は交換クエリパケットの転送を続ける。そして、ノードＥにたまたま出会ってペア交換することにより、コストを削減する。

0072

＜第７の実施形態＞
第７の実施形態は、第１の実施形態で行ったクエリパケットによるペア形成の処理（図４）を行わず、予め確保しておいたイニシャル供給源と強制的にペアを形成することにより、電力消費に即座に対応できるようしたものである。その上で、第２〜６の実施形態で説明したペア交換を行うことにより、より適切なペアに組み替えていく。

0073

処理の前提として、必ず１つ電力供給が可能なノードを、イニシャル供給源として確保しておく。また、ペア形成の後、新たに発生する需要に備えてイニシャル供給源を用意しておく。例えば、制御ネットワーク３内の所定の発電装置をオンにしておくとか、電力会社と契約して電力供給源を確保しておく。

0074

図１９は第７の実施形態における処理例を示すフローチャートである。

0075

図１９において、消費側のＨＥＭＳコントローラ４の消費管理部４３は、消費（予定も含む）の発生を待機し（ステップＳ５０１）、消費が発生すると（ステップＳ５０１のＹＥＳ）、必要とする電力、使用時間等の情報を取得し（ステップＳ５０２）、イニシャル供給源を電力供給源とする電力受入を記録する（ステップＳ５０３）。ペアとなるイニシャル供給源側についても電力供給の記録を行わせる。

0076

これにより、電化製品の使用を開始しようとしたときに、電力供給源を探す時間が必要なく、また、ネットワーク全体としても低コストにいずれなるという長所がある。

0077

＜第８の実施形態＞
第８の実施形態は、各家庭１のＨＥＭＳコントローラ４が収容する電化製品毎の性質に基づいて適切な電力の調達を行うようにしたものである。

0078

家庭内の電化製品は、それぞれ時間（時刻）、温度、消費電力等に対してプライオリティ（優先度）を持つ。例えば、４時までに洗濯を終わらせたり、４時までにＥＶに充電したい場合、まだ十分に時間があればプライオリティは低いが、デッドライン間近になると、プライオリティが増加する。図２０Ａはこのような時間に応じてプライオリティが変化し、デッドラインで最大になる例（デッドライン型）を示している。tmustはデッドラインの時刻である。

0079

また、冷蔵庫の場合、電源を切った時には問題はないが、何回か扉の開け閉めを行なうと、冷蔵庫内部の温度が上昇し、それに伴ってプライオリティが変化する。図２０Ｂはこのような温度に応じてプライオリティが変化する例を示している。tempenableは食品を保存するための許容温度である。

0080

また、エアコンの強中弱の設定を変えたり、ライトをちょっと暗くするのと、完全に消してしまうのとでは、プライオリティが異なることがある。図２０Ｃはこのような電力に応じてプライオリティが変化する例を示している。pminは許容できる最小の電力である。

0081

従って、家庭内で電力需要が発生した場合、電力を必要とする電化製品のプライオリティに応じて電力調達の優先順位を付け、プライオリティの低い電化製品については、使用を遅らせたり、可能であれば電力を小さくしたりする。

0082

ただし、特定の電化製品が頻繁に使用できない場合、ユーザにとっては不便であるため、電化製品毎にＱｏＳ劣化を観測し、ＱｏＳ劣化が観測された場合には、プライオリティ特性をプライオリティが高くなる方向に再設定するようにしている。また、この際、他の家庭とのフェアネスを考慮し、一部の電化製品のプライオリティを高く再設定した場合、他の電化製品のプライオリティ特性をプライオリティが低くなる方向に再設定するようにしている。

0083

図２１は第８の実施形態における処理例を示すフローチャートである。

0084

図２１において、消費側のＨＥＭＳコントローラ４の消費管理部４３は、定期的な時間経過によりタイミングの到来を待機し（ステップＳ６０１）、タイミングが到来すると（ステップＳ６０１のＹＥＳ）、収容する電化製品についてのタイプ、設定状態、ＱｏＳ劣化記録等の情報を取得し（ステップＳ６０２）、電化製品毎にプライオリティカーブを設定する（ステップＳ６０３）。プライオリティカーブとしては図２０Ａ〜図２０Ｃに示したようなものがある。

0085

ここで、初回または過去の所定期間内でＱｏＳ劣化が検出されていない電化製品については原則として標準的なプライオリティカーブを設定するが、過去の所定期間内でＱｏＳ劣化が検出されている電化製品については以前よりもプライオリティが高くなる方向に再設定する。図２２では、デッドライン型のプライオリティカーブについて、初回は実線で示したものを、次は一点鎖線のようにし、その次は二点鎖線のようにする。また、一部の電化製品についてプライオリティが高くなる方向に再設定した場合には、他の電化製品についてプライオリティが低くなる方向にプライオリティカーブを再設定する。

0086

図２１に戻り、消費管理部４３は、電化製品毎にＱｏＳ劣化を監視し、ＱｏＳ劣化が検出された場合（ステップＳ６０４のＹＥＳ）にはその旨を記録する（ステップＳ６０５）。

0087

一方、消費管理部４３は、消費（予定も含む）の発生を待機し（ステップＳ６０６）、消費が発生すると（ステップＳ６０６のＹＥＳ）、電力、使用時間、電化製品ＩＤ、デッドライン、温度、最小電力等の情報を取得し（ステップＳ６０７）、電化製品毎に予め設定されているプライオリティカーブから現時点のプライオリティを取得する（ステップＳ６０８）。

0088

次いで、プライオリティに応じたコスト（購入コスト）を取得する（ステップＳ６０９）。例えば、プライオリティに応じてコストを上昇させる。そして、必要な電力供給を要求するクエリパケットを送信する（ステップＳ６１０）。クエリパケットの送信後の処理は図４に示したものと同様である。

0089

なお、クエリパケットにプライオリティを含め、電力供給源のノードがプライオリティを考慮してリプライするようにしてもよい。

0090

このようにして、できるだけＱｏＳ劣化を観測しないように電化製品を相互にコントロールすることで、学習型で動作し、適切な電力の調達を行うことができる。

0091

＜第９の実施形態＞
上述した第８の実施形態ではＱｏＳ劣化の検出を自動的に行うことを想定しているが、この第９の実施形態では、更にユーザ本人によるＱｏＳ劣化の申告を用いている。すなわち、ＨＥＭＳコントローラ４のユーザインタフェースとして、制御の不快感を入力するボタン（「いやね」ボタン）を設け、システムによる自動的な制御に対してユーザが不快と感じた場合（例えば、電化製品を使いたい場合に使えない等）、そのボタンを押させるようにしている。

0092

図２３は第９の実施形態における処理例を示すフローチャートである。図２３において、ＨＥＭＳコントローラ４の情報入力部４２は、ユーザにより「いやね」ボタンが押されるのを待機し（ステップＳ７０１）、「いやね」ボタンが押されると（ステップＳ７０１のＹＥＳ）、その旨を記録する（ステップＳ７０２）。

0093

制御処理は図２１に示したのと同様であるが、情報取得（ステップＳ６０２）において、所定期間内に「いやね」ボタンが押された回数の記録を参照し、プライオリティカーブの設定（ステップＳ６０３）に反映（「いやね」ボタンが押された回数が多いほど、プライオリティに応じた制御がかかりにくくする）させる点が異なる。

0094

また、この「いやね」回数には上限を設け、例えば、１０回までは無料、１０〜２０回は５００円、２０〜３０回は１０００円として、ペナルティを与えながら各ユーザの個人嗜好にできるだけ一致したプライオリティを形成することができる。すなわち、「いやね」ボタンを押すことでプライオリティカーブを変更し制御がかかりにくくなると同時に、その分、トータルの電気料金が高くなるシステムとなる。

0095

＜第１０の実施形態＞
第１０の実施形態は、電力の供給と受入を行うユーザ間で、相手方の信頼性を確認できるようにしたものである。

0096

図２４は第１０の実施形態にかかるシステムの構成例を示す図であり、クエリを交換する制御ネットワーク３上に新しく認証サーバ８を設けている。認証サーバ８は、不適切な取引に関する情報を保持している。

0097

各ＨＥＭＳコントローラ４は、認証サーバ８に対して、受信したクエリもしくは返信したクエリの信頼性を問い合わすことができ、認証サーバ８は、保持する不適切な取引に関する情報に基づいてクエリの信頼性を決定して応答する。

0098

＜総括＞
以上説明したように、本実施形態によれば、個々の電力消費に対して分散的に電力供給を行うことができる仕組を提供することができる。

0099

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

0100

本国際出願は、２０１４年４月１７日に出願した日本国特許出願第２０１４−０８５８４８号に基づく優先権を主張するものであり、日本国特許出願第２０１４−０８５８４８号の全内容を本国際出願に援用する。

0101

１、１Ａ〜１Ｃ家庭
２電力配電ネットワーク
３制御ネットワーク
４、４Ａ〜４ＣＨＥＭＳコントローラ
４１情報表示部
４２情報入力部
４３消費管理部
４４供給管理部
４５パケット送受信部
５マッチングサーバ
６仮想ネットワーク
７、７Ａ〜７Ｃ仮想エージェント
８ 認証サーバ