OTA
OTA = 空中下载升级，指车辆通过 4G/5G/Wi‑Fi 直接从云端下载更新包并安装，不需要去 4S 店插电脑刷程序。 目的：修 bug、加功能、优化体验、提升安全性。 在汽车智能化里，OTA 是总称，SOTA 是其中一种类型，就像“水果”和“苹果”的关系。
二、SOTA 与 FOTA 的区别（核心）
| 类型 | 全称 | 升级对象 | 典型例子 | 风险程度 |
|---|---|---|---|---|
| SOTA | Software OTA（软件升级） | 娱乐、交互、应用层软件 | 车机导航、语音助手、桌面 UI、音乐/视频 App、氛围灯逻辑 | 低，失败一般不影响开车 |
| FOTA | Firmware/System OTA（固件/系统升级） | 底层系统、控制相关 ECU | 动力响应、刹车逻辑、转向手感、电池管理、辅助驾驶算法 | 高，失败可能导致抛锚 |
简单记：
- SOTA = 车机“手机化”的部分（你能看到的界面、App）
- FOTA = 车“会不会更好开/更安全”的部分
汽车OTA的痛点
1.网络信息安全。它是汽车OTA中一个很大的考量点。软件升级过程中的任何漏洞或者缺陷，都可能危害车辆及其乘客的安全。因此OTA必须是安全可靠、防篡改的，以防止黑客访问敏感数据或者干扰车辆的操作。而另一方面，现在很多车辆的智能驾驶系统都采用硬件预埋，软件付费订阅的方式销售，其价格动辄上万元。如果被一套简单工具“逆向工程”篡改盗用，则对车厂来说也是一笔巨大损失。当然在保障安全的同时，也必须保障体验，让用户能够高效地进行OTA，而不是一味地确认和验证。
2.兼容性。汽车不同型号和不同配置，往往有不同的硬件和软件版本，这就会影响OTA的兼容性。在软件配置管理方面，厂家需要有一套管理方案，确保电子控制器内部软件、单车车辆配置、云端服务器和OTA通讯管道的兼容。这对于只有少量车型及配置的初创来说，难度还算小，但对于车型丰富的传统厂家来说，其复杂程度实属让人头疼。
3.高效便捷性。相信大家都记得早年某车辆OTA过程中停在繁忙路段动弹不得，导致交通堵塞的新闻。汽车毕竟是一个交通工具，如何让OTA过程快速高效，尽量不打扰驾驶员对车辆的操作，则显得尤为重要。
4.鲁棒性。汽车OTA过程中环境变量 很多，例如无线网络信号不好，或者电池余量不足等。但用户肯定希望OTA能够稳定进行，不受外界干扰。而鲁棒性的另一个体现就是要求OTA升级的成功率极高，万一升级失败，也应该有备份措施，防止汽车“变砖”。
应对痛点的几种OTA技术
1.后台传输
传统车载控制器一般通过统一诊断服务（UDS）来传输需要刷写升级的软件，这往往需要控制器进入特定的模式，在传输文件的时候并不允许应用功能开启。这意味着文件传输过程中，用户功能都得中断。但随着车载软件日益丰富，升级的软件包大小也越来越大，这个中断过程时间过长，会严重影响用户体验。
而后台传输技术则允许控制器在运行应用程序的同时，在后台偷偷地传输文件。
2.AB分区
AB分区指整个软件系统（包括操作系统）分为A和B两个独立分区，且系统可以在A和B之间切换。这就可以让A分区跑旧版本软件，保障车辆正常使用的同时，让软件在B分区更新起来。等B分区也更新好了，再重启切换到B分区上。
3.版本回滚
OTA升级过程中不可控的网络状态、车辆状态等因素比较多。为了确保升级的鲁棒性，可以在升级不达预期的情况下采用版本回滚策略。简单来说就是升级新软件的同时，保证旧版本软件备份可用，如果升级失败或者用户不满意，可以安装或者切换回旧版本软件。实现方案上，可以单独给旧版本软件开辟备份分区，也可以与上述AB分区相结合，升级失败时回滚至之前的可用分区。
4.差分升级
现在汽车上复杂控制器的软件包大小越来越大，如果直接传输巨大的数据，网络状态和网络流量都是巨大的挑战。为了应对这个挑战，很多主机厂也会采用差分升级的方式。所谓差分升级，就是利用算法识别新旧软件的差异，制作出来一个差分包。然后云端后台将差分数据包推送给车端，车上的控制器再利用算法，结合旧软件和差分包，生成出来全量的新软件包，然后再进行更新。当然这种技术在手机或者电脑上已经比较成熟，安卓系统就能支持这种升级。差分包的实际文件大小取决于新旧软件之间的差异，但是通常情况下差分包只有全量软件包大小的5%~20%。这可以大大降低无线网络传输的流量，提高鲁棒性。有些算法还支持直接在旧软件包的分区上，直接基于差分包合成全量软件。这样还能进一步节省车载控制器的本地存储空间。
5.信息安全手段
汽车OTA毕竟涉及到软件更新，稍有不慎则容易被黑客攻击或盗用，所以信息安全相关的技术手段必须为此保驾护航。实际上，汽车OTA的信息安全保护可谓是全方位的，常见的手段包括：
-刷写文件安全：通过OTA更新的软件数据包，一般都带有数字签名部分。控制器可以通过签名验证算法和密钥，确认将要刷写的数据包的完整性和合法性。
-文件传输安全：需要更新的软件数据包从云端通过无线网络下载到汽车，这个数据传输的过程一般都带有保护机制。互联网中已经成熟的传输层安全协议（Transport Layer Security, TLS）是最常见的手段。
-诊断安全：汽车OTA过程中往往会伴随通过UDS指令更新标定参数或者触发例程等操作。这时候就需要对UDS诊断操作先做一层安全控制，常见的有UDS的0x27服务，某些OEM还会拓展0x27的子功能或者自定义0x31例程来完成远程诊断的安全校验。
升级方式
普通 ECU 单分区（Bootloader）升级方案
普通 ECU 由于存储空间有限，通常会采用流式刷写的方式进行升级，所谓流式刷写即先将目标刷写空间的数据擦除，然后传输数据的同时，ECU 将已接收的数据写入目的存储地址，通过这种方式可以省去存储升级包的内存空间。传统的 BootLoader 通过 UDS 协议刷写的方式就是典型的流式刷写。
普通 ECU 单分区结构只有 BootLoader(启动引导程序)和应用程序分区。该类型 ECU 需要更新时，首先将 ECU 从当前运行的应用程序分区切 换至 BootLoader 运行，在 BootLoader 中将应用分区当前版本数据擦除后，再从升级主控接收新版本数据并写入应用程序分区，数据检验无误后重启 ECU 切换至应用分区即可运行新版本软件。
这种方案缺陷非常明显， 由于只有一个应用分区，升级前需要擦除，导致升 级过程 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 内存的当前版本软件， 刷写新版本软件，完成激活。
强烈推荐OTA技术链接：http://www.cntransun.com/home/news/id/991