十一号组织先前发布的《SOTA技术概述》一文中简介了FOTA和SOTA的资源开销。其中，FOTA是通过给车辆控制器下载安装完整的固件镜像，来实现系统功能完整的升级更新。由于刷写整个系统，对于控制器运算、内存等资源开销大。SOTA是增量更新，资源开销小，发布更灵活。

同时，《FOTA技术专栏—FOTA运营流程（二）》一文也已提到，FOTA的运营流程需要分别向工信部和市监总局备案，导致整车运营受法律法规管控。

综合以上两点，FOTA是较重量级的升级过程，对于整车愈发频繁的迭代计划并不敏捷。

SOTA的确是更轻量的OTA方式，主要应用于APP更新。然而整车功能迭代，部分变更内容仅仅与配置项、可用资源包有关，而和系统本身或者应用软件更新关系不大。例如：

（1）增加车机、仪表等HMI的壁纸、开机动画、视频、主题模式、皮肤等素材

（2）控制器策略配置、标定等参数更新

（3）控制器可使用的脚本、资源内容

车厂的测试工程师亦有相似需求，例如笔者曾承担的FOTA实车测试，工程车辆UAT和P环境互相切换的痛苦记忆犹新，一般先要整理联网的控制器清单，依次跪求各DRE，刷写完所有相关控制器，重新请求证书、激活后才算完成。实质上不同环境的版本区别尽在域名、密钥、证书等配置项。

为了减少“杀鸡用牛刀”，避免所有场景使用FOTA，车厂希望建立更轻量更敏捷的XOTA方式。

从技术层面分析，由于车联网已日趋成熟，轻量XOTA的实施较容易，问题主要集中于业务层，如下所述：

一、主控的选择

在车厂摸爬滚打多年的老油条对这问题再熟悉不过了。例如FOTA在立项初期时，多家车厂的网联、网关、座舱团队对FOTA主控落在何处撕扯不断。随着各家车厂的电子架构正朝着域融合+中央大脑演进，答案愈发简单。

对于轻量OTA，要考虑车端电子架构的发展、业务主要场景、控制器的运算能力存储空间等综合确定主控制器。同时，和其他OTA是否能融合相同的业务模块也值得考虑。

二、车云协议

上文梳理的业务众多，因此必须要求车云协议能够覆盖多类场景，并具有一定的扩展性，车云协议迭代的过程需要满足老业务的正常运行

三、信息安全

由于PKI会增大云端服务器的开销，同时轻量OTA往往会传输较大的视频、文件，因此是否应用同样的加密策略需根据业务实际评估

FOTA作为车联的黄金通道发挥着巨大的作用，然而随着国内汽车市场卷成一锅粥的趋势，多条OTA通道并行建设，对于整车迭代具有更重要的意义。