基于LoRa的远程监测系统设计

2019-06-25周治平

传感器与微系统 2019年7期

张敏, 周治平

(江南大学物联网工程学院，江苏无锡 214122)

0 引言

随着网络技术的不断发展，远程监测技术出现在人们的生活和工作中。不可否认，物联网软件、安全、云计算以及用户接口已经趋于成熟，无线短距离通信技术，如WiFi、ZigBee、蓝牙等均能实现远程监测需求[1]，且在实际中已存在着较多应用案例。文献[2]讨论了基于通用分组无线业务(general packet radio service,GPRS)和ZigBee技术的嵌入式智能家居控制系统，通过ZigBee技术实现主控制器和终端节点之间的通信。而移动客户端实现家庭设施的信息采集和远程监控；文献[3]提出以太网与CC-Link相结合的远程控制系统，实现对温室大棚的远程监控；文献[4]提出心电图(electro-cardio-graph,ECG)远程监控系统，专门针对需要在居住环境中进行长期健康监测的非技术用户。以上这些应用采用了不同的无线通讯方式，均实现了远程监控的需求，但环境监测、烟雾报警、电力监测这些应用所需数据量较小，对实时性要求并不高，无需进行频繁通信，而这些监测系统却消耗大量功耗在监听网络随时可能发起的请求上，在需要大面积进行传感器部署时，存在很大的资源浪费。文献[5～7]均采用LoRa技术既满足了大量连接需求，且节点无需时刻处于监听状态，在保证远距离通信传输的同时，可以最大限度地降低功耗，节约成本[8]。但目前已实现的基于LoRa的监测系统存在着可扩展性弱、运行效率低的问题，大多系统只是针对于某一参量的信息采集，且部署的服务器端大多数基于虚拟机，运行效率较低。

本文设计了一种基于LoRa的远程监测系统，采用Docker容器技术[9]部署服务器端，大大提高运行效率，多种应用可并行运行，管理人员可通过监控管理平台进行应用和节点管理。为网络避免拥塞，在LoRaWAN的基础上采用了ADC-MAC协议[10]来提高LoRa网络性能。此外，用户可通过服务器提供的串口通讯接口，调用数据库数据，设计应用Web界面，实现数据可视化。

1 系统总体设计

1.1 系统架构设计

基于LoRa的远程监测系统架构如图1所示。针对多种应用的数据采集子系统中，含大量内嵌SX1278射频模块的传感器，它们采集到的信息经由一个或多个网关发送至对应应用的子数据库中，同时同步到总数据库，后台调用管理数据库，并在监测管理平台显示。用户可以客户或管理员身份登录监测管理平台进行数据查询，节点管理等等。

图1 系统架构

1.2 系统硬件设计

数据采集子系统主要包括检测模块、数据处理模块以及无线传输模块，负责采集参数，进行简单处理，经由无线传输模块发送数据至网关。

1)检测模块：根据应用的不同，接入的传感器也不尽相同，用户根据所需接入相应的传感器。

2)数据处理模块：主要由STM32系列微处理器组成。STM32是基于ARM Cortex-M3处理器内核的32位闪存微控制器[11]，专为高性能、低成本的嵌入式应用设计。

3)无线传输模块：SX1278射频芯片是其核心，用于超长距离扩频通信，灵敏度可达-148 dBm,最大链路预算可达168 dB，抗干扰能力强，能最大限度地降低电流消耗。

数据传输子系统由多个网关组成，功能框图如图2所示，其CPU基于ARM11处理器，内存为512KB RAM+4GB EMMC,采用硬件看门狗定时器电路，监控主程序运行，避免进入死循环。

图2 网关功能框图

2 系统软件设计

2.1 环境构建与功能设计

本文设计的监测管理平台是一个私有云平台，网络专用，内网传输，安全性较高。平台采用Docker技术，将多个Web服务组件部署在多个Docker容器上，然后将整个Web服务系统组件连同其运行环境固化成Paas服务，向云端迁移和扩展。后台数据的存储采用mysql为主存储，redis为辅助存储形式减少对数据库的访问，提高性能。采用Nginx结合Lua脚本连接操作MySQL的方法，为避免短时间保持客户端与服务端的连接状态，在频繁通信的情况下，容易发生Socket出错的情况，MySQL选用长连接方式，以确保数据传输的稳定。整个系统功能设计如图3所示。

图3 系统功能框图

数据采集子系统是所有数据的来源，通过安放在监控区域多个传感器采集数据。该子系统的任务是将采集到的数据经由GPRS模块传输至数据库。数据中心包含各应用的子数据库及总数据库，两者之间数据同步。根据用户需求不同，分为客户和管理员两种身份，以保证平台的安全性和规范性。客户主要是负责自己所辖应用的管理工作，具体包括应用创建、节点管理。管理员是整个平台的管理者，负责用户信息管理、应用管理、节点监控及数据维护。平台功能可分为5个模块用户认证与权限管理、数据接入和存储、数据查询管理、监测管理、异常情况报警。

2.2 LoRaWAN规范实现

2.2.1 ADC-MAC规范概述

LoRaWAN规范是星型拓扑结构，终端连接网关是直接通过LoRa无线链路的。根据实际情况，LoRaWAN将设备分成A、B、C三种类型，A类功耗最低。在A类中，终端以ALOHA类型按照自身要求发送数据包，在发送上行链路后，终端打开两个下行接收窗口，剩余的时间便进入睡眠状态。在接收到任何窗口的下游消息，终端才会安排下一个上行链路。终端下一次访问信道的时间是由终端本身决定的而不是其他因素，这种机制并不考虑节点负载、不同监测点的位置以及无线传感网的大小，很容易导致网络拥塞。为解决这个问题，采用了ADC-MAC协议来平衡能源功耗和网络性能。

在该协议中，每个终端异步和动态调整占空比都是基于3个指标：残余能量指标、节点负载指标和网络拥塞指标。残余能量指标

(1)

式中Eremaining为传感器节点残余能量，Einitial为节点初始能量。节点负载指标如下

(2)

式中Nbuffer为由传感器节点缓冲的当前数据包数量，Nmax为传感器节点生成的总数据包量。

LoRa网关和终端支持多信道通信，将信道表示为i∈(1,…,N)。在一个周期T内，终端存在一个上行计数器Chanl_up_Cnt[i]，当终端在任意信道上发送一个数据包，这个信道相应的上行计数器加1。同时重发计数器Chal_Re_Cnt[i]计算重发次数，当终端没有在预定时间内接收到ACK字符，相应的信道计数器加1。终端会随机选择另外的信道重新传输。一个周期后，终端计算出信道的繁忙率

(3)

从而计算出网络繁忙度如下

(4)

通过网络拥塞指标更精确反映网络交通负载

(5)

2.2.2 ADC-MAC协议流程

步骤1:在每个终端入网后，会记录初始的包缓冲区，初始化任务周期φ，并将定时器1设为周期T。

步骤2:如果终端工作在第一个周期T中，使用初始化的占空比通信，否则使用计算后占空比。当终端传输上行链路时，记录传输时间Tt并将定时器2设为T2=Tt(1/φ-1)。这样除了在固定时间内打开窗口1,2接收下游消息;

步骤3:当定时器2结束后，如果有数据等待发送，终端会返回至步骤2，否则继续处于休眠状态，等待下一个数据传送。

步骤4:终端等待定时器1结束，计算3个指标，残余能量α指标、节点负载β、网络拥塞率γ，并计算占空比φ=(α+β)/2γ+η用于下个周期。

步骤5:终端将上行计数器Chanl_up_Cnt[i]、信道繁忙率σ[i]和重发计数器归零Chal_Re_Cnt[i]，但需要保持网络拥塞率γ用于在下个周期T中衡量网络运行负载。同时，终端将设置好定时器1，跳转到步骤2中。

2.2.3 数据获取与调用

LoRa网络所有节点均是双工通信，但主要以传感器上行传输数据为主。图4为系统的软件流程。系统采集数据是通过WebSocket消息传送获取的，写入数据库中便于数据调用。在建立WebSocket连接时，必须在地址中加入创建的应用标记appEUI和用来客户调用API安全验证userSec加密的token，服务器验证通过才能建立WebSocket连接，否则连接失败。在成功连接MySQL后，结合Lua中的Template组件，直接写入动态数据，渲染成页面，响应前端。

图4 系统软件流程

2.3 数据协议设计

考虑到从传感器采集到的每一帧数据编码不一致，需重新编码打包发送至网关，编码规则如下：每一帧由16位字节表示，其中包含2字节帧头、1字节设备号、12字节所要传输的数据、1字节校验位，严格遵循着LoRaWAN规范物理层(physisal layer,PHY)上行射频帧的模式。表1为温湿度应用中消息包的格式。

表1 消息包格式

系统Server端包括网络服务器，应用服务器和客户端，网络服务器直接与网关通信，其工作为：1)验证数据的合法性。2)从网关的信息中提取数据，整理成JSON数据包。3)将校验合法的数据打包成新的JSON数据包上传至应用服务器。应用服务器负责将上传的JSON包的Payload部分进行解密。之后，客户端将应用服务器的数据处理成用户自定义的数据格式。

3 温湿度监测设计

针对系统可扩展性强、多应用特征，设计了温湿度监测应用。Web界面设计是基于OpenResty平台如图5所示，通过Socket通信实时调用数据库中的节点数据，以图表方式呈现。左边下拉菜单选择设备号，查看实时温度、湿度、压强，其中温度参数实时绘制成了折线图，动态添加数据时，曲线左移，可直观看出24 h内的温度变化趋势可直接查看某一时间点温度值。此外，监测管理平台可以管理应用节点，查看节点状态及历史数据。实验证明，本文设计的监测系统运行稳定，给开发应用提供了很大的便利。