02 訂閱 英文縮寫是什么含義與此(請問NSN、RSS、XML是什么意思？？？謝謝)

成的“能力退化”這一問題幾乎是無解的。但馮占軍博士認為，“如果這個中間件在開發過程中，有使用公司的工程師深度參與，提出需求并一起實施，會好一些”。

此外，殷瑋在一篇文章提到，使用AUTOSAR這樣的中間件，Tier 1們應該是很不情愿的，“因為不到增加了成本，還有可能逐步淪為硬件生產商”。但這個也不能說是中間件的鍋，在軟件定義汽車大大趨勢下，這幾乎是必然的。

二．常見的基本概念

1. AUTOSAR CP 與 AUTOSAR AP

在所有的中間件方案中，最著名的非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上”的說法。

在分布式架構下，不同的功能對應著不同的MCU，而每一個MCU上都需要跑一套AUTOSAR CP，若傳感器的類型比較多，則僅ADAS相關功能就需要很多套AUTOSAR CP，那怎么收費呢？

常規的做法是：根據MCU的類型來收費——如果MCU是兩個異構的MCU，那AUTOSAR CP就按兩套來收費；如果MCU是同構的，那AUTOSAR CP就按一套來收費。

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

（圖片摘自安志鵬的直播課）

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

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

結合aFakeProgramer于2020年發表在CSDN上的《為什么要用AP？Adaptive AutoSAR到底給企業提供了一些什么？》一文及東軟睿馳安志鵬在2022年春節前的一場直播中講的內容，AUTOSAR CP與AUTOSAR AP最主要的區別有如下幾點：

1）.編程語言不同——AUTOSAR CP基于C語言，而AUTOSAR AP基于C++語言；

2）.架構不同——AUTOSAR CP 采用的是FOA架構（function-oriented architecture），而AUTOSAR AP采用的則是SOA架構（service-oriented architecture）；

3）.通信方式不同——AUTOAR CP采用的是基于信號的靜態配置通信方式（LIN\CAN...通信矩陣），而AUTOSAR AP采用的是基于服務的SOA動態通信方式（SOME/IP）；

4）.連接關系不同——在AUTOSAR CP中，硬件資源的連接關系受限于線束的連接，而在AUTOSAR AP中，硬件資源間的連接關系虛擬化，不局限于通信線束的連接關系；

5）.調度方式不同——AUTOSAR CP采用固定的任務調度配置，模塊和配置在發布前進行靜態編譯、鏈接，按既定規則順序執行，而AUTOSAR CP則支持多種動態調度策略，服務可根據應用需求動態加載，并可進行單獨更新。

6）.代碼執行和地址空間不同——AUTOSAR CP中，大部分代碼靜態運行在ROM，所有application共用一個地址空間，而在AUTOSAR AP中，應用加載到RAM運行，每個application獨享（虛擬）一個地址空間。

這些區別，帶給AUTOSAR AP的優勢有如下幾點——

1）.ECU更加智能：基于SOA通信使得AP中ECU可以動態的同其他ECU同其他ECU進行連接，提供或獲取服務；

2）.更強大的計算能力：基于SOA架構使得AP能夠更好地支持多核、多ECU、多SoCs并行處理，從而提供更強大的計算能力；

3).更加安全：基于SOA架構使得AP中各個服務模塊獨立，可獨立加載，IAM管理訪問權限；

4).敏捷開發：Adaptive AUTOSAR服務不局限于部署在ECU本地可分布于車載網絡中，使得系統模塊可靈活部署，后期也能靈活獨立更新（FOTA）；

5).高通信帶寬：可實現基于Ether買粉絲等高通信帶寬的總線通信；

6).更易物聯：基于以太網的SOA通信，更易實現無線、遠程、云連接，方便部署V-2-X應用。

（圖片摘自東軟睿馳）

當然了，在某些方面，AUTOSAR AP與AUTOSAR CP相比是有一些“劣勢”的。比如，AUTOSAR CP的時延可低至微秒級、功能安全等級達到了ASIL-D，硬實時；而AUTOSAR AP的時延則在毫秒級，功能安全等級則為ASIL-B，軟實時。

上述區別也導致了兩者應用領域的不同：AUTOSAR CP一般應用在對實時性和功能安全要求較高、對算力要求較低的場景中，如引擎控制、制動等傳統ECU；而AUTOSAR則應用在對實時性和功能安全有一定要求，但對算力要求更高的場景中，如ADAS、自動駕駛，以及在動態部署方面追求較高自由度的信息娛樂場景。

盡管AUTOSAR AP有種種優點，但總的來說，它目前還不夠成熟——主要是信息安全及UCM等模塊不成熟。量產車上裝AUTOSAR AP的不少，但主要用在娛樂場景，真正用在自動駕駛場景的還很少。

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

（圖片摘自超星未來）

2.ROS 2

ROS是機器人操作系統（Robot Operating System）的英文縮寫，原生的ROS本是機器人OS，并不能直接滿足無人駕駛的所有需求，用作自動駕駛中間件的是ROS 2。

ROS 2與ROS 1的主要區別如下：

（1）.ROS 1主要構建于Linux系統之上，主要支持Ubuntu；ROS 2采用全新的架構，底層基于DDS(Data Distribution Service)通信機制，支持實時性、嵌入式、分布式、多操作系統，ROS 2支持的系統包括Linux、windows、Mac、RTOS，甚至是單片機等沒有操作系統的裸機。

（2）.ROS 1的通訊系統基于TCPROS/UDPROS，強依賴于master節點的處理；ROS 2的通訊系統是基于DDS，取消了master，同時在內部提供了DDS的抽象層實現，有了這個抽象層，用戶就可以不去關注底層的DDS使用了哪個商家的API。

（3）.ROS運行時要依賴ros買粉絲re，一旦ros買粉絲re出現問題就會造成較大的系統災難，同時由于安裝與運行體積較大，對很多低資源系統會造成負擔；ROS2基于DDS進行數據傳輸，而DDS基于RTPS的去中心化的通信框架，這就去除了對ros買粉絲re的依賴，系統的穩定性強，對資源的消耗也得到了降低。

(4).由于ROS 缺少Qos機制，topic的穩定性與質量難以保證；ROS2則提供了Qos機制，對通信的實時性、完整性、歷史追溯等功能有了支持，這便大幅加強了框架功能，避免了高速系統難以適用等問題。

不過，ROS2的QoQ配置較為復雜，目前主要是國外一些專業的大學或實驗室在使用,國內僅有極少數公司在嘗試;此外，ROS 2的生態成熟度遠不如ROS,這也給推廣應用帶來了不便。

跟AUTOSAR AP一樣，ROS 2也是跑在soc芯片上、用于滿足高等級自動駕駛的需求的。不過，蕭猛在去年的一批文章中卻特別強調：當我們稱 “ROS/ROS2 為中間件”時，其含義與 “AUTOSAR AP為 中間件”并不是對等的關系。

蕭猛的文章稱：

當我們說 AutoSar是中間件時，這個中間件是很明確的 L.BSW層語義，即處于計算機OS與車載ECU特定功能實現之間，為 ECU功能實現層屏蔽掉特定處理器和計算機OS相關的細節，并提供與車輛網絡、電源等系統交互所需的基礎服務；

ROS/ROS2 是作為機器人開發的應用框架，在機器人應用和計算機OS之間提供了通用的中間層框架和常用軟件模塊(ROS Package)，而且， ROS團隊認為這個框架做得足夠好，可以稱作操作系統（OS）了。

ROS 2盡管在功能上跟AUTOSAR AP有不少重疊之處，但兩者的思路是不一樣的：

（1）.從表現形式上看，AUTOSAR AP首先是一套標準，這個標準定義了一系列基礎平臺組件，每個平臺組件定義了對應用的標準接口，但沒有定義實現細節，和平臺組件之間的交互接口（這些部分留給AUTOSAR AP供應商實現）；ROS2則從一開始就是代碼優先，每個版本都有完整的代碼實現，也定義有面向應用標準API接口。

（2）AUTOSAR AP從一開始就面向ASIL-B應用；ROS 2不是根據ASIL的標準設計的，ROS 2實現功能安全的解決方案是，把底層換為滿足ASIL要求的RTOS和商用工具鏈(編譯器）。

ROS 2“過不了車規”似乎已成為一個很廣泛的行業共識。但在蕭猛看來，ROS2本來就不是為實時域設計的，如果一定要把實時性要求高的車輛控制算法運行在 ROS2中，“那是軟件設計的錯誤，而不是ROS2的問題”。

蕭猛認為，只要能補齊 L.BSW層所需要完成的所有功能、補齊 A 軸所有切面要求的特性，ROS 2就能用于自動駕駛量產車。如前段時間剛拿到采埃孚等多家巨頭投資的Apex.AI公司基于ROS 2定制開發的Apex.OS就已經通過了最高等級的ASIL D認證。

蕭猛說：“這實際上是基于 ROS 2的架構去實現一套 AUTOSAR AP 規范。這可以成為一個單獨的產品，

很赞哦!（86）