JP2004005230A - エージェント利用メンテナンスシステム - Google Patents
エージェント利用メンテナンスシステム Download PDFInfo
- Publication number
- JP2004005230A JP2004005230A JP2002160241A JP2002160241A JP2004005230A JP 2004005230 A JP2004005230 A JP 2004005230A JP 2002160241 A JP2002160241 A JP 2002160241A JP 2002160241 A JP2002160241 A JP 2002160241A JP 2004005230 A JP2004005230 A JP 2004005230A
- Authority
- JP
- Japan
- Prior art keywords
- maintenance
- program
- information
- server
- agent program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012423 maintenance Methods 0.000 title claims abstract description 378
- 238000000034 method Methods 0.000 claims description 52
- 238000012545 processing Methods 0.000 abstract description 31
- 230000007246 mechanism Effects 0.000 description 33
- 238000010586 diagram Methods 0.000 description 18
- 230000005540 biological transmission Effects 0.000 description 14
- 230000004044 response Effects 0.000 description 12
- 230000008569 process Effects 0.000 description 11
- 238000004891 communication Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 238000011179 visual inspection Methods 0.000 description 1
Images
Landscapes
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】各機器の大幅なハードウエアの追加なしに、人手に依存することなく、かつ各機器での処理に負担を与えないでメンテナンスを行う。
【解決手段】保守サーバで生成されたメンテナンスエージェントプログラムをネットワークを介して端末装置で順次実行するメンテナンスシステムにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成してこれをネットワークに送信し、これを受信して端末装置は、自身を対象としたものか否かを判別した後にこのプログラムを登録・実行し、その実行結果情報を当該メンテナンスエージェントプログラムに付加し、ネットワーク上に再度送出する。このメンテナンスエージェントプログラムを回収した保守サーバは実行結果情報を解析・出力するようにした。
【選択図】 図1
【解決手段】保守サーバで生成されたメンテナンスエージェントプログラムをネットワークを介して端末装置で順次実行するメンテナンスシステムにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成してこれをネットワークに送信し、これを受信して端末装置は、自身を対象としたものか否かを判別した後にこのプログラムを登録・実行し、その実行結果情報を当該メンテナンスエージェントプログラムに付加し、ネットワーク上に再度送出する。このメンテナンスエージェントプログラムを回収した保守サーバは実行結果情報を解析・出力するようにした。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明は、ネットワークに接続された端末装置上のアプリケーションプログラム等に対して、メンテナンス状態を調査・診断し、保守センターに設置されたサーバに各端末装置の状態を通知するエージェント機能を利用したメンテナンスシステムに関する。
【0002】
【従来の技術】
従来技術において、各所に設置された機器のメンテナンスのために、メンテナンス要員は、定期的に各所を巡回しその機器毎に調査・保守を行うのが通例であった。
【0003】
しかし、ネットワーク技術が発達した今日においては、各所に設置された機器をネットワークで接続し、種々のメンテナンスプログラムを各機器にインストールしておき、保守状況を上位の保守サーバに通知する仕組みも考えられている。
【0004】
たとえば、ネットワーク管理情報の収集技術としては特開平10−247169号公報や特開平11−252209号公報が挙げられる。
【0005】
【発明が解決しようとする課題】
しかし、このようなネットワーク管理技術では、各機器に個別にメンテナンスプログラムをインストールしておかなくてはならないため、ハードディスク装置やメモリを増設しなければならず機器毎に物理的・経済的な負担が大きくなるという問題があった。
【0006】
また、新しいメンテナンス項目が追加される度に全機器に新たなメンテナンスプログラムをインストールし直さなければならず、そのインストールもオペレータの人手に依存しなければならないため効率的ではなかった。
【0007】
さらに、常に各機器のメンテナンスプログラムを常駐させておかなければならないため、各機器の中央処理装置(CPU)の負荷が大きかった。
【0008】
本発明は、このような点に鑑みてなされたものであり、各機器の大幅なハードウエアの追加なしに、人手に依存することなく、かつ各機器での処理に負担を与えないメンテナンス技術を提供することを技術的課題とする。
【0009】
【課題を解決するための手段】
本発明は、前記課題を解決するために以下の手段を採用した。
本発明の第1の手段は、保守サーバで生成されたメンテナンスエージェントプログラムをネットワークを介して端末装置で順次実行するメンテナンスシステムにおいて、保守サーバにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成し、前記端末装置において、前記保守サーバより送出されたメンテナンスエージェントプログラムを受信して自身を対象としたものか否かを判別し、前記端末装置において、前記メンテナンスエージェントプログラムを実行し、その実行結果情報をネットワーク上に送出し、前記保守サーバにおいて、その実行結果情報を解析・出力するメンテナンスシステムとしたものである。
第2の手段は、ネットワークで接続された端末装置のメンテナンスを保守サーバで管理する方法であって、保守サーバにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成するステップと、前記で生成されたメンテナンスエージェントプログラムを前記端末装置に送信するステップと、端末装置内で実行されたメンテナンスエージェントプログラムの実行結果情報を受信するステップと、受信した実行結果情報を解析し、解析結果を出力するステップとからなる保守サーバを用いたメンテナンス方法である。
第3の手段は、ネットワークで接続された保守サーバに対してメンテナンス実行機能を備えた端末装置であって、保守サーバで生成されたメンテナンスエージェントプログラムを受信する手段と、受信したメンテナンスエージェントプログラムが自身を対象としたものか否かを判定する手段と、前記プログラムが自身を対象としたものであるときに当該メンテナンスエージェントプログラムを格納する手段と、格納された前記メンテナンスエージェントプログラムを実行する手段と、前記プログラムの実行結果情報を保守サーバに送信する手段とからなる端末装置である。
第4の手段は、前記第2の手段において、前記保守サーバが、端末装置毎のハードウエア情報を登録した機器構成データベースと、ハードウエア毎のメンテナンスモジュール情報を登録したメンテナンスデータベースとを有しており、当該機器構成データベースとメンテナンスデータベースとを参照することによりメンテナンスエージェントプログラムに格納するメンテナンスモジュールを決定するようにしたものである。
第5の手段は、前記第2の手段において、鉄道の駅システムのメンテナンス方法に適用したものであり、前記保守サーバに各駅毎の車両の発着時刻情報を有し、当該発着時刻情報に基づいて閑散時間帯に前記メンテナンスエージェントプログラムをネットワークに送出するようにしたものである。
第6の手段は、前記第2の手段において、鉄道の駅システムのメンテナンス方法に適用したものであり、前記保守サーバに各駅毎の乗降客の改札通過情報を有し、当該改札通過情報に基づいて閑散時間帯に前記メンテナンスエージェントプログラムをネットワークに送出するようにしたものである。
【0010】
第7の手段は、前記第3の手段において、前記メンテナンスエージェントプログラムを受信した後に、次の端末が受信すべく該メンテナンスエージェントプログラムをネットワーク上へ送出するようにしたものである。
第8の手段は、前記第2の手段において、前記端末装置から受信した前記実行結果情報に基づいてメンテナンス情報を生成し出力するようにしたものである。第9の手段は、前記第2の手段において、前記実行結果情報の出力に基づいた課金情報を出力するようにしたものである。
第10の手段は、ネットワークで接続された端末装置のメンテナンスを管理する保守サーバであって、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成する手段と、前記で生成されたメンテナンスエージェントプログラムを前記端末装置に送信する手段と、端末装置内で実行されたメンテナンスエージェントプログラムの実行結果情報を受信する手段と、受信したメンテナンスエージェントプログラムの実行結果情報を解析し、解析結果を出力する手段とからなる保守サーバである。
第11の手段は、前記第2の手段において、前記実行結果情報を、前記メンテナンスエージェントプログラムの付加情報として当該メンテナンスエージェントプログラムとともに保守サーバにより受信されるようにしたものである。
第12の手段は、前記第2の手段において、前記メンテナンスの時期に関する情報を有しており、当該時期が到来すると前記メンテナンスエージェントプログラムを生成し、前記端末装置に送信するようにしたものである。
第13の手段は、前記第2の手段において、前記端末装置が、前記メンテナンスエージェントプログラムに記述された内容に基づいて所定のメンテナンス実行プログラム本体のダウンロードを保守サーバに要求するようにしたものである。第14の手段は、前記第2の手段において、前記端末装置が、前記メンテナンスエージェントプログラムの実行の結果、エラーを発生したときに障害対応プログラムの起動、または保守サーバへの障害対応プログラムのダウンロード要求を行うようにしたものである。
【0011】
【発明の実施の形態】
【実施例】
以下、図面に基づいて、本発明の実施の形態を説明する。
図1は、本発明の実施例におけるシステム構成図である。
【0012】
本実施例のネットワークは鉄道の駅システムであり、保守サーバ1を中心に、ネットワーク3を介して改札機4,7、精算機5,8、券売機6,10が接続されている。本実施例ではメンテナンス対象となる端末装置を券売機6,10として説明する。すなわち、保守サーバ1で生成されたメンテナンスエージェントプログラム1がネットワーク3を介して券売機6および10のメンテナンスを実行し、保守サーバ2に帰還するまでを説明する。
【0013】
図8は前記の図1に対応したシステム構成図である。同図に示すように、保守サーバ1ならびに改札機4、精算機5および券売機6はコンピュータシステムで構成されている。たとえば、保守サーバ1の場合、中央処理装置(CPU)1aを中心に、ネットワークと接続するための通信コントローラ1cとハードディスク装置1bを有している。また、外部装置としてディスプレイ装置1dおよびプリンタ装置1eおよびキーボード1fを有している。
【0014】
前記ハードディスク装置1b内には、オペレーティングシステムとともに、図2に示すように、メンテナンスデータベース11、券売機構成データベース12および精算機構成データベース13、改札機構成データベース14等が格納されており、これらのデータベースを参照してメンテナンスエージェントプログラム2が生成されるようになっている。
【0015】
また、ハードディスク装置1b内には、さらに図3に示すように時刻表データベース31,駅毎の通過人員データベース32および送信待機テーブル33を有している。
【0016】
他方、図8に示すように、端末装置である券売機6は、券売機全体の制御部を構成する中央処理装置(CPU)6aを中心に、ネットワークと接続するための通信コントローラ6bと、プログラムや売上げデータ等を格納するメモリ6dと、接客用や係員操作用のディスプレイ6cおよび入力操作部6fを有している。以上は精算機、改札機もほぼ同様の構成であるが、それぞれ異なる動作ハードウェア(メカ4e,5e,6e)を有している。この動作ハードウェアは、たとえば改札機4の場合、券搬送機構、扉開閉機構等がこれに該当する。精算機5や券売機6の場合は、硬貨処理機構、紙幣処理機構、発券処理機構、カード処理機構等がこれに該当する。なお、各動作ハードウェア(メカ4e,5e,6e)は、各々の中にCPU(図示せず)を持つものもある。
【0017】
図2は、メンテナンスエージェントプログラム2を生成するデータベース構成を説明している。同図に示すように、保守サーバ1内のハードディスク装置1bに格納されたデータベースは、保守に関する機構毎のモジュール群(プログラム単位)であるメンテナンスデータベース11と、対象となる券売機6、精算機5および改札機4の機種別のハードウエアおよびソフトウエア構成を示すデータベース(機器別構成データベース12,13,14)とからなり、これらの組み合わせによりメンテナンスエージェントプログラム2が生成される。
【0018】
たとえば、券売機6に関しては、保守サーバ1の中央処理装置(CPU)は、エージェントプログラム生成プログラム(図示せず)をハードディスク装置1bから読み込むと、券売機構成データベース12を参照し、対象となる券売機6の機器構成情報を取得する。この場合、同図ではコインメカA(12a)と発券メカA(12b)とで構成されているため、メンテナンスデータベース11のコインメカAに関するモジュール、すなわちプログラムバージョンチェックモジュール11aとセンサチェックモジュール11bとを読み出す。
【0019】
同様にして発券メカA(12b)に関するモジュール、すなわちプログラムバージョンチェックモジュール11cとセンサチェックモジュール11dとを読み出す。そして、これらのモジュールを結合して券売機用メンテナンスエージェントプログラム2を生成する。
なお、上述のようなメカに関するモジュール以外にも、たとえばCPU6aを中心に構成され各メカと券売機全体の制御を行う制御部に関するモジュールがあってもよい。
このように各機種の機器構成に応じて、メンテナンスモジュール(メンテナンスプログラム)を組合せることにより、メンテナンスエージェントプログラムを生成するので、各機器に応じた適切な保守チェックが可能となる。また、プログラムをモジュール化しているので、大規模なプログラムを組む必要がなく、同一のメカを搭載する機器については、メンテナンスプログラムをモジュールとして共用でき、保守サーバのハードディスク容量やメモリ容量も節約できる。さらに、新しい機種の端末機器ができても、機器別構成データベースを追加し、新規の構成部分がある場合は、必要によりその部分についてのみメンテナンスモジュールを作成すれば、新規の保守サービスを順次、容易に追加できる。
【0020】
図3は、以上のようにして生成されたメンテナンスエージェントプログラム2の保守サーバ1からの送信タイミングを設定する方法を示している。
【0021】
同図に示すように、図2で生成された券売機メンテナンスエージェントプログラム2は、メンテナンスエージェント送信待機テーブル33に記録された時間情報にしたがって保守サーバ1よりネットワーク3に対して送出される。
【0022】
すなわち、保守サーバ1の中央処理装置(CPU)は、時刻表データベース31と通過人員データベース32とを参照し、駅毎の券売機の稼働効率の低い時間にメンテナンス対象となる券売機に対して送信すべくメンテナンスエージェントプログラム送信待機テーブル33を設定する。
【0023】
これは、駅の閑散時間に券売機6のメンテナンスを実行するためである。すなわち、券売機6は駅のラッシュ時(たとえば朝夕)には発券処理に最大限の処理速度が要求されるため、このような混雑時にはメンテナンスを実行すべきではない。一方、昼間や深夜の閑散時間には券売機6はあまり稼働しておらずメンテナンスを行ったとしても発券処理に支障を来すことは少ない。
【0024】
このような閑散時間の判断は、たとえば時刻表データベース31から得ることができる。電車の駅発着回数が少ない時間帯すなわち発着時刻の間隔が大きい時間帯は、券売機の稼働率も低い時間帯であるため、閑散時間と判断することができる。また、改札機4から得られた通過人員データベース32を参照して、この通過人員が少ない時間帯を、閑散時期であると判断する方法であってもよい。
【0025】
このように、本実施例では時刻表データや通過人員データ等から各駅の閑散時間を取得し、このような閑散時間にメンテナンスエージェントプログラム2を送信するようにしたため、各端末(ここでは券売機6)の発券処理に実質的に影響を与えることなくメンテナンスが実行できる。
【0026】
図4は、メンテナンス対象である券売機6におけるメンテナンスエージェントプログラム2の取り込み方法を示す図である。
【0027】
保守サーバ1からメンテナンスエージェントプログラム2が送信された後、このメンテナンスエージェントプログラム2はネットワーク転送データとしてネットワーク3に接続された各端末装置に順番に読み込まれる。このとき、メンテナンスエージェントプログラム2のヘッダには読み込むべき端末装置を特定するアドレス(ここでは券売機6,10のアドレス)が設定されており、このアドレスに該当する端末装置(券売機6,10)が当該メンテナンスエージェントプログラム2を自身のメモリ内に読み込む。
【0028】
同図において、メンテナンスエージェントプログラム2のヘッダに券売機6のアドレス(アドレス1)と券売機10のアドレス(アドレス2)が設定されている場合、ネットワーク3からメンテナンスエージェントプログラム2を受信した券売機6は、まずそのヘッダ情報を解析し、自身(券売機6)のアドレス(アドレス1)が書き込まれているか否かを判定する。ここで、自身のアドレスが書き込まれている場合には、当該メンテナンスエージェントプログラム2は自身(券売機6)に対して送信されたものであると判断し、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録する。
【0029】
ここで、自身のアドレスが書き込まれていない場合には、当該メンテナンスエージェントプログラム2を自身に取り込むことなく再度ネットワーク3に送出する。
【0030】
一方、前記メンテナンスエージェントプログラム2を取り込んだ場合、該メンテナンスエージェントプログラム2を券売機6内で起動してメンテナンス処理を開始する。このメンテナンス処理が完了すると、前記メンテナンスエージェントプログラム2に当該券売機6の実行結果ログ2a(図6参照)を追加して当該メンテナンスエージェントプログラム2を再度ネットワーク3上に送出する。
【0031】
ここで実行結果ログ2aとは、たとえばプログラムを実行した結果に基づいて、実施した保守チェックの内容、チェック結果、障害対応した内容、障害対応結果等のメンテナンス結果の記録情報である。図6に示すように、実行結果ログ2aは端末毎に各々記録される。
【0032】
ネットワーク3からメンテナンスエージェントプログラム2を受信した券売機10は、前記と同様にヘッダ情報を解析し、自身(券売機10)のアドレス(アドレス2)が書き込まれているか否かを判定する。ここで、自身のアドレスが書き込まれている場合には、当該メンテナンスエージェントプログラム2は自身(券売機10)に対して送信されたものであると判断し、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録する。
【0033】
そして、当該メンテナンスエージェントプログラム2を券売機10内で起動してメンテナンス処理を実行した後、その実行結果ログ2aをさらに追加して当該メンテナンスエージェントプログラム2を再度ネットワーク3上に送出する。
【0034】
前記図4に示したメンテナンスエージェントプログラム2には、そのヘッダに対象とする端末機器の全てのアドレスを登録した例だったが、これに限らず、保守サーバ1から送信されるメンテナンスエージェントプログラム2には、対象となる最初の端末装置のアドレス(たとえば券売機6に対するアドレス1)だけを設定するようにしてもよい。
【0035】
この場合、対象となる端末装置(券売機6)内のメモリまたはハードディスク装置内にメンテナンス対象とする同種の機器(次にメンテナンスを行うべき機器)を定義したメンテナンス順序テーブル51を持たせてもよい。図5はそれを示す実施例である。同図の場合、保守サーバ1から送出されるメンテナンスエージェントプログラム2のヘッダには最初のメンテナンス対象となる端末装置(券売機6)のアドレス(アドレス1)のみが登録されている。
【0036】
券売機6は、このメンテナンスエージェントプログラム2を読み込むと、ヘッダを解析し、自身のアドレス(アドレス1)が書き込まれているか否かをチェックする。ここでヘッダに自身のアドレスが書き込まれている場合、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録して当該メンテナンスエージェントプログラム2を起動する。そして当該プログラムの処理を完了すると、その実行結果ログ2aを当該メンテナンスエージェントプログラム2に追加する。そしてさらに自身のメモリまたはハードディスク装置のメンテナンス順序テーブル51に設定された次の端末装置のアドレス(ここでは券売機10のアドレス2)を読み出して、前記メンテナンスエージェントプログラム2のヘッダを書き換えてネットワーク3上に送出する。
【0037】
ネットワーク3から前記メンテナンスエージェントプログラム2を読み込んだ端末装置(ここでは券売機10)は、前記と同様にヘッダを解析し、自身のアドレス(ここでは書き換えられたアドレス2)が書き込まれているか否かをチェックする。ここでヘッダに自身のアドレスが書き込まれている場合、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録して当該メンテナンスエージェントプログラム2を起動する。そして当該プログラムの処理を完了すると、実行結果ログ2aを追加するとともに、自身のメモリまたはハードディスク装置のメンテナンス順序テーブル51に設定された次の端末装置のアドレス(ここではアドレス3)を読み出して、前記メンテナンスエージェントプログラム2のヘッダを書き換えてネットワーク3上に送出する。
【0038】
このように図5に示した実施例によれば、保守サーバ1は、メンテナンスエージェントプログラム2のヘッダにメンテナンス対象となる最初の端末装置のアドレスのみを書き込めばよい。
なお、図4、図5のどちらの方法であれ、最後は保守サーバ1のアドレスが設定されることになる。すなわち、図4の方法では、メンテナンスエージェント2のヘッダ内最後の対象端末アドレスの後に保守サーバ1自身のアドレスを設定して送信する。図5の方法では、最後の対象端末のメンテナンス順序テーブル51の次の送信アドレスエリアに、保守サーバ1のアドレスを設定しておけばよい。これにより、最後のメンテナンス対象端末で処理が実行された後、ネットワーク3上に送出されたメンテナンスエージェント2は、保守サーバ1へ回収されることになる。
【0039】
図6は、前記メンテナンスエージェントプログラム2の実行結果の出力方法について説明した図である。
【0040】
前記図4または図5に示したようにメンテナンスエージェントプログラム2が各端末装置(券売機6,10)を巡回してメンテナンスプログラムを実行しその実行結果ログ2aを収集し、全ての対象端末装置を巡回し終えると、前記保守サーバ1がネットワーク3上から当該メンテナンスエージェントプログラム2を回収する。
なお、図6に示すように、実行結果ログ2aは端末毎に各々記録される。実行結果ログ2aは、L1,L2等の、保守チェックの項目毎のメンテナンス結果情報から構成される。たとえば、券売機6のコインメカについてセンサチェックが実行されると、L2にそのメンテナンス結果情報が記録される。図13は、実行結果ログ内のメンテナンス結果情報Lnの一例を示す図である。メンテナンス・ナンバーは、たとえばメカ種別、保守チェック項目の組合せで決まる番号であり、ここでは後述のメンテナンスプログラムa1〜anの番号nに対応している。メカ種別は、コインメカA、発券メカAなどのチェック対象の種別を表わすデータである。なお、メカ以外に先述の券売機全体の制御部などのチェック対象も種別として含めてもよい。保守チェック項目は、バージョンチェックやセンサチェックなどのチェック内容を表わすデータである。年月日、時刻はチェックの実行日時を示す。チェック結果は、たとえばチェックのOK/NGなどの総合結果である。チェック結果詳細情報は、たとえば、バージョンチェックではインストールされているバージョン情報などが示されたり、センサチェックでは複数の対象センサの番号別に詳細に結果情報が区分されて示される。障害対応項目は、チェック結果がNGの場合に障害対応プログラム(後述)が起動され障害対応(復旧作業)を実行した場合は、その項目が格納される。障害対応結果は、障害対応のOK/NGなどの総合結果である。障害対応結果詳細情報は、障害対応結果を補足する詳細情報が格納される。なお、チェック結果、障害対応結果やそれらの詳細情報は、たとえば、エラーが検出された項目のフラグをセット状態(0→1)にするような形のデータであってもよい。また、数値データによりエラーの有無、種類や状態を区分するような形のデータであってもよい。また、これらの組合せであってもよい。
【0041】
保守サーバ1では、このメンテナンスエージェントプログラム2の実行結果ログ2aを端末毎に解析し、設定されたメンテナンス結果情報を読み出す。たとえばL2のメンテナンス結果情報は券売機におけるコインセンサのチェック結果を示すものであり実行結果ログ2a中の当該メンテナンス結果情報L2内のデータを解析する。エラー情報がある場合、保守サーバ1はエラー情報の内容に基づいてコインメカ用メンテナンス指示テーブル61より対応した警告文字、たとえば「コインメカのセンサワーニングが発生しています。センサ1,3を交換して下さい。」をメンテナンス情報としてディスプレイ装置1d上に表示する。また、印刷を指示された場合には、当該文面をプリンタ装置1eで印刷する。
なお、エラー情報だけでなく、正常結果のものも含め、保守チェック項目の実績をメンテナンス情報として全て表示、印刷するようにしてもよい。この際、各動作ハードウエア(メカ種別)毎に整理して表示、印刷すると見やすい。
【0042】
このように、保守サーバ1において、実行結果ログ2a内のエラー情報を対応する警告情報に変換して表示または印刷出力することにより、保守要員のメンテナンス作業を支援することができる。すなわち、保守要員はネットワーク配下においてエラーが出力された端末装置のみを巡回すればよく、保守要員の効率的な保守巡回が可能となる。しかも、エラー内容や保守作業内容を事前に知ることができるので、作業準備ができ、作業効率を高めることができる。
【0043】
図7は、本実施例のメンテナンスエージェントプログラム2を利用した課金情報の出力方法について説明した図である。
【0044】
前記と同様に、メンテナンスエージェントプログラム2が各端末装置(券売機6,10)を巡回してメンテナンスプログラムを実行しその実行結果ログ2aを収集し、全ての対象端末を巡回し終えると、前記保守サーバ1がネットワーク3上から当該メンテナンスエージェントプログラム2を回収する。
【0045】
保守サーバ1では、このメンテナンスエージェントプログラム2の実行結果ログ2aを解析し、設定されたメンテナンス結果情報を読み出す。ここではたとえば実行結果ログ2a内のメンテナンス結果情報としてL1が設定されて該メンテナンスエージェントプログラム2が回収された場合、このメンテナンス結果情報L1内のデータを解析し、保守チェック項目、障害対応項目などに対応する課金情報を保守サーバ1のハードディスク装置1b内に設定された課金テーブル71を参照して読み出すとともに、これに対応した課金情報をディスプレイ装置1dに表示する。ここで表示されるa1はコインメカA内のプログラムバージョンチェックという保守チェック項目のメンテナンスプログラム実施の課金情報であり、100円が課金されている。券売機6のコインメカAプログラムのバージョンが不一致となっており、プログラムの再ロードを障害対応項目b1として実施した場合を示している。この場合、プログラムの再ロードに500円の課金を必要としている。さらにコインメカAに対しては、センサチェックの保守チェック項目a2(費用200円)を実施しており、券売機6のコインメカAに対するメンテナンスの課金小計は800円となる例を示している。
【0046】
保守サーバ1の中央処理装置(CPU)はこのような課金情報を集計して合計金額をディスプレイ装置1dに出力する。また、プリンタ装置1eから印刷処理してもよいことは勿論である。
なお、課金の仕方としては、チェックの結果エラーになり障害対応プログラム(後述)が起動され障害対応(修復作業)を実行した場合に課金してもよいし、保守チェック項目自体の実行に対して課金する仕方であってもよい。あるいは、これらの併用であってもよい。これら課金の仕方は運用仕様による。また、保守サーバからのメンテナンスエージェント送信による障害対応プログラムの実行だけで対応できないような復旧作業(例えば部品交換や、原因の目視調査など)については、保守要員が実際に対応することになるが、その場合の保守要員の作業項目あるいは保守費用を、保守サーバ1のキーボード1fから入力操作することにより、メンテナンスエージェント送信による課金と合計できるようにしてもよい。また、上述の仕組みにより実際にメンテナンスエージェント送信や保守要員派遣を行う前に、保守作業の費用見積もりを出力する機能をサーバ1に設けてもよい。
【0047】
図9は、メンテナンスエージェントプログラムのフォーマットを詳細に示したものである。
【0048】
同図に示すように、メンテナンスエージェントプログラム2は、サービス識別エリア(ヘッダ)と、メンテナンスプログラムエリアと、実行結果ログエリア2aとで構成されている。
【0049】
サービス識別エリア(ヘッダ)には、機種識別設定エリアと、メンテナンス周期設定エリアと、専用機アドレス設定エリアとが設けられている。機種識別設定エリアは、券売機6、精算機5、改札機4等の機種に関する情報が設定されるようになっている。メンテナンス周期設定エリアにはメンテナンスの周期(たとえば月n回固定日に送信または不定期に送信)が設定されるようになっている。なお、図3に示したメンテナンスエージェントプログラム送信待機テーブル33はこのメンテナンス周期設定エリアと重畳して適用される。たとえば、保守サーバ1がこのメンテナンス周期設定エリアに基づいて当該メンテナンスエージェントプログラム2の送信日に該当していると判断した場合、メンテナンスエージェントプログラム送信待機テーブル33を参照して送信時刻を決定することになる。なお、送信時刻については、前述の時刻表データまたは通過人員データによるものでなくても、直接送信時刻を設定できるようにしてもよい。また、逐次手動で送信を行うことも可能である。
【0050】
端末装置アドレス設定エリアは、メンテナンス対象となる端末装置のアドレスを設定するエリアであり、図4および図5で説明したアドレスが設定されるようになっている。
【0051】
メンテナンスプログラムエリアには、図9の例においては、メモリ空容量チェックプログラム、プログラム・ハードウエアバージョンチェックプログラム(図2で説明したプログラムチェックモジュール11aも含む)、内部エラーカウンタチェックプログラム、ウィルスチェックプログラム等の各メンテナンスプログラム(メンテナンスモジュール)が格納されるようになっている。
上記の各メンテナンスプログラム(メンテナンスモジュール)は、図2で説明したように、各端末装置内部の機器構成毎、たとえば動作ハードウェア(メカ種別)毎に用意される。また、動作ハードウェアが異なってもメンテナンスプログラム(メンテナンスモジュール)が共有できる場合には、兼用する方法も考えられる。
なお、図9のメンテナンスプログラムエリアの構成要素では、図2と別の例を示したが、図2で示したプログラムバージョンチェックモジュール11aやセンサチェックモジュール11bなども、上記のメンテナンスプログラム(メンテナンスモジュール)の例である。
なお、図9で括弧内に示したb1〜bnは、メンテナンスプログラム(メンテナンスモジュール)a1〜anに対応する障害対応プログラム(障害対応モジュール)である。障害対応プログラムb1〜bnも、広い意味でのメンテナンスプログラムと考えてよい。メンテナンスプログラムa1〜anによる保守チェックの結果、エラーになった場合、対応する障害対応プログラムb1〜bnが必要により実行され、メンテナンスエージェントが自動的に障害復旧処理を行う。この障害対応プログラムb1〜bnは、図9の例では、対応するメンテナンスプログラムa1〜anと同じメンテナンスプログラムエリアに含まれている。あるいは、a1〜anの下のエリアに別に障害対応プログラムエリアを設けてもよい。また、後述のダウンロードされたメンテナンスプログラムの実行プログラム内に含まれていてもよい。あるいは、障害対応プログラムを格納した障害対応エージェントとしてエージェント自体を別に設けてもよい。
上記に述べたメンテナンスプログラムa1〜an、障害対応プログラムb1〜bnは、それ自体が保守チェック、障害対応の実行プログラムであってもよい。また、実行プログラムが大きくなる場合には、エージェント内のメンテナンスプログラムエリアには、別途保守サーバ1から保守チェックを実行する実行プログラム本体をダウンロードし起動するようなプログラムだけが、記述されているような仕組みであってもよい。両者の仕組みを混成して、エージェント内のメンテナンスプログラム毎に使い分けてもよい。さらに、エージェント内のメンテナンスプログラムエリアのメンテナンスプログラムa1〜an、障害対応プログラムb1〜bは、単純なコマンド形式の記述で構成され、各実行プログラム本体が、保守サーバ1からダウンロードされて自己起動するような方法でもよい。
【0052】
実行結果ログエリア2aには、図6および図7で説明したメンテナンス結果情報L1、L2等が設定されるようになっている。
【0053】
次に、このようなメンテナンスエージェントプログラム2を用いた処理の手順を図10〜図12を用いて説明する。
図10は、サーバーと各端末装置間のエージェントの移動と処理を示した概要図である。図の上から、サーバ1、券売機1、券売機2が順に示されている。Aは、メンテナンスエージェントを示し、anは各メンテナンスプログラム(メンテナンスモジュール)、bnは各障害対応プログラム(障害対応モジュール)を示す。
また、図11〜図12は、保守サーバ1(左側)と、端末装置である券売機6(右側)の処理概要の関係を示すフロー図である。
【0054】
まず、保守サーバ1は、メンテナンス条件等により必要なメンテナンスエージェントプログラム2を生成する(ステップS121)。この生成方法は図2で説明した通りである。
【0055】
このメンテナンスエージェントプログラム2は、ネットワーク3を介して各端末装置(ここでは券売機6,10等)に送信される(ステップS122)。このとき対象となる端末装置が当該プログラム2を取り込む処理は図4および図5に示した通りである(ステップS123)。
【0056】
前記プログラム2を取り込んだ端末装置(券売機6)では、メンテナンスエージェントプログラム2のメンテナンスプログラムエリアより各モジュールanを読み出して(ステップS125)当該端末装置内で該モジュールを実行する。このとき、必要に応じて保守サーバ1に対して新たな実行プログラムのダウンロード(DLL)を行ってもよい(ステップS126〜S129)。
【0057】
そしてこれらのメンテナンスプログラムを実行する(ステップS130)。このとき、プログラムエラーが発生した場合には(ステップS131:YES)、メンテナンスエージェントプログラム2に格納された障害対応プログラムbnを読み出して(ステップS132)実行する(ステップS137)。またこのような障害対応プログラムが存在しない場合には、前記保守サーバ1に対してダウンロード要求を行う(ステップS133〜S136)。
一方、メンテナンスプログラム実行による保守チェックでエラーが発生しない場合は(ステップS131:NO)、障害対応プログラムを読み出すことなく、未実行のメンテナンスプログラムが残っている場合は(ステップS138:NO)、次のメンテナンスプログラムanを読み込む処理へ移り(ステップS142→ステップ125)、以降同様に処理する。また、障害対応プログラムの実行(ステップS137)が終了した場合も、未実行のメンテナンスプログラムが残っている場合は(ステップS138:NO)、次のメンテナンスプログラムanを読み込む処理へ移る(ステップS142→ステップ125)。
【0058】
以上のようにして、メンテナンスエージェントプログラム2に格納された全てのメンテナンスプログラムを終了すると(ステップS138:YES)、実行結果を保守サーバに送信し(ステップS139)、メンテナンスを完了し、メンテナンスエージェントプログラム2は、ネットワーク3を介して次の端末装置(たとえば券売機10)に送信される(ステップS140)。
最後のメンテナンス対象の端末機器(券売機)でのメンテナンスを終了すると、メンテナンスプログラムエージェント2はサーバへ回収され、サーバ1において、メンテ状況の出力と、課金情報の作成が行われる(ステップS141)。
なお、上述でダウンロードしたプログラムについては、全てのメンテナンスプログラムの処理が各端末で終了した際に、あるいは、各メンテナンスプログラムの処理が終了した際に、自動的に消去するようにしておいてもよい。これにより、メンテナンスに必要な際だけ実行プログラムを格納しておくことになり、余分なメモリ容量の使用を回避することができる。
なお、図6、図7、図9の実施例においては、実行結果をメンテナンスエージェント2に実行ログ結果2aとして付加し、保守サーバ1がメンテナンスエージェント2を回収することにより、実行ログ結果を収集する方法を説明したが、それ以外の方法として、図10の▲4▼や、図12のステップS139で示すように、実行結果情報を各端末機器から保守サーバ1へ直接送信するようにしてもよい。
また、上述の実施形態では、メンテナンスプログラムの実行をすべて終了してから、次の該当端末が受信すべく、メンテナンスエージェントプログラム(エージェント)をネットワーク上へ送信したが、次の端末へ巡回させるためネットワーク上へエージェントを送信するタイミングは、端末においてメンテナンスプログラムの実行が終了する前に、あるいは実行する前とする方法もある。例えば、各端末は、メンテナンスエージェントプログラムを受信すると、その内容を自身のメモリ内にコピーして記憶し、実行する前にメンテナンスエージェントプログラムをネットワーク上へ送出する。その後、メモリ上に記憶した内容に従って、プログラムを実行し、必要により、保守サーバから実行プログラム本体をダウンロードして実行する。そして実行結果については、上述のように、各端末機器から保守サーバへ直接送信する。このようにすると、各端末は、自身より前の端末のメンテナンス実行が終了するまで待たされることがなくエージェントが巡回するので、並行してメンテナンスが実行され、システム全体のメンテナンス処理能力が向上する。
【発明の効果】
本発明により、各機器(端末装置)の大幅なハードウエアの追加なしに、人手に依存することなく、かつ各機器での処理に負担を与えないメンテナンスが可能となった。
【図面の簡単な説明】
【図1】本発明の実施例のシステム構成図
【図2】実施例におけるメンテナンスエージェントプログラムの生成方法を示す図
【図3】メンテナンスエージェントプログラムの送信タイミングの制御方法を示す図
【図4】端末装置におけるメンテナンスエージェントプログラムの取り込み方法を示す図(1)
【図5】端末装置におけるメンテナンスエージェントプログラムの取り込み方法を示す図(2)
【図6】保守サーバにおける実行結果の出力方法を示す図
【図7】保守サーバにおける課金情報の出力例を示す図
【図8】実施例のシステムブロック図
【図9】メンテナンスエージェントプログラムのフォーマット図
【図10】実施例の処理概要図
【図11】実施例の処理概要を示すフロー図(1)
【図12】実施例の処理概要を示すフロー図(2)
【図13】実施例の実行結果ログ内のメンテナンス結果情報Lnの内容を示す図
【符号の説明】
1 保守サーバ
1a 中央処理装置(CPU)
1b ハードディスク装置
1c 通信コントローラ
1d ディスプレイ装置
1e プリンタ装置
2 メンテナンスエージェントプログラム
2a 実行結果ログ
3 ネットワーク
4 改札機
5 精算機
6 券売機
7 改札機
8 精算機
10 券売機
11 メンテナンスデータベース
12 券売機構成データベース
13 精算機構成データベース
31 時刻表データベース
32 通過人員データベース
33 メンテナンスエージェントプログラム送信待機テーブル
【発明の属する技術分野】
本発明は、ネットワークに接続された端末装置上のアプリケーションプログラム等に対して、メンテナンス状態を調査・診断し、保守センターに設置されたサーバに各端末装置の状態を通知するエージェント機能を利用したメンテナンスシステムに関する。
【0002】
【従来の技術】
従来技術において、各所に設置された機器のメンテナンスのために、メンテナンス要員は、定期的に各所を巡回しその機器毎に調査・保守を行うのが通例であった。
【0003】
しかし、ネットワーク技術が発達した今日においては、各所に設置された機器をネットワークで接続し、種々のメンテナンスプログラムを各機器にインストールしておき、保守状況を上位の保守サーバに通知する仕組みも考えられている。
【0004】
たとえば、ネットワーク管理情報の収集技術としては特開平10−247169号公報や特開平11−252209号公報が挙げられる。
【0005】
【発明が解決しようとする課題】
しかし、このようなネットワーク管理技術では、各機器に個別にメンテナンスプログラムをインストールしておかなくてはならないため、ハードディスク装置やメモリを増設しなければならず機器毎に物理的・経済的な負担が大きくなるという問題があった。
【0006】
また、新しいメンテナンス項目が追加される度に全機器に新たなメンテナンスプログラムをインストールし直さなければならず、そのインストールもオペレータの人手に依存しなければならないため効率的ではなかった。
【0007】
さらに、常に各機器のメンテナンスプログラムを常駐させておかなければならないため、各機器の中央処理装置(CPU)の負荷が大きかった。
【0008】
本発明は、このような点に鑑みてなされたものであり、各機器の大幅なハードウエアの追加なしに、人手に依存することなく、かつ各機器での処理に負担を与えないメンテナンス技術を提供することを技術的課題とする。
【0009】
【課題を解決するための手段】
本発明は、前記課題を解決するために以下の手段を採用した。
本発明の第1の手段は、保守サーバで生成されたメンテナンスエージェントプログラムをネットワークを介して端末装置で順次実行するメンテナンスシステムにおいて、保守サーバにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成し、前記端末装置において、前記保守サーバより送出されたメンテナンスエージェントプログラムを受信して自身を対象としたものか否かを判別し、前記端末装置において、前記メンテナンスエージェントプログラムを実行し、その実行結果情報をネットワーク上に送出し、前記保守サーバにおいて、その実行結果情報を解析・出力するメンテナンスシステムとしたものである。
第2の手段は、ネットワークで接続された端末装置のメンテナンスを保守サーバで管理する方法であって、保守サーバにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成するステップと、前記で生成されたメンテナンスエージェントプログラムを前記端末装置に送信するステップと、端末装置内で実行されたメンテナンスエージェントプログラムの実行結果情報を受信するステップと、受信した実行結果情報を解析し、解析結果を出力するステップとからなる保守サーバを用いたメンテナンス方法である。
第3の手段は、ネットワークで接続された保守サーバに対してメンテナンス実行機能を備えた端末装置であって、保守サーバで生成されたメンテナンスエージェントプログラムを受信する手段と、受信したメンテナンスエージェントプログラムが自身を対象としたものか否かを判定する手段と、前記プログラムが自身を対象としたものであるときに当該メンテナンスエージェントプログラムを格納する手段と、格納された前記メンテナンスエージェントプログラムを実行する手段と、前記プログラムの実行結果情報を保守サーバに送信する手段とからなる端末装置である。
第4の手段は、前記第2の手段において、前記保守サーバが、端末装置毎のハードウエア情報を登録した機器構成データベースと、ハードウエア毎のメンテナンスモジュール情報を登録したメンテナンスデータベースとを有しており、当該機器構成データベースとメンテナンスデータベースとを参照することによりメンテナンスエージェントプログラムに格納するメンテナンスモジュールを決定するようにしたものである。
第5の手段は、前記第2の手段において、鉄道の駅システムのメンテナンス方法に適用したものであり、前記保守サーバに各駅毎の車両の発着時刻情報を有し、当該発着時刻情報に基づいて閑散時間帯に前記メンテナンスエージェントプログラムをネットワークに送出するようにしたものである。
第6の手段は、前記第2の手段において、鉄道の駅システムのメンテナンス方法に適用したものであり、前記保守サーバに各駅毎の乗降客の改札通過情報を有し、当該改札通過情報に基づいて閑散時間帯に前記メンテナンスエージェントプログラムをネットワークに送出するようにしたものである。
【0010】
第7の手段は、前記第3の手段において、前記メンテナンスエージェントプログラムを受信した後に、次の端末が受信すべく該メンテナンスエージェントプログラムをネットワーク上へ送出するようにしたものである。
第8の手段は、前記第2の手段において、前記端末装置から受信した前記実行結果情報に基づいてメンテナンス情報を生成し出力するようにしたものである。第9の手段は、前記第2の手段において、前記実行結果情報の出力に基づいた課金情報を出力するようにしたものである。
第10の手段は、ネットワークで接続された端末装置のメンテナンスを管理する保守サーバであって、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成する手段と、前記で生成されたメンテナンスエージェントプログラムを前記端末装置に送信する手段と、端末装置内で実行されたメンテナンスエージェントプログラムの実行結果情報を受信する手段と、受信したメンテナンスエージェントプログラムの実行結果情報を解析し、解析結果を出力する手段とからなる保守サーバである。
第11の手段は、前記第2の手段において、前記実行結果情報を、前記メンテナンスエージェントプログラムの付加情報として当該メンテナンスエージェントプログラムとともに保守サーバにより受信されるようにしたものである。
第12の手段は、前記第2の手段において、前記メンテナンスの時期に関する情報を有しており、当該時期が到来すると前記メンテナンスエージェントプログラムを生成し、前記端末装置に送信するようにしたものである。
第13の手段は、前記第2の手段において、前記端末装置が、前記メンテナンスエージェントプログラムに記述された内容に基づいて所定のメンテナンス実行プログラム本体のダウンロードを保守サーバに要求するようにしたものである。第14の手段は、前記第2の手段において、前記端末装置が、前記メンテナンスエージェントプログラムの実行の結果、エラーを発生したときに障害対応プログラムの起動、または保守サーバへの障害対応プログラムのダウンロード要求を行うようにしたものである。
【0011】
【発明の実施の形態】
【実施例】
以下、図面に基づいて、本発明の実施の形態を説明する。
図1は、本発明の実施例におけるシステム構成図である。
【0012】
本実施例のネットワークは鉄道の駅システムであり、保守サーバ1を中心に、ネットワーク3を介して改札機4,7、精算機5,8、券売機6,10が接続されている。本実施例ではメンテナンス対象となる端末装置を券売機6,10として説明する。すなわち、保守サーバ1で生成されたメンテナンスエージェントプログラム1がネットワーク3を介して券売機6および10のメンテナンスを実行し、保守サーバ2に帰還するまでを説明する。
【0013】
図8は前記の図1に対応したシステム構成図である。同図に示すように、保守サーバ1ならびに改札機4、精算機5および券売機6はコンピュータシステムで構成されている。たとえば、保守サーバ1の場合、中央処理装置(CPU)1aを中心に、ネットワークと接続するための通信コントローラ1cとハードディスク装置1bを有している。また、外部装置としてディスプレイ装置1dおよびプリンタ装置1eおよびキーボード1fを有している。
【0014】
前記ハードディスク装置1b内には、オペレーティングシステムとともに、図2に示すように、メンテナンスデータベース11、券売機構成データベース12および精算機構成データベース13、改札機構成データベース14等が格納されており、これらのデータベースを参照してメンテナンスエージェントプログラム2が生成されるようになっている。
【0015】
また、ハードディスク装置1b内には、さらに図3に示すように時刻表データベース31,駅毎の通過人員データベース32および送信待機テーブル33を有している。
【0016】
他方、図8に示すように、端末装置である券売機6は、券売機全体の制御部を構成する中央処理装置(CPU)6aを中心に、ネットワークと接続するための通信コントローラ6bと、プログラムや売上げデータ等を格納するメモリ6dと、接客用や係員操作用のディスプレイ6cおよび入力操作部6fを有している。以上は精算機、改札機もほぼ同様の構成であるが、それぞれ異なる動作ハードウェア(メカ4e,5e,6e)を有している。この動作ハードウェアは、たとえば改札機4の場合、券搬送機構、扉開閉機構等がこれに該当する。精算機5や券売機6の場合は、硬貨処理機構、紙幣処理機構、発券処理機構、カード処理機構等がこれに該当する。なお、各動作ハードウェア(メカ4e,5e,6e)は、各々の中にCPU(図示せず)を持つものもある。
【0017】
図2は、メンテナンスエージェントプログラム2を生成するデータベース構成を説明している。同図に示すように、保守サーバ1内のハードディスク装置1bに格納されたデータベースは、保守に関する機構毎のモジュール群(プログラム単位)であるメンテナンスデータベース11と、対象となる券売機6、精算機5および改札機4の機種別のハードウエアおよびソフトウエア構成を示すデータベース(機器別構成データベース12,13,14)とからなり、これらの組み合わせによりメンテナンスエージェントプログラム2が生成される。
【0018】
たとえば、券売機6に関しては、保守サーバ1の中央処理装置(CPU)は、エージェントプログラム生成プログラム(図示せず)をハードディスク装置1bから読み込むと、券売機構成データベース12を参照し、対象となる券売機6の機器構成情報を取得する。この場合、同図ではコインメカA(12a)と発券メカA(12b)とで構成されているため、メンテナンスデータベース11のコインメカAに関するモジュール、すなわちプログラムバージョンチェックモジュール11aとセンサチェックモジュール11bとを読み出す。
【0019】
同様にして発券メカA(12b)に関するモジュール、すなわちプログラムバージョンチェックモジュール11cとセンサチェックモジュール11dとを読み出す。そして、これらのモジュールを結合して券売機用メンテナンスエージェントプログラム2を生成する。
なお、上述のようなメカに関するモジュール以外にも、たとえばCPU6aを中心に構成され各メカと券売機全体の制御を行う制御部に関するモジュールがあってもよい。
このように各機種の機器構成に応じて、メンテナンスモジュール(メンテナンスプログラム)を組合せることにより、メンテナンスエージェントプログラムを生成するので、各機器に応じた適切な保守チェックが可能となる。また、プログラムをモジュール化しているので、大規模なプログラムを組む必要がなく、同一のメカを搭載する機器については、メンテナンスプログラムをモジュールとして共用でき、保守サーバのハードディスク容量やメモリ容量も節約できる。さらに、新しい機種の端末機器ができても、機器別構成データベースを追加し、新規の構成部分がある場合は、必要によりその部分についてのみメンテナンスモジュールを作成すれば、新規の保守サービスを順次、容易に追加できる。
【0020】
図3は、以上のようにして生成されたメンテナンスエージェントプログラム2の保守サーバ1からの送信タイミングを設定する方法を示している。
【0021】
同図に示すように、図2で生成された券売機メンテナンスエージェントプログラム2は、メンテナンスエージェント送信待機テーブル33に記録された時間情報にしたがって保守サーバ1よりネットワーク3に対して送出される。
【0022】
すなわち、保守サーバ1の中央処理装置(CPU)は、時刻表データベース31と通過人員データベース32とを参照し、駅毎の券売機の稼働効率の低い時間にメンテナンス対象となる券売機に対して送信すべくメンテナンスエージェントプログラム送信待機テーブル33を設定する。
【0023】
これは、駅の閑散時間に券売機6のメンテナンスを実行するためである。すなわち、券売機6は駅のラッシュ時(たとえば朝夕)には発券処理に最大限の処理速度が要求されるため、このような混雑時にはメンテナンスを実行すべきではない。一方、昼間や深夜の閑散時間には券売機6はあまり稼働しておらずメンテナンスを行ったとしても発券処理に支障を来すことは少ない。
【0024】
このような閑散時間の判断は、たとえば時刻表データベース31から得ることができる。電車の駅発着回数が少ない時間帯すなわち発着時刻の間隔が大きい時間帯は、券売機の稼働率も低い時間帯であるため、閑散時間と判断することができる。また、改札機4から得られた通過人員データベース32を参照して、この通過人員が少ない時間帯を、閑散時期であると判断する方法であってもよい。
【0025】
このように、本実施例では時刻表データや通過人員データ等から各駅の閑散時間を取得し、このような閑散時間にメンテナンスエージェントプログラム2を送信するようにしたため、各端末(ここでは券売機6)の発券処理に実質的に影響を与えることなくメンテナンスが実行できる。
【0026】
図4は、メンテナンス対象である券売機6におけるメンテナンスエージェントプログラム2の取り込み方法を示す図である。
【0027】
保守サーバ1からメンテナンスエージェントプログラム2が送信された後、このメンテナンスエージェントプログラム2はネットワーク転送データとしてネットワーク3に接続された各端末装置に順番に読み込まれる。このとき、メンテナンスエージェントプログラム2のヘッダには読み込むべき端末装置を特定するアドレス(ここでは券売機6,10のアドレス)が設定されており、このアドレスに該当する端末装置(券売機6,10)が当該メンテナンスエージェントプログラム2を自身のメモリ内に読み込む。
【0028】
同図において、メンテナンスエージェントプログラム2のヘッダに券売機6のアドレス(アドレス1)と券売機10のアドレス(アドレス2)が設定されている場合、ネットワーク3からメンテナンスエージェントプログラム2を受信した券売機6は、まずそのヘッダ情報を解析し、自身(券売機6)のアドレス(アドレス1)が書き込まれているか否かを判定する。ここで、自身のアドレスが書き込まれている場合には、当該メンテナンスエージェントプログラム2は自身(券売機6)に対して送信されたものであると判断し、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録する。
【0029】
ここで、自身のアドレスが書き込まれていない場合には、当該メンテナンスエージェントプログラム2を自身に取り込むことなく再度ネットワーク3に送出する。
【0030】
一方、前記メンテナンスエージェントプログラム2を取り込んだ場合、該メンテナンスエージェントプログラム2を券売機6内で起動してメンテナンス処理を開始する。このメンテナンス処理が完了すると、前記メンテナンスエージェントプログラム2に当該券売機6の実行結果ログ2a(図6参照)を追加して当該メンテナンスエージェントプログラム2を再度ネットワーク3上に送出する。
【0031】
ここで実行結果ログ2aとは、たとえばプログラムを実行した結果に基づいて、実施した保守チェックの内容、チェック結果、障害対応した内容、障害対応結果等のメンテナンス結果の記録情報である。図6に示すように、実行結果ログ2aは端末毎に各々記録される。
【0032】
ネットワーク3からメンテナンスエージェントプログラム2を受信した券売機10は、前記と同様にヘッダ情報を解析し、自身(券売機10)のアドレス(アドレス2)が書き込まれているか否かを判定する。ここで、自身のアドレスが書き込まれている場合には、当該メンテナンスエージェントプログラム2は自身(券売機10)に対して送信されたものであると判断し、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録する。
【0033】
そして、当該メンテナンスエージェントプログラム2を券売機10内で起動してメンテナンス処理を実行した後、その実行結果ログ2aをさらに追加して当該メンテナンスエージェントプログラム2を再度ネットワーク3上に送出する。
【0034】
前記図4に示したメンテナンスエージェントプログラム2には、そのヘッダに対象とする端末機器の全てのアドレスを登録した例だったが、これに限らず、保守サーバ1から送信されるメンテナンスエージェントプログラム2には、対象となる最初の端末装置のアドレス(たとえば券売機6に対するアドレス1)だけを設定するようにしてもよい。
【0035】
この場合、対象となる端末装置(券売機6)内のメモリまたはハードディスク装置内にメンテナンス対象とする同種の機器(次にメンテナンスを行うべき機器)を定義したメンテナンス順序テーブル51を持たせてもよい。図5はそれを示す実施例である。同図の場合、保守サーバ1から送出されるメンテナンスエージェントプログラム2のヘッダには最初のメンテナンス対象となる端末装置(券売機6)のアドレス(アドレス1)のみが登録されている。
【0036】
券売機6は、このメンテナンスエージェントプログラム2を読み込むと、ヘッダを解析し、自身のアドレス(アドレス1)が書き込まれているか否かをチェックする。ここでヘッダに自身のアドレスが書き込まれている場合、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録して当該メンテナンスエージェントプログラム2を起動する。そして当該プログラムの処理を完了すると、その実行結果ログ2aを当該メンテナンスエージェントプログラム2に追加する。そしてさらに自身のメモリまたはハードディスク装置のメンテナンス順序テーブル51に設定された次の端末装置のアドレス(ここでは券売機10のアドレス2)を読み出して、前記メンテナンスエージェントプログラム2のヘッダを書き換えてネットワーク3上に送出する。
【0037】
ネットワーク3から前記メンテナンスエージェントプログラム2を読み込んだ端末装置(ここでは券売機10)は、前記と同様にヘッダを解析し、自身のアドレス(ここでは書き換えられたアドレス2)が書き込まれているか否かをチェックする。ここでヘッダに自身のアドレスが書き込まれている場合、当該メンテナンスエージェントプログラム2を自身のメモリまたはハードディスク装置に登録して当該メンテナンスエージェントプログラム2を起動する。そして当該プログラムの処理を完了すると、実行結果ログ2aを追加するとともに、自身のメモリまたはハードディスク装置のメンテナンス順序テーブル51に設定された次の端末装置のアドレス(ここではアドレス3)を読み出して、前記メンテナンスエージェントプログラム2のヘッダを書き換えてネットワーク3上に送出する。
【0038】
このように図5に示した実施例によれば、保守サーバ1は、メンテナンスエージェントプログラム2のヘッダにメンテナンス対象となる最初の端末装置のアドレスのみを書き込めばよい。
なお、図4、図5のどちらの方法であれ、最後は保守サーバ1のアドレスが設定されることになる。すなわち、図4の方法では、メンテナンスエージェント2のヘッダ内最後の対象端末アドレスの後に保守サーバ1自身のアドレスを設定して送信する。図5の方法では、最後の対象端末のメンテナンス順序テーブル51の次の送信アドレスエリアに、保守サーバ1のアドレスを設定しておけばよい。これにより、最後のメンテナンス対象端末で処理が実行された後、ネットワーク3上に送出されたメンテナンスエージェント2は、保守サーバ1へ回収されることになる。
【0039】
図6は、前記メンテナンスエージェントプログラム2の実行結果の出力方法について説明した図である。
【0040】
前記図4または図5に示したようにメンテナンスエージェントプログラム2が各端末装置(券売機6,10)を巡回してメンテナンスプログラムを実行しその実行結果ログ2aを収集し、全ての対象端末装置を巡回し終えると、前記保守サーバ1がネットワーク3上から当該メンテナンスエージェントプログラム2を回収する。
なお、図6に示すように、実行結果ログ2aは端末毎に各々記録される。実行結果ログ2aは、L1,L2等の、保守チェックの項目毎のメンテナンス結果情報から構成される。たとえば、券売機6のコインメカについてセンサチェックが実行されると、L2にそのメンテナンス結果情報が記録される。図13は、実行結果ログ内のメンテナンス結果情報Lnの一例を示す図である。メンテナンス・ナンバーは、たとえばメカ種別、保守チェック項目の組合せで決まる番号であり、ここでは後述のメンテナンスプログラムa1〜anの番号nに対応している。メカ種別は、コインメカA、発券メカAなどのチェック対象の種別を表わすデータである。なお、メカ以外に先述の券売機全体の制御部などのチェック対象も種別として含めてもよい。保守チェック項目は、バージョンチェックやセンサチェックなどのチェック内容を表わすデータである。年月日、時刻はチェックの実行日時を示す。チェック結果は、たとえばチェックのOK/NGなどの総合結果である。チェック結果詳細情報は、たとえば、バージョンチェックではインストールされているバージョン情報などが示されたり、センサチェックでは複数の対象センサの番号別に詳細に結果情報が区分されて示される。障害対応項目は、チェック結果がNGの場合に障害対応プログラム(後述)が起動され障害対応(復旧作業)を実行した場合は、その項目が格納される。障害対応結果は、障害対応のOK/NGなどの総合結果である。障害対応結果詳細情報は、障害対応結果を補足する詳細情報が格納される。なお、チェック結果、障害対応結果やそれらの詳細情報は、たとえば、エラーが検出された項目のフラグをセット状態(0→1)にするような形のデータであってもよい。また、数値データによりエラーの有無、種類や状態を区分するような形のデータであってもよい。また、これらの組合せであってもよい。
【0041】
保守サーバ1では、このメンテナンスエージェントプログラム2の実行結果ログ2aを端末毎に解析し、設定されたメンテナンス結果情報を読み出す。たとえばL2のメンテナンス結果情報は券売機におけるコインセンサのチェック結果を示すものであり実行結果ログ2a中の当該メンテナンス結果情報L2内のデータを解析する。エラー情報がある場合、保守サーバ1はエラー情報の内容に基づいてコインメカ用メンテナンス指示テーブル61より対応した警告文字、たとえば「コインメカのセンサワーニングが発生しています。センサ1,3を交換して下さい。」をメンテナンス情報としてディスプレイ装置1d上に表示する。また、印刷を指示された場合には、当該文面をプリンタ装置1eで印刷する。
なお、エラー情報だけでなく、正常結果のものも含め、保守チェック項目の実績をメンテナンス情報として全て表示、印刷するようにしてもよい。この際、各動作ハードウエア(メカ種別)毎に整理して表示、印刷すると見やすい。
【0042】
このように、保守サーバ1において、実行結果ログ2a内のエラー情報を対応する警告情報に変換して表示または印刷出力することにより、保守要員のメンテナンス作業を支援することができる。すなわち、保守要員はネットワーク配下においてエラーが出力された端末装置のみを巡回すればよく、保守要員の効率的な保守巡回が可能となる。しかも、エラー内容や保守作業内容を事前に知ることができるので、作業準備ができ、作業効率を高めることができる。
【0043】
図7は、本実施例のメンテナンスエージェントプログラム2を利用した課金情報の出力方法について説明した図である。
【0044】
前記と同様に、メンテナンスエージェントプログラム2が各端末装置(券売機6,10)を巡回してメンテナンスプログラムを実行しその実行結果ログ2aを収集し、全ての対象端末を巡回し終えると、前記保守サーバ1がネットワーク3上から当該メンテナンスエージェントプログラム2を回収する。
【0045】
保守サーバ1では、このメンテナンスエージェントプログラム2の実行結果ログ2aを解析し、設定されたメンテナンス結果情報を読み出す。ここではたとえば実行結果ログ2a内のメンテナンス結果情報としてL1が設定されて該メンテナンスエージェントプログラム2が回収された場合、このメンテナンス結果情報L1内のデータを解析し、保守チェック項目、障害対応項目などに対応する課金情報を保守サーバ1のハードディスク装置1b内に設定された課金テーブル71を参照して読み出すとともに、これに対応した課金情報をディスプレイ装置1dに表示する。ここで表示されるa1はコインメカA内のプログラムバージョンチェックという保守チェック項目のメンテナンスプログラム実施の課金情報であり、100円が課金されている。券売機6のコインメカAプログラムのバージョンが不一致となっており、プログラムの再ロードを障害対応項目b1として実施した場合を示している。この場合、プログラムの再ロードに500円の課金を必要としている。さらにコインメカAに対しては、センサチェックの保守チェック項目a2(費用200円)を実施しており、券売機6のコインメカAに対するメンテナンスの課金小計は800円となる例を示している。
【0046】
保守サーバ1の中央処理装置(CPU)はこのような課金情報を集計して合計金額をディスプレイ装置1dに出力する。また、プリンタ装置1eから印刷処理してもよいことは勿論である。
なお、課金の仕方としては、チェックの結果エラーになり障害対応プログラム(後述)が起動され障害対応(修復作業)を実行した場合に課金してもよいし、保守チェック項目自体の実行に対して課金する仕方であってもよい。あるいは、これらの併用であってもよい。これら課金の仕方は運用仕様による。また、保守サーバからのメンテナンスエージェント送信による障害対応プログラムの実行だけで対応できないような復旧作業(例えば部品交換や、原因の目視調査など)については、保守要員が実際に対応することになるが、その場合の保守要員の作業項目あるいは保守費用を、保守サーバ1のキーボード1fから入力操作することにより、メンテナンスエージェント送信による課金と合計できるようにしてもよい。また、上述の仕組みにより実際にメンテナンスエージェント送信や保守要員派遣を行う前に、保守作業の費用見積もりを出力する機能をサーバ1に設けてもよい。
【0047】
図9は、メンテナンスエージェントプログラムのフォーマットを詳細に示したものである。
【0048】
同図に示すように、メンテナンスエージェントプログラム2は、サービス識別エリア(ヘッダ)と、メンテナンスプログラムエリアと、実行結果ログエリア2aとで構成されている。
【0049】
サービス識別エリア(ヘッダ)には、機種識別設定エリアと、メンテナンス周期設定エリアと、専用機アドレス設定エリアとが設けられている。機種識別設定エリアは、券売機6、精算機5、改札機4等の機種に関する情報が設定されるようになっている。メンテナンス周期設定エリアにはメンテナンスの周期(たとえば月n回固定日に送信または不定期に送信)が設定されるようになっている。なお、図3に示したメンテナンスエージェントプログラム送信待機テーブル33はこのメンテナンス周期設定エリアと重畳して適用される。たとえば、保守サーバ1がこのメンテナンス周期設定エリアに基づいて当該メンテナンスエージェントプログラム2の送信日に該当していると判断した場合、メンテナンスエージェントプログラム送信待機テーブル33を参照して送信時刻を決定することになる。なお、送信時刻については、前述の時刻表データまたは通過人員データによるものでなくても、直接送信時刻を設定できるようにしてもよい。また、逐次手動で送信を行うことも可能である。
【0050】
端末装置アドレス設定エリアは、メンテナンス対象となる端末装置のアドレスを設定するエリアであり、図4および図5で説明したアドレスが設定されるようになっている。
【0051】
メンテナンスプログラムエリアには、図9の例においては、メモリ空容量チェックプログラム、プログラム・ハードウエアバージョンチェックプログラム(図2で説明したプログラムチェックモジュール11aも含む)、内部エラーカウンタチェックプログラム、ウィルスチェックプログラム等の各メンテナンスプログラム(メンテナンスモジュール)が格納されるようになっている。
上記の各メンテナンスプログラム(メンテナンスモジュール)は、図2で説明したように、各端末装置内部の機器構成毎、たとえば動作ハードウェア(メカ種別)毎に用意される。また、動作ハードウェアが異なってもメンテナンスプログラム(メンテナンスモジュール)が共有できる場合には、兼用する方法も考えられる。
なお、図9のメンテナンスプログラムエリアの構成要素では、図2と別の例を示したが、図2で示したプログラムバージョンチェックモジュール11aやセンサチェックモジュール11bなども、上記のメンテナンスプログラム(メンテナンスモジュール)の例である。
なお、図9で括弧内に示したb1〜bnは、メンテナンスプログラム(メンテナンスモジュール)a1〜anに対応する障害対応プログラム(障害対応モジュール)である。障害対応プログラムb1〜bnも、広い意味でのメンテナンスプログラムと考えてよい。メンテナンスプログラムa1〜anによる保守チェックの結果、エラーになった場合、対応する障害対応プログラムb1〜bnが必要により実行され、メンテナンスエージェントが自動的に障害復旧処理を行う。この障害対応プログラムb1〜bnは、図9の例では、対応するメンテナンスプログラムa1〜anと同じメンテナンスプログラムエリアに含まれている。あるいは、a1〜anの下のエリアに別に障害対応プログラムエリアを設けてもよい。また、後述のダウンロードされたメンテナンスプログラムの実行プログラム内に含まれていてもよい。あるいは、障害対応プログラムを格納した障害対応エージェントとしてエージェント自体を別に設けてもよい。
上記に述べたメンテナンスプログラムa1〜an、障害対応プログラムb1〜bnは、それ自体が保守チェック、障害対応の実行プログラムであってもよい。また、実行プログラムが大きくなる場合には、エージェント内のメンテナンスプログラムエリアには、別途保守サーバ1から保守チェックを実行する実行プログラム本体をダウンロードし起動するようなプログラムだけが、記述されているような仕組みであってもよい。両者の仕組みを混成して、エージェント内のメンテナンスプログラム毎に使い分けてもよい。さらに、エージェント内のメンテナンスプログラムエリアのメンテナンスプログラムa1〜an、障害対応プログラムb1〜bは、単純なコマンド形式の記述で構成され、各実行プログラム本体が、保守サーバ1からダウンロードされて自己起動するような方法でもよい。
【0052】
実行結果ログエリア2aには、図6および図7で説明したメンテナンス結果情報L1、L2等が設定されるようになっている。
【0053】
次に、このようなメンテナンスエージェントプログラム2を用いた処理の手順を図10〜図12を用いて説明する。
図10は、サーバーと各端末装置間のエージェントの移動と処理を示した概要図である。図の上から、サーバ1、券売機1、券売機2が順に示されている。Aは、メンテナンスエージェントを示し、anは各メンテナンスプログラム(メンテナンスモジュール)、bnは各障害対応プログラム(障害対応モジュール)を示す。
また、図11〜図12は、保守サーバ1(左側)と、端末装置である券売機6(右側)の処理概要の関係を示すフロー図である。
【0054】
まず、保守サーバ1は、メンテナンス条件等により必要なメンテナンスエージェントプログラム2を生成する(ステップS121)。この生成方法は図2で説明した通りである。
【0055】
このメンテナンスエージェントプログラム2は、ネットワーク3を介して各端末装置(ここでは券売機6,10等)に送信される(ステップS122)。このとき対象となる端末装置が当該プログラム2を取り込む処理は図4および図5に示した通りである(ステップS123)。
【0056】
前記プログラム2を取り込んだ端末装置(券売機6)では、メンテナンスエージェントプログラム2のメンテナンスプログラムエリアより各モジュールanを読み出して(ステップS125)当該端末装置内で該モジュールを実行する。このとき、必要に応じて保守サーバ1に対して新たな実行プログラムのダウンロード(DLL)を行ってもよい(ステップS126〜S129)。
【0057】
そしてこれらのメンテナンスプログラムを実行する(ステップS130)。このとき、プログラムエラーが発生した場合には(ステップS131:YES)、メンテナンスエージェントプログラム2に格納された障害対応プログラムbnを読み出して(ステップS132)実行する(ステップS137)。またこのような障害対応プログラムが存在しない場合には、前記保守サーバ1に対してダウンロード要求を行う(ステップS133〜S136)。
一方、メンテナンスプログラム実行による保守チェックでエラーが発生しない場合は(ステップS131:NO)、障害対応プログラムを読み出すことなく、未実行のメンテナンスプログラムが残っている場合は(ステップS138:NO)、次のメンテナンスプログラムanを読み込む処理へ移り(ステップS142→ステップ125)、以降同様に処理する。また、障害対応プログラムの実行(ステップS137)が終了した場合も、未実行のメンテナンスプログラムが残っている場合は(ステップS138:NO)、次のメンテナンスプログラムanを読み込む処理へ移る(ステップS142→ステップ125)。
【0058】
以上のようにして、メンテナンスエージェントプログラム2に格納された全てのメンテナンスプログラムを終了すると(ステップS138:YES)、実行結果を保守サーバに送信し(ステップS139)、メンテナンスを完了し、メンテナンスエージェントプログラム2は、ネットワーク3を介して次の端末装置(たとえば券売機10)に送信される(ステップS140)。
最後のメンテナンス対象の端末機器(券売機)でのメンテナンスを終了すると、メンテナンスプログラムエージェント2はサーバへ回収され、サーバ1において、メンテ状況の出力と、課金情報の作成が行われる(ステップS141)。
なお、上述でダウンロードしたプログラムについては、全てのメンテナンスプログラムの処理が各端末で終了した際に、あるいは、各メンテナンスプログラムの処理が終了した際に、自動的に消去するようにしておいてもよい。これにより、メンテナンスに必要な際だけ実行プログラムを格納しておくことになり、余分なメモリ容量の使用を回避することができる。
なお、図6、図7、図9の実施例においては、実行結果をメンテナンスエージェント2に実行ログ結果2aとして付加し、保守サーバ1がメンテナンスエージェント2を回収することにより、実行ログ結果を収集する方法を説明したが、それ以外の方法として、図10の▲4▼や、図12のステップS139で示すように、実行結果情報を各端末機器から保守サーバ1へ直接送信するようにしてもよい。
また、上述の実施形態では、メンテナンスプログラムの実行をすべて終了してから、次の該当端末が受信すべく、メンテナンスエージェントプログラム(エージェント)をネットワーク上へ送信したが、次の端末へ巡回させるためネットワーク上へエージェントを送信するタイミングは、端末においてメンテナンスプログラムの実行が終了する前に、あるいは実行する前とする方法もある。例えば、各端末は、メンテナンスエージェントプログラムを受信すると、その内容を自身のメモリ内にコピーして記憶し、実行する前にメンテナンスエージェントプログラムをネットワーク上へ送出する。その後、メモリ上に記憶した内容に従って、プログラムを実行し、必要により、保守サーバから実行プログラム本体をダウンロードして実行する。そして実行結果については、上述のように、各端末機器から保守サーバへ直接送信する。このようにすると、各端末は、自身より前の端末のメンテナンス実行が終了するまで待たされることがなくエージェントが巡回するので、並行してメンテナンスが実行され、システム全体のメンテナンス処理能力が向上する。
【発明の効果】
本発明により、各機器(端末装置)の大幅なハードウエアの追加なしに、人手に依存することなく、かつ各機器での処理に負担を与えないメンテナンスが可能となった。
【図面の簡単な説明】
【図1】本発明の実施例のシステム構成図
【図2】実施例におけるメンテナンスエージェントプログラムの生成方法を示す図
【図3】メンテナンスエージェントプログラムの送信タイミングの制御方法を示す図
【図4】端末装置におけるメンテナンスエージェントプログラムの取り込み方法を示す図(1)
【図5】端末装置におけるメンテナンスエージェントプログラムの取り込み方法を示す図(2)
【図6】保守サーバにおける実行結果の出力方法を示す図
【図7】保守サーバにおける課金情報の出力例を示す図
【図8】実施例のシステムブロック図
【図9】メンテナンスエージェントプログラムのフォーマット図
【図10】実施例の処理概要図
【図11】実施例の処理概要を示すフロー図(1)
【図12】実施例の処理概要を示すフロー図(2)
【図13】実施例の実行結果ログ内のメンテナンス結果情報Lnの内容を示す図
【符号の説明】
1 保守サーバ
1a 中央処理装置(CPU)
1b ハードディスク装置
1c 通信コントローラ
1d ディスプレイ装置
1e プリンタ装置
2 メンテナンスエージェントプログラム
2a 実行結果ログ
3 ネットワーク
4 改札機
5 精算機
6 券売機
7 改札機
8 精算機
10 券売機
11 メンテナンスデータベース
12 券売機構成データベース
13 精算機構成データベース
31 時刻表データベース
32 通過人員データベース
33 メンテナンスエージェントプログラム送信待機テーブル
Claims (14)
- 保守サーバで生成されたメンテナンスエージェントプログラムをネットワークを介して端末装置で順次実行するメンテナンスシステムにおいて、
保守サーバにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成し、
前記端末装置において、前記保守サーバより送出されたメンテナンスエージェントプログラムを受信して自身を対象としたものか否かを判別し、
対象であるときに前記端末装置において、前記メンテナンスエージェントプログラムを実行し、その実行結果情報をネットワーク上に送出し、
前記保守サーバにおいて、その実行結果情報を解析・出力するエージェント利用メンテナンスシステム。 - ネットワークで接続された端末装置のメンテナンスを保守サーバで管理する方法であって、
保守サーバにおいて、少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成するステップと、
前記で生成されたメンテナンスエージェントプログラムを前記端末装置に送信するステップと、
端末装置内で実行されたメンテナンスエージェントプログラムの実行結果情報を受信するステップと、
受信した実行結果情報を解析し、解析結果を出力するステップとからなる保守サーバを用いたエージェント利用メンテナンス方法。 - ネットワークで接続された保守サーバに対してメンテナンス実行機能を備えた端末装置であって、
保守サーバで生成されたメンテナンスエージェントプログラムを受信する手段と、
受信したメンテナンスエージェントプログラムが自身を対象としたものか否かを判定する手段と、
前記プログラムが自身を対象としたものであるときに当該メンテナンスエージェントプログラムを格納する手段と、
格納された前記メンテナンスエージェントプログラムを実行する手段と、
前記プログラムの実行結果情報を保守サーバに送信する手段とからなる端末装置。 - 前記保守サーバは、端末装置毎のハードウエア情報を登録した機器構成データベースと、ハードウエア毎のメンテナンスモジュール情報を登録したメンテナンスデータベースとを有しており、当該機器構成データベースとメンテナンスデータベースとを参照することによりメンテナンスエージェントプログラムに格納するメンテナンスモジュールを決定する請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。
- 前記保守サーバを用いたエージェント利用メンテナンス方法は鉄道の駅システムのエージェント利用メンテナンス方法であり、
前記保守サーバには各駅毎の車両の発着時刻情報を有しており、当該発着時刻情報に基づいて閑散時間帯に前記メンテナンスエージェントプログラムをネットワークに送出するようにした請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。 - 前記保守サーバを用いたエージェント利用メンテナンス方法は鉄道の駅システムのエージェント利用メンテナンス方法であり、
前記保守サーバには各駅毎の乗降客の改札通過情報を有しており、当該改札通過情報に基づいて閑散時間帯に前記メンテナンスエージェントプログラムをネットワークに送出するようにした請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。 - 前記端末装置は、前記メンテナンスエージェントプログラムを受信し、次の該当端末が受信すべく該メンテナンスエージェントプログラムをネットワーク上へ送出する請求項3記載の端末装置。
- 前記端末装置から受信した前記実行結果情報に基づいてメンテナンス情報を生成し出力する請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。
- 前記実行結果情報に基づいた課金情報を出力する請求項2記載のエージェント利用メンテナンス方法。
- ネットワークで接続された端末装置のメンテナンスを管理する保守サーバであって、
少なくともメンテナンス対象となる端末装置の情報と、メンテナンスの内容に関する情報とのいずれかに基づいてメンテナンスエージェントプログラムを生成する手段と、
前記で生成されたメンテナンスエージェントプログラムを前記端末装置に送信する手段と、端末装置内で実行されたメンテナンスエージェントプログラムの実行結果情報を受信する手段と、
受信したメンテナンスエージェントプログラムの実行結果情報を解析し、解析結果を出力する手段とからなる保守サーバ。 - 前記実行結果情報は、前記メンテナンスエージェントプログラムの付加情報として当該メンテナンスエージェントプログラムとともに保守サーバにより受信されることを特徴とする請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。
- 前記に加えて、保守サーバは、メンテナンスの時期に関する情報を有しており、当該時期が到来すると前記メンテナンスエージェントプログラムを生成し、前記端末装置に送信することを特徴とする請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。
- 前記端末装置は、前記メンテナンスエージェントプログラムに記述された内容に基づいて所定のメンテナンス実行プログラム本体のダウンロードを保守サーバに要求することを特徴とする請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。
- 前記端末装置は、前記メンテナンスエージェントプログラムの実行の結果、エラーを発生したときに障害対応プログラムの起動、または保守サーバへの障害対応プログラムのダウンロード要求を行うことを特徴とする請求項2記載の保守サーバを用いたエージェント利用メンテナンス方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002160241A JP2004005230A (ja) | 2002-05-31 | 2002-05-31 | エージェント利用メンテナンスシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002160241A JP2004005230A (ja) | 2002-05-31 | 2002-05-31 | エージェント利用メンテナンスシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004005230A true JP2004005230A (ja) | 2004-01-08 |
Family
ID=30429728
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002160241A Pending JP2004005230A (ja) | 2002-05-31 | 2002-05-31 | エージェント利用メンテナンスシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004005230A (ja) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006309322A (ja) * | 2005-04-26 | 2006-11-09 | Toshiba Social Automation Systems Co Ltd | データ集計方法及びデータ集計システム |
JP2008015596A (ja) * | 2006-07-03 | 2008-01-24 | Nec Fielding Ltd | 管理サーバ及び修復プログラム送信方法 |
WO2008087911A1 (ja) * | 2007-01-16 | 2008-07-24 | Kabushiki Kaisha Toshiba | 遠隔監視・診断システム |
WO2008087910A1 (ja) * | 2007-01-16 | 2008-07-24 | Kabushiki Kaisha Toshiba | 遠隔監視・診断システム |
JP2009508241A (ja) * | 2005-11-10 | 2009-02-26 | 華為技術有限公司 | 装置管理において、スケジューリング・タスクを処理するための方法およびシステム |
JP2011238234A (ja) * | 2010-05-11 | 2011-11-24 | Computer Associates Think Inc | コールバックを用いたソフトウェアの動的計測のためのフェイルセーフメカニズム |
US9411616B2 (en) | 2011-12-09 | 2016-08-09 | Ca, Inc. | Classloader/instrumentation approach for invoking non-bound libraries |
JP6427697B1 (ja) * | 2018-01-22 | 2018-11-21 | 株式会社Triart | 情報処理装置、情報処理方法、プログラムおよび情報処理システム |
JP7480842B2 (ja) | 2020-05-18 | 2024-05-10 | 日本電信電話株式会社 | 仮想リソース管理装置、仮想リソース管理方法およびプログラム |
-
2002
- 2002-05-31 JP JP2002160241A patent/JP2004005230A/ja active Pending
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006309322A (ja) * | 2005-04-26 | 2006-11-09 | Toshiba Social Automation Systems Co Ltd | データ集計方法及びデータ集計システム |
JP2009508241A (ja) * | 2005-11-10 | 2009-02-26 | 華為技術有限公司 | 装置管理において、スケジューリング・タスクを処理するための方法およびシステム |
JP2008015596A (ja) * | 2006-07-03 | 2008-01-24 | Nec Fielding Ltd | 管理サーバ及び修復プログラム送信方法 |
US7809529B2 (en) | 2007-01-16 | 2010-10-05 | Kabushiki Kaisha Toshiba | Remote monitoring and diagnostic system |
US8255187B2 (en) | 2007-01-16 | 2012-08-28 | Kabushiki Kaisha Toshiba | Remote monitoring diagnostic system |
US20090019319A1 (en) * | 2007-01-16 | 2009-01-15 | Yoshikazu Ooba | Remote monitoring diagnostic system |
WO2008087910A1 (ja) * | 2007-01-16 | 2008-07-24 | Kabushiki Kaisha Toshiba | 遠隔監視・診断システム |
CN101542519A (zh) * | 2007-01-16 | 2009-09-23 | 株式会社东芝 | 远程监控/诊断系统 |
WO2008087911A1 (ja) * | 2007-01-16 | 2008-07-24 | Kabushiki Kaisha Toshiba | 遠隔監視・診断システム |
JP2008176404A (ja) * | 2007-01-16 | 2008-07-31 | Toshiba Corp | 遠隔監視・診断システム |
JP2011238234A (ja) * | 2010-05-11 | 2011-11-24 | Computer Associates Think Inc | コールバックを用いたソフトウェアの動的計測のためのフェイルセーフメカニズム |
US9411616B2 (en) | 2011-12-09 | 2016-08-09 | Ca, Inc. | Classloader/instrumentation approach for invoking non-bound libraries |
JP6427697B1 (ja) * | 2018-01-22 | 2018-11-21 | 株式会社Triart | 情報処理装置、情報処理方法、プログラムおよび情報処理システム |
WO2019142767A1 (ja) * | 2018-01-22 | 2019-07-25 | 株式会社Triart | 情報処理装置、情報処理方法、プログラムおよび情報処理システム |
JP2019128645A (ja) * | 2018-01-22 | 2019-08-01 | 株式会社Triart | 情報処理装置、情報処理方法、プログラムおよび情報処理システム |
CN111902808A (zh) * | 2018-01-22 | 2020-11-06 | 株式会社特瑞尔 | 信息处理装置、信息处理方法、程序和信息处理系统 |
US11875134B2 (en) | 2018-01-22 | 2024-01-16 | Triart, Inc. | Information processing device, information processing method, program and information processing system |
JP7480842B2 (ja) | 2020-05-18 | 2024-05-10 | 日本電信電話株式会社 | 仮想リソース管理装置、仮想リソース管理方法およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6370455B1 (en) | Method and apparatus for networked wheel alignment communications and service | |
JP2952124B2 (ja) | 写真処理機の故障診断システム | |
JP3267834B2 (ja) | Posシステム装置 | |
CN1326081C (zh) | 便于开户的系统和方法 | |
US10572852B2 (en) | Software application for the automated drop-off and pick-up of a service item at a service facility | |
CN106228357A (zh) | 用于提供基于位置的内容传递的方法和设备 | |
JP2004005230A (ja) | エージェント利用メンテナンスシステム | |
CN109754292A (zh) | 停车自助开票方法、装置和电子设备 | |
RU2688254C1 (ru) | Система мониторинга сети устройств самообслуживания | |
JP2004310645A (ja) | プロパンガスの販売・顧客管理方法及びシステム | |
CN115345746B (zh) | 证券交易方法、装置、设备及介质 | |
ITMI20112406A1 (it) | Terminale cliente e sistema di self-shopping | |
JP2000067146A (ja) | サ―ビス端末機と通信ネットワ―クシステム | |
JP6785460B1 (ja) | 店舗支援方法、プログラム及び店舗支援システム | |
CN114399397A (zh) | 续保跟踪方法、装置、设备及介质 | |
WO2016171379A1 (ko) | 지불 처리 시스템 및 방법 | |
US20100299425A1 (en) | License transfer system, license transfer method, and license transfer program | |
JP3946016B2 (ja) | 画像形成装置、画像形成装置の管理方法 | |
JP6853988B1 (ja) | 廃棄物管理システム及びそのプログラム | |
JP2024041411A (ja) | 販売管理システム | |
JP2007011660A (ja) | 自販機管理システム及びそのプログラム | |
JP2507072B2 (ja) | リカバリ方式 | |
JP2804046B2 (ja) | 分散処理システムのデータ整合化方法 | |
CN114282865A (zh) | 出单信息的透传方法、装置及计算设备 | |
JPH0687279B2 (ja) | Posシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041124 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070913 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070925 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080205 |