“在軟件定義汽車的時代背景下，軟件的地位越來越高，智能汽車行業發展需要實現軟硬件解耦。”

類似上面這樣的話想必大家都不陌生了，在智能汽車發展的這幾年里，汽車供應鏈的構成發生了翻天覆地的改變，而軟硬件解耦，則成為了無論是主機廠還是供應商都一直在想辦法解決的問題。

但是，標準依舊難以統一，各家的接口依舊各不相同。即便這么些年過去了，軟硬件解耦還是面臨著重重困難。

一．軟硬件解耦的背景

01 EE架構的演進

（對該部分主題熟悉的讀者，可以跳過，直接進入下一小節）

幾年前，一輛整車上的ECU僅僅只有十幾到二十個，但隨著電子娛樂消費主義不斷侵入人們生活的方方面面，人們對汽車的功能需求也逐步提升，而在分布式架構的背景下，每新增一種功能都需要不斷地增加對應的ECU。對于自動駕駛汽車來說，更是如此，于是，一輛自動駕駛汽車上的ECU發展到了最多近一兩百個。

ECU的不斷增加使得用于數據傳輸的線束總長度與總成本也不斷增加（根據佐思汽研的測算，如果沿用目前的分布式架構，自動駕駛汽車的線束成本將不會低于 1000 美元），供應商的管理難度也有所增加。

除此之外，分布式架構下，ACC 、AEB這些功能是跟傳感器（中的MCU）綁定的，彼此之間也是割裂的（這不符合第一性原理，人開車的時候不是這樣），而高等級自動駕駛要求是各功能之間是一個有機體，因此，需要通過同一個SoC來實現。

在這樣的背景下，如何在有限的空間里既能提高空間利用率，又能發揮ECU的最大的性能，成為了行業內下一個發展的方向。于是，汽車EE架構開啟了從分布式架構向集中式架構演進的大門，為此，域控制器誕生了 ，許多ECU開始被域控制器取代，主控芯片也從之前的MCU升級成SoC。

ECU不斷減少，汽車上余下的ECU也由原先需要承擔一部分的計算，轉變成僅需要承擔大部分執行功能并被弱化了處理能力的“螺絲釘”（ECU仍有原先處理計算的能力，只是功能上已不需要它處理部分計算）。

EE架構從分布式向域集中演進、SoC取代MCU，為汽車產業從“硬件為王”時代向“軟件定義汽車”時代的跨域創造了前提條件。

SoC芯片上集成了DSP、GPU、NPU等多個模塊，不僅擁有控制單元還集成了大量計算單元。這讓SoC芯片除了可以多任務并發外，還擁有了處理大量數據的能力。SoC芯片替換部分MCU，就像是一家公司多個部門的普通領導人被1個以一抵百的超優秀CEO取代。

在硬件為王的時代，由于軟硬件耦合程度高，整車廠首先會找咨詢公司做未來5-8年的汽車功能需求分析報告，然后再根據報告制定一個5-8年的軟硬件一體化方案。當軟件和硬件投入產線生產，直到整車廠將各種部件裝好出車，5-8年之內，這輛車無論是軟件還是硬件都很難再發生變化。

在軟件定義汽車的時代，如果仍然按照原先車廠的整合流程，一次性定下5-8年的造車方案，那么，在車輛制造的前幾年問題還不會太突出，但在這個方案時間區間的后半段，一輛車交付給用戶的汽車，車上無論是硬件還是軟件都已經遠遠過時。

因此，在產品設計階段，就應該考慮到后續的迭代問題。而要解決迭代問題，就得軟硬件分開發展。

當各家車廠的硬件配置都已趨同，硬件變得“卷無可卷”，為了實現差異化，主機廠需要能夠以非常快速的反應能力去收集用戶不斷變化的需求，并進行對應的軟件迭代。這時，主機廠有兩條路可走：一條是自研軟件和算法，自己解決所有問題，包括軟硬件解耦；另一條則是軟硬件解耦后找合適的供應商提迭代需求。

如果要走第一條路，主機廠需要非常強的實力，但并不是所有的主機廠都具備這樣的能力，所以大部分主機廠會更偏向走第二條路。于是，軟件算法公司地位開始提升，汽車供應鏈關系由原先具有分明的Tier1、Tier2、Tier3走向邊界模糊的關系。

在這樣的背景下，各家軟硬件供應商之間為了更強的競爭力、更優的獨立發展和更好的合作生態，也有軟硬件解耦需求。

然而，盡管軟硬件解耦的口號已經喊了好幾年，效果卻并不理想。

02 傳感器、芯片與算法解耦困難

由于算法和傳感器高度綁定，在實際應用中，這樣的綁定對算法工程師造成了不小的麻煩。比如一輛車之前用的攝像頭從200萬像素的換成800萬像素的之后，算法也不得重寫一遍。

另外，某Tier1的算法工程師：

“即使有能力實現感知算法和傳感器的解耦，在解耦之后如何對傳感器做標定，也特別難。”

由于軟硬件耦合度高，傳感器的數據和傳感器也是高度綁定的，一旦傳感器發生了更換，之前花大價錢做的數據標注就將全部作廢，又不得不開始新的一輪采集，這對于算法公司來說是一件非常麻煩的事，但這件事目前并沒有太好的解決方案。

此外，每輛車上的傳感器配置、安裝位置、安裝角度都各不相同，因而，算法也不盡相同。感知算法不同，規控算法就不同。

如果說算法與傳感器的解耦只是麻煩的話，那么算法和芯片的解耦就顯得十分困難。

比如筆者在與諸多算法工程師交流軟硬件解耦相關問題的時候，發現他們都有共同的痛點之一就是：由于算法移植困難，導致做了很多額外的工作。

這是由于算法遷移的頻率是無法預測的。芯片廠商的競爭與產品迭代時常會影響著市場的偏愛，你無法確定下一個風口是否又會有新的更好用的芯片熱賣。

市場偏愛的變化，又會讓主機廠指定更換不同的芯片。這時候，對于算法工程師來說，也許你基于這款芯片的算法剛改好，那邊又將面臨新的算法移植需求。

造成以上現象的原因是算法和芯片的強綁定關系。不同的芯片提供了不同的BSP，這導致用于給芯片和算法解耦的中間件難以復用，必須對不同的芯片進行不同的定制化適配。

某主機廠智能駕駛系統負責人解釋道：

“中間件跟下層BSP這一層的適配比較令人頭痛。比如座艙芯片用了高通的8155或者8295，而自動駕駛芯片用了TI的TDA4，那么由于它們的芯片所提供的BSP不同，融合時就需要對中間件去做定制化的適配。”

不僅芯片平臺的差異導致中間件不能復用，而且兩款基于同一個芯片平臺做的域控制器，如果硬件架構不一樣（有的域控上面，有2顆甚至3顆SoC），對中間件的需求也不一樣。

二、軟硬件解耦面臨的技術困境

中間件是實現軟硬件解耦所需的最重要的工具，因此，軟硬件解耦的難題，會集中體現在中間件身上。

目前的中間件其實都是需要根據功能、硬件平臺、操作系統來進行定制，哪怕是標準化再高的中間件，也是需要算法公司或者主機廠去做適配的，很難說有一個中間件能夠cover住所有的東西。因為所有的中間件都會有些限定或者限制，比如有的沒辦法快速定義通信接口，有的對于一些跨平臺的支持不是特別友好，有的則是在其他芯片上匹配不好。

而中間件從數據傳輸本身，會出現數據偏轉、數據錯誤、單模塊失效影響數據傳輸等問題。比如，數據傳輸量較大，SOME/IP做數采的時候，很多通信信號采不到，就很容易發生丟包的現象。

另外，數據回傳錯誤還會很容易造成一系列連鎖反應，最終影響決策及執行層，引發不良后果。可以說，數據共享有利有弊，理論上可提高效率，但若源頭出錯，將會引發一連串錯誤，同時也缺乏有效的診斷及糾正機制。

除此之外，時間和地點對于數據傳輸也會有影響。比如在高速上，Autosar AP 對數據傳輸帶寬就會有較高要求，這時，帶寬傳輸協議和數據共線傳輸之間的沖突就會尤為明顯。在節假日期間，帶寬使用集中，負荷過高，就可能無法滿足數據傳輸需求。

除了以上問題外，目前的中間件，還存在緩存機制沒做好、功能組不支持嵌套、狀態機協同做的得不好等問題，這些問題都需要算法工程師在已有中間件的基礎上再去做修改，這大大增加了軟硬件解耦的難度。

三、軟硬件解耦面臨的商業困境

除了上述技術方面的困境外，軟硬件解耦還面臨著一系列商業上的困境。

01 專業中間件廠商

以Vector、 RTI 、EB、易特馳為代表的中間件廠商希望能制作一套標準化、能適配于每一家的軟硬件的中間件，一步到位地實現各家軟硬件解耦的訴求。

但現實卻沒有想象中那么美好。一方面，除卻幾家中間件龍頭企業外，大部分中間件公司的的產品一時半會兒很難贏得主機廠的真正信任；另一方面，算法公司大部分也并沒有那么愿意配合中間件廠商做標準化，因為一旦接口、得逞系統被中間件廠商統一后，就意味著自家產品的可替代性增強，差異化降低，導致算法公司的競爭壓力陡然上升，因此十分抗拒。

此外，在智能汽車的各項技術發展路線尚未明晰的情況下，主機廠是希望自家車的配置跟競品有差異化來取得競爭壁壘（應用層的差異化也需要中間件的差異化做支撐），而標準化的中間件會與這個愿望背道而馳。因而主機廠寧愿自己開發中間件也不希望使用中間件公司開發的標準化中間件。

最終，這些中間件就變得很難賣出去，只做標準化中間件這件事變得難以為繼。

從九章智駕了解到的情況看，除華玉通軟等個別專注于DDS等技術壁壘很高的模塊、并且已通過長時間的積累建立起一定的競爭優勢的公司外，大多數最初定位為“中間件廠商”的公司基本都已在過去一兩年內開始轉型（向其他領域拓展）。

02 供應商

算法公司、部分軟硬件都做的Tier1和芯片廠商都開始做起了中間件，但在實踐中，家家都有一本難念的經。

2.1 算法公司

對于算法公司來說，如果他們購買的標準化中間件過于通用，就會有許多適配上的問題不能解決，但如果拿到的是黑盒交付的通用中間件，與算法不夠匹配將會給算法工程師造成很大的困難。而如果購買了定制化中間件，算法公司還需要花很多時間跟中間件廠商溝通，成本也會很高。

某算法公司工程總監：

“如果有問題，一般來說，公司會將問題報給中間件廠商，但有的廠商配合度較低，需要算法公司提供實際證據證明是中間件的問題，否則就會扯皮，這時候就比較耗費人力和時間，影響開發進程。

“尤其是，剛剛開始涉足中間件的算法公司對于中間件的理解并不是特別專業，找到實證比較麻煩，將會耗費更多時間；而這個過程如果是幾方配合的話主機廠還得出人做協調，這又會導致解決問題的進度被進一步拉長。”

于是，算法公司干脆選擇自研中間件來更好地匹配自己的算法。

另外，國際中間件廠商的中間件價格昂貴，而國內初創的中間件廠商做的中間件，可能還比不過自己根據自己的算法所研制的中間件更為適配，也是算法公司自研中間件的原因之一。

“如果自研，我對我項目需求更了解，會不會比讓中間件廠商去開發更好呢？”某算法公司系統架構工程師道。

除了以上這些外，算法公司自研中間件還有一個原因：各家算法公司的算法差異小，需要通過自研中間件來形成產品的差異化。

某算法公司高級總監說：

“目前，各家算法的差異性很難體現出來，都是用C、C++編程，要體現差異性就要在中間件上面把性能做起來，要把可靠性做起來，也就是增強功能體驗上的一些優勢。”

然而，算法公司自研中間件，也遇到了不少挑戰。首先，主機廠自研中間件是可以對供應商提標準的，而算法公司如果自研中間件，就很難說服主機廠和其他供應商去適配自己的標準。

正如某L4公司軟件總監所說：

“比方像蔚來小鵬他們自己去做中間件，因為他是整車廠，他可以定一套標準去約束他的供應商；但是如果是自動駕駛算法公司去做配套中間件，無論是說服整車廠，讓整車廠相信你這套東西可以套用在別的域上，還是說服主機廠的其他供應商去按自己的標準做融合，都很難。”

另外，當算法公司自研中間件之后，如果出了問題，就無法甩鍋了，因此對于算法公司來說，中間件就需要做得更好。

某主機廠的智能網聯總工程師表示：

“我們會和供應商簽保底的服務協議，也就是說一旦出了嚴重的質量事故，盡管車廠是第一責任人，但我們自然也會第一時間讓這些供應商負責。所以算法公司如果做了中間件的話，到了該承擔責任的環節，他們基本上就逃不了，至少我們也不會讓他去跑”

2.2 芯片廠商

芯片廠商做中間件的目的是為了展現芯片的性能。

從技術的角度看，芯片廠商做中間件的難度要比算法公司低。因為，算法公司需要針對不同芯片做適配，工作量要遠比芯片廠商做中間件更復雜，而芯片廠商做的中間件只要能跟他們自家的芯片適配就好了。

盡管如此，在實踐中，芯片廠商開發出來的中間件，用的人卻很少。

目前，已知在做中間件的主體就包括了中間件廠商、算法公司、芯片廠商和主機廠，中間件的市場份額是被分割得很細的，競爭激烈。這時候如果要開發完整的中間件，開發出來的中間件該賣給誰？是否能真正通過中間件實現盈利？都成為了在開發中間件之前需要考慮的問題。

某算法公司專家說：

“我們通常不會用芯片公司的中間件，因為他們做中間件更多是為了生態，他們的中間件功能可能更多，但性能不一定最優。也就是說， 中間件做的功能很多，包括AI的抽象、數據記錄的回放、點云的處理，可能全部做了，但這種情況下會存在一個問題 —— 本來是算法要做的事情，中間件全部做了，性能就不能完全保證，并且它還要兼顧多家算法公司的需求，靈活度也會變差。”

可以看到，雖然部分芯片廠商是有能力做好中間件的，但是考慮到市場競爭壓力大，還需要投入大量的人力物力去研發，有能力的芯片廠商大部分沒有動力投入太多去做好中間件，而是更愿意專注于做好芯片本身。

所以，大部分芯片廠商的自研中間件做得很輕，做的基本是能夠在芯片上跑起來的demo中間件，以此來向客戶展示芯片的性能。這樣的demo中間件，當然對軟硬件解耦不會起到什么實質性幫助。

03 主機廠

對于主機廠來說，中間件的定制需求是一直存在的。

某主機廠的智能駕駛系統負責人舉例道：

“比方說在寫紅綠燈識別算法或雙目視覺算法時，如果要區別于傳統算法或競爭對手的算法，就需要一套定制中間件，這涉及到中間件的數據訂閱、共享、錄播、回放、發送、存儲、診斷等各個功能。但這些功能不能保證在主機廠所需要體系下或功能機制下完美運行，有可能會發生沖突，這個時候就需要中間件供應商來協助打通。”

但是，相比于使用第三方中間件公司或算法公司的中間件，部分能力較強的主機廠會更愿意自研中間件。

首先，購買閉源的中間件如RTI的DDS，往往意味著中間件定制化，不僅會需要更加昂貴的成本，而且項目的對接周期也會拉得很長；相比之下，自研中間件意味著能夠完全掌控定制化的方向，拿到自己的數據，使產品不受限制，這樣能夠更好地掌控產品的開發進程和后期改造，解決可能因為某個中間件供應商掉鏈子而導致量產交付延期的問題。

其次，自研中間件對于主機廠來說，還可以形成一定的技術壁壘的。對于部分實力強勁的主機廠來說，一些上層的應用層也是完全掌握在自己的手里的，根據自己上層應用的需求去做自己的中間件，能夠更好地做一些中間件的定制化，上層應用也能做出一些特色。

其實，在中間件技術尚未成熟，未來趨勢尚不夠明顯的時候，行業內上下游的玩家之所以都在做中間件，一是試探自己能力的邊界，二是探索整個產業的邊界。

然而，多位主機廠的自動駕駛工程師認為 “跟算法公司相比，主機廠自研中間件優勢不大”。

首先，大多數主機廠在算法能力方面并沒有多少積累。專門組建一個團隊去做中間件所消耗的成本是巨大的，但結果可能還比不過專門做這些的供應商，這樣的消耗所帶來的痛苦程度已經遠遠超過統籌數家供應商所帶來的痛苦。這就像自己的短板項目帶來的苦惱會比自己的強勢項目上新挑戰更讓人感到痛苦。

其次，主機廠自研中間件難以得到足夠多的樣本反饋,因而不利于產品迭代。供應商的算法和中間件大家用的多，客戶基數上去了，那么客戶對bug的反饋率更高，更利于產品的迭代進步；然而，主機廠如果自研，產品僅供給自己，便很容易出現缺乏足夠的樣本數據，因而迭代得比較慢。

另外，主機廠如果要自研中間件，就勢必要從其他企業挖技術人才。然而，對于人才來說，在大公司的一個部門里做事，他們也許是沒有那么強的使命感的，畢竟總會有種“天塌下來，還有上頭的人頂著”的感覺，而最后的結果就是，挖來的人才的能力如果能發揮出80%就算是非常理想了。但同樣是這個技術人才，如果出來單干，研究的東西關系到個人的切身利益，他一定會有更大的壓力以及動力去做好這件事，這樣的環境下往往能夠發揮出更多的才能。

最后，自研中間件對于主機廠來說，是需要耗費的大量人才構建研究團隊，一旦發現這條路走不下去，這么大量的員工都將面臨著全部被裁的風險，，而大量員工被裁又會讓在職員工心里認為“公司不穩定”的情緒上漲。

這么看來，主機廠的“自研中間件”更多的時候可能只是個營銷口號，但這并不是說所有主機廠自研中間件都是無法成功的，實力夠強，能夠成功自研算法的主機廠自研中間件成功的概率還是大的。只是相對而言，對于大多數算法難以自研的主機廠們來說多，軟硬件解耦需求仍然需要由供應商來滿足。

四、中間件正在“背離初心”

中間件的誕生本是為了解決軟件和硬件無法分開發展的問題，因此，人們最初是希望中間件能成為一款起到阻隔效果的軟件，能夠精簡流程，并能夠適配于所有的軟硬件，讓上層軟件應用工程師可以不去考慮硬件的適配問題，安心做好算法。

然而，現實卻與最初的愿望背道而馳。

一方面，中間件呈現出了高強度的定制化。

某算法公司的軟件架構師介紹道：

“每一種車型或每一個芯片平臺對中間件的適配能力是不一樣的，提供的底層軟件對中間件的適配能力也不同。如有的車輛使用QNX操作系統，有的使用Linux操作系統，這兩個操作系統對于中間件就會有一些定制化的內容。

“除了底層操作系統外，軟件應用層對于中間件也會有一些差異化的需求，比如基于某一個平臺上面，需要開啟某些特殊的通信方式，有的需要傳輸數據并不是走傳統的以太網這種通用的鏈路，而是走PCIe或者內存等特殊的鏈路，這就需要對中間件進行定制，使中間件能夠支持不同鏈路的通信需求。

“有的自動駕駛軟件廠商或者主機廠有自己的日志記錄方式，有的可能沒有，就需要有中間件來提供一個日志記錄能力，所以根據不同用戶自身具備的能力，中間件會產生對應的定制化。”

定制化就意味著，無論是讓中間件廠商分人去做標準化之外的需求，還是讓算法公司/主機廠派專門的對接算法工程師去做中間件的個性化適配調整，都需要付出額外的人力物力。

而定制化的中間件又讓算法對數據的解析產生了新的困難。

某主機廠工程師直言：

“如果量產車上要上V2X，但不同品牌車型上的中間件不一樣的話，那它的QoS（服務策略）就不一樣，那對數據的解析就存在問題，因而，車車之間的通信可能存在困難。”

另一方面，“越來越多的玩家開始繞開 AUTOSAR的標準自己搞。即使同樣給予AUTOSAR標準做的中間件，定制化程度也很高。”某主機廠系統專家道。在各家都在自研中間件的當下，中間件大多只適配于自家算法、接口等，無法統一的現象也愈演愈烈。

無論是主機廠還是算法公司，比起考慮中間件是否好用、有沒有實現軟硬件解耦，真正在項目合作時考慮的更多的還是否能解決實際遇到的問題。如果買來的中間件沒能解決問題、沒有達到想要的效果，那么就還需要合作雙方在原本中間件的基礎上再修改增加各項內容，也就會形成不斷“加耦”的狀況，中間件的定制化又成為了一種必然現象。

于是，再回想起中間件最初以簡化流程、減少工作量為目的的初心，不由唏噓。

五、到底如何才能實現軟硬解耦呢？

那么，如果要實現軟硬件解耦，可以從哪些角度著手去做呢？

一方面，可以從操作系統層面先把硬件虛擬化做好，將接口、通信協議等標準化，這樣能夠使上層應用無需考慮底層系統的不同問題，但這需要芯片廠商和操作系統廠商深度合作共通完成，或是芯片廠商自研OS，因此還是存在不小的難度。

另一方面，雖然目前中間件的未來形式還尚不明朗，但有一點可以確定，軟硬件解耦仍然需要以中間件的形式解決，只是中間件可能會分化成幾種方式：

1、中間件廠商基于Autosar本身開發簡化Autosar的工具類型中間件。由于Autosar本身十分復雜，工程師的學習難度不小，如果能夠提供簡化版本的開發工具，把這種工具提供給上下游需要自研中間件的廠商，優化他們自己自研中間件的流程，也不失為一種選擇。

2、中間件廠、主機廠和供應商形成中間件聯盟，由芯片廠或者主機廠牽頭統一規則。在市場邊界的試探中，由一家極強的主機廠或者芯片廠牽頭，形成行業聯盟統一標準，將OS、接口等全部統一，形成行業規范。

3、完全開源，由芯片公司打造專屬OS，讓上下游公司在此基礎上開發。芯片廠商做出類似英偉達CUDA那樣的開源工具包，不但自己開發OS和中間件，并且完全開源，幫助上下游的客戶共通使用工具進行更好的適配開發，建立良好的生態。

4、作為一種服務，上門給供應商做中間件的定制化服務和維護工作。由于受到市場天花板低和中間件難以統一的影響，中間件也許不會成為一種獨立的產品存在，而是成為一種定制化服務。中間件廠商由于具備更優秀的中間件研究經驗，是更優于去提供這種定制化服務的玩家。

曾經，各種手機品牌百花齊放，在“板磚機”和智能機并肩齊飛的2005年到2010年，市面上流通的手機接口最多可以高達200多種。不同品牌的手機有著不同的充電接口，不同的耳機接口，形狀相同大小不同的大大小小的各種接口，甚至同種品牌的手機也有不同的充電接口。

當時的一位數碼達人出差的時候往往不得不帶上5、6種充電器和5、6根不同的線。即便后來我們擁有了萬能充電器，也只是能把板磚機的電池扒拉下來充電，智能機的充電口和大大小小不同的耳機接口無法統一的問題仍然不能被解決。

這樣混亂無序的時期，卻又是手機興起之后，手機科技發展最為燦爛而蓬勃的時候，正如現在智能汽車的發展。而今天，我們看到手機接口已經基本統一，成百上千的手機廠商，在各自自研的過程中，在市場的最終抉擇之下逐漸減少，最終形成了標準。

智能汽車行業作為深受電子消費市場的影響，特別是受手機市場影響的行業，這兩年行業內的各家都顯得十分浮躁，大家都急于去快速進展到一個終局狀態，希望能在很短的時間里選出一個集大成者。然而，汽車的制造業實際上又是一個發展緩慢的行業，從車輛的生產到量產再到投放到消費市場，最后從千萬用戶那收集使用反饋，才能不斷優化自身形成標準。而也許只有這個時候，中間件才能真正統一起來形成標準。

而未來技術成熟之后，中間件也許會作為固化在ASIC芯片上的基礎軟件，不再單獨以中間件的形式出現也未可知。

最后說兩句

不過，話說回來，當前，在各方都困難重重的情況下，中間件到底適合誰來做呢？

總體來看，如果我們是奔著用標準中間件完全實現軟硬件解耦這個目標去的話，最適合去做中間件的其實是芯片廠商。

兩個理由：一是算法的適配歸根結底是要基于芯片平臺的，芯片是基石。二是芯片公司相對于算法公司來說數量更少，統一起來難度相對更小。

但目前而言，基于各家都期望定制化的前提下，最適合做定制化中間件的則是算法公司。

“芯片企業更關注芯片本身的應用，如是否加校驗機制、BSP如何調度、加速等需求，芯片企業均可實現，但芯片企業并不能對應用軟件及中間件提出更好的優化建議，用戶端僅能使用其成熟方案，但此方案未必能夠滿足軟件的全部需求。”

可以看到，算法公司是在業務實踐中收到定制化請求最多、并被要求最多去做中間件適配的角色，能直接做適配自己算法的定制化中間件是最方便的。

某主機廠總工程師也有著相同的觀點：

“就目前而言上層功能服務相對聚焦，自動駕駛方案供應商對功能應用理解較深，從應用層下沉抽象出來中間件，能夠更好匹配底層主流的芯片硬件方案商，整體方案較為合理。”

審核編輯：劉清