OTA 升级过程中断了,怎么办?

道哥分享
关注

AWS 平台部署 OTA 升级任务

AWS 平台按照不同的业务类型,划分为不同的服务。这样处理起来,流程更规范,操作步骤也更多,当然也更赚钱一些!

从上一篇文章中可以看到,当一个新的固件准备好之后,需要做 2 件事情:

把固件(bin 文件)和一个固件描述文件(json格式的文本文件),上传到 S3 云存储服务器上;

在 AWS Core 任务管理中,新建一个升级任务(会得到一个 Job ID)。在这个任务中需要选择:

(1) 步骤1中上传的 json 文件;

(2) 哪些终端设备需要升级;

json 格式的固件描述文档,格式大概如下(可以根据实际的业务需求进行修改):


 "product": "产品名称",
 "group": "设备分组",
 "firmware":
 [
    {
       "ota_type": "esp32",
       "url": "http://xxx/esp32-v1.1.0.bin",
       "md5": "xxx"
    }
 ]

不知道您是否注意到:在 firmware 字段中,使用的是数组([...]),而不是对象({...})?

这样来组织的原因是,OTA 升级不仅仅可以对 ESP32 模组中的固件进行升级("ota_type": "esp32"),还可以对其他的一些固件或用户数据进行更新。

比如:更新 ESP32 串口连接的 MCU 中的固件程序。

对了,一个终端在通过网络连接到云平台时,都有一个唯一的 ID 编号,一般都是利用 ESP32 模组上的网卡 MAC 地址来作为唯一 ID。

当完成以上步骤时,在服务器端,就存在着一个升级任务关系链:

也就是说:一个 Job ID 就对应着一次 OTA 升级任务。终端设备在进行 OTA升级过程中,就是从这个 Job ID 开始的。

ESP32 OTA 升级的触发

ESP32 与 AWS 平台之间,是通过 MQTT 协议进行通信的。

因此,当运营人员创建了一个 OTA 升级任务后,所有相关的终端设备,必须从某个预先确定好的主题(topic)中,接收到 OTA 升级通知指令。

例如一个可能的 topic:$aws/things/xxx/job/notify

其中的 xxx,代表终端设备的 MAC 地址,只有这样,每一个设备才能够接收到属于自己的命令。

升级通知指令的内容中,一定会包含 OTA 升级的 Job ID,例如:


 "timestamp": "xxxxxx",
 "job_id": "001"

当终端设备接收到这个升级通知指令时,提取出 job_id 字段,然后向云平台发起请求:获取与这个 job_id 关联的固件描述信息,也就是之前上传的 Json 格式的文件息。

AWS 平台接收到这个请求后,就会把与这个 job_id 相关联的 OTA 升级任务描述文件(json文件),发送给终端设备。

设备拿到了固件描述文件,自然也就知道了固件的:版本,下载地址,MD5 值等信息,于是就进入后面的下载环节了。

以上的过程描述,基本上是一个终端设备触发 OTA 升级的最基本的过程。

在实际的项目中,可能会遇到一些稍微复杂的情况。

例如:一个终端设备一直处于断电状态。此时,云平台中已经对固件进行了好几次的升级,但是由于这台设备一直没有运行,因此它的固件已经过时了好几个版本。

有一天,这台设备上电运行了,此时它会从云平台接收到好几个升级任务,这个时候应该如何处理呢?

也许,我们就要对升级通知的指令中,赋予更多详细的内容,让这台设备有足够的信息来判断该如何进行升级。

声明: 本文由入驻OFweek维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。
侵权投诉

下载OFweek,一手掌握高科技全行业资讯

还不是OFweek会员,马上注册
打开app,查看更多精彩资讯 >
  • 长按识别二维码
  • 进入OFweek阅读全文
长按图片进行保存