智能網(wǎng)聯(lián)汽車電子電氣架構(gòu)(中)

作者 / 阿寶，出品 / 阿寶1990

一、整體軟件架構(gòu)

汽車電子電氣架構(gòu)正在由傳統(tǒng)的分布式架構(gòu)向域集中式和中央集中式演進， 并繼續(xù)演進至車路云一體化協(xié)同。智能網(wǎng)聯(lián)汽車整體軟件架構(gòu)需要采用 SOA 分層思路構(gòu)建， 從下往上，分為系統(tǒng)軟件層、 功能軟件層、 應用軟件層， 以及云平臺。其中， 系統(tǒng)軟件與功能軟件構(gòu)成了廣義上的操作系統(tǒng)（本文中， 沒有特別強調(diào)說明的“操作系統(tǒng)”， 均指廣義操作系統(tǒng)。如下圖 智能網(wǎng)聯(lián)汽車軟件架構(gòu)中紅色線框內(nèi)所示） ， 是汽車軟件的基礎。

此外， 汽車軟件一般要配合專業(yè)的硬件平臺來運行， 硬件平臺為基于高性能芯片搭建的異構(gòu)分布式硬件運行環(huán)境， 具有選型靈活、 配置可插擴、 算力可堆砌等特點。

智能網(wǎng)聯(lián)汽車軟件架構(gòu)

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

功能軟件是根據(jù)面向服務的架構(gòu)設計理念， 通過提取智能網(wǎng)聯(lián)汽車核心共性需求， 形成各共性服務功能模塊， 高效實現(xiàn)智能網(wǎng)聯(lián)功能開發(fā)的軟件模塊。主要包括數(shù)據(jù)抽象、 通用框架、 通用模型、 API， 以及安全域基礎應用和管理平面。

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

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

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

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

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

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

智駕域控制器軟件架構(gòu)示意圖

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

Adaptive AUTOSAR R21-11 規(guī)范框架

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

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

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

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

二、系統(tǒng)軟件

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

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

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

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

虛擬化技術(shù)示意

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

Hypervisor 類型

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

全虛擬化與半虛擬化

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

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

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

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

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

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

2.2 內(nèi)核

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

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

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

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

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

OSEK/VDX OS， 主要用于安全車控操作系統(tǒng) ?

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

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

微內(nèi)核 RTOS， 用于智能駕駛操作系統(tǒng)和安全車控操作系統(tǒng)

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

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

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

Safety Linux OS， 用于智能駕駛操作系統(tǒng)和智能座艙操作系統(tǒng) ?

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

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

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

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

Android Automotive OS， 主要用于智能座艙操作系統(tǒng)

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

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

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

總體而言， 智能駕駛操作系統(tǒng)與智能座艙操作系統(tǒng)將是未來發(fā)展重點， 其內(nèi)核發(fā)展分別呈現(xiàn)如下趨勢。

2.2.1 智能駕駛操作系統(tǒng)內(nèi)核??

（1）宏內(nèi)核 Linux 的安全能力增強 ?

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

（2） 微內(nèi)核生態(tài)支持能力拓展 ?

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

智能座艙操作系統(tǒng)內(nèi)核

（1）支持多樣化應用 ?

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

（2） 多生態(tài)資源

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

（3）安全性

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

2.3 中間件

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

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

三、功能軟件

數(shù)據(jù)抽象

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

通用框架 ?

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

（1）數(shù)據(jù)流

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

（2）基礎服務

基礎服務是功能軟件層共用的基本服務， 其主要服務于通用模型或功能應用， 比如網(wǎng)聯(lián)服務、 數(shù)據(jù)服務、 OTA、 地圖服務等。

通用模型

（1）智能駕駛通用模型

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

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

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

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

（2）智能座艙通用模型 ?

a. 智能語音識別框架

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

b. 智能視覺識別框架

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

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

c. 多模智能交互框架

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

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

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

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

d. HMI 展示框架

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

Kanzi 框架示意

安全域基礎應用

安全域是指同一系統(tǒng)內(nèi)有相同的安全保護需求， 相互信任， 并具有相同的安全訪問控制和邊界控制策略的子網(wǎng)或網(wǎng)絡。將安全需求相同的接口進行分類， 并劃分到不同的安全域，能夠?qū)崿F(xiàn)域間策略的統(tǒng)一管理。例如車內(nèi)網(wǎng)系統(tǒng)對外的安全接口包括了：近場通訊（wifi/bluetooth/rke/pke/） 、 遠端通訊（4g/5g/gps） 、 對外物理連接節(jié)點（bms） 、 對外物理連接端口（obd、 USB 等） 。針對車內(nèi)通信數(shù)據(jù)進行傳輸控制， 車載通信架構(gòu)中引入防火墻，在整車架構(gòu)外圍及各安全域?qū)又g進行監(jiān)控隔離， 根據(jù)既定的安全策略（如黑/白名單） 對通信通路進行可靠性管理。

管理平面

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

API

應用程序接口可以是基于面向服務（SOA） 的訂閱形式架構(gòu)， 也可以是使用統(tǒng)一開發(fā)接口 （API） 函數(shù)調(diào)用的形式， 使用這些應用軟件接口和 SDK（軟件開發(fā)工具包） 可以進行高效、 靈活、 敏捷的定制化開發(fā)。

四、軟件遠程升級

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

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

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

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

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

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

汽車 OTA 業(yè)務

汽車 OTA 關(guān)鍵技術(shù)：

分布式部署

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

可靠性設計

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

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

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

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

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

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

差分升級

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

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

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

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

無感升級

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

OTA 通信協(xié)議 ?

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

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