整车OTA系统的理解

来源:电子工程专辑发布时间:2022-08-22

分享至微信

2012年，特斯拉发布的Model S，也正是它，将OTA技术带入到汽车行业，每年都会通过OTA来修复问题或者新增功能(图1是特斯拉历年的OTA次数统计)。

图1 特斯拉历年的OTA次数

而今距离那年已经过去了10年，OTA已经被汽车行业广泛认可和接受，并且各主机厂也陆陆续续在部署。

首先来简单聊聊，为啥OTA在汽车行业被越来越接受呢？估计大家偶尔会听到特斯拉召回事件，比如今年4月27号特斯拉因为功率半导体存在微小的制造差异，可能会导致后逆变器发生故障，造成逆变器不能正常控制电流，召回部分车型，而仔细一看，是远程OTA更新电机控制器软件。

图2 特斯拉召回OTA修复通知

从中可以看出，远程OTA可以帮助主机厂为用户远程修复软件问题，大幅度缩短中间步骤的时间，以前还要回4S店更新软件，现在只需用户在中控上点击软件升级即可，大大减少了主机厂的召回成本和用户的时间成本，其次OTA还可以为车辆增加新功能，增加用户的新鲜感，比如更新卡拉、影院模式等；最后以前买车对主机厂而言就是一锤子买卖，而OTA的加持，可以拓宽主机厂的“服务”和“运营”的范畴，增加车辆的附加价值，比如自动驾驶付费软件包，功能订阅等等。

01.

OTA类别

从更新的范围来看，OTA分为SOTA(software-OTA)和FOTA(firmware-OTA)。

SOTA通俗点说是应用程序升级，是一种小范围的应用软件更新，比如你在手机上更新个抖音，这种就是SOTA。SOTA通常应用在座舱控制器，以及后续电子电气架构升级后的中央计算单元以及大型域控制器等。比如座舱控制器中的地图更新、主题壁纸更新、仪表盘风格更新等，特斯拉2019年10月的V10车机更新中影院模式、卡拉OK、地图功能升级、茶杯头游戏，这些就是SOTA。

由于SOTA的升级范围比较小，对控制器的影响也比较小，因此升级的前置条件也比较宽松，比如在主机厂的控制器的UDS升级规范中，通常要求在升级前检查蓄电池电压是否合适、车辆档位、车速、高压等，对于SOTA来说，可能档位、车速、高压都不用看了，车边开边升级。

FOTA是固件升级，需要将控制器的整个软件重新刷一遍，来达到系统功能完整的升级更新或者是bug的修复，这里就类似于以前Android手机的刷机，电脑的重装系统。目前像整车控制器、DCDC、电机控制器、BMS的升级都是FOTA，比如电机控制器的IGBT的过流故障的保护策略有漏洞，需要更新软件；2020年4月特斯拉为Model S和Model X Peformance的升级，将百公里加速缩短至2.3s，车辆热性能提升3倍，升级弹射模式，这些就是FOTA。

由于FOTA升级会影响整个控制器的功能，因此升级前置条件会很严苛，正如前面说，升级前需要检查蓄电池电压是否合适、车辆档位、车速、高压、点火信号等。

目前基本大多数车企都已实现OTA(不管是SOTA还是FOTA)，不过大部分是实现重要控制器的OTA功能，比如自动驾驶控制器，中控、电池管理、电机控制等。各车企的实现情况如图3所示。

图3当前各主机厂的OTA能力(来源头豹)

02.

车辆OTA系统组成

为了实现车辆上控制器的OTA，主机厂必须搭建整个OTA系统，其简要架构如图4所示。整个系统由OTA云端服务器，OTA终端，一般为T-Box，OTA对象——车载控制器组成。

图4 OTA系统的构成

OTA云端服务器

OTA云端服务器包含主机厂支持OTA升级的控制器全部的完整的升级包。OTA云端的设计要求是独立的平台，支持多车型、多型号规格、多种类型ECU软件的升级。OTA云端的框架结构主要包括五部分：OTA管理平台、OTA升级服务、任务调度、文件服务、任务管理，如图5所示。在安全性方面，支持多种安全加密和解密算法，例如常用的对称加密算法DES、AES等和非对称加密算法RSA、DSA。

图5OTA云端服务器架构

OTA终端

OTA终端主要包含OTA引擎和OTA适配器，其中OTA引擎是一个连接OTA终端与OTA云端的桥梁，实现云端同终端的安全通信，包括升级包下载、升级包解密、差分包重构等功能。OTA适配器是为兼容不同的软件或设备的不同更新逻辑或流程，根据统一的接口要求封装的不同实现。升级适配器由需要OTA升级的各个ECU软件实现提供。

OTA对象

OTA对象就是车上能支持OTA的控制器，主要包括座舱控制器、ADAS控制器，以及车内嵌入式控制器。为了支持OTA功能，控制器必须具有软件备份功能，也就是A/B分区，简单的来说，控制器会存两份软件，一份为当前最新，另一份为上一次的。当更新异常或者更新失败后，可以用回上一版的软件。保证控制器不会刷死。

图6控制器A/B分区(来源十一号组织)

03.

OTA流程

在车辆出厂之前，主机厂通常需要将车型和车辆信息录入到OTA云端的信息管理系统中。然后当车出售给用户后，车辆OTA终端首先要在OTA云端进行注册激活。OTA终端上传自身 SN 及车辆 VIN 向OTA云端服务端申请证书， VIN 及 SN 验证合法后（SN 是否在已激活列表中），后台将下发证书，修改车辆状态为已激活。这样终端与云端的通信链路已经建立。

当市场用户反馈或者是主机厂内部测试控制器软件存在Bug时，各个控制器的供应商修复问题，然后后向主机厂提供软件升级包，在主机厂内部走完测试、验证和签字发布流程后，进入到OTA云端服务器的待升级软件列表。

然后由OTA的管理人员创建OTA升级对象，升级计划以及升级内容，并下发通知到对应的用户车辆。

用户根据中控屏幕的提示，在合适的时候确认升级，OTA终端开始从云端将软件包下载下来。这里有两种情况，如果本地没有当前版本软件包的备份，则申请下载当前版本的全量包，如果有，则下载当前软件包的差分包。

差分包的原理是通过差分算法，常用的为Xdelta 算法、 Vcdiff 算法、 Bsdiff 算法，在OTA云端对比新软件包与旧软件包的差别，然后生成一个差分包，将差分包下载到OTA终端后，再将其与本地存的旧文件进行对比，还原新软件包。

图7 差分原理

当OTA终端完成新软件包的下载，以及校验和验签后，在满足对应ECU的刷写条件的时候，比如上面提到的车辆的状态：蓄电池电压、车速、高压状态，以及OTA终端当前的状态(如图8所示)，都符合条件后对ECU进行软件更新。

这里还有一种就是预约升级场景，比如预约晚上10点进行升级。这种情况下T-Box需要具备定时唤醒功能，在预约的时间T-Box被唤醒，然后唤醒BCM给整车上电，同时升级过程中 BCM 还需禁止车内大功率用电负荷（空调、前照灯等）工作，避免蓄电池电量消耗过多。在判断车辆的条件满足后，启动升级流程对控制器进行升级。

图8OTA终端升级任务管理(来源知网)

在升级过程中，OTA终端要把ECU升级进度及时上传给OTA管理服务器，升级完成后汇报升级成功结果。

整个OTA升级的流程如图9所示。

图9OTA发布升级流程(来源知网)

04.

OTA系统的安全机制

整个OTA系统的安全需要从OTA云端到OTA终端以及OTA对象的整个链路进行全方位的防护。从软件上传到OTA云端、OTA云端到OTA终端以及车辆内部升级过程的各个环节，都采用适宜的加密机制来提升整个升级过程的安全性，包括OTA云端的权限限制、证书验证、签名验证和权限验证。

在软件包下载前，OTA云端和终端首先使用 PKI/CA 认证系统进行双向身份验证。验证通过后，云端和车辆端会建立基于 TLS 安全协议的安全通信通道，该通道保证云端与车辆端之间信息传输的安全性。在车辆内部， T-Box、IVI车机和网关之间的交互信息采用私有协议密文传输，升级固件的加解密通过在 T-Box、 IVI 和网关内部集成的硬件安全模块进行，同时硬件安全模块还能保存加密秘钥，防止软件包被篡改。

从OTA云端与OTA终端之间的安全方案如下图所示。

图10 OTA云端与OTA终端之间的安全策略(来源知网)

当OTA终端对新软件包完成安全校验后，开始对特性控制器进行软件更新，这里的安全策略通常是采用对软件包二进制文件的CRC校验，诊断的0x27或者SFD进行权限校验来保证。这些验证后，开始通过UDS协议将新软件下载到控制器中。

05.

软件OTA升级法规

在汽车行业刚引入OTA之时，由于没有法规监管，以及统一的标准，各主机厂按照自己的理解开展OTA推送，或者有些主机厂为了赶上市，抢市场，先发布产品，后续慢慢OTA完善软件。

为了使OTA技术在汽车行业良性地发展，相关的法规以及行业指南也慢慢在完善。

2020年11月25日国家市场监督管理总局出台了《关于进一步加强汽车远程升级（OTA）技术召回监管的通知》，目的是通过有效的手段和方法辨识召回与升级的差别。以避免OEM通过OTA方式消除缺陷，掩盖召回事实的行为。

主机厂在采用OTA方式对已售车辆开展技术服务活动的，应按照根据《缺陷汽车产品召回管理条例》及《缺陷汽车产品召回管理条例实施办法》要求，向市场监管总局质量发展局备案。如发现生产者存在未按规定备案有关信息或召回计划、不配合缺陷调查、隐瞒缺陷或未按照已备案的召回计划实施召回等违法行为的，将严格依法处理。

2021年4月，工业和信息化部装备工业一司组织编制了《智能网联汽车生产企业及产品准入管理指南》，该指南是它涉及功能安全、信息安全、软件升级、数据记录、仿真/实车测试等方面。而在软件升级上又主要包括对管理制度、标准规范、升级影响、测试和验证、适配性、可追溯性、告知义务和安全性等内容写明了相应规范，整体的规范如图11所示。