浅谈电动汽车CAN总线诊断设计

胡艳峰

（陕西重型汽车有限公司汽车工程研究院，陕西 西安 710200）

随着汽车技术的快速发展，汽车性能不断提高，汽车电子控制装置在汽车上的应用越来越多，传统的汽车布线难以满足汽车技术发展的要求，因此汽车总线技术越来越受到主机厂的关注。目前CAN总线技术在汽车上已被广泛应用，并且在相当长一段时间内仍将占据主流地位。与此同时，总线的诊断技术也在同时成长壮大。本文将着重对电动汽车CAN总线的诊断系统设计进行探讨。

1 诊断标准概述

标准化的诊断方式是车载自诊断方法的主流。提到诊断，首先让人想到诊断标准，不同类型的总线的诊断都是基于一定的诊断标准进行。ISO 9141、ISO 14230、ISO／DIS l5765都是早期诊断使用的K线标准。随着之后CAN总线技术的应用，关于CAN总线的诊断标准也随之应运而生。ISO 15765是基于CAN总线的诊断标准，但是其诊断内容更主要是针对有关排放系统；ISO 14229（UDS，Unified Diagnosis Services）统一诊断服务定义了一系列的通用的诊断服务功能；SAE J1939针对于重型载货汽车、大客车的应用，规定了一系列的DM诊断报文。本文将阐述的CAN总线诊断系统是基于UDS及ISO 15765。

2 诊断拓扑结构

为什么要有诊断呢？诊断及故障诊断，它包含两方面内容：一是对设备的运行状态进行监测，多用于车辆设计完成并装车后的功能验证，是技术人员的设计手段；二是在发现异常情况后对设备的故障进行分析、诊断，这种情况多用于4S店工作人员对故障件的故障排查及定位，以便定位、解决故障并反馈给技术人员。诊断的存在大大方便了故障的排查，即使完全不了解设计的销售人员也可以进行。

诊断的方式是什么呢？诊断时要用到诊断设备，一般称之为诊断仪。车辆设计过程中都会有诊断接口，用于诊断仪接入进行诊断。在总线型拓扑结构中，当车辆网络只有一条CAN总线时，可以将诊断仪直接挂在车辆CAN网络上，这样诊断设备就可以对网络上任意一个节点进行诊断，如图1所示。当车辆网络不止一条CAN网络时（这种情况会存在网关），有2种方式：一是在每一条CAN网络上都预留出诊断接口，方便诊断设备接入网络（相当于只有一条CAN总线的情况）；二是诊断设备通过网关实现对网络上节点的诊断功能，如图2所示［1］。

图1 诊断仪直接挂在CAN网络上

图2 诊断仪通过网关进行诊断

3 寻址方式

ISO 15765-2定义了网络层协议数据单元［2］，即N_PDU（Network Protocol Data Unit）。N_PDU的目的是建立一个点对点的网络通信的通道，用于交换通信参数及数据传输。ISO 15765-2描述了4种不同类型的网络层协议数据单元，这4种分别是单帧、首帧、连续帧以及数据流控制。诊断报文采用常规固定式地址模式，并定义了两种寻址方式，一种是物理寻址，一种是功能寻址，详见表1、表2，表中详细描述了CAN报文格式，包括报文内容、数据场以及单个位的定义。

N_PDU类型用N_PCI（Network Protocol Control Information）来区分，详见表3，由表3可看出，字节1的高四位用于区分N_PDU的类型。

表1 物理寻址报文格式

表2 功能寻址报文格式

表3 N_PCI字节概述

表3中其它缩写含义如表4所示。

表4 表3中缩写含义

4 诊断服务选取［1］［3］

ISO 15765-3、UDS中规定了一系列的通用诊断服务。诊断服务的本质是信息交互，一般是诊断仪对节点发出诊断需求，被诊断的节点需要给出相应的响应，即应答信息（应答有肯定应答和否定应答两种）。由于通用的诊断服务是非常全面的考虑，主机厂在开发自己车型的诊断系统时，肯定不能将所有诊断服务都用到，因此都需要根据自身的需要选取需要的诊断服务，从而形成自己车型特有的诊断系统。某电动汽车车型诊断服务选取见表5。

表5 诊断服务选取

表5的服务中，应答ID均指肯定应答ID。每一个诊断服务请求的肯定应答在UDS中都有具体的定义，并根据请求方式的不同肯定应答的方式不同，即都定义了相应的消息帧格式，这里不再详述。但对于否定应答，只给出了通用的否定应答。否定应答消息格式及否定应答代码详见表6、表7。

表6 否定应答消息格式定义

表7 否定应答代码

5 诊断参数定义

诊断服务是诊断标准规定的，主机厂只能在里面选取自己需要的服务，并在自己的诊断系统实现即可；诊断参数却是由主机厂自己来定义的，具体可理解为功能诊断行为及故障代码的定义。电动汽车的主要节点按所属系统划分见表8。

表8 电动汽车节点划分

5.1 故障代码定义

SAE J2012针对排放系统给出了一种占用2个字节的故障代码的定义方式，见表9。

表9 SAE J2012故障代码定义

电动汽车由于没有发动机等，因此SAE J2012规定的故障代码不能直接使用。鉴于电动汽车自身的特点以及参照SAE J1939定义的故障码为4个字节，这里自定义一种故障代码的描述方式，具体为一个诊断故障代码（DTC）占用4个字节，并由4个部分构成，这4个部分是：故障等级、系统分类代码、故障代码和故障发生次数，数据填充方式选用Intel。详见表10。

说明：①故障等级占3位，共有4级故障等级，其中4级故障最为严重。②系统分类代码为P、C、B、U，分别代表动力系统代码、底盘系统代码、车身系统代码和通信网络系统代码；为了与SAE J2012故障代码定义兼容，定义第1字节系统分类代码中的P、B、C、U用第4位和第3位来表示，具体为00：P；01：C；10：B；11：U。故障代码定义如表11所示。

表10 自定义故障代码格式

表11 故障代码定义

按照故障代码格式给出故障码例子，如电机母线电压欠压故障为3级故障，故障代码为P1064，故障代码示例见表12。

表12 故障代码示例

5.2 诊断功能定义

现在就仪表节点给出诊断功能定义示例。电动汽车仪表上要通过CAN总线显示电动汽车特有的一些点亮符号［4］，可参照表13。

表13 GB/T 4094.2—2005标准内容

我们定义一个字节来包含表13中的报警提示，并定义0——指示灯不点亮，没有发生故障；1——指示灯点亮，发生相应故障。报警提示定义见表14。

表14 报警提示定义

5.3 版本信息

版本信息是诊断中一个需要关注的点。在诊断测试过程中，很多时候会出现信息不匹配，这时候首先要查的是版本信息是否正确，因此主机厂一般都会要求网络中的各个节点发送自己的版本信息。版本信息定义见表15。

表15 软件版本信息定义

6 总结

本文从诊断拓扑、诊断标准到用户自定义的诊断参数，详细阐述了诊断系统的设计过程。此外还对电动汽车的节点进行了系统分类，并提出了一种自定义的诊断故障代码格式。

［1］ ISO 14229—2006，Road vehicles-Unified diagnostic services（UDS）-Specification and requirements［S］.

［2］ ISO 15765-2：2004，Road vehicles-Diagnostics on CAN-Part 2：Network layer services［S］.

［3］ ISO 15765-3：2004，Road vehicles-Diagnostics on CAN-Part 2：Application layer services［S］.

［4］ 胡艳峰.基于CANoe的新能源车显示屏测试［J］.汽车电器， 2017（1）：8-11.