AUTOSAR架構深度解析

本文轉載于：AUTOSAR架構深度解析

---

AUTOSAR的分層式設計，用于支持完整的軟件和硬件模塊的獨立性(Independence)，中間RTE(Runtime Environment)作為虛擬功能總線VFB（Virtual Functional Bus）的實現(xiàn)，隔離了上層的應用軟件層（Application Layer）與下層的基礎軟件（Basic Software），擺脫了以往ECU軟件開發(fā)與驗證時對硬件系統(tǒng)的依賴。

軟硬件分離的分層設計，對于OEM及供應商來說，提高了系統(tǒng)的整合能力，尤其標準化交互接口以及軟件組件模型的定義提高了各層的軟件復用能力，從而降低了開發(fā)成本，使得系統(tǒng)集成與產(chǎn)品推出的速度極大提升。

AUTOSAR分層結構及應用軟件層功能

圖中所示，算上復雜驅動層（Complex Device Drivers），AUTOSAR架構中共分六層：

應用軟件層（Application Layer）

運行環(huán)境RTE(Runtime Environment)

服務層（Services Layer）

ECU抽象層（ECU Abstraction Layer）

微控制器抽象層（Microcontroller Abstraction Layer）

復雜驅動（Complex Device Drivers）

自上而下逐層介紹：

---

應用軟件層

AUTOSAR的軟件被組織在獨立的單位軟件組件（software-component）中，其中封裝了部分或全部汽車電子的功能與行為，包括對具體模塊功能的實現(xiàn)以及對應描述，但是對外界僅僅開放了定義好的接口，稱之為PortPrototypes，而所有ECU內(nèi)部組件之間的通信及獲取其他ECU資源的動作就都必須要通過接口來訪問RTE來完成了。

應用軟件層內(nèi)的通信關系如下：

軟件組件能和同一個ECU上其他軟件組件通信

軟件組件能和位于不同ECU上的其他軟件組件通信

軟件組件能和有端口并位于同一個ECU上的基礎軟件（BSW）進行通信

---

虛擬功能總線VFB及運行環(huán)境RTE

虛擬功能總線（VFB）是底層基礎軟件與網(wǎng)絡拓撲結構的抽象，是AUTOSAR提供的所有通信機制的集合，在信息數(shù)據(jù)交互的過程中，應用程序被建模為組合組件。當系統(tǒng)進行配置時，軟件組件就會被映射到指定ECU上，而同時組件間的虛擬連接也被映射到了CAN, FlexRay，MOST等總線上。最后軟件組件利用預先定義好的端口，通過VFB來實現(xiàn)通信。

運行環(huán)境RTE即是具體單個ECU上對VFB接口的實現(xiàn)，可以理解成是面向對象的編程語言中對象的創(chuàng)建。

各軟件組件之間不允許直接進行通信，由RTE封裝好了下層如OESK、COM等通信層BSW后，為上層提供數(shù)據(jù)通信所需的RTE API，再使用端口或者Sender-Receiver通信和Client-Server通信的方式進行交互。

軟件組件「SWC1」的運行實體A通過端口「switch」向外發(fā)送名為a的數(shù)據(jù)元素，軟件組件「SWC2」的運行實體B則通過端口「cmd」接收該數(shù)據(jù)。該過程中運行實體A調(diào)用的RTE API是Rte_Write_Switch_a, 運行實體B實現(xiàn)時調(diào)用的RTE_API是Rte_Read_cmd_a。可見軟件組件在與其他軟件進行通信時，并不依賴模塊所處的網(wǎng)絡環(huán)境及特定拓撲結構。有些ECU 內(nèi)部的S/R通信API可以直接映射到賦值語句，而其他某些ECU內(nèi)的C/S通信API則可以映射為調(diào)用服務運行實體的語句。

---

基礎軟件層(BSW)層內(nèi)劃分及其功能

服務層（Services Layer）被分為3個部分：

1. 通信服務（Communication Services）
包括CAN、LIN、FlexRay在內(nèi)的整車網(wǎng)絡系統(tǒng)、ECU網(wǎng)絡及軟件組件內(nèi)的訪問進行了統(tǒng)一封裝，模塊則通過通信硬件抽象層進行通信：

• 對上層的應用軟件層隱藏了協(xié)議以及報文屬性
• 提供了統(tǒng)一的總線通信接口供應用軟件層調(diào)用
• 提供了統(tǒng)一的網(wǎng)絡管理服務
• 提供了統(tǒng)一的診斷通信接口

2. 內(nèi)存服務(Memory Services)
將微控制器內(nèi)外內(nèi)存的訪問進行統(tǒng)一封裝，而NVRAM管理器提供了一個RAM鏡像，來支持數(shù)據(jù)的快速讀取。

• 以統(tǒng)一的格式為上層的應用軟件層傳輸非易失性數(shù)據(jù)
• 抽象了內(nèi)存地址以及屬性
• 為數(shù)據(jù)的保存、加載、校驗保護、驗證以及安全存儲提供了統(tǒng)一的機制

3. 系統(tǒng)服務（System Services）

• 提供RTOS服務，包括中斷管理、資源管理、任務管理等
• 提供功能禁止管理、通信管理、 ECU狀態(tài)管理、看門狗管理、同步時鐘管理、基本軟件模式管理等服務。

ECU抽象層被分為4部分

1. I/O硬件抽象層(I/O Hardware Abstraction)

• 通過I/O硬件抽象中的信號接口來訪問不同的I/O設備
• 對電流、電壓、頻率等I/O信號進行封裝傳輸
• 對上層的應用軟件層隱藏下層的ECU硬件

2. 通信硬件抽象層(Communication Hardware Abstraction)

通信硬件抽象將微控制器及板上所有的通信信道都進行了封裝，并對CAN、FlexRay、LIN、MOST等通信方式進行了抽象的定義。

3. 內(nèi)存硬件抽象層（Memory Hardware Abstraction）

將片內(nèi)、板上的內(nèi)存資源進行統(tǒng)一封裝，如對片內(nèi)EEPROM和片外的EEPROM都提供了統(tǒng)一的訪問機制。

4. 車載設備抽象層(On-board Hardware Abstraction)

對ECU上特殊的一些外設進行封裝，如WatchDog以及時鐘等。

微控制器抽象層（Microcontroller Abstraction Layer）被劃分為四部分

1. I/O驅動(I/O Drivers)

用于驅動模擬及數(shù)字I/O信號，如ADC, PWM，DIO。

2. 通信驅動(Communication Drivers)

負責車輛各模塊及整車通信，SPI、CAN等。

3. 內(nèi)存驅動(Memory Drivers)

控制設備芯片內(nèi)存（如片內(nèi)Flash、EEPROM）及外部映射設備（外置Flash）。

4. 微處理器驅動(Microcontroller Drivers)

驅動如看門狗（Watchdog）、時鐘模塊（Clock Unit）并負責RAM測試及對微控制器抽象層內(nèi)部設備和映射的微控制器抽象層外部設備的內(nèi)存訪問等功能。

復雜驅動(Complex Device Drivers)

通過對復雜傳感器評估，利用中斷、TPU、PCP等來實現(xiàn)實時性高的傳感器采樣、執(zhí)行器控制等功能。

AUTOSAR架構對軟件組織結構的統(tǒng)一，使得當?shù)讓佑布渲蒙墪r不需要更改整個系統(tǒng)，有利于未來整車系統(tǒng)軟件的更新，而目前各OEM都在著力研發(fā)的智能汽車、自動駕駛等技術都對現(xiàn)有的汽車架構提出了較高的要求，因而AUTOSAR的推廣也成為了汽車電子行業(yè)的趨勢。

總結

以上是生活随笔為你收集整理的AUTOSAR架构深度解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。