1 引 言
隧道病害是隧道因施工质量问题或运营环境波动而出现的结构破损或劣化现象，普遍存在于运营期隧道，是隧道运营期无法回避的现实问题。通常， 隧道病害主要分为渗漏水、衬砌损裂以及结构超限变形三大类，且各类病害之间相互影响、耦合，若不及时整治，将会导致隧道结构状态的劣化，威胁隧道运营安全[1~3]。
由于隧道结构类型及运营环境的差异，隧道病害的表现形式具有极强的多样性，相应的整治方式也不尽相同。以明挖隧道的渗漏水整治为例，明挖隧道的渗漏水主要表现为变形缝及施工缝渗水、混 凝土开裂渗水以及大范围面漏等，相应的整治措施 有安装止水带、注浆止水及防水材料换填等[1,4] 。可见，隧道病害的整治需要根据病害的具体表现对症下药，若忽视隧道病害信息的整理及分析，将会严重影响隧道病害的整治效率，从而不利于隧道的安全 运营。因此，建立隧道病害管理系统，高效地整合并 分析病害信息，及时为隧道病害整治策略提供指导， 对保障隧道安全运营有着积极而深远的意义。本文 将从隧道病害信息数据库以及交互管理系统平台两方面对目前我国隧道病害管理系统的研究现状进行总结分析，并指出未来可能的发展方向。
2 隧道病害管理系统的组成
目前关于隧道病害管理系统的研究已有了一定成果，如周健等[5]从数据库设计及系统开发两方面具体阐述了公路隧道病害预防性养护管理系统的技术特点及功能要求。方恩权[6]以 SQL Server 数据库 整合地铁隧道结构病害信息，并以此为基础利用 Web Service 和Java 语言开发地铁隧道结构病害调查管理系统，实现了病害信息的电子化采集、同步存储以及病害信息浏览、查询和统计分析 。刘志强等[7]以SQL Server 数据库整合隧道结构及病害信息， 在此基础上以Sharp GL 扩展库开发了铁路隧道病害三维虚拟展示软件，实现了隧道病害的展示及整治分析。
可以发现，隧道病害信息的处理、展示及分析是隧道病害管理系统的主要功能，而隧道病害管理系统的结构主要由处理病害信息的数据库和基于数据库开发的交互管理平台两部分组成。常用的隧道病害管理系统的框架结构[8]如图1所示。
图 1 隧道病害管理系统的框架结构
3 病害信息数据库
病害信息数据库是隧道病害管理系统的基础， 负责病害信息的底层管理，为病害信息的多元化展示及分析提供数据支撑。 目前，常用的病害信息数 据库主要有关系型数据库和非关系型数据库两种， 关系型数据库是通过将病害信息归结为二维表格形式，再以这些二维表格为基础，建立表格之间的联系，最终构成如图2所示的E-R模型（实体-关系模型），通过二维表格间的联系路径，完成不同二维表格间信息的分类、合并及选取等操作，实现对病害信息的底层管理。非关系型数据库通常是关系型数据库的简化，弱化了关系模型和表结构的约束，将数据存储在文档、键值对、列簇或图结构中，并根据数据类型选择数据的存储和提取方式。
图 2 隧道病害关系型数据库的 E-R 模型
在隧道病害信息数据库中，有关病害的量化指标信息是数据库中不可或缺的信息，是评定隧道结构健康程度，确定病害整治方式的依据。常见的隧道病害量化指标见表1。
目前，隧道病害数据库建设主要采用Acess、MySQL、SQL Server及Oracle这类关系型数据库，应用方向主要有3个方面：（1）以数据库为载体，系统地收集病害监测数据，以辅助具体的病害分析[9,10]；（2）通过数据库整合隧道工程概况、病害情况及病害评价信息等，强调病害信息的数字化管理[11~13]；（3）通过数据库整合隧道结构参数、坐标、病害属性以及方位坐标等信息，为隧道结构及病害的虚拟仿真提供数据支撑[14,15] 。总结各类关系型数据库的基本情况见表2[9~19]。
由表2可知，MySQL数据库使用门槛低，易于网络化推广及开发，但其数据处理的功能相对单一并且存储容量有限，因此，MySQL 数据库多用于病害属性信息的网络化交互[18]。SQL Server 数据库具备 一定的容量及扩展能力，并且支持存储数据的挖掘及分析，因此，常用于辅助病害监测数据的分析以及隧道病害的虚拟仿真[19]。Acess 数据库有着强大的表处理能力，其适用于隧道结构及病害属性信息的普查统计[13] 。而 Oracle 数据库虽然容量巨大，功能齐全，但其使用门槛较高，通常服务于大规模的隧道运维业务[17]。故隧道病害信息数据库的选用应结合隧道的管理需求进行综合考量。
关系型数据库虽然在隧道病害数据处理上得到大量应用。但是，目前关系型数据库的信息范围还停留在隧道病害的属性及评价信息，信息存储量有 限且主要存储文本及监测数据。以南京定淮门隧道健康监测系统的数据分析为例，数据主要来源于传感器采集的监测数据，如图3所示，该监测系统在N线和S线均设立了专门的关系型数据库用来存储传感器的监测数据，其中 N 线更是设立了两个关系型数据库用以分担数据存储负荷[9]。可见，关系型数据库由于其普遍具有存储容量有限，在面对大数据量及高并发操作下读写性能不佳的短板，无法全面地整合海量的监测数据，常需要多个数据库来分担数据存储负荷，而通过多个关系型数据库分担数据存储负荷的组织方式不利于监测数据的深入分析[20～23]。可见，仅依靠关系型数据无法做好隧道病害的数据存储及管理工作。
图 3 南京定淮门隧道结构监测数据处理流程图
当病害数据库的数据量及用户访问量达到一定程度，关系型数据库读写表现不佳时，非关系型数据库便成为了病害信息处理的可行选择。虽然非关系型数据库在隧道病害信息的处理上尚不成熟，但在其他领域中已有一定应用，而非关系型数据库通常用于实时数据的处理，例如，用户登录信息的缓存[24]，隧道施工信息存储[25]，现场实测数据的缓存[26,27]以及大型室内场所运维状态的感知[28]。总结主要非关系型数据库的特点见表3[24~29]。
分析表3可以发现，非关系型数据库采用分布式存储架构，能够有效分担存储负荷，同时借助缓存技术优化读写性能，从而实现对大规模数据的快速处理和并行操作。故非关系型数据库在实时热点数据的缓存、大数据云存储等方面具有显著的优势。 但非关系型数据库也同样存在着使用门槛高，数据 存储不规范，技术成熟度低，在隧道病害信息管理方 面使用经验少，条件查询效率低，多次检索结果可能不一致，以及数据库维护困难等诸多难题。
然而，随着激光扫描仪、CCD 相机、地质雷达、 无人机以及挂轨式巡检机器人等新型病害感知技术的普及，病害信息将不再拘泥于结构化的表格、文字 及数字，非结构化的图像、视频将会成为病害信息的重要组成部分。病害信息的规模和类型将得到极大的扩展，故未来的病害信息数据库势必要引入非关 系型数据库,一方面，提高病害信息数据库的数据容 量，另一方面，将图片、视频以及点云图像等多元化 的病害感知素材纳入管理范围，以提升隧道病害的管理效率。
4 基于病害信息数据库开发的交互管理平台
基于病害信息数据库开发的软件管理平台在隧 道病害管理系统中的主要作用是帮助用户对病害信息数据库中的信息进行浏览、调入、导出、修改及查询等交互式操作，并为用户深入分析病害数据提供便利。交互管理平台是隧道病害管理成果的集中展示， 而其开发的重难点在于有机融合各数据库中多源异构的数据信息，实现隧道运营状态的可视化[30~32]。
病害交互管理平台功能如图4所示，主要由病害信息获取界面、病害信息浏览界面、病害信息编辑界面、病害信息分析界面以及用户管理界面五部分组成。其中，信息获取界面负责提供病害检测成果， 包括病害图像、视频、巡检报告以及监测数据等，为病害的深入分析提供基础材料[33,34]；信息浏览界面负责隧道结构及病害的直观展示，主要手段有隧道虚拟漫游、病害图像及视频浏览等[35,36]；信息编辑界面负责调整数据库内的信息存储，包括数据的导入、 修改以及删除等；信息分析界面负责直观呈现病害管理成果，主要内容有病害信息评价及预警，曲线及图表定制以及数值模拟预测等[37]；而用户管理界面主要负责调整管理人员的信息及其权限。
图 4 病害交互管理平台的功能组成
基于病害信息数据库开发的交互管理平台主要存在3 种架构：
（1）C/S 架构（Client/Server，客户端/服务器），隧道内的数据工作站依托局域网或通信光缆 远程传输数据，隧道监控中心作为服务器接收数据， 并开发软件加以管理，管理者可在隧道监控中心的 机房中通过操作软件管理隧道病害信息[38]。
（2）B/S 架构（Browser/Server，浏览器/服务器），将所有功能集成于服务器中，管理者通过网络浏览器完成病害信息的浏览并向服务器提供管理需求，而服务器负 责数据底层管理工作，并向浏览器反馈管理效果[39]。
（3）混合架构，是 C/S 架构与 B/S 架构的嫁接融合， 以C/S 架构负责数据同步，以B/S 架构负责数据多元化展示[40]。
关于管理软件平台的开发，目前已有了一些工作，总结如下：
（1）C/S 架构
传统的交互管理平台主要依托 C/S 架构进行开发，即管理人员在隧道监控中心通过操纵专用软件完成病害信息的管理工作。常用的软件开发工具主要有Navicat、BGKLogger、ArcGIS Engine、Open GL 以 及Multigen Creator 等，如图5所示，基于C/S 架构开发的交互管理平台与病害信息数据库通常呈单线交互的关系，数据库负责依托局域网/光纤，经数据库接口向业务逻辑层提供数据，并接受来自业务逻辑层的反馈；业务逻辑层一方面向数据表现层提供多样化的功能调用，另一方面，向数据库调取或保存数据； 服务表现层为操作界面，为用户提供操作接口[40,41]。
图 5 交互管理平台的结构组成（基于 C/S 架构）
基于 C/S 架构的交互管理平台有着强大的数据 管理功能，例如，病害采集数据的实时同步及多视角呈现[40]，隧道结构及病害的虚拟仿真[6,13]，病害数据智能预测[41]以及检测报告的自动生成等[39]。但由于 C/S 架构的技术特点，这些交互管理平台普遍存在更新维护困难、需要安装软件、使用成本高以及信息 表现效果差等问题[39]。
（2）B/S 架构
随着社会网络化程度的提高，越来越多的交互管理平台开始依托 B/S 架构进行开发，如图6所示。 相较于C/S 架构，基于B/S 架构的交互管理平台简化了客户端，管理人员通过网络浏览器登录账号即可实现病害信息的管理，并将功能实现及软件部署全部集成到网络服务器中，简化了系统的开发及维护工作[38,42,43]。基于B/S 架构开发的交互管理平台有着更新维护方便，与全景视觉、WebGIS 等新技术兼容性好的特点，通过实景展示及数据可视化等技术，实现隧道 病害信息的多样化展示，便于直观反映现场的病害情况，并帮助管理者深入地挖掘病害检测数据的价值[35~39]。但这类交互平台严重依赖网络，无法及时同步病害感知数据，并且平台的功能实现完全依赖于网络服务器，导致服务器负载较大，无法承受多用户访问以及大规模数据吞吐所产生的负荷，这给病害检测数据的管理与分析带来了不利影响。
图 6 交互管理平台的结构组成（基于 B/S 架构）
（3）混合架构如图7 所示，基于C/S-B/S 混合架构的交互管理 平台，以 C/S 架构搭建的管理软件负责面向基层的 专业技术人员，负责病害数据的基础管理，如查看病 害检测素材（包括病害图像、激光点云数据以及传感 器读数等），病害检测设备的调试（如调整传感器阈 值、采集频率以及配置数据采集公式等），病害检测数据的更新、整理，数据的专业分析及检测报告的自动生成等[21] 。以 B/S 架构搭建的浏览器负责面向高 层管理者以及部分外界人士，通过隧道场景漫游、定制图表曲线及病害自动评价与预警等方式，展示病害管理成果，使其直观地了解所管理隧道的病害现状及发展趋势，为后期病害管理策略的制定提供帮助[44]。
图 7 交互管理平台的结构组成（基于 C/S-B/S 混合架构）
隧道病害管理面临一个核心矛盾：既要高效处理海量数据入库、管理和分析，又要快速共享病害信息和整治建议，单一架构的管理平台难以应对这些复杂需求。由于管理涉及多方人员，且各自需求多样，而采用混合架构是未来的可行方案，即利用 C/S 架构软件进行基础病害数据管理，并将成果传输至网络服务器；同时，通过B/S 架构的浏览器平台展示多样化的病害信息并提供交互接口。这种混合架构既能充分发挥两种架构的优势，降低维护成本，满足多方管理需求。
5 结 论
通过对我国目前隧道病害管理系统研究现状的分析及展望，可以获得下列结论：
（1）隧道病害管理系统主要由两部分组成，即病害信息数据库以及基于病害信息数据库开发的交互管理平台。隧道病害信息的整理、展示以及分析是隧道病害管理系统的主要功能。
（2）目前的隧道病害信息数据库主要依托关系 型数据库进行开发，常见的关系型数据库主要有 MySQL、SQL Server、Acess以及Oracle。其中，MySQL 数据库适用于病害数据的网络化交互，Acess数据库适用于隧道结构及病害信息的普查统计，SQL Server数据库可以辅助隧道病害的数据分析及虚拟仿真， 而Oracle 数据库通常服务于大规模的隧道运维。
（3）引入非关系型数据库，用于存储图片、视频及点云图像等多元化的病害感知素材，解决关系型数据库的容量限制，这将成为未来病害信息数据库发展的主要方向。
（4）常用的交互管理平台主要为C/S 架构（客户端/服务器）和B/S 架构（浏览器/服务器）2种。其中， C/S 架构虽然有着强大的数据管理能力，但难以大规模推广，并且数据表现能力差。而 B/S 架构虽然数据表达能力强，易于网络化推广，但无法承受大规模的数据吞吐，不利于病害数据分析。
（5）采用 C/S-B/S 混合架构，以 C/S 架构负责数 据的基础管理，以 B/S 架构负责病害信息的多样化展示，是未来病害交互管理平台的一种可行选择。