JP2007156894A - 協調制御データ配信方法、運転支援装置及び配信サーバ - Google Patents

Abstract

【課題】走行支援を中止した地点において、走行支援を再開するための協調制御データ配信方法、運転支援装置及び配信サーバを提供する。
【解決手段】配信システム１は、道路データを記憶した地理データ記憶部、及び道路データに沿って車両の走行制御を行うＣＰＵを備えた運転支援装置１０と、運転支援装置１０とネットワークＮを介して接続された配信サーバ２とを備えている。運転支援装置１０は、車両協調制御に沿わないメンテナンス地点を検出するとともに、検出したメンテナンス地点に関する検出データを、配信サーバ２に送信する。配信サーバ２は、各運転支援装置１０から検出データを収集し、各検出データに基づいた更新データを運転支援装置１０に配信する。
【選択図】図１

Description

本発明は、協調制御データ配信方法、運転支援装置及び配信サーバに関する。

近年、渋滞等の交通問題を解決し、自動車の円滑な走行を図るために、高度道路交通システム（Intelligent Transport Systems）の開発が進められている。このシステムの一
環として、安全運転を支援するシステムが開発されている。このシステムでは、急カーブ等の発見の遅れ、道路状況等の判断の誤り等の問題に対し、車々間通信、路車間通信、又は自動車に搭載された各種装置を用いて、道路状況や他車両に関する各種情報を提供する。さらに、自車両又は他車両の状況に応じて、車両に搭載された表示部やスピーカ等により警報を発し、道路状況に応じた運転操作を支援する。

このような装置として、道路形状に対応させて自動車の走行制御を行う車両制御装置が提案されている（例えば、特許文献１参照）。この制御装置は、装置が有するデータベースに基づき自車両前方の道路形状を推定し、推定結果に基づいてトランスミッションＥＣＵ（電子制御装置）等を制御する。そして、実際にその道路を走行した後、走行した実際の道路形状と推定した道路形状とを比較する。さらに、推定した道路形状と、データベースの道路形状とに大きな差異がある場合には、次回その道路を走行する際に、データベースに基づく走行制御を中止する。
特開平１１−３１１３１６号公報

ところが、車両制御装置による走行制御を中止した後、その道路を走行する際は、常に走行制御が行われない状態になる。このため、走行制御を中止した道路に対するフォローが要求されている。

本発明は、上記問題点に鑑みてなされたものであり、その目的は、走行支援を中止した地点において、走行支援を再開するための協調制御データ配信方法、運転支援装置及び配信サーバを提供することにある。

上記問題点を解決するために、請求項１に記載の発明は、運転支援のための協調制御データを記憶した協調制御データ記憶手段、及び前記協調制御データに沿って車両の走行制御を行う協調制御手段を備えた運転支援装置と、前記運転支援装置とネットワークを介して接続された配信サーバとを用いて、前記協調制御データを更新する協調制御データ配信方法であって、前記運転支援装置が、前記協調制御データと前記車両の走行結果とが合わないメンテナンス地点を検出する段階と、検出したメンテナンス地点に関する検出データを、前記配信サーバに送信する段階と、前記配信サーバが、前記各運転支援装置から前記検出データを収集する段階と、更新した前記協調制御データを前記運転支援装置に送信する段階とを有することを要旨とする。

請求項２に記載の発明は、請求項１に記載の協調制御データ配信方法において、前記配信サーバが、前記各運転支援装置から収集した前記検出データに基づき、前記協調制御データの改訂を通知する通知情報を生成する段階と、前記通知情報を前記各運転支援装置に送信する段階と、前記各運転支援装置から受信したデータ更新要求に基づき、更新された前記協調制御データを前記運転支援装置に送信する段階と、前記運転支援装置が、前記配
信サーバから受信した前記通知情報を、出力手段に出力する段階と、前記通知情報に従って、前記データ更新要求を前記配信サーバに送信する段階とをさらに有することを要旨とする。

請求項３に記載の発明は、請求項２に記載の協調制御データ配信方法において、前記配信サーバが、前記各車両に搭載された前記各運転支援装置から収集した前記各検出データに基づき、前記メンテナンス地点又はメンテナンス地点を含む道路の数を示す前記通知情報を生成することを要旨とする。

請求項４に記載の発明は、車両に搭載された運転支援装置において、運転支援のための協調制御データを記憶した協調制御データ記憶手段と、前記協調制御データに沿って車両の走行制御を行う協調制御手段と、前記協調制御データと前記車両の走行結果とが合わないメンテナンス地点を検出するメンテナンス地点検出手段と、検出したメンテナンス地点に関する検出データを、配信サーバに送信する送信手段と、更新された協調制御データを、前記配信サーバから取得する更新データ取得手段とを備えることを要旨とする。

請求項５に記載の発明は、請求項４に記載の運転支援装置において、前記配信サーバから受信した、前記協調制御データの改訂を通知する通知情報を、出力手段に出力する出力制御手段をさらに備えることを要旨とする。

請求項６に記載の発明は、請求項４又は５に記載の運転支援装置において、前記メンテナンス地点に対する前記協調制御データを生成する生成手段をさらに備え、前記送信手段は、前記運転支援装置が算出した前記協調制御データを含む前記検出データを、前記配信サーバに送信することを要旨とする。

請求項７に記載の発明は、請求項５又は６に記載の運転支援装置において、前記出力制御手段は、前記配信サーバから受信した、前記メンテナンス地点の数を示す前記通知情報を前記出力手段に出力することを要旨とする。

請求項８に記載の発明は、請求項５〜７のいずれか１項に記載の運転支援装置において、前記通知情報に基づき、前記メンテナンス地点を重み付けして、重要度の高いメンテナンス地点を判断する地点判別手段をさらに備え、前記出力制御手段は、重要度の高いメンテナンス地点に関する通知を前記出力手段に出力することを要旨とする。

請求項９に記載の発明は、請求項８に記載の運転支援装置において、前記更新データ取得手段は、前記重要度の高いメンテナンス地点のデータ更新要求を前記配信サーバに送信することを要旨とする。

請求項１０に記載の発明は、請求項５〜９のいずれか１項に記載の運転支援装置において、前記通知情報に基づき、重要度の高いメンテナンス道路数を算出し、そのメンテナンス道路数に応じて通知パターンを変更するパターン選択手段をさらに備えたことを要旨とする。

請求項１１に記載の発明は、車両に搭載された運転支援装置に、運転支援のための協調制御データを配信する配信サーバにおいて、前記各運転支援装置から、前記協調制御データと実際の走行結果とが合わないメンテナンス地点に関する検出データを収集する受信手段と、更新した前記協調制御データを前記運転支援装置に送信する配信手段とを備えたことを要旨とする。

請求項１に記載の発明によれば、運転支援装置が、協調制御データと車両の走行結果とが合わないメンテナンス地点を検出した場合、検出データを配信サーバに送信する。配信サーバは、各運転支援装置から収集した検出データを受信して、検出データの収集を行う。そして、更新した協調制御データを各運転支援装置に送信する。このため、協調制御に沿わない地点も、協調制御データの更新を行うことで、協調制御を可能にすることができる。

請求項２に記載の発明によれば、配信サーバは、各運転支援装置から収集した検出データに基づいて通知情報を生成し、その通知情報を各運転支援装置に送信する。運転支援装置は、受信した通知情報を出力手段に出力し、通知情報に従って更新データの要求を行う。このため、データ更新前に、予め通知を行い、データ更新の可否を問うので、ドライバーにとって必要なタイミングでデータ更新を行うことができる。

請求項３に記載の発明によれば、配信サーバは、各運転支援装置から収集したメンテナンスデータに基づき、メンテナンス地点の数又はメンテナンス地点を含む道路を示す通知情報を、運転支援装置に送信する。このため、運転支援装置では、データ更新が必要なメンテナンス地点の数を出力手段に出力するので、ドライバーは、データ更新が必要なメンテナンス地点の数を確認し、データ更新の可否を決定することができる。

請求項４に記載の発明によれば、運転支援装置が、協調制御データと車両の走行結果とが合わないメンテナンス地点を検出した場合、検出データを配信サーバに送信する。そして、運転支援装置は、検出データに基づいた更新データを配信サーバから受信する。このため、協調制御に沿わない地点も、協調制御データの更新を行うことで、協調制御を可能にすることができる。

請求項５に記載の発明によれば、運転支援装置は、受信した通知情報を出力手段に出力し、通知情報に従って更新データの要求を行う。このため、データ更新前に、予め通知を行い、データ更新の可否を問うので、ドライバーにとって必要なタイミングでデータ更新を行うことができる。

請求項６に記載の発明によれば、運転支援装置は、運転支援装置が算出した協調制御データを送信する。このため、配信サーバは、各運転支援装置から収集した協調制御データを統計することができる。従って、各協調制御データの統計により、最適化した協調制御データを各運転支援装置に配信できる。

請求項７に記載の発明によれば、運転支援装置は、データ更新が必要なメンテナンス地点の数を出力手段に出力するので、ドライバーは、データ更新が必要なメンテナンス地点の数を確認し、データ更新の可否を決定することができる。

請求項８に記載の発明によれば、運転支援装置は、メンテナンス地点を重み付けして、重要度の高いメンテナンス地点に関する通知を出力手段に出力する。このため、ドライバーは、重要度の高いメンテナンス地点の情報を得ることによって、データ更新の可否を決定することができる。

請求項９に記載の発明によれば、運転支援装置は、重要度の高いメンテナンス地点のデータ更新要求を配信サーバに送信する。このため、配信サーバから送信されるデータ量が軽減される。

請求項１０に記載の発明によれば、通知情報に基づき、重要度の高いメンテナンス道路数を算出し、そのメンテナンス道路数に応じて、通知パターンを変更する。このため、例
えば重要度の高いメンテナンス道路数が多い場合には、ドライバーの注意を喚起することができる。

請求項１１に記載の発明によれば、配信サーバは、各運転支援装置から収集した検出データを受信して、検出データの収集を行う。そして、検出データに基づき、更新データを各運転支援装置に送信する。このため、協調制御に沿わない地点も、協調制御データの更新を行うことで、協調制御を可能にすることができる。

以下、本発明を具体化した一実施形態を図１〜図２２に従って説明する。図１は、本実施形態における、配信システム１の概略図である。
図１に示すように、配信システム１は、配信サーバ２を有している。配信サーバ２は、一般通信回線網・専用通信回線網、衛星回線、基地局３等から構成されるネットワークＮを介して、各車両Ｃに搭載された各運転支援装置１０に接続されている。配信サーバ２は、各車両Ｃの運転支援装置１０から、各車両Ｃが走行した道路の状況に関するプローブ情報Ｐｒを収集する。そして、収集したプローブ情報Ｐｒに基づき、各種データを生成して、そのデータを各運転支援装置１０に配信する。

次に、運転支援装置１０の構成について、図２に従って説明する。運転支援装置１０は、協調制御手段、メンテナンス地点検出手段、送信手段、更新データ取得手段、生成手段、地点判別手段、パターン選択手段としてのＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、ＧＰＳ受信部１４、センサ側Ｉ／Ｆ部１５及び通信部１６を備えている。ＣＰＵ１１は、ＧＰＳ（Global Positioning System）衛星からＧＰＳ受信部１４が受信した、緯度・経度等
の座標を示す位置検出信号を入力する。また、センサ側Ｉ／Ｆ部１５を介して、車両Ｃに設けられた車速センサ５０及びジャイロセンサ５１から車速パルス、角速度ωをそれぞれ入力する。そして、ＣＰＵ１１は、これらの信号に基づき、電波航法及び自律航法を組み合わせて自車位置を検出する。

また、ＣＰＵ１１は、センサ側Ｉ／Ｆ部１５を介して、Ｇセンサ５２、上下加速度センサ５３、車重センサ５４から各種電気信号を入力する。Ｇセンサ５２は、車両進行方向の加減速度αを検出し、加減速度αに応じた電気信号をセンサ側Ｉ／Ｆ部１５に出力する。上下加速度センサ５３は、サスペンションのバネ上の車体に取付けられ、バネ上の上下加速度βを検出して、上下加速度βに応じた電気信号をセンサ側Ｉ／Ｆ部１５に出力する。車重センサ５４は、車両Ｃの総重量Ｗを検出し、総重量Ｗに応じた電気信号をセンサ側Ｉ／Ｆ部１５に送信する。例えば、車重センサ５４は、シート下方等に配設されるとともに、車両Ｃのみの重量に、乗員による増加重量を加算した総重量Ｗを検出する。

また、運転支援装置１０は、協調制御データ記憶手段としての地理データ記憶部２０、出力制御手段としての画像プロセッサ２１を備えている。地理データ記憶部２０は、ハードディスク、又は光ディスク等の外部記憶媒体である。この地理データ記憶部２０には、目的地までの経路を探索するための各経路ネットワークデータ（以下、経路データ２２という）と、出力手段としてのディスプレイ２５に地図画面２５ａを出力するための各地図描画データ２３とが格納されている。

図３に示すように、経路データ２２は、全国を各区域に区画したリージョン毎のデータであって、ヘッダ２２ａ、ノードデータ２２ｂ、リンクデータ２２ｃ、リンクコスト２２ｄ、座標データ２２ｅ、バージョン２２ｆを有している。ヘッダ２２ａは、各経路データ２２を管理するためのデータを有している。ノードデータ２２ｂは、交差点、道路の端点等を示す各ノードの番号等の識別データ、隣接するノードの識別データ等を有している。リンクデータ２２ｃは、リンクＩＤや、接続ノードを示す各リンクＩＤ、通行規制を示す
データ等を有している。リンクコスト２２ｄは、リンク長、平均旅行時間等から構成されるデータ群である。座標データ２２ｅは、各ノードの絶対座標を示す。バージョン２２ｆは、その経路データ２２のバージョンを示している。

ＣＰＵ１１は、この経路データ２２を用いて、目的地と現在の自車位置とを接続する推奨経路を探索する。このとき、リンクコスト２２ｄのリンク長、平均旅行時間等を用い、最短距離となる推奨経路、走行時間が最も短縮化される推奨経路、経費が縮小できる推奨経路等のように、複数の経路を探索する。そして、ＣＰＵ１１は、各推奨経路を一度探索すると、その経路を表わすノード・リンクを示す、ノードデータ２２ｂ、リンクデータ２２ｃ、リンクコスト２２ｄ、バージョン２２ｆ等を、履歴データ２４に格納される探索履歴データ２４ａとしてＲＡＭ１２に記憶する。

また、ＣＰＵ１１は、車両Ｃが一度走行した道路は、履歴データ２４中の走行履歴データ２４ｂとして、ＲＡＭ１２に格納する。走行履歴データ２４ｂは、経路探索の有無に関わらず、車両Ｃが走行した道路を示し、ノードデータ２２ｂ、リンクデータ２２ｃ、リンクコスト２２ｄ、バージョン２２ｆ等が記憶されている。

また、図４（ａ）に示すように、地図描画データ２３は、全国の地図を分割したエリア毎に格納され、広域の地図から狭域の地図まで各階層毎に分かれている。各地図描画データ２３は、ヘッダ２３ａ、協調制御データとしての道路データ２３ｂ、背景データ２３ｃ、バージョン２３ｄを有している。ヘッダ２３ａは、その地図描画データ２３の階層、エリア等を示し、管理目的のデータである。道路データ２３ｂは、地図上に表示される道路の形状を示すデータである。背景データ２３ｃは、道路、市街地、河川等を描画する描画データである。

さらに、道路データ２３ｂは、図４（ｂ）に示すように、道路属性データ２３ｇ、制御パラメータ２３ｈ、リンク形状データ２３ｉ、接続データ２３ｊを有している。道路属性データ２３ｇは、道路名称、各道路に割り振られた道路番号、道路の方向、道路幅、車線数を有している。制御パラメータ２３ｈは、道路の路面状況・形状を示すデータであって、カーブの曲率半径Ｒａ、勾配（傾斜角）Ｄａ、道路の凹凸の粗さ又は細かさを示す波長λａ、凹凸の鉛直方向の振幅の大きさを示す振幅レベルＬａ等を有している。

リンク形状データ２３ｉは、道路の形状を示すためのデータであるとともに、座標データ２３ｍ、形状補完データ２３ｎを有している。座標データ２３ｍは、各リンク及び各ノードの座標を有している。形状補完データ２３ｎは、リンクの途中に設定され、道路のカーブ形状を示すために設定された形状補間点に関するデータである。この形状補完データ２３ｎは、形状補完点の座標、各形状補完点の連結部（リンク）の方位等のデータを有している。

運転支援装置１０の画像プロセッサ２１は、ＣＰＵ１１に基づき、自車位置から所定距離内の地図描画データ２３を地理データ記憶部２０から読出す。そして、リンク形状データ２３ｉに基づいた形状の道路、背景データ２３ｃに基づく市街地等を描画するための描画データを生成し、内蔵する画像メモリに一時記憶する。そして、描画データに基づく映像信号をディスプレイ２５に出力する。地図画面２５ａには、自車位置を示す指標が２５ｂが重畳されている。

車両Ｃが走行状態であるとき、ＣＰＵ１１は、ＧＰＳ受信部１４から受信した位置データと、ジャイロセンサ５１から受信した角速度ωと、道路データ２３ｂとを照合して、マップマッチングを行う。例えば、ＣＰＵ１１は、位置データ及び角度変位量に基づき車両Ｃの走行軌跡を算出して、その走行軌跡と、道路データ２３ｂ内に基づく道路形状とを比
較する。そして、類似性が高い道路を、車両Ｃが現在走行している道路であると判断する。マップマッチングの結果、類似性の高い道路が検出されなかった場合、ＣＰＵ１１は、そのマップマッチングが失敗した道路又は地点を、メンテナンス地点として認識し、そのメンテナンス地点に関する検出データ３０をＲＡＭ１２に記憶する。図５（ａ）に示すように、検出データ３０は、地図描画データ２３のバージョン２３ｄ、経路データ２２又は地図描画データ２３に基づくリンクＩＤ３０ａ、座標データ２３ｍ等に基づく座標３０ｂ、属性３０ｃを有している。属性３０ｃは、マップマッチングが失敗した際の、車両Ｃの走行軌跡等である。

また、運転支援装置１０は、図２に示すように音声プロセッサ１７を備えている。音声プロセッサ１７は、ＣＰＵ１１の制御に従って、図示しない音声ファイルデータベースから音声ファイルを読出して音声信号を出力手段としてのスピーカ２６に出力する。これにより、経路を案内する案内音声等が出力される。

また、運転支援装置１０は、外部入力Ｉ／Ｆ部１８と、外部出力Ｉ／Ｆ部１９とを備えている。外部入力Ｉ／Ｆ部１８は、運転支援装置１０のディスプレイ２５に隣設された操作スイッチ２７等が操作されたとき、その入力操作に応じた電気信号をＣＰＵ１１に出力する。また、ディスプレイ２５は、タッチパネルであって、タッチパネルが入力操作されると、外部入力Ｉ／Ｆ部１８は、入力操作に応じた電気信号をＣＰＵ１１に出力する。

また、ＣＰＵ１１は、道路データ２３ｂ（協調制御データ）に基づき判断処理を行うとともに、車両ＥＣＵ５５に外部出力Ｉ／Ｆ部１９を介して制御信号を出力して、いわゆる車両協調制御を行う。車両ＥＣＵ５５は、例えばトランスミッションＥＣＵ、サスペンションＥＣＵ等があるが、ここでは図示を省略する。尚、車両協調制御とは、運転支援装置１０が、道路データ２３ｂ等に基づき道路形状や路面状況を推測して、推測した道路形状や路面形状に応じて行う車両Ｃの制御であって、本実施形態では加減速制御・段差制御を行う。

加減速制御は、道路形状に応じて、トランスミッションＥＣＵ等を制御して、車両Ｃの速度を調節するための制御である。まず、運転支援装置１０のＣＰＵ１１は、推奨経路の探索を実行している間は、その推奨経路内であって、車両Ｃの現在位置から所定距離内の道路に相当する道路データ２３ｂを読み出す。そして、道路データ２３ｂに基づき、進行方向前方の道路の曲率半径Ｒａ、道路を走行するときの車両Ｃの旋回角度、及びカーブ区間の距離を取得及び算出する。経路探索を行わず、単に車両Ｃの現在位置周辺を案内している場合には、車両Ｃの現在位置から所定距離内の道路に相当する道路データ２３ｂに基づき、道路の曲率半径Ｒａ、旋回角度、及びカーブ区間の距離を算出する。

また、ＣＰＵ１１は、旋回角度が閾値以上であるか否かを判断し、閾値以上であった場合には、コーナ制御を行う。このとき、ＣＰＵ１１は、ＲＯＭ１３から図示しない推奨速度マップを読出す。推奨速度マップは、曲率半径Ｒａと推奨速度Ｖｒとを関連付けた曲線であって、この曲線からは、曲率半径Ｒａが小さい場合には小さい推奨速度Ｖｒを、曲率半径Ｒａが大きい場合には比較的大きい推奨速度Ｖｒを算出される。ＣＰＵ１１は、曲率半径Ｒａと、推奨速度マップとに基づき、そのカーブを曲がる際の推奨速度Ｖｒを算出する。

そして、車両Ｃがカーブ入口から所定距離手前に到達すると、ＣＰＵ１１は、車速センサ５０に基づく現在の速度Ｖと、推奨速度Ｖｒとに基づいて、推奨変速段Ｔｒを算出する。このとき、ＣＰＵ１１は、道路データ２３ｂ中の勾配Ｄａを読み出し、勾配Ｄａが大きいと判断した場合には、推奨変速段Ｔｒを補正する。即ち、車両Ｃを登板路において減速させる場合には、シフトダウンの変速を行わなくても、減速効果が得られる。

さらに、ＣＰＵ１１は、車重センサ５４に基づく車両の総重量Ｗに応じて、推奨変速段Ｔｒを補正する。そして、算出した推奨変速段Ｔｒに基づき、車両ＥＣＵ５５（トランスミッションＥＣＵ）を制御する。その結果、急カーブの入口に車両Ｃが進入する際には、車両ＥＣＵ５５の制御に基づきシフトダウンされ、推奨速度Ｖｒまで減速されることとなる。

カーブ制御を実行している間には、ＣＰＵ１１は、自ら曲率半径Ｒ及び勾配Ｄを算出する。具体的には、ＣＰＵ１１は、速度Ｖ、角速度ω、加減速度α、上下加速度β、車両Ｃの総重量Ｗ等の車両情報を、車速センサ５０、ジャイロセンサ５１、Ｇセンサ５２、上下加速度センサ５３及び車重センサ５４から取得する。また、速度Ｖの微分値から算出した加速度γ、及びＧセンサ５２による加減速度αを用いて、以下の式に基づき、勾配Ｄ（傾斜角）を算出する。

Ｄ＝ａｒｃｓｉｎ｛（γ−α）／ｇ｝・・・（式１）
さらに、速度Ｖ及び角速度ωに基づき、曲率半径Ｒ（＝Ｖ／ω）を算出する。そして、勾配Ｄ及び曲率半径Ｒを、ＲＡＭ１２に記憶する。

また、運転支援装置１０のＣＰＵ１１は、推奨経路の案内を行っている場合には、その推奨経路内であって、車両Ｃの現在位置から所定距離内の道路に相当する道路データ２３ｂに基づき、道路の段差形状を検出する。道路データ２３ｂは、上記したように、段差形状を示す波長λａ、振幅レベルＬａを有している。波長λａは、図６に示すように、その道路を走行した場合の揺れのピークとなるピーク点Ｐの間の距離を示す。

ＣＰＵ１１は、道路データ２３ｂに基づき、ＲＯＭ１３に記憶された振幅レベルマップ６０（図１８参照）を用いて振幅レベルＬａを算出する。振幅レベルマップ６０は、上下加速度β及び振動数Ｎａ（＝速度Ｖ／波長λａ）と、揺れのレベル値とを関連付けたテーブルである。車両Ｃが、段差が生じている箇所まで到達すると、ＣＰＵ１１は、レベル値が高い場合には、サスペンションを硬く、レベル値が低い場合には、サスペンションを柔らかくする必要があると判断し、レベル値に応じた信号を車両ＥＣＵ５５（サスペンションＥＣＵ）に出力する。車両ＥＣＵ５５は、サスペンションのショックアブソーバの減衰力を制御して、振幅レベルＬａが大きくなるほど減衰力を比較的小さくする。

また、段差制御を実行している間、ＣＰＵ１１は、車両情報に基づいて、自ら波長λ、振幅レベルＬを算出し、ＲＡＭ１２に記憶する。具体的には、速度Ｖ、上下加速度β、総重量Ｗ等の車両情報を、車速センサ５０、上下加速度センサ５３及び車重センサ５４から取得する。また、上下加速度βの変化を追跡して、上下加速度βの変曲点を検出し、路面の凸部のピーク点Ｐを検出する。そして、変曲点が検出された時間Ｔ１と、次の変曲点が検出された時間Ｔ２を求める。また、ピーク点Ｐが検出されたピーク間隔ΔＴ（＝Ｔ２−Ｔ１）と、速度Ｖとを乗算して、各ピーク点Ｐの間の距離を示す波長λを算出する。さらに、波長λと速度Ｖとに基づき、振動数Ｎ（＝Ｖ／λ）を算出する。そして、算出した波長λと振動数Ｎとを、ＲＡＭ１２に記憶する。

このように、ＣＰＵ１１により、加減速制御及び段差制御が行われ、曲率半径Ｒ等の各種パラメータが生成されると、ＣＰＵ１１は、それらのデータと、道路データ２３ｂとを比較する。そして、曲率半径Ｒ、勾配Ｄ、波長λ、振幅レベルＬのうち、道路データ２３ｂ中の曲率半径Ｒａ、勾配Ｄａ、波長λａ及び振幅レベルＬａと異なるデータがある場合には、その差が閾値未満であるか否かを判断する。本実施形態では、各パラメータの差（例えば、勾配Ｄ，Ｄａ）は、各パラメータの値に対する割合（例えば、ΔＤ／Ｄａ）で表され、閾値は、１０％に設定されている。

例えば、算出した勾配Ｄが、道路データ２３ｂ中の勾配Ｄａと１０％以上異なる場合には、その地点をメンテナンス地点として認識し、検出データ３０としてＲＡＭ１２に記憶する。検出データ３０は、上記したように、バージョン２３ｄ、リンクＩＤ３０ａ、座標３０ｂ、属性３０ｃが記憶されているが（図５（ａ）参照）、属性３０ｃの中には、運転支援装置１０が算出したパラメータであって、差が１０％以上であった値（例えば、勾配Ｄ）が記憶されている。

このように、運転支援装置１０は、マップマッチングに失敗した地点、実際に車両協調制御が適切に実行されなかった地点を、メンテナンス地点として認識する。マップマッチングに失敗した地点は、その位置に道路が新設されているか、道路が改修されていることが想定されるので、そもそも道路データ２３ｂが存在せず、車両協調制御を実行できないと判断する。そして、ＣＰＵ１１は、所定のタイミングで、ＲＡＭ１２に検出データ３０が記憶されているか否かを判断し、検出データ３０が記憶されている場合には、その検出データ３０をプローブ情報Ｐｒとして、通信部１６を介して配信サーバ２に送信する。

図７に示すように、配信サーバ２は、受信手段、通知手段、配信手段としてのＣＰＵ４０、ＲＡＭ４１、ＲＯＭ４２、及び通信部４３を備える。さらに、配信サーバ２は、サーバ側地理データ記憶部４５を備える。ＣＰＵ４０は、ＲＯＭ４２に格納されたデータ更新プログラムに従って、データ更新のための各種処理を行う。

サーバ側地理データ記憶部４５には、全国地図に対応した、最新版のサーバ側経路データ４６、サーバ側描画データ４７が格納されている。サーバ側経路データ４６は、運転支援装置１０の経路データ２２と同様に、ヘッダ４６ａ、ノードデータ４６ｂ、リンクデータ４６ｃ、リンクコスト４６ｄ、座標データ４６ｅ、バージョン４６ｆを有している。また、サーバ側描画データ４７は、運転支援装置１０の地図描画データ２３と同様に、ヘッダ４７ａ、道路データ４７ｂ、背景データ４７ｃを有している。

さらに、配信サーバ２は、ユーザデータ記憶部４８を備えている。ユーザデータ記憶部４８には、各運転支援装置１０に対応するユーザデータ４８ａが格納されている。ユーザデータ４８ａには、各運転支援装置１０に対して付与されたＩＰアドレス等のＩＤ、ユーザが更新用の経路データ２２等を購入した際に、ユーザに対して課金を行うための各種データが格納されている。

以下、本発明を具体化した一実施形態を図８〜図１７に従って説明する。
まず、メンテナンス地点の登録処理について、図８〜１７に従って説明する。運転支援装置１０は、車両走行中、マップマッチング、車両協調制御（加減速制御、段差制御）を行いながら、メンテナンス地点の検出を行う。

まず、運転支援装置１０のＣＰＵ１１は、ＧＰＳ受信部１４、車速センサ５０及びジャイロセンサ５１に基づき、車両Ｃの現在位置を検出する（ステップＳ１−１）。また、自車位置を、道路データ２３ｂの中の道路に位置付けて、マップマッチングを行う。

そして、ＣＰＵ１１は、マップマッチングにより、自車位置を道路上に位置付けできたか否かを判断する（ステップＳ１−２）。例えば、走行軌跡が直線状であるにも関わらず、道路データ２３ｂに基づく道路形状が曲線状である場合には、マップマッチング失敗と判断する（ステップＳ１−２においてＮＯ）。この場合、ＣＰＵ１１は、マップマッチングが失敗した地点を、メンテナンス地点として登録する（ステップＳ１−３）。このとき、地図描画データ２３のバージョン２３ｄ、道路データ２３ｂ内のリンクＩＤ、座標データ２３ｍを検出データ３０に格納する。また、マップマッチングの失敗を示す識別データ
、走行軌跡を示す座標データ等を、属性３０ｃとして検出データ３０に格納する。また、ＣＰＵ１１は、ＲＡＭ１２に記憶されたメンテナンス地点カウンタＣ１の値を、インクリメントする。このメンテナンス地点カウンタＣ１は、ＲＡＭ１２に記憶された検出データ３０の数を累積するカウンタである。

自車位置を道路上に位置付けできた場合には（ステップＳ１−２においてＹＥＳ）、ステップＳ２−１に進む。
次に、ＣＰＵ１１は、図９に示すように、ジャイロセンサ５１から角速度ωを取得し、車速センサ５０から速度Ｖを取得する（ステップＳ２−１）。さらに、速度Ｖを角速度ωで除算して、曲率半径Ｒ（＝Ｖ／ω）を算出する（ステップＳ２−２）。また、ＣＰＵ１１は、道路データ２３ｂから、車両Ｃが現在走行している道路の曲率半径Ｒａを読出す（ステップＳ２−３）。尚、車両Ｃが、「急カーブ」等を示すフラグが対応付けられた地点に到達した際に、曲率半径Ｒの算出を行うようにしてもよい。

そして、ＣＰＵ１１は、角速度ω及び速度Ｖに基づき算出した曲率半径Ｒと、道路データ２３ｂの曲率半径Ｒａとを比較し、その差が閾値（１０％）未満であるか否かを判断する（ステップＳ２−４）。曲率半径Ｒ，Ｒａの差が１０％以上であると判断すると（ステップＳ２−４においてＮＯ）、曲率半径Ｒ，Ｒａが異なる地点を、メンテナンス地点として登録する（ステップＳ２−５）。このとき、ＣＰＵ１１は、検出データ３０に、地図描画データ２３のバージョン２３ｄ、道路データ２３ｂ内のリンクＩＤ及び座標データ２３ｍを格納する。さらに、曲率半径Ｒ，Ｒａが異なることを示す識別データ、新たに算出した曲率半径Ｒを含む属性３０ｃを検出データ３０に格納する。そして、この検出データ３０をＲＡＭ１２に記憶する。また、ＣＰＵ１１は、ＲＡＭ１２に記憶されたメンテナンス地点カウンタＣ１の値を、インクリメントする。差が１０％未満であると判断した場合には（ステップＳ２−４においてＹＥＳ）、ステップＳ３−１に進む。

図１０に示すように、ステップＳ３−１において、ＣＰＵ１１は、Ｇセンサ５２から上下加速度βを取得する。また、車速センサ５０から取得した速度Ｖを微分して、進行方向の加速度γを算出する（ステップＳ３−２）。さらに、取得した上下加速度β、加速度γと、上記した数式（１）に基づき、勾配Ｄを算出する（ステップＳ３−３）。また、ＣＰＵ１１は、道路データ２３ｂから、勾配Ｄａを読出す（ステップＳ３−４）。そして、上下加速度β及び加速度γに基づき算出した勾配Ｄと、道路データ２３ｂの勾配Ｄａとの差が閾値未満であるか否かを判断する（ステップＳ３−５）。本実施形態では、この閾値を１０％とし、勾配Ｄ，Ｄａの差が１０％未満である場合には（ステップＳ３−５においてＹＥＳ）、ステップＳ４−１に進む。

勾配Ｄ，Ｄａの差が１０％以上である場合には（ステップＳ３−５においてＮＯ）、勾配Ｄ，Ｄａの差が１０％以上である地点を、メンテナンス地点として登録する（ステップＳ３−６）。具体的には、ＣＰＵ１１は、検出データ３０に、地図描画データ２３のバージョン２３ｄ、道路データ２３ｂ内のリンクＩＤ及び座標データ２３ｍを格納する。また、新たに算出した勾配Ｄ、勾配が異なることを示す識別データを属性３０ｃとして検出データ３０に格納する。そして、この検出データ３０をＲＡＭ１２に記憶する。このとき、ＲＡＭ１２に記憶されたメンテナンス地点カウンタＣ１の値を、インクリメントする。

次に、ＣＰＵ１１は、波長又振幅レベルが道路データ２３ｂと異なるメンテナンス地点を検出する。図１１に示すように、ＣＰＵ１１は、上下加速度センサ５３から上下加速度βを取得する（ステップＳ４−１）。さらに、上下加速度βの変化を追跡して、上下加速度βの変曲点を検出し、変曲点が検出された時間Ｔ１と、次の変曲点が検出された時間Ｔ２を求める。また、各変曲点が検出された時間のピーク間隔ΔＴ（＝Ｔ２−Ｔ１）を算出するとともに、速度Ｖをピーク間隔ΔＴに乗算して、路面の凹凸形状を示す波長λを算出
する（ステップＳ４−２）。

さらに、ＣＰＵ１１は、ピーク間隔ΔＴに基づき、振動数Ｎ（＝１／ΔＴ）を算出する（ステップＳ４−３）。さらに、ＣＰＵ１１は、車重センサ５４から、そのときの車両Ｃの総重量Ｗを取得する（ステップＳ４−４）。

そして、ＣＰＵ１１は、上下加速度β、振動数Ｎと、図１８に示す振幅レベルマップ６０とに基づき、振幅レベルＬを判断する（ステップＳ４−５）。振幅レベルマップ６０は、３段階の上下加速度β（小）、上下加速度β（中）、上下加速度β（大）と、列方向の振動数Ｎ（大）、振動数Ｎ（中）、振動数Ｎ（小）とから、振幅レベルＬを算出可能になっている。このとき、車両Ｃの総重量Ｗが第１の所定値以上である場合には、車両重量が「大」であると判断し、上下加速度β（小）の絶対値は、０．０５〜０．１５ｍ／ｓ^２の範囲に設定される。また、上下加速度β（中）の絶対値は、０．１５〜０．２５ｍ／ｓ^２の範囲、上下加速度β（大）の絶対値は、０．２５ｍ／ｓ^２〜に設定される。

総重量Ｗが、第２の所定値以上、第１の所定値未満であって、「中」であると判断すると、上下加速度β（小）の絶対値は、０．１〜０．２ｍ／ｓ^２の範囲に設定され、上下加速度β（中）の絶対値は、０．２〜０．３ｍ／ｓ^２の範囲に、上下加速度β（大）の絶対値は、０．３ｍ／ｓ^２〜の範囲に設定される。

総重量Ｗが、第２の所定値未満であって、「小」であると判断すると、上下加速度β（小）の絶対値は、０．１５〜０．２５ｍ／ｓ^２の範囲に設定され、上下加速度β（中）の絶対値は、０．２５〜０．３５ｍ／ｓ^２の範囲に、上下加速度β（大）の絶対値は、０．３５ｍ／ｓ^２〜の範囲に設定される。即ち、車両Ｃの総重量Ｗが大きくなるほど、比較的大きな上下加速度βでも、低い振幅レベルＬが算出され、総重量Ｗが小さくなるほど、比較的小さな上下加速度βでも、高い振幅レベルＬが算出される。

この振幅レベルマップ６０に基づき、振幅レベルＬを算出すると、ＣＰＵ１１は、ステップＳ４−２で算出した波長λと、道路データ２３ｂに記憶された波長λａとを比較して、その差が閾値未満であるか否かを判断する。本実施形態では、この閾値は１０％に設定されている。また、ステップＳ４−５で算出した振幅レベルＬと、道路データ２３ｂに記憶された振幅レベルＬａが異なるか否かを判断する（ステップＳ４−６）。波長λと道路データ２３ｂの波長λａとの差が閾値未満及び各振幅レベルＬ，Ｌａが同じであると判断した場合には（ステップ４−６においてＹＥＳ）、ステップＳ４−８に進む。

ＣＰＵ１１が、各波長λ，λａの差が閾値以上、又は各振幅レベルＬ，Ｌａが異なると判断した場合には（ステップＳ４−６においてＮＯ）、その地点をメンテナンス地点として登録する（ステップＳ４−７）。このとき、ＣＰＵ１１は、バージョン２３ｄ、リンクＩＤ、座標データ２３ｍを記憶した検出データ３０を生成する。またその検出データ３０に、新たに算出した波長λと、波長が異なる事を示すフラグを、属性３０ｃとして記憶する。そして、その検出データ３０をＲＡＭ１２に記憶する。また、ＣＰＵ１１は、ＲＡＭ１２に記憶されたメンテナンス地点カウンタＣ１の値を、インクリメントする。

ステップＳ４−８では、ＣＰＵ１１は、終了トリガの入力があるか否かを判断する。終了トリガは、本実施形態ではイグニッションモジュールのオフ信号、又は運転支援装置１０の主電源のオフ信号である。終了トリガを入力した場合には（ステップＳ４−８においてＹＥＳ）、処理を終了する。このとき、ＲＡＭ１２に記憶された検出データ３０は消去されずに、開始トリガ（イグニッションモジュールのオン信号、主電源のオン信号）を入力するまで記憶する。終了トリガを入力しない場合には（ステップＳ４−８においてＮＯ）、ステップＳ１−１に戻り、車両Ｃが走行している間、車両協調制御と、メンテナンス
地点の登録とを繰り返す。このようにして、車両走行中には、メンテナンス地点の検出データ３０が蓄積される。尚、上記したように、メンテナンス地点は、道路の新設又は改修により、曲率半径Ｒａ等の制御パラメータ２３ｈやリンク形状データ２３ｉ等が無く、車両協調制御を実行できない地点と、曲率半径・勾配・波長・振幅レベルが制御パラメータ２３ｈと異なるために車両協調制御が実行できなかった地点とが含まれる。

次に、データ更新に関する処理について、図１２〜図１７に従って説明する。まず、運転支援装置１０がスリープ状態にあるとき、ＣＰＵ１１は、開始トリガの入力を待つ（ステップＳ５−１）。開始トリガは、本実施形態では、イグニッションモジュールのオン信号又は運転支援装置１０の主電源のオン信号である。

開始トリガを入力したと判断すると（ステップＳ５−１においてＹＥＳ）、通常のナビゲーション処理を起動し、自車位置の検出を行う。また、ＣＰＵ１１は、ＲＡＭ１２に記憶されたメンテナンス地点カウンタＣ１の値を取得して、未登録のメンテナンス地点数を取得する（ステップＳ５−２）。

また、ＣＰＵ１１は、メンテナンス地点数に基づき、配信サーバ２に送信されていない、未登録のメンテナンス地点があるか否かを判断する（ステップＳ５−３）。即ち、メンテナンス地点カウンタＣ１の値が「０」等の初期値であって、未登録のメンテナンス地点が無いと判断した場合には（ステップＳ５−３においてＮＯ）、次の処理である更新データ数の収集処理（ステップＳ６−１）に移行する。

メンテナンス地点カウンタＣ１の値が「０」以上であって、未登録のメンテナンス地点があると判断した場合には（ステップＳ５−３においてＹＥＳ）、ＲＡＭ１２に記憶された検出データ３０を、バージョン２２ｆ，２３ｄとともに、配信サーバ２に対して送信する（ステップＳ５−４）。配信サーバ２に検出データ３０を送信すると、ＣＰＵ１１は、メンテナンス地点カウンタＣ１の値を「０」に初期化する（ステップＳ５−５）。

配信サーバ２は、このように各地域を走行する各車両Ｃの運転支援装置１０から収集した、プローブ情報Ｐｒとしての各検出データ３０を、それぞれＲＡＭ４１に記憶する。そして、各運転支援装置１０から収集した各検出データ３０を統計処理する。例えば、配信サーバ２のＣＰＵ４０は、各検出データ３０が示すメンテナンス地点を含む道路を判断する。また、ＣＰＵ４０は、検出データ３０の属性３０ｃに基づき、メンテナンス地点を含む道路が、新設道路であるか、改修道路であるか、又は車両協調制御が適切に実行できなかった道路であるかを判断する処理を行う。例えば、属性３０ｃに、マップマッチングの失敗を示す識別データが記憶されていた場合、最新の道路データ４７ｂと車両Ｃの走行軌跡とを参照して、新設道路であるか又は改修道路であるかを判断する。属性３０ｃに、曲率半径Ｒ，Ｒａ、又は勾配Ｄ，Ｄａ、又は波長λ，λａ、又は振幅レベルＬ，Ｌａの差が閾値以上であることを示す識別データが記憶されている場合、車両協調不可道路であると判断する。さらに、最新版のサーバ側経路データ４６、又はサーバ側描画データ４７の更新点を検出した場合には、ノードデータ４６ｂやリンクデータ４６ｃ、座標データ４６ｅ等を更新する。又は、属性３０ｃに含まれている曲率半径Ｒ、勾配Ｄ、波長λ又は振幅レベルＬを、サーバ側描画データ４７の道路データ４７ｂに記憶して更新する。そして、更新したリージョンのバージョン４６ｆ，４７ｄを、更新する。

また、配信サーバ２のＣＰＵ４０は、メンテナンス地点を含む道路（メンテナンス道路）が、新設道路又は改修道路であると判断した場合には、ＲＡＭ４１に記憶された新設道路数カウンタC２又は改修道路数カウンタC３とをインクリメントする。新設道路数カウンタC２は、各バージョンの移行過程で、新設された道路を計数するカウンタである。例え
ばバージョン「１」と最新版のバージョン「５」との間の新設道路をカウントする第１新
設道路数カウンタC２ａと、バージョン「２」と最新版のバージョン「５」との間の新設
道路をカウントする第２新設道路数カウンタC２ｂ等が設定されている。ＣＰＵ１１は、
受信したバージョン２２ｆ，２３ｄを参照し、そのバージョン２２ｆ，２３ｄを始点とした移行期間の新設道路数カウンタC２、改修道路数カウンタC３をインクリメントする。

メンテナンス地点を含む道路が、車両協調制御が適切に実行できなかった道路であると判断した場合には、ＲＡＭ４１に記憶された制御不可道路数カウンタC４をインクリメン
トする。制御不可道路数カウンタC４も、新設道路数カウンタC２と同様に、各バージョンの移行過程で生じた、車両協調不可である道路を累積する各カウンタがそれぞれ設定されている。

さらに、配信サーバ２のＣＰＵ４０は、検出データ３０及び各カウンタＣ２〜Ｃ４に基づいて、通知情報としてのメンテナンス通知データ６５及び詳細通知データ６６を生成する。図５（ｂ）に示すように、メンテナンス通知データ６５は、各旧バージョンの数だけ生成され、各カウンタＣ２〜Ｃ４が計数した、新設道路数６５ａ、改修道路数６５ｂ、制御不可道路数６５ｃが含まれている。新しいバージョンになるほど、そのバージョンに対応するメンテナンス通知データ６５の各道路数６５ａ〜６５ｃは少なくなる。

図５（ｃ）に示すように、詳細通知データ６６には、サーバ側描画データ４７に基づく道路番号６６ａ、属性６６ｂが記憶されている。属性６６ｂには、その道路が、新設道路、改修道路、協調制御不可道路のいずれかであるのかを示す識別データが記憶されている。また、サーバ側経路データ４６及びサーバ側描画データ４７に、検出データ３０に基づく、新設道路、改修道路、協調制御不可道路が反映されている場合には、新設道路、改修道路、協調制御不可道路に関する、リンクコスト、道路種別（国道、県道、高速道路等）が、属性６６ｂに記憶されている。この道路番号６６ａ及び属性６６ｂからなるデータは、新設道路・改修道路・協調制御不可道路の数だけ記憶されている。また、詳細通知データ６６は、旧いバージョンの数だけ生成されている。

次に、運転支援装置１０が更新データ数を取得する処理について、図１３に従って説明する。検出データ３０を送信すると、運転支援装置１０のＣＰＵ１１は、配信サーバ２に対して、データ更新を要する道路を示す、新設道路数・改修道路数・協調制御不可地点数の取得要求と、経路データ２２のバージョン２２ｆ、地図描画データ２３のバージョン２３ｄとを送信する（ステップＳ６−１）。複数のバージョン２２ｆ，２３ｄが混在している場合には、各バージョン２２ｆ，２３ｄと、ヘッダ２２ａ，２３ａとを送信する。

配信サーバ２は、この要求を受信すると、受信したバージョン２２ｆ，２３ｄと最新版のバージョンとの間の差異を示すメンテナンス通知データ６５をＲＡＭ４１から読出して、運転支援装置１０に送信する（ステップＳ６−２）。

運転支援装置１０のＣＰＵ１１は、受信したメンテナンス通知データ６５に基づき、ダウンロードをしていないデータがあるか否かを判断し（ステップＳ６−３）、未ダウンロードデータがある場合には（ステップＳ６−３においてＹＥＳ）、道路番号のダウンロードを要求する（ステップＳ６−４）。未ダウンロードデータがない場合には（ステップＳ６−３においてＮＯ）、コスト算出処理（ステップＳ７−１）に進む。

配信サーバ２は、未ダウンロードデータの要求を受信すると、要求された道路番号、属性を含む詳細通知データ６６をＲＡＭ４１から読出し、運転支援装置１０に送信する（ステップＳ６−５）。運転支援装置１０は、受信した詳細通知データ６６を、ＲＡＭ４１に記憶する（ステップＳ６−６）。

次に、メンテナンス地点のコスト算出処理について、図１４に従って説明する。運転支援装置１０のＣＰＵ１１は、配信サーバ２から受信した詳細通知データ６６に基づき、データ更新の必要がある道路のコストを未計算であるか否かを判断する（ステップＳ７−１）。例えば、運転支援装置１０のＲＡＭ１２に、コスト算出フラグを記憶し、このコスト算出フラグが「ＯＮ」であった場合には、コストを算出済みであると判断して（ステップＳ７−１においてＮＯ）、コスト算出処理を終了する。

コスト算出フラグが「ＯＦＦ」であった場合には、コストを未計算であると判断して（ステップＳ７−１においてＹＥＳ）、詳細通知データ６６の道路番号６６ａに基づき、コスト算出を行う（ステップＳ７−２）。具体的には、ＣＰＵ１１は、道路番号６６ａに対応する道路が、図１９に示すコスト判定マップ６１に設定された道路に該当するか否かを判断する。コスト判定マップ６１は、メンテナンス道路を重み付けするためのマップであって、各条件項目６１ａ〜６１ｊが設定され、各条件項目６１ａ〜６１ｊには、コスト６１ｐ〜６１ｙが設定されている。

条件項目６１ａには、メンテナンス道路が、「自宅周辺から所定距離（５０ｋｍ）以内」が設定されている。条件項目６１ａを満たす場合には、コスト６１ｐである「５」が、そのメンテナンス道路のコストとして算出される。

条件項目６１ｂ〜６１ｄは、「登録済みの目的地までの最短距離ルートになりうる道」、「登録済みの目的地までの最短時間ルートになりうる道」、「登録済みの目的地までの最小料金ルートになりうる道」であって、「５」のコスト６１ｑ〜６１ｓが設定されている。ＣＰＵ１１は、詳細通知データ６６の属性６６ｂに、メンテナンス道路のリンクコストが含まれている場合には、各目的地までの探索履歴を示す、上記した探索履歴データ２４ａをＲＡＭ１２から読出す。そして、その目的地までの推奨経路を、メンテナンス道路のリンクコストを反映した経路データ２２を用いて再探索する。そして、距離、時間又は料金のいずれかが短縮又は縮小されるか否かを判断し、短縮又は縮小される場合には、メンテナンス道路のコストに「５」を加算する。このとき、例えば距離、時間及び料金のうち複数が短縮又は縮小される場合には、該当する条件項目６１ｂ〜６１ｄの数だけ、「５」を加算する。

条件項目６１ｅは、そのメンテナンス道路が主要道路であるかであって、「２」のコスト６１ｔが設定されている。ＣＰＵ１１は、受信した属性６６ｂに基づき、そのメンテナンス道路が主要道路であるか否かを判断する。また、条件項目６１ｆは、そのメンテナンス道路が自宅の同一県内であるか否かであって、「２」のコスト６１ｕが関連付けられている。また、条件項目６１ｇは、「走行履歴ルートから半径１ｋｍ以内」であって、「２」のコスト６１ｖが関連付けられている。ＣＰＵ１１は、上記した走行履歴データ２４ｂに基づき、そのメンテナンス道路が、走行履歴のある道路から１ｋｍ以内であるか否かを判断する。

また、条件項目６１ｈは、「自宅の隣接県内」であって、「１」のコスト６１ｗが設定され、条件項目６１ｉは、「走行履歴ルートから半径１０ｋｍ以内」であって、「１」のコスト６１ｘが関連付けられている。さらに、条件項目６１ｊは、その他の道路であって、「１」のコスト６１ｙが関連付けられている。

ＣＰＵ１１は、このコスト判定マップ６１に基づき、通知する新設道路があるか否かを判断する（ステップＳ７−３）。具体的には、ＣＰＵ１１は、算出したコストが「５」以上であって、詳細通知データ６６の属性６６ｂに、「新設道路」を示す識別データが含まれているか否かを判断する。新設道路がないと判断すると（ステップＳ７−３においてＮＯ）、ステップＳ７−５に進む。

新設道路があると判断すると（ステップＳ７−３においてＹＥＳ）、ＣＰＵ１１は、ＲＡＭ１２に記憶された新設道路数カウンタC５の値をインクリメントする（ステップＳ７
−４）。

さらに、ＣＰＵ１１は、通知する改修道路があるか否かを判断する（ステップＳ７−５）。具体的には、ＣＰＵ１１は、算出したコストが「５」以上であって、詳細通知データ６６の属性６６ｂに、「改修道路」が記憶されているか否かを判断する。改修道路がないと判断すると（ステップＳ７−５においてＮＯ）、ステップＳ７−７に進む。

改修道路があると判断した場合（ステップＳ７−５においてＹＥＳ）、ＣＰＵ１１は、ＲＡＭ１２に記憶された改修道路数カウンタC６の値をインクリメントする（ステップＳ
７−６）。

また、ＣＰＵ１１は、算出したコストが「５」以上であって、詳細通知データ６６の属性６６ｂに「協調制御不可道路」が記憶されているか否かを判断する（ステップＳ７−９）。協調制御不可道路ではないと判断した場合（ステップＳ７−９においてＮＯ）、通知方法判断処理（ステップＳ８−１）に進む。

協調制御不可道路があると判断した場合（ステップＳ７−９においてＹＥＳ）、制御不可道路数カウンタC７をインクリメントして（ステップＳ７−１０）、通知方法判断処理
（ステップＳ８−１）に進む。

その結果、各運転支援装置１０ごとに、車両Ｃが通行する可能性が高いメンテナンス道路の数が算出される。即ち、詳細通知データ６６で通知されたメンテナンス道路のうち、車両Ｃを運転操作するドライバーにとって必要性の高い道路が判別され、その数が、新設道路数カウンタC５、改修道路数カウンタC６、制御不可道路数カウンタC７に記憶される
。

次に、通知方法判断処理について、図１５に従って説明する。運転支援装置１０のＣＰＵ１１は、図２０に示す通知パターンマップ６２を、ＲＯＭ１３から読出す（ステップＳ８−１）。通知パターンマップ６２は、メンテナンス道路数と、各種通知方法とを関連付けている。

ＣＰＵ１１は、この通知パターンマップ６２に基づき、通知方法を選択する（ステップＳ８−２）。詳述すると、ＣＰＵ１１は、通知パターンマップ６２に基づき、メンテナンス道路数が「０〜９」である場合には、運転支援装置１０の起動時の通知画像を「表示」、起動時の通知音声が「通知なし」と判断する。また、車両Ｃ走行中に、そのメンテナンス道路に接近したとき、通知画像の描画が「なし」と判断する。

また、ＣＰＵ１１は、メンテナンス道路数が「１０〜９９」であると判断すると、起動時の通知画像の描画を行い、データ更新を推奨する音声を出力すると判断する。さらに、メンテナンス道路に接近したときは、通知画像の描画を行うと判断する。

さらに、ＣＰＵ１１は、メンテナンス道路数が「１００〜」であると判断すると、起動時の通知画像の描画を行い、データ更新を警告する音声を出力するとともに、メンテナンス道路に接近した場合には、通知画像の描画を行うと判断する。

そして、ＣＰＵ１１は、選択した通知パターンが、起動時の通知画像を表示するパターンであるか否かを判断する（ステップＳ８−３）。本実施形態では、起動時の通知画像を
表示しないパターンは設定されていないが、起動時の通知画像を表示しないパターンが選択された場合には（ステップＳ８−３においてＮＯ）、ステップＳ８−５に進む。

通知画像の描画を表示すると判断した場合（ステップＳ８−３においてＹＥＳ）、ＲＯＭ１３等から画像描画用の描画データを読出し、通知画像を出力する（ステップＳ８−４）。その結果、図２１に示す通知画像７０がディスプレイ２５に表示される。通知画像７０には、新設道路数表示７０ａと、改修道路数表示７０ｂと、制御不可道路数表示７０ｃとが表示されている。新設道路数表示７０ａは、メンテナンス通知データ６５の新設道路数６５ａに基づく新設道路数と、コストが「５」以上である新設道路数が表示されている。同様に、改修道路数表示７０ｂには、メンテナンス通知データ６５の改修道路数６５ｂに基づく改修道路数と、コストが「５」以上の改修道路数とが表示されている。制御不可道路数表示７０ｃには、メンテナンス通知データ６５の制御不可道路数６５ｃと、コストが「５」以上の協調制御不可道路の数とが表示されている。

次に、ＣＰＵ１１は、選択したパターンが、音声出力を行うパターンであるか否かを判断する（ステップＳ８−５）。音声出力を行うパターンである場合（ステップＳ８−５においてＹＥＳ）、その音声の種類が推奨音声であるか警告音声であるかを判断し、音声プロセッサ１７を制御して、その音声を出力する（ステップＳ８−６）。その結果、図２１に示すように、推奨音声７１又は警告音声（図示省略）が出力されるので、ドライバーは、通知画像７０及び推奨音声７１（又は警告音声）に基づいて、更新の必要性を判断する。

次に、データ更新処理について図１６に従って説明する。運転支援装置１０のＣＰＵ１１は、更新実行の入力操作を待つ（ステップＳ９−１）。具体的には、通知画像７０に表示された更新実行部７０ｄが入力操作されるのを待つ。

更新実行部７０ｄが入力操作されると（ステップＳ９−１においてＹＥＳ）、運転支援装置１０のＣＰＵ１１は、更新要求と、算出コストが「５」以上のメンテナンス道路の道路番号及び座標（又はリンクＩＤ）、運転支援装置１０のＩＤを配信サーバ２に対して送信する（ステップＳ９−２）。

配信サーバ２は、この要求を受信すると、受信した道路番号に基づき、メンテナンス道路を含むサーバ側経路データ４６、サーバ側描画データ４７を、サーバ側地理データ記憶部４５から読出す。そして、読出したサーバ側経路データ４６及びサーバ側描画データ４７を、それらのデータのバージョン４６ｆ，４７ｄとともに、受信したＩＤに基づき運転支援装置１０に送信する（ステップＳ９−３）。このとき、運転支援装置１０にとって重要度の高いメンテナンス道路のデータのみを送信することにより、データ通信量が軽減される。

運転支援装置１０は、受信した更新データを、地理データ記憶部２０に記憶して、データ更新を行う（ステップＳ９−４）。ＣＰＵ１１は、更新を行うと、経路データ２２又は地図描画データ２３のバージョン２２ｆ，２３ｄを、そのバージョンに応じて更新する。

また、配信サーバ２は、更新データを送信した後、そのデータ量等に応じて、ユーザデータ記憶部４８内のユーザデータ４８ａに基づき、課金処理を行うようにしてもよい。
次に、走行中の画面表示について、図１７に従って説明する。運転支援装置１０のＣＰＵ１１は、自車位置を検出しながら、コストが「５」以上のメンテナンス道路が、自車位置から所定距離以内であるか否かの判断を繰り返す（ステップＳ１０−１）。そして、メンテナンス道路が、自車位置から所定距離以内に入ったと判断した場合（ステップＳ１０−１においてＹＥＳ）、図２２に示す、走行中通知画像７３を表示する。走行中通知画像
７３には、メンテナンス道路の概略を示す道路表示７３ａと、例えば協調制御不可地点を示すメンテナンス地点指標７３ｂとが表示されている。

続いて、ＣＰＵ１１は、音声プロセッサ１７を制御して、更新を促す音声７４を出力する。ドライバーは、更新地点を実際に確認し、データ更新の必要があると判断すると、図示しない更新実行部を操作して、データ更新を要求する。データ更新が要求されると、上記したデータ更新処理が実行される。

上記実施形態によれば、以下のような効果を得ることができる。
（１）上記実施形態では、運転支援装置１０は、道路の形状、曲率半径Ｒａ、勾配Ｄａ、波長λａ、振幅レベルＬａ等を有する道路データ２３ｂを備えるとともに、道路データ２３ｂに沿って車両Ｃの協調制御を行う。また、運転支援装置１０のＣＰＵ１１は、車両協調制御に合わないメンテナンス地点を検出し、メンテナンス地点に関する検出データ３０を、配信サーバ２に送信するようにした。配信サーバ２は、プローブ情報Ｐｒとしての検出データ３０を各運転支援装置１０から収集し、メンテナンス地点数に関するメンテナンス通知データ６５及び詳細通知データ６６を生成し、これらのデータを運転支援装置１０に送信するようにした。運転支援装置１０は、受信したメンテナンス通知データ６５及び詳細通知データ６６に基づき、メンテナンス地点数を示す通知画像７０等をディスプレイ２５に出力し、推奨音声７１等を出力するようにした。さらに、通知画像７０等に基づき、ドライバーの操作があった場合には、配信サーバ２にデータ更新要求を送信し、そのメンテナンス地点を含む最新版のサーバ側経路データ４６及びサーバ側描画データ４７を受信して、地理データ記憶部２０内に記憶するようにした。このため、協調制御に沿わない地点も、通知情報に従って、経路データ２２及び地図描画データ２３の更新を行うことで、協調制御を可能にすることができる。

（２）上記実施形態では、配信サーバ２は、各運転支援装置１０から収集した検出データ３０に基づき、道路データ２３ｂの改訂を通知するメンテナンス通知データ６５及び詳細通知データ６６を生成するとともに、それらのデータを運転支援装置１０に送信するようにした。運転支援装置１０は、受信したメンテナンス通知データ６５及び詳細通知データ６６に基づき、通知画像７０及び走行中通知画像７３をディスプレイ２５に表示し、推奨音声７１等をスピーカ２６から出力するようにした。このため、データ更新前に、予め通知を行い、データ更新の可否を問うので、ドライバーにとって必要なタイミングでデータ更新を行うことができる。

（３）上記実施形態では、運転支援装置１０は、メンテナンス地点を検出した際に、運転支援装置１０が算出した曲率半径Ｒ、勾配Ｄ、波長λ、振幅レベルＬを、属性３０ｃとして検出データ３０に記憶して、配信サーバ２に送信するようにした。このため、配信サーバ２は、各運転支援装置１０から収集した検出データ３０を統計して、最適化した道路データ２３ｂを生成できる。運転支援装置１０は、この最適化された道路データ２３ｂによりデータ更新を行うことができるとともに、その運転支援装置１０が搭載された車両Ｃが走行したことのない道路のデータを得ることができる。

（４）上記実施形態では、配信サーバ２は、収集した検出データ３０に基づき、新設道路・改修道路・協調制御実行不可道路の数を示すメンテナンス通知データ６５を、運転支援装置１０に送信するようにした。このため、運転支援装置１０では、データ更新が必要なメンテナンス道路の数をディスプレイ２５に出力することができるので、ドライバーは、データ更新が必要なメンテナンス道路の数を確認し、データ更新の可否を決定することができる。従って、不必要なデータを受信して、運転支援装置１０の処理量が増大したり、通信コストが増大するのを抑制できる。

（５）上記実施形態では、運転支援装置１０は、詳細通知データ６６に基づき、メンテナンス道路のコスト計算による重み付けを行って、ドライバーが走行する可能性の高いメンテナンス道路の数を、通知画像７０内に表示するようにした。このため、ドライバーは、重要度の高いメンテナンス道路の情報を得ることによって、更新データの必要性を認識することができる。

（６）上記実施形態では、運転支援装置１０は、メンテナンス道路のコスト計算を行い、コストが「５」以上であるメンテナンス道路の数に応じて、通知パターンを選択するようにした。このため、例えば重要度の高いメンテナンス道路数が多い場合には、通知画像７０の表示、推奨音声７１又は警告音声の出力、走行中通知画像７３の表示を行って、車両協調制御が実行できなくなることを、ドライバーに把握させることができる。

尚、本実施形態は以下のように変更してもよい。
・上記実施形態では、経路データ２２及び地図描画データ２３を、図３及び図４に示すデータ構造にしたが、これ以外のデータ構造でもよい。

・上記実施形態では、Ｇセンサ５２、上下加速度センサ５３、車重センサ５４に基づき、加減速度α、上下加速度β、総重量Ｗを計測し、波長λ、振幅レベルＬ等を算出するようにしたが、他のセンサを用いてもよい。例えば、ショックアブソーバのピストンロッド内に組込まれたピエゾ圧力センサにより、路面の凹凸による振幅レベルを検出するようにしてもよい。

・上記実施形態では、運転支援装置１０は、カーブ制御の際には、曲率半径Ｒ、勾配Ｄを算出し、段差制御の際には、波長λ、振幅レベルＬを算出するようにしたが、旋回角度、振動数Ｎ等、これ以外のパラメータを算出し、ＲＡＭ１２に記憶するようにしてもよい。

・上記実施形態では、各曲率半径Ｒ，Ｒａ、各勾配Ｄ，Ｄａ、各波長λ，λａ、各振幅レベルＬ，Ｌａの差が１０％以上あるか否かによって、メンテナンス地点を登録するようにしたが、閾値は、１０％以外の値でもよい。

・振幅レベルマップ６０は、上下加速度β及び振動数Ｎａ等、段差の形状と振幅レベルとを関連づけしたマップであればよく、上記したマップに限定されない。また、コスト判定マップ６１は、メンテナンス道路の属性と、コストとを関連付けたマップであればよく、上記したマップに限定されない。また、通知パターンマップ６２は、メンテナンス道路数（又はメンテナンス地点数）と、通知方法とを関連づけしたマップであればよく、上記したマップに限定されない。

・上記実施形態では、運転支援装置１０は、通知画像７０とともに、その運転支援装置１０がメンテナンス地点として登録した道路数又は地点数をディスプレイ２５に表示するようにしてもよい。

・上記実施形態では、運転支援装置１０が、車両協調制御を行う地点を、経路データ２２又は地図描画データ２３に基づき判別可能にしてもよい。この場合、リンクＩＤや座標等と、その地点が車両協調制御を実行する地点であることを示す制御実行フラグが、関連づけられて経路データ２２又は地図描画データ２３に記憶されている。このようにすると、ＣＰＵ１１は、車両Ｃの進行方向前方に、制御実行フラグがＯＮである地点があるか否かを判断し、そのような地点があった場合には、車両協調制御を実行するとともに、メンテナンス地点であるか否かの判断を行う。

・上記実施形態では、運転支援装置１０のＣＰＵ１１は、コストが「５」以上のメンテナンス道路数に応じて、通知パターンを選択するようにしたが、常に一定の通知パターンにするようにしてもよい。

・上記実施形態では、運転支援装置１０は、道路番号６６ａに基づき、メンテナンス道路のコストを算出するようにしたが、この処理を省略するようにしてもよい。そして、メンテナンス道路数のみをディスプレイ２５に表示するようにしてもよい。

・上記実施形態では、配信サーバ２は、メンテナンス道路数を通知するメンテナンス通知データ６５及び詳細通知データ６６を、運転支援装置１０に送信するようにしたが、更新が必要なデータの有無を示すデータ等を送信するようにしてもよい。

・上記実施形態では、運転支援装置１０は、自らが算出した曲率半径Ｒ等の協調制御データを配信サーバ２に送信するようにしたが、メンテナンス地点を検出したことを示す識別データと、リンクＩＤ・座標のみを配信サーバ２に送信するようにしてもよい。このとき、例えば、配信サーバ２は、メンテナンス地点の検出を示すフラグを「ＯＮ」にする。そして、データ更新担当者により、フラグが「ＯＮ」にされた道路のデータを手動で更新するようにしてもよい。

・上記実施形態では、運転支援装置１０は、車両協調制御として、加減速制御、段差制御を行うようにしたが、その他の走行制御を行うようにしてもよい。
・上記実施形態では、運転支援装置１０は、配信サーバ２から更新データを受信するようにしたが、通知画像７０，走行中通知画像７３等を表示したり、推奨音声７１等を出力するのみでもよい。例えば、ドライバーは、これらの通知に基づき、販売店等の店舗に出向き、運転支援装置１０と、店舗が有する専用端末とをケーブル等で接続して、更新データを送信するようにしてもよい。又は、新たな経路データ２２及び地図描画データ２３を記憶した光ディスクを運転支援装置１０に挿入するようにしてもよい。

・上記実施形態では、運転支援装置１０は、ドライバーに対して、データ更新の必要を示す通知を行った後、入力操作の有無に応じて、データ更新要求を行うようにした。これ以外に、配信サーバ２が、各運転支援装置１０から受信した検出データ３０を統計処理して、更新データを生成し、通知を行うことなく、新たな更新データを自動的に各運転支援装置１０に配信するようにしてもよい。例えば更新データ量が少ない場合や、課金処理がない場合には、このようにすると、ドライバーは、入力操作することなくデータ更新を行うことができるので、利便性を向上できる。

・上記実施形態では、運転支援装置１０は、配信サーバ２からネットワークＮを介して更新データを受信するようにした。これ以外に、販売店等で、旧い経路データ２２及び地図描画データ２３が記憶された光ディスク又はハードディスクからなる地理データ記憶部２０を、新しいデータが記憶された地理データ記憶部２０に交換するようにしてもよい。

本実施形態のシステムを示す概略図。 本実施形態の運転支援装置の構成を説明するブロック図。 経路データの説明図。 （ａ）は地図描画データ、（ｂ）は道路データ、（ｃ）はリンク形状データの説明図。 （ａ）は検出データ、（ｂ）はメンテナンス通知データ、（ｃ）は詳細通知データの説明図。 波長の演算方法の説明図。 配信サーバの構成を説明するブロック図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 本実施形態の処理手順を示す説明図。 振幅レベルマップの説明図。 コスト判定マップの説明図。 通知判定マップの説明図。 通知画像の説明図。 走行中通知画像の説明図。

符号の説明

１…配信システム、２…配信サーバ、１０…運転支援装置、１１…協調制御手段、メンテナンス地点検出手段、送信手段、生成手段、更新データ取得手段、地点判別手段、パターン選択手段としてのＣＰＵ、１７…出力制御手段としての音声プロセッサ、２０…協調制御データ記憶手段としての地理データ記憶部、２１…出力制御手段としての画像プロセッサ、２３ｂ…協調制御データとしての道路データ、２５…出力手段としてのディスプレイ、２６…出力手段としてのスピーカ、３０…検出データ、３０ｃ…協調制御データとしての属性、４０…受信手段、通知手段、配信手段としてのＣＰＵ、４７…通知情報としてのメンテナンス通知データ、４８…通知情報としての詳細通知データ、Ｃ…車両、Ｎ…ネットワーク。

Claims (11)

1. 運転支援のための協調制御データを記憶した協調制御データ記憶手段、及び前記協調制御データに沿って車両の走行制御を行う協調制御手段を備えた運転支援装置と、前記運転支援装置とネットワークを介して接続された配信サーバとを用いて、前記協調制御データを更新する協調制御データ配信方法であって、
   前記運転支援装置が、
   前記協調制御データと前記車両の走行結果とが合わないメンテナンス地点を検出する段階と、
   検出したメンテナンス地点に関する検出データを、前記配信サーバに送信する段階と、
   前記配信サーバが、
   前記各運転支援装置から前記検出データを収集する段階と、
   更新した前記協調制御データを前記運転支援装置に送信する段階と
   を有することを特徴とする協調制御データ配信方法。
2. 請求項１に記載の協調制御データ配信方法において、
   前記配信サーバが、
   前記各運転支援装置から収集した前記検出データに基づき、前記協調制御データの改訂を通知する通知情報を生成する段階と、
   前記通知情報を前記各運転支援装置に送信する段階と、
   前記各運転支援装置から受信したデータ更新要求に基づき、更新された前記協調制御データを前記運転支援装置に送信する段階と、
   前記運転支援装置が、
   前記配信サーバから受信した前記通知情報を、出力手段に出力する段階と、
   前記通知情報に従って、前記データ更新要求を前記配信サーバに送信する段階と
   をさらに有することを特徴とする協調制御データ配信方法。
3. 請求項２に記載の協調制御データ配信方法において、
   前記配信サーバが、
   前記各車両に搭載された前記各運転支援装置から収集した前記各検出データに基づき、前記メンテナンス地点又はメンテナンス地点を含む道路の数を示す前記通知情報を生成することを特徴とする協調制御データ配信方法。
4. 車両に搭載された運転支援装置において、
   運転支援のための協調制御データを記憶した協調制御データ記憶手段と、
   前記協調制御データに沿って車両の走行制御を行う協調制御手段と、
   前記協調制御データと前記車両の走行結果とが合わないメンテナンス地点を検出するメンテナンス地点検出手段と、
   検出したメンテナンス地点に関する検出データを、配信サーバに送信する送信手段と、
   更新された協調制御データを、前記配信サーバから取得する更新データ取得手段と
   を備えることを特徴とする運転支援装置。
5. 請求項４に記載の運転支援装置において、
   前記配信サーバから受信した、前記協調制御データの改訂を通知する通知情報を、出力手段に出力する出力制御手段をさらに備えることを特徴とする運転支援装置。
6. 請求項４又は５に記載の運転支援装置において、
   前記メンテナンス地点に対する前記協調制御データを生成する生成手段をさらに備え、
   前記送信手段は、
   前記運転支援装置が算出した前記協調制御データを含む前記検出データを、前記配信サ
   ーバに送信することを特徴とする運転支援装置。
7. 請求項５又は６に記載の運転支援装置において、
   前記出力制御手段は、
   前記配信サーバから受信した、前記メンテナンス地点の数を示す前記通知情報を前記出力手段に出力することを特徴とする運転支援装置。
8. 請求項５〜７のいずれか１項に記載の運転支援装置において、
   前記通知情報に基づき、前記メンテナンス地点を重み付けして、重要度の高いメンテナンス地点を判断する地点判別手段をさらに備え、
   前記出力制御手段は、
   重要度の高いメンテナンス地点に関する通知を前記出力手段に出力することを特徴とする運転支援装置。
9. 請求項８に記載の運転支援装置において、
   前記更新データ取得手段は、
   前記重要度の高いメンテナンス地点のデータ更新要求を前記配信サーバに送信することを特徴とする運転支援装置。
10. 請求項５〜９のいずれか１項に記載の運転支援装置において、
    前記通知情報に基づき、重要度の高いメンテナンス道路数を算出し、そのメンテナンス道路数に応じて通知パターンを変更するパターン選択手段をさらに備えたことを特徴とする運転支援装置。
11. 車両に搭載された運転支援装置に、運転支援のための協調制御データを配信する配信サーバにおいて、
    前記各運転支援装置から、前記協調制御データと実際の走行結果とが合わないメンテナンス地点に関する検出データを収集する受信手段と、
    更新した前記協調制御データを前記運転支援装置に送信する配信手段と
    を備えたことを特徴とする配信サーバ。

Images