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