自動駕駛軟硬體解耦技術及趨勢探究

「在軟體定義汽車的時代背景下，軟體的地位越來越高，智慧汽車產業發展需要實現軟硬體解耦。」

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

但是，標準依舊難以統一，各家的介面依舊各不相同。即便這麼幾年過去了，軟硬體解耦還是面臨重重困難。

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走向邊界模糊的關係。

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

然而，儘管軟硬體解耦的口號已經喊了好幾年，但效果並不理想。

感測器、晶片與演算法解耦困難

#由於演算法和感測器高度綁定，在實際應用中，這樣的綁定對演算法工程師造成了不小的麻煩。例如一輛車之前用的攝影機從200萬像素的換成800萬像素的之後，演算法也不得重寫一遍。

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

「即使有能力實現感知演算法和感測器的解耦，在解耦之後 如何對感測器做標定，也特別難。」

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

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

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

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

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

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

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

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

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

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

02 軟硬體解耦面臨的技術困境

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

#

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

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

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

除此之外，時間和地點對資料傳輸也會有影響。例如在高速上，Autosar AP 對資料傳輸頻寬就會有較高要求，這時，頻寬傳輸協定和資料共線傳輸之間的衝突就會特別明顯。在假日期間，頻寬使用集中，負荷過高，就可能無法滿足資料傳輸需求。

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

03 軟硬體解耦面臨的商業困境

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

專業中介軟體廠商

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

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

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

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

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

供應商

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

演算法公司

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

某演算法公司工程總監：

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

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

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

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

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

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

某演算法公司資深總監說：

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

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

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

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

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

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

「我們會和供應商簽保底的服務協議，也就是說一旦出了嚴重的品質事故，儘管車廠是第一個責任人，但我們自然也會第一時間讓這些供應商負責。如果演算法公司開發了中間件，那麼一旦涉及到責任，他們幾乎無法逃避責任，我們也不會允許他們逃避責任

晶片廠商

## ##########晶片廠商做中間件的目的是為了展現晶片的性能。 ############從技術的角度看，晶片廠商做中間件的難度要比演算法公司低。因為，演算法公司需要針對不同晶片做適配，工作量要遠比晶片廠商做中間件更複雜，而晶片廠商做的中間件只要能跟他們自家的晶片適配就好了。 ############儘管如此，在實務上，晶片廠商開發出來的中間件，用的人卻很少。 ############目前，已知在做中間件的主體就包括了中間件廠商、演算法公司、晶片廠商和主機廠，中間件的市佔率是分割得很細的，競爭激烈。這時候如果要開發完整的中間件，開發出來的中間件該賣給誰？是否能真正透過中間件獲利？都成為了在開發中間件之前需要考慮的問題。 ############某演算法公司專家說：#######

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

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

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

主機廠

#對主機廠來說，中間件的客製化需求是一直存在的。

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

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

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

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

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

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

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

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

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

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

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

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

04 中介軟體正在「背離初心」

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

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

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

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

#「每一種車型或每一個晶片平台對中介軟體的適配能力是不一樣的，提供的底層軟體對中間件的適配能力也不同。如有的車輛使用QNX作業系統，有的使用Linux作業系統，這兩個作業系統對於中間件就會有一些客製化的內容。

「除了底層作業系統外，軟體應用層對於中間件也會有一些差異化的需求，例如基於某一個平台上面，需要開啟某些特殊的通訊方式，有的需要傳輸資料並不是走傳統的乙太網路這種通用的鏈路，而是走PCIe或記憶體等特殊的鏈路，這就需要對中間件進行定制，使中間件能夠支援不同鏈路的通訊需求。

「有的自動駕駛軟體廠商或主機廠有自己的日誌記錄方式，有的可能沒有，就需要有中間件來提供一個日誌記錄能力，所以根據不同用戶本身俱備的能力，中間件會產生對應的客製化。」

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

而客製化的中間件又讓演算法對資料的解析產生了新的困難。

某主機廠工程師直言：

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

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

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

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

05 到底要如何才能實現軟硬解耦呢？

那麼，如果要實作軟硬體解耦，可以從哪些角度著手去做呢？

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

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

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

2、中介軟體廠、主機廠和供應商形成中介軟體聯盟，由晶片廠或主機廠主導統一規則。在市場邊界的試探中，由一家極強的主機廠或晶片廠牽頭，形成產業聯盟統一標準，將OS、介面等全部統一，形成產業規範。

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

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

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

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

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

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

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

06 最後說兩句

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

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

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

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

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

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

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

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

以上是自動駕駛軟硬體解耦技術及趨勢探究的詳細內容。更多資訊請關注PHP中文網其他相關文章！