UDS诊断概述

UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通讯协议。简单来说，可以理解为UDS诊断协议就是ISO 14229协议，在ISO 14229协议中定义了UDS服务用法、服务格式等信息。UDS诊断最主要目的是为了能够快速准确判断车辆或者某个控制器的故障以及故障原因，从而为维修提供可靠的依据。

诊断服务概览

UDS诊断包括6大类，26种服务，每种服务都有自己独立的ID，即SID（Service Identifier）

常见NRC码

什么是NRC？一句话总结，NRC码用来快速判断故障原因的重要依据。

不同会话支持的服务

并不是所有服务都只在一个会话下活动，由此就有了会话优先级的概念，下图列出了不同会话下支持的服务列表。

寻址方式

UDS诊断服务是实现人或设备与ECU控制器交流的一种语言，在总线上往往有着众多ECU设备，作为诊断设备既可以与所有的ECU一起沟通，也可以指定某一个ECU单独沟通。所以寻址方式就有功能寻址（Functionally Addressed）和物理寻址（Physically Addressed）两种。

1、功能寻址：即广播诊断请求Request，同时等待总线上的ECU给与响应。

2、物理寻址：指定发送特定诊断请求Request，等待指定ECU给与响应。

$10会话控制

DiagnosticSessionControl（诊断会话控制）服务用于启用服务器中的不同诊断会话。该服务是在服务器端使能不同的会话模式，可以通过会话模式赋予不同诊断服务的执行权限。

请求格式：

响应格式：

支持的NRC：

$3E会话保持

3E服务用于会话模式一直保持在非默认会话，不会因为3E时间超时而自动掉到默认会话。

请求格式：

响应格式：

支持的NRC：

$11ECU复位

此服务主要基于请求消息中复位类型执行ECU复位。在ECU执行复位之前，ECU需回复肯定响应消息，才可复位成功，在ECU成功复位后，ECU应激活默认会话。

常用的复位类型，即子功能：

11 01 硬复位，即模拟的状态为电源断开再重新接上的复位。

11 02 Keyoffon复位，模拟的是驾驶员先关闭点火开关再打开类型的复位。

11 03 软复位，模拟的是软件请求的复位，如软件内部出现非预期执行时触发的Reset。

请求格式：

响应格式：

支持的NRC：

$14清除DTC

此服务它可以改变DTC的状态。DTC状态中的八个位，除bit4和bit6外均会被清零，包含当前故障（TestFailed）和历史故障(ConfirmedDTC）。bit4和bit6这两个testNotCompleted开头的会被强制置1。

示例：14 FF FF FF(清除所有DTC) ,此参数包含3个字节的值，表示要清除的DTC组(例如动力总成，车身，底盘)或特定的DTC。

请求格式：

响应格式：

支持的NRC：

$19 读取DTC

19服务是UDS里的重中之重了，可谓是没有19服务就失去了诊断服务的意义，下面就详细介绍下此服务的作用以及用法。

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。

19 01 读取DTC数量

通过状态掩码去查找与其相匹配的故障个数，通过该服务诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。如果某一个故障码的实际状态位为1，并且DTC状态掩码中的相应位也为1，那么就认为该故障码的状态与DTC状态掩码相匹（即：如果DTC状态掩码字节与DTC实际状态字节进行逻辑“位与”运算后的结果为非零值，那么两者就相匹配）；此时则将故障数+1。如果诊断仪定义了一个状态掩码，其中包含ECU不支持的位，那么ECU仅使用本身支持的位进行处理故障信息。

请求格式

响应格式：

19 02 读取DTC列表

按照定义的状态掩码的形式去查找匹配的故障：将匹配的DTC标识符（3个字节）、DTC状态（1个字节）信息返回。上一小节的01子服务只统计与状态掩码相匹配的DTC个数，02子服务则会将这些匹配的DTC信息返回。

请求格式：

响应格式：

19 03 读取DTC快照信息

请求格式：

响应格式：

19 04 读取指定DTC快照信息

为了方便找到故障的原因，车厂一般会在诊断调查表中定义一些信息作为快照信息，例如故障的发生时间、电压、行驶里程数、车速等。在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。

请求格式：

响应格式：

上图：响应报文中DTCSnapshotRecordNumber表示返回的是该DTC的哪一个快照记录；DTCSnapshotRecordNumberOfIdentifiers表示快照信息中定义的成员量；如定义的快照数据有车速、电压、转速、里程这四项信息；

19 06读取扩展数据信息

除了前面04服务的快照信息；一般还会再定义一个扩展信息，用于记录故障的一些其他信息，比如故障发生的次数、老化次数、已老化次数等。而将下来介绍的06服务就是用于请求指定故障码（DTC）的扩展信息。

请求格式：

响应格式：

19 0A 读取所有DTC信息

请求所有支持的DTC信息（3字节的DTC标识符+1字节的DTC状态位），其响应报文与02服务一致；但要区分，该服务返回的是所有DTC的信息；而02服务是返回与请求时状态掩码相与不为0 的DTC信息。

请求格式：

响应格式：

支持的NRC：

$85控制DTC设置

此服务用于在诊断刷写的过程中关闭DTC记录，因为在刷写的过程中往往是针对某个ECU节点单独进行刷写，其他的对手件ECU节点始终处于正常工作状态，那么此时应当发送功能寻址给到各ECU节点使得其停止记录DTC，刷写完成之后再重新开启对手件DTC记录功能即可。

常用子功能

85 01：继续更新状态码状态位。

85 02：停止更新状态码状态位。

请求格式

响应格式：

支持的NRC:

$19服务故障状态掩码位定义

该mask由主机厂提供：

#主要第0位和第三位用的比较多，所以一般故障掩码的值为0x09

bit 0 testFailed：

指示最近执行test的结果，test失败置1，但是它不一定被ECU存储到EEprom中，只有当bit2或bit3被置1时DTC才会被存储。test通过则置0，如果调用了14服务清除DTC的话，也需要重新置0

“0”= DTC测试的最新结果表明未检测到故障。

“1”= DTC测试的最新结果表明了一个成熟的失败结果。

—————————————————————————————

bit 1 testFailedThisOperationCycle ：

该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时，这个位需要置0，在调用了14服务后也需要置0。如果该位置1，那么一直保持置1状态直到新的检测循环开始，因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。对于没有网络管理的 ECU，这个起始点就是 KL15 通断。也就是说上电时间内出现的故障，该位都会置1，不管是否存储。

“0”= testFailed:在当前操作周期内或在当前操作周期内调用ClearDiagnosticInformation后，尚未报告testFailed结果。

“1”= testFailed:在当前操作周期中至少报告了一次testFailed结果。

—————————————————————————————

bit 2 pendingDTC ：

根据ISO 14229的定义，当一个test结束时，若某个DTC满足故障触发条件，则bit2置1。bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态，称为待定DTC。因为DTC并不是一达到触发位就会被报出来的，而是故障出现一段时间后才会被确认，而中间的这个状态就用bit2位来表示，因此bit2位又可被称为待定DTC。当某个DTC刚达到判定条件的时候，bit2被置1，若一段时间后故障条件不满足了，则bit2置0，若一段时间后故障仍然存在，那么bit3就要置1了。

“0”= 在完成测试完成且未检测到故障的操作循环后或调用ClearDiagnosticInformation服务时，该位应设置为0。

“1”= 如果在当前操作循环中检测到故障，则该位应设置为1并锁定。

—————————————————————————————

bit 3 confirmedDTC ：

当bit3置1时，说明故障已经发生了一段时间，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的时候，DTC被存储在EEprom中，但并不代表现在故障还存在，所以可以理解为历史故障。在调用14服务清除DTC后需要置0。

“0”= 自上次调用ClearDiagnosticInformation后，或在满足故障诊断码的老化条件（或由于故障记忆溢出而清除了故障诊断码）后，从未确认过故障诊断码。

“1”= 自上次调用ClearDiagnosticInformation后至少确认一次的DTC，且尚未满足老化标准

—————————————————————————————

bit 4 testNotCompletedSinceLastClear：

因为并不是所有的DTC测试都是从上电就开始的，所以该位用来表示上次调用14服务清除诊断消息后，是否进行过完整的test。如果进行了完整的test，无论结果如何，都置0，否则置1。

“0”= 自上次清除诊断信息以来，DTC测试至少返回一次测试结果（无论通过或失败）。

“1”= 自上次清除诊断信息后，DTC测试尚未运行到完成。

—————————————————————————————

bit 5 testFailedSinceLastClear ：

该位表示在上次调用14服务清除后DTC后，若test DTC未进行测试或者测试了但结果是pass时置0，如果test运行完成并且返回结果为fails，那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。

“0”=自上次清除诊断信息后，DTC测试未显示失败结果。如果满足老化阈值或发生故障记忆溢出，则车辆制造商应负责将该位重置为零（“0”）。

“1”=自上次清除诊断信息以来，DTC测试至少返回一次失败结果。

—————————————————————————————

bit 6 testNotCompletedThisOperationCycle：

该位表示在当前检测循环周期过程中DTC test是否完成，若完成了置0，未完成置1。在调用ClearDiagnosticDTC后需要置1。

“0”= DTC测试在当前驾驶循环期间（或自上次在当前操作循环期间清除诊断信息以来）完成。

“1”= 此操作循环（或自上次清除此操作循环的诊断信息后），DTC测试尚未运行到完成。

—————————————————————————————

bit 7 : warningIndicatorRequested

该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示，如果没有和DTC相关的警告存在，该位应置0；如果该DTC有相关警告指示，bit3置1的时候，bit7也要置1。在调用14服务清除DTC后需要置0

—————————————————————————————

$19拥有28个子服务（Sub-Function）。常用的子服务有：掩码类型：01 (读取符合掩码条件的DTC数量),后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读。

$22读数据

22服务其英文全称：ReadDataByIdentifier Service，为通过DID读取数据的服务，例如，在使用中可以通过22服务去获取软件的版本号，车辆VIN码等信息。在接收到22服务请求后，服务器应访问由DID参数指定的记录的数据元素，并在包含相关数据记录参数的单个DID肯定响应中传输其值。请求消息可以多次包含相同的DID。服务器应将每个DID视为一个单独的参数，并根据要求经常使用每个DID的数据进行响应。22服务为获取对应DID的数据。

请求格式：

响应格式：

支持的NRC:

$27安全访问

安全访问服务，主要功能是为了通过诊断安全地访问服务端，也就是ECU，而设置的一层保护机制。安全访问服务用于修改存储在内存中的 ECU 数据，在此之前，用户首先必须通过该服务授予访问权限。此服务的目的是提供一种访问信息和/或诊断服务的方法，这些服务因安全、排放或安全原因而受到限制。比如一些用于将例程或信息下载/上传到服务器中，并从服务器中读取特定的内存位置的诊断服务可能需要安全访问。因为下载到服务器中的不当程序或信息无疑可能会损害ECU，或危及车辆遵守排放、违反安全或安保标准。安全访问的机制通过使用种子和密钥来实现

使用此服务的典型示例如下∶

1. 客户端首先发送请求种子的诊断请求

2. 服务端收到请求后，计算一个随机种子通过诊断响应发送给客户端

3. 客户端收到种子后，使用定义好的算法计算出密钥，然后通过诊断请求发送给服务端

4. 服务端收到密钥后，与自己计算的密钥作对比，如果一致，验证通过，如果不一致，验证失败

请求格式：

响应格式：

支持的NRC：

$28通信控制

根据ISO14119-1标准中所述，诊断服务28服务主要用于网络中的报文发送与接受，比如控制应用报文的发送与接收，又或是控制网络管理报文的发送与接收。

28服务子功能：

00：enableRxAndTx（使能收发）

01：enableRxAndDisableTx （使能接收并禁止发送）

02：disableRxAndEnableTx （禁止接收并使能发送）

03：disableRxAndTx（禁止收发）

控制类型 （communicationType）：

第3个字节为控制类型，01所有应用报文， 02 所有网络管理报文， 03 都包括。

举例：禁止收发所有报文 28 03 03 总线上所有报文停止通讯

请求格式：

响应格式：

支持的NRC

$2E写数据

请求格式：SID+DID+DATA

响应格式：6E+发送请求的DID+写入的DATA

请求格式：

响应格式：

支持的NRC：

$31例程控制

客户端端使用31服务来执行定义的步骤序列并获取特定序列的相关结果。该服务有极大的灵活性。31服务的典型用途可以包括擦除内存、重置定义的数据、覆盖正常服务控制策略以及控制ECU值随时间变化的功能。通过31服务可以启动特定序列、停止运行该特定序列、请求运行结果。该服务以往常用于ECU在做软件修改更新时，应用于检查刷写条件是否满足、传输数据完整性以及独立性检测。

31服务子功能：

Service 31 01：开始执行例程。

Service 31 03：请求例程结果。

Service 31 02：停止运行例程。

这里注意请求顺序，否则就NRC=24了

请求格式：

响应格式：

—————————————————————————————

总结:

本文主要基于14229协议介绍UDS常用诊断服务，服务子功能及对应服务支持的NRC码。诊断服务的内容实在太多，挑选了重要部分进行总结。

————————————————

版权声明：本文为CSDN博主「赞哥哥.」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明，已获作者转载许可。