基于OPC的隧道监控软件性能优化

肖又发

（中海网络科技股份有限公司，上海200135）

0 引 言

公路隧道属于整个路段中的特殊构造段，因为其内部空间小、密闭性强，一旦发生火灾、交通事故、交通拥堵，环境会发生急剧恶化，将直接影响司乘人员的健康和生命安全。因此，建立功能完善、运行可靠的监控系统非常重要。当前的隧道监控软件主要是基于成熟的组态软件或用于过程控制的OLE（OLE f or Pr ocess Control，OPC）开发的。但采用OPC自动化接口进行开发的程序存在严重不足，当监控点数达到一定数量后，软件响应速度将急剧下降。为此，提出采用分布式系统架构及数据订阅的方式获取反馈数据，使基于OPC开发的隧道监控软件尽量不受监控点数的限制，从而适用于长大隧道及隧道群的实时性监控需求。

1 OPC概述

OPC是一个工业标准。它采用客户／服务器体系，基于微软的COM／DCOM的接口技术，为硬件厂商和应用软件开发者提供一套标准。OPC规范包括OPC服务器和OPC客户端两部分，其实质是在硬件供应商和软件开发商之间建立一套完整的“规则”。只要遵循这套规则，对两者来说数据交互都是透明的，硬件供应商无需考虑应用程序的需求和传输协议，软件开发商也无需了解硬件的实质和操作过程。应用程序作为OPC客户端 ，硬件驱动程序作为OPC接口中的OPC服务器端，OPC的访问关系见图1。

OPC规范中定义了2种标准接口：自定义接口（custo m interface）和自动化接口（auto mation interface）。其中，自动化接口是对自定义接口的进一步封装。使用OPC定制接口进行数据访问具有效率高、速度快、灵活等优点，但是基于定制接口的客户端的开发使用的是C／C＋＋语言，要求程序员掌握较深的COM／DCOM知识，开发难度较大，同时开发时间也会较长。自动化技术作为COM的一种特例或者说是一种应用，为一些弱类型的高级语言（比如Visual Basic，VBA等）提供了另一条使程序间相互通信的途径，而且这种通信方式非常直观，对双方都很友好。使用OPC自动化接口进行数据访问具有简单、易于编程、不需要开发者有相应的COM知识等优点，但是在程序的效率上存在不足。

图1 OPC架构图

2 OPC自动化接口性能测试

2.1 自动化接口对象

在架构上，OPC服务器共分为3层：OPC Server（服务器对象），OPC Gr oup（组对象），OPC Item（数据项）。OPC Server拥有服务器的所有信息，同时也是OPC Group的容器；OPC Group为OPC客户程序提供了一种用来组织数据的方法；OPC Item是服务器端定义的对象，通常指向设备的一个寄存器单元，OPC客户程序可以加入多个OPC Item到OPC Group。

OPC客户程序对设备寄存器的操作都是通过其数据项来完成的，通过OPC Item可以尽可能地隐藏设备的特殊信息，使OPC Server的通用性大大增强。OPC Item并不提供对外接口，客户不能直接对之进行操作，所有的操作都是通过OPC Group进行的。每个OPC Item的数据结构包含3个成员变量：数据值、数据质量和时间戳。

2.2 性能测试

测试环境为：PLC采用菲尼克斯的ILC 171 ET H 2TX，自动化接口封装库采用OPCDa Auto.dll，OPC Server采用菲尼克斯的AX OPC SERVER，该OPC服务器支持OPC标准功能和所有可选接口（符合OPC DA 1.0a和DA 2.04／2.05规范），可同时支持多个控制器，支持多种数据类型，开发语言选用C＃。

1）测试方案：在PLC连续地址上建立10 000个数据项，同时对10个数据项进行累加操作，PLC不进行其他数据采集及运算工作，尽量避免由于PLC性能原因对测试结果造成不利影响。使用Microsoft Visual St udio.NET 2012简体中文专业版开发一个简单的OPC Ite m读写操作程序，程序不进行其他操作。

2）测试结果：程序添加OPC Item到不同的OPC Group，当添加到约1 500个时，加入速度已明显变慢，加入每个标签的时间由开始的不到1 ms达到2 s。当数据项到达2 000时，加入每个标签的时间超过5 s。且随着数量的增加，时间越来越长，程序将变得很难响应其他操作命令。此时查看OPC Server上监视的10个累加数据项，发现数据依然在按PLC里边设定的频率变化，表明OPC Ser ver本身运行正常。

通过该测试可以确定，通过自动化接口，每个OPC客户端可正常监控的数据项有很大限制。

3 性能优化方案

对于一个约2 000 m的长隧道，控制及反馈数据项大约为1 000条；对于隧道群或特长隧道来说，数据项基本上都会超过2 000条，如果不进行优化，使用OPC自动化接口将很难正常监控。为解决这个问题，在开发隧道监控软件时，从系统架构、软件内部实现两方面入手进行优化。

3.1 系统架构优化方案

系统采用以服务总线为核心的分层架构，实现服务的注册、数据的订阅与分发等功能。其中客户端软件为用户提供界面以监视系统运行状况，同时提供外场设备控制、运营管理和应急处置的功能。服务总线软件是系统的核心，接收并处理数据订阅、服务注册命令，同时负责接收、汇集、转发系统实时数据、控制命令等。用OPC通信软件与OPC Server进行通信，采集设备数据并进行处理，随后发送给服务总线；同时，接收服务总线转发的控制命令，将该控制命令发送给OPC Server并返回控制结果。监控系统总体架构见图2。

3.1.1 分布式 OPC通信

系统采用分布式的OPC通信架构，根据不同设备的功能运用不同、用户要求不同、速率快慢要求不同、监控设备所处区域不同等情况，将单一的OPC应用程序拆分成多个OPC通信软件，每一个OPC通信软件掌管一种或几种设备的数据交换。OPC通信软件可以根据现场要求安装在不同的应用服务器上或同一台应用服务器上，采用多进程的运行模式，从而保证一种设备或一个区域的通信操作不会对其他设备或其他区域的通信产生影响，开发难度和维护难度大大降低。

在数据处理方面，传统的OPC应用程序往往是集原始数据获取、数据分析及界面展示功能于一体，这样虽然减少了中间环节出错的概率，但同时也加重了OPC应用程序的数据分析和处理的负担；而采用分布式处理方式，每个软件仅负责系统中的部分功能，所以更能够胜任数据的预处理和最终处理。

3.1.2 数据订阅

在服务总线软件内部建立所需数据的动态缓存，当数据发生变化时对动态缓存进行刷新，并发送给订阅了这些数据的客户端。这使得网络上的请求包数大大减少，并有效降低了对服务器的重复访问次数。在数据点很多的情况下，这种通信方式的优势更能凸现出来。此外，客户端还可通过数据订阅功能实现只订阅当前界面显示的数据，能够大大降低数据处理数量，提高界面响应速度。

3.1.3 服务注册

OPC通信软件根据加载的设备生成服务注册命令，通知服务总线自己管理哪些设备。注册成功后，当总线收到客户端软件发送的控制命令并查询服务注册表后，将命令发送给指定的OPC通信软件，由具体的OPC通信软件完成设备控制。

图2 监控系统总体架构

3.2 软件优化方案

主要针对OPC数据访问及隧道监控设备的特点，对OPC通信软件进行性能方面的优化。

3.2.1 OPC数据访问分析

OPC的数据访问方法有同步访问、异步访问和订阅式数据采集三种。

3.2.1.1 同步方式

OPC应用程序向OPC服务程序发出数据读取或写入请求后，在结果被返回之前必须处于等待状态。同步访问的特点为：读取指定OPC标签对应的过程数据时，应用程序要一直等到数据被读取完。写入指定OPC标签对应的过程数据时，应用程序要一直等待，直到数据被写入完成为止。当客户数据较少且同服务器交互的数据量比较少时可以采用这种方式，但是当网络堵塞或大量客户访问时会造成系统的性能、效率下降。

3.2.1.2 异步方式

OPC Server将读、写操作排队进行，使客户方的调用函数可立刻返回。当服务器读写操作完成后，主动触发OPC应用程序的异步访问完成事件，将数据访问结果传送给OPC应用程序。OPC应用程序在其事件处理程序中接收从OPC Server传来的数据。其特点为：异步方式不会阻塞OPC应用程序的执行，可提高OPC应用程序的效率。

3.2.1.3 订阅式数据的获取

OPC客户应用程序向OPC Server订阅相关数据后，Ser ver周期性地扫描缓冲区的数据，如果发现数据变化超过OPC应用程序设置的幅度，更新数据缓冲器，并通知OPC应用程序。订阅式数据采集方式实际上也属于异步读取方式的一种。OPC Ser ver支持不敏感带（Dead Band），当OPC标签的数据类型是模拟量时，只有变化幅度超过设置的限度才更新缓冲器数据，并通知OPC应用程序。由此可以忽略模拟值的微小变化，减轻OPC Server和OPC应用程序的负荷。其特点为：Server用一定的周期检查过程数据，当发现数字数据变化或模拟数据的变化范围超过设定值时，立刻通知客户程序，传递相应信息。该方式可有效降低对服务器的重复访问次数，同时也可提高OPC客户应用程序的响应速度。

3.2.2 软件实现

通过对OPC数据获取方式进行分析可知，隧道监控实时性要求高，数据获取应尽量采用数据订阅的方式，这样可以降低OPC客户应用程序对OPC Ser ver的访问次数，避免过多的数据访问对OPC Ser ver性能产生影响，同时也可以提高OPC客户应用程序的性能。隧道监控系统中，大部分设备的控制信号和反馈信号是分开的，如风机、车道指示灯、交通信号灯等，每一个信号都对应一个OPC Item。当需要控制某个设备时，可通过将值写入控制信号对应的OPC Item来实现，是否控制成功及当前设备所处的运行状态如何，则通过读取反馈信号对应的OPC Item的值来确定。同时，由于多客户控制问题，OPC客户应用程序不知道设备的运行状态何时发生变化。因此，将设备控制信号与反馈信号对应的OPC Item放入不同的OPC Group中，反馈信号所在的OPC Gr oup采用订阅方式获取数据（OPC Gr oup的Is Subscribed属性置为Tr ue）。

根据分析，采用OPC异步方式写入数据不会防碍OPC客户应用程序的执行，但对于自动化接口，如果采用异步方式读取、写入指定OPC Item数据，OPC Item所在OPC Gr oup的Is Subscribed必须置为Tr ue，也就是说必须采用订阅方式。如果这样，当控制变量发生变化时，会触发对委托函数的调用，在隧道监控系统中这根本是没有必要的，反而会大大降低程序的性能。因此，OPC客户应用程序采用多线程同步方式发送控制命令。这样在同一个过程中就可以得知控制命令是否成功写入OPC服务器。

4 结 语

使用OPC自动化接口进行数据访问具有简单、易于编程、不需要开发者有相应的COM知识等优点，但是传统系统架构在程序效率上存在严重不足。测试显示，当数据项达到2 000条时，监控效率将大大降低，数据项越多，效率越低。为解决这个问题，提出了分布式的软件系统架构，避免单个OPC应用程序监控数据项过多的问题。同时，针对隧道监控的特点，尽量采用订阅方式访问OPC Server，避免多个OPC应用程序定时访问OPC Ser ver对OPC Server的性能产生影响。优化后的软件在昆明绕城高速公路西北段隧道群监控系统（数据项大约5 000条）中得到了应用，控制车道指示器等设备的反馈时间约为1 s，取得了良好的优化效果。

［1］ 赵键.楼宇监控系统中的OPC客户端与服务器应用程序设计［D］.电子科技大学，2009.

［2］ 毛晓羽.OPC技术在数据采集与智能监控系统中的研究与应用［D］.武汉理工大学，2012.

［3］ OPC Task Force.OPC Co mmon Definitions and Interfaces（Vcrsion 1.0）［S］.Opc Co mn.doc，1998.

［4］ OPC Foundation.Data Access Custo m Interface Standard Specification 2.O［s］，1998.

［5］ OPC Foundation.Data Access Auto mation Interface Standar d（Version 2.02）［S］.Opcda20＿auto mdoc，1999.