一文理清车端OTA技术栈

loohoolinda

本文大约6686字，预计阅读时间20分钟。

前言

在2018/2019年前后，OTA这个概念在汽车电子领域并不是很火。随着新四化的兴起，OTA这个概念变得越来越火，伴随着信息安全的兴起，Secure Boot的需求也越来越多，这些需求又推动了汽车电子OTA的发展。

我们不经要问，OTA和之前的UDS刷新是一回事吗，OTA和FOTA是同一件事情吗？OTA和SOTA是同一件事情吗？OTA对于硬件有什么要求吗？

OTA在其他领域，尤其是手机领域，是一个成熟的话题，甚至大家可以在开源网站上找到相关的开源代码，比如说之前介绍过的swupdate。甚至于，大家去买一些开发板玩的时候，很多商家直接送你一套所谓的OTA代码工程，直接开源送你，供你研究。

那么，汽车电子的OTA和其他领域的OTA是一回事吗？从技术本质上讲，大道至简，殊途同归。但是汽车电子的OTA明显更为复杂，对于系统的鲁棒性和稳定性有及其高的要求。后续会展开详细介绍。

对于整个汽车电子OTA软件大致分为云端OTA软件和车端OTA软件。本文不涉及云端OTA软件相关技术栈，仅仅尝试理清车端OTA软件技术栈。

本文作者由于水平有限，难免有些错误或者不准确的地方，恳请读者批评指正。如果读者有任何宝贵意见，Feel  Free  and 随时与我联系，期待您的真挚反馈。

OTA概念

OTA是由Over The Air首字母缩写组成，即空中下载，具体指远程无线方式。OTA技术可以理解为一种无线升级技术。

FOTA是由Firmware Over The Air首字母缩写组成，即固件在线升级，通过云端为具有联网功能的设备提供固件升级服务。

SOTA是由Software Over The Air首字母组成，即软件在线升级。

UDS刷新是指使用Unified Diagnostic Services（统一诊断服务）对设备进行刷新。

从软件形态上讲，UDS刷新是OTA技术栈中的一小部分内容，每个行业都有一些规范，UDS刷新就是汽车行业刷新规范中的一部分。无论是OTA还是UDS刷新，无论是FOTA还是SOTA，这些技术的发展均是为了对汽车进行软件升级。

OTA需求

OTA本质是为了更新汽车软件，本质上是对汽车里面的控制器（熟称电控单元）进行软件更新。OTA的出现是为了帮助OEM为用户远程修复软件问题，减少召回成本和用户的时间成本。

以前软件更新需要去4S店，现在只需要在车机中控屏上点击同意软件升级即可。当然，OTA也附带着产生新的商业模式，拓宽OEM的“服务”和“运营”能力。

OEM对于OTA升级需求

几乎所有的OEM对于此功能的需求的目的均是一致的。

1. 更新稳定

更新稳定要求在全场景下稳定更新，不出错。正常更新时，不会时不时的出现更新失败的事情，绝对不允许把控制器更新成砖（控制器变砖是指控制器无法上电，无法再次被更新，也无法正常使用）。就算汽车异常断电、控制器偶发更新时复位、整车偶发其他尚未更新的控制器节点未保持静默状态（控制器静默是为了给刷新留出能力进行大数据量的通信），重新上下电之后仍然可以正常更新。

异常断电有可能是车主在进行汽车软件升级时，电未充满，导致软件更新时，无法正常供电，这是一种很常见的OTA场景。

控制器偶发更新时复位是由于控制器在做OTA时，需要进行控制器复位进入OTA流程，如果此时硬件状态异常，比如说偶发板载亏电，或者偶发硬件报功能安全故障（可能是硬件残余电流电压导致的），或者软件识别复位失败，或者通信超时，可能会发生更新时控制器复位。

汽车软件进行OTA更新时，并不是一次性完成所有控制器的更新，而是逐步更新各个控制器。在某个控制器进入OTA流程之后，这条总线上的其他控制器应保持静默状态，即不发出正常的通信报文但是允许有少量的符合企标规定的报文发出，静默状态是为了给OTA流程留出足够大的通信带宽，保证OTA所需的通信报文正常发送和接收。

为了防止汽车软件在OTA过程发生异常之后无法正常使用，主流的控制器已经实现了A/B Bank机制，这个机制是为了OTA失败之后，功能仍然可以正常运行。

2. 更新快

用户很反感等待某一件事情，OTA的时间过长，会降低用户的用车体验。因此，OEM必须想尽办法减少OTA的时间，加快OTA的更新速度。其中一条很重要的需求就是减少更新包的大小，通过降低OTA更新包的下载时间，进而降低OTA的更新时间。

更新快不仅仅是更新包小，也可以采用速度更快的物理总线，比如说以前的Normal CAN，现在用CANFD，以前用CAN，现在用以太网。更快的速率会减少更新包的下载速度，进而降低OTA时间。

当然，也可以采用差分，数据压缩的方式提高更新包的下载速度。总而言之，必须要想尽办法降低OTA更新时间。

3. 更新兼容性好

OTA的兼容性演变是一个痛苦的过程，甚至无法预料相应的需求。兼容性不仅仅指传统意义上的软件兼容性和完整性校验，在新四化的过程中，传统控制器和集中式的控制器最大的区别在于控制器内部存在多个刷新单元（多个芯片），导致兼容性和完整性上升到整域的软件兼容。

OTA作为通用软件，业内普遍的做法是同一个平台多车型共用一套OTA软件，这就要求OTA软件能兼容这种同平台多车型的场景。

另外一方面，4S店、政府部门、售后部门、产线等设备的兼容性是OEM不得不面对的现实，售后、质检和产线设备的更新需要投入大量的金钱，一次性按需投入是不现实的，当新老电子电气架构发生交互碰撞，又要考虑兼容的时候，就会产生很多“奇葩”的需求。

4. 符合要求

要求不仅仅是OEM的规范，更要考虑国内法律法规、欧盟法规、美国法规等等其他法规。其中，信息安全合规是OTA的第一挑战。

供应商对于OTA升级需求

1. 没有一丝可能把控制器升级成砖

控制器装载到汽车上时，一般是不会留出debug口，更无法通过debug口对控制器进行更新。因此，对于供应商而言，控制器变砖是无法容忍的，这种情况一般OEM会要求索赔，造成供应商的损失。

2. 永远有备用更新方案

为了在升级时不让控制器变砖，供应商需要在设计OTA流程时，预留出备用的更新方案（紧急状态下的救板子方案），在正常OTA流程无法进行下去的时候，仍然可以通过备用方案完成软件升级的任务。

3. 满足客户企标需求

在前面两条需求的基础上，必然要考虑客户需求，一般按照客户企标进行开发，在这个过程中，需要考虑客户需求与供应商自身需求的架构解耦，平台软件受控流程和项目软件受控流程的一致性。

OTA升级流程

无论OTA技术怎么发展，均离不开以下几样步骤：

1. OTA流程触发

2. OTA前置条件检查

3. 更新包的下载与验证

4. 更新包的刷写

5. 更新后系统的验证

车载控制器的OTA流程一般是被动式触发的，一般由云端或者诊断仪触发。OTA需要一个稳定的电压环境，保证足够的电量，汽车处于安全状态，例如车速为0，档位处于P档，实现网络管理以便于留出足够的总线负载等等。因此，控制器需完成OTA前置条件检查，保证OTA满足顺利完成的基础条件。在前置条件完成之后，进入刷新模式，开始刷新流程，之后的流程典型例子就是UDS34,36,37服务。

在OTA包更新结束之后，必须要对整个系统进行验证，验证软件刷新符合预期，保证软件兼容性和软件完整性。



OTA节点类型

为了更好地了解OTA流程，需提前了解控制器属于哪一类OTA节点。从不同的形态上讲，OTA节点有多种分类。

从车载网络层次角度来看，有的控制器支持外联云或者连接OBD口比如说车机，有的节点属于新E/E架构下的区域控制器比如左前域控制器，有的属于特殊功能的大型控制器比如说刹车，转向控制器，还有智能执行器，传感器等等节点属于车载的最末端。



从数据传输总线的角度看，车载控制器领域有支持以太网的控制器(大型域控制器)、支持汽车电子较为成熟CAN/CANFD总线的控制器（电驱控制器，小三电控制器），也有支持车企应用不多的FlexRay总线的控制器（比如说网关控制器），当然也有支持LIN总线的控制器（方向盘按钮控制器、雨刮控制器等等），有一些控制器通过SPI总线被其他控制器控制（比如说一些智能节点），当然还有其他总线，比如说蓝牙、USB、UART、I2C（蓝牙钥匙、车机通过USB更新软件、通过I2C更新switch，通过串口（UART）连接域控制器更新软件）。



当然，还有其他分类方式，有的节点是OTA的发起方，是Master节点，比如说域控制器下载好软件包之后去刷新其他其他节点。网关作为典型的转发节点，会将DoIP数据流转换成DoCAN数据流。车内所有控制器均是Slave节点，都需要支持OTA流程。

目前很多控制器支持硬件A/B Bank分区比如说英飞凌Tc3xx系列芯片，当然也有很多控制器不支持A/B Bank，比如说NXP S32K1xx系列芯片。软件实现的A/B Bank大部分是由SoC芯片实现的，比如说典型的英伟达Orin芯片。当然我们也可以按照芯片类型去分类OTA节点，比如说MCU节点，同构SoC节点，异构SoC节点。

每一个OTA节点对于OTA失败的影响程度是不一样的，有些关键的节点，比如说重要的switch刷新，一旦OTA失败，switch无法正常工作，将导致以太网无法正常使用，车云连接全部中断。而有的节点一旦OTA失败，由于旧的软件已经被擦除，新的软件更新失败，节点可能会无限复位，如果不做特殊处理，则很难再次刷新。以上这些节点都是影响巨大的节点。而有的节点则影响有限，虽然OTA失败，任何时候均可进入等待刷新模式，只需要重新走OTA流程即可。有的节点比较智能，OTA失败则直接运行旧有软件，完全不影响功能。



MCU OTA技术栈

传统的MCU OTA有如下功能分区：



MCU OTA开发第一步需要考虑的是Memlayout划分，之后开始BootLoader开发。MCU整个OTA流程如下图所示，遵循ISO-14229标准，熟称UDS协议，则Boot需要支持UDS协议开发。我们默认BSW使用工具链开发，比如说vector的工具链，因此BSW开发遵循工具链的相应流程。

若底层基于CAN/CANFD开发，则底层需要支持CAN驱动开发，CANTP协议栈开发（遵循ISO-15765规范）。如果底层基于以太网开发，则需要支持以太网驱动开发、TCP/IP协议栈开发、DoIP协议栈开发（遵循ISO-13400规范），LIN节点则需要支持LIN驱动开发、以及相应的LINTP协议栈开发。

在这个流程中，我们需要使用2E服务写EEPROM，因此，需要支持Fee&Fls驱动开发、支持NvM开发。此外，我们需要使用31服务擦写Pflash，需要支持Fee&Fls驱动开发，PFlash相关接口开发。

为了支持整套刷新流程完成，需要搭建最小的Boot工程，包括相应的编译工具链开发，给27服务提供基于时间计数器的随机数种子接口、提供系统复位接口、提供协议栈所需的时间戳接口。



在此基础上，为了符合信息安全法律法规，引入安全启动、安全刷新、安全认证的流程，需要支持密码学库的开发，比如说基础的RSA、SHA、CMAC算法以及SM2、SM3、SM4国密算法。有些控制器内置信息安全硬件（HSM）或者外置信息安全芯片。那么需要支持信息安全硬件开发并且和Boot/BSW工程集成。在信息安全模块正常运行的情况下，安全认证需要对27服务进行改造，比如说对使用29服务，或者基于CAN做双向认证流程，基于以太网实现TLS流程。为了实现安全启动，硬件方案可以通过HSM/安全芯片实现，软件方案需要对完成Memlay、Linker脚本以及Hex工具链的改造（包括HEX签名工具等等）。

到此为止，BootLoader开发基本完成，已初步完成客户需求开发。然而，为了OTA效率，继续优化迭代，采用压缩算法，改造36服务数据传输，减少所需传输的数据量，则需支持压缩算法适配。为了满足工厂刷新的效率，MCU OTA实现并行刷新，满足工厂一台设备对多个MCU控制器同步刷新的需求，需要对MCU UDS协议栈进行改造。为了实现连续刷新/缓存式刷新，提升数据的传输效率，MCU OTA流程需满足缓存多个UDS命令，则需要改造MCU UDS协议栈以及MCU CANTp协议栈。

当然，很多SoC对MCU进行OTA时，由于MCU是控制器的内部节点，不走UDS协议，也不走传统的车载总线，则需要自定义刷新流程协议，完成相关的驱动和协议开发。

很多控制器需要支持A/B Bank刷新，实现真正的FOTA或者SOTA，则需要开发相应的芯片配置。若芯片本身不支持A/B面，则需要使用软件进行模拟A/B分区，相应配套工程需要实现两套，这种方式在MCU支持的较少。由于芯片自身支持OTA A/B面，很多控制器可不实现BootLoader开发，在A面BSW层级刷新B面，或者在B面BSW层级刷新A面，实现OTA升级。需要在当前流程中插入一步，识别当面处于A面还是B面，刷新时更新对面即可。

为了与客户需求解耦，将Boot划分成两级Boot: Start Boot和Customer Boot。Start Boot实现供应商自身的平台统一开发流程，实现板子自救等需求（防变砖）。Customer boot符合客户OTA流程。在Start Boot和Customer Boot、BSW软件开发的过程中，需要特殊处理10服务的跳转流程。在RAM中运行boot有益处帮助软件排查一些特殊的问题，查询特殊的数据，RAM Boot可通过Start Boot加载并跳转，RAM Boot可根据实际情况进行任意变更，并不需要告知客户。RAM Boot也仅仅是在最紧急的情况下使用，一般用于救板子，刷新丢失的关键数据、Boot自更新等等。在这个架构下，Start Boot可支持更新Customer及其以上的分区，Customer Boot支持更新BSW分区，RAM Boot支持更新所有任意分区，包括工厂分区（理论上出厂则不可修改）。



MCU OTA相关技术总结如下表所示：

Memlayout开发

Boot基础工程开发

基于工具链的BSW开发

驱动开发

传输层协议栈开发

UDS协议栈开发

EEPROM&PFlash驱动开发

存储接口开发（NvM、Pflash接口）

密码学库开发

安全芯片或者HSM开发以及Boot工程集成

压缩算法库开发

相关的协议栈改造（并行刷新，缓存式刷新）

认证流程开发（双向认证、TLS）

链接脚本等工具链开发（含HEX签名工具）

私有刷新OTA协议开发

FOTA芯片配置开发或者配套工程开发

Start Boot和Customer Boot、RAM  Boot开发（特殊处理跳转流程）

符号列表

SoC OTA技术栈

相比较MCU OTA技术栈，SoC OTA技术栈更为复杂，需求更加多样化。就OTA方案而言，可使用Recovery系统方案即在主系统之外，增加一个Recovery系统，升级时，主系统负责升级Recovery系统，Recovery系统负责升级主系统。Recovery系统一般采用intiramfs，尽量保证镜像最小化。AB系统方案采用A/B分区的方式进行OTA升级，即一套存储设备上存储AB两套系统，两套系统互相升级。

SoC整体流程如下图所示，SoC等待云端下发更新指令到车机中控屏，车主点击中控屏同意软件更新之后，车机下发更新指令到SoC控制器，SoC从云端获取更新包，之后进入到更新包处理流程：差分包还原、解压缩、解密、更新包结构验证。处理完更新包之后，SoC控制器将更新包刷新至控制器（MCU、Switch、SoC自刷新、下属子节点），至此完成整套流程。





SoC OTA流程如上所述，SoC获取更新包则需要支持HTTP/HTTPS协议、MQTT协议等等，也有其他自定义的安全协议，需要SoC和云节点交互，需要满足信息安全要求。车云之间需要通过无线连接，一般是WiFi、4/5G、蓝牙，因此需要支持无线连接。更新包需要支持工具链，实现各类软件、镜像文件等的生成与打包、压缩等功能。

在车端SoC控制器内部，需支持更新包的差分还原，则需支持差分算法。差分可以减少更新包的大小，缩短更新包的下载时间，差分包制作和还原过程如下图所示。支持更新包的解压缩，一般需要集成相应的解压缩算法库例如libtar开源库。压缩也是为了减少更新包的大小，加快数据传输，这是基于香农定律对数据本身进行压缩，不需要其他更新包的参与。

更新包的解密需要密码学库或者加密芯片或者内置加密模块的参与，因此需支持密码学库、加密芯片或内置加密模块开发，甚至有些环境集成了TEE。



为了对刷新更新包，此处引入了X-OTA的概念，即支持多种OTA。XOTA支持协议转换、全域跨域升级、整车系统状态控制、集中式升级管理系统。对于SoC更新SoC，需要对硬件存储分区，这一步即制作存储的Memory Layout。为了可以让用户空间调用存储接口，SoC BSP软件需要支持Memory Technology Device（MTD、内存设备技术）或者适配其他存储驱动。作者注：MTD技术主要是为了屏蔽闪存类设备的数据格式差异、简化驱动设计（尤其是与擦写寿命相关的逻辑以及坏块管理）。

对于SoC刷新MCU或者其他下属节点，一般采用DoIP、CANTP或者私有协议的方式完成相关软件的更新，因此此处需要支持LINTP协议、CANTP协议、DoIP协议，UDS Client协议、私有协议相关开发。当然也有可能使用SOA相关的服务完成OTA流程，例如SomeIP、DDS等。

特别说明，特殊节点例如车机和网关，存在大量的OTA过程中协议转换的需求，CAN和LIN互转、DoCAN和DoIP互转，HTTP/SomeIP/DDS等协议与UDS相关协议互转，这里很多协议既是Slave又是Master，并且MCU OTA技术栈的相关需求，此处也必须一并支持。

而对于Switch等特殊节点，电路上一般采用I2C或者SPI相连，因此需用相关通信协议发起OTA流程。SoC BSP需提前开发好相关驱动，用户空间需适配相关的OTA私有协议。

当然，特殊的OTA过程仍需被考虑。串口在正常的OTA流程中很少被用作软件更新，但是在开发过程中，串口经常被用作通信口和开发电脑直连进行软件更新。一般这个软件需要SoC Boot或者芯片的启动流程支持。

有时，客户要求支持在uboot下完成软件特殊更新，一般需基于uboot开发软件，涉及到相关的存储驱动，NFS等驱动的开发。作者注：Uboot支持通过NFS挂载上位机的根文件系统，进而在上位机的文件系统中完成特殊的软件操作。



USB在车机系统的更新中很常见，仪表盘/中控屏本身外置USB接口。将U盘制作成刷新盘即可更新车机甚至其他软件。一般需要开发SoC BSP，使能相关的USB驱动，当然也需开发相应的应用软件。

SoC OTA相关技术总结如下表所示：

车云协议（HTTP/HTTPs、MQTT、其他私有安全协议）

更新包工具链（生成、打包、压缩、差分等等）

差分算法

解压缩库（例如libtar）

无线连接（WiFi, 4/5G,蓝牙）

密码学算法、加密芯片、内置加密模块、TEE开发

存储Memory Layout（文件系统分区划分等等）

SoC BSP适配（MTD、存储驱动适配开发）

LINTP协议、CANTP协议、DoIP协议、UDS 协议、私有协议开发（Master/Slave Client/Server相关开发）

MCU OTA技术栈也需支持

SOA相关协议开发（SomeIP、DDS等）

SoC BSP通信驱动开发（I2C、SPI）

特殊的私有协议开发

SoC Boot开发

SoC Uboot开发（存储协议、NFS协议）

SoC BSP USB开发

符号列表

OTA测试技术栈

OTA测试传统的工具是Vector公司的Canoe/Canape、VFlash，使用Capl作为编程语言，可以实现UDS相关的刷新，也可使用C#语言调用Canoe底层接口完成整套OTA流程的测试。XCP标定工具581/582工具也可以用来实现OTA的上位机刷新。

目前国产CAN设备工具可实现基于Python或者C++语言的整套OTA测试案例，这些国产工具提供了很多底层通信协议供上层使用。Python提供Python-CAN库，为控制器提供局域网支持，为不同的硬件设备提供通用的抽象，以及一套用于CAN总线发送和接收消息的实用程序。Python-CAN是可以调用Vector的相关工具的。

以太网测试则更为便捷，使用电脑即可，也可以使用Vector公司支持以太网的Canoe工具。为了满足T1和RJ45（TX）口的硬件转换，需要额外购买一个T1/TX转接器。Python Scapy库提供提供了以太网各类协议栈相关的接口调用，可很方便的构建出想要的数据帧。使用Python很方便的构建出HTTP相关的服务器，用于模拟云端下发指令。

各类SOA相关的程序例如SomeIP的开源软件vSomeIP，DDS开源软件FastDDS、CycloneDDS等等均可提供相应的软件支持，基于相关构建，实现OTA相关测试案例。

OTA测试相关的技术栈如下：

Vector相关工具的使用Canoe\Canape、VFlash

Capl语言的学习

581、582相关工具的学习

Python语言的学习

Python-Can库、Python-Scapy库

Python HTTP Server的编写

相关开源软件的集成与适配

熟悉主流汽车电子协议栈

符号列表

总结

我们会回到最开始的几个问题。

汽车电子OTA技术从技术栈上和其他领域的OTA一致，但是使用的通信协议种类多，范围广。

OTA和SOTA、FOTA本质上是一件事，软件更新，但是SOTA更偏向于软件实现OTA，FOTA则有了硬件的加持。

FOTA对于硬件有要求，要求硬件层级对芯片的地址访问进行映射。

OTA的技术栈涉及的十分复杂，需要具体问题具体分析。

参考链接

https://www.cnblogs.com/nuoyan/p/11777424.html

https://blog.csdn.net/2301_76563067/article/details/132578692

https://zhuanlan.zhihu.com/p/424564162

https://blog.csdn.net/challenglistic/article/details/130774922

https://blog.csdn.net/PlutoZuo/article/details/133637707

https://blog.csdn.net/weixin_42444745/article/details/132692356