1、泵站远程监测系统是基于在线自动测量技术0泵站远程监测系统是基于在线自动测量技术1现状与建设难点目前对于独立的泵站，建设一套计算机监控系统实现现场的监控，已经有非常成熟的解决方案，相关的工程案例也非常多，而通过建设远程计算机网络，实现异地的监控，也有非常多的成功案例。这些解决方案，大多基于现地的PLC+传输设备（工业总线，局域网）+上位机（组态软件）的方式实现，优点是监测范围广，实时性好，但缺点是造价高，需要传输设备支持。当存在大量的中小泵站需要进行运行监测时，其投入的成本和对基础设施（计算机网）的要求非常高，几乎无法实施。2解决方案2.1体系架构本文所设计的泵站远程监测系统是基于在线自动测量技
2、术，计算机技术以及相关的专用监测软件和通讯网络所组成的一个综合性的在线自动监测，统计，处理系统。它相对于普通的计算机自动控制系统来说，最典型的区别在于：是基于”有人看护值班，信息自动监测传输”要求进行的系统设计，保留日常运行管理人员，实现泵站状态的自动传输和统一显示，因此，应该具备以下几个条件。2.1.1具有独立的监控功能在分层分布式泵站远程自动监测中，按照监测对象的分布进行设置，每个监测模块作为一个设备单元，可以利用通信通道连接到资源共享的网络上实现分散控制。根据IEEE对分布式系统的要求，各现地单元应具备自治性，模块性和并行性。2.1.2具有传输能力既然要实现泵站运行信息的自动传输，系统不
3、仅应该具备现地的各种监测功能，更主要必须保证与远方监测中心进行数据交换，上传有关信息。对于本项目来说，必须选择一套覆盖面广，建设成本和运营费用低，维护量小的信息传输网络。2.1.3统一的运行监测平台有别于常规的泵站计算机监测系统，本系统的监测对象主要是大量中小型泵站，同时还包括已建成的一些有计算机监控系统的大型泵站。需要利用计算机软件技术，在尽可能简洁的显示界面下，显示尽可能多的泵站信息，可以和其他防汛指挥软件实现整合和数据共享，因此要求在监测软件的开发中，脱离通常的组态软件开发模式，采用更通用化的开发语言例如：VB，C，C+等。经过上面的分析，可以看出，是一个包含现地监测，通讯网络，中心软件
4、的多层架构。2.2现地监测现地监测的功能主要是用于将传感设备监测到的信号量采集并传输到监控中心的设备，包括监测各运行状态的仪器仪表和监测主机组成。由于各泵站均已实现电气化，对于泵站的启停观测，直接通过现地控制柜中的交流接触器即可获得；对于需要监测的如电流，电压等参数，通过新添加的仪器仪表也可以取得，这些观测仪器仪表市场上均有成熟的产品，均为常用的自动监测设备，安装调试也和普通的泵站计算机监控系统相同，在此不一一赘述。与通常的泵站计算机监控系统相比，本系统的最大区别在于现场没有采用PLC+上位机的结构，而是采用了集成化的测控终端，与普通的PLC相比，该种测控终端价格更低，集成度更高，并且集成了数
5、据传输模块，可以直接进行数据发送，相当于整合了部分上位机的功能，缺点是可以接入的仪表数量和控制功能相对简单；但对于本系统的监测对象来说，已经能够满足每个泵站所需报送的状态信息，以本项目中使用最多的测控终端WNC2000为例：它支持模拟量（420mA）10个，开关量20个，当接入点数量增加时，还可以通过加入扩展模块进行扩展，相对于传统的PLC+模拟量模块+开关量模块+通讯模块来说，这种测控终端价格低（设备价格仅相当于1个中档PLC的CPU模块），集成度高（整合了通讯模块），安装部署方便（设备体积仅相当于一般的MODEL），因此对于监测的信息量不大的情况下，采用这种一体化监测终端是现有条件下的最佳
6、选择。同时通过SD卡可以实现信息存储功能，能够在通讯中断时自动记录采集的信号量，以备通讯恢复时将监测信号重新发送至监测中心。2.3通讯信道的选择通信系统是监测站网建设工程信息采集子系统的信息传输基础，它的优劣直接影响系统信息及时，准确向中心站汇集。如何准确，及时地将信息传递到中心是本系统设计的关键环节，考虑到工程造价和运营费用，较为可行的方案是采用公网的传输方案，目前能够覆盖大部分泵站的公网传输方式主要有以下几种。2.3.1ADSL利用电话信道，带宽较大，但这种传输方式是一种非对称的传输模式，下载带宽（网页浏览）远大于上传带宽（监测数据传输），难以满足数据传输的需要，而且其覆盖范围和实际带宽效
7、果依赖与接入点与主光纤的距离，难以覆盖大部分泵站。2.3.2GPRSCDMA利用移动联通的无线手机网络，覆盖面较广，能够覆盖大多数泵站，能够提供点到点的实时数据连接；GPRS的峰值速率为11512kbits；CDMA1X系统的峰值速率为15316 kbits，但从实际测试的结果看，GPRS在本地覆盖范围更广，而且实际测试的有效带宽更大；因此在系统建设中，采用了GPRS通信方式发送系统数据，其优势表现如下。（1）实时性强。GPRS网络具有永远在线的特点，只要设备打开在13s内就可以登陆到核心网络，数据时延在7003000ms之内。（2）稳定性好，覆盖好。GPRS网络是在GSM网络上加载的分组交换
8、网，核心设备在移动公司机房，在信号较弱的地方可以自动切换编码方式，增加冗余码保证数据的传输，基本上在移动手机有信号的地方都可以使用GPRS网络，覆盖面广。（3）价格低。由于GPRS网络按照流量收费，在数据传输量不是很大并终端特别多的情况下还可以按照APN接入点的流量收费，整体网络运营费用较低。2.4集中监测软件的架构解决了现场参数的采集和传输问题，在监控中心，就需要开发1套监测软件来显示这些实时采集到运行信息；通常的处理方法有两种：一种是数据接收软件+数据库+显示界面；另一种是利用测控终端自带的组态软件，直接显示监测数据，同时利用组态的数据库功能，在数据库中定时写入监测记录。这两种方案均是普遍
9、采用的常规方案，软件开发难度低，但均有不足之处，主要表现如下。（1）采用数据接收软件+数据库+显示界面的方式。在水资源计量，用电远程抄表系统中应用较多，监测数据通过数据接收软件接收后直接写入数据库，显示界面的开发通常可以使用通用的软件开发语言，可以很方便的与其他指挥系统相连，但采集到的数据经过的流程长，实时性低；在常规的编程方式下，显示的只是用户打开这个页面时数据库中的最新数据，实时运行信息则无法自动更新示到界面，无法达到运行状态的动态显示；虽然在程序开发中可以添加诸如定时刷新页面的功能，但又会出现刷新间隔和系统资源占用的矛盾，很难达到实用性和实时性的平衡。（2）利用测控终端自带的组态软件，系
10、统监测数据直接显示在自带的组态程序中，数据一旦接收，即显示在组态界面上，实时性高，但缺点是受组态软件本身制约，很难与其他系统融合，界面中只能显示当前系统数据，在本项目中，其他利用专网进行监测的水利工程监测的实时信息无法整合到一起，很难加入其它功能，功能局限性大，扩展困难。因此，在本项目监测软件的开发中，笔者进行调研，决定采用一种不同于以往的架构模式：通用工业控制协议OPC+通用开发语言，既满足了系统的实时性要求，又保证系统的扩展性。OPC（用于过程控制的OLE）作为一个工业标准，它由一些世界上占领先地位的自动化系统和硬件，软件公司与微软（Microsoft）紧密合作而建立的，这个标准定义了应用
11、Microsoft操作系统在基于PC的客户机之间交换自动化实时数据的方法，取代了原来的DDE，可以作为一个组件加入到1net的开发环境中。通过这个开发环境，可以在编程过程中将远程变量在软件界面上进行实时显示，同时1net的强大开发能力，可以整合其他业务系统，实现监测系统与业务系统的无缝连接。（1）建立无线测控终端的OPC服务器，无线测控系统采集到的数据通过架设在中心的OPC服务器进行发布。（2）对于已建成通过PLC方式实现的其它自动控制系统，通过PLC或组态软件自带的OPC功能实现OPC服务，利用PLC或组态软件中自带的OPC服务功能，可以在软件开发中实时访问其中的变量，实现了泵站无线监测系统
12、与其他计算机自动控制系统的融合。（3）开发的监测软件通过添加OPC组件，可以访问上述OPC服务器中的所有变量信息，利用1net的强大功能，可以对这些OPC服务器发布的状态变量进行任意组合，整合到业务系统中。2.5与GIS的整合信息技术的发展，特别是软件技术的发展，使得监测系统软件在建设中，不但仅仅考虑数据的正确显示，同时对软件界面和显示方式的要求也越来越高，但在监测系统领域，往往仍停留在以表格形式显示数据的层次，这一方面在于组态软件的扩展性较低，不能支持更加活泼的显示模式，另一方面在于这些监测系统通常应用的领域对于监测点位置信息要求不高，用户通常对于数据的关注度远远大于对空间属性的关注；但对于
13、本系统来说，系统所面向的指挥决策人员往往不仅仅关注每个泵站实时的运行状态，同时也要关注这些泵站所处的位置以及周边的社会经济和地形地貌，因此，在显示运行状态的同时表现泵站的地理位置和地形地貌，也是本系统软件开发工作的一项重大任务。综合软件开发的难度，显示效果和平台购置的成本，本项目采用了外购的地理信息系统开发平台，通过在1net开发环境中加入地理信息系统库，可以在软件界面中插入本地区的电子地图，相关的河流，湖泊，地形地貌等都可以作为独立的图层加入，通过开发图层控制功能用户在浏览时可以选择打开关闭相应图层，查找自己感兴趣的目标，同时在地图中还将本项目监测的各个泵站作为独立图层加入到地图中。通过编程
14、，用户可以在显示的地图中点击某个泵站，就可以将选中的泵站突出显示，并标记其运行状态，要查看详细信息时，也可以通过界面选择，以表单形式显示泵站的详细信息。3总结与展望本系统目前已经实际投入运行，从目前的情况看，运行比较正常，采用的硬件设备运行稳定，没有发生异常；软件系统也具备了比较高的稳定性，用户使用的反响也较好，但也有部分不足之处。（1）基于OPC接口的监测中心软件开发经验不足，对于变量和接口的定义未能在设计之初进行统一规划，各变量和接口的定义在软件编程过程中多次扩充，修改，命名不够规范，后期扩展的成本较高，希望能在今后的项目中引起重视，在设计之初即对所有的监测项目和变量进行统一设计，规范命名。（2）由于先期实施的部分项目选择的电器仪器仪表没有按照相关的规范要求选型和施工，辅助接点少，在现场很难取到需要监测的信号，需要改装或更换，造成了浪费；在今后的类似项目的设计和施工中，要注意在选择相关设备时，充分考虑今后的自动化接口是否完备，预留扩展空间。（3）由于软件需求调研不够充分，或者要求不够明确，不能形成统一的报表，只能在开发过程中随时添加和修改，而且报表样式不够活泼，需要进一步扩展。
