精心整理的 CP AUTOSAR科普介绍材料

一、AUTOSAR的背景介绍

AUTOSAR是AUTOmotive Open System Architecture（汽车开放系统架构）的首字母缩写，是由全球各大汽车整车厂、汽车零部件供应商、汽车电子软件系统公司联合建立的一套标准协议，是对汽车技术开发一百多年来的经验总结。从2003年起，拟定了一个符合汽车电子软件开发的、开放的以及标准化的软件架构。该架构旨在改善汽车电子系统软件的更新与交换，同时更方便有效地管理日趋复杂的汽车电子软件系统。AUTOSAR规范的运用使得不同结构的电子控制单元的接口特征标椎化，应用软件具备更好的可扩展性以及可移植性，能够实现对现有软件的重用，大大降低了重复性工作，缩短开发周期。

AUTOSAR成员之间开展合作的主要目标是：使基本系统功能以及接口标椎化，使软件开发合作伙伴之间能交换、转换和集成各自的车载网络功能，最大限度地提高车辆售后的软件更新和系统升级效率。有了这个标准，AUTOSAR可以把范例从一个基于ECU的系统转移到基于功能的系统进行设计开发，统筹技术和经济方面对不断增长的E/E复杂性的汽车软件开发的管理。由于AUTOSAR提倡“在标准上合作，在实现上竞争”的原则，其核心思想是“统一标准、分散实施、集中配置”，所以采用AUTOSAR将为OEM带来很多好处，使得他们对于软件采购和控制拥有更大和更灵活的权利。软件系统的开放化和标准化将使更多的软件供应商进入汽车电子软件行业，OEM将有更多的选择，这将有利于提高软件产品的质量。

AUTOSAR的计划目标主要有三个：

• 1）建立分层的体系架构
• 2）为应用程序的开发提供方法论
• 3）制定各种应用接口规范

二、AUTOSAR的分层模型

为了实现应用程序和硬件模块之间的分离，AUTOSAR架构被抽象成四层，由上至下依次为：应用层（Application Layer）、运行时环境层（Run Time Environment，即RTE）、基础软件层（Basic Software，即BSW），以及微控制器层（Microcontroller）。如下图所示。

AUTOSAR软件体系结构包含了完全独立于硬件的应用层（APP）和与硬件相关的基础软件层（BSW），并在两者中间设立了一个运行时环境（RTE），从而使两者分离，形成了一个分层体系架构。RTE是专门为应用软件（AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件）提供通信服务的层。在RTE之上，软件架构风格从“分层”转变为“组件风格”。AUTOSAR软件组件通过RTE与其他组件（内部和/或内部ECU）或服务进行通信。所以，这样的分层结构带来两个最大的好处，一方面，OEM可以专注于开发特定的、有竞争力的应用层软件（位于RTE之上），另一方面，它使OEM所不关心的基础软件层（位于RTE之下）得到标准化。

三、AUTOSAR的方法论

AUTOSAR为汽车电子软件系统开发过程定义了一套通用的技术方法，即AUTOSAR方法论。该方法描述了从系统底层配置到ECU可执行代码产生过程的设计步骤，如下图所示。

AUTOSAR设计和开发流程分为三个阶段：系统配置、ECU设计与配置阶段、代码生成阶段。

• 第一阶段：定义系统配置文件，这是系统设计者或架构师的任务。包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模板描述文件来减少初始系统设计时的工作量。系统配置的输入是XML类型的文件，输出是系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。
• 第二阶段：根据系统配置描述文件提取单个ECU资源相关的信息，提取出来的信息生成ECU提取文件。根据这个提取文件对ECU进行配置，例如操作系统任务调度，必要的BSW模块及其配置，运行实体到任务的分配等，从而生成ECU配置描述文件。该描述文件包含了特定ECU的所有信息。
• 第三阶段：生成代码，是基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关代码链接起来形成可执行文件。

具体的开发流程如下：

1. 编写系统配置输入描述文件
   在AUTOSAR中，所有的描述文件都是XML类型的文件。系统配置输入文件包含三部分内容：
   1）软件组件描述，定义了每个涉及的软件组件的接口内容，如数据类型，端口，接口等。
   2）ECU资源描述，定义了每个ECU的资源需求，如处理器、存储器、外围设备、传感器和执行器等。
   3）系统约束描述，定义了总线信号，软件组件间的拓扑结构和映射关系。
2. 系统配置
   系统配置的功能主要是在资源和时序关系的前提下，把软件组件映射到各个ECU上，然后借助系统配置生成器生成系统配置描述文件。这个描述文件包括总线映射之类的所有系统信息以及软件组件与某个ECU的映射关系。
3. 提取特定ECU的描述
   从系统配置描述文件中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、映射到该ECU上的所有软件组件，并将这些信息放在各个ECU的提取文件中。
4. ECU配置
   ECU配置主要是为该ECU添加必要的信息和数据，如任务调度、必要的基础软件模块及其配置、运行实体及任务分配等，并将结果保存在ECU配置描述文件中，该文件包含了属于特定ECU的所有信息，换言之，ECU上运行的软件可根据这些信息构造出来。
5. 生成可执行文件
   根据ECU配置描述文件中的配置信息，生成RTE和基础软件配置代码，完成基础软件和软件组件的集成，最终生成ECU的可执行代码。

四、AUTOSAR的接口类型

通过RTE实现AUTOSAR软件组件之间以及应用层与基础软件之间的通信前提是：软件组件之间必须有标准的AUTOSAR接口。AUTOSAR规范把汽车电子领域内的一些典型的应用划分为若干个由一个或多个软件组件组成的模块，并详细定义了这些软件组件相关的参数，例如名称、范围、类型等。

AUTOSAR定义了三种接口：标椎化接口（Standardized Interface）、AUTOSAR接口（AUTOSAR Interface）和标准化的AUTOSAR接口（Standardized AUTOSAR Interface）。

• AUTOSAR接口是一种与应用相关的接口，与RTE一并生成。基于AUTOSAR接口的端口可以用于软件组件（Software Component,SWC）之间或者软件组件与ECU固件之间（例如复杂驱动）的通信；
• 标准化AUTOSAR接口是一种特殊的AUTOSAR接口。这些在AUTOSAR规范中定义过的接口被SWC用于访问AUTOSAR BSW模块提供的服务，比如ECU管理模块或者诊断事件管理模块；
• 标椎化接口是AUTOSAR规范中用C语言定义的API。这些接口用于ECU内部BSW模块之间，RTE和操作系统之间或者RTE和COM模块之间；

如图所示，基础软件之间通过标椎化接口进行数据通信和操作调用的。故基础软件之间可以相互调用各自的API函数，但是微控制器抽象层只能被ECU抽象层所调用，底层驱动信息通过ECU抽象层传递给服务层使用。

五、AUTOSAR的基础软件层

在上述AUTOSAR的分层模型中，最重要也是最复杂的，莫过于基础软件层BSW了。所以，接下去会花大篇幅重点介绍一下这个BSW。

首先，对基础软件层BSW进行进一步的细分，划分为4层：微控制器抽象层，ECU抽象层，服务层以及复杂驱动层。其中：

• 微控制器抽象层（MicroController Abstraction Layer，即MCAL），它位于BSW的最底层，包含了跟硬件相关的驱动程序、软件模块与直接访问微控制器内部和外围的设备，可以用来访问内存、通信和I/O等；
• ECU抽象层（ECU Abstraction Layer），位于微控制器抽象层之上，对接微控制器抽象层所提供的驱动程序，并同时包含对外部设备的驱动程序，然后负责向上提供统一的访问接口实现对通信、内存或者I/O的访问，从而使得上层模块无须考虑这些资源由微处理器提供还是由外部设备提供；
• 服务层（Service Layer），提供各种类型的后台服务，例如网络服务、内存管理和总线通信服务等，操作系统就位于这一层。服务层是基础软件的最高层，同时与应用程序也有关联。虽然对I/O信号的访问由ECU抽象层覆盖，但服务层负责提供以下接口：操作系统的功能、车辆网络通信管理服务、存储器服务（NVRAM管理）、诊断服务（包括UDS通信、错误存储和故障处理）、ECU状态管理，模式管理、逻辑和时间程序流监控（Wdg管理器）、密码服务（密码服务管理）；
• 复杂驱动层（Complex Drivers Layer，即CCD），跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求，提供集成特殊用途的功能，例如设备驱动程序，在AUTOSAR中未规定的、具有非常高的时间限制或用于迁移等目的；

如下图所示：

所以，总结一下，基础软件层BSW的组件及其功能对应如下：

1. 系统：提供标准化的规定（针对操作系统、定时器以及错误存储器）、ECU特定的服务（ECU状态管理、看门狗管理）和库函数；
2. 内存：对内部和外部的内存（非易失性存储器）的访问入口进行标准化；
3. 通信：对汽车网络系统、ECU通信系统以及ECU内部软件的访问入口进行标准化；
4. 输入/输出：对传感器、执行器以及ECU外设的访问入口进行标准化；

同时，对BSW中的各个子层，还可以从功能上将其中的各个模块划分为4种类型，分别为驱动模块Driver、接口模块Interface、处理模块Handler以及管理器Manager。

1. 驱动模块Driver
   驱动模块包含了控制和使用内部或者外部器件的功能，分为内部驱动和外部驱动。
   1）内部驱动
   内部器件位于微控制器（单片机）的内部，例如内部EEPROM、内部CAN控制器、内部ADC模块等。
   内部驱动程序就是针对单片机内部器件资源的驱动程序，这部分驱动程序属于微控制器抽象层（MCAL）。
   2）外部驱动
   外部器件是指单片机外部的ECU硬件，比如外部EEPROM、外部看门狗、外部Flash等。外部驱动程序就是针对单片机外部硬件资源的驱动程序，属于ECU抽象层。外部驱动程序需要通过微控制器抽象层（MCAL）驱动程序来实现对外部器件的驱动。这种方法下AUTOSAR也支持嵌入在系统基础芯片（SBCs）中的组件，像收发器以及看门狗等。例如，使用SPI通信接口的外部EEPROM驱动程序是通过SPI总线处理程序来驱动外部EEPROM的。但是有一种例外，对于和内存映射相关的外部器件（如外部Flash存储器），其驱动程序是可以直接对微控制器进行存取访问的，所以这部分驱动程序属于微控制器抽象层（MCAL）。
2. 接口模块Interface
   接口模块包含了对其次级模块进行抽象的功能，比如对一个特定功能的硬件进行抽象。它提供一个通用的接口函数（API）来访问一种特定的器件类型，且与该类型器件的数目无关，同时也与器件的具体硬件实现无关。
   接口模块不会改变数据的内容。一般来说，接口属于ECU抽象层。例如，CAN通信系统的接口模块提供一个通用的接口函数来访问CAN通信网络，并且与ECU上CAN控制器的数目以及硬件实现无关。
3. 处理模块Handler
   处理模块是一个专用的接口，它控制一个或多个客户端对一个或多个驱动程序进行并行、多重以及异步地访问。也就是说，它起着缓冲、队列、仲裁以及多路复用的功能。同时，处理程序也不会改变数据本身的内容。处理模块通常会并入驱动程序或是接口模块中（如SPIHandlerDriver、ADC Driver等）。
4. 管理器Manager
   管理器为多重的客户端提供特定的服务。当单纯的处理程序不能满足对多重的客户端进行抽象时，就需要用到管理器来进行处理。除了处理功能外，管理器还可以对数据内容进行评估、改变或是适应数据内容。
   一般而言，管理器属于服务层。例如，非易失性随机存储器（NVRAM）的管理器负责对内部或是外部存储设备进行并行的访问，如Flash、EEPROM存储器等。同时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等。

从上面的划分角度出发，同时考虑到基础软件层主要用于向上提供基础软件服务，包括标准化的系统功能以及功能接口。所以，也可以从服务类型的角度，将上述4个子层更进一步的细分成一系列的基础服务软件组件，包括系统服务（System Services）、存储服务（Memory Services）、通信服务（Communication Services）、以及IO服务（I/O Services）等，如下图：

下面进行展开解释：

1、微控制器抽象层

微控制器器抽象层位于AUTOSAR分层模型中的BSW的最底层，它包含内部驱动，可以直接访问微控制器和片内外设。进一步的，MCAL又可分为微控制器驱动模块组（Microcontroller Drivers）、存储器驱动模块组（Memory Drivers）、通信驱动模块组（Communication Drivers）、以及I/O 驱动模块组（I/O Drivers）。各个部分又由具体的与微控制器硬件相对应的驱动模块组成，如下图：

1.1、微控制器驱动

微控制器驱动由通用定时器驱动（General Purpose Driver，GPT Driver）、看门狗驱动（Watchdog Driver，WDG Driver）、微控制器单元驱动（Microcontroller Unit Driver，MCU Driver）和内核测试（Core Test）四个部分组成。

1.1.1、GPT Driver

在AUTOSAR中有两类定时器，操作系统定时器和硬件定时器。该模块使用通用定时器单元的硬件定时器通道，为操作系统或者其他基础软件模块提供计时功能。一个典型的时间周期是50us-5ms。

GPT驱动的作用是：

• 启动和停止硬件定时器；
• 得到定时器数值；
• 控制时间触发的中断；
• 控制时间触发的中断唤醒。

1.1.2、WDG Driver

WDG Driver的功能主要是初始化和触发看门狗。WDG Driver有内部WDG Driver和外部WDG Driver。内部WDG Driver控制MCU的内部看门狗定时器，提供触发功能和模式选择服务；外部WDG Driver控制外部硬件看门狗，与内部WDG Driver一样，提供触发功能和模式选择服务。

1.1.3、MCU Driver

MCU Driver位于MCAL层，可以直接访问微控制器硬件，它的主要功能是初始化、休眠、复位微控制器以及提供其他MCAL软件模块所需的与微控制器相关的特殊功能。MCU Driver还能够使能并设置MCU时钟，例如CPU时钟、外围器件时钟、预分频器等参数。

1.1.4、Core Test

Core Test（内核测试）模块包含周期性测试和启动测试。内核测试模块可以对CPU所有寄存器进行测试，提供中断控制和异常检测。该模块还对算术逻辑单元、存储保护单元和缓存控制器等进行检测。

1.2、存储器驱动

存储器驱动由内部EEPROM驱动、内部Flash驱动、RAM测试和Flash测试四部分组成。

1.2.1、内部EEPROM驱动

内部EEPROM驱动提供初始化服务，以及对内部EEPROM的读写、写、擦除等操作。该驱动模块一次只能接受一个任务。

1.2.2、内部Flash驱动

内部Flash驱动提供内部Flash初始化服务，以及对内部Flash的读、写、擦除等操作。该驱动还可以将Flash访问代码下载到RAM中，如果需要的话，也可以执行写、擦除操作。

1.2.3、RAM测试

RAM测试模块通过软件对RAM存储进行测试。该模块包含后台测试和前台测试。其中，后台测试是异步服务，前台测试是同步服务。

1.2.4、Flash测试

flash测试模块提供算法来测试诸如数据/程序闪存、程序SRAM等非易失性存储器，这些存储器可以是集成在微控制器内部的，也可以是外部映射到微控制器的存储器。

1.3、通信驱动

通信驱动由以太网（Ethernet）驱动、FlexRay驱动、CAN驱动、LIN驱动和SPI驱动五部分组成。

1.3.1、Ethernet驱动

Ethernet驱动模块使用以太网驱动层访问某些控制器，对所使用的以太网控制器的硬件特性进行抽象，为上层的以太网使用提供统一的接口。可由由若干个以太网驱动模块复合起来组成。

1.3.2、FlexRay驱动

FlexRay驱动用来抽象不同的FlexRay通信控制器及其硬件相关的特性。通信控制器的FlexRay协议强制特性经过封装后只能通过统一的API进行访问。API提供了映射到基于实际通信控制器的硬件访问序列的抽象功能操作。因此，使用FlexRay驱动可以保证FlexRay接口独立于硬件。

对内部或外部FlexRay通信控制器的驱动来说，需要进行下列处理：

• FlexRay控制器的初始化；
• 配置数据处理单元；
• 控制指令向通信控制器的传递；
• 从协议引擎到控制器主接口状态数据的规定；
• 通信控制器和主处理机之间信息数据的传输。

1.3.3、CAN驱动

CAN驱动针对的是微控制器内部的CAN控制器，它可以实现以下功能：

• 对CAN控制器进行初始化；
• 发送和接收报文；
• 对报文的数据和功能进行通知（对接收报文的指示、对发送报文的确认）；
• 溢出和错误处理；
• 唤醒检测；

此外，CAN驱动还具有以下特性：

• 单个或多个CAN通道；
• CAN驱动的多重实例化；
• 对接收报文的中断/轮询模式；

CAN驱动是MCAL的一部分，可以执行硬件访问、向上层提供独立于硬件的API，而仅有的能够访问CAN驱动的上层是CAN接口（CAN Interface）。CAN驱动也可以为数据传输的初始化和通知接收事件的回调函数提供服务，该服务也是独立于硬件的。除此之外，CAN驱动也可以控制从属于同一个CAN硬件单元的CAN控制器的行为和状态。

1.3.4、LIN驱动

LIN驱动使用标准的通用异步收发器（Universal Asynchronous Receiver Transmitter，UART）或者串行通信接口（Serial Communication Interface，SCI）进行通信。

该模块可以完成下列任务：

• LIN硬件的初始化；
• 调度表的处理；
• LIN报文的发送（通过标志位和函数接口确认）；
• LIN报文的接收（通过标志位和函数接口指示）；
• 睡眠和唤醒；
• 协议差错的处理；
• 报文的超时监测；

LIN驱动也是MCAL的一部分，可以执行硬件访问、向上层提供独立于硬件的API。仅有的能够访问LIN驱动的上层是LIN接口（LIN Interface）。一个LIN驱动可以支持多个通道，但是这些通道要属于同一个LIN硬件单元。

1.3.5SPI驱动

SPI驱动模块是微控制器内部同步通信串行接口的驱动。SPI驱动为SPI总线上不同的设备（如EEPROM/Watchdog等）提供读写访问服务。一个SPI设备可以被所使用的SPI硬件和相关的片选信号识别。该模块可以在主、从或者主-从模式下运行。

配置SPI驱动应遵循以下步骤：

• 选择SPI驱动的功能级别，配置可选择的功能特性；
• 根据数据用途来定义SPI通道，它们可以是SPI驱动的内部缓冲器，或者是由用户提供的外部缓冲器；
• 根据硬件属性来定义SPI任务，它们会包含一系列使用这些属性的通道；
• 最后定义任务序列，以优先级排序的方式来传递数据；

1.4、I/O驱动

I/O驱动由PORT驱动、DIO驱动、ADC驱动、PWM驱动、ICU驱动、OCU驱动六部分组成。

1.4.1、PORT驱动

PORT驱动初始化就是对微控制器的整个PORT模块进行初始化配置。

很多端口和管脚被分配有多种不同的功能，即可以进行引脚功能复用，比如通用I/O、模数转换、脉宽调制等功能。因此，对PORT必须有一个整体的配置和初始化，对各管脚的具体配置和使用取决于微控制器和ECU的引脚功能分配。PORT初始化数据应当尽可能高效地写到每个端口。DIO驱动中所用到的端口的配置和初始化都是在PORT驱动模块中完成的。因此，在使用DIO功能之前，应先进行PORT的初始化。

1.4.2、DIO驱动

DIO驱动对微控制器硬件管脚的访问进行了抽象，除此之外，还可以对管脚进行分组。该模块通过DIO通道、DIO端口以及DIO通道组来读写数据，而且这类操作是同步的。

1.4.3、ADC驱动

ADC驱动对微控制器内部模数转换单元进行初始化和控制。它可以提供启动和停止模数转换的服务，分别用来开启和禁用模数转换的触发源。

1.4.4、PWM驱动

PWM驱动为微控制器PWM模块提供初始化和控制服务，可生成周期和占空比都可变的脉冲。

1.4.5、ICU驱动

ICU驱动控制的是微控制器的输入捕获单元（Input Capture Unit），有两种模式：正常模式和休眠模式。

ICU驱动可以提供以下服务：

• 信号边沿检测及通知；
• 中断唤醒；
• 周期性信号时间的测量；
• 边沿时间戳捕获；
• 边沿/脉冲计数；

1.4.6OCU驱动

OCU驱动的作用是对微控制器内部的输出比较单元（Output Compare Unit）进行初始化和控制。当计数器的值到达某个阈值时，OCU模块会自动开始比较并执行相应的操作。

OCU驱动还可以为下列功能提供服务：

• 启动或停止输出通道；
• 设定某个阈值；
• 启用或禁用某个通道的通知函数；
• 获取计数器数值；

2、ECU抽象层

ECU抽象层负责提供统一的访问接口，实现对通信、内存或者IO口的访问，从而无须考虑这些资源是由微处理器提供的还是由外部设备提供的。外部设备的驱动就位于这一层。ECU抽象层主要包括板载设备抽象、存储器硬件抽象、通信硬件抽象以及IO硬件抽象4个部分。

2.1、I/O硬件抽象

I/O硬件抽象是一组模块从外设I/O设备（片上或板载）和ECU硬件布局（例如µC pin脚连接和信号电平倒置）抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来。不同的I/O设备可以通过I/O信号接口访问。

通信硬件抽象是一组模块从通信控制器和ECU硬件布局抽象出来。对于所有的通信系统都需要一个特定的通信硬件抽象（e.g. for LIN, CAN, FlexRay）。

例如：一个ECU微控制器有2个内部CAN通道和一个附加的板载带有4个CAN控制器的ASIC芯片，CAN-ASIC通过SPI方式连接微控制器。

通信驱动被访问通过总线特定的接口（CAN Interface）。

2.2、存储器硬件抽象

存储器硬件抽象是一组模块从外设存储设备（芯片或板载）和ECU硬件布局抽象出来。

例如：芯片上的EEPROM和外部的EEPROM设备都可以通过相同的机制访问。

存储设备被访问通过存储器特定的抽象/仿真模块（例如EEPROM 抽象）。

2.3、板载设备抽象

板载设备抽象包含ECU板载设备驱动，例如内部或外部看门狗，这些驱动访问ECU板载设备通过µC抽象层。

3、服务层

服务层是基础软件层的最高层，它可以实现与应用层软件的关联。I/O信号可以通过ECU抽象层进行获取，此外服务层还提供：操作系统功能、汽车网络通信以及管理功能、内存服务、诊断服务（包含统一诊断服务UDS，错误记忆和故障处理）、ECU状态和模式管理、逻辑与暂时程序流程监管（看门狗管理）、加密服务等；

服务层的主要任务是为应用程序、RTE以及基础软件模块提供最基本的服务。服务层的上层接口保证了微控制器和ECU硬件的独立。

按照服务对象的不同，服务层又分为三个部分，分别为通信服务，内存服务、和系统服务。

3.1、通信服务

通信服务是一组用于车辆网络通信的模块（CAN、LIN、FlexRay以及Ethernet）。通信服务通过通信硬件抽象来与通信驱动程序进行交互。其主要任务是为车辆通信网络和车载网络的诊断通道提供一个统一的接口，为网络管理提供统一的五福，以及从赢哦有那个程序中隐藏相关协议和消息属性。

3.1.1、CAN

CAN通信服务是一组带有CAN通信系统的车辆网络通信。为CAN网络提供统一的接口。应用程序中隐藏协议和消息属性。

CAN通信服务的实施与单片机和ECU硬件无关，但部分依赖于CAN通信本身；

AUTOSAR COM、Generic NM （Network Management）Interface 和 Diagnostic Communication Manager对于所有车辆网络系统都是相同的，并且每个ECU作为一个实例存在。

Generic NM Interface 只包含一个调度程序，不包含其他功能，对于网关ECUs，它还可以包括NM协调器功能，允许同步多个不同的网络（相同或不同类型的）同步唤醒它们或关闭他们。

CAN NM是针对特定CAN网络的，并且通过车辆CAN网络系统进行具体实现。可以通过底层网络适配器（CAN NM）与CAN Generic NM interfaces 连接。

通信系统特定的CAN状态管理器能够管控与通信系统相关的启动和关闭功能。此外，它还可以通过控制COM的不同选项来实现发送PDU以及监控信号超时的功能；

3.1.2、J1939

J1939通信服务是对普通CAN通信协议栈的拓展，主要应用在商用车上。其主要任务是提供J1939通信所需的协议服务，同时从应用程序中隐藏不需要的协议和消息属性。

J1939通信服务具有以下属性：

• J1939通信服务的实施与单片机和ECU硬件无关，它是基于CAN通信的；
• AUTOSAR COM、通用网络管理接口（Generic NM Interface）以及诊断通信管理器（Diagnostic Com.Manager）对所有的车辆网络系统都是通用的，并且作为每个ECU的一个实例而存在；
• 支持在配置阶段未知的动态帧标识符；
• J1939网络管理器管控每一个ECU的特定地址分配，但它不支持休眠/唤醒处理以及其他相关的概念，如局部网络等；
• 提供J1939诊断和请求处理；

3.1.3、 LIN （LIN Master）

LIN通信服务是一组车辆LIN通信系统的模块。其主要任务是为LIN通信网络提供一套统一的接口，同时从应用程序中隐藏协议内容和消息属性。

LIN（主）通信服务具有以下属性：与LIN 2.1兼容的通信协议栈：调度表管理器，用于传输LIN帧和处理切换到其他调度表的请求；传输协议，用于诊断；一个唤醒和休眠接口；

底层LIN驱动：实现LIN协议并对特定硬件进行调整；支持简单的UART和基于LIN硬件的复杂框架；

Lin Interface 控制唤醒/休眠 API，并且允许从节点保持总线 awake （分散管理的方法 decentralized approach）；

通信系统特定LIN State Manager 依靠 Start-up 和 Shutdown 特性处理通信。此外，它还控制来自通信管理器的通信模式请求。LIN state manager 还通过接口COM 控制 I-PDU 组。

当发送LIN帧时，LIN接口需要数据的时刻（即在发送LIN帧之前）从PDU路由器请求帧（I-PDU）的数据。

3.1.4、Communication Services – LIN Slave

LIN Slave 通常是 “智能” 执行器，并且被视为黑盒。由于它们提供的硬件能力和资源非常少，并不打算将AUTOSAR软件组件转移到这样的系统上。因此，没有必要在LIN Slave 上安装AUTOSAR系统。

LIN Slave 可以连接为完整的ECUs。但他们不被迫使用AUTOSAR SW架构。也许他们可以使用同样标准的AUTOSAR模块（比如EEPROM，DIO）。

3.1.5、TCP/IP

TCP/IP通信服务是一组用于车辆TCP/IP通信系统的模块。其主要任务是为Ethernet通信网络提供一套统一的接口，同时从应用程序中隐藏协议内容和消息属性。

TCP/IP通信服务具有下属属性：TCP/IP模块实现TCP/IP协议家族（TCP/UDP/IPv4/IPv6/ARP/ICMP/DHCP）主要协议，并通过以太网（Ethernet）提供动态的、基于Socket的通信；Socket适配器模块是TCP/IP模块中的唯一上层模块；

3.2、存储器服务

Memory Services由一个模块组成，即 NVRAM 管理器。它负责非易失性（non volatile）数据的管理（从不同的内存驱动读/写）。向应用程序提供非易失性数据。提供非易失性数据管理机制，如保存、加载、校验和保护验证、可靠存储等。

3.3、系统服务

System Services 包含一组模块，并且模块的函数可以被所有层的模块使用。例如实时操作系统（包括定时器服务）和错误管理器。
其中一些服务是：µC相关的（如操作系统：OS），并可能支持特殊µC功能（如加密服务管理：Crypto Service Manager），部分ECU硬件和应用程序相关（如ECU状态管理器：ECU State Manager）等。

这些服务为应用程序和基本软件（BSW）模块提供基本服务。

4、复杂驱动层

复杂驱动（CCD）层跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。

复杂驱动程序跟单片机和ECU硬件紧密相关。其上层程序接口是根据AUTOSAR指定并且实施的；其下层程序接口受标准接口程序的限制。

复杂驱动可以使用特定的中断或是复杂的微控制器外设（如PCP/TPU）来直接访问微控制器，从而实现对复杂传感器的评估和执行器的控制，比如喷油控制，电磁阀控制，增量位置检测等。