物联网产品设计中的设备升级功能

物联网产品设计中的设备升级功能

目录

• 物联网产品设计中的设备升级功能
  • 1、背景
  • 2、固件升级对设备的重要性
  • 3、远程固件升级总体框架图
  • 4、TFTP变种协议及远程固件升级流程
    • 1. TFTP协议
      • 1.1 协议简介
      • 1.2 传输模式
      • 1.3 协议格式
      • 1.4 TFTP 通讯流程
      • 1.5 TFTP协议的缺陷
      • 1.6 TFTP客户端/服务器设计注意事项
    • 2.远程固件升级流程
  • 5、IBMS 端程序设计流程图
    • 1. webApi程序设计
    • 2.升级消息通知定时任务程序设计
      • 2.1 Redis消息结构
      • 2.2 平台与设备之间的Modbus定制升级命令及其响应格式
    • 3.升级日志回写Mysql定时任务程序设计
  • 6、几个重要模型
    • 1.UpgradeCluster
    • 2.UpgradeTask
    • 3.UpgradeResult
    • 4.升级设备表
  • 7、升级功能测试
  • 8、网页原型图设计
    • 1.集群管理
      • 1.1 在设备基础上点选或者多选添加集群
      • 1.2 根据硬件版本或者软件版本或者区域编码（区域中文名称）来建立集群
    • 2.升级任务管理
      • 2.1 上传升级文件
      • 2.2 选择升级集群
      • 2.3 选择升级时间段
      • 2.4 输入升级策略
      • 2.5 输入管理员密码以确认升级任务
      • 2.6 确认以后的升级任务
    • 3.升级日志管理

1、背景

在迅速变化和发展的物联网市场，新的产品需求不断涌现，所以对于智能硬件设备的更新需求就变得空前高涨，设备再也不像传统设备同样一经出售就再也不变动。

物联网平台支持经过在线升级方式进行设备固件升级，是智能设备修复系统漏洞、实现系统升级的手段，为用户经过固件升级提供更好的服务。固件升级功能不只可以更新固件，并且还能从新配置片上硬件资源。同时，在线升级也是嵌入式设备端的敏捷式开发的新型产品化方式。

2、固件升级对设备的重要性

物联网领域具备多样性，应用和最终解决方案需求也是如此。面对和传统设备的需求差别，OTA升级显得尤为重要，主要体如今如下几方面：

1. 市场端的快速上线需求
   天下武功惟快不破，物联网设备产品每每留给设计者的时间不长，而且市场须要持续不断地创新和更新功能。在设备设计时，每每会预留一些后加载的需求，先期快速实现一些功能即开始上线，上线后能够经过在线升级的方式更新更多功能，实现渐进式部署，有那么一点相似于互联网的敏捷研发了。只要在架构设计阶段，在硬件层面考虑到了将来的足够需求，就不能够源源不断地优化完善设备功能。

2. 设备部署需求的多样性
   在物联网产品应用过程当中，设备须要肯定推送信息的云主机。那么问题就来了，有多是一个通用的云主机，也有可能由于部署须要又须要更新推送的云主机，这个时候若是设备已经生产出来了，已经在渠道或者客户手中，那么远程固件升级就显得很重要了。

还有一个比较常见的现象，一些设备在安装之后，对于输入输出部件的控制模式须要变动，那么可能须要对部分设备进行固件升级。好比，一开始在一个城市部署了相同智能路灯的设备，可是某些区域的设备关于灯光强度或者时间性须要作变动，那么远程固件升级也能够帮助解决灯光控制方式的变动。

备注：若是预留了远程下行控制指令，且已经支持的，也能够不用升级固件。

3. 设备安全性及完善性
   任何物联网设备不外乎都是两部分组成的：硬件+固件程序。在基于SoC的应用中，远程固件升级功能不只可以更新固件，并且还能从新配置片上硬件资源。

有了远程固件升级的备案，那么产品不必定等到彻底没有缺陷再上市，只要在不存在较为致命的缺陷下，就能够提早上市，解决问题后在远程完成升级修补缺陷。同时基于日益严峻的安全形势威胁，备固件可经过远程固件升级流程得到最新补丁和更多安全算法，作到不断加固的。

3、远程固件升级总体框架图

4、TFTP变种协议及远程固件升级流程

1. TFTP协议

1.1 协议简介

本应用的升级服务采用TFTP协议 RFC1350 中文,而且用到了TFTP(RFC2347)，用来支持OACK包格式，可选项应答，支持-tsize选项(RFC2349)。TFTP (Trivial File Transfer Protocol, 简单文件传输协议也称小型文件传输协议)。默认基于UDP方式进行实现，可是本应用采用TCP方式进行实现，缘由是若是是无线（如4G）组网，UDP没法找到设备，而TCP基于长链接，只要不释放链接，平台能找到内网中的设备，设备须要先链接公网平台。

1.2 传输模式

模式名称	模式含义	说明
netascii	文本传输模式，按照一个字节8位解析	文本模式
octet	二进制模式，数据无需解析	二进制模式
mail	已过期，不使用	已过期

本应用使用octet模式。

1.3 协议格式

TFTP共定义了五种类型的包格式，格式的区分由包数据前两个字节的Opcode字段区分，分别是：

opcode operation:

1. Read request (RRQ)
2. Write request (WRQ)
3. Data (DATA)
4. Acknowledgment (ACK)
5. Error (ERROR)

即：

• 读文件请求包：Read request，简写为RRQ，对应Opcode字段值为1
• 写文件请求包：Write requst，简写为WRQ，对应Opcode字段值为2
• 文件数据包：Data，简写为DATA，对应Opcode字段值为3
• 回应包：Acknowledgement，简写为ACK，对应Opcode字段值为4
• 错误信息包：Error，简写为ERROR，对应Opcode字段值为5

1.4 TFTP 通讯流程

• tsize选项：
  当读操做时，tsize选项的参数必须为“0”，服务器会返回待读取的文件的大小
  当写操做时，tsize选项参数应为待写入文件的大小，服务器会回显该选项

• blksize选项：
  修改传输文件时使用的数据块的大小（范围：4~65464）

• timeout选项：
  修改默认的数据传输超时时间（单位：秒）

1.5 TFTP协议的缺陷

• 传输效率低
• 对于超时机制没有明确说明
• 每包长度固定为512字节，不灵活

1.6 TFTP客户端/服务器设计注意事项

1. 只能是客户端发送读写请求，读写请求数据包中可能附带选项信息。在读写请求数据包中可能有不少个选项，但一个选项只能出现一次。选项出现的顺序并不重要。

2. 当客户端向服务器发送带选项的读请求数据包，服务器可能返回三种响应：

• OACK：应答读请求和选项
• DATA：应答读请求，无选项
• ERROR：请求被拒绝

3. 当客户端向服务器发送带选项的写请求数据包，服务器可能返回三种响应：

• OACK：应答写请求和选项
• ACK：应答写请求，无选项
• ERROR：请求被拒绝

2.远程固件升级流程

备注：4，5步骤，结束包分两种状况：1.若是文件字节不是512的整数倍，设备端则收到不足512字节的包以后，响应ACK，服务端关闭socket；2.若是传输文件恰好是512字节的整数倍，则最后一个有效包传输完成以后，设备端会返回两个ACK。接收到第二个ACK，服务端发空包，ACK返回有效包号+1，服务端关闭socket。

5、IBMS 端程序设计流程图

1. webApi程序设计

2.升级消息通知定时任务程序设计

2.1 Redis消息结构

频道：FileReceive
{
“fileType”:”upgrade”,
“ips”:
  [
    ”192.168.1.1”,
    “192.168.2.3”
  ]
}

2.2 平台与设备之间的Modbus定制升级命令及其响应格式

升级命令及其回应相见《LD_RD_IPDCU800管控协议格式说明书v0.0.12_chengzp20190529》1.4.5

3.升级日志回写Mysql定时任务程序设计

6、几个重要模型

1.UpgradeCluster

存于Redis中，
ip地址以逗号隔开的集合的字符串，例如："192.168.1.2,192.168.2.3"；
集群名称；
设备总数；
用户ID（用来作权限）；
key：集群名称；
使用增删改查方式；

2.UpgradeTask

设备名称；设备IP；
执行时间；DateTime类型；
执行策略：DateTime类型；延时时间；
文件名称：string类型
集群ID；
用户ID

key：GUID；
增删查

3.UpgradeResult

设备名称，IP 地址，升级结果，更新时间

保存到mysql数据库，自增ID为主键；
查

4.升级设备表

key：设备名称（或者IP地址）

taskId，devId（数据库主键）,ip，计划开始时间，内码

此表位于Redis中

7、升级功能测试

Step1. TCP工具下发指令的升级回应包，包类型为05。

Step2.将设备升级为1.04版本。
1.04版本指令
f0 aa 55 0f 85 60 a4 c2 ab 78 20 34 01 4C 44 2D 52 44 5F 49 50 44 43 55 38 35 30 5F 41 70 70 6D 64 5F 31 2E 30 34 2E 38 35 30 2E 31 30 34 2E 35 33 35 31 4E 5F 63 68 65 6E 67 7A 70 32 30 32 30 31 32 30 34 2E 62 69 6E 40 31 39 32 2E 31 36 38 2E 31 2E 31 31 3A 31 30 30 36 39 fe 55 aa ef

Step3.将设备升级为1.05版本。
1.05版本指令
f0 aa 55 0f 85 60 00 a4 c2 ab 78 20 34 01 4C 44 2D 52 44 5F 49 50 44 43 55 38 35 30 5F 41 70 70 6D 64 5F 31 2E 30 35 2E 38 35 30 2E 31 32 30 2E 35 33 35 31 4E 5F 63 68 65 6E 67 7A 70 32 30 32 30 31 32 30 32 2E 62 69 6E 40 31 39 32 2E 31 36 38 2E 31 2E 31 31 3A 31 30 30 36 39 fe 55 aa ef

综上，升级功能单台设备测试成功。

8、网页原型图设计

此部分功能原本应使用Axure工具设计升级部分web交互的动态原型图。可是在另外一个OMC平台已经设计过此模块，前端同事对此比较熟悉。故此处用升级的网页截图代替原型图部分，以做展现。

1.集群管理

1.1 在设备基础上点选或者多选添加集群

1.2 根据硬件版本或者软件版本或者区域编码（区域中文名称）来建立集群

区域编码须要支持直接编码输入与中文输入两种方式来建立集群。支持增删查。

2.升级任务管理

2.1 上传升级文件

2.2 选择升级集群

2.3 选择升级时间段

2.4 输入升级策略

即输入升级延时时间。为一个时间段，单位分钟。

2.5 输入管理员密码以确认升级任务

2.6 确认以后的升级任务

3.升级日志管理

备注：升级日志中的状态可删除。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接和本声明。 本文连接：https://www.cnblogs.com/JerryMouseLi/p/14148272.html