一、智能汽車(chē)基礎(chǔ)軟件平臺(tái)分類(lèi)

汽車(chē)軟件主要分為應(yīng)用軟件和基礎(chǔ)軟件。應(yīng)用軟件和業(yè)務(wù)形態(tài)高度關(guān)聯(lián)，不同控制器的應(yīng)用軟件之間差異較大。基礎(chǔ)軟件介于應(yīng)用軟件和硬件之間，用于屏蔽硬件特性、支撐應(yīng)用軟件?？捎行У貙?shí)現(xiàn)應(yīng)用軟件與硬件之間解耦，非常適合平臺(tái)化最終形成基礎(chǔ)軟件平臺(tái)。

根據(jù)中國(guó)汽車(chē)基礎(chǔ)軟件發(fā)展白皮書(shū)3.0所描述，車(chē)用 基礎(chǔ)軟件平臺(tái)分為車(chē)用基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)和車(chē)用基礎(chǔ)軟件驗(yàn)證平臺(tái)。其中，基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)包含內(nèi)核、虛擬化模塊，中間件，功能軟件以及與之相配套的開(kāi)發(fā)工具鏈，用于支撐應(yīng)用軟件的快速迭代開(kāi)發(fā)。基礎(chǔ)軟件驗(yàn)證平臺(tái)通過(guò)調(diào)試、分析、仿真、測(cè)試等手段驗(yàn)證設(shè)計(jì)和實(shí)現(xiàn)的一致性。

1.1 安全車(chē)控基礎(chǔ)軟件平臺(tái)

安全車(chē)控基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)主要面向車(chē)輛經(jīng)典控制領(lǐng)域，如動(dòng)力系統(tǒng)、底盤(pán)系統(tǒng)和車(chē)身系統(tǒng)等，該類(lèi)基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)對(duì)實(shí)時(shí)性和安全性的要求極高。目前，主流的安全車(chē)控基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)兼容 OSEK/ VDX 或 Classic AUTOSAR 標(biāo)準(zhǔn)，其功能安全等級(jí)需要達(dá)到 ASIL-D。

1.2 自動(dòng)駕駛基礎(chǔ)軟件平臺(tái)

自動(dòng)駕駛基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)主要面向智能駕駛領(lǐng)域，用于智能駕駛輔助，以及全自動(dòng)駕駛功能的控制器上。目前智能駕駛控制器主要使用的底層操作系統(tǒng)有 QNX 以及 Linux。
與安全車(chē)控基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)相比，對(duì)智能駕駛基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)的要求主要體現(xiàn)在：

• 強(qiáng)大的計(jì)算能力，以滿足圖像識(shí)別和決策計(jì)算的要求；
• 強(qiáng)大的數(shù)據(jù)吞吐能力，以滿足多傳感器數(shù)據(jù)的實(shí)時(shí)接入和處理要求；
• 高度的靈活性、擴(kuò)展性、可編程性，以滿足多種算法模型的需要；
• 易用性，以滿足 ADAS 和自動(dòng)駕駛算法所需調(diào)試、調(diào)優(yōu)、調(diào)測(cè)的需要

當(dāng)前異構(gòu)分布硬件各單元所要求的功能安全等級(jí)有所不同，AI 單元需要達(dá)到 QM 至 ASIL-B，計(jì)算單元需要達(dá)到 QM 至 ASIL-D。

1.3 信息娛樂(lè)基礎(chǔ)軟件平臺(tái)

車(chē)載信息娛樂(lè)基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)主要為車(chē)載信息娛樂(lè)服務(wù)以及車(chē)內(nèi)人機(jī)交互提供控制平臺(tái)，是汽車(chē)實(shí)現(xiàn)座艙智能化與多源信息交互的必要運(yùn)行環(huán)境。

車(chē)載信息娛樂(lè)基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)對(duì)于實(shí)時(shí)性、安全性、可靠性的要求處于中等水平，既可以使用 Android、Linux 等非實(shí)時(shí)操作系統(tǒng)，也可以使用 QNX、VxWorks 等實(shí)時(shí)操作系統(tǒng)。為便于應(yīng)用程序移植，當(dāng)前越來(lái)越多的車(chē)載信息娛樂(lè)基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)采用 Android Automotive OS 或其他類(lèi) Linux 系統(tǒng)。

隨著車(chē)輛由單純的交通工具向智能移動(dòng)終端轉(zhuǎn)變，車(chē)載信息娛樂(lè)基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)需要滿足如下要求：

• 支持多樣化應(yīng)用，滿足支付、娛樂(lè)、導(dǎo)航、信息服務(wù)等多樣化功能需求
• 支持多生態(tài)資源，將手機(jī)端龐大的信息娛樂(lè)服務(wù)生態(tài)資源，通過(guò)采用相同或類(lèi)似的操作系統(tǒng)，快速移植到車(chē)輛智能終端，避免重復(fù)開(kāi)發(fā)
• 安全，通過(guò)深度定制達(dá)到車(chē)輛信息安全和功能安全的標(biāo)準(zhǔn)

1.4 智能座艙軟件全景

隨著新能源汽車(chē)的快速普及，智能座艙成為了一個(gè)重要的研發(fā)方向。智能座艙是汽車(chē)內(nèi)部的控制中心，可以提供多種信息和服務(wù)，包括車(chē)輛狀態(tài)、導(dǎo)航、娛樂(lè)等功能。為了實(shí)現(xiàn)這些功能，智能座艙需要一個(gè)可靠、高效的軟件平臺(tái)來(lái)支持。

對(duì)于智能座艙軟件來(lái)說(shuō)，主要的功能定義就是上述信息娛樂(lè)基礎(chǔ)軟件平臺(tái)。

在智能座艙的軟件平臺(tái)中，操作系統(tǒng)內(nèi)核、中間件和虛擬化技術(shù)都是非常重要的組成部分。其中，操作系統(tǒng)內(nèi)核是整個(gè)軟件平臺(tái)的基礎(chǔ)，它負(fù)責(zé)管理硬件資源、提供系統(tǒng)調(diào)用和進(jìn)程管理等功能。常見(jiàn)的操作系統(tǒng)內(nèi)核有Linux、QNX、RTOS等。

在智能座艙的軟件平臺(tái)中，中間件是連接不同組件的重要工具。中間件可以提供消息傳遞、進(jìn)程通信、遠(yuǎn)程調(diào)用等服務(wù)，從而方便系統(tǒng)的開(kāi)發(fā)和維護(hù)。優(yōu)化中間件可以提高系統(tǒng)的可靠性和性能。

虛擬化技術(shù)是將物理資源虛擬化為多個(gè)邏輯實(shí)例的技術(shù)。在智能座艙中，虛擬化技術(shù)可以用于隔離不同的系統(tǒng)組件，提高整個(gè)系統(tǒng)的可靠性和安全性。常見(jiàn)的虛擬化技術(shù)包括Hypervisor和容器技術(shù)。Hypervisor是一種虛擬化技術(shù)，它可以將物理服務(wù)器虛擬化為多個(gè)虛擬機(jī)，從而提高整個(gè)系統(tǒng)的可擴(kuò)展性和靈活性。而容器技術(shù)則是將操作系統(tǒng)層面進(jìn)行虛擬化，從而提高系統(tǒng)的性能和資源利用率。

二、車(chē)用操作系統(tǒng)

2.1 AutoSAR CP

AUTOSAR CP 是 Classical Platform AUTOSAR 的簡(jiǎn)稱，廣泛用于對(duì)實(shí)時(shí)性、安全性要求高的動(dòng)力域控、底盤(pán)域控、車(chē)身域控等方面，以達(dá)到軟硬件解耦、提高開(kāi)發(fā)效率、提升軟件復(fù)用性等目的。
在智能汽車(chē)軟件平臺(tái)領(lǐng)域方面，AUTOSAR CP一般不用于信息娛樂(lè)域。本文只簡(jiǎn)要介紹AutoSAR CP的基本概念，不做詳細(xì)解讀。

• AutoSAR CP的軟件分層架構(gòu)

在 AUTOSAR CP 分層架構(gòu)中，自上而下分別為應(yīng)用軟件層（Application Layer）、運(yùn)行時(shí)環(huán)境 （Runtime Environment）、基礎(chǔ)軟件層（Basic Software Layer）

AutoSAR CP Arch

應(yīng)用軟件層：

包含若干個(gè)軟件組件，軟件組件間通過(guò)端口進(jìn)行交互。每個(gè)軟件組件可以包含一個(gè)或者多個(gè)運(yùn)行實(shí)體，運(yùn)行實(shí)體中封裝了相關(guān)控制算法，其運(yùn)行可由 RTE 事件觸發(fā)。

運(yùn)行時(shí)環(huán)境：

作為應(yīng)用軟件層與基礎(chǔ)軟件層交互的橋梁，為軟硬件分離提供了可能，是 VFB 的具體實(shí)現(xiàn)。 RTE 可以實(shí)現(xiàn)軟件組件間、基礎(chǔ)軟件間以及應(yīng)用軟件組件與基礎(chǔ)軟件之間的通信。RTE 封裝了基礎(chǔ)軟件層的服務(wù)、提供了標(biāo)準(zhǔn)化接口，使得應(yīng)用軟件層可以通過(guò) RTE 接口調(diào)用基礎(chǔ)軟件服務(wù)。此外 RTE 抽象了 ECU 之間的通信，即 RTE 使用標(biāo)準(zhǔn)化接口將 ECU 之間的通信抽象為軟件組件之間的通信。

基礎(chǔ)軟件層：

又可分為四層，包括服務(wù)層、ECU 抽象層、微控制器抽象層和復(fù)雜驅(qū)動(dòng)。各層又由一系列基礎(chǔ)軟件組件構(gòu)成，包括系統(tǒng)服務(wù)、存儲(chǔ)服務(wù)、通信服務(wù)等，它們主要用于提供標(biāo)準(zhǔn)化的基礎(chǔ)軟件服務(wù)。

1. 服務(wù)層提供了汽車(chē)嵌入式系統(tǒng)軟件常用的一些服務(wù)，包括系統(tǒng)服務(wù)、存儲(chǔ)服務(wù)以及通信服務(wù)三大部分。 還提供包括網(wǎng)絡(luò)管理、存儲(chǔ)管理、模式管理和實(shí)時(shí)操作系統(tǒng)等服務(wù)。
2. ECU 抽象層與 ECU 平臺(tái)相關(guān)，但與 微控制器無(wú)關(guān)，包括板級(jí)硬件抽象、存儲(chǔ)硬件抽象、通信硬件抽象和 I/O 硬件抽象。該層將 ECU 結(jié)構(gòu)進(jìn) 行了抽象，負(fù)責(zé)提供統(tǒng)一的訪問(wèn)接口，實(shí)現(xiàn)對(duì)通信、存儲(chǔ)器或者 I/O 的訪問(wèn)，從而不需要考慮這些資源是由微控制器片內(nèi)還是片外提供的。
3. 微控制器抽象層是實(shí)現(xiàn)不同硬件接口統(tǒng)一化的特殊層，包括微控制器驅(qū)動(dòng)、存儲(chǔ)驅(qū)動(dòng)、通信驅(qū)動(dòng)以及 I/O 驅(qū)動(dòng)。通過(guò)微控制器抽象層可將硬件封裝起來(lái)，避免上層軟件直接對(duì)微控制器的寄存器進(jìn)行操作。
4. 最后，由于對(duì)復(fù)雜傳感器和執(zhí)行器進(jìn)行操作的模塊涉及嚴(yán)格的時(shí)序問(wèn)題， 難以抽象，所以在 AUTOSAR CP 規(guī)范中沒(méi)有被標(biāo)準(zhǔn)化，統(tǒng)稱為復(fù)雜驅(qū)動(dòng)。

如上所述，AUTOSAR CP 良好的分層架構(gòu)為軟硬件之間解耦、軟件模塊之間解耦提供了堅(jiān)實(shí)的保障。

• AutoSAR CP的發(fā)展歷程

對(duì)于傳統(tǒng)汽車(chē)電子開(kāi)發(fā)領(lǐng)域，早期使用的OS是OSEK OS, 其中OSEK是德文“Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug”的縮寫(xiě)，譯為汽車(chē)電子開(kāi)放系統(tǒng)及接口。OSEK OS是一個(gè)為滿足汽車(chē)電子可靠性、實(shí)時(shí)性、成本敏感性等需求而打造的實(shí)時(shí)單核操作系統(tǒng)(RTAOS)。

AUTOSAR CP 與 OSEK OS聯(lián)系 ：

首先，AUTOSAR CP是基于OSEK OS繼承發(fā)展而來(lái)，所以上述的OSEK OS的基本特點(diǎn)在AUTOSAR CP都能夠得到滿足，所以AUTOSAR CP是向后兼容的，也就意味著在OSEK OS上能夠運(yùn)行的應(yīng)用程序同樣也可以在AUTOSAR CP上運(yùn)行。

除此之外，AUTOSAR CP也存在自身的一些獨(dú)特的基本特點(diǎn)，下面將從基本屬性與系統(tǒng)基本服務(wù)兩個(gè)方面對(duì)比OSEKOS 與AutoSAR CP：

• AutoSAR CP 的優(yōu)缺點(diǎn)

1. 架構(gòu)充分解耦導(dǎo)致標(biāo)準(zhǔn)和接口規(guī)范繁多。AUTOSAR CP 的規(guī)范文檔非常詳盡，但正是兩百多個(gè)多達(dá)幾萬(wàn)頁(yè)的標(biāo)準(zhǔn)文檔讓一些傳統(tǒng)的嵌入式工程師望而止步。同時(shí) AUTOSAR CP 提出了很多新概念，比如標(biāo)定量通過(guò)描述文件進(jìn)行描述；應(yīng)用接口不通過(guò)傳統(tǒng)全局變量的方式與底層軟件交互，而是 對(duì)接口進(jìn)行描述定義通過(guò) RTE 統(tǒng)一接口進(jìn)行匹配等。AUTOSAR CP 的軟件開(kāi)發(fā)理念和傳統(tǒng)嵌入式工程師的認(rèn)知偏差也是其普及率不高的原因之一。
2. 工具鏈價(jià)格昂貴。目前AutoSAR CP的工具鏈都是老牌經(jīng)典的AutoSAR OS公司所有，軟件授權(quán)和開(kāi)發(fā)費(fèi)用非常高。
3. 工具鏈之間兼容性差影響合作開(kāi)發(fā)的靈活性。由于各廠商對(duì) AUTOSAR CP 規(guī)范的理解并不完全一致，而且各廠商的工具也并不完全兼容，導(dǎo)致 OEM 集成各家供應(yīng)商開(kāi)發(fā)的軟件模塊需要花費(fèi)大量的精力和時(shí)間。
4. 自動(dòng)化程度低導(dǎo)致開(kāi)發(fā)和集成效率偏低?；A(chǔ)軟件與應(yīng)用軟件的接口集成需要大量的手動(dòng)配置工 作，不僅操作上低效出錯(cuò)率高，而且在錯(cuò)誤檢查方面也不如傳統(tǒng)軟件集成方便。
5. 代碼可讀性差導(dǎo)致調(diào)試?yán)щy。這是代碼生成工具普遍存在的問(wèn)題，和 MATLAB 的 AUTOSAR 工 具箱生成的代碼一樣，一些 AUTOSAR 工具鏈的 RTE 代碼生成工具生成的代碼可讀性也較差，這給軟件 調(diào)試帶來(lái)了不少麻煩。

2.2 AutoSAR AP

在基于域的EEA架構(gòu)體系中，智能座艙域通常使用Linux 或者Android作為操作系統(tǒng)；車(chē)身控制域一般使用AutoSAR CP；自動(dòng)駕駛域通常使用Linux或者QNX。

新能源汽車(chē)在由分布式EE架構(gòu)向中央計(jì)算-區(qū)域控制EE架構(gòu)發(fā)展的過(guò)程中，一些廠商認(rèn)為，需要在中央計(jì)算平臺(tái)中提供一個(gè)高靈活，高性能且支持SOA的新軟件平臺(tái)-- Adaptive Platform AutoSAR，簡(jiǎn)稱AutoSAR AP。

• 什么是AutoSAR AP

AUTOSAR 組織在 2017 年推出了新的 AUTOSAR 平臺(tái)—— AUTOSAR AP。AUTOSAR AP 的出現(xiàn)是為了填補(bǔ)高性能計(jì)算平臺(tái)上缺乏好用中間件的空白，采用面向?qū)ο蟮?SOA 架構(gòu)，旨在為上層應(yīng)用提供靈活的軟件開(kāi)發(fā)平臺(tái)；同時(shí)利用汽車(chē)行業(yè)經(jīng)驗(yàn)和優(yōu)勢(shì)，讓所有汽車(chē)軟件能持續(xù)迭代，更快更好地量產(chǎn)上車(chē)。

不同于傳統(tǒng)的AutoSAR CP，它們的主要區(qū)別在于：

AUTOSAR經(jīng)典平臺(tái)（CP）標(biāo)準(zhǔn)滿足了深度嵌入式ECU的需求，而智能ECU的需求卻無(wú)法滿足。傳統(tǒng)ECU的設(shè)計(jì)目的是專(zhuān)為目標(biāo)車(chē)輛而設(shè)計(jì)，在車(chē)輛使用壽命期間不會(huì)有特別大的改動(dòng)。智能ECU則適應(yīng)新型EE架構(gòu)的發(fā)展，引入了以太網(wǎng)，高性能計(jì)算平臺(tái)，以及OTA軟件升級(jí)等。因此，AUTOSAR主持修訂了第二個(gè)軟件平臺(tái)規(guī)范，AUTOSAR自適應(yīng)平臺(tái)（AP）。AP主要提供高性能的計(jì)算和通信機(jī)制，并提供靈活的軟件配置，例如支持空中軟件更新。專(zhuān)門(mén)為CP定義的功能，如訪問(wèn)電信號(hào)和汽車(chē)專(zhuān)用總線系統(tǒng)，可以集成到AP中，但不在標(biāo)準(zhǔn)化的重點(diǎn)中。

• AutoSAR AP的分層架構(gòu)

AutoSAR AP的基本構(gòu)成包括應(yīng)用程序?qū)?、運(yùn)行時(shí)層、操作系統(tǒng)和硬件抽象層。這些組件通過(guò)標(biāo)準(zhǔn)化的接口進(jìn)行通信和協(xié)作，以實(shí)現(xiàn)整個(gè)AUTOSAR Adaptive Platform的功能。

1.應(yīng)用程序?qū)?#xff08;Application Layer）：

應(yīng)用程序?qū)邮茿UTOSAR Adaptive Platform中的最高層，它包括了所有的應(yīng)用程序組件。應(yīng)用程序?qū)油ㄟ^(guò)服務(wù)層和運(yùn)行時(shí)層與其他組件進(jìn)行通信和協(xié)作，以實(shí)現(xiàn)整個(gè)應(yīng)用程序的功能。User Application 通過(guò)原子服務(wù)接口(Atomic Service)獲取服務(wù)：Atomic Service 原子服務(wù)提供了一系列的標(biāo)準(zhǔn)化服務(wù)，例如通信服務(wù)、診斷服務(wù)、存儲(chǔ)服務(wù)等。這些服務(wù)為應(yīng)用程序組件提供了一些基本的功能和接口，以便它們能夠相互通信和協(xié)作。

2.運(yùn)行時(shí)層（Runtime Layer）：

運(yùn)行時(shí)層提供了一些基本的軟件組件和操作系統(tǒng)服務(wù)，例如操作系統(tǒng)抽象層、內(nèi)存管理、進(jìn)程管理等。這些組件和服務(wù)為應(yīng)用程序組件提供了一個(gè)運(yùn)行環(huán)境，以便它們能夠在AUTOSAR AP中運(yùn)行。

3.操作系統(tǒng)和硬件抽象層（Operating System Layer）：

AUTOSAR Adaptive Platform使用基于POSIX標(biāo)準(zhǔn)的操作系統(tǒng)，例如Linux。操作系統(tǒng)層提供了一些基本的操作系統(tǒng)服務(wù)和驅(qū)動(dòng)程序，例如文件系統(tǒng)、網(wǎng)絡(luò)協(xié)議棧、設(shè)備驅(qū)動(dòng)程序等。這些服務(wù)和驅(qū)動(dòng)程序?yàn)檫\(yùn)行時(shí)層和應(yīng)用程序?qū)犹峁┝说讓拥闹С?。硬件抽象層則提供了一個(gè)通用的硬件接口，以便AUTOSAR Adaptive Platform可以在不同的硬件平臺(tái)上運(yùn)行。硬件抽象層將硬件平臺(tái)與操作系統(tǒng)層和運(yùn)行時(shí)層分開(kāi)，以便AUTOSAR Adaptive Platform可以在不同的硬件平臺(tái)上進(jìn)行移植和擴(kuò)展。

• AutoSAR AP的應(yīng)用場(chǎng)景

根據(jù)上述軟件架構(gòu)圖可見(jiàn)，AutoSAR AP主要作為中間件而存在，它支持POSIX操作系統(tǒng)，通過(guò)服務(wù)和API為上層服務(wù)提供功能。

在向中央集中式的計(jì)算平臺(tái)發(fā)展過(guò)程中，目前還按自動(dòng)駕駛域，車(chē)身和底盤(pán)域，智能座艙域等進(jìn)行功能劃分。這些域控制器均需得到高性能 MPU 芯片的支撐。基于 POSIX 系統(tǒng)之上的 AUTOSAR AP 平臺(tái)及相關(guān)工具鏈，為應(yīng)用開(kāi)發(fā)過(guò)程中的效率帶來(lái)顯著提高，而智能座艙域控制器從生態(tài)的角度考慮，一般在 Linux 基礎(chǔ)之上搭載安卓系統(tǒng)。而諸如 SOA 通信、整車(chē)診斷、健康管理的方面則可以參考 AUTOSAR AP 平臺(tái)標(biāo)準(zhǔn)進(jìn)行實(shí)現(xiàn)。如果考慮到多域融合的發(fā)展，在艙駕一體化的道路上，AutoSAR AP和Android將有很大的可能在Hypervisor的基礎(chǔ)上實(shí)現(xiàn)統(tǒng)一。

• AutoSAR AP的案例

基于AutoSAR AP的應(yīng)用場(chǎng)景，可以以一個(gè)OTA升級(jí)的案例來(lái)進(jìn)行講述。

本節(jié)主要介紹基于 AP 的智能域控制器（后續(xù)簡(jiǎn)稱 IDC）OTA 升級(jí)場(chǎng)景及其實(shí)現(xiàn)方案。

IDC 的 OTA 功能可以進(jìn)行自身應(yīng)用軟件及系統(tǒng)軟件、關(guān)聯(lián)器件固件的升級(jí)，并在數(shù)據(jù)管理、軟件升級(jí)、可追溯性、安全驗(yàn)證方面滿足 AP 的相關(guān)要求。

在OTA的功能實(shí)現(xiàn)過(guò)程中，IDC與外界的數(shù)據(jù)交互如圖所示。

云端OTA云服務(wù)器向車(chē)端HUT（終端信息展現(xiàn)單元 Head Unit & Telematics）推送升級(jí)任務(wù)，用戶確認(rèn)升級(jí)后，HUT 會(huì)通過(guò)網(wǎng)關(guān)向 IDC 及 其他 ECU 以 UDS 的形式發(fā)送升級(jí)指令及升級(jí)數(shù)據(jù)，IDC 接收升級(jí)指令與數(shù)據(jù)后，在確保安全的情況下 完成軟件升級(jí)并向 HUT 反饋安裝進(jìn)度及安裝結(jié)果。

1. 數(shù)據(jù)傳輸與管理

a. IDC 內(nèi)部分為 OTA 進(jìn)程和 UDS Server 進(jìn)程，UDS Server 進(jìn)程與 HUT 端交互，負(fù)責(zé)處理、轉(zhuǎn)發(fā) 指令和接收軟件包，OTA 進(jìn)程處理軟件包進(jìn)行升級(jí)。
b. OTA 使用專(zhuān)用的磁盤(pán)分區(qū)保證有足夠的資源來(lái)存儲(chǔ)軟件包及相關(guān)數(shù)據(jù)，從而保證數(shù)據(jù)的安全性。
c. IDC 會(huì)進(jìn)行完整性校驗(yàn)以保證軟件包的完整性。
d. OTA 結(jié)束后，IDC 會(huì)刪除臨時(shí)數(shù)據(jù)，最大限度節(jié)省空間。

2. 軟件升級(jí)

a. OTA 采用雙分區(qū)機(jī)制，通過(guò)活躍分區(qū)去升級(jí)備份分區(qū)，升級(jí)成功后重啟備份分區(qū)，完成備份分區(qū) 和活躍分區(qū)的互相切換，輕松實(shí)現(xiàn) IDC 上的應(yīng)用軟件、中間件、操作系統(tǒng)、配置數(shù)據(jù)的安裝、更新、刪除。
b. OTA 采用雙分區(qū)機(jī)制，通過(guò)切換啟動(dòng)分區(qū)，可以實(shí)現(xiàn) IDC 上所有軟件及數(shù)據(jù)的快速回滾功能。
c. OTA 支持周邊器件的升級(jí)，如 MCU、相機(jī)等。
d. OTA 內(nèi)部維護(hù)狀態(tài)機(jī)，狀態(tài)變化實(shí)時(shí)落盤(pán)，可以支持在異常中斷后恢復(fù)升級(jí)。

3. 可追溯性

a. OTA 提供獲取當(dāng)前軟件版本號(hào)、安裝進(jìn)度、安裝結(jié)果的接口。
b. OTA 會(huì)記錄升級(jí)過(guò)程中的日志，供 HUT 獲取。

4. 安全性

a. OTA 在軟件升級(jí)前會(huì)使用強(qiáng)加密算法校驗(yàn)證書(shū)鏈與軟件包簽名，保證軟件包的真實(shí)性及完整性。
b. OTA 在軟件升級(jí)前會(huì)檢查當(dāng)前車(chē)速、IDC 的溫度、供電情況，保證在安全的情況下進(jìn)行 IDC 軟件 升級(jí)。
c. OTA 時(shí)會(huì)激活 IDC 心跳監(jiān)控機(jī)制及分區(qū)損壞回滾機(jī)制，當(dāng)切換到備份分區(qū)啟動(dòng)失敗后，IDC 不會(huì) 給 MCU 發(fā)送心跳報(bào)文，MCU 會(huì)認(rèn)為 IDC 在 OTA 后變磚，會(huì)給 IDC 斷電重啟，切回原分區(qū)啟動(dòng)，保證車(chē)機(jī)可用。

2.3 虛擬化Hypervisor

• 為什么需要虛擬化

隨著汽車(chē)電子電氣架構(gòu)從分布式架構(gòu)到Domain域架構(gòu)，再到中央計(jì)算-區(qū)域控制架構(gòu)的演變，分散的ECU 功能集成到車(chē)載中央計(jì)算機(jī)，這就是多域融合的趨勢(shì)。 汽車(chē)電子底層硬件不再是由單一芯片提供簡(jiǎn)單的邏輯計(jì)算，而是需要復(fù)雜的多核 SoC 芯片提供更為復(fù)雜控制邏輯以及強(qiáng)大的算力支持。但是多域業(yè)務(wù)具有不同的技術(shù)需求，比如座艙域業(yè)務(wù)強(qiáng)調(diào)交互體驗(yàn)、應(yīng)用生態(tài)豐富，比較適合的操作系統(tǒng)是 Android；車(chē)控域有實(shí)時(shí)性、可靠性要求，操作系統(tǒng)傾向于 RTLinux、RTOS；智駕域強(qiáng)調(diào)大算力融合感知、推演規(guī)劃，也有實(shí)時(shí)性、可靠性要求，也會(huì)選擇RTLinux、RTOS。

在未來(lái)，多域融合技術(shù)集成到一顆SOC之上時(shí)，需要考慮關(guān)鍵業(yè)務(wù)的安全可靠和實(shí)時(shí)性技術(shù)要求，又要考慮到豐富的生態(tài)應(yīng)用，這些需要不同的操作系統(tǒng)才能支持。如何在一顆SOC上劃分資源，并發(fā)運(yùn)行多種操作系統(tǒng)，保證多域融合的可靠性，需要有資源隔離技術(shù)的支持。

資源隔離技術(shù)有多種，從硬件底層逐層向上包括硬件隔離、虛擬化隔離、容器隔離、進(jìn)程隔離等。硬件隔離的隔離性最好，性能、安全、可靠性都有保證；但靈活性、可配置性差，不能實(shí)現(xiàn)硬件共享， 導(dǎo)致整個(gè)系統(tǒng)的資源利用率差，不能充分達(dá)到軟件定義汽車(chē)的目標(biāo)。容器隔離、進(jìn)程隔離可以更輕量級(jí)地實(shí)現(xiàn)業(yè)務(wù)隔離，但還是在同一個(gè)操作系統(tǒng)內(nèi)，存在著資源干擾、相互安全攻擊的隱患，并且無(wú)法支持異構(gòu)操作系統(tǒng)業(yè)務(wù)域融合，影響傳統(tǒng)業(yè)務(wù)繼承，不利于生態(tài)發(fā)展。

目前，在智能座艙域的實(shí)際應(yīng)用中，硬件隔離和虛擬化隔離都有實(shí)際的使用范例。

• Hypervisor

在新能源汽車(chē)智能座艙中，虛擬化技術(shù)也被廣泛應(yīng)用，以提高系統(tǒng)的資源利用率、可靠性和安全性。虛擬化技術(shù)可以將一臺(tái)物理服務(wù)器劃分成多個(gè)虛擬機(jī)，每個(gè)虛擬機(jī)都可以獨(dú)立運(yùn)行不同的應(yīng)用程序和操作系統(tǒng)。

虛擬化技術(shù)可以分為兩種類(lèi)型，一種是基于Type1類(lèi)型的Hypervisor的虛擬化技術(shù)，另一種是基于Type2類(lèi)型的虛擬化技術(shù)。

Type1類(lèi)型的Hypervisor是一種直接運(yùn)行在物理服務(wù)器硬件上的虛擬化軟件，也被稱為裸機(jī)Hypervisor。Type1類(lèi)型的Hypervisor能夠直接訪問(wèn)服務(wù)器的硬件資源，包括處理器、內(nèi)存、網(wǎng)絡(luò)和存儲(chǔ)等，能夠提供更高的性能和穩(wěn)定性。在智能座艙中，Type1類(lèi)型的Hypervisor可以被用來(lái)運(yùn)行多個(gè)虛擬機(jī)，每個(gè)虛擬機(jī)可以運(yùn)行不同的操作系統(tǒng)和應(yīng)用程序。同時(shí)，Type1類(lèi)型的Hypervisor還可以提供強(qiáng)大的安全隔離功能，確保不同的虛擬機(jī)之間互不干擾，從而提高整個(gè)系統(tǒng)的可靠性和安全性。

相比之下，基于Type2的虛擬化技術(shù)則是運(yùn)行在操作系統(tǒng)之上的虛擬化技術(shù)。虛擬機(jī)OS可以與主機(jī)OS共享同一個(gè)操作系統(tǒng)內(nèi)核，這樣可以減少虛擬化層的開(kāi)銷(xiāo)和系統(tǒng)資源的占用。虛擬機(jī)OS位于主操作系統(tǒng)之上，可以將應(yīng)用程序及其依賴項(xiàng)封裝成一個(gè)完整的軟件單元，從而實(shí)現(xiàn)應(yīng)用程序的快速部署和擴(kuò)展。在智能座艙中，基于Type2的虛擬化技術(shù)可以用于隔離不同的應(yīng)用程序和服務(wù)。

Type 1類(lèi)型的Hypervisor直接運(yùn)行在物理硬件之上，直接訪問(wèn)物理硬件并管理所有硬件資源，在延時(shí)、安全性和效率上更勝一籌。但此類(lèi)型Hypervisor需要硬件支持，移植難度大，開(kāi)發(fā)成本也較高，在互聯(lián)網(wǎng)領(lǐng)域常用于數(shù)據(jù)計(jì)算中心。

Type 2類(lèi)型的Hypervisor運(yùn)行在某個(gè)操作系統(tǒng)之上，利用操作系統(tǒng)訪問(wèn)物理硬件，因此在延時(shí)方面具有不可避免的劣勢(shì)。且底層操作系統(tǒng)的任何Bug都將危及其上的虛擬機(jī)，因此安全性方面相對(duì)較弱。但是移植難度小，開(kāi)發(fā)成本低。在互聯(lián)網(wǎng)領(lǐng)域常用于客戶端系統(tǒng)。

Hypervisor可以將一臺(tái)物理服務(wù)器劃分成多個(gè)虛擬機(jī)，每個(gè)虛擬機(jī)可以獨(dú)立運(yùn)行不同的操作系統(tǒng)和應(yīng)用程序。Hypervisor能夠提供強(qiáng)大的安全隔離功能，確保不同的虛擬機(jī)之間互不干擾，從而提高整個(gè)系統(tǒng)的可靠性和安全性。同時(shí)，Hypervisor還能夠動(dòng)態(tài)調(diào)整虛擬機(jī)的資源分配，以滿足系統(tǒng)運(yùn)行的需求。在智能座艙中，使用Hypervisor可以實(shí)現(xiàn)多個(gè)應(yīng)用程序之間的隔離，從而提高系統(tǒng)的可靠性和安全性。

Hypervisor具有如下功能：

（1）設(shè)備模擬。Hypervisor可以創(chuàng)建客戶操作系統(tǒng)可以訪問(wèn)的一些虛擬硬件組件，是否需要取決于客戶操作系統(tǒng)上運(yùn)行的應(yīng)用程序；

（2）內(nèi)存管理。Hypervisor負(fù)責(zé)為自身和客戶操作系統(tǒng)管理和分配硬件內(nèi)存資源；

（3）設(shè)備分配和訪問(wèn)。Hypervisor通?？梢詫⒂布M件分配給客戶操作系統(tǒng)，并控制客戶操作系統(tǒng)實(shí)際可以訪問(wèn)哪些硬件組件；

（4）上下文切換。當(dāng)Hypervisor需要在內(nèi)核上安排新的客戶操作系統(tǒng)時(shí)，Hypervisor必須通過(guò)將在該處理器內(nèi)核上運(yùn)行的現(xiàn)有客戶操作系統(tǒng)的“上下文”（即操作條件）保存到內(nèi)存中來(lái)“切換上下文”。然后進(jìn)行加載新的客戶操作系統(tǒng)時(shí)，可以從內(nèi)存中訪問(wèn)新的客戶操作系統(tǒng)，而不會(huì)中斷執(zhí)行環(huán)境；

（5）捕獲指令。客戶操作系統(tǒng)可能會(huì)根據(jù)其訪問(wèn)權(quán)限級(jí)別執(zhí)行技術(shù)上不應(yīng)執(zhí)行的指令。Hypervisor可以分析客戶操作系統(tǒng)嘗試發(fā)送到硬件的指令，并模擬硬件對(duì)客戶操作系統(tǒng)指令的響應(yīng)；

（6）異常處理。發(fā)生異常（即異常行為）時(shí)，可以將某些異常路由到Hypervisor進(jìn)行處理；

（7）虛擬機(jī)管理。如前所述，Hypervisor最終負(fù)責(zé)啟動(dòng)和停止客戶操作系統(tǒng)在其上運(yùn)行的虛擬機(jī)。

• 區(qū)域硬隔離

與Hypervisor虛擬化相對(duì)應(yīng)的一種多操作系統(tǒng)應(yīng)用方式，是區(qū)域硬隔離。

它是通過(guò)物理隔離來(lái)保障不同系統(tǒng)組件之間的安全。比如說(shuō)，在智能座艙SOC規(guī)劃與設(shè)計(jì)的時(shí)候，根據(jù)功能劃分的不同，在同一顆SOC內(nèi)部劃分出不同的CPU內(nèi)核，以及其他物理硬件資源，并分配給不同的功能來(lái)使用。比如，儀表盤(pán)就可以使用獨(dú)立的CPU核和獨(dú)立的顯示模塊，并運(yùn)行獨(dú)立的RTOS操作系統(tǒng)。

區(qū)域硬隔離能夠提供更高的安全性和隔離性，避免不同的系統(tǒng)組件之間的相互干擾。在智能座艙中，區(qū)域硬隔離可以被用于對(duì)關(guān)鍵系統(tǒng)組件的保護(hù)，從而提高整個(gè)系統(tǒng)的可靠性和安全性。

在智能座艙中，使用Hypervisor和使用區(qū)域硬隔離都有其優(yōu)勢(shì)和不足。實(shí)際上，二者的選擇取決于智能座艙芯片供應(yīng)商的所選擇的技術(shù)路線，也取決于主機(jī)廠對(duì)可靠性和芯片性能的判斷。

• Hypervisor與區(qū)域硬隔離的優(yōu)缺點(diǎn)

以儀表盤(pán)的實(shí)現(xiàn)為例，現(xiàn)代智能座艙的發(fā)展，要求支持“一芯多屏”的功能。顧名思義，就是要求在一顆智能座艙SOC芯片上，同時(shí)支持實(shí)現(xiàn)液晶儀表盤(pán)功能和娛樂(lè)中控大屏功能，甚至還有其他的屏幕。

由于液晶儀表盤(pán)屬于高安全性和高可靠性領(lǐng)域，一般需要使用RTOS操作系統(tǒng)。娛樂(lè)中控大屏需要有豐富的生態(tài)應(yīng)用，一般需要使用Android系統(tǒng)來(lái)支持。

區(qū)域硬隔離和Hypervisor都可以用于實(shí)現(xiàn)儀表盤(pán)功能，但它們有各自的優(yōu)缺點(diǎn)。

綜上所述，使用區(qū)域硬隔離和Hypervisor都可以實(shí)現(xiàn)儀表盤(pán)功能，需要根據(jù)具體的場(chǎng)景和需求進(jìn)行選擇。如果對(duì)可靠性和安全性要求較高，可以選擇區(qū)域硬隔離；如果需要靈活性和可擴(kuò)展性，可以選擇Hypervisor。