WO2018220705A1 - 車載情報装置、車両用サーバ、サーバシステム、及び、車載情報装置の情報送信方法 - Google Patents

Abstract

送信判定部（１４）は、共通情報を送信する場合に必要なスループットと、車両用サーバ（３）との通信状態から推測されるスループットと、車載情報装置（１）の処理負荷とを用いて、共通情報が送信不可であるかを判定する。送信部（１６）は、設定された送信タイミングで車両側情報を車両用サーバ（３）へ送信するとともに、送信判定部（１４）により送信不可であると判定された場合、送信不可メッセージを車両用サーバ（３）へ送信する。

Description

車載情報装置、車両用サーバ、サーバシステム、及び、車載情報装置の情報送信方法

　この発明は、自車両において収集された車両側情報を、車両用サーバへ送信する車載情報装置に関するものである。

　ＩＣＴ（Ｉｎｆｏｒｍａｔｉｏｎ　ａｎｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ）端末としての機能を有する車両いわゆるコネクテッドカーから、当該車両の状態及び周囲の道路状況等の様々なデータをネットワークを介して受信し、当該データを集積及び分析することによる、ドライブレコーダサービス及び自動運転サービス等の提供が期待されている。当該ネットワークは、例えば携帯電話網を利用した無線通信網である。無線通信の高速化及び大容量化は進められているものの、コネクテッドカーが増えることにより、サービスを提供するためのサーバに対する、車両からの通信頻度及び必要な通信容量が増大する。このため、車両からサーバへ向かう方向であるアップリンクでの通信について、特に考慮する必要がある。
　例えば特許文献１には、移動通信システムにおいて、アップリンク上でデータを送信するための無線周波数リソースを要求する方法が記載されている。

特許第５２７９９２９号公報

　アップリンクでの通信として、車両がサーバへ送信する様々なデータの中には、複数の車両間で共通するものと、複数の車両間で共通しないものとが存在する。前者としては、例えば渋滞状況の情報等、後者としては、例えば現在位置の情報等が挙げられる。しかしながら従来は、車両がサーバへ送信するデータについて、このように複数の車両間で共通するかしないかという性質で区別することなく、車両からサーバへ情報が送信されていた。このため、アップリンク用の無線周波数リソースとして、共通情報を送信する全ての車両に対するアップリンク用の無線周波数リソースが必要であり、アップリンク用の無線周波数リソースの効率的な利用が図られていなかった。

　この発明は、上記のような課題を解決するためになされたもので、全ての車両から共通情報が重複してサーバへ送信されることによるアップリンク用の無線周波数リソースの無駄な利用を防ぎ、アップリンク用の無線周波数リソースを効率的に利用することができる車載情報装置を得ることを目的とする。

　この発明に係る車載情報装置は、自車両において収集された１又は複数の車両側情報を、当該車両側情報それぞれに設定された送信タイミングのクラスに応じたタイミングで車両用サーバへ送信する送信部と、他の車両と共通する車両側情報である共通情報を送信する場合に必要なスループットと、車両用サーバとの通信状態から推測されるスループットと、装置処理負荷とを用いて、当該共通情報が送信不可であるかを判定する送信判定部とを備え、送信判定部により送信不可であると判定された場合、送信部は、共通情報が送信不可であるメッセージを車両用サーバへ送信することを特徴とするものである。

　この発明によれば、共通情報が送信不可であるときはその旨のメッセージを車両用サーバへ送信するので、全ての車両から共通情報が重複してサーバへ送信されることによるアップリンク用の無線周波数リソースの無駄な利用を防ぎ、アップリンク用の無線周波数リソースを効率的に利用することができる。

実施の形態１に係る車載情報装置を備えたサーバシステムの構成図である。 実施の形態１に係る車載情報装置、検出装置及び車両用サーバの内部構成例を示すブロック図である。 図３Ａ及び図３Ｂは、実施の形態１に係る車載情報装置のハードウェア構成例を示す図である。 車両側情報の送信タイミングのクラス分けの一例を示す表である。 検出装置による処理を示すフローチャートである。 実施の形態１に係る車載情報装置による処理を示すフローチャートである。 実施の形態１に係る車両用サーバによる処理を示すフローチャートである。 実施の形態１に係る車載情報装置による処理を示すフローチャートである。 実施の形態１に係る車載情報装置による処理を示すフローチャートである。 実施の形態１に係る車両用サーバによる処理を示すフローチャートである。 図１０のフローチャートで示す処理の様子を示すイメージ図である。

　以下、この発明をより詳細に説明するために、この発明を実施するための形態について、添付の図面に従って説明する。
実施の形態１．
　図１は、実施の形態１に係る車載情報装置１を備えたサーバシステムの構成図である。当該サーバシステムは、車載情報装置１、検出装置２及び車両用サーバ３等を有する。車載情報装置１及び検出装置２は、複数台の車両のそれぞれに１又は複数設けられた装置である。図１においては、車載情報装置１及び検出装置２が設けられた３台の車両が示されている。車両用サーバ３は、車両とは別の場所に、１台又は複数台設けられた車外サーバである。各車両に設けられた各車載情報装置１と各検出装置２とは、当該車両内のローカルな通信網例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）により、互いに通信可能となっている。各車載情報装置１と各車両用サーバ３とは、携帯電話網等を利用した無線通信により、互いに通信可能となっている。

　車載情報装置１は、検出装置２が送信した車両側情報を、車両用サーバ３へ送信する。車載情報装置１は、例えば、携帯電話網を利用して車外通信を行うナビゲーション装置又はテレマティックス装置である。車両側情報は、例えば、移動速度又は渋滞状況等を示す情報である。車両側情報の詳細な具体例については、図４を用いて後述する。車載情報装置１は、車両側情報を車両用サーバ３へ送信する際、車両用サーバ３から受信したクラス設定情報を用いて、車両側情報の送信タイミングとして設定されたタイミングで送信する。クラス設定情報は、車両側情報の送信タイミングのクラス分けを示す情報である。
　また、車載情報装置１は、共通情報が送信不可の場合に、その旨を示す送信不可メッセージを車両用サーバ３へ送信する。共通情報とは、他の車両と共通する車両側情報である。

　車載情報装置１には、アプリケーションがインストールされている。当該アプリケーションは、車両にサービスを提供するためのものである。例えば、図１に示す３台の車両のうちの１つには、車両側アプリケーションＡ、車両側アプリケーションＢ及び車両側アプリケーションＣがインストールされており、また、他の１台には、車両側アプリケーションＡ及び車両側アプリケーションＢがインストールされており、さらに他の１台には、車両側アプリケーションＡ及び車両側アプリケーションＤがインストールされている。

　検出装置２は、車両側情報を車両の車載情報装置１へ送信する。検出装置２は、各種のセンサ及びカメラ等を用いて移動速度又は渋滞状況等を検出し、検出結果を用いて車両側情報を作成する。

　車両用サーバ３は、車両側情報の送信タイミングのクラス分けを示すクラス設定情報を、車載情報装置１へ送信する。車両用サーバ３は、図１においては４台設けられており、４台の車両用サーバ３それぞれが、クラス設定情報を送信する。車両用サーバ３には、サービスを提供するためのアプリケーションがインストールされている。例えば、図１では、サーバ側アプリケーションＡがインストールされた車両用サーバ３、サーバ側アプリケーションＢがインストールされた車両用サーバ３、サーバ側アプリケーションＣがインストールされた車両用サーバ３、及び、サーバ側アプリケーションＤがインストールされた車両用サーバ３が示されている。
　サーバ側アプリケーションＡは、車両側アプリケーションＡと対応しており、サーバ側アプリケーションＡと車両側アプリケーションＡとの協働により、車両側情報を用いたサービスが提供される。このことは、サーバ側アプリケーションＢ～サーバ側アプリケーションＤについても同様である。

　サービスとしては、例えば、ドライブレコーダサービス、自動運転サービス及び故障診断サービス等が挙げられ、各サービスは、車載情報装置１から送られた車両側情報を用いて処理を行う。例えばドライブレコーダサービスは、車両をリモートで監視する処理、車両側情報をログとして収集する処理、及び、交通事故発生時に証拠となる車両側情報を収集する処理等を行う。

　なお、図１では、車載情報装置１が設けられた車両として３台を図示したが、車両用サーバ３と通信する車両の台数は、これに限られるものではない。また同様に、車両用サーバ３の台数も図１に示す４台に限られるものではない。また、図１では、サーバ側アプリケーションごとに、つまりサービスごとに車両用サーバ３を１台ずつ設けた場合を示したが、１台の車両用サーバ３に複数の異なるサーバ側アプリケーションがインストールされ、当該１台の車両用サーバ３が複数の異なるサービスを提供するようにしてもよい。

　図２は、車載情報装置１、検出装置２及び車両用サーバ３の内部構成例を示すブロック図である。図２では、１台の車両に設けられた車載情報装置１及び検出装置２についてのみ詳細に示し、他の車両に設けられた車載情報装置１及び検出装置２については、図示を簡略化又は省略している。
　検出装置２は、状態検出部２０、検出側情報作成部２１及び車内送信部２２を有する。
　状態検出部２０は、各種のセンサ及びカメラ等であり、車両、当該車両のユーザ、及び、当該車両の周辺環境等の状態を検出し、検出結果を検出側情報作成部２１に出力する。
　検出側情報作成部２１は、当該検出結果を用いて車両側情報を作成する。
　車内送信部２２は、検出側情報作成部２１が作成した車両側情報を、車載情報装置１へ送信する。

　車載情報装置１は、車内受信部１０、情報蓄積部１１、受信部１２、クラス設定解析部１３、送信判定部１４、情報作成部１５及び送信部１６を有する。
　車内受信部１０は、検出装置２との通信を担い、検出装置２から車両側情報を受信する。車内受信部１０は、受信した車両側情報を情報蓄積部１１に出力する。
　情報蓄積部１１は、車内受信部１０が出力した車両側情報を、不図示の記憶部に蓄積する。また、情報蓄積部１１は、当該記憶部に蓄積されている車両側情報を、処理状況に応じて破棄する。

　受信部１２は、車両用サーバ３との通信を担い、車両用サーバ３からクラス設定情報等の各種の情報を受信する。受信部１２は、受信したクラス設定情報をクラス設定解析部１３に出力する。また、受信部１２は、車載情報装置１と車両用サーバ３との間の無線通信に関する情報である第１無線情報を、送信判定部１４及び情報作成部１５に出力する。第１無線情報は、受信部１２が検出した電波強度等を示す情報であり、受信部１２により作成される。

　クラス設定解析部１３は、受信部１２が出力したクラス設定情報を解析し、情報作成部１５で使用可能なクラス設定情報としてフォーマット変換等して、情報作成部１５に出力する。
　送信判定部１４は、共通情報が、送信不可であるかを判定する。既に述べたように、共通情報とは、他の車両と共通する車両側情報である。送信判定部１４は、判定結果を情報作成部１５に出力する。なお、送信判定部１４による判定の詳細については、後述する。

　情報作成部１５は、情報蓄積部１１によって不図示の記憶部に蓄積されている車両側情報を、情報蓄積部１１を介して取得し、当該車両側情報に更に自車両の車両識別情報及び車両種別等の情報を付加した形式の車両側情報を作成して、送信部１６に出力する。その際、情報作成部１５は、クラス設定解析部１３が出力したクラス設定情報、及び、送信部１６が出力した第２無線情報を用いて処理を行う。第２無線情報とは、送信部１６が無線基地局から受信したコーディング方式等を示す情報である。当該無線基地局は、車載情報装置１と車両用サーバ３との間で通信を仲介する。つまり、情報作成部１５は、第２無線情報を用いることでデータ量を調整して車両側情報を作成し、クラス設定情報に示される送信タイミングに従って、作成した車両側情報を送信部１６に出力する。車両識別情報は、例えば自車両のプレートナンバーを示す情報であり、車両種別は、例えば大型車か小型車かを示す情報、及び車種等を示す情報である。情報作成部１５がこれらの情報を車両側情報に付加することで、車両側情報を利用する車両用サーバ３等は、車両側情報に対応する車両を特定することが可能となる。
　また、情報作成部１５は、送信判定部１４が出力した判定結果が送信不可を示している場合、共通情報が送信不可である旨の送信不可メッセージを作成し、送信部１６に出力する。
　情報作成部１５の機能は、車両側アプリケーションにより制御される。

　送信部１６は、車両用サーバ３との通信を担い、情報作成部１５が出力した車両側情報及び送信不可メッセージを順次車両用サーバ３へ送信する。これにより、車両側情報は、クラス設定情報でそれぞれ設定された送信タイミングのクラスに応じたタイミングで、車両用サーバ３へ送信される。また、送信部１６は、無線基地局から受信した第２無線情報を、送信判定部１４及び情報作成部１５に出力する。

　車両用サーバ３は、受信部３０、データパーサ部３１、サービス実行部３２、クラス設定部３３、車両選択部３４及び送信部３５を有する。
　受信部３０は、車載情報装置１との通信を担い、車載情報装置１が送信した車両側情報及び送信不可メッセージ等を受信する。受信部３０は、当該車両側情報及び送信不可メッセージ等をデータパーサ部３１に出力する。

　データパーサ部３１は、受信部３０が車載情報装置１から受信した各種の情報の出力先を制御し、各情報を適切な構成部へ振り分ける。例えば、データパーサ部３１は、受信部３０が出力した車両側情報を、サービス実行部３２に対しては全て出力する。その一方で、データパーサ部３１は、受信部３０が出力した車両側情報を、車両選択部３４に対しては現在位置及び移動速度等の車両側情報に限って出力する。また例えば、データパーサ部３１は、受信部３０が出力した送信不可メッセージを、車両選択部３４にのみ出力する。

　サービス実行部３２は、データパーサ部３１が出力した車両側情報を用いて、サービスを実行する。例えばドライブレコーダサービスの場合、サービス実行部３２は、車両が異常な運転状態に無いか、ドライバが異常な状態に無いか、または、車両部品若しくは車両装置が故障していないかなどを判定する。サービス実行部３２による実行結果は、送信部３５を介して対応する車両に適宜送信される。サービス実行部３２の機能は、サーバ側アプリケーションにより制御される。
　また、サービス実行部３２は、サービスの実行のためにどのような車両側情報がどのようなタイミングで車両用サーバ３に送信されるべきかを示す要求情報を、クラス設定部３３に出力する。

　クラス設定部３３は、サービス実行部３２が出力した要求情報を用いて、車両側情報の送信タイミングのクラス分けを設定する。クラス設定部３３は、クラス分けの設定内容が示されたクラス設定情報を、送信部３５及びデータパーサ部３１に出力する。

　車両選択部３４は、共通情報を送信させる対象車両を、複数の車両の中から選択する。なお、車両選択部３４による選択の詳細については、後述する。車両選択部３４は、どの車両を対象車両として選択したかの情報をサービス実行部３２に出力する。これにより、サービス実行部３２は、クラス設定部３３に出力する要求情報を作成するとともに、どの車両の車両側情報の中に共通情報が存在するかを知ることができる。
　送信部３５は、車載情報装置１との通信を担い、クラス設定部３３が出力したクラス設定情報等の各種の情報を車載情報装置１へ送信する。

　次に、車載情報装置１のハードウェア構成例について、図３Ａ及び図３Ｂを用いて説明する。
　車載情報装置１の情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各機能は、処理回路により実現される。当該処理回路は、専用のハードウェアであっても、メモリに格納されるプログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）であってもよい。ＣＰＵは、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサ又はＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）とも呼ばれる。また、車載情報装置１の車内受信部１０は、車内通信装置１０４により実現され、受信部１２及び送信部１６は、通信装置１０５により実現される。車内通信装置１０４は、例えばＣＡＮである。また、通信装置１０５は、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）等に対応した無線通信デバイスである。

　図３Ａは、情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能を、専用のハードウェアである処理回路１０１で実現した場合のハードウェア構成例を示す図である。処理回路１０１は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、若しくはＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）、又はこれらを組み合わせたものが該当する。情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能を別個の処理回路１０１を組み合わせて実現してもよいし、各部の機能を１つの処理回路１０１で実現してもよい。

　図３Ｂは、情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能を、メモリ１０２に格納されるプログラムを実行するＣＰＵ１０３で実現した場合のハードウェア構成例を示す図である。この場合、情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能は、ソフトウェア、ファームウェア、又はソフトウェアとファームウェアとの組合せにより実現される。ソフトウェア及びファームウェアはプログラムとして記述され、メモリ１０２に格納される。ＣＰＵ１０３は、メモリ１０２に格納されたプログラムを読み出して実行することにより、情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能を実現する。すなわち、車載情報装置１は、後述する図６、図８及び図９のフローチャートで示す各ステップの処理が結果的に実行されることになるプログラム等を格納するためのメモリ１０２を有する。また、これらのプログラムは、情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の手順又は方法をコンピュータに実行させるものであるとも言える。ここで、メモリ１０２は、例えば、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、フラッシュメモリ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭ）、若しくはＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ　Ｅｒａｓａｂｌｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　ＲＯＭ）等の、不揮発性若しくは揮発性の半導体メモリ、又は、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、若しくはＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）等のディスク状の記録媒体等が該当する。

　なお、情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能について、一部を専用のハードウェアで実現し、一部をソフトウェア又はファームウェアで実現するようにしてもよい。例えば、情報蓄積部１１及びクラス設定解析部１３については専用のハードウェアとしての処理回路でその機能を実現し、送信判定部１４及び情報作成部１５については処理回路がメモリに格納されたプログラムを読み出して実行することによってその機能を実現することが可能である。

　このように、処理回路は、ハードウェア、ソフトウェア、ファームウェア又はこれらの組合せによって、上記の情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５の各部の機能を実現することができる。

　なお、検出装置２の検出側情報作成部２１についても、車載情報装置１の情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５と同様に、図３Ａに示す処理回路１０１、又は、図３Ｂに示すメモリ１０２及びＣＰＵ１０３で実現することができる。また、検出装置２の車内送信部２２は、車内通信装置１０４と同様の通信装置で実現することができる。

　また、車両用サーバ３のデータパーサ部３１、サービス実行部３２、クラス設定部３３及び車両選択部３４についても、車載情報装置１の情報蓄積部１１、クラス設定解析部１３、送信判定部１４及び情報作成部１５と同様に、図３Ａに示す処理回路１０１、又は、図３Ｂに示すメモリ１０２及びＣＰＵ１０３で実現することができる。また、車両用サーバ３の受信部３０及び送信部３５は、通信装置１０５と同様の通信装置で実現することができる。

　次に、車両側情報について詳細に説明する。車両側情報は、例えば、周期的に車両用サーバ３に送信する情報、車両においてイベントが発生するごとに送信する情報、情報の内容が変化するごとに送信する情報、又は、車両において緊急事態が発生した際に送信する情報として、送信タイミングがそれぞれクラス分けされている。

　また、周期的に車両用サーバ３に送信する情報は、例えば、１秒周期又は１分周期の短周期で送信する情報と、１時間周期又は１日周期の長周期で送信する情報として、更に送信タイミングがクラス分けされている。または、周期的に車両用サーバ３に送信する情報は、時間ではなく距離を用いた周期として、車両が１メートル移動するたびに送信する短周期の情報と、車両が１キロメートル移動するたびに送信する長周期の情報として、送信タイミングがクラス分けされてもよい。

　以下では、ドライブレコーダサービスでの適用を例に説明する。
　図４は、ドライブレコーダサービスにおける、車両側情報の送信タイミングのクラス分けの一例を示す表である。
　短周期クラス、長周期クラス、イベントクラス、状態変化クラス、及び、緊急事態発生クラスの５つのクラスが設定されている。

　短周期クラスは、送信タイミングが１秒周期となるクラスである。図４に示すような、車両情報、ナビ情報及び通信情報等が該当する。
　長周期クラスは、送信タイミングが１時間周期となるクラスである。図４に示すような、メンテナンス情報及び路面情報等が該当する。
　イベントクラスは、送信タイミングがエンジン始動時又はエンジン停止時となるクラスである。図４に示すような、メンテナンス情報、ナビ情報、個人情報及び通信情報等が該当する。

　状態変化クラスは、送信タイミングが情報の内容が変化したときとなるクラスである。図４に示すような、車両情報、ナビ情報、ドライバ情報及び道路情報等が該当する。例えば、車両のユーザが目的地を変更するなどしてナビ情報に変化が生じたとき、ナビ情報の送信タイミングとなる。
　緊急事態発生クラスは、送信タイミングが事故発生時又は故障発生時となるクラスである。図４に示すような、センサ情報、連続運転時間を含んだ、状態変化クラスと同様のドライバ情報、及び、短周期クラスと同様の車両情報とナビ情報と通信情報等が該当する。

　図４に示す例では、長周期クラスの路面情報と、状態変化クラスの道路情報とが、他の車両と共通する共通情報となる。つまり、当該路面情報及び当該道路情報は、さほど遠くの車両同士でなければ、同じ内容又はほぼ同じ内容の情報となる。なお、状態変化クラスの道路情報の交差点状態とは、例えば、右折待ち等の交差点での混み具合を指す。どの車両側情報が共通情報であるかは、車両用サーバ３から車載情報装置１に予め通知されている。

　なお、送信タイミングのクラス分けは、サービスごとに独立して様々に設定される。つまり、車両が複数のサービスを受ける場合、図４では短周期クラスに設定されている移動速度等の車両情報が、別のサービス例えば故障診断サービスでは、長周期クラスに設定されるなどする。

　次に、上記のように構成された車載情報装置１、検出装置２及び車両用サーバ３の処理について、図５～図１０に示すフローチャートを用いて説明する。
　図５は、検出装置２が、車載情報装置１へ車両側情報を送信する際の処理を示すフローチャートである。図５に示す処理は、車両のエンジンがＯＮになると、繰り返し行われる。
　状態検出部２０は、図４に示すような、車両、当該車両のユーザ、及び、当該車両の周辺環境等に関する様々な状態を検出し、検出結果を検出側情報作成部２１に出力する（ステップＳＴ１）。

　続いて、検出側情報作成部２１は、状態検出部２０が出力した検出結果を用いて、車両側情報を作成する（ステップＳＴ２）。このとき、検出側情報作成部２１は、検出結果に時刻情報が付加された形式の車両側情報を作成して、車内送信部２２に出力する。
　続いて、車内送信部２２は、検出側情報作成部２１が作成した車両側情報を、車載情報装置１へ送信する（ステップＳＴ３）。

　図６は、検出装置２が送信した車両側情報を、車載情報装置１が受信し管理する際の処理を示すフローチャートである。図６に示す処理は、検出装置２が車両側情報を送信し始めた後に、繰り返し行われる。
　車内受信部１０は、検出装置２から車両側情報を受信する（ステップＳＴ１０）。
　続いて、車内受信部１０は、受信した車両側情報を情報蓄積部１１に出力し、情報蓄積部１１は、当該車両側情報を不図示の記憶部に記憶させて蓄積する（ステップＳＴ１１）。
　その後、情報蓄積部１１は、不図示の記憶部に記憶されている車両側情報を情報作成部１５に渡した場合、当該記憶部からその渡した車両側情報を消去して、破棄する（ステップＳＴ１２）。

　図７は、車両用サーバ３が車載情報装置１へクラス設定情報を送信する際の処理を示すフローチャートである。図７に示す処理は、例えば、サービスを受けるために車載情報装置１が当該サービスを提供する車両用サーバ３と初めて通信したとき等に行われる。
　サービス実行部３２は、サービスの実行のためにどのような車両側情報がどのようなタイミングで車両用サーバ３に送信されるべきかを示す要求情報を、クラス設定部３３に出力する（ステップＳＴ２０）。

　続いて、クラス設定部３３は、サービス実行部３２が出力した要求情報を用いて、クラス設定情報を作成する（ステップＳＴ２１）。なお、このときクラス設定部３３は、各車両側情報のデータ量を指定する情報、又は、サービスを識別可能なデータであって車両側情報の先頭に挿入されるべきパイロットデータ等をクラス設定情報に含める。クラス設定部３３は、作成したクラス設定情報を、送信部３５に出力する。
　続いて、送信部３５は、クラス設定部３３が出力したクラス設定情報を、車載情報装置１へ送信する（ステップＳＴ２２）。

　図８は、車載情報装置１が、車両用サーバ３が送信したクラス設定情報を用いて、車両側で収集された車両側情報を車両用サーバ３へ送信する際の処理を示すフローチャートである。
　受信部１２は、車両用サーバ３が送信したクラス設定情報を受信する（ステップＳＴ３０）。受信部１２は、受信したクラス設定情報を、クラス設定解析部１３に出力する。
　続いて、クラス設定解析部１３は、受信部１２が出力したクラス設定情報を解析する（ステップＳＴ３１）。クラス設定解析部１３は、クラス設定情報を解析すると、情報作成部１５で使用可能なクラス設定情報としてフォーマット変換等して、情報作成部１５に出力する。

　続いて、情報作成部１５は、今が短周期クラス又は長周期クラスの送信タイミングであるかを判定する（ステップＳＴ３２）。このとき、情報作成部１５は、短周期クラスの車両側情報を前回作成してから短周期クラスの周期が経過したか、また、長周期クラスの車両側情報を前回作成してから長周期クラスの周期が経過したかに基づき判定をする。

　短周期クラスの周期及び長周期クラスの周期がどちらも経過していない場合（ステップＳＴ３２；ＮＯ）、情報作成部１５は、後述のステップＳＴ３４の処理を行う。
　一方、短周期クラスの周期又は長周期クラスの周期が経過した場合（ステップＳＴ３２；ＹＥＳ）、情報作成部１５は、周期が経過したクラスの車両側情報を作成する（ステップＳＴ３３）。情報作成部１５が作成した車両側情報は、送信部１６を介して車両用サーバ３へ送信される。なお、情報作成部１５が作成する車両側情報は、情報蓄積部１１によって不図示の記憶部に蓄積されている時刻情報付きの車両側情報に更に、車両の車両識別情報及び車両種別等の情報を付加した形式の車両側情報である。

　続いて、情報作成部１５は、今がイベントクラスの送信タイミングであるか、つまり、エンジン始動又はエンジン停止等のイベントが発生したかを判定する（ステップＳＴ３４）。
　イベントが発生していない場合（ステップＳＴ３４；ＮＯ）、情報作成部１５は、後述のステップＳＴ３６の処理を行う。
　一方、イベントが発生した場合（ステップＳＴ３４；ＹＥＳ）、情報作成部１５は、イベントクラスの車両側情報を作成する（ステップＳＴ３５）。情報作成部１５が作成した車両側情報は、送信部１６を介して車両用サーバ３へ送信される。上記したように、情報作成部１５が作成する車両側情報は、時刻情報、車両の車両識別情報及び車両種別等の情報が付加された形式の車両側情報である。

　続いて、情報作成部１５は、今が状態変化クラスの送信タイミングであるか、つまり、状態変化クラスの車両側情報であって、情報の内容が変化した車両側情報があるかを判定する（ステップＳＴ３６）。
　情報の内容が変化した車両側情報が無い場合（ステップＳＴ３６；ＮＯ）、情報作成部１５は、後述のステップＳＴ３８の処理を行う。
　一方、情報の内容が変化した車両側情報がある場合（ステップＳＴ３６；ＹＥＳ）、情報作成部１５は、当該車両側情報を時刻情報、車両の車両識別情報及び車両種別等の情報が付加された形式にして、車両用サーバ３へ送信する車両側情報を作成する（ステップＳＴ３７）。情報作成部１５が作成した車両側情報は、送信部１６を介して車両用サーバ３へ送信される。

　続いて、情報作成部１５は、今が緊急事態発生クラスの送信タイミングであるか、つまり、事故又は故障が発生したかを判定する（ステップＳＴ３８）。
　事故及び故障が発生していない場合（ステップＳＴ３８；ＮＯ）、情報作成部１５は、１ループ分の処理を終え、その後適宜のタイミングで再度ステップＳＴ３２からの処理を開始する。
　一方、事故又は故障が発生した場合（ステップＳＴ３８；ＹＥＳ）、情報作成部１５は、緊急事態発生クラスの車両側情報を作成する（ステップＳＴ３９）。情報作成部１５が作成した車両側情報は、送信部１６を介して車両用サーバ３へ送信される。上記したように、情報作成部１５が作成する車両側情報は、時刻情報、車両の車両識別情報及び車両種別等の情報が付加された形式の車両側情報である。
　情報作成部１５は、その後、緊急事態発生クラス以外の車両側情報の作成を中止する（ステップＳＴ４０）。

　なお、ここではドライブレコーダサービスを例に挙げて説明しているが、車両がドライブレコーダサービスに加えて他のサービスも受ける場合、当該他のサービスでも１秒周期の短周期クラスが設定されていることがある。この場合、情報作成部１５は、ドライブレコーダサービスでの短周期クラスの車両側情報と、当該他のサービスでの短周期クラスの車両側情報とを、連結した状態で送信部１６に出力し、送信部１６は、連結された状態でそれらの車両側情報を送信する。情報作成部１５が、クラス設定情報に含まれるサービス識別用のパイロットデータ等を適宜挿入して異なるサービスの車両側情報を連結することで、車両用サーバ３のデータパーサ部３１は、自身の車両用サーバ３が提供するサービスの車両側情報のみを抽出することができる。

　また、情報作成部１５は、情報蓄積部１１により不図示の記憶部に蓄積されている車両側情報に、一次処理を施した上で、車両の車両識別情報等を付加した車両側情報を作成してもよい。例えば、図４のイベントクラスのメンテナンス情報の故障診断結果は、各車内機器についてそれぞれの故障の有無を示した車両側情報として不図示の記憶部に蓄積されている。情報作成部１５は、一次処理として、当該車両側情報をいずれの車内機器も故障が無いか、又は、故障している車内機器が１つでも有るかを示す車両側情報として作成し直す。そして情報作成部１５は、二次処理として、一次処理で作成した車両側情報に、車両の車両識別情報等を付加する。

　図９は、車載情報装置１が、共通情報が送信不可であるかを判定する際の処理を示すフローチャートである。図９に示す処理は、車載情報装置１が車両用サーバ３からクラス設定情報を受信している場合に、適宜のタイミングで行われる。例えば、図９に示す処理は、車両が後述の図１１に示す各エリアの境界をまたいで、新しいエリアに進入したときに行われる。
　送信判定部１４は、共通情報を他の車両側情報と共に送信する場合に必要なスループットを算出する（ステップＳＴ５０）。このときの他の車両側情報とは、共通情報と異なる車両側情報であって、他の車両と共通しない車両側情報である。例えば、図４の例では、長周期クラスの路面情報は共通情報である。通常は、車載情報装置１が長周期クラスの車両側情報を車両用サーバ３へ送信する際、その中に路面情報は含まれていない。路面情報を例にすると、ステップＳＴ５０で送信判定部１４は、路面情報を含む長周期クラスの車両側情報がどれくらいのデータ量であるかを求め、必要なスループットを算出する。各車両側情報のデータ量の目安は、例えば、車載情報装置１の不図示の記憶部に予め記憶されるなどしている。

　続いて、送信判定部１４は、車両用サーバ３へ情報を送信する際に期待できるスループットを推測し、また、車載情報装置１の処理負荷を検出する（ステップＳＴ５１）。このとき、送信判定部１４は、受信部１２が出力する第１無線情報と、送信部１６が出力する第２無線情報とを用いてスループットを推測する。第２無線情報には、通信状態を示す情報として、車載情報装置１と車両用サーバ３との間で通信を仲介する無線基地局が指定する送信部１６からの送信時のコーディング方式、つまり、割り当てられるアップリンク用の無線周波数リソースであるスループットの理論値が示されている。また、第１無線情報には、通信状態を示す電波強度等が示されている。弱電界域では実際のスループットは理論値よりも低くなる可能性があるので、送信判定部１４は、第２無線情報に加え第１無線情報を用いて、期待できるスループットを推測する。

　また、送信判定部１４は、車載情報装置１の処理負荷として、例えば車載情報装置１のＣＰＵ負荷率を検出する。

　続いて、送信判定部１４は、ステップＳＴ５０で算出した必要なスループットが、ステップＳＴ５１で推測した期待できるスループットを超えるかを判定する（ステップＳＴ５２）。
　必要なスループットが、期待できるスループットを超える場合（ステップＳＴ５２；ＹＥＳ）、送信判定部１４は、共通情報が送信不可であると判定し、判定結果を情報作成部１５に出力する。すると情報作成部１５は、送信不可メッセージを作成する（ステップＳＴ５３）。情報作成部１５は、作成した送信不可メッセージを送信部１６へ出力する。なお、情報作成部１５は、車両の車両識別情報及び車両種別等の情報を付加して、送信不可メッセージを作成する。
　続いて、送信部１６は、送信不可メッセージを車両用サーバ３へ送信する（ステップＳＴ５４）。

　一方、必要なスループットが、期待できるスループット以下の場合（ステップＳＴ５２；ＮＯ）、送信判定部１４は、ステップＳＴ５１で検出した車載情報装置１の処理負荷が、閾値以上であるかを判定する（ステップＳＴ５５）。例えば、ステップＳＴ５１で送信判定部１４が車載情報装置１のＣＰＵ負荷率を検出した場合を例にする。この場合、閾値はＣＰＵ負荷率７５％程度に設定される。なお、送信判定部１４は、ＣＰＵ負荷率について、一定時間分の平均を取るなどして、瞬間的な負荷の変動を除いた定常的なＣＰＵ負荷率のみを検出するようにしてもよい。
　車載情報装置１の処理負荷が、閾値以上である場合（ステップＳＴ５５；ＹＥＳ）、送信判定部１４は、共通情報が送信不可であると判定し、判定結果を情報作成部１５に出力する。すると、情報作成部１５によるステップＳＴ５３の処理、及び、送信部１６によるステップＳＴ５４の処理が行われる。

　一方、車載情報装置１の処理負荷が、閾値未満である場合（ステップＳＴ５５；ＮＯ）、送信判定部１４は、共通情報が送信可能であると判定する。この場合、送信部１６による送信不可メッセージの送信は行われない。

　図１０は、車両用サーバ３が、共通情報を送信させる対象車両を選択する際の処理を示すフローチャートである。また、図１１は、当該処理の様子を示すイメージ図である。図１１に示すように、車載情報装置１、検出装置２及び車両用サーバ３により構成されるサーバシステムでは、地図上のエリアが例えば１キロメートル四方で区切られて、複数のエリアが定義されている。図１１では、複数のエリアとして、エリアａ１～ａ４を示している。
　サービス実行部３２は、共通情報の取得状況等から、共通情報を得たいエリアを対象エリアとして設定する。ここでは、図１１のエリアａ４が対象エリアとして設定されたとして説明する。

　サービス実行部３２により対象エリアが設定されると、車両選択部３４は、対象エリアとなったエリアａ４の選定マップを作成する（ステップＳＴ６０）。
　車両選択部３４は、選定マップを作成するにあたり、エリアａ４について得られている過去のスループット計測結果を取得する。当該スループットは、車載情報装置１から車両用サーバ３へ向かう方向のスループットである。このため、車両用サーバ３の受信部３０では、車載情報装置１から車両側情報を受信するたびに、そのときのスループットを検出し、受信した車両側情報と共にデータパーサ部３１に出力する。データパーサ部３１は、受信部３０が出力した車両側情報に示される現在位置とスループットとを紐付けて、不図示の記憶部に記憶させる。車両選択部３４は、当該記憶部から、過去のスループット計測結果を取得することができる。
　また、車両選択部３４は、選定マップを作成するにあたり、エリアａ４内の各車両に関しての、目的地、移動速度及び現在位置を取得する。これは、車載情報装置１から受信した車両側情報を用いることで、車両選択部３４による取得が可能である。

　車両選択部３４は、過去のスループット計測結果を対応する地点にそれぞれマッピングする。また、車両選択部３４は、エリアａ４内の車両をそれぞれの現在位置にマッピングする。これにより、選定マップが作成される。

　続いて、車両選択部３４は、選定マップを用いて対象車両を選択する（ステップＳＴ６１）。
　選定マップを用いた対象車の選択方法は、例えば、以下に示す方法が挙げられる。

　まず、車両選択部３４は、過去のスループット計測結果で最もスループットが大きい地点を、対象地点に設定する。図１１の例であれば、過去のスループット計測結果が５Ｍｂｐｓを示した地点が対象地点に設定される。
　続いて、車両選択部３４は、対象地点をまだ通過しておらず、今後通過するであろう１台又は複数台の車両を、各車両の現在位置及び目的地を用いて抽出する。そして、車両選択部３４は、抽出した車両の中から任意の１台を選択する。
　続いて、車両選択部３４は、選択した任意の１台との移動速度の差違が±１０ｋｍ／ｈ程度以内となる他の車両を、抽出した車両の中から更に抽出する。このときに更に抽出された車両と、選択した任意の１台とが、候補車両となる。
　続いて、車両選択部３４は、候補車両となった車両について、当該車両の車載情報装置１から車両用サーバ３へ情報を送信する際に必要なスループットを推測する。このときの推測には、車両が受けるサービスの数である、サービスの加入数が用いられる。例えば、車両選択部３４は、サービスで必要となる平均的なスループットを不図示の記憶部に記録しており、当該平均的なスループットにサービスの加入数を乗じて、必要なスループットを推測する。車両が加入しているサービスの数については、当該車両の車両側情報として、車両用サーバ３が取得可能である。または、車両から具体的なサービス名を車両用サーバ３が取得し、サービスごとに予め得られた平均的な必要スループットを用いて、車両選択部３４は、スループットの推測を行ってもよい。
　続いて、車両選択部３４は、対象地点でのスループット、図１１の例であれば５Ｍｂｐｓと、候補車両となった車両について推測した必要なスループットとを比較する。そして車両選択部３４は、候補車両の中で、対象地点でのスループットから推測した必要なスループットを引いた差分値で候補車両の各車両をランク付けし、差分値が最も大きい車両を、対象車両として選択する。

　なお、スループットは、車両の移動速度にも影響されることから、移動速度が極端に異なる車両同士が候補車両になると、差分値だけで候補車両の各車両をランク付けしたとしても適切なランク付けになりにくいので、上記では移動速度を考慮して候補車両が選定されている。

　車両選択部３４は、対象車両として選択した車両をサービス実行部３２に通知する（ステップＳＴ６２）。サービス実行部３２は、送信部３５を介して、共通情報の送信要求を、対象地点の情報と共に対象車両に通知する。

　なお、受信部３０が、対象車両から送信不可メッセージを受信した場合、車両選択部３４は、当該対象車両を選定マップから除外して、再度ステップＳＴ６１の処理を行う。例えば、車載情報装置１が共通情報の送信要求を受信した場合に再度図９で示した処理を行うようにして、その結果受信部３０が対象車両から送信不可メッセージを受信した場合、車両選択部３４は、当該対象車両を選定マップから除外する。または、設定時間遡った過去から現在までに、受信部３０が既に対象車両から送信不可メッセージを受信していた場合、車両選択部３４は、当該対象車両を選定マップから除外するようにしてもよい。
　また、対象車両からの共通情報の受信に失敗した場合も、車両選択部３４は、当該対象車両を選定マップから除外して、再度ステップＳＴ６１の処理を行う。例えば、車両選択部３４が推測した必要なスループットと、実際に必要なスループットとが大きくずれており、実際に必要なスループットが対象地点でのスループットを超える場合、又は、予期せぬ通信障害が発生した場合等に、車両用サーバ３は、共通情報の受信に失敗する。

　また、対象車両からの共通情報の送信に関しては、対象車両の車載情報装置１が、クラス設定情報で設定されたタイミングに拘らず、対象地点に到達したタイミングで共通情報を他の車両側情報と共に送信するようにしてよい。または、そもそも車両選択部３４が、車両側情報の取得状況からして、対象地点付近で共通情報のクラスの送信タイミングが到来しそうな車両を対象車両として選択し、対象車両の車載情報装置１が、クラス設定情報で設定されたタイミングで共通情報を他の車両側情報と共に送信するようにしてもよい。

　また、対象地点として複数の対象地点が設定されてもよい。例えば、図１１であれば、５Ｍｂｐｓのスループットの地点に加え、３Ｍｂｐｓのスループットの地点も、対象地点として設定されてもよい。

　また、車両選択部３４は、対象エリアに設定したエリアａ４内の車両との実際の通信時に受信部３０で検出したスループットと、選定マップの作成に使った過去のスループット計測結果とを比較して、例えば１Ｍｂｐｓ以上の差違がある場合、対象エリアに設定したエリア内の車両との実際の通信時に受信部３０で検出したスループットを、次回のエリアａ４の選定マップ作成の際に使用できるようにするとよい。

　このように、車載情報装置１は、車両側情報をそれぞれ設定された送信タイミングで車両用サーバ３へ送信することに加え、共通情報については、送信不可であると判定した場合にはその旨を車両用サーバ３に送信して、共通情報の送信は行わない。これにより、全ての車両から共通情報が重複して車両用サーバ３へ送信されることによるアップリンク用の無線周波数リソースの無駄な利用が防がれて、アップリンク用の無線周波数リソースが効率的に利用される。

　なお、上記では、車載情報装置１が例えばナビゲーション装置であるとしたが、車載情報装置１は車両内に持ち込まれたスマートフォン等の携帯端末であってもよい。当該携帯端末は、検出装置２と無線接続されて、車両側情報を受信する。
　また、上記では、クラス設定情報が車両用サーバ３から車載情報装置１に送信されるとしたが、車載情報装置１で車両側アプリケーションをインストールすると、当該アプリケーションにより自動的に車載情報装置１の不図示の記憶部にクラス設定情報が記憶されるようにしてもよい。または、車載情報装置１は、車両が前回走行した際に取得したクラス設定情報を再度利用するようにしてもよい。この場合、車載情報装置１は、エンジンが切られるなどして車両の使用が終了するたびに、その時点でのクラス設定情報を不図示の記憶部に記憶する。

　また、上記では、車載情報装置１は複数の車両側情報を車両用サーバ３へ送信しており、当該複数の車両側情報の一部が共通情報であるとして説明した。しかしながら、サービスによっては、必要とする車両側情報が１種類だけであり、その１種類の車両側情報が共通情報でもある場合が考えられる。この場合も上記した車載情報装置１及び車両用サーバ３の処理は適用可能であり、車載情報装置１の送信判定部１４は、唯一の車両側情報であり共通情報でもあるその車両側情報を送信する場合に必要なスループットを算出して、共通情報が送信不可であるかの判定に用いる。

　以上より、実施の形態１によれば、送信判定部１４は、共通情報が送信不可であるかを判定し、送信不可と判定された場合に、送信部１６は、送信不可メッセージを車両用サーバ３へ送信することで、全ての車両から共通情報が重複して車両用サーバ３へ送信されることによるアップリンク用の無線周波数リソースの無駄な利用が防がれて、アップリンク用の無線周波数リソースが効率的に利用される。

　なお、本願発明はその発明の範囲内において、実施の形態の任意の構成要素の変形、もしくは実施の形態の任意の構成要素の省略が可能である。

　この発明に係る車載情報装置は、車両側情報を送信する際のアップリンク用の無線周波数リソースを効率的に利用することができるので、車両側情報を用いた処理を行うサービスを提供するサーバシステムに用いるのに適している。

　１　車載情報装置、２　検出装置、３　車両用サーバ、１０　車内受信部、１１　情報蓄積部、１２　受信部、１３　クラス設定解析部、１４　送信判定部、１５　情報作成部、１６　送信部、２０　状態検出部、２１　検出側情報作成部、２２　車内送信部、３０　受信部、３１　データパーサ部、３２　サービス実行部、３３　クラス設定部、３４　車両選択部、３５　送信部、１０１　処理回路、１０２　メモリ、１０３　ＣＰＵ、１０４　車内通信装置、１０５　通信装置。

Claims (9)

1. 　自車両において収集された１又は複数の車両側情報を、当該車両側情報それぞれに設定された送信タイミングのクラスに応じたタイミングで車両用サーバへ送信する送信部と、
   　他の車両と共通する車両側情報である共通情報を送信する場合に必要なスループットと、前記車両用サーバとの通信状態から推測されるスループットと、装置処理負荷とを用いて、当該共通情報が送信不可であるかを判定する送信判定部とを備え、
   　前記送信判定部により送信不可であると判定された場合、前記送信部は、共通情報が送信不可であるメッセージを前記車両用サーバへ送信することを特徴とする車載情報装置。
2. 　車両側情報はそれぞれ、周期的に前記車両用サーバに送信する情報、車両においてイベントが発生するごとに送信する情報、情報の内容が変化するごとに送信する情報、又は、車両において緊急事態が発生した際に送信する情報として、送信タイミングがクラス分けされていることを特徴とする請求項１記載の車載情報装置。
3. 　周期的に前記車両用サーバに送信する情報は、１秒周期又は１分周期で送信する情報と、１時間周期又は１日周期で送信する情報として、送信タイミングがクラス分けされていることを特徴とする請求項２記載の車載情報装置。
4. 　車両側情報を用いた処理を行うサービスを車両が複数受ける場合、当該車両側情報はそれぞれ、サービスごとに送信タイミングのクラスが設定されていることを特徴とする請求項１記載の車載情報装置。
5. 　前記送信部は、送信タイミングが同じクラスに属する複数の車両側情報であって、複数の異なるサービスにそれぞれ関連する当該複数の車両側情報を、連結された状態で送信することを特徴とする請求項４記載の車載情報装置。
6. 　複数の車両から、各車両において収集された車両側情報を受信する受信部と、
   　複数の車両間で共通する車両側情報である共通情報を送信させる対象車両を、複数の地点のそれぞれで得られたスループットと、車両側情報を用いた処理を行うサービスであって各車両が受けるサービスの数とを用いて、複数の車両の中から選択する車両選択部とを備えることを特徴とする車両用サーバ。
7. 　前記対象車両から、共通情報が送信不可であるメッセージを前記受信部が受信した場合、前記車両選択部は、当該対象車両以外の車両の中から対象車両を再度選択することを特徴とする請求項６記載の車両用サーバ。
8. 　自車両において収集された１又は複数の車両側情報を、当該車両側情報それぞれに設定された送信タイミングのクラスに応じたタイミングで車両用サーバへ送信する送信部と、
   　他の車両と共通する車両側情報である共通情報を送信する場合に必要なスループットと、前記車両用サーバとの通信状態から推測されるスループットと、装置処理負荷とを用いて、当該共通情報が送信不可であるかを判定する送信判定部とを備え、
   　前記送信判定部により送信不可であると判定された場合、前記送信部は、共通情報が送信不可であるメッセージを前記車両用サーバへ送信する車載情報装置、
   　及び、
   　請求項６記載の車両用サーバを備えることを特徴とするサーバシステム。
9. 　送信部が、自車両において収集された１又は複数の車両側情報を、当該車両側情報それぞれに設定された送信タイミングのクラスに応じたタイミングで車両用サーバへ送信する第１送信ステップと、
   　送信判定部が、他の車両と共通する車両側情報である共通情報を送信する場合に必要なスループットと、前記車両用サーバとの通信状態から推測されるスループットと、装置処理負荷とを用いて、当該共通情報が送信不可であるかを判定する送信判定ステップと、
   　前記送信判定ステップにより送信不可であると判定された場合、前記送信部が、共通情報が送信不可であるメッセージを前記車両用サーバへ送信する第２送信ステップとを備えることを特徴とする車載情報装置の情報送信方法。

Images