新能源汽车OTA升级中的UDS通信分析

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]