本文逻辑：先简要介绍OTA技术的概念和架构，然后重点介绍车辆端目标ECU的OTA实现方案，最后探讨OTA相关的需求。

1 OTA技术概念

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

传统的汽车软件更新方式

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

基于OTA的汽车软件更新方式

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

能有效提升用户体验与满意度

能大范围大批量升级系统并提供升级成功率

能快速修复车辆故障

能有效降低售后维护成本

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

嘉名：为什么提起智能汽车必提整车OTA？

下面将以FOTA技术应用来进一步了解：

2 OTA技术架构

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

智能网联汽车OTA系统架构

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

OTA云端

OTA终端介绍

OTA升级对象[3]

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

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

OTA技术实现示意

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的非易失性存储单元（内存）。

像英飞凌TC2xx系列采用的内存是Flash，存储程序叫做PFlash，存储数据叫做DFlash。为了合理有效使用这些内存，同时也方便管理，通常我们会分配这些内存的用途，以下图的PFlash分配为例，分配2MB存启动软件Bootloader，2MB存底层软件BSW和2MB存应用层软件ASW。针对前面需求，不难理解客户的意思，就是需要能只更新其中一个，比如ASW，而其他不变，即Bootloader和BSW不变。当然，OTA本质上就是实现软件远程刷写，当然会有这样的需求，所以在此先介绍第1个概念--分块刷写、分区刷写。

仅做示意，不代表实际应用情况

第2个概念--地址映射，上面进行了内存分配，那么我们写代码时候，怎么保证代码就能放入规定的内存空间，比如说ASW的软件代码怎么能放在规定的内存空间，更准确第地说，ASW代码编译完成后的地址怎么会在0x8040 0000 - 0x805F FFFF范围。需要使用#pragma用法来实现，以一个ASW函数QxyDemo的定义为例，

Qianyixing_sdata的地址范围属于上图规定的ASW内存空间，通过所示#pragma的用法，那么QxyDemo编译后二进制代码的地址将在Qianyixing_sdata内，也就意味着在0x8040 0000 - 0x805F FFFF范围。

通过上述这个过程，其实我们建立ASW C/C++代码与ECU Flash地址的映射，这样就能保证ASW二进制代码刷写到预期的ECU PFlash地址，同理Bootloader和BSW。当软件运行时，就可以通过有序地访问来自PFlash地址的ASW内容，执行ASW预期的操作和运算。

3.2 几种OTA实现方案

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

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

这里，对于A/B交换方案，其实有三种实现方案：

第1种，基于硬件辅助的A/B交换方案。该方案要求ECU内存足够，而且支持地址重映射，也就是当新版本软件刷写完成，通过更新映射地址来激活新版本软件，即新版本软件运行的入出地址不变。

第2种，A/B交换方法与第1类的差别在于ECU硬件不支持地址重映射，激活新版本软件的入出地址变化。

第3种，基于外扩内存的A/B交换方案，该方案是需要额外的外扩内存，备份当前版本软件和旧版本软件，新版本软件会先刷写原先的旧版本软件空间，然后擦除ECU内存的当前版本软件，刷写新版本软件，完成激活。

针对以上三种A/B交换方案，

这三种方案在新版本软件有问题时，都支持旧版本软件回滚；

第1，2方案的激活时间都较短，但第1种方案一般需要高级版本的ECU才支持，比如英飞凌TC39x；第2种方案软件实现较复杂，因为需要处理不同的复位向量和中断地址；

第3种方案则是通用的方案，因为对已有的MCU平台不需要做很大改动，只需要增加额外的外扩内存就能实现。

注：回滚（Rollback）指的是程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为。回滚包括程序回滚和数据回滚等类型。

3.3 新版本软件

上述OTA升级刷写的新版本软件，一般分为两类。一类是通常理解的新软件替换旧软件。

像车辆ECU的大部分软件很小，都采用这类，但像车辆的娱乐信息系统和车载地图等的软件很大，可能采用另一类：差分文件。

引自[6]: 由于车载网络的带宽资源和计算资源等有限，通常不在其上直接传输完整升级文件而是选择通过差分算法传输增量升级文件然后再通过相应还原算法计算出原完整升级文件，以减少传输过程中的时间消耗以及对车载网络本身的使用负载。差分算法是指在云服务器端比较新、旧版本之间的差异并生成差分 delta 文件，然后将该文件传输到车辆客户端，由车辆客户端根据接收到的差分 delta 文件和旧版文件还原成新版文件。因差分 delta文件的大小远小于源文件，所以有利于无线传输，同时节省流量，能够提升整个传输过程的安全可靠性和经济性。

差分文件

以上就是从ECU角度介绍了OTA技术实现方案的大体思路，具体采用何种方案，主要取决整车网络架构和ECU情况，接下来借助AutoSAR OTA相关文档来谈谈OTA都有哪些典型需求。

4 OTA相关需求

为了实现OTA功能，一般会提什么样的需求？下面通过对OTA升级过程和OTA软件实现架构的理解，来逐步分析。

4.1 OTA升级过程

根据AutoSAR相关文档，OTA升级的完整过程如下示意：

这里假设新软件已经下载到FOTA Master ECU, 那么还需将新软件下载到Target ECU，验证新软件的完整性和正确性，并激活新软件等动作，即执行installation, verification和 activation几个过程：

installation是指将新软件下载到target ECU，这个过程中车辆保持正常运行，即车一边跑一边再下载软件到target ECU, 所谓的 read while write.

在这个过程，Master ECU为了协调OTA升级，需要实时了解进展；软件installation需要多帧传输，这时Target ECU需要进行数据处理；installation过程也可能不是如预期顺利，比如会出现取消或中断等情况。因此，针对这些情况就会产生相应的需求，比如：

verification是指通过预定算法验证新软件。这时需求：Completeness of new software，以及指定相应的验证算法

activation是指车辆处于安全状态下，备份旧软件，激活新软件。这里，如果采用外部Flash来实现，其过程可能为先备份旧软件到外部Flash，然后复制新软件到ECU，再激活新软件。

此时需求为：

以上通过对各个过程描述和分析，示例了各个过程会产生怎样的需求。以此思路，那么对Target ECU又怎样的需求，从AutoSAR文档可见如下需求：

总的来说，需求一方面取决于整车的OTA架构和ECU情况，另一方面又取决于OTA功能的自身定义和特性。

4.2 OTA软件实现

根据AutoSAR架构，OTA软件实现方案如下所示：

对于Target ECU来说，主要分3块工作，支持UDS服务通过通讯模块传输进新软件；OTA handle模块执行处理OTA各个过程，比如上节所述的installation, verification和activation等功能；内存模块写入新软件等。

那么有：

以上就是引用AutoSAR对OTA相关需求的解释。