基于 AUTOSAR 的自动驾驶软件架构

1 AUTOSAR架构软件结构简介

近年随着汽车电子化、智能化发展，汽车CAN总线上搭载的ECU日益增多。各汽车制造商车型因策略不同ECU数目略有不同，但据统计平均一台车约为25个模块，某些高端车型则高达百余个。同时娱乐信息系统作为"人类第三屏"，交互体验正不断扩展，加上车联网程度的逐步加深，整车系统的通信数据量正在以量级增长。

汽车电子领域迫切需要有一种全新的整车软件设计标准来应对愈加复杂的电子设计。为此，在2003年欧洲宝马为首几家OEM巨头与一些Tier1成立AUTOSAR联盟，致力于为汽车工业开发一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，也就是常听到的AUTOSAR（AUTomotive Open System ARchitecture）。整车软件系统可通过AUTOSAR架构对车载网络、系统内存及总线的诊断功能进行深度管理，它的出现有利于整车电子系统软件的更新与交换，并改善了系统的可靠性和稳定性。

AUTOSAR是全球性的汽车开放式系统架构，其在汽车制造及其供应商行业，甚至电子、半导体和软件行业有广泛的应用。

AUTOSAR 就是AUTomotive Open System ARchitecture的简称，中文翻译就是汽车开放系统架构

简言之，将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。如此之后，用户只需要专心负责应用层功能开发即可，底层都交给AutoSAR工程师就行了。用户只需要开发操作系统上层的软件应用即可（类似于基于安卓开发App）

AUTOSAR是一家致力于制定汽车电子软件标准的联盟，目前有100多个会员。各会员依据其对AUTOSAR的贡献及责任分为三个等级，Core Partners（核心合作伙伴）、Premium Partners（高级合作伙伴）、Associate Partners（发展合作伙伴）。9家核心公司主要负责AUTOSAR开发模式的筹划、管理和调控，也是AUTOSAR协议的发起人。高级合作伙伴和发展合作伙伴在核心会员成立的项目领导组的协调和监督下开展工作。值得一提的是，目前国内主机厂只有三家支持AUTOSAR协议，上汽、吉利和一汽。

在这里插入图片描述](https://img-blog.csdnimg.cn/a33df3df99b44e0196274fcca2707b25.png)

目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品，提供需求管理，系统描述，软件构件算法模型验证，软件构建算法建模，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，帮助OEM实现无缝的系统软件架构开发流程。

1.1 使用AutoSAR前的状态

1、原始状态

也就是大家经常使用的敲代码法，目前也有一部分简单的ECU（汽车电子单元，简单的说就是汽车上的某个控制器，比如锂电池管理单元BMS、电机控制单元MCU都可以叫做ECU）在使用这种方式开发，缺点比较明显，主要就是软硬件耦合严重导致的，可以归结为以下：

1. 开发效率低下

2. 开发周期长

3. 代码合作开发难、维护难

4. 可重用性差（例如更换硬件平台后，代码几乎是需要重新开写的）

5. 随着代码量的增加，代码质量也随之下降

2、进阶状态

在代码法的基础上，通过有经验的架构师做出一套优化架构，并且结合一些操作系统（OS）对代码进行封装，这样一来便可以大大降低代码法的很多弊端，一名好的架构师设计出来的架构往往可以起到几倍到十几倍的效率增幅，不过缺点仍然有：

1. 对于不同的客户，由于各家客户需求不同，重用性依然不好

2. 软件耦合也会存在，同时该方法的优劣和架构师的能力直接挂钩

如下图是在AuotSAR以前常用的OSEK架构，对比后面图片的AutoSAR架构，可以看出OSEK的耦合还是挺严重的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iYnWXr5d-1685684019202)(RackMultipart20230602-1-cn0cnq_html_2891918bfeb445aa.png)]

1、AUTOSAR的分层设计AUTOSAR计划目标主要有三个：

建立独立于硬件的分层软件架构

为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同汽车平台复用。

AUTOSAR整体框架为分层式设计，以中间件RTE(Runtime Environment)为界，隔离上层的应用层（Application Layer）与下层的基础软件（Basic Software）

2、软件组件SWC VFB与RTE应用层中的功能由各软件组件（SWC）实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线VFB（Virtual Functional Bus），它是对AUTOSAR所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至ECU内部或者是与其他ECU之间的数据传输。

因此软件组件只需向VFB发送输出信号，VFB将信息传输给目标组建的输入端口，这样的方式使得在硬件定义之前，即可完成功能软件的验证，而不需要依赖于传统的硬件系统。中间件RTE与面向对象OO（object oriented）的编程思想非常接近，所有ECU所对应的RTE都是特定的，它负责着软件构件间以及软件构件与基础软件之间的通信。对于软件构件来说，基础软件不能够直接访问，必须通过RTE进入。因而RTE也被理解成是VFB的接口实现。而构件之间及构件与基础软件的通信关系如图所示：值得注意的是，AUTOSAR软件构件无法直接访问基础软件中的操作系统OS，因而在应用程序中就不存在「task」的概念，且不能动态创建线程，因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。每个软件构件也许会有一个或者多个运行实体，但是一个运行实体只对应一个入口。

3、基础软件层 BSW基础软件则被抽象为四层：

服务层（Services Layer）

ECU抽象层（ECU Abstraction Layer）

微控制器抽象层（Microcontroller Abstraction Layer）

复杂驱动（Complex Device Drivers）

服务层包含RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务；

ECU抽象层中封装了微控制器层及外围设备的驱动，并对微控制器内外设的访问进行了统一，实现了软件应用层与硬件系统的分离；

微控制器抽象层位于基础软件的最底层，包含了访问微控制器的驱动（如I/O驱动、ADC驱动等），做到了上层软件与微控制器的分离，以便应用的后续的移植复用； 复杂驱动由于其严格的时序为应用层通过RTE访问硬件提供支持。

1.2 使用AutoSAR后的状态

1、软硬件隔离

大家经常能看到的下图能很形象的说明这一点，隔离后的好处就是不管你用NXP的还是英飞凌的亦或者是TI的；不管你的硬件是怎么设计的，我们都不用修改我们的代码，只需要配置一下AutoSAR，告诉它我换硬件了，然后AutoSAR帮你匹配硬件。

AUTOSAR软件架构的提出与推广将有效缩短OEM研发与测试新架构车型的时间，未来也将会有越来越多的企业与供应商加入到AUTOSAR无缝解决方案的制定中，一定程度上将提高不同车型平台的软件复用性，从而整体市场的研发成本与开发周期。

AUTOSAR致力于标准化嵌入式软件架构，为创新的电子系统改进性能、安全、环境友好等奠定基础。软硬件之间彼此独立，各个层级之间的开发从此解耦，节省了开发成本和开发时间。对于OEM和供应商而言，彼此的软件复用性都大幅提升，提高了开发效率和开发质量。

图很清晰体现了AUTOSAR对嵌入式软件开发带来的翻天覆地的变化。在此之前，while(1)中各种中断、定时器等，用一句话概括就是你中有我，我中有你。但是AUTOSAR的概念是把一切能剥离的模块全部剥离开，这样对各个模块的维护更加方便。

2 AUTOSAR 软件架构

首先我们来看一张整体的架构图，以后我们会在这张图上细分和深入，添加细节来补充完整。首先就能看出AutoSAR主要分为3个层级：应用层（Application Software Layer），运行时环境（Runtime Environment，RTE），基础软件层（Basic Software Layer，BSW），微控制器（Microcontroller）。应用软件层主要就是用来存放我们自己的代码的地方

实时运行环境是提供应用层所需的资源，同时将应用层和底层隔离

基础软件层是将硬件做封装，一直封装到一个标准的操作系统的状态，以便上层可以标准化调用系统服务

每层之间为保持独立性，每一层只能调用下一层的接口，并为其上一层提供接口。

上图中应用层和BSW层都比其他层大一些，这是因为它们两还可以再做细分，接下来我们看下面这张图，我们将应用层和基础软件层做了细分，

就这几层现在做分别的讨论：

2.1应用层（Application）

应用层包含若干软件组件（Software Component，SWC），SWC封装了需要实现的具体功能，独立于微控制器的类型，与底层硬件的独立性是通过虚拟功能总线（VFB）来实现。而VFB则提供了一种通信机制，具体由RTE和BSW来实现。

• SWC由端口（Port）和运行实体（Runnable Entity，RE）组成。
• 端口（Port）是SWC之间进行通信的接口，通信内容包含数据元素（Data Element，DE）和操作（Operation，OP）。
• 两种常用端口：发送-接收端口（Sender-Receiver Interface，S/R）和客户端-服务器端口（Client-Server，C/S）。
• S/R用于数据传递，发送方将数据元素（Data Element，DE）发送给一个或者几个接收方。C/S用于操作（Operation，OP），即函数调用，服务器提供函数，而客户端用来调用函数，一个函数可以被多个客户端调用，但是一个客户端不能调用多个函数。
• 运行实体（Runnable Entity，RE）是一段可执行代码，封装了具体算法。

2.2运行时环境（RTE）

RTE是AUTOSAR中虚拟总线功能（VFB）接口的实现。

2.3基础软件层（BSW）

基础软件层又分为4个小层，分别是：服务层（Services Layer），ECU抽象层（ECU Abstraction Layer），微控制器抽象层（Microcontroller Abstraction Layer），复杂驱动（Complex Drivers）。

基础软件层又分为4大部分：

1. 硬件抽象层（MCAL）：借助STM32库的概念，硬件抽象层又叫MCAL，就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库Api。就是说这套Api是不同厂商都支持的，但是底层怎么实现，就是芯片厂商的事了。同时也有软件工具EB，可以通过界面配置

MCAL功能

2. ECU抽象层：如果说MCAL只封装了芯片，那么ECU抽象层就是将硬件上所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC275，还有采样电路，电源电路，CAN电路等等。而MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。所以不管硬件是如何实现的，这里封装后，也形成了统一的Api

3. 服务层：这里有是更加高级的一层了，服务层里是包含操作系统（OS）的。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。

4. 复杂驱动：又叫做CDD，主要工作是将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能。（简单说就是其他的概念）

2.4服务层（Services Layer）

在BSW层最上层，提供以下服务：

（1）操作系统（OS）

（2）车辆网络通信和管理服务

（3）内存管理（NVRAM管理）

（4）诊断服务（包括UDS通信，错误存储器和故障处理）

（5）ECU状态管理，模式管理

（6）逻辑和程序流监控（Wdg管理）

复杂驱动（Complex Drivers）

目的:提供复杂传感器和执行器的驱动

功能:重要的应用模块可以直接访问硬件资源，例如: 喷油量控制, 胎压监测提供集成特殊功能的可能性，例如设备的驱动，这些驱动有以下特点：

（1）在AUTOSAR中没有明确规定

（2）对时序要求比较高

（3）用于移植目的ECU抽象层（ECU Abstraction Layer）提供访问外围设备的API，使更上层的软件独立于ECU硬件。

2.5微控制器抽象层（Microcontroller Abstraction Layer）

包含可以直接访问微控制器和外围设备的底层驱动。

假设右门状态有变化，传感器会感知该变化，将检测到的电流信号通过ECU转换成电压信号，之后电压信号被微控制器外围设备感知，至此硬件传递完毕。反应在各硬件上的软件状态如4-6步描述，处在应用层的门控制模块会通过Rte-Read_DoorRight_IsOpen()、Rte_Read_Door_state()两个函数从RTE下层的BSW 读取数据，ECU抽象层通过ADC-get()从更底层读取数据。 其实AUTOSAR就是把一些基础软件封装成包，使得用户只需要关注上层应用层的开发，从而提高效率。

3 AUOTOSAR辅助驾驶系统软件平台开发

3.1 辅助驾驶系统软件分层设计

辅助驾驶功能越来越复杂，系统集成难度大，需要一个可靠的平台去支持它的开发、集成及测试。围绕AUOTOSAR软件架构展开，按照计算中心化集中化的域控制器架构，增加平台化中间件软件，实现软硬分离，目的是增加应用层软件的重用率，避免多次开发。

上图为域控制器软件架构分层图，从下至上共分为5层，硬件层为自主研发的辅助驾驶系统域控制器，主要计算单元为MCU（TC277）和SoC（TDA2Px）；驱动层是实现不同硬件接口统一化的特殊层，包括CAN、以太网、Camra等驱动；OS层是系统层，MCU上运行的是AUTOSAR的OS，基于OSEK内核进行扩展，SoC上可以根据实际情况选择合适的系统，使用的是Linux，也可使用Hypervisor技术运行多个系统；系统层之上是软件中间件，软件中间件的目的是实现软件的复用和软硬分离；APP层是实现自动驾驶功能的软件，这些软件是可重用的软件，可以根据需求在应用了此软件中间件的平台上进行适配。

3.2基于AUTOSAR的智能网联汽车跨平台软件体系结构

3.2.1 跨平台技术研究

智能网联汽车的快速发展导致了汽车的电子电气架构越来越复杂，使得软件成本也急剧增加，传统的基于分离式的电子电气架构以及各厂商独立开发的方式已经显现出系统架构不统一、代码的跨平台运行能力较差和软件耦合比较严重等问题，不适用于现在的智能网联汽车。因此跨平台技术是解决上述问题的有效方案之一。

跨平台技术是软件开发领域的一个重要概念，一个平台下开发出的应用程序在其他平台上也可以实现同样的功能，该技术向下屏蔽底层环境的差异性，向上可以帮助软件开发者更高效地去开发跨平台应用程序。

在跨平台技术之前的软件开发是针对不同的硬件和操作系统平台单独开发的。不同平台的软件对平台的依赖性很大，实现跨平台的应用程序非常困难。要实现不同平台的相同功能，基本上需要从头开发，这需要大量的人力和物力。而跨平台技术的出现很好地解决了上述问题。跨平台技术主要有操作系统抽象层，虚拟机技术，嵌入式图形中间件，跨平台库等技术

3.2.2 基于 AUTOSAR 的跨平台软件架构

本课题的跨平台软件是为辅助驾驶功能开发提供安全、高效、易扩展、易集成测试的平台软件，旨在为辅助驾驶操作系统提供统一的应用程序接口，满足多运算平台（x86、ARM、MCU）兼容和多软件系统（Linux、Windows、ROTS）兼容的要求，

因此跨平台软件应满足以下条件：

（1）可以实现辅助驾驶应用软件跨平台的应用需求；

（2）基于此平台可以开发并验证跨平台的应用程序；

（3）开发出的跨平台应用程序可以方便且高效的移植到不同的系统平台上；

（4）运行服务可扩展，插件功能可扩展。

根据以上需求，按照如下思想来设计软件平台：

（1）按照AUTOSAR分层架构的思想设计跨平台的平台软件，采用分层的架构思想可以更好地实现软硬分离，增加应用软件的重用率。

（2）按照AUTOSAR模块化的思想设计接口及系统库，模块化技术的应用使得平台软件可以更方便地兼容其他功能模块和操作系统。如图所示为自适应AUTOSAR的模块图，自适应AUTOSAR作为中间件软件实现软硬分离的关键技术，共分为基础和服务两个大模块。

参考AUTOSAR软件架构规范设计开发的辅助驾驶系统平台软件，平台软件可以在多运算平台（x86、ARM、MCU）和多软件系统（Linux、Windows、ROTS）上进行适配。软件包括调度模块，执行管理模块，异常诊断与恢复模块，进程间通信模块，数据管理模块等。为平台软件的层次结构图，在不同平台下有对应的平台库，是实现跨平台服务的基础。

辅助驾驶系统域控制器作为辅助驾驶系统的核心计算单元，其与外界的数据交互十分重要，域控制器的通信模块是实现辅助驾驶功能的桥梁。辅助驾驶功能的复杂使得车辆上需要交互的数据大大增加，传统的车载 架构CAN总线受信息传输带宽的限制已无法满足需求，按照新一代的电子电气架构，在车载网络中加入以太网来提高传输带宽。本节按照AUTOSAR规范对域控制器的通信软件进行研究，如图3-6所示为AUTOSAR通信协议栈结构。通信协议栈位于微控制器抽象层（MCAL）与运行环境RTE之间，可以实现了不同速率或类型总线之间数据的交互。

4 AUTOSAR COM模块详细说明

本节列出了 AUTOSAR COM 模块所有功能模块。有关 AUTOSAR COM 模块在通信堆栈中的放置，请参阅下图。

COM** 模块**AUTOSAR COM是位于RTE和PduR之间的服务层模块，主要用于与RTE之间的信号交互，对信号进行打包和解包。另外在该模块中还可以配置IPDU的通信周期、通信周期偏移量、IPDU Group等。

PduR** 模块**PduR的作用是为通信协议栈中的不同总线的IPDU提供路由路径。例如它将接收的IPDU路由至COM、Dcm等模块，或者将COM模块需要发送的IPDU路由至CanIf模块，最后传送至芯片的CAN Driver，将信号发送至总线。

CanTp** 模块**Tp表示传输协议。该模块是特定于总线，其配置取决于基础总线协议，可以是CAN、LIN、CANFD等总线。该模块主要用于长报文的分段发送，以及对分段报文进行重组。

Bus SM 模块 总线状态管理模块负责相应总线状态机的管理和总线故障的处理。它可以基于CAN总线的CanSM，或者是基于LIN总线的LinSM等。

Bus Trcv Driver** 模块**它是ECU抽象层的一部分。它可以是用于CAN收发器的CanTrcv，用于以太网收发器的EthTrcv，用于Flexray收发器的FrTrcv等。此模块用于对收发器进行初始化配置，它提供独立于控制器硬件的用于启动传输的服务和用于通知接收事件的回调函数。

Bus Driver 该模块是AUTOSAR MCAL层的一部分（例如：CanDrv，LinDrv，FrDrv），它实际上与ECU的底层硬件进行交互，并为其上层提供独立于硬件的接口。此模块取决于硬件，并且驱动程序代码可能会根据基础硬件而有所不同。BusIf是唯一可以访问此总线驱动程序的模块。

4.1多核微控制器的分层软件架构

随着汽车领域对计算资源的需求越来越高，OEM和Tier 1正在逐步引入多核 ECU 在其电子架构中的使用。此外，这些多核 ECU为新功能的引入提供了基础， 例如功能安全要求的实施。

AUTOSAR 4.0 版引入了对多核嵌入式 RTOS 的支持。AUTOSAR 4.0 规范中引入了多核启动/关闭、核间通信 (IOC) 等新概念，以扩展单核操作系统规范。

改进后的 Autosar 架构如下所示：

在软件开发符合 AUTOSAR 的每个阶段，都涉及各种工具，以确保生成的界面符合标准。下面的流程图表示了一个简短的 Autosar 开发流程。尽管此图并未涵盖适用于所有软件模块的开发流程。

4.2 ECU 设计和配置方法

AUTOSAR 为系统开发步骤提供了一种通用的技术方法。该图显示了使用 AUTOSAR 技术构建 ECU 的设计步骤概览。这意味着必须为系统中的每个 ECU 执行这些步骤。

需要注意的是，AUTOSAR 没有规定执行开发活动的精确顺序。Autosar 既不讲述流程，也不讲述商业模式和"角色"和"责任"。

下图是通常遵循的工作流程的示例。下图分别描述了 BSW 和应用软件的开发流程。

此阶段的主要活动是从系统配置描述中提取特定于 ECU 的信息、ECU 配置以及可执行 ECU 软件的生成。以下部分将更详细地描述这些活动。

4.3提取特定于 ECU 的信息

AUTOSAR ECU Configuration Extractor工具（例如 System Desk，Da-Vinci）从特定 ECU 所需的系统配置描述中提取信息。这是映射到此特定 ECU 的系统配置描述的所有元素的一对一副本。输出是系统配置的 ECU 摘录。网络数据库（例如 CAN.dbc）文件是生成 ECU 提取物 (.arxml) 的输入。

4.4配置（BSW）ECU

ECU 配置主要处理RTE 和基础软件模块的配置。该配置基于系统配置的 ECU 摘录中可用的参数。可用 SWC 实现和 BSW 模块描述的集合。BSW 还包含供应商特定的 ECU 配置。这是必要的，因为输出 ECU 配置描述具有灵活的结构，在 ECU 提取时不定义固定数量的配置参数。

必须在 BSW 配置期间定义通信模块、MCAL、操作系统或 AUTOSAR 服务。

4.5软件组件实现

SWC 的初始工作从提供软件组件描述 [SWCTempl] 的必要部分开始。即组件内部行为描述作为软件组件相关模板的一部分。内部行为描述了组件的调度相关方面，即可运行实体及其响应的事件。此外，行为指定组件（或更准确地说是哪个可运行组件）如何响应接收到的数据元素等事件。但是，它没有描述组件的详细功能行为。

5基于AutoSAR架构的CAN通讯简介

5.1基于AutoSAR CAN通讯过程简介

随着汽车电子化与自动驾驶的发展，AutoSAR汽车开放式系统架构得到越来越多的重视与应用。如下图所示为常见AutoSAR基础框架，其中红框部分为与通讯相关的部分，包括LIN、CAN、Eth等。

CAN总线通讯取消地址编码的方式，采用消息编码的方式，总线上各个节点都能收到总线发出的消息。各个节点根据ID判断是否为自身所需要的消息进行接收。总线到应用层之间的消息传递以及数据转换过程如下：

总线上只能传递高低电平的物理信号，CAN收发器（软件上包含CAN Driver，CAN transceiver，Driver for CAN ASIC）将总线传递过来的差分电平转换为逻辑电平（TTL电平）（发送时相反）生成二进制码流；CAN收发器将二进制码流发送给CAN控制器（软件上包含CAN Interface）。（数据链路层）

CAN控制器将在二进制码流的基础上生成CAN帧（CAN帧最大传输数据为8byte，此处不详细介绍CAN帧结构以及种类），同时进行位填充、添加CRC校验、应答检查等操作（发送时类似）。（网络层）

通讯服务在收到下层传递过来的CAN帧消息之后进行解析提取、处理CAN帧中包含的信号，通过路由转发给需要的模块。（交互层）

5.2 PDU简介

在介绍完基本数据流向之后，介绍一个重要概念：PDU。PDU是AutoSAR通讯过程中一个重要的概念，全称：协议数据单元（protocol data unit），是数据传输的基本单位。在不同的架构层有不同的PDU分为以下几种：

• PDU（交互层）
• N-PDU（网络层）
• L-PDU（数据链路层）

PDU包含PCI和SDU两部分，PCI包含源地址和目标地址信息，SDU是数据信息。如下图2所示为PDU基本组成。

5.3基于AutoSAR CAN通讯数据流

接下来结合具体AutoSAR模块进行详细数据流介绍。如图所示为通讯数据流，其中红色方框中为CAN通讯数据流；图4为不同的架构层对应的协议数据单元以及对应的AutoSAR模块及对应的CAN帧。

CAN通讯数据流如下：

1. 在CAN Driver收取Bus上传来的信号电平之后生成L-PDU，L-PDU传输至CANIf；
2. CANIf生成CAN帧，生成N-PDU。此时CANIf判断CAN帧的传输方式（单针传输/连续帧传输）。当为单帧传输时，N-PDU 传输SF（single frame），如下图5所示：

当无法利用单帧传输时，需要多帧传输。在多帧传送方式中，网络层根据需要，将数据进行拆分成一个首帧（FF：First Frame）和多个连续帧（CF：Consecutive Frame）。首帧包含了分段数据的总长度信息以及一些数据帧；每个连续帧的第一个字节都包含拆分的顺序编号，后面的七个字节用于存放数据。接收端在接收到连续帧后根据接收数据帧的编号重组服务数据。如下图所示：流控制帧（FC：Flow Control）向发送端传递接收端的接收及响应能力，即最多能够接收多少连续帧以及响应时间STmin等。

3、N-PDU传输到CAN TP经过如上图过程，生成由单帧或组合帧组成的I-PDU。

4、I-PDU进入PDUR进行分配，根据地址信息（PCI）将进入COM模块的I-PDU传入COM。（PDUR：给PUD提供路由功能，通过地址信息分配到不同的目标地）

5、COM对I-PDU的数据信息SDU进行解析，生成signals，signals通过RTE传输给应用层。

CAN消息发送过程与接收过程相反。

以上就是基于AutoSAR架构的CAN通讯简介，相关的诊断刷新功能也是在通讯功能的基础上进行扩展的。

6参考资料

《 AUTOSAR_TechnicalOverview.pdf》

《 AUTOSAR_LayeredSoftwareArchitecture.pdf》

《 AUTOSAR_SWS_VFB.pdf》

《 AUTOSAR_SWS_RTE.pdf》

《 AUTOSAR_SoftwareComponentTemplate.pdf》

《 ECU软件的AUTOSAR分层架构 》浙江大学ESE中心