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的推廣也成為了汽車電子行業的趨勢。
