基于Redis盾构远程监控系统设计

赵 炯， 刘玲锦， 周奇才， 熊肖磊

(同济大学机械与能源工程学院， 上海 201804)

0 引言

盾构是一种结构复杂的大型设备，工作环境较恶劣。为了解盾构实时运行状况，并对设备进行统一管理，需要针对盾构设计远程监控系统。目前国内外著名的盾构生产商如海瑞克、小松、罗宾斯和上海隧道等都有自己的地面数据采集系统，但是大多数都只能安装在1台机器上，不能通过互联网进行实时监控，更不用说提供大量用户的高并发访问。文献[1]以大连地铁103、201为研究对象实现了基于互联网的盾构远程实时监控，但是随着被监测设备增多，数据量增加，会出现数据库访问压力过大和用户体验不佳的问题。文献[2]采用组态软件开发监控系统，这类系统不利于后期扩展，且系统安装复杂，用户必须安装客户端才能访问，这不利于用户使用。文献[3]提到德国ICT Engineering公司的IRIS隧道系统是特别针对盾构隧道施工过程产生的数据进行控制和状态分析而开发的，由于该系统是基于特定的浏览器，并且国内外的项目管理方式不同，所以也不能完全引进。

基于C/S模式开发的系统用户必须安装客户端，不能在任意的计算机上通过互联网访问监控系统，致使系统使用受限。虽然文献[1]采用了B/S模式，但是中心服务器的方式不能很好地应对大数据处理和多用户高并发访问。综合这些问题，本文采用B/S模式和数据缓存技术为系统提供快速的数据处理能力，同时还能处理高并发的访问。常用的缓存技术主要基于内存数据库设计。目前关于内存数据库的产品很多，其中Redis因其良好的性能得到了广泛应用，Redis作为一种高效的Key-Value数据库，支持多语言接口，使用方便，易于搭建集群和扩展[4]。本文围绕Redis技术，以分层的方式设计系统，并对系统中的数据层、应用层和展示层进行详细的介绍。

1 相关技术研究

NoSQL[5](not only SQL)泛指非关系型数据库，常用于超大规模数据的存储和分布式计算。由于NoSQL存储不需要固定的模式，具有半结构化数据的特点，所以很容易做到横向扩展，在Web2.0时代有越来越多的应用。传统的RDBMS需要满足ACID(atomicity，consistency, isolation, durability)特性，NoSQL也类似，需要满足CAP(consistency，availability，partition tolerance)定理[6]，该定理指出1个NoSQL数据库不能同时满足这3个特性，最多只能同时较好地满足其中的2个特性。因此，可以将NoSQL分成3种类型： 1)CA。单点集群，满足一致性、可用性，可扩展性较差。2)CP。满足一致性、分区容忍性，一般性能不是很高。3)AP。满足可用性、分区容忍性，一般对一致性要求较低。根据数据库存储类型还可以将数据库分成4大类，即键值存储数据库、列存储数据库、文档型数据库、图形数据库，如表1所示。

表1 NoSQL数据库分类[6]Table 1 Classification of NoSQL database [6]

结合远程设备实时监控系统数据量大、实时要求高的性能需求和各类NoSQL数据库的特点，最终选择Redis作为系统的数据缓存模块。Redis作为一款开源的Key-Value存储系统，支持丰富的数据结构，包括字符串、集合、列表、字典等，内部由高效的算法和数据结构支持，可实现快速增删改查。在操作方面，Redis基于TCP协议，可用1个Server端连接多个Client端。

对于单节点Redis服务器，如果出现了宕机，则所有基于该实例的应用不能使用。为了保证系统的稳定性，可搭建Redis集群，它由不少于3个处于集群模式的Redis主(Master)服务器组成，每个主(Master)可设置至少1个从(Slave)服务器以实现容灾备份、故障转移。Master和Slave的功能组件基本一致，数据由Redis对象组成，每个Redis对象基于Redis数据结构实现，Redis服务器通过RDB或者AOF持久化将数据备份到磁盘中。Redis集群系统实现原理如图1所示。由图1可以看出： Redis数据对象在系统内部有底层Redis数据结构支持，如链表、整数集合、跳跃表等，而提供给外部应用程序的是经过包装后的数据对象，其功能更加丰富，效率更高。

2 监控系统框架

系统采用B/S模型开发，所以最终呈现给用户的数据是通过浏览器这个载体来完成展示的，而盾构关键零部件的监测数据是通过底层机载系统PLC采集，无法直接展示，需要进行一定的转换。所以整个系统的数据流动过程是先将机载系统采集的数据解析后存储到Redis中，然后这些数据响应客户端的实时请求，同时还将数据存储到关系型数据库(如MySQL)中，为故障诊断、数据挖掘等操作提供数据源。根据数据的流动和功能的划分，整个系统软件架构[7]可以分为数据层、应用层和展示层，如图2所示。

图1 Redis 集群系统架构Fig. 1 Components of Redis cluster

各层的功能总结如下：

1)数据层。数据层的功能主要是将底层机载系统传输到服务器的数据进行解析和存储，并为整个系统提供数据源。

2)应用层。基于数据层提供的数据对盾构进行状态分析、故障统计、故障预测及设备管理等，同时还要处理来自客户端的数据请求。

图2 系统架构图Fig. 2 System structure

3)展示层。该层主要通过浏览器对盾构的实时数据进行展示。为形象生动地表达盾构运行状态，可使用仪表盘、图表等前端插件。

能力与兴趣相辅相成，缺一不可。面对枯燥且深奥的数学知识，学生只有具备良好的学习兴趣，才能以极大的热情投入其中，获得能力的提升。所以，教师在教学中要积极转变思想，摆脱生硬乏味的说教，将数学课堂变得多姿多彩。现代信息技术与数学计算的结合为教师的教学提供了动力支持。在教学开展过程中，教师可以利用多媒体技术的文本、图片、声频以及视频等元素向学生展示一些新鲜新奇的小游戏，使数学教学更富趣味性，抓住学生的注意力。例如，借助信息技术手段设计迷宫之类的数学游戏，让学生通过一系列的数学计算获得提示，指引路径的选择与开启，如果全部做完并正确，便能成功闯出迷宫获得奖励。如此，学生便能积极主动地投入到数学学习中来。

3 数据层

数据层是整个系统的基础，该层的主要功能是将底层PLC采集到的盾构实时数据进行解析以符合应用层格式的需要，同时还将这些数据进行永久性存储，为故障诊断、数据挖掘等操作提供数据来源。

3.1 数据解析和存储

盾构在运行过程中，需要被监测的量主要包括2种，即模拟量和数字量[8]。其中数字量主要对应盾构中的开关量，如某个限位开关是否开启； 而模拟量则对应盾构运行时零部件的压力、速度等量。 这2种类型的数据在计算机内部存储时需要的内存空间是不一样的，如模拟量需要8个字节，而数字量只需1个字节。底层机载系统在传输数据时采用数据包的形式进行传输，模拟量和数字量全部封装在1个数据包中，该数据包不能立即使用，需要经过解析才能得到某个特定测点的实时数据。所以在解析数据包时，首先需要定位到被测点的数据在数据包中的起点位置，然后根据测点对应的字节长度(偏移量)计算出实时数据真实值。解析过程如图3所示。

图3 数据解析流程Fig. 3 Flowchart of data resolution

测点配置表主要包含测点的属性，如sensorName，所属盾构的shieldId，测点对应的数据类型dataType，测点数据在数据包中的偏移量dataOffset，数据阈值dataMin、dataMax等信息，如图4所示。

图4 测点配置表结构Fig. 4 Configuration of monitoring points

数据包被解析后首先存入到Redis数据库中进行缓存，并供多个进程使用，如用于响应客户端的实时请求，保存数据到关系型数据库(如MySQL)中。

由于监控系统对数据实时性要求较高，每隔一定时间(如每隔1 s)就向服务器请求1次数据，所以同1台盾构不同时间点的数据包应该包含时间戳(Timestamp)属性，根据时间戳属性即可选出各个时间点的监控数据。结合Redis数据对象的结构特点，以Key-Value方式进行存储，所以在设计实时数据的存储结构时，可用设备Id为Key，Value部分为1个Map对象，该Map对象的Key为Timestamp，同时Value部分为Data，而Data部分是盾构零部件和实时数据存储的Key-Value对。整个结构如表2所示。由表2可知： 根据盾构的标识符(shieldId)和时间戳(Timestamp)可以决定在某个确定的时间点盾构每个被监测零部件的运行数据列表，表中的Data部分是以Key-Value方式存储每个被监测零部件的数据，Key是被监测零部件名称，Value是当前时间点的监测数据。每隔一定的时间间隔底层机载系统就会将采集到的数据发送到服务器端进行解析，如果接收到的每条数据都存入到Redis数据库中，内存很快就会被占满，所以每隔一定的时间间隔需将旧的数据从Redis中删除。

表2 Redis存储结构Table 2 Storage structure of Redis

前文中提到从数据包中解析后的数据是由多个进程所共享的，一是用于客户端的访问，二是将这些数据存入到关系型数据库作为以后数据挖掘、故障诊断和健康评估的数据源，所以在设计关系型数据库时需要考虑盾构自身的结构特点和系统的功能需求。对于盾构这样的大型设备，其具有结构复杂，集机、电、液系统于一体的特点，每个较大的部件内部还包含了很多较小的零部件。这些零部件之间存在一种包含的关系，在设计数据库[9]表结构时可根据该特点将整个设备表示成树状的结构，即1个设备包含了多个机构，每个机构下包含了多个零部件，零部件下还可能继续包含子部件，即设备与零部件之间是1∶n的关系。在实时监控过程中并不是所有的零部件都要进行监控，为了区别这种关系，可将需要被监测的零部件表示为测点，即1个大的零部件下包含了测点和零件，所以零件和测点之间的关系为1∶n。测点对象中包含的信息除了自身描述信息外，还主要包括测点的实时数据位于数据包中的位置，即start(起点)、Offset(偏移)等信息。综合这些信息，这几个关键部分之间的关系如图5所示。

图5 关键部件关联示意图Fig. 5 Sketch of relevance among key components

3.2 Redis集群

对于单实例Redis数据库，如果Redis出现了故障，则所有基于它的应用程序都不能使用，所以为提高系统的容灾能力和高可用性，需搭建Redis集群。Redis3.0集群采用P2P(point to point)的模式，完全去中心化，它将所有的Key分配到16 384个槽(Slot)中，每个Redis实例负责其中的一部分Slot。集群中的所有信息(节点、端口、Slot等)都是通过节点之间的定期数据交换来更新的。Redis客户端对任意一个实例发出数据请求，如果所需数据不在实例中，Redis可以通过重定向命令引导客户端访问拥有目标数据的实例。

本文基于数据量和功能需求的考虑，部署了3个Redis实例，每个实例具有主/从(Master/Slave)2个节点，并且这些实例部署在不同的服务器上。在各个服务器上安装了Redis后需要修改对应的配置文件，其中的一些关键属性如表3所示。

表3 Redis集群关键配置项Table 3 Key configuration items of Redis cluster

配置完相关属性，并成功启动后，Redis集群对于应用层是几乎透明的。例如： 当客户端访问集群中的Redis1时，发现目标数据并不在Redis1中，但是根据路由信息可知，被请求数据在Redis2中，于是Redis1会向客户端返回1条重定向信息，引导客户端到Redis2中请求数据。其访问过程如图6所示。

图6 Redis集群工作过程Fig. 6 Working process of Redis cluster

当集群中的某个主节点出现故障时，系统会自动监测并切换到从机上，此时从机(Slave)提升为主机(Master)并向客户端提供服务，主从之间的切换对于客户端来说是不可见的，其过程如图6所示。

4 应用层

应用层主要以数据层为基础，对该层提供的实时数据和历史数据进行加工处理，实现相应的业务逻辑。盾构在运行过程中会积累很多重要的工程数据，包括地质信息、盾构各重要零部件的运行参数、设备维修信息和故障信息等，这些数据是管理整个设备重要的信息来源。除了实时监控，对盾构施工前、施工中、施工后的信息管理也十分重要。对于盾构这样的大型设备，施工环境较恶劣，如果出现零件损坏，则势必会影响整个盾构的运行，甚至导致设备损坏无法工作。为了降低设备的故障率，可基于设备历史运行数据进行挖掘分析，预测盾构零部件可能出现的故障[10]，在零部件出现损坏前及时更换，从而不会影响整个系统的正常运行。根据盾构的结构划分，其故障大致可以分为传感器故障、执行器故障、控制器故障和被控对象故障。当故障发生时，系统中的各种量会表现出与常态不同的特征，这些特征中包含了故障的信息，所以根据这些特征信息可以建立起依赖于模型和不依赖于模型的诊断方法，并结合神经网络、模式识别、模糊数学等对故障进行有效的诊断[11-12]。

整个监控系统监测着多台盾构的运行状态，因为每个盾构的生产厂商、工作环境等不同，所以对于不同的盾构需要被监控的信息也不同，这些信息都需要进行统一处理。总之，应用层主要处理整个系统的业务逻辑，以模块化的方式降低系统的耦合程度，简化开发流程。对各个核心的业务进行简化可得到图7所示的3层模型。由图7可以看出： 应用层包含了多个功能模块，每个模块之间相对独立，对展示层提供统一的接口，而数据来自Redis缓存和关系型数据库。

图7 3层模型Fig. 7 Three-layered model

5 展示层

基于前2节的分析，结合系统业务需求，将需要被实时监测的盾构关键部件信息以图表或文字的方式在浏览器端显示，并对数据显示方式进行美化。从浏览器端向服务器请求实时数据，一般有Ajax长轮询[13]、Ajax短轮询等方式，其中长轮询需要在服务器端hold住连接，使得资源消耗比较大，所以在本文研究的系统中采用Ajax短轮询的方式请求实时数据。在服务器端根据每次请求的盾构标识(shieldId)和请求时间戳(Timestamp)从Redis中查询数据，并将查询结果以JSON的方式返回给浏览器端。数据请求流程如图8所示。

图8 数据请求流程图Fig. 8 Flowchart of data request and response

前端使用Ajax将shieldId和Timestamp等信息作为参数传递到服务器端，服务器在接收到实时数据请求后将这些参数解析，并以此为依据从Redis中查询数据，最后将查询结果以JSON[14]的方式返回，浏览器在收到返回数据后进行局部刷新，刷新实时监控页面中的数据，效果如图9所示。由图9可以看出： 实时监控页面是按照盾构的主要部件为模块进行划分的，如千斤顶系统、刀盘系统、注浆系统等，各个模块中关键零部件的参数一目了然，同时还采用了图表、仪表盘等前端插件来加强数据显示效果，使其形象生动，表现力更强。系统其他模块也同样根据各自业务的不同将数据进行展示或根据功能划分对系统进行管理、配置。

图9 实时监控界面Fig. 9 Real-time monitoring interface

6 结论与讨论

本文采用B/S开发模式，并基于Redis缓存技术设计了盾构远程监控系统。整个系统分为数据层、应用层和展示层，为提高系统运行效率，在数据层搭建了Redis集群，将盾构实时监控数据缓存在内存中，从而提高数据处理能力和系统交互能力。目前系统的主要功能是远程监控，虽然在盾构出现故障时能及时监测到，但这具有后效性。为提高设备寿命，下一步可采用数据挖掘、统计分析等方法对盾构关键部件进行故障预测，这样就可以在零部件损坏前及时更换，从而提高系统寿命。

[1] 闫明. 高可用可扩展集群化Redis设计与实现[D]. 西安： 西安电子科技大学， 2014.

YAN ming. Design and implementation of high availability and scalable Redis cluster[D].Xi′an： Xidian University, 2014.

[2] 高勇. 基于WinCC盾构刀盘远程监控系统设计[J].电脑知识与技术, 2011, 7(18): 4462.

GAO Yong. Remote monitoring system designs based on the WinCC shield cutter[J].Computer Knowledge and Technology, 2011, 7(18): 4462.

[3] 刘承恒. 盾构远程监控系统架构和关键技术研究[D]. 西安： 长安大学， 2014.

LIU Chengheng. Study of architecture of TBM remote monitoring system and key technology[D]. Xi′an: Chang′an University, 2014.

[4] 曾泉匀.基于Redis的分布式消息服务的设计和实现[D]. 北京： 北京邮电大学， 2014.

ZENG Quanyun.Design and implementation of distributed message service based on Redis[D].Beijing: Beijing University of Posts and Telecommunications, 2014.

[5] 姚林, 张永库. NoSQL的分布式存储与扩展解决方法[J]. 计算机工程， 2012, 38(6): 40.

YAO Lin， ZHANG Yongku. Solution of NoSQL distributed storage and extension[J]. Computering Engineering, 2012, 38(6): 40.

[6] 胡波. 非关系型数据库统一存储与访问接口研究[D]. 成都： 四川师范大学， 2016.

HU Bo. Research on unified storage and access interface for NoSQL database [D].Chengdu: Sichuan Normal University, 2016.

[7] 杨晓雯, 王晓莉， 赵楷， 等. JAVA教学中软件分层架构思维方式的引导[J]. 信息与电脑, 2017, 10(2): 226.

YANG Xiaowen， WANG Xiaoli, ZHAO Kai， et al. Guide of thinking of software layered architecture in JAVA teaching [J].China Computer & Communication, 2017, 10(2): 226.

[8] 孟祥波, 徐受天， 马强. 基于互联网的盾构远程实时监控系统开发[J]. 隧道建设, 2012, 32(2): 256.

MENG Xiangbo， XU Shoutian， MA Qiang. Development of internet-based real-time remote monitoring system for shield machines[J]. Tunnel Construction, 2012， 32(2): 256.

[9] 丁智斌, 石浩磊. 关系数据库设计与规范化[J]. 计算机与数字工程， 2005(2): 114.

DING Zhibin，SHI Haolei. Design and normalization of relation database [J].Computer and Digital Engineering, 2005(2): 114.

[10] 蒋庆. 地铁盾构设备状态监测与故障诊断研究[D]. 沈阳： 沈阳理工大学， 2010.

JIANG Qing. Condition monitoring and trouble shooting of metro shield equipment[D]. Shenyang： Shenyang Ligong University, 2010.

[11] 刘维. 盾构推进系统故障预测研究[D]. 南京： 南京理工大学， 2014.

LIU Wei. Study of prediction for shield thrusting system fault [D]. Nanjing： Nanjing University of Science and Technology， 2014.

[12] 韩超. 数据挖掘在盾构故障诊断中的应用[D]. 沈阳： 沈阳理工大学， 2011.

HAN Chao.The application research of data mining to shield fault diagnosis [D].Shenyang：Shenyang Ligong University, 2011.

[13] 吴灿培， 胡顺豪， 王海航, 等. 基于Ajax与SVG的web远程实时监控系统[J]. 计算机工程与设计， 2011, 32(9): 3004.

WU Canpei，HU Shunhao，WANG Haihang, et al. Web remote real-time monitoring and control system based on Ajax and SVG[J]. Computer Engineering and Design，2011, 32(9): 3004.

[14] 屈展， 李婵. JSON在Ajax数据交换中的应用研究[J].西安石油大学学报(自然科学版)， 2011, 26 (1): 95.

QU Zhan，LI Chan. Application of JSON in Ajax data exchange [J]. Journal of Xi′an Shiyou University(Natural Science Edition)， 2011， 26(1): 95.