UDS诊断入门（三）

林海myzone 2021-02-28

展开全文

引言

在前面的文章中我们已经介绍了UDS诊断中的诊断和通信管理功能单元的10个服务和数据传输功能单元的7个服务，他们的服务名称和SID如下所示：

本文将继续介绍UDS诊断协议的存储数据传输功能单元和输入输出控制单元以及例行程序功能单元的4个服务，他们分别是

关于上传及下载功能单元的相关服务，我们将在UDS诊断入门（四）中进行介绍。欢迎继续关注。

存储数据传输功能单元

存储数据传输功能单元包含清除诊断信息（0x14）&读取故障码信息（0x19）两个服务，此服务是用来报告服务器故障信息以及清除故障信息所使用的服务，具体介绍请继续向下阅读；

2.1 清除诊断信息（0x14）

2.1.1 服务介绍

清除诊断信息功能是用于客户端向服务器清除一个或多个故障诊断信息的服务；

当清除诊断信息服务完成后，服务器应发出肯定响应。即使没有存储DTC，服务器也应该发送一个肯定的响应。如果服务器支持内存中的DTC状态信息的多个备份(例如RAM中的一个和EEPROM中的一个备份)，服务器应清除读DTC信息状态报告服务所使用的备份。额外的备份，例如长期记忆中的备份，根据适当的备份策略进行更新(例如在电源锁存阶段)。

客户端的请求信息中应包含一个或者多个具体的故障参数，还可以选择清除全部的故障信息，当客户端请求的是一个或者多个具体的故障信息时，服务器应当读取其具体的内存中存储的故障信息（例如故障码，故障状态，故障快照等），并清除。

当存在故障的备份时，故障备份的存储的相关信息可以不受此服务的影响。

2.1.2 请求数据定义

Note：

当请求数据中group of DTC的三个字节的内容全部是FF时，代表清除全部故障信息

2.1.3 肯定响应数据定义

2.2 读取故障码信息（0x19）

2.2.1 服务介绍

2.2.1.1 通用介绍

该服务允许客户端从任何服务器或车内的一组服务器读取驻留在服务器上的诊断故障代码(DTC)信息的状态。除非特殊的子功能另有要求，服务器应返回所有的DTC信息(例如，与排放相关的和非排放相关的)。此服务有如下功能:

-检索匹配客户端定义的DTC状态掩码的DTC数目

-检索符合客户端定义的DTC状态掩码的特定功能组中的DTC列表

-检索与客户端定义的DTC状态掩码相匹配的特定功能组中的DTC列表

-检索所有已经成熟的DTC状态

-检索与客户端定义的DTC关联的DTC快照数据(有时称为冻结帧):DTC快照是与DTC关联的特定数据记录，存储在服务器的内存中。DTC快照的典型用途是在检测到系统故障时存储数据。DTC快照将作为从系统故障发生时起的数据值的快照。存储在DTC快照中的数据参数应该与DTC相关联。DTC特定的数据参数旨在简化技术人员的故障隔离过程

-从DTC内存或DTC镜像内存中检索与客户端定义的DTC和状态掩码组合相关联的DTC扩展数据。DTC扩展数据由与DTC相关联的扩展状态信息组成。DTC扩展数据包含DTC参数值，这些值在请求时已被识别。DTC拓展数据的典型用法是存储与DTC相关联的动态数据

例如：

DTC B1故障指示计数器，显示故障发生时OBD系统运行的时间(发动机运行的小时数)

DTC发生计数器，计算报告“已测试失败”的驾驶周期数

OBD的具体计数器(例如，如果可以在无故障模式下进行驾驶循环，则在“检查引擎”灯关闭前剩余的驾驶循环数)

上次测试失败的时间

测试失败计数器，计算报告的“测试失败”和可能的其他计数器的数目(如果在几个步骤中执行验证)

未完成测试计数器，统计自最近一次完成测试以来的驾驶周期数

-检索与客户端定义的严重性掩码匹配的DTC数量

-检索与客户端定义的严重性掩码记录匹配的DTC列表

-检索客户端定义的DTC的严重性信息

-检索服务器支持的所有DTC的状态

-检索服务器失败的第一个DTC

-检索服务器中最近失败的DTC

-检索服务器确认的第一个DTC

-检索服务器中最近确认的DTC

-从DTC镜像内存中检索匹配客户端定义的DTC状态掩码的DTC列表

-检索镜像存储器直接转发器扩展数据记录数据为客户端定义的直接转发器掩码和客户端定义的直接转发器扩展数据记录号码从直接转发器镜像存储器

-从DTC镜像内存中检索与客户端定义的DTC状态掩码匹配的DTC数目

-检索与客户端定义的DTC状态掩码匹配的仅排放相关的OBD DTC的数量。如果检测到与排放相关的OBD DTC，则会导致故障指示灯打开/显示消息

-检索匹配客户端定义的DTC状态掩码的与排放相关的OBD DTC的状态。如果检测到与排放相关的OBD DTC，则会导致故障指示灯打开/显示消息

-检索所有当前“预失败”的DTC，这些DTC已经或尚未检测到“挂起”或“已确认”

-从DTC内存中检索与客户端定义的DTC扩展数据记录状态相关联的DTC扩展数据

-从用户定义的DTC内存中检索匹配客户端定义的DTC状态掩码的DTC列表

-检索用户自定义的DTC存储器DTC扩展数据记录数据为客户端自定义的DTC掩码掩码和客户端自定义的DTC扩展数据记录号从用户自定义的DTC镜像存储器中取出

-从用户定义的DTC内存中检索客户端定义的DTC掩码的用户定义的DTC内存的DTC快照记录数据

该服务使用sub-function来确定客户机请求的诊断信息类型。关于每个sub-function参数的进一步细节将在下面的内容中介绍。

此服务的使用需要遵循以下原则：

启用标准:

服务器/汽车制造商/系统供应商用于控制服务器实际执行特定内部诊断的特定标准

测试通过标准:

服务器/车辆制造商/系统供应商的特定条件，定义被诊断的系统是否在正常、可接受的操作范围内正常运行(例如，没有故障，诊断的系统被归为“OK”)

测试失败标准:

服务器/汽车制造商/系统供应商特定的失败条件，定义被诊断的系统是否失败了测试。

确认的故障标准:

服务器/汽车制造商/系统供应商特定的故障条件，定义被诊断的系统是否确实有问题(确认)，保证在长期存储器中存储DTC记录

发生计数器:

由某些服务器维护的计数器，记录给定DTC测试报告唯一测试失败发生的实例数量

老化:

某些服务器评估每个内部诊断的过去结果，以确定一个确认的DTC是否可以从长期记忆中清除的过程，例如，在一个校准的故障自由周期的事件中。

在ISO14229，19服务的子功能定义的已经有27个，但是在实际工作中，我们所使用的服务并不需要这么复杂，本文仅介绍在实际工作中所经常使用的一些进行服务的详细介绍，其余如读者感兴趣可以自行查阅ISO14229-1中的19服务介绍。

2.2.1.2 通过状态掩码报告故障码数量（0x01）

客户端可以检索与客户端定义的状态掩码相匹配的DTC数量，方法是发送此服务请求，并将sun-function设置为通过状态掩码报告故障码数量。对此请求的响应包含DTC状态可用性掩码，它提供了服务器为屏蔽目的所支持的DTC状态位的指示。在DTC状态可用性掩码之后，响应包含DTC格式标识符，它报告有关DTC格式和编码的信息。DTC格式标识符后面跟着DTC数量参数，它是一个2字节的无符号数字，包含基于客户机提供的状态掩码的服务器内存中可用的DTC数量。

镜像内存按状态掩码直接转接的子功能报告数目与按状态掩码直接转接的子功能报告数目相同，不同的是它返回从直接转接镜像内存中取出的直接转接的数目。

2.2.1.3 通过状态掩码报告故障（0x02）

客户端可以检索DTC列表，通过发送带有sun-function字节集的请求来根据状态掩码报告DTC，从而满足客户端定义的状态掩码。此子功能允许客户机请求服务器报告所有“测试失败”或“确认”或“等等”的DTC。

通过此功能，客户端可以请求服务器报告存储中的某一状态的全部故障，例如当前故障，历史故障，正在测试的故障，测试完成的故障等。

2.2.1.4 报告故障码快照标识（0x03）

客户端可以为所有捕获的DTC快照记录检索DTC快照记录识别信息，通过发送此服务请求，并设置报告DTC快照识别的子功能。服务器应返回所有存储的DTC快照记录的DTC快照记录识别信息列表。服务器放置在单个DTC快照记录响应消息中的每一项都应包含一个DTC记录(包含DTC编号(高、中、低字节))和DTC快照记录编号。如果一个DTC存储了多个DTC快照记录，那么服务器应该为每个事件在响应中放置一个条目，为每个事件使用不同的DTC快照记录号(用于以后对记录数据的检索)。

DTC快照记录识别信息应在客户端成功发出清除诊断信息请求后被清除。汽车制造商有责任指定删除存储的DTC和DTC快照数据的规则，以防内存溢出(存储的DTC和DTC快照数据的内存空间在服务器中完全被占用)。

2.2.1.5 通过故障码报告故障快照（0x04）

客户端可以为客户端定义的DTC掩码记录和DTC快照记录号检索捕获的DTC快照记录数据，通过发送此服务请求，并设置子功能以按DTC号码报告DTC快照记录。服务器应在其支持的DTC中搜索与客户端指定的DTC掩码记录(包含DTC编号(高、中、低字节))的精确匹配。客户请求中提供的DTC快照记录号参数应指定要求的DTC快照记录数据的特定发生情况

如果服务器支持为单个DTC存储多个DTC快照记录的能力(该功能由系统供应商/车辆制造商定义)，则建议服务器也实现报告DTC快照识别子功能参数。建议客户端首先通过子功能参数“报告DTC快照识别”请求对存储的DTC快照记录进行识别，然后通过“报告DTC快照记录”请求指定的DTC快照记录号

也建议支持子功能参数报告DTC快照记录识别，以便让客户端有机会直接识别存储的DTC快照记录，而不是通过解析服务器所有存储的DTC来确定是否存储了DTC快照记录。

系统供应商/车辆制造商应负责定义在此类服务器上捕获的DTC快照记录是否存储与故障发生信息相关的数据，作为ECU文档的一部分。

2.2.1.6 通过记录编号报告DTC存储数据（0x05）

客户端可以为一个DTC存储数据记录号检索捕获的DTC存储数据记录数据，通过发送此服务请求，并设置子功能以按记录号报告DTC存储数据。服务器应从其存储的DTC存储数据记录中查找与客户端提供的记录号是否匹配。

系统供应商/车辆制造商应负责定义DTC存储数据记录是否存储与第一次或最近一次故障发生相关的数据。

2.2.1.7 通过DTC报告DTC拓展数据（0x06）

客户端可以检索客户端定义的DTC掩码记录和DTC扩展数据记录号的DTC扩展数据记录，通过发送此服务请求，并设置sub-function为通过DTC报告DTC拓展数据。服务器应在其支持的DTC中搜索与客户端指定的DTC掩码记录(包含DTC编号(高、中、低字节))的精确匹配。在这种情况下，客户请求中提供的DTC ExtData记录号参数应指定指定的DTC扩展数据记录，其中DTC扩展数据被请求。

如果是单独的DTC，服务器仅需要报告要求的DTC的拓展数据，如果是0xFE或0xFF则报告全部的数据。

2.2.1.8 报告支持的全部DTC（0x0A）

客户机可以检索服务器支持的所有DTC的状态，方法是发送对该服务的请求，并设置sub-function为报告支持的全部DTC。对此请求的响应包含DTC状态可用性掩码，它提供了服务器为屏蔽目的所支持的DTC状态位的指示。在DTC状态可用性掩码之后，响应还包含DTC列表和状态记录，其中包含服务器支持的每个诊断故障代码的DTC编号和关联状态

2.2.2 请求数据定义

2.2.2.1通过状态掩码报告故障码数量（0x01）请求&通过状态掩码报告故障（0x02）请求

2.2.2.2报告故障码快照标识（0x03）请求&通过故障码报告故障快照（0x04）请求

2.2.2.3通过记录编号报告DTC存储数据（0x05）请求

2.2.2.4通过DTC报告DTC拓展数据（0x06）请求

2.2.2.5报告支持的全部DTC（0x0A）请求

其中19服务的sub-function在ISO14229-1中有如下定义：

Bits 6 – 0	Description
0x00	ISOSAE保留
0x01	通过状态掩码报告故障码数量
0x02	通过状态掩码报告故障
0x03	报告故障码快照标识
0x04	通过故障码报告故障快照
0x05	通过记录编号报告DTC存储数据
0x06	通过DTC报告DTC拓展数据
0x07	通过严重掩码记录上报DTC次数
0x08	通过DTC严重等级报告故障码
0x09	报告DTC的严重等级
0x0A	报告支持的全部DTC
0x0B	报告第一次测试失败的故障
0x0C	报告第一个确认的故障
0x0D	报告最近测试失败的故障
0x0E	报告最近确认的故障
0x0F	根据状态掩码报告镜像内存DTC
0x10	根据DTC报告镜像内存的拓展数据
0x11	通过状态码报告镜像内存的故障数
0x12	通过状态码报告排放相关的故障数
0x13	通过状态码报告排放相关的DTC
0x14	报告DTC的故障检测次数
0x15	报告DTC的永久状态
0x16	通过记录编号报告DTC拓展数据
0x17	通过状态码报告客户自定义的故障内存
0x18	通过DTC码报告客户自定义故障的快照信息
0x19	通过DTC码报告客户自定义故障的拓展数据
0x1A-0x41	ISOSAE保留
0x42	通过掩码记录报告WWH的OBD故障码
0x43-0x54	ISOSAE保留
0x55	通过故障的永久状态报告WWH的OBD故障码

鉴于在2.2.1章节中我们已经对19服务常用的sub-function做出了服务介绍，因此本表仅介绍ISO4229-1对于19服务的其余sub-function做出简介，具体定义和请求数据，本文不再赘述，感兴趣的读者可以自行查阅相关介绍。

2.2.3 肯定响应数据定义

2.2.3.1通过状态掩码报告故障码数量（0x01）响应

2.2.3.2通过状态掩码报告故障（0x02）响应

2.2.3.3报告故障码快照标识（0x03）响应

2.2.3.4通过故障码报告故障快照（0x04）响应

2.2.3.5通过记录编号报告DTC存储数据（0x05）响应

2.2.3.6通过DTC报告DTC拓展数据（0x06）响应

2.2.3.7报告支持的全部DTC（0x0A）响应

输入输出控制功能单元

3.1 通过标识符控制输入输出（0x2F）

3.1.1 服务介绍

客户端使用标识符输入输出控制服务来代替输入信号的值、内部服务器功能和/或强制控制为电子系统的输出(执行器)的值。一般来说，这个服务用于相对简单的(例如静态的)输入替换/输出控制，而如果需要更复杂的输入替换/输出控制，则使用例行程序控制服务。

客户端请求消息包含一个数据标识符，以引用服务器的输入信号、内部服务器功能和/或输出信号(执行器)(在设备控制访问的情况下，它可能引用一组信号)。控制选项记录参数应包括服务器的输入信号、内部功能和/或输出信号所需的所有信息。如果要控制的数据标识符引用了多个参数，那么车辆制造商可能要求请求消息包含控制启用掩码。如果车辆制造商选择支持启用掩码的概念，那么控制启用掩码参数在该服务的标识符请求的所有类型的输入输出控制上都是强制性的。如果输入输出控制的请求标识符的数据标识符引用一个测量输出值或反馈值,服务器负责替换正确的目标价值在服务器控制策略,以便正常服务器控制策略将试图从客户端请求消息达到理想的状态。

如果请求控件成功启动或达到预期状态，服务器应该发送一个积极响应消息。即使数据标识符目前不在测试器的控制范围内，服务器也应向请求消息发送积极响应消息，并带有返回控制ECU的输入输出控制参数。此外，当接收到对ECU的返回控制请求时，服务器应始终向客户端提供将控制掩码(如果支持的话)位全部设置为“1”的能力，以便将打包或位图数据标识符完全返回给ECU。请求消息的控制选项记录参数内的输入输出控制参数后面的控制状态字节的格式和长度应与被请求的数据标识符的数据记录的长度和格式完全匹配。这样就可以确保通过使用与DID相同的标识符读取服务读取数据来获取实际的输出或输入状态。

3.1.2 请求数据定义

3.1.3 肯定响应数据定义

例行程序功能单元

这个功能单元指定远程激活例程的服务，它们应该在服务器和客户端实现。下面的内容描述了两种不同的实现方法(方法“A”和“B”)。也许还有其他可能的实现方法。方法“A”和“B”应使用作为实现例程服务的指南。

每个方法都可能具有在例程停止后请求例程结果服务的功能。方法的选择和实施是由汽车制造商和系统供应商决定。

方法A：

-假设客户端在服务器内存中启动例行程序控制后，停例行程序控制也由客户端负责。

-服务器例程应该在完成启动例程的例程控制请求消息和完成第一个响应消息之间的一段时间内在服务器内存中启动。

-服务器例程应该在完成stop例程请求消息和完成第一个响应消息后的一段时间内停止在服务器的内存中例程。

-客户端可以在例程停止后请求例程结果

方法B：

-假设客户端在服务器内存中启动例行程序控制后，停例行程序控制由服务器决定。

-服务器例程应该在启动例程的例程控制请求消息完成和第一个响应消息完成之间的一段时间内在服务器的内存中激活。

-服务器例程应在任何时间按程序或在服务器内存中预先初始化的方式停止。

4.1 例行程序控制（0x31）

4.1 服务介绍

例行程序控制服务被用来执行以下功能：

— 请求执行例行程序

— 请求结束例行程序

— 请求例行程序结果

例程采用两个字节的例程标识符；

1) 通过例行程序标识符请求执行例行程序

例行程序应在接收到开始执行例行程序请求信息和完成初次响应（肯定响应或否定响应）之间开始执行。响应信息来指示请求已经完成或正在进行中。

例行程序可以用来代替正常的操作或可以与运行的正常操作一起开启和执行，尤其是在第一种情况下，需要通过“诊断会话控制”服务进入一个特定的诊断会话或在该服务之前使用“安全访问”服务给电控单元解锁。

2) 通过例行程序标识符请求结束例行程序

例行程序应在接收到结束执行例行程序请求信息和完成初次响应（肯定响应或否定响应）之间结束例行程序。响应信息来指示请求已经完成或正在进行中。

在刷新或者ECU内存初始的任何时间例行程序都可以被结束。

3) 通过例行程序标识符请求例行程序结果

诊断设备使用该子功能请求存储在ECU内存中的例行程序标识符所关联的例行程序的执行结果。（例如，退出状态信息）。根据停止例行程序子功能请求的肯定响应反馈的例行程序执行结果（如果无法停止例行程序），则需要使用请求例行程序结果子功能请求判断例行程序的状态。

当某些数据由于ECU性能限制无法在例程执行过程中被发出时，这些数据可通过例程结果发出。

4.2 请求数据定义

其中31服务的sub-function在ISO14229-1中有如下定义

Bits 6 – 0	Description
0x00	ISOSAE保留
0x01	开始例程该参数表明ECU将会开始执行例行程序通过该参数标识符
0x02	停止例程该参数表明ECU将会停止执行例行程序通过该参数标识符
0x03	请求例程结果该参数表明ECU将反馈例行程序结果通过该参数标识符