4.5萬
本文是自動駕駛中間件科普系列第二篇，上一篇為? 自動駕駛中間件之一：AUTOSAR正在被“邊緣化”？
隨著傳感器的數量越來越多，數據來源越來越多、規(guī)模也會越來越大，那這些多源異構數據如何在芯片之間、在各任務進程之間高效、穩(wěn)定地傳遞，確?！霸谡_的時間，傳遞正確的數據，并確保數據抵達正確的地點”呢？
會有哪些信息在模塊之間共享？如何將這些信息發(fā)送編碼到消息中？如何將消息從一個模塊傳遞到另一個模塊？如何在接收到消息后解碼？各個模塊間的通信分別花了多長時間？
在OTA的時候，進程如何不被打斷？
這些問題，都需要通過“通信中間件”來解決。在自動駕駛領域，中間件的功能涉及到通信、模塊升級、任務調度、執(zhí)行管理，但其最主要的功能還是通信。當前市場上，無論是Cyber RT還是 ROS，基本上90%的功能就是通信，狹義上說它們就是通信中間件（又被稱為“消息中間件”）。
那么，好的通信中間件應當具備哪些特征？通信中間件可分為哪些類型？常見的SOME/IP和DDS的優(yōu)劣勢各是什么？市場格局將會如何演變？接下來，我們將對這些內容做個簡單的梳理。
一．自動駕駛需要怎樣的通信中間件？
傳統(tǒng)的網絡通信中，在TCP協議下，信息發(fā)出后，接收方需要發(fā)出一個信號，告訴發(fā)送方“我收到了” ，如果沒收到這個信號，那下一條信息就不能發(fā)出；在UDP傳輸方式下，不管接收方有沒有收到，發(fā)送方都會一直發(fā)。
以往，在沒有用通信中間件的時候，為了開發(fā)上層應用，開發(fā)者們需要自己去定義數據的格式、定義數據的發(fā)送方和接收方；但有了SOME/IP和DDS這種“以服務/數據為中心”的發(fā)布和訂閱模式，開發(fā)者們只需明確我需要什么樣的數據、數據傳到哪兒，而無需知道數據是由誰發(fā)出的、怎樣發(fā)出的。
以數據為中心，是相對于傳統(tǒng)的“以消息為中心”而言的，其本質區(qū)別在于通信中間件知道它存儲了什么數據、并能控制如何共享這些數據。
對傳統(tǒng)的以消息為中心的中間件，程序員必須為發(fā)送消息編寫代碼，而對以數據為中心的中間件，程序員只需為如何及何時共享數據編寫代碼，然后就可以直接共享數據值。
通信中間件包括點到點、消息隊列和發(fā)布/訂閱三種工作模式，SOME/IP和DDS都采用了發(fā)布/訂閱模式。
點到點模式具有很強的時間和空間耦合性，使得通信靈活性受到很大限制；消息隊列模式通過一個消息隊列來傳遞消息，解決了通信雙方時間和空間松耦合的問題，但不能實現消息消費者通信的異步，并且還存在服務器瓶頸和單點失效的問題，可靠性得不到保障；發(fā)布/訂閱模型中，發(fā)布者和訂閱者通過主題相關聯，雙方不必知道對方在何處，也不必同時在線，實現了通信雙方在時間、空間和數據通信上的多維松耦合。
此外，相比于面向信號的CAN，DDS和SOME/IP都是面向服務的通信協議。兩者的區(qū)別在于：面向信號的數據傳輸，不管網絡需不需要，它始終會不斷循環(huán)發(fā)送；而面向服務的通信方式則不同，僅當客戶端請求或服務器通知特定訂閱者時，才在客戶端-服務器配置中交換數據，這就確保了永遠不會浪費帶寬，并且僅在需要的時間和地點進行數據通信/交換。
因此，面向服務的通信協議，能夠大大減少網絡負載，提高通信效率。
上汽工程師殷瑋在一篇文章中說，通信中間件的引入整體上可以幫助開發(fā)人員提高工作效率。
SOME/IP和DDS均已被納入AUTOSAR AP的平臺標準中。
創(chuàng)景信息科技公司在官方微信公眾號上的一篇文章中說道：“撇開商業(yè)利益不談，從工程角度來看，將AUTOSAR和DDS結合起來的最大優(yōu)勢是功能域和網絡拓撲不再是對手，而是車輛中的盟友。網絡拓撲結構能夠更好地適應車輛的物理約束，而功能域可以在物理車輛的頂部提供了一個靈活的覆蓋層?！?/p>
通信中間件應該包括以下幾個模塊:數據類型規(guī)范語言、消息傳遞系統(tǒng)、日志/回放工具和實時分析工具。這些模塊應具有如下特征：1.數據類型規(guī)范語言應獨立于平臺和具體的編程語言，以消除用戶實現編組（Marshalling）代碼的需要，同時保證運行時類型的安全性；2.消息傳遞系統(tǒng)需要在不同的進程之間傳輸消息，并提供低延時的消息傳遞功能，且消除對中央通信的依賴，從而使混合模擬、記錄和實時數據源的工作更容易；3.需要提供大量的日志記錄、回放和流量檢查工具，以簡化常見的開發(fā)和調試任務。
衡量一款通信中間件好壞的標準主要有如下幾點：1.接口是否方便？接口方便是很多人喜歡用ros的原因。2.是否安全、穩(wěn)定？安全，即通信的過程中不能出現數據丟失的問題；穩(wěn)定，比如，發(fā)布訂閱的進程連續(xù)開幾天幾夜也不能宕機。3.傳輸可支持多少節(jié)點、跨多少內核？4.在不同通信場景和通信需求下，是否可以進行靈活快速的配置？5.吞吐量、時延。發(fā)送同樣大小的數據包，吞吐量是否更高，延遲是不是比用別的方法更低？
吞吐量，即單位時間內通過的數據量有多少；時延，即數據包傳輸的延遲性有多少。如果通信速度很慢，感知到的信息要經過200毫秒才能傳遞到執(zhí)行系統(tǒng)，那感知做得再好也無濟于事。
車速越高、數據量越大的場景，對中間件的數據吞吐能力和時延的要求就越高。某通信中間件廠商反應，他們的產品在乘用車市場上賣得特別好，但在商用車市場上反響就不行，一個原因就是商用車的駕駛場景簡單，對中間件數據吞吐能力、時延的要求比較低。
二．常見的通信中間件
根據源代碼是否開放，通信中間件可簡單地分為閉源和開源兩種。閉源的通信中間件主要有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年開發(fā)，并在2014年集成進AUTOSAR 4.2.1中。
當前，全球最大的商用SOME/IP產品供應商是Vector。?開源版的SOME/IP則是由Genivi協會來維護的。
02、DDS（Data Distribution Service）
提起DDS，就不得不提OMG組織。OMG是一個國際化的、開放的、非盈利的計算機行業(yè)標準協會，很多大家熟悉的標準(如uml)，都出自于OMG。DDS也是OMG組織推出的標準之一。
（圖片來自創(chuàng)景信息科技公司）
DDS的全稱為Data Distribution Service（數據分發(fā)服務)，是由OMG發(fā)布的分布式通信規(guī)范，采用發(fā)布/訂閱模型，提供多種QoS服務質量策略，以保障數據實時、高效、靈活地分發(fā)，可滿足各種分布式實時通信的應用需求。
DDS將分布式網絡中傳輸的數據定義為“主題”，將數據的產生和接收對象分別定義為“發(fā)布者”和“訂閱者”，從而構成數據的發(fā)布/訂閱傳輸模型。各個節(jié)點在邏輯上無主從關系，點與點之間都是對等關系，通信方式可以是點對點、點對多、多對多等，在QoS的控制下建立連接，自動發(fā)現和配置網絡參數。
DDS最早應用于美國海軍，用于解決艦船復雜網絡環(huán)境中大量軟件升級的兼容性問題，后來擴展至航空、航天、船舶、國防、金融、通信、汽車等領域，包括作戰(zhàn)系統(tǒng)、船舶導航和控制系統(tǒng)、船舶防御系統(tǒng)、無人機駕駛系統(tǒng)和地面控制系統(tǒng)、裝甲車輛控制系統(tǒng)、仿真和培訓系統(tǒng)、雷達處理和空中交通管理系統(tǒng)、金融系統(tǒng)等。
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的標準規(guī)范中是不支持DDS的，但做一些變通后，也可以在CP上集成DDS。
全球范圍內，DDS市場份額最大的供應商（80%左右）的是成立于1991年的美國RTI公司（全稱為Real-Time Innovations）。RTI作為OMG組織董事會的成員，主導了DDS標準的制定，從2004年開始負責主持DDS工作組的工作，目前已經成為這個行業(yè)的領導者，對DDS標準有足夠的權威。
RTI開發(fā)的DDS品牌名為Connext,，因此又被稱為Connext DDS。
03、開源DDS：FAST DDS與OPEN DDS
開源DDS，主要是相對于商用的RTI Connext DDS等而言的，其也是根據OMG官方標準開發(fā)的，但源代碼開放。
在自動駕駛領域比較有影響力的開源DDS是由RTI原核心團隊成員在歐洲創(chuàng)辦的eProsima公司推出的FastDDS。在eProsima將FastDDS的源代碼開放出來后，用戶可以直接在github上免費下載。但FastDDS使用起來比較麻煩，這個時候，用戶就需要通過向eProsima支付費用來取得支持。
OpenDDS 由位于圣路易斯和鳳凰城的的Object Computing的 ACE/TAO 團隊開發(fā)，它和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還沒有。
而據華玉通軟聯合創(chuàng)始人畢曉鵬的解釋，基于開源版本DDS研發(fā)的通信中間件存在“穩(wěn)定性不足”的問題。
04、MQTT（開源）
MQTT是由IBM開發(fā)的即時通訊協議，其全稱是Message Queuing Telemetry Transport （消息隊列遙測傳輸）。
MQTT協議也采用發(fā)布/訂閱模式，所有的物聯網終端都通過TCP連接到云端，云端通過主題的方式管理各個設備關注的通訊內容，負責將設備與設備之間消息的轉發(fā)。
由于延時控制等方面功能較差、服務策略也比較少，MQTT不適用于高速項目和大型項目，但可用于低帶寬、不可靠的網絡場景，提供基于云平臺的遠程設備的數據傳輸和監(jiān)控。在自動駕駛領域，MQTT比較典型的應用場景是V2X。
此外，MQTT在低速車領域也同樣適用。它體積極小，并能提供簡單的QoS保證，非常適合玩具車，掃地車等功能簡單、硬件資源有限的項目。
MQTT也是開源的通信中間件。
三．SOME/IP?& DDS
現階段，SOME/IP和DDS是自動駕駛上用得最多的兩類通信中間件。上文已經提到，兩者的共同點主要有：都是面向服務的通信協議；都采用了“以數據為中心”的發(fā)布和訂閱模式。那么，兩者的主要區(qū)別又有哪些呢？
01、應用場景不同
SOME/IP是專為汽車領域而生的，它針對汽車領域的需求，定義了一套通信標準，并且，在汽車領域深耕的時間比較長；DDS是一個工業(yè)級別的強實時的通信標準，它對場景的適應性比較強，但在用于汽車/自動駕駛領域時需要做專門的裁剪。
02、靈活性、可伸縮性不同
相較于SOME/IP，DDS引入了大量的標準內置特性，例如基于內容和時間的過濾、與傳輸無關的可靠性、持久性、存活性、延遲/截至時間監(jiān)視、可擴展類型等。當AUTOSAR AP與DDS一起構建一個通信框架時，該框架不僅可以與現有ara::com api及應用程序兼容，而且在可靠性、性能、靈活性和可伸縮性等方面，都可以提供重要的好處。
03、訂閱方和發(fā)布方是否強耦合
在SOME/IP中，在正常數據傳輸前，client需要與server建立網絡連接并詢問server是否提供所需服務，在這個層面上，節(jié)點間仍然具有一定耦合性。服務的訂閱方需要知道server在哪里，服務的發(fā)布方需要告知server提供哪種服務，例如寫一個程序，需要用到傳感器數據，這個程序要去詢問server是否可以提供傳感器數據；而在DDS標準下，每個訂閱方或發(fā)布方只需要在自己的程序里面訂閱或發(fā)布傳感器數據就行了，不需要關心任何連接。可以理解為，在DDS中，服務訂閱方和發(fā)布方的解耦更加徹底，需要什么數據，寫一行代碼就行了，不需要再去做綁定。
04、服務策略不同
較好的QoS（服務策略）是DDS標準相比于SOME/IP最重要的特征。
SOME/IP只有一個QoS，即可靠性的定義；而RTI DDS和開源DDS里面分別有50多個和20多個QoS，這些QoS基本上能涵蓋絕大多數可以預見到的智能駕駛場景。
QoS具體是個什么東西，它有何用途？華玉通軟聯合創(chuàng)始人兼技術副總裁畢曉鵬舉了幾個例子：
（1）通信中的傳輸優(yōu)先級、數據可靠性、資源限制、時間過濾等，都需要在QoS里面設置。
（2）數據傳輸過程中可能會出現丟幀現象，也就是說，不是每一幀都能達到接收端。針對這種現象，我們需要考慮場景需求。如果是關鍵信息（報警指令），我們需要發(fā)送方重發(fā)，如果是非關鍵信息（高頻傳感數據），系統(tǒng)就不必把丟失的部分都找回來，這些都只需配置QoS的reliability就可以了。
（3）在感知系統(tǒng)有冗余的情況下，一旦一個傳感器宕機，就需要第二個傳感器補上來。針對這種情況，QoS可以配置一個ownership，對兩個傳感器的數據做優(yōu)先級高低的區(qū)分。配置之后也不需要重新編譯，因為它是動態(tài)部署的，配置完之后就可以按照最新配置運行，去完成不同節(jié)點之間的發(fā)布訂閱。
（4）.DDS的解耦模式允許某一主題發(fā)布方在沒有訂閱方的情況下仍然發(fā)布數據，但后加入的訂閱方也許對這一主題的歷史記錄感興趣。例如，新節(jié)點上線后需要去監(jiān)控其他節(jié)點的運行情況，這些節(jié)點也許每隔較長一段時間才發(fā)布一個信息說自己“運行正?！保敲催@個新上線的節(jié)點就需要去了解其他節(jié)點發(fā)布的歷史信息以確定其運行狀態(tài)，也就是它希望能收到其上線之前其他節(jié)點發(fā)布的歷史數據。這種情況，只需要簡單配置QoS就可以實現，新節(jié)點可以獲知上線之前多長時間、多長節(jié)點的數據流，去關注它的歷史數據等等。
（5）負責監(jiān)控的新節(jié)點上線后，需要去監(jiān)控其他節(jié)點的運行情況。通常，這些節(jié)點每個小時發(fā)布一個信息說自己“運行正?！保灿锌赡苓@個“運行正?！钡墓?jié)點先發(fā)布了，過半小時之后監(jiān)控節(jié)點才發(fā)布，那這時候，監(jiān)控節(jié)點是否還能收到其上線之前其他節(jié)點發(fā)布的數據？這種情況，也是需要通過QoS去配置的，QoS可以去配置訂閱新節(jié)點上線之前多長時間、多長節(jié)點的數據流，去關注它的歷史數據等等。
進一步說，QoS能夠提供實時系統(tǒng)所要求的性能、可預測性和資源可控性，并且能夠保證發(fā)布/訂閱模型的模塊性、可量測性和魯棒性等。因此，DDS能夠滿足非常復雜、非常靈活的數據流要求。
相比之下，SOME/IP只解決了發(fā)布訂閱問題，但由于沒有這些QoS，結果便是，很多本來可用自動配置服務策略來實現的功能，都需要通過軟件開發(fā)人員寫代碼才能實現，這會浪費大量的時間。
此外，由于沒有QoS，SOME/IP在數據量大的時候，無法解決丟包的問題，進而造成指令被卡在某個地方發(fā)不出去，然后，整個系統(tǒng)就無法正常運作了。
05應用場景不同
從應用場景的角度來看，SOME/IP比較偏向于車載網絡，且只能在基于網絡層為IP類型的網絡環(huán)境中使用，而DDS在傳輸方式上沒有特別的限制，對基于非IP類型的網絡，如共享內存、跨核通訊、PCI-e等網絡類型都可以支持。而且，DDS也有完備性的車聯網解決方案，其獨有的DDS Security，DDS Web功能可為用戶提供車-云-移動端一站式的解決方案。
在商業(yè)落地中，DDS和SOME/IP是直接競爭關系。據一位RIT方面的代表透露,對用戶而言，DDS和SOME/IP是“二選一”。但畢曉鵬及東軟睿馳營銷總經理茅海燕、均聯智行首席架構師汪浩偉等均認為，DDS和SOME/IP盡管有很強的競爭關系，但也是可以共存的。
畢曉鵬說，有的OEM既用了DDS，也用了SOME/IP，只是使用的場景不一樣——有時候是在一個核上的進程之間進行通信，有時候是核與核之間進行通信，有的時候是域控制器和其他的車載娛樂系統(tǒng)進行通信等等。“現在確實并不是非要‘二選一’，針對有的場景選擇DDS，針對另一些場景選擇SOME/IP，也是可以的。”
茅海燕說，AP AUTOSAR中，CM提供的一些標準框架可同時兼容DDS和SOME/IP。?“SOME/IP和DDS我們都用過?？傮w而言，SOME/IP強調通信，體量比較小；DDS功能更多，但體量比較大，需要裁剪后才能用于自動駕駛?！?/p>
汪浩偉指出，DDS適用于自動駕駛域，而SOME/IP則可以延伸到整車域。
Vector產品專家蔡守群說：“在我們接觸過的一些項目上，DDS和SOME/IP都有用到?！辈淌厝荷踔琳J為，DDS跟SOME/IP不是競爭關系，存在即合理，用戶可以按需選擇。
那么，在實踐中，誰的市場占有率更高？
畢曉鵬說：“由于SOME/IP本身就是為汽車行業(yè)制定的通信標準，因此，SOME/IP在之前的使用率會稍微高一些，DDS也是近兩年才慢慢被多家的造車新勢力和OEM所采納。但從趨勢來看，未來，DDS的市場占有率是要大于SOME/IP的。”
當然，“DDS優(yōu)于SOME/IP”主要是DDS廠商的說法，為避免本文觀點被廠商們的立場左右，筆者又帶著這些質疑向Vector蔡守群求證。對此，蔡守群的解答如下——
“現在很多人說DDS優(yōu)于SOME/IP，很大程度上是從功能豐富性的角度去考慮的。確實，DDS包含的功能是多于SOME/IP的，但僅僅因為這個原因就說DDS優(yōu)于SOME/IP是不合適的。這就如同拿一部車去跟一個發(fā)動機進行對比一樣：
SOME/IP是AUTOSAR CP的產物， AUTOSAR的設計原則就是將功能模塊化，通過提高模塊顆粒度的方式來實現模塊的高度可復用性；然后再通過不斷復用、不斷測試的方式來提高模塊的質量，因此，SOME/IP產生之初就沒考慮要不斷增加功能。比如，跟SOME/IP結合使用的SD就是一個單獨的模塊。
相比之下，DDS額外提供的QoS，在AUTOSAR CP中是基于VLAN實現在以太網控制器驅動中的；數據則保存在AUTOSAR中有單獨的存儲管理模塊；Security在AUTOSAR中也有對應的通信安全和加密管理模塊。
“DDS廠商們認為，相比于SOME/IP，DDS除了提供了一個通信協議之外，還有其他可用的功能。但實際上，這些功能無論在CP還是在AP中，是有其他功能模塊進行補充的，可以基于系統(tǒng)需求進行選擇部署的，SOME/IP也只是CP/AP中一部分。
“另一方面，DDS豐富的功能必然導致它需要占用更多的資源。在車載MCU領域，資源是一個非常敏感的話題，要在MCU（包括SoC芯片的實時性內核）中運行DDS，只能人為地進行項目級功能裁剪，很難做到跨項目、跨平臺的復用，因而很難做到成熟的產品化；并且，開發(fā)階段的工程化裁剪以及后續(xù)的測試都會大幅度增加項目成本。
“當然，這也只是我個人看到的當前狀況，不知道商業(yè)版的DDS是否已經在考慮進行DDS內部的功能模塊化、工具可配置化，以彌補這方面的不足。（九章智駕在向RTI代理商創(chuàng)景科技方面求證后得到的反饋是：從我們目前已量產應用的項目來看，有多位客戶在多代含MCU的產品中都部署了DDS，DDS在復用性方面并未出現“不成熟”的問題。）
“此外，DDS還有一個問題就是當前還無法完美接入進現有的車載電子電氣設計、開發(fā)、測試工具鏈中。雖然說我們已經著手在設計（PREEvision）、測試（CANoe）中去支持DDS，但這方面的工作也才剛剛開始，雙方的工具都需要不斷測試磨合，短期內是做不到無縫兼容的。
“從協議上看，DDS是一套面向數據的訪問系統(tǒng)，適合多節(jié)點、大數據交互的應用場景；SOME/IP是一套面向服務的訪問系統(tǒng)，可以很方便地用于RPC（遠程過程調用）以及變更通知。對于數據吞吐量，從有效數據的占比來看，DDS和SOME/IP的性能沒有明顯的差別。
“所以，我一直認為DDS和SOME/IP是會并存于車載通信中的，APP可以基于應用場景選擇合適的通信通道。這也是為什么在AUTOSAR AP中是既支持DDS又支持SOME/IP的。
“我們也知道，目前確實有一些OEM在考慮用DDS充當唯一的主干網（中央計算平臺+方位域控制器）通信協議，但是從成熟度、資源占用（主干網上肯定有基于MCU的節(jié)點）以及工具鏈的角度來看，我們認為還是有待商榷的?！?/p>
參考資料：
自動駕駛通信中間件https://blog.csdn.net/qq_23981335/article/details/106563676
一網打盡車載以太網之SOME/IP(上)https://mp.weixin.qq.com/s/kDDIvnijKo2tn07t20M4Cg
一網打盡車載以太網之SOME/IP(下)https://mp.weixin.qq.com/s/iMi1TVhhUK1xZbuOlSZUZw
中間件 DDS(數據分發(fā)服務-Data Distribution Service）https://zhuanlan.zhihu.com/p/428892842
對話華玉通軟畢曉鵬：智能駕駛國產路，有人逢山開路，有人遇水疊橋 | 華玉Wikihttps://mp.weixin.qq.com/s/IVZtiOwUOwqdiIv2_OztyA
一文讀懂自動駕駛的“中間件”https://zhuanlan.zhihu.com/p/372712318
RTI DDS介紹 https://blog.csdn.net/liulihuo_gyh/article/details/79704062
