JP7390908B2 - レポートシステム、第１装置、第２装置、及びレポート方法 - Google Patents

Description

本発明は、レポートシステム、第１装置、第２装置、及びレポート方法に関する。

近年、VPP（Virtual Power Plant）などのように、電力系統の電力需給バランスを調整するシステムが注目を集めている。このようなシステムで用いる通信プロトコルとして、Open ADR（Automated Demand Response）が知られている（例えば、非特許文献１）。

Open ADRの最新版であるOpen ADR 2.0 B Profileでは、各種情報要素のレポートサービスにおいてレポートペイロードの再送が推奨されていない。但し、レポートペイロードの再送がサポートされる場合においては、レポートペイロードの受信に失敗すると、レポートペイロードの受信に成功するまで、レポートペイロードの再送が繰り返される。

Open ADR 2.0 Profile Specification B Profile, Revision Number 1.1, 2015年11月17日

ところで、レポートペイロードの受信に失敗するケースとしては、送信装置と受信装置との間のネットワークで障害が生じるケース、送信装置及び受信装置のいずれか１つで障害が生じるケースなどが考えられる。このような障害として、短期間で回復可能な障害だけではなく、長期間に亘って継続する障害も考えられる。

長期間に亘って継続する障害が生じたケースにおいて、レポートペイロードの再送が繰り返されると、送信装置のリソースが無駄になってしまう。

そこで、本発明は、上述した課題を解決するためになされたものであり、送信装置のリソースが無駄になる事態を軽減することを可能とするレポートシステム、第１装置、第２装置、及びレポート方法を提供することを目的とする。

第１の特徴に係るレポートシステムでは、送信装置から受信装置に対してレポートが送信される。前記レポートシステムにおいて、前記送信装置及び前記受信装置の一方である第１装置は、前記送信装置及び前記受信装置の他方である第２装置に対して、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信する第１送信部を備える。前記第２装置は、前記第１装置に対して、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信する第２送信部を備える。

第２の特徴に係る第１装置は、送信装置から受信装置に対してレポートが送信されるレポートシステムにおいて、前記送信装置及び前記受信装置のいずれか一方である。前記第１装置は、前記送信装置及び前記受信装置の他方である第２装置に対して、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信する送信する送信部と、前記第２装置から、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを受信する受信部を備える。

第３の特徴に係る第２装置は、送信装置から受信装置に対してレポートが送信されるレポートシステムにおいて、前記送信装置及び前記受信装置のいずれか一方である。前記第２装置は、前記送信装置及び前記受信装置の他方である第１装置から、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを受信する受信部と、前記第１装置に対して、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信する送信部を備える。

第４の特徴に係るレポート方法は、送信装置から受信装置に対してレポートを送信する方法である。前記レポート方法は、前記送信装置及び前記受信装置の一方である第１装置から、前記送信装置及び前記受信装置の他方である第２装置に対して、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信するステップと、前記第２装置から、前記第１装置に対して、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信するステップと、を備える。

本発明によれば、送信装置のリソースが無駄になる事態を軽減することを可能とするレポートシステム、第１装置、第２装置、及びレポート方法を提供することができる。

図１は、実施形態に係るレポートシステム１００を示す図である。 図２は、実施形態に係る施設３００を示す図である。 図３は、実施形態に係る下位管理サーバ２００を示す図である。 図４は、実施形態に係る上位管理サーバ４００を示す図である。 図５は、実施形態に係るローカル制御装置３６０を示す図である。 図６は、実施形態に係る挙動定義を説明するための図である。 図７は、実施形態に係るレポート方法の概要を示す図である。 図８は、実施形態に係るレポート方法の第１手順を示す図である。 図９は、実施形態に係るレポート方法の第２手順を示す図である。 図１０は、実施形態に係るレポート方法の第３手順を示す図である。

以下において、実施形態について図面を参照しながら説明する。なお、以下の図面の記載において、同一又は類似の部分には、同一又は類似の符号を付している。但し、図面は模式的なものである。

［実施形態］
（レポートシステム）
以下において、実施形態に係るレポートシステムについて説明する。

図１に示すように、レポートシステム１００は、下位管理サーバ２００と、施設３００と、上位管理サーバ４００と、を有する。図１では、施設３００として、施設３００Ａ～施設３００Ｃが例示されている。

各施設３００は、電力系統１１０に接続される。以下において、電力系統１１０から施設３００への電力の流れを潮流と称し、施設３００から電力系統１１０への電力の流れを逆潮流と称する。

下位管理サーバ２００、施設３００及び上位管理サーバ４００は、ネットワーク１２０に接続されている。ネットワーク１２０は、これらのエンティティ間の回線を提供すればよい。例えば、ネットワーク１２０は、インターネットを含んでもよい。ネットワーク１２０は、VPN（Virtual Private Network）などの専用回線を含んでもよい。

下位管理サーバ２００は、施設３００の電力を管理する電力管理サーバの一例である。下位管理サーバ２００は、レポートを送信する送信装置の一例である。下位管理サーバ２００は、発電事業者、送配電事業者或いは小売事業者、リソースアグリゲータなどの事業者によって管理されるサーバである。リソースアグリゲータは、VPP（Virtual Power Plant）において、発電事業者、送配電事業者及び小売事業者などに逆潮流電力を提供する電力事業者である。リソースアグリゲータは、リソースアグリゲータによって管理される施設３００の潮流電力（消費電力）の削減電力を生み出す電力事業者であってもよい。

下位管理サーバ２００は、施設３００に設けられるローカル制御装置３６０に対して、施設３００に設けられる分散電源（例えば、太陽電池装置３１０、蓄電装置３２０又は燃料電池装置３３０）に対する制御を指示する制御メッセージを送信する。例えば、下位管理サーバ２００は、潮流電力の制御を要求する潮流制御メッセージ（例えば、DR; Demand Response）を送信してもよく、逆潮流電力の制御を要求する逆潮流制御メッセージを送信してもよい。さらに、下位管理サーバ２００は、分散電源の動作状態を制御する電源制御メッセージを送信してもよい。潮流電力又は逆潮流電力の制御度合いは、絶対値（例えば、○○ｋＷ）で表されてもよく、相対値（例えば、○○％）で表されてもよい。或いは、潮流電力又は逆潮流電力の制御度合いは、２以上のレベルで表されてもよい。潮流電力又は逆潮流電力の制御度合いは、現在の電力需給バランスによって定められる電力料金（RTP; Real Time Pricing）によって表されてもよく、過去の電力需給バランスによって定められる電力料金（TOU; Time Of Use）によって表されてもよい。

施設３００は、電力系統１１０の電力を調整する主体である施設エンティティに属する施設の一例である。施設３００は、図２に示すように、太陽電池装置３１０と、蓄電装置３２０と、燃料電池装置３３０と、負荷機器３４０と、ローカル制御装置３６０と、電力計３８０と、を有する。

太陽電池装置３１０は、太陽光などの光に応じて発電を行う分散電源である。太陽電池装置３１０は、固定買取価格（FIT; Feed-in Tariff））が適用される分散電源の一例であってもよい。例えば、太陽電池装置３１０は、PCS（Power Conditioning System）及び太陽光パネルによって構成される。太陽電池装置３１０は、下位管理サーバ２００によって制御可能な制御対象設備の一例であってもよい。

ここで、太陽電池装置３１０から出力される電力は、太陽光などの光の受光量によって変動し得る。従って、太陽電池装置３１０の発電効率を考慮した場合には、太陽電池装置３１０から出力される電力は、太陽光パネルの受光量によって変動し得る可変電力である。

蓄電装置３２０は、電力の充電及び電力の放電を行う分散電源である。蓄電装置３２０は、固定買取価格が適用されない分散電源の一例であってもよい。例えば、蓄電装置３２０は、ＰＣＳ及び蓄電セルによって構成される。蓄電装置３２０は、下位管理サーバ２００によって制御可能な制御対象設備の一例であってもよい。

燃料電池装置３３０は、燃料を用いて発電を行う分散電源である。燃料電池装置３３０は、固定買取価格が適用されない分散電源の一例であってもよい。例えば、燃料電池装置３３０は、ＰＣＳ及び燃料電池セルによって構成される。燃料電池装置３３０は、下位管理サーバ２００によって制御可能な制御対象設備の一例であってもよい。

例えば、燃料電池装置３３０は、固体酸化物型燃料電池（SOFC: Solid Oxide Fuel Cell）であってもよく、固体高分子型燃料電池（PEFC: Polymer Electrolyte Fuel Cell）であってもよく、リン酸型燃料電池（PAFC: Phosphoric Acid Fuel Cell）であってもよく、溶融炭酸塩型燃料電池（MCFC: Molten Carbonate Fuel Cell）であってもよい。

負荷機器３４０は、電力を消費する機器である。例えば、負荷機器３４０は、空調機器、照明機器、ＡＶ（Ａｕｄｉｏ Ｖｉｓｕａｌ）機器などである。負荷機器３４０は、下位管理サーバ２００によって制御されない非制御対象設備の一例であってもよい。

ローカル制御装置３６０は、施設３００の電力を管理する装置（EMS: Energy Management System）である。ローカル制御装置３６０は、太陽電池装置３１０の動作状態を制御してもよく、施設３００に設けられる蓄電装置３２０の動作状態を制御してもよく、施設３００に設けられる燃料電池装置３３０の動作状態を制御してもよい。ローカル制御装置３６０の詳細については後述する（図５を参照）。

実施形態において、下位管理サーバ２００とローカル制御装置３６０との間の通信は、第１プロトコルに従って行われる。一方で、ローカル制御装置３６０と分散電源（太陽電池装置３１０、蓄電装置３２０又は燃料電池装置３３０）との間の通信は、第１プロトコルとは異なる可能性がある第２プロトコルに従って行われてもよい。例えば、第１プロトコルとしては、Open ADR(Automated Demand Response)に準拠するプロトコル、或いは、独自の専用プロトコルを用いることができる。例えば、第２プロトコルは、ECHONET Liteに準拠するプロトコル、SEP(Smart Energy Profile) 2.0、KNX、或いは、独自の専用プロトコルを用いることができる。例えば、第１プロトコル及び第２プロトコルは、両方が独自の専用プロトコルであっても異なる規則で作られたプロトコルであればよい。但し、第１プロトコル及び第２プロトコルは同一の規則で作られたプロトコルであってもよい。

電力計３８０は、電力系統１１０から施設３００への潮流電力及び施設３００から電力系統１１０への逆潮流電力を測定する基幹電力計の一例である。例えば、電力計３８０は、上位管理サーバ４００に帰属するスマートメータである。

ここで、電力計３８０は、所定期間（例えば、３０分）毎に、所定期間における潮流電力又は逆潮流電力の積算値を示す情報要素を含むメッセージをローカル制御装置３６０に送信する。電力計３８０は、自律的にメッセージを送信してもよく、ローカル制御装置３６０の要求に応じてメッセージを送信してもよい。電力計３８０は、所定期間毎に、所定期間における潮流電力又は逆潮流電力を示す情報要素を含むメッセージを下位管理サーバ２００に送信してもよい。

図１に戻って、上位管理サーバ４００は、施設３００の電力を管理する電力管理サーバの一例である。上位管理サーバ４００は、レポートを受信する受信装置の一例である。例えば、上位管理サーバ４００は、電力系統１１０などのインフラストラクチャーを提供するエンティティであり、発電事業者又は送配電事業者によって管理されるサーバであってもよい。上位管理サーバ４００は、リソースアグリゲータを制御するアグリゲータコントローラによって管理されるサーバであってもよい。上位管理サーバ４００は、下位管理サーバ２００を管理するエンティティに対して、各種の業務を委託してもよい。

実施形態において、下位管理サーバ２００と上位管理サーバ４００との間の通信は、第３プロトコルに従って行われる。例えば、第３プロトコルとしては、Open ADRに準拠するプロトコルを用いることができる。第１プロトコルとしてOpen ADRに準拠するプロトコルが用いられる場合には、第３プロトコルは第１プロトコルと同じであってもよい。

実施形態において、下位管理サーバ２００から上位管理サーバ４００に送信されるレポートは、施設３００の電力に関する情報要素を含んでもよい。例えば、レポートは、電力計３８０によって測定された電力を示す情報要素を含んでもよい。レポートは、太陽電池装置３１０の発電電力を示す情報要素を含んでもよい。レポートは、蓄電装置３２０の充電電力及び放電電力の少なくともいずれか１つを示す情報要素を含んでもよい。レポートは、燃料電池装置３３０の発電電力を示す情報要素を含んでもよい。レポートは、各分散電源（太陽電池装置３１０、蓄電装置３２０及び燃料電池装置３３０）の動作状態を示す情報要素を含んでもよい。下位管理サーバ２００は、上位管理サーバ４００に対するレポートに必要な情報を施設３００（ローカル制御装置３６０及び電力計３８０）から受信してもよい。

（下位管理サーバ）
以下において、実施形態に係る下位管理サーバについて説明する。図３に示すように、下位管理サーバ２００は、管理部２１０と、通信部２２０と、制御部２３０と、を有する。下位管理サーバ２００は、VEN(Virtual End Node)の一例であってもよい。

管理部２１０は、不揮発性メモリ又は／及びＨＤＤなどの記憶媒体によって構成されており、施設３００に関する情報を管理する。例えば、施設３００に関する情報は、施設３００に設けられる分散電源（太陽電池装置３１０、蓄電装置３２０又は燃料電池装置３３０）の種別、施設３００に設けられる分散電源（太陽電池装置３１０、蓄電装置３２０又は燃料電池装置３３０）のスペックなどである。スペックは、太陽電池装置３１０の定格発電電力、蓄電装置３２０の定格電力、燃料電池装置３３０の定格電力であってもよい。

通信部２２０は、通信モジュールによって構成されており、ネットワーク１２０を介してローカル制御装置３６０及び上位管理サーバ４００と通信を行う。通信モジュールは、IEEE802.11a/b/g/n、ZigBee、Wi-SUN、LTEなどの規格に準拠する無線通信モジュールであってもよく、IEEE802.3などの規格に準拠する有線通信モジュールであってもよい。

通信部２２０は、第１プロトコルに従って通信を行う。例えば、通信部２２０は、第１プロトコルに従って所定メッセージをローカル制御装置３６０に送信する。通信部２２０は、第１プロトコルに従って所定メッセージ応答をローカル制御装置３６０から受信する。

実施形態では、通信部２２０は、第３プロトコルに従って通信を行う。例えば、通信部２２０は、上述したレポートを上位管理サーバ４００に送信する。さらに、通信部２２０は、下位管理サーバ２００と上位管理サーバ４００との間の設定手順で用いるメッセージの送信又は受信を行う。設定手順は、下位管理サーバ２００を上位管理サーバ４００に登録する装置登録手順、下位管理サーバ２００が対応可能なレポートの能力を上位管理サーバ４００に登録する能力登録手順、上位管理サーバ４００が下位管理サーバ２００に対してレポートの開始を要求するレポート要求手順、下位管理サーバ２００から上位管理サーバにレポートを送信するレポート送信手順などを含んでもよい。

制御部２３０は、少なくとも１つのプロセッサを含んでもよい。少なくとも１つのプロセッサは、単一の集積回路（ＩＣ）によって構成されてもよく、通信可能に接続された複数の回路（集積回路及び又はディスクリート回路（discrete circuits）など）によって構成されてもよい。

制御部２３０は、下位管理サーバ２００に設けられる各構成を制御する。例えば、制御部２３０は、制御メッセージの送信によって、施設３００に設けられるローカル制御装置３６０に対して、施設３００に設けられる分散電源（太陽電池装置３１０、蓄電装置３２０又は燃料電池装置３３０）に対する制御を指示する。制御メッセージは、上述したように、潮流制御メッセージであってもよく、逆潮流制御メッセージであってもよく、電源制御メッセージであってもよい。

実施形態では、制御部２３０は、上述した設定手順を実行する。上述したように、設定手順は、装置登録手順、能力登録手順、レポート要求手順などを含んでもよい。

（上位管理サーバ）
以下において、実施形態に係る上位管理サーバについて説明する。図４に示すように、上位管理サーバ４００は、管理部４１０と、通信部４２０と、制御部４３０と、を有する。上位管理サーバ４００は、VTN(Virtual Top Node)の一例であってもよい。

管理部４１０は、不揮発性メモリ又は／及びＨＤＤなどの記憶媒体によって構成されており、施設３００に関する情報を管理する。例えば、管理部４１０は、下位管理サーバ２００から受信するレポートに含まれる情報を管理する。

通信部４２０は、通信モジュールによって構成されており、ネットワーク１２０を介して下位管理サーバ２００と通信を行う。通信モジュールは、IEEE802.11a/b/g/n、ZigBee、Wi-SUN、LTEなどの規格に準拠する無線通信モジュールであってもよく、IEEE802.3などの規格に準拠する有線通信モジュールであってもよい。

通信部４２０は、第３プロトコルに従って通信を行う。例えば、通信部４２０は、上述したレポートを下位管理サーバ２００から受信する。さらに、通信部４２０は、下位管理サーバ２００と上位管理サーバ４００との間の設定手順で用いるメッセージの送信又は受信を行う。

制御部４３０は、少なくとも１つのプロセッサを含んでもよい。少なくとも１つのプロセッサは、単一の集積回路（ＩＣ）によって構成されてもよく、通信可能に接続された複数の回路（集積回路及び又はディスクリート回路（discrete circuits）など）によって構成されてもよい。

制御部４３０は、上位管理サーバ４００に設けられる各構成を制御する。例えば、制御部４３０は、上述した設定手順を実行する。上述したように、設定手順は、装置登録手順、能力登録手順、レポート要求手順、レポート送信手順などを含んでもよい。

（ローカル制御装置）
以下において、実施形態に係るローカル制御装置について説明する。図５に示すように、ローカル制御装置３６０は、第１通信部３６１と、第２通信部３６２と、制御部３６３とを有する。なお、図５では、第１プロトコル及び第２プロトコルが異なるケースの説明を明確化すべく、第１通信部３６１及び第２通信部３６２が別々の構成として表されているに過ぎない。従って、第１通信部３６１及び第２通信部３６２は１つの通信部によって構成されてもよい。なお、第１プロトコル及び第２プロトコルとして同一のプロトコルが用いられてもよい。

第１通信部３６１は、通信モジュールによって構成されており、ネットワーク１２０を介して下位管理サーバ２００と通信を行う。通信モジュールは、IEEE802.11a/b/g/n、ZigBee、Wi-SUN、LTEなどの規格に準拠する無線通信モジュールであってもよく、IEEE802.3などの規格に準拠する有線通信モジュールであってもよい。

上述したように、第１通信部３６１は、第１プロトコルに従って通信を行う。例えば、第１通信部３６１は、第１プロトコルに従って所定メッセージを下位管理サーバ２００から受信する。第１通信部３６１は、第１プロトコルに従って所定メッセージ応答を下位管理サーバ２００に送信する。

第２通信部３６２は、通信モジュールによって構成されており、分散電源（太陽電池装置３１０、蓄電装置３２０又は燃料電池装置３３０）と通信を行う。通信モジュールは、IEEE802.11a/b/g/n、ZigBee、Wi-SUN、LTEなどの規格に準拠する無線通信モジュールであってもよく、IEEE802.3又は独自の専用プロトコルなどの規格に準拠する有線通信モジュールであってもよい。

上述したように、第２通信部３６２は、第２プロトコルに従って通信を行う。例えば、第２通信部３６２は、第２プロトコルに従って所定メッセージを分散電源に送信する。第２通信部３６２は、第２プロトコルに従って所定メッセージ応答を分散電源から受信する。

制御部３６３は、少なくとも１つのプロセッサを含んでもよい。少なくとも１つのプロセッサは、単一の集積回路（ＩＣ）によって構成されてもよく、通信可能に接続された複数の回路（集積回路及び又はディスクリート回路（discrete circuits）など）によって構成されてもよい。

制御部３６３は、ローカル制御装置３６０に設けられる各構成を制御する。具体的には、制御部３６３は、施設３００の電力を制御するために、所定メッセージの送信及び所定メッセージ応答の受信によって、分散電源の動作状態の設定を機器に指示する。制御部３６３は、施設３００の電力を管理するために、所定メッセージの送信及び所定メッセージ応答の受信によって分散電源の情報の報告を分散電源に指示してもよい。

（適用シーン）
以下において、実施形態に係る適用シーンについて説明する。実施形態では、下位管理サーバ２００（すなわち、送信装置）から上位管理サーバ４００（すなわち、受信装置）に対してレポートを送信するケースについて例示する。

このようなケースにおいて、下位管理サーバ２００及び上位管理サーバ４００の一方である第１装置は、下位管理サーバ２００及び上位管理サーバ４００の他方である第２装置に対して、レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信する。一方で、第２装置は、第１装置に対して、挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信する。挙動定義は、レポートの再送に関する挙動の定義を意味する。

図６に示すように、レポートの再送に関する挙動定義は、再送有無、再送期間、保持期間及び最大量の少なくともいずれか１つを含む。

再送有無は、レポートの再送を行うか否かを定義する情報要素である。再送有無が取り得る値は有及び無の値である。

再送期間は、レポートの再送を継続する期間を定義する情報要素である。再送期間が取り得る値は、２４時間、３６時間、４８時間、７２時間などの値である。例えば、再送期間が２４時間である場合には、２４時間に亘ってレポートの再送が行われる。但し、下位管理サーバ２００は、レポートを受信した旨のメッセージを上位管理サーバ４００から受信した場合にレポートの再送を終了してもよい。

保持期間は、上位管理サーバ４００で受信されなかったレポートの内容を保持する期間を定義する情報要素である。保持期間が取り得る値は、２４時間、３６時間、４８時間、７２時間などの値である。例えば、再送期間が２４時間である場合には、２４時間に亘ってレポートの内容が保持される。但し、下位管理サーバ２００は、レポートを受信した旨のメッセージを上位管理サーバ４００から受信した場合にレポートの内容を破棄してもよい。

保持期間は、再送期間と同じであってもよい。例えば、再送期間及び保持期間がいずれも２４時間であってもよい。このようなケースにおいて、下位管理サーバ２００は、保持期間が満了するまでレポートの内容を保持しつつレポートの再送を行う。下位管理サーバ２００は、上位管理サーバ４００の要求に応じてレポートを送信してもよい。例えば、下位管理サーバ２００は、ｎ回目（ｎは１以上）の再送とｎ＋１回目の再送との間において上位管理サーバ４００から要求された場合に、上位管理サーバ４００にレポートを送信してもよい。

保持期間は、再送期間と異なってもよい。保持期間は、再送期間よりも長い。例えば、再送期間が２４時間であり、保持期間が７２時間であってもよい。このようなケースにおいて、下位管理サーバ２００は、再送期間が満了した後においてもレポートの内容を保持する。下位管理サーバ２００は、上位管理サーバ４００の要求に応じてレポートを送信してもよい。例えば、下位管理サーバ２００は、再送期間が満了した後において上位管理サーバ４００から要求された場合に、上位管理サーバ４００にレポートを送信してもよい。

例えば、挙動定義は、（ｉ）再送有無＝無、（ｉｉ）再送有無＝無、保持期間＝２４時間、（ｉｉｉ）再送有無＝有、再送期間＝２４時間、保持期間＝２４時間、（ｉｖ）再送有無＝有、再送期間＝２４時間、保持期間＝７２時間などのバリエーションを含んでもよい。

実施形態において、再送有無、再送期間及び保持期間の組合せを特定する識別情報要素が予め定義されてもよい。このようなケースにおいて、挙動定義の候補及び挙動定義に関する情報要素は識別情報要素であってもよい。例えば、識別情報要素は、上述した挙動定義のバリエーション毎に割り振られた情報要素であってもよい。

（レポート方法の概要）
以下において、実施形態に係るレポート方法の概要について説明する。図７において、下位管理サーバ２００が送信装置であり、上位管理サーバ４００が受信装置である。ここでは、第３プロトコルとしてOpen ADRに準拠するプロトコルが用いられるケースを例示する。図７では、レポートの受信に成功するケースを例示する。

図７に示すように、ステップＳ１１において、下位管理サーバ２００は、CreatePartyRegistrationを上位管理サーバ４００に送信する。ステップＳ１２において、上位管理サーバ４００は、CreatedPartyRegistrationを下位管理サーバ２００に送信する。ステップＳ１１及びステップＳ１２は、下位管理サーバ２００を上位管理サーバ４００に登録する装置登録手順の一例である。CreatePartyRegistrationは、下位管理サーバ２００を上位管理サーバ４００に登録するための装置登録メッセージの一例であり、CreatedPartyRegistrationは、装置登録メッセージに対する応答メッセージの一例である。

例えば、CreatePartyRegistrationは、下位管理サーバ２００が対応する第３プロトコルのプロファイル情報（例えば、oadrProfileName）、下位管理サーバ２００が対応するトランスポート情報（例えば、oadrTransportName）などを含む。再登録手順においては、CreatePartyRegistrationは、過去の登録手順で用いた識別情報（Registration ID、venID）を含んでもよい。CreatePartyRegistrationは、他の情報（例えば、oadrVenName）を含んでもよい（OpenADR 2.0b Profile Specificationの§8.4.2.1を参照）。

例えば、CreatePartyRegistrationは、下位管理サーバ２００の登録及び解除に用いる識別情報（例えば、Registration ID）、下位管理サーバ２００に割り当てられた識別情報（venID）などを含む（OpenADR 2.0b Profile Specificationの§8.4.2.2を参照）。

ステップＳ２１において、下位管理サーバ２００は、RegisterReportを上位管理サーバ４００に送信する。ステップＳ２２において、上位管理サーバ４００は、RegisteredReportを下位管理サーバ２００に送信する。ステップＳ２１及びステップＳ２２は、下位管理サーバ２００が対応可能なレポートの能力を上位管理サーバ４００に登録する能力登録手順の一例である。RegisterReportは、下位管理サーバ２００が対応可能なレポートの能力を上位管理サーバ４００に登録するための能力登録メッセージの一例であり、RegisteredReportは、能力登録メッセージに対する応答メッセージの一例である。

例えば、RegisterReportは、下位管理サーバ２００が送信可能なレポートの内容（例えば、METADATA report）を含む。METADATA reportは、下位管理サーバ２００が対応可能なレポートの識別情報（例えば、reportSpecifierID）、RegisterReportは、下位管理サーバ２００が対応可能なレポートの種別（例えば、reportType）、レポートによって提供されるデータの識別情報（例えば、rid）、レポートに含まれるデータの集計期間（例えば、Duration）などを含む（OpenADR 2.0b Profile Specificationの§8.3.2.1を参照）。

例えば、RegisteredReportは、上位管理サーバ４００が下位管理サーバ２００から受信したいと望むレポートを特定する情報を含む（OpenADR 2.0b Profile Specificationの§8.3.2.1を参照）。

ステップＳ３１において、上位管理サーバ４００は、CreateReportを下位管理サーバ２００に送信する。ステップＳ３２において、下位管理サーバ２００は、CreatedReportを上位管理サーバ４００に送信する。ステップＳ３１及びステップＳ３２は、上位管理サーバ４００が下位管理サーバ２００に対してレポートの開始を要求するレポート要求手順の一例である。CreateReportは、下位管理サーバ２００に対してレポートの開始を要求する要求メッセージの一例であり、CreatedReportは、要求メッセージに対する応答メッセージの一例である。

例えば、CreateReportは、下位管理サーバ２００が対応可能なレポートの識別情報（例えば、METADATA reportに含まれるreportSpecifierID）、以降の運用で用いる識別情報（例えば、reportRequestID）を含む（OpenADR 2.0b Profile Specificationの§8.3.2.2を参照）。

例えば、CreatedReportは、CreateReportによって要求されたレポートを開始可能であるか否かを示す情報（例えば、Response）を含む（OpenADR 2.0b Profile Specificationの§8.3.2.2を参照）。

ここで、ステップＳ１１、ステップＳ１２、ステップＳ２１、ステップＳ２２、ステップＳ３１及びステップＳ３２は、下位管理サーバ２００と上位管理サーバ４００との間の設定手順の一例である。

ステップＳ４１において、下位管理サーバ２００は、UpdateReportを上位管理サーバ４００に送信する。ステップＳ４２において、上位管理サーバ４００は、UpdatedReportを下位管理サーバ２００に送信する。ステップＳ４１及びステップＳ４２は、下位管理サーバ２００から上位管理サーバにレポートを送信するレポート送信手順の一例である。

例えば、UpdateReportは、上述したレポートの一例であり、UpdatedReportは、レポートを受信した旨のメッセージである。

このような背景下において、下位管理サーバ２００と上位管理サーバ４００との間における挙動定義のネゴシエーションは以下の手順で行うことができる。

（第１手順）
以下において、実施形態に係るレポート方法の第１手順について説明する。図８においては、図７と同様のステップについて同様の符号を付している。以下においては、図７と同様のステップの説明については省略する。図８では、レポートの受信に失敗するケースを例示する。

図８に示すように、ステップＳ１１Ａにおいて、下位管理サーバ２００は、CreatePartyRegistrationを上位管理サーバ４００に送信する。ここで、CreatePartyRegistrationは、挙動定義の候補に関する情報要素を含む。言い換えると、CreatePartyRegistrationは、第１メッセージの一例である。

ステップＳ１２Ａにおいて、上位管理サーバ４００は、CreatedPartyRegistrationを下位管理サーバ２００に送信する。ここで、CreatedPartyRegistrationは、挙動定義の候補の中から選択された挙動定義に関する情報要素を含む。言い換えると、CreatedPartyRegistrationは、第２メッセージの一例である。

ステップＳ４１Ａにおいて、下位管理サーバ２００は、装置登録手順で合意された挙動定義に従って、UpdateReportを上位管理サーバ４００に再送する。

このように、第１手順では、装置登録手順で挙動定義のネゴシエーションが行われる。挙動定義の候補に関する情報要素を含む第１メッセージを送信する第１装置は下位管理サーバ２００であり、選択された挙動定義に関する情報要素を含む第２メッセージを送信する第２装置は上位管理サーバ４００である。

（第２手順）
以下において、実施形態に係るレポート方法の第２手順について説明する。図９においては、図７と同様のステップについて同様の符号を付している。以下においては、図７と同様のステップの説明については省略する。図９では、レポートの受信に失敗するケースを例示する。

図９に示すように、ステップＳ２１Ａにおいて、下位管理サーバ２００は、RegisterReportを上位管理サーバ４００に送信する。ここで、RegisterReportは、挙動定義の候補に関する情報要素を含む。言い換えると、RegisterReportは、第１メッセージの一例である。

ステップＳ２２Ａにおいて、上位管理サーバ４００は、RegisteredReportを下位管理サーバ２００に送信する。ここで、RegisteredReportは、挙動定義の候補の中から選択された挙動定義に関する情報要素を含む。言い換えると、RegisteredReportは、第２メッセージの一例である。

ステップＳ４１Ａにおいて、下位管理サーバ２００は、能力登録手順で合意された挙動定義に従って、UpdateReportを上位管理サーバ４００に再送する。

このように、第２手順では、能力登録手順で挙動定義のネゴシエーションが行われる。挙動定義の候補に関する情報要素を含む第１メッセージを送信する第１装置は下位管理サーバ２００であり、選択された挙動定義に関する情報要素を含む第２メッセージを送信する第２装置は上位管理サーバ４００である。
（第３手順）

以下において、実施形態に係るレポート方法の第３手順について説明する。図１０においては、図７と同様のステップについて同様の符号を付している。以下においては、図７と同様のステップの説明については省略する。図１０では、レポートの受信に失敗するケースを例示する。

ステップＳ３１Ａにおいて、上位管理サーバ４００は、CreateReportを下位管理サーバ２００に送信する。ここで、CreateReportは、挙動定義の候補に関する情報要素を含む。言い換えると、CreateReportは、第１メッセージの一例である。

ステップＳ３２において、下位管理サーバ２００は、CreatedReportを上位管理サーバ４００に送信する。ここで、CreatedReportは、挙動定義の候補の中から選択された挙動定義に関する情報要素を含む。言い換えると、CreatedReportは、第２メッセージの一例である。

ステップＳ４１Ａにおいて、下位管理サーバ２００は、レポート要求手順で合意された挙動定義に従って、UpdateReportを上位管理サーバ４００に再送する。

このように、第３手順では、レポート要求手順で挙動定義のネゴシエーションが行われる。挙動定義の候補に関する情報要素を含む第１メッセージを送信する第１装置は上位管理サーバ４００であり、選択された挙動定義に関する情報要素を含む第２メッセージを送信する第２装置は下位管理サーバ２００である。

（作用及び効果）
実施形態では、下位管理サーバ２００及び上位管理サーバ４００の一方である第１装置は、下位管理サーバ２００及び上位管理サーバ４００の他方である第２装置に対して、レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信する。一方で、第２装置は、第１装置に対して、挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信する。このような構成によれば、下位管理サーバ２００と上位管理サーバ４００との間でレポートの再送に関する挙動定義が行われる。従って、上位管理サーバ４００で生じるデータ欠損の可能性を低減しながらも、下位管理サーバ２００のリソースが無駄になる事態を軽減することができる。

［その他の実施形態］
本発明は上述した実施形態によって説明したが、この開示の一部をなす論述及び図面は、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなろう。

実施形態の第１手順及び第２手順においては、下位管理サーバ２００の通信部２２０は、第１メッセージを送信する第１送信部及び送信部を構成するとともに、第２メッセージを受信する受信部を構成する。上位管理サーバ４００の通信部４２０は、第１メッセージを受信する受信部を構成するとともに、第２メッセージを送信する第２送信部及び送信部を構成する。一方で、実施形態の第３手順においては、上位管理サーバ４００の通信部４２０は、第１メッセージを送信する第１送信部及び送信部を構成するとともに、第２メッセージを受信する受信部を構成する。下位管理サーバ２００の通信部２２０は、第１メッセージを受信する受信部を構成するとともに、第２メッセージを送信する第２送信部及び送信部を構成する。

実施形態では、下位管理サーバ２００が送信装置であり、上位管理サーバ４００が受信装置であるケースを例示した。しかしながら、実施形態はこれに限定されるものではない。具体的には、ローカル制御装置３６０が送信装置であり、下位管理サーバ２００が受信装置であってもよい。このようなケースにおいては、ローカル制御装置３６０がVENであり、下位管理サーバ２００がVTNであってもよい。

実施形態では特に触れていないが、挙動定義は、レポートの再送間隔、レポートの冗長構成などを含んでもよい。すなわち、第１メッセージは、レポートの再送間隔の候補に関する情報要素、レポートの冗長構成の候補に関する情報要素などを含んでもよい。第２メッセージは、選択されたレポートの再送間隔に関する情報要素、選択されたレポートの冗長構成に関する情報要素などを含んでもよい。

実施形態では特に触れていないが、第１メッセージは、１つの挙動定義の候補に関する情報要素を含んでもよい。このようなケースにおいて、第２メッセージは、第１メッセージに含まれる挙動定義の候補を受け入れ可能であるか否かを示す情報要素を含んでもよい。

実施形態では特に触れていないが、挙動定義は、単位時間あたりに許容されるレポートの許容条件を含んでもよい。許容条件は、単位時間において再送可能なレポートの最大回数によって表されてもよく、単位時間において再送可能なレポートの最大データ量によって表されてもよい。このようなケースにおいて、挙動定義は、再送有無、再送期間、保持期間及び許容条件の少なくともいずれか１つを含めばよい。

ここで、再送有無、再送期間、保持期間及び許容条件の中から選択された２以上の要件の組合せを特定する識別情報要素が予め定義されてもよい。このようなケースにおいて、挙動定義の候補及び挙動定義に関する情報要素は識別情報要素であってもよい。例えば、識別情報要素は、上述した挙動定義のバリエーション毎に割り振られた情報要素であってもよい。

実施形態では、各調整電源が別々のＰＣＳを有するケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。２以上の調整電源に対して１つのマルチＤＣリンクのＰＣＳが設けられてもよい。

実施形態では、ローカル制御装置３６０が施設３００に設けられるケースについて例示した。しかしながら、実施形態はこれに限定されるものではない。ローカル制御装置３６０は、クラウドサービスによって提供されてもよい。

実施形態では特に触れていないが、電力とは、瞬時値（ｋＷ）であってもよく、単位時間の積算値（ｋＷｈ）であってもよい。

１００…レポートシステム、１１０…電力系統、１２０…ネットワーク、２００…下位管理サーバ、２１０…管理部、２２０…通信部、２３０…制御部、３００…施設、３１０…太陽電池装置、３２０…蓄電装置、３３０…燃料電池装置、３４０…負荷機器、３６０…ローカル制御装置、３６１…第１通信部、３６２…第２通信部、３６３…制御部、３８０…電力計、４００…上位管理サーバ、４１０…管理部、４２０…通信部、４３０…制御部

Claims (8)

1. 送信装置から受信装置に対してレポートが送信されるレポートシステムであって、
   前記送信装置及び前記受信装置の一方である第１装置は、前記送信装置及び前記受信装置の他方である第２装置に対して、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信する第１送信部を備え、
   前記第２装置は、前記第１装置に対して、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信する第２送信部を備え、
   前記第１送信部は、前記送信装置と前記受信装置との間の設定手順において前記第１メッセージを送信し、
   前記第２送信部は、前記設定手順において前記第２メッセージを送信する、レポートシステム。
2. 前記第１装置は、前記送信装置であり、
   前記第２装置は、前記受信装置であり、
   前記第１送信部は、前記受信装置と通信を行う前記送信装置を前記受信装置に登録するための装置登録メッセージを前記第１メッセージとして送信し、
   前記第２送信部は、前記装置登録メッセージに対する応答メッセージを前記第２メッセージとして送信する、請求項１に記載のレポートシステム。
3. 前記第１装置は、前記送信装置であり、
   前記第２装置は、前記受信装置であり、
   前記第１送信部は、前記送信装置が対応可能な前記レポートの能力を前記受信装置に登録するための能力登録メッセージを前記第１メッセージとして送信し、
   前記第２送信部は、前記能力登録メッセージに対する応答メッセージを前記第２メッセージとして送信する、請求項１に記載のレポートシステム。
4. 前記第１装置は、前記受信装置であり、
   前記第２装置は、前記送信装置であり、
   前記第１送信部は、前記送信装置に対して前記レポートの開始を要求する要求メッセージを前記第１メッセージとして送信し、
   前記第２送信部は、前記要求メッセージに対する応答メッセージを前記第２メッセージとして送信する、請求項１に記載のレポートシステム。
5. 前記挙動定義は、前記レポートの再送の有無、前記レポートの再送を継続する期間、前記受信装置で受信されなかったレポートの内容を保持する期間及び単位時間あたりに許容される前記レポートの許容条件の少なくともいずれか１つを含む、請求項１乃至請求項４のいずれか１項に記載のレポートシステム。
6. 送信装置から受信装置に対してレポートが送信されるレポートシステムにおいて、前記送信装置及び前記受信装置のいずれか一方である第１装置は、
   前記送信装置及び前記受信装置の他方である第２装置に対して、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信する送信する送信部と、
   前記第２装置から、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを受信する受信部を備え、
   前記送信部は、前記送信装置と前記受信装置との間の設定手順において前記第１メッセージを送信し、
   前記受信部は、前記設定手順において前記第２メッセージを受信する、第１装置。
7. 送信装置から受信装置に対してレポートが送信されるレポートシステムにおいて、前記送信装置及び前記受信装置のいずれか一方である第２装置は、
   前記送信装置及び前記受信装置の他方である第１装置から、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを受信する受信部と、
   前記第１装置に対して、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信する送信部を備え、
   前記受信部は、前記送信装置と前記受信装置との間の設定手順において前記第１メッセージを受信し、
   前記送信部は、前記設定手順において前記第２メッセージを送信する、第２装置。
8. 送信装置から受信装置に対してレポートを送信するレポート方法であって、
   前記送信装置及び前記受信装置の一方である第１装置から、前記送信装置及び前記受信装置の他方である第２装置に対して、前記レポートの再送に関する挙動定義の候補に関する情報要素を含む第１メッセージを送信するステップＡと、
   前記第２装置から、前記第１装置に対して、前記挙動定義の候補の中から選択された挙動定義に関する情報要素を含む第２メッセージを送信するステップＢと、を備え、
   前記ステップＡは、前記送信装置と前記受信装置との間の設定手順において前記第１メッセージを送信するステップを含み、
   前記ステップＢは、前記設定手順において前記第２メッセージを送信するステップを含む、レポート方法。