汽车OTA--Flash RWW属性为什么这么重要

目录

1. OTA与RWW

1.1 FOTA需求解读

1.2 什么是RWW

2.主流OTA方案

2.1 单Bank升级

2.2 基于硬件A\B SWAP的FOTA方案

2.3 基于软件实现的FOTA方案

3.小结

---

1. OTA与RWW

1.1 FOTA需求解读

CP AUTOSAR R19-11首次提出了FOTA的概念，针对FOTA Target ECU提出了多条需求：

• FOTA Target ECU shall be capable to install, i.e. receive and store, a new SW image while the current image on the ECU is executed in its normal operating mode.
•  An ongoing installation shall not disturb or reduce the functional scope of the
  respective FOTA Target ECU.

目的是为了缩短因为软件升级导致的汽车停机时间，文档里甚至要求汽车行驶过程中仍可以进行新程序的升级（但必须在汽车安全状态下进行激活），且在新程序升级时不能影响绝大部分汽车功能；

• FOTA Target ECUs shall be capable to internally recover the SW image, being
  active before last (FOTA) activation. This may happen on a trigger by the FOTA
  Master instance.
• FOTA Target ECU shall accept activation of new software in vehicle safe-state

  only.

为防止升级失败，必须有一个回滚机制能够保证汽车回到之前状态；升级成功后，必须让汽车在安全状态下才能激活新的软件进行运行，根据ECU在整车系统中的不同功能，这个安全状态根据OEM来定义。

可以看到，随着软件定义汽车的风越吹越大，升级整车系统以保持最新功能的需求也不断增加；以往在4S店线下召回升级软件的方式日渐落后，借助各种无线通信技术对整车进行升级的方式变成了当前乃至未来的趋势。

1.2 什么是RWW

在上述需求里，我们发现FOTA以以往线下召回最明显的区别在于无感：即ECU运行代码时仍可以实现对新软件的接收和存储。

所以这就对车控类ECU的主控芯片MCU提出了一个非常关键的需求：CPU在Flash取指运行时，可同时对另一区域的Flash进行擦除和编程以存放新软件。这就是Flash在分区上的RWW(Read While Write)特性；Read分区存放当前运行的软件，Write分区存放新的软件。

该特性是基于存储器哈佛结构诞生也发展出来，哈佛结构将系统存储分为程序存储器（Program Memory）和数据存储器（Data Memory），每个存取器有自己独立的总线，如下图：

这样我们就实现了CPU从Program Memory中读取指令的同时，对Data Memory进行读取或写入；但是缺点在于如果Program Memory中代码需要更新，CPU这时候就只能Halt，因为Program Memory Bus正在写入数据代码到Program Memory中，它很忙。

如何优化呢？我们按照总线这个思路，把Program Memory分成多个Bank(Block、Section都行)，并拓展总线，这就能实现在当前Bank运行，同时刷写代码到另外一个Bank。如下图所示：

这个属性天然对OTA非常友好，CPU运行A Bank上的程序，A Bank上的程序提供刷写B Bank的驱动；刷写完成后切换Bank，CPU到B Bank取指运行。

所以，我们可以看到主流车规MCU里基本都支持RWW属性，例如：

•  NXP S32K344支持最高4MB PFlash(Block size = 1MB)，OTA时分为2x2MB，RWW属性在Active block和passive block之间实现；
• 英飞凌TC37x支持最高6MB(2x3) PFlash，OTA是分为2x3，RWW属性在Active Bank与Inactive Bank里实现；
• 意法半导体SPC58NH92，支持最高8个RWW Partitions，OTA可采用RWW P4\6和RWW P5\7互换

2.主流OTA方案

2.1 单Bank升级

这里我们首先回顾以前MCU资源不足，无法考虑A\B升级的方案，如下：

MCU启动后首先运行Bootloader，判断是否有升级请求，如没有则跳转至App运行；假设我们在App里收到升级请求了，立马设置升级请求标志位，并复位系统进入Bootloader；检查到请求Flag后，Bootloader将通信\flash驱动拷贝至RAM或者DFlash，然后开始进行升级流程，如下图：

很明显，这种升级方式不能提供回滚机制、也不能实现零停机升级，是不能满足如今FOTA需求。

在1.2节里，我们明显观察到RWW属性是和OTA强相关的，因此上述MCU也支持硬件OTA机制；这也为我们设计OTA方案提供了便利。

目前主流的OTA方案可以分为基于硬件特性的FOTA方案和软件实现方案。

2.2 基于硬件A\B SWAP的FOTA方案

以英飞凌TC37x为例，它有两个地址映射模式： standard address map和alternate address map，其物理bank和逻辑地址映射关系如下：

而我们在上面提到使用硬件SWAP机制的好处就是只用维护一个工程以及对应链接脚本，因此从逻辑上讲，我们应该就使用standard address map的地址来设计链接文件并编译工程，整体逻辑如下：

从CPU的视角来看，它始终使用逻辑地址0x80000000（举例）来取指，而芯片硬件根据不同地址映射模式来给物理Bank0、1分配逻辑地址，例如0xAA模式下，分配0x80000000给到PFlash1，这样就能保证运行的是更新后的代码。 

2.3 基于软件实现的FOTA方案

即使硬件没有地址映射SWAP的功能，从软件角度也是可以实现上述功能，但前提是Flash的分区要支持RWW；

在软件实现角度里，由于逻辑地址和物理bank是一一对应的，要实现A\B SWAP，就必须维护两个工程，一个工程链接文件锚定Bank A，一个工程链接文件锚定Bank B，有BootManager根据需要选择运行A还是运行B，理论如下：

虽然这个实现了A\B 升级，但是从逻辑上将随着升级次数的增多，对于软件版本的维护和工程的维护是需要审慎进行的。

所以，Flash的RWW对于OTA来说是一个必选项，但是硬件地址映射模式的切换有最好，没有也能做。

3.小结

以上，我们分析了Flash RWW属性，目前汽车车控类MCU的主流OTA方案；对于具备自更新能力的控制器，例如座舱域控制器SOC端、智驾域SOC端、中央网关等等，还没有具体研究过，后面接触了再分享给大家。