基于ADAS的自動泊車功能數據分發(fā)服務該如何設計呢？

隨著汽車電動化、智能網聯化的不斷發(fā)展，汽車控制系統將面臨大量功能增加及技術升級，其中的電子電器架構逐漸趨向于中央計算集中化。針對高級駕駛輔助系統（ADAS）的自動泊車功能，對基于車載以太網的分布式實時通信（DDS）協議開展架構設計，通過多種異構傳感器信息的采集和傳輸，實現自動泊車功能數據的實時交換。從實車檢測效果來看，該設計方案可以滿足當前駕駛輔助系統自動泊車功能的需求。

0 前言

目前，國內汽車駕駛輔助系統控制器之間通信大多采用控制器局域網絡（CAN）總線協議或帶靈活可變數據波特率的控制器局域網絡（CAN-FD）總線協議，少數采用可擴展面向服務的IP 中間件（SOME/IP）協議。隨著汽車智能化、網聯化的發(fā)展，大量數據需要高速傳輸和交換，且對數據的可靠性要求也越來越高，CAN 總線協議已經逐漸滿足不了大量數據傳輸的需求，SOME/IP 協議也滿足不了大數據、多節(jié)點、高質量服務的應用場景，因此分布式實時通信（DDS）協議作為多域控制器之間的通信，被逐步應用于汽車電子系統中[1］。

DDS 協議是一套通信協議和應用程序編程接口的標準，其基于發(fā)布者和訂閱者模型，提供了以數據為中心的連接服務。DDS 協議的功能介于操作系統和應用程序之間，使得各控制模塊之間可以互相通信，且提供了低延遲、高可靠的通信，以及可擴展的架構。

由于DDS 協議體量較大且占用處理器資源較多，所以在汽車高級駕駛輔助系統（ADAS）方面使用較少。DDS 協議對設計和性能的要求比較高，主要體現在處理器的選型、DDS 協議接口定義語言（IDL）設計和服務質量（QoS）設計部分。本文通過在TDA4VM 處理器上對基于ADAS 自動泊車功能的DDS 協議進行設計，從而使DDS 協議的大體量可以通過合理設計IDL 和QoS 來解決，以滿足在車輛自動泊車功能方面的應用需求。

1 系統設計

用于ADAS 自動泊車功能的DDS 協議系統設計如圖1 所示。由圖1 可以看出，在ADAS 控制器（TDA4VM 處理器）上設計自動泊車功能是以DDS 協議來實現通信的，ADAS 控制器與動力底盤控制器之間通過CAN-FD 協議實現相互通信，其中SOC 為系統級芯片，MCU 為單片機。

圖1 基于ADAS 自動泊車功能的DDS 協議的系統設計

自動泊車功能的數據傳輸設計主要是將泊車功能的輸入、輸出信號通過ADAS 控制器內部的DDS 協議傳輸到動力底盤控制器上。因此，在DDS 設計過程中，需要注意ADAS 控制器中的SOC 端和MCU 端DDS 協議的IDL 設 計 和QoS 設計，以及如何通過合理的IDL 和QoS 設計使得ADAS 自動泊車功能能夠滿足給定的功能需求和性能需求[2］。

2 DDS 協議設計技術

基于ADAS 自動泊車功能的DDS 協議設計主要是在TDA4VM 處理器的R5F 內核與A72 內核進行設計部署，具體包括TDA4VM 處理器的DDS協議設計、DDS 協議中IDL 設計、DDS 協議中QoS設計這3 個部分。本文基于ADAS 自動泊車功能DDS 協議的部分設計進行技術分析。

2.1 TDA4VM 處理器的DDS 協議設計

ADAS 控制器采用的是德州儀器公司生產的TDA4VM 處理器。該處理器的優(yōu)點是多核異構且選用適合的內核完成相應的任務，此外專用硬件加速器也可以處理特定任務，從而在性能、功耗和成本上達到最佳平衡。該處理器共有11 個內核，使用其中8 個內核實現ADAS 功能，分別是6 個R5F內核（其中2 個R5F 內核屬于MCU 域，4 個R5F 內核屬于MAIN 域（主域））和2 個A72 內核（屬于MAIN 域），這8 個內核的通信采用DDS 協議實現。DDS 協議是基于操作系統和以太網協議才能實現通信功能的。

將輔助駕駛功能的需求部署在TDA4VM 處理器的不同內核上[3］，推薦方案如圖2 所示。將高算力的輔助駕駛功能或者傳感器采集（例如攝像頭、雷達、全球定位系統（GPS）、慣性測量單元（IMU）和地圖等）部署在2 個A72 內核上，其中包含ADAS 的自動泊車功能。將需要具備功能安全的輔助駕駛功能或者是CAN 總線上的信號采集部署在MCU 域上，將不需要功能安全的輔助駕駛功能部署在MAIN 域的4 個R5F 內核上。

圖2 TDA4VM 處理器上的DDS 部署方案

DDS 協議在TDA4VM 處理器上的部署情況如圖2 所示。按照自動駕駛功能的需求，MCU 域上會有具備汽車安全完整性等級D 的要求，主要功能是對動力底盤相關的信號進行采集和處理；這些信號經過DDS 協議由TDA4VM 處理器內部以太網交換機傳送給高算力的A72 內核，以供ADAS 自動泊車功能使用。MAIN 域上的4 個R5F 內核上主要部署了對ADAS 功能的監(jiān)控及靜默升級等功能。

2.2 DDS 協議的IDL 設計

IDL 是一種描述性語言，以獨立于編程語言和操作系統處理器平臺的方式來定義用于交互的數據類型和接口。本文采用DDS 協議的數據提供者和數據接收者IDL 設計數據格式。ADAS 的自動泊車功能與動力底盤控制通信的信號在TDA4VM處理器上通過MCU 域的R5F 內核和MAIN 域的A72 內核 使 用DDS 協 議 進行傳輸[4］，在 此 過 程中IDL 的設計是評判處理器資源消耗情況的關鍵。在IDL 的設計中，DDS 協議的主題數量是衡量處理器資源消耗的關鍵指標，主題數量越多，資源消耗越大。特別是MCU 域資源比較緊張，在使用DDS 協議時需要重點考慮MCU 端的IDL 設計對資源的消耗。

2.2.1 上通信號

設計MCU 域時，將CAN 總線上采集的動力底盤信號從MCU 域的R5F 內核上傳輸到MAIN 域的A72 內核上，此過程中傳輸的信號稱為上通信號。

考慮到MCU 域的內存問題，且CAN-FD 總線上的數據較多，為了節(jié)省資源，將自動泊車功能的輸入輸出信號和采集到的動力底盤信號解析部署在A72 內核上。在MCU 域上只進行數據接收、數據防丟失設計和監(jiān)控接管。上通信號的IDL 設計方案按照CAN-FD 的信息結構格式來設計IDL 文件，IDL 文件在設計結構中包括CAN-FD 的ID 號、CAN-FD 報文周期、CAN-FD 報文長度和CANFD 報文的64 個字節(jié)數據。此設計方案對DDS 協議在MCU 域的部署來說只使用了1 個主題，從而節(jié)省了DDS 協議的資源消耗，也提高了MCU 域的運行效率。

2.2.2 下通信號

設計SOC 端時，對攝像頭、雷達、GPS 和IMU等信號進行采集并融合處理，將相關的動力底盤信號傳輸到MCU 域的R5F 內核上。將A72 內核上的服務化數據通過DDS 協議傳輸到MCU 域上，此過程中出現的信號稱為“下通信號”。

ADAS 自動泊車功能的下通信號主要是動力底盤信號，需要具備功能安全的要求，所以A72 內核上對于信號的處理只做服務化后的傳輸，在MCU 域上進行信號的解析和傳輸。下通信號的IDL 設計按照ADAS 的自動泊車功能來設計動力控制模塊，此模塊由控制動力的信號結構體（包含速度、加速度、距離與檔位信號）、控制橫向信號的結構體（包含橫向使能與方向盤角度信號）、控制縱向信號的結構體（包含縱向使能、剎車扭矩與速度控制信號）和駐車控制的枚舉結構（包含使能手剎信號與取消手剎信號）4 個部分組成。完成模塊設計后可對動力底盤進行控制。基于功能安全的需求，下通信號需要4 個主題來定義，由于數據量小，使得MCU 域的資源消耗不會太大，同時下通信號也具備了功能安全的要求。此設計方案使得MCU域的資源消耗與信號安全達到了相對的平衡。

2.3 DDS 的QoS 設計

DDS 協議擁有靈活的QoS 選項和配置屬性，其中包括數據的可用性控制、數據的交付方式控制、數據的時效性控制、用戶信息的定義和分發(fā)、網絡和數據資源的控制。用戶可通過QoS 策略來控制數據在應用程序之間共享的方式。用戶可依據應用場景的需求，選擇相應的QoS 策略來滿足通信質量的需求。

DDS 協議的數據提供者和數據接收者中最常用的QoS 選項有可靠性、歷史性、資源限制、持久性、傳輸延遲性與心跳周期。DDS 協議需要設計QoS 屬性的有參與者、數據提供者、數據接收者和主題4 個部分。DDS 協議的QoS 設計在MCU 和SOC 上有不同的實現方法：MCU 是靜態(tài)加載，會以代碼配置形式寫入MCU 的程序中；SOC 可以是動態(tài)加載也可以是靜態(tài)加載，此處采用可擴展標記語言（XML）文件的形式進行動態(tài)加載，靈活性較高。DDS 協議中有默認的QoS 設計，可隨著DDS協議的運行而運行，新設計的QoS 會覆蓋默認的QoS 中的相同配置。

2.3.1 MCU 的QoS 設計

按照ADAS 自動泊車功能的需求，MCU 的數據提供者和數據接收者的QoS 設計需求有所不同。數據提供者的QoS 設計屬性有資源限制設計、歷史性設計、心跳周期設計3 個部分配置，其他屬性選擇默認設計。在資源限制中，最大樣本實例數為3、最大實例數為1、最大樣本數為3，資源限制的設計是為了讓寫入數據的速度與讀取數據的速度相匹配。數據提供者資源限制的最大遠程讀取節(jié)點限制為2，最大寫入通道數為2，如此設計是為了限制讀取端最大的節(jié)點數。在歷史性設計中，歷史數據深度設置為3，這可保證數據丟失補償。在心跳周期設計中，心跳周期設置為250 ms?？蓪崿FDDS協議中，實時發(fā)布訂閱（RTPS）協議包括對已丟失并重傳消息的檢測。

數據接收者的QoS 設計屬性有資源限制設計、歷史性設計2 個部分配置其他屬性選擇默認設計。在資源限制中，最大樣本實例數為3、最大實例數為1、最大樣本數為3，資源限制的設計是為了讓寫入數據的速度與讀取數據的速度相匹配。數據接收者資源限制的最大遠程讀取節(jié)點限制為2，最大寫入通道數為2。此設計是為了限制讀取端最大的節(jié)點數。

2.3.2 SOC 的QoS 設計

根據ADAS 自動泊車功能的需求，將QoS 中的數據提供者和數據接收者XML 文件進行重新設計，保證SOC 的所有數據提供者和數據接收者的QoS 配置項都相同。其中，將QoS 的歷史數據跟蹤深度設置為3，可記錄3 次歷史數據且對數據丟失進行了補償。此外也加入了選擇可靠值屬性，該設計方案是對數據的DDS 協議傳輸進行了加固，并將持久性的QoS 配置項設計為瞬態(tài)局持久性，這對數據提供者來說就是將發(fā)送的數據寫入歷史記錄中且保存已發(fā)送數據，當數據出現丟失時，會將歷史記錄中的數據重新發(fā)送出去。

3 結果與分析

通過對DDS 協議在TDA4VM 處理器上的部署設計、DDS 協議的IDL 設計、DDS 協議的QoS 設計完成了MCU 域的R5F 內核和MAIN 域的A72內核的相互通信，實現了ADAS 自動泊車功能，同時使用基于DDS 協議的性能測試工具進行測試[5］。結果顯示，基于DDS 協議從MCU 域到SOC 端（A72 內核）的通信測試結果延遲時間在2～4 ms。從實車檢測效果來看，該方案可以滿足當前ADAS自動泊車功能的需求。

4 結語

基于ADAS 自動泊車功能的DDS 設計，在TDA4VM 處理器上部署DDS 協議，能夠實現數據的集中化分發(fā)，且在MCU 域上進行DDS 協議部署，可在系統資源緊張的情況下做到大量數據的接收和分發(fā)，從性能角度大幅優(yōu)化了MCU 端DDS 協議帶來的影響，為后期多域和跨域融合使用DDS 協議的設計奠定了基礎。未來，最大的設計挑戰(zhàn)可能還是MCU 端，由于系統資源緊缺且DDS 協議又是一個比較重要且耗費資源的協議，因此當DDS 設計的模塊化變多時，MCU 端的工作負擔會加重，從而影響自動駕駛功能在MCU 域上的運行效率。

審核編輯：劉清