當(dāng)前，面向服務(wù)的軟件架構(gòu)（SOA）在車載軟件中占據(jù)越來越重要的位置，通信中間件便是其落地的關(guān)鍵環(huán)節(jié)之一。數(shù)據(jù)分發(fā)服務(wù)（DDS）在汽車領(lǐng)域的優(yōu)勢(shì)逐漸凸顯，但關(guān)于DDS在車輛上部署與應(yīng)用，文獻(xiàn)卻鮮有提及。文章針對(duì)數(shù)據(jù)分發(fā)服務(wù)，詳細(xì)介紹了其基本原理、發(fā)布訂閱模型和服務(wù)質(zhì)量策略。接著介紹了DDS通信的整個(gè)過程，及DDS在車輛上部署的三種不同形式。最后以FAST DDS為例，詳細(xì)介紹了DDS在車輛上部署的具體流程。基于數(shù)據(jù)分發(fā)服務(wù)的通信中間件在車輛上具有非常廣泛的應(yīng)用前景。
當(dāng)前，我們正身處于汽車行業(yè)向電動(dòng)化、智能化、網(wǎng)聯(lián)化、共享化轉(zhuǎn)型的浪潮之下，智能電控、智能駕駛、智能互聯(lián)、智能出行深刻影響著人們的生活與思考方式，智能網(wǎng)聯(lián)汽車已經(jīng)成為引領(lǐng)我國汽車產(chǎn)業(yè)轉(zhuǎn)型升級(jí)的戰(zhàn)略方向[1-2]。隨之而來的車輛電子電氣架構(gòu)向區(qū)域集中化靠攏，車載軟件趨向更高融合度和復(fù)雜度，海量數(shù)據(jù)向云端遷移，軟件定義汽車已成為行業(yè)發(fā)展的趨勢(shì)。
面向服務(wù)的軟件架構(gòu)也越來越受到各大汽車廠商的青睞。基于新的架構(gòu)模式，功能業(yè)務(wù)可以基于服務(wù)做靈活拓展，業(yè)務(wù)部署的靈活性和業(yè)務(wù)更新的快捷性都有質(zhì)的提升。這些都對(duì)車輛的通信服務(wù)提出了更高的要求。一直沿用的AUTOSAR CP已經(jīng)無法滿足車輛通信的要求，面向服務(wù)的中間件也越來越引起人們的重視。
在分布式系統(tǒng)中，中間件指的是位于操作系統(tǒng)和應(yīng)用程序之間的軟件層。它通過對(duì)計(jì)算平臺(tái)軟硬件的抽象，并提供統(tǒng)一接口，簡化了分布式系統(tǒng)的開發(fā)過程。使用中間件帶來最直接的好處就是實(shí)現(xiàn)了應(yīng)用層和底層的解耦，應(yīng)用層開發(fā)人員可以忽略芯片、傳感器等硬件的差異，從而高效、靈活地將上層應(yīng)用及功能算法在不同平臺(tái)上實(shí)現(xiàn)、迭代、移植。從這點(diǎn)來看，AUTOSAR也可以認(rèn)為是一種中間件。
1 數(shù)據(jù)分發(fā)服務(wù)框架結(jié)構(gòu)及特點(diǎn)
1.1 數(shù)據(jù)分發(fā)服務(wù)簡介
目前主流的面向服務(wù)的中間件有數(shù)據(jù)分發(fā)服務(wù)（Data Distribution Service, DDS）、基于IP的可擴(kuò)展面向服務(wù)的中間件（Scalable service-Oriented MiddlewarE over IP, SOME/IP）、消息隊(duì)列遙測傳輸協(xié)議（Message Queuing Telemetry Transport, MQTT）。DDS是由對(duì)象管理組織（Object Manage- ment Group, OMG）制定的一種面向服務(wù)的通信中間件協(xié)議。采用發(fā)布訂閱模型，強(qiáng)調(diào)以數(shù)據(jù)為中心，提供多種服務(wù)質(zhì)量策略（Quality of Service, QoS），以保障數(shù)據(jù)實(shí)時(shí)、高效、靈活地分發(fā)，可滿足各種分布式實(shí)時(shí)通信的應(yīng)用需求[3-5]。
DDS在國防、航天、電網(wǎng)、醫(yī)療、能源等領(lǐng)域取得大量成功的應(yīng)用，其優(yōu)良的性能經(jīng)過了長期的驗(yàn)證。在汽車領(lǐng)域，早在2018年，AUTOSAR AP在通信管理模塊中加入了DDS技術(shù)；ROS2、Apollo CyberRT的底層也是基于DDS協(xié)議；Orin、Xavier等面向自動(dòng)駕駛的系統(tǒng)級(jí)芯片（System On Chip, SOC）上也都預(yù)留了DDS的接口。DDS已被奧迪、大眾等多家原始設(shè)備制造商（Original Equipment Manufacturer, OEM）廠商應(yīng)用于智能駕駛、泊車充電、仿真測試平臺(tái)等場景；國內(nèi)的造車新勢(shì)力小鵬汽車等也已經(jīng)將DDS技術(shù)應(yīng)用到量產(chǎn)車型上。
DDS能夠?qū)崿F(xiàn)低延時(shí)、高可靠、高實(shí)時(shí)性的數(shù)據(jù)融合服務(wù)，能夠從根本上降低軟件的耦合性、復(fù)雜性，提高軟件的模塊化特性，融合了DDS的汽車軟件能夠更好地運(yùn)行在下一代汽車的體系架構(gòu)中，更能降低開發(fā)的成本、縮短研發(fā)時(shí)間，更快地將產(chǎn)品推向市場。
DDS標(biāo)準(zhǔn)是一種中間件協(xié)議和以數(shù)據(jù)為中心的連接框架，它可以將分布式系統(tǒng)的組件集成在一起。DDS能夠?qū)崿F(xiàn)低延遲、高可靠、高實(shí)時(shí)性的數(shù)據(jù)融合服務(wù)，能夠從根本上降低軟件的耦合性、復(fù)雜性，提高軟件的模塊化特性，數(shù)據(jù)分發(fā)DDS 是OMG提供的用于以數(shù)據(jù)為中心的連接的中間件協(xié)議、連接框架和應(yīng)用, 應(yīng)用程序接口（Application Programming Interface, API）標(biāo)準(zhǔn)。它繼承了分布式系統(tǒng)的組件，提供了低延時(shí)的數(shù)據(jù)連接、極高的可靠性和可擴(kuò)展的體系結(jié)構(gòu)，滿足業(yè)務(wù)和任務(wù)關(guān)鍵型應(yīng)用程序的需求[6]。與SOME/ IP、MQTT相比，DDS具有以下特點(diǎn)：
1）SOME/IP 是針對(duì)汽車領(lǐng)域的中間件，在車載領(lǐng)域已經(jīng)應(yīng)用了較長的時(shí)間。MQTT適用于低帶寬及不穩(wěn)定的網(wǎng)絡(luò)，但它依賴于一個(gè)中央代理。DDS本身是一個(gè)工業(yè)級(jí)別的通信標(biāo)準(zhǔn)，適用于多種的應(yīng)用場景，但用在汽車領(lǐng)域時(shí)可能需要做專門的裁剪。
2）相比于SOME/IP，DDS引入大量標(biāo)準(zhǔn)內(nèi)置特性，在靈活性、可伸縮性等方便更具優(yōu)勢(shì)。
3）SOME/IP主要采用遠(yuǎn)程過程調(diào)用（Remote Procedure Call,RPC）的通信方式，服務(wù)器（server）和客戶機(jī)（client）之間仍有一定的耦合性。而DDS采用發(fā)布/訂閱機(jī)制，實(shí)現(xiàn)了通信雙方在時(shí)間、空間和數(shù)據(jù)通信上的多維松耦合。
4）SOME/IP沒有定義QoS機(jī)制，只能保證數(shù)據(jù)可靠，不能保證延遲。MQTT也具有保證穩(wěn)定傳輸?shù)臋C(jī)制的，但其僅支持QoS0、QoS1、QoS2的QoS策略。DDS具有豐富的QoS策略，能夠滿足高復(fù)雜性、高靈活性的數(shù)據(jù)流要求。
5）SOME/IP基于傳輸控制協(xié)議（Transmission Control Protocol, TCP）或用戶數(shù)據(jù)包協(xié)議（User Datagram Protocol, UDP），只能在基于網(wǎng)絡(luò)層為IP類型的網(wǎng)絡(luò)環(huán)境中使用。而DDS基于實(shí)時(shí)發(fā)布訂閱協(xié)議（Real-Time Publish-Subscribe, RTPS）可以有多種實(shí)現(xiàn)，且DDS獨(dú)有的DDS Security、DDS Web功能可以為用戶提供車-云-移動(dòng)端一站式的解決方案。
1.2 以數(shù)據(jù)為中心的發(fā)布訂閱模型
如圖1所示，DDS內(nèi)所有成員都被稱為實(shí)體。以數(shù)據(jù)為中心的發(fā)布訂閱（Data Centric Publish Subscribe, DCPS）模型基于全局?jǐn)?shù)據(jù)空間（Global Data Space, GDS）的概念，所有對(duì)該空間內(nèi)數(shù)據(jù)感興趣的節(jié)點(diǎn)都可以接入，這在很大程度上提升了中間件的效率。
圖1 DDS組成模型
DDS使用域（Domain）將網(wǎng)絡(luò)劃分為不同的網(wǎng)絡(luò)分組，域由域號(hào)（Domain_ID）唯一標(biāo)識(shí)，只有在同一個(gè)域內(nèi)的通信實(shí)體才能通信。域內(nèi)的參與者（Participant）是參與通信的最小單元，由參與者序號(hào)（Participant_ID）唯一標(biāo)識(shí)，包含若干發(fā)布者（Publisher）、訂閱者（Subscriber）和注冊(cè)主題（Topic），負(fù)責(zé)創(chuàng)建、刪除和管理這些實(shí)體。任何DDS應(yīng)用都必須首先獲取域參與者，然后通過域參與者獲取其他服務(wù)，如發(fā)布者、訂閱者、主題等。
發(fā)布者至少包含一個(gè)數(shù)據(jù)寫入者（Writer），并負(fù)責(zé)創(chuàng)建、刪除和管理數(shù)據(jù)寫入者。同樣，訂閱者至少與一個(gè)數(shù)據(jù)讀取者（Reader）關(guān)聯(lián)，并負(fù)責(zé)創(chuàng)建、刪除和管理數(shù)據(jù)讀取者。數(shù)據(jù)寫入者負(fù)責(zé)將發(fā)布者對(duì)應(yīng)主題的數(shù)據(jù)寫入數(shù)據(jù)存儲(chǔ)區(qū)中，在發(fā)布者和QoS共同作用下發(fā)布實(shí)際的消息數(shù)據(jù)。數(shù)據(jù)讀取者可采用同步、異步、非阻塞等訂閱方式獲取訂閱者接收到的數(shù)據(jù)。
主題是數(shù)據(jù)發(fā)布者和數(shù)據(jù)讀取者相互通信時(shí)的約定，必須包含主題名稱和主題類型兩個(gè)屬性。每個(gè)數(shù)據(jù)發(fā)布者、數(shù)據(jù)讀取者必須與一個(gè)主題綁定，相互通信的數(shù)據(jù)發(fā)布者、數(shù)據(jù)讀取者之間的主題數(shù)據(jù)類型必須相同，且QoS必須匹配。
1.3 服務(wù)質(zhì)量策略
QoS是一種網(wǎng)絡(luò)傳輸策略，應(yīng)用程序指定所需要的網(wǎng)絡(luò)傳輸質(zhì)量行為，QoS服務(wù)實(shí)現(xiàn)這種行為要求，盡可能地滿足客戶對(duì)通信質(zhì)量的要求，DDS定義QoS策略使其對(duì)復(fù)雜網(wǎng)絡(luò)環(huán)境的適應(yīng)性和魯棒性大大增強(qiáng)，優(yōu)化網(wǎng)絡(luò)傳輸質(zhì)量[9-11]。
DDS規(guī)范定義了豐富的服務(wù)質(zhì)量策略，標(biāo)準(zhǔn)中目前有22種，但目前一些DDS版本實(shí)現(xiàn)已經(jīng)能支持50種以上的QoS策略，包括傳輸?shù)目煽啃浴?shù)據(jù)的持久性、資源限制等。用戶可以通過XML文件配置等方式完成QoS的配置。
如圖2所示，所有的DDS實(shí)體都可以綁定相應(yīng)的QoS策略，其可以作用的對(duì)象如圖2所示。QoS特性的支持使DDS非常適用于數(shù)據(jù)類型豐富且功能需求多樣的場景。
用戶可以通過設(shè)置QoS策略來控制數(shù)據(jù)在應(yīng)用程序之間共享的方式，以滿足不同場景下應(yīng)用程序?qū)δ芎托阅苄枨蟆?shù)據(jù)讀取者所屬的訂閱者和數(shù)據(jù)寫入者所屬的發(fā)布者的分區(qū)表達(dá)式應(yīng)該匹配，且數(shù)據(jù)寫入者提供的QoS策略應(yīng)該超過或匹配數(shù)據(jù)讀取者請(qǐng)求的策略，數(shù)據(jù)讀取者才能接收到數(shù)據(jù)寫入者發(fā)送的數(shù)據(jù)。如QoS中的可靠性（RELIABILITY），有可靠（RELIABLE）和最高效（BSET_EFFORT）兩個(gè)選項(xiàng)。如果設(shè)為前者，當(dāng)數(shù)據(jù)讀取者由于各種原因無法收到數(shù)據(jù)時(shí)，樣本數(shù)據(jù)會(huì)進(jìn)行重發(fā)，保證數(shù)據(jù)讀取者能收到數(shù)據(jù)；如果設(shè)為后者，則無法保證數(shù)據(jù)接收的完整性。
圖2 DDS QoS策略
圖3 DDS通信過程
首先啟動(dòng)DCPS層信息倉庫來創(chuàng)建和初始化DDS全局?jǐn)?shù)據(jù)空間，基于域ID創(chuàng)建域。然后，數(shù)據(jù)發(fā)布者和訂閱者分別創(chuàng)建域工廠，域參與者，然后注冊(cè)數(shù)據(jù)類型（DataType），通知DDS生成相關(guān)主題，DDS根據(jù)數(shù)據(jù)類型定義主題并完成QoS設(shè)置。發(fā)送方創(chuàng)建主題、布者和數(shù)據(jù)寫入者；接收方查找主題，創(chuàng)建訂閱者和數(shù)據(jù)讀取者。
當(dāng)數(shù)據(jù)接收方要訂閱某一主題時(shí)，DDS會(huì)自動(dòng)查找主題下的發(fā)布者，并將訂閱者的IP地址發(fā)送給發(fā)布者，發(fā)布者會(huì)詢問訂閱者是否建立連接，訂閱者回復(fù)確認(rèn)連接后，發(fā)布者和訂閱者雙方連接完成，發(fā)布者設(shè)置QoS并發(fā)布最新的數(shù)據(jù)，DDS接收到數(shù)據(jù)，比較QoS，適時(shí)將數(shù)據(jù)傳遞給訂閱者。
其中，數(shù)據(jù)接收方和發(fā)送方建立連接的過程稱為DDS的發(fā)現(xiàn)過程。它主要分為參與者發(fā)現(xiàn)階段（Simple Participant Discovery Protocol, SPDP）和端點(diǎn)發(fā)現(xiàn)階段（Simple Endpoint Discovery Protocol, SEDP）。在參與者發(fā)現(xiàn)階段，用于實(shí)現(xiàn)參與者之間的相互發(fā)現(xiàn)過程。在端點(diǎn)發(fā)現(xiàn)階段，用于實(shí)現(xiàn)參與者內(nèi)部端點(diǎn)之間的相互發(fā)現(xiàn)過程。發(fā)現(xiàn)機(jī)制主要有簡單發(fā)現(xiàn)、靜態(tài)發(fā)現(xiàn)、發(fā)現(xiàn)服務(wù)器、手動(dòng)發(fā)現(xiàn)四種。
3 數(shù)據(jù)分發(fā)服務(wù)在車輛上的應(yīng)用
目前，車輛上的通信大多數(shù)是采用AUTOSAR的架構(gòu)。AUTOSAR CP主要應(yīng)用于對(duì)于實(shí)時(shí)性、功能安全要求高，算力要求低的場景，如底盤控制，發(fā)動(dòng)機(jī)控制等傳統(tǒng)電子控制單元（Electronic Control Unit, ECU）。AUTOSAR AP主要應(yīng)用于對(duì)算力要求較高、對(duì)實(shí)時(shí)性和功能安全要求稍低的場景，如自動(dòng)駕駛域、智能座艙等新型域控制器。
目前主流的芯片設(shè)計(jì)方案采用異構(gòu)核方式，通過把AP部署在高性能核上完成高性能運(yùn)算指令，CP部署在實(shí)時(shí)性核上完成實(shí)時(shí)性要求較高的控制指令。
DDS在車輛上的應(yīng)用處于剛起步階段。簡單來說，DDS在車輛上的部署主要有三種方式。第一種是類似于ROS2或Cyber RT，對(duì)DDS進(jìn)行封裝后，直接將DDS部署在操作系統(tǒng)上，在DDS的上層部署各個(gè)應(yīng)用層模塊，如圖4所示。
圖4 DDS直接部署
第二種是依托AUTOSAR AP平臺(tái)，將DDS部署在AP的Ara::com模塊中，如圖5所示。由于AUTOSAR AP已經(jīng)能支持DDS的集成，基于AUTOSAR分層架構(gòu)，DDS的部署和SOME/IP一樣對(duì)于應(yīng)用層是透明的。通過不同的網(wǎng)絡(luò)綁定，DDS便能較為快捷地集成在AUTOSAR AP中。
第三種，面向資源受限設(shè)備的DDS集成方案，即將DDS部署在微控制器（Micro Control Unit, MCU）上。這樣MCU便能通過DDS與其他的DDS網(wǎng)絡(luò)通信實(shí)現(xiàn)信息交互。而傳統(tǒng)的MCU一般是基于AUTOSAR CP開發(fā)的，而目前CP平臺(tái)僅支持SOME/IP的功能，并不支持DDS的集成。另外，一般基于C++版本實(shí)現(xiàn)的DDS資源占用率較高，并不適合部署在資源受控的微控制器上，因此，需要開發(fā)DDS的輕量化版本。方式之一是將DDS的功能實(shí)現(xiàn)在復(fù)雜設(shè)備驅(qū)動(dòng)模塊，實(shí)現(xiàn)與AUTOSR CP的集成，如圖6所示。
圖5 DDS集成AUTOSAR AP
圖6 DDS集成AUTOSAR CP
一個(gè)DDS在車輛上部署的例子如圖7所示；該車型共使用地平線J5和TI的TDA4共兩塊芯片。其中在J5直接部署DDS；在TDA4的A核上部署集成在AUTOSAR AP上的DDS，R核上部署集成在AUTOSAR CP上的DDS。兩塊芯片通過車載以太網(wǎng)進(jìn)行連接，它們之間的通信方式有UDP、共享內(nèi)存（SHM）、零拷貝（ZeroCopy）及跨核通信等。
圖7 DDS在某車型上的部署
圖8 DDS在車輛上的部署流程
圖9 用戶定義的數(shù)據(jù)類型
表1 定義數(shù)據(jù)類型得到的文件
圖10 程序運(yùn)行結(jié)果
END
