作者 | 李伟 上海控安安全测评中心安全测评部总监来源 |鉴源实验室

引言：前两篇文章（汽车电子架构和CAN网络基础，车载ECU嵌入式软件的测试入门）我们讲了汽车电子架构和网络历史，分享汽车测试中的小知识，本章节我们将从诊断服务测试开始给大家细说测试相关知识。我们一直强调，CAN网络通信是ECU中非常重要的基本功能，诊断服务就是基于CAN网络实现的非常重要的基本功能。在实际项目中，ECU的CAN网络测试内容项比较多，供应商和主机厂测试，跟网络底层相关的CAN协议一致性测试之类，比如电平、通信速率、信号的各种精度等，还包括EMC测试，环境可靠性测试等等。我们这里主要讲上层的相关应用测试。

01

诊断相关基础小知识

1.1 诊断地址

ECU的诊断地址，跟以太网设备间通讯地址设置不一样。在以太网中每个设备都有一个唯一标识符MAC地址。设备间的单播通讯如下图所示：

图 1

以太网络的端口地址直接对应物理设备，设备出厂时Mac地址直接烧录在网卡的E²PROM中，从以太网地址配置上也可以看出两者间的对应关系。ECU的诊断地址是不一样的，不存在类似以太网那样的通讯端口，没有像以太网那样地址跟设备端口的绑定关系，厂商也不会有一个唯一地址在出厂时烧录进CAN处理芯片中，我们可以把它理解为逻辑上的地址。ECU接收到诊断请求时，检查数据帧的接收地址是否跟本ECU配置的诊断地址一致，如果一致则接收并处理，不一致就丢弃。发送数据时则在数据帧对应位置写入配置好的本ECU诊断通讯响应CANID。通过下图我们可以直观的看到诊断通讯关系。

图 2

1.2 物理寻址和功能寻址

在1.1章节中我们通过以太网的设备间单播通讯来类比解释了CAN网络两个ECU间的一般通讯。我们知道以太网有单播、组播、和广播通讯，对应CAN网络有物理寻址（Physical Address）和功能寻址（FunctionalAddress）。

我们通过一个生活中的例子来说明物理寻址和功能寻址的区别。比如我们在统计办公室员工的核酸检测情况时，统计人员分别找到每个员工进行询问，这种方式就类似物理寻址，是一对一的通讯；统计人员在办公室吼一嗓子“大家核酸都做过了么，分别私下跟我说下”，然后每个员工单独回复统计员，这种一对多的询问就类似功能寻址。

通过上述例子，我们可以知道ECU间点对点通讯是物理寻址实现，一对多发出请求是通过功能寻址实现。这里我们强调下即使请求报文是功能寻址，响应端发送回复报文时依然是使用物理寻址来进行答复（不是功能寻址答复）。在实际项目中很多ECU的功能寻址地址通常都是0x7DF，具体项目中ECU地址是多少需要查阅项目对应的诊断规范文档。

通过上面两个章节的讲解，我们可以知道ECU通常情况下会有3个地址，分别对应物理寻址的发和收，以及功能地址。

我们要注意的是CAN网络是总线型网络，采用的是CSMA/CA机制。ECU间的物理寻址和功能寻址的通讯报文在物理层面上其实都是以广播的形式存在的，所有广播域内的ECU均能收到该通讯报文，至于收到该广播报文后如何处理，ECU对比报文的目的地址跟自身的物理寻址接收地址和功能寻址地址是否匹配，然后再决定后续操作。

02

统一诊断服务（UDS）

UDS的全称为Unified Diagnostic Services，关于UDS的详细描述和定义，大家可以查阅ISO 14229标准的系列文件来深入了解。网络上能够找到的关于UDS的文章非常多，我们这里从通俗易懂的角度给大家进行介绍，适合测试工程师快速入门，然后在实际项目中有工作经历之后可以通过其他方式再深入了解相关知识。

之所以一直强调UDS功能比较重要和基础，是因为USD功能在车辆生产和使用过程中对很多其他功能模块和基本操作有直接的影响。首先在车辆生产线下线时，产线电检会使用电检仪通过UDS对多个ECU写入很多必要的预设值信息，如写入对应车辆的VIN码、零件号、物流信息等，还可以激活某些特定设置，或者锁定一些特定状态以防止零部件的随意变更等等。车辆在4S店进行维护保养时，ECU固件的升级、故障码的读取和消除等等，也是通过OBD口连接使用UDS相关服务来完成的。

在上一篇文章中我们提到了，CAN网络上设备间通信基本可以分为3种情况，分别是：设备周期性主动发送一些状态报文；某个条件发生改变并符合设定要求，从而被动触发型信号发送；查询和回复型信号。这里查询和回复型主要就是UDS功能产生的。

为了方便理解，我们可以不是很准确地把UDS看作一个应用层协议（实际肯定不准确），因为在项目开发、测试、标定、排错等过程中接触最多的就是应用层相关的功能。

基于查询和回复这种问答式通信方法，在CAN网络上可以实现很多功能，如获取信息、写入信息、会话控制、重启设备、上传下载等等。我们把每种实现了特殊功能的查询和回复称为一种服务，UDS总体上有6大类，共26种不同服务。至于在具体项目中，网络架构工程师和系统设计工程师会根据实际情况对ECU支持的UDS服务种类进行裁剪，所以一般情况下ECU支持的服务种类要少于26种，通常还会对服务的对子功能做自定义设计。

2.1 请求报文

请求报文的格式比较简单，通常由3部分组成，首先是Service ID固定长度1字节，Service ID直接表明了本服务支持的功能类型，就是前面我们说的26种服务中的一种，Sub-Function是对应的具体服务的每个子功能项设置，有的服务有多个子功能，也有的服务没有子功能，所以Sub-Function项是可选项，最后Parameter项是对应到最详细子功能的属性参数配置项，属性参数的配置也是根据实际情况来进行配备。

图 3

通常Parameter在具体项目中是工程师自定义最多的对象，也有主机厂在诊断规范中会自定义子服务。

我们举一个常见的服务来给大家说明下，如10服务。Service ID是10，功能是用来做会话控制，子功能通常是3个，分别为01、02、03，没有parameter参数，3个子功能分别代表了3种不同会话模式。在某个主机厂的诊断规范中自定了子功能04，为特殊场景自定义了该会话模式。综上所述10服务的请求报文通常会有：10 01、10 02、10 03。

2.2 响应报文

对应于UDS请求报文，ECU通常有3种不同的响应处理。

1）Positive Response正响应

正响应是ECU对接收到的请求给予明确的成功内容结果返回，意味着请求得到成功执行。例如请求是读取车辆VIN码，正响应就是回答VIN是XXX。

正响应返回的报文格式跟请求报文类似分为3个部分，首先是Response SID是对请求服务的回显，Response SID的值为请求报文中SID + 0x40；其他两部分内容为Sub-Function和Parameter，这两部分的内容根据具体情况确定，在项目诊断规范中有明确规定。

正响应的报文格式如下图所示：

图 4

例如：请求10 01，正响应为50 01；请求22 XX XX，正响应为62 XX XX XX。

2）Negative Response负响应

负响应是ECU收到请求之后，无法对请求的内容正确执行，回复了失败，并附带了失败的原因。

负响应回复报文的格式同样可以分为3个部分，首先第一个字节是0x7F，表明请求失败，第二个字节为请求的服务ID，第三个字节为失败原因代码NRC。NRC代码具体对应的失败原因可以查阅NRC的表格来确定，在具体的项目中这部分内容可以查阅项目中的零部件网络诊断规范，在文章中我们多次提及了该文档，这个文档是由车型项目组的网络电子架构团队负责整体汇总发布，零部件的产品系统设计工程师负责维护和变更，所以在实际项目中可以找这两个岗位的工程师获取。

负响应报文格式如下图所示：

图 5

例如：请求10 02，负响应7F 10 7E，7F表明该相应失败，对应的失败服务是10，失败原因是7E，查阅NRC表知道7E的含义是“Sub-function not supported in active session”，提醒使用请求10 02子功能请求时不应该在当前会话模式下，当前的会话模式不支持10 02子功能请求使用。

3）无响应

无响应的出现是网络架构部门为了降低CAN网络上报文环境的复杂情况而做的设计。目的是不回复请求方正响应数据帧，即，当即将答复的响应帧为正响应时，不发送响应帧。

无响应是通过请求报文中子功能的抑制肯定响应指示位实现的。在某些服务的子功能中，最高的bit7位置为1时即设置为正响应抑制，该位置为0时关闭响应抑制。支持响应抑制设置的服务有10、11、28、3E、85等等。

图 6

例如：发送10 81，当回复是正响应时，ECU不答复；发送10 82，答复7F 10 7E，同样是请求带正响应抑制，但是ECU执行失败，此时则进行了回复。

我们之前强调，可以把UDS视为应用层协议，各主机厂对规范的自定义空间比较大，可以自由进行定制化修改。我在一个项目中遇到工程师设计了负响应抑制，跟本章节我们前面内容说的场景恰好相反，前面我们细说了当ECU响应为正响应时进行抑制，只回复失败。在一个项目中我遇到的是某些特定服务ECU正常发送正响应，只有负响应被抑制处理。所以诊断规范的自定义操作空间较大，测试设计时一定要仔细查阅相关规范。

2.3 通讯帧

在上一章节中我们使用了一些服务来举例，实例中包含了的是有效的数据内容，在CAN网络上进行UDS报文传输时，CAN网络的特性对于传输内容长度有一定要求，普通的CAN数据帧每帧8字节长度，在这个长度的报文上传输UDS协议数据时肯定会受到相应的限制，如果1帧报文长度不满足载荷需要，那就需要使用多条数据帧来信息承载。

1）单帧通讯

我们在上一章节列举的例子内容长度均比较短，7个字节的单个数据帧足够使用，这样的数据帧为单帧。

我们通过工具来查看网络上服务问答真实数据报文形式，如下所示：

图 7

我们可以看到两条报文：报文1)，Tester传输，ECU接收ID717，数据长度8字节，我们使用了SID10的会话控制服务，发送了报文“02 10 01”，其中首字节“02”表明本报文后面有效数据长度为2字节，第二字节“10”表明服务为SID10，第三字节“01”表明子功能为01，剩余4-8字节使用AA自动补全。报文2) Tester接收，ECU发送ID71F，数据长度8字节，正响应SID10的会话控制服务，发送了报文“02 50 01”，其中首字节“02”表明本报文后面有效数据长度为2字节，第二字节“50”表明SID10+0x40属于SID10服务的正响应，第三字节“01”是对应子功能。

2）多帧通讯

当一个数据帧7个字节不能完成一次通讯时，就需要把数据拆分到多个数据帧进行传输。我们同样通过下面的实例来进行讲解。

图 8

我们首先看请求报文“03 22 F1 80”，首字节“03”表明报文后面有3字节有效数据，第二字节“22”表明是SID22读取服务，22服务没有子功能，第三、四字节是$22服务读取的参数；返回报文的首帧为“10 10 62 F1 80 56 30 2E”，第一个字节“10”表明本条回复报文是多帧的第一帧，第二字节“10”表明后继有效数据长度为0x10字节，换成10进制为16字节，第三字节“62”是正响应服务SID22+0x40，第四、五字节表明Parameter参数为F1 80，后继的有效数据13字节的信息即为F1 80的读取值；第三帧报文“30 00 00 00 00 00 00 00”，为多帧的流控帧，提示首个响应报文成功发送，继续发送剩余帧；第四帧“21 30 30 2E 30 30 46 42”首字节“21”表明是多帧的第二帧，本帧其余字节均为有效数据内容；第五帧“22 4C 42 31 AA AA AA AA”，首字节“22”表明是多帧的第三帧，因全部多帧的有效长度在第一帧中记录为16字节，所以至此第三响应帧时有效数据内容只有3个字节，加上首字节的序号位，前4字节为有效位，剩余4字节自动填充。

03

部分诊断服务

本章节我们对用到的一些服务做简单介绍，后续使用最频繁的服务我们会单独讲解。

1）$3E服务

$3E服务的用处是提示ECU状态保持，如扩展会话的状态在一段时间后自动退出到默认会话，使用3E服务可以将会话保持在扩展会话模式下。

请求格式为3E 00和3E 80，其中3E 80即为正响应抑制，不需要ECU回复。3E 00的正响应回复报文格式为7E 00。

2）$11服务

$11服务的作用是将ECU进行复位，最常用的有3个子服务，分别是01、02、03，04、05分别是使能和禁用快速休眠，0x40-0x7E为主机厂和零部件供应商自定义字段。

11 01硬复位ECU，即要求ECU执行电池断电到设备上电的重启；11 02车辆点火复位，即要求ECU执行车辆整车电源从off到on状态下的设备复位；11 03软复位ECU，即要求ECU执行应用程序重启，相当于热启动。

11服务发送请求报文后，不一定有响应报文，因为ECU执行成功就是设备重启，所以有主机厂要求11服务支持正响应抑制标识，会要求发送11 81。

3）$31服务

$31Routine服务基本上是厂家定制操作最多的服务，厂家可以预设值很多操作，然后通过31服务来调用执行。比如可以让进行ECU状态检查，让ECU通过预设算法生成特定数据，然后根据这些特定数据生成状态，可以通过31服务锁定这些状态，这个功能在主机厂锁定车辆上配套ECU零部件时会经常用到，这样一旦锁定了当前车辆ECU，其他任何人都不能随意更换，车主想要对这些ECU进行更换维修只能到指定正规的4S店完成，零部件一旦随意更换，通过31服务调用执行生成的状态锁定数据跟车辆不匹配，更换的ECU根本无法正常使用。当然这只是31服务的一个设计功能。

31服务由4部分组成，第一部分SID31；第二部分子功能，分别是01启动、02停止、03查询；第三部分要调用执行的routineID，这部分开始有主机厂自定义；第四部分可选的routine控制参数，跟第三部分的routineID是对应的，也是主机厂自定义内容。例如：31 01 08 09，让ECU调用执行08 09routine，ECU执行成功反馈71 01 08 09，执行过程出现一些问题，条件不满足会返回71 01 08 09 xx yy，其中xx yy是不满足的条件，这里的不满足条件指的是执行当前31服务时的一些ECU其他信息预置条件，如执行当前服务需要已经生成了XX信息，已经锁定了XX状态等，可以理解为服务的内部执行错误。当然如果返回7F 31 7E同样是执行失败，失败的原因可以查找NRC，NCR中的错误我们可以把他理解为服务外部错误，如执行安全等级不正确，会话模式不正确，子功能不存在，超出范围限制等等，NRC错误跟上面的不满足条件失败是两种类型。

04

UDS的测试

UDS的测试通常在收到首个软件版本后就开始执行了，测试的时间段主要集中在OTS造车前，OTS开阀前必须确定UDS功能正常无故障。

UDS的测试设计依据最重要的文档就是零部件的网络诊断规范，在规范中详细定义零部件支持的所有服务，以及服务的所有子功能和属性参数。

通常UDS的功能测试设计重点在功能正常执行场景部分，按照服务、子功能、功能属性参数列举所有请求报文，分别在不同会话模式和安全控制模式下，测试物理寻址、功能寻址的返回情况。正常测试还需要对会话返回的NRC进行测试，这一部分内容通常会被测试工程师遗漏，因为NRC中有部分的测试条件难以预置。

UDS功能还需要进行异常测试的设计，这部分的测试设计通常可以跟NRC部分合并进行。

在设计DTC故障场景模拟时，需要特别注意电源短路的模拟，需要跟硬件工程师确认是否对电源供电，线路板PCB静电泄放等做保护性设计，否则容易造成板卡烧坏。

虽然我们是执行UDS的功能测试，不需要对通讯的时隙精度等进行验证，报文响应间隔时间的精度，超时时间范围精度这些时间相关测试，通常跟信号电平等等一起在开发早期完成。但我们还是建议在测试设计上加入执行时间监控测试，以及报文间隔不同时隙的测试。如多帧发送或响应时，帧间不同时间间隔设置的影响；会话自动退出的时间是否在设计要求内；$30服务不同发送时间间隔对会话保持的影响等等。这部分功能在开发初期通常比较容易出现问题。

阅读原文