(57)【要約】【課題】停留所での待ち人数に応じた車両手配を実施する運行管理システムであって、ユーザの利便性を確保しつつ、かつ、より精度良く待ち人数を特定可能な運行管理システムを提供する。【解決手段】運行管理システム１００は、ユーザによって携帯される無線タグ１と、バス停に設置されるバス停用装置２と、路線バスの運行を管理するセンタ３とを備える。無線タグ１は、固有の識別情報を含むタグ情報パケットを送信するように構成されており、バス停用装置２は、タグ情報パケットを受信する機能を備える。バス停用装置２は、無線タグ１から発せられるタグ情報パケットを受信することによって、路線バスの到着を待っているユーザの人数（つまり待ち人数）を特定する。そして、その特定した待ち人数が、所定の配車要求人数を超過している場合に、臨時バスの配車をセンタ３に要請する。【選択図】図１
2017174203.tif 000002
【特許請求の範囲】
【請求項１】
ユーザによって携帯されて、所定の周波数帯の電波を用いて、固有の識別情報を含むユーザ情報パケットを送信する発信器（１）と、
ユーザを運送するための運送車両が停留する地点である停留所に配置される停留所用装置（２）と、
前記運送車両の運行を管理する運行管理装置（３）と、を備える運行管理システムであって、
前記停留所用装置は、
前記発信器から送信される前記ユーザ情報パケットを受信する停留所側受信装置（２１）と、
前記停留所側受信装置が受信した前記ユーザ情報パケットに基づいて、前記停留所に存在するユーザの数である待ち人数を特定する待ち人数特定部（Ｆｓ４）と、を備え、
前記停留所用装置と前記運行管理装置の少なくとも何れか一方は、前記待ち人数特定部が特定している前記待ち人数に基づいて、前記停留所に前記運送車両を配車する必要があるか否かを判定する配車要否判定部（Ｆｓ５、Ｆｃ５）を備え、
前記運行管理装置は、さらに、
前記配車要否判定部によって前記停留所への配車が必要であると判定された場合に、前記運送車両を前記停留所に配車する処理を行う配車処理部（Ｆｃ４）を備えることを特徴とする運行管理システム。
【請求項２】
請求項１において、
前記停留所用装置は、
広域通信網を介して外部装置と通信を実施するための停留所側広域通信部（２２）と、
前記配車要否判定部としての停留所側配車要否判定部と、
前記停留所側配車要否判定部によって前記停留所への前記運送車両の配車が必要であると判定されている場合に、前記停留所側広域通信部を介して、前記運送車両の配車を要求する配車要求メッセージを前記運行管理装置へと送信する停留所側送信処理部（Ｆｓ１）と、を備え、
前記運行管理装置は、
広域通信網を介して外部装置と通信を実施するための管理側広域通信部（３１）と、
前記管理側広域通信部と協働して、前記停留所用装置から送信されてくる前記配車要求メッセージを受信する管理側受信処理部（Ｆｃ２）と、を備え、
前記配車処理部は、前記管理側受信処理部が前記配車要求メッセージを受信した場合に、当該配車要求メッセージの送信元である前記停留所用装置が設置されている前記停留所に前記運送車両を配車することを特徴とする運行管理システム。
【請求項３】
請求項２において、
前記配車要求メッセージには、前記待ち人数特定部によって特定された前記待ち人数が含まれており、
前記配車処理部は、前記配車要求メッセージに含まれている前記待ち人数に応じた数の乗客を収容可能な前記運送車両を前記停留所に配車することを特徴とする運行管理システム。
【請求項４】
請求項２又は３において、
前記運送車両に搭載される車両用装置（４）を備え、
前記車両用装置は、
広域通信網に接続し、外部装置と通信を実施する車両側広域通信部（４１）と、
衛星航法システムが備える航法衛星が送信する航法信号を受信することで前記車両用装置の現在位置を特定する現在位置特定部（４２）と、
前記車両側広域通信部を介して、少なくとも前記現在位置特定部が特定している前記車両用装置の現在位置を含む、前記運送車両の運行状況を示す通信パケットである状況報告パケットを前記運行管理装置に送信する車両側送信処理部（Ｆｖ１）と、を備え、
前記運行管理装置は、
前記管理側広域通信部が受信した前記状況報告パケットに基づいて前記運送車両の運行状況を管理する運行状況管理部（Ｆｃ３）を備えることを特徴とする運行管理システム。
【請求項５】
請求項４において、
前記運送車両として、予め設定された走行ルートを所定のスケジュールに則って定期的に走行する路線バスである定期バスと、臨時的に運行される臨時バスと、を備え、
前記定期バスで用いられる前記車両用装置は、
前記発信器から送信される前記ユーザ情報パケットを受信する車両側受信装置（４６）と、
前記車両側受信装置が受信した前記ユーザ情報パケットに基づいて、前記運送車両に乗車しているユーザの数である乗車人数を特定する乗車人数特定部（Ｆｖ５）と、を備え、
前記車両側送信処理部は、前記乗車人数特定部が特定している前記乗車人数を示す通信パケットである乗車人数パケットを前記運行管理装置に送信し、
前記管理側受信処理部は、前記管理側広域通信部と協働して前記車両用装置から送信される前記乗車人数パケットを受信し、
前記配車処理部は、
前記定期バスに予め設定されている最大乗車人数と、前記状況報告パケットに示されている現在の前記乗車人数に基づいて残席数を算出し、
前記配車要否判定部は、前記停留所における前記待ち人数と、当該停留所に向かっている前記定期バスの前記残席数とに基づいて、当該停留所に対して前記臨時バスを配車する必要があるか否かを判定することを特徴とする運行管理システム。
【請求項６】
請求項４又は５において、
前記停留所は路線バスが停留する地点であって、
前記運送車両として、所定の運行スケジュールに則って走行する路線バスである定期バスと、臨時的に運行される臨時バスと、を備え、
前記発信器には、前記ユーザが利用する路線である利用路線を示す利用路線情報が予め登録されてあって、
前記ユーザ情報パケットには前記利用路線情報が含まれており、
前記待ち人数特定部は、受信した前記ユーザ情報パケットに示されている前記利用路線情報に基づいて、前記路線毎の前記待ち人数を特定し、
前記配車要否判定部は、前記路線毎の待ち人数に基づいて、前記停留所への前記臨時バスの配車が必要であるか否かを判定することを特徴とする運行管理システム。
【請求項７】
請求項２又は３において、
前記停留所は、所定のイベントの参加者を運送するために臨時的に設定される臨時停留所であって、
前記停留所用装置は、
前記臨時停留所に配置されるものであって、
衛星航法システムが備える航法衛星が送信する航法信号を受信することで前記停留所用装置の現在位置を特定する停留所側位置特定部（２３）を備え、
前記停留所側送信処理部は、前記停留所側位置特定部が特定している位置情報と、前記待ち人数特定部が特定している待ち人数を含む前記配車要求メッセージを送信し、
前記配車処理部は、
前記配車要求メッセージに示される位置情報に基づいて前記臨時停留所として機能している地点を特定するとともに、前記配車要求メッセージに示される待ち人数に基づいて前記臨時停留所における待ち人数を特定し、当該特定した待ち人数に応じた数のバスを前記臨時停留所に配車することを特徴とする運行管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの需要に応じてバスを運行させる運行管理システムに関する。
【背景技術】
【０００２】
従来、ユーザの需要に応じてバスを運行させる交通サービス（いわゆるデマンド型交通サービス）が提案されている。例えば特許文献１には、デマンド型交通サービスを実現するシステム（以降、運行管理システム）として、バスの停留所に設置される停留所用装置と、各バスに搭載される通信装置（以降、バス側装置）と、バスの運行を制御する制御装置（以降、運行制御装置）とを備えるシステムが開示されている。
【０００３】
特許文献１に開示の運行システムにおける停留所用装置は、ユーザによって押下されるためのボタン、人感センサ、及びカメラの少なくとも何れか１つを用いて、バスの到着を待つ人物（つまりユーザ）の存在を検出する。例えば停留所用装置は、ボタンに対するユーザの押下操作や、人感センサの出力信号、カメラによる撮像画像の解析結果に基づいてユーザの存在を検出する。
【０００４】
そして、停留所用装置は、バスの到着を待つユーザが存在した場合には、その旨を運行制御装置に報告する。運行制御装置は、ユーザが存在している旨の報告を実施した停留所用装置の元へバスを向かわせる。つまり、ユーザが存在している旨の報告を実施した停留所用装置が設置されているバス停へバスを配車する。
【０００５】
なお、特許文献１ではより好ましい態様として、停留所用装置は、バスの到着を待つユーザが存在する場合には、操作ボタンが押下された回数や、人感センサの反応回数、カメラ画像の解析結果に基づいて、バスの到着を待っているユーザの人数（以降、待ち人数）を特定し、当該待ち人数についても運行制御装置に報告する態様も開示されている。そのような態様によれば、運行管理装置は、待ち人数に応じたバスの手配（つまり配車）を実施することができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１４−２０３１９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１において停留所用装置がユーザの存在を検出する手段としてボタンのみを備える場合、停留所用装置が待ち人数を認識するためには、ユーザは停留所に到着する度にボタンを押下する必要がある。そのため、仮に停留所に到着したユーザがボタンを押し忘れた場合には、運行管理システムとしては、当該ユーザがバスの到着を待っていることを認識できない。その結果、当該停留所へのバスの手配を実施できなかったり、待ち人数に対応したバスの手配を実施できなかったりして、ユーザの利便性を損なう恐れがある。
【０００８】
人感センサによってユーザの存在を検出する場合には、ユーザにボタンを押下させる手間は生じない。しかしながら、人感センサを用いてユーザの到着を検出する態様においては、特定している待ち人数に誤差を含みやすい。例えば、人感センサに対して複数の人物が同時に到着した場合には複数のユーザを１人として計上してしまう恐れがある。
【０００９】
また、人感センサにとっての死角となる位置（既に待機済みのユーザの背後等）に新たなユーザが並んだ場合には、その新たなユーザの到着を検出できない。さらに、既に待ち人数として計上済みの人物が動いたりした場合には、その人物の動きを新たなユーザの到着として誤検出してしまう恐れもある。
【００１０】
当然、停留所用装置が特定する待ち人数が実際の待ち人数と異なれば、運行制御装置は実際の待ち人数に応じたバスの手配が困難となり、ユーザの利便性を損なってしまう恐れがある。なお、カメラにも撮影できない領域（いわゆる死角）が生じうるため、カメラを用いて待ち人数を特定する場合にも、同様の課題が生じる。
【００１１】
本発明は、この事情に基づいて成されたものであり、その目的とするところは、停留所での待ち人数に応じた車両手配を実施する運行管理システムであって、ユーザの利便性を確保しつつ、かつ、より精度良く待ち人数を特定可能な運行管理システムを提供することにある。
【課題を解決するための手段】
【００１２】
その目的を達成するための本発明は、ユーザによって携帯されて、所定の周波数帯の電波を用いて、固有の識別情報を含むユーザ情報パケットを送信する発信器（１）と、ユーザを運送するための運送車両が停留する地点である停留所に配置される停留所用装置（２）と、運送車両の運行を管理する運行管理装置（３）と、を備える運行管理システムであって、停留所用装置は、発信器から送信されるユーザ情報パケットを受信する停留所側受信装置（２１）と、受信装置が受信したユーザ情報パケットに基づいて、停留所に存在するユーザの数である待ち人数を特定する待ち人数特定部（Ｆｓ４）と、を備え、停留所用装置と運行管理装置の少なくとも何れか一方は、待ち人数特定部が特定している待ち人数に基づいて、停留所に運送車両を配車する必要があるか否かを判定する配車要否判定部（Ｆｓ５、Ｆｃ５）を備え、運行管理装置はさらに、配車要否判定部によって停留所への配車が必要であると判定された場合に、運送車両を停留所に配車する処理を行う配車処理部（Ｆｃ４）を備えることを特徴とする。
【００１３】
以上の構成では、待ち人数特定部は、発信機から発せられるユーザ情報パケットを受信することによって、停留所で運送車両の到着を待っているユーザの人数（つまり待ち人数）を特定する。そして、配車要否判定部は、待ち人数に応じて運送車両の配車が必要か否かを判定し、運送車両の配車が必要であると判定した場合に、配車処理部が運送車両を配車する。
【００１４】
このような構成によれば、ユーザの待ち人数を特定するために、ユーザにボタンを押下させる必要はない。つまり、ユーザの利便性を損なうことなく、待ち人数を特定することができる。
【００１５】
また、ユーザ情報パケットには固有の識別情報が含まれている為、ユーザ情報パケットを複数受信した場合であっても、それぞれの送信元が同一の発信器であるか否かを識別できる。したがって、同一のユーザを重複して待ち人数として計上してしまう恐れを低減することができる。つまり、以上の構成によれば、待ち人数の特定手段として人感センサやカメラの画像解析を用いる場合よりも精度よく待ち人数を特定することができる。
【００１６】
したがって以上の構成によれば、ユーザの利便性を確保しつつ、かつ、より精度良く待ち人数を特定することができる。
【００１７】
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【図面の簡単な説明】
【００１８】
【図１】本実施形態に係る運行管理システム１００の概略的な構成の一例を示す図である。
【図２】無線タグ１の概略的な構成の一例を示すブロック図である。
【図３】バス停用装置２の概略的な構成の一例を示すブロック図である。
【図４】バス停側制御部２５の概略的な構成の一例を示すブロック図である。
【図５】センタ３の概略的な構成の一例を示すブロック図である。
【図６】センタ側制御部３３の概略的な構成の一例を示すブロック図である。
【図７】車両用装置４の概略的な構成の一例を示すブロック図である。
【図８】バス停側制御部２５が実施する配車要求関連処理を説明するためのフローチャートである。
【図９】センタ側制御部３３が実施する配車処理を説明するためのフローチャートである。
【図１０】変形例２に係る運行管理システム１００の作動を説明するための図である。
【図１１】変形例２に係る車両用装置４の概略的な構成の一例を示すブロック図である。
【図１２】変形例２に係るバス停側制御部２５が実施する配車要否判定処理を説明するためのフローチャートである。
【図１３】変形例４に係るセンタ側制御部３３の概略的な構成の一例を示すブロック図である。
【図１４】タグ情報パケットの概略的な構成の一例を示した図である。
【発明を実施するための形態】
【００１９】
［実施形態］
以下、本発明の実施形態について図を用いて説明する。本実施形態に係る運行管理システム１００は、路線バスの運行を管理するシステムである。
【００２０】
ここでの路線バスとは、周知の通り、予め設定されている走行ルートを巡回するバスである。走行ルート上には、ユーザが乗り降りするために路線バスが停留する地点（つまりバス停）が設定されている。何れの地点をバス停とするかは、路線バスサービスを提供する路線バス事業者によって決定される。以降では、予め設定された時刻表に従って各バス停を巡航する路線バスを定期バスとも称する。
【００２１】
運行管理システム１００は、図１に示すように、ユーザに携帯される無線タグ１と、路線バスの停留所に設置されるバス停用装置２と、路線バスの運行を管理するセンタ３と、各路線バスで用いられる車両用装置４と、を備える。
【００２２】
なお、図１にはバス停用装置２を１つしか図示していないが、バス停用装置２は複数のバス停のそれぞれに配置されており、システム全体としては複数存在する。複数のバス停用装置２のそれぞれには、他のバス停用装置２と重複しない識別番号（以降、バス停用装置ＩＤ）が設定されている。
【００２３】
車両用装置４も、複数の路線バスのそれぞれにおいて利用される。そのため、システム全体としては複数存在してもよい。ここでのユーザとは、路線バスの利用者に相当する。
【００２４】
ここでは説明簡略化のため、或る１つのバス停用装置２を対象として説明する。
【００２５】
＜運行管理システム１００の概要構成＞
バス停用装置２や、センタ３、車両用装置４は何れも広域通信網を介して相互に通信可能に構成されている。なお、ここでの広域通信網とは、電気通信事業者によって提供される公衆通信ネットワークを指す。広域通信網としては、例えば電話回線網やインターネット等などを採用することができる。
【００２６】
また、無線タグ１とバス停用装置２はそれぞれ、所定の通信規格に準拠した方式によって、広域通信網を介さない直接的な無線通信を実施可能に構成されている。バス停用装置２と無線タグ１とが通信を実施する際の通信方式等を定める通信規格は、IEEE 802.11やIEEE 802.15.1など、任意のものを採用することができる。
【００２７】
便宜上、バス停用装置２と無線タグ１とが互いに無線通信を実施するための通信規格のことを以降では近距離通信規格と称し、当該近距離通信規格に準拠した無線通信のことを近距離通信と称する。近距離通信によって通信装置同士が通信できる範囲は、電波の送信出力に応じた限定的な範囲、換言すれば広域通信網を介した通信に比べて狭い範囲となる。
【００２８】
無線タグ１には予め、当該無線タグ１を携帯する人物の属性情報や、他の無線タグ１とは重複しない固有の識別番号（以降、タグＩＤ）が登録されている。ここでの属性情報とは、ユーザの年齢などを示す情報である。属性情報についての詳細は別途後述する。
【００２９】
無線タグ１は、無線タグ１に登録されているタグＩＤと属性情報とを含む、近距離通信規格に準拠した通信パケット（以降、タグ情報パケット）を、逐次、又は、所定のトリガを検出した場合に送信するように構成されている。なお、無線タグ１の送信電力等は、タグ情報パケットの伝搬距離が最大でも数十ｍ程度となるように調整されていることが好ましい。タグ情報パケットが請求項に記載のユーザ情報パケットに相当する。
【００３０】
バス停用装置２は、タグ情報パケットを受信することによって、バス停でバスを待っているユーザが存在することを検出する。また、タグ情報パケットに含まれる識別情報に基づいて、バス停用装置２の周辺に存在する無線タグ１の数、換言すれば路線バスの到着を待っているユーザの人数（以降、待ち人数）を特定する。
【００３１】
そして、バス停用装置２は、特定している待ち人数が、所定の配車要求人数以上となっている場合に、センタ３に対して臨時バスの配車を要求する通信パケット（以降、配車要求メッセージ）をセンタ３に送信する。臨時バスは、臨時として運行される路線バスである。
【００３２】
上述の配車要求人数は、バス停用装置２が設けられているバス停（以降、自装置設置地点）への臨時バスの配車をセンタ３に要求するか否かを判定するための閾値として機能するパラメータである。配車要求人数の具体的な値は適宜設計されれば良い。例えば、配車要求人数は、定期バスで収容することが困難となる待ち人数とすればよい。なお、バス停毎に、バス到着時において路線バスに乗車している利用者の数は異なると想定される。そのため、配車要求人数は、バス停毎の利用者の動向を示す過去の実績に基づいて適宜決定されていることが好ましい。
【００３３】
センタ３は、或るバス停用装置２から配車要求メッセージを受信した場合、当該配車要求メッセージの送信元であるバス停用装置２が設けられているバス停に、臨時バスを向かわせる。これにより、ユーザは定期バスに乗れなかった場合であっても、臨時バスを利用して目的地に向かうことができる。以降では便宜上、配車要求メッセージの送信元に相当するバス停用装置２のことを要求元装置と記載し、要求元装置が設けられているバス停のことを配車先バス停と記載する。
【００３４】
なお、車両用装置４は、自分自身が搭載されている路線バスの運行状況を示す通信パケットとして、現在位置を含む通信パケット（以降、状況報告パケット）を逐次（例えば１秒毎に）センタ３に送信するように構成されている。センタ３は、車両用装置４から送信されてくる状況報告パケットを受信することで、各路線バスの運行状況を管理する。
【００３５】
＜無線タグ１の構成について＞
ここでは、無線タグ１の構成について述べる。無線タグ１は、鞄や靴等に取り付けられたり、衣服のポケット等に収容されたりすることで、ユーザによって携帯される。無線タグ１が請求項に記載の発信器に相当する。
【００３６】
無線タグ１は図２に示すように、近距離通信部１１、近接場通信部１２、メモリ１３、及びメイン処理部１４を備える。メイン処理部１４は、近距離通信部１１及びメモリ１３と相互通信可能に構成されており、近接場通信部１２は、メモリ１３と相互通信可能に接続されている。
【００３７】
近距離通信部１１は、近距離通信を行うための通信モジュールであり、より細かい要素として、近距離通信用アンテナと、送受信部とを備える。近距離通信用アンテナは、近距離通信に用いられる周波数帯（例えばRadio Frequency：ＲＦ帯）の電波を送受信するためのアンテナである。送受信部は、近距離通信用アンテナで受信した信号を復調してメイン処理部１４に提供するとともに、メイン処理部１４から入力されたデータを変調して、近距離通信用アンテナから送信する。
【００３８】
近接場通信部１２は、近接場通信（Near Field Communication：ＮＦＣ）を実施するための通信モジュールである。ここでの近接場通信とは、近距離通信よりも通信可能な距離が十分に小さい通信方式による通信を指す。例えば、近接場通信は、通信可能な距離が数ｃｍから数十ｃｍ程度となる通信を指す。
【００３９】
近接場通信部１２は、ISO/IEC 14443やISO/IEC 18092といった、周知の通信規格に準拠して、図示しないリーダライタと近接場通信を実施する。リーダライタは、近接場通信によって無線タグ１に登録されている情報を参照したり、データを書き換えたりするための装置である。無線タグ１のユーザは、リーダライタを用いて無線タグ１に属性情報を登録したり、登録内容を変更したり、登録内容を参照することができる。
【００４０】
メモリ１３は、書き換え可能な不揮発性の記憶媒体である。メモリ１３は、例えばフラッシュメモリを用いて実現すればよい。メモリ１３には、タグＩＤのほか、属性情報が格納される。ここでの属性情報とは、ユーザの属性を示す情報であって、具体的には、年齢や、性別、社会的属性、身体状態などを含む。社会的属性とは、小学生、中学生、高校生、会社員などといった、いわゆる社会的な立場を示す項目である。また、身体状態とは、ハンディキャップの有無や、妊娠中であるか否かなどといった、身体の状態に関わる情報を示す。
【００４１】
メイン処理部１４は、近距離通信部１１の動作を制御する。メイン処理部１４は、例えば、ＣＰＵやＩＣを用いて実現されればよい。メイン処理部１４は、近距離通信部１１と協働し、タグ情報パケットを送信する処理（以降、発信処理）を実施する。
【００４２】
なお、メイン処理部１４は、後述するバス停用装置２からの問い合わせ信号を受信したことをトリガとしてタグ情報パケットを送信するパッシブ送信モードと、所定の送信周期でタグ情報パケットを定期的に送信するアクティブ送信モードの２つの動作モードを備える。
【００４３】
パッシブ送信モードでは、問い合わせ信号を受信していない状態においてはスリープモードになっている。スリープモードは、バス停用装置２からの問い合わせ信号を受信したことを検出するために必要な機能については動作させる一方、その他の機能については動作を停止させることで消費電力を抑制している状態を指す。
【００４４】
メイン処理部１４をパッシブ送信モードとして動作させるか、アクティブ送信モードとして動作させるかは、ユーザによって選択可能に構成されていることが好ましい。本実施形態では一例としてメイン処理部１４は、パッシブ送信モードに設定されているものとする。もちろん、他の態様として、メイン処理部１４は、パッシブ送信モードとアクティブ送信モードの何れか一方でしか動作しないように構成されていても良い。
【００４５】
なお、パッシブ送信モードに設定されている場合、メイン処理部１４は問い合わせ信号を受信した時点を起算時点としてランダム時間待機してからタグ情報パケットを送信するものとする。バス停用装置２の周辺に複数の無線タグ１が存在する場合を想定し、複数の無線タグ１のそれぞれが応答するタイミングが重なってしまうリスクを低減するためである。待機時間は予め登録された乱数表を用いて決定されれば良い。
【００４６】
＜バス停用装置２の構成について＞
バス停用装置２は、バス停毎に、所定の近距離通信エリアを形成するように設置されている。ここでの近距離通信エリアとは、無線タグ１と近距離通信が可能なエリアを指す。バス停用装置２の近距離通信エリアは、ユーザが路線バスの到着を待つ待機場所として機能する領域を十分に含むように形成されていることが好ましい。なお、バス停用装置２は道路上に固定されていてもよいし、可搬型であってもよい。ここでの可搬型とは、動作時の位置は固定されており、持ち運んで設置位置を変更できるタイプを指す。バス停用装置２が請求項に記載の停留所用装置に相当する。
【００４７】
バス停用装置２は図３に示すように、近距離通信部２１、広域通信部２２、ＧＮＳＳ受信機２３、ディスプレイ２４、及びバス停側制御部２５を備える。近距離通信部２１、広域通信部２２、ＧＮＳＳ受信機２３、及びディスプレイ２４のそれぞれはバス停側制御部２５と相互通信可能に接続されている。
【００４８】
近距離通信部２１は、近距離通信を実施するための通信モジュールである。その具体的な構成等は、無線タグ１が備える近距離通信部１１と同様である。近距離通信部２１は、無線タグ１から送信されたタグ情報パケットを受信して、バス停側制御部２５に出力する。近距離通信部２１が請求項に記載の停留所側受信装置に相当する。
【００４９】
広域通信部２２は、広域通信網に接続し、センタ３などの外部装置と広域通信網を介した通信を実施するための通信モジュールである。広域通信部２２は、バス停側制御部２５から入力されたデータを変調して、センタ３に送信する。また、センタ３から送信されたデータを受信してバス停側制御部２５に提供する。なお、本実施形態では一例として広域通信部２２は広域通信網に無線接続する態様とするが、これに限らない。広域通信部２２は、広域通信網に有線接続する構成となっていても良い。広域通信部２２が請求項に記載の停留所側広域通信部に相当する。
【００５０】
ＧＮＳＳ受信機２３は、衛星航法システムであるＧＮＳＳ（Global Navigation Satellite System）が備える航法衛星が送信する航法信号を受信し、受信した航法信号に基づいて現在位置を逐次算出する。現在位置を示す位置情報は、例えば、緯度、経度、高度により表されればよい。ＧＮＳＳ受信機２３が算出した現在位置を示す位置情報はバス停側制御部２５に逐次提供される。ＧＮＳＳ受信機が請求項に記載の停留所側位置特定部に相当する。
【００５１】
ディスプレイ２４は、バス停側制御部２５から入力されたデータに対応する画像を表示する。ディスプレイ２４としては、例えば液晶ディスプレイなどといった、周知のディスプレイを採用することができる。
【００５２】
バス停側制御部２５は、バス停用装置２全体の作動を制御する。バス停側制御部２５は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えるコンピュータとして構成されている。ＲＯＭには、通常のコンピュータをバス停側制御部２５として機能させるためのプログラム（以降、バス停用プログラム）がインストールされている。
【００５３】
なお、上述のバス停用プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。例えばバス停用プログラムはフラッシュメモリに保存されていても良い。ＣＰＵがバス停用プログラムを実行することは、バス停用プログラムに対応する方法が実行されることに相当する。
【００５４】
また、ＲＯＭには、自分自身が配置されているバス停の名称や、位置、当該バス停が対応している路線を示すバス停情報が登録されている。或るバス停が対応している路線とは、そのバス停を通行する路線である。換言すれば、バス停が対応している路線とは、そのバス停でユーザが利用可能な路線である。なお、バス停毎に固有の識別番号（以降、バス停番号）が設定されている場合には、バス停番号もバス停情報に含まれる。
【００５５】
バス停側制御部２５は、ＣＰＵがバス停用プログラムを実行することによって、図４に示す種々の機能を提供する。すなわち、バス停側制御部２５は機能ブロックとして、送信処理部Ｆｓ１、受信処理部Ｆｓ２、タグ検出部Ｆｓ３、待ち人数特定部Ｆｓ４、配車要否判定部Ｆｓ５、及び表示処理部Ｆｓ６を備える。なお、上述した機能ブロックの一部又は全部は、一つ或いは複数のＩＣ等によりハードウェアとして実現されてもよい。
【００５６】
送信処理部Ｆｓ１は、広域通信部２２から送信するための通信パケットを生成し、広域通信部４１から送信させる。広域通信によって送受信される通信パケットには、宛先とする通信装置を示す宛先情報や、送信元を示す送信元情報が含まれている。宛先情報や送信元情報としては、例えばＩＰアドレスやＭＡＣアドレスなどを採用することができる。送信処理部Ｆｓ１が請求項に記載の停留所側送信処理部に相当する。
【００５７】
受信処理部Ｆｓ２は、広域通信部２２が受信したデータを取得する。受信処理部Ｆｓ２が受信したデータは、ＲＡＭに保存されれば良い。受信処理部Ｆｓ２が請求項に記載の停留所側受信処理部に相当する。
【００５８】
タグ検出部Ｆｓ３は、近距離通信部２１と協働し、バス停用装置２周辺に存在する無線タグ１を検出する。ここでのバス停用装置２の周辺とは、バス停用装置２にとって近距離通信可能な範囲である。
【００５９】
タグ検出部Ｆｓ３による無線タグ１の検出方法は適宜設計されれば良い。本実施形態では一例として、タグ検出部Ｆｓ３は、所定のスキャン周期で近距離通信部２１に問い合わせ信号を送信させることによってバス停用装置２周辺に存在する無線タグ１を検出するものとする。
【００６０】
具体的には、タグ検出部Ｆｓ３は近距離通信部２１に問い合わせ信号を送信させることによって、バス停用装置２周辺に存在する無線タグ１にタグ情報パケットを送信させる。そして、問い合わせ信号を受信してから所定の応答受付時間経過するまでに受信したタグ情報パケットに示されるタグＩＤと属性情報とを対応付けてＲＡＭに保存していく。
【００６１】
１回の問い合わせ信号の送信の結果として取得できたタグＩＤの数が、自装置設置地点で路線バスの到着を待っているユーザの数を示唆している。便宜上、１回の問い合わせ信号の送信に対して取得できたタグＩＤ及びそのタグＩＤに対応する属性情報を含むデータのことを、スキャン結果とも称する。また、バス停用装置２周辺に存在する無線タグ１を検出するための一連の処理をスキャン処理とも記載する。
【００６２】
上述のスキャン周期は、問い合わせ信号を送信する間隔に相当するパラメータであって、その具体的な値は適宜設計されれば良い。スキャン周期は、例えば数秒から１０秒程度に設定されれば良い。ここではスキャン周期は１秒に設定されているものとする。応答受付時間は、問い合わせ信号に対する無線タグ１からの応答を受け付ける時間の上限を定めるパラメータである。応答受付時間は、無線タグ１が取りうる待機時間の最大値に応じて低適宜決定されていればよい。
【００６３】
待ち人数特定部Ｆｓ４は、ＲＡＭに登録されているスキャン結果に基づいて、自装置設置地点で路線バスの到着を待っているユーザの数（すなわち待ち人数）を特定する。具体的には、待ち人数特定部Ｆｓ４は、問い合わせ信号に送信に伴って取得できたタグＩＤの数を待ち人数として採用する。
【００６４】
なお、本実施形態では、１回のスキャン処理の結果をそのまま待ち人数として採用する態様とするがこれに限らない。直近Ｎ回のスキャン処理の結果の平均値や中央値を待ち人数として採用してもよい。Ｎは２以上の整数であって例えば５や１０などとすれば良い。そのような態様によれば、パケット衝突などに由来する無線タグ１の検出漏れを抑制することができる。当然、無線タグ１の検出漏れを抑制することは路線バスの到着を
配車要否判定部Ｆｓ５は、待ち人数特定部Ｆｓ４が特定している待ち人数と、バス停用装置２に予め設定されている配車要求人数に基づいて、臨時バスを配車するようにセンタ３に要求する必要があるか否かを判定する。具体的には、待ち人数特定部Ｆｓ４によって特定されている待ち人数が、所定の配車要求人数以上となっている場合には、臨時バスの配車要求が必要であると判定し、送信処理部Ｆｓ１に配車要求メッセージを送信させる。
【００６５】
配車要求メッセージには、自分自身に割り当てられているバス停用装置ＩＤが含まれていればよい。また、本実施形態ではより好ましい態様として、配車要求メッセージには、待ち人数特定部Ｆｓ４が特定した現在の待ち人数が含まれているものとする。つまり、配車要否判定部Ｆｓ５は、バス停用装置ＩＤと待ち人数を含む配車要求メッセージをセンタ３に送信する。
【００６６】
なお、配車要求メッセージに含まれるバス停用装置ＩＤは、センタ３が、要求元装置がどのバス停に設置されているバス停用装置２であるかを特定するために用いられる。また、待ち人数の情報は、バス停で待っているユーザの数に応じた収容人数を有する車両を臨時バスとして手配するために用いられる。配車要否判定部Ｆｓ５が請求項に記載の停留所側配車要否判定部に相当する。
【００６７】
表示処理部Ｆｓ６は、ディスプレイ２４の表示画面を制御する。例えば表示処理部Ｆｓ６は次の定期バスの到着予定時刻等をディスプレイ２４に表示させる。定期バスの到着予定時刻は、センタ３から配信されれば良い。
【００６８】
＜センタ３の構成について＞
センタ３は、路線バス事業者が路線バスとして保有する複数の車両の運行状況等を管理するための設備である。複数の車両は、車両毎に割り当てられた車両ＩＤによって管理されればよい。センタ３が請求項に記載の運行管理装置に相当する。
【００６９】
センタ３は、図５に示すように、広域通信部３１、運行管理データベース（以降、運行管理ＤＢ）３２、及びセンタ側制御部３３を備える。広域通信部３１及び運行管理ＤＢ３２はそれぞれセンタ側制御部３３と相互通信可能に接続されている。
【００７０】
広域通信部３１は、広域通信網に接続し、外部装置（例えばバス停用装置２や車両用装置４）と通信するための通信モジュールである。広域通信部３１は、センタ側制御部３３から入力されたデータを変調して広域通信網に出力する。また、広域通信網を介して届けられたデータを受信してセンタ側制御部３３に提供する。なお、本実施形態では一例として広域通信部３１は広域通信網に有線接続する態様とするが、これに限らない。広域通信部３１は、広域通信網に無線接続する構成となっていても良い。広域通信部３１が請求項に記載の管理側広域通信部に相当する。
【００７１】
運行管理ＤＢ３２は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。運行管理ＤＢ３２は、センタ側制御部３３によるデータの書き込み、読出、削除等が実施可能に構成されている。運行管理ＤＢ３２には、路線バスとして用いる車両毎の運行スケジュールを示すデータ（以降、運行予定情報）が登録されている。
【００７２】
或る車両の運行スケジュールとは、当該車両を定期バスとして稼働させる時間帯（以降、稼働時間帯）や、稼働時間帯における当該路線バスが走行すべき経路（以降、走行ルート）、ドライバの休憩に供される時間帯（以降、休憩時間帯）等を示す。或る路線バスを定期バスとして用いるか、臨時バスとして用いるかは、日毎または時間帯毎に、路線バス事業者によって決定されれば良い。臨時バスとして用いる車両は、所定の車両基地に停留されていれば良い。
【００７３】
また、運行管理ＤＢ３２には、各車両の実際の運行状況を示すデータが登録される。運行状況とは、例えば現在位置や、所定のチェックポイントに対して予め設定されている目標通過時刻に対する遅延時間等である。チェックポイントとは、目標通過時刻が設定されている地点であって、例えばバス停などである。
【００７４】
さらに、運行管理ＤＢ３２には、路線バスとして用いる車両毎の車両情報と、当該車両に搭載されている車両用装置４の車両用装置ＩＤが、車両ＩＤと対応付けられて保存されている。車両情報には、乗車可能な最大人数（以降、定員）や、型番、整備状況などが含まれる。定員が請求項に記載の最大乗車人数に相当する。
【００７５】
センタ側制御部３３は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えるコンピュータとして構成されている。ＲＯＭには、通常のコンピュータをセンタ側制御部３３として機能させるためのプログラム（以降、運行管理プログラム）がインストールされている。
【００７６】
なお、上述の運行管理プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。例えば運行管理プログラムはフラッシュメモリに保存されていても良い。ＣＰＵが運行管理プログラムを実行することは、運行管理プログラムに対応する方法が実行されることに相当する。
【００７７】
センタ側制御部３３は、ＣＰＵが運行管理プログラムを実行することによって、図６に示す種々の機能を提供する。すなわち、センタ側制御部３３は機能ブロックとして、送信処理部Ｆｃ１、受信処理部Ｆｃ２、運行状況管理部Ｆｃ３、及び配車指示部Ｆｃ４を備える。なお、上述した機能ブロックの一部又は全部は、一つ或いは複数のＩＣ等によりハードウェアとして実現されてもよい。
【００７８】
送信処理部Ｆｃ１は、広域通信部３１から送信するための通信パケットを生成し、広域通信部４１から送信させる。送信処理部Ｆｃ１が請求項に記載の管理側送信処理部に相当する。受信処理部Ｆｃ２は、広域通信部３１が受信したデータを取得する。例えば受信処理部Ｆｃ２は、路線バスとして稼働している各車両から送信される状況報告パケットを取得して保存する。受信処理部Ｆｃ２が請求項に記載の管理側受信処理部に相当する。
【００７９】
運行状況管理部Ｆｃ３は、車両用装置４から送信されてくる状況報告パケットを用いて車両毎の現在の運行状況を更新する。運行状況管理部Ｆｃ３は、送信処理部Ｆｃ１と協働し、バス停用装置２に対して定期バスの到着予定時刻等を示す運行状況情報を配信する。
【００８０】
配車指示部Ｆｃ４は、配車要求メッセージを受信したことに基づいて、臨時バスの手配を行う。具体的には、要求元装置が設けられているバス停に向けて臨時バスを向かわせる。ここでの臨時バスの手配（換言すれば配車）とは、臨時バスを所定の地点に差し向けることである。配車指示部Ｆｃ４が請求項に記載の配車処理部に相当する。
【００８１】
また、配車指示部Ｆｃ４は、送信処理部Ｆｃ１と協働して、臨時バスを手配した場合には、要求元装置に向けて臨時バスを配車したことを示す通信パケット（以降、手配完了メッセージ）を送信する。手配完了メッセージには到着予定時間などが含まれていることが好ましい。手配完了メッセージを受信した要求元装置の表示処理部Ｆｓ６は、定期バスの到着予定時刻に加えて、手配完了メッセージに示されている臨時バスの到着予定時刻もディスプレイ２４に表示する。
【００８２】
＜車両用装置４の構成について＞
各車両に搭載される車両用装置４は、図７に示すように、広域通信部４１、ロケータ４２、ディスプレイ４３、スピーカ４４、及び車両側制御部４５を備える。広域通信部４１、ロケータ４２、ディスプレイ４３、及びスピーカ４４のそれぞれは、車両側制御部４５と相互通信可能に接続されている。
【００８３】
広域通信部４１は、広域通信網に無線接続するための通信モジュールである。広域通信部４１は、車両側制御部４５から入力されたデータを変調して所定の宛先とする通信装置（例えばセンタ３）に送信する。また、他の通信装置から送信されてきたデータを受信して車両側制御部４５に提供する。広域通信部４１が請求項に記載の車両側広域通信部に相当する。
【００８４】
ロケータ４２は、道路地図上において、自車両が現在走行している地点を特定する装置である。ロケータ４２は、より細かい構成要素として、ＧＮＳＳ受信機及び地図記憶部を備える。
【００８５】
ＧＮＳＳ受信機は、前述のＧＮＳＳ受信機２３と同様の機能を提供する装置であって、航法衛星から送信される航法信号に基づいて、自車両の現在位置を逐次算出する。ここでの自車両とは、車両用装置４にとって自分自身が搭載されている車両のことである。
【００８６】
地図記憶部は、道路の接続関係や、道路の形状（換言すれば道路構造）を示す道路地図データを記憶している。地図記憶部は、ハードディスクドライブ等の不揮発性の記憶媒体を用いて実現されればよい。
【００８７】
ロケータ４２は、ＧＮＳＳ受信機が検出している現在位置に基づいて、道路地図上における自車両の位置を特定する。道路地図上における車両位置を特定することを、以降ではマッピングとも記載する。車両位置のマッピングは、ナビゲーション装置で慣用されている既知のマップマッチング技術を援用して実施すれば良い。マップマッチング技術は、複数時点における車両の進行方向や走行速度から車両の走行軌跡を求め、この車両の走行軌跡と地図情報から得た道路形状とを比較して車両の現在位置を求める技術である。ロケータ４２は、現在位置を示す位置情報を車両側制御部４５に逐次提供する。ロケータ４２が請求項に記載の現在位置特定部に相当する。
【００８８】
ディスプレイ４３は、車両側制御部４５から入力されるデータに対応する画像を表示する。スピーカ４４は、車両側制御部４５から入力されたデータに対応する音声メッセージや音を出力する。
【００８９】
車両側制御部４５は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えるコンピュータとして構成されている。ＲＯＭには、通常のコンピュータを車両側制御部４５として機能させるためのプログラム（以降、車両用プログラム）がインストールされている。
【００９０】
なお、上述の車両用プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。例えば車両用プログラムはフラッシュメモリに保存されていても良い。ＣＰＵが車両用プログラムを実行することは、車両用プログラムに対応する方法が実行されることに相当する。
【００９１】
車両側制御部４５は、ＣＰＵが車両用プログラムを実行することによって実現される機能ブロックとして、送信処理部Ｆｖ１、受信処理部Ｆｖ２、及び案内処理部Ｆｖ３を備える。なお、上述した機能ブロックの一部又は全部は、一つ或いは複数のＩＣ等によりハードウェア的に実現されてもよい。
【００９２】
送信処理部Ｆｖ１は、広域通信部４１から送信するための通信パケットを生成し、広域通信部４１から送信させる。例えば送信処理部Ｆｖ１は、ロケータ４２から提供される位置情報に基づいて、状況報告パケットを生成してセンタ３に送信する。送信処理部Ｆｖ１が請求項に記載の車両側送信処理部に相当する。受信処理部Ｆｖ２は、広域通信部４１が受信したデータを取得する。
【００９３】
案内処理部Ｆｖ３は、自車両が走行ルートに沿って走行するようにドライバの運転操作を支援する走行案内処理を実施する。例えば車両側制御部４５は走行案内処理として、ディスプレイ４３に走行ルートを示す地図画像を表示するとともに、スピーカ４４から右左折等の運転操作を案内する音声を出力させる。所定の走行ルートに沿ったドライバの運転操作を支援する方法は、ナビゲーション技術の分野で周知の方法を適用することができる。
【００９４】
＜配車要求関連処理＞
次に、バス停側制御部２５が実施する配車要求関連処理について、図８に示すフローチャートを用いて説明する。配車要求関連処理は、センタ３に対して臨時バスの配車を要求するための処理である。図８に示すフローチャートは、所定のスキャン周期で実行されれば良い。
【００９５】
まずステップＳ１０１では、タグ検出部Ｆｓ３がスキャン処理を実施してステップＳ１０２に移る。ステップＳ１０２では待ち人数特定部Ｆｓ４が、ステップＳ１０１でのスキャン処理の結果に基づいて、現在の待ち人数を特定してステップＳ１０３に移る。ステップＳ１０３では配車要否判定部Ｆｓ５が、バス停で待っている全てのユーザを定期バスに乗車させることができるか否か（換言ずれば定期バスで対応できるか否か）を判定する。具体的には、配車要否判定部Ｆｓ５は、ステップＳ１０２で特定した待ち人数が配車要求人数以上であるか否かを判定する。
【００９６】
待ち人数が配車要求人数未満である場合には、ステップＳ１０３が肯定判定されて本フローを終了する。待ち人数が配車要求人数未満であるということは、バス停で待機中の全てのユーザを定期バスで収容できる可能性が高いためである。
【００９７】
一方、待ち人数が配車要求人数以上である場合には、ステップＳ１０３が否定判定されて、ステップＳ１０４に移る。ステップＳ１０４では配車要否判定部Ｆｓ５が送信処理部と協働して、配車要求メッセージをセンタ３に送信してステップＳ１０５に移る。
【００９８】
ステップＳ１０５では受信処理部Ｆｓ２が、センタ３からの手配完了メッセージを受信したか否かを判定する。手配完了メッセージを受信した場合にはステップＳ１０５が肯定判定されてステップＳ１０６に移る。一方、手配完了メッセージをまだ受信していない場合にはステップＳ１０５が否定判定されてステップＳ１０５の判定処理を所定の時間間隔で繰り返す。
【００９９】
ステップＳ１０６では表示処理部Ｆｓ６が、受信した手配完了メッセージに示されている到着予定時刻をディスプレイ２４に表示して本フローを終了する。
【０１００】
＜配車処理＞
次に、センタ側制御部３３が実施する配車処理について、図９に示すフローチャートを用いて説明する。配車処理は、配車要求メッセージの受信をトリガとして、要求元装置が設置されているバス停へ臨時バスを配車する処理である。図９に示すフローチャートは、受信処理部Ｆｃ２が配車要求メッセージを取得した場合に開始されれば良い。
【０１０１】
まずステップＳ２０１では配車指示部Ｆｃ４が、受信した配車要求メッセージに含まれている待ち人数を抽出してステップＳ２０２に移る。ステップＳ２０２では、待ち人数に応じた車両を臨時バスとして選定してステップＳ２０３に移る。
【０１０２】
待ち人数に応じた車両とは、待ち人数に応じた定員を有する車両である。なお、待ち人数の一部は、定期バスに収容されることが期待できる。そのため、定員が待ち人数よりも所定数少ない車両も臨時バスとして採用することができる。また、臨時バスとして手配する車両は、配車先バス停からできるだけ近い場所に存在している車両であることが好ましい。定期バスに乗車できなかったユーザの待ち時間を抑制するためである。
【０１０３】
また、バス停で待っているユーザの人数によっては、１台の車両ではそれらの全てのユーザを収容しきれない場合も想定される。そのように１台の車両では収容しきれないほどの数のユーザが待っている場合には、その待ち人数に応じた複数の車両を臨時バスとして向かわせても良い。
【０１０４】
ステップＳ２０３では、ステップＳ２０２で選択した車両（以降、選定車両）に対して、配車先バス停に向かうように指示する。例えば、センタ側制御部３３はステップＳ２０２での処理結果を、ドライバへの出動指示を担当する人物（以降、オペレータ）に提示し、オペレータがその提示内容に基づいて選定車両のドライバに向けて配車先バス停に向かうように、無線機等によって指示する。
【０１０５】
また、配車指示部Ｆｃ４は、ステップＳ２０２で選択した車両で用いられている車両用装置４に向けて、配車先バス停に向かうように指示する通信パケット（以降、出動指示メッセージ）を送信することで、臨時バスの配車を実現してもよい。その場合、車両側制御部４５は、出動指示メッセージを受信した場合には、ディスプレイ４３に配車先バス停に向かう必要がある旨の画像を表示させたり、同様の旨の音声メッセージをスピーカ４４から出力させたりするように構成されているものとする。
【０１０６】
また、そのような他の態様における車両用装置４は、選定車両のドライバから、出動指示を了解した旨の操作が所定の入力装置に入力された場合に、ドライバが出動指示を了解したことを示す応答信号をセンタ３に返送するものとする。選定車両からの応答信号を受信することによってセンタ３は臨時バスの手配が完了したと判定する。なお、ここで導入される入力装置は、選定車両のドライバが、センタ３からの出動指示を了解したことを入力できればよく、その具体的なデバイスは何でもよい。例えば、物理的に実現されたボタンであってもよいし、タッチパネルであってもよい。
【０１０７】
＜実施形態のまとめ＞
以上の構成では、バス停用装置２は無線タグ１から発せられるタグ情報パケットを受信することで、自装置設置地点で路線バスの到着を待っているユーザの人数を特定する。そして、待ち人数が、バス停毎に予め設定されている配車要求人数以上となっている場合に、待ち人数を含む配車要求メッセージをセンタ３に送信する。センタ３は、配車要求メッセージに含まれている待ち人数に応じた数の乗客を収容可能な車両を臨時バスとして採用して、要求元装置が設けられているバス停に向かわせる。
【０１０８】
したがって以上の構成によれば、１回の定期バスに乗車しきれないほど多くのユーザがバス停に滞留した場合であっても、速やかに臨時バスを手配することが出来る。その結果、ユーザのバス停における待ち時間を抑制することができる。また、センタ３は待ち人数に応じた車両手配を実施するため、過剰な臨時バスの手配を実施してしまう恐れや、臨時バスの収容能力不足に由来してユーザの利便性を損なってしまう恐れを低減することができる。
【０１０９】
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本発明の技術的範囲に含まれる。また、実施形態や、種々の変形例は、矛盾が生じない範囲において他の変形例や実施形態と組み合わせて実施することができる。さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。
【０１１０】
なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。
【０１１１】
［変形例１］
上述した実施形態では、無線タグ１がパッシブ送信モードで動作することを想定していたため、タグ検出部Ｆｓ３は、問い合わせ信号を送信することでバス停用装置２周辺に存在する無線タグ１を検出する態様を例示したが、これに限らない。
【０１１２】
他の態様として、無線タグ１をアクティブ送信モードで動作させる場合には、タグ検出部Ｆｓ３は問い合わせ信号を送信する必要はない。仮にバス停用装置２周辺に存在する無線タグ１が存在する場合には、その無線タグ１から定期送信されるタグ情報パケットを受信できるためである。そのような態様においては、受信したタグ情報パケットに示されるデータを順次ＲＡＭに時系列順に格納していけばよい。
【０１１３】
そして、待ち人数特定部Ｆｓ４は、現時点から所定時間（例えば１秒）以内に受信できているタグ情報パケットに基づいて、待ち人数を特定すれば良い。具体的には、現時点から所定時間以内に取得したタグＩＤの数を待ち人数として採用する。もちろん、重複して取得しているタグＩＤについては１人としてカウントする。つまり、同一のタグＩＤを含むタグ情報パケットについては、それを所定時間内に何回受信しても１人としてカウントする。
【０１１４】
このような態様によっても、バス停用装置２はタグ情報パケットの送受信によって自装置が設定されているバス停で待っているユーザの人数を特定することができる。
【０１１５】
［変形例２］
上述した実施形態において配車要否判定部Ｆｓ５は、予め設定されている配車要求人数を用いて配車要求メッセージを送信するか否かを判定する態様を例示した。換言すれば、臨時バスの配車が必要であるか否かを、予め設定されている配車要求人数を用いて判定する態様を例示したが、これに限らない。
【０１１６】
例えば、配車要否判定部Ｆｓ５は、配車要求人数に代わって、自装置設置地点に向かっている定期バスの空いている席の数（つまり残席数）に基づいて、臨時バスの配車が必要か否かを判定してもよい。以下、配車要否判定部Ｆｓ５が、自装置設置地点に向かっている定期バスの残席数に基づいて臨時バスが必要か否かを判定するための運行管理システム１００の１つの態様について例示する。
【０１１７】
図１０は、変形例２における運行管理システム１００の作動を概略的に表した図である。図１０に示すように、変形例２における運行管理システム１００は次のように作動する。定期バスに搭載されている車両用装置４は、自車両の乗員人数をセンタ３に報告し、センタ３は定期バスの定員から、報告されてきた乗車人数を減算することで残席数を算出する。そして、その算出した残席数を定期バスが通行する予定のバス停に設けられているバス停用装置２に配信する。
【０１１８】
バス停用装置２は、センタ３から配信されてくる定期バスの残席数と、自装置設置地点での待ち人数を比較することで、臨時バスの手配が必要であるか否かを判定する。具体的には、自装置設定地点での待ち人数が、自装置設置地点に向かっている定期バスの残席数を超過している場合に、臨時バスが必要であると判定し、配車要求メッセージを送信する。
【０１１９】
上述した作動を提供するために、変形例２における車両用装置４は、実施形態で述べた種々の部材に加えて図１１に示すように近距離通信部４６を備える。近距離通信部４６は、近距離通信を実施するための通信モジュールである。その具体的な構成等は、無線タグ１が備える近距離通信部１１と同様である。近距離通信部４６は、無線タグ１から送信されたタグ情報パケットを受信して、車両側制御部４５に出力する。近距離通信部４６が請求項に記載の車両側受信装置に相当する。
【０１２０】
また、変形例２における車両側制御部４５は、前述の種々の機能ブロックに加えて、タグ検出部Ｆｖ４及び搭乗者情報管理部Ｆｖ５を備える。タグ検出部Ｆｖ４及び搭乗者情報管理部Ｆｖ５のそれぞれは、ＣＰＵが車両用プログラムを実行することで実現されても良いし、ＩＣ等のハードウェア部材を用いて実現されても良い。
【０１２１】
タグ検出部Ｆｖ４は、近距離通信部４６と協働し、自車両の車室内に存在する無線タグ１を検出する。その検出原理は、バス停用装置２のタグ検出部Ｆｓ３と同様の方法を適用する事ができる。つまり、タグ検出部Ｆｖ４がスキャン処理を実行することで、車室内に存在する無線タグ１を検出する。取得したタグ情報パケットは図示しないＲＡＭに時系列順に並べて保存されればよい。タグ検出部Ｆｖ４が取得したタグ情報パケットに示されるデータは、自車両に乗車しているユーザについてのデータに相当する。
【０１２２】
搭乗者情報管理部Ｆｖ５は、タグ検出部Ｆｖ４のスキャン結果に基づいて、自車両に搭乗しているユーザの数を特定する。具体的には、問い合わせ信号に送信に伴って取得できたタグＩＤの数を自車両に搭乗しているユーザの数（つまり乗車人数）として採用する。搭乗者情報管理部Ｆｖ５が請求項に記載の乗車人数特定部に相当する。
【０１２３】
搭乗者情報管理部Ｆｖ５が特定した乗車人数は、送信処理部Ｆｖ１に提供されて、センタ３へと送信される。便宜上、センタ３を宛先とする、乗車人数を示す通信パケットを乗車人数パケットと称する。
【０１２４】
なお、乗車人数は、状況報告パケットに収容されてセンタ３に報告される態様としてもよい。換言すれば、現在位置と乗車人数は１つの通信パケットに収容されてセンタ３に送信されてもよい。現在位置も乗車人数も、自車両の運行状況を示す情報に該当する。
【０１２５】
変形例２におけるセンタ３は、車両用装置４から逐次報告されてくる乗車人数と、その車両用装置４が用いられている車両（以降、報告元車両）の定員とから、報告元車両の残席数を算出する。そして、報告元車両がこれから通るバス停のバス停用装置２に向けて残席数を示す通信パケット（以降、残席数パケット）を送信する。なお、バス停用装置２にとっては、センタ３から配信されてくる残席数パケットは、自装置設置地点に向かっている定期バスの残席数を示す通信パケットである。
【０１２６】
バス停用装置２は、センタ３からの残席数パケットを受信すると、当該残席数パケットに示されている残席数に基づいて、臨時バスの配車が必要か否かを判定する処理（以降、配車要否判定処理）を実施する。この配車要否判定処理については、図１２に示すフローチャートを用いて説明する。図１２に示すフローチャートは、広域通信部４１が残席数パケットを受信した場合に開始されればよい。
【０１２７】
まず、ステップＳ３０１では配車要否判定部Ｆｓ５が、受信した残席数パケットのペイロード領域を参照し、自装置設置地点に向かっている定期バスの残席数を取得してステップＳ３０２に移る。ステップＳ３０２では待ち人数特定部Ｆｓ４が、タグ検出部Ｆｓ３と協働して待ち人数を特定してステップＳ３０３に移る。ステップＳ３０３では配車要否判定部Ｆｓ５が、ステップＳ３０１で取得した残席数と、ステップＳ３０２で取得した待ち人数とを比較して、待ち人数が残席数を超過しているか否かを判定する。待ち人数が残席数を超過している場合には、ステップＳ３０３が肯定判定されてステップＳ３０４に移り、臨時バスの配車要求が必要であると判定する。一方、待ち人数が残席数以下である場合には、ステップＳ３０３が否定判定されてステップＳ３０５に移り、臨時バスの配車要求は不要であると判定する。
【０１２８】
このような態様によれば、より実際の運行状況に沿って臨時バスを手配することができる。
【０１２９】
［変形例３］
なお、変形例２においては、タグ情報パケットには、ユーザが降車するバス停（以降、降車予定地点）が登録されていることが好ましい。そのような態様によれば、車両用装置４は、無線タグ１との近距離通信によって、自車両に乗車しているユーザが降車する地点を特定することができる。これにより、車両用装置４は、次のバス停で降車するユーザの人数（以降、降車人数）を把握することができる。
【０１３０】
当然、乗車人数から降車人数を差し引いた人数が、次のバス停を出発する際にも引き続き乗車し続けるユーザの人数（以降、乗車継続者数）である。また、車両の定員から乗車継続者数を差し引いた人数が真の残席数である。
【０１３１】
センタ３は、以上のようにして定まる真の残席数をバス停用装置２に配信することで、バス停用装置２は、真の残席数に基づいて、臨時バスの配車が必要であるか否かを判定することができる。したがって、この変形例３の構成によれば、不要な臨時バスの配車要求をより一層抑制することができる。
【０１３２】
［変形例４］
上述した実施形態や種々の変形例では、バス停用装置２が臨時バスの配車が必要であるか否かを判定する態様を例示したが、これに限らない。バス停用装置２は、待ち人数特定部Ｆｓ４が特定した待ち人数をセンタ３に報告し、センタ３が、バス停用装置２から報告されてくる待ち人数に基づいて、臨時バスの配車が必要であるか否かを判定しても良い。
【０１３３】
図１３に示す配車要否判定部Ｆｃ５は、センタ側制御部３３が臨時バスの配車が必要であるか否かを判定するための機能ブロックである。配車要否判定部Ｆｃ５は、ＣＰＵが運行管理プログラムを実行することで実現されても良いし、ＩＣ等のハードウェア部材を用いて実現されても良い。このような態様によっても上述した効果を奏することができる。
【０１３４】
［変形例５］
ところで、１つのバス停が複数の路線に対応している場合も想定される。その場合、１つのバス停用装置２の近距離通信エリア内に、複数種類の路線を利用するユーザが混在して待機することになり、路線毎の待ち人数が不明となってしまう。
【０１３５】
そのような事情を鑑みると、無線タグ１には、図１４に示すように、ユーザが利用する路線を示す利用路線情報が登録されていることが好ましい。このような態様によれば、バス停用装置２は、無線タグ１との近距離通信によって、ユーザが何れの路線の定期バスの到着を待っているかを特定することができる。これにより、バス停用装置２は、路線ごとの待ち人数を特定できるようになり、臨時バスの手配が必要か否かを路線毎に判定できるようになる。
【０１３６】
［変形例６］
以上では、バス停用装置２を路線バスが停留する地点に設置して用いる態様を例示したが、これに限らない。バス停用装置２は、野外コンサートなどのイベントの開催に伴って臨時的にバス停として設定される地点（以降、臨時バス停）に設置して用いられても良い。臨時バス停は、イベントの参加者をイベント会場まで輸送するために運行させるバス（以降、参加者輸送バス）が停留する地点である。臨時バス停が請求項に記載の臨時停留所に相当する。
【０１３７】
なお、そのような場合にバス停用装置２が送信する配車要求メッセージには、ＧＮＳＳ受信機２３が特定しているバス停用装置２の現在位置を示す位置情報が含まれていることが好ましい。センタ３がどの地点に参加者輸送バスを向かわせればよいかを特定するためである。
【０１３８】
一般的に、イベントの参加者はイベントの終了に伴って一斉に帰宅を開始するため、帰宅時には臨時バス停に多数のユーザが並ぶことが想定される。この変形例６に開示の運行管理システム１００によれば、センタ３は、臨時バス停で待っている人数に応じた数の参加者輸送バスを配車することができる。そのため、イベント参加者をスムーズに帰宅させることができる。
【０１３９】
なお、この変形例６に開示の態様においては、イベントの参加証（例えばチケット等）にＩＣチップや近距離通信用のアンテナ等を埋め込むことで、イベントの参加証を無線タグ１として機能させてもよい。
【０１４０】
［変形例７］
以上では、請求項に記載の運送車両をバスとする態様を例示したが、これに限らない。運送車両はタクシーであっても良い。その場合には、タクシーの停留所（いわゆるタクシー乗り場）に、バス停用装置２に相当する装置（以降、タクシー乗り場装置）を配置する。タクシー乗り場装置も請求項に記載の停留所用装置の一例に相当する。なお、運送車両をタクシーとする場合のセンタ３とは、タクシーの運行を管理するセンタである。また、車両用装置４はタクシーに搭載される。
【符号の説明】
【０１４１】
１００  運行管理システム、１  無線タグ（発信器）、２  バス停用装置（停留所用装置）、３  センタ（運行管理装置）、４  車両用装置、１１  近距離通信部、２１  近距離通信部（停留所側受信装置）、２２  広域通信部（停留所側広域通信部）、２３  ＧＮＳＳ受信機（停留所側位置特定部）、Ｆｓ１  送信処理部（停留所側送信処理部）、Ｆｓ２  受信処理部（停留所側受信処理部）、Ｆｓ３  タグ検出部、Ｆｓ４  待ち人数特定部、Ｆｓ５  配車要否判定部（停留所側配車要否判定部）、Ｆｓ６  表示処理部、３１  広域通信部（管理側広域通信部）、３３  センタ側制御部、Ｆｃ１  送信処理部（管理側送信処理部）、Ｆｃ２  受信処理部（管理側受信処理部）、Ｆｃ３  運行状況管理部、Ｆｃ４  配車指示部（配車処理部）、Ｆｃ５  配車要否判定部、４１  広域通信部（車両側広域通信部）、４２  ロケータ（現在位置特定部）、４６  近距離通信部（車両側受信装置）、Ｆｖ１  送信処理部（車両側送信処理部）、Ｆｖ２  受信処理部、Ｆｖ３  案内処理部、Ｆｖ４  タグ検出部、Ｆｖ５  搭乗者情報管理部（乗車人数特定部）
【図１】
2017174203.tif 000003
【図２】
2017174203.tif 000004
【図３】
2017174203.tif 000005
【図４】
2017174203.tif 000006
【図５】
2017174203.tif 000007
【図６】
2017174203.tif 000008
【図７】
2017174203.tif 000009
【図８】
2017174203.tif 000010
【図９】
2017174203.tif 000011
【図１０】
2017174203.tif 000012
【図１１】
2017174203.tif 000013
【図１２】
2017174203.tif 000014
【図１３】
2017174203.tif 000015
【図１４】
2017174203.tif 000016