谈谈对汽车OTA的理解

原创 汽车ECU开发 2022-01-27 08:57

汽车已经慢慢成为一个大型终端设备。对于这样的定义,持续的功能更新是必不可少的,也意味着车辆OTA普及势在必行(PS:如果把车看做是一个终端设备,也就能稍微理解手机、IoT厂商为什么纷纷造车了)。

OTA整体架构包含OTA云端、OTA终端、OTA设计对象三部分,如下图1所示,OTA云端为OEM专属的云端服务器平台,负责零部件的软件版本管理、软件升级任务、数据分析、云诊断/质量管理以及与车端的数据同步。

OTA终端通常采用T-Box/IVI,负责软件包的下载,同时还负责验签、软件包解密、安全刷写、状态上报等,要实现这些功能主要依赖终端设备中的OTA manager和Update Agent,其中OTAmanager负责车辆ECU的更新,Update Agent则兼容不同的车内网络和通信协议。

图1 OTA整体框图(来源知网、头豹)



01.
汽车OTA的发展

在2012年以前,OTA升级主要为SOTA,其含义是软件OTA,用来升级App的,打个比方就像微信在App store里推送新的版本,你点击更新,这个就是SOTA,那会儿车辆还很少配有联网功能。

另外一种是FOTA(固件升级),比如我们的苹果手机系统从iOS15.2升级到15.3,这个就是FOTA。这种是特斯拉在2012年第一次将其引入到汽车上。那一次特斯拉增加了座椅记忆、模仿油车的怠速蠕动等功能。

到2015年左右,传统车企开始通过车辆联网引入局部OTA。2016年丰田宣布采用OTA技术更新ECU,2017年福特宣布采用OTA技术,同年大众宣布采用OTA技术,这个阶段都还是SOTA。

到2019年,国内的新势力开始陆续落地OTA,通过OTA的优化电池管理、自动驾驶、动力系统等系统,持续优化车辆的体验和性能。

图2 2019年蔚来、特斯拉、小鹏的OTA推送(来源网络)

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

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

为了实现整车级的OTA,各主机厂纷纷对原有的网络架构进行的大刀阔斧的变革,如图4列举了部分主机厂中央计算平台架构的落地时间。

图4 部分主机厂的中央计算平台

除了图4整理的外,大部分主机厂都在进行E/E架构中引入三域/中央计算平台、区域控制器,为什么大家都迫不及待的引入这些呢?除了传输数据的大幅增加外,域控架构/中央计算平台将E/E扁平化,利于实现整车级的OTA。

如图5所示为传统分布式架构与域控架构下的OTA升级步骤,在传统网关分布式架构下,由于控制器分散以及层级很深,导致在实现OTA的时候要一层一层的实现转发和透传,多次的转发和透传容易导致数据的丢失,导致升级失败。另外需要支持OTA功能的控制器,通常需要实现软件备份,也就是一个控制器内要存放两份软件,防止升级失败后,控制器变砖。由于传统控制器的芯片Flash和RAM本身就很小,基本不太可能实现。

对于域控架构,或者是中央计算平台架构,大部分控制器的功能进行了整合,大幅减少控制器的数量,而且整体的E/E架构也更加扁平,这样整车OTA实现更加容易且友好。

图5 传统分布式架构与域控架构OTA升级步骤(来源头豹)


02.
OTA发展的制约因素

当前汽车OTA升级面临最主要的问题是安全问题,同时也受通讯基础建设、软件开发能力等因素影响。

在安全性方面无论是在数据传输环节还是软件更新环节,都有可能对汽车功能、个人隐私,甚至是人身安全造成危害。如何保证车辆安全的条件下对汽车更多功能域开放OTA升级是当前行业最基本的挑战,这需要OTA流程提供商、云存储提供商、车企多方共同合作,打造一个安全的OTA升级环境。

在基础设施建设方面,随着新车逐步具备OTA功能,需要管理的车辆也越来越庞大,这就意味着车厂需要更多的服务器来存储大量的用户车辆数据,车厂对数据中心的需求也会越来越大,数据中心的建设和维护对当前车企来说还是一片知识盲区,另外较高的建设和维护成本也可能成为制约OTA发展的因素。

在软件开发能力方面,车企的软件能力是保持自身竞争力的重要能力之一。较强的软件能力将为车企带来更丰富的OTA升级内容、更短的研发周期等,并且持续为用户提供新的体验,提高用户粘性。


03.
特斯拉OTA升级流程
特斯拉作为整车OTA的鼻祖,从2012年推出的Model S到最新的Model 3都具备整车OTA能力。不仅可以通过OTA升级车载娱乐系统、应用程序等,还可以实现对ECU进行软件更新,比如电池管理系统、电驱控制单元、整车控制单元等。
特斯拉的OTA框架
特斯拉的OTA架构如图6所示,首先中控系统的CID通过特斯拉的私有握手协议,将固件包从云端下载下来,并对其进行解密和完整性校验。

图6 OTA升级框架

从OTA升级框架来看,升级方式主要为两种,一种为对有以太网连接的ECU,另一种为通过网关转换为CAN总线的ECU。
对于具有以太网连接的ECU,都具有ic-updater,cid-updater升级代理,其中cid-updater负责从云端获取固件包,并进行校验,可将cid-upadater视为本地服务器,ic-updater作为远程代理。
另外对于这类ECU而言,其采用的软件升级方式为A/B备份,如图7所示。例如当前使用的是A区,当软件需要更新时,先将软件写入至B区, 更新完之后,B区作为主系统启动,而A区作为备份区域。

图7 具有以太网的ECU的A/B备份方式
对于通过网关基于CAN总线的UDS协议或者其他协议更新的ECU。其从release.tgz中提取所需要的文件,包括:
1、boot.img:在升级过程中运行,其类似于常用的flash driver;
2、Release_version.txt:包含固件的版本信息;
3、Version_map2.tsv和Signed_metadata_map.tsv:包含固件信息;
4、Internal_option_default.tsv:包含固件的默认配置信息;
5、ECU命名的文件,其格式为ECUName/ProviderID/ECUFwName.hex。其主要是hex格式的文件,真正需要下载至ECU的文件。

参考:头豹的车OTA研究报告,网络。


本文福利:分享报告《华为:EV高压平台电驱动解决方案创新与展望》,公众号对话框回复【汽车ECU开发028】下载。


推荐阅读

小鹏P7内部ECU技术信息梳理
激光雷达检测的工作原理
CAN总线基础入门总结
CANXL和CANFD数据链路层的主要区别
深度解析CAN FD与传统CAN的差异
一文详解激光雷达
保时捷Taycan的电子电气架构详解
关于汽车人转型,“正能量”故事看腻了,今天来一篇“负能量”的
2021年文章合集,你想要的全在这里!
欧阳明高院士:滑板底盘将给汽车带来一场革命
对传统主机厂的一些思考
Tesla AutoPilot 纯视觉方案解析
如何写一份牛X的汽车软件需求
关于对汽车ECU软件测试的理解
特斯拉最新中央计算模块(CCM)解析
2021款特斯拉Model Y ECU接口梳理
详解CANoe之CAPL编程
关于CAN时间同步的理解
dbc文件的格式以及创建详解
基于UDS的Bootloder详解
关于整车上下电流程的理解
一文详解CAN总线错误帧|附下载
DoIP协议介绍,资料分享!
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
分享不易,恳请点个【在看】
汽车ECU开发 专注于汽车电子ECU软件开发,技术分享。
评论 (0)
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦