(57)【要約】      （修正有）【課題】列車などの停車位置を永続的に把握できる運行管理システム及び車載端末装置を提供する。【解決手段】運行管理システム及び車載端末装置は、複数のアクセスポイントから送信されるＭＡＣアドレスを参照テーブルＴＢＬのＭＡＣアドレスと対比して停車駅を特定する第１処理ＳＴ１〜ＳＴ１３と、第１処理で特定したＭＡＣアドレスの受信強度が有意レベルを下回ると、停車駅を発車したと判定する第２処理と、停車駅を本部コンピュータに連絡する第３処理ＳＴ１４とを有して構成される。参照テーブルＴＢＬのＭＡＣアドレスが、停車駅で取得した情報に基づいて更新され、停車位置が永続的に把握される。【選択図】図４
2018121488.tif 000002
【特許請求の範囲】
【請求項１】
移動体通信網を経由して、本部コンピュータに接続可能な通信部と、停車駅に設置されている複数のアクセスポイントから各々送信される一意の送信情報を、その停車駅を特定する複数の参照情報として、停車駅に対応付けて記憶する参照情報記憶部と、を有して構成され、地下空間も含めて走行可能な移動車両に搭載されて使用される車載端末装置であって、
複数のアクセスポイントから送信される複数の送信情報を受信して、受信強度が所定レベルを超える送信情報と、参照情報記憶部に記憶されている参照情報とを、順番に対比して、一致する参照情報を特定すると共に、その参照情報に対応する停車駅を特定する第１手段と、
その後、第１手段が特定した送信情報を繰り返し受信して、その受信強度が有意レベルを下回ると、第１手段が特定した停車駅を発車したと判定する第２手段と、
第１手段及び／又は第２手段の動作に対応して、特定された停車駅を本部コンピュータに連絡する第３手段と、を有して構成され、
参照情報記憶部に記憶されている参照情報のうち、複数回の停車において繰り返し検出されない未検出の参照情報と、
参照情報記憶部に記憶されていない送信情報であって、複数回の停車動作において繰り返し検出される新規の送信情報と、に基づいて、
参照情報記憶部の記憶内容が更新されるようになっていることを特徴とする車載端末装置。
【請求項２】
第１手段及び第２手段は、移動車両の走行路線が特定されない状態で機能する請求項１に記載の車載端末装置。
【請求項３】
ＧＰＳ情報を取得可能に構成され、ＧＰＳ情報が取得される場合には、緯度と経度の情報に基づいて特定される停車位置が、本部コンピュータに連絡される請求項１又は２に記載の車載端末装置。
【請求項４】
複数Ｍ回連続して未検出となることを条件に、その参照情報が参照情報記憶部から削除される請求項１〜３の何れかに記載の車載端末装置。
【請求項５】
所定の停車駅において、複数Ｎ回連続して検出されることを条件に、その送信情報が参照情報記憶部に新規登録される請求項１〜４の何れかに記載の車載端末装置。
【請求項６】
第１手段は、所定の計測期間において、複数のアクセスポイントから送信される複数の送信情報を受信して、その受信強度が高い順番に参照情報と対比し、最初に一致した参照情報に対応する停車駅に、移動車両が到着したと判定する請求項１〜５の何れかに記載の車載端末装置。
【請求項７】
第１手段は、
所定の計測期間において、複数のアクセスポイントから送信される複数の送信情報を受信して、その受信強度が高い順番に、送信情報と参照情報とを対比し、
最初に一致した参照情報に基づいて特定される停車駅と、受信強度に劣る他の送信情報と一致する参照情報に基づいて特定される停車駅と、
が一致することを条件に、その停車駅に移動車両が到着したと判定する請求項１〜５の何れかに記載の車載端末装置。
【請求項８】
第２手段が到着駅から発車したと判定した後は、
その到着駅に対応する参照情報は、次に機能する第１手段の対比処理において除去される請求項１〜７の何れかに記載の車載端末装置。
【請求項９】
前記送信情報は、アクセスポイントから送信されるビーコンに含まれるＭＡＣアドレスである請求項１〜８の何れかに記載の車載端末装置。
【請求項１０】
請求項１〜請求項９の何れかの車載端末装置を有して構成される運行管理システム。
【請求項１１】
請求項１〜請求項９の何れかに記載の車載端末装置に搭載されて機能し、第１手段乃至第３手段を実現するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＧＰＳ（Global Positioning System ）を利用できない地下でも、鉄道車両などの停車駅を簡易に把握できる運行管理システム及び車載端末装置に関する。
【背景技術】
【０００２】
本出願人は、ＧＰＳを有効活用して、移動中の鉄道車両の現在位置を把握して、安全運行を実現する発明を提案している（特許文献１〜２）。この発明では、ＧＰＳを利用できない地下空間では、地点発信機や、自社の専用通信回線を利用して、列車の位置を把握している。
【０００３】
そして、他社線と相互乗り入れをするような場合、地点発信機や専用通信回線を利用できない他社路線では、他社との相互協力によって、列車の安全運行を担保している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２０７６２１号公報
【特許文献２】特開２０１３−０８６６０８号公報
【特許文献３】特開２０１４−１３８４１９号公報
【発明の概要】
【０００５】
しかし、安全な列車運行の問題とは別に、各列車について、延べ走行距離などの把握のために、停車駅や、その駅への到着時間、及び／又は、その駅からの発車時間などを、運転手や車掌に新たな作業負担を課すことなく、概略的に把握したい場合もある。
【０００６】
ここで、ＷｉＦｉ（図形は登録商標）を活用して、地下路線における現在位置を把握することも考えられる（特許文献３）。しかし、特許文献３に記載の発明は、現在地点に関する最適候補を抽出する一方法を教示するに過ぎず、鉄道車両に関して、永続的に使用できるものではない。
【０００７】
すなわち、ネットワーク機器の移動や廃棄などに基づき、各地点で検出されるＭａｃアドレス（Media Access Control address）には、永続性が担保されないので、上記の発明は、仮に、システム構築時には有効に機能しても、その後、目的のＭａｃアドレスが検出されなくなると位置把握ができなくなるという問題がある。
【発明が解決しようとする課題】
【０００８】
本発明は、上記の問題点に鑑みてなされたものであって、列車などの停車位置を永続的に把握できる運行管理システム及び車載端末装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記の目的を達成するため、本発明は、移動体通信網を経由して、本部コンピュータに接続可能な通信部と、停車駅に設置されている複数のアクセスポイントから各々送信される一意の送信情報を、その停車駅を特定する複数の参照情報として、停車駅に対応付けて記憶する参照情報記憶部と、を有して構成され、地下空間も含めて走行可能な移動車両に搭載されて使用される車載端末装置であって、複数のアクセスポイントから送信される複数の送信情報を受信して、受信強度が所定レベルを超える送信情報と、参照情報記憶部に記憶されている参照情報とを、順番に対比して、一致する参照情報を特定すると共に、その参照情報に対応する停車駅を特定する第１手段と、その後、第１手段が特定した送信情報を繰り返し受信して、その受信強度が有意レベルを下回ると、第１手段が特定した停車駅を発車したと判定する第２手段と、第１手段及び／又は第２手段の動作に対応して、特定された停車駅を本部コンピュータに連絡する第３手段と、を有して構成され、参照情報記憶部に記憶されている参照情報のうち、複数回の停車において繰り返し検出されない未検出の参照情報と、参照情報記憶部に記憶されていない送信情報であって、複数回の停車動作において繰り返し検出される新規の送信情報と、に基づいて、参照情報記憶部の記憶内容が更新されるようになっている。
【発明の効果】
【００１０】
上記した本発明によれば、簡易な構成によって、列車などの停車位置を永続的に把握することができる。
【図面の簡単な説明】
【００１１】
【図１】実施例に係る運行管理システムＳＹＳを示すブロック図である。
【図２】参照テーブルＴＢＬの一部であって特定の○○駅についての記憶データを示している。
【図３】特定の○○駅についての候補テーブルＮｅｗを示す図面である。
【図４】車載端末装置の定常処理であって、停車駅を検出するまでの動作を説明するフローチャートである。
【図５】車載端末装置の定常処理であって、停車駅を発車するまでの動作を説明するフローチャートである。
【図６】停車駅を検出する処理を変更した図４の変形例を説明するフローチャートである。
【発明を実施するための形態】
【００１２】
以下、実施例について更に詳細に説明する。図１は、実施例に係る運行管理システムＳＹＳを示すブロック図である。図示の通り、この運行管理システムＳＹＳは、鉄道車両に搭載される車載端末装置ＴＭと、管理コンピュータＰＣとが、移動体通信網Ｍｏｂ及び仮想プライベートネットワーク（Virtual Private Network ）ＮＥＴを経由して接続されて構成されている。
【００１３】
一般に、仮想プライベートネットワーク（ＶＰＮ）は、インタネットＶＰＮとＩＰ−ＶＰＮ（Internet Protocol Virtual Private Network ）に二分されるが、本実施例では、管理コンピュータＰＣと車載端末装置ＴＭが、インタネットＶＰＮ（Virtual Private Network ）で接続されている。また、管理コンピュータＰＣは、管理対象の全ての鉄道車両について、その運行距離や運行実績などの管理情報を記憶するデータベースＤＢを有しており、車載端末装置ＴＭから受ける運行情報に基づいて記憶内容を適宜に更新している。
【００１４】
車載端末装置ＴＭは、ＷｉＦｉルータとの通信が可能なＷｉＦｉ通信部（無線ＬＡＮ子機）と、コンピュータ回路と、を有して構成され、例えば、汎用のスマホに専用アプリ（Application Program 図５〜図６）と、参照テーブルＴＢＬ（図２）などをインストールして実現される。
【００１５】
なお、この車載端末装置ＴＭは、典型的には、鉄道車両を特定して、列車の適所に配置されるが、複数の鉄道車両において、適宜に使い回す場合でも、動作開始時にその列車を特定する列車ＩＤなどを設定すれば、各鉄道車両の走行距離などを、管理コンピュータＰＣで把握することができる。
【００１６】
図１は、鉄道車両が、他社の地下路線を走行している状態を示しており、Ａ駅もＢ駅も地下駅であるためＧＰＳを利用することができず、また、他社路線であるので、地点発信機や専用通信回線を利用することもできない状態を示している。
【００１７】
図示の通り、Ａ駅やＢ駅には、ＷｉＦｉルータたる多数のアクセスポイント（ＡＰａｉ，ＡＰｂｊ）が配置されており、各アクセスポイント（ＡＰａｉ，ＡＰｂｊ）からは、例えば、１００ｍＳ毎にビーコンが繰り返し放射されている。
【００１８】
放射されるビーコンは、IEEE802.11に規定された各種情報を含むが、各種情報には、各アクセスポイントを一意に特定するＭＡＣアドレス（Media Access Control address）が含まれている。そして、車載端末装置ＴＭの専用アプリは、ＷｉＦｉ通信部を通して、ＭＡＣアドレスと、その受信強度を取得できるよう構成されている。なお、車載端末装置ＴＭは、一般の携帯電話と同様の通信モジュール（communication module）を内蔵して構成されており、電気通信事業者の携帯基地局を経由した通信も実行される（ＳＴ１４，ＳＴ２４参照）。
【００１９】
上記の構成に対応して、本実施例では、自社の鉄道車両が停車する可能性のある全ての地下駅について、各々、複数のＭＡＣアドレスを予め収集しておき、停車駅に対応させて、車載端末装置ＴＭの参照テーブルＴＢＬ（図２）に、書き換え可能に登録している。そして、列車に搭載された車載端末装置ＴＭが、参照テーブルＴＢＬに登録されている何れかＭＡＣアドレスを検出すれば、検出されたＭＡＣアドレスに対応する地下駅に到着したと判定している。
【００２０】
図２は、車載端末装置ＴＭに搭載される参照テーブルＴＢＬの一部であって、特定の○○駅についての登録情報を例示している。図示の通り、参照テーブルＴＢＬは、ＭＡＣアドレス欄と、列車の到着や発車を判定する受信強度の判定閾値欄と、消滅したＭＡＣアドレスを特定するための未検出フラグ欄と、連続未検出回数を特定する連続失敗回数欄と、を有して構成されている。
【００２１】
ここで、受信強度ＲＳＳＩ（Received Signal Strength Indicator）は、受信電力［ｍＷ］に対して、１０＊Ｌｏｇ（受信電力）で与えられるｄＢ値であり、例えば、受信電力１［ｍＷ］で０ｄＢとなる。したがって、通常の場合、受信強度は、必ず、負の値となり、この実施例では、−９０ｄＢを、ステップＳＴ３で判定される最低基準値ＢＳとしている。
【００２２】
また、図２の参照テーブルＴＢＬにおいて、ＭＡＣアドレスの未検出フラグは、○○駅の到着時に、専用アプリによって１又は０の値とされる。そして、列車発車タイミングにおいて、未検出フラグ＝１となる場合は、○○駅では、このＭＡＣアドレスが検出されなかったことを意味し、逆に、未検出フラグ＝０となっている場合は、○○駅で、このＭＡＣアドレスが検出されたことを意味する。
【００２３】
図２の参照テーブルＴＢＬにおいて、連続失敗回数は、○○駅の到着時において、連続して未検出状態が何回続いたかを示している。このような連続失敗回数を検出するため、本実施例では、例えば、複数回連続して未検出でも、その後の到着時に、検出状態となれば、連続失敗回数をゼロに初期設定している。
【００２４】
このようにして算出される連続失敗回数が規定値に達すると、そのＭＡＣアドレスを発信していたネットワーク機器が、移動されたか、廃棄されたと判断して、参照テーブルＴＢＬの更新時に、このＭＡＣアドレスと、その付属データを参照テーブルＴＢＬから削除するようにしている。
【００２５】
なお、先に説明した通り、図２は、○○駅について記載した参照テーブルＴＢＬの一部であって、実際の参照テーブルＴＢＫは、停車可能性のある全ての地下駅について、ＭＡＣアドレスとその他の情報が、一連に記憶されている。そして、到着駅の判定時には、全ての地下駅について、順番にＭＡＣアドレスの一致判定の処理が実行される。
【００２６】
したがって、本実施例では、列車が始発駅を発車する時に、その列車の走行路線を特定する必要が無く、せいぜい、その列車の走行開始時（営業運転開始時）に、車載端末装置ＴＭの電源を投入し、営業運転終了時に電源を遮断するだけで良い。すなわち、本実施例の運用において、車掌や運転手に余分な作業負担を課す必要がない。
【００２７】
なお、この車載端末装置ＴＭは、典型的には、鉄道車両を特定して配置されるが、複数の鉄道車両において、適宜に使い回しても良いことは最初に説明した通りである。
【００２８】
次に、図３は、特定の○○駅について、新規に参照テーブルＴＢＬに新規登録すべきＭＡＣアドレスを特定するための候補テーブルＮｅｗを示している。本実施例では、参照テーブルＴＢＬに未登録であって、○○駅に到着する毎に、高レベルで認識されるＭＡＣアドレスの連続検出回数を特定して、連続検出回数が規定値を超えると参照テーブルＴＢＬの更新時に、そのＭＡＣアドレスを書加えるようにしている。
【００２９】
すなわち、本実施例では、参照テーブルＴＢＬの連続失敗回数に基づいて、参照テーブルＴＢＬのＭＡＣアドレスを消去する一方で、候補テーブルＮｅｗの連続検出回数に基づいて、参照テーブルＴＢＬのＭＡＣアドレスを補充しており、停車駅に設置されたネットワーク機器が移動又は廃棄されても、停車駅を永続的に把握することができる。
【００３０】
以上を踏まえて、車載端末装置ＴＭの専用アプリに内容を、図４〜図５に基づいて具体的に説明する。特に限定されないが、本実施例では、例えば、１秒毎に、図４（ａ）の処理が起動され、一連の処理が終われば、次に起動タイミングまで待機するよう構成されている。
【００３１】
なお、時速１０Ｋｍ程度の徐行運転において、１秒間に進む列車の移動距離は２．８ｍ程度であり、その後、完全停車する列車について、その到着駅を判定する上で、全く問題がない時間間隔であると解される。したがって、専用アプリを起動させる時間間隔τは、何ら１秒に限定されず、例えば、５秒とか１０秒に長期化しても良い。
【００３２】
何れにしても、実施例の専用アプリは、間欠的に起動されるが、専用アプリが起動されると、先ず、ＷｉＦｉ通信部を通して、その時に受信される全てのビーコンに関し、ＭＡＣアドレスと、その受信強度を取得して、不図示の一時テーブルＴＭＰに一時記憶する（ＳＴ１）。
【００３３】
次に、検出フラグＦＬＧの値を判定する（ＳＴ２）。検出フラグＦＬＧは、到着駅を検出したか否かを示しており、ステップＳＴ１３の処理で１にセットされ、その後、その到着駅を列車が出発すると、図５のステップＳＴ２３の処理で０にリセットされる。
【００３４】
そこで、以下では、検出フラグＦＬＧ＝０であって、未だ、到着駅が検出されていない状態について説明する。このような未検出状態では、次に、一時テーブルＴＭＰの記憶情報（ＭＡＣアドレス＋受信強度）を、受信強度順にソートして、所定の採用条件を満たす上位のＮ個の情報を、取得テーブルＧＥＴに保存する（ＳＴ３）。
【００３５】
取得テーブルＧＥＴに採用されるための採用条件には、（１）受信強度が最低基準値ＢＳを超えること、及び、（２）直前の到着駅を特定するＭＡＣアドレスでないこと、が含まれる。
【００３６】
但し、採用条件に、ＳＳＩＤ（Service Set Identifier）や、ＥＳＳＩＤ（Extended Service Set Identifier ）に基づく判定は含まれておらず、アクセスポイントＡＰａｉ，ＡＰｂｊが移動可能か否かは問題にしない。それは、例え、移動可能なアクセスポイントＡＰａｉ，ＡＰｂｊであっても、当該駅で繰り返し安定的に検出される場合には、停車駅を特定する上で好適に活用できるためである。
【００３７】
一方、本実施例において、採用条件（２）を設けるのは、列車が発車した直後は、対抗列車からの反射波などによって、直前の到着駅に設置されたネットワーク機器からのビーコンを受ける可能性があるためである。
【００３８】
また、採用条件（１）を設けるのは、列車が発車した後、地下駅と地下駅の間は、何れの駅に設置されたネットワーク機器からも、有意レベルのビーコン電波を受けないので、不要な判定動作を避けるためである。
【００３９】
したがって、ステップＳＴ３の処理によって、採用条件（１）（２）を満たす情報が得られない場合には、そのまま処理を終える。
【００４０】
一方、到着駅に近づいたような場合には、上記の採用条件（１）（２）を満たす情報が得られるので、受信強度でソートされた上位Ｎ個の情報が、ステップＳＴ３の処理によって、取得テーブルＧＥＴに保存されることになる。
【００４１】
図４（ｂ）に示す通り、取得テーブルＧＥＴには、受信強度が強いＮ個のＭＡＣアドレス（ＭｘＭＡＣ１〜ＭｘＭＡＣｎ）が、各々の受信強度と共に一時記憶される。
【００４２】
そこで、次に、Ｎ個のＭＡＣアドレスに基づいて到着駅を特定するべく、指示変数ｉを１に初期設定する（ＳＴ４）。また、参照テーブルＴＢＬの参照行を、先頭位置に設定して、ＭＡＣアドレス判定用の判定変数ＡＤｘに、指示変数ｉで特定されるｉ番目のＭＡＣアドレスＭｘＭＯＣｉをコピーする（ＳＴ５）。
【００４３】
先に説明した通り、参照テーブルＴＢＬの先頭位置から最終位置までには、全ての停車駅について、ＭＡＣアドレスその他の情報が、停車駅を特定して記憶されている（図２）。
【００４４】
そこで、次に、判定変数ＡＤｘに取得されたＭＡＣアドレスが、参照テーブルＴＢＬに登録されているＭＡＣアドレスと一致するか否かを、一個ずつ順番に判定する（ＳＴ６〜ＳＴ９）。
【００４５】
そして、最終位置まで判定しても一致するＭＡＣアドレスが検出されない場合には（ＳＴ９がＹ判定）、指示変数ｉをインクリメント（＋１）して（ＳＴ１０）、同様の処理を繰り返す。
【００４６】
具体的には、参照テーブルＴＢＬの参照行を、再度、先頭位置に設定して、インクリメントされた指示変数ｉで特定されるｉ番目のＭＡＣアドレス（ＭｘＭＯＣｉ）を、判定変数ＡＤｘにコピーする（ＳＴ５）。なお、指示変数ｉがｉ＝２の状態で、判定変数ＡＤｘにコピーされるＭＡＣアドレス（ＭｘＭＯＣ２）は、受信強度が最強であった第１候補ＭｘＭＯＣ１に続く、受信強度が少し劣る第２候補ＭｘＭＯＣ２ということになる（図４（ｂ）参照）。
【００４７】
このようにして、第１候補ＭｘＭＯＣ１から第Ｎ候補ＭｘＭＯＣｎまでについて、参照テーブルＴＢＬに登録されているＭＡＣアドレスと対比すると、何れ、一致するＭＡＣアドレスが検出される（ＳＴ７がＹ判定）。なお、このときの判定変数ＡＤｘは、一致判定されたＭＡＣアドレスを特定し、ＭＡＣアドレスは到着駅を特定している。
【００４８】
そこで、次に、一致判定されたＭＡＣアドレスの受信強度が、参照テーブルＴＢＬにＭＡＣアドレス毎に記憶されている到着閾値ＴＨ１を上回るか否かを判定する（ＳＴ１２）。そして、到着閾値ＴＨ１を超えない場合は、検出フラグＦＬＧ＝０の状態で、ステップＳＴ１６の判定処理に移行するので、何もしないで処理を終えることになる。
【００４９】
このような動作を採用するのは、列車が地下駅に近づきつつあるような場合には、該当駅のネットワーク機器からビーコン電波を受けるものの、その強度が弱いので、未だ、列車がその駅に到着していないと判定するためである。図２に示す通り、到着閾値ＴＨ１は、参照テーブルＴＢＬに、ＭＡＣアドレス毎に記憶されている。
【００５０】
なお、簡易的には、到着閾値ＴＨ１を、全てのＭＡＣアドレスに対して、共通の値（例えば−９０ｄＢ）としても良く、このような場合には、ステップＳＴ３で問題になる最低基準値ＢＳを、到着閾値ＴＨ１と同一値にすることで、ステップＳＴ１２やＳＴ１６の処理を省略することができる。
【００５１】
但し、実施例の場合には、最低基準値ＢＳとは異なる到着閾値ＴＨ１を設けているので、ステップＳＴ１２の判定で、ＭＡＣアドレスの受信強度が到着閾値ＴＨ１を超えない場合には、最終判定を１秒後の次の判定処理（ＳＴ１２）以降に委ねることになる（ＳＴ１６参照）。
【００５２】
そして、次回、又は、それ以降のステップＳＴ１２の判定において、ＭＡＣアドレスの受信強度が、到着閾値ＴＨ１を上回る場合には、到着駅を検出したと最終判定して、検出フラグＦＬＧを１にセットする（ＳＴ１３）。
【００５３】
次に、ＭＡＣアドレスで特定される到着駅を、車載端末装置ＴＭの機器ＩＤや時刻情報などの他の情報と共に暗号化して、適宜な携帯基地局を経由して、管理コンピュータＰＣに連絡する（ＳＴ１４）。
【００５４】
また、参照テーブルＴＢＬにおける、今回の到着駅についての未検出フラグ欄を全て１に初期設定する（ＳＴ１５）。これは、１秒後の次の処理、及びそれ以降の処理で、参照テーブルＴＢＬの登録情報が有効か否かを判定するためであり、この実施例では、到着駅を検出したこのタイミングで、全ての登録情報が無効であると初期設定している（ＳＴ１５）。
【００５５】
続いて、次回のタイマ割込み処理について説明する。先のタイマ割込み処理のステップＳＴ１３の処理で、検出フラグＦＬＧが１にセットされたので、次回のタイマ割込み処理では、一群のＭＡＣアドレスを取得して一時テーブルＴＭＰに保存した後（ＳＴ１）、ステップＳＴ２の判定を経て、ステップＳＴ１７の処理に移行して、駅到着後の処理を実行することになる。
【００５６】
具体的な処理内容は、図５に示す通りであり、新規に取得された一時テーブルＴＭＰのＭＡＣアドレスのうち、受信強度が最低基準値ＢＳを超えるＭＡＣアドレスについて、参照テーブルＴＢＬの到着駅についての未検出フラグを０に書換える（ＳＴ２０）。
【００５７】
これは、図４のステップＳＴ１５で未検出状態に初期設定されたことに対応する処理であり、到着駅で検出されたＭＡＣアドレスを特定する処理に他ならない。そして、ステップＳＴ２０の処理は、列車が発車するまでの間、１秒毎に繰り返し実行されるので、その停車駅に設置されているネットワーク機器から、有意レベルで受けるＭＡＣアドレスは全て把握されるはずである。
【００５８】
したがって、列車の停車中、１秒毎にいくら繰り返しても、登録済みのＭＡＣアドレスが検出されない場合は、そのネットワーク機器は、移動されたか廃棄された可能性が考えられる。
【００５９】
例えば、図２の参照テーブルでは、１１番目から４４番目までのＭＡＣアドレスが、○○駅の到着時に検出されたことを示している。一方、１番目から１０番目までのＭＡＣアドレスは検出されていないことを示しており、対応するネットワーク機器の撤去が示唆される。そこで、この点を踏まえた処理が、列車発車後に実行される（ＳＴ２６）。
【００６０】
ステップＳＴ２６の処理については、後述するとして、ステップＳＴ２０の処理が終われば、参照テーブルＴＢＬに未登録である有効データを検出するべくステップＳＴ２１の処理が実行される。
【００６１】
具体的には、一時テーブルＴＥＭＰに一時保存されているＭＡＣアドレスについて、受信強度が上位に属し、且つ、参照テーブルＴＢＬの到着駅のデータに関し、未登録の新規ＭＡＣアドレスを、その受信強度と共に、図５（ｂ）に示す作業テーブルＷＫに記憶する（ＳＴ２１）。
【００６２】
この処理も、列車の停車中、１秒毎に繰り返し実行されるので、同じデータが繰り返し検出されるが、作業テーブルＷＫは、最強の受信強度が上書きされる。なお、検出回数の大小に起因する処理を設ける必要はない。
【００６３】
次に、判定変数ＡＤｘで特定されるＭＡＣアドレスの受信強度が発車閾値ＴＨ２を下回ったか否かを判定する（ＳＴ２２）。先に説明した通り、判定変数ＡＤｘは、到着駅のＭＡＣアドレスを特定しており、このＭＡＣアドレスの受信強度が発車閾値ＴＨ２を下回ったことは、列車が発車したことを意味している。
【００６４】
そこで、検出フラグＦＬＧを０にリセットすると共に（ＳＴ２３）、到着駅から発車したことを、車載端末装置ＴＭの機器ＩＤなどの他の情報と共に暗号化して、適宜な携帯基地局を経由して、管理コンピュータＰＣに連絡する（ＳＴ２４）。
【００６５】
一般に、地下路線を走行中の列車内であっても、携帯電話によるデータ通信が可能になっており、ステップＳＴ２４の通信処理に失敗するおそれはない。なお、到着駅の到着は、既に、管理コンピュータＰＣに通知済みであるので（ＳＴ１４）、ステップＳＴ２４の通信処理を省略しても良く、逆に、ステップＳＴ２４の通信処理を残し、ステップＳＴ１４の処理を省略しても良い。
【００６６】
何れにしても、続いて、作業テーブルＷＫの情報に基づいて候補テーブルＮｅｗを更新する（ＳＴ２５）。具体的には、作業テーブルＷＫの全てのＭＡＣアドレス情報について、一つずつ、図３に示す候補テーブルＮｅｗの記憶内容と対比し、もし、同じＭＡＣアドレスが検出される場合には、そのＭＡＣアドレスについて検出フラグを１に設定する。
【００６７】
本実施例では、ステップＳＴ２５の処理開始時に、全ての検出フラグを０にリセットするよう構成されているので、作業テーブルＷＫの全てのＭＡＣアドレスについて、検出フラグの設定処理が終われば、検出フラグ欄の値によって、特定の○○駅について、今回の停車で、検出されたＭＡＣアドレスが全て特定されることになる。
【００６８】
そこで、検出フラグが０のままであって、候補テーブルＮｅｗに記載されているものの、今回の停車時には、検出されなかったＭＡＣアドレスについては、これを削除する。例えば、図３の候補テーブルＮｅｗにおいて、１５番目と２０番目のＭＡＣアドレスは、検出フラグ＝０であるので、今回停車時のステップＳＴ２５の処理で削除される。
【００６９】
一方、検出フラグ＝１の場合には、その値を連続検出回数に加算して、連続検出回数を更新する。例えば、１番目から１２番目までのＭＡＣアドレスは、これまで連続して１５回検出されているが、今回停車時のステップＳＴ２５の処理で、連続検出回数が１６に更新され、その他のＭＡＣアドレスについても、各々、その連続検出回数がインクリメント（＋１）更新される。
【００７０】
図３は、特定の○○駅についての候補テーブルＮｅｗであるが、このような候補テーブルは、全ての停車駅について設けられており、連続検出回数が規定値を超えるＭＡＣアドレスについては、参照テーブルＴＢＬの更新時に、新規のＭＡＣアドレスとして参照テーブルＴＢＬに登録される。
【００７１】
上記のような意義を有するステップＳＴ２５の処理が終われば、次に、参照テーブルＴＢＬに登録されているＭＡＣアドレスについて、今回停車時に検出に失敗したＭＡＣアドレスについて、連続失敗回数を更新する（ＳＴ２６）。
【００７２】
図２に示す通り、参照テーブルＴＢＬには、未検出フラグ欄が設けられている。そして、ステップＳＴ１６の処理において、到着駅を特定する全てのＭＡＣアドレスに関して、未検出フラグが１に初期設定された後、停車時に検出されたＭＡＣアドレスについては、未検出フラグが０に変更されている（ＳＴ２０）。
【００７３】
したがって、ステップＳＴ２６の処理では、未検出フラグを連続失敗回数に加算することで、連続失敗回数を更新している。例えば、図２の参照テーブルＴＢＬの１番〜１０番目、及び、４５番〜４６番目のＭＡＣアドレスは、今回の停車時に検出されなかったので（未検出フラグ＝１）、ステップＳＴ２６の処理で、連続失敗回数が１１や１にインクリメント（＋１）される。
【００７４】
一方、参照テーブルＴＢＬの１１番目から４４番目のＭＡＣアドレスは、今回の停車時に検出されているので（未検出フラグ＝０）、連続失敗回数が全て０に更新される。例えば、２１番目、３１番目、及び、３８番目のＭＡＣアドレスは、この列車が、前回この停車駅に停車した時には、未検出であったが、今回は検出されたので、連続失敗回数が０となる。
【００７５】
このように、参照テーブルＴＢＬの連続失敗回数は、その列車が各到着駅に到着する毎に、ステップＳＴ２６の処理によって、その停車駅に関して更新される。そして、その停車駅に何回到着しても検出されないＭＡＣアドレスについては、このＭＡＣアドレスに対応するネットワーク機器が撤去ないし廃棄されたとして、参照テーブルＴＢＬの更新処理時に、参照テーブルＴＢＬから削除される。
【００７６】
参照テーブルＴＢＬの更新タイミングは、特に限定されないが、車載端末装置ＴＭの電源投入時に、更新の必要性が判定され、更新必要時には、参照テーブルＴＢＬのＭＡＣアドレスを、候補テーブルＮｅｗのＭＡＣアドレスと入れ替えることで更新処理が完了する。
【００７７】
そして、この更新時に、候補テーブルＮｅｗに保存されている受信強度の計測値に基づいて、新規に登録されるＭＡＣアドレスに関して、到着閾値ＴＨ１と発車閾値ＴＨ２とが適宜に設定される。
【００７８】
なお、参照テーブルＴＢＬの更新の必要性は、各停車駅における有効なＭＡＣアドレスが枯渇したか否か、つまり、連続失敗回数が０であるＭＡＣアドレスが、例えば、全体の２／３を下回ったか否かで判定される。
【００７９】
特に限定されないが、この実施例では、上記のように更新された参照テーブルＴＢＬは、電源投入時の更新処理に対応して、管理コンピュータＰＣにも送信されるよう構成されている。したがって、管理コンピュータＰＣは、各車載端末装置ＴＭで機能している参照テーブルをリアルタイムに把握することができる。
【００８０】
なお、各車載端末装置ＴＭにおける、参照テーブルＴＢＬの更新処理を許可するのではなく、参照テーブルＴＢＬの更新を、管理コンピュータＰＣが一元管理するのも好適である。
【００８１】
この場合には、全ての車載端末装置ＴＭについて、例えば、その電源遮断時に、参照テーブルＴＢＬと、候補テーブルＮｅｗを、管理コンピュータＰＣに自動送信する構成を採る。そして、管理コンピュータＰＣが、ＭＡＣアドレスの枯渇状態を一元的に管理して、適宜に更新された参照テーブルＴＢＬを、車載端末装置ＴＭの電源投入時や電源遮断時などに、車載端末装置ＴＭにダウンロードさせる。
【００８２】
以上、本発明の実施例について詳細に説明したが、具体的な記載内容は、何ら本発明を限定するものではなく、適宜に変更可能である。
【００８３】
例えば、図４の実施例では、最初に検出された到着駅について、その正当性のチェックをしていないが、重複チェックをするのも好適である。図６は、このような実施例を例示しており、図４の実施例にステップＳＴ３０〜ＳＴ３５の処理を付加したものである。
【００８４】
以下、動作内容を説明すると、最初に停車駅ＨＴｘが検出されると（ＳＴ７がＹ判定）、そのＭＡＣアドレス（ＭｘＭＡＣｉ）と受信強度を、保存変数ＡＤにコピーし（ＳＴ３０）、停車駅ＨＴｘについての検出回数をカウントアップする（ＳＴ３１）。
【００８５】
そして、検出回数が規定回数（＝２）に達しない場合には（ＳＴ３２がＮ判定）、指示変数ｉを更新して（ＳＴ３３）、次のＭＡＣアドレス（ＭｘＭＡＣｉ＋１）について、同じ手順を経て到着駅を検索する（ＳＴ５〜ＳＴ７）。
【００８６】
そして、このような処理を繰り返していると、何れ、停車駅ＨＴｘについての検出回数が規定値（＝２）に達するので、その後は、保存変数ＡＤに保存されているＭＡＣアドレス（ＭｘＭＡＣｉ）の受信強度が、到着閾値ＴＨ１を上回ることを条件に、判定変数ＡＤｘに、保存変数ＡＤの値をコピーして、ステップＳＴ１３の処理に移行させる。
【００８７】
ところで、ここまでの説明では、専用アプリは、所定時間τ（例えば１秒、５秒、１０秒）毎に起動するよう説明したが、起動時間間隔τを、専用アプリ自身が適宜に変更するのも好適である。
【００８８】
例えば、次回の起動タイミングまでの消費時間を規定するＯＮタイム設定処理を、ＥＮＤ処理に先行して実行させることで、検出フラグＦＬＧ＝０である停車駅を検出までの処理は、例えば、１０秒毎に専用アプリを起動させる一方、停車駅を検出した後（ＦＬＧ＝１）は、例えば、１秒毎に専用アプリを起動させる構成を採ることもできる。
【００８９】
このような構成を採れば、停車駅から停車駅までの列車移動区間において、無駄な処理を、短時間に繰り返す無駄を排除できる。
【００９０】
以上、各種の変更例も含めて説明したが、例えば、（１）最低基準値ＢＳと到着閾値ＴＨ１と発車閾値ＴＨ２の全てを一致させること、（２）最低基準値ＢＳと到着閾値ＴＨ１とを一致させて、ステップＳＴ１２〜ＳＴ１６の処理を省略すること、（３）ステップＳＴ１４又はステップＳＴ２４の処理を省略すること、（４）開放型のインタネット回線の使用が必ずしも禁止されないこと、を含め、具体的な記載内容は、適宜に変更可能である。
【符号の説明】
【００９１】
Ｍｏｂ    移動体通信網
ＰＣ      本部コンピュータ（管理コンピュータ）
ＡＰａｉ  アクセスポイント
ＡＰｂｊ  アクセスポイント
ＴＢＬ    参照情報記憶部
ＴＭ      車載端末装置
ＳＴ１３  第１手段
ＳＴ２２  第２手段と、
ＳＴ１４  第３手段
ＳＴ２４  第３手段
【図１】
2018121488.tif 000003
【図２】
2018121488.tif 000004
【図３】
2018121488.tif 000005
【図４】
2018121488.tif 000006
【図５】
2018121488.tif 000007
【図６】
2018121488.tif 000008