车载诊断标准ISO 15765-3中文

车载诊断标准ISO 15765-3中文ISO 15765-3（2004）道路车辆——控制局域网络诊断—— 第3部分：一元化诊断服务实施（CAN的UDS）道路车辆——控制器局域网（CAN）的诊断—— 第3部分：一元化诊断服务实施（CAN的UDS） 1 范围这部分ISO 15765协议按照ISO 14229-1，描述了在ISO 11898定义的控制器局域网中统一诊断服务（UDS）的实施。它给所有汽车连接至CAN网络服务器及外部测试设备提供诊断服务及服务器存储器编程的需求。它对汽车内部CAN总线架构无任何要求。 2 参考的标准下述的参考文档对于...

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 概况下述的是应用层及会话层的定时参数及它们如何在客户机-服务器模式中如何处理的。图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指示），服务器开始答复信息的运行要求运行要求 0 50ms 在传递了0x78（扩展的超时设置）的否定应答码（通过N_USData.con指示），服务器开始答复信息的运行要求运行要求 5000ms 客户机成功发送不需应答的物理地址请求信息（通过N_USData.con指示），到它能发送下一个物理地址请求信息等待的最小时间（见图6.3.5.3）定时器重载值客户机成功发送功能地址请求信息（通过N_USData.con指示），到它能发送下一个功能地址请求信息等待的最小时间，有可能不需应答也有可能该请求数据只被某个子网功能地址服务器支持（见图6.3.5.3）定时器重载值 a 客户机等待一个应答信息发送的最长时间由客户机决定，但必须满足必须比指定的最小值要大； b 值由客户机决定，但必须满足该值必须比指定的最小值要大； c 扩展的应答定时，在连续的应答码为0x78的否定应答信息之间最小值为，最大容差为±20％的； d 客户机发送下一个请求的最长等待时间由客户机决定，但必须满足非默认会话的定时在服务器一直保持运行。参数被认为是所有系统网络设计参考延时，该延时通过网关及总线带宽加上安全系数（例如最坏情况的50％）。最坏情况（客户机-服务器-客户机信息传输一个来回的必须得传送时间），基于系统的设计，并受以下因素的影响： a) 包含网关的数量 b) CAN帧发送的时间（波特率） c) CAN总线的使用情况 d) CAN设备驱动使用方法（轮询方式还是中断方式）及网络层的处理时间分为两个时间，一是客户机发送请求至服务器的时间，一是服务器发送应答至客户机的时间。图2展示的是组成的一个例子。图2 —— 组成的一个例子——单帧请求和应答信息注意：为了简单描述定时参数，在以下所有的图中，假定客户机到服务器在同一个网络中。所有的说明及附图按照时间顺序表述。 6.3.3会话层定时参数定义当诊断会话而不是默认的会话启动的时，需要按如下表3的会话层定时参数进行会话的操作。表3——会话层定时参数定义定时参数说明类型推荐超时 ms 超时 ms 在功能地址（0x3E）由客户机发送的用于保持诊断会话的信息请求之间的时间，而不是多服务器的默认会话时间（功能的通信），或者对某一具体服务器发送请求最大时间间隔。（物理的通信）。时间重置值 2000ms 4000ms 在没有接收到任何请求信息时，服务器保持诊断会话的时间，不是默认会话活动时间。时间重置值 N/A 5000ms 而且，服务器转变到非默认会话时，应当改变它的应用层定时参数和，以完成适用于诊断会话的操作。非默认的诊断会话适用的定时参数在诊断会话控制应答信息中报告，当一个应答需要传递（见图9.2.1服务说明）或需要提前通知客户不传递任何应答信息时。当客户机启动功能的非默认会话时，它应当调整响应的服务器的定时参数。表4定义了客户机和服务器开启/重启的 / 定时条件。对于客户机，周期性发送功能地址（0x3E）请求信息，应当与连续地发送物理地址（0x3E）请求信息区别开，后者仅仅在没有其它任何诊断请求时发送。对于服务器，不需要这两种（0x3E）的操作方式。表4说明定时器操作是基于网络层服务的，也就是说，定时器在接收到不支持的诊断请求信息时，重启。 6.3.4 客户机和服务器定时器资源要求对于客户机及服务器在默认会话及任何非默认会话完成上述时间定时的定时器资源要求应按照表5及6所示。在非默认会话期间，表6所示附加的定时器资源要求适用于客户机及服务器。表4 ——客户机及服务器的会话层定时启动/停止条件定时参数动作物理和功能通信，使用功能地址，周期性发送请求信息物理通信，使用功能地址，连续发送请求信息初始化开始 N_USData.con用于指示诊断会话控制（10hex）请求信息的完成。只适用于非默认会话的会话类型。若不需应答，N_USData.con指示诊断会话控制（10 hex）请求信息的完成。若需一个应答，N_USData.ind指示诊断会话控制（10 hex）请求信息的完成。随后的开始 N_USData.con指示功能地址（0x3E）请求信息的完成，它是在定时每次到时时发送。若不需应答，N_USData.con指示诊断会话控制任何请求信息的完成。若需一个应答，N_USData.ind指示诊断会话控制任何请求信息的完成。 N_USData.ind在接收到多帧应答信息时，指示出错。初始化开始如果需要一条应答信息被传送的话，N_USData.con指示诊断会话控制应答信息的完成，表示从默认会话转变为非默认会话。如果不需应答。成功地完成请求的服务，该请求为诊断会话控制（10 hex）请求信息要求从默认会话转变至非默认会话，随后的结束 N_USDataFirstFrame.ind指示多帧请求信息开始，N_USData.ind表示任何一个单帧请求信息的接收。如果使用默认会话，被禁用。随后的开始如果需要一条应答信息被传送的话（包括肯定及否定应答），N_USData.con指示任何应答信息的完成，确定一条服务的执行（最后回复信息）。否定应答应答码0x78不会重启。如果不需要任何应答信息（肯定或否定），请求动作的完成（服务结束） N_USData.ind指示接收多帧请求信息时的出错。当请求发送未被请求的信息，如基于某一事件的周期性数据及应答，见6.3.5.4服务器关于更多的处理。表5——默认会话下定时器资源要求定时参数客户机服务器为每一个逻辑通信通道（物理和功能通信）设置一个单独的定时器是需要的，例如，点对点通信需要一个独立的通信通道。 N/A N/A 为扩展的应答定时一个可选择的定时器保证随后的否定应答的发送比早一些。需为每一个物理通信口提供单独的定时器 N/A 需为每一个功能通信口提供单独的定时器 N/A 表6——非默认会话下另外的定时资源需求定时参数客户机服务器当使用周期性发送，功能地址（0x3E）请求信息保持服务器在非默认状态，需提供单独的定时器，不需为每一个激活的诊断会话提供额外的定时器。 N/A 当在无其它诊断请求时，使用连续的发送物理地址（0x3E）请求信息保持单个服务器在非默认状态，为每一个点对点通信通道设置单独的定时器 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时，客户端使用默认重载值为，启动定时器，该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的延时。为了简单化，该图假定客户机和服务器在一条总线上。 d) 服务器通过N_USData.ind指示请求信息的完成。 e) 服务器在接收到N_USData.ind指示时，要求在时间内开始回复信息。也就是说，在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息，该单帧必须在时间内回复。 f) 在多帧应答信息情况下，客户机通过网络层N_USDataFF.ind指示首帧的接收。当接收到首帧时，客户机停止定时器。 g) 如果完整的信息接收到，或者在接收过程中出现了错误，网络层最后都产生一个N_USData.ind。在单帧响应信息，通过单个的N_USData.ind指示单帧的接收。当接收该单帧指示时，客户端停止定时器。 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时，客户端使用默认重载值为，启动定时器，该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的岩石。为了简单化，该图假定客户机和服务器在一条总线上。 d) 服务器通过N_USData.ind指示请求信息的完成。 e) 服务器在接收到N_USData.ind指示时，要求在时间内开始回复信息。也就是说，在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息，该单帧必须在时间内回复。 f) 服务器在给定的时间内无法提供请求的信息时，它可以通过发送应答码为0x78的否定应答信息请求扩展的定时窗。客户端接收到否定应答信息时，客户端网络层产生一个N_USData.ind。接收到应答码为0x78的否定应答信息，客户端重置它的定时器，但使用的是扩展的重载的定时值。 g) 服务器在发送否定应答信息N_USData.con之后，要求在给定的扩展的（）时间内应答信息。如果在给定的扩展的时间内仍无法提供请求的信息，服务器则继续发送应答码为0x78的否定应答。客户端使用的是扩展的重载的定时值重置它的定时器。为了简单起见，图中只显示了一个应答码为0x78的否定应答信息。 h) 一旦服务器可以提供请求的信息（肯定的否定的应答，而不是应答码0x78的应答），它就启动最后结果的应答信息。 i) 在多帧应答信息情况下，客户机通过网络层N_USDataFF.ind指示首帧的接收。当接收到首帧时，客户机停止定时器。 j) 如果完整的信息接收到，或者在接收过程中出现了错误，网络层最后都产生一个N_USData.ind。在单帧响应信息，通过单个的N_USData.ind指示单帧的接收。当接收该单帧指示时，客户端停止定时器。 k) 服务器通过N_USData.con指示响应信息的完成。 6.3.5.1.3 非默认会话期间的物理通信 6.3.5.1.3.1 功能地址（0x3E）信息图5 ——非默认会话期间的物理通信——功能地址图5描述了客户机和服务器非默认会话期间物理通信及使用功能地址的定时处理。客户机周期性发送(0x3E)请求信息，不需要服务器的应答信息。与定时处理与6.3.5.1.1和6.3.5.1.2小节中描述的处理方法相同。唯一的区别是客户端重置的值及服务器端发送结果应答时间会有不同。这是由于转变到另一会话层而不是使用默认会话层，因此使用的是不同的的值。（见9.2.1节诊断会话控制（0x10）服务对定时参数更详细的描述。） a) 客户端诊断应用层通过发送N_USData.req至网络层，传递诊断会话控制（0x10）请求信息。网络层传递该请求信息至服务器。 b) 请求信息是单帧信息。它的完成通过客户端N_USData.con指示。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。客户端产生的N_USData.con促使定时器开启（会话定时器）。 c) 服务器通过N_USData.ind的发送器一个应答。服务器应当发送诊断会话控制（0x10）的肯定应答信息。 d) 服务器通过N_USData.con指示应答信息发送的完成。然后服务器开启定时器，只要它不超时，它就一直处于非默认状态。客户机负责保证定时器在它超时之前复位，以保证服务器处于非默认会话状态。 e) 一旦客户机开启了定时器，这会促使不需应答信息的功能地址（0x3E）请求信息的发送。每一次发送的时机都是在超时时发送。 f) 在网络层通过N_USData.con指示（0x3E）请求信息传递完成之后，客户机再次启动定时器。这就是说，功能地址请求信息是在每一次定时超时之后，周期性发送的。 g) 服务器在处理诊断服务的任何时间内，它都停止定时器。 h) 当诊断服务处理完之后，服务器重启定时器。这就是说，诊断服务，包括（0x3E），都重置定时器。诊断服务是在接收到请求信息（N_USDataFF.ind或者N_USData.ind服务）与完成最后结果应答这个期间内处理的。这里是需要一条应答信息的。或者请求然后诊断服务动作的完成不需要任何应答信息。（及时到达一个点会促使一个应答信息的发送） i) 所有（0x3E）请求信息，在服务器处理另外一条请求信息期间接收的话，都会被服务器忽略。因为它已经停止了定时器，并且在服务处理完之后重启。 6.53.5.1.3.2 物理地址（0x3E）信息图6描述了非默认会话期间客户机与服务器物理通信的定时处理。以及使用物理地址（0x3E）请求信息需要服务器返回应答信息以保持在没有其它诊断服务的时候诊断会话的持续。图6 ——非默认会话期间的物理通信——物理地址 a) 客户端诊断应用层通过发送N_USData.req至网络层，传递诊断会话控制（0x10）请求信息。网络层传递该请求信息至服务器。 b) 请求信息是单帧信息。它的完成通过客户端N_USData.con指示。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。客户端产生的N_USData.con不会促使定时器开启（会话定时器）。这与使用功能地址不同，使用功能地址会周期性发送(0x3E)信息保持诊断会话一直处于激活状态（见6.3.5.3.1）。 c) 服务器通过N_USData.ind指示请求信息的完成。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。 d) 图上给出，假定客户机需要服务器一个应答。服务器应当发送诊断会话控制（0x10）的肯定应答信息。 e) 服务器通过N_USData.con指示应答信息发送的完成。然后服务器开启定时器，只要它不超时，它就一直处于非默认状态。客户机通过N_USData.ind指示诊断会话控制（0x10）的接收。这将促使的开启。客户机负责保证定时器在它超时之前复位，以保证服务器处于非默认会话状态。 f) 客户机任何时候发送一条请求信息至服务器（包括（0x3E）信息），它都会停止。 g) 接收到请求信息的单帧或首帧，服务器都停止定时器。服务器通过N_USData.ind标识请求信息的完成。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。 h) 客户机通过N_USData.ind指示应答信息的完成，这促使客户机开启，服务器通过N_USData.con指示应答信息的完成，这促使服务器开启。还有一种客户机不需要应答的情况，客户机接收到网络层N_USData.con确认标识请求信息发送完时，开启，服务器完成请求的动作时，开启，为简单起见，图中显示的是需要应答的情况。 i) 如果客户机在超时之前，没有发送任何诊断请求信息，这促使客户机在超时时，发送一条物理地址（0x3E）请求信息。 j) 服务器通过N_USData.ind指示（0x3E）请求信息的接收。这促使服务器停止定时器。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。 k) 客户机通过N_USData.ind指示（0x3E）应答信息的完成，这促使客户机开启，服务器通过N_USData.con指示（0x3E）应答信息的完成，这促使服务器开启。还有一种客户机不需要应答的情况，客户机接收到网络层N_USData.con（0x3E）标识请求信息发送完时，开启，服务器完成请求的动作时，开启，为简单起见，图中显示的是需要应答的情况。 6.3.5.2 功能通信 6.3.5.2.1 默认会话期间的功能通信图7描述了默认会话期间，一个客户机与2个服务器功能地址请求信息的定时处理。从服务器角度看，这与物理地址请求信息的定时处理没什么区别。但是客户机对定时的处理就与物理通信不同。图 7——默认会话期间的功能通信 a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送功能地址请求信息。网络层传递该请求信息至服务器。功能地址请求信息只能是单帧信息。 b) 客户机通过N_USData.con指示请求信息的完成。当接到N_USData.con时，客户机启动定时器，使用默认的重置值。该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的延时。为了简单化，该图假定客户机和服务器在一条总线上。 c) 服务器通过N_USData.ind指示请求信息的完成。 d) 功能地址服务器在接收到N_USData.ind后，要求在时间内发送应答信息。也就是说，在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息，该单帧必须在时间内回复。 e) 在多帧应答信息情况下，客户机通过网络层N_USDataFF.ind指示首帧的接收。当接收到首帧时，客户机停止定时器。 f) 当接收到首帧/单帧指示接下来的应答信息，客户端要么知道服务器即将应答或已经应答过了，则停止，要么不是所有服务器应答或它不知道服务器即将应答（客户机等待进一步的应答信息）时，重启。如果完整信息接收到或者在接收过程中产生了一个错误，网络层产生最后结果N_USData.ind。对多帧信息的最后一个N_USData.ind不对定时器产生影响。 g) 服务器通过N_USData.con指示应答信息发送的完成。、 6.5.3.2.2默认会话期间扩展应答定时的功能通信图8描述了默认会话期间客户机与2个服务器功能地址请求信息的定时操作。这里一个服务器通过应答码为0x78的否定应答请求一个扩展的应答定时。从服务器角度看，这与物理地址请求信息的定时处理没什么区别。但是客户机对定时的处理就与物理通信不同。图8——默认会话期间功能通信——扩展的应答定时 a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送功能地址请求信息。网络层传递该请求信息至服务器。功能地址请求信息只能是单帧信息。 b) 客户机通过N_USData.con指示请求信息的完成。当接到N_USData.con时，客户机启动定时器，使用默认的重置值。该定时器的值应当考虑到车载网络设计上（通信网关，总线带宽，等）所有的延时。为了简单化，该图假定客户机和服务器在一条总线上。 c) 服务器通过N_USData.ind指示请求信息的完成。 d) 功能地址服务器在接收到N_USData.ind后，要求在时间内发送应答信息。也就是说，在多帧回复信息条件下，首帧必须在时间内发送，对于单帧回复信息，该单帧必须在时间内回复。服务器在给定的时间内无法提供请求的信息时，它可以通过发送应答码为0x78的否定应答信息请求扩展的定时窗。 e) 客户端接收到否定应答信息时，客户端网络层产生一个N_USData.ind。接收到应答码为0x78的否定应答信息，客户端重置它的定时器，但使用的是扩展的重载的定时值。并且，客户端应当在挂起应答信息列表存储一个服务器标识。一旦在存储在客户端挂起的服务器开始它最后结果应答信息（肯定或否定应答信息包括应答码为0x78的应答），它将从挂起应答信息列表中删除。当无任何应答信息挂起时，客户端重新为使用默认的重载值。为简单化，图中，显示了从服务器#1的仅一个应答码为0x78的否定应答。 f) 只要至少有一个服务器在客户机端挂起时，从任一服务器端任何进一步的应答信息，都会促使定时器使用扩展的值重启（见图9，该图显示了当客户机接收到第二个服务器应答信息开始的情况）。 g) 至于物理的通信，服务器请求扩展的应答定时要求在扩展的时间（）内，应答信息。一旦服务器能提供请求的信息，它就通过发送N_USData.req至网络层开启最后结果应答信息。如果服务器仍然不能在扩展的时间内提供请求的信息，它将继续发送应答码为0x78的否定应答信息。这会促使客户机再次重启定时器，使用扩展的重载值。已经存储在客户端挂起应答信息列表中，服务器端包含应答码为0x78的否定应答信息不影响客户端该信息列表。 h) 如6.3.5.2.1，在多帧应答信息情况下，从任一服务器端接收的首帧，客户机都是通过网络层N_USDataFF.ind指示的。单帧应答信息通过N_USData.ind指示。当接收到首帧/单帧指示接下来的应答信息，客户端要么知道服务器即将应答或已经应答过了，则停止，要么不是所有服务器应答或它不知道服务器即将应答（客户机等待进一步的应答信息）时，重启。 i) 如果完整信息接收到或者在接收过程中产生了一个错误，网络层产生最后结果N_USData.ind。这对定时器不影响。而且适用挂起应答信息列表的处理。 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促使定时器开启（会话定时器）。 c) 服务器通过N_USData.ind指示请求信息的完成。6.3.5.1.1和6.3.5.1.2描述的应答定时适用于此。 d) 图上给出，假定客户机需要服务器一个应答。服务器应当发送诊断会话控制（0x10）的肯定应答信息。 e) 服务器通过N_USData.con指示肯定应答信息发送的完成。然后服务器开启定时器，只要它不超时，它就一直处于非默认状态。客户机负责保证定时器在它超时之前复位，以保证服务器处于非默认会话状态。 f) 一旦客户机开启了定时器，这会促使不需应答信息的功能地址（0x3E）请求信息的发送。每一次发送的时机都是在超时时发送。 g) 在网络层通过N_USData.con指示（0x3E）请求信息传递完成之后，客户机再次启动定时器。这就是说，功能地址请求信息是在每一次定时超时之后，周期性发送的。 h) 服务器在处理诊断服务的任何时间内，它都停止定时器。 i) 当诊断服务处理完之后，服务器重启定时器。这就是说，诊断服务，包括（0x3E），都重置定时器。诊断服务是在接收到请求信息（N_USDataFF.ind或者N_USData.ind服务）与完成最后结果应答这个期间内处理的。这里是需要一条应答信息的。或者请求然后诊断服务动作的完成不需要任何应答信息。（及时到达一个点会促使一个应答信息的发送） j) 所有（0x3E）请求信息，在服务器处理另外一条请求信息期间接收的话，都会被服务器忽略。因为它已经停止了定时器，并且在服务处理完之后重启。与定时处理与6.3.5.1.1和6.3.5.1.2小节中描述的处理方法相同。唯一的区别是客户端重置的值及服务器端发送结果应答时间会有不同。这是由于转变到另一会话层而不是使用默认会话层，因此使用的是不同的的值。（见9.2.1节诊断会话控制（0x10）服务对定时参数更详细的描述。） 6.3.5.3 客户机请求信息最小时间为服务器轮询的服务数据的解读，这对客户机请求信息发送的最小间隔时间有要求的。例如，基于标准的功能，服务器可能处理诊断请求信息以预定的速率（例如10ms）。诊断服务数据解读预定时间应当比运行要求时间短，以满足6.3.5和6.3.5.1.2对服务器要求。请求信息间隔时间的最小定时参数分为如下两个定时参数。 —— ：该定时参数适用于所有功能地址请求信息，因为它在不支持应答数据的情况下，服务器不要求响应功能地址请求信息。 —— ：该定时参数适用于不需服务器应答的物理地址请求信息。（suppressPosRspMsgIndicationBit = TRUE）。物理通信在需要服务器应答的情况下，客户端可以在接收到最后一条应答信息的时候立即发送下一个请求，因为服务器在完成最后结果应答时——意味着该请求已被服务器完全处理完了。图10描述了功能通信期间出现一个问题的例子。当客户机在它确认所有期望的服务器都对先前做了应答时，立即发送下一个请求信息。该情景不仅适用于功能地址请求也适用于物理地址请求，这里客户机不需接受任何应答信息（suppressPosRspMsgIndicationBit = TRUE）。为了处理上述情况，在一条物理或功能地址请求信息与新的物理或功能地址请求信息之间，最小时间和需要为客户机定义。 a) 的值与物理地址的服务器的值相同。该定时适用于所有诊断会话（默认的或非默认的）的所有物理地址请求信息而且所有情况下，都不需要服务器应答。客户机每次启动定时，都发送一条不需应答的物理地址请求信息到总线上，并且，网络层通过N_USData.con指示。当客户机在先前请求信息完全处理完之后，想要发送新的物理地址请求信息时，这只有在定时器不处于活动的情况下。客户端在发送一条新的物理地址请求信息的时刻，启动。然后信息的发送要等到超时。 b) 的值是所有功能地址服务器，所有诊断会话（默认的或非默认的），所有功能地址请求信息的最大值（最坏情况）。客户端每次开启定时器，都发送不需应答的功能地址请求信息到总线上，并且客户端网络层通过N_USData.con指示。当客户机在先前请求信息完全处理完之后，想要发送新的物理地址请求信息时，这只有在定时器不处于活动的情况下。客户端在发送一条新的物理地址请求信息的时刻，启动。然后信息的发送要等到超时。注意：“完全处理完”就是说要么不需应答时没有接收到任何应答，要么所有期待的应答都接受到了。应答的服务器知道并且要求应答，或者服务器不知道并且要求应答时出现超时。对服务器的要求是它应当在（见图7.3）时间内应答信息，这就是说，诊断信息的解读时间应当短于。图10 ——发送下一条请求太早的例子 a) 客户端诊断应用层通过发送N_USData.req功能地址请求信息到网络层。网络层传递信息到服务器。 b) 客户端通过NUSData.con只是请求信息的完成。客户机使用默认的值开启定时器。 c) 服务器通过N_USData.ind指示请求信息的完成。服务器使用默认的值开启定时器。 d) 对于请求的信息，假定只有服务器#1支持请求信息，也就是说服务器#2不会应答信息。服务器#1是快速服务器，能很快处理完请求的信息并在时间内发送应答信息。 e) 客户机接收到应答信息。这通过N_USData.ind指示。客户机仅仅期待服务器#1的应答信息，因此它停止定时器。 f) 服务器#2是慢速服务器，并且在一段时间内（诊断服务数据解读时间）解读请求信息，最坏的情况下，在网络层接收到请求信息之前进行了最后一次请求的信息检查。这就是说，请求会存储在一个缓冲区并且在检查请求信息的例程时执行。当服务器#2处理该条请求时，它确定了它不需要应答，因为它不支持该条请求信息。如图所示，这有可能在服务器#1完成应答信息之后或是在客户机下一条请求信息之后发生。 g) 客户机在所有期待的应答信息完成之后，会立即发送下一条请求。 h) 服务器通过N_USData.ind指示请求信息的完成。但仅仅在快速服务器#1中进行，因为在服务器#2不处理最近一条信息。 i) 客户机新的请求的完成通过N_USData.con指示。图11描述了客户机（基于图10说明的通信情况）定时处理。除此之外图11显示了客户机功能地址（0x3E）的请求。在超时且活动时（请求将等待超时）。图11——功能地址请求信息间隔时间最小值（） a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送功能地址请求信息。网络层传递请求只服务器。 b) 客户端通过N_USData.con指示请求信息的完成。客户机开启定时器并且开启定时器。 c) 服务器通过N_USData.ind指示请求信息的完成。 d) 对于请求的信息，假定只有服务器#1支持请求信息，也就是说服务器#2不会应答信息。服务器#1是快速服务器，能很快处理完请求的信息并在时间内发送应答信息。 e) 客户机接收到应答信息。这通过N_USData.ind指示。客户机仅仅期待服务器#1的应答信息，因此它停止定时器。 f) 服务器#2是慢速服务器，并且在一段时间内（诊断服务数据解读时间）解读请求信息，最坏的情况下，在网络层接收到请求信息之前进行了最后一次请求的信息检查。这就是说，请求会存储在一个缓冲区并且在检查请求信息的例程时执行。当服务器#2处理该条请求时，它确定了它不需要应答，因为它不支持该条请求信息。 g) 尽管客户机接收到了功能地址请求信息所有期待的应答信息，它仍要等待超时之后才允许发送下一条请求信息。在超时的时刻，客户机发送下一条请求信息。 h) 新的请求信息服务器中通过N_USData.ind指示。并服务器#1立即处理，而服务器#2下一次检查请求信息例程中处理该请求。 i) 客户机通过N_USData.con指示新的请求的完成，并且开启定时器。 j) 对于请求的信息，假定只有服务器#1支持请求信息，也就是说服务器#2不会应答信息。服务器#1是快速服务器，能很快处理完请求的信息并在时间内发送应答信息。 k) 客户机接收到应答信息。这通过N_USData.ind指示。客户机仅仅期待服务器#1的应答信息，因此它停止定时器。 l) 服务器#2是慢速服务器，并且在一段时间内（诊断服务数据解读时间）解读请求信息，最坏的情况下，在网络层接收到请求信息之前进行了最后一次请求的信息检查。这就是说，请求会存储在一个缓冲区并且在检查请求信息的例程时执行。当服务器#2处理该条请求时，它确定了它不需要应答，因为它不支持该条请求信息。 m) 客户机定时器超时，促使客户机发送不需服务器应答的功能地址（0x3E）请求信息。在这种情况下，此时仍然活动着，（0x3E）的发送应当到超时时发送。 n) 当定时器超时的时候，客户机可以通过N_USData.req发送功能地址（0x3E）请求。 o) 服务器通过N_USData.ind指示（0x3E）请求信息的接收。 p) 客户机通过N_USData.con指示（0x3E）请求的完成，并启动定时器。图12描述了客户机定时器的操作。该图显示了不需应答的物理地址请求的发送操作及超时时功能地址（0x3E）请求信息。图12——物理地址通信间隔最短时间 a) 客户端诊断应用层通过发送N_USData.req至网络层开始发送物理地址请求信息。网络层传递请求只服务器。 b) 客户端通过N_USData.con指示请求信息的完成。客户机开启定时器。由于不需要应答信息，因此，客户机不需要开启定时器。 c) 服务器通过N_USData.ind指示请求信息的完成。在任何非默认会话期间，定时器此刻是停止的。 d) 服务器在一定时期内（诊断服务数据解读时间）解读请求。在下一次检查请求例程中请求被处理。在非默认会话期间，服务的完全执行会重置定时器。 e) 客户机定时器超时，促使客户机发送功能地址（0x3E）请求信息，不需服务器的应答。 f) 假定定时器此时没有活动，也就是说请求被立即发送。 g) 客户机通过N_USData.con指示（0x3E）请求信息的完成。 h) 服务器通过N_USData.ind指示（0x3E）请求信息得接收。此刻，先前接收到的物理请求仍然在服务器端挂起（还没有处理）并且定时器停止。因此，接收到的（0x3E）请求信息会被服务器忽略。 i) 当定时器在客户机超时，客户机会通过发送N_USData.req发送下一条物理地址请求信息至网络层。 j) 客户机通过N_USData.con指示物理地址请求信息的完成。客户机现在重新开启定时器。由于不需应答信息，因此客户端不启动定时器。 k) 服务器通过N_USData.ind指示请求信息的完成。在任何非默认会话情况下，定时器此刻停止。 6.3.5.4 主动提供的应答信息服务器主动提供的应答信息要么是周期性例程（见服务ReadDataByPeriodicIdentifier in 9.3.4）或者配置引发的，例如DTC状态的变化或者一个日期标识的改变（见服务ResponseOnEvent in 9.2.8）。所有主动提供的应答信息服务器都不应当重启定时器。这在周期性信息传输或者时间触发的事件中时间的时间间隔比短的情况下，有效避免了诊断会话的锁死。定时器只应当在处理一条请求信息并发送最后结果应答信息（例如，初始肯定应答指示一个请求成功执行）的时候被重置。 6.3.6 出错的处理应用层以及客户机和服务器在物理通信、功能通信期间的会话管理出错的处理应当按照表7、表8。假定客户机和服务器都按照该部分15765协议进行应用层及会话层的定时处理。表7——客户机错误处理通信阶段客户端错误类型客户机处理物理通信功能通信请求发送网络层的N_USData.con指示否定结果值客户机在时间之后，有出错指示，应当重发最后的请求重启（由于在请求发送时停止了）客户机在时间之后，有出错指示，应当重发最后的请求超时客户机重新发送最近的请求信息。重启（由于在请求发送时停止了）这里客户机不知道多少服务器应答，这就是指示客户机不再有应答信息了。不用再重复请求信息了。客户机在进一步请求之前，应当完全接受到所有的应答信息。这里客户机知道有多少服务器应答，这就是指示客户机不是所有的服务器都应答。客户机在完全接收到所有应答信息之时发生了超时，应当重新请求信息。应答接收 N_USData.ind网络层否定结果值客户机重新发送最近的请求信息。重启（由于在请求发送时停止了）客户机在完全接收到所有应答信息之时，出错，应当重新请求发送信息。客户机出错处理运行最多2次，也就是说，最坏情况下，请求服务的发送只能是3次。表8——服务器出错处理通信阶段服务器错误类型处理请求接收网络层N_USData.ind指示否定结果值重启定时器（由于它在接收到先前首帧指示时停止了），服务器应当忽略该请求。超时 N/A 应答发送网络层N_USData.ind指示否定结果值重启定时器（由于它在接收到先前的请求信息时停止了）。服务器不应当重新发送该应答信息。 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参数（应用层协议数据单元）说明 N_PDU参数（应用层协议数据单元）说明 A_SA 应用层源地址 N_SA 网络层源址 A_TA 应用层目标地址 N_TA 网络层目标地址 A_Tatype 应用层目标地址类型 N_Tatype 网络层目标地址类型 A_RA 应用层远程地址 N_AE 网络层地址扩展 A_PCI.SI 应用层协议控制信息服务代码 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参数（应用层协议数据单元）说明 A_PDU参数（应用层协议数据单元）说明 N_SA 网络层源址 A_SA 应用层源地址 N_TA 网络层目标地址 A_TA 应用层目标地址 N_Tatype 网络层目标地址类型 A_Tatype 应用层目标地址类型 N_AE 网络层地址扩展 A_RA 应用层远程地址 N_Data[0] 网络层数据 A_PCI.SI 应用层协议控制信息服务代码 N_Data[1]N_Data[n+1 网络层数据 A_Data[0]-A_Data[n 应用层数据 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 15-18 7-0 优先级保留/扩展数据页数据页 PDU格式 PDU-特定域（目标地址或PDU格式扩展）源地址（独有的源地址） 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 目标地址目标地址包含接收实体的地址信息。这应是一单独节点，广

                    本文档为【车载诊断标准ISO 15765-3中文】，请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑，
                    图片更改请在作品中右键图片并更换，文字修改请直接点击文字进行修改，也可以新增和删除文档中的内容。 
 该文档来自用户分享，如有侵权行为请发邮件ishare@vip.sina.com联系网站客服，我们会及时删除。

                    [版权声明] 本站所有资料为用户分享产生，若发现您的权利被侵害，请联系客服邮件isharekefu@iask.cn，我们尽快处理。

                    本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权，请谨慎使用。

                    网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传，仅限个人学习分享使用，禁止用于任何广告和商用目的。
                

下载需要：免费已有0 人下载

立即下载

车载诊断标准ISO 15765-3中文

你可能还喜欢