WHAT
AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。
开放的汽车控制器（ECU）标准软件架构。
WHY 基本思想：软硬件分离
WHY——WHERE
在一个汽车控制器中，
- 应用软件：除了实现具体功能及算法的应用软件，
- 底层软件：还有许多底层软件来保证控制器的正常运行，
于是人们就想通过
- 标准化应用软件和底层软件之间的接口
来让应用软件开发者可以专注于具体应用功能的开发，而无需考虑控制器底层的运行过程。这样即使更换了处理器硬件，应用软件也无需做太多修改就可以被移植过去。
而底层软件的开发则交给专门的公司，他们为每一个处理器硬件写好驱动，并封装成标准化接口提供给上层。这样底层软件就可以被高效地集成到不同项目中。
而由于同一套底层软件被大量重复使用，发现bug的概率大大提高，从而可以很快得到修补，并且通过更新对其它项目进行同步修补。
WHY——AIM TO
- 提高软件的可扩展性和灵活性，方便应用功能的集成和转换，以及控制器网络的优化
- 提升软件的可复用性
- 降低产品和流程的复杂度和风险
- 提升软件的开发和更新速度
- 降低软件开发和维护成本
WHY——BY
- 对应用软件与底层软件之间以及应用软件之间的接口，进行标准化，
- 给出一个控制器软件参考架构，
- 规范分布式开发流程中的交换格式。
HOW
AUTOSAR的基本架构
Classic AUTOSAR架构（图片来源：AUTOSAR官网）
- 微控制器（Microcontroller）：即控制器硬件。
- 应用软件层（Application Software Layer，ASW）：即实现具体应用功能的软件。它可以包含多个软件组件（Software Component，SWC）。
- 运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
- 基础软件层（Basic Software Layer，BSW）:基础软件层，它包含了以下4个部分：
- 微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：是与硬件直接相关的驱动软件，例如对存储器、通信寄存器、IO口的操作等等。
- ECU抽象层（ECU Abstraction Layer，ECUAL）：是对控制器的基础功能和接口进行统一，比如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等等。
- 服务层（Services Layer）：为应用层提供各种后台服务，比如网络管理、存储器管理、总线通信管理服务以及操作系统等。
- 复杂设备驱动（Complex Device Drivers，CDD）：为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
AUTOSAR的开发方法
AUTOSAR遵循的是一种自上而下的开发方式。
即先进行系统设计，再分别进行开发实现，最终进行系统集成。
下图便是AUTOSAR开发流程的一个简要概括。
STEP1 系统功能架构设计
这里首先要提一下虚拟功能总线（Virtual Functional Bus，VFB）。
它是为SWC之间的通信和对BSW服务的调用提供一个虚拟的中间层。
这样整车厂在初期进行系统设计（1）时，就可以专注于软件功能模块的设计，而无需考虑硬件的限制。
SWC因而也可以重复利用，并在不同项目里自由组合。
STEP2 将SWC分割到不同的ECU上，得到系统描述文档
完成系统功能架构设计后，第2步便是将SWC分割到不同的ECU上。
- 同一个ECU内不同SWC之间的信息交换可以在ECU内部完成，
- 而如果不同ECU的SWC之间需要信息交换的话，那就需要通过物理总线了，比如CAN。
通常来说，功能相近的SWC要放在一个ECU上，这样可以减少总线上传递的信号数量，减少总线负载，也减少传输延迟。
这一步会把：
- 整个网络细节定义好，包括信号的长度、处在哪个CAN报文的哪个位置、CAN总线的比特率等等。
- 最终生成一个AUTOSAR XML格式的系统描述文档（System Description）。
STEP3 控制器描述文档
完成系统设计之后，就可以为每个控制器单独生成一个控制器描述文档（ECU Extract of System Description），同样是AUTOSAR XML格式。
它包含了系统里跟这个ECU有关的所有信息：
例如拥有哪些总线，每个总线的参数（如CAN的比特率、LIN的Schedule Table等等），在每条总线上都收发哪些信号，是否带E2E校验，包含哪些SWC，分别都收发哪些信号，等等。
STEP4 分发文档给不同供应商
接下来便是把这些控制器描述文档分发给各个控制器相应的供应商。
- 根据文档生成ECU框架：供应商会从AUTOSAR基础软件提供商（如Vector、Elektrobit）购买相应的基础软件模块，并使用AUTOSAR开发工具导入控制器描述文档，就可以生成该控制器的大体框架。
- 配置参数：之后只需要完成对各个基础软件模块的具体参数配置，就可以自动生成基础软件的C代码，包括RTE。RTE会把基础软件层与应用层的接口封装好。
- 而应用层软件的开发可以同步进行。前面已经定义好了各个SWC使用的接口，做应用层开发的时候只需要使用这些接口即可。
应用层的开发即可以是由同一个控制器的供应商来做，也可以是整车厂自己做，甚至可以将同一个控制器的不同SWC交给不同的供应商来做。
开发过程可以是基于模型的，也可以手动编写C代码。
- 等到应用层和基础软件层都开发完毕之后，由于它们使用了预设好的统一的接口，最后可以很方便地集成到一起。
STEP 5 供应商进行测试
之后供应商便可以对控制器及相应的部件进行测试。前面说过，一辆车上各个部件往往是交给不同的供应商来做的。供应商之间的开发进度往往不同步，而且一般也不会互相往来。那么供应商如何在没有其他部件的情况下，测试自己的部件是否能在系统中正确工作呢？由于我们是在一个设计好的完整系统中切割出一个个ECU Extract的，所以它已经包含了跟系统中其它部件的接口信息。
于是各个供应商可以通过仿真工具建立起一个虚拟的系统环境，来测试他们的部件是否与系统兼容。这也就是硬件在环测试（Hardware in the loop，HIL）。
各个部件开发完成后，就可以集成到一起进行测试了。由于各个部件是基于同一个系统设计开发出来的，它们集成到一起后便可以互相配合了。
当然，实际当中会很多问题在单独开发测试阶段没有被发现，集成到一起之后才会被发现。之后还需要不停地进行修改、测试。
但在AUTOSAR框架下，这个过程也是非常清晰的。当需要修改两个控制器之间的信号时，只要先在系统描述文档里进行修改，再生成更新后的控制器描述文档，相应地供应商再将它们导入AUTOSAR开发工具中，更新相应的信号路径、参数等，就可以很快地生成新的C代码。
局限
AUTOSAR的设想很美好，不过在实际应用当中还是有各种限制。
首先，目前提供AUTOSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，而由于各家对AUTOSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的。这使得应用时的灵活性受到了限制。
其次，AUTOSAR的整套工具链价格还是相当昂贵的。AUTOSAR的优势是提高软件的可复用性来降低成本，但对于一些小供应商来说，如果做的量太小的话，这一优势相对于购置整套开发环境的成本便不那么明显了。
另外，传统AUTOSAR的灵活性也是相对而言的。传统AUTOSAR用的是OSEK OS，是一个静态操作系统。其进程的数量、优先级、内存分配等等都是固定的。一旦需要做一个改动，比如添加一个通信信号，都需要重新生成一遍整个ECU的代码并刷写。
于是人们又开发出了Adaptive AUTOSAR，来满足汽车越来越高的智能化，越来越快的功能和软件更新频率要求。