(57)【特許請求の範囲】
【請求項１】
複数の機器間でデータをやり取りするデータ交換方法であって、
一方の機器から他方の機器へ、やり取りするデータの桁数を問い合わせるステップと、
前記桁数が前記他方の機器で使用するデータの桁数よりも大きい場合、前記他方の機器から前記一方の機器へ、当該他方の機器で使用するデータの桁数を送信するステップと、
前記一方の機器にて、前記桁数を受信するステップと、
前記受信した桁数を、前記他方の機器で使用するデータの桁数として登録するステップと、
前記他方の機器から前記一方の機器へ、前記登録された桁数のデータを送信するステップと、
前記一方の機器が前記送信されたデータを受信するステップと、
を備えることを特徴とするデータ交換方法。
【請求項２】
請求項１に記載のデータ交換方法において、
前記一方の機器の記憶部には、前記他方の機器で使用するデータの桁数とを備える変換テーブルが格納され、
前記やり取りするデータの桁数を問い合わせるステップでは、前記変換テーブルを送信することで問い合わせを行い、
前記登録するステップでは、前記受信した桁数を前記変換テーブルに登録することを特徴とするデータ交換方法。
【請求項３】
請求項２に記載のデータ交換方法において、
前記記憶部は、前記一方の機器から、別の機器にデータを送信する時の桁数を備えた送信データテーブルを備え、
前記一方の機器が前記送信されたデータを受信するステップは、複数のデータを受信し、
前記一方の機器は、前記受信した複数のデータを集計するステップと、
前記集計したデータを前記送信データテーブルの桁数のデータに変換し前記別の機器に当該データを送信するステップと、
を更に備えることを特徴とするデータ交換方法。
【請求項４】
請求項１ないし３のいずれか一項に記載のデータ交換方法において、
前記一方の機器は収入管理システムの機器であり、前記他方の機器は駅システムの機器であることを特徴とするデータ交換方法。
【請求項５】
他の機器との間でデータをやり取りする機器であって、
他の機器へ、やり取りするデータの桁数を問い合わせ、前記他の機器にて使用するデータの桁数を受信する問い合わせ部通信部と、
前記受信した桁数を、前記他の機器で使用するデータの桁数として登録する処理部と、
前記他の機器から、前記桁数のデータを受信する受信部と、
を備えることを特徴とする機器。
【請求項６】
請求項５に記載の機器において、
前記機器は更に記憶部を備え、
前記記憶部には、前記他の機器で使用するデータの桁数を備える変換テーブルが格納され、
前記問い合わせ部通信部は、前記変換テーブルを前記他の機器に送信することで問い合わせを行うことを特徴とする機器。
【請求項７】
請求項６に記載の機器において、
前記記憶部は、前記機器から、別の機器にデータを送信する時の桁数を備えた送信データテーブルを備え、
前記データを前記送信データテーブルの桁数のデータに変換し前記別の機器に当該データを送信するデータ送信部とを更に備えることを特徴とする機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、収入管理システムの技術に関し、特にデータの桁数を汎用的に取り扱う技術に関する。
【背景技術】
【０００２】
現在の鉄道乗車においては、ＩＣ化や他社連絡の増加などにより、乗降人員や収入の集計において取り扱うデータ量は大幅に増加している。またマルチベンダ開発などにより外部接続システムの構成も複雑化してきている。収入管理システムでは、これらの外部要因によりシステムで使用するデータが桁あふれする場合があり、桁あふれが発生するたびに駅システムや外部システムとのインタフェース変更や接続テストを行わなければならないという問題があった。
【０００３】
桁数の取り扱いに関しては、２０００年問題の対策として西暦データを取り扱うプログラムの自動抽出や自動修正の方式がよく知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2000-242483号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
現在の鉄道乗車は乗車券のＩＣ化や取扱パターンの複雑化や詳細化により、システムで取り扱う収入データや乗車人員データなどのデータ量が大幅に増加する傾向にある。
【０００６】
一方、これらを取り扱う収入管理システムでは、多種多様な駅務機器の増加やシステム開発のマルチベンダ化により外部接続システムとのデータ連携が複雑化しており、様々な種類の異なる桁数のデータを取り扱う必要がでてきている。しかしながら、収入管理システムでは駅システムや外部システムなど各接続先システムごとに取り扱うデータの種類や桁数が異なるため、それぞれ別のインタフェースを作成して取り扱う方式が一般的である。
【０００７】
また、データに桁あふれが発生した場合は、それぞれの外部接続システムごとにインタフェースを変更して、桁あふれが発生しないように対応する方式が一般的であるが、複数の駅務機器や複数の外部接続システムのインタフェース変更や接続テストをやり直さなければならないことや、各駅のシステムに対してインタフェースを一斉に変更しなければならないなど、非常に困難を伴う。
【課題を解決するための手段】
【０００８】
本発明では、収入系データの桁数を明示したインタフェースの変換テーブルを使用することにより、新旧インタフェースの桁数を判断して処理することで、旧インタフェースのデータであっても新インタフェースのデータであっても汎用的に取り扱うことができるようにし、桁あふれが発生した場合のインタフェース変更に柔軟に対応できるようにする。
【０００９】
具体的には、取り扱う収入のデータ量が増加した場合にデータの桁数が不足する場合があるという問題に対し、駅システムと収入管理システムとで変換テーブルをやりとりして桁数が不足していた場合は桁数を追加する変換処理を行うことで、桁数の異なるインタフェースをもつ駅システムおよび外部システムとの収入データのやりとりを柔軟に行う方式に関するものである。
【００１０】
本発明では、同じタイプの収入を扱うシステムであっても、変換テーブルをそれぞれ外部システムと収入管理システムとでやりとりして使用することで、例えばｂ駅の旧インタフェースのデータは従来の桁数として処理し、ａ駅の新インタフェースのデータは新たな桁数として処理することにより、他システムとのデータ連携において、旧インタフェースのデータも新インタフェースのデータも共通的に処理することができる。
【発明の効果】
【００１１】
本発明により、乗車人員データや収入データなどが接続先システムごとに異なるインタフェースでデータ連携を行う場合にも、統一的に桁数を取り扱うことができる。また、桁あふれした場合のインタフェース変更にも柔軟に対応することができる。
【図面の簡単な説明】
【００１２】
【図１】システム構成図
【図２】収入変換テーブルのデータ構成例（収入管理システム）
【図３】収入集計データのデータ構成例（収入管理システム）
【図４】人員変換テーブルのデータ構成例（収入管理システム）
【図５】人員集計データのデータ構成例（収入管理システム）
【図６】収入データのデータ構成例（収入管理システム）
【図７】人員データのデータ構成例（収入管理システム）
【図８】収入送信データのデータ構成例（収入管理システム）
【図９】人員送信データのデータ構成例（収入管理システム）
【図１０】収入データのデータ構成例（駅システム）
【図１１】人員データのデータ構成例（駅システム）
【図１２】収入送信データのデータ構成例（外部システム）
【図１３】人員送信データのデータ構成例（外部システム）
【図１４】収入データの集計処理１（従来例）
【図１５】収入データの集計処理２（従来例）
【図１６】収入データの集計処理１
【図１７】収入データの集計処理２
【図１８】収入データの集計処理３
【図１９】収入データの集計処理４
【図２０】収入データの集計処理の具体的な説明図１
【図２１】収入データの集計処理の具体的な説明図２
【図２２】収入データの集計処理の具体的な説明図３
【発明を実施するための形態】
【実施例１】
【００１３】
以下、図面を用いて本発明の実施の形態について説明する。
【００１４】
図１は、本発明の実施の形態を表すシステム構成である。収入管理システム１０は、外部のシステムと通信を行うためのインタフェース１１、収入データの集計や変換などの演算処理を行うための処理部（ＣＰＵ）１２、収入データや収入集計データを保管するためのディスク記憶装置１３、変換テーブルなどの一時記憶として使用するメモリ記憶装置１４、を備える。ここで外部接続システムとは、収入管理システム以外のシステムを指し、その例としては、ａ駅の収入を取り扱うＡシステム２１や、人員を取り扱うＢシステム２２、ｂ駅の収入を取り扱うＣシステム２３や、人員を取り扱うＤシステム２４などの駅システムがあり、また収入管理システムが作成した収入送信データおよび人員送信データを取り扱う外部システムであるＥシステム２５がある。なお、収入管理システムと外部システム（駅システムを含む）との間の通信は、ネットワークを介して接続してもよいし、ケーブルで直接接続してもよい。
【００１５】
図２から図９は、収入管理システムにおいて収入や人員の桁数を汎用的に取り扱うために備える情報のデータ形式である。図２は収入変換テーブルを示し、この収入変換テーブルには、システム種別、駅コード、インタフェース名称、桁数、インタフェース種別を格納する。図３は収入集計データを示し、この収入集計データには、システム種別、駅コード、収入データ、取扱種別などを格納する。図４は人員変換テーブルを示し、この人員変換テーブルには、システム種別、駅コード、インタフェース名称、桁数、インタフェース種別を格納する。図５は人員集計データを示し、この人員集計データには、システム種別、駅コード、人員データ、乗降種別などを格納する。図６は収入データを示し、収入データには、システム種別、駅コード、収入データ、桁数、取扱種別などを格納する。図７は人員データを示し、この人員データには、システム種別、駅コード、人員データ、桁数、乗降種別などを格納する。図８は収入送信データを示し、この収入送信データには、システム種別、駅コード、収入データ、桁数などを格納する。図９は人員送信データを示している。この人員送信データには、システム種別、駅コード、人員データ、桁数、乗降種別などを格納する。
【００１６】
図１０、図１１は、駅システムが収入管理システムに送信する情報のデータ形式である。図１０は収入データを示し、図１１は人員データを示している。収入データは、システム種別、駅コード、収入データ、取扱種別を格納するが、収入データの桁数はもたない。人員データは、システム種別、駅コード、人員データ、乗降種別を格納するが、人員データの桁数はもたない。
【００１７】
図１２、図１３は、外部システムが収入管理システムより受信する情報のデータ形式である。図１２は、収入送信データを示し、図１３は、人員送信データを示す。
【００１８】
ここで、収入送信データは、システム種別、駅コード、収入データを格納するが、収入データの桁数はもたない。人員送信データは、システム種別、駅コード、人員データ、乗降種別を格納するが、人員データの桁数はもたない。
【００１９】
図１４、図１５は、収入管理システムにおいて、駅システムから受信した収入データを集計して、外部システムに送信する場合の従来処理のフローである。
【００２０】
駅システムでは、保存している収入データを、あらかじめインタフェースに定められた桁数のデータを収入管理システムに送信する（ステップ１００１）。収入管理システムでは、駅システムから収入データを受信し（ステップ１００２）、受信したデータがインタフェースに定められた正しい桁数であるかどうかをチェックする（ステップ１００３）。桁数が正しくない場合はエラーとして処理を終了する。
【００２１】
桁数が正しい場合は、受信したデータを集計して収入集計データを作成する（ステップ１００４）。全収入データの集計処理が完了したら（ステップ１００５）、作成した収入集計データをあらかじめインタフェースに定められた桁数のデータで外部システムに送信する（ステップ１００６）。外部システムでは、収入集計データを受信する（ステップ１００７）。なお、人員データの場合も同様の処理となる。
【００２２】
図１６、図１７、図１８は、収入管理システムにおいて、駅システムから受信した収入データを集計して、外部システムに送信する処理において、一部の駅システムが桁あふれによりインタフェースを変更した場合に、桁数を柔軟に取り扱うための処理フローである。
【００２３】
収入管理システムでは、あらかじめ収入変換テーブルとして駅コードとシステム種別ごとにインタフェース名称と収入データ桁数を登録しておく。また、収入管理システムでは、収入データを受信する相手先（駅システム）ごとに、該当するシステム種別、駅コードの収入変換テーブルを送信する（ステップ２００１）（複数の相手先があれば複数の変換テーブルを送信する）。
【００２４】
駅システムでは、駅システム側で取り扱う収入データの桁数が、収入管理システムから受信した収入変換テーブルの桁数よりも大きい（桁あふれした）場合、駅システム側の収入変換テーブルの桁数を変更（駅システム側で取り扱う収入データの桁数までカウントアップ）して、収入管理システムに送信する（ステップ２００３）。
【００２５】
収入管理システムでは、収入変換テーブルに駅システムから受信した桁数を変更（カウントアップ）した収入変換テーブルのデータを追加し（ステップ２００４）、収入変化テーブルへのデータ追加が完了したら駅システムに通知する（ステップ２００５）。これで桁あふれを防止するための準備が完了したことになる。
【００２６】
収入変換テーブルへのデータ追加が完了し、桁あふれを防止するための準備が完了た後に、駅システムから収入管理システムに収入データを送信する（ステップ２００６）。
【００２７】
収入管理システムでは、駅システムが送信した収入データを受信し（ステップ２００７）、受信した収入データのシステム種別と駅コードから収入変換テーブルを参照して、収入データの桁数を取得する（ステップ２００８）。このとき、収入変換テーブルを使用することで変換処理のオーバヘッドが増加するが、変換テーブルをメモリ上に配置するなどの工夫によりオーバヘッドが大きくならないように対処する。次に収入データに収入変換テーブルから取得した桁数を登録する（ステップ２００９）。また、受信した複数の収入データを集計して、収入集計データを作成する（ステップ２０１０）。このとき、収入集計データには他システムとやりとりするデータと比べて十分に大きい桁数をもたせるようにして桁あふれしないようにする。全収入データの集計処理が完了したら（ステップ２０１１）、システム種別と駅コードから収入変換テーブルを参照して収入送信データの桁数を取得する（ステップ２０１２）。実際の収入集計データの桁数が、収入変換テーブルから取得した収入送信データの桁数よりも大きい場合は桁あふれしているものと判断（ステップ２０１３）し、送信相手先の外部システムに該当するシステム種別、駅コードの収入変換テーブルの桁数を変更（カウントアップ）して送信する（ステップ２０１４）。
【００２８】
外部システム側では、桁数が変更された収入変換テーブルを受信し、収入変換テーブルの変更を受信したことを収入管理システムに通知する（ステップ２０１５）。
実際の収入集計データの桁数が収入変換テーブルの桁数よりも小さい（桁あふれしていない）場合は、取得した桁数を収入集計データに登録し、収入送信データを作成し（ステップ２０１６）、作成した収入送信データを外部システムに送信する（ステップ２０１７）。外部システムで収入送信データを受信する（ステップ２０１８）。なお、収入データのみでなく取り扱うデータが人員データの場合も同様の処理となる。
【００２９】
なお、図１６から図１８の説明においては、２つの機器間で桁数の情報を通知し合う際に、収入変換テーブルを送信している形態を説明した。しかし、本発明はこれに限定されるものではなく、例えば、桁数のみの情報を送信してもよい。
【００３０】
図１９は、ａ駅のＡシステムで桁あふれが発生した場合に、Ａシステムの桁あふれ検知を契機に収入管理システム側と収入変換テーブルをやりとりし、ａ駅のＡシステムは新インタフェースで異なる桁数の収入変換テーブルを使用して収入データを処理することが可能となる変換処理の例である。一方、ｂ駅のＡシステムは従来の桁数の収入データとして、旧インタフェースのままで処理することができる
この例では、収入管理システムが、全駅共通のＡシステムとの収入データのやりとりを行うための収入変換テーブル（旧インタフェース）をもっている。ａ駅に対してＡシステムとやりとりするために該当の収入変換テーブルを送信する。このときの収入変換テーブルの桁数を５桁とする。
【００３１】
駅システム側では、ａ駅のＡシステムで作成した収入データが収入管理システムから受信した旧インタフェースの桁数では不足する（桁あふれ）ため、収入変換テーブルの桁数を変更（６桁）して、収入管理システムに送信する。収入管理システムではａ駅のＡシステムで変更されたデータを収入変換テーブルに追加する。
【００３２】
次に、収入管理システムではそれぞれ駅システムから収入データを受信すると、収入変換テーブルを参照して、ａ駅のＡシステムは６桁の収入データと判断し、またｂ駅のＡシステムは５桁の収入データと判断して、それぞれの収入データに桁数を登録する。ａ駅のＡシステム、ｂ駅のＡシステムからそえぞれの収入データを集計して、収入集計データを作成する。
【００３３】
外部システムへの送信についても同様に収入変換テーブルを参照して、送信先のシステムであるＥシステムに７桁の収入データを送信すると判断し、実際の収入集計データが７桁以内におさまっているかどうかをチェックする。この例では７桁以内のため収入送信データを作成し、Ｅシステムに送信する。もし７桁以内におさまっていなければ、Ｅシステム送信用の収入変換テーブルの桁数を変更（カウントアップ）し、Ｅシステムに送信する。
【００３４】
本実施例によると、収入管理システムのデータ連携において、それぞれの駅システムや外部システムと収入変換テーブルの桁数をやりとりし、収入管理システムで変換処理を行うことで、収入データの桁数を従来よりも柔軟に処理できるようになる。これにより、桁あふれが発生した場合のインタフェース変更に対し、柔軟な処理が可能となる。また新旧混在のインタフェースも共通に処理することができる。さらに、収入変換テーブルに新たな種別を追加することにより、桁あふれに対する新旧インタフェースの対応のみでなく、異なる複数のインタフェースにも対応できるようになるなどの使い方も考えられる。
【００３５】
なお、本実施例では、変換テーブルを使用した例を説明したが、本発明はそれに限定されるものではない。変換テーブルを使用した場合は、使用しない場合と比べて変換処理による実行性能へのオーバーヘッドがかかることがあるが、メモリＤＢ化することにより、その影響を最低限に抑えられる。
【符号の説明】
【００３６】
１０：  収入管理システム、１１：インタフェース、１２：処理部（ＣＰＵ）、１３：ディスク記憶装置、１４：メモリ記憶装置、２１：Ａシステム（ａ駅  収入データ）２２：Ｂシステム（ａ駅  人員データ）、２３：Ｃシステム（ｂ駅  収入データ）、２４：Ｄシステム（ｂ駅  人員データ）、２５：Ｅシステム（外部システム）、２６：Ｆシステム（外部システム）
【図１】
0005542724.tif 000002
【図２】
0005542724.tif 000003
【図３】
0005542724.tif 000004
【図４】
0005542724.tif 000005
【図５】
0005542724.tif 000006
【図６】
0005542724.tif 000007
【図７】
0005542724.tif 000008
【図８】
0005542724.tif 000009
【図９】
0005542724.tif 000010
【図１０】
0005542724.tif 000011
【図１１】
0005542724.tif 000012
【図１２】
0005542724.tif 000013
【図１３】
0005542724.tif 000014
【図１４】
0005542724.tif 000015
【図１５】
0005542724.tif 000016
【図１６】
0005542724.tif 000017
【図１７】
0005542724.tif 000018
【図１８】
0005542724.tif 000019
【図１９】
0005542724.tif 000020
【図２０】
0005542724.tif 000021
【図２１】
0005542724.tif 000022
【図２２】
0005542724.tif 000023