JP2021086508A - 車載器、運転評価システム及び運行支援システム - Google Patents

Abstract

【課題】確定ルートを逸脱する行為が妥当であるかを判断可能とする車載器、運転評価システム、及び運転支援システムを提供する。【解決手段】タクシーメータシステム１０は、出発地から目的地までの経路が事前に確定されたものである確定ルートを記憶するＲＡＭ１３と、タクシー車両が確定ルートから逸脱する予定であることを示すルート変更操作を受け付ける入力部１６と、タクシー車両の現在地を示す現在地情報を取得するＧＰＳ受信器２０と、タクシー車両の運行状況に関する状況情報を収集するカメラ１９Ａ、１９Ｂと、ルート変更操作を受け付けた時点におけるタクシー車両の現在地情報と、この時点において取得された状況情報と、を対応付けた逸脱情報を生成するＣＰＵ１１と、を備える。【選択図】図２

Description

本発明は、車載器、運転評価システム及び運行支援システムに関する。

タクシー運用の形態に、事前確定運賃サービスがある。事前確定運賃サービスは、通常の、乗車距離及び時間に応じて運賃が決定される運用形態と異なり、乗客とタクシー会社とが、タクシー乗車前に、走行ルートと運賃とを確定させるものである。事前確定運賃サービスに関連する技術として、特許文献１に記載されたものがある。特許文献１に記載されたタクシーメータは、事前確定運賃と実際の走行距離に応じて算出された運賃とを比較して、低額の運賃を最終的な運賃として出力する。

一方、タクシーやトラック等の車両の運行管理を行う運送業者においては、車両の乗務員（運転者）の運転操作に対する運転評価を行っている（例えば、特許文献２参照。）。特許文献２は、運転評価を行う車載器が、通常モードに加え、良いとされる運転状態を学習するトレーニングモードを備えることを開示する。

特開２０１９−３６２８号公報 特開２０１５−１７９２５５号公報

事前確定運賃サービスによる実際の輸送では、渋滞等の理由から、乗客とタクシー会社との間で事前に確定された走行ルート（確定ルート）を逸脱することが想定される。確定ルートを逸脱する場合、その逸脱の行為が妥当であるかが問題となるが、現状では、タクシー会社（管理者）側で状況を把握することができず、妥当性を判断することができない。このため、タクシー会社において、事前確定運賃サービスを行うタクシーの乗務員による確定ルートからの逸脱行為に関する乗務員評価（運転評価）を行うことができない。

本発明は、上述した事情に鑑みてなされたものであり、その目的は、確定ルートを逸脱する行為が妥当であるかを判断可能とする車載器、運転評価システム、及び運転支援システムを提供することにある。

前述した目的を達成するために、本発明に係る車載器、運転評価システム及び運行支援システムは、下記（１）〜（８）を特徴としている。
（１） 車両に搭載された車載器であって、
出発地から目的地までの経路が事前に確定されたものである確定ルートを記憶する記憶部と、
前記車両が前記確定ルートから逸脱する予定であることを示すルート変更操作を受け付ける操作受付部と、
前記車両の現在地を示す現在地情報を取得する位置取得部と、
前記車両の運行状況に関する状況情報を収集する収集部と、
前記ルート変更操作を受け付けた時点における前記車両の現在地情報と、前記時点において取得された前記状況情報と、を対応付けた逸脱情報を生成する生成部と、
を備えることを特徴とする車載器。
（２） 前記収集部は、前記車両の周辺又は車室内を撮影した画像データを、前記状況情報として収集する撮影部であり、
前記生成部は、前記現在地情報と、前記時点において撮影された前記画像データと、を対応付けて、前記逸脱情報を生成する
ことを特徴とする上記（１）に記載の車載器。
（３） 前記車両は、乗客を輸送するタクシー車両であり、
当該車載器は、前記確定ルートでの輸送に対して事前に確定された運賃である事前確定運賃を提示する提示部を備える
ことを特徴とする上記（１）又は（２）に記載の車載器。
（４） 前記収集部は、前記乗客が携帯端末の操作によって入力したルート変更指示を受け付ける指示受付部であり、
前記生成部は、前記現在地情報と、前記時点において入力されている前記ルート変更指示と、を対応付けて、前記逸脱情報を生成する
ことを特徴とする上記（３）に記載の車載器。
（５） 前記ルート変更指示の受付後に前記車両が走行した距離に応じた運賃を算出する算出部を備え、
前記提示部は、前記距離に応じた運賃を、前記事前確定運賃とともに、又は、前記事前確定運賃に代えて、提示する
ことを特徴とする上記（４）に記載の車載器。
（６） 上記（１）から（５）のいずれか一の車載器と、前記確定ルートを走行する前記車両の運行を管理する管理装置と、を備え、
前記管理装置は、前記逸脱情報及び前記車載器が収集した運行情報に基づいて、前記車両の運転者による運転を評価する運転評価部を備える
ことを特徴とする運転評価システム。
（７） 上記（１）から（５）のいずれか一に記載の車載器と、前記確定ルートを走行する前記車両の運行を管理する、前記車載器と通信可能な管理装置と、を備え、
前記車載器は、前記逸脱情報を前記管理装置に送信する情報送信部を備え、
前記管理装置は、
前記逸脱情報を受信する受信部と、
前記逸脱情報に基づいて、前記逸脱が妥当であると判定された場合に、前記車載器にルート変更許可を送信する許可送信部と、を備える
ことを特徴とする運行支援システム。
（８） 前記車載器は、
前記車両の速度を算出する速度算出部と、
前記現在地情報及び前記速度を含む運行情報を、一定時間間隔で、前記管理装置に送信する送信部と、を備え、
前記管理装置は、
前記受信部が、前記運行情報をさらに受信し、
前記許可送信部が、前記運行情報に基づいて、前記車両が前記一定時間内に走行した距離を算出し、算出された前記距離が一定距離に満たない場合に、前記車載器に前記ルート変更許可を送信する
ことを特徴とする上記（７）に記載の運行支援システム。

上記（１）の構成の車載器によれば、生成された逸脱情報を、記録媒体に保存して管理装置で読み込むか、車載器から管理装置に送信することにより、車両の運行を管理する管理者が、逸脱情報を確認して、確定ルートの逸脱行為の妥当性を判断できる。よって、車両を運転する乗務員の指導を効果的に行うことができる。また、逸脱行為の妥当性の判断結果を、乗務員の運転評価に反映させることができる。

上記（２）の構成の車載器によれば、車両の周辺又は車室内を撮影した画像データが逸脱情報に含まれるため、ルート逸脱時の状況が、例えば、渋滞（工事渋滞、事故渋滞、自然渋滞）、運転者（乗務員）又は同乗者（乗客）の急病であるか、等を、管理者が把握できる。

上記（３）の構成の車載器によれば、乗客は、乗車中に事前確定運賃を確認できるため、一層安心して乗車できる。また、タクシー車両が事前確定運賃サービスによる輸送の実施中に確定ルートを逸脱する行為が、渋滞、急病等の理由による妥当なものであるかを検証できる。したがって、乗客とのトラブル防止に役立ち、かつ、乗務員の適切な運転評価が可能となる。

上記（４）の構成の車載器によれば、乗客自身による操作（ルート変更指示）を逸脱情報に含めることにより、逸脱行為が、乗客の指示によるものであり妥当であることを明確に記録できる。よって、事後の乗客とのトラブル解決に役立つ。

上記（５）の構成の車載器によれば、乗客によるルート変更指示後の走行に伴い発生する運賃を、乗務員及び乗客の双方が把握できる。

上記（６）の構成の運転評価システムによれば、逸脱情報に基づいて、確定ルートを逸脱した行為が妥当であったか否かを、運転評価に反映させることができるため、運転評価の精度を向上できる。

上記（７）の構成の運行支援システムによれば、無線通信を利用して、乗務員に対して、リアルタイムな指導を容易に行うことができる。よって、ルート変更が適切な場合にのみルート変更許可が送信されるので、不適切なルート変更を防止でき、乗務員と乗客とのトラブル回避が可能となる。

上記（８）の構成の運行支援システムによれば、管理装置は、算出された距離が一定距離に満たない場合、すなわち、渋滞を検知した場合に、ルート変更許可を送信するので、渋滞発生時には、車載器側で迅速にルートの変更が可能となる。

本発明によれば、逸脱情報を確認して、確定ルートの逸脱行為の妥当性を判断できる。

以上、本発明について簡潔に説明した。更に、以下に説明される発明を実施するための形態（以下、「実施形態」という。）を添付の図面を参照して通読することにより、本発明の詳細は更に明確化されるであろう。

図１は、本発明の実施形態における運行支援システムの構成を示す図である。 図２は、タクシーメータシステムの構成を示すブロック図である。 図３は、タクシーメータシステムの動作手順（パターン１）を示すフローチャートである。 図４は、タクシーメータシステムの動作手順（パターン２）を示すフローチャートである。 図５は、タクシーメータシステムの動作手順（パターン３）を示すフローチャートである。 図６は、図５の動作手順に対応する、サーバーの動作手順を示すフローチャートである。

本発明に関する具体的な実施形態について、各図を参照しながら以下に説明する。

図１は、本発明の実施形態における運行支援システム１の構成を示す図である。運行支援システム１は、タクシー車両Ｔに搭載されたタクシーメータシステム１０（車載器）と、タクシー車両Ｔの乗客Ｐが所持するスマートデバイス３０と、サーバー５０と、タクシー会社Ｍの事務所内に設置された事務所ＰＣ７０と、を備える。タクシーメータシステム１０及びスマートデバイス３０は、それぞれ、無線通信網８０を介してサーバー５０と通信可能に接続される。また、サーバー５０は、事務所ＰＣ７０と通信可能に接続される。なお、タクシーメータシステム１０と事務所ＰＣ７０とは、無線通信網８０を介して接続されていなくてもよく、その場合、事務所ＰＣ７０は、タクシーメータシステム１０で計測された運行記録データを記録したメモリカード１４Ａ（図２参照）を読み込む構成にする。

運行支援システム１において、タクシー車両Ｔは、事前確定運賃サービスを提供している。事前確定運賃サービスは、通常タクシー車両で実施される、乗車距離及び時間に応じて運賃が決定される運用形態と異なり、乗客とタクシー会社とが、乗客が乗車する前に、走行ルートと運賃とを確定させるものである。本実施形態において、乗客Ｐとタクシー会社Ｍとの間で、事前に（乗客Ｐがタクシー車両Ｔに乗車する前に）走行ルート及び運賃が決定されており、この走行ルート（以後、確定ルートという。）及び運賃はスマートデバイス３０とタクシーメータシステム１０との間で共有されている。

タクシーメータシステム１０は、タクシー車両Ｔが確定ルートを逸脱する際に、逸脱情報を生成する機能を有する。タクシーメータシステム１０の構成については、後述する。

スマートデバイス３０は、演算機能（ＣＰＵ）、記憶機能（メモリ）、通信機能、ＧＰＳ機能、操作受付機能・表示機能（タッチパネル）、音声入出力機能等を有する、携帯可能な電子機器である。スマートデバイス３０は、狭域通信機能によりタクシーメータシステム１０と通信可能であり、モバイル通信機能により無線通信網８０を介してサーバー５０と通信可能である。スマートデバイス３０を所持する乗客Ｐは、サーバー５０にアクセスし、タクシー利用アプリをダウンロード可能である。ダウンロードされたタクシー利用アプリは、スマートデバイス３０のメモリに保持され、スマートデバイス３０にインストールされる。タクシー利用アプリのインストールが終了すると、スマートデバイス３０のホーム画面には、タクシー利用アプリのアイコンが表示される。乗客Ｐがこのアイコンを押下することで、タクシー利用アプリは起動する。

乗客Ｐは、タクシーを利用する前にタクシー利用アプリを起動し、迎車を希望する地点（迎車地、出発地）及び目的地を入力する。タクシー利用アプリは、入力された迎車地から目的地までの複数の経路を検索して結果をタッチパネルに表示して、乗客Ｐに対して経路の選択を促す。タクシー利用アプリは、複数の経路のうち、乗客Ｐが選択した一の経路を走行ルートとして確定する。走行ルートの確定により、運賃も確定される。また、タクシー利用アプリは、タクシー車両Ｔが確定ルートを走行している間に、ルート変更指示を入力するための操作受付画面をタッチパネルに表示する。タクシー利用アプリは、事前確定運賃サービスが開始されタクシー車両Ｔが確定ルートを走行している間に、乗客Ｐが目的地を変更するためのルート変更操作を受け付けると、タクシーメータシステム１０にルート変更指示を送信する。

サーバー５０及び事務所ＰＣ７０は、タクシーメータシステム１０が収集した運行情報及び生成された逸脱情報をリアルタイムで受信し、タクシー車両Ｔの運行を管理する。運行情報は、タクシー車両Ｔの現在地、車速等の運行データ（運行情報）、カメラ１９Ａ、１９Ｂが撮像した画像データ等を含む。逸脱情報は、タクシー車両Ｔが確定ルートを逸脱しようとする時点（地点）及びその時の状況を示す情報である（詳細は後述する。）。サーバー５０及び事務所ＰＣ７０は、受信した逸脱情報をタクシー会社Ｍの管理者に提示して、管理者がその逸脱行為が妥当か否かを判断した結果の入力を受け付ける。サーバー５０は、逸脱が妥当であると判定された場合には、タクシーメータシステム１０に、ルート変更許可を送信する。

また、サーバー５０は、タクシーメータシステム１０から一定時間間隔で受信した運行データに基づいて、タクシー車両Ｔが一定時間内に走行した距離を算出する。サーバー５０は、算出された距離が一定距離に満たない場合には、渋滞が発生していると判断して、タクシーメータシステム１０にルート変更許可を送信する。

事務所ＰＣ７０は、上述したリアルタイムの運行管理に加え、タクシーメータシステム１０から受信した、又は、メモリカード１４Ａから読み込んだ、運行データ及び逸脱情報に基づいて、タクシー車両Ｔの乗務員による運転を評価する機能を有する。事務所ＰＣ７０は、急ブレーキの有無等といった通常の運転操作に対する評価に加え、逸脱情報に基づく妥当性判断の結果を、乗務員の評価に反映することができる。例えば、事務所ＰＣ７０又はサーバー５０から、リアルタイム判断でルート変更許可が送信されなかったにもかかわらずルート変更を実行した場合、タクシー車両Ｔが確定ルートを逸脱した行為が妥当でなかったとして、乗務員の評価を下げることができる。逸脱情報には逸脱をしようとした際の状況を示す画像データ等が含まれるため、具体的な事例を示して、乗務員を指導することができる。

無線通信網８０は、タクシーメータシステム１０及びスマートデバイス３０と広域通信を行うＬＴＥ（Long Term Evolution）網等のパケット通信網である。無線通信網８０は、タクシーメータシステム１０及びスマートデバイス３０とサーバー５０及び事務所ＰＣ７０と間で行われるデータ通信を中継する。タクシーメータシステム１０及びスマートデバイス３０と、サーバー５０及び事務所ＰＣ７０との間の通信は、４Ｇ（(4th Generation）等のモバイル通信網（携帯回線網）で行われてもよいし、無線ＬＡＮ（Local Area Network）で行われてもよい。

図２は、タクシーメータシステム１０の構成を示すブロック図である。タクシーメータシステム１０は、タクシーメータ本体５と、カメラ１９Ａ、１９Ｂと、ＧＰＳ受信器２０と、を備える。タクシーメータ本体５は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、カードリーダライタ（Ｒ／Ｗ）インターフェイス（Ｉ／Ｆ）１４、通信部２４、表示部１５、入力部１６、インターフェイス（Ｉ／Ｆ）１７Ａ、１７Ｂ、ＲＴＣ（時計ＩＣ）１８、及びナビゲーション２２を有する。Ｉ／Ｆ１７Ａには、ＧＰＳ受信器２０が接続される。Ｉ／Ｆ１７Ｂには、カメラ１９Ａ、１９Ｂが接続される。表示部１５及び入力部１６はタッチパネルＴＰを構成する。

ＣＰＵ１１は、タクシーメータ本体５の全体の動作を制御する。ＣＰＵ１１は、タクシー車両Ｔの速度を表す車速パルス信号等を入力する入力ポートを内蔵する。車速パルス信号は、車輪の回転に応じて出力される信号である。ＣＰＵ１１は、通常の賃走時（距離制運賃サービス時）においては、車速パルス信号から得られる走行距離と、ＲＴＣ１８で計時される走行時間とから、運賃を算出する。通常の賃走時、ＣＰＵ１１は、走行距離または走行時間がそれぞれ一定値に達すると、課金をアップする。また、高速道路の賃走時、ＣＰＵ１１は、走行時間による課金を停止し、走行距離による課金アップ（料金上がり）だけを行う。同様に、乗客待ち時など特定の条件下で、ＣＰＵ１１は、走行距離による課金を停止し、走行時間による課金アップだけを行ってもよい。

また、ＣＰＵ１１は、タリフの入力として、タクシーメータ本体５の筐体等に設けられた各種ボタンの選択を受け付ける。例えば、ＣＰＵ１１は、実車ボタンが選択されると、賃走時の運賃を計算し、表示部１５に賃走中のタクシー料金画面を表示する。また、ＣＰＵ１１は、タッチパネルＴＰに表示される高速ボタン、割増ボタン、割引ボタン等が選択された場合、それぞれ高速、割増、割引等のメータ状態をタクシー料金画面に表示可能である。

また、ＣＰＵ１１は、タッチパネルＴＰに表示される事前確定ボタンが選択されると、事前確定運賃サービスに関する処理を開始し、乗客Ｐとタクシー会社Ｍとの間で予め確定された運賃（確定運賃）をタクシー料金画面に表示する。事前確定運賃サービスにおいて、乗客Ｐとタクシー会社Ｍとの間で、タクシー車両Ｔの迎車地（出発地）、輸送目的地（目的地）、迎車地から輸送目的地までの走行ルート（確定ルート）、及び運賃が予め決定されている。また、これらの情報（以下、事前確定情報という。）は、スマートデバイス３０とタクシーメータシステム１０との間で共有されている。尚、事前確定運賃サービス時にも、ＣＰＵ１１は、通常の賃走時と同様に、走行距離、走行時間を計測する。

ＲＯＭ１２は、タクシーメータシステム１０の基本制御プログラム、料金算出に用いられる料金マスタファイル等を記憶する。ＲＡＭ１３は、ＣＰＵ１１が各種プログラムを実行する際のワーキングメモリとして使用され、事前確定情報を記憶する。

カードリーダライタ（Ｒ／Ｗ）インターフェイス（Ｉ／Ｆ）１４には、タクシー車両Ｔの乗務員（運転者）によって所持され、各種データの読み書きが行われるメモリカード１４Ａが挿抜自在に装着される。メモリカード１４Ａには、接触で読み書きを行うＳＤカードやＣＦ（登録商標）カード等のメモリカードの他、非接触で読み書き可能なＩＣカードや磁気カード等が用いられる。なお、このメモリカード１４Ａは、タクシー車両Ｔを管理する事務所ＰＣ７０に対しても、挿抜自在に装着可能である。

通信部２４は、広域通信を行い、無線通信網８０を介して、サーバー５０、事務所ＰＣ７０と通信を行う。また、通信部２４は、狭域通信として近距離無線（例えば、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Bluetooth（登録商標）、ZigBee（登録商標））及び無線ＬＡＮの機能を有し、スマートデバイス３０と通信可能である。なお、通信部２４は、タクシーメータ本体５と別体の通信装置として構成し、インターフェイスを介してタクシーメータ本体５と接続してもよい。

Ｉ／Ｆ１７Ａには、ＧＰＳ受信器２０が接続される。ＧＰＳ受信器２０は、ＧＰＳ衛星から送信される信号を受信し、タクシー車両Ｔの現在地（緯度、経度、高度）を算出し、ＧＰＳ位置情報（現在地情報）として出力可能である。Ｉ／Ｆ１７Ｂには、カメラ１９Ａ、１９Ｂが接続される。カメラ１９Ａは、タクシー車両Ｔに設置され、タクシー車両Ｔの周辺（外部、例えば前方）を撮像して画像データを取得する。また、カメラ１９Ｂは、タクシー車両Ｔの車内のメータ前等に設置され、乗務及び乗客Ｐを含む車室内を撮影して画像データを取得する。ＲＴＣ（時計ＩＣ）１８は現在時刻を計時する。ＲＴＣ１８によって計時される時刻は、車両の運転状態を表す走行データとともにＲＡＭ１３に記録される。

表示部１５は、前述したように、タクシーメータシステム１０における各種情報を表示する。また、入力部１６は、乗務員等による入力操作を受け付ける。本実施形態では、表示部１５と入力部１６は、タッチパネルＴＰで一体的に構成される。タッチパネルを用いた場合、乗務員がタッチパネルＴＰに表示された各種ボタンを押下することで、タクシーメータシステム１０は、入力された情報を受け付ける。なお、表示部１５と入力部１６は、別々の電子部品であってもよい。この場合、表示部は、液晶表示器（ＬＣＤ）、有機ＥＬ、プラズマディスプレイ、ＬＥＤ等の表示デバイスにより構成される。また、入力部は、タッチセンサ、タッチパッド、マウス、キーボード、トラックボール等の入力デバイスにより構成される。さらに、タッチパネルＴＰをタクシーメータ本体５と別体のタブレットとして構成し、インターフェイスを介してタクシーメータ本体５と接続してもよい。

ナビゲーション２２は、走行時、タクシー車両ＴのＧＰＳ位置情報に基づき、表示部１５に表示された地図上に現在地をマーカで描いたり、ナビゲーションを行うための入力項目を表示したり、入力部１６で入力された目的地までの経路を案内する機能を有する。また、ナビゲーション２２は、タクシー車両Ｔが事前確定運賃サービスを行う場合には、確定ルートを案内する。なお、ここでは、ナビゲーション２２は、表示部１５に表示するだけであったが、音声出力機能を有する場合、スピーカやイヤホン端子から音声案内を出力してもよい。また、ナビゲーション２２は、表示部１５とは別にナビゲーション画面を表示可能なディスプレイユニットを有してもよい。

ＣＰＵ１１は、タッチパネルＴＰに表示される確定ルート逸脱ボタンの選択により、ルート変更操作を受け付ける。ＣＰＵ１１は、ルート変更操作を受け付けた時点のタクシー車両Ｔの現在地情報と、カメラ１９Ａ、１９Ｂが取得したタクシー車両Ｔの周辺又は車室内を撮影した画像データ（タクシー車両Ｔの運行状況に関する状況情報）と、を対応付けた逸脱情報を生成する。ＣＰＵ１１は、ルート変更操作を受け付けた場合に、スマートデバイス３０からルート変更指示を受信していたときは、現在地情報と、ルート変更指示と、を対応付けた逸脱情報を生成する。生成された逸脱情報は、通信部２４によってサーバー５０及び事務所ＰＣ７０に送信されるか、又は、メモリカード１４Ａに保存される。

次に、本実施形態の運行支援システム１の動作について説明する。図３は、タクシーメータシステム１０の動作手順（パターン１）を示すフローチャートである。図４は、タクシーメータシステム１０の動作手順（パターン２）を示すフローチャートである。図５は、タクシーメータシステム１０の動作手順（パターン３）を示すフローチャートであり、図６は、図５の動作手順に対応する、サーバー５０の動作手順を示すフローチャートである。

図３は、タクシーメータシステム１０の動作手順（パターン１）を示すフローチャートである。図３は、事前確定運賃サービスの運用時にタクシー車両Ｔが確定ルートから逸脱する予定であることを、サーバー５０及び事務所ＰＣ７０側でリアルタイムに把握し、タクシー会社Ｍの管理者がタクシー車両Ｔの乗務員に対してリアルタイムで指導を行う例を示す。まず、迎車地に到着したタクシー車両Ｔに乗客Ｐが乗車すると、タクシー車両Ｔの乗務員は、乗客Ｐとの間で、目的地及び確定ルート（又は主要経由地点（幹線道路、交差点、有料道路出入口等））の確認を行う。そして、ステップＳ１において、乗務員が事前確定ボタンを押下することにより、タクシーメータシステム１０は、事前確定処理を開始する。事前確定処理において、タクシーメータシステム１０は、タクシー料金画面に、乗客Ｐとタクシー会社Ｍとの間で予め確定された確定運賃を表示し、通常の賃走時の運賃表示を行わない。乗客は、乗車中に事前確定運賃を確認できるため、一層安心して乗車できる。このとき、タクシーメータシステム１０は、通常の賃走時の運賃を計算し記憶することができる。

タクシーメータシステム１０は、タクシー車両Ｔが確定ルートを走行している間、確定ルート逸脱ボタンの押下（選択）、すなわち、ルート変更操作を待機する（ステップＳ２）。ルート変更操作において、確定ルート逸脱ボタンの押下後に、タッチパネルＴＰに複数の変更理由選択ボタン（渋滞、急病、及び乗客都合）を表示させて、該当するルート変更の理由を選択可能とすることができる。ルート変更操作があった場合、タクシーメータシステム１０は、変更理由が、渋滞によるものであるか判断し（ステップＳ３）、Ｙｅｓであればカメラ１９Ａによる車外画像撮影処理を行って（ステップＳ４）、ステップＳ５の処理に移行する。ステップＳ４においてタクシーメータシステム１０は、ルート変更操作を受け付けた時点のタクシー車両Ｔの現在地情報を取得する。そしてタクシーメータシステム１０は、この現在地情報と、カメラ１９Ａが取得したタクシー車両Ｔの周辺を撮影した画像データ（タクシー車両Ｔの運行状況に関する状況情報）と、を対応付けた逸脱情報を生成する。生成された逸脱情報は、ＲＡＭ１３に保持される。一方、ステップＳ３においてＮｏであれば、タクシーメータシステム１０は、ステップＳ５の処理に移行する。

タクシーメータシステム１０は、変更理由が乗務員又は乗客Ｐの急病によるものであるか判断する（ステップＳ５）。ステップＳ５においてＹｅｓであれば、タクシーメータシステム１０は、カメラ１９Ｂによる車内画像撮影処理を行って（ステップＳ６）、ステップＳ７の処理に進む。ステップＳ６においてタクシーメータシステム１０は、ルート変更操作を受け付けた時点のタクシー車両Ｔの現在地情報を取得する。そしてタクシーメータシステム１０は、この現在地情報と、カメラ１９Ｂが取得したタクシー車両Ｔの車室内を撮影した画像データ（タクシー車両Ｔの運行状況に関する状況情報）と、を対応付けた逸脱情報を生成する。生成された逸脱情報は、ＲＡＭ１３に保持される。ここで、ルート変更の理由として、乗務員及び乗客Ｐのいずれが急病であるかを区別して入力可能な構成としてもよい。一方、ステップＳ５においてＮｏであれば、タクシーメータシステム１０は、ステップＳ７の処理に移行する。

タクシーメータシステム１０は、変更理由が乗客Ｐの都合によるものであるか判断する（ステップＳ７）。ステップＳ７においてＹｅｓであれば、タクシーメータシステム１０は、乗客Ｐが所持するスマートデバイス３０から送信されたルート変更指示を受け付けて（ステップＳ８）、ステップＳ９の処理に進む。ステップＳ８においてタクシーメータシステム１０は、ルート変更操作を受け付けた時点のタクシー車両Ｔの現在地情報を取得する。そしてタクシーメータシステム１０は、この現在地情報と、スマートデバイス３０から入力されたルート変更指示（タクシー車両Ｔの運行状況に関する状況情報）と、を対応付けた逸脱情報を生成する。生成された逸脱情報は、ＲＡＭ１３に保持される。一方、ステップＳ７においてＮｏであれば、タクシーメータシステム１０は、ステップＳ９の処理に移行する。

タクシーメータシステム１０は、ステップＳ４、Ｓ６、及びＳ８の少なくともいずれか一で生成された逸脱情報を、サーバー５０へ送信して、ルート変更許可を要求する（ステップＳ９）。逸脱情報を受信したサーバー５０は、逸脱情報をタクシー会社Ｍの事務所ＰＣ７０に転送する。事務所ＰＣ７０は、管理者に逸脱情報を確認させ、確定ルートの逸脱行為が妥当であるか否かの判断結果を入力させる。逸脱行為が妥当であると判断された場合、事務所ＰＣ７０は、ルート変更許可通知をサーバー５０を経由してタクシーメータシステム１０に送信する。一方、逸脱行為が妥当でないと判断された場合、事務所ＰＣ７０は、ルート変更を許可しない旨の通知を、タクシーメータシステム１０に送信する。

タクシーメータシステム１０は、逸脱情報をサーバー５０へ送信した後、サーバー５０（事務所ＰＣ７０）からルート変更許可に関する通知の受信を待機する（ステップＳ１０）。通知を受信すると、タクシーメータシステム１０は、受信した通知が、ルート変更を許可するものか否かを判断する（ステップＳ１１）。受信した通知が、ルート変更を許可しない旨の通知であれば、タクシーメータシステム１０は、ルート変更が不可である旨を記録し（ステップＳ１２）、ステップＳ１４の処理に移行する。一方、受信した通知が、ルート変更許可通知であれば、タクシーメータシステム１０は、ルート変更が許可された旨を記録する（ステップＳ１３）。また、タクシーメータシステム１０は、タクシー車両Ｔによるルート変更内容（ルート変更後の走行履歴）を記憶する。

タクシーメータシステム１０は、メータ状態が空車となるまで待機し（ステップＳ１４）、メータ状態が空車となった時点で、収集したデータを確定し、メモリカード１４Ａに記録する（ステップＳ１５）。ステップＳ１５で記録されたデータ（運行データ、逸脱情報、及びルート変更が妥当であったか否かの情報）は、事務所ＰＣ７０での運転評価に用いることができる。タクシーメータシステム１０は、確定ルートの変更がなかった場合及び確定ルートの変更理由が渋滞であった場合には、メータ状態が空車となった時点で事前確定処理を終了し、確定運賃を最終的な運賃として乗客Ｐに提示する。確定ルートの変更理由が急病であった場合には、タクシーメータシステム１０は、ルート変更時点で事前確定処理を終了し、迎車地から乗客Ｐが降車した地点までの輸送について、通常の賃走時の運賃を最終的な運賃として乗客Ｐに提示する。確定ルートの変更理由が乗客都合であった場合には、タクシーメータシステム１０は、ルート変更時点で事前確定処理を終了する。そして、タクシーメータシステム１０は、確定運賃に、ルート変更時点から乗客Ｐが降車した地点までの、通常の賃走時の運賃を加えたものを、最終的な運賃として乗客Ｐに提示する。これにより、乗客によるルート変更指示後の走行に伴い発生する運賃を、乗務員及び乗客の双方が把握できる。

以上説明したように、本実施形態のタクシーメータシステム１０（パターン１）によれば、無線通信網８０を利用して、タクシー車両Ｔの乗務員に対して、リアルタイムな指導を容易に行うことができる。よって、乗務員が確定ルートを変更しようとする際、ルート変更が適切な場合にのみルート変更許可が送信されるので、不適切なルート変更を防止でき、乗務員と乗客とのトラブル回避が可能となる。特に、生成された逸脱情報には、タクシー車両Ｔの周辺又は車室内を撮影した画像データが含まれる。このため、タクシー車両Ｔの運行を管理する管理者が、逸脱情報を確認して、ルート逸脱時の状況が、例えば、渋滞（工事渋滞、事故渋滞、自然渋滞）、運転者（乗務員）又は同乗者（乗客）の急病であるか、等を把握して、確定ルートの逸脱行為の妥当性を判断できる。よって、具体的な事例に基づいて、タクシー車両Ｔを運転する乗務員の指導を効果的に行うことができる。また、後述するように、逸脱行為の妥当性の判断結果を、乗務員の運転評価に反映させることができる。

図４は、タクシーメータシステム１０の動作手順（パターン２）を示すフローチャートである。図４は、事前確定運賃サービスの運用時にタクシー車両Ｔが確定ルートから逸脱する予定であることをメモリカード１４Ａに記録し、タクシー車両Ｔの運行が終了した後に、事務所ＰＣ７０で事後的に逸脱行為の妥当性を解析する例を示す。図４のステップＳ２１からステップＳ２８の各処理は、図３のステップＳ１からステップＳ８までの各処理と同様である。タクシーメータシステム１０は、ステップＳ２４、Ｓ２６、及びＳ２８の少なくともいずれか一で生成された逸脱情報を、ＲＡＭ１３に保持する（ステップＳ２９）。タクシーメータシステム１０は、メータ状態が空車となるまで待機し（ステップＳ３０）、ステップＳ１５（図３）と同様に、メータ状態が空車となった時点で、収集したデータを確定し、メモリカード１４Ａに記録する（ステップＳ３１）。

タクシー車両Ｔの運行終了後（タクシー車両Ｔが、一日の営業を終えて、タクシー会社Ｍの事務所に戻った後）、メモリカード１４Ａは、タクシーメータシステム１０から取り外される。メモリカード１４Ａに記録されたデータ（運行データ、及び逸脱情報）は、事務所ＰＣ７０に読み込まれる。事務所ＰＣ７０は、乗務員のメモリカード１４Ａに記録されたデータを管理者に提示する。管理者は、逸脱情報を確認してルート変更が妥当であったか否かを判断し、この逸脱情報に妥当性の判断結果を紐付けて記録する。事務所ＰＣ７０は、運行データに加えて、逸脱情報及びその妥当性の判断結果を、運転評価に用いることができる。

図５は、タクシーメータシステム１０の動作手順（パターン３）を示すフローチャートである。図５及び後述する図６は、図３に示した、無線通信を利用したリアルタイムシステムにおいて、サーバー５０からタクシーメータシステム１０に、ルート変更許可を自動で送信する例を示す。図５のステップＳ４１において、図３のステップＳ１の処理と同様に、タクシーメータシステム１０は、事前確定処理を開始する。タクシーメータシステム１０は、一定時間毎に、タクシー車両Ｔの現在地情報と時刻とをサーバー５０に送信し（ステップＳ４２）、サーバー５０からルート変更許可が送信されるまで待機する（ステップＳ４３）。サーバー５０からルート変更許可を受信すると（ステップＳ４３でＹｅｓ）、タクシーメータシステム１０は、カメラ１９Ａによって外部画像データ（タクシー車両Ｔの周辺を撮影した画像データ）を収集する（ステップＳ４４）。収集された外部画像データは、サーバー５０に送信され（ステップＳ４５）、かつ、ＲＡＭ１３に保持される（ステップＳ４６）。タクシーメータシステム１０は、メータ状態が空車となるまで待機し（ステップＳ４７）、メータ状態が空車となった時点で、収集したデータを確定し、メモリカード１４Ａに記録する（ステップＳ４８）。

図６は、図５の動作手順に対応する、サーバー５０の動作手順を示すフローチャートである。ステップＳ５１において、タクシーメータシステム１０において事前確定ボタンが押下されたことがサーバー５０に通知されて、事前確定処理が開始される。事前確定処理において、サーバー５０は、確定ルートを把握し、かつ、確定ルートにおいて、設定時間毎にタクシー車両Ｔが進むと予測される設定距離を把握する。サーバー５０は、一定時間毎に、タクシー車両Ｔの現在地情報と時刻とをタクシーメータシステム１０から受信し（ステップＳ５２）、一定時間内にタクシー車両Ｔが移動した距離を算出する（ステップＳ５３）。

サーバー５０は、設定時間内に設定距離以上を走行したか否かを判断する（ステップＳ５４）。Ｎｏであれば、サーバー５０は、タクシー車両Ｔが走行中の確定ルートに渋滞が発生していると判断して、タクシーメータシステム１０へルート変更許可を送信する。すなわち、サーバー５０は、設定時間毎にタクシー車両Ｔの走行距離を算出して、実際の走行距離が、予測された設定距離に満たない場合には、自動で、タクシーメータシステム１０にルート変更許可を送信する。一方、ステップＳ５４でＹｅｓの場合、サーバー５０は、タクシー車両Ｔが確定ルートを予定通り走行している、と判断して、事前確定処理が終了したか否かを判断する（ステップＳ５６）。サーバー５０は、タクシーメータシステム１０から、メータ状態が空車となった旨の信号を受信すると、事前確定処理を終了する。事前確定処理が終了しない場合、サーバー５０は、ステップＳ５２の処理に戻る。

パターン３（サーバー５０からの自動指示）によれば、渋滞が発生している状況をサーバー５０が迅速に把握して、タクシーメータシステム１０側からルート変更要求がなされる前に、タクシーメータシステム１０にルート変更許可を送信する。このため、渋滞発生時には、タクシーメータシステム１０側で迅速にルートの変更が可能となる。尚、図５及び図６に示したパターン３のフローの後、図３に示したパターン１のフローを実行してもよい。すなわち、サーバー５０が渋滞を検知してルート変更許可を自動送信した後、ルート変更許可を受信したタクシーメータシステム１０が、タクシー車両Ｔの乗務員にルート変更を指示し（促し）、車外画像データを含む逸脱情報を生成してサーバー５０へ送信してもよい。このようにすれば、サーバー５０からのルート変更指示に対して、適切にルート変更がなされたか否かを、乗務員評価に反映することができる。

尚、図６のステップＳ５５でサーバー５０からタクシーメータシステム１０へ、ルート変更許可を送信するのに加え、変更後のルート（修正ルート）を送信してもよい。この構成によれば、サーバー５０側で、修正ルートを走行した場合の運賃を把握できるので、確定ルートを走行した場合の運賃との差分を算出できる。また、この情報を蓄積して一か月あたりの差分を検証することもできる。

次に、事務所ＰＣ７０における、タクシー車両Ｔの乗務員に対する運転評価について説明する。タクシー車両Ｔの乗務員の運転を評価する機能を有する事務所ＰＣ７０と、タクシーメータシステム１０とは、運転評価システムを構成する。事務所ＰＣ７０の電源を投入して使用可能状態使用可能な状態にした後、データ解析のための専用のアプリケーションソフトウェア（簡略化して「アプリ」と呼称する）を起動する。解析用のアプリは、各乗務員のメモリカード１４Ａから、それに記録されている運行データや逸脱情報を読み込む。タクシー会社Ｍの管理者が解析用のアプリに対して、確定ルートからの逸脱適否を解析するモードを指示すると、データの中から該当するイベントデータ（逸脱情報）だけを処理対象として抽出する。

アプリは、タクシーメータシステム１０において、逸脱情報が記録された回数（認識総数）と、その中で確定ルートからの逸脱が適切でなかった回数（不適切回数）とを検出し、不適切率（不適切数）を算出する。アプリは、算出した不適切率を用いて、該当する乗務員の評価に対して加点・原点の処理を実行する。すなわち、抽出した全ての逸脱情報の内容に基づき、タクシーメータシステム１０が逸脱情報が記録された回数（認識総数）と、その中で確定ルートからの逸脱が適切でなかった回数（不適切回数）とを検出し、不適切率（不適切数／認識総数）を算出する。アプリは、算出した不適切率を用いて、該当する乗務員の評価に対して加点・減点の処理を実行する。例えば、不適切率が乗務員全体の平均値に比べて低い乗務員に対しては、（平均値−不適切率）に応じた点数を評価に加算し、不適切率が平均値より高い乗務員に対しては、（不適切率−平均値）に応じた点数を評価から減算し、実際の運転状態の良否を評価に反映する。例えば、不適切率が乗務員全体の平均値に比べて低い乗務員に対しては、（平均値−不適切率）に応じた点数を評価に加算し、不適切率が平均値より高い乗務員に対しては、（不適切率−平均値）に応じた点数を評価から減算し、実際の運転状態の良否を評価に反映する。

アプリは、全ての乗務員に対する当日の運行データを反映した評価が完了した後で、全体の乗務員の評価データに基づいて評価のランキングを作成する。例えば、全ての乗務員の評価データを評価点数の高い順番に並べて、評価上位の数名と評価下位の数名の乗務員を抽出し、評価点数と共に表示する。

アプリは、全ての乗務員に対する当日の運行データを反映した評価が完了した後で、全体の乗務員の評価データに基づいて、全ての乗務員の中から指導対象とすべき乗務員を抽出する。例えば、不適切率が平均よりも高い乗務員を抽出し、安全運転指導や教育が必要な対象者として選定する。このように、乗務員の適切な運転評価が可能となる。

本実施形態においては、事前確定運賃サービスを実施中であれば、逸脱情報を生成して出力又は記憶し、事前確定運賃サービスを実施中でなく、通常の賃走等の場合は逸脱情報を出力しない。これにより、事前運賃確定サービス外でのルート変更を評価対象から除外できるので、よりタクシー会社の希望に沿った、乗務員の運転評価が可能となる。

尚、スマートデバイス３０の形態は、タブレット型に限定されず、腕時計型、眼鏡型等であってもよい。

ここで、上述した本発明の実施形態に係る車載器、運転評価システム及び運行支援システムの特徴をそれぞれ以下［１］〜［８］に簡潔に纏めて列記する。
［１］ 車両（タクシー車両Ｔ）に搭載された車載器（タクシーメータシステム１０）であって、
出発地から目的地までの経路が事前に確定されたものである確定ルートを記憶する記憶部（ＲＡＭ１３）と、
前記車両が前記確定ルートから逸脱する予定であることを示すルート変更操作を受け付ける操作受付部（入力部１６）と、
前記車両の現在地を示す現在地情報を取得する位置取得部（ＧＰＳ受信器２０）と、
前記車両の運行状況に関する状況情報を収集する収集部（カメラ１９Ａ、１９Ｂ、ＣＰＵ１１）と、
前記ルート変更操作を受け付けた時点における前記車両の現在地情報と、前記時点において取得された前記状況情報と、を対応付けた逸脱情報を生成する生成部（ＣＰＵ１１）と、
を備えることを特徴とする車載器。
［２］ 前記収集部は、前記車両の周辺又は車室内を撮影した画像データを、前記状況情報として収集する撮影部（カメラ１９Ａ、１９Ｂ）であり、
前記生成部は、前記現在地情報と、前記時点において撮影された前記画像データと、を対応付けて、前記逸脱情報を生成する
ことを特徴とする上記［１］に記載の車載器。
［３］ 前記車両は、乗客（Ｐ）を輸送するタクシー車両（Ｔ）であり、
当該車載器は、前記確定ルートでの輸送に対して事前に確定された運賃である事前確定運賃を提示する提示部（表示部１５）を備える
ことを特徴とする上記［１］又は［２］に記載の車載器。
［４］ 前記収集部は、前記乗客が携帯端末（スマートデバイス３０）の操作によって入力したルート変更指示を受け付ける指示受付部（通信部２４、ＣＰＵ１１）であり、
前記生成部は、前記現在地情報と、前記時点において入力されている前記ルート変更指示と、を対応付けて、前記逸脱情報を生成する
ことを特徴とする上記［３］に記載の車載器。
［５］ 前記ルート変更指示の受付後に前記車両が走行した距離に応じた運賃を算出する算出部（ＣＰＵ１１）を備え、
前記提示部は、前記距離に応じた運賃を、前記事前確定運賃とともに、又は、前記事前確定運賃に代えて、提示する
ことを特徴とする上記［４］に記載の車載器。
［６］ 上記［１］から［５］のいずれか一の車載器（タクシーメータシステム１０）と、前記確定ルートを走行する前記車両の運行を管理する管理装置（事務所ＰＣ７０）と、を備え、
前記管理装置は、前記逸脱情報及び前記車載器が収集した運行情報に基づいて、前記車両の運転者による運転を評価する運転評価部を備える
ことを特徴とする運転評価システム。
［７］ 上記［１］から［５］のいずれか一に記載の車載器（タクシーメータシステム１０）と、前記確定ルートを走行する前記車両の運行を管理する、前記車載器と通信可能な管理装置（サーバー５０）と、を備え、
前記車載器は、前記逸脱情報を前記管理装置に送信する情報送信部（通信部２４）を備え、
前記管理装置は、
前記逸脱情報を受信する受信部と、
前記逸脱情報に基づいて、前記逸脱が妥当であると判定された場合に、前記車載器にルート変更許可を送信する許可送信部と、を備える
ことを特徴とする運行支援システム（１）。
［８］ 前記車載器は、
前記車両の速度を算出する速度算出部と、
前記現在地情報及び前記速度を含む運行情報を、一定時間間隔で、前記管理装置に送信する送信部と、を備え、
前記管理装置は、
前記受信部が、前記運行情報をさらに受信し、
前記許可送信部が、前記運行情報に基づいて、前記車両が前記一定時間内に走行した距離を算出し、算出された前記距離が一定距離に満たない場合に、前記車載器に前記ルート変更許可を送信する
ことを特徴とする上記［７］に記載の運行支援システム（１）。

１ 運行支援システム
５ タクシーメータ本体
１０ タクシーメータシステム
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ カードリーダライタ（Ｒ／Ｗ）インターフェイス（Ｉ／Ｆ）
１４Ａ メモリカード
１５ 表示部
１６ 入力部
１７Ａ、１７Ｂ インターフェイス（Ｉ／Ｆ）
１８ ＲＴＣ（時計ＩＣ）
１９Ａ、１９Ｂ カメラ
２０ ＧＰＳ受信器
２２ ナビゲーション
２４ 通信部
３０ スマートデバイス
５０ サーバー
７０ 事務所ＰＣ
８０ 無線通信網

Claims (8)

1. 車両に搭載された車載器であって、
   出発地から目的地までの経路が事前に確定されたものである確定ルートを記憶する記憶部と、
   前記車両が前記確定ルートから逸脱する予定であることを示すルート変更操作を受け付ける操作受付部と、
   前記車両の現在地を示す現在地情報を取得する位置取得部と、
   前記車両の運行状況に関する状況情報を収集する収集部と、
   前記ルート変更操作を受け付けた時点における前記車両の現在地情報と、前記時点において取得された前記状況情報と、を対応付けた逸脱情報を生成する生成部と、
   を備えることを特徴とする車載器。
2. 前記収集部は、前記車両の周辺又は車室内を撮影した画像データを、前記状況情報として収集する撮影部であり、
   前記生成部は、前記現在地情報と、前記時点において撮影された前記画像データと、を対応付けて、前記逸脱情報を生成する
   ことを特徴とする請求項１に記載の車載器。
3. 前記車両は、乗客を輸送するタクシー車両であり、
   当該車載器は、前記確定ルートでの輸送に対して事前に確定された運賃である事前確定運賃を提示する提示部を備える
   ことを特徴とする請求項１又は２に記載の車載器。
4. 前記収集部は、前記乗客が携帯端末の操作によって入力したルート変更指示を受け付ける指示受付部であり、
   前記生成部は、前記現在地情報と、前記時点において入力されている前記ルート変更指示と、を対応付けて、前記逸脱情報を生成する
   ことを特徴とする請求項３に記載の車載器。
5. 前記ルート変更指示の受付後に前記車両が走行した距離に応じた運賃を算出する算出部を備え、
   前記提示部は、前記距離に応じた運賃を、前記事前確定運賃とともに、又は、前記事前確定運賃に代えて、提示する
   ことを特徴とする請求項４に記載の車載器。
6. 請求項１から５のいずれか一項に記載の車載器と、前記確定ルートを走行する前記車両の運行を管理する管理装置と、を備え、
   前記管理装置は、前記逸脱情報及び前記車載器が収集した運行情報に基づいて、前記車両の運転者による運転を評価する運転評価部を備える
   ことを特徴とする運転評価システム。
7. 請求項１から５のいずれか一項に記載の車載器と、前記確定ルートを走行する前記車両の運行を管理する、前記車載器と通信可能な管理装置と、を備え、
   前記車載器は、前記逸脱情報を前記管理装置に送信する情報送信部を備え、
   前記管理装置は、
   前記逸脱情報を受信する受信部と、
   前記逸脱情報に基づいて、前記逸脱が妥当であると判定された場合に、前記車載器にルート変更許可を送信する許可送信部と、を備える
   ことを特徴とする運行支援システム。
8. 前記車載器は、
   前記車両の速度を算出する速度算出部と、
   前記現在地情報及び前記速度を含む運行情報を、一定時間間隔で、前記管理装置に送信する送信部と、を備え、
   前記管理装置は、
   前記受信部が、前記運行情報をさらに受信し、
   前記許可送信部が、前記運行情報に基づいて、前記車両が前記一定時間内に走行した距離を算出し、算出された前記距離が一定距離に満たない場合に、前記車載器に前記ルート変更許可を送信する
   ことを特徴とする請求項７に記載の運行支援システム。

Images