基于物联网的电梯安管系统通信模块①

冯 雪, 孙丙宇, 方 薇, 吴 斌(中国科学技术大学 信息科学技术学院, 合肥 006)(中国科学院合肥智能机械研究所, 合肥 00)(安徽中科智能高技术有限责任公司, 合肥 0088)

基于物联网的电梯安管系统通信模块①

冯 雪1,2, 孙丙宇2, 方 薇2, 吴 斌31(中国科学技术大学 信息科学技术学院, 合肥 230026)2(中国科学院合肥智能机械研究所, 合肥 230031)3(安徽中科智能高技术有限责任公司, 合肥 230088)

电梯安管系统是采用多个独立传感器24小时不间断采集电梯运行数据, 通过无线实时上传到电梯运行监管平台, 实现对电梯的全天候运行监测、故障信息记录、报警预警处理和维保管理等功能的系统. 针对传统电梯安管系统传输响应时间过长的问题, 设计实现了一套基于物联网的新型电梯安管系统. 系统在管理平台上设计了一套新型的数据传输通信模型, 该通信模型向下通过GPRS与底层网关交互, 向上利用基于JMS的ActiveMQ消息队列服务与业务层交互, 大大缩短了响应时间.

物联网; 电梯安管系统; ZigBee; GPRS; ActiveMQ; 消息队列

物联网(M2M)作为掀起我国第三次信息革命浪潮的主导技术, 是一种以机器终端智能交互为核心的,网络化的应用与服务. 通过在机器内部嵌入无线通信模块, 以光纤. 无线通信等为接入手段, 为客户提供综合的信息化解决方案, 以满足客户对监控指挥调度、数据采集和测量等方面的信息化需求[1]. 电梯安管系统(即电梯物联网安全监管系统, 以下简称安管系统)是采用独立于电梯品牌的外置多个传感器采集电梯运行数据, 通过无线GPRS实时上传到电梯运行管理平台, 从而实现对电梯的全天候运行监测、故障信息记录和维保管理等功能的系统[2-4]. 系统通过全天候监测电梯运行数据, 可及时发现电梯隐藏的问题, 予以预警和报警, 同时当电梯发生故障时, 及时保障受困人员的人身安全. 因此是否能实时、有效的传递电梯数据, 缩短响应时间, 通知相关电梯安管人员进行故障解除, 降低事故升级的风险, 则拥有至关重要的意义.

目前, 国内外已经有较多机构开始电梯安全运行监管系统的研发工作[5], 如美国OTIS电梯有限公司电梯监控系统. OTIS电梯监控系统可连续不断监视电梯所有数据, 针对特定状况预测发出警告信息, 在北美取得了很好的监控效果. 但是国外的系统普遍的特点是专用性很强, 开放性、通用性和其功能发展程度不匹配, 无法支持其他公司的电梯系统, 大大增加了监控系统区域运营的成本.

基于以上情况, 本文设计实现的安管系统完全独立于电梯品牌, 采用独立分布于各地的电梯传感器采集数据, 同时设计实现了一套基于物联网的新型的数据传输通信模型. 该通信模型利用GPRS与底层网关ZigBee[6,7]进行交互, 同时通过基于JMS[8]的ActiveMQ[9]消息队列服务[10,11]与业务层进行交互, 大大缩短了响应时间. 此外, 该系统在可扩展性和数据传输效率上都得到了明显的提升.

1 电梯安管系统总体架构设计

安管系统的网络拓扑结构图如图1所示. 系统网络拓扑结构可分为四部分: 感知层、通信层、数据处理层和用户层.

1.1 感知层

感知层是指安装在电梯内部的独立的传感器, 全天候不停地对电梯进行实时监测, 获取电梯的各种运行指标, 如: 运行速度、运行方向、运行加速度、是否有人、当前楼层等20多项数据, 并将这些数据通过传感器ZigBee通信模块传递给传送给小区网关的ZigBee通信模块的过程.

图1 网络拓扑结构图

考虑到电梯运行的特点, 不方便采用电缆连接,故本系统采用无线网络进行数据的传递, 通信标准采用目前流行的ZigBee技术[12,13]. 电梯内部的传感器实时监测电梯的运行状况, 得到运行参数后通过传感器的ZigBee模块把数据传送到通信层. 感知层的结构图如图2所示.

图2 感知层结构图

每个电梯传感器和网关都有唯一的4字节ZigBee编码地址. 传感器向网关发送注册包, 得到网关的注册成功确认后, 两者就可以进行数据传输. 小区网关则向传感器数据采集服务器发送注册包, 服务器通过固定间隔不断向网关发送7字节的心跳包, 确认网关是否在线. 该心跳包包含两字节的数据头、4字节的网关ZigBee地址和1字节的数据尾. 若网关有回应则代表其在线, 连接正常. 若网关超过一定的时间没有回应, 则服务器默认网关掉线, 将其剔除. 网关则会在自动上线之后重新向服务器发送注册请求.

1.2 通信层

通信层包括两部分: 小区网关与传感器数据采集服务器之间的通信、传感器数据采集服务器与城域监管云平台(以下简称云平台)之间的通信, 及云平台与用户层的通信. 通信层的结构如图3所示. 其中, 传感器数据采集服务器、云平台和ActiveMQ均独立位于外网, DB数据库则位于小区内部局域网, 但对云平台开放.

图3 通信层结构图

通信数据传输分为数据主动发送和用户主动获取.数据主动推送是小区网关把从传感器接收到的电梯运行参数数据, 通过GPRS发送到传感器数据采集服务器[14], 传感器数据采集服务器接收到来自网关的数据后把数据存储到数据库中保存. 特别的, 当数据为预警报警数据时, 则同时将其发送给云平台并通知到相应的维保人员. 用户主动获取是用户请求通过云平台发送给传感器数据采集服务器, 传感器数据采集服务器根据请求的具体内容, 主动获取某个电梯的传感器数据, 并将其返回.

传感器数据采集服务器与云平台之间通过ActiveMQ提供的消息队列来进行通信, 接收线程包括轮询线程和主动接收线程两个, 轮询线程采用同步监听模式[15], 每天定时三次轮询电梯状态, 而当监听到传来的数据为报警或预警数据时, 主动接收线程会采用中断优先策略传递异常状态, 即优先中断轮询间隔,并及时推送警示给用户.

1.3 数据处理层

数据处理层包括数据采集服务器和云平台. 数据处理层和通信层包含的结构类似, 但是与通信层的数据传输不同, 数据处理层所做的是数据采集服务器和云平台内部处理数据和请求的过程. 系统数据处理主要包括: 预警报警处理、实时请求处理等模块.

1.4 用户层

用户层包括两类: 固定用户和移动用户, 固定用户是指Web客户端注册的用户, 移动用户则是智能手机App端注册用户. 针对省/市中心用户、物业用户、维保用户和检验用户五类用户群体, 将通讯层数据传输到服务器后, 可根据分级权限查看相应内容, 对电梯进行管理维护, 同时还可以针对报警或预警做出相应处理.

2 电梯安全运行监管系统通信层实现

2.1 传感器数据采集服务器与感知层的交互

2.1.1 连接方式的选择

目前常用的网络通信连接方式有两种: 短连接和长连接.

① 短连接是指每进行一次通信, 就建立一个连接, 数据传输结束连接关闭.

② 长连接则是在建立连接之后, 一直保持连接状态, 数据一直通过该连接传递数据. 长连接可以省去较多建立和关闭连接的操作, 节约了大量的时间,适合操作较频繁的情况.

安管系统要求监控必须是连续的, 不可间断的,同时监控所得的数据也必须及时传递到服务器进行梳理, 故小区网关与传感器数据采集服务器之间的连接采用长连接方式[16]. 连接握手示意图如图4. 网关向传感器数据采集服务器发送连接请求, 传感器数据采集服务器返回心跳响应, 网关再次向服务器发送确认信息, 连接成功. 之后网关可以在连接保持期间持续发送数据到服务器, 不需要再次连接.

图4 连接握手示意图

2.1.2 通信协议

系统传输中共有两种协议包: 传感器向服务器发送的预警报警通知包和服务器向传感器发送的报警预警响应包.

(1) 通知包是传感器向服务器发送的报警预警指令, 指令内容如图5. 指令内容包括: 固定头(每个通知包相同), 定长(每个通知包固定长度), 数据头, 网关、电梯ZigBee地址, 保留字, 传感器参数, 消息类型, 校验位, 数据尾. 其中校验方式采用奇偶校验, 即从数据头到数据尾, 包括数据头和数据尾, 不包括检验位, 数据中“1”的个数是奇数还是偶数. 奇数时校验位为“0”, 偶数时为“1”, 用以保证数据传输过程的准确性. 消息类型为是用来区分该信息是预警信息还是报警信息, 以选择处理方式.

(2) 响应包是服务器向传感器发送的应答指令,其指令内容如图6. 指令内容包括: 固定头、定长(消息长度)、机房和网关ZigBee地址、数据头、消息模式(预警和报警)和数据尾. 传感器接收消息的校验依据为:固定长度, 校验头尾.

图5 通知包数据内容

图6 响应包数据内容

2.1.3 传输问题及其解决方法

传输过程中存在一些不可避免的问题需要注意,如黏包、拆包问题.

(1) 黏包: 黏包是指通信时由于某种原因, 导致两个包同时传入服务器接收缓冲区, 即两个不同的包粘结在一起, 这种情况下需要对这两个包按照某种规则进行分包处理.

(2) 拆包: 拆包是指传输过程中由于网速不稳定或者突然断网, 导致某个包只有一部分传递到服务器接收缓冲区, 另一部分在重新建立连接后才传递过去,本来属于一个包的数据被分成两个包, 这种情况需要进行拼包处理.

针对上述问题, 系统给出如下分包算法[17]. 假设接收数据长度为M, 数据采集服务器会首先将数据转换成自定义协议格式, 然后读取信息固定头部数据,判断属于那种信息, 然后获取信息定长L, 并做如下比较:

(1) 若L=M, 则表明该数据为完整的数据包, 直接处理;

(2) 若L＜M, 则表明该数据发生黏包, 截取L长度进行处理, 后继续按照该方式截取, 直至结束;

(3) 若L＞M, 则表明该数据发生拆包, 等待接收下一个数据包合并.

以上分包算法, 可以很好地解决黏包拆包现象,并正确进行数据处理.

2.2 传感器数据采集服务器与城域监管云平台交互

如上图3所示, 传感器数据采集服务器与云平台之间的交互通过基于JMS的ActiveMQ消息队列实现间接通信. 采集服务器、云平台和ActiveMQ均位于外网, 通过网络进行数据传输.

报警预警是安管系统需要实现的一个重要功能之一, 报警是电梯出现事故造成人员被困时, 系统及时向管理人员做出报警提示, 从而及时采取拯救措施的情况. 预警则是一种防范措施. 为了保证信息传递效率, 结合JMS通信协议, 对系统通信过程进行了优化,具体流程如图7所示.

信息从底层电梯传感器发出, 经传输层到达采集服务器(生产端), 然后进入ActiveMQ的消息队列排队,等候云平台(消费端)处理. 消息从生产端到消费端的传输过程按照JMS协议进行通信, 为了保证通信效率,系统为消费端设置一个消息监听器, 用来监测消息队列内部消息是否到达.当有消息到达时监听器的onMessage()方法会被调用, 读取消息类型, 进行具体数据处理. 若消息类型为THREAD_PROCESS_TYPE,则继续该线程, 若消息类型为SELF_PROCESS_TYPE,则表明监听到的为报警预警消息, 优先处理. 若无消息到达则继续检测. 该方法提高了消费端的工作效率,使消息传输时间缩短至3秒左右.

图7 报警预警模块流程图

2.3 城域监管云平台与用户层交互

云平台与用户层的交互包括主动推送模块和实时请求模块, 前者是指云平台每隔固定间隔不断向客户端发送传感器采集的电梯运行数据, 后者则指用户层客户端向云平台发送查询某个电梯运行状况的实时请求. 限于篇幅, 本文仅介绍实时请求模块, 实时请求模块流程图如图8所示.

图8 实时请求模块流程图

用户通过页面前端向云平台发送访问电梯运行数据实时请求, 云平台作为消息生产端将消息传送到ActiveMQ消息队列中排队, 等候消息消费端即传感器数据采集服务器接收消息. 传感器数据采集服务器接收到消息之后再通过传输层传递到小区网关, 小区网关根据具体指令调用某个电梯的传感器数据响应. 实时请求过程需要保证传递数据包的顺序性, 当同一时刻请求很多时, 为了避免消息混乱, 系统使用ActiveMQ提供的sendAndReceive流程进行处理, 通过建立临时通道, 保证消息传递的有序进行[18]. 同样,因为消息队列的引入, 使得该流程信息传输效率得到改进, 效率提升至2-5秒.

3 结语

本文首先简要介绍了电梯安管系统整体架构设计,然后重点阐述了一种新型的通信设计模型和实现方法.该通信模型使得传感器数据采集服务器与网关和城域监管云平台之间的通信更加有序、安全和高效. 据实践统计, 该方法实现的电梯安管系统把常规的安管系统通信响应时间有效的缩短到10秒左右, 使得当发生报警预警状况时, 能够给电梯管理人员足够的时间来及时采取补救措施, 具有重要的意义. 此外, 该系统还具有手机客户端推送功能, 更加方便用户及时查询、更新数据. 但是, 目前该安管系统仍有一定的缺陷.比如针对注册电梯所在区域出现大面积断电, 或者服务器同时接收大量注册包等大数据处理问题, 该通信模型还没有足够的能力来应对. 大数据处理问题是是整个系统面临的考验, 也是之后努力的重点.

1 祝尊震,苏宇,张玉亮,等.基于物联网技术的电梯安全管理系统.微型机与应用,2015,34(1):72–74.

2 程峰.电梯远程监控技术及其发展.科技信息,2010,(18): 728–729.

3 叶安丽,李惠升.电梯远程监控系统.北京建筑工程学院学报, 2000,16(4):42–47.

4 刘宝迅,周慧娟.电梯远程监控系统研究进展.自动化仪表, 2014,35(3):12–16.

5 刘明.基于GPRS的电梯远程监控系统研究[硕士学位论文].武汉:华中科技大学,2006.

6 Kalden R, Meirick I, Meyer M. Wireless Internet access based on GPRS. IEEE Personal Communications, 2000, 7(2): 8–18.

7 王胜贤,高天生.基于ZigBee和GPRS的电梯远程监控系统的设计.测控技术,2016,35(3):149–151.

8 Happner M, Burridge R, Happner M, et al. Java message service specification. Sun Microsystems, 2002, (3-4): 79–195.

9 Snyder B, Bosnanac D, Davies R. ActiveMQ in action. Manning, 2011.

10 张燕,徐立新.ActiveMQ特性与配置研究.电脑编程技巧与维护,2011,(12):6–13.

11 Esposito C, Ficco M, Palmieri F, et al. Interconnecting federated clouds by using publish-subscribe service. Cluster Computing, 2013, 16(4): 1–17.

12 Kinney P. ZigBee Technology: Wireless control that simply works. Researchgate, 2003.

13 闫学勤,谢丽蓉,程志江,等.ZigBee+3G网络在新型井道式电梯监控系统中的应用.自动化仪表,2015,36(1):1–4.

14 刘安厚.基于GPRS的电梯远程监控系统[硕士学位论文].重庆:重庆大学,2009.

15 吴高峰,丁君辉,徐远兵.基于JMS的分布式数据同步.计算机系统应用,2015,24(1):171–175.

16 沈晓.TCP 异步长连接的选择及心跳处理机制的实现.中国金融电脑,2014,(4):37–39.

17 薛津,叶少珍.GPS车辆监控系统服务器性能优化与实现.微型机与应用,2013,(24):60–63.

18 王成良.基于JMS的分布式事务处理系统的研究与实现[硕士学位论文].郑州:解放军信息工程大学,2010.

Communication Module of Elevator Safety Supervision System Based on the Internet of Things

FENG Xue1, SUN Bing-Yu2, FANG Wei2, WU Bin31(School of Information Science and Technology, University of Science and Technology of China, Hefei 230026, China)2(Institute of Intelligent Machines, Chinese Academy of Sciences, Hefei 230031, China)3(Science and Technology Intelligent High Technology Co., Ltd., Hefei 230088, China)

Elevator safety supervision system is the system aiming at implementing all-weather operation monitoring, fault information recording, alarm-and-warn processing, maintenance management, and other functions of the elevators, using several independent sensors which collects the running data of the elevators uninterruptedly all-day, and then uploads these data to the operation monitoring platform of the elevators real-timely through wireless module. Focused on this issue of long response time of traditional elevator safety system, a new type of elevator security system based on the Internet of things is designed and implemented. In the system, a new high speed data transmission communication model is designed on the platform of management. This model interacts down with the underlying gateway by GPRS, and interacts up with the business layer by message queuing service of ActiveMQ based on JMS, greatly shortening the response time.

Internet of things; elevator safety supervision system; ZigBee; GPRS; ActiveMQ; message queue

国家创新基金(13C26213402619)

2016-07-28;收到修改稿时间:2016-09-20

10.15888/j.cnki.csa.005727