物联网产品设计中的设备升级功能
一、背景
在迅速变化和发展的物联网市场，新的产品需求不断涌现，因此对于智能硬件设备的更新需求就变得空前高涨，设备不再像传统设备一样一经出售就不再变更。
物联网平台支持通过在线升级方式进行设备固件升级，是智能设备修复系统漏洞、实现系统升级的手段，为用户通过固件升级提供更好的服务。固件升级功能不仅能够更新固件，而且还能重新配置片上硬件资源。同时，在线升级也是嵌入式设备端的敏捷式开发的新型产品化方式。
二、固件升级对设备的重要性
物联网领域具有多样性，应用和最终解决方案需求也是如此。面对和传统设备的需求差异，OTA升级显得尤其重要，主要体现在以下几方面：
市场端的快速上线需求
天下武功唯快不破，物联网设备产品往往留给设计者的时间不长，并且市场需要持续不断地创新和更新功能。在设备设计时，往往会预留一些后加载的需求，先期快速实现一些功能即开始上线，上线后可以通过在线升级的方式更新更多功能，实现渐进式部署，有那么一点类似于互联网的敏捷研发了。只要在架构设计阶段，在硬件层面考虑到了未来的足够需求，就不可以源源不断地优化完善设备功能。设备部署需求的多样性
在物联网产品应用过程中，设备需要确定推送信息的云主机。那么问题就来了，有可能是一个通用的云主机，也有可能因为部署需要又需要更新推送的云主机，这个时候如果设备已经生产出来了，已经在渠道或者客户手中，那么远程固件升级就显得很重要了。
还有一个比较常见的现象，一些设备在安装以后，对于输入输出部件的控制模式需要变更，那么可能需要对部分设备进行固件升级。比如，一开始在一个城市部署了相同智能路灯的设备，但是某些区域的设备关于灯光强度或者时间性需要做变更，那么远程固件升级也可以帮助解决灯光控制方式的变更。
备注：如果预留了远程下行控制指令，且已经支持的，也可以不用升级固件。
- 设备安全性及完善性
任何物联网设备不外乎都是两部分组成的：硬件+固件程序。在基于SoC的应用中，远程固件升级功能不仅能够更新固件，而且还能重新配置片上硬件资源。
有了远程固件升级的备案，那么产品不一定等到完全没有缺陷再上市，只要在不存在较为致命的缺陷下，就可以提前上市，解决问题后在远程完成升级修补缺陷。同时基于日益严峻的安全形势威胁，备固件可通过远程固件升级流程获得最新补丁和更多安全算法，做到不断加固的。
三、远程固件升级整体框架图
四、TFTP变种协议及远程固件升级流程
1. TFTP协议
1.1 协议简介
本应用的升级服务采用TFTP协议 RFC1350 中文,并且用到了TFTP(RFC2347)，用来支持OACK包格式，可选项应答，支持-tsize选项(RFC2349)。TFTP (Trivial File Transfer Protocol, 简单文件传输协议也称小型文件传输协议)。默认基于UDP方式进行实现，但是本应用采用TCP方式进行实现，原因是如果是无线（如4G）组网，UDP无法找到设备，而TCP基于长连接，只要不释放连接，平台能找到内网中的设备，设备需要先连接公网平台。
1.2 传输模式
本应用使用octet模式。
1.3 协议格式
TFTP共定义了五种类型的包格式，格式的区分由包数据前两个字节的Opcode字段区分，分别是：
opcode operation:
- Read request (RRQ)
- Write request (WRQ)
- Data (DATA)
- Acknowledgment (ACK)
- 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客户端/服务器设计注意事项
只能是客户端发送读写请求，读写请求数据包中可能附带选项信息。在读写请求数据包中可能有很多个选项，但一个选项只能出现一次。选项出现的顺序并不重要。
当客户端向服务器发送带选项的读请求数据包，服务器可能返回三种响应：
- OACK：应答读请求和选项
- DATA：应答读请求，无选项
- ERROR：请求被拒绝
- 当客户端向服务器发送带选项的写请求数据包，服务器可能返回三种响应：
- OACK：应答写请求和选项
- ACK：应答写请求，无选项
- ERROR：请求被拒绝
2.远程固件升级流程
备注：4，5步骤，结束包分两种情况：1.如果文件字节不是512的整数倍，设备端则收到不足512字节的包之后，响应ACK，服务端关闭socket；2.如果传输文件刚好是512字节的整数倍，则最后一个有效包传输完成之后，设备端会返回两个ACK。接收到第二个ACK，服务端发空包，ACK返回有效包号+1，服务端关闭socket。
五、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定时任务程序设计
六、几个重要模型
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中
七、升级功能测试
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
综上，升级功能单台设备测试成功。
八、网页原型图设计
此部分功能本来应使用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