JP2008293258A - リモートメンテナンスシステム - Google Patents

Abstract

【課題】
ある端末のソフトウェアを更新した以降は、他の端末でソフトウェアを更新しても正常に動作しなくなる事態を回避する。
【解決手段】
サーバ１１と複数の端末２１とをネットワークを介して接続し、サーバ１１のリモートアクセスにより、端末２１が有するソフトウェアを更新するリモートメンテナンスシステムにおけるソフトウェア更新の制御方法であって、第１の端末２１が有するソフトウェアを更新した後の動作状況を示す動作状況データを第１の端末２１から受信し、受信した動作状況データの動作状況に応じて、他の端末２１のソフトウェアを更新する制御を行う。
【選択図】図１

Description

本発明は、リモートメンテナンスシステムに係り、特に、サーバとネットワークに接続された端末に組み込まれたソフトウェアのバージョンに応じて該ソフトウェアを更新するリモートメンテナンスシステム、そのソフトウェア更新の制御方法及びサーバに関する。

ネットワークを介して複数の端末とサーバが接続されるシステムにおいて、端末またはサーバの各ファイルに対して自動で更新、削除及び追加する方法が考案されている。例えば、特許文献１には、端末の使用状態を取得しソフトウェアの更新の可否を判定する更新条件判定部と、更新条件判定部により更新可能と判定された端末に対してソフトウェアの更新を指示する更新制御部とを備えたソフトウェア自動更新装置により、非使用状態にある端末の抽出からソフトウェアの更新までを自動的に行うという技術が開示されている。

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

しかしながら、従来技術では、自動的にソフトウェアの更新はできるものの、更新後のソフトウェアが、必ずしも正常に動作するとは限らない。そのため、多くの端末にソフトウェア更新を行い、一斉に更新後のソフトウェアを起動した場合には、更新を行った端末全てが正常に動作しなくなるという最悪の状況も考えられ、その後の業務に支障をきたす。また、この場合、正常に動作しない多くの端末に復旧作業が必要となり、復旧に時間を要するという問題があった。

本発明の目的は、ある端末の更新後のソフトウェアが正常に動作しているか否かの動作状況を監視し、その動作状況に応じて他の端末にも反映させることで、他の端末が正常に動作しなくなる事態を回避することにある。

上記目的を達成するために、本発明のリモートメンテナンスシステムのソフトウェア更新の制御方法は、サーバと複数の端末とをネットワークを介して接続し、該サーバのリモートアクセスにより、該端末が有するソフトウェアを更新するリモートメンテナンスシステムにおけるソフトウェア更新の制御方法であって、第１の端末が有する該ソフトウェアを更新した後の動作状況を示す動作状況データを該第１の端末から受信し、受信した該動作状況データの動作状況に応じて、他の端末のソフトウェアを更新する制御を行うように構成することができる。

また、本発明のリモートメンテナンスシステムは、サーバと複数の端末とをネットワークを介して接続し、該サーバのリモートアクセスにより、該端末が有するソフトウェアを更新するリモートメンテナンスシステムであって、該端末は、該ソフトウェアの更新後の動作に関するログ情報に基づいて、更新後の該ソフトウェアが正常に動作しているか否かの動作状況を診断する診断プログラムを格納する記憶手段と、該診断プログラムが診断した結果である動作状況データを、該サーバ装置へ送信する通信手段とを有し、該サーバは、該端末の該動作状況データを該端末から受信する通信手段と、該端末から受信した該動作状況データを格納する記憶手段と、該記憶手段に格納された該動作状況データに基づいて該他の端末の該ソフトウェアを更新する制御を行う更新制御手段とを有するように構成することができる。

また、本発明のサーバは、端末とネットワークを介して接続され、該端末へのリモートアクセスにより、該端末が有するソフトウェアを更新するサーバであって、第１の端末が有する該ソフトウェアの更新後の動作状況を示す動作状況データを該第１の端末から受信する通信手段と、受信した該動作状況データの動作状況に応じて、該第１の端末以外の他の端末に対するソフトウェアの更新に関する更新処理データを記憶する記憶手段と、該記憶手段に記憶された該更新処理データに基づいて、該他の端末の該ソフトウェアを更新する制御を行う更新制御手段とを有するように構成することができる。

本発明によれば、ある端末の更新後のソフトウェアの動作状況を、他の端末にも反映させることにより、他の端末が正常に動作しなくなる事態を回避できる。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。
〔実施例１〕
まず、図１を参照して、本実施例に係るリモートメンテナンスシステムについて説明する。
図１は、ソフトウェア更新を制御するリモートメンテナンスシステム１００の構成例を示す図である。
リモートメンテナンスシステム１００は、サーバ１１、サーバ側ルータ４１、サーバ側ＬＡＮ１０、端末２１、支店側ルータ４２、支店側ＬＡＮ２０及びＷＡＮ２００から構成されている。ＷＡＮ２００とサーバ側ＬＡＮ１０、及びＷＡＮ２００と支店側ＬＡＮ２０との間にはそれぞれサーバ側ルータ４１、支店側ルータ４２が設けられており、ＷＡＮ−ＬＡＮ間のデータを中継する。サーバ側ＬＡＮ１０と支店側ＬＡＮ２０との間は直接接続されることはなく、ＷＡＮ２００を介して接続されている。ここで、サーバ側ＬＡＮ１０は、各拠点ごと、あるいは地域ごとに設ける構成としてもよい。サーバ側ＬＡＮ１０にはサーバ１１が、支店側ＬＡＮ２０には端末２１が接続されている。

図２は、サーバ１１の構成例を示す図である。
サーバ１１は、中央処理装置（ＣＰＵ）１３、入力部１４、出力部１５、ネットワークインタフェース（ＮＩＣ）１６及び記憶部１７から構成されている。ＣＰＵ１３は、サーバ１１の制御やデータの演算/加工を行う。演算/加工されたデータは、記憶部１７に記憶され、あるいは出力部１５に出力される。入力部１４は、例えばキーボード、マウスである。出力部１５は、ＣＰＵ１３がデータ演算/加工したデータを出力する。ＮＩＣ１６は、ネットワークインタフェースカードであり、サーバ１１をサーバ側ＬＡＮ１０に接続する。

記憶部１７は、配布ファイル１７１、配布先リスト１７２、ソフトウェア動作状況ファイル１７３、配布プログラム１７４、更新制御ファイル１７５及び異常発生台数ファイル１７６の各データを記憶する。

次に、各ファイルについて説明する。
配布ファイル１７１は、各端末２１に配布されるプログラムモジュールやデータ表等を記憶するファイルである。
配布先リスト１７２は、図３に示すように、端末識別番号５０及び拠点識別番号５１から構成されている。端末識別番号５０は、端末２１を識別するために付された数字、文字、記号を組み合わせた列であり、ユニークでなければならない。端末２１の識別番号が決まれば拠点の識別番号は一意に決まる。拠点識別番号５１は、端末２１が設置されている拠点を示す識別番号である。

ソフトウェア動作状況ファイル１７３は、端末２１から受信した、端末２１のソフトウェア動作状況を記録したファイルである。

配布プログラム１７４は、配布ファイル１７１を端末２１に配布し、また、ソフトウェア動作状況ファイル１７３に記録されているソフトウェア動作状況のデータに基づいて、端末２１のソフトウェア更新を制御するプログラムである。ソフトウェア更新の際のエラー発生時には、そのエラーの処理が更新制御ファイル１７５に記述されている場合、この記述された処理を実行する制御を行う。この配布プログラム１７４がＣＰＵ１３で実行されることによって、端末２１のソフトウェアを更新するためのソフトウェア更新制御手段３００が実現する。

異常発生台数ファイル１７６は、サーバ１１がリモートメンテナンスシステム１００のネットワークに接続された端末２１に対するソフトウェア更新処理中に、異常を検知した端末２１の台数を拠点ごとに集計した数を記録したファイルである。

図４及び図５を参照して、更新制御ファイル１７５を説明する。
図４に示すように、更新制御ファイル１７５は、拠点識別番号６０及び許容異常台数６１のフィールドから構成される。
許容異常台数６１は、サーバ１１が端末２１へのソフトウェア更新を中止する契機となる、更新後ソフトウェア動作が正常ではない端末２１の数を表す。更新後のソフトウェアの動作が正常でない端末２１の数が、更新制御ファイル１７５に記述されている許容異常台数６１を超えた場合、サーバはその拠点の端末２１に対して、以降のソフトウェア更新を実行しない。例えば、拠点Ｘの許容異常台数が０の場合、拠点Ｘの端末２１が１台でもソフトウェア更新後の動作が正常でないと通知されれば、サーバ１１はそれ以降、拠点Ｘの端末２１に対してソフトウェア更新を実行しない。

拠点識別番号６０は、拠点を識別するための数字、文字、記号を組み合わせた列であり、ユニークでなければならない。拠点識別番号６０のフィールドには、複数の拠点を示す識別番号を記述してもよく、例えば、全拠点を表す識別番号を記述してよい。これにより、例えば拠点Ｗと拠点Ｚの２拠点を併せた許容異常台数６１を４と記述することができ、この場合、拠点Ｗと拠点Ｚで併せて５台以上の端末２１が、サーバ１１へ更新後のソフトウェアの動作が正常でないと通知すれば、サーバ１１は以降、拠点Ｗ及び拠点Ｚの２拠点の端末２１に対してソフトウェア更新を実行しない。

図５に示すように、更新制御ファイル１７５は、各端末２１に対する更新処理中に発生したエラーに対し、サーバ１１が行う処理が記述されているファイルであり、端末識別番号７０及びエラー発生時の処理７１のフィールドから構成されている。

端末識別番号７０は、端末２１を識別するために付された数字、文字、記号を組み合わせた列であり、ユニークでなければならない。

エラー発生時の処理７１は、エラー発生の内容の項目ごとに、各端末２１がエラー発生時に処理すべき内容を記したフィールドである。例えば、端末Ｘ−００１の電源が投入されていなかった場合、サーバは処理Ａを行う。処理Ａとは、例えば、端末２１へ電源投入指令を送信後、再度ソフトウェア更新を試みる、または、端末２１へのソフトウェア更新は行わず、次の端末２１の処理へ移行する等である。また、処理Ａには、端末２１を異常台数にカウントするか否かの処理を含めてもよい。

図１０を参照して、異常発生台数ファイル１７６を説明する。
異常発生台数ファイル１７６は、拠点識別番号８０及び異常発生台数８１のフィールドから構成されている。拠点識別番号８０は、拠点を識別するための数字、文字、記号を組み合わせた列であり、ユニークでなければならない。異常発生台数８１は、サーバ１１がリモートメンテナンスシステム１００のネットワークに接続された端末２１に対するソフトウェア更新処理中に、異常を検知した端末２１の台数であり、拠点ごとに集計した数である。

図６は、端末２１の構成例を示す図である。
端末２１は、ＣＰＵ２３、入力部２４、出力部２５、ＮＩＣ２６及び記憶部２７から構成されている。ＣＰＵ２３は、端末２１の動作を制御する。入力部２４は、例えばキーボード、マウスである。出力部２５は、ＣＰＵ２３がデータ演算/加工した結果のデータを出力する。ＮＩＣ２６は、ネットワークインタフェースカードであり、端末２１を支店側ＬＡＮ２０に接続する。記憶部２７は、アプリケーションソフトウェア３１、ログファイル３２及び診断プログラム３３の各データを記憶する。

アプリケーションソフトウェア３１は、起動時および起動後のソフトウェアの動作状態をログファイル３２に出力する。

ログファイル３２は、アプリケーションソフトウェア３１により出力されたソフトウェアの動作ログを記録したファイルである。

診断プログラム３３は、アプリケーションソフトウェア３１が出力した動作ログをログファイル３２から取得し、取得した動作ログに基づいて更新したソフトウェアの動作状況を診断して、その結果をサーバ１１にルータ４２を介して通知する。

次に、サーバ１１が、端末２１のソフトウェア更新の制御をする手順について、図７から図９を参照しながら説明する。
図７から図９は、サーバ１１が配布先リスト１７２から次のソフトウェア更新対象となる端末２１の情報を取得した後、端末２１にソフトウェア更新を行い、端末２１からソフトウェア動作状況情報を受信してソフトウェア更新処理を続行するか否かを判断する動作を示すフローチャートである。特に、図９は、ソフトウェア更新の際のエラー発生時の動作を示すフローチャートである。

まず、サーバ１１のＣＰＵ１３は、異常発生台数ファイル１７６の全拠点に対する異常発生台数８１のフィールドを０にセットする（Ｓ１０１）。次に、記憶部１７の配布先リスト１７２から配布ファイル１７１の配布先を取得する（Ｓ１０２）。既に全ての端末２１に配布ファイル１７１を配布済みで、新たな配布先を取得できなかった場合（Ｓ１０３のＮ）、処理を終了する。配布先を取得できた場合（Ｓ１０３のＹ）、配布先である端末２１が更新可能な状態であるか否かの情報を取得する（Ｓ１０４）。端末２１がソフトウェア更新可能な状態でない（例えば端末の電源が投入されていない、更新対象のソフトウェアの前提バージョンが異なる等）場合（Ｓ１０５のＮ）、サーバ１１のＣＰＵ１３は後述のエラー処理を行う。一方、端末２１がソフトウェア更新可能である場合（Ｓ１０５のＹ）、サーバ１１のＣＰＵ１３は記憶部１７の配布ファイル１７１を端末２１へ送信する（Ｓ１０６）。

配布ファイル１７１のファイル配布が正常に終了しなかった場合（Ｓ１０７のＮ）、サーバ１１のＣＰＵ１３は後述のエラー処理を行う。

ファイル配布が正常に終了した場合（Ｓ１０７のＹ）、サーバ１１のＣＰＵ１３は端末２１からソフトウェアの更新後のソフトウェア動作状況が通知されるのを待つ（Ｓ１１０）。端末２１からソフトウェア動作状況が通知されずにタイムアウトした場合（Ｓ１１１）、後述のエラー処理を行う。タイムアウト前に端末２１からソフトウェア動作状況が通知された場合（Ｓ１１０のＹ）、通知された情報を記憶部１７のソフトウェア動作状況ファイル１７３に記憶する（Ｓ１１２）。通知されたソフトウェア動作状況が正常でない場合（Ｓ１１３のＮ）、後述のエラー処理を行う。通知されたソフトウェア動作状況が正常な場合（Ｓ１１３のＹ）、配布先リスト１７２から次の配布先を取得する処理（Ｓ１０２）に戻る。

次に、エラー処理について説明する。
サーバ１１のＣＰＵ１３はソフトウェア更新処理中にエラーが発生したか否かを判定する（Ｓ１２１）。エラーが発生していない場合、配布先リスト１７２から次の配布先を取得する処理（Ｓ１０２）に戻る。エラーが発生した場合、そのエラーに対する処理が更新制御ファイル１７５に記述してあるか否かを判定する（Ｓ１２２）。記述がない場合、処理を終了する。

記述がある場合、異常発生台数ファイル１７６のその端末２１が属する拠点の異常発生台数のフィールドを＋１し（Ｓ１２３）、更新制御ファイル１７５に記述してある処理を行う（Ｓ１２４）。更新制御ファイル１７５に記述してある処理が、処理を終了させる内容であれば、サーバ１１のＣＰＵ１３は処理を終了する（Ｓ１２５のＮ）。更新制御ファイル１７５に記述してある処理が、処理を終了させるものでなければ、配布先リスト１７２から次の配布先を取得する処理（Ｓ１０２）に戻る。

以上のように、本実施例に係るサーバ１１によれば、端末２１のソフトウェア更新後の動作状況を確認しながら1台ごとに確実にソフトウェア更新を行うことができる。尚、ここで1台ごととは、ネットワーク全体で1台ごとではなく、ネットワーク全体の端末２１をいくつかの部分集合に分け、部分集合ごとに1台ごとでもよい。例えば、サーバ１１は拠点ごとに1台ずつソフトウェア更新処理をさせ、各拠点に対する処理を並行して行ってもよい。
〔実施例２〕
次に、実施の形態２に係るソフトウェア更新を制御するリモートメンテナンスシステムについて説明する。尚、実施の形態２に係るリモートメンテナンスシステムの構成例は実施の形態１と同一のため、実施例１の符号を参照する。

実施の形態２が実施の形態１と異なる点は、サーバ１１がソフトウェア更新対象の端末２１に対して予め一斉にファイル配布を行っておき、その後１台ずつ端末２１にソフトウェア更新の指令を送信する点である。ソフトウェア更新の指令を受けた端末２１は先に配布されていたファイルを用いソフトウェアを更新し、更新後にソフトウェアを起動させる。その後、端末２１の診断プログラム３３は更新後のソフトウェアの動作状況を取得し、サーバ１１へ通知する。サーバ１１は通知された動作状況に応じて、他の端末２１へのソフトウェア更新指令を送信するか否かを制御する。

このように実施の形態２によれば、端末１台ずつにファイルを配布するのではなく、一斉に全台に配布するため、ネットワーク通信量を低減することができ、また、全端末に対するソフトウェア更新にかかる時間が短縮できる。

〔実施例３〕
実施の形態３に比して実施の形態１と異なる点は、サーバ１１は、最初は端末１台ずつファイル配布を行い、ある時点で残りの全端末に一斉にソフトウェア更新をさせるという点である。ここで、ある時点とは例えば３台の端末から更新後のソフトウェア動作状況が正常であると通知された時点などである。

このように実施の形態３によれば、初めは１台ずつソフトウェア更新することにより、最低限正常に動作させたい端末数を確保することができ、それ以降は一斉に端末のソフトウェア更新をさせるため全体のソフトウェア更新にかかる時間を短縮することができる。

尚、本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

実施例におけるリモートメンテナンスシステムの構成例を示す図。 実施例におけるサーバの構成例を示す図。 配布先リストの構成例を示す図。 更新制御ファイルの構成例を示す図（その１）。 更新制御ファイルの構成例を示す図（その２）。 実施例における端末装置の構成例を示す図。 端末のソフトウェア更新を制御する動作を示すフローチャート。 端末のソフトウェア更新を制御する動作を示すフローチャート。 通知されたエラーに対する処理を行う動作を示すフローチャート。 異常発生台数ファイルの構成例を示す図。

符号の説明

１０：サーバ側ＬＡＮ、１１：サーバ、 １３：ＣＰＵ、１４：入力部、 １５：出力部、 １６：ＮＩＣ、 １７：記憶部、 ２０：支店側ＬＡＮ、 ２１：端末、 ２３：ＣＰＵ、 ２４：入力部、 ２５：出力部、 ２６：ＮＩＣ、 ２７：記憶部、 ３０：支店側ＬＡＮ、 ３１：アプリケーションソフトウェア、 ３２：ログファイル、 ３３：診断プログラム、 ４１、４２：ルータ、 １００：ネットワーク、 １７１：配布ファイル、 １７２：配布先リスト、 １７３：ソフトウェア動作状況ファイル、 １７４：配布プログラム、 １７５：更新制御ファイル、１７６：異常発生台数ファイル、 ２００：ＷＡＮ、 ３００：更新制御手段

Claims (3)

1. サーバと複数の端末とをネットワークを介して接続し、該サーバのリモートアクセスにより、該端末が有するソフトウェアを更新するリモートメンテナンスシステムにおけるソフトウェア更新の制御方法であって、
   第１の端末が有する該ソフトウェアを更新した後の動作状況を示す動作状況データを該第１の端末から受信し、受信した該動作状況データの動作状況に応じて、他の端末のソフトウェアを更新する制御を行うことを特徴とするソフトウェア更新の制御方法。
2. サーバと複数の端末とをネットワークを介して接続し、該サーバのリモートアクセスにより、該端末が有するソフトウェアを更新するリモートメンテナンスシステムであって、
   該端末は、該ソフトウェアの更新後の動作に関するログ情報に基づいて、更新後の該ソフトウェアが正常に動作しているか否かの動作状況を診断する診断プログラムを格納する記憶手段と、該診断プログラムが診断した結果である動作状況データを、該サーバ装置へ送信する通信手段とを有し、
   該サーバは、該端末の該動作状況データを該端末から受信する通信手段と、該端末から受信した該動作状況データを格納する記憶手段と、該記憶手段に格納された該動作状況データに基づいて該他の端末の該ソフトウェアを更新する制御を行う更新制御手段とを有することを特徴とするリモートメンテナンスシステム。
3. 端末とネットワークを介して接続され、該端末へのリモートアクセスにより、該端末が有するソフトウェアを更新するサーバであって、
   第１の端末が有する該ソフトウェアの更新後の動作状況を示す動作状況データを該第１の端末から受信する通信手段と、
   受信した該動作状況データの動作状況に応じて、該第１の端末以外の他の端末に対するソフトウェアの更新に関する更新処理データを記憶する記憶手段と、
   該記憶手段に記憶された該更新処理データに基づいて、該他の端末の該ソフトウェアを更新する制御を行う更新制御手段とを有することを特徴とするサーバ。

Images