基于Web的地铁盾构施工数据管理平台

2018-03-23吴建波

软件 2018年2期

吴建波，孙庆

（中建三局集团有限公司，湖北武汉 430064）

0 引言

在城市地铁及地下综合管廊的施工过程中，盾构机是最常用的地下隧道挖掘设备。因为地下施工工况复杂，风险大，成本高，每一次地下隧道施工都要记录详细的施工数据，作为后续的施工的数据参考和经验依据。

地铁施工时，各个区间的施工往往是同时进行的。每个施工区间的盾构司机，测量人员以及盾构机本身的数据采集系统都会记录下相关的施工数据。目前这些数据的管理非常分散，各项目部之间的数据管理相互独立；项目部内部，所有工作人员记录的数据基本以纸质文件，或者分散于多个文件中保存。比如盾构司机填写的施工日志，每环管片推进参数记录，测量人员记录的监测数据等等。这些数据文件相对独立和分散，不便于查阅和统筹处理分析。盾构机在运行过程中，本身会采集自身所有传感器的数据并且保存在设备的工控机上，这些数据非常详细地反映了设备的工作状态，但这部分数据基本没有收到关注。

为了分析地铁盾构法施工过程，首先就是要收集详细的施工过程数据。人们对这些数据的收集做了大量工作，文[1]实现了对盾构隧道施工中风险信息的记录、归档和统计分析，文[2]建立了一个传感器网络来实现隧道工程的自动监测，文[3]针对具体的工程实现了施工数据的收集和多种数据的分析方法，文[4]介绍了一个盾构施工管理信息可视化分析软件。本文阐述了一种低成本的通过网络平台来实现多个项目施工过程数据收集的方法。该平台部署在云服务器端，可以收集多种的施工数据，包括盾构机采集的传感器数据，可以多个用户同时访问，不需要额外硬件设施，维护工作量少。各项目相关工作人员，定期将其获得的施工数据上传到服务器，服务器端将对这些数据分类整理和保存，实现对所有施工数据的集中管理，为盾构的统筹分析提供了坚实的数据支撑。

1 开发软件环境

该平台基于Django框架开发，使用MySQL数据库管理系统[5-8]。前端采用 Bootstrap和 jQuery，数据绘图采用 Echarts插件，开发完成后使用gunicorn和nginx部署到云服务器。

Django是用Python语言编写的，广泛应用的开源web框架之一，自带后台管理界面，支持多种数据系统，可方便快速搭建WEB应用。MySQL是最流行的关系型数据库管理系统之一，支持多种编程语言和各种操作系统。Bootstrap和jQuery是用来快速构建前端web页面所用到的CSS样式库和JS框架。Gunicorn是一个应用广泛的高性能的 Python WSGI UNIX HTTP服务器，具有使用非常简单，轻量级的资源消耗，以及高性能等特点。Nginx是一个很强大的高性能Web和反向代理服务器系统架构软件。

2 系统功能分析

采用盾构法施工时，施工主要有两个方面：①对施工区域及周边环境的监测数据；②盾构掘进数据。

施工监测是为了检验施工质量和防止施工对周边环境产生破坏，而对已施工区域及周边重要建筑物进行测量，这也是隧道施工相关规范要求的必须进行的工作。隧道施工的施工监测类容一般包括：地表沉降，燃气，房屋，拱顶等。监测点在施工之前标定好，隧道施工时，对施工区域一定范围内的监测点做定期的测量。测量的周期一般是一天一次。

盾构掘进数据是在隧道掘进过程中产生的数据。包括两个部分：①盾构机操作工人记录的数据；②盾构机设备记录的各种传感器数值。根据各项目的具体需要，盾构机操作工人记录的数据也不仅相同，一般包括对施工进度，施工质量，耗材消耗量，施工过程中遇到的问题等方面的描述。其中有一部分的数据是盾构机无法通过传感器测量，需要进行人工观测的。这部分数据量也不大，记录的频率一般是每掘进一环（1.5米）一次，或一天一次。盾构机在开机情况下会对设备上所有的测量传感器定时采样，并把这些数据记录到系统的数据库。设备采样的频率高，传感器数量多，因此这部分数据量非常大，但如果不经过合理的数据处理，很难从中观测到有用的信息。

本系统设计的目的首先是要将这些数据能全部收集并保存下来，并以合理的逻辑结构形式呈现给用户；其次是集成有效的数据处理方法，从这些数据中提取有用的信息。对于数据量不大的监测数据，可在web页面上画出数据的曲线图；对于数据量非常大的盾构机传感器数据，提供数据处理方法和完整的原始数据下载链接，用户可以下载到本地机后运用相应的数据处理方法分析数据。

系统架构如图1所示，用户通过该平台的web页面录入各种施工数据，后台收到数据后分类整理保存在数据库中。用户需要时，后台将数据传递到前端，在浏览器中生成图形或数据下载链接。

3 系统的实现

因为系统需要管理监测数据和隧道掘进两部分数据，而且这两部分数据只有少量的数据重叠，这里将它们分开来处理[9-12]。在Django工程中，创建两个应用，分别管理施工监测数据和隧道掘进数据。

3.1 监测数据管理

以武汉市地铁 21号线百步亭站-新荣站的实际工程为例。根据测量对象不同，监测数据分地表沉降，周边房屋沉降，给水，拱顶等类型。不同类型的监测对象，对数据变化量的控制要求也不一样，这里进行分类处理。所有监测数据的记录格式基本一致，截取部分地表沉降监测数据如表1所示。

为方便同一个监测测点所有测量数据的读取，将同一测点的所有测量数据用外键连接起来形成一个前向链表，这样在计算监测数据变化速率和累计变化量时将非常方便。充分考虑数据库设计范式的情况下，施工监测的数据模型设计如表2所示。

表1 地表沉降监测数据Tab.1 Settlement monitoring data

3.2 隧道掘进数据管理

以武汉市地铁 21号线百步亭站-新荣站的实际工程为例，隧道掘进过程中，盾构操作工人记录的数据和盾构设备记录的数据如图2所示。

为了兼容所有区间的施工记录，将人工记录的数据统一为[设备编号，环号，日期，数据内容]，其中数据内容包含了后续所有的数据，而每项数据所代表的具体意义在对应设备的列表中给出。同样将盾构机记录的数据统一表示为[设备编号，时间，数据内容]。

隧道掘进数据模型设计如表3所示。

3.3 数据导入和输出

为方便数据的上传，所有的数据记录都通过CSV或Excel表格文件上传后导入系统数据库。同样下载的数据也是表格形式文件。

监测数据的导入模板文件包含多个工作表，每个工作表存放一类监测数据，比如：地表，燃气，房屋，给水等，分别对应于该区间的监测内容名称。文件通过前端上传，后台程序调用openpyxl库来读写表格文件，检查数据格式，并将格式正确的数据保存到数据库。

表2 监测数据表模型Tab.2 Monitoring data model

图2 隧道掘进数据Fig.2 Tunneling data

表3 隧道掘进数据表模型Tab.3 Tunneling data model

盾构掘进数据的上传也采用同样的方式，由于不需要分类，模板文件格式更简单。

数据下载采用 CSV文件格式，合理的利用模板，用少量的代码就可以实现数据文件下载。首先编辑 csv模板文件内容为“{{list_contents}}{% for item in records %} {{ item }}{% endfor %}”，其中list_contents为每列数据代表的意义，保存在掘进设备表中，records为选择的所有数据项；然后在数据模型的中编辑__str__(self)函数，定义好数据的打印格式；最后返回渲染模板函数，并将 content_type设置为" text/csv "，即可生成渲染好的数据文件。

3.4 监测数据绘图

考虑到监测数据量不大，为了方便用户查阅，在前端以图形方式呈现，如图4所示。Django后台程序从数据库中读取数据，写入模板文件，结合JS和Echarts插件在前端显示图形[13-14]。

4 服务器部署

为了节省项目的硬件成本以及相应的维护成本，这里购买了云服务器来部署该平台。服务器的操作系统维 Ubuntu 16.04，系统自带有 Python2和Python3，这里使用Python3运行Django，则需要依次安装软件有：pip3，Django，mysql，git，gunicorn,nginx。安装好之后，按如下步骤部署服务器[15]：

（1）使用 git工具将编写好的平台代码和相关资源文件同步到服务器端的/var/www/目录下。如果后续对代码做了修改，也可以用git工具非常方便地更新。

（2）创建Mysql数据库和对应的用户，并且与Django工程的setting.py文件中的数据库设置一致。

（3）安装Django 项目依赖的python包，对每个app使用makemigrations命令，然后使用migrate命令生产数据库表格。

（4）配置gunicorn；在Django工程目录下执行命令gunicorn-b0.0.0.0:8999 dj_project_name.wsgi，执行命令之后，可以在客户端浏览器访问页面，访问地址：服务器 IP(x.x.x.x):8999，但不能访问图片，样式等静态文件。

（5）配置 nginx；在/etc/nginx/sites-available/新建配置文件，内容如下：

图3 监测数据的导入模板Fig.3 The import template for monitoring data

图4 地表沉降曲线图Fig.4 Surface subsidence curve

编辑好配置文件后，将该文件链接到目录/etc/nginx/sites-enable/，通过命令行检查nginx配置语法并启动nginx，就可以在客户端浏览器看到完整的页面（访问地址：http://x.x.x.x（服务器IP））。

部署过程中需要注意的两个问题：①服务器的端口；部署过程中用到了 8999和 http协议默认的80端口，需要开放服务器端的这个两个端口才能在客户端浏览器正常访问。②数据库的字符集；如果需要在数据库模型中使用了中午字符，需要设置数据库的字符集为utf8，否则在用migrate命令生成数据库表时可能出错。