OTA 2.0：基于车云一体新架构的探讨

首语：

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

01

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的定义比较严谨，但是也已经过时了。

02

汽车OTA等不等于智能汽车软件升级？

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

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

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

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

如果考虑到OTA后台的升级包部署、通知下发以及对所有车辆的OTA状态监控等，可能有更多的步骤。所以，至少从上面三个车辆端的步骤可以看出来，1，下载是一个非常独立的OTA行为，只占用网络带宽，并不对系统造成太多影响；2，刷写是车辆端本地行为；3，软件升级是否成功完成实际上需要靠OTA诊断来判断。

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

03

车载智能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系统，而是另外两类：

1、定制的车载MCU，无文件系统，只有固件

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

并且，汽车的诊断有一套完全不同的规范，且和车内分布式网络信号相关。

所以，似乎IoT行业的FOTA、SOTA、DOTA的分类并不适合套用到车内ECU的OTA升级和诊断方法。

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

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

04

IoT端设备和车载系统

OTA需求的差异点

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

而车载系统则情况不同，维护召回条件苛刻，安全性要求很高，所以对车内多ECU进行OTA升级，就必须开发独立的OTA Master边缘管理模块，由该模块统一管理下载，解析，刷写和诊断。

所以，很多IoT行业的工程师很难理解汽车行业OTA软件升级的需求，主要是对应汽车行业的安全性规范和售后管理机制不熟悉。

05

一个OTA系统

车端、云端，其实并不对等

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

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

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

06

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

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

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