《UDS协议从入门到精通》系列------图解0x35：请求上传
- 一、简介
- 二、数据包格式
-
- [2.1 服务请求格式](#2.1 服务请求格式)
- [2.2 服务响应格式](#2.2 服务响应格式)
-
- [2.2.1 肯定响应](#2.2.1 肯定响应)
- [2.2.2 否定响应](#2.2.2 否定响应)
- 三、通信示例
Tip📌：本文描述中但凡涉及到其他UDS服务的，将陆续提供链接跳转方式以便快速了解他们。（各服务介绍持续更新中...）
学习UDS基础知识以及其他相关内容？>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通（UDS速查手册）》<<<<<<<<<
一、简介
Tip📌：该服务跟34使用方式上服务几乎一致，推荐先阅读《UDS协议从入门到精通》系列------图解0x34：请求下载
与0x34服务相反，该服务用于启动数据上传服务，传输方向是目标ECU（Server）→ Tester（Client），向目标ECU发送该请求的主要作用就是告知目标ECU"我（Tester）想要你存储的数据，请你（目标ECU）发送给我"。
二、数据包格式
2.1 服务请求格式
该服务不支持sub-function。部分参数的含义如下所示：
dataFormatIdentifier（1Byte） ：这个单字节里面标识了数据格式相关的信息，每半个字节分别编码，高半字节指定 "数据压缩方法"，而低半字节则指定"数据加密方法"。如果该字节取值为0x00，则表示既不使用加密方法也不适用压缩方法，其他取值情况有整车制造商或者供应商决定，可以用约定好用不同的取值代表数据是否有压缩，是否有加密，用的又是什么算法等等。
addressAndLengthFormatIdentifier（1Byte）：该参数含义在图中标识的已经比较清晰，不再赘述。比如memoryAddress参数占用m个字节，memorySize参数占用n个字节，则该参数取值为0x(nm)。
memoryAddress（mByte）：对于即将启动的数据传输，该参数指明了从目标ECU内存读取数据的逻辑地址。比如Tester请求将数据写入ECU内存地址为0x12345678的地方（该地址占4个字节），则memoryAddress值为0x12345678，对应addressAndLengthFormatIdentifier参数低4Bits值为0x04。
memorySize（nByte）：对于即将启动的数据传输，该参数指明了从ECU内存读取数据的字节数。比如Tester请求读取目标ECU数据的字节数为0x01234567（即memorySize占4字节），则memorySize值为0x01234567，对应的addressAndLengthFormatIdentifier高4Bits值为0x4。
2.2 服务响应格式
2.2.1 肯定响应
lengthFormatIdentifier（1Byte）：该字节每半个字节单独编码，高4Bits为maxNumberOfBlockLength有效字节长度，低4Bits保留为0。
maxNumberOfBlockLength：字节长度不定，取值长度取决于lengthFormatIdentifier的高半字节，表示0x36服务一次传输一个block的最大的字节数。比如该参数取值为0x202，则使用0x36服务时，一次最多发送字节数为0x202（字节数：0x202 >= 36 （1Byte）+ parameter（x个Bytes））。
这些参数确保了Tester和目标ECU之间的数据传输能够高效和安全地进行。通过maxNumberOfBlockLength参数，Tester可以预先知道目标ECU将发送的数据块的最大长度，从而可以适当地调整自己的接收缓冲区，以避免数据丢失或溢出。
2.2.2 否定响应
可能出现的NRC及其含义如下：
| NRC | 含义 |
|---|---|
| 0x13 | 消息长度错误 |
| 0x22 | 当前条件不满足 |
| 0x31 | 请求参数不受支持，参数错误 |
| 0x33 | 未通过安全访问 |
| 0x70 | 由于某些故障导致无法上传目标ECU的数据到Tester中 |
NRC的处理流程如下所示（即推荐的错误情况检查顺序）：
三、通信示例
基于对本服务以及0x36、0x37三个服务的学习，这里举一个完整的例子，该示例实现：将数据从目标ECU上传到Tester中。数据从目标ECU上传到Tester的过程分三步：
- Tester通过0x35-请求上传服务向目标ECU发送请求，该请求消息中将包括数据的格式信息（是否压缩、加解密信息）、要从目标ECU的哪个地址获取数据、要获取多少字节的数据。目标ECU收到该请求后将通过响应告诉Tester："我（目标ECU）每次最多能传输多少自字节"，即目标ECU会表明自己每次的上传能力。
- Tester得知目标ECU每次上传能力后，将按照目标ECU上传能力做适配，目标ECU将通过0x36-数据传输服务将数据一块块的上传到Tester。
- Tester端收到期望的数据后，通过发送0x37-退出传输服务请求来终止数据上传过程。
在钥匙电开启，发动机关闭，车速为0的背景下，Tester和目标ECU间的通信过程如下图所示：
Tester 目标ECU 通过0x35-请求上传服务向目标ECU发送请求 35 11 33 20 10 00 00 01 FF 1 发起上传数据的请求： 34：Service ID 11：标识数据压缩及加解密算法信息 33：表明地址和大小信息占用几个字节， 高低四位都是3，即地址和大小信息都占3字节 20 10 00：取目标ECU中地址0x201000的数据 00 01 FF：要获取数据大小是0x0001FF(511字节) 75 20 00 81 2 目标ECU通过响应表明自己的上传能力： 74：Service ID + 40 20：高四位表示每次最大传输长度2字节，低四位默认0 00 81：每次最多传输0x0081(129字节)数据 通过36服务传输每个数据块，共计要传输：511➗127=5次，4次不能传完，要再来一次 36 01 3 请求第一块数据： 36：Service ID 01：标识请求的数据块序号 76 01 (xx xx ... xx 实际数据共127字节) 4 通过0x36服务响应发送数据： 76：Service ID + 0x40 01：标识这是第几个数据块（block） 剩下的127字节：实际数据 前面目标ECU回复的最大 接收能力是包括36和01两个字节的 ... ...（传输第2块数据） ... ...（传输第3块数据） ... ...（传输第4块数据） 36 05 5 请求最后一个数据块： 36：Service ID 05：最后一个数据块的序号 76 05 (xx xx xx 实际数据还剩511 - 127*4 = 3字节) 6 通过0x36服务响应发送数据： 76：Service ID + 0x40 05：标识这是第几个数据块（block） 最后剩下3字节实际数据 通过0x37-退出传输服务来终止数据传输过程 37 7 发送退出传输请求， 不跟其他参数也可以，由制造商决定 77 8 给出正响应， 不跟其他参数也可以，由制造商决定 Tester 目标ECU