摘 要：近年来，我国交通道路在迅猛发展中，其重要的组成部分隧道数量也在不断上升。由于我国地理环境比较复杂，隧道集中监控系统在公路的运营和管理以及紧急预案处理中发挥着极其重要的作用。因此，隧道监控系统成为工程单位和公路营运管理单位共同关心的问题，建设稳定、先进、经济以及扩展性强的监控系统成为当前道路监控的首要目标。随着电子技术、通信、计算机技术的高速发展，公路交通逐渐走向信息化和智能化的程度。监控系统除现场较为成熟的硬件及通信体系外，具有可仿真、易拓展、易维护及支持多重冗余体系的计算机监控系统平台成为隧道监控系统的主要软件平台，与硬件通信系统接口的整合后共同推动着隧道监控系统的智能化程度的发展。

一、系统组成

隧道按长度分为短、中、长隧道，一般中长隧道(>250m及>1km)需要考虑的监控设施会较多，集中监控点也较多。中长隧道按国家的设计标准要求必须要配套监控系统以保证隧道内行车的安全和通畅。

隧道的子系统主要包括：照明系统、通风系统、交通诱导系统、CCTV电视监控系统、火灾报警系统、消防控制系统、紧急电话系统、广播系统、LED显示系统等。主要涉及到的控制与检测硬件有PLC控制器(监控通风、照明、消防水泵、车道/交通指示灯等)、车辆检测器、亮度/照度检测仪、风速/风向检测仪、一氧化碳/能见度检测仪、火灾报警主机、LED显示屏、紧急电话、CCTV系统。

从计算机的数据采集方式上主要分为:PLC实时监控系统、CCTV电视监控系统、紧急电话/消防报警/广播系统、LED显示屏系统及紧急预案系统，做为计算机组态软件平台是可以将五个子系统都集成在一个平台上的，但就目前的实际情况来看，上位软件与PLC实时监控系统的接口最为成熟，其它子系统的通讯接口方式都有其独立性的特点，需要进行一些定制的接口开发,实际的数据交换是必然的，这样对组态软件平台就要有良好的开放性、兼容器及可扩展性要求。

二、解决方案

目前的隧道监控系统最重要的指标是必须支持良好的C/S架构、支持ODBC快速接口、支持OLE接口访问、SDK开发包及WEB发布，力控ForceControl6组态软件平台是完全满足以上几项指标的，上述指标在隧道行业的功能特点十分明显，也是解决数据通讯及采集的最有效方式。

1、所有PLC设备的数据通过以太网可以单独与上位机通讯，当然也可由主PLC集合所有从PLC的数据单独与上位机通讯，上位机通讯采用单独的服务器与PLC设备通讯，首先体现的是组态软件的特点，建立IO设备组态和变量标签，将实际的IO设备通道值与变量标签对应，这样现场真实的数据就采集至监控中心，然后组态软件在服务器端下一步要做的步骤不是建立组态工艺画面，而是进行数据的网络共享，进入运行系统后以网络服务器并占用内存/CPU使用率最小的方式在后台运行，实时刷新与存储需要的历史数据，所有的画面都不需要打开,依然保持服务器系统的运行。数据流是通过局域(广域)网与客户端同步方式将数据体现于操作员站仿真的工艺画面中，这样不同的操作员站可定制不同的工艺画面，在客户端有图形化的自主开发性能，这样的C/S架构既保证了整个系统的稳定性也减少了交叉控制的冲突率。

2、ForceControl6的ODBCROUTER组件适合于交通紧急预案分析系统的数据整合,将实时或历史数据以时间间隔方式或以变化率方式存储至预案系统所需要的关系数据库中,主要以模拟量值与故障报警值为主,向导方式设置的过程省去了很多SQL脚本语句的编写,简单、方便、快捷的为紧急预案分析系统提供了原始数据。

3、OLE接口(DBCOM)访问适合于目前绝大多数的高级编程环境(DELPHI、VB、VC++、.net等)中，直接加载已注册至系统中的DBCOMOCX控件就能访问到本地或远程的力控实时数据库(DB)中的数据，在预案分析系统中绝大多数开关量数据是不需要存储的，因此直接访问DB变量的方式来监控，效率极高,减少了总是用ODBC来做数据通道的繁琐性，以“ODBC+OLE接口”两者相结合的方式优化了监控系统与紧急预案分析系统的数据整合。

4、具有自身的软件及通讯协议的LED显示系统、车检系统、紧急电话、消防、CCTV系统，目前所有组态软件在交通隧道行业所包函的此类硬件驱动都是屈指可数的，相当少，在针对整个监控系统集成方案具体实施时就必须考虑以上几个子系统的驱动接口开发问题，力控SDK包制定了驱动接口开发的统一标准，可由高级语言(VB/VC++)开发人员定制开发也可由力控驱动部定制开发，硬件接口驱动解析较为灵活。目前由力控在楼宇项目中的大量应用所积累的经验，相关的CCTV、消防及紧急电话系统已有部分驱动接口，可根据现场实际硬件选型情况是否定制开发，针对车检数据及LED显示系统是否集成于实时监控平台中来定制通讯协议接口的开发。

5、监控系统WEB发布目前在隧道监控领域应用较少，但信息化手段解决交通道路的管理问题终究是交通领域发展的必然趋势，软件的网络结构必须要先行。

三、网络通讯架构

1、原交通隧道监控系统网络通讯架构如下:

由上图可看出初期交通隧道的设计都偏重于现场总线与以太网混合的复杂通讯结构设计，一方面程序设计人员在现场有较大的软硬件调试工作量，一方面也增加了整个系统数据的采集难度。在中控室中并未设计到其它子系统与实时监控系统之间的整合问题，相互之间都是独立的。将车检器与LED大屏都考虑至现场以PLC的通讯来解决数据采集与控制问题，实际所得到的验证是不可靠、不灵活的，车检数据的采集、转发与存储利用PLC的通讯方式很难取到较为准确的统计数据，以及LED大屏显示常常要以ASCII码的方式写一些天气或致词方面的汉字，由目前的常用的PLC是不能实现的，只能以调用已经建立好的文字列表，以通讯协议方式来切换内容的列表号，而不能灵活的进行汉字的输入。

2、初始硬件通讯结构设计决定了上位软件所发挥的作用较为有限，随着实际工程的验证后，目前的通讯网络结构已经有了较大提升。

由上图可看出硬件通讯结构及系统集成方案都是全以太网的通讯结构，由上位软件通过定制的驱动接口程序直接对车检器及LED进行访问，PLC硬件的逻辑编写与调试也全都在中控室直接下载或上传，CCTV由矩阵的通讯接口与上位软件通讯，紧急电话与消防系统可用API、ODBC等数据访问方式获取数据，这样由客户端操控的就是所有的隧道监控子系统，使得系统的整合较为完美。

四、管理及维护

1、硬件通讯管理及维护，就目前的通讯结构来说，所有的硬件或子系统都在一个网段内，判断硬件的通讯是否正常只需要由程序开发人员对其状态动作进行组态即可，由图形化仿真的形式让运行人员知道硬件设备的通讯情况，并实施相应的处理方案。

2、图形化界面的维护，所有交通领域中的图元都有重复使用的必然性，因此将某一类做好的图元转换为图库的处理，以便经常调用，在一些关键的控制动作上加安全区或设置一定的权限，由于紧急事件发生时的预案系统处理具有着较高的优先级，为了避免现场的虚假现象导致大型设备的自动开启还需要有人为确认的预警提示信息才可执行。

3、客户端是可以进行复制的，但需要将开发环境中网络节点的本地IP更改掉才可访问到远程数据，同时也要注意网络服务端是否有足够的对远程客户端访问所限制的数量。

4、ODBC接口主要运用于网络中用来将实时数据转存关系数据库中，由预案系统对数据进行分析，并通过DBCOM访问实时数据库开关量点的方式执行相在的预案，如无紧急事件发生时，预案系统一直处于待机状态，需要将客户端与此系统的优先级进行划分。

5、 由于分段的隧道监控系统的数据点数都较多，普遍都能达到4K点以上，对服务器的数据吞吐量及系统的稳定性有着极大的考验，对系统的优化必不可少，介于网络的通讯，一些防火墙类程序不太适合运行于网络中，尽量减少计算机的进程数，必须有防毒软件避免病毒的侵入。

6、与PLC系统的通讯，尽量减少IO设备列表的数量，即PLC的数据通讯的网络体系结构非常重要，由上位软件通过以太网点对点方式去访问所有PLC的数据是不合适的，由于PLC数量庞大，甚至可达上百台的级别，如果建立上百个连接是必会让系统中增加上百个进程，这对计算机系统是有风险的,目前的方案全都是PLC系统以分组方式进行数据交换，最终定义的所有的主PLC与上位软件进行通讯，有效减少了IO设备列表数量，得到的是高效稳定的系统。

结束语：

交通隧道监控系统引入组态软件已经是以后交通隧道管理的必然趋势，目前大部分隧道系统都利用组态软件预留了数据接口供管理层对未来实施信息化的全方位管理奠定基础，以力控组态软件为核心的信息化平台也将发挥其重要的作用。