汽車電子電氣架構車控軟件系統詳解

0 序言

汽車EEA架構演變中一個明顯的特點是軟硬解耦，OEM將大部分ECU的控制邏輯集中到區域控制器中。區域控制器將數據上傳到中央控制器，中央控制器進行運算處理，并將結果或者決策下發到區域控制器去執行。Tier1逐步成為硬件供應商，只需要按照特定功能和接口提供執行器即可。當需要更換另一家Tier1的ECU時，區域控制器的控制邏輯甚至不需要做更改，或者只需要做簡單的修改。這應該就是所謂的“軟硬解耦”。

人類工業史到處都有解耦這個概念，比如我總能想到初中歷史課上有講到美國工業發展的那段，福特搞起了第一條汽車生產線。流水線本身就是將整個制造流程分割成若干個互相解耦的工位，每個工位SOP中的多個動作可能會調整，但不會影響到其他工位的操作。下一個工位的工人，只需要無腦將上一個工位生產的零部件拿來用就好了。另外，在總線協議中，OSI七層模型，也充分發揚了解耦的這一理念。每一層的技術迭代，不會或者很少影響其他層。比如從傳統以太網發展到車載以太網，物理層和數據鏈路層的技術有一些改變，但并不影響在車載以太網上應用TCP、UDP和IP等協議，這些是網絡層和傳輸層的協議。

以上是從硬件工程師的角度來理解解耦，硬件工程師長期接觸的是這些直觀的物理事物，比較容易理解。硬件上講究解耦，軟件上當然也要解耦。讀研時，寫過單片機的裸機代碼，剛開始不太懂，吃了很多虧。比如我要控一個燈，燈的亮度與PWM的占空比有關，我在主程序里定義PWM=50，但主程序里可能會出現多個PWM=50的這一條代碼。當我要改PWM占空比的時候，需要將多條代碼都修改才行。如果在頭文件里，用宏定義就可以只改一條代碼，且代碼的可讀性也大大增加。用宏定義只是最初級的解耦方式，在一個復雜的軟件系統里，會有多種維度上的解耦。工程師們將系統抽象出好多個層，不同的工程師負責不同層的軟件開發。一來，在開發階段，大家可以獨立開發；二來，在做迭代的時候，不同層的工程師也可以獨立快速的搞完自己的業務，而不必過多的依賴其他工程師的支持。

上一篇文章學習了EEA架構的演變，EEA架構是軟件架構得以實現的基礎，而好的軟件架構又能夠充分發揮EEA架構的能力。本文試圖從軟件的門口路過，朝里面看一眼，大致理解一下軟件工程師們在做哪些事情。

1 軟件架構風格

軟件工程師將軟件代碼抽象出若干個層，再怎么抽象上層軟件，最終都會通過編譯器“翻譯”成多個機器碼。這些機器碼是由底層半導體廠商定義的，比如高通的芯片用的是ARM的架構，那就遵循ARM的指令集。指令集即上述機器碼的集合，定義了哪些機器碼對應了哪些功能。具體的功能則由微架構實現，微架構可以理解為固化在處理器中的最底層的電路，這些在之前的文章中都有談到。因此，從硬件工程師的角度來看軟件，可以從下往上看，心里有底，畢竟參天大樹是從硬件的土壤里生長起來的，這是軟硬件的聯結處。

硬件工程師將底層的硬件地基夯實好，軟件工程師便在其上一層層壘磚頭。一個簡單的軟件建筑沒有什么規則，講究一個快速實現功能就好。但如果要建一個軟件摩天大樓，規矩就多了，比如如何使得系統更容易測試，更容易迭代等等。軟件架構的設計可以遵循不同的風格（或者說是規矩），這些風格本質上是定義了用于描述系統的術語表和一組指導構建系統的規則。在初識“汽車軟件”這座建筑之前，可以先看看軟件架構有哪些風格。

軟件工程師根據項目的特點和需要選擇特定的軟件架構風格,這和不同地方根據當地氣候和民族特色選擇不同的建筑風格其實差不多。至于如何從哪些維度去評判軟件架構的好壞，可以查看《自動駕駛軟件架構之中間件與SOA介紹》這篇文章，里面有提到一些軟件架構的評估方法。

1.1分層架構

分層架構是最常見的軟件架構，這種架構將軟件分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節，層與層之間通過接口通信。在這種架構中，函數調用的方向是固定的，僅能從較高層級向較低層級調用。

分層架構具有以下優點：結構簡單，容易理解和開發；不同技能的程序員可以負責不同的層，天然適合大多數軟件公司的組織架構；每一層可以獨立測試，其他層的接口通過模擬解決。

分層架構的缺點是：擴展性差，上下層還是存在一些耦合，有些功能的變化，可能涉及多層的修改；業務流需要經過多層代碼的處理，性能會有所降低；分層結構中，只能由上層組件調用下層組件，同一個層級中的組件之間無法相互通信，導致軟件架構不太靈活。

1.2基于組件的架構

基于組件的架構，比分層架構更加靈活，所有組件都可以進行消息交互或者相互獨立。所有的通信都應該經過規范定義的公共接口進行，并且每個組件都具備單一的接口，以便通過接口實現對組件的查詢。Windows系統就是典型的基于組件的架構，其大量使用了動態鏈接庫和IUnKnown接口。

需要說明的是，基于組件的架構并不是完全替代分層架構，架構可以分為多個層次。在大的維度上，軟件架構可以使用分層架構。比如系統可以分為平臺層和應用層，這是分層架構的概念。但是在應用層內，多個應用之間可以采用基于組件的架構，多個APP可以互相調用。

1.3單體架構

與基于組件的架構相反，其假定整個系統是一個大型組件，系統中的所有模塊都可以相互使用。這種風格通常用于低成熟度的系統，因為它會導致系統的高耦合和高復雜度。當有人質疑你的代碼沒有分層，沒有架構設計，你就可以試著申辯說這是專門設計的單體架構（說點專業的，?；Ｈ耍?。

單體架構通常被用來實現安全關鍵系統中的部分功能，這類系統的內部組件間必須實時通信，并且通信開銷盡可能小。單體架構采用的典型機制是編程語言中的安全機制，例如使用靜態變量，沒有內存管理，不使用動態結構等。

1.4微內核架構

微內核架構又稱插件架構，指的是軟件的內核相對較小，主要功能和業務邏輯通過插件實現，許多現代操作系統都采用這種架構。這種架構可以被看作分層架構中的一種雙層架構的特例。

內核包含系統運行的最小功能，是具有更高執行權限的有限組件的集合，如任務調度程序、內存管理和基礎進程間通管理，這些組件相較于應用層的組件而言擁有更高級別的權限。應用程序則是相互獨立的，它們之間的通信應該減至最少，避免出現互相依賴的問題。例如，用戶應用程序進程、設備驅動程序或文件服務的組件，這些組件可以具備不同的權限級別，但是其權限級別要始終低于內核進程。

在汽車行業中，微內核架構被用于某些要求高安全性的組件。微內核架構具有以下優點：具有良好的功能延申性；功能之間相互隔離，應用程序可以獨立加載和卸載，容易部署；可定制性高，能適應不同的開發需要；可以漸進式開發，逐步增加功能。

微內核架構的缺點主要有：擴展性差，內核通常是一個獨立單元，不容易做成分布式；因為涉及應用程序與內核的通信，以及內部的應用程序登記機制，開發難度較大。

1.5管道與過濾器架構

管道與過濾器架構適用于基于數據處理而運行的系統，這種架構假定組件沿著數據處理流的方向進行連接，在現代汽車軟件中，這種架構在主動安全域的圖像識別功能中十分常見，這一功能需要在多個階段處理大量的視頻數據，且組件之間必須相互獨立。如果去看Camera的相關介紹，經常會看到pipeline這樣的說法，可能就是因為Camera的處理是流式的，按照一定的順序獲取和處理數據。

管道域過濾器架構由兩大組件構成，一個為過濾器，另一個為管道。過濾器的主要功能為從輸入接口讀取數據，然后經過特定的處理，將結果數據置于輸出接口。管道式連接各個過濾器的組件，負責過濾器間數據的傳輸，充當過濾器之間數據流的通道。

管道與過濾器架構具有以下優點：符合高內聚、低耦合的設計原則，可以方便地對過濾器進行替換或刪除等操作；支持模塊的重用，可以將單個獨立的過濾器應用到其他軟件系統中；支持并行執行，每個過濾器是一個獨立的實體，可以單獨運行，不受其他過濾器影響。

管道與過濾器架構的缺點主要有：不適合處理交互的應用；傳輸的數據沒有標準化，所以讀入數據和輸出數據存在格式轉換等問題，會導致性能降低。

1.6客戶端-服務器架構

客戶端-服務器模式(Client–server model)簡稱C/S結構，是一種網絡架構，它把客戶端(Client) 與服務器 (Server) 區分開來。每一個客戶端軟件的實例都可以向一個服務器或應用程序服務器發出請求。

這種系統的設計原則指定了具有特定角色的組件之間的解耦，即服務器根據客戶端的請求提供資源。

客戶端-服務器架構的優點是：客戶端和服務器可以獨立地進行升級和擴展，從而提高了系統的可擴展性；服務器可以對客戶端進行授權和身份驗證，從而提高了系統的安全性；可以根據不同的應用需求選擇不同的客戶端和服務器軟件，以適應不同的場景。

客戶端-服務器架構的缺點是：服務器是系統的核心部分，一旦服務器出現故障，整個系統就會癱瘓；網絡帶寬和延遲等因素會影響客戶端和服務器之間的通信效率；由于客戶端和服務器需要分別進行維護，因此維護成本較高。

后文提到的SOME/IP用的就是客戶端-服務器的架構思想。

1.7發布者-訂閱者架構

發布者-訂閱者架構可以當作是客戶-服務器架構的特例，這種架構規定信息的提供者和信息的使用者之間是輕耦合的。

訂閱者向中央存儲訂閱信息，以便獲得有關信息的通知。發布者不知道訂閱者，其任務僅僅是更新信息，這與客戶-服務器架構有明顯的差異，后者由服務器將信息直接發送到已知的客戶端。

在汽車軟件中，發布者-訂閱者架構通常用于分發有關車輛狀態變化的信息。其優點在于信息發布者和信息訂閱者之間的解耦，信息發布者不會隨著訂閱者數量的增加而出現過載的情況。其缺點是信息發布者無法控制哪些組件使用信息，也無法確定在任意給定時刻相關組件擁有的信息內容（因為組件不必同步接收更新）。

后文中提到的DDS用的就是發布者-訂閱者的架構思想。

1.8中間件架構

中間件架構假定存在一個公共請求代理，其協調不同組件的資源使用需求。中間件的概念是隨著對象管理組織推出的公用對象請求代理體系結構被引入軟件工程當中的。AUTOSAR標準的設計中使用了中間件架構，中間件在汽車軟件的適應機制和容錯機制中正變得越來越重要。中間件是目前汽車軟件架構的重要組成部分，后面會講。

1.9面向服務的架構

面向服務的架構（Service-Oriented Architecture，SOA）假設組件之間的松耦合采用互聯網的協議標準。它所強調的是架構中組件的接口可以使用網絡服務來訪問，并且可以在系統運行期間按照需要添加和更改服務。

目前汽車電子電氣架構由分布式向集中式演進，同時為了滿足用戶對智能化功能的快速迭代需求，汽車行業正迎來一場新的變革。在這場變革中，SOA是關鍵。SOA的關鍵是將位于整車ECU上的應用程序的不同功能單元拆分為服務，并定義服務接口，借助中間件實現服務的互操作。因此對于實現面向服務的架構，中間件是關鍵核心要素。

1.10總結

各種架構風格并不是互斥的，一種特定的架構可能是由多種架構風格組成的，通過將多種基本風格組合為單個的協作風格來形成一種混合風格。在大的維度的上，是以分層架構來設計的，但在每一層軟件實現上，可能會使用其他的架構風格。后文會對SOA進行展開，就可以看到，SOA里面有多種架構風格的體現。

2 車載智能計算基礎平臺參考架構

看完軟件架構風格，來更直觀地感受下車載軟件架構是什么樣的。網絡上各種文章里提出的各種架構很多，這里給出的是《車載智能計算基礎平臺參考架構2.0》里提出的架構。該文章是由工信部牽頭聯合多個機構給出的白皮書，與各種通信協議一樣，政府也希望智能汽車的軟硬件平臺能夠統一標準，推動產業發展。

白皮書中對車載智能計算基礎平臺的定義是，支撐智能網聯汽車駕駛自動化功能實現的軟硬件一體化平臺，包括芯片、模組、接口等硬件以及系統軟件、功能軟件等軟件。

該基礎平臺架構包含異構分布硬件架構、車控操作系統、安全體系、工具鏈。

該基礎平臺最下層是異構分布硬件架構，負責提供各類硬件結構和滿足多方面算力需求，包括AI計算單元、通用計算單元、控制單元和安全處理單元?？梢元M義理解為以GPU、MCU、FPGA等為核心構建的硬件平臺。

車控操作系統是支撐智能網聯汽車駕駛自動化功能實現和安全可靠運行的軟件集合。車控操作系統采用縱向分層（包含系統軟件和功能軟件）、橫向分區（包括安全車控操作系統、智能駕駛操作系統）式架構。插一句，操作系統分狹義和廣義之分，上面說的是廣義的，狹義的操作系統僅指OS，例如Linux、QNX等。

系統軟件縱向分為跨內核驅動框架層、內核及虛擬化管理層、系統接口層、系統中間件層。系統軟件通過標準的系統接口、系統中間件向上層提供服務，實現與功能軟件的解耦；通過跨內核驅動框架（包括?AI 驅動、BSP 等各類驅動）、硬件抽象層，實現與硬件平臺的解耦。

功能軟件是根據各類智能駕駛功能的核心共性需求，定義和實現共性的功能組件，并通過標準的應用軟件接口及服務，向上層應用軟件提供服務，實現與應用軟件的解耦。

安全體系保障車載智能計算基礎平臺的質量安全和使用安全，包括功能安全、預期功能安全、網絡安全、數據安全、OTA 安全、融合安全等。

工具鏈為車載智能計算基礎平臺的開發迭代提供支撐，包括開發調試工具、測試仿真工具、持續集成工具、過程管理工具等。

我們重點看車載操作系統，這是軟件的部分。這部分可以簡化如下圖所示。

2.1 驅動

驅動負責管理底層的硬件資源，驅動程序本質上是軟件代碼，主要作用是計算機系統與硬件設備之間完成數據傳送的功能，只有借助驅動程序，兩者才能通信并完成特定的功能。這部分軟件工作和底層軟件耦合比較多。

2.2 虛擬化

虛擬化技術用于支持多個不同的操作系統在平臺上運行。由于不同應用對于實時性和安全性的差異，常常會在一個SOC上運行不同操作系統。另外，座艙發展到目前階段，一芯多屏是基本配置。虛擬化能夠管理并虛擬化CPU、內存、外接設備等硬件資源，并將它們分配給運行在虛擬化管理系統軟件上的多個操作系統內核。

2.3 OS

OS是狹義的操作系統，根據不同的應用，需要使用到不同的OS，后面會簡單介紹下。

2.4 系統接口

系統接口是操作系統內核對上層軟件提供的服務接口，支持內存分配、調度管理、I/O處理、同步互斥等功能。POSIX API能提升跨多種操作系統內核的兼容性。POSIX API有實時擴展，包括定時器和時間管理、優先級調度互斥量和條件 變量、消息隊列、共享內存、異步I/O和同步I/O等。

POSIX，Portable Operating System Interface，即可移植操作系統接口。它是一個IEEE 1003.1標準，定義了應用程序和UNIX操作系統之間的操作語言。當應用程序在兩個支持POSIX標準的操作系統中遷移時，可以保證其兼容性。這樣應用程序就與操作系統解耦了，提高了可移植性。你看，一切為了解耦。

2.5 中間件

系統中間件向下獲取操作系統內核的系統接口服務的支持，向上支撐功能軟件層提供系統中間件的服務和接口。系統中間件大致包含如下部分。

SOA框架通常包含模塊化服務、服務注冊發現、標準互操作性接口、服務編排等內容和特征。SOA是目前車載軟件里一個很重要的趨勢，后面也會講。

AI框架用于支撐自動駕駛AI應用和大模型應用的開發。

管理中間件中包括數據加密、身份驗證、健康管理、網絡與系統安全監測等安全措施及服務，對功能軟件中的安全框架和安全服務等提供支撐，提升整體車控系統的穩定性和安全性。

通信中間件具備服務發現、遠程服務調用、讀寫進程信息等典型功能，實現車內單一節點內進程間通信或多節點間通信傳輸，?由基于CAN信號向面向服務的車載以太網數據包傳輸過渡?；贗P的可擴展的面向服務的中間件（SOME/IP）支持復雜車載網絡的服務發現和交互。在安全性方面，SOME/IP 服務發現 （SOME/IP-SD）保證了車輛網絡的安全。數據分發服務（DDS）分布式通信協議可以提供靈活、可靠、實時的數據交換機制，以滿足智能網聯汽車中多種應用程序之間的通訊需求，并確保數據的準確性和及時性。DDS還可以提供良好的擴展性和互操作性。

2.6 功能軟件

功能軟件是根據智能駕駛共性來定義和實現的通用模塊，是支撐智能駕駛應用生態建設的重要層級。說簡單點，就是將零碎的資源整合成若干通用模塊，便于應用程序調用。

再上層的應用軟件就是具體的應用實現了，比如ACC、NOA等等。

解析了上面的內容后，下文將挑選其中部分展開，即OS和中間件，同時會介紹SOA的相關概念。

3 OS

汽標委智能網聯分標委于2021年發布了《車控操作系統架構研究報告》，該白皮書將車用操作系統分為如下幾個部分。

車控操作系統分為安全車控操作系統和智能駕駛操作系統，其中，安全車控操作系統主要面向經典車輛控制領域，如動力系統、底盤系?統和車身系統等，該類操作系統對實時性和安全性要求極高，生態發展已趨于成熟。智能駕駛操作系統主要面向智能駕駛領域，應用于智能駕駛域控制器，該類操作系統對安全性和可靠性要求較高，同時對性能和運算能力的要求也較高。該類操作系統目前在全世界范圍內都?處于研究發展的初期，生態尚未完備。

車載操作系統主要面向信息娛樂和智能座艙，主要應用于車機中控系統，對于安全性和可靠性的要求處于中等水平，該類操作系統發展迅速，依托于該類操作系統的生態也處于迅速發展時期。

該白皮書中的操作系統指的是廣義上的操作系統，即系統軟件和功能軟件的集合。OS是系統軟件中的一部分，本節只關注車控操作系統部分的OS。

3.1 安全車控操作系統OS

歐洲在20世紀90年代發展出用于汽車電子上分布式實時控制系統的開放式系統標準 OSEK/VDX，主要包括4部分標準：1）操作系統規范（OS）；2）通信規范；3）網絡管理規范；4）OSEK實現語言。但隨著技術、產品、客戶需求等的升級，OSEK 標準逐漸不能支持新的硬件平臺。

2003年，寶馬、博世、大陸、戴姆勒、通用、福特、標志雪鐵龍、豐田、大眾9家企業作為核心成員，成立了一個汽車開放系統架構組織（簡稱 AUTOSAR?組織），致力于建立一個標準化平臺，獨立于硬件的分層軟件架構，制定各種車輛應用接口規范和集成標準，為應用開發提供方法論層面的指導，以減少汽車軟件設計的復雜度，提高汽車軟件的靈活性和開發效率，以及在不同汽車平臺的復用性。?AUTOSAR?以?OSEK/VDX 為基礎，但涉及的范圍更廣。

AUTOSAR?組織已發布?Classic和 Adaptive 兩個平臺規范，分別對應安全控制類和自動駕駛的高性能類。Classic 平臺基于 OSEK/VDX 標準，定義了安全車控操作系統的技術規范。需要說明的是Classic AUTOSAR不僅僅定義了OS，還定義了中間件。

3.2 智能駕駛操作系統OS

智能駕駛操作系統將會成為自動駕駛汽車發展的核心競爭力之一。智能駕駛操作系統發展趨勢和特點是縱向分層，以實現層與層之間的解耦，方便快速開發和移植，如下圖所示。

AUTOSAR組織為應對自動駕駛技術的發展推出了Adaptive?AUTOSAR（AP）架構，如下圖所示，其主要特點是采用面向服務的架構（SOA），服務可根據應用需求動態加載，可通過配置文件動態加載配置，并可進行單獨更新，相對于 Classic?AUTOSAR（CP），可以滿足更強大的算力需求，更安全，兼容性好，可進行敏捷開發。

Adaptive AUTOSAR系統主要適應于新的集中式的高性能計算平臺，滿足車內部件之間的高速通信需求和智能駕駛的高計算能力需求。AP平臺采用了服務化的架構，系統由一系列的服務組成，應用和其他軟件模塊可以根據需求調用其中的一個或者多個服務，而服務可以是平臺提供的，也可以是遠程其他部件提供。

AP平臺沒有設計新的操作系統內核，所有符合 POSIX PSE51接口的操作系統內核都可以使用。

目前普遍采用的車控操作系統底層內核主要有Linux、QNX和其他 RTOS（如 FreeRTOS、ThreadX、VxWorks等），三者之間的主要特點對比如下表所示。

4 面向服務的架構

介紹完了操作系統內核，再往上，理論上就要講中間件。但中間件是為了上下層服務的，所以在這之前，要先介紹SOA。

4.1 SOA是什么

上文講了各種軟件架構風格，在汽車發展的不同階段和不同場景中，可能都有被應用。但要重點講的是SOA，這在各種文章中也是高頻出現的，這是以后新能源汽車一個明確的趨勢。

這個概念其實并不新鮮，早在20多年前，WebService出現的時候，SOA就已被譽為是下一代Web服務的基礎框架。但是用在汽車上確是近年來隨著軟件定義汽車的發展，SOA在汽車上才開始得到應用。也就是說SOA在其他領域已經被用上了，汽車只是將SOA的概念拿來用。

汽車SOA是對整車智能化的底層能力進行組織。將車端的硬件能力和各種功能SOA化，劃分為不同的服務，拆分成顆粒度更小的接口。這些服務根據SOA標準進行接口設計，基于SOA標準協議進行通信。說明白點，就是將各種ECU的能力以“菜單”形式呈現出來，中央控制器根據ECU展現出來的能力，去要求ECU執行特定的操作。例如，車艙內有很多燈，燈的顏色、閃爍頻率、亮度等可選。所有燈可以作為一個整體，通過特定的協議（比如SOME/IP或DDS）向中央控制器表明自己可以提供如上服務。

這樣，各服務組件之間就可以相互訪問，從而擴展了服務的組合形式。舉個例子，目前很多車上有DMS系統，DMS是檢測駕駛員狀態的。隨便假設一個場景，我們需要做一個歡迎燈效，當駕駛員進車落座后，車艙內的燈產生一定的燈效。那么其實就是DMS系統要調用燈的服務，DMS系統通過SOME/IP協議，獲得燈的服務，DMS+燈的組合，就可以形成這樣的場景應用。根據用戶需求和工程師們的想象力，不同組件之間的組合可能會產生很多有趣的功能。

SOA是面向服務，與之相對的是面向信號。為了實現某一項功能，ECU從底層到應用層開發了一整套的軟件，并根據事先設定的特定信號與外部進行交互。傳統EE架構中，ECU 由不同的供應商開發，框架無法復用，無法統一，集成難度大。如果開發新的功能，那么整條軟件鏈路上所有相關的參數都需要重新編寫和配置，也就是說模塊之間的耦合度太高，其中一個升級會影響其他模塊都得跟著升級。功能模塊復用率非常低，牽一發而動全身，任何功能的更改，都會帶來非常大的工作量。還是來舉個例子，對于面向服務，DMS系統只需要向燈光系統請求，執行“歡迎燈效”（燈光系統預先定義了某一種功能或服務）。對于面向信號，DMS需要發送的信息則可能是，先開左邊的綠色的燈，再開右邊紅色的燈。在不同的車型上，如果燈光系統有變更。對于SOA，只需要查看下燈光系統支持什么功能，然后調用就好了。但對于面向信號的架構，則需要很多細節的軟件邏輯或參數。

SOA軟件架構的特性就是高內聚、松耦合、服務平臺無關化、服務動態部署/動態發現。因而為汽車出廠后的持續升級和服務降低難度、拓展出更多的可能性。

4.2 SOA的目的

看了上面說的，來思考一下，為什么汽車上要用SOA？一切的目的都是為了實現“軟件定義汽車”。

手機可以通過系統升級，快速增加各種新的特性，使得用戶覺得常用常新。所以，完全可以說是軟件定義手機。對于傳統的燃油車，基本在出廠的時候，其功能就固定了，這就應該叫做機械定義汽車。機械上的迭代是需要很長的周期的，在以往行業競爭沒這么激烈的時候，各個廠家都有自己的特點，有自己的用戶群體。但來到了新能源車時代，車上突然多了很多電子設備，當然還是可以按照以前的路子來，出廠就鎖定。但電子設備上其實是有一定的靈活性的，即其中的軟件可以快速迭代，當某個廠家可以頻繁快速的提供各種更新，那其產品力就大大提升。另外，可以提供多種付費軟件，增加營收。特斯拉就是走的這個路子，可以提供各種軟件服務，大家付費購買。雖然我是硬件出身，但不得不承認，要實現產品的差異化，還是要依靠軟件（當然，如果自己做芯片，且能有跨代的性能差異，那另說）。

4.3 SOA實現的基礎

為了實現軟件定義汽車的目的，就要解開軟件的手腳，讓其自由來去，大展拳腳。因此，需要先做下面幾件事。

（1）EEA功能架構升級

上一篇文章，兩萬多字介紹了EEA架構。EEA要做的很重要的一件事就是軟硬解耦。在初期的分布式電子電氣架構階段，一輛車上有幾十個ECU，每個ECU里都有自己的處理器來承擔相應的邏輯驅動。當整車需要功能迭代時，可能多要多個ECU共同修改配合。最終能不能做成另說，工程師在這個過程中，要花費大量的時間溝通。

EEA架構向著中央集中式架構演進，就是要把控制權回收，集中在自己的手里，大部分的ECU就變成單純的執行器。這就使得軟件從多個ECU抽取出來，匯集到區域控制器和中央控制器中，軟件被獨立出來，就有了操作自由度。

每個控制器上帶著各種ECU，這是控制器的負載，這些ECU的功能后期可能會被標準化。區域控制器根據所有ECU的硬件功能以及自身軟件功能的設計，將自身的能力抽象出若干服務，并通過標準協議，對外提供“菜單”。這樣，不同組件可以調用互相的服務，形成不同的應用。最重要的是，可以快速迭代。幾個ECU換了供應商，沒關系，只需要更新下自身的“菜單”即可。

SOA要抽象出服務，雖然分布式架構也可以抽象，但不如集中式架構來得效率高。因此，可以說EEA功能架構的演進使得軟件系統架構有了更高的服務抽象的能力。

（2）服務發現

所謂服務發現，就是說當ECU的各項能力被抽象出來后，可以被其他組件發現并調用。這就使得SOA有了動態配置的能力，提高了系統的可維護性和可配置性。當一個服務失效時，可以很快的用另一個相同功能的服務替換掉它，新服務的訪問點信息會很快在系統中被其它服務獲取，系統可以很快能從服務失效引起的錯誤中恢復，提高了系統的可靠性。當某個服務需要被升級時，也可以采用類似的方式進行，對系統的可進化性也有顯著幫助。

在SOA中，以上工作依靠一些通信協議來實現，比如SOME/IP、DDS等。這些通信協議里，包含了服務的一些具體信息。SOME/IP和DDS其實是一種消息中間件。是的，SOA中用到了中間件的架構風格，其中最出名的中間件就是AUTOSAR。

（3）EEA網絡架構升級

在之前的文章中，將網絡架構作為EEA架構中其中一個維度。這里將其單獨拎出來，是因為網絡架構升級是實現SOA架構風格的關鍵技術。

在分布式電子電氣架構階段，車上主要使用CAN或CANFD作為主干總線。CAN(FD)總線速度低、無效載荷開銷大（甚至>50%）、有效數據長度太?。–AN 8字節，CAN FD 64字節）。伴隨著智能駕駛、智能座艙等功能的引入，整車數據吞吐量急劇增加，CAN(FD)總線顯得有心無力。

在這樣的需求背景下，誕生了適用汽車領域的車載以太網。車載以太網提供100Mbp~10bps的帶寬能力，可以說一步到位解決汽車當前及以后的數據吞吐量不斷增加的難題。很巧的是，車載以太網的應用，使得SOA也有了發展的基礎。

以太網為什么能夠推動SOA的發展，是因為其具有CAN總線沒有的特點，即支持IP協議，Flexray、LIN和CAN一樣，都不支持IP協議。這意味著這幾個網絡是無法互通的。汽車電子電器架構設計的時候，解決互通問題的辦法就是兩個網絡中間加網關。網關同時支持兩個以上網絡并來回搬運數據。即使是兩條Can總線想要互通也需要加網關，而且網關的數據搬運代碼都需要單獨定制，因為每條Can的應用層協議都不一樣。

設想一下，在這種網絡環境下做SOA服務是什么效果。假如我們基于Can協議實現了一個SOA服務，我們沒法進行RPC（遠程過程調用）請求，因為 Can 協議沒有尋址的概念，請求不知道發給誰。不過好消息是Can 本質上也是發布訂閱的機制，我們可以放棄單播通訊，只做事件廣播。但Can一個消息只有8個字節，沒有地方放更多的頭信息，我們在設計服務發現機制的時候會遇到巨大挑戰。

就算我們設計出了服務發現，對不起，這個服務在別的網段中不會被發現，因為各個網段的服務是不能互通的。我們就需要開發網關程序跨網段搬運數據。但是每增加一個服務，或者對服務的數據格式做些修改，網關程序都要重新修改適配。

就算這些都完成了，我們想讓一個開發好的服務在另一個項目中復用幾乎不可能，因為對應的Can 協議，網關程序全部都要重新適配。

引入以太網技術帶來的?IP 層是解決這些問題的關鍵。不管各段網絡的物理層和鏈路層是什么樣的，只要支持 IP層協議，IP報文就可以在不同網段之間傳輸。IP 協議是可以支持廣播和多播（一次數據發送，多個目標接收）的。而且

廣播和多播是可以跨網段的，有成熟的協議支持。廣播和多播可被用于SOA 的“服務發現”和服務之間的數據發布訂閱。

當有個IP之后，每一個服務就是一個獨立的可執行的軟件組件，可以對其賦予特定的IP地址和標準化接口以便隨時調用，最終通過對這些底層功能的自由組合，以實現某項復雜的智能化功能。

5 中間件

SOA軟件架構下的應用軟件具有標準化、相互獨立和松耦合三大特點。

標準化是指每個服務件具有界定清晰的功能范圍，并且留出標準化的訪問接口，以便于其他控制器在進行功能變更或升級時進行訂閱。

相互獨立是指每個服務之間相互獨立且唯一，若想升級或新增某項功能只要通過標準化的接口調用即可。

松耦合是指，應用軟件可以獨立于車型、硬件平臺、操作系統以及編程語言。這就需要中間件來實現。

中間件本身也是一種軟件，位于操作系統和應用軟件之間。中間件其實就是將應用軟件中常用的、重復的開發工作提取出來，以便提高重用性，而工程師可以專注于核心業務邏輯的開發。對下，它能夠去適配不同的OS內核和架構；對上，它能夠提供一個統一的標準接口，負責各類應用軟件模塊之間的通信以及對底層系統資源的調度。

舉個例子，快遞員給一個小區送快遞，每一個快遞員送每一個快遞都要重復找樓棟，房間號等操作，這個很費時間。如果放在門衛處，門衛幫助分發，則可以大大提高效率。門衛在這里，就可以稱為是一個中間件。

來介紹下主要的中間件標準，AUTOSAR。嚴格來說，AUTOSAR并非特指由某一家軟件公司開發出來的某款操作系統或中間件產品，而是由全球的主要汽車生產廠商、零部件供應商、軟硬件和電子工業等企業共同指定的汽車開放式系統架構標準。不過，在實踐中，各公司基于AUTOSAR標準開發出來的中間件也被稱為AUTOSAR。

當前，AUTOSAR可分為Classic Platform和Adaptive Platform兩個平臺，兩者分別被簡稱為AUTOSAR CP與AUTOSAR AP。

簡單地說，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，對應傳統的車身控制、底盤控制、動力系統等功能，如果涉及到自動駕駛的話，AUTOSAR CP可能無法實現；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，對應自動駕駛的高性能電子系統。

嚴格地說，AUTOSAR CP并不只是個“中間件”，它是相當于“OS內核+中間件”的一套完整的“操作系統”。AUTOSAR CP定義了基本的上層任務調度、優先級調度等。在基于分布式架構的ADAS功能中，AUOTSAR CP便是最常見的“操作系統”。在AUTOSAR的生態形成后，很多芯片廠商的MCU上標配的就是AUTOSAR CP，主機廠沒有什么選擇權。由于分布式架構下的芯片主要是MCU，因此，便有了“AUTOSAR CP主要跑在MCU上”的說法。

隨著EE架構從分布式向集中式演進、芯片由MCU向SOC演進，計算量及通信量成數量級地上升，另外，多核處理器、GPU、FPGA以及專用加速器的需求，還有OTA等，都超出了AUTOSAR CP的支持范圍。

從通信速率方面來講，隨著通信技術的發展，汽車采用了以太網通信，車載以太網為汽車ECU帶來了更高的帶寬，使得數據的大量傳輸能夠在短時間得以實現。以太網為更加有效地傳輸長消息和提供點對點通信提供了有效的解決方案。然而，AUTOSAR CP則是為了傳統的車載通信技術CAN設計的，不能很好地兼容以太網，難以支持基于車載以太網的通信。

從計算能力方面來講，近些年來汽車變得越來越智能，隨之汽車對處理器的性能也提出了更高的要求，諸如自動泊車、環境感知、路徑規劃等高級功能對處理器的告訴案例需求遠遠高于對多核的需求。雖然CP已經應用于傳統的多核處理技術，但依舊無法滿足車輛對ECU處理能力的需求。此外，從處理器核半導體的技術角度看，提高性能的唯一方法是多核并行運行，并行運行以及所謂的異構計算也大大超出了CP能覆蓋的范圍。

2017年，為更好地滿足集中式架構+SOC時代的高等級自動駕駛對中間件的需求，AUTOSAR聯盟推出了通信能力更強、軟件可配置性更靈活、安全機制要求更高的AUTOSAR AP平臺。

需要強調的是，不同于AUTOSAR CP自身已經包含了基于OSEK標準的OS，AUTOSAR AP只是一個跑在Lunix、QNX等基于POSIX標準的OS上面的中間件——它自身并不包含OS。

AP和CP的主要區別如下。

總的來說，AUTOSAR CP一般應用在對實時性和功能安全要求較高、對算力要求較低的場景中，如引擎控制、制動等傳統ECU；而AUTOSAR則應用在對實時性和功能安全有一定要求，但對算力要求更高的場景中，如ADAS、自動駕駛，以及在動態部署方面追求較高自由度的信息娛樂場景。

由于SOC+MCU組合的現象會長期存在，因而，在今后相當長一段時間內，AUTOSAR AP都不可能徹底取代AUTOSAR CP——最常見的分工會是，需要高算力的工作交給AUTOSAR AP,而需要高實時性的工作則交給AUTOSAR CP。

AP修改了大量的CP標準的內容，以SOA的思想進行開發，主要目的是滿足當前汽車自動駕駛、電氣化和互聯互通等趨勢的需求。下圖是AP的軟件分層架構。

AP的架構分層主要分為硬件層、基礎服務層、ARA（實時運行環境）以及應用層?；A服務層中，主要服務包括通信服務、加密服務、日志記錄服務、診斷服務、存儲服務、狀態管理、執行管理、時間同步、升級配置管理等。其中最常用的是通信中間件，常見的兩種通信中間件是SOME/IP和DDS。下面來介紹這兩種通信中間件。

5.1 通信中間件介紹

SOA軟件設計原則之一是模塊化，模塊化可以提高可維護性、代碼重用性并隔離故障。以自動駕駛為例，系統可以分解成特定的任務模塊，如數據收集、狀態估計、任務規劃等。為了完成任務，模塊必須與其他模塊交換信息。在現代操作系統中，將單個模塊映射到軟件進程非常方便，這些進程可以位于相同的計算設備上，也可以位于物理上獨立的計算設備上。這就把信息交換的任務轉化為了進程間通信的問題，也就引出了對通信中間件的需求。

在沒有使用通信中間件的時候，為了開發上層應用，開發者們需要定義數據的格式、數據的發送方和接收方。但有了如SOME/IP和DDS這類的中間件，采用以服務/數據為中心的發布/訂閱模式后，開發者們只需要明確需要什么樣的數據、數據傳到哪里，而無需知道數據是由誰發出的、怎樣發出的。

以數據為中心，是相對于傳統的以消息為中心而言的，其與后者的本質區別在于通信中間件知道它存儲了什么數據，并能控制如何共享這些數據。對傳統的以消息為中心的中間件，程序員必須為發送消息編寫代碼；而對以數據為中心的中間件，程序員只需要為如何及何時共享數據編寫代碼，然后就可以直接共享數據。

常用的自動駕駛通信中間件中，SOME/IP和DDS采用的是發布/訂閱模式。在這種模式中，發布者和訂閱者通過主題相關聯，雙方不必知道對方在何處，也不必同時在線，實現了通信雙方在時間、空間和數據通信上的多維松耦合。

此外，相比于面向信號的CAN，DDS和SOME/IP都是面向服務的通信協議。兩者的區別在于：面向信號的數據傳輸，不管網絡需不需要，它始終會不斷循環發送；而面向服務的通信方式則不同，僅當客戶端請求或服務器通知特定訂閱者時，才在客戶端-服務器配置中交換數據，這就確保了永遠不會浪費帶寬，并且僅在需要的時間和地點進行數據通信/交換。因此，面向服務的通信協議，能夠大大減少網絡負載，提高通信效率。

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

5.2 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協會來維護的。

SOME/IP是一種應用層協議，運行在TCP/IP傳輸協議之上，作為以太網通信中間件來實現應用層和IP層的數據交互，使其不依賴操作系統，同時能兼容AUTOSAR和非AUTOSAR平臺。因此，SOME/IP可以獨立于硬件平臺、操作系統和編程語言。

來拆解一下SOME/IP：

Scalable: 可擴展的，即不拘泥于某一個系統，可以用在多個系統上

Service-oriented：是直接為應用軟件所使用的

Middleware:中間件

Over IP:基于IP通信協議

所以說白了，SOME/IP是一套用TCP/IP協議幫助不同平臺上的分布式應用軟件互相傳遞信息的機制。SOME/IP將服務接口里的內容通過SOME/IP這一套規則打包，交給TCP/IP傳輸。服務可以是多個事件、字段和方法的組合。

SOME/IP協議內容按照AUTOSAR中的描述，我們可以更進一步的拆分為三類子協議：應用層的SOME/IP標準協議，SOME/IP-SD協議以及TP層的SOME/IP-TP協議，這三部分內容相輔相成，完整詳細的闡述了SOME/IP協議的全部內容，是研究SOME/IP協議的必經之路。

在講具體的協議之前，先介紹下事件、方法和字段的概念。

事件：

單向數據傳輸，僅在更改或循環時調用，從數據的提供者發送到訂閱者。事件提供了從提供者到訂閱者的循環發送或變化的數據?？偟膩碚f，事件是訂閱者對提供者提出訂閱后，提供者把訂閱的數據通過循環發送或變化時發送這兩種方式，發送給訂閱者。

方法：

被調用的方法、函數或子例程。方法為訂閱者提供了在提供者端執行遠程過程調用的可能性。

訂閱者如果想讓提供者執行某個函數或方法，就可以SOME/IP中的方法實現。根據不同的消息類型，服務端可選擇是否進行反饋。依據是否需要進行反饋，可以分為：

Request/response：客戶端發出服務請求，服務端執行完畢后反饋調用結果的信息，對該服務進行響應。

Fire/forget：客戶端發出請求后不期待來自服務器的回復響應。

字段：

（1）getter:訂閱者可以調用getter來獲取提供者的值/狀態

（2）Setter:訂閱者可以調用setter來更改提供者端的值/狀態

（3）Notifier:訂閱者可以調用notifier讓提供者把變化的數據發送給訂閱者。

下面來介紹SOME/IP的報文，SOME/IP 報文由消息頭（Header）和數據段（Payload）組成，報文結構如下。

Message ID：

4個字節，用于識別應用程序的方法或事件。所以Message ID由Service ID(16 bit)和Method ID(15 bit)組成，前者表示應用，后者表示方法或事件。當Method ID表示方法時，bit16為0。

當Method ID表示事件時，bit16為1。

舉例來說，當你想用SOME/IP來遠程控制汽車娛樂音響系統里的音樂播放器播放下一首歌時，音樂播放器就是用Service ID表示，而切換到下一曲的動作就是Method ID。由此可以看出，Message ID對于整個系統來說是唯一的。

Length：

4個字節，它是從Request ID到Payload的字節長度。注意，不包括Message ID和Length本身。

Request ID：

4個字節，用來區分訂閱者和提供者之間的同一個方法、事件、getter或setter的多個并行使用。當你前后兩次遠程控制音樂播放器切換到下一曲時，兩次的Request ID是不同的，需要加以區分。準確來說，其實是Request ID里的Session ID來區分。Request ID由Client ID(2個字節)和Session ID(2個字節)組成。

Client ID是訂閱者的的唯一標識，提供者用Client ID區分調用同一方法的多個訂閱者。比如汽車方向盤控件可以控制娛樂音響系統的音樂播放器切換到下一曲，后排的控制面板也可以控制它，那么就可以用不同的Client ID區分它們。所以，每個Client ID在整個車輛中應該是唯一的。

Session ID用來區分同一發送者的連續請求或消息。提供者在生產響應消息時，應該把Request ID復制到響應消息中，這樣訂閱者收到后可以根據Request ID判斷這是哪條請求的響應。

Protocol Version：

1個字節，用來表示SOME/IP的Header的格式，對于SOME/IP協議首部中的改動，Protocol Version應該增加，但是對于payload中格式的改變，Protocol Version不應該增加。

Interface Version:

1個字節，用來表示服務接口版本。

Message Type

1個字節，用于區分不同類型的消息，不同值的含義如下。其中TP為SOME/IP-TP(SOME/IP Transport Protocol)。SOME/IP在采用UDP傳輸超出UDP允許數據長度的數據時需要采用SOME/IP-TP

Return code:

用于表示請求是否被成功地執行。為了簡化報頭各式的排布，每個報文都包含返回碼，具體定義規則如下。

Payload:

該字段包含所請求服務的相關參數。該字段的長度取決于所用的傳輸協議。如果采用了SOME/IP和UDP協議，有效載荷字段長度應不超過1400字節。若超出1400字節長度，可采用SOME/IP-TP或TCP傳輸協議。

這里簡單說下TCP和UDP的區別。這兩個協議都是用來在不同節點間傳遞數據的傳輸層協議。但是主要區別在于：是否需要建立連接。

為了保證長數據分包傳輸時的可靠性，防止漏掉一個或多個數據包，TCP協議需要與接收節點建立連接，并在傳輸的過程中對發送的每個數據包做接收確認。當某一個數據包對方未收到時，發送節點將重新發送，以保證整個數據的完整性。而UDP協議則不需要建立這樣復雜的連接，只需要發送一個單包的數據，之后通過對方回復的響應作為接收確認就可以了。如果未收到對方回復的數據則再發送一遍就可以。因此，針對一些要求實效性且數據不完整不會引起嚴重問題時也會采用UDP協議。因此，通常針對需要建立連接，需要發送多包數據時采用TCP協議；而在不需要建立連接，只需要發送單包數據時采用UDP協議。

當前SOME/IP支持TCP和UDP協議。相對于UDP協議，TCP允許傳輸更大的數據，并且可以通過TCP的特性保證數據傳輸的可靠性。由于在一個IP包中通過UDP傳輸SOME/IP數據有數據長度限制，如果需要傳輸的數據長度超出UDP限制，需要應用SOME/IP-TP。SOME/IP-TP中，無法放置在一個UDP報文中的數據稱為原始報文(original)，被分包后經SOME/IP-TP傳輸的數據部分被稱為片段(segments)。SOME/IP-TP的報文格式與SOME/IP的格式有略微差別，詳情請見下面鏈接，這里不展開。

https://blog.csdn.net/wto9109/article/details/123079284

5.3 SOME/IP SD協議

SOME/IP SD（Service Discovery）是用于服務發現的協議，顧名思義，具備發現服務的基本功能，這是從節點作為Client來考慮的，需要找到網絡上對應的服務；對應地，網絡中必然存在至少提供該服務的節點，該節點可被稱Server。

在這種供需場景中我們看到了提供服務，訂閱服務的過程，該過程如果用專業術語來講可稱為Subcribe/Publish模型，該模型涉及到Client與Server兩方，交互過程如之前文章所描述如下圖。

由上圖可知，Subribe/Publish的過程主要經歷以下四個階段：

（1）對于需要服務的Client而言，通過FindService方式來發現當前網絡中存在的服務；

（2）如果Server存在服務就會通過Offer Service方式來廣播通知自身存在的服務；

（3）Client根據已發現的服務中通過Subcribe EventGroup的方式來訂閱相關事件，同時在Server段發現Client的訂閱滿足條件則會回復正確的肯定響應；

（4）當Client訂閱成功后，Server端便會按照服務的基本屬性來事件型或者周期性提供Client端相關的服務

總而言之，SOME/IP-SD就是用于定位服務，檢查服務可用性以及部署與發布服務句柄的一種應用層協議，該協議只能運行在UDP之上，服務發現報文格式與SOME/IP標準協議一致，且Message ID固定為0xFFFF8100，其中Service ID是0xFFFF，Method ID為0x8100。SOME/IP-SD的報文格式如下。

SOME/IP-SD報文也是SOME/IP報文的一種，只是在SOME/IP標準協議的基礎上擴展了Entry，Option等字段，其中Entry用于同步服務實例的狀態以及發布/訂閱關系的管理，Options則用于傳輸Entry的附加信息。各個字段的具體涵義可以參考下面鏈接的內容，這里不展開。

https://blog.csdn.net/wto9109/article/details/123079284

5.4 DDS協議

DDS（Data Distribution Service）是另外一種常見的面向服務的通信中間件。DDS最早應用在美國海軍系統，用于解決軍艦系統復雜網絡環境中大量軟件升級的兼容性問題。在汽車領域，2018年Adaptive AUTOSAR引用了DDS，作為可選擇的通信方式之一。目前國內已有主機廠開始研究，主要針對自動駕駛相關需求，工具方面，在汽車電子領域常用的工具廠商也在開發這部分內容。

DDS規范是由OMG（Object Management Group）對象管理組織發布的。OMG組織是一個國際性、開放性、非盈利性技術標準聯盟，由供應商、終端用戶、學術機構、政府機構推動，已經有31年的歷史；OMG工作組針對各種技術和行業制定企業集成標準，并開發可為數千個垂直行業提供現實價值的技術標準。

在分布式系統中，DDS位于操作系統和應用程序之間，支持多種編程語言以及多種底層協議。這便是我們常說的跨平臺。

先看下DDS的通信模式，如下圖。

這里需要介紹幾個概念。

Publisher：發布者，發布主題數據，至少與1個DataWriter關聯，通過調用DataWriter的相關函數將數據發出去；

Subscriber：訂閱者，訂閱主題數據，至少與1個DataReader關聯。

DataWriter：數據寫入者，類似緩存，把需要發布的主題數據從應用層寫入到DataWriter中；

DataReader：數據讀取者，同樣可以理解為一種緩存，從訂閱者得到主題數據，隨之傳給應用層；

Topic：是數據的抽象概念，由TopicName標識，關聯相應數據的數據類型(DataType)，如果把車內所涉及的所有Topic集合在一起，這樣就形成一個虛擬的全局數據空間“Global Data Space”，進一步弱化了節點的概念，所以域參與者已經不是節點的概念了；

DDS是一個以數據為中心的中間件協議和API標準，意為用戶只關心自己想要的數據，數據通過Topic進行標識，這樣發布者根據主題發布數據，訂閱者根據自己感興趣的主題訂閱數據。這便是DDS的核心，以數據為中心的發布-訂閱模型DCPS（Data-Centric Publish-Subscribe）。

而SOME/IP是以服務為中心的，在SOME/IP中，我們需要做的是把數據打包成服務，之后服務的消費方向服務提供方通過SD訂閱服務中的事件組，當數據發生變化后，相應的事件報文便會發到總線上。相比之下，DDS確實很直接，直接與數據溝通。

DDS的另一個特點是支持QoS，目前共支持22種QoS策略，每種策略都可以應用在不同的角色上，而針對同一角色，可單獨使用一種QoS，也可以組合使用多種QoS策略。

QoS，即服務質量，其是指使用在網絡上運行的機制或技術來控制流量，確保關鍵應用程序在有限的網絡容量下的性能。簡而言之，就是怎么保證數據更好的傳輸。上面的QoS策略，舉個例子。

RELIABLITY（可靠性）

該策略下，可選的參數有RELIABLE和BEST_EFFORT。Kind = RELIABLE ，如果當網絡發生錯誤， DataReader可能無法收到DataWriter的樣本數據時，會對樣本數據進行重發，保證DataReader能夠收到數據；Kind = RELIABLE ，如果當網絡發生錯誤， DataReader可能無法收到DataWriter的樣本數據時，會對樣本數據進行重發，保證DataReader能夠收到數據。

其他QoS策略不展開，根據產品的需要可以自行配置相關的QoS策略。

5.5 SOME/IP和DDS的對比

SOME/IP和DDS是自動駕駛上用的最多的兩類通信中間件，二者都是面向服務的通信協議，但二者也有一些區別。該部分內容摘自九章智駕公眾號文章《DDS與SOME/IP誰主沉??？》

（1）應用場景不同

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

（2）靈活性、可伸縮性不同

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

（3）訂閱方和發布方是否強耦合

在SOME/IP中，在正常數據傳輸前，client需要與server建立網絡連接并詢問server是否提供所需服務，在這個層面上，節點間仍然具有一定耦合性。服務的訂閱方需要知道server在哪里，服務的發布方需要告知server提供哪種服務，例如寫一個程序，需要用到傳感器數據，這個程序要去詢問server是否可以提供傳感器數據；而在DDS標準下，每個訂閱方或發布方只需要在自己的程序里面訂閱或發布傳感器數據就行了，不需要關心任何連接?？梢岳斫鉃?，在DDS中，服務訂閱方和發布方的解耦更加徹底，需要什么數據，寫一行代碼就行了，不需要再去做綁定。

（4）DDS具有較好的QoS策略

SOME/IP只有一個QoS，即可靠性的定義；而RTI DDS和開源DDS里面分別有50多個和20多個QoS，這些QoS基本上能涵蓋絕大多數可以預見到的智能駕駛場景。以一些具體例子來闡明QoS的作用。

a）通信中的傳輸優先級、數據可靠性、資源限制、時間過濾等，都需要在QoS里面設置。

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

c）在感知系統有冗余的情況下，一旦一個傳感器宕機，就需要第二個傳感器補上來。針對這種情況，QoS可以配置一個ownership，對兩個傳感器的數據做優先級高低的區分。配置之后也不需要重新編譯，因為它是動態部署的，配置完之后就可以按照最新配置運行，去完成不同節點之間的發布訂閱。

d）DDS的解耦模式允許某一主題發布方在沒有訂閱方的情況下仍然發布數據，但后加入的訂閱方也許對這一主題的歷史記錄感興趣。例如，新節點上線后需要去監控其他節點的運行情況，這些節點也許每隔較長一段時間才發布一個信息說自己“運行正?！?，那么這個新上線的節點就需要去了解其他節點發布的歷史信息以確定其運行狀態，也就是它希望能收到其上線之前其他節點發布的歷史數據。這種情況，只需要簡單配置QoS就可以實現，新節點可以獲知上線之前多長時間、多長節點的數據流，去關注它的歷史數據等等。

e）負責監控的新節點上線后，需要去監控其他節點的運行情況。通常，這些節點每個小時發布一個信息說自己“運行正?！?，但也有可能這個“運行正?！钡墓濣c先發布了，過半小時之后監控節點才發布，那這時候，監控節點是否還能收到其上線之前其他節點發布的數據？這種情況，也是需要通過QoS去配置的，QoS可以去配置訂閱新節點上線之前多長時間、多長節點的數據流，去關注它的歷史數據等等。

總的來說，QoS能夠提供實時系統所要求的性能、可預測性和資源可控性，并且能夠保證發布/訂閱模型的模塊性、可量測性和魯棒性等。因此，DDS能夠滿足非常復雜、非常靈活的數據流要求。
??相比之下，SOME/IP只解決了發布訂閱問題，但由于沒有這些QoS，結果便是，很多本來可用自動配置服務策略來實現的功能，都需要通過軟件開發人員寫代碼才能實現，這會浪費大量的時間。

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

在《DDS與SOME/IP誰主沉??？》這篇文章里，業內人員還提到了很多其他的觀點，推薦閱讀原文。

6 總結

EEA構建了骨架，SOA注入了靈魂。再這么成長幾年，車廠就可以整更多的花活了。

編輯：黃飛

?