以太網(wǎng)技術(shù)引入汽車工業(yè)，不僅大大增加了可用帶寬，而且在汽車環(huán)境中建立起了基于IP的通信。以太網(wǎng)最初的應(yīng)用是跟車外交互的診斷，尤其是ECU刷寫。傳統(tǒng)的動力域、車身域和底盤域繼續(xù)使用傳統(tǒng)總線技術(shù)，例如CAN、LIN和FlexRay，并采用基于信號的方式來配置通信。不過，將更多的通信轉(zhuǎn)移到以太網(wǎng)上，充分利用以太網(wǎng)的技術(shù)優(yōu)勢是很有意義的。

汽車工業(yè)引入了一個新的以太網(wǎng)物理層（“車載以太網(wǎng)”/100BASE-T1）和第一個汽車中間件協(xié)議：SOME/IP（Scalable service-Oriented MiddlewarE over IP）。一段時間以來，對來自于IT行業(yè)和物聯(lián)網(wǎng)（IoT）領(lǐng)域的協(xié)議的討論越來越多。這些協(xié)議的主要特點是以數(shù)據(jù)為中心，包括DDS（Data Distribution Service）和MQTT（Message Queuing Telemetry Transport Protocol）。REST（REpresentational State Transfer）也適用于個別的應(yīng)用場景。然而，REST缺少一個對于工程控制系統(tǒng)很重要的特性：不能以事件觸發(fā)的方式（on Event）發(fā)送數(shù)據(jù)。如果不支持這種特性，協(xié)議就不可能在汽車領(lǐng)域得到廣泛的應(yīng)用，這就是為什么本文不再進(jìn)一步討論REST的原因。

MQTT于1999年發(fā)布，自2013年起由OASIS組織進(jìn)行管理。MQTT的兩個主要版本是3.1.1版（在ISO/IEC標(biāo)準(zhǔn)20922中發(fā)布）和后續(xù)2019年發(fā)布的第5版本。MQTT的主要優(yōu)點是資源需求低和在不可靠網(wǎng)絡(luò)中的適用性，這使其在物聯(lián)網(wǎng)領(lǐng)域很受歡迎。MQTT依賴于一個中央“服務(wù)器”（Broker），它會在發(fā)送者（Publisher）和接收者（Subscriber）之間傳遞信息（Topic）。節(jié)點可以在某些主題下發(fā)送報文，也可以訂閱接收某些主題下的報文。MQTT使用TCP作為傳輸協(xié)議（如圖1）。

在基于信號的通信領(lǐng)域，信號是周期性發(fā)送，或者事件觸發(fā)的。遠(yuǎn)程過程調(diào)用（RPC）的本地通信機制或本機動態(tài)訂閱機制不支持變更通知。如果需要，可以在應(yīng)用層手動模擬實現(xiàn)變更通知，而SOME/IP與生俱來可以支持此機制。事件觸發(fā)的數(shù)據(jù)傳輸同樣也是MQTT和DDS通信的基礎(chǔ)。而對于這兩種協(xié)議，雖然RPC（MQTT Version 5）的必要性也被意識到了，但是它們不能直接支持RPC，而是需要通過轉(zhuǎn)發(fā)和返回通道來組合多個主題去實現(xiàn)。

MQTT協(xié)議規(guī)定了字節(jié)數(shù)組最大長度為256M字節(jié)，有效數(shù)據(jù)（UTF8編碼字符串）的序列化和反序列化可以由發(fā)送方和接收方自主處理。DDS提供的數(shù)據(jù)有詳細(xì)類型和專用傳輸協(xié)議，然而和MQTT一樣，它也會涉及字節(jié)數(shù)組的序列化。SOME/IP詳細(xì)定義了數(shù)據(jù)類型，同時定義了支持的數(shù)據(jù)類型的序列化。SOME/IP允許基于其4 字節(jié)長度字段的數(shù)據(jù)報文的有效負(fù)載高達(dá)4GB。

數(shù)據(jù)或者服務(wù)的發(fā)布者和訂閱者如何找到彼此呢？在動態(tài)系統(tǒng)中，這是一個基本問題，尤其是在有多個實例（即有多個數(shù)據(jù)提供者）的情況下。SOME/IP采用“服務(wù)發(fā)現(xiàn)”來解決這一問題?！胺?wù)發(fā)現(xiàn)”是一種在運行時提供服務(wù)和訂閱通知的機制，在DDS中也存在這種機制。MQTT的實現(xiàn)機制有所不同，因為有中央“服務(wù)器”的存在，“服務(wù)器”在運行時會管理所有的主題。如需獲得所有主題的列表，可以在根級別，通過通配符訂閱所有主題。

服務(wù)質(zhì)量（QoS）參數(shù)通常被用來比較通信協(xié)議的優(yōu)劣，它們包括數(shù)據(jù)速率、可靠性和容錯性等參數(shù)。如果中間件協(xié)議并沒有涵蓋所有的特性，則需要在應(yīng)用程序中，即更高層面上來實現(xiàn)，其中一些參數(shù)也會受到底層傳輸協(xié)議的影響。在MQTT中，唯一指定的QoS參數(shù)就是可靠性。用戶可以在發(fā)布（發(fā)送方到“服務(wù)器”）和訂閱（“服務(wù)器”到接收方）三種不同的QoS級別之間進(jìn)行選擇，它們的支持范圍從發(fā)送后不負(fù)責(zé)，到包含歷史值在內(nèi)的發(fā)送后確認(rèn)。SOME/IP并沒有定義自己的QoS機制，它依賴于應(yīng)用程序以及TCP和UDP的通信機制。DDS支持廣泛的QoS機制，不僅實現(xiàn)了傳輸?shù)目煽啃?，還實現(xiàn)了延遲容忍性和容錯性，同時還提供了軟件看門狗、數(shù)據(jù)保存和元數(shù)據(jù)管理等功能，這些功能可以讓應(yīng)用程序節(jié)省大量工作。

目前絕大多數(shù)支持以太網(wǎng)和IP的ECU都是基于AUTOSAR（AUTomotive Open System 

ARchitecture）開發(fā)的。當(dāng)考慮DDS、MQTT和SOME/IP的嵌入式實現(xiàn)時，會出現(xiàn)一個問題：怎樣才能把它們集成到現(xiàn)有的AUTOSAR解決方案中呢？在既定的軟件架構(gòu)中，解決方案帶來的內(nèi)存使用和處理器負(fù)載也很重要。AUTOSAR擁有兩個基礎(chǔ)平臺：經(jīng)典平臺（CP）和自適應(yīng)平臺（AP）。CP是為傳統(tǒng)控制系統(tǒng)而設(shè)計的，一般使用相對較小的微控制器，配置基本上是靜態(tài)的，由符合AUTOSAR標(biāo)準(zhǔn)的操作系統(tǒng)控制。整個解決方案是以二進(jìn)制形式整體編譯的，能夠滿足實時性和較短啟動時間的嚴(yán)格要求。然而一般來說，CP使用的微控制器具有非常有限的RAM和ROM資源，特別是和AP系統(tǒng)所使用的微處理器相比較。作為高性能ECU的補充標(biāo)準(zhǔn)，AP被設(shè)計為在微處理器上執(zhí)行，運行在POSIX標(biāo)準(zhǔn)操作系統(tǒng)上。AP系統(tǒng)的內(nèi)存資源一般是可擴展的，因為它們通常使用外部Flash和RAM芯片?？偟膩碚f，在AP中，靈活性得到了很好的體現(xiàn)，這種靈活性主要指后期增加或者更新軟件功能。

在CP中，應(yīng)用層和基礎(chǔ)軟件通過運行時環(huán)境（RTE）連接在一起；在AP中，協(xié)議規(guī)范的實現(xiàn)是通過ARA:COM接口下的協(xié)議綁定。對于SOME/IP，CP和AP都已有實現(xiàn)。然而對于DDS和MQTT，目前的方法是通過集成已有的物聯(lián)網(wǎng)領(lǐng)域的實現(xiàn)，并將它們適配于AUTOSAR。AP中已經(jīng)定義如何綁定DDS，所以初步看來，經(jīng)過適當(dāng)?shù)墓ぷ?，將DDS和AP集成在一起是可能的。CP的情況大不一樣，支持DDS需要對RTE進(jìn)行比較大的調(diào)整，所以目前還沒有這方面的規(guī)范計劃。另一方面，CP或者AP都還沒有支持MQTT的計劃（如圖4）。此外，所有的協(xié)議都需要通過Socket進(jìn)行通信。這時很重要的一點就是要考慮TCP/IP協(xié)議棧的接口，尤其是在CP中，SOME/IP協(xié)議頭的一部分被直接放在Socket適配器中，這個方法對于DDS和MQTT是不可能的，因為缺乏協(xié)議兼容性。

在功能安全系統(tǒng)設(shè)計方面，MQTT最關(guān)鍵的就是它的中央“服務(wù)器”，該“服務(wù)器”必須在功能安全相關(guān)的系統(tǒng)中進(jìn)行冗余處理，因為它是潛在的單點故障。MQTT第5版在這一方面得到了很好的解決：有一個選項可以指定備用服務(wù)器的地址，這樣對于功能安全就不存在重大的障礙。與此同時，在數(shù)據(jù)量大的情況下，MQTT的中央“服務(wù)器”還有處理瓶頸，必須對其進(jìn)行相應(yīng)的調(diào)整。

在DDS的分散布局和SOME/IP通信架構(gòu)中就不存在這個挑戰(zhàn)。如果電子電氣架構(gòu)由不同的合作伙伴來實現(xiàn)，就需要一個標(biāo)準(zhǔn)的交換格式。DDS和SOME/IP得益于被納入AUTOSAR標(biāo)準(zhǔn)（DDS僅在Adaptive AUTOSAR中），因此它們可以用標(biāo)準(zhǔn)化的方式來描述。這在MQTT中沒有實現(xiàn)，部分原因是在定型和細(xì)節(jié)深度的引用差異。