UDS诊断基础知识简介-ISO14229

什么是UDS？

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

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

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

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

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。

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