1.2.3 AUTOSAR方法论
AUTOSAR的方法论表述了从系统底层开发配置到ECU可执行代码生成的设计和执行步骤。其开发方法是基于虚拟功能总线（Virtual Function Bus，VFB）的方法，故在论述清楚AUTOSAR的方法论之前，需要先说清楚什么是虚拟功能总线。
在AUTOSAR中，应用程序被设计为相互连接的软件组件组合。虚拟功能总线是这些软件组件交互的通信机制。在系统配置阶段，软件组件被映射到特定的ECU上。但是在软件编写阶段，还没有办法确定ECU的个数和软件需要部署的具体ECU，故软件组件之间的虚拟连接被映射为本地连接，或是基于车载网络的通信机制。一个软件组件包含一部分或全部的功能模块，一个软件组件由代码实现和与之关联的正式描述文件组成。虚拟功能总线的概念实现了应用软件与基础软件的严格隔离，进而使软件组件可以独立于通信机制，并和其他软件组件相互通信。
通过VFB可以实现整个软件系统的完整通信，包括所有的功能提供者（架构中称为Provider或Server）和软件功能的使用者（架构中称为Receiver或Client）。因此，VFB也可以为软件提供检查功能，验证软件组件间通信的可信性。
如图1-19所示，VFB需要给整个软件系统的所有软件组件提供如下基础功能：
1）与系统中其他的软件组件进行通信。
2）与系统中的传感器和执行器进行通信。
图1-19 VFB功能实现方法
3）访问标准服务。
4）响应工作模式变化。
5）与系统中的标定、测量系统进行交互。
而VFB中，软件组件间通信通过端口（Port）通信实现，而端口的类型是由接口（Interface）定义的。设计软件组件的时候不必考虑每个软件组件具体要分配到哪个ECU上，也不必考虑软件组件间如何在车载网络中通信。故VFB的存在可以在确定车辆ECU和电气架构前就确定整个汽车电子软件的功能架构。
介绍了VFB后，再来详细讲解一下AUTOSAR的设计和开发流程。
AUTOSAR在开发过程中，主要分为三个阶段：系统配置阶段、ECU设计与配置阶段、代码生成阶段。
1.系统配置阶段
在系统配置阶段，用户需要定义系统配置文件。这是系统设计者或架构师的任务，包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模板描述文件来减少初始系统设计时的工作量。系统配置的输入是ARXML类型的文件，输出是系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。
在AUTOSAR中，所有的描述文件都是ARXML类型的文件。系统配置输入文件包含三部分内容：
1）软件组件描述，定义每个涉及的软件组件的接口内容，如数据类型、端口、接口等。
2）ECU资源描述，定义每个ECU的资源需求，如处理器、存储器、外围设备、传感器和执行器等。
3）系统约束描述，定义总线信号以及软件组件间的拓扑结构和映射关系。
系统配置的功能主要是在资源和时序关系的前提下，把软件组件映射到各个ECU上，然后借助系统配置生成器生成系统配置描述文件。描述文件包括总线映射之类的所有系统信息以及软件组件与某个ECU的映射关系。
从系统配置描述文件中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、映射到该ECU上的所有软件组件，并将这些信息放在各个ECU的提取文件中。
ECU配置主要是为该ECU添加必要的信息和数据，如任务调度、必要的基础软件模块及其配置、运行实体及任务分配等，并将结果保存在ECU配置描述文件中。该文件包含了属于特定ECU的所有信息，换言之，ECU上运行的软件可根据这些信息构造出来。
根据ECU配置描述文件中的配置信息生成RTE和基础软件配置代码，完成基础软件和软件组件的集成，最终生成ECU的可执行代码。
当然，AUTOSAR方法论不仅涵盖了从VFB设计到生成代码软件集成之间的所有步骤，还包括了标定、存储映射和数据保护等方法。其不仅规定了每一个步骤的行为，还规定了各步骤之间的衔接方式。
2.ECU设计与配置阶段
在ECU设计与配置阶段有三部分工作需要完成：建立VFB系统、开发软件功能组件以及开发系统和子系统。
根据前一阶段制定的方针做具体工作。因为所有的软件组件设计都是基于VFB的，所以在此时还没有ECU的概念，所有的软件组件都放在一起开发。整个功能描述独立于任何的ECU和网络。
这一阶段需要做的包括：具体设计VFB中的接口、模式、数据类型、软件组件及其定时。完成这一步后，整个VFB可以确定有哪些软件组件，以及这些软件组件互相之间的关系和通信等。
接下来是软件组件的设计阶段。
建立完VFB后，需要着手开始软件组件的设计。设计完成后，可以通过RTE代码生成器生成头文件，用户进而可以自己开发控制算法。
AUTOSAR Classic Platform体系结构在最高抽象级别上区分了运行在微控制器上的三个软件层：应用层（Application Layer）、运行时环境（Runtime Environment，RTE）和基本软件（Basic Software，BSW），如图1-20所示。
图1-20 AUTOSAR Classic Platform软件层架构
应用层部分是指实现特定的ECU功能的那部分软件，这部分软件负责实现ECU的逻辑功能，比如说，通过算法控制前照灯、空调、电机等，它是汽车功能的一种抽象，与ECU所使用的硬件没有关系。应用层又可以细分为软件组件（SWC），软件组件之间的信息交互不能直接进行，必须通过RTE。通过SWC概念的设计，对应用层软件进一步解耦，使得应用层中的SWC具有了被替换的可能。
中间件部分给应用层提供了通信手段，这里的通信是一种广义的通信，可以理解成接口。应用层与其他软件体的信息交互有两种：一种是应用层中的不同模块之间的信息交互；另一种是应用层模块同基础软件之间的信息交互。而RTE就是这些交互使用的接口的集散地，它汇总了所有需要和软件体外部交互的接口，如图1-21所示。从某种意义上来看，设计符合AUTOSAR的系统其实就是设计RTE。
图1-21 RTE作用机制
虽然汽车中有各种不同的ECU，它们具有各种各样的功能，但是实现这些功能所需要的基础服务是可以抽象出来的，比如I/O操作、AD操作、诊断、CAN通信、操作系统等，无非就是不同的ECU功能，所操作的IO/AD代表不同的含义，所接收发送的CAN消息代表不同的含义，操作系统调度的任务周期优先级不同。这些可以被抽象出来的基础服务被称为基础软件。根据不同的功能，可以将基础软件（BSW）继续细分成四部分：服务层（Service Layer）、ECU抽象层（ECU Abstract Layer）、微控制器抽象层（MCAL）和复杂驱动（Complex Driver）。四部分之间的互相依赖程度不尽相同。
1）服务层（Service Layer）。这一层基础软件提供了汽车ECU非应用相关的服务，包括OS、网络通信、内存管理（NVRAM）、诊断（UDS、故障管理等）、ECU状态管理模块等，它们对ECU的应用层功能提供辅助支持。这一层软件在不同领域的ECU中也非常相似，例如不同ECU中的OS的任务周期和优先级不同，不同ECU中的NVRAM的分区不同、存储的内容不同。
2）ECU抽象层（ECU Abstract Layer）。这一层软件提供了ECU应用相关的服务，它是对一个ECU的抽象，包括了所有ECU的输入输出，比如AD、DIO、PWM等。这一层软件直接实现了ECU的应用层功能，可以读取传感器状态，可以控制执行器输出，不同领域的ECU会有很大的不同。
3）微控制器抽象层（MCAL）。这一层软件是对ECU所使用的主控芯片的抽象，它与芯片的实现紧密相关，是ECU软件的最底层部分，直接与主控芯片及外设芯片进行交互，它的作用是将芯片提供的功能抽象成接口，然后把这些接口提供给上边的服务层/ECU抽象层使用。
4）复杂驱动（Complex Driver）。汽车ECU中有一些领域的ECU会处理相当复杂的硬件信号，执行相当复杂的硬件动作，例如发动机控制、ABS等，这些功能相关的软件很难抽象出来适用于所有的汽车ECU，它是与ECU的应用以及ECU所使用的硬件紧密相关的，属于AUTOSAR构架中在不同的ECU平台上无法移植的部分。
简单来说，第二阶段设计的软件层有如下特点：
1）应用软件层大部分是独立于硬件的。
2）软件组件之间的通信通过RTE访问BSW。
3）RTE表示应用程序的完整接口。
4）基础软件分为三个主要层（服务层，ECU抽象层，微控制器抽象层）和复杂的驱动程序。
5）服务，ECU（ECU）抽象和微控制器抽象。
6）服务被进一步划分为代表系统、内存和通信服务基础设施的功能组。
3.代码生成阶段
最后一个阶段是代码生成和软件集成。软件集成是以ECU为单位的。在AUTOSAR概念中，一个ECU就意味着一个微控制器加上外围电路和软件配置，因此，每个微控制器都需要ECU配置。在这一阶段首先需要进行RTE配置。RTE的配置包括建立OS任务，并将运行实体映射到OS任务上。然后是配置BSW，其中包括通信栈、操作系统、系统服务、存储、诊断、MCAL等基础软件模块。
在配置完成后，则是生成RTE、BSW、OS和MCAL代码。这些代码都是在不同的配置工具中分别生成，而最后放在编译器中统一编译成可执行文件。