ISO14229-1-2013 UDS 汉译笔记（第1~7章）

前言

ISO（国际标准化组织）是全球多国标准实体联盟（ISO成员）。其工作通常由ISO技术委员会来推出国际标准。已成立技术委员会的各组织成员均有权对其感兴趣主题参与该委员会。与ISO关联的国际组织、政府及非政府组织经常参与相关工作。ISO与国际电工协会（IEC）所有电工标准有紧密合作。

国际标准有ISO/IEC第二部分提出的指导进行起草，

各技术委员会主要负责制定国际标准，国际标准草案在各技术委员会传阅投票表决通过，国际标准在75%以上成员投票通过后才能刊发。

需要注意的是文件中某些部分可能涉及专利事宜，在此ISO不负责甄别专利。

ISO 14229-1有ISO/TC 22技术委员会，道路车辆，SC 3组，电气电子设备组编制。

经过技术修订，该第二版完全取代第一版（ISO 14229-2006）。

ISO 14229在总标题“道路车辆——统一诊断服务”以下包含以下部分：

• 第一部分：规范和要求

• 第二部分：会话层服务

• 第三部分：同意诊断服务和CAN实现（UDSonCAN）

• 第四部分：统一诊断服务在FlexRay上实现（UDSonFR）

• 第五部分：统一诊断服务在因特网环境实现（UDSonIP）

• 第六部分：统一诊断服务在K-Line实现（UDSonK-Line）

以下部分正在编写：

• 第七部分：统一诊断服务在LIN上实现（UDSonLIN）

• 第N部分，统一诊断服务在...上实现（UDSon...）

介绍

ISO 14229建立了诊断系统独立于数据链路的通用需求。

为达到上述目标，ISO 14229基于开放系统互连（OSI）与基本参考模型ISO 7498-1和ISO/IEC 10731一致的七层通信系统。表1中映射了此模型，若干用于诊断仪（客户端）和电子控制单元（ECU）的服务分为以下层次：

• 应用层（第七层）统一诊断规范：ISO 14229-1，ISO 14229-3 UDSonCAN，ISO 14229-4 UDSonFR，ISO 14229-5 UDSonIP，ISO 14229-6 UDSonK-Line，ISO 14229-7 UDSonLIN，为来实现的标准和ISO 27145-3 WWH-OBD。

• 表示层（第六层），车辆制造商指定，ISO°27145-2 WWH-OBD。

• 会话层服务（第五层） ISO 14229-2指定

• 传输层服务（第四层）ISO 15765-2 DoCAN，ISO 10681-2 Communication on FlexRay，ISO 13400-2 DoIP，ISO 17987-2 LIN，ISO 27145-4 WWH-OBD指定。

• 网络层服务（第三层）ISO 15765-2 DoCAN，ISO 10681-2 Communication on FlexRay，ISO 13400-2 DoIP，ISO 17987-2 LIN，ISO 27145-4 WWH-OBD中指定

• 数据链路层（第二层）SO 11898-1，ISO 11898-2，ISO 17458-2，ISO 13400-3，IEEE 802.3，ISO 14230-2，ISO 17987-3 LIN 与未来的标准规范，ISO 27145-4 WWH-OBD中指定

• 物理层（第一层）ISO 11898-1，ISO 11898-2，ISO 17458-4，ISO 13400-3，IEEE 802.3，ISO 14230-1，ISO 17987-4 LIN与未来的标准规范，ISO 27145-4 WWH-OBD中指定

注意    本标准规范的诊断服务是由不同应用所实现的，例如：道路车辆行车记录仪，道路车辆牵引车与被牵引车数字信息交互，道路车辆诊断系统等。需要本规范后续修改要长期向后兼容。

表1 - 适用于OSI层次结构的诊断或编程规范

适用性	OSI七层	增强诊断服务						WWH-OBD
依照 ISO/IEC 7498-1和 ISO/IEC 10731 的七层	应用层7	ISO 14229-1, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5						ISO 27145-3
	表现层6	车辆制造商特定						ISO 27145-2
	会话层5	ISO 14229-2
	传输层4	ISO 15765-2	ISO 10681-2	ISO 13400-2	未实现	ISO 17987-2	标准待实现	ISO 27145-4
	网络层3						标准待实现
	链路层2	ISO 11898-1, ISO 11898-2	ISO 17458-2	ISO 13400-3, IEEE 802.3	ISO 14230-2	ISO 17987-3	标准待实现
	物理层1		ISO 17458-4		ISO 14230-1	ISO 17987-4	标准待实现

道路车辆 - 统一诊断服务（UDS）——

第一部分：

规范和要求

1 范围

本部分内容指定了独立于数据链路层的诊断服务，它允许诊断仪（客户端）控制车辆ECU（服务器）中的诊断功能，例如燃油电喷、自动挡变速箱、防抱死系统等通过车辆内置数据链路互联的单元。也指定诊断仪（客户端）启停数据链路上非诊断消息传输的一般服务。

ISO 14229在本部分中不适用于车辆数据链路上两个ECU间非诊断消息传输，但ISO 14229的该部分不限制车载诊断仪（客户端）作为ECU使用数据链路诊断服务，以实现双向诊断数据交换。

ISO 14229 的本部分不限具体实施细则。

2 标准参考

本文有必须参考下列参考文件，凡注明日期的引用，仅使用所提及的版本；对未注明日期的引用，默认使用其最终版本（包含修正案）。

ISO 14229-2，道路车辆 - 统一诊断服务（UDS） - 第二部分：会话层服务

3 术语，定义，符号和简称

3.1 术语和定义

下列术语定义适用于本文件。

3.1.1 boot manager

引导管理器（boot manager）是ECU上电或重置后直接执行的软件，它仅用于检查有效的应用是否可执行转移控制权到再编程软件。

注意    boot manager 可被看作转移控制权到再编程软件的其他条件。

3.1.2 boot memory partition

引导内存（boot memory partition）是引导程序（boot software）所在的服务器内存区域。

3.1.3 boot software

引导程序（boot software）是运行在服务器特定内存区域运行的程序，用于首先引导ECU并执行服务器程序。

注意 1    该内存区域（指boot software所运行内存区域）普通编程序列无法擦除，并且当服务器应用丢失或无效需要再编程时需要被执行。

注意 2    参考 3.1.1 和 3.1.17

3.1.4 客户端

客户端（client）是诊断仪（tester）的一部分功能，用于执行诊断服务。

注意    诊断仪也会用于其他功能，例如数据库管理、规范解析、人机界面。

3.1.5 诊断数据

诊断数据（diagnostic data）位于ECU内存中，可被诊断仪检查和修改。

注意1    诊断数据包含模拟输入输出、数字输入输出、中间值和状态改变信息。

注意2    诊断数据例如车速、节气门角度、后视镜位置、系统状态等，诊断数据中定义了三种值的类型：

• 当前值：用于ECU的一般操作，或由该操作而产生。

• 存储值：在特殊情况下（例如临时或周期性故障）由ECU产生的内部拷贝。

• 静态值：例如车辆VIN码。

服务器不负责保持以诊断为目的内部数据拷贝，这种情况下诊断仪可能只会获取当前值。

注意3    定义返修和开发测试会话会选择不同服务器功能。（例如要操作整个内存区仅开发测试会话能提供对应权限）

3.1.6 诊断例程

诊断例程嵌入于ECU内部，由客户端请求触发执行。

注意    执行例程（而非一般操作程序）或者启用此模式执行一般操作程序。第一种情况下服务器上不能执行一般操作程序；第二种情况下可能启用并运行多个诊断例程，ECU其他功能不受影响。

3.1.7 诊断服务

诊断服务（diagnostic service）是从客户端发起请求服务器信息或修改服务器行为以进行诊断。

3.1.8 诊断会话

诊断会话（diagnostic session）是服务器中一些特定的诊断服务和启用功能的集合。

3.1.9 诊断故障码 DTC

诊断故障码DTC（diagnostic trouble code）【译注：以下中文简称为“故障码”】是由车载诊断系统（OBD）识别的通用错误码，可以标识环境条件错误。

3.1.10 ECU

电子控制单元（electronic control unit: ECU）包含至少一个服务器。

注意    防抱死系统（Anti-lock Breaking System: ABS）、发动机管理系统（Engine Management System）被认为是ECU。

3.1.11 功能单元

功能单元（Functional Unit）是一批功能上接近或互补的诊断服务集。

3.1.12 整数类型

整数类型（integer type）是具有不同值的正、负整数和“0”的简单数据类型。

注意    整数类型取值范围不在ISO 14229中定义

3.1.13 本地客户端

本地客户端（local client）与服务器处于同一本地网络，且处于同一地址空间。

3.1.14 本地服务器

本地服务器（local server）与客户端处于同一本地网络，且处于同一地址空间。

3.1.15 OSI

开放系统互连（open system interconnection）

3.1.16 永久故障码

永久故障码（permanent DTC）保存在非易失性存储器中，清除DTC请求对其无效。直到其他标准得到满足（通常为监管性标准，例如每个DTC对应的监控都成功通过）。

注意    必要条件请参照相关法规。

3.1.17 记录

记录（record）是通过单一手段识别一个或若干互相关联的诊断数据元素。

注意    快照（snapshot）是一个包含各种输入输出数据和错误码的记录样本。

3.1.18 远程服务器

远程服务器（remote server）不直连于主诊断网。

注意 1    远程地址（remote address）用于标识远程服务器，远程地址代表其自己的——独立于主网的——地址空间。

注意 2    远程服务器可以在主网由本地服务器（local server）访问，主网中各本地服务器可充当一组远程服务器的访问入口，一对地址需要标识远程服务器：一个是位于本地作为访问远程服务器的入口的标识，另一个作为远程服务器本身的标识。

3.1.19 远程客户端

远程客户端（remote client）不直连于主诊断网。

注意 1    远程客户端通过远程地址标识

注意 2    远程地址代表其自身地址空间，其独立于主网地址。

3.1.20 再编程软件

再编程软件（reprogramming software）作为引导程序的一部分，接受对电子控制单元的重新编程。

3.1.21 安全

安全（security）机制用于保护车辆模块免受数据链路上未授权的入侵危害。

3.1.22 服务器

服务器（server）功能作为电子控制单元的一部分负责提供诊断服务。

注意    国际标准为使标准规范和实现方式的解耦，对服务器（亦即：功能，function）和电子控制单元进行了区分。

3.1.23 DTC支持

诊断故障码（DTC）在当前配置和标定后被启用，并能在预设的车辆状态下运行。

3.1.24 诊断仪

诊断仪（tester）系统对车辆电子控制单元进行注入测试、检查、监控、诊断，也可以进行专门的操作类型（例如：专供车库设备使用的车外扫描工具、专供生产线使用的车外测试设备，抑或车内诊断仪）。

注意    诊断仪（tester）即客户端（client）

3.2 缩写

缩写	描述
.con	.confirmation 服务原语
.ind	.indication 服务原语_（译者注：用于向更高层或应用层传递状态信息以及接收到的数据）_
.req	.request 服务原语_（译者注：请求服务原语用于向网络层传递控制报文信息和要发送的数据）_
A_PCI	服务层协议控制信息
ECU	电子控制单元
EDR	事件数据记录
N/A	不适用
NR_SI	否定响应服务标识
NRC	否定响应码
OSI	开放系统互联
RA	远程地址
SA	源地址
SI	服务标识
TA	目标地址
TA_TYPE	目标地址类型

4 公约

本公约部分ISO 14229基于OSI服务公约中所研讨的——适用于诊断服务的——内容（ISO/IEC 10731:1994）。

该公约适特为服务使用者和服务提供者之间交互。信息在服务使用者和服务提供者之间通过服务原语传递，服务原语可作为参数传输载体。

图1总结了服务和协议的区别

图1-服务和协议

这部分ISO 14229定义了确认和未确认服务。

确认服务使用六个服务原语：request（译注：请求服务原语用于向网络层传递控制报文信息以及要发送的数据，应用于更高层或应用层，如ECU收到了Tester的数据，传至应用层），req_confirm，indication（译注：指示原语用于向更高层或应用层传递状态信息及接收到的数据，应用于网络层，如ECU接收到了Tester的数据，传至应用层），response（响应），rsp_confirm（相应确认）和confirmation（译注：被网络层使用，用于向更高层或应用层传递状态信息，如Tester收到了ECU方面的数据）。
译注：

未确认服务仅使用request，req_confirm和indication三个服务原语。

本部分ISO 14229中定义的请求（request）和指示（indication）服务原语通常具有相同的格式和参数。因此所有服务的响应和确认的服务原语通常具有相同的格式和参数（除 req_confirm 和 rsp_confirm之外）。在国际标准中定义服务原语时，仅列举了有请求和响应服务原语。

5 文件概述

图2对依据OSI模型实现的UDS文件引述进行了描述

图2 UDS依据OSI模型文件参考

6 应用层服务

6.1 概述

应用层服务通常被称为诊断服务，在基于客户端-服务器端的系统中执行诸如检测、检查、监控或车载服务器诊断功能。客户端通常作为外部检测设备，通过应用层服务向若干服务器发出请求使其执行诊断功能；服务器一般作为ECU的一部分功能，通过应用层服务向客户端返回其所请求诊断服务的响应数据。一般情况下客户端即非车载诊断仪（tester以下均称“诊断仪”），但在某些系统中的客户端会是车载诊断仪。但应用层服务用例与客户端是车载诊断仪还是非车载诊断仪无关。有同一个车辆系统中存在多个客户端的可能。

诊断应用层提供的服务入口具有多个相同结构的服务。每个服务都指定了六个服务原语：其中一个供客户端诊断仪应用程序使用的服务请求原语，发送请求诊断服务的数据到诊断应用层。

• 服务请求原语，用于在诊断仪应用程序的客户端功能传送请求诊断服务相关数据到诊断应用层。

• 服务请求确认原语，用于诊断仪应用程序中的客户端功能，指示服务请求原语成功发送到车辆通信总线。

• 服务指示原语，用于诊断应用层传输数据到ECU诊断应用程序的服务器功能。

• 服务响应原语 ，用于ECU诊断应用程序中的服务器功能，传输由请求诊断服务到诊断应用层的响应数据。

• 服务确认原语，用于诊断应用层传输数据到诊断仪应用程序的客户端功能。

图 3 描述了应用层服务原语

图 3 应用层服务原语 - 服务确认

图 4 描述了应用层服务原语 - 服务未确认

图 4 应用层服务原语 - 服务未确认

对于给定服务请求确认原语（request-confirm）和响应确认原语（response-confirm）通常具有相同的数据单元，这些服务原语的目的是指示之前的请求或响应服务原语调用完成。本国际标准材料不会使用使用这些服务原语，但指定数据链路实现的文件会用到这些定义，例如：执行服务参考点（例：通过response-confirm服务原语，ECUReset服务在客户端成功收到响应时执行重置）。

6.2 应用层服务格式描述

应用层服务根据车辆诊断系统配置方式存在两种格式，通过A_Mtype参数控制应用层服务格式。
若车辆系统的配置可允许客户端通过A_SA、A_TA地址参数寻址所有服务器，则使用应用层服务默认参数，这说明A_Mtype = diagnostics。
如果车辆系统配置使客户端需要自身地址信息和A_SA、A_TA地址参数才可对某些服务器寻址，这就要使用应用层服务远程格式，这说明 A_Mtype = remote disgnostics。
在 6.3 部分给出了应用层服务格式之间的区别。

6.3 服务原语格式描述

6.3.1 一般定义

所有应用层服务的一般格式都相同，服务原语用以下形式编写。

ervice_name.type (
                  parameter A, parameter B, parameter C
                  [,parameter 1, ...]
)

其中

• “service_name”使诊断服务的名字，例如：DiagnosticSessionControl（诊断会话控制），
• “type”表示服务原语的类型，例如：request，
• “parameter A,...”A_SDU（Application layer Service Data Unit）是服务原语（寻址信息）传递的值列表，
• “parameter A, parameter B, parameter C”是所有服务调用都包含的必要参数，
• “[,parameter 1, ...]”这些参数依赖于具体服务，例如：parameter 1是DiagnosticSessionControl（诊断会话控制）服务的diagnosticSession（诊断会话）。中括号表示这部分参数列表可能为空。

6.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诊断应用程序的服务器功能。
特定应用层服务的请求和指示原语通常具有相同的参数和参数值，这意味着数据从客户端传递到服务器过程中，应用层各通信协议实体端不应修改参数列表的参数值。在调用服务请求时，客户端应用程序功能传递到应用层的相同值列表，该值列表应被诊断应用的服务器功能通过应用层对端的服务指示接收。

6.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服务器功能成功执行，第一个服务数据单元应当采用积极响应和积极确认原语。
• 如果请求的诊断服务在ECU的服务器功能执行失败或不能按时完成时，否定响应和确认原语被用于第二个服务数据单元。

6.3.4 服务请确认和服务响应确认原语

对每个应用层服务，服务请求确认（request-confirm）和服务相应确认（response-confirm）原语依据下文一般格式指定。

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应用程序的服务器功能收到的通信结果集。

6.4 服务数据单元规范

6.4.1 必要参数

6.4.1.1 一般定义

应用层服务包含三个必要参数。下面的参数定义适用于所有该国际标准的应用层服务（标准和远程格式）。

6.4.1.2 A_Mtype，应用层消息类型（Application layer Message TYPE)

类型： 枚举

范围： 诊断，远程诊断

描述：
Mtype参数用于标识第 6.2 中规定的车辆诊断系统格式。这部分 ISO 14229 指定了该参数（范围包含两个值）：
如果 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。

6.4.1.3 A_SA，应用层源地址（Application layer Source Address）

类型： 2byte 无符号整型值

范围： 0x0000 - 0xFFFF

描述：
SA参数应当用于对客户端和服务器标识进行编码。

对于服务请求（和服务指示），A_SA代表了请求诊断服务的客户端功能的地址。每个请求诊断服务的客户端功能应当被一个A_SA值代表。如果同一台诊断仪实现了多个客户端功能，那么各客户端功能应用有自身的客户端标识和预旨对应的A_SA值。

对于服务响应（和服务确认），A_SA代表执行诊断服务请求的服务器的地址。一个服务器功能应被单一的或被若干个分布的ECU所实现。若一个服务器功能被单一ECU实现，则该服务器功能拥有一个A_SA地址。如果服务器功能被多个ECU功能分布式实现，则由一个A_SA值代表每个独立的服务器功能的地址。

如果远程客户端或服务器时消息的原始来源，那么A_SA代表从远程网络到本地网络网关的本地服务器。

注意 在通过物理寻址请求时，响应消息中的A_SA和相对应请求中的A_TA是相同的。

6.4.1.4 A_TA，应用层目标地址（Application layer Target Address)

类型： 2 byte无符号整型

范围： 0x0000 - 0xFFFF

描述：
A_TA用于对客户端和服务器端标识进行编码

两个不通过的寻址模式：

• 物理寻址和
• 功能寻址
  被指定用于诊断，因此车辆系统定义两组独立的目标地址（每种寻址方法一个）。

物理寻址一直是一个ECU服务器实现的专用通信方式，在使用物理寻址时，客户端和服务器使用端对端通信方式。

功能寻址用于客户端不知道应对请求做出相应的目标服务器功能的地址，或服务器功能作为分布式功能分布于多个ECU上时。在使用功能寻址时，客户端采用广播通信方式与一个或多个ECU的服务器实现之间进行通信。

低于服务请求（和服务指示），A_TA代表处理请求诊断服务的服务器标识。如果远程服务器已经寻址完成，则A_TA代表从主网到外网作为网关的本地服务器。

对于服务响应（和服务确认），A_TA代表原始请求诊断服务且将接收请求数据的客户端功能的地址（即：请求的A_SA）。服务响应（和服务确认）应使用物理寻址。如果远端客户端已经寻址完成，则A_TA代表从主网到外网作为网关的本地服务器。

注意 响应消息的A_TA和与之相对应的请求消息的A_SA是相同的。

6.4.1.5 A_TA_Type，应用层目标地址类型（Application layer Target Address Type）

类型： 枚举
范围： 物理的（physical），功能的（functional）
描述：
A_TA_type 是A_TA参数的一个扩展。它用于表示消息传输寻址方法的选项。

6.4.1.6 A_Result

类型： 枚举
范围： ok，error
描述：
‘A_Result’参数用于req_confirm和rsp_confirm原语来指示消息是否已经传输正确（ok）或消息传输是否失败（error）。

6.4.1.7 A_Length

类型： 4 byte无符号整型值
范围： $0_d-(2^{32}-1)_d$
描述：
该参数包含发送和接收的数据长度。

6.4.1.8 A_Data

类型： byte串
范围： 未指定
描述：
该参数包含高层及实体交互的全部数据。

6.4.2 车辆系统要求

车辆制造商应保证系统中各服务器均有服务器唯一标识符，车辆制造商同样应保证各客户端也有客户端唯一标志符。
车辆系统诊断网络中所有客户端和服务器地址应由同样取值范围的源地址编码。这就意味着一个客户端和一个服务器不应被同样的A_SA值所代表。
服务器物理目标地址应一直与服务器源地址相同。
远程服务器标识符可独立于主网中客户端与服务器标识符进行分配。
一般情况下只有已经被寻址的服务器才能响应客户端消息。

6.4.3 可选参数 - A_AE，应用层远程地址（Application layer remote address）

类型： 2 byte无符号整型值
范围： 0x0000 - 0xFFFF
描述：
A_AE用于扩展有效地址范围，用来编码客户端和服务器标识符。A_AE应仅仅用于实现了本地服务器和远程服务器概念的车辆。远程地址代表他自己的地址范围并独立于主网络地址。

A_AE参数应当被用于变啊远程客户端和服务器标识符。依据传输A_AE的消息传输方向，A_\AE能够代表一个远程目标地址或远程源地址。

对于在主网络中客户端发起的服务请求，A_AE代表远程服务器标识符（远程目标地址），该远程服务器应执行请求的诊断服务。

物理和功能地址都可使用A_AE，系统构建者应指明每个A_AE的值为物理地址还是功能地址。

注意 在A_TA_type指定A_TA寻址方法方式里没有代表物理或功能远程地址的特别参数，物理和功能远程地址共享1byte取值范围，并且每个值的含义应由系统构建者定义。

一个远程服务器可能由一个ECU实现，也可能由多个分布式ECU实现。如果一个远程服务器被一个ECU实现，则它应当用一个A_AE值进行编码。如果一个远程服务器被多个分布式ECU实现，则远程地址标识符应由一个A_AE值对每个远程服务器进行编码。

7 应用层协议（Application layer protocol）

7.1 一般定义

应用层协议应作为一个已确认的消息传输，每个客户端发送的服务请求，应收到从服务器发送的一个或多个响应。

与此规则相悖的少数情况是使用功能寻址或请求/指示规范中不会生成响应。为避免非必要消息给系统带来负载，少数情况下即使服务器处理请求的诊断服务失败，也不会发送否定响应。上述异常情况会在该规范中给予描述（如 参考7.5）。

一个用层协议应当与会话层协议并行处理，这说明即使客户端等待上一个请求的响应，他也当保持会话层时间（例如：发送通知其他服务器保持诊断会话的TesterPresent请求。其实现依赖于采用的数据链路层）。（译者注：会话层的“会话<session>”是指在一段时间内保持的事件；）

7.2 协议数据单元规范

A_PDU（Protocol data unit specification）由A_SDU（Application layer Service Data Unit）和层规范控制信息A_PCI（Application layer Protocol Control Information）所构造。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”是为每个独立的应用层服务定义的byte串。A_Data串应由A_PCI开头，然后是A_SDU中为每个服务指定的所有服务规范参数。括号说明其中参数列表可能为空；
• “Length”取决于A_Data中字节数；

7.3 应用协议控制信息

7.3.1 PCI，（Protocol Control Information）协议控制信息

A_PCI包含两种格式，它们通过A_PCI参数的第一字节进行标识。首字节不等于0x7F的服务请求和服务响应适用以下定义：

A_PCI (
      SI
)

其中：

• “SI”是服务标识符参数（Service identifier）；
  对首字节等于0x7F的服务响应，适用以下定义：

  A_PCI (
      NR_SI,
      SI
  )
  

  其中：

• “NR_SI”是标识否定服务响应、否定服务确认的规范参数；

• “SI”是服务标识符参数（Service identifier）

注意： 传输在ReadDataByPeriodicIdentifier中定义的周期性数据响应消息（0x2A，参考10.5）的应用层协议数据单元（A_PDU）中不包含A_PCI。

7.3.2 SI，服务标识符（Service Identifier)

类型： 1字节无符号整型值
范围： 0x00 - 0xFF，参考表2中的定义
表 2 - 服务标识符取值范

服务标识符（SI）	服务类型（bit 6）	定义于
0x10 – 0x3E	ISO 14229-1 服务请求	ISO 14229-1
0x3F	不适用	文件预留
0x50 – 0x7E	ISO 14229-1 积极服务响应	ISO 14229-1
0x7F	否定服务响应标识符	ISO 14229-1
0x80 – 0x82	不适用	ISO 14229-1 预留
0x83 – 0x88	ISO 14229-1 服务请求	ISO 14229-1
0x89 – 0xB9	不适用	ISO 14229-1 预留
0xBA – 0xBE	服务请求	由系统供应商定义
0xBF – 0xC2	不适用	ISO 14229-1 预留
0xC3 – 0xC8	ISO 14229-1 积极服务响应	ISO 14229-1
0xC9 – 0xF9	不适用	ISO 14229-1 预留
0xFA – 0xFE	积极服务响应	系统供应商定义
0xFF	不适用	文件预留

注意： 上表为请求消息服务标识符和响应消息服务标识符的1对1交互，SI Byte的第6bit 指示了服务类型。所有请求消息带有SI bit 6 = 0。所有积极响应_（译者注：有时业内也称为正响应，即服务器处理无异常所发出的响应）_的SI bit 6 = 1。ReadDataByPeriodicIdentifier（0x2A参考10.5）的周期性数据相应消息不在此列。

描述：

服务原语调用指定服务适用SI进行编码。每种服务请求应分配唯一的SI值。每种服务响应也应当分配对应的唯一SI标识。

服务标识用于代表从应用层向低层级传递（且从低层级返回）的A_Data数据串。

7.3.3 NR_SI，否定响应服务标识（Negative response service identifier）

类型： 1 byte无符号整型
填充值： 0x7F
描述：
NR_SI是标识否定服务响应、否定服务确认的特殊参数。它作为否定响应、否定确认的A_PCI中的一部分。

注意： NR_SI值于SI值相互协作。为便于解码A_Data，NR_SI的值不可用做SI值

7.4 否定响应、否定确认服务原语

各诊断服务具有依照 表3 所规定的否定响应、否定确认消息。

表 3 - 否定响应 A_PDU

A_PDU 参数	参数名	约定	Byte 值	助记符
SA	源地址	M	0xXXXX	SA
TA	目标地址	M	0xXXXX	TA
TAtype	目标地址类型	M	0xXX	TAT
RA	远程地址（可选）	C	0xXXXX	RA
A_Data.A_PCI.NR_SI	否定响应SID	M	0x7F	SIDNR
A_Data.A_PCI.SI	<服务名>请求SID	M	0xXX	SIDRQ
A_Data.Parameter 1	responseCode（响应码）	M	0xXX	NRC_

M（Mandatory）强制：如果发出否定响应就应当出现这些参数

C（Conditional）条件：RA（Remote Address）PDU参数仅在远程寻址情况下存在

注意： A_Data表示否定响应消息数据字节序列

responseCode（响应码）参数用于否定响应消息中，指示诊断服务失败或未能及时完成的原因。其值定义在A.1中。

7.5 服务器响应实现规范

7.5.1 一般定义

下列条款注明服务器执行服务时的行为，服务器和客户端均应遵循该实现规范。

说明：

缩写	描述
suppressPosRspMsgIndicationBit （译注：禁止肯定响应消息指示位）	TRUE = 服务器不应发送肯定响应消息（异常参考附录A.1的NRC 0x78定义） FALSE = 服务器应当发送肯定或否定响应消息
PosRsp	肯定响应消息缩写
NegRsp	否定响应消息缩写
NoRsp	不发送肯定或否定响应消息缩写
NRC	否定响应码缩写
ALL	服务器支持所有客户端请求消息的请求数据参数
At least 1	服务器必须支持至少一个客户都请求消息的数据参数
None	服务器不支持客户端请求的任何数据参数

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

重要提示 - 依据表中要求的下列条款中：带否定响应码SNS（serviceNotSupported）、SNSIAS（serviceNotSupportedInActiveSession）、SFNS（sub-functionNotSupported）、SFNSIAS（sub-functionNotSupportedInActiveSession）和ROOR（requestOutOfRange）的否定响应消息不应在请求消息使用功能寻址时传输。（异常参考附录 A.1 NRC 0x78 的定义）

7.5.2 常规服务器响应行为

本条款中指定的常规服务器行为对于所有请求消息都是强制性的，验证步骤始于收到请求消息，该图划分为三个子条款。

• 强制：需要通过每个请求消息的评估，
• 可选：可对每个请求消息进行可选性评估，
• 制造商、供应商指定：该步骤可通过制造商、供应商指定的检查方式来扩展。

注意： 依赖于选择的所有规定NRC处理图的实现，对于所有可能的测试模式序列，指定的NRC并非必然

图 5 一般服务器响应行为描述

键：

1. 不能接收诊断请求，因为其他诊断仪请求的诊断任务正在执行。
2. 参考各服务的响应行为（支持否定响应码）。
   图 5 - 服务器一般响应行为

7.5.3 具有子功能参数的请求消息和服务器响应行为

7.5.3.1 具有子功能参数的请求消息的服务器常规响应行为

本节强制指定了所有带子函数参数请求的一般响应，本节上下文中所述的请求消息遵循ISO 14229 请求服务请求消息格式要求。

图6 描述了带子功能参数的请求消息的一般服务响应动作

钥节：
1 长度至少为 2（SID + SubFunction Parameter）。
2 顺序检查方面的子功能，如LinkControl 或 SecurityAccess。
3 参考各服务的相应行为（支持否定响应码）。
图 6 对于带子功能参数请求消息的一般服务器相应行为

7.5.3.2 物理寻址客户端请求消息

每个服务描述都引用本节所述服务器相应行为规范，服务器支持客户端物理寻址带子功能参数的请求。
表 4 展示了可行的物理寻址通信方案

表 4 带子功能参数的物理寻址请求消息和服务器响应行为

服务器用例#	客户端请求消息		服务器能力			服务器响应		服务器响应备注
	寻址方案	子功能 （suppress-PosRspMsg-Indication-Bit）	支持SI	支持子功能	支持数据参数 （仅限适用）	消息	NRC
a)	功能寻址	FALSE （bit=0）	YES	YES	至少1	PosRsp	--	服务发送肯定响应
b)					至少1	NegRsp	NRC=0xXX	由于从请求消息中读取数据参数错误，服务发送否定响应
c)					无		NRC=ROOR	带NRC 0x31的否定响应
d)			NO	--	--		NRC=SNS or SNSIAS	带 NRC 0x11 或 NRC 0x7F的否定响应
e)			YES	NO	--		NRC=SFNS or SFNSIAS	带 NRC 0x12 或 NRC 0x 7E 的否定响应
f)		TRUE （bit=1）	YES	YES	至少1	NoRsp	--	服务器不发送响应
g)					至少1	NegRsp	NRC=0xXX	由于从请求消息中读取数据参数错误，服务器发送否定响应
h)					无		NRC=ROOR	带NRC=0x31的否定响应
i)			NO	--	--		NRC=SNS	带NRC=0x11的否定相应
j)			YES	NO	--		NRC=SFNS	带NRC=0x12的否定响应

描述功能寻址带子功能参数的客户端消息请求情况下的服务器响应。

1. 由于响应消息表示支持服务标识和子功能参数，服务器发送肯定响应消息。
2. 虽然支持客户端服务标识和子功能参数，但在处理子功能时存在某些错误（例如 对照请求消息的服务标志和子功能参数，PDU的长度错误），所以服务器发送否定响应消息（例如 IMLOIF：incorrectMessaeLengthOrIncorrectFormat）。
3. 由于请求消息在功能寻址下经常存在禁止否定响应码ROOR（requestOutOfRange，虽然服务标志和子功能参数是被支持的，可是客户端请求了一个必要但不被支持的数据参数）的情况，所以服务器未响应消息。
4. 在服务标识不支持客户端请求时，服务器会否定响应SNS（serviceNotSupported）和SNSIAS（serviceNotSupportedInActiveSession），但客户端功能寻址模式下请求时SNS和SNSIAS被禁用，所以服务器无响应消息。在这种情况下suppressPosRspMsgIndicationBit无效。
5. 服务器支持客户端请求的服务标识，但不支持该请求适用的子功能参数时，服务器发送否定响应SFNS（sub-functionNotSupported）和SFNSIAS（sub-functionNotSupportedInActiveSession）。在功能寻址请求时SFNS和SFNSIAS被禁用，所以所以服务器无响应消息。这种情况下suppressPosRspMsgIndicationBit无效。
6. 由于客户都请求指示了无响应消息，服务标志和子功能参数支持客户端的请求，所以服务器无响应消息。

   注意    如果服务器使用否定响应码 RCRRP（requestCorrectlyReceivedResponsePending），则最终响应会与 supressPosRspMsgIndicationBit 值无关。

7. 在任何否定响应都会忽略 supprssPosRspMsgIndicationBit，所以该效果与 b) 相同（即发送一个否定响应消息），功能寻址消息请求时也是如此。
8. 由于在功能寻址消息请求情况下，否定响应码 ROOR（requestOutOfRange，是服务器指定虽然服务标识符和子功能参数，但不支持客户端请求的必要的数据参数）被禁用，所以情况与 c) 相同（即不发送响应消息）。
9. 由于（表示服务器不支持客户端请求的服务标识符的）否定响应码 SNS（serviceNotSupported）和 SNSIAS（serviceNotSupportedInActiveSession）在功能寻址消息请求时被禁用，所以效果与 d) 相同（即不发送响应消息）。这种情况下 suppressPosRspMsgIndicationBit 无关紧要。
10. 由于（服务器表示支持客户端请求的服务标识符但不支持子功能参数的）消极响应码 SFNS（sub-functionNotSupported）和 SFNSIAS（sub-functionNotSupportedInActiveSession）在功能寻址消息请求情况下被禁用，所以情况与 e) 相同。suppressPosRspMsgIndicationBit在此情况下无关紧要

7.5.4 无子功能参数的消息请求和服务器响应行为

7.5.4.1 对于无子功能参数消息请求，服务器的一般响应行为

对于请求不带子功能参数的消息请求无有效的一般相应行为，请求消息在本章节上下文中作为服务请求消息，该服务请求消息遵循本部分 ISO 14229 定义的必要格式。

7.5.4.2 物理寻址客户端请求消息

在本章节定义的每个服务的服务器相应行，不支在物理寻址下持带子功能参数的客户端请求，但支持数据参数。

表 6 展示了可行的物理寻址通信方案

表 6 - 物理寻址下无子功能参数的消息请求和服务器相应行为

服务器用例#	客户端 请求消息	服务器能力		服务器响应		服务器响应备注
	寻址 方案	SI 支持	参数 支持	消息	NRC
a)	物理的	YES	ALL	PosRsp	--	服务器发送肯定响应
b)			至少1个		--	服务器发送肯定响应
c)			至少1个	NegRsp	NRC=0xXX	从请求消息中读取数据参数发生错误，服务器发送否定响应
d)			NONE		NRC=ROOR	带 NRC 0x31 的否定响应
e)		NO	--		NRC=SNS或SNSIAS	带 NRC 0x11 或 NRC 0x7F 的否定响应

物理寻址客户端请求无子功能参数的消息时服务器响应用例描述：

1. 服务器支持客户端请求的服务标识符和全部数据参数，并发送肯定响应。
2. 服务器支持客户端请求的服务标识符和至少一个数据参数，并发送肯定响应。
3. 服务器支持客户端请求的服务标识符和至少一个数据参数，单处理服务过程中存在其他错误（例如 错误的请求消息长度），服务器发送否定响应（例如 IMLOIF：incorrectMessageLengthOrIncorrectFormat，译注：消息长度错误或格式错误）。
4. 服务器支持客户端请求的服务标识符但请求的数据参数均不被支持，服务器发送带否定响应码ROOR（requestOutOfRange，译注：请求越界）的否定响应消息。
5. 服务器不支持客户端请求的服务标识符，服务器发送带否定响应码 SNS（serviceNotSupported，译注：不支持的服务）的否定响应消息。

7.5.4.3 功能寻址客户端请求消息

本章节的服务响应行为，被功能寻址下支持客户端请求消息的数据参数，但不支持子功能参数的各服务描述所引用。
表 7 展示了功能寻址下可行的通信方案

表 7 -- 功能寻址无子功能参数的请求消息和服务器响应行为

服务器用例#	客户端 请求消息	服务器能力		服务器响应		服务器响应备注
	寻址 方案	SI 支持	参数 支持	消息	NRC
a)	功能	YES	ALL	PosRsp	--	服务器发送肯定响应
b)			至少1个		--	服务器发送肯定响应
c)			至少1个	NegRsp	NRC=0xXX	从请求消息中读取数据参数发生错误，服务器发送否定响应
d)			NONE	NoRsp	--	服务器不发送响应
e)		NO	--		--	服务器不发送响应

功能寻址不带子功能的请求消息（数据参数跟随服务标识符）服务响应用例描述：

1. 服务器支持客户端请求消息的服务标识符和全部数据参数，服务器发送肯定响应消息。
2. 服务器支持客户端请求消息的服务标识符和至少一个数据参数，服务器发送肯定想应消息。
3. 服务器发送否定响应消息（例如 IMLOIF：incorrectMessagerLengthOrIncorrectFormat）是由于虽然服务器支持客户端请求消息的服务标识符和至少一个抑或多个乃至所有数据参数，但执行服务过程中发生其他错误（例如错误的请求消息长度）。
4. 服务器无响应消息，是由于否定响应码 ROOR（requestOutOrRange；出现该否定响应码是因为虽然支持客户端请求的服务标识符，但所有数据参数都不被支持）一般在功能寻址请求时被禁用。
5. 服务器无响应消息，由于否定响应码 SNS（serviceNotSupported）和 SNSIAS（serviceNotSupportedInActionSession）在客户端请求的服务标识符不被支持时发生，但客户端在功能寻址请求时上述否定响应码被禁用。

7.5.5 服务器响应行为伪代码

服务器伪代码示例描述了服务器在收到客户端请求时执行的逻辑步骤。

SWITCH (A_PDU.A_Data.A_PCI.SI)
  {
  CASE Service_with_sub-function:                     /* test if service with sub-function is supported */
    IF (message_length >= 2) THEN                     /* check minimum length of message with sub-function */
      SWITCH (A_PDU.A_Data.A_Data.Parameter1 & 0x7F)
                                                      /* get sub-function parameter value without bit 7 */
        {
        CASE sub-function_00:                         /* test if sub-function parameter value is supported */
          IF (message_length == expected_sub-function_message_length) THEN
            :                                         /* prepare response message */
            responseCode = positiveResponse;          /* positive response message; set internal NRC = 0x00 */
          ELSE
            responseCode = IMLOIF;                    /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
          ENDIF
          BREAK;
        CASE sub-function_01:                         /* test if sub-function parameter value is supported */
          :                                           /* prepare response message */
          responseCode = positiveResponse;            /* positive response message; set internal NRC = 0x00 */
          :
        CASE sub-function_127:                        /* test if sub-function parameter value is supported */
          :                                           /* prepare response message */
          responseCode = positiveResponse;            /* positive response message; set internal NRC = 0x00 */
          BREAK;
        DEFAULT:
          responseCode = SFNS;                        /* NRC 0x12: sub-functionNotSupported */
        }
    ELSE
      responseCode = IMLOIF;                          /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
    ENDIF
    suppressPosRspMsgIndicationBit = (A_PDU.A_Data.Parameter1 & 0x80);
                                                      /* results in either 0x00 or 0x80 */
    IF ( (suppressPosRspMsgIndicationBit) && (responseCode == positiveResponse) &&
      ("not yet a NRC 0x78 response sent")) THEN      /* test if positive response is required and if responseCode is positive 0x00 */
      suppressResponse = TRUE;                        /* flag to NOT send a positive response message */
    ELSE
      suppressResponse = FALSE;                       /* flag to send the response message */
    ENDIF
    BREAK;
  CASE Service_without_sub-function:                  /* test if service without sub-function is supported */
    suppressResponse = FALSE;                         /* flag to send the response message */
    IF (message_length == expected_message_length) THEN
      IF (A_PDU.A_Data.Parameter1 == supported) THEN
                                                      /* test if data-parameter following the SID is supported*/
        :                                             /* read data and prepare response message */
        responseCode = positiveResponse;              /* positive response message; set internal NRC = 0x00 */
      ELSE
        responseCode = ROOR;                          /* NRC 0x31: requestOutOfRange */
      ENDIF
    ELSE
      responseCode = IMLOIF;                          /* NRC 0x13: incorrectMessageLengthOrInvalidFormat */
    ENDIF
    BREAK;
  DEFAULT:
    responseCode = SNS;                               /* NRC 0x11: serviceNotSupported */
  }
IF (A_PDU.TA_type == functional && ((responseCode == SNS) ¦¦ (responseCode == SFNS) ¦¦ (responseCode == SNSIAS) ¦¦
(responseCode == SFNSIAS) ¦¦ (responseCode == ROOR)) &&
("not yet a NRC 0x78 response sent")) THEN
                                                      /* suppress negative response message */
ELSE
  IF (suppressResponse == TRUE) THEN                  /* suppress positive response message */
  ELSE                                                /* send negative or positive response */
  ENDIF
ENDIF

当请求消息使用功能寻址，并且否定响应消息带有NRC=RCRRP（requestCorrectlyReceivedResponsePending），则最终否定响应消息使用NRC=SNS（serviceNotSupported）、NRC=SNSIAS（serviceNotSupportedInActiveSession）、NRC=SFNS（sub-functionNotSupported）、NRC=SFNSIAS（sub-functionNotSupportedInActiveSession）或NRC=ROOR（requestOutOfRange），如果请求消息的PDU分析结果如上，则应发送上述否定响应码

7.5.6 物理和功能寻址的多重并发请求消息

通用服务器实现只有一个生效的诊断协议实例，一个诊断协议实力只能同时处理一个请求，其原则是接收的任何消息（不论功能还是物理寻址）占有其资源直至请求消息处理完成（发送最终响应或无最终响应）。

只有两种需要分别处理的异常：

• 客户端使用保持在线（keep-alive）逻辑来维持一个或多个服务器之前启动的活动会话。Keep-Alive-Logic（译注 保持在线逻辑）作为功能寻址定义有效的TesterPresent消息，该带有SPRMIB=true的 TesterPresent 消息必须通过旁路逻辑进行处理。服务器必须胜任并确保这个特殊消息不会被服务器应用层阻止并处理跟着它的已寻址的消息。
• 如果服务器支持单个或多个法定诊断请求，其中一个请求发生在非法定服务活动期间内（例如增强诊断），那么该活动服务应终止执行，服务器将启动默认会话和该法定诊断服务。本条规范在编程会话活动期间不生效。

(第8章)[https://www.cnblogs.com/sam-snow-v/articles/15905380.html]