駅務機器の処理ロジック検証装置
【課題】 シミュレートする経路パターンの数を大幅に減らし、全経路パターンについての検証を可能にし、運賃誤収受、誤判定を防止することを目的とする。
【解決手段】 異なる路線が接続する交叉駅、及び乗り換え用／連絡用ラッチをノードとして定義したノードデータ（３１）、同一線区上のノード間をブロックと定義したブロックデータ（３２）を格納した記憶手段（３）と、前記記憶手段からノードデータ、ブロックデータを読み出して経路パターンを生成し、テスト券を生成するテスト券生成手段（１）と、駅務機器の処理モジュールを組み込んだ複数のシミュレータ（２−１〜２−ｎ）とを備え、前記テスト券を各シミュレータに読み込ませて駅務機器の処理を実行させ、各シミュレータでの処理結果を比較するようにしたものである。
【解決手段】 異なる路線が接続する交叉駅、及び乗り換え用／連絡用ラッチをノードとして定義したノードデータ（３１）、同一線区上のノード間をブロックと定義したブロックデータ（３２）を格納した記憶手段（３）と、前記記憶手段からノードデータ、ブロックデータを読み出して経路パターンを生成し、テスト券を生成するテスト券生成手段（１）と、駅務機器の処理モジュールを組み込んだ複数のシミュレータ（２−１〜２−ｎ）とを備え、前記テスト券を各シミュレータに読み込ませて駅務機器の処理を実行させ、各シミュレータでの処理結果を比較するようにしたものである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は自動改札機、窓処理機、精算機等の駅務機器処理ロジックを検証する装置に関する。
【背景技術】
【０００２】
自動改札機、窓処理機、精算機等の駅務機器が各駅に設置され、定期券や乗車券の情報を電子データとして格納したＩＣカードやＳＦカード（ストアード・フェアー・カード）が使用され、各駅務機器ではＩＣカードやＳＦカードのデータを読み込んで最短、最安で運賃計算して精算している。
【０００３】
しかし、鉄道線路は複雑に接続しているため運賃算定が複雑な場合があり、運賃算定についての問題点も指摘されている。従来では、指摘された過去の問題点を中心に経路パターンを人間が想定し、当該経路パターンに妥当する券種（定期券、ＳＦカード等）及び入場駅と出場駅を設定し、各駅務機器の処理モジュールを搭載した複数の判定シミュレータにかけ、判定結果を突き合わせて比較検討していた。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、過去の問題点を中心に人間が想定した経路パターンでの検証では、想定に漏れるパターンが存在し、運賃誤収受につながるおそれがあった。
また、シミュレータにより判定を行うためにはシミュレータにかけるテスト券を作成する必要がある。例えば、出場判定検証を行う場合には、テスト券に入場駅を設定し、シミュレータ側には任意の出場駅設定が必要となる。したがって、各券種に対する入場駅−経由駅−出場駅の経路パターンを作ってもテスト券用の入場駅−経由駅とシミュレータ用の出場駅に分ける必要があり、分けた後の双方のリンクの取り方が課題となる。
また、シミュレートを実施するためにはいろいろな経路パターンを作成する必要があるが、膨大な数のパターンを人手で作成するのは困難である。
【課題を解決するための手段】
【０００５】
本発明は上記課題を解決しようとするもので、シミュレートする経路パターンの数を大幅に減らし、全経路パターンについての検証を可能にし、運賃誤収受、誤判定を防止することを目的とする。
そのために請求項１の発明は、異なる路線が接続する交叉駅、及び乗り換え用／連絡用ラッチをノードとして定義したノードデータ、同一線区上のノード間をブロックと定義したブロックデータを格納した記憶手段と、
前記記憶手段からノードデータ、ブロックデータを読み出して経路パターンを生成し、テスト券を生成するテスト券生成手段と、
駅務機器の処理モジュールを組み込んだ複数のシミュレータと、
を備え、前記テスト券を各シミュレータに読み込ませて駅務機器の処理を実行させ、各シミュレータでの処理結果を比較するようにしたことを特徴とする。
請求項２の発明は、前記テスト券生成手段が、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせて定期用経路パターンを生成することを特徴とする。
請求項３の発明は、前記テスト券生成手段が、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、乗り換え用／連絡用ラッチを含むＳＦ用経路パターンを生成することを特徴とする。
請求項４の発明は、前記テスト券生成手段が、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせるとともに、乗り換え用／連絡用ラッチデータを加えて定期・ＳＦ併用経路パターンを生成することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、１ブロック内は駅１つと見做して入場駅、出場駅を設定することにより、シミュレートする経路パターンの数を大幅に減らすことができるので、検証すべき全ての経路パターンを効率的かつ自動的に生成して検証することが可能となり、運賃誤収受、誤判定を防止すること可能となる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態について説明する。
図１は本発明の処理ロジック検証装置を説明するブロック図、図２は２駅間運賃を説明するための図、図３は処理ロジックを説明する路線図である。
図１に示すように、処理ロジック検証装置は、コンピュータ内に組み込まれたプログラムで構成されるテスト券生成手段１で生成したテスト券を各シミュレータ２−１〜２−ｎに読み込ませて所定の処理を実行させ、それぞれの処理結果を突き合わせて検討するというものである。テスト券生成手段１は、後述するように、メモリ３に格納されているノードデータ３１、ブロックデータ３２を読みだして定期用テスト券、ＳＦ用テスト券、定期・ＳＦ兼用テスト券を生成する。なお、各シミュレータは駅務機器に搭載された処理モジュールと同じモジュールをコンピュータに組み込んだものであり、テスト券生成手段１とシミュレータ２−１〜２−ｎとは同じコンピュータ内に搭載したものであってもよい。
【０００８】
本来、同じ処理を行う駅務機器は全て同じ処理結果を出力すべきであるが、現実には異なる会社で作製されたもの、異なる路線に配置されたもの等においては少しの設計思想の違いから同じ処理結果とならない場合がある。そのため、いろいろな経路パターンを設定してテスト券を生成し、その処理ロジックに違いがあるか否かを検証する必要がある。
【０００９】
テスト券に設定する経路パターンは、従来、過去の問題点を中心に人間が想定して作成していたが、この方法では、想定に漏れるパターンが生じるのは避けられない。そこで、本発明においては、あらゆる経路パターンの作成を効率よく、かつ自動化して作成しようとするものであり、その方法について図２、図３を参照して説明する。
【００１０】
全経路パターンを作成しようとすると、全ての駅を発駅または着駅に設定して経路を作成する必要がある。しかし、この方法では発駅と着駅の組み合わせが膨大になりすぎて現実的ではない。駅務機器の処理ロジックの検証は最終的には料金計算が妥当か否かに帰着する。鉄道運賃は同一路線を重複乗車しない条件で、最短、最安で徴収するのを原則としているが、運賃徴収ロジックに問題の生じようがない場合は簡略化しても差し支えない。例えば、図２において、田町−浜松町間、田町−新橋間の運賃は２駅間運賃テーブルに設定されており、駅務機器では単に運賃テーブルから読み出すだけの処理ですみ、処理ロジックの検証において、この２つのケースを別経路として分ける必要がない。詰まり、処理ロジック上では、品川駅と東京駅のように異なる路線が接続する交差駅同士の間（同一線区内）の任意の２駅間（例えば田町−浜松町、新橋−有楽町）の運賃は２駅間運賃テーブルに設定されていて自明であるので、品川−東京間内の異なる駅を発駅または着駅とした経路パターン、例えば、田町を発駅または着駅とした経路パターンと新橋を発駅または着駅とした経路パターンとは同一の経路パターンとしても問題は生じない。このような考え方により、経路パターンの数を大幅に減らすことが可能である。
【００１１】
図３において、路線ａと路線ｂ，ｃ，ｅがＡ駅、Ｄ駅、Ｇ駅で接続し、路線ｄがＥ駅とＩ駅においてラッチＬで乗換または連絡しているものとする。ここで、異なる路線が接続している交差駅Ａ、Ｄ、Ｇをノード、ノード間を１ブロック区間と定義し、１ブロック区間内の路線をエッジと呼ぶ。また、路線ａと路線ｄを連絡しているようなラッチＬも交差駅と同様にノードとして定義する。
【００１２】
例えば、路線ａのＢ駅と路線ｅのＫ駅を端駅とする定期用経路は、Ｂ駅を含むブロック、Ｄ駅ーＧ駅間ブロック、Ｋ駅を含むブロックを接続することにより生成され、入場駅または出場駅である端駅（Ｂ駅、Ｋ駅）は、その駅が含まれるブロック内の任意の１つの駅だけを設定すればよい。この定期を用いて、例えば路線ｄと路線ｅとが接続するＪ駅で降車した場合を想定すると、運賃計算は、定期券の端駅Ｂ、Ｋ、定期区間内の交差接続駅Ｄ、Ｇと、降車駅であるＪ駅との間の運賃をそれぞれ求めて、その中で最短・最安運賃として求められる。こうして、検証すべき任意の定期用経路パターンは、図４に示すように、端駅を含むブロックと、端駅間のブロックを接続することにより生成される。なお、ここでは図４における端部ブロックの端駅（Ｐ駅、Ｑ駅）は含まない。
【００１３】
また、ＳＦ券を単独で使用したときの運賃は、接続駅での乗り換えのデータは記録されず、ラッチ連絡（データが記録される）がなければ発駅と着駅の２駅間運賃テーブルで算出され、ブロック内を１駅としてみるのと同様に特に検証する必要は生じない。ラッチを通った場合はその記録が残って運賃が算定されるので検証する必要がある。したがって、検証すべき任意のＳＦ用経路パターンは、発駅−ラッチ（ノード）−着駅で生成され、発駅、着駅は任意に選定すればよい。
【００１４】
また、定期券とＳＦ券を併用する場合の検証すべき経路パターンは、図４に示すようにブロックを接続し、さらに中間にラッチ（ノード）を含ませるようにして生成することにより得られる。
【産業上の利用可能性】
【００１５】
本発明によれば、あらゆる経路パターンについて駅務機器の検証が可能となり、運賃誤収受、誤判定を防止することが可能となるので、産業上の利用価値は極めて大きい。
【図面の簡単な説明】
【００１６】
【図１】処理ロジック検証装置を説明するブロック図である。
【図２】２駅間運賃を説明する図である。
【図３】処理ロジックを説明する路線図である。
【図４】経路の生成を説明する路線図である。
【符号の説明】
【００１７】
１…テスト券生成手段、２−１〜２−ｎ…シミュレータ、３…メモリ、３１…ノードデータ、３２…ブロックデータ。
【技術分野】
【０００１】
本発明は自動改札機、窓処理機、精算機等の駅務機器処理ロジックを検証する装置に関する。
【背景技術】
【０００２】
自動改札機、窓処理機、精算機等の駅務機器が各駅に設置され、定期券や乗車券の情報を電子データとして格納したＩＣカードやＳＦカード（ストアード・フェアー・カード）が使用され、各駅務機器ではＩＣカードやＳＦカードのデータを読み込んで最短、最安で運賃計算して精算している。
【０００３】
しかし、鉄道線路は複雑に接続しているため運賃算定が複雑な場合があり、運賃算定についての問題点も指摘されている。従来では、指摘された過去の問題点を中心に経路パターンを人間が想定し、当該経路パターンに妥当する券種（定期券、ＳＦカード等）及び入場駅と出場駅を設定し、各駅務機器の処理モジュールを搭載した複数の判定シミュレータにかけ、判定結果を突き合わせて比較検討していた。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、過去の問題点を中心に人間が想定した経路パターンでの検証では、想定に漏れるパターンが存在し、運賃誤収受につながるおそれがあった。
また、シミュレータにより判定を行うためにはシミュレータにかけるテスト券を作成する必要がある。例えば、出場判定検証を行う場合には、テスト券に入場駅を設定し、シミュレータ側には任意の出場駅設定が必要となる。したがって、各券種に対する入場駅−経由駅−出場駅の経路パターンを作ってもテスト券用の入場駅−経由駅とシミュレータ用の出場駅に分ける必要があり、分けた後の双方のリンクの取り方が課題となる。
また、シミュレートを実施するためにはいろいろな経路パターンを作成する必要があるが、膨大な数のパターンを人手で作成するのは困難である。
【課題を解決するための手段】
【０００５】
本発明は上記課題を解決しようとするもので、シミュレートする経路パターンの数を大幅に減らし、全経路パターンについての検証を可能にし、運賃誤収受、誤判定を防止することを目的とする。
そのために請求項１の発明は、異なる路線が接続する交叉駅、及び乗り換え用／連絡用ラッチをノードとして定義したノードデータ、同一線区上のノード間をブロックと定義したブロックデータを格納した記憶手段と、
前記記憶手段からノードデータ、ブロックデータを読み出して経路パターンを生成し、テスト券を生成するテスト券生成手段と、
駅務機器の処理モジュールを組み込んだ複数のシミュレータと、
を備え、前記テスト券を各シミュレータに読み込ませて駅務機器の処理を実行させ、各シミュレータでの処理結果を比較するようにしたことを特徴とする。
請求項２の発明は、前記テスト券生成手段が、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせて定期用経路パターンを生成することを特徴とする。
請求項３の発明は、前記テスト券生成手段が、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、乗り換え用／連絡用ラッチを含むＳＦ用経路パターンを生成することを特徴とする。
請求項４の発明は、前記テスト券生成手段が、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせるとともに、乗り換え用／連絡用ラッチデータを加えて定期・ＳＦ併用経路パターンを生成することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、１ブロック内は駅１つと見做して入場駅、出場駅を設定することにより、シミュレートする経路パターンの数を大幅に減らすことができるので、検証すべき全ての経路パターンを効率的かつ自動的に生成して検証することが可能となり、運賃誤収受、誤判定を防止すること可能となる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態について説明する。
図１は本発明の処理ロジック検証装置を説明するブロック図、図２は２駅間運賃を説明するための図、図３は処理ロジックを説明する路線図である。
図１に示すように、処理ロジック検証装置は、コンピュータ内に組み込まれたプログラムで構成されるテスト券生成手段１で生成したテスト券を各シミュレータ２−１〜２−ｎに読み込ませて所定の処理を実行させ、それぞれの処理結果を突き合わせて検討するというものである。テスト券生成手段１は、後述するように、メモリ３に格納されているノードデータ３１、ブロックデータ３２を読みだして定期用テスト券、ＳＦ用テスト券、定期・ＳＦ兼用テスト券を生成する。なお、各シミュレータは駅務機器に搭載された処理モジュールと同じモジュールをコンピュータに組み込んだものであり、テスト券生成手段１とシミュレータ２−１〜２−ｎとは同じコンピュータ内に搭載したものであってもよい。
【０００８】
本来、同じ処理を行う駅務機器は全て同じ処理結果を出力すべきであるが、現実には異なる会社で作製されたもの、異なる路線に配置されたもの等においては少しの設計思想の違いから同じ処理結果とならない場合がある。そのため、いろいろな経路パターンを設定してテスト券を生成し、その処理ロジックに違いがあるか否かを検証する必要がある。
【０００９】
テスト券に設定する経路パターンは、従来、過去の問題点を中心に人間が想定して作成していたが、この方法では、想定に漏れるパターンが生じるのは避けられない。そこで、本発明においては、あらゆる経路パターンの作成を効率よく、かつ自動化して作成しようとするものであり、その方法について図２、図３を参照して説明する。
【００１０】
全経路パターンを作成しようとすると、全ての駅を発駅または着駅に設定して経路を作成する必要がある。しかし、この方法では発駅と着駅の組み合わせが膨大になりすぎて現実的ではない。駅務機器の処理ロジックの検証は最終的には料金計算が妥当か否かに帰着する。鉄道運賃は同一路線を重複乗車しない条件で、最短、最安で徴収するのを原則としているが、運賃徴収ロジックに問題の生じようがない場合は簡略化しても差し支えない。例えば、図２において、田町−浜松町間、田町−新橋間の運賃は２駅間運賃テーブルに設定されており、駅務機器では単に運賃テーブルから読み出すだけの処理ですみ、処理ロジックの検証において、この２つのケースを別経路として分ける必要がない。詰まり、処理ロジック上では、品川駅と東京駅のように異なる路線が接続する交差駅同士の間（同一線区内）の任意の２駅間（例えば田町−浜松町、新橋−有楽町）の運賃は２駅間運賃テーブルに設定されていて自明であるので、品川−東京間内の異なる駅を発駅または着駅とした経路パターン、例えば、田町を発駅または着駅とした経路パターンと新橋を発駅または着駅とした経路パターンとは同一の経路パターンとしても問題は生じない。このような考え方により、経路パターンの数を大幅に減らすことが可能である。
【００１１】
図３において、路線ａと路線ｂ，ｃ，ｅがＡ駅、Ｄ駅、Ｇ駅で接続し、路線ｄがＥ駅とＩ駅においてラッチＬで乗換または連絡しているものとする。ここで、異なる路線が接続している交差駅Ａ、Ｄ、Ｇをノード、ノード間を１ブロック区間と定義し、１ブロック区間内の路線をエッジと呼ぶ。また、路線ａと路線ｄを連絡しているようなラッチＬも交差駅と同様にノードとして定義する。
【００１２】
例えば、路線ａのＢ駅と路線ｅのＫ駅を端駅とする定期用経路は、Ｂ駅を含むブロック、Ｄ駅ーＧ駅間ブロック、Ｋ駅を含むブロックを接続することにより生成され、入場駅または出場駅である端駅（Ｂ駅、Ｋ駅）は、その駅が含まれるブロック内の任意の１つの駅だけを設定すればよい。この定期を用いて、例えば路線ｄと路線ｅとが接続するＪ駅で降車した場合を想定すると、運賃計算は、定期券の端駅Ｂ、Ｋ、定期区間内の交差接続駅Ｄ、Ｇと、降車駅であるＪ駅との間の運賃をそれぞれ求めて、その中で最短・最安運賃として求められる。こうして、検証すべき任意の定期用経路パターンは、図４に示すように、端駅を含むブロックと、端駅間のブロックを接続することにより生成される。なお、ここでは図４における端部ブロックの端駅（Ｐ駅、Ｑ駅）は含まない。
【００１３】
また、ＳＦ券を単独で使用したときの運賃は、接続駅での乗り換えのデータは記録されず、ラッチ連絡（データが記録される）がなければ発駅と着駅の２駅間運賃テーブルで算出され、ブロック内を１駅としてみるのと同様に特に検証する必要は生じない。ラッチを通った場合はその記録が残って運賃が算定されるので検証する必要がある。したがって、検証すべき任意のＳＦ用経路パターンは、発駅−ラッチ（ノード）−着駅で生成され、発駅、着駅は任意に選定すればよい。
【００１４】
また、定期券とＳＦ券を併用する場合の検証すべき経路パターンは、図４に示すようにブロックを接続し、さらに中間にラッチ（ノード）を含ませるようにして生成することにより得られる。
【産業上の利用可能性】
【００１５】
本発明によれば、あらゆる経路パターンについて駅務機器の検証が可能となり、運賃誤収受、誤判定を防止することが可能となるので、産業上の利用価値は極めて大きい。
【図面の簡単な説明】
【００１６】
【図１】処理ロジック検証装置を説明するブロック図である。
【図２】２駅間運賃を説明する図である。
【図３】処理ロジックを説明する路線図である。
【図４】経路の生成を説明する路線図である。
【符号の説明】
【００１７】
１…テスト券生成手段、２−１〜２−ｎ…シミュレータ、３…メモリ、３１…ノードデータ、３２…ブロックデータ。
【特許請求の範囲】
【請求項１】
異なる路線が接続する交叉駅、及び乗り換え用／連絡用ラッチをノードとして定義したノードデータ、同一線区上のノード間をブロックと定義したブロックデータを格納した記憶手段と、
前記記憶手段からノードデータ、ブロックデータを読み出して経路パターンを生成し、テスト券を生成するテスト券生成手段と、
駅務機器の処理モジュールを組み込んだ複数のシミュレータと、
を備え、前記テスト券を各シミュレータに読み込ませて駅務機器の処理を実行させ、各シミュレータでの処理結果を比較するようにしたことを特徴とする駅務機器の処理ロジック検証装置。
【請求項２】
前記テスト券生成手段は、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせて定期用経路パターンを生成することを特徴とする請求項１記載の駅務機器の処理ロジック検証装置。
【請求項３】
前記テスト券生成手段は、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、乗り換え用／連絡用ラッチを含むＳＦ用経路パターンを生成することを特徴とする請求項１記載の駅務機器の処理ロジック検証装置。
【請求項４】
前記テスト券生成手段は、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせるとともに、乗り換え用／連絡用ラッチデータを加えて定期・ＳＦ併用経路パターンを生成することを特徴とする請求項１記載の駅務機器の処理ロジック検証装置。
【請求項１】
異なる路線が接続する交叉駅、及び乗り換え用／連絡用ラッチをノードとして定義したノードデータ、同一線区上のノード間をブロックと定義したブロックデータを格納した記憶手段と、
前記記憶手段からノードデータ、ブロックデータを読み出して経路パターンを生成し、テスト券を生成するテスト券生成手段と、
駅務機器の処理モジュールを組み込んだ複数のシミュレータと、
を備え、前記テスト券を各シミュレータに読み込ませて駅務機器の処理を実行させ、各シミュレータでの処理結果を比較するようにしたことを特徴とする駅務機器の処理ロジック検証装置。
【請求項２】
前記テスト券生成手段は、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせて定期用経路パターンを生成することを特徴とする請求項１記載の駅務機器の処理ロジック検証装置。
【請求項３】
前記テスト券生成手段は、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、乗り換え用／連絡用ラッチを含むＳＦ用経路パターンを生成することを特徴とする請求項１記載の駅務機器の処理ロジック検証装置。
【請求項４】
前記テスト券生成手段は、ブロック内は１つの駅と見做して入場駅、出場駅を設定し、隣接するブロックをつなぎ合わせるとともに、乗り換え用／連絡用ラッチデータを加えて定期・ＳＦ併用経路パターンを生成することを特徴とする請求項１記載の駅務機器の処理ロジック検証装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００６−２６８２３２（Ｐ２００６−２６８２３２Ａ）
【公開日】平成１８年１０月５日（２００６．１０．５）
【国際特許分類】
【出願番号】特願２００５−８３２６０（Ｐ２００５−８３２６０）
【出願日】平成１７年３月２３日（２００５．３．２３）
【出願人】（５９３０９２４８２）ジェイアール東日本メカトロニクス株式会社 (85)
【公開日】平成１８年１０月５日（２００６．１０．５）
【国際特許分類】
【出願日】平成１７年３月２３日（２００５．３．２３）
【出願人】（５９３０９２４８２）ジェイアール東日本メカトロニクス株式会社 (85)
[ Back to top ]