基于AUTOSAR标准的车辆电气系统CAN通信协议栈研究

，， ，

(中国北方车辆研究所，北京 100072)

基于AUTOSAR标准的车辆电气系统CAN通信协议栈研究

李艳明，倪永亮，李申，乔凤普

(中国北方车辆研究所，北京100072)

AUTOSAR是面向车辆电子电气领域的开放式软件体系架构标准;在充分学习研究AUTOSAR软件体系标准的基础上，开发了具有层次化、模块化、标准化接口的的CAN底层通信协议栈，并在飞思卡尔16位微控制器MC9S12XEP100的平台中进行了加载测试；测试证明该协议栈能够很好地实现CAN总线各层间的通信，能够满足车辆电子电气系统对总线通信方面的要求，具有较强的兼容性和移植性，可以显著地提高不同硬件平台间软件代码的移植速度，节省了软件开发时间，提升了软件代码的可靠性。

车辆开放系统架构； 软件构件； 协议栈； 协议数据单元；回调函数；传输层

0 引言

随着现代车辆电子技术的发展，信息化程度日益增高、电子控制单元不断增多、软件代码量急速上升；从而导致车辆电子控制系统的软件开发周期较长、产品的人力成本较高、软件可移植率较低等方面，因此车辆电子控制软件常规开发方法面临巨大挑战。为了解决这些突出问题，由世界上主要的车辆制造商及零部件供应商，于2003 年联合制定了车辆开放系统框架( automotive open system architecture，AUTOSAR)[1]，旨在提出一套针对车辆电子软件开发标准化、模块化、通用化的方案，从而达到提升软件研发速度，规范软件研发流程的目的。AUTOSAR的理念、方法论和软件架构已经被越来越多的OEM和供应商认可。目前，AUTOSAR组织成员即涵盖了奔驰、宝马、等著名的车辆生产厂商，也涵盖了Vector、Mentor、ETAS等著名的零部件制造商，我国上汽、一汽、北京经纬恒润公司等也加入了该组织。

在充分学习研究车辆AUTOSAR技术的基础上，将其CAN通信底层规范应用于车辆电子控制领域，旨在提升车辆电子控制软件的开发效率、统一车辆电子控制系统软件架构、夯实车辆电子控制系统软件可靠性。

1 AUTOSAR规范概述

AUTOSAR体系结构主要分为三层，如图1 所示。从上至下依次为应用层、RTE层、基础软件层(BSW)，其中基础软件层细分为服务层、ECU 抽象层、微控制器抽象层及一个特殊的复杂驱动层[2]。

图1 AUTOSAR通信协议栈架构

应用层由各应用软件构件SWC构成。各软件构件间的通信以及软件构件与底层硬件平台间的信息交互都是通过RTE上的标准接口来实现的。

RTE 层实质是一个虚拟功能总线(VFB)，主要为应用层提供通信服务[3]。RTE层主要实现了上层应用软件与下层基础软件之间的隔离，使软件工程师更加关注于上层应用软件的逻辑及算法，无须对底层硬件平台及基础软件进行过多的精力投入，从而大大提升了应用软件的开发速度及其逻辑可靠性。

基础软件层提供系统服务、硬件驱动及实时任务处理等功能，服务层与硬件平台之间加入ECU抽象层和微控制器抽象层。通过抽象设计屏蔽硬件功能的实现细节，并向操作系统和RTE层提供符合规范的标准接口[4]。其中服务层主要包括系统服务、存储服务及通信服务，主要提供操作系统管理、基于UDS(统一诊断服务)的诊断事件控制及管理、Flash存储管理以及通信协议的解析处理等；ECU抽象层主要实现对硬件平台除微控制器外的其它外设(如铁电)等的AUTOSAR抽象化，使之满足上层服务的要求；微控制器抽象层主要是将微控制器内部的资源(如ADC、SCI)等的接口驱动函数进行AUTOSAR标准化，以方便上层应用的调用；复杂驱动位于RTE 层与硬件平台之间，用于驱动对时序严格要求的复杂传感器和执行器(如电机的实时性驱动)。

本文主要针对CAN 通信模块的底层驱动CanDrive、接口层CanIf、传输层CanTp进行了研究与开发，并基于飞思卡尔微控制器MC9S12XEP100实现了基本通信功能。

2 CAN通信协议流程

CAN通信协议栈主要参考ISO-15765 诊断协议进行开发， ISO-15765传输层协议用于发送、接收数据报文并报告发送、接收的结果。ISO 15765协议适用于基于CAN通信网络的车辆诊断系统。如图2所示。

图2 ISO 15765体系结构图

由于CAN总线每帧报文最多只能包含8个字节，因此数据传输方式分为两种方式。对于数据长度小于或等于8个字节的情况，使用一帧CAN报文即可完成传输，该形式被称为单帧传输；对于数据长度大于8个字节的情况，需先将数据分段打包后通过发送多个CAN报文来实现，接收时再将这些CAN报文重新组合，该形式称为多帧传输。传输过程定义了单帧、首帧、连续帧和流控制帧4种基本类型[2]。其传输过程如图3所示。

图3 单帧、多帧传输过程

在多帧传输过程中，发送方和接收方要不断进行信息交换。发送方首先发送“第一帧”，告知接收方将要发送数据的总长度；接收方分配好资源，准备接收数据，然后以一帧“流控制帧”告知发送方一次可以发送的数据包数目和时间间隔；发送方接下来就根据接收方的接收能力将编好序号的数据包依次发送过去，这种传输机制称为流控制机制。图4描述了流控制机制的流程。接收方通过发送“流控制帧”可授权发送方继续发送/延迟发送剩余的连续帧，或在将要发送的数据长度超过自身接收缓存的时候取消目前的分段数据接收，流控制帧中标识接收方能力的两个参数包括。

1)块大小(BS)，即接收方允许发送方一次发送CAN报文的最大数量，然后需等待一个授权来继续发送剩余的CAN报文；

2)最短间隔时间(STmin)：发送方在发送两个连续帧之间等待的最短时间。

3 CAN通信模块设计

3.1 CAN驱动模块(CanDrv)

该模块主要实现CAN控制器的初始化、发送和接收以及提供CAN控制器的状态查询。

CAN驱动模块与其他模块接口交互如图4所示。

图4 CAN驱动模块软件接口关系图

该模块文件关系如图5所示。

图5 CAN模块文件关系图

其中Can.c主要包含CAN模块内部使用的全局数据类型和函数的定义；Can.h主要包含为其他模块所用到的常量，全局变量，数据类型定义和服务函数的外部声明；Can_Cfg.h主要包含在预编译阶段本模块可配置的常量和宏的定义；Can_PBcfg.c 主要包含可执行程序建立后的可配置参数定义；ComStack_Types.h主要包含CAN通信协议栈软件通用的数据类型定义的头文件；Std_Types.h主要包含标准类型定义的头文件；Platform_Types.h 主要包含平台类型定义头文件，包含与平台相关的类型和符号定义；Compiler.h 包含将与特定编译器相关的关键字进行抽象处理的宏定义。

该模块主要函数功能介绍如下。

1)Can_Init()：该函数用于初始化与整个CAN 控制器相关的设置及相关的标志位，并初始化所有的CAN controller。初始化后所有CAN controller由CAN_UNINT状态转换到了CAN_STOPPED状态，此时其还不能参与总线的通信，需要由应用程序单独将每个controller由CAN_STOPPED状态切换到CAN_STARTED状态。

2)Can_SetControllerMode()：该函数执行由软件触发的CAN controller状态转换。该函数会一直查询CAN的状态寄存器相关flag，直到该flag指示转换生效或超时，若转换生效，则通知上层转换成功完成。

3)Can_Write()：该函数主要用于将CAN缓冲区中的报文发送出去。

4)Can_MainFunction_Write()：当发送模式设置为轮询时，该函数用于执行对成功发送确认(TX Confirmation)的轮询及处理。

5)Can_MainFunction_Read()：当接收模式设置为轮询时，该函数用于执行对成功接收指示(RX indication)的轮询及处理。

6)Can_EnableControllerInterrupts()：该函数用于将指定CAN controller的中断恢复到禁止中断前的状态。

3.2 CAN 接口模块(CanIf)

CAN Interface模块位于最底层(CAN Driver)和上层通信服务层的中间，其充当CAN Driver和上层通信服务层的接口层，主要完成发送请求服务、发送确认服务，接收指示服务，CAN控制器模式控制服务，PDU的模式控制服务等。

CAN接口模块与其他模块接口交互如图6所示。

图6 CAN接口模块软件接口关系图

该模块文件关系如图7所示。

图7 Can Interface模块文件关系图

其中CanIf.c包含了Can Interface模块运行时所有的内核代码；CanIf.h是Can Interface模块的头文件，包含了对变量、函数以及类型的外部声明；CanIf_Type.h包含对某些通用的Can Interface类型的声明，CanIf.h需包含该头文件；CanIf_Cbk.h声明了所有在Can Interface模块中执行，但被Can Driver模块调用的回调函数；CanIf_Cfg.h及CanIf_Lcfg.c为该模块的配置文件，主要定义了预编译时间、连接时间的值。

该模块主要函数功能如下。

1)CanIf_Init()：该函数用于初始化CAN Interface模块中的全局变量和数据结构，包括标志位和缓存区等。

2)CanIf_SetControllerMode()：该函数用于改变Controller的模式。

3)CanIf_Transmit()：该函数用于发起对某CAN L-PDU的发送请求。当发送缓存被使能时，如果某个L-PDU在发送请求时被CanDrv拒绝了，CanIf会将其存储到CanIf transmit L-PDU buffer中，此时如果其相应的CanIfTxBuffer已经满了，则CanIf会用新的L-PDU覆盖旧的L-PDU。

4)CanIf_TxConfirmation()：该函数用于确认前一个被成功发送的CAN L-PDU。

5)CanIf_RxIndication()：该函数用于指示经过硬件滤波后成功接收到的某个L-PDU。

3.3 CAN 传输模块(CanTP)

传输模块主要实现通信双方之间的基于ISO 15765协议的CAN通信功能；收发单帧和多帧报文，对多帧报文进行解包和组包；控制数据流；检测报文收发过程中的各类错误，并向上层报告。

该模块文件关系如图8所示。

图8 CanTp模块文件关系图

其中CanTp.c包含CanTp模块内部使用的全局数据类型和函数的定义；CanTp.h包含被其他模块所用到的常量，全局变量，数据类型定义和服务函数的外部声明；CanTp_Cbk.h包含回调函数的外部声明；CanTp_Cfg.h：包含在预编译阶段本模块可配置的常量和可定制数据的定义；CanTp_PBcfg.c包含可执行程序建立后的可配置参数定义。

该模块主要函数功能如下：

1)CanTp_Init()：该函数初始化CanTp模块，包括内部变量初始化和CanTp状态初始化。

2)CanTp_MainFunction()：该函数是传输层模块的主任务处理函数，实现TP内部状态转换，执行定时发送连续帧(CF)，流控制帧(FC)，重发，超时处理等操作。该函数必须被固定周期调用，调用周期可配置。

3)CanTp_Transmit()：发送CAN N-SDU报文，发送单帧或多帧的第一帧。

4)CanTp_RxIndication()：处理接收到的CAN帧(SF，FF，CF，FC)，并调用用户提供的回调函数将数据拷贝到用户提供的缓存中。

5)CanTp_TxConfirmation()：在任意类型的CAN帧被执行发送后，执行该函数确认该帧发送成功。

4 CAN通信流程

4.1 CAN发送流程

首先上层诊断模块DCM向传输协议层发送传输请求并调用请求函数Can_Tp_TxMainFunction()，进而调用Can_TP_CanTransmit(CanTxPduId,pduInfoPtr)起动一次数据的传输;其中CanTxPduId是CAN数据包的PduID，pduInfoPtr是一个指向数据结构的指针，其定义如图10所示,该指针主要包含指向待发送数据的指针以及待发送数据的长度；该函数根据数据长度自动调用长帧传输或者短帧传输。

图9 CAN通信发送流程

图10 待发送数据结构体定义

再次，传输层将待发送数据传递至CANIF接口层，调用一个函数Can_If_Transmit()来发起CAN 发送。该函数在待发送序列CanIfTxPduConfig(CANIF_CFG_TOTAL_TXPDUID)中进行查询是否存在该发送任务,若存在该任务则直接调用底层Can_Write()函数进行发送，同时将待发送数据存放于临时缓冲区中，以防发送失败对数据进行重新发送，并且调用CanIf_TxConfirmation()向上层发送确认；若不存在则取消发送。

最后，CAN底层驱动层调用Can_Write()函数将数据填充到CAN硬件缓冲区中，并触发硬件起动一次CANBuffer的发送[3]。

4.2 CAN接收流程

接收过程如图11所示，当物理总线上有接收数据时，当程序配置为接收中断方式时，将触发CAN_PH0_Rx_ISR()来接收数据；当程序配置为查询接收时，将触发CAN_MainFunction_Read()来接收数据。

图11 CANIF接口层数据结构定义

再次，通过调用CAN_Controller_Rx_handler()函数将数据存入对应的存储区中；若接收成功则调用接收指示函数CanIf_RxIndication()通知接口层成功接收一帧数据，并进行接收确认。

其次，接口层主要调用CanIfRxPduConfig(CANIF_CFG_TOTAL_RXPDUID)函数对收到的数据进行识别与过滤，主要包括接收PduID、CAN总线ID、CANID类型、CAN数据长度、CAN接收缓冲区、CAN接收应用服务程序等，其示例如图12所示。

图12 CAN通信接收流程

最后接口层调用接收确认函数CanTp_RxIndication()通知传输层接收到新的数据,传输层开辟相应的数据存储空间将接收到的数据放置于缓冲区中，并通知上层函数接收到新数据[4]。

5 通信协议栈测试与分析

基于MC9S12XEP100的硬件平台，配合Vector公司的CANoe进行通信协议栈的测试。将上位机CANoe定义为数据接收端，物理寻址ID设定为0x777，功能寻址ID设定为0x7DF；下位机MC9S12XEP100的硬件平台定义为数据发送端，ID 设定为0x77F。

首先上位机发送了10单帧服务请求(02 10 03 00 00 00 00 00)，10服务用于使能不同的诊断会话。诊断会话包括默认会话模式、编程模式和扩展模式，不同的诊断会话具有不同的功能，且定时参数和安全访问级别也不一样。此10服务用于进入扩展模式，在扩展模式下，所有的诊断服务均可以使用。下位机接收后返回一个首帧肯定响应(06 50 03)，证明下位机已经进入扩展模式，已经做好准备接收命令。

其次上位机发送了27单帧服务请求(02 27 01 00 00 00 00 00)。27服务用于安全访问，主要获取下位机的安全种子，经过安全算法计算后返回给下位机安全密钥，经下位机验证正确后方可实现对下位机的解锁；下位机接收后返回一个首帧肯定响应(06 67 01 0C 0C 0C 0C 55)，下位机返回的种子为67 01 0C 0C 0C 0C；上位机经过运算下发安全密钥(06 27 02 00 00 00 01 00)，安全密钥为27 02 00 00 00 01；下位机经过核对返回安全密钥肯定响应(02 67 02 55 55 55 55 55)，证明下位机已经完全解锁，做好准备接收服务请求。

最后，上位机发送了22服务请求数据传输(03 22 F1 90 00 00 00 00)。22服务是依据数据标识符ID来读取对应的数据记录，该数据ID为F1 90；下位机接收后返回一个首帧肯定响应(10 14 62 F1 90 00 00 00 00)，定义传输数据长度为20个字节，并且已经发送前6个字节；上位机依据接收的数据长度发送流控制帧(30 00 02 00 00 00 00 00)，定义下位机传送2个连续帧；下位机开始进行数据传输直到两个连续帧传送完毕。

实验结果表明该CAN总线传输通信协议栈符合ISO15765传输规范，传输时序符合最大时延要求；在时延要求范围内能够可靠稳定地实现CAN总线通信，CAN通信各层均能够正常运行，能够很好地将AUTOSAR通信服务加载于16位微控制器平台中。

6 总结

本文基于目前流行的车辆软件开放架构标准AUTOSAR，设计了车辆电子控制系统基于硬件平台飞思卡尔微控制器MC9S12XEP100的CAN底层通信协议栈。经过测试，该协议栈可以成功高效地完成CAN总线通信，提升了软件的可读性及可移植性，提升了在不同硬件平台下应用软件的移植速度，缩短了开发周期，对车辆电子平台化发展具有重要的意义。

[1] AUTOSAR. layered software architecture[Z].2013.

[2] 冯 川,胡 杰,颜伏伍,等.符合AUTOSAR标准的CAN底层通信研究[J].武汉理工大学学报(信息与管理工程版),2013,35(6):842-845,855.

[3] 宋 波，王安军，王正树.符合AUTOSAR规范的MCU驱动设计与实现[J].研究与开发，2011，：56-60.

[4] 王安军,蒋建春,陈培然.符合AUTOSAR规范的底层驱动软件开发.计算机工程[J]，2011，37(9)：62-64.

ResearchonCANCommunicationProtocolStackofVehicleE/ESystemBasedonAUTOSARCriterion

Li Yanming, Ni Yongliang, Li Shen, Qiao Fengpu

(China North Vehicle Research Institute，Beijing 100072,China)

AUTOSAR is a open software architecture standard in automotive E/E system. On the basis of full study and research of AUTOSAR structure，the CAN Communication Protocol Stack was developed with hierarchy and standardization，also loaded and tested on the micro controller of MC9S12XEP100.The results prove that the Protocol Stack can greatly realize communication between different layers of CAN，which can meet the requirements of Vehicle bus communication；it is also capable of compatibility and transportation，which can observably increase the code transporting speed between different hardware platforms, decrease the software developing time and also increase the code reliability.

AUTomotive open system ARchitecture(AUTOSAR)；SWC；communication protocol stack；PDU；callback function; transportation layer

2017-09-05；

2017-09-27。

李艳明(1981-)，男，副研究员，硕士，主要从事车辆机电综合管理技术方向的研究。

1671-4598(2017)11-0239-05

10.16526/j.cnki.11-4762/tp.2017.11.061

TP3

A