《AUTOSEMO：2024中國汽車基礎軟件發展白皮書5.0（116頁）.pdf》由會員分享，可在線閱讀，更多相關《AUTOSEMO：2024中國汽車基礎軟件發展白皮書5.0（116頁）.pdf（116頁珍藏版）》請在三個皮匠報告上搜索。

1、指導單位：工業和信息化部裝備工業發展中心發布單位：中國汽車工業協會軟件分會中國汽車基礎軟件生態標委會（AUTOSEMO）中國汽車工業協會軟件分會中國汽車基礎軟件生態標委會（AUTOSEMO）地址:北京市豐臺區汽車博物館東路諾德中心11號樓33層郵政編碼：110160聯系電話:010-63979900郵箱:autosemo-網址:中國汽車基礎軟件發展報告 5.0面向 AI 大模型的開放式軟件架構序 言PREFACE全球汽車產業正面臨著能源和智能兩大方向轉型，這給中國汽車產業帶來了由大到強的發展機會。轉型的上半場是能源轉型，中國汽車產業在全球化競爭中占據了有利地位。與此同時，國內新能源汽車市場競爭

2、也日趨激烈，價格戰持續不斷。面對競爭更加激烈的下半場，各整車廠雖通過以價換市、加速車型迭代等手段積極應對，但根源上需要抓緊這一輪人工智能等新技術，形成產業革新的有效破局舉措。扎根基礎技術，需要所有從業者平心靜氣、耐得住寂寞，在高質量發展的指引下，穩步推進產品技術迭代，助力國家邁進汽車強國。智能化是汽車產業轉型下半場的核心，軟件則是智能化的關鍵，是構建差異化的整車應用和創新汽車業務的核心驅動力。目前，各廠家拼殺愈加激烈，加上市場對自動駕駛、智能座艙和萬物互聯等個性化需求的快速增長，導致廠家車型迭代、軟件開發和集成驗證的復雜度大幅增加，開發成本居高不下。這里提出一個想法如果行業內構建出開放性的軟件

3、架構作為基礎，使得其他應用或擴展都能在這個基礎上柔性生長，是否可以解決當前行業問題。對于基礎的構建，可以參考樂高模式，即立足模塊化設計理念，通過組合標準部件，實現多樣化創新。這種通用的行業標準、工具和方法，可以大幅提高開發效率，保證產品質量的穩定性，為廠家贏得時間和資源上的雙重優勢。另外，引爆本輪技術革新的核心人工智能技術正憑借其強大的數據處理、自我學習和主動生成等能力，顛覆整個汽車智能化的發展節奏和開發模式，使汽車軟件創新開發的新范式、新思路也層出不窮。在開放式軟件架構中，也需要深度融入、挖掘人工智能的能力，為汽車智能化的革新性發展筑牢基礎。國產汽車基礎軟件方面，開放式軟件架構模式近些年發展

4、迅猛，其產品力和質量均有較大提升，市場占有率也持續提高。當然，發展過程中也暴露了產品迭代頻繁、研發效率低成本高、行業低水平內卷、商業模式無法閉環等問題。為了在全球汽車產業智能化乃至生態化的競爭中搶占戰略制高點，增強中國的汽車軟件實力，AUTOSEMO 聯合主機廠、Tier1、軟件、芯片廠商和高?？蒲性核?，編制了中國汽車基礎軟件發展報告 5.0，該報告圍繞汽車智能化發展趨勢下的軟件架構，探討如何在融入 AI 大模型的情況下，打造安全、可靠、穩定的開放式軟件架構，希望可以給整車智能化軟件產業鏈參與者提供有益參考和幫助。2024 年 10 月 13 日中國汽車基礎軟件發展白皮書 5.0I一、面向 A

5、I 大模型的開放式軟件架構概述001(一)開放式軟件架構0021.開放式架構 0022.工具鏈 0033.生態屬性 003(二)AI 大模型0041.AI 大模型分類 0042.汽車行業垂直大模型 0043.AI 端側部署 006(三)面向 AI 大模型的開放式軟件架構 0061.開放式軟件架構的中間件 0072.開放式軟件架構的操作系統底座 0073.開放式軟件架構的工具鏈 0084.開放式軟件架構的生態建設 008二、開放式軟件架構的應用層009(一)車端應用0091應用場景 0092AI 大模型在車端應用的挑戰 0143AI 大模型在車端應用的演化趨勢 015(二)云端應用0151應用場

6、景 0152AI 大模型在云端應用的挑戰 0183AI 大模型在云端應用的演化趨勢 018CONTENTS目錄中國汽車基礎軟件發展白皮書 5.0II三、開放式軟件架構的中間件層020（一）開放式軟件架構的中間件 0201.面向 MCU 的標準基礎軟件 0212.面向 SoC 的標準基礎軟件0233.車輛基礎服務 0244.整車通信總線 0325.整車數據處理框架 039（二）AI 大模型與中間件 0441.AI 大模型技術對中間件的影響 0442.基于大模型的中間件 0453.AIAgent 基礎服務層 0454.AI 大模型與中間件結合的發展趨勢 046四、開放式軟件架構的操作系統底座047

7、（一）開放式軟件架構下的操作系統 0471軟硬一體 0472虛擬化 0493實時操作系統 0554SafetyLinux058（二）開放架構下的操作系統安全 0621.信息安全 0632.功能安全 065（三）人工智能與操作系統 0661.AIforOS 0662.OSforAI 0663.AIasOS 068五、開放式軟件架構的工具鏈071（一）經典工具鏈 0711.面向MCU的標準基礎軟件的開發者工具 0712.面向SOC的標準基礎軟件的開發者工具 072中國汽車基礎軟件發展白皮書 5.0III3.車輛基礎服務的開發者工具 0734.整車通信總線的開發者工具 074（二）開放的高效開發框架

8、 0751.高效開發框架的定義 0762.高效開發框架的功能 0773.高效開發框架的接口參考 0784.高效開發框架的開發方法 079（三）AI 大模型賦能創新工具鏈 0801.軟件工程變革 0802.軟件需求開發 0823.軟件架構開發 0834.軟件代碼開發 0845.軟件測試 087六、開放式軟件架構的生態建設088（一）技術生態 0881.開放式接口的統一 0882.通信協議的統一 0893.開發標準和流程的統一 0904.開源庫在汽車開發中的重要性 090（二）產業生態 0911.當前的問題與挑戰 0912.破局之道的思考 092七、AI 大模型對整車軟件發展趨勢和技術路線的影響0

9、93（一）發展趨勢 0931.算法、算料、算力與場景 0932.整車軟件開發方法的變革 095（二）技術路線 0961.基于大模型的新型軟件工藝 0962.整車軟件技術的演進方向 0993.趨勢下的技術點 099中國汽車基礎軟件發展白皮書 5.0IV（三）AI 大模型應用落地方法 100八、案例介紹102（一）軟件平臺 102（二）中間件 102（三）操作系統 103（四）信息安全 104（五）工具鏈 105主要貢獻單位107中國汽車基礎軟件發展白皮書 5.0001一、面向AI大模型的開放式軟件架構概述近年來，人工智能技術的發展進入新階段，大模型在各行各業掀起了智能化變革浪潮。在汽車領域，AI

10、（ArtificialIntelligence 人工智能，以下簡稱 AI）的技術驅動能力完美契合了當下汽車的發展需求，作為新一代智能終端，汽車的智能化發展目前有兩大趨勢：一是電子電氣架構的中央集中，艙駕控三域融合甚至五域（智能座艙、智能駕駛、車身控制、底盤控制與動力控制）融合的中央計算平臺已處于預研或上車階段其中復雜的域融合，給整個汽車軟件的研發效率、質量、擴展性和延續性等帶來了諸多挑戰，亟需開放式的軟件架構支撐。二是 AI 大模型加速應用，一方面通過對軟件工程等輔助開發，提升研發效率和質量；另外一方面則通過在自動駕駛、智能座艙等控制器的端側部署，為用戶帶來全新體驗，這些也對目前的軟件架構帶來

11、了新的挑戰。本報告圍繞汽車智能化發展趨勢下的軟件架構，探討并關注如何在融入 AI 大模型的情況下，打造安全、可靠、穩定的開放式軟件架構，以及該架構中的關鍵技術、實踐案例與發展趨勢，旨在為整車智能化軟件產業鏈參與者提供有益的指導和參考。報告中各章節核心闡述內容如下：第一章面向 AI 大模型的開放式軟件架構概述：介紹了 AUTOSEMO（中國汽車工業協會軟件分會中國汽車基礎軟件生態標委會，以下簡稱 AUTOSEMO）的開放式軟件架構，闡述 AI 大模型的發展已可以深度融入開放式架構并對其發展起到促進作用，從而形成面向 AI 大模型的開放式軟件架構這一持續迭代發展的架構方案。第二章開放式軟件架構的應

12、用層：主要介紹了 AI 大模型在當前汽車智能化應用中的發展情況、挑戰和技術趨勢。第三章開放式軟件架構的中間件層：主要介紹了開放式架構下的中間件，包含標準中間件、車輛基礎服務、整車通信總線和整車數據處理框架以及 AI 大模型與中間件的結合。第四章開放式軟件架構的操作系統底座：結合應用場景，介紹開放式軟件架構下的操作系統如虛擬化、SafetyLinux（功能安全 Linux 操作系統）和實時操作系統的技術重點和演進趨勢；同時聚焦開放式軟件架構下的操作系統安全問題，如信息和功能安全問題及演化趨勢；其次，聚焦 AIOS（人工智能操作系統）這一全新概念，探討當前發展現狀和未來趨勢。第五章開放式軟件架構的

13、工具鏈：探討多域融合背景下，通用的汽車電子研發工具鏈以及用于解決如何更好地多方協同、提升開發效率和質量，同時支持 AI 擴展的高效開發框架。最后介紹應用于整個汽車軟件工程的 AI 大模型工具鏈。第六章開放式軟件架構的生態建設：從技術生態和產業生態兩個維度，分析如何通過行業共建，構建技術標準和開發流程、建設開源庫、保證可持續發展；此外通過構建分層解耦的協作關系，確保行業各層級可以各司其職、正向迭代發展。第七章AI 大模型對整車軟件發展趨勢和技術路線的影響：對汽車行業深度融合 AI 大模型所帶來的變化進行深入分析，引出對行業趨勢和技術路線的思考，繼而探討大模型應用的落地方法。第八章行業內多家企業的

14、實踐方案的分享。中國汽車基礎軟件發展白皮書 5.0002(一)開放式軟件架構開放式軟件架構是指軟件系統或應用程序基于開放的標準和接口進行設計和開發，可以與其他系統或應用程序進行無縫集成和交互，這種架構模式可以提高軟件的靈活性、可擴展性和互操作性，同時也可以降低軟件的成本和風險。其本質是：基于規則的開放參與共建軟件架構，且規則本身對于全體參與者來說，也是開放可修改的?；谶@一定義與原則，AUTOSEMO 從成立開始就提出了汽車軟件架構，經過這幾年演進，已從基礎軟件平臺演化到 2023 年發布的整車軟件開發平臺（如圖 1.1-1 整車軟件開發平臺所示）。圖1.1-1 整車軟件開發平臺開放式軟件架構

15、具備三大特點：（1）軟件架構：以穩定性和安全性高的操作系統底座為基礎，開放性強、兼容度高，復用性好的中間件為核心；（2）工具鏈友好：包括 SDK（SoftwareDevelopmentKit，軟件開發工具包，以下簡稱 SDK）、API（ApplicationProgrammingInterface,應用程序編程接口，以下簡稱 API）、文檔等開發者工具，幫助開發者更快地開發和部署應用程序和服務；（3）生態屬性：行業共建，持續迭代，具有延續性和開放兼容性。1.開放式架構開放式架構（OpenSoftwareArchitecture，以下簡稱 OSA）作為一種創新的軟件設計理念，為汽車軟件領域帶來了

16、革命性的變革。它不僅從根本上加速了軟件的迭代更新，還極大地豐富了功能擴展的可能性，并促進了跨領域的協同合作。在一個不斷生長的開放式架構模式下，擴展性、適應性、可靠性、松耦合等能力，才是軟件的核心競爭力。硬件標準規范工具鏈（開發、仿真、調試、測試等）Adaptive AUTOSARClassic AUTOSAR操作系統內核OS虛擬化Hypervisor功能軟件面向服務的ASF框架數據中心云端設備AIOT設備平臺服務中間件操作系統車端應用云端應用AIOT生態應用整車軟件開發平臺車端平臺云端平臺AIOT端平臺中國汽車基礎軟件發展白皮書 5.0003圖1.1-2 AUTOSEMO開放式軟件架構詳細如圖

17、 1.1-2 所示，AUTOSEMO 的開放式軟件架構基礎軟件部分，除操作系統內核之外，還有用于跨域交互的中間件 ASF（AUTOSEMOServiceFramework，AUTOSEMO 通用服務框架中間件，以下簡稱ASF）。ASF框架是面向整車跨域控制器打造的SOA（Service-OrientedArchitecture，面向服務的架構，以下簡稱 SOA）框架下的中間件，基于標準基礎軟件向上擴展，解決域控制器異構芯片跨核融合問題，實現域控制器的統一開發視圖。ASF 框架是開放的分布式服務框架，通過 ASF 規范統一服務和接口定義，梳理服務開發環境與運行環境，用于打造高效、集成便捷的開發式

18、架構。2.工具鏈在汽車軟件開放式架構中，開發者工具是連接軟件開發者與系統硬件、中間件及最終應用的橋梁，也是保障系統有效開發和維護的關鍵。汽車電子電氣架構趨于復雜化，在多域融合的架構中，滿足開發者應用的工具顯得尤為重要。這些工具不僅要支持不同領域的開發需求，還要提供統一的接口和標準，以確保系統各部分的高效集成，從提升開發效率，到確保軟件質量，促進多域融合架構下軟件的快速迭代與部署。3.生態屬性開放式架構需要從兩個維度進行生態建設：一是技術維度，通過開源社區、開放標準、開發者技術平臺等途徑，促進開放式軟件架構的推廣應用和技術迭代。二是產業維度，通過構建分層解耦的生態系統，促進產業合理分工和投入，減

19、少重復開發，提高資源利用率，推動整個產業的效率提升和技術創新?？傊袊嚮A軟件發展白皮書 5.0004結來看，開放式架構的生態建設具備如下能力：（1）為行業開發者提供可復用的軟件及工具，從而幫助降低開發和部署的成本，減少風險。（2）提高互操作性和標準化程度，使得不同的技術可以更好地協同，支持在平臺中進行快速迭代、原型開發和測試驗證。（3）有助于解決技術碎片化問題，通過共研共創，減少重復開發，提高資源利用率，推動整個產業的效率提升和技術創新。（4）持續關注技術的最新發展，迅速找到上下游企業對同一種技術的開發難點與痛點。通過培訓、研討會等手段找到共同解決問題的思路，保持對新技術和發展趨勢的了解，

20、以應對汽車產業每一個重要的變革階段。(二)AI 大模型人工智能在汽車行業內的應用領域和場景非常廣泛，從自動駕駛到車輛維護，從個性化用戶體驗到安全監控，從生產制造到銷售售后，AI 技術正在重塑汽車行業的方方面面。AI 大模型則標志著“人工智能”從量變走向質變，正以其強大的計算能力和學習能力深刻推動著汽車產業的進步。1.AI 大模型分類為了更好地理解大模型的應用背景和潛力，首先需要對大模型的分類有一個清晰的認識。根據處理數據類型的不同，大模型可以分為如下幾類：l 語言大模型：專注于處理和理解自然語言數據，能夠執行文本生成、機器翻譯、情感分析等任務。l 視覺大模型：處理圖像和視頻數據，執行物體檢測、

21、圖像分類、場景理解等視覺相關的任務。l 多模態大模型：結合語言、視覺等多種類型的數據，實現跨模態的理解和生成，例如通過圖像理解場景并生成描述文字。根據應用領域不同，大模型可以分為如下幾類：l 通用大模型：設計用于廣泛的應用場景，具有較高的靈活性和適應性，但可能在特定領域的專業性上不如垂直大模型。l 行業大模型：針對特定行業的需求定制，具備較強的通用性和適應性，能夠處理多種任務，相當于 AI 成為行業專家。l 垂直大模型：專注于特定領域或細分市場，具備高專業性和針對性，通常在特定任務上表現更佳，如面向 ASPICE（AutomotiveSoftwareProcessImprovementandC

22、apacityDetermination，汽車軟件過程改進及能力評估，以下簡稱 ASPICE）汽車軟件架構的汽車軟件編碼大模型。2.汽車行業垂直大模型如圖 1.2-1 中國主流大模型應用選型評估矩陣所示，目前通用的大模型百花齊放，如 chatGPT、文心一言、通義千問、星火、智譜等，但針對汽車行業的垂直大模型仍然相對較少，主要原因如下：中國汽車基礎軟件發展白皮書 5.0005圖1.2-1 中國主流大模型應用選型評估矩陣（1）高度專業化的需求：汽車行業對軟件的安全性、可靠性和實時性有著極高的要求。這些要求導致汽車軟件的開發必須遵循嚴格的行業標準，如 ASPICE（汽車軟件過程改進及能力評估）、I

23、SO26262（道路車輛功能安全）、AU-TOSAR（汽車開放系統架構）等。垂直大模型需要能夠理解和適應這些標準，這增加了模型開發的復雜性。（2）數據獲取的高難度：汽車行業涉及的數據類型多樣，包括車輛動力學數據、傳感器數據、控制算法等。這些數據往往受到嚴格管控，互通性低，且還需要在實際車輛上進行測試和驗證，直接限制了可用于訓練垂直大模型的數據量。（3）技術和資源的密集性：構建垂直大模型需要大量的計算資源和專業知識。與科技巨頭相比，汽車領域的軟件公司在計算資源、AI 專業人員、大模型開發與實施等方面上存在劣勢。（4）長開發周期和高成本：汽車軟件的開發周期通常較長，且成本較高。這使得企業在投資垂直

24、大模型時更為謹慎，因為需要確保投資能夠帶來相應的回報。（5）技術更新迭代快：汽車行業的技術迭代速度非?？?，新的傳感器、控制單元和軟件架構不斷涌現。垂直大模型需要不斷更新以適應這些變化，模型的迭代、升級和維護的代價高、難度大。中國汽車基礎軟件發展白皮書 5.00063.AI 端側部署當前，AI 在汽車領域開始積極應用。從早期的研發輔助、到輔助車型設計、供應鏈管理，AI 都極大的提升了工作效率。目前，隨著各廠家對 AI 大模型的進一步研究使用，裁減后的 AI 大模型在端側部署已成為新的技術趨勢。從目前討論較多的智駕端到端方案再到座艙領域的智慧化交互以及整車的智能體（AIAgent）方案，AI 大模

25、型已開始與開放式軟件架構進行融合。(三)面向 AI 大模型的開放式軟件架構結合工程中的優秀實踐以及 AI 大模型的端側部署方案，我們對之前提出的整車軟件開發平臺作了完善，形成了面向 AI 大模型的開放式軟件架構。1.3-1 面向AI大模型的開放式軟件架構的定義與構成面向 AI 大模型的開放式軟件架構如圖 1.3-1 所示?；趯﹂_放式軟件架構的分析，面向 AI 大模型的開放式軟件架構除去上層應用之外可以分為操作系統、中間件、工具鏈以及生態四部分構成。應用主要分為車端應用和云端應用，將在第二章詳細展開。軟件架構基礎軟件部分自下而上，首先對整車服務框架規范 ASF 做更豐富的完善，以應對當前多域融

26、合、數據處理以及 AI 部署的技術趨勢；標準中間件部分，中國汽車基礎軟件發展白皮書 5.0007主要遵循 ClassicplatformAUTOSAR（以下簡稱 CP）以及 AdaptiveplatformAUTOSAR（以下簡稱AP）的標準定義；操作系統內核，聚焦在開放式架構下，如何平衡性能、安全和第三方生態；工具鏈部分，則融入多團隊協作以及 AI 開發友好這一理念，進行迭代升級。1.開放式軟件架構的中間件圖 1.3-2 面向AI大模型的開放式軟件架構中間件構成如圖 1.3-2 所示，面向 AI 大模型的開放式軟件架構主要由 ASF 中間件和標準中間件兩部分構成。ASF 中間件：l 對外的接

27、口：給應用提供的 API（應用程序編程接口），需要支持本地，車內其他節點，云端的調用；l 功能軟件：應用軟件加速器；l AI 大模型/應用框架：車端的 AI 模型和基礎類庫；l 整車數據處理框架：多域融合趨勢下，提供整車數據處理單元，實現數據與邏輯的分離。支持AI 趨勢下，對車端數據處理的要求；l 整車通信總線：多域融合趨勢下，提供整車統一的通信框架。包括針對整車不同架構的控制器、不同物理總線、不同通信協議、不同操作系統、不同開發語言及開發體系的統一通信接口及開發方法論。支持 AI 趨勢下，對車端的通信要求；l 車輛基礎服務：車輛基礎服務中間件在多域融合的架構下，可以將不同芯片、不同 ECU

28、甚至不同功能的資源進行協同處理和調用，并打通不同基礎系統間的通信。車輛基礎服務中間件在AUTOSAR 基礎軟件規范的基礎上進行接口封裝、特性增強和場景擴展，解決快速創新的問題；l 標準中間件的接口抽象層：對標準中間件（CPAUTOSAR 和 APAUTOSAR）的抽象。標準中間件：l ClassicPlatformAUTOSAR：運行于 MCU（微控制器）或 SoC（SystemofChip，片上系統）的 R 核，主要用于安全車控；l AdaptivePlatformAUTOSAR：運行于 SoC 的 A 核，主要用于支撐 SOA 架構下的服務，應用于智能駕駛和智能座艙以及服務網關等。2.開放

29、式軟件架構的操作系統底座近些年有一些聲音，意在形成統一的操作系統，即用一個內核支持車控、智駕和座艙這三種不同的應中國汽車基礎軟件發展白皮書 5.0008用需求。但當下尚未形成統一的技術路線，仍然是多種操作系統基于場景需求進行組合使用，可預見的未來技術路線仍然會多路并行。l 智能車控：仍然以 ClassicPlatformAUTOSAR 作為主流方案。部分 Tier1 考慮 CP 本身過重、存在一定使用門檻、OS 調度方式過少等因素，一般基于 FreeRTOS（開源的小型實時操作系統）或其他實時操作系統，形成替代 CP 的車控解決方案。l 智能駕駛：存在多條技術路線。部分廠家完全基于 Linux

30、 進行算法調度和安全監控，或者基于QNX 等微內核方案實現智駕系統調度，也有廠家基于 Linux+RTOS 方案，盡可能地兼顧性能和安全需求。l 智能座艙：座艙領域，主要基于 Andriod 進行車載影音娛樂模塊的功能開發，此外在儀表等車控領域，則采用 CP或微內核方案。3.開放式軟件架構的工具鏈開放式架構從根本上加速了軟件的迭代更新，并極大地豐富了功能擴展的可能性，促進了跨領域協同合作。隨著開放式軟件架構的不斷演進，新的汽車軟件開發過程中需要引入敏捷開發模式、模塊化設計、標準化接口、持續集成與持續部署、跨領域合作、安全管理、AI 賦能等新的開發理念?；谶@些，除了中國汽車基礎軟件發展白皮書

31、4.0（以下簡稱：白皮書 4.0）中介紹的工具鏈之外，本報告中提出了高效開發框架，用于提升開發效率、支持多團隊協作以及支持 AI 開發以及融合 AI 的新一代軟件工程技術方案。4.開放式軟件架構的生態建設開放式軟件架構的生態系統指的是技術生態和產業生態，技術生態主要包括接口統一、技術路線共識，這樣有利于產業鏈上下游合理分工，化整為零，協作開發，促進技術創新；產業生態則是致力于建立開源開放的多層解耦的立體生態體系，有利于軟件架構的演進和技術路線的聚焦發展，促進產業協同進步。中國汽車基礎軟件發展白皮書 5.0009二、開放式軟件架構的應用層AI 大模型顛覆了以往基于規則進行算法開發的模式，轉化為基

32、于數據驅動的新范式。本章節結合應用場景將詳細探討相關的技術路線、挑戰與演化趨勢，旨在為讀者帶來一些啟發。(一)車端應用1 應用場景1.1 智能座艙應用智能座艙系統的特點體現為高算力、中實時（毫秒級）、與車輛行駛安全弱相關，但有強人機交互需求這幾方面。其設備端主要包括中控大屏、數字儀表、流媒體后視鏡、HUD（車輛平視顯示系統）、行車記錄儀等。AI 大模型在智能座艙中的應用，不僅能夠增強人機交互的自然性和便捷性，還能夠提供更加個性化的服務，驅動著座艙系統由智能體進化至智慧體。以下是AI大模型在智能座艙中的幾個典型應用場景：（1）多模態交互AI 大模型可以作為智能座艙中語音識別和自然語言處理的核心，

33、使車輛能夠理解和響應駕駛員及乘客的語音指令。此外，它還可以結合情境感知，實時分析車外環境信息，比如天氣和交通狀況，為用戶提供智能助手功能，增強交互體驗。（2）個性化智能推薦利用 AI 大模型對用戶行為和偏好的學習，智能座艙可以提供個性化的服務和內容推薦。例如，根據用戶的駕駛習慣和常用路線，推薦最優的行車路線；或者根據用戶的音樂播放歷史，推薦用戶可能喜歡的歌曲。同時，系統可以與智能家居聯動，在接近家時自動調整家中環境，提升整體生活便利性。（3）駕駛員行為分析AI 大模型可以通過分析駕駛員的操作習慣、生理狀態（如面部表情、心率等）和駕駛行為，根據綜合分析調整車內環境，以提升駕乘體驗。此外，可以識別

34、駕駛員的情緒狀態，當檢測到緊張或焦慮時，系統能夠自動播放放松音樂，或根據駕駛員的狀態分析，檢測疲勞駕駛等情況，從而提高駕駛的安全性。1.2 智能駕駛應用智能駕駛系統的特點體現為高算力、高實時性（毫秒級，確定時間范圍內）、與車輛行駛安全強相關。（1）傳統算法在智駕的傳統順序方法感知、決策和規控中，AI 大模型應用情況如下：l 環境感知AI 大模型通過車載傳感器（如攝像頭、雷達、激光雷達等）獲取車輛周圍的環境信息，并對這些信息進行分析和處理，進行周圍環境的實時感知，為自動駕駛提供基礎數據支持。l 決策規劃決策規劃環節中，AI 大模型可以根據環境感知獲得的信息，結合車輛的狀態，制定出最優的行駛策略。

35、即使遇到復雜的交通情況，AI 大模型也能夠快速做出合理的決策，提高駕駛的安全性和舒適性。l 控制執行中國汽車基礎軟件發展白皮書 5.0010AI 大模型可以將決策規劃轉化為具體的控制指令，控制車輛的加速、減速、轉向等操作。通過對車輛動力學模型的學習，AI 大模型可以實現精準的控制執行，提高車輛的操控性能和穩定性。如今在智能駕駛領域，端到端解決方案正逐漸成為主流，這里對端到端技術做詳細分析：（2）端到端大模型算法如圖 2.1-1 端到端模型所示，端到端是指：一端輸入傳感器數據（例如視頻、激光雷達點云等信息），另一端直接輸出駕駛決策（例如駕駛動作、駕駛軌跡等）的技術范式。圖2.1-1 端到端模型傳

36、統的非端到端算法將任務進行切分，定義多個子任務：地圖、定位、感知、預測、決策、規劃、控制等子任務負責解決駕駛過程的某些特定問題，這些任務獨立開發、獨立測試，最終集成到一起完成自動駕駛任務。相比于傳統的自動駕駛方案，端到端方案的訓練方式能夠實現系統的全局最優，使得系統能夠獲得更好的駕駛效果；避免預設大量的人工規則，系統也更加簡潔、模塊簡單、效率更高；通過數據驅動的方式，不斷提升系統上限。1)端到端算法的實現方法模塊化端到端：如圖 2.1-2 模塊化端到端所示，模塊化端到端方法是將自動駕駛任務分解成若干個子任務，如感知、定位、路徑規劃和控制等，并針對每個子任務開發專門的算法或模型。這些模塊通常是獨

37、立訓練，在實際部署時連接起來作為完整系統運行。將傳統自動駕駛的多個模塊連接后進行端到端訓練，如 Hydra-MDP（教師-學生知識蒸餾架構）包括感知網絡、軌跡解碼、Multi-targetHydra-Distillation（多目標知識蒸餾），三個部分進行端到端訓練。這種方法的優點在于每個模塊可以單獨優化和測試，使得系統整體穩定可靠。缺點則是模塊間的交互復雜，需要大量工程活動來確保模塊間的協調一致。圖2.1-2 模塊化端到端中國汽車基礎軟件發展白皮書 5.0011單一網絡端到端：如圖 2.1-3 單一網絡端到端所示，單一網絡端到端方法完全摒棄傳統自動駕駛方案的感知、預測、規劃等思想，將所有的功

38、能集成到一個深度神經網絡中，該網絡直接從傳感器輸入映射到車輛控制信號。這種方法不需要顯式的中間步驟，直接通過大量數據訓練得到一個能夠直接完成從感知到動作的模型。單一網絡端到端的優點在于其簡化系統結構，減少中間環節，使得系統更易于訓練和部署。缺點則是對數據量和多樣性要求較高，由于缺乏明確的功能模塊劃分，難以對特定部分進行調試和優化。圖2.1-3 單一網絡端到端2)基于大模型的端到端自動駕駛端到端強調的是從輸入到輸出的端到端訓練方式，追求系統全局最優。大模型優勢在于模型的參數規模，以 GPT 為代表的大模型技術在自然語言處理方面表現出非常強大的泛化能力。端到端自動駕駛結合大模型，借助大模型強大的泛

39、化能力來解決層出不窮的 cornercase（極端情況），借助海量的人駕數據，通過端到端學習來解決實現類人駕駛。端到端與大模型結合目前主要有三種方式：使用大模型直接開車，使用大模型來加速端到端的訓練以及使用大模型來生成數據供自動駕駛訓練。使用大模型直接開車：如圖 2.1-4 使用大模型直接開車方案所示，大模型被訓練成為能夠直接從輸入數據（如攝像頭圖像、雷達數據等）映射到輸出控制指令（如轉向角度、油門踏板位置等）的系統。大模型通常是具有強大泛化能力的預訓練深度學習模型。這樣不需要顯式的中間步驟，提高實時性能。VLA 大模型(Vision-Lan-guage-Actionmodel，視覺語言模型)

40、通過視覺編碼器對視頻進行編碼并 token（AI 處理的數據或文本的最小單位）化，與文本和 query（學到的嵌入表示）一起輸入 VLA 大模型中，即可輸出駕駛動作，實現端到端自動駕駛。中國汽車基礎軟件發展白皮書 5.0012圖2.1-4 使用大模型直接開車方案預訓練大模型加速端到端自動駕駛：如圖 2.1-5 預訓練大模型所示，訓練大模型都需要海量的數據，如讓自動駕駛模型學會看懂警察手勢、理解各類路牌、處理各類障礙物，需要海量的自動駕駛領域數據進行訓練，僅僅依靠自動駕駛領域數據，其采集、存儲、訓練的成本都非常高。引入兩個預訓練大模型，利用其海量數據與通用能力，來幫助自動駕駛理解各類復雜場景，是

41、目前最具性價比的降本方案。在感知階段，通過多模態大模型對齊視覺特征與文本特征，實現識別萬物；在駕駛決策階段，通過引入預訓練模型對駕駛場景做出解釋和建議，提升學習效果。圖2.1-5 預訓練大模型大模型生成數據供自動駕駛訓練：端到端自動駕駛訓練的多樣數據如果全部依賴實車采集，訓練成本高。如圖 2.1-6 大模型生成訓練數據所示，使用大模型生成數據供自動駕駛訓練是另外一種替代方案。世界模型（Worldmodel）被認為是大模型生成訓練數據最有可能的方式之一。世界模型是能夠對環境或世界的狀態進行表征，并基于駕中國汽車基礎軟件發展白皮書 5.0013駛動作預測未來世界的模型。世界模型首先將當前世界看到的

42、視頻進行編碼，結合駕駛動作和其他信息，進行 token（最小的語義單元）化，然后使用自回歸的方式生成未來世界的 token，并解碼成未來世界的視頻。世界模型基于輸入 action（動作）來生成對應的視頻，按照特定的需求來人為構造對應的 action，生成數據，尤其對一些常規方法難以采集、非常危險的動作，如急剎、近距離切入等非常有效。圖2.1-6 大模型生成訓練數據1.3 智能車控應用智能車控包括動力系統、底盤系統、車身系統、電池管理系統、網聯控車系統等，其特點體現為高安全、低算力、強實時（微秒級）、與車輛安全行駛強相關。由于車控系統本身對安全的高要求，AI 在車控系統的應用主要還在探索階段。（

43、1）動力系統優化AI 大模型可以根據車輛的實時數據，如發動機轉速、負荷、溫度等，優化動力系統的控制策略，提高燃油效率和性能。（2）電池管理系統（BMS）在電動汽車中，AI 大模型可以用于預測電池的健康狀況、剩余電量和充電需求，從而優化電池的使用和維護策略，提升續航里程。（3）底盤控制系統AI 大模型可以集成到車輛的底盤控制系統中，實現自適應懸掛調節、電子穩定控制等，以提供更平穩和安全的駕駛體驗。（4）車身電子系統AI 大模型可以用于控制車身電子系統，如自動調節車內溫度、照明、車窗和車門鎖等，以適應駕駛員和乘客的需求。（5）網聯控車系統AI 大模型可以分析車輛的網絡數據，實現遠程監控、故障診斷和

44、車輛優化，同時提供車輛與外部環境的智能交互。（6）車輛能源與熱管理熱管理需要考慮發動機、電池、電機等多個部件工作溫度及其相互影響；系統設計和優化涉及多個學科，設計復雜性高；需要保證在各種環境條件下都能正常工作，系統可靠性要求高；提高車輛能量利用效率，中國汽車基礎軟件發展白皮書 5.0014延長續航里程，電池健康狀態的監測與維護，延長電池使用壽命。通過大模型模擬不同工況下的熱管理效果，幫助工程師優化設計方案，減少實際測試次數；利用大模型根據不同車型和使用場景，定制化熱管理策略，最大化能效比。2 AI 大模型在車端應用的挑戰2.1 技術挑戰AI大模型通常需要大量的計算資源進行訓練和推理。在車端應用

45、中，如何滿足 AI 大模型的計算資源需求是一個難題。需要開發高效的計算架構和算法，提高計算資源的利用率，降低計算成本。(1)計算資源需求高大模型通常具有龐大的參數量和復雜的計算結構，在車端部署大模型，同樣需要大量的計算資源。車輛的嵌入式系統往往計算能力有限，難以滿足大模型的運行要求。例如，進行實時的圖像識別和處理、路徑規劃等任務時，可能會出現計算延遲，影響車輛的響應速度和安全性。為了解決這個問題，需要進行模型壓縮和優化，以降低計算需求。同時，也需要開發更高效的硬件加速器，如專用的更高算力的 AI 芯片，來提升車端的計算能力。(2)數據處理與存儲車端應用需要處理大量的傳感器數據，包括攝像頭圖像、

46、雷達數據、GPS信息等。AI 大模型對數據的質量和數量要求很高，如何高效地采集、傳輸、存儲和處理這些數據是一個挑戰。數據傳輸可能會受到網絡帶寬和穩定性的限制，特別是在車輛高速行駛或處于信號較弱的區域。此外，數據存儲也需要考慮車輛有限的存儲空間和數據安全問題?？梢圆捎眠吘売嬎愫头植际酱鎯Φ燃夹g，在車端進行部分數據處理，減少對云端的依賴，提高數據處理的效率和實時性。同時，加強數據加密和安全防護措施，確保車輛數據的安全。(3)模型穩定性與可靠性車輛運行環境復雜多變，對 AI 大模型的可靠性和穩定性要求極高。在不同的天氣條件、路況和駕駛場景下，模型需要始終保持準確和可靠的性能。例如，在惡劣的天氣下，傳

47、感器數據可能會受到干擾，影響模型的判斷。此外，模型還需要具備一定的容錯能力，能夠在部分傳感器故障或數據異常的情況下繼續正常工作?？梢酝ㄟ^大量的實際測試和驗證，不斷優化模型的性能和魯棒性。同時，建立備份和冗余機制，確保在出現問題時能夠及時切換到備用系統，保障車輛的安全運行。2.2 安全挑戰(1)功能安全AI 大模型在車端的應用直接關系到車輛的行駛安全。如果模型出現錯誤判斷或決策失誤，可能會導致嚴重的交通事故。因此，確保模型的功能安全是至關重要的。需要建立嚴格的安全標準和測試流程，對模型的性能、可靠性和安全性進行全面評估。同時，采用多種安全機制，如冗余設計、故障檢測和隔離等，提高系統的安全性。例如

48、，在自動駕駛系統中，可以采用多傳感器融合和備份決策系統，以降低單一傳感器或模型故障的風險。(2)網絡安全智能化和網聯化程度的提高，讓車端正面臨著越來越多的網絡安全威脅。黑客可能會通過網絡攻擊入侵車輛系統，篡改AI 大模型的參數導致異?？刂栖囕v的行為。加強車輛的網絡安全防護，采用加密技術、身份認證和訪問控制等措施，防止未經授權的訪問和攻擊。中國汽車基礎軟件發展白皮書 5.0015同時，建立實時的網絡安全監測和響應機制，及時發現和應對網絡安全事件。例如，對車輛的通信系統進行加密，確保數據傳輸的安全。對車載軟件進行定期更新和漏洞修復，提高系統的安全性。車端網絡安全入侵監測防御系統（Intrusion

49、DetectionandPreventionSystem,以下簡稱：IDPS）在智能汽車和車聯網環境中承擔著發現并阻止網絡攻擊的任務。當前的 IDPS 基本還是依賴于基于規則的檢測方法，這導致其在面對未知威脅和復雜攻擊時容易出現漏報和漏檢問題。AI 和機器學習技術在威脅檢測中有很大潛力，機器學習模型能夠通過學習大量歷史數據，自動識別正常與異常的網絡行為模式。當新的威脅出現時，系統可以通過持續學習和模型更新，逐步適應新的攻擊手法；通過對正常行為模式的深入學習，基于機器學習的 IDPS 能夠更準確地區分正常行為與異常行為，從而減少誤報率。然而機器學習也面臨著一些挑戰，首先是訓練數據的質量和數量問題

50、，機器學習模型的性能高度依賴于訓練數據。數據集的多樣性和質量決定了模型的檢測效果。如果訓練數據不足或偏向，可能會導致模型無法有效識別攻擊和異常；機器學習的資源需求問題，復雜的機器學習模型，尤其是深度學習模型，通常需要較高的計算資源和內存，這在資源有限的車載系統中可能是一個挑戰?？山忉屝詥栴}：機器學習模型，尤其是深度學習模型，往往是“黑箱”性質的，即其決策過程難以解釋。這可能在安全關鍵的車載環境中引發信任問題，因為系統管理員可能難以理解和驗證模型的判斷。模型更新和維護：隨著時間的推移，網絡攻擊手段不斷演變，機器學習模型需要定期更新以保持其有效性。然而，頻繁更新模型可能會影響系統的穩定性和一致性。

51、3 AI 大模型在車端應用的演化趨勢基于上文對 AI 大模型應用于車端的挑戰分析，當前 AI 大模型上車主要面臨算力、處理器性能、網絡傳輸速率、數據存儲等方面問題。針對這些問題，本文預判演化趨勢如下：(1)模型壓縮與優化隨著模型壓縮技術的發展，大型 AI 模型將能夠在車端更小的硬件上運行，減少對存儲和計算資源的需求。(2)實時性能優化通過算法優化和硬件加速，車端 AI 大模型將提供更快的響應速度和更高的處理效率。(3)邊緣計算車端 AI 大模型將更多地依賴邊緣計算，減少對云端的依賴，提高數據處理速度和實時性。(4)與移動通信技術的融合移動通信技術在通信速率、質量和數據量上直接影響了AI 大模型

52、在車端的應用效果。AI 大模型將與移動通信技術進行深度融合，實現車輛與云端的高效通信和協同計算，為用戶提供更加智能化的服務。(二)云端應用1 應用場景1.1 云端 VSOC如圖 2.2-1汽車網絡安全運營中心所示，云端 VSOC（VehicleSecurityOperationCenter，汽車安全運營中心，以下簡稱 VSOC）是一個專門負責監控、管理和保護車輛安全的綜合性運營中心，它可以集中處理車輛安全事件、風險和威脅，并采取相應的響應和防御措施，以確保車輛和乘客的安全。VSOC 與AI 的結合能夠極大提升汽車網絡安全的檢測、響應、分析和預防能力。通過智能化的威脅檢測、自動化的中國汽車基礎軟

53、件發展白皮書 5.0016事件響應、增強的數據分析和預測能力，AI 可以使 VSOC 系統更加高效和精確地應對現代汽車網絡安全威脅。然而，在實際應用中，也需要解決數據隱私、模型維護、系統復雜性和資源消耗等挑戰。圖2.2-1 汽車網絡安全運營中心結合車端深度學習小模型提供的事件數據和云端大數據及威脅情報資源作為安全運營訓練數據跟 AI大模型的整合，可以顯著提升汽車網絡安全運營管理的效率。車端的小模型在車輛中實時運行，處理傳感器數據、網絡流量和系統日志，以快速檢測異?；顒雍蜐撛谕{。這種模型具備低延遲、高效的實時檢測能力，并且在計算資源有限的車載系統中表現優越。當車輛檢測到異常時，車端會生成事件和

54、告警，并將這些數據上傳至云端。云端則利用強大的計算能力和豐富的威脅情報資源和專業的安全運營分析處置人員，對車端上傳的事件和告警數據進行深入分析。云端的大數據平臺結合大模型可以處理海量數據，結合全球范圍的威脅情報，識別復雜的攻擊模式和系統漏洞。通過這種方式，云端能夠提供精準的威脅識別和深度分析，提高檢測的準確性。事件處理過程分為自動化和半自動化兩個階段。云端系統可以根據分析結果自動化執行響應措施，如生成補丁、調整安全策略或觸發警報。對于復雜的威脅，云端還可以提供決策支持和建議，供安全分析師進一步處理和決策。這種半自動化和全自動化的響應機制提升了事件處理的效率和有效性。此外，系統還包括一個反饋機制

55、，云端將處理結果反饋給車端，以優化小模型的檢測能力和響應策略。定期更新車端的小模型，結合最新的威脅情報和分析結果，不斷提高其檢測和處理能力。這種車云協同的安全架構具有實時與精準檢測、高效資源利用、自動化與優化、全局視角、靈活性與適應性等顯著優勢。車端的小模型負責初步的異常檢測，減少對云端計算資源的依賴；云端則處理復雜的分析任務，提供全球范圍的安全態勢感知和應對能力。通過結合車端和云端的優勢，這一方案大大提升了汽車網絡安全的防護能力，有效應對各種安全威脅，確保車輛的安全運行。1.2 性能預測與優化AI 大模型可以根據輸入的汽車設計參數和性能目標，預測汽車的各項性能指標，通過對大量汽車工中國汽車基

56、礎軟件發展白皮書 5.0017程數據的學習，大模型可以建立起汽車結構參數與性能指標之間的復雜關系模型，充分利用云端的強大算力和大數據能力，從而實現更高效、更智能的預測與優化。如圖 2.2-2 所示，云端能量管理算法搭建了端到端的算法模型，首先將最影響能耗和續駛里程的駕駛員行為和行駛工況識別出來，通過構建駕駛員風格庫與行駛工況庫對不同的駕駛行為和行駛工況進行區分，獲得其對能耗和續駛里程的影響的因子，再根據車輛的其他特征預測長駕駛周期的能耗和續駛里程。通過分析能耗和續駛里程，推薦相應駕駛模式并對加速踏板與制動能量回收強度實時更新，續駛里程不足時會進行相應的充電時間規劃和節能路線導航。圖2.2-2

57、性能預測與優化1.3 故障診斷與預測如圖 2.2-3 故障檢測與預測所示，利用先進的數據處理技術和 AI 大模型，實現對車輛健康狀況的實時監控和預測性故障診斷。該系統通過實車采集的數據，結合云端的強大計算能力，對車輛的關鍵部件進行深入分析，從而提前發現潛在的故障和性能退化問題。及時發現潛在的故障隱患，并給出具體的故障診斷結果和維修建議。此外，大模型還可以通過對歷史故障數據的學習，預測未來可能出現的故障，提前采取預防措施，降低汽車的故障率和維修成本。這不僅提高了汽車的可靠性，也減少了因故障導致的工程開發時間和成本浪費。圖2.2-3 故障檢測與預測中國汽車基礎軟件發展白皮書 5.00181.4 虛

58、擬測試與驗證傳統的物理測試需要耗費大量的時間和成本。而 AI 大模型可以通過虛擬測試技術，對汽車的各項性能進行快速、準確的測試和驗證。如圖 2.2-4 虛擬測試與驗證所示，通過 NVS 三維場景重建，AI 大模型可以快速更改測試條件，創建各種極端或特定測試場景，精確控制測試環境，如道路條件、天氣狀況等，以評估智能駕駛算法在不同環境下的安全性和有效性。圖2.2-4 虛擬測試與驗證這種模擬測試在汽車設計的早期階段就識別出潛在的問題和性能瓶頸，顯著縮短了工程開發周期，加快了新產品從概念到市場的轉化速度，同時也提高了汽車軟件的整體質量和性能。2 AI 大模型在云端應用的挑戰AI 大模型在云端的應用面臨

59、著一系列挑戰：(1)數據隱私與安全性智能網聯的發展，讓汽車的數據量激增，如何在云端安全地存儲和處理這些數據成為一大挑戰。數據隱私保護和網絡安全是汽車制造商和供應商必須嚴格遵守的法規要求。(2)模型的可擴展性與維護云端 AI 大模型需要具備良好的可擴展性，以適應不斷增長的數據和用戶需求。同時，模型的持續維護和更新也是確保其長期有效性的關鍵。(3)實時性能要求云端 AI 大模型需要快速響應車輛的請求，以支持實時應用，如自動駕駛決策支持和遠程監控。這要求云端具備高效的數據處理和分析能力。(4)跨平臺兼容性汽車行業涉及多種硬件和軟件平臺，云端 AI 大模型需要在這些不同的平臺之間實現兼容，以提供統一的

60、服務和體驗。3 AI 大模型在云端應用的演化趨勢(1)邊緣計算與云端協同中國汽車基礎軟件發展白皮書 5.0019隨著邊緣計算技術的發展，未來 AI 大模型將更多地在車輛端進行預處理，減少對云端的依賴，同時保持云端的強大分析和決策支持能力。(2)跨行業融合汽車行業將與其他行業如 IT、通信、能源等更緊密地融合，云端 AI 大模型將成為跨行業數據和應用集成的關鍵。(3)標準化與開源為了促進行業的健康發展，未來將有更多的 AI 大模型標準化工作和開源項目，以支持技術的共享和創新。中國汽車基礎軟件發展白皮書 5.0020三、開放式軟件架構的中間件層縱觀軟件產業的發展歷史，智能手機是一個極為成功的案例。

61、作為軟件規模最龐大的單一設備之一，智能手機具有獨特特點：只有一個核心計算單元，傳感器和執行器充分解耦和軟件化。這種架構使得開發者在設計創新應用時無需深入了解底層操作，如訪問攝像頭或確保通信安全性和可靠性等問題，只需調用接口獲取所需功能。這種體系和產業標準的支持，讓應用開發者能專注于創新，各領域成熟組件能輕松協同運行，通過靈活編排和組合，創造出創新應用。在汽車產業方面，近十年來，各整車制造廠的電子電氣架構逐漸演進至中央計算+區域控制的技術路線。因此，一個合理抽象整車基礎硬件和系統、覆蓋不同功能域的通信框架、為上層應用軟件和生態提供更開放的開發平臺中間件，已成為當前量產落地和持續創新的關鍵。（一）

62、開放式軟件架構的中間件以中央計算平臺為硬件基礎，多域融合的基礎軟件和應用中間件作為推動整車應用創新的軟件底座，已經成為了行業的共識。在這樣的技術路線上發展，產業要解決核心架構體系和框架問題，希望通過構建這樣的體系和框架，讓汽車軟件的開發也可以像手機應用開發一樣，為未來所有軟件運行在同一顆芯片或計算平臺上提供技術支撐并建立相應的軟件架構、方法論以及工具鏈體系。如圖 3.1-1ASF 中間件所示，ASF 中間件是在各個域控制器上都可以使用的、與業務無關的軟件組件，是開發平臺最基礎、最核心的部分。ASF 中間件是面向下一代電子電氣架構的開發平臺，基于符合AUTOSAR 規范的標準基礎軟件，按照軟件架

63、構自下而上包含以下通用基礎組件：標準中間件：面向 MCU 的標準基礎軟件和面向 SoC 的標準基礎軟件；車輛基礎服務中間件：基于中國汽車基礎軟件生態委員會AUTOSEMO服務框架 ASF 技術規范開發；整車通信總線：解決整車通信總線問題，面向整車不同層級開發者視角；整車數據處理框架：統一的數據處理單元，作為管理域控平臺的數據中心，用于解耦業務邏輯與數據處理；高效的開發框架和接口：將在本書第五章節作詳細介紹。中國汽車基礎軟件發展白皮書 5.0021圖3.1-1 ASF中間件1.面向 MCU 的標準基礎軟件1.1 面向 MCU 的標準基礎軟件介紹面向 MCU 的標準基礎軟件平臺是一套專為 MCU

64、設計的嵌入式操作系統和開發環境，以 ClassicPlatformAUTOSAR 規范為代表，旨在為汽車電子控制單元提供高效、穩定、可靠的基礎軟件支持。該軟件支持多任務調度、中斷管理、通信協議、故障診斷等功能，能夠滿足不同車型和域控制器的開發需求。適用場景：l 適用于動力控制、底盤控制、車身控制等傳統電子控制領域；l 支持多種 MCU 硬件平臺，如 ARMCortex-M 系列、PowerPC 等；l 可與上層應用軟件和操作系統無縫集成，提供完整的解決方案。面向 MCU 的標準基礎軟件起源于汽車電子控制領域對高效、可靠基礎軟件的需求。隨著 AUTOSAR等國際標準的推出，面向 MCU 的標準基

65、礎軟件逐漸走向標準化和模塊化。目前，國內外多家廠商已推出基于 AUTOSAR 的 MCU 基礎軟件解決方案，并在汽車電子控制領域得到廣泛應用。1.2 面向 MCU 的標準基礎軟件解讀主要特點：l 標準化：遵循 ClassicPlatformAUTOSAR 等國際標準，提供統一的接口和服務；l 模塊化：支持軟件組件的模塊化設計和復用，降低開發成本；l 高效性：采用實時操作系統和高效的任務調度機制，確保系統迅速響應；l 可靠性：內置故障診斷和自恢復機制，提高系統穩定性和安全性。重要特性：l 多任務調度：支持基于優先級的實時多任務調度；l 中斷管理：提供靈活的中斷配置和管理功能；l 通信協議：支持

66、CAN、LIN 等汽車電子通信協議；中國汽車基礎軟件發展白皮書 5.0022l 故障診斷：內置故障診斷和上報機制，便于故障排查和修復。關鍵技術：l 實時操作系統（RTOS）：提供高效的實時任務調度和同步機制；l 通信協議棧：支持多種汽車電子通信協議，確保數據交換的實時性和可靠性；l 故障診斷和上報：采用先進的故障診斷算法和上報機制，提高故障排查效率。1.3 面向 MCU 的標準基礎軟件發展趨勢最新的 ClassicPlatformAUTOSAR 規范主要針對通信協議、接口標準化、內存操作、數據協議、質量屬性、安全事件等方面進行強化和修改，主要集中在如下方面：新增 DDS 通信協議用于進行 DD

67、S 服務化通信，新增 SENT（SingleEdgeNibbleTransmission，SENT）驅動用于標準化汽車傳感器接口，新增車輛數據協議（VehicleDataProtocol，VDP）用于 ECU 之間的數據采集任務分發，修訂 I2C 驅動規范，新增對內存標準函數庫（MemoryStandardFunctionLibrary，MSFLibrary）的標準化。下面針對這些變化進行詳細描述：a.DDS 通信協議：特性描述：針對 AUTOSAR 平臺中服務實例的發現與廣告場景，定義一套基于 DDS（DataDistri-butionService）的服務發現協議，包括服務實例的廣告和服務

68、實例的發現機制；定義服務的數據類型、QoS 策略、序列和語義，旨在支持 AUTOSAR 經典平臺和自適應平臺以及非 AUTOSAR 平臺之間的 DDS互操作性。意義：通過標準化的服務發現協議，實現了 AUTOSAR 平臺內及跨平臺的服務互操作性，簡化了服務實例的動態發現和綁定過程，提高了系統的靈活性和可擴展性；為 AUTOSAR 平臺提供了一種高效、可靠的數據分發機制，支持復雜的實時通信需求，提高了系統的通信效率和可靠性。b.SENT 驅動：特性描述：針對汽車傳感器接口標準化需求，提出了 SENT（SingleEdgeNibbleTransmission）協議的 API 標準化方案，定義 SE

69、NT 驅動在 AUTOSAR 微控制器抽象層（MCAL）中的實現方式和接口規范。意義：通過 SENT 驅動的標準化，實現傳感器應用程序與基礎軟件層的獨立開發，提高軟件的可重用性和兼容性，降低軟件開發成本。c.車輛數據協議 VDP：特性描述：定義了一種用于在 ECU 之間分發數據采集任務的協議，支持動態配置數據采集點、異步錯誤報告等功能，旨在提高數據采集的靈活性和效率。意義：VDP 協議為車輛數據的高效采集和處理提供了一種標準化的解決方案，支持按需和循環采樣模式，提高了數據采集的實時性和準確性。d.I2C 驅動：特性描述：對 I2C 驅動的規范進行修訂，包括功能要求、API 接口和配置參數的標準

70、化，新增對不同數據傳輸模式和錯誤處理機制的支持。意義：使得 I2C 驅動更加符合 AUTOSAR 標準的要求，提高驅動的穩定性，同時也增強驅動的可配置性和靈活性。e.內存標準函數庫：特性描述：增加了對內存標準函數庫的標準化要求，提供一套優化的內存操作函數，包括內存拷貝、內存移動、內存填充等功能。中國汽車基礎軟件發展白皮書 5.0023意義：簡化內存操作的復雜性，提高代碼的可移植性和可維護性。同時，通過提供優化的內存操作函數，提高程序的運行效率。2.面向 SoC 的標準基礎軟件2.1 面向 SoC 的標準基礎軟件介紹面向 SoC 的標準基礎軟件是一套專為高性能 SoC 設計的嵌入式操作系統和開發

71、環境，旨在為智能網聯汽車提供高效、安全、可擴展的基礎軟件支持。該軟件遵循 AUTOSARAdaptivePlatform 等國際標準，支持多任務調度、實時通信、故障診斷、安全保護等功能，能夠滿足不同車型和域控制器的開發需求。適用場景：l 適用于自動駕駛、智能座艙、車載娛樂等高性能計算和高帶寬需求場景；l 支持多種 SoC 硬件平臺，如 ARMCortex-A 系列、NVIDIAXavier 等；l 可與上層應用軟件和操作系統無縫集成，提供完整的解決方案。面向 SoC 的標準基礎軟件隨著智能網聯汽車的發展而興起。隨著 AUTOSARAdaptive 等國際標準的推出，面向 SoC 的標準基礎軟件

72、逐漸走向標準化和模塊化。目前，國內外多家廠商已推出基于 AdaptivePlatformAUTOSAR規范的SoC基礎軟件產品和解決方案，并在自動駕駛、智能座艙等領域得到廣泛應用。2.2 面向 SoC 的標準基礎軟件解讀主要特點：l 高性能：支持多任務并發處理和高速數據處理，適用于實時應用場景，如自動駕駛和車載信息娛樂系統；l 高帶寬：提供支持高帶寬需求的通信協議棧和基礎服務，確保流媒體和大數據傳輸的流暢性；l 安全性：內置安全保護機制，防止惡意攻擊和數據泄露，保障用戶隱私和系統穩定性；l 可擴展性：支持軟件組件的模塊化設計和動態加載，便于功能擴展和升級。重要特性：l 多任務調度：支持基于優先

73、級的實時多任務調度，確保任務按時執行；l 高帶寬通信：提供高效的通信協議棧，支持大量數據傳輸和快速同步；l 故障診斷：內置故障診斷和上報機制，便于故障排查和修復；l 安全保護：支持加密、認證、防火墻等安全保護機制，確保系統安全。關鍵技術：l 安全可靠的操作系統：提供高效的任務調度機制和可靠的資源管理機制。l 高性能通信協議棧：支持 SOME/IP、DDS、TSN 等高性能通信協議。l 安全保護技術：采用加密、認證、防火墻等安全保護技術，確保系統安全。2.3 面向 SoC 的標準基礎軟件發展趨勢新的 AUTOSARAP 規范主要針對汽車應用程序接口網關、自適應虛擬化等方面進行強化和修改，主要集中

74、在如下方面：新增汽車 API 用于增強系統連接、數據交互能力，強化自適應平臺的虛擬化特征用于虛擬化驗證等場景。a)汽車 API：汽車 API 可以用于連接非AUTOSAR系統，使非AUTOSAR系統能夠與車輛進行高效且安全的數據交換，適用標準化汽車 API 網關連接非AUTOSAR系統，可提高不同車輛和系統之間的兼容性和互操作性。其意義在于適應現代車輛中可能存在的多種不同類型系統的環境，促進汽車與其他領域技術的融合，中國汽車基礎軟件發展白皮書 5.0024為車輛提供更多的功能擴展和創新可能性。汽車 API 可以用于處理不同類型的數據，使用 ARXML（遵守 AUTOSAR 標準的通用的配置/數

75、據庫描述文件）描述 VSS 衍生服務接口，基于 VSS 目錄定義服務接口，可以實現車輛數據在 AUTOSAR 環境中的訪問和展示，并支持不同格式數據的映射和連接。其好處是確保車輛數據得到合理處理和利用，發揮數據價值，為不同應用場景提供準確數據支持。汽車 API 可以提供靈活的數據交互方式，汽車 API 網關可以提供基本的VISS操作（讀、寫、訂閱數據），可以支持多種過濾器，用戶可通過VISS協議訪問車輛，網關負責實現VISS服務器功能并滿足訪問控制和傳輸協議要求。其意義在于滿足不同用戶和應用對車輛數據的訪問需求，提高車輛數據服務質量和效率，為適應未來新傳輸協議和技術發展奠定基礎。汽車 API

76、可以配置和管理網關功能，可以為網關提供ARXML，將 VSS 派生服務接口作為 RPort 進行描述，為開發人員提供更清晰的接口定義和配置信息。同時，能夠確定網關配置方式，明確錯誤處理機制。其意義在于優化網關功能性能，滿足不同場景需求，提升車輛系統質量和用戶體驗，為系統開發、維護和升級提供有力支持。b)自適應平臺的虛擬化特征增強：評估虛擬化對 AUTOSARAP 的影響，包括虛擬化對處理器技術發展的益處和全面評估，包括對 AP架構、元模型、安全、功能集群等方面的影響，制定評估虛擬化影響的指南和方法。其意義在于全面了解虛擬化對 AUTOSARAP 各方面的影響，為后續的改進和優化提供依據。定義支

77、持的虛擬系統配置和相關用例，包括兩種系統配置：一是單機無虛擬化的配置，用于討論和比較；二是虛擬系統配置，包括Type1Hypervisor下的非 APGuests（安全 Guest 和非安全 Guest）、混合臨界性 APGuests（安全Guest 和 QMGuest）以及使用 OSHypervisor 的配置。其意義在于明確不同虛擬系統配置和用例的可實施情況，為虛擬化的實現和應用提供具體的場景和需求。制定虛擬化影響評估的方法和步驟，以“虛擬化將影響自適應平臺”為前提，制定評估準則，包括功能集群影響評估（涵蓋操作系統接口、執行管理、狀態管理等多個元素）和安全影響評估。其意義在于提供一種系統化

78、的評估方法，確保虛擬化的影響能夠得到全面、準確的評估?？紤]虛擬化相關的約束和假設，包括針對單機上的虛擬化和非虛擬化 AP，需要提供一致的平臺視圖；虛擬化系統中雖然可以存在多個 Machine，但只有一個AP實例運行在給定 Machine 中。其意義在于明確虛擬化的基本約束和假設，為虛擬化的實施提供基礎和前提。確定與虛擬化相關的功能元素和架構組件，功能元素部分用于評估虛擬化對功能集群、清單、安全等的影響，架構組件部分包括在AUTOSAR分層軟件架構中的集成、接口以及使用方法的定義，這些部分將在后續更新和完善。其意義在于明確功能元素和架構組件在虛擬化中的作用和影響，為虛擬化的設計和實現提供指導。3

79、.車輛基礎服務車輛基礎服務軟件層是為多域融合而設計，針對分布式異構芯片環境，提供了一整套跨核、跨域協同的基礎功能與服務。通過標準化的接口和協議，實現了各域控制器之間的無縫連接和數據交換，為上層應用軟件提供了穩定、高效、靈活的開發環境；同時，車輛基礎服務軟件層還具備高度的可擴展性和靈活性，能夠適應未來汽車電子電氣架構的不斷演進和升級。車輛基礎服務軟件層主要包含以下功能：l 跨核協同服務：針對異構多核處理器環境，提供高效的核間通信和任務調度機制，確保實時性中國汽車基礎軟件發展白皮書 5.0025和可靠性；l 電源管理服務：根據整車工作條件調整電源模式，以管控電源效率，合理降低功耗；l 日志管理服務

80、：提供面向域控平臺的整車日志統一管理機制，通過統一的工具進行日志收集和管理；l 信息安全服務：為整車提供系統級的信息安全策略，構建信息安全機制；l 健康管理服務：監控各域控制器的運行狀態，及時發現并處理故障，保障整車系統的穩定性和安全性；l 時鐘管理服務：實現整車時鐘同步，確保各域控制器時間基準的一致性；l 存儲管理服務：提供跨域、跨核的共享存儲解決方案，支持數據的高效訪問和備份；l 診斷管理服務：支持遠程和本地診斷，提高故障診斷和修復的效率和準確性；l OTA 升級服務：實現整車級和域控制器的遠程軟件升級，提高軟件的迭代速度和用戶體驗。目前AUTOSAR規范主要針對單 Machine 的場景

81、進行了詳細定義，但面向智能汽車的 SOA 架構和多域融合的應用開發，AUTOSAR未提供全面的支撐，應用開發者往往需要分別在 CP 和 AP 不同的體系平臺上進行開發，再進行交互設計和集成。在這樣的開發過程下，往往需要系統和軟件的重新設計，以及工程過程重新適配和集成，這也是很多車型項目在量產開發過程后期遇到的工程成本問題。車輛基礎服務中間件可以有效解決上述問題。車輛基礎服務中間件在多域融合的架構下，可以將不同芯片、不同 ECU 甚至不同功能的資源進行協同處理和調用，并打通不同基礎系統間的通信。車輛基礎服務中間件在 AUTOSAR 基礎軟件規范的基礎上進行接口封裝、特性增強和場景擴展，解決快速創

82、新的問題。3.1 車輛基礎服務的適用場景面向分布式異構芯片的架構，“跨域協同”成為汽車軟件功能的硬性需求，作為跨域協同服務的基礎底座，其主要滿足以下場景：1.滿足異構芯片與異構核的場景：在新的電子電氣架構下，域控制器成為了最核心的硬件，域控制器中包含多個異構的處理核心（SoC、MCU及各類專用芯片），為了達成實時性、安全性、高算力、高帶寬等系統需求，往往需要多個異構核進行調度、通信、資源管理更多方面的協同合作，因此跨域協同（包括域控制內異構核之間協同，以及多個域控制器芯片之間協同）的需求越來越多，成為了支撐創新的主要動力和重要基礎。車輛基礎服務中間件可以提供跨域協同需要的基礎能力，例如整車 O

83、TA、整車級健康管理、域控級的診斷協同等。2.整車級 SOA 場景：車輛基礎服務中間件提供整車層面上覆蓋所有控制器的統一 SOA 框架。針對多域融合的場景，打通域間資源協調、管理域間通信、對應用開發提供完整 ECU 級別乃至整車級別開發視角的軟件組件層平臺；借此實現中間層軟硬解耦，應用層軟軟解耦，將整車功能原子化后抽象成可調用的 SOA服務，并制定清晰標準的交互接口，為多車型適配提供一致的開發界面，為汽車應用生態提供統一的開放底座。3.工具鏈融合場景：由于歷史發展的原因，AUTOSARClassic/Adaptive規范針對 MCU 與 SoC 的開發方法學方面有一定程度的割裂，當前的工具鏈實

84、踐也往往是各自開發。而在域控制器架構下，很多功能需要 MCU 與 SoC 進行協同，這就要使用兩套工具鏈分別開發，導致開發難度增加，后續的調試效率也受到很大影響。車輛基礎服務中間件工具鏈可以為用戶提供統一的開發視圖，它集成了跨域服務開發所需的各組件，提供整車跨域跨核應用層所需要的基礎服務，例如健康管理中間件、診斷管理中間件、中國汽車基礎軟件發展白皮書 5.0026存儲管理中間件、核間通信中間件、日志管理中間件、OTA 中間件等模塊的配置與代碼生成。3.2 車輛基礎服務的定義如圖 3.1-2 車輛基礎服務中間件所示，車輛基礎服務中間件是基于 AUTOSAR基礎軟件之上的開發組件，實現基于 AUT

85、OSAR 規范的擴充和增強，同時支持跨核跨域協同的系統級基礎功能，支持健康管理、整車日志、整車時鐘、遠程診斷、OTA 等更加豐富的整車級基礎服務，對用戶提供統一的開發視圖，解決現有AUTOSAR 標準基礎軟件平臺在使用門檻高、新應用功能場景定義不足，以及針對大算力多核異構平臺的跨域應用局限性等問題。針對創新車載應用和新一代電子電氣架構，車輛基礎服務中間件將為汽車應用開發者提供面向整車的通信、診斷、存儲、升級、監控、時鐘等基礎服務框架和接口，加速汽車應用開發的迭代速度。圖3.1-2 車輛基礎服務中間件3.3 車輛基礎服務的功能車輛基礎服務中間件主要包括如下功能：1）核間通信（Inter-Core

86、Comm），在多核異構域控系統中，MCU 依然承擔大量的實時數據的邏輯處理工作，為了減輕 MCU 的負載，需要打通 MCU 與 SoC之間的數據通道，實現 MCU 與 SoC 之間的數據協同。與此同時，還應該提供MCU信號與 SOA 服務之間的轉換功能，以及在以太網上進行服務發布的能力，才能解決信號與服務的跨核雙向快速轉化的問題。因此，本模塊的核心特性應該包括：（1）核間通信協議：面向服務的通信協議，提供 Method 以及 Event 語義；為 MCU 和 SoC 之間提供跨核通信方式，為 SoC 內部不同進程提供進程間的通信方式；（2）信號轉服務通信：提供 MCU 功能在 SoC 進行服務

87、化的能力：l SoC 服務直接映射為 MCURTE 接口或 CAN 信號，SoC 側應用操作 SOA 服務對 RTE 接口或CAN 信號進行設定，MCU 側借助 SWC 使用 RTE 接口即可完成對 SoC 服務的操作。這樣可以對 MCU 上已有的基于 CAN 信號和 RTE 開發的 SWC 直接接入 SOA 架構，實現零成本遷移和資產復用；l 提供完備的 SOAEvent、Method、Getter、Setter、Notifier 語義，覆蓋全面的使用場景；中國汽車基礎軟件發展白皮書 5.0027l 提供可視化工具支持 SOA 服務設計，全自動生成 AUTOSARARXML 與 SOA 代碼

88、，支持低成本、快速的、多樣化的服務設計與應用或 SWC 的開發迭代。2）存儲管理（StorageManagement），存儲中間件為域控應用提供了一套統一的存儲器訪問代理和接口封裝，使應用開發者能夠對應用數據的存儲進行系統層面的統一設計和配置，而無需深入了解底層 AP 和 CP 的接口細節，配合內部的存儲管理策略，可以實現數據和文件的跨核訪問和共享策略管理，具體功能包括：（1）跨核存儲：實現跨核共享存儲，提供 MCU 跨核讀寫 SOC 數據的服務；（2）存儲策略：支持立即存儲、周期存儲、下電存儲等策略；（3）多進程訪問：通過本地網絡通信實現 SOC 內多個進程之間共享鍵值存儲；（4）AUTOS

89、AR 擴展：封裝 AUTOSARAdaptive的 PER 模塊文件讀寫、鍵值讀寫功能接口，新增應用所在目錄下文件、鍵值庫的權限控制，并支持設置文件、鍵值庫存儲策略；（5）壓縮解壓：支持應用目錄下的文件和目錄壓縮，支持將應用目錄下的壓縮文件解壓到應用目錄下的子目錄；（6）查詢應用存儲容量：為應用提供查詢本應用的最大存儲容量、已使用容量、剩余容量；（7）查詢存儲分區容量：支持查詢磁盤分區容量，具體包括查詢容量時的時間、分區名稱、分區總容量、分區已使用容量、分區剩余可用容量、分區已使用容量百分比、分區掛載路徑。3）健康管理（HealthManagement），目前 AUTOSARAdaptiveP

90、latform 的健康管理僅定義了針對自適應平臺應用的健康監控機制，缺乏面向域控場景的系統健康管理定義；健康管理中間件基于 AU-TOSAR 進行了特性增強和擴展，為域控應用提供跨核、跨域的健康和信息收集，以及對操作系統的健康狀態監控，具體功能包括：（1）域內健康報告：報告域內各個 MCU/SOC 的健康狀態（主要是故障信息），健康報告內容包括資源故障、應用故障、Nor-Flash 故障、硬件故障、功能邏輯故障、健康指數、故障上報時的車況信息等；（2）POSIXOS 健康檢測：報告域內各個 MCU/SoC 的實時數據（主要是資源使用情況），實時數據內容包括 EMMC 空間、CPU 使用率、內存

91、占用情況、句柄占用情況、進程信息等，以及心跳監測 MCU/SoC 是否在線。4）時鐘管理（ClockManagement），AUTOSARTS 模塊只定義了 gPTP 等協議棧及其配置的功能；但在域控平臺的使用場景下，需要對車輛的多個時鐘源進行選擇，并對整車各 ECU 的時鐘進行同步。時鐘管理中間件提供多時鐘源管理、跨 ECU 時間同步等功能，保證整車時鐘的一致性，具體功能包括：（1）RTC時鐘源管理：獲取當前RTC時間，或在有更高優先級時鐘源信號時向RTC寫入當前時間信息；（2）NTP 時鐘管理：通過 NTP 協議從 NTP 服務器上獲取當前時間；（3）GPS 時鐘管理：獲取 GPS 模塊提

92、供的時間信息；（4）時鐘源管理策略：用戶可以設置各時鐘源的優先級，自動根據運行時各時鐘源的可用狀態選擇時鐘源作為整車時鐘的基準時間；（5）跨核時鐘同步：基于時鐘管理策略配置確定特定時鐘源的時鐘，并通過 gPTP 協議向其他 ECU發布，保證整車時鐘的一致性。5）電源管理（PowerManagement），ECU 需要根據整車的工作條件調整自身的電源模式，以滿足車輛各 ECU 對電源功耗的需求和控制策略，具體功能包括：（1）電源管理：負責管理域控制器的電源狀態；由運行在 MCU 中的電源管理主控程序，管理其他中國汽車基礎軟件發展白皮書 5.0028Partition 中運行電源管理的 Slave

93、 程序；電源管理主控程序負責維護域控制器整體電源狀態，執行上下電流程；Slave 程序負責同步電源狀態到各個 Partition，并執行主控程序的電源命令；（2）電源模式遷移：支持電源模式在 Gateway（啟動前過度）、Run（正常工作）、Standby（低功耗待機）、Reset（復位）之間進行狀態遷移。6）日志管理（LogManagement），AUTOSARCP 和 AP 標準僅定義了面向單個 Machine 的日志管理機制，但域控制器通常包含多個 MCU/SoC，因此不得不針對每一個 MCU/SOC 進行獨立的日志管理部署；日志中間件對 AUTOSAR 規范進行特性擴展和接口封裝，提供

94、了面向域控平臺跨芯片乃至跨整車 ECU 的日志統一管理策略，域控應用開發者可通過統一的工具進行日志管理，具體功能包括：（1）日志收集：支持跨核、跨域收集，支持以太網、CAN 總線日志收集，支持內核、網卡、CoreDump 等日志收集，支持日志存儲路徑、空間統一規劃管理；（2）日志控制：支持云端和診斷儀控制整車日志，以及日志等級過濾的開關控制；（3）日志導出：支持日志上傳云端、車機以及線上瀏覽。7）診斷管理（DiagnosticManagement），AUTOSAR 規范定義了 DCM 和 DEM，來支持單 Ma-chine 場景下的診斷服務，而面向域控架構的場景下，需要滿足更多更復雜的診斷場景

95、，如遠程診斷、跨核診斷等；診斷管理中間件在 AUTOSARCP 和 AP 的基礎上，需要構建面向跨域的診斷管理和通信機制，具體功能包括：（1）遠程診斷：包括遠程或診斷儀 ODX/OTX 腳本下載、解析、車云交互，以及診斷報告的生成、存儲和上傳；（2）安全認證：支持診斷儀與診斷管理中間件的雙向認證功能；（3）診斷仲裁：支持多診斷儀并發診斷時的仲裁功能；（4）診斷路由：外部設備發送到診斷管理中間件的診斷請求，根據診斷路由表分發到相應的器件中，由器件中部署的 DM 模塊處理診斷請求，處理結果通過診斷管理中間件反饋給外部設備。8）OTA（Over-the-Air），構建面向整車的新型系統級 OTA 方

96、案，包括軟件包下載、刷寫報文路由轉發、刷寫代理、版本號管理及軟件包驗簽、軟件包分發等，同時支持 FOTA、SOTA 刷寫，需要能夠識別多種異常情況，并支持在線識別及處理等，具體功能包括：（1）車云車機交互：l 支持車輛注冊、更新車輛配置、升級檢查；l 支持制車車輛包制作、傳輸；l 支持升級模式設置（立即升級、預約升級、夜間自動升級）；（2）OTA 升級策略：l 支持各域控制器的升級；l 支持符合 ETH、CAN、LIN 規范的 ECU 的升級；（3）OTA 升級激活配置：l 支持注冊激活 OTA 功能；l 支持升級軟件的檢查更新；（4）OTA 升級任務管理：l 支持 OTA 升級包下載管理；l

97、 支持 OTA 升級模式管理（主動升級、靜默升級）；中國汽車基礎軟件發展白皮書 5.0029l 支持分組升級管理，同組 ECU 同升同降；l 支持升級版本管理；（5）OTA 升級階段管理：l 支持升級包同步、回滾、刪除；l 支持升級階段狀態管理，包括軟件包升級環境準備、環境檢查、環境恢復；l 支持 ECU 配電管理；（6）信息安全：l 支持下載軟件包時的安全通信和軟件包的解密/驗簽；l 支持以太網診斷儀刷寫 ECU 時的安全認證。9）信息安全中間件（Cyberseurity），AUTOSARAP 可提供加密計算、密鑰存儲及證書存儲相關接口，但存在接口調用過程繁瑣、場景支持不足等問題；通過構建域

98、控級信息安全中間件，對 APCrypto 接口進行封裝及特性擴展，為域控應用在通信、診斷和升級等方面提供系統級的信息安全策略，具體功能包括隨機數生成、散列計算、對稱加解密、簽名驗簽、證書驗證、證書鏈驗證、導入導出密鑰、導入導出證書、Base64 編解碼等功能。3.4 車輛基礎服務的關鍵技術與實施挑戰車輛基礎服務中間件作為面向 SOA 架構的域控級乃至整車級的基礎服務平臺，是通過服務定義來體現對標準基礎軟件和操作系統的擴展和封裝能力的，因此服務的定義/設計需要遵循一定的規范性要求，才能真正提高軟件架構的魯棒性、軟件的穩定性和系統的整體性能。服務設計作為一個關鍵技術，其基本要求如下：a.服務具有獨

99、立性：即服務設計應與硬件配置和實現無關，與上層功能服務層和下層硬件驅動層解耦，完全獨立；b.服務具有原子性：即設計的服務不可再拆分，作為服務的最小單位和執行實體，為上層功能提供最基礎的執行或采集等功能；c.SOA 增強服務具有通用性：在 AUTOSARCP/AP 的基礎之上，為應用提供領域級的通用基礎能力，如數據存儲、服務信號轉換、服務調試等諸如此類的通用性功能；d.整車級系統服務具有全局性：即該類服務的設計更多關注是整車層面對整車內所有系統能力進行協同和管控，該層服務是對系統基礎服務在整車層面的抽象和封裝，即通過該層服務可以配置和控制系統基礎服務，如整車健康管理服務、整車網絡管理服務、整車時

100、鐘服務、整車電源管理服務等。車輛基礎服務中間件的實施面臨多個挑戰，這些挑戰主要源于不同系統、平臺之間的技術差異、安全要求以及數據交互的復雜性。主要體現為以下幾點：a.技術架構與兼容性挑戰：不同域控制器和系統可能采用不同的技術架構，導致中間件在集成時需要考慮多種技術的兼容性；中間件需要支持多種接口標準并進行相應的轉換和適配。b.性能與效率挑戰：跨域通信涉及網絡延遲、帶寬限制等問題，中間件需要優化數據傳輸策略以提高傳輸效率；同時，中間件需要處理來自不同系統的并發請求并快速響應，這對中間件的并發處理能力和擴展性提出了高要求。c.安全與可靠性挑戰：中國汽車基礎軟件發展白皮書 5.0030中間件需要確保

101、數據傳輸過程中的安全性和隱私保護，防止數據泄露和非法訪問；中間件需要具備高度的可靠性和穩定性，以確保整車系統的正常運行和故障排查。d.部署與維護挑戰：跨域中間件的部署可能涉及多個系統、平臺的集成和配置，部署過程復雜且容易出錯；維護和升級也是一大挑戰，需要開發團隊具備專業的技能和經驗以確保中間件的穩定運行和持續優化。e.法規與合規性挑戰：隨著數據保護法規的日益嚴格，中間件需要確保數據傳輸和處理過程符合相關法規要求；這要求各開發團隊密切關注法規動態并及時調整中間件的設計和實現以滿足合規性要求。3.5 車輛基礎服務 API如圖 3.1-3 車輛基礎服務 API 所示，車輛基礎服務中間件通過封裝下層的

102、基礎軟件和操作系統，對上層提供基礎的跨域協同服務組件和功能接口，為上層平臺和應用提供了更多面向服務開發所需要的服務和接口，接口概覽圖如下：圖3.1-3 車輛基礎服務API 車輛基礎服務中間件為上層應用提供的接口以及對下層組件的接口依賴參考表 3.1-1車輛基礎服務API。表3.1-1 車輛基礎服務API組件SOC 應用層接口MCU 應用接口對 AP 接口依賴對 CP 接口依賴核間通信向應用提供方法（Method）和事件（Event）的服務發布和訂閱接口作為客戶端，為 MCU 側應用提供 SOC 側發送的事 件（Event）數 據，并處理方法（Method）調用；作為服務端，向 SOC 側請求方

103、法（Method）服務。依賴 LT、PHM 和EM 模 塊 所 提 供的接口無中國汽車基礎軟件發展白皮書 5.0031組件SOC 應用層接口MCU 應用接口對 AP 接口依賴對 CP 接口依賴存儲管理文件讀寫功能接口;鍵值讀寫功能接口;設置與查詢應用存儲容量功能接口;壓縮解壓功能接口;查詢存儲分區容量接口;核內共享 KV 存儲功能接口;MCU 與 SOC 跨核共享存儲服務接口MCU 本地回讀與存儲服務接口依賴 PER、LT、PHM 和 EM 模塊所提供的接口；依 賴 NvM模塊。健康管理PHM、系統健康監控、存儲管理等組件向本組件（健康管理組件）發送故障信息接口；PHM 向本組件（健康管理組件

104、）周期發送核間心跳接口。PHM 向本組件（健康管理組件）發送硬重置（HardRe-set）請求接口;PHM，系統健康監控向本組件（健康管理組件）發送實時信息接口監視結果發送接口依賴 PER、LT、PHM 和 EM 模塊所提供的接口依賴網絡連接接口；依賴數據獲取 與 發 送接口。時鐘管理獲取 NTP 狀態接口;獲取時區狀態接口獲取絕對時間、相對時間接口；時間轉換接口；設置、獲取、查找、刪除絕對時間、相對時間預約喚醒接口；查詢預約的絕對時間、相對時間鬧鐘接口;共享電源狀態接口。依賴 LT 和 TS 模塊所提供的接口依賴獲取、設 置 時 間接口；依賴獲取時間 基 狀 態接口;依 賴 StbM模塊。電

105、源管理無重啟 Partition、整板接口；快速下電接口；Partition 下電；獲取 Partition 狀態接口；狀態變化通知接口。延時關機接口。依賴 LT 和 SM 模塊所提供的接口無中國汽車基礎軟件發展白皮書 5.0032組件SOC 應用層接口MCU 應用接口對 AP 接口依賴對 CP 接口依賴日志管理基本類型的打印輸出接口;日志打印等級管理接口打印目標控制接口。依賴 LT 模塊；依 賴 DLT和 STBM模塊所提供的接口。診斷管理安全認證接口;0 x10/0 x11/0 x14/0 x-19/0 x22/0 x27/0 x28/0 x-29/0 x2E/0 x31/0 x34/0

106、x-35/0 x36/0 x37/0 x38/0 x-3e/0 x85 服務接口;功能尋址接口;初始化函數和周期函數;ETH 數據收發接口;CAN 數據收發接口。依賴 LT、PHM 和EM 模 塊 所 提 供的接口依賴ETHTP、CANTP 和DCM 模塊接口。OTA軟件包下載階段管理接口，包括下載、查詢、斷點續傳、完整性檢查等;軟件包處理階段接口，包括處理、防降級、同組升級等;軟件包安裝階段接口，包括升級環境檢查與恢復、升級超時、升級重試、升級控制等接口;升級階段狀態管理接口，包括升級狀態、進度上報，升級結果查詢等接口;版本管理接口，包括版本巡檢、依賴性檢查等接口；升級包處理接口，包括升級包

107、同步、回滾、刪除等接口;配電管理接口，包括 ECU 智能配電，蓄電池補電等操作;車云車機交互接口，包括車輛注冊、升級檢查、車輛包傳輸、升級觸發等接口。升級條件校驗;請求下載、傳輸接口;升級包同步、回滾、刪除等接口;A-B 分區同步接口;網絡通信接口。依 賴 CM、DM、LT和 EM 模塊所提供的接口無4.整車通信總線在軟件的發展史上，對于分布式系統，為了實現軟件復用，開發平臺需要提供一套針對異構節點的統一接口抽象與方法論支撐的通信框架，以實現應用可以一致性的開發和動態部署；從而讓軟件解耦更充分，達成最大限度的軟件資產復用。中國汽車基礎軟件發展白皮書 5.0033傳統的電子電氣架構下，汽車軟件（

108、除了座艙域）是個典型的分布式同構系統，以 MCU 上的軟件開發為主，為了實現針對應用的復用與動態部署，AUTOSARClassic 標準提供了 VFB（VirtualFunctionBus）的概念，基于 VFB 開發的應用，可以在不同的控制器上進行復用與遷移。如今的新電子電氣架構下，域控制器的出現，改變了汽車軟件的底層形態，從分布式同構系統變成了分布式異構系統。雖然“集中式”趨勢越來越明顯，但從整車上看，未來很長一段時間內，汽車內仍然會有多個控制器，仍然依賴異構處理器來承載軟件功能，包括 MCU、SOC、GPU、NPU 等各種架構的處理器；同時用于車內/車外通信的物理總線也越來越多，網絡拓撲越

109、來越復雜，通信協議體量越來越大。因此，AUTOSAR 試圖建立統一的通信框架，使用了基于 SOA 的通信方式，但這部分主要以規范POSIX 系統上的以太網為主；同時為了支持與 MCU 之間基于信號的通信方式，提出了 S2S（SignaltoService），但使用限制較多，使用方法復雜。與此同時，由于各行業的開發者進入汽車軟件領域，其背景和開發習慣各有不同，對于 AUTOSAR 的極其嚴謹的、靜態配置為主的、欠缺靈活性的開發方法學難以適應。因此目前汽車軟件領域急需一種可以滿足靈活部署、動態適應、快速調試、高效協同的開發體系，同時還必須滿足清晰的邊界定義和嚴格的過程要求，因此目前主流的自動駕駛開

110、發者傾向于使用比較靈活的 Topic 類的接口，但是又存在可靠性問題亟待解決?；谝陨闲袠I變革帶來的影響下，目前通信框架（例如 SOME/IP、ROS、DDS 等）都難以滿足行業發展趨勢的要求，亟需一種新的整車通信總線。4.1 整車通信總線的適用場景整車通信總線作為汽車內部信息交互的基礎設施，其適用場景隨著技術的發展而不斷擴展，為智能汽車的多樣化功能提供了堅實的通信基礎，同時也為汽車產業的創新和發展開辟了新的道路。隨著汽車向更高級別的智能化和自動化發展，整車通信總線的重要性將愈發凸顯。車輛內外部需求不斷增加，需要支持車輛與外部網絡間以及內部不同的系統組件間的通信，故不能再局限于單一的通信技術和

111、協議棧，而是需要融合多種通信技術，以適應不同的應用場景和需求。1.多域控制器之間的統一通信管理不同域控制器可能運行者不同的硬件平臺和操作系統，且采用不同的通信協議。整車通信總線可以提供一個封裝層軟件，屏蔽上述差異，實現統一的通信語義。這不僅簡化了系統集成，也大大提高了系統的可擴展性和維護性。2.復雜的域內通信需求在域內通信中，通常需要支持高效的、低延遲的通信協議，以確保系統的實時性和可靠性。例如，在一個車載娛樂系統中，不同的控制模塊之間可能需要快速交換大量的多媒體數據。這種情況下，整車通信總線可以通過支持協議緩存（Protobuf）、快速二進制（FastBinary）等高效序列化協議，以及針對

112、域內通信的優化通道管理，確保數據的快速傳輸和處理。3.不同開發體系和語言的集成隨著新供應商和新技術加入汽車軟件領域，汽車軟件架構需要兼容適配不同的開發語言和技術框架。整車通信總線通過提供多語言編程接口和兼容的開發體系，確保不同團隊開發的模塊可以快速集成，這在跨平臺、跨團隊開發時尤為重要，特別是在需要集成第三方系統（如 ROS）時，整車通信總線可以提供必要的接口抽象能力，可以確保系統的互操作性。4.面向自動駕駛的高性能數據處理自動駕駛汽車需要處理大量傳感器數據，并實時做出決策。這要求整車通信總線不僅能夠高效地傳中國汽車基礎軟件發展白皮書 5.0034輸和處理數據，還需要提供支持數據埋點、QoS

113、策略等高級功能，以確保數據的可靠性和實時性。此外，自動駕駛系統中的多個傳感器和控制器之間的數據同步和信息融合，也是整車通信總線的一個重要應用場景，通過緩存融合與同步功能，框架可以自動處理數據的收集與打包，并確保數據的一致性。5.車云之間的通信隨著車聯網技術的普及，車輛與云端之間的通信需求也在不斷增加。整車通信總線通過支持多種網絡協議（TCP、UDP、SOME/IP、DDS），可以確保車輛可以在不同的通信環境中與云端順暢互聯，并支持快速適配和遷移，這為遠程診斷、OTA 升級和智能網聯服務提供基礎能力。4.2 整車通信總線的定義整車通信總線是為了簡化復雜車載系統的設計和開發提出的一種面向服務架構(

114、SOA)的中間件解決方案。它將業務邏輯實現與特定目標平臺的通信層細節隔離開來，使用與編程語言無關的接口模型定義來生成完整的服務 API 和底層傳輸層和序列化層，支持跨域以及域內通信，為分布式異構網絡實現高效、可靠、安全的通信。整車通信總線的核心能力在于為分布式異構系統，尤其是以域控制器為核心的整車網絡提供一個抽象且統一的通信語義平臺。該框架通過高度抽象的通信模型和協議轉換機制，實現對整車級通信資源的有效管理和優化配置，可以滿足車內/車外的高效穩定通信需求。如圖 3.1-4 整車通信總線所示，整車通信總線抽象了各種軟件應用程序和 ECU 之間的底層通信協議，這種抽象讓開發人員擺脫項目環境特定的通

115、信機制，并允許他們專注于業務代碼的開發，而不受特定于操作系統或項目部署設置（網絡拓撲、協議棧）的細節的影響?；谡囃ㄐ趴偩€開發的應用程序需要在車輛內的不同平臺之間移動時基本無需在接口進行任何更改，做到開發一次，部署到多個平臺或者 ECU，這大大縮短了開發過程中的功能交付時間，縮短了整個產品的交付周期。具體而言，整車通信總線定義為一個多層次的通信中間件，它跨越了不同操作系統、物理總線、網絡協議和開發語言的界限，為整車通信提供了一種標準化的交互接口。該框架不僅整合了車內復雜的通信需求，還通過抽象化的通信語義，使得上層應用開發能夠忽略底層硬件和協議的差異，從而大大簡化了開發流程，提高了系統的可維護

116、性和可擴展性。在架構設計上，整車通信總線采用模塊化設計思想，將通信服務劃分為接口層、域內通信層、域間通信層等多個層次，每個層次針對特定的通信場景提供專業的解決方案。通過這種方式，整車通信總線不僅實現了對多樣化通信場景的統一封裝，還保證了不同場景下通信的高效性和可靠性。圖3.1-4 整車通信總線 中國汽車基礎軟件發展白皮書 5.0035整車通信總線的主要特點如下：l 支持面向服務（SOA）的軟件架構，可以支持跨域的服務調用。l 基于接口模型自動生成的 API 接口，并自動生成序列化和傳輸層，手動編碼僅剩業務邏輯，顯著減少工作量，并降低引入錯誤的風險。l 業務代碼與平臺的底層通信層細節分離，平臺的

117、任何更改都不會影響業務邏輯代碼。l 使用與平臺無關的接口定義語言來定義接口，應用程序需要在車輛內的不同平臺之間移動時無需進行任何更改，可以做到開發一次，部署到多個平臺或者 ECU。l 提供完善的通信機制和遠程調用機制，無論服務或客戶端應用程序在何處運行（本地或遠程）以及使用何種通信機制，應用程序的實現始終相同。4.3 整車通信總線的功能為了促進整車系統中各組件之間的通信和協作，提高異構場景中整車通信的互操作性和可擴展性，就需要實現具有統一通信界面的整車通信總線。統一通信框架可提供整車標準化統一接口，簡化整車系統中不同組件之間的通信過程，定義數據傳輸的規則、消息格式、通信協議和安全措施，用于管理

118、不同子系統、組件和傳感器之間的通信，可簡化系統的復雜性，提升通信的效率和可靠性，提高系統的靈活性和可維護性，有助于實現車輛智能化、自動化和網絡化。整車通信總線提供如下主要功能：1.跨系統和協議的一致性封裝整車通信總線實現了對各類系統、物理總線、網絡協議和開發語言的統一封裝，提供了一致性的接口。無論是不同的操作系統、網絡架構還是開發環境，都能夠通過框架進行無縫集成和互操作，極大簡化了跨平臺開發的復雜性。2.多樣化通信語義支持整車通信總線為應用層提供了豐富的通信語義支持，包括數據驅動的 Topic 模型和方法調用的Method 模型。這使得開發者能夠以更靈活的方式進行應用開發，類似于 SOME/I

119、P 和 DDS 等協議，滿足不同應用場景下的通信需求。3.全場景通信支持整車通信總線適配多種通信場景，支持從 RTOS、POSIX、Android 等多種操作系統，并且兼容 CAN、LIN、以太網、PCIe、SPI 等多種物理通信總線。無論是車內外不同節點間的通信，還是域控制器內部的多處理器間通信，框架都能夠提供穩定可靠的支持。4.高效核間通信在多核架構的車載系統中，整車通信總線確保了 MCU 與 SOC 之間的高性能數據交換能力，支持與AUTOSAR 開發體系的直接對接，優化了核間通信效率，確保了系統的整體性能和響應速度。5.靈活的序列化機制整車通信總線提供靈活的序列化支持，通過自動配置，優

120、化數據傳輸的序列化方式，確保不同部署場景下的通信效率。應用層與底層序列化實現完全解耦，框架能夠根據部署環境自動推導出最優的序列化策略，簡化開發和維護。6.端到端 QoS 保障整車通信總線通過端到端的質量服務保障，支持多 Topic 數據的緩存融合與同步，確保數據在傳輸過程中的及時性和完整性。無論是實時性要求高的應用場景，還是對數據可靠性有嚴苛要求的場景，框架都需要提供強有力的支持。中國汽車基礎軟件發展白皮書 5.00367.域內消息與整車協議映射整車通信總線內置 CMBridge 功能，實現域內消息與整車 SOME/IP 協議的映射，確保不同域控制器之間的通信能力。這種映射機制為整車通信架構提

121、供了強大的靈活性和擴展能力。8.動態任務編排與智能調度整車通信總線具備動態任務編排和智能調度能力，能夠根據系統的運行狀態和負載情況，靈活調整任務的執行順序和優先級，從而提升系統的整體運行效率和資源利用率。9.數據監控與仿真能力整車通信總線支持全面的數據監控與仿真功能，為開發者提供了實時的數據流監控和仿真測試支持。這一能力有助于在系統開發和調試過程中發現隱藏問題，確保產品在集成前達到最佳狀態。4.4 整車通信總線的關鍵技術與實施挑戰整車通信總線的設計與實現需要在多個層面上進行創新與突破，從統一語義的接口設計到安全穩定的通信機制，每一個環節都涉及復雜的技術挑戰。解決這些挑戰不僅需要在技術上提供創新

122、的解決方案，還需要在開發流程、工具鏈支持、生態系統建設等方面進行系統性的優化。未來的通信框架將決定整車電子電氣架構的效率和可靠性，是推動智能化和自動化發展的核心基礎。首先，隨著汽車智能化、電動化、網聯化的發展，傳感器數量和數據量的增加對電子電氣架構提出了更高的要求。傳統的分布扁平式電子電氣架構因缺乏主導分層融合的主節點，導致硬件資源浪費、線束布置復雜、基礎軟件難以標準化等問題。為了應對這些挑戰，需要升級現有電子電氣架構，通過硬件資源共享、軟件標準化簡化整車布置，實現輕量化和功能優化。其次，中央計算平臺的引入為整車通信帶來了新的技術挑戰。高算力的異構芯片需要在不同芯片上進行整車功能部署和資源劃分

123、，這要求具備良好的系統、硬軟件架構設計能力，以及持續集成與交付的軟件開發體系。再次，開放式平臺的構建也是整車通信總線的一個重要方面。它要求硬件系統具備靈活的可擴展性，并建立開放的軟件生態，包括穩定的操作系統、底層驅動、虛擬化環境以及統一的中間件技術和服務接口。再次，在安全性方面，整車通信總線需要面對日益增長的網絡安全威脅。隨著汽車電子化程度的提高，車輛可能成為黑客攻擊的目標。因此，需要采取有效的網絡安全措施，如數據加密、身份驗證和訪問控制，以保護車輛通信不受未授權訪問和攻擊。此外，車聯網通信的低時延和高可靠性要求也是整車通信總線需要解決的關鍵問題。例如，遠程駕駛、自動泊車等場景要求端到端的時延

124、達到毫秒級，甚至是微秒級，可靠性要求極高。這就需要 5G 車聯網技術的支持，但 5G 技術在車聯網領域的應用還面臨諸多挑戰，如與公眾通信的區別、上下行時隙配比問題、頻率資源分配等。最后，自動駕駛汽車的通信力和抗干擾能力也是整車通信總線需要重點關注的領域。自動駕駛汽車需要在動態多變的道路環境中進行感知和決策，這就需要強大的通信能力和抗干擾技術來保證車輛能夠準確獲取環境信息并做出正確的決策?；谝陨险撌?，可以總結出如下幾個要點的關鍵技術和實施挑戰：1.統一語義的接口設計關鍵技術：l 分布式系統的集中式開發視圖：在面對不同物理總線、網絡協議和開發語言的分布式異構系統時，統一語義接口的設計是關鍵。需要

125、提供一種能夠在不同系統和平臺之間保持一致性和兼容中國汽車基礎軟件發展白皮書 5.0037性的接口，確保開發人員能夠以一種集中式的方式進行開發和部署。l 統一的服務接口語義：通過標準化的服務接口語義（例如，SOME/IP 和 DDS 協議的封裝），開發者可以在分布式系統中實現組件的統一管理和部署。實施挑戰：l 跨域協同的復雜性：由于不同域（如動力域、智駕域等）有不同的實時性和安全性要求，如何在不犧牲個性化需求的情況下實現統一的接口設計，是一個主要挑戰。l 工具鏈兼容性與開發便捷性：現有的 AUTOSAR 工具鏈在便利性方面還有提升空間，特別是在面向服務的通信中，如何簡化 IDL（arxml）生成

126、與修改過程，降低開發難度，是重要的挑戰。2.多層次的組件設計與服務化通信關鍵技術：l 面向服務的通信架構：通過采用 SOME/IP、DDS 等面向服務的通信協議，實現跨不同開發場景的靈活組件復用，同時確保系統的嚴謹性和可靠性。l 開源中間件的集成：例如，將 ROS2 等開源中間件整合進整車架構中，利用其成熟的生態系統加速算法和應用的開發，同時提供更加輕量化的接口修改方式。實施挑戰：l 開源框架的量產適應性：ROS2 等開源框架雖然具備強大的生態，但其龐大的代碼量和開源性質可能在量產階段帶來風險。如何保證這些開源組件在汽車應用中的安全性和穩定性，并確保其與傳統 AUTOSAR 體系的兼容，是關鍵

127、問題。l 異構系統的統一部署：如何在 MCU、SOC 和 Android 系統上實現統一的通信框架，并保證各平臺之間的協同工作，是需要解決的難題。3.生態系統的友好性與分布式開發支持關鍵技術：l 分布式協同開發：為了支持多方異地、分時開發，需要通信框架能夠靈活適應不同開發周期和組織的需求，確保各模塊在開發過程中的接口穩定性和兼容性。l 模塊化集成與擴展性：隨著架構層次的細化，需要具備強大的模塊集成能力，將不同開發周期和要求的模塊快速集成到現有系統中。實施挑戰：l 接口穩定性與版本管理：在多方開發的情況下，如何有效管理接口的變更和影響，是一個重要的實施挑戰。l 成熟模塊的適配性：將已有的成熟模塊

128、與新的架構無縫對接，同時保持開發和測試的效率，是另一個需要解決的問題。4.邊界網絡節點的支持關鍵技術：l 多網絡協議的兼容性：通信框架需要能夠支持多種網絡協議，并作為邊界網絡節點將不同領域的成熟組件無縫對接，確?？缇W絡、跨領域的數據傳輸與集成。l 邊界節點的動態適應性：實現邊界節點的動態配置和適應能力，確保在多種通信協議下能夠保持通信的一致性和有效性。中國汽車基礎軟件發展白皮書 5.0038實施挑戰：l 網絡協議的復雜性：如何在不同網絡協議之間實現無縫轉換，并確保通信的實時性和數據完整性，是主要挑戰之一。l 統一管理與控制：在實現多網絡協議兼容的同時，如何保證系統的整體管理與控制能力不被削弱，

129、也是一個需要解決的問題。5.安全與穩定的通信機制關鍵技術：l 安全通信協議的集成：需要在通信框架中集成安全協議，確保數據在傳輸過程中的機密性、完整性和真實性，防止非法訪問和數據篡改。l 穩定的實時通信：確保通信的實時性和高可用性，特別是在涉及安全關鍵應用（如自動駕駛）的場景下，需要具備應對各種通信故障的能力。實施挑戰：l 安全與性能的平衡：在確保通信安全的同時，如何不影響系統的性能和實時性，是一個關鍵的平衡點。l 量產階段的穩定性驗證：如何在量產之前充分驗證通信框架的穩定性，特別是在大規模并發通信和復雜網絡環境下的表現，是一個不可忽視的挑戰。4.5 整車通信總線 API整車通信總線針對不同的數

130、據來源提供了統一的接口，屏蔽不同的物理總線與通信協議層，對不同的 Channel 做封裝，向上層應用提供統一操作語義的接口，通過同一套語義的 API 及配置方式，實現整車不同場景下的數據傳遞。具體接口信息如表 3.1-2 所示：表3.1-2 整車通信總線API模塊接口描述CommonTypeTimer定時器，實現定時任務。PodMessage定義使用內存原始拷貝方式格式化的通信消息類型。RawMessage定義可變長度的通信消息類型。MessageInfo定義消息的其它元數據，如發送時間、接收時間、生成時間等。Executor執行器，提供基礎的執行線程環境，用于執行異步消息處理回調、定時器回調

131、。Node所有通信對象（如 Reader、Writer 等）、自定義 Timer，都是從 Node創建出來的，并且和Node 關聯。TopicWriter消息的發布者。Reader消息的訂閱者，當 Writer 發送消息后，Read-er 會收到數據并調用回調。MethodServer實現了服務端的相關功能。Client實現了客戶端的相關功能。中國汽車基礎軟件發展白皮書 5.0039模塊接口描述QoSReaderQoS定義了 Reader 端的 QoS 策略。WriterQoS定義了 Writer 端的 QoS 策略。FusionandFilterCacheFusionSynchro-nize

132、r實現了基于時間規則的緩存與融合同步。SchedulerPerformanceScheduler高并行調度器，帶任務優先級的高并行執行。PersistenceScheduler綁定調度器，任務可以綁定指定的線程；如果任務不指定線程，則通過 Round-Robin 方式綁定到線程。CyclicScheduler周期任務調度器，支持周期任務調度。整車通信總線向上層應用提供了一套和諧一致的 API，其內部對底層通信協議進行了封裝，包括TCP/IP 協議、ZeroMQ 協議、DDS 協議、共享內存等。同時為了更方便上層應用的開發整車通信總線使用動態配置方式，當上層應用切換通信協議時，不需要修改任何代碼

133、，只需要修改相應的配置文件即可。整車通信總線還支持與第三方標準的 DDS 服務和 ZeroMQ 服務進行數據傳遞。5.整車數據處理框架隨著汽車向智能化、電動化和網聯化的方向發展，軟件和計算能力逐漸成為汽車產業的關鍵因素。作為一種重要的資源，數據成為未來軟件能力的重要創新源泉，數據相關的特性也成為創新業務的新賽道，包括數據集成與融合、云計算與邊緣計算的結合、數據安全與隱私保護、數據驅動的智能服務等，因此整車數據相關的需求越來越多，業務邏輯越來復雜，將業務邏輯與數據進行分離的必要性也越來越明確。整車數據處理框架致力于數據與業務邏輯的分離，需要通過統一的視圖將數據處理封裝起來，從而使得業務邏輯簡單化

134、，提高開發效率；因此，整車數據處理框架需要提供高性能的數據存取和簡單易用的 API 接口，支持數據快照功能和多種序列化策略，實現數據的同步與共享。其核心在于數據變化條件的檢測機制和基于數據的動作執行框架，支持分布式共享，并簡化了服務應用的開發。該框架通過接口層、核心層和調度層的高效設計，為應用提供穩定可靠的數據服務，同時保證了數據的實時性和一致性。此外，通過與整車通信總線的無縫銜接，該框架實現了數據的分布式共享，進一步增強了系統的靈活性和可擴展性。整車數據包括但不限于以下幾個方面：l 車輛基本數據：包括車輛標識數據、車輛屬性數據、核心零部件標識數據、車輛鑒別數據、車輛維保數據等。l 感知數據：

135、涵蓋傳感器數據（如激光雷達數據、毫米波雷達數據、攝像頭數據等）、地圖數據、融合數據等，這些數據通過車載傳感器獲取并經過處理，用于車輛的感知算法。l 決策數據：包括駕駛員操作數據、遠程操作數據和系統決策數據，這些數據對車輛的行駛和操作有直接影響。l 運行數據：涉及整車狀態數據、系統及部件狀態數據、安全日志數據等，這些數據反映了車輛的實時運行情況。l 其他數據：包括用戶身份標識數據、用戶與座艙交互數據（非操控類數據）、OTA 數據、V2X數據等，這些數據關聯用戶交互和車輛通信。5.1 整車數據處理框架的適用場景在現代汽車的快速發展背景下，整車數據處理框架的適用場景日益廣泛，支持以下應用場景，包括中

136、國汽車基礎軟件發展白皮書 5.0040但不限于：l 個性化駕駛體驗：利用車端底盤、駕駛員等數據信息，結合云端大模型進行訓練，優化駕駛感，提供舒適且適合不同駕駛習慣的駕駛體驗，還能提高道路交通的安全性和效率。l 智能輔助系統：通過分析駕駛員的行為數據，車輛可以提供更加智能的輔助駕駛功能，如自動泊車、自適應巡航控制等。l 預測性維護：通過車輛的運行數據，預測車輛的維護需求，減少意外故障，提高車輛的可靠性和安全性。l 能源管理：利用車輛的行駛數據和環境數據，優化能源消耗，提高電動汽車的續航里程。整車數據處理框架的適用場景涵蓋了從分布式系統的數據同步到大數據應用的基礎支撐，從簡化應用開發到促進數據融合

137、的多個層面。它不僅為現代汽車電子系統提供了強大的數據管理能力，還為汽車行業的技術創新和業務發展開辟了新的道路。通過整車數據處理框架的應用，汽車制造商能夠更好地應對市場的快速變化，滿足消費者對智能化、網聯化汽車的需求。5.2 整車數據處理框架的定義隨著汽車新業務的發展和新技術的介入，汽車軟件的復雜度大幅增加，業務邏輯越來越復雜，數據協同需求越來越細致，導致汽車軟件的體量、耦合性、維護難度都大幅增加。因此，將業務邏輯與數據治理分割開進行處理，標準化數據定義和使用方法，成為汽車軟件的下一個解耦關鍵點。整車數據處理框架就是為了解決“數據與邏輯”分離的問題而提出的，可以提高軟件的可維護性、可復用性與穩定

138、性。該框架的核心在于構建一個高效、統一、靈活擴展的數據處理界面，使得車輛各系統間的數據能夠同步、共享，并且能夠按需觸發相應的邏輯處理。如圖 3.1-5 整車數據處理框架所示，在整車數據處理框架中，數據被視為獨立的實體，與具體的業務邏輯相分離。這種分離可以通過一系列功能和機制來實現，如 AUTOSARClassic 標準中的 RTE 框架，它允許應用專注于數據本身，而無需關心數據的接收與發送細節。隨著汽車通信技術的發展，整車數據處理框架進一步擴展了其功能，以適應更大的數據量、更多樣的協議類型以及動態的通信需求。圖3.1-5 整車數據處理框架 整車數據處理框架的關鍵組成部分包括：l 數據中心：負責

139、整車數據的存儲、管理和優化，支持快速篩選和服務管理，支持數據快照，實現內存數據到非易失存儲的映射，確保了數據的持久性和一致性。中國汽車基礎軟件發展白皮書 5.0041l 數據采集：提供與不同系統應用通信的接口，支持多種網絡協議和數據類型，使得數據能夠在整車范圍內高效傳輸。l 數據服務：允許用戶配置數據更新、超時和定時觸發等通知方式，通過內置的調度引擎和觸發式服務，簡化了傳統服務應用的開發方法。在整車數據處理框架中，數據的分類和分級遵循一系列原則，包括合規性、科學性、實用性、擴展性、時效性和穩定性。數據分級則基于數據的危害性和重要性進行評估，以確定數據的敏感度和保護級別。整車數據處理框架的設計考

140、慮到數據存儲、數據處理、數據分析、數據安全、實時性、可擴展性、可靠性和開放性等多方面因素。整車數據處理框架的優勢在于：l 高性能：采用讀寫分塊、零拷貝、共享內存等關鍵技術，實現低時延、高吞吐的數據存取，保證了業務數據存取的實時性。l 易用性：API 接口簡潔明了，支持多種編程語言，使得開發者能夠輕松實現數據的序列化、反序列化以及觸發相應的邏輯處理，降低了應用開發的復雜性。l 兼容性與擴展性：能夠與不同的消息框架和數據類型定義無縫銜接，支持分布式系統的數據共享，適應了整車級的數據處理需求?？傮w而言，整車數據處理框架可以為汽車軟件開發提供一個強大的基礎設施，它通過優化數據管理能力和數據服務，可以促

141、進整車電子系統的智能化和網聯化，為汽車行業的創新發展奠定堅實的基礎。5.3 整車數據處理框架的功能整車數據處理框架旨在構建一個高效、靈活的數據服務中心，以實現數據與邏輯的徹底分離，提升現代軟件的可維護性、復用性與安全性。為整車數據的統一處理提供了強有力的支持，確保了數據的高效同步與共享。整車數據處理框架的主要功能如下：l 數據采集：整車數據處理框架能夠從車輛的各個傳感器和控制器中獲取數據，并可以進行降頻的數據收集，即抽幀，為上層業務提供遵守合適規則的、真實需要的數據。l 數據存儲：管理數據的物理存儲和邏輯組織，提供數據存儲訪問接口。l 數據快照：整車數據處理框架具備實時數據快照的能力，這意味著

142、它能夠將內存中的數據狀態在任何時刻映射到非易失性存儲中。這一功能對于故障診斷、系統恢復以及數據記錄至關重要。它確保了即使在系統發生故障的情況下，也能夠通過快照恢復到故障前的狀態，保障了車輛數據的完整性和安全性。l 多種序列化策略：為了適應不同系統、網絡協議和開發語言的數據交換需求，整車數據處理框架支持多種序列化策略。這些策略包括但不限于 JSON、XML、協議緩存（Protobuf）等，且用戶可以根據具體需求進行配置，以實現最佳的數據共享和傳輸效率。l 統一的數據處理單元：作為整車數據的統一處理模塊，是整車數據處理框架的核心組件。它不僅負責數據的存儲、管理和分發，還提供了數據融合、篩選等策略，

143、確保了數據的一致性和準確性。l 高性能存?。赫嚁祿幚砜蚣懿捎昧讼冗M的讀寫分塊、零拷貝和共享內存技術，大幅提升了數據存取的性能。這些技術的應用，使得數據存取具有低時延和高吞吐的特點，同時減少了資源占用，非常適合于量產環境。中國汽車基礎軟件發展白皮書 5.0042l 數據調度引擎：整車數據處理框架的數據調度引擎為用戶提供了靈活的配置選項，支持數據更新、數據超時和定時觸發等多種通知方式。用戶可以利用謂詞系統配置復雜的邏輯表達式，并定義自定義命令來執行特定的動作，從而實現高度定制化的數據處理流程。l 數據安全與合規性：實施數據保護措施，確保合規性，并處理數據訪問請求和審計，提供數據訪問控制、加密、

144、脫敏、合規性檢查和審計日志接口。由此可見，整車數據處理框架具有如下特點：l 支持分布式系統的數據同步與共享：隨著汽車電子系統的復雜性日益增加，分布式異構系統的數據同步與共享成為了一個亟待解決的問題。整車數據處理框架通過提供數據快照功能，實現了內存數據到非易失存儲的映射，保證了數據的一致性和可靠性，確保不同系統間的數據實時同步，為整車提供高效的數據服務。l 支持數據與邏輯分離的開發模式：整車數據處理框架推動了數據與邏輯分離的開發模式，這種模式在現代軟件開發中至關重要。在傳統的 MCU 架構和新興的以太網總線、SOA 開發方式中，整車數據處理框架能夠有效處理動態分配的通信資源，滿足多樣化的數據傳輸

145、需求。適用于對系統性能和擴展性有極高要求的車輛系統。l 支持高效的數據處理與緩存策略：整車數據處理框架為整車數據提供了高效的處理和緩存策略。它能夠根據數據的使用需求，提供多種觸發策略，實現數據的高效利用。在自動駕駛、ADAS等實時性要求高的應用場景中，能夠確保數據的快速響應和處理，提升系統的整體性能。l 支持面向大數據應用的基礎組件：整車數據處理框架作為高性能 Cache 系統，為大數據應用提供了堅實的基礎。它不僅支持高性能的數據中心，還提供了高性能的謂詞系統，為整車數據服務提供了強大的支持。在車輛健康管理、遠程信息處理等大數據應用場景中，整車數據處理框架能夠有效支撐數據的采集、存儲和分析。l

146、 支持多網絡協議和數據類型的兼容性：整車數據處理框架具備良好的兼容性，能夠支持多種網絡協議和數據類型。這使得它能夠無縫對接不同的車輛系統，無論是在 CAN 網絡、以太網總線還是其他新興通信協議下，都能夠穩定運行。l 促進跨平臺和跨系統的數據融合：在整車數據處理框架的支持下，不同平臺和系統之間的數據融合變得更加容易。它為開發者提供了一個統一的接口和數據處理機制，使得跨平臺的數據集成和融合成為可能。對于提升整車的智能化水平和用戶體驗具有重要意義。整車數據處理框架作為汽車智能化發展的關鍵技術，通過其高性能的數據處理和服務能力，為車輛提供了實時、可靠的數據支持。它不僅實現了數據的高效管理，還簡化了開發

147、流程，提升了系統的集成度和可維護性，為智能駕駛和車輛監控等高級功能奠定了堅實基礎，是推動汽車行業向更高效、智能化方向發展的關鍵平臺。5.4 整車數據處理框架 API整車數據處理框架負責收集和存儲整車數據，以及數據丟失、錯誤和延遲處理，實現數據的存儲、查詢和更新，以維護數據的一致性和完整性。具體接口信息如表 3.1-3 所示：中國汽車基礎軟件發展白皮書 5.0043表3.1-3 整車數據處理框架API模塊接口描述DataCenterOpen表示打開數據庫。Close表示關閉數據庫。Set表示更新數據庫中數據。Get表示從數據庫中獲取數據。GetHistoryValue表示獲取所有歷史緩存數據。G

148、etPreviousValuesByTime表示從過去的指定時間范圍內獲取數據。GetFutureValuesByTime表示從未來的指定時間范圍內獲取數據。GetValuesByTime表示在指定時間范圍內獲取數據。5.5 整車數據處理框架的關鍵技術與實施挑戰隨著智能化推進，整車數據處理框架的角色愈發關鍵，需準備應對技術進步帶來的復雜性與不確定性，確保在動態市場中保持領先，助力汽車行業的持續創新與發展。在探討整車數據處理框架技術與挑戰時，我們既要審視當前技術發展，又要預見汽車行業未來趨勢。整車數據處理框架的關鍵技術：l 軟件架構升級：隨著汽車行業向軟件定義汽車轉變，軟件架構的升級成為必然。面

149、向服務的架構（SOA）方法論的應用，使得汽車硬件能力得以服務化，這不僅提高了資源利用率，還增強了系統的靈活性和可擴展性。通過 SOA 標準化的接口設計，整車數據處理框架能夠實現不同服務組件之間的無縫對接，從而提升系統的整體性能和可靠性。l 標準化接口：在整車數據處理框架中，接口標準化是實現跨車型、跨零部件供應商數據共享的關鍵。通過標準化接口，可以大大減少軟件開發過程中的重復工作，降低復雜度，同時確保了不同系統之間的兼容性和可遷移性。l 數據快照能力：數據快照功能為整車數據處理框架提供了內存數據到非易失存儲的映射能力，這對于故障診斷、系統恢復以及數據記錄至關重要。通過快照功能，可以在任何時刻捕捉

150、系統狀態，為后續的分析和優化提供寶貴的數據支持。l 高性能存取技術：通過采用讀寫分塊、零拷貝、共享內存等先進技術，整車數據處理框架實現了高性能的數據存取。這些技術降低了數據存取的時延，提高了吞吐量，同時減少了資源占用，非常適合于資源要求苛刻的場景。l 可配置的采集精度：車端數據庫應具有高采集精度，支持采集原始頻率的信號數據，以確保獲取到的數據準確度滿足項目需求。支持采集原始數據最小周期 10ms；支持云端可配置采集上傳周期，支持自定義數據上傳的數據頻率。l 數據管理策略：車端數據庫應支持數據降頻功能，在支持原始頻率信號存儲和上傳的基礎上，可按照業務部門實際需求自定義指定信號和頻率上傳，實現最小

151、數據量回傳/按需回傳策略。整車數據處理框架的實施挑戰：l 技術架構挑戰：隨著汽車電子電氣架構的復雜化，軟硬件數量的增加，任何部件的增加、修改、更新都會對整車產生影響。未來的整車軟硬件數量可能增加 10 倍以上，這將帶來巨大的挑戰。為了應對這一挑戰，整車數據處理框架需要具備高度的靈活性和可擴展性，以適應不斷變化的中國汽車基礎軟件發展白皮書 5.0044技術需求。l 安全和隱私保護挑戰：汽車行業的快速發展也帶來了安全和隱私保護的挑戰。測試時間長、代價高，安全漏洞可能導致品牌和用戶粘性受損。整車數據處理框架需要采取有效的安全措施，包括數據加密、訪問控制和異常檢測等，以確保數據的安全性和隱私性。l 組

152、織流程挑戰：整車廠需要建立適應新架構的組織流程，以支持敏捷開發和接口測試。這意味著需要對現有的開發流程進行重構，以適應快速變化的軟件需求。此外，組織內部需要建立跨部門的合作機制，以確保整車數據處理框架的順利實施。l 生態協同挑戰：軟件定義汽車的發展需要上下游企業的協同合作，包括軟件公司、硬件供應商和整車企業。整車數據處理框架需要與這些企業建立緊密的合作關系，以確保數據的一致性和互操作性。同時，整車數據處理框架還需要與行業標準和組織合作，以推動整個行業的協同發展。l 數據孤島問題：因車端數據來源廣泛，不同數據源之間可能存在信息孤島，導致數據整合和分析的難度增加。因此需要通過建立統一的數據平臺和數

153、據交換標準，打破數據孤島，實現數據的整合和流通。此外，利用先進的數據集成和融合技術，提高數據處理的效率和準確性，比如SOA 架構就是典型的解決數據孤島的解決方案。l 數據出境安全管理挑戰：智能網聯汽車收集的數據可能包含敏感的地理和個人信息，數據出境時需要符合嚴格的安全評估和監管要求。因此在向境外提供數據時，應當通過國家網信部門組織的數據出境安全評估，并在評估通過的基礎上，確保數據出境活動符合評估時確定的目的、范圍、方式和數據類型。同時，監督接收方按約定使用數據，并處理用戶投訴。綜上所述，整車數據處理框架的實施挑戰是多方面的，涉及技術架構、安全性和生態協同等多個方面。為了應對這些挑戰，需要整車廠

154、和合作伙伴共同努力，建立一個高效、安全、協同的生態系統。這不僅需要技術創新，也需要組織流程的優化和行業合作的加強。只有這樣，才能確保整車數據處理框架的成功實施，推動汽車行業的持續發展。（二）AI 大模型與中間件AI 與車端基礎類庫的結合是智能網聯汽車（ICV）和自動駕駛技術發展的關鍵組成部分。從 AI 視角來看，車是一系列數據與執行器的結合體，車端需要提供給 AI 的是運行數據、控制器與網絡拓撲的抽象模型，AI 基于這些抽象元素進行分析、預測和決策。這個過程中，需要車端提供一系列的基礎類庫，來為AI 開發和運行提供基礎功能支持，基礎類庫包括整車分布式異構架構下車端的通信抽象、數據抽象、車輛基礎

155、服務，以及與車輛系統隔離開來的 AI 基礎服務層。隨著 AI 技術和 AI 應用的不斷發揮在那，我們可以期待更多、更高效、更強大的車端基礎類庫的出現，進一步推動智能網聯汽車的發展，并反哺推動人工智能更全面、更完善的演進趨勢。1.AI 大模型技術對中間件的影響AI 大模型技術對中間件提出了更高的性能要求，但同步也推進了中間件智能化的發展。l 數據處理能力：隨著 AI 大模型在汽車中的應用，數據量呈指數級增長。汽車中間件需要具備更強的大數據處理能力，以確保能夠快速、準確地傳輸和處理 AI 大模型所需的數據。例如，自動駕駛場景下，大量的傳感器數據需要實時傳輸給 AI 大模型進行分析，中間件如果處理速

156、度跟不上，就會影響駕駛安全和決策的及時性。l 兼容性需求：AI 大模型可能不斷更新算法和功能，汽車中間件需要具備更好的兼容性，以適中國汽車基礎軟件發展白皮書 5.0045應不同版本的 AI 大模型與汽車不同硬件和軟件系統的對接。比如，當 AI 大模型從一個版本升級到另一個版本，中間件要能夠保證與新的 AI 大模型以及汽車上原有的其他系統（如車載娛樂系統、車輛控制系統等）繼續正常協作。l 自適應功能：AI 大模型的智能化特性促使汽車中間件向智能化方向發展。中間件需要能夠根據汽車的運行狀態、用戶需求以及 AI 大模型的輸出自動調整數據傳輸策略、優化系統資源分配等。例如，當車輛處于高速行駛狀態時，中

157、間件根據 AI 大模型對路況的分析結果，自動調整數據傳輸優先級，優先保障與安全相關的數據傳輸到 AI 大模型進行分析處理。l 故障診斷與預測能力：借助 AI 大模型強大的數據分析能力，汽車中間件可以增加故障診斷和預測功能。中間件能夠收集汽車各個部件的數據，通過 AI 大模型進行分析，提前發現潛在故障風險，并及時通知車主或相關維修人員。例如，通過對發動機運行數據的長期監測和分析，中間件在 AI 大模型的支持下，可以提前預測發動機可能出現的故障，提高汽車的安全性和可靠性。2.基于大模型的中間件l 從模塊化到服務化：隨著 AI 大模型的廣泛應用，傳統基于功能模塊的軟件架構正逐漸向服務化轉變。服務化架

158、構支持跨功能的集成，車輛的各項功能通過 API 接口形成服務網絡，不同功能之間共享數據和邏輯，使得從而實現更為復雜和智能化的服務組合，使其更符合 AI 應用的動態性和數據驅動特性，使車輛能夠根據實際需求快速調整其行為，同時提高軟件的靈活性和可擴展性。例如，通過集成車輛健康監測、故障預測和維修服務，可以為車主提供一站式的車輛健康管理解決方案，簡化軟件維護，使得開發者能夠更加專注于創造新的價值。l 引入 AI 服務層：在軟件定義汽車的基礎上，AI 邊緣計算與 AI 服務層的引入使得車輛能夠實時處理復雜的數據流，實現智能決策。AI 服務層作為連接底層硬件和上層應用的重要橋梁，能夠提供更加個性化和安全

159、的駕駛體驗，還能為用戶提供諸如自動泊車、智能導航等高級功能。AI服務層還可以支持車輛與其他車輛或基礎設施之間的互聯互通，為實現車聯網和智慧城市奠定基礎。l 生成式開發與自適應系統：生成式開發要求軟件架構具有高度的靈活性和可配置性，自適應系統根據車輛的實際運行情況和外部環境的變化快速迭代和自我優化。例如，如果檢測到車輛的電池電量低，自適應系統可能會自動調整能量管理策略，延長續航里程。這種自適應機制可以提升用戶體驗，車輛安全性和可靠性。隨著更多的數據積累和 AI 算法的不斷優化，自適應系統的性能將進一步提高，為用戶提供更加智能化和個性化的服務。3.AI Agent 基礎服務層車端 Agent 是運

160、行在車輛內部的 AI 智能體，它負責感知來自車身、云端以及外部環境一系列與車輛操作、監控、診斷和通信等相關的任務，并不斷推理、監控、反饋、學習，最終能夠在沒有外界直接操縱的情況下作出決策并執行任務。如果說車端基礎功能層為車端 Agent 能夠實時、準確、高效地獲得數據提供了保證，那么 Agent 基礎服務層則提供了 AI 上車的技術底座，不僅對上層的 AI 應用開發提供框架支持，還通過下層 SOVD 等接口實現對車端行為的管控。如圖 3.2-1AIAgent 所示，Agent 基礎服務層的功能應該包含但不限于以下方面：（1）感知模塊（Perception）：具備對多模態的感知和執行動作的理解/

161、監控的能力。其中 Mul-ti-ModelFusion 功能可以將用戶數據、車身數據、傳感器數據、環境數據等信息整合到同一個上下文中，中國汽車基礎軟件發展白皮書 5.0046以任務的方式發送給規劃模塊；ActionAwareness 可以將動作執行的結果信息反饋給規劃模塊的反思功能（見下文）。（2）規劃模塊（Plan）：具備任務分解及調度、結果跟蹤、知識整理和推理優化的能力。其中 Rea-soning&DC 負責與記憶模塊交互進行邏輯思考、分析和推斷，以及對具體的任務進行分治處理；Task 負責任務管理，監控任務調度及任務優先級管理；Reflection 負責與執行模塊交互，根據歷史經驗進行知

162、識整理和推理優化，這些知識的來源包含用戶參與的反饋信息，以及執行結果評估后的反饋信息。（3）記憶模塊（Memory）：備知識及經驗的整理及檢索、記憶及知識管理的能力。RAG 負責對知識與經驗進行整理和檢索，并根據每個任務目標對知識庫中的相關信息進行整合，生成合適的提示信息發送給 PromptsEngine；PromptsEngine 是提示引擎，負責根據不同的任務構建更精準的提示信息并反饋給執行模塊；Knowledge/Memory 則負責對知識的讀寫和知識庫管理。（4）執行模塊（Action）：具備執行任務和評估執行結果的能力。ExecutionEngine 是動作執行引擎，負責執行離散指令

163、和連續指令，同時內嵌 WebService 框架，可以執行來自 Tools 及云端的指令；Assessment 負責對執行結果進行評估，形成一條執行經驗，并反饋給規劃模塊進行反思。圖3.2-1 AI Agent4.AI 大模型與中間件結合的發展趨勢AI 大模型技術與汽車中間件結合的發展趨勢主要體現在以下幾個方面：l 智能化應用：未來中間件將更加依賴 AI 大模型，實現更高級的智能化功能，如自動駕駛、車載語音助手和個性化服務。l 數據融合與分析：中間件將加強與多種傳感器的數據融合能力，利用 AI 進行實時數據分析，從而提升決策準確性和響應速度。l 邊緣計算：隨著對實時性的需求增加，更多計算將在車

164、輛邊緣進行，減少延遲并提高數據處理效率。l 安全性提升：AI 將幫助中間件實時監控系統安全，預測并防止潛在的安全威脅。l 生態系統整合：中間件將與云服務、物聯網和其他智能設備深度整合，形成更加復雜和互聯的汽車生態系統。這些趨勢將推動汽車中間件向更智能、高效和安全的方向發展。中國汽車基礎軟件發展白皮書 5.0047四、開放式軟件架構的操作系統底座開放式軟件架構的操作系統對下驅動硬件資源、對上承接中間件，通過模塊化設計、標準化接口、虛擬化技術以及 AI 包括大模型的應用，實現了軟硬件的深度一體化和軟軟、軟硬解耦以及多平臺兼容和 AI能力的動態擴展。本章節將圍繞操作系統、安全和 AI 融合，對開放式

165、軟件架構的操作系統底座作詳細介紹。（一）開放式軟件架構下的操作系統如圖 4.1-1 面向 AI 的開放式軟件架構的操作系統底座所示，開放架構不僅為第三方應用、服務和中間件的生態開發提供了強有力的支持，還通過增強的安全性、穩定性、實時性以及大模型賦能的智能化功能，進一步推動了系統的演進和創新。同時，軟硬一體化的設計理念與大模型技術的結合，使得操作系統能夠更高效地調度和利用異構計算資源，為智能駕駛、座艙和智能車控提供更強大的智能開放生態底座支持。圖4.1-1 面向AI的開放架構操作系統底座1 軟硬一體域控制器正從單一功能的域內集成演化至多功能的域間集成。這種轉變不僅提高了系統的集成度和智能化水平，

166、還帶來了計算資源的配置和安全性方面的挑戰和需求，芯片的歸一化趨勢越來越明顯。1.1 技術特性芯片歸一化是指：對計算芯片的規格進行歸一。歸一化的芯片設計能夠統一處理不同功能域（如動力控制、自動駕駛、車載娛樂等）的任務，簡化控制器的系統設計和集成。電子電氣結構的中央集中趨勢也推動了芯片設計的歸一化，以支持跨域任務的協同處理。高集成度的系統級芯片（SoC）正逐漸成為主中國汽車基礎軟件發展白皮書 5.0048流，集成了計算、存儲、通信、安全等多個功能模塊，能夠支持更復雜的計算任務和更高的安全需求。當前，多家主流汽車芯片公司紛紛推出自己的多域融合高性能 SoC 芯片?；谝活w芯片實現艙駕控等多域融合，對

167、操作系統提出了很大的挑戰：l 系統穩定性與實時性的挑戰：同時滿足智駕和車控的實時性與可靠性要求以及座艙的多任務處理和復雜用戶體驗的響應，需要操作系統具備高效的調度、資源管理能力和有效的隔離機制。l 安全性的挑戰：智駕域的安全關鍵任務不受座艙域復雜應用的干擾，需要更高效的虛擬化技術和強健的隔離機制。l 性能優化的挑戰：操作系統設計必須充分利用單芯片的多核、多線程及異構計算資源（如CPU、GPU、NPU 等），以同時滿足多域的高性能需求。為應對以上挑戰，操作系統將在異構計算、實時和非實時任務的調度優化以及內存與 I/O 管理這幾個方面持續優化，以提高系統的可靠性與穩定性，提升軟硬融合的效率和質量軟

168、硬協同背景下，操作系統在芯片歸一化中扮演著重要角色。操作系統作為控制器的核心，需要通過建立車內計算資源池，以高效的資源管理和調度策略靈活地分配計算資源，滿足不同場景需求。此外，軟硬件平臺之間需要深入協作和通信，操作系統要提供一套統一的標準與 API，通過 API 將硬件能力抽象化，使上層應用可以不受硬件差異的影響，從而簡化應用開發，屏蔽底層實現，提升軟硬件協同開發效率。為滿足信息安全與功能安全的需求，操作系統還需要支持虛擬隔離和容器技術，以保證不同的應用在獨立的容器內可以正常運行。芯片設計上，為實現計算資源的有效整合，克服當前面臨的挑戰，行業需要在更高層次上對計算資源進行抽象，如計算任務的細粒

169、度管理，將復雜的計算需求分解成更小、更標準化的任務單元，以便能夠在統一的硬件平臺上高效處理，使軟件能夠無縫地與硬件交互，隱藏硬件之間的差異。硬件與軟件的協同設計是提升系統性能和可靠性的關鍵。具體措施包括：為關鍵算法提供硬件加速，如 AI 推理、圖像處理等，減少軟件層的計算負擔，提高整體系統效率。通過軟件優化硬件的使用模式，如動態電壓和頻率調節（DVFS），在保證性能的前提下降低功耗。提供硬件和軟件一體化的開發工具和軟件開發工具包（SoftwareDevelopmentKit，簡稱 SDK），簡化開發流程，縮短產品上市時間。通過實時監控系統的硬件使用情況，動態調整軟件的運行策略，以適應當前的硬件

170、狀態和外部環境變化。這些措施能夠確保在多域融合的復雜系統中，軟硬件能夠協同工作，達到性能最優、安全性最強的系統設計目標。1.2 挑戰與對策在架構層面上，芯片廠商往往有自己獨特的定義與實現，這導致底層軟件的 Pin2Pin 復用變得極為困難。盡管操作系統通過提供豐富的標準化設備模型來隱藏硬件實現細節的差異，讓軟件開發者可以在更高層次使用硬件功能，但底層軟件的重構常因片上系統的定制化差異而充滿挑戰，開發過程很難脫離原廠的技術支持，使軟件與芯片的深度耦合，在這樣的背景下難以實現一次開發、多次復用的目標，行業的整體開發效率受到影響。以車用 SoC 為例，SoC 往往集成一些大型 IP，如 CPU、GP

171、U、視頻編解碼等，相對應用穩定，接口生態較為完整，使得相關開發者可以通過公開的生態接口進行編程。然而，針對一些定制化的數據通路和基礎控制問題，常與芯片的硬件設計緊密相關，如系統的信息安全架構、內存架構和電源管理等，在芯片設計初期由芯片公司的系統工程師（SE）以較私有實現的方式定義。這種做法使得第三方公司難以直接使用開發接口，標準化的難度也極高，系統的碎片化嚴重。而在實施標準化過程中，由于芯片的性能中國汽車基礎軟件發展白皮書 5.0049要求和物理參數限制等，往往阻礙了統一接口的實現。AUTOSARCP 為解決這些困難提供了參考思路，通過接口進一步下移，實現對 MCU 芯片底層的抽象，定義出芯片

172、模型和底層的硬件/OS 無關性接口，進而使行業相關方得以在統一的接口下協同工作。然而車用芯片的發展速度快，集成度與電路規模越來越大，標準的發展往往與行業實際的發展步調不統一，使得軟硬件之間的適配依然很難協調進行。盡管如此，產業界對縮短開發周期、降低成本的強烈需求也成為驅動芯片廠商與基礎軟件廠商共同定義和實現統一接口的動力，通過進一步解耦底層軟件與芯片，實現一次適配多芯片復用，提升行業的開發效率。這需要在共識、標準的制定以及生態建設方面發力，行業的領導廠商需共同推廣開發標準，對SoC 架構和非標件等差異化部分進行標準約束，加強芯片原廠與軟件廠商甚至 IP 廠商的協同合作，定義與操作系統無關的硬件

173、抽象層（HardwareAbstractionLayer，以下簡稱：HAL），減少底層軟件與硬件之間的直接依賴，隱藏芯片設計細節，使第三方開發者能通過更底層的 HAL 接口與硬件交互。2 虛擬化虛擬化（Hypervisor）也稱為 VMM（VirtualMachineMonitor，虛擬機監視器，以下簡稱：Hyper-visor），是一種運行在物理服務器和虛擬機系統之間的中間軟件層，可允許多個虛擬機共享一套物理基礎設施。當 Hypervisor 被啟動并執行時，會為虛擬機分配 CPU、內存、磁盤、網絡等硬件資源，并加載虛擬機的客戶操作系統。隨著人工智能技術的發展，特別是大規模預訓練模型的興起，

174、對計算資源的需求日益增加。與此同時，為了提高資源利用效率和系統靈活性，虛擬化技術在面向 AI 大模型的開放式軟件架構中發揮了關鍵作用。如圖 4.1-2 虛擬化基座接口所示，虛擬化技術通過將物理資源抽象為邏輯資源，允許在同一物理基礎設施上創建多個獨立的虛擬環境。虛擬化技術通過將不同的資源進行隔離，從而實現不同虛擬環境上資源的獨立，避免不同的虛擬環境故障的相互干擾。在資源隔離的基礎上，虛擬化技術也可以實現資源的共享，從而提高資源的利用率。虛擬化技術提高了系統的靈活性。靈活性體現在允許不同形式的應用部署，以及允許應用重建和重新部署。虛擬化技術通過提供虛擬環境，允許不同特性的應用按需求部署，包括實時性

175、應用、非實時性應用、功能安全應用以及非安全應用。通過允許虛擬環境的創建、銷毀、復制、甚至遷移，從而在部分功能故障的情況，可以實現系統功能的快速重建，以及重新部署，提供系統的可用性、安全行及靈活性。虛擬化技術提高系統的可移植性。靈活的虛擬環境支持不同的操作系統的部署，包括但不限于實時操作系統、多樣性操作系統，如 SafetyLinux、Android、其他 RTOS 功能安全操作系統等等。多樣的環境為已有的軟件提供了便捷的移植環境。虛擬化技術為 AI 應用的部署提供了基礎，隔離性使得 AI 應用與其他應用，如關鍵的控制應用避免相互影響。靈活性和可移植性為 AI 應用提供便捷的部署方式。實時操作系

176、統提供了第一手的數據及實時響應的部署環境。Linux 則提供了更完整的生態和無需修改的部署環境。中國汽車基礎軟件發展白皮書 5.0050圖4.1-2 虛擬化基座接口2.1 技術特性（1）虛擬化構成如圖 4.1-3 虛擬化架構所示，虛擬化的架構主要分為兩種：l 裸機型 Hypervisor裸機型（也被稱為 Type1 型），是指 Hypervisor 運行在物理服務器上，GuestOS 對硬件的訪問必須通過 Hypervisor 完成。Hypervisor 作為底層硬件的直接操作者，擁有硬件的驅動程序，可以直接管理和調用硬件資源。l 宿主型 Hypervisor宿主型（也被稱為 Type2 型）

177、是指 Hypervisor 之下還有一層宿主操作系統，GuestOS 對硬件的訪問必須經過宿主操作系統。虛擬機上的應用程序調用硬件資源需要經過多層（VM 內核 Hypervisor 主機內核），但可以充分利用宿主操作系統提供設備驅動和底層服務來進行內存管理、進程調度和資源管理等。圖4.1-3 虛擬化架構中國汽車基礎軟件發展白皮書 5.0051由于宿主型 Hypervisor 性能較低和開源生態優勢等原因，目前在車端場景主要采用 Type-1 型架構的計算虛擬化。其中計算虛擬化對物理資源的虛擬可分為 CPU 虛擬化、內存虛擬化和 I/O 虛擬化，實現方式可分為全虛擬化、半虛擬化和硬件輔助虛擬化：

178、1）CPU 虛擬化實現虛擬化的經典方式是使用“特權解除、陷入模擬”，即將 Hypervisor 運行在最高特權，GuestOS 運行在非特權級。解除 GuestOS 的特權級后，大部分指令仍然可以直接在硬件上運行，只有執行特權指令時，才會陷入到 Hypervisor 模擬執行。具體實現方式包括 CPU 全虛擬化、CPU 半虛擬化、CPU硬件輔助虛擬化。當前，主流架構（如 ARM 架構，X86 架構等）的 SoC 芯片均支持 CPU 硬件輔助虛擬化，同時該方式也是虛擬化效率較高的一種方式。2）內存虛擬化虛擬內存是一種計算機系統內存管理機制，可以將物理內存抽象化，為應用程序提供連續的虛擬內存地址（

179、64 位系統地址空間為 264）。系統將虛擬地址空間和物理地址空間分別劃分為大小相同的頁，并通過頁表記錄地址之間的映射關系，MMU（內存管理單元）根據頁表完成虛擬地址到物理地址的轉換。在計算虛擬化中，Hypervisor 管理系統的內存資源，虛擬機也有內存管理機制，因此有 VA（客戶機虛擬地址）、PA（客戶機物理地址）、MA（宿主機機器地址）三層映射關系，而內存虛擬化需要完成 VA到 MA 的轉換。就實現方式而言，內存虛擬化也包括內存全虛擬化、內存半虛擬化、內存硬件輔助虛擬化等方式。其中，硬件輔助虛擬化的效率較高。3）I/O 虛擬化從 CPU 的角度來看，外設是通過一組 I/O 資源訪問的設備

180、，因此設備相關的虛擬化被稱為 I/O 虛擬化。Hypervisor 通過 I/O 虛擬化來復用有限的設備資源，包括顯卡、網卡和硬盤等。I/O 虛擬化包括全虛擬化、半虛擬化、硬件輔助虛擬化。其中 I/O 半虛擬化相關技術包括 VirtIO 虛擬化框架，是當前車端外設虛擬化的主流技術之一，對于 GPU/NPU 等高速外設，基于硬件輔助虛擬化也是比較常見的虛擬化技術，可以獲得較高的虛擬化效率保證。（2）虛擬化性能虛擬化損耗是指在虛擬化環境中，由于虛擬化層（如 Hypervisor）對物理資源的抽象和管理，導致虛擬機（VM）在運行應用程序時相對于裸機環境所表現出的性能下降。這種性能下降可能涉及 CPU

181、、內存、I/O、網絡等多個方面。對于 CPU 而言，當前主流架構的 CPU 均支持硬件輔助虛擬化技術，可以有效降低因為虛擬化帶來的性能損耗，通常而言可以控制到 1%左右的損耗比。當然，這里虛擬化性能損耗和實際的系統運行負荷也有一定的關系，如頻繁的上下文切換和調度，一定程度上會加劇 CPU 虛擬化損耗。對于內存而言，當前主流硬件均支持硬件輔助虛擬，可以實現較低的內存虛擬化性能損耗，通?？梢钥刂频?2%以下。對于 I/O 外設而言，其類型多種多樣，有高速設備也有低速設備，對應可采取的虛擬化技術有多種：時間分片復用方式，Passthrough 方式，VirtIO 半虛擬化方式，硬件輔助虛擬化（如基于

182、 IOMMU 技術）。其中時間分片復用方式的虛擬化，需要硬件驅動和 hypervisor 密切配合，實現復雜度高，可以獲得較高的虛擬化性能。Passthrough 是透傳模式，主要場景是外設對于某個特定 VM 的專屬訪問，可以實現接近硬件的虛擬化性能，但是不利于多個 VM 之間的設備共享。VirtIO 半虛擬化方式基于標準化的 VirtIO 框架，中國汽車基礎軟件發展白皮書 5.0052有利于外設虛擬化的前后端解耦，但是這種方式的虛擬化損耗通常比較高（如 10%以上），通常用于低速設備的 I/O 虛擬化。硬件輔助虛擬化需要專門的硬件支持，可以實現較高的虛擬化性能。（3）虛擬化安全虛擬化相關的安

183、全包括功能安全和信息安全等方面。其中，對于功能安全而言，虛擬化作為底層 OS的重要組成部分，既包括自身功能安全特性和要求，也包括和車端軟硬件其他部分的協同，共同實現整體功能安全目標與要求（SafetyGoal）。對于 Hypervisor 自身功能安全要求，需要按 ISO26262（道路車輛功能安全）規范的相關要求進行系統設計、開發、測試與驗證等全生命周期的研發活動，并實現相關的功能安全等級認證（如 ASILB/D）。此外，虛擬化 Hypervisor 還可以和其他系統協同，實現系統整體的功能安全特性提升。如圖 4.1-4多層監視框架所示，在智駕場景中基于 SafetyLinux 的軟件架構是

184、當前相對主流的技術選型，參考 E-GAS（StandardizedE-GasMonitoringConceptforGasolineandDieselEngineControlUnits，由奧迪、BMW、戴姆勒等國際頂尖公司聯合起草制定的 ECU 軟件架構）安全模型架構，基于 Hypervisor 構建多級監控框架，以此提升系統的功能安全特性，具體如下圖所示。圖4.1-4 多層監視框架對于車端信息安全，虛擬化 Hypervisor 同樣發揮重要作用。首先，基于 Hypervisor 的智駕、座艙、多域融合解決方案場景下，不同虛擬機之間可以很好地實現時空隔離與資源訪問控制，一定程度上可保證整個系

185、統的信息安全。此外，如圖 4.1-5 虛擬化信息安全方案所示，在虛擬化 Hypervisor 中實現特定的安全訪問代理，同時與 TEE（TrustExecutionEnvironment 可信執行環境，以下簡稱 TEE）OS 配合也可以實現控制器系統與外部其他系統之間的信息安全隔離和訪問控制，進一步提升車端信息安全。中國汽車基礎軟件發展白皮書 5.0053圖4.1-5虛擬化信息安全方案具體說明如下：（1）非安全虛擬機通過 TEE 虛擬前端驅動調用安全功能，避免直接 SMC（SecureMonitorCall，從非安全世界(NormalWorld)轉移到安全世界(SecureWorld)的機制）

186、調用帶來安全風險；（2）安全虛擬機提供 TEE 虛擬后端驅動，管控各 NEE（Non-secureExecutionEnvironment，非安全執行環境）調用安全功能策略；（3）TEE 系統運行于安全世界（SecureWorld），響應非安全世界（NormalWorld）發起的安全請求；（4）SecureMCU：負責響應硬件安全要求更高的安全請求，SEE（SecureExecutionEnvironment,安全執行環境）或者 TEE 會通過硬件專用 IPC（Inter-ProcessorCommunication，進程間通信）通道轉發到 SecureMCU；2.2 演化趨勢隨著艙駕融合、智

187、能底盤的演進，虛擬化將擴展其 CPU 架構支持，支持更多類型的業務融合，典型如實時控制任務、AI 異構算力共享任務等，潛在發展技術路線如下：（1）MCU 虛擬化MCU 在保證實時性、可靠性的基礎上，正在持續提升算力，以支持部署更復雜的業務功能，同時也在探索硬件虛擬化能力，以支持多運行環境，確保相互之間充分隔離、免于干擾。比如英飛凌的 Tricore1.8 相對于 1.6 的關鍵增強包括：CPU 主頻從 300MHz 提高到 500Hz，更大更快地內存訪問；有 6 個CPU，每一個核可以執行 8 個虛擬機，有專屬或者共享的寄存器資源，可通過專屬資源實現實時虛擬機，也可以通過共享硬件資源實現更多業

188、務系統的并行共享運行。提供內存虛擬化的兩級 MPU 保護，基于PRTO/APU(AccessProtectionUnits)外設保護機制實現外設虛擬化，支持用戶模式和特權模式等。同時，為實現底盤智能化，需要 MCU 集成相應的 AI 算力。在 AIOT(ArtificialIntelligence&Inter-netofThings)領域，已經有 MCU+AI+SRAM 的技術架構，運行小模型 AI，比如基于 TensorflowMi-croLite 的小語音模型，能跑在幾百 KB 到幾 MB 的 SRAM 里面。在汽車底盤域中，MCU 可以繼續發揮CPU 架構的嚴格多發射控制、很短的內部總線

189、和中斷傳輸通路，以及 SRAM 低延時、低功耗機制，保證中國汽車基礎軟件發展白皮書 5.0054ASIL-D 安全可靠性，同時逐步集成、拓展 AI 算力，支持在底盤部署嵌入式 AI 推理應用。如圖 4.1-6 所示，基于虛擬化支持 MCU 融合的系統架構如下圖：圖4.1-6 基于虛擬化支持MCU融合的系統架構MCU 芯片架構更加特殊化，各廠商往往有自己的技術路線，當然，業界也有往 ARM、RISC-V 聚合的發展趨勢。相對于云計算、SOC 系統，短期內 MCU 上的虛擬化系統更難通用化，需要緊密結合 MCU芯片架構，來實現 CPU、內存、NPU、外設資源的虛擬化。因此，也希望能推動 MCU 芯

190、片領域盡快形成共識的技術路線、標準規范，減少虛擬化開發適配工作量。（2）SoC 融合 MCU 功能SoC 芯片越來越重視車規級安全，目前已可支持芯片級 ASIL-B、系統級 ASIL-D。艙駕控一體趨勢下，越來越多的功能融合到一個 SoC 上，因此也存在著智能底盤與艙駕完全融合的演進可能性。SoC 已可以將 APU 應用處理器、MCU 微控制器集成在一起，分別承擔不同安全等級、業務特性的功能，相互之間通過高性能、高確定性的片上通信協同工作；同時業界也在研究基于 A 核來運行強實時、高可靠、高安全業務的可行性，比如底盤控制、動力總成等。A 核融合 MCU 業務的難點主要在于復雜系統的穩定性、多指

191、令及中斷執行的確定性、內存訪問的確定性等，一方面依賴于芯片技術的進步，另一方面可結合虛擬化的資源分配及管理技術。比如對于關鍵業務在編譯時鎖定指令發射機制，虛擬化為關鍵業務虛擬機鎖定分配中斷資源、SRAM 內存資源，以保證時延確定性。如圖 4.1-7 所示，基于虛擬化支持 SoC 融合的系統架構如下圖：圖4.1-7 基于虛擬化支持SoC融合的系統架構中國汽車基礎軟件發展白皮書 5.0055虛擬化根據底盤、動力總成的業務需求，為其分配獨立鎖定 CPU 資源(比如大小核中的小核)，分配確定的 NPUAI 算力資源，同時分配實時性、確定性更好的 SRAM 內存資源，以滿足高功能安全等級要求。外設資源方

192、面可以提供 PassThrough 直通，或者共享復用的虛擬化方式。虛擬化技術在面向 AI 大模型的開放式軟件架構中扮演著越來越重要的角色。隨著技術的不斷進步，虛擬化技術將繼續為 AI 應用提供更強有力的支持，推動 AI 技術朝著更高效、更安全和更智能的方向發展。3 實時操作系統實時操作系統（RealTimeOperateSystem，簡稱 RTOS）是汽車智能化和電子控制單元（ECU）功能實現的關鍵技術之一。如圖 4.1-8 實時操作系統所示，它主要負責支撐并管理整車應用程序的任務調度和資源管理，包括但不限于車輛控制、多媒體播放、智能應用等，確保這些應用程序能夠安全、高效地運行。隨著汽車向電

193、動化、智能化發展，電子電氣架構正從傳統分布式架構向域集中式架構以及中央計算架構轉變，車用操作系統技術成為汽車軟件生態的重要基礎。3.1 技術特性車用實時操作系統的技術重點主要圍繞以下幾個關鍵領域展開，旨在滿足汽車行業對高性能、安全性、可靠性和實時性的嚴格要求。圖4.1-8 實時操作系統（1）確定性與低延遲l 任務調度的確定性：車用 RTOS 必須具備嚴格的任務調度能力，以確保關鍵任務（如制動、轉向等）能夠在嚴格的時間限制內執行。確定性調度意味著系統在任何時候都可以預測任務的執行順序和時間，避免因任務沖突或資源競爭導致的延遲。l 低延遲響應：車用 RTOS 需要在極低的延遲下響應外部事件，如傳感

194、器輸入或用戶指令。低延遲對于實現諸如防撞系統、緊急制動等安全關鍵功能至關重要。（2）安全性與可靠性l 內存保護與任務隔離：RTOS 需要提供強大的內存保護機制，確保各個任務之間相互隔離，防止非授權任務訪問其他任務的內存空間。這對于防止軟件故障傳播，維持系統穩定性和安全性至關重要。l 故障檢測與恢復機制：為了提高系統的可靠性，RTOS 通常集成故障檢測機制，如看門狗定時器，來監控系統運行狀態，并在檢測到異常時進行自動恢復或安全降級處理。中國汽車基礎軟件發展白皮書 5.0056（3）實時通信與同步l 時間敏感網絡（TSN）支持：隨著車內網絡復雜性的增加，RTOS 需要支持時間敏感網絡（TSN）技術

195、，以確保不同系統組件之間的實時數據傳輸和同步。TSN 通過時間分片和優先級調度，保證關鍵數據包能夠在嚴格的時間窗口內傳輸完畢。l 同步協議與多核支持：對于多核處理器，RTOS 需要實現高效的任務同步和跨核通信，以最大化系統性能，同時避免由于任務競爭而引發的資源爭用問題。（4）功能安全與認證l 道路車輛功能安全 ISO26262 認證：車載 RTOS 通常需要符合 ISO26262 功能安全標準，特別是在 ASIL（汽車安全完整性等級）等級較高的應用中。這意味著 RTOS 需要通過嚴格的安全認證流程，并提供符合功能安全要求的架構設計、開發流程和測試驗證手段。l 安全關鍵任務管理：RTOS 需要支

196、持對安全關鍵任務的優先處理和保護機制，確保這些任務能夠在系統發生故障時保持穩定運行，或在必要時優雅降級。（5）資源管理與優化l 動態內存管理：由于車載環境的特殊性，RTOS 必須有效管理有限的內存資源，避免內存泄漏或碎片化。這通常通過靜態內存分配或嚴格的動態內存管理策略來實現。l 功耗管理：隨著汽車電子系統的復雜性增加，RTOS 還需要支持高效的功耗管理，特別是在電動車輛中。RTOS 應能動態調整系統的工作頻率和電源狀態，以在不影響性能的情況下最大限度地減少能耗。（6）虛擬化與多域整合l 虛擬化技術支持：現代車載系統通常需要整合多個功能域，而虛擬化技術可以有效隔離這些功能域。RTOS 需要支持

197、虛擬化，以確保不同域之間的安全隔離和資源共享，避免相互干擾。l 多域系統的實時性保障：在多域融合的環境下，RTOS 需要保證每個域內的實時任務能夠得到及時調度和處理，即使在資源共享的情況下，也不能影響關鍵任務的實時性。（7）可擴展性與兼容性l 模塊化設計：為適應不同車型和應用的需求，RTOS 通常采用模塊化設計，允許根據具體需求定制不同的功能模塊。這種設計能夠提高系統的靈活性和可擴展性。l 標準接口與兼容性：車用 RTOS 需要與多種硬件平臺、傳感器和執行器兼容，并支持 POSIX等標準接口，以確保與第三方軟件庫和工具的兼容性，提高開發效率。（8）實時更新與維護l OTA（Over-the-A

198、ir）更新：隨著汽車電子系統的復雜化和聯網化需求的增加，RTOS 需要支持 OTA 更新功能，允許在不影響車輛正常運行的情況下進行系統更新和維護。l 安全補丁管理：RTOS 還需具備快速部署安全補丁的能力，以應對新出現的安全威脅，確保系統在整個生命周期內的安全性和穩定性。車用實時操作系統的技術重點在于通過高性能的實時調度、安全可靠的系統設計和靈活的資源管理來保障車輛的安全性和穩定性。隨著自動駕駛和智能網聯技術的發展，車載 RTOS 的功能和性能要求將繼續提升，需要不斷適應新的技術趨勢和應用需求。3.2 演化趨勢車用實時操作系統（RTOS）的未來技術演進將受到汽車行業不斷發展的需求推動，特別是在

199、自動駕中國汽車基礎軟件發展白皮書 5.0057駛、智能網聯、功能安全和能源管理等方面。以下是關鍵的演進趨勢：（1）高性能計算與高級傳感器融合l 高性能異構計算支持：隨著自動駕駛技術向 L3、L4 級別發展，RTOS 需要更強的計算能力和實時性，將進一步支持異構計算架構，結合 CPU、GPU、AI 加速器等多種資源，滿足自動駕駛任務的高計算需求。l 高級傳感器融合：RTOS 將處理來自激光雷達、攝像頭、雷達等多種傳感器的數據，使用更復雜的算法和更高的數據帶寬來實時融合信息，生成精確的環境模型。（2）功能安全與信息安全l 多層次安全架構：RTOS 將集成從硬件安全模塊（HSM）到軟件隔離的多層次安

200、全機制，以應對潛在的網絡攻擊和系統故障。l 安全認證與標準化：未來的 RTOS 將廣泛支持 ISO26262（道路車輛功能安全）功能安全標準，并針對不同級別的自動駕駛開發專門的安全認證機制，確保在高安全性環境中的可靠運行。（3）實時與非實時任務的協同管理l 增強的虛擬化技術：RTOS 將進一步發展虛擬化技術，實現實時任務與非實時任務的安全隔離，并優化資源利用率和系統性能。l 多核處理器優化：RTOS 將優化對多核處理器的支持，確保實時任務在多核環境中高效調度和執行，避免資源競爭和瓶頸。（4）多域融合與集中計算l 中央計算單元支持：RTOS 將優化以支持車輛中央計算單元（CCU），統一管理多個功

201、能域（如駕駛輔助、信息娛樂、車身控制）。l 域控制器集成：隨著多個功能域集成到少數幾個高性能控制器中，RTOS 需要支持更復雜的任務調度和資源管理，確保各域之間的任務協同工作。（5）能效管理l 動態功耗管理：未來 RTOS 將更加注重動態功耗管理，通過智能調節系統頻率和電壓，平衡性能需求與能耗，延長電池續航時間。l 能源優化算法：RTOS 將集成復雜的能源優化算法，實時監控和調節車載系統能耗，確保在不同駕駛條件下的最佳能效表現。（6）實時性保障機制l 超低延遲通信：RTOS 將支持更低延遲的通信協議（如時間敏感網絡 TSN），在高數據吞吐量情況下依然滿足嚴格的實時性要求。l 確定性調度算法改進

202、：RTOS 將在確定性調度算法上進一步優化，確保所有關鍵任務都在預定時間內執行，滿足復雜車載系統需求。（7）系統可更新性與長期維護l 分區更新與無縫切換：RTOS 將支持分區式 OTA 更新，允許在不中斷系統關鍵任務的情況下更新組件，減少更新對車輛使用的影響。l 長生命周期支持：RTOS 將優化架構，支持汽車全生命周期內的多次更新和維護需求，包括新功能添加和安全補丁的快速部署。中國汽車基礎軟件發展白皮書 5.0058（8）智能化與自適應能力l AI 驅動的資源調度：RTOS 將引入人工智能，通過歷史數據和實時反饋動態調整任務調度和資源分配，優化系統性能。l 自適應安全機制：RTOS 可能集成自

203、適應安全機制，根據系統運行狀況和外部威脅自動調整安全策略，提高整體防御能力。車用 RTOS 的未來演進趨勢將圍繞高性能計算、功能安全、信息安全、能效優化和智能化展開，以適應自動駕駛和智能網聯技術的發展需求，同時確保系統的安全性、可靠性和實時性。4 Safety LinuxLinux 操作系統由于：a)生態強大，支持多種程序語言與開發工具；b)支持多任務多用戶調度；c)內部自帶防火墻、入侵檢測，能在多數情況下滿足對網絡安全性的需要；這幾個特點，被多家車廠和零部件供應商選擇應用到自動駕駛控制器中。但 Linux 本身在功能安全方面存在缺陷，因此業內普遍的做法是針對 Linux 操作系統做功能安全方

204、面的設計和開發，增強后的 Linux一般被稱為 SafetyLinux（功能安全 Linux 操作系統，以下簡稱 SafetyLinux）。SafetyLinux 內核在汽車功能安全相關領域的應用場景包含高級輔助駕駛（ADAS）、高級自動駕駛（AD）、艙駕一體、汽車中央計算平臺等。在這些應用場景中 SafetyLinux 內核可以支撐運行最高 ASIL-B等級的應用程序。ADAS/AD 的部分應用功能為 ASIL-B 等級。SafetyLinux 內核可以支持 QM（QualityManagement，功能安全技術體系下的“風險邊界”，控制到 QM 風險等級的危害即為“可容忍的”）和ASIL-

205、B（汽車完全完整性等級 B 級，最高為 D 級）的中間件及應用程序同時在用戶態運行，同時確保QM 和 ASIL-B 軟件之間有充分的隔離，不會相互干擾。用于支持功能安全 Linux 內核開發的軟件工具鏈也滿足功能安全的要求，可以支持 ASIL-B 軟件的開發。在自動駕駛系統的場景下，Linux 系統至少需要支撐 QM 和 ASIL-B 的應用軟件運行。所以 Linux 內核自身也至少需要具備 ASIL-B 的功能安全等級。如圖 4.1-9 功能安全 Linux 系統概念框圖所示，內核中的所有子系統都應具備 ASIL-B 的功能安全等級。在實際的產品安全分析過程中，應對 Linux 內核的各個子

206、系統進行進一步細分，識別出更多子模塊。圖4.1-9 功能安全Linux系統概念框圖中國汽車基礎軟件發展白皮書 5.00594.1 技術特性（1）Safety Linux 技術要點在提升自動駕駛 Linux 系統功能安全特性方面，主要工作考慮以下方面：l 針對 Linux 基線選型，選擇開源社區 LTS（LongTermSupport，長期支持）版本作為基線來源，可供參考的版本基線如 Redhat 的 CentOS、Debian、YoctoLinux 等，并根據目標芯片平臺的BSP（BoardSupportPackage 板級支持包，以下簡稱 BSP）支持情況作選擇。為使 Linux系統達到安全

207、完整性等級 ASILB，除了 Linux 內核之外，Linux 內核相關的開發工具鏈和軟件基礎庫都需要滿足功能安全合規的要求。l 進行 Linux 系統危害分析和風險評估：確定 Linux 系統應用在自動駕駛軟件中的支撐作用，從自動駕駛細分應用功能出發分析可能的危害以及這些危害發生的概率和嚴重程度，這是確立ASIL 等級的基礎。進行故障模式、影響和診斷分析（FMEDA），通過 FMEDA 分析證明 Linux內核及其相關組件滿足 ASILB 標準中的單點故障指標（SPFM）和潛在故障指標（LFM）。從產品功能需求到 Linux 內存分配過程中都需要優化任務調度、進程管理以及內存管理，并有效定義

208、目標 ASIL等級、Failsafe、FTTI（Faulttoleranttimeinterval 故障容錯時間間隔）等，采用高效的檢查方法對需求進行驗證，同時基于需求進行精煉并提取有效的數據流和控制流，進行分析驗證。l 安全監控：使用外部監控組件或虛擬機監控程序來托管安全相關的操作，確保內核操作的安全性。例如，EBcorbosLinuxforSafetyApplications引入了基于虛擬機監控程序的安全擴展，符合ASILB/SIL2安全要求。l 硬件和軟件的冗余設計：硬件層面，設計電源監控系統以確保 MCU（微控制單元）的電源供應在安全工作范圍內，并在檢測到電源故障時將 MCU 復位至安

209、全狀態。例如，使用寬 VIN 監控器進行 MCU 電源監控，并確保監控器與電源輸出無關，以避免共因失效；使用功能安全型穩壓器的集成 PGOOD 引腳作為監測欠壓和過壓故障的安全機制，并確保診斷覆蓋率滿足ASILB 要求。軟件層面進行接口層抽象，在用戶態抽象出接口層，接管 Linux 內核的某些操作，通過這個接口層實現功能安全邏輯。例如，使用 AUTOSAR 的 AP 版本或在 Linux 上運行虛擬機來實現功能安全邏輯。依據計算機系統中的 Amdahl 定律來計算容錯系統的可靠性改進，確保所有組件采用冗余設計，使得單點故障不會導致整體系統失效。l 增加外部安全機制（比如程序流監控、數據流監控、

210、冗余計算、冗余存儲等）等方面的有效實施：通過高效的配置工具（如 OSADLMinimizationtool）針對需求分析的 Strace 信息對內核進行裁減，依據最佳時間或產品的特性對內核進行配置，最后基于檢查加分析的方法對內核進行配置和驗證。l 持續的缺陷管理和更新：保持 Linux 內核的更新，及時打補丁以修復缺陷，同時保持與原生態的兼容性，確保系統的安全性和可靠性。值得注意的是，Linux 系統按上述方式被改進和配置以確保滿足在汽車安全關鍵型應用中的可靠性和安全性；然而部分安全改造在一定程度上可能導致改造后降低 Linux 的擴展性、靈活性。除了以上措施，也可采用將 Linux 整體當做

211、軟件組件來進行軟件組件鑒定（ASILB）的方法，但是這類鑒定對超大型軟件代碼不一定適用，且相關的標準也還在制定過程中。中國汽車基礎軟件發展白皮書 5.0060（2）Safety Linux 挑戰隨著汽車逐漸從硬件定義向軟件定義轉變，開源軟件和Linux系統在汽車應用中的重要性日益凸顯。SafetyLinux作為開放架構操作系統的基礎，為汽車制造商提供了一個靈活、可定制且安全的平臺。它允許開發者在保證安全性的同時，快速開發和部署各種車載應用。這種開放性使得汽車制造商能夠更好地應對快速變化的市場需求和技術創新。SafetyLinux在汽車行業中的典型使用場景主要包括ADAS（高級駕駛輔助系統）、儀

212、表集群（InstrumentCluster）和V2X，對應這些場景分別有不同的技術需求。ADAS（高級駕駛輔助系統）l 提供符合 ISO26262（道路車輛功能安全）標準的安全運行環境l 確保實時性能，如快速響應緊急制動l 支持復雜的傳感器融合和數據處理l 便于功能安全認證儀表（InstrumentCluster）l 保證關鍵信息（如速度、警告）的準確顯示l 支持現代數字儀表盤的高性能圖形需求l 實現與車輛其他系統的安全集成l 提供靈活的界面定制和更新能力V2X（車輛對外界通信）l 提供安全的通信機制，保護敏感數據l 支持低延遲的實時信息處理l 確保在復雜環境下的系統可靠性l 便于實現和更新國

213、際通信標準l 與ADAS系統無縫集成綜合而言，SafetyLinux 一般需要具備以下特性來滿足相應汽車系統的需求，a)功能安全：SafetyLinux設計符合ISO26262 等汽車功能安全標準，達到 ASIL-B 的要求。b)實時性能：優化的實時內核確?？焖夙憫偷脱舆t。c)可靠性：提供嚴格的內存保護和進程隔離機制。提供穩定的運行環境，減少系統崩潰和錯誤的可能性。d)開放可定制：基于 Linux 具有強大的生態系統和開發工具。允許汽車制造商根據特定需求定制和優化系統。e)安全通信機制：支持安全的數據傳輸和處理。f)硬件兼容性：支持廣泛的車規級硬件平臺。要實現以上技術特性并不容易，最主要的難

214、點是功能安全特性，因為達到 ASIL-B 的要求，非常不容易，其主要存在的難點如下：l Linux 內核龐大的代碼量和相對復雜的設計，全面分析和驗證如此大規模的代碼庫是一個巨大的挑戰。l Linux 生態系統，涉及眾多貢獻者和頻繁的更新，這種復雜性使得追蹤和驗證每個代碼更改的安全影響變得困難。l 功能安全認證（如 ISO26262 或 DO-178C）要求詳細的文檔和嚴格的開發流程，而 Linux 快中國汽車基礎軟件發展白皮書 5.0061速的開發周期和頻繁的更新可能與功能安全認證所需的嚴格控制和驗證過程不兼容。l Linux 作為一個通用操作系統，在設計之初沒有基于功能安全，設計注重功能性和

215、靈活性，且具有一定的非確定性，這與功能安全要求的可預測性和確定性行為相矛盾，如何實現 Linux 功能安全沒有現成的方法。l 功能安全系統需要長期穩定的版本，而 Linux 社區傾向于快速迭代和頻繁更新。如何在保持系統穩定性的同時，及時應用 Linux 重要的安全補丁和系統更新，確保每次更新或修補后系統仍然滿足功能安全要求是一個持續的挑戰。l 對 Linux 系統的安全性能進行量化分析和統計驗證是一個復雜的過程，需要開發新的方法和工具?？傊?，SafetyLinux 在當前汽車行業中扮演著至關重要的角色，它為開放架構操作系統提供了一個安全、可靠的基礎。其核心價值在于確保車輛關鍵系統的功能安全，同

216、時保持 Linux 的開放性和靈活性。通過嚴格的安全機制、確定性行為、故障檢測和隔離等技術，SafetyLinux 為 ADAS、車輛控制系統和 V2X等安全關鍵應用提供了可靠的運行環境。4.2 演化趨勢（1）Linux 達成功能安全合規的趨勢隨著自動駕駛行業的高速發展，智能網聯汽車的各類標準體系逐漸完善，整車廠出海需求增長，對采用 Linux 應用于自動駕駛的功能安全合規性要求逐漸趨嚴，Linux 系統為確保智能駕駛的安全可靠，需建立成熟且可量化分析、可執行的功能安全體系結合功能安全的分析和處理。Linux 作為宏內核解決方案（包括宏內核、C 庫及 C 編譯器等外部庫）至少有 200 萬行代

217、碼需要達成ISO26262 標準下的 ASIL-B 的功能安全等級合規，這對自動駕駛行業來說無疑是一個很大的挑戰。目前難點主要在錯誤監控、分類和實時處理，以及如何保證在硬件失效和軟件崩潰下汽車仍具有最低限度的安全性。在中國汽車工業協會 AUTOSEMO 工作組內有一批領先的企業投入 Linux 功能安全實踐，如長安汽車的 Linux 內核態功能安全診斷模塊將會在 2025 年獲得功能安全認證；截至 2024 年 9 月零束科技的功能安全 LibC 庫、C 編譯器和 IPC 模塊；地平線征程 5 的 BSP 獲得 ASILB；賽福納斯科技的功能安全SafenuxLinux 核心內核等。國際上的整

218、車廠和相關 Linux 企業也在積極推進針對開源軟件的功能安全國際標準的演進，隨著 ISO8926 的發布，行業內對于開源軟件有了新的實踐路徑，該標準在未來兩年內的落地實踐效果，一定程度上也會影響 ISO26262 第三版內容的制定。預計 Linux 系統解決方案的功能安全有望在 20262027 年得到解決。（2）功能安全 Linux 的生態合作底層操作系統的安全性、穩定性、可靠性是整車安全和性能的保障，需要行業共建，打造一個標準的、符合汽車應用需求的 Linux 版本。功能安全 Linux 內核涉及到內核數百萬甚至上千萬行代碼的功能安全合規的目標，單憑一家或少數幾家公司基本不可能在合理的成

219、本（行業預估對 Linux 內核做 ASILB 認證成本為 100RMB/行）下達成這項目標。針對自動駕駛對功能安全的特殊要求，還需要對 Linux 系統持續進行功能安全特性開發，優化操作系統內核的中斷、內存、調度處理流程，將影響功能安全的操作系統內核異常事件以可靠的方式通知業務軟件，幫助實現系統整體功能安全。為實現自動駕駛中功能安全 Linux 系統，需要各家整車廠、代表企業及生態合作伙伴共同努力，將基中國汽車基礎軟件發展白皮書 5.0062于 Linux 的自動駕駛系統分解成多個部分從而逐個擊破功能安全合規的問題。例如：a)芯片廠商提供內核中功能安全合規的芯片驅動代碼。因為自動駕駛芯片驅動

220、軟件與芯片硬件是強耦合的，所以只有芯片廠商可以基于功能安全芯片硬件開發安全合規的芯片驅動代碼。芯片廠商可以提供 QM 版 Linux 芯片驅動代碼來支持客戶的早期開發和 POC(ProofofConcept)項目，同時提供 ASIL 合規版 Linux 芯片驅動及 STL（Safetytestlibrary）安全測試庫來支持客戶的量產項目。b)Linux 系統類廠商提供功能安全合規的內核基本功能軟件模塊和 Linux 系統開發工具鏈；也可以牽頭將多家廠商分別提供的 Linux 功能安全軟件模塊、工具集成成為一套完整的功能安全 Linux 系統解決方案，多家廠商可以共享功能安全 Linux 系統

221、解決方案所帶來的價值。此外建議 Linux 系統類廠商研究汽車行業對底層軟件的應用和需求特點，提供適合于當前的商業模式。c)自動駕駛軟件廠商提供各類功能安全合規的自動駕駛中間件軟件模塊和應用軟件模塊。自動駕駛軟件廠商也可以將部分重要的 Linux 用戶態開源軟件模塊轉化成功能安全合規的模塊，集成到自身的中間件應用軟件產品中。自動駕駛中間件和應用軟件可以基于 Linux 系統優化并達到最佳的運行效率，從而節約硬件資源。d)功能安全認證機構通過深度參與 Linux 功能安全社區以及 Linux 認證活動，為功能安全 Linux 軟件生態中的多家廠商提供標準化、高效率的功能安全培訓和認證服務。通過標

222、準化、規?；呐嘤柡头?，功能安全認證機構可以加快認證周期以適應功能安全 Linux 自動駕駛軟件的快速迭代的產品特征，同時降低客戶的安全認證的成本，提升自動駕駛功能安全領域整體工程效率。e)整車廠提出自動駕駛系統及 Linux 系統功能安全的需求，并支持其供應鏈中的 Linux 系統生態伙伴。如整車廠在自動駕駛功能安全 Linux 的開發過程中，發起 POC 項目，使得生態伙伴能夠深入理解產品及業務的功能安全需求，在產品化項目中快速交付可量產的功能安全 Linux 系統解決方案。f)標準化組織、生態聯盟提出對自動駕駛 Linux 系統的功能安全要求和團體標準，更新方法論，統一行業認知，彌補現

223、有國際功能安全標準的不足，提高基于功能安全 Linux 的自動駕駛系統整體安全性、性能和性價比。例如針對本報告中分析現有功能安全標準，以及行業最佳安全實踐的不足，建議后續通過行業標準/團體標準的形式，給出軟件和操作系統功能安全的實施細則和行業最佳實踐，形成對現有功能安全標準的補充。g)在政策層面，建議對自動駕駛領域的企業在 Linux 系統的功能安全合規及認證領域的技術成果進行支持。展望未來，SafetyLinux 將繼續演進以應對新的挑戰。這包括適應不斷更新的安全標準、整合 AI 安全機制、支持混合關鍵系統，以及融合功能安全和信息安全。隨著汽車行業向軟件定義汽車轉變，SafetyLinux

224、的重要性將進一步凸顯。汽車制造商和技術供應商需要密切關注 SafetyLinux 的發展，并積極參與其生態系統建設。只有這樣，才能在保證安全性的同時，充分利用開源技術的創新潛力，在競爭激烈的汽車行業中保持領先地位。SafetyLinux 不僅是一個操作系統，更是汽車行業安全創新的重要推動力。（二）開放架構下的操作系統安全開放架構雖然帶來了更高的靈活性和可擴展性，但同時也增加了系統的攻擊面和安全風險。因此，操作系統必須采用多層次的安全架構，涵蓋信息安全、功能安全、網絡安全等多個維度，以保護系統免受潛在威脅。中國汽車基礎軟件發展白皮書 5.00631.信息安全開放架構的操作系統具有代碼透明、可定制

225、性強等優點，但也面臨著獨特的安全挑戰。這些挑戰主要包括：a.代碼公開帶來的潛在漏洞暴露；b.第三方軟件和驅動的安全風險；c.系統配置的復雜性增加了誤操作的可能性；d.網絡連接的普遍性增加了遠程攻擊的風險。1.1 一般安全技術為應對這些挑戰，現代操作系統安全策略通常采用多層次、縱深防御的方法，結合技術手段和管理措施來保護系統的完整性、機密性和可用性。在開放架構的操作系統中，信息安全主要關注以下幾個方面：l 機密性（Confidentiality）：確保信息只能被授權用戶訪問。l 完整性（Integrity）：保證信息在存儲和傳輸過程中不被未經授權的修改。l 可用性（Availability）：確

226、保授權用戶能夠及時訪問所需的信息和資源。為了實現上述安全目標，開放架構的操作系統通常采用以下典型安全策略：（1）訪問控制策略l 自主訪問控制（DAC）：允許資源所有者自行決定訪問權限。l 強制訪問控制（MAC）：系統根據預定義的安全策略控制訪問。l 基于角色的訪問控制（RBAC）：根據用戶在組織中的角色分配權限。l 基于屬性的訪問控制（ABAC）：根據主體、客體、操作和環境的屬性動態決定訪問權限。（2）身份認證和授權l 多因素認證：結合密碼、生物特征、硬件令牌等多種方式。l 單點登錄（SSO）：用戶只需登錄一次即可訪問多個相關系統。l 最小權限原則：僅授予用戶完成任務所需的最小權限。（3）加密

227、和數據保護l 文件系統加密：保護靜態數據的安全。l 網絡通信加密：如 SSL/TLS 協議，保護數據傳輸安全。l 內存保護：防止緩沖區溢出等攻擊。（4）審計和日志l 系統日志：記錄重要系統事件和用戶活動。l 安全審計：定期分析日志，檢測異常行為。（5）漏洞管理l 定期更新和補丁管理：及時修復已知漏洞。l 漏洞掃描：主動識別系統中的安全漏洞。（6）隔離和沙箱技術l 虛擬化技術：隔離不同的應用環境。l 容器技術：提供輕量級的應用隔離。l 應用沙箱：限制應用程序的系統訪問權限。中國汽車基礎軟件發展白皮書 5.00641.2 可信計算可信操作系統（TEEOS）是一種具有高度安全性和可靠性的操作系統，它

228、通過硬件和軟件的結合，提供更強大的安全保障?？尚挪僮飨到y的主要特征包括：（1）可信根（RootofTrust）建立從硬件到軟件的信任鏈，通常包括：l 可信平臺模塊（TPM）：提供硬件級的安全功能。l 安全啟動：確保系統啟動過程中每個組件的完整性。（2）完整性度量和驗證l 在系統啟動和運行時對關鍵組件進行完整性度量。l 使用可信存儲保護完整性度量基準值。（3）強化的訪問控制l 實現細粒度的訪問控制策略。l 支持多級安全（MLS）模型。（4）安全域隔離l 利用硬件虛擬化技術實現強隔離。l 實現可信執行環境（TEE），如 ARMTrustZone。（5）動態安全策略l 支持基于上下文的動態安全策略調

229、整。l 實現自適應安全機制。（6）安全審計和取證l 提供不可篡改的審計日志。l 支持實時安全事件分析和響應。1.3 演化趨勢操作系統的信息安全一直在發展，目前的幾種發展趨勢為：（1）零信任安全模型零信任安全模型是一種新興的安全架構，它的核心理念是”永不信任，始終驗證”。在開放架構的操作系統中，零信任模型的實施包括：a.持續身份驗證：不僅在登錄時，而是在整個會話期間持續驗證用戶身份。b.最小權限訪問：精細化控制每次資源訪問。c.微分段：將網絡分割成小的安全區域，限制橫向移動。d.持續監控和分析：實時監控所有網絡流量和系統活動。（2）人工智能和機器學習在安全中的應用a.異常檢測：使用 AI 算法識

230、別異常的系統行為和用戶活動。b.自動化威脅響應：根據 AI 分析結果自動采取防御措施。c.預測性安全：預測潛在的安全威脅并提前采取防護措施。（3）容器和微服務安全隨著容器和微服務架構的普及，操作系統安全也需要適應這種新的部署模式：a.容器隔離：加強容器間的隔離，防止容器逃逸。中國汽車基礎軟件發展白皮書 5.0065b.鏡像安全：確保容器鏡像的完整性和安全性。c.運行時保護：監控和保護容器運行時的安全。（4）邊緣計算安全隨著邊緣計算的發展，操作系統安全需要擴展到分布式環境：a.輕量級安全解決方案：適應資源受限的邊緣設備。b.分布式信任機制：在邊緣節點間建立信任關系。c.安全數據同步：確保邊緣和云

231、端數據的安全同步。在開放架構下，實施全面的信息安全策略，結合可信計算技術，現代操作系統正在向更安全、更可靠的方向發展。然而，安全是一個持續的過程，需要不斷適應新的威脅和技術變革。隨著人工智能和邊緣計算的發展，操作系統安全將繼續演進，為數字世界提供更堅實的保護。2.功能安全功能安全（FunctionalSafety）是指確保系統或產品在其預期的生命周期內，即使在某些組件發生故障的情況下，仍然能夠安全運行，從而避免對人員造成傷害或對財產造成損害的能力。功能安全在操作系統領域的應用主要分三個方面：對 Linux 內核做功能安全補強，在本章節第一部分第 4 小節 SafetyLinux有詳細介紹；通過

232、功能安全認證的實時操作系統；操作系統作為重要組成，使系統滿足功能安全需求。本小節主要介紹用于操作系統領域的常見的安全措施。2.1 安全冗余功能安全通過風險評估工具（如 HAZOP、FTA）識別潛在的危害，并評估其風險水平?；陲L險評估的結果，制定明確的安全要求規范，定義系統應具備的安全功能。通過設計滿足安全要求的系統架構，并考慮冗余、故障檢測等機制，并確保通過測試和驗證確保系統滿足安全要求。在功能安全領域，通常會采用冗余設計來提高系統的可靠性和安全性，尤其是在那些對安全性有極高要求的應用中，比如航空航天、汽車、鐵路交通和工業自動化等。冗余可以采取多種形式，包括軟件冗余、時間冗余、路徑冗余和硬件

233、冗余等。幾種典型配置:2oo2(TwooutofTwo):2oo2配置意味著有兩個相同或相似的組件，并且需要兩個組件中的至少一個正常工作以保持系統的運行。在這種配置下，如果其中一個組件發生故障，則另一個組件可以接管其功能，從而維持系統的安全性。2oo3(TwooutofThree):2oo3配置則包含三個相同的組件，但只需要其中任意兩個組件正常工作即可保證系統的運行。與 2oo2 相比，2oo3提供了更高的容錯能力，因為即使有一個組件發生故障，系統仍然可以通過其他兩個正常工作的組件來維持運行。這兩種配置通常應用于表決系統中，其中各個組件輸出的結果會被比較，以決定最終的系統行為。表決邏輯可以幫助

234、過濾掉錯誤的輸出，從而提高系統的安全性和可靠性。這兩種配置的實現通常需要從硬件、操作系統、到軟件的逐一認證及整合，構造完整的認證系統。2.2 異構設計異構系統是指由不同類型的組件構成的系統。這些組件可能基于不同的架構、使用不同的編程語言或者有不同的設計原理。異構系統的設計目的是通過多樣化來降低共模故障的風險，即不同類型的錯誤不會同時影響所有的組件，從而提高了整個系統的安全性和可靠性。異構系統的不同的計算平臺可能會并行執行同一任務的不同版本，這樣即使有一個版本出現了缺陷，其他版本仍可以提供正確的結果。異構系統對系統的組成部分，包括硬件、操作系統、應用軟件提出了更高的質量要求，在通用的軟硬件模塊基

235、中國汽車基礎軟件發展白皮書 5.0066礎上，通過冗余來實現降低故障概率的目標。這些方案都是為了增強系統的安全性而設計的，每種方案都有其適用的場景。選擇哪種方案取決于具體應用的需求、成本考慮以及所需的故障容忍級別。在實際部署時，還需要綜合考慮系統的復雜性、維護性以及長期支持等因素。在車用操作系統中，功能安全是關鍵領域，將面向更高的實時性、更強的隔離性、更智能的檢測與預防、以及更嚴格的安全認證方向發展。（三）人工智能與操作系統基于 AI 自我學習與不斷進化的能力，在操作系統領域，AI 與操作系統的結合主要有三個方面:分別是 AIforOS,即基于 AI 在研發領域、軟件工程的能力，促進操作系統技

236、術演化；二是 OSforAI，即操作系統用于支撐 AI 的訓練和進化；第三是 AIasOS，即形成 AIOS，由 AI 執行操作系統的任務調度和資源管理，AI 本身成為操作系統。1.AI for OS基于 AI 訓練的操作系統的開發模型，可以用于對操作系統進行設計、編碼、調測、優化、漏洞分析、補丁檢測和安全增強方便的促進。AI 在研發和軟件工程領域的介紹請參考本書 5.3 節。2.OS for AIAI 大模型的訓練，對計算資源有極高的需求。（1）虛擬化對 AI 的支持為了提高資源利用效率和系統靈活性，虛擬化技術在面向 AI 大模型的開放式軟件架構中發揮了至關重要的作用。虛擬化對于 AI 的支

237、撐，包括 AISoC 的虛擬化支持，AI 加速器（如 NPU、GPU 等）的虛擬化適配，跨域數據傳輸，AI 加速器相關固件加載，資源管理等。虛擬化技術為 AI 應用的部署提供了堅實的基礎。通過隔離性，虛擬化技術確保 AI 應用不會與關鍵的控制應用產生相互影響，從而保障系統的安全性與穩定性。同時，虛擬化的靈活性和可移植性為 AI 應用提供了更加便捷的部署方式。在面向 AI 的虛擬化部署場景中，以下幾種應用尤為重要：a)AI 訓練：為不同的訓練任務提供獨立環境，避免資源沖突，確保訓練過程的穩定性。b)模型測試與驗證：通過快速創建多種測試環境，加速 AI 模型的測試與驗證，提高開發效率。c)AI 部

238、署：l 分布式計算：靈活部署實時和非實時環境，支持多層級端邊云分布式計算，以應對大規模計算需求。l 資源動態擴展：在 AI 模型訓練或推理的過程中，動態擴展資源以應對峰值需求。為進一步優化 AI 的部署環境，虛擬化技術需要在以下幾個方面進行改進：a)提高性能，降低損耗：針對 AI 應用的部署需求，優化虛擬化技術，確保虛擬化環境下的計算性能接近物理環境。b)確保實時性：在 AI 應用中增強交互和數據處理能力的同時，虛擬化技術必須確保系統能夠滿足實時響應的需求，特別是在工業和汽車領域。c)強化安全性：加強虛擬化環境的安全防護機制，確保功能安全和信息安全，為 AI 應用的數據安全和關鍵設施的功能安全

239、提供保障。中國汽車基礎軟件發展白皮書 5.0067d)提升兼容性與互操作性：確保虛擬化技術的良好兼容性，為 AI 應用的軟件和硬件需求提供穩定的部署環境，并增強系統的互操作性。（2）實時操作系統對 AI 的支持實時操作系統（RTOS）不僅需要滿足傳統實時系統的要求，如實時性和可靠性，還需要適應 AI 模型的復雜性和資源密集型特點。實時操作系統主要應用在關鍵的邊緣終端設備上，在部署端為 AI 應用提供數以億計的實時邊緣終端，無論是做為數據來源或做為實時處理的端節點，在 AI 應用交互架構中，發揮了末端神經以及“本能反應”的作用。實時操作系統（RTOS）是端邊云中不可或缺的重要節點，且數量龐大。在

240、邊緣設備的實時操作系統，有著通用操作系統的作用，也有其獨特的特性。RTOS 負責高效地管理設備的計算資源（如 CPU、GPU）、內存和存儲空間，確保 AI 應用推理過程、或者在線訓練，如強化學習過程能夠獲得所需的資源。實時操作系統確保在有限資源的情況下，通過高效的調度機制，確保實時任務能夠及時執行，同時支持非實時的 AI 任務。實時操作系統支持故障檢測與恢復機制，確保系統的高可用性和穩定性，并通過支持功能安全以及信息安全的安全機制，保護數據和模型不被惡意攻擊，并確保數據隱私。通過優化節點間的通信，減少延遲并提高數據傳輸效率，特別是對于分布式部署的場景。實時操作系統在支持 AI 大模型的應用時需

241、要提供 AI 應用所需的必備環境。如高性能計算支持，支持并行計算框架（如 TensorFlow、PyTorch）。通過低延遲實現實時響應及控制，通過優化內核、減少上下文切換等手段，減少任務執行及對中斷的響應延遲。支持 AI 應用所需的多樣化的硬件加速器，如 CPU、GPU、NPU、BPU、FPGA、ASIC 等硬件加速器，提高計算效率。提供內存優化，針對大模型的內存需求，優化內存管理策略，減少碎片化。同時還需保持實時操作系統的自有特性，提供功能安全及信息安全增強，確保數據傳輸和存儲的安全性，防止未授權訪問。通過增強可擴展性，支持模塊化設計，支持 AI 應用快速迭代的，易于添加新功能或更新現有功

242、能。實時操作系統需要隨著 AI 應用架構的發展，不斷地改進和革新。隨著邊緣計算的普及，RTOS 將更加關注如何在邊緣設備上高效地運行 AI 模型，減輕云中心的負擔。RTOS 將更緊密地與專用硬件加速器集成，以支持更高性能的計算任務。RTOS 將不斷發展關注其功能安全機制以及信息安全機制的實現，以應對日益增長的安全威脅。RTOS 將朝著更加智能化的方向發展，能夠根據環境變化自適應調整其行為，以提供實時與非實時任務的混合執行能力提高系統資源利用率。隨著開源文化的推廣，RTOS 也需要更加開放，鼓勵社區貢獻和創新，形成更強大的生態系統。RTOS 以其高可靠性和實時性著稱，在自動駕駛和智能座艙等需要精

243、準時序控制的場景中至關重要。AIOS 在設計時，需要將 RTOS 的優勢融入其中，以確保系統在處理 AI 任務時仍能滿足嚴格的實時性要求。l 實時任務調度：AIOS 需要集成 RTOS 的實時任務調度機制，確保 AI 大模型的推理和計算任務能夠在規定的時間內完成，避免因延遲而導致的安全風險。l 實時數據處理：RTOS 可以為 AIOS 提供高效的數據處理能力，使得傳感器數據能夠及時送達AI 模型進行處理，進而提升自動駕駛系統的響應速度和決策準確性。通過將 RTOS 與 AIOS 結合，系統能夠在確保實時性和可靠性的前提下，支持復雜 AI 計算任務的高效執行。l 任務優先級管理：在 AIOS 中

244、，可以借鑒 RTOS 的任務優先級管理策略，將關鍵 AI 任務設置為高優先級，確保這些任務在資源緊張時仍能得到優先處理。l 多任務并行執行：AIOS 應支持多任務并行執行，通過 RTOS 的調度機制，優化 AI 大模型的中國汽車基礎軟件發展白皮書 5.0068計算任務和系統其他任務之間的協調，實現資源的最優配置。（3）Safety Linux 對 AI 的支持SafetyLinux 作為一類針對安全關鍵系統設計的操作系統，能夠為 AI 提供強大的安全保障。l 功能安全性：SafetyLinux 通過嚴格的安全認證和安全機制，確保操作系統在執行 AI 任務時不會因系統故障導致功能失效?；?Sa

245、fetyLinux 的安全架構，可以構建出一個高度可靠的 AI計算環境。l 信息安全防護：SafetyLinux 的安全特性可以用于保護 AI 模型和數據，防止外部攻擊或內部惡意行為對系統造成影響。SafetyLinux 中的多層安全機制可以幫助 AI 系統實現功能和信息安全，從而提升整個系統的可靠性。l 隔離與容錯機制：基于 SafetyLinux 的隔離與容錯機制，通過虛擬化技術實現系統內部不同任務和模塊的隔離，防止單點故障對整個系統的影響，并通過容錯機制提升系統的整體安全性。3.AI as OS近些年，國內外有多家研究機構進行能自我調度任務、分配資源的 AIOS 研究。其中，LLMOS（

246、大模型操作系統）有較大進展。LLMOS 不僅適用于智能手機、智能家居等消費電子領域，還在自動駕駛、工業自動化等需要高度智能化和實時響應的場景中展現出強大的潛力。它代表了未來操作系統的發展方向，即從傳統的功能性操作系統向智能化、自我優化的方向演進。大模型操作系統（LLMOS）是指基于大語言模型（LLM）技術構建的操作系統，旨在通過深度學習和自然語言處理等 AI 技術，為操作系統提供智能化能力。圖4.3-1 大模型操作系統如圖 4.3-1大模型操作系統所示，AgentApplications 與 LLMKernel 和 OSKernel 的交互流程具有明確的層次分工和交互機制，如下描述：l Age

247、ntApplications：位于系統的最上層，直接與用戶交互，提供特定的功能或服務。例如，中國汽車基礎軟件發展白皮書 5.0069旅行規劃、編程輔助、數學計算等。這些應用程序是用戶體驗的直接接口，負責收集用戶輸入并顯示處理結果。l LLM 系統調用接口：這是 AgentApplications 與 LLMKernel 交互的橋梁。當 AgentAppli-cations 需要利用大型語言模型（LLM）的能力進行推理或生成內容時，它們通過此接口發起請求。該接口負責將應用程序的高層請求轉化為 LLMKernel 可以理解和處理的操作指令。l LLMKernel：負責處理與 LLM 相關的所有任務

248、。LLMKernel 接收從 LLMSystemCallIn-terface 傳遞的請求，執行必要的語言模型推理或數據處理，然后返回結果。這個模塊可能還包括管理和優化 LLM 性能的工具，如緩存、模型切換等，以確保高效的處理速度和資源利用。l OSKernel：作為系統的核心模塊，OSKernel 管理整個系統的資源，如 CPU 調度、內存管理、文件系統訪問、網絡通信等。AgentApplications 在需要系統級服務時（例如文件讀寫、進程管理、網絡請求等），會通過系統調用與 OSKernel 進行交互。OSKernel 確保這些請求得到適當的資源分配，并維護系統的穩定性和安全性。交互流程

249、：l AgentApplications 發出請求：當用戶在應用程序中執行操作（如輸入查詢或命令）時，AgentApplications 會決定是否需要 LLM 的處理能力或操作系統資源。l LLM 請求：如果需要 LLM 支持，應用程序通過 LLM 系統調用接口向 LLMKernel 發送請求。LLMKernel 處理請求，例如生成自然語言響應、分析文本或執行數據推理。l 操作系統服務請求：如果應用程序需要訪問系統資源（如存儲文件、分配內存），它會通過標準的系統調用接口向 OSKernel 發送請求。OSKernel 負責提供這些服務，并確保資源的有效利用和安全管理。l 結果返回：處理完成后

250、，LLMKernel 和 OSKernel 將結果返回給 AgentApplications，后者再將最終的處理結果呈現給用戶。數據流和控制流：l 數據流：用戶輸入的數據首先流向AgentApplications，經由LLMKernel或OSKernel處理后，生成的結果再流回 AgentApplications，最終反饋給用戶。l 控制流：AgentApplications 通過調用接口控制 LLMKernel 和 OSKernel 的行為。它們根據任務的需要，發出不同的系統調用，觸發相應的內核服務或 LLM 處理。操作系統內核根據這些調用執行具體的資源管理、任務調度等操作。這種架構設計使得

251、 AgentApplications 能夠高效地利用 LLM 的強大功能，并訪問操作系統提供的廣泛資源和服務，最終實現豐富、動態且高響應的用戶體驗。通過明確的模塊分工和接口定義，系統確保了應用程序層與內核層之間的高效、可靠、互動。LLMOS 基于自我進化能力能夠使操作系統在運行過程中持續優化自身性能、提高安全性、增強穩定性，并且自動適應新的硬件和 AI 模型。LLMOS 的自我進化能力可以通過以下幾種機制實現：l 在線學習與更新：基于在線學習機制，實時分析和學習操作系統在運行過程中的數據和行為模式，根據學習結果動態調整資源分配策略、優化任務調度機制，并適應新加入的 AI 模型和硬件設備。l 自

252、適應算法：通過自適應算法，根據系統的運行狀況和外部環境變化自動調整系統參數。例如，中國汽車基礎軟件發展白皮書 5.0070系統可以根據當前的計算負載、溫度、能耗等因素，動態調整 AI 模型的推理頻率、調度策略以及資源分配，以實現性能和能效的平衡。l 自治安全管理：利用 AI 技術自動監控和檢測潛在的安全威脅，并在檢測到異常時自動采取應對措施。例如，系統可以自適應地增強安全防護機制、隔離潛在危險模塊或動態修復漏洞，從而提升整體系統的安全性。l 智能故障恢復：在發生系統故障時，通過智能故障診斷和恢復機制，自動分析故障原因，并采取相應的修復措施，減少系統宕機時間，提升系統的可用性。中國汽車基礎軟件發

253、展白皮書 5.0071五、開放式軟件架構的工具鏈隨著開放式軟件架構的不斷演進，傳統的開發方法和工具已難以滿足其快速變化的需求。為了有效應對這一挑戰，我們需要對開發方法和工具進行全面的升級和優化，以確保技術的前瞻性和市場的適應性。與傳統的汽車軟件開發相比，新的汽車軟件開發過程中需要引入敏捷開發模式、模塊化設計、標準化接口、持續集成與持續部署、跨領域合作、安全管理、AI 賦能等新的開發理念，通過不斷優化開發方法和工具，持續推動汽車軟件行業的持續高品質發展。本章節將介紹開放式軟件架構的工具鏈，旨在提出一套定義清晰、合理、簡單、統一的開發方法和開發者工具，促進開放式軟件架構的標準化使用。（一）經典工具

254、鏈在汽車領域開放式軟件架構中，開發者工具是連接軟件開發者與系統硬件、中間件及最終應用的橋梁，也是保障系統有效開發和維護的關鍵。隨著汽車電子電氣架構的不斷復雜化，特別是在多域融合架構中，各種開發者工具的應用顯得尤為重要。這些工具不僅需要支持不同領域的開發需求，還需要提供統一的接口和標準，以確保系統各部分的順暢集成。它們不僅提升了開發效率，還確保了軟件質量，促進了多域融合架構下軟件的快速迭代與部署。在智能網聯汽車領域，高效、全面的開發工具鏈是支撐技術創新與產品快速迭代的關鍵，也是影響開發效率、軟件質量、調試和測試工作的重要因素，因此簡單易用的開發者工具是極其重要的。1.面向 MCU 的標準基礎軟件

255、的開發者工具針對傳統 MCU 領域，ClassicPlatformAUTOSAR 的開發方法學分為三個階段：系統設計與配置階段、ECU 設計與配置階段、代碼生成階段。Arxml 作為系統描述文件，用于對軟件組件、ECU 資源和系統約束機型描述。如圖 5.1-1 所示，為 ClassicPlarformAUTOSAR規范定義的開發流程。圖5.1-1 CP AUTOSAR定義的開發流程中國汽車基礎軟件發展白皮書 5.0072a.第一階段：定義系統配置文件，包括硬件的功能組件、系統通信方式、通信節點、報文數據類型等，通過這些配置約束生成系統描述 arxml 文件和通信描述 arxml 文件。系統描述

256、 arxm 定義系統組件接口、組件內部行為、組件接口數據類型、組件間連接關系等。通信描述 arxml 定義整個系統通信種類，包括總線報文、總線信號、組件和信號的映射關系等。b.第二階段：提取各個 ECU 相關的系統描述文件，對 ECU 完成必要的配置，例如 OS 調度、各個BSW 模塊的配置、組件和底層服務的 Mapping、MCAL 配置等，并生成對應模塊的 arxml 描述文件。c.第三階段：通過工具將模塊 arxml 描述文件和 SWC 描述文件生成邏輯代碼，經由編譯器和連接器生成可執行文件。上述 AUTOSARClassic 方法論描述了從系統設計到各個 ECU 配置到代碼集成的整個過

257、程，建立了一套標準化的平臺方案，大部分工作都可以通過工具配置完成，縮短了產品的開發及設計周期，提升了平臺產品的復用性。2.面向 SOC 的標準基礎軟件的開發者工具針對自適應應用的開發，AdaptivePlatformAUTOSAR 將應用程序的開發方法論進行了標準化，在應用服務設計的同時引入了 Manifest 的概念，它是 AUTOSAR 的一種模型描述文件，主要包含自適應應用程序部署所涉及的一些配置信息，可用于基于工具化配置的應用開發。如圖 5.1-2 所示，為 AdaptivePlatformAUTOSAR 規范所定義的開發方法。圖 5.1-2 AP AUTOSAR定義的開發方法面向SO

258、C的標準基礎軟件的開發者工具，遵循 AdaptivePlatformAUTOSAR 標準的開發方法學，其配置流程包括：（1）軟件層設計a.服務接口設計：定義服務的接口類型，如 Method、Event 及 Field，并完成對應接口的數據類型的定義；b.服務接口部署：選擇服務所使用的通信協議，將服務接口與應用層協議進行綁定。c.服務接口序列化：提供為 SOME/IPpayload 序列化方式的配置功能，可配置通信數據的序列化/中國汽車基礎軟件發展白皮書 5.0073反序列化（通信接口級別）規則。d.應用服務設計：定義軟件功能組件、定義可執行文件、定義可執行程序，設計三者關聯配置關系。（2）硬件

259、層設計a.以太網拓撲設計：在域控制器中支持多網卡網絡拓撲設計，通過配置實現服務與網卡的綁定；b.Machine 設計及部署：設計 ECU 級別的全局文件存儲限制、功能組、診斷車輛宣告標識、診斷邏輯地址、PNC 網絡、網絡拓撲等；（3）通信層設計a.軟/硬件映射：通過將 Machine 與服務接口、服務實例、進程進行 Mapping，在軟硬件解耦的前提下實現映射，部署后可進行通信；b.服務實例化：為服務接口分配實例 ID，應用通過服務實例進行通信，一個服務接口可以實例化為多個實例；c.以太網通信設計：實現服務發現多播 IP 地址綁定、定義服務發現端口號、定義 TCP 通信心跳包時間間隔、定義接收

260、 TCPACK 時間間隔等。3.車輛基礎服務的開發者工具針對跨域跨核的整車業務需求，車輛基礎服務中間件基于跨域服務進行整車視圖下的跨域跨核開發。車輛基礎服務為應用層提供各類可復用的服務模塊，使應用開發者可以直接調用封裝好的各類通用服務，減少服務的重復代碼維護，提高開發效率。圖5.1-3 車輛基礎服務開發流程車輛基礎服務中間件工具鏈作為車輛基礎服務配置工具，實現了基于 AUTOSARCP/AP 組件的配置功能和框架，擴展了整車視圖下的跨域跨核應用配置方法學，如圖 5.1-3 車輛基礎服務中間件開發流程所示，主要包括如下方面：（1）設計a.業務設計：根據業務設計功能；b.配置監控：根據私有協議的

261、ID 分配原則為業務分配 ID；c.工具配置：根據業務 ID 分別配置 SOC 和 MCU 的功能服務。（2）開發與部署a.模塊應用開發：根據設計的私有協議 ID 開發業務功能；b.編譯與集成：分別對 SOC 和 MCU 的工程使用對應編譯鏈進行編譯；（3）測試與驗證：運行系統，對程序功能驗證。具體流程如圖 5.1-4 所示：中國汽車基礎軟件發展白皮書 5.0074圖5.1-4 開發流程4.整車通信總線的開發者工具針對跨域跨核應用的通訊，整車通信總線進行整車視角的通訊矩陣配置。整車通信總線為應用層提供整車通訊基礎框架，使應用可以直接調用封裝好的統一的通訊接口，無需關注具體通訊的細節，便于應用的

262、快速開發以及跨域跨核的移植。如圖 5.1-5 整車通信總線的開發方法所示，具體步驟如下：a.MCU 在整車通信過程中，首先要配置 PortInterface，并導入到 MCUSWC 中。PortInterface 用來映射成整車通信總線的數據結構。一個 PortInterface 下的 Signal 可以映射一個數據結構，也可以多個PortInterface 下的 Signal 映射一個數據結構。一個數據結構與一個 Topic 對應，表示這個 Topic 對應的數據類型。配置完成后，生成 MCU 用的 S2S 通信配置的 arxml 和對應的 S2S 代碼；b.SOC 在整車通信過程中，也需要

263、配置通信數據結構，同樣是與 Topic 對應，也可以通過 Protobuf導入自定義的數據結構進行對應。除此之外，整車通信總線已經內置了預定義消息，定義了常用的數據結構，可以直接使用；c.配置好 Topic 和對應的數據結構，就可以做通信的映射，指定整車通信總線針對一個 Topic 的接收端和發送端，接收或發送端指向 MCU 的就會用到從 PortInterface 下 Signal 映射的數據結構。接收或發送端是 SOC 的可以使用整車設計中 arxml 中定義的，導入的 Protobuf 數據類型和預定義數據類型。AP 的 CM 模塊也可以通過整車通信總線的 Broker 映射與整車通信總

264、線互相通信。完成映射配置后，會產生整車通信總線的配置文件?？梢赃M行 MCU 的應用開發，也支持用 Python 開發應用。中國汽車基礎軟件發展白皮書 5.0075圖5.1-5 整車通信總線的開發方法（二）開放的高效開發框架業界需要一種低門檻的、高效率的、AI 友好的開發語言和編程框架，以便于高質量的開發創新應用，滿足汽車行業快速增長的軟件創新需求。一個開放的高級語言開發框架是可以滿足這些需求，它具有如下特征：l 提高開發效率：開放的高級語言開發框架提供豐富的預定義組件和模塊，使得開發者能夠快速構建應用程序；l 簡化復雜度：這些框架通常遵循成熟的設計模式和最佳實踐，幫助開發者用簡單的方式去管理復

265、雜的系統交互，如多線程處理、網絡通信、數據管理等；l 促進代碼復用：通過提供標準化的接口和可重用的代碼庫，減少重復工作，并且有助于保持代碼的一致性和可維護性；l 增強可擴展性：框架的設計需要考慮系統的擴展需求，允許開發者輕松地添加新功能或修改現有功能，而不破壞原有的系統結構；l 改善軟件質量：由于框架通常經過廣泛的社區測試和驗證，因此它們可以幫助減少開發過程中的錯誤和漏洞，提高軟件的整體質量和安全性；l 支持跨平臺開發：高級語言框架應該支持跨平臺開發，這意味著開發者可以使用相同的代碼庫為目標于不同操作系統或硬件環境的應用程序進行開發；l 降低技術門檻：統一的開發框架應該具有較低的學習門檻，使新

266、成員更容易融入項目，并快速掌握開發技巧；l 降低維護成本：由于代碼更加標準化和模塊化，因此長期來看，這會減少維護成本并簡化未來的升級過程。中國汽車基礎軟件發展白皮書 5.0076開放的高效開發框架可以提前產品上市時間，提升軟件質量，同時降低總體軟件成本。隨著智能化的發展，車端會與云端、移動終端有更多的交互。同時車內的 IVI 與其他控制器的交互也越來越多。云、移動終端、IVI 的 Android 都屬于互聯網生態，在互聯網生態中，WebService 是多設備間的調用最常用的方式。整車軟件架構中增加定義 WebService 的支持，可以更好的支持與互聯網生態的協同。同時針對車內的應用，提供車

267、內統一的通信框架與對外的 WebService 間的映射，使得基于整車通信總線開發的應用，既可以實現車內的 SOA，又可以與互聯網無縫連接，同時也可以更便捷的支持 AI 交互。1.高效開發框架的定義目前汽車軟件領域主流的編程語言是 C/C+，相比 C/C+來說，高級編程語言具有學習成本低、程序可維護性強、移植性強等特點。但同時高級語言也有一些缺點，在執行效率、資源占用、安全性上不如C/C+。因此一般比較復雜的軟件系統，在開發平臺中需要同時支持 C/C+等低級語言用于滿足執行效率與資源占用要求，同時也需要支持高級語言用于創新、開放、開發效率的要求。隨著電子電氣架構的演進，域控制器芯片的算力顯著提

268、升，也為高級語言的應用提供了合適的運行環境。為加快汽車軟件的開發、迭代進程，需要一種易學的、開發效率高的高級語言來支撐軟件開發。這里我們以 Python 語言為例，對高效開發框架進行說明。Python 的開發社區活躍性較高、對全面的標準庫與第三方庫支持度高，同時也是一門 AI 友好的語言，可以方便的將各種各樣的 AI 開源算法庫和基礎工具整合起來。例如 Python 支持現代 AI 框架，包括 TensorFlow、PyTorch 等主流深度學習框架都提供了良好的 PythonAPI 支持，這使得在汽車領域進行復雜的感知任務（如物體識別、路徑規劃等）變得更加簡單直接；同時 Python 語言具

269、有豐富的 AI 基礎庫支持，如 NumPy、Pandas、Matplotlib、Scikit-Learn 等，這些庫可以極大地簡化數據處理、機器學習模型訓練等工作，加速 AI 開發流程。因此 Python語言受到 AI 開發者、算法開發者的青睞，用于解決大量邏輯復雜、規模龐大的工程應用問題。因此，引入 Python 高效開發框架作為 AI 基礎支撐，是符合汽車軟件領域的未來發展趨勢的，但是僅僅將 python 的運行環境和 AI 庫、框架移植到車端無法完成車輛 AI 的整體開發支持，需要考慮如何將車端原有基礎功能如 AP 中的診斷、通信、日志等與 Python 開發的 AI 應用很好的融合起來

270、?；?Python實現的高效開發框架可以解決此問題。綜上原因，如圖 5.2-1高級語言開發框架所示，框架應具備包裝 AUTOSARAP 和通用服務的能力，如提供 AP 及中間件的 Python 接口，達成 Python 開發的組件與 C+開發組件互通，同時基于高效開發框架開發的 Python 應用可以復用 AUTOSARAP 的安全機制和服務，從而降低開發成本。圖5.2-1 高級語言開發框架中國汽車基礎軟件發展白皮書 5.0077另外，目前車內以太網使用的常用通信協議為 SOME/IP 與 DDS，這些協議在車內運行的 AUTOSARAdaptive、AUTOSARClassic、POSIX

271、 系統的節點可以很容易的進行使用和支持。但在座艙域通用的 An-droid 系統中，由于 Java 原生不支持 SOME/IP 與 DDS 協議，因此需要作轉換并帶來額外開銷，也增加了應用與系統的耦合度。同時，在與云、手機通信中，由于車內與云及手機端不同的通信協議，也會涉及協議轉換。上述問題都會帶來開發效率和耦合性問題。WebService 是一種跨編程語言和跨操作系統平臺的遠程調用技術，在 IT 與互聯網領域使用廣泛，生態成熟且豐富。云端、互聯網、手機端，都是充分使用 WebService 作為遠程調用的方法。而汽車軟件目前使用 WebService 作為遠程調用方法的比較少，是因為并未所有

272、節點都具備支持 WebSerivce 的 HTTPServer 及 Web 框架，以及 C/C+不足以有效支撐 Web 框架的開發效率優勢。因此，在 Python 開發框架之上封裝一套 WebService 開發框架，借此提供更通用、更便捷、更直接可見的交互手段，這就使得高效開發框架具備了 Web 訪問消息的能力，并提供 SOVD(Service-OrientedVehicleDiagnostics)、OpenAPI 的支持，同時允許用戶開發自己的服務程序，從而進一步提高交互的便捷性，降低開發成本，極大的提升云端和座艙域開發者的開發效率。2.高效開發框架的功能高效開發框架的結構介紹如下：a)應

273、用層：用戶可以開發 PythonAdaptiveApplication（PAA）或 PythonScript（PS）；也可以通過 HTTP 請求訪問提供的 WebService；還可以通過 Framework 提供的 API 工具進行 API 測試。b)WebServiceFramework：框架核心部分，也是資產復用的核心，提供 Web 屏蔽、參數轉換、調度、異常處理、調試和日志、以及認證、權限、會話、賬戶管理、預定義消息、日志等級控制、SOVD、OpenAPI功能；ServiceFramework 可以運行在 Web 進程中作為 WebService 的入口屏蔽 django 等 Web

274、基礎框架的依賴，也可以通過 CLI 運行 PyService 或執行針對 PyService 開發的測試用例。主要包含以下子功能模塊：i.預定義消息：作用是在軟件中抽象車輛基本數據(例如車速數據、雷達數據等)，然后發布到整車通信總線,統一車輛數據獲取接口。其他應用程序或服務可從整車通信總線中訂閱預定義消息。ii.日志控制：允許遠程調整日志記錄的級別，能夠通過Web服務在一個中心位置管理多輛車輛的日志設置，便于集中管理，并且可實時查看和調整日志等級，有助于故障診斷和性能優化。iii.SOVD 支持：AUTOSAR 新的診斷標準，Service-OrientedVehicleDiagnostics

275、（面向服務的車輛診斷），通過采用面向服務的方法來改進傳統的車輛診斷過程。在傳統的診斷過程中，診斷請求和響應通常是硬編碼的，每個診斷服務都有其固定的請求和響應格式。然而，在現代汽車中，隨著電子系統的復雜性增加，這種硬編碼的方式變得難以管理和維護。因此需要引入 SOVD，其核心理念是將診斷服務視為一組獨立的服務，這些服務可以通過定義好的接口來訪問，有助于簡化車輛診斷的開發和維護，同時也為未來汽車電子系統的擴展提供了更大的靈活性。這種方法提供了以下優勢：l 靈活性：SOVD允許動態配置和更新診斷服務，不需要更改底層的硬件或軟件。l 可擴展性：新的診斷服務可以很容易地添加到現有的系統中，而不會影響到現

276、有的服務。l 標準化：SOVD提供了一種標準化的方式來定義和實現診斷服務，使得不同制造商之間的互操作性成為可能。l 簡化集成：通過將診斷服務抽象為服務，SOVD使得不同ECU之間的集成變得更加簡單。iv.OpenAPI支持：為了更好的支持外部系統遠程訪問車內的AI功能，需要通過API實現數據的交換，中國汽車基礎軟件發展白皮書 5.0078并靈活地集成到各種外部系統中；而OpenAPI規范可以確保API的標準化定義，便于開發者無歧義的理解和使用 API 進行開發和集成。c)PythonFramework：框架核心部分，主要是對下層 AUTOSARAdaptivePlatform 和 ASF 中間

277、件的 Python 封裝。d)廣義操作系統層：是使用 C+開發的 ServiceFramework 和 AUTOSARAP 和 ASF 中間件。3.高效開發框架的接口參考Python 應用開發是建立在 AUTOSARAP 和 ASF 中間件之上的，本框架封裝它們的功能，對上層應用提供 Python 語言形式的接口，其主要接口見下表：表5.2-1 Pyhton開發框架接口關聯模塊接口描述整車通信總線Node應 用 使 用 Node，可 以 創 建 出Topic的 Reader/Writer，這些對象隸屬于這個 Node，同時 Node需要使用Executor 執行器，把其中所有通信相關的對象運行

278、起來。ReaderTopic 的訂閱方，通過 Node 來創建 Reader 的實例。WriterWriter 是一個 Topic 的發布方，通過 Node 來創建 Writer 的實例。Timer基于消息總線的定時器，通過Node 來創建其實例。ServerServer 是一個 Method 的提供方，通過 Node 來創建 Server 的實例。ClientClient 是一個 method 的使用方，通過 Node 來創建 Client 的實例。整車數據處理框架VStatusTableVStatusTable 為 車 輛 狀 態 表 操作類。EMExecutionClientExecut

279、ionClient 類用于向 EM 報告進程狀態。PHMSupervisedEntitySupervisedEntity 類用于向 PHM報告檢查點。HealthChannelHealthChannel 類用于向 PHM 報告健康狀態。LOGCreateLogger創建 Logger 對象。LoggerLogger 類 為 對 AP 的 Lt 的 py-thon 化的日志類。PERKeyValueStorage鍵值存儲操作類。FileStorage文件存儲操作類。ReadWriteAccessor文件存儲中讀寫文件操作類。ReadAccessor文件存儲中讀取文件操作類。中國汽車基礎軟件發展白

280、皮書 5.0079關聯模塊接口描述DiagAbstractGenericExcute重寫讀取、寫入 did 的操作類，抽象類，需要繼承實現 Read、Write、CancelRead、Cancel-Write 方法。GenericDataIdentifier讀取、寫入 did 的代理類，使用22/2e 服務時，先繼承重寫 Ab-stractDataElementExcute 類，然后構造 GenericDidProxy 類。Monitor診斷監視器類，提供 Offer 功能阻塞進程。Condition故障產生的前置條件類，當事件綁定的所有前置條件都達到要求時，才會處理通過 monitor 上報

281、的事件，否則忽略。OperationCycle操作周期類，故障管理功能工作的循環周期。DiagUdsNrcErrc調用 Offer 或 ReportMonitorAc-tion 時可能發生的內部錯誤的類型。DataElement外部擴展數據讀取類，可選服務，提供 Offer、StopOffer 函數。WebService 開發框架接口以 URL 方式定義，接口示例：http:/192.168.182.129:8080/e/system/Admin.getAdmin.json?name=”abc”表5.2-2 WebService開發框架接口說明URLPart說明http:/192.168.18

282、2.129:8080協議、IP 和端口部分，以實際部署情況為準/e/固定，表示 wsgi 前綴system/Admin.getAdmin表示 system 包下執行 Admin 類的 getAdmin 方法。.json表示使用 json 格式輸出，后續可擴展 XML 等格式?name=abcname 為方法參數名，“abc”為參數值的 Json 格式4.高效開發框架的開發方法Python 開發框架的開發方法與 AUTOSARAdaptivePlatform 的應用開發方法一致。WebService 是基于 Python 框架提供 Web 服務的，因此 WebService 開發框架的使用時，需

283、要配置Python 框架。高效開發框架的具體開發流程如圖 5.2-2高效開發框架的開發方法所示：中國汽車基礎軟件發展白皮書 5.0080圖5.2-2 高效開發框架的開發方法在使用高效開發框架進行應用開發時，如下配置需要特別關注：a.Python 框架層功能的配置：i.錯誤碼定義的配置；ii.WebService 日志的配置；iii.API 使用權限定義，配置預置角色是否允許操作 API。b.鎖：如果存在并發訪問的情況下，可能需要考慮鎖機制，本框架應該提供完善的鎖機制。（三）AI 大模型賦能創新工具鏈AI 大模型在汽車軟件開發中扮演著重要的角色，為智能汽車發展提供堅實的技術基礎。本節將從 AI輔

284、助軟件工程的角度探討相關的應用。汽車軟件開發流程包括軟件需求開發、軟件架構設計、軟件代碼開發、軟件測試測試等，工程師可借助以 AI 大模型為基礎的軟件工具輔助開發和測試，如 ChatGPT、智譜 AI、通義千問、GithubCopilot、Codex 等。1.軟件工程變革AI 大模型促進汽車軟件開發工程，由面向過程的開發模式變為面向目標的軟件開發模式。傳統軟件工程是以人為本的協同式開發，強調開發流程、工具、人之間的協同配合，而以 AI 大模型為底座的軟件開發過程，是以數據為本的生成式開發，對協同的要求沒有那么高，通過減少不必要的協同，能極大的提高開發效率。1.1 面向過程的開發模式如圖 5.3

285、-1ASPICE 軟件開發模型所示，目前汽車軟件開發主流遵循 ASPICE 軟件開發模型，AS-PICE 包括了 32 個過程域，其中核心有 16 個過程域。ASPICE 本身是一種面向過程的開發模型，涉及到多個工序和過程，多個開發工種進行協同，通過需求跟蹤來保證需求到交付的完整性。中國汽車基礎軟件發展白皮書 5.0081圖5.3-1 ASPICE軟件開發模型1.2 面向目標的開發模式利用 AI 將現有的 ASPICE 部分過程進行整合，并對接相應的業務子系統，由工程師給出系統和軟件需求，由 AI 執行并生成 ASPICE 過程輸出的相應設計文檔、代碼、測試報告等，工程師對目標交付物進行確認。

286、通過減少過程節點和協作，來優化軟件開發的質量、周期、成本。傳統的軟件工程，需求在傳遞的過程中總有丟失，上下游工序在保證需求準確性時，需要大量的標準化 UML 設計和面對面溝通講解，產生了很大的溝通協作成本，而效果又不盡人意。同時大量的文檔需要人工寫作，同時極易產生設計與實現不符的問題。如圖 5.3-2 所示，AI 大模型賦能軟件工程，使開發過程全數字化，通過 AIGC 生成軟件開發過程中的各種產物：如設計文檔、代碼、測試腳本、測試報告等。過程中對人的依賴性極大的降低，交付周期極致縮短，真正實現持續交付。圖5.3-2 AI用于軟件工程中國汽車基礎軟件發展白皮書 5.0082軟件工程大模型還可以進

287、行模塊化定制部署，包括：(1)軟件需求完善：需求收集、需求分析、文檔補全、需求驗證、溝通橋梁；(2)軟件架構設計：性能優化、復雜設計、快速迭代、架構評估、文檔生成；(3)軟件代碼開發：代碼補全、代碼解釋、代碼優化；(4)軟件測試：測試計劃編制、自動生成測試、測試用例優化；以下進行詳細闡述。2.軟件需求開發在軟件需求開發中，工程師可利用 AI 大模型構建軟件需求開發 AI 助手，通過編制軟件需求開發場景下的提示詞，使 AI 大模型快速理解軟件需求開發流程，在人工梳理和拆分整車系統功能后，AI 大模型可自動生成軟件需求文檔，極大地提升軟件需求的開發效率，同時減少人工編寫軟件需求規格書的錯誤和遺漏。

288、主要包含：1.需求理解與生成；2.文檔編寫；3.需求要點總結；4.內容問答；5.任務總結。2.1 標準解讀在汽車軟件開發過程中，工程師需遵循大量的行業標準，如 AUTOSAR 標準、汽車電子系統功能安全國際標準（ISO26262）、汽車數據處理安全技術要求（GB/T41871）等，工程師在開發前需花費大量的時間完成標準解讀。利用 AI 大模型的文本理解能力，工程師將標準文檔輸入給 AI 大模型進行解讀，生成標準解讀報告，總結提煉重點內容，提升標準解讀的效率。如圖 5.3-3 標準解讀所示，在標準解讀方面有很多用法，常用的有提煉標準要點，介紹標準的背景，發布信息，針對標準的某個部分進行提問等。常

289、用模型：通義千問，文心一言，ChatGPT 等。圖5.3-3 標準解讀中國汽車基礎軟件發展白皮書 5.00833.軟件架構開發傳統的系統架構和軟件架構，是精心設計的構成式軟件架構，受限于架構設計師的經驗和能力，設計質量大為不同。新的架構設計師可能會帶來不同的架構方案，缺乏繼承性。老的架構設計師可能繼承以往架構，同時也繼承大量的技術債，缺乏創新性。AI 大模型賦能軟件架構設計，是一種生成式軟件架構，相比傳統的軟件架構，我們不必從頂層到底層逐步分解，層層定義算法、邏輯、數據、輸入輸出詳細接口、交互流程、狀態機等。我們只需要給出系統和軟件需求，較為抽象的目標定義，AI 就能幫完成接下來的架構、設計、

290、編碼、測試等工作，并且保持開然的設計與實現的一致性，需求到交付的一致性。通過模型訓練和新創新數據訓練，AI 能自動給到我們最優軟件架構，自帶繼承性和創新性。軟件架構設計由構成式軟件架構，向更高效和高質量的生成式軟件架構方向演進。如圖 5.3-4 所示為傳統的軟件架構方法：圖5.3-4 傳統的軟件架構方法如圖 5.3-5 所示為 AI 生成式軟件架構方法：圖5.3-5 AI生成式軟件架構方法中國汽車基礎軟件發展白皮書 5.00843.1 基礎軟件配置AUTOSAR（AUTomotiveOpenSystemARchitecture）是一個為汽車電子控制單元（ECU）提供標準化軟件架構的全球開發合作

291、組織，旨在提高汽車軟件的可移植性、可擴展性和可維護性，主要包括兩種主要平臺：經典平臺（ClassicPlatform,CP）和自適應平臺（AdaptivePlatform,AP）。以 AUTOSARCP 為例，傳統的軟件開發流程如下：1)定義系統配置文件，包括硬件、軟件組件、系統約束條件。2)根據系統配置文件，生成 ECU 配置描述文件。3)使用配置工具生成 ECU 基礎軟件（BSW）。4)定義數據類型及接口，包括基本數據類型、應用數據類型、發送者-接收者接口等。5)DBC 文件導入。6)設計軟件組件，建立軟件內部行為。7)生成 RTE 和 BSW 配置代碼，并完成集成。8)對生成的代碼進行驗

292、證和測試。傳統的 AUTOSARCP 軟件開發流程冗長復雜，軟件故障排查困難，軟件質量嚴重依賴工程師的能力和經驗，軟件開發的門檻較高?；?AI 大模型強大的語義理解和代碼生成能力，軟件開發人員創建 AUTOSARCP 軟件配置的智能AI 工具，結合開源 AI 部署框架 LangChain，通過文本向量化的方式將 AUTOSARCP 的標準轉換為 AI 大模型能夠理解的向量數據，使 AI 大模型快速掌握 AUTOSARCP 相關的行業標準，精通 AUTOSARCP軟件開發流程。相比之下，由 AI 大模型輔助進行的 AUTOSARCP 軟件開發流程可由先前的八個步驟簡化成如下四步：1)使用 AU

293、TOSAR 配置工具創建空白工程文件。2)在 AI 工具中配置工程路徑、DBC 路徑及 AUTOSAR 配置工具路徑。3)通過和 AI 工具進行對話，引導 AI 大模型完成 ECU 配置、BSW 代碼生成、RTE 代碼生成等人工配置流程。4)對生成的代碼進行驗證和測試。在 AI 大模型的輔助下，AUTOSAR 軟件工程服務能夠快速度配置生成解析文件和框架代碼，軟件開發工程師能將數月的開發周期縮短至數天，極大地提升軟件開發效率和質量，同時提高工程師的軟件開發能力，降低軟件開發門檻。4.軟件代碼開發在汽車軟件領域，AI 大模型憑借著其強大的自然語言理解和代碼生成能力，使更多的主機廠在軟件開發流程中

294、引入 AI 大模型。相對于人工軟件開發，AI 大模型輔助下的軟件開發能自動化完成大量重復性開發任務，并對軟件潛在漏洞進行修復，縮短開發周期，極大提升軟件開發效率和質量。在軟件代碼開發中，工程師可使用 GithubCopilot、Codex 等代碼工具輔助開發。以 GithubCopilot代碼生成工具為例，其使用流程如圖 5.3-6基于 AI 的軟件代碼開發流程所示，能夠幫助工程師完成代碼編寫、自動補全、代碼優化、代碼注釋、單元測試等工作，提高軟件開發效率。此外，工程師可使用 AI 大模型生成軟件代碼開發場景下的 AI 助手，通過自然語言交互的方式自動生成數據庫、CAN 通訊等標準化模塊代碼，

295、大大降低了軟件開發門檻，有效提升工程師的代碼編寫能力。中國汽車基礎軟件發展白皮書 5.0085圖5.3-6 基于AI的軟件代碼開發流程常用用法有：a.提出需求，讓模型生成代碼b.粘貼代碼，提出任務描述，在這個代碼基礎上進行修改c.粘貼代碼，讓模型給出代碼質量分析如圖 5.3-7基于文心一言的 C+代碼編寫示例應用舉例：用 c+寫一個單例模式的程序圖5.3-7 基于文心一言的C+代碼編寫示例中國汽車基礎軟件發展白皮書 5.00864.1 BSP 生成BSP（板級支持包）是嵌入式系統開發中重要組成部分，它通過提供硬件抽象接口、設備驅動程序和啟動代碼，使操作系統能夠在硬件平臺上正常運行。傳統的 BS

296、P 的生成過程復雜，涉及硬件分析、啟動代碼開發、驅動程序編寫、操作系統移植和系統調試等多個環節，為 BSP 生成帶來了極大的挑戰，且開發人員需要針對不同的硬件平臺進行適配開發，最終開發完成的代碼質量依賴工程師的軟件開發經驗，難以適應軟件的快速迭代?；?AI 大模型的代碼解析和處理能力，可實現自動識別硬件平臺特性、自動生成設備驅動軟件及代碼漏洞的自動診斷和修復。此外，AI 大模型能夠根據工程師的需求，自動選取合適的軟件工具完成 BSP代碼生成，并基于自身海量的代碼倉庫，可向工程師提供大量的開發建議，拓寬工程師的開發思路，更加高效、可靠地完成 BSP 代碼生成。如圖 5.3-8BSP 編寫示例所

297、示，在 linuxBsp 生成方面，常用的用法有根據描述生成設備樹，對設備樹中的某些字段，節點提問，在已有的設備樹代碼上，根據要求修改代碼等。圖5.3-8 BSP編寫示例中國汽車基礎軟件發展白皮書 5.00875.軟件測試在DevOps理念的推動下，持續集成與持續測試的緊密結合將更加深入。測試不再是開發過程的最后一環，而是貫穿整個軟件生命周期。在軟件測試中，工程師可使用 AI 大模型生成軟件測試場景下的 AI助手，通過輸入軟件測試場景下的提示詞，上傳測試用例編寫模板，AI 大模型可輔助完成測試腳本、測試用例的開發，保證腳本代碼和測試用例的規范性、一致性，提升測試腳本和測試用例的開發效率及質量。

298、在完成軟件測試后，AI 大模型可輔助工程師分析定位軟件測試問題，提供問題解決方案，修復軟件漏洞，提高軟件問題解決效率，確保軟件產品的穩定性和可靠性。中國汽車基礎軟件發展白皮書 5.0088六、開放式軟件架構的生態建設開放式軟件架構的生態系統包含技術生態和產業生態。技術生態主要包括接口統一、技術路線共識，這樣有利于產業鏈上下游合理分工，化整為零，協作開發。產業生態，則是建立開源開放、多層解耦的生態體系，有利于軟件架構的演進和技術路線的聚焦發展，促進產業協同進步。本章節將主要介紹技術生態和產業生態的構建工作。（一）技術生態1.開放式接口的統一API 接口的作用是將軟件系統抽象出來，簡化了不同應用程

299、序之間的交互過程。API 接口的使用，使得軟件開發變得更加快速、高效，并增強了軟件的可擴展性和可維護性。當前各大主機廠以 SOA 的形態研究為目標，提出分層解耦開發目標。從底層的內核與基礎中間件，到框架支撐層的功能軟件，再到上層應用軟件，明確了各層之間的向下依賴關系，各層之間通過規范化的API進行交互，實現了不同層次間的分離與解耦。汽車軟件 API 的統一化和標準化對于智能汽車發展至關重要。API 標準的制定和遵循是為了確保 API 在不同的開發場景中能夠正常運作，并且具備一致的行為和接口。當多個開發者或多個團隊同時開發不同的模塊或服務時，API 標準可以提供一種共同的編碼約定和規范，使得各個

300、模塊或服務之間能夠無縫地協作和集成。在 API 標準發展過程中，過去行業中出現的 API 標準已經初步規定代碼的命名規范、命名約定和語法規則。通過統一的命名和語法規范，提高代碼的可讀性和可維護性。API 規范標準化的三大關鍵要素如下：（1）完整性；即 API 規范必須包含 API 的所有必要信息，包括 API 的接口、協議和安全措施等。（2）準確性；即 API 規范必須準確地描述 API 的功能和行為，不得包含任何錯誤或歧義。（3）簡潔性；即 API 規范必須簡潔明了，易于理解和使用，不得包含任何冗余或不必要的信息。API 規范標準化工作需要建立開放、透明和包容的參與機制，鼓勵來自不同行業、領

301、域和職能的利益相關者共同參與 API 規范標準化工作。定義清晰的參與規則和程序，確保行業參與者有平等的機會參與標準化過程，使其意見和觀點得到充分的考慮和尊重。定期組織研討會、論壇等活動，促進技術生態參與者之間的交流，共同探討和解決 API 規范標準化過程中的問題和挑戰。1.1 POSIX 隨著汽車行業迅速發展產生了從傳統機械和硬件為中心的工程到以軟件為中心的開發的轉變。在這一轉變中，兩個關鍵因素顯現出來：遵循可移植操作系統接口（POSIX）標準的兼容性，以及集成開源第三方庫。POSIX 標準，即可移植操作系統接口（PortableOperatingSystemInterface），定義了一組操

302、作系統接口，旨在跨多個類似 Unix 系統保持兼容性。POSIX 兼容性確保了為一個 POSIX 兼容系統編寫的軟件可以輕松移植到另一個系統上，減少了軟件移植的兼容性問題。對于汽車行業而言，這一標準變得越來越重要，原因包括：中國汽車基礎軟件發展白皮書 5.0089（1）安全關鍵應用中的實時操作系統（RTOS）汽車系統，如 ADAS、動力總成控制和制動系統，要求實時操作以確保安全性和性能。實時操作系統（RTOS）在這些應用中起著至關重要的作用，許多 RTOS 解決方案都是 POSIX 兼容的。POSIX 兼容性確保了開發人員可以利用標準化的系統調用，使得在不同平臺上開發和維護實時應用變得更加容易

303、。例如，制動系統可能需要在事件發生后幾微秒內執行命令。POSIX 兼容的 RTOS 確保了軟件能夠在各種硬件平臺上始終如一地處理這些關鍵時間任務。此外，這種標準化有助于簡化安全關鍵系統的認證過程，例如符合 ISO26262 標準，該標準管理汽車系統的功能安全性。（2）高級駕駛輔助系統（ADAS）和自動駕駛ADAS 和自動駕駛系統依賴于復雜的算法，這些算法必須實時處理大量數據。這些系統通常涉及組件，如傳感器融合、機器學習和計算機視覺，這些組件需要復雜的軟件架構。POSIX 兼容性可以通過提供一組一致的 API（如內存管理、線程和進程間通信的系統級操作）來簡化這些架構的開發。通過遵循 POSIX

304、標準，開發人員可以構建模塊化系統，其中不同組件（例如感知、決策和執行）可以獨立開發，但仍然能夠無縫協同工作。此外，POSIX 兼容系統還可以簡化各種第三方軟件組件的集成，使得更容易將外部供應商或開源社區的創新納入系統中。（3）車載信息娛樂系統（IVI）車載信息娛樂系統（IVI）是另一個 POSIX 兼容性發揮重要作用的領域。IVI 系統管理娛樂、導航和連接功能，它們必須與各種硬件組件（如顯示屏、觸摸屏和網絡接口）交互。POSIX 兼容性使得 IVI 軟件更容易跨不同硬件平臺移植，從而降低了開發時間和成本。此外，POSIX 兼容的 IVI 系統可以利用廣泛的開源軟件，如多媒體框架和網絡協議棧。通

305、過確保與標準 Unix 類操作系統的兼容性，POSIX 兼容的 IVI 系統可以更輕松地集成第三方應用程序和服務，從而提供更豐富的用戶體驗。（4）電動汽車（EV）管理系統電動汽車（EV）管理系統，包括電池管理系統（BMS）和充電控制，要求可靠的軟件在各種條件下運行。POSIX 兼容的操作系統通常用于這些應用中，以確保軟件能夠在從嵌入式控制器到中央處理器的不同硬件平臺上高效運行。例如，BMS 必須監控和控制車輛電池的充放電，在性能與安全之間取得平衡。通過使用 POSIX 兼容的軟件，開發人員可以利用標準化工具和庫來完成實時數據處理、與外部傳感器通信以及錯誤處理等任務。1.2 AUTOSARAUT

306、OSAR（AutomotiveOpenSystemArchitecture）是一個開放且標準化的汽車電子軟件架構，其目標是通過標準化接口和模塊化設計，提高汽車軟件開發的效率、質量和可維護性。其成立的本身目標在于標準化接口，具備如下特點：（1）提高互操作性：通過定義標準接口，使得不同供應商提供的軟件組件能夠無縫集成。（2）簡化集成與測試：減少系統集成和測試過程中的兼容性問題，降低開發復雜度。（3）促進模塊重用：使不同項目之間能夠共享和復用既有的軟件模塊，節約資源。AUTOSAR 部分的內容在本書第三章有詳細介紹，本小節略過。2.通信協議的統一在互聯網領域中 SOA（面向服務的架構）已經被應用和實

307、踐了一段時間，但在汽車行業中，依然是相對較新的概念。在 AdaptivePlatformAUTOSAR 框架中，通信管理模塊包括進程間通信和網絡協議棧。中國汽車基礎軟件發展白皮書 5.0090鑒于整車應用場景和通信需求的特點，SOME/IP、DDS、AMQP、REST、MQTT、和 CoAP 等協議已被廣泛應用，并且每種協議都至少有 10 種不同的代碼實現。汽車通信協議的主要目的是實現車輛各部分之間的協同工作，提高安全性、可靠性和效率。汽車軟件通信協議的統一對于汽車行業的發展至關重要，主要基于以下原因：標準化和兼容性：統一的通信協議能夠確保汽車不同組件、系統之間以及車輛和外部網絡之間的數據交換

308、更加高效、穩定和安全。通過統一標準的約定，汽車通信協議可以提高汽車各個部件之間的協同工作的能力，從而提高安全性、可靠性和效率。技術進步和創新的推動：汽車通信協議的選擇需要根據具體的應用場景和要求來進行，統一的通信協議有助于技術的進步和創新。SOA 架構主要目標是在域內服務和跨域服務打通車云的通信鏈路，但是目前 SOA 接口并沒有完全統一的標準，沒有統一標準就無法達成行業內的可通用性，行業需要一個技術生態共同解決通用性的問題。AUTOSEMO 已于 2021 年初步研討汽車 SOA 架構設計與軟件平臺框架團體標準，該團標形成了系統的 SOA 架構，逐步推進各軟件架構層的汽車通信協議統一。3.開發

309、標準和流程的統一開放式軟件架構的生態建設需要以標準引領為目標，統一加強標準體系建設及規范標準的開發流程。有利于：確保安全性和可靠性：統一的開發標準與流程有助于確保軟件的質量和性能，減少安全問題帶來的風險。提高開發效率：避免因標準不統一導致的開發混亂和重復性的工作。應對技術挑戰：汽車軟件開發面臨著技術復雜性高、迭代快、安全要求高等挑戰。開發標準與流程的統一，有助于工程師更好地聚焦這些挑戰，應對技術問題。綜上所述，開放的軟件架構需要一個統一的開發標準與流程，以確保軟件的質量、安全、效率并推動技術的持續創新和進步。4.開源庫在汽車開發中的重要性使用開源第三方庫已成為汽車軟件開發中的一個重要考慮因素。

310、開源軟件（OSS）提供了許多優勢，包括成本節約、獲取前沿技術，以及利用全球開發者社區的能力。然而，將開源庫集成到汽車系統中也帶來了挑戰，尤其是在確保符合行業標準和安全要求方面。（1）傳感器數據處理現代車輛配備了一系列傳感器，包括攝像頭、LiDAR、雷達和超聲波傳感器。處理這些傳感器的數據需要復雜的算法，如對象檢測、跟蹤和分類。這些算法中的許多作為開源庫提供，例如用于 3D 數據處理的點云庫（PCL）或用于計算機視覺的 OpenCV。通過使用開源庫，汽車開發者可以加速傳感器處理流水線的開發，并利用最新的研究成果。然而，將這些庫集成到安全關鍵系統中需要仔細的驗證和測試，以確保它們符合汽車行業的嚴格

311、可靠性和性能要求。（2）自動駕駛系統中的機器學習和 AI機器學習（ML）和人工智能（AI）在自動駕駛系統中起著至關重要的作用，使車輛能夠從數據中學習并在復雜環境中做出決策。像 TensorFlow、PyTorch 和 scikit-learn 等開源機器學習框架已成為開發汽車領域 AI 模型的熱門工具。中國汽車基礎軟件發展白皮書 5.0091盡管這些框架提供了強大的功能，但在汽車應用中使用它們時需要解決一些挑戰，包括確保模型的可解釋性、可驗證性和安全性。此外，開發人員還必須確保這些框架與底層 POSIX 兼容操作系統的集成不會引入性能瓶頸或安全風險。（3）網絡與連接性隨著車輛的日益互聯，網絡和

312、通信協議已成為汽車系統的重要組成部分。開源網絡庫和協議（如用于消息隊列和通信的 MQTT 協議或用于安全通信的 OpenSSL 庫）常常用于聯網車輛應用中。例如，車輛到一切（V2X）通信使車輛能夠與其他車輛、基礎設施和其他道路使用者進行通信。開源網絡協議?？梢源龠M V2X 解決方案的快速開發，但開發人員必須確保這些庫的安全性、可靠性，并符合ISO/SAE21434 等汽車標準，該標準針對道路車輛的網絡安全性。（4）IVI 和用戶界面開發在 IVI（車載信息娛樂系統）領域，開源庫在構建用戶界面（UI）和多媒體功能中起著重要作用。像Qt 和嵌入式 Chromium 框架（CEF）這樣的框架常用于開

313、發現代化、響應迅速的 UI，這些 UI 提供了高質量的用戶體驗。這些庫允許快速原型設計和開發，使汽車制造商能夠跟上消費者對高級信息娛樂功能的需求。然而，將這些開源庫集成到 IVI 系統中需要仔細考慮性能、兼容性和安全性。例如，在 IVI 系統中使用開源 Web 瀏覽器引入了潛在的安全漏洞，必須通過嚴格的測試和更新來緩解這些漏洞。（二）產業生態1.當前的問題與挑戰在中國汽車基礎軟件發展白皮書 4.0 中，我們提到存在的問題有以下四個。l 國產基礎軟件裝車量有待提高l 硬件、應用、開發者生態構建有差距l 部分標準追隨國外，不能滿足中國應用場景l 國產基礎軟件造血能力低過去一段時間的發展，部分問題已

314、經有了一定的改善，比如目前國產基礎軟件裝車率已從四年前的8%到現在占據了近三成以上。智能化標準這一塊，也有 AUTOSEMO 提出的 ASF、車云一體等標準規范。但在產業鏈生態建設和國產軟件造血能力上，一直沒有大的突破。這反映在當下主要有三個方面的問題：低水平重復建設：當下中國汽車圈的熱點詞匯一定是“卷”。主機廠卷價格、卷配置、卷上市時間，這種氛圍已經波及到整個產業鏈的上下游。在汽車產業新四化發展進入到智能化階段，我們看到不僅有傳統的主機廠、供應商在積極進行智能化轉型，新勢力基本沿著全棧自研的路線在做相關領域研發，科技公司和很多外部力量也紛紛下場。一時間市場紅海一片，低水平重復建設比比皆是。這

315、不僅導致行業整體議價水平低下，無法形成持續投入持續創新的研發與商業閉環，更是擠占技術創新所需要的人才、資金、設備等多方資源，嚴重影響行業的良性循環發展。軟件價值不被認可：傳統觀念中汽車行業長期以來重視硬件的價值，對軟件的重要性認識不足。定價機制即如何合理地為軟件定價是一個挑戰，特別是在軟件成為汽車差異化的重要因素之后。軟件的價值往往體現在用戶體驗上，但如果用戶對此不夠敏感，則可能不會愿意為此付費。這導致軟件雖然是資金密集型投資領域，但無法讓市場直接買單，進而影響后續的技術研發與創新。AI 大模型的訓練重復投入大量資源：AI 大模型的訓練依賴算法、算料、算力和場景，缺一不可。目前中國汽車基礎軟件

316、發展白皮書 5.0092國內市場上，幾乎每家都在針對 AI 大模型做相關投入。一方面同質化嚴重，算力相關的硬件設備價格昂貴且購買渠道受限，另外一方面針對大模型訓練需要的算料和場景，以一家廠商去支撐覆蓋不足。2.破局之道的思考針對上述問題，我們給出的解決方案是構建開源、開放、分層解耦的立體生態體系：建立評估和遴選體系：建立評估和遴選體系，避免業內扎堆重復投入單一領域，造成行業低水平內卷。行業標準的持續建設與推廣：針對共性、平臺性部分，建立統一標準和接口。營造出標準統一，各家針對實現做競爭的市場局面。行業聯盟或其他合作形式：推動形成行業聯盟或其他組織，進行資源整合和優化配置，避免資源擠占，影響技術

317、創新。分層解耦，垂直分工：術業有專攻，聚焦每一領域的技術點，單點突破，提升整體研發效率和技術水平。堅持科學發展觀：汽車產業作為最復雜最綜合的載體，如何發展，路在何方，需要尊重客觀發展規律，有耐心，持續投入。希望通過開放的平臺，能夠聚勢、聚力，匯聚全行業力量，引導行業融合技術路線、推進標準共建，建立起破除內卷、協作發展、分層解耦的立體生態體系。中國汽車基礎軟件發展白皮書 5.0093七、AI大模型對整車軟件發展趨勢和技術路線的影響AI 大模型以其卓越的計算能力、深度學習能力以及廣泛的應用場景，正在重新定義整車軟件的架構和功能，加速整個行業向更智能、更高效和個性化方向邁進。本章節將探討 AI 大模

318、型對整車軟件發展趨勢和技術路線的諸多方面影響，探索 AI 大模型的更多可能。（一）發展趨勢1.算法、算料、算力與場景AI 大模型的訓練和升級，算法、算料（數據）、算力和場景缺一不可。在探索 AI 大模型對整車軟件發展趨勢和技術路線影響之前，先考慮 AI 大模型本身的發展對資源的需求：算法模型對計算、存儲需求增加：大模型可以作為模塊化端到端中的一個模塊發揮作用。大模型也可以與模塊化端到端算法配合，例如理想與清華共同提出的“快慢系統”架構（如圖 7.1-1 所示），或者小鵬汽車的XNet+XPlanner+Xbrain架構。在車端側部署的模型通常經過輕量化處理，但基于功能性、準確性、安全性的考量，

319、模型參數規模仍然達到幾十億以上。對于端到端駕駛任務，為了避免累積誤差和信息丟失，模型模塊之間或者模型之間以多維特征空間中的多維數組或矩陣傳遞。這一種數據量更大且連續的數據形式，對數據的存儲和傳輸效率（如零拷貝方式）要求很高。雖然感知、規控等算法業務內部傳輸的數據形式幾經優化，但域之間、智能體之間、智能體內插件或工具庫之間仍不乏人為數據的發布訂閱，所需內存達到十幾 GB，甚至幾十 GB。如果采用多智能體的架構，對系統資源分配會有更高要求。圖7.1-1 理想與清華提出的“快慢系統”架構芯片和工具鏈設計需支持算法快速迭代：當前的端到端算法和大模型大多基于 Transformer（一種廣泛應用于自然語

320、言處理中的深度學習模型）架構，相比過去卷積網絡中以 4D 為主的比較小的張量，大模型結構中張量的維度更加多變，維度操作更加復雜，張量顯著變大。為應對這個問題，需要芯片的多級緩存、帶寬，AI 編譯器中的前端優化、后端優化同時 runtime 庫的設計思路也要有所調整。另一方面，大模型的中國汽車基礎軟件發展白皮書 5.0094部署中使用到了諸如 KVCache、線程管理、draft 技術等技巧，一些通用的算法技巧會被集成到模型部署的 runtime 庫或部署框架中?，F在各廠商團隊的方案大多仍是大模型使用一套部署框架，其他模型使用過去通行的部署框架，然后通過某種通信機制協同工作。對于 AI 芯片廠商

321、來說，想要自己的芯片參與大模型的異構計算，要么兼容現有的框架，要么提供面向大模型的新的部署框架，因此還會有更多與算法相關的資源調度管理方法出現。豐富的信息輸入與交互：早期自動駕駛領域的 AI 模型輸入的數據主要是圖像數據、激光雷達數據、毫米波雷達數據，此外 GNSS（全球導航衛星系統）、IMU（慣性測量單元）、高精地圖、車身狀態等數據則主要是在基于規則的算法中被用到。如圖 7.1-2 豐富的信息輸入與交互所示，現在自動駕駛算法中要求IMU、車身狀態等數據經過預處理輸入模型參與融合計算。當大模型應用到自動駕駛任務之后，模型數據來源可能會來自于智駕域、座艙域、互聯網，語音、文字、圖像數據、外部知識

322、庫以及長期記憶都會成為模型輸入，可以預見汽車電氣電子架構從域控制器，到域融合，到中央計算，最后到車云協同的發展趨勢。圖7.1-2 豐富的信息輸入與交互數據處理管道構建：AI 大模型訓練依賴于數據質量、多樣性和完整性，有效地構建和管理數據集，準確反映實際應用場景中的復雜性和多樣性。在自動駕駛領域有來自攝像頭、激光雷達、毫米波雷達以及GPS（全球定位系統）等多種傳感器數據，高效的數據處理管道通常包括數據收集、整合、同步、預處理、特征提取、標簽化和版本控制等。AI 大模型訓練和推理根據需求動態調整計算資源，需要高效的資源管理和調度策略。容器化技術和容器編排工具支持模型訓練的自動化和規?；?。模型迭代管

323、理與優化：模型迭代需要跟蹤和管理不同版本的模型，便于模型的更新和回滾。分布式訓練、模型壓縮、模型量化等技術能夠提高訓練效率，減少模型的計算負擔，使得 AI 模型能夠更快地部署到生產環境中。通過模型剪枝和量化技術，可以顯著減小模型大小，降低推理階段的計算成本，這對于車端設備上的實時推理尤其重要。邊緣計算與云端大數據層協同：邊緣計算通過在網絡的邊緣位置部署計算資源，能夠更快地響應本地數據，減少數據傳輸至云端的延遲和帶寬消耗。在自動駕駛等場景中，大量的數據處理能夠在車輛本地完成，車載計算機可以即時處理來自攝像頭、雷達和激光雷達等傳感器的數據，進行實時的環境感知中國汽車基礎軟件發展白皮書 5.0095

324、和決策制定。云端擁有更強大的計算能力和存儲容量，可以處理來自全球各地的海量數據，以及模型訓練和優化任務。這種邊緣計算與云端大數據層的協同工作模式，不僅能夠提高系統的響應速度和可靠性，還能更好地保護用戶隱私。2.整車軟件開發方法的變革數據驅動而非規則驅動：傳統軟件開發方法論往往依賴于明確的規則和邏輯，開發者需要預先編寫詳細的程序指令來指導軟件的行為。在 AI 大模型的背景下，軟件開發的方式從規則驅動轉向數據驅動。數據驅動的方法適用于整個軟件開發生命周期，包括需求分析、設計、測試和部署等階段。過去基于規則的自動駕駛算法通過人工設置的條件判斷和參數，控制車輛在特定場景下的特定行動，但是道路場景是千變

325、萬化的，通過人工預設難以窮盡所有場景。在數據驅動的開發模式下，AI 通過對海量數據的學習來優化模型參數，而不依賴于預設的硬編碼規則，靈活性和適應性更高，能更快地響應場景變化。在自動駕駛領域通過收集大量的駕駛數據來訓練大模型，由于大模型的規模和復雜性，需要充分挖掘硬件性能，優化算法邏輯和部署策略。仿真測試效率與覆蓋度提升：仿真測試是確保軟件質量和可靠性的關鍵手段?；?AI 的仿真環境通過大量的實車數據訓練，相比傳統仿真方法，能夠利用機器學習算法（如深度學習）自動學習復雜系統的動態行為，無需顯式編程就能模擬現實世界場景；能夠根據輸入數據和系統狀態的變化自動調整模型參數，無需重新建模；可以處理更多

326、維度的數據和更復雜的非線性關系，能夠捕捉到細微模式；利用高性能計算平臺和優化算法，能夠實現即時或接近實時的仿真及反饋；可以通過添加更多的訓練數據和微調模型來適應新的場景，更容易擴展和維護?；?AI 的仿真環境能在汽車基礎軟件開發的早期階段就發現潛在的問題，提供詳細的錯誤報告，高精度定位錯誤，積累與優化測試策略方法，給出改進建議，主動式反饋機制加速修復流程，預防潛在的缺陷。AI 仿真環境以其優異的智能化水平、自適應能力、復雜度處理能力、實時性、可擴展性，敏捷且無限數量的生成真實或高度接近真實場景，覆蓋極端或罕見的邊界條件，降低測試成本，使系統的評估變得更加高效和全面。人類、AI 與三方工具緊密

327、協作：如圖 7.1-3人類、AI 與三方工具的協作所示，人類工程師收集挖掘汽車基礎軟件原始需求信息，而 AI 通過智能分析來輔助需求的細化和理解。標準代碼庫通常包含大量的功能和模塊，有些功能并非全部適用于項目，通過 AI 對代碼庫進行智能分析，識別項目所需的特定功能和模塊，按需自動生成 ARXML 文件或腳本，精簡代碼。自動調整配置文件能提高代碼的可讀性和可維護性，減少不必要的依賴，降低復雜度與出現兼容性問題的風險。生成的ARXML文件被導入到第三方工具中，用于系統設計、代碼生成或測試用例的自動化、智能化生成，生成、執行測試用例，人類工程師參與設計、編碼、測試規則定義和輸出評審，確保軟件質量及

328、其穩定性。圖7.1-3 人類、AI與三方工具的協作中國汽車基礎軟件發展白皮書 5.0096基于大模型的仿真訓練：端到端的自動駕駛要求 4D 的標注數據，人工標注成本大，功效低?；诖竽Ｐ偷纳伤惴梢詾榉抡嬗柧毶纱罅勘普?cornercase（極端情況）。當配備影子模式的車輛在道路上行駛的時候，一旦自身算法的規劃控制與駕駛員的操作不一致，汽車會將當時的場景上報到云端，服務器中心通過多模態大模型分析上報的場景，生成類似場景，并執行仿真訓練，然后自動化測試反饋，最后更新算法模型。相較于人工修改代碼，或者重新采集標注數據，這種監督、上報、仿真的方式將大幅提升訓練效率。整車協作開發更加重要：以往，不

329、同域控制器和云端的開發是相互獨立的。大模型或多智能體應用于全駕駛流程，要求以整車的視角協調不同功能模塊的部署和協作。開發團隊首先需要清晰定義不同的軟件模塊的優先級，哪些對實時性要求高，哪些對確定性要求高，哪些是更加靈活隨機的。需要清楚大模型或智能體在規劃汽車行為的時候，車上所有模塊如何做好隔離和聯動。生成式軟件架構方法：相比傳統的軟件架構，生成式軟件架構不必從頂層到底層逐步分解，層層定義算法、邏輯、數據、輸入輸出詳細接口、交互流程、狀態機等，只需要給出系統和軟件需求，較為抽象的目標定義，AI 自動完成架構設計，自然保持設計與實現的一致性、需求到交付的一致性。通過模型訓練和新創新數據訓練，獲得最

330、優軟件架構，自帶繼承性和創新性。（二）技術路線1.基于大模型的新型軟件工藝如圖 7.2-1 基于 AI 的新型軟件研發體系所示，AI 驅動的軟件研發體系以數據為驅動，人機高度協同，對人、機、料、法、環、測全要素重構。在超腦加持下，團隊獲得上帝視角，按需賦能，變革項目組織體制；以開發智能化、過程智能化、測試智能化，AI 數字員工和人類工程師主動智能協同，組裝超級智能體，協作完成復雜任務；將垂直領域的技術、標準、產品、組件、代碼以及實踐構建為知識圖譜，將軟件實體以原子組件的積木化、流水線組合，快速開發軟件產品；AI 接管重復性的工程活動、管理活動和品控活動，讓人類工程師專注于更高層次的設計和創新；

331、搭建個性化、最佳、最適動態開發環境與數字車模擬環境，縮短開發周期；全面 AI 感知與反饋閉環有助于及時發現潛在的風險與優化資源分配，提高交付質量。圖7.2-1 基于AI的新型軟件研發體系中國汽車基礎軟件發展白皮書 5.00971.1 人：項目組織體制的深度變革在超腦的感知、理解、推理、計算、度量、預測與預警能力的加持下，團隊獲得上帝視角，按需為各層級、專業、系統、崗位賦能。如圖 7.2-2 基于 AI 的新型軟件開發組織所示，新型軟件開發組織相比傳統軟件開發金字塔組織結構，給項目管理體制帶來重大變革：在新型軟件開發組織中，AI 將協作頂層企劃團隊產品方案制定、技術質量規劃、項目管理策略制定；為

332、中層平臺團隊在平臺設計、平臺構建提供助手，助力中高級工程師，拓展能力邊界，提高有效產出；以自動化工具與工作流方法，大量取代初級工程師，可靠高效地完成軟件開發任務。自頂向下的信息傳遞和自下而上的執行反饋形成閉環，更高效的任務分發與均衡調度、任務執行與績效反饋，確保開發過程的透明性和可控性。圖7.2-2 基于AI的新型軟件開發組織1.2 機：智能體深度參與軟件工程智能體是一種能夠自主地觀察環境、自我決策并自主地執行特定任務的軟件實體。如圖 7.2-3 智能體深度參與軟件工程所示，智能體如同員工與其他智能體或人類工程師進行交互和協作。精心設計的智能體能夠執行復雜的、通常需要人類經驗和專業技能的任務，

333、同時保持高度的準確性和效率。開發智能體（如代碼生成、代碼審查、代碼重構）、測試智能體（如測試用例、組件測試、自動化測試）、過程智能體（如QCD 監控、需求管理、風險管理）等作為 AI 數字員工，深度參與軟件工程，與人類工程師協同工作，提高軟件開發的效率和質量。智能體通過自學習、自適應、交互協作，完成從場景到交付，從創意到實現，從目標到解決方案的復雜任務。人類工程師可以專注于更復雜和創新的任務。圖7.2-3智能體深度參與軟件工程中國汽車基礎軟件發展白皮書 5.00981.3 料：知識庫與組件化改進編程能力用大模型技術整合技術、標準、產品、組件、代碼以及最佳實踐等元素，將編程語言、中間件、API 接口、微服務、框架、功能代碼、設計模式、解決方案、經驗總結等提取知識庫、知識圖譜，高效地管理和利用現有的技術和資源?；陧椖颗c產品實踐，使用知識萃取技術，將汽車電子基礎軟件的設計、代碼和用例提取為模塊