01

AUTOSAR AP 技術形態

新四化（電動化，網聯化，智能化，共享化）的變革驅使汽車軟件系統變得更加靈活。汽車軟件既要安全又要可持續更新以反映新的功能特性或法規要求，為此需要新架構支持軟件組件的動態部署以及與非車載系統之間的交互。今天的汽車 E/E 架構可劃分為信息娛樂、底盤和車身控制等不同域，信息娛樂系統通常使用 Linux 或商業化的通用操作系統，車身控制則使用標準的 AUTOSAR CP。

隨著未來新技術及深度嵌入式系統對計算能力需求的不斷增長，急需第三種控制器—— 域控制器，用于集成特定領域的功能特性（如車輛動力域、車身域等 )，形成域集中或跨域集中式電子電氣架構。在未來，隨著汽車電子及軟件功能的大幅增長，E/E 架構最終可能向基于中央計算平臺的整車集中式電子電氣架構，以及車云協同控制發展。

在這種趨勢下，需要高度靈活、高性能且支持 HPC、動態通信等特性的新軟件架構平臺—— Adaptive Platform AUTOSAR 平臺（下文簡稱 AUTOSAR AP）。

1.1 軟件分層架構

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

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

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



圖 2.2-1 域控軟件架構圖



圖2.2-2 AUTOSAR AP在軟件架構中的位置

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

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

1.2 工具鏈

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

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

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

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

1.3 開發方法論

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

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

（1）架構設計階段

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

② 機器配置設計（Configure Machine）：定義和配置機器的網絡通信屬性，包含網絡連接配置，服務發現配置等信息；

（2）軟件開發階段

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

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

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

（3）集成與部署階段

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

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



圖2.2-3 AUTOSAR AP開發方法論

02

AUTOSAR AP技術發展趨勢

2.1架構發展趨勢

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

（2）Adaptive AUTOSAR 的發展趨勢

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

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

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

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

a.面向功能安全：新增了系統健康監控，主要用于系統協調健康狀況 / 錯誤。主要包含以下內容：

SHM Client 交流平臺健康狀況；

SHM Master 確定健康指標；

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

增加了確定性同步的內容，描述了同步行為和周期性激活的要求，包括時間同步和數據同步。

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

增加了 Crypto API 的描述；

軟件和硬件解耦；

支持分離式非耦合開發；

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

② 基礎軟件技術路線

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

③ 新的分工趨勢

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

2.2 工具鏈發展方向

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

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

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

03

AUTOSAR AP關鍵技術解讀

3.1 面向服務的架構（SOA）

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

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

3.2 軟硬分離

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

3.3 虛擬化

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

04

AUTOSAR AP典型應用案例

4.1 基于 AP 的基礎軟件產品和解析

（1）日志與調試

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

基于 AP AUTOSAR 標準定義的 LT 協議，Log and Trace 模塊可以讓 AP 應用程序將信息記錄到通信總線、控制臺或文件系統上。同時 DLT 協議也提供了包括日志等級、日志 ID 等字段內容，日志客戶端可以使用此信息來關聯、排序或過濾接收到的日志幀，便于日志的解析查看以及日志相關功能的擴展。

平臺典型的日志系統架構圖如圖 2.2-4 所示：



圖2.2-4 Log And Trace案例

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

（2）日志記錄分析

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



圖2.2-5 日志記錄分析

（3）系統啟動監控

通過解析各功能模塊產生的 DLT 日志，可以分析出整個系統上電啟動過程，用戶可以直觀地觀測各功能模塊的啟動過程，并根據觀測結果調整各功能的啟動策略，達到功能模塊穩定、快速啟動的目的。

4.2 基于 AP 的應用場景介紹

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

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



圖2.2-6 IDC與外界數據交互圖

（1）數據傳輸與管理

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

② OTA 使用專用的磁盤分區保證有足夠的資源來存儲軟件包及相關數據，從而保證數據的安全性。

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

④ OTA 結束后，IDC 會刪除臨時數據，最大限度節省空間。

（2）軟件升級

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

② OTA 采用雙分區機制，通過切換啟動分區，可以實現 IDC 上所有軟件及數據的快速回滾功能。

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

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

（3）可追溯性

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

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

（4）安全性

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

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

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

審核編輯：劉清