席刚刚，解友华，曾晓松，解光耀，张圣洋，单淼刚

（1.201821 上海市 博世华域转向系统有限公司；2.201800 湖北省 武汉市 博世华域转向系统（武汉）有限公司）

0 引言

智能驾驶发展要求EPS 的失效率达到100 fit（109h 内出现1 次故障为1 fit）及以上，为降低单点失效率，EPS 系统设计了双冗余结构[1]（如图1 所示）。2 个系统之间通过IPC（Inter-Processor Communication）进行同步通信，实现驱动扭矩协调分配和关键信息共享。在系统设计中，当2 个系统之间IPC 通信丢失后，系统会切换至物理最大半助力状态，从而避免实际助力输出超出请求的输出水平而导致危险。更为严重的是系统无法在本驾驶循环恢复到正常状态，该设计方案对刷新本身产生了严重影响，尤其是当终端客户在进行OTA 刷新后发现系统无助力，进而产生恐慌。

图1 冗余EPS 系统结构Fig.1 Redundant EPS system structure

一种比较简单的解决方案是主从刷新，通过EPS1 刷新EPS2，此时EPS1 除了实现EPS1 本身的刷新功能外，在对EPS2 进行刷新时作为诊断仪对EPS2 进行数据传输，在EPS2 刷新完毕后对EPS1 本身和EPS2 进行同步重启，从而解决不同步问题。但该方法具有刷新时间长、实现逻辑复杂、刷新工具复杂等缺点。

基于以上刷新背景，对比其他方案的优缺点，再结合以往对单系统刷新的方法及双系统在总线的可见性，本文设计了一种单独刷新的实现方案，能够实现快捷刷新，并保证刷新完成后无系统异常情况，保证EPS 系统正确的助力输出。

1 刷写方案实现

1.1 一般刷新过程简述

如图2 所示，刷新过程一般分为3 个阶段：刷新前准备、刷新过程和刷新后处理[2-5]。

图2 一般刷新过程Fig.2 Generic flashing process

（1）在刷新准备阶段，会检查整车的刷新条件（如对EPS 刷新而言，车速必须小于设定值），之后会通过28 服务关闭普通通信和DTC 检测。除此之外，一般会涉及刷新安全认证。当这些所有步骤均成功完成后，软件会跳转到刷新模式。

（2）刷新过程中，程序运行环境与正常运行模式做对应，主要包含对设定区域的擦除、解析总线数据并做校验。校验通过后，调用相关的Flash 驱动，完成相应区域的数据刷新。数据刷新完毕后，一般还会回读设定刷新区域的数据进行完整性校验，以保证数据被正确刷新成功后才会退出刷新模式。

（3）成功退出刷新模式后，一般会进行相关的后勤数据更新，如刷新时间和刷新诊断相关信息等。

上述刷新过程比较耗时，主要体现在2 个方面：一是擦除对应的flash 和写入新数据本身比较耗时；二是目前越来越多的整车厂都集成了刷新的正当性校验，即保证刷新数据经过整车厂授权且其本身并未被篡改，这其中会涉及相关的数字签名和哈希函数[6]计算或校验，其计算过程本身比较耗时。此外，现阶段的EPS 需要实现的功能较多，需要传输的数据量大，导致数据传输需要一定时间，如果等待给EPS1 传输完数据后再进行EPS2 数据传输会占用大量时间，包括数据传输时间、等待EPS 响应的时间等。

因此，在刷新前准备阶段要求上位机对部分共性的诊断服务进行功能寻址请求，并以较小的时间间隔请求EPS1 和EPS2 分别进入boot 模式。刷新过程中穿插传送EPS1 和EPS2 需要写入的数据，进而减少总的刷新时间。最后在刷新后处理阶段写入后勤数据时同样穿插进行，能够极大缩短任务处理的等待时间。

1.2 同步机制实现

结合上述刷新过程，考虑到在刷新模式下EPS本身并不需要支持其相应的应用功能，在此情况下，如果能确保EPS1 和EPS2 在刷新过程完毕后同步进入到APP 模式（正常工作模式），则可以解决二者不同步导致的系统状态异常。实际中，以UDS 刷新为例，在上位机获知各个ECU 已经刷新完毕后（如获得了ECU 针对37 服务给出的肯定响应），上位机一般会发出10 01 指令通过各ECU退出刷新模式，进而进入APP 模式。需要指出的是，对EPS 而言，EPS1 和EPS2 本身初始化过程并不完全相同，其初始化时间也不可能完全相同，在底层驱动软件中，会对二者的初始化过程有容错处理，即二者允许一定的时间差，这对后续的同步处理机制比较关键。

在不同的软件刷写场景下，特别是在整车产线的刷新场合，为了降低通信异常，在刷新阶段结束后，一般尽量使得各个被刷新的EPS 同步进入正常模式，此时上位机的退出指令一般采用功能寻址的方式，确保所连接总线的各个ECU 均可以收到，进而同步进入到工作模式。以下是几种不同的刷写情况，需要考虑EPS1 和EPS2 的同步情况：

（1）由图1 可知EPS1 和EPS2 均对刷新诊断仪可见，即诊断仪在刷新完毕后的退出指令二者均可以收到，当正常完成刷新后，EPS1 和EPS2 同步进入APP 模式，系统在不需要进行额外操作（如整车休眠）的情况下恢复到正常系统状态和助力状态，此时自然满足客户产线或售后刷新，特别是OTA 的应用场景。

（2）假定EPS1 和EPS2 在第一次刷新过程中有失败而进行重新刷新，此时分2 种情况，一是EPS1 和EPS2 均刷新失败了，二者均需要重新刷新，从同步的角度与第一次刷新情况相同；二是只有EPS1 或EPS2 刷新失败了，重新刷新的过程中，刷新诊断仪一般情况下只会对失败的EPS 进行刷新，刷新完毕后，上位机仍然会发送10 01 指令，理论上EPS1 和EPS2 均可以收到，此时之前刷新成功的EPS 可以主动进行reset，从而与处于Boot模式下EPS 进行同步。

如图3 所示，在软件策略中有一个决定EPS系统是否进入APP模式或Boot模式的软件模块——Boot Manager，一般情况下此部分代码在程序启动后首先执行来判断系统是否应进入APP 模式或Boot 模式。

图3 Boot Manager 基本逻辑Fig.3 Boot Manager basic workflow

如图4 所示，Boot Manager 中对APP 完整性校验和刷新请求检查二者可以不分先后。一般的刷新过程即系统软件在APP 模式下，收到刷新请求并确认后，置位相应的标志位触发程序重启，Boot Manager 再检测到这些标志位后，会进入刷新模式。

图4 部分刷新跳转模式Fig.4 Transition mode of partly flashed

因此，为保证在刷写结束后EPS1 和EPS2 能够实现同步，刷写诊断仪的进入APP 模式指令要求通过功能寻址请求。

2 同步机制优化

可见上述同步过程以上位机的刷新结束命令为起点，处于APP 模式的EPS1 或EPS2 主动重启以达到同步的目的。其中，严格设定处于APP 模式下的EPS1 或EPS2 进行重启前提条件是优化的核心，以减少对其正常功能的影响。图5 所示为EPS 重启功能的设定条件，包含禁用非诊断通信、关闭DTC 记录、相应的安全认证、不同的诊断仪地址等。在满足图5 所有的条件之后调用HWLI_ShutdownTaskContainer 函数，HWLib 软件控制2 个ASIC 芯片进行重启。MCU（Micro-Controller Unit）芯片由ASIC 芯片供电，因此2 个MCU 同样发生复位重启，在初始化完成后由于CAN 收发器在持续接收总线信息，此时收发器通知ASIC 芯片工作并给MCU 芯片供电激活MCU 工作。在完成一系列重启工作后，整个EPS 系统的2 个子系统保持在相同的模式下，此时系统状态正常且能够输出期望的助力。

图5 软件重启条件判定Fig.5 Software reset condition

3 测试验证

在EPS 设计阶段，定义了表1 所示的系统状态。

表1 EPS 系统状态定义Tab.1 Defination of EPS system state

在没有前文同步机制的情况下，利用原始的刷写步骤及EPS 软件测试，对EPS2 进行单独刷写后出现读取故障，如图6（a）所示。图6（a）中EPS 从40 s 左右开始进入Boot 刷新模式，142 s 时跳出Boot 模式，之后完成信息写入。在167 s 时观察EPS 的状态和故障码，ECU1 触发了同步失调故障码并且为当前故障。EPS1 的系统状态变量显示为半助力状态，此时助力降级。用于触发仪表显示故障的标志位也被置位，此时仪表显示 “转向助力减弱” 字样，从而影响整车下线。在售后OTA应用场景下，还可能会造成驾驶员恐慌。

图6 2 种方案刷写结果对比Fig.6 Comparison of the flashing results of two schemes

在集成了同步机制的新软件中，重复原有的刷写步骤，在EPS1 软件不刷的情况下，只对EPS2进行刷写，结束后读取故障如图6（b）所示。软件大概在65 s 时进入Boot 刷新模式，158 s 左右跳出Boot 模式。随后观察ECU 的系统状态和故障码，发现ECU 当前只有历史故障码（历史同步超时），EPS1 和EPS2 均恢复到正常工作模式，触发仪表亮灯标志位也没有置位。可以看出，在不进行额外重新上下电操作的情况下，系统恢复了正常。

4 结语

结合实际项目，本文提出了一种针对双ECU 冗余EPS 系统的单独刷新方案。通过这种方案，最大限度地减少刷新时间，实测达到了客户对刷新时间的要求；同时设计了一种有效的同步机制，保证了冗余系统的同步特性，刷新完毕后系统能自行恢复正常，在售后OTA 应用场景下发挥重要作用。目前应用项目已经进入批产状态，实际测试结果很好地证明该方案的可行性和可靠性。