基于MQTT的液漏监测系统的设计与实现

刘艳芳,侯钰龙 ,高 凯

(中北大学 仪器与电子学院 太原 030051)

0 引言

大多厂房有着服务器等精密仪器电子设备，但液体泄漏的情况时有发生，同时也存在着供水管道漏水、雨水侵入等情况，这就需要及早地发现泄露情况，并精确感知泄漏的点位。分布式或准分布式的光纤传感器在液漏测量方面具有广阔的应用前景，可以在发现液漏的同时及时确定液漏的位置。瑞士SMARTEC SA 公司利用光纤拉曼散射技术来测试液体的泄漏，液漏定位精度达到了2 m[1]；西安石油大学利用布里渊光散射设计了分布式光纤传感器，液漏定位精度达到了0.2 m[2]。上述方法所使用的光纤传感技术都是通过单一光源定位，因此对所使用光源的强度提出了极高的要求，同时对于系统数据处理能力的精确度也随之提高，进而使得测量成本也随之增加。但是目前市场上很难选配到具备厘米级空间定位能力，而且价格低廉的液漏传感器[3]。

在这一特定需求领域应用真空的背景下，实验室采用了多源定位的技术[4]，即选用了柔性LED灯带、POF光纤以及光功率计优化了传统的液漏传感结构。该结构在1 m长的POF光纤上设计了20个监测点位，每一个点位对应一个价格低廉的LED灯珠。相比于单一光源技术，该设计大大降低了测量成本，同时空间分辨率达到了0.05 m，在降低成本的同时也提高了监测系统的空间分辨率。

目前该液漏传感系统仅支持通过串口协议与上位机通信，传输距离仅限于被测厂房内。系统管理员和维修员无法在距厂房50 m以外的监控中心远程控制和查看液漏状态，然而部分工业环境不便现场监测甚至可能会对人体产生危害，所以实现该传感系统的远程监测具有很大的研究意义[5]。

HTTP和MQTT是目前广泛使用的远程通信协议[6]，但HTTP较MQTT协议而言，对设备的功耗要求相对高一些，不适合M2M的场景。而对于物联网来说，网络不稳定、设备功耗大，是需要重点考虑的因素[7]。其次，HTTP的请求-响应模式也不像MQTT的发布/订阅模式那样灵活，服务器的数据必须从设备端主动发送，设备端也需要在与服务器建立连接的情况下取得服务器端的数据[8]。更重要的是，MQTT的每个消息头均可缩短为2个字节，而对于HTTP，每个消息头至少需要200个字节[9]。综合以上因素，在原有系统的基础上，加入了更轻量级的MQTT协议进行数据的推送与交互。相较于HTTP协议的重复建立连接，MQTT协议独有的发布/订阅永久连接模式，显著降低了连接开销，同时该协议对于在不稳定网络状态下的传输也有着故障恢复的机制，该机制是原生HTTP所不具备的。

Qt作为一种跨平台的上位机应用程序开发框架，具有跨平台性广、扩展性强、开发模式简单的特点，现已被广泛运用于嵌入式终端和数据采集等系统中[10]。因此基于以上优点，选择Qt作为客户端的开发框架，管理员和维修员可通过该客户端实现对系统的远程操控以及实时监测。

1 总体设计

液漏监测系统由光纤传感端、MQTT传输端和软件接收端三部分组成，其中光纤传感端主要包括传感带和变换器两部分。

传感带由POF光纤、柔性LED灯带和光纤包层组成，当出现漏液后，液体下落至光纤传感端，从而改变了LED灯带与光纤上耦合结构间的折射率，传感端监测到该点的光强发生突变，进而判断该点位发生液漏。传感带的结构如图1所示。光强数据经过变换器的光电转换模块和信号调理模块，最终将数据传输到变换器的总线传输模块[11]。

图1 传感带设计模型图

图2 液漏监测系统架构图

对于传输端，最后一条传感带汇总的监测数据经过WIFI的ESP8266模块发送至MQTT代理服务器，传输协议的应用层采用轻量级的MQTT来实现数据交互。管理员通过移动端和PC端均可对系统液漏状况进行实时监测和感知，系统维修员也可通过移动端和PC端查看待维修状态的点位信息并提交维修单据。该软件实现了对管道液漏点位的精准定位和远程监测，可以极大提高工作人员的效率。系统总体架构如图2所示。

2 传感端设计

传感端包括传感带和变换器两部分，传感带之间用变换器连接来进行数据传输。每1 m长的传感带上分布20个带有缺陷结构的传感点位，每个缺陷结构传感点位和LED灯珠以及它们之间的耦合区域组成一个传感探针。该探针基于光纤的侧向耦合效应来实现对每个点位的漏点监测，LED灯带的光源会通过缺陷结构进入光纤，发生漏液后，LED灯带和传感带缺陷结构之间的介质由空气变为漏液，从而改变了耦合结构处光的折射率，进而导致探测到的光强发生突变。

变换器电路的中央处理芯片为STM32F103ZET6，其控制流程为：中央处理芯片控制LED灯带按规则闪烁，灯带上灯珠发出的光耦合进入所对应的传感带上的缺陷结构，中央处理芯片控制光电转换模块将光信号转换为电信号，最后将信号放大，发送到总线传输模块[12]。传感端设计如图3所示。

图3 传感端结构示意图

3 远程监测技术

远程监测技术是一种随着计算机技术,通信技术以及传感技术的发展，而逐渐兴起的设备状态监测技术[13]。通过将监测点、控制中心分别部署于两个不同地域，可打破地域间的物理界限,实现通过网络来传输监测信息。该技术采用了多元化的信息传输、监测方案,从而实现了信息、资源和任务的无边界共享,达到了监测的实时性、快速性和有效性,并能够与其它网络系统互连互通,为工业领域提供了一个更高效、全面、安全、快捷的监测模式。

目前主流的远程监测技术均应用于因特网中,并基于TCP/IP协议和WWW规范,可扩展的软件组织架构,使工作人员可以通过访问中心服务器来迅速获取其对应权限下的信息，同时也能及时做出响应。未来,随着嵌入式系统的迅速发展,远程监测技术必然更广泛的应用于远程监测系统上,是监测系统未来的重点发展方向之一。

本系统在设计上使用了物理监测设备作为采集前端，WIFI模块作为网络传输单元，QT客户端作为接收信息端，将三者结合，共同组成了远程液漏监测系统。采集前端主要包括光纤液漏采样设备以及STM32中央处理器组成，其采集到的液漏数据，通过WIFI模块的无线网络，将信息传递给QT客户端，最终实现了用户通过internet便可轻松实现远端厂房内的液漏监测。

4 MQTT协议

MQTT(消息队列遥测传输)是一种基于代理的发布/订阅轻量级消息传输协议[14]。该协议是基于TCP/IP协议的应用层传输协议，具有网络占用开销小、带宽低且易于实现的特点，十分适合于物联网应用下的信息采集和工业控制。在MQTT协议中有发布者(Publisher)、消息代理服务器(Broker)、订阅者(Subscriber)3种通信身份。MQTT消息的发布者和订阅者都可以是客户端，消息代理Broker作为中转服务器，负责接收发布者发布的消息，并将消息传递给该主题的订阅者。消息的发布者也可以同时是该主题的订阅者[15]。MQTT的通信结构如图4所示。

图4 MQTT通信结构图

MQTT设计了一套保证消息稳定传输的机制，包括消息应答、存储和重传。在这套机制下,提供了3种不同层次QoS(quality of service)，QoS是消息的发送方和接收方之间达成的一个协议，MQTT通过控制QoS等级来确定服务质量，QoS级别越高，服务质量越高，流程越复杂，系统消耗越大[16]。本系统选用QoS0和QoS1两种等级，发布者发布一个QoS0等级的消息后，无论订阅者是否成功收到数据，都会删除并丢弃已发送的数据包[17]，发布者和订阅者传递一次QoS0等级消息的流程如图5所示。QoS1等级要保证消息至少到达一次，所以需要有应答机制[18]，发布者和订阅者传递一次QoS1等级消息的流程如图6所示。

图5 QoS0消息传递流程图

图6 QoS1消息传递流程图

当传感端上报液漏监测数据时，传感端作为MQTT协议中的发布者(Publisher)，接收端作为订阅者(Subscriber)，系统一经启动便会进入循环监测状态，当某一个液漏数据包传输失败时，也不会对监测结果产生较大影响，所以该数据包的传递选用QoS0等级。

当液漏监测系统上传待维修液漏点位信息数据时，传感端作为MQTT协议中的发布者(Publisher),系统维修员作为订阅者；当系统维修员在维修完成后回传维修单时，系统维修员作为MQTT协议中的发布者(Publisher),系统管理员作为订阅者。以上两种情况需保证消息发送成功，所以选用QoS1等级。

5 B/S架构和C/S架构的介绍

C/S即Client/Server(客户机/服务器)结构，它是一种网络体系结构，客户端是用户运行应用程序的PC端，要依靠服务器来获取资源。C/S架构通过查询共享数据库来响应客户端请求，在客户端和服务器之间通信一般采用远程调用(RPC)或标准查询语言(SQL)语句。它允许多用户通过GUI前端更新到共享数据库， C/S架构有以下优点：1)响应速度快，信息处理能力强。2)用户界面美观漂亮，人性化强。3)C/S架构的客户端面向固定的用户群体，所以对信息的存储方式更加安全。但是C/S架构也有以下缺点：1)需要专门的客户端安装，不能快速完成安装与配置。2)兼容性差，对于不一样的开发工具，具有较大的局限性。3)开发成本高，C/S架构的客户端需要专业的技术人员开发和维修，每修改一次，就要全部更改程序完成升级。

随着网络技术的发展，B/S软件体系结构出现了。B/S(browser/server)架构被称为浏览器/服务器体系结构。这种结构可以使信息分布式处理，有效的降低资源成本，提高系统的设计性能。B/S架构有以下优点：1)客户端不需要维护，在浏览器中就可以使用。2)业务扩展简单便利，通过添加网页就可以添加服务器功能。3)只需要更改网页就可以实现对客户端的维护，所有用户的客户端就随之更新。但是B/S架构也有以下缺点：1)客户端无法实现个性化的需求。2)客户端服务器端的交互是请求-响应模式，需要经常性的动态刷新页面，所以响应速度慢。3)安全性弱，在开发时要花费很大精力在安全性和速度上。

在本系统中，考虑到漏液监测实时性要求高的特点，同时使用的用户固定单一，所以选择C/S架构模式，使用阿里云物联网平台作为C/S架构的服务器端，采用Qt开发的管理员和维修员的操作软件作为C/S架构的客户端。

6 阿里云物联网云平台配置

阿里云物联网平台是一个集成了设备管理、数据安全通信和消息订阅等能力的一体化平台，为客户端和设备端组建了一个安全可靠的通信网络[19]。该平台支持大体量设备接入，并可将远端采集数据进行上报，由云端服务器进行存储。同时云端提供大量已封装完成的API接口，服务器可直接使用这些接口，将指令下发至分布式设备端，并实现对设备的远端调用及控制能力。

该平台的使用十分简单快捷，仅需提前向平台注册设备端ID，端口号，MQTT协议版本，心跳回包时间间隔，用户名及密码等，通过Internet网络，使用QT基础库中的publish方法发送消息，received方法接收消息，通过QT独有的槽信号机制，也可通过槽函数来实现对消息的接收和处理操作。

客户端云设备和设备端对应的云设备的注册分为创建产品、自定义Topic和创建设备3个步骤。在本系统中，按照所提的3个步骤进行注册操作。

创建产品时，需要指定必要的信息，如：产品名称(液漏监测系统)，品类(自定义类型)，设备链接方式(直连)，联网方式(以太网/WIFI)，数据格式(ICA标准数据格式)，认证方式(设备密钥)。设置完这些字段后，产品创建即为成功。

自定义Topic时，需要两个Topic，其一为发布主题，提供客户端到设备端间的启动/停止交互命令传输，其二为订阅主题，提供设备端到客户端的液漏详细数据传输。

创建设备时，可在该平台提供的web页面中，点击创建设备页面，在产品下拉框中选择液漏监测系统，为其命名设备名称以及备用名称。点击设备详情页面，获取设备名(DeviceName)、产品鉴权(ProductKey)、设备密钥(DeviceSecret)，同时可获取MQTT协议相关链接参数：客户端ID(ClientId)、用户名(UserName)、密码(Password)。通过这些参数的设置，即可将整个监测系统、客户端全部接入该平台，点击连接即可激活设备，此时，整个系统即可完成全部接入。

7 数据库设计

为保证液漏信息、状态的可复盘，本系统也设计使用了数据库作为存储介质，将液漏点位，液漏上报时间，维修完成时间做存储，以便更清晰的展示年度、月度大盘数据，供企业相关管理人员进行故障分析、定损额度的确定。数据库的设计如表1所示。

表1 数据库表结构设计

本系统采用sqlite作为数据库，sqlite的最佳使用场景主要包括以下几点：1)嵌入式设备和物联网。2)应用程序的文件存储格式。3)大多数中低流量网站。4)数据分析。5)企业数据缓存。6)服务器端数据库。7)数据传输格式。8)文件归档或数据容器。9)替换临时磁盘文件。本系统中将其用于场景1所使用。

8 MQTT协议在传感端的实现

设备端通过Wi-Fi网络连接至服务器，使用MQTT协议作为服务器和Wi-Fi模块之间的通信协议。本系统选择了ESP8266做为Wi-Fi传输模块，ESP8266是一款高性能、超低功耗的异步串行通信接口无线Wi-Fi模块[20]。 传感端主函数流程图如图7所示。

9 接收端设计

Qt针对每一种操作系统的平台，都有一套对应的底层类库，且接口是完全一致的[21]。因此，在基于Qt框架所开发的应用程序中，在添加相应的基础库之后，就可以直接编译运行。基于Qt跨平台的特性，系统的接收端采用Qt开发，该软件既可在Windows系统中使用，也可在Android系统中使用，一次开发即可满足客户端在不同平台的复用。

通过该接收端，系统管理员可以实现现场或远程启动/停止监测、接收液漏消息、发送维修信息给系统维修员，同时也支持维修状态查询等功能，从而实现对系统的实时监测，在方便了工作人员的同时避免了严重后果的发生。系统管理员界面如图8所示。

图8 管理员界面设计图

系统维修员通过接收端实现已维修点位、未维修点位的信息查看，未维修点位信息中包含发生液漏后需要及时维修的点位信息，以及维修完成后需要填写的维修单，同时在维修员的界面显示有液漏监测设备的相关信息。系统维修员界面如图9所示。

图9 维修员界面设计图

10 MQTT协议在接收端的实现

在本系统中，接收端和服务器通信主要包括以下3个部分[22]：

1)建立连接。接收端通过connect控制包来连接MQTT服务器，服务器在信息匹配成功后建立连接，同时发送CONNACK包给接收端表示同意本次连接，建立起接收端和服务器端的连接通道。

2)主题订阅。建立连接后，接收端向服务器端发送SUBSCRIBE包订阅关于液漏的相关主题报文，当传感端发送此类主题报文到服务器端后，服务器端将此类报文发送到接收端。

3)消息发布。建立连接后，接收端向服务器端发送对传感系统的控制命令，服务器端收到之后下发给传感端，传感端解析命令后执行相应的操作，最终实现远程控制传感端的功能。

根据接收端和服务器通信的过程，设计接收端的系统架构主要包括业务层、协议层、逻辑层、运算层和数据层。业务层的主要功能是显示、接收和传递用户的反馈，同时提供交互式操作界面[23]。协议层提供可靠的数据传输服务。逻辑层将协议层传过来的操作信息进行甄别处理，实现具体的业务逻辑[24]。运算层封装了数据库，提供了对数据库增删改查的操作接口[25]。数据层用来存储用户信息、系统发生液漏信息、维修情况信息等数据[26]。接收端的系统架构图如图10所示。

图10 接收端设计架构图

11 系统测试

11.1 系统管理员操控测试

系统管理员在PC端输入相应的账号密码登陆系统后，对传感端下发启动监测的命令，命令包经MQTT协议发送给传感端，传感端对命令进行相应解析后，执行启动监测的硬件操作，开始向服务器不断传送液漏监测的数据包，服务器将该数据包发送给管理员客户端，管理员客户端在收到数据包后及时对数据进行解析，判断是否发生液漏，若发生液漏，则及时将该液漏信息反馈给系统维修员。系统管理员操作系统的时序图如图11所示。

图11 系统管理员操控系统时序图

在实际测试中，将系统搭建连接好后，给传感带的第2条灯带的第1个点位注水， 10 s左右后，用作测试的客户端收到液漏的消息，客户端的界面如图12所示。当停止对该点位注水，管理员客户端界面不再提示发生液漏。

图12 发生液漏后管理员客户端界面

11.2 系统维修员操控测试

发生液漏后，系统会通过短信的方式以1次/min的频次向系统维修员发送告警信息，当系统维修员回复“确认收到”之后，告警停止。维修完成后，在客户端的移动端输入相应的账号密码登录在系统上提交维修单据供系统管理员核验。系统维修员操作系统的时序图如图13所示。

图13 系统维修员操控系统时序图

在实际测试中，当传感带的第2条灯带中第1个点位发生液漏时，管理员客户端将该液漏信息发送给服务器后，维修员客户端登录系统后，客户端显示界面如图14所示。

图14 发生液漏后维修员客户端界面

12 结束语

针对实验室设计的高分辨率且成本低廉的液漏传感系统不能实现远程监测的问题，本文基于轻量级的MQTT协议，实现了液漏监测的远程通信，使用Qt的跨平台特性，开发了windows和Android系统都可使用的接收端软件。经测试表明，该系统能够实现对液漏监测数据的高效远程采集，提高了液漏的维修实时性，避免了产生更大范围的液漏所带来的严重后果，具有较高的应用推广价值。