摘要：OTA技术是指系统层级的远程升级技术，可以让汽车即便在已经离厂并且服役中的状态下，能通过互联网从远程进行系统升级，以达到功能更新、亦或是漏洞补救的目的。整车OTA，包含FOTA和SOTA两种OTA类型，二者均为车辆主机厂乃至飞机主机厂关注的重点方向。
1. 过去在汽车上如何实现OTA
对于整车OTA类型，主要分为两类，FOTA（Firmware-over-the-air）和SOTA（Software-over-the-air），两者均为主机厂重点关注及逐步落地的领域，可适应不同场景的OTA需求。
OTA可以理解为远程升级，最早是安卓系统在手机上推出的，终结了手机软件升级需要连接电脑、然后下载软件、再安装更新的繁复流程。目前已经成为车辆系统中一个重要的标配功能。
在油车时代，由于汽车是纯机械结构的，软件几乎不可能影响整车除了娱乐和导航领域以外的其他部分。在这种情况下，当我们希望载入新的导航地图包，甚至升级或修复一些娱乐功能时，都需要到4S店，让工作人员用专业电脑进行操作，这对我们在汽车的全生命周期持续提升其使用体验和价值很不利。
在电车时代，由于其结构相对简约，整车的动力系统、制动系统、电池管理系统等所有和车辆行驶有关系的系统基本都实现了电动化和软件定义，因此，使用软件改写汽车的运动能力，并持续增强驾驶体验，成为了可能。OTA技术就是助推这种能力出现的一个重要的技术基石。
如前文所述，整车的OTA有两种类型。其中，FOTA（Firmware-over-the-air）是指通过给车辆的控制器（ECU）下载完整固件，来实现系统整体能力的提升。需要通过FOTA升级或修复的系统功能包括：智驾系统、制动系统、主动防撞和车辆身份安全等较复杂的功能，这些功能的共有特点，包括：对车辆行驶能力影响较大，需要对汽车的多个领域和多个部件进行同步升级。特斯拉在刚刚推向市场是，曾与老牌豪车保时捷做过一次竞速比赛，在比赛中，特斯拉生产的Model S略微落后于保时捷的Turbo S，为了解决这一问题，特斯拉通过OTA技术将比赛用的Model S的峰值功率提升至50马力，一举反败为胜，这种汽车能力的提升效率，是基于传统机械结构开发汽车的厂商，所不能理解和实现的。
FOTA涉及控制器核心功能（控制策略）的一个完整的系统性更新，对整车性能影响较大，升级过程对时序、稳定性、安全性要求极高，而SOTA就没有这么高的要求了。SOTA（Software-over-the-air）通常指对车辆控制器中的一些软件模块进行增量更新，一般应用于导航和娱乐领域，例如更换多媒体播放器，调整车内灯光效果或是优化仪表板显示等等。SOTA涉及控制器应用层一个小范围的功能局部更新，对整车性能影响较小，升级前置条件要求较低。SOTA的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。
OTA技术相对简单，车厂大多采用基于AP AutoSAR架构平台搭载OTA功能。Autosar CP架构下，所有应用都是静态配置的，一旦软件编译完成就不可更改，其调用的周期也是确定。而在Autosar AP架构下，一切都是OS中的进程，应用是动态运行的，何时调用、进程生存周期、资源占用及进程结束等都由系统动态管理，这为实现OTA功能提供了前置条件。
如上图所示，在AP AutoSAR平台中，包管理主要借助UCM来实现，UCM可实现软件包的更新，安装和删除，并帮助我们管理软件包的依赖。
如上图所示，UCM包含UCM Master、UCM、车辆状态管理器和OTA Client几个主要部分，其各自的功能包括：
（1）UCM Master
为UCM提供服务接口的客户端，它从云端或诊断工具接收、验证、解析软件包，并将软件包传输至UCM或诊断应用程序进行后续激活、回滚等处理。
（2）UCM
为与UCM Master处于同一网络中的UCM服务实例。
（3）OTA Client
建立云端和UCM Master 之间的通信，以传输增量包的信息。
（4）车辆状态管理器
从多个车端ECU收集状态，并计算相应的安全状态，根据车辆包中的安全策略，在发生变化时通知UCM Master。如果不满足安全策略，UCM Master可采取相关措施，如通知用户当前不满足前置条件，同时推迟、暂停或取消更新。
一般的OTA过程为：
（1）打包升级包
（2）传输和校验升级包
（3）安装升级包
（4）激活升级包
（5）如遇异常则回滚升级包
2. 通过云边协同为设备OTA软件系统
实现设备的OTA功能，有两个要点：（1）提供一种便捷的安装包或更新包管理机制，可以为设备安全地动态远程部署安装包或更新包，并提供状态记录功能，以便在OTA失败后回滚。（2）设备的系统架构，支持某个或某些功能，以软件定义，且这些功能是模块化的，可互操作的。云边协同（主要以K8s和Kubeedge等云原生组件为基石）这一技术架构，可以很好地解决上述问题。
如上图所示，KubeEdge 建立在 Kubernetes 之上，将原生容器化应用程序编排和设备管理扩展到边缘主机。它由云部分和边缘部分组成，为网络、应用程序部署和云与边缘之间的元数据同步提供核心基础设施支持。它还支持 MQTT，使边缘设备能够通过边缘节点进行访问。
使用 KubeEdge，可以轻松获取和部署现有的复杂机器学习、图像识别、事件处理和其他高级应用程序到边缘。通过在边缘运行业务逻辑，可以在数据生成的地方本地保护和处理大量数据。通过在边缘处理数据，响应能力显著提高，数据隐私得到保护。其在云端和边端的组成和能力分别为：
（1）在云端
lCloudHub：websocket server，负责监视云端的变化、缓存和向 EdgeHub 发送消息。
lEdgeController：一个扩展的 kubernetes 控制器，用于管理边缘节点和 pod 元数据，以便将数据定位到特定的边缘节点。
lDeviceController：一个扩展的 kubernetes 控制器，用于管理设备，以便设备元数据/状态数据可以在边缘和云之间同步。
（2）在边缘
lEdgeHub：websocket server，负责与云服务交互以进行边缘计算（如 KubeEdge 架构中的 Edge Controller）。这包括将云端资源更新同步到边缘，并将边缘端主机和设备状态更改报告给云。
lEdged：在边缘节点上运行并管理容器化应用程序的代理。
lEventBus：一个 MQTT 客户端，用于与 MQTT 服务器（mosquitto）交互，为其他组件提供发布和订阅功能。
lServiceBus：用于与 HTTP 服务器交互的 HTTP 客户端（REST），为云组件提供 HTTP 客户端功能，以访问在边缘运行的 HTTP 服务器。
lDeviceTwin：负责存储设备状态并将设备状态同步到云。它还为应用程序提供查询接口。
lMetaManager：边缘和边缘中心之间的消息处理器。它还负责将元数据存储到轻量级数据库（SQLite）/从轻量级数据库（SQLite）检索元数据。
近日，在CNCF举办的云原生会议上，报道了某OEM打造的车云协同案例，通过KubeEdge这一轻量化的框架，将汽车作为节点接入云端，由云端动态管理节点上的服务。
该架构引入了容器化技术，将功能与底层软件完全解耦，容器中承载的功能包括智能座舱、远程协作、机器学习、自动驾驶等高存储高算力的业务。实现后能为将来的第三方开发平台打下基础，可构建丰富的车辆功能生态，软件可售业务也可基于此实现。更重要的是，车辆可改变仅通过FOTA实现功能迭代变革的现状，通过该框架，或许能够实现不停车升级，节约用户的时间成本。
灵泽智能同样也提供了面向无人机机载任务计算机的全套解决方案，标配基于云边协同的无人机算法能力的OTA功能，可为用户提供开箱即用的智能蜂群边缘端分布式任务系统解决方案。使用灵泽智能的方案，可使用户的产品更快推向市场，后续通过OTA能力不断迭代和优化用户体验，还可借助灵泽的云商场系统运营周边生态。
总结：OTA技术的落地，不仅仅需要成熟的自动运维和部署技术做支撑，还需要车机或机载各个领域的硬件和软件的接口和数据模型足够开放和规范，需要各个领域的硬件和软件的生态和运营足够成熟，这需要主机、技术供应商和子系统供应商们的共同努力。