基于车云一体新架构的发展，对ota2.0定义的探讨-九游会j9官方网站

智能汽车时代，汽车ota是一个热点概念，也是汽车的一个卖点。作为一家汽车行业的工程服务公司，怿星科技和艾拉比智能合作，基于行业的新需求，电子架构的演进，以及车云一体的新应用场景的发展方向，一起来探讨一下如何更准确更严谨的定义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软件升级，从车辆端一般至少有三个步骤，即：

· 从后台下载升级包（基于车内智能设备的数量，可能是多个升级包）；

· 安全地刷写升级包到指定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）核系统的嵌入式设备，更适合上述的细分方式，具体定义如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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