在我们去规划车机OTA业务的时候，通常会划分成两个部分考虑。一部分为云端系统，主要承载升级包制作/管理，升级任务，策略的管理。另一部分为车机端，主要包含下载/升级条件，升级方式和车机HMI端的显示定义
云端这部分可以说是整个OTA更新的中枢，往上要串联整车的各个系统，比如BOM PDM，往下要承载任务的分发，为其他终端（比如诊断仪）提供升级文件。
作为整个OTA发布的后台枢纽系统，最重要的 也是最核心需要解决的，就是对升级包的管理和升级任务的管理。
对于升级包 需要考虑的问题之多远远超出想象。我们在做设计的过程中，也是从几个方面去考量：
- 升级包的构成
升级包由各个控制器（ECU）的升级文件组成，这些升级文件的数量根据不同的车系和车型会有所不同。
一般情况下，一款车下面有哪些功能的表达，都是这些ECU在发挥作用。而车系车型的不同，本质上也就是ECU的不同，呈现出的就是配置的不同。
- 升级包的特征和属性
升级包的特征和属性，要从两个部分来说明，第一是组成升级包的升级文件，第二是整个升级包。对这两者考虑的角度是不同的。
先来说说升级文件的部分
各个ECU的升级文件都会有各自的属性。怎么理解这个属性的含义呢？我们可以把他分为两大类来看。
第一类是升级文件自身的属性，这里面就包含了升级文件的大小，名称，格式，版本。也包含他是否支持差分，以及可支持的差分算法，差分的效率等。
（差分是一个复杂而具有挑战的话题，我想我会根据我的经验单独聊聊差分）
第二类是业务属性，这就包含了升级的顺序 策略 条件等。依据不同的升级场景和需求，对不同控制器的升级也有了一定的要求。
比如升级的某个功能需要关联的两个ECU按照顺序升级才能呈现出来；或者在某次升级下，我们对某个版本下的其中一个ECU不一定要必须升级，这样灵活的需求，都会对整体升级的策略和条件，有很大的影响。
而往往在已有发布的车型中，出于降低量产后的成本考虑，未来还会存在更换供应商的情况。这也是要考虑的维度之一。
再来说整体升级包
对升级包来说，核心是制包和对版本的管控。
后台在什么时间点制包，制出来的包适用于那些车系 车型，适用于那些硬件版本，包的状态的变更（是否经过测试，是否经过审核，是否制包成功）都需要在考虑制包时，有充分的思考。
而对于版本的管控，需要到另外的维度去思考。升级版本每次变更的内容，版本号变更对应的含义，也同样需要在后台有所体现
当然，不能落下关于安全的部分，对升级包的签名，加密等安全层面的要求，也可以算到这里面，这也是非常重要的。