基于AUTOSAR架构的汽车诊断通信协议栈的开发

乔美昀 韦天文

【摘 要】在研究了AUTOSAR标准的设计思想和诊断通信OSI模型后，开发了基于AUTOSAR架构的汽车诊断通信协议栈。整个协议栈的开发采用由下往上的分层模块化结构，以实现具体的数据传输、通信模式控制、时间管理和诊断服务处理功能为核心，这种开发方式具有开发周期短、软件复用度高、可移植性好的优点。借助自主搭建的故障诊断测试平台对协议栈进行测试，通过ECU刷新的例子，分析了总线上的刷新报文及通信机制，结果表明协议栈可以进行诊断通信并且通信过程符合诊断协议。

【关键词】AUTOSAR；诊断通信协议栈；模块化；诊断协议

【中图分类号】U472.9 【文献标识码】A 【文章编号】1674-0688（2018）07-0036-05

0 引言

随着现代汽车上集成的ECU越来越多，整车网络越来越复杂。诊断通信作为车载网络中的一个重要功能，开发周期和难度也不断增加。为了提高软件的复用率和可移植性，缩短开发周期，全球汽车制造商、零部件供應商、半导体供应商及工具供应商共同制定了AUTOSAR标准。AUTOSAR标准的核心是剥离ECU软件开发对硬件的依赖，为此它将软件分为应用层软件组件（SW Component）、基础软件包（Basic Software）和运行时环境（RTE），AUTOSAR标准如图1所示。

本文在深入研究AUTOSAR标准的设计思想和软件体系后，参照AUTOSAR标准推荐的诊断通信架构，开发了一个基于CAN总线的、具有通用性和可移植性的诊断通信协议栈。

1 诊断通信协议栈总体架构

1.1 诊断通信协议中的OSI模型

为了实现网络通信系统开发的标准化，国际标准组织（ISO）制定了OSI模型。这个模型把网络通信分为7个工作层，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。ISO在后来制定的诊断通信协议中，如ISO15765、ISO14229、ISO15031，也按照OSI模型对诊断通信进行了分层，并用具体的诊断通信协议对每层做了详细的规定。随着诊断通信协议的不断完善，已经形成一套完整的诊断通信架构（见表1）。根据应用范围的不同，诊断通信分为2种：一种是与排放无关的诊断，叫增强型诊断，即UDS诊断；一种是与排放相关的诊断，叫OBD诊断。

传统的诊断通信协议栈的开发，基本都是按照诊断协议中OSI模型来建立整体架构的。但诊断通信的OSI模型并没有在具体功能的开发上提供参考，这就导致不同的汽车制造商按照各自的软件开发标准开发出各自专用的诊断通信软件，其中有的诊断通信软件在诊断应用层直接操作硬件，这些都造成汽车诊断通信软件缺乏通用性和可移植性。

1.2 AUTOSAR标准的诊断通信协议栈架构

AUTOSAR标准基于传统的OSI模型，为诊断通信软件的开发提供了一套完整的解决方案。

协议栈的硬件平台根据选用的芯片、连接的方式及具体的布局而异，但根本原理都是一致的，CAN控制器是硬件的核心，通过不同的CAN收发器接到不同的CAN总线上。

基础软件的微控制器抽象层主要解决硬件的底层驱动问题，对应在诊断通信协议栈中是CAN驱动层。当将诊断通信协议栈移植到其他硬件平台上，只需对CAN驱动做相应的更改，上层软件则可以完全复用。

ECU抽象层，也叫硬件抽象层，主要解决上层软件和硬件驱动之间的接口问题，对应在诊断通信协议栈中是CAN接口层。CAN接口层抽象了CAN控制器的位置和ECU的硬件布局，提供了一种平等访问总线通道的机制而无需考虑这些控制器的物理位置。

服务层用于给应用程序提供可用的服务，在诊断通信协议栈里通过3个层次实现：CAN传输层、Pdu路由层和DCM层。CAN传输层主要解决多帧传输的问题，完成数据的打包和重组。Pdu路由层是考虑到车载网络中有多种通信方式共存，实现不同通信数据的中转，可以对上层屏蔽通信方式的细节。DCM是服务层，也是整个诊断通信协议栈的核心。DCM处理诊断仪发送来的服务请求消息，然后执行相应的操作，最后返回响应消息给诊断仪，整个过程涉及诊断会话的管理、诊断服务的调度及诊断服务的执行。

2 诊断通信协议栈的开发

本文采用freescale高性能芯片MC9S12XEQ512的开发板作为诊断通信协议栈开发和测试的硬件平台，该芯片内部集成5个支持CAN 2.0B标准的CAN控制器，与之配套的CAN收发器采用82C250芯片。

本文开发的诊断通信协议栈，选择实现UDS诊断服务，OBD服务会在以后进行扩展。整个协议栈的开发采用由下往上的方式，DCM以下的模块作为基本CAN通信软件一起开发，DCM作为诊断应用层单独开发。首先制定代码文件结构，然后分别进行基本CAN通信软件的数据传输、通信模式控制和时间管理功能的开发，最后进行DCM层诊断服务处理功能的开发。

2.1 诊断通信协议栈的文件结构

AUTOSAR的模块化思想很大程度上体现在代码文件结构的规范上。在AUTOSAR标准里，诊断通信是作为一个完整的汽车电控系统的子系统进行开发的。诊断通信协议栈中的子模块不仅会调用各自的头文件，也会调用ECU级别的头文件，所以在保证代码的系统性的同时，也导致代码结构较为庞大复杂。本文旨在单独实现诊断通信的功能，因此对代码结构做了一定的简化，整个诊断通信协议栈的代码文件结构如图2所示。

其中，Can_GeneralTypes.h定义了通用CAN协议栈底层模块的数据类型。ComStack_Types.h定义了与在线通信模块Com相关的数据类型，主要是数据协议单元。Std_Types.h定义了Autosar标准专有的数据类型，如版本信息和一些状态模式的宏定义。每个子模块都有若干c文件，主要定义仅限于本模块使用的数据类型、常量和函数。每个用子模块名称命名的头文件xxx.h定义本模块中被外部引用的数据类型、变量和服务。xxx_Cfg.h定义了模块在预编译阶段用于配置的数据。xxx_Cbk.h和用2个模块名称命名的xxx1_xxx2.h声明了某模块被低层模块调用的回调函数。xxx_Types.h定义模块专用数据类型。

2.2 数据传输功能的开发

数据传输功能是基本通信软件的核心功能。本文为所有模块开发了数据传输接口，用于数据的收发、处理和格式转换。

2.2.1 数据传输过程

整个诊断通信协议栈的数据传输过程如下：当总线上有数据发送过来时，首先经过CAN控制器硬件过滤，即进行标识符的匹配过滤。如果通过过滤，CAN驱动将通过中断或轮询的方式触发read（）操作取出CAN控制器硬件接收缓冲区的数据，然后调用CanIf_RxIndication（）将数据传递至CAN接口层，CAN接口通过查询标识符列表对数据进行软件过滤后，再调用上层的xxx _RxIndication（）进一步处理和传递数据，最后通过Dcm _RxIndication（）将数据传递到DCM层。当发送数据时，高层模块通过依次调用低层模块的xxx _Transmit（）将数据往底层传递，最后通过Can_Write（）将数据写入CAN控制器的发送缓冲区，数据再根據传送缓冲优先级依次发送到总线上，低层模块成功发送数据后通过返回xxx _TxConfirmation（）告知上层模块。

2.2.2 数据传输格式

在AUTOSAR标准中，CAN通信协议栈的硬件可以包含多个CAN控制器，但统一由同一个CAN驱动管理。CAN驱动是协议栈里面唯一可以直接访问和操作硬件的模块，它通过分配给每个CAN控制器的ID获得对它们的访问。本文只采用了一个CAN控制器，用于实现ECU和诊断系统在单一网络中的通信。

CAN驱动和上层模块的信息交互都要经过CAN接口层来传递。CAN接口层和驱动层之间的数据传输遵照ISO11898-1协议，对应于OSI模型中的数据链路层，主要解决数据帧格式，实现标准帧和扩展帧的收发，数据单元格式为L-PDU。

单帧传输时，CAN接口层直接和PduR层进行信息交互。AUTOSAR为PduR与其他模块之间的数据交换定义了一个交互层，PduR通过查询I-PDU标识符列表对数据进行路由选择，数据格式为I-PDU。

多帧传输时，CAN接口层和PduR层之间需要CAN传输层来进行数据的打包和拆包。CAN传输层和PduR层之间仍遵照交互层。CAN接口层和CAN传输层之间的数据传输遵照ISO15765-2，对应于OSI模型中的网络层，主要完成寻址和多帧传输的控制，数据格式为N-PDU。

图3以开发过程中的多帧传输为例，展示了各数据单元的格式和映射关系。

2.3 通信模式控制功能的开发

当工作条件发生改变时，如ECU上电和断电，各模块的状态或模式会自动进行转换。当通信需求改变时，需要主动切换模式，为此本文开发了一系列接口函数，主要用于切换通信波特率、CAN控制器状态、PDU通道模式。

UDS的一些诊断服务如link control要求可以切换通信波特率，以满足与不同诊断仪的通信。在CAN驱动层开发了Can_SetBaudrate（）设置波特率，入口参数是目标波特率的ID，波特率ID的选用参照ISO14229-1。

CAN控制器有4种状态：UNINIT，此时CAN控制器未初始化；STOPPED，此时CAN控制器初始化，但不参与总线；STARTED，此时CAN控制器可以正常工作；SLEEP，此时CAN控制器休眠以降低能耗，但可以被事件唤醒。CAN控制器状态在不同的通信条件下进行切换，统一由CAN接口层管理，经由驱动层实现。本文为此分别开发了2个函数，接口层的CanIf_SetControllerMode（）和驱动层Can_

SetControllerMode（）。软件通过CanIf_SetController-

Mode（ ）发出状态切换请求，然后调用Can_SetControll-

erMode（ ）操作CAN控制器的模式控制寄存器，CAN驱动层的控制器状态可以立即切换，CAN接口层的控制器状态需等到驱动层返回E_OK后才切换。

为了可以根据需求改变通信信道的收发模式，本文在CAN接口层开发了功能函数CanIf_SetPduMode（）用于实现L-PDU信道4个状态的切换：CANIF_OFFLINE，此时不进行通信；CANIF_PASSIVE，此时只接收不发送数据；CANIF_ACTIVE，此时只发送不接收数据；CANIF_ONLINE，此时进行正常的数据收发。状态机如图4所示。此外，在CAN传输层还通过CanTp_Shutdown（ ）实现CanTp_

On到CanTp_Off的状态切换，从而关闭多帧数据传输功能。

2.4 时间管理功能的开发

在CAN接口层与CAN传输层进行多帧传输时，为了防止因总线负载过高或等待时间过长导致诊断通信失去联系，本文遵照ISO156765-2中对网络层定时的规定，开发了CAN传输层函数CanTp_MainFunciton（）对通信的时间参数进行控制，主要参数有N_As、N_Bs、N_Ar、N_Br、N_Cr和STM-min。其中，STM-min决定连续帧的发送间隔，由接收方通过流控帧发给发送方，其他的时间参数都有各自的定时器，如果发生超时，定时器溢出，报告错误。假设与ECU进行诊断通信的诊断仪的内部协议栈也是基于AUTOSAR架构进行开发的。

2.5 诊断服务处理功能的开发

UDS诊断服务总共分为六大类：Diagnostic and communication management、Data transmission、Stored data transmission、InputOutput control、Remote activation of routine、Upload and download。ISO14229—1对每个诊断服务作了详细的规定，包括服务请求消息的服务标识符、子功能和数据参数，服务响应消息的服务标识符和否定响应码。

DCM模块对一个诊断服务的处理，首先需要及时对服务请求消息进行接收，其次需要对服务请求消息进行验证，最后执行有效诊断服务请求的操作。本文对应以上要求，为DCM模块分别开发了3个子模块：DSL、DSD、DSP。

DSL直接与PduR进行数据交换，完成服务请求消息的接收和服务响应消息的发送。当接收到DiagnosticSessionControl（10 hex）服务时，DSL根据请求切换诊断会话模式，并返回诊断会话的定时参数，如发送服务请求消息的一方收到服务响应消息的时间间隔P2CAN_Client，用于设定当前会话模式下应用层的超时机制。当接收到SecurityAccess（27 hex）服务时，DSL返回种子，然后再收到对方发来的密钥并验证，决定是否开放安全权限。诊断仪为了保持连接，会周期性地发来TesterPresent服务，DSL接收后将复位session timeout timer以维持当前会话模式，此后不再将该服务发给DSD做进一步处理。

DSD模块首先负责验证服务请求消息的有效性。包括检查服务标识符是否在支持的服务列表里，检查当前会话模式、安全权限和ECU状态是否支持该服务，检查服务子功能和参数格式是否正确。如果发现消息无效，则返回对应的否定响应码。如果请求消息通过有效性验证，DSD将通过诊断服务列表索引到DSP模块对该诊断请求的执行函数。

DSP模块负责执行服务请求的操作，此时需要DSP模块和诊断通信软件之外的模块进行交互。当服务请求消息请求的是读取或清除故障信息，DSP需要访问DEM模块；当请求数据上传下载或读取数据流时，DSP需要访问memory stack。当请求输入输出控制时，DSP需要通过DCM_Send/

ReceiveSignal（）接入RTE来获得对SW组件的访问。

3 诊断通信协议栈的测试

3.1 故障诊断测试平台

本文借助于自主搭建的故障诊断测试平台对开发的诊断通信协议栈进行功能和协议的验证。诊断设备采用自主开发的PC式故障诊断系统，该系统运行在个人电脑上，然后通过自主开发的VCI（车辆通信接口）接入车载诊断网络中，从而和挂载在同一网络中的ECU进行诊断通信，此时开发的诊断通信协议栈已经烧入ECU中。测试平台如图5所示。

3.2 ECU刷新测试

本文参考ISO15765—3提供的非易失性内存再编程消息流程的例子，制订了一套ECU刷新过程测试方案，用于测试协议栈的基本通信和诊断服务处理功能。在诊断通信网络中，诊断仪称作客户端，ECU称作服务器。采用标准的11位OBD CAN id，参考ISO15765-4，配置客户端的物理请求CAN ID为770，服务器的物理响应CAN ID为778，请求消息的CAN帧的无效数据填充55hex，响应消息的填充AA hex（如图6所示）。

采用PC故障诊断系统的数据监听功能进行测试。在进行诊断通信之前，PC故障诊断系统首先要对VCI进行配置，包括设定通信波特率为500 kb/s，通过复位完成配置。

整个ECU刷新测试流程如下：診断会话控制-切换到编程会话模式（0x10 02）；安全访问-获得种子（0x27 01）、发送密钥（0x27 02）；例程控制-清除内存（0x31 01 FF 00）；请求下载（0x34）；传输数据（0x36）；请求退出传输（0x37）；例程控制-检查编程依赖性（0x31 01 FF 01）；ECU复位-硬件复位（0x11 01）。考虑本文测试采用手动方式发送服务请求，难以做到周期性发送诊断仪在线服务，为此屏蔽了ECU的诊断仪在线请求超时错误功能。依次发送以上诊断服务，每发送一个诊断请求消息，立即收到ECU返回来的响应消息，每条消息有8个数据字节，首字节为有效数据个数，然后分别为响应服务标识符、子功能和数据参数。

通过以上测试表明，开发的诊断通信协议栈具有基本的通信功能并且可以正确响应诊断请求，整个过程符合协议要求。

4 结语

本文在研究AUTOSAR标准的设计思想和软件体系后，开发了一个基于AUTOSAR架构的诊断通信协议栈，该协议栈的垂直结构为从下往上的分层模块，水平结构为数据传输、通信模式控制、时间管理和诊断服务处理四大功能。该分层式协议栈的各模块可以单独进行开发和调试，提高了协议栈的开发效率和复用度。通过对硬件抽象层的修改，可以将该诊断通信协议栈快速可靠地应用到其他硬件平台，具有很高的可移植性和通用性。

参 考 文 献

[1]周涛，ISO 15765协议的研究实现[D].合肥：合肥工业大学，2011.

[2]杨会，鲁统利，王天军.基于GMLAN的汽车诊断通信仿真[J].汽车工程，2010，32（10）：902-904，913.

[3]刘丽丽，徐皑冬，宋岩，等.车辆通用故障诊断协议的研究与开发[J].计算机工程，2012，38（16）：9-13.

[4]过锡隽.汽车电控系统J1939协议和诊断通信模块的开发[D].杭州：浙江大学，2006.

[5]张培锋.参照AUTOSAR的汽油发动机ECU软件设计[D].杭州：浙江大学，2010.

[6]郭晞文.参照AUTOSAR标准的汽车电子通信与应用[D].杭州：浙江大学，2008.

[7]胡琦.参照AUTOSAR的汽车故障诊断系统的设计与实现[D].杭州：浙江大学，2011.

[8]邹志斌.车载软件中通信机制的研究与实现[D].成都：电子科技大学，2010.

[9]周毅.汽车诊断通信管理软件的研究与实现[D].成都：电子科技大学，2010.

[10]AUTOSAR GBR，AUTOSAR Specification of Diag-nostic Event Manager V3.1.0，R3.1[S].

[11]ISO 11898—1，Road vehicles-Controller area network（CAN）-Data link layer and physical signaling[S].

[12]ISO/WD15765—2，Road Vehicles-Diagnostic Syst-ems-Diagnostics on CAN-Network Layer Services[S].

[13]ISO/WD15765—3，Road Vehicles-Diagnostic Syst-ems-Diagnostics on CAN-Application Layer Services[S].

[14]ISO/WD15765—4，Road Vehicles-Diagnostic Syst-ems-Diagnostics on CAN-Requirements for Emis-sion Related Systems[S].

[15]ISO 14229—1，Road Vehicles-Unified DiagnosticServices（UDS）-Specification and Requirements[S].

[16]ISO 15031—5，Road Vehicles -Communication bet-ween Vehicle and External Equipmentfor Emissions-related Diagnostics-Emissions-related Diagnostic Services[S].

[17]AUTOSAR GBR，AUTOSAR Specification of CANDriver V4.2.0，R4.1[S].

[18]AUTOSAR GBR，AUTOSAR Specification of CANTransport Layer V5.1.0，R4.1[S].

[19]AUTOSAR GBR，AUTOSAR Specification of CANPdu Router V4.1.0，R4.1[S].

[20]AUTOSAR GBR，AUTOSAR Specification of Diagn-ostic Communication Manager V5.1.0，R4.1[S].

[21]W·齊默尔曼，R·施密特加尔.汽车总线系统[M]. 邓萍，译.北京：机械工业出版社，2009：262-272.

[22]李向燕，唐柳湘，李允.基于autosar的LIN实现[J].企业科技与发展，2012（4）：208-211.

[23]颜伏伍，王攀.基于车载总线的PC式汽车故障诊断系统[J].武汉理工大学学报：信息与管理工程版，2011，33（5）：758-762.

[责任编辑：钟声贤]