AUTOSAR AP技術(shù)形態(tài)與技術(shù)發(fā)展趨勢

01

AUTOSAR AP 技術(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)，車身控制則使用標準的 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.1 軟件分層架構(gòu)

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

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

該層的設計目標是原子服務與平臺解耦，提升軟件復用性。應用層基于原子服務實現(xiàn)對整車服務、應用、體驗等進行定義和組合增強，構(gòu)建差異化競爭力的業(yè)務應用，體現(xiàn)千車千面。



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



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

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

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

1.2 工具鏈

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

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

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

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

1.3 開發(fā)方法論

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

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

（1）架構(gòu)設計階段

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

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

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

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

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

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

（3）集成與部署階段

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

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



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

02

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

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

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

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

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

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

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

Adaptive AUTOSAR 針對這兩項安全需求，定義了完善的特性：

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

SHM Client 交流平臺健康狀況；

SHM Master 確定健康指標；

根據(jù)健康指標進行的機器恢復（例如降級）；

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

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

增加了 Crypto API 的描述；

軟件和硬件解耦；

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

應用程序獨立于加密解決方案。

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

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

③ 新的分工趨勢

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

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

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

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

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

03

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

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

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

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

3.2 軟硬分離

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

3.3 虛擬化

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

04

AUTOSAR AP典型應用案例

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

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

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

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

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



圖2.2-4 Log And Trace案例

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

（2）日志記錄分析

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



圖2.2-5 日志記錄分析

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

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

4.2 基于 AP 的應用場景介紹

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

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



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

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

① IDC 內(nèi)部分為 OTA 進程和 UDS Server 進程，UDS Server 進程與 HUT 端交互，負責處理、轉(zhuǎn)發(fā)指令和接收軟件包，OTA 進程處理軟件包進行升級。

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

③ IDC 會進行完整性校驗以保證軟件包的完整性。

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

（2）軟件升級

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

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

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

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

（3）可追溯性

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

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

（4）安全性

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

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

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

審核編輯：劉清