以下、添付図面を参照して、本願の開示する車載装置、配車管理装置、配車システムおよび配車方法の実施形態を詳細に説明する。なお、以下に示す実施形態によりこの発明が限定されるものではない。
また、以下では、実施形態に係る統合配車システム1が、1台のタクシーTが第1の配車システム2および第2の配車システム3のそれぞれから配車要求を受けることができる統合システムである場合を例に挙げて説明を行う。
まず、実施形態に係る配車方法の概要について、図1および図2を用いて説明する。図1は、本実施形態の比較例に係る配車方法の概要説明図である。また、図2は、実施形態に係る配車方法の概要説明図である。
図1に示すように、統合配車システム1は、第1の配車システム2と、第2の配車システム3とを含む。
第1の配車システム2は、たとえばタクシー会社等により運営されるシステムであり、第1の配車管理装置20を含む。第2の配車システム3は、たとえばタクシー各社と提携するアプリ提供会社等により運営されるシステムであり、第2の配車管理装置30を含む。
第1の配車管理装置20は、たとえばGPSを介して各タクシーの現在位置を把握しておき、電話等を通じたタクシー利用者からの配車依頼に応じて最適なタクシーを検索し、選出されたタクシーへ配車要求を行う装置である。
また、第2の配車管理装置30は、同じくGPSを介して各タクシーの現在位置を把握しておき、タクシー利用者の携帯端末上で動作するタクシー配車アプリを通じた配車依頼に応じて、たとえばタクシー利用者の希望に最も適うタクシーを選出し、選出されたタクシーへ配車要求を行う装置である。
ただし、比較例に係る配車方法を用いた場合、図1に示すように、1台のタクシーTが第1の配車システム2からの配車要求(以下、「第1の配車要求」という)と第2の配車システム3からの配車要求(以下、「第2の配車要求」という)をほぼ同時に受け、バッティングすることが起こりうる。
かかる場合、たとえばタクシーTのドライバーが一方の配車要求を受諾し、他方の配車要求を断れば、断られた方は新たに適したタクシーを選出せねばならず、手間がかかってしまう。
また、たとえばドライバーが故意にまたはミス等により双方の配車要求を受諾してしまった場合、タクシー利用者を長時間待たせてしまったり、タクシー側の無断キャンセルが生じたりすることが起こりうる。
そこで、実施形態に係る配車方法では、図2に示すように、第1の配車システム2および第2の配車システム3のうちから配車要求を、タクシーTのドライバーに対しては、常に1つのみ通知するようにした。
なお、図2には、第1の配車システム2からの第1の配車要求のみが、タクシーTのドライバーに対して通知される例を示している。
これにより、タクシーTのドライバーは、受諾対象となる配車要求を常に1つだけ認識することとなるので、1台のタクシーTに対し、複数の配車システムからの配車要求が重複してしまうのを防止することができる。
以下、本実施形態に係る配車方法についてより具体的に、第1の実施形態、第2の実施形態および第3の実施形態の順に説明する。
(第1の実施形態)
図3は、第1の実施形態に係る配車方法の概要説明図である。第1の実施形態に係る配車方法では、タクシーTに搭載された車載装置50が、第1の配車要求および第2の配車要求のうち、早い方を優先的にドライバーに対し通知する。車載装置50は、統合配車システム1におけるタクシーT側の端末装置である。
具体的には、図3に示すように、第1の実施形態に係る配車方法では、車載装置50がたとえば第1の配車要求の方を先行して取得した場合、車載装置50は、配車要求禁止フラグを第2の配車管理装置30へ送信し、これを設定させる。
そして、かかる配車要求禁止フラグが設定された第2の配車管理装置30は、図示略の配車要求許可フラグが車載装置50から送信され、第2の配車管理装置30に設定されるまでは、タクシーTに対する配車要求を行わない。
一方、車載装置50は、先行して取得した第1の配車要求については、タクシーTのドライバーへこれを通知する。そして、ドライバーがかかる配車要求をたとえば車載装置50を介して受諾したならば、車載装置50は、第1の配車要求に応じた迎車・実車をガイドし、タクシーTによる迎車・実車を支援する。
そして、第1の配車要求の依頼主であるタクシー利用者がタクシーTを降車し、タクシーTが空車状態となったならば、車載装置50は、前述の配車要求許可フラグを第2の配車管理装置30へ送信し、これを設定させる。また、ドライバーが第1の配車要求を受諾しなかった場合も、車載装置50は配車要求許可フラグを第2の配車管理装置30へ送信し、これを設定させる。
なお、図3に示した例では、第1の配車要求の方が先行して取得されることとしたが、第2の配車要求が先行して取得された場合には、車載装置50は、配車要求禁止フラグを第1の配車管理装置20へ送信し、これを設定させることとなる。
すなわち、第1の実施形態に係る配車方法では、先行して取得した配車要求1つのみを優先的に取り扱う排他制御を実行する。
これにより、1台のタクシーTに対し、第1の配車システム2および第2の配車システム3それぞれからの配車要求が重複してしまうのを防止することができる。
次に、図4は、第1の実施形態に係る統合配車システム1の構成例を示すブロック図である。なお、図4では、本実施形態の特徴を説明するために必要な構成要素のみを表しており、一般的な構成要素についての記載を省略している。
換言すれば、図4に図示される各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。例えば、各ブロックの分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することが可能である。なお、かかる点は、後に図7および図12に示すブロック図についても同様とする。
また、図4、後に示す図7および図12を用いた説明では、既に説明済みの構成要素については、説明を簡略するか、説明を省略する場合がある。
図4に示すように、第1の実施形態に係る統合配車システム1は、第1の配車管理装置20と、第2の配車管理装置30と、車載装置50と、携帯端末100とを含む。なお、ここで、第2の配車管理装置30は、第1の配車管理装置20とほぼ同様の構成であるものとする。
第1の配車管理装置20と、第2の配車管理装置30と、車載装置50と、携帯端末100とは、インターネットや携帯電話回線網等のネットワークNを介して相互に通信可能に設けられる。
第1の配車管理装置20から説明する。第1の配車管理装置20は、通信部11と、記憶部12と、制御部13とを備える。
通信部11は、たとえば、NIC(Network Interface Card)等によって実現される。通信部11は、ネットワークNと有線または無線で接続され、ネットワークNを介して、第2の配車管理装置30、車載装置50および携帯端末100との間で情報の送受信を行う。
なお、通信部11は、たとえば第1の配車システム2に含まれる各タクシーと携帯電話回線網等を介して直接に情報(現在位置や空車/実車状態等)の送受信を行うことも可能である。
記憶部12は、たとえば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、図4の例では、車両情報12aと、依頼情報12bと、交通情報12cと、配車要求禁止フラグ情報12dとを記憶する。
車両情報12aは、たとえば第1の配車システム2に含まれる各タクシーの状況に関する情報であり、各タクシーの現在位置や空車/実車状態等を含む。依頼情報12bは、タクシー利用者から携帯端末100を介して依頼される配車依頼に関する情報であり、配車依頼の依頼内容を含む。交通情報12cは、たとえば図示略の交通情報提供システム等から提供される交通状況に関する情報であり、渋滞情報等を含む。
配車要求禁止フラグ情報12dは、上述した配車要求禁止フラグに関する情報であり、車載装置50から配車要求禁止フラグを取得した場合には、該当するタクシーTに紐づけて配車要求禁止フラグが設定される。また、車載装置50から配車要求許可フラグを取得した場合には、該当するタクシーTに紐づけて配車要求許可フラグが設定される。
制御部13は、コントローラ(controller)であり、たとえば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、記憶部12に記憶されている図示略の各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部13は、たとえば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現することができる。
制御部13は、取得部13aと、配車制御部13bとを有し、以下に説明する情報処理の機能や作用を実現または実行する。
取得部13aは、通信部11を介して、車載装置50から送信される各タクシーの状況を取得し、車両情報12aへ格納する。また、取得部13aは、通信部11を介して、携帯端末100から送信される配車依頼を取得し、依頼情報12bへ格納する。
また、取得部13aは、通信部11を介して、図示略の交通情報提供システム等から提供される交通情報を取得し、交通情報12cへ格納する。
また、取得部13aは、車載装置50から配車要求禁止フラグが送信された場合に、通信部11を介してこれを取得し、配車要求禁止フラグ情報12dへ設定する。また、取得部13aは、車載装置50から配車要求許可フラグが送信された場合に、通信部11を介してこれを取得し、配車要求禁止フラグ情報12dへ設定する。
配車制御部13bは、車両情報12a、依頼情報12bおよび交通情報12cに基づいて配車依頼に応じた最適なタクシーTを選出する。また、配車制御部13bは、通信部11を介して、選出した該当のタクシーTに対し配車要求を送信する。配車要求には、依頼情報12bが含まれる。配車要求が送信されるまでには、(1)携帯端末100のタクシー配車アプリ(各タクシー会社(組合)専用アプリ)を通じてタクシー利用者により入力され、送信された、配車依頼に必要なデータに基づいて配車制御部13bが自動的に配車する方法がある。かかる方法では、機械学習を経て生成された学習モデル、いわゆるAI(Artificial Intelligence)を用いることも可能である。また、(2)オペレータOPが電話等を通じたタクシー利用者の発話内容に基づいてマニュアル操作で配車依頼を入力し、かかる入力に応じてディスプレイ等に表示される配車関連情報を確認しつつ、オペレータOPがデータ送信操作や音声等により配車する方法もある。また、上記(1),(2)が混在する方法もある。
次に、車載装置50について説明する。車載装置50は、通信部51と、記憶部52と、制御部53とを備える。
通信部51は、通信部11と同様に、たとえば、NIC等によって実現される。通信部51は、ネットワークNと無線で接続され、ネットワークNを介して、第1の配車管理装置20、第2の配車管理装置30および携帯端末100との間で情報の送受信を行う。
記憶部52は、記憶部12と同様に、たとえば、RAM、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、図4の例では、依頼情報52aと、地図情報52bと、交通情報52cとを記憶する。
依頼情報52aは、前述の依頼情報12bに相当する。地図情報52bは、ナビゲーションに用いられる地図のデータベースである。交通情報52cは、前述の交通情報12cに相当する。
制御部53は、制御部13と同様に、コントローラであり、たとえば、CPUやMPU等によって、記憶部52に記憶されている図示略の各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部53は、制御部13と同様に、たとえば、ASICやFPGA等の集積回路により実現することができる。
制御部53は、取得部53aと、応答制御部53bと、通知部53cとを有し、以下に説明する情報処理の機能や作用を実現または実行する。
取得部53aは、通信部51を介して、第1の配車管理装置20または第2の配車管理装置30から送信される配車要求を取得し、配車要求に含まれる依頼内容を依頼情報52aへ格納する。
応答制御部53bは、第1の配車管理装置20または第2の配車管理装置30から送信される配車要求のうち、先行して取得された配車要求を優先的に取り扱う排他制御を行う。具体的には、上述したように、応答制御部53bは、第1の配車管理装置20または第2の配車管理装置30のうち、先行して取得された配車要求の内容を、ドライバーDに向けて通知部53cに通知させる。
また、応答制御部53bは、かかる通知に対し、ドライバーDの受諾操作を受け付けた場合に、第1の配車管理装置20または第2の配車管理装置30のうち、先行して取得された配車要求を送信した一方へ受諾応答を送信する。また、応答制御部53bは、受諾した配車要求に応じた迎車・実車を図示略のディスプレイやスピーカ等を介してガイドし、タクシーTによる迎車・実車を支援する。
なお、受諾前である場合、基本的にドライバーDに選択権がある。したがって、受諾前に複数の配車要求があった場合、たとえばドライバーDは、ディスプレイ等に表示された複数の配車要求データの中から、そのうちの一つを選択する受諾操作を行うこととなる。なお、かかる選択の変形例として、たとえばドライバーDによって行われる初期動作設定により、自動的に選択が行われるようにしてもよい。自動的な選択は、たとえば表示順に行われてもよいし、複数の配車要求があった場合にいずれを選択するかの既定の設定により行われてもよい。応答制御部53bは、その選択した方に受諾応答を送信し、選択しなかった方に辞退応答を送信することとなる。
なお、他にも、応答時間制限を設けてもよい。かかる場合、配車管理装置側では、所定の応答時間内に車載装置50から受諾応答がなければ、配車要求を取り消し、別の候補となるタクシーTの車載装置50へ改めて配信要求を送信する。また、予め複数の候補に一斉に配車要求を送信しておき、最も受諾応答の早いタクシーTを配車するようにしてもよい。
また、応答制御部53bは、第1の配車管理装置20または第2の配車管理装置30のうち、先行して取得された配車要求を送信した一方に対する他方へ、配車要求禁止フラグを送信する。配車要求禁止フラグを送信された第1の配車管理装置20または第2の配車管理装置30は、配車要求禁止フラグ情報12dへ配車要求禁止フラグを設定する。そして、配車要求許可フラグが車載装置50から送信され、配車要求禁止フラグ情報12dへ設定されるまでは、該当の車載装置50に対する配車要求を行わない。
通知部53cは、図示略のディスプレイやスピーカ等の通知デバイスを介して、ドライバーDに対し、先行して取得された配車要求の内容を通知する。
第2の配車管理装置30は、第1の配車管理装置20とほぼ同様の構成であるが、携帯端末100上で動作するアプリを通じて配車依頼を受け付け、タクシー会社を問わず配車要求を車載装置50へ送信できる点が第1の配車管理装置20とは異なる。
次に、第1の実施形態に係る統合配車システム1が実行する処理の流れについて、図5を用いて説明する。図5は、第1の実施形態に係る統合配車システム1の処理シーケンスの一例を示す図である。なお、図5を用いた説明では、第1の配車要求が先行して取得され、ドライバーDがこれを受諾するものとする。
まず、第1の配車管理装置20が、携帯端末100-1を介してタクシー利用者の配車依頼を受け付けると、第1の配車管理装置20は、選出したタクシーTの車載装置50へ、第1の配車要求を送信する(ステップS101)。そして、車載装置50は、第1の配車要求を取得する(ステップS102)。
そして、車載装置50は、かかる第1の配車要求の内容をドライバーDへ通知し、ドライバーDがこれを受諾すると、受諾応答を第1の配車管理装置20へ送信する(ステップS103)。そして、第1の配車管理装置20はこの受託応答を受信し、その結果携帯端末100-1を介してタクシー利用者へ配車情報を通知する。また、当該タクシーTに対して配車要求禁止フラグを設定し、当該タクシーTが空車になるまで配車要求が行われないようにする。
なお、ドライバーDの受諾前に他の配車管理装置(たとえば第2の配車管理装置30)から配車要求があった場合は、各配車要求が車載装置50のディスプレイに表示され、ドライバーDが、希望する配車要求を選択操作する。そして、ドライバーDが選択した配車要求に対して受諾応答が送信され、他の配車要求に対しては辞退応答が送信される。たとえば、ドライバーDが第1の配車要求の選択操作を行うと、受諾応答を第1の配車管理装置20へ送信(ステップS103)することとなる。
一方、車載装置50は、第2の配車管理装置30へ配車要求禁止フラグを送信する(ステップS104)。第2の配車管理装置30は、これを取得すると(ステップS105)、配車要求禁止フラグを設定する(ステップS106)。
そして、第2の配車管理装置30は、かかる配車要求禁止フラグが設定されている間は、携帯端末100-2からの配車依頼を受けても、車載装置50に対しては、第2の配車要求を送信しない(ステップS107)。つまり、第2の配車管理装置30は、配車要求禁止フラグが設定されていない適切な条件のタクシーTに搭載された車載装置50に配車要求を行う。
そして、車載装置50は、受諾応答した第1の配車要求に応じた迎車・実車を支援する(ステップS108)。その後、第1の配車要求に応じた実車が終了すると(ステップS109)、車載装置50は、タクシーTが空車になったことを示す空車情報を第1の配車管理装置20へ送信する(ステップS110)。そして、第1の配車管理装置20はこの空車情報を受信し、当該タクシーTに対する配車要求禁止フラグを解除し、当該タクシーTに配車要求が行われるようにする。
また、車載装置50は、第2の配車管理装置30に対しては、配車要求許可フラグを送信する(ステップS111)。第2の配車管理装置30は、これを取得すると(ステップS112)、配車要求許可フラグを設定する(ステップS113)、言い換えれば配車要求禁止フラグを解除する。
上述してきたように、第1の実施形態に係る車載装置50は、取得部53aと、応答制御部53bとを備える。取得部53aは、利用者の配車依頼に基づくタクシーT(「輸送車両」の一例に相当)への配車要求を、第1の配車システム2および第2の配車システム3からそれぞれ取得可能である。応答制御部53bは、取得部53aによって取得された配車要求に対する受諾応答が第1の配車システム2および第2の配車システム3の間で排他的に可能となるように、配車要求の排他制御を実行する。
したがって、第1の実施形態に係る車載装置50によれば、1台のタクシーTに対し、第1の配車システム2および第2の配車システム3からの配車要求が重複してしまうのを防止することができる。また、受諾された配車要求以外の配車要求が、1台のタクシーTに対し要求されたままの状態で長時間維持されるのを防止することができる。すなわち、他のタクシーTへの配車要求の切り替えが適切にできなくなくなるのを防止することができる。
また、応答制御部53bは、第1の配車システム2および第2の配車システム3のうち、先行して取得された配車要求を送信した一方に対し、受諾応答が可能となるように当該配車要求の内容をタクシーTのドライバーDへ向けて通知するとともに、上記一方に対する他方に対し、配車要求禁止フラグ(「配車要求禁止」の一例に相当)を設定させる。
したがって、第1の実施形態に係る車載装置50によれば、車載装置50の主導で、配車要求の排他制御を実行することが可能となる。
(第2の実施形態)
次に、第2の実施形態について説明する。図6は、第2の実施形態に係る配車方法の概要説明図である。第2の実施形態に係る配車方法では、第1の配車システム2Aが第2の配車システム3Aの配車情報を随時取得する。そして、第1の配車システム2AのオペレータOPが、第1の配車システム2Aおよび第2の配車システム3A双方の配車状況を監視する。
そして、タクシーTの車載装置50Aが、第1の配車システム2Aおよび第2の配車システム3のいずれからの配車要求を受け付け可能であるかを、オペレータOPが監視状況および指示操作に基づいて車載装置50Aに切り替えさせる。なお、オペレータOPは、配車管理者等であってもよい。
具体的には、図6に示すように、第1の配車管理装置20Aは、第2の配車管理装置30Aから、第2の配車システム3Aの配車情報を随時取得する。そして、これに基づき、第1の配車システム2AのオペレータOPが、第1の配車システム2Aおよび第2の配車システム3A双方の配車状況を監視する。
そして、オペレータOPは、たとえば第1の配車システム2Aにおいてタクシー利用者からの配車依頼があった場合に、かかる配車依頼に応じてあるタクシーTを確保したければ、かかるタクシーTの車載装置50Aへ第1の配車システム2Aだけを配車要求の受付先として切り替えさせる切替指示を送信する。
そして、切替指示を受けた車載装置50Aは、かかる切替指示に応じて受付先システムを切り替える。第1の配車システム2Aだけを配車要求の受付先とした場合、車載装置50Aは、第2の配車システム3A側から配車要求を受けても受付不可応答を返す。
すなわち、第2の実施形態に係る配車方法では、第1の配車システム2Aおよび第2の配車システム3A双方の配車状況を監視し、監視状況に応じて車載装置50Aを一方からの配車要求のみを受け付け可能とさせる排他制御を実行する。
これにより、1台のタクシーTに対し、第1の配車システム2Aおよび第2の配車システム3Aそれぞれからの配車要求が重複してしまうのを防止することができる。
次に、図7は、第2の実施形態に係る統合配車システム1Aの構成例を示すブロック図である。なお、図7は、図4に対応しているため、図7を用いた説明では、図4と異なる点について主に説明する。
図7に示すように、第1の配車管理装置20Aは、記憶部12が配車要求禁止フラグ情報12dに代えて他システム監視情報12eを記憶する点が第1の実施形態とは異なる。また、制御部13が、監視部13cをさらに有する点が第1の実施形態とは異なる。
他システム監視情報12eは、通信部11を介して取得部13aによって取得される自システム以外の他システムの配車状況等を含む情報である。監視部13cは、かかる他システム監視情報12eの内容を、ディスプレイ等を介してオペレータOPへ提示する。
また、監視部13cは、監視状況に応じてオペレータOPから入力される指示操作を受け付け、かかる指示操作に応じたたとえば前述の切替指示を、車載装置50Aへ向けて配車制御部13bに送信させる。
また、車載装置50Aは、制御部53が、切替部53dをさらに有する点が第1の実施形態とは異なる。切替部53dは、通信部51および取得部53aを介して第1の配車管理装置20Aからの切替指示を取得した場合に、かかる切替指示に応じて応答制御部53bに受付先システムを切り替えさせる。
ここで、図8を用いて、より分かりやすく説明する。図8は、第2の実施形態に係る統合配車システム1Aの処理説明図である。ここでは、第1の配車システム2Aについてのみ専有的に受け付け可能とする例を示す。
図8に示すように、タクシー利用者から携帯端末100を通じ、配車依頼を受けたものとする。そして、かかるタクシー利用者は、第1の配車システム2Aにおけるお得意様であり、オペレータOPは、近くにいる自社のタクシーTをぜひとも確保したいと判断したものとする。
かかる場合に、オペレータOPは、第2の配車システム3Aの配車状況を含む他システム監視情報12eの内容を確認し、所望のタクシーTが空車である、すなわち他のシステムの配車要求を受諾していないことを把握できたならば、タクシーTの車載装置50Aに対し切替指示を行う。
そして、車載装置50Aは、かかる切替指示に応じて受付先システムを切り替え、たとえば該当のタクシー利用者が降車するまでの間、図8に示すように第1の配車システム2Aからのみ配車要求を受け付ける。
そして、たとえばタクシー利用者が降車したならば、車載装置50Aは、かかる第1の配車システム2Aからのみ受け付ける切り替え状態を解除する。なお、実車中は配車要求を受諾できないため、かかる解除はタクシー利用者が乗車した際に行ってもよい。
次に、第2の実施形態に係る統合配車システム1Aが実行する処理の流れについて、図9を用いて説明する。図9は、第2の実施形態に係る統合配車システム1Aの処理シーケンスの一例を示す図である。
まず、第1の配車管理装置20Aは、第2の配車管理装置30Aから配車情報を随時取得し、かかる他システムの配車状況を随時監視する(ステップS201)。このとき、第1の配車管理装置20Aは、取得した配車情報をディスプレイ等に表示する。
ここで、携帯端末100-1を介してタクシー利用者の配車依頼を受け付けたものとする。すると、オペレータOPは、配車情報に基づく所定の指示操作により、監視状況に応じて受付先システムの切り替えを指示し(ステップS202)、第1の配車管理装置20Aは、かかる切替指示を車載装置50Aへ送信する(ステップS203)。
そして、車載装置50Aは、切替指示を取得すると(ステップS204)、かかる切替指示に応じて受付先システムを切り替える(ステップS205)。
そして、第1の配車管理装置20Aは、受けていた配車依頼に応じた第1の配車要求を車載装置50Aへ送信する(ステップS206)。また、ここで、第2の配車管理装置30Aが、携帯端末100-2を介したタクシー利用者の配車依頼を受け付け、第2の配車要求を車載装置50Aへ送信したものとする(ステップS207)。
これに応じ、車載装置50Aは、第1の配車要求および第2の配車要求を取得する(ステップS208)。ただし、車載装置50Aは、ステップS205において受付先システムを第1の配車システム2へ切り替えているので、第1の配車要求に対しては受諾応答を返すが(ステップS209)、第2の配車要求に対しては受付不可応答を返す(ステップS210)。なお、仮に第1の配車要求に先行して第2の配車要求を取得しても、車載装置50Aは、受付先システムを第1の配車システム2へ切り替えているので、第2の配車要求に対しては受付不可応答を返す。
そして、車載装置50Aは、受諾応答した第1の配車要求に応じた迎車・実車を支援する(ステップS211)。その後、第1の配車要求に応じた実車が終了すると(ステップS212)、車載装置50Aは、タクシーTが空車になったことを示す空車情報を第1の配車管理装置20Aへ送信する(ステップS213)。
上述してきたように、第2の実施形態に係る第1の配車管理装置20Aは、利用者の配車依頼に基づいてタクシーTを配車する第1の配車システム2の配車管理装置であって、取得部11aと、配車制御部11bとを備える。取得部11aは、第1の配車システム2A以外の第2の配車システム3Aの配車状況を取得可能である。配車制御部11bは、取得部11aによって取得された第2の配車システム3の配車状況に基づいて、タクシーTが第1の配車システム2および第2の配車システム3のうちの一方からのみ上記配車依頼に基づく配車要求を受け付け可能となるように、配車要求の排他制御を実行する。
したがって、第2の実施形態に係る第1の配車管理装置20Aによれば、1台のタクシーTに対し、第1の配車システム2および第2の配車システム3からの配車要求が重複してしまうのを防止することができる。
また、第2の配車システム3の配車状況を監視する監視部13cをさらに備え、配車制御部13bは、第1の配車システム2の指示に基づき、監視部13cの監視状況に応じた配車要求の受付先の切替指示をタクシーTへ送信し、上記一方について専有的に配車要求を受け付け可能となるように、切替指示に基づいてタクシーTに上記受付先を切り替えさせる。第1の配車システム2の指示は、オペレータOPの操作に基づくものであってもよいし、学習モデルに基づく自動的なものであってもよいし、そのいずれを含むものであってもよい。
したがって、第2の実施形態に係る第1の配車管理装置20Aによれば、第1の配車管理装置20Aの主導で、配車要求の排他制御を実行することが可能となる。
(第3の実施形態)
次に、第3の実施形態について説明する。図10は、第3の実施形態に係る配車方法の概要説明図である。なお、図10は、図6に対応しているため、図10を用いた説明では、図6と異なる点について主に説明する。
図10に示すように、第3の実施形態に係る配車方法では、第1の配車管理装置20Bがさらに各種の環境情報を取得する点が第2の実施形態とは異なる。また、タクシーTの車載装置50Bが、第1の配車システム2Bおよび第2の配車システム3Bのいずれからの配車要求を受け付け可能であるかを、オペレータOPが監視状況、指示操作および環境情報に基づいて車載装置50Bに切り替えさせる点が第2の実施形態とは異なる。
環境情報の一例を図11に示す。図11は、環境情報の一例を示す図である。図11に示すように、環境情報は、季節や、日付、時間、予約情報、顧客分布、イベントの進行状況等を含む。
すなわち、第3の実施形態に係る配車方法では、第1の配車システム2Bおよび第2の配車システム3B双方の配車状況を監視するとともにこれらの環境情報を取得し、監視状況および環境情報に応じて車載装置50Bを一方からの配車要求のみを受け付け可能とさせる排他制御を実行する。
これにより、1台のタクシーTに対し、第1の配車システム2Bおよび第2の配車システム3Bそれぞれからの配車要求が重複してしまうのを防止することができる。
次に、図12は、第3の実施形態に係る統合配車システム1Bの構成例を示すブロック図である。なお、図12は、図7に対応しているため、図12を用いた説明では、図7と異なる点について主に説明する。
図12に示すように、第1の配車管理装置20Bは、記憶部12がさらに環境情報12fを記憶する点が第2の実施形態とは異なる。環境情報12fは、図11に示した各種の環境情報に相当し、たとえば通信部11を介して取得部13aによって取得される。また、手入力によって設定されてもよい。監視部13cは、環境情報12fの内容を、他システム監視情報12eの内容に加えてオペレータOPへ提示可能である。
また、監視部13cは、監視状況および/または環境情報12fの内容に応じてオペレータOPから入力される指示操作を受け付け、かかる指示操作に応じたたとえば前述の切替指示を、車載装置50Bへ向けて配車制御部13bに送信させる。
ここで、図13を用いて、より分かりやすく説明する。図13は、第3の実施形態に係る統合配車システム1Bの処理説明図である。ここでは、第1の配車システム2Bについてのみ専有的に受け付け可能とする例を示す。
なお、第3の実施形態では、第1,第2の実施形態のようにタクシー利用者の実際の配車依頼をトリガとするのではなく、将来の配車依頼を自社システムで受けたい場面を想定している。かかる場面は、たとえば、イベント終了時等、多くのタクシー利用者が見込め、利益の拡大を期待できる場面である。
図13に示すように、オペレータOPは、たとえば大勢の帰宅客が見込めるとして、野球のナイター終了にあわせて自社のタクシー車両を確保しておきたいと判断したものとする。
そして、オペレータOPは、たとえば環境情報12fに含まれるイベントの進行状況を確認し、ナイター終了が近づいていることを把握できたならば、複数のタクシーTの各車載装置50Bに対し、期限付き(ここでは2時間)の切替指示を行う。
そして、各車載装置50Bは、かかる切替指示に応じて受付先システムを切り替え、2時間の間、図13に示すように第1の配車システム2Bからのみ配車要求を受け付ける。
そして、2時間が経過したならば、各車載装置50Bは、かかる第1の配車システム2Aからのみ受け付ける切り替え状態を解除する。
このように、環境情報12fの内容に応じたたとえばスケジューリングを可能とすることで、アプリ提供会社等と提携しつつも、タクシー会社の経営戦略を優先した配車を適宜行うことが可能となる。
なお、図13では、イベント終了時を例に挙げたが、この他にも、たとえばお得意先の企業等の近くを走行している空車のタクシーTを、出張帰りの人が多い時間や退社時間等の狙いの時間帯に自社システムから配車したい場合等にも有効である。また、第2の実施形態で示した図8の例で、たとえばお得意様の過去の利用状況に基づいて配車依頼が予測される場合に、自社システムから配車したい場合等にも有効である。また、解除は、スケジューリングに限らず、既に述べたように、タクシー利用者の乗車時または降車時のたびに行ってもよい。また、将来の配車依頼をオペレータOPが判断するのではなく、既に述べたようにAI等を用いるようにしてもよい。
次に、第3の実施形態に係る統合配車システム1Bが実行する処理の流れについて、図14を用いて説明する。図14は、第3の実施形態に係る統合配車システム1Bの処理シーケンスの一例を示す図である。
まず、第1の配車管理装置20Bは、第2の配車管理装置30Bから配車情報を随時取得し、かかる他システムの配車状況を随時監視する(ステップS301)。
また、第1の配車管理装置20Bは随時、外部や車載装置50B等から各種の環境情報を取得する(ステップS302)。このとき、第1の配車管理装置20Bは、取得した各種の環境情報をディスプレイ等に表示する。そして、オペレータOPは、各種の環境情報に基づく所定の指示操作により、監視状況および環境情報に応じた受付先システムの切り替えを指示し(ステップS303)、第1の配車管理装置20Bは、かかる切替指示を車載装置50Bへ送信する(ステップS304)。
そして、車載装置50Bは、切替指示を取得すると(ステップS305)、かかる切替指示に応じて受付先システムを切り替える(ステップS306)。
以降の処理については、図9に示したステップS206~ステップS213と同様であるので、ここでの説明は省略する。
上述してきたように、第3の実施形態に係る第1の配車管理装置20Bにおいて、取得部13aはさらに、環境情報12fを取得可能であって、配車制御部13bは、監視部13cの監視状況および/または環境情報12fに応じた指示に基づき、上記切替指示をタクシーTへ送信する。
したがって、第3の実施形態に係る第1の配車管理装置20Bによれば、監視状況および/または環境情報12fに基づき、第1の配車管理装置20Aの主導で、配車要求の排他制御を実行することが可能となる。また、環境情報12fの内容に応じたたとえばスケジューリングを可能とすることで、アプリ提供会社等と提携しつつも、タクシー会社の経営戦略を優先した配車を適宜行うことが可能となる。
(変形例)
なお、上述した第2の実施形態および第3の実施形態では、オペレータOPの指示操作に基づいて車載装置50A,50Bへ切替指示を送信することとしたが、これに限られるものではない。たとえばオペレータOPの指示内容を学習した学習モデルを用いることによって、前述の切替指示の送信を自動化してもよい。
図15は、かかる変形例の説明図である。図15に示すように、変形例では、たとえば配車制御部13bが、他システム監視情報12eおよび/または環境情報12fに応じたオペレータOPの指示内容を適宜学習することによって学習モデルを生成・更新する。かかる学習は、たとえばディープラーニング等の機械学習のアルゴリズムを用いて行うことができる。
学習モデルは、他システム監視情報12eおよび/または環境情報12fが入力された場合に、かかる入力情報に対応する配車要求や切替指示を出力する、指示内容の推定モデルとして機能する。変形例では、配車制御部13bは、かかる学習モデルによって推定された配車要求や切替指示を、オペレータOPの指示操作によらず、自動的に車載装置50A,50Bへ送信することが可能となる。
また、上述した各実施形態では、2つの配車システム2,3を例に挙げたが、3つ以上の配車システム間においても、各実施形態は適用可能である。
また、上述した各実施形態では、車載装置50,50A,50Bが、それぞれ物理的に一体で、統合配車システム1,1A,1BにおけるタクシーT側のいわば端末装置として構成される例を挙げたが、これに限られるものではない。たとえば、車載装置50,50A,50Bは、タクシーTに搭載されたタクシー会社の専用端末と、ドライバーDが携帯するスマートフォン等の携帯端末上で動作するタクシーT向けのタクシー配車アプリとをWi-Fi(登録商標)等の通信手段で接続し、それぞれを連携動作させることによって仮想的に一体化させるようにしてもよい。
また、上述した各実施形態では、タクシーを例に挙げたが、これに限られるものではなく、利用者の配車依頼に基づいて複数の配車システムから配車要求を受けることができる輸送車両であればよい。
さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。