-供需商情.jpg?orientation=landscape&width=800&height=600)
.jpg?orientation=landscape&width=400&height=300)
2268
去年5月份，九章智駕發(fā)布的《自動駕駛OS現(xiàn)狀及市場格局》在產(chǎn)業(yè)內(nèi)引起了強烈反響，但這篇文章的重點是在說狹義OS即“內(nèi)核”，對作為廣義OS一部分的“中間件”，卻著墨不多。那么，中間件到底是什么，它分為哪些類別？每個類別又有何特殊意義？目前市場上有哪些主要玩家？
帶著這些問題，《九章智駕》在2021年11月份采訪了華玉通軟聯(lián)合創(chuàng)始人畢曉鵬、前中科創(chuàng)達首席架構(gòu)師汪浩偉（現(xiàn)為均聯(lián)智行首席架構(gòu)師）、東軟睿馳業(yè)務(wù)線總監(jiān)兼歐美全球銷售總經(jīng)理茅海燕、Vector產(chǎn)品專家蔡守群等諸多操作系統(tǒng)領(lǐng)域的專家。
接下來，我們將結(jié)合這一系列采訪成果，通過4篇文章對自動駕駛中間做個簡單的“科普”，這是第一篇。
一．中間件的定義與作用
1.什么是中間件？
圖片摘自公眾號“筋斗云與自動駕駛”
筆者在交流中發(fā)現(xiàn)，不同的人對中間件的理解并不一樣，甚至可以說，到現(xiàn)在，這個概念還是模糊不清的。比如：
（1）有的人認為中間件僅指位于OS內(nèi)核之上、功能軟件之下的那部分組件，為上層提供進程管理、升級管理等服務(wù)；而有的人則認為中間件還應(yīng)包括功能軟件和應(yīng)用軟件中間的那部分（參見上圖）。按茅海燕的說法，前者是“通用中間件”，而后者是“專用中間件”。本文中提到的“中間件”，若不做專門說明，便特指“通用中間件”。
（2）有一些人提到的自動駕駛中間件，包括了AUTOSAR（又分為AUTOSAR?CP和AUTOSAR AP），還有一些人口中的中間件，特指ROS2、Cyber RT、DDS等。
（3）未動科技VP蕭猛認為，“中間”一詞是相對的，當有多層堆疊的時候，每一層都是其上下兩層的中間層，因此，在用“中間件”這個詞的時候，我們需要特別指明它究竟位于“哪兩層之間”。按蕭猛的說法，當我們稱 “ROS/ROS2 為中間件”時，其含義與 “AUTOSAR AP為中間件”并不是對等的關(guān)系。
(4)Vector產(chǎn)品專家蔡守群說，他理解的中間件，“是給App開發(fā)提供功能支撐的，對外是沒有功能表征的；但是站在操作系統(tǒng)內(nèi)核的角度，中間件跟App并沒有本質(zhì)的區(qū)別”。
2.中間件的作用
汪浩偉說：“專用中間件原本是應(yīng)用程序的一部分，只是很多公司做自動駕駛都需要用到，就被抽象出來了。”
那么，它究竟有什么用？
畢曉鵬認為，自動駕駛中間件最主要的作用是：對下，它能夠去適配不同的OS內(nèi)核和架構(gòu)；對上，它能夠提供一個統(tǒng)一的標準接口，負責各類應(yīng)用軟件模塊之間的通信以及對底層系統(tǒng)資源的調(diào)度。
據(jù)畢曉鵬解釋，前者，使開發(fā)者們無需考慮底層的OS內(nèi)核是什么，也無需考慮硬件環(huán)境是什么，即不僅實現(xiàn)了應(yīng)用軟件與OS的解耦，也實現(xiàn)了應(yīng)用軟件與硬件的解耦；而后者則確保了數(shù)據(jù)能夠安全實時地傳輸、資源進行合理的調(diào)度。
為什么要通過中間件來支持軟硬件解耦？畢曉鵬解釋道：
我開發(fā)一個應(yīng)用軟件，其中很多內(nèi)容都是與具體應(yīng)用邏輯無關(guān)的，包括數(shù)據(jù)通信、通信安全、系統(tǒng)資源調(diào)度等，比如，有十個進程需要數(shù)據(jù)交互，完全沒有必要在十個程序的軟件代碼里各自進行實現(xiàn)和配置。針對這種情況，我們就可以把重復(fù)的部分抽象成一種服務(wù)，單獨封成一層?xùn)|西（這就是中間件），并提供統(tǒng)一的庫、接口和配置方法，供上層去調(diào)用。這樣的話，有一部分人專門去做中間件的，而做上層應(yīng)用的人也不需要考慮跟底層交互的事情。
舉例說，如果要做一個自動泊車系統(tǒng)，它有各個模塊或業(yè)務(wù)邏輯獨立的不同軟件，在進行通信、數(shù)據(jù)交互，或者調(diào)用底層資源時，只需要中間件的一個接口就可以實現(xiàn)，其他事情不需要考慮，這樣開發(fā)人員就可以專注于自己的業(yè)務(wù)邏輯。
又比如，一個攝像頭需要感知前面的車道線、紅綠燈等，開發(fā)人員就專門做紅綠燈和車道線檢測算法，與外界的數(shù)據(jù)交互只需要使用中間件的通信服務(wù)（例如訂閱攝像頭信息，發(fā)布檢測結(jié)果），而不必關(guān)心數(shù)據(jù)從哪里來、發(fā)給誰。
Nullmax紐勱科技系統(tǒng)平臺總監(jiān)苗乾坤博士在此前的一篇文章中寫道：
“芯片算力大幅增長，攝像頭像素呈翻倍之勢，激光雷達出現(xiàn)在更多新車規(guī)劃上……沒有誰能夠斷言車上的傳感器應(yīng)該有多少，又或者是將來的汽車還會增加哪些硬件，但所有人都知道硬件的變化將會來得更加猛烈。
“所以我們也可以看到，汽車對軟硬件架構(gòu)的要求也越來越高，既要能滿足當下的需求，還要具備相當?shù)那罢靶?、兼容性和擴展性，能夠支持接下來軟硬件升級換代、增減模塊的需求。而自動駕駛的中間件，就正是這樣一個可以按需調(diào)整、滿足各樣需求的現(xiàn)代溫室。
“在早期開發(fā)中，中間件可以化整為零，將巨大的軟件工程分解成若干小任務(wù)，分散解決。在后期應(yīng)用時，它又可以化零為整，像拼積木一樣，根據(jù)需求將一個個模塊組合成一個整體，嚴絲合縫?！?/p>
在春節(jié)前的一場直播中，東軟睿馳產(chǎn)品銷售總監(jiān)安志鵬說，在軟硬件解耦、模塊化管理后，再遇到問題，就不用整個系統(tǒng)都改，只改相對應(yīng)的部分就行了。這樣，軟件的可復(fù)用程度就極大地提升了，同時，驗證的工作量也會減少許多 ，整體開發(fā)效率也會因此提升。
相反，沒有中間件的話，應(yīng)用層就得直接調(diào)用操作系統(tǒng)的接口，后期要是換了操作系統(tǒng)，應(yīng)用層的代碼和算法可能就要推倒重來。
簡言之，中間件通過對計算平臺、傳感器等資源進行抽象，對算法、子系統(tǒng)、功能采取模塊化的管理，并提供統(tǒng)一接口，讓開發(fā)人員能夠?qū)Ｗ⒂诟髯詷I(yè)務(wù)層面的開發(fā)，無需了解無關(guān)細節(jié)。
按東軟睿馳產(chǎn)品銷售總監(jiān)安志鵬的說法，搞AUTSOAR這樣的中間件，并不是只對OEM有利，“零部件供應(yīng)商的選擇面也大了——應(yīng)用做好了，下面的軟件、芯片可以選好幾家供應(yīng)商的，要比傳統(tǒng)的開發(fā)模式快很多，因而，零部件供應(yīng)商也是受益者”。
用蕭猛的話說，中間件最直接的好處就是“為上層屏蔽底層的復(fù)雜性”，軟件開發(fā)人員可以忽略芯片、傳感器等硬件的差異，從而高效、靈活地將上層應(yīng)用及功能算法在不同平臺上實現(xiàn)、迭代、移植。蕭猛認為，中間件可以看做是自動駕駛應(yīng)用背景下的一項“新基建”。?
（圖片摘自馮占軍博士的《AUTOSAR對基礎(chǔ)軟件開發(fā)是喜還是憂？》一文。AUTOSAR只是中間件的一種，但這里寫的“AUTOSAR開發(fā)優(yōu)勢”基本也適用于其他中間件。）
不過，站在開發(fā)者的角度看，中間件的意義也未必全部是正面的。如馮占軍博士在《AUTOSAR對基礎(chǔ)軟件開發(fā)是喜還是憂？》一文中就提到了如下兩點：
底層軟件工程師變成了工具人，“只要你去點點鼠標，用工具配合就可以了”，很多原本由自己做的測試也改由供應(yīng)商來做，進而導(dǎo)致工程師的成就感嚴重降低；時間久了，工程師從0到1開發(fā)的能力也會降低。
（圖片摘自馮占軍博士的文章。盡管文章說的是Autosar,但實際上這些問題在ROS等其他中間件的使用過程中也會存在。）
對軟件工程師來說，中間件造成的“能力退化”這一問題幾乎是無解的。但馮占軍博士認為，“如果這個中間件在開發(fā)過程中，有使用公司的工程師深度參與，提出需求并一起實施，會好一些”。
此外，殷瑋在一篇文章提到，使用AUTOSAR這樣的中間件，Tier 1們應(yīng)該是很不情愿的，“因為不到增加了成本，還有可能逐步淪為硬件生產(chǎn)商”。但這個也不能說是中間件的鍋，在軟件定義汽車大大趨勢下，這幾乎是必然的。
二．常見的基本概念
1.?AUTOSAR CP?與?AUTOSAR AP
在所有的中間件方案中，最著名的非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上”的說法。
在分布式架構(gòu)下，不同的功能對應(yīng)著不同的MCU，而每一個MCU上都需要跑一套AUTOSAR CP，若傳感器的類型比較多，則僅ADAS相關(guān)功能就需要很多套AUTOSAR CP，那怎么收費呢？
常規(guī)的做法是：根據(jù)MCU的類型來收費——如果MCU是兩個異構(gòu)的MCU，那AUTOSAR CP就按兩套來收費；如果MCU是同構(gòu)的，那AUTOSAR CP就按一套來收費。?
隨著EE架構(gòu)從分布式向集中式演進、芯片由MCU向SOC演進，計算量及通信量成數(shù)量級地上升，另外，多核處理器、GPU、FPGA以及專用加速器的需求，還有OTA等，都超出了AUTOSAR 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。
結(jié)合aFakeProgramer于2020年發(fā)表在CSDN上的《為什么要用AP？Adaptive AutoSAR到底給企業(yè)提供了一些什么？》一文及東軟睿馳安志鵬在2022年春節(jié)前的一場直播中講的內(nèi)容，AUTOSAR CP與AUTOSAR AP最主要的區(qū)別有如下幾點：
1）.編程語言不同——AUTOSAR CP基于C語言，而AUTOSAR AP基于C++語言；
2）.架構(gòu)不同——AUTOSAR CP 采用的是FOA架構(gòu)（function-oriented architecture），而AUTOSAR AP采用的則是SOA架構(gòu)（service-oriented architecture）；
3）.通信方式不同——AUTOAR CP采用的是基于信號的靜態(tài)配置通信方式（LINCAN...通信矩陣），而AUTOSAR AP采用的是基于服務(wù)的SOA動態(tài)通信方式（SOME/IP）；
4）.連接關(guān)系不同——在AUTOSAR CP中，硬件資源的連接關(guān)系受限于線束的連接，而在AUTOSAR AP中，硬件資源間的連接關(guān)系虛擬化，不局限于通信線束的連接關(guān)系；
5）.調(diào)度方式不同——AUTOSAR CP采用固定的任務(wù)調(diào)度配置，模塊和配置在發(fā)布前進行靜態(tài)編譯、鏈接，按既定規(guī)則順序執(zhí)行，而AUTOSAR CP則支持多種動態(tài)調(diào)度策略，服務(wù)可根據(jù)應(yīng)用需求動態(tài)加載，并可進行單獨更新。
6）.代碼執(zhí)行和地址空間不同——AUTOSAR CP中，大部分代碼靜態(tài)運行在ROM，所有application共用一個地址空間，而在AUTOSAR AP中，應(yīng)用加載到RAM運行，每個application獨享（虛擬）一個地址空間。
這些區(qū)別，帶給AUTOSAR AP的優(yōu)勢有如下幾點——
1）.ECU更加智能：基于SOA通信使得AP中ECU可以動態(tài)的同其他ECU同其他ECU進行連接，提供或獲取服務(wù)；
2）.更強大的計算能力：基于SOA架構(gòu)使得AP能夠更好地支持多核、多ECU、多SoCs并行處理，從而提供更強大的計算能力；
3).更加安全：基于SOA架構(gòu)使得AP中各個服務(wù)模塊獨立，可獨立加載，IAM管理訪問權(quán)限；
4).敏捷開發(fā)：Adaptive AUTOSAR服務(wù)不局限于部署在ECU本地可分布于車載網(wǎng)絡(luò)中，使得系統(tǒng)模塊可靈活部署，后期也能靈活獨立更新（FOTA）；
5).高通信帶寬：可實現(xiàn)基于Ethernet等高通信帶寬的總線通信；
6).更易物聯(lián)：基于以太網(wǎng)的SOA通信，更易實現(xiàn)無線、遠程、云連接，方便部署V-2-X應(yīng)用。
（圖片摘自經(jīng)緯恒潤）
?
當然了，在某些方面，AUTOSAR AP與AUTOSAR CP相比是有一些“劣勢”的。比如，AUTOSAR CP的時延可低至微秒級、功能安全等級達到了ASIL-D，硬實時；而AUTOSAR AP的時延則在毫秒級，功能安全等級則為ASIL-B，軟實時。
上述區(qū)別也導(dǎo)致了兩者應(yīng)用領(lǐng)域的不同：AUTOSAR CP一般應(yīng)用在對實時性和功能安全要求較高、對算力要求較低的場景中，如引擎控制、制動等傳統(tǒng)ECU；而AUTOSAR則應(yīng)用在對實時性和功能安全有一定要求，但對算力要求更高的場景中，如ADAS、自動駕駛，以及在動態(tài)部署方面追求較高自由度的信息娛樂場景。
盡管AUTOSAR AP有種種優(yōu)點，但總的來說，它目前還不夠成熟——主要是信息安全及UCM等模塊不成熟。量產(chǎn)車上裝AUTOSAR AP的不少，但主要用在娛樂場景，真正用在自動駕駛場景的還很少。
此外，由于SOC+MCU組合的現(xiàn)象會長期存在，因而，在今后相當長一段時間內(nèi)，AUTOSAR AP都不可能徹底取代AUTOSAR CP——最常見的分工會是，需要高算力的工作交給AUTOSAR AP,而需要高實時性的工作則交給AUTOSAR CP。
（圖片摘自超星未來）
2.ROS?2
ROS是機器人操作系統(tǒng)（Robot Operating System）的英文縮寫，原生的ROS本是機器人OS，并不能直接滿足無人駕駛的所有需求，用作自動駕駛中間件的是ROS 2。
ROS 2與ROS 1的主要區(qū)別如下：
（1）.ROS 1主要構(gòu)建于Linux系統(tǒng)之上，主要支持Ubuntu；ROS 2采用全新的架構(gòu)，底層基于DDS(Data Distribution Service)通信機制，支持實時性、嵌入式、分布式、多操作系統(tǒng)，ROS 2支持的系統(tǒng)包括Linux、windows、Mac、RTOS，甚至是單片機等沒有操作系統(tǒng)的裸機。
（2）.ROS 1的通訊系統(tǒng)基于TCPROS/UDPROS，強依賴于master節(jié)點的處理；ROS 2的通訊系統(tǒng)是基于DDS，取消了master，同時在內(nèi)部提供了DDS的抽象層實現(xiàn)，有了這個抽象層，用戶就可以不去關(guān)注底層的DDS使用了哪個商家的API。
（3）.ROS運行時要依賴roscore，一旦roscore出現(xiàn)問題就會造成較大的系統(tǒng)災(zāi)難，同時由于安裝與運行體積較大，對很多低資源系統(tǒng)會造成負擔；ROS2基于DDS進行數(shù)據(jù)傳輸，而DDS基于RTPS的去中心化的通信框架，這就去除了對roscore的依賴，系統(tǒng)的穩(wěn)定性強，對資源的消耗也得到了降低。
(4).由于ROS 缺少Q(mào)os機制，topic的穩(wěn)定性與質(zhì)量難以保證；ROS2則提供了Qos機制，對通信的實時性、完整性、歷史追溯等功能有了支持，這便大幅加強了框架功能，避免了高速系統(tǒng)難以適用等問題。
不過，ROS2的QoQ配置較為復(fù)雜，目前主要是國外一些專業(yè)的大學(xué)或?qū)嶒炇以谑褂?國內(nèi)僅有極少數(shù)公司在嘗試;此外，ROS 2的生態(tài)成熟度遠不如ROS,這也給推廣應(yīng)用帶來了不便。
跟AUTOSAR AP一樣，ROS 2也是跑在soc芯片上、用于滿足高等級自動駕駛的需求的。不過，蕭猛在去年的一批文章中卻特別強調(diào)：當我們稱 “ROS/ROS2 為中間件”時，其含義與 “AUTOSAR AP為 中間件”并不是對等的關(guān)系。
蕭猛的文章稱：
當我們說 AutoSar是中間件時，這個中間件是很明確的 L.BSW層語義，即處于計算機OS與車載ECU特定功能實現(xiàn)之間，為 ECU功能實現(xiàn)層屏蔽掉特定處理器和計算機OS相關(guān)的細節(jié)，并提供與車輛網(wǎng)絡(luò)、電源等系統(tǒng)交互所需的基礎(chǔ)服務(wù)；
ROS/ROS2 是作為機器人開發(fā)的應(yīng)用框架，在機器人應(yīng)用和計算機OS之間提供了通用的中間層框架和常用軟件模塊(ROS Package)，而且， ROS團隊認為這個框架做得足夠好，可以稱作操作系統(tǒng)（OS）了。
ROS 2盡管在功能上跟AUTOSAR AP有不少重疊之處，但兩者的思路是不一樣的：
（1）.從表現(xiàn)形式上看，AUTOSAR AP首先是一套標準，這個標準定義了一系列基礎(chǔ)平臺組件，每個平臺組件定義了對應(yīng)用的標準接口，但沒有定義實現(xiàn)細節(jié)，和平臺組件之間的交互接口（這些部分留給 AUTOSAR AP供應(yīng)商實現(xiàn)）；ROS2則從一開始就是代碼優(yōu)先，每個版本都有完整的代碼實現(xiàn)，也定義有面向應(yīng)用標準API接口。
（2）AUTOSAR AP從一開始就面向ASIL-B應(yīng)用；ROS 2不是根據(jù)ASIL的標準設(shè)計的，ROS 2實現(xiàn)功能安全的解決方案是，把底層換為滿足ASIL要求的RTOS和商用工具鏈(編譯器）。
ROS 2“過不了車規(guī)”似乎已成為一個很廣泛的行業(yè)共識。但在蕭猛看來，ROS2本來就不是為實時域設(shè)計的，如果一定要把實時性要求高的車輛控制算法運行在 ROS2中，“那是軟件設(shè)計的錯誤，而不是ROS2的問題”。
蕭猛認為，只要能補齊 L.BSW層所需要完成的所有功能、補齊 A 軸所有切面要求的特性，ROS 2就能用于自動駕駛量產(chǎn)車。如前段時間剛拿到采埃孚等多家巨頭投資的Apex.AI公司基于ROS 2定制開發(fā)的Apex.OS就已經(jīng)通過了最高等級的ASIL D認證。
蕭猛說：“這實際上是基于 ROS?2的架構(gòu)去實現(xiàn)一套 AUTOSAR AP?規(guī)范。這可以成為一個單獨的產(chǎn)品，投入時間+人+錢可以開發(fā)出來，只是看有沒有必要，值不值得”。
在具體的實踐中，ROS 2跟AUTOSAR AP存在直接競爭關(guān)系——盡管對用戶來說，并不存在嚴格意義上的“二選一”問題，但通常來說，若選了ROS 2，就不會選AUTOSAR ?AP了；若選了AUTOSAR ?AP，就不會選ROS 2了。
3.?CyberRT
Cyber RT是百度Apollo開發(fā)出來的中間件，在Apollo 3.5中正式發(fā)布。Cyber RT和ROS2是比較像的， 其底層也是使用了一個開源版本的DDS。
百度最早用的是ROS 1,但在使用的過程中逐漸發(fā)現(xiàn)了ROS 1存在“若ROS Master出故障了，則任何兩個節(jié)點之間的通信便受到影響”的問題，所以就希望使用一個“沒有中間節(jié)點”的通信中間件來代替ROS 1，那時還沒有ROS2，所以自己去做了一個Cyber RT。
為了解決 ROS 遇到的問題，Cyber RT刪除了master機制，用自動發(fā)現(xiàn)機制代替，這個通信組網(wǎng)機制和汽車網(wǎng)絡(luò)CAN完全一致。此外，Cyber RT的核心設(shè)計將調(diào)度、任務(wù)從內(nèi)核空間搬到了用戶空間。
（圖片出處：https://blog.csdn.net/xhtchina/article/details/118151673）
其相對于其他系統(tǒng)，Cyber RT的一大優(yōu)勢是，專為無人架駛設(shè)計。百度已將Cyber RT開源，某互聯(lián)網(wǎng)巨頭的自動駕駛團隊使用的中間件便是百度開源出來的Cyber RT。
Cyber RT跟ROS 2之間也存在競爭關(guān)系。
在談到AUTOSAR AP、ROS 2與Cyber RT這些中間件的關(guān)系時，Vector產(chǎn)品專家蔡守群的解釋是：
“不需要很機械地去分類，你可以把AUTOSAR ?AP, ROS和Cyber RT都想象成一個提供一組中間件的超市，用戶可以按需從不同的超市購買，并不是說從一個超市買過一個中間件，就不能從其他超市買了。
蔡守群說：AUTOSAR AP中也包含了對ROS接口的支持。說不準哪天ROS和Cyber RT就會加入AUTOSAR AP的組件，或者 AUTOSAR??AP會引入Cyber RT的組件。
4.DDS（通信中間件）
（1）什么是DDS？
在自動駕駛領(lǐng)域，中間件的功能涉及到通信、模塊升級、任務(wù)調(diào)度、執(zhí)行管理，但其最主要的功能就是通信。當前市場上，無論是Cyber RT還是 ROS，基本上90%的功能就是通信，狹義上說就是通信中間件。
通信中間可以分成開源和閉源的兩種。開源的為OPEN DDS、FAST DDS、Cyclone等，閉源的就RTI的DDS和Vector的SOME/IP。DDS的全稱為Data Distribution Service ，指一種數(shù)據(jù)分發(fā)服務(wù)標準，由對象管理組織(OMG)制定。
?DDS能夠?qū)崿F(xiàn)低延遲、高可靠、高實時性的數(shù)據(jù)融合服務(wù)，能夠從根本上降低軟件的耦合性、復(fù)雜性，提高軟件的模塊化特性。高等級自動駕駛現(xiàn)在基本上都在探索依靠DDS來解決異構(gòu)通信、低時延等CP解決不了的挑戰(zhàn)。
融合了DDS的汽車軟件能夠更好地運行在下一代汽車的體系架構(gòu)中，更能降低開發(fā)的成本、縮短研發(fā)的時間，更快地將產(chǎn)品推向市場。
（2）DDS與ROS 2、AUTOSAR AP之間的關(guān)系
ROS 2和Cyber RT的底層都使用了開源的DDS，將DDS作為最重要的通信機制。但也有自動駕駛公司的工程師認為，DDS可以起到替代ROS 2的作用，站在用戶的角度看，兩者之間其實存在“二選一”的關(guān)系。
AUTOSAR CP里一直沒有包含跟DDS有關(guān)的東西，但AUTOSAR AP在?2018年3月的最新版（版本18-10）里開始支持DDS標準。將DDS與AUTOSAR AP結(jié)合使用，不僅可以保證和擴展AUTOSAR AP系統(tǒng)內(nèi)部互操作性的功能，而且還可以將其開放給來自不同的生態(tài)系統(tǒng)（即ROS 2）。
從工程角度來看，將AUTOSAR和DDS結(jié)合起來的最大優(yōu)勢是，功能域和網(wǎng)絡(luò)拓撲不再是對手，而是車輛中的盟友。網(wǎng)絡(luò)拓撲結(jié)構(gòu)能夠更好地適應(yīng)車輛的物理約束，功能域在物理車輛的頂部提供了一個靈活的覆蓋層，這就是所謂的分區(qū)體系結(jié)構(gòu)。
當然，DDS僅是通信中間件的一種。關(guān)于各類通信中間件之間的異同，我們將在本系列的第二篇做更詳細的闡釋。
三．AUTOSAR AP的地位正在弱化？
盡管AUTOSAR是當下最有名的自動駕駛中間件，但《九章智駕》在對諸多中間件廠商們的調(diào)研中得出一個結(jié)論：AUTOSAR在產(chǎn)業(yè)鏈中的地位可能正在弱化。??當然了，那些專注于AUTOSAR系統(tǒng)的廠商們并不認同這一觀點。
我們在上文已經(jīng)提到，隨著EE架構(gòu)從分布式向集中式演進、MCU被SOC取代，CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大勢所趨，在下文，我們主要談的是“AUTOSAR AP的地位會不會弱化”。
2021年12月中旬，兩家AUTOSAR發(fā)起公司大陸集團、豐田聯(lián)合采埃孚、捷豹路虎、沃爾沃、海拉等多家汽車行業(yè)龍頭企業(yè)宣布投資車載操作系統(tǒng)初創(chuàng)公司Apex.AI，而Apex.AI的主力產(chǎn)品Apex.OS則是基于ROS 2發(fā)展起來的。
拿到了Apex.AI公司15%股權(quán)的采埃孚方面在接受媒體采訪時說：“這意味著，我們可以為客戶提供AUTOSAR AP的替代方案。”
盡管AUTOSAR AP已經(jīng)有了標準，但還沒有落地。安波福、采埃孚、大陸這些公司提供的方案，仍然是基于AUTOSAR CP標準的接口。事實上，越來越多的OEM不太想完全用AUTOSAR去解決智能駕駛操作系統(tǒng)的問題。
不僅特斯拉沒有用AUTOSAR AP,國內(nèi)的幾大造車新勢力也沒有用(他們用的是AUTOSAR CP+DDS)。甚至，連一些正在轉(zhuǎn)型的傳統(tǒng)車企也沒打算用AUTOSAR AP。
從產(chǎn)業(yè)鏈中各方的反應(yīng)來看，AUTOSAR AP“地位不穩(wěn)”的原因主要有以下幾個：
1．使用成本太高
馮占軍博士在《AUTOSAR對基礎(chǔ)軟件開發(fā)是喜還是憂？》一文中透露，AUTOSAR的費用通常是“幾百萬起”，并且，針對不同的域控制器、不同的芯片需要“重復(fù)收費”，一般小廠根本吃不消?！翱赡苓€沒有什么產(chǎn)出，幾百萬就花出去了”。
除購買成本高外，畢曉鵬和蕭猛都提到，AUTOSAR前期的學(xué)習(xí)難度很大、學(xué)習(xí)成本也非常高。為了學(xué)會如何使用AUTOSAR,企業(yè)甚至不得不專門培訓(xùn)一批人,如果受培訓(xùn)的人臨時離職了，那培訓(xùn)費用就打了水漂。
2.效率不高
畢曉鵬認為，AUTOSAR AP的配置非常多，它是通過配置加上一部分代碼去實現(xiàn)自己的功能，但配置多了之后，效率不高，而且代碼臃腫。
3.靜態(tài)部署與動態(tài)部署的理念沖突
畢曉鵬博士提到，AUTOSAR AP其實是從AUTOSAR CP發(fā)展而來的，AUTOSAR CP是靜態(tài)部署，只適用于相對簡單的業(yè)務(wù)邏輯和功能，其代碼是固化的，有點像以前的功能手機——功能無法改變，不可能往里面再加一個APP；但AUTOSAR AP有點像現(xiàn)在的智能手機，軟件開發(fā)人員開發(fā)一個APP，跨平臺就可以用不同手機上了，這種動態(tài)部署的理念和之前的靜態(tài)部署概念不甚相同，而其方法論卻是基于靜態(tài)部署衍生而來的，因此在實踐層面會遇到不少問題。
4.無法滿足智能網(wǎng)聯(lián)的需求
由于云端跟車端所使用的操作系統(tǒng)不一樣，AUTOSAR只能負責車內(nèi)的通信，不能支持車端到云端的通信，因而無法支持車路協(xié)同場景（車端跟云端的通信，是通過MQTT、kafka等中間件來實現(xiàn)的）。除此之外，AUTOSAR能否兼容車輛網(wǎng)聯(lián)化中需要用到的數(shù)據(jù)平臺、通信平臺和地圖平臺，也存在很大的疑問。
畢曉鵬說，在發(fā)現(xiàn)了這些問題后，有一些OEM開始逐漸放棄AUTOSAR架構(gòu)，“轉(zhuǎn)而自己去研發(fā)一套更適合動態(tài)部署、成本較低的新型軟件架構(gòu)”。
傳統(tǒng)車廠是從使用CP過來的，所以在慣性上，他們可能還會考慮AP是否適合智能駕駛，但慢慢地也在嘗試轉(zhuǎn)型。如奧迪和TTTech合作做的通信中間件——zFAS，也沒有采用AP。
不同于AUTOSAR CP已經(jīng)是非常標準化的東西，大家用起來沒什么問題，AUTOSAR AP現(xiàn)在的標準也不是很完善，每年也在更新，具體AP能發(fā)展成什么樣，這個誰也不知道，大家更多也是觀望的態(tài)度。
畢曉鵬認為，AUTOSAR標準并不能很好地支撐自動駕駛應(yīng)用和創(chuàng)新的發(fā)展，因此，我們有必要建立一套更適合中國智能駕駛發(fā)展、且自主可控的技術(shù)架構(gòu)和生態(tài)體系。
蕭猛認為，由于從AUTOSAR CP到AUTOSAR AP一脈相承，一些已經(jīng)對AUTOSAR形成路徑依賴的公司會堅持使用AUTOSAR AP,但在經(jīng)歷過招人難、開發(fā)周期長等教訓(xùn)之后，他們有可能轉(zhuǎn)向ROS 2。
當然，以AUTOSAR為主業(yè)的公司，顯然不會認可上述“涉嫌唱衰”AUTOSAR AP的觀點的。
比如，Vector蔡守群就認為，AUTOSAR AP只會越來越重要，因為它是順應(yīng)車載技術(shù)不斷發(fā)展的一套規(guī)范，覆蓋面會越來越廣。
東軟睿馳茅海燕也認為，要將整車域控制器和智駕域控制器合并到統(tǒng)一的中央計算平臺上，沒有AUTOSAR AP的支持很難搞定?！安皇敲考夜径寄芟裉厮估粯幼约簭念^搭建系統(tǒng)的，目前,最好的工具還是AUTOSAR AP”。
參考資料：
