JP2006285769A - バージョン管理システム - Google Patents

Abstract

【課題】複数の事業者サーバと複数の端末装置のデータ・アプリケーションのバージョンアップ作業を自動化する。
【解決手段】ネットワークを介して通信可能に接続され、少なくとも２つの異なるデータ形式でデータを管理する複数の事業者用サーバ２０と、各前記複数の事業者用サーバに接続された複数の端末装置４０と、前記ネットワークに接続されたセンターサーバ１０と、を備え、前記複数の事業者用サーバ２０と、複数の端末装置４０とが保持するデータ・アプリケーションのバージョンを、前記センターサーバ１０を介して一致させる。
【選択図】図１

Description

本発明は、バージョン管理システムに関する。

図１２は、具体的な１つの事業者における駅務システムの概略構成を示すブロック図である。
図１２に示すように、事業者サーバ２０と複数の駅端末４０がＬＡＮ回線５０で接続されている。また、駅端末４０には、それぞれ自動改札機４１、自動精算機４２及び窓口係員精算機４３等が接続されている。ここで、事業者サーバ２０と駅端末４０には、運賃データ等のデータが図示しない記憶装置に記憶されており、運賃データ・アプリケーションが改正された場合には、事業者サーバ２０から全ての駅端末が改正後の運賃データ・アプリケーションをダウンロードし、常に最新バージョンのアプリケーションで、改札や運賃の清算が出来るようになっている。

この場合において、駅務機器（自動改札機・自動精算機・窓口係員精算機）は、上記のように各機器にて運賃データ・アプリケーションのバージョンアップ作業を実施していた。この場合、仮に改札機の台数がｋ通路でかつ、１通路当たりｍ分の作業時間を要するとした場合、全てのバージョンアップに（ｋ×ｍ）分の作業時間が必要になる。

また、近年、駅務機器の普及に伴い、ＳＦカードやＩＣカードの複数の電鉄事業者（以下、単に「事業者」と称する）の共通利用化が進んでおり、各事業者における駅務機器に登録する運賃データ・アプリケーションの共通化が必須条件とされる。この場合において、１つの事業者が運賃改正を行った場合に、全ての事業者における運賃データ・アプリケーションをその事業者に合わせてバージョンアップする必要がある。従って、例えば、事業者の数が１０であれば、１事業者におけるバージョンアップに要する時間の１０倍の時間が必要になることになる。このため、ＩＣカード等を共通利用する全ての事業者において、バージョンアップに必要な手間と時間を短縮するために、共通化された運賃データ・アプリケーションのバージョンアップ作業を自動化することが必要である。

なお、上記の問題は、電鉄事業者について説明したが、例えば、銀行などのＡＴＭ端末などについても同様の問題がある。

本発明は、異なる事業者サーバのデータ・アプリケーション、例えば、運賃データ・アプリケーションのバージョンアップ作業を自動化したバージョンアップ管理システムを提供することを目的とする。

本発明の一局面に係る発明は、ネットワークを介して通信可能に接続され、少なくとも２つの異なるデータ形式でデータを管理する複数の事業者用サーバと、各前記複数の事業者用サーバに接続された複数の端末装置と、前記ネットワークに接続されたセンターサーバと、を備え、前記複数の事業者用サーバと、複数の端末装置とが保持するデータ・アプリケーションのバージョンを、前記センターサーバを介して一致させることを特徴とする。

本発明によれば、センターサーバを備えたことにより、各事業者が保持するデータ・アプリケーションのバージョンを、自動的に一致させることが出来る。

図面を参照して本発明の実施の形態を説明する。

図１は、本発明の一実施形態に係るバージョン管理システムの構成を示すブロック図である。図１において、図１２と同じ部分には同じ符号を付している。なお、以下の実施形態においては、駅務システムについて説明するが、本発明は、駅務システムに限らず、銀行のような複数の事業者が提携してサービスを行うような場合において、データ・アプリケーションのバージョンアップを全ての端末で実施する必要があるようなシステムに全て適用可能である。
図１に示すように、センターサーバ１０と複数の事業者サーバ２０とがネットワーク３０（有線でも無線でも良い。また、専用回線でも、一般回線でもよい）を介して、通信可能に接続されている。各事業者サーバ２０には、図示しない、例えば、ＬＡＮ回線を介して、複数の駅端末４０が接続されている。また、駅端末４０には、それぞれ自動改札機４１、自動精算機４２及び窓口係員精算機４３等が接続されている。ここで、センターサーバ１０と事業者サーバ２０と駅端末４０には、運賃データ等のデータが図示しない記憶装置に記憶されている。なお、センターサーバ１０は全電鉄事業者の総括用のセンターサーバであり、事業者サーバ２０は各電鉄事業者の個別のセンターサーバである。

従来では、データの流れは、各事業者サーバ２０はそれぞれ独立しており、かつ、そのデータ形式なども異なっていた。更に、データ・アプリケーションのバージョンアップは、事業者サーバ２０から駅端末４０へのダウンロード（以下、「ＤＬＬ」と称する。Down Line Loading）のみで行われていた。

本発明では、センターサーバ１０をネットワーク３０の中央に配して、事業者サーバを「スター型ネットワーク」にし、いずれからも、データのダウンロードやアップロード（以下、「ＵＬＬ」と称する。Up Line Loading）が可能、すなわち双方向に対するデータのダウンロードやアップロードが可能となっている。

図２は、センターサーバ１０と事業者サーバ２０と駅端末４０が有する機能一覧を示す図である。図２に示すように、各機器は、
（１）バージョン管理機能：バージョン管理ファイルの管理機能（バージョンチェック等の機能）
（２）ファイルＤＬＬ機能：各種ファイルをＤＬＬする機能
（３）ファイルＵＬＬ機能：各種ファイルをＵＬＬする機能
（４）ファイル入力機能：各種ファイルを外部媒体より入力する機能
（５）ファイル出力機能：各種ファイルを外部媒体に出力する機能
の５つの機能を備えている。なお、図２において、駅端末４０は、ファイルのＵＬＬは行うが、ＤＬＬは行わず、センターサーバ１０は、ファイルのＵＬＬは行わないので、それぞれの機能は有していない。また、ファイルとして、以下のようなファイルがある。
（１）プログラムファイル：判定処理等を実施するアプリケーションプログラム
（２）運賃データファイル：各駅間の乗車運賃を登録した運賃データファイル
（３）パラメータファイル：ＳＦカードの取り扱い等を制御するパラメータファイル
（４）印刷文字・駅名データファイル：ＳＦカードに印刷する文字データファイル。

次に、図３から図７を参照して、各機器間のバージョンを一致させる方法について、説明する。図３において、「新」は最も新しいバージョン、「旧」は最新のバージョンではないことを示している。この場合において、図３に示すように、８通りのバージョンの存在が考えられる。ここで、１番目と８番目については、全ての機器についてデータ・アプリケーションのバージョンが一致しているので、特別な処理は行わない。２番目から７番目については、データ・アプリケーションのバージョンが不一致になっているので、バージョンを一致させる必要がある。この一致させる方法として、詳細は後述するパターン１からパターン４の動作により、一致させることになる。パターン１からパターン４の動作の概略は以下の通りである。
（１）パターン１：センターサーバ１０から、事業者サーバ２０へのＤＬＬ（上位機種間ＤＬＬ）
（２）パターン２：事業者サーバ２０から、駅端末４０へのＤＬＬ（駅端末４０間ＤＬＬ：従来と同じ）
（３）パターン３：駅端末４０から事業者サーバ２０へのＵＬＬ（駅端末４０間ＵＬＬ）
（４）パターン４：事業者サーバ２０から、駅端末４０へのＵＬＬ（上位機種間ＵＬＬ）
上記のパターン１からパターン４の動作の流れを図４から図７を参照して説明する。

図４を参照してパターン１（センターサーバ１０から事業者サーバ２０へのＤＬＬ）の動作の流れを説明する。
センターサーバ１０からバージョンデータが要求されると、事業者サーバ２０からバージョンデータについて応答がなされる。そこで、センターサーバ１０により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば（この場合事業者サーバ２０のデータ・アプリケーションのバージョンが古いものとする）、センターサーバ１０は事業者サーバ２０にＤＬＬ開始要求を出す。事業者サーバ２０はＤＬＬ開始要求に応答する旨をセンターサーバ１０に送出し、その旨に応じて、センターサーバ１０がデータ・アプリケーションをＤＬＬする。事業者サーバ２０は、ＤＬＬが完了したらＤＬＬデータを保存すると共に、センターサーバ１０にＤＬＬが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータをセンターサーバ１０に返す。これにより、事業者サーバ２０のファイルが最新のファイルになるので、センターサーバ１０のファイルとバージョンが一致することになり、処理が終了する。

図５を参照してパターン２（事業者サーバ２０から駅端末４０へのＤＬＬ）の動作の流れを説明する。図５はパターン２の動作の流れを示す図である。
事業者サーバ２０からバージョンデータが要求されると、駅端末４０からバージョンデータについて応答がなされる。そこで、事業者サーバ２０により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば（この場合駅端末４０のデータ・アプリケーションのバージョンが古いものとする）、事業者サーバ２０は駅端末４０にＤＬＬ開始要求を出す。駅端末４０はＤＬＬ開始要求に応答する旨を事業者サーバ２０に送出し、その旨に応じて、事業者サーバ２０がデータ・アプリケーションをＤＬＬする。駅端末４０は、ＤＬＬが完了したらＤＬＬデータを保存すると共に、事業者サーバ２０にＤＬＬが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを事業者サーバ２０に返す。これにより、駅端末４０のファイルが最新のファイルになるので、事業者サーバ２０のファイルとバージョンが一致することになり、処理が終了する。

図６を参照してパターン３（駅端末４０から事業者サーバ２０へのＵＬＬ）の動作の流れについて説明する。図６はパターン３の動作の流れを示す図である。
事業者サーバ２０からバージョンデータが要求されると、駅端末４０からバージョンデータについて応答がなされる。そこで、事業者サーバ２０により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば（この場合事業者サーバ２０のデータ・アプリケーションのバージョンが古いものとする）、事業者サーバ２０は駅端末４０にＵＬＬ開始要求を出す。駅端末４０はＵＬＬ開始要求に応答する旨を事業者サーバ２０に送出し、その旨に応じて、駅端末４０がデータ・アプリケーションをＵＬＬする。事業者サーバ２０は、ＵＬＬが完了したらＵＬＬデータを保存すると共に、駅端末４０にＵＬＬが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを駅端末４０に要求する。駅端末４０は、バージョンデータを事業者サーバ２０に返す。これにより、事業者サーバ２０のファイルが最新のファイルになるので、駅端末４０のファイルとバージョンが一致することになり、処理が終了する。

図７を参照してパターン４（事業者サーバ２０からセンターサーバ１０へのＵＬＬ）の動作の流れを説明する。図６はパターン４の動作の流れを示す図である。
センターサーバ１０からバージョンデータが要求されると、事業者サーバ２０からバージョンデータについて応答がなされる。そこで、センターサーバ１０により、バージョンチェックがなされて、一致していれば、処理を終了する。バージョンが不一致であれば（この場合センターサーバ１０のデータ・アプリケーションのバージョンが古いものとする）、センターサーバ１０は事業者サーバ２０にＵＬＬ開始要求を出す。事業者サーバ２０はＵＬＬ開始要求に応答する旨をセンターサーバ１０に送出し、その旨に応じて、事業者サーバ２０がデータ・アプリケーションをＵＬＬする。センターサーバ１０は、ＵＬＬが完了したらＵＬＬデータを保存すると共に、事業者サーバ２０にＵＬＬが完了した旨の応答を行い、ファイル更新が終了したら、バージョンデータを事業者サーバ２０に要求する。事業者サーバ２０は、バージョンデータをセンターサーバ１０に返す。これにより、センターサーバ１０のファイルが最新のファイルになるので、事業者サーバ２０のファイルとバージョンが一致することになり、処理が終了する。

上記のように、相互にデータ・アプリケーションのバージョンチェックを行い、常に、各機器のデータ・アプリケーションを最新のバージョンにすることが出来る。なお、バージョンチェックのタイミングは、システムの立ち上げ時や、定期的（例えば、３０分毎、１時間毎など）などが考えられる。なお、上記のパターンではバージョンのチェック開始をバージョンデータの要求により開始することとしたが、例えば、センターサーバ１０、事業者サーバ２０、駅端末４０のいずれかでデータ・アプリケーションが更新されたのであれば、その旨を他の機器に通知して、データ・アプリケーションのバージョンを一致させるようにしても良い。例えば、事業者サーバ２０でデータ・アプリケーションを更新した場合、事業者サーバ２０から駅端末４０に当該データ・アプリケーションをＤＬＬすると共に。センターサーバ１０にＵＬＬする。そして、センターサーバ１０から他の事業者サーバ２０にその旨を通知して、他の事業者サーバ２０のデータ・アプリケーションを最新ものに更新すればよい。

上記のように、本実施形態によれば、各機器における、データ・アプリケーションのバージョンを最新ものにすることが出来る。しかし、基本的に、事業者サーバ２０は、それぞれサーバ毎にファイル構造が異なっている。従って、各事業者サーバ２０で共通化するための運賃データ・アプリケーションのファイル構造を標準化することにより、各電鉄事業者サーバ２０間でのファイルのやりとりが可能になる。各ファイルのバージョン情報については、例えば、図８に示すようなバージョン管理ファイルに記録し、当該バージョン管理ファイルで管理すればよい。そして、バージョン管理ファイルを各機種間でデータ送受信することによりバージョンチェックを行う。このように、ファイル構造を標準化しておくことで、全ての事業者サーバ２０のデータ・アプリケーションのバージョンアップに対して、バージョンアップ後、すぐに対応できる。

例えば、センターサーバ１０は定期的に各センターサーバ１０のマスタ運賃データ・アプリケーションのバージョン情報ファイルを収集し、ファイルの照合を行う。バージョン違いがあれば、事業者サーバ２０にエラーメッセージを通知する。または、強制的に最新バージョンを事業者サーバ２０にＤＬＬする。

上記の実施形態では、上位の機器（すなわち、事業者サーバ２０に対するセンターサーバ１０、駅端末４０に対する事業者サーバ２０）によるバージョンチェックにより、データ・アプリケーションを最新のものに更新していた（図９の（ａ））。しかし、このようなバージョンチェックでは、上位の機器に負荷が掛かる。そこで、上位機器の負荷を減少させるために、図９の（ｂ）に示すように、駅端末４０間でもバージョンチェックを行うようにしている。この場合において、駅端末４０の機器構成を管理するファイルが必要となる。図１０及び図１１に、各機器構成を管理するファイルの具体的な構成例を示す。なお、図１０は、事業者サーバ・マスタデータファイルの具体的な構成例であり、図１１は、駅構成マスタデータファイルの具体的な構成例である。

このような構成において、事業者サーバ２０において、運賃データ等のバージョンアップが発生する場合、事業者サーバ２０から、センターサーバ１０に、最新バージョンをリリースするため、ＵＬＬを自動的に行う。
上記のような構成により、ネットワーク３０に接続している事業者サーバ２０は、常に同バージョンのファイルを保持することが可能となる。

前述したように、駅務機器の運賃データ・アプリケーションのバージョンアップ作業は多大の作業時間が発生するが、これを本発明の実施形態により、自動化することにより、駅務システムの導入・保守コストを低減する。また、ボトムアップ式の「スター型ネットワーク」にて、各電鉄事業者システムの運賃データ・アプリケーションプログラムのバージョンチェックを行うことにより、自己診断機能を強化することが可能となる。また、従来は、上位機種からのＤＬＬのみを行うシステムであったが、本発明の伝送手順により、駅端末から上位機種にＵＬＬ（Up Line Loading）及び、駅端末間での、ＤＬＬ・ＵＬＬが可能となる。

また、従来のトップダウン式のダウンロードシステムでは、事業者サーバや駅端末を含む各事業者システムの運賃データ・アプリケーションのバージョンチェックはできなかったが、双方向でのデータのやりとりにより、より信頼性の高いシステムを実現することが可能となる。

現在の駅務機器は、多くのプログラム・運賃データ・各種パラメータファイルを必要としている。また、各事業者間で同じバージョンであることが必須となる。これを手動での確認ではなく、バージョン管理ファイルを本システムの機器間で、データ送受信することにより、自動診断することが可能となる。

大規模なシステムにおいて、一斉に機種間のバージョンチェックを行うことは、伝送負荷が増大するため困難であるが、本発明の実施形態では、駅端末間にて、バージョン管理ファイルをバトンリレーすることにより、１トランザクション単位にバージョンチェックを行うことが可能となる。

また、駅務機器の普及に伴う、運賃データ・アプリケーションの共通化を保守員が手動にて確認しているが、自動化することにより、保守員の負担を減らし、より良いサービスの提供が可能となる。

本発明は、上記各実施の形態に限ることなく、その他、実施段階ではその要旨を逸脱しない範囲で種々の変形を実施し得ることが可能である。さらに、上記各実施形態には、種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組合せにより種々の発明が抽出され得る。

また、例えば各実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

本発明の一実施形態に係るバージョン管理システムの構成を示すブロック図。 センターサーバ１０と事業者サーバ２０と駅端末４０が有する機能一覧を示す図。 各機器が保持するデータ・アプリケーションのバージョンのチェックと、チェック後の動作を示す図である。 パターン１の動作の流れを示す図。 パターン２の動作の流れを示す図。 パターン３の動作の流れを示す図。 パターン４の動作の流れを示す図。 バージョン管理ファイルの構成例を示す図。 本発明の実施形態において、各機器間のデータの流れについて示す図。 事業者サーバ・マスタデータファイルの具体的な構成例を示す図。 駅構成マスタデータファイルの具体的な構成例を示す図。 具体的な１つの事業者における駅務システムの概略構成を示すブロック図。

符号の説明

１０…センターサーバ
２０…事業者用サーバ（事業者サーバ）
３０…ネットワーク
４０…駅端末（端末装置）
４１…自動改札機
４２…自動精算機
４３…窓口係員精算機
５０…ＬＡＮ回線

Claims (4)

1. ネットワークを介して通信可能に接続され、少なくとも２つの異なるデータ形式でデータを管理する複数の事業者用サーバと、
   各前記複数の事業者用サーバに接続された複数の端末装置と、
   前記ネットワークに接続されたセンターサーバと、を備え、
   前記複数の事業者用サーバと、複数の端末装置とが保持するデータ・アプリケーションのバージョンを、前記センターサーバを介して一致させることを特徴とするバージョン管理システム。
2. 請求項１に記載のバージョン管理システムにおいて、前記センターサーバ、前記事業者用サーバ及び前記端末装置は、相互に、データのダウンロード及びアップロードが可能であることを特徴とするバージョン管理システム。
3. 請求項１または請求項２に記載のバージョン管理システムにおいて、前記端末装置は、相互にデータ・アプリケーションのバージョンチェックが可能であり、かつ、バージョンが一致していないときに、最新のデータ・アプリケーションに更新するためにデータ・アプリケーションをダウンロード或いはアップロードが可能であることを特徴とするバージョン管理システム。
4. 請求項１から請求項３のいずれか１項に記載のバージョン管理システムにおいて、
   前記事業者用サーバは、電鉄事業者サーバであり、
   前記端末装置は、駅端末であることを特徴とするバージョン管理システム。

Images