前言
“诊断服务作为应用层的服务功能,实现逻辑很简单,请求-响应,一来一回之间,需要对每个阶段进行时间设置”
之前在介绍UDS服务时,UDS由物理层、链路层、网络层和应用层组成,其中并没有传输层
然而不管是ISO官方文档还是CANoe工具,把应用层的定时参数看作是传输层功能,其中有以下几种:
- P2Client
客户端在成功发送请求消息到收到响应消息的超时时间
- P2*Client
客户端在接收到78 hex的否定响应后等待服务器发送响应时的增强型超时设置
78否定响应码表示服务器暂时繁忙,用来提示客户端继续等待,而P2*Client就是继续等待的超时时间
- P2*Server
服务器在发送78 hex的否定响应后,到服务器发出响应消息时间的性能要求
- S3Client
客户端为保持非默认会话而连续发送的Tester Present请求消息的时间间隔
Tester Present会话保持服务SID是3E hex
- S3Server
服务器在未收到任何诊断请求消息的情况下使诊断会话保持在非默认会话的时间
我们知道如果ECU在一定时间内未收到诊断消息,就会从其他会话返回默认会话,这个时间就是S3Server
所以只要在S3Server内一直有诊断通信,ECU就会维持在活动状态(非默认会话),那为什么还要定义一个3E服务来维持会话呢?
因为有的时候通信可能暂停,等到下次想使用诊断服务时,又需要重新切会话,比较麻烦,所以就定义了一个专门用来维持通信的服务,其实就是定时发送3E请求消息,ECU收到后回复7E响应的过程
- P3ClientPhys
客户端在成功发送无需响应的物理寻址的请求消息后,再次发送下一条物理寻址请求消息的最小时间间隔
- P3ClientFunc
客户端在成功发送所有服务器无需响应或仅需部分服务器响应的功能寻址的请求消息后,再次发送下一条功能寻址请求消息的最小时间间隔