AUTOSAR的分層式架構設計，用於支持完整的軟件和硬件模塊的獨立性(Independence)，中間RTE(Runtime Environment)作為虛擬功能總線VFB（Virtual Functional Bus）的實現，隔離了上層的應用軟件層（Application Layer）與下層的基礎軟件（Basic Software），擺脫了以往ECU軟件開發與驗證時對硬件系統的依賴。
軟硬件分離的分層設計，對於OEM及供應商來說，提高了系統的整合能力，尤其標準化交互接口以及軟件組件模型的定義提高了各層的軟件復用能力，從而降低了開發成本，使得系統集成與產品推出的速度極大提升。
AUTOSAR體系結構在最高抽象級別上分為三個軟件層：應用程序層、運行時環境層和在微控制器上運行的基礎軟件層。
應用軟件層
AUTOSAR的軟件被組織在獨立的單位軟件組件（software-component）中，Atomic Software component（ASWC），包括硬件無關的Application Software Component、Sensor Software Component、Actuator Software Component等。其中封裝了部分或全部汽車電子的功能與行為，包括對具體模塊功能的實現以及對應描述，但是對外界僅僅開放了定義好的接口，稱之為PortPrototypes，而所有ECU內部組件之間的通信及獲取其他ECU資源的動作就都必須要通過接口來訪問RTE來完成了。
應用軟件層內的通信關係如下：
軟件組件能和同一個ECU上其他軟件組件通信
軟件組件能和位於不同ECU上的其他軟件組件通信
軟件組件能和有端口並位於同一個ECU上的基礎軟件（BSW）進行通信
虛擬功能總線VFB及運行環境RTE
虛擬功能總線（VFB）是底層基礎軟件與網絡拓撲結構的抽象，是AUTOSAR提供的所有通信機制的集合，在信息數據交互的過程中，應用程序被建模為組合組件。當系統進行配置時，軟件組件就會被映射到指定ECU上，而同時組件間的虛擬連接也被映射到了CAN, FlexRay，MOST等總線上。最後軟件組件利用預先定義好的端口，通過VFB來實現通信。
運行環境RTE即是具體單個ECU上對VFB接口的實現，可以理解成是面向對象的編程語言中對象的創建。
各軟件組件之間不允許直接進行通信，由RTE封裝好了下層如OESK、COM等通信層BSW後，為上層提供數據通信所需的RTE API，再使用端口或者Sender-Receiver通信和Client-Server通信的方式進行交互。RTE提供基礎的通信服務，支持Software Component之間和 Software Component到BSW的通信（包括ECU內部的程序調用、 ECU外部的總線通信等情況）。RTE使應用層的軟件架構完全脫離於具體的單個ECU和BSW。
AUTOSAR基礎軟件（BSW）進一步劃分為服務層、ECU抽象層、微控制器抽象層和複雜驅動層。
圖中所示，算上複雜驅動層（Complex Device Drivers），AUTOSAR架構中共分六層：
應用軟件層（Application Layer）
運行環境RTE(Runtime Environment)
服務層（Services Layer）
ECU抽象層（ECU Abstraction Layer）
微控制器抽象層（Microcontroller Abstraction Layer）
複雜驅動（Complex Device Drivers）
基礎軟件層(BSW)層內劃分及其功能
基礎軟件層(BSW)分為Service、ECU Abstraction、Microcontroller Abstraction以及Complex Drivers。每層的BSW中包括不同的功能模塊。
服務層（Services Layer）被分為3個部分：
1. 通信服務（Communication Services）
包括CAN、LIN、FlexRay在內的整車網絡系統、ECU網絡及軟件組件內的訪問進行了統一封裝，模塊則通過通信硬件抽象層進行通信：
對上層的應用軟件層隱藏了協議以及報文屬性
提供了統一的總線通信接口供應用軟件層調用
提供了統一的網絡管理服務
提供了統一的診斷通信接口
2. 內存服務(Memory Services)
將微控制器內外內存的訪問進行統一封裝，而NVRAM管理器提供了一個RAM鏡像，來支持數據的快速讀取。
以統一的格式為上層的應用軟件層傳輸非易失性數據
抽象了內存地址以及屬性
為數據的保存、加載、校驗保護、驗證以及安全存儲提供了統一的機制
3. 系統服務（System Services）
提供RTOS服務，包括中斷管理、資源管理、任務管理等
提供功能禁止管理、通信管理、 ECU狀態管理、看門狗管理、同步時鐘管理、基本軟件模式管理等服務。
ECU抽象層被分為4部分
1. I/O硬件抽象層(I/O Hardware Abstraction)
通過I/O硬件抽象中的信號接口來訪問不同的I/O設備
對電流、電壓、頻率等I/O信號進行封裝傳輸
對上層的應用軟件層隱藏下層的ECU硬件
2. 通信硬件抽象層(Communication Hardware Abstraction)
通信硬件抽象將微控制器及板上所有的通信信道都進行了封裝，並對CAN、FlexRay、LIN、MOST等通信方式進行了抽象的定義。
3. 內存硬件抽象層（Memory Hardware Abstraction）
將片內、板上的內存資源進行統一封裝，如對片內EEPROM和片外的EEPROM都提供了統一的訪問機制。
4. 車載設備抽象層(On-board Hardware Abstraction)
對ECU上特殊的一些外設進行封裝，如WatchDog以及時鐘等。
微控制器抽象層（Microcontroller Abstraction Layer）被劃分為四部分
1. I/O驅動(I/O Drivers)
用於驅動模擬及數字I/O信號，如ADC, PWM，DIO。
2. 通信驅動(Communication Drivers)
負責車輛各模塊及整車通信，SPI、CAN等。
3. 內存驅動(Memory Drivers)
控制設備芯片內存（如片內Flash、EEPROM）及外部映射設備（外置Flash）。
4. 微處理器驅動(Microcontroller Drivers)
驅動如看門狗（Watchdog）、時鐘模塊（Clock Unit）並負責RAM測試及對微控制器抽象層內部設備和映射的微控制器抽象層外部設備的內存訪問等功能。
複雜驅動(Complex Device Drivers)
複雜驅動（CCD）層跨越於微控制器硬件層和RTE之間，其主要任務是整合具有特殊目的且不能用MCAL進行配置的非標準功能模塊，將該部分功能嵌入到AUTOSAR基礎軟件層中，從而實現處理複雜傳感器以及執行器的特定功能和時間要求。複雜驅動程序跟單片機和ECU硬件緊密相關。其上層程序接口是根據AUTOSAR指定並且實施的；其下層程序接口受標準接口程序的限制。複雜驅動可以使用特定的中斷或是複雜的微控制器外設（如PCP/TPU）來直接訪問微控制器，從而實現對複雜傳感器的評估和執行器的控制，利用中斷、TPU、PCP等來實現實時性高的傳感器採樣、執行器控制等功能。
AUTOSAR架構對軟件組織結構的統一，使得當底層硬件配置升級時不需要更改整個系統，有利於未來整車系統軟件的更新，而目前各OEM都在着力研發的智能汽車、自動駕駛等技術都對現有的汽車架構提出了較高的要求，因而AUTOSAR的推廣也成為了汽車電子行業的趨勢。
