知財求人 - 知財ポータルサイト「IP Force」
▶ トムトム グローバル コンテント ベスローテン フエンノートシャップの特許一覧 ▶ トムトム インターナショナル ベスローテン フエンノートシャップの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024150555
(43)【公開日】2024-10-23
(54)【発明の名称】向上した機能安全性を有するデジタルＭＡＰデータ
(51)【国際特許分類】
G01C 21/32 20060101AFI20241016BHJP
G08G 1/0962 20060101ALI20241016BHJP
G06F 21/64 20130101ALI20241016BHJP
【ＦＩ】
G01C21/32
G08G1/0962
G06F21/64
【審査請求】有
【請求項の数】20
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2024113532
(22)【出願日】2024-07-16
(62)【分割の表示】P 2022547158の分割
【原出願日】2021-02-25
(31)【優先権主張番号】2002612.6
(32)【優先日】2020-02-25
(33)【優先権主張国・地域又は機関】GB
(71)【出願人】
【識別番号】509097563
【氏名又は名称】トムトム グローバル コンテント ベスローテン フエンノートシャップ
(71)【出願人】
【識別番号】307043223
【氏名又は名称】トムトム インターナショナル ベスローテン フエンノートシャップ
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】シュアーマン， キース， コーネリス， ピーター
(72)【発明者】
【氏名】ロジエ， ローランド， アラリック， イアン
(72)【発明者】
【氏名】ヴァン デ ヴォルスト， エドワード
(72)【発明者】
【氏名】リーバース， ポール
(57)【要約】 （修正有）
【課題】安全で信頼できるデジタル地図の生成及びプロビジョニングのための技術が本書で開示される。
【解決手段】本技術は、地図データに依存する構成要素への車内配信の前にこの地図データの正しさをチェックするために単純で効率的なデータ構造を使用して地図クライアントにおけるデジタル地図データの検証を可能にする。
【選択図】図１
【解決手段】本技術は、地図データに依存する構成要素への車内配信の前にこの地図データの正しさをチェックするために単純で効率的なデータ構造を使用して地図クライアントにおけるデジタル地図データの検証を可能にする。
【選択図】図１
【特許請求の範囲】
【請求項1】
デジタル地図によってカバーされたナビゲート可能なネットワークを移動する車両の電子制御ユニット（ＥＣＵ）上で実行される１つ以上の地図ベース・アプリケーションへ遠隔サーバから送信されている地図データを検証する方法であって、前記デジタル地図は、複数の地図タイルの集合として表され、各タイルは、前記ナビゲート可能なネットワークの部分を含む特定の地理的エリアを表し、前記方法は、
前記サーバにおいて、地図タイルについてのデータ構造を生成することであって、前記データ構造は、前記タイルによってカバーされた前記地理的エリア内及び／又は前記デジタル地図を表す前記タイルのうちの別の１つ以上によってカバーされた前記地理的エリア内に少なくとも部分的に入る１つ以上のオブジェクトの集合を示すオブジェクト・データを含み、
前記地図タイル・データ構造にオブジェクト・データが含まれる１つ以上のオブジェクトの前記集合内の少なくとも１つのオブジェクトについて、前記少なくとも１つのオブジェクトについての前記オブジェクト・データとともに前記地図タイル・データ構造内に、関連付けられたセキュリティ・データが含まれ、前記セキュリティ・データは、その関連付けられたオブジェクト・データの完全性を検証するために使用可能である、ことと、
前記オブジェクト・データ及び関連付けられたセキュリティ・データを含む前記タイルについての前記地図タイル・データ構造を、前記車両の１つ以上の処理ユニットで実行されるクライアント・アプリケーションへ前記サーバから送信することと、を有する方法。
前記サーバにおいて、地図タイルについてのデータ構造を生成することであって、前記データ構造は、前記タイルによってカバーされた前記地理的エリア内及び／又は前記デジタル地図を表す前記タイルのうちの別の１つ以上によってカバーされた前記地理的エリア内に少なくとも部分的に入る１つ以上のオブジェクトの集合を示すオブジェクト・データを含み、
前記地図タイル・データ構造にオブジェクト・データが含まれる１つ以上のオブジェクトの前記集合内の少なくとも１つのオブジェクトについて、前記少なくとも１つのオブジェクトについての前記オブジェクト・データとともに前記地図タイル・データ構造内に、関連付けられたセキュリティ・データが含まれ、前記セキュリティ・データは、その関連付けられたオブジェクト・データの完全性を検証するために使用可能である、ことと、
前記オブジェクト・データ及び関連付けられたセキュリティ・データを含む前記タイルについての前記地図タイル・データ構造を、前記車両の１つ以上の処理ユニットで実行されるクライアント・アプリケーションへ前記サーバから送信することと、を有する方法。
【請求項2】
請求項１に記載の方法であって、
前記クライアント・アプリケーションが、前記タイル・データ構造にデータが記憶される１つ以上のオブジェクトを示すオブジェクト・データを抽出するために、前記タイル・データ構造をアンパックすることと、
前記クライアント・アプリケーションが、前記抽出されたオブジェクト・データの完全性を検証するために、前記関連付けられたセキュリティ・データを使用することと、をさらに有する方法。
前記クライアント・アプリケーションが、前記タイル・データ構造にデータが記憶される１つ以上のオブジェクトを示すオブジェクト・データを抽出するために、前記タイル・データ構造をアンパックすることと、
前記クライアント・アプリケーションが、前記抽出されたオブジェクト・データの完全性を検証するために、前記関連付けられたセキュリティ・データを使用することと、をさらに有する方法。
【請求項3】
デジタル地図によってカバーされた地理的エリア内のナビゲート可能なネットワークを移動する車両に搭載されて実行されるクライアント・アプリケーションを動作させる方法であって、前記デジタル地図は、複数の地図タイルの集合として表され、各タイルは、前記ナビゲート可能なネットワークの部分を含む特定の地理的エリアを表し、各地図タイルは、
前記地図タイルによってカバーされた前記地理的エリア内及び／又は前記デジタル地図を表す前記地図タイルのうちの別の１つ以上によってカバーされた前記地理的エリア内に少なくとも部分的に入る１つ以上のオブジェクトの集合を示すオブジェクト・データと、
前記地図タイル・データ構造内にオブジェクト・データが記憶される少なくとも１つのオブジェクトに関連付けられた前記オブジェクト・データの完全性を検証するためのセキュリティ・データと、を含む関連付けられた地図タイル・データ構造を有し、
前記方法は、
前記クライアント・アプリケーションにおいて、前記ナビゲート可能なネットワークの１つ以上の特徴に関する地図データを求める１つ以上の地図ベース・アプリケーションからの要求を受信することと、
前記クライアント・アプリケーションによって、個別の地図タイル・データ構造から前記特徴に関するオブジェクト・データを取得することと、
前記個別の地図タイル・データ構造から、前記取得されたオブジェクト・データについての関連付けられたセキュリティ・データを取得することと、
前記クライアント・アプリケーションが、前記オブジェクト・データの完全性を検証するために前記セキュリティ・データを使用し、前記データが検証された場合に、前記オブジェクト・データを前記地図ベース・アプリケーションに渡すことと、を有する方法。
前記地図タイルによってカバーされた前記地理的エリア内及び／又は前記デジタル地図を表す前記地図タイルのうちの別の１つ以上によってカバーされた前記地理的エリア内に少なくとも部分的に入る１つ以上のオブジェクトの集合を示すオブジェクト・データと、
前記地図タイル・データ構造内にオブジェクト・データが記憶される少なくとも１つのオブジェクトに関連付けられた前記オブジェクト・データの完全性を検証するためのセキュリティ・データと、を含む関連付けられた地図タイル・データ構造を有し、
前記方法は、
前記クライアント・アプリケーションにおいて、前記ナビゲート可能なネットワークの１つ以上の特徴に関する地図データを求める１つ以上の地図ベース・アプリケーションからの要求を受信することと、
前記クライアント・アプリケーションによって、個別の地図タイル・データ構造から前記特徴に関するオブジェクト・データを取得することと、
前記個別の地図タイル・データ構造から、前記取得されたオブジェクト・データについての関連付けられたセキュリティ・データを取得することと、
前記クライアント・アプリケーションが、前記オブジェクト・データの完全性を検証するために前記セキュリティ・データを使用し、前記データが検証された場合に、前記オブジェクト・データを前記地図ベース・アプリケーションに渡すことと、を有する方法。
【請求項4】
請求項１乃至３の何れか１項に記載の方法であって、オブジェクトについての前記関連付けられたセキュリティ・データは、前記オブジェクトについての前記オブジェクト・データを少なくとも使用して計算されたハッシュ値を含み、前記オブジェクト・データの完全性を検証することは、前記クライアント・アプリケーションが前記ハッシュを再計算し、前記再計算されたハッシュ値を、前記タイル・データ構造に含まれる前記オブジェクトについての前記ハッシュ値と比較することを含む、方法。
【請求項5】
請求項１乃至４の何れか１項に記載の方法であって、前記又は各地図タイル・データ構造は、前記タイル・データ構造の真正性及び／又は完全性を検証するためのデジタル署名を有し、前記デジタル署名は前記サーバによって適用される、方法。
【請求項6】
請求項１乃至５の何れか１項に記載の方法であって、前記クライアント・アプリケーションは、第１アプリケーション及び第２アプリケーションを含み、前記第１アプリケーションは、前記地図ベース・アプリケーション及び前記第２アプリケーションと通信し、前記第２アプリケーションは、前記少なくとも１つの遠隔サーバと通信する、方法。
【請求項7】
請求項６に記載の方法であって、前記デジタル地図によってカバーされた前記ナビゲート可能なネットワーク内の特徴に関する情報を求める１つ以上の地図ベース・アプリケーションからの要求に応答して、前記第１アプリケーションは、第２アプリケーションに、前記特徴に関連付けられたオブジェクト・データを要求し、前記第２アプリケーションはその後、関連するオブジェクト・データ及びその関連付けられたセキュリティ・データを取得し、前記オブジェクト・データ及び前記セキュリティ・データを前記第１アプリケーションに提供し、前記第１アプリケーションは、前記オブジェクト・データの完全性を検証するために前記セキュリティ・データを使用する、方法。
【請求項8】
請求項７に記載の方法であって、前記第１アプリケーションが前記オブジェクト・データの完全性を検証する場合に、前記オブジェクト・データはその後、前記第１アプリケーションから前記地図ベース・アプリケーションに提供される、方法。
【請求項9】
請求項８に記載の方法であって、前記オブジェクト・データの前記検証に失敗した場合に、前記第１アプリケーションは、完全性エラー・メッセージを生成する、及び／又は前記オブジェクト・データを求める別の要求を生成する、方法。
【請求項10】
請求項６乃至９の何れか１項に記載の方法であって、前記第２アプリケーションは、複数の地図タイルについて前記少なくとも１つの遠隔サーバから取得されたデータを記憶する地図タイル・キャッシュを含み、前記第２アプリケーションは、前記オブジェクト・データが前記地図タイル・キャッシュ内に存在するかどうかを最初にチェックすることによって前記オブジェクト・データを取得するように動作可能であり、前記要求に関する前記オブジェクト・データが前記地図タイル・キャッシュ内に存在する場合に、前記第２アプリケーションは、前記地図タイル・キャッシュから前記オブジェクト・データを読み込むが、前記オブジェクト・データが前記地図タイル・キャッシュ内に存在しない場合に、前記第２アプリケーションは、前記オブジェクト・データを求める要求を前記サーバに発行する、方法。
【請求項11】
請求項１０に記載の方法であって、前記又は各地図タイル・データ構造は、前記タイル・データ構造の真正性及び／又は完全性を検証するためのデジタル署名を有し、前記第２アプリケーションは、前記データを前記地図タイル・キャッシュに追加する前に、前記関連付けられたデジタル署名を使用して、前記少なくとも１つのサーバから受信された前記地図タイル・データ構造の真正性及び／又は完全性を検証する、方法。
【請求項12】
請求項１乃至１１の何れか１項に記載の方法であって、前記地図タイルは、前記地理的エリアの部分内の前記ナビゲート可能なネットワークを、ノードによって接続された複数のアークとして表し、タイルの各アーク及びノードは、それに関連付けられたオブジェクト・データ及びセキュリティ・データを有する、方法。
【請求項13】
車両の電子制御ユニット（ＥＣＵ）上で実行される１つ以上の地図ベース・アプリケーションへ少なくとも１つの遠隔サーバからデジタル地図データを提供するために地理的エリア内のナビゲート可能なネットワークを移動する前記車両の１つ以上の中央処理ユニット上で実行されるクライアント・アプリケーションを動作させる方法であって、前記クライアント・アプリケーションは、第１アプリケーション及び第２アプリケーションを含み、前記第１アプリケーションは、前記地図ベース・アプリケーション及び前記第２アプリケーションと通信し、前記第２アプリケーションは、前記少なくとも１つの遠隔サーバと通信し、前記少なくとも１つの遠隔サーバは、（ｉ）複数の地図タイルを記憶する地図タイル・データ・ストアであって、各地図タイルは、前記地理的エリアの部分内の前記ナビゲート可能なネットワークを、ノードによって接続された複数のアークとして表す、地図タイル・データ・ストアと、（ｉｉ）前記地図タイル・データ・ストア内の前記地図タイルのそれぞれについてのメタデータを記憶する地図タイル・メタデータ・ストアとにアクセスし、タイルの各アーク及びノードは、オブジェクト・データと、それに関連付けられたハッシュ値とを有し、前記ハッシュ値は、個別のアーク又はノードについての前記オブジェクト・データと、前記個別のアーク又はノードについての前記オブジェクト・データを含む前記タイルについてのタイル・メタデータとに少なくとも基づいて前記サーバにおいて計算され、前記第２アプリケーションは、（ｉ）前記少なくとも１つの遠隔サーバから取得された複数の地図タイルを記憶する地図タイル・キャッシュと、（ｉｉ）前記少なくとも１つの遠隔サーバから取得された前記地図タイル・キャッシュ内の前記地図タイルのそれぞれについての前記メタデータを記憶する地図タイル・メタデータ・キャッシュと、を含み、前記方法は、
前記第１アプリケーションによって、前記ナビゲート可能なネットワークの特徴に関するデジタル地図データを求める前記地図ベース・アプリケーションからの要求を受信することと、
前記第１アプリケーションによって、前記第２アプリケーションに、前記要求されたデジタル地図データに関する前記少なくとも１つのアーク又はノードについての前記オブジェクト・データ及びハッシュ値を要求することと、
前記第２アプリケーションによって、前記要求されたオブジェクト・データ及びハッシュ値を、前記地図タイル・キャッシュから、又は前記要求されたタイルが前記地図タイル・キャッシュに記憶されていないならば前記地図タイル・データ・ストアから取得し、それらを前記第１アプリケーションに提供することと、
前記第１アプリケーションによって、前記第２アプリケーションに、前記要求されたデジタル地図データに関する前記少なくとも１つのアーク又はノードに関する前記地図タイルについての前記メタデータを要求することと、
前記第２アプリケーションによって、前記要求されたタイル・メタデータを、前記地図タイル・メタデータ・キャッシュから、又は前記要求されたタイル・メタデータが前記地図タイル・メタデータ・キャッシュに記憶されていないならば前記地図タイル・メタデータ・ストアから取得し、それを前記第１アプリケーションに提供することと、
前記第１アプリケーションによって、前記受信されたオブジェクト・データ及びタイル・メタデータに基づいて、前記少なくとも１つのアーク又はノードについての新たなハッシュ値を計算することと、
前記第１アプリケーションによって、前記新たなハッシュ値を前記受信されたハッシュ値と比較することと、
前記第１アプリケーションによって、前記比較に基づいて、前記要求されたデジタル地図データ又は完全性エラー・メッセージとの何れかを前記地図ベース・アプリケーションに提供することと、を有する方法。
前記第１アプリケーションによって、前記ナビゲート可能なネットワークの特徴に関するデジタル地図データを求める前記地図ベース・アプリケーションからの要求を受信することと、
前記第１アプリケーションによって、前記第２アプリケーションに、前記要求されたデジタル地図データに関する前記少なくとも１つのアーク又はノードについての前記オブジェクト・データ及びハッシュ値を要求することと、
前記第２アプリケーションによって、前記要求されたオブジェクト・データ及びハッシュ値を、前記地図タイル・キャッシュから、又は前記要求されたタイルが前記地図タイル・キャッシュに記憶されていないならば前記地図タイル・データ・ストアから取得し、それらを前記第１アプリケーションに提供することと、
前記第１アプリケーションによって、前記第２アプリケーションに、前記要求されたデジタル地図データに関する前記少なくとも１つのアーク又はノードに関する前記地図タイルについての前記メタデータを要求することと、
前記第２アプリケーションによって、前記要求されたタイル・メタデータを、前記地図タイル・メタデータ・キャッシュから、又は前記要求されたタイル・メタデータが前記地図タイル・メタデータ・キャッシュに記憶されていないならば前記地図タイル・メタデータ・ストアから取得し、それを前記第１アプリケーションに提供することと、
前記第１アプリケーションによって、前記受信されたオブジェクト・データ及びタイル・メタデータに基づいて、前記少なくとも１つのアーク又はノードについての新たなハッシュ値を計算することと、
前記第１アプリケーションによって、前記新たなハッシュ値を前記受信されたハッシュ値と比較することと、
前記第１アプリケーションによって、前記比較に基づいて、前記要求されたデジタル地図データ又は完全性エラー・メッセージとの何れかを前記地図ベース・アプリケーションに提供することと、を有する方法。
【請求項14】
請求項１乃至１３の何れか１項に記載の方法であって、前記地図ベース・アプリケーションは自動運転アプリケーションである、又は前記地図ベース・アプリケーションは地図データを自動運転アプリケーションに順に提供する車両ホライズン・プロバイダであり、前記関連付けられたセキュリティ・データに基づく要求されたオブジェクト・データの検証に失敗した場合に、前記自動運転アプリケーションは、セーフ・モードで前記車両を動作させる、及び／又は前記車両を安全な停止に至らせる、方法。
【請求項15】
車両の電子制御ユニット（ＥＣＵ）上で実行される１つ以上の地図ベース・アプリケーションへ少なくとも１つの遠隔サーバからデジタル地図データを提供するために地理的エリア内のナビゲート可能なネットワークを移動する前記車両の１つ以上の中央処理ユニット上で実行されるクライアント・アプリケーションを動作させる方法であって、前記クライアント・アプリケーションは、前記ＥＣＵ上で動作される第１アプリケーションと、第２アプリケーションとを含み、前記第１アプリケーションは、前記地図ベース・アプリケーション及び前記第２アプリケーションと通信し、前記第２アプリケーションは、前記少なくとも１つの遠隔サーバと通信し、前記少なくとも１つの遠隔サーバは、複数の地図タイルを記憶する地図タイル・データ・ストアにアクセスし、各地図タイルは、前記地理的エリアの部分内の前記ナビゲート可能なネットワークを、ノードによって接続された複数のアークとして表し、タイルの各アーク及びノードは、それに関連付けられたオブジェクト・データを有し、前記第２アプリケーションは、前記少なくとも１つの遠隔サーバから取得された複数の地図タイルを記憶する地図タイル・キャッシュを含み、前記方法は、
前記第１アプリケーションによって、前記ナビゲート可能なネットワークの特徴に関するデジタル地図データを求める前記地図ベース・アプリケーションからの要求を受信することと、
前記第１アプリケーションによって、前記第２アプリケーションに、前記要求されたデジタル地図データに関する前記少なくとも１つのアーク又はノードについての前記オブジェクト・データを要求することと、
前記第２アプリケーションによって、前記要求されたオブジェクト・データを取得することであって、前記要求されたオブジェクト・データは、前記要求されたオブジェクト・データが前記地図タイル・キャッシュ内に存在するならば前記地図タイル・キャッシュから、又は前記要求されたオブジェクト・データに関連付けられた前記要求されたタイルが前記地図タイル・キャッシュ内に存在しないなら前記地図タイル・データ・ストアから取得される、ことと、
前記要求されたオブジェクト・データを前記第１アプリケーションに提供することと、
前記第１アプリケーションによって、前記ナビゲート可能なネットワークの前記特徴に対応する前記オブジェクト・データの前記部分を識別することと、
前記第１アプリケーションによって、前記オブジェクト・データの前記識別された部分を使用して、前記要求されたデジタル地図データを前記地図ベース・アプリケーションに提供することと、を有する方法。
前記第１アプリケーションによって、前記ナビゲート可能なネットワークの特徴に関するデジタル地図データを求める前記地図ベース・アプリケーションからの要求を受信することと、
前記第１アプリケーションによって、前記第２アプリケーションに、前記要求されたデジタル地図データに関する前記少なくとも１つのアーク又はノードについての前記オブジェクト・データを要求することと、
前記第２アプリケーションによって、前記要求されたオブジェクト・データを取得することであって、前記要求されたオブジェクト・データは、前記要求されたオブジェクト・データが前記地図タイル・キャッシュ内に存在するならば前記地図タイル・キャッシュから、又は前記要求されたオブジェクト・データに関連付けられた前記要求されたタイルが前記地図タイル・キャッシュ内に存在しないなら前記地図タイル・データ・ストアから取得される、ことと、
前記要求されたオブジェクト・データを前記第１アプリケーションに提供することと、
前記第１アプリケーションによって、前記ナビゲート可能なネットワークの前記特徴に対応する前記オブジェクト・データの前記部分を識別することと、
前記第１アプリケーションによって、前記オブジェクト・データの前記識別された部分を使用して、前記要求されたデジタル地図データを前記地図ベース・アプリケーションに提供することと、を有する方法。
【請求項16】
請求項６乃至１５の何れか１項に記載の方法であって、前記第２アプリケーションは、前記第１アプリケーションよりも低い機能安全性規格に従って開発される、方法。
【請求項17】
請求項１６に記載の方法であって、前記第１アプリケーションは、少なくともＩＳＯ２６２６２：２０１８ＡＳＩＬ－Ｂ機能安全性規格に従って開発される、方法。
【請求項18】
請求項６乃至１７の何れか１項に記載の方法であって、前記第１アプリケーションは、冗長に実装される、方法。
【請求項19】
請求項６乃至１８の何れか１項に記載の方法であって、前記第１アプリケーションは、前記地図ベース・アプリケーションと同じ処理プラットフォーム上で実行される、方法。
【請求項20】
請求項１９に記載の方法であって、前記処理プラットフォームは、前記車両の電子制御ユニット（ＥＣＵ）を含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は一般に、例えばクラウド・サーバ環境から送信されているデジタル地図データを、車両に搭載されて実行される地図ベース・アプリケーションに提供するための方法及びシステムに関する。実施形態は、向上した機能安全性を有するこのようなデジタル地図データを提供するための方法及びシステムに関する。特に、本発明の実施形態は、例えば高度／自動運転アプリケーションで使用するために提供される前に、高精細度（ＨＤ）地図データの完全性（及び真正性）を検証するための技術に関する。実施形態はまた、このような文脈についてクライアント・アプリケーションを動作させる方法に関する。
【背景技術】
【0002】
ナビゲーション・システムは、所望の目的地に到達するように運転者を支援するためにデジタル地図を使用する。このようなデジタル地図は、典型的に、複数のナビゲート可能なセグメント（すなわち、「アーク」）の集合と、道路セグメントを互いに接続するノードとから成り、これらはナビゲート可能な（例えば、道路）ネットワークの適切なグラフ表現を形成する。デジタル地図要素は、例えば経路計画目的のために、目的地までのパスのコストを決定する際に使用されうる、関連するナビゲーション・コスト・パラメータを有する。基本的な道路レベルのナビゲーション及び経路計画サービス（のみ）を支援するデジタル地図は、規格定義地図（ＳＤ地図）と呼ばれることがある。
【0003】
より高度な自動運転（ＡＤ）及び高度運転者支援システム（ＡＤＡＳ）機能を提供するために、道路形状及び車線形状の両方の高度に詳細かつ精密な３次元ビューを提供する、いわゆる高精密度地図（ＨＤ地図）を使用することが必要である。よって、道路形状を規定するアーク及びノードに加えて、このようなＨＤ地図は、車線区分線、車線中心線、道路境界などを記述する車線モデルも含む。よって、典型的なＨＤ地図は、連結エリア及び車線グループを表すアークの集合と、アーク間の接続を記述するノードの集合とを備える。連結エリア及び車線グループは、路面を側方から側方まで（並びに走行方向に沿って）記述する。ＨＤ地図は事実上車両の視界範囲を、そのローカル・センサの範囲を超えて拡大し、それによって、より滑らかで、より安全で、より効率的な運転シナリオを可能にする。
【0004】
ＡＤ／ＡＤＡＳアプリケーションは高度に自動化された運転機能を提供してもよく、その安全性は、車両が走行中のナビゲート可能な（例えば、道路）ネットワークのエリアを反映する正確で最新のＨＤ地図データを受信することに極めて依存していることが理解されよう。したがって、ナビゲート可能な（例えば、道路）ネットワークの周りで車両をナビゲートするためにＡＤ／ＡＤＡＳアプリケーションによって使用されているこのようなデータの完全性又は真正性が損なわれるならば、これは、深刻な（致命的でさえある）結果をもたらしうる。
【0005】
したがって、デジタル地図データは「安全上重要」であり、自動車内システムに要求される規制基準を満たすために、その信頼性が保証されなければならない。例えば、データが例えば記憶及び／又は送信中に破損されないことが保証されるべきである。さらに、データのセキュリティは安全性のための前提条件であり、ＡＤ／ＡＤＡＳアプリケーションがセキュリティ脅威から保護されることが保証されなければならない。したがって、ＡＤ／ＡＤＡＳアプリケーションの機能安全性を達成する際に、これらの側面が考慮されなければならない。
【0006】
車内セーフティ・クリティカル・システムの機能安全性は一般に、ＩＳＯ２６２６２機能安全性規格に準拠したものを開発することによって実現される。セーフティ・クリティカル地図データの製作は、意図された機能（ＳｏＴＩＦ）の安全のためのＩＳＯ２１４４８規格に従うことになる。よって、このようなデジタル地図データの信頼性を保証することは、地図データ配信及び配信システムの開発に一定の要件を課す。しかし、地図配信システム、すなわち地図クライアント（インタフェース）に関連するインタフェース及び機能構成要素の数に起因して、このような地図クライアント（インタフェース）は機能的に複雑なソフトウェア構成要素であることが理解されよう。したがって、所要の機能安全性レベルで地図データ配信及び配布システムを実装することは、労働集約的かつ複雑でありうる。よって、ＡＤ／ＡＤＡＳアプリケーションのための所望の機能安全性要件を満たすことは、典型的に地図配信及び配布システムの設計、試験、及び支援のための著しい負担を伴い、このような複雑な実装は典型的に処理及び記憶リソースの増加を必要とする。
【0007】
ＡＤ／ＡＤＡＳアプリケーションのためのデジタル地図データは典型的に、例えばクラウド・サーバ環境において、１つ以上の地図データ・ソースから適切なソース・データを編集することによって遠隔で生成され、その後、地図データは地図データを必要とする車両にクラウドから配信される。その後、車内配布ネットワークは、地図データを必要とするＡＤアプリケーションに（及び／又は車両に搭載されて実行される他の地図ベース・アプリケーションに）必要に応じて地図データを配布する。
【0008】
地図データのより効率的な配信を提供するために、デジタル地図を複数の地図タイルとして表すことが知られており、各地図タイルは地図エリア全体の部分を表し、地図タイルによってカバーされるエリア内に入るオブジェクトを示すデータを含む。例えば、地図タイルの集合は、ノードによって接続された複数のアークとして地理的エリアの異なる部分におけるナビゲート可能なネットワーク（例えば、道路）を表す集合内の異なる地図タイルで提供されうる。よって、そのエリア内のナビゲート可能な（例えば、道路）ネットワークを規定するアーク及びノードの集合に関係する少なくともオブジェクト・データが、地図タイルについて記憶されうる。これは、アーク／ノード自体の特性を規定する（例えば、そのエリア内の道路／車線形状を規定する）オブジェクト・データと、アーク／ノードに関連するオブジェクト、例えば交通標識などのデータとを含んでもよい。当然ながら、望ましくは地図に含まれてもよい任意の他の適切な情報が、タイルについて記憶されてもよい。地図ベース・アプリケーションがナビゲート可能な（例えば、道路）ネットワーク内のある特徴又は位置に関する情報を必要とする場合に、適切な地図（すなわち、オブジェクト）データを取得するために、関連する地図タイルを求める要求が発行されうる。
【0009】
このような要求は、典型的に、車両上で実行される適切なクライアント・アプリケーション（インタフェース）によって処理される。クライアント・アプリケーション（インタフェース）は地図タイルを受信し、その後、関連する地図データを抽出するためにこれらを適宜処理する。その後、クライアント・アプリケーション（インタフェース）は、所望に応じて、地図データを任意の、例えばＡＤ／ＡＤＡＳアプリケーションに配布することができる。これは、典型的に、例えば現在の車両位置、駆動条件、及び道路データに基づいて、予測される近づきつつある運転パスを考慮することによって生成される適切な「ホライズン」を参照して行われている。そして、ホライズンは、例えばＡＤ／ＡＤＡＳ機能を実装するために、動的（例えば、センサ）データを追加することができるホライズンに至るエリア内のサブ地図を表す地図タイルの集合に関連する。典型的に、対応する複数の予測運転パスに対して複数のホライズンが生成され、予測運転パスの任意の１つから逸脱する車両をより良く考慮し、調整することができる。
【0010】
ホライズンに関連するサブ地図データは例えば、高度運転支援システム・インタフェース仕様（ＡＤＡＳＩＳ）プロトコルに従って、ＡＤ／ＡＤＡＳアプリケーションに提供されうる。例えば、新たなＡＤＡＳＩＳ Ｖ３規格は、多くの場合に車内ＨＤ地図配布に使用される。ＡＤＡＳＩＳ Ｖ３は、ホライズン・プロバイダ、ホライズン再コンストラクタ、及びプロバイダと再コンストラクタとの間で使用されるＡＤＡＳＩＳ Ｖ３プロトコルからなる。ＡＤＡＳＩＳ Ｖ３プロトコルは、典型的に、車内ネットワーク、例えばイーサネットを使用する。サブ地図データがＡＤ／ＡＤＡＳアプリケーションに提供されると、アプリケーションは通常の方法で、例えばホライズン内の地図データを動的センサ・データと比較することなどによって、予測運転戦略を計画できる。
【0011】
よって、このようなシステムは、地図データを車両に直接配信することを可能にする。しかし、地図データがタイルの集合として提供される場合に、ＡＤ／ＡＤＡＳアプリケーションによって使用されている地図データの機能安全性を保証することは依然として困難でありうる。さらに、機能安全性を達成するための既存のアプローチは、実施するのが比較的複雑でありえ、必要とされる機能安全性を実現できる、より効率的なクライアント・アプリケーション（インタフェース）を提供することが望ましい。
【0012】
したがって、本出願人は、例えばＡＤ／ＡＤＡＳアプリケーションについて所望の機能安全性要件を依然として満たしながら地図データを提供する改善された方法の余地が残っていると信じる。
【発明の概要】
【0013】
本発明の第１側面によれば、デジタル地図によってカバーされたナビゲート可能なネットワークを移動する車両の電子制御ユニット（ＥＣＵ）上で実行される１つ以上の地図ベース・アプリケーションへ遠隔サーバから送信されている地図データを検証する方法であって、前記デジタル地図は、複数の地図タイルの集合として表され、各タイルは、前記ナビゲート可能なネットワークの部分を含む特定の地理的エリアを表し、前記方法は、
地図タイルについてのデータ構造をサーバにおいて生成することであって、前記データ構造は、前記タイルによってカバーされた前記地理的エリア内及び／又は前記デジタル地図を表す前記タイルのうちの別の１つ以上によってカバーされた前記地理的エリア内に少なくとも部分的に入る１つ以上のオブジェクトの集合を示すオブジェクト・データを含み、
前記地図タイル・データ構造にオブジェクト・データが含まれる１つ以上のオブジェクトの集合内の少なくとも１つのオブジェクトについて、前記少なくとも１つのオブジェクトについての前記オブジェクト・データとともに前記地図タイル・データ構造内に、関連付けられたセキュリティ・データが含まれ、前記セキュリティ・データは、その関連付けられたオブジェクト・データの完全性を検証するために使用可能である、ことと、
前記オブジェクト・データ及び関連付けられたセキュリティ・データを含む前記タイルについての前記地図タイル・データ構造を、前記サーバから、前記車両の１つ以上の処理ユニット上で実行されるクライアント・アプリケーションへ送信することと、を有する方法が提供される。
地図タイルについてのデータ構造をサーバにおいて生成することであって、前記データ構造は、前記タイルによってカバーされた前記地理的エリア内及び／又は前記デジタル地図を表す前記タイルのうちの別の１つ以上によってカバーされた前記地理的エリア内に少なくとも部分的に入る１つ以上のオブジェクトの集合を示すオブジェクト・データを含み、
前記地図タイル・データ構造にオブジェクト・データが含まれる１つ以上のオブジェクトの集合内の少なくとも１つのオブジェクトについて、前記少なくとも１つのオブジェクトについての前記オブジェクト・データとともに前記地図タイル・データ構造内に、関連付けられたセキュリティ・データが含まれ、前記セキュリティ・データは、その関連付けられたオブジェクト・データの完全性を検証するために使用可能である、ことと、
前記オブジェクト・データ及び関連付けられたセキュリティ・データを含む前記タイルについての前記地図タイル・データ構造を、前記サーバから、前記車両の１つ以上の処理ユニット上で実行されるクライアント・アプリケーションへ送信することと、を有する方法が提供される。
【0014】
本発明は一般に、デジタル地図データの生成及び提供に関し、特に、高度及び／又は自動運転アプリケーションに適した高精細度（ＨＤ）デジタル地図データの提供に関する。特に、自動運転（ＡＤ）アプリケーションについて、地図データは安全上重要であり、したがって、車内安全上重要なシステムの安全性要件を満たすために、その信頼性が保証されなければならないことが理解されよう。よって、本発明の実施形態は、例えば車両に搭載されて実行される地図ベース・アプリケーションに配布され使用される前に、このようなデジタル地図データを検証するための方法に関する。さらに、所望の安全性要件を満たすことができる地図クライアント・インタフェースを開発することは、困難かつ集中的でありうる。よって、本発明の実施形態はまた、以下でさらに説明されるように、機能安全性の向上した（例えば、ＡＳＩＬ－８）レベルを有する地図クライアント・アプリケーションの効率的な実装に関する。
【0015】
例えば、本発明の第１態様の実施形態では、「オブジェクト・レベル」でデジタル地図データを検証するための方法が提供され、これは以下でさらに説明されるように、地図データが送信目的のために複数の地図タイル・データ構造にパッケージ化される場合でさえも、個々の地図オブジェクトが大幅な追加のストレージ及び／又は送信オーバヘッドなしに、効率的な方法で検証されることを可能にする。
【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】
単なる例として、添付の図面を参照して、様々な実施形態がここで説明される。
【図1】地図配信システムの概要を示す。
【図2】、
【図3】、
【図4】、
【図5】、
【図6】、
【図7】、
【図8】実施形態に従ってデジタル地図がどのように編集されうるかを概略的に示し、デジタル地図は、それぞれが複数のタイルを使用して表される複数のレイヤを含む。
【図9】クラウドから、１つ以上の地図ベース・アプリケーションを実行する車両に地図データが配信される実施形態によるクラウド・ベースの地図配信システムを概略的に示す。
【図10】実施形態による地図データを処理するためのクライアント・アプリケーションを概略的に示す。
【図11】実施形態による地図データをローカルに記憶するために使用されてもよいキャッシュを概略的に示す。
【図12】実施形態によるクラウド・ベースの地図データ配信システムを概略的に示す。
【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】
ＨＤ地図検証器３０３は、要求される機能安全性を実現するための不可欠な部分である。すべてのオブジェクト・レベル安全性メカニズムはハッシュに基づいている。６４ビットに切り捨てられたＳＨＡ－２５６ハッシュが使用される。これは、６４ビットが許容可能な小さいサイズであるのに対し、２-64（＝５．４２×１０-20）の衝突確率は同じ低安全性メカニズムの失敗率に変換されるためである。クライアント・フロントエンド９２は、オブジェクト・データの完全性及び検証をチェックする。クライアント・フロントエンド９２はまた、最新の地図バージョンの完全性をチェックするか、又は任意の他の所望の安全性チェックを実行してもよい。
【0093】
クライアント・バックエンド９１は図１１にも示されており、６つの構成要素、すなわち、ＨＤ地図ＲＰＣサービス・スタブ２０１、クライアント・ライブラリ２０２、永続キャッシュ２０３、タイル検証器２０４、ＨＴＴＰＳクライアント２０５、及びコントローラ２０６を備える。クライアント・バックエンド９１は、標準的な品質管理（ＱＭ）規定の手順を用いて開発されたソフトウェア・ライブラリである。ライブラリは、ＡＳＩＬ－Ｂ準拠ＥＣＵプラットフォーム・オペレーティング・システム１０５によって提供されるプロセス上にデプロイされる他のソフトウェア及び実行可能体の部分にリンクされる。クライアント・バックエンドは、そのコントローラ構成要素２０６によって提供されるインタフェースを介して、初期化され、制御され、監視される。コントローラは他のクライアント・バックエンド組み込み構成要素と対話するが、これらの対話のためのインタフェースは図１１には示されていない。
【0094】
クライアント・フロントエンド９２から受信されたサービス要求は、クライアント・ライブラリ２０２に渡される。クライアント・ライブラリは、永続タイル・キャッシュ２０３から、又はクラウド・サービスから、すなわちタイル・データ・サービス１８及びタイル・メタデータ・サービス１４から、タイル・データ及びタイル・メタデータを読み出す必要がありうるこれらの要求にサービス提供する。クラウド・サービスから受信されたタイル・データ及びタイル・メタデータを使用する前に、その完全性及び真正性がタイル検証器２０４によって検証される。例えば、地図タイルはそれぞれ、（少なくとも１つの遠隔サーバによって適用される）デジタル署名を有してもよい。署名は、データがクライアント・フロントエンドに提供される前に、クライアント・バックエンドによって検証される。デジタル署名をチェックすることは、ハッシュよりも複雑であり、ＡＳＩＬ－Ｂにおいて実装することが困難であることが理解されよう。しかし、これは、クライアント・バックエンド９１内のＱＭレベルで容易に行われうる。
【0095】
検証発行の場合に、タイル・データ・サービスに、及び該当する場合に、開始するサービス要求の応答を介してクライアント・フロントエンド９２に、エラーが報告される。クライアント・フロントエンド内のＨＤ地図ＲＰＣクライアント・スタブ１０２はまた、タイムアウト・メカニズムを含む。このタイムアウト・メカニズムは、クライアント・バックエンド９１が（ＡＰＩ呼び出しパラメータとして渡される）指定されたタイムアウト内にＡＰＩ呼び出しに応答しない場合、タイムアウト・エラーを返す。
【0096】
クライアント・ライブラリ２０２は、後での使用のために容易に利用可能となるように、タイル・データ及びタイル・メタデータを永続キャッシュ２０３に記憶する。永続タイル・キャッシュ２０３から読み出されたデータを使用する前に、その完全性がタイル検証器２０４によって検証される。検証の問題が発生した場合、影響を受けるデータはキャッシュからパージされ、クラウド・サービスから新たに読み出される。図１２に、永続タイル・キャッシュ２０３の概念的な構成が示される。永続タイル・キャッシュは２つのキャッシュ、すなわち、タイル・データ・キャッシュ４０１及びタイル・メタデータ・キャッシュ４０２からなると見なされうる。キャッシュはキャッシュ・レコードの集合、すなわち、タイル・データ・キャッシュ・レコード及びタイル・メタデータ・キャッシュ・レコードを含む。それぞれ独自の一意の地図バージョンを有するいくつかの地図に特定のタイル・バージョンのタイルが存在しうるので、タイル・データ・キャッシュ・レコードは１つ以上の関連するタイル・メタデータ・キャッシュ・レコードを有する。関連付けは、それらが共通して有するタイルｉｄ、レイヤｉｄ、及びタイル・バージョンによって表される。タイル・メタデータ・キャッシュ・レコードは、クラウド・サービスがメタデータ署名を除くレコード全体にわたって計算するメタデータを含む。タイル・メタデータ・ハッシュは、６４ビットの切り捨てられたＳＨＡ－２５６ハッシュであり、タイル・メタデータを検証するためにクライアント・フロントエンドによって使用される。
【0097】
クライアント・ライブラリ２０２は、ＨＴＴＰＳクライアント２０５を介してクラウド・サービス１４、１８と対話する。ＨＴＴＰＳクライアント２０５は例えば、タイル・データ・サービス１８及びタイル・メタデータ・サービス１４ｅを認証する。例えば、クライアント・バックエンド９１は、ＴＬＳを介してクラウド・サービスと対話してもよい。ＴＬＳサーバとＴＬＳクライアントとの間で送信されるすべてのメッセージは暗号化され、傍受されてもプライベートのままである。ＴＬＳは、メッセージ・ダイジェストを計算することによってメッセージ完全性を提供する。証明書チェーン・ベースの証明書検証は、ＴＬＳクライアント（すなわち、クライアント・バックエンド９１）がＴＬＳサーバ（すなわち、地図データ・サーバ及び地図メタデータ・サーバ）を認証することを可能にする。タイルを読み出すために、ＨＴＴＰＳクライアントは、まず、タイル・メタデータ・サービス１４からタイル・メタデータを読み出す。このメタデータは、タイルが永続タイル・キャッシュ２０３にまだ存在しない場合に、タイル・データ・サービス１８からタイルを読み出すために使用される関連するタイルのＵＲＩを含む。
【0098】
地図タイル及び地図タイル・メタデータは、それぞれタイル・データ・キャッシュ・レコード及びタイル・メタデータ・キャッシュ・レコードに記憶される。キャッシュ・レコードは、クラウド・サービスによってデジタル署名され、タイル検証器によって検証される。これにより、永続タイル・キャッシュのすべてのコンテンツがデジタル署名される。デジタル署名の作成及び検証は、クラウド内の秘密暗号鍵及び車両内の関連する公開復号鍵を使用する非対称暗号方式に依存している。検証に成功した後、タイル・データ及びタイル・メタデータの完全性及び真正性の両方が保証される。
【0099】
クライアント・フロントエンドのＡＳＩＬ－Ｂ安全性メカニズムは、クライアントがＨＤ地図アプリケーションに提供するＨＤ地図データの完全性を検証する。これらの安全性メカニズムは、アーク（すなわち、車線グループ及び連結エリア）、アーク関連属性、及びノードのレベルで動作する。このレベルがクライアント・フロントエンドによって保証されるため、クライアント・バックエンドはＡＳＩＬ－Ｂレベルで開発される必要がない。よって、クライアント・バックエンドは、例えばＩＳＯ２６２６２：２０１８ＱＭに準拠して開発されてもよい。
【0100】
クライアント・フロントエンド９２及びバックエンド９１は両方とも、同じＥＣＵプラットフォーム上にデプロイされ、ＲＰＣによって、基礎となるＥＣＵプラットフォーム提供のＩＰＣと対話してもよい。これは、ＥＣＵプラットフォームＯＳによって提供される安全なＩＰＣに依存することを可能にし、すなわち、プロセッサ間通信のための安全な通信プロトコル・スタックが回避される。例えば、クライアント・フロントエンド及びクライアント・バックエンドの両方は、他のコードとリンクされ関連する実行可能体に存在するＣ＋＋ライブラリを含んでもよい。これらの実行可能体は、同じＥＣＵプラットフォーム上にデプロイされ、ＲＰＣによって、基礎となるＥＣＵプラットフォーム提供のＩＰＣと対話する。その場合、ＱＭ部分（クライアント・バックエンド）及びＡＳＩＬ－Ｂ（Ｂ）部分（クライアント・フロントエンド）の十分な独立性は、それらを、基礎となるＡＳＩＬ－Ｂ準拠ＥＣＵプラットフォーム・オペレーティング・システムによって提供される別々のプロセスにデプロイすることによって実現されうる。フロントエンドとバックエンドの間のＲＰＣベースの対話は、ＡＳＩＬ－Ｂ準拠のＥＣＵプラットフォームによっても提供される安全なＩＰＣメカニズムに依存する。しかし、これは必ずしもそうである必要はなく、異なるＥＣＵプラットフォーム上にあってもよい。
【0101】
よって、本実施形態は、向上した障害回復力を有する自律車両アプリケーションのための拡張地図クライアントの実装に関する。特に、地図クライアント実装全体に回復技術を適用する代わりに、地図クライアント・バックエンド９１と、地図クライアント・フロントエンド９２とを備える拡張地図クライアントが提供され、地図クライアント・フロントエンド９２（のみ）が機能安全性向上技術を用いて設計される。ここで、本実施形態に係るシステムの動作全体の詳細な説明が提供される。しかし、他の構成ももちろん可能である。
【0102】
上述のように、地図クライアント・フロントエンド９２は、地図アプリケーション（又は複数の地図アプリケーション）及び地図クライアント・バックエンド９１とのインタフェースを有する。ＨＤ地図アプリケーションは、障害検出、障害報告、及び障害診断のためのサービス・インタフェースで拡張された地図クライアント・サービス・インタフェースを備える障害回復地図クライアント・サービス・インタフェースを使用して、地図クライアント・フロントエンド９１と対話する。
【0103】
よって、地図クライアント・フロントエンド９２は、障害監視を提供し、障害回復地図クライアント・サービス・インタフェースを使用して、任意の検出された障害をＨＤ地図アプリケーションに報告する。地図クライアント・フロントエンドの目的は、地図クライアントの障害を、それが提供するデータの完全性を検証することによって検出することである。地図クライアントからのデータで障害が検出された場合に、地図クライアント・フロントエンドは障害のあるデータを破棄し、ＨＤ地図アプリケーションに障害を報告する。
【0104】
本実施形態では、地図クライアント・フロントエンド９２は、地図サーバ・インフラストラクチャの地図タイル・コンパイラ１２内のＨＤ地図機能安全性モジュール１２１０によって生成されたＨＤ道路オブジェクト・データに関連付けられた機能安全性データを使用する。地図タイル・コンパイラ１２は、ＨＤ道路アーク及びＨＤ道路ノード（地図オブジェクト）を編集し、その後、これらの編集されたデータ構造（地図オブジェクト）にわたって「機能安全性データ」を生成する。
【0105】
地図クライアント・バックエンド９１は、ＨＤ道路オブジェクト・データを有するタイル・データを受信し、検証し、キャッシュする。しかし、これは、ＨＤ道路オブジェクト・データ（アーク及びノード・データ）又はそれに関連付けられた機能安全性データを修正、生成、拡張、又は操作しない。したがって、地図クライアントによって出力されるようなＨＤ道路オブジェクト・データ及び関連付けらえた機能安全性データは、地図サーバ・インフラストラクチャ内で生成されるデータと同一であるはずである。
【0106】
地図クライアント・フロントエンド９２は、ＨＤ道路オブジェクト・データを有する機能安全性データを受信する。機能安全性データがＨＤ道路オブジェクト・データと一致しないならば、これは、データを提供する地図クライアントに障害があったことを示す。地図クライアントから受信されたデータに障害を検出した後、地図クライアント・フロントエンドはデータをブロックし、データを要求したＨＤ地図アプリケーションに障害を報告する。ＨＤ地図アプリケーションは、障害報告を使用して、適切な応答をトリガしてもよい。よって、地図クライアント・フロントエンドは、地図クライアント・モジュールの障害から、及び地図サーバから地図クライアント・フロントエンドへの通信パスの障害から、ＨＤ地図アプリケーションを保護する。
【0107】
地図クライアント・フロントエンドの障害検出機能は、地図クライアント・バックエンドの機能の集合と比較して小さい。これは、機能安全性工学技術を使用する実装に適していることを意味する。地図クライアント・フロントエンドの機能安全性実装は、地図クライアントのすべての障害を検出して報告し、その機能安全性工学実装に起因して、地図クライアント・フロントエンド実装自体の障害に対しても障害回復力がある。地図クライアントとクライアント・フロントエンドとの組合せは、拡張地図クライアントと呼ばれる。本発明による拡張地図クライアントは、（規格）地図クライアント実装と、機能安全性地図クライアント・フロントエンド実装とからなる。拡張地図クライアントのこの実装は、機能安全性要件への準拠を提供する。これは、地図クライアントのみの機能安全性実装と比較して、実質的に少ないリソースを使用してこれを実現する。
【0108】
拡張地図クライアントは、リソース（ハードウェア、ソフトウェア、ストレージ、エネルギー、開発、テスト、保守）をわずかに増加させるだけで、ＨＤ地図アプリケーションのための機能安全性地図クライアント・サービス・インタフェースを提供する。
【0109】
上述の方法で地図クライアント２２を分割する別の利点は、クライアント・バックエンド９１における実装強化から地図アプリケーションを保護することをクライアント・フロントエンド９２が助けることである。変形の地図クライアントの実装は、拡張地図クライアントの機能安全性準拠に影響を与えることなく、通常の開発実務を使用して障害回復力を向上してもよい。拡張地図クライアントの構造に起因して、地図クライアント・フロントエンド９２の実装は、地図クライアント・バックエンド９１の機能から独立している。地図クライアント・フロントエンド実装によって機能安全性準拠が決定されるため、地図クライアントに対するいかなる変更も、拡張地図クライアントの機能安全性準拠に影響しない。
【0110】
地図クライアント・フロントエンド９２はまた、要求に（タイムリーに）応答しないようにする地図クライアント・バックエンド９１内の障害に対処するように構成されてもよい。地図クライアント・バックエンド９１は例えば、閾値応答時間をＨＤ地図アプリケーションからの各要求に関連付け、要求に関連付けられた閾値応答時間内に地図クライアントが要求に応答しない場合に、ＨＤ地図アプリケーションにタイムアウト障害応答を返してもよい。
【0111】
地図クライアント・バックエンド９１のＨＴＴＰＳクライアント回路２０５は、データ構造タイルを取得する。地図クライアント・バックエンド９１のクライアント・ライブラリ回路２０２は、まず、地図クライアント・バックエンド９１のタイル検証回路２０４へタイルを送信する。タイル検証回路２０４は、タイル署名７０３を使用して、受信されたタイル・データ構造７００の真正性及び完全性を検証する。タイル検証の後、クライアント・ライブラリ回路２０２は、タイル・データ７０２を記憶するために、タイルを永続タイル・キャッシュ２０３へ送信する。
【0112】
地図クライアント・バックエンド９１の地図インタフェース・アダプタ回路は、ＨＤ地図アプリケーションからＨＤ道路オブジェクト・データを求める要求を受信する。そして、それは、これらの要求をクライアント・ライブラリ回路に転送する。要求は、特定のＨＤ道路オブジェクトｉｄに基づいて、又は特定の場所に基づいて、ＨＤ道路オブジェクトを求めるものでありうる。その結果は、要求されたＨＤ道路オブジェクトが存在しないことであってもよいし、又は１つ以上のＨＤ道路オブジェクトを永続タイル・キャッシュ２０４から返すことであってもよい。要求の結果は、地図クライアント・アダプタ２０１を介してＨＤ地図アプリケーションに返される。ＨＤ道路オブジェクト全体（すなわち、タプル:ＨＤ道路オブジェクトＩＤ、ＨＤ道路データ、機能安全性データ）が返されることに留意されたい。本実施形態では、地図クライアント・フロントエンド９２は、ＨＤ地図アプリケーションからの要求を転送し、返されたＨＤ地図オブジェクトをチェックして、地図クライアント・バックエンド９１内の障害を検出する。地図クライアント・フロントエンド９２は、ＨＤ地図オブジェクト・データ７０４をチェックするためにセキュリティ・データ７０５を使用する。
【0113】
地図クライアント・バックエンド９１がセキュリティ・データ７０５の作成又は処理に何ら関与しないため、地図クライアント・バックエンド９１の機能障害は地図クライアント・フロントエンド９２において確実に検出されうる。
【0114】
よって、上述のシステムは、車両への地図データの配信を可能にする。特に、本実施形態は、後続の車内配布の前に少なくとも所望のＨＤ道路レベル地図データの完全性及び真正性を検証することによって、ＨＤ地図データの車両への安全な配信を保証する。（ナビゲート可能な（例えば、道路）ネットワーク、例えば、交通標識に関連付けられていないＨＤ地図データは、所望される機能安全性のレベルに応じて、検証されてもされなくてもよい。）
例えば、ＨＤ地図データ要求を受け入れると、クライアントは、要求で指定されたＨＤ地図データ（すなわち、正しいデータ）を提供するか、又は完全性エラーを返す。ＨＤ地図データ要求を受け入れると、クライアントは、指定されたタイムアウト内に、要求されたＨＤ地図データを提供するか、又はタイムアウト直後にタイムアウト・エラーを返す。特に、ＨＤ地図データ要求を受け入れると、クライアント・バックエンドはその後、（例えば、認証及びタイル・レベルでのデータの完全性をチェックした後に、）クラウド・サービスから読み出されたＨＤ地図データに等しいＨＤ地図データ、並びに地図データ（すなわち、アーク及びノード）の関連付けられたハッシュ値をクライアント・フロントエンドに提供する。その後、クライアント・フロントエンドは、関連付けられたハッシュ・データを使用してクライアント・バックエンドによって提供されたＨＤ地図データの完全性を検証し、ＨＤ地図データが検証されると、クライアント・フロントエンドは、要求されたＨＤ地図データを地図ベース・アプリケーションに提供できる。ＨＤ地図データを検証できないならば、クライアント・フロントエンドは、データを求める別の要求を発行してもよく、検証されたＨＤ地図データが、例えば、指定されたタイムアウト内に提供されないならば、完全性エラーを発行してもよい。
例えば、ＨＤ地図データ要求を受け入れると、クライアントは、要求で指定されたＨＤ地図データ（すなわち、正しいデータ）を提供するか、又は完全性エラーを返す。ＨＤ地図データ要求を受け入れると、クライアントは、指定されたタイムアウト内に、要求されたＨＤ地図データを提供するか、又はタイムアウト直後にタイムアウト・エラーを返す。特に、ＨＤ地図データ要求を受け入れると、クライアント・バックエンドはその後、（例えば、認証及びタイル・レベルでのデータの完全性をチェックした後に、）クラウド・サービスから読み出されたＨＤ地図データに等しいＨＤ地図データ、並びに地図データ（すなわち、アーク及びノード）の関連付けられたハッシュ値をクライアント・フロントエンドに提供する。その後、クライアント・フロントエンドは、関連付けられたハッシュ・データを使用してクライアント・バックエンドによって提供されたＨＤ地図データの完全性を検証し、ＨＤ地図データが検証されると、クライアント・フロントエンドは、要求されたＨＤ地図データを地図ベース・アプリケーションに提供できる。ＨＤ地図データを検証できないならば、クライアント・フロントエンドは、データを求める別の要求を発行してもよく、検証されたＨＤ地図データが、例えば、指定されたタイムアウト内に提供されないならば、完全性エラーを発行してもよい。
【0115】
地図メタデータは、地図データとは別に転送され、ハッシュによって保護もされる。すなわち、すべての車線グループ及び連結エリアは、それ自体のハッシュを有する関連メタデータを有する。メタデータは、バージョン及びフォーマット情報を含む。
【0116】
図１３に、別の変形の地図データ配布システムが示されている。この実施形態は、車内ＨＤ地図配布システムとして上述のアプローチを利用し、上述のものの拡張である。ここで、単一のクライアント・バックエンド９１が、遠隔プロシージャ呼び出し（ＲＰＣ）によって、車両内に分散された複数のクライアント・フロントエンド９２Ａ、９２Ｂにサービス提供する。車両では、ＲＰＣは典型的に、ＴＣＰ／ＩＰオーバ・イーサネットの上に実装される。セキュアな車内ネットワーク通信に依存して、システムは、ＨＤ地図アプリケーションによって消費されるＨＤ地図データのエンド・ツー・エンド（クラウド・サービスから車内ＨＤ地図アプリケーションへ）を提供する。
【0117】
このシステムは、例えばＡＤＡＳＩＳ Ｖ３が行うよりも多くのデータを車内ネットワークを介して送信することに留意されたい。しかし、ＡＤＡＳＩＳ Ｖ３は、低帯域幅ＣＡＮネットワーク上にデプロイされる必要があるＡＤＡＳＩＳ Ｖ２によってインスパイアされた。ＡＤＡＳＩＳ Ｖ２及びＶ３の両方は、転送されるデータの細粒度選択を可能にする。しかし、イーサネットはＣＡＮよりもはるかに広い帯域幅を有し、そのため、転送するデータの最小量のための最適化はあまり重要ではない。上記で提示されるクライアントは、データの転送及び検証後に細粒度選択を行うためのＡＰＩを提供する。
【0118】
図１４は、単一の地図フロントエンド９２が複数の地図クライアント（クライアント・バックエンド９１Ａ、９１８）によってサービス提供される別の例を示す。
【0119】
よって、本実施形態は、安全でありアプリケーションに配信される前に（車線グループ及び連結エリアのような）有意なエンティティのレベルでＨＤ地図データの完全性／真正性を検証することを含むＨＤ地図配信システムを提供する。さらに、所望の機能安全性は、地図クライアントを、異なるレベルの機能安全性で実装されうるフロント／バックエンドに分割することによって、効率的な方法で実現される。
【0120】
前述の詳細な説明は、例示及び説明の目的のために提示されている。それは、網羅的であること、又は本書に記載される技術を開示される技術に限定することを意図するものではない。上記の教示に照らして、多くの修正及び変形が可能である。記載される実施形態は、本書に記載される技術の原理及びその実用的な用途を最もよく説明するために選択され、それによって、当業者が様々な実施形態において、及び企図される特定の使用に適した様々な修正を伴って、本書に記載される技術を最もよく利用することを可能にする。よって、この明細書、図面、及び／又は特許請求の範囲に開示される特徴は、単独で、又はそれらの様々な組合せで取られた様々な実施形態の実現のための材料であってもよい。さらに、様々な実施形態を参照して本発明を説明してきたが、形態及び詳細における様々な変更が、添付の特許請求の範囲に記載されるような本発明の範囲から逸脱することなくなされ得ることが、当業者によって理解されよう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【手続補正書】
【提出日】2024-07-30
【手続補正1】
【補正対象書類名】明細書
【補正対象項目名】００６５
【補正方法】変更
【補正の内容】
【0065】
単なる例として、添付の図面を参照して、様々な実施形態がここで説明される。
【図1】地図配信システムの概要を示す。
【図2】、
【図3】、
【図4】、
【図5】、
【図6】、
【図7】、
【図8】実施形態に従ってデジタル地図がどのように編集されうるかを概略的に示し、デジタル地図は、それぞれが複数のタイルを使用して表される複数のレイヤを含む。
【図9】クラウドから、１つ以上の地図ベース・アプリケーションを実行する車両に地図データが配信される実施形態によるクラウド・ベースの地図配信システムを概略的に示す。
【図10】実施形態による地図データを処理するためのクライアント・アプリケーションを概略的に示す。
【図11】実施形態による地図データをローカルに記憶するために使用されてもよいキャッシュを概略的に示す。
【図12】実施形態によるクラウド・ベースの地図データ配信システムを概略的に示す。
【図13】
実施形態による別の変形の地図データ配布システムを示す。
【図14】
実施形態による単一の地図フロントエンドが複数の地図クライアントによってサービス提供される別の例を示す。
【外国語明細書】