UDS之时间参数总结篇

前言

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。

网络层时间参数

如下图3所示，清楚的表达了各个时间参数的起始时间及终止时间，以上述流控交互过程为例。

图3 多帧传输过程的时间控制

• N_As: 表示CAN数据帧从请求数据链路层发送至接收到对应的ACK的最大时间间隔；

• N_Bs: 表示发送方数据链路层接受到流控帧的最大时间间隔；

• N_Ar: 表示接收方从请求数据链路层发送流控帧至接收到对应的ACK的最大时间间隔；

• N_Br: 表示接收方请求数据链路层发送流控帧的内在最大时间间隔 (N_Br + N_Ar)<(0.9倍N_Bstimeout)；

• N_Cs: 表示发送方请求数据链路层发送流控帧的内在最大时间间隔 (N_Cs + N_As)<(0.9倍N_Cr timeout);

• N_Cr: 表示接收方接收到流控帧的最大等待时间间隔；

为了便于大家记忆及查询方便，制定相关表格如下图4所示：

图4 网络层时间参数说明

应用场景与作用：

上述时间参数的确定，对于网络层各报文的发送与接收起到了很好的监控作用，能及时发现问题所在。当然考虑到网络高负载的情形，上述参数不一定能够100%满足要求，但是标准要求一般不能超过允许时间的50%。

会话层时间参数

在ISO-15765-3标准中对S3Client与S3Server进行了较为详尽的描述，再次不过多描述，大家可以自行研究学习。

S3Client： 表示Tester为了保持一个ECU或者多个ECU节点同时保持在非默认会话下的时间间隔；

S3Server： 有时也称为S3Timeout，表示ECU未接收到任意诊断报文时维持在非默认会话下的时间间隔；

如下图5所示，描述了这两个时间参数的具体区别。

图5 会话层时间参数

应用场景与作用：

针对有些诊断服务只能在扩展会话下才能够执行的场景，需要保持在非默认会话下，执行该诊断指令。比如在刷写过程中(非必须，但一般一直发送比较号，防止意外的超时)或者其他需要一直工作在默认会话下的场景。

应用层时间参数

在ISO-15765-3标准中针对Tester以及Server列出了3对P时间参数，分别为*P2Client、P2Server、P2*Client、P2 Server、P3Client(Phy) 、P3Client(Func)。

为了较好的比较这六者之间的关系，列表如下图6所示：

图6 应用层时间参数说明

应用场景与作用：

这些时间参数主要用于上位机在测试UDS的过程中，诊断工具需要设置一些参数来实时掌握诊断报文的响应状态以及控制相应诊断请求的发送。这对于评估整个UDS的通信是否稳定等性能指标。

---

更多精彩，敬请关注微信公众号”ADAS与ECU之吾见“!
扫码轻松关注：

公众号后台回复关键字“加群”，便可免费加入AUTOSAR技术交流群，共同探讨CP，AP，SOA，信息与功能安全等前言热点话题！

如果您觉得对你有所帮助，分享不易，多多点赞关注、转发收藏！