您的位置: 首页  >  文章  >  计算机网络学习（7）—— UDS协议

计算机网络学习（7）—— UDS协议

分类: 文章 • 2024-06-03 22:31:34

一、背景

        汽车故障诊断是利用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记录下来。外部诊断设备通过规则的诊断通信与控制系统建立诊断通信连接，并选择相应的诊断方式。例如：读取故障信息服务时，就会将此故障信息读出，并在诊断仪中显示出来。

四、DTC

        一个DTC信息占用4个字节：
计算机网络学习（7）—— UDS协议
        每个DTC均由DTC内容和DTC状态表示：

  • DTC内容。代表了该故障的具体故障方式、故障标志等信息，例如车身系统中ABS传感器故障。前两个字节是我们熟知的类似P0047的故障码，LowByte暂不清楚。故障码包括四个大类，PCBU分别代表：
    P：是Powertrain动力系统。
    C：是Chassis底盘系统。
    B：是Body车身系统。
    U：是Network通信系统。
            如：P0101、C1234、B2236等等DTC开头的字母表示被监测到的故障系统：P为动力系统，B为车身系统，C为底盘系统，U为网络或数据通讯传输系统故障码。
            第一个数字是通用码（对所有的车辆制造商），或是制造商专用码。比如：0指一般码，1指制造商专用码。美国通用汽车公司就有帮助你诊断车辆技术状况所特定的数字类型编码。
            第二个数字指出了受影响的故障系统类型，数字从1-7：1为燃油及空气计量系统，2为燃油及空气计量系统（特指喷射系统回路功能不良），3为点火系统或缺缸监测系统，4为辅助排放系统，5为车速控制和怠速控制系统，6为计算机输出线路系统，7为变速箱。 
            最后两位数字指出了系统中出现故障的部件或部位。
  • DTC状态。则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的故障状态信息。

计算机网络学习（7）—— UDS协议
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。

五、UDS诊断服务

  • SID ，诊断服务标识符（Service Identifier）。
  • DID，数据标识符（Data Identifier）。
  • SF，子功能（Sub-Function）。
  • NRC，否定响应码（Negative Response Code），如果ECU拒绝了一个请求，它会回应一个NRC，不同的NRC有不同的含义。
  • SA，源地址（Source Address ）。
  • TA，目标地址（Target Address）。

        UDS每种服务都有自己独立的ID，即SID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID，有UDS报文包含四种类型：

  • SID
  • SID + SF
  • SID + DID（读写用）
  • SID + SF + DID

        如果是肯定的响应（Positive Response），回复：SID + 0x40，就是如果请求为0x10，则响应为0x50，如果请求为0x22，则响应0x62，回复的是一组数据。
        如果是否定的响应（Negative Response），回复：7F + SID + NRC，回复的是一个声明。
        示例：以CAN总线网络举例，帧数据段8个字节，第1字节被网络层占用：

  • 请求：02 10 02 xx xx xx xx xx，02是网络层单帧SF，数据域有2个字节，10是SID，02是子功能。
  • 肯定响应：02 50 02 xx xx xx xx xx，02同上，50 = 10 + 40表示对SID的肯定回复，02是子功能。
  • 否定响应：03 7F 10 22 xx xx xx xx，03同上，7F表示否定响应，10是SID，22是NRC。

计算机网络学习（7）—— UDS协议
计算机网络学习（7）—— UDS协议

  • a - SID是服务标识符的缩写。
  • b - DEF是默认会话层的缩写。ECU上电后会重置为默认会话层。
  • c - RoE是事件响应的简称。在此列中的“x”表示该服务可作为事件响应机制的事件服务。
  • d - Sub-Fct是子功能的缩写。此服务支持子功能，因此支持肯定的响应抑制功能。
  • e - 这些服务如果在默认会话中可能需要安全访问服务才能请求。
  • f - 在默认会话中无法访问（某些数据标识符DID）。需要发出单独的$27（SecurityAccess）来解锁以访问这些数据。

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

  • 诊断和通信管理功能单元（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信息）。也可以用于从一个会话通过解锁以成功切换到其他会话。
    $28 - 通讯控制（CommunicationControl）
            该服务请求ECU控制其通信行为。一个典型的示例包括要求CAN总线中的ECU关闭车载通信，以提高诊断通信的效率。
    $3E - 待机握手（TesterPresent）
            TesterPresent请求通常定期发送，并包含一个功能地址。它指示测试仪仍处于连接状态（存在），并请求ECU保持当前诊断状态（例如，除默认会话之外的其他会话处于活动状态，RoE机制仍处于活动状态）。对这个服务的正响应抑制可以减少总线负载。
    $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服务完成。

相关推荐