作者：姜鴻雷
[本文選自《智能汽車(chē)：新一代技術(shù)與應用》.姜鴻雷.電子工業(yè)出版社——書(shū)中第八章部分內容]
前言
SOA（面向服務(wù)的架構）的軟件設計原則之一是模塊化。模塊化可以提高軟件系統的可維護性和代碼重用性，并且能夠隔離故障。舉例來(lái)說(shuō)，自動(dòng)駕駛系統可以分解為特定的任務(wù)模塊，如數據采集、狀態(tài)估計和任務(wù)規劃等。為了完成各自的任務(wù)，這些模塊需要相互交換信息。在現代操作系統中，將單個(gè)模塊映射到獨立的軟件進(jìn)程非常方便，這些進(jìn)程可以位于同一計算設備上，也可以位于物理上獨立的計算設備上。這使得進(jìn)程間通信成為一個(gè)深入研究的問(wèn)題，因為信息交換是通過(guò)進(jìn)程間的通信來(lái)實(shí)現的。
一. 通信中間件
在軟件定義汽車(chē)中，應用程序之間的跨進(jìn)程或跨核通信是一個(gè)需要解決的問(wèn)題。模塊化架構為開(kāi)發(fā)人員提供了便利，但也引入了對通信中間件的需求。
在沒(méi)有使用通信中間件的情況下，開(kāi)發(fā)人員需要自己定義數據的格式、發(fā)送方和接收方。然而，使用基于服務(wù)/數據的發(fā)布和訂閱模式（如SOME/IP和DDS），開(kāi)發(fā)人員只需要明確需要什么樣的數據以及數據應該傳遞到哪里，而無(wú)需關(guān)注數據的發(fā)送方和發(fā)送方式。
以數據為中心是相對于傳統的以消息為中心而言的，其本質(zhì)區別在于通信中間件知道存儲了什么數據并能夠控制如何共享這些數據。對于傳統的以消息為中心的中間件，程序員必須為發(fā)送消息編寫(xiě)代碼，而對于以數據為中心的中間件，程序員只需為如何共享數據編寫(xiě)代碼，然后可以直接共享數據值。
通信中間件可以采用點(diǎn)對點(diǎn)、消息隊列和發(fā)布/訂閱三種工作模式，SOME/IP和DDS都采用了發(fā)布/訂閱模式。
在發(fā)布/訂閱模型中，發(fā)布者和訂閱者通過(guò)主題進(jìn)行關(guān)聯(lián)，雙方不需要知道對方在何處，也不需要同時(shí)在線(xiàn)。這實(shí)現了通信雙方在時(shí)間、空間和數據通信上的多維松耦合。
此外，與面向信號的CAN相比，DDS和SOME/IP都是面向服務(wù)的通信協(xié)議。兩者的區別在于面向信號的數據傳輸始終循環(huán)發(fā)送，而面向服務(wù)的通信方式不同，只有在客戶(hù)端請求或服務(wù)器通知特定訂閱者時(shí)，才在客戶(hù)端-服務(wù)器配置中交換數據。這確保了永遠不會(huì )浪費帶寬，并且僅在需要的時(shí)間和地點(diǎn)進(jìn)行數據通信/交換。因此，面向服務(wù)的通信協(xié)議可以大大減少網(wǎng)絡(luò )負載，提高通信效率。
在軟件定義汽車(chē)時(shí)代，車(chē)內的所有可調用功能都被視為服務(wù)，并提供不同類(lèi)型的調用接口，這些接口可以按以下方式分類(lèi)：
1、API接口：提供各類(lèi)函數的調用接口，使應用程序能夠調用系統內部的功能實(shí)現函數。應用程序可以通過(guò)調用相關(guān)的API接口來(lái)提供和使用功能服務(wù)。
2、文件方式：以配置文件或設備文件的形式提供系統內部的調用能力。這些文件可以通過(guò)配置自動(dòng)生成，包含有效的配置信息，并且可以在運行環(huán)境中被特定的程序讀取和識別，實(shí)現特定的服務(wù)。
3、系統原生服務(wù)：操作系統和基礎類(lèi)庫提供的可操作能力，包括對系統CPU和內存的監測、應用程序的監控、系統資源的劃分等。此外，還可以調用C++、boost等基礎類(lèi)庫。
4、IPC接口：各種IPC機制提供系統內進(jìn)程間的調用能力，包括使用套接字（socket）、共享內存等進(jìn)程間通信方式，以及使用特定的跨核通信方式如IPCF。
5、協(xié)議棧接口：通過(guò)網(wǎng)絡(luò )協(xié)議棧提供跨平臺的調用能力，包括SOME/IP、DDS、MQTT、HTTP等網(wǎng)絡(luò )協(xié)議的調度服務(wù)、接口封裝和協(xié)議轉換等。
盡管在互聯(lián)網(wǎng)領(lǐng)域中SOA（面向服務(wù)的架構）已經(jīng)被應用了很長(cháng)時(shí)間，但在汽車(chē)行業(yè)中，它算是相對較新的概念。在A(yíng)daptive AutoSAR框架中，通信管理模塊包括進(jìn)程間通信和網(wǎng)絡(luò )協(xié)議棧。
鑒于汽車(chē)應用場(chǎng)景和通信需求的特殊性，許多互聯(lián)網(wǎng)的SOA技術(shù)并不能直接應用于汽車(chē)領(lǐng)域。一般來(lái)說(shuō)，SOA通信中間件系統的各個(gè)層面需要滿(mǎn)足以下要求：
1、本地服務(wù)和遠程服務(wù)之間的通信應該使用統一的接口描述語(yǔ)言（IDL）定義的文件作為契約。IDL是一種中立的接口描述語(yǔ)言，與具體的操作系統和編程語(yǔ)言無(wú)關(guān)。
2、SOA框架的底層核心功能應具備以下特點(diǎn)：服務(wù)發(fā)現、消息序列化、內部事件/消息處理和傳輸功能。應用程序、服務(wù)和操作系統之間可以通過(guò)標準的通信協(xié)議或服務(wù)接口相互通信或訪(fǎng)問(wèn)，特別是要滿(mǎn)足傳感數據的大數據吞吐傳輸需求。必須支持典型的車(chē)內通信協(xié)議，如SOME/IP協(xié)議、DDS規范等。服務(wù)發(fā)現功能應具備訪(fǎng)問(wèn)控制功能，以防止未經(jīng)授權的用戶(hù)進(jìn)行竊聽(tīng)和侵入；傳輸功能應具備數據加密和簽名等功能，以確保通信數據的安全性。
在未來(lái)，汽車(chē)將與更多的基礎設施進(jìn)行連接，為了實(shí)現與它們的連接，將需要使用不同的通信協(xié)議。
汽車(chē)SOA 通信架構
HTTP、MQTT、SOME/IP和DDS等協(xié)議都用于實(shí)現SOA架構中的通信，只是在不同的場(chǎng)景下承擔不同的責任。例如，SOME/IP協(xié)議用于車(chē)內節點(diǎn)之間的服務(wù)通信，而HTTP和MQTT用于與互聯(lián)網(wǎng)模塊進(jìn)行通信。盡管它們在實(shí)現機制上有些許差異，但它們可以相互切換使用。
MQTT、DDS、AMQP、REST和CoAP等協(xié)議都已被廣泛應用，并且每種協(xié)議都至少有10種不同的代碼實(shí)現。它們都宣稱(chēng)支持實(shí)時(shí)的發(fā)布/訂閱物聯(lián)網(wǎng)協(xié)議。然而，在具體的系統架構設計中，需要考慮實(shí)際場(chǎng)景中的通信需求，并選擇適合的協(xié)議。各種協(xié)議的特點(diǎn)如表所示。
二、SOME/IP 介紹
2011年，寶馬設計并提出了SOME/IP（Scalable Service-oriented Middleware over IP）協(xié)議。SOME/IP采用服務(wù)器-客戶(hù)端的服務(wù)通信模式，并且具備高度可擴展性。SOME/IP協(xié)議是一種應用層協(xié)議，運 行在TCP/UDP傳輸協(xié)議之上（車(chē)載以太網(wǎng)第四層以上）。它作為以太網(wǎng)通信的中間件，實(shí)現應用層與IP層之間的數據交互，使其不依賴(lài)于操作系統，并且兼容AUTOSAR和非AUTOSAR平臺。因此，SOME/IP可以獨立于硬件平臺、操作系統和編程語(yǔ)言。
SOME/IP 協(xié)議架構
SOME/IP具備滿(mǎn)足車(chē)用需求的特性，主要包括以下幾個(gè)方面：基于服務(wù)的通信方式，占用空間小，與AUTOSAR兼容（其他中間件不具備兼容性），可伸縮性（適用于小型和大型平臺），以及兼容性（可適用于車(chē)輛使用的各種操作系統，如AUTOSAR、OSEK、QNX和Linux）。
SOME/IP支持AUTOSAR CP、AUTOSAR AP以及非AUTOSAR平臺之間的通信交互。寶馬設計SOME/IP協(xié)議后，它被AUTOSAR納入正式標準，并隨著(zhù)CP規范的發(fā)布而被廣泛應用于車(chē)載以太網(wǎng)，因此可以說(shuō)是AUTOSAR CP推動(dòng)了SOME/IP的廣泛使用。
在A(yíng)UTOSAR架構中，SOME/IP-SD模塊位于A(yíng)UTOSAR BSW Mode Manager模塊（BswM）和AUTOSAR Socket Adaptor模塊（SoAd）之間。BswM模塊提供了通用模式請求和服務(wù)請求之間的連接，而SoAd模塊處理以太網(wǎng)堆棧和SD模塊之間的服務(wù)請求。通過(guò)配置SoAd中的Socket Connection表，可以接收其他ECU的SD模塊發(fā)送的單播和多播報文。
借助SOME/IP協(xié)議的高度平臺擴展性，可以實(shí)現不同平臺之間的數據交互，而統一的SOME/IP通信機制是不同平臺通信的前提。為了在不同軟件平臺上運行SOME/IP，實(shí)現整車(chē)以太網(wǎng)上的SOA架構通信機制，AP規范中也同步引入了SOME/IP，因此在A(yíng)UTOSAR系統中，CP和AP之間實(shí)現SOME/IP通信相對容易。
為了促進(jìn)非AUTOSAR軟件平臺與車(chē)內CP和APECU之間的交互，GENIVI系統同樣開(kāi)發(fā)了一套開(kāi)源的vSOME/IP軟件源碼，以便與CP/AP進(jìn)行交互。然而，由于vSOME/IP是開(kāi)源的，性能可能略有差異，因此需要統一的規范進(jìn)行約束，以進(jìn)行深度的二次開(kāi)發(fā)。目前，全球最大的商用SOME/IP產(chǎn)品供應商是Vector，而開(kāi)源版的vSOME/IP由GENIVI協(xié)會(huì )維護。
三、DDS 介紹
DDS（Data Distribution Service）是由OMG（Object Management Group）發(fā)布的分布式通信規范。OMG成立于1989年，是一個(gè)國際性、開(kāi)放性、非營(yíng)利性的技術(shù)標準聯(lián)盟，由供應商、終端用戶(hù)、學(xué)術(shù)機構和政府機構推動(dòng)。OMG工作組致力于制定企業(yè)集成標準和開(kāi)發(fā)可為數千個(gè)垂直行業(yè)提供現實(shí)價(jià)值的技術(shù)標準，其中包括統一建模語(yǔ)言SYSML、UML，以及中間件標準CORBA、DDS等。
DDS最早應用于美國海軍系統，用于解決在軍艦系統復雜網(wǎng)絡(luò )環(huán)境中進(jìn)行大量軟件升級時(shí)的兼容性問(wèn)題。隨著(zhù)DDS被ROS2和AUTOSAR引入，目前它已經(jīng)廣泛應用于航空、航天、船舶、國防、金融、通信、汽車(chē)等領(lǐng)域。
DDS的特點(diǎn)：
1、數據中心（Data Centricity）
DDS 數據中心
DDS實(shí)現的數據共享可以被理解為一個(gè)抽象的全局數據空間，無(wú)論應用程序是用哪種開(kāi)發(fā)語(yǔ)言編寫(xiě)，或者在哪種操作系統上運行，都可以以相同的方式訪(fǎng)問(wèn)這個(gè)全局數據空間，就像訪(fǎng)問(wèn)本地存儲空間一樣。當然，全局數據空間只是一個(gè)抽象概念，在實(shí)際實(shí)現中，數據仍然被分別存儲在每個(gè)應用程序的本地空間中。在系統運行時(shí)，數據是按需傳輸或存儲的，數據的發(fā)布者只發(fā)送訂閱者需要的數據，而訂閱者只接收并存儲本地應用程序當前所需的數據。
全局數據空間
DDS還提供了高度靈活的QoS（Quality of Service）策略，以滿(mǎn)足用戶(hù)對數據共享方式的不同需求，例如可靠性和故障處理等。對于對數據安全性要求較高的系統，DDS還提供了精細的數據安全控制，包括應用程序身份認證、權限控制和數據加密等。
4、動(dòng)態(tài)發(fā)現（Dynamic Discovery）
類(lèi)似于SOME/IP-SD，DDS提供了數據發(fā)布者和訂閱者的動(dòng)態(tài)發(fā)現機制，這意味著(zhù)用戶(hù)無(wú)需手動(dòng)配置通信節點(diǎn)的地址或其他屬性信息，因為它們在運行過(guò)程中會(huì )自動(dòng)發(fā)現對方并自動(dòng)完成相關(guān)配置，實(shí)現了即插即用的功能。
5、可擴展架構（Scalable Architecture）
DDS可應用于邊緣計算、霧計算和云計算領(lǐng)域。在邊緣計算中，DDS可以實(shí)現高速實(shí)時(shí)的設備間通信。在中間系統中，DDS提供健壯可靠的QoS和內容感知的信息流。DDS提供可擴展的信息訪(fǎng)問(wèn)和數據分發(fā)手段，用于集成信息系統，將各系統接入云端。
OMG DDS的適用范圍廣泛，涵蓋了從小型設備到云計算系統等超大型系統。DDS能夠以超高速傳輸數據并同時(shí)管理數千個(gè)數據對象，提供極高的可用性和安全性，非常適用于物聯(lián)網(wǎng)。通過(guò)提供一個(gè)標準的通信層，DDS屏蔽了底層復雜性，簡(jiǎn)化了分布式系統的開(kāi)發(fā)。
可擴展架構
6、安全（Security）DDS為關(guān)鍵任務(wù)的工業(yè)物聯(lián)網(wǎng)環(huán)境提供了全面的安全保護機制，跨系統、跨供應商，覆蓋從邊緣設備到云端的安全性需求。
DDS提供了身份驗證、訪(fǎng)問(wèn)控制、數據加密和數據完整性等安全機制，以確保數據分發(fā)的安全性。這些安全機制是在點(diǎn)對點(diǎn)對等架構上實(shí)現的，不會(huì )影響實(shí)時(shí)通信的性能。
目前，DDS已被多個(gè)車(chē)載中間件平臺引入。AUTOSAR AP已完整地集成了DDS標準的網(wǎng)絡(luò )綁定。另外，雖然AUTOSAR CP的標準規范本身不支持DDS，但通過(guò)一些變通方法也可以在CP上集成DDS。ROS2和CyberRT的底層都使用了開(kāi)源的DDS作為最重要的通信機制。針對自動(dòng)駕駛領(lǐng)域的SOC芯片，如Xavier和Orin，也都預留了DDS接口。RTI作為OMG組織董事會(huì )的成員，領(lǐng)導了DDS標準的制定，并開(kāi)發(fā)了名為Connext的DDS品牌，因此也被稱(chēng)為Connext DDS。
開(kāi)源DDS相對于商用的RTI DDS等來(lái)說(shuō)，是根據OMG官方標準開(kāi)發(fā)的，但源代碼是開(kāi)放的，主要包括Fast DDS和Open DDS等。
在自動(dòng)駕駛領(lǐng)域，由RTI原核心團隊成員在歐洲創(chuàng )辦的eProsima公司推出了影響力較大的開(kāi)源DDS，名為Fast DDS。在eProsima將Fast DDS的源代碼開(kāi)放后，用戶(hù)可以直接在GitHub上免費下載。使用Fast DDS需要向eProsima支付費用以獲得支持。
Open DDS由位于圣路易斯和鳳凰城的Object Computing的ACE/TAO團隊開(kāi)發(fā)，與Fast DDS有一定的相似性，兩者都基于RTPS實(shí)現，都是面向數據的通信框架，并遵循同一標準。這類(lèi)框架的典型特征是去中心化、支持QoS機制和實(shí)時(shí)通信，并通常與序列化工具如protobuf進(jìn)行綁定。
盡管開(kāi)源DDS對RTI的商用DDS形成一定的競爭，但開(kāi)源DDS也存在一些不足之處：開(kāi)源DDS的使用門(mén)檻較高，例如RTI DDS的服務(wù)策略有50多個(gè)，而開(kāi)源DDS只有23個(gè)，完整性遠不及前者；RTI的DDS已通過(guò)了ASIL-D認證，而開(kāi)源DDS尚未達到這一認證水平。
四、SOME/IP 與 DDS 對比
SOME/IP和DDS是目前在域控最常用的兩類(lèi)通信中間件，它們都是面向服務(wù)的通信協(xié)議，并采用以數據為中心的發(fā)布/訂閱模式。
然而，SOME/IP和DDS在許多方面也存在差異，主要區別如下：
1、主要應用領(lǐng)域不同：SOME/IP專(zhuān)為汽車(chē)領(lǐng)域開(kāi)發(fā)，針對汽車(chē)領(lǐng)域的需求定義了一套通信標準，并在汽車(chē)領(lǐng)域深耕已久；而DDS是一個(gè)工業(yè)級別的強實(shí)時(shí)通信標準，適應性較強，但在應用于汽車(chē)/自動(dòng)駕駛領(lǐng)域時(shí)需要進(jìn)行專(zhuān)門(mén)的裁剪。
2、靈活性和可伸縮性不同：相比SOME/IP，DDS引入了許多標準內置特性，如基于內容和時(shí)間的過(guò)濾、與傳輸無(wú)關(guān)的可靠性、持久性、存活性、延遲/截止時(shí)間監視、可擴展類(lèi)型等。當AUTOSAR AP與DDS一起構建通信框架時(shí)，該框架不僅與現有API和應用程序兼容，還在可靠性、性能、靈活性和可伸縮性等方面提供重要的好處。
3、訂閱方和發(fā)布方的耦合程度不同：在SOME/IP中，訂閱方在正常數據傳輸之前需要與發(fā)布方建立網(wǎng)絡(luò )連接并詢(xún)問(wèn)發(fā)布方是否提供所需服務(wù)，從這個(gè)角度看，節點(diǎn)之間仍然存在一定的耦合性。而在DDS標準下，每個(gè)訂閱方或發(fā)布方只需要在自己的程序中訂閱或發(fā)布傳感器數據，無(wú)需關(guān)心任何連接。因此，在DDS中，服務(wù)的訂閱方和發(fā)布方更加徹底地解耦。
4、服務(wù)策略不同：良好的服務(wù)質(zhì)量（QoS）是DDS標準相對于SOME/IP最重要的特征。SOME/IP只有一個(gè)QoS，而RTI DDS和開(kāi)源DDS分別提供了50多個(gè)和20多個(gè)QoS，這些QoS基本上涵蓋了大多數可預見(jiàn)的智能駕駛場(chǎng)景。
5、應用場(chǎng)景不同：從應用場(chǎng)景的角度來(lái)看，SOME/IP更適用于車(chē)載網(wǎng)絡(luò )，并且只能在基于IP類(lèi)型的網(wǎng)絡(luò )環(huán)境中使用；而DDS在傳輸方式上沒(méi)有特別的限制，可以支持基于非IP類(lèi)型的網(wǎng)絡(luò )，例如共享內存、跨核通信、PCIe等。此外，DDS還提供了完備的車(chē)聯(lián)網(wǎng)解決方案，其獨有的DDS Security和DDS Web功能為用戶(hù)提供了一站式的“車(chē)-云-移動(dòng)端”解決方案。
參考文獻：
[1] 宋珂. AUTOSAR規范與車(chē)用控制器軟件開(kāi)發(fā). [M]. 化學(xué)工業(yè)出版社. 2019-01[2] 中國汽車(chē)基礎軟件生態(tài)委員會(huì ). 車(chē)載SOA軟件架構技術(shù)規范1.1. [R]. 2021-09[3] Dr. Joachim Schlosser. Why Scrum for embedded software. [R]. 2020-07[4] Stefan Wagener.Jochen M?ller.Christof Menzenbach. How high-performance computers shape the user experience in the cockpit of the future. [R].[5] JASPAR Next Generation High-Speed Network WG. What is the conqueror in the SOA platform for the future in-vehicle networks? [R]. 2021-06[6] ARM. How the SOAFEE Architecture Brings A Cloud-Native Approach To Mixed Critical Automotive Systems. [R]. 2021-09[7] Jochen Steuerwald. A tool and workflow approach for automotive ECUs using AUTOSAR Classic. [R]. 2020-06[8] Steffen Kuhn. Combined application of agile practices and functional safety in automotive software development. [R]. 2020-10[9] STEVE HOWARD.JILL BRITTON. Claiming Compliance for Coding Standards. [R].[10] Trista Lin.David Fernandez Blanco.Juleixis Guariguata. Communication Management in Automotive Service Oriented Architectures. [R]. 2021-11[11] dSPACE Inc. The future of agile software development and validation for autonomous vehicles. [R]. 2021[12] Oded Mann.Amit Shah. Future E/E vehicle architectures and the shifting goal post for mainstream OTA adoption. [R]. 2021-10[13] W3C.GENIVI. Service Oriented Architecture is coming to your vehicle program. [R]. 2021-04[14] Anders Kallerdahl. How can we design and configure systems where Adaptive and Classic AUTOSAR co-exist? [R]. 2020-11[15] Christian G?tz. How to Build a Reliable Connected Car Platform with MQTT. [R]. 2020-02[16] Robert Bosch. INTRODUCTION TO ECLIPSE ICEORYX [R]. 2020-02[17] Vikrant Bhangay.Shehan P R.Renjith G. Modern day eCockpit Architecture-Approaches & Challenges. [R]. 2020-04[18] 中國汽車(chē)工業(yè)協(xié)會(huì ). 軟件定義汽車(chē)服務(wù)API.[19] Omkar Panse. Service oriented architecture for software driven vehicles.[20] ARM. Scalable Open Architecture For the Embedded Edge. [R]. 2021[21] David Rush.Erich Meier. The Future of Work Digital Transformation in Engineering. [R]. 2021[22] Rensas.Opensynergy. Implement virtual I/O device(virtio) standard. [R]. 2021[23] 龔小平. 基于模型設計開(kāi)發(fā)面向服務(wù)的應用. [R]. 2021-05[24] （法）尼古拉斯·納威特，（法）弗朗西斯·西蒙-萊昂. 汽車(chē)嵌入式系統手冊. [M]. 機械工業(yè)出版社. 2016-01[25] 汪珺. 汽車(chē)行業(yè)的IT數字化轉型——DevOps. [R]. 2022-01[26] 楊國梁. 通過(guò)Shift Left 提高汽車(chē)軟件競爭力. [R]. 2021-04[27] 云原生產(chǎn)業(yè)聯(lián)盟. 云原生發(fā)展白皮書(shū). [Z]. 2020-07[28] 中國汽車(chē)工業(yè)協(xié)會(huì ). 中國汽車(chē)基礎軟件發(fā)展白皮書(shū) 2.0. [Z]. 2021-09[29] 楊世春. 自動(dòng)駕駛汽車(chē)平臺技術(shù)基礎. [M]. 清華大學(xué)出版社. 2020-06[30] 肖猛. 自動(dòng)駕駛軟件架構之中間件與SOA. [R]. 2021-10
轉自汽車(chē)電子與軟件
