去年5月份，九章智駕釋出的《自動駕駛OS現狀及市場格局》在産業内引起了強烈反響，但這篇文章的重點是在說狹義OS即“核心”，對作為廣義OS一部分的“中間件”，卻着墨不多。那麼，中間件到底是什麼，它分為哪些類别？每個類别又有何特殊意義？目前市場上有哪些主要玩家？
帶着這些問題，《九章智駕》在2021年11月份采訪了華玉通軟聯合創始人畢曉鵬、前中科創達首席架構師汪浩偉（現為均聯智行首席架構師）、東軟睿馳業務線總監兼歐美全球銷售總經理茅海燕、Vector産品專家蔡守群等諸多作業系統領域的專家。
接下來，我們将結合這一系列采訪成果，通過4篇文章對自動駕駛中間做個簡單的“科普”，這是第一篇。
一．中間件的定義與作用
1.什麼是中間件？
圖檔摘自公衆号“筋鬥雲與自動駕駛”
筆者在交流中發現，不同的人對中間件的了解并不一樣，甚至可以說，到現在，這個概念還是模糊不清的。比如：
（1）有的人認為中間件僅指位于OS核心之上、功能軟體之下的那部分元件，為上層提供程序管理、更新管理等服務；而有的人則認為中間件還應包括功能軟體和應用軟體中間的那部分（參見上圖）。按茅海燕的說法，前者是“通用中間件”，而後者是“專用中間件”。本文中提到的“中間件”，若不做專門說明，便特指“通用中間件”。
（2）有一些人提到的自動駕駛中間件，包括了AUTOSAR（又分為AUTOSAR CP和AUTOSAR AP），還有一些人口中的中間件，特指ROS2、Cyber RT、DDS等。
（3）未動科技VP蕭猛認為，“中間”一詞是相對的，當有多層堆疊的時候，每一層都是其上下兩層的中間層，是以，在用“中間件”這個詞的時候，我們需要特别指明它究竟位于“哪兩層之間”。按蕭猛的說法，當我們稱“ROS/ROS2 為中間件”時，其含義與 “AUTOSAR AP為中間件”并不是對等的關系。
(4)Vector産品專家蔡守群說，他了解的中間件，“是給App開發提供功能支撐的，對外是沒有功能表征的；但是站在作業系統核心的角度，中間件跟App并沒有本質的差別”。
2.中間件的作用
汪浩偉說：“專用中間件原本是應用程式的一部分，隻是很多公司做自動駕駛都需要用到，就被抽象出來了。”
那麼，它究竟有什麼用？
畢曉鵬認為，自動駕駛中間件最主要的作用是：對下，它能夠去适配不同的OS核心和架構；對上，它能夠提供一個統一的标準接口，負責各類應用軟體子產品之間的通信以及對底層系統資源的排程。
據畢曉鵬解釋，前者，使開發者們無需考慮底層的OS核心是什麼，也無需考慮硬體環境是什麼，即不僅實作了應用軟體與OS的解耦，也實作了應用軟體與硬體的解耦；而後者則確定了資料能夠安全實時地傳輸、資源進行合理的排程。
為什麼要通過中間件來支援軟硬體解耦？畢曉鵬解釋道：
我開發一個應用軟體，其中很多内容都是與具體應用邏輯無關的，包括資料通信、通信安全、系統資源排程等，比如，有十個程序需要資料互動，完全沒有必要在十個程式的軟體代碼裡各自進行實作和配置。針對這種情況，我們就可以把重複的部分抽象成一種服務，單獨封成一層東西（這就是中間件），并提供統一的庫、接口和配置方法，供上層去調用。這樣的話，有一部分人專門去做中間件的，而做上層應用的人也不需要考慮跟底層互動的事情。
舉例說，如果要做一個自動泊車系統，它有各個子產品或業務邏輯獨立的不同軟體，在進行通信、資料互動，或者調用底層資源時，隻需要中間件的一個接口就可以實作，其他事情不需要考慮，這樣開發人員就可以專注于自己的業務邏輯。
又比如，一個攝像頭需要感覺前面的車道線、紅綠燈等，開發人員就專門做紅綠燈和車道線檢測算法，與外界的資料互動隻需要使用中間件的通信服務（例如訂閱攝像頭資訊，釋出檢測結果），而不必關心資料從哪裡來、發給誰。
Nullmax紐劢科技系統平台總監苗乾坤博士在此前的一篇文章中寫道：
“晶片算力大幅增長，攝像頭像素呈翻倍之勢，雷射雷達出現在更多新車規劃上……沒有誰能夠斷言車上的傳感器應該有多少，又或者是将來的汽車還會增加哪些硬體，但所有人都知道硬體的變化将會來得更加猛烈。
“是以我們也可以看到，汽車對軟硬體架構的要求也越來越高，既要能滿足當下的需求，還要具備相當的前瞻性、相容性和擴充性，能夠支援接下來軟硬體更新換代、增減子產品的需求。而自動駕駛的中間件，就正是這樣一個可以按需調整、滿足各樣需求的現代溫室。
“在早期開發中，中間件可以化整為零，将巨大的軟體工程分解成若幹小任務，分散解決。在後期應用時，它又可以化零為整，像拼積木一樣，根據需求将一個個子產品組合成一個整體，嚴絲合縫。”
在春節前的一場直播中，東軟睿馳産品銷售總監安志鵬說，在軟硬體解耦、子產品化管理後，再遇到問題，就不用整個系統都改，隻改相對應的部分就行了。這樣，軟體的可複用程度就極大地提升了，同時，驗證的工作量也會減少許多，整體開發效率也會是以提升。
相反，沒有中間件的話，應用層就得直接調用作業系統的接口，後期要是換了作業系統，應用層的代碼和算法可能就要推倒重來。
簡言之，中間件通過對計算平台、傳感器等資源進行抽象，對算法、子系統、功能采取子產品化的管理，并提供統一接口，讓開發人員能夠專注于各自業務層面的開發，無需了解無關細節。
按東軟睿馳産品銷售總監安志鵬的說法，搞AUTSOAR這樣的中間件，并不是隻對OEM有利，“零部件供應商的選擇面也大了——應用做好了，下面的軟體、晶片可以選好幾家供應商的，要比傳統的開發模式快很多，因而，零部件供應商也是受益者”。
用蕭猛的話說，中間件最直接的好處就是“為上層屏蔽底層的複雜性”，軟體開發人員可以忽略晶片、傳感器等硬體的差異，進而高效、靈活地将上層應用及功能算法在不同平台上實作、疊代、移植。蕭猛認為，中間件可以看做是自動駕駛應用背景下的一項“新基建”。
（圖檔摘自馮占軍博士的《AUTOSAR對基礎軟體開發是喜還是憂？》一文。AUTOSAR隻是中間件的一種，但這裡寫的“AUTOSAR開發優勢”基本也适用于其他中間件。）
不過，站在開發者的角度看，中間件的意義也未必全部是正面的。如馮占軍博士在《AUTOSAR對基礎軟體開發是喜還是憂？》一文中就提到了如下兩點：
底層軟體工程師變成了工具人，“隻要你去點點滑鼠，用工具配合就可以了”，很多原本由自己做的測試也改由供應商來做，進而導緻工程師的成就感嚴重降低；時間久了，工程師從0到1開發的能力也會降低。
（圖檔摘自馮占軍博士的文章。盡管文章說的是Autosar,但實際上這些問題在ROS等其他中間件的使用過程中也會存在。）
對軟體工程師來說，中間件造成的“能力退化”這一問題幾乎是無解的。但馮占軍博士認為，“如果這個中間件在開發過程中，有使用公司的工程師深度參與，提出需求并一起實施，會好一些”。
此外，殷玮在一篇文章提到，使用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).高通信帶寬：可實作基于Ethernet等高通信帶寬的總線通信；
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.ROS2
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運作時要依賴roscore，一旦roscore出現問題就會造成較大的系統災難，同時由于安裝與運作體積較大，對很多低資源系統會造成負擔；ROS2基于DDS進行資料傳輸，而DDS基于RTPS的去中心化的通信架構，這就去除了對roscore的依賴，系統的穩定性強，對資源的消耗也得到了降低。
(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 規範。這可以成為一個單獨的産品，投入時間+人+錢可以開發出來，隻是看有沒有必要，值不值得”。
在具體的實踐中，ROS 2跟AUTOSAR AP存在直接競争關系——盡管對使用者來說，并不存在嚴格意義上的“二選一”問題，但通常來說，若選了ROS 2，就不會選AUTOSAR AP了；若選了AUTOSAR AP，就不會選ROS 2了。
3.CyberRT
Cyber RT是百度Apollo開發出來的中間件，在Apollo 3.5中正式釋出。Cyber RT和ROS2是比較像的， 其底層也是使用了一個開源版本的DDS。
百度最早用的是ROS 1,但在使用的過程中逐漸發現了ROS 1存在“若ROS Master出故障了，則任何兩個節點之間的通信便受到影響”的問題，是以就希望使用一個“沒有中間節點”的通信中間件來代替ROS 1，那時還沒有ROS2，是以自己去做了一個Cyber RT。
為了解決ROS 遇到的問題，Cyber RT删除了master機制，用自動發現機制代替，這個通信組網機制和汽車網絡CAN完全一緻。此外，Cyber RT的核心設計将排程、任務從核心空間搬到了使用者空間。
其相對于其他系統，Cyber RT的一大優勢是，專為無人架駛設計。百度已将Cyber RT開源，某網際網路巨頭的自動駕駛團隊使用的中間件便是百度開源出來的Cyber RT。
Cyber RT跟ROS 2之間也存在競争關系。
在談到AUTOSAR AP、ROS 2與Cyber RT這些中間件的關系時，Vector産品專家蔡守群的解釋是：
“不需要很機械地去分類，你可以把AUTOSAR AP, ROS和Cyber RT都想象成一個提供一組中間件的超市，使用者可以按需從不同的超市購買，并不是說從一個超市買過一個中間件，就不能從其他超市買了。
蔡守群說：AUTOSAR AP中也包含了對ROS接口的支援。說不準哪天ROS和Cyber RT就會加入AUTOSAR AP的元件，或者AUTOSAR AP會引入Cyber RT的元件。
4.DDS（通信中間件）
（1）什麼是DDS？
在自動駕駛領域，中間件的功能涉及到通信、子產品更新、任務排程、執行管理，但其最主要的功能就是通信。目前市場上，無論是Cyber RT還是 ROS，基本上90%的功能就是通信，狹義上說就是通信中間件。
通信中間可以分成開源和閉源的兩種。開源的為OPEN DDS、FAST DDS、Cyclone等，閉源的就RTI的DDS和Vector的SOME/IP。DDS的全稱為Data Distribution Service ，指一種資料分發服務标準，由對象管理組織(OMG)制定。
DDS能夠實作低延遲、高可靠、高實時性的資料融合服務，能夠從根本上降低軟體的耦合性、複雜性，提高軟體的子產品化特性。高等級自動駕駛現在基本上都在探索依靠DDS來解決異構通信、低延遲時間等CP解決不了的挑戰。
融合了DDS的汽車軟體能夠更好地運作在下一代汽車的體系架構中，更能降低開發的成本、縮短研發的時間，更快地将産品推向市場。
（2）DDS與ROS 2、AUTOSAR AP之間的關系
ROS 2和Cyber RT的底層都使用了開源的DDS，将DDS作為最重要的通信機制。但也有自動駕駛公司的工程師認為，DDS可以起到替代ROS 2的作用，站在使用者的角度看，兩者之間其實存在“二選一”的關系。
AUTOSAR CP裡一直沒有包含跟DDS有關的東西，但AUTOSAR AP在 2018年3月的最新版（版本18-10）裡開始支援DDS标準。将DDS與AUTOSAR AP結合使用，不僅可以保證和擴充AUTOSAR AP系統内部互操作性的功能，而且還可以将其開放給來自不同的生态系統（即ROS 2）。
從工程角度來看，将AUTOSAR和DDS結合起來的最大優勢是，功能域和網絡拓撲不再是對手，而是車輛中的盟友。網絡拓撲結構能夠更好地适應車輛的實體限制，功能域在實體車輛的頂部提供了一個靈活的覆寫層，這就是所謂的分區體系結構。
當然，DDS僅是通信中間件的一種。關于各類通信中間件之間的異同，我們将在本系列的第二篇做更詳細的闡釋。
三．AUTOSAR AP的地位正在弱化？
盡管AUTOSAR是當下最有名的自動駕駛中間件，但《九章智駕》在對諸多中間件廠商們的調研中得出一個結論：AUTOSAR在産業鍊中的地位可能正在弱化。 當然了，那些專注于AUTOSAR系統的廠商們并不認同這一觀點。
我們在上文已經提到，随着EE架構從分布式向集中式演進、MCU被SOC取代，CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大勢所趨，在下文，我們主要談的是“AUTOSAR AP的地位會不會弱化”。
2021年12月中旬，兩家AUTOSAR發起公司大陸集團、豐田聯合采埃孚、捷豹路虎、沃爾沃、海拉等多家汽車行業龍頭企業宣布投資車載作業系統初創公司Apex.AI，而Apex.AI的主力産品Apex.OS則是基于ROS 2發展起來的。
拿到了Apex.AI公司15%股權的采埃孚方面在接受媒體采訪時說：“這意味着，我們可以為客戶提供AUTOSAR AP的替代方案。”
盡管AUTOSAR AP已經有了标準，但還沒有落地。安波福、采埃孚、大陸這些公司提供的方案，仍然是基于AUTOSAR CP标準的接口。事實上，越來越多的OEM不太想完全用AUTOSAR去解決智能駕駛作業系統的問題。
不僅特斯拉沒有用AUTOSAR AP,國内的幾大造車新勢力也沒有用(他們用的是AUTOSAR CP+DDS)。甚至，連一些正在轉型的傳統車企也沒打算用AUTOSAR AP。
從産業鍊中各方的反應來看，AUTOSAR AP“地位不穩”的原因主要有以下幾個：
1．使用成本太高
馮占軍博士在《AUTOSAR對基礎軟體開發是喜還是憂？》一文中透露，AUTOSAR的費用通常是“幾百萬起”，并且，針對不同的域控制器、不同的晶片需要“重複收費”，一般小廠根本吃不消。“可能還沒有什麼産出，幾百萬就花出去了”。
除購買成本高外，畢曉鵬和蕭猛都提到，AUTOSAR前期的學習難度很大、學習成本也非常高。為了學會如何使用AUTOSAR,企業甚至不得不專門教育訓練一批人,如果受教育訓練的人臨時離職了，那教育訓練費用就打了水漂。
2.效率不高
畢曉鵬認為，AUTOSAR AP的配置非常多，它是通過配置加上一部分代碼去實作自己的功能，但配置多了之後，效率不高，而且代碼臃腫。
3.靜态部署與動态部署的理念沖突
畢曉鵬博士提到，AUTOSAR AP其實是從AUTOSAR CP發展而來的，AUTOSAR CP是靜态部署，隻适用于相對簡單的業務邏輯和功能，其代碼是固化的，有點像以前的功能手機——功能無法改變，不可能往裡面再加一個APP；但AUTOSAR AP有點像現在的智能手機，軟體開發人員開發一個APP，跨平台就可以用不同手機上了，這種動态部署的理念和之前的靜态部署概念不甚相同，而其方法論卻是基于靜态部署衍生而來的，是以在實踐層面會遇到不少問題。
4.無法滿足智能網聯的需求
由于雲端跟車端所使用的作業系統不一樣，AUTOSAR隻能負責車内的通信，不能支援車端到雲端的通信，因而無法支援車路協同場景（車端跟雲端的通信，是通過MQTT、kafka等中間件來實作的）。除此之外，AUTOSAR能否相容車輛網聯化中需要用到的資料平台、通信平台和地圖平台，也存在很大的疑問。
畢曉鵬說，在發現了這些問題後，有一些OEM開始逐漸放棄AUTOSAR架構，“轉而自己去研發一套更适合動态部署、成本較低的新型軟體架構”。
傳統車廠是從使用CP過來的，是以在慣性上，他們可能還會考慮AP是否适合智能駕駛，但慢慢地也在嘗試轉型。如奧迪和TTTech合作做的通信中間件——zFAS，也沒有采用AP。
不同于AUTOSAR CP已經是非常标準化的東西，大家用起來沒什麼問題，AUTOSAR AP現在的标準也不是很完善，每年也在更新，具體AP能發展成什麼樣，這個誰也不知道，大家更多也是觀望的态度。
畢曉鵬認為，AUTOSAR标準并不能很好地支撐自動駕駛應用和創新的發展，是以，我們有必要建立一套更适合中國智能駕駛發展、且自主可控的技術架構和生态體系。
蕭猛認為，由于從AUTOSAR CP到AUTOSAR AP一脈相承，一些已經對AUTOSAR形成路徑依賴的公司會堅持使用AUTOSAR AP,但在經曆過招人難、開發周期長等教訓之後，他們有可能轉向ROS 2。
當然，以AUTOSAR為主業的公司，顯然不會認可上述“涉嫌唱衰”AUTOSAR AP的觀點的。
比如，Vector蔡守群就認為，AUTOSAR AP隻會越來越重要，因為它是順應車載技術不斷發展的一套規範，覆寫面會越來越廣。
東軟睿馳茅海燕也認為，要将整車域控制器和智駕域控制器合并到統一的中央計算平台上，沒有AUTOSAR AP的支援很難搞定。“不是每家公司都能像特斯拉一樣自己從頭搭建系統的，目前,最好的工具還是AUTOSAR AP”。
智能駕駛行業報告專題調研