UDS简介

UDS的定义

​ UDS协议即ISO-14229，是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准。与OBD最大的区别就是UDS是面向整车所有ECU(电控单元)的，而OBD是面向排放系统ECU的。UDS诊断最主要目的是为了能够快速准确判断车辆或者某个控制器的故障以及故障原因，从而为维修提供可靠的依据。

车载诊断的通用协议，包含不同的子类文件。不同的子类文件应用于车载不同总线通信介质：

从最低端物理层到最上端应用层对应不同的总线协议（其中占有主导地位的车载总线CAN、由于ADAS的兴起，车载以太网的引入到车载网络最为火热），从如上截图可以看出UDS协议也给新的车载总线做了预留，这样充分保证了该协议的灵活性。

常用的诊断服务

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

UDS诊断服务可以分为6大类：

• 诊断和通信管理功能单元；
• 数据传输功能单元；
• 存储的数据传输功能单元；
• 输入输出控制功能单元；
• 例程功能单元；
• 上传下载功能单元。

除了诊断和通信管理单元内的服务（如0x10会话控制服务， 0x3E会话保持服务）以外，最为常用的诊断服务基本就是数据传输功能单元中的服务（如0x22 读DID， 0x2E写DID）和存储数据传输单元中的服务（0x19 读DTC，0x14清DTC）。下面就简单介绍一下这几种常用的诊断服务。

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

$10 - 会话控制服务（DiagnosticSessionControl）和0x3E - 会话保持服务

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

该服务用于控制ECU在不同的会话模式之间切换，默认ECU处在子服务号为01的DefaultSession，很多服务需要切换到03 ExtendedSession中才能执行，当需要进行软件刷写时，则需要切换到02 ProgrammingSession。这三种模式的切换方式如下图：

当ECU处于非DefaultSession时，如果一段时间没有诊断操作，将会退回到DefaultSession，这时候如果想要保持在非DefaultSession，可以通过0x3E会话保持服务，则ECU就会保持在当前的Session下。

1、若ECU当前处于默认会话模式，Client发送10 01，ECU会重置所有激活/启动/更改的在激活会话期间的设置/控制；

2、不同会话模式可以任意切换；

3、ECU为了自身安全，不允许长期处于非默认会话模式。在一定时间内（S3），若ECU没有收到任何诊断请求，会强制要求ECU从非默认会话模式，跳转到默认会话模式；

4、在S3时间内，若无需求发送诊断请求，但是还想要求ECU处于非默认会话模式，可以周期性发送Service3E（TesterPresent），让ECU保持当前非默认会话模式。

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

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

此服务主要基于请求消息中复位类型执行ECU复位。在ECU执行复位之前，ECU需回复肯定响应消息，才可复位成功，在ECU成功复位后，ECU应激活默认会话。
常用的复位类型，即子功能：
11 01 硬复位，即模拟的状态为电源断开再重新接上的复位。
11 02 Keyoffon复位，模拟的是驾驶员先关闭点火开关再打开类型的复位。
11 03 软复位，模拟的是软件请求的复位，如软件内部出现非预期执行时触发的Reset。

$27 - 安全访问（SecurityAccess）

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

为了提高安全性，对于某些服务可能会需要进行安全验证，即解锁。如对于有些DID的读或者写，在执行操作之前会需要先解锁，这时候就需要执行0x27服务。0x27服务是由一对子服务构成的，诊断仪向ECU请求seed和诊断仪向ECU发送key。Seed和Key一般会有一个算法，每个Seed对应唯一的一个Key，一般是在产线上注入，在诊断仪向ECU请求Seed后，ECU会返回一个Seed给诊断仪，诊断仪需要再发送对应的Key到ECU，ECU校验Key正确后解锁，诊断仪才能进行后续的操作。

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

1. 客户端首先发送请求种子的诊断请求；
2. 服务端收到请求后，计算一个随机种子通过诊断响应发送给客户端；
3. 客户端收到种子后，使用定义好的算法计算出密钥，然后通过诊断请求发送给服务端；
4. 服务端收到密钥后，与自己计算的密钥作对比，如果一致，验证通过，如果不一致，验证失败。

$28 - 通讯控制（CommunicationControl）

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

根据ISO14119-1标准中所述，诊断服务28服务主要用于网络中的报文发送与接受，比如控制
应用报文的发送与接收，又或是控制网络管理报文的发送与接收。
28服务子功能：
00：enableRxAndTx（使能收发）
01：enableRxAndDisableTx （使能接收并禁止发送）
02：disableRxAndEnableTx （禁止接收并使能发送）
03：disableRxAndTx（禁止收发）

控制类型(communicationType) :

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

$3E - 待机握手（TesterPresent）

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

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

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

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

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

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

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

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

$86 - 事件响应（ResponseOnEvent）

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

$87 - 链路控制（LinkControl）

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

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

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

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

DID是数据ID，通过0x22服务，根据两个字节的ID，可以读出数据。根据request中给出的DID，一次0x22服务可以读取一个或多个DID的值。0x2E服务一般和0x22服务成对出现，用来通过数据ID对数据进行写操作。当然也有的DID是只读的，那么在进行诊断数据库配置的时候就要屏蔽对应的写服务。关于读写服务，还有其他多种，如0x23根据地址读内存信息，0x3D根据地址写内存信息等。

$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快照包含故障发生时的特定数据值。

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）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。

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

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

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

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

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

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

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

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

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

上传下载功能单元（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服务完成。

NRC 否定响应码：

寻址方式

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

功能寻址：

即广播诊断请求Request，同时等待总线上的ECU给与响应。

物理寻址：

指定发送特定诊断请求Request，等待指定ECU给与响应。

Request 和 response 的基本格式

一个完整的诊断服务包括request和response，有些诊断服务还包含一些子服务，即sub-function。诊断 在client向Server发送诊断请求后，server会检查一系列的条件，如果条件不满足，会回复相应的消极响应码（Negative Response Code NRC），用来指示请求失败的原因，此时的回复称为否定回复(Negative Response)。如果所检查的条件都满足了，但是在一个预定的时间间隔内服务还未处理完，可以设置回复一个NRC 0x78的响应，即response pending。服务完成后，会收到一个肯定响应（Positive Response）。

Server端一般的回复流程如下：

Server端对于带子服务的request回复流程如下：

下面几张图分别给出了UDS服务的含子服务的Request, 不含子服务的Request， Positive Response和Negative Response的一般格式。

含子服务的Request的一般格式：

不含子服务的Request的一般格式：

Positive response的一般格式：

Negative response的一般格式：

其中SID是服务的ID号，同一个服务的Positive Response SID = Request SID + 0x40。Negative response 的SID是0x7F。

不同会话支持的服务

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

《AUTOSAR谱系分解(ETAS工具链)》之总目录

《AUTOSAR谱系分解(ETAS工具链)》之总目录