【原】一文了解汽車嵌入式AUTOSAR架構|附下載

如下展示了AUTOSAR的目標、主要挑戰和解決方案以及這些解決方案所帶來的好處。

• 處理與系統相關的快速增長的電氣/電子復雜性；

• 產品修改、升級和更新的實施靈活性；

• 提高軟件解決方案的可擴展性和交叉兼容性；

• 提高系統的軟件質量和可靠性；

• 在早期開發階段啟用錯誤檢測。

AUTOSAR 架構

Autosar架構的意義

現代車輛中電子/電氣系統的數量和這些系統的復雜性正在增加。車輛網絡日益復雜是 AUTOSAR 發展背后的動力。

現代車輛每輛都有 一百多個 ECU 。它們中的每一個都有大量的功能。不遵循標準，當ECU硬件設計改變時，軟件開發最有可能要重寫。

AUTOSAR 的應用范圍專用于汽車 ECU，并具有以下特性：

• 與硬件（傳感器和執行器）的強交互，

• 連接到車輛網絡，如 CAN、LIN、FlexRay 或以太網，

• 計算能力和內存資源有限的微控制器。

• 時間關鍵的系統和實時程序從內部存儲器執行。

分層 Autosar 架構概述

AUTOSAR 架構在三個軟件層之間的最高抽象級別上進行了區分：應用層，運行時環境，基礎軟件。

應用層

應用層是 AUTOSAR 軟件架構的最頂層，支持自定義功能實現。該層由特定的軟件組件和許多應用程序組成，它們是一組相互連接的 AUTOSAR 軟件組件，并按照指令執行特定任務。

每個 AUTOSAR 軟件組件都封裝了完整應用軟件的部分功能。AUTOSAR 沒有規定 AUTOSAR 軟件組件有多大。根據應用程序的要求，AUTOSAR 軟件組件可能是一個小型的、可重復使用的功能，例如車道保持輔助、雨刷控制、自動門解鎖等。

軟件組件之間的通信是通過使用虛擬功能總線的特定端口實現的。這些端口還可以實現軟件組件和 AUTOSAR 基礎軟件 (BSW) 之間的通信。

• 客戶端-服務端通信：客戶端可以通過支持操作的服務端發起操作的執行，服務端執行操作并立即將結果提供給客戶端（同步操作調用）。

• 發送者-接收者通信：這是一種異步通信模式，其中發送者提供一個或多個接收者所需的數據。

RTE 層為應用軟件組件提供獨立于 ECU 的接口，為應用軟件組件(SWC)提供通信服務。

• 客戶端/服務端端口，其中服務端是服務的提供者，客戶端是服務的用戶。
• 發送方/接收方端口，發送方將信息發送到一個或多個接收方。

AUTOSAR 基礎軟件 ( BSW ) 進一步分為三層：

• 服務層，

• ECU抽象層，

• 微控制器抽象和復雜設備驅動程序 (CDD)。

每一層都有不同的功能模塊，不同層之間的模塊交互都是指定的。

微控制器抽象層是基礎軟件的最底層，這意味著 MCAL 模塊可以直接訪問硬件資源。MCAL 包含內部驅動程序，這些驅動程序是直接訪問 μC 和內部外圍設備的軟件模塊。

顧名思義，MCAL 層使上層獨立于 HW（MCU）。

• 操作系統功能
• 車聯網通訊及管理服務
• 內存服務（NVRAM 管理）
• 診斷服務（UDS、錯誤處理、內存）
• ECU狀態管理、模式管理
• 邏輯和時間程序流監控（WdgM）

AUTOSAR COM模塊詳細說明

本節列出了 AUTOSAR COM 模塊所有功能模塊。有關 AUTOSAR COM 模塊在通信堆棧中的放置，請參閱下圖。

該模塊是AUTOSAR MCAL層的一部分（例如：CanDrv，LinDrv，FrDrv），它實際上與ECU的底層硬件進行交互，并為其上層提供獨立于硬件的接口。此模塊取決于硬件，并且驅動程序代碼可能會根據基礎硬件而有所不同。BusIf是唯一可以訪問此總線驅動程序的模塊。

多核微控制器的分層軟件架構

隨著汽車領域對計算資源的需求越來越高，OEM和Tier 1正在逐步引入多核 ECU 在其電子架構中的使用。此外，這些多核 ECU為新功能的引入提供了基礎， 例如功能安全要求的實施。

AUTOSAR 4.0 版引入了對多核嵌入式 RTOS 的支持。AUTOSAR 4.0 規范中引入了多核啟動/關閉、核間通信 (IOC) 等新概念，以擴展單核操作系統規范。

改進后的 Autosar 架構如下所示：

功能安全

系統的安全性取決于特定功能的預期操作。功能安全標準 ISO26262 源自 IEC-61508，指導我們采用基于汽車特定風險的方法來開發電氣和電子 (E/E) 系統。功能安全的目標是正確執行預期操作，否則系統將發生故障并轉移到可預測的安全狀態。軟件是影響系統級復雜性的參數之一。可以使用軟件開發的新技術和概念來最小化復雜性，從而有助于實現功能安全。AUTOSAR R4.0 考慮了對現代汽車軟件開發很重要的功能安全方面。

Autosar下有很多開發方法來檢測和報告軟件開發每個階段的功能錯誤。即使功能安全在整個產品開發的每個階段都適用并遵循，直到涉及到用戶。

以下是導致 E2E 保護檢測到的錯誤的典型干擾源列表：

SW相關來源：

S1。大多數生成的 RTE 中的錯誤，

S2。部分生成和部分手動編碼的 COM 中的錯誤

S3. 網絡堆棧錯誤

S4. 生成的 IOC 或 OS 出錯

硬件相關資源：

H1。硬件網絡故障

H2。網絡電磁干擾

H3. 上下文切換期間或內核之間通信時的微控制器故障

開發 SWC 接口時采用的一個實用方法示例是為數據正確性提供端到端保護。

對于每個傳輸安全相關數據的 RTE Write 或 Read 函數（如 Rte_Write_<p>_<o>()），都有對應的 E2E 保護封裝函數。

1. 封裝函數調用 AUTOSAR E2E 庫。

2. 包裝函數是軟件組件的一部分，最好是生成的。

3. 封裝函數與相應的 RTE 函數具有相同的簽名，只是代替Rte_ 的是E2EPW_。

4. E2EPW_ 函數由 SW-C 的應用邏輯調用，封裝函數執行保護/檢查并在內部調用 RTE 函數。

5. 對于 ECU 間通信，通過 E2E 保護發送的數據元素是按字節數組。字節數組被復制到 COM I-PDU 而不做任何更改。

ECU 設計和配置方法

AUTOSAR 為系統開發步驟提供了一種通用的技術方法。該圖顯示了使用 AUTOSAR 技術構建 ECU 的設計步驟概覽。這意味著必須為系統中的每個 ECU 執行這些步驟。

需要注意的是，AUTOSAR 沒有規定執行開發活動的精確順序。Autosar 既不講述流程，也不講述商業模式和“角色”和“責任”。

下圖是通常遵循的工作流程的示例。下圖分別描述了 BSW 和應用軟件的開發流程。

此階段的主要活動是從系統配置描述中提取特定于 ECU 的信息、ECU 配置以及可執行 ECU 軟件的生成。以下部分將更詳細地描述這些活動。

提取特定于 ECU 的信息

AUTOSAR ECU Configuration Extractor工具（例如 System Desk，Da-Vinci）從特定 ECU 所需的系統配置描述中提取信息。這是映射到此特定 ECU 的系統配置描述的所有元素的一對一副本。輸出是系統配置的 ECU 摘錄。網絡數據庫（例如 CAN.dbc）文件是生成 ECU 提取物 (.arxml) 的輸入。

配置（BSW）ECU

ECU 配置主要處理RTE 和基礎軟件模塊的配置。該配置基于系統配置的 ECU 摘錄中可用的參數。可用 SWC 實現和 BSW 模塊描述的集合。BSW 還包含供應商特定的 ECU 配置。這是必要的，因為輸出 ECU 配置描述具有靈活的結構，在 ECU 提取時不定義固定數量的配置參數。

必須在 BSW 配置期間定義通信模塊、MCAL、操作系統或 AUTOSAR 服務。

軟件組件實現

SWC 的初始工作從提供軟件組件描述 [SWCTempl] 的必要部分開始。即組件內部行為描述作為軟件組件相關模板的一部分。內部行為描述了組件的調度相關方面，即可運行實體及其響應的事件。此外，行為指定組件（或更準確地說是哪個可運行組件）如何響應接收到的數據元素等事件。但是，它沒有描述組件的詳細功能行為。