鋒影
email:[email protected]
如果你認爲本系列文章對你有所幫助，請大家有錢的捧個錢場，點擊此處贊助，贊助額0.1元起步，多少隨意
AUTOSAR架構深度解析
本文轉載於：AUTOSAR架構深度解析
AUTOSAR的分層式設計，用於支持完整的軟件和硬件模塊的獨立性(Independence)，中間RTE(Runtime Environment)作爲虛擬功能總線VFB（Virtual Functional Bus）的實現，隔離了上層的應用軟件層（Application Layer）與下層的基礎軟件（Basic Software），擺脫了以往ECU軟件開發與驗證時對硬件系統的依賴。 
軟硬件分離的分層設計，對於OEM及供應商來說，提高了系統的整合能力，尤其標準化交互接口以及軟件組件模型的定義提高了各層的軟件複用能力，從而降低了開發成本，使得系統集成與產品推出的速度極大提升。
AUTOSAR分層結構及應用軟件層功能
圖中所示，算上覆雜驅動層（Complex Device Drivers），AUTOSAR架構中共分六層：
- 應用軟件層（Application Layer）
- 運行環境RTE(Runtime Environment)
- 服務層（Services Layer）
- ECU抽象層（ECU Abstraction Layer）
- 微控制器抽象層（Microcontroller Abstraction Layer）
- 複雜驅動（Complex Device Drivers）
自上而下逐層介紹：
應用軟件層
AUTOSAR的軟件被組織在獨立的單位軟件組件（software-component）中，其中封裝了部分或全部汽車電子的功能與行爲，包括對具體模塊功能的實現以及對應描述，但是對外界僅僅開放了定義好的接口，稱之爲PortPrototypes，而所有ECU內部組件之間的通信及獲取其他ECU資源的動作就都必須要通過接口來訪問RTE來完成了。
應用軟件層內的通信關係如下：
- 軟件組件能和同一個ECU上其他軟件組件通信
- 軟件組件能和位於不同ECU上的其他軟件組件通信
- 軟件組件能和有端口並位於同一個ECU上的基礎軟件（BSW）進行通信
虛擬功能總線VFB及運行環境RTE
虛擬功能總線（VFB）是底層基礎軟件與網絡拓撲結構的抽象，是AUTOSAR提供的所有通信機制的集合，在信息數據交互的過程中，應用程序被建模爲組合組件。當系統進行配置時，軟件組件就會被映射到指定ECU上，而同時組件間的虛擬連接也被映射到了CAN, FlexRay，MOST等總線上。最後軟件組件利用預先定義好的端口，通過VFB來實現通信。
運行環境RTE即是具體單個ECU上對VFB接口的實現，可以理解成是面向對象的編程語言中對象的創建。
各軟件組件之間不允許直接進行通信，由RTE封裝好了下層如OESK、COM等通信層BSW後，爲上層提供數據通信所需的RTE API，再使用端口或者Sender-Receiver通信和Client-Server通信的方式進行交互。 
軟件組件「SWC1」的運行實體A通過端口「switch」向外發送名爲a的數據元素，軟件組件「SWC2」的運行實體B則通過端口「cmd」接收該數據。該過程中運行實體A調用的RTE API是Rte_Write_Switch_a, 運行實體B實現時調用的RTE_API是Rte_Read_cmd_a。可見軟件組件在與其他軟件進行通信時，並不依賴模塊所處的網絡環境及特定拓撲結構。有些ECU 內部的S/R通信API可以直接映射到賦值語句，而其他某些ECU內的C/S通信API則可以映射爲調用服務運行實體的語句。
基礎軟件層(BSW)層內劃分及其功能
服務層（Services Layer）被分爲3個部分：
1. 通信服務（Communication Services）
包括CAN、LIN、FlexRay在內的整車網絡系統、ECU網絡及軟件組件內的訪問進行了統一封裝，模塊則通過通信硬件抽象層進行通信：
- 對上層的應用軟件層隱藏了協議以及報文屬性
- 提供了統一的總線通信接口供應用軟件層調用
- 提供了統一的網絡管理服務
- 提供了統一的診斷通信接口
2. 內存服務(Memory Services)
將微控制器內外內存的訪問進行統一封裝，而NVRAM管理器提供了一個RAM鏡像，來支持數據的快速讀取。
- 以統一的格式爲上層的應用軟件層傳輸非易失性數據
- 抽象了內存地址以及屬性
- 爲數據的保存、加載、校驗保護、驗證以及安全存儲提供了統一的機制
3. 系統服務（System Services）
- 提供RTOS服務，包括中斷管理、資源管理、任務管理等
- 提供功能禁止管理、通信管理、 ECU狀態管理、看門狗管理、同步時鐘管理、基本軟件模式管理等服務。
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. 內存硬件抽象層（Memory Hardware Abstraction）
將片內、板上的內存資源進行統一封裝，如對片內EEPROM和片外的EEPROM都提供了統一的訪問機制。
4. 車載設備抽象層(On-board Hardware Abstraction)
對ECU上特殊的一些外設進行封裝，如WatchDog以及時鐘等。
微控制器抽象層（Microcontroller Abstraction Layer）被劃分爲四部分
1. I/O驅動(I/O Drivers)
用於驅動模擬及數字I/O信號，如ADC, PWM，DIO。
2. 通信驅動(Communication Drivers)
負責車輛各模塊及整車通信，SPI、CAN等。
3. 內存驅動(Memory Drivers)
控制設備芯片內存（如片內Flash、EEPROM）及外部映射設備（外置Flash）。
4. 微處理器驅動(Microcontroller Drivers)
驅動如看門狗（Watchdog）、時鐘模塊（Clock Unit）並負責RAM測試及對微控制器抽象層內部設備和映射的微控制器抽象層外部設備的內存訪問等功能。
複雜驅動(Complex Device Drivers)
通過對複雜傳感器評估，利用中斷、TPU、PCP等來實現實時性高的傳感器採樣、執行器控制等功能。
AUTOSAR架構對軟件組織結構的統一，使得當底層硬件配置升級時不需要更改整個系統，有利於未來整車系統軟件的更新，而目前各OEM都在着力研發的智能汽車、自動駕駛等技術都對現有的汽車架構提出了較高的要求，因而AUTOSAR的推廣也成爲了汽車電子行業的趨勢。