新闻中心

News

基于车云一体新架构的发展,对OTA2.0定义的探讨


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


Telematics和OTA的区别


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


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


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

  1. CE Telematics:单纯依靠消费电子移动设备(如手机APP)实现车联网功能和应用,如滴滴打车

  2. Embedded Telematics:依靠车载嵌入式系统和车载通信模块实现车联网功能和应用,如最著名的e-Call系统

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


图片1.png.jpg


这是早年的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软件升级,从车辆端一般至少有三个步骤,即:

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

  2. 安全地刷写升级包到指定ECU的固件存储块;

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


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

  1. 下载是一个非常独立的OTA行为,只占用网络带宽,并不对系统造成太多影响;

  2. 刷写是车辆端本地行为;

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


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


车载智能ECU角度FOTA、SOTA、DOTA如何细分?


IoT业内对OTA细分为FOTA(Firmware OTA升级)、SOTA(Software OTA升级)——基本上都要用到差分升级技术,以及DOTA(Diagnostic-Over-the-Air)。对于一个单(MPU)核系统的嵌入式设备,更适合上述的细分方式,具体定义如下:


图片2.jpg


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


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

  • 定制的车载MCU,无文件系统,只有固件

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


并且,汽车的诊断有一套完全不同的规范,且和车内分布式网络信号相关。所以,似乎IoT行业的FOTA、SOTA、DOTA的分类并不适合套用到车内ECU的OTA升级和诊断方法。

 

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


图片3.jpg


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


IoT端设备和车载系统,OTA需求的差异点


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


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


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


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


图片4.jpg


实际上车端系统和云端系统,并不是对等的,一个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既是一个服务接口,也是一个虚拟管道,更是车云一体出行系统不可或缺的“快递员”,对系统设计、规范标准化、测试等,都提出了更高的要求。