<th id="bfrze"></th>

    <button id="bfrze"><object id="bfrze"></object></button>

      1. <em id="bfrze"><acronym id="bfrze"><u id="bfrze"></u></acronym></em><button id="bfrze"></button>

        蓋斯特研報:智能汽車EEA最新發展趨勢與實施策略研究(下篇)
        2024-06-03 關鍵詞:智能汽車,EEA,發展趨勢 點擊量:482

        六、EEA的演進將分成幾個階段?


        前面談到集中化是EEA的總體演進趨勢,具體來看,實現智能汽車EEA的整體進化,不僅需要邏輯集中和物理集中雙管齊下,還需要實現邏輯集中與物理集中的協同。實際上涉及到的內容很多,所以不可能一蹴而就,需要分步實現。


        1.邏輯集中


        邏輯集中意味著軟件系統規模更大、更復雜,因此需要更先進的軟件資源管理和交互技術。在傳統的嵌入式軟件系統中,“I/O控制軟件”與“邏輯處理軟件”被混雜封裝在一起,沒有明確的邊界,這個階段也稱為“軟軟耦合”。

        在談論邏輯集中之前,我們首先要區分“邏輯處理類軟件”和“I/O控制類軟件”?!斑壿嬏幚眍愜浖敝饕溉诤蠜Q策、人機交互、功能組合等包含復雜邏輯策略的應用和算法,“I/O控制類軟件”主要指信號路由、數據預處理、執行驅動等與硬件高度相關的驅動類軟件。強調二類軟件區別,是因為“邏輯集中”中的“邏輯”其實指的就是“邏輯處理類軟件”,此類軟件直接面向用戶需求進行開發,具有更多的數據橫向打通和組件復用的需求,天然就傾向于實現集中,而“I/O控制類軟件”與硬件高度相關,其集中與否由硬件決定而非用戶需求。

        邏輯集中的第一步就是要實現“軟軟解耦”,需要把“邏輯處理軟件”與“I/O控制軟件”通過分類分層的封裝方式來解除綁定,進而允許不同“邏輯處理類軟件”之間能夠實現打通和融合。

        第二步是“功能集聚整合”,即把原本負責不同功能的多套軟件系統集聚整合為一個系統。軟軟解耦后,理論上“邏輯處理類軟件”與“I/O控制類軟件”已經可以部署在不同的硬件上,但在實際工程開發中,考慮到對既有軟件的繼承,一般不會直接徹底打散重構整個軟件體系。此階段一般先繼續保持“邏輯處理類軟件”與“I/O控制類軟件”在一個系統內,只對“邏輯處理”部分進行繼承、融合與再開發,比如將AEB(緊急制動系統)、ACC(自適應巡航系統)、LKA(車道保持系統)等多個駕駛輔助功能整合升級為NOA(自動導航輔助駕駛)功能。

        第三步是邏輯集中的理想階段——“邏輯-控制分離”,即“邏輯處理類軟件”與“I/O控制類軟件”分別集中成兩個軟件系統并分別部署?!斑壿嬏幚怼边@類需要大算力的軟件可以部署至中央計算平臺,而“I/O控制類軟件”則可以部署至更靠近相關硬件的位置,這樣可以最大程度實現同類型算力需求的集中,減少硬件異構集成帶來的額外成本。

        例如,如果需要在一顆智能駕駛SoC上同時運行“環境感知”和“底盤控制”兩類軟件,前者更需要AI算力,而后者只需要CPU算力,那么SoC的設計必須兼顧兩者;如果將“底盤控制”軟件部署在一顆單獨的MCU上,那么SoC的研發和資源冗余就能得以簡化。


        2.物理集中


        相較“邏輯集中”的三個階段,“物理集中”整體可以分為“分布式”、“域融合”、“跨域融合”、“中央計算+區域控制”以及“車云一體”五個階段?!拔锢砑小钡难葸M過程對計算和通信等硬件性能的要求不斷提升,具體參見圖3。



        圖3 EEA物理集中的分階段演進


        從“分布式”到“域融合”再到“跨域融合”,目標是先用5-7個DCU(功能域控制器)取代掉各自域內的ECU,再進行跨域的計算整合將控制器數量縮減至3-4個。對于跨域的計算整合有不同的方式,有的車企按照功能域與功能域進行整合開發MDCU(多域控制器),有的車企則按照功能硬件的物理空間距離進行整合開發ZCU(區域控制器)。

        “中央計算+區域控制”階段是一個分水嶺。在此之前控制器使用SoC芯片或MCU芯片,主要考慮物理集中的繼承關系,假如原控制器就使用了MCU芯片,那么集中后的新控制器往往繼續使用MCU芯片。但到了“中央計算+區域控制”階段,車載計算架構已經重構,讓SoC芯片居中用于中央計算集群/平臺,負責大算力任務;MCU芯片則用于VIU(區域信息單元),負責與硬件控制相關的任務,這樣的計算明確分工能有效簡化硬件設計并提高計算效率。同時,VIU由于運算任務相對簡單可以實現標準化,這樣允許車企針對不同車型來靈活配置所需的數量,大大提高了架構的靈活性和通用性。

        “中央計算+區域控制”階段還可以根據“中央計算”的集中程度進一步細分為“多盒(Multi-Box)”、“單盒多板(One-Box)”、“單板多芯(One-Board)”和“單芯(One-SoC)”四個小階段,這一集中過程除了依賴芯片硬件層面集成設計技術的突破之外,板間互連、片間互連、片上互連等通信技術的進步也是關鍵。

        最終,根據半導體行業“摩爾定律”的發展情況,可以預見在“單芯”階段將出現的瓶頸,因為車端算力不可能無限增長來滿足所有應用場景需求,智能汽車終將迎來“車云一體”式架構。到了“車云一體”式架構階段,部分車端算力將轉移至路端或云端,車路云多端算力通過V2X(車聯網)打通并實現協同計算,由此將EEA的物理空間范疇從車內拓展至車外。


        3.邏輯集中與物理集中協同


        綜合上述邏輯集中與物理集中的演進路徑不難發現,物理集中實際是邏輯集中的支撐,邏輯集中是發揮物理集中價值的關鍵,兩者相互協同才能實現最優的EEA。雖然其中涉及到很多的軟件和硬件,但是軟件最終要部署在硬件上,部署的過程就是成本和效率的優化過程。

        筆者認為,邏輯集中與物理集中存在一個最優匹配關系,如圖4所示。筆者還標注了各大車企在EEA方面的相關進展信息??梢钥吹?,傳統燃油汽車采用的EEA是分布式物理布局,邏輯層面也是很典型的軟軟耦合的嵌入式軟件。當到了物理集中的“域融合”和“跨域融合”階段,實際上車企都是使用相應的集中式控制器來支撐相應“功能集聚整合”后的軟件運行。特斯拉早在2021年實現了區域集中EEA量產,即使今天其比較先進的EEA仍被視為行業標桿。隨著物理維度的進一步集中,“中央計算+區域控制”正好與邏輯維度的“邏輯-控制分離”相匹配,由“中央計算”承擔復雜的“邏輯處理類軟件”,“區域控制”承擔與硬件高度相關的“I/O控制類軟件”。



        圖4 EEA物理集中分階段演進


        然而,理想與現實之間總有差距,實現邏輯集中和物理集中的最優匹配并不容易,常常處于不匹配的狀態。這種不匹配現象在“域/跨域集中式架構”階段,常見于某域/跨域控制器硬件已經完成了開發,而軟件層面無法將部分功能整合進來,導致車內ECU數量并未減少甚至還有所增多。但是,后果更為嚴重的不匹配則體現在“中央集中式架構”階段,這往往反映出企業的研發目標與現有實力的不匹配。

        圖4中列舉了兩個例子。第一個是某科技巨頭的概念架構,該企業早在2020年就提出了“邏輯-控制分離”的目標,當時控制器的硬件水平不足以支撐實現這一目標。也就是說,物理集中落后于邏輯集中,這導致部分傳感器、執行器仍然需要直接接入中央計算集群,使“中央計算”的硬件設計成本明顯增加,最終該企業的相關量產產品并未按照其概念架構來設計;第二個例子是某企業于2023年宣布實現了“中央計算+區域控制”的EEA 3.0量產,從其公開的技術資料了解到,其尚未實現I/O控制與邏輯處理的完全分離,仍然有很多“邏輯處理類軟件”部署在VIU上,這就是邏輯集中落后于物理集中的典型案例。

        圖5展示了不同EEA集中化階段的軟件在不同硬件上的部署方式。筆者將“分布式EEA”定義為1.0階段,“域集中式EEA”定義為2.0階段,“中央集中式EEA”定義為3.0階段。從圖5中可以看出,從“域集中”到“多域/區域集中”,軟件的部署方式沒有本質性變化,企業要做的是開發更強大的控制器以及整合更多的功能,因此即使物理和邏輯暫時不匹配也是走在正確的方向上。



        圖5不同EEA集中化階段下的軟件部署


        需要注意的是,“部分區域化”(所謂2.9階段)的兩個軟件部署例子,可以說是既不承上、也不啟下?!拔锢砺浜笥谶壿嫛睂е隆爸醒胗嬎恪钡能浖軜嬙O計必須額外為硬件控制考慮很多安全性要求,不利于軟件的靈活迭代;“邏輯落后于物理”導致“區域控制”的硬件設計無法標準化復用,面向不同車型需要費時耗力重新適配,成本投入產生極大浪費。這種“總有一方拖累另一方”不僅體現在技術層面,還體現在技術背后的組織團隊,而團隊之間的沖突與拉扯有可能讓企業在很長一段時間都處于“3.0階段就在眼前,但一直在2.9階段打轉”的狀態。


        七、集中式EEA演進面臨著哪些挑戰?


        如前所述,推動EEA向集中化演進必須做三件事:邏輯集中、物理集中、軟硬協同。這三件事分別對應了企業的三項能力:軟件整合與打通能力、集中化硬件開發能力和軟硬件垂直集成能力。但是其中每一項能力都面臨著技術和整供企業分工合作模式的雙重挑戰。


        1.軟件整合與打通能力


        邏輯集中必然使軟件系統更加復雜,這需要管理調度能力更強的OS內核,負責管理軟件資源,以及更靈活高效的中間件來幫助軟件打通。目前OS內核在技術上主要有兩方面挑戰,一方面是汽車上硬件種類多樣,現有的OS尚無法兼容全部的驅動;另一方面是不同軟件對OS內核的性能需求不同,現有的OS產品難以同時兼顧。目前阿里、華為等科技公司以及極少數整車企業正在嘗試研發或改造車載OS內核,但這種研發投入巨大,資源分散反而容易拖累整體技術進展。

        對于中間件,雖然目前尚未打造出足夠安全、高效、靈活的量產產品,但不存在明顯的技術瓶頸。正是因此,軟件供應商和車企都在相關研發上大量投入,且各有優劣。軟件供應商雖然專業性更強,在中間件方面的技術積累更多更快,但短時間內很難將產品平臺化、通用化,難以同時服務好多家車企;相反,車企自研的中間件能夠更好地滿足自身需求。因此,圍繞中間件的整供博弈仍將持續。


        2.集中化硬件開發能力


        物理集中的核心能力是開發高集中度的域控制器或計算平臺,而這又可進一步分為核心SoC芯片層面的開發和計算平臺層面的開發。對于SoC,芯片企業無疑具有明顯的技術優勢,但也有極少數車企能夠自研SoC,并與自研算法更好地協同。相較而言,車企更擅長在計算平臺層面的開發,而應將供應商具有更成熟的量產開發經驗。

        綜合來看,車企自研集中化硬件是期待能夠實現更好地軟硬協同,從而降低對硬件資源的需求,從這個角度看,車企自研芯片是具有合理性的,但是研發周期長,不確定性較大;即使最終研發成功,量產規模能否攤平高昂的研發成本仍然是一個問題。因此,車企很可能仍需要借助專業芯片企業的能力,并探索新的整供合作模式。


        3.軟硬件垂直集成能力


        想要將高度復雜的軟件集成在高度集中的硬件上,是一個難度極大的工程問題。從任務內容上看,車企是最適合負責軟硬件垂直集成的主體,但是其在傳統燃油車時代缺少經驗積累而高度依賴供應商,導致車企的實際能力與需求存在較大的差距。

        從供應商的能力現狀上看,目前主流一級供應商一般只能提供單個功能域的軟硬集成方案,少數零部件巨頭具備跨域的軟硬件集成能力,而對于未來的中央集中式架構下的整車級集成,幾乎不可能由供應商實現。

        從車企的能力現狀上看,大部分車企停留在單功能域垂直集成的水平,極少數車企能夠實現跨域的軟硬件集成,因此整車企業在這方面還有很多功課需要補上。如果繼續依賴供應商,那么路將越走越窄。


        八、整車企業如何推動集中式EEA的落地?


        車企在研發和量產集中式EEA時,需要綜合行業整體水平與自身能力制定適合自身的EEA演進路徑。筆者建議車企注意以下三方面問題:


        1.根據實際情況選擇EEA集中化程度


        在制定EEA集中化戰略時,過于落后于行業就容易被市場競爭淘汰;而過于先進,容易超出自身能力可以控制的范疇。車企需要牢記:沒有最好的架構,只有最適合自己的架構。所以車企需要根據實際情況來選定適合的EEA架構發展策略。

        首先,對于域集中式EEA,目前各類軟硬件技術已能夠滿足行業需求的平均水平,部分供應商甚至能夠提供完整的域級解決方案,大部分車企或多或少都已具備域級軟硬件的開發和集成能力。筆者建議所有車企都應將EEA至少升級到此階段,并逐步擺脫對域級供應商的依賴,自主實現軟硬件垂直集成。

        其次,對于跨域集中式EEA,目前在硬件層面,已有多家芯片企業推出了艙駕一體的芯片,雖然在成本和性能上可以進一步優化,但也算滿足了基本需求;在軟件層面,艙駕融合所需的OS和中間件技術,預計還需1-2年才能成熟。對于不同企業來說,傳統車企在車控功能域上有較多積累,而在智駕和座艙上更依賴供應商;造車新勢力則在智駕、座艙領域投入較多,相關能力掌握較強;還有少數巨頭車企具備全棧自研能力。

        因此,筆者建議傳統車企應優先實現車控域的跨域集中,艙駕融合可以考慮與供應商合作;造車新勢力則應優先自主開發艙駕融合的核心方案;而具有全棧自研能力的車企可以選擇走更為靈活的區域集中路線。

        最后,對于中央集中式EEA,目前硬件層面僅有Muti-Box和One-Box的方案趨向成熟,軟件層面要實現真正的“邏輯-控制分離”還需要很長的發展期,并且尚無車企能真正將整車軟件整合至一個大的系統內,并將其部署至中央計算集群上。因此,筆者建議車企不應該急于推出“形似神不似”的“中央計算+區域控制”架構,而是先在跨域融合階段積累軟硬件能力與經驗,并推進下一代架構的預研,等待各方面條件都成熟時再考慮量產。


        2.基于平衡思維設計EEA


        EEA的設計需要做出各種平衡,可以說是追求平衡的藝術,主要體現在“體驗”和“成本”、“現在”和“未來”、“共性”和“個性”三方面的權衡上。

        對于“體驗”來說,EEA提供了計算和通信的硬件支撐,其技術的先進性決定了用戶體驗的上限,但這種先進性將造成更高的“成本”。因此,EEA的設計切勿盲目堆料,而要根據品牌定位與目標用戶來選擇最優性價比。

        “硬件預留”是平衡“現在”和“未來”的關鍵。如果預留多了容易讓消費者產生“白花錢”的感覺,而預留少了將使得汽車后期難以持續升級迭代。想要合理預留就要求架構師既能對未來技術變化有比較精準的預測,又能對用戶的接受程度有比較好的把握。

        前文已有提及,EEA設計應能做到跨車型、跨品牌、跨平臺復用,從而分攤成本,這其實指的是基礎共性功能,當然不可能一套配置就滿足所有用戶對功能配置的個性化需求,所謂千人千面、千車千面。因此,EEA設計實際要做的是努力實現硬件標準化、平臺化,同時打造算力、主干網帶寬、區域控制器、功能硬件等配置可靈活調節的架構。

        要做好上述平衡,對于架構師的要求非常高,既需要了解具體的軟硬件技術,又要了解用戶需求與業務,還要具備強大的抽象化系統思考。這類人才資源極為稀缺。因此,筆者建議各車企下一步要著重招攬或培養這類稀缺的人才。


        3.面向中央集中式架構推動企業能力與產業分工變革


        目前行業已經處在從EEA 2.5向3.0邁進的發展階段,而面對高度整合、空前復雜的中央集中式EEA架構,只有車企才能主導架構的設計和資源的協同,因此車企必須盡快儲備相應能力,并及時調整分工合作模式,從而實現整車軟硬件的橫向整合與打通。筆者預測的理想情況下中央集中式架構的產業分工詳見圖6。



        圖6理想情況下中央集中式架構的產業分工


        對于“電子電氣器件”,車企應主導定義底層功能硬件的標準化接口,至少也要做到與供應商聯合定義,這樣才能實現軟硬解耦;而供電配電、通信等組件,由于功能相對基礎且單一,車企依賴供應商即可;而域控制器、計算平臺等核心計算節點,考慮到車企很難具備強大的芯片設計能力,建議車企與芯片企業深度綁定或者聯合研發,將自己的重心放在集成電路板或機盒的開發上。

        對于“電子電氣器件的連接關系”,EEA的拓撲結構必須由車企自研或主導設計,且必須與軟件架構深度協同,而線束等具體載體只需要借助成熟的供應鏈即可。

        筆者相信,在符合實際情況規劃、平衡設計以及合理分工下,企業將快速推動EEA架構發展,進而行業將加速向中央集中式的EEA 3.0進化,智能汽車的產品形態也將迎來新一階段的升華,讓我們共同期待!

        相關內容
        首頁 電話 聯系
        會員登錄
        還未注冊?點擊立即注冊
        注冊
        已有賬號?返回登錄
        亚洲人成日韩中文字幕不卡_国产精品无码专区第1页_亚洲A成人片在线播放_国内精品精彩无码视频