软件版本管理

• 字段设计：升级包文件名称 =发布日期（yyyy-MM-dd）_ 软件版本 硬件版本产品型号.bin（上传升级包时，命名完成给到服务器解析）、版本说明、选择类型（非必选）：没选择—通用版；选择：专属版、服务器存放地址、备注、文件名、常用字段（新增、编辑\用户、时间）
• 服务器端：先计算升级包的MD5校验码，然后提前将整个升级包划分成大小1024字节的子包，最后一个子包可以不满1024字节，再计算每个子包的BCC校验码，使用这些参数生成的OTA更新命令。
• Redis设置：imei -- URL：通过URL去服务器匹配，不再通过查库的方式

升级包优先

1. 选择完成升级包后，查询通过选择的升级包进行过滤设备（过滤设备版本低于当前选择升级包版本）
2. 设备上报最新版本（视图）inner join device where （添加检索条件）
3. 接口设计：

• 升级包查询设计：获取全部升级包（权限）
• 查询可升级设备设计：过滤正在进行升级的设备（获取设备升级的最新状态），根据选定的upgraderId（硬件版本一致，软件版本小于），再添加检索条件
• 创建升级状态（任务）：传递设备升级的实体集合，软件版本Id

设备优先

1. 服务器最新版本（同硬件版本下软件版本最高）
2. 设备上报最新版本（视图）inner join device （分页中取出响应的数据，获取单个设备的硬件版本，通过硬件版本匹配，查询软件版本最高的升级包。）
3. 视图：硬件版本中软件版本最高的升级包
4. 接口设计：
   • 查询设计：
   • 组织过滤，查询服务器设备的当前版本，根据查询到的设备硬件版本分类；根据组织（权限过滤），硬件版本版本去 【统一硬件版本下软件版本最高的视图】匹配硬件版本；遍历1中设备，匹配硬件版本，将软件版本设置回去。
   • 创建升级状态（任务）：传递版本检查的实体集合，软件版本Id，升级类型（升级包优先、设备优先）参数

升级任务

• 字段设计：upgrader_id（版本名称、版本号）、imeis(设备号列表)，升级类型（设备优先，升级包优先）、升级时间、待升级、升级中、下载完成、升级成功、未知、升级失败、 总升级数量
• 创建：imeis(设备列表、逗号隔开)，软件版本Id，升级类型（升级包优先、设备优先）
• 查询升级记录，通过group by 状态（待升级、升级中、下载完成、升级成功、未知、升级失败）进行count各种状态的数量。
• 点击详情：通过任务Id 与状态进行过滤查询

升级记录

• 字段设计：taskId、设备（设备名、设备号、所属组织）、升级前版本、升级后版本、升级状态
• 后台：组装下发指令报文，设备上报时下发，触发补偿机制。
• 设备获取升级包时查询该设备的升级记录最新一条获取recordId，创建升级过程记录。
• 状态变更：
  • 根据上报的报文，变更升级记录中的升级状态（升级中【+ReqCOTAP】、下载完成【+COTAPOVER】、升级失败【+COTAPERR】-【OTACMDERR】）
  • 下发升级指令: 30s 待升级 --> 升级失败
  • 超时变更状态：升级中 --> 升级失败（超时时间：size * 30s）
  • 设备收到完成 --> 未知 （超时时间：10m）

补偿机制

1. server下发升级指令，设备无响应？超时时间10s 失败
2. 设备升级包获取，相邻包与包之间的超时时间：3min
3. 设备收包到一半，设备无响应？超时时间：size * 30s 失败
4. 设备收包完成，上报报文：10m 状态未知。若是中间出现了未知的版本，也可创建新的升级任务，下次设备上报，更改掉未知版本为确认版本（成功则不升级，失败则继续添加到升级列表中）

展望

1. 定包重传
2. 失败自动升级