基于MQTT协议的数据断点续传方案研究
2020-11-06姚丽丽
姚丽丽
摘 要:伴随着云计算技术、移动端技术的快速发展,物联网平台在云服务器上的部署已经成为一种趋势。MQTT作为一种基于订阅/发布模型的轻量级即时通信协议,在物联网云平台中得到了广泛应用。然而传统的MQTT设备、网络等发生故障时,会导致故障时段数据缺失,使得业务数据不完整。为此,文中研究了一种基于MQTT协议的断点续传设计方案解决此类问题。
关键词:MQTT;通信协议;断点续传;Json;网关;物联网
中图分类号:TP39文献标识码:A文章编号:2095-1302(2020)10-00-03
0 引 言
伴随着云计算技术的发展,目前越来越多的云服务器(Elastic Compute Service,ECS)在市场出现,主要代表有阿里云、华为云、天翼云、金山云等。云服务器(ECS)具有网络部署、灵活扩展、节约成本、方便维护、公网IP自带等特点。为了解决由于物联网节点分散而导致的网络部署困难、移动端应用必须公网部署、终端需要等问题,越来越多的物联网平台也部署到了云服务器上。
消息队列遥测传输协议(Message Queuing Telemetry Transport,MQTT)是一种基于订阅/发布模型的轻量级即时通信协议,符合物联网的通信要求,目前,其已在物联网云平台中得到了广泛应用[1]。耿锡涛对MQTT协议在电力设备在线监测系统进行了应用研究[2],给出了基于MQTT协议实现温度在线实时采集的设计方案。刘佳利用MQTT协议对城市水务物联网监控系统进行了设计[3]。MQTT本身的设计理念为即时通信,目前的研究与应用也都集中在即时通信上。若传输层网关、代理服务器、平台端服务器以及中间传输网络任何一方在某个时段出现故障,采用常规的MQTT进行即时通信将导致故障时段数据缺失,使得业务数据不完整。为了解决此类问题,本文给出了一种基于MQTT的数据断点续传设计方案。
1 MQTT协议在物联网中的应用介绍
MQTT协议是一种基于订阅/发布数据传输模型的通信协议,MQTT服务代理作为服务端,物联网平台端和下方网关端都属于客户端[4]。在正常设备和网络都无故障的情况下,MQTT可以实现即时通信,当发布端发送消息到达服务端后,订阅端可立即接收已订阅主题的消息。
基于MQTT协议的物联网系统架构如图1所示。网关和传感器之间一般利用RS 485线连接,采用如Modbus,DL645等串口协议通信[5],也可以采用LoRa等无线连接;网关与平台端可采用有线、GPRS、无线等方式进行网络连接,采用MQTT协议通信。
MQTT通过主题对消息进行分类,为了避免消息干扰,物联网系统针对每一网关设置两个主题,其中一个主题作为网关端,用于发送数据,平台端接收数据;另一个作为平台端,用于发送数据,网关端接收数据。若一个物联网系统中有n个网关,则主题数目需要设置2n个。对于每一个网关来说,需要订阅一个主题,发布一个主题;而平台端需要订阅n个网关端发布的主题和发布n个针对不同网关的主题。
MQTT提供了三种服务质量(Quality of Service,QoS)机制[6]。其中,QoS0为只发送一次;QoS1为至少发送一次;QoS2为刚好发送一次。这三种服务质量的控制都是针对发布端和中间代理服务之间的通信质量,对于代理服务和订阅者之间的通信则不做考虑。
2 即时MQTT报文规约设计
2.1 报文格式
Json是一种简单的数据交换格式,它具有层次结构简单、良好的自我描述、生成解析方便、读写速度快等特点。故本文采用Json格式确定物联网平台的报文规约。
报文规约中的具体标识定义:CMD:报文类型;PN:网关编码;State:状态;Direction:传输方向;Value:终端采集设备数据;DataType:数据类型。
2.2 报文类型
借助电力系统的数据分类,物联网传输的数据种类分为遥测、遥信、遥脉和遥设四大类。
遥测:指传输的变量之值,如电压、电流、瞬时流量等,一般来说,该类数据时刻都在发生变化,且具有限值的告警存在。在数据上送过程中,该类数据除了进行全上送外,可以给定幅度进行变化上送。
遥信:传输的状态信息用0和1表示,如合闸状态、机器运行状态等。一般来说,该类数据只要状态发生变化,则需要立即上送。
遥脉:指传输的累计量,如电度、累计流量等,该类数据与遥测数据的最主要区别是该类数据是累计上升的数值,无限值。
遥设:平台端下方给终端设备的设置命令可以是0和1的状态控制,也可以是数值型设置,如空调温度设置等。
根据以上数据种类的应用传输功能,CMD报文类型可根据传输的数据类型等的不同给定相应设置:00,遥设;01,全遥测;02,变化遥测;03,全遥信;04,变化遥信;05,全遥脉。
2.3 规约传输内容
不考虑断点续传,在即时通信的情况下,物联网系统的平台端和网关端分别传输的内容见表1所列,主要包括即时发送的消息和定时发送的消息。全遥测、全遥信和全遥脉数据设置为网关端定时上送,即每固定周期间隔之后上送一次。对于变化遥测,为了避免上送频繁,可设置变化幅度,如变化幅度大于1%,则上送;对于遥信而言,只要发生变位,都需要立即上送;遥设消息由平台端在业务应用的触发下即时发送,网关端接收到消息后立即下发给控制装置,控制装置执行后,网关可将执行结果以遥信突变的方式或者遥测突变的方式上送到平台端。
3 断点续传方案设计
MQTT的数据传输涉及多个环节,如果传输层網关、代理服务器、平台端服务器以及中间传输网络任何一方在某个时段出现故障,采用常规的MQTT进行即时通信将导致故障时段数据缺失。为了保证业务应用的完整性,当故障修复后,故障期间的数据能够继续上送,本文设计了一种基于MQTT的断点续传设计方案。
断点续传方案设计的思想是基于发送数据端在确定接收端可以接收到数据的情况下发送数据;否则,不发送数据,将数据暂存。
由于物联网系统平台端仅发送一些控制消息,因此在发送消息前可以利用MQTT的遗嘱方式获得网关的在线状态而反馈。数据发送主要集中在网关端,故断点续传针对网关端设计,平台端获取断点续传数据后进行解析处理即可。
本文给出的断点续传设计方案如下:
(1)规定平台端每一分钟发送一次心跳(此处心跳也可用MQTT遗嘱实现),当网关端接收到平台端发送来的心跳时,表示当前平台端、代理服务端、网关端及网络运行良好,设置平台在线状态为1,设置上次通信时间等于当前时间;
(2)对于平台端的离线机制,每隔一分钟进行一次状态检测,若当前时间与上次通信时间之差大于规定有效通断时间,则设置平台在线状态为0;
(3)在得知平台端在线离线状态的情况下,网关端的断点续传流程设计如图2所示。
4 应用实例
本文提出的断点续传方案已成功应用到本公司的DMFS-9000蜜云综合能源管控平台中,目前已部署到多个现场。经测试,系统运行良好,满足断线故障后的数据续传业务需求。
DMFS-9000蜜云综合能源管控平台网关端采用DMF-330X系列数据集中器作为网关进行转发,MQTT代理服务器安装在集中业务云平台。
图3所示为网关端MQTT的服务配置程序,采集规约支持标准的Modbus,DL645等,可进行即时开发插件扩展,对规约采用本文介绍的含有数据断点续传的MQTT协议。
图4所示为带有断点续传功能的MQTT协议的平台端的接收解析应用程序。图5所示为业务应用平台的展示界面。
为了进一步说明本文提出的带有断点续传功能的MQTT协议对于业务应用的必要性,同时搭建之前无断点续传功能的平台和带有断点续传功能的平台,网关和代理服务只有一个,代理服务与两个平台不在同一台服务器上,两个平台同时订阅网关的发布数据主题。在6:20时分别将两个平台和代理服务之间的网络断开,8:50时恢复,其结果如图6和图7所示。无断点续传功能的平台在6:20和8:50之间数据缺失,而含有断点续传功能的平台在6:20和8:50之间的数据是完整的。
5 结 语
MQTT协议由于其开源、可靠、轻巧、简单、低功耗的特点,已然成为物联网协议发展的趋势。由于MQTT本身设计思想是给定一种即时通信,在很多物联网业务应用现场,如果出现网络或平台端故障问题,业务应用数据将缺失。为了解决发布端无故障,而代理服务器、平台端或者中間任意传输网络故障的情况下,当故障修复后,故障期间的数据能够继续上送平台,保证业务数据的完整性,本文提出的基于MQTT协议的数据断点续传设计方案已经成功应用到实际项目中,得到了客户的广泛认可。
参考文献
[1]徐侃,丁强.一种基于MQTT协议的物联网通信网关[J].仪表技术,2019,48(1):1-4.
[2]耿锡涛.基于MQTT协议的电力设备温度在线监测系统应用研究[J].工业控制计算机,2019,32(10):73-74.
[3]刘佳.基于MQTT协议的城市水务物联网监控系统设计[J].物联网技术,2019,9(6):14-19.
[4]蒋树庆,房滢.一种基于MQTT协议的数据采集控制系统[J].信息通信,2019,32(8):80-82.
[5]吴俊辉,吴桂初,陈冲,等.基于MQTT协议的物联网网关设计[J].温州大学学报(自然科学版),2019,40(4):54-61.
[6]贾凡,熊刚,朱凤华,等.基于MQTT的工业物联网通信系统研究与实现[J].智能科学与技术学报,2019,1(3):249-259.
[7]刘复源.基于MQTT协议的消息推送平台的设计与实现[D].广州:暨南大学,2015.
[8]陈涛,李娟.基于MQTT协议的推送技术研究[J].软件导刊,2016,15(3):18-21.
[9]龚永罡,付俊英,汪昕宇,等.MQTT协议在物联网中的应用研究[J].电脑与电信,2017,23(11):89-91.
[10]陶强,屈波,熊前兴.基于WinSock构建对等模式下断点续传系统的探讨[J].交通与计算机,2005(1):79-83.