UDS(ISO14229)诊断服务功能及描述完结篇

前言

  汽车诊断技术是指在不拆卸车辆的情况下，通过读取车辆在运行过程中所记录的数据或故障码来查明故障元婴，并确定故障部位的汽车应用技术。我们可以通过该技术，快速检测到汽车故障来提高汽车安全性和维修效率。USD协议诊断主要采用“问 - 答”模式，即诊断仪像车辆指定的ECU发送请求(Request)，指定的ECU会做出相对应的响应(Response)，并将响应返回给诊断仪。从而可以依据定义好的诊断描述文件，就可以将相对应的数据转化为相对应的问题和描述。

一、诊断和通信管理功能单元

1. 0x10(DiagnosticSessionControl)

  客户端请求控制与服务器的诊断会话。这里是所有诊断命令的基石。也就是说，如果你想完成你的诊断命令的发送与响应，首先需要明白0x10服务的作用。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x10(DiagnosticSessionControl)

2. 0x11(ECUReset)

  客户端强制服务器执行重置。这里定义了模拟的重置类型。当使用了该命令并且得到了正响应，则整个客户端将会重新进入到DefaultSession模式下。该点在实现自动化的过程中，需要格外的注意。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x11(ECUReset)

3. 0x27(SecurityAccess)

  客户端请求解锁安全服务器。如果在用于下载/上传的诊断服务例行程序或数据进入服务器并从服务器读取特定的内存位置的情况是可能需要安全访问。 不正确的例程或数据下载到服务器中可能损坏电子设备或其他车辆部件，或冒着车辆遵守排放，安全或安全标准。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x27(SecurityAccess)

4. 0x29(Authentication)

  该服务的目的是为客户提供一种证明其身份的方法，允许其访问数据或诊断服务，这部分数据或服务因安全、排放或安全原因而受到限制。 该服务致力于解决将例程或数据下载或上传到服务器并从服务器读取特定内存位置的诊断服务是可能需要身份验证的情况。不当程序或数据可能会损坏电子设备或其他车辆组件，或危及车辆遵守排放、安全或安保标准的风险。 另一方面，从服务器检索数据也可能会违反数据安全性。该服务支持两个安全概念：
  1. 基于使用非对称加密的 PKI 证书交换程序。 作为证书格式，应使用符合 ISO 7816-8 的 CVC 和符合 ISO/IEC 9594-8、RFC 5280 和 RFC 5755 或 IEEE 1609.2 的 X.509。
  2. 基于使用带有软件认证令牌的非对称加密或对称加密的不带 PKI 证书的请求-响应过程。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x29(Authentication)

5. 0x28(CommunicationControl)

  客户端请求服务器控制其通信。主要适用于打开/关闭某些消息的发送和/或接收。平时测试过程中，一般只会在需要测试该服务的时候，会对通讯模式进行更改。测试其他模块的时候，一般会将该服务设置为启用传输与接收模式，方便测试。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x28(CommunicationControl)

6. 0x3E(TesterPresent)

  客户端向服务器指示它仍然活跃。主要适用于维持在某一模式下。例如，我所在的项目中，进入Extended Session 之后，如果没有任何才做，等待4s之后会切换到Default Session。所以，如果需要维持在Extended Session的话，需要向服务器每隔固定的时间发送3E 服务来告诉服务器我还处在活跃的状态，不需要切换到默认模式。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x3E(TesterPresent)

7. 0x83(AccessTimingParameter)

  客户端使用此服务来读取/修改活动通信的时序参数。这个服务在我的使用过程中没有接触到，所以这里只能提供一些学习内容上的分享。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x83(AccessTimingParameter)

8. 0x84(SecuredDataTransmission)

  客户端使用此服务以扩展的数据链路安全性执行数据传输。此服务主要是在传输数据的过程中，防止受到来自第三方的危害数据安全的数据攻击，更详细的介绍请参考 ISO 15764。也可以用于在客户端和服务器之间以安全模式传输符合某些其他应用程序协议的外部数据。 在这种情况下，安全模式意味着所传输的数据受到保护。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x84(SecuredDataTransmission)

9. 0x85(ControlDTCSetting)

  客户端控制服务器中DTC的设置。这个服务可以选择是否屏蔽DTC的上报，验证其是否真正生效通常会跟0x19服务配合着使用。客户端使用ControlDTCSetting服务来停止或恢复服务器中诊断故障代码（DTC）的设置。该服务请求消息可用于停止在单个服务器或一组服务器中设置诊断故障代码。如果被寻址的服务器不能更改诊断故障代码的设置，则应以ControlDTCSetting否定响应消息作为响应，指示拒绝原因。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x85(ControlDTCSetting)

10. 0x86(ResponseOnEvent)

  客户端请求启动服务器中的事件机制。该服务是请求服务器启动或停止对指定事件的响应的传输。如果服务器中发生指定的事件，此服务提供了自动执行诊断服务的可能性。 客户端指定事件（包括可选的事件参数）和事件发生时要执行的服务（包括服务参数）。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x86(ResponseOnEvent)

11. 0x87(LinkControl)

  客户端请求控制通信波特率。LinkControl服务用于控制客户端和服务器之间的通信链接波特率，以交换诊断数据。 该服务可应用于那些允许在活动诊断会话期间进行波特率转换数据链路层。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x87(LinkControl)

二、数据传输功能单元

1. 0x22(ReadDataByIdentifier)

  客户端请求读取由提供的DID标识的记录的当前值。该服务允许客户端从服务器请求由一个或多个 DID 标识的数据记录值。客户端请求消息包含一个或多个两字节的DID值，这些值标识服务器维护的数据记录。 dataRecord的格式和定义应特定于车辆制造商或系统供应商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。服务器可以限制车辆制造商和系统供应商所同意的可同时请求的DID的数量。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x22(ReadDataByIdentifier)

2. 0x23(ReadMemoryByAddress)

  客户端请求读取提供的内存范围的当前值。该服务允许客户端通过提供的起始地址从服务器请求内存数据，并指定要读取的内存大小。 该服务请求消息用于从由参数memoryAddress和memorySize标识的服务器请求内存数据。对于memoryAddress和memorySize参数的字节数由addressAndLengthFormatIdentifier定义。 也可以使用固定的addressAndLengthFormatIdentifier。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x23(ReadMemoryByAddress)

3. 0x24(ReadScalingDataByIdentifier)

  客户端请求读取DID记录的缩放信息。 dataRecord的格式和定义应特定于车辆制造商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。在收到ReadScalingDataByIdentifier请求后，服务器应访问与指定的dataIdentifier参数关联的缩放信息，并在一个ReadScalingDataByIdentifier肯定响应中发送缩放信息值。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x24(ReadScalingDataByIdentifier)

4. 0x2A(ReadDataByPeriodicIdentifier)

  客户端请求调度服务器中的数据以进行定期传输。该服务允许客户端从服务器请求由一个或多个 PeriodicDataIdentifiers 标识的数据记录值的定期传输。dataRecord的格式和定义应特定于车辆制造商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。在收到除 stopSending 以外的 ReadDataByPeriodicIdentifier 请求时，服务器应检查条件是否正确以执行服务。如果条件正确，则服务器应发送肯定的响应消息，仅包括服务标识符。一旦服务器通过肯定的响应接受了初始请求消息，服务器将永远不会发送否定的响应消息。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x2A(ReadDataByPeriodicIdentifier)

5. 0x2C(DynamicallyDefineDataIdentifier)

  客户端请求动态定义数据标识符，这些数据标识符随后可以由0x22(ReadDataByIdentifier)服务读取。该服务的目的是为客户端提供将一个或多个数据元素分组为数据超集的功能，可以通过 0x22(ReadDataByIdentifier) 或0x2A(ReadDataByPeriodicIdentifier) 服务进行整体请求。该服务在处理诊断应用程序的临时数据需求方面提供了更大的灵活性，超出了可以通过静态定义的 DID 读取的信息的范围，并且还可以通过避免频繁的请求/响应从而降低带宽利用率。动态定义的 DID的定义可以通过单个请求消息或通过多个请求消息来完成。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x2C(DynamicallyDefineDataIdentifier)

6. 0x2E(WriteDataByIdentifier)

  请求写入提供的 DID 指定的数据。该服务允许客户端在由提供的 DID 指定的内部位置将数据写入服务器。数据并且可能会受到保护，也有可能不受到保护。0x2C(DynamicallyDefineDataIdentifier)服务不得与此服务一起使用。服务器可以限制或禁止对某些 DID 值（由供应商/主车厂 定义为只读的 DID）的写访问。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x2E(WriteDataByIdentifier)

7. 0x3D(WriteMemoryByAddress)

  客户端请求覆盖指定的内存范围。该服务会将参数 dataRecord 指定的数据写入由参数 memoryAddress 和 memorySize 指定的存储位置的服务器中。memoryAddress 和 memorySize 参数的字节数由addressAndLengthFormatIdentifier（低半字节和高半字节）定义。 还可以在 memoryAddress 或 memorySize 参数中使用固定的 addressAndLengthFormatIdentifier 和未使用的字节在较高范围的地址位置中填充值 0x00 。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x3D(WriteMemoryByAddress)

三、已存储数据传输功能单元

1. 0x14(ClearDiagnosticInformation)

  允许客户端从服务器清除诊断信息（包括DTC，捕获的数据等）。完全处理该服务后，服务器应发送肯定响应。即使没有存储任何DTC，服务器也应发送肯定的响应。 如果服务器支持内存中 DTC 状态信息的多个副本，则服务器应清除 ReadDTCInformation 状态报告服务使用的副本。永久故障码应存储在非易失性存储器中。 这些 DTC 不能通过任何测试设备（例如车载测试仪，非车载测试仪）清除。 OBD 系统应通过完成并通过车载监控器自行清除这些故障诊断代码。 这将防止仅通过断开电池来清除 DTC。如果重新编程了发动机控制模块，并且所有受监视的组件和系统的就绪状态都设置为“未完成”，则永久性 DTC 必须可擦除。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x14(ClearDiagnosticInformation)

2. 0x19(ReadDTCInformation)

  允许客户端从服务器请求诊断信息（包括DTC，捕获的数据等）。该服务允许客户端从车辆内的任何服务器或服务器组读取服务器驻留诊断故障代码（DTC）信息的状态。 除非另有说明，否则服务器应返回与排放有关的 DTC 信息和与排放无关的 DTC 信息。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x19(ReadDTCInformation)

四、输入输出控制功能单元

1. 0x2F(InputOutputControlByIdentifier)

  请求控制服务器的输入/输出。客户端请求消息包含一个 DID，用于输入信号，内部服务器功能或输出信号。 controlOptionRecord 参数应包含服务器的输入信号，内部功能和输出信号所需的所有信息。如果请求消息已成功执行，则服务器应发送肯定响应消息。 即使 DID 当前不受测试人员控制，服务器也应使用 returnControlToECU 的inputOutputControlIParameter 向请求消息发送肯定响应消息。 如果需要，请求消息的 controlOptionRecord 参数可以实现为单个ON / OFF 参数，也可以实现为更复杂的控制参数序列，包括多个循环，持续时间等。该服务允许在单个请求消息中使用相应的 controlOptionRecord 控制单个 DID。 这样，服务器将以单个响应消息进行响应，其中包括请求消息的 DID 以及可选的 controlStatus 信息。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x2F(InputOutputControlByIdentifier)

五、例程控制功能单元

1. 0x31(RoutineControl)

  客户端请求启动/停止服务器中的例程或请求例程结果。客户端使用 RoutineControl 服务来控制 RID，RID 由两字节的例程标识符标识。具体的控制类型有以下三种：第一种： 启动 RID；第二种： 停止 RID；第三种： 查询 RID 执行结果。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x31(RoutineControl)

六、上传下载功能单元

1. 0x34(RequestDownload)

  客户端请求从客户端到服务器的数据传输。服务器收到 requestDownload 请求消息后，服务器应在发送肯定响应消息之前采取所有必要的措施来接收数据。在这里，ISO 14229 中并没有明确定义需要采用什么措施来确保接受数据的可行性。因此，需要额外关注主车厂给到的相关措施。我所在项目的要求是：进入ProgrammingSession 会话模式下，并对安全访问进行解锁之后才能进行数据的传输。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x34(RequestDownload)

2. 0x35(RequestUpload)

  客户端请求从服务器到客户端的数据传输。服务器收到 requestUpload 请求消息后，服务器应采取所有必要的措施在发送肯定响应消息之前发送数据。在这里，ISO 14229 中并没有明确定义需要采用什么措施来确保接受数据的可行性。因此，需要额外关注主车厂给到的相关措施。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x35(RequestUpload)

3. 0x36(TransferData)

  客户端将数据传输到服务器（下载）或从服务器请求数据（上传）。数据传输方向由前面的 RequestDownload 或 RequestUpload 服务定义。 如果客户端启动了 RequestDownload，则要下载的数据将包含在 TransferData 请求消息中的参数 transferRequestParameter 中。 如果客户端启动了 RequestUpload，则要上载的数据将包含在 TransferData 响应消息中的参数 transferResponseParameter中。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x36(TransferData)

4. 0x37(RequestTransferExit)

  客户端请求终止数据传输。参数 transferRequestParameterRecord 记录包含服务器支持数据传输所需的参数。 这些参数的格式和长度是由主车厂定义的。
详情请看文章链接：跟我学UDS(ISO14229) ———— 0x37(RequestTransferExit)

附录

ISO 14229 协议中所有NRC码的汇总：跟我学UDS(ISO14229) ———— NRC码

Sub-function 参数的详细说明：

我的理解是：
Bit 7 决定该请求是否需要抑制正响应的发送。当bit 7 被置1时，此时系统不会发送正响应。
Bit 0-6 决定了sub-function的值。

跟我学UDS(ISO14229) ———— 0x19 服务参数介绍

 这篇文章主要介绍了一些 0x19 服务在使用过程中的一些参数。平时可能并没有深入的去了解他们的工作原理，转换机制以及具体含义。在这里，我帮大家总结了一篇文章，希望对大家理解这个服务有帮助。

其他的附录表格，我均把他们放在了所需要使用的服务当中，这样更方便大家的理解和阅读。