中國汽車基礎軟件(三)研究范圍 1.車端平臺 3.設備端平臺 3.整車仿真 1.領(lǐng)域知識庫 3.實現(xiàn)技術(shù) 1.開發(fā)方法論綜述 Ⅱ六國產(chǎn)整車軟件開發(fā)平臺問題與展望 1.國產(chǎn)基礎軟件裝車量待提高 3.生成式人工智能(AIGC)在整車次件開發(fā) 一、整車軟件開發(fā)平臺概述近年來，汽車電子電氣架構(gòu)走向集中化，跨域融合作為其核心內(nèi)涵之一，意在將多域功能開發(fā)掛載至集中統(tǒng)一平臺，大幅提升整車軟件的開發(fā)效率與協(xié)同性?，F(xiàn)加速體系化創(chuàng)新，在此趨勢下，2022年發(fā)布的白皮書3.0,即聚焦通用基礎軟件平臺架構(gòu)和技術(shù)，在參考2019版汽標委《車用操作系統(tǒng)標準體系》的基礎上，從安全車控、智能駕駛和車載信息娛樂三個方面開展了系統(tǒng)闡述，以構(gòu)建安全、可靠、穩(wěn)定的基礎軟件底座，助力打造整車軟件開發(fā)平臺，實現(xiàn)高階軟件定義汽車。本次發(fā)布的白皮書4.0,將基礎軟件開發(fā)理論和經(jīng)驗延伸至整車軟件元發(fā)平臺，將服務對象由車端擴展至云端、loT(IntemetofThings,物聯(lián)網(wǎng))端，同時吸收ICT(inormatisandCommunicationsTechnology,信息與通信技術(shù))領(lǐng)域先進理念，結(jié)合AlGC(AntificiateeneGeneratedContent,生成式人工智能)等先進技術(shù)，圍繞SOA(ServiceOrientoArc面向服務的架構(gòu))、云原生、仿真、知識庫等，探討整車軟件開發(fā)平臺的關(guān)鍵技術(shù)、實政案例與發(fā)展書勢，旨在為整車軟件平臺產(chǎn)業(yè)鏈參與者提供有益的指導和參考。第一章整車軟件開發(fā)平臺概述：介紹了目皮書的研究營景和國內(nèi)外整車軟件開發(fā)平臺的發(fā)展現(xiàn)狀，同時對整車軟件開發(fā)平臺進行定義和概述。第三章整車軟件開發(fā)平臺的應用介紹》開發(fā)方法論，以及包含車控、智駕、座艙在內(nèi)的整車軟件開發(fā)平臺的典型應用。第四章整車軟件開發(fā)山發(fā)展：以平臺化、標準化、開放化、知識化等維度為切入點，研究了整車軟件開發(fā)平臺的發(fā)展趨勢。第五章國產(chǎn)整車軟件開發(fā)平臺生態(tài)介紹：以生態(tài)圖譜的形式描述了國產(chǎn)整車軟件開發(fā)平臺生態(tài)的發(fā)第六章國產(chǎn)整車軟件開發(fā)平臺問題與展望：一方面對整車軟件開發(fā)平臺當前存在的問題以及未來發(fā)展提出建議，另一方面結(jié)合AIGC技術(shù)對國產(chǎn)整車軟件開發(fā)平臺的未來發(fā)展進行展望。1.整車軟件開發(fā)平臺現(xiàn)狀構(gòu)建整車軟件開發(fā)平臺目的在于實現(xiàn)高效地開發(fā)、部署和更新軟件。目前，各家的整車軟件開發(fā)平臺正處于快速發(fā)展階段，呈現(xiàn)的主要特征為：集成化、平臺化、虛擬化及云端化，根據(jù)整車軟件應用場景，將各域發(fā)展現(xiàn)狀總結(jié)如下：1.1車控域軟件相對成熟車控域(包含：動力域、底盤域、車身域等)軟件功能可實現(xiàn)網(wǎng)關(guān)信號路由轉(zhuǎn)發(fā)、面向服務通信以及對動力、底盤、車身等各模塊的控制。車控域基礎軟件是應用軟件與硬件交互的橋梁和通道，設計理念充分 借鑒了模塊化、平臺化思想。此外，由于整車域基礎軟件覆蓋控制器種類多樣，驅(qū)動復雜，故基礎軟件編程語言必須采用C語言或匯編語言等實現(xiàn)通訊，常用軟件平臺包括AUTOSARCP、Scheduler、OSEK/1.2智駕域軟件發(fā)展迅速輔助駕駛技術(shù)和功能已經(jīng)日趨成熟，新車搭載率超過50%,智駕體驗與場景覆蓋度成為眾多消費者購車考慮的核心要素。L3/L4高級別自動駕駛技術(shù)尚處于測試、示范階段，規(guī)模化應用尚需時日。智駕軟芯片算力要求較高，軟件迭代速度快，通常采用AUTOSAR方法論并基于AUTOSARAP平臺開發(fā)。1.3座艙域軟件生態(tài)豐富智能座艙領(lǐng)域是主機廠研發(fā)布局的焦點，是整車智能化、差異化競爭力的核心體現(xiàn)，主要包括：HUD(HeadUpDisplay,抬頭顯示)、儀表盤和車載娛樂信息系統(tǒng)三部分組成。智能座艙領(lǐng)域的發(fā)展主要圍繞人的體驗和需求展開，座艙域軟件設計主要涉及到對傳統(tǒng)功能的整合，人機交互方式的提升，其它數(shù)字化衍生服務等。智能座艙軟件通過對艙內(nèi)和交互數(shù)據(jù)采集，并上傳到去端進行處理和計算，從而對資源進行最有效地適配，以增加座艙內(nèi)的安全性、娛樂性和實用性。座能對實的性要求相對較低，但在動態(tài)部署等方面需要較高自由度，目前大多基于AUTOSARAE中開發(fā)。2.整車軟件開發(fā)平臺問題現(xiàn)階段，我國整車軟件研發(fā)以及SOA架構(gòu)的應用均處于起步階身，整車軟件開發(fā)存在開發(fā)流程落后、2.1開發(fā)流程難以匹配技術(shù)革新速度由于汽車行業(yè)的數(shù)字化、網(wǎng)聯(lián)化和智貨化發(fā)展的物，車軟件也在不斷演化，現(xiàn)有AUTOSAR等標準仍然存在許多功能需求無法滿足的情反、如特定領(lǐng)域需求、高性能需求、人工智能等新興技術(shù)關(guān)聯(lián)需求一級零部件供應商、二級零部例供應商等不同的并發(fā)團隊采用不同的流程、方法和標準，導致軟件兼容性2.2工具鏈復雜、兼容性欠整車軟件開發(fā)所使用的工具鏈需要涵蓋多種功能模塊、跨越多個開發(fā)層次、適應多類供應商平臺，并且還需要兼顧安全性、平臺性和規(guī)范性要求。從驅(qū)動軟件、系統(tǒng)軟件、功能軟件，再到上層應用軟件和用戶界面，都需要工具鏈支持。但是不同供應商、不同軟硬件平臺所對應的工具鏈差異顯著，造成開發(fā)通用2.3安全標準規(guī)范體系不完善整車軟件開發(fā)過程中，標準規(guī)范多數(shù)遵從國外體系，其中信息安全、功能安全標準尤為突出，自主制定的標準體系相對匱乏。整車軟件標準體系發(fā)展節(jié)奏與汽車智能化發(fā)展速度失衡。推行自主軟件標準化體系建設，減少軟件之間兼容性差，提高軟件安全性和穩(wěn)定性，促進汽車自主軟件產(chǎn)業(yè)鏈協(xié)同發(fā)展已成軟件定義汽車，已成為行業(yè)共識。主機廠正朝著軟件公司方向轉(zhuǎn)型，國內(nèi)外多家主機廠正在著力打造其專屬整車軟件開發(fā)平臺。一汽于2021年制定了“十四五”戰(zhàn)略規(guī)劃，面向社會發(fā)布“飛刃計劃”,打造完全自主可控的全棧向上為應用軟件提供豐富且標準的服務，以支撐軟件靈活迭代，為用戶提供千人千面的用戶體驗。FAW.通A框架FAW.OS在平臺設計方面最大化保障兼容性與動展性。在硬件層面上，通過虛擬化組件層、操作系統(tǒng)接口抽象層、統(tǒng)一的Al框架隔離硬件平臺差異建立適記層向下兼容多種軟硬件平臺，避免“芯片卡脖子”問題，而且還預留了足夠算力，以輕公遠行更多更好用的APP。在軟件層面上，通過統(tǒng)一的SOA服務層服務2。.上汽云管端一體化氧件平臺如圖1.2-2所示，上汽電團法研發(fā)的“零束云管端一體化SOA軟件平臺”全力打造核心技術(shù)基礎平臺產(chǎn)品，打破了傳統(tǒng)汽車軟領(lǐng)件強耦合及“孤島式”開發(fā)，實現(xiàn)智能車“車云一體、跨域融合”的硬件數(shù)字化和軟件服務化開發(fā)，探索出硬件“可插、可拔、可擴展”、軟件“可買、可賣、可訂閱”全新商業(yè)模式，同時引入開發(fā)者和loT生態(tài)，助力智能汽車行業(yè)創(chuàng)新發(fā)展及應用生態(tài)建設。圖1.2-2上汽云管端一體化軟件平臺 這一軟件平臺已在智己汽車、飛凡汽車的多款量產(chǎn)車型中落地。3.大眾vW.oS大眾操作系統(tǒng)VW.OS是CARIAD(大眾汽車旗下軟件子公司)技術(shù)棧中所有基于軟件的功能的核心。VW.OS通過結(jié)合各合作伙伴提供的解決方案，形成一個可擴展和統(tǒng)一的軟件平臺。VW.OS的架構(gòu)如圖1.2-3所示。圖1.2-3VW.0S系統(tǒng)架構(gòu)VW.OS由SDK(SoftwarebwelopmentKit,軟件開發(fā)工具包)、參考應用程序、運行時軟件組件、嵌入式軟件以及云化工具鏈組成。VW.OS通過與VWAC(大眾汽車云)、大循環(huán)數(shù)據(jù)聚合系統(tǒng)(BigLoop)聯(lián)合工作，形成整車軟件開發(fā)平臺。VW.AC是大眾云服務，負責車輛數(shù)據(jù)向云上遷移。大循環(huán)數(shù)據(jù)聚合系統(tǒng)是一種持續(xù)收集數(shù)據(jù)并驅(qū)動軟件功能進行改進的方法。VW.OS的特點如下：●一致的開發(fā)平臺VW.OS為開發(fā)人員提供面向車輛所有域的一致的開發(fā)環(huán)境?！翊笱h(huán)數(shù)據(jù)聚合系統(tǒng)和增強定期的OTA(Over-the-Air,遠程升級)通過大循環(huán)數(shù)據(jù)聚合系統(tǒng)，不斷持續(xù)收集數(shù)據(jù)，并驅(qū)動軟件功能改進，通過OTA,使用戶能夠在整個車輛使用周期內(nèi)從新的創(chuàng)新功能中受益?！窨缙放频能浖A通過解耦的分層架構(gòu)、面向服務的設計方法，實現(xiàn)更簡化、高效和可擴展的軟件開發(fā)。AreneOS是豐田推出的整車軟件開發(fā)平臺，由工具、整車平臺和數(shù)據(jù)中心這三部分組成。作為一種結(jié)合了構(gòu)建工具和車載軟件服務的綜合平臺，AreneAreneOS的構(gòu)成與功能如圖1.2-4所示。OS目的在于實現(xiàn)整車軟件的快速開發(fā)與部署。軟件平臺十社會系統(tǒng)與車一投供后高人與車AreneOS的特點如下：●標準化的開發(fā)平臺AreneOS為豐田和供應商提供共同中合和標準化流程。通過Arene,豐田和供應商能夠確保跨流程可見性，并簡化集成和測試過程?！褡詣踊?、虛擬化測試AreneOS擴展并加這了軟件測過。rene部署了全流程的自動化測試。同時通過仿真技術(shù)，使物理測試與虛擬測試相結(jié)合，加入針對也件功能的離散獨立分析，確保研發(fā)質(zhì)量?！駭?shù)據(jù)、OTA和迭代開發(fā)工具通過整車數(shù)據(jù)、車輛數(shù)據(jù)分析，持續(xù)獲得需求，并通過迭代的開發(fā)方式和OTA,形成數(shù)據(jù)閉環(huán)，持續(xù)改善品質(zhì)與功能，從而延長了車輛的價值?！裾囓浖_發(fā)平臺AreneOS整合了車輛的各個域，使汽車制造商能夠提供更豐富、更全面的用戶體驗。車載計算資源可以在系統(tǒng)之間共享，使車輛能夠以更少的資源實現(xiàn)更多功能?！駪贸绦虻目梢浦残院涂芍貜褪褂眯訟reneOS旨在最大化軟件的價值。通過標準化接口、解耦的軟件分層和先進的測試協(xié)議，AreneOS開發(fā)的程序不僅在不同平臺之間具有可移植性，而且在同一系列不同年代的車輛之間也具有可重復使用性，從而獲得更大的投資回報率?？傮w而言，整車軟件平臺在全球范圍內(nèi)都得到了廣泛關(guān)注和發(fā)展。不同國家和地區(qū)的汽車廠商紛紛加強整車軟件研發(fā)和創(chuàng)新，以應對日益增長的網(wǎng)聯(lián)化和智能化需求。 (三)研究范圍整車軟件開發(fā)平臺的架構(gòu)如圖1.3-1所示。露端中心測過試.工真鏈(開發(fā)·仿真，調(diào)測過試.等)標準車端平臺云端平臺AIOT端平臺整體結(jié)構(gòu)可以分為軟件平臺、數(shù)據(jù)中心、工具鏈以及開發(fā)相線的材準現(xiàn)危，真中軟件平臺根據(jù)部署的終端不同，可以進一步劃分為車端平臺、云端平臺和設備端平臺。在整車軟件開發(fā)平臺的組成中，有兩個重要的框架，為別為中國軟件評測中心發(fā)布的車載智能計算基礎平臺參考架構(gòu)2.0和中國基礎軟件生態(tài)標委會機手行業(yè)內(nèi)生流車企和零部件企業(yè)提出的整車服務框架ASFAUTOSEMOServiceFramework車penhe圖1.3-2車載智能計算基礎平臺與ASF框架如圖1.3-2所示，整車軟件開發(fā)平臺融合了車載智能計算基礎平臺參考架構(gòu)2.0和ASF框架。車載智能計算基礎平臺為應用軟件提供感知、決策、規(guī)劃、控制及Al端到端大模型等模型庫，以及網(wǎng)聯(lián)云控、信息安全、數(shù)據(jù)安全、車端LLM(LargeLanguageModel,大規(guī)模語言模型)等基礎服務，支撐安全、實時、可擴展的多等級自動駕駛、駕艙融合、車路云一體化等應用。在面向高實時、高性能要求的自動駕駛域控上，融合車載智能計算基礎平臺的自動駕駛操作系統(tǒng)，共同打造整車軟件開發(fā)平臺。ASF框架是面向域控制器打造的SOA框架下的中間件，基于標準基礎軟件向上擴展，解決域控制器異構(gòu)芯片跨核融合問題，實現(xiàn)域控制器的統(tǒng)一開發(fā)視圖。ASF框架是開放的分布式服務框架，通過ASF規(guī)范統(tǒng)一服務和接口定義，梳理服務開發(fā)環(huán)境與運行環(huán)境，用于打造高效、集成便捷的整車軟件開發(fā)平臺。白皮書4.0著重研究車端平臺相關(guān)的開發(fā)技術(shù)，云端平臺和設備端平臺僅在本章節(jié)進行簡要介紹。1.車端平臺車端平臺用于智能車控，智能駕駛，智能座艙等車端軟件開發(fā)。智能車控：包括動力系統(tǒng)、底盤系統(tǒng)、車身系統(tǒng)、電池管理系統(tǒng)、網(wǎng)聯(lián)控車系統(tǒng)等，其特點體現(xiàn)為高安全、低算力、強實時(微秒級)、與車輛安全行駛強相關(guān)。當前AUTOSARCP的標準化在車控基礎軟件上取得了巨大成效，從主機廠到一級零部件供應商、工具鏈廠商都遵循這一標準開發(fā)產(chǎn)品。智能駕駛：其特點體現(xiàn)為高安全、高算力、實時性(毫秒級，確定時間范圍內(nèi))、與車輛行駛安全強相關(guān)。當前未形成統(tǒng)一的技術(shù)路線(ROS/Linux/AUTOSARAP),不過AUTOSARAP已作為其中較為成熟的一項技術(shù)初步顯現(xiàn)技術(shù)價值，其中關(guān)鍵技術(shù)是軟件算法與模型。智能座艙：其特點體現(xiàn)為中安全、高算力、中實時(毫秒級)、行駛安全弱相關(guān)，但有強人機交互需求。主要包括中控大屏、數(shù)字儀表、流媒體后視鏡、HUD、標車記儀等。當前未形成統(tǒng)一的技術(shù)路線(Android/AGL/AUTOSARAP),可預見的未來仍然會多路并行。2.云端平臺云端平臺用于云端軟件開發(fā)。例如，通過平臺服務可以精地自定義到某終端，設置采集頻率和上報頻率，將車輛CAN(ControllerAreaNetyors電行通信辦議)數(shù)據(jù)中的每個參數(shù)通過壓縮等方式傳輸?shù)骄W(wǎng)關(guān)服務，由該服務同一入口來動態(tài)地匹已解析有AN數(shù)據(jù)協(xié)議的內(nèi)容。之后，可將數(shù)據(jù)再轉(zhuǎn)化為業(yè)務數(shù)據(jù)，提供業(yè)務能力支撐，如使查詢、跡分析、車輛診斷等，以供各業(yè)務方使用。3.設備端平臺設備端平臺主要指廣泛的oT設備及相關(guān)的生態(tài)應用。AloT=Al(人工智能)+loT,是一種新的loT應用形態(tài)，是人工智能技術(shù)與勿聯(lián)網(wǎng)在實際應用中的落地融合。AloT的目標是實現(xiàn)主動智能服務，即智能系統(tǒng)根據(jù)用戶行為偏好、戶畫像、環(huán)境等各類信息隨時待命，具有自學習、自適應、自提高能力，可主動提供適用于用戶的服務、而無需等待用戶提出需求。從技術(shù)角度來講，利用Al/ML技術(shù)驅(qū)動的智能視覺、智能音頻、智能語音以及融合感知應用是人工智能物聯(lián)網(wǎng)落地的先發(fā)業(yè)務。其中汽車是AloT的一種重要終端觸點，同時AloT智慧交通)結(jié)合，與出行和生活場景深度融合，創(chuàng)造更多的應用價值。4.數(shù)據(jù)中心數(shù)據(jù)中心主要指整車數(shù)據(jù)中心，用于數(shù)據(jù)存儲與分析。眾所周知，數(shù)據(jù)中心也經(jīng)從最早期的單臺服務器運行單一應用程序，到服務器虛擬化，將一臺高性能服務器虛擬成多個虛擬機來運行不同的應用。目前數(shù)據(jù)中心正處于第三個時代，即基于可組合的基礎架構(gòu)、微服務和特定域處理器，通過使用分解和編程控制等概念，使用軟件定義的技術(shù)，以在數(shù)據(jù)中心內(nèi)匯集計算、存儲和網(wǎng)絡結(jié)構(gòu)等資源?；谠撛O計，不同的處理器可根據(jù)最優(yōu)方案加速不同的工作負載；可以將計算、內(nèi)存和其它資源分成多個池，并以適當?shù)臄?shù)量動態(tài)地分配給服務器和應用程序。5.工具鏈整車軟件開發(fā)所需要的工具鏈，覆蓋設計到驗證階段，是整車軟件開發(fā)平臺的重要組成部分，在車L端平臺上，目前主要應用的工具鏈可以分為如下幾類：●設計工具。類似于Simulink的圖形化編程工具，可以用于功能建模、仿真和驗證。●編譯器和集成開發(fā)環(huán)境。即針對特定嵌入式處理器的編譯器和開發(fā)環(huán)境，如ARMKeil、IAREm-beddedWorkbench等，可以用于開發(fā)底層的驅(qū)動程序和基礎軟件?！衲M和仿真工具。通過該工具，使開發(fā)人員能夠在虛擬環(huán)境中測試軟件并驗證功能和性能，從而減少對實際環(huán)境的依賴?！耖_發(fā)流程管理工具。即版本管理系統(tǒng)、協(xié)作工具、自動化測試和持續(xù)集成工具等，使開發(fā)團隊能夠更好地合作，以保證軟件開發(fā)的效率和質(zhì)量?！裾{(diào)試和測試工具。調(diào)試工具如LauterbachTrace32等，用于調(diào)試嵌入式代碼。測試工具如Vec-torCAST、LDRA等，用于代碼靜態(tài)分析和動態(tài)測試。工具鏈在演進上借鑒了ICT領(lǐng)域的經(jīng)驗，將互聯(lián)網(wǎng)在云端開發(fā)的框架引入車端。工具鏈呈現(xiàn)的特點為，吸收云原生的概念，形成跨域工具鏈、云化工具鏈、車規(guī)級容器以及打造DevOps開發(fā)體系，大幅提高開發(fā)效率和生態(tài)建設能力。6.標準規(guī)范汽車軟件開發(fā)標準旨在規(guī)范汽車軟件的開發(fā)流程、技術(shù)要求個質(zhì)量管理、測試驗證和文檔編制等，以提高汽車軟件的質(zhì)量和效率，確保汽車的安全性和可靠性《當前已有的精準舉例如下：●AUTOSAR:汽車開放系統(tǒng)架構(gòu)。它是一套用于汽車響子系統(tǒng)的開放式標準，旨在提供一致的軟件體系架構(gòu)。它定義了軟件的架構(gòu)和接口，促進了不同EC之間的軟件復用?！馡SO26262:道路車輛功能安全國際標準。內(nèi)容主要潤蓋汽車系統(tǒng)、軟件、硬件等方面的安全完整性，強調(diào)在汽車產(chǎn)品的開發(fā)過程中如他避免、預防、探測、降低或消除風險。ISO26262標準提出了ASIL(即汽車安全完整性等級分為B、C、D四個級別，其中D為最高級)的概念，它會影響到產(chǎn)品開發(fā)階段中各種技術(shù)手段的推薦程度。●MISRAC:汽車工業(yè)軟件可靠性協(xié)會MISRA,MotorIndustrySoftwareReliabilityAssocia-tion)制定的一套鈾對C語言的編碼準則，旨在提高C語言代碼的質(zhì)量和安全性，有助于減少代碼缺陷并提高代碼可靠二、整車軟件開發(fā)平臺的核心技術(shù)本章節(jié)詳細介紹整車軟件開發(fā)平臺中運用的SOA、云原生、仿真以及知通過開發(fā)協(xié)同方式、運用的核心技術(shù)這兩個維度的差異，我們將技術(shù)形態(tài)分為經(jīng)典技術(shù)形態(tài)和創(chuàng)新技術(shù)形態(tài)。本節(jié)將對經(jīng)典和創(chuàng)新這兩種技術(shù)形態(tài)分別進行概述。1.經(jīng)典技術(shù)形態(tài)1.1開發(fā)方式多為單點開發(fā)當前電子電氣架構(gòu)正處于分布式向中央集中、區(qū)域控制轉(zhuǎn)化的過程所以高然存在不少單點開發(fā)的情況。究其原因，總結(jié)為如下兩點：●分布式電子電氣架構(gòu)：各個控制器之間數(shù)據(jù)交互少且每制負責的功能簡單，所使用到的技術(shù)單一，所以可以采用單點開發(fā)模式?！癜踩头€(wěn)定性要求高：汽車是一種復雜的機械皮備，安全和穩(wěn)定性對于汽車電子系統(tǒng)來說至關(guān)重要。通過單點開發(fā)模式，汽車制造商可以更好地率心隨著電子電氣架構(gòu)演化速度加快，從業(yè)考已意到需要更快速、更具創(chuàng)新性的開發(fā)方式來滿足不斷變化的市場需求。因此，多團隊協(xié)同開發(fā)度式正可新成》主流，以便更好地提升開發(fā)效率和創(chuàng)新能力，加速產(chǎn)品上市。1.2當前主流開發(fā)技術(shù)當前主流開發(fā)技術(shù)見表2.12.1-1當前主流開發(fā)技術(shù)sign,基于模型設計)·MATLAB/Simulink:建立車身控制系統(tǒng)模型，進行仿真和測試。MATLAB/Simulink模型與AUTOSAR的結(jié)合：通過AUTOSAR字典的配置、創(chuàng)建AUTOSAR模型、添加AUTOSAR配置、生成符合AUTOSAR標準的SWC,實現(xiàn)Simulink模型與AUTOSAR標準的結(jié)合，為車身控制系統(tǒng)提供符合AUTOSAR標準的軟件組件；套完整的開發(fā)工具鏈。靜態(tài)代碼檢查工具為Polyspace。多采用實時操作系統(tǒng)，主要有FreeRTOS,IN-TEGRITYRTOS,AU-TOSAROS等·基于ClassicPlatformAUTOSAR標準的MCU端的OS監(jiān)控和優(yōu)化工具，如：gliwaT1和VectorTA-toolsuit。中間件●開發(fā)工具：Vector的DaVinci、EB的Tresos、ETAS的ISOLAR、達索的AUTOSARBuilder、東軟睿馳的NeuSAR、中汽創(chuàng)智CAIC·CP等；片專用的調(diào)試工具；·測量標定工具：ETAS的INCA、Vector的Canape等。智駕系統(tǒng)級芯片)操作系統(tǒng)主要是QNX或Linux·Linux:GCC編譯，GNU調(diào)試等。中間件·AUTOSARAP:Vector的AdaptiveMICROSARETAS的RTA-VRTAFEB的Coebos、TTTech的MotionWisoK工的SARAdaptive,Mentor的CapitalSTA3、普華基礎軟件的ORIENTAISAdap-tive、東軟馳的NeUSARDS、中汽創(chuàng)智的CAIC·-·以數(shù)據(jù)為中心的OMGDDS:RTI的ConnextDDSePro.ima的FASTDDS、GreenStrone的SWIFTOSAutoCore的AutoCore.OS軟件平臺等。掘等在內(nèi)的一體化數(shù)據(jù)閉環(huán)解決方案。從大類角度，可分為：數(shù)據(jù)可視化平臺、數(shù)據(jù)標注平臺(包括自動化標注)、數(shù)據(jù)管理平臺等?！鹘y(tǒng)仿真測試：HIL、SIL,國產(chǎn)代表昆易等；展進化出的以TESLA為代表的訓練數(shù)據(jù)/場景/多傳Constellation等。SoC操作系統(tǒng)主要是QNX或安卓·安卓：使用AndroidStudio作為主要開發(fā)工具，它提供了豐富的開發(fā)工具和調(diào)試功能，包括代碼編輯器、調(diào)試器、虛擬設備等。中間件多選用AdaptivePlat-GENIVI(GENMI提供一套基于Linux的座艙中間件，用于連接座艙內(nèi)的各個設備和應用程序)·選用AUTOSARAP的場合，工具鏈介紹同智駕部分·GENIVI:使用GENIVIDevPlatform(GDP)、GENIVIDevelopmentPlatform(GDP)等。2.創(chuàng)新技術(shù)形態(tài)2.1開發(fā)方式轉(zhuǎn)為協(xié)同開發(fā)當前智能網(wǎng)聯(lián)汽車的研發(fā)復雜度在不斷提高，總結(jié)有如下幾點：●用戶場景導向研發(fā)復雜度高。伴隨著智能網(wǎng)聯(lián)汽車在市場占有率的提升，用戶需求和體驗成為各家主機廠的研發(fā)導向，駕乘體驗將不再只是傳統(tǒng)的交通工具，如何抓住相戶的場景體驗，提供豐富的具象化人體感受，將使智能汽車應用場景和功能需求大展，用戶應用場景在整個研發(fā)過程都會經(jīng)過復雜的數(shù)據(jù)化和結(jié)構(gòu)化轉(zhuǎn)化?！裱邪l(fā)技術(shù)棧多維復雜度高。智能網(wǎng)聯(lián)汽車的研發(fā)技術(shù)棧只從傳統(tǒng)的電子電氣嵌入式方向，逐步擴展為云計算、5G通信、人工智能和新能源電池等多維方向。這代表著整個汽車供應鏈的參與方已不再只是傳統(tǒng)的零部件廠商，基礎設施廠商、臺商和軟件研發(fā)廠商都成為了供應鏈中的一環(huán)。供應鏈規(guī)模的擴大帶來的不僅是研發(fā)點術(shù)的復東度提升，也加重了管理和集成驗證的難度。智能化和網(wǎng)聯(lián)化發(fā)展的智能汽、在提供用應豐富的場景體驗的同時，也悄然帶來了行車安全、數(shù)據(jù)泄露、網(wǎng)絡攻擊等嚴重的安全問題。汽車作為車聯(lián)網(wǎng)基本載體是智慧城市發(fā)展的重要環(huán)節(jié)，相關(guān)法規(guī)和行業(yè)監(jiān)管的復系度也將不斷提高，來確保智能網(wǎng)聯(lián)汽車行業(yè)的良性安全發(fā)展?；谶@些特點，汽車整在軟件不發(fā)平臺無法通過封閉式管理和生態(tài)圈來解決這些問題。未來協(xié)同開發(fā)體系將會成為中國汽車整氣較開發(fā)平臺的演進方向。接下來，我們分別從SOA云原生技術(shù)、仿真技術(shù)和知識庫來介紹變革中的技術(shù)形態(tài)。2.2變革中的主流技術(shù)(1)面向服務架構(gòu)(SOA)SOA全稱為ServiceOrientedArchitecture,即面向服務的架構(gòu)，是1996年由Gartner提出，他對SOA概念的解釋為：“SOA是一種C/S(Client-Server,客戶端/服務器)架構(gòu)的軟件設計方法，應用由服務和服務使用者組成，SOA與大多數(shù)通用的C/S架構(gòu)模型不同之處在于它著重強調(diào)架構(gòu)構(gòu)建的松散耦合，并使用獨立的標準接口"。在分析SOA未來演變趨勢時，值得關(guān)注的是市場用戶的消費核心觀的變化，這很有可能直接決定了SOA的發(fā)展形態(tài)。隨著智能網(wǎng)聯(lián)汽車在市場占有率的攀升，消費者對于自動駕駛方面的駕乘的體驗與感知將會趨于熟悉，因此對該部分消費欲望會逐漸降低。取而代之的是，場景化智能化的融合消費體驗，如車內(nèi)娛樂、跨平臺社交等向車外衍生的電子消費能力。用戶消費觀的轉(zhuǎn)變將影響市場反應與產(chǎn)品發(fā)展導向，因此如何快速響應用戶市場需求，從需求側(cè)轉(zhuǎn)向產(chǎn)品側(cè)快速迭代，成為了各家企業(yè)的必爭之地。用戶不懂什么是SOA架構(gòu)，也不明白SOA的技術(shù)優(yōu)勢，他們只關(guān)注日益多元增長的駕乘體驗功能。這些 速迭代的底座。因此SOA架構(gòu)的未來演變趨勢也將建立在跨域融合為用戶展示消費價值較高的功能上。上層應用軟件與SOA基礎軟件平臺的關(guān)系如圖2.1-1所示。安全體系根據(jù)博世的定義，當前整車可分為五大能域，即動力總成域、底盤域、車身域、智能座艙域和自動駕駛域。當前主流主機廠的So構(gòu)規(guī)劃思路為通過實現(xiàn)部分域的融合，實現(xiàn)中央計算平臺+區(qū)域控制隨著汽車芯片的算力較傳統(tǒng)汽車工業(yè)模式已有了長足的進步，域控制器或中央計算平臺都是基于平臺的芯片算力甚至可達千TOPS。芯片的算力在基礎物理層面為SOA架構(gòu)的跨域融合，最終演化成融合整車全域提供了土壤。但是必須正視汽車芯片當前的集成算力現(xiàn)狀并不足以完全支撐中央集中式架構(gòu)，因此各主機廠只能通過電子電氣架構(gòu)來搭建SOA架構(gòu)。從長久的未來看，整車驅(qū)動的全域融合必須要有整車層面的基礎軟件平臺架構(gòu)來支撐。中央計算平臺的演進將最終帶動整車SOA跨域融合的能力。②演變趨勢二：零部件協(xié)議標準化轉(zhuǎn)化雖然主機廠提供的SOA架構(gòu)基礎軟件平臺具備軟硬件解耦能力，但是實際生產(chǎn)集成中各主機廠廠商的零部件往往都是非標準化的，操作系統(tǒng)并沒有自帶非標零部件的協(xié)議。這是由于傳統(tǒng)汽車工業(yè)所帶來的遺留問題，在零部件上存在大量定制化的設計，形成了大量非標零部件。因此需要SOA架構(gòu)的基礎軟件平臺來補充這些零部件的協(xié)議轉(zhuǎn)化，以此才能為上層應用軟件層提供可用的API。從技術(shù)上來說，這并不是一個嚴重的問題，因為提供標準化接口正是SOA架構(gòu)的優(yōu)勢。但從全局上看增加了整車集成驗證的時間成本，也無形中增加了上層應用軟件的代碼復雜度，鎖死了代碼復用的可能性，降低了端到端軟件開發(fā)效率。因此，SOA架構(gòu)的基礎軟件平臺在短期內(nèi)必須盡可能多地對非標零部件具備協(xié)議轉(zhuǎn)化能力。從長期看，整個行業(yè)應該從零部件層面推廣標準化生產(chǎn)，從而提升行業(yè)整體的研發(fā)效率，降低產(chǎn)品復雜度與時間成本。③演變趨勢三：真正實現(xiàn)繁榮的第三方研發(fā)生態(tài)圈如今各主機廠的SOA基礎軟件平臺雖然為獨立的第三方軟件開發(fā)商提供了入口，使得智能汽車軟件研發(fā)領(lǐng)域的進入上層應用軟件的入行門檻大大降低。但是對比同為智能終端的手機，各主機廠的第三方研發(fā)生態(tài)圈依然是相對封閉的，例如車載應用交互界面，我們可以看到主機廠提供了多種上層Androic應用軟件，但不同車型的應用界面可能略有不同。這其中有一部分原因是傳統(tǒng)汽車工業(yè)定制化零部件的弊端在延續(xù)，導致了上層應用軟件的第三方研發(fā)方缺乏后期集成驗證的指導，并加重了軟件適配非標零部件的研發(fā)成本，嚴重時會發(fā)生同一廠商不同型號的產(chǎn)品，交付的應用軟件是獨立的兩套產(chǎn)品。另一部分原因也在于行業(yè)整體缺乏應用商城的整體架構(gòu)規(guī)劃。主機廣雖然公開了部分SOA服務接口，但是缺乏上層應用軟件研發(fā)指南和對底層硬件支持的詳細說明，這客是情況在現(xiàn)階段對第三方研發(fā)者都是不友好的。因此未來SOA服務接口的第三方研發(fā)生態(tài)需要突高的行業(yè)組織來規(guī)劃推動：主導SOA服務接口標準化、第三方研發(fā)接入與集成指導、形成應用服務商店，以此能夠消解傳統(tǒng)汽車遺留的非標零部件的桎梏。對第三方研發(fā)者而言，可以將豐富的互聯(lián)網(wǎng)資題納入SDA研發(fā)生態(tài)中，針對不同用戶的應用場景開發(fā)多樣化的軟件，既可為用戶和汽車制造商創(chuàng)造價值，也能讓第三方研發(fā)者獲得收益，形成三方共贏的良性循環(huán)。(2)云原生云原生是一種構(gòu)建和運行軟件應用程序的現(xiàn)除方法，它利用了云計算的靈活性、可擴展性和彈性。云原生包括當今軟件開發(fā)人員用來為公共云構(gòu)建應用程序的各種工具和技術(shù)，而不是適合本地數(shù)據(jù)中心的傳統(tǒng)架構(gòu)。云原生計算基金會對云原生的定義為：專注于應用程序容器化——將應用程序分解為微服務并打包在輕量級容器中，以便在各他服務器上進行部署和編排。此定義直接點出了云原生相關(guān)的技術(shù)棧：云原生技術(shù)的發(fā)展具有互聯(lián)網(wǎng)行業(yè)技術(shù)棧快速更迭的屬性，任何一項里程碑的技術(shù)都可能會帶來革命性的行業(yè)生態(tài)變化。展望未來智能汽車行業(yè)的云原生技術(shù)，既需要挖掘現(xiàn)有云原生技術(shù)的價值來提供整個供應鏈的協(xié)同研發(fā)效率，也需要關(guān)注人工智能大模型技術(shù)的影響趨勢。(3)仿真技術(shù)隨著汽車電動化、網(wǎng)聯(lián)化和智能化的發(fā)展，仿真技術(shù)也在智能控制、信息通信技術(shù)方面發(fā)生了對應變化。首先是智能化發(fā)展帶了更多的傳感器單元，在智能控制技術(shù)迅速發(fā)展下，通過多樣化主被動智能傳感器來代替人類的感知，如主動型傳感器：超聲波雷達、毫米波雷達和激光雷達，以及被動型傳感器：攝像頭和紅外熱成像等。這些傳感器以光信號或電磁波信號，主要應用于智駕控制場景和智艙控制場景。這些傳感器本身具備邊緣計算能力，能夠?qū)?shù)據(jù)進行實時采集和計算。相較于傳統(tǒng)汽車的傳感器，無論在精準度識別、分辨率和探距能力上都呈現(xiàn)了代差級碾壓。因此基于復雜場景的智能傳感器仿真分析技術(shù)，需要考慮傳感器信號處理和控制器數(shù)據(jù)融合的算法效果，并結(jié)合模型化方法進行驗證，其具體過程如圖2.1-2所示： 圖2.1-2智駕系統(tǒng)開發(fā)測試程由于仿真測試需要貫穿自動駕駛軟件、硬件和率師測試的人模型開發(fā)測試流程，因此當前主流的仿真技術(shù)平臺尚不能提供貫穿流程的全棧式傷真過能力，未來智能網(wǎng)聯(lián)汽車仿真技術(shù)的發(fā)展需要從如下幾點進行突破：①加強場景數(shù)據(jù)共享：由于上卡游企業(yè)文間的場景庫缺乏統(tǒng)一的數(shù)據(jù)格式標準，因此仍然需要大量的人工干預來建立場景庫數(shù)據(jù)的行注和分析提取工作。為了更好地應對測試挑戰(zhàn)和提高測試結(jié)果精準度，場景庫的數(shù)據(jù)格式標準必參趨于統(tǒng)這需要行業(yè)或組織來主導推進統(tǒng)一化標準的建立。同時聯(lián)合各主機廠、技術(shù)供應商、監(jiān)管部門和研究機構(gòu)共享場景數(shù)據(jù)，加強上下游協(xié)同合作關(guān)系，以此來共建基礎通用場景庫。②全棧式仿真平臺貫穿V模型：仿真測試平臺需要為自動駕駛感知、融合與決策、規(guī)控等算法的準確度、域控制器的穩(wěn)定性以及整車運行的響應速度等領(lǐng)域提供測試環(huán)境，而大多數(shù)仿真平臺往往側(cè)重于某一方面，適用于模塊化的二次功能開發(fā)與測試。當前企業(yè)需要使用混合仿真平臺，借助各平臺不同的仿真模塊能力來達到聯(lián)合仿真測試結(jié)果。實際運用過程中，仿真測試工程師需要二次人工開發(fā)接口服務來傳輸場景測試數(shù)據(jù)，并整合各仿真平臺的測試結(jié)果，其中的時間和成本都直接影響了仿真測試驗證與評價的效率。未來端到端自動駕駛逐步成為發(fā)展方向，具備貫穿V模型研發(fā)測試全過程的全棧式仿真平臺將成為必然的發(fā)展趨勢，同時平臺也需要具備強可拓展性、允許企業(yè)仿真測試人員針對特定的測試需求快速構(gòu)建和定制仿真場景。③邊緣計算和分布式仿真：由于智能傳感器在感知模型上需要大算力芯片支撐，隨著數(shù)據(jù)處理能力的提高，邊緣計算和分布式仿真技術(shù)可能會在自動駕駛仿真測試中得到更廣泛的應用。這將有助于在現(xiàn)實交通環(huán)境中更快速地進行仿真測試和數(shù)據(jù)分析，提高測試效率。④仿真測試結(jié)果融合DevOps流程：仿真技術(shù)在本質(zhì)上是測試驗證技術(shù)，在整體研發(fā)生命周期上應當實現(xiàn)上下游研發(fā)測試數(shù)據(jù)可追溯性，從頂端上游的用戶需求至下游仿真測試結(jié)果，應當實現(xiàn)鏈路閉環(huán)。仿真技術(shù)作為制造業(yè)領(lǐng)域的技術(shù)，與云原生DevOps技術(shù)生態(tài)存在一定的行業(yè)壁壘，因此企業(yè)與相關(guān)從業(yè)者應考慮跨行業(yè)融合的解決方案，通過接口服務將仿真測試結(jié)果融合DevOps流程。⑤AI提高場景模擬數(shù)據(jù)準確性：理論上場景模擬數(shù)據(jù)越接近真實世界，智能傳感器仿真測試的準確性就能越高。為了提高場景模擬數(shù)據(jù)的真實性，可以通過引入Al分析模型來訓練模擬數(shù)據(jù)基于真實世界的物理簡化渲染，從而生成仿真度較高的場景模擬數(shù)據(jù)。通過返回仿真測試的評價結(jié)果至Al分析模型，進一步幫助企業(yè)挖掘具有產(chǎn)品商業(yè)價值的場景。(4)知識庫當前汽車的研發(fā)過程是多項目團隊參與+跨領(lǐng)域協(xié)同的復雜過程。新產(chǎn)品從設計到交付，需要有強管控流程來對多個責任主體進行支撐，以此來保證各個項目團隊的研發(fā)與協(xié)同效率。但由于研發(fā)技術(shù)棧的多維跨領(lǐng)域性，各團隊人員在業(yè)務上雖有相互聯(lián)系，卻也在各自領(lǐng)域的技術(shù)知識上有相當程度的獨立性。為了解決跨領(lǐng)域協(xié)同時必然會發(fā)生的協(xié)同效率問題，除了企業(yè)強力的管控流程推進項目，更需要建立高效的企業(yè)知識庫作為抓手。SOA面向服務的架構(gòu)，是一種軟件設計和開發(fā)的思想OA更則上開放標準與軟件資源進行交互，因此可以跨越廠商、產(chǎn)品與技術(shù)。電子電氣架構(gòu)演進方式如圖2.2-1所示，在較件定義當車》配合硬件的標準化程度不斷提高的時代發(fā)展下，SOA設計將成為整車軟件開發(fā)平臺的基礎圖2.2-1電子電氣架構(gòu)演進方式SOA架構(gòu)具有高度的靈活性和可擴展性，能保證車內(nèi)外所有應用避免大量的軟件接口適配，提升電子電器元件的集成度，幫助主機廠和供應商降低成本的同時節(jié)約空間，提高集成效率。它為當代汽車工業(yè)的賦能體現(xiàn)在如下方面：●服務化響應市場與用戶：傳統(tǒng)汽車上的每一個功能無法輕易變動，牽一發(fā)而動全身。而在智能汽車時代，各個域控會將其對應的功能封裝好并提供接口對外開放，可以使得功能與功能的組合、新功能的添加等更為便捷；●靈活的平臺架構(gòu)升級：SOA所帶來的軟硬解耦特性，能夠有效降低架構(gòu)升級帶來的復雜度，使得軟件功能的更新限制在很小的范圍內(nèi)，且對硬件架構(gòu)產(chǎn)生的影響較低。因此在升級時，能夠大幅提升用戶體驗，實現(xiàn)更為便捷的聯(lián)網(wǎng)功能，實現(xiàn)不同平臺間的各種APP共享等功能；●快速安全的通信策略：車載跨系統(tǒng)的通信是通過SOA架構(gòu)的服務來實現(xiàn)的。在網(wǎng)絡基礎設施高度發(fā)展的背景下，以太網(wǎng)的通訊效率大大優(yōu)于傳統(tǒng)的CAN總線方式。服務可以通過共享數(shù)據(jù)來實現(xiàn)跨系統(tǒng)通信，包括使用共享數(shù)據(jù)庫、分布式緩存或共享文件系統(tǒng)等方式，通過加密保護可以確保pheSoharempenef計□□口從功能邏輯的角度對整車功能、整車特性及需求進行設計，輸出整車邏輯功能網(wǎng)絡。將整車功能塊映射到實現(xiàn)此功能的軟件組件(整車視角),識別軟件組件(整車視角)之間的通信接口交互方式，確定是基于服務通信、基于信號通信還是基于信號轉(zhuǎn)服務通信，或是混合通信方式，對軟件組件進行分組。此外還要確定各個ECU硬件節(jié)點(含硬件資源)以及ECU節(jié)點之間的物理通信連接，如CAN總線、以太網(wǎng)總線等。最后將軟件組件映射到各個ECU硬件節(jié)點上。在進行整車級架構(gòu)設計時可靈活使用自頂向下或自底向上的設計方法。成果物包括功能架構(gòu)、整車級軟件架構(gòu)、整車級的硬件架構(gòu)等。對外交付物為整車級的SOA服務接口描述文檔。根據(jù)高層級架構(gòu)設計的輸出進行設計和分解。定義系統(tǒng)拓撲，即將系統(tǒng)功能分解到子系統(tǒng)功能、定義絡管理。自頂向下或自底向上的設計方法同樣適用于此過程。成果物包括系統(tǒng)級的全局時間描述文檔、系統(tǒng)級的網(wǎng)絡管理描述文檔、系統(tǒng)級的信號轉(zhuǎn)服務描述文檔、系統(tǒng)拓撲描術(shù)文檔。時外交付物則為系統(tǒng)級的軟件簇設計描述文檔、系統(tǒng)級的SOA服務實例描述文1.3機器設計(MachineDesign)此過程依賴系統(tǒng)設計的網(wǎng)絡拓撲描述文檔，其主要工作為將要部考當整車的機器(Machine)進行配置設計，包括通信結(jié)構(gòu)、機器(Machine)到實ECUSOA自頂向下或自底向上的設計方法同樣適用于此過程對外交付形為機器設計相關(guān)文檔。此過程的主要輸入是上游的機器設計(Mhchineesgn),主要內(nèi)容有：描述ECU硬件實體的有效資源，例如處理器單元數(shù)量、內(nèi)存、傳暖、執(zhí)行醒、引腳等；選擇合適的操作系統(tǒng)；為機器(Machine)定義硬件可用資源；操作系統(tǒng)配置人中臺服名配置，例如網(wǎng)絡管理等；平臺基礎模塊配置，例如Log等。對外交付物為機器清單描述以及相關(guān)配置?？筛鶕?jù)自頂向下或自屈向的設計方法，定義或重用服務接口及服務接口數(shù)據(jù)類型。對外交付物為進一步完善的SOA服務接口插述文當及SOA服務接口數(shù)據(jù)類型描述文檔。此過程依賴于上游的功能集群設計描述文檔及SOA服務接口描述文檔。主要進行軟件組件設計、可執(zhí)行實體設計、進程設計、功能集群間的交互設計、應用間的交互設計。自頂向下或自底向上的設計方法同樣適用于此過程。此過程的成果物為軟件組件設計文檔、可執(zhí)行實體描述文檔、軟件交互描述文檔。對外交付物為進程設計描述文檔、應用設計描述文檔。需要注意的是此過程的應用設計并不區(qū)分應用層軟件及平臺層軟件。主要工作內(nèi)容包括定義SOA服務實例的提供方和消費方，將SOA服務實例的提供方和消費方映射到可運行實體。成果物包括服務實例映射、服務部署描述等。此過程根據(jù)上游的應用設計描述文檔及SOA服務接口描述文檔進行軟件編碼實現(xiàn)。成果物包括SOA服務實現(xiàn)的應用軟件源代碼、軟件編譯配置、SOA服務開發(fā)框架及實現(xiàn)代碼、平臺服務代碼對象。對外交 功能型服務平臺核心服務(系統(tǒng)級服務)功能型服務(云動)功能型服務(車云系統(tǒng)服務)基礎型服務硬件抽象車云一體整車服務層整車服務層SOA開發(fā)需要的服務；從整車角度，將各節(jié)點的服務進行匯總，為應用開發(fā)提供更便捷的接口。車云一體：提供車云通訊和服務編排等功能，將常用的車云通訊能力封裝，在車端提供數(shù)據(jù)匯總功能統(tǒng)一傳輸至后臺處理；并提供服務編排能力，將各類服務通過編排腳本在車端重新編排成動態(tài)服務。3.SOA軟件平臺整車服務SOA軟件平臺整車服務是指從整車的角度提取各ECU域控制器的通用和公共的部分，用于支持整車的各種功能和業(yè)務需求，實現(xiàn)整車的統(tǒng)一協(xié)調(diào)、管理、調(diào)度和控制等服務。SOA軟件平臺整車服務服務層如圖2.2-4所示，是基于系統(tǒng)基礎服務實現(xiàn)并對應用服務提供整車級通用服務的層級。SOA軟件平臺整車服務常需要跨越多個功能域，實現(xiàn)多個功能域的組合復用。SOA軟件平臺整車服務主要包括了電源管理、網(wǎng)絡管理、多康管理、時鐘服務、升級服務、安全管理、日志和調(diào)試工具管理等。主要包含以下幾個方面：●整車基礎業(yè)務協(xié)同服務，定義整車基礎和公生的酸電源管理，升級管理，日志管理，診斷管理等；●整車通信與網(wǎng)絡協(xié)同服務，定義整車風備配置，網(wǎng)絡調(diào)度，網(wǎng)絡安全等；●整車功能安全協(xié)同服務，定義查手功能安生相關(guān)的服務，如：健康監(jiān)測，功能冗余，安全管理等；·整車跨域協(xié)同服務，定義需里在域間北享的服務，如自動駕駛整車服務，智能座艙整車服務，智能控制整車服務等。對于整車級服務的定史陽實現(xiàn)，主要有以下技術(shù)要求：●標準化的通訊協(xié)議：整本服務層需要使用標準化的通訊協(xié)議，以便各個服務之間能夠進行可靠的通訊和數(shù)據(jù)交換。常用溝通訊協(xié)議包括SOEMIP、DDS、共享內(nèi)存等；●可擴展性和靈活性：整車服務層需要具備良好的可擴展性和靈活性，以適應變化的業(yè)務需求和功能擴展。這包括支持動態(tài)添加和移除服務、動態(tài)調(diào)整服務的資源分配、動態(tài)配置和組合服務等能力；●可靠性和高可用性：整車服務層需要具備高可靠性和高可用性，以確保整車系統(tǒng)的穩(wěn)定運行。這包括支持故障恢復、容錯處理、負載均衡和故障切換等機制；●極致的性能：能夠處理高并發(fā)和大數(shù)據(jù)的操作，滿足整車系統(tǒng)的實時性和響應性；●可移植性和可維護性：良好的代碼質(zhì)量，統(tǒng)一的編程規(guī)范，功能實現(xiàn)基于基礎服務和POSIX操作系統(tǒng)接口，在QNX、LINUX等操作系統(tǒng)間提供較好的可移植性；有較好的故障碼和錯誤日志定義；●整車級服務要具有較好的易用性：提供配套的設計與開發(fā)工具，提高應用層服務的集成和開發(fā)效率；●安全性和權(quán)限控制：整車服務層需要具備強大的安全性和權(quán)限控制機制，以防止未經(jīng)授權(quán)的訪問和惡意攻擊。這包括數(shù)據(jù)加密、身份認證、訪問控制和審計日志等功能；●數(shù)據(jù)管理和分析：整車服務層需要具備強大的數(shù)據(jù)管理和分析能力，以便收集、存儲和分析整車系統(tǒng)的各種數(shù)據(jù)，并為決策和優(yōu)化提供支持。這包括數(shù)據(jù)存儲、數(shù)據(jù)查詢、數(shù)據(jù)挖掘和實時數(shù)據(jù)分L析等功能；●故障診斷和遠程管理：整車服務層需要提供故障診斷和遠程管理功能，以便快速檢測和解決整車系統(tǒng)中的故障，并通過遠程管理接口進行遠程配置和維護；●整車級服務的設計需滿足SOA軟件層級合理劃分的要求，對下做到對系統(tǒng)服務的合理封裝，對上需滿足所有應用層的公共服務需求；●整車級服務的設計需要滿足SOA的所有特性，包括高內(nèi)聚松耦合特性、兼容特性、SOLID原則、無狀態(tài)原則、歸一化原則等；●整車級服務的設計需滿足系統(tǒng)無關(guān)性原則，整車服務往往需要應用于車內(nèi)多個系統(tǒng)中，因此整車服務的設計與定義需要考慮到不同域、不同系統(tǒng)的差異性。整車服務層的設計規(guī)范有助于確保系統(tǒng)的一致性、可用性和可維護性，同時也方便團隊協(xié)作和項目的擴展。設計和定義整車級的服務，需要符合以下規(guī)范：●接口設計規(guī)范：定義清晰的接口規(guī)范，包括輸入?yún)?shù)、輸出結(jié)果、狀態(tài)碼和異常處理等。使用標準的命名規(guī)范和數(shù)據(jù)格式，以便不同服務之間能夠進行無縫集成和交互；●服務命名規(guī)范：給每個服務指定一個唯一的、具有描述性的司名，以便開發(fā)人員和系統(tǒng)管理員能夠清晰地理解其功能和用途。遵循一致的命名約定，提高線碼的可讀性和可維護性；●事件與方法定義規(guī)范：定義統(tǒng)一的事件和方法ID;●異常處理規(guī)范：定義統(tǒng)一的異常處理機制，并規(guī)定不同異常卷型的處理方式。例如，定義標準的錯誤碼和錯誤信息，以便客戶端能夠正確地處理異堂情況●安全設計規(guī)范：在整車服務層中加入合適的安全機制，包括身份認證、權(quán)限控制和數(shù)據(jù)加密等。確保敏感數(shù)據(jù)的安全性和用戶的合法說問；●性能優(yōu)化規(guī)范：考慮到整車服勞屋需要處理大量的數(shù)據(jù)和請求，設計合理的緩存機制和查詢優(yōu)化策略，以提高系統(tǒng)的性能和響應速度●日志和監(jiān)控規(guī)范：在整氣服務層中加入日志記錄和監(jiān)控功能，記錄服務的運行狀態(tài)和重要的操作信息。使用合適的不具和授式，對系統(tǒng)進行實時監(jiān)控和故障診斷；●文件和文檔規(guī)范：為整興服務層編寫清晰、易懂的代碼注釋，并準備好詳細的說明文檔。描述服務的功能、接口和使用方法，以便其他開發(fā)人員和合作伙伴能夠快速理解并正確使用服務；●整車級服務層的數(shù)據(jù)的設計需滿足一致性原則。整車服務會存在跨域交互和使用的情況，此時，數(shù)據(jù)的一致性要求才能保證不同域不同系統(tǒng)的功能符合預期且行為一致；●整車級服務層通信模塊的設計需滿足不同域不同通信協(xié)議的兼容性原則。由于整車服務面向的服務對象為車內(nèi)不同域中的對象，因此整車服務的通信模塊設計之初就必須考慮整車系統(tǒng)內(nèi)所使用的所有通信協(xié)議的兼容性和同步性等問題，并且還需考慮通信協(xié)議的可擴展性；●整車級服務層對于服務訪問的安全問題需要做特別的管理，由于整車級的服務往往關(guān)聯(lián)了車內(nèi)關(guān)鍵的功能和領(lǐng)域，因此服務訪問的權(quán)限管理需在設計時重點考慮；●整車級服務層要使用基礎服務層、設備抽象層、POSIX接口函數(shù)集等提高可移植性，盡量采用一套代碼來適配不同的操作系統(tǒng)，提高服務的可維護性；●整車級服務層要考慮功能安全和信息安全需求：E2E安全機制，配置和數(shù)據(jù)安全，必要的超時和異常監(jiān)測處理，安全日志等。4.整車SOA關(guān)鍵技術(shù)整車SOA在落地實現(xiàn)中有多個關(guān)鍵技術(shù)，詳細如下：●跨域通信中間件：跨域通信中間件提供了對消息隊列、發(fā)布訂閱系統(tǒng)、分布式消息通信機制的抽象和封裝，給SOA服務提供了統(tǒng)一的接口和框架，使其可以在不同的域中運行并實現(xiàn)相互間的通信；●服務注冊和發(fā)現(xiàn)：SOA服務需要進行注冊才能夠被其它服務或應用程序找到并使用它們，調(diào)用者需要具備服務的發(fā)現(xiàn)能力才能夠使用服務的接口和數(shù)據(jù)。服務注冊和發(fā)現(xiàn)通過服務發(fā)現(xiàn)協(xié)議來實現(xiàn)；●服務接口定義和描述：服務與使用者之間需要約定統(tǒng)一的通信合約，這個就是服務的接口定義和描述。接口定義和描述通常描述了具體服務的接口，接口的參數(shù)，使用的數(shù)據(jù)類型，接口之間通●跨域服務調(diào)用接口：跨域服務調(diào)用接口允許一個域中的服務調(diào)用另一個域中的服務，這個域可以是本車的，也可以是云端的?？缬蛘{(diào)用接口通常使用的通信協(xié)議有SomelP,DDS,MQTT,http/https等，同時需要配合安全模塊以確保安全和可控的跨域通信●數(shù)據(jù)和協(xié)議轉(zhuǎn)換：在不同的網(wǎng)絡之間轉(zhuǎn)換數(shù)據(jù)和控制信息，過據(jù)和協(xié)議的轉(zhuǎn)換以實現(xiàn)它們之信號的轉(zhuǎn)發(fā)和交互。數(shù)據(jù)轉(zhuǎn)服務：在當前SOA架構(gòu)下，網(wǎng)夫也高以實現(xiàn)部分信號、數(shù)據(jù)轉(zhuǎn)服務的功能，如S2S(signaltoservice,信號到服務●安全和身份驗證：服務發(fā)現(xiàn)上，需要能夠設定信息安全組隔離機制，使得服務廣播消息只發(fā)給有需要的服務使用者；服務訪問上，需要他夠為服務是供方設置信息安全訪問控制機制，認證并授權(quán)服務使用方發(fā)起的服務請求；服務通信提共信息安全傳輸機制，來滿足不同場景的安全要求；設置服務安全監(jiān)控機制現(xiàn)SC務相關(guān)的異常事件及安全響應處理機制；●服務治理：服務治理涉及管理、監(jiān)控維護和優(yōu)化服務的全生命周期。這些組件是實現(xiàn)汽車功能安●服務編排：SOA提供了服類的編排管理功能，編排管理對現(xiàn)有的服務進行編排和流程管理，可以將多個服務組合成更加雜的亞務流程或工作流程，同時提升底層服務使用的安全性和便捷性。服務編排使用拖拽等工具來定義和管理。本節(jié)主要介紹跨越確定性調(diào)度及確定性通信以及DDS通信中間件技術(shù)。整車跨域通訊技術(shù)見表2.2-1,是整車SOA系統(tǒng)開發(fā)的一個重要環(huán)節(jié)。目前可供選擇的SOC(Ser-vice-OrientedCommunication)協(xié)議有SOME/IP,DDS,MQTT,HTTP,主要區(qū)別如下：表2.2-1整車跨域通訊技術(shù)閱發(fā)布 1.跨域確定性調(diào)度及確定性通信(1)實時系統(tǒng)根據(jù)時間上的要求，計算機系統(tǒng)分為實時系統(tǒng)和非實時系統(tǒng)，非實時系統(tǒng)對任務執(zhí)行時間沒有保證要求，又叫做盡力(BestEffort)系統(tǒng)；實時系統(tǒng)對任務執(zhí)行有時間保征要成，如圖2.2-5所示，本文著重介紹實時系統(tǒng)。實時系統(tǒng)的定義：計算機系統(tǒng)行為的正確性不僅取決于計策機線具的確性，還取決于物理時間的正確性，這樣的計算機系統(tǒng)稱為實時系統(tǒng)。實時系統(tǒng)存在2個關(guān)鍵因素：●計算時間要有正確性保證，即計算時間滿足復由多個實時系統(tǒng)構(gòu)成，通過通信系統(tǒng)進行數(shù)據(jù)互的系統(tǒng)則稱為分布式實時系統(tǒng)。分布式實時系統(tǒng)通過擴展，彌補了單個實時系統(tǒng)在存儲個算方面的局限性。其特點有：●提升系統(tǒng)的擴展性：單個計算系統(tǒng)的計算資源有限；●降低復雜性：通過使用小型化簡單化的智能單元組合實現(xiàn)復雜處理功能；●提升線纜連接的安全性：通過將單個計算節(jié)點靠近傳感器/執(zhí)行器布置，從而減少整個系統(tǒng)的連節(jié)點2節(jié)點1節(jié)點2圖2.2-5實時系統(tǒng)與計算速度無關(guān)，實時系統(tǒng)/分布式實時系統(tǒng)必須保證任務或者動作得到及時響應或處理。任務處理的最后期限稱為截止時間(deadline)。根據(jù)任務的影響，截止時間又分為2種：●軟截止時間(Softdeadlines):錯過截止時間，系統(tǒng)結(jié)果仍然可用；EcunEcunFCU端到端時間基礎軟件運行時環(huán)境軟件組件c執(zhí)行、服務執(zhí)行和通信處理。 (3)基于SOA跨域通信中間件的確定性調(diào)度技術(shù)確定性調(diào)度技術(shù)是跨域服務、跨域通信的一項關(guān)鍵技術(shù)。在通信層面，可以支持的通信技術(shù)包括：CAN,Ethernet/TSN,PCle等。在上層應用層面，支持的應用協(xié)議包括基于IPC的共享內(nèi)存、DDS、SOME/IP等。確定性調(diào)度的實現(xiàn)由以下幾部分組成：丟開時間同步，無法保障分布式實時系統(tǒng)的時間確定性和計算結(jié)果(服務)的確定性。時間同步技術(shù)又分為集中式時間同步和分布式時間同步。在汽車領(lǐng)域目前以基于主從結(jié)構(gòu)的集中式時間同步為主?！裢ㄐ艛?shù)據(jù)的完整：接收端的數(shù)據(jù)要和發(fā)送端的數(shù)據(jù)一致，通常通過數(shù)據(jù)的校驗算法保證，常用的●通信時間的確定：通信的時延有界，通常通過設計手段和測試手段來保證。設計手段有時間觸發(fā)，優(yōu)先級等方式；測試手段有時間戳的方式?！裢ㄐ彭樞虻拇_定：保證接收端的數(shù)據(jù)順序與發(fā)送端的順序一致。通信順序的不確定性的原因主要有：o通信路徑不確定，如存在多條長短不同的通信路徑；。通信路徑上存儲機制，如中繼上的存儲轉(zhuǎn)發(fā)優(yōu)先級，限速設計情，如：交換機；通信機制本身，如存在重傳機制的通信協(xié)議例如保證通信順序的方法有：。通過時間觸發(fā)保證，采用時間敢感架構(gòu)，以時間為方拍驅(qū)動通信消息，從而保證整車分布式實時系統(tǒng)執(zhí)行計算鏈的時間特性和通信的順序。通過標簽計數(shù)，為每條消息加順序信息、接收端可重構(gòu)發(fā)送的順序?！すぞ哝湥悍植际綄崟r系統(tǒng)軟件設計具與要求高、復雜度大的特點，安全可靠的工具鏈對設計、開發(fā)、測試、驗證非常有必要核、工具鏈需要足：o當前汽車架構(gòu)的發(fā)展要求統(tǒng)一)成熟、安全的工具鏈支持不同車型當前和未來幾年間的發(fā)展；o軟硬件分離：滿定在中速面市需求，支持軟、硬件分離研發(fā)，加快集成驗證；o安全性：滿足汽車軟件功能安全開發(fā)與驗證需求；o可集成性：需支持對不同硬件、第三方軟件以及通信方式的集成；o可擴展性：需滿足主機廠對功能的擴展；o可復用性：需支持軟、硬件的復用性，降低開發(fā)周期。(1)概述SOA在汽車領(lǐng)域的發(fā)展和應用，要求在架構(gòu)層面使用高度可擴展、面向服務的通信中間件以實現(xiàn)各分發(fā)服務)作為面向服務的通信中間件，是電子電氣架構(gòu)跨域融合向整車中央集中化轉(zhuǎn)型過程中，實現(xiàn)DDS豐富的QoS(QualityofService,服務質(zhì)量)功能能保證數(shù)據(jù)在多種場景下的高質(zhì)量傳輸。例如，高級別智能駕駛場景中大體量的感知數(shù)據(jù)需要高質(zhì)量的實時傳輸支持，最典型的場景是通過DDS實現(xiàn)攝像頭圖像數(shù)據(jù)和激光雷達點云數(shù)據(jù)在各個硬件間高可靠、高實時傳輸?shù)男枨?；此外，通過部署DDS還能實現(xiàn)智駕域與動力域之間控制信號的實時通訊，以及智駕域與座艙域之間圖像信息實時、可靠的傳輸。目前，DDS在工業(yè)、交通、能源、國防等關(guān)鍵領(lǐng)域的實時分布式通DDSAdaptivePlatformAUTOSARClassicPlatformAUTOSAR準當中。目前國內(nèi)一些成熟的商業(yè)化DDS產(chǎn)品已實現(xiàn)在很多平臺上的集成與部署。①基本概念在實時分布式系統(tǒng)中，DDS協(xié)議位于操作系統(tǒng)和應用程序之間，采用發(fā)布-訂閱模型，定義了各節(jié)點間動態(tài)發(fā)現(xiàn)以及數(shù)據(jù)分發(fā)的邏輯和行為。該模型構(gòu)建了一個虛擬的“全局數(shù)據(jù)空間”的概念，所有對該空間中的數(shù)據(jù)感興趣的應用程序都可以接入。想要向這個數(shù)據(jù)空間提供信息的應用程序稱為"DataW-riter",想從數(shù)據(jù)空間中獲取數(shù)據(jù)的應用程序稱為"DataReader",雙方通過對于主題(Topic)的發(fā)布和訂閱進行匹配，DataWriter將數(shù)據(jù)發(fā)送給每一個匹配的DataReader。DDS通信概念模型如圖2.2-7所示。說明圖22-7DDS通信概念模型 DDS位于OSI模型的應用層，對下可支持UDP/IP、TCP/IP、SharedMemory、ZeroCopy以及核間通信(IPCF、RPMSG)等底層傳輸協(xié)議，傳輸協(xié)議的選擇可通過配置文件進行配置和調(diào)整。DDS可支持靜態(tài)類型、動態(tài)類型以及復雜類型的IDL文件的解析和代碼生成，同時支持對上述類型數(shù)據(jù)的發(fā)布和訂閱功能。DDS通信實體關(guān)系如圖2.2-8所示。DDS核心協(xié)議包括DDS-DCPS(經(jīng)常簡稱為DDS)和DDSI-RTPS兩部分如圖2.2-9所示，擴展協(xié)DDSSECURITYDDSRPCDDSXTypesDDSWEBDDS其中5個重要的協(xié)議包括：scribe,描述以數(shù)接為中心的發(fā)布訂閱通信機制；Protocol,提供了標準的序列化方式以及發(fā)現(xiàn)機制；●DDS-Security:定義了安全模型和服務插件接口(SPI)架構(gòu)；●DDS-RPC:定義了基于DDS實現(xiàn)的遠程調(diào)用框架(RPC);●DDS-XTypes:全稱ExtensibleandDynamicTopictypesforDDS,定義了DDS類型系統(tǒng)，以支持動態(tài)和可擴展的發(fā)布訂閱主題。DDS提供豐富的QoS服務質(zhì)量策略，可靈活滿足各種分布式系統(tǒng)實時通信的場景需求。DDSQoS服務質(zhì)量策略見表2.2-2,應包含OMG組織在DDS規(guī)范(DDSTMVersion1.4)中定義的22個策略： _____級穩(wěn)定傳輸；②高靈活、高擴展性：提供多種通信QoS選擇，為不同智能駕駛通信場景提供靈活的QoS管理，大幅度提升通信靈活性；③通信安全保障：提供訪問控制、應用程序身份認證、數(shù)據(jù)信數(shù)感信思保護等多種安全保障。(三)云原生云原生技術(shù)是一種以云計算為基礎，采用微服務容化、Dev等理念構(gòu)建的新型應用開發(fā)和部署方式。它能夠幫助企業(yè)實現(xiàn)快速迭代、彈性伸縮、高可用性和高成本的目標，從而加速數(shù)字化轉(zhuǎn)型實踐。在汽車行業(yè)中，云原生技術(shù)可以幫助車企實現(xiàn)車聯(lián)網(wǎng)、自動駕駛、智能網(wǎng)聯(lián)等方面的目標，并通過云原生大數(shù)據(jù)提供有價值的商業(yè)洞察和決策支持。為實現(xiàn)“軟件定義汽車”,以面向照多的架(SCA)成為新趨勢。在域集中化架構(gòu)和中央計算架構(gòu)呈現(xiàn)與云服務相似的部署形態(tài)同時，為適應香能網(wǎng)聯(lián)汽車的快速變化，汽車制造商不斷推進在智能駕駛、智能座艙、智能車控等場星中的軟情迭代夏新，這加大了車云平臺在數(shù)據(jù)傳輸、運維管理方面的挑戰(zhàn)。主要體現(xiàn)在以下幾個方面：●大規(guī)模的車輛接入和管理：實現(xiàn)千車千面，需要解決大規(guī)模車輛接入和管理的問題。●快速迭代和靈活部署：面對軟件更新頻繁的挑戰(zhàn)，需要能夠快速迭代和靈活部署車載應用。●車云消息傳輸和業(yè)務協(xié)同：車云平臺需要確保消息傳輸可靠，同時實現(xiàn)車云業(yè)務的協(xié)同作業(yè)。為解決這些挑戰(zhàn)，結(jié)合云原生技術(shù)和邊緣計算技術(shù)，構(gòu)建了云邊(車)高可靠、易擴展的技術(shù)架構(gòu)。通過車云協(xié)同平臺，在車載計算設備上部署容器應用，實現(xiàn)車端連接、車載應用統(tǒng)一部署迭代、車載邊緣計算和消息高可靠傳輸。車載云原生技術(shù)架構(gòu)涵蓋微服務、容器技術(shù)和DevOps等方面，結(jié)合云原生技術(shù)和汽車應用場景的研究，以應對不斷變化的汽車軟件需求。1.微服務架構(gòu)微服務本質(zhì)是一種架構(gòu)風格，倡導將單個應用程序開發(fā)為“一套小型服務”的方法，每個服務“運行在自己的進程中",并通過輕量級機制進行通信。這些服務“圍繞業(yè)務功能構(gòu)建”,并通過全自動部署機制“獨立部署”?！斑@些服務只有最低限度的集中管理”,可能是用不同的編程語言編寫的，并使用不同的數(shù)據(jù)存儲技術(shù)。一個服務通常實現(xiàn)一組獨立的特性或功能，包含自己的業(yè)務邏輯和適配器。各個微服務之間的關(guān)聯(lián)通過暴露API來實現(xiàn)。這些獨立的微服務不需要部署在同一個虛擬機，同一個系統(tǒng)和同一個應用服務器中。 一體化架構(gòu)微服務架構(gòu)圖23-1微服務對比單體應用的微服務對比單體應用架構(gòu)如圖2.3-1所示，微服務架的的共術(shù)優(yōu)費在子通過服務化實現(xiàn)低耦合效果。彼此獨立的各個功能可以單獨開發(fā)與部署。微服務架構(gòu)是一種將應用程序拆分成多個獨立的那匆，每個服務都運行在自己的進程中，并通過輕量級的通信機制進行協(xié)作的技術(shù)。通過單體型構(gòu)與曲服務架糊的對比，微服務在交付速度、吞吐量、系統(tǒng)擴展性、技術(shù)棧多樣性、可用性上的優(yōu)勢，無，將成為三企服務建設的得力臂助。當然微服務在帶來效率與質(zhì)量的提升的同時，也增加了整體過性、架構(gòu)層問題排查分析的難度，但這些弊端在開源體系下配套的中間件、容器與DevOps技術(shù)得到化解。雖然微服務與SOA架構(gòu)在些方面存在相似之處，但微服務更加注重業(yè)務導向、服務粒度的精細化以及服務之間的獨