JP2020166328A - 車載通信装置 - Google Patents

Abstract

【課題】交通渋滞の予測精度を向上できる、車載通信装置を提供する。【解決手段】サーバーで予測された交通渋滞の情報を車両の乗員に提供する車載通信装置１は、算出部４，送信部５，促進部６を備える。算出部４は、交通渋滞の予測と実態とのずれの大きさを算出する。送信部５は、交通渋滞の予測を修正するための情報を車両からサーバーに送信する。促進部６は、ずれの大きさが所定量以上である場合に、サーバーに送信される情報の量を増加させる。【選択図】図２

Description

本発明は、サーバーで予測された交通渋滞の情報を車両の乗員に提供する車載通信装置に関する。

従来、ネットワーク上のサーバーで交通渋滞の発生を予測し、その情報を車両に配信することで経路案内や運転支援に活用させる技術が知られている。例えば、日本道路交通情報センターや道路交通情報通信システムセンターから提供される道路交通情報を、ネットワーク経由で車載ナビゲーション装置にダウンロードさせて経路探索に活用する手法が提案されている。また、車載カメラで周辺の様子を撮影し、その画像をサーバーに送信して渋滞予測を実施させるとともに、予測結果を車両に返送する手法も提案されている（特許文献１，２参照）。

特開2015-076078号公報 特開2018-005264号公報

交通渋滞の予測に際し、道路交通情報だけでなく車載カメラの画像を利用する手法は、実際の走行状況をリアルタイムに確認できるという点で有益であり、予測精度の向上に寄与しうる。しかし、カメラ画像のデータ量は大きいため、車両とサーバーとの間の通信量が増大し、ユーザーが負担すべき通信コストが上昇してしまう。また、交通量の多い地域においては、通信インフラにかかる負荷が増大し、ネットワーク全体の遅延や接続障害を招きうる。

一方、ネットワークトラフィックを軽減するために画像のサイズや解像度を低下させれば、車両とサーバーとの間の通信量を削減することが可能である。しかしこの場合、実際の走行状況をサーバー側で適切に確認できなくなり、交通渋滞の予測精度が低下しうる。なお、車載カメラの画像を利用する代わりにレーザーレーダー（LIDER）やミリ波レーダーなどで得られる情報を利用する渋滞予測システムにおいても、同様の課題が生じる。

本件の目的の一つは、上記のような課題に鑑みて創案されたものであり、車両とサーバーとの間のネットワークトラフィックを適正化するとともに、交通渋滞の予測精度を向上させることである。なお、この目的に限らず、後述する「発明を実施するための形態」に示す各構成から導き出される作用効果であって、従来の技術では得られない作用効果を奏することも、本件の他の目的として位置付けることができる。

ここで開示する車載通信装置は、サーバーで予測された交通渋滞の情報を車両の乗員に提供するものであり、算出部，送信部，促進部を備える。前記算出部は、前記交通渋滞の予測と実態とのずれの大きさを算出する。前記送信部は、前記交通渋滞の予測を修正するための情報を前記車両から前記サーバーに送信する。前記促進部は、前記ずれの大きさが所定量以上である場合に、前記サーバーに送信される情報の量を増加させる。

交通渋滞の予測と実態とのずれが大きい場合に、車両からサーバーに送信される情報の量（サーバーにフィードバックされる情報量）を増加させることで、交通渋滞の予測精度を早期に改善して向上させることができる。また、交通渋滞の予測と実態とのずれが小さい場合には、サーバーに送信される情報の量を増加させずに済むことから、車両とサーバーとの間のネットワークトラフィックを適正化することができる。

渋滞予測システムの構成を説明するための模式図である。 車載通信装置の構成を説明するためのブロック図である。 渋滞予測の手順を例示するフローチャートである。 フィードバック情報の処理手順を例示するフローチャートである。 渋滞予測の手法を例示するフローチャートである。 予測乖離通知後の渋滞予測の手法を例示するフローチャートである。 フィードバック情報の送信手順を例示するフローチャートである。

［１．渋滞予測システム］
図１は、車載通信装置１を搭載した車両１０とサーバー２１との協働による渋滞予測システムを表す模式図である。車載通信装置１は、車両１０とその外部との間の無線通信を司る機能を持つ電子制御装置（コンピューター）であり、インターネット２０上のサーバー２１で予測された交通渋滞の情報を乗員に提供する。また、車載通信装置１は、インターネット２０への接続機能だけでなく、測位衛星から発せられる信号を利用して車両１０の走行経路を案内するカーナビゲーション機能を併せ持つ。

インターネット２０上には、交通渋滞を予測するためのサーバー２１のほか、交通情報サーバー２２，天気情報サーバー２３，災害情報サーバー２４，催事情報サーバー２５などが設けられる。交通情報サーバー２２は、交通情報（交通事故，道路工事区間，通行規制区間の情報）を提供するサーバーであり、天気情報サーバー２３は、天候情報（豪雨，降雪，台風などの情報）を提供するサーバーである。また、災害情報サーバー２４は、自然災害情報（山火事，地震，津波などの情報）を提供するサーバーであり、催事情報サーバー２５は、催事情報（行事やイベント，スポーツの試合，コンサートなどの情報）を提供するサーバーである。なお、高速道路や一般道路のライブ映像を撮影する多数の観測カメラ２６もインターネット２０に接続される。

ここで、渋滞予測システムにおける、情報の流れの概要を説明する。サーバー２１は、観測カメラ２６で撮影されたライブ映像や各種サーバー２２〜２５から提供される情報を用いて、道路の混み具合や渋滞を予測する。観測カメラ２６に映る道路上の車両の流れから、車両の密度や走行速度を実測することができる。また、観測カメラ２６の撮影範囲外における道路の混み具合は、各種サーバー２２〜２５から得られる交通情報，天候情報，自然災害情報，催事情報から推定することができる。サーバー２１で予測された交通渋滞の情報は、インターネット２０を介して車両１０の車載通信装置１に伝達される。これを受けて、車載通信装置１は交通渋滞の情報を音声や映像で乗員に提供する。

また、車載通信装置１は、サーバー２１による交通渋滞の予測が実態に即したものであるか否か（正しい予測であるか否か）を常に検査する。ここで、予測のずれが大きい場合には、その予測を調整，修正するためのフィードバック情報をサーバー２１に送信する。これにより、サーバー２１での予測内容が適正化され、交通渋滞の予測精度が向上する。また、予測のずれが小さい場合（交通渋滞の予測を修正する必要がない場合）には、フィードバック情報の送信を省略してもよいし、データ量の小さいフィードバック情報を送信させることとしてもよい。このように車載通信装置１は、予測のずれが小さい場合と比較して、予測のずれが大きい場合にフィードバック情報を増加させるように機能する。

車載通信装置１からサーバー２１に送信されるフィードバック情報は、車両１０の周囲の状況が直接的に把握できるような情報であることが好ましい。具体的にいえば、車両１０の周囲のライブ映像（動画，静止画）やレーダーの検知画像などをフィードバックすることが好ましい。また、このような情報に加えて、車両１０の走行状態を表す情報（例えば、車速，加速度，舵角，操舵角，ヨーレート，ロールレート，ピッチレートなど）も併せてフィードバックすることが好ましい。

［２．車両］
図１，図２に示すように、車両１０には、車室内外を撮影する撮影装置として、前方カメラ１１，後方カメラ１２，右カメラ１３，左カメラ１４，室内カメラ１５が搭載される。前方カメラ１１は車両１０の前方を撮影するカメラであり、車両１０の前端部やルーフの前端部，フロントガラス近傍などに取り付けられる。一方、後方カメラ１２は車両１０の後方を撮影するカメラであり、車両１０の後端部やルーフの後端部，リヤガラス近傍などに取り付けられる。

また、右カメラ１３は車両１０の右側方を撮影し、左カメラ１４は車両１０の左側方を撮影する。右カメラ１３，左カメラ１４は、側面ドアやピラーやサイドミラーなどに取り付けられる。これらのカメラ１３，１４の撮影範囲は、道路上のみならず車両１０の側方を含むように設定される。好ましくは、カメラ１３，１４の撮影範囲内に水平線が含まれるように画角が設定される。室内カメラ１５はおもに車室内を撮影するカメラであり、インストルメントパネルやバックミラー近傍などに取り付けられる。車載カメラ１１〜１５で撮影される画像中には、車両１０が走行する道路上を映した部分（第一画像）と、道路外を映した部分（第二画像）とが含まれるものとする。

車両１０の外周部には、レーダー装置１６が設けられる。レーダー装置１６は、車両１０の周囲に存在する物体（他車両，障害物，人物など）を検出するための探知機である。レーダー装置１６は、車両１０の周囲に送信波（電磁波，レーザー光，音波など）を照射し、その反射波を受信する機能を有する。一般に、送信波に対する反射波の反射時間，位相差，反射方向などに基づいて、送信波を反射した物体までの距離及び方位（すなわち位置）を把握することができる。なお、レーダー装置１６の具体例としては、ミリ波レーダー装置，マイクロ波レーダー装置，レーザーレーダー装置，超音波センサー装置などが挙げられる。解像度や処理速度が十分に高いレーダー装置１６は、車載カメラ１１〜１５と同じように、車両１０の周囲の状況を把握する用途に対応することができる。

また、車両１０には、車速を検出する車速センサー１７と、加減速度の大きさ及び方向を検出する加速度センサー１８と、操舵輪の舵角を検出する舵角センサー１９とが搭載される。これらのセンサー１７〜１９で得られる情報には、車両１０の走行状態が反映される。車載カメラ１１〜１５，レーダー装置１６，センサー１７〜１９で得られた各種の情報は、車載通信装置１に伝達される。車両１０の車室内には、表示装置７（ディスプレイ）が設けられる。表示装置７は、車載通信装置１の出力装置として機能し、車載通信装置１の処理内容や処理結果を表示する。車両１０の走行経路やマップデータ（地図情報）についても、表示装置７に表示される。

［３．車載通信装置］
車載通信装置１には、ハードウェア資源として、プロセッサー（中央処理装置），メモリ（メインメモリ），記憶装置（ストレージ），インタフェース装置などが内蔵される。記憶装置には、上記の制御を実施するためのプログラム（ソフトウェア）が格納される。プログラムの内容は、必要に応じてメモリ上に読み込まれ、プロセッサーで実行される。なお、車載通信装置１は、インターネット２０上のストレージを外部記憶装置として利用することができる。したがって、ソフトウェアの一部（または全部）をインターネット２０上のストレージに格納しておくことも可能である。

図２に示すように、車載通信装置１には、測位部２，カーナビ制御部３，算出部４，送信部５，促進部６が設けられる。これらの要素は、車載通信装置１の機能を便宜的に分類して示したものであり、個々の要素を独立したプログラムとして記述してもよいし、これらの機能を兼ね備えた複合プログラムとして記述してもよい。理論上は、ソフトウェアの一部（または全部）をハードウェアで実装することが可能である。また、測位部２やカーナビ制御部３は、独立した電子制御装置（カーナビゲーション装置）に内蔵させてもよいし、車載通信装置１に内蔵させてもよい。

測位部２は、GNSS（Global Navigation Satellite System，全球測位衛星システム）や車速センサー１７，加速度センサー１８，舵角センサー１９などの検出情報に基づいて、車両１０の現在位置を計測するものである。ここでは、世界測地系を基準として、車両１０の測位情報（緯度，経度，高さの情報）が測定されるとともに、その場所における時刻や曜日の情報が取得される。また、車両１０の位置の変化に基づき、車両１０の移動方向（進行方向）の情報も併せて測定される。

カーナビ制御部３（カーナビゲーション制御部）は、車両１０が存在する地域の道路情報に基づき、車両１０の走行経路を案内するものである。カーナビ制御部３は、乗員の操作により目的地が入力されると、その目的地までの最適経路を案内する機能を持つ。車両１０からサーバー２１へのフィードバック情報の送信は、少なくともカーナビ制御部３が経路案内をしているとき（すなわちカーナビ作動中）に実施される。なお、車両１０が通行しうる道路の形状や配置を縮尺してなるマップデータは、車載通信装置１に内蔵させてもよいし、インターネット２０上のストレージに保存させてもよい。

算出部４は、サーバー２１による交通渋滞の予測と実態とのずれの大きさを算出するものである。ずれの大きさは、予測通行時間と実通行時間との時間差や、予測速度と実速度との速度差や、予測混雑度と実混雑度との差として定量化することができる。上記の時間差とは、交通渋滞の度合いから推定される、所定区間の通行時間の予測値と、実際に車両１０がその所定区間を通行するのに要した時間との差である。

上記の速度差とは、交通渋滞の度合いから推定される所定区間の平均速度と、実際に車両１０がその所定区間を通行したときの平均速度との差である。予測混雑度は設計交通容量に対する予測交通容量の比であり、実混雑度は設計交通容量に対する実交通容量の比である。なお、交通容量とは、単位時間あたりに通過する車両（標準的なサイズの車両）の台数に相当する交通量の指標値である。このように、時間の次元を含むパラメーターを用いることで、交通渋滞の度合いを定量的に評価することができる。

送信部５は、交通渋滞の予測を修正するためのフィードバック情報を車両１０からサーバー２１に送信するものである。フィードバック情報の具体例としては、車両１０の周囲（道路上や道路外）を車載カメラ１１〜１５で撮影したライブ映像や、レーダー装置１６の検知画像である。本実施形態では、これらの画像だけでなく、実際の車両通行状態を表す情報も併せてサーバー２１に送信される。例えば、画像が取得された時刻の情報や、その時刻における車速，加速度，舵角の情報や、測位情報などがフィードバック情報に含まれる。

フィードバック情報には、実際の車両通行状態を表す情報と、車両通行状態に強く影響を与える外部要因を表す情報との二種類が含まれる。車両１０の車速，加速度，舵角などの情報は、前者の情報に含まれる。また、ライブ映像及び検知画像のうち道路上に相当する部分の情報も、前者の情報に含まれる。これに対し、ライブ映像及び検知画像のうち道路外に相当する部分の情報は、後者の情報に含まれる。本実施形態の送信部５は、車両１０が走行する道路上を撮影した第一画像と、道路外を撮影した第二画像とをサーバー２１に送信する機能を持つ。

例えば、新規に開店したばかりでまだマップデータには反映されていない店舗，競技場やイベント会場付近の人混み，イベント会場やレジャー施設へと続く入場の待ち行列などがライブ映像に映っていれば、その画像から交通渋滞の規模，時間を推定することができる。また、建物の火災や街路樹の倒壊，交通情報サーバー２２に反映されていない交通事故及び工事，天気情報サーバー２３に反映されていないゲリラ豪雨などが画像中に含まれている場合にも、その画像を交通渋滞の予測に役立てることができる。

促進部６は、算出部４で算出されたずれの大きさが所定量以上である場合に、予測がずれていることを表す「予測乖離通知」をサーバー２１に送信し、フィードバック情報の量を増加させるものである。例えば、予測時間と実時間との時間差が所定値未満である場合と比較して、所定値以上である場合にフィードバック情報量を増加させる。あるいは、予測速度と実速度との速度差が所定値未満である場合と比較して、所定値以上である場合にフィードバック情報量を増加させる。これにより、サーバー２１は予測のずれに対して迅速に対応することが可能となる。

フィードバック情報として画像（ライブ映像，検知画像）を送信する場合、情報量を増加させる手法として三種類の手法が考えられる。第一の手法は、画像の解像度（分解能）を上昇させることである。例えば、車載カメラ１１〜１５で撮影された生データを圧縮する際の圧縮率を変更することで、解像度を変更することができる。第二の手法は、画像の送信頻度を上昇させることである。例えば、静止画の送信間隔を短縮したり、動画のフレームレートを増加させる。第三の手法は、画像の撮影に使用されるカメラの数を増加させることである。例えば、ずれが小さいときには前方カメラ１１のみを使用し、ずれが大きい場合にのみ五つの車載カメラ１１〜１５を使用する。

［４．フローチャート］
（４−１．サーバー側の制御）
図３は、サーバー２１での渋滞予測の手順を例示するフローチャートである。本フローは、サーバー２１において所定の周期で繰り返し実施される。ステップＡ１では、サーバー２１が観測カメラ２６のライブ映像を取得するとともに、各種サーバー２２〜２５から交通情報，天候情報，自然災害情報，催事情報を収集する。また、ステップＡ２では、車両１０からのフィードバック情報を取得する。ここで取得されたフィードバック情報が適切である場合、サーバー２１がフィードバック情報を取得した時刻の情報が付加されて、マップデータに紐付けされる（ステップＡ３）。

ステップＡ４では、収集された情報に基づいて交通渋滞が予測される。ここでは例えば、車両１０が通行しうるすべての道路について、交差点や分岐点ごとに切り分けた単位区間（あるいは最大でも所定距離ごとに切り分けた単位区間）が設定されるとともに、単位区間ごとの混雑度や予想通行時間が予測される。具体的な交通渋滞の予測手法としては、公知の手法を適用することができる。

例えば、観測カメラ２６や車載カメラ１１〜１５のライブ映像に映っている単位区間については、そのライブ映像から車両密度や平均車速を求めることができる。ライブ映像に映っていない区間については、天候情報や自然災害情報を考慮して車両密度や平均車速を補正できる。また、交通事故や通行規制が発生している場所の近傍においては、交通情報を考慮して車両密度や平均車速を補正できる。イベントが開催されている場所の近傍においても、催事情報を考慮して車両密度や平均車速を補正できる。ここで予測された結果は、インターネット２０上に公開される。

ステップＡ５では、車両１０から予測乖離通知を受信したか否かが判定される。この条件が不成立であれば、そのまま本フローを終了する。一方、予測乖離通知を受信した場合にはステップＡ６に進み、再び交通渋滞を予測する。予測乖離通知を受信した時点で、その予測乖離通知をサーバー２１に送信した車両１０からのフィードバック情報量が増加している。したがって、ステップＡ６の予測では、ステップＡ４よりも多くの情報を用いることができ、予測の信頼性が向上する。

続いて、サーバー２１は予測がずれた原因を推定するとともに、関連する各種サーバー２２〜２５に情報を提供する。これにより、各種サーバー２２〜２５から提供される情報がより信頼性の高い情報で更新される。ここで予測された結果は、インターネット２０上に公開される。また、予測乖離通知をサーバー２１に送信してきた車両１０に対しては、最新の予測結果を配信する（ステップＡ８）。

（４−２．ライブ映像の処理）
図４は、サーバー２１が車両１０から受け取ったフィードバック情報の処理手順を例示するフローチャートである。このフローは、図３のステップＡ２に含まれる。ステップＢ１では、フィードバック情報のタイムスタンプが新しいものであるか否かが判定される。ここでは、タイムスタンプの時刻が現在時刻に近いか（例えば現在時刻から一時間以内か）否かが判定される。この条件が不成立の場合には、不適切なフィードバック情報として破棄される（ステップＢ６）。一方、ステップＢ１の条件が成立するとステップＢ２に進む。

ステップＢ２では、フィードバック情報に含まれる各データの値が所定範囲内であるか否かが判定される。例えば、車速が所定範囲内（0〜120[km/h]）であることや、舵角が所定範囲内（-60〜60[度]）であることが確認される。また、ライブ映像のデータ量が適正範囲内であることを確認してもよい。ステップＢ２の条件が不成立の場合には、不適切なフィードバック情報として破棄される（ステップＢ６）。一方、ステップＢ２の条件が成立するとステップＢ３に進む。

ステップＢ３では、フィードバック情報に含まれる測位情報が適切であるか否かが判定される。例えば、車両１０の位置をマップデータと照合し、車両１０が走行可能な場所（道路上や駐車場内など）に位置しているか否かが確認される。あるいは、より簡便な地図の情報と照合して、車両１０が海や河川の上に位置していないことを確認してもよい。ステップＢ３の条件が不成立の場合には、不適切なフィードバック情報として破棄される（ステップＢ６）。一方、ステップＢ３の条件が成立するとステップＢ４に進む。

ステップＢ４では、フィードバック情報に含まれるライブ映像が再生可能であるか否かが判定される。この判断は、データ内に埋め込まれたヘッダーやExifなどのメタ情報に基づいて判断してもよいし、ハッシュ値を確認することで判断してもよい。ライブ映像が破損している場合には、不適切なフィードバック情報として破棄される（ステップＢ６）。一方、ライブ映像が再生可能である場合にはステップＢ５に進み、サーバー２１での取得時刻の情報をそのフィードバック情報に付加した上で、マップデータに紐付けして保存する。

（４−３．渋滞予測）
図５は、サーバー２１での渋滞予測の手法を例示するフローチャートである。このフローは、図３のステップＡ４に含まれる。ステップＣ１では、ライブ映像，交通情報，天候情報，自然災害情報，催事情報に基づいて交通渋滞が予測される。ここでは例えば、マップデータ上に含まれるすべての道路について、単位区間ごとの混雑度（予想通行時間）が予測される。

ステップＣ２では、それぞれの単位区間についての混雑度が、毎週の変動に即したものであるか否か、あるいは毎日の変動に即したものであるか否かが判定される。つまり、その曜日・時間帯に特有の混雑が発生しているか否かが判定される。例えば、単位区間ごとに混雑度の毎週の変動モデルと毎日の変動モデルとを作成しておき、ステップＣ１での予測結果がそれらのモデルに沿っているかどうかを判断する。

ステップＣ２の条件が成立する場合にはステップＣ３に進み、サーバー２１は定常的，周期的な渋滞が発生していると判断して本フローを終了する。ステップＣ２の条件が不成立の場合には、突発的（非定常的）な渋滞が発生しているとみなし、原因をさらに追求すべくステップＣ４に進む。

ステップＣ４では、混雑度が高い単位区間について、その付近で交通事故が発生しているか否かが判定される。この判定は、交通情報サーバー２２から提供される交通情報に基づいて実施される。ステップＣ４の条件が成立する場合、渋滞の原因は交通事故であると判断し（ステップＣ５）、本フローを終了する。ステップＣ４の条件が不成立の場合にはステップＣ６に進む。

ステップＣ６では、混雑度が高い単位区間について、その付近に道路工事区間があるか否かが判定される。この判定も、交通情報サーバー２２から提供される交通情報に基づいて実施される。ステップＣ６の条件が成立する場合、渋滞の原因は道路工事であると判断し（ステップＣ７）、本フローを終了する。ステップＣ６の条件が不成立の場合にはステップＣ８に進む。

ステップＣ８では、混雑度が高い単位区間について、その付近で異常気象が発生しているか否かが判定される。この判定は、天気情報サーバー２３から提供される天候情報に基づいて実施される。ステップＣ８の条件が成立する場合、渋滞の原因は天候であると判断し（ステップＣ９）、本フローを終了する。ステップＣ８の条件が不成立の場合にはステップＣ１０に進む。

ステップＣ１０では、混雑度が高い単位区間について、その付近で自然災害が発生しているか否かが判定される。この判定は、災害情報サーバー２４から提供される災害情報に基づいて実施される。ステップＣ１０の条件が成立する場合、渋滞の原因は自然災害であると判断し（ステップＣ１１）、本フローを終了する。ステップＣ１０の条件が不成立の場合にはステップＣ１２に進み、渋滞の原因は不明であると判断する。本フローでの判断結果は後日に改めて分析できるように、サーバー２１に保存しておくことが好ましい。

（４−４．予測乖離通知後の渋滞予測）
図６は、サーバー２１が車両１０から予測乖離通知を受け取った後の渋滞予測の手法を例示するフローチャートである。このフローは、図３のステップＡ６に含まれる。ステップＤ１では、ライブ映像，交通情報，天候情報，自然災害情報，催事情報に基づいて交通渋滞が予測される。このとき参照される情報量は、ステップＣ１で参照される情報量と比較して増えているため、より精度の高い予測が期待できる。

ステップＤ２では、車両１０から送信されたライブ映像の画像中に交通事故が映っているか否かが判定される。この判定は、画像解析を通じて、大破した車両や変形したガードレール，道路に散乱したガラス，警察車両，救急車などを検出することで判定可能である。ステップＤ２の条件が成立する場合、渋滞の原因は交通事故であると判断し（ステップＤ３）、本フローを終了する。ステップＤ２の条件が不成立の場合にはステップＤ４に進む。

ステップＤ４では、車両１０から送信されたライブ映像の画像中に道路工事が映っているか否かが判定される。この判定は、画像解析を通じて、道路工事標識や安全標識，工事用たて看板，工事警備員，工事車両（例えばクレーン車，ミキサー車，はしご車，アスファルトフィニッシャー）などを検出することで判定可能である。ステップＤ４の条件が成立する場合、渋滞の原因は道路工事であると判断し（ステップＤ５）、本フローを終了する。ステップＤ４の条件が不成立の場合にはステップＤ６に進む。

ステップＤ６では、車両１０から送信されたライブ映像の画像中に異常気象が映っているか否かが判定される。この判定は、画像解析を通じて、ゲリラ豪雨や降雪などを検出することで判定可能である。ステップＤ６の条件が成立する場合、渋滞の原因は天候であると判断し（ステップＤ７）、本フローを終了する。ステップＤ６の条件が不成立の場合にはステップＤ８に進む。

ステップＤ８では、車両１０から送信されたライブ映像の画像中に自然災害が映っているか否かが判定される。この判定は、画像解析を通じて、山火事や地割れなどを検出することで判定可能である。ステップＤ８の条件が成立する場合、渋滞の原因は自然災害であると判断し（ステップＤ９）、本フローを終了する。ステップＤ８の条件が不成立の場合にはステップＤ１０に進む。

ステップＤ１０では、車両１０から送信されたライブ映像の画像中にライブイベント会場やその付近の人混み，ライブイベントの待ち行列などが映っているか否かが判定される。この判定は、画像解析を通じて判定可能である。また、ステップＤ１１では、付近でライブイベントが実施されているか否かが判定される。この判定は、催事情報サーバー２５から提供される催事情報に基づいて判定可能である。ステップＤ１０，Ｄ１１のいずれかの条件が成立する場合、渋滞の原因はライブイベントであると判断し（ステップＤ１２）、本フローを終了する。ステップＤ１０，Ｄ１１の条件がともに不成立の場合にはステップＤ１３に進む。

ステップＤ１３では、車両１０から送信されたライブ映像の画像中にレジャー施設やその付近の人混み，レジャー施設の待ち行列などが映っているか否かが判定される。この判定は、画像解析を通じて判定可能である。また、ステップＤ１４では、付近にレジャー施設が存在するか否かが判定される。この判定も、催事情報サーバー２５から提供される催事情報やマップデータに基づいて判定可能である。

ステップＤ１３，Ｄ１４のいずれかの条件が成立する場合、渋滞の原因はレジャー施設であると判断し（ステップＤ１５）、本フローを終了する。ステップＤ１３，Ｄ１４の条件がともに不成立の場合にはステップＤ１６に進み、渋滞の原因は不明であると判断する。本フローでの判断結果は後日に改めて分析できるように、サーバー２１に保存しておくことが好ましい。

（４−５．車両側の制御）
図７は、車両１０からサーバー２１へのフィードバック情報の送信手順を例示するフローチャートである。本フローは、車載通信装置１において所定の周期で繰り返し実施される。ステップＥ１では、カーナビ制御部３が経路案内をしている状態であるか否かが判定される。カーナビ作動中でなければ本フローを終了し、カーナビ作動中であればステップＥ２に進む。

ステップＥ２では、サーバー２１による交通渋滞の予測結果が車両１０に受信され、車載通信装置１に伝達される。また、ステップＥ３では、算出部４において、サーバー２１による交通渋滞の予測と実態とのずれの大きさが算出される。例えば、車両１０が直前に走行した所定区間についての予測通行時間と実通行時間との時間差が算出される。続くステップＥ４では、時間差が所定値以上であるか否かが判定される。この条件が成立する場合にはステップＥ５〜Ｅ９が実施され、不成立の場合にはステップＥ１０〜Ｅ１２が実施される。

ステップＥ５では、促進部６がすべての車載カメラ１１〜１５を起動させる。各カメラで撮影されるライブ映像の画質は「高品質」に設定される（ステップＥ６）。また、促進部６はサーバー２１に予測乖離通知を送信するとともに（ステップＥ７）、車載カメラ１１〜１５で撮影されたライブ映像を含むフィードバック情報を高頻度でサーバー２１にアップロードする（ステップＥ８）。フィードバック情報のアップロード頻度は、数秒周期以下（例えば0.1〜5[秒]周期）とされる。その後、サーバー２１から新たな渋滞の予測結果が配信されるのを待って、カーナビ制御部３が走行経路を再検索し、新たな走行経路を乗員に案内する（ステップＥ９）。

時間差が所定値未満であるとき、すなわち、交通渋滞の予測がおおむね適切である場合にはステップＥ１０に進み、促進部６が前方カメラ１１のみを起動させる。前方カメラ１１で撮影されるライブ映像の画質は、ステップＥ６よりも低品質でデータ量の少ない「標準品質」に設定される（ステップＥ１１）。その後、促進部６は前方カメラ１１で撮影されたライブ映像を含むフィードバック情報を低頻度でサーバー２１にアップロードする。フィードバック情報のアップロード頻度は、ステップＥ８のアップロード頻度よりも少ない頻度であって、数分周期（例えば1〜10分周期）とされる。

［５．効果］
（１）上記の車載通信装置１は、交通渋滞の予測と実態とのずれが大きい場合に、車両１０からサーバー２１に送信される情報の量を増加させる促進部６を備えている。このように、サーバー２１にフィードバックされる情報量を増加させることで、交通渋滞の予測のずれを早期に改善することができ、予測精度を向上させることができる。また、交通渋滞の予測と実態とのずれが小さい場合には、サーバーに送信される情報の量を増加させずに済み、車両１０とサーバー２１との間の通信量を削減することができ、ネットワークトラフィックを適正化することができる。

（２）また、車両１０の周囲を撮影したライブ映像（動画，静止画）をフィードバック情報に含ませることで、サーバー２１による予測の修正精度を高めることができ、予測精度を向上させることができる。例えば、マップデータには反映されていない店舗，人混み，入場の待ち行列などがライブ映像に映っていれば、その画像から交通渋滞の規模，時間を推定することができる。また、建物の火災，発生直後の事故，ゲリラ豪雨など、各種サーバー２２〜２５に反映されていない新しい情報に基づいて交通渋滞を予測することができ、予測精度を向上させることができる。

（３）上記の促進部６は、交通渋滞の予測と実態とのずれの大きさが所定量以上である場合に、ライブ映像の解像度を上昇させている。これにより、ライブ映像に映っている被写体をより精細に捉えることができ、交通渋滞の予測精度をさらに向上させることができる。なお、交通渋滞の予測と実態とのずれの大きさが所定量未満である場合には、標準品質の解像度とされるため、ネットワークトラフィックを過度に圧迫することはない。

（４）上記の促進部６は、交通渋滞の予測と実態とのずれの大きさが所定量以上である場合に、ライブ映像の送信頻度を上昇させている。これにより、多数のライブ映像の中から各種サーバー２２〜２５に反映されていない新しい情報を抽出することができ、予測精度を向上させることができる。なお、交通渋滞の予測と実態とのずれの大きさが所定量未満である場合には、送信頻度が低頻度とされるため、ネットワークトラフィックを過度に圧迫することはない。

（５）上記の促進部６は、交通渋滞の予測と実態とのずれの大きさが所定量以上である場合に、ライブ映像の撮影に使用される車載カメラ１１〜１５の数を増加させている。これにより、車両１０の周囲をより広く撮影することが可能となり、各種サーバー２２〜２５に反映されていない新しい情報を抽出しやすくすることができる。したがって、サーバー２１での予測精度を向上させることができる。なお、交通渋滞の予測と実態とのずれの大きさが所定量未満である場合には、撮影に使用される車載カメラ１１〜１５の数を減少させることで、ネットワークトラフィックを削減することができる。

（６）フィードバック情報をサーバー２１に送信する送信部５は、車両１０が走行する道路上を撮影した第一画像だけでなく、道路外を撮影した第二画像をサーバー２１に送信する機能を持つ。このように、道路外を撮影対象とした第二画像をサーバー２１に提供することで、各種サーバー２２〜２５に反映されていない新しい情報を抽出しやすくすることができ、サーバー２１での予測精度を向上させることができる。なお、右カメラ１３，左カメラ１４の撮影範囲内に水平線が含まれるように画角を設定することで、道路に面した建物や人混みが撮影しやすくなり、新しい情報を取得しやすくなる。

（７）車載通信装置１の算出部４では、交通渋滞の予測と実態とのずれの大きさを表す指標値として、予測通行時間と実通行時間との時間差が算出される。このように、「ずれの大きさ」を定量化することで、サーバー２１での予測の信頼性（正しさ）を客観的に評価することができる。したがって、フィードバック情報量を精度よく増減させることができ、ネットワークトラフィックを適正に保ちつつ交通渋滞の予測精度を向上させることができる。なお、時間差の代わりに、予測速度と実速度との速度差や、予測混雑度と実混雑度との差を用いてもよい。このように、時間の次元を含むパラメーターを用いることで、交通渋滞の度合いを定量的に評価することができる。

（８）本実施形態の送信部５は、ライブ映像だけでなく、実際の車両通行状態を表す情報も併せてサーバー２１に送信している。例えば、画像が取得された時刻の情報や、その時刻における車速，加速度，舵角の情報や、測位情報などがフィードバック情報に含まれる。これにより、フィードバック情報が適切であるか否かを判定することができ、交通渋滞の予測精度を向上させることができる。

［６．変形例］
上記の実施形態はあくまでも例示に過ぎず、本実施形態で明示しない種々の変形や技術の適用を排除する意図はない。本実施形態の各構成は、それらの趣旨を逸脱しない範囲で種々変形して実施することができる。また、必要に応じて取捨選択することができ、あるいは適宜組み合わせることができる。

例えば上述の実施形態では、サーバー２１のみが交通渋滞を予測する渋滞予測システムを示したが、サーバー２１の機能の一部（または全部）を車載通信装置１に負担させてもよいし、分散コンピューティングの手法を用いて複数の車両１０に分担させてもよい。また、上述の実施形態では、車両１０の車載通信装置１に算出部４，送信部５，促進部６が設けられているが、算出部４及び促進部６の機能をサーバー２１に負担させてもよい。少なくとも渋滞予測システム内に算出部４，送信部５，促進部６を設けることで、上述の実施形態と同様の作用，効果を奏するものとなる。なお、ネットワークトラフィックを削減する上では、送信部５を車載通信装置１に設けることが好ましい。

１ 車載通信装置
２ 測位部
３ カーナビ制御部
４ 算出部
５ 送信部
６ 促進部
７ 表示装置
１０ 車両
１１ 前方カメラ
１２ 後方カメラ
１３ 右カメラ
１４ 左カメラ
１５ 室内カメラ
１６ レーダー装置
１７ 車速センサー
１８ 加速度センサー
１９ 舵角センサー
２０ インターネット
２１ サーバー
２２ 交通情報サーバー
２３ 天気情報サーバー
２４ 災害情報サーバー
２５ 催事情報サーバー
２６ 観測カメラ

Claims (8)

1. サーバーで予測された交通渋滞の情報を車両の乗員に提供する車載通信装置において、
   前記交通渋滞の予測と実態とのずれの大きさを算出する算出部と、
   前記交通渋滞の予測を修正するための情報を前記車両から前記サーバーに送信する送信部と、
   前記ずれの大きさが所定量以上である場合に、前記サーバーに送信される情報の量を増加させる促進部と、
   を備えることを特徴とする、車載通信装置。
2. 前記送信部が、前記車両の周囲を撮影した画像を前記サーバーに送信する
   ことを特徴とする、請求項１記載の車載通信装置。
3. 前記促進部は、前記ずれの大きさが所定量以上である場合に、前記画像の解像度を上昇させる
   ことを特徴とする、請求項２記載の車載通信装置。
4. 前記促進部は、前記ずれの大きさが所定量以上である場合に、前記画像の送信頻度を上昇させる
   ことを特徴とする、請求項２または３記載の車載通信装置。
5. 前記促進部は、前記ずれの大きさが所定量以上である場合に、前記画像の撮影に使用されるカメラの数を増加させる
   ことを特徴とする、請求項２〜４のいずれか１項に記載の車載通信装置。
6. 前記送信部は、前記車両が走行する道路上を撮影した第一画像と、前記車両が走行する道路外を撮影した第二画像とを前記サーバーに送信する
   ことを特徴とする、請求項２〜５のいずれか１項に記載の車載通信装置。
7. 前記算出部が、前記交通渋滞の度合いから推定される所定区間の通行時間と前記車両が当該所定区間を通行するのに要した時間である実通行時間との時間差を算出する
   ことを特徴とする、請求項１〜６のいずれか１項に記載の車載通信装置。
8. 前記送信部が、実際の車両通行状態を表す情報を前記サーバーに送信する
   ことを特徴とする、請求項１〜７のいずれか１項に記載の車載通信装置。

Images