UDSonCAN

一、概述

  UDS全称统一的诊断服务，ISO-14229系列标准。

ISO 14229-1定义了诊断服务，不涉及网络及实现，只有应用层的内容。
ISO 14229-3则定义了UDS在CAN总线上的实现。
  诊断通信的过程从用户角度来看，即诊断仪发送诊断请求(request)，ECU给出诊断响应(response)，而UDS就是为不同的诊断功能请求和响应之间定义了统一的内容和格式，位于OSI模型中的应用层。
CAN（Controller Area Network）现场总线仅仅定义了OSI 7 层网络模型的第 1 层（物理层，见 ISO11898-2 标准）、第 2 层（数据链路层，见 ISO11898-1 标准）。在实际设计中，这两层完全由硬件实现，设计人员无需再为此开发相关软件（ Software）或固件（Firmware）。

UDS在诊断中作用主要体现在以下：

• 在诊断故障码中运用
• 数据传输
• 控制例程
• 上传下载

  诊断通信的过程就是诊断仪和ECU交换数据，前者发的是request，后者发的是response，而UDS最重要的作用就是定义了这些request和response的格式及内容。
  UDS一般有两种寻址模式：

• 物理寻址：点对点的寻址模式，一条报文对应于单独一个Server（ECU）。
• 功能寻址：一条报文对应本网络中所有Server。

1 Request的格式

Request的格式可以分为两类：

图1 Request格式

• Service ID长度固定为1字节，代表了这条诊断命令执行的什么功能
• sub-function长度也为1个字节，通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务

  sub-function严格来说是7bit，因为最高位bit被用于抑制正响应(SPR)，如果这个bit被置1，则ECU不会给出正响应；如果这个bit被置0，则ECU会给出正响应。这样做的目的是可以告诉ECU不要发不必要的response，从而节约通信资源。

• parameter根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容。

2 Response的格式

分为positive和negative两种。

2.1 positive response

  意味着诊断仪发送的诊断请求被执行。

图2 positive response格式

  其中response SID这个字节作为诊断请求的echo，它等于SID+0x40；后面的两个部分则视具体的诊断服务而定。

2.2 negative response

  ECU因为某种原因无法执行诊断仪发过来的诊断请求，原因存在于negative response的报文中。
  格式固定为3个字节，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断服务无法被执行的原因。比如，ECU给出7F 22 13这个negative response，则说明22这个服务因为诊断请求数据长度不对的原因无法执行。

图3 NRC类型

通讯标准

二、诊断服务

类别	SID(0x)	服务
诊断通讯管理功能单元	10 11 27 28 3E 85	诊断会话控制 电控单元复位 安全访问 通信控制 待机握手(测试工具保持连接) 控制诊断故障代码设置
数据传输功能单元	22 23 2A 2C 2E 3D	根据标识符读取数据 读取内存 读取数据（周期标识符） 动态定义数据标识符 根据标识符写入数据 写入内存
存储数据传输功能单元	14 19	清除诊断信息 读取诊断故障代码信息
输入/输出控制功能单元	2F	根据标识符输入输出控制
远程激活程序功能单元 （例行程序功能单元）	31	例程控制
上传下载功能单元	34 36 37 38	请求下载 数据传输 请求退出传输 请求文件传输

10h服务

  诊断会话控制服务用于在ECU所支持的诊断会话中转换会话模式，常用的sub-function有：

• 0x01：默认会话，ECU上电之后，默认状态

• 0x02：编程会话，这个session中可以进行软件刷写的一系列诊断服务

• 0x03：拓展会话，在这个session中可执行较多的诊断服务

不同会话不能随意切换，转换流程如下图：

27h服务

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

  该服务在默认会话中不可用。

  安全访问是为车辆安全设计的，允许诊断设备访问ECU内部的重要数据或请求ECU执行影响车辆安全的诊断服务的授权方式。
  安全访问是通过种子-密钥（Seed-Key） 的方式实现的，未经过安全访问解锁时。ECU处于锁定状态，不允许访问重要数据（DID）/存储区域和执行某些影响车辆安全的诊断服务。需要通过安全访问的方式解锁ECU，来允许上述操作的执行。

解锁ECU需要执行如下操作：

• 诊断设备通过UDS的安全访问服务(27服务)向ECU请求种子；
• ECU通过诊断响应，提供随机生成的种子；
• 诊断设备收到种子后，按照事先约定的安全算法，根据种子计算密钥，并将密钥通过27服务发送给ECU；
• ECU收到诊断设备发来的密钥后，与自身根据约定的安全算法计算的密钥进行比对。如果二者一致则通过安全访问，ECU被解锁；不一致则校验失败，ECU仍处于锁定状态。

安全访问算法：一种数字处理的函数，该函数的作用是根据输入数据计算出唯一的输出数据。

28

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

3E(TesterPresent)

  Tester Present请求通常定期发送，并包含一个功能地址，它指示测试仪仍处于连接状态，并请求ECU保持当前诊断状态，对这个服务的正响应抑制可以减少总线负载。

subfunction
0x00	ECU给出response
0x80	ECU不需要给出response

  一般来说主机厂会为该服务定义两个时间参数，一个参数用于规定自己的诊断仪发送0x3E服务的间隔，另一个参数用于定义ECU收不到0x3E服务的timeout时间。

三、诊断服务示例

步骤：

1. 开启ECU
2. 读取ECU识别码
3. 切换到programming会话层
4. 安全访问
5. 烧写变体编码
6. 编写变成日期
7. 重置ECU

四、DTC

  诊断故障码用于汽车故障时对故障部位及原因的排查，一个DTC信息占用4个字节：

4.1 DTC内容

4.2 DTC状态

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

位	功能	说明
Bit 0	TestFailed	通常来说，ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近一次的测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态为就要被置1，表示出错。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置为0.
Bit 1	TestFailedThisOperationCycle	标识该DTC在当前这个operation cycle是否出现过错误。
Bit 2	PendingDTC	表示某个DTC在当前或者上一个operation cycle中是否出现过。pending DTC=1时，DTC被存储。
Bit 3	ConfirmedDTC	当confirmed DTC=1时，说明某个DTC已经被存储到ECU的non-volatile memory中，说明这个DTC曾经满足了confirm条件。
Bit 4	TestNotCompletedSinceLastClear	用于标识自从上次调用了清理DTC的服务后，是否成功执行了对某个DTC的测试。
Bit 5	TestFailedSinceLastClear	标识上次执行过清理DTC之后某个DTC是否出过错。
Bit 6	TestNotCompletedThisOperationCycle	标识在当前operation cycle中是否成功执行了对某个DTC的测试。
Bit 7	WarningIndicatorRequested	ECU是否请求激活警告指示。

【注：】

• testFailed位被置为1，但是它不一定被ECU存储到non-volatile memory中，只有当pending DTC或confirmed DTC被置为1时DTC才会被存储。而pending DTC或confirmed DTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门槛。

• operation cycle的起始点是：ECU通过网络管理唤醒，到ECU通过网络管理进入睡眠。对于没有网络管理的ECU，这个起始点就是KL15通断。

• pendingDTC是位于test failed和confirmed DTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个operation cycle中出现才可以被判定为confirmed的状态，此时就需要借助pending DTC位。

• confirmedDTC=1时，不代表当前这个DTC仍然出错。如果confirmedDTC=1，但是testFailed=0，则说明这个DTC表示的故障目前已经消失了。将confirmedDTC重新置0的方法只有删除DTC（UDS 0x14服务）。

• test not completed since last clear只关心是否执行了测试，不关心测试结果。很多DTC的测试需要满足某些边界条件，并非ECU上电就会对DTC进行检测。

  • testNotCompletedSinceLastClear=1：自从上次清理DTC后还没有完成过针对该DTC的测试；
  • testNotCompletedSinceLastClear=0：自从上次清理DTC后已经完成过针对该DTC的测试。

• 某些比较严重的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯、文字、声音等，warningIndicatorRequested就用于此类DTC。warningIndicatorRequested=1则ECU请求激活警告指示。如果DTC不支持警告指示，则这个位永远置为0。

参考

• UDS诊断入门
• UDS诊断基础简介
• UDS看这篇就够了，吐血整理
• 计算机网络学习 - UDS协议