JP2017090092A - 車載用ダウンロード制御装置、及びダウンロード制御方法 - Google Patents

Abstract

【課題】車両においてダウンロードに掛かる時間や通信費用を少なくして、ユーザーの負担を抑える。【解決手段】車両の走行経路を取得して、ダウンロードに適さない不適区間と、ダウンロードに適した適応区間とに区分する。更に、データのダウンロードに要する所要時間を取得する。そして、走行経路を区分した結果と、所要時間とに基づいて、走行経路上にダウンロードの開始地点を設定しておき、車両が開始地点に到達したら、データのダウンロードを開始する。このように、ダウンロードの開始地点を適切に設定しておくことで、ダウンロードに適した適応区間を走行している間にダウンロードを完了させることができる。このため、ダウンロードに失敗して再びダウンロードしたり、あるいはダウンロードの中断と再開とを繰り返したりすることを防止することができるので、ダウンロードに掛かる時間や通信費用の点でのユーザーの負担を抑えることが可能となる。【選択図】図６

Description

本発明は、走行中の車両において無線通信を利用してデータを取得するための技術に関する。

今日の車両には様々なソフトウェア（すなわち、各種のプログラムやそのプログラムが参照するデータ）が搭載されており、これらのソフトウェアによって様々な機能が実現されている。そして、ソフトウェアを更新すれば、機能を向上させたり、新たな機能を追加したりすることができる。
また、ソフトウェアの更新は、無線通信を介して必要な更新データをダウンロードすることによって、実行することができる。
もっとも、更新データのサイズが大きくなると、ダウンロードに要する時間が長くなるため、ダウンロードに失敗する可能性が高くなる。そして、ダウンロードに失敗すると、ダウンロードし直さなければならなくなるので、更新に要する時間や通信費用が増加してしまい、ユーザーに負担を強いることになる。
そこで、車の状態（例えば、制動用ブレーキの状態や車速など）に応じて、更新データのダウンロードを中断したり再開したりする技術が提案されている（特許文献１）。

特開２０１２−１０３１８１号公報

しかし、上記の提案されている技術では、依然として、更新に要する時間や通信費用の増加に伴うユーザーの負担を軽減できないという問題があった。
これは、次のような理由による。先ず、提案の技術では、車両の状態に応じてダウンロードの中断と再開とを繰り返す事態が生じ得る。そして、このような事態が生じると、ダウンロードが何度も中断されるためにダウンロードに時間が掛かってしまい、更新に要する時間が増加してしまう。また、ダウンロードを中断する際には、サーバーとの間で通信が発生し、更に、ダウンロードを再開する際にもサーバーとの間で通信が発生するので、この分の通信量が増加してしまう。
このような理由から、提案の技術では、ダウンロードに失敗しない場合であっても、更新に要する時間や通信負担が増加してしまうためである。

この発明は、従来技術が有する上記の課題に対応してなされたものであり、車両においてダウンロードに掛かる時間や通信費用を少なくして、ユーザーの負担を抑えることを可能とする技術の提供を目的とする。

上述した課題を解決するために本発明の車載用ダウンロード装置およびダウンロード制御方法は、車両の走行経路を取得して、その走行経路を、ダウンロードに適さない不適区間と、ダウンロードに適した適応区間とに区分する。更に、データのダウンロードに要する所要時間を取得する。そして、走行経路を区分した結果と、所要時間とに基づいて、走行経路上にダウンロードの開始地点を設定しておき、車両が開始地点に到達したら、データのダウンロードを開始する。
このように、ダウンロードの開始地点を適切に設定しておくことで、ダウンロードに適した適応区間を走行している間にダウンロードを完了させることができる。このため、ダウンロードに失敗して再びダウンロードしたり、あるいはダウンロードの中断と再開とを繰り返したりすることを防止することができるので、ダウンロードに掛かる時間や通信費用の点でのユーザーの負担を抑えることが可能となる。

本実施例によるダウンロード装置１０の大まかな構造を示す説明図である。 ダウンロード装置１０の内部で実行されるダウンロード処理（Ｓ１００）のフローチャートである。 ダウンロード開始地点設定処理（Ｓ２００）のフローチャートである。 各適応区間の長さとダウンロードの所要時間とを比較した様子を示す説明図である。 ダウンロード実行処理（Ｓ３００）のフローチャートである。 ダウンロード処理によって更新データをダウンロードした様子を模式的に示した説明図である。 変形例によるダウンロード開始地点設定処理（Ｓ４００）のフローチャートである。

以下では、上述した本願発明の内容を明確にするために実施例について説明する。
Ａ．本実施例の装置構成 ：
図１には、車両１に搭載されたダウンロード装置１０の大まかな構造が示されている。図１（ａ）に示されるように、車両１は、ダウンロード装置１０に加えて、アンテナ２を備えており、外部と無線通信することが可能である。ダウンロード装置１０は、外部との無線通信を利用して、コンピューター制御に使用される様々なデータをダウンロードする。尚、ダウンロード装置１０は、本発明の「車載用ダウンロード制御装置」に対応する。
また、車両１は、走行経路を案内するためのカーナビゲーションシステム（以下、カーナビと略す）や、音楽を再生するためのオーディオ等といった各種の車載器の機能を統合した車載器３を備えている。すなわち、車載器３は、図１（ｂ）に示されるように、カーナビ機能３１と、オーディオ機能３２と、ウェブページを表示するブラウザ機能３３と、電話機能３４とを備える。

車載器３が備える各種の機能は、それぞれの機能に対応したプログラムに基づいて動作している。これらのプログラムを更新すれば、その機能を向上したり、新たな機能を追加したりすることが可能である。また、プログラムを更新しなくても、プログラムが参照するデータを更新することによって、そのプログラムに対応する機能を向上させることも可能である。例えば、カーナビ機能３１のプログラムが参照する地図データを更新すれば、新たに造設された道路についても経路案内することが可能となる。
車載器３で使用される各種のプログラムやプログラムが参照するデータ（以下、これらのプログラムやデータを総称して「ソフトウェア」と呼ぶ）を更新する際には、更新のためのデータ（以下、「更新データ」と呼ぶ）が必要となる。本実施例では、外部のサーバー４から更新データをダウンロードするために、ダウンロード装置１０を使用する。

ダウンロード装置１０は、図１（ｂ）に示されるように、通信部１１と、更新情報取得部１２と、走行経路取得部１３と、走行経路区分部１４と、開始地点設定部１５と、ダウンロード実行部１６と、記憶部１７とを備える。
尚、これらの「部」は、ダウンロード装置１０の内部を機能の観点から分類した概念であり、ダウンロード装置１０が物理的に区分されることを表すものではない。従って、これらの「部」は、ＣＰＵで実行されるコンピュータープログラムとして実現することもできるし、ＬＳＩやメモリーやタイマーを含む電子回路として実現することもできるし、これらを組み合わせることによって実現することもできる。

通信部１１は、アンテナ２に接続されており、サーバー４との間で無線通信を行う。この無線通信の態様は、アンテナ２からサーバー４に直接接続して通信する態様としてもよいし、車両１の乗員が有する携帯端末５に接続し、携帯端末５を介してサーバー４に接続して通信する態様としてもよい。
このように、通信部１１は、サーバー４と直接に通信することもできるし、携帯端末５など他の通信機器を介して通信することもできる。また、携帯端末５などの通信機器は、複数の通信規格に対応していることが一般的である。従って、通信部１１は、通信機器や通信規格を選択する機能を有する。選択の仕方は、車両１の乗員の設定に任せてもよいし、所定の条件に従って自動的に選択するようにしてもよい。尚、本実施例では、車両１に備わるアンテナ２を利用して無線通信するが、これに限られず、ダウンロード装置１０がアンテナを内蔵し、そのアンテナを利用して無線通信するようにしてもよい。

更新情報取得部１２は、車載器３が利用するソフトウェア（すなわち、プログラムまたはプログラムが参照するデータ）について、新たな更新を知らせる更新情報を取得する。更新情報は、車載器３の製造業者等がサーバー４から発信しており、通信部１１がサーバー４と無線通信することで取得できる。取得した更新情報に基づけば、車載器３のソフトウェアに未だ適用されていない更新データが存在するか否かを確認することができる。また、更新情報に基づいて、更新データのデータサイズなどの情報を取得することもできる。

また、更新情報取得部１２は、サーバー４から更新データをダウンロードするのに掛かると見込まれる所要時間についても取得する。この所要時間は、更新データのサイズを、通信速度（単位時間当たりに転送可能なデータのサイズ）で除算することで取得することができる。更新データのサイズは、上述した通りサーバー４から取得できる。一方、通信速度については、各種の通信規格に応じた速度となるため、通信部１１が何れの通信機器や通信規格を選択してサーバー４と無線通信しているのかを示す情報を通信部１１から取得すればよい。
尚、更新データのダウンロードに必要な所要時間を取得することから、更新情報取得部１２が、本発明の「所要時間取得部」に対応する。

走行経路取得部１３は、車載器３のソフトウェアに未だ適用されていない更新データが存在することを更新情報取得部１２が確認した場合に、車両１の走行経路を取得する。車載器３のカーナビ機能３１は、運転者が設定した目的地までの走行経路を決定することができるため、カーナビ機能３１を用いて車両１の走行経路を取得すればよい。もっとも、車両１の走行経路は、必ずしも車載器３のカーナビ機能３１を用いて取得する必要はなく、たとえば運転者が携帯端末５の経路案内機能を使用している場合には、携帯端末５と通信することによって走行経路を取得してもよい。

走行経路区分部１４は、走行経路取得部１３が取得した走行経路を、ダウンロードに適した区間（以下、「適応区間」と呼ぶ）と、ダウンロードに適さない区間（以下、「不適区間」と呼ぶ）とに区分する。ここで、「ダウンロードに適する」とは、ダウンロードの最中に無線通信の通信状態が悪化してダウンロードを中断する虞がない（あるいは、考慮する必要がないほどに小さい）ことを指す。また、「ダウンロードに適さない」とは、ダウンロードの最中に無線通信の通信状態が悪化してダウンロードが中断する虞がある（あるいは、無視できない程度の可能性がある）ことを指す。

適応区間または不適区間の何れであるかは、走行経路が通過する地点の属性に基づいて判断することができる。すなわち、走行経路が「トンネル」という属性の地点を通過する場合、トンネル内では無線通信の電波が届き難いと考えられるので、不適区間と判断できる。また、ビル街では無線通信の電波がビルに遮蔽されて、無線通信が中断されることがあるから、走行経路が「ビル街」という属性の地点を通過する場合も、不適区間と判断することができる。以下、「トンネル」や「ビル街」などといったダウンロードに適さない地点の属性を「不適属性」と称する。
これに対して、走行経路が「住宅街」や「郊外」などの属性が付された地点を通過する場合、電波を遮蔽する物が存在しないので、適応区間と考えて良い。以下、「住宅街」や「郊外」などといったダウンロードに適した地点の属性を「適応属性」と称する。
このような、不適属性であるか適応属性であるかを示す情報を、予め地図データの各地点に付与しておけば、走行経路が通過する地点に付与されている属性を読み出すことによって、走行経路を適応区間と不適区間とに区分することが可能となる。

また、地図上の各地点における無線通信の通信状態を予め調べておき、これを考慮して、不適属性であるか適応属性であるかを示す情報を付与するようにしてもよい。例えば、トンネル内に無線通信の基地局が設置されて、無線通信の電波を安定して送受信できる場合には、トンネルを通過する区間であっても適応属性を付与することができる。あるいは、無線通信の基地局が設置されていない場合には、郊外などのように電波を遮蔽する物が存在しない区間であっても、不適属性を付与することができる。もちろん、通信状態を調べるのではなく、無線通信の基地局の設置場所を調べて、設置場所から所定範囲内では適応属性を付与することとしても良い。あるいは、車両１が走行する度に各地点の通信状態を記録しておき、後で同じ道路を走行する場合には、その記録を参照して、適用属性または不適属性の何れかを付与することとしてもよい。

開始地点設定部１５は、更新情報取得部１２が取得したダウンロードの所要時間と、走行経路区分部１４が走行経路を区分した結果とに基づいて、走行経路において更新データのダウンロードを開始する開始地点を設定する。開始地点の設定の仕方については後で詳述する。
ダウンロード実行部１６は、開始地点設定部１５によって設定されたダウンロードの開始地点に車両１が到達すると、通信部１１を通じてサーバー４と無線通信して、更新データのダウンロードを開始する。尚、ダウンロード実行部１６は、本発明の「ダウンロード開始部」に対応する。
記憶部１７は、ダウンロード実行部１６がダウンロードした更新データを、一時的にメモリーに記憶しておく。
以上のようにして、ダウンロード装置１０が更新データのダウンロードを完了すると、車載器３は、記憶部１７に記憶された更新データを読み出すことによって、ソフトウェアを更新することが可能となる。

Ｂ．ダウンロード処理 ：
図２には、ダウンロード装置１０が実行するダウンロード処理（Ｓ１００）のフローチャートが示されている。このダウンロード処理（Ｓ１００）は、車両１のエンジンキーがＯＮにされると開始されて、エンジンキーがＯＦＦにされるまで一定周期で繰り返して実行される処理である。ダウンロード処理（Ｓ１００）を開始すると、先ず始めに、カーナビ機能３１が車両１の経路案内を開始したか否かを判断する（Ｓ１０１）。運転者がカーナビ機能３１を操作していない場合や、操作しても目的地を設定していない場合には、カーナビ機能３１が経路案内を開始することも無いため（Ｓ１０１：ｎｏ）、処理を終了する。
一方、運転者がカーナビ機能３１を操作して目的地を設定した場合、カーナビ機能３１は目的地までの走行経路の候補を運転者に提示する。これに対して、運転者が走行経路を選択すれば、カーナビ機能３１が経路案内を開始することになる（Ｓ１０１：ｙｅｓ）。

カーナビ機能３１が経路案内を開始したら（Ｓ１０１：ｙｅｓ）、続いて、新たな更新データが存在するか否かを判断する（Ｓ１０２）。ここで、新たな更新データとは、車載器３に搭載されたソフトウェアに未だ適用されていない更新データである。新たな更新データが存在するか否かは、サーバー４から送信される更新情報に基づいて判断することができる。その結果、新たな更新データが存在していなければ（Ｓ１０２：ｎｏ）、ダウンロードする対象が無いので、処理を終了する。そして、ダウンロード処理（Ｓ１００）を実行する一定周期の時間が経過したら、再びダウンロード処理が起動されて、先頭のＳ１０１から処理が開始される。
一方、更新データが存在している場合には（Ｓ１０２：ｙｅｓ）、ダウンロード開始地点設定処理（Ｓ２００）を行うことによってダウンロードの開始地点を設定し、その設定結果に基づいて、ダウンロード実行処理（Ｓ３００）を開始する。

Ｃ．ダウンロード開始地点設定処理 ：
図３には、ダウンロード開始地点設定処理（Ｓ２００）のフローチャートが示されている。ダウンロード開始地点設定処理（Ｓ２００）では、先ず、更新データのサイズを取得する（Ｓ２０１）。更新データのサイズは、サーバー４から発信されている更新情報に基づいて取得できる。
続いて、ダウンロード装置１０とサーバー４との間の通信速度を取得して（Ｓ２０２）、更新データのダウンロードに要する所要時間を取得する（Ｓ２０３）。上述したように、ダウンロードの所要時間は、更新データのサイズと通信速度とに基づいて取得することができる。
次に、車載器３のカーナビ機能３１を用いて車両１の走行経路を取得する（Ｓ２０４）。図２を用いて前述したように、ダウンロード開始地点設定処理（Ｓ２００）は、車両１の運転者がカーナビ機能３１を用いて経路案内を開始した場合（図２のＳ１０１：ｙｅｓ）に開始される処理であるから、車両１の走行経路は直ちに取得することができる。

車両１の走行経路を取得したら（Ｓ２０４）、その走行経路を適応区間と不適区間とに区分する（Ｓ２０５）。前述したように、適応区間であるか不適区間であるかの区分は、走行経路が通過する地点に付された属性を地図データから読み出すことによって判断する。
そして、走行経路を適応区間と不適区間とに区分したら（Ｓ２０４）、各適応区間の予想走行時間を取得する（Ｓ２０５）。ここで、予想走行時間とは、連続して存在する１つの適応区間を車両１が通過するために要すると予想される時間のことをいう。この予想走行時間を取得するのは、次のような理由による。

先ず、上記のＳ２０４の処理によって、走行経路上でダウンロードに適した適応区間を把握することができ、車両１がその適応区間を走行している間であれば、無線通信の電波状況が悪化することなく、ダウンロードを実行することができる。ただし、ダウンロードの所要時間に対して、適応区間の長さが不足していると、その適応区間の後に続く不適区間に入ってからもダウンロードを継続することになる。不適区間に入ったら、無線通信の電波状況が悪化してダウンロードが中断してしまう虞がある。このような事態を回避するには、予め、ダウンロードの所要時間に対して十分な長さの適応区間を検出しておき、その適応区間を走行している最中にダウンロードを完了させればよい。
ここで、ダウンロードの所要時間に対して十分な長さの適応区間を検出するには、ダウンロードの所要時間と、適応区間の長さとを比較すればよいが、これらは時間または距離で表されており尺度が異なるため、そのままでは比較することができない。そこで、本実施例では、適応区間の長さを時間の尺度で表し直すために、上記の予想走行時間を取得している。

図４には、各適応区間の長さとダウンロードの所要時間とを比較した様子が例示されている。図示された例では、車両１の走行経路の途中にトンネルとビル街とが存在しており、トンネルを通過する区間と、ビル街を通過する区間とをそれぞれ不適区間としている。その結果、これらの不適区間以外の区間（図示した例では、適応区間Ａ、適応区間Ｂ、適応区間Ｃ）が適応区間となる。
これら各適応区間の予想走行時間は、各適応区間の距離と、車両１の走行速度とによって決まる。各適応区間の距離は、地図データに基づいて容易に取得することができる。また、車両１の走行速度については、最も単純には、道路の制限速度で走行速度を代用することができる。もっとも、信号や踏切で停車すると制限速度を維持できなくなる。そこで、走行経路上に存在する信号や踏切を検出して、信号や踏切の数が多くなるほど制限速度よりも少なめに走行速度を見積もることとしてもよい。また、走行経路上に渋滞が存在する場合にも、制限速度を維持できなくなる。そこで、走行経路上の交通情報を取得して、走行経路上に渋滞が存在する場合には、渋滞の数、あるいは渋滞の長さなどに応じて、制限速度よりも少なめに走行速度を見積もることとしてもよい。
もちろん、車両１の走行速度に影響を及ぼす事情は、これらに限られるわけではない。例えば、住宅街や商店街を走行する場合には、運転が慎重になるので一時停止することが多くなると考えられる。そこで、走行経路が通過する周囲の状況を地図データから読み出して、走行経路が住宅街あるいは商店街を通過する場合には、制限速度よりも少なめに走行速度を見積もることとしてもよい。

また、カーナビ機能３１はこうした車両１の走行速度に影響を及ぼす様々な事情を考慮して、目的地への到着時刻を予想しているため、その到着時刻に関する情報をカーナビ機能３１から取得すれば、次のようにして、各適応区間の予想走行時間を容易に取得することができる。先ず、カーナビ機能３１は、車両１の走行経路を交差点などの箇所で区切ってリンクと呼ばれる区間に分解し、各リンクを通過するのに要する時間を推定してから、これらを合計して到着時刻を予想している。そこで、本実施例で走行経路を区分して得られた各適応区間について、それぞれの適応区間に含まれる分のリンクを選択し、選択した各リンクを通過するのに要する時間を合計すれば、その適応区間についての予想走行時間を取得することができる。

このようにして予想走行時間を取得した結果、図４に示されるように、適応区間Ａについては予想走行時間ａを取得し、適応区間Ｂについては予想走行時間ｂを取得し、適応区間Ｂについては予想走行時間ｃを取得したとする。これら各適応区間の予想走行時間と、前述の処理（図３のＳ２０２）で取得したダウンロードの所要時間とを比較すれば、各適応区間がダウンロードの所要時間に対して十分な長さであるか確認することができる。
図示された例では、ダウンロードの所要時間を「ｔ」として、それぞれの予想走行時間と比較すると、予想走行時間ａはダウンロードの所要時間ｔよりも短く、適応区間Ａはダウンロードを実行するための十分な長さを有していないことが確認できる。同じく、予想走行時間ｂはダウンロードの所要時間ｔよりも短いため、適応区間Ｂも十分な長さを有していないことが確認できる。
一方、予想走行時間ｃはダウンロードの所要時間ｔよりも長いため、適応区間Ｃについては、ダウンロードを実行するのに十分な長さを有していることが確認できる。

以上のようにして各適応区間の長さを確認すると、別の場面では何れの適応区間も十分な長さを有していないことも考えられる。そこで、図３のダウンロード開始地点設定処理では、十分な長さの適応区間が存在するか否かを判断する（Ｓ２０７）。その結果、十分な長さの適応区間が存在しない場合には（Ｓ２０７：ｎｏ）、ダウンロードが中断される虞があるため、処理を終了する。この場合、更新データをダウンロードしないことになるが、次回以降のダウンロード処理（Ｓ１００）で条件を満たした時にダウンロードを実行すればよい。

一方、図３のＳ２０７の処理で、ダウンロードの所要時間に対して十分な長さの適応区間が存在する場合には（Ｓ２０７：ｙｅｓ）、予想走行時間がダウンロードの所要時間よりも長い適応区間をダウンロード区間として設定する（Ｓ２０８）。ここで、ダウンロード区間とは、走行経路のうち、更新データのダウンロードを実行すると定めた区間をいう。十分な長さの適応区間が複数存在する場合には、予想走行時間が最も長い適応区間をダウンロード区間として設定すれば、時間に余裕をもってダウンロードを実行することができる。あるいは、できるだけ早く更新データをダウンロードしたい場合は、走行経路の中で手前に位置する適応区間をダウンロード区間として設定してもよい。

そして、ダウンロード区間を設定したら（Ｓ２０８）、そのダウンロード区間の中で、車両１が最初に通過する地点をダウンロードの開始地点として設定する（Ｓ２０９）。尚、ダウンロード区間内でダウンロードの所要時間を確保できるのであれば、ダウンロード区間の途中にダウンロードの開始地点を設定することも可能である。
以上のようにしてダウンロードの開始地点を設定すると（Ｓ２０９）、ダウンロード開始地点設定処理（Ｓ２００）を終了して、図２のダウンロード処理に戻った後、今度は、ダウンロード実行処理（Ｓ３００）を開始する。

Ｄ．ダウンロード実行処理 ：
図５には、ダウンロード実行処理（Ｓ３００）のフローチャートが示されている。ダウンロード実行処理（Ｓ３００）では、先ず、車両１の現在位置を取得する（Ｓ３０１）。カーナビ機能３１は、経路案内のために車両１の現在位置を把握しているため、その現在位置を示す情報を取得すればよい。
車両１の現在位置を取得したら（Ｓ３０１）、車両１がダウンロード開始地点に到達したか否かを判断する（Ｓ３０２）。このダウンロード開始地点は、上記のダウンロード開始地点設定処理（図３のＳ２００）を実行したことによって、走行経路中の何れかの地点に設定されている。車両１は走行経路を進むため、Ｓ３０２の判断を繰り返し続けていれば、やがて車両１の現在位置とダウンロード開始地点とが一致することになる（Ｓ３０２：ｙｅｓ）。

車両１がダウンロード開始地点に到達する前は（Ｓ３０２：ｎｏ）、この判断を繰り返し続けるが、再度判断する前に一定時間待機する（Ｓ３０３）。Ｓ３０２の判断は、車両１がダウンロード区間に入ったことを知るための処理であり、車両１がダウンロード開始地点に到達した瞬間を厳密に把握する必要はない。そこで、一定時間毎に判断することで、処理負担の軽減を図ることができる。
そして、車両１がダウンロード開始地点に到達したと判断されたら（Ｓ３０２：ｙｅｓ）、更新データをダウンロードする（Ｓ３０４）。その後は、図２のダウンロード処理に戻って、処理を終了する。

図６には、本実施例のダウンロード処理によって更新データをダウンロードした様子が模式的に示されている。本実施例のダウンロード処理の効果を説明するために、先ず、従来の方法でダウンロードした場合について、図６（ａ）を参照しながら説明する。
本実施例のダウンロード処理によらなければ、新たな更新データが存在すると判ったら、そのままダウンロードを開始することになる。図中では、このダウンロードを開始した地点をＰ地点として示している。その後、ダウンロードを実行している最中に車両１がトンネル内に入ったら、無線通信の電波を受信することができなくなり、ダウンロードは途中で中断してしまう。このようにダウンロードが強制的に中断されると、既にダウンロードした分のデータが全部無駄になってしまう虞がある。また、後で続きからダウンロードできる場合であっても、中断の直前にダウンロードした分のデータについては正常に保存することができずに無駄になってしまう。

その後、車両１がトンネルを抜ければ、無線通信の電波を受信できるようになり、ダウンロードを再開するが、車両１がビル街に入った時に、再び電波を受信できなくなり、ダウンロードが中断する。ビル街の中では、ビル同士の隙間で電波を受信できることもあるが、そのような電波状態は長くは続かず、ダウンロードを再開しても直ぐに中断することになる。
そして、車両１がビル街を抜けて電波を安定して受信できるようになってから、ダウンロードを完了することができる。図中にはそのダウンロードを完了した地点をＱ地点として示している。尚、ここでは、ダウンロードを中断した場合、ダウンロードを再開する際には、既にダウンロードしたデータは記憶されていて、そのデータの続きからダウンロードを再開すればよいものとして説明した。しかし、ダウンロードが中断するとそれまでのデータが破棄されてしまい、最初からダウンロードし直さなければならない場合も存在する。このような場合には、ダウンロードの完了地点は、上述したＱ地点よりも更に後の地点となる。

このように、従来では、ダウンロードの中断と再開とを繰り返して、ダウンロードを開始してから完了するまでに長い時間を要することがあった。
また、ダウンロードの中断と再開とを繰り返すと、無駄な通信量が増えて、通信費の増大を招くことにもなる。ダウンロードを再開する際には、再開の設定のために別の通信をする必要が生じるため、このことも通信費の増大の原因となる。
更には、電波状態が悪いときにダウンロードを実行するとデータが欠損することがあるが、そのままダウンロードを完了してしまうことも生じ得る。この場合、後で更新データをインストールするときになってから、そうしたデータの欠損が判明することになり、事後的にダウンロードをやり直すことになるため、更に時間が掛かり、また、余計な通信費が増えることになる。

これに対して、本実施例のダウンロード処理では、無線通信の電波状態が良好で十分な長さの区間を予め確保してからダウンロードを実行するため、図６（ｂ）に示されるように、中断されることなくダウンロードを完了することができる。ダウンロードが中断されることが無ければ、通信費の無駄が生じることも無くなり、ユーザーの負担を抑えることができる。

また、図６（ａ）に示した従来の場合では、ダウンロードを開始してから完了するまでの区間がＰ地点からＱ地点までと非常に長かったことに対して、図６（ｂ）に示した本実施例の場合では、Ｒ地点からＳ地点までと従来に比べて大幅に短くなっている。このことは、ダウンロードを実行している時間が短いということでもあり、次のような効果を得られる。
先ず、本実施例のダウンロード装置１０を実装するに際しては、ＣＰＵやメモリーなどのハードウェアリソースを車載器３と共有することが考えられる。この場合、ダウンロード装置１０がダウンロードを実行している最中は、車載器３で使用可能なハードウェアリソースが減るため、カーナビ機能３１やオーディオ機能３２などの動作が遅くなる等の影響を及ぼして、ユーザーの負担を招く可能性もある。この点、本実施例によって、ダウンロードを実行している時間を短くすることで、車載器３の動作に影響を与える時間を短くし、ユーザーの負担を小さくすることができる。

尚、上記の説明では、ダウンロードの所要時間に対して十分な長さの適応区間を検出するために、各適応区間の予想走行時間を取得して（図３のＳ２０６）、ダウンロードの所要時間と、各適応区間の長さとを比較していた（図４）。しかし、これに限られず、ダウンロードの所要時間を距離の尺度で表し直して、各適応区間の長さと比較するようにしてもよい。ダウンロードの所要時間を距離の尺度で表し直すには、各適応区間における車両１の走行速度を推定し、その走行速度でダウンロードの所要時間に亘って走行した場合の走行距離を算出すればよい。この走行距離よりも、連続して存在する距離が長い適応区間であれば、ダウンロードの所要時間に対して十分な長さの適応区間であることが分かる。
車両１の走行速度については、車両１は道路上の制限速度で走行するとみなして推定することができる。この際、信号や踏切で停止することを考慮して、信号や踏切の数が多いほど制限速度よりも下方に補正するとよい。また、過去の走行データに基づいて車両１の走行速度を推定してもよいし、あるいは、渋滞情報が取得できる場合には、その情報に基づいて、車両１の走行速度を推定してもよい。

Ｅ．変形例 ：
上述した実施例では、ダウンロードの所要時間に対して十分な長さの適応区間が存在しない場合には（図３のＳ２０７：ｎｏ）、更新データのダウンロードを実行することなく、条件の良い別の機会を待つことにしていた。
しかし、更新データの内容によっては、緊急にダウンロードすることが必要な状況も考えられる。この変形例では、そうした緊急度を表す情報が更新データに付加されている場合について説明する。尚、この変形例は、図３を示して説明したダウンロード開始地点設定処理（Ｓ２００）の変形例である。従って、上述の実施例と共通する点については上述の説明を援用し、この変形例では異なる点に焦点を当てて説明する。

図７には、変形例によるダウンロード開始地点設定処理（Ｓ４００）のフローチャートが示されている。このダウンロード開始地点設定処理（Ｓ４００）において、ダウンロードの所要時間に対して十分な長さの適応区間が存在する場合は、前述のダウンロード開始地点設定処理（図３のＳ２００）と同様の処理を実行する。
すなわち、先ず、更新データのサイズと、通信速度とを取得して（Ｓ４０１，Ｓ４０２）、これらの情報に基づいて、更新データのダウンロードに要する所要時間を取得する（Ｓ４０３）。
次に、カーナビ機能３１から車両１の走行経路を取得して（Ｓ４０４）、その走行経路を適応区間と不適区間とに区分する（Ｓ４０５）。そして、各適応区間の予想走行時間を取得して（Ｓ４０６）、所要時間に対して十分な長さの適応区間が存在するか否かを判断する（Ｓ４０７）。
その結果、十分な長さの適応区間が存在する場合には（Ｓ４０７：ｙｅｓ）、その適応区間をダウンロード区間として設定し（Ｓ４０８）、ダウンロード区間の中で、車両１が最初に通過する地点をダウンロードの開始地点として設定する（Ｓ４０９）。

これに対して、Ｓ４０７の処理で十分な長さの適応区間が存在しない場合には（Ｓ４０７：ｎｏ）、以下の処理を実行する。
先ず始めに、更新データの緊急度を取得する（Ｓ４１０）。上述の実施例で説明したように、新たな更新を知らせる更新情報がサーバー４から発信されており、この更新情報には更新データのサイズが含まれていた。この変形例では、この更新情報に、更新データの緊急度を示す情報が付加されており、その緊急度は「高」、「中」、「低」の三段階の値のうち何れかの値に設定されている。そこで、更新データの緊急度を取得したら（Ｓ４１０）、取得した緊急度が「高」か否かを判断する（Ｓ４１１）。
尚、緊急度の取得と、緊急度の値の判断は、ダウンロード装置１０が備える更新情報取得部１２（図１参照）が実行する。

取得した緊急度が「高」か否かを判断した結果（Ｓ４１１）、緊急度が「高」である場合には（Ｓ４１１：ｙｅｓ）、ダウンロード区間を設定する（Ｓ４０８）。もっとも、先のＳ４０７の処理で、ダウンロードの所要時間に対して十分な長さの適応区間が存在しないことを条件として（Ｓ４０７：ｎｏ）、Ｓ４１０以降の処理を実行している。従って、Ｓ４１１で「ｙｅｓ」と判断した後に実行するＳ４０８の処理では、十分な長さの適応区間をダウンロード区間として設定できるわけではない。従って、ここでは、Ｓ４０６の処理で予想走行時間を取得した適応区間のうち、予想走行時間が最も長い適応区間をダウンロード区間として設定する。

この場合、車両１が適応区間を走行している最中にダウンロードを完了できないまま、車両１が不適区間に入る可能性があるが、不適区間に入ったからといって直ぐに無線通信の電波が受信できなくなるとは限らない。また、不適区間で無線通信の電波が受信できなくなってダウンロードが中断したとしても、その後、既にダウンロードが済んだ分のデータの続きからダウンロードを再開することで、できる限り早期にダウンロードを完了するようにすることが可能となる。更新データの緊急度が「高」である場合には（Ｓ４１１：ｙｅｓ）、このような考え方に基づいてダウンロードが中断されるリスクを許容し、更新データの迅速なダウンロードを重視して、ダウンロード区間を設定する（Ｓ４０８）。そして、設定したダウンロード区間の中で、車両１が最初に通過する地点をダウンロードの開始地点として設定する（Ｓ４０９）。その後は、前述の実施例と同様に、図２のダウンロード処理に戻った後、ダウンロード実行処理（図５のＳ３００）を実行すればよい。

図７のＳ４１１の判断で、緊急度が「高」でない場合には（Ｓ４１１：ｎｏ）、続いて、緊急度は「中」か否かを判断する（Ｓ４１２）。この判断の結果、緊急度が「中」でないと判断した場合には（Ｓ４１２：ｎｏ）、緊急度が「高」、「中」、「低」の三段階の値のうち、「高」でも「中」でもないことから、緊急度は「低」ということになる。緊急度が低い場合には、ダウンロードが中断される可能性が有る場合にまでダウンロードを実行する必要は無いので、前述の実施例と同様に、更新データのダウンロードを実行することなく処理を終了する。

一方、Ｓ４１２の処理で緊急度が「中」であると判断した場合には（Ｓ４１２：ｙｅｓ）、未実施カウントを「＋１」だけカウントする（Ｓ４１３）。未実施カウントとは、緊急度が「中」の更新データについて、ダウンロードを実行しなかった回数を数えた情報のことをいう。
続いて、未実施カウントが所定回数になったかを判断する（Ｓ４１４）。未実施カウントが所定回数になっていない間は（Ｓ４１４：ｎｏ）、緊急度が「低」である場合と同様に、更新データのダウンロードを実行することなく処理を終了する。
尚、未実施カウントをカウントする処理と、所定回数に達したか否かの判断は、ダウンロード装置１０が備える更新情報取得部１２（図１参照）が実行する。

Ｓ４１４の判断で、未実施カウントが所定回数に達した場合には（Ｓ４１４：ｙｅｓ）、緊急度が「高」である場合と同様に、十分な長さの適応区間を確保できなくてもダウンロード区間を設定する（Ｓ４０８）。こうすれば、緊急度が「中」の更新データについては、ダウンロードが中断される可能性が有る場合には出来る限りダウンロードの実行をしないようにしつつ、ダウンロードを実行していない期間が長期化する事態を避けることができる。このことから、未実施カウントの所定回数は、ダウンロードを実行していない期間をどれだけ許容できるかということに基づいて定めればよい。

以上説明したように、この変形例によると、前述の実施例と同様にダウンロードが中断されないようにしながらも、緊急の場合には、ダウンロードが中断されるリスクを許容して、更新データを迅速にダウンロードすることが可能となる。
上記の説明では、緊急度を「高」、「中」、「低」の三段階の値で設定していたが、何れかの値を無くして、緊急度を二段階の値で設定してもよい。例えば、緊急度が「中」の設定を無くせば、上記の未実施カウント（図７のＳ４１３参照）を扱う必要は無くなる。
一方、緊急度が「中」に相当する設定を更に二段階以上に分けることで、全体として四段階以上の緊急度を設定することもできる。この場合、緊急度が「中」に相当する複数の設定については、未実施カウントの所定回数（Ｓ４１４参照）を互い異なる回数とすればよい。

また、上記の説明では、緊急度が「高」の場合について（Ｓ４１１：ｙｅｓ）、ダウンロードの所要時間に対して十分な長さの適応区間が存在しなくても、予想走行時間が最も長い適応区間をダウンロード区間として設定するようにしていた。しかし、ダウンロード区間は、必ずしも１つの適応区間に設定する必要はなく、複数の適応区間に分割して設定するようにしてもよい。こうすれば、ダウンロードの実行中に車両１が不適区間に入って、ダウンロードが強制的に中断されるということが無くなる。ダウンロード区間を分割して設定した場合も、１つの適応区間を走行し終わる際にダウンロードが完了していなければ、ダウンロードを中断することにはなるが、強制的に中断されるのではないため、ダウンロードした分のデータについては正常に保存することができる。
ここで、ダウンロード区間を分割して設定する場合には、ダウンロード区間として設定するそれぞれの適応区間を、予想走行時間が長い適応区間から選ぶとよい。こうすれば、ダウンロードの中断回数が少なくなり、ダウンロードを再開するときに生じる再開の設定のため通信量を抑えることができる。

以上、本発明の実施例について説明したが、本発明は上記の実施例に限られるものではなく、その要旨を逸脱しない範囲において更に種々の態様で実施することができる。
例えば、上記の実施例では、車載器３に搭載されるソフトウェアの更新データをダウンロードすることについて説明したが、これに限られず、その他の内容のデータであっても何ら変わるところなく本発明を実施してダウンロードすることができる。

１…車両、 ２…アンテナ、 ３…車載器、
１０…ダウンロード装置、 １１…通信部、 １２…更新情報取得部、
１３…走行経路取得部、 １４…走行経路区分部、 １５…開始地点設定部、
１６…ダウンロード実行部、 １７…記憶部、 ３１…カーナビ機能、
３２…オーディオ機能、 ３３…ブラウザ機能、 ３４…電話機能。

Claims (8)

1. 現在位置を取得する機能と、設定された目的地までの走行経路を取得する機能とを備えた車両（１）に搭載されて、該車両の外部からデータをダウンロードする動作を制御する車載用ダウンロード制御装置（１０）であって、
   前記車両の走行経路を取得する走行経路取得部（１３）と、
   前記走行経路が通過する地点の属性に基づいて、該走行経路を、ダウンロードに適さない不適区間と、ダウンロードに適した適応区間とに区分する走行経路区分部（１４）と、
   前記データのダウンロードに要する所要時間を取得する所要時間取得部（１２）と、
   前記走行経路を区分した結果と、前記所要時間とに基づいて、前記走行経路上に前記データのダウンロードの開始地点を設定する開始地点設定部（１５）と、
   前記車両が前記開始地点に到達したことを検出して、前記データのダウンロードを開始するダウンロード開始部（１６）と
   を備える車載用ダウンロード制御装置。
2. 請求項１に記載の車載用ダウンロード制御装置であって、
   前記走行経路取得部は、前記走行経路と、該走行経路が通過する地点の属性とを取得しており、
   前記走行経路区分部は、ダウンロードに適さない不適属性あるいはダウンロードに適する適応属性の少なくとも一方を予め記憶しており、前記走行経路が通過する地点の属性が前記不適属性または前記適応属性の何れに該当するか否かに基づいて、前記走行経路を前記不適区間と前記適応区間とに区分する
   ことを特徴とする車載用ダウンロード制御装置。
3. 請求項１または請求項２に記載の車載用ダウンロード制御装置であって、
   前記所要時間取得部は、前記データのデータサイズを取得して、該データサイズと該データをダウンロードする際の通信速度とに基づいて、前記所要時間を算出する
   ことを特徴とする車載用ダウンロード制御装置。
4. 請求項１ないし請求項３の何れか一項に記載の車載用ダウンロード制御装置であって、
   前記開始地点設定部は、単独の前記適応区間内で前記ダウンロードを完了させることが可能な長さを有する前記適応区間を、前記ダウンロードの所要時間に基づいて検出し、該適応区間内に前記ダウンロードの前記開始地点を設定する
   ことを特徴とする車載用ダウンロード制御装置。
5. 請求項４に記載の車載用ダウンロード制御装置であって、
   前記開始地点設定部は、道路上の制限速度に基づいて推定された前記車両の走行速度で、前記ダウンロードの所要時間に亘って走行した時の走行距離を取得し、単独の長さが該走行距離よりも長い前記適応区間を検出して、該適応区間内で前記ダウンロードが完了するように、該ダウンロードの前記開始地点を設定する
   ことを特徴とする車載用ダウンロード制御装置。
6. 請求項４に記載の車載用ダウンロード制御装置であって、
   前記開始地点設定部は、単独の前記適応区間を前記車両が通過するために要すると予想される走行時間が、前記ダウンロードの所要時間よりも長い前記適応区間を検出して、該適応区間内で前記ダウンロードが完了するように、該ダウンロードの前記開始地点を設定する
   ことを特徴とする車載用ダウンロード制御装置。
7. 請求項４ないし請求項６の何れか一項に記載の車載用ダウンロード制御装置であって、
   前記所要時間取得部は、前記ダウンロードの所要時間と、該ダウンロードの緊急度を取得しており、
   前記開始地点設定部は、前記ダウンロードの緊急度が所定値以上の場合には、単独の前記適応区間内で前記ダウンロードを完了させることが可能な前記適応区間を検出できない場合でも、前記走行経路中に存在する適応区間内に前記ダウンロードの前記開始地点を設定する
   ことを特徴とする車載用ダウンロード制御装置。
8. 現在位置を取得する機能と、設定された目的地までの走行経路を取得する機能とを備えた車両に適用されて、該車両の外部からデータをダウンロードする動作を制御するダウンロード制御方法であって、
   前記車両の走行経路を取得する工程（Ｓ２０４）と、
   前記走行経路が通過する地点の属性に基づいて、該走行経路を、ダウンロードに適さない不適区間と、ダウンロードに適した適応区間とに区分する工程（Ｓ２０５）と、
   前記データのダウンロードに要する所要時間を取得する工程（Ｓ２０３）と、
   前記走行経路を区分した結果と、前記所要時間とに基づいて、前記走行経路上に前記データのダウンロードの開始地点を設定する工程（Ｓ２０９）と、
   前記車両が前記開始地点に到達したことを検出して、前記データのダウンロードを開始する工程（Ｓ３０４）と
   を備えるダウンロード制御方法。

Images