通用 OTA 设计方案

通用 OTA 设计方案

背景

随着年龄的增长,很多曾经烂熟于心的技术原理已被岁月摩擦得愈发模糊起来,技术出身的人总是很难放下一些执念,遂将这些知识整理成文,以纪念曾经努力学习奋斗的日子。本文内容并非完全原创,大多是参考其他文章资料整理所得,感谢每位技术人的开源精神。

简介

本文介绍通用的 OTA 设计方案。OTA(Over The Air)即空中下载技术,基于无线网络对设备固件、软件或驱动进行更新。

方案

角色

本文说明的 OTA 方案中包含 6 个参与角色:

  • 管理员(ADMIN):维护使用 OTA 服务的设备信息及固件版本信息。
  • 设备(DEVICE):使用到 OTA 服务的设备。
  • 网关(GATEWAY):过滤来自管理员和设备的请求。
  • 认证服务(AUTH SERVICE):对管理员身份做鉴权。
  • OTA 服务(OTA SERVICE):存储使用 OTA 服务的设备信息,并为这些设备提供 OTA 服务。
  • 文件服务(FILE SERVICE):负责实际存储固件版本文件。

流程

整个流程分为 4 个阶段:

  • A:管理员维护 OTA 设备信息。

    • [A-1] 管理员(ADMIN)发送设备管理请求到网关(GATEWAY),设备管理请求可能包含创建设备、更改设备信息、删除设备等操作;
    • [A-2] 网关(GATEWAY)接收到请求后,首先验证请求人(即管理员)身份合法性,从请求中提取关键信息,如 HTTP Header 中的 token,并发送身份合法性校验请求到认证服务(AUTH SERVICE);
    • [A-3] 认证服务(AUTH SERVICE)确认合法后通知网关(GATEWAY);
    • [A-4] 网关(GATEWAY)收到认证服务(AUTH SERVICE)返回的身份校验通过结果后,将管理员(ADMIN)的设备管理请求发送到 OTA 服务(OTA SERVICE);
    • [A-5] OTA 服务(OTA SERVICE)处理完设备管理请求后返回给网关(GATEWAY);
    • [A-6] 网关(GATEWAY)将设备管理请求处理结果返回给管理员(ADMIN)。至此 OTA 服务(OTA SERVICE)已有设备相关信息。
  • B:设备上线注册,与 OTA 服务建立长连接。

    • [B-1] 设备(DEVICE)发送上线注册请求到 OTA 服务(OTA SERVICE);
    • [B-2] OTA 服务(OTA SERVICE)校验设备合法性,处理合法设备的注册请求;
    • [B-3] OTA 服务(OTA SERVICE)校验设备合法后返回给设备一个标识(如:token),设备后续请求都需携带这个标识;
    • [B-4] 设备(DEVICE)收到注册成功结果响应后,紧接着发送一个设备固件版本上报请求到网关(GATEWAY);
    • [B-5] 网关(GATEWAY)收到设备(DEVICE)的固件版本上报请求后,首先从请求中取出设备身份标识(如:token),发送设备身份验证请求到 OTA 服务(OTA SERVICE);
    • [B-6] OTA 服务(OTA SERVICE)返回设备身份验证通过结果给网关(GATEWAY);
    • [B-7] 网关(GATEWAY)再次将设备(DEVICE)的固件版本上报请求转发给 OTA 服务(OTA SERVICE);
    • [B-8] OTA 服务(OTA SERVICE)处理固件版本上报请求,更新设备的固件版本信息;
    • [B-9] OTA 服务(OTA SERVICE)将设备固件版本上报处理结果返回给网关(GATEWAY);
    • [B-10] 网关(GATEWAY)将设备固件版本上报处理结果返回给设备(DEVICE)。
  • C:管理员上传固件升级包。

    • [C-1] 管理员(ADMIN)发送固件升级包上传请求到网关(GATEWAY);
    • [C-2] 网关(GATEWAY)接收到请求后,首先验证请求人(即管理员)身份合法性,从请求中提取关键信息,如 HTTP Header 中的 token,并发送身份合法性校验请求到认证服务(AUTH SERVICE);
    • [C-3] 认证服务(AUTH SERVICE)确认合法后通知网关(GATEWAY);
    • [C-4] 网关(GATEWAY)收到认证服务(AUTH SERVICE)返回的身份校验通过结果后,将管理员(ADMIN)的固件升级包上传请求发送到 OTA 服务(OTA SERVICE);
    • [C-5] OTA 服务(OTA SERVICE)调用文件服务(FILE SERVICE)执行实际的固件升级包文件存储操作;
    • [C-6] 文件服务(FILE SERVICE)存储完成固件升级包后,将固件升级包的 URL 返回给 OTA 服务(OTA SERVICE);
    • [C-7] OTA 服务(OTA SERVICE)收到固件升级包 URL 响应后存储固件升级包信息到数据库(通常是关系型数据库);
    • [C-8] OTA 服务(OTA SERVICE)将固件升级包上传成功结果返回给网关(GATEWAY);
    • [C-9] 网关(GATEWAY)将固件升级包上传成功结果返回给管理员(ADMIN)。
  • D:管理员创建 OTA 升级任务并执行。

    • [D-1] 管理员创建 OTA 升级任务,将请求发送给网关(GATEWAY);
    • [D-2] 网关(GATEWAY)接收到请求后,首先验证请求人(即管理员)身份合法性,从请求中提取关键信息,如 HTTP Header 中的 token,并发送身份合法性校验请求到认证服务(AUTH SERVICE);
    • [D-3] 认证服务(AUTH SERVICE)确认合法后通知网关(GATEWAY);
    • [D-4] 网关(GATEWAY)收到认证服务(AUTH SERVICE)返回的身份校验通过结果后,将管理员(ADMIN)创建 OTA 升级任务的请求发送到 OTA 服务(OTA SERVICE);
    • [D-5] OTA 服务(OTA SERVICE)解析管理员下发的升级任务,计算并查找到需要升级的设备(DEVICE)以及对应的固件升级包信息;
    • [D-6] OTA 服务(OTA SERVICE)通过长连接通知设备(DEVICE)执行 OTA 升级,通知中包含固件升级包 URL 及其签名信息;
    • [D-7] 设备(DEVICE)收到 OTA 升级通知后,根据通知中的固件升级包 URL 下载文件;
    • [D-8] 设备(DEVICE)下载固件升级包的请求首先到达网关(GATEWAY),网关(GATEWAY)从请求中取出设备身份标识(如:token),发送设备身份验证请求到 OTA 服务(OTA SERVICE);
    • [D-9] OTA 服务(OTA SERVICE)返回设备身份验证通过结果给网关(GATEWAY);
    • [D-10] 网关(GATEWAY)将设备(DEVICE)的下载固件升级包请求发送给文件服务(FILE SERVICE);
    • [D-11] 文件服务(FILE SERVICE)返回固件升级包二进制流给设备(DEVICE);
    • [D-12] 设备(DEVICE)下载固件升级包过程中可以持续上报下载进度给 OTA 服务(OTA SERVICE);
    • [D-13] OTA 服务(OTA SERVICE)可以通过控制台展示设备(DEVICE)下载固件升级包的实时进度;
    • [D-14] 设备(DEVICE)下载固件升级包完成后,首先通过 [D-6] 中拿到的签名信息验证固件升级包完整性,确认后执行本地升级操作;
    • [D-15] 设备(DEVICE)升级过程中可以持续上报升级进度给 OTA 服务(OTA SERVICE);
    • [D-16] OTA 服务(OTA SERVICE)可以通过控制台展示设备(DEVICE)升级的实时进度;
    • [D-17] 设备(DEVICE)升级完成后将升级结果上报给 OTA 服务(OTA SERVICE);
    • [D-18] OTA 服务(OTA SERVICE)收到设备(DEVICE)升级结果上报信息后,更新设备固件信息;
    • [D-19] OTA 服务(OTA SERVICE)可以通过控制台展示设备(DEVICE)升级的结果。

总结

本文只展示了一个通用的 OTA 设计方案,为什么说是 通用,因为应用到具体项目时需要根据实际需求情况做调整,譬如:

  • 本文方案中的 OTA 服务(OTA SERVICE)既负责固件版本信息维护,又负责设备信息维护,但在一些 ToB 项目中存在一个专门的服务用于维护设备信息,即 MDM(Mobile Device Management,移动设备管理),在这种情况下设备信息维护由 MDM 服务负责,而固件版本信息维护由 OTA 服务负责,本方案中展示的设备身份认证请求应该发送给 MDM 服务而非 OTA 服务;
  • 本文方案中的文件服务(FILE SERVICE)其实混合了文件管理和文件存储这两个概念,通常在稍大规模的系统设计中,文件管理和文件存储服务是分离开的;
  • 本文方案只说明了整体业务流程,并未怎么提及实现细节,这其中还有很多具体的关键技术:
    • 设备与 OTA 服务器之间的长连接管理;
    • 管理员及设备的身份鉴权;
    • 服务间鉴权;
    • 固件包签名及合法性校验;
    • 固件包下载协议:HTTP(S) / MQTT;
    • 固件包版本号规则;
    • 固件包分组传输;
    • 固件包断点续传。
相关推荐
菜盐荒1 个月前
nrf52832 OTA could not open file“*.hex“:Application file not found
nrf52·ota
OH五星上将3 个月前
如何实现OpenHarmony的OTA升级
嵌入式硬件·openharmony·ota·鸿蒙开发·鸿蒙源码
Mr.Cssust6 个月前
【自动驾驶】针对低速无人车的线控底盘技术
人工智能·信息安全·自动驾驶·嵌入式软件·ota·功能安全·线控底盘
stark1898y6 个月前
CH32V 系列 MCU IAP 使用函数形式通过传参形式灵活指定APP跳转地址
单片机·嵌入式硬件·mcu·iap·risc-v·ota
洛奇看世界7 个月前
Android OTA 交流群 2024 年 4 月问题汇总
android·ota·update engine
yutian060610 个月前
OTA 升级软件推荐,附带MD5计算工具,CRC计算工具,CRC16计算工具,CRC32计算工具,AES计算工具
ota·crc计算软件·md5计算软件·aes计算软件
螳螂观察1 年前
国民新旅游时代,OTA们如何制胜新周期?
ota
天赐好车1 年前
汽车OTA
汽车·ota