OTA2.0：基于车云一体新架构的探讨.docVIP

OTA2.0：基于车云一体新架构的探讨 Telematics和OTA的区别 汽车Telematics的概念出现已经有快20年了，OTA概念在手机行业的出现稍晚一些，辐射到汽车行业是最近5年的事情。同样是基于移动数据网络作为通信管道，实现车辆终端和服务器后台的交互，表面上好像都是车云一体的场景，而实际上这两个概念对车联网系统的描述维度是不一样的。 Telematics是一个创造出来的单词，指的就是汽车和服务后台（TSP）通过移动网络的数据交互实现信息化的功能。最初的Telematics定义，将车辆本身看成一个终端，并不考虑车内子系统和功能域。 Telematics从系统实现角度分为三类： CE Telematics：单纯依靠消费电子移动设备（如手机APP）实现车联网功能和应用，如滴滴打车。 Embedded Telematics：依靠车载嵌入式系统和车载通信模块实现车联网功能和应用，如最著名的e-Call系统。 Hybrid Telematics：融合了车载嵌入式系统和移动设备实现更复杂的车联网功能和应用，如蓝牙OBD模块和智能手机的配合。 这是早年的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诊断。 FOTA、SOTA、DOTA如何细分 IoT业内对OTA细分为FOTA，Firmware OTA升级；SOTA，Software OTA升级，基本上都要用到差分升级技术；以及DOTA，Diagnostic-Over-the-Air。对于一个单（MPU）核系统的嵌入式设备，更适合上述的细分方式，具体定义如下： 其中，由于像Android/Linux这样的中间件和应用层软件相对占用存储空间巨大，如果是整个文件系统打包替换升级，需要的升级包下载时间也非常长，不满足OTA升级的要求，所以SOTA升级一般来说都采用差分升级的方式。 我们回到车载智能ECU，不同于很多非汽车行业的IoT设备，大量的车载ECU恰恰很少是这种单核Linux/Android系统，而是另外两类： 1、定制的车载MCU，无文件系统，只有固件 2、MCU + MPU的复杂系统，并且由于汽车安全性等要求，MPU往往不允许主动升级，而是需要MCU对其进行复杂的状态控制和监管。 并且，汽车的诊断有一套完全不同的规范，且和车内分布式网络信号相关。 所以，似乎IoT行业的FOTA、SOTA、DOTA的分类并不适合套用到车内ECU的OTA升级和诊断方法。 车载智能ECU的形态更多的是这个样子的： 其中高规格的MCU可以直接配置以太网接口，可以实现升级包的快速刷写；根据不同的系统要求，车载智能ECU的OTA升级方式会有差异；目前域控制器和车内ECU分布式网络的形态还在迭代中，无法形成