2.2.1  技術(shù)形態(tài)

新四化（電動化，網(wǎng)聯(lián)化，智能化，共享化）的變革驅(qū)使汽車軟件系統(tǒng)變得更加靈活。汽車軟件既要安全又要可持續(xù)更新以反映新的功能特性或法規(guī)要求，為此需要新架構(gòu)支持軟件組件的動態(tài)部署以及與非車載系統(tǒng)之間的交互。

今天的汽車 E/E 架構(gòu)可劃分為信息娛樂、底盤和車身控制等不同域，信息娛樂系統(tǒng)通常使用 Linux 或商業(yè)化的通用操作系統(tǒng)，車身控制則使用標(biāo)準(zhǔn)的 AUTOSAR CP。隨著未來新技術(shù)及深度嵌入式系統(tǒng)對計算能力需求的不斷增長，急需第三種控制器—— 域控制器，用于集成特定領(lǐng)域的功能特性（如車輛動力域、車身域等 )，形成域集中或跨域集中式電子電氣架構(gòu)。

在未來，隨著汽車電子及軟件功能的大幅增長，E/E 架構(gòu)最終可能向基于中央計算平臺的整車集中式電子電氣架構(gòu)，以及車云協(xié)同控制發(fā)展。在這種趨勢下，需要高度靈活、高性能且支持 HPC、動態(tài)通信等特性的新軟件架構(gòu)平臺—— Adaptive Platform AUTOSAR 平臺（下文簡稱 AUTOSAR AP）。

1.  軟件分層架構(gòu)

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

AUTOSAR AP 在基礎(chǔ)平臺層，這一層包含了 AUTOSAR AP、AUTOSAR CP、專用基礎(chǔ)功能等，主要為整車提供基礎(chǔ)運(yùn)行環(huán)境。

原子服務(wù)層是實現(xiàn)數(shù)據(jù)融合和控制邏輯的功能模塊，作為服務(wù)的最小單位與單一執(zhí)行實體，通過   API 為應(yīng)用提供可按需編排的基礎(chǔ)服務(wù)，實現(xiàn)一次開發(fā)多次復(fù)用，最大化提升開發(fā)效率。該層的設(shè)計目標(biāo)是原子服務(wù)與平臺解耦，提升軟件復(fù)用性。

應(yīng)用層基于原子服務(wù)實現(xiàn)對整車服務(wù)、應(yīng)用、體驗等進(jìn)行定義和組合增強(qiáng)，構(gòu)建差異化競爭力的業(yè)務(wù)應(yīng)用，體現(xiàn)千車千面。

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

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

AUTOSAR AP 在域控軟件架構(gòu)中位于中間件的位置，通過服務(wù)和API 為上層服務(wù)提供功能，如圖2.2-2 所示。

在 Non-AUTOSAR 環(huán)境中，系統(tǒng)已經(jīng)實現(xiàn)了部分 AUTOSAR AP 標(biāo)準(zhǔn)組件，只需要實現(xiàn)剩余部分組件即可滿足 AUTOSAR AP 的標(biāo)準(zhǔn)。比如在 Android Automotive OS 中，軟件框架提供了進(jìn)程管理、執(zhí)行管理、Log、加密、生命周期管理等功能，基礎(chǔ)軟件供應(yīng)商實現(xiàn)通信管理、診斷、升級、網(wǎng)絡(luò)管理等功能， 即可滿足 AUTOSAR AP 的標(biāo)準(zhǔn)。

2.  工具鏈

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

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

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

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

3.  開發(fā)方法論

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

圖 2.2-3 簡要展示了 AP 平臺的開發(fā)工作流，總體來說需要經(jīng)歷三個階段七個步驟，最終將開發(fā)的軟件集成入車輛中。

(1) 架構(gòu)設(shè)計階段

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

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

(2) 軟件開發(fā)階段

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

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

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

(3) 集成與部署階段

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

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

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

2.2.2  技術(shù)發(fā)展趨勢

1.  架構(gòu)發(fā)展趨勢

(1) Adaptive AUTOSAR 的歷史

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

(2) Adaptive AUTOSAR 的發(fā)展趨勢

① 技術(shù)趨勢

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

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

b. 穩(wěn)定性：增加針對系統(tǒng)穩(wěn)定的特性。如在 EM 細(xì)節(jié)中增加了配置進(jìn)程錯誤碼、功能組增加 unde- fined 狀態(tài)、增加對進(jìn)程意外終止的處理，PHM 中增加確定性執(zhí)行的監(jiān)控，UCM 中增加容錯機(jī)制等。

同時在這些功能場景下，信息安全與功能安全成為不可或缺的關(guān)鍵機(jī)制。Adaptive AUTOSAR 針對這兩項安全需求，定義了完善的特性：

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

• SHM Client 交流平臺健康狀況；

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

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

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

  
  

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

• 增加了 Crypto API 的描述；

• 軟件和硬件解耦；

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

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

  
  

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

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

③ 新的分工趨勢

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

2.  工具鏈發(fā)展方向

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

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

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

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

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

當(dāng)前整車電子電氣架構(gòu)，功能不集中，分散到不同 ECU，使得功能和信號交互異常復(fù)雜，代碼和邏輯冗余相當(dāng)嚴(yán)重，而互聯(lián)網(wǎng)開發(fā)思想不斷涌入汽車行業(yè)，汽車電子電氣開發(fā)也必須盡快適應(yīng)變革。

面向服務(wù)的體系結(jié)構(gòu)，是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù) 之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，獨(dú)立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言，使得構(gòu)建在各種這類系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。通過 引入 SOA 架構(gòu)，不但可以使應(yīng)用軟件與硬件及應(yīng)用軟件與應(yīng)用軟件之間松耦合，還可以使車端軟件、通信、信息安全能和云端環(huán)境產(chǎn)生很好的協(xié)同，實現(xiàn)一整套車云生態(tài)環(huán)境，因此車端采用基于服務(wù)的通信 SOA 是有效的落地方案。

2.  軟硬分離

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

3.  虛擬化

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

2.2.4  典型應(yīng)用案例

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

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

日志作為行為或狀態(tài)詳細(xì)描述的載體，提供可用于分析系統(tǒng)的活動和診斷問題的跟蹤記錄。在安全事件分析、事件回溯和取證過程中起著相當(dāng)重要的作用。

在 AP AUTOSAR 中，Log and Trace 模塊負(fù)責(zé)管理和記錄 AP 平臺的日志，既可以應(yīng)用于開發(fā)過程， 也可以適用于量產(chǎn)過程。在架構(gòu)上，Log and Trace 模塊會與 AP 的時間同步及通信管理等模塊交互?；?AP AUTOSAR 標(biāo)準(zhǔn)定義的 LT 協(xié)議，Log and Trace 模塊可以讓 AP 應(yīng)用程序?qū)⑿畔⒂涗浀酵ㄐ趴偩€、控制臺或文件系統(tǒng)上。同時 DLT 協(xié)議也提供了包括日志等級、日志 ID 等字段內(nèi)容，日志客戶端可以使用此信息來關(guān)聯(lián)、排序或過濾接收到的日志幀，便于日志的解析查看以及日志相關(guān)功能的擴(kuò)展。

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

圖2.2-4 Log And Trace案例

其中，App 通過使用 DLT 接口將相應(yīng)的操作步驟、狀態(tài)監(jiān)控、故障信息等內(nèi)容發(fā)送至 Daemon；

Daemon 表示 DLT 守護(hù)進(jìn)程，它接收并處理來自 AP 應(yīng)用程序的日志信息，并根據(jù)配置對日志進(jìn)行終端顯示、文件存儲、網(wǎng)絡(luò)傳輸?shù)炔僮鳎?

Dlt-Viewer 表示通過網(wǎng)絡(luò)傳輸接收 Daemon 日志信息的客戶端，對日志信息進(jìn)行 UI 展示，方便用戶進(jìn)行日志的查看和分析。

日志記錄分析

上文介紹了從日志產(chǎn)生到日志數(shù)據(jù)流轉(zhuǎn)的整個過程，基于已有的日志信息，Dlt-Viewer 可以提取出我們所關(guān)注的數(shù)據(jù)，如圖 2.2-5 所示。

Dlt-Viewer 提供相當(dāng)多 DLT 日志處理功能，除了日志顯示、日志導(dǎo)入 / 導(dǎo)出等功能外，還提供了強(qiáng)大的日志過濾、標(biāo)記等功能。過濾器可以是某一字段，甚至是正則表達(dá)式。它提供了插件的開發(fā)接口，極大地提升了功能擴(kuò)展的能力。

圖2.2-5 日志記錄分析

(3) 系統(tǒng)啟動監(jiān)控

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

2.  基于 AP 的應(yīng)用場景介紹

本節(jié)主要介紹基于 AP 的智能域控制器（后續(xù)簡稱 IDC）OTA 升級場景及其實現(xiàn)方案。IDC 的 OTA 功能可以進(jìn)行自身應(yīng)用軟件及系統(tǒng)軟件、關(guān)聯(lián)器件固件的升級，并在數(shù)據(jù)管理、軟件升級、可追溯性、安全驗證方面滿足 AP 的相關(guān)要求。

在OTA 的功能實現(xiàn)過程中，IDC 與外界的數(shù)據(jù)交互如圖2.2-6 所示。云端OTA 云服務(wù)器向車端HUT（終端信息展現(xiàn)單元 Head Unit & Telematics）推送升級任務(wù)，用戶確認(rèn)升級后，HUT 會通過網(wǎng)關(guān)向 IDC 及其他 ECU 以 UDS 的形式發(fā)送升級指令及升級數(shù)據(jù)，IDC 接收升級指令與數(shù)據(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)行升級。

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

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

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

(2) 軟件升級

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

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

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

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

(3) 可追溯性

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

② OTA 會記錄升級過程中的日志，供 HUT 獲取。

(4) 安全性

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

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

③ OTA 時會激活 IDC 心跳監(jiān)控機(jī)制及分區(qū)損壞回滾機(jī)制，當(dāng)切換到備份分區(qū)啟動失敗后，IDC 不會給 MCU 發(fā)送心跳報文，MCU 會認(rèn)為 IDC 在 OTA 后變磚，會給 IDC 斷電重啟，切回原分區(qū)啟動，保證車機(jī)可用。

注：本章有關(guān)AUTOSAR 的內(nèi)容是AUTOSEMO 會員單位的經(jīng)驗解讀，僅供行業(yè)參考。