—— AUTOSAR的基本架构
AUTOSAR平台的软件架构。它可以分为以下几部分：

• 微控制器（Microcontroller）：即控制器硬件。
• 基础软件层（Basic Software Layer，BSW）:基础软件层，它包含了以下4个部分：
• 微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：是与硬件直接相关的驱动软件，例如对存储器、通信寄存器、IO口的操作等等。
• ECU抽象层（ECU Abstraction Layer，ECUAL）：是对控制器的基础功能和接口进行统一，比如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等等。
• 服务层（Services Layer）：为应用层提供各种后台服务，比如网络管理、存储器管理、总线通信管理服务以及操作系统等。
• 复杂设备驱动（Complex Device Drivers，CDD）：为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
• 运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
• 应用软件层（Application Software Layer，ASW）：即实现具体应用功能的软件。它可以包含多个软件组件（Software Component，SWC）。

—— AUTOSAR的开发方法
AUTOSAR遵循的是一种自上而下的开发方式。即先进行系统设计，再分别进行开发实现，最终进行系统集成。
下图便是AUTOSAR开发流程的一个简要概括。虚拟功能总线（Virtual Functional Bus，VFB）是为SWC之间的通信和对BSW服务的调用提供一个虚拟的中间层。这样整车厂在初期进行系统设计时，就可以专注于软件功能模块的设计，而无需考虑硬件的限制。SWC因而也可以重复利用，并在不同项目里自由组合。

• 完成系统功能架构设计后，第2步便是将SWC分割到不同的ECU上。同一个ECU内不同SWC之间的信息交换可以在ECU内部完成，而如果不同ECU的SWC之间需要信息交换的话，那就需要通过物理总线了，比如CAN。通常来说，功能相近的SWC要放在一个ECU上，这样可以减少总线上传递的信号数量，减少总线负载，也减少传输延迟。这一步会把整个网络细节定义好，包括信号的长度、处在哪个CAN报文的哪个位置、CAN总线的比特率等等。最终生成一个AUTOSAR XML格式的系统描述文档（System Description）。
• 完成系统设计之后，就可以为每个控制器单独生成一个控制器描述文档（ECU Extract of System Description），同样是AUTOSAR XML格式。它包含了系统里跟这个ECU有关的所有信息，例如拥有哪些总线，每个总线的参数（如CAN的比特率、LIN的Schedule Table等等），在每条总线上都收发哪些信号，是否带E2E校验，包含哪些SWC，分别都收发哪些信号，等等。
• 接下来便是把这些控制器描述文档分发给各个控制器相应的供应商。供应商会从AUTOSAR基础软件提供商（如Vector、Elektrobit）购买相应的基础软件模块，并使用AUTOSAR开发工具导入控制器描述文档，就可以生成该控制器的大体框架。
• 之后供应商便可以对控制器及相应的部件进行测试。各个供应商可以通过仿真工具建立起一个虚拟的系统环境，来测试他们的部件是否与系统兼容。这也就是硬件在环测试（Hardware in the loop，HIL）。
• 各个部件开发完成后，就可以集成到一起进行测试了。由于各个部件是基于同一个系统设计开发出来的，它们集成到一起后便可以互相配合了。当然，实际当中会很多问题在单独开发测试阶段没有被发现，集成到一起之后才会被发现。之后还需要不停地进行修改、测试。但在AUTOSAR框架下，这个过程也是非常清晰的。当需要修改两个控制器之间的信号时，只要先在系统描述文档里进行修改，再生成更新后的控制器描述文档，相应地供应商再将它们导入AUTOSAR开发工具中，更新相应的信号路径、参数等，就可以很快地生成新的C代码。