前言:
因为不会转载,故在这里贴出原文连接,写的非常好!条理清晰,一遍看懂@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后”也存在两种不同的情况,先看下面这张图
情况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,计时器也是启动了
一般可以设置定时器参数如下图