鉴于篇幅原因，上篇没有多描述ECU刷写过程中所执行的那些动作。这里通过实例以及UDS建议刷写序列内容，一起解读刷写过程中的内容。
如下图，ISO 14229对于刷写过程所需Action所给出的推荐步骤。
1、若ECU当前处于Application中，想要完成对ECU的刷写，需进入到对应的Boot模式下。在诊断范畴，通过会话模式（1002 Programming Session）切换进入Boot模式。在Bootloader代码作用下完成对ECU的刷写动作；
2、出于对ECU的保护，需要安全认证后才有刷写ECU的权力。在UDS协议中推荐使用Service27（SecurityAccess Service），解锁成功后允许对ECU进行下一步的刷写行为；
3、Fingerprint在UDS中的定义是：车辆制造商特定于在任何数据（例如应用程序软件）下载到ECU之前，将“指纹”写入服务器内存中。“指纹”标识谁修改了服务器内存。如下图定义DID0xF198为Fingerprint，里面包含3个信息：
1) Serial number of flash tool：刷写上位机工具序列号；
2) Repair Shop Identification：维修店识别号；
3) Programming Date：更新软件的时间（年月日）
通过2E服务将Fingerprint写入到ECU内存中。
4、在ECU软件刷写时，若内存中没有存储擦除驱动，需要下载擦除驱动。通过特定的下载序列进行下载：
RequestDownload (…)：请求下载，UDS协议中定义格式如下：
Service 34请求以及响应格式如上所表述。下图以实际例子来说明Service34的帧格式：
根据上面介绍：
0x00可知该块数据没有采用加密和压缩方法；
0x44表示数据存放的地址和数据长度都是用4Bytes表示；
0x00000030数据存放的起始地址；
0x0484该块数据的大小；
TransferData：UDS协议中定义该服务请求和响应格式如下：
RequestTransferExit：请求退出传输
5、RoutineControl用于检查下载是否完整，关于RoutineControl，UDS协议中格式定义如下：
其中对应SubFunction定义如下：
其中通过RoutineDID定义一系列检测动作（也可称例程）验证数据下载结果。而对于SubFunction（01/02/03）分别表示对于检测例程的开始执行、停止执行和请求执行结果。
例如定义DID1314 Check ProgrammingIntegrity ：通过数学方法计算data内容中CRC值，校验刷写前后数据是否一致；
DID 5201 Check Programming Dependencies：校验刷写后的数据，查看版本号是否一致？内容是都一致？
步骤6、7、8跟上述动作一致，个人认为这里UDS协议将Driver区分开（一个负责擦除内存，一个负责在内存上写入数据）。
9、对ECU所需更新的Appdata进行下载（例如：校验和、签名、DTC、硬件/软件兼容性等）；
步骤10、11是验证下载结果。
12、写入ECU培训信息，比如VIN码、软硬件版本号等
以上是个人对于ECU刷写整体流程的认识。
由于现阶段车企对OTA越发重视，所以要求Bootloader功能具有很高的稳健性，能够保证在不同极端条件下都可以对ECU进行刷写。因此Bootloader刷写测试的重要性越来越凸显。如下举常见几种测试策略，方便大家理解：
1) 在刷写过程中突然中断刷写，后再继续刷写，检测ECU Bootloader处理策略；
2) 在刷写过程中突然掉电，后上电继续刷写，检测ECU Bootloader处理策略；
3) 在一定电压阈值内进行刷写，检测ECU处理策略；
4) 刷写过程中，只对ECU内存进行擦除，不写入ECUApp数据内存，看看ECUBootloader处理策略；
……
若您有所收获，是我更新的最大动力！
有关注，不迷路！
现阶段可在私信上面沟通技术疑问，我会及时回复！
-----------------------------------------
作者简介 | 穿拖鞋的汉子
汽车电子工程师
来，每天进步一点点！
联系客服
