GnAT·嚴·SEMO發展白皮書3.02022序序言力、加快車用操作系統等關鍵技術攻關和產業化落地已成為中國汽車基礎軟件發展的重中之重。化、網聯化勝負的關鍵。在開放前提下要允許多路徑發布之后，在工業信息化部裝備一司和裝備中心的指導下第三次發布中國汽車基礎軟件白以及AUTOSEMO80余家成員單位，根據各家在生態領域積累的經驗，結合目前汽車軟件產業發展現狀，以智能汽車車用基礎軟件平臺為主題，圍繞中國汽車基礎軟件領域中的關鍵技術和關鍵標準研究進展進行總結。本書內容涵蓋市場發展情況，關鍵汽車軟件技術趨勢、關鍵標準研究情況、汽車軟件產業生態發展建議等方面。旨在鼓勵行業內的技術交希望借此書，能和各行業內單位共同探討基礎軟件技術發展、生態建設、人才培養等關鍵問題。旨在承擔中國汽車產業變革中的生態發展任務，為將來具有多要素、多維度、中國汽車基礎軟件發展白皮書3.0 第第1.1智能汽車車用基礎軟件平臺的定義與分類1.2智能汽車車用基礎軟件開發平臺的要素1.3智能汽車車用基礎軟件平臺發展現狀1.3.2豐田Arene·OS2.1AUTOSARCP2.1.2技術發展趨勢0102.2.2技術發展趨勢0192.3操作系統內核2.3.2技術發展趨勢025GnAUT5SMO中國汽車基礎軟件發展白皮書3.02.4虛擬化2.4.2技術發展趨勢0413第3第3.1基礎軟件開發平臺3.2基礎軟件驗證平臺3.2.1驗證平臺概要0623.2.2驗證平臺典型案例0634.1功能安全與基礎軟件4.2信息安全與基礎軟件0864.2.2信息安全軟件架構 4.3.2基于邊緣計算的嵌入式車端數據管 4.3.3數據驅動能力分級 4.4.1雙態敏捷開發模型 4.4.3持續集成持續交付 中國汽車基礎軟件發展白皮書3.0 中國汽車基礎軟件發展白皮書3.0第1章智能汽車車用基礎軟件平臺概述基于一個整車平臺，車企可以衍生出多款車型，從而全面提升硬件資源的復用性。縱觀汽車工業的白皮書3.0旨在分析汽車基礎軟件平臺及其關聯技術的發展趨勢，除了對其技術形態做一般性定義汽車軟件主要分為應用軟件和基礎軟件。應用軟件和業務形態高度關聯，不同控制器的應用軟件之車用基礎軟件開發平臺和車用基礎軟件驗證平臺在汽車軟件中的位置如圖1.1-1所示。基礎軟件平模塊，中間件，功能軟件以及與之相配套的開發工具鏈，用于支撐應用軟件的快速迭代開發。基礎軟件車用基礎軟件開發平臺車用基礎軟件驗證平臺2019年10月，汽標委發布了《車用操作系統標準體系》，參考該標準可以類似地將智能汽車車用GnAUT5SMO中國汽車基礎軟件發展白皮書3.0基礎軟件開發平臺對實時性和安全性的要求極高。目前，主流的安全車控基礎軟件開發平臺兼容OSEK/智能駕駛基礎軟件開發平臺主要面向智能駕駛領域，用于智能駕駛輔助，以及全自動駕駛功能的控中國軟件測評中心2019年發布的《車載智能計算基礎平臺參考架構1.0》就是智能駕駛基礎軟件開車載信息娛樂基礎軟件開發平臺主要為車載信息娛樂服務以及車內人機交互提供控制平臺，是汽車隨著車輛由單純的交通工具向智能移動終端轉變，車載信息娛樂基礎軟件開發平臺需要滿足如下l支持多生態資源，將手機端龐大的信息娛樂服務生態資源，通過采用相同或類似的操作系統，快l安全，通過深度定制達到車輛信息安全和功能安全的標準一是標準化/可擴展的功能實現。標準化/可擴展的功能實現既要充分滿足整車應用對基礎軟件開發平臺的功能需求，又要充分考慮這些功能需求的標準化/可擴展性。總結和歸納共性的需求，基于共性需求參考和借鑒國內外的優秀案例，充分考慮未來汽車基礎軟件的發展趨勢，提出更加成熟的軟件設二是符合功能安全要求。基礎軟件開發平臺支撐著整車應用的實現，如果不能守護好安全這道大門，中國汽車基礎軟件發展白皮書3.0后果不堪設想。ISO26262（2018）對基礎軟件開發過程的各個階段提出了充分的要求和建議，可以作開發方法論是基礎軟件開發平臺的重要組成部分。清晰的開發方法論可以最大程度發揮出基礎軟件交互規則不僅定義了基礎軟件開發平臺內部之間的交互規則，還定義了基礎軟件開發平臺與應用軟件、其他開發工具之間的交互規則，以便基礎軟件開發平臺可以與其他開發環境更好地兼容與交互。詳CP開發方法論為例，圖1.2-1展示了從系統層級配置到ECU可執行文件生成的過程以及該過程中的文圖1.2-1AUTOSARCP方法論概覽配套工具鏈是基礎軟件開發平臺的必要組成部分。使用工具鏈自動生成基礎軟件開發平臺的配置代放完整的要求。詳見圖1.2-2。基礎軟件開發平臺工具鏈基礎軟件開發平臺工具鏈GnAUT5SMO中國汽車基礎軟件發展白皮書3.0開放完整是提高開發效率的重要保證。工具鏈需要：配合基礎軟件開發平臺對新技術新功能不斷開用軟件開發；需要通過工具鏈的開放生態助力基礎軟件開發平臺的生態化發展。工具鏈的完整性不僅是單一業務場景下的功能完整，更是覆蓋全流程的完整。以自動駕駛為例，工具鏈需要覆蓋從算法模型訓練到芯片運行模型預測的完整AI開發過程，并通過其開放性不斷豐富自動駕駛應用場景庫以加快開發速國內外主機廠、造車新勢力、零部件供應商等都在著力打造其專屬的基礎軟件平臺，并已形成以OS為核心向基礎軟件平臺進化的趨勢。此處挑選兩個國外主機廠基礎軟件開發平臺的案例進行介紹，國內專門從事自主軟件平臺VW·OS的研發TOSARAPR19-03標準)。目前該平臺已實現在大眾ID.3系列車型上的搭載。大眾VW·OS如圖1.3-1中國汽車基礎軟件發展白皮書3.0為了更好地應對軟件定義汽車的發展需求，2021年8月豐田宣布將在未來五年內打造整車軟件平豐田Arene·OS軟件平臺如圖1.3-2所示，其主要包括軟件工具包和AreneAPI車輛應用程序編來實現數據處理和索引）。借助Arene·OS的車輛抽象層,開發者可以將相同的源代碼部署到任何運行問題。例如在安全車控基礎軟件平臺方面，本土化問題也越來越突出，不少控制器開發還是基于國外的解決方案；在智能駕駛基礎軟件平臺方面，還存在多處“卡脖子”技術短板，尚未出現足夠成熟的解決GnAUT5SMO中國汽車基礎軟件發展白皮書3.0第3章智能汽車車用基礎軟件平臺分別介紹了基于功能軟件的自動駕駛平臺和基于ASF(AU-第4章智能汽車車用基礎軟件開發平臺關聯技術以六個技術領域為切入點，分別研究了基礎軟件平臺對支撐功能安全所起的作用；研究了基礎軟件開發平臺對支撐信息安全所起的作用；研究了邊緣計算如何更好地駕馭數據以支撐車企數字化轉型；研究了雙態開發模型和持續集成持續發布CI/CD如何支撐中國汽車基礎軟件發展白皮書3.0第2章智能汽車車用基礎軟件的內核和中間件SARCP規范不僅提出了軟件分層架構，而且定義了基于該規范的標準開發流程AUTOSARCP為基于該規范的系統開發提供了一個通用的技術方法。它定義了從系統開發到單個ECU開發的各個階段，以及在各個階段需要完成的工作內容、需要提供的成果物。開發一個系統可分解一、開發抽象系統描述和基于VFB(虛擬功能總線，它描述了ECU個數和網絡拓撲無關）的系統描述，如圖2.1-1所示。該階段首先基于功能提出對整個系統的技術要求和約束條件，并且從功能視角設計合理高效的系統架構。其次，工程師在車輛電子電氣架構尚未確硬件資源情況將VFB視角的SWC分配到各個EGnAUT5SMO中國汽車基礎軟件發展白皮書3.0四、ECU軟件集成。當ECUExtract、基礎軟件、原子級SWC都開發完成后即可進行ECU軟件集進行整車級別的軟件架構設計以及相關功能模塊的定義。ECU級開發則著重開發單片機底層軟件。SWC級開發則主要開發具體控制算法。各級開發可以并行，不同的開發之間通過標準化的ARXML文件進行在AUTOSARCP分層架構中，自上而下分別為應用軟件層（ApplicationLayer）、運行時環境應用軟件層包含若干個軟件組件，軟件組件間通過端口進行交互。每個軟件組件可以包含一個或者RTE可以實現軟件組件間、基礎軟件間以及應用軟件組件與基礎軟件之間的通信。RTE封裝了基礎軟件層的服務、提供了標準化接口，使得應用軟件層可以通過RTE接口調用基礎軟件服務。此外RTE抽象了ECU之間的通信，即RTE使用標準化接口將ECU之間的通中國汽車基礎軟件發展白皮書3.0圖2.1-3AUTOSARCP軟件分層架構還提供包括網絡管理、存儲管理、模式管理和實時操作系統等服務。EC微控制器無關，包括板級硬件抽象、存儲硬件抽象、通信硬件抽象和I/O硬件抽象。該層將ECU結構進行了抽象，負責提供統一的訪問接口，實現對通信、存儲器或者I/O的訪問，從而不需要考慮這些資源是由微控制器片內還是片外提供的。微控制器抽象層是實現不同硬件接口統一化的特殊層，包括微控制對微控制器的寄存器進行操作。最后，由于對復雜傳感器和執行器進行操作的模塊涉及嚴格的時序問題，V模型是目前汽車電子軟件開發過程中采用的主流開發模式，V模型左側統稱為設計階段，主要涵GnAUT5SMO中國汽車基礎軟件發展白皮書3.0圖2.1-4AUTOSARCP工具鏈三、MCAL/BSW配置及RTE代碼生成工具。MCAL配置工具主要用于底層驅動的配置與配置代碼生成、BSW配置工具主要用于基礎軟件協議棧的配置與配置代碼生成，生成后的配置代碼需要與工具供應商提供的靜態代碼一同進行ECU軟件集成。RTE代碼生成工具以軟件組件ARXML或基礎軟件配置此外，目前市面上的AUTOSAR工具鏈都是桌面應用程序，這使工具鏈的維護和升級都不方便，并且由于應用程序在各個電腦上都是獨立的，所以其資源是不可共享的，使開發效率降低。而隨著5G和千兆網絡的普及，在未來，AUTOSAR工具鏈由桌面應用程序發展為Web應用程序AUTOSARCP發展歷史悠久，從誕生到現在已經有近20年的歷史。本章節將從當前痛點分析角度中國汽車基礎軟件發展白皮書3.0AUTOSARCP帶來的優勢和便利前文已經敘述了很多，但是它也不是完美的，在實際應用過程中也概念，比如標定量通過描述文件進行描述；應用接口不通過傳統全局變量的方式與底層軟件交互，而是對接口進行描述定義通過RTE統一接口進行匹配等。AUTOSARCP的軟件開發理念和傳統嵌入式工程完全兼容，導致OEM集成各家供應商開發的軟件模塊需要花費大量的精力和時間。原本希望借助AU-TOSARCP標準統一的優勢合作開發，但是因為工具鏈的兼容性問題而不得不統一工具鏈的使用，嚴重作，不僅操作上低效出錯率高，而且在錯誤檢查方面也不如傳統軟件集成方便。對于某些錯誤提示往往不能快速定位錯誤原因，對于某些需求追加或變更往往不能快速對應。針對這一痛點，國內大部分OEM具箱生成的代碼一樣，一些AUTOSAR工具鏈的RTE代碼生成工具生成調試帶來了不少麻煩。例如在調試基于SOMEIP的服務通信時需要根據服務請求信號、提供信號的數據多核分配，就算應用軟件做了多核分配，多核系統的優勢將受到核間通信效率的制約，甚至系統整體性方式，即衛星給其所在核的其他模塊提供服務接口并將收到的服務請求通過主衛星通信傳遞給主星，主衛星僅為同核其他模塊提供服務接口并將服務請求轉發到主星上處理；另一種極端情況是衛星和主星一GnAUT5SMO中國汽車基礎軟件發展白皮書3.0由于衛星提供的接口可以被該核的其他模塊直接調用并通過高效的主衛星通信與主星交互，從而避免了低效的Client/Server通信，大大提高了多核系統中基礎軟件的服務效率。另外由于主衛星可并行處要配合自旋鎖）這樣的數據結構對跨核PDU進行路由，可將不同類型的將CAN協議棧和以太網協議棧分配到不同的核。通過這樣的協議棧分割可達到CPU負載均衡及提升多中國汽車基礎軟件發展白皮書3.0如圖2.1-6軟件集群技術示例所示，通過軟件集群技術AUTOSARCP軟件架構被分割成了兩個獨單獨編譯，其除了可以搭載SWC之外在多個高度解耦的應用軟件集群，但是只能且必須存在一個主軟件集群，分別將應用軟件集群和主軟件如圖2.1-6軟件集群技術示例中的藍框所示，各個軟件集群就像是控制器上的一塊塊拼圖，而這些連接在一起形成完整的可執行文件。圖2.1-7軟件集群的連接展示了二進制清單連接兩個軟件簇的例子，其中軟件集群A運行時需要一個資源（RequireResource，指軟件集群運行時所需要的一切，或是S/R一覽表被默認值填寫且是可修改的，如圖2.1-7黃色框所示。對于軟件集群B來說，因為其具備固定的如果在燒寫時進行軟件集群連接，那么目標板內的軟件集群連接器軟件（On-boardSoftwareClusterConnector）負責在燒寫的同時，將軟件集群B中資源的句柄拷貝至軟件集群A中資源的句柄，從而完GnAUT5SMO中國汽車基礎軟件發展白皮書3.0模塊（LowProxyModules）兩部分，其中高代理模塊位于應用軟件集群代替原先的基礎軟件模塊提供符合AUTOSAR標準的接口，低代理模塊位于主軟件集群負責實現真正的基礎軟件模塊功能，二者之間SPONSE。其中REQUEST為期待響應的請求，客戶端有需求時才會向服務端發送請求，且客戶端會等待服務端反饋的結果。例如，客戶端如果需要向服務端請求VIN碼，則可發送REQUEST類型的消息。RESPONSE則為響應消息，即服務端的用于響應客戶端REQUEST類型的報文。例如：客戶端向服務端請求VIN碼，服務端則通過RESPONSE類型的消息給客戶端回復VIN碼。REQUE不期待響應的請求，客戶端有需求時才會向服務端發送請求，但客戶端不關注結果。例如，客戶端如果件通知，客戶端先向服務端訂閱消息，服務端當發現被訂閱的消息發生變化時則主動通知客戶端。例如，中國汽車基礎軟件發展白皮書3.0Center）將以太網數據轉換為SOC應用模塊所需要的數據。在SOME/IP通信中，SOC側的SDC作為客戶端，啟動后即開始訂閱MCU側的所有已知服務，MC發送訂閱的報文，為保證實時性，SOME/IP的數據傳輸周期與CASOME/IP序列化方式采用大端一字節對齊。因為一字節對齊是最簡單的對齊方式，大多編譯器很容易實現；并且采用一字節對齊，序列化后沒有冗余數據，報文的有效負載段都是有意義的數據，所以總析等工作。SOME/IP報文結構如圖2.本案例中的SOME/IP協議均基于UDP協議開發，它在用戶有需求的時候才發送報文，這種方法有一、傳輸效率高。與CAN等周期性的網絡相比，總線上不會出現過多不必要的數據，從而減少了資三、數據長度長。CAN-FD報文數據長度最大64字節，LIN報文數據長度最大8字節，單幀Flex-在智能駕駛中，時間是一個非常重要的參數，各個系統中需要保證時間一致，其中包括車云系統之GnAUT5SMO中國汽車基礎軟件發展白皮書3.0如圖2.1-10多傳感器融合系統中，CameraECU通過高精度攝像頭采集車道線、障礙物、標識等信息；RadarECU通過毫米波雷達進行障礙物、障礙物速度等信息的采集；Camera/RadarECU通過該系統對數據實時性、真實性要求比較高，所以需要保證Camera/RadarEC了達到該目的，如圖2.1-11時間同步步驟所示，本案例采用了AUTOSARCP時間同步解決方案，即注：本章有關AUTOSAR的內容是AUTOSEMO會員單位的經驗解讀，僅供行業參考。中國汽車基礎軟件發展白皮書3.0新四化（電動化，網聯化，智能化，共享化）的變革驅使汽車軟件系統變得更加靈活。汽車軟件既要安全又要可持續更新以反映新的功能特性或法規要求，為此需要新架構支持軟件組件的動態部署以及商業化的通用操作系統，車身控制則使用標準的AUTOSARCP。隨著未來新技術及深度嵌入式系統對計在未來，隨著汽車電子及軟件功能的大幅增長，E/E架構最終可能向基于中央計算平臺的整車集中原子服務層是實現數據融合和控制邏輯的功能模塊，作為服務的最小單位與單一執為應用提供可按需編排的基礎服務，實現一次開發多次復用，最大化提升開發效率。該層的設計目標是GnAUT5SMO中國汽車基礎軟件發展白皮書3.0圖2.2-2AUTOSARAP在軟件架構中的位置端口及框架設計,最終導出AP平臺的ARXML文件。產品工具應具備支持導入導出、解析、l軟件開發階段：使用AP產品生成工具，用于實現組件API代碼及ManAUTOSARAP開發方法論涉及工作產品的標準化，用于描述工作產品（如服務、應用程序、機器及其配圖2.2-3簡要展示了AP平臺的開發工作流，總體來說需要經歷三個階段七個步驟，最終將開發的中國汽車基礎軟件發展白皮書3.0①服務接口設計（DefineServices）：主要是定義服務接口及數據類型，包括定義服務所包含的圖2.2-3AUTOSARAP開發方法論標準。目前最新版本為R21-11。GnAUT5SMO中國汽車基礎軟件發展白皮書3.0在汽車行業，智能網聯、自動駕駛、V2X、OTA等功能逐漸成為標配，AdaptiveAUTOSAR面向POSIX標準的操作系統，可以更好支持這些功能。在最新的標準中為了更好的支持開發，在可用性及穩活支持日志內容定義等。同時，針對域控制器的異構平臺，新版本論上進行統一，定義了自動駕駛的傳感器接口、整車級健康管理的架構與接口、針對整車OTA升b.穩定性：增加針對系統穩定的特性。如在EM細節中增加了配置進程錯誤碼、功能組增加un同時在這些功能場景下，信息安全與功能安全成為不可或缺的關鍵機制。AdaptiveAUTOSAR針對l根據健康指標進行的機器恢復（例如降級l增加了確定性同步的內容，描述了同步行為和周期性激活的要求，包括時間同步和數據同步。b.面向信息安全：增加了入侵檢測系統管理，由標準化的接口來報告安全事件。通過標準化的過濾l軟件和硬件解耦；l支持分離式非耦合開發；l應用程序獨立于加密解決方案。隨著各種域控制器方案陸續問世，各細分賽道由分散到集中，由獨立到整合。目前整車域控制器，例如智駕域控，中央域控，智能座艙域控等均需得到高性能MPU芯片的支撐，因此POSIX標準系統的受域控制器行業的蓬勃發展以及各項政策利好，越來越多的參與者以各種新的身份加入進來，整體的行業角色將不再是E/E時代的OEM、Tier1及Tier2三種。隨著產業鏈結構的變化，位于下游負責整車生產和組裝的主機廠（即行業所說的OEM將不再通過系統與設備集成來獲取價值增量，而會轉向中國汽車基礎軟件發展白皮書3.0環境狀態成為下一個工具的輸入或啟動環境。因此，工具鏈的效率決定了整個系統的開發效率。所以隨著行業的發展成熟，工具鏈的發展將由現在分散的多工具相互切換配合形態，逐步升級到成熟開放的中拼的是對AP服務模塊的實現及理解。往出現多種開發工具同時使用的問題，因此亟需一套集成開發環境來簡化用戶桌面當前整車電子電氣架構，功能不集中，分散到不同ECU，使得功能和信號交互異常復雜，代碼和邏面向服務的體系結構，是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，獨立于實現服務的硬件平臺、操作系統和編程語言，使得構建在各種這類系統中的服務可以以一種統一和通用的方式進行交互。通過信息安全能和云端環境產生很好的協同，實現一整套車云生態環境，因此車端采用基于服務的通信SOA當前高算力芯片層出不窮，通過虛擬化技術，將芯片上所跑的各類業務分類進行隔離已經是目前很多車企的選擇。同時，在軟硬分離的背景下，在x86架構PC機上或云端通過虛擬化技術運行虛擬控制日志作為行為或狀態詳細描述的載體，提供可用于分析系統的活動和診斷問題的跟蹤記錄。在安全GnAUT5SMO中國汽車基礎軟件發展白皮書3.0Daemon表示DLT守護進程，它接收并處理來自AP上文介紹了從日志產生到日志數據流轉的整個過程，基于已有的日志信息，Dlt-Viewer可以提取出我們所關注的數據，如圖2.2-5所示。中國汽車基礎軟件發展白皮書3.0通過解析各功能模塊產生的DLT日志，可以分析出整個系統上電啟動過程，用戶可以直觀地觀測各本節主要介紹基于AP的智能域控制器（后續簡稱IDC）OTA升級場景及其實現方案。IDC的OTA其他ECU以UDS的形式發送升級指令及升級數據，IDC接收升級指令與數據后，在確保安全的情況下OTA服務器4/5G/WiFiECU1GWECU1GW①OTA采用雙分區機制，通過活躍分區去升級備份分區，升級成功后重啟GnAUT5SMO中國汽車基礎軟件發展白皮書3.0注：本章有關AUTOSAR的內容是AUTOSEMO會員單位的經驗解讀，僅供行業參考。在車輛動力電子，底盤電子和車身電子等實時控制功能實現當中，經常會使用到一些功能相對簡單的微控制單元（MCU）芯片（如單片機這類芯片資源配置較低，硬件上沒有為操作系統內核提供復雜的內存管理和特權級別的隔離功能，因此會采用一種簡要的操作系統內核結構設計。在簡要結構設計當中，內核服務與應用程序會被放置在同一地址空間，應用程序無需切換地址空間和權限層級就能夠直接調用內核服務，具有高效的優勢，有利于實時業務的實現。但相對于后面提到的宏內核和微內核架構設計，簡要架構系統缺乏內核隔離保護能力，任何一個模塊（無論是應用還是內核服務）出現問題都可駕駛和智能座艙領域也有大量應用。宏內核的特點是將所有傳統的操作系統服務（例如進程調度，內存在硬件能力的支撐下，宏內核可以實現用戶程序和內核的安全隔離保護，采用合適的進程調度機制（優先級搶占式）時也能夠滿足車用領域的硬實時性任務要求，并能支持虛擬化等新技術來滿足汽車E/E架但是應該看到，由于面向通用業務而設計，隨著宏內核功能的豐富，其代碼量也會變得越來越龐大，以Linux內核為例，2021年底其內核已經達到了3220萬代碼行的規模，且可能會持續增長，在域這不僅意味著軟件復雜度和硬件成本的增加，也意味著更高的信息安全和功能安全挑戰。目前，業界中國汽車基礎軟件發展白皮書3.0還未看到基于宏內核的操作系統產品通過功能安全ASIL為了應對這些問題，宏內核架構的操作系統也采用了模塊化，抽象，分層，層級等方法來控制其不l模塊化：內核通過模塊化的策略來組織功能，提供可加載內核模塊（LKM）機制。例如將大部分l層級：對于內核的資源管理引入層級的概念，如進程調度優先級的分類等。從功能服務的角度看，微內核（Microkernel）操作系統和宏內核系統并無本質差異，只是采用了不同的內核架構設計思路。由于宏內核架構系統將所有的服務都運行在內核態，任何一個模塊出現錯誤或者被攻擊就有可能引發內核的崩潰，從而影響到整個系統的穩定性。而且隨著內核代碼量越來越大，這種概率還會提高。為了保證內核的穩定性，微內核架構主張將宏內核的功能進行解耦，將某些功能從內態的服務提供各種通信機制，以保證這些服務能夠相互協作，這樣即使單個服務出錯或者被攻破也不會實現機制保留在內核態運行，這樣可以根據應用場景適配不同的內核服務實現機制。微內核的這兩個設計理念不僅提高了安全性，而且由于內核功能相對簡單，其內核服務的時延相對比較容易控制和估算，不過由于第一代微內核系統代表Mach采用了一種過于通用的進程間通信IPC（Inter-Process系結構相關的，過度抽象將極大影響IPC的性能，而利用體系結構相關的狀態進行優化則可將IPC性能提升到極致”。經過改進和優化，第二代微內核系統代表SeL4在采用了最小化設計原則的到了與同時期宏內核系統同樣的效率水平。及相應框架已經得到業界廣泛認可。當前汽車E/E架構正逐步邁入跨域集中式階段。新階段E/E架構的GnAUT5SMO中國汽車基礎軟件發展白皮書3.0從功能安全的角度看，不同功能域對于操作系統內核的要求也不相同。例如在功能相對簡單的安全簡要架構內核系統技術本身發展空間非常有限。考慮到基于微內核的RTOS實時系統已經有支持ASIL-D在智能駕駛領域，能夠滿足高功能安全（ASIL-D）和高性能要求的微內核實時操作系統將被廣泛應用。與此同時，為滿足機器學習和視覺AI算法的操作系統層接口要求，基于宏內核的安全操作系統（如滿足智能駕駛要求的功能安全等級。此外，宏內核系統也在一直不斷進行內核的裁剪優化，對安全關鍵功能采用ISO26262形式化或半形式化方法完成正向設計和驗證，以滿足高功能安全等級和高可靠性的在簡要架構操作系統產品領域，有國外大量的OSEK/VDXOS系統可供選擇，國內部分廠家開發的化落地，國內也有不少基礎軟件供應商在大力投入車用領域操作系統的開發，具備相當的競爭力。在開場上建立的強大生態占據了主導地位，但是國內部分頭部廠商都在積極發展自己的系統生態。與此同時，不少國內廠家還積極參加了Linux基金會的ELISA項目，旨在構建和認證基于Linux的安全關鍵應用程都可能對應著一個或多個進程，用戶應用進程之間由于可靠性和信息安全的需要采用了各種嚴格的時空隔離手段（技術原理參見2.3.3.2節）進行隔離，不能直接進行通信。但是用戶進程間的協作又必須要進在實現進程間的數據傳遞功能的同時，還需要內核通過對進程的運行狀態和運行時間的控制來實現控制中國汽車基礎軟件發展白皮書3.0發送者進程Write()接收者進程Read()Pipe(0) Pipe(1)消息隊列消息發送者進程Write()接收者進程Read()Pipe(0) Pipe(1)消息隊列消息類型數據進程2進程n進程1信號量接收者進程發送者進程具有父子兩個親緣FIFO（命可以在兩進程通信并進行讀寫操作；通過消息進程間傳PVVP用于進程共享內存兩個或多數據數據數據GnAUT5SMO中國汽車基礎軟件發展白皮書3.0SIGKILL接收送者進程1發送者進程SIGCHILD信號編號接收送者進程nSIGKILL接收送者進程1發送者進程SIGCHILD信號編號接收送者進程n接收送者進程2接收者接收者進程發送者進程TCP/UDP/IP/…基于TCP/IP協議出于最小內核服務設計的考慮，在微內核架構系統中，類似于驅動，文件系統等傳統的內核服務被移到了用戶態，許多原本可以通過簡單系統調用就可實現的內核功能也必須使用IPC機制來提供服務，在系統負荷較高的情況下可能會面臨著比宏內核更加嚴重的效率問題。因此對微內核系統的研究一般都傳統的微內核IPC機制設計是通過端口（port）和消息（message）來實現進程間接通信。通信的雙方不需要顯式指定另一方，而是通過端口進行通信，這樣可以將用戶進程本身和IPC通信隔離開，只要一個進程在內核擁有某個端口，就能通過這個端口和另一端的進程通信。進程之間通過端口流通的數移線程技術就是把其他進程的代碼拉進當前進程中運行，這樣就會大量減少內核進程切換的代價，同時也能通過共享參數棧和寄存器來簡化數據傳輸，減在一些學術文獻中，遷移線程模型被用在了LRPC（輕量級遠程過程調進程1操作系統內核進程1操作系統內核進程1進程2操作系統內核進程2中國汽車基礎軟件發展白皮書3.0用戶態進程1操作系統內核進程2操作系統內核進程2進程1進程2操作系統內核進程2上面兩張圖(圖2.3-1和圖2.3-2)是主流IPC和遷移線程IPC設計的對比。“要做到‘將代碼拉到本地’，遷移線程首先需要對線程結構進行解耦，明確線程中哪些部分是對通信請求處理起關鍵作用的。然后，這部分允許被調用者（負責處理請求的邏輯）運行在調用者的上下文中，將跨進程調用變成更接服務端進程線程池Binder驅動果。客戶端首先從內核和ContextManager處獲取服務端信息，然后通過內核對內核會從對應的服務端線程池里找到空閑的線程來響應處理（通過內存映射方式僅用一次拷貝完成數據內核Binder驅動也允許用戶為服務端配置一個最大上限線程數，這樣動態分配結合最大上限配置能夠防服務端進程線程池Binder驅動客戶端進程用戶態open/ioctl注冊服務獲取服務信息注冊服務ContextContextmanageropen/ioctlopen/ioctlVV內核態<內核態<>GnAUT5SMO中國汽車基礎軟件發展白皮書3.0在車用環境中，無論是基于宏內核還是基于微內核架構搭建的操作系統，使用什么樣的IPC通信機制并不是固定的，需要根據不同的應用和需求目標進行靈活選擇，必要時甚至會要求內核改進IPC通信要程度的任務同時在一個計算單元中運行的情況。如果不采用一定的隔離措施，就會出現低功能安全等級或者非關鍵任務進程有意無意地干擾高功能安全要求或者重要任務進程的運行的情況（因自身缺陷或應用BOS內核第一個層次是處理器級別的物理空間隔離(圖2.3-4)，例如可以將A和B兩個應用分別獨立運行在同一計算單元的不同處理器中，每個處理器都是一個獨立的運行系統。即使A應用所在處理器發生系統應用BOS內核處理器2應用A處理器2應用AOS內核處理器1處理器1應用BGuestOS第二個層次是虛擬機/容器級別的時空隔離(圖2.3-5)，例如可以在同一個計算單元（可能有1到多個處理器）上虛擬出多個資源獨立的虛擬機空間，每個虛擬機/容器分配有獨立的物理地址空間和處理器資源。將A和B兩個應用分別運行在不同的虛擬機/容器空間中，即使A所在虛擬機空間發生了系應用BGuestOS應用AGuestOS虛擬化處理器硬件第三個層次是內核和應用間的隔離(圖2.3-6)。因為所有應用都不可避免地要調用內核服務，一旦內核出現問題，很容易導致系統故障，從而影響到所有運行在該內核之上的應用，所以需要將內核空間與用戶空間隔離開來。用戶應用程序只能運行在被內核映射分配好的地址空間，并限制用戶態進程訪問內核地址空間，系統同時會禁止用戶進程執行某些可能破壞內核服務的機器指令，運行這些指令只能通中國汽車基礎軟件發展白皮書3.0應用應用OS內核處理器分區2應用BOS服務層第四個層次是應用間的分區時空隔離機制分區2應用BOS服務層OS服務層分區1OS服務層應用AOSOS微內核處理器硬件行隔離外，還需在負責時空隔離的操作系統內核和分區內進行實時調度（見2.3.3.3章節）。在分區隔離機制中，操作系統內核實施管理和安全驗證所有核心資源的配額和訪問，以保證系統的可靠性。操作系統內核為每個分區配置獨立的CPU時間和內存空間，并在分區內提供分區操作系統服務，實現分區內資區發送虛擬中斷，相應的分區操作系統在分配到的時間片中截獲信號，完成中斷處理，保證分區時間窗口的確定性，防止中斷處理過長導致分區調度時鐘窗口的不確定性。操作系統內核的空間域可以定義出一個空間保護模型，每個空間域（分區）有自己的內存地址空間，每個空間域類似于傳統的操作系統的進程，空間域內的任務類似于傳統的操作系統的線程。分區內調度的是任務，應用層和分區操作系統服第五個層次是應用任務進程或線程之間的時空隔離(圖2.3-8)。即操作系統內核/或者分區操作系統負責為每個任務進程分配獨立的地址空間和處理器服務時隙，并禁止進程之間的直接訪問。進程之間的信息交換必須通過調用內核提供的IPC（見2.3.3.1章節）進程通信服務來完成。這一層次的隔離可以GnAUT5SMO中國汽車基礎軟件發展白皮書3.0應用B應用B應用AOS內核/服務層處理器硬件上無法直接提供地址空間的隔離機制，需要通過軟件技術來實現隔離保護。基于軟件的隔離保護技術包括段保護、段匹配和地址沙箱技術。其具體的實現原理和特點見下表2.3-2。但無論是哪種基于軟件在目標代碼中的內存訪問指令前插入優化過的運行時檢測代碼，如果發現要訪問的段地址與當前段寄存器沖突，則拋出異常，并在系統失依賴于處理器硬件結構和機器把指令分為安全指令和不安全指令。針對不安全指令（跳轉指令、訪存指令）進行檢查。不安全指令可分為：可靜態驗證的指令（不通過運行就可確定其訪問地址的指令）和不可靜態驗證的指令（其訪問地址在程序運行時可能變且與處理器依賴關系強，移植在段匹配技術中，把每一個不安全指令的插入代碼中的地址高位填充為預定的段標識符，地址填充并不捕捉非法地址，它僅僅阻止影響的地址填充需要在每一個不安全的存儲或跳轉指種是分段機制，一種是分頁機制。分段機制只是在早期的X86架構處理器上引入（在X86-64架構之后引入了多級頁表機制。虛擬地址的哪個頁面映射到物理內存的哪個頁幀是通過頁表（PageTable）來描中國汽車基礎軟件發展白皮書3.0MMU配合操作系統內核完成了諸多空間隔離功能，比如通過特權模式劃分了內核空間和用戶空間，用戶空間無法直接訪問內核空間，必須通過某些手段（系統調用，異常，中斷等）切換到特權模式才能間接訪問內核。此外，每個進程都擁有自己獨立的地址空間，進程切換時地址空間也會切換。不同進程都擁有自己的一套頁表，因而即使兩個進程虛擬地址相同，映射的物理地址也是不同的。切換地址空間此外，操作系統內核還可以對每個頁表的訪問權限進行設置，當進程要訪問不可訪問權限的內存地址時，會產生一個異常通知處理器，操作系統內核可以通過捕獲這種異常和對這種異常的合理處理來實隨著計算單元硬件和虛擬化技術不斷地進步，配合操作系統內核所能提供的軟件隔離保護手段，基本上能夠滿足未來整車E/E架構智能集中化趨勢下的時空隔離要求。具體使用哪種隔離機制或者幾種隔在汽車應用領域，不可避免地要應對兩類實時任務。一類被稱為硬實時任務，這類任務無論在什么樣的情況下都必須在規定的截止時間內執行完畢，否則會造成不可接受的后果（如因碰撞傳感器引發的無論是哪種車用操作系統，都面臨著多個軟硬實時任務（進程/線程）同時爭奪有限資源的問題，需要操作系統內核提供合適的調度機制來滿足硬實時任務截止時間要求，在此基礎上，還需要滿足其他l非搶占調度方式是指當一個低優先級任務獲得了處理器執行資源后，即使內核知道有更高優先級的任務在等待處理器資源，仍然會讓這個低優先級任務繼續執行，直到當前任務完成或發生某種事件而進入阻塞態時，才會把處理器資源分配給當前最高優先級的任務。雖然這種調度方式比較l搶占式調度方式是指當一個低優先級任務正在處理器上執行時，如果有更高優先級的任務出現需這種方式對提高系統的實時性和響應效率有明顯的好處，但也要遵循一定原則，否則可能因為頻很顯然，車用領域的操作系統內核都必須支持基于任務優先級的搶占式調度方式。內核任務調度系統設計的核心是如何為每個任務定義合適的優先級，以保證包括任務截止時間在內的各項系統性能指標GnAUT5SMO中國汽車基礎軟件發展白皮書3.0阻塞隊列CPU隊列n阻塞隊列CPU隊列n時間片耗盡▲隊列1為空當隊列1▲隊列1為空當隊列1隊列0隊列0當隊列0為空隊列2隊列2當隊列2為空為了簡化系統設計，有的簡要架構系統（如uC/OS-II）甚至規定所有任務的優先級都不同，任務的優先級也同時唯一標識了該任務本身，但在復雜系統下這個方法不太適用。通常我們會將系統中所有的低優先級隊列才能得到服務。此外，還需為每個任務隊列采用合適的任務調度策略來決定哪個任務該優理定義。常用的任務調度策略和對應的任務優先級定義如下表2.3-非搶占式，當長短任務混合時對短SJF非搶占式，必須預測任務的運行時間，而且性能嚴重依賴于任務到達STCF搶占式，傾向于完成較短任務，導在任務運行時間相似的情況下平均針對MLQ調度策略可能帶來的低優先級任務饑餓（長時間得不到服務）和中國汽車基礎軟件發展白皮書3.0同時還會對任務的運行時間做評估，即統計每個任務已經執行了多長時間，并據此判斷此任務是長任務還是短任務，然后調整對應任務的優先級，被判斷為長任務的優先級會被逐次調低。為避免低優先級任務長期得不到服務，還可以定時/不定時將所有任務優先級提到最高，再根據任務實際運行長短動態逐這種策略是要預先知道任務的周期，并根據周期靜態地為每個任務分配一個優先級：任務的周期越短，意味著截止時間要求越迫切，優先級越高。RM優先級的任務。此外，RM也可以引入動另外，還有一種分區調度機制，該機制將處理器算力按一定比例然后把不同線程分到這些分區里按上述調度策略進行調度。當分區里的處理器資源預算被用完以后，該同樣可以采取“自適應分區調度”機制來改進調度性能，即定時計算各分區的算力閑置情況，在分區算需要指出的是，內核硬實時調度機制只是支撐硬實時任務的一部分，整個任務的實時性還需要依賴于應用本身的設計，例如在AUTOSARCP中還提出了通過將應用和CPU核（多核情況下）綁定，禁止總之，從技術發展趨勢看，上述的這些基于優先級的搶占式進程調度機制通過一定程度的“動態”優化，都能很好地在滿足硬實時任務的截止時間要求的基礎上，照顧到軟實時業務和其他非實時業務的在汽車安全車控和智能駕駛應用領域，操作系統內核除了要滿足應用的實時性和確定性要求外，功能安全的保證也同等重要的。由于操作系統內核是由軟件代碼組成，從軟件工程的角度來看，缺陷幾乎是不可避免的，而這些缺陷在某些特定條件下有可能會引發功能安全故障。因此，為了及時在系統運行過程中發現這些故障，并及時處理以防止故障的擴散，避免引發功能安全事故，采取健康監控是一種必極高的飛行器航空電子領域中，健康監控功能已經成為飛行器安全的重要保障機制。國際航空電子標準中定義的系統層次的健康監控中，將單一CPU內的健康監控體系分為三層故障處理級別。與之類似，汽車電子系統雖然沒有統一的故障處理級別標準，但也可以參考航空電子標準中的健康監控機制，例如可將故障級別劃分為分區級、管理級和核心級三個等級，并可對不同級別的故障設置不同的處理策略(圖2.3-10)。GnAUT5SMO中國汽車基礎軟件發展白皮書3.0故障產生故障產生檢測故障產生時的系統狀態，注入故障事件檢測故障產生時的系統狀態，注入故障事件查詢系統健康監控表查詢系統健康監控表<>將異常分區掛到異常分區隊列啟動管理級健康監控模塊，查詢管理健康監控表，進行管理級故障處理啟動分區級健康監控模塊，查詢分區健康監控表，進行分區級故障處理 判定故障級別<>將異常分區掛到異常分區隊列啟動管理級健康監控模塊，查詢管理健康監控表，進行管理級故障處理啟動分區級健康監控模塊，查詢分區健康監控表，進行分區級故障處理啟動核心級健康監控模啟動核心級健康監控模塊，查詢核心健康監控表，進行核心級故障處理底層硬件抽象層的異常處理程序首先會根據異常產生的位置來判定異常處理級別，然后健康監控系統根l如果CPU異常產生的位置是在操作系統內核態，則該異常屬于核心級異l如果CPU異常產生的位置是用戶態，則進行以下如果用戶分區產生的異常不是二次異常（用戶分區觸發異常的處理過程中再次觸發的異常被認定l分區級中國汽車基礎軟件發展白皮書3.0l管理級每個用戶分區可以配置一個管理分區，用來幫助被管理用戶分區處理自身無法處理的異常。被升級l核心級主要處理內核態程序運行過程中產生的一些異常和管理分區無法處理的被管理用戶分區產生的異常，內核態程序運行過程中產生的異常需要執行健康監控中的內核默認異常處理，如記錄異常上下文信分區內應用應用分區分區內應用分區級健康監控分區級健康監控應用故障產生管理分區管理級健康監控管理級健康監控故障注入操作系統內核故障注入分區級管理級系統健康監控表核心級核心級健康監控整個健康監控系統的故障分派及處理的架構如圖2.3-11所示，其核心是由操作系統內核所維護的系統健康監控表，該表由系統集成者進行靜態配置，作為系統邏輯配置的一部分。當處理器或操作系統內核檢測到一個故障時，在系統健康監控表中通過系統狀態和故障類型，獲取事先定義的故障處理級別。統健康監控表是作為健康監控總體故障處理派發的一級表，當故障處理進入對應故障級別的處理流程后，從2017年開始，一些國內供應商本土化研發的車用操作系統已經陸續在上汽、一汽、長安等OEM廠商的驗證交付項目和研發量產項目中得到應用。現階段，一些有代表性的基礎軟件供應商正在與國內GnAUT5SMO中國汽車基礎軟件發展白皮書3.0大產品，其中，Hypervisor提供半虛擬化功能并提供隔離保障，微內核RTOS運行緊急儀表，Safetyl提供快速啟動方案，支持啟動動畫；l提供中控投屏視頻與儀表畫面的融合方案；l提供儀表畫質監控功能；l提供業務穩定性監控功能，異常情況下及時切換到緊急儀表。但獲得所需功能安全等級認證較難。考慮到這些問題，某廠家基于自研車用操作系統產品系列，推出基智駕應用軟件智駕應用軟件智駕服務框架及功能軟件AUTOSARAPAILIBAUTOSARCPMicrokernelAUTOSARCPHypervisor異構異構SoC智能芯片中國汽車基礎軟件發展白皮書3.0AI融合感知處理及算法類業務需要使用圖形圖像處理以及深度學習算法模型框架，對底層算力芯片的驅動適配要求也較高，這部分服務由SafetyLinux承載，可充分利用其既有成熟的軟硬件生態快速完成開發。SafteyLinux支持POSIX標準中的大部分實時信號處理機制和功能，同時通過開源實時性RT同時，依托于某廠家微內核RTOS的ASIL-D級功能安全能力，通過在SafetyLinux中部署健康監控代理，實時對SafetyLinux眾所周知，自動駕駛系統中有著大量的算法任務調度，海量的傳感器數據交互，加上自動駕駛特有的應用場景，因此對操作系統有著非常嚴格的要求。對于操作系統而言，不但對實時性有著非常嚴格的微內核架構不僅保證了操作系統服務的硬實時性，并且在軟件架構上也契合了SOA的軟件開發思路，使得小魔盒在軟件架構的設計上更簡潔。QNX功能安全更是其優勢所在26262ASIL-D認證，得益于此，小魔盒的安全認證變得更為簡單。隨著ICT技術的發展，單SOC算力可以承擔更多業務，網絡帶寬拓展及低時延、區分服務等特性使合、可軟件定義。電子電氣架構從分布式架構到域集中式架構，再到中央集中式架構轉變，分散的ECU汽車電子底層硬件不再是由單一芯片提供簡單的邏輯計算，而是需要復雜的多核SoC芯片提供更為復雜控制邏輯以及強大的算力支持。但是多域業務具有不同的技術需求，比統傾向于RTLinux、RTOS；智駕域GnAUT5SMO中國汽車基礎軟件發展白皮書3.0件隔離的隔離性最好，單隔離域的性能、安全可靠性最好，但靈活性、可配置性差，不能實現硬件共享，彈性靈活的優選方案，是軟件定義汽車的重要支撐技術。典型應用場景如圖2.4-按需分配給每個虛擬機，允許它們獨立地訪問已授權的虛擬資源。Hypervisor實現了硬件資源的整合和隔離，使應用程序既能共享CPU等物理硬件，也能依托不同的內核環境和驅動運行，從而滿足汽車領域中國汽車基礎軟件發展白皮書3.0l虛擬機設備模擬：根據需求創建虛擬機可以訪問的虛擬硬件組件；l虛擬機通信：為虛擬機提供IPC，共享內存等通信機制。l虛擬機調度：為虛擬機提供優先級和時間片等調度算法；l虛擬機生命周期管理：創建，啟動和停止虛擬機；l虛擬機調測服務：提供控制臺，日志等調試功能；l輕量高效。Hypervisor在帶來軟件定義的靈活性的同時，也導致了軟件棧層次增加，不可避免會有性能損耗。汽車領域的成本敏感特性，注定了降低CPU、存儲、網絡、GPU等外設性能損耗的l安全可靠。相較于互聯網領域看重的資源動態分配和閑置利用，汽車領域更看重Hypervisor的實l便捷適配。在汽車領域，芯片類型和操作系統豐富多樣，嵌入式虛擬化的一大特點就是異構，Hy-GnAUT5SMO中國汽車基礎軟件發展白皮書3.0其特點是硬件平臺基本同構，大量節點構成集群，