OTA（ON THE AIR）空中升级

本质

OTA实质就是在车机上插一张流量卡，把车企网络服务器上面的s19（或其他格式）下载到车机里，然后由车机对车载ECU进行bootloader刷写。

OTA技术实现分三步：

1、将更新软件上传到OTA中心，

2、OTA中心无线传输更新软件到车辆端

3、车辆端自动更新软件。

OTA的技术是CAN bootloader，一般而言，车载ECU只有支持了bootloader，才能在此基础上搞OTA。

换句话说，只有本地刷写OK了，才能OTA。

1、定义

OTA：空中升级（ON THE AIR）是通过无线通讯网络（WIFI/5G/4G），实现对汽车控制器的软件进行更新的技术。

只要是通过无线通信方式实现升级的，都可以叫OTA升级，比如网络/蓝牙。

通过有线方式进行升级，叫本地升级，比如通过UART，USB或者SPI通信接口来升级设备固件。

一般来说，OTA 分为三类：

1、 FOTA（Firmware-over-the-air，固件在线升级），指的是给一个车辆设备、ECU 闪存下载完整的固件镜像，或者修补现有固件、更新闪存。

例如它可以升级咱们车辆的转向系统，让我们的驾驶操作更 加轻松，升级油门踏板的反应力度，让加速更线性舒适等等，总之相比SOTA而言，FOTA技术含金 量更高。

2、SOTA（Software-over-the-air，软件在线升级），指的是对操作系统、地图，应用程序进行更新升级。

那些看上去离使用者更近的应用程序和地图 OTA，都属于 SOTA 的范畴。例如我们升级多媒体系统更换操作界面、主题，甚至是更换仪表盘显示风格时，用到的基本都是这种SOTA的升级方式，这也是如今我们自主品牌汽车OTA升级主要方式。

3、COTA（Configuration-over-the-air），付费购买服务后，通过OTA方式打开车辆上某项功能权限。

2、FOTA和SOTA的区别

（1）SOTA（对车载信息交互系统的升级）：针对车机系统内的软件和娱乐功能做远程增加、删除、改进、升级等。像导航功能、界面优化、人机交互功能等远程升级都属于SOTA，在新能源车上已经是属于相当普遍的功能了。它可以改变雨刮、智能大灯、导航软件、音乐软件、语音交互系统等等表层控制程序的使用体验。汽车厂商仅仅需要发送需要修改的部分即可，更像是我们通常意义上说的“补丁”。

（2）FOTA（对车辆三电系统控制程序的升级）：对系统固件的升级。通常来说，汽车都存在电子控制单元ECU，你可以将它理解为整车的大脑，它负责整车的执行机构，包括发动机、变速箱、行驶机构、驾驶辅助系统等。而FOTA就是在不改变汽车硬件的情况下，对车子的驾驶辅助功能、底盘悬架、车身控制等进行远程升级。而上述提到的特斯拉和理想的OTA升级均属于FOTA。它可以改变车辆的充放电、动能回收、加速性能、辅助驾驶系统逻辑等等与深度驾控有关的体验。譬如说之前特斯拉通过升级将动能回收的选项取消了，这属于FOTA升级。

3、OTA实现

以汽车嵌入式控制器为例，其软件软件代码分为两大类：

一部分是操作系统、用户数据、标定数据等代码，统称为应用程序（APP），

另一部分则是运行引导程序（Bootloader）

Bootloader是一段独立的代码(这段Boot代码一般是出厂预置，或使用编程器烧录的，通常只有1k或4k，通常是占用一块独立的Block，当系统上电之后，Bootloader可以进行：关闭WATCHDOG、改变系统时钟、初始化存储控制器、将更多的代码复制到内存中等一系列初始化动作，然后再将操作系统内核制到内存中运行。简单地说，Bootloader就是这么一小段程序，它在系统上电时开始执行，初始化硬件设备、准备好软件环境，最后调用操作系统内核进入工作。与之对应的是PC中的BIOS。

Bootloader和APP应用程序在嵌入式存储器中的位置如下：

由于我们所有的操作系统和用户数据都放在APP程序中，通过更改这部分数据可以优化控制器的使用体验，所以许多汽车厂家所谓对MCU进行固件更新（FOTA）实际上就是对MCU内存中的APP存储区域进行刷写。

刷写有两种方式:

(1)先擦除当前版本软件，再刷写新版本软件，但这种方法有个隐患，就是新软件有问题时，由于旧软件已经被擦除，没有备份，恢复会很麻烦

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

由于OTA可以对控制器软件进行擦写，为了确保软件的完整性，可信性，许多车企在OTA系统中开发了安全服务平台。

此外为了，节省OTA下载时流量费用，许多车企开发了差分升级的技术，即利用算法，做出原版软件和新版软件差分包，将差分包下载到flash中，内部的BootLoader程序再利用算法将新版软件还原，一般差分包只有原包的5%左右。

3.1、OTA升级核心流程

1.制作升级包      2.下载升级包      3.验签升级包         4.更新程序

3.1.1、OTA下载方式

不管采用OTA方式还是有线通信方式升级，下载升级包的方式包括后台式下载和非后台式下载两种模式。（不管哪种方法，最后都是由BootLoader完成新固件覆盖老固件的操作）

（1）后台式下载（新固件下载过程中，应用可以正常使用）：

在升级的时候，新固件在后台悄悄下载，即新固件下载属于应用程序功能的一部分，在新固件下载过程中，应用可以正常使用，也就是说整个下载过程对用户来说是无感的，下载完成后，系统再跳到BootLoader程序，由BootLoader完成新固件覆盖老固件的操作。

比如智能手机升级Android或者iOS系统都是采用后台式方式，新系统下载过程中，手机可以正常使用。

（2）非后台式下载（升级过程中正常功能都无法使用）：

在升级的时候，系统需要先从应用程序跳入到BootLoader程序，由BootLoader进行新固件下载工作，下载完成后BootLoader继续完成新固件覆盖老固件的操作，至此升级结束。

早先的功能机就是采用非后台来升级操作系统的，即用户需要先长按某些按键进入bootloader模式，然后再进行升级，整个升级过程中手机正常功能都无法使用。

3.1.2、新旧固件覆盖模式

新固件替换老固件覆盖的两种方式：双区模式和单区模式。

（1）双区模式（后台式下载必须采用此模式，以5.4.2章节内容为准）

        双区模式中老固件和新固件在flash中各占一块bank（存储区）。假设老固件放在bank0（运行区）中，新固件放在bank1（下载区）中，升级的时候，应用程序先把新固件下载到bank1中，只有当新固件下载完成并校验成功后，系统才会跳入BootLoader程序，然后擦除老固件所在的bank0区，并把bank1的新固件拷贝到bank0中。

        优点：

        升级过程中出现问题或者新固件有问题，它还可以选择之前的老固件老系统继续执行而不受        其影响。

        缺点：

        多占用flash空间的一个存储区，在系统资源比较紧张的时候较为困难。

（2）单区模式（Bootloader先擦除后升级）

        单区模式的非后台式下载只有一个bank0（运行区），老固件和新固件共享这一个bank0。升级的时候，进入bootloader程序后先擦除老固件，然后直接把新固件下载到同一个bank中，下载完成后校验新固件的有效性，新固件有效升级完成，否则要求重来。

        优点：

        跟双区模式相比，单区模式节省了Flash空间的一个bank，在系统资源比较紧张的时候，单区模式是一个不错的选择。

        缺点：

        如果升级过程中出现问题或者新固件有问题，单区模式碰到这种情况就只能一直待在bootloader中，然后等待再次升级尝试，此时设备的正常功能已无法使用，从用户使用这个角度来说，可以说此时设备已经“变砖”了。

        相比较，双区模式虽然牺牲了很多存储空间，但是换来了更好的升级体验。

3.2、MCU OTA升级

以MCU（微控制器）固件升级为例，讲解嵌入式裸机程序的OTA升级。由于裸机固件是固化在设备的存储器（如flash）中，即存储器中保存的是机器码，对MCU进行OTA固件升级，也就是要实现通过OTA方式将存储器中旧固件的机器码替换为新固件的机器码。

3.2.1、制作升级包

通过签名工具使用签名算法对固件进行数字签名，签名后的文件即为升级包。

3.2.2、下载升级包（后台式、非后台式）

根据上位机软件和MCU设备约定的通信协议，上位机软件将升级包通过OTA方式发送给MCU设备，MCU设备收到数据后，根据通信协议解析出升级包的数据，并将升级包的数据保存到存储器中。

3.2.3、验签升级包

MCU设备接收完所有的升级包后，先计算升级包中固件的摘要，然后使用非对称秘钥的

公钥解密升级包的签名值，如果解密出来的固件摘要与自己计算的摘要相同，则验签成功。

3.2.4、更新固件（单区模式、双区模式）

验签成功保证了固件的完整性和合法性后，MCU设备从应用程序进入BootLoader程序，

在BootLoader程序中将flash中的新固件数据搬运到旧固件的存储区，将其覆盖。

然后BootLoader程序启动固件运行，此时固件为新固件。

flash固件数据更新：

擦除flash，写flash。

4、OTA测试

所以，在测OTA之前，我们要先测单个ECU的BT刷写。（因为OTA是基于BT实现的）

此时，大家一定要记得车辆技术讲过的HIL概念中的“虚实结合”，一定要明确自己的测试对象，哪些用真实的，哪些是虚拟的。

（1）第一步：测单个ECU的BT

        在测单个ECU的时候，ECU是真实的，诊断仪是虚拟的，我们通过这个虚拟的诊断仪，模拟各种复杂特殊工况，充分考察该ECU在各种情形下的表现，是否符合功能规范和性能要求。）

（2）第二步：OTA测试（要测的是OTA服务器+车机，模拟的是ECU）

         OTA测试，你的测试对象是“OTA服务器+车机”，目的是测试他俩一起的可靠性，这一点一定要明白！

        你需要模拟的是ECU，通过模拟ECU各种各样的正常回复、异常回复、异常信号和动作，考察这个OTA系统的可靠性，这才是根本！

         所以，最有用的OTA方案，压根不需要车企提供ECU，提供刷写规范即可。

        再次呼吁

        我们的测试目的是OTA系统，而不是ECU。

        用上真实的ECU，就类似于HIL测试领域的纯实物了，属于录制分析，测试覆盖率极其有限，很多工况都模拟不出来。

        ota既要模拟ecu测试ota系统，模拟更多异常场景；同样也需要测试实际ecu单件，实车场景，这是为了测试在多场景的ecu成功率, 测实际件并不是一无是处。

5、OTA技术架构

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

OTA云端：OEM专属的云端服务器平台

OTA终端：采用TBox

网络架构采用功能域划分方式。

5.1 OTA升级对象（不太重要）

汽车OTA升级对象主要包括操作系统和应用APP，以及车内嵌入式设备ECU的升级。

5.1.1 操作系统升级（双系统升级策略）

存放系统程序的区域分为两部分，一部分为当前运行程序，另部分为备份程序。

除了第一次安装的时候没有备份之外之后的安装都是有两系统程序共存的。当前运行的是最新版本程序、备份区域为上一版本程序。当当前程序发生错误的时候，系统自动回滚到上一版本，不会导致系统死机的情况发生，为系统提供双重保险。

5.1.2 App 应用软件升级（验证成功被新版本覆盖；验证失败回滚旧版本）

与操作系统升级类似，但不需要支持双区系统。如果升级完成并运行验证成功，则被新版本覆盖:如果验证失败，则回滚旧版本。其中 APP 升级适配器需要实现版本故障诊断能力，即对每个文件 hash 表进行 hash 验证等，以便判断文件是否被损坏。

5.1.3 车内嵌人式设备 ECU等的升级

依赖 ECU自身提供的升级协议(包括 Ehemet、Can等)，通过OTA终端的ECU 升级适配器适配不同的设备需求，并完成升级，如图7 所示。这些车内 ECU 自身需要对外暴露升级的指令规范、并具有保证可靠升级、以及判断和汇报升级结果的机制。通常，嵌入式设备升级频率相对较小软件大小较小，一般采用通知静默全量升级模式。

5.2 FOTA升级

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

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

行车时不升级软件，只下载软件。等安全状态下，才会更新ECU软件。

若是双区模式，可在车辆正常运行状态下，将新软件下载到target ECU。

车辆处于安全状态下，备份旧软件，激活新软件。

支持UDS服务通过通讯模块传输进新软件。

5.3 ECU的OTA技术实现方案

主要介绍车内嵌入式设备ECU的OTA技术实现方案，也就是整车控制器，发动机控制器，变速箱控制器和电池管理控制器等实现OTA升级，可以采用怎样的实现方案。

从上文可知，在车辆端，OTA实现是从TBox 端（4G LTE）经网关，通过总线通讯（CAN或以太网）将软件刷写到车内嵌入式设备ECU（目标ECU）。

对于汽车ECU软件研发来说，所谓软件要么是模型，要么是C/C++代码，但最终都会变成一个二进制文件，比如HEX, S19, Bin等格式。这个文件将会被刷写到ECU的非易失性存储单元（内存）。

问：关于软件刷写，经常会看到需求“要求支持Bootloader，BSW，ASW和标定等独立刷写”，这是怎么个概念呢？

答：像英飞凌TC2xx系列采用的内存是Flash，存储程序叫做PFlash，存储数据叫做DFlash。为了合理有效使用这些内存，同时也方便管理，通常我们会分配这些内存的用途，以下图的PFlash分配为例，分配2MB存启动软件Bootloader，2MB存底层软件BSW和2MB存应用层软件ASW。针对前面需求，不难理解客户的意思，就是需要能只更新其中一个，比如ASW，而其他不变，即Bootloader和BSW不变。

5.4 几种OTA实现方案

OTA实现方案分为两种：

5.4.1 单区模式（先擦除再刷写）

1、与通常的刷写方式一样，即先擦除当前版本软件，再刷写新版本软件，但这种方法有个隐患，就是新软件有问题时，由于旧软件已经被擦除，没有备份，恢复会很麻烦。

5.4.2 A/B交换。（内存中会分两块区域，支持旧版本软件回滚）

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

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

（1）该方案要求ECU内存足够，而且支持地址重映射，也就是当新版本软件刷写完成，通过更新映射地址来激活新版本软件，即新版本软件运行的入出地址不变。

（2）与第1类的差别在于ECU硬件不支持地址重映射，激活新版本软件的入出地址变化。

（3）基于外扩内存的A/B交换方案

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

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

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

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

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

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

5.5 新版本软件

OTA升级刷写的新版本软件，一般分为两类：

1、新软件替换旧软件。（像车辆ECU的大部分软件很小，都采用这类）

2、差分文件。（像车辆的娱乐信息系统和车载地图等的软件很大，可能采用此类）

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

5.6 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，再激活新软件。

5.7 OTA软件实现

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