JP2004206390A

JP2004206390A - ソフトウェア管理装置及びソフトウェア管理サーバ

Info

Publication number: JP2004206390A
Application number: JP2002374539A
Authority: JP
Inventors: Takeshi Higuchi; 毅樋口; Tatsuya Tsurukawa; 達也鶴川
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2002-12-25
Filing date: 2002-12-25
Publication date: 2004-07-22

Abstract

【課題】組み込み機器に配布するソフトウェアの配信処理に適した時間の抽出を行う。
【解決手段】サーバよりネットワークを介して送信されたソフトウェアを受信して組み込み機器に適用するソフトウェア管理装置であって、上記組み込み機器の稼働状況を取得して上記ソフトウェアの更新に適する時間帯を算出する状況監視手段と、上記時間帯に基づいて、上記ソフトウェアを取得し、さらに上記組み込み機器への適用を指示する更新制御手段とを備えたソフトウェア管理装置を提供する。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、組み込み機器において動作するソフトウェアを更新するための装置および組み込み機器において動作するソフトウェアを更新管理するためのサーバ装置に関するものである。
【０００２】
【従来の技術】
近年の半導体製造技術や情報処理技術などの向上に伴ない、コンピュータの処理能力が大幅に高くなっており、かつ、コンピュータの小型化や低価格化も日々進行している。また、ネットワーク技術の向上に伴い、インターネットの普及やブロードバンド化が進んでいる。このような背景の下、例えば携帯電話のように、従来専用装置として設計され、単一の機能しか備えていなかった機器に、汎用的なＣＰＵ（中央演算装置）を内蔵させ、コンピュータなどにも用いられている基本ソフトウェアなどを用いることにより、コンピュータと同様に複数のアプリケーションソフトウェアを動作させ、より複雑な処理を行わせるようになっている。これらの機器は、潜在的には通常のパーソナルコンピュータやワークステーションと遜色ない機能を有しているが、キーボード装置やディスプレイ装置などのマンマシンインターフェースを省略することで、主として専用機能を果たすような利用形態で用いられている。このような機器は、一般に組み込み機器と呼ばれることが多い。
【０００３】
このように、各機器が複雑な処理を行うようになると、その処理を行うソフトウェアも複雑化してくるため、品質や信頼性の維持が問題となってくる。例えば、これらの機器上で動作するソフトウェアに不具合があった場合、これらの組み込み機器は、前述の通りマンマシンインターフェースを持たないことが多いので、通常のコンピュータのように手軽にソフトウェアの更新を行うことができない場合が多い。
【０００４】
またこのような組み込み機器は、無人運転されている場合などもある。そのため、ソフトウェアのアップデートのために、ネットワークを用いた遠隔更新が行う要求が高い。さらに、これらの機器は専用機器であるという性格を有しているため、２４時間自動運転されている場合が多く、ソフトウェアを更新するために、その機能を停止するには注意を要する場合が多い。
【０００５】
そこでソフトウェアを更新しても、その組み込み機器が関連する業務やシステム全体に支障を来さない所定の時間帯を予め見い出し、この時間帯を利用してソフトウェアを更新する手段が開示されている（例えば特許文献１）。
【０００６】
【特許文献１】
特開２０００−１４８４５５（第５−６頁、第１図）
【０００７】
【発明が解決しようとする課題】
しかしながら、上述の方法においても以下のような問題がある。すなわち、ソフトウェアの更新を行う時間が所定の時間帯に固定されているため、緊急事態の発生などのために、その時間帯に組み込み機器がソフトウェアの更新を行うことができない場合にもソフトウェアの更新を行ってしまい、その組み込み機器が関連する業務やシステム全体に支障を来すおそれがある。また、組み込み機器にソフトウェアを配信するサーバ側の負荷分散を考慮していないために、ソフトウェア配信対象となる組み込み機器が多数存在し、同時に更新要求を行う場合には、サーバやネットワークの負荷が増大してしまう。
【０００８】
本発明は、組み込み機器用のソフトウェア管理装置およびソフトウェア管理サーバによって、ソフトウェア配信可能な時間帯を検出し、ソフトウェアの配信を組み込み機器本来の処理に影響することなく確実に行えるようにするものである。
【０００９】
【課題を解決するための手段】
本発明に係るソフトウェア管理装置は、
サーバよりネットワークを介して送信されたソフトウェアを受信して組み込み機器に適用するソフトウェア管理装置であって、
上記ソフトウェア管理装置は、
上記サーバより上記ソフトウェアを取得するソフトウェア取得手段と、
上記ソフトウェアを上記組み込み機器に適用するソフトウェア更新手段と、
上記組み込み機器の稼働状況を取得して上記ソフトウェアの更新に適する時間帯を算出する状況監視手段と、
上記時間帯に基づいて、上記ソフトウェア取得手段に上記ソフトウェアの取得を指示し、さらに上記ソフトウェア更新手段に上記ソフトウェア取得手段により取得した上記ソフトウェアの上記組み込み機器への適用を指示する更新制御手段とを備えるものである。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
実施の形態１．
図１は、本発明の実施の形態１における組み込み機器とソフトウェア管理装置、及びソフトウェア管理サーバを示した構成図である。図において、組み込み機器１は、実施の形態１におけるソフトウェア管理装置の処理対象となる機器である。ソフトウェア管理装置２（以後、管理装置２という）は、組み込み機器１のソフトウェアを更新する機能を有する部位であって、組み込み機器１の部品または組み込み機器１に組み込まれてたＣＰＵによって実行されるプログラムとして実現されている。ただし管理装置２は、必ずしも組み込み機器１と一体となっている必要はなく、組み込み機器１とＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）やＲＳ−２３２Ｃインターフェースによって接続されていてもよい。
【００１１】
管理装置２において、通信手段３は、ネットワークを介して情報（データ）を送受信できる部位であって、具体的にはＬＡＮアダプタやＬＡＮアダプタに相当する機能をワンチップ化したＬＳＩなどによって実現されている。ただし、通信手段３は、ネットワークを介して情報を送受信できるようになっていればよいのであって、そのような条件を満たすものであれば、モデム装置その他の通信装置であってもよい。ソフトウェア取得手段４は、組み込み機器１のＣＰＵによって実行されるプログラムを通信手段３を介して取得する部位であって、具体的にはコンピュータプログラムとして実現されている。ソフトウェア更新手段５は、組み込み機器１で実行されるソフトウェアを実際に置き換えて、かつ組み込み機器１にこのソフトウェアの実行を指示する機能を有する部位である。このような処理を、一般に「ソフトウェアの適用」と呼ぶことが多い。ソフトウェア更新手段５が更新対象としているソフトウェアは、更新前においてすでに組み込み機器１によって実行されていることも想定される。このような場合には、更新対象となるソフトウェアの実行を一旦停止又は終了させた上で、このソフトウェアの新しいバージョンを適用することとなる。状況監視手段６は、組み込み機器１の稼働状況を取得する部位である。稼働状況とは、例えば組み込み機器１のＣＰＵの使用率（または負荷状況）などの情報である。ＣＰＵの使用率をモニタリングするためには、例えば入出力処理を完了させるための待機時間を監視し、全時間からこの待機時間の合計を減算し、これを全時間で除算すればよい。または組み込み機器１が搭載しているオペレーティングシステムが、ＣＰＵの使用率をモニタリングする機能を有している場合には、その機能の出力結果を利用してもよい。更新制御手段７は、ソフトウェアの新しいバージョンの取得をソフトウェア取得手段４に指示し、さらに取得したソフトウェアの適用をソフトウェア更新手段５に指示する部位である。
【００１２】
ネットワーク１０は、管理装置２とサーバを接続するためのネットワークであって、管理装置２の通信手段３がデータを送受信するための媒体となるものであるが、このネットワークは無線であってもよい。組み込み機器用ソフトウェア管理サーバ１１（以後、サーバ１１と呼ぶ）は、組み込み機器１で実行されるソフトウェアを配信するためのサーバであって、図示せぬＣＰＵを有するコンピュータによって実現される。サーバ１１において、通信手段１２は、ネットワーク１０を介してデータを送受信する部位であり、機能としては通信手段３と同様であるので、説明を省略する。通知手段１３は、管理装置２に各種の情報を通知する部位であって、例えばソフトウェアの更新に適する時間帯に関する情報を通知したり、サーバ１１の図示せぬ記憶装置に組み込み機器１用のソフトウェアであって、現在配布されているソフトウェアよりも新しいバージョンが存在する場合には、通信手段１２を介して管理装置２にそのことを通知するなどの作用を有する。ソフトウェア配信手段１４は、サーバ１１が記憶している組み込み機器１用のソフトウェアの新しいバージョンを通信手段１２を介して管理装置２に送信するための部位である。記憶装置１５は、組み込み機器１用のソフトウェアを記憶するための装置であって、具体的にはハードディスク装置などの不揮発性記憶装置によって実現される。
【００１３】
次に実施の形態１におけるソフトウェア更新処理について説明する。図２は、実施の形態１におけるソフトウェア更新処理のフローチャートである。ステップＳ１０１において、サーバ１１上の通知手段１３は、現在組み込み機器１が実行しているソフトウェアよりも新しいバージョンのソフトウェアがサーバ１１の記憶装置１５上に導入されたことを検出すると、そのことを管理装置２に通知する。またこれと同時に、ソフトウエアの配信に要する時間とソフトウェアの適用に要する時間も通知する。このような処理を行うための前提として、サーバ１１は現在組み込み機器１で実行しているソフトウェア、すなわち最後にサーバ１１が組み込み機器１に配布したソフトウェアのバージョンを取得あるいは記憶していることになる。
【００１４】
ただし、このようなバージョン情報を記憶しておくことは、サーバ１１を実現するために必須ではなく、例えば組み込み機器１上のソフトウェアのバージョン管理はオペレータ等が行うこととし、通知手段１３はサーバ１１の記憶装置１５上に何らかのバージョンによる組み込み機器１用のソフトウェアが存在していることを検出すると無条件に、管理装置２に配布すべきソフトウェアが存在することを通知するような構成としてもよい。また、現時点で組み込み機器１が実行しているソフトウェアのバージョンを通信手段１２を介して取得し、サーバ１１上の記憶装置１５に存在する組み込み機器１用のソフトウェアのバージョンとを比較した上で、サーバ１１上の記憶装置１５に存在するソフトウェアのバージョンの方が新しい場合には、管理装置２に通知するような構成としてもよい。
【００１５】
なお、バージョン情報としては、ソフトウェアの実体であるプログラムの実行可能ファイルのタイムスタンプを採用してもよいし、プログラムの実行可能ファイルを生成する場合に、コンパイラ等がこの実行可能ファイルのヘッダに埋め込むバージョン番号やビルド番号などを利用してもよい。また、ソフトウエアの配信に要する時間とソフトウェアの適用に要する時間については、オペレータ等が事前にテスト環境で計測した時間に基づいて指定する。
【００１６】
ステップＳ１０２において、管理装置２上の更新制御手段７は、ソフトウェアの送信可能時間帯の検出を行う。ソフトウェアの送信可能時間帯とは、ネットワーク１０を介して、組み込み機器１用のソフトウェアの実行可能ファイルをサーバ１１から管理装置２に送信するのに十分な長さの時間帯をいう。このような時間帯は、組み込み機器１が使用できるネットワーク１０の帯域幅が制限されている場合に問題になる。例えば、組み込み機器１がネットワーク１０のトラフィックを監視するための機器である場合には、組み込み機器１のソフトウェアを配布するために発生するネットワークトラフィックが、本来の監視対象であるトラフィックに極力影響しないようにする必要がある。またネットワーク１０の帯域幅が狭く、かつ他の機器が多数接続されている状態であって、組み込み機器１用ソフトウェアの更新のために他の機器の処理が影響を受けるような時間帯にソフトウェアの配布を行うことを避ける必要がある。
【００１７】
このような時間帯を検出するために、更新制御手段７はネットワーク１０のトラフィック量を、例えば１分おき、または１０分おきなど定期的にモニタする。そして１日または１週間など所定の期間の間採取したトラフィック量の中で、最小となる時間帯を検出し、その時間帯をソフトウェアの送信可能時間とする。したがって例えば土曜日の午前２：００〜４：００が最もトラフィック量が少ないことを検出した場合には、次に到来する土曜日の午前２：００〜４：００がここでの時間帯に相当することになる。
【００１８】
このように過去の履歴に基づいて、将来のソフトウェアの送信可能時間帯を予測しうる理由は、実施の形態１の組み込み機器１がいわゆる専用機器として用いられているためである。これらの専用機器は、通常無人運転環境下に置かれており、したがってある一定周期ごとにこのようなネットワークトラフィック量が小さくなる時間帯が到来することが予測できる。また携帯電話のように無人運転環境にはない機器であっても、携帯電話の利用者の生活パターンや使用パターンに応じて、例えば夜間は使用頻度が下がる、というような特定の利用形態が存在する場合が多い。更新制御手段７は、このような時間帯をトラフィック量に基づいて算出するものである。
【００１９】
なおこの他に、このような処理を管理装置２によってではなく、サーバ１１で実行する構成も考えられる。この場合には、サーバ１１上で採取したネットワーク１０のトラフィック量の中で、最もトラフィック量の少ない時間帯を選択し、この時間帯をステップＳ１０１における通知に合わせて各組み込み機器の管理装置２に送信するようにしてもよい。またソフトウェアの送信可能時間帯の検出処理はサーバ１１を構成する上では必須ではない。例えば、組み込み機器１の機能がネットワークトラフィックに依存しない場合、あるいはシステムの性質上特にネットワークトラフィックの小さくなる時間帯の存在が予測できない場合などは、特に時間帯を定めずにソフトウェアの送信をすることになる。
【００２０】
次に上記時間帯の到来とともに、ステップＳ１０３において、管理装置２の更新制御手段７は、サーバ１１に対して新しいソフトウェアの配信依頼を行う。ステップＳ１０２で説明したように、送信可能時間帯の算出を行わない場合には、ステップＳ１０１の直後にこの処理を実行してもよい。また送信可能時間帯の算出をサーバ１１で実行した場合には、この処理を省略して、サーバ側で送信可能時間帯の到来を待った後に、次のステップＳ１０４の処理を実行してもよい。
【００２１】
続いて、ステップＳ１０４において、サーバ１１のソフトウェア配信手段１４は、組み込み機器１用のソフトウェアの配信をソフトウェア取得手段４に対して行う。ソフトウェアの配信はネットワーク１０を介してプログラムの実行可能ファイルをＴＣＰ／ＩＰのｆｔｐ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）などの手順によるファイル転送によって行われる。
【００２２】
ここで、ファイル転送によって取得したソフトウエアのプログラム実行可能ファイルは、図示せぬ一時記憶領域に記憶させることとする。この一時記憶領域は、組み込み機器１がこのソフトウェアを起動するために参照するプログラム実行可能ファイルが記憶されている記憶領域とは異なる領域である。
【００２３】
なお、これまで説明してきたステップＳ１０１〜Ｓ１０３の処理を省略して、最初からステップＳ１０４を実行するような構成としてもよい。例えば管理装置２側ではなく、サーバ１１側で送信可能時間帯を算出するような構成を採用した場合は、管理装置２側でソフトウェア配信のための特別な準備を必要としないので、ステップＳ１０１の通知処理も省略することができる。このような場合には、最初からステップＳ１０４を実行するという構成を採ることで、構成を単純化することも可能である。
【００２４】
次に、ステップＳ１０５において、更新制御手段７は更新可能時間の検出を行う。更新可能時間の検出方法は、組み込み機器１の用途・性質によってさまざまな方法が考えられるが、ここでは組み込み機器１に搭載されたＣＰＵの稼働状況に基づいて、更新可能時間帯を算出する方法について説明する。
【００２５】
まず状況監視手段６は、組み込み機器１に搭載されたＣＰＵの稼働状況（使用率）を予め監視しておく。ここで、ＣＰＵの稼働状況とは、所定の稼働時間単位、例えば１秒おき、あるいは１分おきごとに、その時間内に行われた入出力処理の完了待機やＳｌｅｅｐシステムコール（プログラムが意図的に一定時間実行を遅延させる処理）、イベント待機のためにＣＰＵがアイドル状態になる時間（アイドル時間）を総計し、前述した所定の稼働時間からこのアイドル時間を減算した残りの時間が、前述した所定の稼働時間に占める割合をいう。
【００２６】
例えば、センサからの信号を処理するようなシステムである場合、センサからの信号は入出力処理に相当するので、センサからある信号が入力された後、次の信号が入力されるまでの間はアイドル時間となる。その他前述したとおり、組み込み機器１で動作しているオペレーティングシステムが出力するＣＰＵ使用率を稼働状況として取得してもよい。
【００２７】
更新制御手段７は、この稼働状況を１日あるいは１週間、１ヶ月などの周期で集積し、最も稼働状況の低い期間を検出する。ソフトウェアの更新に要する時間以上の長さを有する期間を更新可能時間帯として算出する。その結果、次の周期における同一の時間帯が更新可能時間帯として使用される。
【００２８】
次に更新制御手段７が算出した更新可能時間帯が到来すると、ステップＳ１０６において更新制御手段７は、ソフトウェア更新手段５に指示を行い、ソフトウェア取得手段４が取得した新しいバージョンのソフトウェアを組み込み機器１に適用する。適用処理を開始した時点で、古いバージョンのソフトウェアが組み込み機器１によって実行されている場合には、一度その実行を終了させる。そしてソフトウェア取得手段４は、一時記憶領域に記憶されている新しいバージョンのソフトウェアを、組み込み機器１が参照する記憶領域に記憶されているプログラムの実行可能ファイルを上書きし、さらにソフトウェアを起動する。
【００２９】
ここで、組み込み機器１の機能がこのソフトウェアのみの起動によっては完全に回復しない場合には、更新制御手段７は、組み込み機器１全体を再起動し、その後に続いてソフトウェアの起動を行う。このような場合、上述したソフトウェアの更新に要する時間とは、再起動を含む時間となる。この時間はステップＳ１０１の通知処理に伴って管理装置２に伝えられたものであるが、ステップＳ１０１を省略するような構成とした場合には、ステップＳ１０４のソフトウェアの配信処理の前後に、適用に要する時間の長さをサーバ１１が通知するような構成としてもよい。
【００３０】
続くステップＳ１０７において、更新制御手段７は、更新完了通知をサーバ１１のソフトウェア配信手段１４に対して行う。ステップＳ１０８において、ソフトウェア配信手段は、この更新完了通知を受けて、更新完了確認を行う。更新完了確認は、記憶装置１５にそのソフトウェアが組み込み機器１について配信を完了したことを示すフラグを記憶させることによって行われる。
【００３１】
以上から明らかなように、実施の形態１によるソフトウェア管理装置とソフトウェア管理サーバによれば、組み込み機器１の稼働状況に応じて、動的にソフトウェアの配信時間及びソフトウェアの適用時間を決定することができる。
【００３２】
なお、上記においては、ソフトウェアの配信処理とソフトウェアの適用処理又は更新処理を別のステップとして扱い、ソフトウェア取得手段４が取得したソフトウエアのプログラム実行可能ファイルを一時記憶領域に一旦記憶させた上で、後にこのプログラム実行可能ファイルを組み込み機器１の参照する記憶領域のプログラム実行可能ファイルに上書きする構成としたが、この他にソフトウェア取得手段４が直接的に組み込み機器１の参照する記憶領域のプログラム実行可能ファイルに上書きする構成とすることも可能である。ただし、このような構成とするためには、ソフトウェアの配信までも更新可能時間帯に行う必要があるので、更新可能時間帯の時間長さにファイル転送の時間を含める必要がある。
【００３３】
実施の形態２．
次に本発明の実施の形態２における組み込み機器とソフトウェア管理装置、及び組み込み機器用ソフトウェア管理サーバについて説明する。図３は、実施の形態２における組み込み機器とソフトウェア管理装置、及びソフトウェア管理サーバの構成図である。図において、イベント源８は組み込み機器１の稼働状況を表す情報であって、組み込み機器１の状態に応じてさまざまなイベントを発生する。稼働状況取得手段１６は、通信手段１２を介して管理装置２から組み込み機器１の稼働状況を取得するための部位であり、具体的には、図示せぬＣＰＵによって実行されるコンピュータプログラムによって構成される。更新時間帯算出手段１７は、稼働状況取得手段１６が取得した組み込み機器１の稼働状況に基づいて、ソフトウェアの更新処理を実行する時間帯を算出し、稼働状況取得手段１６と同じくコンピュータプログラムによって構成される。なお、実施の形態１と同じ符号を付した構成要素については、実施の形態１と同様であるので、説明を省略する。
【００３４】
次に実施の形態２におけるソフトウェア更新処理について説明する。図４は、実施の形態２におけるソフトウェア更新処理のフローチャートである。図のステップＳ２０１において、管理装置２の状況監視手段６は、イベント源８が発生するイベントを、通信手段３によりサーバ１１の稼働状況取得手段１６に送信する。例えば、組み込み機器１が自動車を制御するコンピュータであり、イベント源８が自動車の運転状況を監視するセンサである場合、エンジンの始動、エンジンの停止、自動車の発信、自動車の停止などといったイベントを発生する。状況監視手段６は、このような情報を取得して稼働状況取得手段１６に送信する。
【００３５】
ステップＳ２０２において、稼働状況取得手段１６はステップＳ２０１により状況監視手段６から送信されてくるイベントを履歴情報として蓄積する。イベントの蓄積は記憶装置１５にイベントを記憶させることによって行われ、それぞれのイベントは発生時間とイベントの内容が関連づけられる形で記録される。またそれと同時に、イベント源８から出力されるイベントに基づいて、組み込み機器１の状態を遷移状態として求め、これを各イベントに関連づけて履歴情報に記憶させる。図５に、稼働状況取得手段１６が記録する履歴情報の例を示す。図において、カラム２１１はそのイベントの発生した時刻を示すものであり、カラム２１２はイベントの種類、カラム２１３は遷移元状態、カラム２１４は遷移先状態である。ここで、遷移元状態とはイベントが発生する前の自動車の運行状態であり、遷移先状態とはイベント発生後の自動車の運行状態である。
【００３６】
次にステップＳ２０３において、更新可能時間帯の算出を行う。図５で示した履歴情報の場合、各イベントが隣接しているレコードであるとすると、あるレコードの遷移先状態とそのレコードの次のレコードの遷移元状態は同じ状態になる。例えば、一のレコードの遷移先状態が「エンジン稼働」である場合には、その次のレコードの遷移元状態は「エンジン稼働」となる。したがってこれに基づき、一のレコードの発生日時とその次のレコードの発生日時との差を算出することにより、「エンジン稼働」であった状態の時間長さ（遷移状態の持続時間）を取得することができる。このようにして、各遷移状態の持続時間の最小値を算出し、その平均値がソフトウェアの配信処理に要する時間以上となる遷移状態を検出する。例えば前掲の自動車の運行状態において、各遷移状態の持続時間の最小値が図６のようになったとする。ソフトウェアの更新処理に要する時間が３０秒であるとすると、「エンジン停止」状態あるいは「前進」状態にある場合にソフトウェアの更新処理を実行するのが最適であることが分かる。
【００３７】
次にステップＳ２０４において更新可能イベントが到来した場合、すなわち前掲の例でいえば、「エンジン停止」状態あるいは「前進」状態が到来した場合に、サーバ１１のソフトウェア配信手段１４は、管理装置２のソフトウェア取得手段４に対してソフトウェアの配信を行う。ソフトウェア取得手段４は、取得したソフトウェアのプログラム実行ファイルを組み込み機器１が参照する記憶領域とは異なる一時領域に記憶させる。
【００３８】
続いてステップＳ２０５において、管理装置２のソフトウェア更新手段５は、ソフトウェア取得手段４が取得したソフトウェアを組み込み機器１に適用する。そのために、ソフトウェア更新手段５は現在組み込み機器１が実行しているソフトウェアの実行を終了させ、次に一時領域に記憶されていたプログラム実行ファイルを組み込み機器１が参照する記憶領域に上書きする。
【００３９】
次にステップＳ２０６において、ソフトウェア更新手段５は、通信手段３を介してサーバ１１のソフトウェア配信手段１４に対し、更新完了通知を行う。続いてサーバ１１のソフトウェア配信手段１４は、この更新完了通知を受けて、更新完了確認を行う。更新完了確認は記憶装置１５にそのソフトウェアが組み込み機器１について配信を完了したことを示すフラグを記憶させることによって行われる。以上が、実施の形態２によるソフトウエア配信処理である。
【００４０】
なお上記では、自動車の運行状態の遷移を例にして、ソフトウェア配信に適する時間帯の検出方法を説明したが、このような時間帯の検出方法は自動車の運行状態の遷移に限られるものではない。例えば、組み込み機器１が温度監視を行う機器である場合、イベント源８は温度センサとなる。またこのようなイベント源に基づくサーバ１１の稼働状況取得手段１６が蓄積する履歴情報は、例えば図７のようになる。図において、カラム３０１はその温度を検出した時間であり、カラム３０２はイベント源８において検出された温度である。この場合において、この温度監視器の上限値が４０℃で下限値が１０℃であると設定されている場合、各温度からこれらの上限値、下限値のいずれかに達する最短時間が図８のように算出されているものとする。仮にソフトウェアの更新に３０秒とすると、この履歴情報から１８．４℃から２９．１℃の間であれば、ソフトウェアの更新が可能であることが予測できる。この場合には、したがって、ソフトウェア配信手段１４は、１８．４℃と２９．１℃の間の値がイベントとして到来した場合に、ソフトウェア配信処理を開始する。
【００４１】
以上より明らかなように、実施の形態２におけるソフトウェア管理装置とソフトウェア管理サーバによれば、組み込み機器１の状態遷移が起きない時間帯を選択して、動的にソフトウェアの配信時間及びソフトウェアの適用時間を決定するので、組み込み機器１が果たすべき機能に影響を与えることなく、ソフトウェアの配信処理を行うことができる。
【００４２】
また、更新可能時間帯の算出処理をサーバ１１側で実行する構成としたので、組み込み機器１あるいは管理装置２に大容量の記憶装置を装着できない場合であっても、上述した効果を奏することができる。
【００４３】
なお、組み込み機器１あるいは管理装置２に大容量の記憶装置を装着できるような場合には、管理装置２が自律的に更新可能時間帯の算出を行うような構成を採用してもよい。この場合には、ステップＳ２０２のイベントの蓄積、ステップ２０３の更新可能時間帯の算出はいずれも管理装置２側で実行し、これらが終了した後に、更新可能時間帯の到来とともに、実施の形態１のように配信依頼をサーバ１１のソフトウェア配信手段１４に行うようにすればよい。
【００４４】
また実施の形態２において、状況監視手段６は、組み込み機器１の稼働状況を取得するたびに、稼働状況監視手段１４に稼働状況を出力したが、稼働状況を通知する回数が多いと、通信のオーバーヘッドが増大することが考えられる。例えばこのような稼働状況をたとえばＴＣＰ／ＩＰパケットで通信する場合には、それぞれのパケットにヘッダを付加する必要があるので、稼働状況の通知回数が多いと、パケットヘッダによるオーバーヘッドが増大することになる。そこで、状況監視手段６は所定の期間の稼働状況を記憶しておき、所定の期間の終期に稼働状況監視手段１４に通知するようにしてもよい。
【００４５】
その他、実施の形態２ではイベント源８からのイベント情報に基づいて、ソフトウェア配信処理の実行可能な時間帯を求める構成としたが、実施の形態１と同じように組み込み機器１のＣＰＵの使用率に基づいて、サーバ１１側でソフトウェア配信が可能な時間帯を算出するようにしてもよい。その場合には、状況監視手段はイベント源８からの情報の代わりにＣＰＵ使用率を定期的に稼働状況取得手段１６に通知するようにすればよい。
【００４６】
実施の形態３．
次に本発明の実施の形態３におけるソフトウェア管理装置及びソフトウェア管理サーバについて説明する。実施の形態１及び実施の形態２では、組み込み機器単体から得られる情報に基づいてソフトウェアの更新可能時間帯の算出を行った。これに対し実施の形態３では、複数の組み込み機器から得られる情報に基づいて、ネットワーク負荷およびサーバの負荷などシステム全体の負荷を軽減しながら、ソフトウェアの更新処理を行う方法について説明する。
【００４７】
図９は、実施の形態３における組み込み機器とソフトウェア管理装置、及びソフトウェア管理サーバの構成図である。図において、稼働状況マイニング手段１８は、一定期間の間に複数の組み込み機器で発生するイベントや、それらの組み込み機器の遷移状態を分析して、ソフトウェア配信に適した時間帯やイベントの抽出を行う。また組み込み機器３１は、実施の形態３のソフトウェア更新処理の対象となる機器である。その他、実施の形態２と同一の符号を付した構成要素については、実施の形態２と同様であるので、説明を省略する。ここで、図９では図示しないが、組み込み機器３１においても、組み込み機器１と同様に、ソフトウェア管理装置２、通信手段３、ソフトウェア取得手段４、ソフトウェア更新手段５、状況監視手段６、更新制御手段７、イベント源８に相当する部位を有しているものとする。
【００４８】
次に、実施の形態３におけるソフトウェア更新処理について説明する。図１０は、実施の形態３におけるソフトウェア更新処理のフローチャートである。図のステップＳ３０１において、サーバ１１の稼働状況取得手段１６は各組み込み機器で発生するイベントを収集する。具体的には、組み込み機器１の状況監視手段６がイベント源８からイベントを取得し、通信手段３を介してサーバ１１にイベントを送信する。また組み込み機器３１においても同様に、これらに相当する部位がイベントを送信する。サーバ１１の稼働状況取得手段１６は、通信手段１２を介してこれらのイベントを受信する。
【００４９】
続いてステップＳ３０２において、稼働状況取得手段１６は、取得したイベントを、そのイベント後にそれぞれの組み込み機器が達する遷移状態に変換する。例えば組み込み機器１が温度監視装置であって、イベント源８が温度センサである場合、イベントは温度センサにより取得された温度の値であり、遷移状態とはその温度の結果組み込み機器１が置かれる状態（定常状態、異常状態など）である。また稼働状況取得手段１６は、変換した遷移状態を記憶装置１５上のログファイルに出力する。このログファイルはイベント、あるいは新たに発生した遷移状態ごとに１つのレコードを構成し、このレコードには発生時間、遷移状態、その遷移状態をとっている組み込み機器名あるいは組み込み機器を特定するＩＤ（ネットワークアドレスなどを含む）を少なくとも含むものとする。
【００５０】
図１１はこのログファイルの内容の例を示す説明図である。図において、例えば組み込み機器１は２００２年１２月２日１０時１５分２０秒に遷移状態Ａとなり、組み込み機器３１は２００２年１２月２日１０月１５分２１秒に遷移状態Ｂとなったことを示している。なおイベントから遷移状態へ変換する処理については、稼働状況取得手段１６で行わずに、組み込み機器１の状況監視手段６で行うという構成としてもよい。その場合にはステップＳ３０２は省略可能となる。
【００５１】
次に、ステップＳ３０３において稼働状況マイニング手段１８は、遷移状態ログのマイニングを行うことによってログファイルを解析し、各遷移状態の発生傾向を取得する。具体的には、全時間を所定の期間に分割し、それぞれの期間において遷移状態が生じる統計量を取得する。遷移状態の統計量には、その遷移状態の持続時間の平均値とばらつきを少なくとも含むものとする。
【００５２】
また、ステップＳ３０３におけるマイニング処理では、複数の組み込み機器の遷移状態の組み合わせをも考慮するものとする。組み合わされた遷移状態の持続時間とは、次のように考えるものとする。すなわち、例えば図１１の例の場合、２００２年１２月２日において組み込み機器１は１０時１５分２０秒に遷移状態Ａとなり、組み込み機器３１は１０月１５分２１秒に遷移状態Ｂとなった後に、組み込み機器１は１０時１５分２２秒に遷移状態Ｃとなっている。そうすると、組み込み機器１が遷移状態Ａとなり、かつ、組み込み機器３１が遷移状態Ｂとなっている時間は、１０月１５分２１秒から１０時１５分２２秒までである。したがって、遷移状態Ａと遷移状態Ｂの組み合わせの持続時間は１秒ということになる。なお、ばらつきについては後述することとする。
【００５３】
前述したとおり、遷移状態ログのマイニングでは、各組み込み機器の遷移状態の組み合わせについても考慮する。例えば組み込み機器１がＡ_１、Ｂ_１という遷移状態をとるものとし、組み込み機器３１がＡ_２、Ｂ_２という遷移状態をとるものとすると、Ａ_１、Ｂ_１、Ａ_２、Ｂ_２という個別の遷移状態の持続時間だけでなく、Ａ_１とＡ_２、Ａ_１とＢ_２、Ｂ_１とＡ_２、Ｂ_１とＢ_２、といった遷移状態の持続時間についても計算することとする。一般に、組み込み機器がＮ個存在し、それぞれのとり得る遷移状態がＴ_Ｋ個（Ｋ＝１，２，…，Ｎ）あるとすると、個別あるいは部分的な組み合わせまでを考慮した組み合わせの総数は、次式のＰ_Ｎによって表される。
【００５４】
【数１】

【００５５】
遷移状態ログのマイニングでは、原則として、上式によって得られるＰ_Ｎ通りの遷移状態の組み合わせ全てについて、持続時間およびそれらのばらつきを算出するが、組み込み機器の台数が多く、Ｎが大きな値となる場合には、Ｐ_Ｎの値は大きくなるため、計算量が膨大となる。そこで次のような方法によって、計算量を低減してもよい。
【００５６】
第１の方法として、各組み込み機器の性質やシステムによって生じる可能性の極めて低い遷移状態の組み合わせ、あるいは定常的に生じるわけではない遷移状態の組み合わせが予め分かっている場合には、それらをパターンとして表現し、そのパターンを含む遷移状態の組み合わせについて、持続時間の計算を省略する方法が考えられる。具体的には、例えば組み込み機器１がＡ_１、Ｂ_１という遷移状態をとるものとし、組み込み機器３１がＡ_２、Ｂ_２という遷移状態をとる場合であって、Ａ_１とＢ_２という組み合わせが生じることが極めてまれである場合には、「Ａ_１−Ｂ_２」というパターンを外部から稼働状況マイニング手段１８に与え、稼働状況マイニング手段１８はこのパターンに関する持続時間の計算を省略する。
【００５７】
ここで、さらにＡ_３、Ｂ_３、Ｃ_３という遷移状態をとる組み込み機器が別にあり、論理的にＡ_１とＢ_２とＣ_３という遷移状態が生じうる場合であっても、この遷移状態の組み合わせの中には、「Ａ_１−Ｂ_２」というパターンを含むために、この遷移状態に関する発生時間、持続時間の計算が省略される。これによって、周期的に生じない遷移状態に関する計算を省略することで、計算量が削減される。
【００５８】
第２の方法として、所定の個数以上の遷移状態からなる組み合わせについては、発生時間、持続時間の計算を省略するという方法が考えられる。Ａ_１という遷移状態が発生する確率と持続時間はＡ_１とＢ_１とが同時に発生する確率と持続時間よりも当然に大きい。そうすると、多数組み合わせた遷移状態が発生する確率がその持続時間は微少となることが予測できる。そこで、所定の個数、例えば４個以上の遷移状態の組み合わせの持続時間の計算を無条件に省略するようにすれば、計算量が削減される。
【００５９】
第３の方法として、各組み込み機器の遷移状態のうち、それぞれの組み込み機器が定常状態にある、と考えられる遷移状態の組み合わせについてのみ優先的に持続時間を計算する方法が考えられる。例えば組み込み機器１の遷移状態Ａ_１と組み込み機器３１の遷移状態Ａ_２がそれぞれの組み込み機器において定常状態を示すものであるならば、Ａ_１とＡ_２の組み合わせは最も頻繁に発生する組み合わせであると考えられる。このような遷移状態が事前に分かっているのであれば、これをパターンとして表現し、外部から稼働状況マイニング手段１８に与えて、このパターンに関する持続時間の計算のみを行わせることによって、計算量を削減することができる。
【００６０】
次に、これらの遷移状態の組み合わせに基づいて、ログファイルのレコードから各遷移状態の発生時間、持続時間を求める処理について具体的に説明する。図１２は、各遷移状態の発生時間、持続時間を計算する方法の説明図である。図において、２００２年１２月２日１０時１５分２０秒のレコードは、組み込み機器１が遷移状態Ａにおかれたことを示すものである。したがって遷移状態Ａは２００２年１２月２日１０時１５分２０秒を発生時間とすることになる。また２００２年１２月２日１０時１５分２１秒のレコードは、組み込み機器３１が遷移状態Ｂにおかれたことを示すものである。したがって遷移状態Ｂが２００２年１２月２日１０時１５分２１秒に発生したことになる。
【００６１】
さらに、このレコードは組み込み機器１が遷移状態Ａにおかれ、かつ、組み込み機器３１が遷移状態Ｂにおかれたことを示すものでもある（図では遷移状態Ａ＋Ｂとして示している）。そこで遷移状態Ａ＋Ｂの発生時間は２００２年１２月２日１０時１５分２１秒となる。
【００６２】
次に、２００２年１２月２日１０時１５分２２秒のレコードは、組み込み機器１が遷移状態Ｃにおかれたことを示すものである。また、このレコードによって、それまで組み込み機器１がおかれていた遷移状態Ａが終了したことをも意味する。そこで、前述した遷移状態Ａの持続時間は、２００２年１２月２日１０時１５分２２秒と、その発生時間である２００２年１２月２日１０時１５分２０秒との差である２秒となる。さらに２００２年１２月２日１０時１５分２３秒のレコードは、組み込み機器３１が遷移状態Ｄにおかれたことを示すものである。
【００６３】
このレコードによって、それまで続いていた組み込み機器３１の遷移状態Ｂが終了したことが示されるので、遷移状態Ａの場合と同様に発生時間との差を算出して、持続時間が２秒となる。またこのレコードは同時に、遷移状態Ａ＋Ｂが終了したことを示すものでもある。そこで、遷移状態Ａ＋Ｂについても、発生時間との差を算出して持続時間が１秒となる。
【００６４】
また、ログファイル中には大量のレコードが出力され、各遷移状態の組み合わせが複数個検出されることになるが、稼働状況マイニング手段１８は、それぞれの遷移状態の組み合わせごとに、各持続時間の平均値とばらつきを算出する。そして、稼働状況マイニング手段１８は、算出した各遷移状態の組み合わせごとの持続時間とそのばらつきについて、組み合わせた遷移状態の個数に応じて重み付けを行う。これは遷移状態Ａと遷移状態Ａ＋Ｂとの持続時間を単純に比較すると、必ず遷移状態Ａの持続時間が長くなるからである。重み付けの方法としては、組み合わせる遷移状態の個数に応じて、定数を乗じていくというような単純な方法も考えられる。例えば、遷移状態の個数をＳとした場合に、定数をＣとして、得られた持続時間ＴにＣ^Ｓ−１（ただしＣ＞１）を乗じた値Ｃ^Ｓ−１Ｔを最終的な持続時間として出力する方法である。あるいは、所定の周期のうち、各遷移状態が占めている時間の割合に基づいて算出した係数を遷移状態の持続時間に乗じていく方法を用いてもよい。
【００６５】
次に、ステップＳ３０４において、更新時間帯算出手段１７は、更新可能時間帯の算出を行う。ここでは予めオペレータ等が開発環境あるいはテスト環境において、組み込み機器に配布しようとしているソフトウェアの配布および更新に要する時間を測定しておき、その時間（以下、単に更新時間という）を更新可能時間帯に与えておくものとする。更新時間帯算出手段１７は、ステップＳ３０３で求めた各遷移状態の持続時間の平均値とばらつきから、各遷移状態の持続時間の最小時間を算出する。次にこの最小時間と更新時間を比較し、更新時間よりも長い最小時間を有する遷移状態を選択して特定する。
【００６６】
ここで、最小時間の算出方法について説明する。最小時間は、遷移状態の持続時間の平均値およびばらつきに基づいて決定される。前述したとおり、ばらつきとは持続時間の分散の度合いを示すものである。最も簡単なばらつきの算出方法は、ある遷移状態の持続時間の最小値と持続時間の平均値の差（持続時間の平均値−持続時間の最小値）を算出する方法である。
【００６７】
また、このような方法を採用した場合には、持続時間の平均値より、ばらつきの値を減じた値（持続時間の平均値−ばらつき）を最小時間として算出してもよい。また、統計的な手法を用いて最小時間を算出してもよい。例えば、ある遷移状態に関する持続時間の全標本に基づいて、９５％の信頼区間や９９％の信頼区間などの推定を行い、最小時間を推定するような方法や、Ｔ分布などの特定の分布モデルを採用して最小時間を算出するような方法など、周知の統計的方法を用いてもよい。
【００６８】
一方、更新時間については、次のようなことを考慮する必要がある。すなわち、実施の形態３では、複数の組み込み機器にソフトウェアを配布する必要があるという点である。そこで、更新時間をソフトウェアのプログラム実行ファイルをファイル転送するための時間（以下、転送時間Ｔ_Ｔという）と、各組み込み機器においてそのプログラム実行ファイルを適用するための時間（以下、適用時間Ｔ_Ａという）に分けて考える。そうすると、更新時間をＴとした場合、テスト環境ではＴ＝Ｔ_Ｔ＋Ｔ_Ａの関係が成立する。ところが、多数の組み込み機器にソフトウェアを配布する場合、Ｔ_Ａについてはテスト環境とほぼ同じ値となるのに対して、Ｔ_Ｔは配布対象となる組み込み機器の台数によって変動する。これは、サーバ１１の負荷およびネットワーク１０の伝送能力の制限によるものである。サーバ１１の性能とネットワーク１０の帯域幅が十分に確保できる場合には、多数の組み込み機器に実際にソフトウェア配布を行う場合であっても、ファイル転送処理を並列に実行することによって、ファイル転送に要する時間はほぼＴ_Ｔに近い値となるものと考えられる。またサーバ１１の性能とネットワーク１０の帯域幅が低い場合には、組み込み機器の台数をＮとするとファイル転送に要する時間はＮ×Ｔ_Ａに近づく。
【００６９】
そこで実施の形態３では、ファイル転送をいわゆるステージ実行あるいは段階実行と呼ばれる方式で処理することとする。ステージ実行あるいは段階実行とは、配布対象となる組み込み機器を所定の台数ずつに分類して、それぞれのグループごとに並列にファイル転送を行う方式である。各グループの台数は、サーバ１１の処理能力およびネットワーク１０の伝送能力に依存する。ここで、グループの数をＭとし、各グループにおけるファイル転送時間（そのグループに属する組み込み機器全てにファイル転送を行い完了するまでの時間）をＴ_Ｋとする（ただし、Ｋ＝１，２，…，Ｍ）。すると各グループ毎の更新時間はＴ_Ｋ＋Ｔ_Ａとなる。更新時間帯算出手段１７は、各グループごとに最小時間がＴ_Ｋ＋Ｔ_Ａよりも大きい遷移状態の組み合わせを求める。
【００７０】
次に、ステップＳ３０５においてソフトウェア配信手段１４は、更新可能イベントが到来し、すなわちステップＳ３０４で求めたソフトウェア配信処理を開始しうる遷移状態に組み込み機器がおかれたことを検出して、ソフトウェアの配信に要する時間を求める。更新可能イベントはステージ実行の各グループごとに待機することとし、ソフトウェアの配信はこれらのグループごとに実行する。
【００７１】
続いて、ステップＳ３０６において、ソフトウェア更新手段５はサーバ１１より配布されたプログラム実行ファイルを組み込み機器１に適用する。プログラム実行ファイルの適用処理以降の処理については実施の形態１及び実施の形態２で説明した方法と同じ方法を用いるので、説明を省略する。
【００７２】
以上より明らかなように、実施の形態３による組み込み機器用ソフトウェア管理装置と組み込み機器用ソフトウェア管理サーバによれば、複数の組み込み機器に対するソフトウェア配布処理の開始時間を各組み込み機器の遷移状態に基づいて決定することができる。
【００７３】
さらに、実施の形態３による組み込み機器用ソフトウェア管理装置と組み込み機器用ソフトウェア管理サーバによれば、各組み込み機器の遷移状態の組み合わせも考慮してソフトウェア配布処理の開始時間を決定するので、複数の組み込み機器が協調して単一の機能を実現するようなシステムにおいても、ソフトウエア配布時間を適切に決定することができるという効果を奏する。
【００７４】
なお、上記の説明においては、ステージ実行の各グループに属する組み込み機器と各遷移状態をとる組み込み機器との関係については言及しなかったが、この関係を考慮して遷移状態の組み合わせを決定することも当然に可能である。例えば、組み込み機器１が遷移状態Ａにある途中で、組み込み機器３１が遷移状態Ｂに変化したとしても、遷移状態Ａの時間長さが更新時間に比べて十分に長いのであれば、組み込み機器１に対してはソフトウェアの配布処理を開始できる。このような処理を実現するには、ステージ実行の各グループに含まれる全ての組み込み機器の遷移状態の組み合わせの持続時間とばらつきを優先的に抽出するような構成をとればよい。
【００７５】
【発明の効果】
本発明は、組み込み機器の稼働状況に基づいてソフトウェアの配布処理を行う時間を動的に決定する構成としたので、組み込み機器のソフトウェアメンテナンスに要する運用負荷を軽減し、またメンテナンスを容易に行えることを通じて、ソフトウェアのアップデートによりバグの少ないソフトウェアを採用しやすくなる結果、システム全体の信頼性を向上させることができる、という効果を奏するものである。
【図面の簡単な説明】
【図１】本発明の実施の形態１における組み込み機器及び組み込み機器用ソフトウェア管理サーバの構成図である。
【図２】本発明の実施の形態１におけるソフトウェア配布処理のフローチャートである。
【図３】本発明の実施の形態２における組み込み機器及び組み込み機器用ソフトウェア管理サーバの構成図である。
【図４】本発明の実施の形態２におけるソフトウェア配布処理のフローチャートである。
【図５】本発明の実施の形態２におけるイベント履歴情報の構成を示す構成図である。
【図６】本発明の実施の形態２における遷移状態と持続時間の平均値の処理を説明するための説明図である。
【図７】本発明の実施の形態２におけるイベント処理の例を示す説明図である。
【図８】本発明の実施の形態２におけるイベント処理の例を示す説明図である。
【図９】本発明の実施の形態３における組み込み機器及び組み込み機器用ソフトウェア管理サーバの構成図である。
【図１０】本発明の実施の形態３におけるソフトウェア配布処理のフローチャートである。
【図１１】本発明の実施の形態３におけるログファイルの構成例を示す説明図である。
【図１２】本発明の実施の形態３における遷移状態の算出方法を示す説明図である。
【符号の説明】
１：組み込み機器
２：ソフトウェア管理装置
３：通信手段
４：ソフトウェア取得手段
５：ソフトウェア更新手段
６：状況監視手段
７：更新制御手段
８：イベント源
１０：ネットワーク
１１：組み込み機器用ソフトウェア管理サーバ
１２：通信手段
１３：通知手段
１４：ソフトウェア配信手段
１５：記憶装置
１６：稼働状況取得手段
１７：更新時間帯算出手段
１８：稼働状況マイニング手段

Claims

サーバよりネットワークを介して送信されたソフトウェアを受信して組み込み機器に適用するソフトウェア管理装置であって、
上記ソフトウェア管理装置は、
上記サーバより上記ソフトウェアを取得するソフトウェア取得手段と、
上記ソフトウェアを上記組み込み機器に適用するソフトウェア更新手段と、
上記組み込み機器の稼働状況を取得して上記ソフトウェアの更新に適する時間帯を算出する状況監視手段と、
上記時間帯に基づいて、上記ソフトウェア取得手段に上記ソフトウェアの取得を指示し、さらに上記ソフトウェア更新手段に上記ソフトウェア取得手段により取得した上記ソフトウェアの上記組み込み機器への適用を指示する更新制御手段と、
を備えることを特徴とするソフトウェア管理装置。
前記状況監視手段は、前記組み込み機器のＣＰＵの負荷状況を所定の周期ごとに取得し、上記負荷状況に基づいて上記ソフトウェアの更新に適する時間帯を算出することを特徴とする請求項１に記載されたソフトウェア管理装置。
前記状況監視手段は、前記組み込み機器の遷移状態の持続時間を取得し、前記ソフトウェアの更新に要する時間よりも持続時間の長い上記組み込み機器の遷移状態を選択して、上記組み込み機器が次に上記遷移状態に達する時間に開始する時間帯を上記ソフトウェアの更新に適する時間帯として算出することを特徴とする請求項１に記載されたソフトウェア管理装置。
前記更新制御手段は、前記時間帯の到来により、前記ソフトウェア取得手段に前記ソフトウェアの取得を指示することを特徴とする請求項１乃至請求項３のいずれか一に記載されたソフトウェア管理装置。
組み込み装置にソフトウェアを適用するソフトウェア管理装置にネットワークを介して上記ソフトウェアを送信するソフトウェア管理サーバであって、
上記ソフトウェア管理サーバは、
上記ソフトウェアと上記組み込み機器の稼働状況履歴とを記憶する記憶装置と、
上記ソフトウェア管理装置から送信される上記組み込み装置の稼働状況を受信し、上記稼働状況履歴に記録する稼働状況取得手段と、
上記稼働状況履歴に基づいて、上記ソフトウェアを上記組み込み機器に適用する時間帯を算出する更新時間帯算出手段と、
上記時間帯に基づいて、上記ソフトウェア管理装置に、上記記憶装置が記憶するソフトウェアを上記通信手段を介して送信するソフトウェア配信手段と、を備えることを特徴とするソフトウェア管理サーバ。
前記稼働状況取得手段は、前記ソフトウェア管理装置が所定の周期ごとに前記組み込み機器から取得し送信する該組み込み機器のＣＰＵの負荷状況を受信して、前記稼働状況履歴に記録し、
前記更新時間帯算出手段は、稼働状況履歴に記録された上記組み込み機器のＣＰＵの負荷状況に基づいて前記時間帯を算出することを特徴とする請求項５に記載されたソフトウェア管理サーバ。
前記稼働状況取得手段は、前記ソフトウェア管理装置が前記組み込み機器から取得し送信する該組み込み機器の遷移状態を受信して、前記稼働状況履歴に記録し、
前記更新時間帯算出手段は、上記稼働状況履歴に記録された持続時間が、前記ソフトウェアの更新に要する時間よりも長い上記組み込み機器の遷移状態を選択し、上記組み込み機器が次に上記遷移状態に達する時間に開始する時間帯を上記ソフトウェアの更新に適する時間帯として算出することを特徴とする請求項５に記載されたソフトウェア管理サーバ。
前記稼働状況履歴に記録された遷移状態の各組み合わせについて持続時間とばらつきを算出する稼働状況マイニング手段をさらに備え、
前記稼働状況取得手段は、上記稼働状況マイニング手段の算出した上記遷移状態の各組み合わせについての持続時間とばらつきに基づいて、上記遷移状態の各組み合わせの持続時間の最小値を算出し、該最小値が前記ソフトウェアの更新に要する時間よりも長い遷移状態の組み合わせを特定して、上記組み込み機器が該遷移状態の組み合わせに達する時間に開始する時間帯を上記ソフトウェアの更新に適する時間帯として算出することを特徴とする請求項５に記載されたソフトウェア管理サーバ。
前記通信手段を介して、前記ソフトウェア管理装置に前記更新時間帯算出手段が算出した時間帯を通知し、前記ソフトウェア管理装置に上記時間帯の到来とともに前記ソフトウェアを前記組み込み機器に適用させる通知手段をさらに備え、
前記ソフトウエア配信手段は、上記時間帯の到来以前に上記管理装置に上記ソフトウェアの送信を行うことを特徴とする請求項５乃至請求項８のいずれか一に記載したソフトウェア管理サーバ。