除了云端平台这部分，还要有通讯协议层面。云端和汽车端之间指令的接口和协议的制定，不同车厂会有不同诉求。艾拉比既可以支持车厂私有化定制协议的要求，也可以提供基于OMA标准的协议。 第一，它既是云端的工具，也是云端的管理系统。一涉及到管理，就涉及到工作流、角色、人员的管理， 同时OTA的管理平台并不是独立存在，比如跟车厂的信息安全平台、车辆管理的系统进行核心打通， 芮亚楠：从OTA基本流程中的安全防护来说。主要包含了升级包的加密与签名，服务器端对于升级包的安全存储，基于身份验证建立安全链接通道，以及汽车端信息安全防护，对升级包的验签和解密管控。我们会配合OEM定义清晰的信息安全防护架构以及升级流程，最终还要通过专业第三方的渗透测试来验证OTA的信息安全防护能力达到预定的防护等级。 当车辆发出“okay”信号后，云端就会发送自己的签名，而后车辆再进行验证。接着，车辆的ECU模块就会开始进行首个升级任务。这就引出了一个问题：如果安装失败了，系统必须能够激活“恢复(restore)”功能，以便能够恢复至升级前的状态。 假设一份清单上有三个升级任务，如果第三个升级任务安装失败，系统就需要用到“清除(removal)”功能，将系统恢复至升级前的状态。 第一步——生成更新包
更新包里不仅仅有要修复的缺陷或者要加入的新功能，分发包的更新顺序、更新前和更新后需要做哪些验证检查等等，都会被打包到这个文件里。 加密，是不让别人看见我传输的是什么内容。认证，就是确保车辆端、云端是我期望的、认可的对象。 比如车机进行软件升级时，要发出认证请求到服务器；服务器收到车端请求信息后，发回反馈，要求发送数字证书自证身份。车端发送数字证书到服务器端；服务器对数字证书进行校验是否存在问题；验证无误后终端管理系统向终端发送验证结果，这时才可以开始进行相应的软件升级。更新包会被加密后传输到车端，在T-box解密后再分发到车机。另外一个比较重要的车端部分是网关，可以避免ECU与联网的远程信息处理单元直接接触，提高了OTA更新的安全性。 刚刚提到，FOTA相对SOTA要更具挑战一些，原因之一在于集成固件更新安装程序的闪存都比较小，FOTA更新包和更新软件要能在车辆嵌入式设备的小内存中完成安装。因此更新包会尽可能地压缩大小，一般会被压缩到原始大小的5%。 为了保证效率，在技术上我们会用到差分更新的方式，也就是比较新旧版本之间的差异，生成差异文件。当新旧文件差异不是特别大，就可以只传输差异文件。 差分更新的核心技术是各家供应商掌握的字节差分算法。 比如为特斯拉提供OTA技术的Redbend（ 比如汽车更新一定不能影响车辆的安全行驶。车的环境可能会发生很多变化，例如进入到隧道、地下车库这些没有信号的地方，出现异常的时候，需要车辆端的电子零部件能够应对不同的外界环境，做好保护，并且在升级失败的时候完成自恢复。 在OTA方面，特斯拉是真正玩转OTA的首家车企。从2013年至今，特斯拉已经使用OTA进行了应用程序、地图、灯光、语音、空气悬架升高等在内的多处更新，并且实现了Autopilote在内的驾驶辅助功能的升级。 OTA升级还需要途径将认证内容（这里指升级软件）下载至车内，以及用来存储这些内容的“位置”。在进行升级时，车辆会收到一份清单，上面列明了所有升级项目；当车辆发出“okay”信号后，云端就会发送自己的签名，而后车辆再进行验证。接着，车辆的ECU模块就会开始进行首个升级任务。