整车OTA部署（一）分布式架构下的整车OTA部署方案

开垦者

一、分布式架构下的整车OTA部署方案

随着软件定义汽车进程的深入，采用OTA技术进行车载软件升级是众多车企维持售出车辆常用常新的重要手段，在此技术的应用过程中，根据车辆EEA的集成化程度以及所搭载的控制节点智能化程度的不同，在进行整车OTA网络部署时，对于传统ECU/域控以及具有智能化应用的如座舱域、智驾域等产品有着不同的升级方案。


图1 整车OTA部署关键
我们知道在传统的分布式电子电气架构下，通常可与‘云端’形成联网的车载节点多为远程信息处理控制单元（即T-BOX）或车载信息娱乐系统（即IVI），而在OTA技术的应用中，车联网技术的应用是车辆从云端下载软件升级包的关键，由此便形成了以T-BOX或IVI为OTA过程主要控制节点的方案，其架构示意如下：


图2 基于分布式EEA的OTA部署
在采用此方案进行OTA部署的整车上，当有软件升级需求时，由T-BOX/IVI通过接收来自‘云端’的数据并基于UDS等协议为下级节点完成软件的更新工作。在此方案下，处于架构中的网关仅实现对数据的转发功能。但由于分布式EEA的原因，通常控制节点较为分散且又有较深的层级（即节点之下还挂有节点），在此长链路架构的作用下，会导致在OTA过程中需对数据进行多次转发与透传，而这一动作便会增加数据丢失的风险，进而提高了OTA升级失败的概率。

为缓解此类问题发生的风险，通过由T-BOX/IVI先将软件升级包进行下载后再分发至网关，并由网关承担对下级ECU的软件更新工作的方案被提出。此方案以T-BOX/IVI为软件升级包的存储区，以GW为OTA过程的主要控制节点，这相对于以T-BOX等为主要控制节点的方案而言，缩短了数据链路，可让OTA过程更加稳定可靠，其部署示意如下图所示。不过，由于升级包的下载与存储需求的增加，对于相关控制单元的内存则提出了更高的要求。


图3 以GW为主控的OTA方案
二、传统控制节点的OTA方式

在上述两类方案中，由于整车EEA的缘故，决定了其所应用的相关控制节点的算力、性能水平并不会太高。通常情况下，此类控制节点大多是基于存储空间较为有限的MCU（微控制单元）平台进行开发的传统控制单元，在对此类产品进行升级时，鉴于其存储空间的限制，通常是先将需刷写空间的数据进行擦除以释放其存储空间，接着再将接收到的数据写入，通过这一个来回，便完成了程序的升级，此过程也被称为流式刷写。

常见的以BootLoader（启动引导程序）为引导，并通过UDS协议完成软件刷写的过程便是典型的流式刷写方式。当然，程序的下载与更新并非这几句话便能讲明，其过程还涉及安全校验、信息校验、诊断等内容，如诊断会话传输可如下图示意，其他流程也有具体的标准要求，这里暂不做深入。


图4 诊断会话传输
在传统分布式电子电气架构的整车环境中，根据车载应用的环境及要求的不同，对ECU中的主控芯片的选择也存在差异，通常在MCU的选型上，根据其内存空间结构的不同，可分为单分区和双分区两类。

2.1.单分区方案

单分区结构的产品是在片内存储中仅有一个BootLoader和一个APP（应用程序）分区，当需对软件进行更新时，按照相关软件更新流程，在ECU收到更新请求后，便会从当前所运行的应用程序切换至BootLoader模式，接着会将当前应用程序分区中的数据进行擦除，然后再将从主控节点所接收到的新版本数据写入应用程序分区中，待刷写完成且数据检验无误后，可通过重启ECU将运行软件再切换至应用分区。完成整个流程后便可让ECU运行新版本软件，从而实现软件的更新过程。基于此应用的更新过程简单、对MCU内存要求低等特性，在传统控制节点的软件更新中，依然被作为主流应用模式。其过程流程示意如下所示：


图5 单分区ECU升级示意
如上描述所示，采用此方案进行ECU软件升级时，由于APP分区只有一个，且在升级时需对其APP数据进行擦除，这一动作便使得ECU在OTA升级的过程中无法正常工作，而升级过程中若出现异常，只有不完整数据的ECU将彻底失去功能作用，进而导致系统故障。为此需有相关技术手段以确保升级失效时的软件回滚，同时，由于升级过程存在让ECU失能的情况，因此通常采用此方案进行产品升级时要求车辆处于非运行状态。

2.2.双分区方案

为了防止单分区下由于软件升级导致的ECU变砖，在搭载了具有更高性能MCU的产品上，常通过AB双分区方案为当前运行版本和升级版本分配不同的存储区，在有软件更新需求时，ECU可正常工作于A区，并通过对B区进行更新以完成软件的升级。在B区更新完成且校验成功后，可在下次重启ECU时，载入B区的软件，进而实现新版本软件的功能应用。若B区升级出现异常，则在下次重启ECU时仍运行A区软件。通过此AB面的方式可提升软件升级过程中系统抵抗异常风险的能力。

在应用AB面方案对传统控制单元进行软件升级时，其执行方式共有三种：

1）以MCU自身硬件为辅助，基于MCU具有足够存储空间的前提下，当软件更新完成后，通过更新地址映射地址来激活新版本软件，此方案下新版本软件运行的入出地址不会发生变化，其过程示意如下：


图6 基于硬件辅助的AB面方案
2）与方案一过程类似，但由于此时所搭载的MCU硬件不支持地址映射，因此激活新版软件的入出地址会发生变化，其流程示意如下：


图7 地址变化的AB面方案
3）此方案下所搭载的MCU内存空间较之上述两类要小，常为单分区类型。在进行硬件设计时，通过外扩存储空间的方式额外增加软件的备份空间，以此来实现AB面双分区方式。在进行软件更新时，通过在外扩的存储区间中将新版软件写入，待其写入成功且校验完成后，通过擦除MCU中的当前软件版本再将已在外扩存储中更新完成的软件版本写入此区域，从而实现系统软件的更新动作，其流程示意如下所示：


图8 基于外扩内存的AB面方案