(57)【要約】【課題】複数のバージョンのソフトウェアが存在する場合に、直前のバージョンに限定されずに、最適なバージョンを自動的に選択できるソフトウェア自動更新システムを提供する。【解決手段】コンピュータ装置で実行され、製品の製造や検査を管理する機能別アプリケーション１００の起動、停止、及びソフトウェアの更新を管理する起動停止管理アプリケーション１０３を有し、この起動停止管理アプリケーション１０３は、機能別アプリケーション１００について保有されている複数のバージョンから、特定のバージョンを選択するバージョン選択部１０５を有している。【選択図】図１
2007317089.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアをコンピュータ装置に運用させるにあたり、前記ソフトウェアについてバージョンの異なる複数種類のソフトウェアを更新ソフトウェアとして記憶する手段と、前記ソフトウェアを更新するときに、予め定められた優先順位に従って、複数のバージョンからいずれか１つのバージョンを選択するバージョン選択部と、前記バージョン選択部で選択されたバージョンの前記更新ソフトウェアを運用用のソフトウェアとして更新するソフトウェア更新処理部とを有することを特徴とするソフトウェア自動更新システム。
【請求項２】
前記複数のバージョンとは、現在運用中のバージョンと、過去に運用実績のあるバージョンと、運用実績のない新規なバージョンとを含むことを特徴とする請求項１に記載のソフトウェア自動更新システム。
【請求項３】
前記バージョン選択部は、新規なバージョンに設定された優先順に従って、更新するバージョンを選択するように構成されていることを特徴とする請求項２に記載のソフトウェア自動更新システム。
【請求項４】
現在運用中の前記ソフトウェアに不具合が発生したときに、不具合の内容を示す情報と、不具合が発生するまでの運転時間とを、前記ソフトウェアのバージョンと関連付けて記憶する状態記録部を有することを特徴とする請求項２に記載のソフトウェア自動更新システム。
【請求項５】
前記バージョン選択部は、自動更新するバージョンとして、前記各バージョンの運用実績を比較して決定するように構成されていることを特徴とする請求項２から請求項４に記載のソフトウェア自動更新システム。
【請求項６】
前記コンピュータ装置を起動停止させるプログラムと、このプログラムによって起動可能な１つ以上の別の前記ソフトウェアとを有することを特徴とする請求項１から請求項５のいずれか一項に記載のソフトウェア自動更新システム。
【請求項７】
前記更新のタイミングは、前記ソフトウェアの起動時又は終了時であることを特徴とする請求項６に記載のソフトウェア自動更新システム。
【請求項８】
更新した前記バージョンの前記更新ソフトウェアが、予め設定されている時間、正常動作したときに、この更新ソフトウェアを、同じソフトウェアを運用させる他のコンピュータ装置に送信する通信演算部を有することを特徴とする請求項１から請求項６のいずれか一項に記載のソフトウェア自動更新システム。
【請求項９】
コンピュータ装置で運用するソフトウェアを更新するにあたり、
前記ソフトウェアの更新対象として記憶装置に記憶されているバージョンの異なる複数の更新ソフトウェアから、いずれかのバージョンの前記更新ソフトウェアを選択する工程と、
選択されたバージョンの前記更新ソフトウェアを抽出し、前記更新ソフトウェアを、前記コンピュータ装置に運用させるソフトウェアとして更新する工程と、
を有することを特徴とするソフトウェア自動更新方法。
【請求項１０】
コンピュータ装置で運用するソフトウェアの更新対象として、記憶装置に記憶されているバージョンの異なる複数の更新ソフトウェアから、いずれかのバージョンの前記更新ソフトウェアを選択する工程と、
選択されたバージョンの前記更新ソフトウェアを抽出し、前記更新ソフトウェアを、前記コンピュータ装置で運用するソフトウェアとして更新する工程と、
を前記コンピュータ装置に実行させることを特徴とするソフトウェア自動更新プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ装置に不具合が発生したときに、ソフトウェアを自動的に更新するシステム、及びその方法、並びにこのシステムに用いられるプログラムに関する。
【背景技術】
【０００２】
従来、ソフトウェアを更新する際には、ソフトウェアの提供者から新たなバージョンのソフトウェアを取得し、対象となるパーソナルコンピュータにインストールしていた。ここで、新たなバージョンの入手方法としては、電子メールで取得したり、ウェブサーバからダウンロードしたり、フレキシブルディスクやＣＤ−Ｒ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｒｅｃｏｒｄａｂｌｅ）などの媒体により取得したりすることがあげられる。
新しいバージョンのソフトウェアをインストールするタイミングとしては、対象となるアプリケーションを起動する前や、終了させた後があげられ、ソフトウェアの入れ替えを行った後には、コンピュータ装置を再起動するという手順がとられている。さらに、更新対象となるソフトウェアを配布し、更新するための手順としては、動的にデータベースを検索し、新しいバージョンのソフトウェアを自動的に取得する方法がある（例えば、特許文献１参照）。さらに、この種のソフトウェアの中には、更新後のソフトウェアの正常動作を確認する手段を備え、異常が発生したと判断した場合には、更新前のバージョンに自動的に戻すものがある（例えば、特許文献２参照）。
【特許文献１】特開２０００−３３０７７８号公報
【特許文献２】特開平１１−３２１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、この種のソフトウェア自動配布システムは、新しいバージョンが段階的にリリースされることを前提とするもので、その都度動作確認を行って、異常などの不具合が発生したときに更新前のバージョンに戻すという手法がとられているので、不具合が発生した時に戻すことができるのは、直前に動作を確認したバージョンのソフトウェアのみであった。
ここで、主に生産工場の設備などに使用されるソフトウェアは、不具合として解析困難な問題に対する対策として、複数のバージョンを用意し、適当なものを選択する場合がある。さらに、バージョンアップに盛り込みたい処理内容が複数あるときに、それらの処理が同一のアプリケーションとして共存させられない場合がある。このような場合には、更新対象となるソフトウェアが同時に複数個リリースされるが、従来のソフトウェア自動配布システムでは、これら複数個のソフトウェアの中から最適なバージョンのソフトウェアを自動的に選択し、インストールすることはできなかった。そして、生産工場などでは、不具合が発生した場合には、その都度、システム設計者などが呼び出され、不具合の原因などを調べて、システムを再起動させなければならないので、作業効率が悪かった。
この発明は、このような事情に鑑みてなされたものであり、その目的とするところは、複数のバージョンのソフトウェアを選択可能にし、直前のバージョンに限定されずに、最適なバージョンを自動的に選択するようにすることである。
【課題を解決するための手段】
【０００４】
上記の課題を解決する本発明は、ソフトウェアをコンピュータ装置に実行させるにあたり、前記ソフトウェアについてバージョンの異なる複数種類のソフトウェアを更新ソフトウェアとして記憶する手段と、前記ソフトウェアを更新するときに、予め定められた優先順位に従って、複数のバージョンからいずれか１つのバージョンを選択するバージョン選択部と、前記バージョン選択部で選択されたバージョンの前記更新ソフトウェアを実行用のソフトウェアとして更新するソフトウェア更新処理部とを有することを特徴とするソフトウェア自動更新システムとした。
このソフトウェア自動更新システムでは、コンピュータ装置に実行させ、運用するソフトウェアを更新する場合に、そのソフトウェアに対して用意されている複数のバージョンから特定のバージョンが選択される。そして、選択されたバージョンのファイルを実行ファイルとして更新し、そのコンピュータ装置に実行させる。バージョンの選択にあたっては、予め設定しておいた条件等に基づいて行われる。
【発明の効果】
【０００５】
本発明によれば、コンピュータ装置に実行させ、運用させるソフトウェアの更新を行うにあたり、そのソフトウェアについてバージョンの異なる複数の候補を用意し、これら候補の中から選択される一のバージョンのソフトウェアに更新するようにしたので、最も安定して動作できるバージョンのソフトウェアを実行させることが可能になる。特に、２４時間稼動するシステムにおいて、安定した運用が可能になる。また、複数のバージョンの動作確認が必要な場合には、バージョン選択部の条件を設定することによって、そのような確認作業を自動的に行うことが可能になる。さらに、同じソフトウェアを実行させるコンピュータ装置が複数ネットワーク接続されている場合には、特定のコンピュータ装置における実績に基づいて最適なソフトウェアが自動的に更新されるようになるので、バージョンの管理が容易になる。
【発明を実施するための最良の形態】
【０００６】
発明を実施するための最良の形態について図面を参照しながら詳細に説明する。
図１は、本発明の第１の実施の形態における自動ソフト更新システムのシステム構成を示しており、コンピュータ装置で起動中のソフトウェア構造を簡略化したブロック図になっている。
この自動ソフト更新システムが適用されるコンピュータ装置では、機能別アプリケーション１００と、起動停止管理アプリケーション１０３との２つのソフトウェアが実行可能になっている。機能別アプリケーション１００は、Ａモジュール１０１と、Ｂモジュール１０２との２つに機能分割された構成になっている。この機能別アプリケーション１００は、例えば、ソケット通信等の通信手段を備えており、起動停止管理アプリケーション１０３と情報伝達を行うようになっている。
【０００７】
起動停止管理アプリケーション１０３は、機能別アプリケーション１００に対して起動命令及び停止命令、処理命令、エラー発生報告受信等を行う通信演算部１０４と、更新時に適切なバージョンを選択するバージョン選択部１０５と、バージョン選択部１０５で選択されたバージョンへの入れ替え処理を行うソフトウェア更新処理部１０６と、更新後の機能別アプリケーション１００の立ち上げ手順を管理する起動手順記憶部１０７と、バージョンごとの履歴を管理するバージョン履歴記憶部１０８と、機能別アプリケーション１００の終了時の情報を保存するプログラム状態記録部１０９と、バージョンごとにアプリケーションソフトウェアや、そのバージョンのアプリケーションソフトウェアで必要とされるモジュールソフトウェアが記憶されている記憶部１１０とから構成されている。なお、記憶部１１０は、メモリや、ハードディスクドライブ等を使用することができ、この起動停止管理アプリケーション１０３の必須の構成要素ではなく、コンピュータ装置側の構成としても良い。
【０００８】
次に、この実施の形態の作用について説明する。
最初に、起動停止管理アプリケーション１０３の処理の概略を図２のフローチャートを参照して説明する。図２に示すように、起動停止管理アプリケーション１０３は、最初に更新処理を行い（ステップＳ２０１）、システムを継続して作動させる場合には（ステップＳ２０２においてＮ）、機能別アプリケーション１００の動作状態の監視処理を行って（ステップＳ２０３）、更新処理が必要な場合には（ステップＳ２０４でＹ）、再びステップＳ２０１の更新処理に戻る。システムを停止する場合には（ステップＳ２０２でＹ）、終了処理を行う（ステップＳ２０５）。
【０００９】
上記の各処理（ステップＳ２０１〜ステップＳ２０５）の詳細、及びコンピュータ装置の動作を含めて、図３のフローチャートを用いて説明する。
まず、最初にコンピュータ装置のＯＳ（オペレーティングシステム）を起動させる（ステップＳ３０１）。次に、起動停止管理アプリケーション１０３を起動させる（ステップＳ３０２）。この際に、例えば、ＯＳのスタートアップ登録等のように、ＯＳに起動停止管理アプリケーション１０３の自動起動を設定しておくと、起動停止管理アプリケーション１０３が自動的に起動される。
起動停止管理アプリケーション１０３が起動されると、起動停止管理アプリケーション１０３はプログラム状態記録部１０９に記憶されている前回の停止状態等を参照し、機能別アプリケーション１００を最適なバージョンに更新するソフトウェア更新処理を行う（ステップＳ３０３）。このソフトウェア更新処理の詳細は、後述する。
さらに、起動停止管理アプリケーション１０３は、起動手順記憶部１０７に登録されている手順に従って、ステップＳ３０３のソフトウェア更新処理で選択されたバージョンのソフトウェアを実行させ、機能別アプリケーション１００を起動させる（ＳステップＳ３０４）。なお、ステップＳ３０３及びステップＳ３０４が図２のステップＳ２０１（更新処理）に相当する。
ここで、システムを正常終了する場合（ステップＳ３０５でＹ）には、機能別アプリケーションを終了後（ステップＳ３１２）、起動停止管理アプリケーションを終了させ（ステップＳ３１３）、ここでの処理を終了する。ステップＳ３１２及びステップＳ３１３が、図２のステップ２０５（終了処理）に相当する。
【００１０】
一方、システムを終了しない場合（ステップＳ３０４においてＮ）には、運用処理に入る。ここで、運用処理とは、例えば、機能別アプリケーション１００が生産ラインにおいて基板の検査を行う際に使用されるアプリケーションである場合には、この機能別アプリケーション１００をコンピュータ装置に実行させ、基板の検査を行わせることをいう。この運用処理は、エラーが発生しない限り、繰り返される。
これに対して、運用処理の実行中にエラーが発生したら（ステップＳ３０７においてＹ）、プラグラム状態記録部１０９に動作ログの保存を行う（ステップＳ３０８）。このときのログとは、エラーの発生原因を特定するためのもので、運用処理中に常時必要なログを保存している場合に行われる。これらステップＳ３０６からステップＳ３０８までの処理が、図２のステップＳ２０３に相当する。
【００１１】
そして、通信演算部１０４が、発生したエラーの種類から機能別アプリケーション１００の再起動が必要か否かを判断する（ステップＳ３０９）。
関連するプロセスが終了不能又は中断不能である場合には、再起動が必要であって、継続が不可能であると判断し（ステップＳ３０９でＮ）、機能別アプリケーション１００のみを終了させた後（ステップＳ３１０）、ソフト更新処理に戻る（ステップＳ３１１でＮから進むステップＳ３０３）。さらに、機能別アプリケーション１００を正常に終了できない場合や、再起動後の動作が保障できないエラーの場合には、ＯＳから再起動を行う（ステップＳ３１１でＹ）。この場合には、ステップＳ３０１のＯＳ起動処理に戻る。ステップＳ３０９からステップＳ３１１までの処理が、図２のステップＳ２０４に相当する。
【００１２】
エラー発生からＯＳ再起動までの処理（ステップＳ３０７〜Ｓ３１１，Ｓ３０１）は、作業者の介在しない完全な自動処理としても良いし、ダイアログ等のＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を用いて作業者の判断を必要とする処理としても良い。そして、自動処理又は手動処理の切り替えは、起動停止管理アプリケーション１０３の設定によって行われるようにしても良い。
【００１３】
さらに、ステップＳ３０３に示すソフト更新処理の詳細について、図４のフローチャートを参照して説明する。
まず、エラーの発生原因に基づいて、ソフトウェアの更新の必要性を判断する（ステップＳ４０１）。更新の必要がないソフトウェア不具合以外のエラーの場合には（ステップＳ４０１においてＮ）、ここでの処理を終了する。なお、更新の必要がないエラーとは、例えば、モジュール１０１，１０２がハードウェア制御しているハードウェハの動作エラーや、前回の終了時に作業者がコンピュータ装置を正常終了していた場合等があげられる。
更新が必要と判断された場合には（ステップＳ４０１においてＹ）、リトライ回数の判断を行う（ステップＳ４０２）。リトライ回数とは、そのバージョンのソフトウェアを実行させた回数をいい、不具合などにより再起動した場合には、リトライ回数が１つ加算されるようになっている。リトライ回数が、予め定義されている回数に達するまでは（ステップＳ４０２においてＹ）、ソフトウェア更新を行わないで同一バージョンを再起動して実行させる。これに対して、リトライ回数の上限値に達した場合には（ステップＳ４０２においてＮ）、バージョン選択部１０５において更新予約ファイルの有無を確認する（ステップＳ４０３）。更新予約ファイルとは、更新対象となるバージョンのファイルのことである。
【００１４】
更新予約ファイルを検索した結果、更新対象となるバージョンがある場合には（ステップＳ４０３においてＹ）、更新順序リストの有無を調べる（ステップＳ４０４）。更新順序リストとは、更新対象となるバージョンが複数個ある場合に、どのバージョンを優先的に更新対象として用いるかを定義したリストである。更新順序リストが存在する場合には（ステップＳ４０４においてＹ）、バージョン選択部１０５が、このリストに従って更新ファイルを決定する（ステップＳ４０５）。一方、更新順序リストが存在しない場合には（ステップＳ４０４においてＮ）、バージョン選択部１０５が、各バージョンのファイル名称や、タイムスタンプの比較等、他の方法によって更新するバージョンを決定する（ステップＳ４０６）。
更新するバージョンを決定したら、ソフトウェア更新処理部１０６が、運用中の実行ファイルを、更新するバージョンの更新ファイルで置き換える。具体的には、最初に、運用中の実行ファイルを履歴フォルダに移動する（ステップＳ４０７）。このとき、バージョンを示す情報をファイルの名称に追加してリネームしておく。さらに、更新するバージョンの更新ファイルを実行フォルダに移動させ、ファイル名をリネームして実行可能なファイル、つまり実行ファイルにする（ステップＳ４０８）。
【００１５】
一方、ステップＳ４０３の処理で更新予約ファイルが存在していない場合には、履歴ファイルの有無を調べる（ステップＳ４０９）。履歴ファイルとは、過去の運用したバージョン群についての情報が格納されているファイルである。履歴ファイルが存在しない場合には（ステップＳ４０９でＮ）、更新を行わずにここでの処理を終了する。一方、更新ファイルが存在している場合には（ステップＳ４０９でＹ）、例えば、過去に正常動作している時間の平均値から最適なバージョンを選択する（ステップＳ４１０）。このとき決定したバージョンが現在運用しているバージョンと同じ場合には（ステップＳ４１１でＹ）、更新を行わずにここでの処理を終了し、バージョンが異なる場合のみ、ステップＳ４０７及びステップＳ４０８の処理を行って機能別アプリケーション１００のバージョンを更新する。
【００１６】
ここで、ステップＳ４０７及びステップＳ４０８の処理を行うためのファイル構造の一例を図５に示す。
実行フォルダ５００は、現在運用しているバージョンのファイルを管理するフォルダである。実行フォルダ５００内には、以下の各ファイルが格納されている。実行ファイル５０１は、更新対象となる機能別アプリケーション１００の実行可能なソフトウェアで、例えば、「Ａｐｐｌｉｃａｔｉｏｎ．ｅｘｅ」である。モジュール５０２及びモジュール５０３は、実行ファイル５０１に付随し、機能別アプリケーションの実行に必要なモジュールであり、例えば、それぞれ「Ｍｏｄｕｌｅ１．ｄｌｌ」及び「Ｍｏｄｕｌｅ２．ｄｌｌ」となる。更新履歴ファイル５０４は、実行ファイル５０１の更新を実行した場合の情報が格納されるファイルで、例えば、「更新履歴．ｔｘｔ」からなる。設定ファイル５０５は、実行ファイル５０１内部の各種設定を行うためのデータからなり、例えば、「設定ファイル．ｉｎｉ」となる。なお、機能別アプリケーション１００が、モジュール５０２，５０３や、設定ファイル５０５を必要としない場合には、これらのファイルは実行フォルダ５００に格納されない。また、モジュール５０２，５０３や、設定ファイル５０５の数は、図５に示すものに限定されない。
【００１７】
また、履歴フォルダ５０６は、過去に運用したバージョンファイルを管理するフォルダで、ステップＳ４０７の処理を実行した際に更新前の実行ファイルから作成されるリネームファイルが、履歴ファイルとして格納される。図５においては、機能別アプリケーション１００のバージョン０．０．０．０に対応する履歴ファイル５０７と、バージョン１．０．０．０に対応する履歴ファイル５０８とが格納されている。リネームしたファイル名としては、種々のものを使用できるが、例えば、実行ファイル５０１が、「Ａｐｐｌｉｃａｔｉｏｎ．ｅｘｅ」である場合には、履歴ファイル５０７は、「Ａｐｐｌｉｃａｔｉｏｎ−０．ｅｘｅ」とする。また、履歴ファイル５０８は、「Ａｐｐｌｉｃａｔｉｏｎ−１．ｅｘｅ」とする。これら履歴ファイル５０７，５０８に関する情報は、更新履歴ファイル５０４に保存される。
【００１８】
更新予約フォルダ５０９は、更新対象となる更新ファイルとして、新規バージョンの更新ファイル（更新予約ファイル）を格納するフォルダである。図５には、新規バージョンとして３つのバージョンが用意されている例が図示されている。すなわち、更新順序リストファイル５１０、例えば、「更新順序リスト．ｔｘｔ」は、更新予約フォルダ５０９内の更新予約ファイルの更新順序を定義したファイルであって、図４のステップＳ４０４で参照されるものである。更新予約ファイル５１１は、例えば、バージョン３．０．０．０の実行ファイル（Ａｐｐｌｉｃａｔｉｏｎ−３．ｅｘｅ）、更新予約ファイル５１２は、バージョン４．０．０．０の実行ファイル（Ａｐｐｌｉｃａｔｉｏｎ−４．ｅｘｅ）、更新予約ファイル５１３は、バージョン５．０．０．０の実行ファイル（Ａｐｐｌｉｃａｔｉｏｎ−５．ｅｘｅ）である。また、更新候補ファイル５１４は、更新対象となるモジュールで、例えば、Ｍｏｄｕｌｅ１．ｄｌｌの更新候補として、Ｍｏｄｕｌｅ１−２．ｄｌｌといったモジュールがあげられる。
【００１９】
さらに、図６に更新履歴ファイル５０４のフォーマットの一例を示す。
図６に示すように、更新履歴ファイル５０４は、テキスト形式で作成されており、例えば、一行目には、ファイル名データ６００が配置されている。ファイル名データ６００には、「Ａｐｐｎａｍｅ＝Ａｐｐｌｉｃａｔｉｏｎ．ｅｘｅ」など、実行ファイルの名称が定義されている。
バージョンデータ６０１は、実行中のソフトウェアのバージョン情報が記述される。
リトライデータ６０２，６０３，６０４には、バージョンごとに、３回リトライした場合の各リトライ実施前までの正常動作時間と、その平均動作時間が記録されている。例えば、リトライデータ６０２は、「[０．０．０．０]」、つまり０．０．０．０バージョンについて、「００１＝５」、１回目のリトライまでに５時間動作し、「００２＝１５」、２回目のリトライまでは１５時間動作し、「００３＝１０」、３回目のリトライまでは１０時間動作したことを示している。また、「Ａｖｅ＝１０」、つまり３回の平均動作時間が１０時間であることが示されている。リトライデータ６０４は、２．０．０．０バージョンのリトライ回数と動作時間を示すもので、「００３＝」のデータがないことから、３回目のリトライの確認中であることがわかる。
【００２０】
そして、エラーデータ６０５は、リトライの原因を示すエラー情報を示している。エラーデータ６０５は、バージョンごと、リトライごとにエラーの内容を示すコードが付される。このエラー情報は、履歴フォルダ５０６に格納されている履歴ファイル５０７，５０８から最適なバージョンを選択する基準として、動作時間以外に、例えば、特定のエラーが発生していないバージョンを採用するといった選択条件を設けた場合に用いられる。
【００２１】
さらに、図５に示す更新順序リストファイル５１０のフォーマットの一例を図７に示す。
更新順序リストファイル５１０には、優先順位が高い順にファイルの名称が定義されており、１行目には第１優先データ７００を示し、「Ｕｐｄａｔｅ１＝Ａｐｐｌｉｃａｔｉｏｎ‐３．ｅｘｅ」、つまり、Ａｐｐｌｉｃａｔｉｏｎ‐３．ｅｘｅが最も優先順位が高いバージョンの実行ファイルであることが定義されている。以下、２行目の第２優先データ７０１は、「Ｕｐｄａｔｅ２＝Ａｐｐｌｉｃａｔｉｏｎ‐４．ｅｘｅ」となっており、この実行ファイルが２番目に優先順位が高いバージョンであることが定義されている。３行目の第３優先データ７０２は、「Ｕｐｄａｔｅ３＝Ａｐｐｌｉｃａｔｉｏｎ‐５．ｅｘｅ，Ｍｏｄｕｌｅ１‐２．ｄｌｌ」となっており、最も優先順位が低い実行ファイルと、この実行ファイルとセットでバージョンアップするモジュールとが定義されている。このように、バージョンアップの対象は、２つ以上のファイルを同時に行わせることも可能である。
【００２２】
この実施の形態によれば、コンピュータ装置に機能別アプリケーション１００を実行させ、生産装置や検査装置の制御を行う際に、このコンピュータ装置に起動停止管理アプリケーション１０３を実行させることで、機能別アプリケーション１００の起動時、又は機能別アプリケーション１００に起因する不具合が発生したときに、起動停止管理アプリケーション１０３が、履歴フォルダ５０６又は、更新予約フォルダ５０９に格納されている更新ファイル（履歴ファイル５０７，５０８，更新予約ファイル５１１〜５１４）から最適なものを自動的に判断し、そのような更新ファイルを実行ファイルとして機能別アプリケーション１００を運用させるようにしたので、複数の候補のうちから最適な実行ファイルを自動的に選択することが可能になる。したがって、コンピュータ装置を安定して動作させることができる。また、２４時間稼動するシステムにおいても安定した運用が可能になる。
さらに、更新履歴ファイル５０４で、バージョンごとの平均動作時間や、エラーの内容を保存するようにしたので、複数のバージョンを複数回運用した場合に、より安定性の高い実行ファイルを選択することが可能になり、生産装置などを安定して運用することが可能になる。ここにおいて、新しいバージョンの実行ファイルをテストする場合には、更新順序リストファイル５１０を作成し、優先順位を決定しておけば、この順番に更新を行わせることができるので、管理者にとって好ましい実行ファイルを優先使用することが可能になり、問題点の克服などを速やかに行えるようになる。
【００２３】
本発明の第２の実施の形態について図面を参照しながら詳細に説明する。なお、第１の実施の形態と同一の構成要素には同じ符号を付してある。また、重複する説明は省略する。
図８に示すように、３台のコンピュータ装置８００，８０１，８０２と、サーバ８０３との合計４台のパーソナルコンピュータがスイッチングハブ８０４を介してネットワーク接続されている。各コンピュータ装置８００〜８０２は、それぞれが生産装置又は検査装置の制御に用いられる。また、各コンピュータ装置８００〜８０２には、第１の実施の形態における機能別アプリケーション１００及び起動停止管理アプリケーション１０３がインストールされ、実行されている。
【００２４】
ここで、このソフトウェア自動更新システムでは、コンピュータ装置８００にインストールされている起動停止管理アプリケーション１０３のみに、最適バージョンを他のコンピュータ装置８０１，８０２に展開できる機能を有しているとする。この機能は、例えば、予め設定した期間を不具合なく動作し、安定動作が確認されたバージョンを他のコンピュータ装置８０１，８０２にコピーする機能である。
【００２５】
この実施の形態における展開処理について、図９のフローチャートを用いて説明する。
まず、特定のバージョンについて、予め設定した時間以上運用できることを確認する（ステップＳ９０１）。コンピュータ装置８００の起動停止管理アプリケーション１０３に、他のコンピュータ装置８０１，８０２に展開するように設定されている場合には（ステップＳ９０２でＹ）、バージョンの展開が予定されているコンピュータ装置８０１，８０２の更新予約フォルダ５０９（図５参照）に、コンピュータ装置８００が現在実行中のファイルを、更新対象のバージョンファイルとしてコピーする（ステップＳ９０３）。
さらに、コンピュータ装置８０１の起動停止管理アプリケーション１０３は、サーバ８０３への登録の有無を調べる（ステップＳ９０４）。登録の必要がある場合には（ステップＳ９０５でＹ）、サーバ８０３の更新フォルダにも、運用中のファイルをコピーし（ステップＳ８０５）、ここでの処理を終了する。
【００２６】
また、このようにネットワークを構築してある場合には、サーバ８０３に更新ファイル（例えば、図５の更新予約ファイル５１１〜５１４）を置いておくことも可能である。この場合のコンピュータ装置８００の処理について図１０を参照して説明する。
例えば、コンピュータ装置８０１で運用中の起動停止管理アプリケーション１０３がコンピュータ装置８０１で運用するアプリケーションの更新処理を行う際、サーバ８０３内の更新ファイルの有無をチェックし（ステップＳ１００１）、更新ファイルを見つけた場合には（ステップＳ１００２でＹ）、自己の更新予約フォルダ５０９（図５参照）にそのファイルをコピーする（ステップＳ１００３）。この処理は、定期的にサーバ８０３をチェックするプログラムを実行させることで、任意のタイミングで行うようにしても良い。
【００２７】
この実施の形態では、ネットワーク接続された複数のコンピュータ装置８００〜８０２を有し、これらコンピュータ装置８００〜８０２に同じ機能別アプリケーション１００を実行させることで運用されるシステムにおいて、１つのコンピュータ装置の実績に基づいて、安定して運用できるバージョンを選択し、実行させることができ、さらにこのバージョンの実行ファイルを他のコンピュータ装置に展開させることで、他のコンピュータ装置においても安定して運用可能なバージョンの機能別アプリケーション１００を運用することが可能になる。したがって、大規模な生産工場であっても効率良く、かつ安定した運用が可能になる。また、管理者の手間を省略することができる。
さらに、サーバ８０３の更新フォルダをチェックして必要なファイルを自己の更新予約フォルダ５０９にコピーするようにしたので、新しいバージョンのファイルを遠隔地からアップロード等するだけでテストすることが可能になり、作業効率が向上する。
その他の作用及び効果は、第一の実施の形態と同様である。
【００２８】
なお、本発明は、前記の各実施の形態に限定されずに広く応用することができる。
例えば、起動停止管理アプリケーション１０３は、更新対象を選択する条件や、新規なファイルと運用実績のあるファイルとの優先順位などを、管理者によって設定可能にしても良い。この場合には、起動停止管理アプリケーション１０３は、条件設定を容易にするＧＵＩをモニタ表示するようにすると良い。
また、図１０に示すステップＳ１００１の処理は、コンピュータ装置８００〜８０２がＯＳを再起動するたびに、起動停止管理アプリケーション１０３がサーバ８０３をチェックしても良い。また、起動停止管理アプリケーション１０３が一定時間稼動するたびにサーバ８０３をチェックするようにしても良い。
【００２９】
また、図３におけるソフト更新処理（ステップＳ３０３）は、機能別アプリケーション１００の終了時、つまりステップＳ３１０を実行した後に行うようにしても良い。コンピュータ装置が、前回までは安定して運用できていた場合に、そのような運用状態を優先させることができる。
さらに、各コンピュータ装置は、機能別アプリケーション１００を複数種類有し、選択的に、又は同時に複数の機能別アプリケーション１００が実行されるようにしても良い。この場合に、起動停止管理アプリケーション１０３は、各機能別アプリケーション１００ごとに、前記処理を実行する。
【図面の簡単な説明】
【００３０】
【図１】本発明の実施の形態におけるソフトウェア自動更新システムの概略を示すブロック図である。
【図２】起動停止管理アプリケーションの処理の概略を示すフローチャートである。
【図３】ソフトウェア自動更新システムの処理を示すフローチャートである。
【図４】図３のステップＳ３０３の処理の詳細を示すフローチャートである。
【図５】図４に示すステップＳ４０７及びステップＳ４０８の処理を行うためのファイル構造の一例を示す図である。
【図６】更新履歴ファイルのフォーマットの一例を示す図である。
【図７】更新順序ファイルのフォーマットの一例を示す図である。
【図８】複数のコンピュータ装置がネットワーク接続されている場合のソフトウェア自動更新システムを説明する図である。
【図９】図８に示すソフトウェア自動更新システムにおいて、ソフトウェアを更新する際の展開処理を示すフローチャートである。
【図１０】図８に示すソフトウェア自動更新システムにおいて、サーバに格納されたファイルに基づいて更新処理を行う場合を示すフローチャートである。
【符号の説明】
【００３１】
１００    機能別アプリケーション（ソフトウェア，プログラム）
１０３    起動停止管理アプリケーション（プログラム）
１０４    通信演算部
１０５    バージョン選択部
１０６    ソフトウェア更新処理部
１０９    プログラム状態記憶部
１１０    記憶部
５０７，５０８  履歴ファイル（更新ソフトウェア）
５１１，５１２，５１３，５１４  更新予約ファイル（更新ソフトウェア）
８００，８０１，８０２    コンピュータ装置
【図１】
2007317089.tif 000003
【図２】
2007317089.tif 000004
【図３】
2007317089.tif 000005
【図４】
2007317089.tif 000006
【図５】
2007317089.tif 000007
【図６】
2007317089.tif 000008
【図７】
2007317089.tif 000009
【図８】
2007317089.tif 000010
【図９】
2007317089.tif 000011
【図１０】
2007317089.tif 000012