作者 / 阿寶

出品/阿寶1990

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、系統(tǒng)軟件

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

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

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

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

虛擬化技術(shù)示意

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

Hypervisor 類型

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

全虛擬化與半虛擬化

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

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

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

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

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

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

2.2 內(nèi)核

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）支持多樣化應(yīng)用

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

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

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

（3）安全性

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

2.3 中間件

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

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

三、功能軟件

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

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

通用框架

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

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

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

（2）基礎(chǔ)服務(wù)

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

通用模型

（1）智能駕駛通用模型

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

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

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

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

（2）智能座艙通用模型

a. 智能語音識(shí)別框架

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

b. 智能視覺識(shí)別框架

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

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

c. 多模智能交互框架

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

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

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

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

d. HMI 展示框架

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

Kanzi 框架示意

安全域基礎(chǔ)應(yīng)用

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

管理平面

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

API

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

四、軟件遠(yuǎn)程升級

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

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

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

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

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

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

汽車 OTA 業(yè)務(wù)

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

分布式部署

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

可靠性設(shè)計(jì)

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

加密及認(rèn)證：加密和認(rèn)證機(jī)制保證升級包完整可靠。

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

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

支持升級回退：對于升級異常或成功的情況都支持回退操作， 恢復(fù)到升級前的版本。

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

差分升級

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

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

（2）在設(shè)備端升級時(shí)， 通過還原算法把差分包還原后再進(jìn)行升級。

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

無感升級

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

OTA 通信協(xié)議

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

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

審核編輯：湯梓紅