AUTOSAR的全稱是AUTomotive Open System Architecture，直譯為汽車開放系統架構，是由全球汽車制造商、零部件供應商及其他電子、半導體和軟件系統公司聯合建立，緻力于為汽車工業開發一個開放的、标準化的軟件架構。簡單來說，AUTOSAR是一種開放的軟件架構，需要汽車制造商、零部件供應商、芯片供應商及軟件公司共同合作來實現該軟件架構。

AUTOSAR目前分為兩種：Classic Platform AUTOSAR和Adaptive Platform AUTOSAR，也稱為CP和AP。通常我們提到的AUTOSAR一般指Classic AUTOSAR，它是用在衆多汽車ECU上的AUTOSAR架構。而Adaptive AUTOSAR是随着近些年汽車信息娛樂系統的發展，在帶有高級操作系統(Linux或QNX)的車載Soc上使用的一種AUTOSAR架構。本文談論的是Classic AUTOSAR，因此下面提到的AUTOSAR均指Classic AUTOSAR。

那麼問題來了，為什麼要使用AUTOSAR這種軟件架構，或者說使用AUTOSAR能帶來哪些好處？

在說明AUTOSAR的優勢之前，我們先來看一下使用AUTOSAR之前的軟件開發現狀。

軟硬件耦合

傳統的汽車ECU開發，一般是由一個經驗比較豐富的軟件架構師來搭建一個項目的軟件架構。做的比較好的軟件架構可能會考慮軟件分層，比如驅動層、服務層、應用層等，做的不好的軟件架構，軟件層級可能就沒有那麼分明，在應用層甚至直接會嵌入硬件驅動相關的代碼。

多人同時開發效率低下

在AUTOSAR之前，ECU軟件開發一般按照功能模塊進行分工。不同模塊之間的數據交互需要負責相應模塊的工程師提前定義好接口，并在各自的模塊開發完成後進行聯合調試，調試過程中可能會發現定義接口時沒有考慮到的一些問題，此時需要重新設計接口并進行再一次的聯合調試。

軟件複用性低

由于傳統的ECU 軟件在開發時沒有清晰的層級劃分，軟硬件之間以及不同的功能模塊之間耦合性較大，由于MCU選型不一樣或者不同汽車主機廠的項目需求有差異，在把一套已經開發完成的軟件移植到另一個項目時，會遇到比較大的困難。

在使用AUTOSAR之後會有哪些改變呢？

軟硬件隔離

下圖的左側是在使用AUTOSAR之前的狀态，可以看到軟硬件之間的耦合性是很大的。右側是使用AUTOSAR之後的狀态，軟硬件是被分隔開來的。如果更換MCU，隻需要變更AUTOSAR架構中的一部分即可(BSW，即基礎軟件)，而處于上層的應用軟件是可以直接複用的。

軟硬件隔離

提高團隊開發效率

AUTOSAR對不同模塊之間的數據交互接口進行了統一定義(RTE)，每個模塊隻需要按照接口标準定義去開發，當開發完成後可以直接進行聯合調試，因為接口定義出現問題的概率是很低的。

軟件複用性程度提高

由于軟硬件之間進行了良好的隔離，以及模塊之間的通信接口也是按标準開發的。一個開發好的軟件可以直接根據新項目的需求取用相應的模塊，移植到另一個項目上。由于上層的應用軟件不會涉及具體的硬件，即使更換MCU應用層也無需做相應的更改。

介紹完了AUTOSAR的好處，一起來看一下AUTOSAR的具體架構。

下圖展示了AUTOSAR比較High Level的三個大的層級：應用軟件層、RTE和基礎軟件層。應用軟件層包含了汽車主機廠要求的和功能相關的軟件，RTE是應用層不同模塊之間以及應用層和基礎軟件層之間進行交互的橋梁，基礎軟件層則包含MCU及其外圍設備驅動、硬件抽象層以及為上層應用提供接口服務的服務層。

AUTOSAR基本架構

而基礎軟件層(BSW)可以再進一步劃分，如下圖的微處理器抽象層(MCAL)、ECU抽象層、服務層以及複雜驅動。

MCAL其實就是MCU的驅動軟件，對每個外設模塊的操作進行了寄存器操作的封裝，比如SPI的初始化隻需要調用一個初始化函數即可，不用關心函數内部是怎麼實現的。

ECU抽象層相比MCAL多了一些闆上硬件資源的驅動，比如外部看門狗、片外EEPROM或FLASH等，如果要使用這些硬件資源直接調用ECU抽象層的接口即可。

服務層是進一步的封裝和抽象，一般包括OS、電源狀态管理、整車網絡通信、診斷服務、存儲服務等。

複雜驅動主要包含一些不在AUTOSAR标準規範裡的一些硬件設備的驅動，比如電機驅動、一些比較複雜的傳感器驅動等。

BSW架構

以上是對AUTOSAR架構的一個大體的介紹，針對每一層都可以展開進行詳細的介紹。如果大家對AUTOSAR或者汽車軟件開發有興趣，可以關注微信公衆号“汽車軟件後花園”，獲取更多幹貨。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!