特許 7662042 地図更新システム、車載器、および、サーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-04-07

(45)【発行日】2025-04-15

(54)【発明の名称】地図更新システム、車載器、および、サーバ

(51)【国際特許分類】

   G09B 29/00 20060101AFI20250408BHJP

【ＦＩ】

G09B29/00 Z

【請求項の数】 11

(21)【出願番号】P 2023545618

(86)(22)【出願日】2022-08-30

(86)【国際出願番号】 JP2022032663

(87)【国際公開番号】W WO2023033004

(87)【国際公開日】2023-03-09

【審査請求日】2023-11-02

(31)【優先権主張番号】P 2021144044

(32)【優先日】2021-09-03

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【氏名又は名称】矢作 和行

(74)【代理人】

【識別番号】100121991

【弁理士】

【氏名又は名称】野々部 泰平

(74)【代理人】

【識別番号】100145595

【弁理士】

【氏名又は名称】久保 貴則

(72)【発明者】

【氏名】阿部 真也

(72)【発明者】

【氏名】堀畑 智

(72)【発明者】

【氏名】寺澤 智仁

【審査官】池田 剛志

(56)【参考文献】

【文献】特開２０２０－０３８３５９（ＪＰ，Ａ）

【文献】国際公開第２０１９／１３１９０３（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１９／００１９４０９（ＵＳ，Ａ１）

【文献】特開２０１７－０９０５４８（ＪＰ，Ａ）

【文献】特開２００７－０５１９７３（ＪＰ，Ａ）

【文献】特開２０１８－１０５７７４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０９Ｂ２３／００－２９／１４

(57)【特許請求の範囲】

【請求項1】

車両（２）に搭載されている記憶部（３０）に記憶され、前記車両の挙動を制御する車両制御部（５０）が使用する地図情報を更新する必要があるか否かを判断する地図更新システム（１）であって、
前記車両制御部が実行する車両制御に不具合があるか否かを判断する不具合判断部（６１）を備え、複数の前記車両にそれぞれ搭載される複数の車載器（６０）と、
前記不具合の原因が前記地図情報にあると判断したことに基づいて、前記地図情報を更新する必要があると判断する更新判断部（８６）を備え、前記車載器と通信するサーバ（８０）と、を備え、
前記不具合判断部は、前記車両制御に不具合があるか否かを判断した情報である不具合判断結果情報を車両側通信部（４０）から前記サーバに送信し、
前記サーバは、
前記車両から受信した前記不具合判断結果情報に基づいて、前記不具合の原因を検査するか否かを判断する検査要否判断部（８４）と、
前記検査要否判断部が、前記不具合の原因を検査すると判断した場合に、前記不具合の原因を検査することを指示する検査指示を、１つ以上の前記車載器へ送信する検査指示部（８５）と、を備え、
前記車載器は、
前記検査指示を受信した場合に、前記記憶部に記憶されている前記地図情報と、前記車両に搭載されている周辺検出センサ（２１）により検出される情報から作成する認識地図情報とを比較することで、前記記憶部に記憶されている前記地図情報が正しいかを検査し、検査結果を前記車両側通信部から前記サーバに送信する検査部（６２）を備え、
前記更新判断部は、前記車両から送信された前記検査結果に基づいて前記地図情報の更新が必要であるか否かを判断する、地図更新システム。

【請求項2】

請求項１に記載の地図更新システムであって、
前記不具合判断部は、前記車両のドライバが、前記車両制御部による車両制御を変更する車両操作をしたことに基づいて、前記車両制御部が実行する車両制御に不具合があると判断する、地図更新システム。

【請求項3】

請求項１または２に記載の地図更新システムであって、
前記不具合判断結果情報には、前記車両制御の内容を特定する情報が含まれる、地図更新システム。

【請求項4】

請求項１または２に記載の地図更新システムであって、
前記不具合判断結果情報には、不具合が生じたときの前記車両の位置を特定する位置特定情報が含まれる、地図更新システム。

【請求項5】

請求項１または２に記載の地図更新システムであって、
前記検査要否判断部は、複数の前記車両から前記不具合判断結果情報を取得した場合に、複数の前記不具合判断結果情報を統計処理して、前記不具合の原因を検査するか否かを判断する、地図更新システム。

【請求項6】

請求項１または２に記載の地図更新システムであって、
前記更新判断部は、複数の前記車両から送信された前記検査結果を統計処理して、前記不具合の原因が前記地図情報にあるか否かを判断する、地図更新システム。

【請求項7】

請求項６に記載の地図更新システムであって、
前記更新判断部の判断により前記地図情報に不具合の原因がある場合に、地図情報の利用を停止する、地図更新システム。

【請求項8】

請求項６に記載の地図更新システムであって、
前記更新判断部の判断により前記地図情報に不具合の原因がある場合に、前記車両の自動運転または運転支援に関するアプリケーションの利用を停止する地図更新システム。

【請求項9】

請求項６に記載の地図更新システムであって、
前記更新判断部の判断により前記地図情報に不具合の原因がなく、前記車両の自動運転または運転支援に関するアプリケーションに不具合がある場合に、前記アプリケーションを停止する地図更新システム。

【請求項10】

車両（２）に搭載されている記憶部（３０）に記憶されている地図情報を使用して前記車両の挙動を制御する車両制御部（５０）が実行する車両制御に不具合があるか否かを判断し、判断結果を示す不具合判断結果情報を車両側通信部（４０）からサーバ（８０）に送信する不具合判断部（６１）と、
前記サーバから検査指示を受信した場合に、前記記憶部に記憶されている前記地図情報と、前記車両に搭載されている周辺検出センサ（２１）により検出される情報から作成する認識地図情報とを比較することで、前記記憶部に記憶されている前記地図情報が正しいかを検査し、検査結果を前記車両側通信部から前記サーバに送信する検査部（６２）を備える車載器。

【請求項11】

車両（２）に搭載されている記憶部（３０）に記憶されている地図情報を使用して前記車両の挙動を制御する車両制御部（５０）による車両制御に不具合があるか否かを判断した情報である不具合判断結果情報を、前記車両から受信し、前記不具合判断結果情報に基づいて、前記不具合の原因を検査するか否かを判断する検査要否判断部（８４）と、
前記検査要否判断部が、前記不具合の原因を検査すると判断した場合に、前記不具合の原因を検査することを指示する検査指示を、１つ以上の車載器（６０）へ送信する検査指示部（８５）と、
複数の前記車両から前記不具合判断結果情報を取得した場合に、複数の前記不具合判断結果情報を統計処理して、前記不具合の原因が前記地図情報にあるか否かを判断し、前記不具合の原因が前記地図情報にあると判断したことに基づいて、前記地図情報を更新すると判断する更新判断部（８６）と、を備えるサーバ。

【発明の詳細な説明】

【関連出願の相互参照】

【0001】

この出願は、２０２１年９月３日に日本に出願された特許出願第２０２１－１４４０４４号を基礎としており、基礎の出願の内容を、全体的に、参照により援用している。

【技術分野】

【0002】

地図更新システム、その地図更新システムが備える車載器およびサーバに関する。

【背景技術】

【0003】

特許文献１に記載されている装置は、車両に搭載された外界センサで検出した地物の位置および形状等と、地図データとして記憶部に記憶されている地物情報とを比較する。そして、外界センサで検出した地物に変化があると判断した場合には、差異情報をサーバへ送信する。サーバは、その差異情報をもとに高度化地図データベースを更新する。

【先行技術文献】

【特許文献】

【0004】

【文献】国際公開第２０１７／２１２６３９号

【発明の概要】

【0005】

特許文献１では、高度化地図データベースに含まれている地物情報が、実際に現地を走行した車両に搭載されたセンサで検出した地図の位置および形状等と相違している場合に、高度化地図データベースを更新する。しかし、地図情報が、実際の道路、地物などを正しく表していないとしても、必ずしも地図情報を更新しなければならない訳ではない。地図情報を車両の挙動を制御するために使用する場合、車両制御に影響がなければ、必ずしも地図情報を更新する必要はない。必須ではないにも関わらず地図情報を常に更新してしまうと、地図情報の更新の手間が増える恐れがある。

【0006】

本開示は、この事情に基づいて成されたものであり、その目的とするところは、必須ではない地図情報の更新を抑制できる地図更新システム、車載器、および、サーバを提供することにある。

【0007】

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的態様との対応関係を示すものであって、開示した技術的範囲を限定するものではない。

【0008】

上記目的を達成するための地図更新システムに係る１つの開示は、
車両に搭載されている記憶部に記憶され、車両の挙動を制御する車両制御部が使用する地図情報を更新する必要があるか否かを判断する地図更新システムであって、
車両制御部が実行する車両制御に不具合があるか否かを判断する不具合判断部を備え、複数の車両にそれぞれ搭載される複数の車載器と、
不具合の原因が地図情報にあると判断したことに基づいて、地図情報を更新する必要があると判断する更新判断部を備え、車載器と通信するサーバと、を備え、
不具合判断部は、車両制御に不具合があるか否かを判断した情報である不具合判断結果情報を車両側通信部からサーバに送信し、
サーバは、
車両から受信した不具合判断結果情報に基づいて、不具合の原因を検査するか否かを判断する検査要否判断部と、
検査要否判断部が、不具合の原因を検査すると判断した場合に、不具合の原因を検査することを指示する検査指示を、１つ以上の車載器へ送信する検査指示部と、を備え、
車載器は、
検査指示を受信した場合に、記憶部に記憶されている地図情報と、車両に搭載されている周辺検出センサにより検出される情報から作成する認識地図情報とを比較することで、記憶部に記憶されている地図情報が正しいかを検査し、検査結果を車両側通信部からサーバに送信する検査部を備え、
更新判断部は、車両から送信された検査結果に基づいて地図情報の更新が必要であるか否かを判断する地図更新システムである。

【0009】

この地図更新システムは、車両制御部が実行する車両制御の不具合の原因が地図情報にあると判断したことに基づいて、地図情報を更新する必要があると判断する。そのため、車両制御部が実行する車両制御に不具合がなければ、地図情報が最新でなくても、地図情報を更新する必要がないという判断が可能になる。よって、必須ではない地図情報の更新を抑制できる。

【0012】

上記目的を達成する車載器およびサーバは、この地図更新システムが備える車載器とサーバである。

【0013】

すなわち、車載器は、車両に搭載されている記憶部に記憶されている地図情報を使用して車両の挙動を制御する車両制御部が実行する車両制御に不具合があるか否かを判断し、判断結果を示す不具合判断結果情報を車両側通信部からサーバに送信する不具合判断部と、
サーバから検査指示を受信した場合に、記憶部に記憶されている地図情報と、車両に搭載されている周辺検出センサにより検出される情報から作成する認識地図情報とを比較することで、記憶部に記憶されている地図情報が正しいかを検査し、検査結果を車両側通信部からサーバに送信する検査部を備える車載器である。

【0014】

また、サーバは、車両に搭載されている記憶部に記憶されている地図情報を使用して車両の挙動を制御する車両制御部による車両制御に不具合があるか否かを判断した情報である不具合判断結果情報を、車両から受信し、不具合判断結果情報に基づいて、不具合の原因を検査するか否かを判断する検査要否判断部と、
検査要否判断部が、不具合の原因を検査すると判断した場合に、不具合の原因を検査することを指示する検査指示を、１つ以上の車載器へ送信する検査指示部と、
複数の車両から不具合判断結果情報を取得した場合に、複数の不具合判断結果情報を統計処理して、不具合の原因が地図情報にあるか否かを判断し、不具合の原因が地図情報にあると判断したことに基づいて、地図情報を更新すると判断する更新判断部と、を備えるサーバである。

【図面の簡単な説明】

【0015】

【図1】実施形態の地図更新システム１の全体構成を示す図。

【図2】車載システム１０の構成を示す図。

【図3】不具合判断部６１が実行する処理を示す図。

【図4】不具合判断部６１が実行する処理を示す図。

【図5】サーバ８０の構成を示す図。

【図6】地図情報の利用停止、アプリケーション利用停止に関するフローチャート。

【図7】地図情報の利用停止、アプリケーション利用停止に関するフローチャート。

【発明を実施するための形態】

【0016】

以下、実施形態を図面に基づいて説明する。図１は、本実施形態の地図更新システム１の全体構成を示す図である。地図更新システム１は、車両２に搭載された車載システム１０と、車両２の外の任意の位置に設置されたサーバ８０とを備えている。車載システム１０とサーバ８０とは通信回線網３を介して通信できる。

【0017】

〔車載システム１０の構成〕
図２に車載システム１０の構成を示す。車載システム１０は、車載センサ２０、記憶部３０、車両側通信部４０、車両制御部５０、車載器６０を備えている。これらは、車内ＬＡＮ１１に接続されており、車内ＬＡＮ１１を介して互いに通信する。

【0018】

車載センサ２０は、車両制御に使う種々の情報を検出するために車両２に搭載されるセンサである。車載センサ２０は、周辺検出センサ２１と、ＧＮＳＳ受信機２４と、慣性センサ２５と、ドライバ操作検出センサ２６とを備えている。この他に、車載センサ２０として、ドライバの状態を検出するセンサなど、他のセンサを備えてもよい。

【0019】

周辺検出センサ２１は、車両２の周辺に存在する種々の物体を検出するセンサである。物体には、区画線などの平面的な物体も含まれる。図２には、周辺検出センサ２１としてカメラ２２とＬｉｄａｒ２３を示している。カメラ２２は、車両２の前方の画像を撮影する。また、カメラ２２は、車両２の側方および後方を撮影するようになっていてもよい。Ｌｉｄａｒ２３は、光の投光と受光により、車両２の周辺に存在する物体の位置などを検出する。周辺検出センサ２１は、これらに加えて、あるいは、これらに代えて、ミリ波レーダなど、車両２の周辺に存在する物体を検出する他のセンサを備えていてもよい。周辺検出センサ２１は、カメラ、Ｌｉｄａｒ、ミリ波レーダなどのうち、いずれか一つ、または複数の組み合わせにより、車両周辺の物体を検出する構成としてもよい。

【0020】

ＧＮＳＳ受信機２４は、衛星航法システムであるＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）が備える航法衛星が送信する航法信号を受信し、受信した航法信号に基づいて現在位置を逐次算出する。慣性センサ２５は、車両２に生じる慣性を検出するセンサであり、加速度センサおよび角速度センサの一方または両方を含む。ＧＮＳＳ受信機２４と慣性センサ２５は、車両２の現在位置を逐次検出するためのセンサである。現在位置の変化は車両２の挙動を示すので、ＧＮＳＳ受信機２４と慣性センサ２５は、車両２の挙動を示す情報を検出するセンサである。

【0021】

ドライバ操作検出センサ２６は、ドライバが車両２の挙動を変化または維持するためにする入力操作を検出するセンサである。ドライバ操作検出センサ２６は、アクセルセンサ、ブレーキセンサ、ステアリングセンサ、シフトポジションセンサなどである。

【0022】

記憶部３０は、書き込み可能であり、種々の情報を記憶している。記憶部３０には、フラッシュメモリを用いることができる。記憶部３０には、地図データベース（以下、地図ＤＢ）が記憶されている。地図ＤＢは、高精度地図と呼ばれる地図情報を含んでいる。高精度地図は、３次元地図であり、道路の周辺に存在する地物についての情報を含んでいる。地物には、信号機、道路標識が含まれる。高精度地図には、立体的な情報だけでなく、区画線の位置など、平面的な情報についても、経路探索する際に用いる高精度ではない地図よりも、詳細な情報を持っている。

【0023】

車両側通信部４０は、無線通信をする通信部であり、通信回線網３を介してサーバ８０との間で通信する。

【0024】

車両制御部５０は、車載センサ２０から、車両２の挙動を示す情報および車両２の周辺に存在する物体を示す情報の少なくとも一方を取得する。また、車両制御部５０は記憶部３０に記憶されている地図ＤＢからも情報を取得する。車両制御部５０は、これら取得した情報を使い、車両２の挙動を制御する１種類または複数種類の車両制御を実行する。車両制御部５０は、少なくとも１つのプロセッサを備えた構成により実現できる。

【0025】

車両制御の一例は、信号停止制御である。信号停止制御は、対象信号機の灯火が赤であって、矢印灯火が示す方向に走行する走行レーンを走行中でない場合には、停止線で停止する制御である。対象信号機は、周辺検出センサ２１で複数の信号機が検出できた場合、どれが対象信号機であるかは、車両２に対する信号機の位置と向きなどから判断する。地図ＤＢには、信号機の座標、信号形状、サイズなど、信号機を特定する情報（以下、信号機情報）が含まれている。信号停止制御では、地図ＤＢに記憶されている信号機情報を用いて、周辺検出センサ２１を用いて検出した信号機から対象信号機を特定する。そして、特定した対象信号機において点灯している灯火を判断する。

【0026】

車両制御の他の例は、車線維持制御である。車線維持制御は、区画線と車両２との車幅方向の位置を逐次検出しつつ、同じ車線を自動で走行する制御である。車線維持制御は、周辺検出センサ２１を使って認識した区画線の位置および形状と、地図ＤＢに含まれている区画線の位置および形状とのずれが許容範囲であるかを条件として制御することがある。周辺検出センサ２１が認識した区画線が正しいかを確認して車両制御するためである。

【0027】

なお、周辺検出センサ２１を使って認識した区画線から定まる目標軌道と、地図ＤＢに含まれている区画線から定まる目標軌道とを比較してもよい。目標軌道は、車両２の左右両側にある区画線がともに認識できた場合、左右両側の区画線の中間、つまり、車線幅方向中央を示す軌道とすることができる。目標軌道同士を比較しても、区画線同士を比較することと類似の判断ができるからである。

【0028】

また、車線維持制御は、周辺検出センサ２１を使って認識した区画線から定まる目標軌道が、地図ＤＢに含まれている区画線と交差しないことを条件として制御することがある。周辺検出センサ２１を使って認識した区画線の位置と形状が、地図ＤＢに含まれている区画線の位置と形状と少しずれていることを許容しつつ、車線維持制御を実行しているのに、車両２が区画線を超えてしまうことを抑制するためである。

【0029】

車両制御の他の例は、車線変更制御である。車線変更制御は、区画線が車線変更可能な種類の区画線である道路区間において、その区画線を超える車両２の制御をして、車両２が走行している車線を変更する制御である。車線変更制御は、周辺検出センサ２１を使って認識した区画線の位置および形状と、地図ＤＢに含まれている区画線の位置および形状とを比較する。加えて、車線変更制御は、周辺検出センサ２１が検出した信号から認識した線種が、地図ＤＢに含まれている区画線の線種であるかも確認する。認識した区画線がかすれていて破線と認識したが、地図ＤＢでは実線の区画線になっていたり、色の誤認識で、黄線を白線と誤認識していたりする可能性もあるからである。また、場合にはよっては、地図ＤＢが間違っており、黄線が白線に変更になっている可能性もある。

【0030】

車両制御部５０が実行する車両制御は、上述した具体的な制御に限られず、他の制御、たとえば、定速走行制御、車間距離制御、自動駐車制御などでもよい。車両制御部５０は、１種類以上の車両制御を実行する。

【0031】

車載器６０は、少なくとも１つのプロセッサを備えた構成により実現できる。たとえば、車載器６０は、プロセッサ、不揮発性メモリ、ＲＡＭ、Ｉ／Ｏ、およびこれらの構成を接続するバスラインなどを備えたコンピュータにより実現できる。不揮発性メモリには、汎用的なコンピュータを車載器６０として作動させるためのプログラムが格納されている。プロセッサが、ＲＡＭの一時記憶機能を利用しつつ、不揮発性メモリに記憶されたプログラムを実行することで、車載器６０は、不具合判断部６１、検査部６２、地図更新部６３として作動する。これらの作動が実行されることは、プログラムに対応する方法が実行されることを意味する。

【0032】

不具合判断部６１は、車両制御部５０が実行する車両制御に不具合があるか否かを、車両制御の種類別に判断する。不具合を判断する具体的条件を５つ説明する。不具合判断部６１は、以下に説明する５つの条件のうち、いずれか１つの条件飲みを用いてもよいし、２つ以上の条件を組み合わせて用いてもよい。

【0033】

１つ目の条件は、車両２のドライバが、車両制御部５０による車両制御を変更する車両操作をしたことである。１つ目の条件を具体的に説明する。信号停止制御であれば、信号停止制御により停止を予定している位置よりも手前でドライバのブレーキ操作により車両２が停止した場合に、信号停止制御に不具合があると判断できる。これとは反対に、信号停止制御により車両２を停止させるために、車両制御部５０が車両２を減速させている状態で、ドライバがアクセル操作をした場合に、信号停止制御に不具合があると判断してもよい。車線維持制御であれば、ドライバのハンドル操作により車幅方向の位置が所定距離以上変更された場合に車線維持制御に不具合があると判断できる。所定距離は、車線を変更する距離でもよいが、１つの車線内で位置を調整する程度の距離でもよい。車線変更制御であれば、車線変更制御により車線変更をしている途中でドライバがハンドル操作により、車線を変更しないように車両２の横位置を戻した場合に、車線変更制御に不具合があると判断してもよい。

【0034】

定速走行制御であれば、ドライバがシフト位置を変更した場合に、定速走行制御に不具合があると判断してもよい。また、これらの車両制御を実行中に、ドライバが操作部を操作して車両制御を強制的に終了させた場合に、ドライバが終了させた車両制御に不具合があると判断してもよい。具体的な車両制御と、その車両制御に不具合があると判断するドライバ操作との対応関係は事前に設定される。

【0035】

不具合を判断する２つ目の条件は、地図起因制御情報とセンサ起因制御情報とが相違する場合である。地図起因制御情報は、車両制御に使う情報であって、地図ＤＢに含まれている情報を使って決定する制御情報である。信号停止制御であれば、信号機の位置などの信号機情報を制御に使う。地図ＤＢに含まれている信号機情報は、地図起因制御情報の一例である。

【0036】

信号機情報を詳しく説明する。信号機情報は、信号機の座標、形状、サイズ、向き、灯火配列、灯火数、灯火色、灯火形状、灯火の点灯パターンのうちの１つ以上を含ませることができる。この信号機情報を地図起因御情報とする場合、対応する情報を、周辺検出センサ２１を用いて取得する。取得した情報がセンサ起因制御情報である。

【0037】

地図起因制御情報とセンサ起因制御情報とが相違するかどうかの判断において、誤差と言える相違であれば、相違するとは判断しない。地図起因制御情報とセンサ起因制御情報とが相違するかどうかは、たとえば、地図起因制御情報とセンサ起因制御情報との差が、事前に設定した閾値を超えているか否かにより判断する。

【0038】

地図起因制御情報は、地図ＤＢに含まれている情報を加工して生成することもある。たとえば、車線維持制御において、地図ＤＢに含まれている区画線から定まる目標軌道は、地図ＤＢに含まれている情報を加工して生成する地図起因制御情報の一例である。センサ起因制御情報は、車両制御に使う情報であって、周辺検出センサ２１が検出した情報を使って決定する制御情報である。たとえば、周辺検出センサ２１を使って認識した区画線の位置および形状は、センサ起因制御情報である。

【0039】

不具合を判断する３つ目の条件は、車両制御部５０が車両制御に使う１つ以上の車載センサ２０が出力する情報がエラーであるという条件である。車載センサ２０が出力する情報がエラーになる場合として、車載センサ２０が故障する場合と、車載センサ２０は故障していないが、何らかの事情により正しい信号を出力できない場合とがある。後者の例として、ＧＮＳＳ受信機２４が、周囲の環境により、必要数の航法衛星から航法信号を受信できなかった場合がある。後者の他の例として、ドライバの状態を検出するセンサが、ドライバの姿勢などにより、ドライバの状態（たとえばドライバの顔）を検出できない場合がある。また、ドライバの状態を検出するセンサが検出したドライバの状態が、たとえばハンドルを握っていないなど、車両制御が継続できない状態である場合を、ドライバの状態を検出するセンサが出力する情報がエラーであるとしてもよい。

【0040】

不具合を判断する４つ目の条件は、車両２において警報が出ているという条件である。車両２における警報は、追突警報、衝突警報、車間距離警報などを含む。この警報は、車両の挙動が急激に変化した場合、例えば急ハンドル、急発進、急加速、急停止などが発生した場合に実行される。

【0041】

不具合を判断する５つ目の条件は、市場クレームが発生しているという条件である。この５つ目の条件は、上記他の条件とは異なり、手動で情報取得するものを含む。５つ目の条件は、人を介して市場クレームに関する情報がサーバ８０などに入力されることにより、不具合判断部６１による判断において利用可能になる。市場クレームの入手ルートには、例えば、正規ルートと非正規ルートとがある。正規ルートは、エンドユーザから車両メーカやディーラへの伝達ルート、車両メーカなどを含む組織からの内部情報によるルート、公官庁などからの情報ルートである。非正規ルートは、ユーザコミュニティやソーシャルネットワーキングサービスなどから得た情報を人がサーバ８０などに入力することで取得できるルートである。ソーシャルネットワーキングサービスでは、登録したユーザがアクセスして情報を提供できる。この非正規ルートによれば、まだ公に顕在化していないソーシャルネットワーキングサービスを利用した情報を広く拾い上げることができる。

【0042】

図３、図４は、不具合判断部６１が実行する処理を示すフローチャートである。不具合判断部６１は、図３に示す処理を、不具合を判断する車両制御が実行されているときに、所定の周期で実行する。Ｓ１では、実行中の車両制御に不具合があるかどうかを判断する。車両制御に不具合があると判断する条件は、車両制御の種類別に１つ以上の条件が設定されている。

【0043】

不具合がないと判断した場合には、Ｓ１の判断結果がＮＯになる。Ｓ１の判断結果がＮＯであれば、図３の処理を終了する。図３の処理を終了した場合であって、車両制御が継続中であれば、所定周期後、図３の処理を再び開始する。

【0044】

Ｓ１の判断結果がＹＥＳであればＳ２に進む。Ｓ２では、不具合判断結果情報を作成し、所定の記憶部に記憶する。不具合判断結果情報は、Ｓ１の判断結果を含む。また、不具合判断結果情報には、不具合があると判断した車両制御の内容を特定する情報が含まれる。車両制御の内容を特定する情報は、たとえば、信号停止制御、車線維持制御など、具体的な車両制御の名称である。不具合判断結果情報には、不具合が生じたときの車両２の位置を特定する位置特定情報が含まれる。位置特定情報の一例は座標である。位置特定情報の他の例は、不具合が生じたときに車両２が走行している道路リンク、レーンリンクである。不具合が生じたときに車両２が交差点に位置していれば、位置特定情報がその交差点名でもよい。

【0045】

また、不具合判断結果情報には、不具合が生じた時刻、日付、どの条件により不具合と判断したかを示す情報、天候、地図ＤＢのバージョン情報のうちの１つ以上を含ませてもよい。

【0046】

不具合判断部６１は、図４に示す処理を任意に設定されたアップロードタイミングで実施する。アップロードタイミングは、たとえば、車両制御が終了するごとである。また、アップロードタイミングは、車両２の起動時、すなわち、イグニッションスイッチがオンになるときでもよい。また、アップロードタイミングは、図３が終了する都度でもよい。

【0047】

図４において、Ｓ１１では、不具合判断結果情報が記憶されているかを判断する。Ｓ１１の判断結果がＮＯであれば図４の処理を終了する。Ｓ１１の判断結果がＹＥＳであればＳ１２へ進む。

【0048】

Ｓ１２では、記憶されている不具合判断結果情報を、車両側通信部４０からサーバ８０にアップロードする。アップロード後は、アップロードした不具合判断結果情報を記憶部から消去する。

【0049】

説明を図２に戻す。検査部６２は、サーバ８０からの検査指示を車両側通信部４０が受信した場合に、検査指示に従って検査を実施する。検査対象には、地図ＤＢが含まれる。すなわち、検査部６２は、記憶部３０に記憶されている地図ＤＢが正しいかを検査する。また、検査対象には車両制御部５０が実行する車両制御が含まれることもある。

【0050】

地図ＤＢの検査は、具体的には、記憶部３０に記憶されている地図ＤＢと、車両２に搭載されている周辺検出センサ２１により検出される情報から作成する認識地図情報とを比較することである。

【0051】

検査指示には、地図ＤＢのうち、地図情報が正しいかを検査すべきエリアが指示されている。指示されるエリアは、道路のある区間など相対的に広いエリアであることもあれば、交差点など相対的に狭いエリアであることもある。検査部６２は、車両側通信部４０から検査指示を取得した場合であって、検査指示に示されているエリアを走行する場合、検査指示に示されているエリアにおいて、周辺検出センサ２１により検出される情報から認識地図情報を作成する。

【0052】

認識地図情報は、たとえば、区画線の位置と形状である。ただし、認識地図情報として具体的にどの地図情報に対応する認識地図情報を作成するかは、任意に設定できる。検査部６２は、周辺検出センサ２１により検出される情報から作成可能な範囲で、できるだけ多くの認識地図情報を作成することが好ましい。地図ＤＢが正しいかどうかを、より多くの地図情報について判断できるからである。

【0053】

検査部６２は、検査指示に車両制御を特定する情報が含まれている場合、検査指示により特定された車両制御を、検査指示により特定された区間で実行する。そして、実行した車両制御に不具合があるか否かを判断する。車両制御に不具合があるかどうかを判断する処理は、不具合判断部６１が実行する処理と同じでよい。

【0054】

検査指示に、検査用の地図データが含まれている場合には、地図ＤＢのうち、検査用の地図データに対応する部分を、検査用の地図データにより更新する。その後、車両制御に不具合があるかどうかを検査する。この場合には、地図ＤＢを更新したことにより、車両制御に不具合が生じなければ、不具合の原因が地図情報にあったと推定できる。加えて、地図ＤＢを更新しても車両制御に不具合が生じれば、不具合の原因が地図情報以外にあると推定できる。

【0055】

検査指示には、他に、検査する条件として、天候、時間帯などの条件が指示されていることもある。検査部６２は、検査指示に示された条件を満たした状態で、車両制御あるいは地図ＤＢを検査する。

【0056】

検査部６２は、検査結果を車両側通信部４０からサーバ８０に送信する。検査結果の一例は、認識地図情報と、記憶部３０に記憶されている地図ＤＢに含まれる情報のうちこの認識地図情報に対応する情報との差分を示す情報である。認識地図情報が区画線であれば、互いに同一リンクとなる認識地図情報である区画線と地図ＤＢに含まれる区画線とにおいて、リンク端点間の距離である。また、検査結果は、上記差分を示す情報を算出する前の情報でもよい。すなわち、検査結果は、認識地図情報と、記憶部３０に記憶されている地図ＤＢにおいて認識地図情報に対応する情報でもよい。また、記憶部３０に記憶されている地図ＤＢを、バージョン情報などによりサーバ８０が管理できていれば、検査結果は、認識地図情報と地図ＤＢのバージョンでもよい。

【0057】

地図更新部６３は、更新用地図データを車両側通信部４０が受信した場合、その更新用地図データを用いて、記憶部３０に記憶された地図ＤＢを更新する。更新用地図データは、サーバ８０から配信される。

【0058】

〔サーバ８０構成〕
図５にサーバ８０の構成を示す。サーバ８０は、サーバ側通信部８１、記憶部８２、サーバ側制御部８３を備えている。サーバ側通信部８１は、通信回線網３を介して車両側通信部４０と通信する通信部である。サーバ側通信部８１は、通信回線網３に有線接続してもよいし、無線接続してもよい。

【0059】

記憶部８２には、配信地図ＤＢが記憶されている。配信地図ＤＢは、車両２の記憶部３０に記憶されている地図ＤＢの一部または全部を更新するために、車両２に配信する地図を格納したデータベースである。

【0060】

サーバ側制御部８３は、少なくとも１つのプロセッサを備えた構成により実現できる。たとえば、サーバ側制御部８３は、プロセッサ、不揮発性メモリ、ＲＡＭ、Ｉ／Ｏ、およびこれらの構成を接続するバスラインなどを備えたコンピュータにより実現できる。不揮発性メモリには、汎用的なコンピュータをサーバ側制御部８３として作動させるためのプログラムが格納されている。プロセッサが、ＲＡＭの一時記憶機能を利用しつつ、不揮発性メモリに記憶されたプログラムを実行することで、サーバ側制御部８３は、検査要否判断部８４、検査指示部８５、更新判断部８６として作動する。これらの作動が実行されることは、プログラムに対応する方法が実行されることを意味する。

【0061】

検査要否判断部８４は、車両２から受信した不具合判断結果情報に基づいて、不具合の原因を検査するか否かを判断する。不具合の原因を検査するか否かはエリア別に判断する。エリアは、車両制御の種類別に決定することができる。たとえば、車両制御が信号停止制御であれば、交差点に存在する信号機を含むように設定された交差点の周囲とその交差点の手前の一定距離とすることができる。車両制御が車線維持制御あるいは車線変更制御であれば、車線維持制御あるいは車線変更制御に不具合が生じた道路リンクあるいはレーンリンクを含むようにエリアを決定する。

【0062】

検査要否判断部８４は、複数の車両２から送信された不具合判断結果情報を統計処理して、不具合の原因を検査するか否かを判断することができる。たとえば、事前に設定された一定時間内に同じ種類の車両制御について、一定数以上、その車両制御に不具合があることを意味する不具合判断情報を受信した場合に、不具合の原因を検査すると判断する。上記一定時間は、高速道路か一般道路かなど道路種別に応じて変更してもよい。道路種別は、不具合判断結果情報に含まれている位置特定情報と記憶部８２に記憶されている配信地図ＤＢとに基づいて決定してもよい。また、交通量に応じて一定時間を決定してもよい。

【0063】

さらに、不具合判断結果情報が示す、どの条件で不具合と判断したかを考慮してもよい。たとえば、不具合の原因が地図ＤＢであるかどうかを判断する場合、不具合と判断した条件が車載センサ２０が出力する情報がエラーであるという条件となっている不具合判断結果情報は、不具合判断結果情報として数えないようにしてもよい。

【0064】

検査要否判断部８４は、必ずしも、複数の車両２から送信された不具合判断結果情報を統計処理する必要はない。一定時間ごとに、最初に受信した不具合判断結果情報をもとに、不具合の原因を検査するか否かを判断してもよい。この場合、一定時間内に不具合判断結果情報を受信した場合に、不具合の原因を検査すると判断することができる。この判断は、車両制御の内容ごとにすることができる。

【0065】

また、一定時間内に不具合判断結果情報を受信し、かつ、その不具合判断結果情報は、不具合と判断したときに成立した条件が車載センサ２０が出力する情報がエラーであるという条件ではない場合に、不具合の原因を検査すると判断してもよい。つまり、不具合と判断したときに成立した条件が、前述した第１の条件または第２の条件である場合に、不具合の原因を検査すると判断してもよい。前述した第１、第２、第３の条件を比較すると、第１、第２の条件が成立した場合、第３の条件が成立した場合よりも地図ＤＢが不具合である可能性が高いからである。

【0066】

検査指示部８５は、検査要否判断部８４が不具合の原因を検査すると判断した場合に、不具合の原因を検査することを指示する検査指示を、１つ以上の車載システム１０へ送信する。検査は、不具合の原因が地図ＤＢにあるか否かを判断することを目的の１つとする。したがって、検査指示には、検査すべき地図のエリアを指示する情報が含まれる。指示されるエリアは、検査要否判断部８４が検査すべきと判断したエリア、または、そのエリアを含むように設定されたより広いエリアである。エリアを指示する情報は、エリアの中心など、エリアを特定する１つ以上の座標でもよい。

【0067】

検査指示部８５は、検査指示を、通信可能な全部の車載システム１０に送信してもよい。あるいは、検査指示により検査することを指示しているエリアの周囲に存在する車載システム１０に対して検査指示を送信してもよい。

【0068】

検査指示には、検査する車両制御を特定する情報を含ませることができる。検査する車両制御を特定する場合、時間帯、天候など、車両制御を実行する条件を含ませることができる。また、検査指示には、検査用に、検査指示で特定しているエリアに対する地図データ、配信地図ＤＢから抽出して含ませてもよい。

【0069】

車載システム１０は、検査指示を受信して、検査部６２が、検査指示にしたがって検査をした場合、検査結果をサーバ８０へ送信する。サーバ８０の更新判断部８６は、検査結果をもとに、地図ＤＢを更新する必要があるかを判断する。正確には、更新判断部８６は、地図ＤＢのうち検査指示した地図情報を更新する必要があるかを判断する。地図ＤＢのうち検査指示した地図情報を更新することも、地図ＤＢを更新することになる。以下、「地図ＤＢを更新する」は、地図ＤＢのうち検査指示した地図情報を更新することを意味する場合がある。更新判断部８６は、検査結果から、地図ＤＢが正しくないと判断できる場合に、地図ＤＢを更新する必要があると判断する。

【0070】

たとえば、更新判断部８６は、複数の車両２から受信した検査結果を統計処理して、地図ＤＢを更新する必要があるかを判断する。一例としては、更新判断部８６は、検査結果を事前に設定した一定数、取得した場合に、取得した検査結果において、地図ＤＢが正しいことを示している検査結果の比率が閾値を以上である場合には、地図ＤＢは正しいので、地図ＤＢは更新しないと判断する。この場合、車両制御の不具合の原因は、地図ＤＢ以外の原因であると推定できる。

【0071】

地図ＤＢが正しいことを示している検査結果の比率が閾値よりも小さい場合には、更新判断部８６は、地図ＤＢを更新する必要があると判断する。地図ＤＢを更新する必要があると判断する場合には、車両制御が不具合となった原因が地図ＤＢにあると推定したことになる。

【0072】

更新判断部８６は、地図ＤＢを更新する必要があると判断した場合には、記憶部８２に記憶されている配信地図ＤＢから更新用地図データを作成する。そして、作成した更新用地図データを、車両制御が不具合があるとの判断結果を送信した車載システム１０に送信する。この更新用地図データを車両側通信部４０が受信した場合、地図更新部６３が地図ＤＢを更新する。なお、更新用地図データを、受信相手を特定せずに放送的に送信してもよい。更新用地図データを放送的に送信する場合、受信側にて、更新用の地図データのバージョンなどから、更新用の地図データを更新するかどうかを決定する。

【0073】

図６に、地図情報の利用停止、アプリケーション利用停止に関するフローチャートを示す。検査要否判断部８４は、図６のＳ１００に示す処理を、不具合判断結果情報を取得しているときに所定の周期で実行する。Ｓ１００では、不具合判断結果情報に基づいて、前述したように、不具合の原因を検査するか否かを判断する。不具合の検査をしないと判断すれば、Ｓ１００の判断結果がＮＯになる。Ｓ１００の判断結果がＮＯであれば、Ｓ１００の処理を繰り返し実行する。

【0074】

Ｓ１００の判断結果がＹＥＳであればＳ１１０に進む。Ｓ１１０では、更新判断部８６は、車両２から送信された検査結果に基づいて、または複数の車両２から送信された検査結果を統計処理して、不具合の原因が地図情報にあるか否かを判断する。不具合の原因が地図情報にあると判断すれば、Ｓ１１０の判断結果がＹＥＳになる。Ｓ１１０の判断結果がＹＥＳであれば、Ｓ１２０に進む。Ｓ１２０では、地図更新システム１は、地図情報の利用を停止する処理を実行する。車載システム１０は、Ｓ１２０の処理が実行されたことを車両２のユーザに対して表示、または音声で報知するようにしてもよい。Ｓ１２０の処理実行後、図６の処理を終了する。図６の処理を終了した場合であって、車両制御が継続中であれば、所定周期後、図６の処理を再び開始する。

【0075】

不具合の原因が地図情報にないと判断すれば、Ｓ１１０の判断結果がＮＯになる。Ｓ１１０の判断結果がＮＯであれば、Ｓ１３０に進む。Ｓ１３０では、車載器６０または不具合判断部６１は、車両２のアプリケーションに不具合があるか否かを判断する。Ｓ１３０は、アプリケーションの機能部が正常に動作していないこと、運転状態や運転支援の表示に不具合があること、その他の故障時等に不具合があると判断する。アプリケーションは、車両制御部５０が実行する車両２の自動運転の制御または運転支援の制御に関わるソフトウェアである。アプリケーションは、車両２に搭載されており、車両２においてユーザが操作や視認でき、利用可能なソフトウェアである。自動運転の制御または運転支援の制御は、例えば、定速走行制御、車間距離制御、自動駐車制御、車線変更制御、交差点運転制御などを含む。アプリケーションは、車両内において利用され、車両２の自動運転または運転支援に関するアプリケーションである。アプリケーションは、経路案内、あるいは自動運転または運転支援に関する標識や地物を、表示または音声案内する。

【0076】

アプリケーションに不具合がないと判断すれば、Ｓ１３０の判断結果がＮＯになる。Ｓ１３０の判断結果がＮＯであれば、Ｓ１００に戻る。アプリケーションに不具合があると判断すれば、Ｓ１３０の判断結果がＹＥＳになる。Ｓ１３０の判断結果がＹＥＳであれば、Ｓ１４０に進む。Ｓ１４０では、車載器６０は、アプリケーションの利用を停止する処理を実行する。車載器６０は、Ｓ１４０の処理が実行されたことを車両２のユーザに対して表示、または音声で報知するようにしてもよい。Ｓ１４０の処理実行後、図６の処理を終了する。図６の処理を終了した場合であって車両制御が継続中であれば、所定周期後、図６の処理を再び開始する。

【0077】

図７に、地図情報の利用停止、アプリケーション利用停止に関するフローチャートを示す。図７に示す処理は図６に対してＳ１２５を実行する点が相違する。図７に示すように、Ｓ１１０の判断結果がＹＥＳであれば、Ｓ１２０の処理とともに、Ｓ１２５の処理を実行するようにしてもよい。Ｓ１２５では、車載器６０は、アプリケーションの利用を停止する処理を実行する。車載器６０は、Ｓ１２５の処理が実行されたことを車両２のユーザに対して表示、または音声で報知するようにしてもよい。Ｓ１２５の処理実行後、図６の処理を終了する。この処理により、更新判断部の判断により地図情報に不具合の原因がある場合に、自動運転または運転支援に関するアプリケーションの利用を停止できる。

【0078】

〔実施形態のまとめ〕
以上、説明した本実施形態の地図更新システム１では、更新判断部８６は、車載システム１０から送信された検査結果に基づいて地図ＤＢを更新する必要があるかどうかを判断する。検査結果は検査指示に応じて得られる結果であり、検査指示は、車両制御に不具合がある場合に出される。よって、検査結果に基づいて地図ＤＢを更新する必要があると判断することは、車両制御の不具合の原因が地図情報にあると判断したことに基づいて、地図情報を更新する必要があると判断したことを意味する。

【0079】

そのため、車両制御部５０が実行する車両制御に不具合がなければ、地図ＤＢが最新でなくても、地図ＤＢを更新する必要がないという判断が可能になる。よって、必須ではない地図ＤＢの更新を抑制できる。

【0080】

また、不具合判断部６１は、車両２のドライバが、車両制御部５０による車両制御を変更する車両操作をしたことに基づいて、車両制御部５０が実行する車両制御に不具合があると判断する。車両制御に不具合がある場合、ドライバが車両制御を変更する車両操作をすることが多いので、不具合判断部６１は、車両制御に不具合があるにも関わらず、不具合があると判断できない場合を少なくできる。

【0081】

不具合判断部６１は、地図起因制御情報とセンサ起因制御情報とが相違することに基づいて、車両制御部５０が実行する車両制御に不具合があると判断する。このようにして車両制御に不具合があるか否かを判断することで、地図情報に起因して車両制御に不具合があるにも関わらず、不具合があると判断できない場合を少なくできる。

【0082】

不具合判断部６１は、車載センサ２０が出力する情報がエラーであることに基づいて車両制御に不具合があると判断する。このようにして車両制御に不具合があるか否かを判断することで、車両制御の不具合の原因としてある程度の割合を占める可能性がある不具合を、不具合であると判断できなくなってしまうことを抑制できる。

【0083】

地図更新システム１は、車載器６０とサーバ８０とを備えており、車載器６０が不具合判断部６１を備え、サーバ８０が、検査要否判断部８４と検査指示部８５と更新判断部８６を備える。更新判断部８６は、地図ＤＢを更新する必要があるかどうかを、複数の車載器６０から不具合判断結果情報を取得して判断できる。また、検査要否判断部８４は、不具合判断結果情報に基づいて、不具合の原因を検査するか否かを判断する。検査要否判断部８４が不具合の検査をしないと判断すれば、検査指示部８５は検査指示を車載器６０へ送信しない。この構成により、不具合の原因を検査する必要がない場合にまで、不具合の原因を検査してしまうことを抑制できる。

【0084】

不具合判断結果情報には、車両制御の内容を特定する情報が含まれる。これにより、検査要否判断部８４は、車両制御の内容を特定して、不具合の原因を検査する必要があるか否かを判断できる。

【0085】

不具合判断結果情報には、不具合が生じたときの車両２の位置を特定する位置特定情報が含まれる。これにより、検査要否判断部８４は、不具合を検査するエリアを特定して、不具合の要因を検査する必要あるか否かを判断できる。

【0086】

検査要否判断部８４は、複数の車両２から不具合判断結果情報を取得した場合に、複数の不具合判断結果情報を統計処理して不具合の原因を検査するか否かを判断する。したがって、不具合の原因を検査するか否かを判断する精度が高められる。

【0087】

更新判断部８６は、複数の車両２から送信された検査結果を統計処理して不具合の原因が地図情報にあるか否かを判断する。したがって、不具合の原因が地図情報にあるか否かを判断する精度が高められる。

【0088】

地図更新システム１は、更新判断部８６の判断により地図情報に不具合の原因がある場合に、地図情報の利用を停止する。これによれば、不具合が生じた地図情報を使用する車両２の挙動制御を回避することができる。

【0089】

地図更新システム１は、更新判断部８６の判断により地図情報に不具合の原因がある場合に、車両２の自動運転または運転支援に関するアプリケーションを停止する。これによれば、不具合が生じた地図情報を使用するアプリケーションの使用を回避することができる。

【0090】

地図更新システム１は、更新判断部８６の判断により地図情報に不具合の原因がなく、車両２の自動運転または運転支援に関するアプリケーションに不具合がある場合に、アプリケーションを停止する。これによれば、地図情報の不具合があるか否かにかかわらず、不具合の原因があるアプリケーションの使用を回避することができる。

【0091】

以上、実施形態を説明したが、開示した技術は上述の実施形態に限定されるものではなく、次の変形例も開示した範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。なお、以下の説明において、それまでに使用した符号と同一番号の符号を有する要素は、特に言及する場合を除き、それ以前の実施形態における同一符号の要素と同一である。また、構成の一部のみを説明している場合、構成の他の部分については先に説明した実施形態を適用できる。

【0092】

＜変形例１＞
実施形態では、不具合判断部６１は、車両制御に不具合があると判断した場合にのみ、不具合判断結果情報を作成していた。しかし、不具合判断部６１は、車両制御に不具合がないと判断した場合にも、そのことを意味する不具合判断結果情報を作成してもよい。

【0093】

車両制御に不具合がある場合および不具合がない場合、ともに不具合判断結果情報を作成する場合、検査要否判断部８４は、たとえば以下の判断をする。検査要否判断部８４は、一定数の不具合判断結果情報を集計し、車両制御に不具合があることを意味する不具合判断結果情報の比率に基づいて、不具合の原因を検査するか否かを判断する。なお、前述した３つ目の条件、すなわち、車載センサ２０が出力する情報がエラーであるという条件が成立した場合、地図ＤＢが原因である可能性は低い。そこで、不具合の原因が地図ＤＢであるか否かを検査するか否かを判断する場合、上記の比率において、前述した３つ目の条件が成立したことを意味する不具合判断結果情報は、車両制御に不具合がないとして扱ってもよい。

【0094】

＜変形例２＞
実施形態では、サーバ８０は、車両２の外にあると説明した。しかし、サーバ８０は、車両２に搭載されていてもよい。よって、更新判断部８６など、サーバ側制御部８３の機能を車載器６０が備えていてもよい。

【0095】

＜変形例３＞
実施形態において、検査要否判断部８４は統計処理をする必要がないことを説明した。したがって、検査要否判断部８４を省略し、不具合判断部６１が車両制御に不具合があると判断した場合に、検査指示部８５が検査指示を出すようにしてもよい。

【0096】

＜変形例４＞
地図起因制御情報とセンサ起因制御情報とが相違する場合、地図ＤＢに不具合がある可能性が高い。このように、車両制御の不具合の原因が地図ＤＢにある可能性が高い場合には、検査要否判断部８４、検査指示部８５、検査部６２を省略して、更新判断部８６は、不具合の原因が地図情報にあると判断してもよい。なお、この変形例４においても、不具合判断部６１は、車両制御に使う地図起因制御情報と、それに対応するセンサ起因制御情報とが相違するかを判断する。地図ＤＢが、現実の道路や地物を正しく表現していないとしても、現実の道路や地物を正しく表現していない地図情報を車両制御に使わないのであれば、不具合判断部６１は車両制御に不具合があるとは判断しない。たとえば、車線変更制御においては、区画線が実線か破線かを区別する必要があるが、実線の色は使わない。よって、変形例４の態様でも、必須ではない地図情報の更新を抑制できる。

【0097】

＜変形例５＞
更新判断部８６は、検査結果を必ずしも統計処理する必要はない。更新判断部８６は、１つのみの検査結果から、地図ＤＢを更新するかどうかを判断してもよい。

【0098】

＜変形例６＞
実施形態で説明した不具合判断結果情報には、車両制御の内容を特定する情報と車両２の位置を特定する情報とが含まれていた。しかし、不具合判断結果情報に、車両制御の内容を特定する情報および車両２の位置を特定する情報の一方または両方が含まれていなくてもよい。この場合であっても、不具合判断部６１が、車両制御に不具合があると判断しなければ、更新判断部８６は地図情報を更新するとは判断しないので、必須ではない地図情報の更新を抑制できる。

【0099】

＜変形例７＞
実施形態では、サーバ８０から配信される更新用地図データをもとに、車載器６０の地図更新部６３が地図ＤＢをオンラインで更新していた。しかし、地図ＤＢの更新は、オフラインで行われてもよい。

【0100】

（技術的思想の開示）
この明細書は、以下に列挙する複数の項に記載された複数の技術的思想を開示している。いくつかの項は、後続の項において先行する項を択一的に引用する多項従属形式（a multiple dependent form）により記載されている場合がある。さらに、いくつかの項は、他の多項従属形式の項を引用する多項従属形式（a multiple dependent form referring to another multiple dependent form）により記載されている場合がある。これらの多項従属形式で記載された項は、複数の技術的思想を定義している。

【0101】

（技術的思想１）
車両（２）に搭載されている記憶部（３０）に記憶され、前記車両の挙動を制御する車両制御部（５０）が使用する地図情報を更新する必要があるか否かを判断する地図更新システム（１）であって、
前記車両制御部が実行する車両制御に不具合があるか否かを判断する不具合判断部（６１）と、
前記不具合の原因が前記地図情報にあると判断したことに基づいて、前記地図情報を更新する必要があると判断する更新判断部（８６）とを備えた、地図更新システム。

【0102】

（技術的思想２）
技術的思想１に記載の地図更新システムであって、
前記不具合判断部は、前記車両のドライバが、前記車両制御部による車両制御を変更する車両操作をしたことに基づいて、前記車両制御部が実行する車両制御に不具合があると判断する、地図更新システム。

【0103】

（技術的思想３）
技術的思想１または２に記載の地図更新システムであって、
前記不具合判断部は、前記記憶部に記憶された地図情報に基づいて定まり、前記車両制御部による車両制御に使う地図起因制御情報と、前記車両に搭載された周辺検出センサ（２１）により検出された情報に基づいて定まり、前記地図起因制御情報に対応する情報であるセンサ起因制御情報とが相違することに基づいて、前記車両制御部が実行する車両制御に不具合があると判断する、地図更新システム。

【0104】

（技術的思想４）
技術的思想１～３のいずれか１項に記載の地図更新システムであって、
前記車両制御部は、前記車両に搭載されている車載センサ（２０）から、前記車両の挙動を示す情報および前記車両の周辺に存在する物体を示す情報の少なくとも一方を取得して前記車両の挙動を制御し、
前記不具合判断部は、前記車載センサが出力する情報がエラーであることに基づいて、前記車両制御部が実行する前記車両制御に不具合があると判断する、地図更新システム。

【0105】

（技術的思想５）
技術的思想１～４のいずれか１項に記載の地図更新システムであって、
前記不具合判断部を備え、複数の前記車両にそれぞれ搭載される複数の車載器（６０）と、
前記更新判断部を備え、前記車載器と通信するサーバ（８０）と、を備え、
前記不具合判断部は、前記車両制御に不具合があるか否かを判断した情報である不具合判断結果情報を車両側通信部（４０）から前記サーバに送信し、
前記サーバは、
前記車両から受信した前記不具合判断結果情報に基づいて、前記不具合の原因を検査するか否かを判断する検査要否判断部（８４）と、
前記検査要否判断部が、前記不具合の原因を検査すると判断した場合に、前記不具合の原因を検査することを指示する検査指示を、１つ以上の前記車載器へ送信する検査指示部（８５）と、を備え、
前記車載器は、
前記検査指示を受信した場合に、前記記憶部に記憶されている前記地図情報と、前記車両に搭載されている周辺検出センサ（２１）により検出される情報から作成する認識地図情報とを比較することで、前記記憶部に記憶されている前記地図情報が正しいかを検査し、検査結果を前記車両側通信部から前記サーバに送信する検査部（６２）を備え、
前記更新判断部は、前記車両から送信された前記検査結果に基づいて前記地図情報の更新が必要であるか否かを判断する、地図更新システム。

【0106】

（技術的思想６）
技術的思想５に記載の地図更新システムであって、
前記不具合判断結果情報には、前記車両制御の内容を特定する情報が含まれる、地図更新システム。

【0107】

（技術的思想７）
技術的思想５または６に記載の地図更新システムであって、
前記不具合判断結果情報には、不具合が生じたときの前記車両の位置を特定する位置特定情報が含まれる、地図更新システム。

【0108】

（技術的思想８）
技術的思想５～７のいずれか１項に記載の地図更新システムであって、
前記検査要否判断部は、複数の前記車両から前記不具合判断結果情報を取得した場合に、複数の前記不具合判断結果情報を統計処理して、前記不具合の原因を検査するか否かを判断する、地図更新システム。

【0109】

（技術的思想９）
技術的思想５～８のいずれか１項に記載の地図更新システムであって、
前記更新判断部は、複数の前記車両から送信された前記検査結果を統計処理して、前記不具合の原因が前記地図情報にあるか否かを判断する、地図更新システム。

【0110】

（技術的思想１０）
技術的思想９に記載の地図更新システムであって、
前記更新判断部の判断により前記地図情報に不具合の原因がある場合に、地図情報の利用を停止する地図更新システム。

【0111】

（技術的思想１１）
技術的思想９に記載の地図更新システムであって、
前記更新判断部の判断により前記地図情報に不具合の原因がある場合に、前記車両の自動運転または運転支援に関するアプリケーションの利用を停止する地図更新システム。

【0112】

（技術的思想１２）
技術的思想９に記載の地図更新システムであって、
前記更新判断部の判断により前記地図情報に不具合の原因がなく、前記車両の自動運転または運転支援に関するアプリケーションに不具合がある場合に、前記アプリケーションを停止する地図更新システム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】