JP2019091365A - 運行管理システムおよび運行管理プログラム - Google Patents

Abstract

【課題】遅延理由を取得するシステムの提供。【解決手段】予定地点と前記予定地点に対応づけられた予定時刻とを含む走行計画を取得する走行計画取得部と、車両の走行地点と前記走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部と、前記走行計画に対する遅延が発生している場合、前記走行実績と前記走行計画とに基づいて遅延理由を取得する遅延理由取得部と、前記遅延理由を出力する遅延理由出力部と、を備える運行管理システムが構成される。【選択図】図１

Description

本発明は、運行管理システムおよび運行管理プログラムに関する。

貨物運送等において、車両が時刻通りに予定された地点に到着したり、予定された地点から出発したりすることが必要になる場合がある。このように予定が決められている場合に、予定に遅延を生じさせないようにするための技術が知られている。例えば、特許文献１においては、到着予定時刻を算出し、指定された集荷時刻を越えていたときに遅延があると判定する技術が開示されている。また、特許文献１においては、遅延が検知された場合に、他の車両に代替輸送を依頼する計画を算出することが開示されている。

特開２００１−１０４５５９号公報

特許文献１に開示された従来の技術においては、遅延が発生した場合に遅延の理由を特定することができなかった。従って、遅延が発生した場合に、遅延に対する改善策を立案し、対策することができない。このため、従来技術では遅延の再発を防止することができず、予定通りに車両が運行するように管理することは困難であった。
本発明は、上記課題にかんがみてなされたもので、遅延理由を取得するシステムの提供を目的とする。

上記の目的を達成するため、運行管理システムは、予定地点と予定地点に対応づけられた予定時刻とを含む走行計画を取得する走行計画取得部と、車両の走行地点と走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部と、走行計画に対する遅延が発生している場合、走行実績と走行計画とに基づいて遅延理由を取得する遅延理由取得部と、遅延理由を出力する遅延理由出力部と、を備える。

また、上記の目的を達成するため、運行管理プログラムは、コンピュータを、予定地点と予定地点に対応づけられた予定時刻とを含む走行計画を取得する走行計画取得部、車両の走行地点と走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部、走行計画に対する遅延が発生している場合、走行実績と走行計画とに基づいて遅延理由を取得する遅延理由取得部、遅延理由を出力する遅延理由出力部、として機能させる。

すなわち、運行管理システム、運行管理プログラムは、車両の走行実績を収集し、走行実績と走行計画とに基づいて遅延理由を取得して出力する。このため、車両の運転者などの人為的な入力等に依拠することなく、遅延理由を取得し、出力するシステムを提供することができる。従って、運行管理者は、遅延が発生した場合にその遅延理由を確実に認識することができる。

さらに、上記の目的を達成するため、運行管理システムが車両の走行地点と走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部と、予定地点からの出発時刻が予定された予定時刻よりも遅いことが走行実績に基づいて特定される場合、遅延理由が出発の遅れであると取得する遅延理由取得部と、遅延理由を出力する遅延理由出力部と、を備えていてもよい。

さらに、上記の目的を達成するため、運行管理プログラムが、コンピュータを車両の走行地点と走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部、予定地点からの出発時刻が予定された予定時刻よりも遅いことが走行実績に基づいて特定される場合、遅延理由が出発の遅れであると取得する遅延理由取得部、として機能させてもよい。

すなわち、走行実績に基づいて出発時刻を解析すれば、出発時刻が予定時刻よりも遅いに遅延理由が出発遅れであると取得することができる。

運行管理システムのブロック図である。 遅延有無判断処理を示すフローチャートである。 遅延理由判断処理を示すフローチャートである。 図４Ａ，図４Ｂは、遅延理由の出力例を示す図である。 他の実施形態に係る遅延理由判断処理を示すフローチャートである。 他の実施形態に係る遅延理由判断処理を示すフローチャートである。

ここでは、下記の順序に従って本発明の実施の形態について説明する。
（１）システム構成：
（１−１）ナビゲーションシステムの構成：
（１−２）運行管理システムの構成：
（１−３）運行管理者端末の構成
（２）遅延有無判断処理：
（３）遅延理由判断処理：
（４）出力例：
（５）他の実施形態：

（１）システム構成：
図１は、本発明にかかる運行管理システム１００の構成を示すブロック図である。本実施形態において運行管理システム１００は、複数の配送車両によって荷物を計画通りに配送するために利用される。本実施形態において運行管理システム１００は、配送車両で利用されるナビゲーションシステム１０および運行管理者端末５０と協働する。運行管理者端末５０は、複数の配送車両の運行管理を行う運行管理者が利用する端末であり、１台以上の端末が、例えば、配送会社の拠点等に設置される。ナビゲーションシステム１０は、複数の配送車両のそれぞれで利用され、配送車両に搭載されてもよいし、可搬型の端末が配送車両に持ち込まれて利用されても良い。

（１−１）ナビゲーションシステムの構成：
本実施形態にかかるナビゲーションシステム１０は、走行予定経路に沿って配送車両を誘導する案内を行うための端末であり、本実施形態においては、運行管理者と荷物の荷主とで予め走行計画を策定し、同意している。ナビゲーションシステム１０は、当該走行計画に従って配送車両を案内する機能を実行可能である。

走行計画は、予定地点と予定地点に対応づけられた予定時刻とによって規定されており、本実施形態においては、予定地点間の走行予定経路も含まれている。予定地点は、配送車両の出発地点、経由地点、最終目的地点のいずれかであり、各地点においては、荷物の積み込み、荷下ろし（以後、荷役と呼ぶ）のいずれかまたは双方が行われる。

ナビゲーションシステム１０は、ＣＰＵ，ＲＡＭ，ＲＯＭ等を備える制御部１２、図示しない記録媒体、通信部１５、ＧＮＳＳ受信部１６、車速センサ１７、ジャイロセンサ１８を備えている。制御部１２は、図示しない記録媒体やＲＯＭに記憶された図示しないナビゲーションプログラムを実行することができる。

図示しない記録媒体には、走行計画を示す情報と地図情報とが記録される。地図情報は、配送車両の位置や案内対象の施設の特定に利用される情報であり、配送車両が走行する道路上に設定されたノードの位置等を示すノードデータ，ノード間の道路の形状を特定するための形状補間点の位置等を示す形状補間点データ，ノード同士の連結を示すリンクデータ，道路やその周辺に存在する地物の位置等を示すデータ等を含んでいる。地物を示すデータには、地物の属性が対応づけられている。地物の属性には施設の種類（例えば、配送拠点、休憩地点等）が含まれている。

ＧＮＳＳ受信部１６は、Global Navigation Satellite Systemの信号を受信する装置であり、航法衛星からの電波を受信し、図示しないインタフェースを介して配送車両の現在地を算出するための信号を出力する。制御部１２は、この信号を取得して配送車両の現在地を取得する。車速センサ１７は、配送車両が備える車輪の回転速度に対応した信号を出力する。制御部１２は、図示しないインタフェースを介してこの信号を取得し、車速を取得する。ジャイロセンサ１８は、配送車両の水平面内の旋回についての角加速度を検出し、配送車両の向きに対応した信号を出力する。制御部１２は、この信号を取得して配送車両の進行方向を取得する。車速センサ１７およびジャイロセンサ１８等は、配送車両の走行軌跡を特定するために利用され、本実施形態においては、配送車両の出発位置と走行軌跡とに基づいて現在地が特定され、当該出発位置と走行軌跡とに基づいて特定された配送車両の現在地がＧＮＳＳ受信部１６の出力信号に基づいて補正される。

通信部１５は、他の装置と通信を行う回路を備えている。制御部１２は、通信部１５を介して運行管理システム１００と通信を行うことが可能である。また、制御部１２は、通信部１５を介して図示しない交通情報管理システムと通信を行うことが可能である。交通情報管理システムは、道路区間毎の渋滞度を管理するサーバであり、ナビゲーションシステム１０や運行管理システム１００からの要求に応じて要求された道路区間の渋滞度を示す情報を送信する。

制御部１２は、図示しないナビゲーションプログラムの機能により、走行計画および地図情報に基づいて、図示しないユーザＩ／Ｆ部の出力部を利用して配送車両の運転者に対して走行予定経路を指示する経路案内を行うことが可能である。また、制御部１２は、ナビゲーションプログラムの機能により、通信部１５を介して交通情報管理システムと通信を行い、走行予定経路上の交通情報を取得する。

制御部１２は、当該交通情報が示す渋滞度に基づいて現在地から次の予定地点までの所要時間を推定する。なお、所要時間の推定は、渋滞度から平均車速を推定し、道路区間の距離と平均車速に基づいて所要時間を算出するなどして実施可能である。そして、制御部１２は、所要時間に基づいて予定地点への推定到着時刻を算出し、ユーザＩ／Ｆ部に表示させる。この結果、配送車両の運転者に走行計画の充足度合いを伝達することができる。

以上の構成において、制御部１２は、配送車両の走行実績を運行管理システム１００に送信する。本実施形態において制御部１２は、一定期間（または一定距離）毎に、ＧＮＳＳ受信部１６，車速センサ１７，ジャイロセンサ１８の出力信号に基づいて配送車両の現在地を取得する。そして、制御部１２は、当該現在地に現在時刻と配送車両の識別情報（例えば、車両ナンバー等）を対応づけた走行実績を示す情報を生成し、通信部１５を介して運行管理システム１００に走行実績を送信する。この結果、運行管理システム１００においては、各配送車両の走行地点に走行時刻が対応づけられた走行実績であって、一定期間毎に収集された走行実績を取得することができる。

（１−２）運行管理システムの構成：
運行管理システム１００は、ＣＰＵ，ＲＡＭ，ＲＯＭ等を備える制御部２００、記録媒体３００、通信部４００を備えている。通信部４００は、ナビゲーションシステム１０および運行管理者端末５０と情報の授受を行う回路を備えており、制御部２００は、通信部４００を介してナビゲーションシステム１０および運行管理者端末５０と通信を行うことができる。また、制御部２００は、記録媒体３００やＲＯＭに記憶されたプログラムを制御部２００で実行することができる。本実施形態においては、このプログラムとして運行管理プログラム２１０を実行可能である。

また、記録媒体３００には、走行計画を示す走行計画情報３００ａおよび地図情報３００ｃが予め記録され、配送車両の運行過程で送信される走行実績を示す走行実績情報３００ｂが順次記録されていく。なお、走行計画情報３００ａは、上述のナビゲーションシステム１０の記録媒体に記録される走行計画と同様であり、予定地点と予定地点に対応づけられた予定時刻とによって規定され、予定地点間の走行予定経路も含まれている。

ただし、運行管理システム１００においては、運行管理対象となる配送車両の全てについての走行計画が走行計画情報３００ａとして記録媒体３００に記録されている。従って、走行計画情報３００ａには、配送車両の識別情報が対応づけられており、配送車両毎の走行計画が区別できるように構成されている。なお、走行計画情報３００ａは、予め策定されて記録媒体３００に記録されていれば良く、例えば、運行管理者が運行管理者端末５０から配送車両毎の走行計画情報３００ａを運行管理システム１００に送信し、記録媒体３００に記録される構成を採用可能である。

走行実績情報３００ｂは、各配送車両から送信される各配送車両の走行実績を示している。すなわち、走行実績情報３００ｂは、配送車両が走行した走行地点に走行時刻が対応づけられた走行実績が一定期間毎に収集された情報であり、配送車両の識別情報が対応づけられている。地図情報３００ｃは、ナビゲーションシステム１０の記録媒体に記録される地図情報と同様の情報であり、ノードデータ，形状補間点データ，リンクデータ，道路やその周辺に存在する地物の位置等を示すデータ等を含んでいる。地物を示すデータには、地物の属性（施設の種類等）が含まれている。

本実施形態において、運行管理プログラム２１０は、走行計画取得部２１０ａと走行実績取得部２１０ｂと遅延理由取得部２１０ｃと遅延理由出力部２１０ｄとを備えている。走行計画取得部２１０ａは、予定地点と予定地点に対応づけられた予定時刻とを含む走行計画を取得する機能を制御部２００に実行させるプログラムモジュールである。本実施形態においては、記録媒体３００に予め走行計画情報３００ａが記録されているため、制御部２００は、当該記録媒体３００を参照することによって走行計画を取得する。

なお、本実施形態においては、全ての配送車両を対象にして一定期間毎に遅延の発生の有無が判定され、遅延が発生している場合に遅延理由が取得されるが、必要なときに特定の配送車両について遅延の有無の判定や遅延理由の取得等が行われてもよい。いずれにしても、制御部２００は、走行計画取得部２１０ａの機能により、配送車両の識別情報に基づいて判定対象となる配送車両の走行計画情報３００ａを取得する。

走行実績取得部２１０ｂは、車両の走行地点と走行地点に対応づけられた走行時刻とを含む走行実績を取得する機能を制御部２００に実行させるプログラムモジュールである。すなわち、制御部２００は、走行実績取得部２１０ｂの機能により、通信部４００を監視し、ナビゲーションシステム１０から走行実績が送信されると、当該通信部４００を介して走行実績を取得し、走行実績情報３００ｂとして記録媒体３００に記録する。

遅延理由取得部２１０ｃは、走行計画に対する遅延が発生している場合、走行実績と走行計画とに基づいて遅延理由を取得する機能を制御部２００に実行させるプログラムモジュールである。走行実績は各配送車両における走行地点と走行時刻との履歴であるため、制御部２００は、走行実績に基づいて走行地点の移動に要した時間を特定することができる。そして、遅延理由は、配送車両の走行地点毎の挙動に密接に関連しており、ある存在地点においては他の存在地点特有の遅延理由は発生しない。そこで、本実施形態においては、遅延が発生した場合における車両の挙動を地点と関連づけて特定し、特定の地点で特定の挙動が行われたか否かに基づいて遅延理由を特定する構成が採用されている。

具体的には、制御部２００は、通信部４００を介して図示しない交通情報管理システムと通信し、走行計画情報３００ａが示す走行予定経路を構成する道路区間の渋滞度を取得する。また、制御部２００は、渋滞度から平均車速を推定し、道路区間の距離と平均車速に基づいて所要時間を算出することにより、現在地から次の予定地点までの推定所要時間を取得する。さらに、制御部２００は、推定所要時間に基づいて次の予定地点への推定到着時刻を算出する。さらに、制御部２００は、走行計画情報３００ａに基づいて次の予定地点に対応づけられた予定時刻を取得し、予定時刻が推定到着時刻より前である場合に遅延が発生していると判定する。

遅延が発生していると判定された場合、制御部２００は、走行実績情報３００ｂに基づいて走行地点毎の挙動を特定していく。本実施形態において制御部２００は、配送車両の走行地点が道路上である場合の挙動と、予定地点である場合の挙動と、休憩地点である場合の挙動を特定する。

すなわち、配送車両が道路上を走行中に遅延が発生した場合、遅延理由が道路事情である可能性が高い。そこで、遅延理由取得部２１０ｃは、道路上での所要時間を実績に基づいて推定し、計画上の所要時間と比較する。具体的には、遅延理由取得部２１０ｃは、配送車両が配送車両の走行予定経路に従って走行する場合の推定所要時間を、走行実績に基づいて取得する。すなわち、制御部２００は、遅延が発生しているか否か判定する際に取得された推定所要時間を、実績に基づいて推定された所要時間として取得する。

さらに、制御部２００は、走行計画情報３００ａに基づいて、配送車両が走行計画に従って走行する場合の予定所要時間を取得する。予定所要時間は、例えば、以下のようにして取得可能である。制御部２００が、配送車両が最後に出発した予定地点と、現在向かっている予定地点と、に対応づけられた予定時刻の差分を予定地点間の所要時間として取得する。また、制御部２００が、走行予定経路および地図情報３００ｃに基づいて配送車両の現在地点から次の予定地点までの残距離を取得する。さらに、制御部２００が、走行予定経路および地図情報３００ｃに基づいて予定地点間の距離を取得する。そして、制御部２００が予定地点間の所要時間に対して残距離／（予定地点間の距離）を乗じることにより、予定所要時間を取得する。

推定所要時間と予定所要時間とが取得されると、制御部２００は、推定所要時間と予定所要時間とを比較し、推定所要時間が予定所要時間を超える場合に、遅延理由が道路事情であると取得する。なお、本実施形態においては、道路区間毎の渋滞度に基づいて推定所要時間が取得され、道路外の滞在時間（例えば、休憩地点での休憩時間）は考慮されない。すなわち、配送車両が道路を走行する時間が所要時間として考慮され、道路上での所要時間に基づいて道路事情による遅延であるか否か判定される。なお、配送車両が予定地点を出発していない場合、道路上での所要時間に基づく遅延理由の判定は省略されても良い。

また、配送車両が予定より長く予定地点に滞在していた場合、遅延理由が予定地点における出発遅れである可能性が高い。そこで、制御部２００は、遅延理由取得部２１０ｃの機能により、走行実績情報３００ｂを参照し、配送車両が道路上または休憩地点に存在する場合には配送車両が最後に出発した予定地点を特定する。また、制御部２００は、遅延理由取得部２１０ｃの機能により、走行計画情報３００ａを参照し、配送車両が予定地点に存在する（予定地点と同一地点または予定地点から既定距離以内の地点）場合、当該予定地点を特定する。さらに、制御部２００は、特定された予定地点に対応づけられた予定時刻を取得する。

さらに、制御部２００は、走行実績に基づいて、予定地点からの出発時刻が当該予定時刻より遅いか否か判定する。すなわち、配送車両が道路上または休憩地点に存在する場合、制御部２００は、配送車両が最後に出発した予定地点から出発した直後の走行地点（予定地点から既定距離以内の走行地点）に対応づけられた走行時刻を出発時刻として取得し、当該出発時刻が予定時刻より遅いか否かを判定する。一方、配送車両が予定地点に存在する場合、制御部２００は、最も遅い走行時刻が予定時刻より遅い場合に出発事項が予定時刻より遅いと判定する。出発時刻が予定時刻より遅いと判定された場合、制御部２００は、遅延理由が出発の遅れであると取得する。

さらに、配送車両が予定より長く休憩地点に滞在していた場合、遅延理由が休憩超過である可能性が高い。そこで、制御部２００は、遅延理由取得部２１０ｃの機能により、走行実績情報３００ｂを参照し、配送車両が最後の予定地点以後において休憩地点で休憩を行ったか否かを判定する。すなわち、制御部２００は、地図情報３００ｃを参照し、配送車両の走行地点が道路外の地点（本実施形態においてはサービスエリアや駐車場等の休憩地点）に一致（休憩地点から既定距離以内に存在する場合を含む）した状態で走行地点が移動しない場合、配送車両の運転者が休憩したとみなす。

さらに、制御部２００は、走行実績情報３００ｂに基づいて、当該休憩地点での滞在時間を取得する。すなわち、配送車両の現在地点が休憩地点ではない場合、制御部２００は、配送車両の走行地点が休憩地点と一致した後、一致しなくなるまでの期間を走行時刻に基づいて特定し、滞在時間と見なす。配送車両の現在地点が休憩地点である場合、制御部２００は、配送車両の走行地点が休憩地点と一致した後、現在時刻までの期間を走行時刻に基づいて特定し、滞在時間と見なす。そして、制御部２００は、配送車両の道路外での滞在期間が基準期間より長いか否か判定し、基準期間より長い場合、遅延理由が休憩超過であると取得する。なお、基準期間は走行計画等によって予め決められている。

以上のような遅延の有無の判定と、遅延理由の取得は、配送車両毎に実行される。この結果、制御部２００は、配送車両毎に、走行計画に対する遅延の有無を特定し、遅延がある場合には遅延理由を特定することになる。

遅延理由出力部２１０ｄは、遅延理由を出力する機能を制御部２００に実行させるプログラムモジュールである。本実施形態においては、運行管理者端末５０を利用する運行管理者に対して遅延理由を出力する。すなわち、運行管理者は運行管理者端末５０を操作して所望の配送車両を出力させる指示を行うことができる。当該指示が行われると、配送車両の識別情報が送信される。

そこで、制御部２００は、通信部４００を介して当該配送車両の識別情報を取得し、遅延理由取得部２１０ｃの機能によって取得された遅延理由の中から、識別情報で指定される配送車両の遅延理由を抽出する。そして、制御部２００は、通信部４００を介して当該遅延理由を送信する。この結果、運行管理者端末５０において遅延理由が表示される。

以上の構成によれば、運行管理システム１００は、配送車両の走行実績を自動的に収集し、走行実績と走行計画とに基づいて遅延理由を取得することができる。このため、車両の運転者などの人為的な入力等に依拠することなく、遅延理由を取得し、出力するシステムを提供することができる。従って、運行管理者は、遅延が発生した場合にその遅延理由を確実に認識することができる。このため、運行管理者は遅延理由を解消するように対策をすることで、遅延の再発が防止される可能性を高めることができ、この結果、予定通りに車両が運行するように管理できる可能性を高めることができる。

（１−３）運行管理者端末の構成：
運行管理者端末５０は、運行管理者が配送車両毎の遅延の有無、遅延理由等を確認するための端末である。運行管理者端末５０は、ＣＰＵ，ＲＡＭ，ＲＯＭ等を備える制御部５２、図示しない記録媒体、ユーザＩ／Ｆ部５４、通信部５５を備えている。制御部５２は、図示しない記録媒体やＲＯＭに記憶された図示しないプログラムを実行することができる。なお、図示しない記録媒体には走行計画情報３００ａと地図情報３００ｃと同一の情報が記録されている。

ユーザＩ／Ｆ部５４は、運行管理者の入力を受け付ける入力部と、情報を表示する出力部とを備えており、任意の情報を出力部に表示することができる。むろん、出力部の出力態様は表示に限定されず、音声出力等であっても良い。通信部５５は、他の装置と通信を行う回路を備えており、制御部５２は、通信部５５を介して運行管理システム１００と通信を行うことが可能である。

制御部５２は、図示しないプログラムの機能により、配送車両毎の遅延の有無、遅延理由等をユーザＩ／Ｆ部５４の出力部に表示させることが可能である。すなわち、制御部５２は、ユーザＩ／Ｆ部５４を制御し、配送車両を指定する情報（識別情報等）を入力させるインタフェース画面を表示させる。運行管理者がユーザＩ／Ｆ部５４の入力部を操作して識別情報を指定すると、制御部５２は、通信部５５を介して当該識別情報を運行管理システム１００に送信する。

運行管理システム１００が識別情報を取得すると、当該識別情報が示す配送車両の遅延の有無および遅延理由を示す情報が返信される。制御部５２は、通信部５５を介して当該情報を受信し、ユーザＩ／Ｆ部３４７の出力部に遅延の有無および遅延理由を表示させる。遅延理由の表示態様は種々の態様を採用可能であり、本実施形態において制御部５２は、地図情報３００ｃを参照し、走行予定経路を地図上に表示させ、地図上に遅延理由を示す情報を表示することができる。

（２）遅延有無判断処理：
次に、制御部２００が遅延理由取得部２１０ｃの機能によって実行する遅延有無判断処理を説明する。運行管理システム１００においては、予め記録媒体３００に走行計画情報３００ａが記録されている。また、制御部２００は通信部４００を監視し、ナビゲーションシステム１０から走行実績情報３００ｂが送信されると、当該走行実績情報３００ｂを記録媒体３００に記録していく。

このように運行管理システム１００が稼働している状況において、制御部２００は、一定期間（例えば、１００ｍｓ）毎に、各配送車両を処理対象として図２に示す遅延有無判断処理を実行する。遅延有無判断処理が開始されると、制御部２００は、配送車両の走行地点と走行時刻を取得する（ステップＳ１００）。すなわち、制御部２００は、処理対象の配送車両の識別情報が対応づけられた走行実績情報３００ｂを参照し、処理対象の配送車両の最新の走行地点と走行時刻とを取得する。

次に、制御部２００は、配送車両の次の予定地点を取得する（ステップＳ１０５）。すなわち、制御部２００は、処理対象の配送車両の識別情報が対応づけられた走行計画情報３００ａを参照し、配送車両の最新の走行地点以後に到達予定の予定地点を次の予定地点として取得する。具体的には、制御部２００は、走行予定経路に従って走行した場合に最新の走行地点から最も近い予定地点を次の予定地点として取得する。なお、配送車両の走行地点が予定地点と一致する場合、当該予定地点後に最初に到達すべき予定地点が次の予定地点である。

次に、制御部２００は、推定到着時刻を取得する（ステップＳ１１０）。すなわち、制御部２００は、通信部４００を介して走行予定経路を構成する各道路区間の渋滞度を取得し、渋滞度に基づいて現在地から次の予定地点までの推定所要時間を取得する。次に制御部２００は、次の予定地点に対応する予定時刻を取得する（ステップＳ１１５）。すなわち、制御部２００は、処理対象の配送車両の識別情報が対応づけられた走行計画情報３００ａを参照し、次の予定地点に対応づけられた予定時刻を取得する。

そして、制御部２００は、予定時刻に間に合うか否かを判定する（ステップＳ１２０）。すなわち、制御部２００は、ステップＳ１１５で取得した予定時刻がステップＳ１１０で取得した推定到着時刻より後である場合に、予定時刻に間に合うと判定する。ステップＳ１２０において予定時刻に間に合うと判定されない場合、遅延が発生しているとみなし、制御部２００は、遅延理由判断処理（ステップＳ１３０）を実行する。一方、ステップＳ１２０において、予定時刻に間に合うと判定された場合、制御部２００は、ステップＳ１３０をスキップし、遅延有無判断処理を終了する。この場合、一定期間後に再び遅延有無判断処理が実行される状態となる。

以上のように、本実施形態において制御部２００は、配送車両の次の予定地点に間に合うか否かを判定する構成である。従って、ある配送車両の走行計画情報３００ａにおいて３個以上の予定地点が含まれる場合、各予定地点から次の予定地点までの区間は複数個存在し、各区間で遅延が発生したか否か判定されることになる。

（３）遅延理由判断処理：
次に、制御部２００が遅延理由取得部２１０ｃの機能によって実行する遅延理由判断処理を説明する。遅延理由判断処理において制御部２００は、現在地点以後の推定所要時間と計画された予定所要時間を取得する（ステップＳ２００）。すなわち、制御部２００は、通信部４００を介して走行予定経路を構成する各道路区間の渋滞度を取得し、渋滞度に基づいて現在地から次の予定地点までの推定所要時間を取得する。さらに、制御部２００は、配送車両が最後に出発した予定地点と、現在向かっている次の予定地点と、に対応づけられた予定時刻の差分を予定地点間の所要時間に対して、現在地点から次の予定地点までの残距離と予定地点間の距離との比を乗じるなどして予定所要時間を取得する。

次に、制御部２００は、推定所要時間が予定所要時間よりも長いか否かを判定する（ステップＳ２０５）。ステップＳ２０５において、推定所要時間が予定所要時間よりも長いと判定された場合、制御部２００は、遅延理由が道路事情であると判定する（ステップＳ２１０）。

一方、ステップＳ２０５において、推定所要時間が予定所要時間よりも長いと判定されない場合、制御部２００は、最後に到達した予定地点の出発時刻と予定時刻を取得する（ステップＳ２１５）。すなわち、制御部２００は、走行実績情報３００ｂを参照し、配送車両が道路上または休憩地点に存在する場合には配送車両が最後に出発した予定地点を特定する。配送車両が予定地点に存在する場合、当該予定地点が最後に出発した予定地点である。

さらに、制御部２００は、走行実績に基づいて、当該予定地点からの出発時刻を取得する。すなわち、制御部２００は、配送車両が最後に出発した予定地点から出発した直後の走行地点に対応づけられた走行時刻を出発時刻として取得する。配送車両が予定地点に存在する場合、例えば、最後に取得された走行実績情報３００ｂに含まれる走行時刻が出発時刻であると見なすことで判定を行うことが可能である。さらに、制御部２０は、最後に到達した予定地点または配送車両が存在する予定地点に対応づけられた予定時刻を取得する。

次に、制御部２００は、ステップＳ２１５で取得された出発時刻が予定時刻より遅いか否かを判定する（ステップＳ２２０）。ステップＳ２２０において、出発時刻が予定時刻より遅いと判定された場合、制御部２００は、遅延理由が出発遅れと判定する（ステップＳ２２５）。

一方、ステップＳ２２０において、出発時刻が予定時刻より遅いと判定されない場合、制御部２００は、制御部２０は、配送車両の道路外での滞在時間を取得する（ステップＳ２３０）。すなわち、制御部２００は、地図情報３００ｃを参照し、予定地点を出発後において、配送車両の走行地点が道路外の地点に一致した状態で走行地点が移動しない場合、配送車両の運転者が休憩したとみなす。さらに、制御部２００は、走行実績情報３００ｂに基づいて、配送車両の走行地点が休憩地点と一致した後、一致しなくなるまでの期間を走行時刻に基づいて特定し、滞在時間と見なす。配送車両の現在地点が休憩地点である場合、制御部２００は、配送車両の走行地点が休憩地点と一致した後、現在時刻までの期間を走行時刻に基づいて特定し、滞在時間と見なす。

次に、制御部２００は、滞在時間が基準時間よりも長いか否か判定する（ステップＳ２３５）。ステップＳ２３５において、滞在時間が基準時間よりも長いと判定された場合、制御部２００は、遅延理由が休憩超過と判定する（ステップＳ２４０）。一方、ステップＳ２３５において、滞在時間が基準時間よりも長いと判定されない場合、制御部２００は、遅延理由不明と判定する（ステップＳ２４５）。

処理対象の配送車両について遅延が発生している場合において、以上のようにして、遅延理由が特定されると、制御部２００は、当該処理対象の配送車両が存在する区間について遅延の発生が発生したことを示す情報と遅延理由とを示す情報を対応付けてＲＡＭ等のメモリに記録する。

以上の構成において、制御部２００は、配送車両の次の予定地点に間に合わない場合に、次の予定地点までの区間における遅延理由を判断する構成である。従って、ある配送車両の走行計画情報３００ａにおいて３個以上の予定地点が含まれる場合、各予定地点から次の予定地点までの区間は複数個存在し、配送車両が現在存在する区間で遅延理由が特定されることになる。このため、配送車両が現在存在する区間で遅延理由不明とされた場合であっても、配送車両が現在存在する区間よりも前の区間において、道路事情や出発遅れが遅延理由として特定されている場合はあり得る。

（４）出力例：
以上の処理により、配送車両のそれぞれについて遅延の有無と遅延理由とが特定された状態において、運行管理者端末５０が配送車両の識別情報を指示すると、制御部２００は、遅延理由出力部２１０ｄの機能により、遅延理由を出力する。運行管理者端末５０においては、種々の態様によって遅延理由を出力可能である。

図４Ａおよび図４Ｂは、遅延理由の出力例を示す図である。これらの例においては、遅延理由が出力された車両が配送車両１であることが想定されている。また、これらの例においては、配送車両の走行計画に含まれる走行予定経路と予定地点とが地図上に表示される。すなわち、図４Ａおよび図４Ｂにおいて、配送車両１は予定地点Ｐ₁，Ｐ₂，Ｐ₃の順に配送を行うように計画されており、予定地点Ｐ₁〜Ｐ₃の走行予定経路が太い線で示され、配送車両の現在地点（最新の走行地点）がアイコンＩcで示されている。従って、図４Ａ，図４Ｂともに配送車両は予定地点Ｐ₂，Ｐ₃間の区間に存在する状態が想定されている。

また、図４Ａ，図４Ｂともに、配送車両がアイコンＩcで示す位置において、次の予定地点Ｐ₃に対応づけられた予定時刻に間に合わず、遅延が発生していることが想定されている。ただし、図４Ａで想定されている遅延理由と、図４Ｂで想定されている遅延理由とは異なっており、図４Ａにおいて配送車両１が遅延した遅延理由は、予定地点Ｐ₂，Ｐ₃間の区間の道路事情であり、図４Ｂにおいて配送車両１が遅延した遅延理由は、予定地点Ｐ₁における出発遅れである。これらの遅延理由は、文字によって示されるとともに、地図上でも示されている。

図４Ａにおいては、予定地点Ｐ₂，Ｐ₃間の区間の道路が破線で示されることによって当該区間の道路事情が通常より悪い（例えば、事故や渋滞等）ことが示されており、運行管理者は当該道路事情によって予定地点Ｐ₃への到達が遅れると認識することができる。このように遅延理由が示されると、同一の区間における同一理由での遅延が頻発するか否かを解析するなどして、例えば、配送経路を変更するなどの対策を立てることが可能である。この結果、より効率的に運行されるように運行管理することが可能である。

一方、図４Ｂにおいては、予定地点Ｐ₁を示すアイコンが他の予定地点よりも強調されることによって当該予定地点での出発が予定より遅かったことが示されており、運行管理者は当該出発遅れによって予定地点Ｐ₃への到達が遅れると認識することができる。このように遅延理由が示されると、同一の予定地点における同一理由での遅延が頻発するか否かを解析するなどして、例えば、予定地点での作業内容を変えるなどの対策を立てることが可能である。この結果、より効率的に運行されるように運行管理することが可能である。

（５）他の実施形態：
以上の実施形態は本発明を実施するための一例であり、走行実績に基づいて遅延理由を取得する限りにおいて、他にも種々の実施形態を採用可能である。例えば、走行計画情報３００ａに走行予定経路が含まれない構成が採用されてもよい。この場合、例えば、走行予定経路は配送車両の運転者に任されており、予定地点と予定時刻とが運行管理者と荷主とで合意されている構成等を採用可能である。

上述の実施形態を構成する各システムは、機能を共有したより少ない装置で構成されても良い。このような例としては、図１に示す少なくとも１台のシステムが、他の１台以上のシステムと同一の装置で構成される例が挙げられる。例えば、ナビゲーションシステム１０と運行管理者端末５０とが一体の装置で構成されても良いし、運行管理システム１００と運行管理者端末５０とが一体の装置で構成されても良いし、運行管理システム１００とナビゲーションシステム１０とが一体の装置で構成されても良い。

むろん、ナビゲーションシステム１０は、車両に備えられていても良いし、可搬型の端末等であっても良い。さらに、図１に示すシステムがより多数のシステムで構成されても良い。例えば、運行管理システム１００がクラウドサーバで構成されても良い。

また、運行管理システム１００を構成する各部（走行計画取得部２１０ａ、走行実績取得部２１０ｂ、遅延理由取得部２１０ｃ、遅延理由出力部２１０ｄ）の少なくとも一部が複数の装置に分かれて存在していても良い。例えば、走行計画取得部２１０ａ、走行実績取得部２１０ｂ、遅延理由取得部２１０ｃ等がナビゲーションシステム１０や運行管理者端末５０で実行される構成等であってもよい。また、上述の実施形態の一部の構成が省略される構成や、処理が変動または省略される構成も想定し得る。

走行計画取得部は、予定地点と予定地点に対応づけられた予定時刻とを含む走行計画を取得することができればよい。すなわち、車両が到達すべき地点と当該地点に対応づけられた時刻とが走行計画として予め定義され、走行計画取得部が当該走行計画を取得可能であれば良い。予定地点は、車両の走行開始地点、すなわち、出発地点を含み、出発後に到達すべき地点が１カ所であれば、合計２カ所の地点が予定地点となる。出発後に到達すべき地点がＮカ所（Ｎは２以上の整数）であれば、合計Ｎ＋１カ所の地点が予定地点となる。

出発地点を含む予定地点は、上述の実施形態のように荷役が行われる地点であっても良いし、他の目的の地点であっても良い。例えば、人員輸送等であれば人員の乗降が行われる地点が予定地点となり得るし、目的地への訪問であれば目的地が予定地点となり得る。また、同一の予定地点と見なされる範囲は、計画の態様に応じて規定されて良い。例えば、広い拠点内の複数の地点で荷役が行われる場合に、複数の地点のそれぞれが予定地点とされても良いし、拠点を示す代表地点が予定地点とされても良く、種々の構成を採用可能である。

予定時刻は、予定地点に対応づけられていればよく、当該予定時刻に基づいて走行計画に対する遅延の有無や遅延理由を評価可能であれば良い。予定時刻は、同一地点について少なくとも１個設定されていれば良く、２個以上設定されていても良い。例えば、予定時刻までに車両において達成すべき目的と対応づけて予定時刻が定義されても良く、予定地点への到達予定時刻や予定地点からの出発予定時刻等が予定時刻となってもよい。予定時刻が２個以上設定される場合、走行計画に対する遅延の有無が判定される時刻が予め決められる。例えば、１個の予定地点に到達予定時刻と出発予定時刻とが対応づけられる場合、何れか一方の時刻で遅延の有無が判定されるのか、双方の時刻で遅延の有無が判定されるのか予め決められる。

走行実績取得部は、車両の走行地点と走行地点に対応づけられた走行時刻とを含む走行実績を取得することができればよい。すなわち、走行実績取得部は、車両が走行した走行地点と、当該走行地点を走行した走行時刻とを少なくとも含む走行履歴を取得することができればよい。

走行地点は、車両が実際に走行した地点であれば良く、例えば、予め決められたタイミングで車両の現在地が取得され、走行地点と見なされる構成等が挙げられる。なお、予め決められたタイミングとしては、種々のタイミングが想定可能であり、例えば、一定期間毎のタイミング、車両で減速されたタイミング、車両が停止したタイミング、車両で既定の操作がされたタイミング等が挙げられる。

遅延理由取得部は、走行計画に対する遅延が発生している場合、走行実績と走行計画とに基づいて遅延理由を取得することができればよい。すなわち、走行実績は、車両が走行した走行地点に走行時刻が対応づけられた情報であり、走行計画は予定地点に予定時刻が対応づけられた情報である。従って、両者を比較すれば、走行計画のどの段階で遅延が発生したのか、または、どの段階で遅延が発生すると推定されるのか、特定することができる。このため、遅延理由を取得することができる。

遅延理由は、種々の理由が想定可能であり、例えば、車両の挙動や存在地点等に基づいて遅延理由が取得される構成等を採用可能である。このような構成としては、走行実績に基づいて車両の存在地点が予定地点、道路上、予定地点ではない道路外（休憩地点等）のいずれかであるのか特定される構成が挙げられる。より具体的には、予定地点に車両が存在した状態で遅延が発生した場合に遅延理由が出発遅れ、道路上に車両が存在した状態で遅延が発生した場合に遅延理由が道路事情、予定地点ではない道路外に車両が存在した状態で遅延が発生した場合に遅延理由が休憩超過であると判定する構成等が挙げられる。

なお、存在地点に起因して遅延が発生したか否か判定する際には、例えば、各地点に車両が存在する状態で遅延が確定または遅延が生じると推定される場合に遅延が発生したと判定される構成であっても良いし、走行実績に基づいて各地点の滞在期間が特定され、滞在期間が既定期間以上である場合に遅延が発生したと判定される構成であっても良い。

予定地点で発生する理由と、予定地点間で発生する理由とは、より詳細に判定されても良く、例えば、走行実績に基づいて、予定時刻前に予定地点に到達している（出発地点であれば最初から出発地点に存在する）にもかかわらず、予定時刻を過ぎても予定地点にとどまっていることが判明している場合、予定地点で発生する理由、例えば、出発遅れが遅延理由であると取得されてもよい。

また、走行実績に基づいて、遅延することなくある予定地点を出発し、次の予定地点に対して予定時刻において未達であることが推定される、または確定している場合、ある予定地点と次の予定地点との間で発生する理由（例えば、道路事情等）が遅延理由であると取得されてもよい。

なお、遅延が発生しているか否かの判定は、遅延理由取得部で行われても良いし、遅延理由取得部と異なる判定部（例えば、ナビゲーションシステム等）で行われてもよい。また、遅延が発生しているか否かの判定を行うための手法は、上述のように推定到着時刻を算出する手法以外にも種々の手法が採用されてよい。例えば、予定地点における走行時刻が予定時刻を過ぎている場合等に遅延が発生していると判定する構成等であっても良い。この場合、予定地点は荷役地点に限らず、例えば、道路上に設定された任意の地点であってもよい。

遅延理由出力部は、遅延理由を出力することができればよい。出力先は、上述の実施形態のように、外部の装置（当該装置を操作する運行管理者）に限定されず、運行管理システムが備える出力部（ディスプレイやスピーカ等）であっても良い。

さらに、遅延理由を取得するための手法は、上述の手法に限定されない。例えば、予定地点における予定時刻よりも当該予定地点に対する推定到着時刻の方が遅い場合に遅延理由が道路事情であると取得する構成等を採用可能である。さらに、遅延理由が道路事情であるか否か判定するために、道路上の交通情報を解析しても良い。このような構成は、例えば、上述の図１に示す運行管理システム１００において、遅延理由取得部２１０ｃが交通情報を解析する構成によって実現可能である。

すなわち、配送車両に遅延が生じていると判定された場合に、制御部２００が遅延理由取得部２１０ｃの機能により、走行実績情報３００ｂを参照し、走行地点の時間変化に基づいて配送車両が道路上を走行しており、かつ、車速が基準車速より遅いことが特定される場合に遅延理由が道路事情であると取得する構成等を採用可能である。より具体的には、例えば、図３に示すフローチャートを図５，図６に示すフローチャートに置換する構成を採用可能である。すなわち上述の図３におけるステップＳ２０５において、推定所要時間が予定所要時間よりも長いと判定された場合に、制御部２００は、走行実績情報３００ｂに基づいて車速を取得する（ステップＳ２０６）。当該車速は、例えば、最新の走行実績を含む複数の走行地点に基づいて走行距離を特定し、対応する複数の走行時刻に基づいて所要時間を特定し、走行距離を所要時間で除する処理等によって実現可能である。

次に、制御部２００は、車速が基準車速より遅いか否か判定し（ステップＳ２０７）、車速が基準車速より遅いと判定された場合にステップＳ２１０を実行し、車速が基準より遅いと判定されない場合にステップＳ２４５を実行する。この構成によれば、配送車両の車速が基準車速より遅くなっていることを確認した上で遅延理由が道路事情であると取得することができる。従って、遅延理由が道路事情であることを正確に特定できる可能性を高めることができる。

さらに、車両が走行予定経路を外れた場合に経路外れが遅延理由であると判定する構成であっても良い。この構成は、例えば、上述の図１に示す構成に以下の構成を付加することで実現可能である。すなわち、配送車両に遅延が生じていると判定された場合に、制御部２００が遅延理由取得部２１０ｃの機能により、走行計画情報３００ａに基づいて走行予定経路を取得し、走行実績情報３００ｂを参照して走行地点を取得する。そして、制御部２００が、走行地点が走行予定経路上であるか否かを判定し、走行予定経路上ではなく走行予定経路外である場合に、遅延理由が経路外れであると取得する構成等を採用可能である。

より具体的には、例えば、図３に示すフローチャートを図５，図６に示すフローチャートに置換する構成を採用可能である。図５に示すフローチャートにおいては、遅延理由が道路事情であるか否かの判定を行う前に経路外れであるか否かの判定が行われる。すなわち、遅延理由判断処理が開始されると、制御部２００は、走行実績情報３００ｂに基づいて配送車両の現在地点を取得する（ステップＳ１９１）。配送車両の現在地点は、例えば、最新の走行地点が現在地点であると見なす処理等によって実現可能である。

次に、制御部２００は、現在地点が走行予定経路外であるか否かを判定し（ステップＳ１９２）、現在地点が走行予定経路外であると判定された場合に遅延理由が経路外れと判定する（ステップＳ１９３）。ステップＳ１９２において、現在地点が走行予定経路外であると判定されない場合、制御部２００は、ステップＳ２００以降の処理を実行する。

一方、図６に示すフローチャートにおいては、遅延理由が道路事情であるか否かの判定が行われた後に経路外れであるか否かの判定が行われる。すなわち、ステップＳ２０５において、推定所要時間が予定所要時間よりも長いと判定されない場合に、制御部２００がステップＳ２１１，ステップＳ２１２を実行する。ステップＳ２１１，ステップＳ２１２は、図５に示すステップＳ１９１，ステップＳ１９２と同様の処理である。そして、ステップＳ２１２において、現在地点が走行予定経路外であると判定された場合に制御部２００は遅延理由が経路外れと判定する（ステップＳＳ２１３）。

ステップＳ２１２において、現在地点が走行予定経路外であると判定されない場合、制御部２００は、ステップＳ２１５以降の処理を実行する。むろん、遅延理由が経路外れであるか否かの判定は、遅延理由が出発遅れであるか否かの判定や休憩超過であるか否かの判定の後に行われてもよい。また、ステップＳ２０７で車速が基準車速より遅いと判定されない場合に実行されてもよい。以上の構成によれば、走行予定経路を間違えた場合や、道に迷ったことによって遅延が生じたことを特定することができる。

さらに、走行計画情報が示す予定時刻が、予定地点への到着予定時刻と予定地点からの出発予定時刻とを含む構成において、時刻の定義の差異に基づいて詳細な遅延理由を取得しても良い。例えば、上述の図１に示す構成において、走行計画情報３００ａが示す予定時刻に到着予定時刻と出発予定時刻とが含まれる構成を想定する。この構成において、制御部２００は、遅延理由取得部２１０ｃの機能により、走行実績情報３００ｂに基づいて、予定地点への到着時刻と到着予定時刻とを比較し、到着時刻が到着予定時刻以前である場合、予定地点への到着は間に合っていると判定する。この場合、配送車両は計画通りに行動していると推定される。

さらに、制御部２００は、走行実績情報３００ｂに基づいて、予定地点からの出発時刻を取得し、出発時刻が出発予定時刻よりも遅いか否か判定する。そして、予定地点への到着は間に合っているにもかかわらず、出発時刻が出発予定時刻よりも遅い場合には、配送車両ではなく予定地点側に問題があると推定される。そこで、制御部２００は、遅延理由が予定地点での遅延であると取得する。なお、予定地点での遅延は、例えば、予定地点に存在する施設側の理由であり、荷物の滞留、未達、荷役のためのヤードが混雑していたなど、配送車両や配送車両の運転手に起因していない理由が挙げられる。

さらに、本発明のように、走行実績に基づいて遅延理由を取得する手法は、プログラムや方法としても適用可能である。また、以上のようなシステム、プログラム、方法は、単独の装置として実現される場合もあれば、車両に備えられる各部と共有の部品を利用して実現される場合もあり、各種の態様を含むものである。例えば、以上のようなシステムで実現される方法、プログラムを提供することが可能である。また、一部がソフトウェアであり一部がハードウェアであったりするなど、適宜、変更可能である。さらに、装置を制御するプログラムの記録媒体としても発明は成立する。むろん、そのソフトウェアの記録媒体は、磁気記録媒体であってもよいし光磁気記録媒体であってもよいし、今後開発されるいかなる記録媒体においても全く同様に考えることができる。

１０…ナビゲーションシステム、１２…制御部、１５…通信部、１６…ＧＮＳＳ受信部、１７…車速センサ、１８…ジャイロセンサ、２０…制御部、５０…運行管理者端末、５２…制御部、５４…ユーザＩ／Ｆ部、５５…通信部、１００…運行管理システム、２００…制御部、２１０…運行管理プログラム、２１０ａ…走行計画取得部、２１０ｂ…走行実績取得部、２１０ｃ…遅延理由取得部、２１０ｄ…遅延理由出力部、３００…記録媒体、３００ａ…走行計画情報、３００ｂ…走行実績情報、３００ｃ…地図情報、３４７…ユーザＩ／Ｆ部、４００…通信部

Claims (12)

1. 予定地点と前記予定地点に対応づけられた予定時刻とを含む走行計画を取得する走行計画取得部と、
   車両の走行地点と前記走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部と、
   前記走行計画に対する遅延が発生している場合、前記走行実績と前記走行計画とに基づいて遅延理由を取得する遅延理由取得部と、
   前記遅延理由を出力する遅延理由出力部と、
   を備える運行管理システム。
2. 前記走行計画は、前記車両の走行予定経路を含み、
   前記遅延理由取得部は、
   前記車両が前記車両の走行予定経路に従って走行した場合に前記予定地点に到着する推定到着時刻を取得し、前記予定時刻よりも前記推定到着時刻の方が遅い場合に遅延が発生していると判定する、
   請求項１に記載の運行管理システム。
3. 前記走行計画は、前記車両の走行予定経路を含み、
   前記遅延理由取得部は、
   前記車両が前記車両の走行予定経路に従って走行する場合の推定所要時間を、前記走行実績に基づいて取得し、前記推定所要時間が前記走行計画に従って走行する場合の予定所要時間を超える場合に、前記遅延理由が道路事情であると取得する、
   請求項１または請求項２に記載の運行管理システム。
4. 前記遅延理由取得部は、
   前記走行実績に基づいて、前記車両が道路上を走行しており、かつ、車速が基準車速より遅いことが特定される場合、前記遅延理由が道路事情であると取得する、
   請求項２に記載の運行管理システム。
5. 前記遅延理由取得部は、
   前記予定地点からの出発時刻が当該予定地点に対して対応づけられた前記予定時刻よりも遅いことが前記走行実績に基づいて特定される場合、前記遅延理由が出発の遅れであると取得する、
   請求項１〜請求項４のいずれかに記載の運行管理システム。
6. 前記遅延理由取得部は、
   前記走行実績に基づいて、前記車両の道路外での滞在期間が基準期間より長いことが特定される場合、前記遅延理由が休憩超過であると取得する、
   請求項１〜請求項５のいずれかに記載の運行管理システム。
7. 前記走行計画は、前記車両の走行予定経路を含み、
   前記遅延理由取得部は、
   前記走行実績に基づいて、前記車両が前記車両の走行予定経路外の道路を走行したことが特定される場合、前記遅延理由が経路外れであると取得する、
   請求項１〜請求項６のいずれかに記載の運行管理システム。
8. 前記予定時刻は、前記予定地点への到着予定時刻と前記予定地点からの出発予定時刻とを含み、
   前記遅延理由取得部は、
   前記予定地点への到着時刻が前記到着予定時刻以前であり、前記予定地点からの出発時刻が前記出発予定時刻よりも遅いことが前記走行実績に基づいて特定される場合、前記遅延理由が前記予定地点での遅延であると取得する、
   請求項１〜請求項７のいずれかに記載の運行管理システム。
9. 前記走行計画は、３個以上の前記予定地点を含み、
   前記遅延理由は、前記予定地点の間の区間毎に取得される、
   請求項１〜請求項８のいずれかに記載の運行管理システム。
10. 車両の走行地点と前記走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部と、
    予定地点からの出発時刻が予定された予定時刻よりも遅いことが前記走行実績に基づいて特定される場合、遅延理由が出発の遅れであると取得する遅延理由取得部と、
    前記遅延理由を出力する遅延理由出力部と、
    を備える運行管理システム。
11. コンピュータを、
    予定地点と前記予定地点に対応づけられた予定時刻とを含む走行計画を取得する走行計画取得部、
    車両の走行地点と前記走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部、
    前記走行計画に対する遅延が発生している場合、前記走行実績と前記走行計画とに基づいて遅延理由を取得する遅延理由取得部、
    前記遅延理由を出力する遅延理由出力部、
    として機能させる運行管理プログラム。
12. コンピュータを、
    車両の走行地点と前記走行地点に対応づけられた走行時刻とを含む走行実績を取得する走行実績取得部、
    予定地点からの出発時刻が予定された予定時刻よりも遅いことが前記走行実績に基づいて特定される場合、遅延理由が出発の遅れであると取得する遅延理由取得部、
    前記遅延理由を出力する遅延理由出力部、
    として機能させる運行管理プログラム。

Images