JP2020135286A

JP2020135286A - 車載器及びタクシーシステム

Info

Publication number: JP2020135286A
Application number: JP2019026528A
Authority: JP
Inventors: 敏彦杉山; Toshihiko Sugiyama
Original assignee: Yazaki Energy System Corp
Current assignee: Yazaki Energy System Corp
Priority date: 2019-02-18
Filing date: 2019-02-18
Publication date: 2020-08-31
Anticipated expiration: 2039-02-18
Also published as: JP7244291B2

Abstract

【課題】サーバとの間の無駄な通信をなくすことができる車載器及びタクシーシステムを提供することを目的とする。【解決手段】取付情報をクラウドサーバ５０へ送信する通信ユニット２１及びタクシーメータ１０は、タクシー車両８に搭載される。タクシーメータ１０は、タクシー車両８へのタクシーメータ１０の取り付けが完了したことを示す取付情報をクラウドサーバ５０に送信するための入力部１６と、入力部１６での入力に応じて通信ユニット２１に取付情報を送信させ、取付情報の送信が完了したか否かを管理するＣＰＵ１１と、を備える。ＣＰＵ１１は、取付情報を送信後、通信サービス開始状態を検出するまでの間は、クラウドサーバ５０との間の通信サービスを制限する。【選択図】図１

Description

本発明は、車載器及びタクシーシステムに関する。

タクシー会社によるタクシー車両の運用において、タクシーメータと通信機器とをタクシー車両に取り付け、サーバを利用するタクシーシステムが知られている（例えば、特許文献１参照）。特許文献１に開示された運行管理システムは、タクシー車両の入出庫処理にクラウドサーバを利用するものである。また、車載器と管理サーバとを備える車載器運用システムにおいて、通信の契約を解除あるいは休止する場合、管理サーバが、遠隔操作で車載器内の通信モジュールの送信機能を停止させるものが提案されている（特許文献２参照）。

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

一般的なタクシーシステムにおいて、タクシーメータは、タクシーメータで収集した、メータ状態、料金情報、売上情報、走行距離、時間情報等のメータ情報を、一定間隔またはトリガ発生時に、サーバに送信している。また、サーバからは、タクシー会社（管理者）からタクシー車両（乗務員）へのメッセージ、広告情報、運賃料金情報等の配信情報を、一定間隔またはトリガ発生時に、タクシーメータに送信している。トリガ発生時とは、急加減速や急発進が発生した時、またはメータ状態が変化した時等である。

このようなタクシーメータとサーバとの間のデータ送受信は、タクシー車両への車載器（タクシーメータ及び通信機器）の取り付け後に開始され、その後継続される。このため、タクシー車両への車載器取り付け後乗務員が運用を開始する前、休車時、タクシー車両の故障修理時、タクシー車両の予備検査時等の、タクシー車両が本来の運用をされていない場合にも、タクシーメータとサーバとの間で不要な通信が発生し、余分な通信料がかかっていた。タクシーメータとクラウドサーバとの間の不要な通信について、特許文献１には開示がない。また、特許文献２は、通信契約の解除あるいは休止後に管理サーバが車載器の送信機能や記録機能を制限する点を開示するものの、車載器と管理サーバとの間の不要な通信については開示しない。

本発明は、上述した事情に鑑みてなされたものであり、その目的は、サーバとの間の無駄な通信をなくすことができる車載器及びタクシーシステムを提供することにある。

前述した目的を達成するために、本発明に係る車載器及びタクシーシステムは、下記（１）〜（５）を特徴としている。
（１）車両に搭載され、サーバとの間でデータを送受信する車載器であって、
前記車両への前記車載器の取り付けが完了したことを認識して取付情報を生成する第一生成部と、
前記取付情報を前記サーバへ送信する送信部と、
前記送信部に前記取付情報を送信させ、前記取付情報の送信が完了したか否かを管理する制御部と、
を備え、
前記制御部は、前記取付情報を送信後、通信サービス開始状態を検出するまでの間は、前記サーバとの間の通信サービスを制限することを特徴とする車載器。
（２）前記車両はタクシー車両であって、
前記制御部は、前記取付情報の送信完了後において前記タクシー車両が初回の営業を開始した場合、前記通信サービス開始状態を検出し、前記サーバから前記車載器に配信情報を送信する通信サービスの開始を通知する通信サービス開始通知を、前記サーバへ送信するよう前記送信部を制御する
ことを特徴とする上記（１）に記載の車載器。
（３）前記制御部は、前記取付情報の送信完了後において、出庫操作がされた場合、メータ状態が実車もしくは迎車となった場合、または、前記タクシー車両が所定距離走行した場合に、前記タクシー車両が初回の営業を開始したと判断する
ことを特徴とする上記（２）に記載の車載器。
（４）前記通信サービスの停止を通知すべき状態を認識して通信サービス停止通知を生成する第二生成部を備え、
前記制御部は、前記送信部に前記通信サービス停止通知を送信させ、前記通信サービス開始状態が解除されたことを認識する
ことを特徴とする上記（２）または（３）に記載の車載器。
（５）サーバと、
タクシー車両に搭載され、前記サーバとの間でデータを送受信する車載器と、を備えるタクシーシステムであって、
前記車載器は、
前記タクシー車両への前記車載器の取り付けが完了したことを示す取付情報を前記サーバに送信するための第一入力部と、
前記取付情報を前記サーバへ送信する送信部と、
前記第一入力部での入力に応じて前記送信部に前記取付情報を送信させ、前記取付情報の送信が完了したか否かを管理する制御部と、
を備え、
前記制御部は、前記取付情報を送信後、通信サービス開始状態を検出するまでの間は、前記サーバとの間の通信サービスを制限し、前記取付情報の送信完了後において前記タクシー車両が初回の営業を開始した場合、前記通信サービス開始状態を検出し、前記サーバから前記車載器に配信情報を送信する通信サービスの開始を通知する通信サービス開始通知を、前記サーバへ送信するよう前記送信部を制御し、
前記サーバは、前記取付情報を受信し、かつ、前記通信サービス開始通知を受信していない場合、前記車載器に、機器設定に関する情報を送信する
ことを特徴とするタクシーシステム。

上記（１）の構成の車載器によれば、車載器の取り付け完了後、通信サービス開始状態となるまでの間は、サーバとの通信サービスが制限される。このため、車載器が車両に取り付けられた後乗務員が運用を開始する前、休車時、車両の故障修理時、及び車両の予備検査時等の、車両が本来の運用をされていない場合に、車載器（例えばタクシーメータ及び通信機器）とサーバとの間で不要な通信が行われることを防止できる。これにより、タクシー会社等の車両の管理者の通信料の負担を軽減でき、かつ、サーバの処理や通信負荷を低減できる。
また、例えば車載器に設けられた通知ボタンでの操作に応じて、または所定の条件を満たした場合に自動で、サーバに車載器の取り付け完了を通知することにより、サーバは車載器の取り付け状態を認識でき、サーバによる車載器の管理が可能となる。

また、仮に、例えば、車載器のタクシー車両への取り付けが完了した時点で直ちに通信サービスが開始される場合には、実際にタクシーシステムの運用を開始する時点と車載器の取り付け完了時点とを近づけて不要な通信の発生を極力避けるべく、全てのタクシー車両に対する車載器の取り付け作業を短期間で行うことが求められる。このため、特にタクシー車両の台数が多い場合には、車載器の取り付け不良が発生しうる。これに対し、上記構成によれば、車載器（タクシー車両）毎に通信サービスの開始を行うことができるため、車載器の取り付け作業を余裕ある日程で行うことができる。よって、取付不良の低減を図れる。また、車載器の取り付けが完了した車両から取付情報が送信されるため、サーバにて、全車両における取付作業の進捗状況を管理できる。

本明細書において、通信サービスは、車載器からサーバへ、タクシーメータのメータ状態、料金情報、売り上げ情報、及び走行距離・時間情報等のメータ情報を送信し、サーバから車載器へ、メッセージ、広告情報、及び運賃料金情報等の配信情報を送信することを意味する。また、本明細書において、取付情報（アクティベート情報）は、取付車両情報、取付会社情報、及び使用する通信機器情報（ＩＣＣＩＤ：IC Card IDentifier）を含む。

上記（２）の構成の車載器によれば、サーバは、通信サービス開始通知を受信した時点から通信サービスを開始できる。また、車載器は、通信サービス開始通知を送信した後、サーバへのメータ情報の送信を開始する。このため、タクシー車両が実際に営業を開始した時点から通信サービスを開始できる。

上記（３）の構成の車載器によれば、取付情報の送信後、初回の出庫操作がされた（出庫ボタンが操作された）場合に通信サービスを開始できる。また、出庫操作がなされなかった場合であっても、実車ボタンもしくは迎車ボタンが操作されてメータ状態が空車から実車または迎車に変更された時点で、通信サービスを開始できる。さらに、メータ状態が変更されない場合であっても、タクシー車両の走行距離が所定距離（例えば１０ｍ）に達した場合に、初回の営業が開始されたとして、通信サービスを開始できる。

上記（４）の構成の車載器によれば、通信サービス開始後に、車両が営業に使用できない状態である休車、車両の故障修理、車両の予備検査等の通信サービスの停止を通知すべき状態が発生した場合には、サーバに通信サービスの停止を通知して、サーバからの配信情報の送信を停止できる。このため、通信サービス開始後にタクシーが本来の運用をされなくなった場合に、車載器とサーバとの間で不要な通信が行われることを防止できる。また、通信サービス停止通知に、休車や車両の故障といった停止条件（通信サービス停止の理由）の情報を含めることにより、通信サービスの停止が妥当であるかをサーバ側で管理できる。尚、通信サービスの停止を通知すべき状態として、車両が入庫した場合を含めてもよい。

上記（５）の構成のタクシーシステムによれば、上記（１）及び（２）の構成による効果に加え、以下の効果を奏する。サーバは、通信サービスが開始される前の時点で、車載器に必要な、機器設定に関するプログラム等の情報を車載器に送信し、この時点で不要な配信情報は送信しない。このため、通信の無駄を防ぎつつ、必要な情報を予め車載器に提供することができる。

本発明によれば、サーバとの間の無駄な通信をなくすことができる車載器及びタクシーシステムを提供することができる。

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

図１は、本発明の実施形態におけるタクシーシステムの構成を示すブロック図である。図２は、タクシーメータのタッチパネルの表示画面例を示す図である。図３は、タクシーメータの起動処理を示すフローチャートである。図４は、タクシーメータの初回出庫処理を示すフローチャートである。図５は、タクシーメータの休車開始時の処理を示すフローチャートである。図６は、タクシーメータの休車終了時の処理を示すフローチャートである。

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

図１は、本発明の実施形態におけるタクシーシステム５の構成を示すブロック図である。タクシーシステム５は、タクシー車両８に搭載されたタクシーメータ１０（車載器）及び通信ユニット２１（車載器）と、車両外に存在するクラウドサーバ５０（サーバ）と、を備える。タクシーメータ１０は、通信ユニット２１を経由して、車両外に存在するクラウドサーバ５０との間で通信できるようになっている。

タクシーメータ１０は、ＣＰＵ１１（制御部、第一生成部、第二生成部）、ＲＯＭ１２、ＲＡＭ１３、カードリーダライタ（Ｒ／Ｗ）インターフェイス（Ｉ／Ｆ）１４、表示部１５、入力部１６（第一入力部、第二入力部）、インターフェイス（Ｉ／Ｆ）１７Ａ，１７Ｂ，１７Ｃ、ＲＴＣ（時計ＩＣ）１８、及び電源部２２を有する。Ｉ／Ｆ１７Ａには、ＧＰＳ受信器２０が接続される。Ｉ／Ｆ１７Ｂには、ＥＴＣ車載器１９が接続される。Ｉ／Ｆ１７Ｃには、通信ユニット２１（送信部）が接続される。

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

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

さらに、ＣＰＵ１１は、タクシーメータ１０及び通信ユニット２１の状態が以下の三種類のいずれであるかを管理する。
（１）タクシーメータ１０及び通信ユニット２１が物理的にタクシー車両８に取り付けられている状態である機器取付状態
（２）タクシー車両８へのタクシーメータ１０及び通信ユニット２１の取り付けが完了したことを示す取付情報の、クラウドサーバ５０への送信が完了した状態である取付情報送信完了状態
（３）通信サービスの開始を通知する通信サービス開始通知の、クラウドサーバ５０への送信が完了した状態である通信サービス開始通知送信完了状態（通信サービス開始状態）
取付情報（アクティベート情報）は、タクシー車両８の車両情報である取付車両情報、取付作業を実施する会社の情報である取付会社情報、及び使用する通信ユニット２１の機器情報である通信機器情報（ＩＣＣＩＤ：IC Card IDentifier）を含む。通信サービスは、タクシーメータ１０からクラウドサーバ５０へ、タクシーメータ１０のメータ状態、料金情報、売り上げ情報、及び走行距離・時間情報等のメータ情報を送信し、クラウドサーバ５０からタクシーメータ１０へ、メッセージ、広告情報、及び運賃料金情報等の配信情報を送信することを意味する。

ＣＰＵ１１は、図２（Ｂ）に示す取付完了ボタンｂ０が、取付作業者によって操作されることにより、取付情報を通信ユニット２１を経由してクラウドサーバ５０へ送信し、タクシーメータ１０の内部状態を、機器取付状態から取付情報送信完了状態に変更する。この取付完了ボタンｂ０は、タクシーメータ１０及び通信ユニット２１をタクシー車両８に取り付ける作業中の設定画面ＧＭ１に表示される。尚、タクシーメータ１０の筐体１０ｚに設けた機械式ボタン等を「取付完了ボタン」としてもよい。

また、ＣＰＵ１１は、取付情報の送信完了後において、タクシー車両８が初回の営業を開始した場合、通信サービス開始状態であることを検出する。通信サービス開始状態であることを検出したＣＰＵ１１は、通信サービス開始通知を通信ユニット２１を経由してクラウドサーバ５０へ送信し、タクシーメータ１０の内部状態を、取付情報送信完了状態から通信サービス開始通知送信完了状態に変更する。ＣＰＵ１１は、乗務員によって出庫操作がされた（出庫ボタンが操作された）場合、メータ状態が実車もしくは迎車となった場合、または、タクシー車両８が所定距離（例えば１０ｍ）走行した場合に、タクシー車両８が初回の営業を開始したと判断する。

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

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

Ｉ／Ｆ１７Ａには、ＧＰＳ受信器２０が接続される。ＧＰＳ受信器２０は、ＧＰＳ衛星から送信される時刻データを受信し、タクシー車両８の現在位置（緯度、経度、高度）を算出し、ＧＰＳ位置情報として出力可能である。Ｉ／Ｆ１７Ｂには、ＥＴＣ車載器１９が接続される。ＲＴＣ（時計ＩＣ）１８は現在時刻を計時する。ＲＴＣ１８によって計時される時刻は、車両の運転状態を表す走行データとともにＲＡＭ１３に記録される。Ｉ／Ｆ１７Ｃには、通信ユニット２１が接続される。通信ユニット２１は、例えばテレマティクスモジュールと呼ばれる端末のように、携帯電話会社等が設置した無線基地局３０との間で無線通信を行うことが可能である。通信ユニット２１は、この携帯電話会社側の通信設備を経由して、インターネット等のネットワーク上に配置されたクラウドサーバ５０との間で必要に応じて通信回線を接続することができる。

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

電源部２２は、このタクシー車両８のエンジンキーの動作に連動するスイッチのオンオフに従って、このスイッチがオンの時に所定の直流電力を各回路に供給する。

図２は、タクシーメータ１０のタッチパネルＴＰ１の表示画面例を示す図であり、（Ａ）はタクシー料金画面ＧＭ０が表示された状態、（Ｂ）は設定画面ＧＭ１が表示された状態を示す。タクシーメータ１０は、箱形の筐体１０ｚを有する。筐体１０ｚの前面には、タッチパネルＴＰ１が配置される。タッチパネルＴＰ１は、表示部１５及び入力部１６を有する。図２（Ａ）において、表示部１５は、矩形のタクシー料金画面ＧＭ０、及びタクシー料金画面ＧＭ０の縁部に沿うように逆Ｌ字形の操作画面ＧＳ０を表示する。タクシー料金画面ＧＭ０には、運賃及びメータ状態が表示される。メータ状態は、高速、割増、割引、次回料金上がりバー等の情報を含む。操作画面ＧＳ０には、入力部１６である各種ボタンｂ１〜ｂ５，ｂ１１〜ｂ１５が配置される。具体的に、操作画面ＧＳ０の右側には、空車ボタンｂ１、実車（賃走）ボタンｂ２、支払ボタンｂ３、合計ボタンｂ４及び迎車ボタンｂ５が配置される。また、操作画面ＧＳ０の下側には、高速ボタンｂ１１、割増ボタンｂ１２、予約ボタンｂ１３、貸切ボタンｂ１４及び割引ボタンｂ１５が配置される。

図２（Ｂ）において、表示部１５は、図２（Ａ）に示すタクシー料金画面ＧＭ０に代えて、設定画面ＧＭ１を表示する。設定画面ＧＭ１は、タクシーメータ１０及び通信ユニット２１をタクシー車両８に取り付ける作業に用いられる。設定画面ＧＭ１の中央には、入力部１６である取付完了ボタンｂ０が表示される。取付作業者が、取り付け作業が完了した時点で取付完了ボタンｂ０を操作することにより、取付情報が通信ユニット２１を経由してクラウドサーバ５０へ送信される。尚、表示部１５において、タクシーメータ１０及び通信ユニット２１の状態が、機器取付状態、取付情報送信完了状態、及び、通信サービス開始状態のいずれであるかに応じた表示を行うことにより、取付作業者等に状態を容易に把握させることができる。例えば表示部１５は、ＣＰＵ１１の指示により、表示部１５の右上角等に表示される電波の状況を示す電波マークの表示位置に、機器取付状態であればＡを表示し、取付情報送信完了状態であればＳを表示し、通信サービス開始状態となった場合にはＳの表示を消して電波マークを表示してもよい。また、図２（Ａ）及び図２（Ｂ）に示すように、筐体１０ｚの下方には、メモリカード１４Ａが挿抜自在に装着される挿入口１４ｚが配置される。

一方、クラウドサーバ５０は、タクシーメータ１０に対して、タクシー会社（管理者）からタクシー車両８（乗務員）へのメッセージ、広告情報、運賃料金情報等の配信情報を、一定間隔またはトリガ発生時に送信することができる。トリガ発生時とは、タクシー車両８において、急加減速や急発進が発生した時、またはメータ状態が変化した時等である。本実施形態において、クラウドサーバ５０は、タクシーメータ１０から取付情報（アクティベート情報）を受信すると、この取付情報に基づいて、タクシー車両８の車両情報、取付会社情報、及び通信ユニット２１の機器情報（ＩＣＣＩＤ：IC Card IDentifier）を登録する。この登録により、クラウドサーバ５０は、タクシーメータ１０の管理が可能となる。また、クラウドサーバ５０は、タクシーメータ１０から通信サービス開始通知を受信すると、タクシーメータ１０への配信情報の送信を開始する。すなわち、通信サービスが開始される。さらに、クラウドサーバ５０は、タクシーメータ１０から通信サービス停止通知を受信すると、通信サービスを停止する。通信サービス停止通知には、停止条件が、休車、車両故障、及び予備検査等のいずれであるかという情報を含まれる。通信サービス停止通知に停止条件が含まれることにより、クラウドサーバ５０は、タクシーメータ１０の停止の妥当性を判断できる。クラウドサーバ５０は、通信サービス停止通知を受信した後、通信サービス開始通知を受信すると、配信情報の送信を再開する。

次に、以上のように構成されたタクシーシステム５において、タクシーメータ１０が行う処理を説明する。

図３は、タクシーメータ１０の起動処理を示すフローチャートである。まず、ＣＰＵ１１は、ＡＣＣ（アクセサリー電源）がＯＮされると（ステップＳ１でＹＥＳ）、ＡＣＣ−ＯＮ処理を行い、電源部２２から各部に電源を供給する（ステップＳ２）。次に、ＣＰＵ１１は、通信サービス開始状態であるか、すなわち、取付情報を受信後に、通信サービス開始通知を受信し、かつ、通信サービス停止通知を受信していないか、を判断する（ステップＳ３）。通信サービス開始状態である場合（ステップＳ３でＹＥＳ）、ＣＰＵ１１は、タクシーメータ１０のメータ情報のクラウドサーバ５０への送信を開始する、すなわち、車載器−サーバ間データ送信処理を開始する（ステップＳ４）。ステップＳ１においてＡＣＣがＯＮされない場合（ステップＳ１でＮＯ）及びステップＳ３において通信サービス開始状態でない場合（ステップＳ３でＮＯ）、ＣＰＵ１１はメータ起動処理を終了する。

図４は、タクシーメータ１０の初回出庫処理を示すフローチャートである。本処理は、図３のメータ起動処理において、車載器−サーバ間データ送信処理が開始されない場合（ステップＳ３でＮＯ）に実行される。まず、ＣＰＵ１１は、出庫ボタンが操作され出庫処理が行われたか否かを判断する（ステップＳ１１）。出庫処理がされた場合（ステップＳ１１でＹＥＳ）、ＣＰＵ１１は、タクシーメータ１０及び通信ユニット２１の取り付け後、初回の出庫か否かを判断する（ステップＳ１２）。初回の出庫である場合（ステップＳ１２でＹＥＳ）、ＣＰＵ１１は、通信サービス開始状態であることを検出して、クラウドサーバ５０に通信サービス開始通知を送信する（ステップＳ１３）。ステップＳ１３において、ＣＰＵ１１は、タクシーメータ１０の内部状態を通信サービス開始状態に変更して、初回出庫処理を終了する。通信サービス開始通知送信処理（ステップＳ１３）の後、タクシーメータ１０とクラウドサーバ５０との間で通信サービスが開始される。一方、ステップＳ１１において、出庫処理がされていない場合（ステップＳ１１でＮＯ）は、実質的に営業が開始されているか否かを判断する（ステップＳ１４）。ステップＳ１４において、実車ボタンもしくは迎車ボタンが操作されてメータ状態が空車から実車または迎車に変更された場合、または、タクシー車両８の走行距離が所定距離（例えば１０ｍ）に達した場合、ＣＰＵ１１は、実質的に営業が開始されたと判断する。営業が開始された場合（ステップＳ１４でＹＥＳ）、取り付け後の初回営業か否かを判断し（ステップＳ１５）、初回営業の場合はステップＳ１３の処理に進む（ステップＳ１５でＹＥＳ）。ステップＳ１４において営業が開始されていないと判断した場合（ステップＳ１４でＮＯ）、ＣＰＵ１１は、ステップＳ１１の処理に戻る。また、ステップＳ１２で初回の出庫でない場合（ステップＳ１２でＮＯ）及びステップＳ１５で取り付け後初回の営業でない場合（ステップＳ１５でＮＯ）、ＣＰＵ１１は初回出庫処理を終了する。

次に、図５及び図６を参照して、タクシーメータ１０が通信サービス開始状態である場合において、タクシー車両８が営業に使用できない状態である休車となった場合の処理を説明する。図５は、タクシーメータ１０の休車開始時の処理を示すフローチャートであり、図６は、タクシーメータ１０の休車終了時の処理を示すフローチャートである。図５において、ＣＰＵ１１は、例えば不図示の休車ボタンが押下されることにより、休車開始が入力されたことを検知して（ステップＳ２１）、休車フラグをＯＮにしてタクシーメータ１０の通信サービス開始状態を解除する（ステップＳ２２）。そして、ＣＰＵ１１は、休車開始情報を通信ユニット２１を経由してクラウドサーバ５０へ送信して、通信サービスの停止を通知する（ステップＳ２３）。休車開始情報は、通信サービス停止通知のうち、停止条件が休車であることを示すものである。そして、ＣＰＵ１１は、タクシーメータ１０とクラウドサーバ５０との間のデータ送信処理を停止する（ステップＳ２４）。その後、ＣＰＵ１１は、休車終了入力がなされるか否かを監視する（ステップＳ２５）。

図６において、ＣＰＵ１１は、例えば休車ボタンの押下が解除されることにより、休車終了が入力されたことを検知して（ステップＳ３１）、休車フラグをＯＦＦにして内部状態を通信サービス開始状態とする（ステップＳ３２）。次にＣＰＵ１１は、タクシーメータ１０とクラウドサーバ５０との間のデータ送信処理を開始する（ステップＳ３３）。そして、ＣＰＵ１１は、休車終了情報を通信ユニット２１を経由してクラウドサーバ５０へ送信して、通信サービスの開始を通知する（ステップＳ３４）。その後、ＣＰＵ１１は、休車開始入力がなされるか否かを監視する（ステップＳ３５）。

図５及び図６を参照して、休車時の処理を説明したが、同様の処理により、故障修理、予備検査等にも通信サービスの停止及び再開を実現できる。管理者等が、休車ボタンの代わりに、故障修理ボタン、予備検査ボタン等、各停止条件に応じて通信サービスを停止するための入力部（第二入力部）を操作し、ＣＰＵ１１が図５及び図６と同様の処理を実行することにより、各停止条件において、通信サービスの停止及び再開処理を実現できる。休車ボタン、故障修理ボタン、予備検査ボタン等の入力部は、表示部１５のモードを選択することによって操作画面ＧＳ０（入力部１６）の各種ボタンとして表示されたり、取付完了ボタンｂ０のように設定画面ＧＭ１等に表示されたりしてもよい。または、休車ボタン等の入力部は、機械式ボタンとして筐体１０ｚに設けられてもよい。このように、通信サービス開始後に、休車、車両の故障修理、車両の予備検査等が発生した場合には、休車ボタン等の各停止条件に応じた入力部を操作することにより、クラウドサーバ５０に通信サービスの停止を通知して、クラウドサーバ５０からの配信情報の送信を停止できる。このため、通信サービス開始後にタクシー車両８が本来の運用をされなくなった場合に、車載器（タクシーメータ１０及び通信ユニット２１）とクラウドサーバ５０との間で不要な通信が行われることを防止できる。また、通信サービス停止通知が、各停止条件に応じた入力部の操作により送信されることから、休車や車両の故障といった停止条件（通信サービス停止の理由）の情報を含む。このため、通信サービスの停止が妥当であるかをクラウドサーバ５０側で管理できる。

本実施形態によれば、車載器（タクシーメータ１０及び通信ユニット２１）の取り付け完了後、通信サービス開始状態となるまでの間は、クラウドサーバ５０との通信サービスが制限される。このため、車載器がタクシー車両８に取り付けられた後乗務員が運用を開始する前、休車時、車両の故障修理時、車両の予備検査時等の、タクシー車両８が本来の運用をされていない場合に、車載器（タクシーメータ１０及び通信ユニット２１）とクラウドサーバ５０との間で不要な通信が行われることを防止できる。これにより、タクシー会社の通信料の負担を軽減でき、かつ、サーバの処理や通信負荷を低減できる。

尚、本発明は、前述した実施形態に限定されるものではなく、適宜、変形、改良、等が可能である。その他、前述した実施形態における各構成要素の材質、形状、寸法、数値、形態、数、配置箇所、等は本発明を達成できるものであれば任意であり、限定されない。例えば、通信ユニット２１は、タクシーメータの筐体１０ｚ内に組み込まれてもよい。また、本発明の車載器は、タクシー以外の車両であってサーバと通信を行う機能を有するトラック、バス、乗用車にも適用が可能である。

ここで、上述した本発明の実施形態に係る車載器及びタクシーシステムの特徴をそれぞれ以下［１］〜［５］に簡潔に纏めて列記する。
［１］車両（タクシー車両８）に搭載され、サーバ（クラウドサーバ５０）との間でデータを送受信する車載器（タクシーメータ１０、通信ユニット２１）であって、
前記タクシー車両への前記車載器の取り付けが完了したことを認識して取付情報を生成する第一生成部（ＣＰＵ１１）と、
前記取付情報を前記サーバへ送信する送信部（通信ユニット２１）と、
前記送信部に前記取付情報を送信させ、前記取付情報の送信が完了したか否かを管理する制御部（ＣＰＵ１１）と、
を備え、
前記制御部は、前記取付情報を送信後、通信サービス開始状態を検出するまでの間は、前記サーバとの間の通信サービスを制限することを特徴とする車載器。
［２］前記車両はタクシー車両であって、
前記制御部は、前記取付情報の送信完了後において前記タクシー車両が初回の営業を開始した場合、前記通信サービス開始状態を検出し、前記サーバから前記車載器に配信情報を送信する通信サービスの開始を通知する通信サービス開始通知を、前記サーバへ送信するよう前記送信部を制御する
ことを特徴とする上記［１］に記載の車載器。
［３］前記制御部は、前記取付情報の送信完了後において、出庫操作がされた場合、メータ状態が実車もしくは迎車となった場合、または、前記タクシー車両が所定距離走行した場合に、前記タクシー車両が初回の営業を開始したと判断する
ことを特徴とする上記［２］に記載の車載器。
［４］前記通信サービスの停止を通知すべき状態を認識して通信サービス停止通知を生成する第二生成部（ＣＰＵ１１）を備え、
前記制御部は、前記送信部に前記通信サービス停止通知を送信させ、前記通信サービス開始状態が解除されたことを認識する
ことを特徴とする上記［２］または［３］に記載の車載器。
［５］サーバ（クラウドサーバ５０）と、
タクシー車両（８）に搭載され、前記サーバとの間でデータを送受信する車載器（タクシーメータ１０、通信ユニット２１）と、を備えるタクシーシステム（５）であって、
前記車載器は、
前記タクシー車両への前記車載器の取り付けが完了したことを示す取付情報を前記サーバに送信するための第一入力部（入力部１６、取付完了ボタンｂ０）と、
前記取付情報を前記サーバへ送信する送信部（通信ユニット）と、
前記第一入力部での入力に応じて前記送信部に前記取付情報を送信させ、前記取付情報の送信が完了したか否かを管理する制御部（ＣＰＵ１１）と、
を備え、
前記制御部は、前記取付情報を送信後、通信サービス開始状態を検出するまでの間は、前記サーバとの間の通信サービスを制限し、前記取付情報の送信完了後において前記タクシー車両が初回の営業を開始した場合、前記通信サービス開始状態を検出し、前記サーバから前記車載器に配信情報を送信する通信サービスの開始を通知する通信サービス開始通知を、前記サーバへ送信するよう前記送信部を制御し、
前記サーバは、前記取付情報を受信し、かつ、前記通信サービス開始通知を受信していない場合、前記車載器に、機器設定に関する情報を送信する
ことを特徴とするタクシーシステム。

５タクシーシステム
８タクシー車両
１０タクシーメータ
１０ｚ筐体
１１ＣＰＵ
１２ＲＯＭ
１３ＲＡＭ
１４カードリーダライタ（Ｒ／Ｗ）インターフェイス（Ｉ／Ｆ）
１４Ａメモリカード
１４ｚ挿入口
１５表示部
１６入力部
１７Ａ，１７Ｂ，１７Ｃインターフェイス（Ｉ／Ｆ）
１８ＲＴＣ（時計ＩＣ）
１９ＥＴＣ車載器
２０受信器
２１通信ユニット
２２電源部
３０無線基地局
５０クラウドサーバ
ｂ０取付完了ボタン
ＴＰ１タッチパネル

Claims

車両に搭載され、サーバとの間でデータを送受信する車載器であって、
前記車両への前記車載器の取り付けが完了したことを認識して取付情報を生成する第一生成部と、
前記取付情報を前記サーバへ送信する送信部と、
前記送信部に前記取付情報を送信させ、前記取付情報の送信が完了したか否かを管理する制御部と、
を備え、
前記制御部は、前記取付情報を送信後、通信サービス開始状態を検出するまでの間は、前記サーバとの間の通信サービスを制限することを特徴とする車載器。
前記車両はタクシー車両であって、
前記制御部は、前記取付情報の送信完了後において前記タクシー車両が初回の営業を開始した場合、前記通信サービス開始状態を検出し、前記サーバから前記車載器に配信情報を送信する通信サービスの開始を通知する通信サービス開始通知を、前記サーバへ送信するよう前記送信部を制御する
ことを特徴とする請求項１に記載の車載器。
前記制御部は、前記取付情報の送信完了後において、出庫操作がされた場合、メータ状態が実車もしくは迎車となった場合、または、前記タクシー車両が所定距離走行した場合に、前記タクシー車両が初回の営業を開始したと判断する
ことを特徴とする請求項２に記載の車載器。
前記通信サービスの停止を通知すべき状態を認識して通信サービス停止通知を生成する第二生成部を備え、
前記制御部は、前記送信部に前記通信サービス停止通知を送信させ、前記通信サービス開始状態が解除されたことを認識する
ことを特徴とする請求項２または３に記載の車載器。
サーバと、
タクシー車両に搭載され、前記サーバとの間でデータを送受信する車載器と、を備えるタクシーシステムであって、
前記車載器は、
前記タクシー車両への前記車載器の取り付けが完了したことを示す取付情報を前記サーバに送信するための第一入力部と、
前記取付情報を前記サーバへ送信する送信部と、
前記第一入力部での入力に応じて前記送信部に前記取付情報を送信させ、前記取付情報の送信が完了したか否かを管理する制御部と、
を備え、
前記制御部は、前記取付情報を送信後、通信サービス開始状態を検出するまでの間は、前記サーバとの間の通信サービスを制限し、前記取付情報の送信完了後において前記タクシー車両が初回の営業を開始した場合、前記通信サービス開始状態を検出し、前記サーバから前記車載器に配信情報を送信する通信サービスの開始を通知する通信サービス開始通知を、前記サーバへ送信するよう前記送信部を制御し、
前記サーバは、前記取付情報を受信し、かつ、前記通信サービス開始通知を受信していない場合、前記車載器に、機器設定に関する情報を送信する
ことを特徴とするタクシーシステム。