15765-3 应用层与会话层

6 应用和会话层

## 6.1 应用层服务

    ISO 15765的这一部分将ISO 14229-1中定义的应用层服务用于基于客户端-服务器的系统，以执行诸如车载车辆服务器的测试，检查，监视，诊断或编程之类的功能。

## 6.2 应用层协议

    ISO 15765的这部分使用的应用层协议定义在 ISO 14229-1中。

 

## 6.3 应用层和诊断会话管理时序

6.3.1 概述

以下内容指定了应用程序层和会话层时序参数，以及如何为客户端和服务器处理它们。

 

图 1 ——在CAN上实现的UDS 对应到 OSI模型 

下面两种通信脚本要区分开来

a) 物理通信，于

         1) 默认会话，和

         2) 非默认会话——会话处理需求；

b) 功能会话，于

         1) 默认会话，和

         2) 非默认会话——会话处理需求。

对于所有情况，都应考虑服务器通过否定响应消息（包括响应代码78 hex）请求增强的 响应时序 窗口的可能性。

ISO 15765-2中定义的网络层服务用于在客户端和服务器中执行应用层和诊断会话时序管理

6.3.2 应用层时序参数规范

默认诊断会话的应用层时序参数值应符合表2。

表2 默认会话的应用层时序参数定义

时序参数	描述	类型	最小值	最大值
P2CAN_Client	客户端在成功传输请求消息后（通过N_USData.con指示）等待响应消息的开始传入（多帧消息的N_USDataFirstFrame.ind或单帧 消息的N_USData.ind）所引起的超时	计时器 重载 值	P2CAN_Server_max + ∆P2CAN	N/A 附a
P2*CAN_Client	客户端在接收到应答码为 78 hex 的否定响应后（通过N_USData.ind 指示）等待接收响应消息（多帧消息的N_USDataFirstFrame.ind或单帧 消息的N_USData.ind）所引起的增强超时	计时器 重载 值	P2*CAN_Server_max + ∆P2CAN_rsp	N/A 附 b
P2CAN_Server	服务器开始 响应 消息的运行需求，在接收到一个请求消息后（通过 N_USData.ind 指示）	运行需求	0	50 ms
P2*CAN_Server	服务器的开始 响应 消息的运行需求，在它传输一个响应代码为78 hex（增强响应时序） 的否定响应消息（通过 N_USData.con 指示）后	运行需求	0 附 c	5000 ms
P3CAN_Client_Phys	客户端在成功发送无需任何响应物理寻址请求消息（通过N_USData.con指示）之后，可以传输下一个物理寻址请求消息（请参见6.3.5.3）之前，最短等待时间。	计时器 重载 值	P2CAN_Server_max	N/A 附d
P3CAN_Client_Func	客户端在成功传输一个功能寻址请求消息到可以传输下一个功能寻址请求消息之间最短等待时间，此情况下不需要响应，或请求数据 只被允许使用子网级别的功能寻址服务	计时器 重载 值	P2CAN_Server_max	N/A 附d
a   客户端等待响应消息启动的最大时间由客户端决定，前提是P2CAN_Client大于P2CAN_Client的指定最小值。 b   客户端为P2*CAN_Client使用的值由客户端决定，前提是它大于P2*CAN_Client指定的最小值。 c   在增强响应时序中，连续否定消息传输最小间隔时间，每个消息的响应码都为 78 hex ，时间应为½P2*CAN_Server_max，最大允许偏差为P2*CAN_Server_max的±20%。 d   客户端等待发送下一个请求消息的最大时间由客户端决定，前提是对于非默认会话，S3Server计时在服务器中保持活跃。

参数∆P2CAN考虑任何系统网络设计相关的延迟，如由网关和总线带宽加上安全边际(例如最坏情况的50%)引起的延迟。最坏的情况(从客户端到服务器以及从服务器到客户端的往返所需的传输时间)，基于系统设计，受影响于

a) 涉及网关的数量，

b) CAN帧传输时间（波特率），

c) CAN总线利用率，

d) CAN设备驱动程序的实现方法(轮询与中断)和网络层的运算耗时。

 

∆P2CAN的值 分为向被寻址服务器发送请求的时间和向客户端发送响应的时间:

∆P2CAN = ∆P2CAN_Req + ∆P2CAN_Rsp

 

图2提供了一个∆P2CAN构成的示例

图2 示例，∆P2CAN——单帧请求和响应消息

 

注意 为了简单地描述时序参数，在后面的所有图中都假设客户端和服务器位于同一网络上。所有的描述和图形都以与时间相关的顺序表示。

默认会话与非默认会话

ECU上电后，默认处于 默认会话(default-session) 状态

DiagnosticSessionControl这个服务非常简单，但是它却是ECU和诊断通信的第一条诊断命令。

诊断仪接入后，一般会让ECU保持在非默认状态(non-default-session)，这时需要诊断仪每隔固定的时间发送TesterPresent (0x3E)服务。

 

6.3.3 会话层时序参数规范

当启动诊断会话 而不是 默认会话 的时，需要进行会话处理，这是通过表3中给出的会话层时序参数实现的。

表3 会话层时序参数定义

时序参数	描述	类型	推荐超时 ms	超时 ms
S3Client	客户端传输用于保持诊断会话的功能寻址TesterPresent（3E hex）请求消息时，消息之间间隔时间。而不是多服务器的默认会话活跃的时间（functional communication），或者向某个服务器物理传输的请求消息之间的最大时间（physical communication）。	计时器 重载 值	2000ms	4000ms
S3Server	服务器在不接收任何诊断请求消息的情况下保持除 defaultSession 之外的诊断会话处于活动状态的时间。	计时器 重载 值	N/A	5000ms

此外，当转换到非默认会话时，服务器可能会更改其应用程序层时序P2CAN_Server和P2 * CAN_Server，以实现一定的性能，或补偿在应用非默认诊断会话期间的限制。非默认的诊断会话可用的时间参数可以通过 DiagnosticSessionControl 积极响应消息来得到。需要知道时序参数的情况：当响应需要传输（见服务描述9.2.1），或客户端必需提前知道可用时序参数在没有响应需要传输的情况下。当客户端启动一个非默认的会话功能，然后它应该适应响应服务器的时间参数。

 

表4定义了客户机和服务器启动/重启其S3Client/S3Server计时器的条件。对于客户端来说，定期传输的功能性寻址 TesterPresent(3E hex)请求消息应该与循序传输的物理寻址TesterPresent(3E hex)请求消息区别开来，后者只在没有任何其他诊断请求消息的情况下传输。对于服务器，不需要区分不同TesterPresent (3E hex)的处理。此外，表4显示，S3Server定时器处理基于网络层服务原语，这意味着在接收到服务器不支持的诊断请求消息时，S3Server定时器也将重新启动。

 

在客户端，需要区分周期性发送物理寻址与循序发送功能寻址的TesterPresent请求

服务器不须区分

 

表4 客户端与服务器会话层时序启、停条件

时序参数	动作	物理 和 功能通信， 使用功能寻址， 周期性传输 TesterPresent请求信息	只能 物理 通信， 使用物理寻址， 循序传输 TesterPresent请求信息
S3Client	Initial start 初始开始	N_USData.con 指示DiagnosticSessionControl(10 hex)请求消息的完成。这只适用于非默认会话类型。	N_USData.con 指示DiagnosticSessionControl(10 hex)请求消息的完成，在不需要响应的情况下
			N_USData.ind 指示DiagnosticSessionControl(10 hex)响应消息的接收，在需要响应的情况下
	Subsequent start 后续开始	N_USData.con 指示功能寻址 TesterPresent(3E hex)请求消息的完成，此请求在S3client计时器每次超时 时发送	N_USData.con 指示任意请求消息的完成，在不需要响应的情况下
			N_USData.ind 指示任意响应消息的接收，在需要响应的情况下
			N_USData.ind 指示出错，在收到多帧响应消息时
S3Server	初始开始	N_USData.con 指示一个DiagnosticSessionControl 积极响应消息的传输完成，这个响应消息用于将默认会话转为非默认会话，在需要响应消息的情况下
		服务DiagnosticSessionControl(10 hex) 请求动作的成功完成，这个请求消息用于将默认会话转为非默认会话，在不需要、不允许响应消息的情况下
	后续停止	N_USDataFirstFrame.ind 指示一个多帧请求消息的开始，或者N_USData.ind 指示单帧请求消息的接收。如果默认会话活跃，S3Server 计时器是 不 可用 的
	后续开始	N_USData.con 指示结束服务执行的任何响应消息（最终响应消息）的完成，在需要/允许发送响应消息（包括积极和消极 响应消息）的情况下。响应代码为78 hex 的否定响应不会重新启动S3Server计时器。
		请求动作的完成（服务结论），在不需要、不允许响应消息（积极和消极）的情况下
		N_USData.ind 指示出错，在收到多帧响应消息时
		有关当请求服务器发送未经请求的响应消息（例如周期数据或基于事件的响应）时服务器中S3Server操作的更多详细信息，请参见6.3.5.4。

 

6.3.4 客户端和服务器计时器资源需求

在默认会话和任何非默认会话期间，客户端和服务器满足上述给定的时序要求所需的计时器资源应符合表5和表6的列表。在非默认会话期间，表6中给出的额外计时器资源需求适用于客户端和服务器。

讲了不同时序参数在不同会话中可能需要的计时器的数目，一个计时器对应一个时序参数，一个服务器上可以对应多个计时器

表 5 默认会话下计时器资源需求

时序参数	客户端	服务器
P2CAN_Client	每个逻辑通信通道(物理和功能通信)都需要单一定时器，例如，每个点对点通信都需要一个单独的通信通道。	N/A
P2CAN_Server	N/A	可能需要一个可选的计时器用于增强响应计时，这是为了确保在P2*CAN_Server到期之前传输后续消极 响应消息（响应码78 hex ）
P3CAN_Physical	每个逻辑物理通信通道都需要单一计时器。	N/A
P3CAN_Functional	每个逻辑功能通信通道都需要单一计时器。	N/A

 

表 6 非默认会话下额外的计时器资源需求

时序参数	客户端	服务器
S3Client	下面情况需要单一计时器，当使用周期性传输时、功能寻址TesterPresent(3E hex)请求消息去保持服务在非默认会话。不需要为每个活跃的诊断会话提供额外的计时器	N/A
	每个点对点通信通道需要单一的计时器，当使用循序传输的、物理寻址的TesterPresent (3E)十六进制请求消息时将单一服务器保持在非默认会话，在没有另一个诊断请求消息的情况下
S3Server	N/A	服务器中需要单一计时器，因为在单个服务器中每次只能有一个诊断会话是活跃的

 

 

6.3.5 时序参数细节描述

 

物理寻址Physical addressing，一对一通信

功能寻址Functional addressing，一对多通信

参考ISO 15765 5.3.2.4

 

6.3.5.1 物理通信

6.3.5.1.1 默认会话期间的物理通信Physical communication during defaultSession

图3图形化地描述了在默认会话期间客户端和服务器中对物理寻址请求消息的时序处理。

图 3默认会话期间的物理通信

a 客户端上的诊断应用开始请求消息的传输，通过向网络层发送一个N_USData.req。网络层传输此请求到服务器。请求消息可以是单帧或多帧。

b 多帧 消息的情况下，服务器端被指示 请求的开始是通过网络层传来的N_USData.ind。

c 客户端被指示 请求消息的完成，通过 N_USData.con。当接收到N_USData.con ，客户端启动它的P2CAN_Client计时器，使用默认重载 值P2CAN_Client。P2CAN_Client计时器的值要考虑有车辆网络设计引起的延迟（跨网关通信、总线带宽等）。为简单起见，该图假设客户端和服务器位于同一网络上。

d 请求消息的完成在服务器通过N_USData.ind指示。

e 服务器收到N_USData.ind后，要在P2CAN_Server 内开始响应消息。这意味着，在 多帧 响应的情况下 首帧 要在P2CAN_Server内发送，单帧 响应的情况下 单帧 要在P2CAN_Server内发送。

f 在多帧响应的情况下，第一帧的接收在客户端中通过网络层的N_USDataFF.ind指示。当接收到 首帧 的指示，客户端停止它的 P2CAN_Client 计时器。

g 网络层会生成一个最终 N_USData.ind ，当全部的消息都已接收，或接收过程中发生错误。单帧响应的情况下，单帧的接收在客户端中通过单个N_USData.ind 指示。当接收到单帧的指示，客户端停止它的P2CAN_Client 计时器。

h 响应消息的完成在服务器中通过N_USData.con指示。

 

知识点：

• 步骤 a
  1. 请求时通过网络层传输的
• 步骤c，P2CAN_Client计时器的启动。
• 步骤d，P2CAN_Server计时器的启动。
• 对于多帧、单帧请求消息，启动计时器的必须等全部数据发送、接收。
• 步骤e，P2CAN_Server计时器的停止。
  1. 响应必须在P2CAN_Server规定的时间内发出。
• 步骤f，多帧响应P2CAN_Client计时器的停止。
  1. 响应必须在 P2CAN_Client 规定的时间内接收到
• 步骤g，单帧响应P2CAN_Client计时器的停止。
  1. 对于多帧、单帧响应，停止计时器在第一个数据帧发送、接收完成。一个多帧响应在客户端侧会出现一个N_USDataFF.ind、多个N_USData.ind
• 会话过程中，计时器的值大于预设值时，会引起额外操作。如：增强响应时序窗口、报超时错误

 

##### 6.3.5.1.2 在默认会话期间使用增强响应时序进行物理通信Physical communication during defaultSession with enhanced response timing

图4图形化地描述了客户端和服务器在默认会话期间对物理寻址请求消息的时序处理，以及服务器对增强响应时序的请求(消极响应码78 hex处理)。

 

图 4——Physical communication during non-default session — Enhanced response timing

图片描述这里是不是印错了

 

a 发送请求

b 请求消息接收的指示，多帧情况下

c 请求发送完成

d 请求消息接收完成

e 发送响应，响应码为0x78 ，用于增强响应时序

f 如果服务器不能在P2CAN_Server响应时序内提供所请求的信息，它可以通过发送包含响应代码78 hex 的消极响应消息来请求一个增强的响应时序窗口。在客户端接收到否定响应消息后，客户端网络层生成一个N_USData.ind。接收到响应码78 hex 的否定响应消息会导致客户端重新启动它的P2CAN_Client计时器，但是使用增强的重载值P2*CAN_Client。

g 响应传输完成，服务器重启计时器，使用P2*CAN_Server。

h 服务器在定时内，发送响应

i 接收到多帧帧响应消息的首帧，停止计时器

j 接收到单帧消息，停止计时器

k 传输完成在服务器端指示

 

图片右侧步骤

客户端默认挂起列表为空

步骤f中，客户端不仅要重设计时器，还要在挂起列表中添加一个ECU#1（就是服务器#1）的标识。

当客户端接收到ECU#1发回的消息，从挂起列表中移除ECU#1。这部分知识，在功能通信中详细介绍（6.3.5.2.1）

挂起列表为空

 

知识点：

• 步骤e
  1. 增强时序请求由服务器发出
• 步骤 g，重启计时器，使用增强时序参数
  1. 服务器可以多次发送增强响应时序请求，每次增强响应时序，都会导致客户端与服务器重启计时器。
  2. 增强时序强求不止演示的这一种
  3. 增强响应时序后，时序参数为P2*CAN_Client、P2*CAN_Server
• 右侧步骤
  1. 客户端必须确认接收到的消息由ECU#1发出，才会结束客户端计时器。如果接收到的消息不是由ECU#1发出，客户端会重启计时器。

 

##### 6.3.5.1.3 非默认会话期间的物理通信

 

注意：下面时序图中，请求都是诊断请求，也就是非默认请求

 

6.3.5.1.3.1 功能寻址的TesterPresent(3E hex)消息

图5以图形化的描述了在非默认会话(例如programmingSession)中执行物理通信时客户端和服务器端的时序处理，并使用一个功能性寻址、周期性传输的TesterPresent (3E hex)请求消息，该请求消息不需要来自服务器的响应消息。

 

P2CAN_Client和P2CAN_Server时序的处理与6.3.5.1.1和6.3.5.1.2中描述的处理相同。唯一的例外是客户端上的重载 值和服务器发送最终响应时间的结果时间可能不同。这是基于转换到的会话不是默认会话，因此使用的是不同P2CAN_Client的值(参见9.2.1中的DiagnosticSessionControl(10 hex)服务，了解如何向客户端报告时序参数)。

图 5——非默认会话期间的物理通信-功能寻址的TesterPresent

 

a 发送DiagnosticSessionControl请求，用于启动非默认会话。DiagnosticSessionControl请求消息是个单帧。

b 客户端收到请求消息发送完成指示。在客户端启动了两个计时器，P2CAN_Client、S3Client

c 服务器收到请求消息完成的指示，这里是单帧。响应时序与6.3.5.1.1相同

d 在P2CAN_Server内，向客户端发回响应。

e响应消息的传输完成在服务器中通过N_USData.con表示。现在服务器启动其S3Server定时器，只要未超时，该定时器将保持已激活的非默认会话为活动状态。客户端有责任确保S3Server定时器在超时前被重置，以保持服务器处于非默认会话中。

f 一旦在客户端中启动S3Client定时器，就会导致在每次S3Client定时器超时 时传输一个功能寻址的TesterPresent (3E hex)请求消息，这并不需要响应消息。

g 根据网络层的N_USData.con指示的TesterPresent（3E hex）请求消息的传输完成，客户端再一次启动S3Client 计时器。这意味着每次S3Client超时，都要发送功能寻址TesterPresent（3E hex）请求消息

h 每次服务器需要处理诊断服务，都会停止其S3Server计时器。

i 当诊断服务执行完成，服务器重启S3Server计时器。这意味着任何诊断服务，包括TesterPresent (3E十六进制)，都会重置S3Server定时器。

j在处理另一个请求消息期间收到的任何TesterPresent (3E hex)请求消息都可以被服务器忽略，因为它已经停止了其S3Server定时器，一旦正在进行的服务被完全处理后将重新启动它。

 

知识点

• 步骤 a
  1. DiagnosticSessionContro诊断服务，具体描述见ISO 14229
• 步骤 b
  1. 这里S3Client的启动条件对应的是表4 S3Client 初始开始第一列
• 步骤 e
  1. S3Server 的初始开始
  2. 客户端有责任确保S3Server定时器在超时前被重置
• 步骤 h
  1. S3Server计时器的停止。这部分在表4中的S3Server 后续停止中规定了。
• 步骤f
  1. S3Client超时 时会自动重启
• 步骤g、h、i
  1. 无需响应的请求消息的完成，会重启S3Server计时器。这部分在表4中的S3Server 后续开始中规定了。
  2. 任何诊断会话的完成，都会重启S3Server定时器。
• 步骤j
  1. 客户端、服务器同时处于发送和接收状态
  2. 服务器忽略TesterPresent (3E hex)请求
• S3系列时序参数用于非默认会话

 

6.3.5.1.3.2 物理寻址的TesterPresent(3E hex)消息

 

图6中以图形化的描述了在非默认会话（例如：programmingSession）中执行物理通信时客户端和服务端的时序处理，并使用一个物理性寻址TesterPresent（3E hex）请求消息，该消息需要服务器的响应消息以保持诊断会话活跃，在没有任何其他诊断服务的情况下。

区别在于S3Client计时器启动位置不同。

这里的TesterPresent需要响应

图 6——非默认会话期间的物理通信-物理寻址的TesterPresent

a发送DiagnosticSessionControl请求，用于启动非默认会话。

B请求消息传输完成，请求消息是个单帧消息。它的完成在客户端中通过N_USData.con指示。

c服务器收到请求消息完成的指示，这里是单帧。响应时序与6.3.5.1.1相同

d 对于给定的图，假定客户端需要服务器响应。服务器将传输DiagnosticSessionControl (10 hex)积极响应消息

e DiagnosticSessionControl (10 hex)积极响应消息的传输完成，服务器启动S3Server计时器，在超时前保持被激活的非默认会话活跃。在客户端，接收到DiagnosticSessionControl (10 hex)积极响应消息。这造成S3Client的启动。客户端需确保S3Server计时器超时后的重设以保持服务器在非默认会话中。

f 客户端传输请求，造成S3Client计时器的停止

g每次服务器需要处理诊断服务，都会停止其S3Server计时器。

h 响应消息传输完成，重启S3Client、S3Server计时器

i 如果客户端在S3Client超时之前没有发送任何诊断请求消息，那么S3Client定时器超时将导致客户端发送一个物理寻址的TesterPresent (3E十六进制)请求消息。

j 收到请求消息，停止其S3Server计时器

k TesterPresent (3E hex)响应消息传输完成，重启S3Client、S3Server计时器

 

知识点：

• 物理寻址时，S3Client时序参数启、停条件
• 步骤 b
  1. 物理寻址的DiagnosticSessionControl请求消息，在客户端中不会导致S3Client定时器(会话定时器)的启动。具体参考表4
• 步骤e
  1. 物理寻址的DiagnosticSessionControl响应完成，会让S3Client、S3Server计时器启动。
• 步骤 f
  1. 这里传输的任何请求都会导致S3Client计时器停止
• 步骤 i
  1. S3Client超时 时，会导致客户端发送一个物理寻址的TesterPresent (3E十六进制)请求消息。与上一个图不同的是，这里需要完成响应才会让S3Client响应
• 步骤e、h、k
  1. 此处任何请求的响应完成，都会让S3Client、S3Server计时器启动。

6.3.5.2 功能通信

一个客户端与多个服务器通信

6.3.5.2.1 默认会话期间的功能通信

图7图形化地描述了在默认会话期间客户端和两个(2)服务器对一个功能性寻址请求消息的时序处理。从服务器的角度来看，与物理寻址请求消息相比，时序处理没有区别，但客户端时序处理与物理通信不同。

图7——默认会话期间的功能通信

a 客户端的诊断应用开始传输一个功能寻址请求消息，通过向网络层发送一个N_USData.req。网络层传输此请求到服务器。一个功能寻址的请求消息只能是单帧消息。

b客户端被指示 请求消息的完成，通过 N_USData.con。当接收到N_USData.con，客户端启动P2CAN_Client计时器，使用默认的重载 值 P2CAN_Client。跟物理通信一样，P2CAN_Client计时器的值要考虑由车辆网络设计引起的延迟（跨网关通信、总线带宽等）。为简单起见，该图假设客户端和服务器位于同一网络上。

c 请求消息的完成，在服务器端通过N_USData.ind指示。

d 功能寻址的服务器接收到N_USData.ind 后需要在P2CAN_Server 内开始响应消息。因此，对于多帧响应消息，首帧要在P2CAN_Server 内发送；对于单帧响应消息，单帧要在P2CAN_Server 内发送。

e 在多帧响应消息的情况下，任何服务器发回的首帧的接收，在客户端通过网络层N_USDataFF.ind指示。单帧响应消息由N_USData.ind指示。

f当接收到的响应消息是 首帧、单帧 指示的时，如果客户端知道预期响应的服务器，且所有服务器都响应了，它停止它的P2CAN_Client。或者重启它的P2CAN_Client计时器，当并不是所有预期的服务器都已响应，或者客户端不知道预期响应的服务器(客户端等待进一步响应消息的开始)。客户端的网络层将生成最终的N_USData.ind ，如果接收到完整的消息或在接收过程中发生错误。在客户端接收到多帧 消息最后的N_USData.ind 不会对P2CAN_Client计时器有任何影响

g 响应消息的传输完成也会在服务器通过N_USData.con指示。

 

知识点：

• 步骤a
  1. 一个功能寻址的请求消息只能是单帧消息。
• 步骤c
  1. 有两个服务器
• 步骤d
  1. 多个服务器响应消息，会牵扯到仲裁
• 步骤e
  1. P2CAN_Client的重启与停止
  2. 客户端知道server需要返回response并且所有servers都返回了时，停止P2CAN_Client。不是所有servers都返回响应了时,重启P2CAN_Client；不知道server是否需要返回时，重启P2CAN_Client。

 

 

##### 6.3.5.2.2在默认会话期间使用增强响应时序进行功能通信

图8图形化地描述了在默认会话期间客户端和两个(2)服务器对一个功能性寻址请求消息的时序处理,其中一个服务器通过一个响应码为 78 hex的消极 响应消息请求增强响应时序。

从服务器的角度来看，与需要增强响应时序的物理寻址请求消息相比，时间处理没有区别，但客户端处理时序的方式与物理通信不同。

图 8 默认会话（增强响应时序）下的功能通信

a 客户端发送功能寻址的请求消息

b 请求消息传输完成，客户端启动P2CAN_Client计时器

c 请求消息接收完成，服务器启动P2CAN_Server计时器

d 当存在某个服务器不能在P2CAN_Server内发回响应时，此服务器可以请求增强响应时序窗口

e 客户端内部接收到否定响应消息后，客户端网络层生成一个N_USData.ind。接收到响应码78 hex的消极响应消息会导致客户端重新启动其P2CAN_Client计时器，使用增强的重载 值P2*CAN_Client。此外，客户端应该在挂起响应消息的列表中存储一个服务器标识。一旦在客户机中存储为挂起的服务器以其最终响应消息(积极或消极响应消息，包括一个不是78 hex的响应代码)开始，它将从挂起响应消息列表中删除。当没有要来的响应消息挂起时，客户端将为其P2CAN_Client计时器重新使用默认的重载值。为简单起见，图中只显示了一条否定响应消息，来自服务器#1的其中包含响应代码78 hex。

f 只要在客户端中至少有一个服务器存储为挂起状态，任何来自请求所寻址的任何服务器的进一步响应消息的启动都将导致重新启动P2CAN_Client定时器，使用增强的重载值P2*CAN_Client。(在图9中，显示为当客户端接收到第二个服务器响应的消息时) 。

g 服务器应在P2*CAN_Server内发送响应消息，如不能，可以再次请求增强响应时序窗口。如果请求增强响应时序窗口的服务器已经保存在客户端的挂起列表中，那这个请求不会对客户端的挂起列表产生影响。

h 客户端接收到多帧响应消息的首帧的指示，并根据预期的响应服务器决定对P2CAN_Client计时器的处理。

i网络层将生成最终的N_USData.ind ，在以下情况：接收到多帧响应消息完全被接收或在接收过程中发生错误。在客户端接收到多帧 消息最后的N_USData.ind 不会对P2CAN_Client计时器有任何影响。此外，如上所述的挂起响应消息列表的处理也适用。

j 服务器接收到传输完成的指示。

 

知识点：

• 步骤e
  1. 往挂起响应消息列表增加项目
  2. 增强响应时序会导致客户端计时器使用增强重载值P2*CAN_Client
• 步骤 f
  1. 客户端判断有预期响应的服务器没有发回响应是通过挂起列表吗？
  2. 挂起列表中存在服务器，其它任何服务器发回的响应都将导致重新启动P2CAN_Client定时器
• 步骤h
  1. 移除挂起响应消息列表的项目

 

6.3.5.2.3 非默认会话期间的功能通信

 

图9图形化地描述了在默认会话期间客户端和两个(2)服务器对一个功能性寻址请求消息的时序处理,其中一个服务器通过一个响应码为 78 hex的消极 响应消息请求增强响应时序。

图9 非默认会话期间的功能通信

6.3.5.3 客户端请求消息最短间隔时间

 

20210602更新。

例如，为了允许在服务器中进行轮询驱动的服务数据解释，需要定义客户端发送的请求消息之间的最短时间。 服务器可以根据其正常功能以一定的调度速率（例如10毫秒）处理诊断请求消息。 诊断服务数据解释调度程序的时间应小于性能要求P2CAN_Server，以便满足6.3.5和6.3.5.1.3.2的服务器要求。

请求消息之间的最短时间的时序参数分为以下两个时序参数。

• P3CAN_Functional：此计时参数适用于任何功能性寻址请求消息，因为如果服务器不支持所请求的数据，则可能不需要响应功能性寻址请求消息。
• P3CAN_Physical：此计时参数适用于任何物理寻址请求消息，当服务器不需要发送响应(suppressPosRspMsgIndicationBit = TRUE)。

在物理通信的情况下，当服务器需要一个响应，客户端将会在最后一个响应消息完成接收后，立即传输下一个请求，因为对请求的响应完成意味着请求被服务器完成处理

图10图形化地描述了在功能性通信过程中可能出现的一个问题示例，即客户端在确定对前一个请求消息所有期望的服务器都做出响应后，立即传输下一个请求。

此场景不仅适用于功能寻址的请求，也适用于客户端不希望接收任何响应消息的物理寻址请求(suppressPosRspMsgIndicationBit = TRUE)。

为了处理所描述的场景，为客户端定义了物理寻址或功能寻址请求消息结束和新的物理寻址或功能寻址请求消息开始之间的最小时间P3CAN_Physical和P3CAN_Functional。

1. P3CAN_Physical的值与物理寻址服务的P2CAN_Server_max相同。此时序适用于任何诊断会话(默认和非默认会话)中的任何物理寻址请求消息，并且在服务器不需要响应的情况下。

客户端中启动P3CAN_Physical计时器，每次在总线上成功传输不需要响应的物理寻址请求消息时，这是在客户端中通过N_USData.con指示的。当客户端想要传输一个新的物理寻址请求消息，在之前的请求已经被处理完成后，那么只有当想要传输物理寻址请求消息的客户端的P3CAN_Physical计时器不再活动时，才允许传输。在客户端想要传输一个新的物理寻址请求消息的时间点，如果P3CAN_Physical仍然是活动的，那么传输将被延迟到P3CAN_Physical超时。

1. P3CAN_Functional的值将会是功能寻址服务的P2CAN_Server_max的最大值，适用于任何诊断会话（默认和非默认会话）中的功能寻址请求消息。

每次在总线上成功传输需要响应或不需要响应的功能性寻址请求消息时（这是在客户端通过N_USData.con指示的），在客户端中启动P3CAN_Functional定时器。当客户端想要传输一个新的功能寻址请求消息，在之前的请求已经被处理完成后，那么只有当想要传输物理寻址请求消息的客户端的P3CAN_Functional计时器不再活动时，才允许传输。在客户端想要传输一个新的功能寻址请求消息的时间点，如果P3CAN_Functional仍然是活动的，那么传输将被延迟到P3CAN_Functional超时。

总结：

• 两种计时器都用于客户端
• P3CAN_Physical只能用于不需要响应的物理寻址请求
• P3CAN_Functional用于需要响应或不需要响应的功能性寻址请求
• 必须在计时器不在活跃后才能发送请求

服务器的要求是，它必须在P2CAN_Server中的开始响应消息(参见7.3)。这意味着服务器的诊断数据解释速率应小于P2CAN_Server。

图 10 关键问题的例子——当过早的传输下一个请求

 

 

f 服务器2是一个缓慢的服务器，它分期解释接收到的请求(诊断服务数据解释率)。在最坏的情况下，对传入请求消息的最后一次检查是在网络层接收功能性寻址请求消息之前。这意味着请求将存储在缓冲区中，并在调度程序下次检查传入请求时最早处理。当服务器#2处理请求时，它确定不需要回答，因为它不支持所请求的信息。如图所示，这将是在服务器#1的响应消息完成之后，甚至在客户端传输的下一个请求消息完成之后。

结论：

服务器2的时序与服务器1的时序对不起，可能会导致服务器2即使收到支持的请求时做出的响应，不会被客户端收到。

图11图形化地描述了客户端的P3CAN_Functional时序处理(基于图10所示的通信场景)。此外，图11展示了在S3Client超时 时，且P3CAN_Functional计时器依然活跃，在客户端中对功能性寻址的TesterPresent (3E十六进制)请求消息的处理（(请求将被延迟到P3CAN_Functional超时后）。

 

 

图11——功能寻址请求消息之间的最短时间（P3CAN_Functional）

 

 

 

b 请求消息的完成在客户端通过N_USData.con指示。客户端启动P2CAN_Client 计时器，以及 P3CAN_Functional计时器。

g 即使客户端已经收到了一个功能性请求消息的所有预期响应消息，它也应该等到P3CAN_Client超时后才被允许发送下一个请求消息。在P3CAN_Client超时时间点，客户端发送下一个请求消息。

 

知识点：

• 请求只能等待P3时序计时器结束后发出
• P3时序计时器只能自己超时结束
• 步骤b
  1. P3CAN_Functional计时器的启动。每次请求发送完成都会启动

图12图形化地描述了客户端的P3CAN_Physical时序处理。该图展示了不需要响应的物理寻址的请求的处理，请求是S3Client超时 时功能寻址的TesterPresent(3E hex)请求消息

图12——物理寻址请求消息之间的最小时间（P3CAN_Physical）

 

b 请求消息的完成在客户端通过N_USData.con指示。客户端此时启动P3CAN_Physical 计时器。没有响应需要传输，因此客户端不需启动P2CAN_Client计时器。

f 这里假设P3CAN_Functional计时器在这个时间点没有激活，请求可以立即发出。

h 请求消息TesterPresent (3E hex)的接收在服务器通过N_USData.ind指示。在这个时间点，前一个接收到的物理请求依然在服务器挂起（没有走完流程），S3Server计时器也停了。因此接收到的TesterPresent (3E hex) 请求消息会被服务器忽略。

知识点

• 步骤f
  1. 功能寻址的请求不受P3CAN_Physical 计时器限制

6.3.5.4 未被请求的响应消息

 

未经请求的消息是由服务器基于周期调度程序(参见9.3.4中的service ReadDataByPeriodicIdentifier)或配置的触发器传输的，例如DTC状态的改变或dataIdentifier值的改变(参见9.2.8中的service ResponseOnEvent)。

 

任何未经请求发送的响应消息不得重置服务器上的S3Server定时器

 

6.3.6 错误处理

 

表7 客户端错误检测

通信阶段	客户端错误类型	客户端处理
		物理通信	功能通信
请求传输	网络层传来的N_USData.con带有一个消极结果值	客户端应重复最后一个请求，时间为错误指示之后的P3CAN_Physical后。   重启S3Client，在物理寻址并循序传输TesterPresent的情况下(因为S3Client由于请求消息传输而停止)	客户端应重复最后一个请求，时间为错误指示之后的P3CAN_Functional后。
P2CAN_Client P2*CAN_Client	超时	客户端应重复最后一个请求。   重启S3Client，在物理寻址并循序传输TesterPresent的情况下(因为S3Client由于请求消息传输而停止)	如果客户机不知道服务器响应的数量，那么这就表明客户端不期望有更多的响应消息。不需要重试请求消息。 客户端应该完全接收所有正在进行的响应消息，直到它可以继续进一步的请求。
			如果客户机知道响应服务器的数量，那么这就告诉客户机不是所有预期的服务器都响应。 客户端重复最后一个请求，在接收到错误发生的时间点的全部响应消息的指示后。
响应接收	网络层传来的N_USData.ind带有一个消极结果值	客户端应重复最后一个请求。   重启S3Client，在物理寻址并循序传输TesterPresent的情况下(因为S3Client由于请求消息传输而停止)	客户端重复最后一个请求，在接收到错误发生的时间点的全部响应消息的指示后。
定义的客户端错误处理最多应执行两(2)次，这意味着服务请求传输的最坏情况是三(3)次。

 

 

表8 服务器错误处理

通信阶段	服务器错误类型	服务器处理
请求接收	网络层传来的N_USData.ind带有一个消极结果值	重启S3Server计时器(因为它被 之前接收到的FirstFrame 关闭了)。服务器会忽略这个请求
P2CAN_Server P2CAN_Client P2*CAN_Client	超时	N/A
响应传输	网络层传来的N_USData.con带有一个消极结果值	重启S3Server计时器(因为它被 之前接收到的FirstFrame 关闭了)。服务器不会重新传输这个响应消息。