汽车电子 ECU OTA 升级和瑞萨 Automotive MCU 方案介绍

本文主要介绍在特定 OTA 需求下的 Automotive MCU 选型过程中，针对技术人员遇到的常见问题进行总结、分析与思考，并结合 OTA 技术分类与实现原理，梳理瑞萨对应 Automotive MCU 方案的特点，以帮助工程师或相关技术人员更好地评估和选择适合的芯片方案。相关分析与思考仅为抛砖引玉，希望能帮助工程技术人员理解并发挥瑞萨 Automotive MCU 在实现 OTA 功能方面的特性。

随着汽车电子产品越来越智能化和网联化，ECU 的 OTA 功能逐渐被各大主机厂和 Tier-1 厂家重视，以特斯拉为代表的新能源汽车是此技术的主要拥趸，并由此在燃油车推广开来。由于目前车用 OTA 主要是针对娱乐系统，车身控制系统 ECU/ZCU 进行升级。相对而言，因为涉及到安全风险，底盘/三电系统推进 OTA 升级功能比较保守谨慎。因此在此文中提及的瑞萨 Automotive MCU 主要指 RL78 F1x/F2x 系列，以及 RH850 F 系列和 U 系列 16bit/32bit 单芯片微控制器，这两个系列是在车身控制器、娱乐系统 ECU、域控领域比较常见的方案。

本文以能检索到各类技术标准对 OTA 不同定义展开，尝试以通俗易懂的技术语言对不同术语表述下的 OTA 进行分类，对每种 OTA 的原理和优劣势进行对比，分析各种 OTA 实现需要的 MCU 低层支持，并汇总瑞萨 Automotive MCU 在支持 OTA 方面所具有的特性。

OTA：全称 Over the Air Technology (空中下载技术)

FOTA：全称 Firmware OTA (通过 OTA 升级 Firmware)

SOTA：全称 Software OTA (通过 OTA 升级 Software)

Full OTA：可以理解为全系统 OTA

ECU：全称 Electronic Controller Unit (汽车电子控制单元)

ZCU：全称 Zone Controller Unit (汽车区域控制单元，可以理解为在新的 EE 架构下，相对于 ECU 集成度更高的控制单元)

目前能检索到的权威 OTA 技术定义来自 ISO 24089:2023 -《道路车辆软件升级工程》、UN Regulation No. R156 -《软件更新与网络安全》和 AUTOSAR Spec 中 SWS 部分关于 OTA 实现的要求。

以下来自 ISO 24089:2023

3.1.12 Firmware Over-The-Air (FOTA):
"Process of remotely updating executable code stored in non-volatile memory of electronic control units (ECUs)."

3.1.15 Software Over-The-Air (SOTA):
"Process of remotely updating application software or data files without modifying firmware."

3.1.18 Full Vehicle Over-The-Air (Full OTA):
"End-to-end process that enables updates to all software and firmware components in a vehicle, including safety-related and non-safety-related ECUs, via wireless networks."

以下来自 UN Regulation No. R156：

Annex 5, Section 2.4:
"FOTA updates shall ensure no safety degradation during and after the update process, with validation via cryptographic authentication."

同样通过能检索到的渠道，先援引汽车行业标准对不同 OTA 技术要求的描述。

以下来自 CP AUTOSAR R19-11：

• 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

• 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.

以下来自 UN Regulation No. R156：

Annex 7, Section 3.2:
"For Full OTA implementations, manufacturers shall demonstrate:
(a) Integrity protection across all ECUs;
(b) No safety degradation during cross-ECU updates."

以下来自 ISO 24089 Annex B：

"Full OTA requires:

• Cryptographic binding between ECUs (e.g., HSM-based chain-of-trust);
• Evidence of no interference between concurrent updates."

通过以上定义和要求，不难发现 OTA 分为两类：一类是固件在线升级 FOTA，是指不改变车辆原有配件的前提下，通过写入新的固件程序来升级 ECU；另一类是软件在线升级 SOTA，是指升级那些离用户更近的应用程序，包括 OS 或UI界面和车载地图、人机交互界面等应用功能。而 Full OTA 则是面向端到端的整机升级，特指安全风险更高，要求更严苛的系统更新。

笔者在查阅和研究相关资料后，在此进行简要汇总，希望能帮助各位技术人员避开晦涩的官方术语，以更直观清晰的方式进行对比。如下图所示对比表中提到的安全等级并非汽车标准文件的强制要求，具体可根据产品实际应用场景灵活选择。

从标准中得到的 OTA 概念和定义非常抽象，对于工程技术人员来说，最重要的在于如何实现 OTA 升级。如果抛开汽车各类规范文件对 OTA 模糊的要求来看，简单地说，OTA 升级最终都会归结到如何写入/擦除 FLASH 的问题上。更确切地说，需要仔细研究的是：如何安全地写入/擦除 FLASH？

对于 FLASH 的一般结构原理，大家可能并不陌生。MCU 中的 FLASH 基本上都是 NOR FLASH，其写入和擦除操作都是以“Block”为单位组织的，这个“Block”是 FLASH 物理组织上的概念。

除了物理层面的“Block”结构，我们还需要理解软件设计中为支持不同 OTA 功能 (如 FOTA、SOTA、Full OTA) 而引入的“分区”，此分区为虚拟组织上的概念。简单来说，系统设计人员会把若干个 Block 划分成一个分区来存放不同功能程序，如下图 (图6) 即是一个常见的 MCU FLASH 分区设计：

从图中我们可以看出，Bootloader 分区对应于 FOTA 中的 F，即 Firmware；App code 分区对应于 SOTA 中 S，即software；整个 FLASH  (Booloader+Flag area+App Code+Template area) 对应于 Full OTA 中的 Full。

当然，根据系统设计人员对于 FOTA、SOTA 和 Full OTA 的理解，以及他们自己软件功能的划分，上述 FLASH 分区可能更细致或者不一样，总之这都是可以调整的软件上的虚拟概念。例如下图 (图7) 所示，工程人员可以将 App1 code 定义为 Firmware，App2 code 定义为 Software，这一切取决于系统功能设计。

理解上述分区概念后，接下来我们再来看 OTA 升级的实现方法，即如何实现 FLASH 擦写。FLASH 擦写本身存在一定风险，如果擦写过程中掉电重启或者出现其他错误，则 Code FLASH 中的数据并不完整，严重时会导致系统无法启动，产品变砖，这也正是我们需要在软件层面进行分区的根本原因。

以图 5 所示的分区方案为例，系统包含一个 Bootloader 分区和一个应用程序分区。在对应用程序分区进行擦写时，必须确保 Bootloader 分区的内容不受影响。这样即使擦写失败，系统也至少能启动到 Bootloader 阶段，为后续系统恢复操作提供可能。因此，对于最低安全保障的 OTA 升级来说，FLASH 至少划分两个软件分区是必不可少的。

若有进一步要求，比如汽车电子 ECU OTA 升级中经常提到的回滚 (Rollback) 概念，明确提出如果升级失败，要求回滚到旧的软件。这时不论是 firmware 软件，还是 app 软件，有了新旧之别，势必会又多划分几个分区。以上述图 6 为例，我们可以把 App1 看作是老的 app 软件分区，app2 视为新的 app 软件分区。如果在擦写 app2 分区时失败，系统默认回滚从 app1 分区进入应用程序，如果擦写 app2 分区成功，系统会跳到新的 app2 分区地址进入应用程序。

上述 OTA 实现逻辑对软件设计带来了一些基础性挑战。不难理解，每个功能软件都有独立的 main 入口，多个软件功能分区意味着我们必须编译出多个对应的软件镜像，即管理多个软件工程和 bin 文件。更重要的是，每个功能软件必然会被要求处理中断，最典型的应用就是接受升级文件 (不论是 CAN 升级、UART 升级或是 Ethernet 升级) 和重启；而软件镜像存放不同的 FLASH 地址空间，它们的中断向量表也必须放置在 FLASH 不同的起始地址。

通过上述图示，我们可以看到 MCU 在处理多个软件镜像时的一般流程，涉及多个 main() 入口、多个中断向量表以及在不同 FLASH 地址间的跳转，这对 MCU 和 CPU 单元提出了一个基本要求：至少能存放处理多个中断向量表偏移地址。

根据前面两节的介绍，结合 OTA 功能特性和安全要求，部分设计人员会将接收 OTA 升级文件这一功能专门放在 Bootloader 或某一个特定分区镜像中处理，这种设计意味着，当程序在正常运行时，必须重启到 Bootloader 分区或者跳转到特定分区中，以处理升级文件传送和 FLASH 擦写的动作。下图 (图9) 展示了对应的软件流程：

是否有可能在 App 程序运行的同时，对 App 分区镜像进行升级呢？答案是肯定的。比如我们在 App 程序里同时实现接收升级文件和 FLASH 擦写动作，并把 App 程序拷贝到 RAM 空间去执行。这种设计对 MCU 性能、RAM 大小、应用程序设计提出了较高要求。或者为了安全起见，设计新旧两个 App 分区，在两个 App 程序里分别处理对方镜像的升级动作，如下图 (图10) 所示。但这种设计同样需要较大的 FLASH 和 RAM 空间，以及较高的 MCU 性能，因为除了 App 自身完善的系统任务功能外，用于接受升级文件的设备驱动 (UART/CAN/Ethernet)、FLASH 读写库和中断中断处理都是必不可少的。

在汽车电子行业的 OTA 功能实际落地过程中，往往会遇到一些特殊要求，例如：要求不得重启、不得影响当前运行的程序等。我们常听到的诸如“不停机 OTA”、“无等待 OTA”、“静默无感 OTA”等术语，均可归入此类需求。总结一下，这些实现方式可分为两大类：非后台升级、后台升级。下面将对这两种方式进行对比和分析：

如下图 (图11) 所示，在升级的时候，系统需要先从应用程序重启到 BootLoad 程序，由 BootLoader 进行新固件下载工作，下载完成后 BootLoader 继续完成新固件覆盖老固件的操作，至此升级结束。

如下图 (图12) 所示，App 应用程序中必须支持接受下载文件、并行擦写 FLASH 的功能，即新固件下载和 FLASH 擦写属于应用程序功能的一部分，有的更高要求不影响当前运行 App。

针对上述分类，综合前面章节对软件设计实现逻辑的分析，笔者将不同升级模式和 OTA 特殊要求对 MCU 的资源要求和系统设计挑战汇总如下表 (表1) 所示：

通过上述对比可以看出，为实现具有特殊要求的 OTA 功能，系统设计人员面临着巨大的挑战，需要在软硬件资源、成本、开发难度和性能等多个纬度进行评估与权衡，从而决定最终开发路线。

简单来说，如果软件架构设计的足够好且实施能力强，那么即使利用较少资源也能在一定程度上实现所谓特殊要求的 OTA；如果硬件资源多，并有特定功能支持，则实现特殊要求的 OTA 功能会相对容易。

但是要用软件方式实现无感/静默要求的 OTA 升级，根据上面章节分析，有一项 MCU 的硬件功能是必须的，即 FLASH 分区要支持边读边写功能。因为 App A 分区在运行/读 FLASH 时，必须能擦写 App B 分区，如下图 (图13) 所示。该功能一般称做 RWW (Read while write)，在某些型号 (如瑞萨 RH850 F1Kx 系列) 中也被称为 BGO (Back Ground Operation)。

此外，正如前文章节及表 1 中所提到的，系统设计人员必须编译两套代码、维护两个软件镜像在 FLASH 不同地址间的跳转、以及两个中断向量表的地址放置和处理。尽管通过软件方式可以实现这些机制，但仍存在相当的复杂性和挑战。但好在最新的 MCU 产品能支持 Bank 分区和 Bank Swap/Hardware Remapping 技术，如下图 (图14) 所示：

Bank 分区是指在 FLASH 硬件上把多个 Block 组成一个 Bank，用户无需考虑软件 App 分区；Bank Swap/Hardware Remapping 由硬件控制不同 Bank 分区的跳转和切换，从软件角度看，用户操作的都是同一个入口地址或中断向量处理地址。该功能并非实现无感或静默 OTA 所必需的，但它能够降低用户软件设计的复杂度，同时具备天然防止产品变砖的能力，可提升回滚速度并增强系统安全性。

通过上面章节的介绍和分析，我们不难得出结论，在 MCU 上现实 OTA 需要哪些支持？完全由用户怎么定义和设计 OTA 功能而决定。有些特殊要求，比如无感/静默/ No-wait OTA，必须有 MCU FLASH 关键特性支持；有些常规 OTA 升级，基本上无需 MCU 有什么特殊硬件特性，基本上只要 FLASH 空间足够大即可；还有些 OTA 功能，比如 Full OTA、回滚要求、不影响当前运行程序等，这些模糊的定义需要综合评估软硬件特性、成本、开发难度，由用户自己平衡取舍。我们可以利用较高的CPU性能、较大的 FLASH 容量、平滑的 OS 调度，和优秀的软件设计，做到无需 FLASH 硬件支持也能支持无感 OTA 升级；我们也可以利用新一代的 MCU FLASH 硬件特性，简化软件设计来支持高级的 OTA 功能。最终怎么选，不一而论。

以下将列举瑞萨 Automotive MCU 在硬件方面支持 OTA 的相关特性，供用户根据实际需求进行评估与选择。

表2 瑞萨 MCU 家族在支持 OTA 功能中需要评估的特性对比

本文主要介绍了汽车电子 ECU OTA 升级的基本概念、技术分类与实现原理，并结合实际开发中遇到的问题，系统分析了不同 OTA 模式对 MCU 资源的硬件与软件要求。在此基础上，进一步梳理了瑞萨 Automotive MCU (包括 RL78、RH850 系列) 在支持 FOTA、SOTA 及无感升级等方面的关键硬件特性，以帮助工程师或相关技术人员更好地评估和选择适合的芯片方案。

欲了解关于更多瑞萨相关方案或技术信息，请与骏龙科技当地的办事处联系或点击下方「联系我们」，提交您的需求，骏龙科技公司愿意为您提供更详细的技术解答。