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的推广也成为了汽车电子行业的趋势。
