JP2004157767A - ソフトウェア更新システム - Google Patents

Abstract

【課題】従来、デバイスドライバの更新期間中の間、アプリケーションの処理が停止してしまうという課題があった。
【解決手段】最新バージョンのブートローダを保存する更新作業用端末１００と、制御対象機器３０を無停止で制御する更新対象装置２００とを備える。また、前記更新対象装置は、ブートローダの実行領域である第１及び第２のブートローダ領域３１、３２と、前記第１及び第２のブートローダ領域に対応した更新情報を持つブートローダ管理テーブル３３と、前記更新作業用端末からダウンロードした最新バージョンのブートローダを、前記ブートローダ管理テーブルを参照し前記更新情報に基づいて前回更新していないブートローダ領域に更新するブートローダ管理部４１とを有する。
【効果】停止させることが許されない更新対象装置を停止させることなく、更新対象装置のブートローダ等を更新することが可能になる。
【選択図】 図６

Description

【０００１】
【発明の属する技術分野】
この発明は、各種の制御装置などに搭載されるブートローダ、デバイスドライバ、アプリケーションなどのソフトウェアの更新をその装置を停止させることなく、動作中に行うソフトウェア更新システムに関するものである。
【０００２】
【従来の技術】
従来のソフトウェア更新システムは、更新を行うデバイスドライバモジュールが制御する周辺装置の稼動状況を監視することで前記デバイスドライバモジュールを安全に置換可能なタイミングを検出し、該タイミング検出後、前記デバイスドライバモジュール置換中は、デバイスドライバモジュールに対する入出力リクエストをエラーさせることなくペンディング状態に設定し、前記デバイスドライバモジュールの置換完了後に、ペンディング状態の入出力リクエストの処理から再開する（例えば、特許文献１参照）。
【０００３】
また、他の従来のソフトウェア更新システムは、旧ドライバを新ドライバに切替える場合には、共通制御部により、新ドライバをロードして初期設定し、運用中の旧ドライバで管理されている入出力装置を旧ドライバから切り離して、新ドライバ経由での運用に移行させる（例えば、特許文献２参照）。
【０００４】
【特許文献１】
特開平１１−２０３１２０号公報（第３頁−第５頁、図１）
【特許文献２】
特開平０８−０６９４３０号公報（第３頁−第６頁、図１）
【０００５】
【発明が解決しようとする課題】
上述したような従来のソフトウェア更新システムでは、デバイスドライバの動作中の更新を可能とする方式であるが、この方式では実際の処理中にアプリケーションからのデバイスドライバに対する要求をペンディングしているため、実質的にはデバイスドライバの更新期間中の間、アプリケーションの処理が停止してしまう。また、デバイスドライバの更新が終わり、再度処理を開始したときに、更新したデバイスドライバに問題があり動作しない場合に、復旧するために再度、更新前のデバイスドライバに戻す必要がでてくる。この場合、更新前のデバイスドライバがなければ、装置を復旧させることができないという問題点があった。
【０００６】
また、他の従来のソフトウェア更新システムは、更新時に旧ドライバを残しておき、旧ドライバを動作させながら、新ドライバヘ段階的に処理を移行することで、更新時にドライバの動作を停止させずに、ドライバの更新を可能としている。また、旧ドライバを一時保存しておくことで、新ドライバが異常であることをアプリケーションが検出し、旧ドライバでの復旧を要求することで、旧ドライバでの処理の復帰が可能であるようにしている。しかし、アプリケーションによりデバイスドライバが正常に動作しているかを判定したりするなどのデバイスドライバの管理などを行う必要があるため、アプリケーションに特別な処理が必要になるという問題点があった。
【０００７】
さらに、以上述べた２つの従来のソフトウェア更新システムでは、デバイスドライバの更新についてのみ対応しており、アプリケーション自身の更新には対応していないため、アプリケーションの比重が大きく、アプリケーションに更新が集中するような場合には、結局、装置を停止した後、更新を行い、再度装置を立ち上げなければならないという問題点があった。
【０００８】
この発明は、前述した問題点を解決するためになされたもので、ソフトウェアのうち、ブートローダ、デバイスドライバ、アプリケーションのそれぞれにおいて、装置の動作を停止させることなく、更新を実施し、もし正常に動作しなければ、更新前のソフトウェアで自動的に復旧させることができ、ソフトウェアの更新時にも動作を停止させる必要がなく、停止することが許されないような分野に装置を適用することができるソフトウェア更新システムを得ることを目的とする。
【０００９】
【課題を解決するための手段】
この発明に係るソフトウェア更新システムは、最新バージョンのブートローダを保存する更新作業用端末と、制御対象機器を無停止で制御する更新対象装置とを備える。また、前記更新対象装置は、ブートローダの実行領域である第１及び第２のブートローダ領域と、前記第１及び第２のブートローダ領域に対応した更新情報を持つブートローダ管理テーブルと、前記更新作業用端末からダウンロードした最新バージョンのブートローダを、前記ブートローダ管理テーブルを参照し前記更新情報に基づいて前回更新していないブートローダ領域に更新するブートローダ管理部とを有する。
【００１０】
【発明の実施の形態】
実施の形態１．
この発明の実施の形態１に係るソフトウェア更新システムのブートローダ更新処理について図面を参照しながら説明する。図１は、この発明の実施の形態１に係るソフトウェア更新システムの対象となるシステムのハードウエア構成を示す図である。なお、各図中、同一符号は同一又は相当部分を示す。
【００１１】
図１において、パソコンなどのソフトウェア更新作業用端末１００は、ネットワーク４００などにより、ＣＰＵ等を有する制御装置などのソフトウェア更新対象装置２００に接続されている。ここで、ネットワーク４００は、ソフトウェアの更新に必要なファイル転送機能などを備えている。また、ソフトウェア更新対象装置２００は、モータなどの制御対象機器３００に対して、制御を行い、その制御は、非常に重要で、かつ常に行われているため、ソフトウェア更新対象装置２００を停止させることは許されないものとする。
【００１２】
図２は、この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新作業用端末とソフトウェア更新対象装置の動作を示す図である。
【００１３】
また、図３は、この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新作業用端末からソフトウェア更新対象装置へ送られる送信データの構成を示す図である。
【００１４】
ソフトウェア更新作業用端末１００は、図２に示すように、最新のバージョンなどの更新対象のソフトウェアをハードディスク装置（ＨＤ）１２にファイルとして保存している。このファイルをソフトウェア更新対象装置２００に送付する際には、インストーラ１１が、図３に示すように、送信データにタイプ（Ｔｙｐｅ）フィールドを付加して送信を行う。なお、通信については、イーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））などのＬＡＮやＲＳ２３２Ｃなどのシリアルなどを想定している。
【００１５】
ソフトウェアの更新作業を行う作業者は、ソフトウェア更新作業用端末１００のインストーラ１１に対して、送信するファイル名称及び送信する種別（ブートローダ、デバイスドライバ、アプリケーション）を指定して送信を行う。インストーラ１１は、指定されたファイルを読み込み、指定された種別のタイプ（Ｔｙｐｅ）フィールドを付加して、ソフトウェア更新対象装置２００にデータを送信する。なお、図３に示す送信データのＳフィールド、Ｅフィールドは、通信媒体（Ｅｔｈｅｒｎｅｔ（登録商標）やシリアルなど）の形態に応じて付加されるものである。
【００１６】
データを受信したソフトウェア更新対象装置２００は、タイプ（Ｔｙｐｅ）フィールドをチェックし、受信したデータが、ブートローダなのか、デバイスドライバなのか、アプリケーションなのかを種別判定プログラム（図示せず）により判定し、それぞれインストール処理を行う。
【００１７】
図４は、図１で示したソフトウェア更新対象装置２００に搭載されるソフトウェア構成を示す図である。
【００１８】
図４において、ソフトウェア更新対象装置２００は、初期化コード（プログラム）２と、ブートローダ３と、オペレーティングシステム４と、デバイスドライバ５と、アプリケーション６とを有する。ここで、ブートローダ３は、２つの領域を持ち、それぞれブートローダ領域＃１（３１）、ブートローダ領域＃２（３２）とする。また、デバイスドライバ５も同様に、デバイスドライバ領域＃１（５１）、デバイスドライバ領域＃２（５２）を持つ。さらに、アプリケーション６についても、アプリケーション領域＃１（６１）とアプリケーション領域＃２（６２）からなるものとする。なお、デバイスドライバ５、アプリケーション６は複数あるが、図示は省略している。
【００１９】
図５は、図１で示したソフトウェア更新対象装置２００に搭載されるソフトウェア構成を示す図である。
【００２０】
図５において、ソフトウェア更新対象装置２００は、ブートローダ更新プログラム７をさらに有する。また、オペレーティングシステム４は、ブートローダ管理部４１を有する。
【００２１】
つぎに、この実施の形態１に係るソフトウェア更新システムの更新動作について図面を参照しながら説明する。
【００２２】
図６は、この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【００２３】
図１に示されたソフトウェア更新作業用端末１００から、ネットワーク４００経由でソフトウェア更新対象装置２００のブートローダ３の更新を行う場合には、種別判定プログラムの判定に基づいて、ブートローダ更新プログラム７が、その要求を受け取る。
【００２４】
要求を受け取ったブートローダ更新プログラム７は、オペレーティングシステム４に対して、ブートローダ３の更新要求を発行する。オペレーティングシステム４の内部に含まれるブートローダ管理部４１は、受け取ったブートローダ３の更新要求に基づいて、ブートローダ３の領域を更新する。その際、２つあるブートローダ領域３１、３２のうち、前回更新した領域に対して更新を行うのではなく、それ以前の領域に対して更新を行う。
【００２５】
すなわち、ブートローダ管理部４１が更新要求を受け付け、領域を更新する際には、交互にブートローダの領域を更新することになる。
【００２６】
図６は、ブートローダ管理部が交互に領域を更新する際の動作について示している。ブートローダ３の領域には、ブートローダ３のプログラムが保存される領域に加えて、それらを管理するブートローダ管理テーブル３３があり、このブートローダ管理テーブル３３には、次に更新するべきブートローダ領域を示すフラグと、ブートローダが保存されるアドレスが記録されている。
【００２７】
例えば、＃１側の領域のフラグが０で、＃２側の領域のフラグが１という値を示しているとすると、ブートローダ更新要求を受け取ったブートローダ管理部４１は、フラグが０である＃１に対して、ブートローダの更新を行い、更新完了後、＃１のフラグを１にセットし、＃２のフラグを０にセットする。その後さらに、ブートローダ更新要求がきた場合には、０にフラグがセットされている＃２の領域のブートローダが更新される。
【００２８】
従って、停止させることが許されないソフトウェア更新対象装置２００を停止させることなく、ソフトウェア更新対象装置２００のブートローダ３を更新することが可能になる。
【００２９】
実施の形態２．
この発明の実施の形態２に係るソフトウェア更新システムのブートローダ更新の異常処理について図面を参照しながら説明する。図７は、この発明の実施の形態２に係るソフトウェア更新システムの動作を示す図である。
【００３０】
この実施の形態２は、上記の実施の形態１で更新されたブートローダ３が正常に動作しなかった場合に自動的に復旧する方式であり、以下図７に基づいて、この実施の形態２の方式について説明する。
【００３１】
初期化コード（プログラム）２は、装置の電源投入、リセットなどにより実行を開始し、ブートローダ管理テーブル３３を参照し、どちらのブートローダ３を起動するかを判定する。
【００３２】
図７の例では、＃１のフラグが１となっているため、初期化コード（プログラム）２は、＃１の領域のブートローダ３１を起動する。同時に、ブートローダ監視タイマ３４を起動する。ここで、このブートローダ監視タイマ３４には、タイムアップしたときに起動されるタイマハンドラ３５を設定しておく。ブートローダ監視タイマ３４は、設定された時間になると、タイマハンドラ３５を起動するが、ブートローダ３によりリセットし、そのカウントを停止することができる。
【００３３】
起動されたブートローダ３１は、オペレーティングシステム４を起動し、その起動を完了したときに、ブートローダ３１の動作が完了したとして、ブートローダ監視タイマ３４をリセットする。
【００３４】
もし、ブートローダ３１に問題があり、オペレーティングシステム４のブート処理ができなかった場合には、ブートローダ監視タイマ３４をリセットすることができないため、ブートローダ監視タイマ３４がタイムアップし、タイマハンドラ３５が起動される。
【００３５】
このタイマハンドラ３５は、正常に装置を復帰させるため、ブートローダ管理テーブル３３のフラグをチェックし、ブートローダ３１の１にセットされているフラグを０にセットし、ブートローダ３２の０にセットされているフラグを１にセットし直して、装置のリセットを行う。
【００３６】
装置がリセットされると再び、初期化コード２から処理が再開されるが、ブートローダ管理テーブル３３が、タイマハンドラ３５によって書き換えられているため、前回起動に失敗したブートローダ＃１ではなく、ブートローダ＃２によって、ブート処理が行われ、正常にオペレーティングシステム４のブート処理が行われる。
【００３７】
ブートローダ監視タイマ３４に設定される値は、ブートローダ３がオペレーティングシステム４を起動できる時間を考慮した値を設定する必要がある。
【００３８】
従って、更新後のブートローダが正常に動作しなかった場合でも、更新前のブートローダで自動的に処理を復旧させることができるため、信頼のできるブートローダの更新をすることができる。
【００３９】
実施の形態３．
この発明の実施の形態３に係るソフトウェア更新システムのデバイスドライバ更新処理について図面を参照しながら説明する。図８は、この発明の実施の形態３に係るソフトウェア更新システムの動作を示す図である。
【００４０】
オペレーティングシステム４は、図８に示すように、デバイスドライバ管理テーブル４２Ａを持ち、各デバイスドライバ管理テーブルのエントリは、１つのデバイスドライバに対応するものとする。
【００４１】
図９では、アプリケーション６からデバイスドライバ５がどのように呼び出されるかを示している。
【００４２】
ここでは、アプリケーション６１のメインルーチン６１２が、デバイスドライバ５２の機能の１つに該当するルーチンを呼び出す様子を示している。アプリケーション６１がデバイスドライバ５２を呼び出す際には、その機能番号（デバイスドライバ管理テーブル４２Ａの左端欄）で呼び出すようにする。この機能番号により、呼び出される際、オペレーティングシステム４はデバイスドライバ管理テーブル４２Ａに従い、そのエントリのフラグを参照し、有効なフラグがセットされたエントリからそのコール（Ｃａｌｌ）先のアドレスを得る。
【００４３】
オペレーティングシステム４は、該当するサブルーチンをコールするが、同様にサブルーチンの処理を監視するためのタイマ４３を起動する。また、このタイマ４３には設定された時間を越えた場合にコールされるタイマハンドラ４４が設定されている。
【００４４】
図１０は、この発明の実施の形態３に係るソフトウェア更新システムのデバイスドライバの更新動作を示す図である。
【００４５】
図１に示されたソフトウェア更新作業用端末１００から、ネットワーク４００経由でソフトウェア更新対象装置２００のデバイスドライバ５の更新を行う場合には、種別判定プログラムの判定に基づいて、デバイスドライバ更新プログラム８が、その要求を受け取る。
【００４６】
要求を受け取ったデバイスドライバ更新プログラム８は、オペレーティングシステム４に対して、デバイスドライバ５の更新要求を発行する。オペレーティングシステム４の内部に含まれるデバイスドライバ管理部（図示せず）は、受け取ったデバイスドライバ５の更新要求に基づいて、デバイスドライバ５の領域を更新する。その際、２つあるデバイスドライバ領域５１、５２のうち、前回更新した領域に対して更新を行うのではなく、それ以前の領域に対して更新を行う。
【００４７】
すなわち、デバイスドライバ管理部が更新要求を受け付け、領域を更新する際には、交互にデバイスドライバの領域を更新することになる。
【００４８】
デバイスドライバ５の更新を実施した場合には、デバイスドライバ管理部は、デバイスドライバ管理テーブル４２Ａの各デバイスドライバのエントリを参照し、無効な領域（フラグが０）に対して更新を行った後、対応するフラグを有効にセット（１）し、反対側の領域のフラグを無効にセット（０）する。なお、デバイスドライバ５の更新は、ルーチン（機能）毎にでも実施できる。
【００４９】
オペレーティングシステム４は、アプリケーション６からデバイスドライバ５の呼び出しがある度にデバイスドライバ管理テーブル４２Ａのフラグを参照し、最新のルーチンをコールするため、任意のタイミングでデバイスドライバ５の入れ替えを行うことが可能である。
【００５０】
従って、装置を停止させることなくデバイスドライバ５の更新を可能とするため、装置の稼動中に装置のデバイスに依存する処理部分を更新することが可能になる。デバイスドライバ５の更新により、装置のソフトウェアを全く停止することがないため、停止させることが許されない装置でデバイスの制御処理などを変更することが可能になる。
【００５１】
実施の形態４．
この発明の実施の形態４に係るソフトウェア更新システムのデバイスドライバ更新の異常処理について図面を参照しながら説明する。
【００５２】
この実施の形態４は、上記の実施の形態３で更新されたデバイスドライバ５が正常に動作しなかった場合に自動的に復旧する方式であり、以下図９に基づいて、この実施の形態４の方式について説明する。
【００５３】
オペレーティングシステム４がアプリケーション６１からの要求に従い、デバイスドライバ５２のルーチンをコールする際には、タイマ４３をスタートさせる。このタイマ４３には、その設定値を越えた時間が経過した場合に、呼び出されるタイマハンドラ４４がセットされている。
【００５４】
ここでもしデバイスドライバ５２のサブルーチンに異常があり、オペレーティングシステム４から呼び出された後、一定時間を越えて処理が戻らなかった場合には、タイマハンドラ４４が起動され、異常処理が行われる。
【００５５】
このタイマハンドラ４４は、各デバイスドライバのエントリのうち、異常のあったルーチンのエントリのフラグの１を０へ、０を１ヘセットする。タイマハンドラ４４は、フラグの更新が完了した後、異常があった旨をオペレーティングシステム４に通知する。オペレーティングシステム４では、再度同一のデバイスドライバ５２のサブルーチン呼び出しを行う。このとき、タイマハンドラ４４により、該デバイスドライバの該ルーチンのフラグは書き換えられているため、再度呼び出されたときには、異常のあったデバイスドライバのルーチンではなく、前回更新された領域のデバイスドライバが呼び出され処理が再開される。
【００５６】
従って、装置を停止させることなくデバイスドライバの更新を可能とするため、装置の稼動中にデバイスに依存する処理部分を更新することが可能になる。また、デバイスドライバに異常があった場合でも、自動的に復旧できるため信頼のある更新が可能になる。
【００５７】
実施の形態５．
この発明の実施の形態５に係るソフトウェア更新システムのアプリケーション更新処理について図面を参照しながら説明する。図１１は、この発明の実施の形態５に係るソフトウェア更新システムの動作を示す図である。
【００５８】
図１１において、オペレーティングシステム４は、アプリケーション管理テーブル４５Ａを持ち、このアプリケーション管理テーブル４５Ａの１エントリは、１つのアプリケーションを指すものとする。アプリケーション６は、２つのアプリケーション領域を持ち、アプリケーションを更新する際には、交互に領域を更新する。
【００５９】
図１２では、アプリケーション管理テーブル４５Ａの１エントリの構造と、その参照動作（どのようにアプリケーション領域を参照しているか）を示している。
【００６０】
図１２において、１エントリは、それぞれのアプリケーションのメインルーチン、サブルーチン１、サブルーチン２を指している。なお、図１２では、簡略化するためサブルーチンが２つしかないアプリケーションの例を示しているが、サブルーチンの数については、適用される装置のアプリケーションの規模に応じて、適当な数に変更することができる。
【００６１】
アプリケーション管理テーブル４５Ａのエントリ４５１は、２つあるアプリケーション領域６１、６２に存在するアプリケーションのメインルーチン６１２、６２２、サブルーチン１（６１３、６２３）、サブルーチン２（６１４、６２４）をそれぞれ参照している。
【００６２】
図１に示されたソフトウェア更新作業用端末１００から、ネットワーク４００経由でソフトウェア更新対象装置２００のアプリケーション６の更新を行う場合には、種別判定プログラムの判定に基づいて、アプリケーション更新プログラム（図示せず）が、その要求を受け取る。
【００６３】
要求を受け取ったアプリケーション更新プログラムは、オペレーティングシステム４に対して、アプリケーション６の更新要求を発行する。オペレーティングシステム４の内部に含まれるアプリケーション管理部４５Ｂ（図１５参照）は、受け取ったアプリケーション６の更新要求に基づいて、アプリケーション６の領域を更新する。その際、２つあるアプリケーション領域６１、６２のうち、前回更新した領域に対して更新を行うのではなく、それ以前の領域に対して更新を行う。
【００６４】
すなわち、アプリケーション管理部が更新要求を受け付け、領域を更新する際には、交互にアプリケーションの領域を更新することになる。
【００６５】
アプリケーション６１の更新を実施する場合には、アプリケーション管理部４５Ｂは、アプリケーション６１が持つメインルーチン６１２、サブルーチン１（６１３）、サブルーチン２（６１４）の更新登録をアプリケーション管理テーブル４５Ａに対して行う。また、アプリケーションを構成するメインルーチン、サブルーチンについては、オペレーティングシステム４からコールされ、必ず一定時間で処理を終えた後、処理をオペレーティングシステム４に返すものでなければならない。
【００６６】
図１３は、アプリケーション管理テーブルの構造を示す図である。
【００６７】
図１３において、アプリケーションのエントリ４５１は、メインルーチン、サブルーチン１、サブルーチン２についてそれぞれの場所を参照するためのアドレスを持つが合わせて、エントリの内容が有効であるか無効であるかのフラグを持つ。このフラグの内容は、１が有効、０が無効とする。オペレーティングシステム４は、フラグの内容を見て、有効な方のルーチンに対して呼び出し処理を行う。
【００６８】
図１４は、オペレーティングシステムの動作を示す図である。
【００６９】
この図１４は、オペレーティングシステム４がどのように各ルーチンの呼び出しを行うかを示している。オペレーティングシステム４は、各アプリケーションのエントリから、メインルーチンを参照し呼び出しを行う。図中では、メインルーチン６１２を呼び出す。その際、同時に、タイマ４６をスタートする。このタイマ４６には、タイマハンドラ４８がセットされており、設定された時間が経過するとタイマハンドラ４８が起動されるようになっている。このタイマ４６は、リセットした場合には動作を停止させることができるようになっている。
【００７０】
呼び出されたメインルーチン６１２は、処理実行中に、サブルーチンコールをすることがあるが、直接サブルーチンコールをするのではなく、アプリケーション６１のエントリに含まれるサブルーチンを機能番号（アプリケーション管理テーブル４５Ａの左端欄）に従ってコールする。
【００７１】
ここでは、図１３で示された該アプリケーションエントリの２番を指定し、サブルーチン１をコールしたとする。オペレーティングシステム４は、アプリケーション６１からの要求に従い、サブルーチン１（６１３）をコールするときに、タイマ４７をスタートさせる。このタイマ４７は、タイマ４６とは独立した別のタイマである。このタイマ４７にも、タイマ４６と同様に、設定時間を経過したときに呼び出されるタイマハンドラ４８をセットしておく。
【００７２】
オペレーティングシステム４から呼び出されたサブルーチン１（６１３）は、処理完了後、オペレーティングシステム４ヘ処理を戻し、オペレーティングシステム４は、処理が戻ってきたときに、呼び出し時にスタートさせたタイマ４７をリセットする。
【００７３】
もしここで、サブルーチン１（６１３）に異常があり、オペレーティングシステム４に対して処理を返さない場合には、タイマ４７がタイムアップし、タイマハンドラ４８が呼び出される。このタイマハンドラ４８は、異常処理を実施するとともに、オペレーティングシステム４へ異常があったことを通知する。
【００７４】
ここでは、サブルーチン１（６１３）に異常がなく、正常に処理がオペレーティングシステム４ヘ戻ってきた場合を説明する。サブルーチンから処理が戻ってきた後、オペレーティングシステム４は、サブルーチンの呼び出し元であるメインルーチン６１２に対して、処理をリターンする。
【００７５】
処理を戻されたメインルーチン６１２は、その処理を完了したとして、最終的にオペレーティングシステム４に処理を返す。処理を戻されたオペレーティングシステム４は、メインルーチン６１２を呼び出した際に起動したタイマ４６をリセットする。
【００７６】
もし、メインルーチン６１２になんらかの異常があり、処理が一定時間を越えてもオペレーティングシステム４へ返らなかった場合には、タイマ４６がタイムアップし、タイマハンドラ４８が起動され、オペレーティングシステム４ヘタイマハンドラ４８が通知を行う。
【００７７】
アプリケーションの更新を行う際には、ネットワーク４００からダウンロードされたアプリケーションプログラムをアプリケーション領域６に更新することで行うことは、前述のとおりであるが、アプリケーション管理部４５Ｂは、更新処理を行ったタイミングで、図１３に示すエントリのフラグを更新し、更新された領域のフラグを１に、反対側の領域のフラグを０にセットする。各ルーチンの処理が終わった段階で常にオペレーティングシステム４に対して処理が返り、ルーチンを呼び出す際には、最新のフラグの状態に従い、有効なメインルーチン、サブルーチンを呼び出す形式のため、常に任意のタイミングでアプリケーションの更新が可能になる。ただし、アプリケーションは構成するルーチンの構造を変更することはできないようになっている。
【００７８】
従って、装置を停止させることなくアプリケーションを更新することが可能であるため、装置に搭載されたアプリケーションを更新し、装置の動作を変更する際などに、動作を停止させることなく更新を行うことができる。
【００７９】
実施の形態６．
この発明の実施の形態６に係るソフトウェア更新システムのアプリケーション更新の異常処理について図面を参照しながら説明する。図１５は、この発明の実施の形態６に係るソフトウェア更新システムの動作を示す図である。
【００８０】
この実施の形態６は、上記の実施の形態５で更新されたアプリケーション６が正常に動作しなかった場合に自動的に復旧する方式であり、以下図１５に基づいて、この実施の形態６の方式について説明する。
【００８１】
オペレーティングシステム４がアプリケーション６１のルーチンをコールする際には、上述したようにタイマ４６、４７をスタートさせる。これらのタイマ４６、４７には、その設定値を越えた時間が経過した場合に、呼び出されるタイマハンドラ４８がセットされている。
【００８２】
ここでもしアプリケーション６１のサブルーチンに異常があり、オペレーティングシステム４から呼び出された後、一定時間を越えて処理が戻らなかった場合には、タイマハンドラ４８が起動され、異常処理が行われる。
【００８３】
このタイマハンドラ４８は、各アプリケーションのエントリのうち、異常のあったルーチンのエントリのフラグの１を０へ、０を１ヘセットする。タイマハンドラ４８は、フラグの更新が完了した後、異常があった旨をオペレーティングシステム４に通知する。オペレーティングシステム４では、再度同一のアプリケーション６１のサブルーチン呼び出しを行う。このとき、タイマハンドラ４８により、該アプリケーションの該ルーチンのフラグは書き換えられているため、再度呼び出されたときには、異常のあったアプリケーションのルーチンではなく、前回更新された領域のアプリケーションが呼び出され処理が再開される。
【００８４】
オペレーティングシステム４は、呼び出したルーチンに異常があったことを認識した後、再度、該当エントリに基づき、同一のルーチンをコールするが、タイマハンドラ４８により、ルーチンのフラグが入れ替えられているため、異常終了したルーチンではなく、前回更新のルーチンにより再度呼び出しが行われるため、アプリケーション更新時に問題のあるルーチンが更新された場合でも、正常に復帰できるようになっている。
【００８５】
従って、更新後のアプリケーションに異常があり、正常に動作できなかった場合に、自動的に前回更新のバージョンのアプリケーションで処理を復旧するため、信頼のあるアプリケーションの更新が可能である。
【００８６】
実施の形態７．
この発明の実施の形態７に係るソフトウェア更新システムについて図面を参照しながら説明する。図１６は、この発明の実施の形態７に係るソフトウェア更新システムの構成を示す図である。
【００８７】
図１６において、ソフトウェア更新対象装置２００の全構成管理部９は、ブートローダ構成管理部４１０と、デバイスドライバ構成管理部４１１と、アプリケーション構成管理部４１２と連携して動作する。
【００８８】
例えば、アプリケーション構成管理部４１２は、装置にインストールされた各アプリケーションのバージョン管理を行い、またそれらのアプリケーションの構成を全構成管理部９に伝える。ブートローダ構成管理部４１０、デバイスドライバ構成管理部４１１についても同様な階層構造をとる。
【００８９】
全構成管理部９は、ネットワーク４００を通じてサーバ（ソフトウェア更新作業用端末）５００に対してそれぞれのソフトウェアの最新バージョンに対して問い合わせを行う。サーバ５００は、各ソフトウェアの最新バージョンがなんであるかを全体構成管理部９に対して返し、全体構成管理部９は、各バージョンを比較した後、装置にインストールされているバージョンが古ければ、上記の実施の形態１、３、及び５に示された方法により、能動的にブートローダ、デバイスドライバ、アプリケーションの各バージョンアップを行う。
【００９０】
それぞれのバージョンの更新時になんらかの異常があった場合には、上記の実施の形態２、４、及び６の方法に従い、古いバージョンのソフトウェアによりただちに処理を復旧することが可能である。
【００９１】
すなわち、ブートローダ、デバイスドライバ、アプリケーションのソフトウェアの最新のバージョンがサーバ５００上に保存され、全構成管理部９がサーバ５００に対して定期的に各ソフトウェアの内容をチェックし、装置にインストールされているソフトウェアが古いものであれば、サーバ５００上のソフトウェアで自動的に更新することにより、常に装置のソフトウェア構成を最新の状態に保つものである。
【００９２】
従って、ソフトウェア更新対象装置２００は、自動的にサーバ５００に対して最新のバージョンのソフトウェアを問い合わせ、装置のソフトウェア構成を最新に保つことが可能になる。同一の装置が複数ある場合には、それぞれの装置のソフトウェアを更新する作業を装置が自動的に行うため、装置のバージョンアップを行う作業が大幅に軽減される。
【００９３】
【発明の効果】
この発明に係るソフトウェア更新システムは、以上説明したとおり、停止させることが許されないソフトウェア更新対象装置を停止させることなく、ソフトウェア更新対象装置のブートローダ等を更新することが可能になる。
【図面の簡単な説明】
【図１】この発明の実施の形態１に係るソフトウェア更新システムの対象となるシステムのハードウエア構成を示す図である。
【図２】この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新作業用端末とソフトウェア更新対象装置の動作を示す図である。
【図３】この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新作業用端末からソフトウェア更新対象装置へ送られる送信データの構成を示す図である。
【図４】この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新対象装置に搭載されるソフトウェア構成を示す図である。
【図５】この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新対象装置に搭載されるソフトウェア構成を示す図である。
【図６】この発明の実施の形態１に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図７】この発明の実施の形態２に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図８】この発明の実施の形態３に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図９】この発明の実施の形態３及び４に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１０】この発明の実施の形態３に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１１】この発明の実施の形態５に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１２】この発明の実施の形態５に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１３】この発明の実施の形態５に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１４】この発明の実施の形態５に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１５】この発明の実施の形態６に係るソフトウェア更新システムのソフトウェア更新対象装置の動作を示す図である。
【図１６】この発明の実施の形態７に係るソフトウェア更新システムの構成を示す図である。
【符号の説明】
２ 初期化コード（プログラム）、３ ブートローダ、４ オペレーティングシステム、５ デバイスドライバ、６ アプリケーション、７ ブートローダ更新プログラム、８ デバイスドライバ更新プログラム、９ 全構成管理部、１１インストーラ、１２ ハードディスク装置、３３ ブートローダ管理テーブル、３４ ブートローダ監視タイマ、３５ タイマハンドラ、４１ ブートローダ管理部、４２Ａ デバイスドライバ管理テーブル、４３ タイマ、４４ タイマハンドラ、４５Ａ アプリケーション管理テーブル、４５Ｂ アプリケーション管理部、４６ タイマ、４７ タイマ、４８ タイマハンドラ、１００ ソフトウェア更新作業用端末、２００ ソフトウェア更新対象装置、３００ 制御対象機器、４００ ネットワーク、４１０ ブートローダ構成管理部、４１１ デバイスドライバ構成管理部、４１２ アプリケーション構成管理部、５００ サーバ。

Claims (7)

1. 最新バージョンのブートローダを保存する更新作業用端末と、
   制御対象機器を無停止で制御する更新対象装置とを備え、
   前記更新対象装置は、
   ブートローダの実行領域である第１及び第２のブートローダ領域と、
   前記第１及び第２のブートローダ領域に対応した更新情報を持つブートローダ管理テーブルと、
   前記更新作業用端末からダウンロードした最新バージョンのブートローダを、前記ブートローダ管理テーブルを参照し前記更新情報に基づいて前回更新していないブートローダ領域に更新するブートローダ管理部と
   を有することを特徴とするソフトウェア更新システム。
2. 前記更新対象装置は、
   前記ブートローダ管理テーブルの更新情報に基づいて前記最新バージョンのブートローダが起動されると同時に起動され、前記最新バージョンのブートローダが正常に動作しない場合にはタイムアップとなるタイマと、
   前記タイマのタイムアップにより起動されると、前記ブートローダ管理テーブルの更新情報を今回の更新前の状態に戻すタイマハンドラと
   をさらに有することを特徴とする請求項１記載のソフトウェア更新システム。
3. 最新バージョンのデバイスドライバを保存する更新作業用端末と、
   制御対象機器を無停止で制御する更新対象装置とを備え、
   前記更新対象装置は、
   デバイスドライバの実行領域である第１及び第２のデバイスドライバ領域と、
   前記第１及び第２のデバイスドライバ領域に対応した更新情報を持つデバイスドライバ管理テーブルと、
   前記更新作業用端末からダウンロードした最新バージョンのデバイスドライバを、前記デバイスドライバ管理テーブルを参照し前記更新情報に基づいて前回更新していないデバイスドライバ領域に更新するデバイスドライバ管理部と
   を有することを特徴とするソフトウェア更新システム。
4. 前記更新対象装置は、
   前記デバイスドライバ管理テーブルの更新情報に基づいて前記最新バージョンのデバイスドライバが起動されると同時に起動され、前記最新バージョンのデバイスドライバが正常に動作しない場合にはタイムアップとなるタイマと、
   前記タイマのタイムアップにより起動されると、前記デバイスドライバ管理テーブルの更新情報を今回の更新前の状態に戻すタイマハンドラと
   をさらに有することを特徴とする請求項３記載のソフトウェア更新システム。
5. 最新バージョンのアプリケーションを保存する更新作業用端末と、
   制御対象機器を無停止で制御する更新対象装置とを備え、
   前記更新対象装置は、
   アプリケーションの実行領域である第１及び第２のアプリケーション領域と、
   前記第１及び第２のアプリケーション領域に対応した更新情報を持つアプリケーション管理テーブルと、
   前記更新作業用端末からダウンロードした最新バージョンのアプリケーションを、前記アプリケーション管理テーブルを参照し前記更新情報に基づいて前回更新していないアプリケーション領域に更新するアプリケーション管理部と
   を有することを特徴とするソフトウェア更新システム。
6. 前記更新対象装置は、
   前記アプリケーション管理テーブルの更新情報に基づいて前記最新バージョンのアプリケーションが起動されると同時に起動され、前記最新バージョンのアプリケーションが正常に動作しない場合にはタイムアップとなるタイマと、
   前記タイマのタイムアップにより起動されると、前記アプリケーション管理テーブルの更新情報を今回の更新前の状態に戻すタイマハンドラと
   をさらに有することを特徴とする請求項５記載のソフトウェア更新システム。
7. 前記更新対象装置は、
   前記更新作業用端末に対して最新バージョンに対して問い合わせを行い、インストールされているバージョンと比較し、前記インストールされているバージョンが古い場合には、能動的に前記最新バージョンを取得する全構成管理部
   をさらに有することを特徴とする請求項１から請求項６までのいずれかに記載のソフトウェア更新システム。

Images