特斯拉作为整车 OTA 的鼻祖，从 2012 年推出的 Model S 到最新的 Model 3 都具备整车 OTA 能力。不仅可以通过 OTA 升级车载娱乐系统、应用程序等，还可以实现对 ECU 进行软件更新，比如电池管理系统、电驱控制单元、整车控制单元等。
特斯拉的 OTA 框架
特斯拉的 OTA 架构如图 1 所示，首先中控系统的 CID 通过特斯拉的私有握手协议，将固件包从云端下载下来，并对其进行解密和完整性校验。
从 OTA 升级框架来看，升级方式主要为两种，一种为对有以太网连接的 ECU，另一种为通过网关转换为 CAN 总线的 ECU。
对于具有以太网连接的 ECU，都具有 ic-updater，cid-updater 升级代理，其中 cid-updater 负责从云端获取固件包，并进行校验，可将 cid-upadater 视为本地服务器，ic-updater 作为远程代理。
另外对于这类 ECU 而言，其采用的软件升级方式为 A/B 备份，如图 2 所示。例如当前使用的是 A 区，当软件需要更新时，先将软件写入至 B 区， 更新完之后，B 区作为主系统启动，而 A 区作为备份区域。
对于通过网关基于 CAN 总线的 UDS 协议或者其他协议更新的 ECU。其从 release.tgz 中提取所需要的文件，包括：
1）boot.img：在升级过程中运行，其类似于常用的 flash driver；
2）Release_version.txt：包含固件的版本信息；
3）Version_map2.tsv 和 Signed_metadata_map.tsv：包含固件信息；
4）Internal_option_default.tsv：包含固件的默认配置信息；
5）ECU 命名的文件，其格式为 ECUName/ProviderID/ECUFwName.hex。其主要是 hex 格式的文件，真正需要下载至 ECU 的文件。
特斯拉 OTA 的供应商
为了实现上述的 OTA 框架，目前特斯拉选择的供应商是哈曼旗下的 Red Bend，Red Bend 提供的 OTA 平台用于进行车辆与云端的通信，并且哈曼与特斯拉是允许双方替换代码，而不是替换文件，但是涉及到整车软件升级问题时，特斯拉依赖的则是其内部开发的 API 接口。
哈曼到底是一家什么公司呢？哈曼其实是三星全资子公司 (2017 年收购)，专注在汽车、消费、企业级市场的互联技术，为物联网、车联网的打通实现强力融合。
哈曼的 OTA 方案中，采用与 NXP 联合开发的 「软件更新网关」，可为整车所有 ECU 提供安全的 OTA 操作，而不在意 CPU、内存和网络资源太小，并且集成了网络安全的措施，例如在更新服务激活前，从 OTA 系统自动启动二进制文件扫描。
目前除了特斯拉还有其他的一些产商在使用，如表 1 所示。
近年特斯拉 OTA 汇总
从 2012 至今，特斯拉的 OTA 已经实施了 9 年了。在这么长的时间跨度里，到底实现过哪些 OTA 呢？
从 2012 到 2019 年 4 月的近 6 年多的时间里，总共实施了 37 次 OTA 升级，平均每年 6 次，具体每年的次数如图 3 所示。
在这些升级中，潜在问题改善有 11 项，全新功能导入有 67 项，交互界面、交互逻辑优化 64 项，如图 4 所示。
从升级所涉及的控制器来看，涉及到的包括：ADAS、ESP、EPS、Ibooster、VCU、BCM、HU、IPC、BMS、OBC、AC、MCU、AMP、GW、PTC、CAMERA、ECSS、SRCU、TPMS、IPC 等 20 个 ECU，其中 HU 的升级次数多达 20 次，EPS、OBC、AMP 等升级最少，为 1 次，如图 5 所示，这个也很好理解，网络架构中越接近执行层的通常变更越少。
从不同功能域的角度来看，这些升级涉及到了动力系统域、座舱娱乐域、车身电子域、底盘和自动驾驶域等。其中座舱娱乐域升级次数最多达到 20 次。2016 年 7 月后，特斯拉加速了自研自动驾驶系统，因此自动驾驶域的升级次数逐年增多，如图 6 所示。
对自动驾驶域而言，其软件升级主要经历了三个阶段：
阶段一：4.0 版到 6.0 版本
特斯拉未真正加入智能驾驶功能，其 OTA 升级主要集中在智能网联、人机交互和导航功能。
阶段二：6.1 版到 7.1 版
特斯拉首次初步实现了智能驾驶功能，实现了车道保持 LKA、自动变道 ALC 和自动泊车 APA 三大功能。
阶段三：8.0 版 10.0 版
特斯拉对 ADAS 系统进行持续优化，仅 8.0 版就更新了 200 多项的改进，同时还进一步扩展了信息娱乐功能和人机交互。
最后来我们来看一下这些年特斯拉具体更新了什么吧。
