[导读]0x00UDS概述UDS（UniversityDiagnosticsSystem通用诊断系统）是一个在整车系统上经常使用的设备维护协议。其主要遵循的法规为：ISO-15765、ISO-14229，其主要协议模式脱胎于OBD（On-boarddiagnostics）诊断协议。经常应...

0x00 UDS概述

UDS（University Diagnostics System通用诊断系统）是一个在整车系统上经常使用的设备维护协议。其主要遵循的法规为：ISO-15765、ISO-14229，其主要协议模式脱胎于OBD（On-board diagnostics）诊断协议。经常应用在整车的各种ECU上面。是一个在整车ECU应用层开发经常使用的也是较为复杂的协议层之一。
本篇文章主要介绍了UDS协议相关的协议的宏观介绍。阅读本文之前，您需要了解的一些前置技能有：

技能名称	技能熟练度	技能教程链接
CAN总线	熟悉	暂无
数据类型	熟悉	暂无
OBD	了解	暂无
整车缩写	了解	暂无

0x10 层次类型

UDS主要分为五大协议层次：物理层、链路层、协议基层、协议网络层、协议应用层。此外，还有较为完善的协议时效管理与协议的错误、正确反馈码。
而整个协议的交互分为客户端和服务端，而客户端为诊断仪；服务端就是整车上的ECU。
需要注意的是：错误反馈值严格根据反馈的错误检测流程决定。这种错误检测流程会在后期简述。
为了方便讲解，我暂时将协议基层、协议网络层、协议应用层统称为协议层，具体的详情会在后期简述。

0x11 物理层

物理层主要的实现可以为任何协议的硬件决定，这个是由链路层的选择支持的。例如常用CAN协议进行载体，物理层就可以使用相应的CAN芯片进行构架。如果使用LAN进行载体则也可以使用相应的芯片进行构架。

0x12 链路层

链路层是整个协议的实现基石（从软件工程师的角度来讲），链路层定义了当前的系统基层数据定义与底层驱动的选择和编写。而整个链路层稳定性对于当前网络的实现都是非常重要的地方。其决定了数据接收的正确性与误码率，也决定的反馈码的传输正常，很多上层查询不到的问题都有可能出在这里。

0x13协议层

协议层主要进行以下几大操作：数据接收、数据处理、数据反馈、时间限制。

数据接收

UDS主要依托于硬件协议进行数据构架，本文主要以汽车行业常用的CAN总线协议进行数据构架。CAN帧数的数据是固定的，对于大数据的传输是比较难受的，基于此，UDS具有一定的数据定义：标准帧（Normal Frame）、首帧（First Frame）、流控帧（Constraints Frame）、数据帧（Data Frame）。对于各个数据的定义主要是靠CAN单帧数据中的第一位字节数据中的前四位Bit数据决定。

数据帧定义	数据帧标识	数据实体示例
标准帧	00	00 XX XX XX XX XX XX XX
首帧	01	1X XX XX XX XX XX XX XX
流控帧	11	30 AA BB XX XX XX XX XX
数据帧	10	20 XX XX XX XX XX XX XX

而首帧中，AABB则是相关的时控参数，这个会在之后再讲。

数据处理

数据处理主要是根据当前的接收数据，将其根据应用层相应的指令进行数据处理。

数据反馈

数据反馈则是对于当前的指令数据处理完成之后，将其处理结果反馈给当前的数据接收端，这个数据反馈分为正反馈（正确反馈）和负反馈（错误反馈）。且严格根据时序限制进行数据传输。

时间限制

协议层主要的时间限制为两项，一项为流控帧对于数据帧发送时间的时控参数限制（网络层），另一项为应用系统在线时效和模式时控参数限制（应用层）。前者主要原因为避免当前数据重放错误，后者主要避免当前模式错误定义。

0x20 数据类型

数据主要分为单帧和多帧。而多帧则根据传输流程分为：首帧、多帧、流控帧。

0x21 单帧

单帧则很简单，主要给一些不怎么长的指令集进行传输，优点在于快准狠，一帧即可代表一个指令，对于软件测试模拟也比较方便。但是缺点在于很多场景下无法使用，例如大量数据的传输。其主要的数据格式定义为：

数据定义	长度bit	备注
帧格式定义	0~3	相应的协议数据定义
帧长度	4~7	后面的有效字节长度
数据实体	8~63	数据根据帧长度定义

对于单帧的反馈也是相似的，也就不在阐述了。

0x22 多帧

首帧

首帧的是整个多帧传输流程的起始，一般由客户端先发出，包括了当前指令请求的长度和先前的几个数据。其主要的数据格式定义为：

数据定义	长度bit	备注
帧格式定义	0~3	相应的协议数据定义
帧长度	4~15	整个多帧的有效数据长度
数据实体	16~63	一部分数据

流控帧

流控帧是当前的首帧接收端接收后，判断当前数据没有出错的情况下，发送的一种数据响应，主要包含了当前多帧的数据发送最短间隔时间与流控帧发送次数。其主要的数据格式定义为：

数据定义	长度bit	备注
帧格式定义	0~3	相应的协议数据定义
流控帧状态	4~7	一般为0，具体详见ISO14229
流控帧最短发送次数	8~15	块大小
数据发送最短间隔时间	16~24	流控帧的时控主要参数
填空	25~63	一般为协定值

块大小：当前发送的数据帧是有一定的次序的，而一旦发到一定次序，则数据接收端就会发送一次流控帧，否则发送端就会判断当前多帧发送失败。
数据发送最短间隔时间：当前两帧数据帧的发送间隔时间，单位为毫秒。

数据帧

数据帧是当前的服务端发出流控帧之后，在一定时间内由客户端进行发出。数据帧就是大量帧格式的主要组成部分，也是经常在编程上面会出错的地方。其主要的数据格式定义为：

数据定义	长度bit	备注
帧格式定义	0~3	相应的协议数据定义
数据帧长度	4~7	与流控帧[8_15]相关,00xF循环
数据实体	8~63	剩下的全部数据

0x30 模式类型

模式是UDS中的一个非常重要的软件抽象，UDS在应用层中抽象了3大模式：普通模式、扩展模式、编程模式。而扩展和编程模式中，又分为普通权限模式和特权模式。模式之间的主要区别如下：

模式名称	授权模式	具有权限
普通模式	普通权限模式	无法读取内部数据，执行较为简单的指令（重启、模式切换、会话保持）
普通模式	特权模式	无此模式
扩展模式	普通权限模式	可以读取内部的ECU状态值，ECU错误值，厂商SN号等
扩展模式	特权模式	可以读写内部的ECU错误值、厂商SN号等
编程模式	普通权限模式	可以读取一些厂商内部值
编程模式	特权模式	可以读写厂商内部值、可以刷新当前的固件版本

而在普通权限模式下，可以使用相应的应用层指令可以将其切换呈特权模式，但是会有自有的密钥算法进行交互，且有很严格的时序和错误次数的要求。这个我会在之后的应用层的详细讲解中进行介绍。

0x40 时效类型

时效类型主要为应用会话过期时效与帧交互过期时效。

0x41应用会话过期时效

应用会话是指当前客户端与服务端的交互中，应用层完成指令的间隔。单位一般为秒，例如五秒。一般主要使用在普通模式与扩展模式的切换和普通模式与编程模式的切换作为时间限制。
整个会话期间，要求客户端一直进行应用层的指令发送，就算仅仅使用CAN帧进行发送也无法算作会话成功。

0x42 帧交互过期时效

此与流控帧的时序控制相关，一般由服务端进行发送，单位为毫秒。主要是在数据帧的发送期间使用，但是需要注意的是，这个时序控制并不是限制最大时间，而是限制最小发送时间。也就是说，如果发送的是10ms的时序控制时间，则客户端的每一个数据帧的最小的发送时间就是10ms，如果在9ms的时候发送了数据帧，则很多时候会服务器端会将其丢弃。附多帧发送的时序图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uRMnfXox-1574862939925)(https://www.abcde.engineer/wp-content/uploads/2019/05/2d46212699373f8ce6170de603e2731b.png)]

0x50 反馈类型

反馈类型主要分为：正反馈和负反馈，可能因为翻译或者是我自己的感受，总是觉得这两个称呼很难受。其实正反馈就是正确的指令的编码返回，而负反馈则是当指令的编码错误或者流程原因导致了无法执行指令的情况下，给客户端反馈的错误代码简短的错误记录。他们的格式基本上如下：

0x51 正反馈

反馈帧格式：

帧格式定义	位置bit	备注
正反馈位置	2	当其为1时就是正反馈，否则就可能不是正反馈
客户端指令	0~2、3~7	一般都是客户端传输过来的指令
相应的状态数据	8~63	根据相应的指令格式进行反馈