1.前言
新能源汽车普遍具备OTA升级的功能。
而ECU往往是通过CAN通信接受升级的数据包并完成更新升级。
本篇文章分析新能源汽车OTA升级中的UDS通信。
OTA升级时UDS通信的双方是Tester和ECU。
2. OTA升级前
2.1 下载OTA升级安装包
OTA升级前，汽车车机需要从远程的服务器上下载到升级安装包，并利用签名算法验证升级安装包的完整性。
2.2 汽车升级环境准备
每次OTA升级大概要花费1个小时的时间。
因此，汽车OTA包下载到本地后车机后，车机和ECU通信前，需要检查汽车是否具备OTA升级的条件。
比如：汽车的电量是否够？汽车是否是停车状态？
如果汽车升级环境不具备，则禁止升级。
3. 升级步骤
每次OTA升级，会涉及多个ECU，他们之间有时有顺序关系，但是对于每个ECU的升级步骤则大同小异，这里针对单个ECU的升级过程做分析。这里拿canid是“710/718”的ECU举例。
UDS报文data的格式为：
单帧：正文长度 + UDS服务编号 + 填充符
多帧：较为复杂，见具体解释。
3.1 汽车升级环境确认
再次确认汽车升级环境具备了。
大多数情况下，这一步可以忽略。
对于部分使用频率不高的ECU，可能大多数时间处于休眠状态，如果汽车内部通信畅通，ECU在汽车正常工作状态时会受到汽车某其他ECU发过来的请求唤醒的报文。ECU在被唤醒后才可以进行OTA升级。
3.2 进入03扩展会话
tester向ECU发送
canid:0x710
data: [0x02, 0x10, 0x03, 0x55, 0x55, 0x55, 0x55, 0x55]ECU回复tester
canid:0x718
data: [0x06, 0x50, 0x03, 0x00, 0x32, 0x01, 0xf4, 0xaa]报文内容解读：
0x32, 0x01, 0xf4:
0x0032=50ms=0.05秒: p2server_max，指的是ECU在收到请求和给出响应之间的这个时间间隔，他描述了ECU的反应速度。
0x01f4=0x01F4*10ms=5000ms=5秒: p2*server_max。
诊断仪收到这两个参数之后，就对ECU的响应速度有了认知，可以据此来判断ECU的响应是否及时。
推荐阅读资料：
统一诊断服务(UDS) - 诊断会话控制（Diagnostic Session Control）_百战穿甲的博客-CSDN博客_uds会话
3.3 状态更新（判断ECU升级环境是否具备）
tester向ECU发送
canid:0x710
data: [0x04, 0x31, 0x01, 0x02, 0x03, 0x55, 0x55, 0x55]ECU回复tester
canid:0x718
data: [0x04, 0x71, 0x01, 0x02, 0x03, 0xaa, 0xaa, 0xaa]推荐阅读资料：
UDS 服务 Service 0x31 - RoutineControl_aFakeProgramer的博客-CSDN博客_uds31服务
3.4 关闭DTC错误诊断功能 与 禁止ECU间数据传输
3.4.1 DTC OFF
tester向ECU发送广播
canid:0x7DF
data: [0x02, 0x85, 0x02, 0x55, 0x55, 0x55, 0x55, 0x55]3.4.2 forbid transfer
tester向ECU发送广播
canid:0x7DF
data: [0x03, 0x28, 0x03, 0x01, 0x55, 0x55, 0x55, 0x55]推荐阅读资料：
UDS（七）应用层 28/85_车小猿的博客-CSDN博客_uds85服务
3.5 安全解锁与进入02编程会话
要想具有刷写ECU的权限，必须顺利进入02编程会话，而能否顺利进入02编程会话的前提则是安全解锁验证要能通过。
3.5.1 seed/key安全验证
tester向ECU请求seed
canid:0x710
data: [0x02, 0x27, 0x01, 0x55, 0x55, 0x55, 0x55, 0x55]ECU回复tester seed
若seed长度为2个字节：
canid:0x718
data: [0x04, 0x67, 0x01, key0, key1, 0xaa, 0xaa, 0xaa]若seed长度为4个字节：
canid:0x718
data: [0x06, 0x67, 0x01, key0, key1, key2, kehy3, 0xaa]tester向ECU发送key请求鉴权
若seed长度为2个字节：
canid:0x710
data:[0x06, 0x27, 0x02, key0, key1, 0x55, 0x55, 0x55]若seed长度为4个字节：
canid:0x710
data:[0x06, 0x27, 0x04, key0, key1, key2, key3, 0x55]ECU回复tester鉴权通过
canid:0x718
data: [0x02, 0x67, 0x02, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa]3.5.2 进入编程会话
tester向ECU发送
canid:0x710
data:[0x02, 0x10, 0x02, 0x55, 0x55, 0x55, 0x55, 0x55]ECU回复tester
canid:0x718
data: [0x06, 0x50, 0x02, 0x00, 0x32, 0x01, 0xf4, 0xaa]推荐阅读资料：
3.6 请求下载flash文件
tester向ECU发送请求下载第1帧
canid:0x710
data:[0x10, 0x0b, 0x34, 0x00, 0x44, 0xfe, 0xf2, 0x70]ECU回复tester 流控帧
canid:0x718
data:[0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]tester向ECU发送请求下载第2帧
canid:0x710
data:[0x21, 0x00, 0x00, 0x00, 0x01, 0x00, 0x55, 0x55]ECU回复tester正面响应
canid:0x718
data:[0x04, 0x74, 0x20, 0x0f, 0xf2, 0xaa, 0xaa, 0xaa]报文内容解读：
Tester向ECU请求下载报文长度超过一个标准帧，所以被拆成第1帧和第2帧，以多帧的形式发送。
0x10, 0x0b,：1表示多帧的首帧,00b表示报文正文长度。
0x34, 0x00, 0x44： 表示34下载服务
0xfe, 0xf2, 0x70, 0x00, 0x00, 0x00, 0x01, 0x00：
表示 startAddress(0xfef27000)+blockSize(00001000)
0x21：表示多帧的第二帧
ECU在接收到多帧的首帧后，会向Tester主动发一条流控帧
流控帧0x3后面的含义：第一位0x00,流控状态，这里假设其值为0,表示续帧可持续发送 第二位0x00，表示只发一帧流控帧，服务端将一直发续帧直到全部数据发送完毕，第三位表示续帧发送的最小时间间隔多长（0x00，0ms）
Tester在收到流控帧后才发多帧的第2帧。
0x20, 0x0f, 0xf2：
这里 0x20(length of format identifier) 0x0ff2(maxnumber of block length)
推荐阅读资料：
UDS（十）应用层 34/36/37_车小猿的博客-CSDN博客_34服务
3.7 传输flash文件
tester向ECU发送请求文件传输
canid:0x710
data:[ 0x13,0xD4,0x36,0x01,0x1E,0xEF,0x20,0xA0]ECU回复tester流控帧
canid:0x718
data:[0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]tester向ECU继续发送续帧
canid:0x710
data:[ 0x21,0x14,0x00,0xE0,0x00,0x66,0x00,0xE0]当续帧全部发送完成后，ECU给tester发送回复
canid:0x718
data:[0x02, 0x76, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00]若tester发现flash已经全部发送成功，则向ECU发送请求退出传输：
canid:0x710
data:[0x01, 0x37, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55]ECU回复tester请求退出传输的正面响应
canid:0x718
data:[0x01, 0x77, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa]本节发送的报文结构比较复杂，且报文组包和上一节的ECU回复有强关联，具体组包原则可以查看
根据hex文件制作UDS统一诊断服务CAN多帧报文-python_晓翔仔的博客-CSDN博客_uds多帧发送
3.8 flash文件 CRC32验证
tester向ECU发送请求CRC32验证，报文包含了CRC32正确值（0x63F4DF27）
canid:0x710
data:[0x10, 0x08, 0x31, 0x01, 0x02, 0x02, 0x63, 0xF4]ECU回复tester流控帧
canid:0x718
data:[0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]tester向ECU继续发送续帧
canid:0x710
data:[0x21, 0xDF, 0x27, 0x55, 0x55, 0x55, 0x55, 0x55]ECU验证CRC32是正确的，向tester发送CRC32验证通过的正面响应
canid:0x718
data:[0x05, 0x71, 0x02, 0x02, 0x02, 0xaa, 0xaa, 0xaa]关于CRC32的计算可以查看
用python计算Intel Hex文件数据的checksum“CRC32”的值_晓翔仔的博客-CSDN博客
3.9 擦除待刷写的空间
tester向ECU发送请求擦除即将要刷写的空间地址范围，报文包含了请求擦除的起始地址和地址长度（0x00c10000+0x00038000）
canid:0x710
data:[0x10, 0x0d, 0x31, 0x01, 0xff, 0x00, 0x44, 0x00]ECU回复tester流控帧
canid:0x718
data:[0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]tester向ECU继续发送续帧
canid:0x710
data:[0x21, 0xc1, 0x00, 0x00, 0x00, 0x03, 0x80, 0x00]ECU擦除成功，向tester发送擦除结果的正面响应
canid:0x718
data:[0x05, 0x71, 0x01, 0xff, 0x00, 0x00, 0x00, 0x00]3.10 请求下载app文件
同3.6节
3.11传输app文件
同3.7节
3.12 app文件的CRC32验证
同3.8节
3.13 检查硬软件版本号
tester向ECU发送请求获取版本号
canid:0x710
data:[0x03, 0x22, 0xF1, 0x8C, 0x55, 0x55, 0x55, 0x55]ECU获取版本号并回复报文1
canid:0x718
data:[0x0c, 0x62, 0xF1, 0x8C, 0x31 0x32, 0x33, 0x34]tester向ECU发送请求流控帧
canid:0x710
data:[0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]继续发送版本号的报文2
canid:0x718
data:[0x21, 0x35, 0x36, 0x37, 0x38 0x39, 0xaa, 0xaa]例子里报文携带的版本号是“123456789”。
推荐阅读资料：
UDS服务基础篇之22_汽车小T的博客-CSDN博客_22服务 uds
3.14 ECU 重启
tester向ECU发送请求重启
canid:0x710
data:[0x02, 0x11, 0x01, 0x55, 0x55, 0x55, 0x55, 0x55]ECU重启并回复
canid:0x718
data:[0x02, 0x51, 0x01, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa]推荐阅读资料：
3.15 开放ECU间数据传输和开启DTC错误诊断功能
3.4.1 DTC ON
tester向ECU发送广播
canid:0x7DF
data: [0x02, 0x85, 0x01, 0x55, 0x55, 0x55, 0x55, 0x55]3.4.2 open transfer
tester向ECU发送广播
canid:0x7DF
data: [0x03, 0x28, 0x03, 0x01, 0x55, 0x55, 0x55, 0x55]推荐阅读资料：
UDS（七）应用层 28/85_车小猿的博客-CSDN博客_uds85服务
至此，OTA升级的UDS报文过程交换全部结束。
3.16 其他
若ECU处理消息比较慢，有时会主动发送一个消息挂起的回复
canid:0x718
data:[0x03, 0x7f, serviceid, 0x78, 0xaa, 0xaa, 0xaa, 0xaa]ECU返回NRC 0X78，说明ECU当前处理能量不足，所以需要更长的反应时间。这是tester需要再等一等，不要轻易判定ECU已经拒绝回复了。
在进入特殊会话模式后，一般5秒内没有数据传输，就会退回默认会话。
tester往往会每隔2-4秒发一个握手报文，来维持会话。
如果握手报文格式如：
canid:0x710
data:[0x02, 0x3E, 0X80, 0x55, 0x55, 0x55, 0x55, 0x55]
则无肯定响应报文回复
如果握手报文格式如：
canid:0x710
data:[0x02, 0x3E, 0X00, 0x55, 0x55, 0x55, 0x55, 0x55]则有肯定响应报文回复
canid:0x718
data:[0x02, 0x7E, 0X00, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa]推荐阅读资料：
4.总结
本文主要分析了一次OTA升级步骤里用到的UDS服务以及报文解释。
UDS服务的种类不是特别多，响应的格式也有规范的说法。
可以查阅了解所有类型UDS服务。