JP2024017971A - 情報処理装置および情報処理方法 - Google Patents

Abstract

【課題】より安全な軽車両の走行経路を探索する。【解決手段】バスの運行に関する情報である運行情報を取得し、前記運行情報に基づいて、軽車両である第一の車両の走行経路を生成する。【選択図】図１

Description

本開示は、経路案内システムに関する。

自転車にとって好適な走行経路を生成する技術がある。これに関し、例えば、特許文献１には、自転車の走りやすさに基づいて経路探索を行うことができる情報処理装置が開示されている。

特開２０１３－００３０４８号公報

本開示は、より安全な軽車両の走行経路を探索することを目的とする。

本開示の実施形態の一態様は、バスの運行に関する情報である運行情報を取得することと、前記運行情報に基づいて、軽車両である第一の車両の走行経路を生成することと、を実行する制御部を有する、情報処理装置である。

本開示の実施形態の一態様は、バスの運行に関する情報である運行情報を取得する第一のステップと、前記運行情報に基づいて、軽車両である第一の車両の走行経路を生成する第二のステップと、を含む、情報処理方法である。

また、他の態様として、上記の方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本開示によれば、より安全な軽車両の走行経路を探索することができる。

第一の実施形態に係る経路探索システムの概要図。 ユーザ装置１００の構成要素を示した図。 ユーザ装置１００から送信される乗車リクエストの一例。 サーバ装置２００の構成要素を示した図。 車両データ２０２Ｂの一例。 運行データ２０２Ｄの一例。 車載装置３００の構成要素を示した図。 車両データを送受信する処理のシーケンス図。 乗車予約を行う処理のシーケンス図。 道路リンクごとの評価値を算出する処理のフローチャート。 経路探索を行う処理のシーケンス図。

利用者からのリクエストに基づいて運行されるオンデマンドバスが知られている。オンデマンドバスは、運行経路や停留所が決まっておらず、複数の利用者からのリクエストに
基づいて、経路や乗降地点が動的に設定される交通システムである。

ところで、自転車をはじめとする軽車両にとって、バスの存在が走行安全上の支障になりうる場合が存在する。例えば、自転車が車道を通行する場合、大型車による追い越しが安全上のリスクとなる場合がある。また、バスが停留所に停車している場合、自転車がバスを安全に追い越すためには、乗降客や対向車との接触を避けるために特段の注意が必要となる。
リスクを低減させるためには、自転車を、バスの走行頻度や停車頻度がより低い経路に誘導することが好ましいが、従来技術ではこれが出来なかった。
本開示に係る情報処理装置は、かかる問題を解決する。

本開示の第一の態様に係る情報処理装置は、バスの運行に関する情報である運行情報を取得することと、前記運行情報に基づいて、軽車両である第一の車両の走行経路を生成することと、を実行する制御部を有する。

バスは、路線バスであってもよいし、利用者からのリクエストに基づいてオンデマンド運行される、オンデマンドバスであってもよい。
オンデマンドバスとは、利用者からのリクエストに応じて運行される乗合自動車である。本実施形態では、オンデマンドバスの運行経路や乗降地点は、事前に定まっておらず、利用者からのリクエストに応じて動的に決定される。

第一の態様に係る情報処理装置は、典型的には、バスの運行を管理する管理装置、または、当該管理装置から情報を取得して経路探索を行う装置である。
情報処理装置は、バスの運行に関する情報（運行情報）を取得する。運行情報は、バスの運行予定を示すデータであってもよいし、バスの運行実績を示すデータであってもよい。これらのデータは、走行経路に関する情報を含んでいてもよいし、停留所に関する情報を含んでいてもよい。
また、運行情報は、バスに搭載された車載装置から取得してもよし、バスの運行を管理する装置またはデータベースから取得してもよい。

情報処理装置は、バスの運行情報に基づいて、第一の車両の走行経路を生成することができる。第一の車両は、例えば、自転車をはじめとする軽車両であることが好ましい。
これにより、例えば、走行中または停車中のバスに遭遇する可能性がより低い経路に第一の車両を誘導することができ、第一の車両の走行安全性を向上させることができる。

なお、制御部は、複数の道路リンクに、バスの運行に関する評価値を関連付けたマップを生成してもよい。評価値は、例えば、バスが通過する頻度を表す値であってもよいし、利用者の乗降のためにバスが停車する頻度を表す値であってもよい。

なお、経路探索を行う際は、制御部が、バスが通過する頻度がより低い、または、バスが利用者の乗降のために停車する頻度がより低い複数の道路リンクを選択してもよい。

また、制御部は、マップを時間帯別に生成してもよい。時間帯に適合したマップを利用することで、経路探索の精度をより向上させることができる。

以下、本開示の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは開示の技術的範囲をそれらのみに限定する趣旨のものではない。

（第一の実施形態）
第一の実施形態に係る経路探索システムの概要について、図１を参照しながら説明する。本実施形態に係る経路探索システムは、車載装置３００が搭載された車両１０と、ユーザ装置１００と、サーバ装置２００とを含んで構成される。システムに含まれる車両１０（車載装置３００）は複数であってもよい。
なお、本実施形態では、オンデマンドバスに乗車する利用者が所持する装置をユーザ装置１００Ａと称し、自転車の経路探索を行う装置をユーザ装置１００Ｂと称するが、双方は同一の構成を有する装置であってもよい。双方を区別する必要がない場合、ユーザ装置１００と称する。

車両１０は、車載装置３００を搭載したオンデマンドバスである。オンデマンドバスは、利用者からの乗車リクエストに応じて運行される乗合自動車である。車両１０は、乗務員が運転する車両であってもよいし、自律走行車両であってもよい。車載装置３００は、サーバ装置２００と無線通信可能に構成される。本明細書では、車両１０のことをオンデマンドバス、または、単にバスと称する。

オンデマンドバスへの乗車を希望する利用者は、ユーザ装置１００Ａを介して、乗車リクエストをサーバ装置２００に送信する。乗車リクエストは、例えば、乗車希望地点、乗車希望時刻、降車希望地点などを含む。

これらの情報は、例えば、ユーザ装置１００Ａにインストールされた、経路探索システムを利用するためのアプリケーションソフトウェアによって生成および送信されることができる。ただし、これらの情報は、必ずしも携帯端末を利用して生成されなくてもよい。例えば、ネットワークに接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、またはウェアラブルコンピュータ等）やパーソナルコンピュータを利用して生成されてもよい。

サーバ装置２００は、ユーザ装置１００Ａから送信された乗車リクエストに基づいて、オンデマンドバスの運行計画を生成する。運行計画とは、例えば、運行経路、利用者を乗降させる地点、および、運行スケジュールなどを含むデータである。

利用者を乗降させる地点は、サーバ装置２００が決定することができる。例えば、サーバ装置２００は、利用者が乗降を希望する地点と、バスが走行可能な道路に基づいて、当該利用者を乗降させる地点を決定する。また、複数の利用者が、互いに近隣にある複数の地点から乗車を希望し、同一方面への移動を希望している場合、サーバ装置２００は、当該複数の利用者をグループ化し、当該複数の利用者を単一の地点から乗車させてもよい。
サーバ装置２００は、利用者が乗降する地点を巡回する経路（およびそのスケジュール）を生成し、前述した運行計画を生成して、対象の車両（車載装置３００）に送信する。

車載装置３００は、サーバ装置２００から運行計画を受信する。バスが有人車両である場合、当該運行計画が乗務員に提供される。バスが無人車両である場合、当該運行計画は、バスに搭載された、自律走行を制御する装置に送信される。

さらに、本実施形態では、ユーザ装置１００Ｂが、自転車の経路探索を行うためのリクエストをサーバ装置２００に送信する。サーバ装置２００は、自装置が生成したバスの運行計画を参照し、「オンデマンドバスがどの程度の頻度で通過するか」に基づいて道路リンクの評価を行う。また、バスの運行頻度がより少ない道路リンクを優先して経路探索を行い、得られた結果をユーザ装置１００Ｂに提供する。これにより、より安全な経路に自転車を誘導させることが可能になる。

本実施形態に係る経路探索システムにおいては、複数のユーザ装置１００、サーバ装置
２００、および、車載装置３００が、ネットワークによって相互に接続される。ネットワークには、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークは、携帯電話等の電話通信網、Ｗｉ－Ｆｉ（登録商標）等の無線通信網を含んでもよい。

システムを構成する各要素について説明する。
図２は、ユーザ装置１００のシステム構成を示した図である。
ユーザ装置１００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、またはウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ装置１００は、制御部１０１、記憶部１０２、通信部１０３、入出力部１０４、および位置情報取得部１０５を含んで構成される。

制御部１０１は、ユーザ装置１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができ
る。
制御部１０１は、リクエスト部１０１１と、経路探索部１０１２の二種類の機能モジュールを有して構成される。各機能モジュールは、後述する記憶部１０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

リクエスト部１０１１は、装置の利用者から、オンデマンドバスの乗車予約を行うために必要な情報を取得し、乗車リクエストをサーバ装置２００に送信する。具体的には、リクエスト部１０１１は、後述する入出力部１０４を介して、利用者の識別子、乗車希望地点、乗車希望時刻、降車希望地点などを取得する。取得された情報は、乗車リクエストとしてサーバ装置２００へ送信される。図３は、リクエスト部１０１１によって生成された乗車リクエストの一例である。また、リクエスト部１０１１は、サーバ装置２００と対話することで、乗車予約を確定させる処理を行う。

経路探索部１０１２は、装置の利用者から、自転車の経路探索を行うために必要な情報を取得し、経路探索を行うためのリクエスト（以下、経路探索リクエスト）をサーバ装置２００に送信する。具体的には、経路探索部１０１２は、後述する入出力部１０４を介して、出発地、目的地などを取得し、これらの情報を含む経路探索リクエストを生成し、サーバ装置２００へ送信する。また、経路探索部１０１２は、サーバ装置２００から、サーバ装置２００によって生成された経路を受信し、出力する処理を行う。

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やハード
ディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリ、あるいは、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）のようなディスク記録媒体である。

通信部１０３は、ユーザ装置１００をネットワークに接続するための無線通信インタフェースである。通信部１０３は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ等の移動体通信サービスを介して、ネットワークへのアクセスを提供する。
入出力部１０４は、装置の利用者が行った入力操作を受け付け、情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

なお、本実施形態では、ユーザ装置１００Ａとユーザ装置１００Ｂを、同一の構成を有する装置であるものとしたが、双方はそれぞれ別の装置であってもよい。すなわち、オンデマンドバスへの乗車をリクエストする装置と、経路探索を行う装置がそれぞれ別にあってもよい。

次に、サーバ装置２００の構成について説明する。
サーバ装置２００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。なお、サーバ装置２００は、単一のコンピュータで構成されてもよいし、互いに連携する複数台のコンピュータによって構成されてもよい。

図４は、サーバ装置２００のシステム構成を示した図である。サーバ装置２００は、制御部２０１、記憶部２０２、および通信部２０３を含んで構成される。

制御部２０１は、サーバ装置２００が行う制御を司る演算装置である。制御部２０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部２０１は、リクエスト取得部２０１１、運行管理部２０１２、および、経路探索部２０１３の三種類の機能モジュールを有して構成される。各機能モジュールは、補助記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

リクエスト取得部２０１１は、ユーザ装置１００から送信された乗車リクエストを取得し、リクエストデータ２０２Ａとして、記憶部２０２に一時的に記憶させる。取得および記憶された乗車リクエストは、運行管理部２０１２によって利用される。

運行管理部２０１２は、オンデマンドバスの運行に関する各種指令を行う。
具体的には、運行管理部２０１２は、第一に、複数の車両１０（車載装置３００）から、バスの運行および車両１０に関するデータ（以下、車両データ）を取得し、記憶させる。これにより、サーバ装置２００は、複数の車両１０の現在位置や状態を把握することができる。
また、運行管理部２０１２は、第二に、複数のユーザ装置１００から収集した複数の乗車リクエストに基づいて、バスの運行計画を生成する。運行計画は、バスの運行経路、運行スケジュール、乗車させる利用者についての情報などを含む。バスの運行経路および運行スケジュールは、複数の乗車リクエストに含まれる利用者の希望に基づいて生成される。生成された運行計画は、運行データ２０２Ｄとして記憶されるとともに、対象の車両１０（車載装置３００）に送信される。

経路探索部２０１３は、自転車の走行に好適な経路を探索する。具体的には、ユーザ装置１００から受信した経路探索リクエストに応じて、出発地と目的地を結ぶ経路を生成し
、ユーザ装置１００に提供する。経路探索部２０１３は、通常の経路探索と同様に、複数の道路リンクに割り当てられたコスト指標（例えば、距離や通過時間など）に基づいて、出発地と目的地を結ぶ経路を生成する。

さらに、経路探索部２０１３は、コスト指標の一つとして、オンデマンドバスが通過する頻度の低さを利用して経路探索を行う。すなわち、オンデマンドバスが通過する頻度がより低い道路リンクを優先して経由するよう、経路探索を行う。
このため、経路探索部２０１３は、運行データ２０２Ｄに基づいて、対象の道路リンクをオンデマンドバスがどの程度の頻度で通過するかを表す評価値を算出し、複数の道路リンクのそれぞれに関連付ける処理を、経路探索に先立って実行する。
このように構成することで、自転車がより安全に走行できる経路を決定することができる。

記憶部２０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部２０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部２０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。
記憶部２０２には、リクエストデータ２０２Ａ、車両データ２０２Ｂ、地図データ２０２Ｃ、および、運行データ２０２Ｄが記憶される。

リクエストデータ２０２Ａは、図３に例示したような、複数のユーザ装置１００から受信した乗車リクエストの集合である。

車両データ２０２Ｂは、車載装置１００から送信された複数の車両データの集合である。
図５は車両データの一例である。車両データには、車両ＩＤ、日時情報、経路情報、位置情報、および、車両情報の各フィールドが含まれる。車両ＩＤフィールドには、車両を一意に識別する識別子が格納される。日時情報フィールドには、車両データが生成された日時が格納される。
経路情報フィールドには、バスの運行経路に関する情報が格納される。
位置情報フィールドには、バスが現在走行中である区間が格納される。位置情報は、例えば、緯度および経度によって表されてもよいし、停留所の識別子によって表されてもよい。位置情報は、例えば、「停留所Ｘ１からＸ２の間を走行中」といった情報であってもよい。
位置情報は、例えば、バス（車両１０）が有するＧＰＳモジュールを介して取得してもよいし、前述した運行関連機器から取得してもよい。例えば、運行関連機器から取得したデータに基づいて、走行中である区間を判定してもよい。
車両情報フィールドには、オンデマンドバスの車両に関する情報が格納される。車両に関する情報は、例えば、バスのタイプ（ノンステップバス等）や、バスが有する設備（車椅子用スペース、車椅子用スロープ等）に関する情報であってもよい。
なお、格納された車両データ２０２Ｂは、所定のタイミング（例えば、受信してから所定の時間が経過したタイミング）で削除されてもよい。

地図データ２０２Ｃは、道路リンクの集合によって表された道路地図データである。複数の道路リンクのそれぞれには、距離、通過時間、または交通量といった情報が関連付いていてもよい。さらに、地図データ２０２Ｃは、リアルタイムの交通状況が反映されたデータであってもよい。リアルタイムの交通状況は、例えば、外部装置から周期的に取得されたデータに基づいて周期的にアップデートされてもよい。

運行データ２０２Ｄは、複数の乗車リクエストに基づいて運行管理部２０１２が生成し
た、バスの運行計画の集合である。
図６は、運行データ２０２Ｄの一例である。図示したように、運行データ２０２Ｄには、運行を一意に識別する識別子（運行ＩＤ）、車両の識別子（車両ＩＤ）、バスが経由する地点、その通過時刻、および、乗車する利用者に関する情報（利用者情報）などが含まれる。利用者情報には、利用者の識別子、乗車予約の識別子、乗車地点、および、降車地点などが含まれる。
なお、運行データ２０２Ｄは、将来における運行計画のみを含むデータであってもよいし、過去の運行実績をも含むデータであってもよい。

通信部２０３は、サーバ装置２００をネットワークに接続するための通信インタフェースである。通信部２０３は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。

ここで、経路探索部２０１３が提供する機能について、より詳しく説明する。
経路探索部２０１３は、ユーザ装置１００から受信した経路探索リクエストに基づいて、自転車に好適な経路を生成する。
経路探索部２０１３は、第一に、運行データ２０２Ｄに基づいて、複数の道路リンクに対して評価値を付与する。本実施形態では、評価値とは、オンデマンドバスの走行頻度に関連付いた値である。例えば、ある道路リンクにおいて、過去の所定期間においてバスが通過した頻度が低いほど、高い評価値が付与される。
評価値の付与は、所定の周期で、全ての道路リンクに対して行われる。

経路探索部２０１３は、第二に、複数の道路リンクに付与された評価値をコスト指標の一つとして扱い、経路探索を行う。一般的に、経路探索は、所要時間や距離をコスト指標として用いて実行される。本実施形態では、経路探索部２０１３は、これに加え、付与された評価値をコスト指標の一つとする。これにより、オンデマンドバスが走行する頻度がより低い道路リンクの集合を生成することが可能になる。

次に、車載装置３００の構成について説明する。
車載装置３００は、オンデマンドバス（車両１０）に搭載されたコンピュータである。車載装置３００は、サーバ装置２００と通信することで、運行に関する情報のやり取りを行う。
車載装置３００は、バスの乗員または乗客に情報を提供する装置を兼ねていてもよい。例えば、車載装置３００は、乗客に対して案内を行う機器（以下、運行関連機器）であってもよい。運行関連機器として、例えば、バスが有する行先表示機や放送装置を制御する機器が挙げられる。
また、車載装置３００は、車両プラットフォームが有する電子制御ユニット（ＥＣＵ）であってもよい。また、車載装置３００は、通信機能を有するデータコミュニケーションモジュール（ＤＣＭ）であってもよい。
車載装置３００は、外部ネットワークと無線通信を行う機能を有する。車載装置３００は、外部ネットワークと通信することで、交通情報や道路地図データなどをダウンロードする機能を有していてもよい。

車載装置３００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

図７は、バス（車両１０）に搭載される、車載装置３００の構成要素を詳細に示した図である。
車載装置３００は、制御部３０１、記憶部３０２、通信部３０３、および、入出力部３０４を有して構成される。

制御部３０１は、所定のプログラムを実行することで、車載装置３００の各種機能を実現する演算ユニットである。制御部３０１は、例えば、ＣＰＵ等によって実現されてもよい。制御部３０１は、記憶されたプログラムをＣＰＵによって実行することでその機能を実現してもよい。

制御部３０１は、所定のタイミングで、バスの運行および自車両に関するデータ（車両データ）を取得ないし生成し、サーバ装置２００に送信する。車両データは、例えば、経路情報（予定された運行経路）、位置情報（現在の走行位置）、車両情報などを含む。

記憶部３０２は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部３０２には、制御部３０１にて実行される各種プログラム、当該プログラムが利用するデータ等が記憶される。

通信部３０３は、無線通信を行うためのアンテナと通信モジュールを含む。アンテナは、無線信号の入出力を行うアンテナ素子である。本実施形態では、アンテナは、移動体通信（例えば、３Ｇ、ＬＴＥ、５Ｇ等の移動体通信）に適合したものである。なお、アンテナは、複数の物理的なアンテナを含んで構成されてもよい。例えば、マイクロ波やミリ波などの高周波帯の電波を利用した移動体通信を行う場合、通信の安定化を図るため、複数のアンテナを分散して配置してもよい。通信モジュールは、移動体通信を行うためのモジュールである。

入出力部３０４は、入力された操作を受け付け、情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

なお、図２、図４、および図７に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

次に、各装置が実行する処理について説明する。
図８は、車載装置３００およびサーバ装置２００が車両データを送受信する処理のシーケンス図である。図示した処理は、車両１０の走行中において、制御部３０１によって、所定の周期で繰り返し実行される。

まず、ステップＳ１１で、車載装置３００が、所定の送信周期が到来したか否かを判定する。所定の周期（例えば、１分ごと）が到来した場合、処理はステップＳ１２へ遷移する。所定の周期が到来していない場合、所定の時間だけ待機し、処理を繰り返す。
ステップＳ１２では、車載装置３００が、車両データを生成する。生成された車両データは、ステップＳ１３においてサーバ装置２００に送信される。
ステップＳ１４では、サーバ装置２００（運行管理部２０１２）が、車載装置１００から送信された車両データを受信し、記憶部２０２に格納する。
これにより、サーバ装置２００の記憶部２０２には、複数の車両１０から受信した車両データが随時蓄積されていく。

図９は、システムに含まれる各装置がインタラクションを行い、乗車予約を受け付ける処理のシーケンス図である。図示した処理は、利用者の操作に基づいて開始される。

まず、ステップＳ２１で、ユーザ装置１００（リクエスト部１０１１）が、乗車リクエストを生成する。本ステップでは、所定のインタフェースを介して、乗車希望地点、降車希望地点、乗車希望時刻などを利用者に入力させる。リクエスト部１０１１は、生成した乗車リクエストをサーバ装置２００（リクエスト取得部２０１１）に送信する。

サーバ装置２００によって取得された乗車リクエストは、サーバ装置２００において、所定のトリガが発生するまで蓄積される。トリガは、周期的（例えば、１０分おき等）に発生させてもよいし、定められた時刻に発生させてもよい。
所定のトリガが発生すると、ステップＳ２２の処理が開始される。

ステップＳ２２では、運行管理部２０１２が、所定のルールに従い、複数の乗車リクエストに基づいて、車両１０を選定したうえで、当該車両１０の運行経路および運行スケジュールを決定し、これらを含んだ運行計画を生成する。車両１０の選定は、例えば、蓄積された車両データに基づいて行うことができる。
運行計画が生成されると、運行管理部２０１２は、予約結果を案内するための情報を生成してユーザ装置１００に送信し、リクエスト部１０１１がこれを出力する（ステップＳ１３）。予約結果を案内するための情報は、例えば、乗車地点、乗車時刻、および、降車地点に関する情報を含む。これにより利用者は、乗車予約が成立したことを確認することができる。
また、運行管理部２０１２は、対象の車両１０に搭載された車載装置３００に、生成した運行計画を送信する。

次に、サーバ装置２００が、オンデマンドバスの運行計画に基づいて、複数の道路リンクに評価値を付与する処理について説明する。図１０は、サーバ装置２００（経路探索部２０１３）が、複数の道路リンクに評価値を付与する処理のフローチャートである。図示した処理は、所定のタイミングで周期的に実行される。

まず、ステップＳ３１で、記憶部２０２に記憶された運行データ２０２Ｄに基づいて、地図データ２０２Ｃに定義された複数の道路リンクのそれぞれについて、オンデマンドバスの運行頻度を算出する。運行頻度は、例えば、所定の期間（例えば、一週間）におけるバスの通過回数の合計であってもよいし、これらの平均値（例えば、一日あたりの平均通過回数）であってもよい。

次に、ステップＳ３２で、算出された運行頻度に基づいて評価値を生成し、当該評価値を、対応する道路リンクに関連付け、その結果を地図データ２０２Ｃに反映する。評価値は、ステップＳ３１で算出した値そのものであってもよいし、ステップＳ３１で算出した値に基づいてクラス分けをした結果（例えば、高頻度、中頻度、低頻度）であってもよい。
なお、道路リンクに既に評価値が付与されている場合、経路探索部２０１３は、結果を上書きしてもよいし、過去に付与された評価値との相加平均等を取り、その結果を上書きしてもよい。

次に、サーバ装置２００が、ユーザ装置１００からのリクエストに基づいて、自転車の経路探索を行う処理について説明する。
図１１は、ユーザ装置１００とサーバ装置２００がインタラクションを行い、自転車に好適な経路探索を行う処理のシーケンス図である。図示した処理は、利用者の操作に基づ
いて開始される。

まず、ステップＳ４１で、ユーザ装置１００が、経路探索リクエストを生成する。本ステップでは、経路探索部１０１２が、装置の利用者から出発地および目的地を取得し、これらを含む経路探索リクエストを生成する。生成された経路探索リクエストは、サーバ装置２００（経路探索部２０１３）へ送信される。

ステップＳ４２では、サーバ装置２００（経路探索部２０１３）が、経路探索リクエストに含まれる出発地と目的地を結ぶ経路を探索する。経路探索部２０１３は、複数の道路リンクに割り当てられたコスト指標（例えば、距離や通過時間など）に基づいて、出発地と目的地を結ぶ経路を探索する。さらに、経路探索部２０１３は、コスト指標の一つとして、オンデマンドバスが通過する頻度の低さを利用して経路探索を行う。これにより、例えば、より低い通過頻度を示している道路リンクが優先されて探索される。

ステップＳ４２で得られた経路情報は、ユーザ装置１００に送信され、ステップＳ４３において出力される。これにより、ユーザ装置１００の利用者は、自転車の走行に好適な経路を得ることができる。

以上説明したように、第一の実施形態に係る経路探索システムでは、オンデマンドバスの運行に係る情報に基づいて、サーバ装置２００が、道路リンクごとにバスの走行頻度を判定する。そして、走行頻度に基づいて生成された評価値に基づいて、よりオンデマンドバスの走行頻度が低い道路リンクを優先した経路を生成する。これにより、自転車にとって走行がより安全な経路を生成することが可能になる。

（第一の実施形態の変形例）
第一の実施形態では、サーバ装置２００が生成した運行計画に基づいて、各道路リンクにおけるオンデマンドバスの走行頻度を判定したが、走行頻度は、車両１０（車載装置３００）から収集したデータ（車両データ）に基づいて判定してもよい。車両データには、タイムスタンプ、および、車両１０の位置情報が含まれるため、ステップＳ３１においてこれを参照することで、車両１０が走行していた道路リンクを判定することができる。

（第二の実施形態）
第一の実施形態では、オンデマンドバスの走行頻度に基づいて経路探索を行ったが、経路探索を行う際の基準は、これ以外のものであってもよい。
サーバ装置２００は、運行データ２０２Ｄに基づいて、オンデマンドバスが停車する停留所の位置、当該停留所における停車時間、当該停留所において乗降した利用者の人数などを把握することができる。
そこで、第一の実施形態のステップＳ２１において、以下のような値を算出し、ステップＳ２２において、これらの値に基づいて評価値を生成するようにしてもよい。
（１）車両１０が道路リンク内において、利用者の乗降のために停車する頻度（所定期間における停車回数またはその平均値）
（２）停留所における停車時間（所定期間における停車時間の合計値またはその平均値）（３）停留所における乗降者の数（所定期間における乗降者数の合計値またはその平均値）

第二の実施形態では、このようにして求めた評価値に基づいて経路探索を行う。具体的には、車両１０が、利用者の乗降のために停車する頻度がより低い道路リンク、停車時間がより短い道路リンク、または、乗降者数がより少ない道路リンクを優先して経路探索を行う。これにより、自転車にとって走行しやすい道路リンクを抽出することが可能になる。

なお、本実施形態では、評価基準として、上述した３つの例を上げたが、これらを組み合わせてもよいし、第一の実施形態（すなわち、運行頻度を評価値として用いる形態）とこれらを組みわせてもよい。

（第三の実施形態）
第一および第二の実施形態では、所定の期間内におけるオンデマンドバスの運行実績に基づいて、道路リンクごとの評価値を算出した。一方、オンデマンドバスに対する需要は、時間帯または曜日によって変動しうる。そこで、特定の時間帯や曜日において経路探索が行われた場合に、当該時間帯、または曜日に対応する運行データを用いて、評価値を算出するようにしてもよい。

第三の実施形態では、ステップＳ２１において、経路探索を行う対象の時間帯および／または曜日を特定する。時間帯や曜日は、経路探索を行ったタイミングに対応するものであってもよいし、利用者によって指定されたものであってもよい。
時間帯は、例えば、所定のタイムゾーン（例えば、３０分ごと）に区切られたものであってもよい。また、曜日は、日曜から土曜のいずれかであってもよいし、平日、週末、休日、休前日、または祝日（公休日）のような区分であってもよい。
そして、特定された時間帯および／または曜日に対応する運行データを抽出し、バスの運行頻度等を算出する。

このように、第三の実施形態では、時間帯や曜日別に経路探索を行うことができるため、オンデマンドバスの運行頻度等をより精度よく判定することが可能になる。

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、サーバ装置２００として、オンデマンドバスの運行を管理する装置（運行管理装置）を例示したが、サーバ装置２００は、斯様な運行管理装置から情報を取得して経路探索を行う装置であってもよい。
また、実施形態の説明では、車両１０としてオンデマンドバスを例示したが、車両１０は、運行経路や運行スケジュールが定まっている路線バスであってもよい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気
カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１０・・・車両
１００・・ユーザ装置
２００・・・サーバ装置
３００・・・車載装置
１０１，２０１，３０１・・・制御部
１０２，２０２，３０２・・・記憶部
１０３，２０３，３０３・・・通信部
１０４，３０４・・・入出力部
１０５・・・位置情報取得部

Claims (20)

1. バスの運行に関する情報である運行情報を取得することと、
   前記運行情報に基づいて、軽車両である第一の車両の走行経路を生成することと、
   を実行する制御部を有する、情報処理装置。
2. 前記制御部は、前記運行情報に基づいて、前記バスが走行する頻度がより低い道路リンクを経由した前記走行経路を生成する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記運行情報に基づいて、複数の道路リンクに、前記バスの運行に関する評価値を関連付けたマップを生成し、前記評価値に基づいて前記走行経路を生成する、
   請求項１に記載の情報処理装置。
4. 前記評価値は、対応する道路リンクを前記バスが通過する頻度に関する値である、
   請求項３に記載の情報処理装置。
5. 前記運行情報は、複数の前記バスから周期的に取得した位置情報を含み、
   前記制御部は、前記位置情報に基づいて、前記道路リンクごとの前記評価値を算出する、
   請求項４に記載の情報処理装置。
6. 前記制御部は、前記バスが通過する頻度がより低い複数の道路リンクを選択することで前記走行経路を生成する、
   請求項４に記載の情報処理装置。
7. 前記評価値は、対応する道路リンクにおいて、利用者の乗降のために前記バスが停車する頻度に関する値である、
   請求項３に記載の情報処理装置。
8. 前記運行情報は、動的に設定された前記バスの停留所に関する情報を含み、
   前記制御部は、前記停留所に関する情報に基づいて、前記道路リンクごとの前記評価値を算出する、
   請求項７に記載の情報処理装置。
9. 前記制御部は、前記バスが利用者の乗降のために停車する頻度がより低い複数の道路リンクを選択することで前記走行経路を生成する、
   請求項７に記載の情報処理装置。
10. 前記制御部は、前記マップを時間帯別に生成する、
    請求項３から９のいずれか１項に記載の情報処理装置。
11. バスの運行に関する情報である運行情報を取得する第一のステップと、
    前記運行情報に基づいて、軽車両である第一の車両の走行経路を生成する第二のステップと、
    を含む、情報処理方法。
12. 前記第二のステップでは、前記運行情報に基づいて、前記バスが走行する頻度がより低い道路リンクを経由した前記走行経路を生成する、
    請求項１１に記載の情報処理方法。
13. 前記運行情報に基づいて、複数の道路リンクに、前記バスの運行に関する評価値を関連付けたマップを生成する第三のステップをさらに含み、
    前記第二のステップでは、前記評価値に基づいて前記走行経路を生成する、
    請求項１１に記載の情報処理方法。
14. 前記評価値は、対応する道路リンクを前記バスが通過する頻度に関する値である、
    請求項１３に記載の情報処理方法。
15. 前記運行情報は、複数の前記バスから周期的に取得した位置情報を含み、
    前記第三のステップでは、前記位置情報に基づいて、前記道路リンクごとの前記評価値を算出する、
    請求項１４に記載の情報処理方法。
16. 前記第二のステップでは、前記バスが通過する頻度がより低い複数の道路リンクを選択することで前記走行経路を生成する、
    請求項１４に記載の情報処理方法。
17. 前記評価値は、対応する道路リンクにおいて、利用者の乗降のために前記バスが停車する頻度に関する値である、
    請求項１３に記載の情報処理方法。
18. 前記運行情報は、動的に設定された前記バスの停留所に関する情報を含み、
    前記第三のステップでは、前記停留所に関する情報に基づいて、前記道路リンクごとの前記評価値を算出する、
    請求項１７に記載の情報処理方法。
19. 前記第二のステップでは、前記バスが利用者の乗降のために停車する頻度がより低い複数の道路リンクを選択することで前記走行経路を生成する、
    請求項１７に記載の情報処理方法。
20. 前記第三のステップでは、前記マップを時間帯別に生成する、
    請求項１３から１９のいずれか１項に記載の情報処理方法。

Images