这一节开始我们来设计 OTA 升级功能。

设备 OTA 升级

OTA（Over-the-Air Technology），一般叫做空中下载技术，在物联网应用里，设备一般都是通过 OTA 技术进行软件升级的，毕竟人工升级一台台设备的成本太高了。
设备应用升级的类型可能会包括设备应用程序、固件、OS 等，具体如何在设备上执行这些升级程序，各个设备都不同，本课程不在这方面进行论述。这里 IotHub 会对设备 OTA 升级的流程进行一个约定，并做一定的抽象和封装，实现以下一些功能：

  • 业务系统可以将升级的内容发送给设备，包括升级包和升级包的类型（应用、固件等）；
  • IotHub 可以监控设备的升级的进度，包括升级包下载的进度、安装是否成功等；
  • 业务系统可以向 IotHub 提供的接口查询设备的升级情况。

接下来我们对 OTA 升级的流程做详细的分析。

如何获取当前设备的软件版本号

设备的软件版本号可能包括设备应用程序、固件、操作系统等的版本号，在上行数据数据处理的功能中，IotHub 提供了一个设备状态上报的功能，在每次设备系统启动时，设备应该通过状态上报功能上报当前的软件版本号，类似以下代码：

  1. var device = new IotDevice(...)
  2. device.connect()
  3. device.updateStatus({app_ver: "1.1", os_ver: "9.0" })

具体版本的种类和格式，由业务系统和设备约定，IotHub 不做强制约定。

下发升级指令

业务系统可以通过 IotHub 的 Server API 获取当前的设备软件版本信息，按照业务需求决定哪些设备需要升级。业务系统可以通过 IotHub 提供的接口向设备下发升级指令，指令数据包括：

  • 将要升级的软件版本号；
  • 此次升级的类型（应用、固件、OS 等，由业务系统和设备约定）；
  • 升级包的下载地址；
  • 升级包的 md5 签名；
  • 升级包的大小，单位为字节。

    在 MQTT 应用架构里，如果要传输较大的二进制文件，比如照片、软件升级包等，一定不要放到 MQTT 消息的 Payload 里面，而是将文件的URL放入Payload中，Client 在收到消息以后，再通过 URL 去下载文件。 这样做的原因我在《MQTT 协议快速入门》有详细解释。

在进行 OTA 升级前，业务系统需要将升级包上传到一个设备可以访问的网络文件存储服务器中，并提供升级包的下载 URL。同时需要提供升级包的 md5 签名，以免因为网络原因导致设备下载到不完整升级包，进而导致升级错误。

设备上报升级进度

设备接收到升级指令后，应该按照次序执行以下操作。

  1. 下载升级包。
  2. 校验安装包的 md5 签名。
  3. 执行安装/烧写。
  4. 向 IotHub 上报新的软件版本号，如果升级以后要重启设备应用，设备会在应用启动时，自动通过状态上报功能上报自己的软件版本号；如果升级以后不需要重启设备应用，那么设备应用代码应该再使用状态上报功能上报自己的软件版本号。

在这个流程中，设备需要上报升级的进度，包括升级包下载的进度、升级中发生的错误，设备上报的进度数据是一个 JSON 对象，格式如下：

  1. {
  2.   type: "firmware",
  3.   version: "1.1",
  4.   progress: 70
  5.   desc: "downloading"
  6. }
  • type：代表此次升级的类型，比如固件、应用等；
  • version：代表升级的版本；
  • progress：当前的安装进度，由于只有在下载升级包时才能够保证设备应用是在运行的，所以 progress 只记录下载升级包的进度，取值为 1 ～ 100。在安装升级包时，很多时候设备应用都是处于被关闭状态的，无法上报进度。同时 progress 也被当做错误码使用：-1代表下载失败、-2代表签名校验识别、-3代表安装/烧写失败、-4代表其他错误导致的安装失败。
  • desc：当前安装步骤的描述，也可以记录错误信息。

由于在安装过程中，设备应用处于不可控状态，所以确定安装升级包是否成功的依据只有一个：检查设备状态中的软件版本号是否更新为期望的版本号，而不能依赖设备上报的进度数据。

OTA升级流程

总结一下，设备执行 OTA 升级的流程如下（图中虚线代表该步骤可能会被重复执行多次）：
31.OTA升级——功能设计 - 图1

  1. 业务系统将升级文件上传到文件存储服务器，获得升级文件可下载的 URL；
  2. 业务系统调用 IotHub 的接口请求对设备下发 OTA 升级指令，包含升级包 URL 等信息。
  3. IotHub 下发 OTA 指令到设备。
  4. 设备通过指令数据中的升级文件 URL 从文件存储服务器下载升级文件。
  5. 在下载和升级过程中，设备上报进度或错误信息。
  6. 设备完成升级后，通过状态上报功能上报新的软件版本号。

这一节我们完成了 OTA 功能的设计，下一节我们开始实现 OTA 功能的服务端实现。