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

('车载诊断标准ISO-15765-3中文LT出，以下缩略词术语同样适用。DA目标地址ID标识符DLC数据长度码GW网关LSB最低有效位MSB最高有效位NA网络地址SA源地址SM子网掩码TOS服务类型4协定该部分ISO15765协议基于ISO14229-1的协定，该协议遵从使用到诊断服务的OSI服务协议。5统一诊断服务（UDS）对照OSI模型的应用见图16应用层及会话层6.1应用层服务该部分ISO15765协议使用ISO14229-1的客户机-服务器式的应用层服务。该系统具有测试、检测、监视，诊断及汽车服务器在线编程的功能。6.2应用层协议该部分ISO15765协议使用ISO14229-1应用层协议。6.3应用层诊断会话管理定时重要——任何一个服务器端产生的不等于N_OK的N_USData.indication的指示服务，服务器应用层都不应该有一个应答信息。6.3.1概况下述的是应用层及会话层的定时参数及它们如何在客户机-服务器模式中如何处理的。图1OSI模型中，基于CAN的UDS实施下述的几种通信会话方式需区别开：a)物理的通信在如下期间1）默认会话方式2）非默认的会话方式——需进行会话处理b)功能的通信在如下期间1）默认的会话方式2）非默认的会话方式——需进行会话处理所有的情况下，请求服务器否定应答信息的扩展的定时应答，包括应答码78hex应当予以考虑。定义在ISO15765-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指示），服务器开始答复信息的运行要求运行要求050ms在传递了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）由客户机发送的用于保持诊断会话的信息请求之间的时时间重置值2000ms4000ms间，而不是多服务器的默认会话时间（功能的通信），或者对某一具体服务器发送请求最大时间间隔。（物理的通信）。在没有接收到任何请求信息时，服务器保持诊断会话的时间，不是默认会话活动时间。时间重置值N/A5000ms而且，服务器转变到非默认会话时，应当改变它的应用层定时参数和，以完成适用于诊断会话的操作。非默认的诊断会话适用的定时参数在诊断会话控制应答信息中报告，当一个应答需要传递（见图9.2.1服务说明）或需要提前通知客户不传递任何应答信息时。当客户机启动功能的非默认会话时，它应当调整响应的服务器的定时参数。表4定义了客户机和服务器开启/重启的/定时条件。对于客户机，周期性发送功能地址（0x3E）请求信息，应当与连续地发送物理地址（0x3E）请求信息区别开，后者仅仅在没有其它任何诊断请求时发送。对于服务器，不需要这两种（0x3E）的操作方式。表4说明定时器操作是基于网络层服务的，也就是说，定时器在接收到不支持的诊断请求信息时，重启。6.3.4客户机和服务器定时器资源要求对于客户机及服务器在默认会话及任何非默认会话完成上述时间定时的定时器资源要求应按照表5及6所示。在非默认会话期间，表6所示附加的定时器资源要求适用于客户机及服务器。表4——客户机及服务器的会话层定时启动/停止条件定时参数动作物理和功能通信，使用功能地址，周期性发送请求信息物理通信，使用功能地址，连续发送请求信息初始化开始N_USData.con用于指示诊断会话控制（10hex）请求信息的完成。只适用于非默认会话的会话类型。若不需应答，N_USData.con指示诊断会话控制（10hex）请求信息的完成。若需一个应答，N_USData.ind指示诊断会话控制（10hex）请求信息的完成。随N_USData.con指示若不需应后的开始功能地址（0x3E）请求信息的完成，它是在定时每次到时时发送。答，N_USData.con指示诊断会话控制任何请求信息的完成。若需一个应答，N_USData.ind指示诊断会话控制任何请求信息的完成。N_USData.ind在接收到多帧应答信息时，指示出错。初始化开始如果需要一条应答信息被传送的话，N_USData.con指示诊断会话控制应答信息的完成，表示从默认会话转变为非默认会话。如果不需应答。成功地完成请求的服务，该请求为诊断会话控制（10hex）请求信息要求从默认会话转变至非默认会话，随后的结束N_USDataFirstFrame.ind指示多帧请求信息开始，N_USData.ind表示任何一个单帧请求信息的接收。如果使用默认会话，被禁用。随后的开始如果需要一条应答信息被传送的话（包括肯定及否定应答），N_USData.con指示任何应答信息的完成，确定一条服务的执行（最后回复信息）。否定应答应答码0x78不会重启。如果不需要任何应答信息（肯定或否定），请求动作的完成（服务结束）N_USData.ind指示接收多帧请求信息时的出错。当请求发送未被请求的信息，如基于某一事件的周期性数据及应答，见6.3.5.4服务器关于更多的处理。表5——默认会话下定时器资源要求定时参数客户机服务器为每一个逻辑通信通道（物理和功能通信）设置一个单独的定时器是需要的，例如，点对点通信需要一个独立的通信通道。N/AN/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主动提供的应答信息服务器主动提供的应答信息要么是周期性例程（见服务ReadDataByPeriodicIdentifierin9.3.4）或者配置引发的，例如DTC状态的变化或者一个日期标识的改变（见服务ResponseOnEventin9.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概述该部分的ISO15765协议使用ISO1576502定义的网络层服务进行诊断信息的收发。本节定义应用层协议数据单元（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.responseA_PDU到N_USData.requestN_PDUA_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.inN_PDU到A_PDU的映射的定义。表10————N_USData.indN_PDU到ServiceName.conf/ServiceName.indA_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）请求信息保持非默认会话处于激活状态。）如果ISO15765-4说明的11位的CAN标识在扩展的诊断中重新使用，适用如下要求：a)ISO15765-4协议的网络层定时参数同样适用于扩展的诊断；b)DLC（CAN数据长度码）应当设置为8并且CAN帧应当包含8字节（未使用的字节也应当填充）；注意：ISO15765-4允许最大8OBD相关服务器，为8个服务器定义了11位CAN标识。8.2法规29位OBD的CAN标识法规的29位CAN标识应按照ISO15765-2说明的标准固定的地址格式，同样能用于扩展的诊断。如果ISO15765-4说明的29位的CAN标识在扩展的诊断中重新使用，适用如下要求：a)ISO15765-4协议的网络层定时参数同样适用于扩展的诊断；b)DLC（CAN数据长度码）应当设置为8并且CAN帧应当包含8字节（未使用的字节也应当填充）；注意：表中给出的CAN标识符按照ISO15765-2协议优先级信息使用默认的值。8.3扩展的诊断29位CAN标识8.3.1概述本部分说明使用29位CAN标识的标准地址及路由的概念。主要使用了最流行的网络协议（IP）的握手机制。因此地址及路由的算法可用于不同子网位置的节点的通信及路由。准地址及路由的概念遵循如下的特征：——网络结构最灵活的设计操作——完全定制的网络及节点地址——CAN控制器硬件过滤特征通过分配合适的网络及节点地址优化。——网关需要知道与它连接的子网的网络地址，而不需要所有子网成员的地址。下面描述了CAN标识符结构的技术细节，包括地址，子网掩码。也包括了对路由及广播的算法的详细描述。8.3.229位CAN标识符结构本文档描述的29位CAN标识符结构与如下协议是兼容的。有ISO15765-2,ISO15765-3,ISO15765-4及SAEJ1939-21.因此SAEJ1939-21定义的29位CAN标识结构中25位的编码（保留/扩展数据页）和24位编码（数据页）应当确定该CAN标识或CAN帧是J1939的还是ISO15765的。这对汽车网络设计者根据他的需求及对SAEJ1939和ISO15765协议的使用，定制非诊断的信息及相关CAN标识是重要的。8.3.2.1SAEJ1939的29位CAN标识符结构关于SAEJ193929位CAN标识符格式见如下表11表11——SAEJ1939的CAN标识符结构29位CAN标识符28、27、26252423-1615-187-0优先级保留/扩展数据PDU格式PDU-特定域（目标地址或源地址（独有数据页页PDU格式扩展）的源地址）8.3.2.2ISO15765的29位CAN标识符结构表12显示了ISO15765的CAN标识符结构与SAEJ1939格式的区别。25位——SAEJ1939保留/扩展数据页，ISO15765使用扩展数据页24位——SAEJ1939数据页，ISO15765数据页因此，ISO15765格式与SAEJ1939格式的29位CAN标识能在同一个CAN总线上互不影响的共存。表12——ISO15765的CAN标识符结构29位CAN标识28-26252423，2221-1110-0优先级扩展数据页数据页服务类型（TOS）源地址目标地址编码见8.3.2.4编码见8.3.2.5源地址（独有的源地址）目标地址（独有的目标地址）8.3.2.3优先级域SAEJ1939定义的优先级域用于CAN总线的仲裁机制。由于CAN标识符不再能自由分配（源地址和目的地址包含在CAN标识符中），CAN信息优先级由发送者分配并间接由接收者分配。存在８种不同的优先级。优先级６分配至诊断请求信息／帧。8.3.2.４扩展的数据页及数据页域扩展的数据页及数据页位决定了使用哪一种２９位的CAN标识。见表１３编码的说明表１３——扩展数据页及数据页域扩展的数据页位２５数据页位２４说明００SAEJ1939定义或厂家定义的“标准通信信息”０１SAEJ1939定义或厂家定义的“标准通信信息”１０SAEJ1939定义或厂家定义的“标准通信信息”１１ISO15765定义的8.3.2.5服务类型（TOS）域服务类型域用于表述一个节点不需要分配不同地址的情况下，分配不同项服务。因此，8种不同的服务类型能同时分配给单个的目标地址。不同服务类型的定义见表14表14——服务类型的定义（TOS）位23位22服务类型（TOS）说明00ISO保留该位组合为ISO为将来保留01OEM-定义的信息该位组合指示信息为OEM特定的，ISO15765-3及以前的协议信息能通过相同的网络但不同的协议信息混合使用在一个服务器上。10网络控制信息协议/网络管理该位组合指示帧包含的网关收发数据用于支持当前子网状态的信息（例如，网络无法到达/网络超载）和节点信息（例如，主机无法到达）11ISO15765-3定义的信息该位组合包含了节点ISO15765定义的诊断服务。CAN帧用户数据字节包括诊断请求（ISO15765-3）使用网络层服务及ISO15765-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个位提供固定节点地址。最大的子网数量可根据如下计算：（X代表使用到网络地址的位的个数）b)节点地址节点地址部分包含了地址中剩下的连续的位“Y”（Y=11-X），并决定了子网中具体的节点。在子网中应当是独有的。所有的位都置位0或1是不允许的。所以最小节点地址长度为2个位，最大为9个位。子网中最多节点个数根据如下公式计算：（Y代表使用到节点地址的位的个数）分配给节点独有的地址应当存储在节点的内部存储器中。一个节点接收目标地址域为该节点地址的的信息。表15展示了源地址和目标地址的一个例子。发送及接收节点不在同一个子网中。表15——源地址和目标地址的一个例子29位CAN标识282726252423222111100优先级0x6ISO15765格式服务类型ISO15765信息源地址0x2ED目的地址0x32F110111101011101101011001011118.3.3.3子网掩码子网掩码为网络地址及节点地址分配。子网掩码长度为11位（与地址长度一致）。子网掩码的值通过设置开始连续的位“X”为1分配。将网络地址部分设置为1，将节点地址的部分设置为0.（见表16和表17发送与接收者的子网掩码的例子）由于固定的子网掩码长度及一开始的连续的位“X”设置为1，只有这些位置位1而不是所有位。因此需要一个短记号定义子网掩码。表16——发送端子网掩码例子子网掩码1098765432100X7C0(短的记号/5)网络地址部分节点地址部分11111000000表17——接收端子网掩码例子子网掩码1098765432100X7C0(短的记号/5)网络地址部分节点地址部分11111100000每一个分配子网掩码的节点都应当存储在它内部存储器内。相同子网的节点分配相同的子网掩码。8.3.3.4网络地址节点的网络地址现在可以通过分配地址及子网掩码计算出来。见表18和19发送者和接收者的例子决定了网络地址。表18——发送者网络地址源地址位109876543210地址：0x2ED01011101101子网掩码：/511111000000网络地址：0x2C001011000000表19——接收者网络地址源地址位109876543210地址：0x32F01100101111子网掩码：/611111100000网络地址：0x32001100100000为了描述子网掩码，网络地址及子网掩码按如下形式记录：<网络层地址>/<短的子网掩码记录>实例：发送端子网：0x2C0/5接收端子网：0x320/6该信息被网关用来路由。8.3.3.5广播地址8.3.3.5.1通用广播地址（0x7FF）通用广播地址允许在网络上所有节点广播信息。为了发送一个广播信息到整个网络，目标地址必须为0x7FF(所有的位都设置为1)。包含该目标地址的信息将会被所有网关路由。所有的网络节点都应当接收并处理地址为0x7FF的信息。8.3.3.5.2子网广播地址子网的广播用于广播信息到特定子网上的节点。为了发送一条广播信息到某一特定子网上，该子网广播地址应当计算出来。通过将目标子网信息（网络地址及子网掩码）可实现。即将所有节点地址的部分设置为1。见表20对于接收子网的子网广播的例子表20——接收子网的子网广播的例子目标地址位109876543210地址：0x32F01100100000子网掩码：/611111100000网络地址：0x32001100111111子网广播信息网关正常路由所有的节点都必须接收网络地址与他们自身网络地址相同的信息，并且在目标地址域节点地址的部分所有的位都应设置为“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——路由表例子子网（网络地址/子网掩码）端口网关1500/51680/52640/53网关2500/51680/61650/61640/628.3.5.3.4路由算法连接到不同的子网的网关从端口接收所有的信息。如果网关是一有地址的节点，那么直接连接到该网关端口，在所有地址范围中只有一个地址应当被分配。在合适的路由算法之前，有另外的对信息接收的检查。如果目标地址为0x7FF，信息除了信息接收端口，被复制到所有端口，忽略正常的路由算法。8.3.5.3.5路由例子见图15从地址0x51A的客户机到地址0x642服务器CAN帧传输的路由的例子，该例子使用表21的路由信息。在接收到该信息时，下一步如下进行处理。a)网关11）CAN-ID分析：DA=0x642，见表22和表23表22——网关1路由判定路由描述网络端口（0x642逻辑且0x7C0）=0x640!=500\uf0e0非本地地址\uf0e0路由500/51表23——网关1路由分析路由描述网络端口（0x642逻辑且0x7E0）=0x640！=680\uf0e0下一入口680/62（0x642逻辑且0x7C0）=0x640=640\uf0e0正确路径640/532）查该信息是否是发送到网关：0x642!=0x6543）将信息送至端口3b)网关21）CAN-ID分析：DA=0x642.见表24和表25表24——网关2路由判定路由描述网络端口（0x642和0x7C0）=0x640!=650\uf0e0非本地地址\uf0e0路由650/61表25——网关2路由分析路由描述网络端口（0x642逻辑且0x7E0）=0x640!=640\uf0e0正确路径640/622）检查该信息是否发送到网关：0x642!=0x6413）将信息传递至端口2步骤：A从端口“X”接收到信息1将接收信息的目标地址与接收信息端口的子网掩码一位一位进行逻辑“且”操作。2将结果与接收信息的端口的网络地址进行比较。端口的网络地址要么存储在节点存储器内，要么通过端口的地址及子网掩码计算出来。如果结果与网络地址相等，接收到的信息是该端口子网的本地信息，并且不再做任何路由（B）。如果结果与端口网络地址不等，则需要进行路由分析。进行第3步。3将接收信息的目标地址与当前路由表入口的子网掩码一位一位进行逻辑“且”操作。4将结果与当前路由表入口的网络地址进行比较。如果匹配的话，算法从步骤8继续，否则算法从步骤5继续。5如果有另外的路由表入口，算法从步骤6继续，否则，不再做任何路由（B）。6选择了下一个路由表入口，算法跳到步骤3继续。7信息的目标地址与网关当前端口的地址进行比较。该步骤只有在网关是一个有地址的节点时才需要，否则算法直接跳到步骤8.如果是网关当前端口的地址，算法从步骤9继续，如果目标地址与网关地址不同，算法从步骤8继续。8信息发送到路由表网络地址与目标地址匹配的入口端口上。9信息是发送到网关节点上的，并由网关应用层处理。B路由结束KeyDA目标地址GWADport_X的网关地址NA网络地址SM子网掩码entry_X网关路由表入口#Xprot_X网关的#X端口图14路由算法顺序图图15——从客户机0x51A到服务器0x642的路由的例子9诊断服务实施9.1统一诊断服务总览该部分定义了ISO14229-1定义的诊断服务是如何适用于CAN的。对于每一个应用服务，都定义了可用的子功能及数据参数。注意：子功能参数的定义考虑了suppressPosRspMsgIndicatonBit参数的最高有效位。该参数在ISO14229-1中定义。表26用于提供所有统一诊断服务的总览，它们适用于CAN诊断实施，表包含了可用服务总数。使用该部分ISO15765协议实施CAN诊断的某些应用上可能限制了可使用服务的数量，并可将它们按应用范围/诊断会话（默认会话，编程会话等）进行归类。表26——CAN诊断——统一诊断服务总览诊断服务名称（ISO14229-1）服务ID值（16进制）子功能支持suppressPosRspMsgIndicatonBit=TRUE（1）；（无应答）支持(a)子目录诊断与通信管理功能单元DiagnosticSessionControl10是是9.2.1ECUReset11是是9.2.2SecurityAccess27是是9.2.3CommnicationControl28是是9.2.4TesterPresent3E是是9.2.5SecuredDataTransmission84—N/A9.2.6ControlDTCSettin85是是9.2g.7ResponseOnEvent86是是9.2.8LinkControl87是是9.2.9数据发送功能单元ReadDataByIdentifier22—N/A9.3.1ReadMemoryByAddress23—N/A9.3.2ReadScalingDataByIdentifier24—N/A9.3.3ReadDataByPeriodicIdentifier2A—N/A9.3.4DynamicallyDefineDataIdentifier2C是是9.3.5WriteDataByIdentifier2E—N/A9.3.6WriteMemoryByAddress3D—N/A9.3.7存储数据发送功能单元ReadDTCInformati19是是9.4on.1ClearDignositicInformation14—9.4.2输入/输出控制功能单元InputOutPutControlByIdentifier2F—N/A9.5.1例行的远程激活功能单元RoutineControl31是是9.6.1上载/下载功能单元RequestDownload34—N/A9.7.1RequestUpload35—N/A9.7.2TransferData36—N/A9.7.3RequestTransferExit37—N/A9.7.4a这是指suppressPosRspMsgIndicatonBit=FALSE(0)表示服务支持使用该子功能参数。系统设计者需保证如果客户机不需要一个应答信息[suppressPosRspMsgIndicatonBit=TRUE（1）]并且服务器需要超过的时间去处理请求信息时，客户机应当在连续请求之间插入足够的时间。有可能的一个情况是，当服务器不执行请求的动作，也不指示任何原因至客户机。9.2诊断与通信控制功能单元9.2.1诊断会话控制（DiagnosticSessionControl）（10hex）服务表27定义了适用于CAN诊断服务的子功能参数表27——子功能参数定义Hex(位6-0)描述Cvt助记忆法01defaultSessionUDS02ECUProgrammingSessionUECUPS03ECUExtendedDiagnosticSessionUECUEDS表28和29定义了应答信息数据参数结构，sessionParameterRecord适用于CAN诊断实施。表28——会话参数记录定义记录的位位置说明Cvt16进制值助记忆法#1#2#3#4SessionParameterRecord[]#1={(高字节)（低字节）（高字节）（低字节）}MMMM00-FF0-FF00-FF00-FFSPREC_P2CSMHP2CSMLP2ECSMHP2ECSML表29——会话参数记录内容定义参数说明#占用字节解决最小值最大值服务器支持默认的定时用于激活诊断会话21ms0ms65535ms服务器支持扩展的（NRC78hex）用于激活诊断会话210ms0ms655350ms9.2.2ECU复位（ECUReset）（11hex）服务表30定义了该项CAN服务的子功能参数表30——子功能参数定义Hex(位6-0)描述Cvt助记忆法01hardResetUHR02keyOffOnResetUKOPPONR03softResetUSR04enableRapidPowerShutDownUERPSD05disableRapidPowerShutDownUDRPSD9.2.3安全访问（SecurityAccess）(27hex)服务表31定义了该项CAN服务的子功能参数表31——子功能参数定义Hex(位6-0)描述Cvt助记忆法01requestSeedURSD02sendKeyUSK03,0507-5FrequestSeedURSD04,0608-60sendKeyUSK9.2.4通信控制服务（CommunicationControl）(28hex)表32定义了该项CAN服务的子功能参数表32——子功能参数定义Hex(位6-0)描述Cvt助记忆法00enableRxAndTxUERXTX01enableRxAndDisableTxUERXDTX02disableRxAndEnableTxUDRXETX03disableRxAndTxUDRXTX表33定义了CAN服务实施可用的数据参数表33——数据参数定义——通信类型Hex(位1-0)描述Cvt助记忆法01bapplicationUAPPL10bnetworkManagementUNWM位1–0适用任何组合。每一个位代表一种通信类型，可能每次都不止初始化一种通信类型。9.2.5测试仪现场服务（TesterPresent）(3Ehex)表33定义了该项CAN服务的子功能参数表33——子功能参数定义Hex描述Cvt助记忆法(位6-0)00zeroSubFunctionMZSUBF9.2.6安全数据传输服务（SecuredDataTransmission）(84hex)对于该CAN服务实施，既没有额外的需求也没有限制。9.2.7控制故障吗信息设置服务（ControlDTCSetting）(85hex)表35定义了该项CAN服务的子功能参数表33——子功能参数定义Hex(位6-0)描述Cvt助记忆法01onMON02offMOFF9.2.8基于事件应答服务（ResponseOnEvent）(86hex)CAN实施须满足以下相关条件a)大量的ResponseOnEvent服务都伴随着不同的启动和停止诊断服务的要求（不同的时间类型EventTypes,应答记录服务serviceToRespondTo-Records）。b)当ResponseOnEvent服务激活时，服务器能够同时处理诊断请求及相应的应答信息。这应当完成一组请求/应答CAN标识。见图16.如果相同的CAN请求/应答标识用于诊断通信中以及serviceToRespondToresponses服务。如下限制需适用：1）在一个事件发生之后，服务器应当忽略即将到来的诊断请求。并且开始运行serviceToRespondTo-response服务，直到该服务完成。2）在客户机发送一个诊断请求后，接收到任何应答信息，应答信息应当按照可能的应答服务serviceToRespondTo-responses及期望的诊断应答分类。3）如果应答是一个serviceToRespondTo-response（由基于事件应答服务的应答）。客户机应当在serviceToRespondTo-response完全接收到之后，重复该请求。4）当应答不确定时（例如，应答可能产生于一个事件的应答或者一个诊断请求的应答），客户机应当将该应答同时作为一个serviceToRespondTo-response及诊断请求应答。客户机不应当重复该请求除非NegativeResponseCodebusyRepeatRequest(21hex)（见否定应答码，ISO14229-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助记符0doNotStoreEventMDNSE1storeEventUSE表37——子功能参数定义（位5-1）hex说明Cvt助记符00stopResponseOnEventUSTPROE01onDTCStatusChangeUONDTCS02onTimerInterruptUOTI03onChangeOfDataIdentifierUOTI04reportActiveEventsUOCOCID05startResponseOnEventUSTRTROE06clearResponseOnEventUCLRROE07onComparisonOfValuesMOCOV表38——数据参数定义——serviceToRespondToRecord.serviceId推荐的服务（ServiceToRespondTo）请求服务标识（SId）ReadDataByIdentifier22hexReadDTCInformation19hexRoutineControl31hexInputOutputControlByIdentifier2Fhex9.2.9连接控制（LinkControl）(87hex)服务表39定义了CAN服务实施的子功能参数表39——子功能参数定义（位6-1）hex说明Cvt助记符01verifyBaudrateTransitionWithFixedBaudrateUVBTWFBR02verifyBaudrateTransitionWithSpecificedBaudrateUVBTWSBR03transitionBaudrateUTB9.3数据发送功能单元9.3.1通过标识符读数据服务（ReadDataByIdentifier）（22hex）对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.3.2通过地址读内存（ReadMemoryByAddress）(23hex)对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.3.3通过标识符读刻度数据（ReadScalingDataByIdentifier）(24hex)对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.3.4通过周期的标识读数据（ReadDataByPeriodicIdentifier）(25hex)在ISO14229-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：未答复的拆分数据传输，ISO15765-2网络层，包括拆分数据传输的协议控制信息UUDT：未答复的未拆分数据传输，CAN单帧，不包括协议控制信息，导致7/8数据字节为标准/扩展地址。表41——周期发送——对于应答类型#2的应答要求信息类型客户请求要求服务器应答要求服务器约束UUDT使用不同的CAN标识用于周期发送无约束对周期发送只有单帧应答对于可能的新请求（非周期发送）有多帧应答周期发送的请求作为一个普通的诊断请求并且通过服务器网络层实现该应答（作为服务标识为0x6A的USDT信息）在接收到N_USData.con只是肯定应答完成时，应用层开启独立的机制，处理周期发送的信息。服务器处理周期发送是作为一个单帧UUDT以信息支流的形式。（例如，直接通过CAN控制器数据链路层而不需网络层写UUDT信息）对于UUDT信息，不需要包含协议控制信息（PCI）和服务标识（SId）,只包含周期标识。所以，对于标准地址最大7字节periodicDataIdentifier数据，对于扩展地址最大6字节periodicDataIdentifier数据。图18和图19描述了两个类型的周期应答信息，服务器应当对其处理。而且，图中显示，对于周期发送应答信息不应当受服务器定时器的影响。对于这两张图，假定非默认会话在周期机制设置之前就激活了。（ReadDataByPeriodicIdentifier服务需要非默认会话条件下执行）。图18——应答信息类型#1的处理a)客户机诊断应用通过发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。b)客户机通过N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。c)服务器通过N_USData.ind指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.2，而且，服务器停止定时器。d)图中，假定客户机需要服务器的一个应答。服务器应发送ReadDataPeriodicIdentifier肯定应答信息指示请求已被处理并且周期信息的发送将要随后开启。e)服务器通过N_USData.con指示ReadDataPeriodicIdentifier应答信息发送的完成。随后服务器重启定时器，这用于保持处于非默认会话状态，而不超时。f)服务器开始发送周期应答信息（单帧信息）。每个周期信息使用网络层协议并且使用用于其它应答信息的CAN应答标识。因此，服务器每次发送N_USData.req到网络层时，一个周期信息都被发送，并且当前没有其它服务在被服务器处理。例子中，假定服务器在下一个请求信息到来之前，能发送客户机发起的3周期信息。周期应答信息的发送对定时器无任何影响（见6.3.5.4）。g)客户机诊断应用层通过发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。h)客户机通过N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。i)在周期机制激活期间，服务器通过N_USData.ind（或者单帧的N_USData.ind）指示请求信息的开始。服务器应当立即停止周期机制，处理接收到的请求信息。而且，服务器在处理任何诊断服务的时候，它都停止定时器。j)服务器通过N_USData.ind指示多帧请求信息的完成，随后应答定时参考6.3.5.1.1和6.3.5.1.2。周期信息发送机制处于非激活状态。k)图中，假定客户机需要服务器的一个应答。服务器应当通过发送N_USData.req至网络层发送一个肯定（或否定）应答。该例中，假定应答时多帧信息。l)定时器超时，客户机发送功能地址TesterPresent(0x3E)请求信息重启服务器中的定时器。m)服务器在处理先前请求，发送多帧信息应答的过程中。因此，服务器在接收到TesterPresent(0x3E)请求信息时，不应动作。因为定时器还没有重新激活。n)当诊断服务完全处理完了，服务器重启定时器。这是说，所有诊断服务包括TesterPresent(0x3E)都能重启定时器。诊断服务在接收到请求信息（N_USDataFF.ind和N_USData.ind）到完成最后结果应答的时间内都会执行。当需要应答信息时，或者当有请求导致的动作的完成但不需应答信息时（指定时间的到达导致的应答信息）。这包括否定应答信息（包括应答码0x78）。服务器在完成处理之后（最后结果信息完全发送）重启周期机制。o)服务器重启周期应答信息的发送（单帧信息）。每一周期信息使用网络层协议，及用于其它应答信息的CAN应答标识。因此，服务器每周期发送一个N_USData.req至网络层并被传输，并且服务器没有其它服务在当前处理。周期应答信息的发送对不影响。（见6.3.5.4）p)一旦开启（非默认会话激活），导致功能地址TesterPresent(0x3E)的发送，不需要应答信息。每次在超时时。q)网络层通过N_USData.con指示TesterPresent(0x3E)请求信息发送完之时，客户机再次重启定时器。也就是说，功能地址TesterPresent（0x3E）请求信息在定时器每次超时的周期都发送。图19——应答信息类型#2处理a)客户机诊断应用通过发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。b)客户机通过N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。c)服务器通过N_USData.ind指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.2，而且，服务器停止定时器。d)图中，假定客户机需要服务器的一个应答。服务器应发送ReadDataPeriodicIdentifier肯定应答信息指示请求已被处理并且周期信息的发送将要随后开启。e)服务器通过N_USData.con指示ReadDataPeriodicIdentifier应答信息发送的完成。随后服务器重启定时器，这用于保持处于非默认会话状态，而不超时。f)服务器开始发送周期应答信息（单帧信息）。每个周期信息使用网络层协议并且使用用于其它应答信息的CAN应答标识。因此，服务器每次发送N_USData.req到网络层时，一个周期信息都被发送，并且当前没有其它服务在被服务器处理。例子中，假定服务器在下一个请求信息到来之前，能发送客户机发起的3周期信息。周期应答信息的发送对定时器无任何影响（见6.3.5.4）。g)客户机诊断应用层通过发送N_USData.req到网络层开始发送ReadDataByPeriodIdentifier(0x2A)请求信息。网络层发送该信息之服务器。请求信息要么做为单帧信息要么是多帧信息（依赖于请求信息中periodicDataIdentifier包含的数量）。该例中，假定请求信息是单帧信息。h)客户机通过N_USData.con指示请求信息的完成。随后应答定时参考6.3.5.1.1和6.3.5.1.3。i)在周期机制激活期间，服务器通过N_USData.ind（或者单帧的N_USData.ind）指示请求信息的开始。服务器应当立即停止周期机制，处理接收到的请求信息。而且，服务器在处理任何诊断服务的时候，它都停止定时器。j)服务器通过N_USData.ind指示多帧请求信息的完成，随后应答定时参考6.3.5.1.1和6.3.5.1.2。周期信息发送机制处于非激活状态。k)图中，假定客户机需要服务器的一个应答。服务器应当通过发送N_USData.req至网络层发送一个肯定（或否定）应答。该例中，假定应答是多帧信息。当网络层发送完多帧应答信息时，周期机制继续发送周期应答信息。l)定时器超时，客户机发送功能地址TesterPresent(0x3E)请求信息重启服务器中的定时器。m)服务器在处理先前请求，发送多帧信息应答的过程中。因此，服务器在接收到TesterPresent(0x3E)请求信息时，不应动作。因为定时器还没有重新激活。n)当诊断服务完全处理完了，服务器重启定时器。这是说，所有诊断服务包括TesterPresent(0x3E)都能重启定时器。诊断服务在接收到请求信息（N_USDataFF.ind和N_USData.ind）到完成最后结果应答的时间内都会执行。当需要应答信息时，或者当有请求导致的动作的完成但不需应答信息时（指定时间的到达导致的应答信息）。这包括否定应答信息（包括应答码0x78）。服务器在完成处理之后（最后结果信息完全发送）重启周期机制。o)一旦开启（非默认会话激活），导致功能地址TesterPresent(0x3E)的发送，不需要应答信息。每次在超时时。p)网络层通过N_USData.con指示TesterPresent(0x3E)请求信息发送完之时，客户机再次重启定时器。也就是说，功能地址TesterPresent（0x3E）请求信息在定时器每次超时的周期都发送。表42描述了CAN服务实施可用数据参数表42——数据参数定义——发送模式16进制数描述Cvt助记符01sendAtSlowRateUSASR02sendAtMediumRateUSAMR03sendAtFastRateUSAFR04stopSendingUSS9.3.5动态定义数据标识（DynamicallyDefineDataIdentifier）（0x2C）服务当客户机动态定义一个periodicDataIdentifier并且动态定义的periodicDataIdentifier总长超过了单帧周期应答信息最大长度时，该请求应通过应答码0x31(请求超出范围，requestOutOfRange)否定应答拒绝，见ReadDataByPeriodicIdentifier(9.3.4)参考周期应答信息格式。当多个DynamicallyDefineDataIdentifier请求信息用于设置单个的periodicDataIdentifier并且服务器检测到连续请求期间超出了最大字节数时，服务器应将该定义置位请求之前，以免超出。表43描述了CAN服务实施可用数据参数表43——子功能参数定义16进制数描述Cvt助记符01defineByIdentifierUDBID02defineByMemoryAddressUDBMA03clearDynamicallyDefinedDataIdentifierUCDDDI9.3.6通过标识写数据服务（WriteDataByIdentifier）(0x2E)对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.3.7通过地址写内存服务（WriteMemoryByAddress）(0x3D)9.4存储发送数据功能单元9.4.1读故障码信息服务（ReadDTCInformation）（19hex）表44描述了CAN服务实施可用数据参数表44——子功能参数定义进制（位6-0）描述Cvt助记符01通过状态掩码报告故障码个数URNODTCBSM02通过状态掩码报告故障码MRDTCBSM03短标识报告故障码信息URDTCSSI04记录号报告故障码信息URDTCSSBDTC05故障码号报告故障码信息URDTCSSBRN06故障码号报告故障码扩展数据记录URDTCEDRBDN07安全码记录报告故障码号URNODTCBSMR08安全码记录报告故障码URDTCBSMR09报告故障码安全信息URSIODTC0A报告支持的故障码URSUPDTC0B报告第一个测试失败的故障码URFTFDTC0C报告第一个确认的故障码URFCDTC0D报告近期测试失败最多的故障码URMRVDTC0E报告近期确认最多的故障码URMRCDTC0F状态掩码报告镜像内存故障码URMMDTCBSM10通过故障码号报告镜像内存故障码扩展数据记录URMMDEDRBDN11通过状态掩码报告镜像内存故障码个数URNOMMDTCBSM12状态掩码报告排放相关OBD故障码个数CRNOOBDDTCBSM13状态掩码报告排放相关OBD故障码CROBDDTCBSM表45描述了CAN服务实施可用故障码状态位故障码故障类型字节用于CAN服务中，则DTCFailureTypeByte定义应按照ISO15031-6.表45——DTC状态位定义位说明Cvt助记符排放的非排放0测试故障UUTF1在该监测循环检测故障MTFTMC2挂起的故障码MUPDTC3确认的故障码MMCDTC4从最近一次清除时测试未完成TNCSLC5从最近一次清除时测试故障TFSLC6该监测循环测试未完成MMTNCTMC7警告指示请求MUWIR：当位2（pendingDTC）支持的时候，位1（testFailedThisMonitoringCycle）是强制的，位2（pendingDTC）不支持的时候，位1（testFailedThisMonitoringCycle）为用户可选的。：位4（testNotPassedSinceLastClear）和位5(testNotFailedSinceLastClear)应当总是同时支持。9.4.2清故障码信息服务（ClearDiagnosticInformation）(0x14)表46描述了CAN服务实施可用数据参数表46——子功能参数定义——一组故障码16进制数描述Cvt助记符000000-FFFFFE单独/单个故障码USDTCFFFFFF所有组（所有故障码）MAGDTC9.5输入输出控制功能单元9.5.1输入输出控制标识服务（InputOutputControlByIdentifier）(0x2F)控制选项记录的第一个字节用作输入输出控制参数时，表47描述了CAN服务实施可用数据参数表46——子功能参数定义——输入输出控制参数16进制数描述Cvt助记符00返回控制到ECUURCTECU01重启到默认URTD02冻结当前状态UFCS03短期调整USTA9.6例程远程激活功能单元9.6.1例程控制服务（RoutineControl）(0x31)表48描述了CAN服务实施可用数据参数表48——子功能参数定义16进制数描述Cvt助记符01启动例程USTR02停止例程USTPR03请求例程结果URRR9.7上传/下载功能单元9.7.1请求下载服务（RequestDownload）(0x34)对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.7.2请求上传服务（RequestUpload）(0x35)对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.7.3传输数据服务（TransferData）（0x36）对于该项服务的CAN实施既没有定义另外的要求，也没有限制。9.7.4请求传输退出服务（RequestTransferExit）（0x37）对于该项服务的CAN实施既没有定义另外的要求，也没有限制。',)