JP2014199213A - 走行支援システム、走行支援方法及びコンピュータプログラム - Google Patents

Abstract

【課題】渋滞情報の変化によって走行計画が頻繁に修正されることを防止した走行支援システム、走行支援方法及びコンピュータプログラムを提供する。【解決手段】ＶＩＣＳセンタから渋滞情報を取得するとともに、現在の車両の状態を取得し、車両の状態に基づく基準で、渋滞情報から車両の走行予定経路の渋滞状況が変化したか否か判定し、走行予定経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、走行計画４８を修正するように構成する。【選択図】図１５

Description

本発明は、駆動モータとエンジンとを駆動源として備えた車両において効率の良い走行を行う為の走行計画を作成する走行支援システム、走行支援方法及びコンピュータプログラムに関する。

近年においては、エンジンを駆動源とするガソリン車以外にもバッテリから供給される電力に基づいて駆動されるモータを駆動源とする電気自動車や、モータとエンジンを駆動源とするハイブリッド車両等が存在する。

そして、従来では上記ハイブリッド車両において、燃料効率の良い走行を行わせる為に、走行を開始する際に走行予定経路に対してモータとエンジンの制御スケジュールである走行計画を作成することが行われている。ここで、上記走行計画を作成する際には、走行中の燃料消費量を推測し、推測された燃料消費量を用いて走行計画を作成することが行われている。例えば、特開２０１１−２７４７２号公報では、リンクのリンク長と平均車速と渋滞情報に基づいて、該リンクを走行する際に必要な燃料消費量を算出し、燃料消費量を最小とする経路を探索するとともに、探索された経路を走行する際に燃料消費量を最小とする走行計画を作成する技術について記載されている。

特開２０１１−２７４７２号公報（第４頁〜第６頁、図１１）

ここで、上記特許文献１に記載の技術では、渋滞情報に基づいて走行計画を作成しているので、渋滞情報が変化すればその度に走行計画を修正（再計画）する必要がある。しかしながら、渋滞情報が変化する度に走行計画を修正することとすると、走行計画が頻繁に修正されることとなり、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担が大きくなる問題があった。また、渋滞情報の変化には、走行計画にほとんど影響の無い変化もあり、そのような場合においても一律に走行計画を修正することは、不要な処理負担が増加する原因となっていた。

本発明は前記従来における問題点を解消するためになされたものであり、駆動モータとエンジンとを駆動源として備えた車両の駆動モータとエンジンの制御スケジュールである走行計画を作成する場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止した走行支援システム、走行支援方法及びコンピュータプログラムを提供することを目的とする。

前記目的を達成するため本願の請求項１に係る走行支援システム（１）は、駆動源として駆動モータ（５）とエンジン（４）を備える車両（２）が所定の走行経路を走行する場合に、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した走行計画（４８）を作成する走行計画手段（３３）と、前記走行経路の渋滞情報を取得する渋滞情報取得手段（３３）と、前記車両の状態を取得する車両状態取得手段（３３）と、前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定手段（３３）と、前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正手段（３３）と、を有することを特徴とする。
尚、「駆動モータとエンジンとを駆動源として併用して」とは、必ずしもエンジンと駆動モータを両方駆動させた状態とする必要はなく、状況に応じていずれか一方のみを駆動させた状態も含む。例えば、エンジンのみを駆動源とする走行と、駆動モータのみを駆動源とする走行と、エンジンと駆動モータを両方駆動源とする走行のいずれかを走行状況によって使い分ける状態が該当する。

また、請求項２に係る走行支援システム（１）は、請求項１に記載の走行支援システムであって、前記車両状態取得手段（３３）は、前記車両（２）の状態として前記車両の動作モードを取得し、前記変化判定手段（３３）は、前記車両の動作モードに応じた異なる基準でリンク毎の渋滞度を算出し、算出された前記リンク毎の渋滞度を比較して前記走行経路の渋滞状況が変化したか否か判定することを特徴とする。

また、請求項３に係る走行支援システム（１）は、請求項２に記載の走行支援システムであって、前記車両（２）の状態は、前記走行経路に対して前記走行計画（４８）を作成し、前記駆動モータ（５）と前記エンジン（４）の駆動制御をするロング動作モードと、前記車両の進行方向前方の道路状況に基づいて前記車両の位置から進行方向前方の所定距離以内の範囲に対して前記走行計画を作成し、前記駆動モータと前記エンジンの駆動制御をするミドル動作モードのいずれかであって、前記変化判定手段（３３）は、前記車両の状態が前記ロング動作モードか前記ミドル動作モードかによって異なる基準によりリンク毎の渋滞度を算出し、算出された前記リンク毎の渋滞度を比較して前記走行経路の渋滞状況が変化したか否か判定することを特徴とする。

また、請求項４に係る走行支援システム（１）は、請求項３に記載の走行支援システムであって、前記渋滞情報は、前記走行経路の混雑区間及び前記混雑区間よりも渋滞度合いが高い渋滞区間を特定する情報であって、前記変化判定手段（３３）は、前記車両（２）の状態がミドル動作モードである場合に、前記走行経路を構成するリンクの少なくとも一部に前記渋滞区間があれば該リンクを渋滞と判定し、リンク内に前記渋滞区間が無く、且つリンクの少なくとも一部に前記混雑区間があれば該リンクを混雑と判定し、それ以外のリンクを空きと判定し、リンク毎の渋滞、混雑、空きの渋滞度の判定結果が変化した場合に、前記走行経路の渋滞状況が変化したと判定することを特徴とする。

また、請求項５に係る走行支援システム（１）は、請求項３に記載の走行支援システムであって、前記渋滞情報は、前記走行経路の混雑区間及び前記混雑区間よりも渋滞度合いが高い渋滞区間を特定する情報であって、前記変化判定手段は、前記車両（２）の状態がロング動作モードである場合に、前記走行経路を構成するリンクの半分以上が渋滞区間であれば該リンクを渋滞と判定し、それ以外のリンクを空きと判定し、リンク毎の渋滞、空きの渋滞度の判定結果が変化した場合に、前記走行経路の渋滞状況が変化したと判定することを特徴とする。

また、請求項６に係る走行支援システム（１）は、請求項１に記載の走行支援システムであって、前記車両（２）の状態は、前記車両内の通信における通信負荷であって、前記車両内の通信における通信負荷が高い程、前記変化判定手段（３３）の基準を前記走行経路の渋滞状況が変化したと判定され難くなる基準とすることを特徴とする。

また、請求項７に係る走行支援システム（１）は、請求項１に記載の走行支援システムであって、前記車両（２）の状態は、前記車両内の通信を制御する通信ＥＣＵ（１４）のリソースであって、前記通信ＥＣＵのリソースが少ない程、前記変化判定手段の基準を前記走行経路の渋滞状況が変化したと判定され難くなる基準とすることを特徴とする。

また、請求項８に係る走行支援方法は、駆動源として駆動モータ（５）とエンジン（４）を備える車両（２）が所定の走行経路を走行する場合に、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した走行計画を作成する走行計画ステップと、前記走行経路の渋滞情報を取得する渋滞情報取得ステップと、前記車両の状態を取得する車両状態取得ステップと、前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定ステップと、前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正ステップと、を有することを特徴とする。

更に、請求項９に係るコンピュータプログラムは、コンピュータに、駆動源として駆動モータ（５）とエンジン（４）を備える車両（２）が所定の走行経路を走行する場合に、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した走行計画を作成する走行計画機能と、前記走行経路の渋滞情報を取得する渋滞情報取得機能と、前記車両の状態を取得する車両状態取得機能と、前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定機能と、前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正機能と、を実行させることを特徴とする。

前記構成を有する請求項１に記載の走行支援システムによれば、エンジンと駆動モータを駆動源とするハイブリッド車両の駆動モータとエンジンの制御スケジュールである走行計画を作成する場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止することが可能となる。その結果、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。

また、請求項２に記載の走行支援システムによれば、車両の動作モードによって異なる基準によりリンク毎の渋滞度を算出し、算出されたリンク毎の渋滞度を比較して走行経路の渋滞状況が変化したか否か判定するので、車両の動作モードとその動作モードでの渋滞判定基準とに基づいて走行計画を修正する必要があるか否かを適切に判定することが可能となる。

また、請求項３に記載の走行支援システムによれば、車両の状態がロング動作モードかミドル動作モードかによって異なる基準によりリンク毎の渋滞度を算出し、算出されたリンク毎の渋滞度を比較して走行経路の渋滞状況が変化したか否か判定するので、車両の動作モードとその動作モードでの渋滞判定基準とに基づいて走行計画を修正する必要があるか否かを適切に判定することが可能となる。

また、請求項４に記載の走行支援システムによれば、車両の状態がミドル動作モードである場合に、渋滞の判定基準をより渋滞度が変化し易く且つ細分化することによって、渋滞情報の更新に基づく走行計画の修正を行い易く構成することが可能となる。その結果、バッテリ残量に余裕が無いような車両の状況では、走行計画を常に最適化することによって、燃料消費量が増加したりバッテリ残量が多い状態で走行を終了する等の事態の発生を防止し、効率の良い走行を行わせることが可能となる。

また、請求項５に記載の走行支援システムによれば、車両の状態がロング動作モードである場合に、渋滞の判定基準をより渋滞度が変化し難く且つ概略化することによって、渋滞情報の更新に基づく走行計画の修正を行い難く構成することが可能となる。その結果、バッテリ残量に余裕があるような車両の状況では、走行計画を可能な限り修正しないことによって、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。

また、請求項６に記載の走行支援システムによれば、車両内の通信負荷が高い状態程、渋滞情報の更新に基づく走行計画の修正を行い難く構成するので、走行計画に関する通信が頻繁に行われることによって車両内の他の通信が阻害されることを防止することが可能となる。

また、請求項７に記載の走行支援システムによれば、車両の通信ＥＣＵのリソースが少ない状態程、渋滞情報の更新に基づく走行計画の修正を行い難く構成するので、走行計画に関する通信が頻繁に行われることによって車両内の他の通信が阻害されることを防止することが可能となる。

また、請求項８に記載の走行支援方法によれば、エンジンと駆動モータを駆動源とするハイブリッド車両の駆動モータとエンジンの制御スケジュールである走行計画を作成する場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止することが可能となる。その結果、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。

更に、請求項９に記載のコンピュータプログラムによれば、エンジンと駆動モータを駆動源とするハイブリッド車両の駆動モータとエンジンの制御スケジュールである走行計画を作成させる場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止することが可能となる。その結果、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。

本実施形態に係る車両及び車両制御システムの概略構成図である。 本実施形態に係る車両制御システムの制御系を模式的に示すブロック図である。 渋滞情報ＤＢに記憶される渋滞情報の一例について示した図である。 車両がロング動作モードに設定されている場合において作成される走行計画の一例を示した図である。 車両がミドル動作モードに設定されている場合において作成される走行計画の一例を示した図である。 本実施形態に係る走行支援処理プログラムのフローチャートである。 渋滞判定基準の決定方法について説明した図である。 本実施形態に係る渋滞状況変化判定処理のサブ処理プログラムのフローチャートである。 本実施形態に係る第１判定処理のサブ処理プログラムのフローチャートである。 第１判定処理で走行予定経路の渋滞状況が変化したか否かを判定する際の具体例について示した図である。 本実施形態に係る第２判定処理のサブ処理プログラムのフローチャートである。 第２判定処理で走行予定経路の渋滞状況が変化したか否かを判定する際の具体例について示した図である。 第２判定処理で走行予定経路の渋滞状況が変化したか否かを判定する際の具体例について示した図である。 本実施形態に係る第３判定処理のサブ処理プログラムのフローチャートである。 第３判定処理で走行予定経路の渋滞状況が変化したか否かを判定する際の具体例について示した図である。 第３判定処理で走行予定経路の渋滞状況が変化したか否かを判定する際の具体例について示した図である。

以下、本発明に係る走行支援システムについてナビゲーション装置に具体化した一実施形態に基づき図面を参照しつつ詳細に説明する。
先ず、本実施形態に係るナビゲーション装置１を車載機として搭載した車両２の車両制御システム３の概略構成について図１及び図２を用いて説明する。図１は本実施形態に係る車両制御システム３の概略構成図、図２は本実施形態に係る車両制御システム３の制御系を模式的に示すブロック図である。尚、車両２はモータとエンジンを駆動源として用いるハイブリッド車両である。特に、以下に説明する実施形態では外部電源からバッテリを充電することができるプラグインハイブリッド車両を用いることとする。

図１及び図２に示すように、本実施形態に係る車両制御システム３は、車両２に対して設置されたナビゲーション装置１と、エンジン４と、駆動モータ５と、発電機６と、バッテリ７と、プラネタリギヤユニット８と、車両制御ＥＣＵ９と、エンジン制御ＥＣＵ１０と、駆動モータ制御ＥＣＵ１１と、発電機制御ＥＣＵ１２と、充電制御ＥＣＵ１３と、通信制御ＥＣＵ１４とから基本的に構成されている。

ここで、ナビゲーション装置１は、車両２の室内のセンターコンソール又はパネル面に備え付けられ、車両周辺の地図や目的地までの走行予定経路を表示する液晶ディスプレイ３５や、経路案内に関する音声ガイダンスを出力するスピーカ３６等を備えている。そして、ＧＰＳ等によって車両２の現在位置を特定するととともに、目的地が設定された場合においては出発地（例えば現在位置）から目的地までの経路の探索、並びに設定された走行予定経路に従った案内を液晶ディスプレイ３５やスピーカ３６を用いて行う。また、ナビゲーション装置１は、後述するように、出発地から目的地までの走行予定経路が設定された場合に、渋滞情報等に基づいて車両２の駆動源（エンジン４及び駆動モータ５）を制御する制御スケジュールである走行計画を作成する。尚、ナビゲーション装置１の詳細な構成については後述する。

また、エンジン４はガソリン、軽油、エタノール等の燃料によって駆動される内燃機関等のエンジンであり、車両２の第１の駆動源として用いられる。そして、エンジン４の駆動力であるエンジントルクはプラネタリギヤユニット８に伝達され、プラネタリギヤユニット８により分配されたエンジントルクの一部により駆動輪１７が回転させられ、車両２が駆動される。

また、駆動モータ５はバッテリ７から供給される電力に基づいて回転運動するモータであり、車両２の第２の駆動源として用いられる。駆動モータはバッテリ７から供給された電力により駆動され、駆動モータ５のトルクである駆動モータトルクを発生する。そして、発生した駆動モータトルクにより駆動輪１７が回転させられ、車両２が駆動される。更に、エンジンブレーキ必要時及び制動停止時において、駆動モータ５は回生ブレーキとして機能し、車両慣性エネルギーを電気エネルギーとして回生する。

また、本実施形態に係るプラグインハイブリッド車両では、ナビゲーション装置１において後述の走行計画が作成されている場合には、基本的に作成されている走行計画に基づいてエンジン４及び駆動モータ５が制御される。具体的には、走行計画において指定されたＥＶ走行区間では、駆動モータ５のみを駆動源として走行する所謂ＥＶ走行を行う。また、走行計画において指定されたＨＶ走行区間では、エンジン４と駆動モータ５とを駆動源として併用して走行する所謂ＨＶ走行を行う。尚、ＨＶ走行では、発進時や停止時や高速走行時等の走行状況に合わせて駆動源を切り替えて走行を行う。具体的には、エンジン４のみを駆動源とする走行と、駆動モータ５のみを駆動源とする走行と、エンジン４と駆動モータ５を両方駆動源とする走行のいずれかを走行状況によって使い分ける。
一方、ナビゲーション装置１において走行計画が作成されていない場合には、基本的にバッテリ７の残量が所定値以下となるまではＥＶ走行を行う。そして、バッテリ７の残量が所定値以下となった後はＨＶ走行を行う。

また、発電機６はプラネタリギヤユニット８により分配されたエンジントルクの一部により駆動され、電力を発生させる発電装置である。そして、発電機６は図示されない発電機用インバータを介してバッテリ７に接続されており、発生した交流電流を直流電流に変換し、バッテリ７に供給する。尚、駆動モータ５と発電機６を一体的に構成しても良い。

また、バッテリ７は充電と放電とを繰り返すことができる蓄電手段としての二次電池であり、鉛蓄電池、キャパシタ、ニッケルカドミウム電池、ニッケル水素電池、リチウムイオン電池、ナトリウム硫黄電池等が用いられる。更に、バッテリ７は車両２の側壁に設けられた充電コネクタ１８と接続されている。そして、自宅や所定の充電設備を備えた充電施設において、充電コネクタ１８をコンセント等の電力供給源に接続することにより、バッテリ７の充電を行うことが可能となる。更に、バッテリ７は上記駆動モータで発生した回生電力や発電機６で発電された電力によっても充電される。

また、プラネタリギヤユニット８はサンギヤ、ピニオン、リングギヤ、キャリア等によって構成され、エンジン４の駆動力の一部を発電機６へと分配し、残りの駆動力を駆動輪１７へと伝達する。

また、車両制御ＥＣＵ（エレクトロニック・コントロール・ユニット）９は、車両２の全体の制御を行う電子制御ユニットである。また、車両制御ＥＣＵ９には、エンジン４の制御を行う為のエンジン制御ＥＣＵ１０、駆動モータ５の制御を行う為の駆動モータ制御ＥＣＵ１１、発電機６の制御を行う為の発電機制御ＥＣＵ１２、バッテリ７の制御を行う為の充電制御ＥＣＵ１３が接続されるとともに、ＣＡＮ等の車載ネットワークを介してナビゲーション装置１を含む複数の車載器と双方向通信可能に接続されている。
そして、車両制御ＥＣＵ９は、演算装置及び制御装置としてのＣＰＵ２１、並びにＣＰＵ２１が各種の演算処理を行うに当たってワーキングメモリとして使用されるＲＡＭ２２、制御用のプログラム等が記録されたＲＯＭ２３等の内部記憶装置を備えている。

また、エンジン制御ＥＣＵ１０、駆動モータ制御ＥＣＵ１１、発電機制御ＥＣＵ１２及び充電制御ＥＣＵ１３は、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ等からなり、それぞれエンジン４、駆動モータ５、発電機６、バッテリ７の制御を行う。

また、通信制御ＥＣＵ１４は、ナビゲーション装置１を含む各種車載器や車両制御ＥＣＵ９との間で行われる通信の制御を行う。

続いて、ナビゲーション装置１の構成について図２を用いて説明する。
図２に示すように本実施形態に係るナビゲーション装置１は、ナビゲーション装置１が搭載された車両の現在位置を検出する現在位置検出部３１と、各種のデータが記録されたデータ記録部３２と、入力された情報に基づいて、各種の演算処理を行うナビゲーションＥＣＵ３３と、ユーザからの操作を受け付ける操作部３４と、ユーザに対して車両周辺の地図や施設の関する施設情報を表示する液晶ディスプレイ３５と、経路案内に関する音声ガイダンスを出力するスピーカ３６と、記憶媒体であるＤＶＤを読み取るＤＶＤドライブ３７と、プローブセンタやＶＩＣＳ（登録商標：Vehicle Information and Communication System）センタ等の情報センタとの間で通信を行う通信モジュール３８と、から構成されている。

以下に、ナビゲーション装置１を構成する各構成要素について順に説明する。
現在位置検出部３１は、ＧＰＳ４１、車速センサ４２、ステアリングセンサ４３、ジャイロセンサ４４等からなり、現在の車両の位置、方位、車両の走行速度、現在時刻等を検出することが可能となっている。ここで、特に車速センサ４２は、車両の移動距離や車速を検出する為のセンサであり、車両の駆動輪の回転に応じてパルスを発生させ、パルス信号をナビゲーションＥＣＵ３３に出力する。そして、ナビゲーションＥＣＵ３３は発生するパルスを計数することにより駆動輪の回転速度や移動距離を算出する。尚、上記４種類のセンサをナビゲーション装置１が全て備える必要はなく、これらの内の１又は複数種類のセンサのみをナビゲーション装置１が備える構成としても良い。

また、データ記録部３２は、外部記憶装置及び記録媒体としてのハードディスク（図示せず）と、ハードディスクに記録された地図情報ＤＢ４６、渋滞情報ＤＢ４７、走行計画４８、及び所定のプログラム等を読み出すとともにハードディスクに所定のデータを書き込む為のドライバである記録ヘッド（図示せず）とを備えている。尚、データ記録部３２をハードディスクの代わりにメモリーカードやＣＤやＤＶＤ等の光ディスクにより構成しても良い。

ここで、地図情報ＤＢ４６は、例えば、道路（リンク）に関するリンクデータ、ノード点に関するノードデータ、各分岐点に関する分岐点データ、施設等の地点に関する地点データ、地図を表示するための地図表示データ、経路を探索するための探索データ、地点を検索するための検索データ等が記憶された記憶手段である。尚、リンクデータには傾斜区間に関する情報（傾斜角度に関する情報を含む）、カーブに関する情報（開始点、終了点、旋回半径に関する情報を含む）も含まれる。また、地図情報ＤＢ４６を外部のサーバに記憶し、ナビゲーション装置１が通信によりリンクデータ等を取得する構成としても良い。

また、渋滞情報ＤＢ４７は、ＶＩＣＳセンタ等の交通情報センタから取得した渋滞情報が一定期間累積的に記憶される記憶手段である。ここで、渋滞情報ＤＢ４７に格納されている渋滞情報は、渋滞の度合いを示す渋滞度、渋滞度の区間を示す渋滞開始位置と渋滞長、旅行時間等を含む。ここで、渋滞度とは、渋滞の程度を示した情報であり、渋滞の程度の高い方から、『渋滞』、『混雑』、『空き』のデータがある。そして、この渋滞度は、道路の属性（都市間高速道路、都市内高速道路、一般道路）と道路を通過する車両の平均車速に基づいて決定される。一例として、一般道路では、平均車速が１０ｋｍ以下であれば“渋滞”と決定し、平均車速が１０ｋｍより大きく２０ｋｍ未満であれば“混雑”と決定し、平均車速が２０ｋｍ以上であれば“空き”と決定している。そして、ナビゲーション装置１は、所定時間毎（例えば５分毎）に光ビーコンやＦＭ多重放送等の通信網を介してＶＩＣＳセンタ等の交通情報センタから新たな渋滞情報を取得し、渋滞情報ＤＢ４７へと格納する。そして、渋滞情報ＤＢ４７に格納された渋滞情報は、一定期間（例えば１時間）保持され、後述のように走行計画の作成に用いられる。

以下に、図３を用いて渋滞情報ＤＢ４７に記憶される渋滞情報についてより詳細に説明する。図３は渋滞情報ＤＢ４７に記憶される渋滞情報の一例を示した図である。
図３に示すように渋滞情報は、リンクを識別するＶＩＣＳリンク番号と、そのリンクについての渋滞度、渋滞度の区間を示す渋滞開始位置と渋滞長、旅行時間等から構成される。例えば、図３に示す渋滞情報は、２０１３年１月６日の１３時５６分から１４時１分までの５分間に生成され１４時１分に配信される情報であり、ＶＩＣＳリンク番号『５３３９４５−４−４』のリンクについて、全区間において渋滞度が『渋滞』であり、旅行時間が７分であることを示している。また、ＶＩＣＳリンク番号『５３３９４６−１０−２』のリンクについて、全区間において渋滞度が『混雑』であり、旅行時間が５分であることを示している。更に、ＶＩＣＳリンク番号『５３３９４７−６−１』のリンクについて、地点Ａから２００ｍ区間において渋滞度が『混雑』であり、旅行時間が３分であることを示している。尚、渋滞情報ＤＢ４７には、上記渋滞情報以外の情報、例えば規制情報、駐車場情報、サービスエリア情報、パーキングエリア情報等についても記憶しても良い。

尚、ＶＩＣＳデータで用いられるリンク番号（ＶＩＣＳリンク番号）とナビゲーション装置１で用いられるリンク番号とは異なる。また、リンクの区分もＶＩＣＳデータとナビゲーション装置１とでは異なっている。従って、ナビゲーション装置１がＶＩＣＳセンタから渋滞情報を取得した場合には、ナビゲーション装置１が規定するリンク区分に基づく渋滞情報へと変換する必要がある。

また、走行計画４８は、ナビゲーション装置１において走行予定経路が設定された場合にナビゲーションＥＣＵ３３により作成され、走行予定経路を車両２が走行する際に、エンジン４及び駆動モータ５をどのように制御するかを決定する制御スケジュールである。

走行計画４８では、例えば走行予定経路の区間毎（本実施形態では特にリンク毎）にＥＶ走行を行うＥＶ走行区間と、ＨＶ走行を行うＨＶ走行区間とを設定する。例えば、図４には、リンクａ〜ｅからなる走行予定経路を走行する際に作成された走行計画４８の一例を示す。図４に示す走行計画４８では、リンクａはＥＶ走行区間に区分され、リンクｂ、ｃはＨＶ走行区間に区分され、リンクｄはＥＶ走行区間に区分され、リンクｅはＨＶ走行区間に区分される。尚、走行計画４８は、走行予定経路の渋滞情報、リンク情報（道路の形状、勾配、平均車速等）、車両情報（前面投影面積、駆動機構慣性重量、車重、駆動輪の転がり抵抗係数、空気抵抗係数、コーナリング抵抗等）から、ＥＶ走行を行った方が燃料効率が良いと予測できる区間はＥＶ走行区間に設定し、ＨＶ走行を行った方が燃料効率が良いと予測できる区間はＨＶ走行区間に設定する。また、後述のように車両の動作モードがロング動作モードである場合には、図４に示すように走行予定経路全体（但し、走行経路の全長が特に長い場合には出発地から所定距離（例えば２００ｋｍ）以内）に対して走行計画４８を作成する。一方、車両の動作モードがミドル動作モードである場合には、図５に示すように車両の現在位置から進行方向前方の所定距離以内（例えば３ｋｍ以内）の範囲に対してのみ走行計画４８を作成する。尚、特にミドル動作モードでは、バッテリ７の残量の目標値を設定し、その目標値に近づくように走行計画４８を作成する。また、ＥＶ走行区間やＨＶ走行区間以外にバッテリ７の残量に基づいてＥＶ走行を行うかＨＶ走行を行うかを決定する不特定走行区間を設定しても良い。

そして、車両２が走行予定経路を走行する際に、ナビゲーションＥＣＵ３３は車両２の現在位置と、走行計画４８とに基づいて、走行制御を変更（ＥＶ走行→ＨＶ走行、又は、ＨＶ走行→ＥＶ走行）するタイミングとなったか否かを判定する。そして、走行制御を変更するタイミングであると判定された場合に、車両制御ＥＣＵ９に対してＥＶ走行又はＨＶ走行を指示する制御指示を送信する。そして、ＥＶ走行を指示する制御指示を受信した車両制御ＥＣＵ９は、駆動モータ制御ＥＣＵ１１を介して駆動モータ５を制御し、駆動モータ５のみを駆動源とするＥＶ走行を開始する。また、ＨＶ走行を指示する制御指示を受信した車両制御ＥＣＵ９は、走行状況に応じてエンジン制御ＥＣＵ１０及び駆動モータ制御ＥＣＵ１１を介してエンジン４及び駆動モータ５を制御し、エンジン４と駆動モータ５とを駆動源として併用して走行するＨＶ走行を開始する。また、ＨＶ走行時には所定区間（例えば、車両２が高速で定常走行する区間）において発電機６を駆動することによって、バッテリ７の充電も行われる。
尚、渋滞情報ＤＢ４７や走行計画４８は外部のサーバに記憶し、ナビゲーション装置１が通信により更新又は取得する構成としても良い。

一方、ナビゲーションＥＣＵ（エレクトロニック・コントロール・ユニット）３３は、ナビゲーション装置１の全体の制御を行う電子制御ユニットであり、演算装置及び制御装置としてのＣＰＵ５１、並びにＣＰＵ５１が各種の演算処理を行うにあたってワーキングメモリとして使用されるとともに、経路が探索されたときの経路データ等が記憶されるＲＡＭ５２、制御用のプログラムのほか、後述の走行支援処理プログラム（図６参照）や車重等の車両に関する車両情報等が記録されたＲＯＭ５３、ＲＯＭ５３から読み出したプログラムを記憶するフラッシュメモリ５４等の内部記憶装置を備えている。尚、ナビゲーションＥＣＵ３３は、処理アルゴリズムとしての各種手段を構成する。例えば、走行計画手段は、走行予定経路に対してＥＶ走行区間とＨＶ走行区間を設定した走行計画を作成する。渋滞情報取得手段は、走行予定経路の渋滞情報を取得する。車両状態取得手段は、車両の状態を取得する。変化判定手段は、車両の状態に基づく基準で、渋滞情報から走行予定経路の渋滞状況が変化したか否か判定する。走行計画修正手段は、走行予定経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、走行計画を修正する。

操作部３４は、走行開始地点としての出発地及び走行終了地点としての目的地を入力する際等に操作され、各種のキー、ボタン等の複数の操作スイッチ（図示せず）から構成される。そして、ナビゲーションＥＣＵ３３は、各スイッチの押下等により出力されるスイッチ信号に基づき、対応する各種の動作を実行すべく制御を行う。尚、操作部３４は液晶ディスプレイ３５の前面に設けたタッチパネルによって構成することもできる。また、マイクと音声認識装置によって構成することもできる。

また、液晶ディスプレイ３５には、道路を含む地図画像、交通情報、操作案内、操作メニュー、キーの案内、出発地から目的地までの走行予定経路、走行予定経路に沿った案内情報、ニュース、天気予報、時刻、メール、テレビ番組等が表示される。

また、スピーカ３６は、ナビゲーションＥＣＵ３３からの指示に基づいて案内経路に沿った走行を案内する音声ガイダンスや、交通情報の案内を出力する。

また、ＤＶＤドライブ３７は、ＤＶＤやＣＤ等の記録媒体に記録されたデータを読み取り可能なドライブである。そして、読み取ったデータに基づいて音楽や映像の再生、地図情報ＤＢ４６の更新等が行われる。

また、通信モジュール３８は、交通情報センタ、例えば、ＶＩＣＳ（登録商標）センタやプローブセンタ等から送信された渋滞情報、規制情報、交通事故情報等の各情報から成る交通情報を受信する為の通信装置であり、例えば携帯電話機やＤＣＭが該当する。

続いて、前記構成を有するナビゲーション装置１においてナビゲーションＥＣＵ３３が実行する走行支援処理プログラムについて図６に基づき説明する。図６は本実施形態に係る走行支援処理プログラムのフローチャートである。ここで、走行支援処理プログラムは、ＶＩＣＳセンタから渋滞情報が送信されるタイミング（例えば５分間隔）で実行され、走行予定経路に沿って作成された走行計画４８を修正するプログラムである。尚、以下の図６、図８、図９、図１１及び図１４にフローチャートで示されるプログラムは、ナビゲーション装置１が備えているＲＡＭ５２やＲＯＭ５３に記憶されており、ＣＰＵ５１により実行される。

先ず、走行支援処理プログラムではステップ（以下、Ｓと略記する）１において、ＣＰＵ５１は、ＶＩＣＳセンタから送信された渋滞情報を取得する。ここで、渋滞情報は、渋滞の度合いを示す渋滞度、渋滞度を示す区間（開始位置や渋滞長）を含む（図３参照）。尚、取得された渋滞情報は渋滞情報ＤＢ４７へと累積的に格納される。

次に、Ｓ２においてＣＰＵ５１は、渋滞情報ＤＢ４７に格納された渋滞情報の内、直近に取得された渋滞情報とその１回前に取得された渋滞情報を比較し、車両の走行予定経路における渋滞情報が更新されたか否か判定する。尚、渋滞情報が更新された場合とは、渋滞度が変化した場合に加えて、渋滞度が同じで渋滞度を示す区間（開始位置や渋滞長）のみ変化した場合も含む。

そして、車両の走行予定経路における渋滞情報が更新されたと判定された場合（Ｓ２：ＹＥＳ）には、Ｓ３へと移行する。それに対して、車両の走行予定経路における渋滞情報が更新されていないと判定された場合（Ｓ２：ＮＯ）には、現在の走行計画４８を修正することなく当該走行支援処理プログラムを終了する。

Ｓ３においてＣＰＵ５１は、ＣＡＮを介して車両制御ＥＣＵ９や通信制御ＥＣＵ１４と通信を行うことにより、車両状態を取得する。尚、本実施形態では以下の（Ａ）〜（Ｃ）の車両状態について取得される。
（Ａ）車両の動作モード（ロング動作モード又はミドル動作モード）
（Ｂ）通信の負荷状況
（Ｃ）通信制御ＥＣＵ１４のリソース

ここで、車両の動作モードは、ロング動作モードとミドル動作モードのいずれかに特定される。そして、ロング動作モードは、走行予定経路全体（但し、走行経路の全長が特に長い場合には出発地から所定距離（例えば２００ｋｍ）以内）の走行計画４８を作成し（図４）、作成された走行計画に従って駆動モータ５とエンジン４の駆動制御をするモードである。また、ミドル動作モードは、車両の現在位置から進行方向前方の所定距離以内（例えば３ｋｍ以内）の範囲に対してのみ走行計画４８を作成し（図５）、作成された走行計画４８に従って駆動モータ５とエンジン４の駆動制御をするモードである。尚、ミドル動作モードは、バッテリ７の残量の目標値を設定し、その目標値に近づくように走行計画４８を作成する。また、プラグインハイブリッド車両では、基本的に走行開始時からバッテリ残量が所定基準値（例えば１０％）以下となるまではロング操作モードが設定され、バッテリ残量が所定基準値以下となるとミドル動作モードへと移行する。

次に、Ｓ４においてＣＰＵ５１は、前記Ｓ３で取得した車両状態に基づいて、渋滞判定基準を決定する。ここで、渋滞判定基準は、走行予定経路の渋滞状況が変化したか否か判定する為の基準である。

本実施形態では渋滞判定基準は以下の（１）〜（５）の５種類の基準が存在する。
（１）走行予定経路内の渋滞情報が僅かでも更新されていれば、走行予定経路の渋滞状況が変化したと判定する。
（２）走行予定経路全体の渋滞度を比較して、渋滞度が変化した部分があれば走行予定経路の渋滞状況が変化したと判定する。
（３）走行予定経路全体の渋滞度を比較して、渋滞度が変化した部分があれば走行予定経路の渋滞状況が変化したと判定する。但し、混雑は空きとみなす。
（４）ミドル判定基準により判定された渋滞度をリンク単位で比較して、渋滞度が変化したリンクがあれば走行予定経路の渋滞状況が変化したと判定する。
（５）ロング判定基準により判定された渋滞度をリンク単位で比較して、渋滞度が変化したリンクがあれば走行予定経路の渋滞状況が変化したと判定する。
尚、ミドル判定基準とは、リンクの少なくとも一部に渋滞区間があれば該リンクの渋滞度を渋滞と判定し、リンク内に渋滞区間が無く、且つリンクの少なくとも一部に混雑区間があれば該リンクの渋滞度を混雑と判定し、それ以外のリンクの渋滞度を空きと判定する基準である。
また、ロング判定基準とは、リンクの半分以上が渋滞区間であれば該リンクの渋滞度を渋滞と判定し、それ以外のリンクの渋滞度を空きと判定する基準である。
尚、（１）〜（５）の内、（１）の渋滞判定基準が走行予定経路の渋滞状況が変化したと最も判定され易く、以降（２）〜（５）の順で渋滞判定基準が走行予定経路の渋滞状況が変化したとより判定され難い基準となる。

そして、前記Ｓ４においてＣＰＵ５１は、図７に示す態様で、前記Ｓ３で取得した（Ａ）車両の動作モード（ロング動作モード又はミドル動作モード）、（Ｂ）通信の負荷状況、（Ｃ）通信制御ＥＣＵ１４のリソースの組み合わせによって渋滞判定基準を決定する。例えば、通信の負荷状況が所定の基準値より高く、通信制御ＥＣＵ１４のリソースが所定の基準値より少なく、車両の動作モードがミドル動作モードである場合には（２）の渋滞判定基準に決定される。尚、上記基準値の値は車両内で行われるＣＡＮ通信を正常に行うことができる負荷上限及びリソース下限とし、ＲＡＭ５２等に格納される。

次に、Ｓ５においてＣＰＵ５１は、後述の渋滞状況変化判定処理（図８）を実行する。尚、渋滞状況変化判定処理は、渋滞情報ＤＢ４７に格納された渋滞情報と前記Ｓ４で決定された渋滞判定基準とに基づいて、走行予定経路の渋滞状況が変化したか否かを判定する処理である。

続いて、Ｓ６においてＣＰＵ５１は、前記Ｓ５の渋滞状況変化判定処理において、走行予定経路の渋滞状況が変化したと判定されたか否かを判定する。

そして、前記Ｓ５の渋滞状況変化判定処理において、走行予定経路の渋滞状況が変化したと判定された場合（Ｓ６：ＹＥＳ）には、Ｓ７へと移行する。それに対して、前記Ｓ５の渋滞状況変化判定処理において、走行予定経路の渋滞状況が変化していないと判定された場合（Ｓ６：ＮＯ）には、現在の走行計画４８を修正することなく当該走行支援処理プログラムを終了する。

Ｓ７においてＣＰＵ５１は、変化後の走行予定経路の渋滞状況を用いて、現在の走行計画４８を再作成（修正）する。具体的には、走行予定経路の渋滞情報、リンク情報（道路の形状、勾配、平均車速等）、車両情報（前面投影面積、駆動機構慣性重量、車重、駆動輪の転がり抵抗係数、空気抵抗係数、コーナリング抵抗等）から、ＥＶ走行を行った方が燃料効率が良いと予測できる区間はＥＶ走行区間に設定し、ＨＶ走行を行った方が燃料効率が良いと予測できる区間はＨＶ走行区間に設定する（図４、図５）。尚、特にミドル動作モードでは、バッテリ７の残量の目標値を設定し、その目標値に近づくように走行計画４８を作成する。

そして、Ｓ８においてＣＰＵ５１は、修正された走行計画４８を、ＣＡＮを介して車両制御ＥＣＵ９へと送信する。尚、車両では、ナビゲーション装置１において作成され車両制御ＥＣＵ９へと送信された走行計画４８に基づいてエンジン４及び駆動モータ５が制御される。具体的には、走行計画４８において指定されたＥＶ走行区間では、駆動モータ５のみを駆動源として走行するＥＶ走行を行う。また、走行計画４８において指定されたＨＶ走行区間では、エンジン４と駆動モータ５とを駆動源として併用して走行するＨＶ走行を行う。尚、ＨＶ走行では、発進時や停止時や高速走行時等の走行状況に合わせて駆動源を切り替えて走行を行う。具体的には、エンジン４のみを駆動源とする走行と、駆動モータ５のみを駆動源とする走行と、エンジン４と駆動モータ５を両方駆動源とする走行のいずれかを走行状況によって使い分ける。

次に、前記Ｓ５において実行される渋滞状況変化判定処理のサブ処理について図８に基づき説明する。図８は渋滞状況変化判定処理のサブ処理プログラムのフローチャートである。

先ず、Ｓ１１においてＣＰＵ５１は、前記Ｓ４で決定された渋滞判定基準が上記（１）の判定基準であるか否か判定する。

そして、前記Ｓ４で決定された渋滞判定基準が上記（１）の判定基準であると判定された場合（Ｓ１１：ＹＥＳ）にはＳ１２へと移行し、後述の第１判定処理（図９）を実行する。その後、Ｓ６へと移行する。

それに対して、前記Ｓ４で決定された渋滞判定基準が上記（１）の判定基準でないと判定された場合（Ｓ１１：ＮＯ）には、Ｓ１３へと移行する。

Ｓ１３においてＣＰＵ５１は、前記Ｓ４で決定された渋滞判定基準が上記（２）又は（３）の判定基準であるか否か判定する。

そして、前記Ｓ４で決定された渋滞判定基準が上記（２）又は（３）の判定基準であると判定された場合（Ｓ１３：ＹＥＳ）にはＳ１４へと移行し、後述の第２判定処理（図１１）を実行する。その後、Ｓ６へと移行する。

それに対して、前記Ｓ４で決定された渋滞判定基準が上記（２）及び（３）の判定基準でもないと判定された場合（Ｓ１３：ＮＯ）、即ち、前記Ｓ４で決定された渋滞判定基準が上記（４）又は（５）の判定基準であると判定された場合には、Ｓ１５へと移行し、後述の第３判定処理（図１４）を実行する。その後、Ｓ６へと移行する。

次に、前記Ｓ１２において実行される第１判定処理のサブ処理について図９に基づき説明する。図９は第１判定処理のサブ処理プログラムのフローチャートである。

先ず、Ｓ２１においてＣＰＵ５１は、走行予定経路を構成する全リンクに対して以下のＳ２２の判定処理が行われたか否かを判定する。

そして、走行予定経路を構成する全リンクに対して以下のＳ２２の判定処理が行われたと判定された場合（Ｓ２１：ＹＥＳ）には、Ｓ２５へと移行する。それに対して、走行予定経路を構成する全リンクに対して以下のＳ２２の判定処理が行われていないと判定された場合（Ｓ２１：ＮＯ）には、Ｓ２２へと移行する。

Ｓ２２においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンク（出発地から近い順に選択される）について、渋滞情報ＤＢ４７に格納された渋滞情報の内、直近に取得された渋滞情報とその１回前に取得された渋滞情報（渋滞度及び渋滞度を示す区間）を比較する。そして、渋滞情報が変化（即ち、渋滞情報によって特定される渋滞度、渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれかが変化）したか否か判定する。

その結果、リンクの渋滞情報が変化したと判定された場合（Ｓ２２：ＹＥＳ）には、Ｓ２４へと移行する。それに対して、リンクの渋滞情報が変化していないと判定された場合（Ｓ２２：ＮＯ）には、Ｓ２３へと移行する。

Ｓ２３においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンクを次のリンクへと更新する。その後、Ｓ２１へと戻り、更新後のリンクを対象としてＳ２２以降の処理が行われる。

また、Ｓ２４においてＣＰＵ５１は、走行予定経路の渋滞状況が変化したと判定する。その後、Ｓ６へと移行する。その結果、Ｓ７において走行計画４８が修正されることとなる。

一方、Ｓ２５においてＣＰＵ５１は、走行予定経路の渋滞状況が変化していないと判定する。その後、Ｓ６へと移行する。その結果、走行計画４８は修正されないこととなる。

ここで、渋滞判定基準が（１）の場合に実行される上記第１判定処理（図９）では、図１０に示すように走行予定経路を構成するリンクの内、リンクの一部又は全部において渋滞度を示す区間が変化したリンクや渋滞度が変化したリンクがあれば、走行予定経路の渋滞状況が変化したと判定されることとなる。

次に、前記Ｓ１４において実行される第２判定処理のサブ処理について図１１に基づき説明する。図１１は第２判定処理のサブ処理プログラムのフローチャートである。

先ず、Ｓ３１においてＣＰＵ５１は、走行予定経路を構成する全リンクに対して以下のＳ３２以降の判定処理が行われたか否かを判定する。

そして、走行予定経路を構成する全リンクに対して以下のＳ３２以降の判定処理が行われたと判定された場合（Ｓ３１：ＹＥＳ）には、Ｓ３７へと移行する。それに対して、走行予定経路を構成する全リンクに対して以下のＳ３２以降の判定処理が行われていないと判定された場合（Ｓ３１：ＮＯ）には、Ｓ３２へと移行する。

Ｓ３２においてＣＰＵ５１は、前記Ｓ４で決定された渋滞判定基準が上記（２）の判定基準であるか否か判定する。

そして、前記Ｓ４で決定された渋滞判定基準が上記（２）の判定基準であると判定された場合（Ｓ３２：ＹＥＳ）には、Ｓ３３へと移行する。それに対して、前記Ｓ４で決定された渋滞判定基準が上記（３）の判定基準であると判定された場合（Ｓ３２：ＮＯ）には、Ｓ３６へと移行する。

Ｓ３３においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンク（出発地から近い順に選択される）について、渋滞情報ＤＢ４７に格納された渋滞情報の内、直近に取得された渋滞情報とその１回前に取得された渋滞情報（渋滞度及び渋滞度を示す区間）を比較する。そして、渋滞情報によって特定されるリンクの渋滞度及び渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれかが変化したか否か判定する。

その結果、リンクの渋滞度及び渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれかが変化したと判定された場合（Ｓ３３：ＹＥＳ）には、Ｓ３５へと移行する。それに対して、リンクの渋滞度及び渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれも変化していないと判定された場合（Ｓ３３：ＮＯ）には、Ｓ３４へと移行する。

Ｓ３４においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンクを次のリンクへと更新する。その後、Ｓ３１へと戻り、更新後のリンクを対象としてＳ３２以降の処理が行われる。

また、Ｓ３５においてＣＰＵ５１は、走行予定経路の渋滞状況が変化したと判定する。その後、Ｓ６へと移行する。その結果、Ｓ７において走行計画４８が修正されることとなる。

一方、Ｓ３６においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンク（出発地から近い順に選択される）について、渋滞情報ＤＢ４７に格納された渋滞情報の内、直近に取得された渋滞情報とその１回前に取得された渋滞情報（渋滞度及び渋滞度を示す区間）を比較する。そして、渋滞情報によって特定されるリンクの渋滞度及び渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれかが変化したか否か判定する。但し、前記Ｓ３６の判定処理では混雑の渋滞度については考慮しない（即ち、混雑区間については空きとみなす）。

その結果、リンクの渋滞度及び渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれかが変化したと判定された場合（Ｓ３６：ＹＥＳ）には、Ｓ３５へと移行する。それに対して、リンクの渋滞度及び渋滞度を示す区間（渋滞長、渋滞開始位置）のいずれも変化していないと判定された場合（Ｓ３６：ＮＯ）には、Ｓ３４へと移行する。

一方、Ｓ３７においてＣＰＵ５１は、走行予定経路の渋滞状況が変化していないと判定する。その後、Ｓ６へと移行する。その結果、走行計画４８は修正されないこととなる。

ここで、渋滞判定基準が（２）の場合に実行される上記第２判定処理（図１１）では、図１２に示すように走行予定経路を構成するリンクの内、渋滞度を示す区間が変化したリンクや渋滞度が変化したリンクがあれば、走行予定経路の渋滞状況が変化したと判定されることとなる。尚、渋滞度としては混雑も渋滞や空きと区分して判定対象となる。従って、渋滞度が空きから混雑へと変化した場合や、混雑を示す区間が変化した場合にも、走行予定経路の渋滞状況が変化したと判定されることとなる。

一方、渋滞判定基準が（３）の場合に実行される上記第２判定処理（図１１）では、図１３に示すように走行予定経路を構成するリンクの内、渋滞度を示す区間が変化したリンクや渋滞度が変化したリンクがあれば、走行予定経路の渋滞状況が変化したと判定されることとなる。但し、渋滞情報に含まれる混雑区間は空きとみなされるので、例えば、渋滞度が空きから混雑へと変化した場合や、混雑を示す区間が変化した場合には、走行予定経路の渋滞状況が変化していないと判定されることとなる。従って、渋滞判定基準が（２）の場合よりも走行予定経路の渋滞状況が変化したと判定され難くなる。

次に、前記Ｓ１５において実行される第３判定処理のサブ処理について図１４に基づき説明する。図１４は第３判定処理のサブ処理プログラムのフローチャートである。

先ず、Ｓ４１においてＣＰＵ５１は、走行予定経路を構成する全リンクに対して以下のＳ４２以降の判定処理が行われたか否かを判定する。

そして、走行予定経路を構成する全リンクに対して以下のＳ４２以降の判定処理が行われたと判定された場合（Ｓ４１：ＹＥＳ）には、Ｓ４８へと移行する。それに対して、走行予定経路を構成する全リンクに対して以下のＳ４２以降の判定処理が行われていないと判定された場合（Ｓ４１：ＮＯ）には、Ｓ４２へと移行する。

Ｓ４２においてＣＰＵ５１は、前記Ｓ４で決定された渋滞判定基準が上記（４）の判定基準であるか否か判定する。

そして、前記Ｓ４で決定された渋滞判定基準が上記（４）の判定基準であると判定された場合（Ｓ４２：ＹＥＳ）には、Ｓ４３へと移行する。それに対して、前記Ｓ４で決定された渋滞判定基準が上記（５）の判定基準であると判定された場合（Ｓ４２：ＮＯ）には、Ｓ４４へと移行する。

Ｓ４３においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンクの渋滞度をミドル判定基準によりリンク単位で特定する。尚、ミドル判定基準では、前記したようにリンクの少なくとも一部に渋滞区間があれば該リンクの渋滞度を渋滞と判定し、リンク内に渋滞区間が無く、且つリンクの少なくとも一部に混雑区間があれば該リンクの渋滞度を混雑と判定し、それ以外のリンクの渋滞度を空きと判定する。そして、上記Ｓ４３の渋滞度の特定は、渋滞情報ＤＢ４７に格納された渋滞情報の内、直近に取得された渋滞情報とその１回前に取得された渋滞情報のそれぞれに基づいて計２パターン特定する。その後、Ｓ４５へと移行する。

一方、Ｓ４４においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンクの渋滞度をロング判定基準によりリンク単位で特定する。尚、ロング判定基準では、リンクの半分以上が渋滞区間であれば該リンクの渋滞度を渋滞と判定し、それ以外のリンクの渋滞度を空きと判定する。そして、上記Ｓ４４の渋滞度の特定は、渋滞情報ＤＢ４７に格納された渋滞情報の内、直近に取得された渋滞情報とその１回前に取得された渋滞情報のそれぞれに基づいて計２パターン特定する。その後、Ｓ４５へと移行する。

次に、Ｓ４５においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンクについて、前記Ｓ４３又はＳ４４で直近に取得された渋滞情報に基づいて特定された渋滞度とその１回前に取得された渋滞情報に基づいて特定された渋滞度を比較する。そして、リンクの渋滞度が変化したか否か判定する。

その結果、リンクの渋滞度が変化したと判定された場合（Ｓ４５：ＹＥＳ）には、Ｓ４７へと移行する。それに対して、リンクの渋滞度が変化していないと判定された場合（Ｓ４５：ＮＯ）には、Ｓ４６へと移行する。

Ｓ４６においてＣＰＵ５１は、走行予定経路を構成するリンクの内、判定対象となるリンクを次のリンクへと更新する。その後、Ｓ４１へと戻り、更新後のリンクを対象としてＳ４２以降の処理が行われる。

また、Ｓ４７においてＣＰＵ５１は、走行予定経路の渋滞状況が変化したと判定する。その後、Ｓ６へと移行する。その結果、Ｓ７において走行計画４８が修正されることとなる。

一方、Ｓ４８においてＣＰＵ５１は、走行予定経路の渋滞状況が変化していないと判定する。その後、Ｓ６へと移行する。その結果、走行計画４８は修正されないこととなる。

ここで、渋滞判定基準が（４）の場合に実行される上記第３判定処理（図１４）では、図１５に示すように走行予定経路を構成するリンクの内、ミドル判定基準によりリンク単位で特定された渋滞度が変化したリンクがあれば、走行予定経路の渋滞状況が変化したと判定されることとなる。尚、リンクの一部に渋滞区間や混雑区間があれば、該リンクの渋滞度は渋滞又は混雑と判定される（即ち、リンクの渋滞度がより変化し易く且つ細分化される）こととなるので、渋滞判定基準が（５）の場合よりも走行予定経路の渋滞状況が変化したと判定され易くなる。

一方、渋滞判定基準が（５）の場合に実行される上記第３判定処理（図１４）では、図１６に示すように走行予定経路を構成するリンクの内、ロング判定基準によりリンク単位で特定された渋滞度が変化したリンクがあれば、走行予定経路の渋滞状況が変化したと判定されることとなる。尚、リンクの半分以上が渋滞区間でなければリンクの渋滞度は渋滞と判定されず、混雑も考慮されない（即ち、リンクの渋滞度がより変化し難く、概略化される）ので、渋滞判定基準が（４）の場合よりも走行予定経路の渋滞状況が変化したと判定され難くなる。

以上詳細に説明した通り、本実施形態に係るナビゲーション装置１、ナビゲーション装置１による走行支援方法及びナビゲーション装置１で実行されるコンピュータプログラムでは、ＶＩＣＳセンタから渋滞情報を取得するとともに（Ｓ１）、現在の車両の状態を取得し（Ｓ３）、車両の状態に基づく基準で、渋滞情報から車両の走行予定経路の渋滞状況が変化したか否か判定し（Ｓ６）、走行予定経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、走行計画４８を修正する（Ｓ７）ので、渋滞情報の変化によって走行計画４８が頻繁に修正されることを防止することが可能となる。その結果、走行計画４８の修正に係る処理負担や修正された走行計画４８を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画４８を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。
また、車両の状態がロング動作モードかミドル動作モードかによって異なる基準によりリンク毎の渋滞度を算出し、算出されたリンク毎の渋滞度を比較して走行経路の渋滞状況が変化したか否か判定するので、車両の動作モードとその動作モードでの渋滞判定基準とに基づいて走行計画を修正する必要があるか否かを適切に判定することが可能となる。
また、車両の状態がミドル動作モードである場合には、渋滞の判定基準をより渋滞度が変化し易く且つ細分化することによって、渋滞情報の更新に基づく走行計画の修正を行い易く構成することが可能となる。その結果、バッテリ残量に余裕が無いような車両の状況では、走行計画を常に最適化することによって、燃料消費量が増加したりバッテリ残量が多い状態で走行を終了する等の事態の発生を防止し、効率の良い走行を行わせることが可能となる。
また、車両の状態がロング動作モードである場合には、渋滞の判定基準をより渋滞度が変化し難く且つ概略化することによって、渋滞情報の更新に基づく走行計画の修正を行い難く構成することが可能となる。その結果、バッテリ残量に余裕があるような車両の状況では、走行計画を可能な限り修正しないことによって、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。
また、車両内の通信負荷が高い状態程、渋滞情報の更新に基づく走行計画の修正を行い難く構成するので、走行計画に関する通信が頻繁に行われることによって車両内の他の通信が阻害されることを防止することが可能となる。
また、車両の通信制御ＥＣＵ１４のリソースが少ない状態程、渋滞情報の更新に基づく走行計画の修正を行い難く構成するので、走行計画に関する通信が頻繁に行われることによって車両内の他の通信が阻害されることを防止することが可能となる。

尚、本発明は前記実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の改良、変形が可能であることは勿論である。
例えば、本実施形態では、渋滞情報はＶＩＣＳセンタから取得する構成としているが、ＶＩＣＳセンタ以外のセンタ（例えばプローブセンタ）から渋滞情報を取得する構成としても良い。

また、本実施形態では、渋滞判定基準を決定する際に用いる車両の状態として（Ａ）車両の動作モード（ロング動作モード又はミドル動作モード）、（Ｂ）通信の負荷状況、（Ｃ）通信制御ＥＣＵ１４のリソースを挙げているが、他の項目についても考慮する構成としても良い。例えば、ナビゲーションＥＣＵ３３のリソースについても考慮して渋滞判定基準を決定しても良い。

また、本実施形態の走行支援処理プログラム（図６、図８、図９、図１１、図１４）はナビゲーション装置の備えるナビゲーションＥＣＵ３３が実行することとしているが、車両制御ＥＣＵ９が実行するようにしても良い。また、複数のＥＣＵによって処理を分担して行うようにしても良い。

また、本発明はナビゲーション装置以外に、車両制御ＥＣＵ９を介して車両の制御が可能な各種装置に対して適用することが可能である。例えば、ナビゲーション装置以外の車載器、携帯電話機やスマートフォンやＰＤＡ等の携帯端末、パーソナルコンピュータ等（以下、携帯端末等という）に適用することも可能である。また、サーバと携帯端末等から構成されるシステムに対しても適用することが可能となる。その場合には、上述した走行支援処理プログラム（図６、図８、図９、図１１、図１４）の各ステップは、サーバと携帯端末等のいずれが実施する構成としても良い。

１ ナビゲーション装置
２ 車両
３ 車両制御システム
４ エンジン
５ 駆動モータ
７ バッテリ
３３ ナビゲーションＥＣＵ
５１ ＣＰＵ
５２ ＲＡＭ
５３ ＲＯＭ

本発明は、車両において効率の良い走行を行う為の走行計画を作成する走行支援システム、走行支援方法及びコンピュータプログラムに関する。

本発明は前記従来における問題点を解消するためになされたものであり、車両の駆動源の制御スケジュールである走行計画を作成する場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止した走行支援システム、走行支援方法及びコンピュータプログラムを提供することを目的とする。

前記目的を達成するため本願の請求項１に係る走行支援システム（１）は、車両（２）が所定の走行経路を走行する場合に、前記走行経路に対して前記車両の駆動源（４、５）の制御に係る走行計画を作成する走行計画手段（３３）と、前記走行経路の渋滞情報を取得する渋滞情報取得手段（３３）と、前記車両の状態を取得する車両状態取得手段（３３）と、前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定手段（３３）と、前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正手段（３３）と、を有することを特徴とする。

また、請求項３に係る走行支援システム（１）は、請求項２に記載の走行支援システムであって、前記車両は駆動源として駆動モータとエンジンを備え、前記走行計画手段は、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した前記走行計画を作成し、前記車両（２）の状態は、前記走行経路に対して前記走行計画（４８）を作成し、前記駆動モータ（５）と前記エンジン（４）の駆動制御をするロング動作モードと、前記車両の進行方向前方の道路状況に基づいて前記車両の位置から進行方向前方の所定距離以内の範囲に対して前記走行計画を作成し、前記駆動モータと前記エンジンの駆動制御をするミドル動作モードのいずれかであって、前記変化判定手段（３３）は、前記車両の状態が前記ロング動作モードか前記ミドル動作モードかによって異なる基準によりリンク毎の渋滞度を算出し、算出された前記リンク毎の渋滞度を比較して前記走行経路の渋滞状況が変化したか否か判定することを特徴とする。

また、請求項８に係る走行支援方法は、走行計画手段（３３）が、車両（２）が所定の走行経路を走行する場合に、前記走行経路に対して前記車両の駆動源の制御に係る走行計画を作成するステップと、渋滞情報取得手段（３３）が、前記走行経路の渋滞情報を取得するステップと、車両状態取得手段（３３）が、前記車両の状態を取得するステップと、変化判定手段（３３）が、前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定するステップと、走行計画修正手段（３３）が、前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正するステップと、を有することを特徴とする。

更に、請求項９に係るコンピュータプログラムは、コンピュータを、車両（２）が所定の走行経路を走行する場合に、前記走行経路に対して前記車両の駆動源の制御に係る走行計画を作成する走行計画手段と、前記走行経路の渋滞情報を取得する渋滞情報取得手段と、前記車両の状態を取得する車両状態取得手段と、前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定手段と、前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正手段と、して機能させることを特徴とする。

前記構成を有する請求項１に記載の走行支援システムによれば、車両の駆動源の制御スケジュールである走行計画を作成する場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止することが可能となる。その結果、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。

また、請求項８に記載の走行支援方法によれば、車両の駆動源の制御スケジュールである走行計画を作成する場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止することが可能となる。その結果、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。

更に、請求項９に記載のコンピュータプログラムによれば、車両の駆動源の制御スケジュールである走行計画を作成させる場合において、渋滞情報の変化によって走行計画が頻繁に修正されることを防止することが可能となる。その結果、走行計画の修正に係る処理負担や修正された走行計画を車両内で送信する為の通信に係る処理負担を軽減することが可能となる。また、車両の状況に基づいて走行計画を修正する必要がある状況でのみ走行計画の修正を行わせることが可能であり、不要な処理が行われることを防止することが可能となる。

Claims (9)

1. 駆動源として駆動モータとエンジンを備える車両が所定の走行経路を走行する場合に、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した走行計画を作成する走行計画手段と、
   前記走行経路の渋滞情報を取得する渋滞情報取得手段と、
   前記車両の状態を取得する車両状態取得手段と、
   前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定手段と、
   前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正手段と、を有することを特徴とする走行支援システム。
2. 前記車両状態取得手段は、前記車両の状態として前記車両の動作モードを取得し、
   前記変化判定手段は、
   前記車両の動作モードに応じた異なる基準でリンク毎の渋滞度を算出し、
   算出された前記リンク毎の渋滞度を比較して前記走行経路の渋滞状況が変化したか否か判定することを特徴とする請求項１に記載の走行支援システム。
3. 前記車両の状態は、
   前記走行経路に対して前記走行計画を作成し、前記駆動モータと前記エンジンの駆動制御をするロング動作モードと、
   前記車両の進行方向前方の道路状況に基づいて前記車両の位置から進行方向前方の所定距離以内の範囲に対して前記走行計画を作成し、前記駆動モータと前記エンジンの駆動制御をするミドル動作モードのいずれかであって、
   前記変化判定手段は、
   前記車両の状態が前記ロング動作モードか前記ミドル動作モードかによって異なる基準によりリンク毎の渋滞度を算出し、
   算出された前記リンク毎の渋滞度を比較して前記走行経路の渋滞状況が変化したか否か判定することを特徴とする請求項２に記載の走行支援システム。
4. 前記渋滞情報は、前記走行経路の混雑区間及び前記混雑区間よりも渋滞度合いが高い渋滞区間を特定する情報であって、
   前記変化判定手段は、
   前記車両の状態がミドル動作モードである場合に、
   前記走行経路を構成するリンクの少なくとも一部に前記渋滞区間があれば該リンクを渋滞と判定し、
   リンク内に前記渋滞区間が無く、且つリンクの少なくとも一部に前記混雑区間があれば該リンクを混雑と判定し、
   それ以外のリンクを空きと判定し、
   リンク毎の渋滞、混雑、空きの渋滞度の判定結果が変化した場合に、前記走行経路の渋滞状況が変化したと判定することを特徴とする請求項３に記載の走行支援システム。
5. 前記渋滞情報は、前記走行経路の混雑区間及び前記混雑区間よりも渋滞度合いが高い渋滞区間を特定する情報であって、
   前記変化判定手段は、
   前記車両の状態がロング動作モードである場合に、
   前記走行経路を構成するリンクの半分以上が渋滞区間であれば該リンクを渋滞と判定し、
   それ以外のリンクを空きと判定し、
   リンク毎の渋滞、空きの渋滞度の判定結果が変化した場合に、前記走行経路の渋滞状況が変化したと判定することを特徴とする請求項３に記載の走行支援システム。
6. 前記車両の状態は、前記車両内の通信における通信負荷であって、
   前記車両内の通信における通信負荷が高い程、前記変化判定手段の基準を前記走行経路の渋滞状況が変化したと判定され難くなる基準とすることを特徴とする請求項１に記載の走行支援システム。
7. 前記車両の状態は、前記車両内の通信を制御する通信ＥＣＵのリソースであって、
   前記通信ＥＣＵのリソースが少ない程、前記変化判定手段の基準を前記走行経路の渋滞状況が変化したと判定され難くなる基準とすることを特徴とする請求項１に記載の走行支援システム。
8. 駆動源として駆動モータとエンジンを備える車両が所定の走行経路を走行する場合に、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した走行計画を作成する走行計画ステップと、
   前記走行経路の渋滞情報を取得する渋滞情報取得ステップと、
   前記車両の状態を取得する車両状態取得ステップと、
   前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定ステップと、
   前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正ステップと、を有することを特徴とする走行支援方法。
9. コンピュータに、
   駆動源として駆動モータとエンジンを備える車両が所定の走行経路を走行する場合に、前記走行経路に対して前記駆動モータのみを駆動源として走行するＥＶ走行範囲と、前記駆動モータと前記エンジンとを駆動源として併用して走行するＨＶ走行範囲を設定した走行計画を作成する走行計画機能と、
   前記走行経路の渋滞情報を取得する渋滞情報取得機能と、
   前記車両の状態を取得する車両状態取得機能と、
   前記車両の状態に基づく基準で、前記渋滞情報から前記走行経路の渋滞状況が変化したか否か判定する変化判定機能と、
   前記走行経路の渋滞状況が変化したと判定された場合に、該変化後の渋滞状況を用いて、前記走行計画を修正する走行計画修正機能と、
   を実行させることを特徴とするコンピュータプログラム。

Images