章群英，张耀允，戴 玮

(安徽省交通规划设计研究总院股份有限公司，安徽 合肥 230088)

0 引 言

桥梁工程建设是交通系统中重要的组成部分，现阶段我国桥梁基础建设逐渐完备[1]，但是桥梁养护工作成为现阶段一项重要的任务[2]。由于施工、气象、日照、以及承载力等因素日积月累的影响，桥梁不可避免发生裂缝、混凝土剥落、钢筋锈蚀和支座伸缩装置破损等病害[3]。随着桥梁养护数据量的日益增多和BIM+GIS信息化技术的兴起[4]，传统桥梁养护手段已不能满足当前的需求，人工处理方法明显滞后[5,6]，容易发生桥梁养护不及时甚至是交通事故，损害驾驶员及乘车人的生命和财产安全。

Web Service技术是当前数据分享的主流技术，该方法不受计算机软、硬件的约束，可以直接获取海量数据，速度快、安全性高、成本低、操作简单[7,8]。结合Web Service技术提供的第三方json养护数据开发一种信息化融合工具，根据不同用户需求，简单、高效的完成复杂桥梁养管数据的筛选、处理和输出，以便桥梁的及时维修和保养，有效的保障桥梁正常安全运营。

1 数据源

数据源主要包括Web Service技术通过URL地址分享的第三方json数据和数据库数据[9]。Web端的第三方json数据包含大量字段信息，需要根据设计需求进行筛选和处理。第三方json数据运用桥梁病害id作为关联id识别不同时间同一构件的相同病害。具体形式如下图1所示。检测时间由远及近，形式(a)：从第二次检测开始，其关联id依次继承上一次检测的病害id。形式(b)：从第二次检测开始，后续所有检测均继承第一次检测的病害id。形式(c)：从第二次检测开始，后续所有检测随意继承之前检测的任意病害id。利用桥梁病害的关联id可以在工具开发时，高效的去除冗余数据。

图1 (a)～(c)分别为三种不同的构件病害关联形式

为了方便描述，根据数据内容和结构分别定义若干个表格。MySQL数据库内包含了病害基础表、病害记录表、病害编码表、构件编码表、检测任务表等。表1分别给出了主要表格即病害记录表和病害基础表的表结构，病害记录表按病害种类划分为多个表格，每个表格内记录了发生该病害的所有构件的检测和维修状态包括检测或维修时间、构件id、维修状态和病害描述等。病害基础表记录了所有构件已维修或未维修或新产生的病害，只记录当前的三种病害处理状态。病害编码表和构件编码表利用数字编码分别标记病害类型和桥梁构件类型。构建编码表用guid编码识别不同的构件。

表1 病害记录表和病害基础表的表结构

2 工具设计与开发

病害记录表更新和完善的目的是为了获取发生某种病害的构件，其病害从发生到未维修再到已维修的时间、状态、检测批次以及损坏面积、长度、宽度等信息，以便相关人员及时检修。与病害记录表不同的是，病害基础表更新的目的是获取不同构件发生病害的当前状态。

根据以上需求，桥梁养管数据融合工具的设计主要包含三个模块：病害记录表的更新、病害基础表的更新和病害记录表的完善，设计框架如图2所示。首先通过URL地址获取web端第三方json养护数据，对数据进行预处理后存入数据库。用户可通过养护工具打开数据库数据，根据实际需求更新或完善病害记录表和病害基础表。最后根据不同实际需求，下载更新结果。

图2 设计流程图

2.1 病害记录表的更新设计

为了简化用户操作，增强数据的安全性和可靠性，保证数据入库质量，本课题引入一个病害预存表，后续更新也主要基于该表的操作。根据用户需求并结合图2的设计流程图，病害记录表的更新应放在首位。

病害预存表是来自于web端接口的第三方养护数据，由于该数据信息维度多，格式不规范，不易操作。因此在数据加载前，系统内部应提前对数据进行预处理操作包括筛选、字段名称修改、字段拆分、增加guid列、构件id的匹配等。数据经过预处理后，病害预存表内仅留下所需的字段信息。

数据预处理阶段是后续工具设计和开发的关键，由于数据源的不规范性，代码处理较复杂，因此前期工作的可靠性十分重要。基于清洗的数据，根据项目软件开发需求，设计关键修改功能，这些功能为用户的多样需求提供保障，设计如下：

(1)为了方便用户根据实际情况选择或者修改桥梁工程故障检测的开始时间和结束时间，除数据的增、删、改功能外，应给“开始时间”、“结束时间”设置时间列表。

(2)“状态”列描述了桥梁病害的当前状态包括新病害、旧病害和已修复，由于桥梁故障检测人员不可避免存在错填、漏填现象，以及桥梁病害状态的更新需求，设置下拉框供用户选择。

(3)病害id根据桥梁的构件类型划分病害，由于不同的构件可能会发生多种病害，利用构件树和映射方法构建病害分类体系树结构，供用户选填。

(4)构件id与病害id不同，构件类型的划分更加详细，要求定位到具体的某个构件上，因此种类繁多。这也是功能设计的一个难点和要点。确定后的构件id是一串guid字符，除了提供树结构供用户选填外，还要求通过定位guid字符直接找到该构件，因此需要设置构件实体分解系统EBS[10](Entity Breakdown System)。另外，应设置时间段查询工具，以实现优先对某段时间的数据进行更新。

2.2 病害基础表的更新设计

节已完成对数据预处理和病害预存表修改功能的设计。在此基础上，病害基础表的更新设计还应提供数据库中已存在的旧病害基础表，表中包含的构件id、开始时间、结束时间等字段可以作为参考信息，以便用户删除重复或者错误记录如图3所示。

图3 旧病害基础表的修改

2.3 病害记录表的完善设计

本节设计主要包括两个部分：桥梁病害记录表批次id的完善和桥梁病害面积、长度和宽度的完善。

由于批次id需要软件使用者桥梁检测的先验知识，拥有桥梁构件检测的批次资料，因此，该模块设计较为灵活。提供包含guid字段的检测任务表，并设置复制粘贴和批量复制粘贴功能，以便高效完成病害记录表批次id的更新。最后，将包含构件id、缺损情况描述和缺损范围字段的原始病害预存表通过底层筛选后提供给用户，方便用户根据构件id找到其中对构件损害面积、长度和宽度的详细描述如图4所示。

图4 病害记录表的完善

2.4 工具开发

按照设计框架和思路，首先进行病害记录表和病害基础表更新的开发，在此基础上进行病害记录表的完善。

开发基于MySQL数据库，采用C#编程语言并结合Visual Studio 2017的Microsoft .NET Framework 4.6.1框架，与之前版本的框架相比，Microsoft .NET Framework 4.6.1包括了大量与可靠性、稳定性、安全性和性能相关的修复。利用URL地址接收Web Service技术分享的第三方json数据，该数据需要经过清理、修改和导出，实现桌面端养护数据的查阅、处理和下载等功能。具体操作包括数据读入、数据加工、数据下载三个步骤，通过用户与软件的协同操作，对数据库表格进行特定的添加、删除、保存、匹配等操作，获取所需养护数据，实现了Web端第三方数据的加工和融合。

3 项目验证

以马鞍山长江大桥左汊悬索桥项目的数据为例，在实际项目运用中，该桥梁养管数据融合工具具有以下特点：(一)对于桥梁病害数据数据源的清理、入库后的加工处理较为完备，通用性强，可应用于其他桥梁公路项目；(二)可以在入库前和入库后分别检查数据源即第三方json数据的错误，因此数据质量明显提高；(三)该工具界面相对简洁、对复杂数据处理简单化、提高了数据加工的总体效率。

3 结束语

本文基于马鞍山长江大桥左汊悬索桥项目数据库数据和web端第三方数据，利用.net框架和MySQL数据库，根据用户需求开发了桥梁养管第三方养护数据融合工具，该工具可为桥梁BIM技术中的养护模块提供数据支撑，帮助检查员及时发现和维修桥梁，尽可能的阻止交通事故的发生，更好的保障人民的生命和财产安全。