JP6664343B2 - ソフトウェア更新管理システム及びプログラム - Google Patents

Description

本発明は、ソフトウェア更新管理システム及びプログラム、特に設備機器において動作するソフトウェアの更新に関する。

保守対象のビルのオーナー等の顧客が使用するタブレットやスマートフォンなどの端末にアプリケーションを配布して、顧客ビルの設備機器に関連するサービスを顧客に提供することが行われている。顧客が配布されたアプリケーションを使用してサービスを正常に利用できるようにするには、ビルの設備機器において動作するソフトウェアのバージョンが、配布されたアプリケーションに対応している必要がある。もし、対応していない場合には、設備機器のソフトウェアを更新したり新規インストールしたりする必要がある。以降の説明では、更新と新規インストールをあわせて「更新」と呼ぶことにする。

従来においては、更新の実績やビル設備の運用スケジュールを参照して設備機器（コントローラ）のソフトウェアの更新スケジュールを作成する技術が提案されている（例えば、特許文献１）。

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

ところで、顧客が上記サービスを利用できない場合、顧客は、どの設備機器のソフトウェアを更新してよいのか、またどのタイミングで更新してよいのかを判断することができない。ビル管理会社は、設備機器のソフトウェア及びその更新を管理するが、ソフトウェアの更新は、他のシステム（例えば、更新対象が空調設備の場合における入退管理システム）や他の顧客（例えば、ビルがテナントビルの場合における他のテナント）による設備機器の制御に影響を与える可能性がある。そのため、例えば、設備機器があまり利用されていない時間帯など適切なタイミングでソフトウェアの更新を行うことが望まれる。

従来においては、ソフトウェアの更新実績や設備機器の制御スケジュールを参照して設備機器の制御に影響を与えない時間帯を求め、その時間帯にソフトウェアの更新を行えるようにしていた。しかしながら、設備機器を動作させるための制御処理には、制御スケジュールとして設定されていない制御（例えば、顧客操作や環境変化をトリガーとして実行される制御）やビル設備の内部処理（例えば、データ集計処理）等があるが、従来では、ソフトウェアの更新実績や設備機器の制御スケジュールに表れてこない制御に与える影響を考慮していなかった。

本発明は、設備機器の制御スケジュールに表れてこない制御をも考慮してソフトウェアの更新を行うことを目的とする。

本発明に係るソフトウェア更新管理システムは、設備機器の制御のスケジュールが定義された制御スケジュール情報を記憶する制御スケジュール情報記憶手段と、前記設備機器において動作するソフトウェアの更新予定時間及び更新所要時間を含む更新要求情報を受け付ける受付手段と、前記設備機器にかかる負荷の状態を示す状態情報を取得する状態情報取得手段と、ソフトウェアの更新の可否を判定する更新判定手段と、前記更新判定手段からの指示に応じてソフトウェアの更新を行う更新手段と、を有し、前記更新判定手段は、前記状態情報を参照して、更新予定時間を迎えるソフトウェアの更新処理が、前記制御スケジュール情報にスケジュールが定義されている制御のみならず、定義されていない制御にも与える影響の度合いを示す影響度を算出する影響度算出部を含み、算出した影響度が所定の閾値以上の場合には当該ソフトウェアの更新を前記更新手段に指示しないものである。

また、前記制御スケジュール情報には、前記設備機器の各制御に対する優先度が予め設定されており、前記更新判定手段は、更新予定時間になっても更新が実行されていないソフトウェアに対し、更新予定時間からの経過時間に応じた優先度を設定する優先度設定部を含み、当該ソフトウェアの影響度が閾値以上であっても、当該ソフトウェアの優先度が当該ソフトウェアの更新を実行しようとした場合に重複して実行されることになる制御の優先度を上回る場合には当該ソフトウェアの更新を前記更新手段に指示するものである。

また、前記設備機器にかかる負荷の時系列的変化が定義された負荷モデルを記憶する負荷モデル記憶手段を有し、前記更新判定手段は、当該ソフトウェアの影響度が閾値以上であっても、前記負荷モデルを参照することによって前記設備機器にかかる負荷が今後上昇すると判断した場合に当該ソフトウェアの更新を前記更新手段に指示するものである。

本発明に係るプログラムは、設備機器の制御のスケジュールが定義された制御スケジュール情報を記憶する制御スケジュール情報記憶手段にアクセス可能なコンピュータを、前記設備機器において動作するソフトウェアの更新予定時間及び更新所要時間を含む更新要求情報を受け付ける受付手段、前記設備機器にかかる負荷の状態を示す状態情報を取得する状態情報取得手段、ソフトウェアの更新の可否を判定する更新判定手段、前記更新判定手段からの指示に応じてソフトウェアの更新を行う更新手段、として機能させるものである。

前記更新判定手段は、前記状態情報を参照して、更新予定時間を迎えるソフトウェアの更新処理が、前記制御スケジュール情報にスケジュールが定義されている制御のみならず、定義されていない制御にも与える影響の度合いを示す影響度を算出する影響度算出部を含み、算出した影響度が所定の閾値以上の場合には当該ソフトウェアの更新を前記更新手段に指示しないものである。

本発明によれば、設備機器の制御スケジュールに表れてこない制御をも考慮してソフトウェアの更新を行うことができる。

また、制御の実行に支障を来さないようにソフトウェアの更新を待機させる場合でも、更新予定日時から経過した時間が長くなった場合にはソフトウェアの更新を行うことができる。

また、制御機器の係る負荷が高く制御の実行に支障を来すことになる状態であっても、今後、制御機器に係る負荷が更に上昇するのであれば、ソフトウェアの更新を現時点で行うことができる。

本発明に係るソフトウェア更新管理システムの一実施の形態を示した全体構成図である。 実施の形態１におけるビル設備に搭載されるコンピュータのハードウェア構成図である。 実施の形態１におけるビル設備のブロック構成図である。 実施の形態１における更新要求情報記憶部に登録される更新要求情報のデータ構成の一例を示す図である。 実施の形態１における制御スケジュール情報記憶部に登録される制御スケジュール情報のデータ構成の一例を示す図である。 実施の形態１におけるソフトウェア更新処理を示すフローチャートである。 実施の形態１において取得される状態情報のデータ構成の一例を示す図である。 実施の形態２におけるビル設備のブロック構成図である。 実施の形態２における更新要求情報記憶部に登録される更新要求情報のデータ構成の一例を示す図である。 実施の形態２における制御スケジュール情報記憶部に登録される制御スケジュール情報のデータ構成の一例を示す図である。 実施の形態２におけるソフトウェア更新処理を示すフローチャートである。 実施の形態３におけるビル設備のブロック構成図である。 実施の形態３におけるソフトウェア更新処理を示すフローチャートである。

以下、図面に基づいて、本発明の好適な実施の形態について説明する。

実施の形態１．
図１は、本発明に係るソフトウェア更新管理システムの一実施の形態を示した全体構成図である。図１には、遠隔監視センタ１、顧客事務所２及び顧客ビル３が示されている。顧客事務所２は、顧客ビル３のオーナー等の顧客の事務所であり、公衆回線やインターネットなどの顧客用ネットワーク４を介して遠隔監視センタ１と通信を行う顧客端末２０が設けられる。顧客端末２０は、顧客が使用するパーソナルコンピュータ（ＰＣ）、スマートフォンあるいはタブレットなどの端末である。顧客ビル３は、顧客が所有するビルであり、ソフトウェアの更新対象とする１又は複数の設備機器（以下、「ビル設備」）３０が設置される。ビル設備３０は、公衆回線やインターネットなどの設備用ネットワーク５を介して遠隔監視センタ１と通信を行う。なお、顧客ビル３には、１又は複数のビル設備３０が設置されるが、各ビル設備３０とも後述する構成を有していればよいので、図１には、便宜的に１台のみ図示している。

遠隔監視センタ１は、ビル設備保守会社の施設であり、顧客ビル３に設置されているビル設備３０を遠隔から監視する。また、顧客端末２０にアプリケーションを配布することで、顧客に対し、顧客が所有する顧客ビル３のビル設備３０の利用に関連するサービスを提供する。

遠隔監視センタ１は、管理端末１１、ソフトウェア管理サーバ１２、顧客情報管理サーバ１３、顧客サービスサーバ１４及びビル設備管理装置１５をイントラネット１６で接続した構成を有している。管理端末１１は、遠隔監視センタ１において顧客端末向けアプリケーションとビル設備向けソフトウェアを管理する管理者により使用されるＰＣ等で構成され、ソフトウェアや各種情報の管理に用いられる。ソフトウェア管理サーバ１２は、顧客端末向けアプリケーション及びビル設備向けソフトウェアを保持管理するサーバコンピュータである。顧客情報管理サーバ１３は、顧客ビル３のビル設備３０について、配置やソフトウェアバージョンなどを含む構成情報を保持管理するサーバコンピュータである。顧客サービスサーバ１４は、サービスを顧客に提供するサーバコンピュータである。そのために、顧客サービスサーバ１４は、顧客からの要求に応じて顧客端末向けアプリケーションを顧客端末２０にダウンロードする。また、顧客サービスサーバ１４は、ビル設備３０におけるソフトウェアの更新をビル設備管理装置１５に要求し、更にソフトウェアが更新された通知をビル設備管理装置１５から受けると、ダウンロードした顧客端末向けアプリケーションが利用可能になった旨を顧客に通知する。ビル設備管理装置１５は、ビル設備３０の管理に用いられるサーバコンピュータである。具体的には、ビル設備３０の制御及び状態監視を実行する。また、ソフトウェアの更新要求に応じてビル設備３０自身が実行するソフトウェアの更新を管理する。

図２は、本実施の形態におけるビル設備３０に搭載されるコンピュータのハードウェア構成図である。本実施の形態においては、ソフトウェアを自ら更新でき、また実行する能力を持つコントローラを想定している。コントローラは、接続された空調等の各種設備（図示せず）の動作制御を行う設備機器である。コントローラに搭載されるコンピュータは、従前から存在する汎用的なハードウェア構成で実現できる。すなわち、コンピュータは、図２に示したようにＣＰＵ４１、ＲＯＭ４２、ＲＡＭ４３、ハードディスクドライブ（ＨＤＤ）４４、通信手段として設けられたネットワークインタフェース（ＩＦ）４５を内部バス４６に接続して構成される。

図３は、本実施の形態におけるビル設備３０のブロック構成図である。なお、本実施の形態の説明に用いない構成要素については図から省略している。本実施の形態におけるビル設備３０は、更新要求受付部３１、状態監視部３２、更新判定部３３、ソフトウェア更新部３４、制御部３５、ソフトウェア記憶部３６、更新要求情報記憶部３７及び制御スケジュール情報記憶部３８を有している。更新要求受付部３１は、ビル設備３０において動作するソフトウェアの更新要求情報を遠隔監視センタ１から受け付ける。状態監視部３２は、ビル設備３０にかかる負荷の状態を監視し、その状態を示す状態情報を更新判定部３３に渡す。更新判定部３３は、更新要求受付部３１が受け付けた更新要求に応じて、要求されたソフトウェアの更新が可能かどうかの判定を行う。そして、更新可と判定したときにはソフトウェアの更新をソフトウェア更新部３４に指示する。本実施の形態における更新要求受付部３１には、影響度算出部３３１が含まれている。影響度算出部３３１は、状態情報を参照して、更新予定時間を迎えるソフトウェアの更新処理が、制御スケジュール情報にスケジュールが定義されている制御のみならず、定義されていない制御にも与える影響の度合いを示す影響度を算出する。ソフトウェア更新部３４は、更新判定部３３からの指示に応じてソフトウェアの更新を行う。制御部３５は、各構成要素３１〜３４と連携してソフトウェアの更新処理を制御する。ソフトウェア記憶部３６には、更新対象のソフトウェアが蓄積される。

図４は、本実施の形態における更新要求情報記憶部３７に登録される更新要求情報のデータ構成の一例を示す図である。更新要求情報記憶部３７には、更新要求受付部３１により取得された更新要求情報が登録され、ソフトウェア更新部３４により更新が実行されると削除される。更新要求情報は、Ｕ−ＩＤ、ビルＩＤ、設備ＩＤ、ソフトウェア名、バージョン、所要時間及び更新要求日時を含む。Ｕ−ＩＤは、更新要求情報（レコード）の識別情報である。ビルＩＤは、更新要求情報を受け付けた顧客ビル３の識別情報である。設備ＩＤは、ソフトウェアの更新対象となるビル設備３０の識別情報である。本実施の形態では、更新要求情報をビル設備３０毎に保持するので、ビルＩＤ及び設備ＩＤにはそれぞれ、同じ識別情報が設定されることになる。ソフトウェア名は、更新対象のソフトウェアを特定する情報としての名称で、バージョンは更新後のソフトウェアのバージョンを示す。所要時間は、当該ソフトウェアの更新に要する時間である。更新要求日時は、当該ソフトウェアの更新処理の実行を開始させる予定日時である。

図５は、本実施の形態における制御スケジュール情報記憶部３８に登録される制御スケジュール情報のデータ構成の一例を示す図である。制御スケジュール情報記憶部３８には、ビル設備３０に対して行われる制御のスケジュールが予め定義された更新要求情報が登録される。動作制御部（図示せず）は、この制御スケジュールに従ってビル設備３０又はビル設備３０に接続されている空調等の設備機器の動作を制御する。制御スケジュール情報は、ＳＣ−ＩＤ、ビルＩＤ、設備ＩＤ、制御内容、設定値、開始日時及び終了日時を含む。ＳＣ−ＩＤは、制御スケジュール情報（レコード）の識別情報である。ビルＩＤ及び設備ＩＤは、更新要求情報において説明したとおりである。制御内容は、実施する制御の内容を特定する名称である。設定値には、当該制御を実施する際の具体的な設定値が設定される。開始日時及び終了日時は、制御を実施する時間の範囲を指定する情報であり、当該制御の始期と終期が設定される。

ビル設備３０における各構成要素３１〜３５は、ビル設備３０に搭載されるコンピュータと、コンピュータに搭載されたＣＰＵ４１で動作するプログラムとの協調動作により実現される。また、各記憶部３６〜３８は、ビル設備３０に搭載されたＨＤＤ４４にて実現される。あるいは、ＲＡＭ４３又は外部にある記憶手段をネットワーク経由で利用してもよい。

また、本実施の形態で用いるプログラムは、通信手段により提供することはもちろん、ＣＤ−ＲＯＭやＵＳＢメモリ等のコンピュータ読み取り可能な記録媒体に格納して提供することも可能である。通信手段や記録媒体から提供されたプログラムはコンピュータにインストールされ、コンピュータのＣＰＵがプログラムを順次実行することで各種処理が実現される。

顧客端末向けアプリケーション又はビル設備向けソフトウェアが更新されると、管理者は、管理端末１１を用いて更新されたソフトウェア、及び顧客端末向けアプリケーションとビル設備向けソフトウェアのバージョンの対応関係を示す対応情報をソフトウェア管理サーバ１２に登録する。顧客は、顧客端末２０を操作して顧客サービスサーバ１４から顧客端末向けアプリケーションをダウンロードにより取得する。顧客サービスサーバ１４は、ソフトウェア管理サーバ１２に登録されている対応情報及び顧客情報管理サーバ１３に登録されている顧客情報を参照することによって、当該顧客が新たに取得した顧客端末向けアプリケーションに対応するバージョンのビル設備向けソフトウェアが、当該顧客の顧客ビル３のビル設備３０にインストールされていないことを認識すると、ビル設備３０のソフトウェアの更新をビル設備管理装置１５に要求する。ビル設備管理装置１５は、この要求に応じてビル設備３０に更新要求情報を送信することで、ソフトウェアの更新を指示する。

遠隔監視センタ１から更新要求情報が送信されてくると、更新要求受付部３１は、その情報を取得し、更新要求情報記憶部３７に登録することで、ソフトウェアの更新要求を受け付ける。

次に、本実施の形態におけるソフトウェア更新処理について図６に示したフローチャートを用いて説明する。

更新判定部３３は、更新要求情報記憶部３７から更新要求情報から１レコード読み出す（ステップ１０１）。なお、ここでは、読み出した１つの更新要求情報に着目して説明する。他の更新要求情報に対しても同様に、更新要求情報記憶部３７から読み出して後述する処理を行うことになる。更新判定部３３は、更に制御スケジュール情報記憶部３８から制御スケジュール情報を読み出す（ステップ１０２）。

読み出した更新要求情報において更新対象とするソフトウェアの更新予定日時になるまで待機し（ステップ１０３でＮ）、その更新予定日時になると（ステップ１０３でＹ）、更新判定部３３は、状態監視部３２から状態情報を取得する（ステップ１０４）。なお、本実施の形態では、上記のような手順にて処理するが、ステップ１０１において更新判定部３３に更新要求情報の更新予定日時と現在時刻とを常時対比させ、更新予定日時を迎える時点で、該当する更新要求情報を読み出させるようにしてもよい。

図７は、本実施の形態における状態情報のデータ構成例を示した図である。状態情報は、Ｓ−ＩＤ、ビルＩＤ、設備ＩＤ、監視項目名、状態及び取得日時を含む。Ｓ−ＩＤは、状態情報（レコード）の識別情報である。ビルＩＤ及び設備ＩＤは、更新要求情報において説明したとおりである。監視項目名は、監視する項目を示す名称である。状態は、当該監視項目における現時点における状態である。１レコード目の状態情報は、ＣＰＵ負荷率が７０％であることを示している。取得日時は、負荷の状態が取得された日時である。

続いて、影響度算出部３３１は、更新予定日時を迎えるソフトウェアに対して影響度を算出する（ステップ１０５）。影響度は、更新予定日時を迎えるソフトウェアの更新処理を実行することによってビル設備３０に与える影響を客観的に数値によって示す指標である。本実施の形態では、影響度を次のようにして算出する。まず、説明の簡略化のためにＣＰＵ負荷率に着目して説明する。

本実施の形態では、影響度の有無を判別するために閾値を予め設定している。例えば、ＣＰＵ負荷率に対する閾値に８０％を設定したとする。ここで、状態情報から検出されるＣＰＵ負荷率が７０％であったとする。この場合の影響度は７０％となり、閾値（８０％）を下回るので（ステップ１０６でＮ）、更新判定部３３は、当該ソフトウェアの更新をソフトウェア更新部３４に指示する。この指示に応じて、ソフトウェア更新部３４は、新しいバージョンのソフトウェアを遠隔監視センタ１から取得し、当該ソフトウェアを更新する（ステップ１０７）。

一方、状態情報から検出されるＣＰＵ負荷率（影響度）が９０％であったとすると閾値（８０％）以上となるので（ステップ１０６でＹ）、更新判定部３３は、当該ソフトウェアの更新をソフトウェア更新部３４に指示することなくステップ１０４に戻る。すなわち、影響度が閾値を下回るまでステップ１０４〜１０６を繰り返すことになる。

以上の説明では、説明の簡略化のためにＣＰＵ負荷率に着目して説明したが、ビル設備３０の負荷を示す情報としては、その他にもメモリ使用率等種々の情報（監視項目）がある。そこで、本実施の形態では、影響度を計算により算出することにした。すなわち、影響度をＩとすると、影響度を次の式にて算出する。
Ｉ＝ａ（ｔｂ−ｔａ）＋ｂＬａ

ここで、ｔｂは更新要求情報に設定されている所要時間、ｔａは制御スケジュール情報の開始日時から得られる時間であって、ある制御につき現在時刻から当該制御が次に実行されることになる時間（開始日時）までの時間である。ここでいう、「ある制御」には、当該ソフトウェアの更新処理を実行しようとした場合に重複して実行されることになる制御が該当する。制御とソフトウェアの更新処理は、ビル設備３０の資源を共に使用（消費）するため、ソフトウェアの更新処理を更新予定日時に実行させてしまうと、重複して実行される既存の制御に影響を与えてしまうことになりかねないからである。Ｌａは、取得された状態情報に基づき現時点でビル設備３０にかかる負荷を所定の計算式にて数値化した負荷情報である。ａ及びｂは係数であり、ビル設備３０毎又はビル設備３０の種類（空調、入退システム等）毎に適宜設定される。

上記計算式において、（ｔｂ−ｔａ）は、ソフトウェアの更新処理が制御スケジュール情報に定義されている制御が実行されない間に実行できるかどうかを示している。仮に、ソフトウェア更新の所要時間ｔｂが、制御が実行されない空き時間ｔａより長ければ、それだけ制御の実行に影響を与えることになる。

また、負荷情報Ｌａには、制御スケジュールに定義されていない制御（例えば、顧客操作や環境変化をトリガーとして実行される制御）やビル設備の内部処理（例えば、データ集計処理）等による使用に基づくビル設備３０にかかる負荷が含まれる。この負荷情報Ｌａを加えて影響度を算出することで、ソフトウェアの更新の可否の判定の際に、ソフトウェアの更新実績や設備機器の制御スケジュールには表れてこない制御による負荷を考慮することが可能となる。仮に、制御スケジュールに定義されている制御が実行されていないのにもかかわらず、負荷情報Ｌａが示す値が相対的に大きければ、制御スケジュールに定義されていない制御が実行されている可能性があると推定できる。つまり、ソフトウェアの更新を開始してしまうと、制御スケジュールに定義されていない制御の実行に影響を与えることになりうる。

上記説明では、ＣＰＵ負荷率を用いて簡略的に説明したが、更新判定部３３は、影響度算出部３３１において上記計算式にて算出した影響度を、所定の閾値と比較することで、上記説明したようにソフトウェアの更新の可否を判定する。なお、上記計算式は一例であってこれに限定する必要はない。

算出した影響度が閾値を下回ると（ステップ１０６でＮ）、前述したように、更新判定部３３による指示によりソフトウェアの更新が行われる（ステップ１０７）。

一方、影響度が閾値以上の場合（ステップ１０６でＹ）、ステップ１０４〜１０６を繰り返すことになる。しかしながら、ビル設備３０の負荷はいずれ落ちてきて、影響度はいずれ閾値を下回るようになるとも考えられる。更新予定日時は過ぎるかもしれないがビル設備３０の制御の実行に影響を与えないタイミングでソフトウェアの更新を実行することができる。

以上説明したように、本実施の形態によれば、ビル設備３０にかかる負荷を考慮することで、ソフトウェアの更新処理が制御スケジュール情報に定義されている制御のみならず、制御スケジュール情報に定義されていない制御にも与える影響をも考慮してソフトウェアの更新の実行を制御することができる。すなわち、本実施の形態によれば、ビル設備３０における動作、運用等に影響を与えないようにしてソフトウェアを更新することができる。

ソフトウェアの更新が終了すると、当該ソフトウェアに対応する更新要求情報は、制御部３５又は制御部３５による制御のもとソフトウェア更新部３４により更新要求情報記憶部３７から削除される。そして、ソフトウェアが更新されたことは、遠隔監視センタ１を介して顧客に通知され、これにより、顧客は、顧客端末向けアプリケーションが利用できるようになったことを知ることになる。このように、本実施の形態によれば、ビル設備３０において更新すべきソフトウェアやソフトウェアの更新タイミングを意識することなく、顧客は、サービスの提供を受けることができるようになる。

なお、本実施の形態では、更新が終了したソフトウェアに対応する更新要求情報を更新要求情報記憶部３７から削除するようにしたが、削除せずに、更新が終了した旨を示すフラグ情報あるいは更新終了日時を当該更新要求情報に対応付けして記録するようにしてもよい。

実施の形態２．
図８は、本実施の形態におけるビル設備のブロック構成図である。実施の形態１（図１）と同じ構成要素には同じ符号を付け説明を省略する。本実施の形態では、実施の形態１において示した更新判定部３３に、優先度設定部３３２を追加している。優先度設定部３３２は、更新予定時間になっても更新が実行されていないソフトウェアに対し、更新予定時間からの経過時間に応じた優先度を設定する。なお、ビル設備３０のハードウェア構成は実施の形態１と同じでよい。

図９は、本実施の形態における更新要求情報記憶部３７に登録される更新要求情報のデータ構成の一例を示す図である。本実施の形態における更新要求情報には、実施の形態１（図４）に示したデータ構成に、優先度設定部３３２によって設定、更新される優先度が追加設定される。

図１０は、本実施の形態における制御スケジュール情報記憶部３８に登録される制御スケジュール情報のデータ構成の一例を示す図である。本実施の形態における制御スケジュール情報には、実施の形態１（図５）に示したデータ構成に、設定度が予め設定される。制御スケジュール情報に含まれる優先度は、制御それぞれに対応して設定される固定値である。遅延させることなくスケジュール通りに実行させたい制御ほど高い値の優先度が設定される。

次に、本実施の形態におけるソフトウェア更新処理について図１１に示したフローチャートを用いて説明する。なお、実施の形態１と同じ処理ステップには、同じステップ番号を付け、説明を適宜省略する。

前述したように、更新判定部３３は、ソフトウェアの更新の可否について判定する際、ビル設備３０の負荷の状態を参照して影響度を算出する（ステップ１０１〜１０５）。そして、算出した影響度が閾値を下回ると（ステップ１０６でＮ）、実施の形態１と同様に更新判定部３３による指示によりソフトウェアの更新が行われる（ステップ１０７）。

一方、影響度が閾値以上の場合（ステップ１０６でＹ）、本実施の形態における優先度設定部３３２は、当該ソフトウェアに対し優先度を設定する（ステップ２０１）。より詳細に説明すると、各ソフトウェアには、優先度の初期値として０が設定されており、当該ソフトウェアの更新要求日時からの経過時間が所定の閾値Ｔｓを超える度に優先度を１ずつ上げていく。例えば、閾値Ｔｓが５分とした場合、更新要求日時から５分経過したときに１、１０分経過したときに２、と、優先度は時間の経過に伴い高い値となるように更新される。

優先度を設定すると、更新判定部３３は、ソフトウェアの所要時間及び制御スケジュール情報の開始日時と終了日時を参照し、制御スケジュール情報に定義されている制御の中から、仮にソフトウェアの更新を今から実行しようとした場合に、ソフトウェアの更新処理と重複して実行されることになる制御を抽出する。そして、ソフトウェアの優先度と抽出した１又は複数の制御の優先度を比較し、ソフトウェアの優先度が全ての制御の優先度を上回るのであれば（ステップ２０２でＮ）、更新判定部３３は、ソフトウェア更新部３４に指示することで、ソフトウェアを更新させる（ステップ１０７）。

一方、ソフトウェアの優先度がいずれかの制御の優先度以下であれば（ステップ２０２でＹ）、ソフトウェアの更新指示をすることなくステップ１０４に戻る。これにより、ステップ１０４〜２０２の処理は繰り返し実行される可能性はあるが、ステップ２０１において、時間の経過に伴いソフトウェアの優先度が高くなるので、ソフトウェアの優先度は、いずれ抽出した全ての制御の優先度を上回ることになり、これにより、ソフトウェアは更新されることになる。

実施の形態１においては、影響度が閾値以上の場合でも、ビル設備３０にかかる負荷はいずれ落ちてくると仮定し、これにより影響度はいずれ閾値を下回るようになるので、それまで待ってソフトウェアの更新を行うことにした。本実施の形態では、このような仮定は不要としている。つまり、ビル設備３０の負荷は一定以上継続して高い状態にあるとしたら、ソフトウェアは更新できなくなる。そこで、このような場合に対処できるように、優先度をソフトウェア及び制御に設定し、ソフトウェアの更新ができない状態が続いた場合に、重複して実行されることになるかもしれない制御との優先度の関係から、ソフトウェアの更新処理の方が制御の実行より優先度が高くなったときにソフトウェアの更新を行うようにした。これにより、制御の実行に対し若干の影響を与えるかもしれないが、ソフトウェアの更新が実行されない状態のまま続くことから回避することができる。

実施の形態３．
図１２は、本実施の形態におけるビル設備のブロック構成図である。実施の形態１（図１）と同じ構成要素には同じ符号を付け説明を省略する。なお、ビル設備３０のハードウェア構成は実施の形態１と同じでよい。

本実施の形態では、実施の形態１に示した構成に、負荷モデル記憶部３９を追加した構成を有している。負荷モデル記憶部３９に記憶される負荷モデルは、ビル設備３０にかかる負荷の時系列的変化が定義されたモデルデータであり、過去の負荷の遷移から生成される。例えば、負荷の高い制御が実行したり、複数の制御が同時に実行したりするときにビル設備３０にかかる負荷は高くなる。また、負荷モデルには、負荷の遷移のみならず、制御中の時間帯、あるいは保守中や集計中（例えば、日報処理の制御プログラムの動作時）などビル設備３０の利用状況を示す情報を時間に関連付けて設定してもよい。ビル設備３０の現在の利用状況は、遠隔監視センタ１から取得するようにしてもよい。

次に、本実施の形態におけるソフトウェア更新処理について図１３に示したフローチャートを用いて説明する。なお、実施の形態１と同じ処理ステップには、同じステップ番号を付け、説明を適宜省略する。

前述したように、更新判定部３３は、ソフトウェアの更新の可否について判定する際、ビル設備３０の負荷の状態を参照して影響度を算出する（ステップ１０１〜１０５）。そして、算出した影響度が閾値を下回ると（ステップ１０６でＮ）、実施の形態１と同様に更新判定部３３による指示によりソフトウェアの更新が行われる（ステップ１０７）。

一方、影響度が閾値以上の場合（ステップ１０６でＹ）、本実施の形態における更新判定部３３は、負荷モデル記憶部３９から負荷モデルを取得し、負荷モデルから現時点以降の負荷のレベルの動向を認識する（ステップ３０１）。ここで、ビル設備３０にかかる負荷が今後上昇すると判断した場合（ステップ３０２でＹ）、ソフトウェア更新部３４に指示することで、ソフトウェアを更新させる（ステップ１０７）。

一方、ビル設備３０にかかる負荷が今後上昇しないと判断した場合（ステップ３０２でＮ）、ソフトウェアの更新指示をすることなくステップ１０４に戻る。

実施の形態１においては、影響度が閾値以上の場合でも、ビル設備３０にかかる負荷はいずれ落ちてくると仮定してステップ１０４〜１０６を繰り返すようにした。ただ、ビル設備３０にかかる負荷は落ちるどころかこれ以降上昇することも考えられる。

そこで、本実施の形態では、過去の実績に基づき生成された負荷モデルを参照して、現時点以降、負荷が落ちない、すなわち影響度が閾値を下回ることが見込めない場合には、影響度が閾値以上であってもソフトウェアの更新を強行するようにした。このようにして、ソフトウェアの更新が実行されない状態のまま続くことから回避することができる。

なお、上記説明では、負荷の遷移のみに注目してソフトウェアの更新の可否を判定するようにした。ただ、制御中等利用状況を示す情報が付加されている場合、この情報を更に参照してソフトウェアの更新の可否を判定するようにしてもよい。例えば、今後、負荷は上昇する傾向にあっても、直近にいずれの制御も実行されない保守中となる時間帯が存在すれば、その時間までソフトウェアの更新を待機する。あるいは、今後、負荷が低下する傾向にあっても現時点以降はしばらく制御中が続くのであれば、保守中である現時点でソフトウェアの更新を実行してしまう。このように、負荷の遷移に加えて過去におけるビル設備３０の利用状況を参照して、ソフトウェアの更新の可否を判定してもよい。

なお、本実施の形態では、便宜的に負荷モデルを１つある場合で説明したが、営業日／休日、時節等に応じて複数用意しておいてもよい。

また、本実施の形態は、実施の形態１に追加する機能として説明したが、実施の形態２と組み合わせて実施してもよい。

ところで、前述した実施の形態以外にも、次のように変形させて実施してもよい。例えば、状態監視部３２は、ビル設備３０にかかる負荷の状態を監視したが、これに加えて、特定のソフトウェア、具体的には更新対象となるソフトウェアやこのソフトウェアと連携して実行されるソフトウェア、あるいはプライオリティの高い制御ソフトウェア等の動作状態を監視対象としてもよい。そして、特定のソフトウェアが動作中の場合はソフトウェアの更新を待機させる。

また、上記各実施の形態においてステップ１０６において影響度と比較する閾値は固定値であった。ただ、負荷モデルのように時間に応じて設定値を変えるようにしてもよい

また、上記各実施の形態においては、ビル設備３０において当該ビル設備３０のソフトウェアの更新制御を行うようにしたが、他の装置、例えば、ゲートウェイとのその他の装置でビル設備３０のソフトウェアの更新制御を行うようにしてもよい。顧客ビル３に複数のビル設備３０が設置されている場合、複数のビル設備３０を管理するビル管理装置で行うようにしてもよい。あるいは遠隔監視センタ１から行うようにしてもよい。

また、顧客ビル３に複数のビル設備３０が設置されている場合において複数のビル設備３０が連携して動作する場合は、他のビル設備３０の負荷をも考慮する、すなわち他のビル設備３０の状態情報をも参照して影響度を算出するようにしてもよい。遠隔監視センタ１がソフトウェアの更新制御を行う場合には、他の顧客ビル３のビル設備３０の負荷を考慮するようにしてもよい。この場合、遠隔監視センタ１の顧客ビル３におけるソフトウェアの更新の管理を行うことになるが、この場合、算出した影響度に基づきソフトウェアの更新する順番を決めるようにしてもよい。

更に、本実施の形態では、ビル設備３０におけるソフトウェアの更新の可否をビル設備３０において自動的に判断するようにしたが、ビル設備３０に通知部を設けて、ソフトウェアの更新の是非を顧客に問い合わせるようにしてもよい。

１ 遠隔監視センタ、２ 顧客事務所、３ 顧客ビル、４ 顧客用ネットワーク、５ 設備用ネットワーク、１１ 管理端末、１２ ソフトウェア管理サーバ、１３ 顧客情報管理サーバ、１４ 顧客サービスサーバ、１５ ビル設備管理装置、１６ イントラネット、２０ 顧客端末、３０ ビル設備、３１ 更新要求受付部、３２ 状態監視部、３３ 更新判定部、３４ ソフトウェア更新部、３５ 制御部、３６ ソフトウェア記憶部、３７ 更新要求情報記憶部、３８ 制御スケジュール情報記憶部、３９ 負荷モデル記憶部、４１ ＣＰＵ、４２ ＲＯＭ、４３ ＲＡＭ、４４ ハードディスクドライブ（ＨＤＤ）、４５ ネットワークインタフェース（ＩＦ）、４６ 内部バス、３３１ 影響度算出部、３３２ 優先度設定部。

Claims (4)

1. 設備機器の制御のスケジュールが定義された制御スケジュール情報を記憶する制御スケジュール情報記憶手段と、
   前記設備機器において動作するソフトウェアの更新予定時間及び更新所要時間を含む更新要求情報を受け付ける受付手段と、
   前記設備機器にかかる負荷の状態を示す状態情報を取得する状態情報取得手段と、
   ソフトウェアの更新の可否を判定する更新判定手段と、
   前記更新判定手段からの指示に応じてソフトウェアの更新を行う更新手段と、
   を有し、
   前記更新判定手段は、
   前記状態情報を参照して、更新予定時間を迎えるソフトウェアの更新処理が、前記制御スケジュール情報にスケジュールが定義されている制御のみならず、定義されていない制御にも与える影響の度合いを示す影響度を算出する影響度算出部を含み、
   算出した影響度が所定の閾値以上の場合には当該ソフトウェアの更新を前記更新手段に指示しないことを特徴とするソフトウェア更新管理システム。
2. 前記制御スケジュール情報には、前記設備機器の各制御に対する優先度が予め設定されており、
   前記更新判定手段は、
   更新予定時間になっても更新が実行されていないソフトウェアに対し、更新予定時間からの経過時間に応じた優先度を設定する優先度設定部を含み、
   当該ソフトウェアの影響度が閾値以上であっても、当該ソフトウェアの優先度が当該ソフトウェアの更新を実行しようとした場合に重複して実行されることになる制御の優先度を上回る場合には当該ソフトウェアの更新を前記更新手段に指示することを特徴とする請求項１に記載のソフトウェア更新管理システム。
3. 前記設備機器にかかる負荷の時系列的変化が定義された負荷モデルを記憶する負荷モデル記憶手段を有し、
   前記更新判定手段は、当該ソフトウェアの影響度が閾値以上であっても、前記負荷モデルを参照することによって前記設備機器にかかる負荷が今後上昇すると判断した場合に当該ソフトウェアの更新を前記更新手段に指示することを特徴とする請求項１に記載のソフトウェア更新管理システム。
4. 設備機器の制御のスケジュールが定義された制御スケジュール情報を記憶する制御スケジュール情報記憶手段にアクセス可能なコンピュータを、
   前記設備機器において動作するソフトウェアの更新予定時間及び更新所要時間を含む更新要求情報を受け付ける受付手段、
   前記設備機器にかかる負荷の状態を示す状態情報を取得する状態情報取得手段、
   ソフトウェアの更新の可否を判定する更新判定手段、
   前記更新判定手段からの指示に応じてソフトウェアの更新を行う更新手段、
   として機能させ、
   前記更新判定手段は、
   前記状態情報を参照して、更新予定時間を迎えるソフトウェアの更新処理が、前記制御スケジュール情報にスケジュールが定義されている制御のみならず、定義されていない制御に与える影響度を算出する影響度算出部を含み、
   算出した影響度が所定の閾値以上の場合には当該ソフトウェアの更新を前記更新手段に指示しないことを特徴とするプログラム。
   

Images