基于UDS的ECU诊断刷写流程 助力汽车智能化发展

软件刷写通常是指将软件程序烧录到ECU芯片内存的特定地址段，然后ECU就会运行该软件程序以实现其特有的功能。本篇文章是围绕这一烧录刷写过程展开介绍。

当前，风丘诊断工具链，可实现从诊断数据配置到完整刷写测试的一体化流程支持，全面满足基于 UDS的 ECU 诊断与软件刷写需求。借助 Q-Tester 能够稳定实现与 ECU 控制器的可靠数据交互，高效完成软件烧录与刷写校验等关键步骤。整套方案功能完整、流程覆盖全面，可贯穿车辆诊断与软件刷写的全开发周期，并且可根据车企及供应商的实际需求，灵活定制刷写流程与诊断功能。

整个诊断刷写流程分为三个大步骤，分别是预刷写步骤、刷写中步骤和刷写后步骤。在这三个步骤中，我们将讲解关于UDS诊断刷写流程的详细过程。

1. 预刷写

（图1 会话模式转换图）

这一步的主要工作是做刷写前的准备工作。诊断议Tester先向ECU发出22服务来读取ECU的版本信息。然后，Tester再发出1003，使ECU从默认会话转到拓展会话模式，在拓展会话模式下，Tester将进行一系列刷写前的检查。

（图2 刷写前指令流程图）

首先，Tester会使用31服务来检测一些车辆状态。整车厂通常会定义一些控制器刷写的前置条件,这一步可检查刷写前提条件是否满足,若设定条件未满足，则将退出刷写。其次,如果在刷写过程中没有关闭DTC，则会记录不必要的DTC，因此需在预编程步骤关闭DTC存储——发送85服务指令即可关闭DTC存储功能。之后还需使用28服务关闭与诊断无关的报文，以降低总线负载。这个操作，一是可节约总线上的通信资源，提升刷写效率；二是可排除其他报文对刷写的干扰，防止刷写失败。

2. 刷写中

经过上述的预编程，接下来将进入正式的刷写进程。

| 安全算法验证

（图3 安全算法验证流程图）

Tester先发送10 02服务从拓展会话切换到编程会话。在执行刷写这种较高层的诊断服务之前，需先进行27安全访问服务，完成身份验证。诊断仪向ECU发送27 01请求种子“Seed”，这时ECU回复诊断仪发送Seed。接着诊断仪根据刚刚得到的Seed使用算法进行计算得到安全密钥，并向ECU发送。ECU同样通过算法得到密钥，并将其与从诊断仪发出的密钥进行对比并判断是否通过。若通过，则将进入下一步——使用2E写入刷写时间以及刷写人身份信息。

| 数据传输

（图4 刷写数据流程图）

Tester 首先发送31服务，启动目标 ECU 的内存擦除操作，为后续程序刷写清理空间（根据厂商自己定义是否执行这一擦除操作）。接着，Tester 发送34服务，向 ECU 请求确认刷写地址、传输数据块大小等信息。配置确认完成后，Tester 发送36 服务，开始向 ECU 传输第一块程序数据。ECU 收到后回复76 01，表示当前数据块接收成功。随后 Tester 继续发送36 02 xx xx、36 03 xx xx… 依次传输后续数据块，直到整段程序数据发送完毕。所有数据块传输完成后，Tester 发送37服务请求退出传输，通知 ECU 结束本次数据传输会话。传输结束后，Tester 使用31 服务检查数据传输是否正确。如果本次刷写包含多个数据块，则会重复执行34（请求下载）、36（传输数据）、37（退出传输）、31（例程校验）的流程，依次完成其他数据块的刷写与校验。所有数据块刷写、校验全部完成后，Tester 发送31 01 FF 01服务，确认目标 ECU 的内存编程依赖关系，验证各程序段之间的兼容性与完整性。最后，Tester 发送11 01服务，请求 ECU 重启，至此，第二步骤刷写全部结束。

3. 刷写后

这一步骤是刷写完成后的收尾与状态恢复工作，确保 ECU 回归正常运行。

（图5 刷写后流程图）

首先，诊断仪 Tester 10 03指令切换至拓展会话，随后发送28 服务指令，重新开启刷写前关闭的非诊断报文，恢复整车总线通信；同时发送85 服务指令，重新开启 DTC 存储功能，恢复故障诊断能力。最后，Tester 发送10 01指令，将 ECU 从拓展会话切回默认会话，完成整个刷写流程。

以上就是一般的基于UDS诊断的ECU刷写流程。诊断的刷写流程架构基本一致，但会存在部分差异，视具体情况而定。Q-Tester.Expert是基于ODX（ASAM MCD-2D/ISO 22901-1）国际标准的工程诊断仪，内置Sequence序列可以支持各种刷写流程。通过此诊断仪，用户可实现与ECU控制器之间的数据交互，高效完成软件烧录这一过程，同时Q-Tester.Expert还支持以太网诊断（DoIP），也可根据用户需求进行扩展开发。

| 刷写实例