經緯恒潤：AUTOSARDDS在HPC上的開發實踐

DDS的目標是在正確的時間在正確的位置(right place)共享正確的數據(right data)。2024年3月14日，在2024第五屆軟件定義汽車論壇暨AUTOSAR中國日上，北京經緯恒潤科技股份有限公司研發經理于洪斌介紹，DDS標準可分為以下四個部分——核心標準、 擴展標準、 網關標準、 API標準。同時，他對DDS的發展歷程以及AUTOSAR DDS 在HPC上的開發實踐進行了講解。針對HPC項目的開發實踐，于洪斌以經緯恒潤DDS開發工具鏈為例進行了分享。

北京經緯恒潤科技股份有限公司研發經理

以下為演講內容整理:

DDS的發展歷程及概述

DDS，即Data Distribution Service，是由OMG組織提出的新一代分布式實時數據通信中間件協議。DDS的目標是在正確的時間、正確的位置共享正確的數據，具有以下四個特點。

第一，DDS采用以數據為中心的發布訂閱機制。數據的發送端需要有相應的publisher來關聯對應的datawriter實現數據的發送，而數據的接收端需要有相應的訂閱者來關聯對應的數據讀取者實現數據的接收。只要數據的發送方和接收方的主題和服務質量相匹配，就能夠實現數據的交互。

圖源:經緯恒潤

其次，DDS具有豐富的服務質量策略。OMG組織已經提出了22種標準的QoS策略，但在實際應用中，可以根據實際場景進行定制化開發，因此并不局限于這22種策略。第三，DDS具有大規模的可擴展性。DDS中間件可以支持多種編程語言，如C語言、Java等，并且能夠兼容多種操作系統，包括Linux系統、安卓系統以及RTOS系統等。因此，它的應用范圍從小型控制器單元擴展到大型云端設備，應用范圍非常廣泛。

DDS還支持動態發現機制。在DDS網絡中，當我們向網絡添加新節點時，其他節點可以通過動態發現機制自動構建相應的通信關系，因此可以實現真正的即插即用功能。第三點是安全性。像DDS這樣的協議已經公布了相應的規范標準，在這些標準中包括身份認證、數據加密以及數據完整性等方面的規范要求。通過遵循這些規范要求，我們可以實現數據的可靠性和安全性傳輸。

DDS標準主要分為以下四個部分。第一部分是核心標準，包括DDS協議、RTBS協議、Cecired協議以及X-TYPE協議等。第二部分是擴展標準，其中定義了像XML協議、RPZ協議等。第三部分是網關協議標準，主要定義了DDS協議與其他協議之間轉換的標準和規范要求。例如，DDS外部協議定義了DDS協議與外部協議之間的協議轉換標準規范要求。第四部分是API標準，針對不同的編程語言如C、C++、Java等，規定了實現相應DDS通信中間件功能所需遵循的API接口規范要求。

DDS協議最初由OMG組織于2004年推出1.0版本的協議規范，隨著時間的推移，OMG組織不斷迭代協議標準，并增加其他協議的規范要求。例如，AUTOSAR聯盟組織在2018年基于AP的R18-03協議標準增加了對DDS網絡綁定相關的支持。經緯恒潤于2023年推出了經緯恒潤的AUTOSARDDS的協議站組件。

AUTOSAR的應用領域非常廣泛，涉及到航空航天、智能電網、醫療器械等多個領域。在汽車行業中，自動駕駛方向是最為廣泛應用的領域之一。這是因為自動駕駛涉及大量數據的傳輸，包括MCU內部的并行通信、SOC內部的核間通信以及跨芯片的通信。傳輸內容從簡單的信號到流媒體數據，再到二維、三維的感知數據，因此對通信效率和大量數據分發有很高的要求。DDS協議是基于數據的通信方式，同時支持各種QoS策略，因此與自動駕駛方向高度契合，可以通過DDS協議實現相關的數據通信功能。

AUTOSARDDS在HPC上的開發實踐

AUTOSARDDS在HPC上的開發實踐基于L4的項目，主要包括車云交互系統、軟駕系統、感知系統和底盤系統等幾大系統。正在開發的HPC控制器屬于軟駕系統，主要實現自動駕駛功能。

目前，HPC控制器是基于TDA4芯片進行開發的，其中包括兩個主要的控制器，即HPC1和HPC2。HPC1主要實現激光識別和智駕融合功能，而HPC2則負責視覺識別相關功能。另外，TBOX模塊主要用于與云端進行數據交互，并將路徑信息下發至相關設備。對于TC397芯片，主要實現智駕控制功能。在早期開發階段，我們采用了SOMEIP通訊方式進行功能開發，而對于DDS內部通訊則采用了核間通訊方式。在新一代平臺上，我們將所有MCU之間的通訊以及MCU內部通訊都切換到了DDS通訊方式。

要實現這種轉換，需要進行大量的開發工作，具體包括以下三個部分:首先是DDS系統設計，包括DDS需求規范開發、DDS通信矩陣開發以及DDS XML通信矩陣模板開發。其次是ECU軟件的開發，因為早期HPC控制器采用了AUTOSAR標準的CP和AP軟件，所以需要對AP和CP軟件進行升級，以支持相應的DDS模塊。同時，相關的工具鏈也需要進行迭代，以支持對DDS通信矩陣的解析。最后，完成所有基礎軟件搭建后，需要與原有的HPC相關應用軟件進行整體系統聯調，包括數據融合相關軟件，這是第二個階段，也是ECU軟件開發的一部分。

圖源:經緯恒潤

DDS的系統設計是針對實際項目需求開發的，其中通信矩陣的設計工作是其中的重要部分。在通信矩陣的設計過程中，主要涉及三個部分，針對DDS常用的屬性進行設計開發工作。

首先，我們需要將基于SOA架構開發的服務列表轉換成DDS所需的通信矩陣。將服務列表分成兩類:一類是基于RPC類型的服務，另一類是非RPC類型的服務。

第二部分是進行與數據相關的設計。在這方面，設計內容相對簡單，主要是針對數據類型進行設計，類似于SOMEIP的設計。然而，在DDS相關的XTypes協議標準中，實際上增加了一些數據屬性的要求。因此，在通信矩陣的設計中，我們單獨增加了一些列表，針對屬性進行配置。這些屬性包括數據可選性、可擴展性以及可便性的配置。用戶可以基于我們的模板，針對相關的數據類型進行單獨的屬性配置。

第三步是對于Entity設計。這部分的設計內容主要包括DataReader、DataWriter、Publisher、Domain等。所有這些設計完成后，就形成了HPC通信矩陣模板。通信矩陣設計完成后，還需要形成相應的DDS通信矩陣，這樣做的目的是為了給下游的軟件提供集中開發的基礎。我們選用的通信矩陣模板是XML文件格式，可以包含相應的ECU信息，還可以包含AP、CP所使用的所有服務相關的屬性信息，包含的信息更加全面。

所有系統設計完成后，接下來就是相關的軟件開發工作。軟件開發工作主要涉及對相關的CP和AP的供應鏈進行升級，包括軟件模塊的開發工作。目前AP和CP的DDS軟件模塊已經實現了對AP和CP的供應鏈兼容，并且支持相應通信矩陣的導入配置。這些軟件模塊能夠與AP、CP供應鏈的其他軟件模塊進行整體集成、開發和迭代，實現了相應的RTPS協議、DDS協議和X-Types協議相關的內容，并且能夠兼容不同操作系統以及相關的硬件平臺。

針對軟件測試部分，實際上，無論是OMG還是AUTOSAR官方，都沒有對一致性測試規范進行一致的定義要求?？紤]到整車廠在進行相關DDS網絡設計時，不同的Tier1供應商可能使用不同的DDS軟件解決方案，可能會使用開源的DDS，也可能會使用商用的RTI的DDS，甚至可能使用我們恒潤的DDS。在這種情況下，如何保證相關DDS的兼容性就會涉及到一致性測試的問題。因此，我們基于OMG組織的相關規范要求，開發了相應的一致性測試工具，并將其集成到AETP測試軟件中，以進行相關的DDS一致性測試功能。

在HPC的開發設計過程中，我們得出了一些總結和思考，主要有以下三點。首先，DDS協議在實現過程中代碼量非常大，其中許多功能在實際應用中可能并不需要。因此，我們認為可以對DDS的協議站進行適當的裁減，去除不必要的功能，以提高效率和性能。

其次，每家DDS協議站都支持多種QoS服務，但實際項目中可能并不會使用所有這些服務。因此，我們認為可以對無效的QoS服務進行適當的裁減，并根據整車廠的規范要求進行DDS定制化開發，以滿足實際項目需求。

最后，工具鏈的兼容性也是關鍵。大部分控制器都基于AUTOSAR的軟件架構進行開發，因此對于DDS的軟件模塊，如何實現與已有工具鏈的兼容性是關鍵。我們采取了將DDS模塊直接嵌入到自己的AUTOSAR的DDS軟件平臺中的解決方案，從而實現了對全套AUTOSAR解決方案的兼容性。

經緯恒AUTOSARDDS解決方案

在設計過程中，我們認為在DDS的開發主要遵循以下三個原則。第一，規范性。要遵循OMG組織提出的標準規范，保證整個設計流程的規范化和設計產物的規范化。第二，兼容性。要考慮到不同平臺實現的DDS兼容性，還有DDS軟件模塊跟已有的AUTOSAR工具鏈的兼容性。第三，可行性。要關注實際落地效果的性能，并且不斷優化設計原則。

AUTOSARDDS的全套解決方案包括以下幾個方面:第一，通信矩陣設計:設計了相應的DDS通信矩陣模板，支持通信矩陣到xml文件的轉換，為系統設計提供了基礎。第二，通信矩陣轉換網絡設計工具:提供了支持通信矩陣到xml文件的轉換工具，方便用戶進行通信矩陣的設計和轉換。第三，軟件層面解決方案:提供了針對AP和CP的解決方案，支持對DDSxml文件的解析，使得軟件開發和集成更加順暢。第四，測試階段:提供了一致性測試的AETPDDS套件，支持對DDS通信矩陣的測試，確保系統的穩定性和可靠性。第五，總線監控設備:提供相關的總線監控設備，可以進行實車的監測，并支持DDS通信矩陣的解析，幫助用戶進行系統調試和故障排除。

圖源:經緯恒潤