UDS诊断基础知识简介-ISO14229

什么是UDS？

UDS全称为Unified Diagnostic Services，统一的诊断服务。由ISO-14229系列标准定义。

诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能请求和响应之间定义了统一的内容和格式。位于OSI模型中的应用层。

作为汽车诊断通信重要构成部分，UDS在诊断中作用主要体现在以下几个方面

1. 在诊断故障码中运用
   读取当前故障，历史故障，读取故障发生时环境信息，清除故障码
2. 数据传输
   读取各种参数，下线配置
3. 控制例程
   下线测试，身份认证，控制器reset等
4. 上传下载
   刷新常用的诊断服务

Diagnostic request的格式：

Diagnostic request的格式可以分为两类：一类是拥有sub-function的，另一类是没有sub-function的，如下面两张图所示。Service ID(以下简称SID)的长度固定为1个字节，代表了这条诊断命令执行的什么功能。sub-function的长度也是1个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。而后面的parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容。

有一点要补充的是，其实sub-function严格来说是7个bit，而不是1个byte，因为它的最高位bit被用于抑制正响应（suppress positive response,SPR），如果这个bit被置1，则ECU不会给出正响应（positive response）； 如果这个bit被置0，则ECU会给出正响应。这样做的目的是可以告诉ECU不要发不必要的response，从而节约通信资源。

Diagnostic response的格式：

Diagnostic response分为positive和negative两类。positive response意味着诊断仪发过来的诊断请求被执行了，而negative response则意味着ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negative response的报文中。

除了UDS之外也有其它的通信协议，比如OBD（用于汽车法规排放相关协议）。基于CAN的UDS俗称UDSonCAN，而基于K线的UDS目前很少见。对于UDS和OBD的通信结构如下图:

positive response的格式如上图所示，也基本上是由三部分组成，其中的response SID这个字节作为诊断请求的echo，它等于SID + 0X40。后面的两个部分则视具体的诊断服务而定。

negative response的格式固定为3个字节，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断服务无法被执行的原因。下面这张图列举了部分原因代码，比如，如果ECU给出7F 22 13这个negative response，则说明22这个服务因为诊断请求数据长度不对的原因无法执行。

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

通讯机制

基于CAN的UDS俗称UDSonCAN，而基于K线的UDS目前很少见。下面是UDS通讯结构图：

UDS特点：UDS为事件驱动型，不会主动告诉外部信息，一问一答的形式，如诊断仪发出指令，UDS回复。

常用的诊断服务

下面来简单梳理一些服务的格式。

10服务：DiagnosticSessionControl

10服务的主要功能为ECU诊断状态控制。

常用的sub-function有：

0x01：defaultSession（ECU上电之后，默认状态）–默认会话

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

0x03：extendedDiagnosticSession（在这个session中可执行较多的诊断服务）–扩展回话会话注意：10 指令中不同会话的转换是按照上图的流程来的 不能随意切换。如默认会话下不能直接进入编程会话

11服务：电控单元复位

11 01 ： hard Reset （simulates the power-on/start-up sequence typically performed after a server has been previously disconnected from its power supply）（模拟通常在服务器之前与其电源断开连接后执行的开机/启动顺序）

11 02 ：keyOffOnReset（similar to the driver turning the ignition key off andback on）（同时关闭和重新打开点火钥匙（类似于司机把点火钥匙关掉再打开））

11 03 ：soft Reset（causes the server to immediatelyrestart the application program if applicable）（使服务器立即启动应用程序（如果适用） ）

27服务：SecurityAccess安全访问

对于安全级别稍微高一些的诊断服务，需要执行27这个安全访问诊断命令，进行一个简单的身份验证。

完成27服务有以下步骤：

1，诊断仪向ECU请求“请求种子”（通常是一个与时间相关的伪随机数）；

2，ECU向诊断仪发送“反馈关键字”；

3，诊断仪向ECU发送“Key” (根据反馈关键字和一个本地的密码进行计算得来)

4，ECU判断诊断仪发来的“Key”是否有效

下面举个解锁的例子：

诊断仪发送：27 05

ECU响应 : 67 05 01 01 01（关键字是 01 01 01）

诊断仪发送 : 27 06 02 03 04（key值是02 03 04，seed是 01 01 01，假设本地密码为01 02 03，而算法就是将密码与seed相加）

ECU验证成功 : 67 06

此时ECU就处于unlocked的状态了，那些被保护起来的诊断服务和诊断数据可以被操作了。

28服务：CommunicationControl

该服务用于打开/关闭某些类别的报文的发送/接收。

sub-function：

0x00enableRxAndTx （激活接收和发送）

0x01enableRxAndDisableTx（激活接收和关闭发送）

0x02disableRxAndEnableTx（激活发送和关闭接收）

0x03disableRxAndTx（关闭接收和发送）

communicationType：

0x1：代表普通应用报文；

0x2：代表网络管理报文；

0x3：代表普通应用报文和网络管理报文。

14服务：ClearDiagnosticInformation

14服务主要功能为删除存储在ECU中的DTC

sub-function用于标识将要被删除的DTC种类，UDS规定用FFFFFF表示所有种类的DTC

例 ：诊断仪发送：14 FF FF FF(清除所有种类的DTC)

    ECU响应: 54（给出positiveresponse）

85服务：ControlDTCSetting

该服务用于控制ECU的DTC存储。

sub-function： 0x01 : on 0x02 : off

19服务：ReadDTCInformation

19服务主要功能为读取存储在ECU中的DTC

sub-function

0x01用于读取符合特定条件的DTC数量。

0x02用于读取符合特定条件的DTC列表。

0x06用于读取某个DTC及其相关的环境数据。

Parameter

Parameter是指DTC的status。

bit0 表示这个DTC是active的还是passive的；

bit4表示这个DTC是否已经被confirm了，如果DTC的状态是confirm，则说明该DTC已经被ECU存储下来了。

比如：

19 02 08这个命令的用途，就是读取所有状态为confirm的DTC的数量。

31服务：RoutineControl

31服务是调用ECU内置的一些操作序列的接口。

sub-function

启动（0x01）

停止（0x02）

查询结果（0x03）

routineControlOptionRecord，用于标识routine执行时所需要的参数，由各家自定义它的内容

例如，假设用0x0801这个ID来代表检查ECU是否满足软件刷写条件（比如车速、转速为0，KL15接通等）的routine。

诊断仪向ECU发送31 01 08 01即可启动0x0801这个routine。

还有很多诊断服务，常用的是这些，持续更新~