今天從整體闡述下AutoSar的架構。
談及AutoSar架構前，要稍微瞭解下AutoSar的背景知識。
汽車上控制器迅速地發展，逐漸出現同一供應商不同代別的產品無法相互移植和複用的現象，更別提不同的供應商的兼容性了。不同代別控制器無法複用，導致軟件開發成本居高不下。另外，歐洲各OEM的軟件和系統能力比較強，ECU供應商主要負責軟件底層和硬件服務，不同供應商平臺的不兼容性，導致OEM十分頭痛，問題遲遲無法得到解決。
2003年，以寶馬爲首的幾家OEM與Tier1成立AUTOSAR聯盟，希望爲汽車工業開發一套支持分佈式的、功能驅動的汽車電子軟件開發方法和電子控制單元上的軟件架構標準化方案，也就是我們說的AUTOSAR（AUTomotive Open System ARchitecture），旨在擺脫軟件對硬件和系統的依賴，降低OEM長期開發成本。
概括起來，傳統軟件開發被AutoSar取代，主要有這麼幾個原因：電子系統的複雜性不斷增長；軟件代碼量急速上升；生命週期差別:整車的生命週期往往長於ECU的生命週期；嵌入式系統不支持硬件抽象；有限的軟件模塊化；兼容性差，當硬件更換後，軟件要推倒重寫；
那麼AutoSar的應運而生，主要追求的目標就是：適用於整個產品生命週期；從軟件中把硬件抽象出來，對於不同硬件平臺具有更大的靈活性；更多的配置而非實現；標準化AUTOSAR的代碼配置/建模工具；通過對BSW的標準化提高了代碼質量；競爭力只體現於對OEM的特殊功能要求的實現；在整個汽車生命週期中，軟件可以不斷更新或升級；兼容性將覆蓋整個網絡節點，甚至適用不同OEM。
AutoSar的思想是將ECU的整個系統分層處理，將系統功能和硬件依賴性剝離開，通過AutoSar聯繫起來。AutoSar提供標準的應用程序(SWC)接口，運行環境(RTE)，基礎軟件(BSW) ，總線通信和開發流程及數據交換格式。
上面提到的分層結構，從物理層意義看，主要是Application、RTE和BSW三層。
應用層將軟件劃分成一個原子軟件組件ASWC(Atomic Software component),包括Application Software Component，Sensor Software Component和Actuator Software Component等。不同ASWC之間，以及ASWC與BSW之間都是通過VFB(Virtual Functional Bus)通信。
RTE提供基礎的通信服務，支持Software Component之間和Software Component到BSW的通信（包括ECU內部的程序調用、ECU外部的總線通信等情況）。RTE使應用層的軟件架構完全脫離於具體的單個ECU和BSW。
BSW層主要包括任務調度，系統服務，診斷服務、存儲服務、通訊協議棧，微控制器抽象層、外部硬件抽象層和複雜驅動。這裏偷個懶，截取幾張圖放這裏，大家overview地瞭解一下，後續有機會針對每一項詳細介紹的。
今天先介紹這麼多，大概感性地瞭解下，有問題後臺留言溝通。
文章首發於微信公衆號“汽車控制與人工智能”，歡迎關注。