JP2006285769A - バージョン管理システム - Google Patents
バージョン管理システム Download PDFInfo
- Publication number
- JP2006285769A JP2006285769A JP2005106402A JP2005106402A JP2006285769A JP 2006285769 A JP2006285769 A JP 2006285769A JP 2005106402 A JP2005106402 A JP 2005106402A JP 2005106402 A JP2005106402 A JP 2005106402A JP 2006285769 A JP2006285769 A JP 2006285769A
- Authority
- JP
- Japan
- Prior art keywords
- server
- version
- data
- file
- center server
- 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
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】複数の事業者サーバと複数の端末装置のデータ・アプリケーションのバージョンアップ作業を自動化する。
【解決手段】ネットワークを介して通信可能に接続され、少なくとも2つの異なるデータ形式でデータを管理する複数の事業者用サーバ20と、各前記複数の事業者用サーバに接続された複数の端末装置40と、前記ネットワークに接続されたセンターサーバ10と、を備え、前記複数の事業者用サーバ20と、複数の端末装置40とが保持するデータ・アプリケーションのバージョンを、前記センターサーバ10を介して一致させる。
【選択図】図1
【解決手段】ネットワークを介して通信可能に接続され、少なくとも2つの異なるデータ形式でデータを管理する複数の事業者用サーバ20と、各前記複数の事業者用サーバに接続された複数の端末装置40と、前記ネットワークに接続されたセンターサーバ10と、を備え、前記複数の事業者用サーバ20と、複数の端末装置40とが保持するデータ・アプリケーションのバージョンを、前記センターサーバ10を介して一致させる。
【選択図】図1
Description
本発明は、バージョン管理システムに関する。
図12は、具体的な1つの事業者における駅務システムの概略構成を示すブロック図である。
図12に示すように、事業者サーバ20と複数の駅端末40がLAN回線50で接続されている。また、駅端末40には、それぞれ自動改札機41、自動精算機42及び窓口係員精算機43等が接続されている。ここで、事業者サーバ20と駅端末40には、運賃データ等のデータが図示しない記憶装置に記憶されており、運賃データ・アプリケーションが改正された場合には、事業者サーバ20から全ての駅端末が改正後の運賃データ・アプリケーションをダウンロードし、常に最新バージョンのアプリケーションで、改札や運賃の清算が出来るようになっている。
図12に示すように、事業者サーバ20と複数の駅端末40がLAN回線50で接続されている。また、駅端末40には、それぞれ自動改札機41、自動精算機42及び窓口係員精算機43等が接続されている。ここで、事業者サーバ20と駅端末40には、運賃データ等のデータが図示しない記憶装置に記憶されており、運賃データ・アプリケーションが改正された場合には、事業者サーバ20から全ての駅端末が改正後の運賃データ・アプリケーションをダウンロードし、常に最新バージョンのアプリケーションで、改札や運賃の清算が出来るようになっている。
この場合において、駅務機器(自動改札機・自動精算機・窓口係員精算機)は、上記のように各機器にて運賃データ・アプリケーションのバージョンアップ作業を実施していた。この場合、仮に改札機の台数がk通路でかつ、1通路当たりm分の作業時間を要するとした場合、全てのバージョンアップに(k×m)分の作業時間が必要になる。
また、近年、駅務機器の普及に伴い、SFカードやICカードの複数の電鉄事業者(以下、単に「事業者」と称する)の共通利用化が進んでおり、各事業者における駅務機器に登録する運賃データ・アプリケーションの共通化が必須条件とされる。この場合において、1つの事業者が運賃改正を行った場合に、全ての事業者における運賃データ・アプリケーションをその事業者に合わせてバージョンアップする必要がある。従って、例えば、事業者の数が10であれば、1事業者におけるバージョンアップに要する時間の10倍の時間が必要になることになる。このため、ICカード等を共通利用する全ての事業者において、バージョンアップに必要な手間と時間を短縮するために、共通化された運賃データ・アプリケーションのバージョンアップ作業を自動化することが必要である。
なお、上記の問題は、電鉄事業者について説明したが、例えば、銀行などのATM端末などについても同様の問題がある。
本発明は、異なる事業者サーバのデータ・アプリケーション、例えば、運賃データ・アプリケーションのバージョンアップ作業を自動化したバージョンアップ管理システムを提供することを目的とする。
本発明の一局面に係る発明は、ネットワークを介して通信可能に接続され、少なくとも2つの異なるデータ形式でデータを管理する複数の事業者用サーバと、各前記複数の事業者用サーバに接続された複数の端末装置と、前記ネットワークに接続されたセンターサーバと、を備え、前記複数の事業者用サーバと、複数の端末装置とが保持するデータ・アプリケーションのバージョンを、前記センターサーバを介して一致させることを特徴とする。
本発明によれば、センターサーバを備えたことにより、各事業者が保持するデータ・アプリケーションのバージョンを、自動的に一致させることが出来る。
図面を参照して本発明の実施の形態を説明する。
図1は、本発明の一実施形態に係るバージョン管理システムの構成を示すブロック図である。図1において、図12と同じ部分には同じ符号を付している。なお、以下の実施形態においては、駅務システムについて説明するが、本発明は、駅務システムに限らず、銀行のような複数の事業者が提携してサービスを行うような場合において、データ・アプリケーションのバージョンアップを全ての端末で実施する必要があるようなシステムに全て適用可能である。
図1に示すように、センターサーバ10と複数の事業者サーバ20とがネットワーク30(有線でも無線でも良い。また、専用回線でも、一般回線でもよい)を介して、通信可能に接続されている。各事業者サーバ20には、図示しない、例えば、LAN回線を介して、複数の駅端末40が接続されている。また、駅端末40には、それぞれ自動改札機41、自動精算機42及び窓口係員精算機43等が接続されている。ここで、センターサーバ10と事業者サーバ20と駅端末40には、運賃データ等のデータが図示しない記憶装置に記憶されている。なお、センターサーバ10は全電鉄事業者の総括用のセンターサーバであり、事業者サーバ20は各電鉄事業者の個別のセンターサーバである。
図1に示すように、センターサーバ10と複数の事業者サーバ20とがネットワーク30(有線でも無線でも良い。また、専用回線でも、一般回線でもよい)を介して、通信可能に接続されている。各事業者サーバ20には、図示しない、例えば、LAN回線を介して、複数の駅端末40が接続されている。また、駅端末40には、それぞれ自動改札機41、自動精算機42及び窓口係員精算機43等が接続されている。ここで、センターサーバ10と事業者サーバ20と駅端末40には、運賃データ等のデータが図示しない記憶装置に記憶されている。なお、センターサーバ10は全電鉄事業者の総括用のセンターサーバであり、事業者サーバ20は各電鉄事業者の個別のセンターサーバである。
従来では、データの流れは、各事業者サーバ20はそれぞれ独立しており、かつ、そのデータ形式なども異なっていた。更に、データ・アプリケーションのバージョンアップは、事業者サーバ20から駅端末40へのダウンロード(以下、「DLL」と称する。Down Line Loading)のみで行われていた。
本発明では、センターサーバ10をネットワーク30の中央に配して、事業者サーバを「スター型ネットワーク」にし、いずれからも、データのダウンロードやアップロード(以下、「ULL」と称する。Up Line Loading)が可能、すなわち双方向に対するデータのダウンロードやアップロードが可能となっている。
図2は、センターサーバ10と事業者サーバ20と駅端末40が有する機能一覧を示す図である。図2に示すように、各機器は、
(1)バージョン管理機能:バージョン管理ファイルの管理機能(バージョンチェック等の機能)
(2)ファイルDLL機能:各種ファイルをDLLする機能
(3)ファイルULL機能:各種ファイルをULLする機能
(4)ファイル入力機能:各種ファイルを外部媒体より入力する機能
(5)ファイル出力機能:各種ファイルを外部媒体に出力する機能
の5つの機能を備えている。なお、図2において、駅端末40は、ファイルのULLは行うが、DLLは行わず、センターサーバ10は、ファイルのULLは行わないので、それぞれの機能は有していない。また、ファイルとして、以下のようなファイルがある。
(1)プログラムファイル:判定処理等を実施するアプリケーションプログラム
(2)運賃データファイル:各駅間の乗車運賃を登録した運賃データファイル
(3)パラメータファイル:SFカードの取り扱い等を制御するパラメータファイル
(4)印刷文字・駅名データファイル:SFカードに印刷する文字データファイル。
(1)バージョン管理機能:バージョン管理ファイルの管理機能(バージョンチェック等の機能)
(2)ファイルDLL機能:各種ファイルをDLLする機能
(3)ファイルULL機能:各種ファイルをULLする機能
(4)ファイル入力機能:各種ファイルを外部媒体より入力する機能
(5)ファイル出力機能:各種ファイルを外部媒体に出力する機能
の5つの機能を備えている。なお、図2において、駅端末40は、ファイルのULLは行うが、DLLは行わず、センターサーバ10は、ファイルのULLは行わないので、それぞれの機能は有していない。また、ファイルとして、以下のようなファイルがある。
(1)プログラムファイル:判定処理等を実施するアプリケーションプログラム
(2)運賃データファイル:各駅間の乗車運賃を登録した運賃データファイル
(3)パラメータファイル:SFカードの取り扱い等を制御するパラメータファイル
(4)印刷文字・駅名データファイル:SFカードに印刷する文字データファイル。
次に、図3から図7を参照して、各機器間のバージョンを一致させる方法について、説明する。図3において、「新」は最も新しいバージョン、「旧」は最新のバージョンではないことを示している。この場合において、図3に示すように、8通りのバージョンの存在が考えられる。ここで、1番目と8番目については、全ての機器についてデータ・アプリケーションのバージョンが一致しているので、特別な処理は行わない。2番目から7番目については、データ・アプリケーションのバージョンが不一致になっているので、バージョンを一致させる必要がある。この一致させる方法として、詳細は後述するパターン1からパターン4の動作により、一致させることになる。パターン1からパターン4の動作の概略は以下の通りである。
(1)パターン1:センターサーバ10から、事業者サーバ20へのDLL(上位機種間DLL)
(2)パターン2:事業者サーバ20から、駅端末40へのDLL(駅端末40間DLL:従来と同じ)
(3)パターン3:駅端末40から事業者サーバ20へのULL(駅端末40間ULL)
(4)パターン4:事業者サーバ20から、駅端末40へのULL(上位機種間ULL)
上記のパターン1からパターン4の動作の流れを図4から図7を参照して説明する。
(1)パターン1:センターサーバ10から、事業者サーバ20へのDLL(上位機種間DLL)
(2)パターン2:事業者サーバ20から、駅端末40へのDLL(駅端末40間DLL:従来と同じ)
(3)パターン3:駅端末40から事業者サーバ20へのULL(駅端末40間ULL)
(4)パターン4:事業者サーバ20から、駅端末40へのULL(上位機種間ULL)
上記のパターン1からパターン4の動作の流れを図4から図7を参照して説明する。
図4を参照してパターン1(センターサーバ10から事業者サーバ20へのDLL)の動作の流れを説明する。
センターサーバ10からバージョンデータが要求されると、事業者サーバ20からバージョンデータについて応答がなされる。そこで、センターサーバ10により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合事業者サーバ20のデータ・アプリケーションのバージョンが古いものとする)、センターサーバ10は事業者サーバ20にDLL開始要求を出す。事業者サーバ20はDLL開始要求に応答する旨をセンターサーバ10に送出し、その旨に応じて、センターサーバ10がデータ・アプリケーションをDLLする。事業者サーバ20は、DLLが完了したらDLLデータを保存すると共に、センターサーバ10にDLLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータをセンターサーバ10に返す。これにより、事業者サーバ20のファイルが最新のファイルになるので、センターサーバ10のファイルとバージョンが一致することになり、処理が終了する。
センターサーバ10からバージョンデータが要求されると、事業者サーバ20からバージョンデータについて応答がなされる。そこで、センターサーバ10により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合事業者サーバ20のデータ・アプリケーションのバージョンが古いものとする)、センターサーバ10は事業者サーバ20にDLL開始要求を出す。事業者サーバ20はDLL開始要求に応答する旨をセンターサーバ10に送出し、その旨に応じて、センターサーバ10がデータ・アプリケーションをDLLする。事業者サーバ20は、DLLが完了したらDLLデータを保存すると共に、センターサーバ10にDLLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータをセンターサーバ10に返す。これにより、事業者サーバ20のファイルが最新のファイルになるので、センターサーバ10のファイルとバージョンが一致することになり、処理が終了する。
図5を参照してパターン2(事業者サーバ20から駅端末40へのDLL)の動作の流れを説明する。図5はパターン2の動作の流れを示す図である。
事業者サーバ20からバージョンデータが要求されると、駅端末40からバージョンデータについて応答がなされる。そこで、事業者サーバ20により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合駅端末40のデータ・アプリケーションのバージョンが古いものとする)、事業者サーバ20は駅端末40にDLL開始要求を出す。駅端末40はDLL開始要求に応答する旨を事業者サーバ20に送出し、その旨に応じて、事業者サーバ20がデータ・アプリケーションをDLLする。駅端末40は、DLLが完了したらDLLデータを保存すると共に、事業者サーバ20にDLLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを事業者サーバ20に返す。これにより、駅端末40のファイルが最新のファイルになるので、事業者サーバ20のファイルとバージョンが一致することになり、処理が終了する。
事業者サーバ20からバージョンデータが要求されると、駅端末40からバージョンデータについて応答がなされる。そこで、事業者サーバ20により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合駅端末40のデータ・アプリケーションのバージョンが古いものとする)、事業者サーバ20は駅端末40にDLL開始要求を出す。駅端末40はDLL開始要求に応答する旨を事業者サーバ20に送出し、その旨に応じて、事業者サーバ20がデータ・アプリケーションをDLLする。駅端末40は、DLLが完了したらDLLデータを保存すると共に、事業者サーバ20にDLLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを事業者サーバ20に返す。これにより、駅端末40のファイルが最新のファイルになるので、事業者サーバ20のファイルとバージョンが一致することになり、処理が終了する。
図6を参照してパターン3(駅端末40から事業者サーバ20へのULL)の動作の流れについて説明する。図6はパターン3の動作の流れを示す図である。
事業者サーバ20からバージョンデータが要求されると、駅端末40からバージョンデータについて応答がなされる。そこで、事業者サーバ20により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合事業者サーバ20のデータ・アプリケーションのバージョンが古いものとする)、事業者サーバ20は駅端末40にULL開始要求を出す。駅端末40はULL開始要求に応答する旨を事業者サーバ20に送出し、その旨に応じて、駅端末40がデータ・アプリケーションをULLする。事業者サーバ20は、ULLが完了したらULLデータを保存すると共に、駅端末40にULLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを駅端末40に要求する。駅端末40は、バージョンデータを事業者サーバ20に返す。これにより、事業者サーバ20のファイルが最新のファイルになるので、駅端末40のファイルとバージョンが一致することになり、処理が終了する。
事業者サーバ20からバージョンデータが要求されると、駅端末40からバージョンデータについて応答がなされる。そこで、事業者サーバ20により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合事業者サーバ20のデータ・アプリケーションのバージョンが古いものとする)、事業者サーバ20は駅端末40にULL開始要求を出す。駅端末40はULL開始要求に応答する旨を事業者サーバ20に送出し、その旨に応じて、駅端末40がデータ・アプリケーションをULLする。事業者サーバ20は、ULLが完了したらULLデータを保存すると共に、駅端末40にULLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを駅端末40に要求する。駅端末40は、バージョンデータを事業者サーバ20に返す。これにより、事業者サーバ20のファイルが最新のファイルになるので、駅端末40のファイルとバージョンが一致することになり、処理が終了する。
図7を参照してパターン4(事業者サーバ20からセンターサーバ10へのULL)の動作の流れを説明する。図6はパターン4の動作の流れを示す図である。
センターサーバ10からバージョンデータが要求されると、事業者サーバ20からバージョンデータについて応答がなされる。そこで、センターサーバ10により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合センターサーバ10のデータ・アプリケーションのバージョンが古いものとする)、センターサーバ10は事業者サーバ20にULL開始要求を出す。事業者サーバ20はULL開始要求に応答する旨をセンターサーバ10に送出し、その旨に応じて、事業者サーバ20がデータ・アプリケーションをULLする。センターサーバ10は、ULLが完了したらULLデータを保存すると共に、事業者サーバ20にULLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを事業者サーバ20に要求する。事業者サーバ20は、バージョンデータをセンターサーバ10に返す。これにより、センターサーバ10のファイルが最新のファイルになるので、事業者サーバ20のファイルとバージョンが一致することになり、処理が終了する。
センターサーバ10からバージョンデータが要求されると、事業者サーバ20からバージョンデータについて応答がなされる。そこで、センターサーバ10により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば(この場合センターサーバ10のデータ・アプリケーションのバージョンが古いものとする)、センターサーバ10は事業者サーバ20にULL開始要求を出す。事業者サーバ20はULL開始要求に応答する旨をセンターサーバ10に送出し、その旨に応じて、事業者サーバ20がデータ・アプリケーションをULLする。センターサーバ10は、ULLが完了したらULLデータを保存すると共に、事業者サーバ20にULLが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを事業者サーバ20に要求する。事業者サーバ20は、バージョンデータをセンターサーバ10に返す。これにより、センターサーバ10のファイルが最新のファイルになるので、事業者サーバ20のファイルとバージョンが一致することになり、処理が終了する。
上記のように、相互にデータ・アプリケーションのバージョンチェックを行い、常に、各機器のデータ・アプリケーションを最新のバージョンにすることが出来る。なお、バージョンチェックのタイミングは、システムの立ち上げ時や、定期的(例えば、30分毎、1時間毎など)などが考えられる。なお、上記のパターンではバージョンのチェック開始をバージョンデータの要求により開始することとしたが、例えば、センターサーバ10、事業者サーバ20、駅端末40のいずれかでデータ・アプリケーションが更新されたのであれば、その旨を他の機器に通知して、データ・アプリケーションのバージョンを一致させるようにしても良い。例えば、事業者サーバ20でデータ・アプリケーションを更新した場合、事業者サーバ20から駅端末40に当該データ・アプリケーションをDLLすると共に。センターサーバ10にULLする。そして、センターサーバ10から他の事業者サーバ20にその旨を通知して、他の事業者サーバ20のデータ・アプリケーションを最新ものに更新すればよい。
上記のように、本実施形態によれば、各機器における、データ・アプリケーションのバージョンを最新ものにすることが出来る。しかし、基本的に、事業者サーバ20は、それぞれサーバ毎にファイル構造が異なっている。従って、各事業者サーバ20で共通化するための運賃データ・アプリケーションのファイル構造を標準化することにより、各電鉄事業者サーバ20間でのファイルのやりとりが可能になる。各ファイルのバージョン情報については、例えば、図8に示すようなバージョン管理ファイルに記録し、当該バージョン管理ファイルで管理すればよい。そして、バージョン管理ファイルを各機種間でデータ送受信することによりバージョンチェックを行う。このように、ファイル構造を標準化しておくことで、全ての事業者サーバ20のデータ・アプリケーションのバージョンアップに対して、バージョンアップ後、すぐに対応できる。
例えば、センターサーバ10は定期的に各センターサーバ10のマスタ運賃データ・アプリケーションのバージョン情報ファイルを収集し、ファイルの照合を行う。バージョン違いがあれば、事業者サーバ20にエラーメッセージを通知する。または、強制的に最新バージョンを事業者サーバ20にDLLする。
上記の実施形態では、上位の機器(すなわち、事業者サーバ20に対するセンターサーバ10、駅端末40に対する事業者サーバ20)によるバージョンチェックにより、データ・アプリケーションを最新のものに更新していた(図9の(a))。しかし、このようなバージョンチェックでは、上位の機器に負荷が掛かる。そこで、上位機器の負荷を減少させるために、図9の(b)に示すように、駅端末40間でもバージョンチェックを行うようにしている。この場合において、駅端末40の機器構成を管理するファイルが必要となる。図10及び図11に、各機器構成を管理するファイルの具体的な構成例を示す。なお、図10は、事業者サーバ・マスタデータファイルの具体的な構成例であり、図11は、駅構成マスタデータファイルの具体的な構成例である。
このような構成において、事業者サーバ20において、運賃データ等のバージョンアップが発生する場合、事業者サーバ20から、センターサーバ10に、最新バージョンをリリースするため、ULLを自動的に行う。
上記のような構成により、ネットワーク30に接続している事業者サーバ20は、常に同バージョンのファイルを保持することが可能となる。
上記のような構成により、ネットワーク30に接続している事業者サーバ20は、常に同バージョンのファイルを保持することが可能となる。
前述したように、駅務機器の運賃データ・アプリケーションのバージョンアップ作業は多大の作業時間が発生するが、これを本発明の実施形態により、自動化することにより、駅務システムの導入・保守コストを低減する。また、ボトムアップ式の「スター型ネットワーク」にて、各電鉄事業者システムの運賃データ・アプリケーションプログラムのバージョンチェックを行うことにより、自己診断機能を強化することが可能となる。また、従来は、上位機種からのDLLのみを行うシステムであったが、本発明の伝送手順により、駅端末から上位機種にULL(Up Line Loading)及び、駅端末間での、DLL・ULLが可能となる。
また、従来のトップダウン式のダウンロードシステムでは、事業者サーバや駅端末を含む各事業者システムの運賃データ・アプリケーションのバージョンチェックはできなかったが、双方向でのデータのやりとりにより、より信頼性の高いシステムを実現することが可能となる。
現在の駅務機器は、多くのプログラム・運賃データ・各種パラメータファイルを必要としている。また、各事業者間で同じバージョンであることが必須となる。これを手動での確認ではなく、バージョン管理ファイルを本システムの機器間で、データ送受信することにより、自動診断することが可能となる。
大規模なシステムにおいて、一斉に機種間のバージョンチェックを行うことは、伝送負荷が増大するため困難であるが、本発明の実施形態では、駅端末間にて、バージョン管理ファイルをバトンリレーすることにより、1トランザクション単位にバージョンチェックを行うことが可能となる。
また、駅務機器の普及に伴う、運賃データ・アプリケーションの共通化を保守員が手動にて確認しているが、自動化することにより、保守員の負担を減らし、より良いサービスの提供が可能となる。
本発明は、上記各実施の形態に限ることなく、その他、実施段階ではその要旨を逸脱しない範囲で種々の変形を実施し得ることが可能である。さらに、上記各実施形態には、種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組合せにより種々の発明が抽出され得る。
また、例えば各実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
10…センターサーバ
20…事業者用サーバ(事業者サーバ)
30…ネットワーク
40…駅端末(端末装置)
41…自動改札機
42…自動精算機
43…窓口係員精算機
50…LAN回線
20…事業者用サーバ(事業者サーバ)
30…ネットワーク
40…駅端末(端末装置)
41…自動改札機
42…自動精算機
43…窓口係員精算機
50…LAN回線
Claims (4)
- ネットワークを介して通信可能に接続され、少なくとも2つの異なるデータ形式でデータを管理する複数の事業者用サーバと、
各前記複数の事業者用サーバに接続された複数の端末装置と、
前記ネットワークに接続されたセンターサーバと、を備え、
前記複数の事業者用サーバと、複数の端末装置とが保持するデータ・アプリケーションのバージョンを、前記センターサーバを介して一致させることを特徴とするバージョン管理システム。 - 請求項1に記載のバージョン管理システムにおいて、前記センターサーバ、前記事業者用サーバ及び前記端末装置は、相互に、データのダウンロード及びアップロードが可能であることを特徴とするバージョン管理システム。
- 請求項1または請求項2に記載のバージョン管理システムにおいて、前記端末装置は、相互にデータ・アプリケーションのバージョンチェックが可能であり、かつ、バージョンが一致していないときに、最新のデータ・アプリケーションに更新するためにデータ・アプリケーションをダウンロード或いはアップロードが可能であることを特徴とするバージョン管理システム。
- 請求項1から請求項3のいずれか1項に記載のバージョン管理システムにおいて、
前記事業者用サーバは、電鉄事業者サーバであり、
前記端末装置は、駅端末であることを特徴とするバージョン管理システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005106402A JP2006285769A (ja) | 2005-04-01 | 2005-04-01 | バージョン管理システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005106402A JP2006285769A (ja) | 2005-04-01 | 2005-04-01 | バージョン管理システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006285769A true JP2006285769A (ja) | 2006-10-19 |
Family
ID=37407614
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005106402A Pending JP2006285769A (ja) | 2005-04-01 | 2005-04-01 | バージョン管理システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2006285769A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009205243A (ja) * | 2008-02-26 | 2009-09-10 | Yokogawa Electric Corp | フィールド機器管理装置、フィールド機器管理システム、フィールド機器管理方法、コンピュータプログラム、記録媒体 |
-
2005
- 2005-04-01 JP JP2005106402A patent/JP2006285769A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009205243A (ja) * | 2008-02-26 | 2009-09-10 | Yokogawa Electric Corp | フィールド機器管理装置、フィールド機器管理システム、フィールド機器管理方法、コンピュータプログラム、記録媒体 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7313577B2 (en) | Generating difference files using module information of embedded software components | |
JP5164996B2 (ja) | 装置管理システム | |
EP2456257B1 (en) | Method and system for upgrading wireless data card | |
CN102446105B (zh) | 可按需定制应用程序的方法和系统 | |
CN111694592A (zh) | 项目版本发布的管理方法以及系统 | |
CN106843976B (zh) | 用于生成镜像文件的方法和装置 | |
CN103067445B (zh) | 一种分布式系统的软件升级方法及装置 | |
CN100521616C (zh) | 在设备管理中上报终端信息的方法及系统 | |
CN101192061B (zh) | 用于同步控制器固件下载的装置及方法 | |
US20150220318A1 (en) | Wireless firmware upgrades to an alarm security panel | |
CN107870774A (zh) | 一种用于aoi系统软件版本管理的系统 | |
US20020049053A1 (en) | Concentrated maintenance management method and concentrated maintenance management system for portable telephone system utilizing the internet | |
EP1918842A2 (en) | Upgrade service system | |
CN110895472A (zh) | 一种识别业务变更的方法和装置 | |
CN107851158A (zh) | 用于安全地交换设备的配置数据的方法和装置 | |
US20200231195A1 (en) | Method for operating a rail vehicle | |
CN110098952A (zh) | 一种服务器的管理方法和装置 | |
CN102385345A (zh) | 手持现场维护工具的改进功能 | |
CN112104688A (zh) | 一种综合业务型移动作业终端应用管理系统 | |
CN109360029A (zh) | 一种远程终端广告机的自我管理方法 | |
CN113127023B (zh) | 业务升级的方法、装置和系统 | |
CN111782252A (zh) | 一种软件更新控制方法、系统及相关设备 | |
US20100058312A1 (en) | Content Data Providing System, Content Providing Apparatus and Content Data Processing Terminal | |
CN105589718A (zh) | 智能设备的系统更新方法与更新装置 | |
CN113243003B (zh) | 管理飞行器设备软件配置的方法和装置 |