下一代OTA的挑战与解决方案-电子发烧友网

OTA是智能汽车的核心能力之一，是车辆常用常新、千车千面的基石。随着集中化EEA架构和SOA软件架构逐渐成熟走向市场，OTA技术也从单一的软件更新演进到融合OEM研发、生产、售后、市场反馈等多个系统及环节，以提供覆盖整车全生命周期管理、智能制造、智能售后、数据闭环等众多应用。下一代OTA在更高效、安全、精准、自动化地将新功能部署到目标车辆上同时，可有效降低整车生产、拥有成本，更能够通过持续的低成本高精数据采集，来开发、验证最新的应用，提高客户粘性，成为整车DevOps的核心通道。

下一代OTA的驱动力

下一代OTA的挑战与需求主要来自三方面：

集中化的EEA架构

与DevOps的集成

基于OTA的新的场景需求

除了传统的执行器和传感器ECU，集中化的EEA架构引入了以Ethernet为主干网的多元网络，及域控制器或者HPC+区控制器架构的多个功能强大的硬件。这些HPC或者域控制器都是多uP+uC架构，uP也是多核异构架构。不仅仅在HPC或者域控制器内部有复杂软件版本的依赖关系，跨域之间及和传统ECU之间的关系更为纷繁复杂。并且它们的升级包常常多达数GB，甚至几十GB，升级时间更长，迫切需要新的升级协议及升级机制支持，以提高刷写的可靠性与效率。在新能源车领域，除了OTA过程中的车辆安全管理及升级失败回滚机制外，还会涉及到高低压电源管理。在确保OTA的成功率同时，还会设置多个不同的电源模式，以适应不同的用户场景，以提高电量使用效率，提高用户满意度。

DevOps是在大规模复杂软件领域广泛使用的一个方法论。在引入智能汽车软件行业，与OTA结合时，有其特殊的复杂性。特别是对一些头部OEM来说，他们拥有不同平台，不同动力类型、不同国家、不同配置、不同供应商零配件、不同应用场景的软硬件配置需求，再加上下文要提到的SOTA，容器化化更新技术，让不同的车辆拥有了千车千面的可能性，可对车主提供高度个性化服务，但是同时对于每辆车的软件及数据管理也是一项新的巨大挑战。在面向全球百万量级的车辆，在市场上经过一定时间更新迭代后，实时动态地管理车辆配置，并精准地匹配目标软件版本，会是一个极其复杂的难题。千头万绪的整车软件组件之间依赖性管理，会让一挑战更为艰巨。如果此时还是靠当前人工管理车辆，组建升级包，监控、管理升级任务，以实现软件的精准、按时交付，基本是一个不可能完成的任务。我们看到越来越多的整车厂面临着这样的问题。

随着整车厂SDV.OS的成熟，作为与车辆保持始终在线的SOP后车辆运营通道，整车厂对OTA有了越来越多的期待。除了传统的软件更新，整车厂希望能够把OTA平台的应用场景进一步拓展到生产、售后、终端用户场景需求采集与反馈、应用市场等多个方面。并且能够以低成本、高效、灵活、快速地实现生产降本，售后增效，新场景有用户量且持续迭代。为此下一代OTA平台除了集成智慧工厂、远程诊断外，还亟需数据闭环、大数据云平台及应用商店等功能，以实现有粘性的用户应用，提高用户满意度，实现持续营收。

下一代OTA的架构

下一代OTA解决方案包含云端 (Off-board)，车端(Onboard)两部分。

除了较为常见的云端OTA车辆管理、权限管理、设备管理、OTA Campaign管理，车端的信令交互，升级包下载，解压，解密，升级主控，升级代理外，下文将着重介绍为解决上述挑战的一些新技术与方案。

VLCS 整车全生命周期配置系统

VLCS（Vehicle Lifecycle Configuration System）是一套整车全生命周期配置（包括硬件，软件，数据）管理系统及基于该系统高精准，自动化的软件交付系统。VLCS面向下一代集中化EEA和SOA架构的整车软件升级及管理、集成了整车厂的研发，生产，售后，市场，终端客户等多个管理系统，有机地融合到DevOps环境，让每辆车全生命周期阶段的所有软硬件配置变更都在环内追溯，在软件持续交付的同时，构成一车一档案。同时在VLCS内可以集成软件批准，软件发布控制，软件依赖管理，软件合并更新管理等核心组件。不仅为车辆的软件管理，故障横向对比排除提供了有力的数据支撑，同时也为高精准的自动化软件匹配，交付提供了基础。

在VLCS系统内提供两种自动化、高精度软件匹配交付机制。一种是在传统的人工手动组包，发起更新活动的基础上，基于前述的VLCS核心能力，实现的自动化组包更新，从而避免大量重复人工操作，以及由此引发的失误。在VLCS系统中软件批准，及经软件发布流程验证成功后，进行软件依赖项及软件合并升级配置。系统会自动生成差分包，自动组包，自动加密签名，自动发起升级活动并自动生成升级报告。基于该系统也可以支持整车厂应用商店客户在线订阅功能，能够自动触发针对该客户的个性化升级活动。

另一种是面向未来SDV场景，更为灵活、高效的软件交付策略，以实现针对不同应用场景（私家车，租出，车队），不同用户，不同时间（短期订阅功能），地点（国家，路况）来安装或者激活对应功能，做到软件可售、提升服务体验。在该策略下，云端根据车端上报的车辆状态及用户信息计算目标车辆需要达到的功能状态，并将计算结果下发到车辆。由车辆根据计算结果决定分别下载哪些升级包或者激活哪些功能，并执行相关操作，以尽快达到终端用户所期待状态。而不需要OTA运维工作人员在云端组包以及发起更新活动，从而进一步降低人工干预的工作，提高交付精度和效率。

面向SDV.OS的差分更新、SOTA及容器化更新

车端ECU的安全、高效、友好的OTA更新策略是终端用户最能直观感受到的OTA本身功能。端到端网络安全（Security），不同用车场景下的车辆安全（Safty）升级机制是下一代OTA功能的基本保障，这些需要对不同国家的法律法规，整车电子电器架构有系统深入的理解。同时，针对车端丰富多样的ECU类型，需要全面支持在新一代EEA架构下的各种车内升级包分发升级协议，如UDS on CAN / DoIP / Some/IP/DDS/定制协议等，也可支持多域控下的并行下载、域内分发、并行刷写、多分区刷写等机制。为了进一步提高更新效率，降低软件更新时间，面向SDV.OS，OTA需要在差分更新、SOTA及容器化更新等多方面进行行业领先的探索。

差分更新

差分更新组件分为云端差分生成工具及车端还原组件。主要是为了降低域控制器或者HPC等智能件的升级包大小，以降低网络传输时长及网络流量。这些智能件通常带一个或者多个操作作系统，如Linux、Android、QNX等。待更新的软件及数据包通常能够达到数GB，在云端经过差分工具利用专有差分算法识别提取新旧软件的差异，并压缩后制作出一个差分包。实测场景下能够做到原包的5%，甚至2%以下。在车端完成差分包下载后，差分还原组件可以在车辆正常工作情况下，结合车端原有旧版软件及差分软件包执行升级包还原操作，之后进行软件升级刷写。差分更新也需要支持传统嵌入式ECU差分升级。主要是为了降低升级包在车内CAN总线上分发的时间，实测场景下能够降低CAN总线传输时长70%~90%。ETAS差分工具已集成在OTA平台中应用在多个量产项目中，也可以作为单独组件集成在整车厂的工具链或者云端后台。

基于Autosar AP的SOTA

我们在座舱域Andriod环境下，已经看到一部分软件可以类似我们使用的手机中的应用一样，可以在“应用市场”种下载和安装，而不需要进行整车的OTA升级，提供接近消费电子的使用体验。目前这些应用主要还是集中在日常手机生态中。在SDV.OS环境下，将涌现大量与汽车功能属性密切相关的应用，如智驾域，车身域、底盘域、动力域，以及跨域的功能应用等。Autosar AP UCM组件就是提供类似应用升级服务的，它可以支持软件级别的升级功能。

下一代OTA方案与Autosar AP集成，提供端到端SOTA解决方案。UCM Client是一个特定于项目的自适应应用程序，用作与更新Machine的单点交互。其具有以下组件：

**UCM Master: **UCM Master具有多重职责，主要负责检索Machine上软件包的当前状态信息，与UCM sub ordinates进行通信，并将适当的软件包传输给UCM。以组织更新。它可以通过使用通信管理的服务来寻址不同Machine上的UCM subordinates。

OTA Client:此客户端处理软件包从远程存储库转移到Machine上的过程。

**Diagnostic Client: **此客户端与诊断管理器通信，以利用诊断管理功能组织更新。

在Machine上安装、更新或删除的软件包的接收由UCM Master负责, UCM Client负责处理跨多台机器的更新协调, UCM client获取关于AUTOSAR自适应平台软件的信息，并通过使用UCM API传输和处理软件包来执行更新过程。

ETAS OTA 方案

容器化更新

容器化是在SDV.OS发展趋势下，从ICT行业引入到汽车行业的又一个“泊来”品。其有助于开发人员更快地创建和部署应用程序，无论是在训练过程中还是在运行时，尤其在诸如ADAS、手势识别、语音识别、面部识别等功能的AI/ML模型中非常常见。它提供了更高的可移植性、灵活性，并让应用程序更接近“编写一次，随处运行”的期望状态，可以在多个硬件上灵活运行。容器化应用程序不会捆绑操作系统的副本，它们在真正的意义上是“隔离”的。因此容器化更新在应对多个版本和配置管理挑战，以及管理应用程序和中间件组件的依赖关系，容器可以发挥重要作用。这与其在IT和云环境中变得流行的原因基本相同。

SDV.OS下的车辆功能将是微服务、软件应用程序、ML/AI模型等的组合，将这些不同的部分打包成容器集，作为单个单元推送到不同车辆上。虽然云端的容器现在已成为事实上的标准，但要应用到智能汽车领域，形成车云一体化的架构，也有其独特的复杂性。

OTA的增值场景应用

以ETAS的下一代OTA方案为例，进一步把OTA的应用向生成、售后、终端用户场景需求采集与反馈、应用市场等多个方面延申。提供远程诊断，智能诊断，智能工厂，数据闭环等服务。

远程诊断

ETAS整合了传统的诊断业务和功能，实现了从传统诊断到远程诊断。基于传统诊断的知识积累和工具集合，重新定义了车端诊断的运行环境。使用诊断开发的IDE工具GRADE-X Authoring，通过拖拉拽的操作，用所见即所得的方式编辑诊断序列，编辑的诊断包支持ISO国际标准ODX和OTX协议。

该方案有如下几个优点：

1.整合博世传统诊断业务能力，在车端提供集成诊断的运行环境。实现不依赖传统诊断设备连接车辆，执行诊断指令。

2.支持ODX与OTX标准的可视化编辑工具。实现一次编辑，到处执行的能力。

3.多年的车载诊断经验，具备了诊断数据分析的能力。

目前已经有多个国内落地的项目经验：例如工厂EOL，OTA和诊断赋能OEM在产线电检环节替代传统的诊断设备，进行产线电检和刷写，不仅节省了产线设备同时还提高了产线的诊断效率。

远程诊断主要有如下几个应用场景：

1.故障诊断：远程诊断技术可以实时监测车辆的运行数据和故障信息，提供精准的故障诊断和解决方案。

2.预防性维护：远程诊断技术可以通过分析车辆的运行数据，提前预判潜在故障，并提供相应的维护建议，避免故障的发生。

3.远程协助：远程诊断技术可以通过视频会议、远程协助等方式，为维修服务提供商提供远程技术支持，提高维修服务的效率和减少维修成本。

4.车辆健康管理：远程诊断技术可以实现对车辆的健康状况进行实时监测和分析，为车主提供个性化的驾驶建议和维护建议，提高车辆的使用寿命和安全性。

数据闭环

车辆量产上市后，会面临车辆的维护，既有功能的持续迭代，新应用场景的挖掘、开发与验证。以实现对终端用户有意义和粘性的千车千面应用，这才是SDV的终极意义。这些需求都涉及到量产后围绕车辆不同类型数据的持续采集。

如车辆的维护，远程诊断能够解决一定的问题，但是当我们需要定位问题的根因时，往往靠远程诊断采集的数据类型和数据量远远不够，特别是对一些偶发、难以复现的故障排查，整车厂花费了大力的精力和财力在这方面。再比如自动驾驶算法corner case的持续收集与算法迭代，针对不同用户群的各种潜在应用场景挖掘及推向市场后的反馈等，这些都需要收集不同类型的数据，并且采集的信号类型和频率都可能会因不同部门，不同目的，不同场景的具体需求而异。同时显然车辆的无线通道带宽是有限的，数据流量及存储的费用也不菲，整车厂只对高价值区间的数据感兴趣。

ETAS的下一代OTA还推出了数据闭环解决方案。该方案的目标是动态、灵活地采集整车高精度数据，包括：

·全车总线数据，包括CAN/CAN FD，以太网等

·诊断数据

·ECU内部标定数据

·域控制器或者HPC的中间件数据

·传统嵌入式ECU内部有业务价值的数据（与硬件部门合作）

在云端可以动态配置所采集信号类型及频率，设置数据触发上传逻辑及采集时间段，并将任务发送到车端。由车端边缘引擎负责解析执行，获取到目标价值数据后，经压缩上传到云端。基于云端的大数据平台可以进行故障分析、软件迭代、新的应用挖掘与验证等服务。