智能網聯汽車電子電氣架構詳解

作者 / 阿寶

出品/阿寶1990

一、整體軟件架構

汽車電子電氣架構正在由傳統的分布式架構向域集中式和中央集中式演進， 并繼續演進至車路云一體化協同。智能網聯汽車整體軟件架構需要采用 SOA 分層思路構建， 從下往上，分為系統軟件層、 功能軟件層、 應用軟件層， 以及云平臺。其中， 系統軟件與功能軟件構成了廣義上的操作系統（本文中， 沒有特別強調說明的“操作系統”， 均指廣義操作系統。如下圖 智能網聯汽車軟件架構中紅色線框內所示） ， 是汽車軟件的基礎。此外， 汽車軟件一般要配合專業的硬件平臺來運行， 硬件平臺為基于高性能芯片搭建的異構分布式硬件運行環境， 具有選型靈活、 配置可插擴、 算力可堆砌等特點。

智能網聯汽車軟件架構

系統軟件是針對汽車場景定制的復雜大規模嵌入式系統運行環境， 不僅為上層應用以及功能的實現提供了高效、 穩定環境的支持， 也是各類應用調度底層硬件資源的“橋梁”， 在智能汽車整體軟硬件架構中處于核心的位置。主要包含虛擬化管理與 BSP（板級支持包） 、 操作系統內核（如：OSEK、 RTOS、 Linux、 Android Q） 、 基礎中間件三層， 進一步細化可分為異構分布系統的多內核設計及優化、 虛擬化管理（如 Hypervisor） 、 POSIX（可移植操作系統接口） 、 系統中間件及服務（如 AUTOSAR、 DDS）等。

功能軟件是根據面向服務的架構設計理念， 通過提取智能網聯汽車核心共性需求， 形成各共性服務功能模塊， 高效實現智能網聯功能開發的軟件模塊。主要包括數據抽象、 通用框架、 通用模型、 API， 以及安全域基礎應用和管理平面。

應用軟件運行在操作系統之上， 具體負責功能實現。即為實現具體自動駕駛功能、 HMI（人機界面） 交互等算法軟件， 基于下層基礎服務實現對整車服務、 應用、 體驗等進行定義和組合增強， 構建差異化競爭力的應用。應用算法差異化涵蓋了智能座艙（車載信息娛樂系統 IVI、 車聯網、 人機交互、 中控系統、 ADAS、 智能座椅等） 、 智能駕駛（L1-L5 級智能駕駛等級） 等領域。同時伴隨著云端軟件復雜性的提高， 車載網絡信息安全（檢測與防衛遠程攻擊） 也將逐步成為未來應用算法的關注焦點。

云平臺是獨立與車端之外， 可以在云端部署， 并與車端互聯互通， 提供計算、 互聯等服務的遠程服務平臺。在新一代汽車的 SOA 架構下， 越來越多的應用層接入云端， 使得車載網絡在以前獨立的電子領域（例如信息娛樂、 ADAS 和動力總成） 之間建立連接。云服務平臺包含大數據服務、 遠程診斷、 應用商店、 駕駛服務等。

此外， 汽車軟件整體架構在設計和開發過程中， 還需要關注安全要求， 以及配套工具鏈。安全體系自底向上貫穿硬件、 系統軟件、 功能軟件和應用軟件等各個層級， 需要關注的安全要求有功能安全、 信息安全、 預期功能安全， 防護的層次主要有三個， 分別是車路云一體安全防控、 整車級安全防控、 零部件級安全防控。軟件的配套工具鏈包括系統設計工具、 軟件配置工具、 系統集成工具和開發、 調試、 測試工具等。

當前， 車端軟件架構 SOA 化主要集中在智駕、 座艙、 車身功能域， 動力和底盤域受限于實際需求、 時延和可靠性要求以及其他非技術原因， 暫時還未實現 SOA 化。但未來， 隨著EEA 向 HPC 中央計算平臺的進一步演進， 車端各功能域軟件也會逐步實現完全 SOA 化。

各大整車企業和供應商提出的新一代軟件架構中， 均采用了 SOA 設計思想， 提出分層解耦開發目標。從底層的內核與基礎中間件， 到框架支撐層的功能軟件， 再到上層應用軟件，明確了各層之間的向下依賴關系， 各層之間通過規范化的 API 進行交互， 實現了不同層次間的分離與解耦。

汽車軟件整體架構中， 操作系統（OS） 是基礎支撐。不同功能域對于操作系統的要求也不同。比如傳統的動力和底盤域， 仍然是高實時性高確定性的嵌入式 OS（如 OSEK/VDX OS），通常和經典 AUTOSAR 平臺綁定在一起。在智能座艙領域， 以車端 Android 操作系統為主，通過 SOA 網關實現自身服務和外部功能域之間的服務化交互。在智駕域， 滿足高功能安全和高性能要求的實時操作系統 RTOS 被廣泛應用（如 BlackBerry QNX， 中興 ZEOS 等） ， 同時為滿足機器學習和視覺 AI 算法的 OS 層接口要求， 安全 Linux 操作系統也需要引入， 比如和RTOS 一起構筑軟件功能安全島， 支撐 AI 算法豐富接口要求的同時， 滿足智駕要求的功能安全等級， 如下圖所示。

智駕域控制器軟件架構示意圖

汽車軟件 SOA 新架構中均引入了自適應 AUTOSAR（Adaptive AUTOSAR） 平臺， 用于滿足一定的代碼規范性和功能安全的目標， 同時也是借助于 Adaptive AUTOSAR 平臺自身SOA 架構完成軟件系統設計與開發。Adaptive AUTOSAR 經過五年左右的發展， 目前推出了R21-11 最新規范（如下圖所示）， 國內外 AUTOSAR 廠商均在規劃對齊最新規范進行各自 Adaptive AUTOSAR 產品的完善?？傮w而言， Adaptive AUTOSAR 平臺面臨的場景更加多樣化， 相應的處理邏輯更加復雜多樣， 功能范圍更加寬泛， 即使是目前 Adaptive AUTOSAR 最新的規范也不能完全滿足應用軟件的需要， 需要在此基礎上做進一步的擴展和完善。在國內， 中國智能網聯汽車產業創新聯盟基礎軟件工作組和中國汽車基礎軟件生態委員會（AUTOSEMO）等組織正在致力于推進相關標準化工作。

Adaptive AUTOSAR R21-11 規范框架

在汽車軟件 SOA 架構中， 通過針對不同設備的抽象和適配， 對外發布原子服務， 實現設備和軟件平臺之間的解耦。在此基礎上進一步定義組合服務、 應用服務以及動態服務， 實現服務的完全共享和重用。當前， 中國汽車工程學會、 汽車工業協會等組織在積極推進感知設備、 執行機構、 車身傳感器及執行器、 熱管理系統的設備抽象和原子服務定義， 具體落地實現還需要一個較長時期的過程。

此外， 軟件 SOA 架構中各服務和應用模塊之間的通訊， 當前應用層協議主要還是SOME/IP 及其關聯的服務發現（SD） 。目前 Classic AUTOSAR 和 Adaptive AUTOSAR 都已經支持了 SOME/IP 協議棧， 同時在 Adaptive AUTOSAR 平臺中還提供了 S2S 服務， 實現服務和信號的相互轉換， 支持面向服務功能模塊和面向信號模塊之間的消息互通。當前， 以數據為中心的 DDS 協議雖然已經納入 Adaptive AUTOSAR， 但目前對 DDS 的支持還很少。另外， 用于車云通訊的 MQTT（Message Queuing Telemetry Transport， 消息隊列遙測傳輸， ISO標準下基于發布/訂閱范式的消息協議） 、 RESTful 還沒有正式應用到車端軟件架構中。

汽車 SOA 架構設計當前處于起步階段， 面臨諸多挑戰。其中包括車端硬件環境的限制，高實時性和高確定性要求， 系統設計與工作模式的轉變， 面向服務通訊組件的整合與集成，架構服務化帶來的信息安全風險， 功能安全方面的挑戰， 異構環境及非 SOA 架構模塊的并存增加了系統架構的復雜度等。

總體而言， 目前整車企業更多是進行少量服務化嘗試， SOA 架構還未形成通用普適性規范。汽車軟件架構正處于 SOA 化和傳統非 SOA 化架構并存的階段， 軟件跨域分布式計算與多功能域異構軟件環境是其顯著特點。未來隨著汽車電子電氣架構向中央集中式演進， 汽車軟件架構也會逐步實現全面 SOA 化， 各域功能進一步融合， 服務定義更加豐富， 服務重用與共享程度更高， 軟件開發更加靈活便捷。伴隨著車云一體化發展， 汽車軟件平臺會逐步演進為智能網聯汽車邊緣計算節點， 和智能網聯云平臺充分協同， 有效推動軟件定義汽車的實現。

二、系統軟件

2.1 虛擬化管理與板級支持包

系統軟件層面， 主要包括 BSP（板級支持包） 、 Hypervisor（虛擬化管理） 、 操作系統內核（狹義操作系統） 、 中間件組件等。

Hypervisor 是運行在基礎物理服務器和操作系統之間的中間軟件層， 可允許多個操作系統和應用共享硬件， 也可稱為 VMM（Virtual Machine Monitor） ， 即虛擬機監視器。硬件虛擬化技術管理并虛擬化硬件資源（如 CPU、 內存和外圍設備等） ， 提供給運行在 Hypervisor之上的多個內核系統。虛擬化（Hypervisor） 解決方案提供了在同一硬件平臺上承載異構操作系統的靈活性， 同時實現了良好的高可靠性和故障控制機制， 以保證關鍵任務、 硬實時應用程序和一般用途、 不受信任的應用程序之間的安全隔離， 實現了車載計算單元整合與算力共享， 是實現車載跨平臺應用、 提高硬件利用率的重要途徑。

在域集中式電子電氣架構下， 各種功能模塊都集中到少數幾個計算能力強大的域控制器中， 不同安全等級的應用需要共用相同的計算平臺， 傳統的物理安全隔離被打破。虛擬化技術可以模擬出一個具有完整硬件系統功能、 運行在一個完全隔離環境中的計算機系統。此時供應商不再需要設計多個硬件來實現不同的功能需求， 而只需要在車載主芯片上進行虛擬化的軟件配置， 形成多個虛擬機， 在每個虛擬機上運行相應的軟件即可滿足需求， 如下圖所示。虛擬化技術的出現讓“多系統”成為現實。

虛擬化技術示意

如下圖所示， Hypervisor 通常被分成 Type1 與 Type2， Type1 類型的 Hypervisor 直接運行在硬件之上， Hypervisor 需要自己管理所有硬件資源；Type2 類型的 Hypervisor 運行在某個Host 系統之上， 利用 Host 系統對硬件資源進行訪問。大家在 PC 上使用的 Virtual Box 和 VMware 虛擬機， 就屬于 Type2 的類型。

Hypervisor 類型

全虛擬化時， Hypervisor 完整模擬了所有硬件資源， Guest OS 不知道正在被虛擬化， 它也不需要任何修改就能運行， Hypervisor 負責捕獲并處理所有特權指令， 如果 Guest OS 使用的指令集架構與物理設備的相同（例如都是 ARM64） ， 那么用戶級別的指令可以直接在物理設備上運行。在某些場景下， 要完全模擬一個真實的物理設備是非常慢的， 因為所有對模擬寄存器的訪問都會產生一個軟中斷， 之后系統需要切換處理器特權模式， 陷入到 Hypervisor 當中進行模擬， 這樣會帶來很多額外的性能開銷。為了解決這個問題， 部分外圍設備會采用半虛擬化， 半虛擬化方式需要修改 Guest OS， 使之意識到自身運行在虛擬機當中， 通過 Guest OS 當中的前端驅動， 與 Hypervisor 中的后端驅動進行直接通信， 以此來換取更好得 I/O 性能，VMware vSphere、 華為 FusionSphere 就是比較常見的半虛擬化的方案。全虛擬化和半虛擬化方案如下圖所示。

全虛擬化與半虛擬化

每個提供商都將為該特定處理器提供操作系統和應用程序,隨著系統復雜程度的提高， 所需的計算能力被集中在一臺集中式計算機中。這些處理器被要求放在一起， 同時又要互不干擾分開工作， 不同的安全等級往往會帶來很大的難度。通過軟件虛擬化的方法， 可以創建分配任務的錯覺， 將每個任務分開， 如果某個特定任務由于軟件故障而失敗， 那么其他所有任務都將不受影響。軟件虛擬化是分隔不同軟件系統并降低總體硬件成本的有效方法。

在車載虛擬化領域， 主流的虛擬化技術提供商包括BlackBerry QNX Hypervisor（閉源） 及Intel與Linux基金會主導的ACRN（開源） 。目前， 只有QNX Hypervisor應用到量產車型， 也是唯一被認可功能安全等級達到ASIL D級的虛擬化操作系統。

Hypervisor 介乎于底層 DCU 硬件和上層操作系統軟件之間， 與標準化服務器（x86） +標準化操作系統（Windows 和 Linux） 的云虛擬化應用場景不同， 汽車嵌入式環境中的虛擬化技術面臨的挑戰是 Hypervisor 往往需要定制適配底層 DCU 硬件和上層操作系統軟件， 這對于 Hypervisor 的大規模商用與普及是一個非常大的技術障礙。因此 OASIS（Organization for the Advancement of Structured Information Standards， 結構化信息標準促進組織） 于 2016 年 3 月正式標準化 VirtIO 項目， 旨在提供一種通用的框架和標準接口， 減少 Hypervisor 對底層不同硬件和上層不同軟件的適配開發工作量。

同樣地， BSP（板級支持包） 是介于主板硬件和操作系統之間的中間軟件層。BSP 用于為操作系統提供虛擬硬件平臺， 使其具有硬件無關性， 可以在多平臺上移植。BSP 包括 Bootloader（以基礎支持代碼來加載操作系統的引導程序） 、 HAL（硬件抽象層） 代碼、 驅動程序、 配置文件等。不同的操作系統對應于不同定義形式的 BSP， 例如 VxWorks 的 BSP 和 Linux 的 BSP 相對于某一 CPU 來說盡管實現的功能一樣， 可是寫法和接口定義是完全不同的，所以寫 BSP 一定要按照該系統 BSP 的定義形式來寫， 這樣才能與上層操作系統保持正確的接口。

對于一般的嵌入式系統， 硬件部分需要嵌入式硬件工程師設計硬件電路， 新出廠的電路板， 需要 BSP 來保證其能穩定工作， 在此基礎之上， 才能進行下一步的軟件開發。

BSP 涉及到的企業較多， 涵蓋芯片制造商、 第三方軟件服務商、 整車企業， 比如高通、華為、 德賽西威、 中科創達、 長城毫末和長城諾博等。

2.2 內核

內核（狹義操作系統） 是汽車操作系統最基本的部分， 負責管理系統的進程、 內存、 設備驅動程序、 文件和網絡系統， 決定著系統的性能和穩定性， 是系統軟件層的核心， 也被稱為操作系統內核（OS 內核） /底層操作系統。根據域集中架構下汽車操作系統的發展情況，可將對應的內核粗略分為三大類：智能座艙操作系統內核、 智能駕駛操作系統內核和安全車控操作系統內核。

智能座艙操作系統主要為車載信息娛樂服務以及車內人機交互提供控制平臺， 是汽車實現座艙智能化與多源信息融合的運行環境。智能座艙操作系統應用于車機中控、 儀表、 T-Box等系統， 提供導航、 多媒體娛樂、 語音、 輔助駕駛、 AI 以及網聯等功能， 對于安全性和可靠性的要求處于中等水平。隨著車輛由單純交通工具向智能移動終端轉變， 智能座艙操作系統內核需要支持更多樣化的應用與服務， 可以支撐一個豐富的生態。

智能駕駛操作系統主要面向智能駕駛領域， 運行于智能駕駛域控制器， 支持智能駕駛所需的高性能計算、 高帶寬通信的高算力異構芯片， 對安全性和可靠性要求較高， 同時對性能和運算能力的要求也較高。智能駕駛操作系統內核應以標準的 POSIX 接口為基礎， 兼容國際主流的系統軟件。中間件如 Adaptive AUTOSAR 等， 滿足智能駕駛不同應用所需的功能安全和信息安全等要求。根據當前異構分布硬件架構各單元所加載的內核系統安全等級有所不同，AI 單元內核系統支持 QM~ASIL-B， 計算單元內核系統支持 QM ~ ASIL-D， 控制單元內核系統需支持 ASIL-D 安全等級。

安全車控操作系統用于傳統的車輛控制， 適用于動力系統、 底盤與車身控制等領域， 支持 MCU 等控制芯片。車輛底盤控制與動力系統對操作系統最基本的要求是高實時性， 系統需要在規定時間內完成資源分配、 任務同步等指定動作， 而嵌入式實時操作系統具有高可靠性、 及時性、 交互性以及多路性等優勢， 系統響應度極高， 通常在毫秒或者微秒級別， 滿足了高實時性的要求。目前主流的安全車控操作系統都兼容 OSEK/VDX 和 Classic AUTOSAR 標準。安全車控操作系統內核需要符合車規級實時控制功能安全應用需求， 應達到 ISO26262 ASIL-D 級安全認證。

在汽車電子電氣系統中， 不同的 ECU 提供不同的服務， 同時對底層操作系統的要求也不同。為支持車載軟件適應不同的汽車應用場景和硬件資源， 需要不同的底層汽車操作系統（OS內核） 來支撐。因打造全新操作系統需要花費太大的人力、 物力， 所以當前基本沒有企業會開發全新的 OS 內核。比如 Waymo、 百度、 特斯拉、 Mobileye ， 無論是自動駕駛企業還是車企的“自研操作系統”， 其實都是在上述現成 OS 內核的基礎之上， 將自研中間件和應用軟件整合形成。目前普遍采用的汽車 OS 內核主要有：

OSEK/VDX OS， 主要用于安全車控操作系統

OSEK/VDX 是應用在模塊和靜態實時操作系統上的標準， 由主要的汽車制造商、 供應商、研究機構以及軟件開發商發起。OSEK， 是指德國的汽車電子類開放系統和對應的接口標準；而 VDX 則是汽車分布式執行標準， 后來加入了 OSEK 團體。OSEK/VDX 標準主要由四部分組成：操作系統規范、 通信規范、 網絡管理規范和 OSEK 實現語言。OSEK/VDX OS 一般用作安全車控操作系統， 主要用于 ECU/TCU（遠程信息控制單元） 等底層控制單元。這些單元通常使用處理能力簡單且資源受限的 MCU 執行傳統的車輛控制任務， 對實時性、 安全性要求非?？量?。

目 前 OSEK/VDX 是國際上被廣泛應用的汽車行業標準 ， AUTOSAR OS 正是在OSEK/VDX 的基礎上進行了擴展， 并成為汽車應用主流。各嵌入式操作系統廠商都相繼推出了符合 OSEK/ VDX 規范的產品， 比較典型的有 Vector 公司的 osCAN 及 MICROSAR OS、WINDRIVER 公司的 OSEKWorks、 ETAS 公司的 RTA-OSEK、 MOTOROLA 的 OSEKturbo、美國密西根大學的 EMERALDS-OSEK、 普華軟件的 ORIENTAIS OS 等。隨著該規范應用的不斷深人，其結構和功能不斷完善和優化， 版本也不斷升級和擴展。

微內核 RTOS， 用于智能駕駛操作系統和安全車控操作系統

隨著自動駕駛技術的發展， 車輛環境融合感知與智能決策需求帶來了更為復雜的算法，并產生了大量的數據， 需要更高的計算能力和數據通訊能力?；?OSEK/VDX OS 的傳統嵌入式實時操作系統已經不能滿足未來自動駕駛的需求， 這些需求對原有的車控操作系統提出了巨大的挑戰。為應對挑戰， 業界在繼承 OSEK/VDX OS 高實時、 高功能安全特性的基礎上，發展出可運行于異構大算力、 高帶寬環境之上的微內核 RTOS 實時操作系統。

微內核 RTOS 架構設計是內核部分代碼量少， 系統服務更多的運行在用戶空間， 當某個服務發生問題時并不會影響內核穩定性， 天生具備功能安全優勢。但微內核缺少類似 Linux的開源生態環境支持， 所以微內核更適合汽車軟件中對功能安全要求更高、 穩定性更強的部分， 但同時對軟件生態沒有過高要求的場景使用（如需要 AI 算法模型框架的高級自動駕駛，較為封閉的微內核 RTOS 的應用生態很難滿足） 。

基于 POSIX 標準的微內核 RTOS， 通常以 ASIL-D 功能安全級別為目標， 滿足安全實時要求， 適用于自動駕駛所需要的高性能計算和高帶寬通信， 支撐自動駕駛決策、 規劃、 控制的算法需求， 可用于智能駕駛操作系統。在一些基于異構核的 SOC 硬件環境， 微內核 RTOS可以通過 Hypervisor 虛擬化平臺運行在實時核上， 用作安全車控操作系統， 支撐一些對實時性、 安全性要求高的功能需求。目前應用在汽車領域的微內核 RTOS 主要包括 BlackBerry QNX、 風河 VxWorks、 華為鴻蒙 OS、 中興 GoldenOS、 阿里 AliOS 等。

Safety Linux OS， 用于智能駕駛操作系統和智能座艙操作系統

Linux 是一款開源、 功能強大、 應用廣泛的操作系統。Linux 具有內核緊湊高效等特點，可以充分發揮硬件的性能。它與 QNX 等微內核解決方案相比最大優勢在于開源以及豐富的生態應用， 具有很強的定制開發靈活度。通?；?Linux 開發新的操作系統是指基于 Linux Kernel 進一步集成中間件、 桌面環境和部分應用軟件。Linux 功能較 QNX 等微內核更強大，組件也更為復雜， 因此 Linux 常用于支持更多應用和接口的信息娛樂系統中。AGL、 GENIVI 等聯盟致力于將開源 Linux 操作系統推廣至汽車領域中。AGL（Automotive Grade Linux） 是一款基于開放源代碼的車載操作系統。Linux 基金會推出可定制、 開源的車載系統平臺 AGL，旨在成為未來車載系統開源標準平臺?；ヂ撈囅到y聯盟（COVESA） ， 前身為 GENIVI 聯盟， 專注于實現對車載信息娛樂系統開源開發平臺的廣泛普及。

不論是 AGL、 GENIVI， 還是原生 Linux， 由于其對硬件外設驅動支持性高、 軟件生態豐富等特性， 成為了現階段汽車操作系統首選之一， 但其依然面臨缺乏功能安全的局限。為此，Linux 基金會啟動了 ELISA 開源項目， 致力于聯合業界廠家研發以功能安全級別 ASIL-B 為目標的 Safety Linux 操作系統。Safety Linux 操作系統繼承 Linux 豐富的應用生態， 可更好地支持汽車高級自動駕駛業務。

ELISA 項目吸引來諸多重量級汽車領域廠商和供應商參與。ELISA 的創始會員包括豐田、寶馬、 Intel、 RedHat、 英偉達等， 國內廠家華為、 中興通訊、 斑馬智行、 上汽、 地平線、 國汽智控也已經加入該組織。

目前來看， 實現 Safety Linux 工作量巨大， 盡管 ELISA 發布了一些資料對 Linux 進行了諸多卓有成效的鑒定分析， 但由于系統過于龐大， 后續分析仍然道路漫長， 而基于分析構建的認證工具、 過程資產也需要 ELISA 成員貢獻大量的精力， 任重而道遠。以 ASIL-B 為目標的 Safety Linux 實現， 尤其對內核關鍵功能進行安全增強更是一個長期任務。

Android Automotive OS， 主要用于智能座艙操作系統

Google 基于移動端 Android 操作系統， 開發了 Android Automotive OS， 專門服務于汽車領域。由于 Android Automotive 繼承了 Android 生態圈開放靈活的優點， 被廣泛應用到了車載信息娛樂系統當中（安全性要求較低， 車規要求寬松， 個性化需求多） 。但對功能安全要求高的儀表、 ADAS/AD 相關系統，Android Automotive OS 則無法勝任。

近年來， 智能座艙的娛樂與信息服務屬性越發凸顯， 目前主流車型的智能座艙操作系統包括 QNX、 Linux、 Android 等。QNX 占據了絕大部分份額， 開源的 Linux 以及在手機端擁有大量成熟信息服務資源的 Android 也被眾多廠商青睞。Android Automotive OS 成為后起之秀， 為了加快 Android Automotive OS 在座艙領域的應用進程， Google 建立了一個聯盟 OAA，包括奧迪、 通用、 現代、 芯片廠商英偉達等。Android Automotive OS 的買家， 不僅包括絕大部分后裝供應商， 同時也有新興造車勢力和傳統整車企業。

國內各大互聯網巨頭、 造車新勢力紛紛基于 Android 進行定制化改造， 推出了自己的汽車操作系統， 如阿里 AliOS、 百度小度車載 OS、 比亞迪 DiLink、 蔚來 NIO OS、 小鵬 Xmart OS等，傳統車企， 吉利推出的 GKUI 智能車載系統、 奇瑞 Cloudrive、 東風風神 Windlink 3.0、 長安的 in Call 均是基于 Android Automotive OS 開發。此外， 一些 Tier1 供應商， 也在 Android 領域進行深耕， 例如博泰推出基于 Android 深度定制版擎 OS。

總體而言， 智能駕駛操作系統與智能座艙操作系統將是未來發展重點， 其內核發展分別呈現如下趨勢。

2.2.1 智能駕駛操作系統內核

（1）宏內核 Linux 的安全能力增強

繼承 Linux 豐富的開源生態， 基于開源、 功能強大 Linux 宏內核， 重點增強其安全性和實時性， 發展以功能安全級別 ASIL-B 為目標的 Safety Linux 操作系統。在實時性處理方面，Safety Linux 包括大部分 POSIX 標準中的實時信號處理機制和功能， 如符合 POSIX 標準的調度策略， 包括 FIFO（先入先出） 調度策略、 時間片輪轉調度策略和靜態優先級搶占式調度策略。Safety Linux 內核提供內存鎖定功能， 以避免在實時處理中存儲頁面被換出， 同時通過實時調度算法減少任務上下文的切換時間， 從而滿足任務的時限要求。另外， Safety Linux 通過開源實時性 RT 補丁， 支持三級搶占、 自旋鎖主動釋放、 資源分區、 任務可配置優先級、任務排他性綁核運行、 無中斷干擾、 智能遷移等特性， 增強實時調度能力。在安全性方面，Safety Linux 針對車用場景需求裁剪系統配置， 借助 ELISA 開源項目提供的安全分析方法和認證工具， 識別功能安全需求， 對安全關鍵功能采用 ISO 26262 形式化或半形式化方法完成正向設計和驗證。另外提供任務運行監控、 內核增強管理、 緊急控制臺、 可靠重啟、 輕量級異常轉儲以及系統黑匣子等安全機制， 增強 Linux 安全能力。

（2） 微內核生態支持能力拓展

注重功能安全， 以 ASIL-D 功能安全級別為目標， 基于 POSIX 標準實現的微內核 RTOS。微內核 RTOS 僅實現任務調度、 時鐘、 中斷、 內存管理、 IPC 等最基礎功能， 文件系統、 網絡協議棧、 設備驅動、 POSIX 接口等都放在微內核之外， 運行在受內存保護的用戶態空間。微內核 RTOS 內核小巧， 代碼量少， 運行速度極快， 具有獨特的微內核架構， 安全和穩定性高， 不易受病毒破壞系統。微內核 RTOS 目前在全世界范圍內處于研究發展的初期， 不同廠家有不同的實現， 芯片及應用生態尚未完備。相比 Linux， 由于微內核 RTOS 缺少類似的開源生態環境支持， 目前只適合對功能安全要求更高、 穩定性更強， 但同時對軟件生態沒有過高要求的場景使用。未來對于智駕應用引入的 AI 算法模型框架， 微內核 RTOS 需要向上擴展支持 PSE51、 PSE52 及 PSE53、 PSE54 等 POSIX 接口標準， 甚至需要支持非 POSXI 標準接口， 向下則需定制適配兼容不同硬件廠家的 AI 算力芯片。

智能座艙操作系統內核

（1）支持多樣化應用

能夠支持多樣化的應用已經成為智能座艙操作系統的重要指標。目前， 汽車座艙除了儀表顯示、 空調/車窗控制等傳統功能外， 已經開始集成支付、 娛樂、 導航、 信息服務等多樣化功能。

（2） 多生態資源

越來越多的智能座艙操作系統采用 Android Automotive OS 或其他類 Linux 系統的原因是便于應用程序移植。目前手機端已經具備十分龐大的信息娛樂服務生態資源， 通過采用相同或類似的操作系統， 直接將功能移植到車輛智能終端上， 無疑是一種能夠避免重復開發并且快速豐富車端生態的思路。

（3）安全性

智能座艙的使用不僅關乎用戶的個人隱私安全與財產安全， 同時也通過車載網絡與底盤控制、 自動駕駛等車控系統相連通。因此， 智能座艙操作系統不能簡單地將手機操作系統復制到車端， 而應通過深度定制達到車輛信息安全和功能安全的標準。

2.3 中間件

為了提高軟件的管理性、 移植性、 裁剪性和質量， 需要定義一套架構、 方法學和應用接口，從而實現標準的接口、 高質量的無縫集成、 高效的開發以及通過新的模型來管理復雜的系統，即軟件架構“中間件”。中間件位于硬件及操作系統之上， 應用軟件之下， 是汽車軟件架構中重要的基礎軟件?？傮w作用是為應用軟件提供運行與開發環境， 幫助用戶靈活、 高效地開發和集成復雜的應用軟件， 并能在不同的技術之間實現資源共享， 并管理計算資源和網絡通信。中間件的核心思想在于“統一標準、 分散實現、 集中配置”。統一標準才能給各個廠商提供一個通用的開放的平臺；分散實現則要求軟件系統分層化、 模塊化， 并且降低應用與平臺之間的耦合度；由于不同模塊來自不同的廠商， 模塊之間存在復雜的相互聯系， 要想將其整合成一個完善的系統， 必須要求將所有模塊的配置信息以統一的格式集中管理起來， 集中配置生成系統。

有了汽車軟件中間件后， 所有的軟件和應用都具備了標準化接口， 同時硬件功能也被抽象成服務， 可以隨時被上層應用調用；軟件開發可以跨配置、 跨車型、 跨平臺、 跨硬件適應；軟件開發者可以更多地聚焦軟件功能的差異化；軟件認證可以有標準可依。汽車軟件架構中間件包括了應用廣泛的AUTOSAR、 ROS2， 以及百度 Apollo 專為無人駕駛研發的Cyber RT， 博世旗下子公司ETAS研發的針對高級別自動駕駛應用的通信中間件Iceoryx， 通信中間件SOME/IP、DDS、 MQTT等。

三、功能軟件

數據抽象

數據抽象通過對傳感器、 執行器、 自車狀態、 地圖以及來自云端的接口等數據進行標準化處理， 為上層的通用模型提供各種不同的數據源進而建立異構硬件數據抽象， 達到功能和應用開發與底層硬件的解耦。

通用框架

功能軟件通用框架是承載通用模型的基礎， 分為數據流（計算引擎） 和基礎服務兩部分。數據流向下封裝不同的智能駕駛系統軟件和中間件服務， 向通用模型中的算法提供與底層系統軟件解耦的算法框架， 基礎服務是功能軟件層共用的基本服務， 其主要服務于通用模型或 功能應用。

（1）數據流

數據流框架向下封裝不同的智能駕駛系統軟件和中間件服務， 向智能駕駛通用模型中的算法提供與底層系統軟件解耦的算法框架。數據流框架的主要作用是對通用模型中的算法進行抽象、 部署、 驅動， 解決跨域、 跨平臺部署和計算的問題。

（2）基礎服務

基礎服務是功能軟件層共用的基本服務， 其主要服務于通用模型或功能應用， 比如網聯服務、 數據服務、 OTA、 地圖服務等。

通用模型

（1）智能駕駛通用模型

智能駕駛通用模型是對智能駕駛中智能感知、智能決策和智能控制等過程的模型化抽象。

環境模型作為智能感知框架， 為智能決策和智能控制提供模型化的廣義環境信息描述。環境模型調度各類感知、 融合和定位算法， 對傳感器探測信息， 車-路、 車-車協同信息， 以及高精地圖先驗信息進行處理加工， 提供探測、 特性、 對象、 態勢、 場景等各級語義的道路交通環境和自車狀態信息。

規劃模型根據環境模型、 自車定位、 個性化設置和自車狀態反饋等信息， 為自車提供未來一段時間內的行駛軌跡， 主要分為行為預測、 行為決策和運動規劃三大部分。行為預測是根據感知和地圖數據對其他交通參與者未來的行駛軌跡進行預測， 為行為決策提供更全面、可靠的參考信息；行為決策為自車提供行為策略， 同時為運動規劃提供相應的規劃約束條件，保證規劃結果不僅滿足交通法規等硬性要求， 同時更加符合人的駕駛策略；運動規劃根據以上信息， 為自車規劃未來一段時間內的安全、 舒適、 正確的軌跡。

控制模型主要由常規工況和降級工況組成， 其中常規工況主要針對 ODD（運行設計域）以內的動態駕駛任務， 降級工況主要針對發生系統性失效或者超出 ODD 以外的動態駕駛任務， 均需要進行輸入處理、 狀態決策、 控制計算及執行輸出等。針對上游及底盤信息的輸入，以及控制輸出均需要適配層去匹配不同的功能算法框架平臺及車輛平臺；針對橫縱向及緊急控制等算法模塊需要進行故障診斷、 配置及標定接口模塊統一管理。

（2）智能座艙通用模型

a. 智能語音識別框架

智能語音交互主要涵蓋語音喚醒、 語音識別、 自然語言理解、 語音合成等技術， 核心是自然語言處理（NLP） 。智能座艙語音交互應用主要是語音助手， 不同于早期的只能撥打電話或簡單地識別幾個單詞， 自然語音識別一般指可以識別一個句子， 語音助手則是基于自然語義的理解并做出對應的調整或給出對應的響應。智能座艙域將 NLP 技術（含自然語言理解、 自然語言生成） 封裝成服務框架， 為座艙各類智能語音交互提供 API 接口。

b. 智能視覺識別框架

在智能座艙領域， 計算機視覺使用深度學習等先進技術， 配合攝像頭和顯示器等輸入輸出設備， 結合專業的 AI 計算芯片， 及時有效地存儲、 傳輸、 處理圖像信息， 幫助大幅度提升信息轉化效率和用戶體驗。計算機視覺的底層技術可分為全圖檢測、 目標跟蹤、 分類識別（粗細粒度） 、 Re-ID（行人重識別技術） 、 視頻理解、 3D 感知及特定任務回歸等。結合應用可以進一步擴展為人體部位檢測、 活體檢測、 行為分類、 人臉識別、 手勢識別和視線跟蹤等方向， 這些視覺感知結果為座艙的人機交互及圖像識別提供了基礎能力。

座艙域控針對智能視覺識別框架封裝服務接口， 提供手勢識別服務支持手勢交互。同時也提供人臉圖像識別接口， 支持 DMS（駕駛員監測系統） 和 OMS（乘客監測系統） 等智能應用。

c. 多模智能交互框架

基于語音和視覺的多模智能交互是提升車載智能 HMI 體驗的關鍵技術， 其核心是多模態交互， 對應技術是多模感知的算法融合技術， 從被動交互走向主動交互， 實現個性化推薦、多模意圖理解、 多模態輸出等。

多模語音是典型的多模融合技術， 該技術深度融合了語音和唇部圖像信息， 有非常明顯的優點， 無論語音前端和后端都可以借助于多模技術提升算法性能。多模語音技術的主要優點主要體現在圖像信息的引入、 誤喚醒的控制以及音區個數的增加。

隨著車載終端 AI 芯片的豐富算力能支持視頻流和音頻流的實時處理， 結合視覺輔助的多模語音方案正成為技術演進的趨勢。相較于純語音算法日益趨緩的發展， 多模語音方案不僅能夠帶來高噪聲場景下指標的顯著提升， 解決高噪環境語音方案難用的傳統痛點， 極大提高用戶體驗。

座艙域控針對多模智能交互框架封裝服務接口， 提供手勢、 語音識別的融合服務。同時也提供人臉圖像識別接口， 支持 DMS（駕駛員疲勞監測系統） 和 OMS（乘客監測系統） 等智能應用。

d. HMI 展示框架

智能座艙 HMI 人機交互界面逐步朝著大屏、 多屏、 酷炫、 智能等方向發展， 針對不同形式的 HMI 展示需要， 統一封裝一套強大的 MVC（模型視圖控制器） 展示框架尤為必要。近年來中科創達提供的 Kanzi 展示框架在座艙車機領域應用廣泛， Kanzi 框架包括 KANZI Studio 和 KANZI Engine， 以及由 KANZI Connect、 KANZI Maps、 KANZI Particles、 KANZI Autostereoscopy 構成的功能包， 如下圖所示?；?Kanzi 框架進行服務化封裝， 可以支撐 3D 儀表、 HUD 抬頭顯示、 AR 導航等應用的酷炫效果展示。

Kanzi 框架示意

安全域基礎應用

安全域是指同一系統內有相同的安全保護需求， 相互信任， 并具有相同的安全訪問控制和邊界控制策略的子網或網絡。將安全需求相同的接口進行分類， 并劃分到不同的安全域，能夠實現域間策略的統一管理。例如車內網系統對外的安全接口包括了：近場通訊（wifi/bluetooth/rke/pke/） 、 遠端通訊（4g/5g/gps） 、 對外物理連接節點（bms） 、 對外物理連接端口（obd、 USB 等） 。針對車內通信數據進行傳輸控制， 車載通信架構中引入防火墻，在整車架構外圍及各安全域層之間進行監控隔離， 根據既定的安全策略（如黑/白名單） 對通信通路進行可靠性管理。

管理平面

管理平面是汽車操作系統實現的設計基石。管理平面是復雜嵌入式系統的通用概念， 包含日志、 管理、 配置、 監控等非強實時功能， 存在于每個硬件單元。數據平面是實時控制平面， 實現自動駕駛操作系統的主要功能和數據處理， 運行自動駕駛通用數據、 實時狀態監控、數據收集、 失效切換、 網聯、 云控等功能模塊。

API

應用程序接口可以是基于面向服務（SOA） 的訂閱形式架構， 也可以是使用統一開發接口 （API） 函數調用的形式， 使用這些應用軟件接口和 SDK（軟件開發工具包） 可以進行高效、 靈活、 敏捷的定制化開發。

四、軟件遠程升級

在軟件定義汽車的時代， 汽車安裝了大量的軟件程序， 從而變得越來越智能， 但當出現一個程序問題或者更新升級時， 傳統模式將是一項繁重的任務， 而遠程升級技術會是解決汽車軟件程序/系統升級的難題的有效方案。

汽車遠程升級， 又稱為 OTA（Over-the-air， 空中下載技術） ， 是指通過移動通信網絡（3G/4G/5G 或 WiFi 等） ， 對零部件終端上固件、 數據及應用等“軟件”進行遠程管理的技術。OTA 貫穿了汽車軟件系統最上層的應用軟件、 云服務， 直到最底層的系統軟件層， 縱向跨越了軟件不同層次， 將深刻影響汽車軟件的開發和更新迭代。

汽車 OTA 可分兩類：一是 SOTA（Software-over-the-air， 軟件在線升級） ， 在操作系統的基礎上對應用程序進行升級， 例如 UI 界面、 車載地圖、 人機交互界面等。二是 FOTA（Firmware-over-the-air 即固件在線升級） ， 在不改變車輛原有配件的前提下， 通過寫入新的固件程序進行設備升級， 比如通過 FOTA 新增自動駕駛功能等。

汽車 OTA 主要作用：一是降低汽車召回的成本。通過 OTA 修復部分軟件 BUG， 可以大大節省汽車廠家、 4S 店和車主的費用及時間成本。二是增加汽車新功能和體驗。具備 OTA功能的車輛在使用期間可以增加新人機交互方式或功能、 優化設備系統性能。三是拓展了汽車服務新空間。借助于 OTA， 整車企業在完成車輛銷售后可以繼續和車主產生互動， 并持續提升用戶體驗， 拓寬了車廠用戶運營及服務的范疇。

汽車 OTA 升級流程， 核心業務包括軟件包研制、 升級任務定義、 車端版本下載和刷新等部分。升級過程一般可分為三步， 首先將更新軟件上傳到 OTA 中心， 然后 OTA 中心無線傳輸更新軟件到車輛端， 最后車輛端自動更新軟件。

汽車 OTA 業務可以劃分為 OTA 云端、 OTA 車端和整車企業 IT 系統， 如下圖所示。OTA 的云平臺用以管理 OTA 的業務， 包括車型管理、 車輛管理、 零件管理、 升級固件管理、升級任務管理、 用戶管理、 數據統計等功能。OTA 的車端主要負責處理升級管理， 包括車端的人機交互、 升級包的下載、 升級條件判斷、 升級流程管理、 升級結果通知等。汽車 OTA 業務還可以與整車企業現有的 IT 系統做整合從而實現車廠信息化系統的統一建設。

汽車 OTA 業務

汽車 OTA 關鍵技術：

分布式部署

隨著以中央計算為核心的電子電氣架構的普及， 以及軟件定義汽車的普及， 要實現整車軟件升級， OTA 軟件功能將會在不同的域進行部署， 來滿足 OTA 的實時性與硬件資源的局限性。這就要求 OTA 軟件功能的設計具有可移植性， OTA 軟件的分布式設計技術尤為關鍵。

可靠性設計

容災備份：軟件包倉庫（軟件包文件） 及 OTA 云服務的關鍵數據（車輛、 ECU 檔案、最新版本號等） 需要支持災備， 通過在不同數據中心、 甚至不同城市之間做備份。

加密及認證：加密和認證機制保證升級包完整可靠。

支持斷電續傳、 斷電續升：車端 OTA 升級代理從云端下載升級包時， 需要支持斷電/短鏈續傳功能， 和具體實現方式， 比如可以將升級包切分為多個數據塊， 每次下載之后記錄當前最新的塊序號， 續傳時從最新的塊序號開始下載即可。斷電續升是指車端升級代理刷寫ECU 固件包時， 斷電恢復后可以按最新版本數據位置繼續刷寫。

支持 A/B 塊升級策略：在車端 ECU 模塊中， 只是先向備用目錄刷寫版本包， 刷寫成功后再重啟切換加載位置（bootloader 中控制） ， 通過這種方式實現 A/B 塊升級策略。如果升級后出現問題， 可以確?？焖侔踩赝?。此外， 車端針對同類 ECU， 支持灰度升級策略， 即先升級一個 ECU， 驗證正常后再批量刷寫同類型的其他各個 ECU。

支持升級回退：對于升級異?；虺晒Φ那闆r都支持回退操作， 恢復到升級前的版本。

支持重復升級：支持同版本號多次重復刷寫， 主要應用場景是對于升級結果不可信的情況， 可以多次嘗試， 確保升級結果可信。

差分升級

差分升級又稱“增量升級”， 就是升級時并不會把所有的文件全部進行替換， 而只是替換那些需要更新的文件。過程分為：

（1）從兩個升級包通過差分工具， 利用差分算法生成差分包。

（2）在設備端升級時， 通過還原算法把差分包還原后再進行升級。

差分升級與整包升級相比， 優勢在于升級包的大小減少， 縮減了下載時間節省了網絡流量；劣勢在于在升級過程的處理上更為復雜， 流程控制上需要更嚴謹。

無感升級

無感升級是指在系統升級過程中， 對于用戶使用車輛沒有影響。這種升級方式常用于車輛的智能設備， 目前市場上多數案例還是集中體現在座艙域。無感升級對于設備的要求較高，需要有 A/B 兩套均可正常工作的系統分區。例如， 在域控制器內進行內存分區， 一個區用于升級， 一個區用于車輛正常運行， 可實現在 A 系統正常提供各種應用功能的情況下， 去升級 B 系統， 從而在升級期間不影響車輛使用。對于集成了復雜功能的域控設備的車輛， 無感升級可大大縮短車輛用戶可感知的升級時間， 減小了駐車升級時對車輛電量的消耗， 縮短了車輛不可用時間， 也保證了系統始終的可用性。不過， 在車輛運行時執行完成 B 系統的升級過程， 對設備系統的性能與安全性也提出了很高的要求。尤其是在 FOTA 層面， 例如實現傳統的電子控制單元 ECU 的“無感升級”， 一方面需要解決數據包傳輸的問題， 另一方面 ECU 本身要支持類似于“A/B”的系統特性， 提供備份冗余， 或者實現軟件內容 A/B 區域的地址映射。

OTA 通信協議

OTA 的通信協議主要包括車云的通信協議， 與車內控制器之間的通信協議。隨著新的汽車電子電氣架構的發展， 以及以中央計算為核心的電子電氣架構的普及， OTA 的車云通信協議需要實現標準化， 用于普及未來汽車軟件生態的共享。同時通過統一的通信協議， 更好的監管 OTA 的升級記錄與 OTA 的安全流程。

從應用現狀來看， 目前僅有少數車型能夠提供整車 FOTA， 大多數車型能夠做到的 OTA還只是將軟件升級包發送至車內的 T-BOX， 而不能實現 ECU 層面的軟件升級。FOTA 能夠深層次改變汽車控制系統、 管理系統及性能表現， 比 SOTA 在技術實現上難度更大。FOTA 涉及控制器核心功能（控制策略） 的系統性更新， 對整車性能影響較大， 升級過程對時序、 穩定性、 安全性要求極高， 同時升級前置條件包括擋位、 電量、 車速等要求， 因而升級過程一般不支持車輛運行， 也就是前文提及的“無感升級”在 FOTA 層面的實現頗具挑戰。作為車輛應用軟件的底層載體， 操作系統是汽車 OTA 得以實現的關鍵支撐技術， 尤其 FOTA 固件更新。

審核編輯：湯梓紅