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。
还有很多诊断服务，常用的是这些，持续更新~