 Show
于 2022-03-31 14:44:58 首次发布 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 一．服务概述此服务的目的是为客户提供一种证明其身份的方法，允许其访问数据和/或诊断服务，这些数据和/或诊断服务由于安全、排放或安全等原因而受到限制。
用于将例程或数据下载/上传到服务器以及从服务器读取特定内存位置的诊断服务可能需要身份验证。 不正确的程序或下载到服务器的数据可能会潜在地损害电子设备或其他车辆部件，或危及车辆的排放、安全或安全标准的遵守。 另一方面，当从服务器检索数据时，可能会违反数据安全性。 图片摘自ISO 14229 子功能定义： •“ deAuthenticate ”，此子功能参数有效地结束认证状态。 •“ VerfyCertificateUnidirectional ”，此子功能参数启动单向身份验证过程，仅针对 ECU 对测试仪进行单向身份验证。 • “verifyCertificateBidirectional”， 这个SubFunction参数启动双向身份验证过程，客户端对服务器进行身份验证，服务器对客户端进行身份验证。 •“ proofOfOwnership ”，此子功能参数用于将所有权证明数据传输到测试仪。 •“ TransmitCertificate ”，此子功能参数独立或在先前的身份验证之后传输证书。 二、基于PKI 证书交换的认证Authentication with PKI Certificate Exchange (APCE)前提条件： 认证流程 图片摘自ISO 14229 认证过程概述： 1 测试人员向 ECU 发出身份验证请求； 2. 在此请求消息中，包含测试仪的证书； 3. 收到请求消息后，ECU 将验证测试仪的证书； 4. 如果通过了证书验证，则 ECU 创建一个挑战 ； 5，6 取决于认证所使用的算法及是否双向认证； 7.并将挑战发送回测试人员； 8. 只是双向认证用到； 9.取决于认证所用到的算法 10. 测试人员通过签署挑战 ECU 来计算所有权证明测试人员； 11. 测试人员将所有权证明发送给 ECU ； 12. ECU 用收到的证书测试器中的公钥验证所有权证明测试器； 13.用来创建会话密钥（可选）； 14.设定访问权限； 15. 如果通过了所有权证明的验证，则 ECU 返回响应或者会话密钥（会话密钥可选）； 16，17，18用来设定会话密钥 最后. ECU 响应认证成功。 三、基于挑战应答的认证Authentication with Challenge-Response (ACR)前提条件： 认证流程概述 1 测试人员通过 SubFunction requestChallengeForAuthentication 请求认证。 2. ECU 创建挑战 3. ECU 将挑战发送给测试人员。（14229图中的序号错误应该为3） 4. 双向认证时需要 5. 测试人员计算测试人员的所有权证明如下： 如果非对称密码时:构建适当的(特定于汽车制造商的)令牌(例如，基于CVC)内容，包含令牌授权、身份验证、权限/角色、服务器端质询信息，以及客户端质询信息和其他信息，视情况而定。使用客户私钥计算令牌内容签名，并构建包含令牌内容和签名的客户端身份验证令牌。产生的客户端身份验证令牌是客户端POWN。 如果使用对称密码：使用预共享的对称密钥，通过 ECU 侧 Challenge 来计算签名（例如，一次签名 或 HMAC 或 CMAC ）。生成的签名是测试者方 POWN 。 6. 如果服务器在步骤3中指示了其他参数，那么客户端在需要的附加参数中提供适当的附加参数。 7. 测试人员通过子功能 verifyProofOfOwnershipUnidirectional 发送测试人员端 POWN 。 8. ECU 验证测试仪侧 POWN 。 11. 如果验证成功，ECU 根据访问权限授予对诊断对象的访问权限。 9，10，12~16 取决于是否双向认证和是否需要会话密钥 四、服务格式具体服务格式请参考ISO 14229-1 2020版 文章目录
前言汽车诊断技术是指在不拆卸车辆的情况下，通过读取车辆在运行过程中所记录的数据或故障码来查明故障元婴，并确定故障部位的汽车应用技术。我们可以通过该技术，快速检测到汽车故障来提高汽车安全性和维修效率。USD协议诊断主要采用“问 - 答”模式，即诊断仪像车辆指定的ECU发送请求(Request)，指定的ECU会做出相对应的响应(Response)，并将响应返回给诊断仪。从而可以依据定义好的诊断描述文件，就可以将相对应的数据转化为相对应的问题和描述。 一、诊断和通信管理功能单元1. 0x10(DiagnosticSessionControl) 客户端请求控制与服务器的诊断会话。这里是所有诊断命令的基石。也就是说，如果你想完成你的诊断命令的发送与响应，首先需要明白0x10服务的作用。 2. 0x11(ECUReset) 客户端强制服务器执行重置。这里定义了模拟的重置类型。当使用了该命令并且得到了正响应，则整个客户端将会重新进入到DefaultSession模式下。该点在实现自动化的过程中，需要格外的注意。 3. 0x27(SecurityAccess) 客户端请求解锁安全服务器。如果在用于下载/上传的诊断服务例行程序或数据进入服务器并从服务器读取特定的内存位置的情况是可能需要安全访问。 不正确的例程或数据下载到服务器中可能损坏电子设备或其他车辆部件，或冒着车辆遵守排放，安全或安全标准。 4. 0x29(Authentication) 该服务的目的是为客户提供一种证明其身份的方法，允许其访问数据或诊断服务，这部分数据或服务因安全、排放或安全原因而受到限制。 该服务致力于解决将例程或数据下载或上传到服务器并从服务器读取特定内存位置的诊断服务是可能需要身份验证的情况。不当程序或数据可能会损坏电子设备或其他车辆组件，或危及车辆遵守排放、安全或安保标准的风险。 另一方面，从服务器检索数据也可能会违反数据安全性。该服务支持两个安全概念： 5. 0x28(CommunicationControl) 客户端请求服务器控制其通信。主要适用于打开/关闭某些消息的发送和/或接收。平时测试过程中，一般只会在需要测试该服务的时候，会对通讯模式进行更改。测试其他模块的时候，一般会将该服务设置为启用传输与接收模式，方便测试。 6. 0x3E(TesterPresent) 客户端向服务器指示它仍然活跃。主要适用于维持在某一模式下。例如，我所在的项目中，进入Extended Session 之后，如果没有任何才做，等待4s之后会切换到Default Session。所以，如果需要维持在Extended Session的话，需要向服务器每隔固定的时间发送3E 服务来告诉服务器我还处在活跃的状态，不需要切换到默认模式。 7. 0x83(AccessTimingParameter) 客户端使用此服务来读取/修改活动通信的时序参数。这个服务在我的使用过程中没有接触到，所以这里只能提供一些学习内容上的分享。 8. 0x84(SecuredDataTransmission) 客户端使用此服务以扩展的数据链路安全性执行数据传输。此服务主要是在传输数据的过程中，防止受到来自第三方的危害数据安全的数据攻击，更详细的介绍请参考 ISO 15764。也可以用于在客户端和服务器之间以安全模式传输符合某些其他应用程序协议的外部数据。 在这种情况下，安全模式意味着所传输的数据受到保护。 9. 0x85(ControlDTCSetting)
客户端控制服务器中DTC的设置。这个服务可以选择是否屏蔽DTC的上报，验证其是否真正生效通常会跟0x19服务配合着使用。客户端使用ControlDTCSetting服务来停止或恢复服务器中诊断故障代码（DTC）的设置。该服务请求消息可用于停止在单个服务器或一组服务器中设置诊断故障代码。如果被寻址的服务器不能更改诊断故障代码的设置，则应以ControlDTCSetting否定响应消息作为响应，指示拒绝原因。 10. 0x86(ResponseOnEvent)
客户端请求启动服务器中的事件机制。该服务是请求服务器启动或停止对指定事件的响应的传输。如果服务器中发生指定的事件，此服务提供了自动执行诊断服务的可能性。 客户端指定事件（包括可选的事件参数）和事件发生时要执行的服务（包括服务参数）。 11. 0x87(LinkControl) 客户端请求控制通信波特率。LinkControl服务用于控制客户端和服务器之间的通信链接波特率，以交换诊断数据。 该服务可应用于那些允许在活动诊断会话期间进行波特率转换数据链路层。 二、数据传输功能单元1. 0x22(ReadDataByIdentifier) 客户端请求读取由提供的DID标识的记录的当前值。该服务允许客户端从服务器请求由一个或多个 DID 标识的数据记录值。客户端请求消息包含一个或多个两字节的DID值，这些值标识服务器维护的数据记录。
dataRecord的格式和定义应特定于车辆制造商或系统供应商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。服务器可以限制车辆制造商和系统供应商所同意的可同时请求的DID的数量。 2. 0x23(ReadMemoryByAddress) 客户端请求读取提供的内存范围的当前值。该服务允许客户端通过提供的起始地址从服务器请求内存数据，并指定要读取的内存大小。
该服务请求消息用于从由参数memoryAddress和memorySize标识的服务器请求内存数据。对于memoryAddress和memorySize参数的字节数由addressAndLengthFormatIdentifier定义。 也可以使用固定的addressAndLengthFormatIdentifier。 3. 0x24(ReadScalingDataByIdentifier) 客户端请求读取DID记录的缩放信息。
dataRecord的格式和定义应特定于车辆制造商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。在收到ReadScalingDataByIdentifier请求后，服务器应访问与指定的dataIdentifier参数关联的缩放信息，并在一个ReadScalingDataByIdentifier肯定响应中发送缩放信息值。 4. 0x2A(ReadDataByPeriodicIdentifier)
客户端请求调度服务器中的数据以进行定期传输。该服务允许客户端从服务器请求由一个或多个 PeriodicDataIdentifiers 标识的数据记录值的定期传输。dataRecord的格式和定义应特定于车辆制造商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。在收到除 stopSending 以外的 ReadDataByPeriodicIdentifier 请求时，服务器应检查条件是否正确以执行服务。如果条件正确，则服务器应发送肯定的响应消息，仅包括服务标识符。一旦服务器通过肯定的响应接受了初始请求消息，服务器将永远不会发送否定的响应消息。 5. 0x2C(DynamicallyDefineDataIdentifier) 客户端请求动态定义数据标识符，这些数据标识符随后可以由0x22(ReadDataByIdentifier)服务读取。该服务的目的是为客户端提供将一个或多个数据元素分组为数据超集的功能，可以通过 0x22(ReadDataByIdentifier) 或0x2A(ReadDataByPeriodicIdentifier) 服务进行整体请求。该服务在处理诊断应用程序的临时数据需求方面提供了更大的灵活性，超出了可以通过静态定义的 DID 读取的信息的范围，并且还可以通过避免频繁的请求/响应从而降低带宽利用率。动态定义的 DID的定义可以通过单个请求消息或通过多个请求消息来完成。 6. 0x2E(WriteDataByIdentifier) 请求写入提供的 DID 指定的数据。该服务允许客户端在由提供的 DID 指定的内部位置将数据写入服务器。数据并且可能会受到保护，也有可能不受到保护。0x2C(DynamicallyDefineDataIdentifier)服务不得与此服务一起使用。服务器可以限制或禁止对某些 DID 值（由供应商/主车厂 定义为只读的 DID）的写访问。 7. 0x3D(WriteMemoryByAddress) 客户端请求覆盖指定的内存范围。该服务会将参数 dataRecord 指定的数据写入由参数 memoryAddress 和 memorySize 指定的存储位置的服务器中。memoryAddress 和 memorySize 参数的字节数由addressAndLengthFormatIdentifier（低半字节和高半字节）定义。 还可以在 memoryAddress 或 memorySize 参数中使用固定的 addressAndLengthFormatIdentifier
和未使用的字节在较高范围的地址位置中填充值 0x00 。 三、已存储数据传输功能单元1. 0x14(ClearDiagnosticInformation) 允许客户端从服务器清除诊断信息（包括DTC，捕获的数据等）。完全处理该服务后，服务器应发送肯定响应。即使没有存储任何DTC，服务器也应发送肯定的响应。 如果服务器支持内存中 DTC 状态信息的多个副本，则服务器应清除 ReadDTCInformation
状态报告服务使用的副本。永久故障码应存储在非易失性存储器中。 这些 DTC 不能通过任何测试设备（例如车载测试仪，非车载测试仪）清除。 OBD 系统应通过完成并通过车载监控器自行清除这些故障诊断代码。 这将防止仅通过断开电池来清除 DTC。如果重新编程了发动机控制模块，并且所有受监视的组件和系统的就绪状态都设置为“未完成”，则永久性 DTC 必须可擦除。 2. 0x19(ReadDTCInformation)
允许客户端从服务器请求诊断信息（包括DTC，捕获的数据等）。该服务允许客户端从车辆内的任何服务器或服务器组读取服务器驻留诊断故障代码（DTC）信息的状态。 除非另有说明，否则服务器应返回与排放有关的 DTC 信息和与排放无关的 DTC 信息。 四、输入输出控制功能单元1. 0x2F(InputOutputControlByIdentifier) 请求控制服务器的输入/输出。客户端请求消息包含一个 DID，用于输入信号，内部服务器功能或输出信号。 controlOptionRecord
参数应包含服务器的输入信号，内部功能和输出信号所需的所有信息。如果请求消息已成功执行，则服务器应发送肯定响应消息。 即使 DID 当前不受测试人员控制，服务器也应使用 returnControlToECU 的inputOutputControlIParameter 向请求消息发送肯定响应消息。 如果需要，请求消息的 controlOptionRecord 参数可以实现为单个ON / OFF 参数，也可以实现为更复杂的控制参数序列，包括多个循环，持续时间等。该服务允许在单个请求消息中使用相应的 controlOptionRecord 控制单个 DID。 这样，服务器将以单个响应消息进行响应，其中包括请求消息的 DID 以及可选的 controlStatus 信息。 五、例程控制功能单元1. 0x31(RoutineControl) 客户端请求启动/停止服务器中的例程或请求例程结果。客户端使用 RoutineControl 服务来控制 RID，RID 由两字节的例程标识符标识。具体的控制类型有以下三种：第一种： 启动 RID；第二种： 停止 RID；第三种： 查询 RID 执行结果。 六、上传下载功能单元1. 0x34(RequestDownload)
客户端请求从客户端到服务器的数据传输。服务器收到 requestDownload 请求消息后，服务器应在发送肯定响应消息之前采取所有必要的措施来接收数据。在这里，ISO 14229 中并没有明确定义需要采用什么措施来确保接受数据的可行性。因此，需要额外关注主车厂给到的相关措施。我所在项目的要求是：进入ProgrammingSession 会话模式下，并对安全访问进行解锁之后才能进行数据的传输。 2. 0x35(RequestUpload) 客户端请求从服务器到客户端的数据传输。服务器收到 requestUpload 请求消息后，服务器应采取所有必要的措施在发送肯定响应消息之前发送数据。在这里，ISO
14229 中并没有明确定义需要采用什么措施来确保接受数据的可行性。因此，需要额外关注主车厂给到的相关措施。 3. 0x36(TransferData) 客户端将数据传输到服务器（下载）或从服务器请求数据（上传）。数据传输方向由前面的 RequestDownload 或 RequestUpload 服务定义。 如果客户端启动了 RequestDownload，则要下载的数据将包含在 TransferData 请求消息中的参数 transferRequestParameter 中。 如果客户端启动了 RequestUpload，则要上载的数据将包含在 TransferData 响应消息中的参数
transferResponseParameter中。 4. 0x37(RequestTransferExit) 客户端请求终止数据传输。参数 transferRequestParameterRecord 记录包含服务器支持数据传输所需的参数。 这些参数的格式和长度是由主车厂定义的。 附录ISO 14229 协议中所有NRC码的汇总：跟我学UDS(ISO14229) ———— NRC码Sub-function 参数的详细说明： 我的理解是： Bit 7 决定该请求是否需要抑制正响应的发送。当bit 7 被置1时，此时系统不会发送正响应。 Bit 0-6 决定了sub-function的值。 跟我学UDS(ISO14229) ———— 0x19 服务参数介绍这篇文章主要介绍了一些 0x19 服务在使用过程中的一些参数。平时可能并没有深入的去了解他们的工作原理，转换机制以及具体含义。在这里，我帮大家总结了一篇文章，希望对大家理解这个服务有帮助。 其他的附录表格，我均把他们放在了所需要使用的服务当中，这样更方便大家的理解和阅读。 |
UDS 29服务
版權 © 2024 ihoctot Inc.
