车载诊断标准-中文 - 图文

ISO 15765-3（2004）

道路车辆——控制局域网络诊断——

第3部分：

一元化诊断服务实施（CAN的UDS）

道路车辆——控制器局域网（CAN）的诊断—— 第3部分：

一元化诊断服务实施（CAN的UDS）

1 范围

这部分ISO 15765协议按照ISO 14229-1，描述了在ISO 11898定义的控制器局域网中统一诊断服务（UDS）的实施。它给所有汽车连接至CAN网络服务器及外部测试设备提供诊断服务及服务器存储器编程的需求。它对汽车内部CAN总线架构无任何要求。

2 参考的标准

下述的参考文档对于该文档的应用是必不可少的。

3 术语，定义和缩略词

为编撰该文档目的，这些术语和定义已在ISO 14229-1，ISO 15765-1及ISO 15765-2中给出，以下缩略词术语同样适用。 DA 目标地址 ID 标识符 DLC 数据长度码 GW 网关 LSB 最低有效位 MSB 最高有效位 NA 网络地址 SA 源地址 SM 子网掩码 TOS 服务类型

4 协定

该部分ISO 15765协议基于ISO 14229-1的协定，该协议遵从使用到诊断服务的OSI服务协议。

5 统一诊断服务（UDS）对照OSI模型的应用

见图1

6 应用层及会话层

6.1 应用层服务

该部分ISO 15765协议使用ISO 14229-1的客户机-服务器式的应用层服务。该系统具有测试、检测、监视，诊断及汽车服务器在线编程的功能。

6.2 应用层协议

该部分ISO 15765协议使用ISO 14229-1应用层协议。

6.3 应用层诊断会话管理定时

重要——任何一个服务器端产生的不等于N_OK的N_USData.indication的指示服务，服务器应用层都不应该有一个应答信息。

6.3.1 概况

下述的是应用层及会话层的定时参数及它们如何在客户机-服务器模式中如何处理的。

诊断层ISO 14229统一诊断服务（UDS）ISO 15765-3统一诊断服务实施ISO 15765-2CAN诊断网络层ISO 11898-1数据链路层及物理信号用户定义例如：11898-1或-2物理插接口

图1 OSI模型中，基于CAN的UDS实施

下述的几种通信会话方式需区别开：

a) 物理的通信在如下期间 1） 默认会话方式

2） 非默认的会话方式——需进行会话处理 b) 功能的通信在如下期间 1） 默认的会话方式

2） 非默认的会话方式——需进行会话处理

所有的情况下，请求服务器否定应答信息的扩展的定时应答，包括应答码78hex应当予以考虑。

定义在ISO 15765-2的网络层主要是处理客户机-服务器的应用层及诊断会话管理的定时。

6.3.2 应用层定时参数定义

用于默认的诊断会话的应用层定时参数值应按照如下表2设置

表2——默认会话的应用层定时参数定义 定时参数 描述 成功发送请求信息（通过N_USData.con应答指示）到接收答复信息开始（多帧信息的N_USDataFirstFrame.ind和单帧信息的N_USData.ind）的超时设置 接收到应答码为0x78的否定应答（通过N_USData.con指示）到接收答复信息开始（多帧信息的N_USDataFirstFrame.ind和单帧信息的N_USData.ind）的扩展的超时设置 在接收到请求信息（通过N_USData.ind指示），服务器开始答复信息的运行要求 在传递了0x78（扩展的超时设置）的否定应答码（通过N_USData.con指示），服务器开始答复信息的运行要求 客户机成功发送不需应答的物理地址请求信息（通过N_USData.con指示），到它能发送下一个物理地址请求信息等待的最小时间（见图6.3.5.3） 类型 定时器 重载值 最小值 最大值 a N/A P2CAN_ClientP2CAN_Server_max??P2CAN*P2CAN_Client 定时器 重载值 *P2CAN_Server_max_rsp??P2CANb N/A P2CAN*P2CAN_Server 运行 要求 运行 要求 0 50ms _Server 0 c5000ms P2CAN_Client_Phys 定时器 重载值 P2CAN_Server_max N/Ad P2CAN_Client_Func 客户机成功发送功能地址请求信息定时器 （通过N_USData.con指示），到它重载值 能发送下一个功能地址请求信息等待的最小时间，有可能不需应答也有可能该请求数据只被某个子网功能地址服务器支持（见图6.3.5.3） P2CAN_Server_max N/Ad a 客户机等待一个应答信息发送的最长时间由客户机决定，但必须满足P2CAN_Client必须比指定的P2CANb _Client最小值要大； *值由客户机决定，但必须满足该值必须比指定的P2CAN*P2CAN_Client_Client最小值要大； c 扩展的应答定时，在连续的应答码为0x78的否定应答信息之间最小值为1*为±20％的P2CAN2*P2CAN_Server，最大容差_Server； d 客户机发送下一个请求的最长等待时间由客户机决定，但必须满足非默认会话的S3Server定时在服务器一直保持运行。 ?P2CAN参数被认为是所有系统网络设计参考延时，该延时通过网关及总线带宽加上安全系数（例如最坏情况的50％）。最坏情况（客户机-服务器-客户机信息传输一个来回的必须

得传送时间），基于系统的设计，并受以下因素的影响： a) 包含网关的数量

b) CAN帧发送的时间（波特率） c) CAN总线的使用情况

d) CAN设备驱动使用方法（轮询方式还是中断方式）及网络层的处理时间

?P2CAN分为两个时间，一是客户机发送请求至服务器的时间，一是服务器发送应答至客户

机的时间。

?P2CAN??P2CAN_Req??P2CAN_Rsp

图2展示的是?P2CAN组成的一个例子。

图2 ——?P2CAN组成的一个例子——单帧请求和应答信息

注意：为了简单描述定时参数，在以下所有的图中，假定客户机到服务器在同一个网络中。所有的说明及附图按照时间顺序表述。

6.3.3会话层定时参数定义

当诊断会话而不是默认的会话启动的时，需要按如下表3的会话层定时参数进行会话的操作。

表3——会话层定时参数定义 定时参数 说明 断会话的信息请求之间的时间，而不是多服务器的默认会话时间（功能的通信），或者对某一具体服务器发送请求最大时间间隔。（物理的通信）。 类型 推荐超时 ms 超时 ms 4000ms S3Client 在功能地址（0x3E）由客户机发送的用于保持诊时间重置值 2000ms S3Server 在没有接收到任何请求信息时，服务器保持诊断时间重置值 N/A 会话的时间，不是默认会话活动时间。 5000ms 而且，服务器转变到非默认会话时，应当改变它的应用层定时参数P2CAN*P2CAN_Client_Server和

，以完成适用于诊断会话的操作。非默认的诊断会话适用的定时参数在诊断会

话控制应答信息中报告，当一个应答需要传递（见图9.2.1服务说明）或需要提前通知客户不传递任何应答信息时。当客户机启动功能的非默认会话时，它应当调整响应的服务器的定时参数。

表4定义了客户机和服务器开启/重启的S3Client/S3Server定时条件。对于客户机，周期性发送功能地址（0x3E）请求信息，应当与连续地发送物理地址（0x3E）请求信息区别开，后者仅仅在没有其它任何诊断请求时发送。对于服务器，不需要这两种（0x3E）的操作方式。表4说明S3Server定时器操作是基于网络层服务的，也就是说，S3Server定时器在接收到不支持的诊断请求信息时，重启。

6.3.4 客户机和服务器定时器资源要求

对于客户机及服务器在默认会话及任何非默认会话完成上述时间定时的定时器资源要求应按照表5及6所示。在非默认会话期间，表6所示附加的定时器资源要求适用于客户机及服务器。

表4 ——客户机及服务器的会话层定时启动/停止条件 定时 参数 动作 物理和功能通信， 使用功能地址， 周期性发送请求信息 N_USData.con用于指示诊断会话控制（10hex）请求信息的完成。只适用于非默认会话的会话类型。 N_USData.con指示功能地址（0x3E）请求信息的完成，它是在S3Client定时每次到时时发送。 物理通信， 使用功能地址， 连续发送请求信息 若不需应答，N_USData.con指示诊断会话控制（10 hex）请求信息的完成。 若需一个应答，N_USData.ind指示诊断会话控制（10 hex）请求信息的完成。 若不需应答，N_USData.con指示诊断会话控制任何请求信息的完成。 若需一个应答，N_USData.ind指示诊断会话控制任何请求信息的完成。 N_USData.ind在接收到多帧应答信息时，指示出错。 S3Client 初始化 开始 随后的 开始 S3Server 初始化 开始 如果需要一条应答信息被传送的话，N_USData.con指示诊断会话控制应答信息的完成，表示从默认会话转变为非默认会话。 如果不需应答。成功地完成请求的服务，该请求为诊断会话控制（10 hex）请求信息要求从默认会话转变至非默认会话， 随后的 结束 随后的 开始 N_USDataFirstFrame.ind指示多帧请求信息开始，N_USData.ind表示任何一个单帧请求信息的接收。如果使用默认会话，S3Server被禁用。 如果需要一条应答信息被传送的话（包括肯定及否定应答），N_USData.con指示任何应答信息的完成，确定一条服务的执行（最后回复信息）。否定应答应答码0x78不会重启S3Server。 如果不需要任何应答信息（肯定或否定），请求动作的完成（服务结束） N_USData.ind指示接收多帧请求信息时的出错。 当请求发送未被请求的信息，如基于某一事件的周期性数据及应答，见6.3.5.4服务器关于S3Server更多的处理。 表5——默认会话下定时器资源要求 定时参数 客户机 服务器 P2CAN_Client为每一个逻辑通信通道（物理和功能通信）N/A 设置一个单独的定时器是需要的，例如，点对点通信需要一个独立的通信通道。 N/A 为扩展的应答定时一个可选择的定时器保证随后的否定P2CAN_Server *应答的发送比P2CAN_Server早一些。 P2CAN_Physical 需为每一个物理通信口提供单独的定时器 P2CAN_Functional 需为每一个功能通信口提供单独的定时器

表6——非默认会话下另外的定时资源需求 定时参数 客户机 当使用周期性发送，功能地址（0x3E）请求信息保持服务器在非默认状态，需提供单独的定时器，不需为每一个激活的诊断会话提供额外的定时器。 当在无其它诊断请求时，使用连续的发送物理地址（0x3E）请求信息保持单个服务器在非默认状态，为每一个点对点通信通道设置单独的定时器 N/A N/A 服务器 N/A S3Client S3Server N/A 服务器需一个单独的定时器，因为只有单诊断会话能在一个服务器中激活。 6.3.5具体的定时参数描述 6.3.5.1物理通信

6.3.5.1.1默认会话下物理通信

图3描述了客户机和服务器在默认会话下物理地址请求信息定时的操作。

图3——默认会话下物理通信

a) 客户端诊断应用层通过发送N_USData.req到网络层开始发送请求信息。网络层传递该请求信息至服

务器。该请求信息要么以单诊的形式或多帧的形式。

b) 在多帧信息情况下，请求开始于网络层发送的N_USDataFF.ind通知服务器。

c) 请求信息的完成通过客户机N_USData.con指示。当接收到N_USData.con时，客户端使用默认重载

值为

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指示响应信息的完成。

6.3.5.1.2 默认会话期间扩展了应答定时的物理通信

图4描述了默认会话期间客户机和服务器物理地址请求信息定时操作，及服务器请求扩展的响应定时（否定应答码0x78的处理）。

图4 ——默认会话期间的物理通信——扩展了应答定时

a) 客户端诊断应用层通过发送N_USData.req到网络层开始发送请求信息。网络层传递该请求信息至服

务器。该请求信息要么以单诊的形式或多帧的形式。

b) 在多帧信息情况下，请求开始于网络层发送的N_USDataFF.ind通知服务器。

c) 请求信息的完成通过客户机N_USData.con指示。当接收到N_USData.con时，客户端使用默认重载

值为

P2CAN_Client，启动

P2CAN_Client定时器，该定时器的值应当考虑到车载网络设计上（通信网关，

总线带宽，等）所有的岩石。为了简单化，该图假定客户机和服务器在一条总线上。

d) 服务器通过N_USData.ind指示请求信息的完成。 e) 服务器在接收到N_USData.ind指示时，要求在

帧回复信息条件下，首帧必须在

P2CAN_Server时间内开始回复信息。也就是说，在多

P2CAN_Server时间内发送，对于单帧回复信息，该单帧必须在

P2CAN_Server时间内回复。

f) 服务器在给定的

P2CAN_Server时间内无法提供请求的信息时，它可以通过发送应答码为0x78的否定

应答信息请求扩展的定时窗。客户端接收到否定应答信息时，客户端网络层产生一个N_USData.ind。接收到应答码为0x78的否定应答信息，客户端重置它的

*载的P2CAN_ClientP2CAN_Client定时器，但使用的是扩展的重

定时值。

g) 服务器在发送否定应答信息N_USData.con之后，要求在给定的扩展的

*时间内应答信息。如果在给定的扩展的P2CAN_ServerP2CAN_Server*（P2CAN_Server）

时间内仍无法提供请求的信息，服务器则继续发

送应答码为0x78的否定应答。

*客户端使用的是扩展的重载的P2CAN_Client定时值重置它的

P2CAN_Client定时器。为了简单起见，图中只显示了一个应答码为0x78的否定应答信息。

h) 一旦服务器可以提供请求的信息（肯定的否定的应答，而不是应答码0x78的应答），它就启动最后

结果的应答信息。

i) 在多帧应答信息情况下，客户机通过网络层N_USDataFF.ind指示首帧的接收。当接收到首帧时，客

户机停止

P2CAN_Client定时器。

j) 如果完整的信息接收到，或者在接收过程中出现了错误，网络层最后都产生一个N_USData.ind。在

单帧响应信息，通过单个的N_USData.ind指示单帧的接收。当接收该单帧指示时，客户端停止

P2CAN_Client定时器。

k) 服务器通过N_USData.con指示响应信息的完成。

6.3.5.1.3 非默认会话期间的物理通信 6.3.5.1.3.1 功能地址（0x3E）信息

后结果N_USData.ind。对多帧信息的最后一个N_USData.ind不对P2CANg) 服务器通过N_USData.con指示应答信息发送的完成。、

_Client定时器产生影响。

6.5.3.2.2默认会话期间扩展应答定时的功能通信

图8描述了默认会话期间客户机与2个服务器功能地址请求信息的定时操作。这里一个服务器通过应答码为0x78的否定应答请求一个扩展的应答定时。从服务器角度看，这与物理地址请求信息的定时处理没什么区别。但是客户机对定时的处理就与物理通信不同。

图8——默认会话期间功能通信——扩展的应答定时

a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送功能地址请求信息。网络层传递该请求

信息至服务器。功能地址请求信息只能是单帧信息。 b) 客户机通过N_USData.con指示请求信息的完成。当接到N_USData.con时，客户机启动P2CAN定时器，使用默认的重置值P2CAN_Client_Client。该定时器的值应当考虑到车载网络设计上（通信网关，总

线带宽，等）所有的延时。为了简单化，该图假定客户机和服务器在一条总线上。 c) 服务器通过N_USData.ind指示请求信息的完成。 d) 功能地址服务器在接收到N_USData.ind后，要求在P2CAN在多帧回复信息条件下，首帧必须在P2CAN_Server_Server时间内发送应答信息。也就是说，

时间内发送，对于单帧回复信息，该单帧必须在

时间内无法提供请求的信息时，它可以通过

P2CAN_Server时间内回复。服务器在给定的P2CAN_Server发送应答码为0x78的否定应答信息请求扩展的定时窗。

e) 客户端接收到否定应答信息时，客户端网络层产生一个N_USData.ind。接收到应答码为0x78的否

定应答信息，客户端重置它的P2CAN_Client*定时器，但使用的是扩展的重载的P2CAN_Client定时值。

并且，客户端应当在挂起应答信息列表存储一个服务器标识。一旦在存储在客户端挂起的服务器开始它最后结果应答信息（肯定或否定应答信息包括应答码为0x78的应答），它将从挂起应答信息列表中删除。当无任何应答信息挂起时，客户端重新为P2CAN_Client使用默认的重载值。为简单化，图

中，显示了从服务器#1的仅一个应答码为0x78的否定应答。

f) 只要至少有一个服务器在客户机端挂起时，从任一服务器端任何进一步的应答信息，都会促使

P2CAN_Client*定时器使用扩展的值P2CAN_Client重启（见图9，该图显示了当客户机接收到第二个服

务器应答信息开始的情况）。

g) 至于物理的通信，服务器请求扩展的应答定时要求在扩展的时间P2CAN_Client*（P2CAN_Client）内，

应答信息。一旦服务器能提供请求的信息，它就通过发送N_USData.req至网络层开启最后结果应答

*信息。如果服务器仍然不能在扩展的P2CAN_Client时间内

提供请求的信息，它将继续发送应答码为

定时器，使用扩展的重载值

0x78的否定应答信息。这会促使客户机再次重启P2CAN_Client*P2CAN_Client。已经存储在客户端挂起应答信息列表中，服务器端包含应答码为0x78的否定应答信

息不影响客户端该信息列表。

h) 如6.3.5.2.1，在多帧应答信息情况下，从任一服务器端接收的首帧，客户机都是通过网络层

N_USDataFF.ind指示的。单帧应答信息通过N_USData.ind指示。当接收到首帧/单帧指示接下来的

应答信息，客户端要么知道服务器即将应答或已经应答过了，则停止P2CAN_Client，要么不是所有服

。

务器应答或它不知道服务器即将应答（客户机等待进一步的应答信息）时，重启P2CAN_Clienti) 如果完整信息接收到或者在接收过程中产生了一个错误，网络层产生最后结果N_USData.ind。这对

P2CAN_Client定时器不影响。而且适用挂起应答信息列表的处理。

j) 服务器通过N_USData.con指示完成发送。

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

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

图9描述了非默认会话期间客户机与2个服务器功能地址请求信息的定时操作。这里一个服务器通过应答码为0x78的否定应答请求一个扩展的应答定时。从服务器角度看，

a) 客户端诊断应用层通过发送N_USData.req至网络层开始功能地址诊断会话控制（0x10）的发送。网

络层传递该请求信息至服务器。请求信息是单帧。 b) 客户端通过N_USData.con指示请求信息的完成。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。

除此之外，客户端产生的N_USData.con促使S3Client定时器开启（会话定时器）。

c) 服务器通过N_USData.ind指示请求信息的完成。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。 d) 图上给出，假定客户机需要服务器一个应答。服务器应当发送诊断会话控制（0x10）的肯定应答信

息。 e) 服务器通过N_USData.con指示肯定应答信息发送的完成。然后服务器开启S3Server定时器，只要它

不超时，它就一直处于非默认状态。客户机负责保证S3Server定时器在它超时之前复位，以保证服务器处于非默认会话状态。

f) 一旦客户机开启了S3Client定时器，这会促使不需应答信息的功能地址（0x3E）请求信息的发送。

每一次发送的时机都是在S3Client超时时发送。

g) 在网络层通过N_USData.con指示（0x3E）请求信息传递完成之后，客户机再次启动S3Client定时器。

这就是说，功能地址请求信息是在每一次S3Client定时超时之后，周期性发送的。 h) 服务器在处理诊断服务的任何时间内，它都停止S3Server定时器。

i) 当诊断服务处理完之后，服务器重启S3Server定时器。这就是说，诊断服务，包括（0x3E），都重置

S3Server定时器。诊断服务是在接收到请求信息（N_USDataFF.ind或者N_USData.ind服务）与完成

最后结果应答这个期间内处理的。这里是需要一条应答信息的。或者请求然后诊断服务动作的完成

不需要任何应答信息。（及时到达一个点会促使一个应答信息的发送）

j) 所有（0x3E）请求信息，在服务器处理另外一条请求信息期间接收的话，都会被服务器忽略。因为

它已经停止了S3Server定时器，并且在服务处理完之后重启。

P2CAN_Client与P2CAN_Server定时处理与6.3.5.1.1和6.3.5.1.2小节中描述的处理方法

相同。唯一的区别是客户端重置的值及服务器端发送结果应答时间会有不同。这是由于转变到另一会话层而不是使用默认会话层，因此使用的是不同的P2CAN节诊断会话控制（0x10）服务对定时参数更详细的描述。）

_Client的值。（见9.2.1

6.3.5.3 客户机请求信息最小时间

为服务器轮询的服务数据的解读，这对客户机请求信息发送的最小间隔时间有要求的。例如，基于标准的功能，服务器可能处理诊断请求信息以预定的速率（例如10ms）。诊断

服务数据解读预定时间应当比运行要求时间P2CAN_Server短，以满足6.3.5和6.3.5.1.2对

服务器要求。

请求信息间隔时间的最小定时参数分为如下两个定时参数。 ——P3CAN_Functional：该定时参数适用于所有功能地址请求信息，因为它在不支持应答数据

的情况下，服务器不要求响应功能地址请求信息。 ——P3CAN_Physical：该定时参数适用于不需服务器应答的物理地址请求信息。

（suppressPosRspMsgIndicationBit = TRUE）。

物理通信在需要服务器应答的情况下，客户端可以在接收到最后一条应答信息的时候立即发送下一个请求，因为服务器在完成最后结果应答时——意味着该请求已被服务器完全处理完了。

图10描述了功能通信期间出现一个问题的例子。当客户机在它确认所有期望的服务器都对先前做了应答时，立即发送下一个请求信息。

该情景不仅适用于功能地址请求也适用于物理地址请求，这里客户机不需接受任何应答信息（suppressPosRspMsgIndicationBit = TRUE）。

为了处理上述情况，在一条物理或功能地址请求信息与新的物理或功能地址请求信息之间，最小时间P3CANa) P3CAN_Physical_Physical和P3CAN_Functional需要为客户机定义。

_Server_max的值与物理地址的服务器P2CAN的值相同。该定时适用于所有诊断

会话（默认的或非默认的）的所有物理地址请求信息而且所有情况下，都不需要服务器应答。

客户机每次启动P3CAN_Physical定时，都发送一条不需应答的物理地址请求信息到总线上，

并且，网络层通过N_USData.con指示。当客户机在先前请求信息完全处理完之后，想要发送新的物理地址请求信息时，这只有在P3CAN_Physical定时器不处于活动的情况下。

_Physical客户端在发送一条新的物理地址请求信息的时刻，启动P3CAN要等到P3CANb) P3CAN_Physical。然后信息的发送

超时。

_Server_max_Functional的值是所有功能地址服务器P2CAN，所有诊断会话（默认的或非

默认的），所有功能地址请求信息的最大值（最坏情况）。 客户端每次开启P3CAN_Functional定时器，都发送不需应答的功能地址请求信息到总线上，

并且客户端网络层通过N_USData.con指示。当客户机在先前请求信息完全处理完之后，想要发送新的物理地址请求信息时，这只有在P3CAN_Functional定时器不处于活动的情况下。客

_Functional户端在发送一条新的物理地址请求信息的时刻，启动P3CAN到P3CAN_Functional。然后信息的发送要等

超时。

注意：“完全处理完”就是说要么不需应答时没有接收到任何应答，要么所有期待的应答都

接受到了。应答的服务器知道并且要求应答，或者服务器不知道并且要求应答时出现

P2CAN_Client超时。

_Server对服务器的要求是它应当在P2CAN信息的解读时间应当短于P2CAN_Server（见图7.3）时间内应答信息，这就是说，诊断

。

图10 ——发送下一条请求太早的例子

a) 客户端诊断应用层通过发送N_USData.req功能地址请求信息到网络层。网络层传递信息到服务器。 b) 客户端通过NUSData.con只是请求信息的完成。客户机使用默认的P2CAN定时器。

c) 服务器通过N_USData.ind指示请求信息的完成。服务器使用默认的P2CAN_Server_Client值开启P2CAN_Client值开启P2CAN_Server定时器。

d) 对于请求的信息，假定只有服务器#1支持请求信息，也就是说服务器#2不会应答信息。服务器#1

是快速服务器，能很快处理完请求的信息并在P2CAN_Server时间内发送应答信息。

e) 客户机接收到应答信息。这通过N_USData.ind指示。客户机仅仅期待服务器#1的应答信息，因此

它停止P2CAN_Client定时器。

f) 服务器#2是慢速服务器，并且在一段时间内（诊断服务数据解读时间）解读请求信息，最坏的情况

下，在网络层接收到请求信息之前进行了最后一次请求的信息检查。这就是说，请求会存储在一个

缓冲区并且在检查请求信息的例程时执行。当服务器#2处理该条请求时，它确定了它不需要应答，因为它不支持该条请求信息。如图所示，这有可能在服务器#1完成应答信息之后或是在客户机下一条请求信息之后发生。

g) 客户机在所有期待的应答信息完成之后，会立即发送下一条请求。

h) 服务器通过N_USData.ind指示请求信息的完成。但仅仅在快速服务器#1中进行，因为在服务器#2

不处理最近一条信息。

i) 客户机新的请求的完成通过N_USData.con指示。

图11描述了客户机（基于图10说明的通信情况）P3CAN_Functional定时处理。除此之外

_Functional图11显示了客户机功能地址（0x3E）的请求。在S3Client超时且P3CAN求将等待P3CAN

_Functional活动时（请

超时）。

图11——功能地址请求信息间隔时间最小值（P3CAN_Functional）

a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送功能地址请求信息。网络层传递请求只

服务器。 b) 客户端通过N_USData.con指示请求信息的完成。客户机开启P2CAN_Client定时器并且开启

P3CAN_Functional定时器。

c) 服务器通过N_USData.ind指示请求信息的完成。

d) 对于请求的信息，假定只有服务器#1支持请求信息，也就是说服务器#2不会应答信息。服务器#1

是快速服务器，能很快处理完请求的信息并在P2CAN_Server时间内发送应答信息。

e) 客户机接收到应答信息。这通过N_USData.ind指示。客户机仅仅期待服务器#1的应答信息，因此

它停止P2CAN_Client定时器。

f) 服务器#2是慢速服务器，并且在一段时间内（诊断服务数据解读时间）解读请求信息，最坏的情况

下，在网络层接收到请求信息之前进行了最后一次请求的信息检查。这就是说，请求会存储在一个缓冲区并且在检查请求信息的例程时执行。当服务器#2处理该条请求时，它确定了它不需要应答，因为它不支持该条请求信息。 g) 尽管客户机接收到了功能地址请求信息所有期待的应答信息，它仍要等待P3CAN许发送下一条请求信息。在P3CAN_Client_Client超时之后才允

超时的时刻，客户机发送下一条请求信息。

h) 新的请求信息服务器中通过N_USData.ind指示。并服务器#1立即处理，而服务器#2下一次检查请

求信息例程中处理该请求。 i) 客户机通过N_USData.con指示新的请求的完成，并且开启P3CAN_Functional定时器。

j) 对于请求的信息，假定只有服务器#1支持请求信息，也就是说服务器#2不会应答信息。服务器#1

是快速服务器，能很快处理完请求的信息并在P2CAN_Server时间内发送应答信息。

k) 客户机接收到应答信息。这通过N_USData.ind指示。客户机仅仅期待服务器#1的应答信息，因此

它停止P2CAN_Client定时器。

l) 服务器#2是慢速服务器，并且在一段时间内（诊断服务数据解读时间）解读请求信息，最坏的情况

下，在网络层接收到请求信息之前进行了最后一次请求的信息检查。这就是说，请求会存储在一个缓冲区并且在检查请求信息的例程时执行。当服务器#2处理该条请求时，它确定了它不需要应答，因为它不支持该条请求信息。 m) 客户机S3Client定时器超时，促使客户机发送不需服务器应答的功能地址（0x3E）请求信

息。在这种情况下，P3CAN时发送。 n) 当P3CAN_Functional_Functional此时仍然活动着，（0x3E）的发送应当到P3CAN_Functional超时

定时器超时的时候，客户机可以通过N_USData.req发送功能地址（0x3E）请求。

o) 服务器通过N_USData.ind指示（0x3E）请求信息的接收。 p) 客户机通过N_USData.con指示（0x3E）请求的完成，并启动P3CAN_Functional定时器。

图12描述了客户机P3CAN_Physical定时器的操作。该图显示了不需应答的物理地址请求

的发送操作及S3Client超时时功能地址（0x3E）请求信息。

图12——物理地址通信间隔最短时间P3CAN_Physical

a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送物理地址请求信息。网络层传递请求只

服务器。 b) 客户端通过N_USData.con指示请求信息的完成。客户机开启P3CAN答信息，因此，客户机不需要开启P2CAN_Client_Physical定时器。由于不需要应

定时器。

c) 服务器通过N_USData.ind指示请求信息的完成。在任何非默认会话期间，S3Server定时器此刻是停止的。

d) 服务器在一定时期内（诊断服务数据解读时间）解读请求。在下一次检查请求例程中请求被处理。

在非默认会话期间，服务的完全执行会重置S3Server定时器。

e) 客户机S3Client定时器超时，促使客户机发送功能地址（0x3E）请求信息，不需服务器的应答。

f) 假定P3CAN_Functional定时器此时没有活动，也就是说请求被立即发送。

g) 客户机通过N_USData.con指示（0x3E）请求信息的完成。

h) 服务器通过N_USData.ind指示（0x3E）请求信息得接收。此刻，先前接收到的物理请求仍然在服务

器端挂起（还没有处理）并且S3Server定时器停止。因此，接收到的（0x3E）请求信息会被服务器忽略。 i) 当P3CAN_Physical定时器在客户机超时，客户机会通过发送N_USData.req发送下一条物理地址请求

信息至网络层。

j) 客户机通过N_USData.con指示物理地址请求信息的完成。客户机现在重新开启P3CAN器。由于不需应答信息，因此客户端不启动P2CAN_Client_Physical定时

定时器。

k) 服务器通过N_USData.ind指示请求信息的完成。在任何非默认会话情况下，S3Server定时器此刻停

止。

6.3.5.4 主动提供的应答信息

服务器主动提供的应答信息要么是周期性例程（见服务ReadDataByPeriodicIdentifier in 9.3.4）或者配置引发的，例如DTC状态的变化或者一个日期标识的改变（见服务ResponseOnEvent in 9.2.8）。

所有主动提供的应答信息服务器都不应当重启S3Server定时器。这在周期性信息传输或者时间触发的事件中时间的时间间隔比S3Server短的情况下，有效避免了诊断会话的锁死。

S3Server定时器只应当在处理一条请求信息并发送最后结果应答信息（例如，初始肯定应答指示一个请求成功执行）的时候被重置。

6.3.6 出错的处理

应用层以及客户机和服务器在物理通信、功能通信期间的会话管理出错的处理应当按照表7、表8。假定客户机和服务器都按照该部分15765协议进行应用层及会话层的定时处理。

表7——客户机错误处理

通信阶段 请求发送 客户端错误类型 物理通信 客户机处理 功能通信 网络层的客户机在P3CAN_Physical时间之客户机在P3CAN_Physical时间之后，N_USData.con指示否定结果值 后，有出错指示，应当重发最后有出错指示，应当重发最后的请求 的请求 重启S3Client（由于S3Client在请求发送时停止了） 超时 客户机重新发送最近的请求信息。重启S3Client（由于S3Client在请求发送时停止了） 这里客户机不知道多少服务器应答，这就是指示客户机不再有应答信息了。不用再重复请求信息了。 客户机在进一步请求之前，应当完全接受到所有的应答信息。 这里客户机知道有多少服务器应答，这就是指示客户机不是所有的服务器都应答。 客户机在完全接收到所有应答信息之时发生了超时，应当重新请求信息。 P2CAN*P2CAN_Client _Client应答接收 N_USData.ind网络层否定结果值 客户机重新发送最近的请求信息。重启S3Client（由于S3Client在请求发送时停止了） 客户机在完全接收到所有应答信息之时，出错，应当重新请求发送信息。 客户机出错处理运行最多2次，也就是说，最坏情况下，请求服务的发送只能是3次。 表8——服务器出错处理 通信阶段 请求接收 服务器错误类型 网络层N_USData.ind指示否定结果值 超时 _Server处理 重启S3Server定时器（由于它在接收到先前首帧指示时停止了），服务器应当忽略该请求。 N/A P2CAN 网络层N_USData.ind指示否定结果值 重启S3Server定时器（由于它在接收到先前的请求信息时停止了）。服务器不应当重新发送该应答信息。 P2CAN*P2CAN_Client_Client应答发送

7 网络层接口

7.1概述

该部分的ISO 15765协议使用ISO 1576502定义的网络层服务进行诊断信息的收发。本节定义应用层协议数据单元（A_PDU）到网络层协议数据单元（N_PDU）的映射。 注意：网络层的服务用语应用层及诊断会话管理的定时。（见6.3）

7.2 流控N_PCI参数定义

客户机Stmin参数不应该使用0xF1-0xF9的值。这些Stmin参数值应汽车制造商要求服务器应当支持。

7.3 信息发送的A_PDU到N_PDU的映射

应用层协议数据单元的参数按照下表9所示映射到网络层协议数据单元。它用于定义客户机/服务器诊断服务信息的请求/应答。

网络层向应用层的(N_USData.con)成功发送确认服务。应用层是需要这项服务，因为它需要在请求/应答完成时立即进行另外的动作（例如ECU重启，波特率调整等）。

表9——ServiceName.request/ServiceName.response A_PDU到N_USData.request N_PDU A_PDU参数（应用层协议数据单元） A_SA A_TA A_Tatype A_RA A_PCI.SI 说明 应用层源地址 应用层目标地址 应用层目标地址类型 应用层远程地址 应用层协议控制信息服务代码 N_PDU参数（应用层协议数据单元） N_SA N_TA N_Tatype N_AE N_Data[0] 说明 网络层源址 网络层目标地址 网络层目标地址类型 网络层地址扩展 网络层数据 A_Data[0]-A_Data[n 应用层数据 N_Data[1]N_Data[n+1 网络层数据 7.4 信息接收的N_PDU到A_PDU的映射

网络层协议数据单元的参数按照下表9所示映射到应用层协议数据单元。用于定义接收到的诊断请求/应答的确认/指示。

网络层对接收到首帧N_PDU (N_USDataFirstFrame.ind)时指示不直接到应用层，因为它仅仅用于应用层定时（见6.3）。因此没有N_USDataFirstFrame.in N_PDU到A_PDU的映射的定义。

表10————N_USData.ind N_PDU到ServiceName.conf/ServiceName.ind A_PDU的映射 N_PDU参数（应用层协议数据单元） N_SA N_TA N_Tatype N_AE N_Data[0] 说明 网络层源址 网络层目标地址 网络层目标地址类型 网络层地址扩展 网络层数据 A_PDU参数（应用层协议数据单元） A_SA A_TA A_Tatype A_RA A_PCI.SI A_Data[0]-A_Data[n 说明 应用层源地址 应用层目标地址 应用层目标地址类型 应用层远程地址 应用层协议控制信息服务代码 应用层数据 N_Data[1]N_Data[n+1 网络层数据 8 标准的诊断CAN标识

8.1 法规OBD的11位CAN标识

法规OBD的11位CAN标识也用于扩展的CAN诊断（例如功能请求CAN标识能用于功能地址（0x3E）请求信息保持非默认会话处于激活状态。）

如果ISO 15765-4说明的11位的CAN标识在扩展的诊断中重新使用，适用如下要求： a) ISO 15765-4协议的网络层定时参数同样适用于扩展的诊断；

b) DLC（CAN数据长度码）应当设置为8并且CAN帧应当包含8字节（未使用的字节也应当填充）；

注意：ISO 15765-4允许最大8OBD相关服务器，为8个服务器定义了11位CAN标识。

8.2法规29位OBD的CAN标识

法规的29位CAN标识应按照ISO 15765-2说明的标准固定的地址格式，同样能用于扩展的诊断。

如果ISO 15765-4说明的29位的CAN标识在扩展的诊断中重新使用，适用如下要求： a) ISO 15765-4协议的网络层定时参数同样适用于扩展的诊断；

b) DLC（CAN数据长度码）应当设置为8并且CAN帧应当包含8字节（未使用的字节也应当填充）；

注意：表中给出的CAN标识符按照ISO 15765-2协议优先级信息使用默认的值。

8.3 扩展的诊断29位CAN标识

8.3.1 概述

本部分说明使用29位CAN标识的标准地址及路由的概念。主要使用了最流行的网络协议（IP）的握手机制。因此地址及路由的算法可用于不同子网位置的节点的通信及路由。 准地址及路由的概念遵循如下的特征： ——网络结构最灵活的设计操作 ——完全定制的网络及节点地址

——CAN控制器硬件过滤特征通过分配合适的网络及节点地址优化。

——网关需要知道与它连接的子网的网络地址，而不需要所有子网成员的地址。

下面描述了CAN标识符结构的技术细节，包括地址，子网掩码。也包括了对路由及广播的算法的详细描述。

8.3.2 29位CAN标识符结构

本文档描述的29位CAN标识符结构与如下协议是兼容的。有ISO 15765-2, ISO 15765-3, ISO 15765-4及SAE J1939-21.因此SAE J1939-21定义的29位CAN标识结构中25位的编码（保留/扩展数据页）和24位编码（数据页）应当确定该CAN标识或CAN帧是J1939的还是ISO 15765的。这对汽车网络设计者根据他的需求及对SAE J1939和ISO 15765协议的使用，定制非诊断的信息及相关CAN标识是重要的。

8.3.2.1 SAE J1939的29位CAN标识符结构

关于SAE J193929位CAN标识符格式见如下表11

表11——SAE J1939的CAN标识符结构

29位CAN标识符 28、27、26 优先级 25 保留/扩展 数据页 24 数据页 23-16 PDU格式 15-18 PDU-特定域（目标地址或PDU格式扩展） 7-0 源地址（独有的源地址） 8.3.2.2 ISO 15765的29位CAN标识符结构

表12显示了ISO 15765的CAN标识符结构与SAE J1939格式的区别。 25位——SAE J1939保留/扩展数据页，ISO 15765使用扩展数据页 24位——SAE J1939数据页 ，ISO 15765数据页

因此，ISO 15765格式与SAE J1939格式的29位CAN标识能在同一个CAN总线上互不影响的共存。

表12——ISO 15765的CAN标识符结构 29位CAN标识 28-26 25 24 23，22 21-11 10-0 优先级 扩展 数据页 服务类型（TOS） 源地址 目标地址 数据页 编码见8.3.2.4 编码见8.3.2.5 源地址（独有的源地目标地址（独有的目址） 标地址） 8.3.2.3 优先级域

SAE J1939定义的优先级域用于CAN总线的仲裁机制。由于CAN标识符不再能自由分配（源地址和目的地址包含在CAN标识符中），CAN信息优先级由发送者分配并间接由接收者分配。存在８种不同的优先级。

优先级６分配至诊断请求信息／帧。

8.3.2.４ 扩展的数据页及数据页域

扩展的数据页及数据页位决定了使用哪一种２９位的CAN标识。见表１３编码的说明

表１３——扩展数据页及数据页域 扩展的数据页位２５ 数据页位２４ 说明 ０ ０ SAE J1939定义或厂家定义的“标准通信信息” ０ １ SAE J1939定义或厂家定义的“标准通信信息” １ ０ SAE J1939定义或厂家定义的“标准通信信息” １ １ ISO 15765定义的 8.3.2.5 服务类型（TOS）域

服务类型域用于表述一个节点不需要分配不同地址的情况下，分配不同项服务。因此，8种不同的服务类型能同时分配给单个的目标地址。不同服务类型的定义见表14

表14——服务类型的定义（TOS） 位23 位22 服务类型（TOS） 说明 0 0 ISO保留 该位组合为ISO为将来保留 0 1 OEM-定义的信息 该位组合指示信息为OEM特定的，ISO 15765-3及以前的协议信息能通过相同的网络但不同的协议信息混合使用在一个服务器上。 1 0 网络控制信息 协该位组合指示帧包含的网关收发数据用于支持当前子议/网络管理 网状态的信息（例如，网络无法到达/网络超载）和节点信息（例如，主机无法到达） 1 1 ISO 15765-3定义该位组合包含了节点ISO 15765定义的诊断服务。CAN的 信息 帧用户数据字节包括诊断请求（ISO 15765-3）使用网络层服务及ISO 15765-2定义的传输层 8.3.2.6 源地址

源地址包含发送实体地址。该信息保证了正确仲裁以及被接收者用于回复信息。源地址结构见8.3.3描述。

8.3.2.7 目标地址

目标地址包含接收实体的地址信息。这应是一单独节点，广播地址或通用广播。网关使用目标地址决定CAN帧是否应当路由到另外一条CAN总线上。该目标地址结构见8.3.3所述。

8.3.3地址结构

8.3.3.1概述

目标地址及源地址都编码在29位CAN标识符中，并且每个长度为11位。如下所示，字母“X”和“Y”代表可变参数。

8.3.3.2地址的定义

一个地址包含两个部分 a) 网络地址

网络地址部分包含第一个连续的位“X”地址并且决定了一个节点所在的网络。同一物理总线上的节点应当分配同一个网络地址。网络地址部分不应当将所有的位置为1.因此，最小的网络地址长度应为2个位。最大长度应为9个位因为因为至少需要2个位提供固定节点地址。最大的子网数量可根据如下计算：

2X?1（X代表使用到网络地址的位的个数）

b) 节点地址

节点地址部分包含了地址中剩下的连续的位“Y”（Y=11-X），并决定了子网中具体的节点。在子网中应当是独有的。所有的位都置位0或1是不允许的。所以最小节点地址长度为2个位，最大为9个位。子网中最多节点个数根据如下公式计算：

2Y?2（Y代表使用到节点地址的位的个数）

分配给节点独有的地址应当存储在节点的内部存储器中。一个节点接收目标地址域为该节点地址的的信息。

表15展示了源地址和目标地址的一个例子。发送及接收节点不在同一个子网中。

表15——源地址和目标地址的一个例子 29位CAN标识 28 27 26 25 24 23 22 21 11 优先级0x6 ISO 15765格式 服务类型ISO 15765信息 1 1 0 1 1 1 1 0 1 0 1 1 1 0 1 1 0 1 0 1 1 0 0 1 0 1 1 1 1 源地址 0x2ED 10 0 目的地址 0x32F 8.3.3.3 子网掩码

子网掩码为网络地址及节点地址分配。 子网掩码长度为11位（与地址长度一致）。子网掩码的值通过设置开始连续的位“X”为1分配。将网络地址部分设置为1，将节点地址的部分设置为0.（见表16和表17发送与接收者的子网掩码的例子）

由于固定的子网掩码长度及一开始的连续的位“X”设置为1，只有这些位置位1而不是所有位。因此需要一个短记号定义子网掩码。

表16——发送端子网掩码例子 子网掩码 10 9 8 7 6 5 4 3 2 1 0 0X7C0(短的记号/5) 网络地址部分 节点地址部分 1 1 1 1 1 0 0 0 0 0 0 表17——接收端子网掩码例子 子网掩码 10 9 8 7 6 5 4 3 2 1 0 0X7C0(短的记号/5) 网络地址部分 节点地址部分 1 1 1 1 1 1 0 0 0 0 0 每一个分配子网掩码的节点都应当存储在它内部存储器内。相同子网的节点分配相同的子网掩码。

8.3.3.4 网络地址

节点的网络地址现在可以通过分配地址及子网掩码计算出来。见表18和19发送者和接收者的例子决定了网络地址。

表18——发送者网络地址 源地址 位 10 9 8 7 6 5 4 3 2 1 0 地址：0x2ED 0 1 0 1 1 1 0 1 1 0 1 子网掩码：/5 1 1 1 1 1 0 0 0 0 0 0 网络地址：0x2C0 0 1 0 1 1 0 0 0 0 0 0

表19——接收者网络地址 源地址 位 10 9 8 7 6 5 4 地址：0x32F 0 1 1 0 0 1 0 子网掩码：/6 1 1 1 1 1 1 0 网络地址：0x320 0 1 1 0 0 1 0 为了描述子网掩码，网络地址及子网掩码按如下形式记录： <网络层地址>/<短的子网掩码记录> 实例：

发送端子网：0x2C0/5 接收端子网：0x320/6 该信息被网关用来路由。

3 1 0 0 2 1 0 0 1 1 0 0 0 1 0 0 8.3.3.5 广播地址

8.3.3.5.1 通用广播地址（0x7FF）

通用广播地址允许在网络上所有节点广播信息。为了发送一个广播信息到整个网络，目标地址必须为0x7FF(所有的位都设置为1)。包含该目标地址的信息将会被所有网关路由。所有的网络节点都应当接收并处理地址为0x7FF的信息。 8.3.3.5.2 子网广播地址

子网的广播用于广播信息到特定子网上的节点。为了发送一条广播信息到某一特定子网上，该子网广播地址应当计算出来。通过将目标子网信息（网络地址及子网掩码）可实现。即将所有节点地址的部分设置为1。见表20对于接收子网的子网广播的例子

表20——接收子网的子网广播的例子 目标地址 位 10 9 8 7 6 5 4 3 2 1 0 地址：0x32F 0 1 1 0 0 1 0 0 0 0 0 子网掩码：/6 1 1 1 1 1 1 0 0 0 0 0 网络地址：0x320 0 1 1 0 0 1 1 1 1 1 1

子网广播信息网关正常路由

所有的节点都必须接收网络地址与他们自身网络地址相同的信息，并且在目标地址域节点地址的部分所有的位都应设置为“1”。

8.3.4 信息接收

每一个子网的节点都将CAN帧中目标地址与它自己的地址相比较。如果匹配的话，包含的信息就传递至OSI模型相邻的上层进一步处理。

8.3.5路由

8.3.5.1 概述

路由适用于当一个节点与另外一个节点不再一个子网上，因而CAN帧就需要从一个子网传递至另一个子网。者通过另外的节点，物理上连接到CAN帧接收子网及发送子网。因此，一个CAN帧从源子网到目的子网，可能通过几个网关

8.3.5.2网络及子网结构

大体上，网络可按需求设计，需考虑如下几个条件： ——地址应当是唯一的。

——所有同一子网的节点都必须使用相同的子网掩码。 ——所有同一子网的节点都必须使用相同的网络地址。

——当一个网络地址分配个一个子网时，在那个地址范围的网络地址都不应当分配个其它的网络，因为这会导致路由问题。

图13显示了连接到网关的四个子网的配置。3个子网通过一个网关连接的，第4个子网通过另外的一个网关连接。

图13——网络配置例子

8.3.5.3网关及路由 8.3.5.3.1说明

网关是连接多于一个子网的节点，由此能够将一个子网的CAN帧传递到另一个子网上。

8.3.5.3.2端口

一个端口是网关连接到物理子网的接口。网关至少有两个端口，每一个端口都分配所在子网的网络地址及子网掩码。

见图13的配置有2个网关，网关1有3个接口，网关2有2个接口。

8.3.5.3.3路由表

为了确定一个CAN帧是否需要被路由，需要生成一张路由表并存储在网关的存储器中。路由条目包含网络地址，子网掩码及能到达的子网的端口。该条目应当存有通过该网关每一个连接的子网（直接的或间接的）。

见表21所示的是图13的网络。通过对网络640/6和650/6的分级设计。路由表条目缩减

到一个条目640/5。

表21——路由表例子 子网（网络地址/子网掩码） 端口 网关1 500/5 1 680/5 2 640/5 3 网关2 500/5 1 680/6 1 650/6 1 640/6 2 8.3.5.3.4路由算法

连接到不同的子网的网关从端口接收所有的信息。如果网关是一有地址的节点，那么直接

连接到该网关端口，在所有地址范围中只有一个地址应当被分配。在合适的路由算法之前，有另外的对信息接收的检查。如果目标地址为0x7FF，信息除了信息接收端口，被复制到所有端口，忽略正常的路由算法。

8.3.5.3.5路由例子

见图15从地址0x51A的客户机到地址0x642服务器CAN帧传输的路由的例子，该例子使用表21的路由信息。

在接收到该信息时，下一步如下进行处理。 a) 网关1

1） CAN-ID分析：DA=0x642，见表22和表23

表22——网关1路由判定 路由描述 网络 端口 （0x642逻辑且0x7C0）= 0x640 != 500?非本地地址?路由 500/5 1 表23——网关1路由分析 路由描述 网络 端口 （0x642逻辑且0x7E0）= 0x640 ！= 680?下一入口 680/6 2 （0x642逻辑且0x7C0）= 0x640 = 640?正确路径 640/5 3 2） 查该信息是否是发送到网关：0x642 != 0x654 3） 将信息送至端口3 b) 网关2

1） CAN-ID分析：DA=0x642.见表24和表25 表24——网关2 路由判定 路由描述 网络 端口 （0x642和0x7C0）= 0x640 != 650?非本地地址?路由 650/6 1 表25——网关2路由分析 路由描述 网络 端口 （0x642逻辑且0x7E0）= 0x640 != 640?正确路径 640/6 2 2） 检查该信息是否发送到网关：0x642 != 0x641 3） 将信息传递至端口2

b) 当ResponseOnEvent服务激活时，服务器能够同时处理诊断请求及相应的应答信息。这应当完成一组请求/应答CAN标识。见图16.如果相同的CAN请求/应答标识用于诊断通信中以及serviceToRespondToresponses服务。如下限制需适用：

1） 在一个事件发生之后，服务器应当忽略即将到来的诊断请求。并且开始运行serviceToRespondTo-response服务，直到该服务完成。

2） 在客户机发送一个诊断请求后，接收到任何应答信息，应答信息应当按照可能的应答服务serviceToRespondTo-responses及期望的诊断应答分类。

3） 如果应答是一个serviceToRespondTo-response（由基于事件应答服务的应答）。客户机应当在serviceToRespondTo-response完全接收到之后，重复该请求。 4） 当应答不确定时（例如，应答可能产生于一个事件的应答或者一个诊断请求的应答），客户机应当将该应答同时作为一个serviceToRespondTo-response及诊断请求应答。客户机不应当重复该请求除非NegativeResponseCode

busyRepeatRequest(21hex)（见否定应答码，ISO 14229-1的定义。） c) ResponseOnEvent服务只有在激活的诊断会话中可用的诊断服务中使用。

d) 当ResponseOnEvent服务处于激活状态时，诊断会话中任何的改变都回中止当前的ResponseOnEvent。例如，如果一个ResponseOnEvent服务在阔真的诊断会话建立起来了，它在服务器转换到默认会话时应当中止。

e) 如果ResponseOnEvent（0x86）服务在默认会话时建立了，如下应当适用： 1） 事件类型子功能参数位6设置为0（不存储事件），那么该事件应当在服务器关电时中止，并且服务器不应当在重启或开电时继续一个ResponseOnEvent诊断服务。（例如，ResponseOnEvent中止）。

2） 事件类型子功能参数位6设置为1（存储事件），它会重新发送

serviceToRespondTo-responses按照ResponseOnEvent在重启电后。

图16——发生时同时存在的请求

f) 子功能参数值responseRequired = “no”应当只用于事件类型eventType = stopResponseOnEvent, startResponseOnEvent或clearResponseOnEvent。当检测到指定事件时，服务器应当总是返回一个事件触发的应答。

g) 服务器应当最后发送肯定应答用于指示ResponseOnEvent(0x86)服务到达了限定事件窗，除非出现以下某种情况：

1） 如果事件类型没有建立ResponseOnEvent，例如，stopResponseOnEvent,

startResponseOnEvent， clearResponseOnEvent或reportActivatedEvents； 2） 如果事件窗建立起来了

——如果在事件窗关闭之前，服务已经处于非激活状态。 ——子功能参数事件类型位6设置为0（不存储），并且系统关电或重启

h) 当指定的事件监测到时，服务器应当以合适的serviceToRespondTo-response立即应答。立即应答信息应当不会破坏其它任何诊断请求及已经处于发送状态的应答（例如，该serviceToRespondTo-response应当延迟直到当前信息发送完之后。见图17）。

图17——在一条信息处理过程中事件发生

i)

ResponseOnEvent服务仅适用于短暂的事件及条件。服务器应当在每一事件发生时，返回一个应答。在一个时期内持续的情况，应答服务应当在启动发生的时候执行。该事件类型的定义主要是为了避免serviceToRespondTo-responses较高频率发生，因而需采取合适的手段进行处理。在serviceToRespondTo-responses的最小时间间隔属于事件类型（eventTypeRecord）的一部分（汽车厂家指定）。 表36和37定义了CAN服务实施的子功能参数 表38定义了CAN服务实施的数据参数

表36——事件类型子功能位6定义——存储状态 位6值 说明 Cvt 助记符 0 doNotStoreEvent M DNSE 1 storeEvent U SE

表37——子功能参数定义 （位5-1）hex 说明 Cvt 助记符 00 stopResponseOnEvent U STPROE 01 onDTCStatusChange U ONDTCS 02 onTimerInterrupt U OTI 03 onChangeOfDataIdentifier U OTI 04 reportActiveEvents U OCOCID 05 startResponseOnEvent U STRTROE 06 clearResponseOnEvent U CLRROE 07 onComparisonOfValues M OCOV 表38——数据参数定义——serviceToRespondToRecord.serviceId 推荐的服务（ServiceToRespondTo） 请求服务标识（SId） ReadDataByIdentifier 22 hex ReadDTCInformation 19 hex RoutineControl 31 hex InputOutputControlByIdentifier 2F hex 9.2.9 连接控制（LinkControl）(87 hex)服务 表39定义了CAN服务实施的子功能参数 表39——子功能参数定义 （位6-1）hex 说明 Cvt 助记符 01 verifyBaudrateTransitionWithFixedBaudrate U VBTWFBR 02 verifyBaudrateTransitionWithSpecificedBaudrate U VBTWSBR 03 transitionBaudrate U TB 9.3数据发送功能单元

9.3.1通过标识符读数据服务（ReadDataByIdentifier）（22hex） 对于该项服务的CAN实施既没有定义另外的要求，也没有限制。 9.3.2通过地址读内存（ReadMemoryByAddress）(23 hex)

对于该项服务的CAN实施既没有定义另外的要求，也没有限制。

9.3.3 通过标识符读刻度数据（ReadScalingDataByIdentifier）(24hex) 对于该项服务的CAN实施既没有定义另外的要求，也没有限制。

9.3.4通过周期的标识读数据（ReadDataByPeriodicIdentifier）(25hex) 在ISO 14229-1定义了两种类型的应答信息用于该服务，如下所示： ——应答信息类型#1（包括服务标识，periodicDataIdentifier和periodicDataIdentifier的回应）：该类型的应答信息映射到USDT信息，使用与其它的USDT相同的CAN标识应答。单个periodicDataIdentifier的USDT信息不应超过一个CAN帧，也就是说，完整的USDT应答信息应当在一个单帧的N_PDU内。 ——应答信息类型#2包括（periodicDataIdentifier和periodicDataIdentifier的数据）：该类型应答信息映射到UUDT信息，使用不同的CAN标识作为USDT的应答信息。单个的periodicDataIdentifier的UUDT信息应当在单个CAN帧范围内。 两个应答类型对客户机服务器的要求如下表40和41.

表40——周期发送——对于应答类型#1信息的要求 信息类客户请服务器应服务器约束 型 求要求 答要求 USDT使无约束 对周期发对于新过来的请求应当有较高优先级，周期发送应当用相同送只有单延迟 的CAN标帧应答 周期应答应当作为普通的USDT信息处理（使用协议控识用于对于可能制信息（PCI），服务标识（SId）和周期数据标识诊断通的新请求（periodicDataIdentifier）），并由服务器网络层处信及周（非周期理。也就是说，当使用标准地址，最大有5字节期发送 发送）有periodicDataIdentifier的数据，当使用扩展地址，多帧应答 最大有4字节periodicDataIdentifier的数据。 对于到来的多帧请求信息，所有周期发送机制在多帧请求的首帧或单帧请求的N_USData.ind被应用层出力时时，应当被延迟。一旦服务完成（包括发送最后结果应答信息），周期信息发送应当继续。 USDT： 未答复的拆分数据传输， ISO 15765-2网络层，包括拆分数据传输的协议控制信息

UUDT ：未答复的未拆分数据传输，CAN单帧，不包括协议控制信息，导致7/8数据字节为标准/扩展地址。

表41——周期发送——对于应答类型#2的应答要求 信息类客户请服务器应服务器约束 型 求要求 答要求 UUDT使无约束 对周期发周期发送的请求作为一个普通的诊断请求并且通过服用不同送只有单务器网络层实现该应答（作为服务标识为0x6A的USDT的CAN标帧应答 信息） 识用于对于可能在接收到N_USData.con只是肯定应答完成时，应用层周期发的新请求开启独立的机制，处理周期发送的信息。 送 （非周期服务器处理周期发送是作为一个单帧UUDT以信息支流发送）有的形式。（例如，直接通过CAN控制器数据链路层而不多帧应答 需网络层写UUDT信息） 对于UUDT信息，不需要包含协议控制信息（PCI）和服务标识（SId）,只包含周期标识。所以，对于标准地址最大7字节periodicDataIdentifier数据，对于扩展地址最大6字节periodicDataIdentifier数据。 图18和图19描述了两个类型的周期应答信息，服务器应当对其处理。而且，图中显示，对于周期发送应答信息不应当受服务器定时器S3Server的影响。对于这两张图，假定非默认会话在周期机制设置之前就激活了。（ReadDataByPeriodicIdentifier服务需要非默认会话条件下执行）。

图18——应答信息类型#1的处理

a)

客户机诊断应用通过

发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。 b) c)

止S3Server定时器。 d)

且周期信息的发送将要随后开启。 e)

时器，这用于保持处于非默认会话状态，而不超时。 f)

服务器开始发送周期

应答信息（单帧信息）。每个周期信息使用网络层协议并且使用用于其它应答信息的CAN应答标识。因此，服务器每次发送N_USData.req到网络层时，一个周期信息都被发送，并且当前没有其它服务在被服务器处理。例子中，假定服务器在下一个请求信息到来之前，能发送客户机发起的3周期信息。周期应答信息的发送对定时器S3Server无任何影响（见6.3.5.4）。 g)

客户机诊断应用层通

过发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。 h) i)

客户机通过

N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。

在周期机制激活期间，

服务器通过N_USData.ind（或者单帧的N_USData.ind）指示请求信息的开始。服务器应当立即停止周期机制，处理接收到的请求信息。而且，服务器在处理任何诊断服务的时候，它都停止S3Server定时器。 j)

送机制处于非激活状态。 k)

例中，假定应答时多帧信息。 l) m)

动作。因为S3Server定时器还没有重新激活。

图中，假定客户机需要

服务器的一个应答。服务器应当通过发送N_USData.req至网络层发送一个肯定（或否定）应答。该

服务器通过

N_USData.ind指示多帧请求信息的完成，随后应答定时参考6.3.5.1.1和6.3.5.1.2 。周期信息发

服务器通过

N_USData.con指示ReadDataPeriodicIdentifier应答信息发送的完成。随后服务器重启S3Server定

图中，假定客户机需要

服务器的一个应答。服务器应发送ReadDataPeriodicIdentifier肯定应答信息指示请求已被处理并

客户机通过

N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。

服务器通过

N_USData.ind指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.2，而且，服务器停

S3Client定时器超时，

客户机发送功能地址TesterPresent(0x3E)请求信息重启服务器中的S3Server定时器。

服务器在处理先前请

求，发送多帧信息应答的过程中。因此，服务器在接收到TesterPresent(0x3E)请求信息时，不应

n) 当诊断服务完全处理

完了，服务器重启S3Server定时器。这是说，所有诊断服务包括TesterPresent(0x3E)都能重启

S3Server定时器。诊断服务在接收到请求信息（N_USDataFF.ind和N_USData.ind）到完成最后结果

应答的时间内都会执行。当需要应答信息时，或者当有请求导致的动作的完成但不需应答信息时（指定时间的到达导致的应答信息）。这包括否定应答信息（包括应答码0x78）。服务器在完成处理之后（最后结果信息完全发送）重启周期机制。 o)

服务器重启周期应答

信息的发送（单帧信息）。每一周期信息使用网络层协议，及用于其它应答信息的CAN应答标识。因此，服务器每周期发送一个N_USData.req至网络层并被传输，并且服务器没有其它服务在当前处理。周期应答信息的发送对S3Server不影响。（见6.3.5.4） p)

时时。 q)

网络层通过

N_USData.con指示TesterPresent(0x3E)请求信息发送完之时，客户机再次重启S3Client定时器。也就是说，功能地址TesterPresent（0x3E）请求信息在S3Client定时器每次超时的周期都发送。

一旦S3Client开启（非

默认会话激活），导致功能地址TesterPresent(0x3E)的发送，不需要应答信息。每次在S3Client超

图19——应答信息类型#2处理

a) 客户机诊断应用通过

发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。

b) c)

止S3Server定时器。 d)

且周期信息的发送将要随后开启。 e)

时器，这用于保持处于非默认会话状态，而不超时。 f)

客户机通过

N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。

服务器通过

N_USData.ind指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.2，而且，服务器停

图中，假定客户机需要

服务器的一个应答。服务器应发送ReadDataPeriodicIdentifier肯定应答信息指示请求已被处理并

服务器通过

N_USData.con指示ReadDataPeriodicIdentifier应答信息发送的完成。随后服务器重启S3Server定

服务器开始发送周期

应答信息（单帧信息）。每个周期信息使用网络层协议并且使用用于其它应答信息的CAN应答标识。因此，服务器每次发送N_USData.req到网络层时，一个周期信息都被发送，并且当前没有其它服务在被服务器处理。例子中，假定服务器在下一个请求信息到来之前，能发送客户机发起的3周期信息。周期应答信息的发送对定时器S3Server无任何影响（见6.3.5.4）。

g) 客户机诊断应用层通

过发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。

h) i)

客户机通过

N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。

在周期机制激活期间，

服务器通过N_USData.ind（或者单帧的N_USData.ind）指示请求信息的开始。服务器应当立即停止周期机制，处理接收到的请求信息。而且，服务器在处理任何诊断服务的时候，它都停止S3Server定时器。

j)

送机制处于非激活状态。 k)

服务器通过

N_USData.ind指示多帧请求信息的完成，随后应答定时参考6.3.5.1.1和6.3.5.1.2 。周期信息发

图中，假定客户机需要

服务器的一个应答。服务器应当通过发送N_USData.req至网络层发送一个肯定（或否定）应答。该例中，假定应答是多帧信息。当网络层发送完多帧应答信息时，周期机制继续发送周期应答信息。

l) m)

S3Client定时器超时，

客户机发送功能地址TesterPresent(0x3E)请求信息重启服务器中的S3Server定时器。

服务器在处理先前请

求，发送多帧信息应答的过程中。因此，服务器在接收到TesterPresent(0x3E)请求信息时，不应动

作。因为S3Server定时器还没有重新激活。 n)

当诊断服务完全处理

完了，服务器重启S3Server定时器。这是说，所有诊断服务包括TesterPresent(0x3E)都能重启

S3Server定时器。诊断服务在接收到请求信息（N_USDataFF.ind和N_USData.ind）到完成最后结果

应答的时间内都会执行。当需要应答信息时，或者当有请求导致的动作的完成但不需应答信息时（指定时间的到达导致的应答信息）。这包括否定应答信息（包括应答码0x78）。服务器在完成处理之后（最后结果信息完全发送）重启周期机制。 o)

时。 p)

网络层通过

N_USData.con指示TesterPresent(0x3E)请求信息发送完之时，客户机再次重启S3Client定时器。也就是说，功能地址TesterPresent（0x3E）请求信息在S3Client定时器每次超时的周期都发送。 表42描述了CAN服务实施可用数据参数 表42——数据参数定义——发送模式 16进制数 描述 01 02 03 04 sendAtSlowRate sendAtMediumRate sendAtFastRate stopSending Cvt U U U U 助记符 SASR SAMR SAFR SS 一旦S3Client开启（非

默认会话激活），导致功能地址TesterPresent(0x3E)的发送，不需要应答信息。每次在S3Client超时

9.3.5 动态定义数据标识（DynamicallyDefineDataIdentifier）（0x2C）服务

当客户机动态定义一个periodicDataIdentifier并且动态定义的periodicDataIdentifier总长超过了单帧周期应答信息最大长度时，该请求应通过应答码0x31(请求超出范围，requestOutOfRange)否定应答拒绝，见ReadDataByPeriodicIdentifier(9.3.4)参考周期应答信息格式。

当多个DynamicallyDefineDataIdentifier请求信息用于设置单个的periodicDataIdentifier并且服务器检测到连续请求期间超出了最大字节数时，服务器应将该定义置位请求之前，以免超出。 表43描述了CAN服务实施可用数据参数

表43——子功能参数定义 16进制数 描述 01 02 03 defineByIdentifier defineByMemoryAddress clearDynamicallyDefinedDataIdentifier Cvt U U U 助记符 DBID DBMA CDDDI 9.3.6 通过标识写数据服务（WriteDataByIdentifier）(0x2E) 对于该项服务的CAN实施既没有定义另外的要求，也没有限制。 9.3.7 通过地址写内存服务（WriteMemoryByAddress）(0x3D) 9.4存储发送数据功能单元

9.4.1 读故障码信息服务（ReadDTCInformation）（19 hex） 表44描述了CAN服务实施可用数据参数

表44——子功能参数定义 进制 描述 Cvt 助记符

本文来源：https://www.bwwdw.com/article/sxea.html