您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
未来软件定义汽车,OTA体系建设是车厂的首要任务
 
 
   次浏览      
 2021-7-9 
 
编辑推荐:
本文主要介绍了OTA与智能网联汽车战略、OTA体系设计思考、OTA体系实践与进阶 。
本文来自于微信首席出行官EO,由火龙果软件Anna编辑、推荐。

十年来,随着市场内逐渐兴起“可更新的汽车信息娱乐系统”的概念,汽车制造商也“赶时髦”地推出了可升级的车机系统和以及配备了联网功能的汽车。而像特斯拉这样来自硅谷的公司则走得更远,率先开始为车主提供OTA远程更新服务。据国外相关机构预测,到2022年,全球汽车生产企业每年能够通过使用OTA的方式节省350亿美元的成本。显而易见,在汽车未来发展的过程中,空中升级(OTA)对于车辆的信息安全显得愈发重要。

基于其在电子、软件行业12年的从业经验,具体解析智能网联汽车OTA体系的设计与实践。ABUP艾拉比智能科技专注为汽车、物联网领域合作伙伴提供专业OTA升级技术解决方案和定制化服务。该公司目前正式合作的客户包括比亚迪、江淮、上汽通用、上汽乘用车、长城汽车等主机厂,以及国内Tier 1供应商等,具备一定合作经验与技术基础。

主要围绕三方面展开:OTA与智能网联汽车战略、OTA体系设计思考、OTA体系实践与进阶。亿欧汽车对他的观点进行了整理编辑,以下为分享实录:

首先,行业发展趋势势必将走向由软件定义汽车。摩根士丹利的数据显示,目前在整个汽车产品中软件与硬件的占比为1:9。就现阶段而言,硬件占据了整个汽车成本以及生态系统的绝对主导性地位。但是在未来,随着智能化、网联化的不断发展,汽车内部的占比构成会变成4:4:2,如果把内容也看作是另外一种软件形态的话,那么未来软件的整个成本构成及生态占比会超过硬件。这就是“软件定义汽车”概念的由来。

从消费端来看,用户逐渐开始把自己的关注点从汽车动力、车身长度、内饰等方面,向对软件体验及内容生态等方面的感受倾斜。随着“软件定义汽车”趋势的走强,未来或许还将发展成“软件定义品牌”,就这点来说,相信大家在手机行业都已经有了切身的体验。现在决定消费者对于诸多手机品牌厂商的品牌体验和感受的差异性并不仅仅是硬件。如今,产品硬件本身是同质化的,大家可能基本都选择高通的芯片、索尼的摄像头等等。但真正造成用户对品牌形成差异化体验的,永远是软件的体验以及内容的生态。

所以从这个角度来讲,这种“新概念”迫使整车厂必须去建立一套系统,使其能够有效地管理自己未来的软件资产,并且能够远程进行运维维护以及更新。这就是整个OTA体系建设诉求的由来。

OTA与智能网联汽车战略

我们先来探讨一下OTA技术在智能网联汽车发展战略中的重要地位。2017年,各大主机厂纷纷发布了自己关于2025年智能网联汽车的发展规划及发展战略。在这当中,我们发现了一些共同点:其实很多主机厂都把OTA和诊断平台变成自己发展战略规划中的一个重要的里程碑和基础节点进行建设。

在整体思路方面,大家普遍会分为四个阶段:第一阶段,汽车联网能力的构建和普及:在打造个人用户系统的同时,提供基于互联网特色的内容和体验。

第二阶段,OTA和诊断平台等基础性平台的能力建设,为未来智能网联核心工作的发展打下一个比较坚实的基础。

第三阶段,引入辅助驾驶:很多车厂会在2020年左右推出支持辅助驾驶以及低级别自动驾驶的部分智能网联汽车产品,通过已经建设好的OTA体系不断优化迭代辅助驾驶算法以及能力,同时车联网后台可以利用OTA管道来收集、处理更多与辅助驾驶相关的大数据信息。

第四阶段,对于很多车厂2025规划来说,都是V2X以及高级自动驾驶能力的实现。众所周知,任何一个通信标准从诞生到成熟,都必须依赖于OTA技术的不断迭代,来保证整体互联性和互通性的普及。事实上,高级别自动驾驶的实现,也是一个逐渐迭代的过程,不可能一蹴而就。目前,很多厂商选择硬件冗余并通过软件不断迭代的方式,最终达到高级别自动驾驶的状态。

通过OTA技术,未来具有强大硬件性能和软件OTA能力的车辆,才能成为真正意义上的智能终端。借此,车联网才能够将大数据能力、监控更新能力以及用户管理能力融为一体,完成下一代的进阶。

今年年初,国家发改委发布了智能汽车创新发展战略,其中也对2020和2025年国家智能汽车创新发展的战略目标进行了明确规划。此举无形中推动了V2X以及高级自动驾驶能力的快速实现,所以对于很多主机厂来说,目前OTA体系的建设迫在眉睫。

在整车厂的规划中,OTA体系和整个智能网联运营平台又存在何种对应关系呢?整车厂对于OTA平台的建设思路是独立、统一、易对接和可扩展的。

独立意味着,区别于现在的TSP平台。大家都知道,目前很多车厂在1.0发展规划中已有自己的TSP平台,其中具备一定的OTA能力实现对TBOX甚至是车机等单独业务功能模块的远程升级。但是站在整车角度来看,这种模式对整车长远的发展并不能起到很好的支撑作用。所以,现阶段有必要去建设一套独立化的专属OTA管理平台。

统一,指的是未来对于固件升级、应用层软件升级、新功能的导入、ECU固件的更新、ECU标定的更新、配置字的更新、安全补丁包升级等方面,未来都需要在OTA平台上进行具体的实施和落地,这需要一个统一的接口。

易对接的特点是,未来OTA平台并非孤立存在,需要与各平台体系进行打通,这样才能产生更大的价值。

可扩展指的是,让OTA平台未来能够自由扩展到更多平台进行对接。同时,同一套OTA管理平台可以支撑不同车辆车型平台,还可以根据车辆数目的增多,进行硬件扩展。

汽车OTA体系设计思路

从整个OTA体系的功能定位上来看,未来TSP平台可以借助OTA平台实现操作系统版本的更新、新功能的导入激活、ATP的升级管理以及内容的更新;诊断和售后平台可以借助OTA平台实现ECU固件的更新、ECU标定的更新、配置字的更新;车厂以后自己建设智能驾驶管理平台未来可以借助OTA平台实现逻辑处理部件的更新,以及算法和一些算法参数的更新,包括现在很多车厂正在建设的安全运维管理平台,未来可以利用OTA平台进行信息安全的应急措施的响应,以及安全漏洞的补丁升级。这就是OTA体系在整车厂规划中重要作用的体现。

接下来,我们再看一下汽车OTA体系整体的设计和建设思路。从汽车OTA体系的基本框架来看,汽车OTA体系是一个典型的由云、管、端组成的系统。未来,汽车端层次包含了很多跟汽车OTA相关的具体应用程序,运行在供应商的设备上。汽车端的工作包括:负责本地信息的采集及上报、未来升级包的下载与本地执行等。

中间层——通信端,主要负责在云端和汽车端之间进行业务交互协议定义,以及应用层的相关协议。服务器端则主要负责升级包的制作,车型和车辆的管理,为不同的车型和车辆配置不同的升级策略和升级任务。这就是典型的OTA管理体系的构成。

在云端,整体OTA体系建设核心思路包含以下几个方面:首先是软件管理,包括对于升级包的分类,譬如ECU的固件包、很多车机平台的软件包,还有未来的地图包、语音包、参数标定以及配置字等不同的升级类型。我们首先需要对它进行分类,同时不同类型的升级包需要不同的制作过程。升级包及其制作过程都对应不同的ECU,还有升级包自己本身迭代版本的对应关系,都需要在软件管理层面进行统一考虑。

其次是车辆的管理。对于OTA来说,当我们去推送或者配置一次OTA升级时,我们首先要了解到车端的具体情况,包括车端硬件体系的构成以及当前软件版本的具体信息。这是能够配置好OTA升级的前提条件。

再次是任务管理。我们会在任务管理中为不同的车辆模型配置不同的升级策略。配置好升级策略之后,未来还要通过白名单或黑名单的方式去管理不同的升级灰度。比如说有些升级,必须要面对特定地区的车辆,或者是特定用户名单中的车辆,或者是工程车辆。还有对于升级条件的管理,车辆必须满足某种条件才能收到自己的升级包以执行整个升级过程。此外,还有对于发布后的升级任务进行管理,管理其执行度及执行状况。

当然,除此之外,对于OTA体系来说最重要的还有对于人员的管理。随着未来OTA体系部署和建设的私有化,车厂也规划了专门的OTA管理团队,这当中就会涉及到一些角色以及权限的分配。不同的角色和不同的权限对应着不同的管理及工作流程,所以在云端建设中,人员的管理也是重中之重。

在管道端的建设速度方面,主要包括了以下几个层次的思考:首先在链路层,对于整车厂而言,主要考虑的问题是:未来流量池的问题、未来整个OTA体系的流量是走用户的流量还是走自己的流量?是否采用独立的APN?还是跟现有的TSP APN复用?未来OTA场景走的是公网还是私网?或者说公网私网混合的架构?这些都是链路层需要考虑的问题。

那在协议层部分主要考虑的是,在车端和云端建立的连接,是基于TLS1.2的双向还是单向认证体系?这部分跟整车端的实际能力以及车厂的建设思路息息相关。

至于管道端的应用层,很多车厂需要考虑的是整个应用层的协议。车端和云端的交互是否采用国际通用标准,比如说采用OMA体系协议的规范和框架?还是基于私有化的自定义的协议体系和框架?这部分也将直接影响到未来的成本投入及灵活性,车厂需要做出综合考量。

而在整个OTA体系中,建设难度相对较高的是车端体系的建设思路,其中主要包括三个层面。首先是整体架构的设计,包含升级目标的确定:哪些ECU未来可以作为远程升级的目标,以及升级主控的选择:需要以什么样的设备为主,把升级包分发给别人,来掌控整个升级流程的进展。还有升级流程的设计:未来整个升级流程如何执行,出现问题应该怎样处理。

除了整体架构之外,也要在总线和协议方面进行考量。未来升级包在车内进行传输,那我们采用什么类型的总线进行传输?大家都知道,大部分总线都是基于CAN线来传输的。然而对于一些智能化设备而言,是否还适用于走CAN线,或者去走一些高速的总线。对于传输协议也是如此,对于CAN线上升级包的传输或者是刷写,可以复用现有UDS的协议。但是对于一些高速线的升级包的传输,也需要额外定义一些OTA相关的传输协议。未来升级的整个场景和用户的HMI是息息相关的,车主必须要有执行权,所以整个升级体系的流程必须要与HMI定义清晰的协议体系框架。

最后就是电气性能的规划和设计,主要包括升级方式的划分。大家都知道,未来在车内整个架构中,不同ECU的电器器件,肯定会对应不同的升级方式,有些可能是采用UDS刷写的方式,有些可能采用整包升级的方式,有些必须要采用差分升级或者增量升级的方式,这样不同的升级方式需要提前进行划分。有了不同的升级方式,也要对应地对空间、分区等ECU的选择阶段进行空间方面的预留。同时,对于被选择作为升级主控节点的设备,或者刷写主控节点的设备,未来也要提前规划一些能力,比如说联网能力、存储能力、分发能力以及安全能力。

当然,上述三个方面其实只是一个前提和基础,这只能保证未来车端是可以支撑云端OTA体系的。这其中最大的难点在于,由于未来车厂希望这套体系可以应用于不同车型与平台中,所以在平台和车型之间存在着巨大差异化的前提条件下,如何能够把上述设计抽象出统一的OTA升级体系规范,这件事对于很多从业者来说非常值得思考,并且迫在眉睫。

汽车OTA体系实践与进阶

最后,我们讨论一下关于汽车OTA体系的进阶思考。首先,是统一化的建设思路。车厂必须在整个OTA体系的设计阶段,就考虑到未来OTA管理平台所接入车型的差异化。所以整体思路应该遵循:导入供应商的多元化以及ECU具体产品设备的硬件和软件碎片化,才能保证未来自己平台的统一化。

设计得再好,也要有可行性作为保障和前提。所以可行性保障对车厂来说也是重中之重。就这方面而言,作为OTA服务商必须能够给予车厂成熟方案,并且能够根据车厂的实际诉求、实际能力进行实际的定制。同时能够拿出合理的分工及可行性计划。更关键的是,除了拥有开发能力和可行性能力之外,还要有一个能够进行测试和验收的成熟方案。在这部分,目前国内体系相对比较缺失,这就必须要依赖于整个OTA体系服务商现有的经验和项目能力,进行整体把控。

另外一部分,就是对于供应商的选择。对于支持OTA的车型而言,未来供应商的角色会变得非常重要。未来供应商的能力包括对于自身设备特性的规划能力,主控设备是否已经具备了联网、存储、本地分发、安全管理等能力。他们是否有能力对于车厂定义好的HTK进行集成式的开发,以及自身的设施和验证能力,对于车厂来说都是很关键的。

当然,对于车厂来说,最关键的还是自身管理体系的完善以及平台的建设。管理体系的完善包括车场自身对于车型车辆以及具体车辆中软件管理能力的不断建设和不断提高。以及与未来建设好的OTA管理平台,同步进行OTA运营团队的战略建设,当前我们也在配合很多车场同步进行团队建设。这样就保证了未来我们建设好的OTA平台,是由真正的OTA运营团队进行运营的,保证未来的交付质量和交付效率。同时车厂也要规划更多其他功能型平台的建设,以及它们如何和OTA平台对接,这些也是在OTA平台建设阶段同时需要考虑的问题。

在Q&A环节,对于部分听众关于OTA技术的问题进行了解答:

Q:在OTA更新过程中,除了签名验签的防护机制之外还有其他防护策略吗?如果仅有签名验签的防护,有哪些风险?

A:在OTA的更新中,其实签名和验签机制是最基础的工作,也是我们进行OTA体系建设时必须要实现的机制。通过签名和验签机制,主要防护未来升级包来源的合法性,这是一个基础。当然,只有签名和验签机制是远远不够的,同时还涉及到身份的验证。比如说,车端要和云端实现交互,除了验签机制之外,还要对身份进行验证。这部分工作需要基于PKI的体系进行建设,或者需要PKI的一些基础。同时,除了对升级包进行签名和验签之外,还需要加密和解密技术,为了杜绝未来升级包内容泄露的可能性。

Q:OTA升级管端通道是用公网或私网,各自的优劣势,怎么考虑?

A:对于公网和私网的优劣势主要基于以下几方面考量:私网最大的好处当然就在于安全性和私密性的保证,其劣势则在于未来随着车辆不断增多,对于整个服务器的处理能力以及管道吞吐量有着很高的要求,尤其是对于整个车辆跨地域覆盖程度是一个很大的挑战。

公网的优势就在于,可以利用现有的公有云资源,尤其是借助CDN技术,来保证未来面对大规模车辆的升级场景时,可以采用CDN技术进行升级包的有效分发和高效的下载。当然,缺点主要在于相对私网来说,安全性稍有欠缺。这个就是车厂方面的实际考量。

从实际项目案例来看,目前大部分都采用了公网私网整合的架构,业务流程使用私网,升级包的下载过程基于公网。这也是世纪项目中的典型选择。

Q:针对于不同硬件供应商升级包格式的差异化,OTA平台如何做到统一管理各类厂商的升级包?

A:这是一个十分核心的问题。未来需要提供一套整体的统一的做包工具,通过做包工具弥补这些差异化。当然,在做包的时候,首先需要进行分类,再去实现标准化。除了标准化之外,还有管理的统一性,要跟车厂现有的管理体系规范达成一致。比如说很多车厂现有的零部件管理系统,其中一些编码规则将同样适用于软件,统一规划实现。

Q:现阶段在车辆深度嵌入式且对安全性要求较高的应用方面,似乎还尚未实现OTA。对此,艾拉比方面未来是否有相关针对性计划?您认为,就这方面而言,哪种路线是最优选择?

A:从我们以及很多车厂的观点来看,当考虑技术可行性和方案搭建时,其实就已经把深度嵌入且相对安全性较高的ECU升级考虑进来了,这里面最典型的就是底盘ECU等等。当然现在大家看到,很多车厂对外宣传或者对外介绍时,的确是没有涉及到这样一些领域。这背后的原因在于,OTA体系的建设不是一蹴而就的,需要一个渐进的过程。所以对于车厂来说,现阶段并未把ECU体系作为当前建设目标,但是目前在我们的合作车厂中,都已经将其确立为下一步升级目标了。

第二,对于这样一些核心关键件的ECU,同时也需要有很高的可靠性保障。为了实现这种保障,在整体架构层面,未来比如说刷写这些ECU,或者升级这样ECU的节点上面,要做很多优化和冗余的工作。同时呢,对于这样的ECU本身,也要做好这种双分区、双备份的机制,这样的话才能够实现可靠稳定的升级。

所以就这方面而言,关于这个路线我认为肯定是一个逐步实现的过程。不是说车厂有直接规划就可以直接实现的,同时也要借助于ECU厂商以及整车架构的变化。所以我相信可能大家在2019年或2020年的部分车型上,能够见证这样场景的实现。

事实上,在智能汽车领域,除了技术端的OTA升级,还有更多汽车供应商、人工智能技术甚至能源网络运营商等占据产业链上游的领域需要去探寻。

 
   
次浏览       
相关文章

汽车电子电气架构解析
一文读懂汽车自动驾驶技术原理
究竟什么是“软件定义汽车”
中央计算单元架构和高性能计算单元架构
相关文档

汽车设计-汽车的整体结构及动力系统
自动驾驶汽车软件计算框架
SysML在汽车领域的应用实践
电子电气架构-大陆汽车系统架构平台
相关课程

AutoSAR原理与实践
功能安全管理体系(基于ISO26262)
MBSE(基于模型的系统工程)
基于UML和EA进行系统分析设计
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]
 
最新文章
AUTOSAR模式管理看这一篇就够了
AUTOSAR架构介绍
无人驾驶汽车系统入门——最短路径搜索之A*算法
汽车功能安全 - 软件开发
干货 | 一文帮你读懂ISO26262汽车功能安全!
最新课程
Auto SAR原理与实践
MBSE(基于模型的系统工程)
国际汽车行业五大质量工具理论与实战
人工智能助力汽车行业升级
基于UML和EA进行系统分析设计
SysML和EA进行系统设计建模
更多...   
成功案例
均胜(上海)汽车安全有限公司 购买EA工具
深圳某汽车企业 模型驱动的分析设计
上海某汽车电子 EA+UML进行嵌入式系统分析设计
上海蔚来汽车 SysML+EA-进行嵌入式系统分析设计
更多...