摘要

如涉及高級駕駛輔助系統（ADAS）等復雜算法的應用原型通常在基于個人計算機（PC）的系統上開發。為進行驗證，這些原型必須在汽車嵌入式系統上運行。此外，隨著行業對基于 AUTOSAR 的電子控制單元（ECU）需求的不斷增長，與 AUTOSAR 環境的集成也成為必然要求。由于 AUTOSAR 方法學涉及多個必須執行的步驟，該集成過程本身耗時較長。相反，對于快速原型開發而言，非功能性需求所耗費的時間和精力應盡可能最少。本文提出了一種將非 AUTOSAR 兼容的原型代碼自動集成到 AUTOSAR 系統中的概念，同時支持特定于應用的配置和完整系統的生成。其主要目標是減少 AUTOSAR 基礎軟件（BSW）的內存占用，并集成原型代碼，從而為應用提供一個 AUTOSAR 處理器在環（Processor-in-Loop, PiL）測試環境。

1、引言

1.1 AUTOSAR概述

AUTOSAR 是汽車開放系統架構（AUTomotive Open System Architecture）的縮寫，是汽車行業軟件開發的標準化架構。它由汽車原始設備制造商（OEM）、供應商、工具提供商以及其他電子、半導體和軟件公司共同協作制定。AUTOSAR 的主要目標是制定和建立汽車電子電氣（E/E）架構的開放標準，為汽車軟件的開發提供基礎架構。采用這一行業標準，能夠實現成本節約、質量提升和復雜性降低等諸多優勢。AUTOSAR 聯盟針對應用程序接口（API）、架構、方法學等核心主題制定了相關規范。標準的 AUTOSAR 架構由三個主要層構成，分別是應用層（Application Layer）、運行時環境（RTE, Run Time Environment）和基礎軟件（BSW, Basic SoftWare）。應用層由軟件組件（SWC, SoftWare Components）組成，這些組件通過 RTE 進行通信，目標應用的核心功能即位于此層，且該層獨立于目標硬件。RTE 負責處理軟件組件之間以及 ECU 之間的信息交換，同時作為與架構下層進行通信的媒介。

RTE 的核心任務是使軟件組件擺脫對特定硬件的依賴，讓開發人員能夠專注于應用開發，且 RTE 是針對每個具體配置專門生成的。BSW 本身不具備任何應用功能，是三個主要層中對硬件依賴性最強的部分，其核心任務是為上層提供硬件無關的服務。BSW 包含多個模塊，這些模塊被歸類為五個主要部分：服務（Services）、通信（Communication）、ECU 抽象層（ECU Abstraction）、復雜設備驅動程序（CDD, Complex Device Drivers）和操作系統（OS）。每個模塊都遵循固定的規范，并提供由 AUTOSAR 定義的 API。要在 AUTOSAR 環境中運行，所有 BSW 模塊都需要進行配置，相關模塊列表可參考 [AUTOSAR 聯盟文檔]。本文重點關注的 AUTOSAR 架構中的一個重要部分是 CDD。CDD 是 AUTOSAR 中的一種機制，用于實現那些未被 AUTOSAR 支持的模塊，例如復雜的傳感器和執行器控制、非標準化驅動程序等。在 CDD 中實現的軟件代碼能夠完全符合 AUTOSAR 規范，且具有直接訪問硬件的優勢。不過，為了與其他軟件組件進行通信，CDD 仍需遵守 RTE 的相關規則。

AUTOSAR 引入 CDD 的主要目的之一是為不同 AUTOSAR 版本之間的遷移提供解決方案，從而避免對現有完整應用程序進行重新設計。此外，許多硬件模塊并未得到 AUTOSAR 的支持，例如 MOST 總線或 APIX2 等新型硬件，目前尚無對應的 AUTOSAR 模塊。而且，CDD 對 BSW 模塊的訪問限制極少。圖 1 展示了 AUTOSAR 架構中規定的軟件組件的典型結構。軟件組件包含應用功能，其代碼需遵循 AUTOSAR 規范，且具有固定的結構。端口（Ports）用于外部通信，其類型必須通過標準化接口進行指定，代碼中需采用 AUTOSAR 規定的格式實現通信。可運行實體（Runnables）是主要的可執行單元，可由定義的事件或操作系統觸發，也可視為 C 語言函數。獨占區域（EA, Exclusive Areas）是代碼中的臨界區。有關 AUTOSAR 軟件組件的更多詳細信息可參考相關規范。軟件組件的結構和行為描述通過標準的軟件組件描述文件、組件代碼及其說明共同完成，三者結合構成一個完整的軟件組件。

圖1、AUTOSAR軟件組件

1.2 原型開發

高級駕駛輔助系統（ADAS）涉及復雜的算法，在發布最終版本之前需要進行大量的原型開發。此類應用的功能大多獨立于硬件，通常在 PC 平臺上使用高級語言開發，之后再移植到嵌入式系統中。例如，Baselabs 公司的 ADAS 原型開發解決方案，其算法先以 C# 語言開發，然后轉換為 C 語言。然而，為了進行處理器在環（PiL）或硬件在環（HiL）驗證，該原型仍需在真實的 ECU 環境中進行測試。

原型開發解決方案在 PC 環境中成功驗證代碼后，還會生成 C 語言代碼，這些生成的 C 代碼可方便地與嵌入式原型開發解決方案集成，但仍需針對特定目標平臺進行適配。對于時間至關重要的快速原型開發而言，Baselabs 等公司提供的解決方案非常實用。隨著 AUTOSAR 的日益普及，ADAS 應用的快速原型開發也必須在 AUTOSAR 系統上進行，以確保 ECU 符合 AUTOSAR 標準。然而，由于 AUTOSAR 涉及多個配置步驟和復雜的方法學，要使這些原型達到可使用狀態，需要投入大量時間和專業技能，這無疑增加了開發過程的復雜性。此外，原型開發解決方案生成的 C 代碼并不符合 AUTOSAR 規范，需要進行適配才能實現集成。快速原型開發的核心應是算法本身的功能，而非原型開發平臺的底層技術細節。

因此，需要一種自動化支持來完成整個流程，包括從非兼容 C 代碼的集成到特定于應用的 AUTOSAR 系統的配置和生成。本文的目標是提出一種可與 AUTOSAR 工具配合使用的方法，實現基于 AUTOSAR 系統的自動化快速原型開發。

圖 2 展示了該方法涉及的步驟。模塊 1 接收 C 代碼和信號映射信息 / 網絡描述文件作為輸入，生成應用系統架構，并從提供的 C 代碼中提取信息，為后續步驟做準備，詳細步驟見第 3 節。模塊 2 利用模塊 1 生成的系統架構和提取的信息，為模塊 1 中的應用生成特定于 AUTOSAR BSW 的配置，同時生成部分作為 CDD 一部分的 BSW 模塊，詳細說明見第 4 節。上述模塊支持 AUTOSAR 系統架構、RTE 和 BSW 的生成，而這些組件本身由相關工具生成。本文的目的并非開發新的 AUTOSAR 工具，而是提供一種方法，將特定應用的整個 AUTOSAR 方法學流程連接起來并實現自動化。此外，AUTOSAR 已為其不同元素的各種描述提供了多個模板 [AUTOSAR 聯盟文檔]。

圖2、概念

2、現有方法

汽車領域已存在多種模型在環（MiL, Model-in-Loop）、硬件在環（HiL, Hardware-in-Loop）和處理器在環（PiL, Processor-in-Loop）方法。在 AUTOSAR 領域，已有諸如虛擬驗證平臺（Virtual Verification Platforms）之類的方法，該平臺在 x86 處理器上使用基于 Linux 的 HiL 環境，其中 CDD 被廣泛用于應用層與 RTE 的集成，原型代碼在軟實時條件下在該平臺上運行。提出了一種非常類似的快速原型開發解決方案。此外，已有研究成功實現了在符合 AUTOSAR 規范的前提下，在 BSW 中添加自定義功能。

3、與AUTOSAR的集成

前面提到的非 AUTOSAR 兼容的生成 C 代碼需要按照 AUTOSAR 規范進行適配。為此，需要對代碼進行解析，以獲取其結構和行為信息，然后對代碼進行修改，使其符合 AUTOSAR 軟件組件的規范。由于軟件組件之間存在很強的依賴性，僅通過代碼解析無法將其分離，還需要深入理解代碼所實現的邏輯。因此，按照非正式的編程標準方法，本文假設每個 C 文件對應一個軟件組件。此外，由于這些 C 文件的功能針對汽車領域，本文假設已對其進行了 MISRA-C（汽車工業軟件可靠性協會 C 語言規范）檢查。要解析 C 源代碼文件、將其集成為 AUTOSAR 軟件組件并生成相應的軟件組件描述文件，首先需要確定兩個方面的信息：結構架構和行為架構。結構架構即代碼的框架結構（對應軟件組件描述文件），而行為架構則指源代碼在運行時的表現（內部行為）。

3.1 結構架構的確定

結構架構由代碼中的各種靜態元素構成，可通過解析頭文件或 C 代碼本身來獲取：

· 函數原型：函數原型在源代碼中以函數聲明的形式存在，需將其聲明為 AUTOSAR 軟件組件中的可運行實體（Runnables）。

· 數據類型：應用程序特有的結構體和數據類型等聲明可通過解析提取，并納入應用系統架構中。此外，AUTOSAR 已指定了標準的數據類型頭文件，因此需避免重復定義。全局變量應定義為組件中的可運行實體間變量（IRV, Inter Runnable Variables），其數據類型也需在 AUTOSAR 主系統中聲明。其他類型的變量（如靜態變量或常量變量）可通過 C 語法識別，并納入軟件組件描述文件。

· 端口和接口：AUTOSAR 中的端口和接口用于實現軟件組件之間、網絡之間或與 BSW 之間的通信。當代碼中出現外部函數調用或對網絡 / 硬件通信（如 CAN 總線）的訪問時，可創建相應的端口。接口描述由參與通信的變量標識。其中一種確定接口類型的方法是檢查是否存在嵌套函數調用：若存在嵌套函數調用，則可將發送者 - 接收者接口（sender-receiver interface）映射到這些端口；若檢測到嵌套調用但仍需使用客戶端 - 服務器接口（client-server interface），則需通過代碼注釋進行標記，以便源代碼解析器識別；若函數存在返回值，則表明需要使用客戶端 - 服務器接口。諸如訪問 CAN 消息之類的網絡通信語句需要使用發送者 - 接收者接口。

· 映射：為了使軟件組件通過 AUTOSAR RTE 實現標準化通信，需要進行映射配置，這也是 RTE 生成的必要步驟。軟件組件端口之間的連接可通過檢測函數調用來確定。在本文提出的概念中，由于使用了作為 BSW 一部分生成的特定于應用的 CDD，網絡通信中的信號映射或輸入 / 輸出（IO）處理無需額外配置，詳細信息見第 4 節。

3.2 內部行為的確定

· 數據訪問：每個組件的數據訪問可通過函數作用域內的變量、接口的數據元素和全局變量來確定。若要使用測量和校準參數的相關功能，可通過顯式注釋進行說明。

· 可運行實體觸發：若可運行實體是時間觸發的，可在函數原型的注釋中注明相關條件，以便解析器識別。映射到端口的發送者接口或服務器接口決定了是否需要觸發機制。若軟件組件的可運行實體內部存在調用關系，則可將其標識為可運行實體間觸發（inter-runnable triggering）。

· 獨占區域：程序的臨界區需要開發人員明確標識，可通過注釋或特定指令從 C 源代碼中識別出獨占區域。

3.3 代碼適配

在確定了每個 C 源文件的結構和行為特性后，可生成每個組件的軟件組件描述文件及其映射關系。然而，原始代碼仍需進行修改，以適配 AUTOSAR 規范。適配工作包括以下內容：

· 包含 RTE 頭文件：#include RTE_SWCname.h

· 用 RTE 語句替換外部函數調用、網絡 / 硬件訪問：RTE_Read_SWCname_portname_interfacename (&variable)

· 函數名重命名：void SWCname_func1()

· 聲明 RTE 訪問所需的額外變量：

圖3、非AUTOSAR合規的C代碼示例

· 包含 RTE 確認語句，例如：status = E_OK

· 標記代碼中的獨占區域：void Rte_Enter_uniquename (); void Rte_Exit_uniquename ();RTE 的相關規范可參考相關文獻。本文提出的概念中，這些語句的格式規則已整合到解析工具中，若 AUTOSAR 版本發生變化，可方便地進行適配。圖 3 展示了一個 C 文件中功能代碼的典型實現。為了更好地說明，僅從該代碼中即可提取以下信息：

· 可運行實體：func1 () 和 func2 ()

· 全局變量（IRV）：globalVar

· 端口：CAN 消息發送和接收端口、外部函數調用（component_call）端口

· 接口：CAN 通信對應的 2 個發送者 - 接收者接口；component_call 函數對應的 1 個客戶端 - 服務器接口或發送者 - 接收者接口（可通過檢查其他組件確定）

· func2 () 中標記的獨占區域

· func2 () 對 func1 () 的可運行實體間觸發

· func1 () 的接收事件（數據可用）觸發當所有組件的源代碼解析完成后，可通過調用任何應用層 AUTOSAR 工具的 API，生成軟件組件及其映射關系。此外，導入網絡配置文件可確定系統拓撲結構，進而生成完整系統。提取的信息也有助于 BSW 的配置，詳細說明見第 4 節。

4、BSW配置與特定于應用的CDD生成

成功搭建應用層工具后，可生成包含 ECU 描述（使用 AUTOSAR 標準模板或工具提供的模板）的系統描述文件。該文件導入系統后，可用于 BSW/RTE 生成工具。系統描述文件采用 AUTOSAR 標準格式生成，確保了可移植性。此時，任何能夠導入標準 AUTOSAR 系統描述文件的工具都可完成 RTE 的配置。對于 AUTOSAR BSW 的配置，僅考慮必要的模塊，這些模塊的配置具有可移植性，且直接受應用特性影響。集成過程中提取的信息有助于創建操作系統任務，并將可運行實體映射到這些任務中。若為時間觸發型可運行實體，則還需要設置操作系統警報（OS alarm）。

初始化函數可作為操作系統初始化任務包含在內，或添加到調度管理器（SCHM，BSW 模塊）中。解析器需通過顯式注釋識別此類初始化函數并提取相關信息。快速原型開發平臺通常與實際目標硬件存在差異，因此并非所有 BSW 配置都能直接應用于最終的應用實現。對于那些受應用變化影響較大的動態配置（如通信驅動程序、IO 訪問等），本文提出的概念采用生成特定于應用的 BSW 并將其納入 CDD 的方式。通過這種方法，可使用精簡且優化的硬件抽象驅動程序，同時應用層仍能在目標硬件的 AUTOSAR 環境中運行，無需修改任何應用架構配置。圖 4 展示了包含生成的 CDD 的應用系統概述。集成過程（第 3 節）中獲取的映射信息用于生成標準化的 AUTOSAR 接口，以便與軟件組件進行通信。集成過程中無需映射通信信號，這一任務由生成的 CDD 棧直接完成。集成過程還包括對源代碼中的信號信息進行適配，通過 RTE 語句在主架構中創建相應的端口和接口，生成的 CDD 使用相同的接口讀取和寫入信號數據。

路由相關信息通過標準網絡描述文件（如 dbc、fibex 或 ldf 文件）獲取。對于 ADAS 等復雜算法，通常需要收集大量傳感器數據參數，這些參數也可能是大型結構體對象。生成的路由機制無需軟件組件 / 代碼行（LOC）額外付出努力即可完成數據收集，從而省去了相關工作。從圖 4 的框圖中可以看出，CDD 棧中可包含多種通信協議。這些協議單元利用配置信息生成，包含用于硬件抽象和路由的標準化接口。該層包含的驅動程序封裝了微控制器特定的代碼和地址，這些代碼和地址也是通過設備相關配置生成的。該層既可以使用自定義實現的代碼，也可以使用制造商提供的微控制器抽象層（MCAL）。包含此類 CDD 棧后，需要配置相關的 AUTOSAR BSW 模塊，以處理其依賴關系。因此，需要生成以下 BSW 模塊的配置：

· 操作系統（OS）：配置 CDD 中使用的 AUTOSAR 中斷服務程序（ISR），并創建非中斷觸發的任務。

· ECU 狀態管理器（ECUM）：該模塊包含驅動程序初始化函數列表，基于 CDD 棧的函數也需在此進行配置。

調度管理器（SCHM）：主函數需在此進行配置。圖 4 中的 BSW 配置器將生成這些配置，以供任何 BSW 工具使用。AUTOSAR 還提供了可重復使用的 BSW 模塊描述模板。對于端口等不受應用影響的其他模塊配置，可使用模板避免重復配置。

圖4、使用生成的CDD的AUTOSAR系統概述

5、實現與結果

為了驗證本文提出的方法，我們開發了一款工具，用于實現 AUTOSAR 系統的生成。實現過程中，我們使用了 SPC560P開發板，搭配符合 AUTOSAR 3.0 版本的應用層和 BSW 工具。應用原型采用傳感器融合算法，用于處理來自攝像頭和超聲波傳感器的原始圖像，該代碼包含 1000 行代碼（LOC），通過 CAN 總線收集傳感器數據。CAN 總線的通信通過包含 10 個 CAN 信號的 dbc 文件進行指定。處理后的數據通過輸出到計算機進行診斷，以完成驗證。我們使用靜態測試工具 ASTAS對生成的代碼進行 AUTOSAR 相關錯誤檢查。靜態測試通過后，將生成的代碼在上述開發板上進行編譯和執行。

圖 5 和圖 6 展示了兩種評估方法在.bss 段、代碼段和數據段內存占用方面的對比圖表。從圖表中可以看出，與方法 1 相比，方法 2 在三個段的內存占用上都實現了顯著的節省。兩種方法使用相同的應用代碼。方法 1 通過手動適配和修改代碼，將其集成到 AUTOSAR 環境中，使其符合規范，并手動使用工具為相應應用創建完整系統，該方法使用了包括 CAN 棧在內的必要 AUTOSAR BSW 模塊。方法 2 基于本文提出的概念實現，未使用 AUTOSAR CAN 棧，而是采用了第 4 節中提到的 CDD 概念。

圖5、內存使用情況比較圖表1

圖6、內存使用情況比較圖表2

6、結論

本文成功提出并實現了一種基于 AUTOSAR 的自動化快速原型開發概念。該概念定義并實現了非 AUTOSAR 兼容 C 代碼的集成、相關 BSW 的配置以及特定于應用的 CDD 生成的自動化步驟。所需輸入僅包括帶有附加注釋的 C 源代碼文件和網絡描述文件。該概念通過修改 C 源代碼文件并生成應用系統架構，將其集成到 AUTOSAR 系統中，自動完成了受應用直接影響的 BSW 模塊的配置。生成的 CDD 特定于應用、獨立于版本，作為 BSW 的一部分直接與主應用的軟件組件交互。

方法 1 的實現需要具備 AUTOSAR 相關的技能和知識，而方法 2 僅需基礎知識，且整個實現過程僅需幾分鐘，大幅減少了時間和精力成本。本文提出的概念能夠使原型代碼在符合 AUTOSAR 規范的真實 ECU 上運行，從而支持 PIL 驗證。此外，該方法顯著降低了內存占用，能夠容納更多應用組件，同時提供所需的運行環境。由于生成的 BSW 配置、應用架構和修改后的代碼均符合 AUTOSAR 標準，因此可在后續開發階段中重復使用。除快速原型開發外，CDD 棧還可用于驅動程序優化或需要特殊驅動程序的場景。

（添加微信號NewCarRen咨詢）