物联网技术不断发展和完善&＃xff0c;其在社会各领域中逐渐得到推广和应用。在环境监测领域&＃xff0c;存在监测范围广、传感器数量多及节点数据上传频繁等特征&＃xff0c;人们一直致力于发展高效的通信技术&＃xff0c;以实现更低的功耗、更远的通信距离、更大的覆盖范围[1]。物联网的通信手段从ZigBee、Wi-Fi和蓝牙等传统技术&＃xff0c;发展到目前国内热度极高的窄带物联网(Narrow Band Internet of Things&＃xff0c;NB-IoT)、长距离通信(Long of Range&＃xff0c;LoRa)等低功耗广域网技术[2]。各大物联网企业都相继推出针对这两种新技术的解决方案。这些方案架构大致相似&＃xff0c;例如中兴的LoRaWAN解决方案&＃xff0c;其涵盖终端层、网关层、云平台层及应用层&＃xff0c;在应用层提供丰富的功能&＃xff0c;如查看历史数据报表、异常信息告警、数据分析和设备控制等。但针对不同应用场景&＃xff0c;需要实现个性化功能时&＃xff0c;平台提供的操作接口都比较单一&＃xff0c;很难满足二次开发的需求。目前&＃xff0c;基于LoRaWAN协议的监测系统开发&＃xff0c;大部分开发者均选择图1所示的方案架构。该架构包含终端层、传输层、网络层和应用层四层。网络层又由LoRa服务器、Web服务器(Web网络应用服务器)和数据库三部分组成。该分层架构为开发人员提供了更多的操作空间&＃xff0c;系统的灵活性与可扩展性更强。
实验室安全监测属于室内环境监测中的一类&＃xff0c;该应用场景主要功能需求如图2所示。安全监测系统集中管理多个区域的实验室&＃xff0c;各实验室内主要配置温湿度传感器、烟雾报警传感器等终端设备。终端周期采集数据&＃xff0c;并上传至数据中心进行集中处理&＃xff0c;各实验室管理人员登录应用层网页端页面和移动端App时&＃xff0c;均能查看其管辖实验室内所有终端最新采集数据&＃xff0c;接收异常数据的告警信息。对于终端上传的非紧急类异常数据信息&＃xff0c;如超出阈值的温湿度数据&＃xff0c;应用层无须即刻获知此信息&＃xff0c;但对于烟雾报警等紧急类异常消息&＃xff0c;须在尽可能短的时间内被通知到管理人员并得到妥善处理&＃xff0c;以免酿成重大安全事故。可见&＃xff0c;环境监测系统在应用于实验室安全管理时&＃xff0c;系统数据传输的即时性尤为重要。然而&＃xff0c;图1所示架构应用在此场景时&＃xff0c;实现的监测系统却不能展现出较好的实时性。对于图1架构&＃xff0c;其网络层采用数据库系统作为终端层采集数据的存储中转站&＃xff0c;LoRa服务器接收处理所有终端数据并存入数据库&＃xff0c;Web服务器(WS)通过读取数据库来获得最新终端数据以响应应用层数据请求。这类“拉取”式的通信方式在本质上就会为系统带来不同程度的延时[3]。并且&＃xff0c;终端数量众多&＃xff0c;系统长期运行&＃xff0c;使得数据库存储着大量的记录&＃xff0c;数据读取操作耗时过长&＃xff0c;这也导致WS延时响应应用程序请求。
考虑上述问题&＃xff0c;并针对实验室安全监测应用场景&＃xff0c;本文基于现有方案架构&＃xff0c;在LoRa服务器与WS间建立基于MQTT协议的通信链路&＃xff0c;取代基于数据库读取的数据共享方式&＃xff0c;实现WS对终端数据的即时获取。同时&＃xff0c;系统引入WebSocket通信技术&＃xff0c;实现WS与应用层程序的实时数据传输。并且&＃xff0c;针对监测系统同时对多个监测区域进行统一管理、分区展示的应用需求&＃xff0c;为系统设计数据推送策略&＃xff0c;进一步提高系统数据交互实时性。
1 相关技术介绍
WebSocket协议在单个TCP连接上实现全双工通信[4]&＃xff0c;其工作机制基于订阅-发布模式。WebSocket通信的建立过程如图3所示。Websocket复用HTTP通道&＃xff0c;两者使用相同的TCP端口。在Web端网页开发中&＃xff0c;WebSocket协议已被纳入HTML5规范中&＃xff0c;现代主流浏览器都支持此协议的使用。
消息队列遥测传输协议(Message Queuing Telemetry Transport&＃xff0c;MQTT)是IBM发布的一种“轻量级”、基于发布-订阅机制的协议。该协议基于TCP/IP协议&＃xff0c;提供可靠、有序与双向的数据传输机制[5]&＃xff0c;在物联网领域应用广泛。发布-订阅机制中存在三种角色&＃xff1a;发布者、订阅者和代理[6]。发布者将特定主题标识的消息发送给代理&＃xff0c;然后代理将该消息转发给对该特定主题感兴趣的每个订阅者。
2 延时原因分析及解决方案
分析图1方案构架&＃xff0c;以第一时间将终端层数据传输到应用层程序为基准&＃xff0c;对系统通信过程中存在的延时做时段划分&＃xff0c;如图4所示。
第一类延时的长短由通信网络情况的优劣决定。对于通信时段T1、T2&＃xff0c;在LoRaWAN通信组网、LoRa网关与LoRa服务器之间的网络越好&＃xff0c;其数据传输延时越小。
第二类延时由系统进行数据处理产生。时段T3是LoRa服务器接收处理网关上传数据&＃xff0c;并进行数据存储时系统内部操作用时&＃xff0c;该部分时长主要与搭载运行LoRa服务器的硬件设备相关&＃xff0c;设备处理速度越快&＃xff0c;T3时段用时越短。时段T4主要由WS读取数据库产生&＃xff0c;数据库表中纪录越多&＃xff0c;数据读取耗时越长。时段T5涵盖从应用程序发起请求到收到响应整个过程&＃xff0c;主要由两部分组成&＃xff0c;一是数据包在网络通道中的传输&＃xff0c;显然&＃xff0c;此处的时长同样与网络情况相关&＃xff1b;二是WS请求处理时间&＃xff0c;若WS运行内存充裕&＃xff0c;则此处耗时较小&＃xff0c;但若在高并发场景&＃xff0c;WS资源的耗尽将导致其不能即刻响应应用程序请求&＃xff0c;则此部分的时长无法确定&＃xff0c;最坏情况下甚至会丢失请求&＃xff0c;应用程序无法获取到数据响应。
对于上述两类延时&＃xff0c;通过使用通信稳定的硬件设备&＃xff0c;确保底层终端数据正常传输&＃xff0c;并为系统配置满足应用场景需求的硬件处理设备&＃xff0c;最大程度地减少T1、T2、T3时段的延时。本文将重点解决T4与T5两个时间段存在的延时&＃xff0c;该部分主要涉及应用程序与WS间的通信及WS的数据库操作。
目前&＃xff0c;Web页面程序多选用轮询技术来实现与WS的实时通信[7]&＃xff0c;频繁地发起HTTP请求来模拟实时数据传输。考虑本文应用场景的特点&＃xff1a;各类终端上传数据的周期各异&＃xff0c;即便上传周期相同&＃xff0c;因设备并非在同一时间开机运行&＃xff0c;数据上传时刻也将不同。故Web页面主动发起的请求若周期大&＃xff0c;无法获取所有终端最新数据&＃xff1b;若周期小&＃xff0c;过于频繁地请求也必将加重服务器的负担&＃xff0c;降低系统整体响应速度。为了避免上述情况&＃xff0c;本文将数据传输的主动方从应用程序端转换到WS端。选用WebSocket通信技术&＃xff0c;实现WS主动将终端采集数据发送至Web页面&＃xff0c;进而从根本上实现页面与WS间的实时数据传输。
考虑移动应用App&＃xff0c;若其与WS时刻保持长连接将占据移动设备大量资源&＃xff0c;且考虑管理员无须时刻查看终端数据&＃xff0c;故两者通信仍采用HTTP协议即可。对于需要及时处理的异常信息&＃xff0c;例如烟雾传感报警&＃xff0c;通过在WS启用短信及邮件服务&＃xff0c;将告警信息及时通知到对应管理人员。
转变页面程序与WS间数据通信主动方后&＃xff0c;需要考虑WS应在何时推送数据至应用程序。图1架构中&＃xff0c;所有终端上传的数据均经由LoRa服务器处理并存储至数据库。若WS仍采用周期读取数据库的方式来获取最新终端层数据&＃xff0c;读取间隔选取和读取操作耗时问题仍存在。本文在LoRa服务器和WS间建立MQTT通信服务&＃xff0c;使其在接收到终端数据时&＃xff0c;立即发布终端数据至WS&＃xff0c;WS接收处理完数据后&＃xff0c;即刻推送数据消息到应用程序。对接收的每条数据信息&＃xff0c;WS在将结合该终端更多基本信息&＃xff0c;对数据进行综合处理。为实现更加快速的基本信息查询&＃xff0c;搭建基于内存的高速缓存数据库&＃xff0c;存储系统内终端基本信息。本文仍保留传统架构中涵盖的数据库系统&＃xff0c;用于持久化存储全部终端数据记录&＃xff0c;以便系统功能拓展。
至此&＃xff0c;WS与应用程序、WS与LoRa服务器间&＃xff0c;双方均保持双向、实时通信。本文实验室安全监测系统最终架构如图5所示。
3 系统解决方案实现
系统主要模块如图6所示。下面将对应用程序层、LoRa服务层进行简要阐述&＃xff0c;并对应用服务层做详细阐述。
3.1 LoRa服务层实现
LoRa服务层除实现基于LoRaWAN协议的硬件设备通信服务外&＃xff0c;由于还负责维护与应用服务层间数据的传输&＃xff0c;需再实现MQTT数据传输服务。本系统选择Mosquitto代理服务器来搭建一个MQTT消息中间件。服务器端本地安装Mosquitto并在默认端口1883开启服务&＃xff0c;并定义数据发布主题“loraPub”。LoRa服务器端每收到一次终端数据&＃xff0c;将开启一个新进程&＃xff0c;通过MQTT服务发布所接收数据。
3.2 应用服务层实现
应用服务层既需监听LoRa服务层发布数据&＃xff0c;将其快速传送至相应应用程序&＃xff0c;也需为应用程序层提供访问连接服务&＃xff0c;并对访问连接进行管理。为了最大程度减小应用程序层数据更新的延时&＃xff0c;本系统实现结合WebSocket与MQTT通信的服务模块。设计数据缓冲层&＃xff0c;存储常用信息于内存中&＃xff0c;减少数据读取耗时。为实现同时对多区域进行实时监管&＃xff0c;设计数据推送及异常告警模块&＃xff0c;保证终端数据被解析处理后能推送至正确应用程序。数据缓冲层中保存着系统运行中所有在线WebSocket客户端的连接数据&＃xff0c;为数据推送模块提供数据参考。同时&＃xff0c;由于在网络不稳定、断网等异常情况下&＃xff0c;WebSocket服务端无法及时感知客户端断开连接。为使数据推送更加高效&＃xff0c;设计巡检模块实时监测客户端连接情况。下面将对该层实现进行详细说明。
3.2.1 通信模块实现
系统运行中常出现LoRa服务层同时接收大量数据包的情况&＃xff0c;导致WS端常需同时支持多个MQTT通信服务。系统需有应对高并发连接的能力。Node作为一种新型的Web服务器&＃xff0c;在很多场景下展现出极强的高并发处理能力[8]&＃xff0c;本文选择它作为系统的WS的具体实现&＃xff0c;并使用Express应用框架创建Node服务&＃xff0c;基于该服务&＃xff0c;实现WebSocket、HTTP及MQTT通信服务。
Node端安装MQTT库&＃xff0c;通过访问Mosquitto服务器与LoRa服务层建立通信连接。订阅主题“loraPub”&＃xff0c;通过node_mqtt模块提供的on方法监听LoRa服务层数据的发布。安装Socket.io库WebSocket服务&＃xff0c;配置HTTP与WebSocket开启同一端口号3000使两个通信服务共存。
3.2.2 数据存储模块实现
使用Redis数据库实现系统高速数据存储&＃xff0c;Redis是基于内存的&＃xff0c;以“键-值”形式对数据进行存储的数据库[9]。数据库存储内容及详情如表1所示。键NODE、USER分别用于保存终端信息和用户信息。键onlineClient用于管理系统运行中的WebSocket连接客户端信息&＃xff0c;在非客户端主动断开连接的情况下&＃xff0c;实时记录登录客户端的连接状态&＃xff0c;作为后续高效数据推送的依据。
表中area字段表示节点/用户所属区域&＃xff0c;pwd代表用户名对应登录密码&＃xff0c;type代表终端节点类型&＃xff0c;posx、posy表示终端在Web展示页面上对应的坐标位置。sid标识每个Socket连接会话的id&＃xff0c;这是一个随机生成唯一标识&＃xff0c;每一次新的连接建立&＃xff0c;其对应一个新的sid&＃xff0c;定义该键有两种取值&＃xff0c;0代表该连接客户端离线&＃xff0c;1代表该连接客户端在线。
服务端本地安装Redis数据库并开启服务。Node端安装Redis库&＃xff0c;并连接本地Redis服务器。内存中建立WSClient对象变量&＃xff0c;以sid为键&＃xff0c;其对应所属区域area为值&＃xff0c;实时记录所有与Node服务端保持连接状态的会话信息。
3.2.3 巡检点名模块实现
Web页面与WS建立WebSocket连接&＃xff0c;并订阅“devMsg”主题监听数据发布。为实现WS实时感知WebSocket客户端连接情况&＃xff0c;页面程序中自定义“myPing”主题的周期心跳发布。WS每监听到一个“myPing”主题数据&＃xff0c;便在onlineClient中修改对应sid的状态值为1。WS将把监听同一区域数据的连接会话分配至同一room&＃xff0c;并以区域名命名该room。利用库提供的rooms、join和leave等相关操作方法&＃xff0c;建立如图7所示巡检点名流程&＃xff0c;实现服务端对连接会话的状态监测。
WS在周期读取键onlineClient中数据&＃xff0c;判断所有记录会话连接状态。所有离线会话将被全局记录量WSClient和Socket中所属对应room中移除。每次巡检最后&＃xff0c;都会将所有会话状态重新置0&＃xff0c;WS重新等待Web页面上传的心跳。巡检点名模块实现了WS对会话连接情况的精准掌握&＃xff0c;为其实现高效数据推送提供参考。
3.2.4 数据推送模块实现
系统若不为WS设计一套数据推送策略&＃xff0c;其在监听到LoRa服务器的数据时&＃xff0c;将不加区分地发送数据至所有在线Web页面&＃xff0c;这将带来数据安全问题。且浏览器会因为耗时处理多余的数据&＃xff0c;令真正需要处理的数据等待更长时间。本系统设计数据推送方案&＃xff0c;减小此情况引起的页面数据渲染延时。
WS在启动时即与LoRa服务层的Mosquitto服务器建立连接&＃xff0c;并订阅“loraPub”主题&＃xff0c;监听LoRa服务层的数据发布。Web页面与WS建立WebSocket连接后&＃xff0c;WS将启动巡检点名模块对Web页面的连接状态进行实时监听。WS工作流程如图8所示。
LoRa服务层发布数据时&＃xff0c;数据以字符串“dev_eui#data”形式传输。该字符串包含终端编号与数据值&＃xff0c;并以字符“#”作为分隔符。当WS监听到数据时&＃xff0c;先对接收到的字符串进行解析&＃xff0c;获取设备编号&＃xff0c;并根据设备编号查找出该设备所属区域area及其余基本信息&＃xff0c;若此时全局记录对象WSClient中存在监听该区域的在线会话端&＃xff0c;则将推送数据到对应的Web页面&＃xff1b;若此时WSClient中无监听该区域的在线会话&＃xff0c;则不执行数据推送操作。若此时判断出数据异常&＃xff0c;例如&＃xff0c;烟雾传感器状态值异常等&＃xff0c;WS将启动短信邮件服务&＃xff0c;发送异常告警信息到对应实验室管理员。具体数据推送流程如图9所示。
3.3 应用程序层
应用程序层由Web端界面和移动App组成。WS开启短信、邮件服务&＃xff0c;将异常信息实时发送至管理员&＃xff0c;当App捕获到设备接收到告警信息时&＃xff0c;将调用手机闪关灯及扬声器等硬件设备&＃xff0c;触发声光报警&＃xff0c;再次提醒管理人员。APP端同时为用户提供信息注册、数据查看等基本功能&＃xff0c;用户主动查看数据时&＃xff0c;通过向应用服务层发起HTTP请求来获取最新数据。对于Web页面展示&＃xff0c;核心功能是为各实验室管理人员实时展示其管辖实验室内所有终端最新采集数据。使用Vue.js前端库来编写Web端应用程序&＃xff0c;利用其“虚拟节点”和“数据绑定”特性[10]&＃xff0c;Web页面能对接收数据进行快速渲染&＃xff0c;减小视图更新延时。Web页面与WS间的WebSocket通信通过Socket.IO模块中的socket.io-client库进行实现。
4 功能与性能测试
系统搭建环境为华中师范大学九号教学楼二楼各个实验室&＃xff0c;在各室中安装LoRa烟雾节点及温湿度节点&＃xff0c;LoRa服务层均能正常接收所有终端节点上传数据。
4.1 功能测试
主动触发对二楼监测区域内209室的烟雾报警节点&＃xff0c;仅二楼管理员监看界面在209室位置显示异常告警图标&＃xff0c;并播放告警音乐&＃xff0c;页面通知栏也立刻播放告警信息。二楼区域的其他管理员&＃xff0c;即使未登录网页页面&＃xff0c;也将收到邮件提醒及App端的声光报警。具体告警实现如图10所示。
4.2 性能测试
采用自动化测试工具Apache ab对系统进行测试。为了排除网络的不稳定性对测试结果的影响&＃xff0c;配置本系统WS与应用程序的网络处于同一交换机的同一局域网下。对于数据推送方案的用时测试&＃xff0c;由于减少了不必要的数据推送及页面渲染处理&＃xff0c;系统的延时将必定得到减小。
测试系统数据传输延时。定义数据传输时间为WS监听到LoRa服务层数据&＃xff0c;到Web页面收到所监听区域内所有终端数据并完成视图渲染的全程总用时。对比传统轮询数据库查询方式&＃xff0c;分别测试监测区域内有单个/多个终端时&＃xff0c;数据传输时长&＃xff0c;测试结果如图11所示。可见&＃xff0c;本系统的通信延时明显低于传统方案&＃xff0c;且监测范围内终端越多&＃xff0c;本系统优势越明显。并且&＃xff0c;对基于Ajax轮询的数据传输用时测试时&＃xff0c;是基于所有终端均在同一时刻完成数据采集上传&＃xff0c;Web页面零延时发起请求&＃xff0c;实际最新数据更新到Web页面会有更长的时延。
5 结论
本文分析了环境监测领域中&＃xff0c;基于LoRa技术的解决方案的应用现状&＃xff0c;并针对实验室安全监测这一特殊应用场景时&＃xff0c;系统无法满足高实时性需求这一问题&＃xff0c;在现有解决方案架构中引入MQTT与WebSockt通信技术&＃xff0c;并结合使用Redis数据存储技术、Node.js服务端技术等&＃xff0c;减小监测系统通信的整体延时。并针对系统需集中管理多个监测区域的实际应用场景&＃xff0c;设计了服务端数据推送策略&＃xff0c;使得Web页面能高效接收对应监管区域数据&＃xff0c;进一步降低系统数据更新时延。
参考文献
[1] 刘伟&＃xff0c;胡安林.无线传感器网络覆盖率与节能性研究[J].电子技术应用&＃xff0c;2016&＃xff0c;42(6)&＃xff1a;98-100&＃xff0c;104.
[2] 邵嘉&＃xff0c;庞成鑫&＃xff0c;卢小姣&＃xff0c;等.LPWAN技术在能源物联网领域应用研究[J].物联网技术&＃xff0c;2018&＃xff0c;8(12)&＃xff1a;44-47.
[3] 吴丽梅&＃xff0c;韩利峰&＃xff0c;黄文博&＃xff0c;等.实时Web技术在辐射监测系统中的应用[J].计算机应用&＃xff0c;2018(S2)&＃xff1a;337-340.
[4] 张玉清&＃xff0c;贾岩&＃xff0c;雷柯楠&＃xff0c;等.HTML5新特性安全研究综述[J].计算机研究与发展&＃xff0c;2016&＃xff0c;53(10)&＃xff1a;2163-2172.
[5] 朱明辉&＃xff0c;赵信广&＃xff0c;尤星懿.基于FreeRTOS和MQTT的海洋监测网络框架[J].电子技术应用&＃xff0c;2018&＃xff0c;44(1)&＃xff1a;41-44.
[6] ADHITYA B.A publish subscribe based middleware for enabling real time web access on constrained device[C].2017 9th International Conference on Information Technology and Electrical Engineering(ICITEE)&＃xff0c;2017&＃xff1a;1-5.
[7] 张艺.基于WebSocket的即时通信系统研究与实现[J].软件&＃xff0c;2015&＃xff0c;36(3)&＃xff1a;89-94.
[8] LIANG L&＃xff0c;ZHU L&＃xff0c;SHANG W&＃xff0c;et al.Express supervision system based on NodeJS and MongoDB[C].IEEE/ACIS International Conference on Computer & Information Science.IEEE&＃xff0c;2017.
[9] 李鹏鹏&＃xff0c;郑扬飞&＃xff0c;刘玉龙.Redis在即时通讯系统中的应用[J].软件&＃xff0c;2017&＃xff0c;38(1)&＃xff1a;115-119.
[10] 麦冬&＃xff0c;陈涛&＃xff0c;梁宗湾.轻量级响应式框架Vue.js应用分析[J].信息与电脑(理论版)&＃xff0c;2017(7)&＃xff1a;58-59.
作者信息:
张 丽&＃xff0c;李 达&＃xff0c;刘辉席&＃xff0c;刘守印
(华中师范大学 物理科学与技术学院&＃xff0c;湖北 武汉430079)
京公网安备 11010802041100号