基于车云一体新架构的发展,对ota2.0定义的探讨-金年会金字招牌信誉至上

基于车云一体新架构的发展,对ota2.0定义的探讨
技术干货 2022.04.01

智能汽车时代,汽车ota是一个热点概念,也是汽车的一个卖点。作为一家汽车行业的工程服务公司,怿星科技和艾拉比智能合作,基于行业的新需求,电子架构的演进,以及车云一体的新应用场景的发展方向,一起来探讨一下如何更准确更严谨的定义ota2.0,也欢迎各位行业专家提出自己的见解。


telematics和ota的区别

汽车telematics的概念出现已经有快20年了,ota概念在手机行业的出现稍晚一些,辐射到汽车行业是近5年的事情。同样是基于移动数据网络作为通信管道,实现车辆终端和服务器后台的交互,表面上好像都是车云一体的场景,而实际上这两个概念对车联网系统的描述维度是不一样的。


telematics是一个创造出来的单词,指的就是汽车和服务后台(tsp)通过移动网络的数据交互实现信息化的功能。早期的telematics定义,将车辆本身看成一个终端,并不考虑车内子系统和功能域。


telematics从系统实现角度分为三类:

· ce telematics:单纯依靠消费电子移动设备(如手机app)实现车联网功能和应用,如滴滴打车

· embedded telematics:依靠车载嵌入式系统和车载通信模块实现车联网功能和应用,如著名的e-call系统

· hybrid telematics:融合了车载嵌入式系统和移动设备实现更复杂的车联网功能和应用,如蓝牙obd模块和智能手机的配合


基于车云一体新架构的发展,对ota2.0定义的探讨(图1)


这是早年的telematics的需求范围,随着智能汽车的进一步发展,现阶段telematics这个概念稍微有点过时了,oem都开始搭建自己的os和自己的vehicle api。


ota从字面上解释是over-the-air,是指通信管道,也就是说任何车云一体的功能,只要是通过无线通信管道实现的,都是ota?显然不是的。这说明了ota这个概念从诞生之初,在工程领域就是很不严谨,或者说比telematics更加不严谨。


首先,ota无线通信的管道必须是ip移动网络,对智能设备来说,即便在一公里的接入点可以是wi-fi这种局域网,但是ota的服务后台是在广域网远端的。其次,ota不是指具体的车云一体的功能或者场景,应该指的是通过无线ip移动网络实现如软件升级,系统诊断这类的none-functional requirements。所以,不论是telematics还是ota,或者说国内提出的车联网或网联车,都不是工程上的严谨的定义。相比较而言,telematics的定义比较严谨,但是也已经过时了。


汽车ota =智能汽车软件升级?

汽车ota在作为卖点进行宣传的过程中,几乎是和车内智能系统的软件升级划等号的,而从工程定义角度,不能这么看。完成一次汽车ota软件升级,从车辆端一般至少有三个步骤,即:

· 从后台下载升级包(基于车内智能设备的数量,可能是多个升级包);

· 安全地刷写升级包到指定ecu的固件存储块;

· 通过如ecu重启等方式确认新版本刷写成功并回复后台。


如果考虑到ota后台的升级包部署、通知下发以及对所有车辆的ota状态监控等,可能有更多的步骤。所以,至少从上面三个车辆端的步骤可以看出来:

· 下载是一个ota行为,只占用网络带宽,并不对系统造成太多影响;

· 刷写是车辆端本地行为;

· 软件升级是否成功完成实际上需要靠ota诊断来判断。


所以从数据报文的类型角度,车端的ota需要和ota后台协商的实际上就是连续数据报文(升级包)和响应数据报文(诊断消息)两种。汽车ota,考虑到车辆端安全性要求,实际上更多的报文交互是ota诊断。


车载智能ecu角度fota、sota、dota如何细分?

iot业内对ota细分为fota(firmware ota升级)、sota(software ota升级)——基本上都要用到差分升级技术,以及dota(diagnostic-over-the-air)。对于一个单(mpu)核系统的嵌入式设备,更适合上述的细分方式,具体定义如下:


640 (1).jpg


其中,由于像android/linux这样的中间件和应用层软件相对占用存储空间巨大,如果是整个文件系统打包替换升级,需要的升级包下载时间也非常长,不满足ota升级的要求,所以sota升级一般来说都采用差分升级的方式。


我们回到车载智能ecu,不同于很多非汽车行业的iot设备,大量的车载ecu恰恰很少是这种单核linux/android系统,而是另外两类:

· 定制的车载mcu,无文件系统,只有固件

· mcu   mpu的复杂系统,并且由于汽车安全性等要求,mpu往往不允许主动升级,而是需要mcu对其进行复杂的状态控制和监管


并且,汽车的诊断有一套完全不同的规范,且和车内分布式网络信号相关。所以,似乎iot行业的fota、sota、dota的分类并不适合套用到车内ecu的ota升级和诊断方法。

 

车载智能ecu的形态更多的是这个样子的:


640 (2).jpg


其中高规格的mcu可以直接配置以太网接口,可以实现升级包的快速刷写,根据不同的系统要求,车载智能ecu的ota升级方式会有差异。目前域控制器和车内ecu分布式网络的形态还在迭代中,无法形成大一统的规范,使车内ota软件升级逻辑的设计和部署变得复杂且有挑战。


iot端设备和车载系统,ota需求的差异点

需求的差异点,应该是对ota升级的边缘管理的要求不同。简单讲,大量的单核系统iot端设备,由于芯片和硬件平台的共性非常强,所以边缘管理可以极致简化,简化到将ota master部署在iot端设备的芯片固件里,做到标准化;而且,由于iot设备成本要求敏感,易于维修替换,所以大量的iot端设备的ota升级是做到了系统自升级。


而车载系统则情况不同,维护召回条件苛刻,安全性要求很高,所以对车内多ecu进行ota升级,就必须开发ota master边缘管理模块,由该模块统一管理下载、解析、刷写和诊断。所以,很多iot行业的工程师很难理解汽车行业ota软件升级的需求,主要是对应汽车行业的安全性规范和售后管理机制不熟悉。


一个ota系统,车端、云端其实并不对等

谈到汽车ota系统或者车云系统,基本上汽车工程师都会画类似这样的图来描述整个系统:


基于车云一体新架构的发展,对ota2.0定义的探讨(图4)


实际上车端系统和云端系统,并不是对等的,一个ota云端系统要管理成千上万的车端系统。从车内逻辑出发,这样的ota系统框图没有问题,而从云端需求建设角度出发,ota云在这类架构图里更多的是被看成只是一些云接口,实现对车端ota的服务和响应,而不是真正的ota云。ota系统的云端需求、实现、测试验收,和ota系统的车端需求、实现、测试验收应该是完全分离的两个(甚至更多个)子项目,oem为了简化流程把ota当成一个系统或者一个功能来管理,已经越来越不能满足车云一体架构发展的要求。


汽车的应用和出行的体验,在越来越往云端转移,车端从一个纯粹的功能件,变成了一半功能一半容器的智能平台。我们从ota系统开始,可以尝试着打破传统的认知和管理模式。



将来的汽车ota应该是个服务接口


前面讲到,车云架构发展和建设的几个趋势,包括对ota在车载应用更加规范化和标准化的定义,车内新一代智能ecu子系统对ota软件升级提出了新的要求,整车架构的软件化和服务化,要求ota系统需要进行软硬模块的拆分等等。


我们不妨换一个角度思考,智能汽车1.0时代的ota,需要端到端的“快递”服务,可以将软件升级包通过无线移动网络下发到车辆,同时配合在整个软件升级过程中对车辆状态的监控,也需要基于ota进行远程诊断。智能汽车2.0时代的ota,仍然还是端到端的“快递”服务,只是“快递物”从软件升级包,变成了更多的内容,包括智能汽车的云端app在本地端的软件配置;智能传感器的云诊断和激活;配合云端ai的边缘算法优化;高精地图数据包等等。智能2.0要求的汽车ota“快递”必须做到精确、安全、私密、快速。将来ota既是一个服务接口,也是一个虚拟管道,更是车云一体出行系统不可或缺的“快递员”,对系统设计、规范标准化、测试等,都提出了更高的要求。 




关注怿星科技公众号,获取更多资讯


基于车云一体新架构的发展,对ota2.0定义的探讨(图5)


网站地图