（二）UDS简介

原创已于 2024-08-04 18:48:56 修改 · 1.4k 阅读

24 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#汽车 #mcu

于 2024-07-08 13:38:31 首次发布

IAP与OTA 专栏收录该内容

8 篇文章

订阅专栏

IAP和OTA（UDS简介）

这里写目录标题

IAP和OTA（UDS简介）

什么是UDS

UDS是汽车诊断常用到的协议，它是应用层的协议，什么意思呢？也就是说我们底层驱动硬件用到的各种总线协议，像CAN总线协议，LIN总线协议。这些都属于是物理层的协议，这些物理层的协议一帧的数据可能包含ID，CRC校验码，同步段，还有实际要发送的“数据”等等，以保证这一帧的“数据”是有效的。而UDS协议就包含在这一帧有效的“数据”之中。

我们去4S店维修汽车的时候，维修人员拿的诊断仪其实就是使用的UDS协议，通过UDS协议可以读取到汽车的故障码，也就是DTC。UDS是采用的一问一答的方式，它定义了一系列的服务，我们按照这些服务的格式去询问汽车上各个ECU单元，然后ECU又会按照对应的格式返回对应的故障信息给到诊断仪。

我们此次用到的IAP，也是需要在UDS之上来进行的，UDS处了可以获取汽车各个ECU的故障信息，同时还定义了一套数据传输的规则，我们需要解析这一连串的UDS的数据，获取需要烧录的hex文件。

UDS对应的OSI七层模型

看到没有，UDS其实是不管底层总线协议是什么，它是应用层的协议，虽然底层协议不同，UDS的数据格式也有略微一点区别，这个后边会介绍到。注：是ISO14229-1这份协议里边规定了UDS的。
UDS对应的OSI七层模型

6大类26项服务

6大类26项服务
26项服务就是26个SID，每个SID可能又有分为多个子ID，具体用到什么服务，要实现哪些功能再具体看每个服务的使用规则。对于IAP来说，我们一般用到的是“上传和下载功能单元”的0x34、0x35、0x36、0x37、0x38服务，还有0x10、0x11.

三种会话

默认会话、编程会话、扩展会话

为什么有这三种会话呢？
这是因为服务的场景不同，举个例子，我去找同事聊天，聊一些无关紧要的事，此时我在默认会话就可以了；哪一天，领导决定我干的不错，可以给我涨点工资，此时，我就被叫到了办公司这样比较私密的地方；后来，老板决定我是公司的未来，决定分我一点股份，此时我又被叫到了老板的私人别墅里。不同的会话，可以做的事情是不同的。

利用10服务进行会话的切换。比如
“10 01 xx xx xx xx xx xx”，进入默认会话
“10 02 xx xx xx xx xx xx”，进入编程会话
“10 03 xx xx xx xx xx xx”，进入扩展会话

注
1.ECU上电要处于默认会话之下。
2.在非默认会话下超过多少秒（具体主机厂来决定），要从非默认会话返回默认会话
3.如果要进入扩展会话，要先进入编程会话，才可以进入扩展会话，不能跳步，直接从默认会话到扩展会话。

3、4种帧格式

可以看到无论是CAN，还是LIN，他们一帧传输的数据也就8个字节，但是对于一些服务，像IAP用到的37服务，它要进行代码的更新，那么就不可能只有单单的8字节，一个hex是nK或者nM，一帧肯定传输不完，此时多帧传输就派上用场了。
一般分为：单帧，首帧，连续帧，流控帧。
单帧（SF）：如果一条命令只有一帧数据就能存得下，那么就用单帧
首帧（FF）：如果数据需要多帧来传输，那么这些帧的第一条就是首帧，首帧有标明接下来有多少数据由连续帧来传输
连续帧（CF）：多帧传输，除首帧外，其他的都是连续帧
流控帧（FC）：接收方在接收到诊断仪发送过来的首帧之后，要返回流控帧指导发送方接下来应该怎么发，流控帧的作用就是来告诉诊断仪隔多久给我发一帧，还有一次性可以给我发送多少帧。
在这里插入图片描述

在这里插入图片描述

FS： 0 继续发送、 1 等待、 2 溢出，终止

BS： 0 不限制连续帧、 1~255 连续帧数量

STmin： 0-7F 连续帧最小间隔时间 0~127ms 、 F1-F9 连续帧最小间隔时间 100-900us

为什么目录标题写着“3、4”呢？
这个特别说明一下，如果是LIN总线为载体的话，它是没有流控帧的；如果是CAN总线为载体的话，是存在流控帧的。这是不同的物理层的细微差别。

DTC故障码

例如：P0420
它是用诊断仪读取出来的5位故障码，它占用2个字节，具体怎么解读呢？
P0420
-》 0x04 20
-》 00（P） 00（0） 0100（4） 0010（2） 0000（0）

bit0-bit1：
P（0）：动力系统
C（1）：底盘系统
B（2）：车身系统
U（3）：网络系统

bit2-bit3：
0：ISO/SAE控制
1：制造商自定义

bit4-bit7：
故障所属的子系统：例：点火系统、排放系统…

bit8-bit15:
发生故障的具体部件及类型：例：水温电压信号太高、节气门传感器电压低…

然而，我们用19服务读取出来的肯定响应却不只有一个五位故障码，读取出来的是这样子的
“五位故障码 + 故障类型字节 + 状态位”
故障类型字节：（00~0F）一般故障、（60-6F）算法故障…
故障码：bit0 （当前故障）、bit3 （已确认的故障）故障码在一个操作周期（一次上下电）出现3次或者多次，就会置位该位…

物理寻址和功能寻址

物理寻址和功能寻址其实就是私聊和群发的区别。
对于CAN总线来说，每一个ECU对应一个ID（也就是对应的仲裁段），比如左车门的ECU是0x120，右车门的ECU是0x121，物理寻找就是单独给0x120或者0x121发，而功能寻址的话，一般ID是设置才成0x7DF。这样子如果发0x7DF的话，左车门和右车门都能收到。

对于LIN总线来说呢，虽然说每个ECU也是有对应的ID，但是，它不像CAN一样，在一帧UDS报文里边，会有一个NAD的字节，这个字节来表示私聊还是群发，0x7F表示群发，具体看下篇。