關鍵詞：駕駛輔助系統(tǒng)；自動泊車；分布式實時通信；異構傳感器

0前言

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

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

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

1系統(tǒng)設計

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

自動泊車功能的數(shù)據(jù)傳輸設計主要是將泊車功能的輸入、輸出信號通過ADAS 控制器內(nèi)部的DDS 協(xié)議傳輸?shù)絼恿Φ妆P控制器上。因此，在DDS 設計過程中，需要注意ADAS 控制器中的SOC 端和MCU 端DDS 協(xié)議的IDL 設計和QoS 設計，以及如何通過合理的IDL 和QoS 設計使得ADAS 自動泊車功能能夠滿足給定的功能需求和性能需求［2］。

2 DDS 協(xié)議設計技術

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

2. 1 TDA4VM 處理器的DDS協(xié)議設計

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

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

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

2. 2 DDS協(xié)議的IDL設計

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

2. 2. 1 上通信號

設計MCU 域時，將CAN 總線上采集的動力底盤信號從MCU 域的R5F 內(nèi)核上傳輸?shù)組AIN 域的A72 內(nèi)核上，此過程中傳輸?shù)男盘柗Q為上通信號。

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

2. 2. 2下通信號

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

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

2. 3DDS 的QoS 設計

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

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

2. 3. 1 MCU 的QoS 設計

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

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

2. 3. 2 SOC 的QoS設計

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

3結果與分析

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

4結語

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