JP7378633B2 - 地図データ更新装置及び地図データ更新方法 - Google Patents

Description

本開示は、地図データ更新装置及び地図データ更新方法に関する。

ナビゲーション装置等の車載端末では、地図上の道路のデータなどを含む地図データベース（以下、データベースを「ＤＢ」と略記することもある）が用いられる。現実世界の最新の道路状態を車載端末の地図ＤＢに反映するために、地図ＤＢ配信サーバが最新の地図ＤＢを車載端末に配信（送信）し、車載端末が地図ＤＢ配信サーバからの地図ＤＢに基づいて地図ＤＢを更新する技術が様々に提案されている。この技術では、地図ＤＢ配信サーバの地図ＤＢが定期的または非定期に更新されると、当該地図ＤＢが地図ＤＢ配信サーバに格納されることになり、新しいバージョンの地図ＤＢが生成されるたびに、対応するバージョンの地図ＤＢが配信される。

地図ＤＢの全国または特定の範囲は、当該範囲をメッシュ（パーセル）と呼ばれる特定の矩形状で区分することで得られる複数のエリアの集合体で表現される。車載端末が地図ＤＢを更新する場合、地図ＤＢ配信サーバに地図ＤＢのバージョンアップ（バージョンの更新）を要求し、地図ＤＢ配信サーバから配信される時点で最新である地図ＤＢに更新する。特許文献１では、各メッシュについて、バージョンごとの更新有無のフラグをリストにしたバージョンアップリスト（バージョンアップ管理ファイル）を記憶する構成が提案されている。

国際公開第２０１２／０９５９７４号

近年、複数のメッシュ領域内の地図を示す複数のメッシュファイルについて、全てのメッシュファイルを更新するのではなく、必要なメッシュファイルだけリアルタイムで最新のメッシュファイルに更新することが求められている。

しかしながら、従来の地図データ更新装置では、メッシュファイルの更新を管理するためのファイルのデータサイズが比較的大きいため、メッシュファイルの更新についてリアルタイム性が損なわれているという問題があった。特に、車線単位の道路形状を含む高精度地図ＤＢの高精度維持のために、メッシュファイルの更新がしばしば行われるＡＤＡＳ（Advanced Driver Assistance System）やＡＤ（Automated Driving）などでは、当該リアルタイム性は重要である。

そこで、本開示は、上記のような問題点を鑑みてなされたものであり、メッシュファイルの更新を管理するためのファイルのデータサイズを低減可能な技術を提供することを目的とする。

本開示に係る地図データ更新装置は、それぞれが、地図データを区分して得られる複数のメッシュの１つ以上に対応する複数のメッシュファイルを、サーバと通信を行うことによって選択的に更新する地図データ更新装置であって、複数のビットの位置が複数のメッシュファイルのメッシュＩＤと対応付けられたビット配列を有し、メッシュファイルの更新の要否を示す１ビットのフラグ情報が、ビット配列のうち当該メッシュファイルのメッシュＩＤに対応する位置に格納された更新要否管理ファイルを記憶する記憶部と、複数のメッシュファイルのうち車両で用いられる対象として特定されたメッシュファイルである特定メッシュファイルのメッシュＩＤと、更新要否管理ファイルとに基づいて特定メッシュファイルを更新し、かつ、特定メッシュファイルの更新結果と、更新ファイルとに基づいて更新要否管理ファイルを更新する更新部とを備え、前記更新ファイルは、第１バージョンの前記地図データと、前記第１バージョンの１つ前の第２バージョンの前記地図データとの間の差に基づいて前記メッシュファイルの更新の要否が設定される、または、前記複数のメッシュファイルのそれぞれのバージョンが格納されたバージョン管理ファイルに関して、第１バージョンの前記バージョン管理ファイルと、前記第１バージョンの１つ前の第２バージョンの前記バージョン管理ファイルとの間の差に基づいて前記メッシュファイルの更新の要否が設定される。

本開示によれば、複数のビットの位置が複数のメッシュファイルのメッシュＩＤと対応付けられたビット配列を有し、メッシュファイルの更新の要否を示す１ビットのフラグ情報が、ビット配列のうち当該メッシュファイルのメッシュＩＤに対応する位置に格納された更新要否管理ファイルを用いる。このような構成によれば、メッシュファイルの更新を管理するためのファイルのデータサイズを低減することができる。

本開示の目的、特徴、局面及び利点は、以下の詳細な説明と添付図面とによって、より明白となる。

実施の形態１に係る地図ＤＢ更新装置の構成を示すブロック図である。 実施の形態１に係る更新要否管理ファイルのデータ例を示す図である。 実施の形態２に係る車載端末の構成を示すブロック図である。 本実施の形態２に係るメッシュ領域、メッシュファイル、及び、バージョン管理ファイルの関係を示す図である。 車載端末及び地図ＤＢ配信サーバに記憶される各種ファイルを示す図である。 実施の形態２に係る車載端末の動作を示すフローチャートである。 実施の形態２に係る車載端末の動作を示すフローチャートである。 実施の形態２に係る車載端末の動作を示すフローチャートである。 実施の形態２に係る車載端末の動作例を示す図である。 実施の形態２に係る車載端末の動作例を示す図である。 実施の形態２に係る更新要否管理ファイルのデータ例を示す図である。 実施の形態２の変形例４に係る車載端末の動作を示すフローチャートである。 実施の形態３に係る車両制御装置の構成を示すブロック図である。 実施の形態３に係るメッシュ領域を示す図である。 実施の形態３に係る車両制御装置の動作を示すフローチャートである。 実施の形態３に係る車両制御装置の動作を示すフローチャートである。 実施の形態３に係る車両制御装置の動作を示すフローチャートである。 実施の形態３の変形例２に係るメッシュ領域を示す図である。 実施の形態４に係る車両制御装置の構成を示すブロック図である。 その他の変形例に係る地図ＤＢ更新装置のハードウェア構成を示すブロック図である。 その他の変形例に係る地図ＤＢ更新装置のハードウェア構成を示すブロック図である。

＜実施の形態１＞
図１は、本実施の形態１に係る地図データ更新装置である地図ＤＢ更新装置１などの構成を示すブロック図である。

地図ＤＢ更新装置１は、例えば車両に備え付けられたり、車両に持ち込まれたりすることによって、車両とともに移動可能となっている。以下の説明では、地図ＤＢ更新装置１とともに移動可能であり、着目の対象となる車両を「自車両」と記すこともある。

自車両または地図ＤＢ更新装置１には、地図データである地図ＤＢが記憶されている。この地図ＤＢは、複数のメッシュに区分されており、複数のメッシュファイルのそれぞれは１つ以上のメッシュに対応している。つまり、１つのメッシュファイルは、地図ＤＢの一部に相当する。なお、以下の説明では、１つのメッシュファイルは、１つの矩形状のメッシュの範囲に相当するものとして説明するが、複数の矩形状のメッシュの範囲に相当してもよい。

サーバである地図ＤＢ配信サーバ６１では、地図ＤＢのメッシュファイルが適宜更新され、地図ＤＢ更新装置１からの要求に応じて、更新されたメッシュファイルが地図ＤＢ配信サーバ６１から地図ＤＢ更新装置１に配信される。地図ＤＢ更新装置１は、このような地図ＤＢ配信サーバ６１と通信を行うことによって複数のメッシュファイルを選択的に更新する。ここで、複数のメッシュファイルを選択的に更新するとは、複数のメッシュファイルの１つ以上を更新することに相当する。

図１の地図ＤＢ更新装置１は、記憶部１１と更新部１２とを備える。記憶部１１は、更新要否管理ファイルを記憶している。

図２は、更新要否管理ファイルのデータ例を示す図である。更新要否管理ファイルはビット配列を有している。当該ビット配列では、複数のビットの位置が、複数のメッシュファイルを識別するためのメッシュＩＤと対応付けられている。

図２では、地図ＤＢが８つのメッシュファイルに区分されており、８つのメッシュファイルがメッシュＩＤ［１］～［８］によって識別される例が示されている。そして、一番左端のビットの位置にはメッシュＩＤ［１］が対応付けられ、その右隣のビットの位置にはメッシュＩＤ［２］が対応付けられ、…、一番右端のビットの位置にはメッシュＩＤ［８］が対応付けられている。なお、図２では、ビットの位置の左から右に向かって、メッシュＩＤが大きくなっていくように、ビットの位置とメッシュＩＤとが対応付けられているが、これらの対応関係は、地図ＤＢ更新装置１のデータ記憶の効率性などを考慮して適宜変更されてもよい。

更新要否管理ファイルでは、メッシュファイルの更新の要否を示す１ビットのフラグ情報である更新要否フラグが、上記ビット配列のうち当該メッシュファイルのメッシュＩＤに対応する位置に格納されている。例えば、１ビットの値が「１」である更新要否フラグが更新必要を示し、１ビットの値が「０」である更新要否フラグが更新不要を示す場合を想定する。この場合図２では、メッシュＩＤ［１］に対応する位置には値が「０」である更新要否フラグが格納されているため、メッシュＩＤ［１］のメッシュファイルは更新不要であることが示されている。また例えば、図２では、メッシュＩＤ［２］に対応する位置には値が「１」である更新要否フラグが格納されているため、メッシュＩＤ［２］のメッシュファイルは更新必要であることが示されている。

ここで、複数のメッシュファイルのうち自車両で用いられる対象として特定されたメッシュファイルを「特定メッシュファイル」と記す。特定メッシュファイルは、１つのメッシュファイルであってもよいし、複数のメッシュファイルであってもよい。図１の更新部１２は、特定メッシュファイルのメッシュＩＤと、更新要否管理ファイルとに基づいて、自車両または地図ＤＢ更新装置１に記憶された特定メッシュファイルを更新する。

例えば、図２において、メッシュＩＤ［１］～［４］のメッシュファイルが特定メッシュファイルであり、メッシュＩＤ［５］～［８］のメッシュファイルが特定メッシュファイルでない場合を想定する。この場合、メッシュＩＤ［１］～［４］のうち更新要否フラグとして更新必要（「１」）が設定されているメッシュＩＤは、メッシュＩＤ［２］，［４］である。このため、更新部１２は、メッシュＩＤ［２］，［４］の新しいメッシュファイルを地図ＤＢ配信サーバ６１から受信する。そして、更新部１２は、受信したメッシュファイルで、自車両または地図ＤＢ更新装置１に記憶されている特定メッシュファイル（メッシュＩＤ［２］，［４］のメッシュファイル）を更新する。

また、更新部１２は、特定メッシュファイルの更新結果と、地図ＤＢ配信サーバ６１から受信した受信情報とに基づいて、更新要否管理ファイルを更新する。

例えば、図２の更新要否管理ファイルにおいて上記例のような更新が行われた場合、更新部１２は、当該更新要否管理ファイルのメッシュＩＤ［２］，［４］の更新要否フラグを、更新必要（「１」）から更新不要（「０」）に更新する。

例えば、地図ＤＢ配信サーバ６１からの受信情報が、メッシュＩＤ［３］のメッシュファイルが更新されたことを示す場合、更新部１２は、図２の更新要否管理ファイルのメッシュＩＤ［３］の更新要否フラグを、更新不要（「０」）から更新必要（「１」）に更新する。

＜実施の形態１のまとめ＞
従来、メッシュファイルの更新を管理するためのファイルとして、メッシュＩＤと、メッシュファイルのバージョンとを対応付けたファイルが用いられている。しかしながら、メッシュファイルが多くなったり、バージョンの数が多くなったりすると、メッシュＩＤの番号及びバージョンの数が大きくなり、上記ファイルのデータサイズが大きくなるという問題があった。

これに対して本実施の形態１に係る地図ＤＢ更新装置１は、複数のビットの位置が複数のメッシュファイルのメッシュＩＤと対応付けられたビット配列を有し、メッシュファイルの更新の要否を示す１ビットのフラグ情報が、ビット配列のうち当該メッシュファイルのメッシュＩＤに対応する位置に格納された更新要否管理ファイルを用いる。このような構成によれば、メッシュファイルの更新を管理するためのファイルのデータサイズを低減することができ、更新要否管理ファイルのオープン・クローズ時間が短縮されるとともに、演算時間の短縮が実現できる。その結果として、メッシュファイルの更新についてリアルタイム性を高めることができる。

また従来では、地図ＤＢ配信サーバ６１でいくつかのメッシュファイルが更新された場合、車両でも当該いくつかのメッシュファイルが全て更新される。しかしながら、このような更新は、車両のＣＰＵ（Central Processing Unit）リソース及びメモリリソースの消費が比較的大きいという問題があった。

これに対して本実施の形態１では、地図ＤＢ配信サーバ６１で更新されたメッシュファイルのうち、自車両で用いられる対象として特定されたメッシュファイルである特定メッシュファイルを、更新要否管理ファイルに基づいて更新する。これにより、必要性が乏しいメッシュファイルの更新が抑制されるので、自車両のＣＰＵリソース及びメモリリソースの消費を低減することができる。その結果、メッシュファイルの更新についてリアルタイム性を高めることができる。

＜実施の形態２＞
図３は、本実施の形態２に係る地図データ更新装置である地図ＤＢ更新装置１を備える車載端末３１ａなどの構成を示すブロック図である。以下、本実施の形態２に係る構成要素のうち、上述の構成要素と同じまたは類似する構成要素については同じまたは類似する参照符号を付し、異なる構成要素について主に説明する。

車載端末３１ａは、通信端末６２を介して地図ＤＢ配信サーバ６１と通信を行う。地図ＤＢ配信サーバ６１は、実施の形態１の地図ＤＢ配信サーバ６１と同様である。ただし、本実施の形態２に係る地図ＤＢ配信サーバ６１は、後述するバージョン管理ファイルを管理している。

車載端末３１ａは地図ＤＢを用い、当該地図ＤＢは地図ＤＢ更新装置１で適宜更新される。図３の車載端末３１ａは、地図ＤＢ更新装置１だけでなく、地図データ記憶部である地図ＤＢ記憶部３２と、衛星測位装置３３と、車両センサ３４と、車両位置検出部である自車両位置検出部３５と、地図データアクセス部である地図ＤＢアクセス部３６と、地図アプリケーション３７とを備える。

地図ＤＢ記憶部３２は、地図データである地図ＤＢについて複数のメッシュファイルを記憶している。本実施の形態２では、１つのメッシュファイルは、１つの矩形状のメッシュの範囲に相当するが、これに限ったものではない。

本実施の形態２では、地図ＤＢ記憶部３２の地図ＤＢは、例えば、通常精度地図データである通常精度地図ＤＢと、通常精度地図ＤＢよりも高精度である高精度地図データである高精度地図ＤＢとを含む。通常精度地図ＤＢは、例えば、道路中心線の道路形状を含み、その誤差が数ｍレベルである地図ＤＢである。高精度地図ＤＢは、例えば、車線中心線の車線形状を含み、その誤差が数ｃｍレベルである地図ＤＢである。

衛星測位装置３３は、例えば、ＧＰＳ（Global Positioning System）受信機などのＧＮＳＳ（Global Navigation Satellite System）受信機であり、衛星により測定された自車両の位置を示す測位データを取得する。

車両センサ３４は、自車両の車速パルスや自車両の加速度などの自車両のセンサ情報を検出する。車両センサ３４は、自車両周辺の状態を検出する装置を含んでもよい。

自車両位置検出部３５は、衛星測位装置３３で取得された測位データと、車両センサ３４で検出されたセンサ情報とに基づいて、自車両の位置を検出する。なお、自車両位置検出部３５は、地図ＤＢ記憶部３２の地図ＤＢに含まれる道路形状に基づいて、自車両の位置のマップマッチング処理を行ってもよい。

地図ＤＢアクセス部３６は、地図ＤＢ記憶部３２に記憶されている複数のメッシュファイルのうち地図アプリケーション３７から要求されたメッシュファイルを、実施の形態１で説明した特定メッシュファイルとして特定する。そして、地図ＤＢアクセス部３６は、特定メッシュファイルの地図更新要求を、地図ＤＢ更新装置１の地図ＤＢ更新部１２ａに出力する。地図更新要求を受けた地図ＤＢ更新部１２ａは、特定メッシュファイルを適宜更新する処理を行う。なお、地図ＤＢ更新部１２ａによる処理で、地図ＤＢ記憶部３２の特定メッシュファイルが更新されることもあれば更新されないこともある。地図ＤＢアクセス部３６は、処理後の特定メッシュファイルを地図ＤＢ記憶部３２から読み出して地図アプリケーション３７に出力する。

地図アプリケーション３７は、地図ＤＢのメッシュファイルを用いるアプリケーションであり、自車両位置検出部３５で検出された自車両の位置に基づいて、地図ＤＢアクセス部３６にメッシュファイルを要求する。地図アプリケーション３７には、例えば、ナビゲーションアプリケーション、ＡＤＡＳアプリケーション、及び、ＡＤアプリケーションなどが用いられる。

＜地図ＤＢ更新装置＞
図３の地図ＤＢ更新装置１は、更新要否管理情報記憶部１１ａと、地図ＤＢ更新部１２ａと、通信Ｉ／Ｆ（インターフェース）部１３と、新規更新情報記憶部１４とを備える。図３の更新要否管理情報記憶部１１ａは、図１の記憶部１１の概念に含まれ、図３の地図ＤＢ更新部１２ａは、図１の更新部１２の概念に含まれる。

更新要否管理情報記憶部１１ａは、実施の形態１で説明した更新要否管理ファイルと同様の更新要否管理ファイルを記憶している。

地図ＤＢ更新部１２ａは、地図ＤＢアクセス部３６から特定メッシュファイルの地図更新要求を受けると、特定メッシュファイルのメッシュＩＤと、更新要否管理ファイルとに基づいて、地図ＤＢ記憶部３２の特定メッシュファイルを更新するか否かを判定する。地図ＤＢ更新部１２ａは、特定メッシュファイルを更新すると判定した場合に、通信Ｉ／Ｆ部１３を介して、特定メッシュファイルに相当する新しいメッシュファイルを地図ＤＢ配信サーバ６１から受信する。そして、地図ＤＢ更新部１２ａは、受信したメッシュファイルで、地図ＤＢ記憶部３２の特定メッシュファイルを更新する。また、地図ＤＢ更新部１２ａは、特定メッシュファイルの更新結果と、地図ＤＢ配信サーバ６１から通信Ｉ／Ｆ部１３を介して受信した受信情報とに基づいて更新要否管理ファイルを更新する。

通信Ｉ／Ｆ部１３は、通信端末６２の通信を制御して地図ＤＢ配信サーバ６１と通信を行う。以下、地図ＤＢ更新装置１のいずれかの構成要素が、通信Ｉ／Ｆ部１３などを介して地図ＤＢ配信サーバ６１と送信または受信することを、当該構成要素が地図ＤＢ配信サーバ６１と送信または受信すると略記することもある。

新規更新情報記憶部１４は、地図ＤＢ配信サーバ６１から受信した更新ファイルを適宜記憶する。本実施の形態２に係る受信情報は更新ファイルであり、この更新ファイルは、地図ＤＢ配信サーバ６１が管理しているバージョン管理ファイルに基づいて生成される。

＜バージョン管理ファイル＞
図４は、本実施の形態２に係るメッシュ領域、メッシュファイル、及び、バージョン管理ファイルを示す図である。

地図ＤＢが示す地図の領域は、メッシュ（パーセル）と呼ばれる特定の矩形状で複数のメッシュ領域に区分されている。図４（ａ）の例では、地図ＤＢが示す地図の領域は、５×７のメッシュ領域に区分されている。複数のメッシュ領域のそれぞれには、メッシュ領域を識別するためのメッシュＩＤが付与されている。図４（ａ）の例では、左下のメッシュ領域にメッシュＩＤとして０１を付与する。そして、（ｉ）右に１つ進むにつれてメッシュＩＤの番号に１を加えることと、（ｉｉ）右端のメッシュ領域のメッシュＩＤの次の番号をその段の上の左端のメッシュ領域に付与することと、を行う。ただし、メッシュＩＤの付与ルールは、これに限ったものではなく、その他の付与ルールが用いられてもよい。

各メッシュ領域内の道路リンクやノードを含む部分的な地図ＤＢは、図４（ｂ）に示すようなメッシュファイルに格納される。なお、図４（ｂ）のメッシュファイル（ｍ＝１～Ｍ）（ｖｎ）のうち、ｍはメッシュファイルのメッシュＩＤを示し、ｎは地図ＤＢのバージョンを示す。図４（ａ）の場合、Ｍ＝３５であり、３５のメッシュファイルが用いられる。

複数のメッシュファイルのバージョンは、バージョン管理ファイルで管理されている。なお、図４（ｂ）のバージョン管理ファイル（ｖｎ）のうち、ｎは地図ＤＢのバージョンを示す。

図４（ｃ）は、本実施の形態２に係るバージョン管理ファイルを示す図である。バージョン管理ファイルのファイル名には、例えば、バージョン管理ファイルのバージョンが分かる名称（図４（ｃ）の例ではＶｅｒ．ｎでありｎ≧３）が付与される。

００００のアドレスには、メッシュＩＤ［０１］のメッシュファイルが更新されたときの地図ＤＢのバージョン（図４（ｃ）の例ではＶｅｒ．３）が、メッシュファイルのバージョンとして格納されている。０００１のアドレスには、メッシュＩＤ［０２］のメッシュファイルが更新されたときの地図ＤＢのバージョン（図４（ｃ）の例ではＶｅｒ．２）が、メッシュファイルのバージョンとして格納されている。以下のアドレスにも同様にメッシュファイルのバージョンが格納されている。

一般に、地図ＤＢのバージョンアップが発生しても、全てのメッシュファイルは更新されるとは限らず、一部のメッシュファイルが更新されるが、残りのメッシュファイルが更新されないことが多い。このため、図４（ｃ）に示すように、複数のメッシュファイルのバージョンは互いに異なることが多い。また、メッシュファイルのバージョンは、地図ＤＢのバージョンと同じか、それよりも小さい。一方、バージョン管理ファイルのバージョンは、複数のメッシュファイルのいずれかが更新されると更新されるため、地図ＤＢのバージョンと実質的に同じである。

地図ＤＢのバージョンがＶｅｒ．１である場合、図４（ｄ）に示すように、バージョン管理ファイルにおける全てのメッシュファイルのバージョンはＶｅｒ．１である。図４（ｄ）のようなバージョン管理ファイルは、本実施の形態２では実質的に使用されないため、バージョンがＶｅｒ．１であるバージョン管理ファイルは設定されなくてもよい。

図５は、地図ＤＢがｎ回更新されたとき、つまり地図ＤＢのバージョンがＶｅｒ．ｎであるときに、車載端末３１ａ及び地図ＤＢ配信サーバ６１に記憶される各種ファイルを示す図である。

地図ＤＢ配信サーバ６１では、バージョンが１からｎまでのＭ×ｎ個のメッシュファイルが記憶され、バージョンが１からｎまでのｎ個のバージョン管理ファイルが記憶される。

車載端末３１ａでは、バージョンがｎ以下であるＭ個のメッシュファイルが記憶され、１個の更新要否管理ファイルが記憶される。なお、地図ＤＢ配信サーバ６１における、一のメッシュＩＤのメッシュファイルが更新されたとしても、車載端末３１ａにおける、当該一のメッシュＩＤのメッシュファイルは、地図アプリケーション３７によって要求されなければ更新されない。このため、車載端末３１ａのメッシュファイルのバージョンと、地図ＤＢ配信サーバ６１のメッシュファイルのバージョンとは、メッシュＩＤが同じであっても、同じとなることもあれば異なることもある。つまり、車載端末３１ａのメッシュファイルのバージョンは、地図ＤＢ配信サーバ６１のメッシュファイルのバージョンに対して、ある程度独立している。

地図ＤＢ配信サーバ６１は、最新バージョン（第１バージョン）のバージョン管理ファイル（地図ＤＢ）と、最新バージョンの１つ前のバージョン（第２バージョン）のバージョン管理ファイル（地図ＤＢ）との間の差に基づいて、更新ファイルを生成する。更新ファイルは、更新要否管理ファイルと同一データ形式のファイルであり、メッシュＩＤごとにメッシュファイルの更新の要否が設定されている。

例えば、（ｎ－１）バージョンのバージョン管理ファイルからｎバージョンのバージョン管理ファイルへの更新が行われ、最新バージョンがｎバージョンになった場合を想定する。この場合、地図ＤＢ配信サーバ６１は、バージョン管理ファイルへの更新に伴って車載端末３１ａで更新が必要なメッシュファイルについて、更新要否管理ファイルのメッシュＩＤの更新要否フラグを更新必要に設定するための更新ファイルを生成する。一方、地図ＤＢ配信サーバ６１は、バージョン管理ファイルへの更新に伴って車載端末３１ａで更新が不要なメッシュファイルについて、更新要否管理ファイルのメッシュＩＤの更新要否フラグを更新不要に設定するための更新ファイルを生成する。

なお、本実施の形態２では、値が「１」である更新要否フラグは、対応するメッシュＩＤの特定メッシュファイルが更新必要であることを示し、値が「０」である更新要否フラグは、対応するメッシュＩＤの特定メッシュファイルが更新不要であることを示す。

＜動作＞
図６～図８は、本実施の形態２に係る車載端末３１ａの動作を示すフローチャートである。

まず図６を用いて、地図アプリケーション３７が主に行う動作について説明する。

地図アプリケーション３７が起動すると、ステップＳ１にて自車両位置検出部３５は、衛星測位装置３３で取得された測位データと、車両センサ３４で検出されたセンサ情報とに基づいて、自車両の位置を検出する。なお、自車両位置検出部３５は、地図ＤＢ記憶部３２の地図ＤＢに含まれる道路形状に基づいて、自車両の位置のマップマッチング処理を行ってもよい。地図アプリケーション３７は、自車両位置検出部３５で検出された自車両の位置を取得する。

ステップＳ２にて、地図アプリケーション３７は、自車両位置検出部３５で検出された自車両の位置に基づいて、地図アプリケーション３７で必要なメッシュファイルを地図ＤＢアクセス部３６に要求する。

これにより、地図ＤＢアクセス部３６は、地図アプリケーション３７から要求されたメッシュファイルを特定メッシュファイルとして特定し、特定メッシュファイルの地図更新要求を地図ＤＢ更新部１２ａに出力する。地図更新要求を受けた地図ＤＢ更新部１２ａは、地図ＤＢ記憶部３２の特定メッシュファイルを適宜更新する処理を行う。地図ＤＢアクセス部３６は、処理後の特定メッシュファイルを地図ＤＢ記憶部３２から読み出す。

ステップＳ３にて、地図アプリケーション３７は、地図ＤＢアクセス部３６が地図ＤＢ記憶部３２から読み出した特定メッシュファイルを取得する。

ステップＳ４にて、地図アプリケーション３７は、地図ＤＢアクセス部３６から取得された特定メッシュファイルを用いてナビゲーション機能、ＡＤＡＳ機能（運転支援機能）、及び、ＡＤ機能（自動運転機能）などを実行する。

ステップＳ５にて、車載端末３１ａは、例えば自車両の駆動源（例えばエンジン及びモータの少なくともいずれか１つ）の停止、または、地図アプリケーション３７の終了指示の有無に基づいて地図アプリケーション３７を終了するか否かを判定する。終了すると判定された場合には図６の動作が終了し、終了すると判定されなかった場合には処理がステップＳ１に戻る。

次に図７を用いて、地図ＤＢアクセス部３６が主に行う動作について説明する。

ステップＳ１１にて、地図ＤＢアクセス部３６は、地図アプリケーション３７からメッシュファイルの要求を受けたか否かを判定する。要求を受けたと判定された場合には処理がステップＳ１２に進み、要求を受けたと判定されなかった場合にはステップＳ１１の処理が繰り返される。

ステップＳ１２にて、地図ＤＢアクセス部３６は、地図アプリケーション３７から要求されたメッシュファイルを、特定メッシュファイルとして特定し、特定メッシュファイルの地図更新要求を地図ＤＢ更新部１２ａに出力する。地図更新要求の出力は、特定メッシュファイルが最新に更新されているか否かの問い合わせに相当する。

ステップＳ１３にて、地図ＤＢアクセス部３６は、地図データ準備可能情報を地図ＤＢ更新部１２ａから受けたか否かを判定する。なお、地図データ準備可能情報は、地図更新要求を受けた地図ＤＢ更新部１２ａが特定メッシュファイルを適宜更新する処理を行った後に、地図ＤＢ更新部１２ａから地図ＤＢアクセス部３６に出力される情報である。地図データ準備可能情報を受けたと判定された場合には処理がステップＳ１４に進み、地図データ準備可能情報を受けたと判定されなかった場合にはステップＳ１３の処理が繰り返される。

ステップＳ１４にて、地図ＤＢアクセス部３６は、特定メッシュファイルを地図ＤＢ記憶部３２から読み出す。

ステップＳ１５にて、地図ＤＢアクセス部３６は、読み出された特定メッシュファイルを地図アプリケーション３７に出力する。その後、処理がステップＳ１１に戻る。

次に図８を用いて、地図ＤＢ更新装置１の地図ＤＢ更新部１２ａが主に行う動作について説明する。

ステップＳ２１にて、地図ＤＢ更新部１２ａは、地図ＤＢ配信サーバ６１において地図ＤＢのバージョンが更新されたか否かを確認する。確認方法としては、地図ＤＢ更新部１２ａが地図ＤＢ配信サーバ６１に定期または不定期で問い合わせる方法であってもよいし、地図ＤＢ配信サーバ６１から地図ＤＢ更新部１２ａに定期または不定期で通知する方法であってもよい。

バージョンが更新されたことを確認した場合には処理がステップＳ２２に進み、バージョンが更新されたことを確認しなかった場合には処理がステップＳ２３に進む。

ステップＳ２２にて、地図ＤＢ更新部１２ａは、バージョン管理ファイルに基づき生成された更新ファイルを地図ＤＢ配信サーバ６１から受信し、当該更新ファイルに基づいて更新要否管理ファイルを更新する。これにより、更新要否管理ファイルのいずれかのメッシュファイルにおいて、メッシュＩＤに対応する更新要否フラグが更新必要に更新される。なお、更新要否管理ファイルの更新については後で詳細に説明する。その後、処理がステップＳ２３に進む。

ステップＳ２３にて、地図ＤＢ更新部１２ａは、地図ＤＢアクセス部３６から特定メッシュファイルの地図更新要求を受けたか否かを判定する。地図更新要求を受けたと判定された場合には処理がステップＳ２４に進み、地図更新要求を受けたと判定されなかった場合には処理がステップＳ２１に戻る。

ステップＳ２４にて、地図ＤＢ更新部１２ａは、更新要否管理ファイルのビット配列のうち、特定メッシュファイルのメッシュＩＤに対応する位置の更新要否フラグを取得する。

ステップＳ２５にて、地図ＤＢ更新部１２ａは、更新要否フラグが更新必要を示しているか否かを判定する。更新要否フラグが更新必要を示していると判定された場合には処理がステップＳ２６に進み、更新要否フラグが更新必要を示していない（更新不要を示している）と判定された場合には処理がステップＳ２９に進む。

ステップＳ２６にて、地図ＤＢ更新部１２ａは、更新要否フラグによって更新必要と示された特定メッシュファイルについて、新しいメッシュファイルを地図ＤＢ配信サーバ６１に要求し、地図ＤＢ配信サーバ６１から新しいメッシュファイルを受信する。

ステップＳ２７にて、地図ＤＢ更新部１２ａは、受信したメッシュファイルで、地図ＤＢ記憶部３２の特定メッシュファイルを上書きする。これにより、地図ＤＢ記憶部３２の複数のメッシュファイルのうち、更新要否管理ファイルの更新要否フラグによって更新必要と示された特定メッシュファイルが更新される。

ステップＳ２８にて、地図ＤＢ更新部１２ａは、更新要否管理ファイルのうち、ステップＳ２７で更新された特定メッシュファイルの更新要否フラグを更新必要（「１」）から更新不要（「０」）に更新する。更新不要（「０」）に更新された更新要否フラグは、ステップＳ２２にて更新必要に更新されるまで更新不要を維持するため、当該更新要否フラグに関してステップＳ２６～Ｓ２８の処理は行われない。

ステップＳ２９にて、地図ＤＢ更新部１２ａは、地図データ準備可能情報を地図ＤＢアクセス部３６に出力する。その後、処理がステップＳ２１に戻る。なお、図示しないが、図６～図８の動作は電源オフなどにより終了する。

＜動作例＞
図９及び図１０は、本実施の形態２に係る車載端末３１ａの動作例を示す図である。

なお、この動作例では、地図ＤＢ記憶部３２及び更新要否管理情報記憶部１１ａは、電源が確保されているメモリ、または、不揮発性メモリを含むものとする。そして、メッシュファイル及び更新要否管理ファイルは、自車両の駆動源（例えばエンジン及びモータの少なくともいずれか１つ）を停止しても消えないように、それらメモリに記憶されているものとする。

ここでは説明を簡単にするため、最新のバージョンがＶｅｒ．１である場合に、Ｖｅｒ．１の地図ＤＢが格納された車載端末３１ａがリリースされたとして説明する。

地図ＤＢ配信サーバ６１にはＶｅｒ．１のメッシュファイルしか存在しないため、バージョン管理ファイルは、図９（ａ）のようなデータとなる。

この例では、車載端末３１ａの初期状態の更新要否管理ファイルは、図９（ｂ）のようなデータになる。車載端末３１ａの地図ＤＢは最新のバージョンであるため、図８のステップＳ２１，Ｓ２３，Ｓ２４，Ｓ２５，Ｓ２９の処理が順に行われるが、ステップＳ２２，Ｓ２８の更新要否管理ファイルの変更は行われない。

次に、地図ＤＢ配信サーバ６１の地図ＤＢのバージョンがＶｅｒ．２に更新され、バージョン管理ファイルが図９（ｃ）のようなデータになったとする。なお、図９（ｃ）の例では、メッシュＩＤ［０１］，［０６］，［０７］，［０８］のメッシュファイルがＶｅｒ．２に更新され、それ以外のメッシュファイルは更新されていない。更新された新しいメッシュファイルは地図ＤＢ配信サーバ６１に格納される。

このように地図ＤＢのバージョンがＶｅｒ．２に更新されると、地図ＤＢ配信サーバ６１は、地図ＤＢ（バージョン管理ファイル）のバージョンアップに応じて図９（ｄ）のような更新ファイル（Ｖｅｒ．２）を作成する。更新ファイルは、更新要否管理ファイルと同一データ形式を有しており、更新ファイルではメッシュＩＤと、メッシュファイルのビットアドレスと、更新フラグとが対応付けられている。なお、値が「１」である更新フラグは、対応するメッシュＩＤのメッシュファイルが地図ＤＢ配信サーバ６１において更新されたことを示し、値が「０」である更新フラグは、対応するメッシュＩＤのメッシュファイルが地図ＤＢ配信サーバ６１において更新されていないことを示す。

更新ファイルの更新フラグは、地図ＤＢ配信サーバ６１によって、最新バージョンのバージョン管理ファイルと、最新バージョンの１つ前のバージョンのバージョン管理ファイルとの間の差に基づいて設定される。ここでは、最新バージョンの１つ前のバージョンのバージョン管理ファイルは、図９（ａ）のバージョン管理ファイルであり、最新バージョンのバージョン管理ファイルは、図９（ｃ）のバージョン管理ファイルである。このため、図９（ａ）から図９（ｃ）へのバージョン管理ファイルへのバージョンアップにおいて、更新されたメッシュファイルには更新フラグとして「１」が、更新されていないメッシュファイルには更新フラグとして「０」が設定される。

地図ＤＢ更新装置１の地図ＤＢ更新部１２ａは、地図ＤＢ配信サーバ６１から図９（ｄ）の更新ファイルを受信すると、図８のステップＳ２２の処理を行う。例えば、地図ＤＢ更新部１２ａは、図９（ｄ）の更新ファイルと、図９（ｂ）の更新要否管理ファイルとに基づいて、更新要否管理ファイルを更新するビット演算を行う。本実施の形態２では、地図ＤＢ更新部１２ａは、ビット演算としてビット単位のＯＲ処理を行うことにより、図９（ｅ）のように更新要否管理ファイルを更新する。本実施の形態２では、このようにビット単位のＯＲ処理だけで更新要否管理ファイルを更新するので、更新要否管理ファイルを高速に更新することができる。

その後、図６のステップＳ２にて地図アプリケーション３７が、例えばメッシュＩＤ［０６］のメッシュファイルを要求した場合に、図８のステップＳ２４、Ｓ２５，Ｓ２６，Ｓ２７，Ｓ２８の処理が行われる。これにより図９（ｆ）のように、地図ＤＢ更新部１２ａは、更新要否管理ファイルのメッシュＩＤ［０６］（ビットアドレス＝０１０１）に対応する更新要否フラグを、更新必要（「１」）から更新不要（「０」）に更新する。このような処理は、地図アプリケーション３７が、更新必要（「１」）に設定されているメッシュファイルを要求した場合に実行される。通常、この処理を実行するか否かは車載端末３１ａごとに異なるので、更新要否管理ファイルの内容は車載端末３１ａごとに異なる。

次に、地図ＤＢ配信サーバ６１の地図ＤＢのバージョンがＶｅｒ．３に更新され、バージョン管理ファイルが図１０（ａ）のようなデータになったとする。なお、図１０（ａ）の例では、メッシュＩＤ［０１］，［０２］，［０３］のメッシュファイルがＶｅｒ．３に更新される。一方、メッシュＩＤ［０４］，［０５］のメッシュファイルはＶｅｒ．１のままであり、メッシュＩＤ［０６］，［０７］，［０８］のメッシュファイルはＶｅｒ．２のままである。更新された新しいメッシュファイルは地図ＤＢ配信サーバ６１に格納される。

地図ＤＢのバージョンがＶｅｒ．３に更新されると、地図ＤＢ配信サーバ６１は、図９（ｂ）から図１０（ａ）への地図ＤＢ（バージョン管理ファイル）のバージョンアップに応じて図１０（ｂ）のような更新ファイル（Ｖｅｒ．３）を作成する。図１０（ｂ）の更新ファイルでは、バージョン管理ファイルのバージョンアップにおいて、更新されたメッシュファイルには更新フラグとして「１」が、更新されていないメッシュファイルには更新フラグとして「０」が設定される。この結果、メッシュＩＤ［０１］～［０３］の更新フラグに「１」が設定され、メッシュＩＤ［０４］～［０８］の更新フラグに「０」が設定される。

地図ＤＢ更新装置１の地図ＤＢ更新部１２ａは、地図ＤＢ配信サーバ６１から図１０（ｂ）の更新ファイルを受信すると、図８のステップＳ２２の処理を行う。例えば、地図ＤＢ更新部１２ａは、図１０（ｂ）の更新ファイルと、図９（ｆ）の更新要否管理ファイルとに基づいて、更新要否管理ファイルを更新するビット演算を行う。本実施の形態２では、地図ＤＢ更新部１２ａは、ビット演算としてビット単位のＯＲ処理を行うことにより、図１０（ｃ）のように更新要否管理ファイルを更新する。

なお、メッシュＩＤ［０６］の更新要否フラグは図９（ｆ）の時点で「０」である。図１０（ａ）のＶｅｒ．３のバージョン管理ファイルでは、メッシュＩＤ［０６］のメッシュファイルの最新バージョンはＶｅｒ．２であるため、更新要否管理ファイルのメッシュＩＤ［０６］の更新要否フラグは「０」となる。図１０（ａ）とは異なり、仮にＶｅｒ．３のバージョン管理ファイルにおいてメッシュＩＤ［０６］のメッシュファイルの最新バージョンがＶｅｒ．３であった場合には、更新要否管理ファイルのメッシュＩＤ［０６］の更新要否フラグは「１」となる。

その後、図６のステップＳ２にて地図アプリケーション３７が、例えばメッシュＩＤ［０３］のメッシュファイルを要求すると、図８のステップＳ２４、Ｓ２５，Ｓ２６，Ｓ２７，Ｓ２８の処理が行われる。これにより、地図ＤＢ更新部１２ａは、図１０（ｄ）のように、更新要否管理ファイルのメッシュＩＤ［０３］（ビットアドレス＝００１０）に対応する更新要否フラグを、更新必要（「１」）から更新不要（「０」）に更新する。このような処理は、地図アプリケーション３７が、更新必要（「１」）に設定されているメッシュファイルを要求した場合に実行される。通常、この処理を実行するか否かは車載端末３１ａごとに異なるので、更新要否管理ファイルの内容は車載端末３１ａごとに異なる。

図１０（ｅ）は、図１０（ｄ）の更新要否管理ファイルが得られたときの、車載端末３１ａの各メッシュファイルのバージョンを示す図である。図１０（ｅ）の情報は、車載端末３１ａで適宜記憶されてもよい。車載端末３１ａのＣＰＵリソースが余っている場合に、バージョン状態を示す図１０（ｅ）の情報を記憶する処理を実行すれば、その記憶処理の実行によるメッシュファイルの更新についてリアルタイム性の低下を抑制することができる。

図１１は、メッシュの数が比較的大きい場合の本実施の形態２に係る更新要否管理ファイルのデータ例を示す図である。図１１のように、メッシュＩＤ［０１］～［１６］は、ＷＯＲＤアドレス（０）の１６ビットのＷＯＲＤのデータに格納され、メッシュＩＤ［１７］～［３２］は、ＷＯＲＤアドレス（１）の１６ビットのＷＯＲＤのデータに格納される。

＜実施の形態２のまとめ＞
以上のような本実施の形態２によれば、実施の形態１と同様に、更新要否管理ファイルを用いてメッシュファイルを更新するため、メッシュファイルの更新についてリアルタイム性を高めることができる。

また本実施の形態２では、更新ファイルと更新要否管理ファイルとに基づいて、更新要否管理ファイルを更新するビット演算を行うため、更新要否管理ファイルを高速に更新することができる。

＜実施の形態２の変形例１＞
実施の形態２では、地図ＤＢ配信サーバ６１の地図ＤＢのバージョンが更新された場合に、地図ＤＢ配信サーバ６１で、図９（ｄ）及び図１０（ｂ）のような更新ファイルを生成して車載端末３１ａに送信（配信）したが、これに限ったものではない。

例えば、地図ＤＢ配信サーバ６１は、図９（ｂ）及び図１０（ａ）のようなバージョン管理ファイルを送信（配信）し、地図ＤＢ更新部１２ａがバージョン管理ファイルに基づいて更新ファイルを生成してもよい。つまり、地図ＤＢ更新部１２ａは、地図ＤＢ配信サーバ６１から新しく受信したバージョン（第１バージョン）のバージョン管理ファイルと、そのバージョンの１つ前のバージョン（第２バージョン）のバージョン管理ファイルとの間の差に基づいて更新ファイルを生成してもよい。そして、地図ＤＢ更新部１２ａは、当該更新ファイルと、更新要否管理ファイルとに基づいて、更新要否管理ファイルを更新するビット演算を行ってもよい。

＜実施の形態２の変形例２＞
実施の形態２の図９及び図１０の動作例では、車載端末３１ａがリリースされたときに車載端末３１ａの地図ＤＢのバージョンと、地図ＤＢ配信サーバ６１の地図ＤＢのバージョンとが同一であるとして説明した。しかしながら、車載端末３１ａに地図ＤＢを格納した時期と、車載端末３１ａのリリース時期との間に遅延があった場合には、地図ＤＢ配信サーバ６１の地図ＤＢのバージョンと、車載端末３１ａに格納された地図ＤＢのバージョンとの差が大きい可能性がある。

そこで本変形例２では、車載端末３１ａに、リリース時において最新バージョンの地図ＤＢが格納される。そして、車載端末３１ａの動作時の図８のステップＳ２２にて、地図ＤＢ更新部１２ａは、地図ＤＢ配信サーバ６１から入手した地図ＤＢの最新バージョン（Ｖｅｒ．ｎｂ）と、車載端末３１ａの地図ＤＢのバージョン（Ｖｅｒ．ｎａ）とを比較する。

そして、地図ＤＢ更新部１２ａは、Ｖｅｒ．ｎａの地図ＤＢの更新要否管理ファイルを更新するために、Ｖｅｒ．ｎａ＋１からＶｅｒ．ｎｂまでの更新ファイルを地図ＤＢ配信サーバ６１に要求してビット演算を行い、更新要否管理ファイルを更新する。なお、地図ＤＢ更新部１２ａは、先に複数の更新ファイルの間でビット演算を行ってから、その演算結果と更新要否管理ファイルとのビット演算を行ってもよい。または、地図ＤＢ更新部１２ａは、Ｖｅｒ．ｎａの地図ＤＢの更新要否管理ファイルとＶｅｒ．ｎａ＋１の更新ファイルとのビット演算を行い、それで得られた更新要否管理ファイルとＶｅｒ．ｎａ＋２の更新ファイルとのビット演算を行い、…というように、更新ファイルのバージョン順に、更新要否管理ファイルと更新ファイルとのビット演算を行ってもよい。

＜実施の形態２の変形例３＞
実施の形態２では、更新要否管理ファイルにおいて、値が「１」である更新要否フラグが更新必要を示し、値が「０」である更新要否フラグが更新不要を示したが、「０」と「１」とは逆でもよい。

すなわち、更新要否管理ファイルにおいて、値が「０」である更新要否フラグが更新必要を示し、値が「１」である更新要否フラグが更新不要を示してもよい。この場合、地図ＤＢ更新部１２ａは、ビット演算としてビット単位のＯＲ処理ではなく、ビット単位のＡＮＤ処理を行えば、実施の形態２と同様の動作を実現することができる。

＜実施の形態２の変形例４＞
実施の形態２では、更新要否管理情報記憶部１１ａは不揮発性メモリを含み、更新要否管理ファイルなどは不揮発性メモリに記憶されているとして説明したがこれに限ったものではない。

本変形例４では、高速に更新要否管理ファイルの更新を行うために、更新要否管理情報記憶部１１ａは、不揮発性メモリと、不揮発性メモリよりも処理速度が高い高速メモリとを含む。高速メモリは、例えば、ＳｏＣ（system on chip）に内蔵された、Ｌ１キャッシュ、Ｌ２キャッシュ、Ｌ３キャッシュ、…を含むキャッシュメモリである。

本変形例４では、地図ＤＢ更新部１２ａは、不揮発性メモリに記憶された更新要否管理ファイルの少なくとも一部を、予め定められた開始タイミングで更新要否管理ワークファイルとして高速メモリにロードする。更新要否管理ファイルの少なくとも一部は、更新要否管理ファイルの全部であってもよいし、後で説明する変形例５のように更新要否管理ファイルの一部であってもよい。なお、予め定められた開始タイミングは、例えば、地図ＤＢ更新装置１の電源オンによる立ち上げ時、メッシュファイルのバージョンアップ時、地図ＤＢ更新装置１のＣＰＵ負荷が小さいときなどを含む。

地図ＤＢ更新部１２ａは、更新要否管理ファイルの代わりに更新要否管理ワークファイルを用いて更新を行う。具体的には、地図ＤＢ更新部１２ａは、特定メッシュファイルのメッシュＩＤと、更新要否管理ワークファイルとに基づいて、地図ＤＢ記憶部３２の特定メッシュファイルを更新する。地図ＤＢ更新部１２ａは、地図ＤＢ配信サーバ６１から受信した更新ファイルなどの受信情報と、特定メッシュファイルの更新結果とに基づいて更新要否管理ワークファイルを更新する。

地図ＤＢ更新部１２ａは、予め定められた終了タイミングで、更新要否管理ワークファイルを更新要否管理ファイルの少なくとも一部として不揮発性メモリに記憶する。これにより、更新要否管理ワークファイルの更新が、更新要否管理ファイルに反映される。なお、予め定められた終了タイミングは、例えば、地図ＤＢ更新装置１の電源オフによるシャットダウン時などを含む。

図１２は、本変形例４に係る車載端末３１ａの動作のうち、地図ＤＢ更新装置１の地図ＤＢ更新部１２ａが主に行う動作を示すフローチャートである。図１２の動作は、図８の動作にステップＳ３１～Ｓ３６を追加した動作と同様である。以下、ステップＳ３１～Ｓ３６について主に説明する。

ステップＳ３１にて、地図ＤＢ更新部１２ａは、更新要否管理情報記憶部１１ａの不揮発性メモリに記憶された更新要否管理ファイルの少なくとも一部を、更新要否管理ワークファイルとして、更新要否管理情報記憶部１１ａの高速メモリにロードする。

ステップＳ２１にてバージョンが更新されたことを確認した場合には処理がステップＳ３２に進み、バージョンが更新されたことを確認しなかった場合には処理がステップＳ２３に進む。

ステップＳ３２にて、地図ＤＢ更新部１２ａは、図８のステップＳ２２と同様の処理を更新要否管理ファイルの代わりに更新要否管理ワークファイルに行う。更新要否管理ワークファイルは高速メモリにロードされているため、地図ＤＢ更新部１２ａは、ステップＳ２２の処理よりも高速でステップＳ３２の処理を行うことができる。その後、処理がステップＳ２３に進む。

ステップＳ２３にて地図更新要求を受けたと判定された場合には処理がステップＳ３３に進み、地図更新要求を受けたと判定されなかった場合には処理がステップＳ３５に進む。

ステップＳ３３にて、地図ＤＢ更新部１２ａは、図８のステップＳ２４と同様の処理を更新要否管理ファイルの代わりに更新要否管理ワークファイルに行う。更新要否管理ワークファイルは高速メモリにロードされているため、地図ＤＢ更新部１２ａは、ステップＳ２４の処理よりも高速でステップＳ３３の処理を行うことができる。

ステップＳ２５にて更新要否フラグが更新必要を示していると判定された場合には処理がステップＳ２６に進み、更新要否フラグが更新必要を示していないと判定された場合には処理がステップＳ２９に進む。

ステップＳ２６及びステップＳ２７の処理が行われた後、ステップＳ３４の処理が行われる。ステップＳ３４にて、地図ＤＢ更新部１２ａは、図８のステップＳ２８と同様の処理を更新要否管理ファイルの代わりに更新要否管理ワークファイルに行う。更新要否管理ワークファイルは高速メモリにロードされているため、地図ＤＢ更新部１２ａは、ステップＳ２８の処理よりも高速でステップＳ３４の処理を行うことができる。その後、ステップＳ２９及びステップＳ３５の処理が行われる。

ステップＳ３５にて、地図ＤＢ更新部１２ａは、予め定められた終了タイミングになったか否かを判定する。予め定められた終了タイミングになったと判定された場合には処理がステップＳ３６に進み、予め定められた終了タイミングになったと判定されなかった場合には処理がステップＳ２１に戻る。

ステップＳ３６にて、地図ＤＢ更新部１２ａは、更新要否管理ワークファイルを、更新要否管理ファイルの少なくとも一部として不揮発性メモリに記憶する。その後、図１２の動作が終了する。

以上のような本変形例４に係る地図ＤＢ更新装置１によれば、高速メモリを用いるので、更新要否管理ファイルに関する処理を高速で行うことができる。更新要否管理ファイルのサイズが小さいので、比較的小容量しか準備されていない高速メモリ、特にＬ１キャッシュ、Ｌ２キャッシュなどのキャッシュメモリに更新要否管理ワークファイルを記憶することが可能となる。

＜実施の形態２の変形例５＞
本変形例５では、変形例４と同様に高速メモリにロードなどを行う。ただし、本変形例５では、地図ＤＢ更新部１２ａは、不揮発性メモリに記憶された更新要否管理ファイルの一部であるサブ更新要否管理ファイルのみを、更新要否管理ワークファイルとして高速メモリであるキャッシュメモリにロードする。サブ更新要否管理ファイルは、更新要否管理ファイルのうち、自車両が位置するメッシュファイルである車両位置メッシュファイルを管理する部分ファイルである。

例えば複数のメッシュファイルで１つの拡大メッシュ領域を設定し、複数の拡大メッシュ領域で全国の地図領域をカバーし、拡大メッシュ領域ごとにサブ更新要否管理ファイルを設定し、全国の地図領域に更新要否管理ファイルを設定する場合を想定する。この場合、上記のように構成された本変形例５によれば、自車両が位置する拡大メッシュ領域の、自車両の移動に伴う切り替わりに応じて、キャッシュメモリに格納されるサブ更新要否管理ファイルが切り替えられる。このように、サブ更新要否管理ファイルをキャッシュメモリに格納して、サブ更新要否管理ファイルを適宜切り替え可能に構成された本変形例５によれば、サイズが比較的小さいキャッシュメモリの使用効率を高めることができる。

なお、サブ更新要否管理ファイルは、更新要否管理ファイルのうち、車両位置メッシュファイルを管理する部分ファイルに限ったものではなく、地図アプリケーション３７が要求するメッシュファイルを管理する部分ファイルであってもよい。

＜実施の形態２の変形例６＞
変形例４の高速メモリに用いられるＳｏＣのキャッシュメモリとして、ＣＰＵからのアクセスが速い順にＬ１キャッシュ、Ｌ２キャッシュ、Ｌ３キャッシュ、・・・を含むキャッシュメモリが提案されている。これらのキッシュメモリが記憶可能なデータサイズに関して、一般的に、Ｌ１＜Ｌ２＜Ｌ３＜・・・という関係が成り立つ。以下で説明する本変形例６では、このことを考慮した構成となっている。

本変形例６では、更新要否管理ワークファイルは、第１更新要否管理ワークファイルと、第２更新要否管理ワークファイルとを含む。第１更新要否管理ワークファイルは、車両位置メッシュファイルを管理し、例えば２５（＝５×５）のメッシュファイルを管理する。第２更新要否管理ワークファイルは、車両位置メッシュファイル周辺の、車両位置メッシュファイルよりも広いメッシュファイルを管理し、例えば６２５（＝２５×２５）のメッシュファイルを管理する。

高速メモリであるキャッシュメモリは、第１高速メモリと第２高速メモリとを含み、第１高速メモリは、第２高速メモリよりも処理速度が高くなっている。例えば、第１高速メモリにはＬ１キャッシュが、第２高速メモリにはＬ２キャッシュ及びＬ３キャッシュが用いられる。ただし、第１高速メモリ及び第２高速メモリには、これ以外の組み合わせが用いられてもよいし、Ｌ４キャッシュなどを組み合わせてもよい。

第１高速メモリには、サブ更新要否管理ファイルに対応する第１更新要否管理ワークファイルがロードされる。第２高速メモリには、サブ更新要否管理ファイルを除く地図をカバーする更新要否管理ファイルに対応する第２更新要否管理ワークファイルがロードされる。

以上のように構成された本変形例６によれば、地図アプリケーション３７により要求されるメッシュファイルが、その隣に移行していく通常の場合には、第１高速メモリが用いられるため更新要否の判定を高速で行うことができる。一方、地図アプリケーション３７により要求されるメッシュファイルが、その隣に移行せず、地図ＤＢへのアクセスが連続的でない場合には、第１高速メモリよりは低速であるが、不揮発性メモリなどのメインメモリより高速である第２高速メモリが用いられる。このため、この場合であっても更新要否管理ファイルに関する処理をある程度高速で行うことができる。特に、地図アプリケーション３７がＡＤＡＳアプリケーションやＡＤアプリケーションである場合、自車両が、自車両の経路である走行ルート上を連続的に移動していくことに合わせて、要求されるメッシュファイルが移行するので上記効果は有効である。

＜実施の形態３＞
図１３は、本実施の形態３に係る地図データ更新装置である地図ＤＢ更新装置１を備える車両制御装置３１ｂなどの構成を示すブロック図である。以下、本実施の形態３に係る構成要素のうち、上述の構成要素と同じまたは類似する構成要素については同じまたは類似する参照符号を付し、異なる構成要素について主に説明する。

本実施の形態３に係る車両制御装置３１ｂの構成は、実施の形態２に係る車載端末３１ａ（図３）の構成において、走行制御部３８及び周辺検出センサ３９が追加された構成と同様である。

また本実施の形態３に係る地図ＤＢ記憶部３２の地図ＤＢは、上述した通常精度地図ＤＢ及び高精度地図ＤＢだけでなく、周辺検出センサ３９で検出された情報を用いて自車両の位置を特定するための施設地図データである施設地図ＤＢを含んでいる。

図１４は、本実施の形態３に係るメッシュ領域を示す図である。図１４（ａ）は高精度地図ＤＢのメッシュ領域を示し、図１４（ｂ）は通常精度地図ＤＢのメッシュ領域を示し、図１４（ｃ）は施設地図ＤＢのメッシュ領域を示す。図１４（ａ）～図１４（ｃ）に示すように、本実施の形態３では、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのメッシュのサイズ（メッシュ領域の広さ）は互いに同じであり、それらのメッシュファイルは１つの更新要否管理ファイルで管理される。そして、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのメッシュについて、特定メッシュファイル及び更新要否管理ファイルは一括して更新される。

地図アプリケーション３７は、自車両位置検出部３５が測位データとセンサ情報とに基づいて検出した自車両の位置と、通常精度地図ＤＢとに基づいて、走行経路（自車両が走行する経路）を探索（推定）する。走行経路の探索には、例えば一般的なナビゲーション装置と同様の探索機能が用いられる。地図ＤＢアクセス部３６は、地図アプリケーション３７から取得した走行経路の情報に基づいて、当該走行経路上のメッシュファイル、その周辺メッシュファイル、及び、走行経路の前方のメッシュファイルの少なくともいずれか１つを特定メッシュファイルとして特定する。このとき、走行経路の情報は、リンクＩＤ、リンク形状、分岐点の座標のいずれかの情報、または、その他の走行経路に対応したメッシュファイルを特定可能な情報であればよい。

実施の形態２と同様に、地図ＤＢアクセス部３６は、特定メッシュファイルの地図更新要求を、地図ＤＢ更新装置１の地図ＤＢ更新部１２ａに出力する。地図更新要求を受けた地図ＤＢ更新部１２ａは、特定メッシュファイルを適宜更新する処理を行う。地図ＤＢアクセス部３６は、地図ＤＢ更新部１２ａによる処理が行われた後の施設地図ＤＢを自車両位置検出部３５に出力する。また、地図ＤＢアクセス部３６は、地図ＤＢ更新部１２ａによる処理が行われた後の高精度地図ＤＢを地図アプリケーション３７に出力する。

車両のセンサである周辺検出センサ３９は、自車両周辺の情報を検出する。周辺検出センサ３９には、例えばカメラが撮影した自車両周辺の画像を認識する画像認識センサ、及び、ＬｉＤＡＲ（light detection and ranging）などが用いられる。

自車両位置検出部３５は、地図ＤＢ更新部１２ａによる処理が行われた後の施設地図ＤＢと、周辺検出センサ３９で検出された自車両周辺の情報とに基づいて、自車両の走行の制御に用いられる自車両の位置を検出する。例えば、自車両位置検出部３５は、施設地図ＤＢに格納された施設の形状と、周辺検出センサ３９で検出された画像認識結果とを照合して、車線単位の自車両の位置を検出する。このようにして検出された自車両の位置の精度は、衛星測位装置３３の測位データと、車両センサ３４のセンサ情報とに基づいて検出された自車両の位置の精度よりも高い。なお、施設地図ＤＢと、周辺検出センサ３９の自車両周辺の情報とに基づいて検出された自車両の位置は、当該自車両の位置検出後の走行経路の探索に用いられてもよい。

以下、地図アプリケーション３７が、施設地図ＤＢと、周辺検出センサ３９の自車両周辺の情報とに基づいて自車両位置検出部３５で検出された自車両の位置を取得し、当該自車両の位置を走行制御部３８に出力する構成について説明する。ただしこれに限ったものではなく、自車両位置検出部３５が自車両の位置を走行制御部３８に直接出力する構成であってもよい。

地図アプリケーション３７は、自車両位置検出部３５からの自車両の位置と、地図ＤＢ更新部１２ａによる処理が行われた後の高精度地図ＤＢとに基づいて、自車両の前方または周辺の道路情報を、走行制御部３８に出力する。自車両の前方の道路情報には、例えば車線の形状や看板の位置情報などが含まれ、出力の形式は自車両を原点とした相対座標としてもよい。

走行制御部３８は、地図アプリケーション３７からの出力情報に基づいて自車両の走行を制御する。つまり、地図ＤＢ更新部１２ａによる処理が行われた後の前記高精度地図データは、間接的に車両の走行の制御に用いられる。走行制御部３８には、例えば車線単位の制御が可能なＡＤＡＳ ＥＣＵ（Electronic Control Unit）及びＡＤ ＥＣＵ（Electronic Control Unit）などが用いられる。

＜動作＞
図１５及び図１６は、本実施の形態３に係る車両制御装置３１ｂの動作を示すフローチャートである。まず図１５を用いて、走行制御部３８が主に行う動作について説明する。

ステップＳ４１にて、走行制御部３８は、地図アプリケーション３７及び地図ＤＢ更新部１２ａによる処理が行われた後の施設地図ＤＢに基づく自車両の位置を取得する。また、走行制御部３８は、地図アプリケーション３７から、地図ＤＢ更新部１２ａによる処理が行われた後の高精度地図ＤＢに基づいて抽出された自車前方または周辺の道路情報を取得する。

ステップＳ４２にて、走行制御部３８は、自車両の位置及び道路情報に基づいて自車両の走行を制御する。

ステップＳ４３にて、走行制御部３８は、自車両の駆動源が停止したか否かを判定する。駆動源が停止したと判定された場合には図１５の動作が終了し、駆動源が停止したと判定されなかった場合には処理がステップＳ４１に戻る。

次に図１６を用いて、地図アプリケーション３７が主に行う動作について説明する。

ステップＳ５１にて、自車両位置検出部３５は、衛星測位装置３３の測位データと、車両センサ３４のセンサ情報とに基づいて、自車両の位置を検出する。

ステップＳ５２にて、地図アプリケーション３７は、自車両の位置と、通常精度地図ＤＢとに基づいて走行経路を探索する。走行経路の探索に用いられる自車両の位置には、ステップＳ５１で検出される自車両の位置が用いられてもよい。

ステップＳ５３にて、地図アプリケーション３７は、走行経路の情報を地図ＤＢアクセス部３６に出力する。

ステップＳ５４にて、地図アプリケーション３７は、ステップＳ５（図６）と同様のアプリケーション終了判定の処理を行う。

次に図１７を用いて、地図ＤＢアクセス部３６が主に行う動作について説明する。

ステップＳ６１にて、地図ＤＢアクセス部３６は、走行経路の情報を地図アプリケーション３７から取得する。ただし、これに限らず経路情報は車両システム上のナビゲーション装置、外部のスマートフォンデバイスやサーバアプリケーションなどから取得してもよい。

ステップＳ６２にて、地図ＤＢアクセス部３６は、走行経路の情報に基づいて、当該走行経路上の高精度地図ＤＢのメッシュファイル、その周辺メッシュファイル、及び、走行経路の前方のメッシュファイルの少なくともいずれか１つを特定メッシュファイルとして選定（特定）する。

ステップＳ６３にて、地図ＤＢアクセス部３６は、特定メッシュファイルの地図更新要求を地図ＤＢ更新部１２ａに出力する。その後、処理がステップＳ６１に戻る。この際、図７のステップＳ１３～Ｓ１５と同様の処理が行われてもよい。

地図ＤＢアクセス部３６にて、図１７の処理を図７の処理に先んじて行うことで、地図アプリケーション３７からメッシュファイルの要求を受けた際に、特定メッシュファイルを地図アプリケーション３７に出力するまでのレスポンスが向上する。

地図ＤＢ更新装置１の地図ＤＢ更新部１２ａが主に行う動作については、実施の形態２の動作（図８）と同様であるため、詳細な説明は省略する。ただし、本実施の形態３では、ステップＳ２５及ぶステップＳ２６の処理は、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢについて行われる。

＜実施の形態３のまとめ＞
以上のような本実施の形態３によれば、地図ＤＢ更新部１２ａによる処理が行われた後の高精度地図データが、自車両の走行の制御に用いられ、地図ＤＢ更新部１２ａによる処理が行われた後の施設地図データが、自車両の位置の検出に用いられる。これにより、更新についてリアルタイム性が高められたデータを、ＡＤＡＳやＡＤなどの自車両の走行の制御に用いることができる。

＜実施の形態３の変形例１＞
実施の形態３では、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのメッシュファイルが、１つの更新要否管理ファイルによって管理された。しかしながら、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのメッシュファイルが同時に更新されるとは限らない。

そこで、３つの更新要否管理ファイルが、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢにそれぞれ割り当てられることにより、３種類の地図ＤＢにおいて個別に更新要否が設定されてもよい。そして、地図ＤＢ更新部１２ａは、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢの全てにおいて個別に、特定メッシュファイル及び更新要否管理ファイルを更新してもよい。

または、１つの更新要否管理ファイルが、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのいずれか２つに割り当てられ、別の更新要否管理ファイルが、残りの１つに割り当てられることにより、２種類の地図ＤＢの更新要否と、１種類の地図ＤＢの更新要否とが個別に設定されてもよい。そして、地図ＤＢ更新部１２ａは、２種類の地図ＤＢと１種類の地図ＤＢとにおいて個別に、特定メッシュファイル及び更新要否管理ファイルを更新してもよい。

また、施設地図ＤＢは施設区分ごとに更新要否管理ファイルに格納されることにより、複数の施設区分を有する施設地図ＤＢが、複数の更新要否管理ファイルに格納されてもよい。

＜実施の形態３の変形例２＞
実施の形態３では、図１４のように通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのメッシュのサイズは互いに同じであったが、これに限ったものではない。例えば、図１８に示すように、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのうちの３つにおいて、メッシュのサイズが互いに異なってもよい。

図１８は、本変形例２に係るメッシュ領域を示す図である。図１８（ａ）は高精度地図ＤＢのメッシュ領域を示し、図１８（ｂ）は通常精度地図ＤＢのメッシュ領域を示し、図１８（ｃ）は施設地図ＤＢのメッシュ領域を示す。図１８では、高精度地図ＤＢのメッシュのサイズが最も小さく、施設地図ＤＢのメッシュのサイズが最も大きいが、これに限ったものではない。

なお、メッシュのサイズは、地図ＤＢの種類ではなく、地図ＤＢのデータサイズ及びや更新頻度に基づいて設定されてもよい。例えばデータサイズが大きいほどメッシュのサイズが小さく設定されてもよいし、更新頻度が多いほどメッシュのサイズが小さく設定されてもよい。また、通常精度地図ＤＢ、高精度地図ＤＢ、及び、施設地図ＤＢのうちの３つではなく２つにおいて、メッシュのサイズが互いに異なってもよい。

＜実施の形態３の変形例３＞
本変形例３では、実施の形態３に係る更新要否管理情報記憶部１１ａが、実施の形態２の変形例４のように、高速メモリを含む。ただし、本変形例３の高速メモリは、処理速度が互いに異なる第１、第２及び第３高速メモリを含む。なお、第１高速メモリの処理速度が最も高く、第３高速メモリの処理速度が最も低い。

本変形例３では、更新要否管理ファイルに対応する更新要否管理ワークファイルは、高精度地図ＤＢ、施設地図ＤＢ、及び、通常精度地図ＤＢの複数のメッシュファイルにそれぞれ用いられる第１、第２及び第３更新要否管理ワークファイルを含む。そして、処理速度が最も高い第１高速メモリには、高精度地図ＤＢを管理する更新要否管理ファイルが第１更新要否管理ワークファイルとしてロードされる。第２高速メモリには、施設地図ＤＢを管理する更新要否管理ファイルが第２更新要否管理ワークファイルとしてロードされる。処理速度が最も低い第３高速メモリには、通常精度地図ＤＢを管理する更新要否管理ファイルが第３更新要否管理ワークファイルとしてロードされる。そして、第１、第２及び第３更新要否管理ワークファイルに対して実施の形態２の変形例４と同様の動作（図１２）が行われる。

このような本変形例３によれば、サイズが比較的小さいキャッシュメモリの使用効率を高めることができる。

＜実施の形態４＞
図１９は、本実施の形態４に係る地図データ更新装置である地図ＤＢ更新装置１を備える車両制御装置３１ｂなどの構成を示すブロック図である。以下、本実施の形態４に係る構成要素のうち、上述の構成要素と同じまたは類似する構成要素については同じまたは類似する参照符号を付し、異なる構成要素について主に説明する。

本実施の形態４に係る地図ＤＢ更新装置１は、地図ＤＢ記憶部３２及び地図ＤＢアクセス部３６をさらに備える点で、実施の形態３に係る地図ＤＢ更新装置１（図１３）と異なる。このような構成であっても、実施の形態３と同様の効果が得られる。なお、地図ＤＢ更新装置１の構成は、図１３の構成及び図１９の構成に限ったものではない。例えば、車両制御装置３１ｂの地図ＤＢ更新装置１は、地図ＤＢ記憶部３２、自車両位置検出部３５及び地図ＤＢアクセス部３６の少なくともいずれか１つをさらに備える構成であってもよい。すなわち、車両制御装置３１ｂの地図ＤＢ更新装置１は、図１３の車両制御装置３１ｂの構成要素のうち地図ＤＢ更新装置１以外の構成要素をさらに備える構成であってもよい。

なお、本実施の形態４は、実施の形態３で説明した車両制御装置３１ｂ（図１３）を変更した構成であったが、実施の形態２で説明した車載端末３１ａ（図３）に同様の変更が行われた構成であってもよい。例えば、車載端末３１ａの地図ＤＢ更新装置１は、地図ＤＢ記憶部３２、自車両位置検出部３５及び地図ＤＢアクセス部３６の少なくともいずれか１つをさらに備える構成であってもよい。すなわち、車載端末３１ａの地図ＤＢ更新装置１は、図３の車載端末３１ａの構成要素のうち地図ＤＢ更新装置１以外の構成要素をさらに備える構成であってもよい。

＜その他の変形例＞
上述した図１の記憶部１１及び更新部１２を、以下「更新部１２等」と記す。更新部１２等は、図２０に示す処理回路８１により実現される。すなわち、処理回路８１は、更新要否管理ファイルを記憶する記憶部１１と、特定メッシュファイルのメッシュＩＤと、更新要否管理ファイルとに基づいて特定メッシュファイルを更新し、かつ、特定メッシュファイルの更新結果と、地図ＤＢ配信サーバ６１から受信した受信情報とに基づいて更新要否管理ファイルを更新する更新部１２と、を備える。処理回路８１には、専用のハードウェアが適用されてもよいし、メモリに格納されるプログラムを実行するプロセッサが適用されてもよい。プロセッサには、例えば、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、ＤＳＰ（Digital Signal Processor）などが該当する。

処理回路８１が専用のハードウェアである場合、処理回路８１は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、またはこれらを組み合わせたものが該当する。更新部１２等の各部の機能それぞれは、処理回路を分散させた回路で実現されてもよいし、各部の機能をまとめて一つの処理回路で実現されてもよい。

処理回路８１がプロセッサである場合、更新部１２等の機能は、ソフトウェア等との組み合わせにより実現される。なお、ソフトウェア等には、例えば、ソフトウェア、ファームウェア、または、ソフトウェア及びファームウェアが該当する。ソフトウェア等はプログラムとして記述され、メモリに格納される。図２１に示すように、処理回路８１に適用されるプロセッサ８２は、メモリ８３に記憶されたプログラムを読み出して実行することにより、各部の機能を実現する。すなわち、地図ＤＢ更新装置１は、処理回路８１により実行されるときに、更新要否管理ファイルを記憶するステップと、特定メッシュファイルのメッシュＩＤと、更新要否管理ファイルとに基づいて特定メッシュファイルを更新し、かつ、特定メッシュファイルの更新結果と、地図ＤＢ配信サーバ６１から受信した受信情報とに基づいて更新要否管理ファイルを更新するステップと、が結果的に実行されることになるプログラムを格納するためのメモリ８３を備える。換言すれば、このプログラムは、更新部１２等の手順や方法をコンピュータに実行させるものであるともいえる。ここで、メモリ８３は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）などの、不揮発性または揮発性の半導体メモリ、ＨＤＤ（Hard Disk Drive）、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ（Digital Versatile Disc）、そのドライブ装置等、または、今後使用されるあらゆる記憶媒体であってもよい。

以上、更新部１２等の各機能が、ハードウェア及びソフトウェア等のいずれか一方で実現される構成について説明した。しかしこれに限ったものではなく、更新部１２等の一部を専用のハードウェアで実現し、別の一部をソフトウェア等で実現する構成であってもよい。例えば、更新部１２については専用のハードウェアとしての処理回路８１、及び、インターフェースなどでその機能を実現し、それ以外についてはプロセッサ８２としての処理回路８１がメモリ８３に格納されたプログラムを読み出して実行することによってその機能を実現することが可能である。

以上のように、処理回路８１は、ハードウェア、ソフトウェア等、またはこれらの組み合わせによって、上述の各機能を実現することができる。

また、以上で説明した地図ＤＢ更新装置１は、ＰＮＤ（Portable Navigation Device）、ナビゲーション装置、ＡＤＡＳ機能やＡＤ機能を行うための走行制御装置などの車両装置と、携帯電話、スマートフォン及びタブレットなどの携帯端末を含む通信端末と、車両装置及び通信端末の少なくとも１つにインストールされるアプリケーションの機能と、サーバとを適宜に組み合わせてシステムとして構築される地図ＤＢ更新システムにも適用することができる。この場合、以上で説明した地図ＤＢ更新装置１の各機能あるいは各構成要素は、前記システムを構築する各機器に分散して配置されてもよいし、いずれかの機器に集中して配置されてもよい。

なお、各実施の形態及び各変形例を自由に組み合わせたり、各実施の形態及び各変形例を適宜、変形、省略したりすることが可能である。

上記した説明は、すべての局面において、例示であって、限定的なものではない。例示されていない無数の変形例が、想定され得るものと解される。

１ 地図ＤＢ更新装置、１１ 記憶部、１２ 更新部、３２ 地図ＤＢ記憶部、３５ 自車両位置検出部、３６ 地図ＤＢアクセス部、６１ 地図ＤＢ配信サーバ。

Claims (15)

1. それぞれが、地図データを区分して得られる複数のメッシュの１つ以上に対応する複数のメッシュファイルを、サーバと通信を行うことによって選択的に更新する地図データ更新装置であって、
   複数のビットの位置が前記複数のメッシュファイルのメッシュＩＤと対応付けられたビット配列を有し、前記メッシュファイルの更新の要否を示す１ビットのフラグ情報が、前記ビット配列のうち当該メッシュファイルのメッシュＩＤに対応する前記位置に格納された更新要否管理ファイルを記憶する記憶部と、
   前記複数のメッシュファイルのうち車両で用いられる対象として特定されたメッシュファイルである特定メッシュファイルのメッシュＩＤと、前記更新要否管理ファイルとに基づいて前記特定メッシュファイルを更新し、かつ、前記特定メッシュファイルの更新結果と、更新ファイルとに基づいて前記更新要否管理ファイルを更新する更新部と
   を備え、
   前記更新ファイルは、
   第１バージョンの前記地図データと、前記第１バージョンの１つ前の第２バージョンの前記地図データとの間の差に基づいて前記メッシュファイルの更新の要否が設定される、または、
   前記複数のメッシュファイルのそれぞれのバージョンが格納されたバージョン管理ファイルに関して、第１バージョンの前記バージョン管理ファイルと、前記第１バージョンの１つ前の第２バージョンの前記バージョン管理ファイルとの間の差に基づいて前記メッシュファイルの更新の要否が設定される、地図データ更新装置。
2. 請求項１に記載の地図データ更新装置であって、
   前記サーバからの受信情報は、
   前記第１バージョンの前記地図データと、前記第２バージョンの前記地図データとの間の差に基づいて前記メッシュファイルの更新の要否が設定された、前記更新要否管理ファイルと同一データ形式の前記更新ファイルを含み、
   前記更新部は、
   前記更新ファイルと前記更新要否管理ファイルとに基づいて、前記更新要否管理ファイルを更新するビット演算を行う、地図データ更新装置。
3. 請求項１に記載の地図データ更新装置であって、
   前記サーバからの受信情報は、前記バージョン管理ファイルを含み、
   前記更新部は、
   前記第１バージョンの前記バージョン管理ファイルと、前記第２バージョンの前記バージョン管理ファイルとの間の差に基づいて前記メッシュファイルの更新の要否が設定された、前記更新要否管理ファイルと同一データ形式の前記更新ファイルを生成し、前記更新ファイルと前記更新要否管理ファイルとに基づいて、前記更新要否管理ファイルを更新するビット演算を行う、地図データ更新装置。
4. 請求項２に記載の地図データ更新装置であって、
   前記更新部は、
   前記更新要否管理ファイルにおいて、値が１である前記フラグ情報が更新必要を示し、値が０である前記フラグ情報が更新不要を示す場合には、前記ビット演算としてビット単位のＯＲ処理を行い、前記更新要否管理ファイルにおいて、値が０である前記フラグ情報が更新必要を示し、値が１である前記フラグ情報が更新不要を示す場合には、前記ビット演算としてビット単位のＡＮＤ処理を行う、地図データ更新装置。
5. 請求項１に記載の地図データ更新装置であって、
   前記記憶部は、不揮発性メモリと、前記不揮発性メモリよりも処理速度が高い高速メモリとを含み、
   前記更新部は、
   前記不揮発性メモリに記憶された前記更新要否管理ファイルの少なくとも一部を、予め定められた開始タイミングで更新要否管理ワークファイルとして前記高速メモリにロードし、
   前記特定メッシュファイルのメッシュＩＤと、前記更新要否管理ワークファイルとに基づいて前記特定メッシュファイルを更新し、
   前記サーバから受信した受信情報と、前記特定メッシュファイルの更新結果とに基づいて前記更新要否管理ワークファイルを更新し、
   予め定められた終了タイミングで、前記更新要否管理ワークファイルを前記更新要否管理ファイルの前記少なくとも一部として前記不揮発性メモリに記憶する、地図データ更新装置。
6. 請求項５に記載の地図データ更新装置であって、
   前記更新要否管理ファイルの前記少なくとも一部は、前記更新要否管理ファイルの一部であり、
   前記更新要否管理ファイルの一部は、前記車両が位置する前記メッシュファイルである車両位置メッシュファイルを管理する部分ファイルを含む、地図データ更新装置。
7. 請求項５に記載の地図データ更新装置であって、
   前記更新要否管理ワークファイルは、
   前記車両が位置する前記メッシュファイルである車両位置メッシュファイルを管理する第１更新要否管理ワークファイルと、
   前記車両位置メッシュファイル周辺の、前記車両位置メッシュファイルよりも広い前記メッシュファイルを管理する第２更新要否管理ワークファイルと
   を含み、
   前記高速メモリは、
   前記第１更新要否管理ワークファイルがロードされる第１高速メモリと、
   前記第２更新要否管理ワークファイルがロードされる第２高速メモリと
   を含み、
   前記第１高速メモリは、前記第２高速メモリよりも処理速度が高い、地図データ更新装置。
8. 請求項１に記載の地図データ更新装置であって、
   前記地図データは、
   通常精度地図データと、
   前記通常精度地図データよりも高精度である高精度地図データと、
   前記車両の位置を特定するための施設地図データと
   を含む、地図データ更新装置。
9. 請求項８に記載の地図データ更新装置であって、
   前記更新部は、
   前記通常精度地図データ、前記高精度地図データ、及び、前記施設地図データのうちの少なくとも２つにおいて個別に、前記特定メッシュファイル及び前記更新要否管理ファイルを更新する、地図データ更新装置。
10. 請求項９に記載の地図データ更新装置であって、
    前記通常精度地図データ、前記高精度地図データ、及び、前記施設地図データのうちの少なくとも２つにおいて、前記メッシュのサイズが互いに異なる、地図データ更新装置。
11. 請求項５に記載の地図データ更新装置であって、
    前記地図データは、
    通常精度地図データと、
    前記通常精度地図データよりも高精度である高精度地図データと、
    前記車両の位置を特定するための施設地図データと
    を含み、
    前記更新要否管理ワークファイルは、
    前記高精度地図データ、前記施設地図データ、及び、前記通常精度地図データの前記複数のメッシュファイルをそれぞれ管理する第１、第２及び第３更新要否管理ワークファイルを含み、
    前記高速メモリは、
    前記第１、第２及び第３更新要否管理ワークファイルがロードされ、処理速度が互いに異なる第１、第２及び第３高速メモリを含む、地図データ更新装置。
12. 請求項８に記載の地図データ更新装置であって、
    前記通常精度地図データに基づいて、前記車両が走行する経路を探索し、前記経路に基づいて前記特定メッシュファイルを特定する地図データアクセス部をさらに備え、
    前記更新部による処理が行われた後の前記高精度地図データが、前記車両の走行の制御に用いられる、地図データ更新装置。
13. 請求項８に記載の地図データ更新装置であって、
    前記更新部による処理が行われた後の前記施設地図データと、前記車両のセンサで検出された前記車両周辺の情報とに基づいて、前記車両の走行の制御に用いられる前記車両の位置を検出する車両位置検出部をさらに備える、地図データ更新装置。
14. 請求項１に記載の地図データ更新装置であって、
    前記地図データを記憶する地図データ記憶部をさらに備える、地図データ更新装置。
15. それぞれが、地図データを区分して得られる複数のメッシュの１つ以上に対応する複数のメッシュファイルを、サーバと通信を行うことによって選択的に更新する地図データ更新装置の地図データ更新方法であって、
    複数のビットの位置が前記複数のメッシュファイルのメッシュＩＤと対応付けられたビット配列を有し、前記メッシュファイルの更新の要否を示す１ビットのフラグ情報が、前記ビット配列のうち当該メッシュファイルのメッシュＩＤに対応する前記位置に格納された更新要否管理ファイルを記憶し、
    前記複数のメッシュファイルのうち車両で用いられる対象として特定されたメッシュファイルである特定メッシュファイルのメッシュＩＤと、前記更新要否管理ファイルとに基づいて前記特定メッシュファイルを更新し、かつ、前記特定メッシュファイルの更新結果と、更新ファイルとに基づいて前記更新要否管理ファイルを更新し、
    前記更新ファイルは、
    第１バージョンの前記地図データと、前記第１バージョンの１つ前の第２バージョンの前記地図データとの間の差に基づいて前記メッシュファイルの更新の要否が設定される、または、
    前記複数のメッシュファイルのそれぞれのバージョンが格納されたバージョン管理ファイルに関して、第１バージョンの前記バージョン管理ファイルと、前記第１バージョンの１つ前の第２バージョンの前記バージョン管理ファイルとの間の差に基づいて前記メッシュファイルの更新の要否が設定される、地図データ更新方法。

Images