车载测试项目 UDS诊断 ISO14229协议

每日直播时间：
周一到周五：20：00-23：00
周六与周日：9：00-17：00

直播内容：（车厂一比一测试）

HIL（硬件在环）测试、UDS功能诊断、UDS自动化诊断、数据库制作、DTC故障制造、CANoe工具使用、ECU刷写、报文解析、导航测试、车控测试、OTA升级测试、TBOX测试等

UDS诊断相关的知识点

 

文章目录

             一、背景
             二、概述
             三、诊断原理
             四、UDS诊断服务
             五、DTC

一、背景

        汽车故障诊断是利用ECU监测控制系统各组成部分的工作情况，发现故障后自动启动故障记录和处理逻辑。汽车故障诊断模块不仅能够存储记忆汽车故障，还能够实时提供汽车各种运行参数。外部诊断设备通过一定的诊断通信规则与ECU建立诊断通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。

二、概述

        统一诊断服务（Unified Diagnostic Services），简称UDS。是ISO 15765和ISO 14229定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN、LIN、Flexray、Internet、K-line）上实现，是当前汽车领域广泛使用的一种车载诊断协议标准。

        UDS协议应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。

三、诊断原理

        根据UDS的诊断协议，汽车上的控制系统需要根据规则化的诊断协议进行故障记录和处理，最终体现为诊断故障代码（Diagnostic Trouble Code，DTC）的方式。例如，网络通信丢失的故障诊断机制：

        自动变速箱控制单元（Transmission Control Unit，TCU）和制动防抱死系统（Antilock Brake System，ABS）是CAN车载网络上的两大电子控制单元，这2个ECU要通过CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电子控制单元本身控制策略引起的通信停止等原因，2个电子控制单元之间可能会出现通信丢失的现象。

        控制系统需要将故障信息（例如：通信丢失故障信息）诊断出来，以处理通信被破坏时出现丢失帧的故障现象，并记录为DTC。一旦某一控制系统，如TCU监测到一段规定的时间内并没有接收到ABS发来的通信数据，便将此DTC记录下来。外部诊断设备通过规则的诊断通信与控制系统建立诊断通信连接，并选择相应的诊断方式。例如：读取故障信息服务时，就会将此故障信息读出，并在诊断仪中显示出来。

四、UDS诊断服务

SID ：诊断服务标识符（Service Identifier）。

DID：数据标识符（Data Identifier）。

SF：子功能（Sub-Function）。

NRC：否定响应码，如ECU拒绝了一个请求，会回应一个NRC，不同的NRC有不同的含义。

SA：源地址（Source Address ）。

TA：目标地址（Target Address）。

Tester：测试仪，比如周立功、CANoe、创芯科技等。
 

UDS一般有两种寻址模式：

物理寻址 Physical  Addressing	是一种点对点的寻址模式，一条报文对应于单独一个Server（ECU）。
功能寻址 Functional  Addressing	一条报文对应本网络中所有Server（ECU），也就是说本网络中所有ECU都要对这条指令做出响应。

        UDS本质上是一种定向的通信，是一种交互协议（Request/Response），采用的是Client/Server的模式，基本是Client发送一个请求报文，Server根据请求报文做出回应，Client一般情况下是指测试仪（Tester），Server一般是指电控单元（ECU）。UDS每种服务都有自己独立的ID，即SID，UDS请求报文中需要包含SID，有UDS报文和响应如下：

 

根据功能和处理目的被分类为不同的功能单元：

诊断和通信管理功能单元（Diagnostic and Communication Management）

$10 - 诊断会话控制（DiagnosticSessionControl）

        该服务请求ECU从活动会话过渡到其他会话。
包含三个子功能：01 - Default、02 - Programming、03 - Extended。

$11 - 电控单元复位（ECUReset）

        该服务请求ECU执行复位。
ECUReset请求参数的示例包括：hardReset、keyOffOnReset、softReset。

$27 - 安全访问（SecurityAccess）

        此服务用于在活动诊断会话中达到更高的安全级别。可能需要SecurityAccess请求来解锁并访问受保护的功能及数据（例如通过DID读取ECU ID信息）。也可以用于从一个会话通过解锁以成功切换到其他会话。

        例子：

        Rx：02 27 05 00 00 00 00 00，安全访问，05子功能。

        Tx：07 67 05 08 27 11 F0 77，肯定响应，回复了对应安全级别的种子。

        Rx：06 27 06 FF FF FF FF 00，发送密钥，4个FF。注意06是与05成对使用的。

        Tx：03 7F 27 78 00 00 00 00，否定响应，7F+27+NRC。

        Tx：02 67 06 00 00 00 00 00，肯定响应，通过安全校验。

$28 - 通讯控制（CommunicationControl）

        该服务请求ECU控制其通信行为。
一个典型示例包括要求CAN总线中的ECU关闭车载通信，以提高诊断通信的效率。

$3E - 待机握手（TesterPresent）

        TesterPresent请求通常定期发送，并包含一个功能地址。它指示测试仪仍处于连接状态（存在），并请求ECU保持当前诊断状态（例如，除默认会话之外的其他会话处于活动状态，RoE机制仍处于活动状态）。对这个服务的正响应抑制可以减少总线负载。

        例子：02 3E 80 00 00 00 00 00，发送一个3E服务的报文，保持非默认会话状态，80表示无需回复。

$83 - 访问时间参数（AccessTimingParameter）

        该请求用于读取和/或修改通信定时参数。

$84 - 安全数据传输（SecuredDataTransmission）

        此请求用于传输受加密方法保护的诊断数据。
为此，必须实现位于应用程序层与测试仪和ECU的应用程序之间的“安全子层”。数据根据ISO 15764（扩展数据链接安全性）进行处理。

$85 - 诊断故障码设置控制（ControlDTCSetting）

        该服务要求ECU停止/恢复DTC的设置。将此服务与车载通信切换 （服务$28通讯控制）相结合，可增加用于Flash编程的速度。

$86 - 事件响应（ResponseOnEvent）

        事件响应（RoE）服务请求ECU自动传输指定事件的响应。

$87 - 链路控制（LinkControl）

        该服务请求控制通信数据速率。对于CAN，它会影响ISO 11898中规定的数据链路层，从而影响用于板载通信以及诊断通信的数据速率。转换数据速率的请求分为：验证网络上的ECU是否允许特定的数据速率，在验证结果为肯定的情况下请求转换，执行转换。

数据传输功能单元（Data Transmission）

$22 - 通过ID读数据（ReadDataByldentifier）

        该服务请求读取由DID参数标识的数据记录值。DID用于标识特定的本地数据记录。数据标识符0xF224可以包含诸如电池电压，歧管绝对压力，空气质量流量，车辆大气压以及计算出的负载值之类的数据。

$23 - 通过地址读内存（ReadMemoryByAddress）

        该服务请求读取指定内存范围的当前值。请求参数是内存地址和内存大小。用于请求参数的字节数在addressAndLengthFormatldentifier中指定。

$24 - 通过ID读比例数据（ReadScalingDataByidentifier）

        该服务请求ECU将缩放信息值传输到测试仪。测试人员使用定标信息值来转换数据。这项服务的实施增加了ECU软件的实用性。作为替代，测试器可以将缩放比例信息存储在数据库中。

$2A - 通过周期ID读取数据（ReadDataUyPeriodicidentifier）

        该服务请求定期发送数据记录值。所请求的数据的传输速率由传输模式参数设置，例如“中等速率发送”，例如300 ms。

$2C - 动态定义标识符（DynamicallyDefineDataldentifier）

        该服务允许测试人员在ECU中动态定义新的数据标识符，其中包含对静态定义的标识符和/或内存地址的引用。测试人员随后可以通过服务请求2A（readDataByPeriodicIdentifier）读取此动态定义的数据记录。动态定义的标识符的一个优点是， 一次服务可以请求传输很多的的数据记录。

$2E - 通过ID写数据（WriteDataByldentifier）

        通过此服务，可以将由标识符（DID）指定的数据记录写入ECU存储器。

$3D - 通过地址写内存（WriteMemoryByAddress）

        该服务允许将数据记录直接写入ECU的内存。请求参数是内存地址和内存大小以及数据记录。用于参数内存地址和内存大小的字节数在addressAndLengthFormatidentifier中指定。

存储数据传输功能单元（Stored Data Transmission）

$14 - 清除诊断信息（ClearDiagnosticInformation）

        清除（复位）DTC格式，它可以改变DTC的状态。此服务允许在一个或多个ECU中清除错误存储器的内容。因此，可以使用物理地址或功能地址来请求服务。3个FF代表清除所有DTC。例如：

        请求：14 + FF + FF + FF；

        响应：54 。

$19 - 读取故障码信息（ReadDTCInformation）

        诊断故障代码（DTC）用于编码和识别检测到的与排放有关和与排放无关的故障。DTC通常为三个字节，OBD II占用两个字节。该服务从一个或多个ECU请求DTC信息的状态。因此，该服务可以用物理地址或功能地址查询。测试人员可以请求与DTC关联的已存储数据记录，也称为“DTC快照”。DTC快照包含故障发生时的特定数据值。

输入输出控制功能单元（Input & Output Control）

$2F - 通过标识符控制输入输出（InputOutputControlByIdentifier）

        该服务主要用于代替输入信号的值和/或控制ECU的输出。通常，此服务会绕过ECU的应用程序软件并直接触发输出电路，然后直接读取连接到输入电路的传感器。

例行程序功能单元（Remote Activation of Routine）

$31 - 例行程序控制（RoutineControl）

        该服务用于维护和停止ECU内部例行程序。可以读取例程的结果以进行分析。该例行程序由两个字节的例行程序identifier标识。

上传下载功能单元（Upload & Download）

$34 - 请求下载（RequestDownload）

        此服务启动从测试仪到ECU的数据传输。当ECU准备从测试仪接收数据时，它会发送肯定响应，其中包含用于后续数据传输的可用块大小（每个传输数据请求的数据字节数）

$35 - 请求上传（RequestUpload）

        此服务启动从ECU到测试仪的数据传输。当ECU准备好将数据发送到测试仪时，它会发送一个肯定的响应，其中包含用于后续数据传输的块大小（每个传输数据请求的数据字节数）

$36 - 数据传输（TransferData）

        此服务用于在测试仪和ECU之间（下载）或在ECU和测试仪之间（向上）传输数据。如果需要一个以上的transferData请求来传输数据，则使用blockSequenceCounter对传输次数进行计数。计数器允许在传输损坏后重复传输块。因此，在出现通信问题时，不必再次传输完整的数据

$37 - 请求退出传输（RequestTransferExit）

        该服务用于终止transferData服务。完整的数据传输从requestDownloadrequestUpload服务开始，再由几个transferData服务继续，并由requestTransferExit服务完成。

$38 - 请求文件传输（RequestFileTransfer）

        该服务用于终止transferData服务。完整的数据传输从requestDownloadrequestUpload服务开始，再由几个transferData服务继续，并由requestTransferExit服务完成。

五、DTC

      诊断故障码（Diagnostic Trouble Code，DTC），是故障类型的"身份ID"，用于汽车故障时对故障部位及原因的排查。一个DTC信息占用4个字节：

        每个DTC均由DTC内容和DTC状态表示：

DTC内容。代表了该故障的具体故障方式、故障标志等信息。其中，DTCHighByte、DTCMiddleByte这两个字节表示故障内码，对应5位标准故障码（第一位是字母，后面四位是数字），如"B100016"这个故障码中的"B1000"，最后面的"16"则是DTCLowByte的内容（DTCLowByte是描述故障种类和子类型，该部分内容遵循ISO 15031-6，对于不需要该字节信息的DTC，可填充为0x00）。

故障内码与5位标准故障码的位置对应关系如下：

1、第一位

2、第二位

3、第三位是数字，表示故障所属的子系统，以对动力系统为例（P开头的故障码），有以下的情况：

        0 - 表示燃油和空气计量辅助排放控制整个系统。

        1 - 表示燃油和空气计量系统。

        2 - 表示燃油和空气计量系统（喷油器）。

        3 - 表示点火系统。

        4 - 表示废气控制系统。

        5 - 表示巡航、怠速控制系统。

        6 - 车载电脑和输出信号。

        7 - 传动系统控制。

        8 - 传动系统控制。

4、第四、五位也是数字，表示具体故障对象和类型。

故障码的16进制表示：

        根据前面介绍的故障内码与5位标准故障码的对应关系，我们可以将标准故障码换算成其16进制的表示，便于我们在代码中的记录操作。

        关于标准故障码换算为16进制表示，其实只需根据第一小节中介绍的故障内码与5位标准故障码的对应关系，将标准故障码的第一、第二位（如下例中的“U0”、“B1”）换算为对应的内码格式，再以16进制表示出来，至于后面的其他内容，其格式本来就是16进制进行表示的，直接照着写下来即可（其实只是将标准故障码的第一、二位进行转换即可了）。例如：

U007304，其故障内码为：1100 0000 0111 0011，换算成16进制则为C073，补充上DTCLowByte（04），则其完整的16进制表示为0xC07304。

B100016，其故障内码为：1001 0000 0000 0000，换算成16进制则为9000，补充上DTCLowByte（16），则其完整的16进制表示为0x900016。

DTC状态。则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的故障状态信息。

位	功能
Bit 0	testFailed
Bit 1	testFailedThisOperationCycle
Bit 2	pendingDTC
Bit 3	confirmedDTC
Bit 4	testNotCompletedSinceLastClear
Bit 5	testFailedSinceLastClear
Bit 6	testNotCompletedThisOperationCycle
Bit 7	warninglndicatorRequested

Bit 0：testFailed

        通常来说，ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态位就要被置1，表示出错。此时DTC的testFailed位被置1，但是它不一定被ECU存储到non-volatile memory中，只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置为0。

Bit 1：testFailedThisOperationCycle

        这个bit用于标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，即是否出现过错误。operation cycle的起始点是：ECU通过网络管理唤醒，到ECU通过网络管理进入睡眠。对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过，比如，当前testFailed=0， 说明当前这个DTC没有出错，如果testFailedThisOperationCycle=1的话，就说明这个DTC在当前这个operation cycle中出过错，但是当前错误又消失了。

Bit 2：pendingDTC

        根据规范的解释，pendingDTC=1表示某个DTC在当前或者上一个operation cycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个operation cycle中出现才可以被判定为confirmed的状态，此时就需要借助于pendingDTC位了。pendingDTC=1的时候，DTC就要被存储下来了，如果接下来的两个operation cycle中这个DTC都还存在，那么confirmedDTC就要置1了。如果当前operation cycle中，故障发生，pendingDTC=1，但是在下一个operation cycle中，故障没有了，pendingDTC仍然为 1，再下一个operation cycle中，故障仍然不存在，那么pendingDTC就可以置0了。

Bit 3：confirmedDTC

        当confirmedDTC=1时，则说明某个DTC已经被存储到ECU的non-volatile memory中，说明这个DTC曾经满足了被confirmed的条件。但是请注意，confirmedDTC=1时，并不意味着当前这个DTC仍然出错，如果confirmedDTC=1，但testFailed=0，则说明这个DTC表示的故障目前已经消失了。将confirmedDTC重新置0的方法只有删除DTC，UDS用0x14服务，OBD用0x04服务。

Bit 4：testNotCompletedSinceLastClear

        这个bit用于标识，自从上次调用了清理DTC的服务（UDS用0x14服务，OBD用0x04服务）之后，是否成功地执行了对某个DTC的测试（不管测试结果是什么，只关心是否测了）。因为很多DTC的测试也是需要满足某些边界条件的，并不是ECU上电就一定会对DTC进行检测。

testNotCompletedSinceLastClear=1，自从清理DTC之后还没有完成过针对该DTC的测试。

testNotCompletedSinceLastClear=0，自从清理DTC之后已经完成过针对该DTC的测试。

Bit 5：testFailedSinceLastClear

        这个位与bit1有些类似，bit1标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，而testFailedSinceLastClear标识的是在上次执行过清理DTC之后某个DTC是否出过错。

testFailedSinceLastClear=0，自从清理DTC之后该DTC没有出过错。

testFailedSinceLastClear=1，自从清理DTC之后该DTC出过至少一次错。

Bit 6：testNotCompletedThisOperationCycle

        这个位与bit4类似，b4标识自从上次调用了清理DTC的服务之后，是否成功地执行了对某个DTC的测试。而testNotCompletedThisOperationCycle则标识在当前operation cycle中是否成功地执行了对某个DTC的测试。

testNotCompletedThisOperationCycle=1，在当前operation cycle中还没在完成过针对该DTC的测试。

testNotCompletedThisOperationCycle=0，在当前operation cycle中已经完成过针对该DTC的测试。

Bit 7：warningIndicatorRequested

        某些比较严重的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯，或者是文字，或者是声音。这个warningIndicatorRequested就用于此类DTC。

warningIndicatorRequested=1， ECU请求激活警告指示。

warningIndicatorRequested=0，ECU不请求激活警告指示。

        注意，如果这个DTC不支持警告指示，则这个位永远置0。