1、 1 車車載載操作系統操作系統總體技術要求總體技術要求 研究研究報告報告 汽標委智能網聯汽車分標委汽標委智能網聯汽車分標委 資源管理與信息服務標準工作組資源管理與信息服務標準工作組 2 2021021 年年 7 7 月月 汽標委智能網聯汽車分標委發布 2 目目 錄錄 前前 言言 . 1 1 1 術語定義及縮略語術語定義及縮略語 . 3 1.1 術語與定義術語與定義 . 3 1.2 縮略語縮略語 . 4 2 車載操作系統技術現狀車載操作系統技術現狀 . 4 2.1 車載操作系統技術比較車載操作系統技術比較 . 4 2.2 車載操作系統技術應用現狀車載操作系統技術應用現狀 . 5 2.3 車載操作

2、系統信息安全技術現狀車載操作系統信息安全技術現狀 . 6 2.4 用于車載環境的虛擬機技術現狀用于車載環境的虛擬機技術現狀 . 8 3 車載操作系統技術演進趨勢車載操作系統技術演進趨勢 . 13 3.1 單系統向多系統轉變單系統向多系統轉變 . 13 3.2 單核向多核轉變單核向多核轉變 . 13 3.3 更豐富的基礎服務更豐富的基礎服務 . 13 3.4 提供適配硬件和應用的統一接口提供適配硬件和應用的統一接口 . 15 3.5 安全性要求更高安全性要求更高 . 16 4 車載操作系統技術標準化需求車載操作系統技術標準化需求 . 16 4.1 多系統技術標準化多系統技術標準化 . 16 4.

3、2 多核技術標準化多核技術標準化 . 16 4.3 基礎服務技術標準化基礎服務技術標準化 . 16 4.4 接口技術標準化接口技術標準化 . 17 4.5 安全技術標準化安全技術標準化 . 17 汽標委智能網聯汽車分標委發布 3 5 多系統技術要求建議多系統技術要求建議 . 17 5.1 虛擬機技術要求虛擬機技術要求 . 17 5.2 硬件隔離技術要求硬件隔離技術要求 . 18 6 多核技術要求建議多核技術要求建議 . 18 7 基礎服務技術要求建議基礎服務技術要求建議 . 19 7.1 互聯服務互聯服務 . 19 7.2 地圖及定位服務地圖及定位服務 . 19 7.3 語音服務語音服務 .

4、19 7.4 多媒體服務多媒體服務 . 21 7.5 云服務能力云服務能力 . 21 7.6 輔助駕駛服務輔助駕駛服務 . 23 7.7 AI AI 服務服務 . 23 8 接口技術要求建議接口技術要求建議 . 24 8.1 面向硬件的接口面向硬件的接口 . 24 8.2 面向應用的接口面向應用的接口 . 24 9 安全技術要求建議安全技術要求建議 . 25 9.1 信息安全信息安全 . 25 9.2 功能安全功能安全 . 25 10 總結及標準化項目建議總結及標準化項目建議 . 26 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 1 前前 言言 隨著智能網聯汽車的飛速發展，傳

5、統的分布式的電子架構已經不 能滿足整車的需求， 電子架構正在朝著由分布式向集中式， 由封閉到 開放，面向智能化、網聯化和集中化的路徑發展。2019 年 10 月，汽標委發布了車用操作系統標準體系 ， 規范了車用操作系統定義， 劃分了車用操作系統邊界，明確了車用操作系統分類，構建了車用操作系統標準體系，為車用操作系統標準化工作的開展提供了指導方向。車用操作系統是運行于車內的程序集合，管理硬件資源，提供軟件平臺和界面接口，為上層應用提供基礎服務。車用操作系統從與整車正常運行是否相關的角度，分為車控操作系統和車載操作系統。 車載操作系統主要應用于中控、 儀表和 T-box，提供車載信息娛樂服務， 可

6、具備網聯功能， 提供導航、 多媒體娛樂、 語音、輔助駕駛、AI 等高級功能。近年來，隨著汽車電子、云計算、大數據等技術的快速發展，車載操作系統的架構和技術功能不斷演進，急需開展相關標準化需求研究，指導車載操作系統的研發、測試、示范和運行等。 本研究報告的車載操作系統研究范圍是介于應用程序和硬件抽象層之間，主要由車載操作系統內核、資源抽象層、基礎庫、基礎服務、運行時環境及程序運行框架組成。 本研究報告涉及的車載操作系統架構在車載操作系統架構研究報告中有相應的詳細分析。 在此衷心感謝參加研究報告編寫的各單位、組織及個人。 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 2 組織指導組

7、織指導：汽標委智能網聯汽車分標委 牽頭單位：牽頭單位：國汽（北京）智能網聯汽車研究院有限公司、阿里巴巴（中國）有限公司 參與單位參與單位：斑馬網絡技術有限公司、上汽大眾汽車有限公司、國汽智控（北京）科技有限公司、 中國汽車技術研究中心有限公司、 中國軟件評測中心 （工業和信息化部軟件與集成電路促進中心） 、東軟集團（大連）有限公司、惠州市德賽西威汽車電子股份有限公司、大陸汽車車身電子系統有限公司、高通無線通信技術（中國）有限公司、長城汽車股份有限公司、 北汽福田汽車股份有限公司、 北京汽車股份有限公司、 上海博泰悅臻電子設備制造有限公司、 華為技術有限公司、 中興通訊股份有限公司、 泛亞汽車技

8、術中心、 江蘇智能交通及智能駕駛研究院、 Elektrobit、 上海機動車檢測認證技術研究中心有限公司、 安徽江淮汽車集團股份有限公司、 東風商用車有限公司、 一汽解放汽車有限公司、 上海汽車集團股份有限公司零束軟件分公司、 東風日產乘用車公司、 東風汽車集團有限公司技術中心、上汽通用五菱汽車股份有限公司、襄陽達安汽車檢測中心有限公司、北京百度智行科技有限公司。 參與人員參與人員：劉衛國、霍克、王琳、劉大鵬、卜燁雯、金一華、劉克、滿志勇、田思波、潘晏濤、吳含冰、張路、郭盈、周波、周海龍、李偉、伍宇志、唐僑、許勁、李儼，陳書平、石曉坤、毛雷、來冬清、錢國平、劉東、劉珺、秦文婷、顧照泉、周錚、陳

9、曉、陳琨、江浩、劉翔海、王紅燕、周鵬、王觀、李兵、黃慧麗、桂紹靖、管杰、吳勇剛、鄭巖、孫華、王圭、鄒徳英、武揚、程周、王振、彭楊、江恒、高海龍、彭偉、賈元輝。 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 3 1 術語定義及縮略語術語定義及縮略語 1.1 術語與定義術語與定義 下列術語與定義適用于本文件。 1.1.1 車用車用操作系統操作系統 vehicle operating system 運行于車內的系統程序集合，以實現管理硬件資源、隱藏內部邏輯提供軟件平臺、提供用戶程序與系統交互接口、為上層應用提供基礎服務等功能，包含車控操作系統和車載操作系統。 1.1.2 車車載載操作

10、系統操作系統 on-vehicle operating system 運行于車載芯片上，管理和控制智能網聯汽車車載軟件、硬件資源的軟件集合，為智能網聯汽車提供除駕駛自動化功能實現以外的服務，包括車載信息娛樂、網聯、導航、多媒體娛樂、語音、輔助駕駛、AI 等服務。 1.1.3 單系統架構單系統架構single system architecture 單個車載操作系統的架構，由車載操作系統內核、資源抽象層、基礎庫、 基礎服務、 運行時環境、 程序運行框架和車載操作系統安全模塊組成，對底層硬件和上層應用程序提供統一的接口。 1.1.4 多系統架構多系統架構multisystem architectu

11、re 在同一套硬件之上運行多個車載操作系統單系統的架構，分為硬件隔離、虛擬機管理器、容器三類多系統基礎架構，以及兩類或三類基礎架構的混合架構。 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 4 1.1.5 資源抽象層資源抽象層 resource abstraction layer 運行于車載操作系統內核上，為車載操作系統應用和基礎服務提供SoC 芯片平臺硬件的資源抽象、整車信號的資源抽象、外部 IoT 設備的資源抽象和外圍 IC 的資源抽象。 1.2 縮略語縮略語 下列縮略語適用于本文件。 ADAS：高級駕駛輔助系統 (Advanced Driving Assistance S

12、ystem) AI: 人工智能 (Artificial Intelligence) API: 應用程序編程接口 (Application Programming Interface) ASIL: 汽車安全集成等級 (Automotive Safety Integration Level) OBD：車載診斷（On-Board Diagnostics） OBU：車載單元（On-Board Unit） OTA: 空中下載 (Over the Air) RTOS: 實時操作系統 (Real Time Operating System) V2X：車與外界的互聯（Vehicle-to-Everything

13、） 2 車載操作系統車載操作系統技術技術現狀現狀 2.1 車載操作系統車載操作系統技術技術比較比較 目前， 應用于車載領域的操作系統有括 QNX、 Linux/AGL、 RT-Linux、AliOS、AliOS RT、Android 和鴻蒙 OS 等。各車載操作系統的對比參考如表 1 所示。 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 5 表 1 車載操作系統對比 車載 OS QNX Linux Android AliOS 鴻蒙 OS 技術性能 微內核 宏內核 宏內核 宏內核 宏 / 微 內核 編譯執行 編譯執行 編譯/解釋混合執行 編譯/解釋混合執行 編譯執行 可擴展性 高

14、 高 高 高 高 是否可裁剪 否（微內核，無剪裁的必要 ） 是 是 是 是 是否開源 否 是 是，有風險 部分開源 部分開源 硬件支持 多 多 多 多 少 是否具備功能安全證書 AISL-D AISL-D （RT-AliOS） AISL-D 2.2 車載操作系統車載操作系統技術技術應用現狀應用現狀 車載操作系統可用于實現一芯多屏（多屏融合、多屏互動等功能） 、單屏多系統（虛擬運行環境、多應用生態融合等功能） 、及一芯多功能單元（信息娛樂、T-box等功能）的方案。 （1）一芯多屏應用 一芯多屏應用是車載操作系統多系統應用中最常見的使用場景。典型應用有理想One智能駕艙多屏系統。該系統使用了TI

15、 J6和高通S820a兩塊芯片支持了Linux和Android兩套操作系統在四塊屏幕上的顯示。 （2）單屏多系統應用 單屏多系統應用主要用于對安全域非安全域有區分需求，并希望通過多系統擴展生態圈的使用場景。典型應用有南北大眾新一代信息娛樂汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 6 系統CNS3。該系統使用Renesas RCar H3N芯片支持Linux和Android兩套操作系統在一塊屏幕上的融合顯示。 （3）一芯多功能單元應用 為了充分發揮車載SoC的性能，滿足汽車上對多人多屏多應用的場景需求，在車載系統上更多地引入虛擬機系統方案。 2.3 車載操作系統車載操作系統信

16、息安全技術信息安全技術現狀現狀 目前主流的車載操作系統信息安全技術是基于ARM TrustZone的TEE技術。ARM TrustZone是基于硬件的安全功能，通過對硬件架構進行修改，在處理器層次引入了兩個不同權限的保護域安全域和普通域，任何時刻處理器僅在其中的一個環境內運行。同時這兩個域完全是硬件隔離的，具有不同的權限，普通域中運行的應用程序或操作系統訪問安全域資源受到嚴格的限制，反過來安全域中運行的程序可以正常訪問普通域中的資源。兩種域之間的硬件隔離和不同權限等屬性為代碼和數據提供了有效安全機制，普通域用于運行操作系統，提供了正常執行環境（Rich Execution Environmen

17、t，REE） ；安全域則使用安全小內核（TEE-kernel）提供可信執行環境（Trusted Execution Environment，TEE） ，機密數據可以在TEE中被存儲和訪問。即使普通域中操作系統被破壞入侵或ROOT，攻擊者也無法讀取或篡改TEE，保護關鍵業務與數據。TEE支持設備安全啟動、安全升級保護、敏感信息保護、安全管理等，對關鍵業務實時保護，TEE不需要額外的硬件支持，可由軟件控制自主切換。 （1）信息通訊的安全防護 系統可使用非對稱加密技術、鑒權技術、證書管理和認證技術、安全協議技術、防火墻技術 、VPN等技術，對系統通信進行信息安全防汽標委智能網聯汽車分標委發布車載操作

18、系統總體技術要求研究報告 7 護。 （2）系統服務層的信息安全防護 系統可使用訪問控制、惡意行為檢測、加密存儲等技術，對系統服務層進行信息安全防護。其中訪問控制機制，依據安全策略控制用戶、進程等主體對文件、數據庫等客體進行訪問。禁止不必要的服務（如FTP 服務等） ，禁止非授權的遠程接入服務，禁止 ROOT 用戶直接登錄，且限制用戶提權操作，刪除或禁用無用賬號 。 （3）系統應用的信息安全防護 系統應用可通過混淆、加殼防護、防反編譯、安全應用管理器等技術進行信息安全防護。 （4） 密碼加密安全 常見密碼算法類型包括對稱加密算法、非對稱加密算法、雜湊算法。 對稱加密算法：數據加密標準DES、高級

19、數據加密標準AES、國際數據加密算法IDEA、分組密碼算法SM4。 非對稱加密算法：RSA、橢圓曲線密碼算法ECC、數字簽名算法DSA、橢圓曲線公鑰密碼算法SM2。 雜湊算法：MD5（不安全） 、SHA1（160比特、不安全） 、 SM3、SHA256，用于保障數據完整性、數字簽名、MAC設計。 隨著國密算法的引入，國密安全模塊逐漸成為系統中的組成部分。國密安全服務通過固化在只讀存儲中的根證書和CA平臺進行交互，當系統收到外部請求，服務先將請求報文中的證書部分進行校驗比對，再通過證書附著的公鑰對請求內容進行驗簽，以此確認報文真實可靠，通過這種方式可以服務對外部進入的軟件升級包、控制命令、推送消

20、息等進入的消息進汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 8 行驗證，防止其被篡改。同時，組合AES、3DES以及國密的SM2和SM4構成的對稱、非對稱加密組合為通訊的私密性提供有效的保護。國密安全服務能夠為總線通訊、網絡連接、數據存儲等其他模塊提供加密、驗簽、簽名和密鑰存儲、證書管理等功能。 2.4 用于車載環境的用于車載環境的虛擬機虛擬機技術技術現狀現狀 虛擬機技術包括 Type-1 和 Type-2 兩種類型。 （1）Type-1 Type-1 型虛擬化技術通過提供系統虛擬機 （例如模擬類似于真實硬件的整個系統） ， 允許未經修改的客戶機操作系統作為客戶機運行， 該模

21、式需要借助硬件的虛擬化支持， 例如 X86 架構 AMD-V/Intel VT， ARMv8 和 Power架構的虛擬化 profile 等。其優勢在于客戶操作系統不需要進行任何修改就可以使客戶操作系統正常運行，并且它們并不知道自己在虛擬化環境下運行。這種虛擬化技術使用簡單，具有很好的兼容性，但這種虛擬化方式由于需要捕捉客戶操作系統發出的敏感特權指令，進而通過虛擬機管理器來模擬系統的特權指令，這個過程將降低指令的執行速度。 （2）Type-2 由于 Type-1 技術對硬件性能的要求較高， 并且運行效率不高。 因此提出了 Type-2 虛擬化技術解決方案。在 Type-2 中，虛擬機系統（客戶

22、 OS）的內核需要經過特殊修改，把特權指令改成對虛擬化層 API 的調用。在Type-1 的基礎上，把客戶操作系統進行了修改，增加了一個專門的 API，汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 9 這個 API 可以將客戶操作系統發出的指令進行最優化，即不需要Hypervisor 耗費一定的資源進行翻譯操作，因此 Hypervisor 的工作負擔變得非常的小，因此整體的性能也有很大的提高。Type-2 技術可以減少模擬執行特權指令造成的性能開銷，另外這種技術還可以優化 I/O 訪問和操作，運行速度基本可達到本機速度。 目前，可應用于車載環境的虛擬機典型技術方案有以下幾種：

23、a) Xen 虛擬機 Xen 是一個開放源代碼的 Hypervisor 平臺， 是在單個計算機上運行多達 100 個滿特征的操作系統。操作系統必須進行顯式地修改（ “移植” ）以在 Xen 上運行 （但是提供對用戶應用的兼容性） 。 這使得 Xen 無需特殊硬件支持，就能達到高性能的虛擬化。Xen 虛擬機可以在不停止的情況下在多個物理主機之間實時遷移。在操作過程中，虛擬機在沒有停止工作的情況下內存被反復的復制到目標機器。虛擬機在最終目的地開始執行之前，會有一次 60-300 秒的非常短暫的暫停以執行最終的同步化，給人無縫遷移的感覺。類似的技術被用來暫停一臺正在運行的虛擬機到磁盤，并切換到另外一

24、臺，第一臺虛擬機在以后可以恢復。 典型的 Xen 的應用架構圖如圖 1 所示。 圖1 Xen 虛擬機架構 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 10 b) QNX 虛擬機 由 QNX 提供的閉源虛擬機（如圖 2 所示）是基于 type1 實時優先級的微內核管理程序，用于管理虛擬機。QNX 虛擬機管理程序可以更容易地獲得安全關鍵部件，并通過隔離不同的客戶端操作系統的非安全關鍵組件，以確保安全性。QNX Hypervisor 能夠滿足嵌入式零停機生產系統的精度要求。 QNX 虛擬機可以支持多個不同的架構，在這些架構中可以分別運行QNX 的基礎服務(Foundation ),

25、主機端(Host)，虛擬機端(GVM)。 基礎服務模式： 所有的物理設備的驅動都運行于 QNX 的主機端(Host)，所有的用戶級應用都運于 QNX 虛擬機中(如顯示管理， 啟動動畫， 靜態畫面等) Host 模式，所有物理硬件的驅動均運行于 QNX 主機端，用戶的應用程序和驅動程序都運行在 Host 端，這種模式下通常只能運行一個 Linux 客戶端。 多用戶模式，所有的物理驅動均運行于 QNX host 端，用戶級應用和驅動都運行于主機 Host 端， 這種模式通?？梢灾С?2 個以上 Linux 客戶端。 圖 2 QNX 虛擬機架構 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研

26、究報告 11 c) ACRN 虛擬機 ACRN 是一個比較成熟、穩定的基礎虛擬化技術開源方案，由 Intel 聯合東軟開發的基于 Intel 芯片的虛擬化技術，目前只能應用于 Intel 系列芯片。ACRN 可以靈活的支持邏輯分區、共享和混合模式。 圖3 ACRN 虛擬機架構 如圖 3 所示， 硬件資源可以被分成兩個區域部分， 一部分可以直接被Hypervisor 啟動，甚至可以在 VM 啟動之前。若果沒有提前啟動的 VM，Service VM 是第一個啟動的，并且可以直接獲取硬件資源。 ACRN 為嵌入式和車載應用量身定制的虛擬化方案，追求靈活性、輕量級，并且在開發階段對代碼量有嚴格控制。由

27、于代碼量小，在做實時性、穩定性和功能安全的認證時就會比較方便。 ACRN 在設計上考慮了功能安全的要求和實時性要求，在開源社區里也在推動符合功能安全認證的開發模式，是針對車載的技術方案。它直接運行在芯片上，有 Service OS 的概念，這個概念是為了把 I/O 設備支持單獨拿出來放在 OS 里，現在開源的Service OS 是基于 Linux 的。在車載領域有很多 I/O 資源的共享，下圖是汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 12 具體落實下來后可能的架構。Service OS 會把儀表盤做在里面，ADAS 的顯示功能做在 ADAS 的 VM 里，Android

28、、中控和后臺都有單獨的虛擬機。從I/O 的延遲來講，實時性能不是最好，因為 I/O 訪問要經過 Service OS。 d) COQOS 虛擬機 COQOS 虛擬機（如圖 4）由 OpenSynergy 公司推出，不僅可用于座艙，也可以用于自動駕駛系統， 對自適應AUTOSAR也有對應， 并且也通過了2018版的 ASIL B 級認證。 最新的 COQOS Hypervisor SDK 圍繞安全高效的虛擬機管理程序構建，可在一個SoC上同時運行多用途操作系統以及RTOS和AUTOSAR兼容軟件。 圖4 COQOS 虛擬機架構 e) 哈曼虛擬機 圖5 HARMAN 虛擬機架構 汽標委智能網聯汽車

29、分標委發布車載操作系統總體技術要求研究報告 13 HARMAN虛擬機 （如圖 5）可以被用作各種硬件/軟件平臺配置的抽象層，每個軟件平臺可以在各自的參考硬件上使用，每種硬件平臺已經有一個 A 或 B 樣本可用于快速汽車制造商原型和車輛集成集群，在給定參考硬件上的不同的儀表和信息娛樂系統組合可以允許汽車制造商在不同市場、品牌和型號上進行區分。 3 車載操作系統車載操作系統技術技術演進趨勢演進趨勢 3.1 單系統向多系統轉變單系統向多系統轉變 隨著車輛的功能從單一的安全駕駛功能逐步向智能化、娛樂化、個性化過渡，單一系統已無法滿足多樣的功能需求。多系統的架構設計和技術方案在不斷演進中，從而支持不同的

30、車載應用。 3.2 單核單核向向多多核核轉變轉變 多核芯片的出現讓車載操作系統設計變得更加復雜。在單核 CPU 中，并不需要考慮 CPU 間負載均衡的問題，無論線程如何切換，CPU 始終處于工作狀態，并不會影響程序運行的總時間。但對于多核 CPU，系統必須考慮負載均衡的問題，避免出現負載小的 CPU 出現空閑等待的現象。 3.3 更豐富的基礎服務更豐富的基礎服務 傳統車載 ECU 的服務能力較為專一，僅提供如駕駛、娛樂等某一方面的基礎服務， 因此各 ECU 的操作系統功能也較為單一。 今后的車載操作系統通過如下方式提供更加豐富的基礎服務： 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研

31、究報告 14 某些傳統模塊通過增加能力承載更多的服務， 例如傳統的車載操作系統僅僅用于多媒體娛樂，加入導航功能后為駕乘人員提供了行車線路，帶來了駕乘便利；在增加了 ADAS 等輔助駕駛能力后，為駕乘人員的安全駕駛提供了幫助。 隨著某些模塊能力的提升，模塊自身可承載更強的服務能力，比如定位和地圖服務，隨著定位的能力越來越強，地圖的精度和實時性越來越高，將導航功能逐漸升級成輔助駕駛能力，甚至能夠為自動駕駛的關鍵決策提供原始數據。 車載操作系統逐步可提供的典型的新基礎服務包括： 1）互聯服務 傳統車載系統隨 ECU 固化，除非特殊情況返廠，一旦出廠基本不會進行修改或者功能變更。而車載系統在支持網絡互

32、聯的功能后，一方面系統的 OTA 功能能夠為系統固件升級以及上層應用、模塊的更新提供服務，形成一個持續性的軟件服務平臺。其次通過車載網關訪問公共互聯網和云服務平臺，為各種復雜應用提供更多的網絡接入和服務功能。而通過專網互聯，能夠為主機廠或者監管部門提供車輛特別是運營車輛的實時數據。同時 V2X 的通訊能力也為車路協同提供了更便捷的渠道。 另一方面， 通過定制的上層應用，手機、筆記本等便攜設備和車載系統產生互動，內容包括電子商務等支付業務以及定制化的個人服務。 2）輔助駕駛服務 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 15 傳統車載系統提供的人機互動相對較少，主要集中于主機

33、面板，需要通過駕乘人員的手部操作以及觀看輸出結果獲得反饋信息。而今后的系統則提供了更豐富的人機交互方式，如通過語音、手勢對車輛系統下達指令可以為駕乘安全提供更多保障；系統還能通過車內傳感器對駕乘人員的身份進行識別，提供相應個性化的駕乘環境，以及為了提供更好的視覺體驗提供的抬頭顯示以及 AR 導航等等。 3）AI 服務 隨著車載系統的算力提高和高速總線的出現， 各個感知設備提供各種數據，如視覺、指紋、壓力傳感器獲取駕乘人員的信息，車載操作系統需有高效安全的數據采集和分析機制進行分析和計算。車載操作系統需具備在端側進行數據訓練的能力從而在不上傳用戶數據的情況下讓系統具備越來越個性化的智能，根據一定

34、的規則和算法制定策略，分析比對駕駛習慣、駕乘人員狀態、外部環境，提供最佳的駕艙環境配置策略。在人機交互和主動服務上隨著駕乘人員對于系統使用的深入而越來越智能，給駕乘人員帶來優質安全的體驗。 3.4 提供適配硬件和應用的統一接口提供適配硬件和應用的統一接口 傳統車載 ECU 模塊的硬件平臺和操作系統基本自成一體，各個模塊的軟件接口和系統基本不能兼容，替換不同廠商的模塊和系統往往就意味著局部架構的改變。今后的操作系統能夠提供統一的接口，為今后產品的封裝和模塊化提供有力的支持。 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 16 3.5 安全性安全性要求更高要求更高 傳統的車載系統平

35、臺比較封閉，功能較單一，且分布式的架構使得系統相對安全。 隨著系統的復雜度和開放程度越來越高， 架構越來越集中化，以及服務越來越網聯化，使得整個系統功能越來越豐富的同時，也為外部入侵提供了途徑，增加了安全威脅面和攻擊面，信息安全和功能安全的重要性也慢慢凸顯出來。 4 車載操作系統技術標準化需求車載操作系統技術標準化需求 4.1 多系統多系統技術標準化技術標準化 由于不同的服務和應用對車載操作系統的實時性、 安全性和功能等要求不同， 多系統的架構設計和技術方案在不斷演進中， 包括硬件隔離技術、虛擬機技術等。但目前對多系統的技術要求尚未形成統一共識，車廠很難根據自身對多系統的安全性和靈活性等需求選

36、擇合適的多系統技術方案。 4.2 多多核核技術標準化技術標準化 多核技術的復雜度較高，運行在不同內核上的應用為了互相訪問、相互協作，需在 IPC 機制、共享內存的數據結構和同步原語等方面進行標準化。 4.3 基礎服務基礎服務技術技術標準化標準化 目前對車載操作系統可提供的基礎服務尚未統一其定義及技術能力要求，例如高精度定位具體可實現的精度和可支持的場景是什么等，不便汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 17 于車廠基于自身應用需求選擇適合的車載操作系統。因此，需要對基礎服務的技術要求進行標準化。 4.4 接口接口技術標準化技術標準化 統一的上層和底層接口技術是車載操作系

37、統實現與硬件和上層應用程序解耦的關鍵，從而適配不同的硬件平臺和兼容不同的應用。 4.5 安全安全技術標準化技術標準化 車載操作系統的信息安全和功能安全十分重要， 包括網聯網關的安全防護和主動檢測、應用模塊隔離和系統的訪問控制、功能備份和異?；謴偷雀鞣N防護手段，都逐步會成車載系統重要的安全屏障。因此，急需對車載操作系統的功能安全和信息安全提出新的要求。 5 多系統技術多系統技術要求要求建議建議 5.1 虛擬虛擬機機技術技術要求要求 （1） 硬件系統資源分配和共享（靜態和動態） ； （2） 外設資源的分配和共享（靜態和動態） ； （3） 域隔離，保證操作系統之間的獨立性； （4） 支持多操作系統間

38、通信，支持系統間的數據共享； （5） 支持系統安全和功能安全相關方案； （6） 管理各操作系統優先級，實現自適應分配最大化利用硬件資源，并滿足對時間敏感需求和系統服務質量的要求； （7） 管理各操作系統生命周期，包括啟動，運行，關閉，重啟等狀態； 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 18 （8） Hypervisor的存在應保證其實時性，不應對各操作系統性能產生影響； （9） 具有不同安全性和安全級別的應用程序可以在相同的硬件上運行，通過硬件或軟件分區相互保護； （10）全局電源管理。 5.2 硬件隔離技術硬件隔離技術要求要求 硬件隔離技術支持將硬件資源通過硬件分區的

39、方式進行劃分和管理，硬件資源的所屬分區擁有對該資源的訪問和管理權限，其他分區不能對該資源進行操作。針對具備內存保護單元的多核 SoC，可創建兩個系統的硬件分區，將不同的硬件資源劃分到兩個分區，并將不同 CPU 內核劃分到兩個分區，實現兩個分區上的 CPU 分別獨立運行各自操作系統。 硬件隔離技術的具體要求包括： （1） 管理系統資源， 如 SoC 外圍設備(Resource)， 內存區域(Memory)和引腳等。 （2）允許將資源劃分為與不同執行環境關聯的不同所有權組。 （3）允許所有者配置對資源的訪問權限。 （4）提供硬件強制隔離。 6 多核技術多核技術要求要求建議建議 車載操作系統面向多核

40、芯片硬件平臺時， 在資源共享、 內核調度算法、汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 19 IPC、CPU 負載均衡等方面需支持相應的技術要求，確保讓每個內核獨立訪問某種資源，不會被其他內核上的應用程序爭搶。 7 基礎服務基礎服務技術要求技術要求建議建議 7.1 互聯服務互聯服務 車載操作系統應支持與 T-Box、OBD、Tuner、V2X-OBU 等多車載終端互聯服務。車載操作系統應支持與個人移動端、云端的信息交互互通。系統應支持通過無線（如 Wi-Fi、藍牙）或有線（如 USB）等方式，與個人移動端投屏互聯，實現娛樂智能服務、輔助控制服務等；系統應內置常用 MQTT、

41、CoAP、HTTPS 等網絡協議，具備與云端互通能力，連接各種云服務。 7.2 地圖地圖及定位及定位服務服務 車載操作系統應支持地圖服務 （位置服務） ， 為包括地圖在內的各類應用程序提供位置相關的 API。地圖服務模塊可結合 GNSS、各類傳感器以及車輛信號數據，采用復雜的數據融合及濾波算法，實現準確的位置信息求解，為包括地圖在內的各類應用程序提供位置相關的 API。云端可實時獲取上傳的位置數據，部署各類服務，將位置信息與第三方服務或數據挖掘的數據進行融合，為用戶提供所需的與位置相關的增值和個性化的服務。 7.3 語音服務語音服務 車載操作系統應支持語音服務，其架構可分為語音形象、語音編程框

42、汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 20 架、語音服務模塊、語音開放平臺和語音自學習系統五部分。 語音形象：語音形象是一個特殊的系統內置應用，提供了所有交互展示型的功能，并向上層的語音類應用提供 API。比如：當有語音輸入（ASR）操作時，語音形象應用會將識別出來的文字顯示在屏幕上。當有語音播報（TTS）時，語音形象應用會處于播報態。語音形象應用通過接收下層語音框架上報的多種狀態信息（喚醒態、識別態、處理態、播報態等），展示相應狀態所對應的可視化界面。 語音編程框架：提供語音 API 支持基于 CAF 編寫的語音應用（CloudApp）或車載小程序語音應用。 語音服務

43、模塊：語音框架還提供了多個語音服務，主要是提供本地語音語義能力和與云端能力對接，主要包括：聲學前端和語音喚醒模塊（WUW），語音識別模塊（ASR），語音合成模塊（TTS），語音聲紋模塊（VPR），語義理解模塊（NLU），對話管理模塊（DM），語義生成模塊（NLG）等。整個架構是一套端云一體組件化可插拔的技術架構。 語音開放平臺：支持第三方應用開發者自助式編寫離線/在線的NLU、DM、NLG 等技能，通過技能管理還可進行可視化編輯、管理等工作。 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 21 語音自學習系統：通過將語音喚醒、語音識別等用戶交互的音頻數據進行定期的回流，并對獲取

44、的大量語音數據進行分析和訓練，可以得到更好的相關模型參數，通過閉環優化系統，定期將這些模型參數及相關資源進行下發，使最終用戶可以感覺到語音定期會更新很多新的能力，語音喚醒、語音識別、語義理解等效果也變得更好，而且能提供很多個性化的優化效果，用戶體驗也會變得更好。 7.4 多媒體服務多媒體服務 車載操作系統應支持基礎的圖像、音頻、視頻的編解碼播放和控制服務。 7.5 云服務能力云服務能力 7.5.1 自動升自動升級服務級服務（O OTATA） 車載操作系統應支持自動升級服務 （OTA） ， 通過網絡自動檢測到新版本（如新功能、安全補丁等）并下載安裝，為新功能、安全補丁的發布提供升級通道。 自動升

45、級服務架構如圖 6 所示，由客戶端與服務端兩部分構成?？蛻舳艘韵到y級服務的方式運行在操作系統中，支持服務端檢測系統版本、下載升級包、安裝升級包等操作。服務端應包括如下模塊： 操作控制臺：主要為配置管理員提供發布版本、上傳升級包的操作功能； 汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 22 版本查詢服務：向客戶端提供版本檢測查詢服務，要能穩定支撐大量設備的并發查詢請求； 升級包下載服務：向客戶端提供升級包下載服務，通常需要依賴分布式的文件存儲并接入數據中心以提高下載速度； 數據存儲：結構化的版本數據存儲以及非結構化的升級包文件存儲； 其他：升級過程全鏈路數據分析模塊、版本升級效

46、果統計模塊等，以幫助掌握升級過程并跟蹤新版本升級情況和效果。 圖 6 自動升級服務（OTA）架構 7.5.2 賬賬號號 帳號包括系統賬號、系統中安裝的應用賬號和服務帳號。不同的帳號服務可有各自的獨立的用戶界面、操作流程以及鑒權方式。 系統賬號是面向互聯網汽車的車載操作系統中云+端資源的串接器，汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 23 通過帳號統一接入服務端的服務資源和計算資源，實現數據共享和服務融合，以及多移動端的信息流轉和互通。系統帳號應提供分層次的應用授權訪問機制，通過服務端鑒權保證服務端訪問的安全性和合法性。系統帳號應支持對本地資源的管理，通過服務端鑒權保證在本

47、地增加、刪除以及切換帳號對應本地用戶資源并訪問該資源的安全性和合法性。 車載操作系統應支持的賬號管理機制包括： (1) 統一管理和開放帳號服務 (2) 匹配系統帳號和本地用戶資源管理 (3) 支持多系統帳號 (4) 帳號管理與帳號服務解耦 (5) 多帳號數據隔離 7.6 輔助駕駛服務輔助駕駛服務 車載操作系統可支持簡單的輔助駕駛服務，如 360 環式、倒車影像、盲區提示、車窗控制等。結合 CAN 消息的硬件抽象、標定、電源策略、時間策略和亮度策略，基于圖像拼接算法等技術，完成單一車控功能或組合式車控功能。 7.7 AI AI 服務服務 隨著車機芯片或者異構 AI 芯片的算力增強，智能座艙的智能

48、化程度越來越高，對于視覺感知、語音交互、網聯通信等功能需求的不斷提升，汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 24 車載操作系統的 AI 能力也許相應提升。 車載操作系統需支持結合 TensorFlow、MXNet、Caffe、PyTorch 等多種機器學習框架，同時再利用量化推理、自動計算調度優化、異構編譯執行等技術，來支撐本地 AI 功能開發?；谝陨霞夹g可設計語音識別、自然語言處理、圖像識別、文本分類、地圖導航、搜索引擎等 AI 模塊引擎，支持 AR 導航、盲區檢測，駕駛員疲勞檢測，FaceID，手勢識別、語音圖像理解等人機交互 AI 應用，滿足這些應用的各類性能指

49、標要求。 8 接口接口技術要求技術要求建議建議 8.1 面向硬件面向硬件的的接口接口 面向硬件的接口主要有面向 SoC 的硬件接口、面向整車信號的接口，面向外圍 IC 的接口以及面向 IoT 設備的互聯接口等。面向硬件的接口將操作系統面向車規級芯片的接口標準化，使得操作系統在調用硬件資源時，不需要了解硬件的內部邏輯及資源分配情況，只需要按照標準的接口進行參數配置即可實現對硬件的調用，從而實現對于不同硬件的適配，保證系統較高移植性。其中，多核異構架構適配性技術要求包括異構平臺硬件體系的融合驅動和異構平臺并行計算框架。 8.2 面向面向應用的應用的接口接口 面向應用程序的接口主要有 UI 控件、圖

50、形圖像處理、多媒體、網絡、藍牙、攝像頭、音頻、機器學習、位置、車身信號、本地數據庫、應用管理、系統等。面向應用程序的接口使得應用程序在調用操作系統的基礎服務時，不需要了解其內部邏輯，只需要按照統一的接口進行參數配置即可汽標委智能網聯汽車分標委發布車載操作系統總體技術要求研究報告 25 實現應用程序與操作系統的交互，從而進一步實現應用程序與操作系統的解耦，促進應用生態發展。 9 安全安全技術要求技術要求建議建議 9.1 信息安全信息安全 鑒于車載操作系統內核功能的復雜性，車載操作系統應構建完整的信息安全防護機制，降低內核漏洞對系統安全的危險，強化內核的安全防護能力。系統應具備多域隔離、一致性檢查