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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

反馈帧格式：

反馈帧格式：

这篇文章只是作为UDS的一篇较为简浅的介绍，仅介绍了关于反馈、模式、命令层、数据帧格式相关的一些简单的数据定义。UDS是一个较为庞大完整的系统。所以后续还需要更新，将其填补完整。

后面还会将其进行扩展，将一些反馈帧、各层的详细描述、模式的相关的切换方式、反馈相关的流程与错误记录。敬请期待~

本文首发自 记：从零开始讲解UDS（一）——协议概述。-我的博客，更多文章可进入我的博客详查。