JP2018055486A - ファームウェア提供システム、ファームウェア提供システムの制御方法及び電源システム - Google Patents

Abstract

【課題】電源装置及びコントローラのファームウェアのダウンロード及び更新を効率よく行う。【解決手段】複数の電源装置及び複数の電源装置にそれぞれ対応する制御装置にネットワークを介してファームウェアを提供するサーバを備えるファームウェア提供システムである。サーバは、各制御装置がサーバからファームウェアのダウンロードを実行する第１日時を、サーバの一斉送信可能なデータ容量を超えないように、制御装置にそれぞれ割り当てる。さらに、サーバは、第１日時を含むスケジュール情報を各制御装置に送信する。制御装置は、ネットワークを介してサーバと通信する通信部と、制御部とを備える。制御部は、スケジュール情報をサーバから通信部を介して取得する。さらに、制御部は、第１日時に、ファームウェアをサーバからダウンロードする。【選択図】図１

Description

本発明は、ファームウェア提供システム、ファームウェア提供システムの制御方法及び電源システムに関する。

ファームウェア（Ｆｉｒｍｗａｒｅ）によって所望の機能を実現させる電気機器には、ファームウェアのバージョンアップに応じて、電気機器のファームウェアを提供することが望ましい。そこで、通信機能を備える電気機器では、外部サーバから電気機器にファームウェアをダウンロードすることで、ファームウェアのバージョンアップに応じて、電気機器のファームウェアを更新させている。

一方、電気機器の高機能化に伴い、電気機器のファームウェアのサイズが増加している。そのため、複数の電気機器が、サーバからファームウェアを同時にダウンロードしようとすることで、そのサーバに掛かる負荷が増大してしまい、サーバがダウンしてしまうといった事態が生じることがある。そこで、このような事態を回避すべく、ファームウェアを記憶する宅内通信装置（ＢｒｏａｄＢａｎｄ Ｒｏｕｔｅｒ）と、宅内通信装置のファームウェアを管理する管理サーバとを備える更新システムが開示されている（特許文献１）。

特開２０１２−１１８９１４号公報

特許文献１に記載の更新システムでは、ファームウェアを提供する提供サーバに加えて、管理サーバを設ける必要がある。そのため、管理サーバを設けることによって、コストが増加してしまうことがある。

さらに、燃料電池装置のような電源装置、及び、その電源装置を制御するコントローラのファームウェアのダウンロード及び更新は、確実に完了する必要がある。しかしながら、特許文献１に記載の更新システムには、宅内通信装置のファームウェアのダウンロードが途中で中断されて不完全に終わった場合に、その後、その宅内通信装置のファームウェアを、どのようにして提供するかについては言及されていない。

かかる点に鑑みてなされた本発明の目的は、電源装置及びコントローラのファームウェアのダウンロード及び更新を効率よく行うファームウェア提供システム、フェームウェア提供システムの制御方法及び電源システムを提供することにある。

本発明の一実施形態に係るファームウェア提供システムは、複数の電源装置及び該複数の電源装置にそれぞれ対応する制御装置にネットワークを介してファームウェアを提供するサーバを備える。前記サーバは、各前記制御装置が前記サーバから前記ファームウェアのダウンロードを実行する第１日時を、前記サーバの一斉送信可能なデータ容量を超えないように、前記制御装置にそれぞれ割り当てる。さらに、前記サーバは、前記第１日時を含むスケジュール情報を各前記制御装置に送信する。前記制御装置のそれぞれは、前記ネットワークを介して前記サーバと通信する通信部と、制御部とを備える。前記制御部は、前記スケジュール情報を前記サーバから前記通信部を介して取得し、さらに、前記第１日時に、前記ファームウェアを前記サーバからダウンロードする。

本発明の一実施形態に係るファームウェア提供システムの制御方法は、複数の電源装置及び各該電源装置に対応する制御装置のファームウェアを提供するサーバを備えるファームウェア提供システムの制御方法である。該ファームウェア提供システムの制御方法は、前記サーバによって、前記制御装置が前記サーバから前記ファームウェアのダウンロードを実行する第１日時を、前記サーバの一斉送信可能なデータ容量を超えないように、各前記制御装置にそれぞれ割り当てる。さらに、前記ファームウェア提供システムの制御方法は、前記サーバによって、前記第１日時を含むスケジュール情報を各前記制御装置に送信する。加えて、前記ファームウェア提供システムの制御方法は、各前記制御装置によって、前記スケジュール情報を前記サーバから取得する。さらに、前記ファームウェア提供システムの制御方法は、各前記制御装置によって、前記第１日時に、前記ファームウェアを前記サーバからダウンロードする。

本発明の一実施形態に係る電源システムは、複数の電源装置及び該複数の電源装置にそれぞれ対応する制御装置にネットワークを介してファームウェアを提供するサーバと、複数の電源装置と、前記複数の電源装置にそれぞれ対応する制御装置とを備える。前記サーバは、各前記制御装置が前記サーバから前記ファームウェアのダウンロードを実行する第１日時を、前記サーバの一斉送信可能なデータ容量を超えないように、前記制御装置にそれぞれ割り当てる。さらに、前記サーバは、前記第１日時を含むスケジュール情報を各前記制御装置に送信する。前記制御装置のそれぞれは、前記ネットワークを介して前記サーバと通信する通信部と、制御部とを備える。前記制御部は、前記スケジュール情報を前記サーバから前記通信部を介して取得する。さらに、前記制御部は、前記第１日時に、前記ファームウェアを前記サーバからダウンロードする。

本発明の一実施形態に係るファームウェア提供システム、ファームウェア提供システムの制御方法及び電源システムによれば、電源装置及びコントローラのファームウェアのダウンロード及び更新を効率よく行うことができる。

本発明の第１の実施形態に係るファームウェア提供システムの概略構成を示す図である。 本発明の第１の実施形態に係るファームウェア提供システムにおいて、スケジュール情報を取得する際の動作の一例を示すシーケンス図である。 本発明の第１の実施形態に係るファームウェア提供システムにおいて、ファームウェアをダウンロードする際の動作の一例を示すシーケンス図である。 本発明の第１の実施形態に係るファームウェア提供システムにおいて、ファームウェアを更新する際の動作の一例を示すシーケンス図である。 本発明の第２の実施形態に係るファームウェア提供システムの概略構成を示す図である。 本発明の第２の実施形態に係るファームウェア提供システムにおいて、ダウンロードの開始時刻及び終了時刻を設定する際の動作の一例を示すシーケンス図である。 サーバによって設定されるコントローラのダウンロードの開始時刻及び終了時刻の一例を示す図である。 本発明の第２の実施形態に係るファームウェア提供システムにおいて、ファームウェアをダウンロードする際の動作の一例を示すシーケンス図である。 ダウンロードが終了した際に、コントローラがそれぞれ保持しているファームウェアの一例を示す図である。 本発明の第２の実施形態に係るファームウェア提供システムにおいて、コントローラの間で、足りないファームウェアを相互で補完しあう際の動作の一例を示すシーケンス図である。

以下、本発明に係る実施形態について、図面を参照して説明する。なお、以下では、特許請求の範囲における「電源装置」を「燃料電池装置」として説明するが、「電源装置」は、当該電源装置と通信可能なコントローラ（制御装置）を備えるものであれば、燃料電池装置以外のものであってもよく、例えば、蓄電装置、太陽光発電装置、ガス発電機等であってもよい。

（第１の実施形態）
図１に、本発明の第１の実施形態に係るファームウェア提供システム１の概略構成を示す。ファームウェア提供システム１は、サーバ１０と、複数の端末装置と、燃料電池装置（電源装置）３０−１〜３０−ｎと、コントローラ（制御装置）４０−１〜４０−ｎとを備える。燃料電池装置３０−１〜３０−ｎ及びコントローラ４０−１〜４０−ｎは、それぞれ、同一又は異なる需要家施設に設置される。また、複数の端末装置は、それぞれ、異なる需要家施設毎に設置される燃料電池装置を利用するユーザが利用する端末装置であり、図１の例では、複数の端末装置のうち、燃料電池装置３０−１を利用するユーザの端末装置２０のみが示されている。

サーバ１０は、ネットワーク１００及びルータ５０−１〜５０−ｎを介して、端末装置２０及びコントローラ４０−１〜４０−ｎと接続される。サーバ１０は、燃料電池装置３０−１〜３０−ｎ及び燃料電池装置３０−１〜３０−ｎにそれぞれ対応するコントローラ４０−１〜４０−ｎに、最新のファームウェアを提供する。なお、燃料電池装置３０−１〜３０−ｎには、それぞれに対応するコントローラ４０−１〜４０−ｎを介して、サーバ１０から最新のファームウェアが提供される。

また、サーバ１０は、燃料電池装置３０−１〜３０−ｎ及びコントローラ４０−１〜４０−ｎのファームウェアの更新に関するスケジュールを管理する。スケジュールには、各コントローラ４０−１〜４０−ｎが、サーバ１０から最新のファームウェアのダウンロードをそれぞれ実行する第１日時Ａ−１〜Ａ−ｎが含まれる。また、スケジュールには、各コントローラ４０−１〜４０−ｎが、ファームウェアの更新をそれぞれ実行する第２日時Ｂ−１〜Ｂ−ｎが含まれる。

スケジュール管理に関し、サーバ１０は、第１日時Ａ−１〜Ａ−ｎを、サーバ１０の一斉送信可能なデータ容量を超えないように、各コントローラ４０−１〜４０−ｎにそれぞれ割り当てる。第１日時Ａ−１〜Ａ−ｎには、各コントローラ４０−１〜４０−ｎがダウンロードを実行する日にちが含まれる。例えば、サーバ１０は、各コントローラ４０−１〜４０−ｎがファームウェアのダウンロードを実行する日にちを分散させることで、サーバ１０の一斉送信可能なデータ容量を超えないようにする。

なお、第１日時Ａ−１〜Ａ―ｎには、各コントローラ４０−１〜４０−ｎがファームウェアのダウンロードを開始する時刻である開始時刻と、各コントローラ４０−１〜４０−ｎがファームウェアのダウンロードを終了する時刻である終了時刻がそれぞれ含まれる。サーバ１０は、例えば、各コントローラ４０−１〜４０−ｎのダウンロードの開始時刻及び終了時刻を、それぞれ、各燃料電池装置３０−１〜３０−ｎの発電電力が比較的少なくなる時間帯に設定してもよい。例えば、夜間の消費電力が昼間の消費電力と比較して小さくなる需要家施設において、燃料電池装置３０−１が負荷追従運転を行っている場合、燃料電池装置３０−１の夜間の発電電力は、燃料電池装置３０−１の昼間の発電電力と比較して小さくなる。従って、この場合、サーバ１０は、コントローラ４０−１がファームウェアのダウンロードの開始時刻及び終了時刻を、夜間の時間帯に設定することができる。なお、サーバ１０は、コントローラ４０−１に対して燃料電池装置３０−１の状態情報を要求することで、コントローラ４０−１から燃料電池装置３０−１の発電電力の情報を取得する。

また、スケジュール管理に関し、サーバ１０は、例えば各燃料電池装置３０−１〜３０−ｎのユーザによって、燃料電池装置３０−１〜３０−ｎ毎に指定される日時に基づき、第２日時Ｂ−１〜Ｂ−ｎをそれぞれ設定する。サーバ１０は、燃料電池装置３０−１〜３０−ｎ毎に指定される日時を、ユーザが利用する端末装置からネットワーク１００を介して取得する。例えば、サーバ１０は、燃料電池装置３０−１のユーザが指定する日時を、端末装置２０からネットワーク１００を介して取得する。

また、サーバ１０は、スケジュール情報の要求を、コントローラ４０−１〜４０−ｎから、ルータ５０−１〜５０−ｎ及びネットワーク１００を介して、それぞれ取得する。サーバ１０は、スケジュール情報の要求を送信したコントローラに対し、スケジュール情報を送信する。スケジュール情報には、例えば、そのスケジュール情報が送信されるコントローラに割り当てられた第１日時と、そのコントローラがファームウェアを更新する日時として設定した第２日時と、そのコントローラ等のファームウェアのバージョン情報等が含まれる。例えば、サーバ１０からコントローラ４０−１へ送信されるスケジュール情報には、第１日時Ａ−１と、第２日時Ｂ−１と、コントローラ４０−１及び燃料電池装置３０−１のファームウェアのバージョン情報等が含まれる。

端末装置２０は、燃料電池装置３０−１を利用するユーザが使用する端末である。端末装置２０は、ネットワーク１００を介して、サーバ１０と接続される。ユーザは、端末装置２０を用いて、燃料電池装置３０−１等のファームウェアの更新処理を実行可能な日時を指定し、サーバ１０に送信する。

ここで、燃料電池装置３０−１のファームウェアの更新処理中は、燃料電池装置３０−１の運転を停止させる必要がある。さらに、燃料電池装置３０−１は、運転を停止させる際、例えば１２時間程度の、長い時間を要する場合がある。これは、燃料電池装置３０−１では、動作温度が高温であり、運転を停止させる際に、十分な時間をかけて発電セルの冷却を行わないと、熱ストレスによって、発電セルに劣化が生じるおそれがあるためである。従って、燃料電池装置３０−１のファームウェアの更新処理自体が数分程度で完了する場合であっても、燃料電池装置３０−１の運転を停止させる必要があるために、結果として、燃料電池装置３０−１のファームウェアの更新処理は、長い時間を要する。この間、燃料電池装置３０−１が設置される需要家施設では、燃料電池装置３０−１からの電力供給を受けることができない。そこで、本実施形態では、ユーザが、燃料電池装置３０−１の運転を停止させても支障がない日時すなわち燃料電池装置３０−１のファームウェアの更新処理を実行可能な日時を予め指定し、端末装置２０を用いて、サーバ１０に送信する。例えば、需要家施設が店舗である場合、ユーザは、店舗の休業日を、燃料電池装置３０−１のファームウェアの更新処理を実行可能な日時として指定する。

次に、燃料電池装置３０−１〜３０−ｎ及びコントローラ４０−１〜４０−ｎについて、燃料電池装置３０−１及びコントローラ４０−１を例に説明する。なお、以後、燃料電池装置３０−１を「燃料電池装置３０」と表記し、コントローラ４０−１を「コントローラ４０」と表記する。また、ルータ５０−１を「ルータ５０」と表記する。また、以後、第１日時Ａ−１を単に「第１日時」と表記し、「第２日時Ｂ−１」を単に「第２日時」と表記する。

燃料電池装置３０は、例えば、固体酸化物形燃料電池装置（ＳＯＦＣ：Ｓｏｌｉｄ Ｏｘｉｄｅ Ｆｕｅｌ Ｃｅｌｌ）又は固体高分子形燃料電池装置（ＰＥＦＣ：Ｐｏｌｙｍｅｒ Ｅｌｅｃｔｒｏｌｙｔｅ Ｆｕｅｌ Ｃｅｌｌ）等である。燃料電池装置３０は、店舗等の需要家施設に設置される。燃料電池装置３０は、発電部３１と、電力変換部３２と、通信部３３と、記憶部３４と、制御部３５とを備える。

発電部３１は、燃料（例えば、所定割合で配合されたガス、空気及び改質水）の電気化学反応によって発電する。発電部３１は、発電した直流電力を、電力変換部３２に供給する。

電力変換部３２は、発電部３１から供給される直流電力を、交流電力に変換する。電力変換部３２は、変換後の交流電力を、燃料電池装置３０が設置される需要家施設の負荷機器等に供給する。

通信部３３は、例えばケーブル等を介して、コントローラ４０と通信する。

記憶部３４は、燃料電池装置３０の各機能を実現させるためのファームウェアを保持（格納）する。記憶部３４に保持されているファームウェアは、ファームウェアのバージョンがアップに伴い、最新のものに更新される。

制御部３５は、燃料電池装置３０全体を制御及び管理するプロセッサ等である。制御部３５は、例えば、電力変換部３２を制御する。

また、制御部３５は、コントローラ４０の指示に基づき、燃料電池装置３０のファームウェアの更新処理を実行する。この処理の詳細については、下記の＜ファームウェアを更新する際の処理＞において説明する。

コントローラ４０は、燃料電池装置３０の運転を制御するものである。コントローラ４０は、ルータ５０及びネットワーク１００を介してサーバ１０と接続される。また、コントローラ４０は、例えばケーブル等を介して、燃料電池装置３０と接続される。

ここで、コントローラ４０は、ルータ５０と接続されているため、ネットワーク１００を介してサーバ１０に接続することができる（そのため、コントローラ４０には、ネットワーク１００に接続するためのＩＰアドレスが割り当てられている。）。これに対し、燃料電池装置３０は、ルータ５０と接続されていないため、ネットワーク１００に接続することができない（そのため、燃料電池装置３０にはＩＰアドレスが割り当てられていない。）。そのため、本実施形態では、コントローラ４０が、コントローラ４０自身のファームウェアと、燃料電池装置３０のファームウェアとを、サーバ１０からダウンロードする。

コントローラ４０は、通信部４１と、記憶部４２と、表示部４３と、制御部４４とを備える。

通信部４１は、ルータ５０及びネットワーク１００を介してサーバ１０と通信する。また、通信部４１は、例えばケーブル等を介して、燃料電池装置３０と通信する。

記憶部４２は、コントローラ４０の各機能を実現させるためのファームウェアを保持する。記憶部４２に保持されているファームウェアは、ファームウェアのバージョンがアップに伴い、最新のものに更新される。

表示部４３は、スケジュール情報等を表示する。表示部４３は、例えばタッチセンサ等を有して構成される。

制御部４４は、コントローラ４０全体を制御及び管理するプロセッサ等である。制御部４４は、サーバ１０からスケジュール情報に基づき、コントローラ４０及び燃料電池装置３０のファームウェアのダウンロード及び更新を行う。これらの処理については、下記の＜スケジュール情報を取得する際の処理＞、＜ファームウェアをダウンロードする際の処理＞及び＜ファームウェアを更新する際の処理＞において説明する。

＜スケジュール情報を取得する際の処理＞
以下、サーバ１０からスケジュール情報を取得する際の制御部４４の処理について、図２を用いて説明する。なお、ファームウェア提供システム１では、図２に示すステップＳ１０１〜Ｓ１０７の処理が定期的に（例えば、１日１回程度）行う。

コントローラ４０の制御部４４は、サーバ１０に対して、スケジュール情報の要求を、通信部４１からルータ５０及びネットワーク１００を介して送信する（ステップＳ１０１）。サーバ１０は、コントローラ４０からスケジュール情報の要求を取得すると、コントローラ４０にスケジュール情報を送信する（ステップＳ１０２）。

なお、スケジュール情報は、ファームウェアと比較すると、データ容量が小さい。そのため、複数のコントローラがサーバからスケジュール情報を同一タイミングでダウンロードしても、サーバ１０への負荷が増してサーバ１０がダウンするといった事態が起きにくい。従って、コントローラ４０は、任意のタイミングで、スケジュール情報をサーバ１０から取得することができる。

コントローラ４０の制御部４４は、サーバ１０からネットワーク１００及びルータ５０を介して送信されたスケジュール情報を、通信部４１を介し取得すると、取得したスケジュール情報を解析する（ステップＳ１０３）。

制御部４４は、解析したスケジュール情報に基づき、燃料電池装置３０及びコントローラ４０のファームウェアの少なくとも１つの更新があるか否か判定する（ステップＳ１０４）。制御部４４は、例えば、今回のステップＳ１０３の処理で解析したスケジュール情報と、前回のステップＳ１０３の処理で解析したスケジュール情報とを比較して、スケジュール情報に変更があるか否か判定する。

制御部４４は、燃料電池装置３０及びコントローラ４０のファームウェアの少なくとも１つの更新があると判定したとき（ステップＳ１０４：Ｙｅｓ）、ステップＳ１０５の処理に進む。一方、制御部４４は、燃料電池装置３０及びコントローラ４０の全てのファームウェアの更新がないと判定したとき（ステップＳ１０４：Ｎｏ）、処理を終了する。

ステップＳ１０５の処理では、制御部４４は、ステップＳ１０３の処理で解析したスケジュール情報に変更があるか否か判定する。制御部４４は、例えば、今回のステップＳ１０３の処理で解析したスケジュール情報と、前回のステップＳ１０３の処理で解析したスケジュール情報とを比較して、スケジュール情報に変更があるか否か判定する。

このようにステップＳ１０１〜Ｓ１０５の処理を定期的に行うことで、スケジュールを管理しているサーバ１０側でスケジュール情報が変更されても、コントローラ４０側でスケジュール情報の変更を速やかに把握することができる。

制御部４４は、スケジュール情報に変更がないと判定したとき（ステップＳ１０５：Ｎｏ）、ステップＳ１０６の処理に進む。一方、制御部４４は、スケジュール情報に変更があると判定したとき（ステップＳ１０５：Ｙｅｓ）、ステップＳ１０７の処理に進む。

ステップＳ１０６の処理では、制御部４４は、スケジュール情報を、表示部４３に表示させ、ユーザに提示する。制御部４４は、例えば、「××××年××月××日にアップデートが始まります。更新後のコントローラのバージョンは○○です。また、更新後の燃料電池装置のバージョンは△△です。」と表示部４３に表示させる。

ステップＳ１０７の処理では、制御部４４は、変更後のスケジュール情報を、表示部４３に表示させ、ユーザに提示する。

このようにステップＳ１０１〜Ｓ１０７の処理を定期的に行うことで、スケジュール情報が、更新を開始するまで定期的に（例えば、毎日）、表示部４３を介してユーザに提示される。これにより、表示部４３をこまめに見るという習慣がユーザになくても、更新を開始するまでに、ユーザが表示部４３を視認する可能性が高くなる。そのため、ユーザにおいて、知らない間にファームウェアが更新されていたという事態を防ぐことができる。

なお、ステップＳ１０６，Ｓ１０７の処理において、制御部４４は、ユーザがファームウェアの更新を承認するか否かを問う内容の表示を、表示部４３に表示させてもよい。この場合、制御部４４は、例えばコントローラ４０の入力部等を介して、ユーザからファームウェアの更新を承認する旨の回答を得られたときに、後述の図３及び図４に示すステップＳ２０１以降の処理を実行するようにしてもよい。

＜ファームウェアをダウンロードする際の処理＞
次に、ファームウェアをダウンロードする際の制御部４４の処理について、図３を用いて説明する。

コントローラ４０の制御部４４は、ファームウェアのダウンロードを実行する第１日時になると、最新のファームウェアの要求を通信部４１から、ルータ５０及びネットワーク１００を介してサーバ１０に送信する（ステップＳ２０１）。サーバ１０は、コントローラ４０から最新のファームウェアの要求を取得すると、最新のファームウェアを、ネットワーク１００及びルータ５０を介してコントローラ４０に送信する（ステップＳ２０２）。

コントローラ４０の制御部４４は、最新のファームウェアを、サーバ１０からネットワーク１００及びルータ５０を介して、通信部４１から取得する。すると、制御部４４は、ファームウェアの更新を実行する第２日時になるまで、取得した最新のファームウェアを記憶部４２に保持させておく（ステップＳ２０３）。

このようなステップＳ２０１〜Ｓ２０３の処理によって、本実施形態では、サーバ１０によって予め設定された第１日時に、コントローラ４０は、サーバ１０からファームウェアをダウンロードする。さらに、本実施形態では、サーバ１０によって、サーバ１０の一斉送信可能なデータ容量を超えないように、各コントローラにそれぞれ第１日時が割り当てられている。これにより、本実施形態では、複数のコントローラがサーバ１０から同時にファームウェアをダウンロードしようとすることで、サーバ１０への負荷が大きくなり、サーバ１０がダウンしてしまうといった事態を防ぐことができる。

ここで、本実施形態では、コントローラ４０が、コントローラ４０自身のファームウェアと、燃料電池装置３０のファームウェアとを、サーバ１０からまとめてダウンロードする。これにより、本実施形態では、通信トラフィックを低減させることができる。さらに、本実施形態では、燃料電池装置３０をネットワーク１００に直接接続させないことで、セキュリティを向上させることができる。

＜ファームウェアを更新する際の処理＞
次に、ファームウェアを更新する際の燃料電池装置３０及びコントローラ４０の処理について、図４を用いて説明する。なお、以下では、燃料電池装置３０及びコントローラ４０の両方のファームウェアを更新するものとする。

コントローラ４０の制御部４４は、ファームウェアの更新を実行する第２日時になると、ファームウェアの更新を開始する旨を、表示部４３に表示させ、ユーザに提示する（ステップＳ３０１）。制御部４４は、例えば、「ファームウェアのアップデートを開始します。更新後のコントローラのバージョンは○○です。また、更新後の燃料電池装置のバージョンは△△です。」と表示部４３に表示させる。

次に、制御部４４は、コントローラ４０のファームウェアの更新処理を実行する（ステップＳ３０２）。このとき、制御部４４は、ステップＳ３０１の処理で表示部４３に表示されているファームウェアの更新を開始する旨の表示を、ファームウェアの更新中である旨の表示に切り替えてもよい。この場合、制御部４４は、例えば、「ファームウェアのアップデート中です。」といった内容の表示に切り替える。

コントローラ４０の制御部４４は、コントローラ４０のファームウェアの更新処理が完了すると、燃料電池装置３０に対して、運転停止の要求を、通信部４１を介して送信する（ステップＳ３０３）。燃料電池装置３０では、制御部３５が、運転停止の要求をコントローラ４０から通信部３３を介して取得すると、燃料電池装置の運転停止処理を実行する（ステップＳ３０４）。制御部３５は、燃料電池装置３０の運転停止処理が完了すると、コントローラ４０に対して、燃料電池装置３０の運転停止処理が完了した旨を、通信部３３を介して通知する（ステップＳ３０５）。

コントローラ４０の制御部４４は、燃料電池装置３０の運転停止処理が完了した旨を燃料電池装置３０から通信部４１を介して取得すると、燃料電池装置３０に対して、燃料電池装置３０の最新のファームウェアを、通信部４１を介して送信する（ステップＳ３０６）。

燃料電池装置３０では、制御部３５が、最新のファームウェアを、コントローラ４０から通信部３３を介して取得すると、燃料電池装置３０の更新処理を実行する（ステップＳ３０７）。制御部３５は、燃料電池装置３０のファームウェアの更新処理が完了すると、コントローラ４０に対して、更新処理が完了した旨を、通信部３３を介して送信する（ステップＳ３０８）。

コントローラ４０の制御部４４は、燃料電池装置３０の更新処理が完了した旨を、燃料電池装置３０から通信部４１を介して取得すると、更新処理が完了した旨を、表示部４３に表示させ、ユーザに提示する（ステップＳ３０９）。制御部４４は、例えば、「アップデートが完了しました。」と表示部４３に表示させる。

なお、ステップＳ３０１の処理において、制御部４４は、ファームウェアの更新を開始する旨の代わりに、ユーザがファームウェアの更新の開始を承認するか否かを問う内容の表示を、表示部４３に表示させてもよい。この場合、制御部４４は、表示部４３のタッチセンサ等を介して、ユーザからファームウェアの更新の開始を承認する旨の回答が得られたときに、ステップＳ３０２以降の処理を実行するようにしてもよい。

また、燃料電池装置３０のファームウェアのみを更新する場合は、ステップＳ３０２の処理は行わなくてもよい。また、コントローラ４０のファームウェアのみを更新する場合は、ステップＳ３０３〜Ｓ３０８の処理を行わなくてもよい。

また、ステップＳ３０１〜Ｓ３０９の処理では、燃料電池装置３０のファームウェアの更新よりも、コントローラ４０のファームウェアの更新を先に実行しているが、コントローラ４０のファームウェアの更新を先に実行してもよい。

以上のように、本実施形態では、サーバ１０によって予め設定された第１日時に、コントローラ４０は、サーバ１０からファームウェアをダウンロードする。さらに、本実施形態では、サーバ１０によって、サーバ１０の一斉送信可能なデータ容量を超えないように、各コントローラにそれぞれ第１日時が割り当てられている。これにより、本実施形態では、複数のコントローラがサーバ１０から同時にファームウェアをダウンロードしようとすることで、サーバ１０への負荷が大きくなり、サーバ１０がダウンしてしまうといった事態を防ぐことができる。従って、本実施形態では、燃料電池装置３０及びコントローラ４０のファームウェアのダウンロード及び更新を効率よく行うことができる。さらに、本実施形態では、管理専用の他のサーバ等を設けることなく、ファームウェアを提供するサーバ１０が各コントローラにそれぞれ第１日時を割り当てることで、サーバ１０への負荷の増大を防いでいる。従って、コストを増加させることなく、本実施形態に係る処理を実現することができる。

さらに、本実施形態では、コントローラ４０は、サーバ１０によって設定されたスケジュールに沿って、燃料電池装置３０及びコントローラ４０のファームウェアのダウンロード及び更新を行っている。言い換えれば、コントローラ４０でファームウェアのスケジュールを設定しなくてもよい。そのため、コントローラ４０に、スケジュール設定のための高度な機能を追加することなく、本実施形態に係る処理を実現することができる。従って、低コストで、本実施形態に係る処理を実現することができる。

また、本実施形態では、コントローラ４０によって、設定されたスケジュールに沿って、自動的に、燃料電池装置３０の運転が停止され、燃料電池装置３０のファームウェアの更新が行われる。従って、本実施形態では、燃料電池装置３０のファームウェアを更新するために、メンテナンス人員を需要家施設に派遣しなくてもよい。これにより、本実施形態では、燃料電池装置３０及びコントローラ４０のファームウェアのダウンロード及び更新を、さらに効率よく行うことができる。

（第２の実施形態）
次に、第２の実施形態について説明する。第１の実施形態では、同一又は異なる需要家施設毎にそれぞれ設置される複数の燃料電池装置及び複数のコントローラにおいて、ファームウェアのダウンロード及び更新を効率よく行う方法について説明した。第２の実施形態では、同一需要家施設に設置され、親装置又は子装置に設定される複数の燃料電池装置、及び、親機又は子機に設定される複数のコントローラにおいて、ファームウェアのダウンロード及び更新を効率よく行う方法について説明する。以下では、第１の実施形態と異なる点について主に説明する。なお、第１の実施形態に係る構成要素と同一の構成要素には、同一符号を付し、その説明を省略する。

図５に、本発明の第２の実施形態に係るファームウェア提供システム２の概略構成を示す。ファームウェア提供システム２は、サーバ１０と、端末装置２０と、燃料電池装置３０Ａ，３０Ｂ，３０Ｃと、コントローラ４０Ａ，４０Ｂ，４０Ｃと、ルータ５０Ａ，５０Ｂ，５０Ｃとを備える。燃料電池装置３０Ａ〜３０Ｃは、同一需要家施設に設置され、連結運転を行うものである。連結運転を行う複数の燃料電池装置では、そのうち１つが親装置に設定され、その他が子装置に設定される。本実施形態では、燃料電池装置３０Ａが親装置に設定され、燃料電池装置３０Ｂ，３０Ｃが子装置に設定されているものとする。さらに、コントローラ４０Ａ〜４０Ｃにおいて、親装置である燃料電池装置３０Ａに対応するコントローラ４０Ａが親機に設定され、燃料電池装置３０Ｂ，３０Ｃにそれぞれ対応するコントローラ４０Ｂ，４０Ｃが子機に設定されているものとする。

なお、図５では、３つの燃料電池装置３０Ａ〜３０Ｃと３つのコントローラ４０Ａ〜４０Ｃとを備えるファームウェア提供システム２が示されているが、燃料電池装置及びコントローラの数は、これに限定されず、２つであってもよいし、４つ以上であってもよい。

サーバ１０は、コントローラ４０Ａに対し、燃料電池装置３０Ａの状態情報の要求を、ネットワーク１００を介して送信する。サーバ１０は、この要求に対する応答として、コントローラ４０Ａから、燃料電池装置３０Ａの状態情報を、ネットワーク１００を介して取得する。燃料電池装置３０Ａの状態情報には、例えば、燃料電池装置３０Ａの発電電力の値、連結運転を行っている旨等が含まれる。なお、サーバ１０は、コントローラ４０Ａに対して、燃料電池装置３０Ａの状態情報の要求を、例えば数秒間隔で定期的に行う。また、サーバ１０は、同様にして、コントローラ４０Ｂ，４０Ｃのそれぞれから、燃料電池装置３０Ｂ，３０Ｃの状態情報をそれぞれ取得する。

また、サーバ１０は、燃料電池装置３０Ａ〜３０Ｃの状態情報に基づき、コントローラ４０Ａ〜４０Ｃのそれぞれにおいて、第１日時に含まれるファームウェアのダウンロードの開始時刻及び終了時刻を設定する。この処理の詳細については、下記の＜開始時刻及び設定時刻を設定する際の処理＞において説明する。

親装置である燃料電池装置３０Ａは、親機であるコントローラ４０Ａの制御の下、発電等を行う。親装置である燃料電池装置３０Ａは、例えば、連結運転を行う燃料電池装置３０Ａ〜３０Ｃにおいて、ベース電源として運転する。燃料電池装置３０Ａは、発電部３１Ａと、電力変換部３２Ａと、通信部３３Ａと、記憶部３４Ａと、制御部３５Ａとを備える。発電部３１Ａ、電力変換部３２Ａ、通信部３３Ａ、記憶部３４Ａ及び制御部３５Ａは、それぞれ、図１に示す発電部３１、電力変換部３２、通信部３３、記憶部３４及び制御部３５と同様の機能を実現することができる。

子装置である燃料電池装置３０Ｂは、子機であるコントローラ４０Ｂの制御の下、発電等を行う。また、子装置である燃料電池装置３０Ｃは、子機であるコントローラ４０Ｃの制御の下、発電等を行う。子機である燃料電池装置３０Ｂ，３０Ｃは、例えば、負荷追従運転を行う。燃料電池装置３０Ｂは、発電部３１Ｂと、電力変換部３２Ｂと、通信部３３Ｂと、記憶部３４Ｂと、制御部３５Ｂとを備える。発電部３１Ｂ、電力変換部３２Ｂ、通信部３３Ｂ、記憶部３４Ｂ及び制御部３５Ｂは、それぞれ、図１に示す発電部３１、電力変換部３２、通信部３３、記憶部３４及び制御部３５と同様の機能を実現することができる。また、燃料電池装置３０Ｃは、発電部３１Ｃと、電力変換部３２Ｃと、通信部３３Ｃと、記憶部３４Ｃと、制御部３５Ｃとを備える。発電部３１Ｃ、電力変換部３２Ｃ、通信部３３Ｃ、記憶部３４Ｃ及び制御部３５Ｃは、それぞれ、図１に示す発電部３１、電力変換部３２、通信部３３、記憶部３４及び制御部３５と同様の機能を実現することができる。

親機であるコントローラ４０Ａは、自機器に対応する燃料電池装置３０Ａの運転を制御する。また、コントローラ４０Ａは、子機であるコントローラ４０Ｂ，４０Ｃを制御する。コントローラ４０Ａは、通信部４１Ａと、記憶部４２Ａと、表示部４３Ａと、制御部４４Ａとを備える。通信部４１Ａ、記憶部４２Ａ、表示部４３Ａ及び制御部４４Ａは、それぞれ、図１に示す通信部４１、記憶部４２、表示部４３及び制御部４４と同様の機能を実現することができる。以下では、異なる点を主に説明する。

通信部４１Ａは、ルータ５０Ａ及びネットワーク１００を介して、サーバ１０と通信する。また、通信部４１Ａは、ルータ５０Ａ，５０Ｂを介してコントローラ４０Ｂと数新し、ルータ５０Ａ，５０Ｃを介してコントローラ５０Ｃと通信する。

制御部４４Ａは、サーバ１０からネットワーク１００及びルータ５０Ａを介して送信される燃料電池装置３０Ａの状態情報の要求を、通信部４１Ａを介し取得する。すると、制御部４４Ａは、燃料電池装置３０Ａの状態情報を、通信部４１Ａからネットワーク１００及びルータ５０Ａを介して、サーバ１０に送信する。

また、制御部４４Ａは、サーバ１０からスケジュール情報を取得すると、取得したスケジュール情報を解析して、自機器のダウンロードの開始時刻及び終了時刻を検出する。さらに、制御部４４Ａは、子機であるコントローラ４０Ｂ，４０Ｃから、コントローラ４０Ｂ，４０Ｃのダウンロードの開始時刻及び終了時刻を、ルータ５０Ａ等を介して、通信部４１から取得する。

また、制御部４４Ａは、自機器のダウンロードの開始時刻になると、ファームウェアを所定順序でサーバ１０からネットワーク１００、ルータ５０Ａ及び通信部４１Ａを介してダウンロードする。所定順序については後述する。

また、制御部４４Ａは、自機器でダウンロードが完了したファームウェアと、ダウンロードの実行処理を終了した子機から通知される子機でダウンロードが完了したファームウェアとに基づき、ダウンロードが未完了であるファームウェアを検出する。さらに、制御部４４Ａは、予めコントローラ４０Ｂ，４０Ｃから取得したコントローラ４０Ｂ，４０Ｃのダウンロードの開始時刻等に基づき、次にダウンロードを実行する子機を検出する。制御部４４は、次にダウンロードを実行する子機に、検出したダウンロードが未完了であるファームウェアをダウンロードするよう、ルータ５０等を介して指示する。この処理の詳細は、下記の＜ファームウェアをダウンロードする際の処理＞において説明する。

また、制御部４４Ａ、コントローラ４０Ａ〜４０Ｃの全てがダウンロード実行処理を終了すると、自機器で保持していないファームウェアを保持している子機を検出する。制御部４４は、自機器でダウンロードが完了したファームウェアと、子機から通知される子機でダウンロードが完了したファームウェアとに基づき、親機が保持していないファームウェアを保持している子機を検出する。制御部４４は、検出した子機に対し、親機が保持していないファームウェアを送信するよう、ルータ５０Ａ等を介して要求する。また、制御部４４Ａは、子機であるコントローラ４０Ｂ，４０Ｃから通知される子機でダウンロードが完了したファームウェアに基づき、子機であるコントローラが保持していないファームウェアを検出する。さらに、制御部４４は、その検出したファームウェアを、その検出したファームウェアを保持していない子機であるコントローラに、ルータ５０Ａ等を介して送信する。この処理の詳細は、下記の＜ファームウェアを補完する際の処理＞において説明する。

子機であるコントローラ４０Ｂは、親機であるコントローラ４０Ａの制御の下、自機器に対応する燃料電池装置３０Ｂの運転を制御する。コントローラ４０Ｂは、通信部４１Ｂと、記憶部４２Ｂと、表示部４３Ｂと、制御部４４Ｂとを備える。通信部４１Ｂ、記憶部４２Ｂ、表示部４３Ｂ及び制御部４４Ｂは、それぞれ、図１に示す通信部４１、記憶部４２、表示部４３及び制御部４４と同様の機能を実現することができる。以下では、異なる点を主に説明する。

通信部４１Ｂは、ルータ５０Ｂ及びネットワーク１００を介して、サーバ１０と通信する。また、通信部４１Ｂは、ルータ５０Ｂ，５０Ａを介してコントローラ４０Ａと通信し、ルータ５０Ｂ，５０Ｃを介してコントローラ５０Ｃと通信する。

制御部４４Ｂは、サーバ１０からスケジュール情報を取得すると、取得したスケジュール情報を解析して、自機器のダウンロードの開始時刻及び終了時刻を検出する。さらに、制御部４４Ｂは、コントローラ４０Ｂのダウンロードの開始時刻及び終了時刻を、通信部４１Ｂからルータ５０Ｂ，５０Ａを介して、親機であるコントローラ４０Ａに通知する。

また、制御部４４Ｂは、親機であるコントローラ４０Ａからルータ５０Ａ，５０Ｂを介して、親機によって検出されたダウンロードが未完了であるファームウェアをダウンロードするよう指示を受ける。この場合、制御部４４Ｂは、自機器のダウンロードの開始時刻になると、そのダウンロードが未完了であるファームウェアを、所定順序でサーバ１０から通信部４１Ｂを介してダウンロードする。さらに、制御部４４Ｂは、自機器のダウンロード実行処理が終了すると、自機器でダウンロードが完了したファームウェアを、ルータ５０Ｂ，５０Ａを介して、親機であるコントローラ４０Ａに通知する。この処理の詳細は、＜ファームウェアをダウンロードする際の処理＞において説明する。

また、制御部４４Ｂは、親機であるコントローラ４０Ａから、親機が保持していないファームウェアを送信するよう要求を受けると、そのファームウェアを、通信部４１Ｂからルータ５０Ｂ，５０Ａを介してコントローラ４０Ａに送信する。また、制御部４４Ｂは、親機であるコントローラ４０Ａからファームウェアを取得すると、そのファームウェアを、記憶部４２Ｂに保持させる。この処理の詳細は、下記の＜ファームウェアを補完する際の処理＞において説明する。

子機であるコントローラ４０Ｃは、親機であるコントローラ４０Ａの制御の下、自機器に対応する燃料電池装置３０Ｃの運転を制御する。コントローラ４０Ｃは、通信部４１Ｃと、記憶部４２Ｃと、表示部４３Ｃと、制御部４４Ｃとを備える。通信部４１Ｃ、記憶部４２Ｃ、表示部４３Ｃ及び制御部４４Ｃは、それぞれ、図１に示す通信部４１、記憶部４２、表示部４３及び制御部４４と同様の機能を実現することができる。以下では、異なる点を主に説明する。

通信部４１Ｃは、ルータ５０Ｃ及びネットワーク１００を介して、サーバ１０と通信する。また、通信部４１Ｃは、ルータ５０Ｃ，５０Ａを介してコントローラ４０Ａと通信し、ルータ５０Ｃ，５０Ｂを介してコントローラ５０Ｂと通信する。

制御部４４Ｃの処理は、制御部４４Ｂの処理と同様であるため、説明を省略する。

＜開始時刻及び設定時刻を設定する際の処理＞
以下、コントローラ４０Ａ〜４０Ｃのダウンロードの開始時刻及び終了時刻を設定する際のサーバ１０の処理の一例について、図６を用いて説明する。

まず、サーバ１０は、同一需要家施設に設置される複数の燃料電池装置が、連結運転を行っているか否か判定する（ステップＳ４０１）。サーバ１０は、例えば、コントローラ４０Ａから取得する状態情報に連結運転を行っている旨が含まれる場合、燃料電池装置３０Ａ〜３０Ｃが連結運転を行っていると判定する。

サーバ１０は、同一需要家施設に設置される複数の燃料電池装置が連結運転を行っていると判定したとき、（ステップＳ４０１：Ｙｅｓ）、ステップＳ４０２の処理に進む。一方、サーバ１０は、同一需要家施設に設置される複数の燃料電池装置が連結運転を行っていないと判定したとき（ステップＳ４０１：Ｎｏ）、処理を終了する。

ステップＳ４０２の処理では、サーバ１０は、各コントローラ４０Ａ〜４０Ｃがそれぞれダウンロードを行う時間（以下、「ダウンロード時間」という）を算出する。サーバ１０は、ファームウェアの全容量と、コントローラ及びサーバ１０間の通信速度と、コントローラの数とに基づき、ダウンロード時間を算出する。例えば、サーバ１０は、ファームウェアの全容量と、コントローラ及びサーバ１０間の通信速度とに基づき、１つのコントローラのみで全ファームウェアをダウンロードした場合に掛かる時間（以下「第１時間」と表記する）を算出する。さらに、サーバ１０は、第１時間を、コントローラの数で除算することで、ダウンロード時間を算出する。例えば、第１時間が３０分間であり、コントローラの数が３つである場合、ダウンロード時間は、１０分間と算出される。

ステップＳ４０３の処理では、サーバ１０は、連結運転を行っている複数の燃料電池装置の発電電力の全てが、時刻に対して変動しているか否か判定する。サーバ１０は、例えば、コントローラ４０Ａ〜４０Ｃからそれぞれ取得する燃料電池装置３０Ａ〜３０Ｃの状態情報を参照し、燃料電池装置３０Ａ〜３０Ｃの発電電力の全てが時刻に対して変動しているか否か判定する。ここで、燃料電池装置３０Ａ〜３０Ｃの全てが負荷追従運転を行っている場合、燃料電池装置３０Ａ〜３０Ｃの発電電力の全てが時刻に対して変動する。一方、燃料電池装置３０Ａ〜３０Ｃの何れか１つがベース電源として運転している場合、ベース電源として運転している燃料電池装置の発電電力は時刻に対して一定となるため、燃料電池装置３０Ａ〜３０Ｃの発電電力の何れか１つは時刻に対して変動しない。従って、燃料電池装置３０Ａ〜３０Ｃの全てが負荷追従運転を行っている場合、サーバ１０は、燃料電池装置３０Ａ〜３０Ｃの発電電力の全てが時刻に対して変動していると判定する。一方、燃料電池装置３０Ａ〜３０Ｃの何れか１つがベース電源として運転している場合、サーバ１０は、燃料電池装置３０Ａ〜３０Ｃの発電電力の全てが時刻に対して変動していると判定しない。

サーバ１０は、連結運転を行っている複数の燃料電池装置の発電電力の全てが時刻に対して変動していると判定したとき（ステップＳ４０３：Ｙｅｓ）、ステップＳ４０４の処理に進む。一方、サーバ１０は、連結運転を行っている複数の燃料電池装置の発電電力の全てが時刻に対して変動していると判定しないとき（ステップＳ４０３：Ｎｏ）、ステップＳ４０６の処理に進む。従って、燃料電池装置の全てが負荷追従運転を行っている場合、サーバ１０は、ステップＳ４０４，Ｓ４０５の処理に進む。一方、連結運転を行っている複数の燃料電池装置にベース電源として運転を行っている燃料電池装置が含まれる場合、サーバ１０は、ステップＳ４０６，Ｓ４０７，Ｓ４０８に進む。

ステップＳ４０４の処理では、サーバ１０は、発電電力が時刻に対して変動する燃料電池装置すなわち負荷追従運転を行っている燃料電池装置のそれぞれにおいて、発電電力が第１所定値よりも小さくなる時間帯を抽出する。例えば、夜間の消費電力が昼間の消費電力と比較して小さくなる需要家施設において、燃料電池装置が負荷追従運転を行っている場合、その燃料電池装置の夜間の発電電力は、その燃料電池装置の昼間の発電電力と比較して小さくなる。そのため、この場合には、ステップＳ４０４の処理によって夜間の時間帯が抽出される。

ステップＳ４０５の処理では、サーバ１０は、ステップＳ４０２の処理で算出したダウンロード時間と、ステップＳ４０４の処理で抽出した時間帯とに基づき、コントローラ４０Ａ〜４０Ｃのダウンロードの開始時刻及び終了時刻をそれぞれ設定する。以下、この処理の一例として、コントローラ４０Ａのダウンロードの開始時刻及び終了時刻を設定する例を説明する。

例えば、サーバ１０は、ステップＳ４０２の処理でダウンロード時間を１０分間と算出し、ステップＳ４０４の処理で燃料電池装置３０Ａの発電電力が第１所定値よりも小さくなる時間帯として夜間の時間帯を抽出しているものとする。この場合、サーバ１０は、ステップＳ４０４の処理で抽出した夜間の時間帯において、開始時刻と終了時刻との間の時間が１０分間となるように、コントローラ４０Ａのダウンロードの開始時刻及び終了時刻を設定する。

このようなステップＳ４０４，Ｓ４０５の処理によって、燃料電池装置の全てが負荷追従運転を行っている場合、燃料電池装置の発電電力が小さくなる時間帯に、全コントローラのダウンロードの開始時刻及び終了時刻が設定される。一般的に、燃料電池装置の発電電力が大きくなると、燃料電池装置を制御するコントローラの処理量は増加し、燃料電池装置の発電電力が小さくなると、燃料電池装置を制御するコントローラの処理量は低減する。従って、本実施形態では、コントローラの処理量が比較的低減される時間帯に、ダウンロードの開始時刻及び終了時刻を設定することで、ファームウェアのダウンロードを効率よく行うことができる。

ステップＳ４０６の処理では、サーバ１０は、ステップＳ４０４の処理と同様にして、発電電力が時刻に対して変動する燃料電池装置すなわち負荷追従運転を行っている燃料電池装置において、発電電力が第１所定値よりも小さくなる時間帯を抽出する。

ステップＳ４０７の処理では、発電電力が時刻に対して変動する燃料電池装置すなわち負荷追従運転を行っている燃料電池装置の全てにおいて、発電電力が第２所定値よりも大きくなる時間帯を抽出する。例えば、昼間の消費電力が夜間の消費電力と比較して大きくなる需要家施設において、燃料電池装置が負荷追従運転を行っている場合、その燃料電池装置の昼間の発電電力は、その燃料電池装置の夜間の発電電力と比較して大きくなる。そのため、この場合には、ステップＳ４０７の処理によって昼間の時間帯が抽出される。

ステップＳ４０８の処理では、サーバ１０は、ステップＳ４０２の処理で算出したダウンロード時間と、ステップＳ４０６，Ｓ４０７の処理で算出した時間帯とに基づき、コントローラ４０Ａ〜４０Ｃのダウンロードの開始時刻及び終了時刻をそれぞれ設定する。以下、この処理の一例を説明する。以下では、燃料電池装置３０Ａがベース電源として運転を行い、燃料電池装置３０Ｂ，３０Ｃが負荷追従運転を行っているものとする。

まず、コントローラ４０Ｂ，４０Ｃのダウンロードの開始時刻及び終了時刻を設定する例について説明する。例えば、サーバ１０は、ステップＳ４０２の処理でダウンロード時間を１０分間と算出し、ステップＳ４０６の処理で燃料電池装置３０Ｂ，３０Ｃの発電電力が第１所定値よりも小さくなる時間帯として夜間の時間帯をそれぞれ抽出しているものとする。この場合、サーバ１０は、ステップＳ４０６の処理で燃料電池装置３０Ｂに関して抽出した夜間の時間帯において、開始時刻と終了時刻との間の時間が１０分間となるように、コントローラ４０Ｂのダウンロード開始時刻及び終了時刻を設定する。同様に、サーバ１０は、ステップ４０６の処理で燃料電池装置３０Ｃに関して抽出した夜間の時間帯において、開始時刻と終了時刻との間の時間が１０分間となるように、コントローラ４０Ｃのダウンロード開始時刻及び終了時刻を設定する。

次に、コントローラ４０Ａのダウンロードの開始時刻及び終了時刻を設定する例について説明する。例えば、サーバ１０は、ステップＳ４０２の処理でダウンロード時間を１０分間と算出し、ステップＳ４０７の処理で燃料電池装置３０Ｂ，３０Ｃの発電電力が第２所定値よりも大きく時間帯として昼間の時間帯をそれぞれ抽出しているものとする。この場合、サーバ１０は、ステップＳ４０７の処理で燃料電池装置３０Ｂ，３０Ｃに関して抽出した昼間の時間帯において、開始時刻と終了時刻との間の時間が１０分間となるように、コントローラ４０Ａのダウンロード開始時刻及び終了時刻を設定する。

図７に、サーバ１０によって設定されるコントローラ４０Ａ〜４０Ｃのダウンロードの開始時刻及び終了時刻の一例を示す。なお、図７に示す「日にち」は、ダウンロードを実行する第１日時に含まれる日にちであり、第１の実施形態において説明したように、コントローラ４０Ａ〜４０Ｃのそれぞれに、例えば分散させて割り当てられている。

このようなステップＳ４０６，Ｓ４０８の処理によって、負荷追従運転を行っている燃料電池装置の発電電力が小さくなる時間帯に、負荷追従運転を行っている燃料電池装置を制御するコントローラのダウンロードの開始時刻及び終了時刻が設定される。上述のように、一般的には、燃料電池装置の発電電力が小さくなると、燃料電池装置を制御するコントローラの処理量は低減する。従って、負荷追従運転を行っている燃料電池装置を制御するコントローラでは、該コントローラの処理量が比較的低減される時間帯に、ダウンロードの開始時刻及び終了時刻が設定される。これにより、本実施形態では、ファームウェアのダウンロードを効率よく行うことができる。

さらに、ステップＳ４０７，Ｓ４０８の処理によって、負荷追従運転を行っている燃料電池装置の発電電力が高くなる時間帯に、ベース電源として運転している燃料電池装置を制御するコントローラのダウンロードの開始時刻及び終了時刻が設定される。これにより、ベース電源の燃料電池装置を制御するコントローラのダウンロード実行中に、何らかの通信不慮により、ベース電源の燃料電池装置の運転が停止した場合でも、負荷追従運転を行っている燃料電池装置の運転は、発電電力が大きい状態で継続される。従って、このような事態が生じても、本実施形態では、安定して需要家施設に電力を供給することができる。

なお、サーバ１０は、コントローラ４０Ａ〜４０Ｃに対してダウンロードの開始時刻及び終了時刻を設定する際、親機のダウンロードの開始時刻及び終了時刻が、子機のダウンロードの開始時刻及び終了時刻よりも、早い時刻となるように設定してもよい。これは、後述の＜ファームウェアをダウンロードする際の処理＞を実行するためである。この場合、サーバ１０は、図７に示す「日にち」において、コントローラ４０Ａの日にちを、コントローラ４０Ｂ〜４０Ｃの日にちよりも、早い日にちに設定する。このとき、第１の実施形態に係る処理で、例えば、コントローラ４０Ｂの日にちの方がコントローラ４０Ａの日にちよりも早い日にちに設定されている場合、サーバ１０は、コントローラ４０Ａの日にちと、コントローラ４０Ｂの日にちを入れ替えてもよい。

また、後述の図８及び図１０に示す処理を実行しない場合、サーバ１０は、ステップＳ４０２の処理において、ダウンロード時間を第１時間としてもよい。

ここで、ダウンロードの開始時刻及び終了時刻は、サーバ１０からコントローラ４０Ａ〜４０Ｃにそれぞれ送信されるスケジュール情報に含まれる。従って、例えば、コントローラ４０Ａの制御部４４Ａは、前述の図２に示すステップＳ１０３の処理によって、自機器のダウンロードの開始時刻及び終了時刻を検出することができる。なお、第２の実施形態では、子機であるコントローラ４０Ｂの制御部４４Ｂは、自機器のダウンロードの開始時刻及び終了時刻を検出すると、自機器のダウンロードの開始時刻及び終了時刻を、親機であるコントローラ４０Ａに、ルータ５０Ａ等を介して通知する。子機であるコントローラ４０Ｃについても同様である。

＜ファームウェアをダウンロードする際の処理＞
以下、最新のファームウェアをサーバ１０からダウンロードする際のコントローラ４０Ａ〜４０Ｃの動作の一例について、図８を用いて説明する。まず、燃料電池装置及びコントローラのファームウェアについて簡単に説明する。

燃料電池装置及びコントローラのファームウェアは、複数種類存在する。以下の説明では、燃料電池装置を制御するための２種類のファームウェアと、コントローラを制御するための４種類のファームウェアとの合計６種類が存在するものとする。燃料電池装置の２種類のファームウェアは、例えば燃料電池装置に含まれる燃料電池を制御するためのファームウェアと、燃料電池装置に含まれる電力変換装置を制御するためのファームウェアとである。コントローラの４種類のファームウェアは、例えばブートローダに関するファームウェアと、カーネルに関するファームウェアと、ファイルシステムに関するファームウェアと、アプリケーションに関するファームウェアとである。一般的に、燃料電池装置を制御するための２種類のファームウェアは、コントローラを制御するための４種類のファームウェアと比較すると、データ容量が小さい（なお、更新に掛かる時間は、燃料電池装置を制御するための２種類のファームウェアの方が、コントローラを制御するための４種類のファームウェアよりも長くなる。）。そのため、サーバ１０から燃料電池装置及びコントローラのファームウェアの６種類をダウンロードする際、燃料電池装置の２種類のファームウェアが、コントローラの４種類のファームウェアよりも、先にダウンロードされる。言い換えれば、サーバ１０から燃料電池装置及びコントローラのファームウェアの６種類をダウンロードする際は、所定順序でファームウェアがダウンロードされる。従って、以下では、サーバ１０からダウンロードする６種類のファームウェアをファームウェア１，２，３，４，５，６とし、これら６種類のファームウェアは、ファームウェア１，２，３，４，５，６の所定順序でダウンロードされるものとする。また、コントローラ４０Ａ〜４０Ｃのダウンロードの開始時刻及び終了時刻等は、図７に示す時刻であるものとする。

コントローラ４０Ａの制御部４４は、コントローラ４０Ａのダウンロードの開始時刻の所定時間前になると、最新のファームウェアの要求を、通信部４１Ａからルータ５０Ａ及びネットワーク１００を介してサーバ１０に送信する（ステップＳ５０１）。サーバ１０は、コントローラ４０Ａから最新のファームウェアの要求を取得すると、コントローラ４０Ａのダウンロードの開始時刻（２０１６年８月９日１２時００）から終了時刻（２０１６年８月９日１２時１０）までの間、最新のファームウェアをコントローラ４０Ａに送信し続ける（ステップＳ５０２）。これにより、サーバ１０からコントローラ４０Ａへ、ファームウェア１，２が送信される。なお、コントローラ４０Ａの制御部４４Ａは、ファームウェア３のダウンロード中に終了時刻となり、ファームウェア３のダウンロードが未完了で終わった場合には、ファームウェア３を破棄する。

コントローラ４０Ａの制御部４４Ａは、サーバ１０からネットワーク１００及びルータ５０Ａを介して送信されるファームウェア１，２を、通信部４１Ａを介し取得すると、取得したファームウェア１，２を記憶部４２Ａに保持させる（ステップＳ５０３）。

このようなステップＳ５０１〜Ｓ５０３の処理によって、親機であるコントローラ４０Ａには、サーバ１０から、ファームウェア１，２が所定順序（ファームウェア１，２）でダウンロードされる。

コントローラ４０Ａの制御部４４Ａは、自機器でダウンロードが完了したファームウェア１，２に基づき、ファームウェア３〜６のダウンロードが未完了であると検出する。さらに、制御部４４Ａは、予めコントローラ４０Ｂ，４０Ｃから取得したコントローラ４０Ｂ，４０Ｃのダウンロードの開始時刻及び終了時刻に基づき、次にダウンロードを実行する子機がコントローラ４０Ｂであると特定する。従って、制御部４４Ａは、通信部４１Ａからルータ５０Ａ，５０Ｂを介して、コントローラ４０Ｂに対してファームウェア３以降のファームウェアをダウンロードするよう指示を送信する（ステップＳ５０４）。コントローラ４０Ｂの制御部４４Ｂは、コントローラ４０Ａからルータ５０Ａ，５０Ｂを介して送信されるファームウェア３以降のファームウェアをダウンロードするよう指示を、通信部４１Ｂを介し取得する。

コントローラ４０Ｂの制御部４４Ｂは、コントローラ４０Ｂのダウンロードの開始時刻の所定時間前になると、最新のファームウェアの要求を、通信部４１Ｂからルータ５０Ｂ及びネットワーク１００を介してサーバ１０に送信する（ステップＳ５０５）。このとき、制御部４４Ｂは、ステップＳ５０４の処理で取得した指示に基づき、最新のファームウェア１〜６のうち、ファームウェア３以降のファームウェアを要求する。サーバ１０は、この要求を取得すると、コントローラ４０Ｂのダウンロードの開始時刻（２０１６年８月１０日２３時００分）から終了時刻（２０１６年８月１０日２３時１０分）までの間、ファームウェア３以降のファームウェアを送信し続ける。これにより、サーバ１０からコントローラ４０Ｂへ、ファームウェア３〜５が送信される。なお、コントローラ４０Ｂの制御部４４Ｂは、ファームウェア６のダウンロード中に終了時刻となり、ファームウェア６のダウンロードが未完了で終わった場合には、ファームウェア６を破棄する。

コントローラ４０Ｂの制御部４４Ｂは、サーバ１０からネットワーク１００及びルータ５０Ｂを介して送信されるファームウェア３〜５を、通信部４１Ｂを介し取得すると、取得したファームウェア３〜５を記憶部４２Ｂに保持させる（ステップＳ５０７）。

このようなステップＳ５０４〜Ｓ５０７の処理によって、子機であるコントローラ４０Ｂには、サーバ１０から、親機がダウンロードしていないファームウェア３〜５が、所定順序（ファームウェア３，４，５）でダウンロードされる。

コントローラ４０Ｂの制御部４４Ｂは、ファームウェア３〜５のダウンロードが完了した旨を、通信部４１Ｂからルータ５０Ｂ，５０Ａを介してコントローラ４０Ａに送信する（ステップＳ５０８）。コントローラ４０Ａの制御部４４Ａは、コントローラ４０Ｂからルータ５０Ｂ，５０Ａを介して送信される、コントローラ４０Ｂによるファームウェア３〜５のダウンロードが完了した旨を、通信部４１Ａを介し取得する。

このようなステップＳ５０８の処理によって、親機であるコントローラ４０Ａの制御部４４が、コントローラ４０Ｂがファームウェア３〜５を保持しており、さらにファームウェア６がダウンロード未完了であることを検出することができる。

コントローラ４０Ａの制御部４４Ａは、自機器でダウンロードが完了したファームウェア１，２と、コントローラ４０Ｂから取得したファームウェア３〜５のダウンロードが完了した旨とに基づき、ダウンロードが未完了であるファームウェアは、ファームウェア６であると検出する。さらに、制御部４４Ａは、予めコントローラ４０Ｂ，４０Ｃから取得したコントローラ４０Ｂ，４０Ｃのダウンロードの開始時刻及び終了時刻に基づき、次にダウンロードを実行する子機は、コントローラ４０Ｃであると特定する。従って、コントローラ４０Ａの制御部４４Ａは、通信部４１Ａからルータ５０Ａ，５０Ｃを介して、コントローラ４０Ｃに対してファームウェア６をダウンロードする旨の指示を送信する（ステップＳ５０９）。コントローラ４０Ｃの制御部４４Ｃは、コントローラ４０Ａからルータ５０Ａ，５０Ｃを介して送信されるファームウェア６をダウンロードする旨の指示を、通信部４１Ｃを介し取得する。

コントローラ４０Ｃの制御部４４Ｃは、コントローラ４０Ｃのダウンロードの開始時刻の所定時刻前になると、最新ファームウェア６の要求を、通信部４１Ｃからルータ５０Ｃ及びネットワーク１００を介してサーバ１０に送信する（ステップＳ５１０）。サーバ１０は、この要求を取得すると、コントローラ４０Ｃのダウンロードの開始時刻（２０１６年８月１１日２３時４０分）から終了時刻（２０１６年８月１２日２３時５０分）までの間、ファームウェア６を送信し続ける。これにより、サーバ１０からコントローラ４０Ｂへ、ファームウェア６が送信される。

コントローラ４０Ｃの制御部４４Ｃは、サーバ１０からネットワーク１００及びルータ５０Ｃを介して送信されるファームウェア６を、通信部４１Ｃを介し取得すると、取得したファームウェア６を記憶部４２Ｃに保持させる（ステップＳ５１２）。

このようなステップＳ５０９〜Ｓ５１２の処理によって、子機であるコントローラ４０Ｃには、サーバ１０から、コントローラ４０Ａ，４０Ｂがダウンロードしていないファームウェア６が、ダウンロードされる。

コントローラ４０Ｃの制御部４４Ｃは、ファームウェア６のダウンロードが完了した旨を、通信部４１Ｃからルータ５０Ｃ，５０Ａを介してコントローラ４０Ａに送信する（ステップＳ５１３）。コントローラ４０Ａの制御部４４Ａは、コントローラ４０Ｃからルータ５０Ｃ，５０Ａを介して送信される、コントローラ４０Ｃによるファームウェア６のダウンロードが完了した旨を、通信部４１Ａを介し取得する。

このようなステップＳ５１３の処理によって、親機であるコントローラ４０Ａの制御部４４が、コントローラ４０Ｃがファームウェア６を保持しており、さらにファームウェア１〜６のダウンロードが全て完了したことを検出することができる。

ステップＳ５０１〜Ｓ５１３の処理によって、コントローラ４０Ａ〜４０Ｃがそれぞれ保持しているファームウェア１〜６を図９に示す。このように、コントローラ４０Ａ〜４０Ｃのそれぞれで保持しているファームウェアを組み合わせれば、ファームウェア１〜６の全てをそろえることができる。さらに、本実施形態では、各コントローラ４０Ａ〜４０Ｃが足りないファームウェアを相互で補完しあうことで、各コントローラ４０Ａ〜４０Ｃは全てのファームウェア１〜６の保持が可能になる。以下、この処理を説明する。

＜ファームウェアを補完する際の処理＞
以下、コントローラ４０Ａ〜４０Ｃの間で、足りないファームウェアを相互で補完しあう際の動作の一例について、図１０を用いて説明する。なお、親機であるコントローラ４０Ａは、ステップＳ５０８の処理によって、コントローラ４０Ｂはファームウェア３〜５を保持しているが、コントローラ４０Ｂはファームウェア１，２，６を保持していないことを検出している。親機であるコントローラ４０Ａは、ステップＳ５１３の処理によって、コントローラ４０Ｃはファームウェア６を保持しているが、コントローラ４０Ｃはファームウェア１〜５を保持していないことを検出している。

コントローラ４０Ａの制御部４４Ａは、通信部４１Ａからルータ５０Ａ、５０Ｂを介して、コントローラ４０Ｂに対してファームウェア３〜５の要求を送信する（ステップＳ６０１）。コントローラ４０Ｂの制御部４４Ａは、この要求を取得すると、記憶部４２Ｂに保持されているファームウェア３〜５を、通信部４１Ｂからルータ５０Ｂ，５０Ａを介してコントローラ４０Ａに送信する（ステップＳ６０２）。

コントローラ４０Ａの制御部４４Ａは、コントローラ４０Ｂからルータ５０Ｂ，５０Ａを介して送信されるファームウェア３〜５を、通信部４１Ａを介し取得すると、取得したファームウェア３〜５を記憶部４２Ａに保持させる（ステップＳ６０３）。

コントローラ４０Ａの制御部４４Ａは、通信部４１Ａからルータ５０Ａ、５０Ｂを介して、コントローラ４０Ｃに対してファームウェア６の要求を送信する（ステップＳ６０４）。コントローラ４０Ｃの制御部４４Ｃは、この要求を取得すると、記憶部４２Ｃに保持されているファームウェア６を、通信部４１Ｃからルータ５０Ｃ，５０Ａを介してコントローラ４０Ａに送信する（ステップＳ６０５）。

コントローラ４０Ａの制御部４４Ａは、コントローラ４０Ｃからルータ５０Ｃ，５０Ａを介して送信されるファームウェア６を、通信部４１Ａを介し取得すると、取得したファームウェア６を記憶部４２Ａに保持させる（ステップＳ６０６）。

このようなステップＳ６０１〜Ｓ６０６の処理によって、コントローラ４０Ａは、ファームウェアのダウンロードが中断されて不完全に終わった場合でも、ファームウェア１〜６の全てを取得することができる。

コントローラ４０Ａの制御部４４Ａは、記憶部４２Ａに記憶されているファームウェア１，２，６を、通信部４１Ａからルータ５０Ａ，５０Ｂを介してコントローラ４０Ｂに送信する（ステップＳ６０７）。

コントローラ４０Ｂの制御部４４Ｂは、コントローラ４０Ａからルータ５０Ａ，５０Ｂを介して送信されるファームウェア１，２，６を、通信部４１Ｂを介し取得すると、取得したファームウェア１，２，６を記憶部４２Ｂに保持させる（ステップＳ６０８）。

このようなステップＳ６０７，Ｓ６０８の処理によって、コントローラ４０Ｂは、ファームウェアのダウンロードが中断されて不完全に終わった場合でも、ファームウェア１〜６の全てを取得することができる。

コントローラ４０Ａの制御部４４Ａは、記憶部４２Ａに記憶されているファームウェア１〜５を、通信部４１Ａからルータ５０Ａ，５０Ｃを介してコントローラ４０Ｃに送信する（ステップＳ６０９）。

コントローラ４０Ｃの制御部４４Ｃは、コントローラ４０Ａからルータ５０Ａ，５０Ｃを介して送信されるファームウェア１〜５を、通信部４１Ｃを介し取得すると、取得したファームウェア１〜５を記憶部４２Ｃに保持させる（ステップＳ６１０）。

このようなステップＳ６０９，Ｓ６１０の処理によって、コントローラ４０Ｃは、ファームウェアのダウンロードが中断されて不完全に終わった場合でも、ファームウェア１〜６の全てを取得することができる。

第２の実施形態に係るファームウェア提供システム２のその他の構成及び効果は、第１の実施形態に係るファームウェア提供システム１の構成及び効果と同様である。

本発明の一実施形態を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各構成部、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の構成部やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、本発明の一実施形態について装置を中心に説明してきたが、本発明は装置が備えるプロセッサにより実行される方法、プログラム、又はプログラムを記録した記憶媒体としても実現し得るものであり、本発明の範囲にはこれらも包含されるものと理解されたい。

１，２ ファームウェア提供システム
１０ サーバ
２０ 端末装置
３０−１〜３０−ｎ，３０Ａ，３０Ｂ，３０Ｃ 燃料電池装置（電源装置）
３１，３１Ａ，３１Ｂ，３１Ｃ 発電部
３２，３２Ａ，３２Ｂ，３２Ｃ 電力変換部
３３，３３Ａ，３３Ｂ，３３Ｃ 通信部
３４，３４Ａ，３４Ｂ，３４Ｃ 記憶部
３５，３５Ａ，３５Ｂ，３５Ｃ 制御部
４０−１〜４０−ｎ，４０Ａ，４０Ｂ，４０Ｃ コントローラ（制御装置）
４１，４１Ａ，４１Ｂ，４１Ｃ 通信部
４２，４２Ａ，４２Ｂ，４２Ｃ 記憶部
４３，４３Ａ，４３Ｂ，４３Ｃ 表示部
４４，４４Ａ，４４Ｂ，４４Ｃ 制御部
５０−１〜５０−ｎ，５０Ａ，５０Ｂ，５０Ｃ ルータ
１００ ネットワーク

Claims (14)

1. 複数の電源装置及び該複数の電源装置にそれぞれ対応する制御装置にネットワークを介してファームウェアを提供するサーバを備えるファームウェア提供システムであって、
   前記サーバは、各前記制御装置が前記サーバから前記ファームウェアのダウンロードを実行する第１日時を、前記サーバの一斉送信可能なデータ容量を超えないように、前記制御装置にそれぞれ割り当て、さらに、前記第１日時を含むスケジュール情報を各前記制御装置に送信し、
   前記制御装置のそれぞれは、
   前記ネットワークを介して前記サーバと通信する通信部と、
   前記スケジュール情報を前記サーバから前記通信部を介して取得し、さらに、前記第１日時に、前記ファームウェアを前記サーバからダウンロードする制御部と、を備える、ファームウェア提供システム。
2. 請求項１に記載のファームウェア提供システムにおいて、
   前記サーバは、前記電源装置毎に指定される日時に基づき、前記電源装置及び前記制御装置のファームウェアの更新を実行する第２日時を設定し、
   前記スケジュール情報は、前記第２日時をさらに含み、
   前記通信部は、前記電源装置と通信し、
   前記制御部は、前記第２日時に、前記制御装置のファームウェアを最新のものに更新し、さらに、前記第２日時に、前記電源装置のファームウェアを前記電源装置に前記通信部を介して転送し、該電源装置にファームウェアの更新を実行させる、ファームウェア提供システム。
3. 請求項１又は２に記載のファームウェア提供システムにおいて、
   各前記制御装置は、表示部をさらに備え、
   前記制御部は、前記スケジュール情報を、前記表示部に表示させる、ファームウェア提供システム。
4. 請求項１から３の何れか１項に記載のファームウェア提供システムにおいて、
   前記制御部は、前記スケジュール情報を、前記サーバから定期的に取得する、ファームウェア提供システム。
5. 請求項１から４の何れか１項に記載のファームウェア提供システムにおいて、
   前記電源装置は、燃料電池装置である、ファームウェア提供システム。
6. 請求項１から５の何れか１項に記載のファームウェア提供システムにおいて、
   前記サーバは、前記第１日時に含まれる、ダウンロードを実行する日にちを各前記制御装置に対して分散させる、ファームウェア提供システム。
7. 請求項１から６の何れか１項に記載のファームウェア提供システムにおいて、
   前記サーバは、各前記制御装置に対し、該制御装置に対応する前記電源装置の状態情報を送信するよう要求し、
   前記制御装置は、前記サーバから前記電源装置の状態情報の要求を取得すると、該制御装置に対応する前記電源装置の状態情報を、前記サーバに対して送信し、
   前記サーバは、複数の前記制御装置から、該複数の制御装置に対応する各前記電源装置の状態情報を取得し、
   前記サーバは、同一需要家施設に設置され、かつ連結運転を行っている複数の前記電源装置において、前記状態情報に基づき、該連結運転を行っている複数の前記電源装置の全ての発電電力が時刻に対して変動しているか否か判定し、
   前記サーバは、前記連結運転を行っている複数の前記電源装置の全ての発電電力が時刻に対して変動していると判定したとき、前記ファームウェアの全容量と、該複数の電源装置にそれぞれ対応する各前記制御装置及び前記サーバ間の通信速度と、該制御装置の数とに基づき、ダウンロード時間を算出し、さらに、該ダウンロード時間と、該複数の前記電源装置の発電電力が第１所定値よりも小さくなる時間帯とに基づき、各該制御装置のダウンロードの開始時刻及び終了時刻を設定し、
   前記ダウンロードの開始時刻及び終了時刻は、前記第１日時に含まれる、ファームウェア提供システム。
8. 請求項７に記載のファームウェア提供システムにおいて、
   前記サーバは、前記状態情報に基づき、前記連結運転を行っている複数の前記電源装置の全ての発電電力が時刻に対して変動していると判定しないとき、該複数の電源装置のうち、発電電力が時刻に対して変動している１部の電源装置において、前記ダウンロード時間と、該１部の電源装置の発電電力が第１所定値よりも小さくなる時間帯とに基づき、該１部の電源装置に対応する各前記制御装置のダウンロードの開始時刻及び終了時刻を設定し、さらに、前記ダウンロード時間と、該１部の電源装置の発電電力が第２所定値よりも大きくなる時間帯とに基づき、該１部以外の電源装置に対応する各前記制御装置のダウンロードの開始時刻及び終了時刻を設定する、ファームウェア提供システム。
9. 請求項７又は８に記載のファームウェア提供システムにおいて、
   前記サーバは、同一需要家施設に設置され、親機又は子機に設定される複数の前記制御装置に対して前記ダウンロードの開始時刻及び終了時刻を設定する場合、親機である前記制御装置のダウンロードの開始時刻及び終了時刻が、子機である前記制御装置のダウンロードの開始時刻及び終了時刻よりも、はやい時刻となるように設定する、ファームウェア提供システム。
10. 請求項９に記載のファームウェア提供システムにおいて、
    親機である前記制御装置の通信部と、子機である前記制御装置の通信部とは、ルータを経由して互いに通信し、
    子機である前記制御装置の制御部は、前記サーバからスケジュール情報を取得すると、スケジュール情報に含まれる、自機器のダウンロードの開始時刻及び終了時刻を、親機である前記制御装置に前記ルータを経由して通知し、
    親機である前記制御装置の制御部は、自機器のダウンロードの開始時刻になると、ファームウェアを、所定順序で前記サーバから前記通信部を介してダウンロードし、
    親機である前記制御装置の制御部は、自機器でダウンロードが完了したファームウェアと、子機である前記制御装置から通知される該子機でダウンロードが完了したファームウェアとに基づき、ダウンロードが未完了であるファームウェアを検出し、さらに、予め子機から取得した子機のダウンロードの開始時刻及び終了時刻に基づき、次にダウンロードを実行する子機を検出し、該次にダウンロードを実行する子機である前記制御装置に対し、該検出したダウンロードが未完了であるファームウェアをダウンロードするよう、前記ルータを経由して指示し、
    子機である前記制御装置の制御部は、親機である前記制御装置から、親機によって検出されたダウンロードが未完了であるファームウェアをダウンロードするよう指示を受けている場合、自機器のダウンロードの開始時刻になると、該ダウンロードが未完了であるファームウェアを、所定順序で前記サーバから前記通信部を介してダウンロードする、ファームウェア提供システム。
11. 請求項９又は１０に記載のファームウェア提供システムにおいて、
    親機である前記制御装置の制御部は、自機器でダウンロードが完了したファームウェアと、子機である前記制御装置から通知される該子機でダウンロードが完了したファームウェアとに基づき、該親機が保持していないファームウェアを保持している子機を検出し、さらに、該検出した子機に対し、該親機が保持していないファームウェアを送信するよう前記ルータを経由して要求し、
    子機である前記制御装置の制御部は、親機である前記制御装置から該親機が保持していないファームウェアを送信するよう要求を受けると、該親機に対して、該ファームウェアを、前記ルータを経由して送信する、ファームウェア提供システム。
12. 請求項１１に記載のファームウェア提供システムにおいて、
    親機である前記制御装置の制御部は、子機である前記制御装置から通知される該子機でダウンロードが完了したファームウェアに基づき、該子機である前記制御装置が保持していないファームウェアを検出し、該検出したファームウェアを、該子機である前記制御装置に対し、前記ルータを経由して送信し、
    子機である前記制御装置の制御部は、親機である前記制御装置からファームウェアを取得すると、該ファームウェアを自機器の記憶部に保持させる、ファームウェア提供システム。
13. 複数の電源装置及び各該電源装置に対応する制御装置のファームウェアを提供するサーバを備えるファームウェア提供システムの制御方法であって、
    前記サーバによって、
    前記制御装置が前記サーバから前記ファームウェアのダウンロードを実行する第１日時を、前記サーバの一斉送信可能なデータ容量を超えないように、各前記制御装置にそれぞれ割り当て、
    前記第１日時を含むスケジュール情報を各前記制御装置に送信し、
    各前記制御装置によって、
    前記スケジュール情報を前記サーバから取得し、
    前記第１日時に、前記ファームウェアを前記サーバからダウンロードする、ファームウェア提供システムの制御方法。
14. 複数の電源装置及び該複数の電源装置にそれぞれ対応する制御装置にネットワークを介してファームウェアを提供するサーバと、
    複数の電源装置と、
    前記複数の電源装置にそれぞれ対応する制御装置と、を備え、
    前記サーバは、各前記制御装置が前記サーバから前記ファームウェアのダウンロードを実行する第１日時を、前記サーバの一斉送信可能なデータ容量を超えないように、前記制御装置にそれぞれ割り当て、さらに、前記第１日時を含むスケジュール情報を各前記制御装置に送信し、
    前記制御装置のそれぞれは、
    前記ネットワークを介して前記サーバと通信する通信部と、
    前記スケジュール情報を前記サーバから前記通信部を介して取得し、さらに、前記第１日時に、前記ファームウェアを前記サーバからダウンロードする制御部と、を備える、電源システム。
    

Images