UDS之时间参数总结篇

汽车小T

已于 2023-04-16 16:51:34 修改

阅读量1.8w

点赞数 57

分类专栏： UDS诊断服务详解文章标签： java 运维自动驾驶

于 2021-04-26 23:09:07 首次发布

本文链接：https://blog.csdn.net/wto9109/article/details/116176643

版权

UDS诊断服务详解专栏收录该内容

12 篇文章 260 订阅

订阅专栏

前言

UDS： (Unified Diagnostic Service) 统一诊断服务协议。

之所以称为统一诊断服务，则是因为该协议是建立在各种传输方式之上的应用层协议，与底层所采用的通信介质都没有关系，该协议内容在ISO14229-1中定义，目前该协议版本已更新至2020版。

在UDS开发及测试过程中，总是会出现各种各样的时间参数，你是否存在以下烦恼呢：

为什么会有这些时间参数呢？
这么多的时间参数，怎么记得住呀！
这些时间参数名字大同小异，到底有啥区别呢？
这些时间参数到底应该如何正确的使用呢？

不要着急，实属正常，谁也没法一直记住这么多参数，在此之前，我跟大家一样，同样存在上述种种疑惑。开发及测试过程中往往容易忽视这些时间参数的作用，等到出现问题时才去进一步了解其含义。
为了较为全面的对UDS用到的UDS参数有个了解，接下来，我将从网络层，会话层，应用层以下三个层面来跟大家一起探讨学习UDS用到的所有时间参数，如下图1所示：

在这里插入图片描述

正文

以DoCAN为例，以下传输层与网络层相关参数在ISO-15765-2中都会有相关细节性的描述，本文只做系统性总结，对具体细节不作展开，大家可自行深入研究。

传输层时间参数

Addressing Mode(AM)

在发送诊断指令的过程中，存在以下两种寻址方式：

物理寻址： 即该诊断服务请求只针对符合请求中物理地址的ECU，其他ECU节点不做任何接收处理；
功能寻址： 即该诊断物理请求针对当前网络下所有的ECU节点，所有的ECU均会接收处理该诊断请求；

一般而言，一个ECU节点只会存在1对物理寻址，1对功能寻址；每一对寻址方式根据客户的需求来自行定义。

应用场景与作用：

当该诊断请求需要发送至特定ECU节点时，就需要使用物理寻址方式，如使用$2E服务写DID或者执行$34，$36, $37执行下载程序时；
当该诊断请求需要发送至当前网络下所有的ECU节点时，就需要使用功能寻址，典型过程如FBL刷写过程中的$28,$85服务等。

Block Size与STmin

Block Size 简称“BS”，该参数与STmin一般同时出现。此两参数主要用于诊断报文传输多帧时会使用到。在传输多帧诊断报文的过程中，存在着三种类型的帧：

首帧FF（First Frame ）：发送多帧过程中的首帧报文；
流控帧FC（Flow Control）：发送方发送首帧报文之后，如果有流控，接收方回复的流控帧；
连续帧CF（Consecutive Frame）：流控帧之后发送方能够连续发送的报文帧；

如下图2所示，较为清晰了表述FF、FC、CF三者之间的交互关系。
在这里插入图片描述

图2 流控交互机制

BS： 接收方表示发送流控帧之后，发送方被允许连续发送的最大帧数目。特殊情况下，如果该值为0，则表示发送连续帧没有限制，如果值为8，表示发送方最多能连续发送8帧CF就会继续收到接收方的流控帧；
STmin： 接收方发送流控帧之后，发送方发送的连续帧之间的时间最小间隔。如果值为0，表示对于发送方发送CF的最小时间没有要求。

应用场景与作用：

在APP模式下，发送报文长度大于8或者大于64（CANFD）时，就会自动开启流控模式。在Boot模式下，由于使用到$36下载服务，涉及到大量数据的传输，也必然会使用到流控。

由上可知，BS与Stmin的大小能够用来评估接收方的接收能力，如果都为0，表示接收方接收能力最强；

当然，有些时候，虽然Boot均可以设置为0，但是往往FBL刷写过程中涉及到网关的转发，而网关接收能力存在限制，因此，此时对应的Boot也必须按照网关的接收能力来设置BS与Stmin。