接上一篇：详解汽车远程升级（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 主控功能模块

（2） OTA 主控部署方案

      由于车辆 E/E 架构的不同以及控制器升级方式的不同，功能模块的部署方式  也有所不同。在传统网关分布式架构下，按照 OTA 主控部署的位置不同，大致分为：远程信息处理控制单元（TCU/T-BOX）方案、车载信息娱乐系统（IVI） 方案、网关（GW）方案，如图 2-4 所示。前两种方案，由 TCU/IVI 来进行 ECU 的软件刷写，GW 仅作为路由实现数据的转发，刷写的链路比较长；后一种方案直接是由 GW 进行刷写，刷写链路较短，但是 GW 并不能直接联网，如果通过TCU/IVI 路由联网必须增加安全机制，或者由 TCU/IVI 下载升级包后再分发至网关。

图 2-4  传统的 OTA 主控部署方案[1]   

 

      传统网关分布式架构下，由于控制器分散以及层级很深，导致在实现 OTA  的过程中要进行多次的转发和透传，容易导致数据丢失，增加升级失败的概率。另外，需要在 OTA 主控内部对软件进行备份，以保证升级失败后，控制器可以被回滚。由于传统控制器的芯片 Flash 和 RAM 容量小，实现也比较困难。

      对高算力和大带宽数据传输的迫切需求和“软件定义汽车” 的理念驱动， 各家 车企逐步开始进行整车 E/E 架构的升级和变革，引入了“ 中央计算平台+区域控制 器”的中央集中式架构，整体 E/E 架构更加扁平化，有利于实现整车级的 OTA。中央控制器和域控制器之间采用的是以太网，数据传输能力增强；并且 SOA 架构使得域控制器之间的交互机制更加灵活。针对区域控制器的 OTA 主控部署方案如图 2-5 所示。可采用中央控制单元(CCU)作为升级主控，对于 ECU的刷写有两种方式：1)  区域控制器作为网关路由 UDS 报文，主控通过 UDS 升级区域控制器和该区域的所有传感器和执行器；2)区域控制器作为副主控，即升级主控先将该区域所有 ECU 的更新文件传输到区域控制中，由区域控器完整自身升级以及与其连接的执行器和传感器的刷写[1]。

图 2-5  区域控制器方案

          

（3） ECU 端架构方案

      车端 ECU 作为被升级对象， 在 OTA 系统中主要功能是按照一定的协议升级 主控接收目标版本数据，将目标版本数据写入都指定的存储区域中并引导运行新版本软件，从而实现自身软件的更新。按 ECU 芯片类型及运行软件的特性可分为普通 ECU 和智能 ECU，而不同的 ECU 类型根据其内存空间结构又可以分为单分区和双分区两类。针对两类 ECU 的两种不同分区方案，ECU 端的升级可以大致归类为 4 种方案，本小节将分别对其展开讨论。

          

      ①  普通 ECU 单分区（Bootloader）升级方案

      普通 ECU 由于存储空间有限，通常会采用流式刷写的方式进行升级，所谓流式刷写即先将目标刷写空间的数据擦除，然后传输数据的同时，ECU 将已接收的数据写入目的存储地址，通过这种方式可以省去存储升级包的内存空间。传统的 BootLoader 通过 UDS 协议刷写的方式就是典型的流式刷写。

      如图 2-6 所示，普通 ECU 单分区结构只有 BootLoader(启动引导程序)和应用程序分区。该类型 ECU 需要更新时，首先将 ECU 从当前运行的应用程序分区切 换至 BootLoader 运行，在 BootLoader 中将应用分区当前版本数据擦除后，再从升级主控接收新版本数据并写入应用程序分区，数据检验无误后重启 ECU 切换至应用分区即可运行新版本软件。

图  2-6 Bootloader 升级方案示意图

      这种方案缺陷非常明显， 由于只有一个应用分区，升级前需要擦除，导致升 级过程 ECU 功能无法使用，如果更新过程异常中断或者失败也会导致功能无法使用。另外，这类升级通常需要在车辆非运行状态下才能进行，在软件数量较大所需升级时间较长的情况下，对车辆低压电池供电，尤其对于燃油车挑战较大。

      由于这用方案具有对内存空间要求低、在 BootLoader 进行更新不受应用程 序干扰、实现简单等优势，目前现有升级解决方案中大部分普通 ECU 的更新仍采用这种方式。

          

      ② 普通 ECU 双分区（AB 分区）升级方案

      通过 AB 分区方案，为软件的运行版本和升级的目标版本分配不同的存储区，A 与 B 分区彼此为回滚，A 分区系统运作提供服务时，刷新 B 分区，待 B 分区软件刷写完成通过校验后，下次重启时载入 B 分区；若刷写错误或关联 ECU 刷新失败，则仍以 A 分区系统启动，从而提高升级的可靠性，最小化回滚所需的时间。

      对于 AB 升级，其实有三种实现方案：第 1 类基于硬件辅助的 A/B 交换方 案。该方案要求 ECU 内存足够，而且支持地址重映射，也就是当新版本软件刷写完成，通过更新映射地址来激活新版本软件，即新版本软件运行的入出地址不变；第 2 类与第 1 类的差别在于 ECU 硬件不支持地址重映射，激活新版本软件的入出地址会变化；第 3 类，基于外扩内存的 A/B 交换方案，该方案是需要额外的外扩内存，备份当前版本软件和旧版本软件，新版本软件会先刷写原先的旧版本软件空间，然后擦除 ECU 内存的当前版本软件， 刷写新版本软件，完成激活。

AB 升级方案示意图如图2-7 所示

图 2-7  AB 升级方案示意图

          

      ③ 智能 ECU 单分区升级方案

      智能 ECU 是指具有高性能处理器，可运行现代操作系统(如 Linux 、QNX、 Android 等)支持文件系统的控制器。这类控制器存储介质成本相对较低， 一般存储空间较为充足，通常不会采用流式刷写的方式进行升级，而是先将升级包保存到 ECU 本地存储，然后进行安装。智能 ECU 的升级通常采用私有协议，通过升级代理(update agent)接收 OTA 主控的升级包和控制命令，根据主控的指令使用 本地安装程序(Installer)完成升级包的安装。图 2-8 为智能 ECU 升级单分区方案和双分区方案的系统框架对比。

图 2-8  智能 ECU 升级方案示意图

      单分区方案通常包含主系统分区和更新子系统分区，以及用于存储升级包的 缓存区域。正常系统功能相关软件运行在主系统分区，更新子系统是一个最小功能系统仅用于实现软件安装功能。该方案软件更新流程：①系统正常运行在主系统分区，同升级代理从 OTA 主控接收升级包文件，并保存在升级包缓存区， ② 升级包接收完成后由进行解密、签名认证，③接收到 OTA 主控安装命令后，升级代理将 ECU 切换至更新子系统，在子系统中通过安装程序将升级包安装到主系统分区，替换分区中的旧版本软件， ④安装完成后系统重启切换到新的主分区软件版本。

     ④ 智能 ECU 双分区升级方案

      智能 ECU 双分区方案与单分区相似，双分区方案具有两个结构完全相同的 系统分区，两个分区都具备升级代理和安装程序的功能。系统默认运行在 A 系统分区，有新版本软件需要更新时，可以通过升级代理从 OTA 主控接收升级包，并直接通过安装程序将其安装到 B 系统分区中，整个更新过程不影响 ECU 正常功能使用。该方案软件更新流程：①系统正常运行在 A 系统分区，同升级代理从 OTA 主控接收升级包文件，并保存在升级包缓存区；②升级包接收完成后由进行解密、签名认证；③接收到 OTA 主控安装命令后，A 系统分区安装程序将缓存中的升级包安装到 B 系统分区；④收到 OTA 主控激活命令后将系统启动引导标志设置为 B 系统分区，⑤重启系统后切换运行 B 系统分区新安装的软件版本。

2.3.2  车载端关键技术       

（1） OTA 主控

      ① 电源管理：由于整车升级时间较长，且要确保车辆处于安全状态， 因此需要管理升级过 程中各个控制器的工作状态。如果车辆在熄火状态下升级，考虑到长时间的电池电量消耗，在升级之前要对车辆的现有电量进行检查，升级过程中需要设计电源管理策略对升级与不升级的控制器、耗电的电器件进行差异化管理。如果控制器由于不可控的意外导致升级异常，也应处于低功耗模式，降低对整车电量的消耗。

      ② 车辆控制：对于影响车辆安全的升级，整个升级过程需要保持在一种安全状态，因此， OTA 主控需要具备一定车辆功能控制能力，根据不同的升级类型，控制车辆的功能状态。

      ③ 异常处理：在 OTA 传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU 必须支持软件回滚、断点续传、丢失重传等处理机制。

          

（2）OTA 相关协议

      ① 标准协议：支持软件刷写和软件升级的标准过程，方便 OTA 的开发、测试和集成，如传统 ECU 支持 UDS 协议、AUTOSARAP 的 UCM。

      UDS，即统一诊断服务，主要用于车外诊断设备通过车辆诊断口连接车内总 线，并向控制器请求控制器内部信息或向控制器传输数据。FBL 规范定义了控制器要实现软件刷写所需遵循的软件架构，并且定义了刷写时需要使用哪些 UDS 服务，以及这些服务之间的顺序关系。使用这些 UDS 诊断服务，可以命令控制器擦除原有内存中的软件数据，接收新的软件数据并写入到内存，最终执行新的软件程序。传统 ECU 基本采用的都是基于 UDS 协议的软件刷写这种升级方式。

      AUTOSARAP ，即自适应平台，是由软件更新配置管理器（UCM）提供了处理软件更新请求的服务。UCM 负责在 AP 上更新，安装，删除和保留软件记录，实现了软件包管理，确保以安全可靠的方式更新或修改 AP 上的软件。UCM Master 提供了一种标准的平台解决方案，通过与多个 UCM 之间协调和分配车辆内的包，实现 AUTOSARAP 的软件更新。

      ② 私有协议：除了升级遵从标准协议的传统控制器，OTA 还需要支持智能 ECU 的升级。智能 ECU 通常带有操作系统并且自身具有升级能力，作为升级对象，需要从 OTA 主控模块或者云端获取升级包，并与 OTA 主控进行信息交互，实现升级的触发和升级信息的反馈。对于这部分升级所涉及到的升级包分发和升级控制，现在并没有统一的定义和标准，各家车企和供应商的实现方案也各异。

          

（3） ECU 端升级技术

      ① 差分升级：相对于整包升级，差分升级方案不仅可以节省 MCU 内部的资源空间、还可 以节省下载和升级过程中的功耗。从另一个角度说，通过将差分部分下发到设备保证了软件版本的安全性。差分升级的流程如表 2-8，图 2-9 、2-10 所示。

表 2-8  差分升级基本流程

      差分的实现方式主要有两种：基于文本文件的差分和基于二进制文件的差分， 其区分在于对比文件的差异，前者是基于逻辑上的，后者是基于物理上的。在升级时，通过与制作过程对应的还原工具，将差分包还原后写入到存储器中，保证写入后的内容与目标版本内容一致。

图 2-9 差分计算过程

      差分计算程序接收旧版本 v1.0 与新版本 v1.1 后生成差分升级包 v1.0-v1.1-update.patch。ECU 端从云端下载差分升级包v1.0-v1.1-update.patch 后，开始后续的差分还原操作。

图 2-10  差分还原过程

      差分还原算法输入参数为旧版本安装包 v1.0 与差分升级包 v1.0-v1.1- update.patch。通过差分还原算法处理后得到最新的完整升级包 v1.1 。ECU 端安装 v1.1 完整升级包实现升级目标。

      ② 安全启动：安全启动(Secure Boot)用于保证固件启动的代码受信任的安全保证机制，它 通过在引导加载过程中，对加载固件进行检验，从而防止加载和执行恶意代码。固件的每一步加载都经过数字签名认证，而每一步签名认证的根证书中的密钥需要与固化在芯片内部不可修改的签名密钥匹配，从而行成一个完整信任链。

      ③ 安全校验：ECU 端需要具备对所安装软件包进行完整性校验和真实性校验的能力，这要求 ECU 有能力对更新数据进行签名验证。传统的 ECU 刷写过程通常只通过循环冗余校验验证更新数据的完整性，而无法验证其真实性，存在被刷写非法软件的风险。

          

2.4  人机交互        

2.4.1  人机交互要素分析

      车端的人机交互主要体现在信息娱乐系统上，覆盖到 OTA 的整个过程，包括信息提示、用户确认、关键信息显示等。人机交互过程需要考虑的要素大致可以分为两个方面，即法规符合性和使用便利性，如表 2-8 所示。

表 2-9  人机交互要素分类及示意

2.4.2  人机交互方式分类

     基于实际业务要求，各家 OEM 的 OTA 人机交互方式各有差异，本节共总结 6 种主流升级方式，并针对营运车辆与非营运车辆使用性质不同，分别展开分析，具体如表 2-10 所示。

表 2-10  人机交互方式分类

 

   

转自汽车电子与软件