为了便于学习ISO14229UDS诊断协议，提供两个资源链接：

a)ISO14229-Part1，2，3，4，5，6，7UDS最新标准文件获取路径

b)ISO14229Roadvehicles—Unifieddiagnosticservices(UDS)标准各Part部分修订和发布状态汇总

诊断的概念来源于医学，医生通过询问、观察病人，或者通过仪器检测，利用数据对病症做出判断。

而车辆诊断的目的也有类似的地方，为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因，从而为维修提供可靠的依据。

内容大致分为三个部分，首先介绍诊断的基本概念，再为大家讲解UDS诊断协议，以及协议中常用到的诊断服务，最后对今天的内容做一个小结。

车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议，常用的诊断协议有ISO14230，ISO15031，ISO15765，还有我们熟悉的ISO14229就是UDS协议，在协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。

UDS是UnifiedDiagnosticServices的缩写，在国际标准ISO14229-1中定义，UDS标准中除了定义服务的用法，以及服务的格式以外，还定义了一些标准化的数据，而到OEM要使用UDS协议时，除了要使用标准定义的服务以及标准数据以外，还要依据自身的情况，定义属于OEM的特定数据，比如说，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。

随着车辆ECU的增多，车辆网络拓扑结构也越来越负责，比如说一辆车需要有多种总线(CAN总线，LIN，以太网，FlexRay)，

所以在2013年释放的UDS协议中，除了对通用诊断服务的定义以外，还增加了关于UDS在各个总线中应用的定义

这张图就描述了UDS在OSI七层模型中的应用，OSI七层模型，第一层第二层分别定义了物理层和数据链路层，第三层第四层定义了网络层和传输层，第七层是应用层。

比如说我们熟悉CAN总线，物理层和数据链路层遵循的是ISO11898，而它的传输层遵循的是ISO15765-2，在ISO14229-3中定义了UDS基于CAN总线的应用，而现在比较火的以太网，它的物理层和数据链路层遵循的是ISO13400-3，它的传输层也就是DoIP遵循的是ISO13400-2,它的UDS基于以太网的应用是ISO14229-5

下面我们来看下，关于诊断服务的一些知识，

首先来看服务请求和响应格式，“请求”由Tester端发送给ECU，请求报文里带有SID，根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”

看两个名词，一个叫做Subfunction，一个叫做ID，UDS服务支持Subfunction的请求和响应格式，“请求”为“SID+一个字节Subfunction+具体的数据”，肯定响应为“SID+40+Subfunction+具体的数据”，而有的UDS服务里面是不支持Subfunction，是支持DID的，DID是“数据ID”的意思，那么它的请求格式为“SID+具体的DID+数据内容”，肯定响应“SID+40+DID+具体的数据”，这里举出两个例子，一个是“31例程控制服务”，还有一个是“2FIO控制服务”，31就是它的请求报文里面，带一个字节的Subfunction和两个字节的RoutineID，后面的这个数据是跟具体的数据内容，也可以没有具体的数据。2F是它的SID+两个字节的DID+一个字节的输入输出控制参数(这里注意这一个字节的数据类似于Subfunction，但是他不是Subfunction)+后面加具体的数据内容。

下面为大家介绍一个概念，为肯定响应抑制位。肯定响应抑制位是在Subfunction里的这个字节的最高位，我们把它叫做肯定响应抑制位。只有这个服务支持Subfunction的时候，才有可能支持肯定响应抑制位，当肯定响应抑制位置1的时候，要求所有的肯定响应的抑制将不再发送。当肯定响应抑制位为0的时候，肯定响应是不被抑制的。这里要注意的是它只是抑制肯定响应，而否定响应是不被抑制的。

Tester发送的请求报文格式错误，或者请求发送的条件处于错误，ECU将发送否定响应，否定响应的格式是“7F+SID+NRC”，常用到的NRC在这里罗列了。

11表示服务不支持；

12subfunction不支持；

13请求的长度不正确，或者格式不正确

31是请求超出范围；

7E是在当前会话下subfunction不支持

7F是在当前会话下服务不支持

来看两个时间参数，一个是叫做P2Sever，一个是叫做P2Sever*。当Tester给ECU发送请求过后，ECU需要在P2Sever时间内给出相应的响应，如果ECU当前正在处理别的任务，处理别的事情，而不能在P2Sever的时间内给出相应的响应，那么它先在P2Sever时间内给出一个NRC为78的Pending报文，告诉Tester“ECU正在忙”，之后会在P2Sever*的时间内给出其它的响应报文，如果P2Sever*的时间内还是不能给出相应的肯定响应和否定响应，将继续给出Pending报文，直到能够正确处理请求报文之后，会给出正确的响应报文。

今天会着重介绍26个UDS服务里的6个，分别是10诊断会话控制，14清除诊断信息，19读取诊断信息，22由DID读取数据，27安全解锁服务，2E由DID写入数据。

下面我们来看诊断会话控制就是10服务

ECU会有不同的会话控制，所以ECU在不同的阶段，比如说开发，生产，售后阶段也会用到不同的会话模式，因为每个服务功能的不同，也会在诊断规范里定义这些服务所支持的诊断会话模式

这张表是14229里面，对各个诊断服务，对会话控制的支持情况，比如说通信控制28服务，要求在默认会话下不支持；27安全解锁服务，在默认会话模式下不支持；和刷写相关的34,36,37服务，在默认会话下也是不支持的。

我们来看更会话控制有关的3个NRC，首先来看NRC7F:NRC7F是指在当前会话下服务不支持。28通信控制服务，要求在默认会话下是不支持的，在扩展会话下能支持。而当ECU处于默认会话的时候，我们上位机发送了28这个服务，ECU收到之后，会回复7FNRC的否定响应。

NRC7E和NRC7F不同的是：NRC7E是在当前会话下Subfunction不支持。一个用的比较多的用法是，编程会话是不能够由默认会话跳转到编程会话的，只能由扩展会话跳转到编程会话。但ECU处于默认会话的时候，执行了1002编程会话的请求，ECU会回复7ENRC的否定响应。

再来看NRC31，NRC31常用的用法是请求超出范围，比如说22服务，发送的DID，是ECU不支持的，比如说发送的请求220101，因为ECU不支持0101这个DID，会发送NRC31的否定响应，还有一个用法是：22在3个会话(默认，编程，扩展下都是支持的)，22后面所跟的DID来读取数据的DID对各个会话等级是有要求的，比如说读取硬件版本号在编程会话模式下是支持的，读取车速在编程会话下是不支持的，当ECU处于编程会话的时候，来通过C001来读取车速，那么ECU会回复NRC31的否定响应。

这个是会话状态的一个状态机，状态机之间可以互相跳转，状态机自身也能跳转，我们把除了默认会话之外的会话状态，都叫做非默认会话状态。当ECU一上电的时候是处于默认会话的，我们通过10，比如说1003,1002来将会话状态由默认会话跳转到非默认会话。由非默认会话执行1001跳转至默认会话。当ECU处于非默认会话的时候，S3time这个时间超时，ECU也会从非默认会话跳转到默认会话。为了防止ECU从非默认会话跳转至默认会话，我们要求Tester端周期发送3E服务Testerpresent，让ECU一直维持在非默认会话。那么S3time这个时间怎么用呢？我们来看下面这张图

Tester端会利用S3Client周期发送Testerpresent给ECU，ECU收到Testerpresent比如说3E00，3E80的服务请求，会让ECU维持在非默认会话，如果Tester端S3server这个时间内，比如说5000毫秒时间内，都没有给ECU发送任何诊断请求报文，那么ECU就会从非默认会话跳转到默认会话；如果ECU处于解锁状态，也会从解锁状态跳转到锁定状态。通常S3cleint时间小于S3server的时间，比如说网关延时的一些情况。

这个是10服务的请求和响应格式。SID+一个字节的Subfunction(常用的有01默认会话，02编程会话，03扩展会话)，它的肯定响应格式是50(就是10+40)+一个字节的Subfunction(就是诊断会话类型)+4个字节的会话参数。

支持的NRC有3个，12subfunction不支持；13请求格式或者长度错误；22条件不支持。

下面我们来看下，安全解锁27服务。

常用到的服务：2E服务通过DID来写入数据；2F通过DID来控制输入输出端口的数值；还有ECU刷写有关的编程服务。这些服务都会改变和影响一些内存里的数据，或者输入输出端口的一些值，所以这些服务是一个被保护的服务。这些服务只有ECU处于解锁状态下才能够执行，而ECU一上电处于锁定状态，那么ECU如何从锁定状态跳转到解锁状态呢？

是要求Tester端和ECU端进行27解锁服务之后，ECU才能够处于解锁状态，那么这个解锁的过程是一个固定的：首先由Tester端给ECU发送请求报文来请求种子，ECU收到这个报文后，回复肯定响应，肯定响应里带有种子数；Tester端收到这个种子数，根据自己安全算法算出来一个K1发送给ECU，ECU也有自己对应的安全算法，他由这个Seed算出来一个密钥K2，当ECU收到这个K1后和自身计算的K2进行比较，如果两者是一致的，那么ECU发送肯定响应给Tester端，告诉Tester端ECU已经解锁。

我们刚才也提到了ECU一上电处于锁定状态，只有执行了安全解锁的流程后才能跳转到解锁状态，一个ECU可以同时拥有多个安全等级，多个安全等级之间可以是相互独立的，也可以是有依赖关系的，比如说要求先解锁安全等级1才能解锁安全等级2，那么当ECU处于解锁状态的时候，会有几种情况会使ECU由解锁状态跳转至锁定状态，比如说执行了11复位服务，比如说有了重新上下电，还比如说有了执行10会话切换，也会让ECU由解锁状态跳转到锁定状态。

当ECU处于解锁状态的时候Tester端再去请求种子的时候，回复的种子全为0。

这个是请求种子的请求报文和肯定响应报文。请求报文为“27+01”；肯定响应“67+01+四个字节的种子”。

当Tester端计算得到了一个密钥，它会发送“27+02+4个字节的密钥”给ECU。当ECU将两者密钥比较后，它认为比较的结果是一致的，ECU会给Tester端发送“67+02”，认为ECU已经处于解锁状态。

那么当ECU已经处于解锁状态的时候，Tester端又一次请求了种子，发送了请求种子的请求报文给ECU，那么ECU就会回复“种子数全为0的肯定响应”报文给Tester端。表明ECU现在处于解锁状态。

这个是27服务支持的所有NRC是在14229-1里定义，比如说我们常用的12；13；这里注意24是一个请求顺序错误，比如说我们要求的安全解锁状态过程必须是先请求Seed再发送key，如果你没有执行请求seed的请求报文，直接发送了key，就会回复24NRC；比如说35是非法Key，如果Tester发送了非法的密钥给ECU，ECU就会回复35NRC；36是尝试次数超限，比如说这是要看具体的诊断规范定义，有的定义请求尝试次数不能超过3次，那么Tester端发送给ECU的Key连续3次错误的时候，ECU就会回复36NRC；37指延时还没有到，因为在有的诊断规范里定义请求的尝试次数达到最大值的时候，ECU会锁定一段的时间，在这个时间之内，你的Tester端是不能够再次请求种子的，所以在这个时间之内，比如说有的整车厂用到10秒延时，Tester端再一次发送了请求种子的请求报文给ECU，那么ECU就会回复37NRC的否定响应报文。

下面我们来看通过DID来读取和写入数据，就是22和2E服务

首先来看22服务的请求和响应格式，请求格式“22+两个字节的DID”；它的肯定响应“62+DID+所读取的数据”。这里举出了一个例子，比如说现在的DID是F186来读取当前的诊断会话状态，它的肯定响应格式“62+F186+02”读取当前处于编程会话状态。

在14229-12013版附录C里面列出一些推荐使用的DID和这些DID的功能，大家也可以去看一下这个附录C

22服务支持的NRC。13是请求格式不正确；14读取的数据已经超过了传输的最大值，就是超限了；31我们刚才也已经提到过了，比如说请求的DID不支持，请求的DID在当前会话下不支持；33要求在解锁状态下，而现在没有处于解锁状态执行了响应的请求。

看一下由DID写入数据：2E服务。他的请求格式“2E+2个字节的DID+需要写入的数值”；肯定响应的格式“6E+DID”。这里举出来一个例子，由F190来写入VIN码，写入一个17字节的VIN码，这里简化，就打了省略号。当写入成功后，ECU回复肯定响应“6E+F190”

2E服务支持的NRC。31；3E；33；72和编程有关的，比如说在Bootloader刷写的过程中，需要对Flash进行操作，而写入数据没有写成功的时候，会回复72NRC

下面我们来看和故障存储有关的服务。

什么是故障呢？当系统检测到了一个错误或者是一个故障发生的时候，会将相对应的数值故障码进行存储，那么这个对应的数值故障码，我们称之为故障码，就是DTC。

一个DTC可以反应出一个故障发生的具体位置，和这个故障发生原因和类型，我们通过读取的DTC信息，可以为维修提供一些依据。除此以外还有与法律有关的故障，比如说排放有关的，在未来还会有安全相关的故障

通过这个故障可以反应出在ECU具体的哪一个位置，和产生的故障类型，在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成，而ISO15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。那么我们常用的UDS服务里面DTC格式用的是哪一种呢？有95%用到的DTC格式都是ISO15031-6里定义的DTC的故障类型和格式

ISO15031-6定义的DTC格式什么样的呢？

两个字节的根字节来定义DTC，

左边前两位能反应DTC到底是哪一个系统：

00表示Powertrain;

01表示底盘；

10表示车身；

11是网络相关的。

左边第3~4位反应的是，DTC到底是由ISO，SAE，这些标准组织所定义的故障，还是由整车厂来定义命名的故障；

左边第5~8反应的是车辆系统的区域；

右边8位，这个字节具体的编码，就是DTC的编码。

在14229-1中定义的19服务读取DTC信息里，定义28个Subfunction，根据不同的Subfunction来获取不同的诊断信息，在这里我们介绍4个不同的Subfunction，这4个Subfunction也是在规范中常用的，他们分别是02；04；06；0A。

刚才我们提到了DTC状态字节，这个DTC状态由8个位组成的一个字节。这8个位分别代表不同的含义，具体这8个位代表的含义，包括这8个位初始值是什么，它什么时候被置1，什么时候又被清0，它在什么情况下用，怎样用，在14229-12013版附录D有详细的定义。大家如果想具体了解这8个位的定义，可以参看附录D。

这里要提醒大家的是除了Bit4和Bit6以外，其它所有位的初始值都应该为0，而Bit4和Bit6的初始值位1。

常用的有比如说Bit0和Bit3.

Bit0当检测到这个故障，发生错误的时候被置1；

Bit3ConfirmedDTC根据具体DTC的应用逻辑，这个DTC被检测到了多次，这个次数由具体的ECU规范定义，那么这一位也应该被置1。

我们通过1902读取DTC的时候，会用到3个不同类型的DTCStatus，那么这3个不同的DTC有什么区别呢：

我们来看具体的请求和响应格式，首先看1902。1902后面跟一个字节的StatusMask，第0位和第3位被置1，而这一个字节Mask，是在ECU诊断规范定义的，所以5902+一个字节的Mask+具体的DTC+DTC后面的跟的DTCStatus。

如果有多个DTC，后面会重复DTC的格式：3个字节的DTC+DTCStatus。

通过190A读取ECU支持的所有DTC，请求格式是两个字节“19+0A”；肯定响应格式“59+0A+一个字节的Mask+后面跟ECU支持的所有DTC”

当诊断故障信息被存储了以后，我还需要，问题我们已经通过维修的方式解决了，我们用什么样的方法将这个DTC清除呢？

用到14服务清除诊断信息，14服务格式很简单，请求格式是“14+3个字节数值”，这3个字节的数值可以是针对单个DTC清除，也可以是按组来清除DTC，也可以是清除全部DTC。当3个字节都为FF时，表示将ECU里产生的所有DTC清除。

那我能不能按照组来清除DTC，比如说清除和车身有关的DTC，就按照车身这个组的数值，将它添加到请求报文格式里；

那我能不能单独清除，只针对某一个DTC，清除这个DTC，也是可以的。只需将这个DTC的具体数值放在请求报文，那么的肯定响应格式是一个字节54。

这个表格在14229中也有描述，大家可以具体参看。