ISO 14229-1-2020

服务流程

service request primitive（服务请求）

- 确认模式/未确认模式

service request-confirmation primitive（服务请求发送成功）

- 确认模式/未确认模式

service indication primitive（服务请求接收成功）

- 确认模式/未确认模式

service response primitive（服务应答）

- 确认模式

service response-confirmation primitive（服务应答发送成功）

- 确认模式

service confirmation primitive（服务应答接收成功）

- 确认模式

A_Mtype（诊断服务应用层数据格式）

• diagnostics                               -    A_SA，A_TA寻址
• remote diagnostics                 -    A_SA，A_TA及额外信息寻址
• secure diagnostics                  -    A_SA，A_TA寻址安全服务器
• secure remote diagnostics    -    A_SA，A_TA及额外信息寻址安全服务器

接口描述

service_name.type ( 

    parameter A, 

    parameter B, 

    parameter C 

    [,parameter 1, ...] 

) 

参数 A、B、C 为必填参数，参数 1... 为可选参数（根据诊断服务类型定义）

service request primitive（服务请求）

- 确认模式/未确认模式

request被诊断应用中的诊断服务客户端调用，以启动服务并将有关请求诊断服务的数据传递给应用层。

service_name.request ( 

    A_MType（消息类型）, 

    A_SA（源地址）, 

    A_TA（目标地址）, 

    A_TA_type（目标地址类型）, 

    [A_AE], 

    A_Length（数据长度）, 

    A_Data[,parameter 1, ...]（应用层数据）, 

)

service indication primitive（服务请求接收成功）

- 确认模式/未确认模式

indication被诊断应用中的诊断服务服务器调用，以指示对ECU诊断应用具有重要意义的内部事件，并将有关所请求诊断服务的数据传递给ECU诊断应用的服务器功能。

service_name.indication ( 

    A_MType（消息类型）, 

    A_SA（源地址）, 

    A_TA（目标地址）, 

    A_TA_type（目标地址类型）, 

    [A_AE], 

    A_Length（数据长度）, 

    A_Data[,parameter 1, ...]（应用层数据）, 

)

service response primitive（服务应答）

- 确认模式

response被诊断应用中的诊断服务服务器调用，以启动服务并将请求的诊断服务提供的响应数据传递给应用层。

service_name.response ( 

    A_MType（消息类型）, 

    A_SA（源地址）, 

    A_TA（目标地址）, 

    A_TA_type（目标地址类型）, 

    [A_AE], 

    A_Length（数据长度）, 

    A_Data[,parameter 1, ...]（应用层数据）, 

)

service confirmation primitive（服务应答接收成功）

- 确认模式

confirmation被诊断应用中的诊断服务客户端调用，以指示对客户端诊断应用很重要的内部事件，并将关联的先前服务请求的结果传递给诊断测试器诊断应用的客户端功能。

service_name.confirm ( 

    A_MType（消息类型）, 

    A_SA（源地址）, 

    A_TA（目标地址）, 

    A_TA_type（目标地址类型）, 

    [A_AE], 

    A_Length（数据长度）, 

    A_Data[,parameter 1, ...]（应用层数据）, 

)

对每个response和confirm，将指定两个不同的服务数据单元（两组参数）

• 如果请求的诊断服务可以由ECU中的服务器功能成功执行，则第一个服务数据单元应使用有效response和有效confirm。

• 如果请求的诊断服务失败或ECU中的服务器功能无法及时完成，则第二个服务数据单元应使用无效response和无效confirm。

参数类型

A_MType（消息类型）

数据类型：枚举

取值范围：

• diagnostics                               -    A_SA，A_TA寻址
• remote diagnostics                 -    A_SA，A_TA及额外信息寻址
• secure diagnostics                  -    A_SA，A_TA寻址安全服务器
• secure remote diagnostics    -    A_SA，A_TA及额外信息寻址安全服务器

参数描述：

参数MType应用于识别7.2中规定的车辆诊断系统的格式，本文档为该参数指定了四个值的范围：

• If A_Mtype = diagnostics, then the service_name primitive shall consist of the parameters A_SA, A_TA and A_TAtype. 
• If A_Mtype = remote diagnostics, then the service_name primitive shall consist of the parameters A_SA, A_TA, A_TAtype and A_AE. 
• If A_Mtype = secure diagnostics, then the service_name primitive shall consist of the parameters A_SA, A_TA and A_TAtype. 
• If A_Mtype = secure remote diagnostics, then the service_name primitive shall consist of the parameters A_SA, A_TA, A_TAtype and A_AE.

A_SA（源地址）

数据类型：2字节无符号整数

取值范围：0x0000 to 0xFFFF

参数描述：

参数SA应用于编码客户端和服务器标识符。

对于service request（和service indication），A_SA 表示已请求诊断服务的客户端功能的地址。每个请求诊断服务的客户端功能都应以一个 A_SA 值表示。如果在同一诊断测试仪中实现多个客户端功能，则每个客户端功能都应具有自己的客户端标识符和相应的 A_SA 值。

对于service response（和service confirmation），A_SA 表示已执行所请求诊断服务的服务器功能的地址。服务器功能可以仅在一个 ECU 中实现，也可以分布在多个 ECU 中实现。如果服务器功能仅在一个 ECU 中实现，则应仅使用一个 A_SA 值对其进行编码。如果服务器功能分布在多个 ECU 中实现，则应为每个单独的服务器功能分配一个 A_SA 值，该值为代表各自的服务器功能地址经编码后的值。

如果远程客户端或服务器是消息的原始来源，则 A_SA 代表本地服务器，即从远程网络到主网络的网关。注意：如果request消息使用了物理寻址，则response消息中的 A_SA 值将与相应request消息中的 A_TA 值相同。

A_TA（目标地址）

数据类型：2字节无符号整数

取值范围：0x0000 to 0xFFFF

参数描述：

参数 A_TA 应用于编码客户端和服务器标识符。

有以下两种寻址方式：

• 物理寻址
• 功能寻址

因此，可以为车辆系统定义两组独立的目标地址（每种寻址方法各一组）。

物理寻址应始终是给在一个 ECU 中实现的服务器的专用消息。当使用物理寻址时，通信是客户端和服务器之间的点对点通信。

如果客户端不知道响应诊断服务请求的服务器功能的物理地址，或者服务器功能在多个 ECU 中作为分布式功能实现，则客户端将使用功能寻址。使用功能寻址时，通信是从客户端到在一个或多个 ECU 中实现的服务器的广播通信。

对于service request（和service indication），A_TA 表示应执行所请求诊断服务的服务器的服务器标识符。如果正在寻址远程服务器，则 A_TA 表示本地服务器，即从主网络到远程网络的网关。

对于service response（和service confirmation），A_TA 表示最初请求诊断服务并应接收请求数据的客户端功能的地址（即request的 A_SA）。service response（和service confirmation）应始终使用物理寻址。如果要寻址远程客户端，则 A_TA 表示本地服务器，即从主网络到远程网络的网关。注意：response消息的 A_TA 值始终与相应request消息的 A_SA 值相同。

A_TA_type（目标地址类型）

数据类型：枚举

取值范围：

• physical
• functional

参数描述：

参数 A_TA_type 是 A_TA 参数的扩展，用于表示消息传输所选择的寻址方法。

A_Result（发送结果）

数据类型：枚举

取值范围：

• ok
• error

参数描述：

req_confirm 和 rsp_confirm 原语使用参数“A_Result”来指示消息是否已正确传输（ok）或者消息传输是否失败（error）。

A_Length（数据长度）

数据类型：4字节无符号整数

取值范围：0x0 to (0xFFFFFFFF - 1)

参数描述：

参数 A_Length 包括要发送/接收的数据的长度。

A_Data（应用层数据）

数据类型：多字节字符串

取值范围：不适用

参数描述：

参数 A_Data 包括上层实体要交换的所有数据。

A_AE（可选参数，应用层远端地址）

数据类型：2字节无符号整数

取值范围：0x0000 to 0xFFFF

参数描述：

A_AE 用于扩展可用地址范围以对客户端和服务器标识符进行编码。A_AE 仅应在实现本地服务器和远程服务器概念的车辆中使用。远程地址代表其自己的地址范围，并且独立于主网络上的地址。

参数 A_AE 应用于对远程客户端和服务器标识符进行编码。A_AE 可以表示远程目标地址或远程源地址，具体取决于携带 A_AE 的消息的方向。

对于主网络上的客户端发送的service request（和service indication），A_AE 代表应执行请求的诊断服务的服务器的远程服务器标识符（远程目标地址）。

A_AE 既可用作物理地址，又可用作功能地址。对于 A_AE 的每个值，系统构建者应指定该值是代表物理地址还是功能地址。

A_TA_type 指定 A_TA 的寻址方法时，没有表示物理或功能远程地址的特殊参数。物理和功能远程地址共享相同的 1 字节值范围，每个值的含义应由系统构建者定义。

对于远程服务器发送的service response（和service confirmation），A_AE 表示已执行请求的诊断服务的远程服务器的物理位置（远程源地址）。

远程服务器可以只在一个 ECU 中实现，也可以分布在多个 ECU 中实现。如果远程服务器只在一个 ECU 中实现，则应仅用一个 A_AE 值对其进行编码。如果远程服务器分布在多个 ECU 中实现，则应针对远程服务器的每个物理位置用一个 A_AE 值对远程服务器标识符进行编码。

附加

车辆制造商应确保系统中的每个服务器都具有唯一的服务器标识符。车辆制造商还应确保系统中的每个客户端都具有唯一的客户端标识符。

车辆系统中诊断网络的所有客户端和服务器地址都应编码到同一源地址范围中。这意味着在给定的车辆系统中，客户端和服务器不应由相同的 A_SA 值表示。

服务器的物理目标地址应始终与服务器的源地址相同。

远程服务器标识符可以独立于主网络上的客户端和服务器标识符进行分配。

一般来说，只有被寻址的服务器才会响应客户端请求消息。

协议

A_PDU（应用层协议数据单元）直接由 A_SDU（应用层服务数据单元）和层特定控制信息 A_PCI（应用层协议控制信息）构成。A_PDU 应具有以下通用格式：

A_PDU ( 

    Mtype, 

    SA, 

    TA, 

    TA_type, 

    [RA,] 

    A_Data = A_PCI + [parameter 1, ...], 

    Length 

)

• “Mtype、SA、TA、TA_type、RA、Length”与 A_SDU 中使用的参数相同。
• “A_Data” 是为每个单独的应用层服务定义的字节数据字符串。A_Data 字符串应以 A_PCI 开头，后跟每个服务指定的 A_SDU 中的所有服务特定参数。括号表示参数列表的这一部分可以为空。
• “Length”决定 A_Data 的字节数。

A_PCI 包含两种格式。格式由 A_PDU（A_PCI ？😂） 参数的第一个字节的值标识。

对于所有服务请求以及第一个字节不等于 0x7F 的服务响应，应适用以下定义：

A_PCI ( 

    SI 

)

• “SI”为服务标识符。

对于第一个字节等于 0x7F 的服务响应，应适用以下定义：

A_PCI ( 

    NR_SI, 

    SI 

)

• “NR_SI”是识别否定服务response/confirmation的特殊参数；
• “SI”为服务标识符。

注意：对于服务 ReadDataByPeriodicIdentifier（0x2A，参见 11.5）中定义的周期性数据响应消息的传输，应用层协议数据单元 (A_PDU) 中不存在 A_PCI。

SI（服务标识符）

数据类型：1字节无符号整数

取值范围：0x00 to 0xFF 按照表2中的定义

参数描述：

应使用 SI 对服务原语中调用的具体服务进行编码。每个请求服务都应分配一个唯一的 SI 值。每个肯定响应服务都应分配一个相应的唯一 SI 值。

服务标识符用于表示从应用层传递到较低层（并从较低层返回）的 A_Data 数据字符串中的服务。

A_NR_SI（否定响应服务标识符）

数据类型：1字节无符号整数

固固定值：0x7F

参数描述：

NR_SI 参数是用于标识否定服务response/confirmation的特殊参数。它应为否定response/confirmation消息的 A_PCI 的一部分。

NR_SI 值与 SI 值协调一致。NR_SI 值不作为 SI 值使用，是为了使 A_Data 编码和解码更加容易。

否定response/confirmation服务原语

每项诊断服务均具有否定response/否定confirmation消息，该消息根据表 3 用消息 A_Data 字节指定。

第一个 A_Data 字节 (A_PCI.NR_SI) 始终是特定的否定响应服务标识符。

第二个 A_Data 字节 (A_PCI.SI) 应为否定响应消息对应的服务request/indication消息中的服务标识符值的副本。

参数responseCode用于否定响应消息中，表示诊断服务失败或无法及时完成的​​原因。其值定义在A.1中。

service response实现规则

缩写解释：

suppressPosRspMsgIndicationBit

• TRUE  = 服务器不应发送肯定响应消息（例外情况请参阅 NRC 7816 定义中的 A.1）
• FALSE = 服务器应发送肯定或否定响应消息

PosRsp

• 肯定响应消息的缩写

NegRsp

• 否定响应消息的缩写

NoRsp

• 不发送肯定或否定响应消息的缩写

NRC

• 否定响应代码的缩写

ALL

• 服务器支持客户端请求消息的所有请求数据参数

At least 1

• 服务器应支持客户端请求消息的至少 1 个数据参数

None

• 服务器不支持客户端请求消息中所请求的数据参数

DataParam

• 数据参数

SI

• 服务标识符

SF

• 子功能

无论寻址模式如何（物理、功能寻址类型），服务器都应支持其诊断服务列表。

重要信息：

根据以下子条款中表格的要求，当request消息使用功能寻址时，带有 

• SNS         (serviceNotSupported)
• SNSIAS   (serviceNotSupportedInActiveSession)
• SFNS       (SubFunctionNotSupported)
• SFNSIAS (SubFunctionNotSupportedInActiveSession)
• ROOR      (requestOutOfRange)

否定响应代码的否定response消息不应被传输（例外情况参见 NRC 7816 定义中的 A.1）。

一般服务器响应行为

本节中指定的一般服务器响应行为对于所有请求消息都是强制性的。验证步骤从接收请求消息开始。该图分为三个小节：

mandatory（强制）：

• 由每个请求消息进行评估。

optional（可选）：

• 可以由每个请求消息选择性地评估。

manufacturer/supplier specific（制造商/供应商特定）：

• 可以通过额外的制造商/供应商特定检查来扩展该程序。

根据指定 NRC 处理的所有图中实现的选择，不能保证所有可能的测试模式序列都具有特定的 NRC。

带有 SubFunction 参数的request消息和服务器响应行为

本子条款中指定的一般服务器响应行为对于带有 SubFunction 参数的所有request消息都是强制性的。本子条款上下文中的request消息被定义为遵循本文档中定义的格式要求的服务request消息。图 6 描述了带有 SubFunction 参数的request消息的一般服务器响应行为。

物理寻址的客户端request消息

本节中指定的服务器响应行为在每个服务的服务描述中引用，该服务支持从客户端接收到的物理寻址request消息中的 SubFunction 参数。

• a) 服务器发送肯定响应消息
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 并指示响应消息
• b) 服务器发送否定响应消息（例如 IMLOIF：不正确的消息长度或错误格式）
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 但在处理 SubFunction 期间，出现了一些其他错误（例如，根据请求消息中的服务标识符和 SubFunction 参数，PDU 长度错误）
• c) 服务器发送带有否定响应代码 ROOR (requestOutOfRange) 的否定响应消息
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 但客户端的request消息的数据参数不被服务器支持
• d) 服务器发送带有否定响应代码 SNS (serviceNotSupported) 或 SNSIAS (serviceNotSupportedInActiveSession) 的否定响应消息
• 因为客户端request中的服务标识符参数不被服务器支持
• e) 服务器发送带有否定响应代码 SFNS (SubFunctionNotSupported) 或 SFNSIAS (SubFunctionNotSupportedInActiveSession) 的否定响应消息
• 因为客户端request中的服务标识符参数被服务器支持
• 但客户端request中的 SubFunction 参数不被服务器支持
• f) 服务器不发送响应消息，
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 并指示无响应消息

如果使用否定响应代码RCRRP（requestCorrectlyReceivedResponsePending），则应独立于suppressPosRspMsgInductionBit 值给出最终响应。

• g) 与 b) 中的效果相同（即发送否定响应消息）
• 因为对于在接收到物理寻址request消息时需要发送的任何否定响应
• 都会忽略suppressPosRspMsgIndicationBit
• h) 与 c) 中的效果相同（即发送否定响应消息）
• 因为对于在接收到物理寻址request消息时需要发送的任何否定响应
• 都会忽略suppressPosRspMsgIndicationBit
• i) 与 d) 中的效果相同（即发送否定响应消息）
• 因为对于在接收到物理寻址request消息时需要发送的任何否定响应
• 都会忽略suppressPosRspMsgIndicationBit
• j) 与 e) 中的效果相同（即发送否定响应消息）
• 因为对于在接收到物理寻址request消息时需要发送的任何否定响应
• 都会忽略suppressPosRspMsgIndicationBit

功能寻址客户端request消息

本小节中规定的服务器响应行为在每个服务的服务描述中被引用，该服务支持从客户端接收的功能寻址request消息中的 SubFunction 参数。

• a) 服务器发送肯定响应消息
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 并指示响应消息
• b) 服务器发送否定响应消息（例如 IMLOIF：不正确的消息长度或错误格式）
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 但在处理 SubFunction 期间，出现了一些其他错误（例如，根据请求消息中的服务标识符和 SubFunction 参数，PDU 长度错误）
• c) 服务器不发送响应消息
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 ROOR（requestOutOfRange，服务器识别该代码是因为支持服务标识符和 SubFunction 参数，但不支持客户端请求所需的数据参数）
• 在这种情况下，suppressPosRspMsgIndicationBit 无关紧要
• d) 服务器不发送响应消息
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 SNS (serviceNotSupported) 和 SNSIAS (serviceNotSupportedInActiveSession)
• 在这种情况下，suppressPosRspMsgIndicationBit 无关紧要
• e) 服务器不发送响应消息
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 SFNS (SubFunctionNotSupported) 和 SFNSIAS (SubFunctionNotSupportedInActiveSession)
• 在这种情况下，suppressPosRspMsgIndicationBit 无关紧要
• f) 服务器不发送响应消息，
• 因为客户端request中的服务标识符和 SubFunction 参数被服务器支持
• 并指示无响应消息

如果使用否定响应代码RCRRP（requestCorrectlyReceivedResponsePending），则应独立于suppressPosRspMsgInductionBit 值给出最终响应。

• g) 与 b) 中的效果相同（即发送否定响应消息）
• 因为对于在接收到功能寻址request消息时需要发送的任何否定响应
• 都会忽略suppressPosRspMsgIndicationBit
• h) 与 c) 中的效果相同（即不发送响应消息）
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 ROOR（requestOutOfRange，服务器识别该代码是因为支持服务标识符和 SubFunction 参数，但不支持客户端请求所需的数据参数）
• 在这种情况下，suppressPosRspMsgIndicationBit 无关紧要
• i) 与 d) 中的效果相同（即不发送响应消息）
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 SNS (serviceNotSupported) 和 SNSIAS (serviceNotSupportedInActiveSession)
• 在这种情况下，suppressPosRspMsgIndicationBit 无关紧要
• j) 与 e) 中的效果相同（即不发送响应消息）
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 SFNS (SubFunctionNotSupported) 和 SFNSIAS (SubFunctionNotSupportedInActiveSession)
• 在这种情况下，suppressPosRspMsgIndicationBit 无关紧要

不带 SubFunction 参数的request消息和服务器响应行为

对于不带 SubFunction 参数的request消息，没有通用的服务器响应行为。本节上下文中的request消息定义为遵守本文档中定义的格式要求的服务request消息。

物理寻址的客户端request消息

本节中指定的服务器响应行为在每个服务的服务描述中引用，该服务不支持 SubFunction 参数，但是支持从客户端接收的物理寻址request消息中的数据参数。

表 6 显示了具有物理寻址的可能的通信方案。

• a) 服务器发送肯定响应消息
• 因为客户端request中的服务标识符和所有数据参数被服务器支持
• b) 服务器发送肯定响应消息
• 因为客户端request中的服务标识符和至少一个数据参数被服务器支持
• c) 服务器发送否定响应消息（例如 IMLOIF：不正确的消息长度或错误格式）
• 因为客户端request中的服务标识符和至少一个数据参数被服务器支持
• 但在处理服务期间，出现了一些其他错误（例如，根据请求消息中的服务标识符和数据参数，PDU 长度错误）
• d) 服务器发送带有否定响应代码 ROOR (requestOutOfRange) 的否定响应消息
• 因为客户端request中的服务标识符被服务器支持
• 但客户端的request消息的任何数据参数都不被服务器支持
• e) 服务器发送带有否定响应代码 SNS (serviceNotSupported) 或 SNSIAS (serviceNotSupportedInActiveSession) 的否定响应消息
• 因为客户端request中的服务标识符参数不被服务器支持

功能寻址客户端request消息

本节中指定的服务器响应行为在每个服务的服务描述中引用，该服务不支持 SubFunction 参数，但是支持从客户端接收的功能寻址request消息中的数据参数。

表 7 显示了具有功能寻址的可能的通信方案。

• a) 服务器发送肯定响应消息
• 因为客户端request中的服务标识符和所有数据参数被服务器支持
• b) 服务器发送肯定响应消息
• 因为客户端request中的服务标识符和至少一个数据参数被服务器支持
• c) 服务器发送否定响应消息（例如 IMLOIF：不正确的消息长度或错误格式）
• 因为客户端request中的服务标识符和至少一个、多个或所有数据参数被服务器支持
• 但在处理服务期间，出现了一些其他错误（例如，根据请求消息中的服务标识符和数据参数，PDU 长度错误）
• d) 服务器不发送响应消息
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 ROOR（requestOutOfRange，服务器识别该代码是因为支持服务标识符，但不支持客户端请求所需的数据参数）
• e) 服务器不发送响应消息
• 因为在功能寻址request消息的情况下，始终忽略否定响应代码 SNS (serviceNotSupported) 和 SNSIAS (serviceNotSupportedInActiveSession)

服务器响应行为的伪代码示例

以下是服务器伪代码示例，描述服务器在接收来自客户端的request时应执行的逻辑步骤。

SWITCH (A_PDU.A_Data.A_PCI.SI)

{

    CASE Service_with_SubFunction: /* test if service with SubFunction is supported */

        IF (message_length >= 2) THEN /* check minimum length of message with SubFunction */

            SWITCH (A_PDU.A_Data.A_Data.Parameter1 & 0x7F) /* get SubFunction parameter value without bit 7 */

            {

                CASE SubFunction_00: /* test if SubFunction parameter value is supported */

                    /* prepare response message */

                    IF (message_length == expected_SubFunction_message_length) THEN 

                        responseCode = positiveResponse; /* pos. response message; set internal NRC = 0x00 */

                    ELSE

                        responseCode = IMLOIF; /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */

                    ENDIF

                    BREAK;

                CASE SubFunction_01: /* test if SubFunction parameter value is supported */

                    /* prepare response message */

                    responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */

                    BREAK;

                CASE SubFunction_127: /* test if SubFunction parameter value is supported */

                    /* prepare response message */

                    responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */

                    BREAK;

                DEFAULT:

                    responseCode = SFNS; /* NRC 0x12: SubFunctionNotSupported */

            }

        ELSE

            responseCode = IMLOIF; /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */

        ENDIF

        suppressPosRspMsgIndicationBit = (A_PDU.A_Data.Parameter1 & 0x80); /* results in either 0x00 or 0x80 */

        IF ( 

            (suppressPosRspMsgIndicationBit) && 

            (responseCode == positiveResponse) &&

            (“not yet a NRC 0x78 response sent”)

        ) THEN /* test if pos. response is required and if responseCode is positive 0x00 */

            suppressResponse = TRUE; /* flag to NOT send a positive response message */

        ELSE

            suppressResponse = FALSE; /* flag to send the response message */

        ENDIF

        BREAK;

    CASE Service_without_SubFunction: /* test if service without SubFunction is supported */

        suppressResponse = FALSE; /* flag to send the response message */

        IF (message_length == expected_message_length) THEN

            IF (A_PDU.A_Data.Parameter1 == supported) THEN /* test if data-parameter following the SID is supported*/

                /* read data and prepare response message */

                responseCode = positiveResponse; /* positive response message; set internal NRC = 0x00 */

            ELSE

                responseCode = ROOR; /* NRC 0x31: requestOutOfRange */

            ENDIF

        ELSE

            responseCode = IMLOIF; /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */

        ENDIF

    BREAK;

    DEFAULT:

        responseCode = SNS; /* NRC 0x11: serviceNotSupported */

}

IF (

    A_PDU.TA_type == functional && 

    (

        (responseCode == SNS) ¦¦ 

        (responseCode == SFNS) ¦¦ 

        (responseCode == SNSIAS) ¦¦ 

        (responseCode == SFNSIAS) ¦¦ 

        (responseCode == ROOR)

    ) &&

    (“not yet a NRC 0x78 response sent”)

) THEN 

    /* suppress negative response message */

ELSE

    IF (suppressResponse == TRUE) THEN 

        /* suppress positive response message */

    ELSE

 

        /* send negative or positive response */

    ENDIF

ENDIF

当request消息采用功能寻址，且需要发送NRC=RCRRP（requestCorrectlyReceivedResponsePending）的否定响应消息时，如果最终的否定响应消息是收到的request消息的PDU分析的结果，则还应发送使用 

• NRC=SNS（serviceNotSupported）
• NRC=SNSIAS（serviceNotSupportedIn-ActiveSession）
• NRC=SFNS（SubFunctionNotSupported）
• NRC=SFNSIAS（SubFunctionNotSupportedIn-ActiveSession）
• NRC=ROOR（requestOutOfRange）

的最终的否定响应消息。

具有物理和功能寻址的多个并发request消息

常见的服务器实现在服务器中只有一个可用的诊断协议实例。一个诊断协议实例一次只能处理一个请求。规则是，任何收到的消息（无论寻址模式是物理寻址还是功能寻址）都会占用此资源，直到request消息被处理完成（发送最终响应或无响应的应用程序调用）。

只有两种例外情况需分别处理：

• 客户端使用 Keep-Alive-Logic 来使先前启用的会话在一个或多个服务器中保持活动状态。Keep-Alive-Logic 定义为 SPRMIB=true 的功能寻址有效 TesterPresent 消息，应由旁路逻辑处理。服务器应确保这种特定的消息不会“阻塞”服务器的应用层，并确保可以处理紧随其后的寻址消息。
• 如果支持 0x00 至 0x0F 范围内服务的服务器收到 0x00 至 0x0F 范围内的诊断请求，则应中止 0x00 至 0x0F 范围之外的任何活动服务，启动默认会话，并处理 0x00 至 0x0F 范围内的诊断服务。如果编程会话处于活动状态，则此要求不适用。

服务描述约定

服务描述

本小节简要概述了服务的功能。每项诊断服务规范都以对客户端和服务器执行的操作的描述开始，这些操作特定于每项服务。每项服务的描述都包含一个表格，其中列出了其原语的参数：request/indication、对肯定或否定结果的response/confirmation。所有原语都具有相同的结构：

对于给定的request/indication和response/confirmation A_PDU 定义，每个参数的存在由以下约定 (Cvt) 值之一描述：

表8规定了A_PDU参数约定。

request消息

本子条款包括一个或多个表格，定义服务request/indication的 A_PDU（应用层协议数据单元，见第 8 条款）参数。如果不同 SubFunction 参数 ($Level) 的request消息在 A_Data 参数的结构上有所不同，并且无法在单个表格中明确指定，则每个 SubFunction 参数 ($Level) 可能有一个单独的表格。

表9指定带有 SubFunction 的request A_PDU 定义

注：上表所示的寻址信息仅用于定义目的。进一步的服务request/indication定义仅指定 A_PDU.A_Data 参数，因为 A_PDU.A_Data 参数表示服务request/indication的消息数据字节。

request消息 SubFunction 参数 $Level (LEV_) 定义

本节规定了为服务<服务名称>的request/indication定义的 SubFunction $Levels（LEV_）参数。

如果所描述的服务不使用 SubFunction 参数值并且不使用 suppressPosRspMsgIndicationBit（这隐含地表明需要响应），则本节不包含任何定义。

SubFunction 参数字节分为两部分（按bit级别），如表 11 所定义。

除 suppressPosRspMsgIndicationBit 之外，支持 SubFunction 参数值的服务应支持 SubFunction 参数值表中定义的 SubFunction 参数值。

每个服务都包含一个表，该表定义 SubFunction 参数值的值，仅考虑bit 0-6。

注意：如果对于包含大量数据的响应，SPRMIB 为 TRUE，则需要使用分页缓冲区处理，这可能会导致以下情况：

• 第一批数据的传输仍可在响应时间窗口内开始，但当服务执行结束时，时间已超出了响应时间窗口的限制。
• 如果在这种情况下抑制响应，则无法通知客户端有关延迟的信息，并且服务器仍然处于繁忙状态，尚未准备好接收另一个request。

对于客户端，建议不要在同一request中请求大量数据并且设置 SPRMIB（例如 SID 0x19 SF 0x0A），因为这会违背 SPRMIB 的目的。对于服务器实现，建议在发送 NRC 0x78（RCRRP）后，也发送肯定response，以防在 SPRMIB 为 TRUE 时使用分页缓冲区处理。

表 12 指定了request消息中的 SubFunction 参数定义。

表 14 规定了 SubFunction 字节值的计算。

request消息数据参数定义

本小节规定了服务 <服务名称> 的request/indication的数据参数 $DataParam (DP_)。如果所述服务不使用任何数据参数，则本小节不包含任何定义。数据参数部分可以包含多个字节。

本小节提供了每个数据参数的通用描述。详细定义可在本文档的附件中找到。具体附件取决于服务。附件还规定了是否应支持数据参数，或者在服务器支持服务的情况下用户可选择是否支持。

表 15 指定了request消息的数据参数。

肯定response消息

本小节规定了服务response/confirmation的 A_PDU 参数（应用层协议数据单元 A_PDU 的详细描述见 8.2）。当不同 SubFunction 参数 $Level 的response消息在 A_Data 参数的结构上有所不同时，每个 SubFunction 参数 $Level 可能有一个单独的表。

诊断服务的肯定response消息（如果需要）应在诊断服务执行后发送。如果诊断服务需要不同的处理（例如 ECUReset 服务），则可以在诊断服务的服务描述中找到何时发送肯定response消息的适当描述。

表 16 规定了肯定response A_PDU。

注：上表中显示的寻址信息仅用于定义目的。进一步的服务response/confirmation定义仅指定 A_PDU.A_Data 参数，因为 A_PDU.A_Data 参数表示服务response/confirmation的消息数据字节。

肯定response消息数据参数定义

本小节规定了服务 <服务名称> 的response/confirmation的数据参数。如果所述服务不使用任何数据参数，则本小节不包含任何定义。数据参数部分可以包含多个字节。

本小节提供了每个数据参数的通用描述。详细定义可在本文档的附件中找到。具体附件取决于服务。附件还规定了是否应支持数据参数，或者在服务器支持服务的情况下用户可选择是否支持。

表 17 指定了response数据参数。

支持的否定响应代码 (NRC_)

本小节规定了应为该服务实施的否定响应代码。下表记录了每个响应代码发生的情况。否定response消息的定义可在 8.6 中找到。服务器应使用否定响应 A_PDU 来指示已识别的错误情况。

除每个服务描述中指定的否定响应代码外，还应使用 A.1 中列出的否定响应代码（如果适用）。详情可在 A.1 中找到。

表 18 规定了支持的否定响应代码。

附件A（规范性）

A.1 否定响应代码

表 A.1 定义了本文档中使用的所有否定响应代码。每个诊断服务都指定了适用的否定响应代码。服务器中的诊断服务实现还可以使用本文中指定的由车辆制造商定义的其他适用否定响应代码。

否定响应代码范围 0x00 至 0xFF 分为三个范围：

• 0x00：
• 服务器内部实现的 positiveResponse 参数值
• 0x01 至 0x7F：
• 与通信相关的否定响应代码
• 0x80 至 0xFF：
• 否定响应代码，表示在服务器收到request时特定条件不正确。
• 只要响应代码 0x22（条件不正确）被列为有效，就可以使用这些响应代码，以便更具体地报告无法采取所请求操作的原因。

消息流示例

本小节包含服务 <服务名称> 的消息流示例。所有示例均显示在消息级别（不包含寻址信息）。

表 19 指定了request消息流示例。

表 21 显示了否定响应消息的消息流示例。

诊断和通讯管理功能单元

表22规定了诊断和通信管理功能单元。

DiagnosticSessionControl（0x10）服务

- 诊断和通讯管理功能

服务描述

DiagnosticSessionControl 服务用于在服务器中启用不同的诊断会话。

诊断会话在服务器中启用一组特定的诊断服务和/或功能。此服务提供的功能是服务器可以报告对已启用的诊断会话有效的数据链路层特定参数值（例如，定时参数值）。本文档的用户应定义在每个诊断会话中启用的确切服务和/或功能集。

服务器中应始终只有一个诊断会话处于活动状态。服务器应始终在通电时启动默认诊断会话。如果没有启动其他诊断会话，则只要服务器通电，默认诊断会话就应运行。

服务器应能够在正常运行条件和车辆制造商定义的其他运行条件（例如，跛行回家运行条件）下提供诊断功能。如果客户端已请求正在运行的诊断会话，则服务器应发送肯定request消息，并按照图 7 所示的方式运行，该图描述了在会话之间转换时服务器的内部行为。

• 每当客户端请求新的诊断会话时，服务器应在新会话的计时在服务器中被激活之前
• 发送 DiagnosticSessionControl 肯定response消息。

• 某些情况下可能要求在发送肯定response之前
• 进入新会话，同时保持旧协议的响应计时。

• 如果服务器无法启动请求的新诊断会话
• 则它应以 DiagnosticSessionControl 否定response消息进行响应，
• 并且当前会话将继续（有关服务器和客户端应如何表现的更多信息，请参阅诊断会话参数定义）。

• 非默认诊断会话（不包括编程会话）中的诊断服务和诊断功能集是默认会话中提供的功能的超集
• 这意味着在切换到任何非默认诊断会话时，默认会话的诊断功能也可用。
• 会话可以启用车辆制造商特定的服务和功能，这些服务和功能不属于本文档的一部分。

要启动新的诊断会话，服务器可能会要求满足某些条件。所有这些条件都是用户定义的。这些条件的示例包括：

• 服务器可能只允许具有特定客户端标识符（客户端诊断地址）的客户端启动特定的新诊断会话（例如，服务器可能要求只有具有客户端标识符 0xF4 的客户端才可以启动扩展诊断会话）。

• 可能需要满足某些安全条件（例如，车辆不得移动或发动机不得运转）。例如，转换到编程会话可能会导致正常功能的丧失，因此某些 ECU 可能要求车辆处于安全状态。

在某些系统中，当启动新的诊断会话时，需要更改通信计时参数。诊断会话控制服务实体可以使用适当的服务原语来更改底层指定的计时参数，以更改本地节点中的通信计时，并可能更改客户端想要与之通信的节点中的通信计时。

图 7 概述了诊断会话转换以及服务器在转换到另一个会话时应执行的操作。

Key

• 1. 默认会话：
• 当服务器处于默认会话中并且客户端请求启动默认会话时，服务器应完全重新初始化默认会话。服务器应重置激活会话期间所有激活/启动/更改的设置/控件。这不包括编入非易失性存储器的长期更改

• 2. 默认会话转换到任何其他会话：
• 当服务器从默认会话转换到除默认会话之外的任何其他会话时，服务器应仅暂停在默认会话期间通过 ResponseOnEvent (0x86) 服务在服务器中配置的事件（类似于自非默认会话处于活动状态以来的时间段内的 stopResponseOnEvent）。

• 3. 相同或其他会话：
• 当服务器从默认会话以外的任何诊断会话转换到默认会话以外的另一个会话（包括当前活动的诊断会话）时，服务器应（重新）初始化诊断会话，这意味着：

• 通过 ResponseOnEvent (0x86) 服务在服务器中配置的每个事件都应停止

• 安全访问应重新锁定。安全访问的锁定应重置任何依赖于安全访问解锁状态的活动诊断功能（例如，DID 的活动输入输出控制）

• 新会话中支持的、不依赖于安全访问的所有其他活动诊断功能均应保留。例如，任何配置的定期调度程序在从一个非默认会话转换到另一个或同一个非默认会话时都应保持活动状态，并且 CommunicationControl 和 ControlDTCSetting 的状态不应受到影响，这意味着在会话切换期间，正常通信应保持禁用状态

• 4. 转换到默认会话：
• 当服务器从默认会话以外的任何诊断会话转换到默认会话时，服务器应恢复通过 ResponseOnEvent (0x86) 服务在服务器中配置的每个事件，并且事件窗口仍然有效。

• 此外，应在服务器中激活锁定的安全级别。应终止默认会话中不支持的任何其他活动诊断功能。例如，应禁用任何配置的定期调度程序或输出控制，并应重置 CommunicationControl 和 ControlDTCSetting 服务的状态，这意味着在会话切换到默认会话时，应重新启用被禁用的正常通信。

• 服务器应重置激活会话期间所有激活/启动/更改的设置/控件。这不包括编入非易失性存储器的长期更改

表 23 指定了默认会话和非默认会话（定时服务）期间允许的服务。任何非默认会话都与诊断会话计时器绑定，该计时器应由客户端保持活动状态。

request消息

表 24 指定了request消息。

request消息 SubFunction 参数 $Level (LEV_) 定义

DiagnosticSessionControl 服务使用 SubFunction 参数 diagnosticSessionType 来选择服务端的具体行为。表 25 详细说明了可能的诊断会话的解释和用法。

指定了以下 SubFunction 值（未显示 suppressPosRspMsgIndicationBit（bit 7））。

肯定response消息定义

表 26 指定了肯定response消息定义。

肯定response消息数据参数定义

表 27 指定了response数据参数参数定义。

表 28 和表 29 定义了适用于在支持的数据链路上实施此服务的response消息数据参数 sessionParameterRecord 的结构。

支持的否定响应代码 (NRC_)

应为该服务实现以下否定响应代码。表 30 记录了每个响应代码发生的情况。如果错误场景适用于服务器，则应使用列出的否定response。

消息流示例 DiagnosticSessionControl – 开始 programmingSession

此消息流显示如何在服务器中启用诊断会话“programmingSession”。客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的 bit 7）设置为“FALSE”（“0”）来请求获取response消息。对于给定的示例，假设 P2Server_max 等于 50 毫秒，P2*Server_max 等于 5 000 毫秒。

表 31 指定了 DiagnosticSessionControl request消息流示例 #1。

ECUReset（0x11）服务

- 诊断和通讯管理功能

服务描述

客户端使用 ECUReset 服务来请求服务器重置。

此服务请求服务器根据嵌入在 ECUReset request消息中的 resetType 参数值的内容有效地执行服务器重置。ECUReset 肯定response消息（如果需要）可以在服务器执行重置之前或之后发送。

强烈建议在执行 ECU 重置之前发送 ECUReset 肯定response消息。

重要提示 — 服务器和客户端应满足 8.7 中规定的request和response消息行为。

本文档未定义从对 ECU 重置请求的肯定response消息之后到重置成功完成期间 ECU 的行为。建议在此期间 ECU 不接受任何request消息，也不发送任何response消息。

request消息

表 33 指定了request消息定义。

request消息 SubFunction 参数 $Level (LEV_) 定义

ECUReset request消息使用 SubFunction 参数 resetType 来描述服务端应如何执行重置（未显示 suppressPosRspMsgIndicationBit（bit 7））。

表 34 指定了request消息中的 SubFunction 参数定义。

肯定response消息定义

表 35 指定了肯定response消息。

肯定response消息数据参数定义

表 36 指定了response数据参数参数定义。

支持的否定响应代码 (NRC_)

应为该服务实现以下否定响应代码。表 37 记录了每个响应代码发生的情况。如果错误场景适用于服务器，则应使用列出的否定响应。

消息流示例 ECUReset

本小节规定了成功执行服务器中的 ECUReset 服务所需要满足的示例条件。

服务器条件：点火 = 开启，系统不得处于运行模式（例如，如果系统是发动机管理，则发动机应关闭）。

客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的 bit 7）设置为“FALSE”来请求response消息。

服务器应在执行 resetType 之前发送 ECUReset 肯定response消息。

表 38 规定了 ECUReset request消息流示例 #1。

SecurityAccess（0x27）服务

- 诊断和通讯管理功能

服务描述

此服务的目的是提供一种访问数据和/或诊断服务的方法，这些服务的访问因安全、排放或安全原因而受到限制。将例程或数据下载/上传到服务器以及从服务器读取特定内存位置的诊断服务是可能需要安全访问的情况。下载到服务器的不正确的例程或数据可能会损坏电子设备或其他车辆部件，或危及车辆对排放、安全或安全标准的合规性。安全概念使用种子和密钥的关系。

该服务的典型使用示例如下：

• 客户端请求“种子”
• 服务器发送“种子”
• 客户端发送“密钥”（适用于收到的种子）
• 服务器响应说“密钥”有效并且它将自行解锁

‘requestSeed’ SubFunction 参数值应始终为奇数，且同一安全级别对应的‘sendKey’ SubFunction 参数值应等于‘requestSeed’ SubFunction 参数值加一。

任何时刻只能有一个安全级别处于活动状态。例如，如果与 requestSeed 0x03 关联的安全级别处于活动状态，并且tester请求成功解锁与 requestSeed 0x01 关联的安全级别，则只有与 requestSeed 0x01 关联的安全级别支持的安全功能才会在那时解锁。与 requestSeed 0x03 关联的安全级别之前解锁的任何其他安全功能将不再处于活动状态。安全级别编号是任意的，并不意味着级别之间存在任何关系。

• 客户端应通过发送服务 SecurityAccess“requestSeed”消息请求服务器“解锁”。

• 服务器应通过使用服务 SecurityAccess“requestSeed”肯定response消息发送“种子”来响应。

• 然后，客户端应通过使用适当的服务 SecurityAccess“sendKey”request消息向服务器返回“密钥”号码来响应。

• 服务器应将此“密钥”与内部存储/计算的密钥进行比较。
• 如果两个数字匹配，则服务器应启用（“解锁”）客户端对特定服务/数据的访问，并通过服务 SecurityAccess“sendKey”肯定response消息指示这一点。
• 如果两个数字不匹配，则应将此视为虚假访问尝试。无效密钥应要求客户端从头开始，并使用附件 I 中指定的 SecurityAccess“requestSeed”消息。

有关安全访问处理细节的更多详细信息在附件 I 中指定。

• 如果服务器支持安全性，但在收到 SecurityAccess“requestSeed”消息时请求的安全级别已解锁，则该服务器应使用 SecurityAccess“requestSeed”肯定response消息服务进行响应，其中种子值等于零 (0)。

• 对于当前已锁定的给定安全级别，服务器绝不会发送全零种子。客户端应使用此方法通过检查非零种子来确定服务器是否已针对特定安全级别锁定。

• 在服务器启动/重置后，以及在一定数量的错误访问尝试后（参见下文的进一步描述），可能需要进行汽车制造商指定的时间延迟，然后服务器才能积极响应来自客户端的服务 SecurityAccess“requestSeed”消息。

• 如果支持此延迟计时器，则应在达到汽车制造商指定的错误访问尝试次数后，或当服务器启动/重置并且之前执行的 SecurityAccess 服务因一次错误访问尝试而失败时激活延迟。

• 如果服务器支持此延迟计时器，则在成功执行 SecurityAccess 服务“sendKey”后，服务器应清除启动/重置时延迟计时器调用的服务器内部指示信息。

• 如果服务器支持此延迟计时器并且无法确定在启动/重置之前执行的 SecurityAccess 服务是否失败，则延迟计时器应在启动/重置后始终处于活动状态。

• 仅当服务器在启动/重置时被锁定才需要延迟。

• 汽车制造商应选择是否支持延迟计时器。

• 尝试访问安全机制不应妨碍正常的车辆通信或其他诊断通信。

• 如果在服务器锁定期间请求安全服务，提供安全性的服务器应支持拒绝消息。

• 在特定诊断会话期间请求的某些诊断功能/服务可能需要成功的安全访问序列。在这种情况下，应需要以下服务序列：
• DiagnosticSessionControl 服务
• SecurityAccess 服务
• 安全诊断 服务

• 对于服务器中已启用的诊断会话（会话已启动），允许使用不同的访问模式。

重要提示 — 服务器和客户端应满足 8.7 中规定的request和response消息行为。

附件I（规范性）

I 安全访问状态图

本附件的目的是基于具有状态转换条件和动作定义的状态图来描述 ECU 中的 SecurityAccess 服务处理。以下是定义的基础：

• 使用析取范式以便在状态之间和状态内定义单一转换。

• 析取范式的定义：
• 如果一个语句是一个析取运算（OR的序列），由一个或多个析取项组成，其中每个析取项都是一个或多个文字的连接项（AND），则该语句处于析取范式。

基于析取范式的状态转换定义

图 I.1 以图形方式描述了 SecurityAccess 处理的状态图。给定的数字表示状态转换条件和转换时要执行的操作。

状态图考虑到一般会话处理是在会话管理层的适当位置进行的（参见 ISO 14229-2），因此在状态图中不予考虑。

状态转换定义使用了一些参数，这些参数可以根据车辆制造商的特定要求进行设置。对 Delay_Timer 和 Att_Cnt 参数的支持是可选的，由车辆制造商决定。一般来说，对于较长的种子/密钥长度（例如 16 个字节及以上），对这些参数的支持不再那么重要。

表 I.1 指定了状态转换 - 参数。

表 I.2 包括完整的状态转换定义。

应当考虑，当通过使用 OR 连接在一起的多个连接词定义状态转换时，每个连接词都应用了一个动作，一次只有一个分离的连接词变为真，并强制状态转换，以便只执行定义的某个状态转换的动作之一（例如，只传输单个否定响应）。

request消息

表 40 指定了request消息定义-SubFunction = requestSeed。

表 41 指定了request消息定义-SubFunction = sendKey。

request消息 SubFunction 参数 $Level (LEV_) 定义

SubFunction 参数 securityAccessType 向服务器指示此服务的进行步骤、客户端想要访问的安全级别以及种子和密钥的格式。如果服务器支持不同级别的安全，则每个级别应由 requestSeed 值标识，该值与 sendKey 值具有固定关系：

• “requestSeed = 0x01”标识“requestSeed = 0x01”和“sendKey = 0x02”之间的固定关系。

• “requestSeed = 0x03”标识“requestSeed = 0x03”和“sendKey = 0x04”之间的固定关系。

表 42 中定义了 requestSeed 和 sendKey 的值（未显示 suppressPosRspMsgIndicationBit（bit 7））。

request消息数据参数定义

表 43 指定了request消息的数据参数。