AUTOSAR架构深度解析
AUTOSAR架構(gòu)深度解析
本文轉(zhuǎn)載于：AUTOSAR架構(gòu)深度解析
AUTOSAR的分層式設(shè)計(jì)，用于支持完整的軟件和硬件模塊的獨(dú)立性(Independence)，中間RTE(Runtime Environment)作為虛擬功能總線VFB（Virtual Functional Bus）的實(shí)現(xiàn)，隔離了上層的應(yīng)用軟件層（Application Layer）與下層的基礎(chǔ)軟件（Basic Software），擺脫了以往ECU軟件開發(fā)與驗(yàn)證時(shí)對(duì)硬件系統(tǒng)的依賴。
軟硬件分離的分層設(shè)計(jì)，對(duì)于OEM及供應(yīng)商來說，提高了系統(tǒng)的整合能力，尤其標(biāo)準(zhǔn)化交互接口以及軟件組件模型的定義提高了各層的軟件復(fù)用能力，從而降低了開發(fā)成本，使得系統(tǒng)集成與產(chǎn)品推出的速度極大提升。
AUTOSAR分層結(jié)構(gòu)及應(yīng)用軟件層功能
圖中所示，算上復(fù)雜驅(qū)動(dòng)層（Complex Device Drivers），AUTOSAR架構(gòu)中共分六層：
自上而下逐層介紹：
應(yīng)用軟件層
AUTOSAR的軟件被組織在獨(dú)立的單位軟件組件（software-component）中，其中封裝了部分或全部汽車電子的功能與行為，包括對(duì)具體模塊功能的實(shí)現(xiàn)以及對(duì)應(yīng)描述，但是對(duì)外界僅僅開放了定義好的接口，稱之為PortPrototypes，而所有ECU內(nèi)部組件之間的通信及獲取其他ECU資源的動(dòng)作就都必須要通過接口來訪問RTE來完成了。
應(yīng)用軟件層內(nèi)的通信關(guān)系如下：
虛擬功能總線VFB及運(yùn)行環(huán)境RTE
虛擬功能總線（VFB）是底層基礎(chǔ)軟件與網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的抽象，是AUTOSAR提供的所有通信機(jī)制的集合，在信息數(shù)據(jù)交互的過程中，應(yīng)用程序被建模為組合組件。當(dāng)系統(tǒng)進(jìn)行配置時(shí)，軟件組件就會(huì)被映射到指定ECU上，而同時(shí)組件間的虛擬連接也被映射到了CAN, FlexRay，MOST等總線上。最后軟件組件利用預(yù)先定義好的端口，通過VFB來實(shí)現(xiàn)通信。
運(yùn)行環(huán)境RTE即是具體單個(gè)ECU上對(duì)VFB接口的實(shí)現(xiàn)，可以理解成是面向?qū)ο蟮木幊陶Z言中對(duì)象的創(chuàng)建。
各軟件組件之間不允許直接進(jìn)行通信，由RTE封裝好了下層如OESK、COM等通信層BSW后，為上層提供數(shù)據(jù)通信所需的RTE API，再使用端口或者Sender-Receiver通信和Client-Server通信的方式進(jìn)行交互。
軟件組件「SWC1」的運(yùn)行實(shí)體A通過端口「switch」向外發(fā)送名為a的數(shù)據(jù)元素，軟件組件「SWC2」的運(yùn)行實(shí)體B則通過端口「cmd」接收該數(shù)據(jù)。該過程中運(yùn)行實(shí)體A調(diào)用的RTE API是Rte_Write_Switch_a, 運(yùn)行實(shí)體B實(shí)現(xiàn)時(shí)調(diào)用的RTE_API是Rte_Read_cmd_a。可見軟件組件在與其他軟件進(jìn)行通信時(shí)，并不依賴模塊所處的網(wǎng)絡(luò)環(huán)境及特定拓?fù)浣Y(jié)構(gòu)。有些ECU 內(nèi)部的S/R通信API可以直接映射到賦值語句，而其他某些ECU內(nèi)的C/S通信API則可以映射為調(diào)用服務(wù)運(yùn)行實(shí)體的語句。
基礎(chǔ)軟件層(BSW)層內(nèi)劃分及其功能
服務(wù)層（Services Layer）被分為3個(gè)部分：
1. 通信服務(wù)（Communication Services）
包括CAN、LIN、FlexRay在內(nèi)的整車網(wǎng)絡(luò)系統(tǒng)、ECU網(wǎng)絡(luò)及軟件組件內(nèi)的訪問進(jìn)行了統(tǒng)一封裝，模塊則通過通信硬件抽象層進(jìn)行通信：
- 對(duì)上層的應(yīng)用軟件層隱藏了協(xié)議以及報(bào)文屬性
- 提供了統(tǒng)一的總線通信接口供應(yīng)用軟件層調(diào)用
- 提供了統(tǒng)一的網(wǎng)絡(luò)管理服務(wù)
- 提供了統(tǒng)一的診斷通信接口
2. 內(nèi)存服務(wù)(Memory Services)
將微控制器內(nèi)外內(nèi)存的訪問進(jìn)行統(tǒng)一封裝，而NVRAM管理器提供了一個(gè)RAM鏡像，來支持?jǐn)?shù)據(jù)的快速讀取。
- 以統(tǒng)一的格式為上層的應(yīng)用軟件層傳輸非易失性數(shù)據(jù)
- 抽象了內(nèi)存地址以及屬性
- 為數(shù)據(jù)的保存、加載、校驗(yàn)保護(hù)、驗(yàn)證以及安全存儲(chǔ)提供了統(tǒng)一的機(jī)制
3. 系統(tǒng)服務(wù)（System Services）
- 提供RTOS服務(wù)，包括中斷管理、資源管理、任務(wù)管理等
- 提供功能禁止管理、通信管理、 ECU狀態(tài)管理、看門狗管理、同步時(shí)鐘管理、基本軟件模式管理等服務(wù)。
ECU抽象層被分為4部分
1. I/O硬件抽象層(I/O Hardware Abstraction)
- 通過I/O硬件抽象中的信號(hào)接口來訪問不同的I/O設(shè)備
- 對(duì)電流、電壓、頻率等I/O信號(hào)進(jìn)行封裝傳輸
- 對(duì)上層的應(yīng)用軟件層隱藏下層的ECU硬件
2. 通信硬件抽象層(Communication Hardware Abstraction)
通信硬件抽象將微控制器及板上所有的通信信道都進(jìn)行了封裝，并對(duì)CAN、FlexRay、LIN、MOST等通信方式進(jìn)行了抽象的定義。
3. 內(nèi)存硬件抽象層（Memory Hardware Abstraction）
將片內(nèi)、板上的內(nèi)存資源進(jìn)行統(tǒng)一封裝，如對(duì)片內(nèi)EEPROM和片外的EEPROM都提供了統(tǒng)一的訪問機(jī)制。
4. 車載設(shè)備抽象層(On-board Hardware Abstraction)
對(duì)ECU上特殊的一些外設(shè)進(jìn)行封裝，如WatchDog以及時(shí)鐘等。
微控制器抽象層（Microcontroller Abstraction Layer）被劃分為四部分
1. I/O驅(qū)動(dòng)(I/O Drivers)
用于驅(qū)動(dòng)模擬及數(shù)字I/O信號(hào)，如ADC, PWM，DIO。
2. 通信驅(qū)動(dòng)(Communication Drivers)
負(fù)責(zé)車輛各模塊及整車通信，SPI、CAN等。
3. 內(nèi)存驅(qū)動(dòng)(Memory Drivers)
控制設(shè)備芯片內(nèi)存（如片內(nèi)Flash、EEPROM）及外部映射設(shè)備（外置Flash）。
4. 微處理器驅(qū)動(dòng)(Microcontroller Drivers)
驅(qū)動(dòng)如看門狗（Watchdog）、時(shí)鐘模塊（Clock Unit）并負(fù)責(zé)RAM測(cè)試及對(duì)微控制器抽象層內(nèi)部設(shè)備和映射的微控制器抽象層外部設(shè)備的內(nèi)存訪問等功能。
復(fù)雜驅(qū)動(dòng)(Complex Device Drivers)
通過對(duì)復(fù)雜傳感器評(píng)估，利用中斷、TPU、PCP等來實(shí)現(xiàn)實(shí)時(shí)性高的傳感器采樣、執(zhí)行器控制等功能。
AUTOSAR架構(gòu)對(duì)軟件組織結(jié)構(gòu)的統(tǒng)一，使得當(dāng)?shù)讓佑布渲蒙?jí)時(shí)不需要更改整個(gè)系統(tǒng)，有利于未來整車系統(tǒng)軟件的更新，而目前各OEM都在著力研發(fā)的智能汽車、自動(dòng)駕駛等技術(shù)都對(duì)現(xiàn)有的汽車架構(gòu)提出了較高的要求，因而AUTOSAR的推廣也成為了汽車電子行業(yè)的趨勢(shì)。
總結(jié)
以上是生活随笔為你收集整理的AUTOSAR架构深度解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python cls和self_pyth
- 下一篇： 位运算判断奇偶性