AUTOSAR架构软件结构简介
生活随笔
收集整理的這篇文章主要介紹了
AUTOSAR架构软件结构简介
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
近年隨著汽車電子化、智能化發展,汽車CAN總線上搭載的ECU日益增多。各汽車制造商車型因策略不同ECU數目略有不同,但據統計平均一臺車約為25個模塊,某些高端車型則高達百余個。同時娛樂信息系統作為「人類第三屏」,交互體驗正不斷擴展,加上車聯網程度的逐步加深,整車系統的
通信數據量正在以量級增長。
汽車電子領域迫切需要有一種全新的整車軟件設計標準來應對愈加復雜的電子設計。為此,在2003年 歐洲寶馬為首幾家OEM巨頭與一些 Tier1成立AUTOSAR聯盟,致力于為汽車工業開發一套支持分布式的、功能驅動的汽車電子軟件開發方法和電子控制單元上的 軟件架構標準化方案,也就是我們常聽到的AUTOSAR( AUTomotive Open System ARchitecture)。整車軟件系統可通過AUTOSAR架構對 車載網絡、系統內存及 總線的診斷功能進行深度管理,它的出現有利于整車電子系統軟件的更新與交換,并改善了系統的可靠性和穩定性。
目前支持AUTOSAR標準的工具和軟件供應商都已經推出了相應的產品,提供需求管理,系統描述,軟件構件算法模型驗證,軟件構建算法建模,軟件構件代碼生成,RTE生成,ECU配置以及基礎軟件和操作系統等服務,幫助OEM實現無縫的系統軟件架構開發流程。
1 AUTOSAR的分層設計AUTOSAR計劃目標主要有三個:
建立獨立于硬件的分層軟件架構 為實施應用提供方法論,包括制定無縫的軟件架構堆疊流程并將應用軟件整合至ECU 制定各種車輛應用接口規范,作為應用軟件整合標準,以便軟件構件在不同汽車平臺復用
AUTOSAR整體框架為
分層式設計,以中間件
RTE(Runtime Environment)為界,隔離上層的
應用層(Application Layer)與下層的
基礎軟件(Basic Software)
2 軟件組件SWC VFB與RTE應用層中的功能由 各軟件組件(SWC)實現,組件中封裝了部分或者全部汽車電子功能,包括對其具體功能的實現以及對應描述,如控制大燈,空調等部件的運作,但與汽車硬件系統沒有連接。
在設計開發階段中,軟件組件通信層面引入了一個新的概念, 虛擬功能總線VFB(Virtual Functional Bus),它是對AUTOSAR所有通信機制的抽象,利用VFB,開發工程師將軟件組件的通信細節抽象,只需要通過AUTOSAR所定義的接口進行描述,即能夠實現軟件組件與其他組件以及硬件之間的通信,甚至ECU內部或者是與其他ECU之間的數據傳輸。
因此軟件組件只需向VFB發送輸出信號,VFB將信息傳輸給目標組建的輸入端口,這樣的方式使得在硬件定義之前,即可完成功能軟件的驗證,而不需要依賴于傳統的硬件系統。 中間件RTE與 面向對象OO(object oriented)的編程思想非常接近,所有ECU所對應的RTE都是特定的,它負責著軟件構件間以及軟件構件與基礎軟件之間的通信。對于軟件構件來說,基礎軟件不能夠直接訪問,必須通過RTE進入。 因而RTE也被理解成是VFB的接口實現。
而 構件之間及 構件與基礎軟件的通信關系如圖所示:
值得注意的是,AUTOSAR軟件構件 無法直接訪問基礎軟件中的操作系統OS,因而在應用程序中就不存在「task」的概念,且不能動態創建線程,因此并行的任務由RTE直接管理調入的「構件運行實體」來實現。每個軟件構件也許會有一個或者多個運行實體,但是一個運行實體只對應一個入口。
3 基礎軟件層 BSW基礎軟件則被抽象為四層:
服務層包含RTOS、通信與網絡管理、內存管理、診斷服務、狀態管理、程序監控等服務;
ECU抽象層中封裝了微控制器層及外圍設備的驅動,并對微控制器內外設的訪問進行了統一,實現了軟件應用層與硬件系統的分離;
微控制器抽象層位于基礎軟件的最底層,包含了訪問微控制器的驅動(如I/O驅動、ADC驅動等),做到了上層軟件與微控制器的分離,以便應用的后續的移植復用;? 復雜驅動由于其嚴格的時序為應用層通過RTE訪問硬件提供支持。
AUTOSAR軟件架構的提出與推廣將有效縮短OEM研發與測試新架構車型的時間,未來也將會有越來越多的企業與供應商加入到AUTOSAR無縫解決方案的制定中,一定程度上將 提高不同車型平臺的軟件復用性,從而整體市場的研發成本與開發周期。
本文僅簡單介紹AUTOSAR架構的軟件結構,后續會對其中涉及到的軟件組件之間的端口定義及ECU的配置等細節進行介紹。
參考資料 《 AUTOSAR_TechnicalOverview.pdf》
《 AUTOSAR_LayeredSoftwareArchitecture.pdf》
《 AUTOSAR_SWS_VFB.pdf》
《 AUTOSAR_SWS_RTE.pdf》
《 AUTOSAR_SoftwareComponentTemplate.pdf》
汽車電子領域迫切需要有一種全新的整車軟件設計標準來應對愈加復雜的電子設計。為此,在2003年 歐洲寶馬為首幾家OEM巨頭與一些 Tier1成立AUTOSAR聯盟,致力于為汽車工業開發一套支持分布式的、功能驅動的汽車電子軟件開發方法和電子控制單元上的 軟件架構標準化方案,也就是我們常聽到的AUTOSAR( AUTomotive Open System ARchitecture)。整車軟件系統可通過AUTOSAR架構對 車載網絡、系統內存及 總線的診斷功能進行深度管理,它的出現有利于整車電子系統軟件的更新與交換,并改善了系統的可靠性和穩定性。
目前支持AUTOSAR標準的工具和軟件供應商都已經推出了相應的產品,提供需求管理,系統描述,軟件構件算法模型驗證,軟件構建算法建模,軟件構件代碼生成,RTE生成,ECU配置以及基礎軟件和操作系統等服務,幫助OEM實現無縫的系統軟件架構開發流程。
1 AUTOSAR的分層設計AUTOSAR計劃目標主要有三個:
2 軟件組件SWC VFB與RTE應用層中的功能由 各軟件組件(SWC)實現,組件中封裝了部分或者全部汽車電子功能,包括對其具體功能的實現以及對應描述,如控制大燈,空調等部件的運作,但與汽車硬件系統沒有連接。
在設計開發階段中,軟件組件通信層面引入了一個新的概念, 虛擬功能總線VFB(Virtual Functional Bus),它是對AUTOSAR所有通信機制的抽象,利用VFB,開發工程師將軟件組件的通信細節抽象,只需要通過AUTOSAR所定義的接口進行描述,即能夠實現軟件組件與其他組件以及硬件之間的通信,甚至ECU內部或者是與其他ECU之間的數據傳輸。
因此軟件組件只需向VFB發送輸出信號,VFB將信息傳輸給目標組建的輸入端口,這樣的方式使得在硬件定義之前,即可完成功能軟件的驗證,而不需要依賴于傳統的硬件系統。 中間件RTE與 面向對象OO(object oriented)的編程思想非常接近,所有ECU所對應的RTE都是特定的,它負責著軟件構件間以及軟件構件與基礎軟件之間的通信。對于軟件構件來說,基礎軟件不能夠直接訪問,必須通過RTE進入。 因而RTE也被理解成是VFB的接口實現。
而 構件之間及 構件與基礎軟件的通信關系如圖所示:
值得注意的是,AUTOSAR軟件構件 無法直接訪問基礎軟件中的操作系統OS,因而在應用程序中就不存在「task」的概念,且不能動態創建線程,因此并行的任務由RTE直接管理調入的「構件運行實體」來實現。每個軟件構件也許會有一個或者多個運行實體,但是一個運行實體只對應一個入口。
3 基礎軟件層 BSW基礎軟件則被抽象為四層:
- 服務層(Services Layer)
- ECU抽象層(ECU Abstraction Layer)
- 微控制器抽象層(Microcontroller Abstraction Layer)
- 復雜驅動(Complex Device Drivers)
服務層包含RTOS、通信與網絡管理、內存管理、診斷服務、狀態管理、程序監控等服務;
ECU抽象層中封裝了微控制器層及外圍設備的驅動,并對微控制器內外設的訪問進行了統一,實現了軟件應用層與硬件系統的分離;
微控制器抽象層位于基礎軟件的最底層,包含了訪問微控制器的驅動(如I/O驅動、ADC驅動等),做到了上層軟件與微控制器的分離,以便應用的后續的移植復用;? 復雜驅動由于其嚴格的時序為應用層通過RTE訪問硬件提供支持。
AUTOSAR軟件架構的提出與推廣將有效縮短OEM研發與測試新架構車型的時間,未來也將會有越來越多的企業與供應商加入到AUTOSAR無縫解決方案的制定中,一定程度上將 提高不同車型平臺的軟件復用性,從而整體市場的研發成本與開發周期。
本文僅簡單介紹AUTOSAR架構的軟件結構,后續會對其中涉及到的軟件組件之間的端口定義及ECU的配置等細節進行介紹。
參考資料 《 AUTOSAR_TechnicalOverview.pdf》
《 AUTOSAR_LayeredSoftwareArchitecture.pdf》
《 AUTOSAR_SWS_VFB.pdf》
《 AUTOSAR_SWS_RTE.pdf》
《 AUTOSAR_SoftwareComponentTemplate.pdf》
《 ECU軟件的AUTOSAR分層架構 》浙江大學ESE中心
轉載自 http://mp.weixin.qq.com/s/SgX8LLo0bWcOhNcX9mx1rg
總結
以上是生活随笔為你收集整理的AUTOSAR架构软件结构简介的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 查理·芒格提炼的9个思维模型
- 下一篇: js数组方法总结