汽车车机OTA升级

1. 前言

        在崇尚“软件定义汽车”的大背景下,各大汽车厂商,尤其是新能源汽车厂商都支持了汽车远程OTA升级。

        远程OTA可以帮助主机厂为用户远程修复软件问题,大幅度缩短中间步骤的时间,以前还要回4S店更新软件,现在只需用户在中控上点击软件升级即可,大大减少了主机厂的召回成本和用户的时间成本,其次OTA还可以为车辆增加新功能,增加用户的新鲜感,比如更新卡拉、影院模式等;最后以前买车对主机厂而言就是一锤子买卖,而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升级会影响整个控制器的功能,因此升级前置条件会很严苛,正如前面说,升级前需要检查蓄电池电压是否合适、车辆档位、车速、高压、点火信号等。

这里,我获取到了

1)汽车车机安卓系统的OTA远程升级包

2)汽车车机安卓系统的Recovery模式服务的代码

3)升级过程的部分日志打印

下面来谈谈我了解到的OTA升级过程。

2. OTA升级包

OTA升级包的结构:

Media
    |----md5
          |---META-INF/
              `|CERT.RSA
              `|CERT.SF
              `|MANIFEST.MF
              `|----com/
                     `|----android/	
						`|----otacert
		|----config
		|----mcu.xcd
		|----metadata
		|----update.zip/
			`|---META-INF/
				`|CERT.RSA
				`|CERT.SF
				`|MANIFEST.MF
				`|----com/
					`|----android/
						`|----metadata
						`|----otacert
					`|----google/
						`|----android/
							`|----update-binary
							`|----updater-script
			`|----patch/
				`|----firmware-update
					`|----cmnlib.mbn.p
					`|----cmnlib64.mbn.p
					`|----devcfg.mbn.p
					`|----emmc_appsboot.mbn.p
					`|----keymaster.mbn.p
					`|----NON-HLOS.bin.p
					`|----rpm.mbn.p
					`|----sbl1.mbn.p
					`|----sbl1.mbn.p
					`|----tz.mbn.p
				`|----boot.img.p
			`|----system.new.dat
			`|----system.patch.dat
			`|----system.transfer.list
    |----signature

其中:        

        metadata文件是描述设备信息及环境变量的元数据。主要包括一些编译选项,签名公钥,时间戳以及设备型号等。

ota-required-cache=0
ota-type=BLOCK
post-build=Android/msm8953_64/msm8953_64:7.1.2/N2G47H/180:user/release-keys
post-timestamp=1626287511
pre-device=msm8953_64

        updater-script:此文件是一个脚本文件,具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。

        update-binary是一个二进制文件,相当于一个脚本解释器,能够识别updater-script中描述的操作。

        update.zip包的签名:update.zip更新包在制作完成后需要对其签名,否则在升级时会出现认证失败的错误提示。而且签名要使用和目标板一致的加密公钥。

3. OTA升级的安全验证与升级

3.1. 对OTA压缩包解压缩,并验证签名(signature)。

3.2. 检查“config”文件,文件内容是:qc+mcu, 确认本次需要升级的有两样,分别是 QC update.zip 和  mcu.xcd。

3.3 打开安全芯片(safe chip)获取safe key并对mcu.xcd进行解密,解密后文件命名decryptmcu.xcd。

3.4 向MCU请求软件版本号并 确认mcu和decryptmcu.xcd文件具有同样的软件版本号。

3.5 向MCU请求安全解锁(UDS 0x27服务),并将decryptmcu.xcd的内容刷进去(UDS 0x34 download服务)

step0:high voltage prepare
step1:enter diagConversation
step2:DTC off
step3:forbid transfer
step4:erase routine
step5:ask seed
step51:ask key to check
step6:enter code conversation model
step7:ask seed
step 71:send key to check
step8:erase routine
step9:ask to download
step10:send xcd data
step11:ask to quite sending
STEP 9 10 11 可以进行视情况进行多个周期的执行
step12:CRC32 check
step13:ecu reset
step14:recovery transfer
step15:DTC on

3.6 验证update.zip的签名update.zip\META-INF\com\android\otacert。

对update.zip包检查时大致会分三步:

①检验SF文件与RSA文件是否匹配。

②检验MANIFEST.MF与签名文件中的digest是否一致。

③检验包中的文件与MANIFEST中所描述的是否一致。

3.7 执行 update.zip\META-INF\com\google\android\updater-script脚本,这是正式的升级操作

1) radio update verification

验证每个镜像的MD5

2) Patching system image after verification

verification 和patch system img时用到了 system.transfer.list、system.new.dat、system.patch.dat。

patch system img执行的动作有:

patching * blocks to *
moving * blocks
stashing * overlapping blocks to *
writing * blocks to *
deleting *
zeroing * blocks
erasing * blocks

用boot.img.p对boot.img打补丁。

3) Patching firmware images

打的补丁是update.zip\patch\firmware-update\*mbn.p

3.8 打完补丁后用md5算法对所有img进行了完整性验证

4.最后

分享一些有用的资料:

android ota升级涉及的分区,Android OTA升级原理 - 实现流程(整理一)_请叫我麻花的博客-CSDN博客

Android系统Recovery工作原理之使用update.zip升级过程分析(一)---update.zip包的制作_快上车_来不及解释了的博客-CSDN博客

谈谈整车OTA系统的理解 - 知乎

<think>嗯,用户问的是OTA升级的原理,我需要解释清楚这个概念。首先,OTA全称是Over-The-Air,也就是通过无线网络进行升级。用户可能对技术细节不太了解,所以我得用通俗易懂的语言来解释。 首先,我应该从基本流程入手。OTA升级一般包括几个步骤:检测更新、下载更新包、验证、安装和重启。这些步骤需要详细说明每个环节的作用。比如检测更新时设备怎么连接到服务器,下载的内容是什么,验证为什么重要,安装过程如何确保安全,最后的重启步骤。 然后要区分不同类型的OTA,比如全量升级和增量升级。全量是指整个系统镜像,而增量只下载差异部分,这样节省流量和时间。用户可能不知道这两种的区别,需要举例说明。 安全机制是关键部分。用户可能担心升级过程中的安全性,所以需要提到数字签名、加密传输、回滚机制等。解释这些如何防止恶意软件和确保数据完整。 另外,底层技术方面,可能需要提到差分算法,比如bsdiff,以及分区切换(A/B分区)的原理,这样用户能理解技术如何支持无缝升级和降低风险。 还需要考虑不同设备的应用场景,比如手机、物联网设备、汽车,各自的OTA特点。比如汽车可能需要更严格的安全性和可靠性,而物联网设备可能关注低功耗和网络稳定性。 用户可能的疑问点包括升级失败怎么办,验证失败如何处理,为什么需要重启等。在解释过程中,要自然涵盖这些问题的答案,比如回滚机制和双分区设计的作用。 最后,总结OTA的优势和挑战,比如便捷性和安全性之间的平衡,以及技术实现的复杂性。确保回答结构清晰,逐步展开,让用户能够一步步理解整个过程。</think>OTA(Over-The-Air)升级是一种通过无线网络远程更新设备固件或软件的技术。其核心原理可分为以下步骤,我们以智能手机为例逐步说明: --- ### **一、基础流程框架** 1. **更新检测** - 设备定期(或手动)向厂商服务器发送请求,包含当前系统版本、硬件型号等信息 - 服务器比对最新版本号,若存在更新则返回元数据(如更新包大小、版本说明等) 2. **下载更新包** - 通过HTTP/HTTPS或专用协议下载压缩的更新文件 - **全量升级**:下载完整系统镜像(如2GB) - **增量升级**:仅下载与当前版本的差异文件(如200MB,使用`bsdiff`等算法生成) 3. **本地验证** - 校验数字签名(如RSA-2048 + SHA-256),确保更新包未被篡改 - 检查文件完整性(CRC32或哈希值匹配) - 验证系统分区剩余空间是否足够 4. **安装阶段** - **传统方式**:直接覆写系统分区,需重启进入Recovery模式 - **A/B分区**:将更新写入备用分区(如`slot B`),确保主分区(`slot A`)仍可正常启动 5. **重启生效** - 切换至新分区启动 - 首次启动时完成应用优化(Android的ART编译等) --- ### **二、关键技术细节** #### 1. 差分算法(Delta Update) ```math \Delta = \text{bsdiff}(F_{old}, F_{new}) ``` - 通过二进制对比生成差异包,典型压缩率可达90% - 更新时执行逆向操作: ```math F_{new} = \text{bspatch}(F_{old}, \Delta) ``` #### 2. 双分区机制(A/B System) ```mermaid graph LR A[活动分区 slot A] -->|正常运行时| B[更新备用分区 slot B] B -->|重启后切换| A ``` - 优势:实现无缝更新,降低"变砖"风险 - 存储开销:需额外预留10-20%的存储空间 #### 3. 安全防护链 - 传输层:TLS 1.3加密通道 - 包签名:非对称加密验证(如ECDSA) - 回滚保护:版本计数器(anti-rollback counter)阻止降级攻击 --- ### **三、典型应用场景** 1. **智能手机** - 每月安全补丁平均下载量:50-300MB - 升级成功率要求:>99.9%(运营商准入测试标准) 2. **物联网设备** - 低功耗设计:仅在Wi-Fi连接时下载 - 容错机制:断点续传、多重备份 3. **智能汽车** - 分级更新:ECU(电子控制单元)逐个刷新 - 安全规范:符合ISO 21434网络安全标准 - 耗时:整车升级可能需30分钟以上 --- ### **四、挑战与解决方案** | 挑战 | 技术对策 | |------|----------| | 断电导致损坏 | 写操作原子化(使用事务日志) | | 存储空间不足 | 增量更新 + 动态空间预检 | | 网络不稳定 | 分块下载 + MD5分片校验 | | 兼容性问题 | 灰度发布(先推送给5%用户) | --- ### **五、演进趋势** 1. **云原生部署**:Kubernetes集群管理大规模设备升级 2. **5G加速**:利用切片网络保障QoS 3. **AI预测**:通过设备画像预测最佳更新时间窗口 通过这种分层式、多校验的设计,OTA在确保安全可靠的前提下,实现了电子设备的高效远程维护。当前主流系统的升级成功率已超过99.95%,平均每次升级耗时比5年前缩短了60%以上。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

晓翔仔

星光很亮,我们永远胸怀梦想

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值