自動駕駛中間件之二：通信中間件，DDS與SOME/IP 誰主沉浮？

随着傳感器的數量越來越多，資料來源越來越多、規模也會越來越大，那這些多源異構資料如何在晶片之間、在各任務程序之間高效、穩定地傳遞，確定“在正确的時間，傳遞正确的資料，并確定資料抵達正确的地點”呢？

會有哪些資訊在子產品之間共享？如何将這些資訊發送編碼到消息中？如何将消息從一個子產品傳遞到另一個子產品？如何在接收到消息後解碼？各個子產品間的通信分别花了多長時間？

在OTA的時候，程序如何不被打斷？

這些問題，都需要通過“通信中間件”來解決。

在自動駕駛領域，中間件的功能涉及到通信、子產品更新、任務排程、執行管理，但其最主要的功能還是通信。目前市場上，無論是Cyber RT還是 ROS，基本上90%的功能就是通信，狹義上說它們就是通信中間件（又被稱為“消息中間件”）。

那麼，好的通信中間件應當具備哪些特征？通信中間件可分為哪些類型？常見的SOME/IP和DDS的優劣勢各是什麼？市場格局将會如何演變？接下來，我們将對這些内容做個簡單的梳理。

一．自動駕駛需要怎樣的通信中間件？

傳統的網絡通信中，在TCP協定下，資訊發出後，接收方需要發出一個信号，告訴發送方“我收到了” ，如果沒收到這個信号，那下一條資訊就不能發出；在UDP傳輸方式下，不管接收方有沒有收到，發送方都會一直發。

以往，在沒有用通信中間件的時候，為了開發上層應用，開發者們需要自己去定義資料的格式、定義資料的發送方和接收方；但有了SOME/IP和DDS這種“以服務/資料為中心”的釋出和訂閱模式，開發者們隻需明确我需要什麼樣的資料、資料傳到哪兒，而無需知道資料是由誰發出的、怎樣發出的。

以資料為中心，是相對于傳統的“以消息為中心”而言的，其本質差別在于通信中間件知道它存儲了什麼資料、并能控制如何共享這些資料。

對傳統的以消息為中心的中間件，程式員必須為發送消息編寫代碼，而對以資料為中心的中間件，程式員隻需為如何及何時共享資料編寫代碼，然後就可以直接共享資料值。

通信中間件包括點到點、消息隊列和釋出/訂閱三種工作模式，SOME/IP和DDS都采用了釋出/訂閱模式。

點到點模式具有很強的時間和空間耦合性，使得通信靈活性受到很大限制；消息隊列模式通過一個消息隊列來傳遞消息，解決了通信雙方時間和空間松耦合的問題，但不能實作消息消費者通信的異步，并且還存在伺服器瓶頸和單點失效的問題，可靠性得不到保障；釋出/訂閱模型中，釋出者和訂閱者通過主題相關聯，雙方不必知道對方在何處，也不必同時線上，實作了通信雙方在時間、空間和資料通信上的多元松耦合。

此外，相比于面向信号的CAN，DDS和SOME/IP都是面向服務的通信協定。兩者的差別在于：面向信号的資料傳輸，不管網絡需不需要，它始終會不斷循環發送；而面向服務的通信方式則不同，僅當用戶端請求或伺服器通知特定訂閱者時，才在用戶端-伺服器配置中交換資料，這就確定了永遠不會浪費帶寬，并且僅在需要的時間和地點進行資料通信/交換。

是以，面向服務的通信協定，能夠大大減少網絡負載，提高通信效率。

上汽工程師殷玮在一篇文章中說，通信中間件的引入整體上可以幫助開發人員提高工作效率。

SOME/IP和DDS均已被納入AUTOSAR AP的平台标準中。

通信中間件應該包括以下幾個子產品:資料類型規範語言、消息傳遞系統、日志/回放工具和實時分析工具。這些子產品應具有如下特征：

1.資料類型規範語言應獨立于平台和具體的程式設計語言，以消除使用者實作編組（Marshalling）代碼的需要，同時保證運作時類型的安全性；

2.消息傳遞系統需要在不同的程序之間傳輸消息，并提供低延時的消息傳遞功能，且消除對中央通信的依賴，進而使混合模拟、記錄和實時資料源的工作更容易；

3.需要提供大量的日志記錄、回放和流量檢查工具，以簡化常見的開發和調試任務。

衡量一款通信中間件好壞的标準主要有如下幾點：

1.接口是否友善？接口友善是很多人喜歡用ros的原因。

2.是否安全、穩定？安全，即通信的過程中不能出現資料丢失的問題；穩定，比如，釋出訂閱的程序連續開幾天幾夜也不能當機。

3.傳輸可支援多少節點、跨多少核心？

4.在不同通信場景和通信需求下，是否可以進行靈活快速的配置？

5.吞吐量、時延。發送同樣大小的資料包，吞吐量是否更高，延遲是不是比用别的方法更低？

吞吐量，即機關時間内通過的資料量有多少；時延，即資料包傳輸的延遲性有多少。如果通信速度很慢，感覺到的資訊要經過200毫秒才能傳遞到執行系統，那感覺做得再好也無濟于事。

車速越高、資料量越大的場景，對中間件的資料吞吐能力和時延的要求就越高。某通信中間件廠商反應，他們的産品在乘用車市場上賣得特别好，但在商用車市場上反響就不行，一個原因就是商用車的駕駛場景簡單，對中間件資料吞吐能力、時延的要求比較低。

二．常見的通信中間件

根據源代碼是否開放，通信中間件可簡單地分為閉源和開源兩種。閉源的通信中間件主要有Vector公司的SOME/IP、RTI公司的DDS等;開源的通信中間件主要有OPEN DDS、FAST DDS、Cyclone DDS等。

下面，我們将對這幾類通信中間件做個簡單的介紹。

01

SOME/IP

SOME/IP的全稱為：Scalable service-Oriented MiddlewarE over IP，是一種面向服務的傳輸協定。嚴格地說，SOME/IP不是一款特定的産品，而是一種技術标準。其最早由寶馬在2012-2013年開發，并在2014年內建進AUTOSAR 4.2.1中。

目前，全球最大的商用SOME/IP産品供應商是Vector。 開源版的SOME/IP則是由Genivi協會來維護的。

02

DDS（Data Distribution Service）

提起DDS，就不得不提OMG組織。OMG是一個國際化的、開放的、非盈利的計算機行業标準協會，很多大家熟悉的标準(如uml)，都出自于OMG。DDS也是OMG組織推出的标準之一。

（圖檔來自創景資訊科技公司）

DDS的全稱為Data Distribution Service（資料分發服務)，是由OMG釋出的分布式通信規範，采用釋出/訂閱模型，提供多種QoS服務品質政策，以保障資料實時、高效、靈活地分發，可滿足各種分布式實時通信的應用需求。

DDS将分布式網絡中傳輸的資料定義為“主題”，将資料的産生和接收對象分别定義為“釋出者”和“訂閱者”，進而構成資料的釋出/訂閱傳輸模型。各個節點在邏輯上無主從關系，點與點之間都是對等關系，通信方式可以是點對點、點對多、多對多等，在QoS的控制下建立連接配接，自動發現和配置網絡參數。

DDS最早應用于美國海軍，用于解決艦船複雜網絡環境中大量軟體更新的相容性問題，後來擴充至航空、航天、船舶、國防、金融、通信、汽車等領域，包括作戰系統、船舶導航和控制系統、船舶防禦系統、無人機駕駛系統和地面控制系統、裝甲車輛控制系統、仿真和教育訓練系統、雷達處理和空中交通管理系統、金融系統等。

2018年，DDS首次被引進AUTOSAR AP，作為可選擇的通信方式之一。2018年3月，DDS的主要提供者RTI公司宣布，AUTOSAR AP的最新版本（版本18-03）已經具有DDS标準的完整網絡綁定。

ROS 2和Cyber RT的底層都使用了開源的DDS，将DDS作為最重要的通信機制。與此相對應的是，Xaver、Orin等面向自動駕駛的SOC晶片上也都預留了DDS接口。

AUTOSAR CP的标準規範中是不支援DDS的，但做一些變通後，也可以在CP上內建DDS。

全球範圍内，DDS市場佔有率最大的供應商（80%左右）的是成立于1991年的美國RTI公司（全稱為Real-Time Innovations）。RTI作為OMG組織董事會的成員，主導了DDS标準的制定，從2004年開始負責主持DDS工作組的工作，目前已經成為這個行業的上司者，對DDS标準有足夠的權威。

RTI開發的DDS品牌名為Connext,，是以又被稱為Connext DDS。

03

開源DDS：FAST DDS與OPEN DDS

開源DDS，主要是相對于商用的RTI Connext DDS等而言的，其也是根據OMG官方标準開發的，但源代碼開放。

在自動駕駛領域比較有影響力的開源DDS是由RTI原核心團隊成員在歐洲創辦的eProsima公司推出的FastDDS。在eProsima将FastDDS的源代碼開放出來後，使用者可以直接在github上免費下載下傳。但FastDDS使用起來比較麻煩，這個時候，使用者就需要通過向eProsima支付費用來取得支援。

OpenDDS 由位于聖路易斯和鳳凰城的的Object Computing的 ACE/TAO 團隊開發，它和FastDDS具有一定的相似性——兩者都是基于RTPS實作的，面向資料的通信架構，遵循的是同一标準。這類架構的典型特征是去中心化，支援QoS機制，支援實時通信。通常會綁定如protobuf等序列化工具。

在許多情況下，FastDDS 、OpenDDS可以跟RTI的Connnext DDS互操作/通信。當然，具體還得看場景。比如開源DDS 的QoS（服務政策）有 23個，大家都用這23個QOS互動，那就能互操作；如果Connext用的是超出這23個自定義範圍的QoS，那麼開源DDS就解析不了。此外，如果用的是OMG沒開源的DDS工具，那也沒法互操作。

國内某中間件廠商負責人介紹，出于成本的考量，英偉達的Xavier自帶的Driver.OS中便采用了FastDDS或OpenDDS這樣的開源DDS。

RTI方面認為，開源DDS是其最大的競争對手。

當然了，開源DDS的使用門檻也很高。比如，RTI DDS的服務政策有50多個，但開源DDS的服務政策隻有23個，完整程度遠不及前者。此外RTI的DDS已經通過了ASIL-D的認證，但開源DDS還沒有。

而據華玉通軟聯合創始人畢曉鵬的解釋，基于開源版本DDS研發的通信中間件存在“穩定性不足”的問題。

04

MQTT（開源）

MQTT是由IBM開發的即時通訊協定，其全稱是Message Queuing Telemetry Transport （消息隊列遙測傳輸）。MQTT協定也采用釋出/訂閱模式，所有的物聯網終端都通過TCP連接配接到雲端，雲端通過主題的方式管理各個裝置關注的通訊内容，負責将裝置與裝置之間消息的轉發。

由于延時控制等方面功能較差、服務政策也比較少，MQTT不适用于高速項目和大型項目，但可用于低帶寬、不可靠的網絡場景，提供基于雲平台的遠端裝置的資料傳輸和監控。在自動駕駛領域，MQTT比較典型的應用場景是V2X。

此外，MQTT在低速車領域也同樣适用。它體積極小，并能提供簡單的QoS保證，非常适合玩具車，掃地車等功能簡單、硬體資源有限的項目。

MQTT也是開源的通信中間件。

三．SOME/IP & DDS

現階段，SOME/IP和DDS是自動駕駛上用得最多的兩類通信中間件。上文已經提到，兩者的共同點主要有：都是面向服務的通信協定；都采用了“以資料為中心”的釋出和訂閱模式。那麼，兩者的主要差別又有哪些呢？

應用場景不同

SOME/IP是專為汽車領域而生的，它針對汽車領域的需求，定義了一套通信标準，并且，在汽車領域深耕的時間比較長；DDS是一個工業級别的強實時的通信标準，它對場景的适應性比較強，但在用于汽車/自動駕駛領域時需要做專門的裁剪。

靈活性、可伸縮性不同

相較于SOME/IP，DDS引入了大量的标準内置特性，例如基于内容和時間的過濾、與傳輸無關的可靠性、持久性、存活性、延遲/截至時間監視、可擴充類型等。當AUTOSAR AP與DDS一起建構一個通信架構時，該架構不僅可以與現有ara::com api及應用程式相容，而且在可靠性、性能、靈活性和可伸縮性等方面，都可以提供重要的好處。

訂閱方和釋出方是否強耦合

在SOME/IP中，在正常資料傳輸前，client需要與server建立網絡連接配接并詢問server是否提供所需服務，在這個層面上，節點間仍然具有一定耦合性。服務的訂閱方需要知道server在哪裡，服務的釋出方需要告知server提供哪種服務，例如寫一個程式，需要用到傳感器資料，這個程式要去詢問server是否可以提供傳感器資料；而在DDS标準下，每個訂閱方或釋出方隻需要在自己的程式裡面訂閱或釋出傳感器資料就行了，不需要關心任何連接配接。可以了解為，在DDS中，服務訂閱方和釋出方的解耦更加徹底，需要什麼資料，寫一行代碼就行了，不需要再去做綁定。

服務政策不同

較好的QoS（服務政策）是DDS标準相比于SOME/IP最重要的特征。

SOME/IP隻有一個QoS，即可靠性的定義；而RTI DDS和開源DDS裡面分别有50多個和20多個QoS，這些QoS基本上能涵蓋絕大多數可以預見到的智能駕駛場景。

QoS具體是個什麼東西，它有何用途？華玉通軟聯合創始人兼技術副總裁畢曉鵬舉了幾個例子：

（1）通信中的傳輸優先級、資料可靠性、資源限制、時間過濾等，都需要在QoS裡面設定。

（2）資料傳輸過程中可能會出現丢幀現象，也就是說，不是每一幀都能達到接收端。針對這種現象，我們需要考慮場景需求。如果是關鍵資訊（報警指令），我們需要發送方重發，如果是非關鍵資訊（高頻傳感資料），系統就不必把丢失的部分都找回來，這些都隻需配置QoS的reliability就可以了。

（3）在感覺系統有備援的情況下，一旦一個傳感器當機，就需要第二個傳感器補上來。針對這種情況，QoS可以配置一個ownership，對兩個傳感器的資料做優先級高低的區分。配置之後也不需要重新編譯，因為它是動态部署的，配置完之後就可以按照最新配置運作，去完成不同節點之間的釋出訂閱。

（4）.DDS的解耦模式允許某一主題釋出方在沒有訂閱方的情況下仍然釋出資料，但後加入的訂閱方也許對這一主題的曆史記錄感興趣。例如，新節點上線後需要去監控其他節點的運作情況，這些節點也許每隔較長一段時間才釋出一個資訊說自己“運作正常”，那麼這個新上線的節點就需要去了解其他節點釋出的曆史資訊以确定其運作狀态，也就是它希望能收到其上線之前其他節點釋出的曆史資料。這種情況，隻需要簡單配置QoS就可以實作，新節點可以獲知上線之前多長時間、多長節點的資料流，去關注它的曆史資料等等。

（5）負責監控的新節點上線後，需要去監控其他節點的運作情況。通常，這些節點每個小時釋出一個資訊說自己“運作正常”，但也有可能這個“運作正常”的節點先釋出了，過半小時之後監控節點才釋出，那這時候，監控節點是否還能收到其上線之前其他節點釋出的資料？這種情況，也是需要通過QoS去配置的，QoS可以去配置訂閱新節點上線之前多長時間、多長節點的資料流，去關注它的曆史資料等等。

進一步說，QoS能夠提供實時系統所要求的性能、可預測性和資源可控性，并且能夠保證釋出/訂閱模型的子產品性、可量測性和魯棒性等。是以，DDS能夠滿足非常複雜、非常靈活的資料流要求。

相比之下，SOME/IP隻解決了釋出訂閱問題，但由于沒有這些QoS，結果便是，很多本來可用自動配置服務政策來實作的功能，都需要通過軟體開發人員寫代碼才能實作，這會浪費大量的時間。

此外，由于沒有QoS，SOME/IP在資料量大的時候，無法解決丢包的問題，進而造成指令被卡在某個地方發不出去，然後，整個系統就無法正常運作了。

05

從應用場景的角度來看，SOME/IP比較偏向于車載網絡，且隻能在基于網絡層為IP類型的網絡環境中使用，而DDS在傳輸方式上沒有特别的限制，對基于非IP類型的網絡，如共享記憶體、跨核通訊、PCI-e等網絡類型都可以支援。而且，DDS也有完備性的車聯網解決方案，其獨有的DDS Security，DDS Web功能可為使用者提供車-雲-移動端一站式的解決方案。

在商業落地中，DDS和SOME/IP是直接競争關系。據一位RIT方面的代表透露,對使用者而言，DDS和SOME/IP是“二選一”。

但畢曉鵬及東軟睿馳營銷總經理茅海燕、均聯智行首席架構師汪浩偉等均認為，DDS和SOME/IP盡管有很強的競争關系，但也是可以共存的。

畢曉鵬說，有的OEM既用了DDS，也用了SOME/IP，隻是使用的場景不一樣——有時候是在一個核上的程序之間進行通信，有時候是核與核之間進行通信，有的時候是域控制器和其他的車載娛樂系統進行通信等等。“現在确實并不是非要‘二選一’，針對有的場景選擇DDS，針對另一些場景選擇SOME/IP，也是可以的。”

茅海燕說，AP AUTOSAR中，CM提供的一些标準架構可同時相容DDS和SOME/IP。 “SOME/IP和DDS我們都用過。總體而言，SOME/IP強調通信，體量比較小；DDS功能更多，但體量比較大，需要裁剪後才能用于自動駕駛。”

汪浩偉指出，DDS适用于自動駕駛域，而SOME/IP則可以延伸到整車域。

Vector産品專家蔡守群說：“在我們接觸過的一些項目上，DDS和SOME/IP都有用到。”蔡守群甚至認為，DDS跟SOME/IP不是競争關系，存在即合理，使用者可以按需選擇。

那麼，在實踐中，誰的市場占有率更高？

畢曉鵬說：“由于SOME/IP本身就是為汽車行業制定的通信标準，是以，SOME/IP在之前的使用率會稍微高一些，DDS也是近兩年才慢慢被多家的造車新勢力和OEM所采納。但從趨勢來看，未來，DDS的市場占有率是要大于SOME/IP的。”

當然，“DDS優于SOME/IP”主要是DDS廠商的說法，為避免本文觀點被廠商們的立場左右，筆者又帶着這些質疑向Vector蔡守群求證。對此，蔡守群的解答如下——

“現在很多人說DDS優于SOME/IP，很大程度上是從功能豐富性的角度去考慮的。确實，DDS包含的功能是多于SOME/IP的，但僅僅因為這個原因就說DDS優于SOME/IP是不合适的。這就如同拿一部車去跟一個發動機進行對比一樣：

SOME/IP是AUTOSAR CP的産物， AUTOSAR的設計原則就是将功能子產品化，通過提高子產品顆粒度的方式來實作子產品的高度可複用性；然後再通過不斷複用、不斷測試的方式來提高子產品的品質，是以，SOME/IP産生之初就沒考慮要不斷增加功能。比如，跟SOME/IP結合使用的SD就是一個單獨的子產品。

相比之下，DDS額外提供的QoS，在AUTOSAR CP中是基于VLAN實作在以太網控制器驅動中的；資料則儲存在AUTOSAR中有單獨的存儲管理子產品；Security在AUTOSAR中也有對應的通信安全和加密管理子產品。

“DDS廠商們認為，相比于SOME/IP，DDS除了提供了一個通信協定之外，還有其他可用的功能。但實際上，這些功能無論在CP還是在AP中，是有其他功能子產品進行補充的，可以基于系統需求進行選擇部署的，SOME/IP也隻是CP/AP中一部分。

“另一方面，DDS豐富的功能必然導緻它需要占用更多的資源。在車載MCU領域，資源是一個非常敏感的話題，要在MCU（包括SoC晶片的實時性核心）中運作DDS，隻能人為地進行項目級功能裁剪，很難做到跨項目、跨平台的複用，因而很難做到成熟的産品化；并且，開發階段的工程化裁剪以及後續的測試都會大幅度增加項目成本。

“當然，這也隻是我個人看到的目前狀況，不知道商業版的DDS是否已經在考慮進行DDS内部的功能子產品化、工具可配置化，以彌補這方面的不足。（九章智駕在向RTI代理商創景科技方面求證後得到的回報是：從我們目前已量産應用的項目來看，有多位客戶在多代含MCU的産品中都部署了DDS，DDS在複用性方面并未出現“不成熟”的問題。）

“此外，DDS還有一個問題就是目前還無法完美接入進現有的車載電子電氣設計、開發、測試工具鍊中。雖然說我們已經着手在設計（PREEvision）、測試（CANoe）中去支援DDS，但這方面的工作也才剛剛開始，雙方的工具都需要不斷測試磨合，短期内是做不到無縫相容的。

“從協定上看，DDS是一套面向資料的通路系統，适合多節點、大資料互動的應用場景；SOME/IP是一套面向服務的通路系統，可以很友善地用于RPC（遠端過程調用）以及變更通知。對于資料吞吐量，從有效資料的占比來看，DDS和SOME/IP的性能沒有明顯的差别。

“是以，我一直認為DDS和SOME/IP是會并存于車載通信中的，APP可以基于應用場景選擇合适的通信通道。這也是為什麼在AUTOSAR AP中是既支援DDS又支援SOME/IP的。

“我們也知道，目前确實有一些OEM在考慮用DDS充當唯一的主幹網（中央計算平台+方位域控制器）通信協定，但是從成熟度、資源占用（主幹網上肯定有基于MCU的節點）以及工具鍊的角度來看，我們認為還是有待商榷的。”

參考資料：

自動駕駛通信中間件

一網打盡車載以太網之SOME/IP(上)

一網打盡車載以太網之SOME/IP(下)

中間件 DDS(資料分發服務-Data Distribution Service）

https://zhuanlan.zhihu.com/p/428892842

對話華玉通軟畢曉鵬：智能駕駛國産路，有人逢山開路，有人遇水疊橋 | 華玉Wiki

一文讀懂自動駕駛的“中間件”

https://zhuanlan.zhihu.com/p/372712318

RTI DDS介紹

寫在最後

與作者交流

如果希望與文章作者直接交流，可以直接掃描右方二維碼，添加作者本人微信。

注：加微信時務必備注您的真實姓名、公司、崗位

等資訊，謝謝！

作業系統交流群

作業系統相關領域專業人士，若想加群交流，可掃描右方二維碼添加從業人員微信，并提供一下名片，然後拉您入群。

等資訊，謝謝

關于投稿

如果您有興趣給《九章智駕》投稿（“知識積累整理”類型文章），請掃描右方二維碼，添加從業人員微信。

以及投稿意向等資訊，謝謝！

“知識積累”類稿件品質要求：

A：資訊密度高于絕大多數券商的絕大多數報告，不低于《九章智駕》的平均水準；

B：資訊要高度稀缺，需要80%以上的資訊是在其他媒體上看不到的，如果基于公開資訊，需要有特别牛逼的獨家觀點才行。多謝了解與支援。