NDS背景簡介

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

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

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

圖1：NDS的口號 （來源：NDS組織官網）

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

圖2：NDS協會成員

NDS.Classic和NDS.Live

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

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

NDS.Classic

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

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

圖4：NDS格式數據庫及其接口示意圖

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

NDS.Live

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

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

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

NDS.Live架構介紹

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

模塊（Module）

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

圖6：NDS.Live模塊概覽

模塊分為5種類型：

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

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

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

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

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

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

圖7：不同用例下數據層的復用示意圖

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

服務層（Service Layer）

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

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

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

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

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

NDS應用例子

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

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

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

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

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

寫在最后

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

審核編輯 ：李倩