隧道掘进设备多源异构数据采集系统设计开发与应用

徐受天, 游宇嵩, 叶 蕾, 赵严振, 徐剑安

(中铁工程装备集团有限公司, 河南 郑州 450016)

0 引言

随着隧道施工机械自动化程度不断发展，采用全断面隧道掘进机施工成为当前隧道施工的主要工法。本文中隧道掘进设备主要指全断面隧道掘进机，包括盾构(用于城市软土地层掘进)和TBM(用于山岭隧道硬岩掘进)。根据工作原理不同，盾构分为土压平衡盾构和泥水平衡盾构，TBM分为敞开式、双护盾式和单护盾式[1-3]。全断面隧道掘进机掘进时工作环境恶劣，高频振动、电磁干扰等现象严重[4]，采集设备一般集中部署，位于掘进设备的主控室内，通过网络连接到设备各处感知端。传统盾构/TBM的相关监控系统主要限于对PLC数据的采集。随着隧道施工机械化、数字化、Wi-Fi、5G及大数据技术的发展，对数据的获取提出了更高的要求[5]。除传统盾构/TBM外，隧道施工专用设备、矿用机械也越来越多地投入使用。不同种类的控制器数据、高频率振动数据、工业相机照片、三维激光扫描点云图等通过数据挖掘后，在指导施工、改进装备设计上发挥的作用越来越大。当前智能传感、物联网、大数据、无线通信、工业互联网等技术发展迅速，对于盾构/TBM智能化起到了推动作用[6]。同时，国内外各大厂家均在产品智能化方面开展了大量研究，隧道施工数据的种类与数量与日俱增，无疑对海量多源异构数据的采集、存储也提出了更高的要求。

张静等[7]采用地上地下部署工控机，利用光纤网络传输的方式，采集PLC的数据到Web服务器，进而实现可视化；但这种方式仅实现了接入PLC的数据获取。陈刚等[8]采用基于云平台的盾构数据采集系统，通过OPC协议循环读取PLC地址，根据用户设置的配置文件，将PLC记录信息按照类型逐条区分处理，然后调用Web API接口，将数据同步发送到云服务器的数据库中；这种方式不用进行终端部署，但仍仅采集接入PLC的数据。周奇才等[9]针对盾构施工地层损失监测，设计了一种基于Modbus协议和RS485总线的数据采集系统；但该种方式采集数据较为单一，只针对RS485接口传感器进行采集。于祥涛[10]以昆明市轨道交通5号线施工为项目依托，利用亚控科技的采集盒子进行数据采集，盒子自带RS232、RS485、以太网口3种接口，采集的数据主要是PLC数据、电表、水表、电瓶车状态等；这种方式利用现有产品进行采集，优点是可以快速实现，缺点是不便于拓展，对于其他接口的传感器无法采集。

针对国内外市面上存在的大量数据采集终端或数据网关，树根互联、上海自动化仪表、Woodhead等公司产品能兼容国内外主流PLC和控制器，但是普遍存在以下问题：1)只能采集主流的、标准的物联设备，对隧道施工中类似工业相机、振动传感器、点云扫描、激光/雷达探测等设备产生的数据无法采集，可扩展性较差；2)鼓励数据存储于开发厂商的公有云，数据的灵活读取和二次利用较困难，也不利于数据安全，如果私有化则需要高额的定制费用且后期运维成本极高。因此，有必要开发可以同时采集隧道施工中产生的大量多源异构数据的专用数据采集系统，本文以此展开研究。

1 总体方案设计

1.1 系统目标及需求

在进行隧道施工专用多源异构数据采集系统研究时，需要提前将系统所应达到的指标明确化、具体化。系统所应达到的目标如下。

1.1.1 多数据源支持

在一个物理终端上支持同时采集多种类型数据源的数据，彼此独立，互不干扰；同种类型支持多通道数据传输，如支持同时采集多个同类型的PLC数据。

1.1.2 多协议解析

支持多种常用协议的解析，如西门子PLC的S7协议、OPC UA、Modbus TCP等。支持多种硬件设备数据的采集，如西门子S7-200/300/400/1200/1500系列PLC、易福门控制器、TBM刀盘磨损检测装置、线阵/面阵工业相机、高频振动传感器等。

1.1.3 实时和历史数据传输

按实时数据和历史数据2种途径同时传输数据。实时数据每次仅传输当前时刻最新的数据。历史数据传输频率相对较小，每次打包传输多条数据。遇到网络、故障等原因，则按时间顺序续传，确保数据不丢失。

1.1.4 数据预处理和边缘计算

支持在终端上进行简单预处理和边缘计算：将明显异常的数据进行过滤或处理，将结构化/半结构化数据或占用空间较大的数据转换为简单、小巧的结构化数据，具体处理或计算方法可以随时进行远程调整等。

1.1.5 现场数据接口

为终端的上位机、第三方信息化智能化系统提供统一的数据接口。提供数据接口的目的是：1)防止第三方直接读取现场设备，破坏设备数据的保密性，及造成设备数据输出负载增大；2)减少上位机和第三方软件的复杂数据处理过程。

1.1.6 数据源动态扩展

在不影响其他程序的情况下，支持快速定制化开发扩展新组件，以支持新类型数据源的接入。当新类型的数据源接入后，无需刷机、固件升级和新增硬件，而是通过远程管理的形式进行功能扩展。

1.1.7 本地Web管理及远程监控接口

终端不开发基于平台的图像界面，采用Web方式进行可视化图形管理页面开发。维护人员使用另外一台计算机通过Web浏览器打开终端管理网页，进行现场终端管理。系统提供对终端进行远程监控的接口，主要包括：查看终端操作系统状态(CPU、内存、外存)；查看和结束进程；查看和设置网络连接；浏览操作系统文件系统；上传、下载文件；查看和配置数据源参数；查看运行日志文件等。

1.2 系统架构设计

系统总体架构设计决定了后期维护的便捷性、可拓展性以及施工单位、业主等用户的使用体验[11]。本文所述多源异构数据采集系统采用一主多从的架构，每个数据源作为独立从设备，与其他设备互不干扰，主从设备之间通过Socket套接字进行通信，基于TCP/IP协议可实现数据源的快速接入。管理者可以通过远程或者在本地以插件形式添加、删除、修改从设备，在不影响其他链路的前提下，实现数据源的灵活配置、简单部署。采集终端在采集到数据之后，通过MQTT等协议进行数据的上传，数据以结构化存储在本部的大数据中心。多源异构数据采集系统总体架构设计如图1所示，当前所接入的数据源为基于Snap7协议的PLC数据源、基于Modbus RTU协议的刀盘滚刀监测数据源、基于Http协议的Python边缘计算数据源、基于Socket套接字通信的振动监测数据源、基于千兆网通信的线阵相机图像采集数据源以及基于OpcUA、Modbus TCP协议的国产PLC数据源等。服务器位于数据中心，用于收集来自所有终端的数据，并集中统一管理。终端安装于各隧道施工现场。每个终端由1个主模块和若干个数据源模块组成。每个数据源模块启动1个独立进程，对应1种类型的数据源采集。

图1 多源异构数据采集系统总体架构设计

1.3 系统软件方案

1.3.1 运行环境及关键技术应用

本文所述多源异构数据采集系统中，服务器运行环境为基于x86架构的64位标准Linux-CentOS操作系统。采集终端可以实现跨平台部署运行，适用于基于ARM或x86的Linux操作系统、Windows操作系统，同时支持32位和64位。本系统开发语言根据语言特性进行选定，采用多种语言共同开发。其中，服务器、终端主模块和数据源模块的主体部分选用Go语言；Web前端部分选用JavaScript、HTML5语言；终端Web后端使用Go语言；服务器Web后端使用Java或Go语言；边缘计算、部分数据源的前置输入视情况选用C/C++或Go语言。

1.3.2 终端交互设计

终端主模块与数据源模块的交互流程如图2所示。TCP连接成功后，开始针对不同数据源配置相应的硬件参数，连接硬件成功后，配置相应的映射表读取数据。

图2 终端主模块与数据源模块的交互流程

终端主模块与服务器的交互流程如图3所示。终端上电后，检查数据源列表，查看哪些数据源在线，然后开始进行各个数据源服务，与各个数据源建立独立连接和映射关系，进而周期性发送采集到的设备数据。在发生连接错误时，发布广播消息，通知服务器连接错误，不再发送数据。

图3 终端主模块与服务器的交互流程

针对历史数据传输，终端每隔指定时间读取多条数据进行打包，将数据包通过网络传递给服务器。在终端传送前，提前与服务器约定好数据包大小、历史数据时间段信息、数据量以及采样频率等。

1.3.3 终端通信设计

本系统根据各数据源与终端特性进行相应的通信设计。为了保证统一性，终端采用多接口设计，多接口接入的数据统一进行无缝协议转换，最终输出到终端主进程数据均是按照TCP/IP协议进行数据接收处理。通信设计依据如下：

1)为方便代码维护，服务器与终端主模块之间、终端模块与各数据源模块之间采用统一的通信模块。

2)采用TCP长连接方式和RPC形式，即一问一答。通信伙伴对每个请求都必须响应且只响应1次。

3)密钥交换使用标准TLS，保证通信过程中数据不会被破译和篡改[12]。无需再设计其他形式的加密算法。

4)终端主进程与服务器之间、终端主模块与数据源模块均基于C/S架构方案，相对于B/S架构，C/S架构具有响应速度快、与现场设备通信频率高等特点[13]。

建立TCP连接后的所有通信过程，都按1个请求严格对应1个响应的方式展开。每个请求称为1个“请求帧”，每个响应称为1个“响应帧”，如图4所示。

图4 通信过程

当1个TCP连接建立后，同时开启2个队列Channel，一个是Send Loop队列，另一个是Receive Loop队列。TCP是基于流的可靠连接，但仍需要考虑多线程及多协程时数据的正确性[11]。

1.4 服务器设计方案

服务器端的方案设计由高性能服务程序、数据传输与存储2部分组成。

1.4.1 高性能服务程序

高性能服务程序要求能够达到处理高并发、高数据吞吐量的网络数据的能力。服务器的资源包括网络带宽、包吞吐量、CPU资源、内存资源等[14-15]。

本系统采用Go语言，其语言特性对异步提供了良好的支持，用Goroutine(协程)+Channel的模式构造服务程序。Goroutine是在线程之上封装的协程，每个协程都有自己的堆栈，协程间使用Channel进行相互通信。服务程序采用网络连接池、线程池和内存池，实现了多任务多线程的异步处理。

1.4.2 数据传输与存储

数据传输与存储是利用事先定义好的数据传输策略，在服务器接收到数据后进行存储。数据远程传输分为实时数据传输和历史数据传输2部分。实时数据可尽可能保证数据的实时性，但不能保证数据不丢失；历史数据可保证数据在时间上的完整性，但不能保证数据实时性。

实时数据是按照指定时间间隔从已缓存的内存中获取当前最新数据，直接推送到远程数据中心。历史数据是从缓存数据库中查询指定数量的最老数据，按照时间顺序打包，然后发送至数据中心。当数据发送成功后，便将该数据从缓存数据中删除，如图5所示。

图5 数据远程传输示意图

2 管理平台设计

2.1 远程数据管理平台

多源数据采集系统远程数据管理平台采用B/S架构，以Java SpringBoot技术为基础，利用MyBatis、Vue、WebSocket等技术相结合进行开发，使用WebSocket标准协议在客户端和服务端之间进行双向数据传输。数据采集系统的数据管理平台集权限管理、项目管理、设备管理、网关管理、实时监控、数据存储等功能于一体，能够实现从数据实时通讯到应用的完整处理流程。系统具有简洁大方的用户交互界面，能够提供最低1 000台设备的并发接入能力与即时的数据推送呈现体验。

盾构远程数据管理平台的网址链接为：https://tmain.tbmcloud.com.cn/#/login?redirect=%2Fscreen。用户可直接登录进行查看。

2.1.1 监控中心

多源数据采集系统监控中心界面如图6所示。系统总览页面展示当前用户权限下所有的网关数据源的信息，包括设备总数、在线数量、所在位置；实时数据页面可选择展示某个数据源远程传输的实时数据点位数值信息；历史数据查询页面可查询某个数据源一段时间范围的历史数据，展示选定点位的数据连续情况。

图6 多源数据采集系统监控中心界面

2.1.2 管理中心

多源数据采集系统管理中心界面如图7所示，能够实现项目管理、设备管理、网关管理、角色管理、用户管理等功能。项目管理用于管理数据采集终端应用的项目信息，包括项目名称、负责人、项目地址等信息；设备管理用于管理数据采集终端应用的掘进设备信息，包括与采集终端网关的关联与拆解、项目调度，以及相关联终端网关的数据源的基本参数、采集频率、点位信息的远程设置等功能；网关管理用于管理终端网关信息，包括网关的名称、网关的编号、网关远程连接的密码等信息；角色管理页面将用户分成不同的角色，角色对应功能模块的管理权限；用户管理可以对用户进行查询、新增、修改、删除操作，关联到不同的角色，由角色确定用户的管理权限。

图7 多源数据采集系统管理中心界面

2.2 终端本地管理平台

多源数据采集系统终端本地管理平台采用Web B/S架构，Web后台使用Go开发，Web页面使用HTML编写[16]，实现了对数据采集网关的系统运行环境信息监控、连接远程服务器的通讯配置、数据源的增减及参数配置、数据源的数据采集监控等功能。针对本地管理平台从以下几个方面进行阐述：

1)终端状态可视化。终端状态实现了对网关硬件运行环境的信息展示，包括运行时间、CPU占用率、磁盘占用率等信息，有助于分析采集网关的运行效率和系统的健壮性、可靠性。

2)参数设置。参数设置页面实现了配置数据采集网关与远程服务器通讯的IP地址、端口信息、选择性是否接入外网等功能。

3)数据源管理。数据源页面实现了配置数据源的通讯地址和通讯协议、采集频次、历史数据传输的数量、导入导出点位变量表等信息展示，如图8所示。

图8 采集终端管理平台数据源界面

4)数据实时监控。实时监控页面实现了实时显示网关采集数据源的点位变量数据，数据显示刷新频率为1 s，在数据源断开或者延迟过大时，实时监控数据将不再刷新，由此得知数据源出现通信问题，界面如图9所示。

图9 采集终端管理平台实时监控界面

3 数据源模块设计与现场测试

隧道施工时的网络部署主要是以以太网为主，各感知端通过以太网接入到主控室的交换机上，而后接入采集终端，其中，设备数据源的采集频率一般为缺省值，如PLC采集速率一般为1次/s，且用户可进行自定义设置。

3.1 西门子PLC数据源

3.1.1 采集模块设计

目前PLC厂商的OPC服务器通常只能运行在Windows平台上，且体积庞大，占用资源多[17]。因考虑到兼容ARM开发，宜选用直接利用PLC的内部协议，用以太网进行连接。西门子S7-200/300/400等均支持S7协议。选用开源的Snap7函数库可以对S7协议进行解析，相对OPC、OPC UA等其他方式，具有跨平台、通信效率高、占用资源少的优点，缺点是开发难度较大[18]。

由于每台设备的PLC地址不尽相同，需要事先定义PLC的点位表，存储于本地数据库中，只有在点位表中存在的地址才进行读取，避免不必要的CPU和带宽资源浪费。在S7协议中，PLC数据存储于I、Q、M、DB等不同的区域，需要分别读取，而且每次读取时只能读取一段连续存储区域。连续区域中，部分地址可能是未定义的[19]。通过优化算法，既保证每次读取的连续区域足够大以减少读取次数，又避免读取到过多的无用数据。

以图10为例，1个灰色格子表示1个需要采集的PLC变量，白色格子表示不需要采集的PLC变量。图中列举了3种读取方式，其中，A方式保证每次只读取需要采集的变量，但是读取了3次；C方式仅读取1次，但是读取了过多无需采集的数据；而B方式兼顾了读取次数和读取总数量，更加合理。

图10 PLC连续区域读取示意图

3.1.2 现场部署测试

2020年7月31日，在广州地铁11号线盾构上进行了PLC接入测试，如图11所示。该项目通讯机柜内的内外网网口相对容易排查，交换机是比较常规的网口布局，内外网网口分别在交换机不同的区域。在查找到内网及外网网口后，进行系统部属测试，数据实时回传至服务器。

(a)内网、外网网口

3.2 振动监测数据源

3.2.1 采集模块设计

主机振动监测系统由加速度传感器、信号采集与传输、信号处理与显示3个模块组成，系统架构如图12所示。

图12 主机振动监测系统架构

加速度传感器可获取主驱动电机、中心舱、刀盘隔板等位置的振动信号，信号采集仪将采集到的加速度数据通过TCP/IP通信协议接入数据采集终端，对传感器数据进行采集与存储，最后传输到上位机。

3.2.2 现场部署测试

2020年12月，在云南大瑞铁路高黎贡山隧道TBM上搭载了所设计的振动监测数据源，并进行了现场部署测试。采集仪部署如图13(a)所示，位于人舱出口后方主梁底部位置。数据采集终端部署如图13(b)所示，位于主控室操作台上方。上位机运行图见图13(c)，为采集到的数据在上位机上的可视化显示。经过本次测试，振动数据设置采集频率为240 Hz，数据可实时回传及存储，系统运行正常。

(a)采集仪部署

3.3 渣片监测数据源

3.3.1 采集模块设计

在TBM掘进时，由掘进出渣情况可以从侧面反映当前掌子面的情况。渣片图像分割系统搭载的主要目的是识别TBM施工时渣片的粒径大小并进行分组。在TBM施工时，滚刀与岩层间存在多种形式的作用力，根据力的相互作用进行岩层的切割，形成渣片后利用皮带机进行出渣。在掘进过程中，正常的渣片粒径长边为10～15 cm(工程经验所得)，当出现较大粒径时，说明滚刀与岩层间存在切割异常。为了避免刀具异常磨损，此时渣片分割系统发出预警信号，一方面提示前方的地质情况可能发生突变，另一方面提醒总推进力可能过大，需要司机及时调整掘进参数，为TBM安全施工提供一定的保障。在进行渣片粒径分级识别中，由于皮带机速度≥3 m/s，普通相机拍出的渣片图像模糊且无法准确分辨，故本数据源所采用的渣片相机为线阵相机，最高行宽为4 096 pt，最高行频为28 000 pt，所生成的无损图像大小≥40 MB，利用激光进行补光处理后，无需外加灯光。

渣片状态在线监测系统设计方案如图14所示。硬件部分传输采用千兆网口，采用直连或者接千兆交换机的方式，将相机端接入到数据采集终端，相机采用独立电源/POE供电。软件部分网络传输基于TCP/IP协议，通过相机厂家提供的API接口和数据解析格式进行相机的查找、连接、拍摄及数据传输。

图14 渣片状态在线监测系统设计方案

3.3.2 现场部署测试

在进行渣片监测数据源测试时，同样选择云南大瑞铁路高黎贡山隧道TBM进行了相机搭载、通信测试等。如图15所示，回传的图像数据在上位机上显示，图像采集频率为0.7 FPS，图像大小平均为30 MB。

(a)相机现场部署

4 结论与讨论

本文主要论述了专用的隧道掘进设备多源异构数据采集系统的设计方案、实现方法及现场应用情况。采用一主多从的系统架构，按照“微服务”的设计思想，设计了数据源接入接口统一以及数据源进程相互独立的程序架构，开发出安全、稳定、高性能、高并发、低带宽占用的统一数据传输协议的程序框架，提出了一种以插件形式组织数据源接入，进行快速定制化程序开发并远程更新终端程序的方法。

通过隧道施工数据智能采集系统在工程项目中的具体应用，数据采集网关先后接入PLC数据、振动监测数据、渣土改良数据、刀盘磨损数据等10多种异构类型的数据源，解决了隧道施工中各种异构数据采集的难题。

由于本文所述的多源数据采集网关的边缘计算能力有限，内存资源有限，从而在同时接入多个大密度数据源进行传输时速率有所降低，因此，如何优化多个大密度数据源传输策略是今后需要研究的重点内容。