关于诊断中的各种时间参数

前言：

因为不会转载，故在这里贴出原文连接，写的非常好！条理清晰，一遍看懂@king110108

原文链接：UDS之时间参数总结篇_uds时间参数-CSDN博客

以下内容是我自己对这篇文章的一些备注和理解，以及从测试的角度如何测量这些时间参数

1：首先作者花心思用思维导图作了个提纲，就很不错，作者从应用分层的角度来划分各种时间参数 

作者按4层划分，一共统计了 15个时间参数，和BS（该参数也间接影响其他时间参数的设置和测量）

2：传输层的AM和BS，不算时间相关的参数，STmin该怎么测量。先看STmin的具体定义

计时开始时间：第一帧，续帧发送完成时刻 

计时结束时刻：第二帧，续帧开始发送时刻

2.1 测试方式1——最准确的测量方式，使用示波器或逻辑分析仪

步骤1：为了避免干扰，如果测试样件支持28服务，先禁止应用报文和网管报文的发送。

步骤2：发送一个多帧报文，如22读取一段大于12Byte的数据（是确至少存在两个续帧）

步骤3：找到第一个续帧的ack处，记为T_Stm_start

步骤4：找到第二个续帧的SOF处，记为T_Stm_stop

比较规定的Stmin 与（T_Stm_stop-T_Stm_start）的大小即可

2.2 测试方法2——不太准确，但是可以通过计算，补偿误差

就是我们使用CANoe或spy3中的报文显示界面直接测量，查看两个续帧之间的间隔时间即可。

误差在于，此侧脸的时间是，第一个续帧被接收时刻 ---第二个续帧被接收时刻，之间的差值

仔细看上图，这样侧脸的时间差值，与标准定义的Stmin，相差了第二个续帧从SOF开始发送到ACK的值。而这个值我们根据诊断帧的类型和长度，和波特率可以很容易得计算出来。

比如第2帧，续帧是CAN11bit仲裁段，经典帧，500k，数据段长度=8BYTE

可知发送的时长为，100nit*2us=200us，直接将测试值-200us即可

 3：网络层时间参数

3.1 从最简单的AS 大致讲一下As这个时间段内，样件通讯中的各层，都干嘛了？

**1）首先网络层，开始调用数据链路层的req函数（也可以称为服务）

**2）数据链路层，req函数开始接收，从网络层传入的实参数据。并判断数据是否合理和正确。

**3）判断数据正确后，数据链路层，则需要开始调用物理层的req服务

**4）物理层也有一套检查机制，数据正确，则开始向双绞线上发送实际的编码电压

**5）数据层发送完成，会调动一个confirm函数（常称为服务），向数据链路层报告数据已经完成发送。

**6）数据链路层，在接收完物理层传递的confirm信号后，开始向NM层调用一个confirm函数（常称为服务），表示数据传输已经完成。

到这里一个Ar的时间参数，算是走完了一整个流程。从以上描述我们知道，如果流程中的任何一个环节出错，Ar都会超时。

3.3 为什么要设置Ar参数

我们知道任何一种通讯协议，最重要的特性有以下几种，可靠性和实时性，时间参数就是为了保证通讯的实时性，如果一个通讯的底层代码，走完上面一套流程，花费了几百毫秒的时间。那这个通讯底层代码，就可以被称为一个合格的垃圾代码。

还想一下，我们bootload时，数据量巨大，如果每发一帧报文，在最初处理阶段就花费几百毫秒，你会不会头皮发麻？？？

3.3影响N_Ar的因素有那些？

因素1：代码的架构

因素2：波特率等

因素3，协议中的帧类型，和数据长度

3.4 如何测量N_Ar参数

具体如何测量，我不是很清楚，问了开发人员说可以，可以通过劳特巴赫，来测量等以后学会了，单独写出来和大家分享。

3.5 比较容易测量的N_Bs和N_Cr

3.5.1N_Bs参数

看下图，我圈出来的两个。可以明显的知道，就是在首诊发送完成后，到流控帧发送完成。

直接使用CANoe中的报文界面，直接量取就好 。

同样的N_Cr有两种方法去量取

**1）直接量取，从流控帧发出，到续帧中首帧报文发出的时间差

**2）从前一流控帧被发出，到下一帧流控帧被发出

思考问题 :看看上面中的N_Cr中的第二种描述，和STmin的描述。现在有如下情况，请思考

问1？：

当我们设置N_Cr=100时，我们有通过流控帧设置STmin=200，这样的设置会不会有问题。

答1 ：这样设置是肯定有问题的，STmin<N_Cr

问2？：

日常诊断中，我们使用诊断仪和车辆进行诊断，如果这样描述诊断仪就是sender，在诊断仪中只设置N_Ax相关的参数是否就可以了？同理对于车辆认为是Receiver，只设置N_Bx相关参数是否就可以？

答2:不可以，诊断仪和车辆和sender和Receiver并没有确定的映射关系，即诊断仪既可以是sender也可以是Receiver

问3：？

网络层中的各种参数，之间的关系

 答3：

•  (N_Br + N_Ar)<(0.9倍N_Bstimeout)；
•  (N_Cs + N_As)<(0.9倍N_Cr timeout);

4：会话层参数

会话层参数以s开头，代表的是Session（会话），一般情况下工程中会有 10 01 、10 02 、10 03

三种状态之间相互跳转。

Tester代表客户端，Server代表服务器端。

非默认10 01会话下，如果一段时间没有新的请求下，会话会自动跳转到10 01会话下，S3Server就规定了这个跳转的时间，一般设置为5s

S3Tester规定的是 3E服务在Test中发送的周期，为了维持会话，而定期发送的帧。

这里需要注意S3Server这个参数

这个参数在需要肯定响应和抑制肯定响应位时，情况还不一样。看下面一张图

4.1 关于服务器定时器初始化Init 

   提取信息1：S3必须是在非默认回话下，才会启动

提取信息2：S3server必须是应用层判断非否定响应，才会启动S3server定时器，非否定响应可能回一个postive响应，也可能不回响应

提取信息3：对必须回 postive响应，等待N_USD.con后，才会启动定时器

提取信息4：对子功能中的，存在肯定抑制响应位并置位的情况，只要Request中的Ind服务被调用时，才会启动S3server定时器。

对3和4的实例讲解

（**1）肯定响应情况+需要回复一个肯定响应帧的情况

       如 client端请求 71A 03 10 03 xx xx xx xx xx

Server端会回一个 72A 06 50 03 AA BB CC DD xx （AA,BB,CC,DD是P2相关的参数）的肯定响应

在这个帧发出后，网络层的服务才会调用con服务，给应用层，来指示已经发送完成，这是S3serve服务器才会启动。

这里也可以看出只有肯定响应，才能启动，定时器，如果是否定响应，不会触发定时器。

（**2）肯定响应情况+肯定响应被抑制的情况

       而当你发出  71A 03 10 83 xx xx xx xx xx（注意标红的是抑制肯定响应位，被抑制），

此时对于Server来说，只要服务器网络层中的N_Data_ind中的服务被调用，计时器就开始初始化且被计时。

这里还有一个点，比较重要“必须是服务器中的ind服务被调用，FF.Ind被调用是，不会开启定时器的”

4.2 关于服务器定时器初始化停止计时

这么一小段话，其实要分为两个 部分。

**1) N_USDataFirstFrame_ind 或者N_USData_ind，任何都会停止已经开始计时的计时器。

**2）一旦重新回到默认回话，定时器也会被停止

4.3 关于服务器定时器初始化重新初始化

**1）是指新的诊断回应被发出（且已经被全部成功发出了），此时如果旧的计时器还没结束，此时会重置S3server计时器。上图中第一栏又说明，无论是正响应还是负响应。都能重启计时器，上一个章节又说必须正响应才能

初始化计时器。这里情况不同，上一章节是指初始状态为 10 01 跳转到其他状态 如 10 02活10 02

这里说的是指会话状态已经在非默认会话状态下。这一点需要清楚。

**2）0x78不会重置S3server定时器

**3）对于不需要响应的诊断请求，从诊断请求被完全被发出后开始计时。

**4）多帧的诊断request帧（指client发出的），在server接收时，出现错误。这里的错误，存在以下类型

一共大概10种，具体不再详述，大家有兴趣自行参考IS015765-3,这里有几种错误是server能发出的，大家需要自己去查阅标准。当错误发生时计时器也会报错

4.4 如何测试S3clent和S3server相关参数

S3server如果想简单测一下timeout比较好测，如果要求测试精度不高，甚至可以手动计时。但是如果想详细测试，比较复杂。等我理清了，可能以一个测试case的方式和大家分享。

5：应用层参数

5.1 规范中对这些参数的解释

5.2  P2can_Clinet与P2can_server

**1) P2can_Clinet 是指应用层，在接收到网络层的 N_USData.con后，此处为开始点。到接收到服务器端的N_USDataFirstFrame.ind 或 N_USDataind,也就是接收到网络层的首诊，或多帧信息的首帧指示时，为结束点

这里上一段标红的字段“在接收到网络层的 N_USData.con后”也存在两种不同的情况，先看下面这张图

应用层定时器参数：request请求多帧或单帧，response回复单帧

情况1：N_USData.req请求的帧，数据链路层使用signalFrame就可以发出

情况2：N_USData.req请求的帧，数据链路层使用MulFrame才可以发出，以多帧为例

关注图中的 a，b，c，d的各种图标，实际图中是外侧带一个圆圈。

a和b之间时间 略微大于N_b->C

B——>C之间的时间，要略微大于 N_Br+N_Bs+若干个*N_Cr

故等待Sender端（此处也是指client端）所有多帧都发送完之后，才会走到C处。然后从C点开始

到客户端接收到首诊指示或数据指示，指的是P2client的值。从D点开始到E点，意义在于诊断请求报文全部发出后，到应用层开始求发出诊断响应。诊断响应也需要分为两种，一种是单帧，一种是多帧，无论是单帧或者多帧报文对P2Server的值几乎不受影响。P2Server 稍微>N_Br.

 5.3  P2*can_Clinet与P2*can_server

**1）P2*can_server ，是指从0x78 被发出后，网络层调用.con服务为起始点，到应用层再次调用.req服务为终点时刻。

**2） P2*can_Clinet，是指client端从接收0x78服务开始计时，为开始时刻，到response的FF帧被接收，或SF被接收，为结束时刻。

注意，此图中其实P2can_server计时器和P2can_Clinet，计时器也是启动了

一般可以设置定时器参数如下图