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所示。
当前各主机厂的OTA能力
02.车辆OTA系统组成
为了实现车辆上控制器的OTA,主机厂必须搭建整个OTA系统,其简要架构如图4所示。整个系统由OTA云端服务器,OTA终端,一般为T-Box,OTA对象——车载控制器组成。
OTA系统的构成
OTA云端服务器
OTA云端服务器包含主机厂支持OTA升级的控制器全部的完整的升级包。OTA云端的设计要求是独立的平台,支持多车型、多型号规格、多种类型ECU软件的升级。OTA云端的框架结构主要包括五部分:OTA管理平台、OTA升级服务、任务调度、文件服务、任务管理,如图所示。在安全性方面,支持多种安全加密和解密算法,例如常用的对称加密算法DES、AES等和非对称加密算法RSA、DSA。
OTA云端服务器架构
OTA终端
OTA终端主要包含OTA引擎和OTA适配器,其中OTA引擎是一个连接OTA终端与OTA云端的桥梁,实现云端同终端的安全通信,包括升级包下载、升级包解密、差分包重构等功能。OTA适配器是为兼容不同的软件或设备的不同更新逻辑或流程,根据统一的接口要求封装的不同实现。升级适配器由需要OTA升级的各个ECU软件实现提供。
OTA对象
OTA对象就是车上能支持OTA的控制器,主要包括座舱控制器、ADAS控制器,以及车内嵌入式控制器。为了支持OTA功能,控制器必须具有软件备份功能,也就是A/B分区,简单的来说,控制器会存两份软件,一份为当前最新,另一份为上一次的。当更新异常或者更新失败后,可以用回上一版的软件。保证控制器不会刷死。
控制器A/B分区(来源十一号组织)
03.OTA流程
在车辆出厂之前,主机厂通常需要将车型和车辆信息录入到OTA云端的信息管理系统中。然后当车出售给用户后,车辆OTA终端首先要在OTA云端进行注册激活。OTA终端上传自身 SN 及车辆 VIN 向OTA云端服务端申请证书, VIN 及 SN 验证合法后(SN 是否在已激活列表中),后台将下发证书,修改车辆状态为已激活。这样终端与云端的通信链路已经建立。
当市场用户反馈或者是主机厂内部测试控制器软件存在Bug时,各个控制器的供应商修复问题,然后后向主机厂提供软件升级包,在主机厂内部走完测试、验证和签字发布流程后,进入到OTA云端服务器的待升级软件列表。
然后由OTA的管理人员创建OTA升级对象,升级计划以及升级内容,并下发通知到对应的用户车辆。
用户根据中控屏幕的提示,在合适的时候确认升级,OTA终端开始从云端将软件包下载下来。这里有两种情况,如果本地没有当前版本软件包的备份,则申请下载当前版本的全量包,如果有,则下载当前软件包的差分包。
差分包的原理是通过差分算法,常用的为Xdelta 算法、 Vcdiff 算法、 Bsdiff 算法 ,在OTA云端对比新软件包与旧软件包的差别,然后生成一个差分包,将差分包下载到OTA终端后,再将其与本地存的旧文件进行对比,还原新软件包。
差分原理
当OTA终端完成新软件包的下载,以及校验和验签后,在满足对应ECU的刷写条件的时候,比如上面提到的车辆的状态:蓄电池电压、车速、高压状态,以及OTA终端当前的状态(如图8所示),都符合条件后对ECU进行软件更新。
这里还有一种就是预约升级场景,比如预约晚上10点进行升级。这种情况下T-Box需要具备定时唤醒功能,在预约的时间T-Box被唤醒,然后唤醒BCM给整车上电,同时升级过程中 BCM 还需禁止车内大功率用电负荷(空调、前照灯等)工作,避免蓄电池电量消耗过多。在判断车辆的条件满足后,启动升级流程对控制器进行升级。
OTA终端升级任务管理
在升级过程中,OTA终端要把ECU升级进度及时上传给OTA管理服务器 ,升级完成后汇报升级成功结果 。
整个OTA升级的流程如图9所示。
OTA 发布升级流程
04.OTA系统的安全机制
整个OTA系统的安全需要从OTA云端到OTA终端以及OTA对象的整个链路进行全方位的防护。从软件上传到OTA云端、OTA云端到OTA终端以及车辆内部升级过程的各个环节,都采用适宜的加密机制来提升整个升级过程的安全性,包括OTA云端的权限限制、证书验证、签名验证和权限验证。
在软件包下载前,OTA云端和终端首先使用 PKI/CA 认证系统进行双向身份验证。验证通过后,云端和车辆端会建立基于 TLS 安全协议的安全通信通道,该通道保证云端与车辆端之间信息传输的安全性。在车辆内部, T-Box、IVI车机和网关之间的交互信息采用私有协议密文传输,升级固件的加解密通过在 T-Box、 IVI 和网关内部集成的硬件安全模块进行,同时硬件安全模块还能保存加密秘钥,防止软件包被篡改。
从OTA云端与OTA终端之间的安全方案如下图所示。
OTA云端与OTA终端之间的安全策略
当OTA终端对新软件包完成安全校验后,开始对特性控制器进行软件更新,这里的安全策略通常是采用对软件包二进制文件的CRC校验,诊断的0x27或者SFD进行权限校验来保证。这些验证后,开始通过UDS协议将新软件下载到控制器中。
05.软件OTA升级法规
在汽车行业刚引入OTA之时,由于没有法规监管,以及统一的标准,各主机厂按照自己的理解开展OTA推送,或者有些主机厂为了赶上市,抢市场,先发布产品,后续慢慢OTA完善软件。
为了使OTA技术在汽车行业良性地发展,相关的法规以及行业指南也慢慢在完善。
2020年11月25日国家市场监督管理总局出台了《关于进一步加强汽车远程升级(OTA)技术召回监管的通知》,目的是通过有效的手段和方法辨识召回与升级的差别。以避免OEM通过OTA方式消除缺陷,掩盖召回事实的行为。
主机厂在采用OTA方式对已售车辆开展技术服务活动的,应按照根据《缺陷汽车产品召回管理条例》及《缺陷汽车产品召回管理条例实施办法》要求,向市场监管总局质量发展局备案。如发现生产者存在未按规定备案有关信息或召回计划、不配合缺陷调查、隐瞒缺陷或未按照已备案的召回计划实施召回等违法行为的,将严格依法处理。
2021年4月,工业和信息化部装备工业一司组织编制了《智能网联汽车生产企业及产品准入管理指南》,该指南是它涉及功能安全、信息安全、软件升级、数据记录、仿真/实车测试等方面。而在软件升级上又主要包括对管理制度、标准规范、升级影响、测试和验证、适配性、可追溯性、告知义务和安全性等内容写明了相应规范,整体的规范如图11所示。
指南中软件升级的规范
2022年4月15日,工业和信息化部装备工业发展中心发布了《关于开展汽车软件在线升级备案的通知》,主要从备案范围、备案要求、备案工作流程、实施安排和企业责任五个方面来规范主机厂OTA升级,比如明确备案范围:OTA升级应进行备案,并且申请主体应是汽车整车生产企业。
文章来源于网络,如若侵权,请联系站长删除。
本站承接各类商务合作,如有合作需求,请联系我们。