车载 OTA技术概念

news2024/11/25 7:36:32

1 OTA技术概念

随着高级辅助驾驶的发展和自动驾驶的引入，汽车变得越来越智能，这些智能汽车被软件控制，装有巨量的软件程序，当出现一个软件程序问题或者更新时，如果按照传统的解决方式，那都将是一项很繁重的任务。以某车上市后出现的刹车逻辑问题为例，按照传统的解决方案，那么所有该车辆先将被召回，然后派人更新软件。这样，一方面影响用户体验和满意度，另一方面又要耗费大量的人力物力来修复问题。

为了解决传统方式的痛点，使得软件更新更迅速，一种远程升级软件的技术OTA被引入到汽车行业。汽车远程升级技术OTA(Over-the-Air)是指通过移动通信网络（2G/3G/4G或Wifi）对汽车的零部件终端上固件、数据及应用进行远程管理的技术。简单来说OTA技术实现分三步：首先将更新软件上传到OTA中心，然后OTA中心无线传输更新软件到车辆端，最后车辆端自动更新软件。

也就是上述刹车逻辑问题的解决方式就变成了更新软件无线传输到车辆并自动完成更新，完美地解决传统方式的痛点，显然我们可以看出OTA技术的优势：

能有效提升用户体验与满意度
能大范围大批量升级系统并提供升级成功率
能快速修复车辆故障
能有效降低售后维护成本

而且随着汽车行业已进入软件定义汽车的时代，对售后汽车售卖各种各样功能的新商业模式兴起，也要求汽车必须具备OTA功能。这里准确地说，OTA分为两类，一类是固件在线升级FOTA（Firmware-Over-the-Air），是指不改变车辆原有配件的前提下，通过写入新的固件程序，使拥有联网功能的设备进行升级，包括车辆的发动机，电机，变速箱，底盘等控制系统，比如特斯拉曾通过FOTA新增过自动驾驶功能、增加过电池容量和改善过刹车距离等。另一类是软件在线升级SOTA（Software-Over-the-Air），是在操作系统的基础上对应用程序进行升级，是指那些离用户更近的应用程序，UI界面和车载地图、人机交互界面等功能，像娱乐系统更新操作界面或主题。

2 OTA技术架构

当前智能网联汽车的OTA架构由OTA云端，OTA终端和OTA升级三部分组成，如下所示。

这里，OTA云端为OEM专属的云端服务器平台，OTA终端采用TBox，网络架构采用功能域划分方式。考虑到本文对OTA技术介绍的完整性，但重点不在说明OTA技术架构，而是旨在说明车内嵌入式设备ECU等的升级方案，故引用《智能网联汽车的OTA升级方案》供相关朋友再做进一步研究。

针对ECU升级的过程描述：FOTA 系统主要通过车载移动互联网进行数据上报及下行传输，通过车内网对车内设备单元进行数据刷写。典型的 FOTA 系统网络安全主要由 OTA 远程管理平台端、 TBox 端（4G LTE）、中央网关、域控制器端及数个 ECU 等节点组成。

FOTA 系统网络安全性需要确保升级包在远程服务器端的安全存储、后台服务器到车端的安全加密通讯、中央网关的升级包解密、防火墙和 OTA 管理，以及车内网络基于对称加密的安全通讯和安全 Bootloader 等要素。

3 ECU的OTA技术实现方案

本部分主要介绍车内嵌入式设备ECU的OTA技术实现方案，也就是整车控制器，发动机控制器，变速箱控制器和电池管理控制器等实现OTA升级，可以采用怎样的实现方案。从上文可知，在车辆端，OTA实现是从TBox 端（4G LTE）经网关，通过总线通讯（CAN或以太网）将软件刷写到车内嵌入式设备ECU（目标ECU）。那么具体刷写到目标ECU还是其他存储设备？以及又将如何启动新软件运行？下面将详细介绍，不过为了更好地理解ECU的OTA实现方案，先解释下分区刷写和地址映射的概念：

3.1 分区刷写与地址映射的概念

关于软件刷写，经常会看到需求“要求支持Bootloader，BSW，ASW和标定等独立刷写”，这是怎么个概念呢？下面进行详细解释：对于汽车ECU软件研发来说，所谓软件要么是模型，要么是C/C++代码，但最终都会变成一个二进制文件，比如HEX, S19, Bin等格式。这个文件将会被刷写到ECU的非易失性存储单元（内存）。

3.2 几种OTA实现方案

在介绍了分区刷写和地址映射的概念后，下面来了解ECU的OTA实现方案。总的来说，OTA实现方案分为两种，一种与通常的刷写方式一样，即先擦除当前版本软件，再刷写新版本软件，但这种方法有个隐患，就是新软件有问题时，由于旧软件已经被擦除，没有备份，恢复会很麻烦，因此就提出了另一种，即A/B交换。

A/B交换就是内存中会分两块区域，一块存放当前版本软件，另一块存放旧版本软件。当OTA升级新版本软件时，新版本软件将代替旧版本软件，这时，一块放的是当前版本软件，另一块放的是新版本软件。再激活运行新版本软件，此时原先的当前版本就变为旧版本软件，作为备份，以防运行的新版本软件有问题，可以及时回滚恢复。

正常情况：最常见的情形，例如设备下线时，A分区和B分区都可以成功启动并正确运行，所以两个分区都设置为bootable和successful，但由于是从B分区启动，所以只有B分区设置为active。
升级中：系统正在从B分区运行，因此，B分区是可启动(bootable)且被标记为成功(successful)的活动分区。由于正在更新A分区，因此A分区被标记为不可启动(unbootable)。在此状态下，重启仍从slot B运行。
升级完成，正在等待重新启动：系统正在从B分区运行，B分区可启动(bootable)且被标记为成功(successful)，A分区升级完成后，重启后需要从A分区启动被标记为active和bootable，但尚未验证成功，所以不能被标记为successful，bootloader应尝试从A分区启动。
系统重启：设备重启后，bootloader检测到A分区为active，完成校验之后，A分区如能正确运行，应将slot A 标记为成功(successful)。对比第1个普通场景，A和B分区都设置为bootable和successful，但active从B分区切换到A分区。至此，B分区成功更新并切换到A分区，设备重新进入正常场景。