図面 (/)

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

出願人 学校法人慶應義塾
発明者 山中直明山本草詩浅見康介遠藤光泰
出願日 2015年3月27日 (5年10ヶ月経過) 出願番号 2016-513698
公開日 2017年4月13日 (3年10ヶ月経過) 公開番号 WO2015-159682
状態 特許登録済
技術分野 交流の給配電 特定用途計算機 給配電網の遠方監視・制御
主要キーワード 電力消費源 送電ネットワーク 仮想エージェント 購入コスト ランダムウォーク 長距離送電 配電ネットワーク 相手方ノード
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年4月13日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

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

概要

背景

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

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

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

概要

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

目的

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とする

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

請求項1に記載の電力制御ネットワークシステムにおいて、前記制御ネットワークにおける前記電力供給源に対応するノードは、周辺ノードから前記クエリパケットを受信するクエリパケット受信手段と、電力コストおよび距離指標を含めたリプライパケットを送信するリプライパケット送信手段とを備え、前記電力消費源に対応するノードにおける前記消費管理手段は、リプライパケットに含まれる電力コストおよび距離指標に基づいて最適な電力供給源を選択することを特徴とする電力制御ネットワークシステム。

請求項3

請求項2に記載の電力制御ネットワークシステムにおいて、前記リプライパケット送信手段は、前記クエリパケットの要求電力に対して供給可能電力不足する場合にも、供給可能電力を含むリプライパケットを送信し、前記消費管理手段は、消費電力を低減可能か否かを考慮して電力供給源を選択することを特徴とする電力制御ネットワークシステム。

請求項4

請求項2または3のいずれか一項に記載の電力制御ネットワークシステムにおいて、前記リプライパケット送信手段は、電力供給可能な時間条件を含むリプライパケットを送信し、前記消費管理手段は、前記時間条件を考慮して電力供給源を選択することを特徴とする電力制御ネットワークシステム。

請求項5

請求項1乃至4のいずれか一項に記載の電力制御ネットワークシステムにおいて、前記電力消費源または前記電力供給源に対応するノードは、既に所定の電力について消費と供給が対応付けられている自己相手ノードとのペアについて、ペア交換を要求する交換クエリパケットを周辺ノードに対して送信する交換クエリパケット送信手段と、前記交換クエリパケットへの応答である交換実行パケットを受信する交換実行パケット受信手段と、受信した交換実行パケットに従ってペア交換を行うペア交換手段とを備え、他の電力消費源または電力供給源に対応するノードは、前記交換クエリパケットを受信する交換クエリパケット受信手段と、自己の既に保持する他の相手ノードとのペアと前記交換クエリパケットの示すペアとを比較し、距離指標が少なくなることを考慮してペア交換の可否を判断するペア交換判断手段と、ペア交換すると決定した場合にペア交換を行うとともに、交換実行パケットを送信する交換実行パケット送信手段とを備えたことを特徴とする電力制御ネットワークシステム。

請求項6

請求項1乃至4のいずれか一項に記載の電力制御ネットワークシステムにおいて、前記電力消費源または前記電力供給源に対応するノードは、既に所定の電力について消費と供給が対応付けられている自己と相手ノードとのペアについてのペア情報マッチングサーバに送信するペア情報送信手段と、前記マッチングサーバからペア交換情報を受信し、ペア交換を行うペア交換手段とを備えたことを特徴とする電力制御ネットワークシステム。

請求項7

請求項5または6のいずれか一項に記載の電力制御ネットワークシステムにおいて、いずれかのサーバ上に存在する仮想エージェントとして、前記ノードの個々に対応し、対応するノードと状態の同期を行い、前記ノードに代わってペア交換の処理を行う手段を備えたことを特徴とする電力制御ネットワークシステム。

請求項8

請求項7に記載の電力制御ネットワークシステムにおいて、前記仮想エージェントをいずれかの仮想ネットワークに収容し、所定のタイミングで前記仮想ネットワークに収容される前記仮想エージェントをランダムシャッフルする手段を備えたことを特徴とする電力制御ネットワークシステム。

請求項9

請求項5に記載の電力制御ネットワークシステムにおいて、前記交換クエリパケット送信手段は、隣接するノードのいずれかにランダムに交換クエリパケットを送信し、前記他の電力消費源に対応するノードは、ペア交換を実行しない場合に、受信元以外の隣接するノードのいずれかにランダムに交換クエリパケットを転送することを特徴とする電力制御ネットワークシステム。

請求項10

請求項1乃至9のいずれか一項に記載の電力制御ネットワークシステムにおいて、前記消費管理手段は、当該電力消費源で電力消費が必要となった場合に、前記クエリパケット送信手段を用いず、予め用意された電力供給源候補の中から電力消費を賄う電力供給源を選択することを特徴とする電力制御ネットワークシステム。

請求項11

請求項1乃至10のいずれか一項に記載の電力制御ネットワークシステムにおいて、各ノードは、収容する電化製品毎に、状況に応じた電力供給の優先度を表すプライオリティ特性を設定する手段と、前記電化製品毎に電力供給のQoS劣化監視して記録する手段と、QoS劣化が記録された場合に前記プライオリティ特性を優先度が高くなる方向に再設定するとともに、他の電化製品の前記プライオリティ特性を優先度が低くなる方向に再設定する手段とを備えたことを特徴とする電力制御ネットワークシステム。

請求項12

請求項11に記載の電力制御ネットワークシステムにおいて、ユーザが制御の不快感を入力するボタンインタフェースを提供する手段を備え、前記ボタンが押された回数を前記QoS劣化に反映することを特徴とする電力制御ネットワークシステム。

請求項13

請求項1乃至12のいずれか一項に記載の電力制御ネットワークシステムにおいて、不適切取引に関する情報を保持し、前記ノードからの問い合わせに対してクエリ信頼性を応答する手段を備えたことを特徴とする電力制御ネットワークシステム。

請求項14

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

請求項15

複数の電力供給源と複数の電力消費源とが送電ネットワークで接続され、前記送電ネットワークにオーバーレイされた制御ネットワークを備えたシステムの前記制御ネットワークにおけるノードを構成する装置を構成するコンピュータを、当該ノードで電力消費が必要となった場合に、周辺ノードに対して必要な電力供給を要求するクエリパケットを送信するクエリパケット送信手段、前記クエリパケットへの応答であるリプライパケットを受信するリプライパケット受信手段、受信したリプライパケットに基づいて電力消費を賄う電力供給源を選択する消費管理手段として機能させる制御プログラム

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

先行技術

0005

特開2011−36118号公報
特表2011−523545号公報
特表2013−539337号公報
特開2014−18059号公報

発明が解決しようとする課題

0006

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

0007

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

0008

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

課題を解決するための手段

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

従来のスマートグリッドにおける制御の概要を示す図(その1)である。
従来のスマートグリッドにおける制御の概要を示す図(その2)である。
第1の実施形態にかかるシステムの構成例を示す図である。
HEMSコントローラの構成例を示す図である。
第1の実施形態における処理例を示すフローチャートである。
ホップ数によりクエリパケットを送信する範囲を規定する例を示す図である。
IPアドレスによりクエリパケットを送信する範囲を規定する例を示す図である。
クエリパケットとリプライパケットの例を示す図(その1)である。
クエリパケットとリプライパケットの例を示す図(その2)である。
クエリパケットとリプライパケットの例を示す図(その3)である。
第2の実施形態における処理例を示すフローチャートである。
交換クエリパケットの例を示す図である。
ペア交換の判断の例を示す図である。
第3の実施形態にかかるシステムの構成例を示す図である。
第3の実施形態における処理例を示すフローチャートである。
第4の実施形態にかかるシステムの構成例を示す図である。
第5の実施形態における仮想ネットワークシャッフルの例を示す図である。
第6の実施形態における処理例を示すフローチャートである。
第6の実施形態における交換クエリの送信の例を示す図である。
第7の実施形態における処理例を示すフローチャートである。
プライオリティカーブの例を示す図(その1)である。
プライオリティカーブの例を示す図(その2)である。
プライオリティカーブの例を示す図(その3)である。
第8の実施形態における処理例を示すフローチャートである。
プライオリティカーブの変更の例を示す図である。
第9の実施形態における処理例を示すフローチャートである。
第10の実施形態にかかるシステムの構成例を示す図である。

実施例

0012

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

0013

<第1の実施形態>
図2は第1の実施形態にかかるシステムの構成例を示す図である。

0014

図2において、複数の家庭1A、1B、1C、・・をカバーする電力配電ネットワーク2にオーバレイする形で制御ネットワーク3が構築されており、各家庭1A、1B、1C、・・に対応するノードとしてHEMS(Home Energy Management System)コントローラ4A、4B、4C、・・が設けられている。なお、家庭1A、1B、1C、・・には、常に電力消費源になるものと、常に電力供給源になるものと、状況に応じて電力消費源になったり電力供給源になったりするものとがある。また、家庭1A、1B、1C、・・には、個人の家庭に限らず、発電を行う事業者事業所が含まれていてもよい。

0015

図3はHEMSコントローラ4(4A、4B、4C、・・)の構成例を示す図である。

0016

図3において、HEMSコントローラ4は、情報表示部41と情報入力部42と消費管理部43と供給管理部44とパケット送受信部45とを備えている。

0017

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

0018

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

0019

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

0020

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

0021

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

0022

図4において、消費側のHEMSコントローラ4の消費管理部43は、消費(予定も含む)の発生を待機し(ステップS101)、消費が発生すると(ステップS101のYES)、必要とする電力、使用時間等の情報を取得し(ステップS102)、必要な電力供給を要求するクエリパケットをブロードキャスト形式で送信する(ステップS103)。

0023

周辺の他のノードのHEMSコントローラ4は、クエリパケットの受信を待機し(ステップS104)、クエリパケットを受信すると(ステップS104のYES)、ブロードキャストによる所定範囲に到達したか否か判断し(ステップS105)、到達していない場合(ステップS105のNO)は周辺の他のノードにクエリパケットを転送する(ステップS106)。

0024

図5はホップ数によりクエリパケットを送信する範囲を規定する例を示す図であり、ホップ数を「2」とした例である。すなわち、電力消費源Sからクエリパケットをブロードキャストする場合、ホップ数が「2」に達するノードA21、A22、A23、B21、C21、C22、D21までクエリパケットが送信される。

0025

図6はIPアドレスによりクエリパケットを送信する範囲を規定する例を示す図であり、より高度に隣接関係を決めるため、発電所からの送電網の構造を考えてアドレスを付与し、そのアドレスに基づいて範囲を決めている。各配電ネットワークの分岐部分で、例えば、8bitずつに区切られたアドレスを階層的に付与する。この方法では、電力消費源Sを例えば「128.25.48.7」とすると、隣接ノードは「128.25.48.**」すべてのノードとなる。また、もう1段階だけ離れたノードは「128.25.**.**」のノード群となる。

0026

図4戻り、HEMSコントローラ4の供給管理部44は、自ノードでの供給可能電力、コスト(売電価格)等の情報を取得し(ステップS107)、クエリパケットに応答するか否か判断し(ステップS108)、応答する場合(ステップS108のYES)、リプライパケットを返信する(ステップS109)。

0027

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

0028

電力を受け入れる場合(ステップS111のYES)、電力供給源のノードに対して受入パケットを送信し(ステップS112)、内部的に、電力、電力コスト、電力供給源等を記録する(ステップS113)。

0029

他のノードのHEMSコントローラ4の供給管理部44は、受入パケットの受信を待機し(ステップS114)、受入パケットを受信すると(ステップS114のYES)、電力、電力コスト、電力消費源等を記録する(ステップS115)。

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

図10に戻り、他のノードのHEMSコントローラ4の消費管理部43は、交換クエリパケットの受信を待機し(ステップS204)、交換クエリパケットを受信すると(ステップS204のYES)、ブロードキャストによる所定範囲に到達したか否か判断し(ステップS205)、到達していない場合(ステップS205のNO)は周辺の他のノードにクエリパケットを転送する(ステップS206)。

0040

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

0041

図12はペア交換の判断の例を示す図であり、ノードAS(消費)とノードAD(供給)の間でペアが形成され、ノードBS(消費)とノードBD(供給)の間でペアが形成され、ノードCS(消費)とノードCD(供給)の間でペアが形成されているものとしている。なお、ノード間の数字はホップ数を示している。

0042

ここで、ノードAS(消費)から交換クエリパケットを送信し、それをノードBS(消費)が受信したとすると、それまでのホップ数の合計が10+10=20であるのに対し、ペア交換をしたとした場合(ノードAS(消費)とノードBD(供給)のペアと、ノードBS(消費)とノードAD(供給)のペアに組み替え)のホップ数の合計は3+3=6となり、距離指標が少なくなるため、ペア交換すると判断される。

0043

また、ノードAS(消費)から送信された交換クエリパケットをノードCS(消費)が受信したとすると、それまでのホップ数の合計が10+10=20であるのに対し、ペア交換をしたとした場合(ノードAS(消費)とノードCD(供給)のペアと、ノードCS(消費)とノードAD(供給)のペアに組み替え)のホップ数の合計は3+25=28となり、距離指標が大きくなるため、ペア交換しないと判断される。

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

図14において、既にペアを形成している消費側のHEMSコントローラ4の消費管理部43は、定期的またはランダムな時間経過によりタイミングの到来を待機し(ステップS301)、タイミングが到来すると(ステップS301のYES)、ペアについての電力、電力コスト、電力消費源(自ノード)、電力供給源等の情報を取得し(ステップS302)、ペア情報をマッチングサーバ5に送信する(ステップS303)。

0052

マッチングサーバ5はペア情報の受信を待機し(ステップS304)、ペア情報を受信すると(ステップS304のYES)、受信したペア情報を一時的に保持する(ステップS305)。

0053

次いで、マッチングサーバ5は、一時的に保持している複数のペア情報について、ペア交換により距離指標が少なくなるか等の観点からペア間のマッチングを行い(ステップS306)、マッチングが成立した場合(ステップS307のYES)、ペア交換する2組のペアのノードに対して交換指示を送信する(ステップS308)。

0054

ペア情報の送信元のノードは、交換指示の受信を待機し(ステップS309)、交換指示を受信すると(ステップS309のYES)、電力消費の記録を新たなペアについてのものに変更し、元のペアの相手ノードに対してもペア交換を通知して記録を変更させる(ステップS310)。

0055

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

0056

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

0057

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

0058

図15は第4の実施形態にかかるシステムの構成例を示す図であり、図2に示した構成または図13に示した構成に加え、新たなサーバまたはマッチングサーバ5の上に、任意数の仮想ネットワーク6を設け、その中に、HEMSコントローラ4A、4B、4C、・・の状態と同期する仮想エージェント7A、7B、7C、・・を収容するようにしている。HEMSコントローラ4A、4B、4C、・・で状態の変化があった場合、対応する仮想エージェント7A、7B、7C、・・に反映され、仮想エージェント7A、7B、7C、・・で状態の変化があった場合もHEMSコントローラ4A、4B、4C、・・に反映される。なお、仮想ネットワーク6が複数となる場合、電力の供給と受入のペアは仮想ネットワークの中に閉じたものとする。

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

図17において、既にペアを形成している消費側のHEMSコントローラ4の消費管理部43は、定期的またはランダムな時間経過によりタイミングの到来を待機し(ステップS401)、タイミングが到来すると(ステップS401のYES)、ペアについての電力、電力コスト、電力消費源(自ノード)、電力供給源等の情報を取得し(ステップS402)、ペア交換を要求する交換クエリパケットをランダムな1方向に送信する(ステップS403)。

0066

他のノードのHEMSコントローラ4の消費管理部43は、交換クエリパケットの受信を待機し(ステップS404)、交換クエリパケットを受信すると(ステップS404のYES)、自ノードで形成しているペアがあれば、そのペア(複数のペアでも可)についての電力、電力コスト、電力消費源(自ノード)、電力供給源等の情報を取得する(ステップS405)。

0067

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

0068

ペア交換しないと判断された場合(ステップS406のNO)、ホップリミット等による所定範囲に到達したか否か判断し(ステップS407)、到達していない場合(ステップS407のNO)は入口以外のランダムな1方向にクエリパケットを転送する(ステップS408)。

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

図19において、消費側のHEMSコントローラ4の消費管理部43は、消費(予定も含む)の発生を待機し(ステップS501)、消費が発生すると(ステップS501のYES)、必要とする電力、使用時間等の情報を取得し(ステップS502)、イニシャル供給源を電力供給源とする電力受入を記録する(ステップS503)。ペアとなるイニシャル供給源側についても電力供給の記録を行わせる。

0076

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

0077

<第8の実施形態>
第8の実施形態は、各家庭1のHEMSコントローラ4が収容する電化製品毎の性質に基づいて適切な電力の調達を行うようにしたものである。

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

図21において、消費側のHEMSコントローラ4の消費管理部43は、定期的な時間経過によりタイミングの到来を待機し(ステップS601)、タイミングが到来すると(ステップS601のYES)、収容する電化製品についてのタイプ、設定状態、QoS劣化記録等の情報を取得し(ステップS602)、電化製品毎にプライオリティカーブを設定する(ステップS603)。プライオリティカーブとしては図20A図20Cに示したようなものがある。

0085

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

0086

図21に戻り、消費管理部43は、電化製品毎にQoS劣化を監視し、QoS劣化が検出された場合(ステップS604のYES)にはその旨を記録する(ステップS605)。

0087

一方、消費管理部43は、消費(予定も含む)の発生を待機し(ステップS606)、消費が発生すると(ステップS606のYES)、電力、使用時間、電化製品ID、デッドライン、温度、最小電力等の情報を取得し(ステップS607)、電化製品毎に予め設定されているプライオリティカーブから現時点のプライオリティを取得する(ステップS608)。

0088

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

0089

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

0090

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

0091

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

0092

図23は第9の実施形態における処理例を示すフローチャートである。図23において、HEMSコントローラ4の情報入力部42は、ユーザにより「いやね」ボタンが押されるのを待機し(ステップS701)、「いやね」ボタンが押されると(ステップS701のYES)、その旨を記録する(ステップS702)。

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

国際出願は、2014年4月17日に出願した日本国特許出願第2014−085848号に基づく優先権を主張するものであり、日本国特許出願第2014−085848号の全内容を本国際出願に援用する。

0101

1、1A〜1C家庭
2電力配電ネットワーク
3制御ネットワーク
4、4A〜4CHEMSコントローラ
41情報表示部
42情報入力部
43消費管理部
44供給管理部
45パケット送受信部
5マッチングサーバ
6仮想ネットワーク
7、7A〜7C仮想エージェント
8 認証サーバ

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ