UDS诊断之36服务

TransferData （0x36）—— 数据传输

这个服务通常是用来下载/上传数据时用的，数据的传输方向由不同的服务控制：0x34服务表示下载，0x35服务表示上传。

0x36服务包含了一个blockSequenceCounter，在多个服务请求序列失败的时候以提高错误处理机制。在接收到0x34/0x35服务以后，blockSequenceCounter会被初始化为1。

1.服务请求报文定义

图1 服务请求报文定义

Sub-Function：

本服务没有子服务。

服务请求报文中参数定义：

（1）blockSequenceCounter

这个值在第一次初始化的时候为0x01，往后每增加一次0x36服务的请求这个值也跟着增加1，直到增加到0xFF，会重新再从0x00增加（笔者的理解就是blockSequenceCounter的值对应用户此次请求传输出去的数据，以确保数据传输无误）。

例如以下2种情形：

• 数据已经正确的传输给ECU了，但是用户这边没有收到肯定响应，timeout以后用户这边会再次重复刚刚发出去的数据（blockSequenceCounter还是之前那个值）。这时候ECU通过blockSequenceCounter的值就可以知道用户又重复传了一次相同的数据，就不用再次重新写一遍Memory而直接给用户发送肯定响应。
• 如果数据没有正确传输给ECU，用户这边也不会收到肯定响应，timeout以后用户这边会再次重复刚刚发出去的数据（blockSequenceCounter还是之前那个值）。这时候ECU通过blockSequenceCounter的值就可以知道这是新传来的数据，则执行写Memory的操作，并且在成功后发送相应的肯定响应。

（2）transferRequestParameterRecord

用来传输的数据，格式和长度是由车厂自定义的。

2.肯定响应

图2 肯定响应报文格式

（1）blockSequenceCounter

与服务请求报文中的blockSequenceCounter一致。

（2）transferResponseParameterRecord

• 对于下载来说，transferResponseParameterRecord应该包含由ECU计算的checksum，并且这个参数中不会再重复transferRequestParameterRecord里的数据。
• 对于上传来说，transferResponseParameterRecord包含上传的数据。

3.支持的NRC

图3 0x36服务支持的NRC

4.示例

后续讲完0x37服务后展示。