0 序言

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

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

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

上一篇文章學(xué)習(xí)了EEA架構(gòu)的演變，EEA架構(gòu)是軟件架構(gòu)得以實現(xiàn)的基礎(chǔ)，而好的軟件架構(gòu)又能夠充分發(fā)揮EEA架構(gòu)的能力。本文試圖從軟件的門口路過，朝里面看一眼，大致理解一下軟件工程師們在做哪些事情。

1 軟件架構(gòu)風(fēng)格

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

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

軟件工程師根據(jù)項目的特點和需要選擇特定的軟件架構(gòu)風(fēng)格,這和不同地方根據(jù)當?shù)貧夂蚝兔褡逄厣x擇不同的建筑風(fēng)格其實差不多。至于如何從哪些維度去評判軟件架構(gòu)的好壞，可以查看《自動駕駛軟件架構(gòu)之中間件與SOA介紹》這篇文章，里面有提到一些軟件架構(gòu)的評估方法。

1.1分層架構(gòu)

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

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

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

1.2基于組件的架構(gòu)

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

需要說明的是，基于組件的架構(gòu)并不是完全替代分層架構(gòu)，架構(gòu)可以分為多個層次。在大的維度上，軟件架構(gòu)可以使用分層架構(gòu)。比如系統(tǒng)可以分為平臺層和應(yīng)用層，這是分層架構(gòu)的概念。但是在應(yīng)用層內(nèi)，多個應(yīng)用之間可以采用基于組件的架構(gòu)，多個APP可以互相調(diào)用。

1.3單體架構(gòu)

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

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

1.4微內(nèi)核架構(gòu)

微內(nèi)核架構(gòu)又稱插件架構(gòu)，指的是軟件的內(nèi)核相對較小，主要功能和業(yè)務(wù)邏輯通過插件實現(xiàn)，許多現(xiàn)代操作系統(tǒng)都采用這種架構(gòu)。這種架構(gòu)可以被看作分層架構(gòu)中的一種雙層架構(gòu)的特例。

內(nèi)核包含系統(tǒng)運行的最小功能，是具有更高執(zhí)行權(quán)限的有限組件的集合，如任務(wù)調(diào)度程序、內(nèi)存管理和基礎(chǔ)進程間通管理，這些組件相較于應(yīng)用層的組件而言擁有更高級別的權(quán)限。應(yīng)用程序則是相互獨立的，它們之間的通信應(yīng)該減至最少，避免出現(xiàn)互相依賴的問題。例如，用戶應(yīng)用程序進程、設(shè)備驅(qū)動程序或文件服務(wù)的組件，這些組件可以具備不同的權(quán)限級別，但是其權(quán)限級別要始終低于內(nèi)核進程。

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

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

1.5管道與過濾器架構(gòu)

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

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

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

管道與過濾器架構(gòu)的缺點主要有：不適合處理交互的應(yīng)用；傳輸?shù)臄?shù)據(jù)沒有標準化，所以讀入數(shù)據(jù)和輸出數(shù)據(jù)存在格式轉(zhuǎn)換等問題，會導(dǎo)致性能降低。

1.6客戶端-服務(wù)器架構(gòu)

客戶端-服務(wù)器模式(Client–server model)簡稱C/S結(jié)構(gòu)，是一種網(wǎng)絡(luò)架構(gòu)，它把客戶端(Client) 與服務(wù)器 (Server) 區(qū)分開來。每一個客戶端軟件的實例都可以向一個服務(wù)器或應(yīng)用程序服務(wù)器發(fā)出請求。

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

客戶端-服務(wù)器架構(gòu)的優(yōu)點是：客戶端和服務(wù)器可以獨立地進行升級和擴展，從而提高了系統(tǒng)的可擴展性；服務(wù)器可以對客戶端進行授權(quán)和身份驗證，從而提高了系統(tǒng)的安全性；可以根據(jù)不同的應(yīng)用需求選擇不同的客戶端和服務(wù)器軟件，以適應(yīng)不同的場景。

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

后文提到的SOME/IP用的就是客戶端-服務(wù)器的架構(gòu)思想。

1.7發(fā)布者-訂閱者架構(gòu)

發(fā)布者-訂閱者架構(gòu)可以當作是客戶-服務(wù)器架構(gòu)的特例，這種架構(gòu)規(guī)定信息的提供者和信息的使用者之間是輕耦合的。

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

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

后文中提到的DDS用的就是發(fā)布者-訂閱者的架構(gòu)思想。

1.8中間件架構(gòu)

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

1.9面向服務(wù)的架構(gòu)

面向服務(wù)的架構(gòu)（Service-Oriented Architecture，SOA）假設(shè)組件之間的松耦合采用互聯(lián)網(wǎng)的協(xié)議標準。它所強調(diào)的是架構(gòu)中組件的接口可以使用網(wǎng)絡(luò)服務(wù)來訪問，并且可以在系統(tǒng)運行期間按照需要添加和更改服務(wù)。

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

1.10總結(jié)

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

2 車載智能計算基礎(chǔ)平臺參考架構(gòu)

看完軟件架構(gòu)風(fēng)格，來更直觀地感受下車載軟件架構(gòu)是什么樣的。網(wǎng)絡(luò)上各種文章里提出的各種架構(gòu)很多，這里給出的是《車載智能計算基礎(chǔ)平臺參考架構(gòu)2.0》里提出的架構(gòu)。該文章是由工信部牽頭聯(lián)合多個機構(gòu)給出的白皮書，與各種通信協(xié)議一樣，政府也希望智能汽車的軟硬件平臺能夠統(tǒng)一標準，推動產(chǎn)業(yè)發(fā)展。

白皮書中對車載智能計算基礎(chǔ)平臺的定義是，支撐智能網(wǎng)聯(lián)汽車駕駛自動化功能實現(xiàn)的軟硬件一體化平臺，包括芯片、模組、接口等硬件以及系統(tǒng)軟件、功能軟件等軟件。

該基礎(chǔ)平臺架構(gòu)包含異構(gòu)分布硬件架構(gòu)、車控操作系統(tǒng)、安全體系、工具鏈。

該基礎(chǔ)平臺最下層是異構(gòu)分布硬件架構(gòu)，負責(zé)提供各類硬件結(jié)構(gòu)和滿足多方面算力需求，包括AI計算單元、通用計算單元、控制單元和安全處理單元。可以狹義理解為以GPU、MCU、FPGA等為核心構(gòu)建的硬件平臺。

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

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

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

安全體系保障車載智能計算基礎(chǔ)平臺的質(zhì)量安全和使用安全，包括功能安全、預(yù)期功能安全、網(wǎng)絡(luò)安全、數(shù)據(jù)安全、OTA 安全、融合安全等。

工具鏈為車載智能計算基礎(chǔ)平臺的開發(fā)迭代提供支撐，包括開發(fā)調(diào)試工具、測試仿真工具、持續(xù)集成工具、過程管理工具等。

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

2.1 驅(qū)動

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

2.2 虛擬化

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

2.3 OS

OS是狹義的操作系統(tǒng)，根據(jù)不同的應(yīng)用，需要使用到不同的OS，后面會簡單介紹下。

2.4 系統(tǒng)接口

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

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

2.5 中間件

系統(tǒng)中間件向下獲取操作系統(tǒng)內(nèi)核的系統(tǒng)接口服務(wù)的支持，向上支撐功能軟件層提供系統(tǒng)中間件的服務(wù)和接口。系統(tǒng)中間件大致包含如下部分。

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

AI框架用于支撐自動駕駛AI應(yīng)用和大模型應(yīng)用的開發(fā)。

管理中間件中包括數(shù)據(jù)加密、身份驗證、健康管理、網(wǎng)絡(luò)與系統(tǒng)安全監(jiān)測等安全措施及服務(wù)，對功能軟件中的安全框架和安全服務(wù)等提供支撐，提升整體車控系統(tǒng)的穩(wěn)定性和安全性。

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

2.6 功能軟件

功能軟件是根據(jù)智能駕駛共性來定義和實現(xiàn)的通用模塊，是支撐智能駕駛應(yīng)用生態(tài)建設(shè)的重要層級。說簡單點，就是將零碎的資源整合成若干通用模塊，便于應(yīng)用程序調(diào)用。

再上層的應(yīng)用軟件就是具體的應(yīng)用實現(xiàn)了，比如ACC、NOA等等。

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

3 OS

汽標委智能網(wǎng)聯(lián)分標委于2021年發(fā)布了《車控操作系統(tǒng)架構(gòu)研究報告》，該白皮書將車用操作系統(tǒng)分為如下幾個部分。

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

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

該白皮書中的操作系統(tǒng)指的是廣義上的操作系統(tǒng)，即系統(tǒng)軟件和功能軟件的集合。OS是系統(tǒng)軟件中的一部分，本節(jié)只關(guān)注車控操作系統(tǒng)部分的OS。

3.1 安全車控操作系統(tǒng)OS

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

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

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

3.2 智能駕駛操作系統(tǒng)OS

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

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

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

AP平臺沒有設(shè)計新的操作系統(tǒng)內(nèi)核，所有符合 POSIX PSE51接口的操作系統(tǒng)內(nèi)核都可以使用。

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

4 面向服務(wù)的架構(gòu)

介紹完了操作系統(tǒng)內(nèi)核，再往上，理論上就要講中間件。但中間件是為了上下層服務(wù)的，所以在這之前，要先介紹SOA。

4.1 SOA是什么

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

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

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

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

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

SOA軟件架構(gòu)的特性就是高內(nèi)聚、松耦合、服務(wù)平臺無關(guān)化、服務(wù)動態(tài)部署/動態(tài)發(fā)現(xiàn)。因而為汽車出廠后的持續(xù)升級和服務(wù)降低難度、拓展出更多的可能性。

4.2 SOA的目的

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

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

4.3 SOA實現(xiàn)的基礎(chǔ)

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

（1）EEA功能架構(gòu)升級

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

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

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

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

（2）服務(wù)發(fā)現(xiàn)

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

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

（3）EEA網(wǎng)絡(luò)架構(gòu)升級

在之前的文章中，將網(wǎng)絡(luò)架構(gòu)作為EEA架構(gòu)中其中一個維度。這里將其單獨拎出來，是因為網(wǎng)絡(luò)架構(gòu)升級是實現(xiàn)SOA架構(gòu)風(fēng)格的關(guān)鍵技術(shù)。

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

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

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

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

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

就算這些都完成了，我們想讓一個開發(fā)好的服務(wù)在另一個項目中復(fù)用幾乎不可能，因為對應(yīng)的Can 協(xié)議，網(wǎng)關(guān)程序全部都要重新適配。

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

廣播和多播是可以跨網(wǎng)段的，有成熟的協(xié)議支持。廣播和多播可被用于SOA 的“服務(wù)發(fā)現(xiàn)”和服務(wù)之間的數(shù)據(jù)發(fā)布訂閱。

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

5 中間件

SOA軟件架構(gòu)下的應(yīng)用軟件具有標準化、相互獨立和松耦合三大特點。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AP和CP的主要區(qū)別如下。

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

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

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

AP的架構(gòu)分層主要分為硬件層、基礎(chǔ)服務(wù)層、ARA（實時運行環(huán)境）以及應(yīng)用層。基礎(chǔ)服務(wù)層中，主要服務(wù)包括通信服務(wù)、加密服務(wù)、日志記錄服務(wù)、診斷服務(wù)、存儲服務(wù)、狀態(tài)管理、執(zhí)行管理、時間同步、升級配置管理等。其中最常用的是通信中間件，常見的兩種通信中間件是SOME/IP和DDS。下面來介紹這兩種通信中間件。

5.1 通信中間件介紹

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

在沒有使用通信中間件的時候，為了開發(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ù)。

常用的自動駕駛通信中間件中，SOME/IP和DDS采用的是發(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ò)負載，提高通信效率。

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

5.2 SOME/IP協(xié)議

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é)會來維護的。

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

來拆解一下SOME/IP：

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

Service-oriented：是直接為應(yīng)用軟件所使用的

Middleware:中間件

Over IP:基于IP通信協(xié)議

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

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

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

事件：

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

方法：

被調(diào)用的方法、函數(shù)或子例程。方法為訂閱者提供了在提供者端執(zhí)行遠程過程調(diào)用的可能性。

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

Request/response：客戶端發(fā)出服務(wù)請求，服務(wù)端執(zhí)行完畢后反饋調(diào)用結(jié)果的信息，對該服務(wù)進行響應(yīng)。

Fire/forget：客戶端發(fā)出請求后不期待來自服務(wù)器的回復(fù)響應(yīng)。

字段：

（1）getter:訂閱者可以調(diào)用getter來獲取提供者的值/狀態(tài)

（2）Setter:訂閱者可以調(diào)用setter來更改提供者端的值/狀態(tài)

（3）Notifier:訂閱者可以調(diào)用notifier讓提供者把變化的數(shù)據(jù)發(fā)送給訂閱者。

下面來介紹SOME/IP的報文，SOME/IP 報文由消息頭（Header）和數(shù)據(jù)段（Payload）組成，報文結(jié)構(gòu)如下。

Message ID：

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

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

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

Length：

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

Request ID：

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

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

Session ID用來區(qū)分同一發(fā)送者的連續(xù)請求或消息。提供者在生產(chǎn)響應(yīng)消息時，應(yīng)該把Request ID復(fù)制到響應(yīng)消息中，這樣訂閱者收到后可以根據(jù)Request ID判斷這是哪條請求的響應(yīng)。

Protocol Version：

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

Interface Version:

1個字節(jié)，用來表示服務(wù)接口版本。

Message Type

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

Return code:

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

Payload:

該字段包含所請求服務(wù)的相關(guān)參數(shù)。該字段的長度取決于所用的傳輸協(xié)議。如果采用了SOME/IP和UDP協(xié)議，有效載荷字段長度應(yīng)不超過1400字節(jié)。若超出1400字節(jié)長度，可采用SOME/IP-TP或TCP傳輸協(xié)議。

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

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

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

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

5.3 SOME/IP SD協(xié)議

SOME/IP SD（Service Discovery）是用于服務(wù)發(fā)現(xiàn)的協(xié)議，顧名思義，具備發(fā)現(xiàn)服務(wù)的基本功能，這是從節(jié)點作為Client來考慮的，需要找到網(wǎng)絡(luò)上對應(yīng)的服務(wù)；對應(yīng)地，網(wǎng)絡(luò)中必然存在至少提供該服務(wù)的節(jié)點，該節(jié)點可被稱Server。

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

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

（1）對于需要服務(wù)的Client而言，通過FindService方式來發(fā)現(xiàn)當前網(wǎng)絡(luò)中存在的服務(wù)；

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

（3）Client根據(jù)已發(fā)現(xiàn)的服務(wù)中通過Subcribe EventGroup的方式來訂閱相關(guān)事件，同時在Server段發(fā)現(xiàn)Client的訂閱滿足條件則會回復(fù)正確的肯定響應(yīng)；

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

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

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

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

5.4 DDS協(xié)議

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

DDS規(guī)范是由OMG（Object Management Group）對象管理組織發(fā)布的。OMG組織是一個國際性、開放性、非盈利性技術(shù)標準聯(lián)盟，由供應(yīng)商、終端用戶、學(xué)術(shù)機構(gòu)、政府機構(gòu)推動，已經(jīng)有31年的歷史；OMG工作組針對各種技術(shù)和行業(yè)制定企業(yè)集成標準，并開發(fā)可為數(shù)千個垂直行業(yè)提供現(xiàn)實價值的技術(shù)標準。

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

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

這里需要介紹幾個概念。

Publisher：發(fā)布者，發(fā)布主題數(shù)據(jù)，至少與1個DataWriter關(guān)聯(lián)，通過調(diào)用DataWriter的相關(guān)函數(shù)將數(shù)據(jù)發(fā)出去；

Subscriber：訂閱者，訂閱主題數(shù)據(jù)，至少與1個DataReader關(guān)聯(lián)。

DataWriter：數(shù)據(jù)寫入者，類似緩存，把需要發(fā)布的主題數(shù)據(jù)從應(yīng)用層寫入到DataWriter中；

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

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

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

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

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

QoS，即服務(wù)質(zhì)量，其是指使用在網(wǎng)絡(luò)上運行的機制或技術(shù)來控制流量，確保關(guān)鍵應(yīng)用程序在有限的網(wǎng)絡(luò)容量下的性能。簡而言之，就是怎么保證數(shù)據(jù)更好的傳輸。上面的QoS策略，舉個例子。

RELIABLITY（可靠性）

該策略下，可選的參數(shù)有RELIABLE和BEST_EFFORT。Kind = RELIABLE ，如果當網(wǎng)絡(luò)發(fā)生錯誤， DataReader可能無法收到DataWriter的樣本數(shù)據(jù)時，會對樣本數(shù)據(jù)進行重發(fā)，保證DataReader能夠收到數(shù)據(jù)；Kind = RELIABLE ，如果當網(wǎng)絡(luò)發(fā)生錯誤， DataReader可能無法收到DataWriter的樣本數(shù)據(jù)時，會對樣本數(shù)據(jù)進行重發(fā)，保證DataReader能夠收到數(shù)據(jù)。

其他QoS策略不展開，根據(jù)產(chǎn)品的需要可以自行配置相關(guān)的QoS策略。

5.5 SOME/IP和DDS的對比

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

（1）應(yīng)用場景不同

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

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

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

（3）訂閱方和發(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ù)，寫一行代碼就行了，不需要再去做綁定。

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

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

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

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

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

d）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ù)等等。

e）負責(zé)監(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)就無法正常運作了。

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

6 總結(jié)

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

編輯：黃飛

?