蒋 鹏，刘洪涛

(1.安徽省公路工程检测中心，安徽 合肥 230051；2.桥梁与隧道工程检测安徽省重点实验室，安徽 合肥 230051)

0 引 言

安徽省干线公路桥梁安全监测平台(以下简称“平台”)于2013年开发投入使用，经过了几轮系统功能改造及平台升级，先后接入了十余座不同结构的桥梁监测子系统(以下简称“子系统”)，而数据接入的稳定性、完整性、可用性等问题[1]，始终是制约平台扩充发展的主要原因，根本问题在于平台端和子系统端数据的传输，为此，作了一定的尝试和探索。

1 远程数据传输方式探索

子系统的实时监测数据必须有效传输至桥梁管理部门监控中心，即平台端，进行统一维护管理，子系统也做了本地存储，实现了分布式数据库管理。初期远程数据传输[2]作了以下三个方面的探索：

传输方式一：按照平台端制定的通讯协议标准，由各家桥梁监测系统建设方负责开发各自的数据接口软件，获得平台接入授权后，通过网络发送数据到平台网关，经过网关预处理后传送至平台端数据库存储。

传输方式二：通过MS-SQL SERVER数据库同步模式，将子系统端数据同步到独立的数据库服务器中，该独立服务器相当于传输中转站，平台端主动抓取独立服务器中的数据。

传输方式三：子系统端采集设备直接上传到数据网关，该方式桥端不需要配置工控机，采集设备须具有网络功能模块，平台端网关接收的数据是原始数据，需要经过计算处理，需要提高网关服务器的计算能力和网络带宽。

2 远程数据传输存在问题分析

三种传输方式经过一段时间的试运行之后，表现出子系统端没有回传数据、数据时断时续、数据回传延迟时间长、回传数据质量不理想等问题。

上述三种数据传输方式在运行中主要存在以下问题[3]：

(1)结构复杂，平台数据网关要同时处理三种类型的数据接入方式，降低了整个系统稳定性；

(2)升级影响大，一旦平台进行功能升级或通讯协议进行版本升级，所有接入桥梁的自建数据接口软件都需要同步改造，重新开发和测试；

(3)软件质量无法保障。因各桥端建设方自建接口软件没有办法统一要求，软件质量无法控制，使数据上传效果始终得不到保证；

(4)重复投资，每新建一套监测系统，采购了不同厂家的设备，都存在开发接口软件的费用；

(5)故障难以定位和定责，由于数据接口各环节存在交叉和分工，对传输中断、数据延迟等情况难以控制和解决；导致数据质和量无法保证，这极大的降低了平台的有效性，也影响下一步数据应用和分析能力。

(6)各自建接口软件功能不一致，包括数据校验、中断续传等功能或者不能实现，或者将本应分布处理的应用集中到了平台数据网关，使数据网关增加额外的压力。

3 解决方案

针对以上情况，经过对相关桥梁的情况分析，我们将平台功能向子系统端延伸，开发了一套桥梁监测大数据平台配套系统——基于ZMQ的通用型数据接口软件[4]。将以前由各桥端公司开发的各自不同类型、不同功能、不同质量的接口软件，改为由平台端统一编制的接口软件，并规范好子系统端的数据存储格式，由接口软件自动提取子系统本地的数据，通过网络发送至平台端数据网关。

后期的管理模式是桥梁健康监测系统承建方根据要求建立数据库表，并提供远程登录方式，平台端技术人员远程登录子系统端工控机，根据操作说明完成接口软件安装及配置，向平台端发送请求，得到接入许可后即可实现工控机数据的获取和上传，数据上传工作各环节均不需要承建方的参与。当系统出现中断时，该接口软件自动进行比对和中断续传，当平台进行升级时，该接口软件可以远程同步升级。

4 结 论

平台端制定的接口软件一次性的解决数据传输方面的问题，并为今后大量桥梁接入的运维管理打好必要的基础[5]。此外，以该软件为抓手，增加了远程控制子系统端工控机的管理模块，可以实时在线监测工控机的CPU、内存等硬件运行状态，发现问题及时处理。该传输方式的应用规范了长期运维模式，有效降低运营成本，减少管理投入，同时也避免了各建设方之间交叉环节，提高了平台的故障响应能力。