AUTOSAR架構軟體結構簡介
阿新 • • 發佈：2019-02-20
近年隨著汽車電子化、智慧化發展，汽車CAN總線上搭載的ECU日益增多。各汽車製造商車型因策略不同ECU數目略有不同，但據統計平均一臺車約為25個模組，某些高階車型則高達百餘個。同時娛樂資訊系統作為「人類第三屏」，互動體驗正不斷擴充套件，加上車聯網程度的逐步加深，整車系統的通訊資料量正在以量級增長。
汽車電子領域迫切需要有一種全新的整車軟體設計標準來應對愈加複雜的電子設計。為此，在2003年歐洲寶馬為首幾家OEM巨頭與一些Tier1成立AUTOSAR聯盟，致力於為汽車工業開發一套支援分散式的、功能驅動的汽車電子軟體開發方法和電子控制單元上的軟體架構標準化方案，也就是我們常聽到的AUTOSAR（AUTomotiveOpenSystemARchitecture）。整車軟體系統可通過AUTOSAR架構對車載網路、系統記憶體及匯流排的診斷功能進行深度管理，它的出現有利於整車電子系統軟體的更新與交換，並改善了系統的可靠性和穩定性。
目前支援AUTOSAR標準的工具和軟體供應商都已經推出了相應的產品，提供需求管理，系統描述，軟體構件演算法模型驗證，軟體構建演算法建模，軟體構件程式碼生成，RTE生成，ECU配置以及基礎軟體和作業系統等服務，幫助OEM實現無縫的系統軟體架構開發流程。
1AUTOSAR的分層設計
AUTOSAR整體框架為分層式設計，以中介軟體RTE(Runtime Environment)為界，隔離上層的應用層（Application Layer）與下層的基礎軟體（Basic
Software）
2軟體元件SWC VFB與RTE應用層中的功能由各軟體元件（SWC）實現，元件中封裝了部分或者全部汽車電子功能，包括對其具體功能的實現以及對應描述，如控制大燈，空調等部件的運作，但與汽車硬體系統沒有連線。
在設計開發階段中，軟體元件通訊層面引入了一個新的概念，虛擬功能匯流排VFB
因此軟體元件只需向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（AUTomotiveOpenSystemARchitecture）。整車軟體系統可通過AUTOSAR架構對車載網路、系統記憶體及匯流排的診斷功能進行深度管理，它的出現有利於整車電子系統軟體的更新與交換，並改善了系統的可靠性和穩定性。
目前支援AUTOSAR標準的工具和軟體供應商都已經推出了相應的產品，提供需求管理，系統描述，軟體構件演算法模型驗證，軟體構建演算法建模，軟體構件程式碼生成，RTE生成，ECU配置以及基礎軟體和作業系統等服務，幫助OEM實現無縫的系統軟體架構開發流程。
1AUTOSAR的分層設計
- 建立獨立於硬體的分層軟體架構
- 為實施應用提供方法論，包括制定無縫的軟體架構堆疊流程並將應用軟體整合至ECU
- 制定各種車輛應用介面規範，作為應用軟體整合標準，以便軟體構件在不同汽車平臺複用
2軟體元件SWC VFB與RTE應用層中的功能由各軟體元件（SWC）實現，元件中封裝了部分或者全部汽車電子功能，包括對其具體功能的實現以及對應描述，如控制大燈，空調等部件的運作，但與汽車硬體系統沒有連線。
在設計開發階段中，軟體元件通訊層面引入了一個新的概念，虛擬功能匯流排VFB
因此軟體元件只需向VFB傳送輸出訊號，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中心