系统信息数据集中监测

系统信息数据集中监测（精选8篇）

系统信息数据集中监测 篇1

摘 要：铁路信号集中监测系统目前在铁路有着广泛的应用，它已经成为每个站必须配备的辅助信号设备，由于其技术的逐步成熟，行业标准的逐步完善，是一套电务职工日常维修设备的必要辅助系统。

关键词：信号集中监测；隐患排查；故障分析

中图分类号：TN911 文献标识码：A

铁路电务信号集中监测系统是电务部门运用越来越广泛的一个设备维护辅助系统。随着铁路维修制度的逐步改变，设备维修只能在天窗点内进行，由于维修天窗点时间的不足、日常又不能进行开盖检查设备，所以很难保证设备的良好运行。近年来随着系统中设备监测项目的逐步增加，通过运用系统实时监测的特点，可以发现大量的信号设备安全隐患，为信号设备实现状态维修提供了可靠的数据依据。信号工可以利用监测系统提前发现设备问题，做到有针对性地重点检修设备，最大化地利用有限的天窗时间。下面通过现场的实际运用分析来讲解一下系统的多方面运用方法。

一、利用监测系统发现道岔设备安全隐患

目前的信号集中监测系统对道岔设备主要采集的数据有动作电流数值、动作功率数值、定位表示交流电压数值、反位表示交流电压数值、定位表示直流电压数值和反位表示直流电压数值。通过各种数据的横向对比，可以发现道岔不同部位发生的不同问题。利用道岔动作电流曲线发现配线错误问题

2015年曹妃甸西站因站改需要对站内电缆进行割接，割接电缆后，施工人员对各类设备进行了单项连锁试验，连锁关系全部正确。但在电缆割接后，职工日常巡视微机监测发现11#、13#道岔动作电流曲线偶尔发生异常。通过对所有道岔曲线进行对比综合分析后，发现只有11#、13#道岔同时扳动时、两组道岔的电流曲线均异常。

车间人员查看电缆割接前道岔的电流曲线，11#、13#道岔同时扳动时，各相电流曲线均正常，动作电流在1A左右。查看电缆割接后道岔的电流曲线，发现4月27日18点04分35秒扳动13#道岔，A相电流超标、动作电流在4A左右、持续时间约26秒；B相电流升高、动作电流在1.5A左右；C相电流升高、动作电流在1.2A左右。4月27日18点04分43秒扳动11#道岔，A相电流降低、动作电流在0.5A左右；B相电流升高、动作电流在1.5A左右；C相电流超标、动作电流在3.7A左右、持续时间约26秒。由于两组道岔的控制电缆在同一根电缆中，初步分析怀疑电缆是否有接地短路点。由于道岔站场位置离机械室比较远，道岔的控制电缆采用的是双芯并用，车间利用天窗点对两组道岔的控制电缆进行了绝缘对地摇测，未发现有电缆绝缘不良问题。车间又分别对两组道岔电缆甩线进行通断核对试验，发现11#道岔的X5与13#道岔的X1有一芯电缆交叉上错。对错误配线进行倒接后，再同时操纵两组道岔，道岔的动作电流曲线恢复正常。利用道岔表示电压曲线发现设备性能不良问题

2016年2月18日涿鹿车间通过微机监测发现涿鹿站5#道岔定、反位直流表示电压由21V降为约16V。对道岔的表示电路进行分析认为定反位表示电路的公共部分存在问题，公共部分中怀疑点最大的就是表示二极管性能不良，天窗点中对5#道岔的表示二极管进行更换后表示电压全部恢复正常。对更换下的表示二极管进行测试发现表示二极管两个并联使用的陶瓷电阻有一个存在内部断线问题。

总之，我们日常通过分析道岔的各种监测曲线，可以发现不同类型的设备安全隐患。通过动作功率曲线可以发现道岔解锁困难、中途转换卡阻、尖轨入槽困难、道岔表示缺口不适等问题。当道岔扳动时，动作功率曲线升高后一直不回落，可以判断为道岔解锁困难，道岔无法进行转换，通过现场查找杆件是否有卡阻进行处理。当道岔扳动转换途中，动作功率曲线有突然的升高或者小毛刺等现象时，可以判断为转换途中有卡阻的地方，一般情况是滑床板缺油或者杆件在转换途中有异物磨卡。当道岔在即将转换到位时，动作功率曲线有突然的升高现象，可以判断为尖轨入槽不顺，一般情况是基本轨有肥边或者尖轨有吊板问题，此种情况需及时联系工务部门进行病害整治，才能彻底解决此类问题。利用道岔表示电压曲线可以发现表示二极管性能不良、道岔动静接点虚接、表示回路电缆虚接等问题。当道岔表示电压曲线下降了一定数值后保持平稳，可以判定为道岔表示二极管性能不良，及时进行更换即可解决此类问题。当道岔表示电压曲线存在细微波动时，可以判断为表示接点虚接或者回路中有电缆虚接部位，此类问题需要进行现场检查，逐步进行排除处理。

二、利用监测系统发现ZPW-2000A轨道电路设备安全隐患

目前的信号集中监测系统对ZPW-2000A轨道电路设备主要采集的数据有功出电压、功出电流、主轨入电压、主轨出电压、小轨入电压、小轨出电压、送端分线盘电压、受端分线盘电压。可以通过各项数值的综合分析判断为室内、室外设备问题。利用受端电压发现室外设备短路问题

2015年3月30日大同南区间0144G主轨出电压波动达60MV～70MV，通过查看送端分线盘电压、受端分线盘电压判断为室外问题，首先怀疑是轨道区段内的补偿电容有性能不良的，或者是送受端调谐线存在虚接问题。车间人员到达现场对调谐线及补偿电容进行了细致的检查，没有发现明显的问题。继而车间重新对线路进行了检查，发现线路外侧有工务部门新卸的一小段钢轨，钢轨正好放在了几根地锚拉杆上部，经过初步分析是新卸的备轨短路地锚拉杆，形成第三轨道通路，造成了轨道区段的电压波动，如图1所示。

分析原因：ZPW-2000A轨道区段中有均匀分布的补偿电容，对轨道上传输的轨道电压起到补偿作用，以便实现轨道信号的长距离传输。如图所示新卸的钢轨放在了线路的外侧，刚好放在了地锚拉杆绝缘与钢轨的中间，中间这一部分拉杆是没有绝缘性能的，当新轨分别与第一个和第三个地锚拉杆短路时，相当于形成了第三条轨道通路，中间会有3个补偿电容被短路掉，不再起到补偿作用。由于短路点没有形成死短路，所以在监测系统中主轨出电压表现为波动的形态。此种设备隐患很容易同调谐线虚接、补偿电容虚接问题混淆，需要现场进行实地检查判断。利用各项监测数据快速判断故障点

2016年4月6日，铁炉村中继站至下庄区间2960G红光带，由于大秦线上有很多长大区间，交通不便，所以当区间发生设备故障时，首先需要通过监测系统的各项参数值判断区分室内外问题。这样可以压缩很大一部分故障处理时间，减少故障给行车带来的损失。上述故障发生时，通过微机监测查看2960G分为3个轨道区段，2960AG功出电流正常、主轨出电压正常；2960BG、2960CG的功出电流为零、主轨出电压为零；可以判断问题在2960AG处。进一步查找分析，2960AG处在区间分界处，它的主轨接收设备在下庄站，它的小轨接收设备在铁炉村中继站，通过查看中继站2960AG的小轨出电压是正常的，可以判定为小轨站联条件没有送出的问题。车间人员分别赶到下庄和铁炉村中继站机械室查找，发现是站联电缆的问题，找到提前核对好的备用电缆进行倒接，倒接后故障恢复。

我们日常利用信号集中监测系统可以对电源屏、信号机、轨道电路、道岔等信号设备进行实时监控，动态的发现设备使用情况，对于一些无法人工发现的设备隐患，可以通过监测系统进行综合分析判断。同时可以为电务人员提供大数据支持，电务人员利用监测系统对信号设备电气特性进行日、月、年的动态分析，通过分析设备使用状态做到有针对性的周期维护，减少了一大部分设备故障。作为铁路信号系统的新设备新技术，熟练使用信号集中监测系统是每一名电务人员必备的业务知识，合格的信号工必须能够利用监测系统发现设备安全隐患和快速判断设备故障部位。

参考文献

系统信息数据集中监测 篇2

某大型国有企业附属水厂, 在全公司近十平方公里的范围内, 设有给水、污水处理和循环水等装置, 包括取水、制水、中水回用、循环水、污水处理、污水提升泵站、外供用水单位等数十个岗位及若干关口计量点。各计量点分散、距离远, 且在生产管理上相互关联、相互影响, 如果能实现各各计量点数据共享和集中监测, 将大大有利于生产调度, 降低管理控制难度, 确保生产安全稳定, 提高装置和厂级的管理水平。本文就是以此为背景做的数据集中监测系统。

1 GPRS技术介绍

GPRS通用无线分组业务, 是一种基于GSM系统的无线分组交换技术, 提供端到端的、广域的无线IP连接。GPRS充分利用共享无线信道, 实现数据终端的高速、远程接入。GPRS无线数据采集, 可充分利用现有的中国移动网络资源, 建设成本低、网络覆盖范围广、数据传输率高、永远在线实时性好、通信费用低等特点, 在远程突发性数据实时传输中有不可比拟的优势, 特别适合于频发小数据量的实时传输。因此, 在本系统中采用GPRS技术是非常合适的。

2 集中监测系统网络架构介绍

本系统首先利用GPRS无线通信技术, 对分散的计量监测点数据采集传输到带有GPRS通信程序的中心DCS系统 (和利时) ;然后在中心DCS系统中绘制成流程图画面进行WEB发布。

通过GPRS和Internet平台, 构成一条无线的数据传送通道, 将现场计量表计的RS485信号 (如果表计没有RS485输出, 则将仪表的4~20m A输出信号接入8通道的研华4017模拟量采集模块, 转换成RS485信号) 接入深圳宏电的H7710 DTU, 借助中国移动网络进行数据通信, 传入中心DCS系统。

中心DCS服务器装有Smart Pro3.1.3组态软件及定制开发的研华4017GPRS通信程序, GPRS传输过来的数据可以通过Smart Pro3.1.3组态软件流程图画面显示。同时, 中心DCS服务器安装HOLLi AS RMIS系统, 通过HOLLi AS RMIS进行WEB发布, 实现企业管理网与DCS控制系统的无缝连接。架构图如图1。

3 GPRS无线数据通信的实现

3.1 监测点数据采集终端硬件配置

数据采集终端硬件及其功能:

(1) 8通道的研华4017模拟量采集模块的作用是把4~20m A信号转换成RS485信号。

(2) 深圳宏电H7710 DTU作用是将RS485串口数据转换为IP数据, 并无线传送。

(3) 24V直流电源模块:为研华4017及宏电H7710 DTU供电。

3.2 研华4017模拟量采集模块的配置

通过RS-232/485转换器, 将4017模块RS485信号接入PC机串口, 给4017模块接上电源, 在PC机上运行ADAM-4000-5000Utility程序。

研华4017模块配置步骤如下:

(1) Address中本监测点的研华4017的实际地址;

(2) Baud Rate设为9600bps (与DTU一致) ;

(4) 点击“Update”按钮;

(5) 为节省传输流量, 仅将使用的CH0、CH1、CH2、CH3四个通道打上勾;

(6) 点击“Update”, 再点击“Refresh”, 即完成配置。

4 OPC数据通信的实现

4.1 Smart Pro系统OPC Server通信软件应用

本软件遵循OPC DA 1.0、2.0标准, 适用于Smart Pro3.1.3软件系统, 可以与支持OPC Client的第三方应用系统交换数据。

4.2 HOLLi AS RMIS软件应用

选择开始->所有程序->RMIS->服务管理器, 打开所示的服务管理器。在HOLLi AS RMIS系统管理器中进行组态, 将需要发布的计量点添加到系统管理器中, 并进行流程图组态。

5 计量数据集中监测的实现

通过HOLLi AS RMIS系统, 将水厂计量点的主参数表、流程图画面等以WEB方式发布, 全公司局域网内的任意一台PC机经过相关设置后, 即可访问中心DCS系统HOLLi AS RMIS软件发布的WEB网页, 浏览到水厂计量点的实时和历史数据。

6 结束语

系统信息数据集中监测 篇3

摘要：论述了一种适用于处理海量监测数据的结构性态监测信息管理系统（MIMS）的设计方案.基于三层浏览器/服务器架构搭建软件系统，利用多服务器协同工作机制提升系统性能.应用大数据技术，充分考虑海量监测数据对数据管理系统的高要求，选用MongoDB数据库作为数据管理平台，论述了数据库结构和采用的数据格式.最后以宁波南站结构性态监测为例，展示了系统的实现效果.结果表明该系统具有很好的扩展性和通用性，每天可接收远程数据约10 GB，能实现对海量监测数据的实时吞吐和高效组织管理.

关键词：结构性态监测；大数据；MongoDB数据库；多服务器协作；浏览器/服务器

中图分类号：TP274文献标识码：A

土木工程领域的结构健康监测研究始于上世纪70年代末.目前，对结构健康监测技术的研究大多集中在传感网络子系统设计及损伤识别和安全预警等方面.在结构性态监测软件的开发方面，近几年也出现了一些技术创新和实践成果，如土石坝安全监测软件[1]、桥梁结构健康监测系统软件[2]和上海中心大厦结构健康监测软件[3]等.但这些软件基本上都是针对特定结构开发，系统的可移植性、可维护性和可扩展性表现较差.在监测数据的组织管理方面，已有的结构性态监测软件大多是从海量的监测数据中获取有效的关键数据形成数据报告，不能实现全部监测数据的实时吞吐，并且存在数据采集与存储不同步的问题.

随着物联网、云计算和社交网络等新兴技术与服务的出现，数据类型和数据量正以惊人的速度扩张，如何更好地管理和利用大数据开始备受关注[4-6].在结构健康监测中应用大数据技术，对实时监测数据流进行统计分析，可以预测出数据发展的趋势，从而实现系统对结构损伤的识别、诊断和预测.达到这一目的的关键在于实现监测数据的实时吞吐和高效组织管理.由于土木工程结构健康监测与物联网的融合以前所未有的速度生成数据，这些数据即使经过过滤，只保留有效的数据，其数据量也是惊人的庞大.如何实现对海量监测数据的组织、存储、查询和分析，既是实现对结构全寿命周期跟踪式在线监测的前提，也是对结构进行有效的损伤识别和安全评定的基础.

针对以上问题，本文提出一种大数据技术下的结构性态监测信息管理系统（MIMS）设计方案.该方案以实现高效的数据管理和安全的数据共享为目的，实现监测数据实时或近实时的、动态的、数字化、网络化和可视化的管理.系统已应用于多个大型项目的结构健康监测，如宁波南站、上海中心大厦、兰州西站和上海世博轴阳光谷等.

1系统架构

目前，基于网络化的监测软件实现模式主要有两种方式，一种为客户机/服务器（Client/Server， C/S）模式，另一种为浏览器/服务器（Browser/Server， B/S）模式[7].

B/S模式是Web2.0兴起后的一种网络结构模式，该模式由服务器安装数据库和Web应用，承担系统的核心功能；客户机安装浏览器作为客户端，浏览器通过服务器端的Web应用间接同数据库进行数据交互.这一模式解决了传统C/S模式中专用客户端软件开发成本高，升级维护困难等问题（见图1）.

该体系结构具有以下优点：

1）广域网/局域网都可使用，对客户端软硬件环境要求不高，只要有操作系统和浏览器即可；

2）各层在逻辑上相对独立，具有很好的灵活性、可重用性和可扩展性；

3）系统功能集中在服务器端，可随时进行更换或更新，从而实现无缝升级，降低系统维护成本；

4）可添加用户管理机制，利用业务逻辑层阻止未授权用户访问数据层，实现数据的安全管理；

5）浏览器即客户端，一方面可降低开发难度和成本，另一方面可充分利用页面制作技术与用户进行更加生动和丰富的交流.

2系统功能实现

2.1服务器软件

MIMS的功能主要包括数据的采集与接收、过滤与转换以及处理与查询，如图2所示.系统核心功能集中在服务器端.考虑到各功能环节对服务器有各自不同的要求，且具有不同步性，因此将各个功能模块设计成相互独立的服务器软件.

MIMS的运行模式是以系统的自动运行为主，一旦服务器软件或硬件出现故障，系统的运行将终止，如果不被及时发现并加以维护将会造成不可预计的数据损失乃至工程损失.因此，MIMS设计有独立的自检服务器软件，以实时监视服务程序，当有异常状态发生时，以邮件和短信的方式通知相关技术人员.

2.2多服务器协同机制

MIMS采用多服务器协同机制对服务器进行管理.Internet的快速增长要求服务器具备提供大量并发访问服务的能力，因此对于大负载的服务器来讲，CPU，I/O处理能力成为瓶颈[8].通过提高硬件性能来提高单台服务器性能的效果有限，而采用多服务器协同工作机制和负载均衡技术可以很好地应对大量并发访问的情况.

MIMS中的各功能模块被设计成独立的服务器软件，这些软件可以在单台服务器上运行，但效率较低.为提高运算效率，可以采用多服务器协同系统来均衡服务器负荷，将各服务器软件设计在不同服务器中，并形成相互协作机制.如图3所示，服务器1负责将传感器网络传来的数据进行采集并存储于数据库；服务器2首先实现和服务器1的数据库同步，然后对这些数据进行过滤、筛选和转换并存储于另一个数据库中；服务器3同步已经过转换的数据，再根据客户浏览器通过Web服务器提交的指令对数据进行分析和处理.各服务器通过数据库的管控进行数据同步，以C/S模式相互访问，实现相互调用和协同工作.

3数据管理方案

3.1数据库

结构健康监测系统对数据库的要求非常高.已有的较为成熟的结构健康监测系统大都采用文件形式存储数据，也有一部分采用关系型数据库对监测数据进行管理.采用文件形式显然不能实现数据的实时存储与查询，且组织管理效率非常低，而关系型数据库的应用也受到诸多限制，一般只能实现对部分关键数据的存取，不能实现对海量监测数据的实时吞吐.目前，监测系统正在向网络化发展且监测数据的规模也在不断扩大，监测系统对数据库的要求越来越高.对海量监测数据的高效率存储访问以及对数据库的高并发读写和高可扩展性等要求已经成为传统的关系型数据库无法应对的难题[9-10].

近年来，随着大数据时代的到来，NoSql（Not Only SQL）数据库得到了迅速的发展， NoSql数据库具有传统关系型数据库无法比拟的高并发、高效率和高可扩展等特性，其中MongoDB数据库的表现尤为突出[11-12].MIMS采用高性能、易部署、易使用且存储数据方便的MongoDB数据库对监测数据进行管理，实现了对海量监测数据的实时吞吐和高效存储与查询.

3.2数据格式

3.2.1数据存储格式

这里的数据存储格式是指数据保存在数据库或文件中的编排格式.其应满足一定条件：1）保证记录所需要的全部信息；2）充分利用存贮空间，提高存贮效率；3）采用统一的格式，方便与数据处理模块间的数据交换.MongoDB使用BSON（Binary Serialized Document Format）结构来存储数据，可以满足以上要求.BSON是一个轻量级的二进制数据格式，可以存储内嵌的文档对象和数组对象.MIMS采用以BSON格式存储的文档对象存储信息，其中每条记录包括测量点位（position）、传感器类型（dimTyp）、测量批次（batch）、测量时间（datetime）和测量值（value），示例如下：

{″position″：″SWGJ12″，″dimTyp″：″stress″，″batch″：null，″datetime″：newDate（2014，4，6，16，12，9），″value″：-23.396}.

3.2.2数据交换格式

为了整合资源，建立统一的信息化平台，MIMS中的数据交换采用统一的标准数据格式.格式标准化可以极大地提高对数据的管理效率，让用户快速简单地得到必要的数据.

当前比较流行的数据交换格式有XML（Extensible Markup Language），JSON（JavaScript Object Notation）和YAML（Yet Another Markup Language）.由于数据存储格式已选用是类似JSON的BSON格式，为了方便与数据库的数据交互，MIMS数据交换格式选用JSON格式.JSON 是一种轻量级的数据交换格式，易于阅读和编写，同时也易于机器解析和生成，可以满足本设计对数据格式的要求.

JSON简单说就是JavaScript中的对象和数组，对象数据结构为 {键：值， 键：值，…}，键为对象的属性，值为对应的属性值，属性值的类型又可以是数字、字符串、逻辑值、数组或对象.数组数据结构为 [字段1， 字段2， 字段3，…]，其中字段值的类型又可以是数字、字符串、逻辑值、数组或对象.利用对象、数组两种结构可以组合成多层嵌套的数据结构，如以下示例，最外层是包含″Stresses″和″Temperatures″两个属性的对象，他们的属性值又嵌套了多个子对象的数组.

{

″Stresses″： [

{″position″：″SWGJ11″，″value″：[-23.396， -23.63， -24.352 …]}，

{″position″：″SWGJ12″，″value″：[-24.153， -24.953， -23.303 …]}，

…

] ，

″Temperatures″： [

{″position″：″SWGJ11″，″value″：[31.1， 30.5， 31.9 …]}，

{″position″：″SWGJ12″，″value″：[29.3， 30.2， 32.3 …]}，

…

]

}.

4 应用实例—宁波南站结构性态监测系统

4.1工程结构概况

宁波南站站房采用南北地上进站、高架候车、地下出站的功能格局.新建站房共3个主要层面：地下一层（主要负担进出站功能）、站台层（地面层）和高架层（含商业夹层）.地下二层（地铁2号线站厅层）和地下三层（地铁2的站台层）的土建工程大部分位于铁路站房下，详见图4.高架层东西向总长度114.0 m：该方向柱距不均匀，为24+21+24+21+24 m；南北向总宽度185.5 m，柱距为25+2×21.5+43+2×21.5+31.5 m. 地下一层、站台层东西向总长度66.0 m（柱距为21 m及24 m），南北向宽度185.5 m.

本工程的监测内容主要包括：1）施工和运营过程中钢结构关键部位的应力监测；2）运营过程中结构关键部位的振动加速度响应监测；3）运营过程中风敏感部位的风压监测；4）运营过程中整体结构所处风环境的风速监测.

4.2系统配置

宁波南站结构性态监测系统包含静态（应力应变）采集通道167个，动态（风速风向、风压力和加速度）采集通道87个.采用单台服务器配置即可满足性能要求.

服务器配置：2路处理器，每路采用主频1 800 MHz，L3缓存10 MB的4核心4进程处理器；安装内存为8.00 G；3块3TB硬盘作为RAID5.

数据库配置：采用MongoDB主从模式配置为采集端数据库（主）和分析端数据库（从）.

网络传输配置：采集现场局域网带宽100 M，VPN远程传输带宽为3 M.

4.3系统展示

宁波南站结构性态监测系统功能包括首页、系统说明、系统管理、设备总览、实时监测和监测回放.首页包括登录、项目概述和监测分项简介，系统说明包括项目功能说明和监测点位详细说明，系统管理包括密码管理、角色管理和用户管理.设备总览画面如图5所示，包括监测设备的最新运行状态统计和测点设备的详细状态表，共分为应力应变统计、风荷载统计、风压统计和加速度统计.

实时监测是对所有动态点位（风速风向、风压力和加速度）和静态点位（应力）的实时监测.监测点位的选取方法如图6所示，将监测结构分为不同的监测区域，点击每个区域可弹出传感器布置细节图，以选取监测点位.静态点位取最新一天的监测数据，动态点位取最新30 s的监测数据，分别绘制时程图进行展示，如图7和图8所示.

监测回放是对所有监测点位历史监测数据的回放.选择要查询的时间段和监测点位（点位选取方法与实时监测页面相同）后会获取相应的历史监测数据显示在页面中，如图9所示为2014年2月1日至2014年3月1日的应变监测记录.在时程图上拖动鼠标选择相应区域后还可放大进行细节展示，如图10所示.图11展示了2014年9月22日2：15：00-2：30：00的风荷载监测统计数据.风压力和加速度监测画面和以上界面类似，不再赘述.

5结论

本文研究了大数据技术下的结构性态监测信息管理系统设计，从系统架构、系统功能实现和数据管理方案等三个层面论述了本结构性态监测信息管理系统的可行性和优越性.最后以宁波南站结构性态监测项目为例，展示了系统的应用效果.主要结论有：

1）应用三层B/S架构搭建的系统具有很好的扩展性和通用性，可方便灵活地加入各种数据分析功能，并且适用于多种工程结构的性态监测.

2）系统具有高度的伸缩性.根据项目对性能和经济性的不同需求，可选择配置一台服务器，或利用多台服务器协同工作.

3）基于大数据技术，以MongoDB数据库为数据管理平台，能实时吞吐海量的监测数据，每天可接收远程数据约10 GB，可同时供多方分析、查看和使用.系统设计时已考虑大数据分析，设有监测数据中心，通过多个监测项目以及长期的数据积累，可获得海量、高增长率和多样化的监测数据.

4） 网页设计采用基于HTML5的新一代WEB技术，用户界面简约大气，使用舒适方便，并兼容多种终端平台，如工作站、笔记本和平板电脑等.

5）目前系统各功能模块服务器均采用单台服务器，支持不多于300个动态采集通道，数据分析速率也有一定限制.若要进一步扩充采集通道、提高数据分析速率，可通过搭建服务器集群来实现.

参考文献

[1]刘德志， 李俊杰. 土石坝安全监测软件系统设计与实现[J]. 大连理工大学学报， 2006， 46（3）： 407-412.

LIU Dezhi， LI Junjie. Design and implementation of earth rockfill dam security monitoring software system [J]. Journal of Dalian University of Technology， 2006， 46（3）： 407-412.（In Chinese）

[2]WANG Jianguo， SU Meiyan， ZHAO Guomin， et al. Design and implementation of the earthquake precursor network running monitoring software based on C/S structure [C] // 2010 6th International Conference on Wireless Communications， Networking and Mobile Computing （WiCOM）. Piscataway， NJ： IEEE Computer Society， 2010， 4： 1-4.

[3]胡笳， 李晗， 杨晖柱， 等. 上海中心大厦结构健康监测软件集成设计及应用[J]. 同济大学学报：自然科学版， 2014，42（3）： 460-467.

HU Jia， LI Han， YANG Huizhu， et al. Integrated design and application of structural health monitoring software system of Shanghai Tower [J]. Journal of Tongji University： Natural Science，2014， 42（3）： 460-467. （In Chinese）

[4]孟小峰，慈祥. 大数据管理：概念、技术与挑战 [J]. 计算机研究与发展， 2013， 50（1）： 146-169.

MENG Xiaofeng， CI Xiang. Big data management： Concepts， techniques and challenges [J]. Computer Research and Development， 2013， 50（1）： 146-169. （In Chinese）

[5]KAMBATLA K， KOLLIAS G， KUMAR V， et al. Trends in big data analytics [J]. Journal of Parallel and Distributed Computing， 2014， 74（7）： 2561-2573.

[6]MARTINEZ M A， CUESTA C E， ARIAS M， et al. The solid architecture for realtime management of big semantic data [J]. Future Generation Computer Systems， 2015，47： 62-79.

[7]张燕. 基于C/S模式的远程数据监测系统设计[J]. 计算机与网络， 2008， 34（17）： 68-70.

ZHANG Yan. Design of remote data monitoring system based on C/S model [J]. China Computer & Network， 2008， 34（17）： 68-70. （In Chinese）

[8]罗天洪， 罗文军， 陈小安. 网络环境下协同设计的多服务器技术[J]. 重庆大学学报：自然科学版， 2006， 29（9）： 5-9.

LUO Tianhong， LUO Wenjun， Chen Xiaoan. Multiserver technology for internetbased collaborative design [J]. Journal of Chongqing University： Natural Science，2006， 29（9）： 5-9. （In Chinese）

[9]张文盛， 郑汉华. 基于MongoDB构建高性能网站技术研究[J]. 吉林师范大学学报：自然科学版， 2013， 34（1）： 123-127.

ZHANG Wensheng， ZHENG Hanhua. Research on the construction of high performance Web site based on MongoDB technology [J]. Journal of Jilin Normal University： Natural Science， 2013， 34（1）： 123-127. （In Chinese）

[10]PARKER Z， POE S， VRBSKY S V. Comparing NoSQL MongoDB to an SQL DB [C] //Proceedings of the Annual Southeast Conference. Savannah， GA： Association for Computing Machinery （ACM）， 2013， 5： 1-6.

[11]BARBIERATO E，GRIBAUDO M， IACONO M. Performance evaluation of NoSQL bigdata applications using multiformalism models [J]. Future Generation Computer Systems， 2014， 37： 345-353.

系统信息数据集中监测 篇4

应用温室技术进行农作物种植是实现我国农业现代化过程中的重要环节,温度和湿度是温室控制中的重要环境参数.为实现对多点温湿度数据的.自动监测,设计了以32位ARM处理器S3C44B0X为核心的多路数据采集和处理系统.该系统采用单一采集中心和多个智能采集节点的分布式结构,节点与中心采用RS-485总线进行通信,采集中心实时地收集、处理和显示各智能节点传回的温湿度数据,可有效提高数据采集工作的效率和稳定性.

作 者：黄伟锋 叶祥 作者单位：黄伟锋(仲恺农业工程学院,机电工程学院,广州,510225;华南农业大学,工程学院,广州,510642)

叶祥(仲恺农业工程学院,机电工程学院,广州,510225)

财政扶贫资金管理监测信息系统 篇5

二、在扶贫综合信息发布平台和扶贫综合查询分析平台上建立了扶贫项目管理体系、资金管理体系和效益评估体系。

三、总体业务数据流程如下：

首先，中央财政部向省级财政拨付扶贫资金，省级财政资金到位后进行向地级财政的指标分配，接着地级财政向县级财政做指标分配。此后县级的项目管理部门据此开始项目申报，例如：申报到省级的过程是逐级经过地级选报、省级审批、地级转批。审批后，省级财政逐级向下进行资金的拨付，拨付到地级然后拨付到县级。项目申报过程与资金的拨付过程都有特殊情况，比如说省管县的情况，在我们这个系统中可以解决省管县的问题。同时项目审批之后开始执行，涉及到了项目的招标、中标及合同信息等的录入，执行后可以通过财政部门进行报账。整个数据由县级向上级汇总便于上级管理监测。

四、数据流图分为资金数据流图和项目数据流图。资金数据流为由上级到下级。首先中央财政部向省级财政做指标分配和资金拨付，接着省级财政资金到位后进行本级安排以及指标分配，之后进行资金的拨付。地级财政资金到位后同样进行本级安排和指标分配，之后进行资金拨付。县级财政资金到位后进行本级安排，然后进行项目资金报账。项目管理的流程为：由下级逐级到上级。首先，县级项目管理单位申报项目，然后经过审批。审批之后即可进行招标、中标、合同、启动，启动后可以录入进度、验收和绩效考评信息。

五、信息综合查询对应分为资金信息查询和项目信息查询。在资金信息统计查询中，各级财政可以查看资金分配、拨付、安排及报账资金统计信息。项目信息统计查询中上级可以查询到所管辖的下级的已审批项目情况，包括招标、中标、合同、启动、进度、验收及绩效考评信息。

具体介绍

通过上网在浏览器中输入地址，（http://），这是内蒙古财政信息网，面可以看到新增的信息，点击编辑和删除可以进行修改和删除操作。公告通知、扶贫简报、新闻快递、工作动态的浏览和录入的方法与此类似。在这里不再赘述。

本系统的最后一个功能模块为系统维护。首先选择用户修改密码。点击此菜单进入后，首先需要输入原密码，然后输入新密码，再重新输入新密码表示确认。点击提交按钮后用户登录的密码会被自动保存。注意：新密码可使用任何英文字母及阿拉伯数字、下划线组合，不得少于6个字符和超过20个字符,并区分英文字母大小写。本级信息维护子菜单使用来录入本地区的简介信息，包括人文地理等，录入的权限在财政部门。所以以新疆维吾尔自治区财政的身份登录，点击此菜单进入后，在文本框中录入完毕后提交，点击页面左边的新疆简介链接就可以看到刚才录入的信息。系统维护的最后一个子菜单为帮助，其中介绍了本系统的开发背景、总体框架及流程，方便用户理解。勤劳的蜜蜂有糖吃

系统信息数据集中监测 篇6

一、红麦舆情监测系统

红麦网络舆情监测系统（也称unotice舆情监控系统，鹰眼舆情监控系统），是将搜索引擎技术应用在企业舆论情报服务的一次创新。系统利用独有爬虫技术，能根据预定的监控关键词在15分钟以内发现15万个重点媒体、论坛、博客、微博等网站里的舆情信息，并对危机信息及时报警。系统利用中文分词技术、自然语言处理技术、中文信息处理技术，对信息进行垃圾过滤、去重、相似性聚类、情感分析、提取摘要、自动聚类等处理，配合专业分析师生成详细的舆情分析报告。

（一）服务对象：政府机关、各级各类组织机构、企业等。

（二）解决方案

红麦为传统企业、互联网企业和政府部门提供专业的舆情数据监测、数据分析及咨询服务。协助企业准确掌握产品和市场情况，监控竞争对手和行业动态，了解网民口碑，为企业市场、行销决策提供支持支撑服务。帮助政府部门快速发现突发事件、重大事件，快速应对，提高政府和企业的形象。并在国内网络口碑研究领域奠定了领先地位和服务品牌。红麦从产品出发，推出一系列面向行业客户的一体化舆情平台解决方案，这些方案为客户的互联网舆论环境、危机公关、营销效果、品牌口碑、竞争对手策略等提供全方位解决之道。

◆ 红麦认为，聆听网络口碑很重要

◆ 品牌需要通过网络口碑获取消费者洞察和产品反馈，深入理解网络社区文化

◆ 品牌需要融入网络社区，与网民互动，传递品牌心声

红麦舆情监测解决方案综合了各类政府、企业级用户的应用需求，旨在为客户提供更加容易与目标人群沟通并挖掘更多价值资讯的全方位解决方案。

二、麦知讯第三方网络舆情监控系统

麦知讯是一家致力于向国内外行业用户提供互联网信息监测整体解决方案、业务发展信息咨询的高科技公司。它在资本运作和整合国内多家互联网信息专业公司、行业研究咨询公司的过程中不断成长，并通过合理地选择和应用成熟的互联网信息技术，使公司在原有业务的优势得到巩固的同时，也在新的业务领域取得了优异的成绩。它的舆情监控内容包括：口碑信息监测（企业、产品、品牌正负面口碑监测，竞品间的口碑对比监测等）、网络营销监测（针对营销主题，提供点击数、回复数、回复时间、回复人、回复内容、回复语气、回复人感情倾向、正反向关注度、主题删帖率等监测服务）、网络营销效果监测（搜索引擎呈现率、产品品牌知名度、用户关注度、好评率变化统计分析）、网络营销咨询服务（为企业或公关公司提供网络营销方案或决策意见及建议）等。

三、Goonie网络舆情监控系统

它依托自主研发的搜索引擎技术和文本挖掘技术，通过网页内容的自动采集处理、敏感词过滤、智能聚类分类、主题检测、专题聚焦、统计分析，实现各单位对自己相关网络舆情监督管理的需要，最终形成舆情简报、舆情专报、分析报告、移动快报，为决策层全面掌握舆情动态，做出正确舆论引导，提供分析依据。它支持多种网页格式、多种字符集编码、整个互联网采集以及内容抽取识别技术，具有热点话题、敏感话题识别，舆情主题跟踪，自动摘要，舆情趋势分析，突发事件分析，舆情报警系统，舆情统计报告等多种功能。同时，用户可以设定采集的栏目、URL、更新时间、扫描间隔等，系统的扫描间隔最小可以设置成1分钟，即每隔一分钟，系统将自动扫描目标信息源，以便及时发现目标信息源的最新变化，并以最快的速度采集到本地。

四、鹰隼网络舆情监控系统

本果公司在透析互联网特点、网民习惯和偏好基础上，充分运用自身搜索引擎技术、全文检索技术、相似性排重技术、自然语言智能处理技术、内容管理、互联网技术以及电子政务和电子商务软件开发优势，成功研发了鹰隼网络舆情监控系统。

它对舆情的处理按照信息采集、舆情过滤、自动分类、相似性排重、舆情分析、舆情展示的流程推进，整个系统由三部分组成，分别是信息采集子系统、舆情处理分析子系统和舆情管理子系统。它能够有效地搜索互联网上各层次各角落各形式的信息，深层次地挖掘网络舆情价值，全天候并及时地提供最新网络舆情资讯、丰富翔实的信息、形象直观的图表，自动化的舆情预警，并递送网络舆情、舆情分析、统计数据、舆情报告。

五、军犬网络舆情监控系统 它是中科点击公司开发的一个体系结构先进、功能强大的面向政府、企业提供网络舆情监测和决策参考的应用系统，广泛地用于舆情监控监测，竞争情报以及风险预警等领域，它是一套综合运用搜索引擎技术、文本处理技术、知识管理方法、自然语言处理、手机短信平台，通过对互联网海量信息自动获取、提取、分类、聚类、主题监测、专题聚焦,以满足用户对网络舆情监测和热点事件专题追踪等需求的舆情监控平台。

系统信息数据集中监测 篇7

2011年4月16日, 随着所有系统复制数据验证顺利结束, 宁夏电力公司集中式信息系统数据级容灾建设工作全部实施完成。作为西安容灾中心第一批唯一一家网省建设单位, 宁夏电力公司高度重视、周密部署、统筹实施, 在中国电科院、甲骨文、惠普等参建厂商的配合下, 于2010年12月23日开始容灾实施, 12月29日完成营销管理系统、生产管理系统、ERPECC系统、ERP ECC系统、企业门户数据库/数据交换系统的6套应用系统数据库复制工作。

2011年1月24日开始存储复制实施, 于1月30日完成国网容灾要求的30多个信息系统基于存储复制的数据级容灾。3月16日开始复制数据的一致性及可用性验证, 于4月16日完成复制数据的所有指标的验证工作。至此, 宁夏电力公司集中式信息系统数据级容灾建设工作全面完成。

宁夏电力公司完成数据归集及存储级优化整合工作, 实现了集中式数据级容灾, 确保了该公司信息系统在面临大规模灾难或不可预见的意外事件时, 各项关键业务数据能够得到及时保护。信息系统可以实现快速恢复, 以保证业务的连续运行, 并可持续对国家、社会和内部用户提供所需要的服务, 履行所承担的社会职能, 降低和规避日常运营风险。

数据集中工程前端系统设计及实现 篇8

关键词:数据集中工程 前端系统设计

1 数据集中工程前端系统的设计

数据集中工程的总体目标是将原来各省分行独自处理保存的业务数据上收到总行数据中心,从而实现帐务数据、核心业务的集中处理,以满足未来业务发展的需要。

按照数据集中工程的总体规划,建立总行数据中心(在北京、上海两地分别建立两个数据中心,并互联以满足业务的需要),各分行原有的帐务数据和核心业务系统功能全部上收至总行数据中心的DCC主机;为了将各省分行的交易包括总行统一的业务和各分行特色性业务接入到总行DCC主机,总行统一开发大前置系统部署于各个分行,前端系统通过大前置系统将各分行的交易发送到总行数据中心DCC主机。

前端软件系统按结构设计分为前端平台系统、前端核心系统和前端特色业务系统三部分。

1.1 前端平台系统:包括操作系统、数据库、中间件等平台软件。其配置标准为:

1.2 前端核心系统指在支行网点运行的,应用于柜员工作站的全行统一的业务系统。它通过网络系统与前置机进行数据交互,完成交易的处理功能。包括柜员工作站软件、授权/消息服务程序、通讯服务程序、前端数据库四大部分。

1.3 前端特色业务系统是指由前台实现的核心业务系统以外的业务功能。

2 数据集中工程前端系统的实现

数据集中工程前端系统的核心是前端核心系统,主要业务是由柜员工作站软件和授权/消息服务程序完成的。由于决大多数业务根据其特点可以分类,具有统一的模式,因此每一类业务可以采用统一的模板来分类处理,在不同的模板存储不同的参数,形成各种交易。前端应用系统的设计是通过使用两种类型的源代码文件(过程文件和资源文件),存储每个交易的具体交易参数为交易模板,构造交易驱动器来描述同一类的交易流程,突现流程概念,从交易模板获取具体交易参数,实现具体交易功能。

交易驱动器是一个前端交易流程控制程序,完成从交易初始化到交易结束之间各个功能模块的动态调用,大部分的交易可以由一个通用的交易驱动器实现,特殊交易可以编写特殊的交易驱动器前端应用系统需要实现的功能由交易驱动器、资源和过程以及其它手工编制的程序部件和功能函数配合完成。交易驱动器的主要功能是根据交易的信息,调度交易所需资源和过程实现一般交易的处理流程。

3 前端系统的安全模块和安全规范

数据集中工程(简称DCC)是一个三层结构(前端/渠道、前置系统、DCC主机)的分布式系统,在跨物理系统进行数据传输时,毫无疑问会涉及到数据保密的问题。如何合理、可靠、高效地实现数据传输的保密,是前端系统在和前置系统连接时必须考虑的重要问题。

前置系统在考虑和前端的安全问题时,是以三级密钥体系和动态交换工作密钥的安全机制为基础,并在其上进行了扩展增强,最终形成了数据集中下的前置系统和前端系统的安全规范。

3.1 三级密钥体系 密钥如何管理、分发等问题历来是分布式系统的安全体系下的重点和难点。DCC的安全体系在充分考虑加密的强度的同时,还需要考虑管理维护的简便性,以及和DCC主机的安全机制兼容等问题。经过充分对比论证,制定了目前的以masterkey作为基础密钥加密保护basekey和workkey,basekey用于身份认证和动态交换workkey,workkey用于加/解密和MAC校验保护交易数据的三级密钥体系结构。

在此密钥体系下,针对通讯节点而设置的masterkey和basekey都是通过非计算机网络的其它渠道(如密码信封)分发的,不存在因网络传输泄密的问题。masterkey在存储时是通过安全模块采用固定的密钥加密保护的,basekey则是通过明文的masterkey加密保护存储的;针对通讯节点而动态交换的workkey是由masterkey加密保护存放的。

3.2 身份认证和密钥同步 对于前置系统来说,如何鉴别某个和它连接的外部系统通讯节点是否合法呢?由于我们在前置系统上登记了所有合法的和它连接的通讯节点号(即前置系统的所有对等通讯节点号),以及和这些通讯节点中的每一个约定的basekey,而这些信息是通过非网络的方式约定的,可被我们认为是保密的,可靠的。因此,我们可以是此为依据来鉴别某个通讯节点的合法性。

一个通讯节点在和前置系统进行所有的交易前,必须首先向前置系统申请密钥同步(对workkey进行同步,后续的交易数据将以此密钥进行加密,MAC保护传输),在进行密钥同步的同时,前置系统可以对发起密钥同步的通讯节点的身份进行:双方按照约定的算法,申请密钥同步的通讯节点用basekey加密其通讯节点号,而前置系统则使用basekey解密,如果解得的通讯节点号与所用的basekey组合后得到的(通讯节点号、basekey)对在前置系统的安全数据库中能够找到匹配项,则说明该通讯节点合法,身份认证通过,前置系统通讯节点的密钥服务器为该通讯节点动态产生workkey,刷新安全环境(数据库和共享内存中的缓存)中的workkey,并将其用basekey加密后返回给该通讯节点。

申请密钥同步的通讯节点在接收到前置系统通讯节点的密钥服务器返回的workkey后,先使用basekey解密,得到workkey明文后,再用本通讯节点的masterkey加密并存放到安全环境(数据库和共享内存中的缓存)中。

身份认证和密钥同步可通过随安全模块发布的工具程序来进行,无需再做什么开发工作,仅需要对安全模块进行正确的配置即可。

3.3 安全API 安全API是安全模块把安全加/解密,MAC校验功能开放给其它需要安全通讯功能的应用程序使用的接口。它定义了应用程序的开发模型和编程接口。

3.4 安全模块的运转机制 安全模块主要由安全工具和安全API两部分构成,这两部分在建立安全通讯环境的过程中起到了不同作用。运行在不同的通讯节点上的安全工具程序密钥申请客户端applykey和密钥分发服务器keyserver互配合,来完成workkey密钥的同步功能;在此之前,还需要通过inst_node、setmkey工具来添加一个本地通讯节点和设置它的masterkey,通过addpeernode工具来设置该通讯节点的对等通讯节点的basekey,通过sec_init启动并初始化安全环境。

在sec_init初始化安全环境成功之后,使用安全API的应用程序就可以运行进行数据的加/解密了。但是只有在本地通讯节点和它的对等通讯节点的workkey正确同步之后,数据的加/解密才能正确进行,否则,将会导致数据加/解密错误。

安全工具程序和安全API是相辅相成,不可分割的。安全工具程序是构建安全子系统的基础,它创建和维护安全API得以运行的安全环境;安全API则为应用程序使用安全子系统的数据保护功能提供了标准编程接口。

4 结束语