01

AUTOSAR AP 技術(shù)形態(tài)

新四化（電動(dòng)化，網(wǎng)聯(lián)化，智能化，共享化）的變革驅(qū)使汽車(chē)軟件系統(tǒng)變得更加靈活。汽車(chē)軟件既要安全又要可持續(xù)更新以反映新的功能特性或法規(guī)要求，為此需要新架構(gòu)支持軟件組件的動(dòng)態(tài)部署以及與非車(chē)載系統(tǒng)之間的交互。今天的汽車(chē) E/E 架構(gòu)可劃分為信息娛樂(lè)、底盤(pán)和車(chē)身控制等不同域，信息娛樂(lè)系統(tǒng)通常使用 Linux 或商業(yè)化的通用操作系統(tǒng)，車(chē)身控制則使用標(biāo)準(zhǔn)的 AUTOSAR CP。

隨著未來(lái)新技術(shù)及深度嵌入式系統(tǒng)對(duì)計(jì)算能力需求的不斷增長(zhǎng)，急需第三種控制器—— 域控制器，用于集成特定領(lǐng)域的功能特性（如車(chē)輛動(dòng)力域、車(chē)身域等 )，形成域集中或跨域集中式電子電氣架構(gòu)。在未來(lái)，隨著汽車(chē)電子及軟件功能的大幅增長(zhǎng)，E/E 架構(gòu)最終可能向基于中央計(jì)算平臺(tái)的整車(chē)集中式電子電氣架構(gòu)，以及車(chē)云協(xié)同控制發(fā)展。

在這種趨勢(shì)下，需要高度靈活、高性能且支持 HPC、動(dòng)態(tài)通信等特性的新軟件架構(gòu)平臺(tái)—— Adaptive Platform AUTOSAR 平臺(tái)（下文簡(jiǎn)稱(chēng) AUTOSAR AP）。

1.1 軟件分層架構(gòu)

典型的域控軟件架構(gòu)如圖 2.2-1 所示，整體可被分為四層，即操作系統(tǒng)層、基礎(chǔ)平臺(tái)層、原子服務(wù)層、應(yīng)用組合服務(wù)層。

AUTOSAR AP 在基礎(chǔ)平臺(tái)層，這一層包含了 AUTOSAR AP、AUTOSAR CP、專(zhuān)用基礎(chǔ)功能等，主要為整車(chē)提供基礎(chǔ)運(yùn)行環(huán)境。原子服務(wù)層是實(shí)現(xiàn)數(shù)據(jù)融合和控制邏輯的功能模塊，作為服務(wù)的最小單位與單一執(zhí)行實(shí)體，通過(guò) API 為應(yīng)用提供可按需編排的基礎(chǔ)服務(wù)，實(shí)現(xiàn)一次開(kāi)發(fā)多次復(fù)用，最大化提升開(kāi)發(fā)效率。

該層的設(shè)計(jì)目標(biāo)是原子服務(wù)與平臺(tái)解耦，提升軟件復(fù)用性。應(yīng)用層基于原子服務(wù)實(shí)現(xiàn)對(duì)整車(chē)服務(wù)、應(yīng)用、體驗(yàn)等進(jìn)行定義和組合增強(qiáng)，構(gòu)建差異化競(jìng)爭(zhēng)力的業(yè)務(wù)應(yīng)用，體現(xiàn)千車(chē)千面。



圖 2.2-1 域控軟件架構(gòu)圖



圖2.2-2 AUTOSAR AP在軟件架構(gòu)中的位置

AUTOSAR AP 在域控軟件架構(gòu)中位于中間件的位置，通過(guò)服務(wù)和API 為上層服務(wù)提供功能，如圖2.2-2 所示。 在 Non-AUTOSAR 環(huán)境中，系統(tǒng)已經(jīng)實(shí)現(xiàn)了部分 AUTOSAR AP 標(biāo)準(zhǔn)組件，只需要實(shí)現(xiàn)剩余部分組件即可滿(mǎn)足 AUTOSAR AP 的標(biāo)準(zhǔn)。

比如在 Android Automotive OS 中，軟件框架提供了進(jìn)程管理、執(zhí)行管理、Log、加密、生命周期管理等功能，基礎(chǔ)軟件供應(yīng)商實(shí)現(xiàn)通信管理、診斷、升級(jí)、網(wǎng)絡(luò)管理等功能， 即可滿(mǎn)足 AUTOSAR AP 的標(biāo)準(zhǔn)。

1.2 工具鏈

基于自適應(yīng)平臺(tái)的應(yīng)用程序開(kāi)發(fā)一般要經(jīng)歷三個(gè)階段，分別是設(shè)計(jì)建模階段、軟件開(kāi)發(fā)階段、集成部署階段，為了更好地支撐這三個(gè)階段的活動(dòng)，AP 工具鏈具備以下能力：

設(shè)計(jì)建模階段使用建模工具，用于生成 ARXML，完成 Adaptive Application、Service Instance、Executable、Machine 等設(shè)計(jì)開(kāi)發(fā)，配置 SWC（Software Component）相關(guān)配置項(xiàng)，完成 SWC 端口及框架設(shè)計(jì) , 最終導(dǎo)出 AP 平臺(tái)的 ARXML 文件。產(chǎn)品工具應(yīng)具備支持導(dǎo)入導(dǎo)出、解析、編輯ARXML 文件的能力。

軟件開(kāi)發(fā)階段：使用 AP 產(chǎn)品生成工具，用于實(shí)現(xiàn)組件 API 代碼及 Manifest 配置文件的生成。輸入是標(biāo)準(zhǔn)的 ARXML 文件，生成源代碼和 Manifest 配置文件，另外需要包含應(yīng)用層的代碼編輯器和代碼庫(kù)管理，實(shí)現(xiàn)源碼編輯，編譯鏈文件編寫(xiě)，代碼庫(kù)同步等功能。

集成部署階段：使用集成編譯調(diào)試以及部署工具，包含編譯工具、可視化調(diào)試工具、部署工具、資源監(jiān)控等工具，支持編譯、調(diào)試、部署等功能。

1.3 開(kāi)發(fā)方法論

為了支持 AP 平臺(tái)下應(yīng)用程序獨(dú)立、敏捷、分布式的開(kāi)發(fā)，需要在開(kāi)發(fā)方法論上有一套標(biāo)準(zhǔn)化的方法。AUTOSAR AP 開(kāi)發(fā)方法論涉及工作產(chǎn)品的標(biāo)準(zhǔn)化，用于描述工作產(chǎn)品（如服務(wù)、應(yīng)用程序、機(jī)器及其配置）、工作產(chǎn)品應(yīng)如何交互、以實(shí)現(xiàn)自適應(yīng)平臺(tái)產(chǎn)品開(kāi)發(fā)過(guò)程中不同角色之間所需的信息交換。

圖 2.2-3 簡(jiǎn)要展示了 AP 平臺(tái)的開(kāi)發(fā)工作流，總體來(lái)說(shuō)需要經(jīng)歷三個(gè)階段七個(gè)步驟，最終將開(kāi)發(fā)的軟件集成入車(chē)輛中。

（1）架構(gòu)設(shè)計(jì)階段

① 服務(wù)接口設(shè)計(jì)（Define Services）：主要是定義服務(wù)接口及數(shù)據(jù)類(lèi)型，包括定義服務(wù)所包含的method、event、field、trigger 等通信元素以及數(shù)據(jù)類(lèi)型詳細(xì)說(shuō)明等；

② 機(jī)器配置設(shè)計(jì)（Configure Machine）：定義和配置機(jī)器的網(wǎng)絡(luò)通信屬性，包含網(wǎng)絡(luò)連接配置，服務(wù)發(fā)現(xiàn)配置等信息；

（2）軟件開(kāi)發(fā)階段

③ 定義與配置可執(zhí)行實(shí)例及通信方式，定義可執(zhí)行實(shí)例如何訪問(wèn)軟件集；

④ 定義軟件集群所提供的服務(wù)實(shí)例、配置服務(wù)實(shí)例和可執(zhí)行實(shí)例的映射；

⑤ 服務(wù)實(shí)例接口框架源碼生成；軟件集群源碼開(kāi)發(fā)及測(cè)試等；

（3）集成與部署階段

⑥ 軟件集群集成 (Integrate Software) ：配置可執(zhí)行實(shí)例和進(jìn)程的映射、定義和配置應(yīng)用程序配置清單、定義和配置服務(wù)實(shí)例部署信息；

⑦ ECU 集成 (ECU(Machine) Integrate)，定義應(yīng)用程序執(zhí)行清單 (Execution Manifest)、定義平臺(tái)程序的配置清單、診斷和進(jìn)程之間的映射配置；



圖2.2-3 AUTOSAR AP開(kāi)發(fā)方法論

02

AUTOSAR AP技術(shù)發(fā)展趨勢(shì)

2.1架構(gòu)發(fā)展趨勢(shì)

（1）Adaptive AUTOSAR 的歷史 Adaptive AUTOSAR 于 2017 年應(yīng)運(yùn)而生，主要為了提供高算力、高網(wǎng)絡(luò)帶寬下的基礎(chǔ)軟件開(kāi)發(fā)平臺(tái)標(biāo)準(zhǔn)。目前最新版本為 R21-11。

（2）Adaptive AUTOSAR 的發(fā)展趨勢(shì)

① 技術(shù)趨勢(shì) 在汽車(chē)行業(yè)， 智能網(wǎng)聯(lián)、自動(dòng)駕駛、V2X、OTA 等功能逐漸成為標(biāo)配，Adaptive AUTOSAR 面向POSIX 標(biāo)準(zhǔn)的操作系統(tǒng)，可以更好支持這些功能。在最新的標(biāo)準(zhǔn)中為了更好的支持開(kāi)發(fā)，在可用性及穩(wěn)定性上做了如下提升：

a.可用性：提升模塊特性的合理性及便利性。支持更多的 SOA 通訊協(xié)議、通信失效模式的檢測(cè)、靈活支持日志內(nèi)容定義等。同時(shí)，針對(duì)域控制器的異構(gòu)平臺(tái)，新版本在 AP 與 CP 的共用特性及方法論上進(jìn)行統(tǒng)一，定義了自動(dòng)駕駛的傳感器接口、整車(chē)級(jí)健康管理的架構(gòu)與接口、針對(duì)整車(chē) OTA 升級(jí)的流程等域控制器架構(gòu)的使用功能等。

b.穩(wěn)定性：增加針對(duì)系統(tǒng)穩(wěn)定的特性。如在 EM 細(xì)節(jié)中增加了配置進(jìn)程錯(cuò)誤碼、功能組增加 unde- fined 狀態(tài)、增加對(duì)進(jìn)程意外終止的處理，PHM 中增加確定性執(zhí)行的監(jiān)控，UCM 中增加容錯(cuò)機(jī)制等。 同時(shí)在這些功能場(chǎng)景下，信息安全與功能安全成為不可或缺的關(guān)鍵機(jī)制。

Adaptive AUTOSAR 針對(duì)這兩項(xiàng)安全需求，定義了完善的特性：

a.面向功能安全：新增了系統(tǒng)健康監(jiān)控，主要用于系統(tǒng)協(xié)調(diào)健康狀況 / 錯(cuò)誤。主要包含以下內(nèi)容：

SHM Client 交流平臺(tái)健康狀況；

SHM Master 確定健康指標(biāo)；

根據(jù)健康指標(biāo)進(jìn)行的機(jī)器恢復(fù)（例如降級(jí)）；

增加了確定性同步的內(nèi)容，描述了同步行為和周期性激活的要求，包括時(shí)間同步和數(shù)據(jù)同步。

b.面向信息安全：增加了入侵檢測(cè)系統(tǒng)管理，由標(biāo)準(zhǔn)化的接口來(lái)報(bào)告安全事件。通過(guò)標(biāo)準(zhǔn)化的過(guò)濾機(jī)制來(lái)傳輸合格的安全事件。

增加了 Crypto API 的描述；

軟件和硬件解耦；

支持分離式非耦合開(kāi)發(fā)；

應(yīng)用程序獨(dú)立于加密解決方案。

② 基礎(chǔ)軟件技術(shù)路線

隨著各種域控制器方案陸續(xù)問(wèn)世，各細(xì)分賽道由分散到集中，由獨(dú)立到整合。目前整車(chē)域控制器， 例如智駕域控，中央域控，智能座艙域控等均需得到高性能 MPU 芯片的支撐，因此 POSIX 標(biāo)準(zhǔn)系統(tǒng)的搭載顯得尤為必要。基于 POSIX 系統(tǒng)之上的 AUTOSAR Adaptive 平臺(tái)及相關(guān)工具鏈，為應(yīng)用開(kāi)發(fā)過(guò)程中的效率帶來(lái)顯著提高，而座艙域控一般在 Linux 基礎(chǔ)之上搭載安卓系統(tǒng)，在程序啟動(dòng)、狀態(tài)切換、存儲(chǔ)等方面有自己獨(dú)立的生態(tài)，而諸如 SOA 通信、整車(chē)診斷、健康管理的方面需要參考 AUTOSAR AP 平臺(tái)標(biāo)準(zhǔn)給予補(bǔ)齊和增強(qiáng)，工具鏈未來(lái)需要從整車(chē)視角實(shí)施統(tǒng)一化配置。

③ 新的分工趨勢(shì)

受域控制器行業(yè)的蓬勃發(fā)展以及各項(xiàng)政策利好，越來(lái)越多的參與者以各種新的身份加入進(jìn)來(lái)，整體 的行業(yè)角色將不再是 E/E 時(shí)代的 OEM、Tier1 及 Tier2 三種。隨著產(chǎn)業(yè)鏈結(jié)構(gòu)的變化，位于下游負(fù)責(zé)整車(chē)生產(chǎn)和組裝的主機(jī)廠（即行業(yè)所說(shuō)的 OEM），將不再通過(guò)系統(tǒng)與設(shè)備集成來(lái)獲取價(jià)值增量，而會(huì)轉(zhuǎn)向基于用戶(hù)需求和自身產(chǎn)品定位，建立有效的梳理篩選機(jī)制，向上游 Tier1 及 Tier2 提出更多定制化的需求。

2.2 工具鏈發(fā)展方向

工具鏈（tool chain）是在一套流程里面用到的所有工具和相關(guān)庫(kù)組成的集合，上一個(gè)工具的輸出或環(huán)境狀態(tài)成為下一個(gè)工具的輸入或啟動(dòng)環(huán)境。因此，工具鏈的效率決定了整個(gè)系統(tǒng)的開(kāi)發(fā)效率。所以隨著行業(yè)的發(fā)展成熟，工具鏈的發(fā)展將由現(xiàn)在分散的多工具相互切換配合形態(tài)，逐步升級(jí)到成熟開(kāi)放的中間服務(wù)體系，來(lái)匹配整個(gè)產(chǎn)業(yè)的發(fā)展態(tài)勢(shì)，在平衡各自的專(zhuān)業(yè)分工的前提下避免產(chǎn)生信息數(shù)據(jù)孤島。

現(xiàn)行的工具鏈標(biāo)準(zhǔn)基本是在 AUTOSAR AP 規(guī)范所約定的框架內(nèi)按照給定的方法論實(shí)現(xiàn)功能，各家比拼的是對(duì) AP 服務(wù)模塊的實(shí)現(xiàn)及理解。在第一階段的服務(wù)實(shí)施提供后，要比拼的就是在整個(gè)產(chǎn)業(yè)上下游的環(huán)節(jié)中的規(guī)范度、可移植性及整體的效率提升。

從集成角度，基于 AP 的開(kāi)發(fā)工具鏈一般是基于 Linux 系統(tǒng)進(jìn)行開(kāi)發(fā)、編譯和調(diào)試，在用戶(hù)桌面端往往出現(xiàn)多種開(kāi)發(fā)工具同時(shí)使用的問(wèn)題，因此亟需一套集成開(kāi)發(fā)環(huán)境來(lái)簡(jiǎn)化用戶(hù)桌面，為基于 AP 的應(yīng)用開(kāi)發(fā)提供便捷性。

03

AUTOSAR AP關(guān)鍵技術(shù)解讀

3.1 面向服務(wù)的架構(gòu)（SOA）

當(dāng)前整車(chē)電子電氣架構(gòu)，功能不集中，分散到不同 ECU，使得功能和信號(hào)交互異常復(fù)雜，代碼和邏輯冗余相當(dāng)嚴(yán)重，而互聯(lián)網(wǎng)開(kāi)發(fā)思想不斷涌入汽車(chē)行業(yè)，汽車(chē)電子電氣開(kāi)發(fā)也必須盡快適應(yīng)變革。面向服務(wù)的體系結(jié)構(gòu)，是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱(chēng)為服務(wù)）通過(guò)這些服務(wù) 之間定義良好的接口和契約聯(lián)系起來(lái)。

接口是采用中立的方式進(jìn)行定義的，獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語(yǔ)言，使得構(gòu)建在各種這類(lèi)系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。通過(guò) 引入 SOA 架構(gòu)，不但可以使應(yīng)用軟件與硬件及應(yīng)用軟件與應(yīng)用軟件之間松耦合，還可以使車(chē)端軟件、通信、信息安全能和云端環(huán)境產(chǎn)生很好的協(xié)同，實(shí)現(xiàn)一整套車(chē)云生態(tài)環(huán)境，因此車(chē)端采用基于服務(wù)的通信 SOA 是有效的落地方案。

3.2 軟硬分離

傳統(tǒng)汽車(chē)控制器的開(kāi)發(fā)模式是等硬件確定后，再進(jìn)行軟件的設(shè)計(jì)、開(kāi)發(fā)、測(cè)試，軟件的開(kāi)發(fā)依賴(lài)于硬件，無(wú)法先行或同步開(kāi)發(fā)，導(dǎo)致軟硬件兩個(gè)團(tuán)隊(duì)人員只能順序完成工作，浪費(fèi)時(shí)間。并且一旦硬件發(fā)生改變， 軟件則需要大量的修改適配，重復(fù)工作量巨大。在新型整車(chē)集中式 E/E 架構(gòu)下，功能服務(wù)化，接口統(tǒng)一化， 增加了中間件層，軟硬分離成為可能。

3.3 虛擬化

當(dāng)前高算力芯片層出不窮，通過(guò)虛擬化技術(shù)，將芯片上所跑的各類(lèi)業(yè)務(wù)分類(lèi)進(jìn)行隔離已經(jīng)是目前很 多車(chē)企的選擇。同時(shí)，在軟硬分離的背景下，在 x86 架構(gòu) PC 機(jī)上或云端通過(guò)虛擬化技術(shù)運(yùn)行虛擬控制器進(jìn)行服務(wù)設(shè)計(jì)的驗(yàn)證也是目前的主流軟件先行方案。

04

AUTOSAR AP典型應(yīng)用案例

4.1 基于 AP 的基礎(chǔ)軟件產(chǎn)品和解析

（1）日志與調(diào)試

日志作為行為或狀態(tài)詳細(xì)描述的載體，提供可用于分析系統(tǒng)的活動(dòng)和診斷問(wèn)題的跟蹤記錄。在安全事件分析、事件回溯和取證過(guò)程中起著相當(dāng)重要的作用。 在 AP AUTOSAR 中，Log and Trace 模塊負(fù)責(zé)管理和記錄 AP 平臺(tái)的日志，既可以應(yīng)用于開(kāi)發(fā)過(guò)程， 也可以適用于量產(chǎn)過(guò)程。在架構(gòu)上，Log and Trace 模塊會(huì)與 AP 的時(shí)間同步及通信管理等模塊交互。

基于 AP AUTOSAR 標(biāo)準(zhǔn)定義的 LT 協(xié)議，Log and Trace 模塊可以讓 AP 應(yīng)用程序?qū)⑿畔⒂涗浀酵ㄐ趴偩€、控制臺(tái)或文件系統(tǒng)上。同時(shí) DLT 協(xié)議也提供了包括日志等級(jí)、日志 ID 等字段內(nèi)容，日志客戶(hù)端可以使用此信息來(lái)關(guān)聯(lián)、排序或過(guò)濾接收到的日志幀，便于日志的解析查看以及日志相關(guān)功能的擴(kuò)展。

平臺(tái)典型的日志系統(tǒng)架構(gòu)圖如圖 2.2-4 所示：



圖2.2-4 Log And Trace案例

其中，App 通過(guò)使用 DLT 接口將相應(yīng)的操作步驟、狀態(tài)監(jiān)控、故障信息等內(nèi)容發(fā)送至 Daemon；Daemon 表示 DLT 守護(hù)進(jìn)程，它接收并處理來(lái)自 AP 應(yīng)用程序的日志信息，并根據(jù)配置對(duì)日志進(jìn)行 終端顯示、文件存儲(chǔ)、網(wǎng)絡(luò)傳輸?shù)炔僮鳎?Dlt-Viewer 表示通過(guò)網(wǎng)絡(luò)傳輸接收 Daemon 日志信息的客戶(hù)端，對(duì)日志信息進(jìn)行 UI 展示，方便用戶(hù)進(jìn)行日志的查看和分析。

（2）日志記錄分析

上文介紹了從日志產(chǎn)生到日志數(shù)據(jù)流轉(zhuǎn)的整個(gè)過(guò)程，基于已有的日志信息，Dlt-Viewer 可以提取出我們所關(guān)注的數(shù)據(jù)，如圖 2.2-5 所示。Dlt-Viewer 提供相當(dāng)多 DLT 日志處理功能，除了日志顯示、日志導(dǎo)入 / 導(dǎo)出等功能外，還提供了強(qiáng)大的日志過(guò)濾、標(biāo)記等功能。過(guò)濾器可以是某一字段，甚至是正則表達(dá)式。它提供了插件的開(kāi)發(fā)接口，極大地提升了功能擴(kuò)展的能力。



圖2.2-5 日志記錄分析

（3）系統(tǒng)啟動(dòng)監(jiān)控

通過(guò)解析各功能模塊產(chǎn)生的 DLT 日志，可以分析出整個(gè)系統(tǒng)上電啟動(dòng)過(guò)程，用戶(hù)可以直觀地觀測(cè)各功能模塊的啟動(dòng)過(guò)程，并根據(jù)觀測(cè)結(jié)果調(diào)整各功能的啟動(dòng)策略，達(dá)到功能模塊穩(wěn)定、快速啟動(dòng)的目的。

4.2 基于 AP 的應(yīng)用場(chǎng)景介紹

本節(jié)主要介紹基于 AP 的智能域控制器（后續(xù)簡(jiǎn)稱(chēng) 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)證方面滿(mǎn)足 AP 的相關(guān)要求。 在OTA 的功能實(shí)現(xiàn)過(guò)程中，IDC 與外界的數(shù)據(jù)交互如圖2.2-6 所示。

云端OTA 云服務(wù)器向車(chē)端HUT（終端信息展現(xiàn)單元 Head Unit & Telematics）推送升級(jí)任務(wù)，用戶(hù)確認(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é)果。



圖2.2-6 IDC與外界數(shù)據(jù)交互圖

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

① 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í)。

② OTA 使用專(zhuān)用的磁盤(pán)分區(qū)保證有足夠的資源來(lái)存儲(chǔ)軟件包及相關(guān)數(shù)據(jù)，從而保證數(shù)據(jù)的安全性。

③ IDC 會(huì)進(jìn)行完整性校驗(yàn)以保證軟件包的完整性。

④ OTA 結(jié)束后，IDC 會(huì)刪除臨時(shí)數(shù)據(jù)，最大限度節(jié)省空間。

（2）軟件升級(jí)

① OTA 采用雙分區(qū)機(jī)制，通過(guò)活躍分區(qū)去升級(jí)備份分區(qū)，升級(jí)成功后重啟備份分區(qū)，完成備份分區(qū)和活躍分區(qū)的互相切換，輕松實(shí)現(xiàn) IDC 上的應(yīng)用軟件、中間件、操作系統(tǒng)、配置數(shù)據(jù)的安裝、更新、刪除。

② OTA 采用雙分區(qū)機(jī)制，通過(guò)切換啟動(dòng)分區(qū)，可以實(shí)現(xiàn) IDC 上所有軟件及數(shù)據(jù)的快速回滾功能。

③ OTA 支持周邊器件的升級(jí)，如 MCU、相機(jī)等。

④ OTA 內(nèi)部維護(hù)狀態(tài)機(jī)，狀態(tài)變化實(shí)時(shí)落盤(pán)，可以支持在異常中斷后恢復(fù)升級(jí)。

（3）可追溯性

① OTA 提供獲取當(dāng)前軟件版本號(hào)、安裝進(jìn)度、安裝結(jié)果的接口。

② OTA 會(huì)記錄升級(jí)過(guò)程中的日志，供 HUT 獲取。

（4）安全性

① OTA 在軟件升級(jí)前會(huì)使用強(qiáng)加密算法校驗(yàn)證書(shū)鏈與軟件包簽名，保證軟件包的真實(shí)性及完整性。

② OTA 在軟件升級(jí)前會(huì)檢查當(dāng)前車(chē)速、IDC 的溫度、供電情況，保證在安全的情況下進(jìn)行 IDC 軟件升級(jí)。

③ 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ī)可用。

審核編輯：劉清