汽车OTA的典型架构及发展趋势

一、OTA 的过往

从手机到汽车嘛，大家也都知道个大概。先解释几个名词吧：

• OTA，Over The Air/空中下载，所谓“空中”指的是远程无线方式，指通过移动通信（GSM或CDMA）的空中接口对 SIM 卡数据及应用进行远程管理，OTA 技术可以理解为一种远程无线升级技术[1]；
• FOTA，Firmware Over The Air/固件空中升级，指通过云端升级技术，为具有连网功能的设备：例如手机、平板电脑、便携式媒体播放器、移动互联网设备等提供固件升级服务；刷过手机的朋友们应该对“固件版本”印象深刻，手机中的固件升级即可称为 FOTA；
• SOTA，Software Over The Air/软件空中升级，偏向于应用软件升级。

事实上 FOTA 与 SOTA 界限比较模糊，Windows 操作系统升级、手机升级、嵌入式系统、单片机控制程序等都的远程升级可以笼统地称为 FOTA；转移到汽车电子这块，为了方便讨论，我们将 HU 中的 APP 更新称为 SOTA，将其他 ECU 的更新甚至于所有更新统称为 OTA。

二、由汽车电子电气架构的发展趋势看汽车 OTA 的核心价值

事实上，大家看到这里对汽车 OTA 的主要目的可能有了初步的认识？大致上就是上一小节中饼图中所展示的 3 点：缺陷修复、新功能推送以及交互界面优化。不过在这一小节中我还是想从汽车电子电气架构发展趋势层面将汽车 OTA 说的更透彻些[3]。

先来看下趋势：

• 软件定义汽车（Software Defined Vehicles，简称SDV）将成为汽车行业普遍的发展趋势，其核心思想是：决定未来汽车的是以人工智能为核心的软件技术，而不再是汽车的马力大小、是否真皮座椅、机械性能好坏[4]；
• 高端汽车控制器节点 80~100，整车代码量已经突破 1 亿行[5]。而汽车行业80%~90% 的创新基于电子，离不开软件的支撑，还在不断发展[6]；
• 汽车电子的创新水平最终会向IT及传统消费电子看齐[7]。

再来看下汽车 OTA 的核心价值：

• 潜在问题改善。不断攀升的代码量即使按照 CMMI（capability maturity Model integration，能力成熟度集成模型）5 级的最高软件标准进行控制，代码缺陷率仍为 0.32‰，潜在问题的规模不容小觑[4]；OTA 可有效解决软件故障， 通过应急响应降低开发周期短带来的软件风险问题，以及完成对信息安全漏洞的修复；
• 全新功能导入。通过 FOTA 的功能进行新功能新特性的导入，让客户有常用常新的感觉，能够提升汽车使用的用户友好度；
• 进行界面优化更新，提升人机交互体验。汽车连接互联网，改变了过去销售是研发过程结束的汽车销售模式，使销售成为厂商与客户互动的开始，因此会带来投诉率高的风险。而是用界面和内容的更新可以从一定程度上降低投诉率。

三、汽车OTA的典型架构

▲汽车OTA 更新流概览

上图展示车辆内从主机厂服务器更新程序到指定 ECU 的过程中的主要部件。 首先通过蜂窝网络建立车辆与服务器之间的安全连接，确保全新的，待更新的固件安全地传输到车辆的 Telematics Unit，然后再传输给 OTA Manager。 OTA Manager 管理车辆所有 ECU 的更新过程。它控制着将固件更新分发到 ECU，并告知 ECU 何时执行更新 - 在多个 ECUs 需要同时更新的情况下尤为重要 - 例如推送一项新功能，而该新功能涉及多个 ECUs。更新过程完成后，OTA Manager 将向服务器发送确认。

针对 OTA Manager 它可能需要外挂 NAND flash 用来存储固件包，同样也可以用来存储其他车辆 ECUs 的备份，以期在 ECU 升级失败之后进行调用。这些备份应该通过加密&认证的方式进行防护避免外部攻击。

OTA Manager 内部有一个表格，包含各个车辆 ECU 的相关信息，譬如 SN 号以及当前的固件版本。这样便于 OTA Manager 核实接收到的固件升级包并确保是通过授权的。如果是正在更新的 ECU 不具备加密能力那么 OTA Manager 同样需要负责更新过程的解码及验签[8]。

从上图不难看出 OTA Manager 的重要性，也正是基于此，并结合网关的安全性、隔离性以及天然的多连接属性，部分主机厂启动自研网关（集成 OTA Manager 角色），譬如蔚来、FF。

四、汽车 OTA 的挑战

尽管汽车 OTA 使用的技术，包括 Telematics 以及通信技术都已成熟，汽车 OTA 却并没有想象中的普及？主要有两个大的挑战[5]：一个是安全的考量；将车辆的嵌入式系统重编程的接口开放，使其更容易受到黑客攻击。...是的，我又要说起特斯拉了...还有科恩实验室。

腾讯科恩实验室（Keen Security Lab of Tencent）连续两年，分别在 2016 年 9 月、2017 年 7 月实现了针对特斯拉 Model X 系统的破解，而从科恩实验室 2017 年的报道中我们发现特斯拉在 2016 年加入了“代码签名”安全机制，并对所有 FOTA 升级固件进行强制完整性校验[9] - 而这两个举措放在现在则是安全机制的标配了，可以说后发者站在前人的肩膀上。

也正是因为特斯拉趟过的坑能够让后来者一上来就重视安全的方案设计。

针对汽车 OTA 的安全性，主要可以从以下两个方面做一个简要分析：

• 信息安全；主要是通信加密、软件包验签、更新隔离以及安全芯片等；
• 功能安全；主要包括 OTA Manager 的启动条件判断（车辆状态等）、ECU 升级的预编程条件判断、整车模式配合以及升级方案考量（A/B 法等）；
• BTW，针对 2017 年的漏洞，特斯拉在两周之内修补了这些漏洞[10]。

二个是汽车产品线中的大量变体和配置使得难以为典型 EEA（Electronic and Electrical Architecture，电子电气架构）内的所有现有组合提供安全且一致的更新。包括不同地区、跨版本之间的兼容性等。

其他的还有诸如 roll back 机制、推送/升级的策略等，前期设计是一方面，实际运营过程中积累的 know how 更是至关重要。

汽车 OTA 不是什么洪水猛兽，也不是什么阳春白雪；它就是它，能够为消费者、主机厂带来共同收益的一项服务；是新趋势，也是新挑战，希望能够在看得到-看得起-看得懂-追得上的过程中享受其价值。