汽车C A N总线诊断通信模块的开发测试

申帅赵恬

（重庆邮电大学 自动化学院，中国 重庆 400065）

0 前言

随着汽车电子技术的飞速发展，越来越多的电子器件应用到车辆内部，极大的提高了车辆的安全性、可靠性和舒适性。同时也带来了新的问题，车身线束增多、车辆故障诊断困难增加[1]。为了减少车身线束、提高通信速率，车载总线技术应运而生。

CAN总线以其在高实时性、可靠性和抗干扰能力等方面的优势，成为当前应用最为广泛的车载总线技术之一。本文遵循国际诊断标准ISO 15765完成诊断通信模块的开发，实现过程采取分层模块化设计，提高通信模块的通用性、重用性。

1 ISO 15765诊断协议体系

ISO 15765是2000年欧洲汽车厂商推出一种基于CAN总线的诊断系统通信标准，目前ISO 15765标准已被多数整车厂商采用，成为汽车行业的通用诊断标准[2]。ISO 15765根据开放系统互连（Open System Interconnection,OSI）7层参考模型，采用分层思想模块化设计的方式，各模块负责处理各自功能并提供标准接口[4]，各模块间通过接口调用实现通信，以减低模块间耦合度，增强协议栈的通用性和可靠性。

ISO 15765-3以ISO 14229为基础定义诊断协议栈应用层的内容，对应于OSI模型应用层，主要包括应用层诊断服务格式、应用层接口、应用层时间参数等信息。ISO 15765-2定义了诊断协议栈网络层的内容，对应于OSI模型网络层和传输层，包括了网络层单帧、多帧传输机制，以及多帧传输过程中的流控制、时间处理、错误处理等内容。

2 通信模块的开发

网络层的实现是整个通信模块的主要内容[3]，其核心是多帧传输机制中ECU内部的状态转换、时间管理以及错误处理。

2.1 网络层多帧传输机制

CAN总线数据传输以CAN数据帧为基本数据单元，每一个CAN数据帧最多可传送8个字节的数据，而完成汽车诊断功能需要传输的数据往往大于8个字节，因此需要采用多帧传输机制。ISO 15765-2定义了4种网络层协议数据单元N_PDU以完成单帧或多帧的数据传输，4种帧类型通过N_PCI（网络层协议控制信息）区分[4]。其定义格式如表1所示：

表1 CAN总线报文格式定义

不同的帧类型由N_PCI第一个字节的高四位区别，N_PCItype的值0、1、2、3分别代表了单帧、第一帧、连续帧和后续帧。流控帧FS为流状态参数，BS为连续帧块大小，STmin为连续帧发送的最小时间间隔。

在多帧传输的过程中，网络层的内部操作为解决对等实体间的数据同步通信问题，采用了数据传输流控制方法，通过流控帧实现对通信双方的管理，是发送端适应接收端网络层的接受能力。其传输过程如图1所示：

图1 多帧传输过程

2.2 状态转换机制

为了实现网络层多帧传输机制的复杂逻辑，在程序编写过程中设计状态机，用枚举类型定义了数据传输过程中ECU网络层在某一时刻的所有可能状态。

数据传输过程中ECU处理不同类型被定义为不同的外部事件，ECU在不同的状态下将处理不同的CAN帧。ECU网络层状态定义是收敛的，因此在某一时刻一定会处于所有状态中的其中一个，保证能够对所有类型CAN帧都能够响应；且ECU网络层状态是正交的，不会对同一类型CAN帧重复处理。

此外ECU根据当前网络层状态，对所收到的CAN帧处理，不仅取决于接收到的帧类型，还取决于不同帧类型的相对收发顺序。当ECU网络层处于某一状态收到相应帧类型，且满足特定的条件时，才能处理相应CAN帧并完成ECU状态转换。

2.3 时间管理

网络层时间管理主要是超时处理和延时发送功能。ISO 15765定义的网络层时间参数有 N_As，N_Bs，N_Ar，N_Br和 N_Cr。 超时处理通过对时间参数的控制，防止通信双方中的一方因为潜在错误挂起时，另一方持续等待从而失去通信能力。延时发送功能用于多帧传输过程中连续多条后续帧的发送，连续两条后续帧之间的发送间隔必须大于ISO 15765定义的最小时间间隔STmIn。

协议栈时间管理利用ECU的系统时钟实现，通过配置每1ms产生一次系统中断，在中断处理函数中对定义的16位无符号计数器timeoutCounter进行减1操作。在通信过程中每接收或发送一条报文，则会更新计数器为相应时间参数的门限值，在进行下一步操作之前首先判断计数器是否为0，若为0则说明超时，中断当前接受或发送进入相应的超时处理。

2.4 错误处理

网络层的错误包括了帧格式错误、帧参数错误。通信双方必须按照ISO 15765规定的帧格式、帧间逻辑及时间参数收发报文，任何类型的错误都将导致当前通信中断，并进入相应的超时处理。网络层错误类型及处理方式如表2所示：

表2 网络层错误处理描述

3 通信模块的测试

诊断协议栈的测试采用德国Vector Informatik公司总线工具CANoe及其配套专用诊断测试工具CAN dela Studio、CANoe Option DiVa，作为测试仪。协议栈运行在采用NXP LPC 1768为控制器的开发板，作为下位机。测试仪和下位机通过标准的DB9接口连接，CAN总线的通信速率定义为500Kb/s，物理寻址请求报文ID定义为0x766，功能寻址请求报文ID定义为0x760，响应报文ID定义为0x7A6。

根据诊断需求使用CAN dela Studio配置生成诊断数据库（CDD文件），将诊断数据库导入CANoe Option DiVa中自动生成测试用例并通过CANoe运行，如图2所示。

图2 通信模块测试结果

4 结论

测试结果表明，本文所述实现的诊断协议栈符合ISO 15765标准，能够完成汽车故障诊断功能，且具有较强的可靠性和通用性。并且协议栈各模块参考AUTOSAR架构设计实现，方便协议栈在不同硬件平台的移植，具有较强的复用性和可移植性。

［1］郭刚，王励明，卢明.基于 MVCI、ODX的诊断标准研究[J].制造业自动化，2010，（10）：15-16.

［2］李锐，王晶莹，姚燕，等.基于ISO 15765的车载CAN网络诊断设计[J].计算机工程，2012，(4):35-36.

［3］韩鑫，鲍可进.CAN总线网络层协议栈开发测试[J].计算机工程，2011（08）：232-234.

［4］程安宇，赵国庆，冯辉宗，等.基于CAN总线的电子控制单元功能测试方法[J].计算机应用，2012(1):139-1.