JP7302952B2 - 運行管理プログラム、運行管理方法及び運行管理装置 - Google Patents

Description

本発明は、運行管理プログラム、運行管理方法及び運行管理装置に関する。

過労運転等を抑制する側面から、運転者の拘束時間、休息期間や運転時間などの基準にしたがって運行管理者等により運行計画が作成される。このような運行計画の作成を支援する側面から、デジタルタコグラフ、いわゆる運行記録計を搭載する商用車、例えばトラックやバス等から収集される走行データを用いて、出発および目的の地点や日時などの指定条件に対応する運行ルートを策定するプラットフォームが提供されている。

特開２０１７－１５１５６６号公報

しかしながら、上記の技術では、運行計画を円滑に変更することができない。

すなわち、上記のプラットフォームは、あくまで計画の時点で想定される道路および交通の状況に基づいて運行ルートを策定するものに過ぎない。このため、運行計画にしたがって運行が実際に行われる運行中の局面と、運行計画が作成される局面との間では、道路や交通の状況にずれが生じる場合がある。

このように道路および交通の状況にずれが生じる場合、運行計画を円滑に変更するのが困難である現状がある。なぜなら、運行計画の変更の要否の判断を始め、ルートや目的地の到着予定時間等の変更内容の決定が運行管理者個人の技量、例えば経験則などに委ねられているからである。このため、運行計画の変更の要否を判断出来なかったり、運行計画の変更内容に見通しが立たなかったりすることが一因となって運行計画の変更の判断が遅れることがある。

１つの側面では、本発明は、運行計画を円滑に変更できる運行管理プログラム、運行管理方法及び運行管理装置を提供することを目的とする。

一態様では、運行管理プログラムは、車載装置から位置および日時を取得し、出発地から目的地までのルート上のノードおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される位置または日時と、前記車載装置から取得される日時に対応するノードまたは車載装置から取得される位置に対応する到着予定時刻とのずれが許容範囲外であるか否かを判定し、前記ずれが前記許容範囲外である場合、前記車載装置から取得される日時から所定の期間内における他の車両の走行実績に基づいて前記車載装置から取得される位置から前記目的地までのルートおよび所要時間を再計算し、再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する、処理をコンピュータに実行させる。

運行計画を円滑に変更できる。

図１は、実施例１に係る運行管理システムの一例を示す図である 図２は、実施例１に係る運行管理装置の機能的構成の一例を示すブロック図である。 図３は、運行ルートの逸脱判定の一例を示す図である。 図４は、チェックポイント計画情報１３ｂの一例を示す図である。 図５は、車両動態情報１３ｃの一例を示す図である。 図６は、ルックアップテーブルの一例を示す図である。 図７は、変更承認受付画面の一例を示す図である。 図８は、変更承認受付画面の一例を示す図である。 図９は、車両予定情報の一例を示す図である。 図１０は、実施例１に係る第１判定処理の手順を示すフローチャートである。 図１１は、実施例１に係る第２判定処理の手順を示すフローチャートである。 図１２は、実施例１及び実施例２に係る運行管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。 図１３は、車両の走行データの一例を示す図である。 図１４は、プローブデータの一例を示す図である。

以下に添付図面を参照して本願に係る運行管理プログラム、運行管理方法及び運行管理装置について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［運行管理システム］
図１は、実施例１に係る運行管理システムの一例を示す図である。図１に示す運行管理システム１は、トラックやバス等の車両３の運行管理を支援する運行管理サービスを提供するものである。

図１に示すように、運行管理システム１には、運行管理装置１０と、デジタルタコグラフ３０と、運行管理者端末５０とが含まれる。なお、図１には、説明の便宜上、１つのデジタルタコグラフ３０が運行管理装置１０に接続される例を挙げたが、任意の台数、例えば複数のデジタルタコグラフ３０が運行管理装置１０に接続されることを妨げない。

運行管理装置１０は、上記の運行管理サービスを提供するコンピュータである。

一実施形態として、運行管理装置１０は、パッケージソフトウェア又はオンラインソフトウェアとして、上記の運行管理サービスに対応する機能を実現する運行管理プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、運行管理装置１０は、上記の運行管理サービスを提供するサーバとしてオンプレミスに実装することとしてもよいし、アウトソーシングによって上記の運行管理サービスを提供するクラウドとして実装することとしてもかまわない。

デジタルタコグラフ３０は、車両３に搭載される車載装置の一種であり、デジタコ、あるいは運行記録計とも呼ばれる。以下、デジタルタコグラフのことを「デジタコ」と記載する場合がある。

例えば、デジタコ３０は、図示しない車両のデジタコ専用コネクタやＥＣＵ（Electronic Control Unit）などを介して接続されることにより、速度や距離などの走行記録を取得できる。例えば、デジタコ３０は、速度や距離などの法定の走行パラメータの時系列データを始め、これと共に、デジタコ３０は、図示しないＧＰＳ（Global Positioning System）受信機などを介して、緯度および経度を含む位置情報の時系列データを走行データとして取得することができる。なお、デジタコ３０は、任意のサンプリング周期、例えば０．５秒以下の間隔で走行データを取得できる。走行データは複数の車両のそれぞれに搭載されたデジタコから取得する。

このようにデジタコ３０により取得された走行データは、デジタコ３０に搭載された３ＧやＬＴＥ（Long Term Evolution）等のモバイルネットワーク対応の無線通信モジュールにより運行管理装置１０へアップロードされる。例えば、運行管理装置１０へのアップロードは、ＥＣＵやＧＰＳによる出力が得られる度、所定の周期もしくは定期時刻などの任意の契機に実行できる。

運行管理者端末５０は、上記の運行管理サービスの提供を受けるクライアントの一例に対応するコンピュータである。あくまで一例として、運行管理者端末５０は、運送事業者の運行管理者等の関係者により使用される。

例えば、運行管理者端末５０には、パーソナルコンピュータなどのデスクトップ型のコンピュータなどが対応する。これはあくまで一例であり、運行管理者端末５０は、ラップトップ型のコンピュータや携帯端末装置、ウェアラブル端末などの任意のコンピュータであってかまわない。

［運行計画の作成サービス］
上記の運行管理サービスの一環として、運行管理装置１０は、車両３の乗務員による運転日報の作成や車両３の動態管理、配車管理などのサービスを提供することができる他、運行計画の作成を支援する運行計画の作成支援サービスなどを提供できる。例えば、上記の運行計画の作成支援サービスでは、車両３から収集される走行データを用いて、出発および目的の地点や日時などの指定条件に対応する運行ルートを策定するプラットフォームが利用される。

［課題の一側面］
上記の背景技術の欄でも説明した通り、上記のプラットフォームは、あくまで計画の時点で想定される道路および交通の状況に基づいて運行ルートを策定するものに過ぎない。このため、運行計画にしたがって運行が実際に行われる運行中の局面と、運行計画が作成される局面との間では、道路や交通の状況にずれが生じる場合がある。

このように道路および交通の状況にずれが生じる場合、運行計画を円滑に変更するのが困難である現状がある。なぜなら、運行計画の変更の要否の判断を始め、ルートや目的地の到着予定時間等の変更内容の決定が運行管理者個人の技量、例えば経験則などに委ねられているからである。このため、運行計画の変更の要否を判断出来なかったり、運行計画の変更内容に見通しが立たなかったりすることが一因となって運行計画の変更の判断が遅れることがある。

［課題解決のアプローチの一側面］
そこで、本実施例に係る運行管理装置１０は、デジタコ３０から取得される現在の位置および日時と、運行計画で定められたルートの予定位置および到着予定日時とのずれが許容範囲を超えると、運行管理者端末５０から承認を受け付けることを条件に直近の走行実績を用いて再計算されたルートおよび所要時間に基づいて運行計画を変更する運行計画の変更支援サービスを提供する。

この運行計画の変更支援サービスによって、運行計画の変更の要否の判断を始め、ルートや目的地の到着予定時間等の変更内容の決定を運行管理者個人の技量、例えば経験則などに委ねずともよくなる。それ故、運行計画の変更の要否を判断出来なかったり、運行計画の変更内容に見通しが立たなかったりする事態を抑制することができる。したがって、本実施例に係る運行管理装置１０によれば、運行計画を円滑に変更することが可能になる。

［連携先のシステム］
このように運行計画が変更される場合、本実施例に係る運行管理装置１０は、上記の運行計画の変更支援サービスの一環として、運行管理システム１が連携する連携先のシステム２に、変更後の運用計画に関する情報を通知することができる。

このような連携先のシステム２の例として、荷主側システム２０やバース予約システム４０、求貨求車システム６０などが挙げられる。

（１）荷主側システム
これらのうち、荷主側システム２０は、運送事業者に発注を行う荷主により運用される各種のシステムである。例えば、荷主側システム２０は、サプライチェーンを最適化する目的で構築されるＳＣＭ（Supply Chain Management）システムの他、荷主が運送事業者への発注に用いる発注システム等などが対応する。この他、荷主側システム２０は、車両３の乗務員による荷積みや荷卸し等を確認する担当者、その責任者等により使用されるコンピュータであってもかまわない。

例えば、荷主側システム２０には、上記の運行計画の作成支援サービスを通じて、運行計画の作成時に荷主により発注された目的地の到着予定日時が登録または通知されている。つまり、運行計画が作成された段階で、目的地の到着予定日時がサプライチェーンや荷主側のスケジュールとして組み込まれた状況にある。このため、車両３の目的地の到着予定日時がずれると、運送事業者が荷主側に与える影響は大きい。このことから、運行計画の変更時には、変更後の目的地の到着予定日時が速やかに通知されるのが好ましい。このような側面から、運行計画の変更時には、上記の運行計画の変更支援サービスを通じて、変更後の運行計画に設定された目的地の到着予定日時が通知される。

（２）バース予約システム
また、バース予約システム４０は、バースの予約を受け付けるコンピュータシステムである。ここで言う「バース」とは、荷積みや荷卸しが行われるスペースを指し、例えば、マルチテナント型の物流センタ等で提供される。例えば、バース予約システム４０は、バースへの車番や入構日時、作業時間などの必要事項の入力をＷｅｂを介して受け付け、入構日時および作業時間により定まる時間枠にバースの空きが存在する場合、当該時間枠に上記の車番の車両３に関する予約を登録する。

例えば、バース予約システム４０には、上記の運行計画作成支援サービスを通じて、運行計画に基づいた予約登録が行われる。例えば、運行計画には、車番もしくは車番と紐付けられた車両の識別情報、例えば車両ＩＤ（IDentification）が含まれる。さらに、運行計画には、運行ルート上の経由地としてバースが含まれると共にバースの到着予定日時や作業時間が含まれる。これら車番、到着予定日時および作業時間がバース予約システム４０に通知されることにより、バースの予約が登録される。

このように予約が登録された入構日時に対応する時間枠に車両３が入構できない場合、次のようなデメリットが生じる場合がある。例えば、物流センタの事業者にとっては、予約が登録された車両３が入構日時に到着しないにもかかわらず、バースを空けた状態にせねばならず、バース待ちの他の車両にバースを使用させることができないので、バースの運用が非効率になる。このような側面から、運行計画の変更時には、上記の運行計画の変更支援サービスを通じて、変更後の運行計画に設定されたバースへの到着予定日時がバース予約システム４０に通知されることにより、バースの予約の時間枠が変更される。

（３）求貨求車システム
また、求貨求車システム６０は、運送事業者から受け付ける求貨のリクエストと、荷主から受け付ける求車のリクエストとをマッチングすることにより、荷主に運送事業者の車両３を配車するシステムである。例えば、求貨のリクエストには、車両３が実車から空車になる場所および日時が含まれる一方で、求車のリクエストには、荷主が荷積みを要求する場所および日時が含まれる。

例えば、求貨求車システム６０には、上記の運行計画作成支援サービスを通じて、運行計画に基づいた求貨のリクエストが行われる。すなわち、目的地に到着した段階で車両３は実車から空車になるので、目的地および到着予定日時を求貨の条件とするマッチングのリクエストが求貨求車システム６０に行われる。この求貨のリクエストは、求貨求車システム６０により求車のリクエストとの間でマッチングされる。この結果、求貨のリクエストで指定された条件と適合する求車のリクエストの発行元である荷主に当該求貨のリクエストの発行元である運送事業者の車両３を配車することが計画される。

このように配車が計画された場合、目的地の到着予定日時に車両３が到着できない状況に陥ると、次のようなデメリットが生じる場合がある。例えば、車両３が目的地の到着予定日時に遅れる場合、求貨のリクエストで荷主により指定された場所および日時に車両３が到着できず、サプライチェーンや荷主のスケジュールに乱れが生じる。これは求貨求車システム６０を運用する事業者にとってもマッチング精度の低下を意味する。また、車両３が目的地の到着予定日時よりも前に到着する場合、到着予定日時よりも前に到着する時間の分、運行計画の作成時よりも車両３の積荷を追加する余裕が生まれるにもかかわらず、その利益を逸することになる。

このような側面から、運行計画の変更時には、上記の運行計画の変更支援サービスを通じて、変更後の運行計画に設定された目的地への到着予定日時が求貨求車システム６０に通知される。これによって、サプライチェーンや荷主のスケジュールの乱れを抑制したり、求貨求車のマッチング精度の低下を抑制したり、あるいは配車計画の作成時よりも積荷を追加したりすることができる。

［運行管理装置１０の構成］
続いて、上記の運行計画の作成支援サービスおよび上記の運行計画の変更支援サービスを提供する運行管理装置１０の機能的構成について説明する。図２は、実施例１に係る運行管理装置１０の機能的構成の一例を示すブロック図である。図２に示すように、運行管理装置１０は、通信Ｉ／Ｆ（InterFace）部１１と、記憶部１３と、制御部１５とを有する。なお、図１には、データの授受の関係を表す実線が示されているが、説明の便宜上、最小限の部分について示されているに過ぎない。すなわち、各処理部に関するデータの入出力は、図示の例に限定されず、図示以外のデータの入出力、例えば処理部及び処理部の間、処理部及びデータの間、並びに、処理部及び外部装置の間のデータの入出力が行われることとしてもかまわない。

通信Ｉ／Ｆ部１１は、他の装置、例えばデジタコ３０や運行管理者端末５０、荷主側システム２０、バース予約システム４０、求貨求車システム６０などとの間で通信制御を行うインタフェースに対応する。

一実施形態として、通信Ｉ／Ｆ部１１には、ＬＡＮカードなどのネットワークインタフェースカードなどが対応する。例えば、通信Ｉ／Ｆ部１１は、デジタコ３０から走行データを受け付けたり、運行計画の変更に関するアラートをデジタコ３０へ出力したりする。また、通信Ｉ／Ｆ部１１は、運行計画の作成または変更に関する各種のＧＵＩ（Graphical User Interface）画面を運行管理者端末５０に出力したり、画面に対する操作情報を受信したりする。

記憶部１３は、制御部１５で実行されるＯＳ（Operating System）を始め、上記の運行管理プログラム、例えばアプリケーションプログラムやミドルウェアなどの各種プログラムに用いられるデータを記憶する機能部である。

一実施形態として、記憶部１３は、運行管理装置１０における補助記憶装置として実装することができる。例えば、記憶部１３には、ＨＤＤ（Hard Disk Drive）、光ディスクやＳＳＤ（Solid State Drive）などを採用できる。なお、記憶部１３は、必ずしも補助記憶装置として実装されずともよく、運行管理装置１０における主記憶装置として実装することもできる。この場合、記憶部１３には、各種の半導体メモリ素子、例えばＲＡＭ（Random Access Memory)やフラッシュメモリを採用できる。

記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、運行計画情報１３ａと、チェックポイント計画情報１３ｂと、車両動態情報１３ｃを記憶する。

このように図２に示されたデータ以外にも、記憶部１３には、他の電子データが記憶されることとしてもかまわない。例えば、記憶部１３には、各車両に搭載されたデジタコ３０から収集された走行データ、あるいは走行データの収集および解析が実行された商用車のプローブデータ等が記憶される。また、記憶部１３には、道路地図情報の他、運行管理者端末５０に関するアカウント情報や車両３の属性情報、例えば車両ＩＤや車番、車種、最大の総重量や積載量などが記憶される。

なお、図２に示す運行計画情報１３ａ、チェックポイント計画情報１３ｂおよび車両動態情報１３ｃの説明は、各データの取得、生成または参照が行われる制御部１５の説明と合わせて行うこととする。

制御部１５は、運行管理装置１０の全体制御を行う処理部である。

一実施形態として、制御部１５は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などのハードウェアプロセッサにより実装することができる。ここでは、プロセッサの一例として、ＣＰＵやＭＰＵを例示したが、汎用型および特化型を問わず、任意のプロセッサ、例えばＧＰＵ（Graphics Processing Unit）やＤＳＰ（Digital Signal Processor）の他、ＤＬＵ（Deep Learning Unit）やＧＰＧＰＵ（General-Purpose computing on Graphics Processing Units）により実装することができる。この他、制御部１５は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによって実現されることとしてもかまわない。

制御部１５は、図示しない主記憶装置として実装されるＲＡＭのワークエリア上に、上記の運行管理プログラムを展開することにより、下記の処理部を仮想的に実現する。なお、ここでは、上記の運行管理サービスに対応する機能がパッケージ化された運行管理プログラムが実行される例を挙げたが、上記の運行計画の作成支援サービスまたは上記の運行計画の変更支援サービスなどの単位でプログラムモジュールが実行されることとしてもかまわない。

図１に示すように、制御部１５は、運行計画作成部１５ａと、動態監視部１５ｂと、第１判定部１５ｃと、第２判定部１５ｄと、再計算部１５ｅと、変更部１５ｆと、通知部１５ｇとを有する。ここで、運行計画作成部１５ａは、上記の運行計画の作成支援サービスに対応する機能を実現する処理部に対応し、動態監視部１５ｂ、第１判定部１５ｃ、第２判定部１５ｄ、再計算部１５ｅ、変更部１５ｆおよび通知部１５ｇは、上記の運行計画の変更支援サービスに対応する機能を実現する処理部に対応する。

運行計画作成部１５ａは、上記の運行計画の作成を支援する処理部である。

一実施形態として、運行計画作成部１５ａは、ログイン認証に成功した運行管理者端末５０から運行計画の作成のリクエストを受け付けると、運行計画の作成に用いる条件を指定する運行計画作成画面を運行管理者端末５０に表示させる。この運行計画作成画面には、車両３の指定、出発地および目的地の指定や目的地への到着日時の指定などを受け付けるＧＵＩコンポーネントが含まれる。また、運行計画作成画面には、積載物の有無の指定、高速道路または一般道路の優先道路の指定、連続運転時間や連続休憩時間の指定などを受け付けるＧＵＩコンポーネントが含まれることとしてもかまわない。この他、運行計画作成画面には、配車計画で定められた物流センタ等を経由地として追加するＧＵＩコンポーネントが含まれることとしてもかまわない。この運行計画作成画面を介して運行管理者端末５０から運行計画の作成の条件が指定されると、運行計画作成部１５ａは、上記の走行データを用いて、指定の条件を満たす運行ルートを算出する。

例えば、運行計画作成部１５ａは、過去の所定期間、例えば６ヶ月間の走行データを参照して、出発地の周辺地域を出発又は通過し、かつ到着日時に対応する曜日および時刻の所定の時間範囲内に目的地に到着又は通過するルートを検索する。そして、運行計画作成部１５ａは、走行データから検索されたルートのうち同一のルートをクラスタリングすることにより、同一のルートごとに当該ルートの走行回数を計数する。その上で、運行計画作成部１５ａは、走行回数が所定の閾値以上であるルートを運行ルートの候補として抽出する。このように運行ルートの候補が抽出される際、運行計画作成部１５ａは、運行計画作成画面で指定された連続運転時間や連続休憩時間などの条件に基づいて休憩地を設定することができる。

さらに、運行計画作成部１５ａは、上記のプローブデータを用いて、運行ルートの候補ごとに当該運行ルートの所要時間を算出する。ここで、上記のプローブデータは、車両３の走行時の走行データの収集およびその解析が実行されることにより得られる。ここでは、デジタルタコグラフの装着義務が課される貨物商用車を例に挙げたが、デジタコ３０に類する運行監視装置を搭載する任意の車両、すなわち自動車全般から収集される走行データを用いることができる。例えば、デジタルタコグラフの個体を識別する個体番号ごとに、時刻、位置、速度および距離などが対応付けられた走行データがモバイルネットワーク等を介してプラットフォームへ収集される。このようにデジタルタコグラフごとに収集された走行データの間で、道路が所定の単位、例えば５０ｍで区切られた道路区間、及び、時間が所定の単位、例えば時、分または秒ごとに区切られた時間区間ごとに、当該道路区間を当該時間区間に走行する車両の交通量や走行時間を集計する統計処理がプラットフォームにより実行される。このとき、プラットフォームは、デジタルタコグラフの個体番号等から車種、例えば超大型や大型、一般などを識別し、車種ごとに車両の交通量を集計することもできる。この他、プラットフォームは、進行方向ごとに車両の交通量および走行時間を集計することもできる。これによって、道路区間および時間区間ごとに車種別および進行方向別の車両走行量が対応付けられたプローブデータが得られる。

例えば、運行計画作成部１５ａは、候補とする運行ルートの出発地から目的地までの道路区間ごとに当該道路区間における走行時間を積算することにより、運行ルートの所要時間を算出する。このように走行時間を積算する際、到着日時として指定された曜日に対応する走行時間であり、かつ当該道路区間が走行される時間帯に対応する走行時間を用いることにより、所要時間を高精度に算出することができる。

その後、運行計画作成部１５ａは、運行ルートの候補ごとに当該運行ルートの所要時間の他、出発地、目的地、休憩ポイント、経由地とする物流拠点、主要な分岐などのノードおよびこれらのノードにおける予定到着日時などを含む運行計画を作成する。その上で、運行計画作成部１５ａは、運行ルートの候補ごとに作成された運行計画の中から選択を受付ける運行計画選択画面を運行管理者端末５０に表示させる。この運行計画選択画面を介して選択を受け付けた場合、運行計画作成部１５ａは、当該選択を受け付けた運行計画を運行計画情報１３ａとして記憶部１３に保存する。

このような運行計画とは別に、運行計画作成部１５ａは、運行計画に設定された運行ルートで予定と実績の比較、いわゆる予実比較を行う側面から、予実比較を実施するチェックポイントとするノード、例えば交差点等を上記の運行計画よりも細かい粒度、例えばキロポスト単位で設定する。その上で、運行計画作成部１５ａは、チェックポイントのノードごとに当該ノードの到着予定日時が対応付けられたデータをチェックポイント計画情報１３ｂとして記憶部１３に保存する。

動態監視部１５ｂは、車両３の動態監視を実行する処理部である。動態監視部１５ｂは、取得部の一例に対応する。

一実施形態として、動態監視部１５ｂは、デジタコ３０から位置情報を含む走行データが取得された場合、デジタコ３０に対応する車両３に関する車両動態情報１３ｃのエントリを更新することにより、車両３の動態監視を実現する。例えば、車両動態情報１３ｃのエントリには、図５を用いて後述する通り、緯度、経度、ノード検出時刻およびノードＮｏなどの項目が含まれる。これらの項目のデータが位置情報に基づいて最新に更新される。すなわち、動態監視部１５ｂは、デジタコ３０から位置情報を含む走行データが取得された場合、記憶部１３に記憶された車両動態情報１３ｃのエントリのうち当該デジタコ３０を搭載する車両３のエントリを識別する。その上で、動態監視部１５ｂは、当該車両３のエントリに含まれる緯度および経度をデジタコ３０から位置情報として取得された緯度および経度に更新する。さらに、動態監視部１５ｂは、図示しない道路地図情報に含まれるノードのうち、デジタコ３０から取得された位置情報を最寄りのノードにマップマッチする。その上で、動態監視部１５ｂは、マップマッチングされたノードの識別情報、例えば識別番号をノードＮｏとして上書き保存すると共に、位置情報の取得日時をノード検出時刻として上書き保存する。以下、車両動態情報１３ｃのエントリに含まれる緯度および経度のことを「現在位置」と記載し、車両動態情報１３ｃのエントリに含まれるノードのことを「現在地ノード」と記載する場合がある。

第１判定部１５ｃは、車両３が運行ルートから逸脱しているか否かを判定する処理部である。

一実施形態として、第１判定部１５ｃは、車両動態情報１３ｃのエントリが更新された場合、当該エントリに含まれる緯度および経度により識別される現在位置から所定の距離以内の範囲に車両３の運行計画に設定された運行ルートが含まれるか否かを判定する。

図３は、運行ルートの逸脱判定の一例を示す図である。図３には、車両３の運行ルートＲ１を実線の太線で示されると共に、運行ルートＲ１から逸脱したルートを破線で示し、逸脱後に再計算された運行ルートが実線で示されている。さらに、図３には、車両３の現在位置が時刻ｔ１～時刻ｔ７ごとにプロットされると共に、現在位置から所定の距離以内の範囲Ｅ１が破線で示されている。

図３に示すように、時刻ｔ１～時刻ｔ３では、車両３が運行ルートＲ１上を走行している。その後、時刻ｔ３から車両３が運行ルートＲ１からの逸脱を開始する。この時刻ｔ３の段階では、車両３の現在位置から所定の距離以内の範囲Ｅ１に運行ルートＲ１が含まれるので、運行ルートＲ１からの逸脱とは識別されない。続いて、時刻ｔ４の段階では、車両３の現在位置から所定の距離以内の範囲Ｅ１に運行ルートＲ１が含まれなくなるので、運行ルートＲ１から逸脱したと識別される。このように運行ルートＲ１からの逸脱が識別された時刻ｔ４の段階で後述の通知部１５ｇによりアラートがデジタコ３０および運行管理者端末５０に出力される。そして、時刻ｔ６の段階で時刻ｔ６の現在位置から目的地までのルートが後述の再計算部１５ｅにより再計算された上で再計算されたルートがデジタコ３０および運行管理者端末５０に出力される。その後、時刻ｔ７の段階では、再計算されたルート上を走行している。これをもって、運行ルートに復帰したと識別される。

第２判定部１５ｄは、運行計画の作成時の予定と、車両３の動態監視で得られる走行実績とのずれが所定の許容範囲外であるか否かを判定する処理部である。第２判定部１５ｄは判定部の一例に対応する。

１つの側面として、第２判定部１５ｄは、デジタコ３０から位置情報が取得された現在日時と、デジタコ３０から取得された位置情報に対応する到着予定時刻とのずれが許容範囲外であるか否かを判定する。

より具体的には、第２判定部１５ｄは、車両動態情報１３ｃのエントリに含まれる現在地ノードが更新された場合、当該現在地ノードがチェックポイント計画情報１３ｂに含まれるチェックポイントに対応するか否かを判定する。ここで、現在地ノードがチェックポイントに対応する場合、第２判定部１５ｄは、チェックポイント計画情報１３ｂのうち当該チェックポイントに対応付けられた到着予定日時と、現在時刻、すなわち車両動態情報１３ｃのエントリ内のノード検出時刻またはデジタコ３０から位置情報が取得された時刻が更新された時刻との差を算出する。

図４および図５に第２判定部が予実比較に用いるチェックポイント計画情報１３ｂおよび車両動態情報１３ｃの一例を示す。図４は、チェックポイント計画情報１３ｂの一例を示す図であり、図５は、車両動態情報１３ｃの一例を示す図である。

図４に示すチェックポイント計画情報１３ｂの例で言えば、築地市場を出発地として２０時に出発し、その後、芝、品川駅、南蒲田、鶴見駅、・・・、桜橋、梅香のチェックポイントを経由して３時２５分に目的地である大阪南港に到着する計画であることを意味する。一方、図５に示す車両動態情報１３ｃの例で言えば、車両３の現在位置が北緯３６．６２５３度および東経１３９．７３２１度であることを意味する。さらに、現在位置の最寄りの現在地ノードがノードの識別番号「３１３５」を有するので、現在地ノードが品川駅であることも意味する。加えて、当該現在地ノード「品川駅」が検出された現在時刻が２０時７分３０秒であることを意味する。

これらチェックポイント計画情報１３ｂおよび車両動態情報１３ｃの間では、現在地ノードが品川駅であるので、チェックポイント計画情報１３ｂの品川駅の到着予定日時「２０時５分３０秒」と、現在地ノード「品川駅」が検出された現在時刻「２０時７分３０秒」との差が算出される。例えば、現在時刻から到着予定日時が差し引かれることにより、その時間差として２分が算出される。このように現在時刻から到着予定日時が差し引かれる場合、運行計画の進捗が運行計画よりも遅れる場合に正の符号となる一方で、運行計画よりも早まる場合に負の符号となる。

このようにチェックポイントにおける到着予定日時および現在時刻の時間差が算出される一方で、第２判定部１５ｄは、現在位置から目的地までの残りの距離または時間に基づいて当該チェックポイントで時間差が許容される許容範囲の上限閾値を動的に設定する。

あくまで一例として、図６に示すルックアップテーブルを用いることにより、許容範囲の上限閾値を動的に設定できる。図６は、ルックアップテーブルの一例を示す図である。図６には、残りの距離および許容範囲として用いる上限閾値の対応関係が６段階で示されている。図６に示すルックアップテーブルの例で言えば、残りの距離が長いほど長い許容範囲が上限閾値として設定される用いられることを意味する。具体的には、残り距離が１０ｋｍ以上３０ｋｍ未満の範囲である場合、許容範囲の上限閾値が１５分に設定される。また、残り距離が３０ｋｍ以上５０ｋｍ未満の範囲である場合、許容範囲の上限閾値が３０分に設定される。さらに、残り距離が５０ｋｍ以上１００ｋｍ未満の範囲である場合、許容範囲の上限閾値が６０分に設定される。また、残り距離が１００ｋｍ以上２００ｋｍ未満の範囲である場合、許容範囲の上限閾値が９０分に設定される。さらに、残り距離が２００ｋｍ以上５００ｋｍ未満の範囲である場合、許容範囲の上限閾値が１２０分に設定される。また、残り距離が５００ｋｍ以上である場合、許容範囲の上限閾値が１５０分に設定される。

このように、ルックアップテーブルでは、残り距離が長くなるにしたがって長い許容範囲の上限閾値が設定される一方で、残り距離が短くなるにしたがって短い許容範囲の上限閾値が設定される。このような許容範囲の上限閾値を定義するのは、残りの距離によって運行計画の進捗の遅れをどの程度リカバリーできるのかが異なることが一因にある。なお、ここでは、あくまで一例としてルックアップテーブルを用いる場合を例示したが、残り距離が長くなるにしたがって長い許容範囲の上限閾値を導出する関数を用いて、許容範囲の上限閾値を算出することとしてもかまわない。また、ここでは、残りの距離に応じて許容範囲の上限閾値を設定する例を挙げたが、残りの時間に応じて許容範囲の上限閾値を設定することとしてもかまわない。

このように許容範囲の上限閾値が設定された後、第２判定部１５ｄは、チェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外であるか否かを判定する。なお、ここでは、チェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外であるか否かを判定する例を挙げたが、デジタコ３０から取得される現在位置と、デジタコ３０から位置情報が取得される日時に対応する運行予定のノードとのずれが許容範囲外であるか否かを判定することもできる。

再計算部１５ｅは、運行ルートおよび所要時間を再計算する処理部である。

一実施形態として、再計算部１５ｅは、第１判定部１５ｃにより運行ルートからの逸脱が判定された場合、あるいはチェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外である場合、複数の車両の走行データを用いて、車両動態情報１３ｃのエントリ内の現在位置から目的地までの運行ルートを再計算し、上記のプローブデータを用いて、当該運行ルートの所要時間を再計算する。なお、ここでは、運行ルートおよび所要時間の両方を再計算する例を挙げたが、所要時間に絞って再計算を行うこともできる。

ここで、運行管理装置１０は随時複数の車両から走行データを取得しており、その走行データに基づき地点間の所要時間を算出する。図１３は車両の走行データの一例を示す図である。車両の走行データは車両を識別する車両ＩＤ、車両の緯度及び経度、緯度経度の情報を取得した日付と時刻、及び、その時刻における車両速度とを含む。例えば、図１３には、車両ＩＤ「００１００」および車両ＩＤ「００２１０」の２つの車両、および、２０１８年８月１８日の日付に関する走行データのエントリが抜粋して示されているが、実際には多数の車両に関するエントリ、さらには、膨大な期間のエントリが走行データに含まれる。

例えば、運行管理装置１０は第一の地点から第二の地点までの所要時間を、同一の車両についての走行データの第一の地点に相当する緯度及び経度に対応する時刻と第二の地点に相当する緯度及び経度に対応する時刻との差分により算出する。運行管理装置１０は、地点間の走行データがある場合には、それぞれの所要時間の統計値、例えば平均を算出することもできる。また、運行管理装置１０は、平均を算出する時間範囲を調整することも可能である。これにより図１４に示すプローブデータを得ることができる。図１４は、プローブデータの一例を示す図である。図１４に示すように、プローブデータは、リンクを識別するリンクＮｏ、当該リンクを走行する走行データを用いる統計処理の対象とする時間帯、当該リンクの距離、及び、当該リンクの平均旅行時間を含む。図１４には、リンクＮｏ「２３１１０１３２」およびリンクＮｏ「０１３２１０８８」の２つのリンクに関するプローブデータが抜粋して示されているが、実際には多数のリンクのエントリが網羅的に含まれるデータであってよく、時間帯の粒度がさらに細かく、あるいは粗くして平均等の統計処理が行われてもかまわない。あくまで一例として、リンクＮｏ「２３１１０１３２」を例に挙げれば、リンクＮｏ「２３１１０１３２」で識別されるリンクの距離が２５５ｍであり、１５分間隔の時間帯ごとに当該リンクを走行する車両の平均走行時間が示されている。すなわち、２１時、２１時１５分、２１時３０分における平均走行時間のそれぞれが３２．３秒、２９．５秒、３１秒であることを示している。なお、ここでは、２１時、２１時１５分、２１時３０分の３つの時間帯が抜粋されているが、実際には１日２４時間分の時間帯が網羅的に集計されていることは言うまでもない。

チェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外である場合、再計算部１５ｅは、所要時間の算出に現在時刻から所定の期間、例えば１５分間以内にデジタコ３０から収集および解析が行われた他の複数の車両から取得した直近のプローブデータを用いる。これによって、所要時間の算出精度を高まることができるので、目的地への到着予定日時の推定精度も高めることができる。

さらに、チェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外である場合、再計算部１５ｅは、運行ルートの探索に用いる条件を緩和したり、降下したりすることができる。例えば、運行計画の作成時に一般道路が優先道路として指定されている場合、高速道路を優先道路に変更して運行ルートを再計算することができる。また、許容範囲の下限閾値を下回る場合、一般道路を優先道路に変更して運行ルートを再計算することができる。

変更部１５ｆは、運行計画を変更する処理部である。

一実施形態として、変更部１５ｆは、再計算部１５ｅにより運行ルートおよび所要時間が再計算された場合、再計算後の運行ルートおよび所要時間に基づいて、現在位置から目的地までに経由する休憩ポイント、物流拠点、主要な分岐などのノードおよびこれらのノードにおける予定到着日時などを含む運行計画を再作成する。その上で、変更部１５ｆは、記憶部１３に運行計画情報１３ａとして記憶された現行の運行計画と、再作成された変更後の運行計画とを含む運行計画の変更承認受付画面を運行管理者端末５０に表示させる。

図７は、変更承認受付画面の一例を示す図である。図７には、現在地ノードが中沢町のノードとなった時点で運行計画の変更のレコメンドが行われる例が示されている。図７に示すように、変更承認受付画面２００では、変更前の運行計画が画面内の左側に表示される一方で、変更後の運行計画が画面内の右側に表示される。このような変更承認受付画面２００上でＯＫボタン２００Ａが押下操作されることにより、運行計画の変更が承認される一方で、キャンセルボタン２００Ｂが押下操作されることにより、運行計画の変更が却下される。

ここで、変更後の運行計画では、現在地ノードである中沢町のノード以降の運行ルートが一新されている。具体的には、変更前の運行計画では、一般道路を優先道路として探索が行われた運行ルートが設定されているが、変更後の運行計画では、高速道路を優先道路として探索が行われた運行ルートが再設定されている。すなわち、変更後の運行計画では、浜松西のインターチェンジから福島のインターチェンジまで高速道路を走行するルートが再設定されることにより、目的地である大阪南港への到着予定日時が変更前の運行計画よりも約４０分程度早くなる。この変更承認受付画面２００の表示によって、運行管理者は、変更前の運行計画よりもコストはかかるものの、許容範囲を超える遅れをリカバリーできるばかりでなく、約４０分も早く目的地に到着できる計画変更であることを確認できる。

図８は、変更承認受付画面の一例を示す図である。図８には、現在地ノードが小田原市民会館前のノードとなった時点で運行計画の変更のレコメンドが行われる例が示されている。図８に示すように、変更承認受付画面２１０でも、変更前の運行計画が画面内の左側に表示される一方で、変更後の運行計画が画面内の右側に表示される。このような変更承認受付画面２１０上でＯＫボタン２１０Ａが押下操作されることにより、運行計画の変更が承認される一方で、キャンセルボタン２１０Ｂが押下操作されることにより、運行計画の変更が却下される。

ここで、変更後の運行計画では、変更前の運行計画と比べて、運行ルートの変更はないものの、現在地ノードである小田原市民会館前のノード以降に到着予定日時の遅れが反映されている。具体的には、変更前の運行計画では、小田原市民会館前へ２２時１０分５５１５秒に到着予定であったのが、変更後の運行計画では、現在時刻の２３時５分５０秒に変更されると共に、直近の道路および交通の状況が加味されて目的地である大阪南港へ９時４３分に到着する予定に変更されている。この変更承認受付画面２１０の表示によって、運行管理者は、目的地への到着が１時間弱遅れる見通しを日付が変わる前の段階で決断できる状況であることを確認できる。

このような運行計画の変更承認受付画面上で承認を受け付けた場合、変更部１５ｆは、再計算後の運行ルートおよび所要時間に基づいて再作成された運行計画、当該運行計画から再設定されたチェックポイントおよびその到着予定日時が対応付けられたチェックポイント計画を記憶部１３の運行計画情報１３ａおよびチェックポイント計画情報１３ｂに保存する。さらに、変更部１５ｆは、連携先のシステム２への通知時に参照される車両予定情報を変更後の運行計画に対応する到着予定日時に更新する。

通知部１５ｇは、デジタコ３０や運行管理者端末５０の他、連携先のシステム２に対する各種の通知を実行する処理部である。

一実施形態として、通知部１５ｇは、運行計画が変更された場合、荷主側システム２０やバース予約システム４０、求貨求車システム６０へ通知を行う。例えば、通知部１５ｇは、荷主側システム２０および求貨求車システム６０には、ワークエリア上に保存された車両予定情報を参照して、変更後の運行計画に設定された目的地の到着予定日時が通知される。図９は、車両予定情報の一例を示す図である。図９に示すように、車両予定情報には、車両ＩＤ、目的地の緯度、経度、到着予定日時などが含まれる。この車両予定情報にしたがって車両ＩＤ「Ａ００１０」の車両の目的地への到着予定が３時２５分であることが荷主側システム２０および求貨求車システム６０に通知される。また、通知部１５ｇは、変更後の運行計画に設定されたバースへの到着予定日時をバース予約システム４０に通知する。例えば、図８に示された運行計画の例で言えば、磐田物流センタにより運営されるバース予約システム４０に車両３の車番、入構時刻「２時３０分」および作業時間「１時間」が通知される。これにより、磐田物流センタのバース予約システム４０では予約の変更が可能となる。

［処理の流れ］
次に、本実施例に係る運行管理装置の処理の流れについて説明する。ここでは、運行管理装置１０により実行される（１）第１判定処理を説明した後に、（２）第２判定処理を説明することとする。

（１）第１判定処理
図１０は、実施例１に係る第１判定処理の手順を示すフローチャートである。この処理は、上記の運行計画の変更支援サービスが提供中である限り、反復して実行される。図１０に示すように、デジタコ３０から位置情報が取得されると（ステップＳ１０１Ｙｅｓ）、動態監視部１５ｂは、図示しない道路地図情報に含まれるノードのうち、デジタコ３０から取得された位置情報を最寄りのノードにマップマッチする（ステップＳ１０２）。

続いて、動態監視部１５ｂは、ステップＳ１０１で取得された位置情報の緯度および経度、ステップＳ１０２でマップマッチングが行われた現在時刻、ステップＳ１０２でマップマッチングが行われた現在地ノードに基づいて、車両動態情報１３ｃのエントリのうち当該デジタコ３０を搭載する車両３のエントリを更新する（ステップＳ１０３）。

そして、第１判定部１５ｃは、ステップＳ１０３で更新された車両動態情報１３ｃのエントリに含まれる緯度および経度により識別される現在位置から所定の距離以内の範囲に車両３の運行計画に設定された運行ルートが含まれるか否かを判定する（ステップＳ１０４）。ステップ１０４の処理では、運転手が運行ルートから逸脱していると判断した場合に、運転手がデジタコ３０のボタンを押すこと等により、運行ルートから逸脱している状況をデジタコ３０に入力することもできる。なお、現在位置から所定の距離以内の範囲に運行ルートが含まれる場合（ステップＳ１０４Ｎｏ）、ステップ１０１の処理へ移行する。

このとき、現在位置から所定の距離以内の範囲に運行ルートが含まれない場合（ステップＳ１０４Ｙｅｓ）、車両３が運行ルートから逸脱したと識別される。この場合、通知部１５ｇは、運行ルートからの逸脱を携行するアラートをデジタコ３０および運行管理者端末５０に出力する（ステップＳ１０５）。そして、再計算部１５ｅは、現在位置から目的地までのルートを再計算する（ステップＳ１０６）。その後、通知部１５ｇは、ステップＳ１０６で再計算されたルートをデジタコ３０および運行管理者端末５０に出力し（ステップＳ１０７）、ステップＳ１０１の処理へ移行する。

このように既存の動態監視を発展させて運行ルートからの逸脱が監視される。

（２）第２判定処理
図１１は、実施例１に係る第２判定処理の手順を示すフローチャートである。この処理は、一例として、上記の運行計画の変更支援サービスが提供中である限り、反復して実行される。図１１に示すように、第２判定部１５ｄは、車両動態情報１３ｃのエントリに含まれる現在地ノードが更新されたか否かを監視する（ステップＳ３０１）。そして、現在地ノードが更新された場合（ステップＳ３０１Ｙｅｓ）、第２判定部１５ｄは、当該現在地ノードがチェックポイント計画情報１３ｃに含まれるチェックポイントに対応するか否かを判定する（ステップＳ３０２）。

ここで、現在地ノードがチェックポイントに対応する場合（ステップＳ３０２Ｙｅｓ）、第２判定部１５ｄは、チェックポイント計画情報１３ｂのうち当該チェックポイントに対応付けられた到着予定日時と、現在時刻、すなわち車両動態情報１３ｃのエントリ内のノード検出時刻が更新された時刻との差を算出する（ステップＳ３０３）。その上で、第２判定部１５ｄは、チェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外であるか否かを判定する（ステップＳ３０４）。

このとき、チェックポイントにおける到着予定日時および現在時刻の時間差が許容範囲外である場合（ステップＳ３０４Ｙｅｓ）、再計算部１５ｅは、複数の車両の走行データを用いて、車両動態情報１３ｃのエントリ内の現在位置から目的地までの運行ルートを再計算すると共に、上記のプローブデータを用いて当該運行ルートの所要時間を再計算する（ステップＳ３０５）。

続いて、変更部１５ｆは、記憶部１３に運行計画情報１３ａとして記憶された現行の運行計画と、ステップＳ３０５で再計算された運行ルートおよび所要時間に基づいて再生成された運行計画とを含む運行計画の変更承認受付画面を運行管理者端末５０に表示させる（ステップＳ３０６）。

その後、運行計画の変更承認受付画面上で承認を受け付けた場合（ステップＳ３０７Ｙｅｓ）、変更部１５ｆは、再計算後の運行ルートおよび所要時間に基づいて再作成された運行計画に基づいて運行計画およびチェックポイント計画を記憶部１３の運行計画情報１３ａおよびチェックポイント計画情報１３ｂに保存する（ステップＳ３０８）。さらに、変更部１５ｆは、連携先のシステム２への通知時に参照される車両予定情報を変更後の運行計画に対応する到着予定日時に更新する（ステップＳ３０９）。

続いて、通知部１５ｇは、変更後の運行計画に設定された目的地の到着予定日時を荷主側システム２０に通知し、変更後の運行計画に設定されたバースへの到着予定日時をバース予約システム４０に通知し、変更後の運行計画に設定された目的地の到着予定日時を求貨求車システム６０に通知する（ステップＳ３０９～ステップＳ３１１）。これらステップＳ３０９～ステップＳ３１１の処理の実行後はステップＳ３０１に移行する。

なお、図１１に示すフローチャートでは、車両動態情報１３ｃのエントリに含まれる現在地ノードが更新されることを条件に処理が起動される例を挙げたが、デジタコ３０から第２判定処理の実行を要求するリクエストを受け付けることにより、処理を起動することとしてもかまわない。

［効果の一側面］
上述してきたように、本実施例に係る運行管理装置１０は、デジタコ３０から取得される現在の位置および日時と、運行計画で定められたルートの予定位置および到着予定日時とのずれが許容範囲を超えると、運行管理者端末５０から承認を受け付けることを条件に直近の走行実績を用いて再計算されたルートおよび所要時間に基づいて運行計画を変更する運行計画の変更支援サービスを提供する。

この運行計画の変更支援サービスによって、運行計画の変更の要否の判断を始め、ルートや目的地の到着予定時間等の変更内容の決定を運行管理者個人の技量、例えば経験則などに委ねずともよくなる。それ故、運行計画の変更の要否を判断出来なかったり、運行計画の変更内容に見通しが立たなかったりする事態を抑制することができる。したがって、本実施例に係る運行管理装置１０によれば、運行計画を円滑に変更することが可能である。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［スタンドアローン］
上記の実施例１では、運行管理装置１０およびデジタコ３０のクライアントサーバシステムにおいて運行管理装置が上記の運行計画の変更サービスに対応する処理を実行する例を説明したが、変更の承認操作以外の処理はデジタコ３０でスタンドアローンで実行されることとしてもかまわない。この場合、動態監視部１５ｂ、第１判定部１５ｃ、第２判定部１５ｄ、再計算部１５ｅ、変更部１５ｆおよび通知部１５ｇなどの機能部がデジタコ３０に備わることを妨げない。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、動態監視部１５ｂ、第１判定部１５ｃ、第２判定部１５ｄ、再計算部１５ｅ、変更部１５ｆまたは通知部１５ｇを運行管理装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、動態監視部１５ｂ、第１判定部１５ｃ、第２判定部１５ｄ、再計算部１５ｅ、変更部１５ｆまたは通知部１５ｇを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の運行管理装置１０の機能を実現するようにしてもよい。

［運行管理プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１２を用いて、上記の実施例と同様の機能を有する運行管理プログラムを実行するコンピュータの一例について説明する。

図１２は、実施例１及び実施例２に係る運行管理プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１２に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０～１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１２に示すように、上記の実施例１で示した動態監視部１５ｂ、第１判定部１５ｃ、第２判定部１５ｄ、再計算部１５ｅ、変更部１５ｆおよび通知部１５ｇと同様の機能を発揮する運行管理プログラム１７０ａが記憶される。この運行管理プログラム１７０ａは、図２に示した動態監視部１５ｂ、第１判定部１５ｃ、第２判定部１５ｄ、再計算部１５ｅ、変更部１５ｆおよび通知部１５ｇの各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０から運行管理プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、運行管理プログラム１７０ａは、図１２に示すように、運行管理プロセス１８０ａとして機能する。この運行管理プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうち運行管理プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、運行管理プロセス１８０ａが実行する処理の一例として、図１０～図１１に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

なお、上記の運行管理プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に運行管理プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から運行管理プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに運行管理プログラム１７０ａを記憶させておき、コンピュータ１００がこれらから運行管理プログラム１７０ａを取得して実行するようにしてもよい。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）車載装置から位置および日時を取得し、
出発地から目的地までのルート上のノードおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される位置または日時と、前記車載装置から取得される日時に対応するノードまたは車載装置から取得される位置に対応する到着予定時刻とのずれが許容範囲外であるか否かを判定し、
前記ずれが前記許容範囲外である場合、前記車載装置から取得される日時から所定の期間内における他の車両の走行実績に基づいて前記車載装置から取得される位置から前記目的地までのルートおよび所要時間を再計算し、
再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する、
処理をコンピュータに実行させることを特徴とする運行管理プログラム。

（付記２）前記運行計画の変更後の目的地への到着予定日時を前記車載装置に通知する処理を前記コンピュータにさらに実行させることを特徴とする付記１に記載の運行管理プログラム。

（付記３）前記運行計画の変更後の目的地への到着予定日時を荷主側の装置に通知する処理を前記コンピュータにさらに実行させることを特徴とする付記１に記載の運行管理プログラム。

（付記４）求貨に関する場所および日時のリクエストと、求車に関する場所および日時のリクエストをマッチングする求貨求車システムに対し、前記運行計画の変更後の目的地への到着予定日時を前記求貨のリクエストとして通知する処理を前記コンピュータにさらに実行させることを特徴とする付記１に記載の運行管理プログラム。

（付記５）前記運行計画の変更後のバースへの到着予定日時をバースの予約を受け付けるバース予約システムに通知する処理を前記コンピュータにさらに実行させることを特徴とする付記１に記載の運行管理プログラム。

（付記６）前記許容範囲は、前記車載装置から取得される位置から前記目的地までの残りの距離または時間に応じて設定されることを特徴とする付記１に記載の運行管理プログラム。

（付記７）車載装置から位置および日時を取得し、
出発地から目的地までのルート上のノードおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される位置または日時と、前記車載装置から取得される日時に対応するノードまたは車載装置から取得される位置に対応する到着予定時刻とのずれが許容範囲外であるか否かを判定し、
前記ずれが前記許容範囲外である場合、前記車載装置から取得される日時から所定の期間内における他の車両の走行実績に基づいて前記車載装置から取得される位置から前記目的地までのルートおよび所要時間を再計算し、
再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する、
処理をコンピュータが実行することを特徴とする運行管理方法。

（付記８）前記運行計画の変更後の目的地への到着予定日時を前記車載装置に通知する処理を前記コンピュータがさらに実行することを特徴とする付記７に記載の運行管理方法。

（付記９）前記運行計画の変更後の目的地への到着予定日時を荷主側の装置に通知する処理を前記コンピュータがさらに実行することを特徴とする付記７に記載の運行管理方法。

（付記１０）求貨に関する場所および日時のリクエストと、求車に関する場所および日時のリクエストをマッチングする求貨求車システムに対し、前記運行計画の変更後の目的地への到着予定日時を前記求貨のリクエストとして通知する処理を前記コンピュータがさらに実行することを特徴とする付記７に記載の運行管理方法。

（付記１１）前記運行計画の変更後のバースへの到着予定日時をバースの予約を受け付けるバース予約システムに通知する処理を前記コンピュータがさらに実行することを特徴とする付記７に記載の運行管理方法。

（付記１２）前記許容範囲は、前記車載装置から取得される位置から前記目的地までの残りの距離または時間に応じて設定されることを特徴とする付記７に記載の運行管理方法。

（付記１３）車載装置から位置および日時を取得する取得部と、
出発地から目的地までのルート上のノードおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される位置または日時と、前記車載装置から取得される日時に対応するノードまたは車載装置から取得される位置に対応する到着予定時刻とのずれが許容範囲外であるか否かを判定する判定部と、
前記ずれが前記許容範囲外である場合、前記車載装置から取得される日時から所定の期間内における他の車両の走行実績に基づいて前記車載装置から取得される位置から前記目的地までのルートおよび所要時間を再計算する再計算部と、
再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する変更部と、
を有することを特徴とする運行管理装置。

（付記１４）前記運行計画の変更後の目的地への到着予定日時を前記車載装置に通知する通知部をさらに有することを特徴とする付記１３に記載の運行管理装置。

（付記１５）前記運行計画の変更後の目的地への到着予定日時を荷主側の装置に通知する通知部をさらに有することを特徴とする付記１３に記載の運行管理装置。

（付記１６）求貨に関する場所および日時のリクエストと、求車に関する場所および日時のリクエストをマッチングする求貨求車システムに対し、前記運行計画の変更後の目的地への到着予定日時を前記求貨のリクエストとして通知する通知部をさらに有することを特徴とする付記１３に記載の運行管理装置。

（付記１７）前記運行計画の変更後のバースへの到着予定日時をバースの予約を受け付けるバース予約システムに通知する通知部をさらに有することを特徴とする付記１３に記載の運行管理装置。

（付記１８）前記許容範囲は、前記車載装置から取得される位置から前記目的地までの残りの距離または時間に応じて設定されることを特徴とする付記１３に記載の運行管理装置。

１ 運行管理システム
２ 連携先のシステム
３ 車両
１０ 運行管理装置
１１ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ 運行計画情報
１３ｂ チェックポイント計画情報
１３ｃ 車両動態情報
１５ 制御部
１５ａ 運行計画作成部
１５ｂ 動態監視部
１５ｃ 第１判定部
１５ｄ 第２判定部
１５ｅ 再計算部
１５ｆ 変更部
１５ｇ 通知部
２０ 荷主側システム
３０ デジタコ
４０ バース予約システム
５０ 運行管理者端末
６０ 求貨求車システム

Claims (8)

1. 車載装置から位置および日時を取得し、
   出発地から目的地までのルート上のチェックポイントおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される日時と、前記車載装置から取得される位置に対応するチェックポイントの到着予定日時との時間差が、前記車載装置から取得される位置から前記目的地までの残り距離が長くなるに従って長い時間の閾値が設定される上限値を含む許容範囲外であるか否かを判定し、
   前記時間差が許容範囲外である場合、道路が所定の単位で区切られた道路区間、及び、時間が所定の単位で区切られた時間区間ごとに大型車両の走行時間および走行量が対応付けられた大型車両の走行実績のうち、前記大型車両の走行回数が所定の閾値以上であるルートの候補の出発地から目的地までの道路区間ごとに、前記目的地の到着予定日時として指定される曜日に対応する走行時間であり、かつ前記道路区間が走行される時間帯に対応する走行時間を積算することにより、新たなルートおよび所要時間を再計算し、
   再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する、
   処理をコンピュータに実行させることを特徴とする運行管理プログラム。
2. 前記運行計画の変更後の目的地への到着予定日時を前記車載装置に通知する処理を前記コンピュータにさらに実行させることを特徴とする請求項１に記載の運行管理プログラム。
3. 前記運行計画の変更後の目的地への到着予定日時を荷主側の装置に通知する処理を前記コンピュータにさらに実行させることを特徴とする請求項１または２に記載の運行管理プログラム。
4. 求貨に関する場所および日時のリクエストと、求車に関する場所および日時のリクエストをマッチングする求貨求車システムに対し、前記運行計画の変更後の目的地への到着予定日時を前記求貨のリクエストとして通知する処理を前記コンピュータにさらに実行させることを特徴とする請求項１、２または３に記載の運行管理プログラム。
5. 前記運行計画の変更後のバースへの到着予定日時をバースの予約を受け付けるバース予約システムに通知する処理を前記コンピュータにさらに実行させることを特徴とする請求項１～４のいずれか１つに記載の運行管理プログラム。
6. 前記許容範囲は、前記車載装置から取得される位置から前記目的地までの残りの時間に応じて設定されることを特徴とする請求項１～５のいずれか１つに記載の運行管理プログラム。
7. 車載装置から位置および日時を取得し、
   出発地から目的地までのルート上のチェックポイントおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される日時と、前記車載装置から取得される位置に対応するチェックポイントの到着予定日時との時間差が、前記車載装置から取得される位置から前記目的地までの残り距離が長くなるに従って長い時間の閾値が設定される上限値を含む許容範囲外であるか否かを判定し、
   前記時間差が許容範囲外である場合、道路が所定の単位で区切られた道路区間、及び、時間が所定の単位で区切られた時間区間ごとに大型車両の走行時間および走行量が対応付けられた大型車両の走行実績のうち、前記大型車両の走行回数が所定の閾値以上であるルートの候補の出発地から目的地までの道路区間ごとに、前記目的地の到着予定日時として指定される曜日に対応する走行時間であり、かつ前記道路区間が走行される時間帯に対応する走行時間を積算することにより、新たなルートおよび所要時間を再計算し、
   再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する、
   処理をコンピュータが実行することを特徴とする運行管理方法。
8. 車載装置から位置および日時を取得する取得部と、
   出発地から目的地までのルート上のチェックポイントおよび到着予定日時が対応付けられた運行計画を参照して、前記車載装置から取得される日時と、前記車載装置から取得される位置に対応するチェックポイントの到着予定日時との時間差が、前記車載装置から取得される位置から前記目的地までの残り距離が長くなるに従って長い時間の閾値が設定される上限値を含む許容範囲外であるか否かを判定する判定部と、
   前記時間差が許容範囲外である場合、道路が所定の単位で区切られた道路区間、及び、時間が所定の単位で区切られた時間区間ごとに大型車両の走行時間および走行量が対応付けられた大型車両の走行実績のうち、前記大型車両の走行回数が所定の閾値以上であるルートの候補の出発地から目的地までの道路区間ごとに、前記目的地の到着予定日時として指定される曜日に対応する走行時間であり、かつ前記道路区間が走行される時間帯に対応する走行時間を積算することにより、新たなルートおよび所要時間を再計算する再計算部と、
   再計算されたルートおよび所要時間の承認を受け付けた場合、前記承認を受け付けたルートおよび所要時間に基づいて前記運行計画を変更する変更部と、
   を有することを特徴とする運行管理装置。

Images