ISO 14229-1:2020
第 1 部分：应用层
道路车辆 — 统一诊断服务（UDS）
1 范围
本文件规定了与诊断服务的数据链路无关的需求（允许诊断测试仪（客户端）对车载电子控制单元（ECU，服务器）中的诊断功能进行控制），例如，通过串行数据链路连接到道路车辆的电子燃油喷射系统、自动变速箱、防抱死制动系统等。
本文件规定了通用服务，允许诊断测试仪（客户端）停止或恢复数据链路上的对非诊断消息的传输。
本文件不适用于（车辆通信数据链路中）两个 ECU 之间的对非诊断消息的传输。但是，本文件并不限制车载测试仪（客户端）在 ECU 中的实现方式，以便通过车辆通信数据链路中的诊断服务进行双向诊断数据交换。
本文件未对任何实现需求进行规定。
2 规范性引用
下列文件在本文中被引用，其部分或全部内容构成本文件的要求。凡是注日期的引用文件，仅其版本适用。凡是不注日期的引用文件，其最新版本（包括所有的修改）适用于本文件。
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS)
- Part 2: Session layer services
ISO 7816-8, Identification cards — Integrated circuit cards
- Part 8: Commands and mechanisms for security operations
ISO/IEC 9594-8, Information technology — Open Systems Interconnection — The Directory
- Part 8: Public-key and attribute certificate frameworks
IEEE 754-2008, IEEE Standard for Floating-Point Arithmetic
IEEE 1609.2, Standard for Wireless Access in Vehicular Environments — Security Services for Applications and Management Messages
X.509, Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks
RFC 5280, Internet Engineering Task Force — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5755, Internet Engineering Task Force — An Internet Attribute Certificate Profile for Authorization
3 术语和定义
就本文件而言，以下术语和定义适用于本文件。
ISO 和 IEC 在以下地址维护用于标准化的术语数据库：
- IEC Electropedia: available at http://www.electropedia.org/
- ISO Online browsing platform: available at http://www.iso.org/obp
3.1 启动（boot）内存分区
在服务器（3.18）内存中存放启动（boot）软件（3.2）的区域。
3.2 启动（boot）软件
该软件在服务器 (3.18) 内存的特定区域被执行，主要被用于启动 ECU (3.9) 并执行服务器编程。
注意 1：
在正常的编程过程中，该内存区域不会被擦除。当服务器应用程序丢失或被判定为无效时，该区域会被执行，以确保始终能够重新执行服务器编程。
注意 2：
参见 0 和 17.3.1.1。
3.3 客户端
测试仪 (3.20) 的功能的一部分，该功能利用诊断服务 (3.6)。
注 1：
测试仪通常会利用其他功能，例如，数据库管理、特定解释、人机界面。
3.4 诊断通道
客户端 (3.3) 到服务器 (3.18) 的专用传输路径，被用于诊断通信。
注 1：
对于同时被连接至同一服务器的多个客户端，可通过各自的测试仪 (3.20) 源地址对其进行区分。
3.5 诊断数据
位于电子控制单元 (3.9) 内存中的数据，可供测试仪 (3.20) 检查和/或修改。
注 1：
诊断数据包括模拟输入/输出数据、数字输入/输出数据、中间值以及各种状态信息。
注 2：
诊断数据的示例：车速、节流阀角度、后视镜位置、系统状态等。诊断数据定义了三种类型的值：
- 当前值：处于正常运行状态下的电子控制单元当前正在使用（或由此产生）的值
- 存储值：在特定时刻（例如，发生故障时或定期）被创建的当前值的内部副本（由电子控制单元创建）
- 静态值：例如，车辆识别码 (VIN)
服务器 (3.18) 没有义务出于诊断目的保留其数据的内部副本，在这种情况下，测试仪只能请求当前值。
注3：
对“维修车间”或“开发测试”会话进行定义会选择不同的服务器功能（例如，可能仅在开发测试会话中被允许访问的所有内存的位置）。
3.6 诊断服务
客户端（3.3）发起信息交换，目的是向服务器（3.18）请求诊断信息和/或修改其行为以进行诊断。
3.7 诊断会话
在内部启用了特定的诊断服务 (3.6) 和功能的服务器 (3.18) 的状态。
3.8 诊断故障码（DTC）
车载诊断系统识别出的故障状况的通用数字标识符。
3.9 ECU
电子控制单元，即提供有关所连接的传感器和控制网络的信息的单元。
注1：
被视为电子控制单元的系统包括防抱死制动系统（ABS）和发动机管理系统。
3.10 功能单元
一组功能相近或互补的诊断服务（3.6）。
3.11 本地服务器
与客户端 (3.3) 一起被连接至同一本地网络的服务器 (3.18) ，并且其所属的地址空间与客户端一致。
3.12 永久 DTC
即使在清除诊断故障码请求被发出后，仍会被保留在非易失性存储器（Nvm）中的诊断故障码 (3.8) ，直到其他条件（通常为法规要求。例如，关于每个诊断故障码的相应监控均已成功通过）满足。
注 1：
请参阅相关法规以了解所有的必要需求。
3.13 记录
一个或多个诊断数据（3.5）元素，这些元素通过单一的标识方式被共同指代。
注 1：
示例：包含各种输入/输出数据及故障码的快照。
3.14 远程服务器
未直接地被连接至主诊断网络的服务器 (3.18)。
注 1：
远程服务器通过远程地址被标识。远程地址代表一个独立于主网络地址的地址空间。
注 2：
远程服务器通过主网络上的本地服务器 (3.11) 被访问。主网络上的每个本地服务器都可以作为通往一组独立的远程服务器的网关。因此，一对地址将被用于标识远程服务器：一个本地地址被用于标识通往远程网络的网关，一个远程地址被用于标识远程服务器本身。
3.15 远程客户端
未直接地被连接至主诊断网络的客户端 (3.3)。
注 1：
远程客户端通过远程地址被标识。
注 2：
远程地址代表一个独立于主网络地址的地址空间。
3.16 重编程软件
启动（boot）软件（3.2）的一部分，允许对电子控制单元（3.9）进行重新编程。
3.17 安全
通过车辆诊断数据链路（3.5）保护车辆免受“未经授权”入侵的机制。
3.18 服务器
作为电子控制单元 (3.9) 的一部分，提供诊断服务 (3.6) 功能。
注 1：
本文档区分服务器（即功能）和电子控制单元，以确保其独立于具体的实现方式。
3.19 支持的 DTC
当前已被配置/校准并被启用的诊断故障码 (3.8) ，可在预定义的车辆条件下被执行。
3.20 测试仪
被用于对车载电子控制单元 (3.9) 的功能（测试、检验、监控或诊断）进行控制的系统，可被用于特定类型的操作人员（例如，专用于维修技师的非车载扫描工具、专用于装配厂的非车载测试工具或车载测试仪）。
注 1：
测试仪也被称为客户端 (3.3)。
4 符号和缩写词
.con
- 服务原语 .confirmation
.ind
- 服务原语 .indication
.req
- 服务原语 .request
A_PCI
- 应用层协议控制信息
ACR
- 通过 Challenge-Response 进行的身份验证
APCE
- 通过 PKI 证书交换进行的身份验证
BER
- 根据 ITU-T X.690 标准的基本编码规则
CMAC
- 基于密码的消息认证码
CVC
- 卡片可验证证书
ECU
- 电子控制单元
EDR
- 事件数据记录器
GMAC
- Galois 消息认证码
HMAC
- 基于哈希的消息认证码
N/A
- 不适用
NR_SI
- 负响应服务标识符
NRC
- 负响应码
OID
- 根据 ISO/IEC 9834-1 标准的对象标识符
OSI
- 开放式系统互连
PKCS
- 公钥密码学标准
PKI
- 公钥基础设施
POWN
- 所有权证明
RA
- 远端地址
SA
- 源地址
SI
- 服务标识符
TA
- 目标地址
TA_type
- 目标地址类型
X.509
- 根据 ISO/IEC 9594-8 标准的 PKI 标准
5 公约
本文档基于 OSI 服务约定（ISO/IEC 10731）中针对诊断服务所讨论的约定。
这些约定对服务用户和服务提供者之间的交互进行了规定。信息通过服务原语在服务用户和服务提供者之间被传递，服务原语可以传递参数。
关于服务和协议之间的区别请见图 1。
本文档对确认服务和非确认服务进行了定义。
确认服务使用六个服务原语：请求 (request)、确认请求 (req_confirm)、指示 (indication)、响应 (response)、确认响应 (rsp_confirm) 和确认 (confirmation)。
非确认服务仅使用请求 (request)、确认请求 (req_confirm) 和指示 (indication) 服务原语。
对于在本文档中被定义的所有服务，请求 (request) 和指示 (indication) 服务原语的格式和参数始终相同。因此，对于所有服务，响应 (response) 和确认 (confirm) 服务原语（确认请求 (req_confirm) 和确认响应 (rsp_confirm) 除外）的格式和参数也始终相同。本文档对服务原语进行定义时，仅列出请求 (request) 和响应 (response) 服务原语。
6 文档概述
图 2 描绘了根据 OSI 模型被实现的 UDS 文档。
7 应用层服务
7.1 概述
应用层服务通常被称为诊断服务。在基于客户端-服务器的系统中，应用层服务被用于执行诸如车载服务器的测试、检查、监控或诊断等功能。通过应用层服务，客户端（通常指外部测试设备）请求在一个或多个服务器中执行诊断功能。服务器（通常是 ECU 的一部分）通过应用层服务将被请求的诊断服务提供的响应数据发送回客户端。客户端通常是外部测试仪，但在某些系统中也可以是车载测试仪。对应用层服务的使用与客户端的类型（外部测试仪或车载测试仪）无关。在同一个车辆系统中可以存在多个客户端。
应用层的访问点提供了许多具有相同通用结构的服务。对于每项服务，都为其指定了六个服务原语：
- 服务请求原语，由诊断测试仪应用程序中的客户端使用，被用于将有关所请求的诊断服务的数据传递给应用层。
- 服务请求确认原语，由诊断测试仪应用程序中的客户端使用，被用于指示在服务请求原语中被传递的数据已成功地被发送至诊断测试仪所连接的车辆通信总线上。
- 服务指示原语，由应用层使用，被用于将数据传递给 ECU 诊断应用程序中的服务器。
- 服务响应原语，由 ECU 诊断应用程序中的服务器使用，被用于将被请求的诊断服务提供的响应数据传递给应用层。
- 服务响应确认原语，由 ECU 诊断应用程序中的服务器使用，被用于指示在服务响应原语中被传递的数据已成功地被发送至 ECU 在接收诊断请求时所处的车辆通信总线上。
- 服务确认原语，由应用层使用，被用于将数据传递给诊断测试仪应用程序中的客户端。
图 3 描绘了应用层服务原语“已被确认的服务”。
7.2 应用层服务的格式描述
根据车辆诊断系统被配置的方式，应用层服务将采用四种不同的格式。应用层服务的格式由参数 A_Mtype 控制。
如果车辆诊断系统被配置为允许客户端通过地址参数 A_SA 和 A_TA 对所有服务器进行寻址，则应使用应用层服务的默认格式。这意味着 A_Mtype = diagnostics。
如果车辆诊断系统被配置为允许客户端通过除了地址参数 A_SA 和 A_TA 外的其他地址信息来对特定服务器进行寻址，则应使用应用层服务的远程格式。这意味着 A_Mtype = remote diagnostics。
如果车辆诊断系统被配置为允许客户端通过地址参数 A_SA 和 A_TA 对处理安全数据的服务器进行寻址，则应使用应用层服务的安全格式。这意味着 A_Mtype = secure diagnostics。
如果车辆诊断系统被配置为允许客户端通过除了地址参数 A_SA 和 A_TA 外的其他地址信息来对处理安全数据的服务器进行寻址，则应使用应用层服务的安全远程格式。这意味着 A_Mtype = secure remote diagnostics。
对应用层服务的不同格式在 7.3 节中被详细地说明。
7.3 服务原语的格式描述
7.3.1 一般定义
所有应用层服务都采用相同的通用格式。服务原语的编写形式如下：
service_name.type (
parameter A, parameter B, parameter C
[, parameter 1, ...]
)
其中：
- “service_name”是诊断服务的名称（例如，DiagnosticSessionControl）
- “type”表示服务原语的类型（例如，request）
- “parameter A, ...”是 A_SDU（应用层服务数据单元），以服务原语传递的值的列表的形式被呈现（寻址信息）
- “parameter A, parameter B, parameter C”是所有在服务调用中必须被包含的参数
- “[, parameter 1, ...]”是取决于特定服务的参数（例如，对于 DiagnosticSessionControl 服务，parameter 1 可以是 diagnosticSession）。方括号表示参数列表的这一部分可以为空
7.3.2 服务请求和服务指示原语
对于每个应用层服务，服务请求和服务指示原语均按照以下通用格式被指定：
service_name.request (
A_MType,
A_SA,
A_TA,
A_TA_type,
[A_AE],
A_Length,
A_Data[, parameter 1, ...],
)
请求原语由诊断测试仪应用程序中的客户端使用，被用于启动服务并将有关所请求的诊断服务的数据传递给应用层。
service_name.indication (
A_MType,
A_SA,
A_TA,
A_TA_type,
[A_AE],
A_Length
A_Data[, parameter 1, ...],
)
应用层使用指示原语来指示对于 ECU 诊断应用程序具有重要意义的内部事件，并将所请求的诊断服务的数据传递给 ECU 诊断应用程序的服务器。
特定应用层服务的请求原语和指示原语始终具有相同的参数和参数值。这意味着，当数据从客户端被传输至服务器时，应用层通信中的对端协议实体不得更改各个参数的值。客户端在服务请求中传递给应用层的值应与（对端）服务器在服务指示中从（对端）应用层接收到的值相同。
7.3.3 服务响应和服务确认原语
对于每个已被确认的应用层服务，服务响应和服务确认原语均按照以下通用格式被指定：
service_name.response (
A_Mtype,
A_SA,
A_TA,
A_TA_type,
[A_AE],
A_Length
A_Data[, parameter 1, ...],
)
响应原语由 ECU 诊断应用程序中的服务器使用，被用于启动服务并将所请求的诊断服务提供的响应数据传递给应用层。
service_name.confirm (
A_Mtype,
A_SA,
A_TA,
A_TA_type,
[A_AE],
A_Length
A_Data[, parameter 1, ...],
)
应用层使用确认原语来指示对于客户端应用程序具有重要意义的内部事件，并将（之前）所请求的诊断服务的结果传递给诊断测试仪应用程序的客户端。它并不一定表示在远程对端实体上的任何活动（例如，服务器不支持所请求的服务或通信中断）。
特定应用层服务的响应原语和确认原语始终具有相同的参数和参数值。这意味着，当数据从服务器被传输至客户端时，应用层通信中的对端协议实体不得更改各个参数的值。服务器在服务响应中传递给应用层的值应与（对端）客户端在服务确认中从（对端）应用层接收到的值相同。
对于每个响应原语和确认原语，将为其指定两个不同的服务数据单元（两组参数）：
- 如果 ECU 中的服务器能够成功地执行所请求的诊断服务，则应使用肯定响应原语和肯定确认原语以及第一个服务数据单元。
- 如果所请求的诊断服务失败或 ECU 中的服务器未及时完成所请求的诊断服务，则应使用否定响应原语和否定确认原语以及第二个服务数据单元。
7.3.4 服务请求确认和服务响应确认原语
对于每个应用层服务，服务请求确认和服务响应确认原语均按照以下通用格式被指定：
service_name.req_confirm (
A_Mtype,
A_SA,
A_TA,
A_TA_type,
[A_AE],
A_Result
)
应用层使用请求确认原语来指示对于客户端应用程序具有重要意义的内部事件，并将（之前）服务请求的通信结果传递给诊断测试仪应用程序的客户端。
service_name.rsp_confirm (
A_Mtype,
A_SA,
A_TA,
A_TA_type,
[A_AE],
A_Result
)
应用层使用响应确认原语来指示对于服务器应用程序具有重要意义的内部事件，并将（之前）服务响应的通信结果传递给 ECU 应用程序的服务器。
7.4 服务数据单元规范
7.4.1 强制参数
7.4.1.1 一般定义
应用层服务包含三个强制参数。以下参数的定义适用于在本文档中被指定的所有应用层服务（标准格式和远程格式）。
7.4.1.2 A_Mtype（应用层消息类型）
类型：
- 枚举
范围：
- 诊断、远程诊断、安全诊断、安全远程诊断
描述：
- 参数 Mtype 被用于标识车辆诊断系统的格式，如 7.2 节所述。本文档为该参数指定了四个值：
- 如果 A_Mtype = diagnostics，则 service_name 原语应包含参数 A_SA、A_TA 和 A_TAtype。
- 如果 A_Mtype = remote diagnostics，则 service_name 原语应包含参数 A_SA、A_TA、A_TAtype 和 A_AE。
- 如果 A_Mtype = secure diagnostics，则 service_name 原语应包含参数 A_SA、A_TA 和 A_TAtype。
- 如果 A_Mtype = secure remote diagnostics，则 service_name 原语应包含参数 A_SA、A_TA、A_TAtype 和 A_AE。
7.4.1.3 A_SA（应用层源地址）
类型：
- 2 字节无符号整数
范围：
- 0x0000 至 0xFFFF
描述：
- 参数 SA 被用于对客户端和服务器标识符进行编码。
- 对于服务请求（和服务指示），A_SA 表示请求诊断服务的客户端的地址。对于每个请求诊断服务的客户端，都应使用一个 A_SA 值对其进行表示。如果在同一诊断仪中存在多个客户端，则每个客户端都应有自己的客户端标识符和相应的 A_SA 值。
- 对于服务响应（和服务确认），A_SA 表示执行所请求的诊断服务的服务器的地址。服务器可以被实现为仅存在于一个 ECU 中，也可以被实现为分布于多个 ECU 中。如果服务器被实现为仅存在于一个 ECU 中，则只需使用一个 A_SA 值对其进行编码。如果服务器被实现为分布于多个 ECU 中，则对于每个服务器（不同 ECU 中），都应使用一个 A_SA 值对其进行编码。
- 如果消息的原始来源是远程客户端或远程服务器，则 A_SA 表示作为（远程网络到主网络）网关的本地服务器。
注意
如果请求消息使用了物理寻址，则响应消息中的 A_SA 值将与相应请求消息中的 A_TA 值相同。
7.4.1.4 A_TA（应用层目标地址）
类型：
- 2 字节无符号整数
范围：
- 0x0000 至 0xFFFF
描述：
- 参数 A_TA 被用于对客户端和服务器标识符进行编码。
- 诊断系统指定了两种不同的寻址方法：
- 物理寻址
- 功能寻址
- 因此，可以为车辆系统定义两组独立的目标地址（每种寻址方法一组）。
- 物理寻址应始终被应用于发送给被实现为仅存在于一个 ECU 中的服务器的专用消息，客户端和服务器之间的通信方式为点对点通信。
- 如果客户端不知道响应诊断服务请求的服务器的物理地址，或者服务器被实现为分布于多个 ECU 中，则客户端应使用功能寻址。使用功能寻址时，客户端向一个或多个服务器（被实现为分布于多个 ECU 中）发起广播通信。
- 对于服务请求（和服务指示），A_TA 表示将执行所请求的诊断服务的服务器的标识符。如果寻址的目标为远程服务器，则 A_TA 表示作为（主网络到远程网络）网关的本地服务器。
- 对于服务响应（和服务确认），A_TA 表示最初请求诊断服务并将接收响应数据的客户端的地址（服务请求的 A_SA）。服务响应（和服务确认）应始终使用物理寻址。如果寻址的目标为远程客户端，则 A_TA 表示作为（主网络到远程网络）网关的本地服务器。
注意
响应消息中的 A_TA 值始终与相应请求消息的 A_SA 值相同。
7.4.1.5 A_TA_Type（应用层目标地址类型）
类型：
- 枚举
范围：
- 物理寻址、功能寻址
描述：
- 参数 A_TA_type 是对参数 A_TA 的扩展，被用于表示消息传输的寻址方式。
7.4.1.6 A_Result
类型：
- 枚举
范围：
- 成功，失败
描述：
- 参数 A_Result 由服务请求确认和服务响应确认原语使用，被用于指示消息传输的结果（成功、失败）。
7.4.1.7 A_Length
类型：
- 4 字节无符号整数
范围：
- 0 到 (2^32-1)
描述：
- 此参数包含待被发送/接收的数据的长度。
7.4.1.8 A_Data
类型：
- 字符串
范围：
- 不适用
描述：
- 此参数包含需要在上层实体之间被交换的所有数据。
7.4.2 车辆系统需求
车辆制造商应确保系统中的每个服务器都具有唯一的（服务器）标识符，还应确保系统中的每个客户端都具有唯一的（客户端）标识符。
在车辆系统中的诊断网络的所有客户端和服务器的地址都应在同一源地址范围内被编码。这意味着在给定的车辆系统中，客户端和服务器不应使用相同的 A_SA 值。
服务器的响应的目标地址（物理寻址）应始终与请求的源地址相同。
可以独立于主网络上的客户端和服务器的标识符对远程服务器的标识符进行分配。
通常情况下，只有被寻址的服务器才会响应客户端的请求消息。
7.4.3 A_AE（可选参数，应用层远程地址）
类型：
- 2 字节无符号整数
范围：
- 0x0000 至 0xFFFF
描述：
- A_AE 被用于对可用的地址范围进行扩展，以对客户端和服务器的标识符进行编码。A_AE 仅应被用于实现了本地服务器和远程服务器概念的车辆。远程地址的范围仅代表远程目标的地址范围，且独立于主网络上的地址。
- 参数 A_AE 被用于对远程客户端和远程服务器的标识符进行编码。根据 A_AE 所处的消息的传输的方向，A_AE 可以表示远程目标地址或远程源地址。
- 对于客户端在主网络上发送的服务请求（和服务指示），A_AE 表示将执行所请求的诊断服务的远程服务器的标识符（远程目标地址）。
- A_AE 既可被用于物理寻址，也可被用于功能寻址。对于 A_AE 的每个值，系统构建者应指定该值表示的是物理寻址的地址还是功能寻址的地址。
- 没有像 A_TA_type 那样专门被用于表示远程地址的类型（物理寻址或功能寻址）的特殊参数来指定 A_TA 的寻址方式。物理寻址或功能寻址的远程地址的取值范围相同（0x0 至 0xFF），每个值的含义应由系统构建者定义。
- 对于远程服务器发送的服务响应（和服务确认），A_AE 表示执行所请求的诊断服务的远程服务器的物理位置（远程源地址）。
- 远程服务器可被实现为仅存在于一个 ECU 中，也可被实现为分布于多个 ECU 中。如果远程服务器被实现为仅存在于一个 ECU 中，则只需使用一个 A_AE 值对其进行编码。如果远程服务器被实现为分布于多个 ECU 中，则应针对每个远程服务器的物理位置使用一个 A_AE 值对其进行编码。
8 应用层协议
8.1 一般定义
应用层协议应始终为已被确认的消息传输，这意味着对于每个由客户端发送的服务请求都应存在与之对应的一个或多个来自服务器的响应。
此规则的唯一例外情况为，功能寻址或服务请求/指示明确地指定不存在服务响应/确认的少数情况。为了避免系统承受过多不必要的消息，即使服务器未能完成所请求的诊断服务，在某些情况下也不应发送否定响应消息。在本文档的相关子条款中将对这些例外情况进行描述（例如，参见 8.7）。
应并行处理应用层协议及会话层协议。这意味着即使客户端正在等待先前的服务请求的响应，也应保持适当的会话层时序（例如，如需在其他服务器上保持诊断会话，则应发送 TesterPresent 请求。具体实现取决于所使用的数据链路层）。
8.2 A_PDU（应用协议数据单元）
应用层协议数据单元 (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 的字节数。
8.3 A_PCI（应用协议控制信息）
A_PCI 由两种格式组成。格式由 A_PDU 参数的第一个字节的值标识。对于所有服务请求以及第一个字节不等于 0x7F 的服务响应，应适用以下定义：
A_PCI (
SI
)
其中：
- SI 是“服务标识符”参数。
对于首字节为 0x7F 的服务响应，应适用以下定义：
A_PCI (
NR_SI,
SI
)
其中：
- NR_SI 为被用于对否定服务响应/确认进行标识的特殊参数。
- SI 是“服务标识符”参数。
注意
关于根据服务 ReadDataByPeriodicIdentifier（0x2A，参见 11.5）定义的周期性数据响应消息的传输，在其应用层协议数据单元 (A_PDU) 中不存在 A_PCI。
8.4 SI（服务标识符）
类型：
- 1 字节无符号整数
范围：
- 0x00 至 0xFF（根据表 2 中的定义）。
- 服务标识符 (SI) 被用于对服务原语中调用的特定服务进行编码。每个被请求的服务都应被分配一个唯一的 SI 值。每个肯定响应也应被分配一个唯一的 SI 值。
- 对于在从应用层到下层（以及从下层到应用层）的传递中的 A_Data，其中的服务标识符被用于对服务进行标识。
8.5 A_NR_SI（否定响应服务标识符）
类型：
- 1 字节无符号整数
固定值：
- 0x7F
描述：
- NR_SI 是一个特殊参数，被用于对否定服务响应/确认进行标识。它应被包含在否定响应/确认消息的 A_PCI 中。
注意：
NR_SI 的值应与 SI 的值协调一致。NR_SI 的值不被用作 SI 的值，以便简化对 A_Data 的编码和解码。
8.6 否定响应/否定确认服务原语
每个诊断服务都有一个否定响应/否定确认消息，该消息由在表 3 中被指定的 A_Data 的字节表示。第一个 A_Data 字节 (A_PCI.NR_SI) 始终为特定的否定响应服务标识符。第二个 A_Data 字节 (A_PCI.SI) 应为与该否定响应消息对应的服务请求/指示消息中的服务标识符的值的副本。
8.7 服务器响应实现规则
8.7.1 一般定义
以下子条款规定了服务器在执行服务时的行为。服务器和客户端均应遵循这些实现规则。
图例
重要
根据以下子条款表格的需求，当请求消息使用功能寻址时，不得发送响应码为：
- SNS（serviceNotSupported）
- SNSIAS（serviceNotSupportedInActiveSession）
- SFNS（SubFunctionNotSupported）
- SFNSIAS（SubFunctionNotSupportedInActiveSession）
- ROOR（requestOutOfRange）
的否定响应消息（例外情况参见 A.1 中对 NRC 0x78 的定义）。
8.7.2 服务器的一般响应行为
本子条款中规定的服务器的一般响应行为对于所有请求消息而言都是强制性的。验证步骤从接收请求消息开始。该图分为三个子条款：
- 强制性：对于每个请求消息，对此条件进行评估为必须的。
- 可选：对于每个请求消息，对此条件进行评估为可选的。
- 制造商/供应商特定：通过额外的制造商/供应商特定的检查，可以对该过程进行扩展。
注意
根据图中（指定对 NRC 的处理）所有被实现的选项，对于所有可能的测试模式序列不能保证都存在对应的 NRC。
图 5 显示了服务器的一般响应行为。
8.7.3 带有 SubFunction 参数的请求消息及服务器的响应行为
8.7.3.1 对于带有 SubFunction 参数的请求消息的服务器的一般响应行为
本子条款中规定的服务器的一般响应行为对于所有带有 SubFunction 参数的请求消息都是强制性的。本子条款中的请求消息是指符合本文档中定义的格式要求的服务请求消息。图 6 展示了对于带有 SubFunction 参数的请求消息的服务器的一般响应行为。
8.7.3.2 物理寻址的客户端请求消息
本子条款中规定的服务器的响应行为在各项服务的服务描述中均被引用，该服务支持通过物理寻址的客户端的请求消息中的 SubFunction 参数。
表 4 显示了通过物理寻址的可能的通信方案。
- a) 服务器发送肯定响应消息，因为客户端所请求的服务及 SubFunction 参数均被支持，并指示需要响应消息。
- b) 服务器发送否定响应消息（例如，IMLOIF（incorrectMessageLengthOrIncorrectFormat）），因为客户端所请求的服务及 SubFunction 参数均被支持，但在对 SubFunction 进行处理的过程中出现了其他错误（例如，根据请求消息中的服务标识符和 SubFunction 参数得出的 PDU 长度不匹配）。
- c) 服务器发送带有否定响应码 ROOR（requestOutOfRange）的否定响应消息，因为客户端所请求的服务及 SubFunction 参数均被支持，但数据参数不受支持。
- d) 服务器发送否定响应消息，其否定响应码为 SNS（serviceNotSupported）或 SNSIAS（serviceNotSupportedInActiveSession），因为客户端所请求的服务标识符不受支持，并指示需要响应消息。
- e) 服务器发送否定响应消息，其否定响应码为 SFNS（SubFunctionNotSupported）或 SFNSIAS（SubFunctionNotSupportedInActiveSession），因为客户端请求的数据参数（如果适用）中的服务标识符受支持，但子功能参数不受支持，并指示需要响应消息。
- f) 服务器不发送响应消息，因为客户端所请求的服务及 SubFunction 参数均被支持，并指示不需要响应消息。
- g) 与 b) 相同（即发送否定响应消息），因为对于任何需要针对物理寻址的请求消息发送的否定响应，suppressPosRspMsgIndicationBit 都会被忽略。
- h) 与 c) 相同（即发送否定响应消息），因为对于任何需要针对物理寻址的请求消息发送的否定响应，suppressPosRspMsgIndicationBit 都会被忽略。
- i) 与 d) 相同（即发送否定响应消息），因为对于任何需要针对物理寻址的请求消息发送的否定响应，suppressPosRspMsgIndicationBit 都会被忽略。
- j) 与 e) 相同（即发送否定响应消息），因为对于任何需要针对物理寻址的请求消息发送的否定响应，suppressPosRspMsgIndicationBit 都会被忽略。
8.7.3.3 功能寻址的客户端请求消息
本子条款中规定的服务器的响应行为在各项服务的服务描述中均被引用，该服务支持通过功能寻址的客户端的请求消息中的 SubFunction 参数。
表 5 显示了通过功能寻址的可能的通信方案。
- a) 服务器发送肯定响应消息，因为客户端所请求的服务及 SubFunction 参数均被支持，并指示需要响应消息。
- b) 服务器发送否定响应消息（例如，IMLOIF（incorrectMessageLengthOrIncorrectFormat）），因为客户端所请求的服务及 SubFunction 参数均被支持，但在对 SubFunction 进行处理的过程中出现了其他错误（例如，根据请求消息中的服务标识符和 SubFunction 参数得出的 PDU 长度不匹配）。
- c) 服务器不发送响应消息，因为对于功能寻址的请求消息，否定响应码 ROOR（requestOutOfRange，因为客户端所请求的服务及 SubFunction 参数均被支持，但数据参数不受支持）始终会被抑制。在这种情况下，suppressPosRspMsgIndicationBit 不起作用。
- d) 服务器不发送响应消息，因为对于功能寻址的请求消息，服务器始终会抑制否定响应码 SNS（serviceNotSupported）和 SNSIAS（serviceNotSupportedInActiveSession）。这些代码表示服务器不支持客户端所请求的服务。在这种情况下，suppressPosRspMsgIndicationBit 参数不起作用。
- e) 服务器不发送响应消息，因为对于功能寻址的请求消息，服务器始终会抑制否定响应码 SFNS（SubFunctionNotSupported）和 SFNSIAS（SubFunctionNotSupportedInActiveSession）。这些代码表示服务器支持客户端所请求的服务，但不支持 SubFunction 参数。在这种情况下，suppressPosRspMsgIndicationBit 参数不起作用。
- f) 服务器不发送响应消息，因为客户端所请求的服务及 SubFunction 参数均被支持，并指示不需要响应消息。
- g) 与 b) 相同（即发送否定响应消息），因为对于任何否定响应，suppressPosRspMsgIndicationBit 都会被忽略。即使请求消息为功能寻址的，情况也是如此。
- h) 与 c) 相同（即不发送响应消息），因为对于功能寻址的请求消息，否定响应码 ROOR（requestOutOfRange，因为客户端所请求的服务及 SubFunction 参数均被支持，但数据参数不受支持）始终会被抑制。在这种情况下，suppressPosRspMsgIndicationBit 的值无关紧要。
- i) 与 d) 相同（即不发送响应消息），因为对于功能寻址的请求消息，服务器始终会抑制否定响应码 SNS（serviceNotSupported）和 SNSIAS（serviceNotSupportedInActiveSession）。这些代码表示服务器不支持客户端所请求的服务。在这种情况下，suppressPosRspMsgIndicationBit 参数不起作用。
- j) 与 e) 相同（即不发送响应消息），因为对于功能寻址的请求消息，服务器始终会抑制否定响应码 SFNS（SubFunctionNotSupported）和 SFNSIAS（SubFunctionNotSupportedInActiveSession）。这些代码表示服务器支持客户端所请求的服务，但不支持 SubFunction 参数。在这种情况下，suppressPosRspMsgIndicationBit 参数不起作用。
8.7.4 不包含 SubFunction 参数的请求消息及服务器的响应行为
8.7.4.1 对于不包含 SubFunction 参数的请求消息的服务器的一般响应行为
对于不包含 SubFunction 参数的请求消息，服务器没有一般的响应行为。本子条款中的请求消息是指符合本文档中定义的格式要求的服务请求消息。
8.7.4.2 物理寻址的客户端请求消息
本子条款中规定的服务器的响应行为在各项服务的服务描述中均被引用，该服务不支持通过物理寻址的客户端的请求消息中的 SubFunction 参数，但支持其中的数据参数。
表 6 显示了通过物理寻址的可能的通信方案。
- a) 服务器发送肯定响应消息，因为客户端所请求的服务及所有数据参数均被支持。
- b) 服务器发送肯定响应消息，因为客户端所请求的服务及至少一个数据参数均被支持。
- c) 服务器发送否定响应消息（例如，IMLOIF（incorrectMessageLengthOrIncorrectFormat）），因为客户端所请求的服务及至少一个数据参数均被支持，但在对服务进行处理的过程中出现了其他错误（例如，请求消息的长度错误）。
- d) 服务器发送带有否定响应码 ROOR（requestOutOfRange）的否定响应消息，因为客户端所请求的服务被支持，但任何数据参数均不受支持。
- e) 服务器发送否定响应消息，其否定响应码为 SNS（serviceNotSupported）或 SNSIAS（serviceNotSupportedInActiveSession），因为客户端所请求的服务不受支持。
8.7.4.3 功能寻址的客户端请求消息
本子条款中规定的服务器的响应行为在各项服务的服务描述中均被引用，该服务不支持通过功能寻址的客户端的请求消息中的 SubFunction 参数，但支持其中的数据参数。
表 7 显示了通过功能寻址的可能的通信方案。
- a) 服务器发送肯定响应消息，因为客户端所请求的服务及所有数据参数均被支持。
- b) 服务器发送肯定响应消息，因为客户端所请求的服务及至少一个数据参数均被支持。
- c) 服务器发送否定响应消息（例如，IMLOIF（incorrectMessageLengthOrIncorrectFormat）），因为客户端所请求的服务及至少一个数据参数均被支持，但在对服务进行处理的过程中出现了其他错误（例如，请求消息的长度错误）。
- d) 服务器不发送响应消息，因为对于功能寻址的请求消息，否定响应码 ROOR（requestOutOfRange，因为客户端所请求的服务被支持，但任何数据参数均不受支持）始终会被抑制。
- e) 服务器不发送响应消息，因为对于功能寻址的请求消息，服务器始终会抑制否定响应码 SNS（serviceNotSupported）和 SNSIAS（serviceNotSupportedInActiveSession）。这些代码表示服务器不支持客户端所请求的服务。
8.7.5 服务器的响应行为的伪代码示例
以下是服务器的伪代码示例，被用于描述服务器在收到客户端请求时应执行的逻辑步骤。
SWITCH (A_PDU.A_Data.A_PCI.SI)
{
/* test if service with SubFunction is supported */
CASE Service_with_SubFunction:
/* check minimum length of message with SubFunction */
IF (message_length >= 2) THEN
/* get SubFunction parameter value without bit 7 */
SWITCH (A_PDU.A_Data.A_Data.Parameter1 & 0x7F)
{
/* test if SubFunction parameter value is supported */
CASE SubFunction_00:
IF (message_length == expected_SubFunction_message_length) THEN
/* prepare response message */
:
/* pos. response message; set internal NRC = 0x00 */
responseCode = positiveResponse;
ELSE
/* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
responseCode = IMLOIF;
ENDIF
BREAK;
/* test if SubFunction parameter value is supported */
CASE SubFunction_01:
/* prepare response message */
:
/* positive response message; set internal NRC = 0x00 */
responseCode = positiveResponse;
:
/* test if SubFunction parameter value is supported */
CASE SubFunction_127:
/* prepare response message */
:
/* positive response message; set internal NRC = 0x00 */
responseCode = positiveResponse;
BREAK;
DEFAULT:
/* NRC 0x12: SubFunctionNotSupported */
responseCode = SFNS;
}
ELSE
/* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
responseCode = IMLOIF;
ENDIF
/* results in either 0x00 or 0x80 */
suppressPosRspMsgIndicationBit = (A_PDU.A_Data.Parameter1 & 0x80);
/* test if pos. response is required and if responseCode is positive 0x00 */
IF ((suppressPosRspMsgIndicationBit) &&
(responseCode == positiveResponse) &&
("not yet a NRC 0x78 response sent"))
THEN
/* flag to NOT send a positive response message */
suppressResponse = TRUE;
ELSE
/* flag to send the response message */
suppressResponse = FALSE;
ENDIF
BREAK;
/* test if service without SubFunction is supported */
CASE Service_without_SubFunction:
/* flag to send the response message */
suppressResponse = FALSE;
IF (message_length == expected_message_length) THEN
/* test if data-parameter following the SID is supported*/
IF (A_PDU.A_Data.Parameter1 == supported) THEN
/* read data and prepare response message */
:
/* positive response message; set internal NRC = 0x00 */
responseCode = positiveResponse;
ELSE
/* NRC 0x31: requestOutOfRange */
responseCode = ROOR;
ENDIF
ELSE
/* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
responseCode = IMLOIF;
ENDIF
BREAK;
DEFAULT:
/* NRC 0x11: serviceNotSupported */
responseCode = SNS;
}
IF (A_PDU.TA_type == functional &&
(
(responseCode == SNS) ||
(responseCode == SFNS) ||
(responseCode == SNSIAS) ||
(responseCode == SFNSIAS) ||
(responseCode == ROOR)
) &&
("not yet a NRC 0x8 response sent"))
THEN
/* suppress negative response message */
ELSE
IF (suppressResponse == TRUE) THEN
/* suppress positive response message */
ELSE
/* send negative or positive response */
ENDIF
ENDIF
当请求消息为功能寻址时，需要发送否定响应码为 RCRRP（requestCorrectlyReceivedResponsePending）的否定响应消息，在对请求消息进行处理后，如果需要发送的否定响应码为：
- SNS（serviceNotSupported）
- SNSIAS（serviceNotSupportedInActiveSession）
- SFNS（SubFunctionNotSupported）
- SFNSIAS（SubFunctionNotSupportedInActiveSession）
- ROOR（requestOutOfRange）
则也应发送该否定响应消息。
8.7.6 通过物理寻址或功能寻址的多个并发的请求消息
常见的服务器的实现中，服务器端只存在一个诊断协议实例为可用。一个诊断协议实例一次只能处理一个请求。规则是，任何接收到的消息（无论寻址模式为物理寻址还是功能寻址）都会占用此资源，直到请求消息被处理完毕（发送最终响应或无需响应）。
只有两种例外情况需要被单独地处理：
- 客户端使用 keep-alive 逻辑来保持先前在一个或多个服务器上被启用的会话处于活动状态。keep-alive 逻辑被定义为通过功能寻址的有效的 TesterPresent 消息，其中 SPRMIB 为 TRUE，并且应由旁路逻辑处理。服务器有责任确保此特定消息不会“阻塞”服务器的应用层，并且紧随其后的寻址消息可被处理。
- 如果服务器支持服务标识符为 0x00 到 0x0F 的服务，并且接收到服务标识符为 0x00 到 0x0F 的诊断请求，则应中止该服务标识符范围之外的任何活动的服务，然后启动默认会话，并处理该服务标识符范围内的诊断服务。如果编程会话正处于活动状态，则此需求不适用。
有关如何对多个客户端进行处理的更多信息，请参阅附件 J。
9 服务描述约定
9.1 服务描述
本子条款定义了本文档中各项诊断服务的描述方式。它规定了每项诊断服务的服务描述的一般格式。
本子条款简要概述了服务的功能。每项诊断服务规范的开头为关于客户端和服务器应执行的操作的描述，这些操作因服务而异。每项服务的描述都包含一个表格，其中列出了其基本参数（肯定或否定）：请求/指示、响应/确认。所有参数的结构相同：
对于给定的请求/指示和响应/确认的 A_PDU 的定义，每个参数的存在情况由以下约定 (Cvt) 值之一描述：
表 8 规定了 A_PDU 参数的约定。
9.2 请求消息
9.2.1 请求消息的定义
本子条款包含一个或多个表，被用于对服务请求/指示的 A_PDU（应用层协议数据单元，参见条款 8）参数进行定义。如果不同 SubFunction 参数（$Level）的请求消息在 A_Data 参数结构上存在差异，且无法在单个表中被清晰地定义，则每个 SubFunction 参数（$Level）可能需要一个单独的表。
表 9 定义了带有 SubFunction 参数的请求消息的 A_PDU。
注：
上表所示的寻址信息仅被用于定义目的。后续的服务请求/指示定义仅指定 A_PDU 的 A_Data 参数，因为 A_PDU 的 A_Data 参数代表服务请求/指示的消息数据字节。
9.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
此子条款指定：为服务 <服务名称> 的请求/指示定义的 SubFunction $Levels (LEV_) 参数。
如果所描述的服务未使用 SubFunction 参数，且未使用 suppressPosRspMsgIndicationBit（这隐式地表示需要响应），则此子条款不包含任何定义。
如表 11 所示，SubFunction 参数字节（按位）被分为两部分。
除了 suppressPosRspMsgIndicationBit 之外，支持 SubFunction 参数的服务应支持 SubFunction 参数表中定义的 SubFunction 参数值。
每个服务都包含一个表，该表定义了 SubFunction 参数值，仅考虑（SubFunction 参数字节）第 0 位到第 6 位。
注意
如果 SPRMIB 被设置为 TRUE 且传输包含大量的数据，以及需要使用分页缓冲处理，则可能会出现以下情况：第一批数据的传输的开始在响应时序窗口内，但服务在终止时处于响应时序窗口外。如果在这种情况下抑制响应，则无法通知客户端关于延迟，但服务器仍然处于繁忙状态（尚未做好接收下一个请求的准备）。
对于客户端，建议不要在同一请求中传输大量的数据并设置 SPRMIB（例如，SID 为 0x19，SF 为 0x0A），因为这会违背 SPRMIB 的设计初衷。对于服务器端，如果 SPRMIB 为 TRUE 且使用了分页缓冲处理，建议发送 NRC 0x78 (RCRRP) 并随后发送肯定响应。
表 12 定义了请求消息的 SubFunction 参数。
表 14 详细说明了 SubFunction 字节的值的计算方法。
9.2.3 请求消息的数据参数的定义
本子条款指定了请求/指示服务 <服务名称> 的数据参数 $DataParam (DP_)。如果所描述的服务不使用任何数据参数，则本子条款不包含任何定义。数据参数部分可以包含多个字节。本子条款提供了对每个数据参数的通用描述。详细定义可在本文档的附录中被找到。具体附录取决于服务。附录还规定了在服务器支持该服务的情况下，数据参数是否必须被支持，或者是否对于用户为可选的。
表 15 规定了请求消息的数据参数。
9.3 肯定响应消息
9.3.1 肯定响应消息的定义
本子条款包含一个或多个表，被用于对服务响应/确认的 A_PDU（应用层协议数据单元，参见条款 8）参数进行定义。如果不同 SubFunction 参数（$Level）的响应消息在 A_Data 参数结构上存在差异，且无法在单个表中被清晰地定义，则每个 SubFunction 参数（$Level）可能需要一个单独的表。
诊断服务的肯定响应消息（如果需要）应在诊断服务执行完毕后被发送。如果诊断服务需要不同的处理方式（例如，ECUReset 服务），则对何时发送肯定响应消息的相应说明可以在该诊断服务的服务描述中被找到。
表 16 规定了肯定响应的 A_PDU。
注：
上表所示的寻址信息仅被用于定义目的。后续的服务响应/确认定义仅指定 A_PDU 的 A_Data 参数，因为 A_PDU 的 A_Data 参数代表服务响应/确认的消息数据字节。
9.3.2 肯定响应消息的数据参数的定义
本子条款规定了服务 <服务名称> 的响应/确认所需的数据参数。如果所描述的服务不使用任何数据参数，则本子条款不包含任何定义。数据参数部分可以包含多个字节。本子条款提供了对每个数据参数的通用描述。详细定义可在本文档的附录中被找到。具体附录取决于服务。附录还规定了在服务器支持该服务的情况下，数据参数是否必须被支持，或者是否对于用户为可选的。
表 17 规定了响应的数据参数。
9.4 支持的否定响应码（NRC_）
本子条款规定了此服务应实现的否定响应代码。下表记录了每个响应代码的适用情况。否定响应消息的定义见 8.6 节。服务器应通过否定响应的 A_PDU 指示已识别的错误情况。
如果适用，除各服务描述中被指定的否定响应代码外，还应使用在 A.1 节中被列出的否定响应代码。详细信息见 A.1 节。
表 18 列出了支持的否定响应代码。
9.5 消息流示例
本子条款包含服务 <服务名称> 的消息流的示例。所有示例均以消息级别被显示（不包含寻址信息）。
表 19 列出了请求消息的消息流的示例。
表 20 列出了肯定响应消息的消息流的示例。
表 21 列出了否定响应消息的消息流的示例。
10 诊断和通信管理功能单元
10.1 概述
表 22 指定了诊断和通信管理功能单元。
10.2 DiagnosticSessionControl (0x10) 服务
10.2.1 服务描述
DiagnosticSessionControl 服务被用于在服务器中启用不同的诊断会话。
诊断会话会在服务器中启用一组特定的诊断服务和/或功能。此服务使服务器能够报告（诊断会话被启用时有效）数据链路层的特定参数（例如，时序参数）的值。本文档的用户应定义在每个诊断会话中被启用的确切的服务和/或功能集。
在服务器中必须始终只存在一个诊断会话处于活动状态。服务器启动时必须始终启动默认诊断会话。如果没有启动其他诊断会话，则只要服务器上电，默认诊断会话就应持续运行。
服务器应能够在正常运行条件以及由车辆制造商定义的其他运行条件（例如，跛行回家模式）下提供诊断功能。
如果客户端请求的诊断会话已处于运行状态，则服务器应发送肯定响应消息，并按照图 7 所示的方式运行，该图描述了服务器在会话切换时的内部行为。
每当客户端请求新的诊断会话时，服务器应在新的诊断会话的时序生效之前发送 DiagnosticSessionControl 服务的肯定响应消息。某些情况下，可能需要在发送肯定响应之前进入新的诊断会话，同时保持响应的发送时序。如果服务器无法启动被请求的新的诊断会话，则应发送 DiagnosticSessionControl 服务的否定响应消息，当前会话将继续运行（有关服务器和客户端行为的更多信息，请参阅参数 diagnosticSession 的定义）。非默认诊断会话（不包括 programmingSession）中的诊断服务和功能集是默认诊断会话的超集，这意味着切换到任何非默认诊断会话时，默认诊断会话中的诊断功能也可用。会话可以启用车辆制造商特定的服务和功能，这些服务和功能不被包含在本文档中。
要启动新的诊断会话，服务器可以请求满足某些条件。所有这些条件均由用户定义。此类条件的示例包括：
- 服务器可能只允许具有特定客户端标识符（客户端诊断地址）的客户端启动特定的新的诊断会话（例如，服务器可能要求只有客户端标识符为 0xF4 的客户端才能启动扩展诊断会话）。
- 可能需要满足某些安全条件（例如，车辆不得移动或发动机不得运转）。例如，转换到编程会话可能会导致正常功能丧失，因此某些 ECU 可能要求车辆处于安全状态。
在某些系统中，启动新的诊断会话时需要更改通信时序参数。DiagnosticSessionControl 服务实体可以使用相应的服务原语来更改由底层指定的时序参数，从而更改本地节点以及客户端想要与之通信的节点的通信时序。
图 7 概述了诊断会话切换以及服务器在切换到另一个会话时应执行的操作。
 |
Figure 7 — Server diagnostic session state diagram |
表 23 列出了在默认会话和非默认会话（定时服务）期间被允许的服务。任何非默认会话都和一个诊断会话定时器相关联，客户端必须保持该定时器处于活动状态。
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
10.2.2 请求消息
10.2.2.1 请求消息的定义
表 24 指定了请求消息的定义。
10.2.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
SubFunction 参数 diagnosticSessionType 由 DiagnosticSessionControl 服务用于对服务器的具体行为进行选择。表 25 详细说明了各种诊断会话及其用法。
下表指定了以下 SubFunction 参数值（未显示 suppressPosRspMsgIndicationBit（位 7））。
10.2.2.3 请求消息的数据参数的定义
此服务不支持请求消息的数据参数。
10.2.3 肯定响应消息
10.2.3.1 肯定响应消息的定义
表 26 指定了肯定响应消息的定义。
10.2.3.2 肯定响应消息的数据参数的定义
表 27 指定了响应消息的数据参数的定义。
表 28 和表 29 定义了响应消息的数据参数 sessionParameterRecord 的结构，适用于此服务的实现（在受支持的数据链路上）。
10.2.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 30 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
10.2.5 消息流示例 DiagnosticSessionControl - 开始编程会话
此消息流展示了如何在服务器中启用编程会话。客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的第 7 位）设置为 FALSE （'0'）以请求响应消息。在本示例中，假设 P2Server_max 等于 50 毫秒，P2*Server_max 等于 5000 毫秒。
表 31 指定了 DiagnosticSessionControl 服务的请求消息的消息流的示例。
表 32 指定了 DiagnosticSessionControl 服务的肯定响应消息的消息流的示例。
10.3 ECUReset（0x11）服务
10.3.1 服务描述
ECUReset 服务由客户端用于请求服务器复位。
此服务请求服务器根据响应消息的内容（如有需要）执行服务器复位。该响应消息可以在服务器执行复位之前或之后被发送。强烈建议在执行 ECU 复位之前发送 ECUReset 服务的肯定响应消息。
重要
服务器和客户端应满足 8.7 节中规定的请求和响应消息的行为。
本文档未定义 ECU 在从发送 ECUReset 服务的肯定响应消息到复位成功期间的行为。建议在此期间 ECU 不接受任何请求消息，也不发送任何响应消息。
10.3.2 请求消息
10.3.2.1 请求消息的定义
表 33 指定了请求消息的定义。
10.3.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
ECUReset 服务的请求消息使用 SubFunction 参数 resetType 来描述服务器应如何执行复位操作（未显示 suppressPosRspMsgIndicationBit（位 7））。
表 34 指定了请求消息的 SubFunction 参数的定义。
10.3.2.3 请求消息的数据参数的定义
此服务不支持请求消息的数据参数。
10.3.3 肯定响应消息
10.3.3.1 肯定响应消息的定义
表 35 指定了肯定响应消息的定义。
10.3.3.2 肯定响应消息的数据参数的定义
表 36 指定了响应消息的数据参数的定义。
10.3.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 37 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
10.3.5 消息流示例 ECUReset
本子条款规定了服务器成功地执行 ECUReset 服务所需满足的条件。
服务器需满足的条件：点火开关已打开，系统不得处于运行模式（例如，如果系统是发动机管理系统，则发动机必须关闭）。
客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的第 7 位）设置为 FALSE （'0'）以请求响应消息。
服务器在执行复位（由 resetType 定义）操作前，必须先发送 ECUReset 服务的肯定响应消息。
表 38 指定了 ECUReset 服务的请求消息的消息流的示例 #1。
10.4 SecurityAccess（0x27）服务
10.4.1 服务描述
此服务的目的是提供一种对数据和/或诊断服务进行访问的方式，出于安全、排放或安保原因，对访问进行限制。例如，将程序或数据下载/上传到服务器以及对服务器的特定内存位置进行读取的诊断服务，可能需要安全访问权限。下载到服务器的不当程序或数据可能会损坏电子设备或其他车辆部件，或使车辆不符合排放、安全或安保标准。此安全机制采用种子和密钥的形式。
对此服务进行使用的典型示例如下：
- 客户端请求“种子”
- 服务器发送“种子”
- 客户端发送“密钥”（与接收到的种子匹配）
- 服务器响应“密钥”有效，并对自身进行解锁
SubFunction 参数 requestSeed 的值必须始终为奇数，且同一安全级别的（与 SubFunction 参数 requestSeed）对应的 SubFunction 参数 sendKey 的值必须等于 SubFunction 参数 requestSeed 的值加 1。
任意时刻只能存在一个安全级别处于被激活状态。例如，如果与 requestSeed（0x03）关联的安全级别处于被激活状态，并且测试仪的请求成功地解锁了与 requestSeed（0x01）关联的安全级别，则此时应仅解锁与 requestSeed（0x01）关联的安全级别（所支持的受保护功能）。之前被解锁的与 requestSeed（0x03）关联的安全级别（所支持的任何其他受保护功能）将不再处于被激活状态。安全级别的编号是任意的（级别之间不存在任何关系）。
客户端应通过发送 SecurityAccess 服务的带有 SubFunction 参数 requestSeed 的请求消息以请求对服务器进行解锁。服务器应通过肯定响应消息（对于 SecurityAccess 服务的带有 SubFunction 参数 requestSeed 的请求消息）发送“种子”作为响应。客户端随后应通过发送 SecurityAccess 服务的带有 SubFunction 参数 sendKey 的请求消息向服务器返回一个“密钥”作为响应。服务器应将此“密钥”与内部存储/计算的密钥进行比较。如果两者匹配，则服务器应开启（解锁）客户端对特定服务/数据的访问权限，并通过肯定响应消息（对于 SecurityAccess 服务的带有 SubFunction 参数 sendKey 的请求消息）进行指示。如果两者不匹配，则应将其视为一次无效的访问尝试。对于无效的访问尝试，应要求客户端按照附件 I 中的规定，通过 SecurityAccess 服务的带有 SubFunction 参数 requestSeed 的请求消息重新进行尝试。有关对安全访问的处理的更多详细信息，请参见附件 I。
如果服务器支持安全级别，但在收到 SecurityAccess 服务的带有 SubFunction 参数 requestSeed 的请求消息时，所请求的安全级别已被解锁，则该服务器应通过种子值为零 (0) 的肯定响应消息（对于 SecurityAccess 服务的带有 SubFunction 参数 requestSeed 的请求消息）进行响应。对于当前已被锁定的安全级别，服务器绝不应发送种子值为零 (0) 的肯定响应消息。客户端应使用此方法，通过检查种子是否为零确定服务器是否已解锁特定的安全级别。
在服务器上电/复位后，以及在经历一定次数的无效的访问尝试后（详见下文），可能需要在进行由车辆制造商指定的延时后，服务器才能对客户端发送肯定响应消息（对于 SecurityAccess 服务的带有 SubFunction 参数 requestSeed 的请求消息）。如果服务器支持延时，则在服务器上电/复位后（在上电/复位前被执行的 SecurityAccess 服务已失败），以及在经历一定次数的无效的访问尝试后，应进行延时。如果服务器支持延时，则在成功地发送肯定响应消息（对于 SecurityAccess 服务的带有 SubFunction 参数 sendKey 的请求消息）后，服务器应清除上电/复位时由延时定时器发出的（内部）指示。如果服务器支持延时，并且无法确定在上电/复位前被执行的 SecurityAccess 服务是否失败，则延时定时器在上电/复位后应始终保持被激活状态。仅当服务器在上电/复位时处于锁定状态才需要进行延时。车辆制造商应选择是否支持延时。
处理对 SecurityAccess 服务的请求不得妨碍正常的车辆通信或其他诊断通信。
如果在服务器处于锁定状态时请求 SecurityAccess 服务，则提供该服务的服务器应支持拒绝消息。
在特定的诊断会话中被请求的某些诊断功能/服务可能需要先成功地执行 SecurityAccess 服务，在这种情况下，需要执行以下服务：
- DiagnosticSessionControl 服务
- SecurityAccess 服务
- 安全诊断服务
对于已被启用的诊断会话，服务器允许使用不同的访问模式。
重要
服务器和客户端应满足 8.7 节中规定的请求和响应消息的行为。
10.4.2 请求消息
10.4.2.1 请求消息的定义
表 40 指定了 SubFunction 参数为 requestSeed 的请求消息的定义。
表 41 指定了 SubFunction 参数为 sendKey 的请求消息的定义。
10.4.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
SubFunction 参数 securityAccessType 向服务器指示此服务的当前步骤、客户端想要访问的安全级别以及种子和密钥的格式。如果服务器支持不同的安全级别，则每个级别都应由不同的 requestSeed 的值标识，该值与 sendKey 的值的对应关系为固定的：
- requestSeed = 0x01 标识了 requestSeed = 0x01 和 sendKey = 0x02 之间的固定的对应关系。
- requestSeed = 0x03 标识了 requestSeed = 0x03 和 sendKey = 0x04 之间的固定的对应关系。
requestSeed 和 sendKey 的值在表 42 中被指定（未显示 suppressPosRspMsgIndicationBit（位 7））。
10.4.2.3 请求消息的数据参数的定义
表 43 指定了请求消息的数据参数的定义。
10.4.3 肯定响应消息
10.4.3.1 肯定响应消息的定义
表 44 指定了肯定响应消息的定义。
10.4.3.2 肯定响应消息的数据参数的定义
表 45 指定了响应消息的数据参数的定义。
10.4.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 46 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
10.4.5 消息流示例 SecurityAccess
10.4.5.1 假设
对于以下消息流示例，假设服务器处于“锁定”状态，满足以下条件即可成功地解锁服务器：
- 请求种子的 SubFunction：0x01 (requestSeed)
- 发送密钥的 SubFunction：0x02 (sendKey)
- 服务器的种子（2 字节）：0x3657
- 服务器的密钥（2 字节）：0xC9A9（例如，种子的二进制补码）
客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的第 7 位）设置为 FALSE （'0'）以请求响应消息。
10.4.5.2 示例 #1 - 服务器处于“锁定”状态
10.4.5.2.1 步骤 #1：请求种子
表 47 指定了 SecurityAccess 服务的请求消息的消息流示例 #1 - 步骤 #1。
10.4.5.2.2 步骤 #2：发送密钥
表 49 指定了 SecurityAccess 服务的请求消息的消息流示例 #1 - 步骤 #2。
10.4.5.3 示例 #2 - 服务器处于“解锁”状态
10.4.5.3.1 步骤 #1：请求种子
表 51 指定了 SecurityAccess 服务的请求消息的消息流示例 #2 - 步骤 #1。
10.5 CommunicationControl（0x28）服务
10.5.1 服务描述
此服务的目的是开启/关闭服务器对某些消息（例如，应用程序通信消息）的发送和/或接收的功能。
如果所请求的 SubFunction 在处于活动状态的会话中受支持，则即使其已处于被激活状态，服务器仍应发送肯定响应。
重要
服务器和客户端应满足 8.7 节中规定的请求和响应消息的行为。
10.5.2 请求消息
10.5.2.1 请求消息的定义
表 53 指定了请求消息的定义。
10.5.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
SubFunction 参数 controlType 包含有关服务器应如何修改（由 communicationType 参数引用）通信模式的信息（未显示 suppressPosRspMsgIndicationBit（位 7））。
10.5.2.3 请求消息的数据参数的定义
表 55 指定了请求消息的数据参数的定义。
10.5.3 肯定响应消息
10.5.3.1 肯定响应消息的定义
表 56 指定了肯定响应消息的定义。
10.5.3.2 肯定响应消息的数据参数的定义
表 57 指定了肯定响应消息的数据参数的定义。
10.5.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 58 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
10.5.5 消息流示例 CommunicationControl（禁用网络管理消息的传输）
客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的第 7 位）设置为 FALSE （'0'）以请求响应消息。
表 59 指定了 CommunicationControl 服务的请求消息的消息流示例。
10.5.6 消息流示例 CommunicationControl（将远程网络切换至仅诊断调度模式，地址为 0x000A 的节点已被连接至该远程网络）
客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的第 7 位）设置为 FALSE （'0'）以请求响应消息。
表 61 指定了 CommunicationControl 服务的请求消息的消息流示例。
10.5.7 消息流示例 CommunicationControl（将连接至子网络且地址为 0x000A 的节点切换至具有增强地址信息的应用调度模式）
客户端通过将 suppressPosRspMsgIndicationBit（SubFunction 参数的第 7 位）设置为 FALSE （'0'）以请求响应消息。
表 63 指定了 CommunicationControl 服务的请求消息的消息流示例。
10.6 Authentication（0x29）服务
10.6.1 服务概览
本服务的目的是为客户端提供身份验证的方式，使其能够访问受限的（出于安全、排放或安保等原因）数据和/或诊断服务。下载/上传程序或数据至服务器以及对服务器的特定内存位置进行读取的诊断服务可能需要身份验证。下载至服务器的不当程序或数据可能会损坏电子设备或其他车辆部件，或使车辆不符合排放、安全或安保标准。另一方面，从服务器检索数据时也可能存在数据泄漏的风险。
本服务支持两种安全概念：
- 概念 #1 基于使用非对称加密的 PKI 证书交换（参见 10.6.2）。证书格式应采用符合 ISO 7816-8 标准的 CVC 或符合 ISO/IEC 9594-8、RFC 5280 和 RFC 5755 或 IEEE 1609.2 标准的 X.509。
- 概念 #2 基于质询-响应（无需 PKI 证书），其使用带有软件身份验证令牌的非对称加密（参见 10.6.3）或对称加密（参见 10.6.3）。
注意
关于加密内容的生成、分发和存储不在本文档的讨论范围之内。
图 8 概述了 Authentication 服务的安全概念。
图 8 仅显示了主要的身份验证选项。
为了确定服务器支持的身份验证的方式，客户端可以发送带有 SubFunction 参数 authenticationConfiguration 的服务请求。
10.6.2 通过 PKI 证书交换进行身份验证 (APCE)
- Authentication 服务被用于身份验证、取消身份验证及显式地传输证书。SubFunction 参数 authenticationTask 被用于标识待被处理的相应任务。
- SubFunction 参数 deAuthenticate 被用于主动地结束已验证的状态。
- SubFunction 参数 verifyCertificateUnidirectional 被用于启动单向身份验证（仅客户端对于服务器或服务器对于客户端）。
- SubFunction 参数 verifyCertificateBidirectional 被用于启动双向身份验证（客户端和服务器双方）。
- SubFunction 参数 proofOfOwnership 被用于向客户端传输所有权证明。
- SubFunction 参数 transmitCertificate 被用于独立地或在先前的身份验证之后传输证书。
前提条件：
不同的证书集（以及相应的私钥）在客户端和服务器双方都可用：
- 在单向身份验证的情况下，客户端需要一个包含其私钥的客户端证书，被用于验证其合法身份。根据公钥基础设施 (PKI) 的信任模型，服务器可能需要由证书颁发机构 (CA) 颁发并签署的客户端的证书。
- 在双向身份验证的情况下，客户端需要一个包含其私钥的客户端证书，被用于验证其合法身份。此外，服务器还需要一个包含其私钥的服务器证书，被用于验证其合法身份。根据公钥基础设施 (PKI) 的信任模型，客户端和服务器可能都需要由证书颁发机构 (CA) 颁发并签署的证书。
由 SubFunction 参数 verifyCertificateUnidirectional 或 verifyCertificateBidirectional 触发的认证被分为两个步骤，如图 9 所示。
变体 1：单向身份验证
- 客户端创建质询值（如果被用于所有权证明）（1）。
- 通过带有 SubFunction 参数 verifyCertificateUnidirectional 的请求消息，客户端发送其证书，以及其质询值（如已在（1）中生成）（2） 。
- 服务器验证客户端证书（3）。
- 服务器创建质询值（4）。
- 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协商建立会话密钥，则服务器生成一个临时私钥/公钥对，以便稍后获取会话密钥（被用于后续安全通信）（5）。
- 服务器发送临时公钥（如已在（5）中生成），以及其质询值（7）。
- 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协商建立会话密钥，则客户端生成一个临时私钥/公钥对，以便稍后获取会话密钥（被用于后续安全通信）（9）。
- 通过构建适当的身份验证令牌，客户端计算所有权证明，该令牌的待签名内容至少包含服务器的（部分）质询值，以及其临时公钥（如已在（9）中生成）（10）。
- 客户端通过带有 SubFunction 参数 proofOfOwnership 的请求消息发送所有权证明，以及其临时公钥（如已在（9）中生成）（11）。
- 服务器使用从客户端接收到的证书中的临时公钥对所有权证明进行验证（12）。
- 如果客户端在 (2) 中指示建立会话密钥，则服务器将创建或派生会话密钥并启用它们以进行后续安全通信，并设置会话密钥信息（13）。
- 服务器根据访问权限授予（客户端）对诊断对象的访问权限（14）。
- 服务器发送 Authentication 服务的肯定响应消息，并且发送会话密钥信息（如已在（13）中生成）（15）。
- 如果客户端在 (2) 中指示建立会话密钥，则客户端将从会话密钥信息中提取会话密钥或派生会话密钥以进行后续安全通信（16）。
- 如果客户端在 (2) 中指示建立会话密钥，则客户端将使用会话密钥对会话密钥信息进行验证（17）。
- 如果客户端在 (2) 中指示建立会话密钥，则客户端将启用会话密钥以进行后续安全通信（18）。
建议根据 ISO/IEC 9798-3（单向两步身份验证）创建质询，或者创建等效于 ISO/IEC 9798-3 中与安全相关的质询的质询。
建议根据 ISO/IEC 9798-3（单向两步身份验证）构建身份验证令牌，或者构建等效于 ISO/IEC 9798-3 中与安全相关的身份验证令牌的身份验证令牌。
注意
如果证书中所使用的算法仅适用于签名计算，而不适用于密钥协商，则必须保证 Diffie-Hellman 密钥协商（对于建立会话密钥）可用。
注意
（17）确保会话密钥被建立完成且有效。
注意
使用单向身份验证时，客户端不会对服务器进行身份验证。因此，客户端无法确定它是否正在与正确的服务器进行通信。
变体 2：双向身份验证
- 客户端创建质询值（1），并通过带有 SubFunction 参数 verifyCertificateBidirectional 的请求消息发送质询值与客户端证书（2）。
- 服务器验证客户端证书（3）。
- 服务器创建质询值（4）。
- 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协商建立会话密钥，则服务器生成一个临时私钥/公钥对，以便稍后获取会话密钥（被用于后续安全通信）（5）。
- 通过构建适当的身份验证令牌，服务器计算所有权证明，该令牌的待签名内容至少包含客户端的（部分）质询值，以及其临时公钥（如已在（5）中生成）（6）。随后（服务器）将其与质询值（服务器）、服务器证书以及其临时公钥（如已在（5）中生成）一同发送（7）。
- 客户端使用从服务器接收到的证书中的临时公钥对服务器证书及所有权证明进行验证（8）。
- 如果客户端在 (2) 中指示基于临时 Diffie-Hellman 密钥协商建立会话密钥，则客户端生成一个临时私钥/公钥对，以便稍后获取会话密钥（被用于后续安全通信）（9）。
- 通过构建适当的身份验证令牌，客户端计算所有权证明，该令牌的待签名内容至少包含服务器的（部分）质询值，以及其临时公钥（如已在（9）中生成）（10）。
- 客户端通过带有 SubFunction 参数 proofOfOwnership 的请求消息发送所有权证明，以及其临时公钥（如已在（9）中生成）（11）。
- 服务器使用从客户端接收到的证书中的临时公钥对所有权证明进行验证（12）。
- 如果客户端在 (2) 中指示建立会话密钥，则服务器将创建或派生会话密钥并启用它们以进行后续安全通信，并设置会话密钥信息（13）。
- 服务器根据访问权限授予（客户端）对诊断对象的访问权限（14）。
- 服务器发送 Authentication 服务的肯定响应消息，并且发送会话密钥信息（如已在（13）中生成）（15）。
- 如果客户端在 (2) 中指示建立会话密钥，则客户端将从会话密钥信息中提取会话密钥或派生会话密钥以进行后续安全通信（16）。
- 如果客户端在 (2) 中指示建立会话密钥，则客户端将使用会话密钥对会话密钥信息进行验证（17）。
- 如果客户端在 (2) 中指示建立会话密钥，则客户端将启用会话密钥以进行后续安全通信（18）。
若各项验证均通过，服务器应允许客户端对由客户端证书指定的诊断服务进行访问，并向客户端发送肯定响应消息。若在此过程中的任何环节的验证失败，服务器或客户端应停止进行身份验证并发送相应的响应消息。客户端应根据相应的消息显示提示信息（参见外部测试设备规范）。
建议根据 ISO/IEC 9798-3（双向三步身份验证）构建身份验证令牌，或者构建等效于 ISO/IEC 9798-3 中与安全相关的身份验证令牌的身份验证令牌。
注意
如果证书中所使用的算法仅适用于签名计算，而不适用于密钥协商，则必须保证 Diffie-Hellman 密钥协商（对于建立会话密钥）可用。
注意
（17）确保会话密钥被建立完成且有效。
注意
针对无效的访问尝试的管理（如最大尝试次数、（访问尝试间）延迟时间等），应由整车制造商 (OEM) 决定。
注意
在客户端侧，若对服务器的身份验证失败，特别是在服务器侧对客户端的身份验证已通过并授予客户端相应的访问权限后，客户端可选择向服务器发送带有 SubFunction 参数 deAuthenticate 的消息，以确保服务器吊销已授予客户端的访问权限并拒绝后续未经授权的访问请求。对访问的控制应由整车制造商 (OEM) 负责。
本节所述的会话密钥，其有效期最长不得超过与其对应的会话的持续时间。
为了独立于先前的身份验证或在其之后对证书进行传输，可以使用 SubFunction 参数 transmitCertificate。该 SubFunction 参数旨在向服务器提交证书以供后续处理，而无需进行质询-响应的过程。该证书可被用于对额外的权限进行激活或对已签名的数据进行验证（使用证书中的公钥）。因此，应使用对应的私钥对数据进行签名（数据和签名应被独立地发送至服务器）。
对于不同情况（如额外的权限被激活），应提供不同的 SubFunction 参数 certificateEvaluationId，以便服务器对证书进行识别。该 SubFunction 参数可支持多种类型的证书。
注意
通过证书增加权限的机制应由整车制造商 (OEM) 决定。
10.6.3 通过质询-响应进行身份验证 (ACR)
前提条件：
- 如果使用非对称加密，则需要客户端密钥对：客户端私钥存在于客户端，客户端公钥存在于服务器。如果采用双向身份验证，则需要额外的服务器密钥对：服务器私钥存在于服务器，服务器公钥存在于客户端。
- 如果使用对称加密，则需要存在一个对称密钥，该密钥应预先在客户端和服务器之间被共享。
变体 1：单向身份验证
- 通过发送带有 SubFunction 参数 requestChallengeForAuthentication 的请求消息，客户端请求身份验证，并指定要使用的算法及是否需要建立会话密钥（1）。
- 服务器创建质询值（2）。
- 服务器发送质询值，并指示是否需要提供其他参数（3）。
- 客户端创建质询值（如果被用于所有权证明）（4）。
- 客户端应按如下方式计算所有权证明（客户端侧）（5）：
- 如果使用非对称加密：应构建一个合适的（车辆制造商 (OEM) 特定）令牌（例如，基于 CVC），其内容包含令牌授权、身份验证、权限/角色、服务器的质询值，以及（视情况而定）客户端的质询值和其他信息。应使用客户端私钥计算令牌内容的签名，并构建包含令牌内容和签名的客户端的身份验证令牌。生成的客户端的身份验证令牌即为所有权证明（客户端侧）。
- 如果使用对称加密：应使用被预先共享的对称密钥计算服务器的质询值、客户端的质询值，以及附加参数（例如，车辆制造商 (OEM) 预先定义的权限/角色）的签名（例如，一次性签名、HMAC、CMAC 或 GMAC）。生成的签名即为所有权证明（客户端侧）。
- 如果服务器在（3）中指定了附加参数，则客户端应提供相应的附加参数（6）。
- 客户端通过带有 SubFunction 参数 verifyProofOfOwnershipUnidirectional 的请求消息发送所有权证明（如已在（4）中生成）、质询值以及所需的附加参数（如已指定）（7）。
- 服务器对所有权证明（客户端侧）进行验证（8）。
- 如果客户端在 (1) 中指示建立会话密钥，则服务器将创建或派生会话密钥并启用它们以进行后续安全通信，并设置会话密钥信息（10）。
- 服务器根据访问权限授予（客户端）对诊断对象的访问权限（11）。
- 服务器发送 Authentication 服务的肯定响应消息，并且发送会话密钥信息（如已在（10）中生成）（12）。
- 如果客户端在 (1) 中指示建立会话密钥，则客户端将从会话密钥信息中提取会话密钥或派生会话密钥以进行后续安全通信（14）。
- 如果客户端在 (1) 中指示建立会话密钥，则客户端将使用会话密钥对会话密钥信息进行验证（15）。
- 如果客户端在 (1) 中指示建立会话密钥，则客户端将启用会话密钥以进行后续安全通信（16）。
建议根据 ISO/IEC 9798-2 或 ISO/IEC 9798-4（单向两步身份验证）创建质询值，或者创建等效于 ISO/IEC 9798 中与安全相关的质询值的质询值。
注意
（15）确保会话密钥被建立完成且有效。
变体 2：双向身份验证
- 通过发送带有 SubFunction 参数 requestChallengeForAuthentication 的请求消息，客户端请求身份验证，并指定要使用的算法及是否需要建立会话密钥（1）。
- 服务器创建质询值（2）。
- 服务器发送质询值，并指示是否需要提供其他参数（3）。
- 客户端创建质询值（4）。
- 客户端应按如下方式计算所有权证明（客户端侧）（5）：
- 如果使用非对称加密：应构建一个合适的（车辆制造商 (OEM) 特定）令牌（例如，基于 CVC），其内容包含令牌授权、身份验证、权限/角色、服务器的质询值，以及（视情况而定）客户端的质询值和其他信息。应使用客户端私钥计算令牌内容的签名，并构建包含令牌内容和签名的客户端的身份验证令牌。生成的客户端的身份验证令牌即为所有权证明（客户端侧）。
- 如果使用对称加密：应使用被预先共享的对称密钥计算服务器的质询值、客户端的质询值，以及附加参数（例如，车辆制造商 (OEM) 预先定义的权限/角色）的签名（例如，一次性签名、HMAC、CMAC 或 GMAC）。生成的签名即为所有权证明（客户端侧）。
- 如果服务器在（3）中指定了附加参数，则客户端应提供相应的附加参数（6）。
- 客户端通过带有 SubFunction 参数 verifyProofOfOwnershipBidirectional 的请求消息发送所有权证明（如已在（4）中生成）、质询值以及所需的附加参数（如已指定）（7）。
- 服务器对所有权证明（客户端侧）进行验证（8）。
- 服务器应按如下方式计算所有权证明（服务器侧）（9）：
- 如果使用非对称加密：应构建一个合适的（车辆制造商 (OEM) 特定）令牌（例如，基于 CVC），其内容包含令牌授权、身份验证、客户端的质询值，以及（视情况而定）服务器的质询值。应使用服务器私钥计算令牌内容的签名，并构建包含令牌内容和签名的服务器的身份验证令牌。生成的服务器的身份验证令牌即为所有权证明（服务器侧）。
- 如果使用对称加密：应使用被预先共享的对称密钥计算客户端的质询值、服务器的质询值的签名（例如，一次性签名、HMAC、CMAC 或 GMAC）。生成的签名即为所有权证明（服务器侧）。
- 如果客户端在 (1) 中指示建立会话密钥，则服务器将创建或派生会话密钥并启用它们以进行后续安全通信，并设置会话密钥信息（10）。
- 服务器根据访问权限授予（客户端）对诊断对象的访问权限（11）。
- 服务器发送 Authentication 服务的肯定响应消息，并且发送所有权证明（服务器侧）以及会话密钥信息（如已在（10）中生成）（12）。
- 客户端对所有权证明（服务器侧）进行验证（13）。
- 如果客户端在 (1) 中指示建立会话密钥，则客户端将从会话密钥信息中提取会话密钥或派生会话密钥以进行后续安全通信（14）。
- 如果客户端在 (1) 中指示建立会话密钥，则客户端将使用会话密钥对会话密钥信息进行验证（15）。
- 如果客户端在 (1) 中指示建立会话密钥，则客户端将启用会话密钥以进行后续安全通信（16）。
若各项验证均通过，服务器应允许客户端对由客户端证书指定的诊断服务进行访问，并向客户端发送肯定响应消息。若在此过程中的任何环节的验证失败，服务器或客户端应停止进行身份验证并发送相应的响应消息。客户端应根据相应的消息显示提示信息（参见外部测试设备规范）。
建议根据 ISO/IEC 9798-2 或 ISO/IEC 9798-4（双向三步身份验证）构建身份验证令牌，或者构建等效于 ISO/IEC 9798 中与安全相关的身份验证令牌的身份验证令牌。
注意
（15）确保会话密钥被建立完成且有效。
注意
针对无效的访问尝试的管理（如最大尝试次数、（访问尝试间）延迟时间等），应由整车制造商 (OEM) 决定。
注意
在客户端侧，若对服务器的身份验证失败，特别是在服务器侧对客户端的身份验证已通过并授予客户端相应的访问权限后，客户端可选择向服务器发送带有 SubFunction 参数 deAuthenticate 的消息，以确保服务器吊销已授予客户端的访问权限并拒绝后续未经授权的访问请求。对访问的控制应由整车制造商 (OEM) 负责。
本节所述的会话密钥，其有效期最长不得超过与其对应的会话的持续时间。
注意
步骤（11）中授予（客户端）的对诊断对象的访问权限可被更改，具体操作为（再次）在 ACR 流程中的步骤（4）中使用新的权限/角色。这样做，新的权限/角色将替换原有的权限/角色，授予（客户端）的访问权限也会随之更改。
图 10 显示了使用质询-响应 (ACR) 的身份验证。
10.6.4 一般需求
The authentication is designed to secure applicable diagnostic sessions/functions/services. Therefore the following sequence of services shall be required:
- Authentication service,
- Any diagnostic service that is secured or restricted by authentication.
For authentication there is no direct relationship to diagnostic session or security level. Once
authenticated, the server shall be in an authenticated state which it only shall leave if a security timeout
occurs, a mileage offset limit is reached or the authenticated state is intentionally left by the
“deAuthenticate” request. Applicable diagnostic services assigned to the corresponding authentication
settings shall be accessible as long as the client is authenticated.
There are several possibilities to leave the authenticated state:
- Explicitly: the authentication request shall be called with the SubFunction parameter “deAuthenticate”.
- Implicitly using a timeout as fallback: a timer shall be installed. The timer shall start when transitioning to the authenticated state. If the timer times out, then the authenticated state shall be ended. The timeout can be set individually or can be bound to an existing timing parameter (e.g. session layer timing parameter definitions). At least every request message of the same diagnostic protocol received by the transport protocol layer shall keep the authenticated state active and reset the timeout period.
The timer value is vehicle manufacturer specific.
It is recommended that the usage of the timeout is based on a reliable internal time.
- Implicitly using a mileage offset limit as fallback: a mileage monitoring shall be installed. The mileage monitoring shall start when transitioning to the authenticated state. If the mileage limit is reached, then the authenticated state shall be ended.
NOTE 2
The mileage offset limit is vehicle manufacturer specific.
It is recommended that the usage of the mileage monitoring is based on reliable mileage
information.
The explicit exit condition shall be mandatory, the implementation of at least one of the implicit exit
conditions shall be mandatory, both are optionally possible.
If a server supports authentication and is already in an authenticated state when an authentication
request message is received from the same client, that server shall stay in the authenticated state until
the authentication is again successfully completed. The server shall change its state to the new received
authentication information.
Unsuccessful attempts to access an authenticated state shall not prevent other diagnostic
communication. An authenticated state shall be linked to a certain diagnostic channel. Multiple clients
can be handled on multiple channels with different authentication settings. The basis for this would be a
multi-user server system.
Servers which provide security shall support the NRC 3416 “authenticationRequired”, if a secured
service is requested while the server is in a non-authenticated state.
As an option, session keys can be established and used to further secure communication between client
and server.
This can be achieved, for example, using one of the following approaches:
- by creation of the session key on the server side and an encrypted transmission to the client, or
- by using an asymmetric key agreement protocol, or
- by derivation of existing pre-shared keys on both sides (in case of symmetric cryptography).
10.6.5 请求消息
10.6.5.1 请求消息的定义
Table 65 specifies the request message definition - SubFunction = deAuthenticate.
Table 66 specifies the request message definition - SubFunction = verifyCertificateUnidirectional.
Table 67 specifies the request message definition - SubFunction = verifyCertificateBidirectional.
Table 68 specifies the request message definition - SubFunction = proofOfOwnership.
Table 69 specifies the request message definition - SubFunction = transmitCertificate.
Table 70 specifies the request message definition - SubFunction = requestChallengeForAuthentication.
Table 71 specifies the request message definition - SubFunction = verifyProofOfOwnershipUnidirectional.
The value of algorithmIndicator in the request message definition - SubFunction = verifyProofOfOwnershipUnidirectional (Table 71) shall be the same as the value of algorithmIndicator in the request message definition - SubFunction = requestChallengeForAuthentication (Table 70).
Table 72 specifies the request message definition - SubFunction =
verifyProofOfOwnershipBidirectional.
The value of algorithmIndicator in the request message definition - SubFunction = verifyProofOfOwnershipBidirectional (Table 72) shall be the same as the value of algorithmIndicator in the request message definition - SubFunction = requestChallengeForAuthentication (Table 70).
Table 73 specifies the request message definition - SubFunction = authenticationConfiguration.
10.6.5.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
The SubFunction parameter authenticationTask indicates to the server the explicit task which it should
conduct (suppressPosRspMsgIndicationBit (bit 7) not shown). Table 74 specifies the request message
SubFunction parameter definition.
10.6.5.3 请求消息的数据参数的定义
Table 75 specifies the data-parameters of the request message.
10.6.6 肯定响应消息
10.6.6.1 肯定响应消息的定义
Table 76 specifies the response message definition - SubFunction = deAuthenticate.
Table 77 specifies the response message definition - SubFunction = verifyCertificateUnidirectional.
Table 78 specifies the response message definition - SubFunction = verifyCertificateBidirectional.
Table 79 specifies the response message definition - SubFunction = proofOfOwnership.
Table 80 specifies the response message definition - SubFunction = transmitCertificate.
Table 81 specifies the response message definition - SubFunction = requestChallengeForAuthentication.
The value of algorithmIndicator in the response message definition - SubFunction = requestChallengeForAuthentication (Table 81) shall be the same as the value of algorithmIndicator in the request message definition - SubFunction = requestChallengeForAuthentication (Table 70).
Table 82 specifies the response message definition - SubFunction =
verifyProofOfOwnershipUnidirectional.
The value of algorithmIndicator in the response message definition - SubFunction = verifyProofOfOwnershipBidirectional (Table 82) shall be the same as the value of algorithmIndicator in the request message definition - SubFunction = requestChallengeForAuthentication (Table 70).
Table 83 specifies the response message definition - SubFunction =
verifyProofOfOwnershipBidirectional.
The value of algorithmIndicator in the response message definition - SubFunction = verifyProofOfOwnershipBidirectional (Table 83) shall be the same as the value of algorithmIndicator in the request message definition - SubFunction = requestChallengeForAuthentication (Table 70).
Table 84 specifies the response message definition - SubFunction = authenticationConfiguration.
10.6.6.2 肯定响应消息的数据参数的定义
Table 85 specifies the data-parameters of the response message.
10.6.7 支持的否定响应码（NRC_）
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 86. The listed negative responses shall
be used if the error scenario applies to the server.
The evaluation sequence is documented in Figure 11.
NOTE
The detailed NRCs 0x50 to 0x5D can be used. Alternatively, the general negative response code 0x10 can
be used.
10.6.8 消息流示例 Authentication
10.6.8.1 示例 #1 - 通过 PKI 证书交换（无需建立会话密钥）进行单向身份验证（正常流程）
10.6.8.1.1 假设
For the below given message flow the following conditions apply:
- Step #1:
- This step is optional: client requests the authentication configuration of the server
- Step #2:
- No secure communication for further communication - communicationConfiguration: 0x00
- Length of Certificate Client (2 bytes): 0x01F4
- Certificate Client (500 bytes)
- Parameter returnValue in the positive response indicating Certificate verified, Ownership verification necessary: 0x11
- Length of the Challenge Client (2 bytes): 0x0020
- Challenge Client: 32 bytes random number
- Length of the Challenge Server (2 bytes): 0x0040
- Challenge Server: 32 bytes ECU identification concatenated with 32 bytes random number
- Step #3:
- Length of Proof of Ownership (2 bytes): 0x0150
- Proof of Ownership (336 bytes)
- Parameter returnValue in the positive response indicating Ownership verified, Authentication complete: 0x12
- Length of session key information (2 bytes): 0x0000
- Step #4:
- Diagnostic service ECUReset (0x11) is a secured service
10.6.8.1.2 步骤 #1 - 请求身份验证配置
Table 87 specifies the Authentication Configuration request message flow example #1 - step #1.
Table 88 specifies the Authentication Configuration positive response message flow example #1 - step #1.
10.6.8.1.3 步骤 #2 - 发送证书客户端
Table 89 specifies the Authentication request message flow example #1 - step #2.
Table 90 specifies the Authentication positive response message flow example #1 - step #2.
10.6.8.1.4 步骤 #3 - 验证所有权证明
Table 91 specifies the Authentication request message flow example #1 - step #3.
Table 92 specifies the Authentication positive response message flow example #1 - step #3.
10.6.8.1.5 步骤 #4 - 尝试发送随机安全服务
Table 93 specifies the ECUReset request message after successful Authentication request message attempt - example #1 - step #4.
Table 94 specifies the ECUReset response message after successful Authentication request message attempt example #1 - step #4.
10.6.8.2 示例 #2 - 通过 PKI 证书交换（无需建立会话密钥）进行单向身份验证（异常流程）
10.6.8.2.1 假设
For the below given message flow the following conditions apply:
- Step #1:
- No secure communication for further communication - communicationConfiguration: 0x00
- Length of Certificate Client (2 bytes): 0x01F4
- Certificate Client (500 bytes)
- NRC 0x50 Certificate verification failed ‐ Invalid Time Period (CVFITP)
- Length of the Challenge Client (2 bytes): 0x0020
- Challenge Client: 32 bytes random number
- Step #2:
- Diagnostic service ECUReset (0x11) is a secured service
10.6.8.2.2 步骤 #1 - 发送证书客户端
Table 95 specifies the Authentication request message flow example #2 - step #1.
Table 96 specifies the Authentication positive response message flow example #2 - step #1.
10.6.8.2.3 步骤 #2 - 尝试发送随机安全服务
Table 97 specifies the ECUReset request message after failed Authentication request message attempt -
example #2 - step #2.
Table 98 specifies the ECUReset response message after failed Authentication request message attempt example #2 - step #2.
10.6.8.3 示例 #3 – 通过 PKI 证书交换进行身份验证后传输证书（正常流程）
10.6.8.3.1 假设
For the below given message flow the following conditions apply:
- Server is already in an authenticated state,
- Length of Certificate Data (2 bytes): 0x01F4,
- Certificate Data (500 bytes),
- Parameter returnValue in the positive response indicating Certificate verified: 0x13,
- Public key in Certificate is used for signature verification, e.g. after signed data is transferred to the server.
The signature may be sent within the data transferred to the server or an additional individual vehicle manufacturer routine. A suitable signature for the data may be sent to be able to verify the transferred data with the public key from the Certificate.
10.6.8.3.2 步骤 #1 - 发送证书
Table 99 specifies the transmitCertificate request message flow example #3 - step #1.
Table 100 specifies the transmitCertificate positive response message flow example #3 - step #1.
10.6.8.4 示例 #4 - 通过使用非对称加密的质询-响应（无需建立会话密钥）进行单向身份验证（正常流程）
10.6.8.4.1 假设
For the below given message flow the following conditions apply:
- Step #1: This step is optional: client requests the authentication configuration of the server
- Parameter communicationConfiguration (1 byte): 0x00
- Parameter algorithmIndicator (16 bytes): 0x06092A864886F70D01010A0000000000
NOTE 1
In this example the value 0x06092A864886F70D01010A0000000000 is the BER encoding (right padded with zeros up to 16 bytes) of the OID 1.2.840.113549.1.1.10 identifying the RSA digital signature scheme RSASSA-PSS according to PKCS #1 v2.2 RSA Cryptography Standard.
- Length of the Challenge Client (2 bytes): 0x0020
- Challenge Client: 32 bytes random number
- No additional parameter data needed
- Length of the Challenge Server (2 bytes): 0x0040
- Server challenge: 32 bytes ECU identification concatenated with 32 bytes random number
- Length of the client Proof of Ownership (2 bytes): 0x0150
- Proof of Ownership: 336 bytes software authentication token with structure based on the cardverifiable certificate definition as per ISO/IEC 7618-8:
- The authentication token is encoded in the TLV template 0x7F21; this template contains the token content and the token signature.
- The content is encoded in the TLV object 0x7F4E within the TLV template 0x7F21.
- The signature is encoded in the TLV object 0x5F37 within the TLV template 0x7F21.
NOTE 2
The authentication token is valid, i.e. the format, content and the signature are correct.
10.6.8.4.2 步骤 #1 - 请求身份验证配置
Table 101 specifies the Authentication Configuration request message flow example #4 - step #1.
Table 102 specifies the Authentication Configuration positive response message flow example #4 - step #1.
10.6.8.4.3 Step #2: Request the Challenge
Table 103 specifies the Authentication request message flow example #4 - step #2.
Table 104 specifies the Authentication positive response message flow example #4 - step #2.
10.6.8.4.4 Step #3: Validate the Proof of Ownership
Table 105 specifies the Authentication request message flow example #4 - step #3.
Table 106 specifies the Authentication positive response message flow example #4 - step #3.
10.6.8.5 Example #5 - Unidirectional Authentication using Challenge-Response (ACR) with asymmetric cryptography without session key establishment (failure path)
10.6.8.5.1 Assumptions
For the below given message flow the following conditions apply:
- Parameter communicationConfiguration (1 byte): 0x00
- Parameter algorithmIndicator (16 bytes): 0x06092A864886F70D01010A0000000000
NOTE 1
In this example the value 0x06092A864886F70D01010A0000000000 is the BER encoding (right padded with zeros up to 16 bytes) of the OID 1.2.840.113549.1.1.10 identifying the RSA digital signature scheme RSASSA-PSS according to PKCS #1 v2.2 RSA Cryptography Standard.
- Length of the Challenge Client (2 bytes): 0x0020
- Challenge Client: 32 bytes random number
- No additional parameter data needed
- Length of the Challenge Server (2 bytes): 0x0040
- Server challenge: 32 bytes ECU identification concatenated with 32 bytes random number
- Length of the client Proof of Ownership (2 bytes): 0x0150
- Proof of Ownership: 336 bytes software authentication token with structure based on the cardverifiable certificate definition as per ISO/IEC 7618-8:
- The authentication token is encoded in the TLV template 0x7F21; this template contains the token content and the token signature.
- The content is encoded in the TLV object 0x7F4E within the TLV template 0x7F21.
- The signature is encoded in the TLV object 0x5F37 within the TLV template 0x7F21.
NOTE 1
The authentication token is not valid due to an incorrect signature.
- Parameter returnValue in the positive response indicating invalid signature: 0x21
NOTE 2
The value of this parameter is in the vehicle manufacturer specific range. The Mnemonic is also manufacturer specific.
10.6.8.5.2 Step #1: Request the Challenge
Table 107 specifies the Authentication request message flow example #5 - step #1.
Table 108 specifies the Authentication positive response message flow example #5 - step #1.
10.6.8.5.3 Step #2: Validate the Proof of Ownership
Table 109 specifies the Authentication request message flow example #5 - step #2.
Table 110 specifies the Authentication negative response message flow example #5 - step #2.
10.6.8.6 Example #6 Unidirectional Authentication using Challenge-Response (ACR) with symmetric cryptography without session key establishment (happy path)
10.6.8.6.1 Assumptions
For the below given message flow the following conditions apply:
- Parameter communicationConfiguration (1 byte): 0x00
- Parameter algorithmIndicator (16 bytes): 0x06096086480165030401020000000000
NOTE
In this example the value 0x06096086480165030401020000000000 is the BER encoding (right padded with zeros up to 16 bytes) of the OID 2.16.840.1.101.3.4.1.2 identifying the AES-128 CBC mode cryptographic algorithm according to FIPS PUB 197. In this example the AES keys is 0x2B7E151628AED2A6ABF7158809CF4F3C
- No Challenge Client needed
- No additional parameter data needed
- Length of the Challenge Server (2 bytes): 0x0010
- Server challenge: 16 bytes random number
- Length of the client Proof of Ownership (2 bytes): 0x0010
- Client Proof of Ownership: 16 bytes value calculated from the Challenge Server and the key. In this example, the calculation is AES encryption of the 16 bytes of Challenge Server using the key 0x2B7E151628AED2A6ABF7158809CF4F3C
10.6.8.6.2 Step #1: Request challenge for Authentication
Table 111 specifies the Authentication request message flow example #6 - step #1.
Table 112 specifies the Authentication positive response message flow example #6 - step #1. The server returns 16 bytes of the challengeServer value.
10.6.8.6.3 Step #2: Verify Proof of Ownership Unidirectional
Table 113 defines Authentication request message flow example #6 - step #2. The client provided the correct ProofOfOwnership value.
Table 114 defines Authentication positive response message flow example #6 - step #2.
10.6.8.7 Example #7 Unidirectional Authentication using Challenge-Response (ACR) with symmetric cryptography without session key establishment (failure path)
10.6.8.7.1 Assumptions
For the below given message flow the following conditions apply:
- Parameter communicationConfiguration (1 byte): 0x00
- Parameter algorithmIndicator (16 bytes): 0x06096086480165030401020000000000
NOTE
In this example the value 0x06096086480165030401020000000000 is the BER encoding (right padded with zeros up to 16 bytes) of the OID 2.16.840.1.101.3.4.1.2 identifying the AES-128 CBC mode cryptographic algorithm according to FIPS PUB 197.
- No Challenge Client needed
- No additional parameter data needed
- Length of the Challenge Server (2 bytes): 0x0010
- Server challenge: 16 bytes random number
- Length of the client Proof of Ownership (2 bytes): 0x0010
- Client Proof of Ownership: 16 bytes value calculated from the Challenge Server and the key. In this example, the AES keys of the client do not match with the keys of the server
10.6.8.7.2 Step #1: Request challenge for Authentication
Table 115 specifies the Authentication request message flow example #7 - step #1.
Table 116 specifies the Authentication positive response message flow example #7 - step #1. The server returns 16 bytes of the challengeServer value.
10.6.8.7.3 Step #2: Verify Proof of Ownership Unidirectional
Table 117 defines Authentication request message flow example #7 - step #2. The client provides an invalid Proof of Ownership.
Table 118 defines Authentication negative response message flow example #7 - step #2.
10.7 TesterPresent (0x3E) 服务
10.7.1 服务描述
此服务被用于向服务器（或多个服务器）指示客户端仍处于连接状态，并且先前被激活的某些诊断服务和/或通信将仍处于活动状态。
此服务被用于将一个或多个服务器保持在（除默认会话之外）诊断会话中。这可以通过定期地发送 TesterPresent 服务的请求消息来实现，在没有其他诊断服务的情况下，此举可防止服务器自动地切换回默认会话。有关通过此服务将一个或多个服务器保持在（除默认会话之外）诊断会话中的详细要求，请参阅 ISO 14229 的实现规范。
重要
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
10.7.2 请求消息
10.7.2.1 请求消息的定义
表 119 指定了请求消息的定义。
10.7.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
表 120 指定了此服务的 SubFunction 参数（未显示 suppressPosRspMsgIndicationBit（位 7））。
10.7.2.3 请求消息的数据参数的定义
此服务不支持请求消息的数据参数。
10.7.3 肯定响应消息
10.7.3.1 肯定响应消息的定义
表 121 指定了肯定响应消息的定义。
10.7.3.2 肯定响应消息的数据参数的定义
表 122 指定了肯定响应消息的数据参数的定义。
10.7.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 123 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
10.7.5 消息流示例 TesterPresent
10.7.5.1 示例 #1 - TesterPresent（suppressPosRspMsgIndicationBit = FALSE）
表 124 指定了 TesterPresent 服务的请求消息的消息流的示例 #1。
10.7.5.2 示例 #2 - TesterPresent（suppressPosRspMsgIndicationBit = TRUE）
表 126 指定了 TesterPresent 服务的请求消息的消息流的示例 #2。
10.8 ControlDTCSetting (0x85) service
10.8.1 Service description
The ControlDTCSetting service shall be used by a client to stop or resume the updating of DTC status
bits in the server(s). DTC status bits are reported in the statusOfDTC parameter of the positive response
to certain SubFunctions of ReadDTCInformation (see D.2 for definition of the bits).
The ControlDTCSetting request message can be used to stop the updating of DTC status bits in an
individual server or a group of servers. If the server being addressed is not able to stop the updating of
DTC status bits, it shall respond with a ControlDTCSetting negative response message indicating the
reason for the reject.
When the server accepts a ControlDTCSetting request with a SubFunction value of DTCSettingType =
off, the server shall suspend any updates to the DTC status bits (i.e. freeze current values) until the
functionality is enabled again. The update of the DTC status bit information shall continue once a
ControlDTCSetting request is performed with SubFunction set to "on" or a transition to a session where
ControlDTCSetting is not supported occurs (e.g. session layer timeout to defaultSession, ECU reset, etc.).
The server shall still send a positive response if the service is supported in the active session with a
requested SubFunction set to either "on" or "off" even if the requested DTC setting state is already
active.
If a ClearDiagnosticInformation (0x14) service is sent by the client, the ControlDTCSetting shall not
prohibit resetting the server's DTC status bits. The behaviour of the individual DTC status bits shall be
implemented according to the definitions in D.2, Figure D.1 to Figure D.8.
DTC status bits document certain information relative to a numerical identifier (DTC) that represents a
specific fault condition(s). ControlDTCSetting only switches on/off the DTC status bit updating.
ControlDTCSetting service is not intended to cause fault monitoring to be switched off nor is it intended
to cause failsoft strategies to be disabled. It is not recommended that failsoft or failsafe strategies be
directly linked or coupled with DTC status bits (e.g. an accepted ClearDiagnosticInformation request
does not directly remove any active failsoft).
IMPORTANT
The server and the client shall meet the request and response message behaviour as
specified in 8.7.
10.8.2 Request message
10.8.2.1 Request message definition
Table 127 specifies the request message.
10.8.2.2 Request message SubFunction parameter $Level (LEV_) definition
The SubFunction parameter DTCSettingType is used by the ControlDTCSetting request message to
indicate to the server(s) whether diagnostic trouble code status bit updating shall stop or start again
(suppressPosRspMsgIndicationBit (bit 7) not shown in Table 128).
10.8.2.3 Request message data-parameter definition
Table 129 specifies the data-parameter of the request message.
10.8.3 Positive response message
10.8.3.1 Positive response message definition
Table 130 specifies the positive response message.
10.8.3.2 Positive response message data-parameter definition
Table 131 specifies the data-parameter of the positive response message.
10.8.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 132. The listed negative responses
shall be used if the error scenario applies to the server.
10.8.5 Message flow example(s) ControlDTCSetting
10.8.5.1 Example #1 - ControlDTCSetting (DTCSettingType = off)
Note that this example does not use the capability of the service to transfer additional data to the server. The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 133 specifies the ControlDTCSetting request message flow example #1.
Table 134 specifies the ControlDTCSetting positive response message flow example #1.
10.8.5.2 Example #2 - ControlDTCSetting ( DTCSettingType = on)
This example does not use the capability of the service to transfer additional data to the server. The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 135 specifies the ControlDTCSetting request message flow example #2.
Table 136 specifies the ControlDTCSetting positive response message flow example #2.
10.9 ResponseOnEvent (0x86) 服务
10.9.1 服务描述
ResponseOnEvent 服务请求服务器在发生指定事件时启动或停止对响应的传输。
此服务允许服务器在发生指定事件时自动地执行诊断服务。客户端应指定事件（包括可选的事件参数）以及在该事件发生时需要被执行的诊断服务（包括被传递给该诊断服务的参数）。有关客户端和服务器的行为的简要概述，请参见图 12。
注意
图 12 假设事件窗口定时器被配置为在服务器断电前发生超时，因此 ResponseOnEvent 服务的（最终）肯定响应消息将在事件窗口（计时）的末尾出现。
在接收到 ResponseOnEvent 服务的请求消息时，服务器应对其中的 SubFunction 参数和数据内容进行评估。这包括以下 SubFunction 参数及数据：
- eventType（SubFunction 参数）
- eventWindowTime
- eventTypeRecord (eventTypeParameter #1-#m)
如果 ResponseOnEvent 服务的请求消息中的数据无效（serviceToRespondToRecord 参数不在评估范围内），则应发送带有否定响应码 ROOR（requestOutOfRange）的否定响应消息。serviceToRespondToRecord 参数将在指定事件发生时被评估，该事件将触发对 serviceToRespondToRecord 参数包含的服务的执行。当该事件发生时，应执行 serviceToRespondToRecord 参数包含的服务。对 serviceToRespondToRecord 参数包含的服务的执行遵循的规则与其他服务的相同。特别是，所有服务器的一般响应行为均遵循图 5 和图 6 所示的规则。如果出现条件不满足的情况，则应发送带有相应否定响应码的否定响应消息。应按照 DTC 事件（多个）发生的顺序进行通知。对于 DID 事件（多个）也是如此。
当 SubFunction 参数为 onChangeOfDataIdentifier 或 onComparisonOfValues 时，需要服务器对已被配置的数据标识符 (DID) 的值进行采样并比较。因此，服务器应定义以下参数：
- ResponseOnEventSchedulerRate：被用于比较数据标识符 (DID) 的值或检测 DTC 状态的更改的周期性调度程序的调用频率。
- MaxNumChangeOfDataIdentifierEvents：通过 SubFunction 参数 onChangeOfDataIdentifier 配置的事件的最大数量（一次请求中）。
- MaxNumComparisonOfValueEvents：通过 SubFunction 参数 onComparisonOfValues 配置的事件的最大数量（一次请求中）。
- MaxSupportedDIDLength：比较数据标识符 (DID) 的值时允许的最大比较长度（字节数）。
对于事件的处理，是否以先进先出 (FIFO) 的方式进行处理或是否事件逻辑被暂时地停止，由车辆制造商决定。
强烈建议将 MaxSupportedDIDLength 的值设置为 4 字节（例如，避免定义读取常量“calibration”标签的事件逻辑）。
建议将 ResponseOnEventSchedulerRate 的值设置为服务器内部调度器的速率的整数倍。ResponseOnEventSchedulerRate 的值将直接对服务器的性能造成影响。当 ResponseOnEventSchedulerRate 的值超过阈值时，服务器会将所有对已被配置的数据标识符 (DID) 的值的采样缓存（读取）至本地，并比较这些值，如果满足条件则触发相应事件。数值过小的值会增加服务器的 CPU 负载（过采样），并可能改变服务器的整体行为，这在调试时尤其不理想。
服务器仅在采样阶段检测数据标识符 (DID) 的值的变化。两次采样的值的不同不会触发相应事件（欠采样）。
在系统设计时应选择合适的 ResponseOnEventSchedulerRate 的值，以避免对数据标识符 (DID) 的值的过采样和欠采样造成的影响。
图 13 给出了一个过采样和欠采样的示例。服务器的 ResponseOnEventSchedulerRate 的值被配置为 10 ms，并为数据标识符 (DID) 的值配置了onComparisionOfValues 事件，其 compareLogic 为“大于 80 mV”。在测量时间内，数据标识符 (DID) 的值两次超过阈值“80 mV”，一次在 10 ms 后，另一次在 44 ms 后。服务器每 10 ms 对数据标识符 (DID) 的值进行一次采样，只有第一次（10 ms 后）触发了相应事件。对于第二次（44 ms 后），由于前后采样点的值均低于阈值，因此无法识别。
带有 SubFunction 参数 onChangeOfDataIdentifier 或 onComparisonOfValues 的请求消息将向服务器添加一个新的事件。无论 ResponseOnEvent 服务是否已启动或停止（SubFunction 参数 startResponseOnEvent，stopResponseOnEvent），服务器都应添加该事件。添加新事件后，服务器需要在下次执行周期性调度程序时对新的数据标识符 (DID) 的值进行采样。
配置 eventType（SubFunction 参数）为 onDTCStatusChange 的事件及 SubFunction 参数为 reportMostRecentDtcOnStatusChange 或 reportDTCRecordInformationOnDtcStatusChange 的请求消息将要求服务器在特定 DTC 状态发生更改时发送响应。服务器会根据被提供的 DTCStatusMask 检查每个 ResponseOnEventSchedulerRate 周期内的 DTC 状态的变化，并针对每次检测到的变化发送一个响应。因此，服务器需要定义以下参数：
- MaxNumberOfStoredDTCStatusChangedEvents：在一个 ResponseOnEventSchedulerRate 周期内，可以存储的 DTC 的最大数量（其状态已发生变化）。
实现应遵循以下规则：
- a) ResponseOnEvent 服务可以在任何会话中被设置和激活，包括默认会话。无需 TesterPresent 服务即可使 ResponseOnEvent 服务处于被激活状态。
- b) 如果在指定事件发生时诊断服务正在被处理（这意味着正在接收请求消息、正在执行被请求的服务或正在发送响应消息（包括 NRC 0x78 (RCRRP) 否定响应消息）（如果 suppressPosRspMsgIndicationBit = FALSE）），则由 serviceToRespondToRecord 参数指定的服务请求应在处理结束后才被执行。
注意
在某些情况下，由于 ServiceToRespondTo 参数所请求的服务的延迟，ServiceToRespondTo 参数所请求的服务获取的数据可能与事件发生时的不一致。
- c) 当事件逻辑（条件）满足且事件在事件时间窗口内发生时，服务器应执行 serviceToRespondToRecord 参数所请求的服务。
- d) 一旦 ResponseOnEvent 服务被 ResponseOnEvent 服务的请求消息（SubFunction 参数 startResponseOnEvent）启动，当对应的事件发生时，服务器应向（设置了相应事件并启动了 ResponseOnEvent 服务）客户端发送对应的响应消息。
- e) 当 DiagnosticSessionControl 服务请求切换至任何非默认会话时，无论切换的目标会话是否与当前的会话相同，ResponseOnEvent 服务都应被停止。当返回默认会话时，所有先前在默认会话中被启动的 ResponseOnEvent 服务都应被重新启动。
- f) 多个 ResponseOnEvent 服务可被并行处理，启动或停止它们的前提条件各不相同（不同的 EventType、serviceToRespondToRecords 等）。对 ResponseOnEvent 服务的启动或停止（SubFunction 参数 startResponseOnEvent，stopResponseOnEvent）始终影响所有已被设置的 ResponseOnEvent 服务。
- g) 如果 ResponseOnEvent 服务已被设置并被启动（SubFunction 参数 startResponseOnEvent），则应遵循以下规则：
- i) 如果 eventType（SubFunction 参数）的第 6 位（bit）被设置为 0（不存储事件），则当服务器断电时，对应的事件的 ResponseOnEvent 服务将被停止。服务器在（ResponseOnEvent 服务被停止后）复位或上电后不应继续处理之前已被停止的 ResponseOnEvent 服务。
- ii) 如果 eventType（SubFunction 参数）的第 6 位（bit）被设置为 1（存储事件），则当服务器断电重启后，应恢复之前（断电重启前）已被启动的 ResponseOnEvent 服务。因此，存储事件仅当 eventWindowTime 参数的值为无限大时被允许使用。
- h) 当 eventType（SubFunction 参数）为 stopResponseOnEvent、startResponseOnEvent 或 clearResponseOnEvent 时，应将 suppressPosRspMsgIndicationBit 设置为 1。当检测到指定事件时，服务器应始终发送对应的响应。对于由 serviceToRespondToRecord 参数指定的服务请求，应将 suppressPosRspMsgIndicationBit 设置为 0。
- i) 仅当 eventWindowTime 参数的值不为无限大且当前时间已超出事件时间窗口时，服务器才应发送 ResponseOnEvent 服务的最终响应（参见图 12）。如果在超出事件时间窗口之前，由于任何原因（例如，eventType（SubFunction 参数）为 stopResponseOnEvent 的请求消息或会话切换）ResponseOnEvent 服务被停止，则不应发送最终响应。
- j) 服务器应发送 ResponseOnEvent 服务的“中间”响应，以指示发生在两次周期性调度程序被执行之间的 DTC 状态的更改的次数已超过 MaxNumberOfStoredDTCStatusChangedEvents。
- k) 为避免干扰正常的诊断服务，建议仅将 ResponseOnEvent 服务应用于瞬态事件或情况。服务器应在每次事件发生时发送一次响应。
- l) 为避免造成总线负载过高，在每次对 ResponseOnEvent 服务的周期性调度程序的调用中仅发送一个响应。如果在单次调用中检测到多个事件，则应立即发送与第一个事件对应的响应。如果服务器使用队列，则对后续事件/消息的处理应被延后至后续调用。否则，服务器将丢弃这些事件。新增的事件应在当前响应被发送完成后被（延迟）处理。当 ResponseOnEvent 服务已被启动，服务器应能够处理并发的服务请求并相应地发送响应，参见图 14。对于对应于事件的响应和对应于一般服务请求的响应，应使用不同的源地址。当两者的源地址相同时（一般服务请求的客户端与设置事件的客户端相同），则以下限制适用：
- i) 当事件发生且正在发送对应于该事件的响应时，服务器可以忽略已接收到的由设置该事件的客户端发出的一般服务请求，直到对应于该事件的响应被发送完成。如果一般服务请求由其他客户端发出，则服务器是否忽略该请求取决于服务器自身的功能。
- ii) 当客户端在发送服务请求后收到任何响应时，应对其进行分类：对应于事件的响应或对应于先前的服务请求的响应。
- 1) 如果响应为对应于事件的响应，客户端应在对该响应的接收完成后重新发送服务请求。
- 2) 如果无法对响应进行分类（即，响应既可能为对应于事件的响应，也可能为对应于一般服务请求的响应），客户端应将该响应视为对应于两者的响应（既是对应于事件的响应，也是对应于一般服务请求的响应）。客户端不得重新发送服务请求，除非接收到带有否定响应码 BRR（busyRepeatRequest）的否定响应消息（请参阅本文档中的否定响应码的定义）。
- iii) 当指定事件发生时，服务器应立即发送对应响应。对该响应的传输不得中断任何其他正在被处理的服务请求或响应（即，对应于事件的响应应被延迟发送，直到当前正在被处理的响应被发送完成，参见图 15）。
出于性能考虑（例如，避免未对由 serviceToRespondToRecord 参数指定的服务请求进行处理），建议遵循以下建议：
- 数据标识符 (DID) 的值的数据长度应尽可能地短。建议最大数据长度为 32 位（bit）。更长的数据长度会延长比较数据标识符 (DID) 的值的时间。
- 数据标识符 (DID) 的值应包含测量数据（例如，避免定义对常量进行读取的事件逻辑（条件））。
- 对于由 serviceToRespondToRecord 参数指定的服务请求的肯定响应消息的大小应被限制在由车辆制造商指定的范围内。
重要
服务器和客户端应满足 8.7 节中规定的请求和响应消息的行为。
每个客户端都可以设置自己的事件逻辑（条件），即它们可被独立地处理。
注意
不支持在不同的客户端之间共享事件逻辑（条件）。如果某个客户端将会话切换至非默认会话，服务器应暂停所有 ResponseOnEvent 服务。
哪些客户端可以设置 ResponseOnEvent 服务取决于车辆制造商。如果对于特定客户端而言，ResponseOnEvent 服务不可用，则应返回否定响应码为 SNS（serviceNotSupported）的否定响应消息。
10.9.2 请求消息
10.9.2.1 请求消息的定义
表 138 指定了请求消息的定义。
10.9.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
10.9.2.2.1 请求消息的 SubFunction 参数的定义
SubFunction 参数 eventType 由 ResponseOnEvent 服务的请求消息使用，用于指定需要在服务器中设置的事件并设置 ResponseOnEvent 服务（SubFunction 参数 startResponseOnEvent，stopResponseOnEvent）。表 139 中的 SubFunction 参数值还指定了其适用的 eventTypeRecord 参数的长度（未显示 suppressPosRspMsgIndicationBit（位 7））。
SubFunction 参数 eventType 的位（bit）6 被用于指示事件是否应被存储在服务器的非易失性存储器中，并应在服务器下次上电时被重新启动，或者是否应在服务器断电后被停止（参数 storageState（SubFunction 参数 eventType 的位（bit）6））。
10.9.2.2.2 请求消息的 SubFunction 参数 onDTCStatusChange 的规范
通过 Subfunction 参数 onDTCStatusChange，服务器会监控 DTC 状态的变化，并在 DTC 状态发生变化且 DTC 与 DTCStatusMask 匹配时发送对应于事件的响应。
对于 Subfunction 参数 reportMostRecentTestFailedDTC（假设此时 DTCStatusMask 为 0x01）或 Subfunction 参数 reportMostRecentConfirmedDTC（假设此时 DTCStatusMask 为 0x08），被发送的对应于事件的响应的参数 DTCAndStatusRecord 应包含状态发生变化的 DTC。
10.9.2.2.3 请求消息的 SubFunction 参数 reportMostRecentDtcOnStatusChange 的规范
此 SubFunction 参数通过 FIFO 队列缓存所有状态发生变更的 DTC（已通过 SubFunction 参数 onDTCStatusChange 设置与该 DTC 对应的事件）。当队列溢出时，应通过将对应于事件的响应中的 numberOfIdentifiedEvents 参数设置为 0xFF 通知客户端，以允许客户端同步其内部 DTC 状态（通过 ReadDTCInformation 服务（0x19）的带有 SubFunction 参数 reportDTCByStatusMask 的服务请求消息）。
通过 SubFunction 参数 reportMostRecentDtcOnStatusChange，服务器对 DTC 状态的 testFailed 位（bit 0）或 confirmedDTC 位（bit 3）的变化进行监控，并在变化发生时发送响应。
服务请求消息中的 eventTypeRecord 参数的长度为 1 字节，被允许的值为 0x0D 和 0x0E。所有其他的值均为保留值，不得使用。当 eventTypeRecord 参数的值为 0x0D 时，表示当 testFailed 位（bit 0）从 0 变为 1 的事件发生时，应发送对应于事件的响应，此响应消息由 ReadDTCInformation 服务（0x19）的带有 SubFunction 参数 reportMostRecentTestFailedDTC 的服务请求的肯定响应消息定义，其中 DTCAndStatusRecord 参数包含触发事件的 DTC 及其状态。当 eventTypeRecord 参数的值为 0x0E 时，表示当 confirmedDTC 位（bit 3）从 0 变为 1 的事件发生时，应发送对应于事件的响应，此响应消息由 ReadDTCInformation 服务（0x19）的带有 SubFunction 参数 reportMostRecentConfirmedDTC 的服务请求的肯定响应消息定义，其中 DTCAndStatusRecord 参数包含触发事件的 DTC 及其状态。
根据图 5，服务器将直接发送响应，而没有遵循服务器的一般响应行为。
此 SubFunction 参数未使用 serviceToRespondToRecord 参数，因为它由 eventTypeRecord 参数的第一个字节隐式地定义。该字节与 ReadDTCInformation 服务（0x19）的 SubFunction 参数对应。
此 SubFunction 参数允许连续地发送响应，以便更好地控制 MaxNumberOfStoredDTCStatusChangedEvents 队列的大小（网络上的最大突发流量的大小等于 MaxNumberOfStoredDTCStatusChangedEvents 队列的大小）。
10.9.2.2.4 请求消息的 SubFunction 参数 reportDTCRecordInformationOnDtcStatusChange 的规范
With subfunction reportDTCRecordInformationOnDtcStatusChange the server monitors changes of DTC status and sends a response on event message if a DTC status has changed that matches the DTC status mask. The send response on event message is fixed to SubFunctions of service ReadDTCInformation having the DTCMaskRecord as parameter of the request message. The DTCMaskRecord of that request message is replaced with the 3 byte DTC number of the DTC whose status change was detected.
This allows the server to report further information such as extended data records or snapshot records based on the DTC that changed the status. A use of a serviceToRespondToRecord with definition of diagnostic requests for ReadDTCInformation would not allow to read information for the DTC with the changed status as the DTCMaskRecord would be fixed within the serviceToRespondToRecord.
This allows to get within one response message the changed DTC, its status and, e.g. the detailed timestamp of the occurrence stored within a Snapshot- or ExtendedDataRecord.
通过子函数 reportDTCRecordInformationOnDtcStatusChange，服务器监控 DTC 状态的变化，并在 DTC 状态发生变化且与 DTC 状态掩码匹配时，发送事件消息响应。发送事件消息响应的子函数是 ReadDTCInformation 服务，其请求消息的参数为 DTCMaskRecord。该请求消息中的 DTCMaskRecord 会被替换为检测到状态变化的 DTC 的 3 字节 DTC 编号。
这使得服务器能够根据状态发生变化的 DTC 报告更多信息，例如扩展数据记录或快照记录。如果使用 serviceToRespondToRecord 并定义 ReadDTCInformation 的诊断请求，则无法读取状态发生变化的 DTC 的信息，因为 DTCMaskRecord 已被 serviceToRespondToRecord 固定。
这样，就可以在一条响应消息中获取状态发生变化的 DTC、其状态以及例如其他信息。快照记录或扩展数据记录中存储的事件详细时间戳。
10.9.2.2.5 请求消息的 SubFunction 参数 onChangeOfDataIdentifier 的规范
With subfunction onChangeOfDataIdentifier the server is allowed to poll the measurements in a fixed period of time and compare the content, therefore it is acceptable that the server might lose some changes and trigger less events than expected.
The eventTypeRecord sets the two byte DID value that shall be monitored for any change. Dynamically Defined DIDs in the range between 0xF200 - 0xF3FF are excluded.
NOTE:
Statically defined DIDs are allowed.
10.9.2.2.6 请求消息的 SubFunction 参数 onComparisonOfValues 的规范
Tables 141 to 143 specify the parameters for the request message with SubFunction onComparisonOfValues parameters in case of serviceToRespondToRecord specifying a comparison between read DIDs.
Table 142 specifies the comparison logic parameter definition.
Table 143 specifies the localization of value 16 bit bitfield parameter definition.
10.9.2.3 请求消息的数据参数的定义
Table 144 specifies the data-parameters of the request message.
10.9.3 肯定响应消息
10.9.3.1 肯定响应消息的定义
Table 145 specifies the positive response message for all SubFunctions but reportActivatedEvents.
Table 146 specifies the positive response message for SubFunction = reportActivatedEvents.
10.9.3.2 肯定响应消息的数据参数的定义
Table 147 specifies the data-parameters of the positive response message.
10.9.4 支持的否定响应码（NRC_）
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 148. The listed negative responses shall be used if the error scenario applies to the server.
10.9.5 消息流示例 ResponseOnEvent
10.9.5.1 假设
For the message flow examples it is assumed, that the eventWindowTime equal to 0816 defines an event window of 80 s (eventWindowTime * 10 s). The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
NOTE
The definition of the eventWindowTime is vehicle manufacturer specific, except for certain values as specified in B.2.
The following conditions apply to the shown message flow examples and flowcharts:
- Trigger signal: It is up to the vehicle manufacturer to define a specific trigger signal, which causes the client (external test equipment, OBD-Unit, diagnostic master, etc.) to start the ResponseOnEvent request message. This trigger signal could be enabled by an event as well as by a fixed timing schedule like a heartbeat-time (which should be greater than the eventWindowTime). Furthermore there could be a synchronous message (e.g. SYNCH-signal) on the data link used as trigger signal.
- Open event window: Receiving the ResponseOnEvent request message, the server shall evalaute the request. If the evaluation was positive, the server shall set up the event logic and shall send the initial positive response message of the ResponseOnEvent service. To activate the event logic the client shall request ResponseOnEvent SubFunction startResponseOnEvent. After the positive response the event logic is activated and the event window timer is running. It is up to the vehicle manufacturer to define the event window in detail, using the parameter eventWindowTime (e.g. timing window, ignition on/off window). In case of detecting the specified eventType (EART_) the server shall respond immediately with the response message corresponding to the serviceToRespondToRecord in the ResponseOnEvent request message.
- Close event window: It is recommended to close the event window of the server according to the parameter eventWindowTime. After this action, the server shall stop sending event driven diagnostic response messages. The same could either be reached by sending the ResponseOnEvent (ROE_) request message including the parameter stopResponseOnEvent or by power off.
10.9.5.2 示例 #1 - ResponseOnEvent（有限的事件窗口）
Table 149 specifies the setup of ResponseOnEvent request message flow example #1.
Table 150 specifies the ResponseOnEvent initial positive response message flow example #1.
The event logic is set up; now it shall be activated.
Table 151 specifies the start of the ResponseOnEvent request message flow example #1.
Table 152 specifies the ResponseOnEvent positive response message flow example #1.
In case the specified event occurs the server sends the response message according to the specified serviceToRespondToRecord.
Table 153 specifies the ReadDTCInformation positive response message flow example #1.
The message flow for the case where the client would request to report the currently active events in the server during the active event window will look as follows.
Table 154 specifies the ResponseOnEvent request number of active events message flow example #1.
Table 155 specifies the ResponseOnEvent reportActivatedEvents positive response message flow example #1.
If the specified event window time has expired the server shall send a final positive response.
Table 156 specifies the ResponseOnEvent final positive response message flow example #1
The following flowcharts show two different kind of server behaviour:
- No event occurs within the finite event window. In this case the server shall send the response of the ResponseOnEvent at the end of the event window.
- Multiple events (#1 to #n) within a finite event window. Each positive response of the serviceToRespondTo is related to an identified event (#1 to #n) and shall have the same service identifier (SId) but might have different content. At the end of the event_Window the server shall transmit a positive response message of the responseOnEvent service, which indicates the numberOfIdentifiedEvents.
Figure 16 depicts the finite event window - no event during active event window.
Figure 17 depicts the finite event window - multiple events during active event window.
10.9.5.3 示例 #2 - ResponseOnEvent（无限的事件窗口）
Table 157 specifies the ResponseOnEvent request message flow example #2.
Table 158 specifies the ResponseOnEvent initial positive response message flow example #2.
The event logic is set up, now it shall be activated.
Table 159 specifies the start of ResponseOnEvent request message flow example #2.
Table 161 specifies the ReadDTCInformation positive response message flow example #2.
The following flowcharts show two different kind of server behaviour:
- No event occurs within the infinite event window.
- Multiple events (#1 to #n) within a infinite event window. Each positive response of the serviceToRespondTo is related to an identified event (#1 to #n) and shall have the same service identifier (SI) but might have different content.
Figure 18 depicts the infinite event window - Nn event during active event window.
Figure 19 depicts the infinite event window - multiple events during active event window.
10.9.5.4 Example #3 - ResponseOnEvent (infinite event window) - SubFunction parameter "onComparisonOfValues"
This example only explains the utilisation of SubFunction parameter "onComparisonOfValues" assuming that the communication behaviour of the ROE service described in Example #1 and Example #2 has not changed. Therefore this example does not describe the complete message flow. Instead, only the event window setup request message and the positive response message to the occurring event is shown and explained. Start and Stop request messages as well as the different response messages are already described in the examples above. The following conditions apply:
- a service 0x22 - ReadDataByIdentifier is chosen as the serviceToRespondTo,
- a the dataIdentifier 0x0104 includes the measurement value which is to be compared at data byte#11 and #12 (this measurement value may also be read by utilising service 0x22),
- a an event occurs if the measurement value (MV) is higher than the so called comparison parameter (CP) therefore the operator value (see description below) is chosen as 0x01 - "MV > CP",
- a as hysteresis value 0x0A - 10 % is chosen,
- a as eventWindowTime the value 0x02 - "infinite" is chosen,
- a as doNotStoreEvent (eventType SubFunction bit 6) the value 0b is chosen,
- a in any case a response is requested.
- Byte#4 to 5: dataIdentifier 0x0104
- Byte#6 to 7: Localisation of reading and definition of reading type.
EXAMPLE 1 If the reading is in the 11th byte of the data record, the following applies:
- 11*8 = 88 dec = 000101 1000b Bit#10 - Bit#14: length in bits - 1.
- With 5 bits, there is a maximum size of 32 bits = "long".
EXAMPLE 2 For a "word", the length is therefore 15 dec = 0 1111b Bit#15: Sign entry: 1 = signed, 0 = unsigned.
EXAMPLE 3 Total assignment would be:
- 1011 1100 0101 1000b = 0xBC58 thus Byte#6 contains 0xBC, Byte#7 contains 0x58
- Byte#8: Comparison operation (operator)
EXAMPLE 4 operator MV > CP = 0x01
- Byte#9 -12: Comparison parameters due to the 4 byte length, all data formats from 'Bit' through 'Long' type can be transmitted.
EXAMPLE 5 If comparison value is 5 242 = 0x0000 147A
- Byte#9 = 0x00, Byte#10 = 0x00, Byte#11 = 0x14 and Byte#12 = 0x7A
- Byte#13: Hysteresis value (specified as percentage of comparison parameter). The value is specified directly. It only applies to the operators "<" and ">". In case of zero as comparison value, the hysteresis value shall be defined as an absolute value.
EXAMPLE 6 Hysteresis value 10 % = 0x0A.
Table 162 specifies the ResponseOnEvent request message example #3.
NOTE
Response message and subsequent initialisation sequence is not shown.
The server reacts if the measurement value is higher than 5 242d after a successful event window set up and activation of the ROE mechanism. The specified event occurs and the server sends the following message.
Table 163 specifies the ReadDataByIdentifier positive response message example #3.
A further event occurs not before the measurement value is at least once below 90 % of the comparison parameter value. This behaviour is specified by the hysteresis value. If this condition is fulfilled and the measurement value is again higher than the comparison value, a new event occurs and a new ReadDataByIdentifier response message is sent by the server.
10.9.5.5 Example #4 - ResponseOnEvent request message (reportMostRecentDtcOnStatusChange)
This example explains the request message for a ResponseOnEvent setup requesting the most recent test failed DTC. Table 164 specifies the ResponseOnEvent request message flow example #4.
 |
Table 164 — ResponseOnEvent request message flow example #4 |
10.9.5.6 Example #5 - ResponseOnEvent request message (reportDTCRecordInformationOnDtcStatusChange)
This example explains the request message for a ResponseOnEvent setup requesting an extended data record 0x12 for all DTC that have the confirmedDTC (Bit 3) set. Table 166 specifies the ResponseOnEvent request message flow example #4.
After setting up the response on event in this example, the server starts to monitor Bit 3 DTC status changes. If the DTC 0x12A104 is confirmed, the server sends the response on event, by sending the result of the service 0x19 0x06 0x12 0xA1 0x04 0x12 and sends a positive response message. Table 167 specifies the ReadDTCInformation positive response message flow example #1.
10.10 LinkControl (0x87) service
10.10.1 Service description
The LinkControl service is used to control the communication between the client and the server(s) in order to gain bus bandwidth for diagnostic purposes (e.g. programming). This service optionally applies to those data link layers, which provides the capability to reconfigure its communication parameter (e.g. change the baudrate on CAN or reconfigure a FlexRay cycle design) during a non-default diagnostic session.
NOTE
Further details on the application and usage of this service on a certain data link layer can be found in the individual data link layer specific diagnostic services implementation UDSonXYZ 'data link' specification.
This service is used to transition the data link layer into a certain state which allows utilizing higher diagnostic bandwidth most likely for programming purposes. To overcome functional communication constraints (e.g. the baudrate shall be transitioned in multiple servers at the same time) the transition itself is split into two steps:
- Step #1: The client verifies if the transition can be performed and informs the server(s) about the mode transition mechanism to be used. Each server shall respond positively (suppressPosRspMsgIndicationBit = FALSE) before the client performs step #2. This step actually does not perform the mode transition.
- Step #2: The client actually requests the mode transition (e.g. higher baudrate). This step shall only be requested if step #1 has been performed successfully. In case of functional communication it is recommended that there shall not be any response from a server when the mode transition is performed (suppressPosRspMsgIndicationBit = TRUE), because one server might already have been transitioned to the new mode while others are still in progress.
The linkControlType parameter in the request message in conjunction with the conditional linkControlModeIdentifier/linkRecord parameter provides a mechanism to transition with either a predefined mode transition parameter or a specifically defined mode transition parameter.
This service is tied to a non-defaultSession. A session layer timer timeout will transition the server(s) back to its (their) normal mode of operation. The same applies in case an ECUReset service (0x11) is performed. Once a data link mode transition has taken place, any additional non-defaultSession request(s) shall not cause a retransition into the default mode of operation (e.g. during a programming session).
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
10.10.2 Request message
10.10.2.1Request message definition
Table 168 specifies the request message (linkControlType = verifyModeTransitionWithFixedParameter).
Table 169 specifies the request message (linkControlType = verifyModeTransitionWithSpecificParameter).
Table 170 specifies the request message (linkControlType = transitionMode).
10.10.2.2Request message SubFunction parameter $Level (LEV_) definition
The SubFunction parameter linkControlType is used by the LinkControl request message to describe the action to be performed in the server (suppressPosRspMsgIndicationBit (bit 7) not shown in table below).
Table 171 specifies the request message SubFunction parameters.
10.10.2.3Request message data-parameter definition
Table 172 specifies the data-parameters of the request message.
10.10.3 Positive response message
10.10.3.1Positive response message definition
Table 173 specifies the positive response message.
10.10.3.2Positive response message data-parameter definition
Table 174 specifies the data-parameter of the positive response message.
10.10.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 175. The listed negative responses shall be used if the error scenario applies to the server.
10.10.5 Message flow example(s) LinkControl
10.10.5.1 Example #1 - Transition baudrate to fixed baudrate (PC baudrate 115,2 kBit/s)
10.10.5.1.1 Step#1: Verify if all criteria are met for a baudrate switch
Table 176 specifies the LinkControl request message flow example #1 - step #1.
Table 177 specifies the LinkControl positive response message flow example #1 - step #1.
10.10.5.1.2Step#2: Transition the baudrate
Table 178 specifies the LinkControl request message flow example #1 - step #2.
There is no response from the server(s). The client and the server(s) shall transition the baudrate of
their communication link.
10.10.5.2Example #2 - Transition baudrate to specific baudrate (150 kBit/s)
10.10.5.2.1Step#1: Verify if all criteria are met for a baudrate switch
Table 179 specifies the LinkControl request message flow example #2 - step #1.
Table 180 specifies the LinkControl positive response message flow example #2 - step #1.
10.10.5.2.2Step#2: Transition the baudrate
Table 181 specifies the LinkControl request message flow example #2 - step #2.
There is no response from the server(s). The client and the server(s) shall transition the baudrate of
their communication link.
10.10.5.3Example #3 - Transition FlexRay cycle design to 'programming'
The following example reflects a scenario, where a FlexRay network cycle design is transitioned into an
optimized 'programming' mode (e.g. utilizing an enhanced dynamic segment for programming).
10.10.5.3.1Step#1: Verify if all criteria are met for a scheduler switch
Table 182 specifies the LinkControl request message flow example #3 - step #1.
Table 183 specifies the LinkControl positive response message flow example #3 - step #1.
10.10.5.3.2Step#2: Transition to programming scheduler
Table 184 specifies the LinkControl request message flow example #3 - step #2.
There is no response from the server(s). The client and the server(s) shall transition the cycle design of
the FlexRay communication link.
11 数据传输功能单元
11.1 概述
表 185 指定了数据传输功能单元。
11.2 ReadDataByIdentifier (0x22) 服务
11.2.1 服务描述
ReadDataByIdentifier 服务允许客户端向服务器请求一个或多个由 dataIdentifier 标识的数据的记录值。
客户端发送的请求消息包含一个或多个 dataIdentifier 参数（2 字节），被用于标识由服务器维护的数据的记录值（有关对有效的 dataIdentifier 参数的值的定义，请参见 C.1）。dataRecord 参数的格式和定义应由车辆制造商或系统供应商决定，并且可以包含模拟输入/输出信号、数字输入/输出信号、内部数据以及系统状态信息（如服务器支持）。
根据车辆制造商和系统供应商提供的定义，服务器可能会限制并发请求中的 dataIdentifier 参数的最大数量。
在接收到 ReadDataByIdentifier 服务的请求消息后，服务器应访问由 dataIdentifier 参数标识的数据的记录值，并在对本次请求消息的肯定响应消息中通过 dataRecord 参数传输这些值。请求消息可以包含（多个）重复的 dataIdentifier 参数。服务器应将每个 dataIdentifier 参数视为一个单独的参数，并根据请求中该 dataIdentifier 参数（相同）出现的次数在响应中（多次）填充与其对应的响应数据。
重要
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
11.2.2 请求消息
11.2.2.1 请求消息的定义
表 186 指定了请求消息的定义。
11.2.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
此服务不支持请求消息的 SubFunction 参数。
11.2.2.3 请求消息的数据参数的定义
表 187 指定了请求消息的数据参数的定义。
11.2.3 肯定响应消息
11.2.3.1 肯定响应消息的定义
表 188 指定了肯定响应消息的定义。
11.2.3.2 肯定响应消息的数据参数的定义
表 189 指定了肯定响应消息的数据参数的定义。
11.2.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 190 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
流程如图 20 所示。
11.2.5 消息流示例 ReadDataByIdentifier
11.2.5.1 假设
本子条款规定了（示例中）执行 ReadDataByIdentifier 服务所需满足的条件。客户端可以随时对由 dataIdentifier 标识的数据进行请求，而无需考虑服务器的状态。
以下示例中的 dataIdentifier 参数专门针对动力总成设备（例如，发动机控制模块）。有关与排放相关的系统的公认术语/定义/缩略语的更多详细信息，请参阅 ISO 15031-2 [16]。
在第一个示例中，将对一个由 dataIdentifier 标识的数据（2 字节）进行读取（其中 dataIdentifier 0xF190 标识的数据为 VIN 码（车辆识别码））。
在第二个示例中，将对多个由 dataIdentifier 标识的数据（2 字节）进行读取（其中 dataIdentifier 0x010A 标识的数据为发动机冷却液温度、节气门位置、发动机转速、歧管绝对压力、质量空气流量、车速传感器、气压、计算负载值、怠速空气控制和加速踏板位置，而 dataIdentifier 0x0110 标识的数据为电池正极电压）。
11.2.5.2 示例 #1 - 读取单个 dataIdentifier 0xF190（VIN 码）
表 191 指定了 ReadDataByIdentifier 服务的请求消息的消息流的示例 #1。
表 192 指定了 ReadDataByIdentifier 服务的肯定响应消息的消息流的示例 #1。
11.2.5.3 示例 #2 - 读取多个 dataIdentifier 0x010A、0x0110
表 193 指定了 ReadDataByIdentifier 服务的请求消息的消息流的示例 #2。
表 194 指定了 ReadDataByIdentifier 服务的肯定响应消息的消息流的示例 #2。
11.3 ReadMemoryByAddress (0x23) service
11.3.1 Service description
The ReadMemoryByAddress service allows the client to request memory data from the server via
provided starting address and size of memory to be read.
The ReadMemoryByAddress request message is used to request memory data from the server
identified by the parameter memoryAddress and memorySize. The number of bytes used for the
memoryAddress and memorySize parameter is defined by addressAndLengthFormatIdentifier (low and
high nibble).
It is also possible to use a fixed addressAndLengthFormatIdentifier and unused bytes within the
memoryAddress or memorySize parameter are padded with the value 0x00 in the higher range address
locations.
In case of overlapping memory areas it is possible to use an additional memoryAddress byte as a
memory identifier (e.g. use of internal and external flash).
The server sends data record values via the ReadMemoryByAddress positive response message. The
format and definition of the dataRecord parameter shall be vehicle manufacturer specific. The
dataRecord parameter may include analog input and output signals, digital input and output signals,
internal data and system status information if supported by the server.
IMPORTANT
The server and the client shall meet the request and response message behaviour as
specified in 8.7.
11.3.2 Request message
11.3.2.1 Request message definition
Table 195 specifies the request message.
11.3.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
11.3.2.3 Request message data-parameter definition
Table 196 specifies the data-parameters of the request message.
11.3.3 Positive response message
11.3.3.1 Positive response message definition
Table 197 specifies the positive response message.
11.3.3.2 Positive response message data-parameter definition
Table 198 specifies the data parameter of the positive response message.
11.3.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 199. The listed negative responses
shall be used if the error scenario applies to the server.
 |
Table 199 — Supported negative response codes |
The evaluation sequence is documented in Figure 21.
11.3.5 Message flow example ReadMemoryByAddress
11.3.5.1 Assumptions
This subclause specifies the conditions to be fulfilled for the example to perform a
ReadMemoryByAddress service. The service in this example is not limited by any restriction of the
server.
11.3.5.2 Example #1: ReadMemoryByAddress - 4-byte (32-bit) addressing
The client reads 259 data bytes from the server's memory starting at memory address 0x20481392.
Table 200 specifies the ReadMemoryByAddress request message flow example #1.
Table 201 specifies the ReadMemoryByAddress positive response message flow example #1.
11.3.5.3 Example #2: ReadMemoryByAddress - 2-byte (16-bit) addressing.
The client reads five data bytes from the server's memory starting at memory address 0x4813.
Table 202 specifies the ReadMemoryByAddress request message flow example #2.
Table 203 specifies the ReadMemoryByAddress positive response message flow example #2.
11.3.5.4 Example #3: ReadMemoryByAddress, 3-byte (24-bit) addressing
The client reads three data bytes from the server's external RAM cells starting at memory address 0x204813.
Table 204 specifies the ReadMemoryByAddress request message flow example #3.
Table 205 specifies the ReadMemoryByAddress first positive response message, example #3.
11.4 ReadScalingDataByIdentifier (0x24) service
11.4.1 Service description
The ReadScalingDataByIdentifier service allows the client to request scaling data record information
from the server identified by a dataIdentifier.
The client request message contains one dataIdentifier value that identifies data record(s) maintained
by the server (see C.1 for allowed dataIdentifier values). The format and definition of the dataRecord
shall be vehicle manufacturer specific, and may include analog input and output signals, digital input
and output signals, internal data, and system status information if supported by the server.
Upon receiving a ReadScalingDataByIdentifier request, the server shall access the scaling information
associated with the specified dataIdentifier parameter and transmit the scaling information values in
one ReadScalingDataByIdentifier positive response.
IMPORTANT
The server and the client shall meet the request and response message behaviour as
specified in 8.7.
11.4.2 Request message
11.4.2.1 Request message definition
Table 206 specifies the request message.
11.4.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
11.4.2.3 Request message data-parameter definition
Table 207 specifies the data-parameter of the request message.
11.4.3 Positive response message
11.4.3.1 Positive response message definition
Table 208 specifies the positive response message.
11.4.3.2 Positive response message data-parameter definition
Table 209 specifies the data-parameters of the positive response message.
 |
Table 209 — Response message data-parameter definition |
11.4.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 210. The listed negative responses
shall be used if the error scenario applies to the server.
The evaluation sequence is documented in Figure 22.
11.4.5 Message flow example ReadScalingDataByIdentifier
11.4.5.1 Assumptions
This subclause specifies the conditions to be fulfilled for the example to perform a
ReadScalingDataByIdentifier service. The client may request dataIdentifier scaling data at any time
independent of the status of the server.
The first example reads the scaling information associated with the two byte dataIdentifier 0xF190,
which contains a single piece of information (17 character VIN number).
The second example demonstrates the use of a formula and unit identifier for specifiying a data variable
in a server.
The third example illustrates the use of readScalingDataByIdentifier to return the supported bits
(validity mask) for a bit mapped dataIdentifier that is reported without the mask through the use of
readDataByIdenditfier.
11.4.5.2 Example #1: readScalingDataByIdentifier wth dataIdentifier 0xF190 (VIN number)
Table 211 specifies the ReadScalingDataByIdentifier request message flow example #1.
Table 212 specifies the ReadScalingDataByIdentifier positive response message flow example #1.
11.4.5.3 Example #2: readScalingDataByIdentifier wth dataIdentifier 010516 (Vehicle Speed)
Table 213 specifies the ReadScalingDataByIdentifier request message flow example #2.
Table 214 specifies the ReadScalingDataByIdentifier positive response message flow example #2.
Using the information contained in C.2 for decoding the scalingBytes, constants (C0, C1) and units, the
data variable of vehicle speed is calculated using the following formula:
Vehicle Speed = (0,75 * x + 30) km/h
where 'x' is the actual data stored in the server and is identified by dataIdentifier 0x0105.
11.4.5.4 Example #3: readScalingDataByIdentifier wth dataIdentifier 0x0967
This example shows how a client could determine which bits are supported for a dataIdentifier in a
server that is formatted as a bit mapped record reported without a validity mask.
The example dataIdentifier (0x0967) is defined in Table 215.
Table 216 specifies the ReadScalingDataByIdentifier request message flow example #3.
Table 217 specifies the ReadScalingDataByIdentifier positive response message flow example #3.
The above example makes the assumption that the only bits supported (i.e. that contain information)
for this dataIdentifier in the server are byte#1, bits 1 and 0, and byte#2, bits 6, 1, and 0.
11.5 ReadDataByPeriodicIdentifier (0x2A) service
11.5.1 Service description
The ReadDataByPeriodicIdentifier service allows the client to request the periodic transmission of data
record values from the server identified by one or more periodicDataIdentifiers.
The client request message contains one or more 1-byte periodicDataIdentifier values that identify data
record(s) maintained by the server. The periodicDataIdentifier represents the low byte of a
dataIdentifier out of the dataIdentifier range reserved for this service (0xF2XX, see C.1 for allowed
periodicDataIdentifier values), e.g. the periodicDataIdentifier 0xE3 used in this service is the
dataIdentifier 0xF2E3.
The format and definition of the dataRecord shall be vehicle manufacturer specific, and may include
analog input and output signals, digital input and output signals, internal data, and system status
information if supported by the server.
Upon receiving a ReadDataByPeriodicIdentifier request other than stopSending the server shall check
whether the conditions are correct to execute the service.
A periodicDataIdentifier shall only be supported with a single transmissionMode at a given time. A
change to the schedule of a periodicDataIdentifier shall be performed on reception of a request message
with the transmissionMode parameter set to a new schedule for the same periodicDataIdentifier.
Multiple schedules for different periodicDataIdentifiers shall be supported upon vehicle manufacturer's
request.
IMPORTANT
If the conditions are correct then the server shall transmit a positive response message,
including only the service identifier. The server shall never transmit a negative response message once
it has accepted the initial request message by responding positively.
Following the initial positive response message, the server shall access the data elements of the records
specified by the periodicDataIdentifier parameter(s) and transmit their value in separate periodic data
response messages for each periodicDataIdentifier containing the associated dataRecord parameters.
The separate periodic data response messages defined to transmit the periodicDataIdentifier data to
the client following the initial positive response message shall include the periodicDataIdentifier and
the data of the periodicDataIdentifier, but not the positive response service identifier. The mapping of
the periodic response message onto certain data link layers is described in the appropriate
implementation specifications of ISO 14229.
The documented periodic rate for a specific transmissionMode is defined as the time between any two
consecutive response messages with the same periodicDataIdentifier, when only a single
periodicDataIdentifier is scheduled. If multiple periodicDataIdentifiers are scheduled concurrently, the
effective period between the same periodicDataIdentifier will vary based upon the following design
parameters:
- SchedulerRate: the call rate of the periodic scheduler.
- NumPeriodicAddr: the number of available protocol specific periodic data response message address information IDs allocated per scheduler call (e.g. CAN identifier on CAN).
- MaxNumPDID: the number of periodicDataIdentifiers that can be defined in parallel to be transmitted concurrently.
These parameter values will impact the extent of how much the effective period between the same
periodicDataIdentifier will increase if multiple periodicDataIdentifers are transmitted concurrently.
Therefore, all of the previously mentioned design parameters shall be specified by the vehicle
manufacturer. Each time the periodic scheduler is called it shall determine if any
periodicDataIdentifiers are ready to transmit.
It is useful to define the following parameters:
- NumPDID: the current number of periodicDataIdentifiers scheduled to be transmitted concurrently.
- PeriodicRateCount: the number of SchedulerRate intervals within the periodic rate.
NOTE
The periodic rate is an integer multiple of the periodic scheduler call rate.
Two scheduling implementation types are defined that specify how periodicDataIdentifiers are
transmitted for a transmissionMode based upon the above parameters. It is vehicle manufacturer
specific which implementation is used.
Both scheduler types use a PeriodicRateCounter, which is initially loaded with the PeriodicRateCount
and decrements every time the scheduler is called. When the PeriodicRateCounter reaches zero the
periodic rate has expired and is reloaded.
- Scheduler type #1: When the PeriodicRateCounter reaches zero then transmission of all scheduled PDIDs begins, starting with the first in the list of scheduled PDIDs. NumPeriodicAddr PDIDs will be transmitted each scheduler call, using the addresses that are available. This continues until all NumPDID scheduled PDIDs have been transmitted, and begins again the next time PeriodicRateCounter reaches zero.
- Scheduler type #2: When the PeriodicRateCounter reaches zero then the next scheduled NumPeriodicAddr PDIDs are transmitted. The PDIDs are only transmitted at the scheduler call when PeriodicRateCounter reaches zero, and not at other scheduler calls.
Scheduler type #1 can result in “aliasing” when there are too many PDIDs to transmit within the
periodic rate. This occurs when NumPDID > PeriodicRateCount * NumPeriodicAddr. If aliasing occurs,
then the PDIDs are continually transmitted at the scheduler rate in their scheduled order. The ECU shall
not drop any PDIDs.
The following is a pseudo-code specification of a simple scheduler for a single transmission rate that
supports both scheduler types. This is just for guidance, actual implementations may vary:
// Initialization
PeriodicRateCount = PeriodicRate/SchedulerRate;
PeriodicRateCounter = PeriodicRateCount;
PDIDnext = 0; // Index into list if active PDIDs to be transmitted.
// Determine, if scheduler type #1 has an alias situation
Alias = 0;
IF (SchedulerType == 1)
IF (Ceiling(NumPDID/NumPeriodicAddr) > PeriodicRateCount)
Alias = 1;
ENDIF;
ENDIF;
START periodic scheduler;
// Periodic scheduler called at the ScheduleRate
SchedulerCall()
PeriodicRateCounter = PeriodicRateCounter - 1;
// If scheduler type 1 and not all PDIDs in list have been transmitted, OR
// PeriodicRateCounter indicates a new Periodic Rate is to begin, OR
// scheduler type 1 aliasing
IF (((SchedulerType == 1) && (PDIDnext != 0)) ||
(PeriodicRateCounter == 0) || (Alias)
)
// Transmit the next set of NumPeriodicAddr PDIDs from the list of active PDIDs
i = 0;
Periodic_Address = Initial Periodic_Address;
// Loop and send the next set of PDIDs based on the Number of addresses available.
WHILE(i < NumPeriodicAddr)
// Fill in data and Periodic_Address of next PDID to transmit
PDID_MSG.data[] = PDID[PDIDnext] data;
PDID_MSG.UUDTaddr = Periodic_Address;
SEND PDID_MSG;
PDIDnext = (PDIDnext + 1) % NumPDID;
// Don't send duplicate PDID(s) for scheduler type 1, unless an alias situation
IF (SchedulerType == 1)
IF ((PDIDnext == 0) && (!Alias))
EXITWHILE;
ENDIF;
ENDIF;
// Use next periodic address
Periodic_Address = Periodic_Address + 1;
i = i + 1;
ENDWHILE;
ENDIF;
// Has the Periodic time expired?
IF (PeriodicRateCounter == 0)
// Yes, reload the periodic rate count for the next transmission rate period
PeriodicRateCounter = PeriodicRateCount;
ENDIF;
Example, two distinct ECU implementations may both support a fast transmissionMode with a periodic rate of 10 ms and a single unique periodic data response message address information ID. If the first implementation calls the periodic scheduler every 10 ms, the time between the same periodicDataIdentifier would increase to 20 ms when two periodicDataIdentifiers are scheduled and would increase to 40 ms when four periodicDataIdentifiers are scheduled. If the second implementation calls the periodic scheduler every 5 ms, the time between the same periodicDataIdentifier would remain at 10 ms when two periodicDataIdentifiers are scheduled and would increase to 20 ms when four periodicDataIdentifiers are scheduled. See more examples in 11.6.5.
Upon receiving a ReadDataByPeriodicIdentifier request including the transmissionMode stopSending the server shall either stop the periodic transmission of the periodicDataIdentifier(s) contained in the request message or stop the transmission of all periodicDataIdentifier if no specific one is specified in the request message. The response message to this transmissionMode only contains the service identifier.
The server may limit the number of periodicDataIdentifiers that can be simultaneously supported as agreed upon by the vehicle manufacturer and system supplier. Exceeding the maximum number of periodicDataIdentifier that can be simultaneously supported shall result in a single negative response and none of the periodicDataIdentifiers in that request shall be scheduled. Repetition of the same periodicDataIdentifier in a single request message is not allowed and the server shall ignore them all except one periodicDataIdentifer if the client breaks this rule.
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
11.5.2 Request message
11.5.2.1 Request message definition
Table 218 specifies the request message.
11.5.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
11.5.2.3 Request message data-parameter definition
Table 219 specifies the data-parameters of the request message.
11.5.3 Positive response message
11.5.3.1 Positive response message definition
There shall be a distinction between the initial positive response message, which indicates that the server accepts the service and subsequent periodic data response messages, which include periodicDataIdentifier data.
Table 220 specifies the initial positive response message to be transmitted by the server when it accepts the request.
The data of a periodicDataIdentifier is transmitted periodically (with updated data) at a rate determined by the transmissionMode parameter of the request.
After the initial positive response, for each supported periodicDataIdentifier in the request the server shall start sending a single periodic data response message as defined below.
Table 221 specifies the periodic data response message data definition.
11.5.3.2 Positive response message data-parameter definition
This service does not support response message data-parameters in the positive response message.
Table 222 specifies the periodic message data-parameters of the defined periodic data response message.
11.5.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 223. The listed negative responses shall be used if the error scenario applies to the server.
The evaluation sequence is documented in Figure 23.
11.5.5 Message flow example ReadDataByPeriodicIdentifier
11.5.5.1 General assumptions
The examples below show how the ReadDataByPeriodicIdentifer behaves. The client may request a periodicDataIdentifier data at any time independent of the status of the server.
The periodicDataIdentifier examples below are specific to a powertrain device (e.g. engine control module). Refer to ISO 15031-2[16] for further details regarding accepted terms/definitions/acronyms for emission related systems.
11.5.5.2 Example #1 - Read multiple periodicDataIdentifiers 0xE3 and 0x24 at medium rate
11.5.5.2.1 Assumptions
The example demonstrates requesting of multiple dataIdentifiers with a single request (where periodicDataIdentifier 0xE3 (= dataIdentifier 0xF2E3) contains engine coolant temperature, throttle position, engine speed, vehicle speed sensor, and periodicDataIdentifier 0x24 (= dataIdentifier 0xF224) contains battery positive voltage, manifold absolute pressure, mass air flow, vehicle barometric pressure, and calculated load value).
The client requests the transmission at medium rate and after a certain amount of time retrieving the periodic data the client stops the transmission of the periodicDataIdentifier 0xE3 only.
11.5.5.2.2 Step #1: Request periodic transmission of the periodicDataIdentifiers
Table 224 specifies the ReadDataByPeriodicIdentifier request message flow example - step #1.
Table 225 specifies the ReadDataByPeriodicIdentifier initial positive response message flow example - step #1.
Table 226 specifies the ReadDataByPeriodicIdentifier subsequent positive response message #1 flows - step #1.
 |
Table 226 — ReadDataByPeriodicIdentifier subsequent positive response message #1 flows – step #1 |
Table 227 specifies the ReadDataByPeriodicIdentifier subsequent positive response message #2 flows –
step #1.
 |
Table 227 — ReadDataByPeriodicIdentifier subsequent positive response message #2 flows – step #1 |
The server transmits the above shown subsequent response messages at the medium rate as applicable
to the server.
11.5.5.2.3 Step #2: Stop the transmission of the periodicDataIdentifiers
Table 228 specifies the ReadDataByIdentifier request message flow example – step #2.
 |
Table 228 — ReadDataByIdentifier request message flow example – step #2 |
Table 229 specifies the ReadDataByIdentifier positive response message flow example – step #2.
 |
Table 229 — ReadDataByIdentifier positive response message flow example – step #2 |
The server stops the transmission of the periodicDataIdentifier 0xE3 only. The periodicDataIdentifier 0x24 is still transmitted at the server medium rate.
11.5.5.3 Example #2 - Graphical and tabular example of ReadDataByPeriodicIdentifier service periodic schedule rates
11.5.5.3.1 ReadDataByPeriodicIdentifier example overview
This subclause contains an example of scheduled periodic data, with both a graphical and tabular
example of the ReadDataByPeriodicIdentifier (0x2A) service.
The example contains a graphical depiction of what messages (request/response) are transmitted
between the client and the server application, followed by a table which shows a possible
implementation of a server periodic scheduler, its variables and how they change each time the
background function that checks the periodic scheduler is executed.
In the examples below, the following implementation is defined:
- The fast periodic rate is 25 ms and the medium periodic rate is 300 ms.
- The periodic scheduler is checked every 12,5 ms, which means that the periodic scheduler background function is called (polled) with this period. Each time the background periodic scheduler is called it will traverse the scheduler entries until a single periodic identifier is sent, or until all identifiers in the scheduler have been checked and none are ready to transmit. In the example implementation the “periodic scheduler transmit index” variable in the tables is the first index checked when traversing the scheduler to see if an identifier is ready for transmit.
- The maximum number of periodicDataIdentifiers which may be scheduled concurrently is 4.
- One unique periodic data response message address information ID is allocated.
Since the periodic scheduler poll-rate is 12,5 ms, the fast rate loop counter would be set to 2 (this value
is based on the scheduled rate (25 ms) divided by the periodic scheduler poll-rate (12,5 ms) or
25/12,5) each time a fast rate periodicDataIdentifier is sent and the medium rate loop counter would be
reset to 24 (scheduled rate divided by the periodic scheduler poll-rate or 300/12,5) each time a
medium rate periodicDataIdentifier is sent.
11.5.5.3.2 Example #2 – Read multiple periodicDataIdentifiers 0xE3 and 0x24 at medium rate
At t = 0,0 ms, the client begins sending the request to schedule 2 periodicDataIdentifiers (0xF2E3 and 0xF224) at the medium rate (300 ms). For the purposes of this example, the server receives the req
 |
Figure 24 — Example #2 – periodicDataIdentifiers scheduled at medium rate |
Table 230 and Table 231 show a possible implementation of the periodic scheduler in the server. The
table contains the periodic scheduler variables and how they change each time the background function
that checks the periodic scheduler is executed.
 |
Table 230 — Example #2: Periodic scheduler table for scheduler type 1 |
 |
Table 231 — Example #2: Periodic scheduler table for scheduler type 2 |
11.5.5.4 Example #3 - Graphical and tabular example of ReadDataByPeriodicIdentifier service periodic schedule rates
11.5.5.4.1 ReadDataByPeriodicIdentifier example overview
This subclause contains an example of scheduled periodic data with both a graphical and tabular
example of the ReadDataByPeriodicIdentifier (0x2A) service.
The example is based on the example given in 11.5.5.3. The example contains a graphical depiction of
what messages (request/response) are transmitted between the client and the server application,
followed by a table which shows a possible implementation of a server periodic scheduler, its variables
and how they change each time the background function that checks the periodic scheduler is executed.
11.5.5.4.2 Read multiple periodicDataIdentifiers at different periodic rates
In this example, three periodicDataIdentifiers (for simplicity 0x01, 0x02, 0x03) are scheduled at the fast
periodic rate (25 ms) and then another request is sent for a single periodicDataIdentifier (0x04) to be
scheduled at the medium periodic rate (300 ms). For the purposes of this example, the server receives
the first ReadDataByPeriodicIdentifier request (1), sends a positive response (2) without any periodic
data and executes the periodic scheduler background function for the first time t = 25,0 ms (3). When
the second ReadDataByPeriodicIdentifier request (5) is received, the server sends a positive response
(7) without any periodic data and starts executing the periodic scheduler background function at
t = 62,5 ms (8) at a scheduled medium rate of 300 ms.
Figure 25 depicts the example #3 – periodicDataIdentifiers scheduled at fast and medium rate.
 |
Figure 25 — Example #3 – periodicDataIdentifiers scheduled at fast and medium rate |
Table 232 shows a possible implementation of the periodic scheduler in the server. The table contains
the periodic scheduler variables and how they change each time the background function that checks
the periodic scheduler is executed. Table 232 also shows aliasing for the three fast rate
periodicDataIdentifiers.
 |
Table 232 — Example #3: Periodic scheduler table for scheduler type 1 |
Table 233 modifies example 3 to add a second medium rate periodicDataIdentifiers (0516) for the
example of a scheduler type 2. The example implementation is simplified by using separate fast and
medium rate transmit indexes.
 |
Table 233 — Example #3: Periodic scheduler table for scheduler type 2 |
11.5.5.5 Example #4 - Tabular example of ReadDataByPeriodicIdentifier service periodic schedule rates
This subclause contains an example of scheduled periodic data with a tabular example of the
ReadDataByPeriodicIdentifier (0x2A) service. The example contains a table which shows a possible
implementation of a server periodic scheduler, its variables and how they change each time the
background function that checks the periodic scheduler is executed.
In the examples below, the following information is defined:
- The fast periodic rate is 10 ms.
- The periodic scheduler is checked every 10 ms, which means that the periodic scheduler background function is called (polled) with this period.
- The maximum number of periodicDataIdentifiers, which may be scheduled concurrently, is 16.
- Two unique periodic data response message address information IDs are allocated.
Since the periodic scheduler poll-rate is 10 ms, the fast rate loop counter would be set to 1 (this value is
based on the scheduled rate (10 ms) divided by the periodic scheduler poll-rate (10 ms)) each time a
fast rate periodicDataIdentifier is sent.
At t = 0,0 ms, the client begins sending the request to schedule 2 periodicDataIdentifier (for simplicity 0x01, 0x02) at the fast periodic rate (10 ms). For the purposes of this example, the server receives the
request and executes the periodic scheduler background function the first time t = 10 ms.
 |
Table 234 — Example #4: Periodic scheduler table |
11.5.5.6 Example #5 - Tabular example of ReadDataByPeriodicIdentifier service periodic schedule rates
This subclause uses the same assumptions as in 11.5.5.5. In this example, more periodicDataIdentifiers
than unique periodic data response message address information IDs in the response message set are
requested.
At t = 0,0 ms, the client begins sending the request to schedule 3 periodicDataIdentifier (for simplicity 0x01, 0x02, 0x03) at the fast periodic rate (10 ms). For the purposes of this example, the server receives
the request and executes the periodic scheduler background function the first time t = 10 ms.
 |
Table 235 — Example #5: Periodic scheduler table |
11.6 DynamicallyDefineDataIdentifier (0x2C) service
11.6.1 Service description
The DynamicallyDefineDataIdentifier service allows the client to dynamically define in a server a data
identifier that can be read via the ReadDataByIdentifier service at a later time.
The intention of this service is to provide the client with the ability to group one or more data elements
into a data superset that can be requested en masse via the ReadDataByIdentifier or
ReadDataByPeriodicIdentifier service. The data elements to be grouped together can either be
referenced by:
- a source data identifier, a position and size or
- a memory address and a memory length, or
- a combination of the two methods listed above using multiple requests to define the single data element. The dynamically defined dataIdentifier will then contain a concatenation of the dataparameter definitions.
This service allows greater flexibility in handling ad hoc data needs of the diagnostic application that
extend beyond the information that can be read via statically defined data identifiers, and can also be
used to reduce bandwidth utilization by avoiding overhead penalty associated with frequent
request/response transactions.
The definition of the dynamically defined data identifier can either be done via a single request message
or via multiple request messages. This allows for the definition of a single data element referencing
source identifier(s) and memory addresses. The server shall concatenate the definitions for the single
data element. A redefinition of a dynamically defined data identifier can be achieved by clearing the
current definition and start over with the new definition. When multiple
DynamicallyDefineDataIdentifier request messages are used to configure a single DataIdentifier and the
server detects the overrun of the maximum number of bytes during a subsequent request for this
DataIdentifier (e.g. definition of a periodicDataIdentifier), then the server shall leave the definition of
the DataIdentifier as it was prior to the request that would have led to the overrun.
Although this service does not prohibit such functionality, it is not recommended for the client to
reference one dynamically defined data record from another, because deletion of the referenced record
could create data consistency problems within the referencing record.
This service also provides the ability to clear an existing dynamically defined data record. Requests to
clear a data record shall be positively responded to if the specified data record identifier is within the
range of valid dynamic data identifiers supported by the server (see C.1 for more details).
The server shall maintain the dynamically defined data record until it is cleared or as specified by the
vehicle manufacturer (e.g. deletion of dynamically defined data records upon session transition or upon
power down of the server).
The server can implement data records in two different ways:
- Composite data records containing multiple elemental data records which are not individually referenced.
- Unique 2-byte identification “tag” or dataIdentifier (DID) value for individual, elemental data records supported within the server (an example elemental data record, or DID, is engine speed or intake air temperature). This implementation of data records is a subset of a composite data record implementation, because it only references a single elemental data record instead of a data record including multiple elemental data records.
Both types of implementing data records are supported by the DynamicallyDefineDataIdentifier service
to define a dynamic data identifier.
- Composite block of data: The position parameter shall reference the starting point in the composite block of data and the size parameter shall reflect the length of data to be placed in the dynamically defined data identifier. The tester is responsible to not include only a portion of an elemental data record of the composite block of data in the dynamic data record.
- 2-byte DID: The position parameter shall be set to one and the size parameter shall reflect the length of the DID (length of the elemental data record). The tester is responsible to not include only a portion of the 2-byte DID value in the dynamic data record.
The ordering of the data within the dynamically defined data record shall be of the same order as it was
specified in the client request message(s). Also, first position of the data specified in the client’s request
shall be oriented such that it occurs closest to the beginning of the dynamic data record, in accordance
with the ordering requirement mentioned in the preceding sentence.
In addition to the definition of a dynamic data identifier via a logical reference (a record data identifier)
this service provides the capability to define a dynamically defined data identifier via an absolute
memory address and a memory length information. This mechanism of defining a dynamic data
identifier is recommended to be used only during the development phase of a server.
IMPORTANT
The server and the client shall meet the request and response message behaviour as
specified in 8.7.
11.6.2 Request message
11.6.2.1 Request message definition
Table 236 specifies the request message – SubFunction = defineByIdentifier.
 |
Table 236 — Request message definition - SubFunction = defineByIdentifier |
Table 237 specifies the request message – SubFunction = defineByMemoryAddress.
 |
Table 237 — Request message definition - SubFunction = defineByMemoryAddress |
Table 238 specifies the request message – SubFunction = clearDynamicallyDefinedDataIdentifier.
 |
Table 238 — Request message definition - SubFunction = clearDynamicallyDefinedDataIdentifier |
11.6.2.2 Request message SubFunction parameter $Level (LEV_) definition
The sub-parameters defined as valid for the request message of this service are indicated in Table 239
(suppressPosRspMsgIndicationBit (bit 7) not shown).
 |
Table 239 — Request message SubFunction parameter definition |
11.6.2.3 Request message data-parameter definition
Table 240 specifies the data-parameters of the request message.
 |
Table 240 — Request message data-parameter definition |
11.6.3 Positive response message
11.6.3.1 Positive response message definition
Table 241 specifies the positive response message.
 |
Table 241 — Positive response message definition |
11.6.3.2 Positive response message data-parameter definition
Table 242 specifies the data-parameters of the positive response message.
 |
Table 242 — Response message data-parameter definition |
11.6.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 243. The listed negative responses
shall be used if the error scenario applies to the server.
 |
Table 243 — Supported negative response codes |
11.6.5 Message flow examples DynamicallyDefineDataIdentifier
11.6.5.1 Assumptions
This subclause specifies the conditions to be fulfilled for the example to perform a
DynamicallyDefineDataIdentifier service.
The service in this example is not limited by any restriction of the server.
In the first example, the server supports 2-byte identifiers (DIDs), which reference a single data
information. The example builds a dynamic data identifier using the defineByIdentifier method and
then sends a ReadDataByIdentifier request to read the just configured dynamic data identifier.
In the second example, the server supports data identifiers, which reference a composite block of data
containing multiple data information. The example builds a dynamic identifier also using the
defineByIdentifier method, and sends a ReadDataByIdentifier request to read the just defined data
identifier.
The third example builds a dynamic data identifier using the defineByMemoryAddress method, and
sends a ReadDataByIdentifier request to read the just defined data identifier.
In the fourth example, the server supports data identifiers, which reference a composite block of data
containing multiple data information. The example builds a dynamic data identifier using the
defineByIdentifier method and then uses the ReadDataByPeriodicIdentifier service to requests the
dynamically defined data identifier to be sent periodically by the server.
The fifth example demonstrates the deletion of a dynamically defined data identifier.
Table 244 shall be used for the examples below. The values being reported may change over time on a
real vehicle, but are shown to be constants for the sake of clarity.
 |
Table 244 — Composite data blocks - DataIdentifier definitions |
Refer to ISO 15031-2[16] for further details regarding accepted terms/definitions/acronyms for
emissions-related systems.
For all examples the client requests to have a response message by setting the
suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 245 specifies the elemental data records – DID definitions.
 |
Table 245 — Elemental data records - DID definitions |
Table 246 specifies the memory data records – memory address definitions.
 |
Table 246 — Memory data records - Memory address definitions |
11.6.5.2 Example #1: DynamicallyDefineDataIdentifier, SubFunction = defineByIdentifier
The example in Table 247 will build up a dynamic data identifier (DDDI 0xF301) containing engine oil
temperature, ambient air temperature, and engine oil level using the 2-byte DIDs as the reference for
the required data.
 |
Table 247 — DynamicallyDefineDataIdentifier request DDDDI 0xF301 message flow example #1 |
Table 248 specifies the DynamicallyDefineDataIdentifier positive response DDDDI 0xF301 message flow
example #1.
 |
Table 248 — DynamicallyDefineDataIdentifier positive response DDDDI F30116 message flow example #1 |
Table 249 specifies the ReadDataByIdentifier request DDDDI 0xF301 message flow example #1.
 |
Table 249 — ReadDataByIdentifier request DDDDI 0xF301 message flow example #1 |
Table 250 specifies the ReadDataByIdentifier positive response DDDDI 0xF301 message flow example
#1.
 |
Table 250 — ReadDataByIdentifier positive response DDDDI 0xF301 message flow example #1 |
11.6.5.3 Example #2: DynamicallyDefineDataIdentifier, SubFunction = defineByIdentifier
The example in Table 251 will build up a dynamic data identifier (DDDDI 0xF302) containing engine
coolant temperature (from data record 0x010A), engine speed (from data record 0x010A), IAC Pintle
Position (from data record 0x010A) and knock sensor (from data record 0x050B).
 |
Table 251 — DynamicallyDefineDataIdentifier request DDDDI 0xF302 message flow example #2 |
Table 252 specifies the DynamicallyDefineDataIdentifier positive response DDDDI 0xF302 message flow
example #2.
 |
Table 252 — DynamicallyDefineDataIdentifier positive response DDDDI 0xF302 message flow example #2 |
Table 253 specifies the ReadDataByIdentifier request DDDDI 0xF302 message flow example #2.
 |
Table 253 — ReadDataByIdentifier request DDDDI 0xF302 message flow example #2 |
Table 254 specifies the ReadDataByIdentifier positive response DDDDI 0xF302 message flow example
#2.
 |
Table 254 — ReadDataByIdentifier positive response DDDDI 0xF302 message flow example #2 |
11.6.5.4 Example #3: DynamicallyDefineDataIdentifier, SubFunction = defineByMemoryAddress
The example in Table 255 will build up a dynamic data identifier (DDDDI 0xF302) containing engine
coolant temperature (from memory block starting at memory address 0x2109 1969), engine speed (from
memory block starting at memory address 0x2109 196B), and knock sensor (from memory block
starting at memory address 0x1310 1995).
 |
Table 255 — DynamicallyDefineDataIdentifier request DDDDI 0xF302 message flow example #3 |
Table 256 specifies the DynamicallyDefineDataIdentifier positive response DDDDI 0xF302 message flow
example #3.
 |
Table 256 — DynamicallyDefineDataIdentifier positive response DDDDI 0xF302 message flow example #3 |
Table 257 specifies the ReadDataByIdentifier request DDDDI 0xF302 message flow example #3.
 |
Table 257 — ReadDataByIdentifier request DDDDI 0xF302 message flow example #3 |
Table 258 specifies the ReadDataByIdentifier positive response DDDDI 0xF302 message flow example
#3.
 |
Table 258 — ReadDataByIdentifier positive response DDDDI 0xF302 message flow example #3 |
11.6.5.5 Example #4: DynamicallyDefineDataIdentifier, SubFunction = defineByIdentifier
The example in Table 259 will build up a dynamic data identifier (DDDDI 0xF2E7) containing engine
coolant temperature (from data record 0x010A), engine speed (from data record 0x010A), and knock
sensor (from data record 0x050B).
The value for the dynamic data identifier is chosen out of the range that can be used to request data
periodically. Following the definition of the dynamic data identifier, the client requests the data
identifier to be sent periodically (fast rate).
 |
Table 259 — DynamicallyDefineDataIdentifier request DDDDI 0xF2E7 message flow example #4 |
Table 260 specifies the DynamicallyDefineDataIdentifier positive response DDDDI 0xF2E7 message flow
example #4.
 |
Table 260 — DynamicallyDefineDataIdentifier positive response DDDDI 0xF2E7 message flow example #4 |
Table 261 specifies the ReadDataByPeriodicIdentifier request DDDDI 0xF2E7 message flow example #4.
 |
Table 261 — ReadDataByPeriodicIdentifier request DDDDI 0xF2E7 message flow example #4 |
Table 262 specifies the ReadDataByPeriodicIdentifier initial positive message flow example #4.
 |
Table 262 — ReadDataByPeriodicIdentifier initial positive message flow example #4 |
Table 263 and Table 264 define the ReadDataByPeriodicIdentifier periodic data response #1 DDDDI 0xF2E7 message flow example #4.
 |
Table 263 — ReadDataByPeriodicIdentifier periodic data response #1 DDDDI 0xF2E7 message flow example #4 |
NOTE
Multiple response messages with different Byte values are not shown in this example.
 |
Table 264 — ReadDataByPeriodicIdentifier periodic data response #n DDDDI 0xF2E7 message flow example #4 |
11.6.5.6 Example #5: DynamicallyDefineDataIdentifier, SubFunction = clearDynamicallyDefined-DataIdentifier
The example in Table 265 demonstrates the clearing of a dynamicallyDefinedDataIdentifier, and
assumes that DDDDI 0xF303 exists at the time of the request.
 |
Table 265 — DynamicallyDefineDataIdentifier request clear DDDDI 0xF303 message flow example #5 |
Table 266 specifies the DynamicallyDefineDataIdentifier positive response clear DDDDI 0xF303 message
flow example #5.
 |
Table 266 — DynamicallyDefineDataIdentifier positive response clear DDDDI 0xF303 message flow example #5 |
11.6.5.7 Example #6: DynamicallyDefineDataIdentifier, concatenation of definitions (defineByIdentifier/defineByAddress)
This example will build up a dynamic data identifier (DDDI 0xF301) using the two definition types. The
following list shows the order of the data in the dynamically defined data identifier (implicit order of
request messages to define the dynamic data identifier):
- 1st portion: engine oil temperature and ambient air temperature referecend by 2-byte DIDs (defineByIdentifier),
- 2nd portion: engine coolant temperature and engine speed referenced by memory addresses,
- 3rd portion: engine oil level referenced by 2-byte DID.
11.6.5.7.1 Step #1: DynamicallyDefineDataIdentifier, SubFunction = defineByIdentifier (1 st portion)
Table 267 specifies the DynamicallyDefineDataIdentifier request DDDI 0xF301 message flow example
#6 definition of 1st portion (defineByIdentifier).
 |
Table 267 — DynamicallyDefineDataIdentifier request DDDI 0xF301 message flow example #6 definition of 1st portion (defineByIdentifier) |
Table 268 specifies the DynamicallyDefineDataIdentifier positive response DDDI 0xF301 message flow
example #6 definition of first portion (defineByIdentifier).
 |
Table 268 — DynamicallyDefineDataIdentifier positive response DDDI 0xF301 message flow example #6 definition of first portion (defineByIdentifier) |
11.6.5.7.2 Step #2: DynamicallyDefineDataIdentifier, SubFunction = defineByMemoryAddress (2 nd portion)
Table 269 specifies the DynamicallyDefineDataIdentifier request DDDDI 0xF301 message flow example
#6 definition of 2nd portion (defineByMemoryAddress).
 |
Table 269 — DynamicallyDefineDataIdentifier request DDDDI 0xF301 message flow example #6 definition of 2nd portion (defineByMemoryAddress) |
Table 270 specifies the DynamicallyDefineDataIdentifier positive response DDDI 0xF301 message flow
example #6.
 |
Table 270 — DynamicallyDefineDataIdentifier positive response DDDI 0xF301 message flow example #6 |
11.6.5.7.3 Step #3: DynamicallyDefineDataIdentifier, SubFunction = defineByIdentifier (3 rd portion)
Table 271 specifies the DynamicallyDefineDataIdentifier request DDDI 0xF301 message flow example
#6 definition of 3rd portion (defineByIdentifier).
 |
Table 271 — DynamicallyDefineDataIdentifier request DDDI 0xF301 message flow example #6 definition of 3rd portion (defineByIdentifier) |
Table 272 specifies the DynamicallyDefineDataIdentifier positive response DDDI 0xF301 message flow
example #6.
 |
Table 272 — DynamicallyDefineDataIdentifier positive response DDDI 0xF301 message flow example #6 |
11.6.5.7.4 Step #4: ReadDataByIdentifier - dataIdentifier = DDDDI 0xF301
Table 273 specifies the ReadDataByIdentifier request DDDDI 0xF301 message flow example #6.
 |
Table 273 — ReadDataByIdentifier request DDDDI 0xF301 message flow example #6 |
Table 274 specifies the ReadDataByIdentifier positive response DDDDI 0xF301 message flow example
#6.
 |
Table 274 — ReadDataByIdentifier positive response DDDDI 0xF301 message flow example #6 |
11.6.5.7.5 Step #5: DynamicallyDefineDataIdentifier - clear definition of DDDDI 0xF301
Table 275 specifies the DynamicallyDefineDataIdentifier request clear DDDDI 0xF301 message flow
example #6.
 |
Table 275 — DynamicallyDefineDataIdentifier request clear DDDDI 0xF301 message flow example #6 |
Table 276 specifies the DynamicallyDefineDataIdentifier positive response clear DDDDI 0xF301 message
flow example #6.
 |
Table 276 — DynamicallyDefineDataIdentifier positive response clear DDDDI 0xF301 message flow example #6 |
11.7 WriteDataByIdentifier (0x2E) 服务
11.7.1 服务描述
WriteDataByIdentifier 服务允许客户端将信息写入服务器，写入的位置由提供的 dataIdentifier 参数指定。
客户端通过 WriteDataByIdentifier 服务将 dataRecord 参数写入服务器。数据（可能已加密，也可能未加密）由 dataIdentifier 参数标识。
动态定义的 dataIdentifier 参数不得与此服务一起使用。车辆制造商有责任确保在执行此服务时服务器满足所需的条件。此服务的适用场景可能包括：
- 将配置信息写入服务器（例如，VIN 码（车辆识别码））
- 清除非易失性存储器（NvM）
- 重置已学习的值
- 对选项进行设置
注意
服务器可以限制或禁止对由某些 dataIdentifier 参数指定的位置进行写入（由系统供应商/车辆制造商定义的只读 dataIdentifier 参数等）。
重要
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
11.7.2 请求消息
11.7.2.1 请求消息的定义
表 277 指定了请求消息的定义。
 |
Table 277 — Request message definition |
11.7.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
此服务不支持请求消息的 SubFunction 参数。
11.7.2.3 请求消息的数据参数的定义
表 278 指定了请求消息的数据参数的定义。
 |
Table 278 — Request message data-parameter definition |
11.7.3 肯定响应消息
11.7.3.1 肯定响应消息的定义
表 279 指定了肯定响应消息的定义。
 |
Table 279 — Positive response message definition |
11.7.3.2 肯定响应消息的数据参数的定义
表 280 指定了肯定响应消息的数据参数的定义。
 |
Table 280 — Response message data-parameter definition |
11.7.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 281 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
 |
Table 281 — Supported negative response codes |
流程如图 26 所示。
 |
Figure 26 — NRC handling for WriteDataByIdentifier service |
11.7.5 消息流示例 WriteDataByIdentifier
11.7.5.1 假设
本子条款规定了（示例中）执行 WriteDataByIdentifier 服务所需满足的条件。
本示例中的服务不受服务器的任何限制。在本示例中，将对一个由 dataIdentifier 标识的数据（2 字节）进行写入（其中 dataIdentifier 0xF190 标识的数据为 VIN 码（车辆识别码））。
11.7.5.2 示例 #1 - 写入单个 dataIdentifier 0xF190（VIN 码）
表 282 指定了 WriteDataByIdentifier 服务的请求消息的消息流的示例 #1。
 |
Table 282 — WriteDataByIdentifier request message flow example #1 |
表 283 指定了 WriteDataByIdentifier 服务的肯定响应消息的消息流的示例 #1。
 |
Table 283 — WriteDataByIdentifier positive response message flow example #1 |
11.8 WriteMemoryByAddress (0x3D) service
11.8.1 Service description
The WriteMemoryByAddress service allows the client to write information into the server at one or more contiguous memory locations.
The WriteMemoryByAddress request message writes information specified by the parameter dataRecord[] into the server at memory locations specified by parameters memoryAddress and memorySize. The number of bytes used for the memoryAddress and memorySize parameter is defined by addressAndLengthFormatIdentifier (low and high nibble). It is also possible to use a fixed addressAndLengthFormatIdentifier and unused bytes within the memoryAddress or memorySize parameter are padded with the value 0016 in the higher range address locations.
The format and definition of the dataRecord shall be vehicle manufacturer specific and may or may not be secured. It is the vehicle manufacturer's responsibility to assure that the server conditions are met when performing this service. Possible uses for this service are:
- clear non-volatile memory; and
- change calibration values.
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
11.8.2 Request message
11.8.2.1 Request message definition
Table 284 specifies the request message definition.
 |
Table 284 — Request message definition |
11.8.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
11.8.2.3 Request message data-parameter definition
Table 285 specifies the data-parameters of the request message.
 |
Table 285 — Request message data-parameter definition |
11.8.3 Positive response message
11.8.3.1 Positive response message definition
Table 286 specifies the positive response message.
 |
Table 286 — Positive response message definition |
11.8.3.2 Positive response message data-parameter definition
Table 287 specifies the data-parameters of the positive response message.
 |
Table 287 — Response message data-parameter definition |
11.8.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 288. The listed negative responses shall be used if the error scenario applies to the server.
 |
Table 288 — Supported negative response codes |
The evaluation sequence is documented in Figure 27.
 |
Figure 27 — NRC handling for WriteMemoryByAddress service |
11.8.5 Message flow example WriteMemoryByAddress
11.8.5.1 Assumptions
This subclause specifies the conditions to be fulfilled for the example to perform a WriteMemoryByAddress service. The service in this example is not limited by any restriction of the server.
The following examples demonstrate writing data bytes into server memory for 2-byte, 3-byte, and 4- byte addressing formats, respectively.
11.8.5.2 Example #1: WriteMemoryByAddress, 2-byte (16-bit) addressing
Table 289 specifies the WriteMemoryByAddress request message flow example #1.
 |
Table 289 — WriteMemoryByAddress request message flow example #1 |
Table 290 specifies the WriteMemoryByAddress positive response message flow example #1.
 |
Table 290 — WriteMemoryByAddress positive response message flow example #1 |
11.8.5.3 Example #2: WriteMemoryByAddress, 3-byte (24-bit) addressing
Table 291 specifies the WriteMemoryByAddress request message flow example #2.
 |
Table 291 — WriteMemoryByAddress request message flow example #2 |
Table 292 specifies the WriteMemoryByAddress positive response message flow example #2.
 |
Table 292 — WriteMemoryByAddress positive response message flow example #2 |
11.8.5.4 Example #3: WriteMemoryByAddress, 4-byte (32-bit) addressing
Table 293 specifies the WriteMemoryByAddress request message flow example #3.
 |
Table 293 — WriteMemoryByAddress request message flow example #3 |
Table 294 specifies the WriteMemoryByAddress positive response message flow example #3.
 |
Table 294 — WriteMemoryByAddress positive response message flow example #3 |
12 存储数据传输功能单元
12.1 概述
表 295 指定了存储数据传输功能单元。
 |
Table 295 — Stored data transmission functional unit |
12.2 ClearDiagnosticInformation (0x14) service
12.2.1 Service description
The ClearDiagnosticInformation service is used by the client to clear diagnostic information in one or multiple servers' memory.
The server shall send a positive response when the ClearDiagnosticInformation service is completely processed. The server shall send a positive response even if no DTCs are stored. If a server supports multiple copies of DTC status information in memory (e.g. one copy in RAM and one copy in EEPROM) the server shall clear the copy used by the ReadDTCInformation status reporting service. Additional copies, e.g. backup copy in long-term memory, are updated according to the appropriate backup strategy (e.g. in the power-latch phase).
NOTE
In case the power-latch phase is disturbed (e.g. a battery disconnection during the power-latch phase) this can cause data inconsistency.
The behaviour of the individual DTC status bits shall be implemented according to the definitions in D.2, Figure D.1 to Figure D.8.
The request message of the client contains one parameter. The parameter groupOfDTC allows the client to clear a group of DTCs (e.g. Powertrain, Body, Chassis, etc.), or a specific DTC. Refer to D.1 for further details. Unless otherwise stated, the server shall clear both emissions-related and non emissionsrelated DTC information from memory for the requested group.
DTC information reset/cleared via this service includes but is not limited to the following:
- DTC status byte (see ReadDTCInformation service in 12.3),
- captured DTC snapshot data (DTCSnapshotData, see ReadDTCInformation service in 12.3),
- captured DTC extended data (DTCExtendedData, see ReadDTCInformation service in 12.3),
- other DTC related data such as first/most recent DTC, flags, counters, timers, etc. specific to DTCs.
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
12.2.2 Request message
12.2.2.1 Request message definition
Table 296 specifies the request message.
 |
Table 296 — Request message definition |
12.2.2.2 Request message SubFunction parameter $Level (LEV_) definition
There are no SubFunction parameters used by this service.
12.2.2.3 Request message data-parameter definition
Table 297 specifies the data-parameter of the request message.
 |
Table 297 — Request message data-parameter definition |
12.2.3 Positive response message
12.2.3.1 Positive response message definition
Table 298 specifies the positive response message.
 |
Table 298 — Positive response message definition |
12.2.3.2 Positive response message data-parameter definition
There are no data-parameters used by this service in the positive response message.
12.2.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 299. The listed negative responses shall be used if the error scenario applies to the server.
 |
Table 299 — Supported negative response codes |
The evaluation sequence is documented in Figure 28.
 |
Figure 28 — NRC handling for ClearDiagnosticInformation service |
12.2.5 Message flow example ClearDiagnosticInformation
The client sends a ClearDiagnosticInformation request message to a single server. Table 300 specifies the ClearDiagnosticInformation request message flow example #1. The client sends a ClearDiagnosticInformation request message to a single server.
 |
Table 300 — ClearDiagnosticInformation request message flow example #1 |
Table 301 specifies the ClearDiagnosticInformation positive response message flow example #1.
 |
Table 301 — ClearDiagnosticInformation positive response message flow example #1 |
12.3 ReadDTCInformation (0x19) service
12.3.1 Service description
12.3.1.1 General description
This service allows a client to read the status of server resident Diagnostic Trouble Code (DTC) information from any server, or group of servers within a vehicle. Unless otherwise required by the particularSubFunction, the server shall return all DTC information (e.g. emissions-related and non emissions-related). This service allows the client to do the following:
- retrieve the number of DTCs matching a client defined DTC status mask;
- retrieve the list of all DTCs matching a client defined DTC status mask;
- retrieve the list of DTCs within a particular functional group matching a client defined DTC status mask;
- retrieve all DTCs with "permanent DTC" status;
- retrieve DTCSnapshot data (sometimes referred to as freeze frames) associated with a client defined DTC: DTC Snapshots are specific data records associated with a DTC, that are stored in the server's memory. The typical usage of DTC Snapshots is to store data upon detection of a system malfunction. The DTC Snapshots will act as a snapshot of data values from the time of the system malfunction occurrence. The data-parameters stored in the DTC Snapshot shall be associated to the DTC. The DTC specific data-parameters are intended to ease the fault isolation process by the technician;
- retrieve a list of all DTCs which support a specific DTCExtendedDataRecord for a client defined DTCExtDataRecordNumber;
- retrieve DTCExtendedData associated with a client defined DTC and status mask combination out of the DTC memory. DTCExtendedData consists of extended status information associated with a DTC. DTCExtendedData contains DTC parameter values, which have been identified at the time of the request. A typical use of DTCExtendedData is to store dynamic data associated with the DTC, for example:
- DTC B1 Malfunction Indicator counter which conveys the amount of time (number of engine operating hours) during which the OBD system has operated while a malfunction is active;
- DTC occurrence counter, counts number of driving cycles in which "testFailed" has been reported;
- DTC aging counter, counts number of driving cycles since the fault was latest failed excluding the driving cycles in which the test has not reported "testPassed" or "testFailed";
- specific counters for OBD (e.g. number of remaining driving cycles until the "check engine" lamp is switched off if driving cycle can be performed in a fault free mode);
- time of last occurrence (etc.);
- test failed counter, counts number of reported "testFailed" and possible other counters if the validation is performed in several steps;
- uncompleted test counters, counts numbers of driving cycles since the test was latest completed (i.e. since the test reported "testPassed" or "testFailed");
- retrieve the number of DTCs matching a client defined severity mask;
- retrieve the list of DTCs matching a client defined severity mask record;
- retrieve severity information for a client defined DTC;
- retrieve the status of all DTCs supported by the server;
- retrieve the first DTC failed by the server;
- retrieve the most recently failed DTC within the server;
- retrieve the first DTC confirmed by the server;
- retrieve the most recently confirmed DTC within the server;
- retrieve all current "prefailed" DTCs which have or have not yet been detected as "pending" or "confirmed";
- retrieve DTCExtendedData associated with a client defined DTCExtendedData record status out of the DTC memory;
- retrieve the list of DTCs out of a user defined DTC memory matching a client defined DTC status mask;
- retrieve user defined DTC memory DTCExtendedData record data for a client defined DTC mask;
- retrieve user defined DTC memory DTCSnapshotRecord data for a client defined DTC mask out of the user defined DTC memory;
- retrieve DTC information for a client defined DTCReadinessGroupIdentifier.
This service uses a SubFunction to determine which type of diagnostic information the client is
requesting. Further details regarding each SubFunction parameter are provided in the following
subclauses.
This service makes use of the following terms:
- Enable criteria: Server/vehicle manufacturer/system supplier specific criteria used to control when the server actually performs a particular internal diagnostic.
- Test pass criteria: Server/vehicle manufacturer/system supplier specific conditions, that define, whether a system being diagnosed is functioning properly within normal, acceptable operating ranges (e.g. no failures exist and the diagnosed system is classified as “OK”).
- Test failure criteria: Server/vehicle manufacturer/system supplier specific failure conditions that define, whether a system being diagnosed has failed the test.
- Confirmed failure criteria: Server/vehicle manufacturer/system supplier specific failure conditions that define whether the system being diagnosed is definitively problematic (confirmed), warranting storage of the DTC record in long term memory.
- Occurrence counter: A counter maintained by certain servers that records the number of instances in which a given DTC test reported a unique occurrence of a test failure.
- Aging: A process whereby certain servers evaluate past results of each internal diagnostic to determine if a confirmed DTC can be cleared from long-term memory, for example in the event of a calibrated number of failure free cycles.
A given DTC value (e.g. 0x080511) shall never be reported more than once in a positive response to
readDTCInformation with the exception of reading DTCSnapshotRecords, where the response may
contain multiple DTCSnapshotRecords for the same DTC.
When using paged-buffer-handling to read DTCs (especially for SubFunction =
reportDTCByStatusMask), it is possible that the number of DTCs can decrease while creating the
response. In such a case the response shall be filled up with DTC 0x000000 and DTC status 0x00. The
client shall treat these DTCs as not present in the response message.
IMPORTANT
The server and the client shall meet the request and response message behaviour as
specified in 8.7.
12.3.1.2 Retrieving the number of DTCs that match a client defined status mask (SubFunction = 0x01 reportNumberOfDTCByStatusMask)
A client can retrieve a count of the number of DTCs matching a client defined status mask by sending a
request for this service with the SubFunction set to reportNumberOfDTCByStatusMask. The response to
this request contains the DTCStatusAvailabilityMask, which provides an indication of DTC status bits
that are supported by the server for masking purposes. Following the DTCStatusAvailabilityMask the
response contains the DTCFormatIdentifier which reports information about the DTC formatting and
encoding. The DTCFormatIdentifier is followed by the DTCCount parameter which is a 2-byte unsigned
numeric number containing the number of DTCs available in the server's memory based on the status
mask provided by the client.
12.3.1.3 Retrieving the list of DTCs that match a client defined status mask (SubFunction = 0x02 reportDTCByStatusMask)
The client can retrieve a list of DTCs, which satisfy a client defined status mask by sending a request
with the SubFunction byte set to reportDTCByStatusMask. This SubFunction
The evaluation shall be done as follows: The server shall perform a bit-wise logical AND-ing operation
between the mask specified in the client’s request and the actual status associated with each DTC
supported by the server. In addition to the DTCStatusAvailabilityMask, the server shall return all DTCs
for which the result of the AND-ing operation is non-zero (i.e. (statusOfDTC & DTCStatusMask) != 0). If
the client specifies a status mask that contains bits that the server does not support, then the server
shall process the DTC information using only the bits that it does support. If no DTCs within the server
match the masking criteria specified in the client’s request, no DTC or status information shall be
provided following the DTCStatusAvailabilityMask byte in the positive response message.
DTC status information shall be cleared upon a successful ClearDiagnosticInformation request from the
client (see DTC status bit definitions in D.2 for further descriptions on the DTC status bit handling in
case of a ClearDiagnosticInformation service request reception in the server).
12.3.1.4 Retrieving DTCSnapshot record identification (SubFunction = 0x03 reportDTCSnapshotIdentification)
A client can retrieve DTCSnapshot record identification information for all captured DTCSnapshot
records by sending a request for this service with the SubFunction set to
reportDTCSnapshotIdentification. The server shall return the list of DTCSnapshot record identification
information for all stored DTCSnapshot records. Each item the server places in the response message
for a single DTCSnapshot record shall contain a DTCRecord [containing the DTC number (high, middle,
and low byte)] and the DTCSnapshot record number. In case multiple DTCSnapshot records are stored
for a single DTC then the server shall place one item in the response for each occurrence, using a
different DTCSnapshot record number for each occurrence (used for the later retrieval of the record
data).
A server can support the storage of multiple DTCSnapshot records for a single DTC to track conditions
present at each occurrence of the DTC. Support of this functionality, definition of “occurrence” criteria,
and the number of DTCSnapshot records to be supported shall be defined by the system
supplier/vehicle manufacturer.
DTCSnapshot record identification information shall be cleared upon a successful
ClearDiagnosticInformation request from the client. It is in the responsibility of the vehicle
manufacturer to specify the rules for the deletion of stored DTCs and DTCSnapshot data in case of a
memory overflow (memory space for stored DTCs and DTCSnapshot data completely occupied in the
server).
12.3.1.5 Retrieving DTCSnapshot record data for a client defined DTC mask (SubFunction = 0x04 reportDTCSnapshotRecordByDTCNumber)
A client can retrieve captured DTCSnapshot record data for a client defined DTCMaskRecord in
conjunction with a DTCSnapshot record number by sending a request for this service with the
SubFunction set to reportDTCSnapshotRecordByDTCNumber. The server shall search through its
supported DTCs for an exact match with the DTCMaskRecord specified by the client (containing the DTC
number (high, middle, and low byte)). The UserDefDTCSnapshotRecordNumber parameter provided in
the client’s request shall specify a particular occurrence of the specified DTC for which DTCSnapshot
record data is being requested.
NOTE 1
The UserDefDTCSnapshotRecordNumber does not share the same address space as the
DTCStoredDataRecordNumber.
If the server supports the ability to store multiple DTCSnapshot records for a single DTC (support of
this functionality to be defined by system supplier/vehicle manufacturer), then it is recommended that
the server also implements the reportDTCSnapshotIdentification SubFunction parameter. It is
recommended that the client first requests the identification of DTCSnapshot records stored using the
SubFunction parameter reportDTCSnapshotIdentification before requesting a specific
DTCSnapshotRecordNumber via the reportDTCSnapshotRecordByDTCNumber request.
It is also recommended to support the SubFunction parameter reportDTCSnapshotRecordIdentification
in order to give the client the opportunity to identify the stored DTCSnapshot records directly instead of
parsing through all stored DTCs of the server to determine if a DTCSnapshot record is stored.
It shall be the responsibility of the system supplier/vehicle manufacturer to define whether
DTCSnapshot records captured within such servers store data associated with occurrence information
of a failure as part of the ECU documentation.
Along with the DTC number and statusOfDTC, the server shall return a single predefined
DTCSnapshotRecord in response to the client’s request, if a failure has been identified for the client
defined DTCMaskRecord and DTCSnapshotRecordNumber parameters (DTCSnapshotRecordNumber
unequal 0xFF).
NOTE 2
The exact failure criteria is defined by the system supplier/vehicle manufacturer.
The DTCSnapshot record may contain multiple data-parameters that can be used to reconstruct the
vehicle conditions (e.g. B+, RPM, time-stamp) at the time of the failure occurrence.
The vehicle manufacturer shall define format and content of the DTCSnapshotRecord. The data
reported in the DTCSnapshotRecord first of all contains a dataIdentifier to identify the data that follows.
This dataIdentifier/data combination can be repeated within the DTCSnapshotRecord.The usage of one
or multiple dataIdentifiers in the DTCSnapshotRecord allows for the storage of different types of
DTCSnapshotRecords for a single DTC for different occurrences of the failure. A parameter which
indicates the number of record DataIdentifiers contained within each DTCSnapshotRecord shall be
provided with each DTCSnapshotRecord to assist data retrieval.
The server shall report one DTCSnapshot record in a single response message, except the client has set
the UserDefDTCSnapshotRecordNumber to FF16, because this shall cause the server to respond with all
DTCSnapshot records stored for the client defined DTCMaskRecord in a single response message. The
DTCAndStatusRecord is only included one time in the response message. If the client has used FF16 for
the parameter DTCSnapshotRecordNumber in its request, the server shall report all DTCSnapshot
records captured for the particular DTC in numeric ascending order.
The server shall negatively respond if the DTCMaskRecord or DTCSnapshotRecordNumber parameters
specified by the client are invalid or not supported by the server. This is to be differentiated from the
case in which the DTCMaskRecord and/or DTCSnapshotRecordNumber parameters specified by the
client are indeed valid and supported by the server, but have no DTCSnapshot data associated with it
(e.g. because a failure event never occurred for the specified DTC or record number). The server shall
send the positive response containing only the DTCAndStatusRecord [echo of the requested DTC
number (high, middle, and low byte) plus the statusOfDTC].
DTCSnapshot information shall be cleared upon a successful ClearDiagnosticInformation request from
the client. It is in the responsibility of the vehicle manufacturer to specify the rules for the deletion of
stored DTCs and DTCSnapshot data in case of a memory overflow (memory space for stored DTCs and
DTCsnapshot data completely occupied in the server).
12.3.1.6 Retrieving DTCStoredData record data for a client defined record number (SubFunction = 0x05 reportDTCStoredDataByRecordNumber)
A client can retrieve captured DTCStoredData record data for a DTCStoredDataRecordNumber by
sending a request for this service with the SubFunction set to reportDTCStoredDataByRecordNumber.
The server shall search through its stored DTCStoredData records for the match of the client provided
record number.
The DTCStoredDataRecordNumber does not share the same address space as the
DTCSnapshotRecordNumber.
It shall be the responsibility of the system supplier/vehicle manufacturer to define whether
DTCStoredData records captured within such servers store data associated with the first or most recent
occurrence of a failure.
NOTE
The exact failure criteria is defined by the system supplier/vehicle manufacturer.
The DTCStoredData record may contain multiple data-parameters that can be used to reconstruct the
vehicle conditions (e.g. B+, RPM, time-stamp) at the time of the failure occurrence.
The vehicle manufacturer shall define format and content of the DTCStoredDataRecordNumber. The
data reported in the DTCStoredDataRecord first of all contains a dataIdentifier to identify the data that
follows. This dataIdentifier/data combination can be repeated within the DTCStoredDataRecord. The
usage of one or multiple dataIdentifiers in the DTCStoredDataRecord allows for the storage of different
types of DTCStoredDataRecords for a single DTC for different occurrences of the failure. A parameter
which indicates the number of record DataIdentifiers contained within each DTCStoredDataRecord
shall be provided with each DTCStoredDataRecord to assist data retrieval.
The server shall report one DTCStoredDataRecord in a single response message, except the client has
set the DTCStoredDataRecordNumber to FF16, because this shall cause the server to respond with all
DTCStoredDataRecords stored in a single response message.
In case the client requested to report all DTCStoredDataRecords by record number, then the
DTCAndStatusRecord shall be repeated in the response message for each stored DTCStoredDataRecord.
The server shall negatively respond if the DTCStoredDataRecordNumber parameters specified by the
client are invalid or not supported by the server. This shall be differentiated from the case in which the
DTCStoredDataRecordNumber parameters specified by the client are indeed valid and supported by the
server, but have no DTCStoredDataRecord data associated with it (e.g. because a failure event never
occurred for the specified record number). In this case, the server shall send the positive response
containing only the DTCStoredDataRecordNumber (echo of the requested record number).
DTCStoredDataRecord information shall be cleared upon a successful ClearDiagnosticInformation
request from the client. It is in the responsibility of the vehicle manufacturer to specify the rules for the
deletion of stored DTCs and DTCStoredDataRecord data in case of a memory overflow (memory space
for stored DTCs and DTCStoredDataRecord data completely occupied in the server).
12.3.1.7 Retrieving DTCExtendedData record data for a client defined DTC mask and a client defined DTCExtendedData record number (SubFunction = 0x06 reportDTCExtDataRecordByDTCNumber)
A client can retrieve DTCExtendedData for a client defined DTCMaskRecord in conjunction with a
DTCExtendedData record number by sending a request for this service with the SubFunction set to
reportDTCExtDataRecordByDTCNumber. The server shall search through its supported DTCs for an
exact match with the DTCMaskRecord specified by the client [containing the DTC number (high, middle,
and low byte)]. In this case, the DTCExtDataRecordNumber parameter provided in the client’s request
shall specify a particular DTCExtendedData record of the specified DTC for which DTCExtendedData is
being requested.
Along with the DTC number and statusOfDTC, the server shall return a single predefined
DTCExtendedData record in response to the client’s request (DTCExtDataRecordNumber unequal to 0xFE or 0xFF).
The vehicle manufacturer shall define format and content of the DTCExtDataRecord. The structure of
the data reported in the DTCExtDataRecord is defined by the DTCExtDataRecordNumber in a similar
way to the definition of data within a record DataIdentifier. Multiple DTCExtDataRecordNumbers and
associated DTCExtDataRecords may be included in the response. The usage of one or multiple
DTCExtDataRecordNumbers allows for the storage of different types of DTCExtDataRecords for a single
DTC.
The server shall report one DTCExtendedData record in a single response message, except the client has
set the DTCExtDataRecordNumber to 0xFE or 0xFF, because this shall cause the server to respond with
all DTCExtendedData records stored for the client defined DTCMaskRecord in a single response
message.
The server shall negatively respond if the DTCMaskRecord or DTCExtDataRecordNumber parameters
specified by the client are invalid or not supported by the server. This includes the case where a
DTCExtDataRecordNumber of 0xFE is sent by the client, but no OBD extended data records (0x90 to 0xEF)
are supported by the server. This shall be differentiated from the case in which the DTCMaskRecord
and/or DTCExtDataRecordNumber parameters specified by the client are indeed valid and supported
by the server, but have no DTC extended data associated with it (e.g. because of memory overflow of the
extended data). In case of reportDTCExtDataRecordByDTCNumber the server shall send the positive
response containing only the DTCAndStatusRecord [echo of the requested DTC number (high, middle,
and low byte) plus the statusOfDTC].
Clearance of DTCExtendedData information upon the reception of a ClearDiagnosticInformation service
is specified in 11.2.1. It is in the responsibility of the vehicle manufacturer to specify the rules for the
deletion of stored DTCs and DTC extended data in case of a memory overflow (memory space for stored
DTCs and DTC extended data completely occupied in the server).
12.3.1.8 Retrieving the number of DTCs that match a client defined severity mask record (SubFunction = 0x07 reportNumberOfDTCBySeverityMaskRecord)
A client can retrieve a count of the number of DTCs matching a client defined severity status mask
record by sending a request for this service with the SubFunction set to
reportNumberOfDTCBySeverityMaskRecord. The server shall scan through all supported DTCs,
performing a bit-wise logical AND-ing operation between the mask record specified by the client with
the actual information of each stored DTC.
(((statusOfDTC & DTCStatusMask) != 0) && ((severity & DTCSeverityMask) != 0)) == TRUE
For each AND-ing operation yielding a TRUE result, the server shall increment a counter by 1. If the
client specifies a status mask within the mask record that contains bits that the server does not support,
then the server shall process the DTC information using only the bits that it does support. Once all
supported DTCs have been checked once, the server shall return the DTCStatusAvailabilityMask and
resulting 2-byte count to the client.
If no DTCs within the server match the masking criteria specified in the client's request, the count
returned by the server to the client shall be 0. The reported number of DTCs matching the DTC status
mask is valid for the point in time when the request was made. There is no relationship between the
reported number of DTCs and the actual list of DTCs read via the SubFunction reportDTCByStatusMask,
because the request to read the DTCs is done at a different point in time.
12.3.1.9 Retrieving severity and functional unit information that match a client defined severity mask record (SubFunction = 0x08 reportDTCBySeverityMaskRecord)
The client can retrieve a list of DTC severity and functional unit information, which satisfy a client
defined severity mask record by sending a request with the SubFunction byte set to
reportDTCBySeverityMaskRecord. This SubFunction allows the client to request the server to report all
DTCs with a certain severity and status that are "testFailed" OR "confirmed" OR "etc.". The evaluation
shall be done as follows.
The server shall perform a bit-wise logical AND-ing operation between the DTCSeverityMask and the
DTCStatusMask specified in the client’s request and the actual DTCSeverity and statusOfDTC associated
with each DTC supported by the server.
In addition to the DTCStatusAvailabilityMask, server shall return all DTCs for which the result of the
AND-ing operation is TRUE.
(((statusOfDTC & DTCStatusMask) !=0) && ((severity & DTCSeverityMask) != 0)) == TRUE
If the client specifies a status mask within the mask record that contains bits that the server does not
support, then the server shall process the DTC information using only the bits that it does support. If no
DTCs within the server match the masking criteria specified in the client’s request, no DTC or status
information shall be provided following the DTCStatusAvailabilityMask byte in the positive response
message.
12.3.1.10Retrieving severity and functional unit information for a client defined DTC (SubFunction = 0x09 reportSeverityInformationOfDTC)
A client can retrieve severity and functional unit information for a client defined DTCMaskRecord by
sending a request for this service with the SubFunction set to reportSeverityInformationOfDTC. The
server shall search through its supported DTCs for an exact match with the DTCMaskRecord specified
by the client [containing the DTC number (high, middle, and low byte)].
12.3.1.11Retrieving the status of all DTCs supported by the server (SubFunction = 0x0A reportSupportedDTC)
A client can retrieve the status of all DTCs supported by the server by sending a request for this service
with the SubFunction set to reportSupportedDTCs. The response to this request contains the
DTCStatusAvailabilityMask, which provides an indication of DTC status bits that are supported by the
server for masking purposes. Following the DTCStatusAvailabilityMask, the response also contains the
listOfDTCAndStatusRecord, which contains the DTC number and associated status for every diagnostic
trouble code supported by the server.
12.3.1.12Retrieving the first/most recent failed DTC (SubFunction = 0x0B reportFirstTestFailedDTC, SubFunction = 0x0D reportMostRecentTestFailedDTC)
The client can retrieve the first/most recent failed DTC from the server by sending a request with the
SubFunction byte set to “reportFirstTestFailedDTC” or “reportMostRecentTestFailedDTC”, respectively.
Along with the DTCStatusAvailabilityMask, the server shall return the first or most recent failed DTC
number and associated status to the client.
No DTC/status information shall be provided following the DTCStatusAvailabilityMask byte in the
positive response message if there were no failed DTCs logged since the last time the client requested
the server to clear diagnostic information. Also, if the status of only one DTC is failed since the last time
the client requested the server to clear diagnostic information, the one failed DTC shall be returned to
both reportFirstTestFailedDTC and reportMostRecentTestFailedDTC requests from the client.
Record of the first/most recent failed DTC shall be independent of the ageing process of confirmed
DTCs.
As mentioned above, first/most recent failed DTC information shall be cleared upon a successful
ClearDiagnosticInformation request from the client (see DTC status bit definitions in D.2 for further
descriptions on the DTC status bit handling in case of a ClearDiagnosticInformation service request
reception in the server).
12.3.1.13Retrieving the first/most recently detected confirmed DTC (SubFunction = 0x0C reportFirstConfirmedDTC,SubFunction = 0x0E reportMostRecentConfirmedDTC)
The client can retrieve the first/most recent confirmed DTC from the server by sending a request with
the SubFunction byte set to “reportFirstConfirmedDTC” or “reportMostRecentConfirmedDTC”,
respectively. Along with the DTCStatusAvailabilityMask, the server shall return the first or most recent
confirmed DTC number and associated status to the client.
No DTC/status information shall be provided following the DTCStatusAvailabilityMask byte in the
positive response message if there were no confirmed DTCs logged since the last time the client
requested the server to clear diagnostic information. Also, if only 1 DTC is confirmed since the last time the client requested the server to clear diagnostic information the one confirmed DTC shall be returned
to both reportFirstConfirmedDTC and reportMostRecentConfirmedDTC requests from the client.
The record of the first confirmed DTC shall be preserved in the event that the DTC failed at one point in
the past, but then satisfied aging criteria prior to the time of the request from the client (regardless of
any other DTCs that become confirmed after the aforementioned DTC is confirmed). Similarly, record of
the most recently confirmed DTC shall be preserved in the event that the DTC was confirmed at one
point in the past, but then satisfied aging criteria prior to the time of the request from the client
(assuming no other DTCs is confirmed after the aforementioned DTC failed).
As mentioned above, first/most recent confirmed DTC information shall be cleared upon a successful
ClearDiagnosticInformation request from the client.
12.3.1.14Retrieving a list of "prefailed" DTC status (SubFunction = 0x14 reportDTCFaultDetection-Counter)
The client can retrieve a list of all current "prefailed" DTCs which have or have not yet been detected as
"pending" or "confirmed" at the time of the client's request. The intention of the
DTCFaultDetectionCounter is a simple method to identify a growing or intermittent problem which
cannot be identified/read by the statusOfDTC byte of a particular DTC. The internal implementation of
the DTCFaultDetectionCounter shall be vehicle manufacturer specific. The use case of "prefailed" DTCs
is to speed up failure detection during testing in the manufacturing plants for DTCs that require a
maturation time unacceptable to manufacturing testing. Service has a similar use case after repairing or
installing new components.
12.3.1.15Retrieving a list of DTCs with "permanent DTC" status (SubFunction = 0x15 reportDTCWithPermanentStatus)
The client can retrieve a list of DTCs with "permanent DTC" status as described in 3.12.
The SubFunction 0x15 will be replaced by SubFunction 0x55 in the future. In case there is a need for
PermanentDTC implementation it is recommended to use the 0x55 SubFunction.
12.3.1.16Retrieving DTCExtendedData record data for a client defined DTCExtendedData record number (SubFunction = 0x16 reportDTCExtDataRecordByRecordNumber)
A client can retrieve DTCExtendedData for a client defined DTCExtendedData record number by
sending a request for this service with the SubFunction set to
reportDTCExtDataRecordByRecordNumber. The server shall search through all supported DTCs for
exact matches with the DTCExtDataRecordNumber specified by the client. In this case, the
DTCExtDataRecordNumber parameter provided in the client’s request shall specify a particular
DTCExtendedData record for all supported DTCs for which DTCExtendedData is being requested.
The server shall return a DTCExtendedData record along with the DTC number and statusOfDTC for
each supported DTC that contains data for the requested DTCExtDataRecordNumber.
The vehicle manufacturer shall define the format and content of the DTCExtDataRecord. The structure
of the data reported in the DTCExtDataRecord is defined by the DTCExtDataRecordNumber in a similar
way to the definition of data within a record DataIdentifier.
The server shall negatively respond if the DTCExtDataRecordNumber parameter specified by the client
is invalid or not supported by the server.
Clearance of DTCExtendedData information upon the reception of a ClearDiagnosticInformation service
is specified in 11.2.1. It is in the responsibility of the vehicle manufacturer to specify the rules for the
deletion of stored DTCs and DTC extended data in case of a memory overflow (memory space for stored
DTCs and DTC extended data completely occupied in the server).
12.3.1.17Retrieving the list of DTCs out of the server's user defined DTC memory that match a client defined DTC status mask (SubFunction = 0x17 reportUserDefMemoryDTCByStatusMask)
The client can retrieve a list of DTCs from a user defined memory, which satisfy a client defined status
mask by sending a request with the SubFunction byte set to reportUserDefMemoryDTCByStatusMask.
This SubFunction allows the client to request the server to report all DTCs that are “testFailed” or
“confirmed” or “etc.” from the user defined memory.
The evaluation shall be done as follows: the server shall perform a bit-wise logical AND-ing operation
between the mask specified in the client’s request and the actual status associated with each DTC
supported by the server in that user defined memory. In addition to the DTCStatusAvailabilityMask, the
server shall return all DTCs for which the result of the AND-ing operation is non-zero (i.e. (statusOfDTC
& DTCStatusMask) != 0) in that specific memory. If the client specifies a status mask that contains bits
that the server does not support, then the server shall process the DTC information using only the bits
that it does support. If no DTCs within the server match the masking criteria specified in the client’s
request in that specific memory, no DTC or status information shall be provided following the
DTCStatusAvailabilityMask byte in the positive response message.
DTC status information shall be cleared either by a service 0x14 ClearDTC service with the
memorySelection parameter set to the applicable memory or by manufacturer specific conditions (e.g. a
routine control request from the client).
12.3.1.18Retrieving user defined memory DTCSnapshot record data for a client defined DTC mask and a client defined DTCSnapshotNumber out of the DTC user defined memory (SubFunction = 0x18 reportUserDefMemoryDTCSnapshotRecordByDTCNumber)
A client can retrieve captured DTCSnapshot record data for a client defined DTCMaskRecord in
conjunction with a DTCSnapshot record number and a user defined memory identifier by sending a
request for this service with the SubFunction set to
reportUserDefMemoryDTCSnapshotRecordByDTCNumber. The server shall search through its
supported DTCs for an exact match with the DTCMaskRecord specified by the client [containing the DTC
number (high, middle, and low byte)]. The DTCSnapshotRecordNumber parameter provided in the
client’s request shall specify a particular occurrence of the specified DTC and the defined memory for
which DTCSnapshot record data is being requested.
NOTE 1
The DTCSnapshotRecordNumber does not share the same address space as the
DTCStoredDataRecordNumber.
It shall be the responsibility of the system supplier/vehicle manufacturer to define whether
DTCSnapshot records captured within such servers store data associated with the first or most recent
occurrence of a failure.
Along with the DTC number and statusOfDTC, the server shall return a single predefined
UserDefDTCSnapshotRecordNumber from the specific user memory in response to the client’s request,
if a failure has been identified for the client defined DTCMaskRecord and
UserDefDTCSnapshotRecordNumber parameters (UserDefDTCSnapshotRecordNumber unequal 0xFF)
and that specific memory.
NOTE 2
The exact failure criteria is defined by the system supplier/vehicle manufacturer.
The DTCSnapshot record may contain multiple data-parameters that can be used to reconstruct the
vehicle conditions (e.g. B+, RPM, time-stamp) at the time of the failure occurrence.
The vehicle manufacturer shall define format and content of the DTCSnapshotRecord in the user
defined memory (i.e. the content of the DTCSnapshotRecords can differ between different memories)
records. The data reported in the DTCSnapshotRecord first of all contains a dataIdentifier to identify the
data that follows. This dataIdentifier/data combination can be repeated within the DTCSnapshotRecord. The usage of one or multiple dataIdentifiers in the DTCSnapshotRecord in the
user defined memory allows for the storage of different types of DTCSnapshotRecords for a single DTC
for different occurrences of the failure. A parameter which indicates the number of record
DataIdentifiers contained within each DTCSnapshotRecord shall be provided with each
DTCSnapshotRecord to assist data retrieval.
The server shall report one DTCSnapshot record in a single response message, except if the client has
set the UserDefDTCSnapshotRecordNumber to 0xFF, because this shall cause the server to respond with
all DTCSnapshot records stored for the client defined DTCMaskRecord and the user defined memory in
a single response message. The DTCAndStatusRecord is only included one time in the response
message.
The server shall negatively respond if the DTCMaskRecord, UserDefDTCSnapshotRecordNumber,
UserDefMemory parameters specified by the client are invalid or not supported by the server. This is to
be differentiated from the case in which the DTCMaskRecord and/or
UserDefDTCSnapshotRecordNumber parameters specified by the client are indeed valid and supported
by the server for that specific memory, but have no DTCSnapshot data associated with it (e.g. because a
failure event never occurred for the specified DTC or record number). The server shall send the positive
response containing only the DTCAndStatusRecord [echo of the requested DTC number (high, middle,
and low byte) plus the statusOfDTC].
DTCSnapshot information shall be cleared upon a manufacturer specific conditions (e.g a routine
control) request from the client. It is in the responsibility of the vehicle manufacturer to specify the
rules for the deletion of stored DTCs and DTCSnapshot data in case of a memory overflow (memory
space for stored DTCs and DTCsnapshot data completely occupied in the server for that specific
memory).
12.3.1.19Retrieving user defined memory DTCExtendedData record data for a client defined DTC mask and a client defined DTCExtendedData record number out of the DTC memory (SubFunction = 0x19 reportUserDefMemoryDTCExtDataRecordByDTCNumber)
A client can retrieve DTCExtendedData for a client defined DTCMaskRecord in conjunction with a
DTCExtendedData record number and a UserDefMemoryIdenitfier by sending a request for this service
with the SubFunction set to reportUserDefMemoryDTCExtDataRecordByDTCNumber. The server shall
search through its supported DTCs for an exact match with the DTCMaskRecord specified by the client
[containing the DTC number (high, middle, and low byte)] and the UserDefMemoryIdentifier. In this
case the DTCExtDataRecordNumber parameter provided in the client’s request shall specify a particular
DTCExtendedData record of the specified DTC for which DTCExtendedData is being requested.
Along with the DTC number and statusOfDTC, the server shall return a single predefined
DTCExtendedData record in response to the client’s request (DTCExtDataRecordNumber unequal to 0xFE or 0xFF).
The vehicle manufacturer shall define format and content of the UserDefDTCExtDataRecord. The
structure of the data reported in the DTCExtDataRecord is defined by the DTCExtDataRecordNumber
for that specific user defined memory in a similar way to the definition of data within a record
DataIdentifier. Multiple DTCExtDataRecordNumbers and associated DTCExtDataRecords may be
included in the response. The usage of one or multiple DTCExtDataRecordNumbers allows for the
storage of different types of DTCExtDataRecords for a single DTC.
The server shall report one DTCExtendedData record in a single response message, except the client has
set the DTCExtDataRecordNumber to FE16 or FF16, because this shall cause the server to response with
all DTCExtendedData records stored for the client defined DTCMaskRecord out of the user defined
memory in a single response message.
The server shall negatively respond if the DTCMaskRecord or DTCExtDataRecordNumber parameters
specified by the client are invalid or not supported by the server or not in that specific memory. This
shall be differentiated from the case in which the DTCMaskRecord and/or DTCExtDataRecordNumber parameters specified by the client are indeed valid and supported by the server, but have no DTC
extended data associated with it (e.g. because of memory overflow of the extended data). In case of
reportDTCExtDataRecordByDTCNumber the server shall send the positive response containing only the
DTCAndStatusRecord [echo of the requested DTC number (high, middle, and low byte) plus the
statusOfDTC].
DTCExtendedDataRecord information shall be cleared upon a manufacturer specific conditions by
either a service 1416 ClearDiagnosticInformation with the memorySelection parameter set to the
applicable memory or by a routine control request from the client.
12.3.1.20Retrieving the list of all DTCs that supports an specific DTCExtendedDataRecord (SubFunction = 0x1A reportSupportedDTCExtDataRecord)
A client can retrieve the list of all DTCs that supports a specific DTCExtendedDataRecord by sending a
request for this service with the SubFunction set to reportDTCExtendedDatatIdentification. The server
shall search through its supported DTCs. If a DTC support the requested
DTCExtendedDataRecordNumber it should be included in the response. Along with the DTC number(s)
and the statusOfDTC, the server shall return the DTCExtendedDataRecordNumber for that DTC(s). The
server shall negatively respond if the DTCExtendedDataRecord parameter specified by the client is
invalid or not supported by the server.
12.3.1.21Retrieving the list of VOBD DTCs from a functional group that match a client defined status mask (SubFunction = 0x42 reportWWHOBDDTCByMaskRecord)
The implementation and usage of DTCSeverityMask (with severity and class) is defined in ISO 27145-3[22]
.
12.3.1.22Retrieving a list of VOBD DTCs with "permanent DTC" status (SubFunction = 0x55 reportWWHOBDDTCWithPermanentStatus)
The client can retrieve a list of VOBD DTCs with the "permanent DTC" status as described in 3.12.
12.3.1.23Retrieve DTC information for a client defined DTCReadinessGroupIdentifier (SubFunction = 0x56 reportDTCInformationByDTCReadinessGroupIdentifier)
A client can retrieve DTC information for a client defined DTC Readiness Group Identifier by sending a
request of this service with the SubFunction set to
reportDTCInformationByDTCReadinessGroupIdentifer. The server shall search through its supported
DTCs for an exact match with the DTCReadinessGroupIdentifier specified by the client. Along with the
DTC number(s) and the statusOfDTC, the server shall return the DTCReadinessGroupIdentifier for those
DTCs.
The server shall negatively respond if the DTCReadinessGroupIdentifier parameter specified by the
client is invalid or not supported by the server.
12.3.2 Request message
12.3.2.1 Request message definition
Table 302 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 302 — Request message definition - SubFunction = reportNumberOfDTCByStatusMask, reportDTCByStatusMask |
Table 303 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 303 — Request message definition - SubFunction = reportDTCSnapshotIdentification, reportDTCSnapshotRecordByDTCNumber |
Table 304 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 304 — Request message definition - SubFunction = reportDTCStoredDataByRecordNumber |
Table 305 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 305 — Request message definition - SubFunction = reportDTCExtDataRecordByDTCNumber |
Table 306 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 306 — Request message definition - SubFunction = reportNumberOfDTCBySeverityMaskRecord, reportDTCSeverityInformation |
Table 307 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 307 — Request message definition - SubFunction = reportSeverityInformationOfDTC |
Table 308 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 308 — Request message definition - SubFunction = reportSupportedDTC, reportFirstTestFailedDTC, reportFirstConfirmedDTC, reportMostRecentTestFailedDTC, reportMostRecentConfirmedDTC, reportDTCFaultDetectionCounter, reportDTCWithPermanentStatus |
Table 309 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 309 — Request message definition - SubFunction = reportDTCExtDataRecordByRecordNumber |
Table 310 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 310 — Request message definition - SubFunction = reportUserDefMemoryDTCByStatusMask |
Table 311 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 311 — Request message definition - SubFunction = reportUserDefMemoryDTCSnapshotRecordByDTCNumber |
Table 312 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 312 — Request message definition - SubFunction = reportUserDefMemoryDTCExtDataRecordByDTCNumber |
Table 313 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 313 — Request message definition - SubFunction = reportSupportedDTCExtDataRecord |
Table 314 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 314 — Request message definition - SubFunction = reportWWHOBDDTCByMaskRecord |
Table 315 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 315 — Request message definition - SubFunction = reportWWHOBDDTCWithPermanentStatus |
Table 316 specifies the structure of the ReadDTCInformation request message based on the used
SubFunction parameter.
 |
Table 316 — Request message definition - SubFunction = reportDTCInformationByDTCReadinessGroupIdentifier |
12.3.2.2 Request message SubFunction parameter $Level (LEV_) definition
The SubFunction parameters are used by this service to select one of the DTC report types specified in
Table 317. Explanations and usage of the possible levels are detailed below
(suppressPosRspMsgIndicationBit (bit 7) not shown).
 |
Table 317 — Request message SubFunction definition |
12.3.2.3 Request message data-parameter definition
Table 318 specifies the data-parameters of the request message.
 |
Table 318 — Request data-parameter definition |
12.3.3 Positive response message
12.3.3.1 Positive response message definition
Positive response(s) to the service ReadDTCInformation requests depend on the SubFunction in the
service request.
Table 319 specifies the positive response message format of the SubFunction parameter.
 |
Table 319 — Response message definition - SubFunction = reportNumberOfDTCByStatusMask, reportNumberOfDTCBySeverityMaskRecord |
Table 320 specifies the positive response message format of the SubFunction parameter.
 |
Table 320 — Response message definition - SubFunction = reportDTCByStatusMask, reportSupportedDTCs, reportFirstTestFailedDTC, reportFirstConfirmedDTC, reportMostRecentTestFailedDTC, reportMostRecentConfirmedDTC, reportDTCWithPermanentStatus |
Table 321 specifies the positive response message format of the SubFunction parameter.
 |
Table 321 — Response message definition - SubFunction = reportSnapshotIdentification |
Table 322 specifies the positive response message format of the SubFunction parameter.
 |
Table 322 — Response message definition - SubFunction = reportDTCSnapshotRecordByDTCNumber |
Table 323 specifies the positive response message format of the SubFunction parameter.
 |
Table 323 — Response message definition - SubFunction = reportDTCStoredDataByRecordNumber |
Table 324 specifies the positive response message format of the SubFunction parameter.
 |
Table 324 — Response message definition - SubFunction = reportDTCExtDataRecordByDTCNumber |
Table 325 specifies the positive response message format of the SubFunction parameter.
 |
Table 325 — Response message definition - SubFunction = reportDTCBySeverityMaskRecord, reportSeverityInformationOfDTC |
Table 326 specifies the positive response message format of the SubFunction parameter.
 |
Table 326 — Response message definition - SubFunction = reportDTCFaultDetectionCounter |
Table 327 specifies the positive response message format of the SubFunction parameter.
 |
Table 327 — Response message definition - SubFunction = reportDTCExtDataRecordByRecordNumber |
Table 328 specifies the positive response message format of the SubFunction parameter.
 |
Table 328 — Response message definition - SubFunction = reportUserDefMemoryDTCByStatusMask |
Table 329 specifies the positive response message format of the SubFunction parameter.
 |
Table 329 — Response message definition - SubFunction = reportUserDefMemoryDTCSnapshotRecordByDTCNumber |
Table 330 specifies the positive response message format of the SubFunction parameter.
 |
Table 330 — Response message definition - SubFunction = reportUserDefMemoryDTCExtDataRecordByDTCNumber |
Table 331 specifies the positive response message format of the SubFunction parameter.
 |
Table 331 — Response message definition - SubFunction = reportSupportedDTCExtDataRecord |
Table 332 specifies the positive response message format of the SubFunction parameter.
 |
Table 332 — Response message definition - SubFunction = reportWWHOBDDTCByMaskRecord |
Table 333 specifies the positive response message format of the SubFunction parameter.
 |
Table 333 — Response message definition - SubFunction = reportWWHOBDDTCWithPermanentStatus |
Table 334 specifies the positive response message format of the SubFunction parameter.
 |
Table 334 — Response message definition - SubFunction = reportDTCByReadinessGroupIdentifier |
12.3.3.2 Positive response message data-parameter definition
Table 335 specifies the data-parameters of the positive response message.
 |
Table 335 — Response data-parameter definition |
12.3.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 336. The listed negative responses
shall be used if the error scenario applies to the server.
 |
Table 336 — Supported negative response codes |
12.3.5 Message flow examples – ReadDTCInformation
12.3.5.1 General asumption
For all examples the client requests to have a response message by setting the
suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
12.3.5.2 Example #1 - ReadDTCInformation, SubFunction = reportNumberOfDTCByStatusMask
12.3.5.2.1 Example #1 overview
This example demonstrates the usage of the reportNumberOfDTCByStatusMask SubFunction parameter
for confirmed DTCs (DTC status mask 0x08), as well as various masking principles. The
DTCStatusAvailabilityMask for this sever = 0x2F.
12.3.5.2.2 Example #1 assumptions
The server supports a total of three DTCs (for the sake of simplicity), which have the following states at
the time of the client request.
The following assumptions apply to DTC P0805-11 Clutch Position Sensor - circuit short to ground
(0x080511), statusOfDTC 0x24 (0010 0100b).
Table 337 specifies the statusOfDTC = 0x24 of DTC P0805-11.
 |
Table 337 — statusOfDTC = 2416 of DTC P0805-11 |
The following assumptions apply to DTC P0A9B-17 Hybrid Battery Temperature Sensor - circuit voltage
above threshold (0x0A9B17), statusOfDTC of 0x26 (0010 0110b).
Table 338 specifies the statusOfDTC = 0x26 of DTC P0A9B-17.
 |
Table 338 — statusOfDTC = 2616 of DTC P0A9B-17 |
The following assumptions apply to DTC P2522-1F A/C Request “B” - circuit intermittent (0x25221F),
statusOfDTC of 0x2F (0010 1111b).
Table 339 specifies the statusOfDTC = 0x2F of DTC P2522-1F.
 |
Table 339 — statusOfDTC = 2F16 of DTC P2522-1F |
12.3.5.2.3 Example #1 message flow
In the following example, a count of one is returned to the client because only DTC P2522-1F A/C
Request “B” - circuit intermittent (0x25221F), statusOfDTC of 0x2F (0010 1111b) matches the client
defined status mask of 0x08 (0000 1000b).
Table 340 specifies the ReadDTCInformation, SubFunction = reportNumberOfDTCByStatusMask,
request message flow example #1.
 |
Table 340 — ReadDTCInformation, SubFunction = reportNumberOfDTCByStatusMask, request message flow example #1 |
Table 341 specifies the ReadDTCInformation, SubFunction = reportNumberOfDTCByStatusMask,
positive response, example #1.
 |
Table 341 — ReadDTCInformation, SubFunction = reportNumberOfDTCByStatusMask, positive response, example #1 |
12.3.5.3 Example #2 - ReadDTCInformation, SubFunction = reportDTCByStatusMask, matching DTCs returned
12.3.5.3.1 Example #2 overview
This example demonstrates usage of the reportDTCByStatusMask SubFunction parameter, as well as
various masking principles in conjunction with unsupported masking bits. This example also applies to
the SubFunction parameter reportUserDefMemoryDTCByStatusMask, except that the status mask
checks are performed with the DTCs stored in the user defined memory.
12.3.5.3.2 Example #2 assumptions
The server supports all status bits for masking purposes, except for bit 7 “warningIndicatorRequested”.
The server supports a total of three DTCs (for the sake of simplicity), which have the following states at
the time of the client request.
The following assumptions apply to DTC P0A9B-17 Hybrid Battery Temperature Sensor - circuit voltage
above threshold (0x0A9B17), statusOfDTC 0x24 (0010 0100b).
Table 342 specifies the statusOfDTC= 0x24 of DTC P0A9B-17.
 |
Table 342 — statusOfDTC= 2416 of DTC P0A9B-17 |
The following assumptions apply to DTC P2522-1F A/C Request “B” - circuit intermittent (0x25221F),
statusOfDTC of 0x00 (0000 0000b).
Table 343 specifies the statusOfDTC = 0x00 of DTC P2522-1F.
 |
Table 343 — statusOfDTC = 0016 of DTC P2522-1F |
The following assumptions apply to DTC P0805-11 Clutch Position Sensor - circuit short to ground
(0x080511), statusOfDTC of 0x2F (0010 1111b).
Table 344 specifies the statusOfDTC = 0x2F of DTC P0805-11.
 |
Table 344 — statusOfDTC = 0x2F of DTC P0805-11 |
12.3.5.3.3 Example #2 message flow
In the following example, DTCs P0A9B-17 (0x0A9B17) and P0805-11 (0x080511) are returned to the
client’s request. DTC P2522-1F (0x25221F) is not returned because its status of 0x00 does not match the
DTCStatusMask of 0x84 (as specified in the client request messsage in the following example). The
server shall bypass masking on those status bits it does not support.
Table 345 specifies the ReadDTCInformation, SubFunction = reportDTCByStatusMask, request message
flow example #2.
 |
Table 345 — ReadDTCInformation, SubFunction = reportDTCByStatusMask, request message flow example #2 |
Table 346 specifies the ReadDTCInformation, SubFunction = reportDTCByStatusMask, positive
response, example #2.
 |
Table 346 — ReadDTCInformation, SubFunction = reportDTCByStatusMask, positive response, example #2 |
12.3.5.4 Example #3 - ReadDTCInformation, SubFunction = reportDTCByStatusMask, no matching DTCs returned
12.3.5.4.1 Example #3 overview
This example demonstrates usage of the reportDTCByStatusMask SubFunction parameter, in the
situation where no DTCs match the client defined DTCStatusMask.
12.3.5.4.2 Example #3 assumptions
The server supports all status bits for masking purposes, except for bit 7 “warningIndicatorRequested”.
The server supports a total of two DTCs (for the sake of simplicity), which have the following states at
the time of the client request.
The following assumptions apply to DTC P2522-1F A/C Request “B” - circuit intermittent (0x25221F),
statusOfDTC 0x24 (0010 0100b).
Table 347 specifies the statusOfDTC= 0x24 of DTC P2522-1F.
 |
Table 347 — statusOfDTC= 0x24 of DTC P2522-1F |
The following assumptions apply to DTC P0A9B-17 Hybrid Battery Temperature Sensor - circuit voltage
above threshold (0x0A9B17), statusOfDTC of 0x00 (0000 0000b).
Table 348 specifies the statusOfDTC = 0x00 of DTC P0A9B-17.
 |
Table 348 — statusOfDTC = 0x00 of DTC P0A9B-17 |
The client requests the server to reportByStatusMask all DTCs having bit 0 (TestFailed) set to logical ‘1’.
12.3.5.4.3 Example #3 message flow
In the following example, none of the above DTCs are returned to the client’s request because none of
the DTCs has failed the test at the time of the request.
Table 349 specifies the ReadDTCInformation, SubFunction = reportDTCByStatusMask, request message
flow example #3.
 |
Table 349 — ReadDTCInformation, SubFunction = reportDTCByStatusMask, request message flow example #3 |
Table 350 specifies the ReadDTCInformation, SubFunction = reportDTCByStatusMask, positive
response, example #3.
 |
Table 350 — ReadDTCInformation, SubFunction = reportDTCByStatusMask, positive response, example #3 |
12.3.5.5 Example #4 - ReadDTCInformation, SubFunction = reportDTCSnapshotIdentification
12.3.5.5.1 Example #4 overview
This example demonstrates the usage of the reportDTCSnapshotIdentification SubFunction parameter.
12.3.5.5.2 Example #4 assumptions
The following assumptions apply:
- The server supports the ability to store two DTCSnapshot records for a given DTC.
- The server shall indicate that two DTCSnapshot records are currently stored for DTC number 0x123456. For the purpose of this example, assume that this DTC had occurred three times (such that only the first and most recent DTCSnapshot records are stored because of lack of storage space within the server).
- The server shall indicate that one DTCSnapshot record is currently stored for DTC number 0x789ABC.
- All DTCSnapshot records are stored in ascending order.
12.3.5.5.3 Example #4 message flow
In the following example, three DTCSnapshot records are returned to the client’s request.
Table 351 specifies the ReadDTCInformation, SubFunction = reportDTCSnapshotIdentification, request
message flow example #4.
 |
Table 351 — ReadDTCInformation, SubFunction = reportDTCSnapshotIdentification, request message flow example #4 |
Table 352 specifies the ReadDTCInformation, SubFunction = reportDTCSnapshotIdentification, positive
response, example #4.
 |
Table 352 — ReadDTCInformation, SubFunction = reportDTCSnapshotIdentification, positive response, example #4 |
12.3.5.6 Example #5 - ReadDTCInformation, SubFunction = reportDTCSnapshotRecordByDTCNumber
12.3.5.6.1 Example #5 overview
This example demonstrates the usage of the reportDTCSnapshotRecordByDTCNumber SubFunction
parameter. This example also applies to the SubFunction parameter reportUserDefMemoryDTCSnapshotRecordByDTCNumber, except that the checks are performed with the DTCs stored in the
user defined memory.
12.3.5.6.2 Example #5 assumptions
The following assumptions apply:
- The server supports the ability to store two DTCSnapshot records for a given DTC.
- This example assumes a continuation of the previous example.
- Assume that the server requests the second of the two DTCSnapshot records stored by the server for DTC number 0x123456 (see previous example, where a DTCSnapshotRecordCount of 0x02 is returned to the client).
- Assume that DTC 0x123456 has a statusOfDTC of 0x24, and that the following environment data is captured each time a DTC occurs.
- The DTCSnapshot record data is referenced via the dataIdentifier 0x4711.
Table 353 specifies the DTCSnapshot record content.
 |
Table 353 — DTCSnapshot record content |
12.3.5.6.3 Example #5 message flow
In the following example, one DTCSnapshot record is returned in accordance to the client’s
reportDTCSnapshotRecordByDTCNumber request.
Table 354 specifies the ReadDTCInformation, SubFunction = reportDTCSnapshotRecordByDTCNumber,
request message flow example #5.
 |
Table 354 — ReadDTCInformation, SubFunction = reportDTCSnapshotRecordByDTCNumber, request message flow example #5 |
Table 355 specifies the ReadDTCInformation, SubFunction = reportDTCSnapshotRecordByDTCNumber,
positive response, example #5.
 |
Table 355 — ReadDTCInformation, SubFunction = reportDTCSnapshotRecordByDTCNumber, positive response, example #5 |
12.3.5.7 Example #6 - ReadDTCInformation, SubFunction = reportDTCStoredDataByRecordNumber
12.3.5.7.1 Example #6 overview
This example demonstrates the usage of the reportDTCStoredDataByRecordNumber SubFunction
parameter.
12.3.5.7.2 Example #6 assumptions
The following assumptions apply:
- The server supports the ability to store two DTCStoredDataRecords for a given DTC.
- This example assumes a continuation of the previous example.
- Assume that the server requests the second of the two DTCStoredDataRecords stored by the server for DTC number 0x123456 (see previous example, where a DTCStoredDataRecordCount of two is returned to the client).
- Assume that DTC 0x123456 has a statusOfDTC of 0x24, and that the following environment data is captured each time a DTC occurs.
- The DTCStoredData record data is referenced via the dataIdentifier 0x4711.
Table 356 specifies the DTCStoredData record content.
 |
Table 356 — DTCStoredData record content |
12.3.5.7.3 Example #6 message flow
In the following example, DTCStoredData record number two is requested and the server returns the
DTC and DTCStoredData record content.
Table 357 specifies the ReadDTCInformation, SubFunction = reportDTCStoredDataByRecordNumber,
request message flow example #6.
 |
Table 357 — ReadDTCInformation, SubFunction = reportDTCStoredDataByRecordNumber, request message flow example #6 |
Table 358 specifies the ReadDTCInformation, SubFunction = reportDTCStoredDataByRecordNumber,
positive response, example #6.
 |
Table 358 — ReadDTCInformation, SubFunction = reportDTCStoredDataByRecordNumber, positive response, example #6 |
12.3.5.8 Example #7 - ReadDTCInformation, SubFunction = reportDTCExtDataRecordByDTCNumber
12.3.5.8.1 Example #7 overview
This example demonstrates the usage of the reportDTCExtDataRecordByDTCNumber SubFunction
parameter. This example also applies to the SubFunction parameter reportUserDefMemoryDTCExtDataRecordByDTCNumber, except that the checks are performed with the DTCs stored in the
user defined memory.
12.3.5.8.2 Example #7 assumptions
The following assumptions apply:
- The server supports the ability to store two DTCExtendedData records for a given DTC.
- Assume that the server requests all available DTCExtendedData records stored by the server for DTC number 0x123456.
- Assume that DTC 0x123456 has a statusOfDTC of 0x24, and that the following extended data is available for the DTC.
- The DTCExtendedData is referenced via the DTCExtDataRecordNumbers 0x05 and 0x10 (see Tables 359 and 360).
 |
Table 359 — DTCExtDataRecordNumber 0516 content |
 |
Table 360 — DTCExtDataRecordNumber 1016 content |
12.3.5.8.3 Example #7 message flow
In the following example, a DTCMaskRecord including the DTC number and a
DTCExtDataRecordNumber with the value of 0xFF (report all DTCExtDataRecords) is requested by the
client. The server returns two DTCExtDataRecords which have been recorded for the DTC number
submitted by the client.
Table 361 specifies the ReadDTCInformation, SubFunction = reportDTCExtDataRecordByDTCNumber,
request message flow example #7.
 |
Table 361 — ReadDTCInformation, SubFunction = reportDTCExtDataRecordByDTCNumber, request message flow example #7 |
Table 362 specifies the ReadDTCInformation, SubFunction = reportDTCExtDataRecordByDTCNumber,
positive response, example #7.
 |
Table 362 — ReadDTCInformation, SubFunction = reportDTCExtDataRecordByDTCNumber, positive response, example #7 |
12.3.5.9 Example #8 - ReadDTCInformation, SubFunction = reportNumberOfDTCBySeverityMaskRecord
12.3.5.9.1 Example #8 overview
This example demonstrates the usage of the reportNumberOfDTCBySeverityMaskRecord SubFunction
parameter.
12.3.5.9.2 Example #8 assumptions
The server supports a total of three DTCs which have the following states at the time of the client
request:
The following assumptions apply to DTC P0A9B-17 Hybrid Battery Temperature Sensor - circuit voltage
above threshold (0x0A9B17), statusOfDTC 0x24 (0010 0100b), DTCFunctionalUnit = 0x10, DTCSeverity = 0x20.
NOTE 1
Only bit 7 to 5 of the severity byte are valid.
Table 363 specifies the statusOfDTC = 0x24 of DTC P0A9B-17.
 |
Table 363 — statusOfDTC = 2416 of DTC P0A9B-17 |
The following assumptions apply to DTC P2522-1F A/C Request “B” - circuit intermittent (0x25221F),
statusOfDTC of 0x00 (0000 0000b), DTCFunctionalUnit = 0x10, DTCSeverity = 0x20.
NOTE 2
Only bit 7 to 5 of the severity byte are valid.
Table 364 specifies the statusOfDTC = 0x00 of DTC P2522-1F.
 |
Table 364 — statusOfDTC = 0016 of DTC P2522-1F |
The following assumptions apply to DTC P0805-11 Clutch Position Sensor - circuit short to ground
(0x080511), statusOfDTC of 0x2F (0010 1111b), DTCFunctionalUnit = 0x10, DTCSeverity = 0x40.
NOTE 3
Only bit 7 to 5 of the severity byte are valid.
Table 365 specifies the statusOfDTC = 0x2F of DTC P0805-11.
 |
Table 365 — statusOfDTC = 0x2F of DTC P0805-11 |
The server supports the testFailed and confirmedDTC status bits for masking purposes.
12.3.5.9.3 Example #8 message flow
In the following example, a count of one is returned to the client because DTC P0805-11 (0x080511)
match the client defined severity mask record of 0xC001 (DTCSeverityMask = 0x11 xxxxb = 0xC0,
DTCStatusMask = 0000 0001b).
Table 366 specifies the ReadDTCInformation, SubFunction =
reportNumberOfDTCBySeverityMaskRecord, request message flow example #8.
 |
Table 366 — ReadDTCInformation, SubFunction = reportNumberOfDTCBySeverityMaskRecord, request message flow example #8 |
Table 367 specifies the ReadDTCInformation, SubFunction =
reportNumberOfDTCBySeverityMaskRecord, positive response, positive response, example #8.
 |
Table 367 — ReadDTCInformation, SubFunction = reportNumberOfDTCBySeverityMaskRecord, positive response, example #8 |
12.3.5.10Example #9 - ReadDTCInformation, SubFunction = reportDTCBySeverityMaskRecord
12.3.5.10.1Example #9 overview
This example demonstrates the usage of the reportDTCBySeverityMaskRecord SubFunction parameter.
12.3.5.10.2Example #9 assumptions
The assumptions defined in 11.3.5.9.2 and those defined in this subclause apply.
In the following example, the DTC P0805-11 (0x080511) match the client defined severity mask record
of 0xC001 (DTCSeverityMask = 0xC0 = 110x XXXXb, DTCStatusMask = 0x01, 0000 0001b) and is reported
to the client. The severity of DTC P0805-11 (0x080511) is 0x40 (010x XXXXb). The server supports all
status bits for masking purposes, except for bit 7 “warningIndicatorRequested”.
NOTE
Only bit 7 to 5 of the severity mask byte are valid.
12.3.5.10.3Example #9 message flow
In the following example, one DTCSeverityRecord is returned to the client’s request.
Table 368 specifies the ReadDTCInformation, SubFunction = reportDTCBySeverityMaskRecord, request
message flow example #9.
 |
Table 368 — ReadDTCInformation, SubFunction = reportDTCBySeverityMaskRecord, request message flow example #9 |
Table 369 specifies the ReadDTCInformation, SubFunction = reportDTCBySeverityMaskRecord, positive
response example #9.
 |
Table 369 — ReadDTCInformation, SubFunction = reportDTCBySeverityMaskRecord, positive response, example #9 |
12.3.5.11Example #10 - ReadDTCInformation, SubFunction = reportSeverityInformationOfDTC
12.3.5.11.1Example #10 overview
This example demonstrates the usage of the reportSeverityInformationOfDTC SubFunction parameter.
12.3.5.11.2Example #10 assumptions
The assumptions defined in 11.3.5.10.2 apply.
12.3.5.11.3Example #10 message flow
In the following example, the DTC P0805-11 (0x080511), which matches the client defined DTC mask
record, is reported to the client.
Table 370 specifies ReadDTCInformation, SubFunction = reportSeverityInformationOfDTC, request
message flow example #10.
 |
Table 370 — ReadDTCInformation, SubFunction = reportSeverityInformationOfDTC, request message flow example #10 |
Table 371 specifies ReadDTCInformation, SubFunction = reportSeverityInformationOfDTC, positive
response, example #10.
 |
Table 371 — ReadDTCInformation, SubFunction = reportSeverityInformationOfDTC, positive response, example #10 |
12.3.5.12Example #11 – ReadDTCInformation - SubFunction = reportSupportedDTCs
12.3.5.12.1Example #11 overview
This example demonstrates the usage of the reportSupportedDTCs SubFunction parameter.
12.3.5.12.2Example #11 assumptions
The assumptions defined in 12.3.5.10.2 apply. Besides the following assumptions apply:
- The server supports a total of three DTCs (for the sake of simplicity), which have the following states at the time of the client request.
- The following assumptions apply to DTC 0x123456, statusOfDTC 0x24 (0010 0100b), see Table 372.
 |
Table 372 — statusOfDTC = 0x24 |
The following assumptions apply to DTC 0x234505, statusOfDTC of 0x00 (0000 0000b), see Table 373.
 |
Table 373 — statusOfDTC = 0x00 |
The following assumptions apply to DTC 0xABCD01, statusOfDTC of 0x2F (0010 1111b), see Table 374.
 |
Table 374 — statusOfDTC = 2F |
12.3.5.12.3Example #11 message flow
In the following example, all three of the above DTCs are returned to the client’s request because all are
supported.
Table 375 specifies ReadDTCInformation, SubFunction = reportSupportedDTCs, request message flow
example #11.
 |
Table 375 — ReadDTCInformation, SubFunction = reportSupportedDTCs, request message flow example #11 |
Table 376 specifies ReadDTCInformation, SubFunction = readSupportedDTCs, positive response,
example #11.
 |
Table 376 — ReadDTCInformation, SubFunction = readSupportedDTCs, positive response, example #11 |
12.3.5.13Example #12 - ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, information available
12.3.5.13.1Example #12 overview
This example demonstrates usage of the reportFirstTestFailedDTC SubFunction parameter, where it is
assumed that at least one failed DTC occurred since the last ClearDiagnosticInformation request from
the server.
If exactly one DTC failed within the server since the last ClearDiagnosticInformation request from the
server, then the server would return the same information in response to a
reportMostRecentTestFailedDTC request from the client.
In this example, the status of the DTC returned in response to the reportFirstTestFailedDTC is no longer
current at the time of the request (the same phenomenon is possible when requesting the server to
report the most recent failed/confirmed DTC).
The general format of request/response messages in the following example is also applicable to
SubFunction parameters reportFirstConfirmedDTC, reportMostRecentTestFailedDTC, and
reportMostRecent-ConfirmedDTC (for the appropriate DTC status and under similar assumptions).
12.3.5.13.2Example #12 assumptions
The following assumptions apply:
- At least one DTC failed since the last ClearDiagnosticInformation request from the server.
- The server supports all status bits for masking purposes.
- DTC number 0x123456 = first failed DTC to be detected since the last code clear.
- The following assumptions apply to DTC 0x123456, statusOfDTC 0x26 (0010 0110b), see Table 377:
 |
Table 377 — statusOfDTC = 0x26 |
12.3.5.13.3Example #12 message flow
In the following example DTC 0x123456 is returned to the client’s request, see Table 378.
 |
Table 378 — ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, request message flow example #12 |
Table 379 specifies ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, positive response,
example #12.
 |
Table 379 — ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, positive response, example #12 |
12.3.5.14Example #13 - ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, no information available
12.3.5.14.1Example #13 overview
This example demonstrates usage of the reportFirstTestFailedDTC SubFunction parameter, where it is
assumed that no failed DTCs have occurred since the last ClearDiagnosticInformation request from the
server.
The general format of request/response messages in the following example is also applicable to
SubFunction parameters reportFirstConfirmedDTC, reportMostRecentTestFailedDTC, and
reportMostRecentConfirmedDTC (for the appropriate DTC status and under similar assumptions).
12.3.5.14.2Example #13 assumptions
The following assumptions apply:
- No failed DTCs have occurred since the last ClearDiagnosticInformation request from the server.
- The server supports all status bits for masking purposes.
12.3.5.14.3Example #13 message flow
In Table 380 no DTC is returned to the client’s request.
 |
Table 380 — ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, request message flow example #13 |
Table 381 specifies ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, positive response,
example #13.
 |
Table 381 — ReadDTCInformation, SubFunction = reportFirstTestFailedDTC, positive response, example #13 |
12.3.5.15Example #14 - ReadDTCInformation, SubFunction = reportDTCFaultDetectionCounter
12.3.5.15.1Example #14 overview
This example demonstrates the usage of the reportDTCFaultDetectionCounter SubFunction parameter.
12.3.5.15.2Example #14 assumptions
The following assumptions apply:
- The server supports FaultDetectionCounter for continuously executed monitors.
12.3.5.15.3Example #14 message flow
In the following example, the client requests DTCs which has not yet got the status “TestFailed”, i.e. they
are prefailed. The server returns one DTC with the status of preFailed to the Client.
Table 382 specifies the ReadDTCInformation, SubFunction = reportDTCFaultDetectionCounter, request
message flow example #14.
 |
Table 382 — ReadDTCInformation, SubFunction = reportDTCFaultDetectionCounter, request message flow example #14 |
Table 383 specifies the ReadDTCInformation, SubFunction = reportDTCFaultDetectionCounter, positive
response, example #14.
 |
Table 383 — ReadDTCInformation, SubFunction = reportDTCFaultDetectionCounter, positive response, example #14 |
12.3.5.16Example #15 - ReadDTCInformation, SubFunction = reportDTCExtDataRecordByRecordNumber
12.3.5.16.1Example #15 overview
This example demonstrates the usage of the reportDTCExtDataRecordByRecordNumber SubFunction
parameter.
12.3.5.16.2Example #15 assumptions
The following assumptions apply:
- a) The server supports the ability to store two DTCExtendedData records for all DTCs.
- b) Assume that the server requests all available DTCExtendedData records stored by the server for Record number 0x05.
- c) Assume that DTC 0x123456 has a statusOfDTC of 0x24, and that the following extended data is available for the DTC.
- d) The DTCExtendedData is referenced via the DTCExtDataRecordNumber 0x05
- e) Assume that DTC 0x234561 has a statusOfDTC of 0x24, and that the following extended data is available for the DTC.
- f) The DTCExtendedData is referenced via the DTCExtDataRecordNumber 0x05.
Table 384 specifies DTCExtDataRecordNumber 0x05 content for DTC 0x123456.
 |
Table 384 — DTCExtDataRecordNumber 0516 content for DTC 0x123456 |
 |
Table 385 — DTCExtDataRecordNumber 0516 content for DTC 234561 |
12.3.5.16.3 Example #15 message flow
In the following example, a DTCMaskRecord including the DTC number and a DTCExtDataRecordNumber with the value of 0x05 (report all DTCExtDataRecords) is requested by the client. The server returns two DTCs which have recorded the DTCExtDataRecordNumber submitted by the client.
Table 386 specifies ReadDTCInformation, SubFunction = reportDTCExtDataRecordByRecordNumber,request message flow example #15.
 |
Table 386 — ReadDTCInformation, SubFunction = reportDTCExtDataRecordByRecordNumber, request message flow example #15 |
Table 387 specifies ReadDTCInformation, SubFunction = reportDTCExtDataRecordByRecordNumber, positive response, example #15.
 |
Table 387 — ReadDTCInformation, SubFunction = reportDTCExtDataRecordByRecordNumber, positive response, example #15 |
12.3.5.17 Example #16 - ReadDTCInformation - SubFunction = reportDTCExtendedDataRecordIdentification
12.3.5.17.1Example #16 overview
This example demonstrates the usage of the reportDTCExtendedDataRecordIdentification SubFunction parameter.
12.3.5.17.2Example #16 assumptions
The assumptions defined in 12.3.5.10.2 apply. Besides the following assumptions apply:
- The server supports for three DTCs the DTCExtendedDataRecord 0x91 (DTC based IUMPR ), which have the same states like in example#11 at the time of the client request.
12.3.5.17.3Example #16 message flow
In the following example, all three of the above DTCs are returned to the client's request because all support DTCExtendedDataRecord 0x91.
Table 388 specifies ReadDTCInformation, SubFunction = reportDTCExtendedDataRecordIdentification, request message flow, example #16.
 |
Table 388 — ReadDTCInformation, SubFunction = reportDTCExtendedDataRecordIdentification, request message flow, example #16 |
Table 389 specifies ReadDTCInformation, SubFunction = reportDTCExtendedDataRecordIdentification, positive response, example #16.
 |
Table 389 — ReadDTCInformation, SubFunction = reportDTCExtendedDataRecordIdentification, positive response, example #16 |
12.3.5.18Example #17 - ReadDTCInformation, SubFunction = reportWWHOBDDTCByMaskRecord
12.3.5.18.1Example #17 overview
This example demonstrates the usage of the reportWWHOBDDTCByMaskRecord SubFunction parameter for confirmed DTCs (DTC status mask 0816). The vehicle uses a CAN bus which connects two emissions-related servers.
The client uses the following request parameter settings:
- FunctionalGroupIdentifier = 0x33 (emissions system group),
- DTCSeverityMaskRecord.DTCSeverityMask = 0xFF (report DTCs with any severity and Class status),
- DTCSeverityMaskRecord.DTCStatusMask = 0x08 (report DTCs with confirmedDTC status = '1').
The servers support the following settings:
- FunctionalGroupIdentifier = 0x33 (emissions system group),
- DTCStatusAvailabilityMask = 0xFF,
- DTCSeverityAvailabilityMask = 0xFF,
- DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_04 = 0x04.
12.3.5.18.2Example #17 assumptions
All assumptions of example #1 apply.
12.3.5.18.3Example #17 message flow
In the following example server #1 only reports DTC P2522-1F A/C Request "B" - circuit intermittent (0x25221F) because the statusOfDTC of 0x2F (0010 1111b) matches the client defined status mask of 0x08 (0000 1000b). Server #2 reports DTC P0235-12 Turbocharger/Supercharger Boost Sensor "A" - circuit short to battery because the statusOfDTC of 0x2E (0010 1110b) matches the client defined status mask of 0x08 (0000 1000b).
Table 390 specifies ReadDTCInformation request, SubFunction = reportNumberOfDTCByStatusMask.
 |
Table 390 — ReadDTCInformation request, SubFunction = reportNumberOfDTCByStatusMask |
Table 391 specifies ReadDTCInformation response, SubFunction = reportWWHOBDDTCByStatusMask.
 |
Table 391 — ReadDTCInformation response, SubFunction = reportWWHOBDDTCByStatusMask |
Table 392 specifies ReadDTCInformation response, SubFunction = reportOBDDTCByStatusMask.
 |
Table 392 — ReadDTCInformation response, SubFunction = reportOBDDTCByStatusMask |
12.3.5.19Example #18 - ReadDTCInformation, SubFunction = reportOBDDTCWithPermanentStatus, matching DTCs returned
12.3.5.19.1Example #18 overview
This example demonstrates usage of the reportWWHOBDDTCWithPermanentStatus SubFunction parameter. This example also applies to the SubFunction parameter reportPermanentDTC, except that the FunctionalGroupIdentifier is used in reportWWHOBDDTCWithPermanentStatus.
12.3.5.19.2Example #18 assumptions
The server supports four permanent DTCs to be stored.
The following assumptions apply to DTC P0805-11 Clutch Position Sensor - circuit short to ground (0x080511), statusOfDTC of 0x2F (0010 1111b). Since P0805-11 is emission relevant and illuminates MIL, it is also stored as a Permanent DTC.
Table 393 specifies the statusOfDTC = 0x2F of DTC P0805-11.
 |
Table 393 — statusOfDTC = 2F16 of DTC P0805-11 |
12.3.5.19.3Example #18 message flow
In the following example, DTC P0805-11 (0x080511) is returned to the client's request.
Table 394 specifies the ReadDTCInformation, SubFunction = reportWWHOBDDTCWithPermanentStatus, request message flow example #2.
 |
Table 394 — ReadDTCInformation, SubFunction = reportWWHOBDDTCWithPermanentStatus, request message flow example #2 |
Table 395 specifies the ReadDTCInformation, SubFunction = reportWWHOBDDTCWithPermanentStatus, positive response, example #2.
 |
Table 395 — ReadDTCInformation, SubFunction = reportWWHOBDDTCWithPermanentStatus, positive response, example #18 |
12.3.5.20Example #19 - ReadDTCInformation - SubFunction = reportDTCByReadinessGroupIdentifier
12.3.5.20.1Example #19 overview
This example demonstrates the usage of the reportDTCByReadinessGroupIdentifier SubFunction parameter.
12.3.5.20.2Example #19 assumptions
The assumptions defined in 12.3.5.10.2 apply. Besides the following assumptions apply:
- The server supports the DTCReadinessGroupIdentifier Comprehensive Components Monitoring Group (0x01) with three DTCs which have the same states like in example#11 at the time of the client request.
- This DTCs are part of the "emission system group" 0x33.
12.3.5.20.3 Example #19 message flow
In the following example, all three of the above DTCs are returned to the client's request because all belonging to ReadynessGroupID=0x01.
Table 396 specifies ReadDTCInformation, SubFunction = reportDTCByReadinessGroupIdentifier, request message flow, example #19.
 |
Table 396 — ReadDTCInformation, SubFunction = reportDTCByReadinessGroupIdentifier, request message flow, example #19 |
Table 397 specifies ReadDTCInformation, SubFunction = reportDTCByReadinessGroupIdentifier,positive response, example #19.
 |
Table 397 — ReadDTCInformation, SubFunction = reportDTCByReadinessGroupIdentifier, positive response, example #19 |
13 InputOutput control functional unit
13.1 Overview
Table 398 specifies the InputOutput Control functional unit.
 |
Table 398 — InputOutput Control functional unit |
13.2 InputOutputControlByIdentifier (0x2F) service
13.2.1 Service description
The InputOutputControlByIdentifier service is used by the client to substitute a value for an input signal, internal server function and/or force control to a value for an output (actuator) of an electronic system. In general, this service is used for relatively simple (e.g. static) input substitution/output control whereas routineControl is used if more complex input substitution/output control is necessary.
The client request message contains a dataIdentifier to reference the input signal, internal server function, and/or output signal(s) (actuator(s)) (in case of a device control access it might reference a group of signals) of the server. The controlOptionRecord parameter shall include all information required by the server's input signal(s), internal function(s) and/or output signal(s). The vehicle manufacturer may require that the request message contain a controlEnableMask if the dataIdentifier to be controlled references more than one parameter (i.e. the dataIdentifier is packeted or bitmapped). If the vehicle manafuacturer chooses to support the EnableMask concept, the controlEnableMask parameter is mandatory on all types of InputOutputControlByIdentifier requests for this service. If inputOutputControlByIdentifier is requested on a dataIdentifier that references a measured output value or feedback value, the server shall be responsible for substituting the correct target value within the server control strategy so that the normal server control strategy will attempt to reach the desired state from the client request message.
The server shall send a positive response message if the request control was successfully started or has reached its desired state. The server shall send a positive response message to a request message with an inputOutputControlParameter of returnControlToECU even if the dataIdentifier is currently not under tester control. In addition, when receiving a returnControlToECU request, a server shall always provide the client the capability of setting the controlMask (if supported) bits all to '1' in order to return control of a packeted or bit-mapped dataIdentifier completely back to the ECU. The format and length of the controlState bytes following the inputOutputControlParameter within the controlOptionRecord parameter of the request message shall exactly match the length and format of the dataRecord of the dataIdentifier being requested. This way it shall be ensured that the actual output or input state can be retrieved by using the service ReadDatabyIdentifier with the same DID.
When utilizing the inputOutputControlByIdentifier service to perform input substitution or output control, there are two fundamental requirements placed on the ECU accepting the request. The first is to disconnect the appropriate data object(s) referenced by the parameter(s) within the dataIdentifier from all upstream control strategies that would otherwise update the data object value. The second is to substitute a value into the appropriate data object(s) that will be used for all downstream activities of the control strategy. For example, a tester request to directly force the headlamps on would need to prevent the headlamp switch position from affecting the headlamp output and substitute the desired state of "On" into the data object(s) used by the functions which ultimately decide the headlamp state desired output
The service allows the control of a single dataIdentifier and its corresponding parameter(s) in a single request message. Doing so, the server will respond with a single response message including the dataIdentifier of the request message plus controlStatus information.
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
13.2.2 Request message
13.2.2.1 Request message definition
Table 399 specifies the request message.
 |
Table 399 — Request message definition |
13.2.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
13.2.2.3 Request message data-parameter definition
The following data-parameters (Table 400) are defined for this service:
 |
Table 400 — Request message data-parameter definition |
13.2.3 Positive response message
13.2.3.1 Positive response message definition
Table 401 specifies Positive response message definition.
 |
Table 401 — Positive response message definition |
13.2.3.2 Positive response message data-parameter definition
Table 402 specifies Response message data-parameter definition.
 |
Table 402 — Response message data-parameter definition |
13.2.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 403. The listed negative responses shall be used if the error scenario applies to the server.
 |
Table 403 — Supported negative response codes |
The evaluation sequence is documented in Figure 29.
 |
Figure 29 — NRC handling for InputOutputControlByIdentifier service |
13.2.5 Message flow example(s) InputOutputControlByIdentifier
13.2.5.1 Assumptions
The example below shows how the InputOutputControlByIdentifier is used with an HVAC Control Module and assumes that physical communication is performed with a single server
13.2.5.2 Example #1 - "Air Inlet Door Position" shortTermAdjustment
The parameter being controlled is the "Air Inlet Door Position" associated with dataIdentifier (0x9B00). Conversion: Air Inlet Door Position [%] = decimal(Hex) * 1 [%]
13.2.5.2.1 Step #1: ReadDataByIdentifier
Table 404 to Table 413 specifies an example which uses the ReadDataByIdentifier service to read the current state of the Air Inlet Door Position.
 |
Table 404 — ReadDataByIdentifier request message flow example #1 - step #1 |
 |
Table 405 — ReadDataByIdentifier positive response message flow example #1 - step #1 |
13.2.5.2.2 Step #2: shortTermAdjustment
 |
Table 406 — InputOutputControlByIdentifier request message flow example #1 - step #2 |
 |
Table 407 — InputOutputControlByIdentifier positive response message flow example #1 - step #2 |
NOTE
The client has sent an inputOutputControlByIdentifier request message as specified above. The server has sent an immediate positive response message, which includes the controlState parameter "Air Inlet Door Position" with the value of 12 %. The air inlet door requires a certain amount of time to move to the requested value of 60 %.
13.2.5.2.3 Step #3: ReadDataByIdentifier
This example uses the readDataByIdentifier service to read the current state of the Air Inlet Door Position.
 |
Table 408 — ReadDataByIdentifier request message flow example #1 - step #3 |
 |
Table 409 — ReadDataByIdentifier positive response message flow example #1 - step #3 |
NOTE
The client has sent a readDataByIdentifier request message as specified above while inputOutputControlByIdentifier is active. It will take a finite amount of time for the server control strategy to ultimately reach the desired value. The example above reflects when the server has finally reached the desired target value.
13.2.5.2.4 Step #4: returnControlToECU
 |
Table 410 — InputOutputControlByIdentifier request message flow example #1 - step #4 |
 |
Table 411 — InputOutputControlByIdentifier positive response message flow example #1 - step #4 |
13.2.5.2.5 Step #5: freezeCurrentState
 |
Table 412 — InputOutputControlByIdentifier request message flow example #1 - step #5 |
 |
Table 413 — InputOutputControlByIdentifier positive response message flow example #1 - step #5 |
13.2.5.3 Example #2 - EGR and IAC shortTermAdjustment
13.2.5.3.1 Assumptions
This example uses a packeted dataIdentifier 0x0155 to demonstrate control of individual parameters or multiple parameters within a single request.
This subclause specifies the test conditions for a shortTermAdjustment function and the associated message flow of the example dataIdentifier 0x0155. The dataIdentifier supports five individual parameters as described in Table 414 below.
 |
Table 414 — Composite data blocks – DataIdentifier definitions – Example #2 |
DataIdentifier 0x0155 is packeted by definition and is comprised of five elemental parameters. For individual control purposes, each of these elemental parameters is selectable via a single bit within the ControlEnableMaskRecord. If a given dataIdentifier has a definition other than packeted or bitmapped, the ControlEnableMaskRecord is not present in the request message. The most significant bit of ControlMask#1 is always required to correspond to the first parameter in the dataIdentifier starting at the most significant bit of ControlState#1. This is demonstrated in Table 415.
 |
Table 415 — ControlEnableMaskRecord– Example #2 |
13.2.5.3.2 Case #1: Control IAC Pintle Position only
Table 416 specifies the InputOutputControlByIdentifier request message flow example #2 - Case #1.
 |
Table 416 — InputOutputControlByIdentifier request message flow example #2 – Case #1 |
NOTE
The values transmitted for RPM, Pedal Position A, Pedal Position B, and EGR Duty Cycle in controlState#2 - #5 are irrelevant because the controlMask#1 parameter specifies that only the first parameter in the dataIdentifier will be affected by the request.
Table 417 specifies the InputOutputControlByIdentifier positive response message flow example #2 - Case #1.
 |
Table 417 — InputOutputControlByIdentifier positive response message flow example #2 – Case #1 |
The value transmitted for all parameters in controlState#1 - controlState#5 shall reflect the current state of the system.
13.2.5.3.3 Case #2: Control RPM Only
Table 418 specifies the InputOutputControlByIdentifier request message flow example #2 - Case #2.
 |
Table 418 — InputOutputControlByIdentifier request message flow example #2 – Case #2 |
NOTE
The values transmitted for IAC Pintle Position, Pedal Position A, Pedal Position B, and EGR Duty Cycle in controlState#1 and controlState#4 - #5 are irrelevant because the controlMask#1 parameter specifies that only the second parameter in the dataIdentifier will be affected by the request.
Table 419 specifies the InputOutputControlByIdentifier positive response message flow example #2 - Case #2.
 |
Table 419 — InputOutputControlByIdentifier positive response message flow example #2 – Case #2 |
The value transmitted for all parameters in controlState#1 - controlState#5 shall reflect the current state of the system.
13.2.5.3.4 Case #3: Control both Pedal Position A and EGR Duty Cycle
Table 420 specifies the InputOutputControlByIdentifier request message flow example #2 - Case #3.
 |
Table 420 — InputOutputControlByIdentifier request message flow example #2 – Case #3 |
NOTE
The values transmitted for IAC Pintle Position, RPM and Pedal Position B in controlState#1 - #3 and controlState#4 (bits 3 to 0) are irrelevant because the controlMask#1 parameter specifies that only the third and fifth parameter in the dataIdentifier will be affected by the request.
Table 421 specifies the InputOutputControlByIdentifier positive response message flow example #2 - Case #3.
 |
Table 421 — InputOutputControlByIdentifier positive response message flow example #2 – Case #3 |
The value transmitted for all parameters in controlState#1 - controlState#5 shall reflect the current state of the system.
13.2.5.3.5 Case #4: Return control of all parameters to the ECU
Table 422 specifies the InputOutputControlByIdentifier request message flow example #2 - Case #4.
 |
Table 422 — InputOutputControlByIdentifier request message flow example #2 – Case #4 |
Table 423 specifies the InputOutputControlByIdentifier positive response message flow example #2 - Case #4.
 |
Table 423 — InputOutputControlByIdentifier positive response message flow example #2 – Case #4 |
The value transmitted for all parameters in controlState#1 - controlState#5 shall reflect the current state of the system.
14 Routine functional unit
14.1 Overview
Table 424 specifies the Routine functional unit.
 |
Table 424 — Routine functional unit |
This functional unit specifies the services of remote activation of routines, as they shall be implemented in servers and client. The following subclause describes two different methods of implementation (methods "A" and "B"). There may be other methods of implementation possible. Methods "A" and "B" shall be used as a guideline for implementation of routine services.
NOTE
Each method can feature the functionality to request routine results service after the routine has been stopped. The selection of method and the implementation is the responsibility of the vehicle manufacturer and system supplier.
The following is a brief description of method "A" and "B":
- Method "A":
- This method is based on the assumption that after a routine has been started by the client in the server's memory the client shall be responsible to stop the routine.
- The server routine shall be started in the server's memory some time between the completion of the RoutineControl request message that starts the routine and the completion of the first response message (if "positive" based on the server's conditions).
- The server routine shall be stopped in the server's memory some time after the completion of the StopRoutine request message and the completion of the first response message (if "positive" based on the server's conditions).
- The client may request routine results after the routine has been stopped.
- Method "B":
- This method is based on the assumption that after a routine has been started by the client in the server's memory that the server shall be responsible to stop the routine.
- The server routine shall be started in the server's memory some time between the completion of the RoutineControl request message that starts the routine and the completion of the first response message (if "positive" based on the server's conditions).
- The server routine shall be stopped any time as programmed or previously initialized in the server's memory.
14.2 RoutineControl (0x31) service
14.2.1 Service description
The RoutineControl service is used by the client to execute a defined sequence of steps and obtain any relevant results. There is a lot of flexibility with this service, but typical usage may include functionality such as erasing memory, resetting or learning adaptive data, running a self-test, overriding the normal server control strategy, and controlling a server value to change over time including predefined sequences (e.g. close convertible roof) to name a few. In general, when used to control outputs this service is used for more complex type control whereas inputOutputControlByIdentifier is used for relatively simple (e.g. static) output control.
14.2.1.1 Overview
The RoutineControl service is used by the client to:
- start a routine;
- stop a routine; and
- request routine results.
A routine is referenced by a 2-byte routineIdentifier.
The following subclauses specify start routine, stop routine, and request routine results referenced by a routineIdentifier.
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
14.2.1.2 Start a routine referenced by a routineIdentifier
The routine shall be started in the server's memory some time between the completion of the StartRoutine request message and the completion of the first response message if the response message is positive or negative, indicating that the request is already performed or in progress to be performed.
The routines could either be tests that run instead of normal operating code or could be routines that are enabled and executed with the normal operating code running. In particular in the first case, it might be necessary to switch the server in a specific diagnostic session using the DiagnosticSessionControl service or to unlock the server using the SecurityAccess service prior to using the StartRoutine service.
14.2.1.3 Stop a routine referenced by a routineIdentifier
The server routine shall be stopped in the server's memory some time after the completion of the StopRoutine request message and the completion of the first response message if the response message is positive or negative, indicating that the request to stop the routine is already performed or in progress to be performed.
The server routine shall be stopped any time as programmed or previously initialized in the server's memory.
14.2.1.4 Request routine results referenced by a routineIdentifier
This SubFunction is used by the client to request results (e.g. exit status information) referenced by a routineIdentifier and generated by the routine which was executed in the server's memory.
Based on the routine results, which may have been received in the positive response message of the stopRoutine SubFunction parameter (e.g. normal/abnormal Exit With Results) the requestRoutineResults SubFunction shall be used.
An example of routineResults could be data collected by the server, which could not be transmitted during routine execution because of server performance limitations.
14.2.2 Request message
14.2.2.1 Request message definition
Table 425 specifies the request message.
 |
Table 425 — Request message definition |
14.2.2.2 Request message SubFunction parameter $Level (LEV_) definition
The SubFunction parameters are used by this service to select the control of the routine. Explanations and usage of the possible levels are detailed in Table 426 (suppressPosRspMsgIndicationBit (bit 7) not shown).
 |
Table 426 — Request message SubFunction definition |
14.2.2.3 Request message data-parameter definition
Table 427 specifies the data-parameters of the request message.
 |
Table 427 — Request message data-parameter definition |
14.2.3 Positive response message
14.2.3.1 Positive response message definition
Table 428 specifies the positive response message.
 |
Table 428 — Positive response message definition |
14.2.3.2 Positive response message data-parameter definition
Table 429 specifies the data-parameters of the positive response message.
 |
Table 429 — Response message data-parameter definition |
14.2.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 430. The listed negative responses shall be used if the error scenario applies to the server.
 |
Table 430 — Supported negative response codes |
The evaluation sequence is documented in Figure 30.
 |
Figure 30 — NRC handling for RoutineControl service |
14.2.5 Message flow example(s) RoutineControl
14.2.5.1 Example #1: SubFunction = startRoutine
This subclause specifies the test conditions to start a routine in the server to continuously test (as fast as possible) all input and output signals on signal intermittence. Then, a technician can "wiggle" all wiring harness connectors of the system under test. After the doing this, the routine in the server is stopped. The routineIdentifier references this routine by the routineIdentifier 0x0201.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph].
The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 431 specifies the RoutineControl request message flow - example #1.
 |
Table 431 — RoutineControl request message flow - example #1 |
Table 432 specifies the positive response message flow - example #1.
 |
Table 432 — positive response message flow - example #1 |
14.2.5.2 Example #2: SubFunction = stopRoutine
This subclause specifies the test conditions to start a routine in the server to continuously test (as fast as possible) all input and output signals on signal intermittence. Then, a technician can "wiggle" all wiring harness connectors of the system under test. After the doing this, the routine in the server is stopped. The routineIdentifier references this routine by the routineIdentifier 0x0201.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph].
The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 433 specifies the RoutineControl request message flow - example #2.
 |
Table 433 — RoutineControl request message flow - example #2 |
Table 434 specifies the RoutineControl positive response message flow - example #2.
 |
Table 434 — RoutineControl positive response message flow - example #2 |
14.2.5.3 Example #3: SubFunction = requestRoutineResults
This subclause specifies the test conditions to start a routine in the server to continuously test (as fast as possible) all input and output signals on signal intermittence. Then, a technician can "wiggle" all wiring harness connectors of the system under test. After the doing this, the routine in the server is stopped. The routineIdentifier references this routine by the routineIdentifier 0x0201.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph].
The client requests to have a response message bysetting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 435 specifies the RequestRoutineResults request message flow - example #3.
 |
Table 435 — RequestRoutineResults request message flow – example #3 |
Table 436 specifies the RequestRoutineResults positive response message flow - example #3.
 |
Table 436 — RequestRoutineResults positive response message flow - example #3 |
14.2.5.4 Example #4: SubFunction = startRoutine with routineControlOption
This subclause specifies the test conditions to start a routine in a transmission control unit to calibrate the gear shift for a certain gear in a special mode. The gear could be any from #1 to #20 and the mode can be bench, stand alone and in-vehicle. The routineIdentifier references this routine by the routineIdentifier 0x0202.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph].
The client requests to have a response message by setting the suppressPosRspMsgIndicationBit (bit 7 of the SubFunction parameter) to "FALSE" ('0').
Table 437 specifies the RoutineControl request message flow - example #4.
 |
Table 437 — RoutineControl request message flow - example #4 |
Table 438 specifies the RoutineControl positive response message flow - example #4.
 |
Table 438 — RoutineControl positive response message flow - example #4 |
15 上传下载功能单元
15.1 概述
表 439 指定了上传下载功能单元。
 |
Table 439 — Upload Download functional unit |
15.2 RequestDownload (0x34) 服务
15.2.1 服务描述
客户端通过 requestDownload 服务向服务器请求（从客户端到服务器）数据传输（下载）。
服务器收到 requestDownload 服务的请求消息后，应采取一切必要的措施以接收数据，然后发送肯定响应消息。
重要
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
15.2.2 请求消息
15.2.2.1 请求消息的定义
表 440 指定了请求消息的定义。
 |
Table 440 — Request message definition |
15.2.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
此服务不支持请求消息的 SubFunction 参数。
15.2.2.3 请求消息的数据参数的定义
表 441 指定了请求消息的数据参数的定义。
 |
Table 441 — Request message data-parameter definition |
15.2.3 肯定响应消息
15.2.3.1 肯定响应消息的定义
表 442 指定了肯定响应消息的定义。
 |
Table 442 — Positive response message definition |
15.2.3.2 肯定响应消息的数据参数的定义
表 443 指定了肯定响应消息的数据参数的定义。
 |
Table 443 — Response message data-parameter definition |
15.2.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 444 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
 |
Table 444 — Supported negative response codes |
流程如图 31 所示。
 |
Figure 31 — NRC handling for RequestDownload service |
15.2.5 消息流示例 RequestDownload
有关完整的消息流的示例，请参见 15.5.5。
15.3 RequestUpload (0x35) service
15.3.1 Service description
The RequestUpload service is used by the client to initiate a data transfer from the server to the client (upload).
After the server has received the requestUpload request message the server shall take all necessary actions to send data before it sends a positive response message.
IMPORTANT
The server and the client shall meet the request and response message behaviour as specified in 8.7.
15.3.2 Request message
15.3.2.1 Request message definition
Table 445 specifies the request message.
 |
Table 445 — Request message definition |
15.3.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
15.3.2.3 Request message data-parameter definition
Table 446 specifies the data-parameters of the request message.
 |
Table 446 — Request message data-parameter definition |
15.3.3 Positive response message
15.3.3.1 Positive response message definition
Table 447 specifies the positive response message.
 |
Table 447 — Positive response message definition |
15.3.3.2 Positive response message data-parameter definition
Table 448 specifies the data-parameters of the positive response message.
 |
Table 448 — Response message data-parameter definition |
15.3.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which each response code would occur are documented in Table 449. The listed negative responses shall be used if the error scenario applies to the server.
 |
Table 449 — Supported negative response codes |
The evaluation sequence is documented in Figure 32.
 |
Figure 32 — NRC handling for RequestUpload service |
15.3.5 Message flow example(s) RequestUpload
See 15.5.5 for a complete message flow example.
15.4 TransferData (0x36) 服务
15.4.1 服务描述
客户端通过 TransferData 服务传输数据，数据传输方向可以是客户端到服务器（下载）或服务器到客户端（上传）。
数据传输方向由之前的 RequestDownload 或 RequestUpload 服务定义。如果客户端请求 RequestDownload 服务，则待下载的数据被包含在 TransferData 服务的请求消息的 transferRequestParameter 参数中。如果客户端请求 RequestUpload 服务，则待上传的数据被包含在 TransferData 服务的响应消息的 transferResponseParameter 参数中。
TransferData 服务的请求消息包含一个 blockSequenceCounter 参数，以便当在多个 TransferData 服务的请求中出现 TransferData 服务故障时，更好地处理错误。服务器在收到 RequestDownload、RequestUpload 或 RequestFileTransfer 服务的请求消息时，应将 blockSequenceCounter 参数初始化为 1。这意味着在 RequestDownload、RequestUpload 或 RequestFileTransfer 服务的请求消息之后，TransferData 服务的第一个请求消息的 blockSequenceCounter 参数为 1。
重要
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
15.4.2 请求消息
15.4.2.1 请求消息的定义
表 450 指定了请求消息的定义。
 |
Table 450 — Request message definition |
15.4.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
此服务不支持请求消息的 SubFunction 参数。
15.4.2.3 请求消息的数据参数的定义
表 451 指定了请求消息的数据参数的定义。
 |
Table 451 — Request message data-parameter definition |
15.4.3 肯定响应消息
15.4.3.1 肯定响应消息的定义
表 452 指定了肯定响应消息的定义。
 |
Table 452 — Positive response message definition |
15.4.3.2 肯定响应消息的数据参数的定义
表 453 指定了肯定响应消息的数据参数的定义。
 |
Table 453 — Response message data-parameter definition |
15.4.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 454 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
 |
Table 454 — Supported negative response codes |
流程如图 33 所示。
 |
Figure 33 — NRC handling for TransferData service |
15.4.5 消息流示例 TransferData
有关完整的消息流的示例，请参见 15.5.5。
15.5 RequestTransferExit (0x37) 服务
15.5.1 服务描述
客户端通过此服务退出客户端与服务器之间的数据传输（上传或下载）。
重要
服务器和客户端应符合 8.7 节中规定的请求和响应消息的行为。
15.5.2 请求消息
15.5.2.1 请求消息的定义
表 455 指定了请求消息的定义。
 |
Table 455 — Request message definition |
15.5.2.2 请求消息的 SubFunction 参数 $Level (LEV_) 的定义
此服务不支持请求消息的 SubFunction 参数。
15.5.2.3 请求消息的数据参数的定义
表 456 指定了请求消息的数据参数的定义。
 |
Table 456 — Request message data-parameter definition |
15.5.3 肯定响应消息
15.5.3.1 肯定响应消息的定义
表 457 指定了肯定响应消息的定义。
 |
Table 457 — Positive response message definition |
15.5.3.2 肯定响应消息的数据参数的定义
表 458 指定了肯定响应消息的数据参数的定义。
 |
Table 458 — Response message data-parameter definition |
15.5.4 支持的否定响应码（NRC_）
本服务实现以下否定响应码。表 459 记录了每个响应码的适用情况。如果服务器出现错误，则应使用所列的否定响应码。
 |
Table 459 — Supported negative response codes |
流程如图 34 所示。
 |
Figure 34 — NRC handling for RequestTransferExit service |
15.5.5 消息流示例 - 下载/上传数据
15.5.5.1 下载数据至服务器
15.5.5.1.1 假设
本子条款规定了从客户端向服务器传输数据（下载）所需的条件。
示例包含三个步骤。
在步骤一中，客户端向服务器请求 RequestDownload 服务。通过此服务，客户端和服务器会通过请求和响应消息的参数交换以下信息。
表 460 指定了 transferRequestParameter 参数的值。
 |
Table 460 — Definition of transferRequestParameter values |
表 461 指定了 transferResponseParameter 参数的值。
 |
Table 461 — Definition of transferResponseParameter value |
在步骤二中，从内存地址（服务器） 0x00602000 开始，客户端向该内存地址（服务器）传输长度为 65535 字节的数据。
在步骤三中，客户端通过 RequestTransferExit 服务请求退出（终止）数据传输。
测试条件：点火开关开启，发动机关闭，车速为 0 公里/小时。
本例中，假设服务器支持长度为 3 字节的 memoryAddress 参数和长度为 3 字节的 MemorySize 参数。如果 MemorySize 参数的值为压缩前的数据的大小，则无法计算请求 TransferData 服务（单次请求中传输的数据的长度为 127 字节）的次数，因为压缩方式及压缩率尚未标准化。如果 MemorySize 参数的值为压缩后的数据的大小，则请求 TransferData 服务（单次请求中传输的数据的长度为 127 字节）的次数为 516，之后会跟随一个 TransferData 服务请求（传输的数据的长度为 3 字节）。因此，应假定最后一个 TransferData 服务的请求消息的长度为 0x05（长度为 3 字节的数据、长度为 1 字节的 ServiceId 及长度为 1 字节的 blockSequenceCounter）。
15.5.5.1.2 步骤 #1 - 请求下载
表 462 指定了 RequestDownload 服务的请求消息的消息流示例。
 |
Table 462 — RequestDownload request message flow example |
表 463 指定了 RequestDownload 服务的肯定响应消息的消息流示例。
 |
Table 463 — RequestDownload positive response message flow example |
15.5.5.1.3 步骤 #2 - 传输数据
表 464 指定了 TransferData 服务的请求消息的消息流的示例。
 |
Table 464 — TransferData request message flow example |
表 465 指定了 TransferData 服务的肯定响应消息的消息流的示例。
 |
Table 465 — TransferData positive response message flow example |
表 466 指定了 TransferData 服务的请求消息的消息流的示例。
 |
Table 466 — TransferData request message flow example |
表 467 指定了 TransferData 服务的肯定响应消息的消息流的示例。
 |
Table 467 — TransferData positive response message flow example |
15.5.5.1.4 步骤 #3 - 请求退出传输
表 468 指定了 RequestTransferExit 服务的请求消息的消息流的示例。
 |
Table 468 — RequestTransferExit request message flow example |
表 469 指定了 RequestTransferExit 服务的肯定响应消息的消息流的示例。
 |
Table 469 — RequestTransferExit positive response message flow example |
15.5.5.2 从服务器上传数据
本子条款规定了从服务器向客户端传输数据（上传）所需的条件。
示例包含三个步骤。
在步骤一中，客户端向服务器请求 RequestUpload 服务。通过此服务，客户端和服务器会通过请求和响应消息的参数交换以下信息。
表 470 指定了 transferRequestParameter 参数的值。
 |
Table 470 — Definition of transferRequestParameter values |
表 471 指定了 transferResponseParameter 参数的值。
 |
Table 471 — Definition of transferResponseParameter value |
在步骤二中，从内存地址（服务器） 0x00201000 开始，服务器向客户端传输长度为 511 字节的数据（从该内存地址（服务器）开始）。
在步骤三中，客户端通过 RequestTransferExit 服务请求退出（终止）数据传输。
测试条件：点火开关开启，发动机关闭，车速为 0 公里/小时。
本例中，假设服务器支持长度为 3 字节的 memoryAddress 参数和长度为 3 字节的 MemorySize 参数。此外，假设服务器支持 TransferData 服务的 blockSequenceCounter 参数。其中，包含 5 次 TransferData 服务请求，4 次传输的数据的长度为 127 字节的请求，及 1 次传输的数据的长度为 3 字节的请求。
15.5.5.2.1 步骤 #1 - 请求上传
表 472 指定了 RequestUpload 服务的请求消息的消息流示例。
 |
Table 472 — RequestUpload request message flow example |
表 473 指定了 RequestUpload 服务的肯定响应消息的消息流示例。
 |
Table 473 — RequestUpload positive response message flow example |
15.5.5.2.2 步骤 #2 - 传输数据
表 474 指定了 TransferData 服务的请求消息的消息流的示例。
 |
Table 474 — TransferData request message flow example |
表 475 指定了 TransferData 服务的肯定响应消息的消息流的示例。
 |
Table 475 — TransferData positive response message flow example |
表 476 指定了 TransferData 服务的请求消息的消息流的示例。
 |
Table 476 — TransferData request message flow example |
表 477 指定了 TransferData 服务的肯定响应消息的消息流的示例。
 |
Table 477 — TransferData positive response message flow example |
15.5.5.2.3 步骤 #3 - 请求退出传输
表 478 指定了 RequestTransferExit 服务的请求消息的消息流的示例。
 |
Table 478 — RequestTransferExit request message flow example |
表 479 指定了 RequestTransferExit 服务的肯定响应消息的消息流的示例。
 |
Table 479 — RequestTransferExit positive response message flow example |
15.6 RequestFileTransfer (0x38) service
15.6.1 Service description
The requestFileTransfer service is used by the client to initiate a file data transfer from either the client
to the server or from the server to the client (download or upload). Additionally, this service has
capabilities to retrieve information about the file system.
This service is intended as an alternative solution to the RequestDownload and RequestUpload service
supporting data upload and download functionality if a server implements a file system for data
storage. When configuring a download or upload process to or from a file system, the
RequestFileTransfer service shall be used replacing the RequestDownload or RequestUpload. The
actual data transfer and termination of the data transfer are implemented by using the TransferData
and RequestTransferExit as used with the RequestDownload or RequestUpload service. This service
also includes functionality for deleting files or directories on the server's file system. For this use case
the TransferData and RequestTransferExit service are not applicable.
After the server has received the RequestFileTransfer request message the server shall take all
necessary actions to receive or transmit data before it sends a positive response message.
IMPORTANT
The server and the client shall meet the request and response message behaviour as
specified in 8.7.
15.6.2 Request message
15.6.2.1 Request message definition
Table 480 specifies the request message.
 |
Table 480 — Request message definition |
15.6.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
15.6.2.3 Request message data-parameter definition
Table 481 specifies the data-parameters of the request message.
 |
Table 481 — Request message data-parameter definition |
15.6.3 Positive response message
15.6.3.1 Positive response message definition
Table 482 specifies the positive response message.
 |
Table 482 — Positive response message definition |
15.6.3.2 Positive response message data-parameter definition
Table 483 specifies the data-parameters of the positive response message.
 |
Table 483 — Response message data-parameter definition |
15.6.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 484. The listed negative responses
shall be used if the error scenario applies to the server.
 |
Table 484 — Supported negative response codes |
The evaluation sequence is documented in Figure 35.
 |
Figure 35 — NRC handling for requestFileTransfer service |
15.6.5 Message flow example(s) RequestFileTransfer
15.6.5.1 Assumptions
This sub-clause specifies the conditions applicable for this message flow example.
NOTE
This example is limited to the description of the requestFileTransfer request and the requestFileTransfer
positive response. The usage of transferData and requestTransferExit in this context is identical with the usage of
these services with requestDownload or requestUpload, thus the examples describing the download/upload
sequence apply as well.
Table 485 specifies the message parameter values.
 |
Table 485 — Definition RequestFileTransfer message parameter values |
15.6.5.2 Request file transfer
Table 486 and Table 487 show an example of the RequestFileTransfer request and response message
flow.
 |
Table 486 — RequestFileTransfer request message example |
 |
Table 487 — RequestFileTransfer positive response request message example |
16 Security sub-layer definition
16.1 General
16.1.1 Purpose
The purpose of the security sub-layer is to transmit data that is protected against attacks from third
parties - which could endanger data security.
16.1.2 Security sub-layer description
Figure 36 illustrates the security sub-layer. The security sub-layer shall be added in the server and
client application for the purpose of performing diagnostic services in a secured mode.
 |
Figure 36 — Security sub-layer implementation |
There are two methods to perform diagnostic service data transfer between the client and server(s):
- Unsecured data transmission mode
The application uses the diagnostic services and application layer service primitives with A_Mtype set
either to diagnostic or to remote diagnostics defined in this document to exchange data between a client
and a server. The message of SecureDataTransmission is not allowed. All other messages bypass the
security sub-layer and are processed as regular messages.
- Secured data transmission mode
The application uses the diagnostic services and application layer service primitives with A_Mtype set
either to secure diagnostic or to secure remote diagnostics defined in this document to exchange data
between a client and a server. The security sub-layer uses the SecuredDataTransmission service for the
transmission/reception of the secured data. Depending on the key distribution secured links may be
point-to-point communication only.
The task of the security sub-layer when performing a diagnostic service in a secured mode is to encrypt
data provided by the "Application Layer", to decrypt data provided by the "Network Layer", to add an
authentication code, to verify an authentication code, and to add, check, and remove security specific
data elements. The security sub-layer uses the SecuredDataTransmission (0x84) request message of the
application layer to transmit and receive the entire diagnostic message or message according to an
external protocol (request and response), which shall be exchanged in a secured mode.
16.1.3 Security sub-layer access
The concept of accessing the security sub-layer for a secured service execution is similar to the
application layer interface as described in this document. The security sub-layer makes use of the
application layer service primitives.
The following describes the execution of confirmed diagnostic service in a secured mode:
- The client application uses the security sub-layer SecuredServiceExecution service request to perform a diagnostic service in a secured mode (A_Mtype = secureDiag). The security sub-layer performs the required action to establish a link with the server(s), adds the specific security related parameters, encrypts the service data of the diagnostic service to be executed in a secured mode if needed and uses the application layer SecuredDataTransmission service request message to transmit the secured data to the server.
- The server receives an application layer SecuredDataTransmission service indication, which is handled by the security sub-layer of the server. The security sub-layer of the server checks the security specific parameters decrypts encrypted data, confirms authenticity of the message and presents the data of the service to be executed in a secured mode to the application with message type set to secureDiag. The application service cannot be the SecuredDataTransmission (0x84) service request message.
- When the authentication of the SecuredDataTransmission service failed a regular negative response message is responded with using the SecuredDataTransmission (0x84) request message service identifier and a NRC.
- The application executes the service and uses the Mtype = secureDiag to respond to the service in a secured mode. The security sub-layer of the server adds the specific security related parameters, encrypts the response message data if needed and uses the application layer SecuredDataTransmission service response message to transmit the response data to the client.
- The client receives an application layer SecuredDataTransmission service confirmation primitive, which is handled by the security sub-layer of the client. The security sub-layer of the client checks the security specific parameters, decrypts encrypted response data and presents the data via the security sub-layer SecuredServiceExecution confirmation to the application.
The ∆P2 timing highly varies with each ECU due to the used security algorithm and performance of the
ECU. On timeout the message transmission had failed and the client application can assume that the
request is not processed in the server.
Figure 37 and Figure 38 show the physical communication flow with normal and enhanced response
timing.
 |
Figure 37 — Physical communication during defaultSession - with SOM.ind and security sublayer |
 |
Figure 38 — Physical communication during defaultSession - with enhanced response timing and security sub-layer |
IMPORTANT
The client shall process messages with A_Mtype = secureDiag in the security sub-layer.
The server shall process the SecuredDataTransmission service in the security sub-layer. The
SecuredDataTransmission service does not have any state or timing behaviour like the P2 timing.
Therefore, for complex security layer calculations, the value of ∆P2 shall be considered. Additionally,
the server and the client only meet the request and response message behaviour as specified in 8.7 for
SID 0x84. The SecuredDataTransmission service is also not aware of any session or security level
restrictions.
16.1.4 General server response behaviour
The general server response behaviour specified in Figure 39 is mandatory for all request messages in
case the SecureDataTransmission service is supported. The validation steps start with the reception of
the request message.
 |
Figure 39 — Security sub-layer – Server response behaviour |
16.2 SecuredDataTransmission (0x84) service
16.2.1 Service description
The SecuredDataTransmission service is applicable if a client intends to use diagnostic services defined
in this document in a secured mode. It may also be used to transmit external data, which conform to
some other application protocol, in a secured mode between a client and a server. A secured mode in
this context means that the data transmitted is protected by cryptographic methods.
16.2.2 Request message
16.2.2.1 Request message definition
The security sub-layer generates the application layer SecuredDataTransmission request message
parameters.
Table 488 specifies the request message using plain text (unencrypted).
 |
Table 488 — Request message definition |
NOTE
Encrypted messages would make the internal SID unreadable without decryption.
16.2.2.2 Request message SubFunction parameter $Level (LEV_) definition
This service does not use a SubFunction parameter.
16.2.2.3 Request message data-parameter definition
Table 489 specifies the data-parameters of the request message.
 |
Table 489 — Request message data-parameter definition |
The Administrative Parameter is a bit string of 16 bits length. The bit assignment shall be according to
Table 490. If a bit is set to 1 then the corresponding feature is requested. If it is set to 0 then the
corresponding feature is not requested.
 |
Table 490 — Definition of Administrative Parameter |
Table 491 specifies Definition of Signature/Encryption calculation parameter.
 |
Table 491 — Definition of Signature/Encryption calculation parameter |
16.2.3 Positive response message for successful internal message
16.2.3.1 Positive response message definition for successful internal message
Table 492 specifies the positive response message where the internal service request is successful.
 |
Table 492 — Positive response message definition |
16.2.3.2 Positive response message data-parameter definition
Table 493 specifies the data-parameter of the positive response message.
 |
Table 493 — Response message data-parameter definition |
16.2.3.3 Positive response message definition for unsuccessful internal message
Table 494 specifies the positive response message where the internal service request is successful.
 |
Table 494 — Positive response message definition |
16.2.3.4 Positive response message data-parameter definition
Table 495 specifies the data-parameter of the positive response message.
 |
Table 495 — Response message data-parameter definition |
16.2.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under
which each response code would occur are documented in Table 496. The listed negative responses
shall be used if the error scenario applies to the server.
 |
Table 496 — Supported negative response codes |
NOTE 1
The response codes listed above apply to the SecuredDataTransmission (0x84) service. In case the
internal diagnostic service performed in a secured mode requires a negative response then this negative response
is sent to the client in a secured mode via a SecuredDataTransmission positive response message.
NOTE 2
The negative response code secureDataTransmissionRequired (0x38) can be used for other diagnostic
services if the requested action is required to be sent using a secured communication channel. The negative
response code secureDataTransmissionNotAllowed (0x39) can be used for internal message service if the
requested action is not allowed to be sent using a secured communication channel.
16.2.5 Message flow example SecuredDataTransmission
16.2.5.1 Assumptions
For the example messages, the message will send a signed, but unencrypted message. The signature
calculation used was 1's complement.
16.2.5.2 Example #1: SecuredDataTransmission to Write DID
The security sub-layer generates the application layer SecuredDataTransmission request message
parameters. This example shows the request and a positive response.
Table 497 specifies the request message.
 |
Table 497 — SecuredDataTransmission request message flow example #1 |
Table 498 specifies the SecuredDataTransmission positive response message flow example #1.
 |
Table 498 — SecuredDataTransmission response message flow example #1 |
16.2.5.3 Example #2: SecuredDataTransmission to Write DID
The security sub-layer generates the application layer SecuredDataTransmission request message
parameters. This example shows the request and a negative response to the internal service request.
The reject occurs because the data size for writing the VIN (DID 0xF190) is too short (only two bytes
length).
Table 499 specifies the request message.
 |
Table 499 — SecuredDataTransmission request message flow example #2 |
Table 500 specifies the SecuredDataTransmission positive response message flow example #2.
 |
Table 500 — SecuredDataTransmission response message flow example #2 |
17 Non-volatile server memory programming process
17.1 General information
This subclause defines a framework for the physically oriented download of one or multiple application
software/data modules into non-volatile server memory. The defined non-volatile server memory
programming sequence addresses:
- a) vehicle manufacturer specific needs in performing certain steps during the programming process, while being compliant with the general service execution requirements as specified in this document and ISO 14229-2 (such as the sequential order of services and the session management),
- b) to support networks with multiple nodes connected, which interact with each other, using normal communication messages,
- c) use of either a physically oriented vehicle approach (point-to-point communication — servers do not support functional diagnostic communication) or a functionally oriented vehicle approach (point-to-point and point-to-multiple communication — servers support functional diagnostic communication). A single vehicle shall only support one of the above mentioned vehicle approaches.
The programming sequence is divided into two programming phases. All steps are categorized based on
the following types:
- Standardized steps: this type of step is mandatory. The client and the server shall behave as specified.
- Optional/recommended steps: this type of step is optional. These optional steps require the usage of a specific diagnostic service identifier (as described in the step) and contain recommendations on how an operation shall be performed. Where the specified functionality is used, then the client and the server shall behave as specified.
- Vehicle manufacturer specific steps: this type of step is optional. The usage and content (e.g. diagnostic service identifiers used) of these optional steps is left to the discretion of the vehicle manufacturer and shall be in accordance with this document and ISO 14229-2.
The defined steps can either be:
- functionally addressed to all nodes on the network (functionally oriented vehicle approach, servers support functional diagnostic communication), or
- physically addressed to each node on the network (physically oriented vehicle approach).
Each step of the two programming phases of the programming procedure will specify the allowed
addressing method for that step. The vehicle manufacturer specific steps can either by functionally or
physically addressed (depends on the OEM requirements).
Figure 40 depicts the non-volatile server memory programming process overview.
 |
Figure 40 — Non-volatile server memory programming process overview |
The programming process the client is required to follow consists of two distinct types of diagnostic
service executions:
- Master execute
- All steps that are required to be synchronized between multiple programming steps which run in parallel shall be coordinated as they are intended for vehicle wide functions (e.g. typically using functional addressing). This is achieved via the "master execute" of the client. The steps defined for the “Pre-Programming Step” and the "Post-programming Step" of the individual programming phases are executed by the "master execute" of the client. The programming process requires synchronisation between the individual "Programming steps" (e.g. the transition of the vehicle network into a mode of operation that allows for programming of individual ECUs, or at the point in time when the individual parallel "Programming steps" reach the point where a conclusion of a programming phase is required). The master execute shall maintain the vehicle in the mode of operation it has transitioned to.
- Programming execute
- All steps that are not required to be synchronized between multiple "Programming steps" do not require any coordination by the client and can run in parallel, therefore no “master execute” is required in the client during the execution of these steps. The "Programming steps" of the individual ECUs can be executed individually in parallel by the client until they are concluded and require the execution of the "Post-programming phase". All steps controlled by the "programming execute" are ECU oriented steps (e.g. physically addressed to the ECU to be programmed).
- d) Programming phase #1 — download of application software and/or application data
- 1) Within programming phase #1, the application software/data is transferred to the server.
- i) Optional Pre-Programming step — Setup of vehicle network for programming
- The preprogramming step of phase #1 is optional and used to prepare the vehicle network for a programming event of one or multiple servers. This step provides certain hooks where a vehicle manufacturer can insert specific operations that are required for the OEM vehicle’s network (perform wake-up, determine communication parameters, read server identification data, etc.).
- This step also contains provisions to increase the bit rate to improve download performance. The usage of this functionality is optional and can only be performed in case of a functionally oriented vehicle approach (functional diagnostic communication supported by the servers).
- The request messages of this step can either be physically or functionally addressed.
- 2) Server Programming step — Download of application software and application data
- The server programming step of phase #1 is used to program one or multiple servers (download of application software and/or application data and/or boot software).
- Within this step, only physical addressing is used by the client, which allows for parallel or sequential programming of multiple nodes. In the case where the preprogramming step is not used, then the DiagnosticSessionControl (1016) withSubFunction programmingSession can also be performed using functional addressing.
- At the end of this step, a physical reset of the reprogrammed server(s) is optional. The use of the reset leads to the requirement to implement programming phase #2 in order to finally conclude the programming event by physically clearing DTCs in the reprogrammed server(s), because after the physical reset during this step the reprogrammed server(s) enable(s) the default session and perform(s) their normal mode of operation while the remaining server(s) have still disabled normal communication. The reprogrammed server(s) will potentially set DTCs.
- Furthermore, it shall be considered that the reprogrammed server could activate a new set of diagnostic address, which differs from the ones used when performing a programming event (see 17.3).
- If either the server that was reprogrammed does not change its communication parameters or the client knows the changed communication parameters, then following the reset certain configuration data can be written to the reprogrammed server.
- 3) Post-Programming step — Re-synchronisation of vehicle network after programming
- The post-programming step of phase #1 concludes the programming phase #1. This step is performed when the programming step of each reprogrammed server is finished.
- The request messages of this step can either be physically or functionally addressed.
- The vehicle network is transitioned to its normal mode of operation. This can either be done via a reset using the ECUReset (0x11) service or an explicit transition to the default session via the DiagnosticSessionControl (0x10) service.
- e) Programming phase #2 — Server configuration (optional)
- 1) Programming phase #2 is an optional phase in which the client can perform further actions that are needed to finally conclude a programming event (write the VIN, trigger Immobilizer learn-routine, etc.). For example, if the server(s) that has (have) been reprogrammed is (are) physically reset during the server programming step of programming phase #1, then DTCs shall be cleared in this server(s).
- 2) When executing this phase, the downloaded application software/application data is running/activated in the server and the server provides its full diagnostic functionality.
- Pre-Programming step — Setup of vehicle network for server configuration
- The preprogramming step of phase #2 is used to prepare the vehicle network for the programming step of phase #2. This step is an optional step and provides certain hooks where a vehicle manufacturer can insert specific operations that are required for OEM vehicle’s network (e.g. wake-up, determine communication parameters).
- The request messages of these steps can either be physically or functionally addressed.
- Programming step — Final server configuration
- The programming step is used to, for example, write data (e.g. VIN), after the server reset.
- The content of this step is vehicle manufacturer specific.
- If the server(s) that has (have) been reprogrammed is physically reset at the end of the server programming step of programming phase #1, then DTCs shall be cleared in this server(s) during the programming step of phase #2.
- The request messages of these steps are physically addressed.
- Post-Programming step — Re-synchronisation of vehicle network after final server configuration
- The post-programming step concludes programming phase #2. This step is performed when the programming step of each reprogrammed server is finished. The vehicle network is transitioned to its normal mode of operation.
- This step can either be functionally oriented (servers support functional diagnostic communication) or physically oriented.
- The request messages of these steps can either be physically or functionally addressed.
17.2 Detailed programming sequence
17.2.1 Programming phase #1 — Download of application software and/or application data
17.2.1.1 Pre-Programming step of phase #1 — Setup of vehicle network for programming
Figure 41 graphically depicts the functionality embedded in the preprogramming step.
 |
Figure 41 — Preprogramming step of phase 1 (STP1) |
17.2.1.2 Programming step of phase #1 — Download of application software and data
Following the preprogramming step, the programming of one or multiple servers is performed. The
programming sequence applies for a programming event of a single server and is therefore physically
oriented. When multiple servers are programmed, then multiple programming events either run in
parallel or will be performed sequentially.
Figure 42 graphically depicts the functionality embedded in the programming step of phase #1.
 |
Figure 42 — Programming step of phase 1 (STP2) |
17.2.1.3 Post-Programming step of phase #1 — Re-synchronisation of vehicle network
Figure 43 graphically depicts the functionality embedded in the post-programming step of phase #1.
 |
Figure 43 — Post-programming step of phase 1 (STP3) |
17.2.1.4 Preprogramming step of phase #2 — Server configuration
The preprogramming step of phase #2 is optional and should be used when there is the need to perform
certain action after the software reset of the reprogrammed server. This will be the case when the
server does not provide the required functionality to finally conclude the programming event when
running out of boot software during the programming step of phase #1.
Figure 44 graphically depicts the functionality embedded in the preprogramming step of phase #2.
 |
Figure 44 — Preprogramming step of phase 2 (STP4) |
EXAMPLE
A vehicle manufacturer-specific additional initialization step can be to issue a request that causes
gateway devices to perform a wake-up on all data links which are not accessible by the client directly through the
diagnostic connector. The gateway will keep the data link(s) awake as long as the non-defaultSession is kept active
in the gateway.
17.2.1.5 Programming step of phase #2 — Final server configuration
The programming step of phase #2 is optional and contains any action that needs to take place with the
reprogrammed server after the reset (when the application software is running) such as writing specific
identification information. This step might be required in case the server does not provide the required
functionality to perform an action when running out of boot software during the programming step of
phase #1. When multiple servers require performing additional functions, then multiple programming
steps can run in parallel or will be performed sequentially.
Figure 45 depicts the programming step of phase 2 (STP5).
 |
Figure 45 — Programming step of phase 2 (STP5) |
17.2.1.6 Post-programming step of phase #2 — Re-synchronisation of vehicle network
Figure 46 depicts the Post-programming step of phase 2 (STP6).
 |
Figure 46 — Post-programming step of phase 2 (STP6) |
17.3 Server reprogramming requirements
17.3.1 Requirements for servers to support programming
During a programming session, servers shall default their physical I/O pins (wherever possible and
without risk of damage to the server/vehicle and without risk of safety hazards) to a predefined state
which minimizes current draw.
17.3.1.1 Boot software description and requirements
17.3.1.1.1 Boot software general requirements
All programmable servers that support programming of the application software shall contain boot
software in a boot memory partition. Servers that support boot software typically continue to execute
out of the boot software until a complete set of application software and application data is
programmed (e.g. it is possible for some servers to begin executing application software despite not
having 100 % of application data programmed).
The boot memory partition shall be protected against inadvertent erasure such that a failed attempt to
modify application data or application software does not prohibit the server's ability to recover and be
programmed after the failed attempt. The server shall be able to recover and be reprogrammed if any of
the following error conditions occur during the programming process:
- a) loss of supplied power connection;
- b) loss of the ground connection;
- c) disruption of data link communication;
- d) over- or under-voltage conditions.
The boot software can be protected via hardware (e.g. via settings in a control register which prevents
certain sectors of the memory from being erased or written to) or software (e.g. address range
restrictions in the programming routines). It is recommended that the boot software not be capable of
being modified by the same programming erase/write routines that are used to modify the application
software and application data. Programming the boot software as part of the programming process may
be allowed, provided that a mechanism is in place to ensure that there is no possibility that the server
could fail at a point of the programming process where it cannot recover and be programmed with a
subsequent programming event.
Boot software resides in the boot memory partition and is the software that a server begins executing
upon power-up. Transfer of program control to the boot software also occurs once the server is
informed that it is about to be programmed (e.g. reference the DiagnosticSessionControl service and the
programming process defined in 17.2.1.2). A typical implementation showing the interactions and
transitions between the boot software and the application software is shown in Figure 47.
 |
Figure 47 — Example of typical interaction and transitions between application and boot software |
17.3.1.1.2 Boot software diagnostic service requirements
Table 501 to Table 503 define the minimum diagnostic service requirements for the boot software of a
programmable server. The listed services shall be supported in order to fulfil the requirements for
performing non-volatile server memory programming during programming phase #1. The tables make
use of the steps defined for programming phase #1 (see 17.2.1). The service(s) to be supported for
steps (1), (3) and (8) shall be defined by the vehicle manufacturer.
 |
Table 501 — Boot software diagnostic service support during preprogramming step of phase #1 |
NOTE
Table 501 only applies if the vehicle manufacturer supports the preprogramming step of phase #1.
 |
Table 502 — Boot software diagnostic service support during programming step of phase #1 |
 |
Table 503 — Boot software diagnostic service support during post-programming step of phase #1 |
17.3.1.2 Security requirements
All programmable servers that have emission, safety or theft related features shall employ a seed and
key security feature, accessible via the SecurityAccess (0x27) service, to protect the programmed server
from inadvertent erasure and unauthorized programming. All such field service replacement servers
shall be shipped to the field with the security feature activated (i.e. a programming tool cannot gain
access to the server without first gaining access through the SecurityAccess service).
17.3.2 Software, data identification and fingerprints
17.3.2.1 Software and data identification
The boot software, application software and application data may be identified via the dataIdentifiers
according to C.1. The structure of the dataRecord for bootSoftwareIdentification,
applicationSoftwareIdentification and applicationDataIdentification is vehicle manufacturer specific.
The bootSoftwareIdentification, applicationSoftwareIdentification and applicationDataIdentification
shall be part of each module that is downloaded into the server; therefore any write operation to the
defined dataIdentifiers shall be rejected by the server.
17.3.2.2 Software and data fingerprints
A fingerprint uniquely identifies the programming tool that erased and/or reprogrammed the server
software/data. If the server software/data is separated in several modules, the fingerprint could also
identify which software/data module is manipulated (e.g. boot software, application software, and
application data). If supported a fingerprint shall be written into non-volatile memory of the server
before any software/data manipulation occurs (e.g. before erasing the flash memory).
The boot software, application software and application data fingerprints may be identified via the
dataIdentifiers according to C.1.
The structure of the dataRecord for bootSoftwareFingerprint, applicationSoftwareFingerprint, and
applicationDataFingerprint is vehicle manufacturer specific.
17.3.3 Server routine access
Routines are used to perform non-volatile memory access such as erasing non-volatile memory and
checking the successful download of a module.
Table 504 specifies the standardized routineIdentifiers for non-volatile memory access. Other
routineIdentifier numbers used in the programming sequence are specified by the vehicle
manufacturer.
 |
Table 504 — routineIdentifiers for non-volatile memory access |
17.4 Non-volatile server memory programming message flow examples
17.4.1 General information
The following example presents CAN message traffic for a non-volatile server memory-programming
event of a single server. The given message flows are based on a single server and the transfer of two
modules, where each module has a length of 511 bytes. The network layer buffer size of the server that
is reprogrammed is 255 bytes (reported in the RequestDownload positive response message). The
programming example uses the 11 bit OBD CAN Identifiers as specified in ISO 15765-4. Therefore, all
frames shall be padded with filler bytes (DLC = 8). All CAN frames of a request message are padded with
a filler byte of 0x55. All CAN frames of a response message are padded with a filler byte of 0xAA.
NOTE
Filler bytes can have any value.
17.4.2 Programming phase #1 — Pre-Programming step
See Table 505 through Table 507.
 |
Table 505 — StartDiagnosticSessionControl(extendedSession) |
 |
Table 506 — ControlDTCSetting(off) |
 |
Table 507 — CommunicationControl(disableRxAndTx in the application) |
17.4.3 Programming phase #1 — Programming step
See Table 508 through Table 523.
 |
Table 508 — DiagnosticSessionControl(programmingSession) |
 |
Table 509 — SecurityAccess(requestSeed) |
 |
Table 510 — SecurityAccess(sendKey) |
 |
Table 511 — RoutineControl(eraseMemory) |
 |
Table 512 — RequestDownload — Module #1 |
 |
Table 513 — TransferData — Module #1 (block #1) |
 |
Table 514 — TransferData — Module #1 (block #2) |
 |
Table 515 — TransferData — Module #1 (block #3) |
 |
Table 516 — RequestTransferExit — Module #1 |
 |
Table 517 — RequestDownload — Module #2 |
 |
Table 518 — TransferData — Module #2 (block #1) |
 |
Table 519 — TransferData — Module #2 (block #2) |
 |
Table 520 — TransferData — Module #2 (block #3) |
 |
Table 521 — RequestTransferExit — Module #2 |
 |
Table 522 — RoutineControl(validate application) |
 |
Table 523 — WriteDataByIdentifier — dataIdentifier = VIN |
17.4.4 Programming phase #1 — Post-Programming step
For the Post-Programming step, see Table 524.
 |
Table 524 — ECUReset — hardReset |
Annex A (normative)
Global parameter definitions
A.1 Negative response codes
Table A.1 defines all negative response codes used within this document. Each diagnostic service
specifies applicable negative response codes. The diagnostic service implementation in the server may
also utilise additional and applicable negative response codes specified in this as defined by the vehicle
manufacturer.
The negative response code range 0x00 to 0xFF is divided into three ranges:
- 0x00: positiveResponse parameter value for server internal implementation,
- 0x01 to 0x7F: communication related negative response codes,
- 0x80 to 0xFF: negative response codes for specific conditions that are not correct at the point in time the request is received by the server. These response codes may be utilised whenever response code 2216 (conditionsNotCorrect) is listed as valid in order to report more specifically why the requested action cannot be taken.
 |
Table A.1 — Negative Response Code (NRC) definition and values |
Annex B (normative)
Diagnostic and communication management functional unit dataparameter definitions
B.1 communicationType parameter definition
The communicationType is a 1-Byte value. The bit-encoded low nibble of this byte represents the
communicationTypes, which can be controlled via the CommunicationControl (0x28) service. For
example, a communicationType with a bit combination (Bits 1 to 0) of "112" is valid and disables both
"normalCommunicationMessages" and "networkManagementCommunicationMessages" messages. The
high nibble of the communicationType 1-Byte value defines which of the subnets connected to the
receiving node shall be disabled/enabled when an appropriate CommunicationControl service is
received.
Table B.1 specifies the communicationType and subnetNumber byte.
 |
Table B.1 — Definition of communicationType and subnetNumber byte |
B.2 eventWindowTime parameter definition
Table B.2 specifies the eventWindowTime parameter values.
 |
Table B.2 — Definition of eventWindowTime parameter values |
B.3 linkControlModeIdentifier parameter definition
Table B.3 specifies the linkControlModeIdentifier values.
 |
Table B.3 — Definition of linkControlModeIdentifier values |
B.4 nodeIdentificationNumber parameter definition
The nodeIdentificationNumber is a 2-Byte value which represents a unique identification number of a
node somewhere connected to a network in the vehicle where the same node can be connected to
different networks in different car lines (e.g a LIN node with an unique node address is connected to
network A in one model while the same node is connected to network B in a different model). Therefore
the nodeIdentificationNumber provides a mechanism where the associated master node, which the
remote node is connected to, transitions the relevant network into a certain diagnostic mode (e.g.
disables normal communication on a LIN network). Only the associated master node, which has
detected the connection of the related node, identified by the nodeIdentificationNumber, shall perform
the requested communicationControl service.
NOTE
This parameter is only available if the controlType value is set to 0416 or 0516. Individual parameters are
defined by the vehicle manufacturer.
Table B.4 specifies the nodeIdentificationNumber values.
 |
Table B.4 — Definition of nodeIdentificationNumber values |
B.5 AuthenticationReturnParameter definitions
Table B.5 specifies the authenticationReturnParameter definitions.
 |
Table B.5 — authenticationReturnParameter definitions |
NOTE
The authenticationReturnParameter can be used individually, depending on how much information
should be given to the client (e.g. specific authenticationReturnParameter can be used while development time
and general authenticationReturnParameter can be used after production).
Annex C (normative)
Data transmission functional unit data-parameter definitions
C.1 DID parameter definitions
The parameter dataIdentifier (DID) logically represents an object (e.g. Air Inlet Door Position) or
collection of objects. This parameter shall be available in the server's memory. The dataIdentifier value
shall either exist in fixed memory or temporarily stored in RAM if defined dynamically by the service
dynamicallyDefineDataIdentifier. In general, a dataIdentifier is capable of being utilized in many
diagnostic service requests including 0x22 (readDataByIdentifier), 0x2E (writeDataByIdentifier), and 0x2F (inputOutputControlByIdentifier). A dataIdentifier is also used in various diagnostic service
responses (e.g. positive response to service 0x19 SubFunction readDTCSnapshotRecordByDTCNumber).
IMPORTANT
Regardless of which service a dataIdentifier is used with, it shall consistently represent
the same thing (i.e. a given object with a given size/meaning/etc.) on a given ECU.
The only case this does not apply to is the dynamically defined dataIdentifiers, as they are not
predefined in the ECU, but are defined by the client using service 0x2C (dynamicallyDefineDataIdentifier). DataIdentifier values are defined in Table C.1.
 |
Table C.1 — DID data-parameter definitions |
C.2 scalingByte parameter definitions
The parameter scalingByte (SBYT) consists of one byte (high and low nibble). The scalingByte high
nibble specifies the data type, which is used to represent the dataIdentifier (DID). The scalingByte low
nibble specifies the number of bytes used to represent the parameter in a datastream.
Table C.2 specifies the scalingByte (High Nibble) parameter.
 |
Table C.2 — scalingByte (High Nibble) parameter definitions |
Table C.3 specifies the scalingByte (Low Nibble) parameter.
 |
Table C.3 — scalingByte (Low Nibble) parameter definition |
C.3 scalingByteExtension parameter definitions
C.3.1 scalingByteExtension for scalingByte high nibble of bitMappedReportedWithOutMask
The parameter scalingByteExtension (SBYE) is only supported for scalingByte parameters with the high
nibble encoded as formula, unit/format, or bitMappedReportedWithOutMask.
A scalingByte with high nibble encoded as bitMappedReportedWithOutMask shall be followed by
scalingByteExtension bytes representing the validity mask for the bit mapped dataIdentifier. Each byte
shall indicate which bits of the corresponding dataIdentifier byte are supported for the current
application.
Table C.4 specifies the scalingByteExtension for bitMappedReportedWithOutMask.
 |
Table C.4 — scalingByteExtension for bitMappedReportedWithOutMask |
C.3.2 scalingByteExtension for scalingByte high nibble of formula
The parameter scalingByteExtension (SBYE) is only supported for scalingByte parameters with the high
nibble encoded as formula, unit/format, or bitMappedReportedWithOutMask.
A scalingByte with high nibble encoded as formula shall be followed by scalingByteExtension bytes
defining the formula. The scalingByteExtension consists of one byte formulaIdentifier and constants as
described in the table below.
Table C.5 specifies the scalingByteExtension Bytes for formula.
 |
Table C.5 — scalingByteExtension Bytes for formula |
Table C.6 specifies the formulaIdentifier encoding.
 |
Table C.6 — formulaIdentifier encoding |
Formulas are defined using variables (y, x, etc.) and constants (C0, C1, C2, etc.). The variable y is the
calculated value. The other variables, in consecutive order, are part of the data stream referenced by a
dataIdentifier. Each constant is expressed as a two byte real number defined in Table C.7. The two byte
real numbers (C = M * 10E) contain a 12 bit signed (2's complement) mantissa (M) and a 4 bit signed
(2's complement) exponent (E). The mantissa can hold values within the range –2 048 to +2 047, and
the exponent can scale the number by E-8 to E7. The exponent is encoded in the high nibble of the high
byte of the two byte real number. The mantissa is encoded in the low nibble of the high byte and the
complete low byte of the two byte real number.
 |
Table C.7 — Two byte real number format |
C.3.3 scalingByteExtension for scalingByte high nibble of unit/format
The parameter scalingByteExtension (SBYE) is only supported for scalingByte parameters with the high
nibble encoded as formula, unit/format, or bitMappedReportedWithOutMask.
A scalingByte with high nibble encoded as unit/format shall be followed by a single
scalingByteExtension byte defining the unit/format. The one byte scalingByteExtension is defined in
Table C.8. If combined units and/or formats are used, e.g. mV, then one scalingByte (and
scalingByteExtension) shall be included for each unit/format.
 |
Table C.8 — Unit/format scalingByteExtension encoding |
C.3.4 scalingByteExtension for scalingByte high nibble of stateAndConnectionType
A scalingByte with high nibble encoded as stateAndConnectionType shall be followed by a single
scalingByteExtension byte defining the stateAndConnectionType. The one byte scalingByteExtension is defined in Table C.9. The stateAndConnectionType encoding is used specially for input and output
signals. Encoded in the scalingByteExtension data byte is information about the physical layout,
electrical levels and functional state.
 |
Table C.9 — Encoding of scalingByte High Nibble of stateAndConnectionType |
C.4 transmissionMode parameter definitions
Table C.10 specifies the transmissionMode parameter.
 |
Table C.10 — transmissionMode parameter definitions |
C.5 Coding of UDS edition version number
Table C.11 specifies the coding of UDS version number DID FF0016 – 4 bytes unsigned value. The
specification release version of this document is: 3.0.0.0.
 |
Table C.11 — Coding of UDS edition version number DID FF0016 – 4 bytes unsigned value |
Table C.12 defines examples for V1.0.0.0, V2.0.0.0, and V3.0.0.0.
 |
Table C.12 — DID FF0016 UDS edition version values of this document |
Annex D (normative)
Stored data transmission functional unit data-parameter definitions
D.1 groupOfDTC parameter definition
Table D.1 provides group of DTC definitions.
 |
Table D.1 — Definition of groupOfDTC and range of DTC numbers |
D.2 DTCStatusMask and statusOfDTC bit definitions
D.2.1 Convention and definition
This subclause specifies the mapping of the DTCStatusMask/statusOfDTC parameters used with the
ReadDTCInformation service. Every server shall adhere to the convention for storing bit-packed DTC
status information as defined in the table below. Actual usage of the bit-fields shall be defined in the
implementation standards.
The status of the TestFailed bit shall not directly be linked to the failsafe behaviour associated with the
monitor status. That means for triggering of the failsafe behaviour which is associated with the status of
a certain monitor a separate set of status bits needs to be maintained. The vehicle manufacturer shall
define if and how any synchronisation mechanism between DTC status and failsafe relevant monitor
status is applied and implemented.
The following is a list of definitions used for the description of the DTC status bit definitions.
- Test: A test is an on-board diagnostic software algorithm that determines the malfunction status of operation cycle. Other tests can run every program loop, sampling as often as every few milliseconds. The end result of a test represents a completely matured/qualified condition (i.e. passed or failed). That means a test which needs a failing condition over a specific time or evaluation of additional plausibility checks before a component is considered to be failing will return a “Failed” condition only after all maturation criteria have been fulfilled. Each DTC is associated with a test representing a detectable fault symptom.
- Test Sample: A test sample represents the 'pass' or 'fail' result from a single instance of a DTC test execution when the test run criteria are met. This represents a single sample and therefore not generally a fully matured/qualified condition. For an ECU supporting the DTC Fault Detection Counter a test sample representing a fail will increase the DTC Fault Detection Counter by a specific amount and a test sample representing a pass will decrease the DTC Fault Detection Counter by a specific amount.
- Complete: Complete is an indication that a test was able to determine whether a malfunction exists or does not exist for the current operation cycle (complete does not imply failed).
- Test results: While a test runs or after it has completed it may indicate one the following results to the internal failure handler:
- PreFailed: This status may be used by tests in ECUs to indicate that the test is currently maturing a failure condition. One use case for this information is in manufacturing to speed up failure detection for optimised workflow while maintaining fault tolerance in the field.
- Failed: This status is available after a test has run to its completion and indicates a completely matured failing condition.
- Passed: This status is available after a test has run to its completion and indicates that the system or component is not failing.
- Failure: A failure is the inability of a component or system to meet its intended function. A failure has occurred when fault conditions have been detected for a sufficient period of time, implying that a test returned a “Failed” result. The terms "failure" and "malfunction" are interchangeable.
- Monitor: A monitor consists of one or more tests used to determine the proper functioning of a component or system.
- Monitoring cycle: A monitoring cycle is the time in which a monitor runs to its completeness. This is a manufacturer defined set of conditions during which the tests of a monitor can run. A monitoring cycle may be executed several times during an operation cycle or once over several operation cycles.
- Operation Cycle: An operation cycle specifies the start and end conditions for monitors to run. During an operation cycle several monitoring cycles may have completed (regardless of their test results). An ECU may support several operation cycles. For body and chassis ECUs it is up to the manufacturer to define an operation cycle (e.g. time between powering up and powering down the ECU or between ignition on and ignition off). For powertrain ECUs, there are additional criteria defining an operation cycle. Emissions-related powertrain ECUs use an engine-running or engineoff time period to define an operation cycle which is referred to as driving cycle. If a reset condition for a DTC status bit is associated with the beginning of the operation cycle, it might also be considered the end of the previous cycle (i.e. it is not always possible to distinguish the beginning versus the end of each operation cycle).
NOTE
For emissions-related monitors, the criteria for the beginning and the end of an operation cycle
are defined by legislation.
- Pending: The pending status of a failure is defined as a test having reported a “Failed” result for this test during the current operation cycle or during the last completed operation cycle. Once the test has reported a “Passed” condition for a complete operation cycle of this failure, the pending status is reset.
- Confirmation Threshold: The confirmed status of a failure is defined as a test having reported 'Failed' for this test for a given number of operation cycles where the test has run to completion. Typically for non-OBD use cases the threshold for operation cycles is defined as one. For OBD use cases this threshold is typically greater than one. Implementations may use a Trip Counter (see Figure D.9) as a trigger for changing the confirmed status from 0 to 1. The Trip Counter counts the number of operation cycles (driving cycles) where a malfunction occurred. If the counter reaches the threshold (e.g. 2 driving cycles) the confirmed bit changes from 0 to 1.
- Aging Threshold: The aging of a DTC is defined as a test having reported no 'Failed' result for a given number of vehicle manufacturer or regulation defined operation cylces and it is vehicle manufacturer specific if the respective cycle triggers incrementing the aging counter depending on whether the test has run to completion or not during the cycle. Implementations may use an aging counter (see Figure D.11) as a trigger for changing the confirmed status from 1 to 0 and erasing the DTC information from non-volatile memory. The aging counter counts the number of cycles (e.g. warm-up cycles) meeting the previously mentioned criteria. If this counter reaches the threshold (e.g. 40 warm-up cycles) the confirmed bit changes from 1 to 0.
- Driving cycle: A specific type of operation cycle used for emissions-related ECUs. Refer to “OperationCycle” for further details. In emissions-related ECUs only one operation cycle shall be supported, which is identical to the driving cycle as defined by legislation.
- Monitor Level Enable Conditions: The criteria/conditions for when a monitor is allowed to run and report a test result.
- DTC Status Update Condition: A condition where all DTC status bits are allowed to be updated by the monitor (e.g. controlDTCSetting DTCSettingType does not equal 'off"). This generic condition applies to all DTC status bit transitions [i.e. if this condition is false none of the transitions depicted in Figure D.1 to Figure D.8 shall be allowed except reset of the status bits triggered by the reception of a clearDiagnosticInformation command (see 10.8.1 and 12.2.1)].
- DTC Storage Condition: A condition defined by the vehicle manufacturer indicating whether the relevant DTC status bits and the related DTC data (e.g. DTC Extended or Snapshot data) that is capable of being updated is updated and stored in non-volatile memory.
D.2.2 Pseudocode data dictionary
The pseudocode data dictionary defines variables used in the pseudocode definition for each
statusOfDTC bit.
Table D.2 specifies the Pseudocode data dictionary.
 |
Table D.2 — Pseudocode data dictionary |
D.2.3 DTC status bit definitions
Table D.3 specifies the DTC status bit '0' testFailed.
 |
Table D.3 — DTC status bit 0 testFailed definitions |
Figure D.1 specifies the DTC status bit '0' testFailed logic.
 |
Figure D.1 — DTC status bit 0 testFailed logic |
Table D.4 specifies the DTC status bit '1' testFailedThisOperationCycle.
 |
Table D.4 — DTC status bit 1 testFailedThisOperationCycle definitions |
Figure D.2 specifies the DTC status bit '1' testFailedThisOperationCycle logic.
 |
Figure D.2 — DTC status bit 1 testFailedThisOperationCycle logic |
Table D.5 specifies the DTC status bit '2' pendingDTC.
 |
Table D.5 — DTC status bit 2 pendingDTC definitions |
Figure D.3 specifies the DTC status bit '2' pendingDTC logic.
 |
Figure D.3 — DTC status bit 2 pendingDTC logic |
Table D.6 specifies the DTC status bit '3' confirmedDTC.
 |
Table D.6 — DTC status bit 3 confirmedDTC definitions |
Figure D.4 specifies the DTC status bit '3' confirmedDTC logic.
 |
Figure D.4 — DTC status bit 3 confirmedDTC logic |
Table D.7 specifies the DTC status bit '4' testNotCompletedSinceLastClear.
 |
Table D.7 — DTC status bit 4 testNotCompletedSinceLastClear definitions |
Figure D.5 specifies the DTC status bit '4' testNotCompletedSinceLastClear logic.
 |
Figure D.5 — DTC status bit 4 testNotCompletedSinceLastClear logic |
Table D.8 specifies the DTC status bit '5' testFailedSinceLastClear.
 |
Table D.8 — DTC status bit 5 testFailedSinceLastClear definitions |
Figure D.6 specifies the DTC status bit '5' testFailedSinceLastClear logic.
 |
Figure D.6 — DTC status bit 5 testFailedSinceLastClear logic |
Table D.9 specifies the DTC status bit '6' testNotCompletedThisOperationCycle.
 |
Table D.9 — DTC status bit 6 testNotCompletedThisOperationCycle definition |
Figure D.7 specifies the DTC status bit '6' testNotCompletedThisOperationCycle logic.
 |
Figure D.7 — DTC status bit 6 testNotCompletedThisOperationCycle logic |
Table D.10 specifies the DTC status bit '7' WarningIndicator requested.
 |
Table D.10 — DTC status bit 7 WarningIndicator requested definitions |
Figure D.8 specifies the DTC status bit '7' WarningIndicator requested logic.
 |
Figure D.8 — DTC status bit 7 WarningIndicator requested logic |
D.2.4 Example for operation of DTC Status Bits
This example provides an overview on the operation of the DTC status bits in a two operation cycle
emissions-related OBD DTC. The figure shows the handling for a two operation cycle emissions-related
OBD DTC. The handling can also be applied to non-emissions-related OBD DTCs and is shown here for
general informational purposes.
Figure D.9 defines an example of a two operation cycle emissions-related OBD DTC.
 |
Figure D.9 — Example of a two operation cycle emissions-related OBD DTC |
D.3 DTC severity and class definition
D.3.1 DTC severity and class byte definition
This subclause specifies the mapping of the DTCSeverityMask/DTCSeverity parameters used with the
ReadDTCInformation service. Every server shall adhere to the convention for storing bit-packed DTC
severity information as defined in Table D.11.
The DTCSeverityMask/DTCSeverity byte contains DTC severity and DTC class information. The
DTCSeverityMask/DTCSeverity byte is reported in a 1-Byte value as defined in Table D.11. The optional
upper 3 bits (bit 7 to 5) of the 1-Byte value are used to represent the DTC severity information. If not
supported by the server those bits shall be set to "0". The mandatory lower 5 bits (bit 4 to 0) of the 1-
Byte value are used to represent the DTC class information.
 |
Table D.11 — DTCSeverityMask/DTCSeverity byte definition |
D.3.2 DTC severity bit definition
The DTC severity bit definition defines bit states to report the recommended action to be taken by the
system (e.g. vehicle) operator. Table D.12 defines DTC severity status bits.
 |
Table D.12 — DTC severity bit definitions (bit 7 to 5) |
D.3.3 DTC class definition
The DTC class definitions apply to OBD systems which comply with the VOBD GTR. Class A, B1, B2 or C
are attributes of an emissions-related DTC. These attributes characterise the impact of a malfunction on
emissions or on the OBD system's monitoring capability according to the requirements of the VOBD
GTR.
The DTC class information contained within a diagnostic request is allowed to have more than one bit
set to 1 in order to request information for multiple DTC classes. The DTC class information contained
within a diagnostic response shall only ever have a single bit set to 1. Table D.13 specifies the GTR DTC
Class definition (bit 4 to 0).
 |
Table D.13 — GTR DTC Class definition (bit 4 to 0) |
D.4 DTCFormatIdentifier definition
This parameter value specifies the format of a DTC reported by the server. A given server shall support
only one DTCFormatIdentifier. See Table D.14.
 |
Table D.14 — Definition of DTCFormatIdentifier (DTCFID_) |
D.5 FunctionalGroupIdentifier definition
The FunctionalGroupIdentifier specifies different functional system groups. The identifier is used to
distinguish commands sent by the test equipment between different functional system groups within an
electrical architecture which consists of many different servers. If a server has implemented software of
the emissions system as well as other systems which may be inspected during an I/M test, it is
important that only the DTC information of the requested functional system group is reported. An
emissions I/M test should not be failed because another functional system group (e.g. safety system
group) has DTC information stored.
The FunctionalGroupIdentifier specifies a functional system group for the purpose of:
- Requesting DTC status information from a vehicle, and
- Clearing DTC information in the vehicle.
The main purpose is to be able to report/clear DTC information specific to a functional system group.
An ECU may be part of several functional system groups, e.g. emissions system, brake system, etc. In
case DTCs are reported for the brake system during an emissions inspection & maintenance (I/M) test
the vehicle shall not fail the emissions I/M test because the ECU, which is part of the emissions
functional system, also reports brake functional system DTCs.
Table D.15 specifies the FunctionalGroupIdentifiers.
 |
Table D.15 — Definition of FunctionalGroupIdentifiers (FGID_) |
D.6 DTCFaultDetectionCounter operation implementation example
The DTC fault detection counter operation for non-emissions related servers is shown in Figure D.10.
 |
Figure D.10 — Example of DTCFaultDetectionCounter operation for non-emissions related server |
D.7 DTCAgingCounter example
This example provides an overview on the operation of a DTCAgingCounter which counts number of
driving cycles since the fault was latest failed.
Figure D.11 specifies the DTCAgingCounter example.
 |
Figure D.11 — DTCAgingCounter example |
D.8 DTCExtendedDataRecordNumber value definition
Table D.16 specifies the ranges and values of the DTCExtendedDataRecordNumber parameter.
 |
Table D.16 — DTCExtendedDataRecordNumber value definition |
Annex E (normative)
Input output control functional unit data-parameter definitions
Table E.1 specifies the inputOutputControlParameter.
 |
Table E.1 — inputOutputControlParameter definitions |
Annex F (normative)
Routine functional unit data-parameter definitions
Table F.1 specifies the routineIdentifier.
 |
Table F.1 — routineIdentifier definition |
Annex G (normative)
Upload and download functional unit data-parameter
The RequestFileTransfer request message contains the modeOfOperation parameter. The values are
defined in Table G.1.
 |
Table G.1 — Definition of modeOfOperation values |
Annex H (informative)
Examples for addressAndLengthFormatIdentifier parameter values
Table H.1 contains examples of combinations of values for the high and low nibble of the
addressAndLengthFormatIdentifier. The following should be considered:
- Values, which are either marked as "not applicable" for the "manageable memorySize" or the "memoryAddress range", are not allowed to be used and should be rejected by the server via a negative response message.
- Values with an applicable "manageable memorySize" and "memoryAddress range" are allowed for this parameter
 |
Table H.1 — addressAndLengthFormatIdentifier example |
Annex I (normative)
Security access state chart
I.1 General
The purpose of this annex is to describe the SecurityAccess service handling in an ECU, based on a state
chart with state transition conditions and action definitions. The following is the base for the definition:
- Usage of the disjunctive normal form in order to have single transitions defined between and within the states.
- Definition of “disjunctive normal form”: “A statement is in disjunctive normal form if it is a disjunction (sequence of ORs) consisting of one or more disjuncts, each of which is a conjunction (AND) of one or more literals”.
I.2 Disjunctive normal form based state transition definitions
Figure I.1 graphically depicts the state chart for the SecurityAccess handling. The given numbers
reference state transition conditions and actions to be performed on the transition.
 |
Figure I.1 — SecurityAccess state chart |
The state chart takes into account that the general session handling is done at the proper place within
the session management layer (see ISO 14229-2) and therefore is not considered in the state-chart.
The state transition definitions make use of some parameters that can be set according to vehicle
manufacturer specific requirements. The support of Delay_Timer and Att_Cnt parameters is optional
and decided by the vehicle manufacturer. In general, for longer seed/key lengths (e.g. 16 bytes and
beyond) the support of these parameters is no longer as important.
Table I.1 specifies the state transitions – parameters.
 |
Table I.1 — State transitions – parameters |
Legend:
- AND, OR logical operation
- Italic optional, customer specific
- “==” equal (comparison operator)
- “=” assignment operator
- “<>” un-equal
- “<” less than
- “>” greater than
- “+” mathematical addition
- “-” mathematical subtraction
- “++” increment operator (variable++ is the same as variable = variable + 1)
Table I.2 includes the complete set of state transition definitions.
 |
Table I.2 — State transitions – disjunctive normal form representation |
It shall be considered that when defining the state transitions via multiple conjunctions which are ORed together, and each conjunction has an action applied, that only one of the conjunctions of a
disjunction becomes true at a time and forces a state transition in order to only execute one of the
actions for a certain state transition defined (e.g. only single negative response to be transmitted).
Annex J (informative)
Recommended implementation for multiple client environments
J.1 Introduction
This annex is intended to address the increasing number of use cases where the diagnostic vehicle
topology is extended by adding one or more onboard diagnostic clients to the basic diagnostic topology
with a single diagnostic client (external test equipment) and multiple servers (ECUs in vehicle).
This document and the normative references herein do not limit the number of diagnostic
communication channels that a server can support. The design of such a server-implementation for
multi-client handling, should take into account that there are specifications and restrictions which force
certain diagnostic clients to be served with a higher priority than others, e.g. to fulfil existing legislative
OBD requirements. In this case the vehicle system design should ensure that parallel client requests can
be handled by the respective server(s).
An example for such a scenario would be an internal data logger which is connected to a server in
parallel to an OBD scan tool externally connected to the diagnostic connector.
Either the overall vehicle design accounts for this parallel handling of client requests (e.g. gateway
arbiter mechanism) or the individual servers should implement new strategies to assign the available
resources to different clients. In the server either the protocol implementation or the available
resources are unique and can only be accessed by one client at a time.
This annex describes the implementation on server level only. It is the vehicle manufacturer's
responsibility to select a mechanism which fits its individual needs best.
J.2 Implementation specific limitations
A unique Address Information should be assigned to each communication participant to allow the
detection of different clients, which then can be used to limit the functionality or to assign priorities.
If the vehicle manufacturer's design does not use unique address information for certain peer protocol
entities, the implementation described in this annex does not apply. In this case, the vehicle design
should ensure that the chosen approach for handling of multiple clients fulfils the legislative
requirements.
J.3 Use cases relevant for system design
Figure J.1 shows an example of a vehicle topology where multiple clients exist.
 |
Figure J.1 — Example vehicle topology with onboard clients |
The implementation described in this document is intended to fulfil the use cases summarized in
Figure J.1. All use case scenarios marked with an 'N/A' in the table below are not described as part of
this document. It is highly recommended to avoid such scenarios. The implementation and design rules
specified in this annex are not intended to support OBD communication requirements beyond the
scenarios defined in Table J.1.
 |
Table J.1 — Use case (UC) matrix of multiple client scenarios to be addressed |
When referring to the term 'test equipment in use' it should be differentiated between the server
perspective and the client perspective as follows:
- from a server perspective a test tool is considered in use if a request is currently processed or a non-default session is active;
- from a client perspective a test tool is considered in use if an expected response has not yet been received, P3 client is not expired yet or a non-default session is active.
When referring to the term 'additional test equipment' the following definition applies:
- a test equipment in this context is considered 'additional' if another tool is in use (refer to definition of test tool in use).
When referring to the term 'OBD scan (tool) test equipment' the following definition applies:
- On-Board Diagnostic (OBD) regulations require passenger cars and light, medium and heavy duty trucks to support communication of a minimum set of diagnostic information with off-board test equipment according to SAE J1978/ISO 15031-4. A vehicle is considered non-compliant if the communication with the test equipment (e.g. handheld scan tools, PC based diagnostic computers, etc.) cannot be conducted as defined by the appropriate standards.
When referring to the term 'OEM service test equipment' the following definition applies:
- An OEM specified test equipment which fulfils the OEM requirements and utilizes proprietary address information. The OEM Service test equipment may utilize standardized parts, i.e. SAE J2534 to communicate between the application and the Service tool hardware, but the communication to the vehicle utilizes OEM proprietary information.
When referring to the term 'on-board client' the following definition applies:
- An ECU which may include at least a diagnostic client part but also may include a diagnostic server part. The client part has functionality to sent diagnostic service requests to other servers in the vehicle. An example may be a telematics gateway which can be integrated into an ECU which also includes other functionality. The telematics gateway will act as a server if an OEM Service tool is connected to the diagnostic connector and requests data from the telematic gateway, but the telematic gateway itself also acts as a client requesting data from the other servers in the vehicle.
J.4 Use case evaluation
Table J.2 is intended to guide the decision what kind of concept the system designer should select.
 |
Table J.2 — Evaluation of multiple client use cases |
J.5 Multiple client server level implementation
J.5.1 Definition of diagnostic protocol
In this context a diagnostic communication protocol is a compilation of specific parameter values
depending on the Address Information (e.g. protocol buffer size, session timings, supported services,
security levels).
A protocol is identified by a communication path established between peer protocol entities. Each peer
protocol entity has exactly one unique physical address, and 0 to n functional addresses (for the
server(s)) identified by the respective N_AI.
NOTE 1
That means one single address cannot be used for different protocols.
NOTE 2
As defined in this document, there is only one diagnostic session state and one security level state
active at a time in one specific ECU and shared over all active protocols.
J.5.2 Assumptions
A protocol can either have exclusive protocol resources or multiple protocols can share one protocol
resource.
The OBD scan (tool) test equipment client address has either the highest priority or an exclusive
protocol resource is assigned to this address ensuring that the legislative requirements can be fulfilled.
J.5.3 Multiple client handling flow
If a server implements multiple client handling on server level the implementation should adhere to the
flow chart depicted in Figure J.2.
 |
Figure J.2 — Multiple client handling flow |
Bibliography
[1] ISO 4092:1988/Cor.1:1991, Road vehicles — Diagnostic systems for motor vehicles — Vocabulary —
Technical Corrigendum 1
[2] ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model:
The Basic Model
[3] ISO/IEC 7618-8:2006, Identification cards — Integrated circuit cards
[4] ISO/TR 8509:1987, Information processing systems — Open Systems Interconnection — Service
conventions
[5] ISO/IEC 9798-2, IT Security techniques — Entity authentication — Part 2: Mechanisms using
authenticated encryption
[6] ISO/IEC 9798-3, IT Security techniques — Entity authentication — Part 3: Mechanisms using digital
signature techniques
[7] ISO/IEC 9798-4, Information technology — Security techniques — Entity authentication — Part 4:
Mechanisms using a cryptographic check function
[8] ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference
Model — Conventions for the definition of OSI services
[9] ISO 11992-4, Road vehicles — Interchange of digital information on electrical connections between
towing and towed vehicles — Part 4: Diagnostics
[10] ISO 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic
services on CAN implementation (UDSonCAN)
[11] ISO 14229-4, Road vehicles — Unified diagnostic services (UDS) — Part 4: Unified diagnostic
services on FlexRay implementation (UDSonFR)
[12] ISO 14229-5, Road vehicles — Unified diagnostic services (UDS) — Part 5: Unified diagnostic
services on Internet Protocol implementation (UDSonIP)
[13] ISO 14229-6, Road vehicles — Unified diagnostic services (UDS) — Part 6: Unified diagnostic
services on K-Line implementation (UDSonK-Line)
[14] ISO 14229-7, Road vehicles — Unified diagnostic services (UDS) — Part 7: UDS on local
interconnect network (UDSonLIN)
[15] ISO 14229-8, Road vehicles — Unified diagnostic services (UDS) — Part 8: Unified diagnostic
services on clock extension peripheral interface implementation (UDSonCXPI)
[16] ISO 15031-2, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 2: Guidance on terms, definitions, abbreviations and
acronyms
[17] ISO 15031-6, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 6: Diagnostic trouble code definitions
[18] ISO 15765-4, Road vehicles — Diagnostic communication over Controller Area Network
(DoCAN) — Part 4: Requirements for emissions-related systems
[19] ISO 22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model
specification
[20] ISO 26021-2, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 2:
Communication requirements
[21] ISO 27145-2, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics
(VOBD) communication requirements — Part 2: Common data dictionary
[22] ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics
(VOBD) communication requirements — Part 3: Common message dictionary
[23] SAE J1939:2011, Serial Control and Communications Heavy Duty Vehicle Network — Top Level
Document
[24] SAE J1939-73:2010, Application Layer — Diagnostics
[25] ISO 10681-2, Road vehicles — Communication on FlexRay — Part 2: Communication layer services
[26] ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and
physical signalling
[27] ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access
unit
[28] ISO 13400-2, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 2:
Transport protocol and network layer services
[29] ISO 13400-3, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 3:
Wired vehicle interface based on IEEE 802.3
[30] ISO 14230-1, Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 1:
Physical layer
[31] ISO 14230-2, Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data
link layer
[32] ISO 15031-4, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 4: External test equipment
[33] ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 5: Emissions-related diagnostic services
[34] ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN)
— Part 2: Transport protocol and network layer services
[35] ISO 16844-7, Road vehicles — Tachograph systems — Part 7: Parameters
[36] ISO 17458-2, Road vehicles — FlexRay communications system — Part 2: Data link layer
specification
[37] ISO 17458-4, Road vehicles — FlexRay communications system — Part 4: Electrical physical layer
specification
[38] ISO 17987-2, Road vehicles — Local Interconnect Network (LIN) — Part 2: Transport protocol and
network layer services
[39] ISO 17987-3, Road vehicles — Local Interconnect Network (LIN) — Part 3: Protocol specification
[40] ISO 17987-4, Road vehicles — Local Interconnect Network (LIN) — Part 4: Electrical physical
layer (EPL) specification 12 V/24 V
[41] ISO 20794-3, Road vehicles — Clock extension peripheral interface (CXPI) — Part 3: Transport and
network layer
[42] ISO 20794-4, Road vehicles — Clock extension peripheral interface (CXPI) — Part 4: Data link
layer and physical layer
[43] ISO 26021-2, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 2:
Communication requirements
[44] ISO 27145-4, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics
(WWH-OBD) communication requirements — Part 4: Connection between vehicle and test
equipment
[45] IEEE 802.3, IEEE Standard for Ethernet
[46] SAE J1978, OBD II Scan Tool — Equivalent to ISO/DIS 15031-4:December 14, 2001
[47] SAE J1979, E/E Diagnostic Test Modes
[48] SAE J1979-2, Compliant OBDII Scan Tool
[49] SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes
[50] SAE J2012, Diagnostic Trouble Code Definitions
[51] SAE J2534, Recommended Practice for Pass-Thru Vehicle Programming (STABILIZED Jul 2019)
[52] ISO 15765-5, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN)
— Part 5: Specification for an in-vehicle network connected to the diagnostic link connector
评论
发表评论