OTA云平台架构及关键技术

OTA 技术最早应用在 PC 电脑和移动手机行业，近几年才开始在汽车行业中 广泛应用。然而车内通讯网络的复杂性、汽车电子系统的碎片化等因素限制着 OTA 技术整车范围普及。本章从 OTA 定义与应用场景、OTA 实现流程和“云-管-端”关键技术进行研究，为行业从业者对 OTA 技术的设计开发、技术验证和生产工作提供参考。

一、汽车 OTA 定义与应用场景

1.1  OTA 定义及分类

OTA 是 Over the Air 的缩写，通常指的是远程无线方式，OTA 技术可以理解为一种远程无线升级技术。在无特别说明情况下，本文所指的 OTA 是所有汽车远程升级的统称。实现 OTA 的基础是车辆具备远程联网功能，这意味着正是智能网联汽车渗透率的快速增长，推动了 OTA 的快速普及。

OTA 的本质是通过技术实现软件更新，智能网联汽车与传统汽车的软件升级不同之处在于，通过 OTA 技术，原始设备制造商（OEM）可以不用通过售后服务中心，而是直接远程连接目标联网车辆，将软件更新推动至待升级的车辆。

随着 OTA 的应用越来越广泛，针对升级对象的不同，延伸出来很多不同的 概念。人们在谈及 OTA 相关业务时通常会在前面增加一个具体对象，用于表明使用 OTA 技术实现何种功能，比如远程软件升级、远程固件升级、远程配置、远程数据更新等。然而在一些 OTA 解决方案中，已经模糊了不同类型远程升级的边界，将所有可升级的软件对象抽象为软件簇，而软件簇包含了从小到配置字信息大到整个操作系统固件所有颗粒度的对象。并且，GB《汽车软件升级通用 技术要求》中对软件升级（Software Update）的定义已经涵盖了下述几种 OTA 概念（远程诊断除外）。

1.1.1  远程软件升级(SOTA)

SOTA（Software Over-The-Air），即远程软件升级，是指在操作系统的基础上对应用程序进行远程升级。SOTA 通过远程下载并给车辆安装“应用程序升级包”，来实现控制器功能的一个“增量”更新， 一般应用于娱乐系统和智驾系统。

SOTA 一般涉及应用层小范围的功能局部更新，不包括汽车核心系统，对整 车性能和安全影响较小，升级前置条件要求较低。SOTA 的增量更新策略， 可以大幅减小升级包文件大小、从而节约网络流量和存储空间。

1.1.2  远程固件升级(FOTA)

FOTA（Firmware Over-The-Air），即远程固件升级，是指囊括车辆底层算法至顶层应用的综合升级，在不改变车辆原有配件的前提下，通过远程下载并写入新的固件程序进行设备升级。FOTA 包括驱动、系统、功能、应用等的升级，与硬件的更换没有关系。

FOTA 涉及车辆的核心系统，包括但不限于汽车动力控制系统、底盘电子系 统、自动驾驶系统、车身控制系统等核心零部件的控制系统，可以改变车辆的充放电、动能回收、加速性能、辅助驾驶系统逻辑等与深度驾控有关的体验。理论上所有支持固件更新的电子控制单元（ECU）都可以涵盖在 FOTA 范围中。

1.1.3  远程配置(COTA)

COTA（Configuration Over-The-Air），即远程配置，是指通过 OTA 的方式实现远程修改配置字，以达到修改软件功能配置的目的。配置字是一组以数据标识码(DID)方式存储在 ECU 上的数据，可通过诊断指令进行读取和修改。它根据特定的编码规则与车辆功能特征码一一对应，通过配置可判断车辆的功能配置，软件可根据配置实现相应的功能。远程配置常见的应用场景是远程开启和关闭某项功能，例如软件订阅功能。

1.1.4  远程诊断/远程数据更新(DOTA)

DOTA 有两种常见解释：

DOTA(Data Over-The-Air)，即远程数据更新，是指一些独立于软件程序存在的数据包的更新，比如，地图数据、语音数据和算法模型数据等。这类更新的特点是数据量比较大，更新流程相对独立，比如，地图数据通常由地图应用自行更新，而数据量也可能高达几 G 到几十G。

DOTA(Diagnostic Over-The-Air)，即远程诊断，通过云平台实时数据采集监控，主动性地检查汽车系统异常问题，为远程问题修复与人工问题修复提供决策依据。远程诊断的触发方式有两种，一种是用户在车辆上发现异常状况的响应式；另一种是周期性收集通讯网络、应用程序、硬件效能、使用操作记录、系统程序等状态信息，利用大数据后台分析监测故障。

1.1.5  其他类型(XOTA)

随着汽车智能化程度越来越高，除了车辆本身软件的升级外，还可能会涉及 到外部智能设备交互功能的软件更新，比如，智能钥匙、AR 设备等。目前有些企业和组织将所有与车辆相关联的软件升级统称为 XOTA，即 Everything Over-The-Air 的意思。

1.2 OTA 应用场景

1.2.1 车辆生命周期维度

从开发者编译生产出目标版本软件，到该软件更新至目标硬件设备上的全过 程涉及多个阶段。在不同的阶段，受产品形态和生产环境限制，所适用的软件更新目的和手段也有所不同，如下表 2- 1 所示。目前，大部分车企的 OTA 主要集中在售后软件更新，但不论是从效率上还是成本上 OTA 都体现出了巨大的优势。随着 OTA 应用越来越成熟，从单一的售后升级场景向更多的应用场景发展是的必然趋势。

表 2-1  车辆生命周期维度的软件更新应用

1.2.2  软件运营管理维度

从软件运营管理的维度 OTA 的典型应用场景如下表 2-2 所示。

表 2-2  软件运营管理维度的软件更新典型应用场景

二、 汽车 OTA 技术体系   

2.1  OTA 实现流程

汽车软件更新的本质是将供应商或者 OEM 内部开发部门编译出来的软件或 者数据替换当前车辆 ECU 中的版本，以实现预期的特定功能。因此，汽车软件升级所需要的核心工作是建立远程传输链路并实现 OEM 云端系统远程更新车辆 ECU 中的软件数据。同时，为了准确、安全、可靠地完成 ECU 软件的更新，OTA 系统需要云端管理系统对软件、升级对象进行管理，以实现人工操作到自动化的转变；车端系统需要完成软件数据的接收和分发工作，并保证无专业技师操作情况下的安全升级。 

图 2-1：OTA 实现流程(来源 AutoSAR)    

图2-1 是一个典型的 OTA 系统框架，包含了三个基本要素，即云端的 OTA 平台、车端 OTA 主控、OTA 对象。其中：OTA 云平台负责 OTA 升级包管理、车辆管理及 OTA 发布等功能，车端 OTA 主控负责从 OTA 云平台下载升级包并将其刷写到目标 ECU ，OTA 升级对象即最终软件刷写的主体，从主控接收软件并完成自身软件更新。OTA 的基本实现流程（图2-1）可归纳为下表 2-3 所示步骤。

表 2-3  OTA 的基本实现流程

2.2  OTA 云平台架构及关键技术    

OTA 云平台是支撑 OTA 业务正常运行的相关云端系统的集合，既包括实现 OTA 核心功能的 OTA 服务端，也包括了其他关联系统如企业 IT 管理系统、安全服务端、web 控制台以及文件服务端。OTA 云平台业务范围涉及软硬件生命周期管理、业务流程整合、软件远程分发等软件更新所有相关业务，是一个软件升级管理体系(SUMS)。

2.2.1  云平台架构

基于 OTA 产品业务形态，结合系统组件之间松耦合高内聚的标准，行业内 普遍将云平台设计为 4 层的分层架构型式，如图 2-2 所示，包括前端展示层、路由网关层、业务服务层和数据存储层。前端展示层是系统与用户交互的 web 应用层，用户访问和操作云平台系统的交互接口；网关路由层包括指令控制层和网关接入层，是云平台与车端建立通信链接以及控制车端流程的通信中间件；业务服务层负责所有 OTA 相关业务逻辑的处理，包括车辆、软件包管理、策略管理等诸多业务模块，是 OTA 云平台的核心；数据存储层负责 OTA 所有业务相关数据存储，包括基本的数据库集群数据缓存和大文件存储等。

图 2-2  OTA 云服务框架图

（1） 前端展示层

前端展示层的划分，是基于前后端分离开发方式设计的架构分层模式，主要 负责 Web 端用户交互页面的功能。核心思想是前端页面通过调用后端的接口并进行交互，前端专注于交互页面的开发，业务逻辑由后端负责。对 OTA 云平台而言，前端展示层可以理解为业务服务层的用户交互接口，其展示功能与具体业务功能一一对应。

（2） 指令控制层

各业务平台与网关接入层的连通介质，接收来自业务系统指令并将指令发送 至网关可访问的缓存中，接收来自网关回写的升级状态至各业务系统可访问的消息队列中。

（3） 网关接入层

针对不同的数据格式及上层需求，接收封装来自车载终端传输的数据，并流

向缓存、消息队列等中间件。

（4）业务服务层

业务服务层是 OTA 服务所有业务及相关流程管理功能在云平台端的实现， 除了车辆管理服务、软件包服务、版本服务、策略管理和任务管理 5 个支撑 OTA 的核心功能外，还包括关联系统审批、数据对接、信息安全服务、测试、统计分析、日志查询等重要辅助功能。由于不同的企业内部管理存在差异，云平台所支持的辅助业务可能存在较大差异，常见服务列举见表 2-4。

表 2-4 常见服务举例

（5） PKI 系统

公钥基础设施（Public Key Infrastructure，PKI）：基于公钥密码体制实现数字证书的发布、撤销和管理等功能，并为数字证书用户提供相应服务的系统。其目的在于创造、管理、分配、使用、存储以及撤销数字证书，可以用来保证通信对象的身份真实性、软件程序的来源真实性和完整性、通信行为的不可否认性等。

PKI 在 OTA 系统中的作用主要在于为相关实体发放数字证书，通过密码技术保证升级包和升级过程的安全。主要包括车辆证书、设备证书、供应商证书等 的申请和校验；云端对车端身份认证，车端对云端身份认证；升级包的安全认证等。

（6）外部数据系统

外部数据对接的系统可能包括整车生命周期配置系统（VLCS）、远程诊断系 统、软件可售系统及一些其他支撑系统组成。主机厂研发部门需要根据车型的功能规划确定该车型所对应的软硬件相关配置。需要进行软件更新时， 从 VLCS 系统中确定所涉及的车型和影响的功能范围，并依据确定好的范围， 从物料信息管理系统(BOM)中申请软件物料号作为版本控制依据， 供应商软件释放后经由产品生命周期管理系统（PLM）系统通过验证审批后流转到 OTA 服务端供升级使用使用。OTA 服务端管理设备中初始的车辆信息，可通过对接 MES 在车辆下线检验合格后将新生产车辆自动注册到 OTA 云平台，所有升级目标车辆应保证是已 注册车辆。除此之外，根据实际需要还可能会从汽车经销商管理系统（DMS）系 统获取经销商及售后服务站点信息，售后系统通常也需要与 OTA 系统关联以同步最新版本信息以及线下配置更改信息等。

另外， OTA 系统在升级前可通过远程诊断系统获得最新的 ECU 配置信息及 状态信息，并且当远程诊断系统发现问题后，可以通过 OTA 系统下发经过测试验证的补丁包来修复。对于一些有运营需求的主机厂来说，通过 OTA 系统配合软件可售系统，可以实现软件付费升级、功能付费使用等后向运营，真正实现“千车千面”、“用户定义汽车”。

（7）数据存储层

数据存储层包括数据库集群、缓存和存储节点，分别用于存储 OTA 云平台 不同类型的数据。其中，数据库集群，主要用于存储车辆信息版本信息等关系型数据；缓存，为了解决数据库性能瓶颈问题，可以通过多架设一层缓存层来减少对数据库的直接访问；存储节点，针对较大的升级包、配置文件等需要提供车端下载的文件，通常可以存储在分布式存储节点上。

2.2.2  关键技术

（1）安全技术

OTA 服务端以及企业 IT 管理系统、安全服务端、web 控制台、文件服务端 等关联系统，会面临传统云平台的所有安全威胁。为保证 OTA 升级的安全性，常用安全技术如表 2-5 所示。   

表 2-5  OTA 云平台常用安全技术

（2） OTA 技术

OTA 系统常用升级技术如表 2-6 所示。

表 2-6  OTA 云平台常用升级技术

2.3  OTA 车载端架构及关键技术

2.3.1  车载端架构

OTA 车载端功能模块主要包括 2 大部分，即 OTA 主控和 OTA 对象，如图 2-3 所示。OTA 主控是车端 OTA 系统的核心，车端所有 OTA 业务逻辑均由主控实现，包括上报车辆信息、下载更新文件、升级包安装、车辆状态管理、人机交互等。

图 2-3  车载端功能模块(参考 AutoSAR UCM)

（1） OTA 主控功能模块

按照车载端的工作流程，车载端的功能模块包括：OTA 客户端负责与云端进 行数据交互；下载模块负责升级包下载及分发；升级管理模块负责升级过程的控制；升级代理负责执行软件刷写或者软件安装；人机交互模块负责升级信息提示、用户输入、升级过程的展示等，如表 2-7 所示。

表 2-7  OTA 主控功能模块