NDS背景簡介

當今時代，說起汽車，人們自然會提到智能駕駛，而說起智能駕駛，人們則自然會提到高精地圖。高精地圖是離我們這么近又那么遠的一個概念。說起高精地圖，相信即使是行外人士，也不會完全不知道它是什么意思，畢竟我們手機上的地圖APP通常都不止一個，大家用起來都十分利索。

實際上高精地圖的發(fā)展與智能網(wǎng)聯(lián)汽車密切相關。相對于以往的導航地圖，高精地圖是智能駕駛汽車規(guī)劃道路行駛路徑的重要基礎，能為車輛提供定位、決策和交通動態(tài)信息等依據(jù)。另一方面，高精地圖也能為智能駕駛汽車上的傳感器補位，增強超視距的感知，提高系統(tǒng)安全性。當功能豐富、使用場景多樣的高精地圖需要落實到汽車上下游產(chǎn)業(yè)鏈，并適應日益提速迭代的汽車及其應用開發(fā)周期，就對制定通用的地圖標準提出了需求。而今天我們要探討的NDS就是其中最常用的導航地圖數(shù)據(jù)標準。

NDS的全稱是Navigation Data Standard，亦即導航數(shù)據(jù)標準，由NDS組織制定及維護。NDS格式是高精地圖的常用格式，也是國際OEM的普遍選擇。NDS可以用于移動應用程序、互聯(lián)汽車云解決方案和自動駕駛。

圖1：NDS的口號 （來源：NDS組織官網(wǎng)）

每每談論到標準，我們都容易想起行業(yè)圈子，因為標準組織內有哪些玩家往往能體現(xiàn)標準分量。而從行業(yè)背景來看，NDS是為汽車行業(yè)服務的，由汽車行業(yè)負責。具體的協(xié)會成員直接看下圖，囊括中外，我們耳熟能詳?shù)腛EM、Tier1和圖商都位列其中。

圖2：NDS協(xié)會成員

NDS.Classic和NDS.Live

這些年汽車的發(fā)展異常迅速，越來越多的車輛配備了聯(lián)網(wǎng)功能，車云協(xié)作越來越主流，與車輛地圖相關的APP應用也是層出不窮。這就對地圖數(shù)據(jù)格式提出了新的要求。為了應對這種趨勢，NDS自身也在蛻變和革命。在2019年NDS正式對外公布了其新一代的導航數(shù)據(jù)格式NDS.Live，并把之前的NDS命名為NDS.Classic以示區(qū)分。

圖3：2019年NDS在公開會議上正式提出了下一代數(shù)據(jù)格式NDS.Live

NDS.Classic

目前量產(chǎn)車上用的NDS數(shù)據(jù)格式大部分都是NDS.Classic，它已經(jīng)在30多個不同品牌的數(shù)百萬輛汽車上部署，用于導航、ADAS和自動駕駛等，有著良好的記錄。它本質上是為嵌入式設備使用而設計的。之前很長一段時間，導航地圖數(shù)據(jù)都是存儲在數(shù)據(jù)載體（DVD、USB、HDD、SD卡）上，而且對應的數(shù)據(jù)只會在車上用。相信有資歷的車友都能想起以前手動升級一版導航地圖是如何大費周章。基于此，NDS.Classic的存儲格式實質上是數(shù)據(jù)庫類型的。它作為一個嵌入式數(shù)據(jù)庫，可以漸進式更新。當然隨著技術發(fā)展，NDS.Classic后來也支持OTA。

舉個例子，下圖就是一個應用NDS導航系統(tǒng)的系統(tǒng)示意圖。虛線左邊是NDS規(guī)范的主體內容，通過編譯器將原始的地圖輸入生成滿足NDS規(guī)范的數(shù)據(jù)庫（一般以SQL文件格式存儲），然后數(shù)據(jù)庫提供操作接口給不同的業(yè)務應用，例如地圖顯示、地位和路徑規(guī)劃等應用。

圖4：NDS格式數(shù)據(jù)庫及其接口示意圖

NDS.Classic是一個基于瓦片（Tile-based）的組織結構，支持瓦片級的更新。瓦片可以理解為地球面上的一個四邊形。我們在手機上看地圖的時候，數(shù)據(jù)經(jīng)常是一個方塊一個方塊地加載出來，背后也是因為數(shù)據(jù)是基于瓦片來存儲和傳輸?shù)?。四維圖新在《智能網(wǎng)聯(lián)汽車高精地圖白皮書》中提到，其向某OEM 最終交付 2.5.4 版本的 NDS 規(guī)格的中國全境高速和部分城市道路的高精地圖數(shù)據(jù)，平均一個瓦片的數(shù)據(jù)大小大約在 60-80kb。

NDS.Live

相比之下，NDS.Live就不再是一個數(shù)據(jù)庫，而是一個分布式地圖數(shù)據(jù)系統(tǒng)。這其中包括數(shù)據(jù)服務以及應用服務，比如路徑生成、電動車里程計算和POI搜索等功能。這些服務的應用接口在NDS.Live中定義，但規(guī)范中并不包括底層通訊傳輸。NDS.Live的用戶能夠自由選擇NDS數(shù)據(jù)或應用服務的部署位置，這可以是在云端、車載娛樂控制器或者手機APP等其他任何地方。NDS.Live可以說是NDS的新一代規(guī)范，更具生命力。

NDS.Live支持多種數(shù)據(jù)傳輸協(xié)議，包括常用的從云端到車端通訊的HTTP/REST和車載通訊SOME/IP。但無論選擇哪種傳輸協(xié)議，接口層的互操作性都由NDS.Live來維護，因為數(shù)據(jù)在被傳遞到傳輸層之前是以互操作、跨平臺、跨語言的方式進行序列化的。如下圖示例，底層采用HTTP傳輸，然后在標準的HTTP協(xié)議之上設計應用接口作為適配參考層，同時根據(jù)NDS.Live規(guī)范可以設計統(tǒng)一的服務層，供不同的上層應用模塊調用。如果例子中的HTTP協(xié)議換成SOME/IP協(xié)議，則只需設計對應的參考層，可以最大限度地復用上層應用和底層標準傳輸協(xié)議。而下圖示例中的參考層雖然不屬于NDS.Live的規(guī)范內容，但是NDS組織也提供了針對HTTP和SOME/IP的參考層實現(xiàn)樣例。

圖5：NDS.Live與不同傳輸層接口層次示意圖

NDS.Live架構介紹

在傳輸協(xié)議和API適配之上，則是NDS.Live規(guī)范的主體部分。如圖5所示，我們可以分兩個層次來進一步理解：模塊（Module）和服務層（Service Layer）。

模塊（Module）

NDS.Live是一個基于模塊的分布式地圖系統(tǒng)，因此規(guī)范和文檔也是按模塊安排的。模塊代表相關數(shù)據(jù)的集合，例如數(shù)據(jù)類型、定義和接口。下圖是NDS.Live所定義的模塊概覽。

圖6：NDS.Live模塊概覽

模塊分為5種類型：

-Common：通用模塊，用于可以全局復用的通用數(shù)據(jù)，例如基礎的數(shù)據(jù)類型等。

-Feature： 特征模塊，用于定義地圖特征和幾何數(shù)據(jù)。

-Attribute： 屬性模塊，用于定義屬性，可以簡單理解為是對地圖特征的更細致描述。例如ADAS、定位等都是在屬性模塊中定義。

-Reference： 參考模塊，實際上是特征模塊和屬性模塊之間的接口。通過參考模塊引用數(shù)據(jù)，可以降低模塊之間的耦合度。

-Service：服務模塊，提供數(shù)據(jù)訪問的接口。服務的終端訪問定義都在該模塊定義，例如常見的“請求-應答”和“發(fā)布-訂閱”服務接口都在這類模塊中定義。

這些不同的模塊之間不同的排列組合，可以滿足不同的用例。例如在ADAS應用場景下，基于車道的特征模塊、ADAS屬性模塊、數(shù)據(jù)類型定義的通用模塊和定義具體服務接口的服務模塊之間就可以滿足。而在不同的應用場景和不同的模塊下，NDS.Live還抽象出了不同的數(shù)據(jù)層（Data Layer），用來定義具體的數(shù)據(jù)結構。這背后同樣是“高內聚、低耦合”的思想。如下圖所示，不同用例可以取5種數(shù)據(jù)層中的若干種。例如普通ISA（Intelligent Speed Assist）場景下，業(yè)務只需要道路基礎信息和限速信息，可以只獲取底下兩層。更復雜的功能業(yè)務，則可以用更豐富的層次。當然這只是在功能邏輯層面的區(qū)分，實際上在數(shù)據(jù)二進制存儲和通訊等實現(xiàn)過程中，不同層次的數(shù)據(jù)層會打包進一個數(shù)據(jù)容器（Data Container）中。

圖7：不同用例下數(shù)據(jù)層的復用示意圖

另外，在數(shù)據(jù)壓縮和安全方面，NDS.Live也提供了針對數(shù)據(jù)層的解決方案，有利于滿足汽車行業(yè)的功能安全和信息安全等要求。NDS.Live中明確了支持的壓縮算法。而關于數(shù)據(jù)簽名，NDS.Live也提供了一個預定義的哈希和簽名機制列表。簽名算法可以用專有的簽名算法接口進行擴展。用于簽名和加密的密鑰管理不在NDS.Live的范圍內，但它提供了URL或密鑰ID接口。結合AUTOSAR中的密鑰管理模塊，可以快速高效地部署數(shù)據(jù)安全系統(tǒng)。

服務層（Service Layer）

服務層可以理解為NDS.Live中定義的通信中間件。NDS.Live規(guī)范是針對多個網(wǎng)絡參與者的分布式系統(tǒng)開發(fā)的。每個參與者由一個網(wǎng)絡節(jié)點代表，由該節(jié)點來提供或請求與地圖和導航有關的信息。

NDS.Live系統(tǒng)內的每個通信事件都涉及兩種類型的網(wǎng)絡節(jié)點：服務端節(jié)點和客戶端節(jié)點。服務層所定義的服務接口，就是用于服務端節(jié)點和客戶端節(jié)點之間的信息傳遞。服務端和客戶端之間可以通過“請求-應答”和“發(fā)布-訂閱”模式進行通信。而NDS.Live中定義的服務接口分兩種類型：通用服務接口和基于模塊的服務接口。

兩種服務接口類型的主要差別就是是否對不同的模塊通用。通用服務接口如下圖左側所示，如果客戶端發(fā)起一個請求，來獲取不同模塊所提供的不同數(shù)據(jù)內容。這時候服務接口可以把不同數(shù)據(jù)源拼接在一起，統(tǒng)一通過同一個服務響應來傳遞數(shù)據(jù)。這種匯納多個數(shù)據(jù)源后由統(tǒng)一的服務響應傳遞數(shù)據(jù)的方式，在NDS.Live中也稱為智慧層（Smart Layer）。

智慧層的設計也是基于終端使用場景出發(fā)的，例如客戶端傳來基于瓦片ID的請求，服務端可以把對應瓦片內不同模塊不同層次的數(shù)據(jù)都放在同一個數(shù)據(jù)容器內后響應。除了支持NDS.Classic的基于瓦片的方法，NDS.Live還增加了路徑和對象作為容器的額外選項。例如ADAS客戶端發(fā)來基于路徑幾何特性的請求，服務端可以把該路徑對應的數(shù)據(jù)統(tǒng)一響應。這樣可以為基于路徑的自動駕駛和ADAS用例減少數(shù)據(jù)帶寬。又例如針對泊車場景，需要單獨下載一個停車場的高清地圖時，可以通過對象作為容器和服務接口來傳輸。

圖8：NDS.Live兩種服務接口類型對比

NDS應用例子

NDS作為導航數(shù)據(jù)標準，致力于標準化流程和接口，以支撐更多產(chǎn)業(yè)創(chuàng)新。那么它在汽車行業(yè)中是怎么應用的？接下來我們看一個NDS官網(wǎng)上展示的實際例子。這個例子是BMW和dSPACE兩大巨頭聯(lián)手打造的HIL（Hardware In the Loop，硬件在環(huán)測試）方案，架構如下所示。

圖9：NDS 2022大會上展示的一種應用NDS的HIL架構

從連接的其他模擬模型可以猜測，被測ECU是ADAS的域控制器。對于毫米波雷達、激光雷達等傳感器，通過仿真環(huán)境配合各個傳感器的內核算法模型，可以仿真感知數(shù)據(jù)，然后提供給被測ECU。而跟NDS息息相關的主要是圖9中上部分的鏈路，也就是NDS和OpenDrive的雙向格式轉換的打通。

OpenDrive是dSPACE仿真環(huán)境對于地圖數(shù)據(jù)的統(tǒng)一接口，可以被輸入到仿真環(huán)境中，以開發(fā)和驗證ADAS功能。但原生OpenDrive生成的場景往往缺乏實際駕駛區(qū)域旁邊的環(huán)境細節(jié)。而這些細節(jié)又往往影響到所需驗證的功能。因此在打通NDS和OpenDrive雙向轉換之前，對于某些測試用例，可能需要手動修改三維場景。但有了上圖所示的雙向轉換之后，當需要把采集的真實數(shù)據(jù)回灌到被測ECU時，基于NDS的豐富的導航地圖數(shù)據(jù)可以經(jīng)過車機后自動轉換為OpenDrive格式，提供給仿真環(huán)境，然后生成相對更真實的3D環(huán)境進行測試。而當采用dSPACE搭建虛擬環(huán)境時，生成的OpenDrive地圖數(shù)據(jù)也可以轉換為NDS，供車機渲染酷炫的動畫。

來自兩大巨頭將接口標準的打通，相信也會加速NDS的應用推廣。方案中呈現(xiàn)的NDS和OpenDrive雙向轉換，相信也會商業(yè)化成為產(chǎn)品。這樣一來，在推廣應用NDS作為高精地圖數(shù)據(jù)標準的同時，原有的硬件在環(huán)測試設備和方案也可以沿用，是一個共贏的局面。

寫在最后

隨著智能駕駛技術的日益成熟，高精地圖已經(jīng)成為了各大廠家的新戰(zhàn)場。高盛對全球高精地圖市場的預判是，到2025年市場規(guī)模會擴大到94億美元。行業(yè)普遍認為，未來15年高精地圖行業(yè)將進入黃金發(fā)展期。而在這個過程中，最好的選擇肯定是制定標準。如果不能，那選擇一個有前景的標準進行跟隨和應用也是提升自身核心競爭力的有效手段。那么你覺得NDS是這個有前景的標準嗎？

審核編輯 ：李倩