实时数据论文（精选11篇）
实时数据论文 篇1
摘要：基于关系数据库, 探讨实时数据在关系表中的压缩存储和访问技术。采用Oracle数据库内部语言, 对给出的压缩方法加以实现。程序运行结果表明, 针对大量的实时数据具有良好的压缩效果, 压缩后数据量急剧减少, 在数据时间间隔频率不高和采集点数较少时, 给出的方法可作为实时数据库的替代方案。
关键词：关系数据库,实时数据,数据压缩,Oracle
0 引 言
在工业实时数据库的发展历程中, 早期的实时数据库使用封闭的文件系统, 目前先进的实时数据库系统直接使用开放的关系数据库如Oracle或SQL Server等存储历史数据, 这样实时数据库就可以直接融入上层应用信息系统。但是, 这种信息化应用的前提是, 企业必须购买专门的实时数据库系统。是否可以在关系数据库中直接存储实时数据, 这是值得探讨的问题。
由于实时数据具有不间断、数据量大的特点, 并且需要高速的历史数据定位访问能力, 故在关系数据库中, 采用传统的方式, 进行数据存储和访问, 是不可行的, 需要考虑数据压缩。
将要探讨的实时数据的压缩存储是在Oracle 10g数据库内部, 采用数据库自身的语言PL/SQL (Program language/Structured Query Language) 实现。为了提高数据压缩率, 提出了逻辑压缩和物理压缩两种方式, 其中物理压缩采用的是数据库层面的进制转换技术, 即对长时间的历史数据处理成二进制数进行合并存储, 达到减少数据表记录数的目的, 这种方式具有一定的新颖性;逻辑压缩为针对实时数据的有损压缩, 采用的是Swinging Door (旋转门) 压缩技术, 达到减少数据存储量的目的。所不同的是, 将旋转门技术嵌入关系数据库内部实现, 这种方式, 在国内尚未有文献报道。
1 数据压缩的原理及实现
如上所述, 实时数据在关系数据库中的压缩, 涉及逻辑压缩和物理压缩两个方面, 其中前者为有损压缩, 即数据被还原时有损失, 后者为无损压缩。
1.1 逻辑压缩
逻辑压缩采用旋转门算法, 该算法主要应用在基于时间序列的工业历史数据上, 通过旋转门压缩方法后, 能够消除小信号扰动, 达到过滤噪声的功能, 且增加数据的平滑度, 有利于进行数据分析和挖掘。但它是一种有损压缩, 通过丢弃一些数据的方法来达到减少存储容量的要求。这些被丢弃的数据在一定误差内必须不影响过程历史数据的重构[1]。
旋转门压缩技术的实现方法是, 系统每接收到一个新值 (即当前值) , 都会和最近保存值 (即图1的最近保存点) 一起构造出一个有两条边同X轴垂直的平行四边形, 该平行四边形也称为压缩偏移覆盖区。如果在新值和最近保存值之间只要存在一个值, 落在平行四边形外, 那么就存储新值的上一个值, 否则就继续接收新值, 没有任何数据点被保存。如图1在对测试点C进行压缩测试时, 发现不再满足旋转门压缩算法的条件, 则说明点B未通过压缩测试, 存储该点并作为最近保存点, 并继续下一轮的压缩测试。如图1所示, 平行四边形垂直方向的边长是压缩偏移量的两倍, 压缩偏移量可由用户设定, 并且每个信号点 (数据采集点) 均可以有自己的压缩偏移量[2]。压缩偏移量取得越大, 数据的压缩率就越高, 反之, 压缩偏移量越小, 则压缩率越底, 但是, 解压的精度和压缩率成反比。图1按第1到第7点的顺序说明了旋转门压缩算法的原理。旋转门算法步骤的具体文字描述可参见文献[3]。
(1) 旋转门算法的PL/SQL程序实现
/*首先对原有S1、S2的斜率值初始化*/
OldS1 number:= -1; OldS2 number:=1;
/*对某采集点的给定所有值循环压缩, 在压缩测试值到达最后一个时停止循环, 变量v_CurrSub为当前压缩值下标, v_Num为待压缩值的个数*/
While v_CurrSub<v_Num loop
v_CurrSub:=v_CurrSub+1;
/*求取斜率S1、S2、S, v_RecoTab是以记录为元素的数组, 记录含有值 (value) 和时间 (time) 两项, v_LastSub为最近保存值的下标, CompDif为压缩偏移量, TimeDif为等距时间。*/
S1:= (v_RecoTab (v_CurrSub) .value- (v_RecoTab (v_LastSub) .value+CompDif) ) /TimeDif;
S2:= (v_RecoTab (v_CurrSub) .value- (v_RecoTab (v_LastSub) .value-CompDif) ) /TimeDif;
S:= (v_RecoTab (v_CurrSub) .value- v_RecoTab (v_LastSub) .value) /TimeDif;
if S1>OldS1 then OldS1:=S1; end if;
if S2<OldS2 then OldS2:=S2; end if;
if S<OldS1 or S>OldS2 then
/*将前一个测试点作为新的保存点*/
v_LastSub:=v_CurrSub-1;
end if;
end loop;
(2) 旋转门算法的实用解压方式
通常, 采用的历史数据解压缩算法要与采用的压缩算法相对应, 一个常用的、简单的解压缩方法是线性插值算法。如图1所示, 直线AB连接A和B两个测量点, 它们之间的任何测量值可以用下面的公式进行线性插值:
这个估计作为t时刻的历史数据y的解压缩值。记yi为i时刻的解压缩值,
1.2 物理压缩
同样所提出的物理压缩, 也主要应用在基于时间序列的工业历史数据上, 并且这些数据必须等距时间。物理压缩的基本原理是, 对于某个采集点, 将一段等距时间序列的数据, 用一个特定的且区别于小数点的符号连接成规定长度的字符串 (该处的特定符号可称为连接符) , 再将该字符串转换成二进制串, 使用关系数据库中存储二进制的大对象类型 (比如在Oracle数据库中可采用BLOB类型) , 对此串进行存储。由于压缩后的数据为二进制串, 所以对重要的工业数据具有一定的保密性。
(1) 物理压缩步骤的文字描述
1) 设置当前数据采集点的数值连接串为空字符串, 并记录该采集点将要参加压缩数据的起始时间点 (BegTim) ;
2) 将当前时间点的值及一个连接符 (如逗号) 接入连接串, 并记录下当前时间点 (EndTim) ;
3) 如当前采集点的数值连接串的长度小于最大设定值 (如2KB) 则转入2 (否则, 去掉最后多余连接符并转入4) ;
4) 将当前采集点对应的数值连接串转换为二进制串存入关系数据库表;
5) 对新的时间点的值, 重复以上过程。
(2) 物理压缩对应解压方法及实现
解压时分两种情况, 一是解压时间点 (DcompTim) 的值位于字符连接串 (ConnStr) 的首或尾时, 直接求子串即可得到。二是解压时间点的值位于连接串中间时, 则用解压时间减去连接串的起始时间, 接着用该时间差除以各值之间的等距时间 (TimDif) , 从而求出需解压值在连接串中的位置 (DcompPos) , 利用该位置值算出需解压值前一个连接符 (ConnLab) 的位置 (BegPos) 和后一个连接符的位置 (EndPos) , 最后结合两个连接符的位置值求出给定时间点的解压值。解压对应的部分PL/SQL程序如下:
DcompPos:= (DcompTim-BegTim) *24*60*60/TimDif;
BegPos:=INSTR (ConnStr, ConnLab, 1, MidPos) ;
EndPos:=INSTR (ConnStr, ConnLab, 1, MidPos+1) ;
/*由解压点的值在连接串中的开始位置下标BegPos+1及长度EndPos-BegPos-1, 通过求子串求出字符类型解压值*/
StrVal:=SUBSTR (ConnStr, BegPos+1, EndPos-BegPos-1) ;
/*将字符类型的解压值转换为Number类型*/
NumVal:=TO_NUMBER (StrVal) ;
1.3 混合压缩
为了得到更高的压缩率, 在介绍了物理压缩和逻辑压缩的原理, 自然会想到将它们结合起来, 这里称为混合压缩, 从而得到更好的压缩效果。例如某一采集点一段连续时间的数值是:6.1、6.1、6.2、6.1、6.2、6.3 (如各数值间的等距时间为5分钟) , 直接利用物理压缩的数值连接串为:“6.1, 6.1, 6.2, 6.1, 6.2, 6.3”, 采用压缩偏移量为0.1进行逻辑压缩后仅得到两个数值6.1和6.3, 再结合物理压缩的思想将这两个数值用逗号连接成串:“6.1, , , , , 6.3”, 其中逗号为连接符 (当解压时发现两个连接符号之间没有值, 则找到最近两个存在的值6.1和6.3, 利用时间差进行线性插值解压) 。最后将该字符串转换成二进制串存入表1的压缩连接串值字段 (当然在解压时首先要将该二进制串转换成字符串再进行解压) 。
2 压缩性能分析
为了对历史数据在关系数据库中的压缩性能作进一步分析, 笔者对实际发生的数据压缩情况进行了跟踪。表2分别对逻辑、物理及混合压缩进行了压缩性能分析, 其中原始 (数据) 记录和逻辑压缩后的记录采用相同形式的存储表设计, 对应数据库表均包含采集点、时间和值三个字段, 所以某采集点一个时间点的值对应一条记录。而物理压缩和逻辑压缩采用表1的存储形式, 故某采集点一段时间内值的连接串构成一条记录 (连接串的长度一般不大于2KB) , 总记录数相对逻辑压缩急剧减少。表2列举了五个采集点作为实验对象, 在第一栏给出了每个采集点不同的编号, 表中数据格式表示数值的有效位数, 采集点FI-1134的数据变化频繁, 而FIC-1111比较平稳, 其余三个采集点变化相对稳定, 代表了普遍情况。各采集点的采样频率均为5分钟, 时间跨度为30天, 原始记录数为8640个。
如表2所示, 采集点FIC-1111逻辑压缩后的记录数为3975, 与原始记录数8640相比后得到压缩率约为46%。可见旋转门算法对变化不频繁采集点的压缩率是相当高的, 而五个采集点的平均压缩率约为65%。由于采集点FI-1134的数值变化比较频繁, 另外三个采集点数值变化适中, 所以此平均压缩率可在一定程度上反映实际应用情况。物理压缩是在原始记录的基础上将一段时间内的数值连接成串进行存储, 故记录数急剧减少。而采用混合压缩方式, 是在物理压缩的基础上运用了逻辑压缩, 使得一段时间间隔内的压缩连接串相比物理压缩时更短, 因此减少了记录数。可见以上的压缩方式对于基于时间序列的工业历史数据具有良好的压缩性能和一定的实用价值。
3 结束语
综上所述, 关系数据库中, 实现实时数据的压缩存储和访问是可行的。经过数据压缩, 显著提高了数据存储量及访问效率, 能够实现关系型数据库对历史数据长时间、高频率的存储。由于采用纯数据库技术, 提出的方法可推广至Oracle 10g以外其他版本或其他类型的关系数据库。
参考文献
[1]汪勇.流程工业历史数据库的研究[D].杭州:浙江大学信息科学与工程学院, 2005.
[2]彭春华, 林中达.PI实时数据库及其在电厂SIS系统中的应用[J].工业控制计算机, 2003, 16 (6) :28-33.
[3]张景涛, 王华, 王宏安.实时数据的存取与压缩[J].计算机技术, 2003, 30 (3) :47-50.
实时数据论文 篇2
靶场弹道跟踪实时数据平滑算法及实现
通过分析靶场测试中目标的弹道特性,提出并利用了Gram-Schmidt曲线拟合方法实现弹道数据的.平滑处理.并利用VC++高效编程保证了弹道数据平滑的实时性.试验表明,该方法能够大大提高靶场弹道测试过程中弹道测试设备对飞行特性不稳定目标的跟踪能力,同时减少了跟踪过程中跟踪抖动对精密跟踪设备的损害.
作 者：胡杰 钱礼华 付宇 HU Jie QIAN Li-hua FU Yu 作者单位：中国兵器工业第○五一基地,陕西,渭南,714200刊 名：桂林航天工业高等专科学校学报英文刊名：JOURNAL OF GUILIN COLLEGE OF AEROSPACE TECHNOLOGY年，卷(期)：200914(4)分类号：V557关键词：弹道跟踪 实时数据平滑 Gram-Schmidt 曲线拟合
海量数据实时处理算法设计与分析 篇3
【关键词】海量数据 MapReduce算法 hash
一、背景以及现状
随着互联网的发展，在许多科学领域，信息数量呈指数型增长。截止到2011年全球信息总量为1.8ZB[1]。海量数据的时代已经来临，然而面对海量数据该如何存储，如何有效的处理，及时有效的处理了这些数据对于各行各业乃至整个社会的发展有着重要的意义。过去的几年里单机的性能得到发展，硬件也得到发展。但在理论上这些硬件技术的发展是有限的。现今的多核技术就是并行技术发展的一个实例[2]。
二、MapReduce的技术特征
1）横向扩展与纵向扩展。对于MapReduce集群的构建采用低廉且容易扩展的低端商用服务器，考虑到大量数据存储的需要，基于低端服务器的集群远比基于高端服务器的集群优越，所以基于低端服务器实现都会使用MapReduce并行计算集群。
2）失效与常态。相对低端的服务器适用于MapReduce集群，无论哪个节点失效，其他的节点要无缝接管着失效节点的计算任务；当该节点恢复以后将不需要人工配置而是能自动无缝加入集群。
3）处理向数据迁移。MapReduce采取数据与代码互定位的技术时，计算节点首先计算其本地存储的数据并对其负责使数据发挥本地化的特点。
三、对MapReduce改进
（一）预处理算法
大量事实证明，在数据挖掘中整个工作量的60%到80%都是数据预处理[3]。通过数据预处理工作可以使残缺的数据变得完整，能达到数据类型相同化、数据格式的一致化、数据存储集中化和数据信息精练化[4]。采用Hash算法，间接取余法。公式：f（x）：= x mod maxM ； maxM一般是不太接近 2^t 的一个质数。得余数x，根据x对源数据进行预处理分配，采用Hash取模进行等价映射。
（二）分布缓存
对由N台缓存服务器组成的集群缓存把集群依次编号为0 - （N-1）。
1）hash机器节点。首先求出机器节点处的hash值，然后把它分布到0～2^32的一个圆环上（顺时针分布）。如图3-1，集群中有ABCDE五台机器，通过hash算法把它们分布到如图3-1所示的环上。
2）访问方式。写入缓存的请求，Key值为K计算器hash值为hash（K），Hash（K）对应着图3-1环中的某一个点。若该点没有对应映射到具体的某个机器节点上，就进行顺时针查找直到找到确定的目标节点，也就是首次有映射机器的节点。Hash（K）的值介于A～B之间时，那么它命中的机器节点应当就是图3-1中的B节点。
3）增加节点的处理。如图3-1中如果在原有集群的基础上想再增加一台机器F，过程如下，首先要计算机器节点的Hash值，找到环中的一个节点，把机器映射上，如图3-2所示。在增加机器节点F以后访问策略不发生改变，按2）中的方式继续访问，那么此时仍然是不可避免的是缓存不命中的情况，hash（K）在增加节点之前不能命中的数据是落在C～F之间的数据。hash它使用了虚拟节点的思想，在圆上分配了100～200个点为其中的每一个物理节点，这样就能较好的抑制了分布的不均匀的情况，还能最大限度减小当服务器增减时缓存的重新分布。
{三}复用中间结果
在对海量数据进行了预处理和分布式缓存之后，采用简单随机取样[5]的方法对缓存好的数据进行随机取样具体实现该方法。
四、实验
本论文的实验可以对是某地区房价数据进行处理，简要的过程如下：
第一数据预处理阶段，首先让每一组数据分别自动编号，然后采用取余的方法。第二根据分组情况，分别把各组数据放置到不同的服务器上。第三采用简单随机取样的方法对缓存好的数据进行随机取样，选择出最适合的房产。
五、结束语
本文在算法方面也还有一些不足之处，有待深入的分析。目前海量数据的处理还有很多值得深入研究和挖掘的地方，还将会是热门的话题以及更多专家学者热衷研究的方向。
【参考文献】
[1] John Gantz， David Reinsel .The 2011 Digital Universe study： Extracting Value from Chaos [J]. International Data Corporation （IDC）， 2011
[2]陈康，郑纬民.云计算：系统实例与研究现状[J].软件学报，2009，20（5） ：1337 -1348.
[3]D. Romano， Data Mining Leading Edge： Insurance&Banking， InProceedings of Knowledge Discovery and Data Mining， Unicorn， BrunelUniversity， 1997.
[4]刘军强，高建民，李言等.基于逆向工程的点云数据预处理技术研究.现代制造工程.2005.7： 73-75.
实时数据论文 篇4
在工业生产中,要维护大量共享数据和控制数据;又需要实时处理来支持其任务与数据的定时限制[1]。传统的实时系统虽然支持任务的定时限制,但它针对的是结构与关系很简单、稳定不变和可预报的数据,不涉及维护大量共享数据及它们的完整性和一致性[2]。实时数据库需要对一系列的概念、理论、技术、方法和机制进行研究,并对各个功能模块做详细周到的设计[3,4]。
历史数据处理作为工业实时数据库系统的一个核心功能,其主要作用是保存实时数据的历史记录。由于先进控制应用和实时优化的需要,有一部分历史数据被访问的频率可能很高,为了减小磁盘的读写负担,需要在内存中保存部分近期的历史数据,称之为内存历史数据。另外,对于超过一定时限陈旧的数据,需从内存中清除,并做一定的处理,然后转存到磁盘文件上。
1.1内存历史数据库
有部分历史数据是保存在内存里的。因为某些先进控制软件和实时优化软件等需要频繁访问这些数据,而内存的存取速度快的特点可以充分满足这些软件的实时访问需求。根据需要可以将某些历史数据有选择性地保存到磁盘历史数据库中[5]。
1.2 磁盘历史数据库
磁盘历史数据库主要以磁盘文件的形式存储历史数据。这种以磁盘文件为介质的形式适宜于存储长时间、大量的历史数据。同时便于转移、备份历史数据。为了使磁盘历史数据库具有快速、稳定的存储、读取性能,历史数据文件的结构、数据缓冲区的设置及使用的压缩算法等设计都是至关重要的。
目前,实时数据库市场主要为国外的 PI(PlantInformation system)、Industrial SQL Server 等几大品牌所占据。这几个实时数据库在技术性能、功能扩展等方面是比较先进成熟的。
PI 采用了独到的压缩算法和二次过滤技术,这使得 PI 成为实时数据库中压缩性能最为优越的一个。根据计算通过 PI 的数据压缩技术的处理,104点/s 数据存储一年,仅需4 G 空间。性能优越、使用简单等优点使得 PI 成为应用最广泛的实时数据库产品[6]。
IP21(InfoPlus.21)用于集成生产过程信息与高层次应用程序的基础数据平台,它使用户可以访问和集成来自整个工厂范围内 DCS 及 PLC 的数据,它通过功能极强的分析工具、历史数据管理、图形化的用户界面和大量的过程接口来访问和集成数据。IP21是一个智能化实用化的信息管理系统,它可以提供给用户最需要的东西:合适的实时应用支持、多线程、客户机/服务器结构。先进的过程数据服务器和历史数据管理在应用的任何地方都是可行的,特别是其灵活的数据结构可以根据应用的需要重新定义以适合自己的应用系统的需要。
Industrial SQL Server 是由数据采集、数据压缩、生产动态浏览和历史数据归档等功能构成一个完整的实时数据库系统,实时数据和历史数据用专门的文件保存[7];数据库服务器内嵌 MS SQL Server,使其具备关系型数据库特性,增强了复制功能,集成了 Mail 和Internet。它是第一个可满足工厂对数据采集速度、存储量要求的实时关系型数据库,是常规关系型数据库的数据采集速度、存储量的数百倍;它扩展了 SQL 语句,使其具有了时间特性。
上述几大实时数据库虽然在很多方面都很先进,但也存在一些不足之处需要改进。首先,现今几大实时数据库的历史数据查询性能有待提高。影响到查询性能一个很重要的因素是历史数据的文件结构,尤其是索引结构。另外,各实时数据库生产商在历史数据的压缩处理这方面下了很大的功夫,尤其是 PI 在这方面做得很好,但是历史数据的压缩效率还有提升的空间。
2 历史数据存储过程
实时数据库通过接口软件从下层采集数据,这些数据同时被写入到内存历史数据库和磁盘历史数据库中。某个测点在内存数据库中保存的历史数据长度,在测点组态时就已确定。当保存的内存数据长度超过这个值时,相对陈旧的数据将会被新采集到的数据替换。而将写入到磁盘的历史数据,只要磁盘空间足够大,一般是没有长度限制的。整个工厂的过程数据存储量是巨大的,不进行相应的压缩处理必将浪费大量的存储空间。因此,数据压缩是历史数据写入到磁盘之前的重要处理环节。
如图1所示,实时数据库通过接口软件从下层设备采集数据,采集方式可以是多种多样的。当今比较通用的是用 OPC(OLE for Process Control)通信方式获取数据,此时接口软件即相当于一个 OPC 客户端,通过网络获取 OPC 服务器提供的数据。接口软件获取的数据有2份拷贝,一份传至内存数据库,替换掉内存数据库内原有的陈旧数据;另外一份则通过调用磁盘历史数据库模块做一些相关处理,将数据写入到磁盘文件。其中,历史数据库的历史数据存取模块是提供对历史数据读取操作的相关接口。工厂过程数据如不经过任何处理全部存入磁盘文件,占用的空间将会是相当庞大的。因此,过程数据在存入磁盘之前需要经过相关的压缩处理。各种数据类型所采用的压缩方式有可能是不一样的,压缩算法在本文后面章节有详细描述。此外,为防止频繁进行磁盘写操作,内存中开辟了历史数据缓冲区,需要存入磁盘的过程数据首先放在缓冲区,当缓冲区中积累了一定数量的历史数据时再一次性地写入到磁盘历史数据库文件中。
3 内存历史数据库管理
在实时数据库中可能有一部分测点的近期数据将有可能被频繁访问,若每次访问这些测点数据都从磁盘上临时读取,这对磁盘将会是一个很大负担。内存历史数据库即是用作存放这些数据的。
在测点组态时,可根据需要设置各个测点要保存的内存历史数据长度。内存数据库根据组态信息预分配数据空间。进入内存数据库的数据都是经过压缩处理的,过程数据源源不断地通过接口软件采集而来,填入到内存数据库的数据区。当数据区填满时,陈旧数据从数据区中被淘汰掉,取而代之的是新采集来的数据,以保持测点数据的实时性。
4 磁盘历史数据库管理
各位号的磁盘历史数据是以磁盘文件的形式存在的。所设计的磁盘历史数据库中存在2种文件:历史数据文件和管理信息文件。一个实时数据库项目通常有一个管理信息文件及多个历史数据文件。历史数据文件主要存放位号历史数据及相关的索引信息;而历史数据管理文件保存了实时数据库中所有历史数据文件的信息及文件间的时间索引,以便快速定位某时间段对应的历史数据文件。
4.1磁盘历史库的文件描述
4.1.1 历史数据文件
历史数据文件采用的是页面存储管理方式,这样可以提高存储和访问效率。页面大小设置为多少最合适,可以根据相关性能方面的测试获取,历史数据文件结构如图2所示。
历史数据文件一般都有一个文件头页,这个页面记录了本数据文件的首个空页、空索引页的位置、页总数及页尺寸等信息。文件头页为整个文件的起始页,文件头页后紧跟着的是大量的数据页。数据页分为历史数据页和索引数据页2种类型。
历史数据页中存放位号的历史数据。一个位号的历史数据可存放在多个页面上,但一个页面不可存放多个位号的历史数据。同一个位号的历史数据可能分散在不连续的数据页内,这些不连续的数据页通过时间索引链接在一块,于是形成同一位号的历史数据链。历史数据链中的数据是以时间顺序排列的。时间索引页为测点历史数据建立一段顺序时间索引,为了提高查询速度,一个时间索引页中保存多个时间索引。每个时间索引都对应着本文件内一个历史数据页。同一时间索引页中存放的均为相同位号数据页的索引,同位号诸多索引页之间通过某种机制前后链接在一起形成索引链。并且这个索引链是跨文件的。如此通过对索引链的前后查找,就可以定位到某待查询时间的历史数据所在的页,然后再通过二分查找或者顺序查找的方式,定位到该数据页中那个要查找的历史数据。
4.1.2 管理信息文件
历史数据库的管理信息文件主要记录那些正在被实时数据库使用的历史数据文件。其主要目的是快速定位到某时间段对应的历史数据文件。一个实时数据库项目中一般有一个管理信息文件,另外还有很多个历史数据文件。管理信息文件与历史数据文件如图3所示是一对多的关系,但并非每一个历史数据文件都在管理信息文件中有记录。
4.2磁盘历史数据缓冲区
磁盘历史数据缓冲区是为了防止频繁地写磁盘而开辟的一块内存区。将要写入到磁盘的历史数据,首先放在缓冲区中,当缓冲区中累积了一定数量的历史数据时再一次性写入历史数据文件中[8,9]。
系统中配置有系统参数作为存盘时间。当存盘时间到达后,一次写入磁盘历史数据库。系统结束运行时,要将历史数据缓冲区的历史数据写入历史数据文件。用户访问历史数据时,系统首先检查历史数据缓冲区是否有用户需要的历史数据,然后再查历史数据库文件中是否有用户需要的历史数据。
用户通过系统参数可以设置历史数据库缓冲区的大小,历史数据缓冲区设置得比较大可以加快查找近期历史数据的速度,但同时内存开销也加大。最好根据本机物理内存的容量,动态设置缓冲区大小。
5 磁盘历史数据库实现
磁盘历史数据库是实时数据库的一个子模块,它主要是由实时调度模块来驱动。本课题中是以动态链接库的形式实现的。
5.1磁盘历史数据库的总体架构
磁盘历史数据库主要是为实时模块提供了对磁盘历史数据进行操作的功能。该模块主要针对上面所提到的2种文件:管理信息文件和历史数据文件。其内部大体框架以及调用流程如图4所示。
其中,接口模块负责为外部调用模块提供接口函数。通过这些接口,磁盘历史库的功能暴露给外部模块。读写操作模块是整个历史库的核心模块,提供了最为核心的读写功能,其上层接口模块中一些主要的功能函数,实际上都是在对读写模块进行封装。由于写数据的实现相对比较复杂,在此将其提出来做详细描述。写数据函数实现大致如下:
…
pLastData = GetLast(pCompress);
if ( pLastData == NULL )
{
//追加模式
return Append(pCompress,pData, nCount);
}
if (IsTimeLessThan(pLastData, pStartData) )
{
return Append(pCompress, pData, nCount);
}
if (IsTimeLessThan(pEndData, pLastData) )
{
//插入模式
return Insert(pCompress, pData, nCount);
}
//中间插入模式
return MidAppend(pCompress,pData,nCount);
…
首先,从存放在磁盘上的压缩结构中获取历史数据文件中某测点的最后一个数据。如果不存在该数据,则表示系统刚初始化,就直接追加数据。同样,如果待存入这批数据的起始时间在磁盘最末历史数据之后,依然采用的是追加模式。
除此之外,还有另外2种情况:一是待写入这批数据的结束时间在磁盘最末历史数据之前;二是待写入这批数据的起始时间在磁盘最末历史数据之前,但结束时间在磁盘最末历史数据之后。对于这2种情况,前者采用插入模式写入数据,而后者采用中间插入模式写入数据。所谓的中间插入是在删除部分已有数据的前提下进行的一种特殊追加方式。 由于篇幅问题,上述几种数据写入模式的具体流程在此不再做详细描述。
另外,数据页模块负责对缓冲区的数据页面进行解析,其调用了压缩模块的功能。管理信息文件访问模块和历史数据文件访问模块,分别提供了对管理信息文件和历史数据文件的访问功能。
5.2磁盘历史库重要功能模块详述
5.2.1 读写操作功能模块
读写子模块主要是提供了对历史数据的读写操作功能。通过该模块可以读取到某一段时间内的所有数据。写操作方面,该模块对传入的数据做相关的压缩处理,然后调用下层的一些模块将数据写入到历史数据文件。
读历史数据函数的大致形式如下:
int GetData(Time *pStart,Time *pEnd,HisData *pData )
要获取数据的时间段通过 pStart、pEnd 这2个输入参数传入,而 pData 作为一个输入/输出参数,传入的是要获取的测点标识号等相关信息,而得到的是对应时间段的历史数据。
写历史数据函数的大致形式如下:
int WriteData( HisData *pHisData)
待写入的历史数据列表由 pHisData 参数传入,在函数内部根据时间属性判断进行的是追加操作还是插入操作,从而往磁盘文件新增历史数据。读写模块给历史库提供了最核心的功能,因此,它是最为关键的一个模块。在本历史库中的源码中该模块占据了5 000行左右的代码,是一个很大的模块。
5.2.2 压缩模块
在工业控制过程中,测点将产生大量实时数据,由此产生的历史数据是海量的,如不做任何处理直接存储到磁盘历史库,将占用大量空间[10,11,12]。因此,压缩处理是磁盘历史库中一个很重要的功能。
磁盘历史库中压缩处理分为有损压缩和无损压缩2种。这里所指的有损压缩实际上就是一个筛选数据的过程,通过有损压缩过程,磁盘历史库从大量数据中筛选出哪些是需要保存到历史数据文件的,哪些是可以丢弃的。而无损压缩则是将原始数据以某种编码方式来存储,以达到节省存储空间的目的,这种压缩方式是可以通过解压缩来恢复数据原貌的[13,14,15]。磁盘历史库对不同数据类型采用的压缩方式是不尽相同的。主要分为浮点型数、开关量数以及字符串数这3种来进行处理。
a. 浮点型数据的压缩方式。本磁盘历史库中针对浮点型数据采用了旋转门压缩算法。在进行数据压缩时,旋转门压缩算法将比较新的实时数据点和前一个被保留的数据点之间的偏移,如果新的数据点和前一个被保留的数据点所构成的压缩偏移覆盖区的区域可以覆盖前面所有的数据点时,将没有任何数据点被保存。反之如果有任何一个数据点落在压缩偏移覆盖区外,则新数据点的前一个点将被保留,同时整个压缩偏移覆盖区将被重置,并且以新数据点的前一个点作为新的起点。而上面所说的压缩偏移覆盖区实际上是一个平行四边形,其起点是前一个被保留的数据点,终点是最新的一个数据点。平行四边形垂直方向的边长是压缩偏移量的2倍,压缩偏移量由测点组态决定,可以为每个测点指定其合适的压缩偏移量。图5说明了旋转门压缩算法的原理(y 为值坐标,t 为时间坐标)。
浮点型数据压缩处理的实现,即逐个判断所有的历史数据点,哪些是需要写入到磁盘文件,哪些是可以丢弃的这样一个过程。在下列这几种情况下,数据是需要写入到磁盘文件的:当前点为本测点的第1个数据时;当前点质量戳与前一点质量戳不一致时;当前点未通过旋转门压缩检测时。
b. 开关量数据的压缩方式。开关量数据采用的是变化即保存方式,这也是一种无损压缩方式,但其原理和实现都比浮点数所使用的旋转门压缩算法更简单。压缩模块在处理每个原始开关量数据时,都会与历史数据库中相同测点的最后一个历史数据记录做比较。如果当前开关量数据和最后历史数据记录的值相同则滤过该数据,不将其保存进历史数据文件;反之,则保存进历史数据文件,并将该数据设为最后历史数据记录。如一串原始开关量数据为11101001,经过开关量压缩处理,最后得到的要存入到磁盘文件上的数据就为10101。
c. 字符串数据的压缩方式。字符串数据是一种比较特殊的数据类型,单个数据的长度可能比较长。因此,有可能需要进行2次压缩。针对原始的字符串数据,首先通过有损压缩筛选出需要保存的字符串历史数据。然后再根据需要保存的字符串历史数据的具体情况选择性地做无损压缩处理。并非所有的字符串历史数据都需要做无损压缩,只有针对那些比较长的字符串,无损压缩才有意义。当然,经过无损压缩的历史数据从磁盘文件读出来时,必须做相应的解压缩操作,以恢复数据原貌。字符串数据的压缩过程实现大致如下:
…
if(strcmp(pData->Value,(pCompress->pLastSave)->strValue)==0)
{
//与上一记录数据内容相同,则不保存
return;
}
//记录最后保存数据信息
Copy(GetLastSaveData(pCompress),pData);
if(pData->Length>=20)
{
//执行无损压缩
ExecuteZlibCompress(&ComprData,pData);
//保存历史数据
AppendData(pWriteInfo,&ComprData);
return;
}
//保存历史数据
AppendData(pWriteInfo,pData);
return;
…
待处理数据进入之后首先与磁盘上记录的上一次保存数据进行比较,如果值相同则不进行任何存储操作。反之,值不相同,则需要将该数据保存至磁盘历史文件,并再对最后保存数据信息做修改。另外,如果待保存字符串数据过长,进行无损压缩处理是有必要的。至于如何衡量字符串是否过长,这与采用的无损压缩算法有关,需要通过相关测试获取。本文中所描述的历史库采用了 zlib 无损压缩。通过测试表明,采用20字节作为字符串长短衡量标准是比较合适的。
压缩模块有大约1 000行的代码。在这个模块中根据不同的数据类型进行不同的压缩操作,这是本历史库的一个特点。实际上,本历史库中数据的压缩效率也是很高的。
5.2.3 数据页存取模块
历史数据文件采用页面存储,数据页存取模块的主要功能是对这些页面进行操作。其中,页面分为历史数据页和数据索引页2种,这2种页面的大小不一定相同,页面结构也不相同。因此,对这2种页面的解析方式是不一样的。数据页存取模块代码量约2 000行,这部分主要负责解析这2种页面。
6 结语
历史数据处理是实时数据库中一个至关重要的功能。文中论述了实时数据库系统历史数据处理的详细过程,以及磁盘历史数据库的实现技术。
摘要：实时数据库(RTDB)是传统数据库技术与实时系统相结合的产物,是厂级信息监控系统(SIS)的核心。历史数据是系统定时从实时数据库中采样,保存到历史数据库中的数据,用户需要时可随时从历史数据库中访问历史数据。历史数据库包含内存历史数据库和磁盘历史数据库。内存历史数据库关注的是测点近期数据的组织方式;磁盘历史数据库管理的对象是历史数据文件和管理信息文件。对磁盘历史数据库的文件结构、缓冲区进行了描述,并详细阐述了其总体架构及重要功能模块(读/写操作、压缩、数据页存取)的实现技术。
VFP环境下实时数据采集的实现 篇5
----服务程序包括二个基本部分：其一是WinMain入口函数，它主要完成一此初始化任务，建立一个名为hwnd的原始数据显示窗口，服务程序名为PFBCdas。其二是应用程序功能函数MainWndProc。下面是程序清单（因篇幅关系，在此省去WinMain函数）。
#define AD_Interval 1000 //采样周期为 1000ms
#define base 0x280 // A/D采样板基地址
/* base+k (k=1,2,…14)为A/D板各寄存器地址 */
#include
#include
#include
#include
#include
#include
#include
#include
#include
int i, j, k , AD_Status, idTimer;
int AD_Data[8][16]; // A/D数据存储单元
int DdeAdviseStatus=0;
char buf[64], DDEbuf[2048]; //数据暂存缓冲器
char szAppName[]=“PFBCdas”; //服务程序名
char szDdeTopic[]=“AD001”; //主题名
char szDdeItem[]=“DATA”; // 数据项名
long FAR PASCAL _export MainWndProc(HWND, UINT, UINT, LONG) ;
long FAR PASCAL _export MainWndProc (HWND hwnd, UINT message, UINT
wParam, LONG lParam)
//应用程序功能函数
{
ATOM aAppName,aTopic;
ATOM aItem;
GLOBALHANDLE hDdeData;
DDEDATA FAR *lpDdeData;
static HWND hwndClient;
switch (message)
{
case WM_CREATE:
idTimer=SetTimer(hwnd,NULL,AD_Interval,NULL);
//打开定时器
outportb(base+11,0x10); //选择软件触发方式
outportb(base+9,1); //选择输入信号放大倍数为10
outportb(base+14,0);
outportb(base+13,0); //清A/D完成位
outportb(base+10,0); //选择通道0
return 0;
case WM_TIMER:
for(i=0;i<6;i++)
for(j=0;j<16;j++) //采样点为6*16=96个
{
outportb(base+13,j);
outportb(base+10,i);
outportb(base+12,0); //启动A/D转换
do AD_Status=inportb(base+5);
while ((AD_Status&0x10)==0x10);
//判转换是否结束?
AD_Data[i][j]=(inportb(base+5)&0x0f)*256+inportb(base+4);
/* 读A/D转换后的数字值 */
}
_strdate(buf); //取采样日期
strcpy(DDEbuf,buf);
strcat(DDEbuf,“,”);
_strtime(buf); //取采样时间
strcat(DDEbuf,buf);
strcat(DDEbuf,“,”);
for(i=0;i<6;i++)
for(j=0;j<16;j++)
{
char temp[32];
strcat(itoa(AD_Data[i][j],buf,10),“,”);
/*各采样数据之间以逗号分隔*/
strcat(DDEbuf,buf);
}
if(DdeAdviseStatus!=0) //如果建立了DDE服务
{
aItem = GlobalAddAtom (szDdeItem) ;
//添加DDE数据项为全局原子
hDdeData = GlobalAlloc (GHND | GMEM_DDESHARE,
sizeof (DDEDATA) + strlen (DDEbuf)) ;
/*给采样数据分配全局内存块*/
lpDdeData = (DDEDATA FAR *) GlobalLock (hDdeData) ;
lpDdeData->fResponse = 0 ;
lpDdeData->fRelease = 1 ;
lpDdeData->fAckReq = 0 ;
lpDdeData->cfFormat = CF_TEXT ;
//采样数据为文本格式
lstrcpy ((LPSTR) lpDdeData->Value,DDEbuf) ;
/*将采样数据从缓冲器放至DDE内存*/
GlobalUnlock (hDdeData) ;
if(!PostMessage(hwndClient,WM_DDE_DATA,hwnd,
MAKELONG(hDdeData,aItem))) //发送DDE数据
{
GlobalFree(hDdeData);
//若发送失败，则释放资源
GlobalDeleteAtom(aItem);
}
}
return 0;
case WM_DDE_INITIATE: //DDE初始化
hwndClient=wParam;
实时数据论文 篇6
关键词:数据同步共享锁实时数据监控
中图分类号:TM73文献标识码:A文章编号:1674-098X(2011)05(c)-0018-01
1 引言
在工控组态软件领域,普遍存在一个称作读者写者的问题,即对某些资源的访问,存在两种可能的情况,一种访问必须是排他的,称作写操作;另一种访问可以是共享的,称为读操作。对于一个实时数据监控系统来说,由于Windows是一个多任务抢占式的操作系统,在多个线程共同访问一个数据区的环境下,会产生数据同步的问题。比如:有提供数据的服务程序A和若干界面显示程序B、C、D等。服务程序和显示程序共同使用一块数据内存区E,其中服务程序负责更新内存数据(写操作),而显示程序则定时访问内存区数据(读操作)。假设数据内存区E中变量的数据结构为:
FILETIMEftTime;//时间
DWORD dwValue;//值
那么,在B刚读取完某个变量的ftTime值后,插入了A的写操作,这时候再读取到的dwValue值就和ftTime不一致了。这种不一致的现象必须通过数据同步来避免。所以,对内存区E的读写访问必须作以下两个约束:
1)A正在进行写操作时,B、C、D必须等待该操作完成才能访问E;约束条件(1)
2)B、C、D正在访问E时,A 必须等待该操作完成才对E进行写操作;约束条件(2)
以上约束可以简单的归纳为:读写互斥。
2 一般解决方法
在Windows下,系统提供了事件、互斥量、信号量等核心对象以及一些等待函数来进行多线程同步。单独使用这些核心对象均能够实现读写的互斥。
但是单纯的实现读写互斥并不能完全满足实时监控系统对访问效率的要求。因为读操作的并发并不会引起数据的不同步,为了提高效率,必须在之前的两个约束的基础上增加读写访问的另一约束,即约束(3):B、C、D能够同时访问E。
3 共享锁
3.1 数据结构
利用Windows内核对象的特性,可以编程实现满足上述三点约束条件的共享锁类。
共享锁的内部数据结构由读事件、写事件、互斥对象和读者计数组成。
其中,读、写事件是一对命名的、手动重置的事件,初始化为有信号状态。事件可以使用Windows Api函数CreateEvent、ResetEvent和SetEvent 来创建、重置和置位。这对事件成员的作用是实现读写的互斥。
共享锁中的互斥对象是一个初始化无所有者的命名互斥量。互斥量可以使用CreateMutex、WaitForSingleObject和ReleaseMutex来创建、进入和离开。互斥对象在共享锁中的作用有两个:对写操作进行保护,保证一个时刻内只有一个线程在进行写操作;在多个读线程中保护读者计数,保证所有读线程中对读者计数的操作都是原子操作。
读者计数实际上是一片命名的内存区,可以用CreateFileMapping和MapViewOfFile来创建和映射该内存区。读者计数用于对同一时刻内的并发读操作进行管理。
3.2 读写操作流程
3.2.1 写操作
数据服务A在对数据内存区E進行写数据操作时,首先重置写事件。这时候写事件为无信号状态,这就意味着B、C、D等读线程将在“等待 写”这一步中挂起,不再进行读操作。接下来A将等待读事件,如果之前时刻已经有若干线程在进行读操作,那么A将等到这些操作完成后进入互斥对象。这就意味着A已经独占了内存区E这块资源,可以放心地进行写操作了。
在A完成写操作后,首先离开互斥对象,释放之前独享的这块资源,再置位写事件,让B、C、D等读线程结束挂起状态,进行读操作。
3.2.2 读操作
假设B线程某一时刻想以读者的身份访问数据区,B首先等待写事件,如果写操作正在进行,那么B将被挂起直到写操作完成。接下来B将访问读者计数,如果读者计数为0,B将重置读事件;否则意味着在前一时刻已经有另外的读者(C或者D)已经重置了读事件,B将读者计数自增后直接进入读操作。当然,在访问读者计数的整个过程中都使用互斥对象对计数进行保护。
在完成读操作后,B再次访问读者计数字,如果发现此时B已经是最后一位读者(计数=1),B将置位读事件,计数自减后退出。
4 比较和结果
4.1 实验平台的搭建
创建一个写者线程,三个读者线程,同时运行。在每个线程内,记录下每次操作的性质(读或写)、操作时间和操作者(线程),保存到日记文件中,是为原始数据。分三次进行实验:1无数据同步;2使用互斥对象进行数据同步;3使用文中所述共享锁进行数据同步。
4.2 比较和结果
未使用锁情况下,由于Windows是抢占式的操作系统,A、B、C、D四个进程将对E资源进行无序的竞争。
使用了互斥锁情况下,在B、C、D的读周期内不可能再出现值被A修改的情况。但是这样的数据同步的缺陷也是明显的:在B的读周期内A、C和D都在挂起等待状态,消耗了不必要的时间;另外,在这样的数据同步模式下,读者和写者的地位是平等的,A作为数据的提供者却必须要和B、C、D同等的去抢占资源,而且读者越多负担越重,是一种很不合理的作法。同样,在B、C、D的读周期内数据不会被A改动,解决了数据同步的问题。另外,B、C、D可以并发进行,因为多个读者访问不会对资源E造成破坏,避免了A不必要的等待时间,提高了效率。
更重要的是,共享锁对读者和写者的权限进行了区分:写者优先于读者访问共享资源。这是因为任意时刻下A想对资源E进行写操作时都会重置写事件,这时试图进行读操作的其他读者就被迫进入等待状态,A只需要等待前一时刻已经进入读周期的进程完成操作。这就保证了服务程序A的工作效率,也就是保证数据的实时性。
5 结语
综上所述,共享锁具有同步数据和优先保证写者效率的工作特性。这些独特的工作使得这样的共享锁在工业控制级别的实时软件系统中具有很重要的现实意义。在实时数据库、实时监控系统、数据报警系统等领域的软件开发中具有广泛的应用前景。
参考文献
国内电网实时数据集成应用综述 篇7
随着电力系统不断发展,国内电网建立了多个实时或者非实时的监视、控制和管理系统。这些实时或者非实时系统对电网安全生产、经营和管理起到了不可替代的作用。但已建成的相关应用系统,多为不同时期分别进行建设或由不同专业负责建设的,由于缺少总体设计和统一规范,造成系统间数据流向不合理、通信接口复杂;各应用系统数据、网络模型参数得不到共享,增加了系统参数和数据维护的难度,制约了信息化水平的进一步提高。各系统之间相对孤立,信息的可见性和数据的可用性较弱,信息传递的容量、效率无法得到保证,存在“信息断层”。随着系统间数据共享需求的不断增加,有必要建立一个统一的实时数据应用集成平台,充分发挥企业实时数据资源的作用。江苏、浙江、上海、山东等地都已经陆续开始了电网实时数据集成应用方面的研究与实践。现从集成应用的范围、规范化及关键技术等方面总结和分析国内各地的电网实时数据应用现状,总结出该研究领域的新思路和新进展。
1 应用集成的范围从调度级向企业级发展
1.1 国网公司发布调度系统数据整合指导方案
调度EMS各子系统的信息共享以及EMS与其他系统的信息交换成为实时数据集成应用的起点。
随着越来越多的实时或准实时应用系统的开发和投用以及安全分区的实施,传统的点到点的网状数据交换手段形成了更加复杂的环境,通过私有接口模式实现点对点方式的数据交换已逐渐被数据中心的理念取代。
国家电网公司在电力二次系统安全防护框架的基础上,研究分析调度机构现有各应用系统的特点,并在考虑数据整合工作实施和今后系统应用发展的基础上,提出了省级以上调度系统数据整合的总体方案,逐步建设适用于安全区Ⅰ、安全区Ⅱ各应用系统的生产控制数据平台以及适用于管理信息大区应用的调度生产数据平台,2大平台协同工作[1]。
各级调度机构已经逐步开展了集数据、模型、图形等为一体的调度综合数据平台的研究和建设[2,3,4]。表1分别描述了南方电网、浙江、江西等地的综合数据平台的应用情况。
1.2 集成实时数据和管理信息的公司级数据中心逐渐出现
调度数据中心解决了调度自动化系统的数据规划和整合,实现了调度自动化系统间的协同。然而它还不能满足其他专业和企业级的生产和管理需求,因此逐渐出现了企业级数据平台的概念。
山东电力2007年从弥补生产自动化监控系统和管理信息系统之间的“信息断层”以及满足“企业级”数据分析和应用的需要,设计了“企业级”的生产实时数据平台,以实现生产实时信息安全交换和共享。生产实时数据平台在满足安全生产和稳定运行的同时,更好地服务于电网经济运行和企业经营。
上海电力公司从面向电网整体的生产管理角度出发,为解决设备与电网网架脱节、设备运维信息与电网运行信息脱节的状况,在实时监控、输配电管理、电力营销等业务系统之上,以IEC61970和IEC61968的公共信息模型(CIM)为基础,建立了全电压等级一体化电网模型,实现了电网设备参数、电网网络拓扑、地理信息、用户信息、实时信息等一体化支撑平台。上海企业级数据中心立足于公司整体,成为整个电网不同系统间的“桥梁”和“纽带”,各类信息在企业范围内达到共享[5]。
由上述案例可以看出,公司级数据中心,立足于公司整体,数据不仅来源于调度系统,还来源于其他部门、其他专业的相关系统;而且数据中心服务于企业整体,各类信息在企业范围内共享。
1.3 调度级和公司级数据中心的协同工作
虽然调度级数据中心与公司级数据中心分别处于2个不同安全区域、为不同用户群提供服务,但2个中心(或平台)密切关联,共同搭建了生产自动化监控系统和管理信息系统之间的桥梁。
在国网公司的调度系统数据整合总体方案中,不仅明确了建立适用于安全区Ⅰ、安全区Ⅱ各系统应用的生产控制数据平台以及适用于管理信息大区(Ⅲ)应用的调度生产数据平台,同时还提出了公司综合信息集成平台,并明确了调度生产数据平台向公司综合信息集成平台传送电网运行和调度生产管理相关信息的数据流向。
2 应用集成和数据集成范围
依据已查阅的文献资料,集成应用的范围或数据集成范围有如下3种代表案例。
a.上海电力从面向电网整体的生产管理角度,集成调度运行管理、设备运行管理和营销管理,形成了包括网络拓扑、设备参数、实时数据、地理信息、资产信息等内容的数据中心。
b.中国电科院从提高电网计算分析的角度,提出了在线与离线数据的整合。
c.南方电网为了满足全局协调控制和在线安全稳定分析的需要,实现了各省调和总调的电网模型和图形的整合。
总结上述案例,从应用角度集成范围归纳如图1所示,从信息类型的角度可用图2描述。
各种不同的案例只是对同一范畴的对象集,从不同出发点、以大小不同的视角、从不同切入点,开始电力信息集成之路。
3 集成应用的规范化、标准化
3.1 调度综合数据平台普遍遵循IEC61970的相关标准[7,8]
IEC61970在调度数据共享中的应用可分为横向和纵向2个方面。横向共享是指本地调度中心内各应用系统之间的数据共享。纵向共享是指不同级调度机构自动化系统之间的数据共享。
浙江金华地调实现了基于IEC61970-CIM/CIS的电网数据异构平台[3]。该平台的数据源自EMS系统,实现了CIM数据库、接口服务程序、GDA服务、基于XML的CIM导入/导出工具和基于CORBA的企业集成总线,为地理信息系统、管理信息系统、电量计费系统和配电管理系统等应用功能提供了标准的电网模型、参数、实时数据和状态估计结果等访问服务。
华东电网建立了基于IEC61970的电网计算、设备模型的调度实时信息管理系统,采用CIM/XML模型文件交换和模型合并等技术,实现了上、下级调度自动化系统间信息资源的共享和分责分级维护[6]。
南方电网为了满足全局协调控制和在线安全稳定分析的需要,基于IEC61970标准,各省调与总调间通过定期传送实时数据断面以及在电网模型或图形发生变化时传输CIM以及与CIM相配套的SVG图形文件,形成全网CIM和SVG图形,为南网新EMS、网省协调AVC、在线预决策、安全预警等其他应用系统提供完整的在线模型[7]。
3.2 公司级综合应用中也已有IEC61970的应用案例
上海电力一体化电网平台以IEC61970和IEC61968的CIM为基础结合管理实践进行扩充,建立了全电压等级一体化电网模型,实现了电网设备数据、电网网络拓扑、地理信息、用户信息、实时信息等的一体化支撑,为各种电压等级设备管理和业务流程的沟通打下了模型基础。
3.3 CIM/CIS的不同应用深度[9,10,11,12]
根据已查阅的文献,在所有调度级综合数据平台和企业级综合数据平台中,都强调遵从CIM/CIS标准。但遵从CIM并不意味着支持CIM的所有方面,也不意味着数据库的结构与CIM的类图完全一致。由于应用背景不同等因素,CIM/CIS有着不同深度的应用。
3.3.1 仅在数据交换时遵循CIM/CIS
有案例只在各应用组件的接口级上遵循CIM,即公用接口的数据表示符合CIM的语义、词法、关系3个方面的要求。
杭州电力局在信息集成的初始阶段,基于CORBA与XML技术,应用CIM对DF8002 SCADA系统进行包装,使之成为遵循IEC61970 Part 4 CIS的GDA和HSDA服务器,所提供的数据采用CIM数据模式。通过此方式为其他系统提供了CIM/XML电网模型、CIM/SVG图形、GDA/HSDA服务,解决了数据一致性问题,使企业各部门、各业务使用的数据保持了统一性、完整性、可靠性。
在集成应用初期或应用系统对外信息共享需求较少时,采用此种方式。此种方式简单快捷,但不同类型数据间关联的实现相对复杂。
3.3.2 按CIM存储数据
对CIM/CIS的深入应用是不仅在接口层面,而且在数据存储层面基于CIM标准。这种应用涉及到CIM建模和模型扩展。一般在领域CIM建模和模型扩展相对成熟的情况下按CIM存储数据。目前新建的调度数据平台一般都按CIM存储数据。
河南电力公司借鉴了CIM,对电力综合数据平台的数据流进行了规划。首先,把握CIM中各类之间的关系,了解重要类的各个属性,列出现有系统中与CIM实体的属性相对应的参数,对CIM中没有而项目中所需要的实体或者属性,根据实际需要,在CIM中进行建模或扩展。
西北电网的调度数据平台系统从EMS系统将电网模型、参数数据按照CIM格式导出,电网模型和部分运行信息按IEC61970 CIM方式存储。
南京地调基于CIM和IEC61970系列标准设计出输电网模型,并扩充IEC61970 CIM使之能够表达配电网模型,定义电网运行数据XML交换格式。
3.4 CIM建模研究情况
根据文献资料,2006年起清华大学、浙江大学以及浙江电力公司已开展多个领域的建模研究。
文献[13]在对现有AVC系统进行详细分析的基础上,抽象出电压控制器的概念,利用递归组合的方法描述分级电压控制的层次结构,通过继承和关联的方式将电压控制器模型与CIM中现有的模型相结合,充分利用其中已有的信息,完成对AVC系统CIM的详细设计。
在电力系统中,一些重要设备的附属设备较多,而CIM中模型不可能全面地反映这些附属设备的模型。如在发电机设备中有励磁机、电力系统稳定器(PSS)、原动机调速器等附属设备,这些附属设备无论在实际运行中还是在系统的仿真计算中,都有重要的作用。
文献[14]在对励磁系统进行详细分析的基础上,抽象出励磁系统的模型,通过继承和关联的方式将励磁系统模型与CIM中现有的模型相结合,充分利用CIM中已有的信息,完成了基于CIM的励磁系统详细建模。
文献[15]在继承CIM中原有开关类模型的基础上,对配电系统中的重合器、分段器、开闭所、环网柜及分布式电源建立了CIM,扩展了CIM在配电系统中的应用。
4 集成应用的关键技术
调度级数据中心、公司级数据中心虽然数据来源、服务对象不同,但2个数据中心的核心技术基本相同。相关技术的实现方案趋于成熟。
4.1 架构
尽管当前的数据中心架构形式多样,但其核心技术是基本相同的;其主要模块也是相似的,如:基于组件技术(如CORBA)的集成总线、基于CIM的数据模型、基于CIS的接口、基于SVG的图形导入导出、基于CIM/XML的电网模型拼接等。
4.2 组件技术
目前,主流对象中间件技术标准有OMG公司的CORBA、Microsoft的COM/DCOM、Sun公司的EJB等。3种技术的核心思想都有一定的共通之处,彼此具有相当的兼容性。
其中,CORBA适合于分布式对象环境,具有平台、位置和语言的无关性,而且其功能完整性、发展成熟性也是最好的[16]。目前浙江杭州、江苏南京、江西、山西都有CORBA技术应用的成功案例。从上述成功案例中,可以得出这样一个结论:只要选择合适的组件粒度和高效的CORBA中间件产品,CORBA完全能够满足调度自动化集成系统的性能要求;而调度自动化集成系统可把CORBA作为整个系统的集成框架,合理发挥CORBA的各种强大功能和服务,从核心上保证IEC61970标准的实施。
4.3 数据模型
电网运行数据中心不仅要考虑电网实时数据、电网参数数据、网络拓扑数据、发电和负荷数据、机组自动控制系统数据以及系统统计分析结果,而且对海量各类数据的存储、提取需要规范统一的、可扩展的数据模型。CIM定义了电力系统模型的层次结构,为应用间共享的信息提供一个公共的语言。
4.4 全电网模型
我国电网的运行和管理具有典型的分层分区的特点,因此基于CIM形成全电网模型是实现信息共享和集成的基础。全电网模型的建立将使得各应用系统可以以标准接口的方式获取任意电压等级范围内的电网模型、拓扑和设备参数。技术处理上涉及电网模型的拆分与拼接以及模型的导出。
4.4.1 模型的拆分与拼接
电力系统模型的拆分用于只对整个系统的部分地区或某电压等级以上的系统进行分析研究。可以根据电压等级或区域进行拆分。
全电网模型的建立实际上就是完成模型的拼接过程,基于IEC 61970规范的CIM/XML模型导入功能是模型拼接的基础,而模型拼接的关键前提是保持边界模型的设备命名一致。
为了最大限度地不影响EMS、DMS以及涉及到的其他自动化系统,可以采用指定边界设备定义的方法来实现模型拼接。各个系统均导出全模型,在综合数据平台上进行拼接的时候首先根据事先设定好的边界设备进行拓扑分析,将那些在边界范围之外的设备全部舍弃,从而得到只包括某区域范围内部以及相应边界设备的模型,再根据边界设备名称一致的特点来进行模型拼接,最终得到全网的大模型。
4.4.2 电网模型的导出
由于XML是独立于任何体系结构、独立于任何语言的数据格式,其中立性非常适合应用于系统集成中的信息交换。将SCADA电网模型导出为CIM XML/RDF格式,方便不同应用、不同系统间的数据交换。
根据不同需要,电网模型按照全网模型、拆分模型、增量模型3种方式导出。
4.4.3 案例
南方电网基于CIM实现电网全局模型,一旦省调EMS电网模型发生变化,CIM/XML导出模块导出CIM,包括电网结构、参数和量测映射关系,一旦省调EMS图形文件发生变化,SVG图形导出模块导出与CIM相配套的SVG图形文件,全面实现基于CIM的电网模型的拼接。
4.5 图形导入、导出
SCADA系统的应用只有将数据和图形结合起来才具有一定的意义,需要在已有系统上提供相应的图形导出模块,同时综合数据平台则利用图形导入模块实现对图形的接收。
SVG是由W3C开发的一种开放标准的文本式矢量图形描述语言,SVG图形交换和CIM/XML文件一起使用能正确识别和表达图形上的设备和动态数据点。数据中心的图形的导入、导出目前基本上都是基于SVG技术[17]。
SVG图形导入、导出过程具体实现如下:
a.图形文件的接收方负责将图形文件转换到自己的图形环境中,接收方根据图形文件提供的关键信息(如设备类型、地点、旋转等)用自己的绘图包来画出图形;
b.底层的CIM数据库与图形表现一致,连接关系已保存在底层的CIM数据库中,因此不需要交换;
c.菜单往往针对特定应用,因此菜单不作为图形的一部分交换;
d.交换是分层次的,例如大视图、连接关系、动态对象、注释/符号以及减少混乱的方法。
4.6 数据对外接口技术
数据对外接口经历了从专用的API到CIM/CIS。
CIS包含2个层次,Part 4XX CIS规范是与具体实现技术无关的规范,这个层次主要提出“如何交换”和“交换什么”,Part 5XX提供如何将Part 4XX CIS规范映射到特定的底层实现技术。目前,2个层次都尚未完善,各类具体技术映射(如CORBA映射、EJB映射等)标准尚未形成[18]。
为了方便将来开发新应用,并使以前投入运行但仍有效工作的系统向外提供标准服务,需要对已有系统进行包装,使之提供符合IEC61970的接口,包括GDA、HSDA等。第三方用户可使用这些标准接口灵活地开发新应用,或者使用这些服务进行消息传递,实现RPC形式的数据交换。可采用CORBA实现GDA、HSDA服务器。CORBA的使用允许应用构件在可执行级上互操作。
清华大学应用软件的对外接口就实现了从专用API接口到IEC61970-CIM/CIS标准的过程。
基于专用API,清华大学应用软件已在我国60多家地区级以上电网调度中心运行。这是一种1对N的接口模式,如图3所示。
2003年后,清华大学采用了IEC61970-CIM/CIS标准进行接口,图4为新的接口模式示意图。
在这种新模式下,接口采用标准的软总线方式,无需对每个厂家做私有接口,开放性好。目前基于这种标准接口模式,清华大学的应用软件在江苏省调、广东省调和金华地调等调度中心都得到了成功应用。
5 结论
分析已查阅的文献和应用案例,电力信息集成应用的发展趋势有3大特点:全电网、两中心协同以及遵循CIM/CIS标准。
a.“全电网”总结于集成应用的横向、纵向的数据来源和使用范围。电力信息集成应用由面向调度员、操作员的调度数据中心,发展为面向整个公司,服务于调度、营销、生产、发策、基建等不同部门的需求的公司级数据中心。全电网数据中心的数据不仅仅包含生产实时数据,还包含电网模型、图形、地理信息以及各类管理信息,同时在全电网数据中心建立起生产自动化监控系统和管理信息系统之间的桥梁。我国电网的运行和管理具有典型的分层分区的特点,上下级调度运行数据的整合已成为必需。
b.调度级数据中心与公司级数据中心分别处在2个不同的安全区域,面向不同用户,公司级数据中心中的调度系统的数据应该由调度级数据中心传递的,保证了相同数据的一致性。2个数据中心之间不可替代。
红外相机数据高速实时存储技术 篇8
在航天航空技术领域,经常需要采集大容量高精度的红外图像信息,对于有些信息专业人员无法现场进行数据处理,只能先存储备份,然后读取分析采集到的图像数据并还原显示在计算机上。由于图像传输速度快、容量大,而Flash的存储速度一般不超过40 Mbyte/s,本文充分利用乒乓缓存的思想对高速数据流进行实时无缝缓存,避免了图像快速传输过程中的丢数现象,利用流水线技术写Flash,解决了Flash写入速度的限制。与传统的存储系统相比,该系统具有存储速度快、可靠性强、稳定性高、适用范围广等优点。
1 系统组成及设计框架
系统采用Altera公司Cyclone II系列EP2C35F484C6芯片作为主要控制核心[1],红外相机捕捉到的视频图像信号通过LVDS接口电路进入解码模块,经FPGA处理过的图像数据通过乒乓结构实时无缝缓存,最后用流水线写Flash技术将图像数据存储在NAND Flash闪存阵列。存储的图像数据在需要时可用分析软件通过FT245控制的USB 2.0接口读出并将图像显示在计算机上,系统组成框图如图1所示。
1.1 图像解码模块
本系统采用National公司差分接收芯片DS90CR216作为视频解码芯片,经LVDS接口电路解码后的信号主要有帧同步信号(vsync)、行同步信号(hsync)、像素时钟(mclk)以及8位数据,其中,像素时钟为29.5 MHz,行同步周期为64μs,高电平有效,每行有384个有效像素,帧同步周期为20 ms,高电平有效,每帧有289行有效数据,图像数据在时钟上升沿变化,因此选择2片128 kbyte的SRAM即可满足要求。解码后图像信号时序如图2所示。
1.2 数据无缝缓存设计流程
乒乓缓冲技术是FPGA设计中最常用的一种数据缓冲方法,其最大的特点是能实现实时无缝缓冲与节约缓冲区空间[2]。
本系统每秒传输50帧图像,每帧期间帧同步高电平时间约为18.5 ms,低电平时间约为1.5 ms,如果在帧同步低电平1.5 ms的时间内从SRAM中将数据转存至Flash,会产生丢数。因此,为了给数据处理单元赢得更多的处理时间[3],采用的乒乓缓冲模块工作流程为:当帧同步信号为高电平时,将经过FPGA处理过的图像数据写入SRAM1,同时地址计数器1开始递加计数,此时地址计数器的值一方面为FPGA数据处理模块提供触发参考,另一方面也为缓存空间提供了参考。当帧同步为低电平时,FPGA控制乒乓缓存逻辑切换总线开关,开始选择SRAM2为写空间,将SRAM1切换为读空间以读取缓存在SRAM1中的图像数据,此时地址计数器1开始递减计数,当SRAM1中的数据全部读出后,地址计数器1计数到0。当帧同步信号再次变高后,将图像数据写入SRAM2,地址计数器2递加计数,等待帧同步为低电平时,切换读写信号,选择SRAM2为读空间,SRAM1为写空间,开始读取SRAM2中的数据同时地址计数器2的值开始递减计数,同样当SRAM2中的数据全部读出后,地址计数器2计数到0。待帧同步又一次为高电平时,将图像数据写入SRAM1中,地址计数器1开始递加计数。如此循环切换读写空间,将缓存在2片SRAM中的数据读出并存入Flash中。乒乓操作读写时序如图3所示。
2 Flash阵列流水线存储流程
2.1 芯片简介
选用三星公司容量为1 Gbyte的闪存K9K8G08U0A,它由8 192个存储块组成,每个存储块分为64页,每页容量为2 kbyte,其外部有8个I/O引脚和6个信号管脚,而这8个I/O脚既是命令和地址的输入引脚,也是数据的输入输出端口。该闪存是一种高密度非易失性的存储器,主要特点为:1)读、写(编程)操作均以页为单位,擦除以块为单位。2)读取每页时间为20μs,页编程的典型时间是200μs,块擦除的典型时间是1.5 ms。3)页寄存器写入最低时间是50μs,页编程的最大时间是700μs,块擦除的最大时间是2 ms。由于每次进行页编程之前都需要写页地址,不难计算出写一页所需时间为250~750μs,写入的速度约2.600 0~7.812 5 Mbyte/s。实验证明,页编程的时间正是限制Flash存储速度的关键因素,因此在对其进行页编程操作时采用流水线技术来实现高速大容量Flash的存储[4]。
2.2 Flash存储设计流程
本系统所采用的流水线技术主要分为3个步骤实现:1)向Flash加载编程指令、地址以及数据;2)待加载完成之后,Flash芯片会自动执行将载入到页数据寄存器的数据写到内部存储单元的编程操作[5];3)当自动编程结束后,由FPGA下发“70h”读状态指令以检测Flash的I/O口最低位是否为“0”,如果是,表示编程成功,页计数器递加并继续对下一页编程,当页计数器从0加到63后,页计数器清0,块计数器加1,继续进行页编程操作,当块计数器递加至8 192块时,停止对Flash的页编程操作,等待上位机的读Flash指令。流水线存储的示意图如图4所示。
由于每次对Flash加载数据和地址后总是有大概200μs以上的时间花费在芯片编程上,所以可用多片1 Gbyte的Flash组成流水线工作模式:在第1片加载完成执行编程时可以加载第2片Flash,待第2片Flash编程时又加载第3片Flash,依此操作执行,实现时间的复用,缩短了Flash阵列的有效页编程时间,从而提高了写Flash的整体速度。如果工程项目要求写Flash的速度应为60 Mbyte/s,用5片Flash组成流水线操作模式,那么每片的速度应为12 Mbyte/s,经计算加载一页数据到Flash寄存器的时间大概为162.76μs,而700μs÷162.76μs≈4.3,所以采用5级本系统的流水线技术是可以满足设计要求的。
3 实验结果
本系统经多次实际存储红外相机捕捉视频图像的实验,用读数软件从Flash中将数据读取出来后再经过Matlab处理还原,验证了系统的可行性和可靠性。图5为捕捉到的一张男士挥手的红外图。
4 小结
实验结果表明,本系统具有以下优点:1)以FPGA为逻辑控制核心,采用乒乓缓存模块将红外相机下发的高速大容量数据进行缓存能避免因传输速度太快而出现数据丢帧的现象。采用流水线阵列存储,打破了传统存储方式下Flash存储速度不能超过40 Mbyte/s的束缚,实现了高速大容量存储技术的突破。2)系统占用体积小,成本低,硬件电路简单,调试方便,能完成大量视频数据的无缝缓存和实时存储。3)为高速大容量数据可靠记录、高速实时准确存储提供了有效的技术方案,并在多次实际应用中以其稳定、可靠的性能得到广泛的应用。
摘要：介绍了一种高速大容量固态存储器的组成机制和存储技术,以FPGA为逻辑控制单元,通过LVDS接口电路将红外相机采集到的图像数据经过乒乓结构实时无缝缓存,利用流水线写Flash技术提高了Flash写入的速度,可通过扩展Flash阵列来满足速度更高容量更大的存储要求。可用FT245控制的USB2.0接口读取Flash中的数据并上传至计算机,最后用分析软件可以清晰看到拍摄结果。结果表明,该系统稳定可靠地存储了高速传输的图像数据,具有较强的可行性和实用性。
关键词：现场可编程门阵列,乒乓结构,流水线,USB2.0
参考文献
[1]宋海吒,唐立军,谢新辉.基于FPGA和OV7620的图像采集及VGA显示[J].电视技术,2011,35(5):45-47.
[2]姚远,李辰.FPGA应用开发入门与典型实例:修正版[M].北京:人民邮电出版社,2010.
[3]谭树人,张茂军,徐伟.多传感器同步图像采集系统的设计[J].电视技术,2006,30(9):84-87.
[4]杨海涛,苏涛.基于FPGA的高速大容量固态存储设备设计[J].国外电子元器件,2007(5):68-72.
实时数据论文 篇9
为了解决上述问题,将实时数据库引入管道监控系统,实时数据库系统能够提供高速、及时的实时数据服务,能够有效的集成异构监控系统,在管道监控系统运行过程中,实时记录监控数据的运行情况,通过对输油管道监控过程的关键数据(温度,压力,流量)进行实时监控分析,随时随地掌握输油管道的运行情况,及时处理输油管道中出现的问题,使管道平稳进行输油。
1 实时数据库
实时数据库是连接底层控制网络和上层管理信息系统网络连接的桥梁,是工控系统运行的核心部分,具有海量的存储数据,丰富完整的信息量等特点,其最大的优点是实时性强,可以实现最新的数据库状态、时间一致的数据值和及时处理事务,企业可以通过在工控组态软件中的实时数据库系统,进行质量监控、先进过程控制、计划调度、经营决策等,在工控组态软件中的实时数据库的结构如图1所示,可以看出,在结构上,实时数据库与传统数据库类似,最大区别在于调度和事务管理方面。
2 管道实时监控系统分析
实时数据库是管理和维护实时数据及与其相关的信息,通常包含以下功能特点:良好的数据模型,数据库组态,现场数据采集,数据检索机制,访问调度和并发控制机制,供基于优先级的数据访问,滚动存储机制,预处理机制,自动更新机制,支持不同类型的事务,补偿机制,动态汇总机制和人机界面等功能,为了能在管道实时监控系统中更好支持高速数据访问和实时应用要求,文中选用了PI(Plant Information)实时数据系统,它是由美国OSI软件公司开发的实时数据系统,在系统中,可以对集成到系统中的所有现场运行数据进行监控、挖掘、分析和存储,并能实时动态显示输油管道实时运行情况,这有利于企业管理人员及时准确地掌握输油管道运行状况和各种信息,为他们做准确的决策提供帮助,此外,其还是连接上层企业信息管理系统和输油管道数据采集设备的桥梁,基于此,根据输油管道的需求情况和PI实时数据库特点,设计的系统架构如图2所示。
3 实时数据库在管道实时监控系统中的应用
PI实时数据库提供实时数据、海量历史数据和报警服务,并通过完善的人机界面软件以及管理配置软件,完成对数据的采集、存储、查询、显示和分析的功能。
3.1 数据库的功能模块
系统中,对于经常变化的实时数据(如DO、DI、D/A、A/D值),这些数据每个采样周期都更新,采用内存缓冲区存取加快了存取速度;对于非共享型数据(如组态软件的组态参数),这些数据不需要经常更新,可以采用文件管理系统存取,减轻了系统负担;对于输油管道状态的历史数据,由于其数据量非常巨大,采用关系数据库SQL Server存取。
采用面向对象编程(OOP)技术对实时数据库进行设计,采用平衡二叉树的数据结构来组织内存实时数据,提高对实时数据库的查询、插入、删除和更新的效率,此外,将管理程序的所有功能封装成一个专用的实时数据库类,通过对这些接口函数实现对各种功能操作,如:读写数据函数,事故处理函数,报警函数,计算函数,显示链接函数,初始化函数,基本操作函数和数据采集函数,具体实时数据库类如图3所示。
3.2 实时数据库的事务调度系统
管道实时监控系统运行后,要同时进行多个事务调度处理,如DCS数据采集、越限报警、紧急事件报警、事故处理、图形刷新显示、数据传输、现场监控、数据计算处理、历史数据存取等事务活动,这些事务需要并行处理,必须对实时数据库进行事务调度,使得其同时满足各种约束条件事务请求,实现各个部分协调动作,当前常用的事务调度策略可分为三类:优先级调度算法,时间片轮算法和多级反馈队列调度算法,系统采用优先级调度算法,基于优先级的调度算法主要有如下几种:先来先服务,截止期最早最优先,可达截止期最早最优先,可达截止期最早最优先,价值密度最大最优先和价值最高最优先(HVF,highest value first),在系统中,采用价值最高最优先算法,价值最高最优先函数为V(T)=c(w1(t-ts)-w2d+w3p-w4s),其中,s为空余时间,d为事务的截止期,p为已执行时间,c为T的危险度,t为当前时间,ts为T的开始时间,w1,w2,w3,w4为加权因子。在上位机,将CPU时间按照价值最高最优先准则分配给各个事件,根据多任务调度设计的思想,把实时数据库系统中的事务划分为不同的线程,同时对每个线程设定不同的优先级,定期处理某一事件而不会在某一事件上处理时间过长,此外还设定定时策略,以完善事务调度,如图4所示。
3.3 I/O接口
I/O接口是实现上层应用软件,客户端,智能终端,实时数据库之间进行通信的关键部件,由于在现场采集设备可能是来自不同厂商的不同时期的产品,其所采用的接口种类不统一,其系统结构和通讯方式也可能不一样,为了使本实时数据库达到具有开放性接口功能,在通用接口软件框架下对IO接口进行了简化,I/O接口体系结构图如图5所示。
实时数据库共提供了两个接口模块:下层接口模块和上层接口模块,下层接口模块用于与各种智能终端设备(如智能控制设备PLC与DCS,智能总线备Profi Bus、Can Bus与Mod Bus等,PC总线PCI/ISA/USB等)通讯和交换数据;而上层接口模块用于与企业信息管理系统软件的数据通信,如:数据查询,Internet的通信等应用程序。
为了提高系统的实时性能和统一数据接口,利用Windows的DLL技术和全局内存共享技术来建立系统运行时的实时数据库,针对不同的接口方式开发不同的动态库链接的策略,通过调用动态连接库中的函数,实现不同任务间的快速通信及数据处理。
3.4 数据压缩处理技术
在管道监控系统中,从管道现场采集到的实时数据量非常大,若不对这些数据进行压缩,会浪费系统大量的存储空间,因此,有写实时必要采取数据压缩技术对这些实时数据进行压缩处理,常用数据压缩算法有杜邦矩形向后斜率法、例外报告算法和旋转门压缩算法,PI实时数据库采用的就是旋转门压缩算法,若系统接收到一个新数值,只有当上次记录数值以来的任一数值都不在阀值范围之内,才会记录前一数值。旋转门压缩算法压缩流程为:
1)记x(1)=X(1),y(1)=Y(1),初始化j=1,m=1,k1=-M,k2=+M
2)m=m+1;
3)假如m>N那么转到⑻;
4)j=j+1,x(j)=X(m),
5)假如k1
6)假如j-1≧TLM,那么转到⑺,否则转到⑻;
7)m=m-1,TL=j-2,x(1)=X(m),y(m)=Y(m),初始化j=1,k1=-M,k2=+M,记录TL,
转到(2);
8)m=m-1,TL=j-2,x(1)=X(m),y(m)=Y(m),初始化j=1,k1=-M,k2=+M,记录TL;
9)返回。
上述算法中,k1,k2分别表示上扇门及下扇门的斜率,,TLM为每段压缩的最大长度,TL为该段压缩数据的采样长度,M为数值较大的整数x(j)为每段的第i个数据点,Y(i)存放压缩后的过程变量,数组X(i)存放压缩前的过程变量,E为记录限,表示偏差的阈值参数。
4 结束语
管道实时监控系统中存在着大量的实时数据处理、存储和集成问题,仅依靠分散控制系统(DCS)和关系数据库技术并不能满足数据实时性和数据有效共享要求,实时数据库是实时技术与数据库技术相结合的产物,是DCS组态软件体系结构的关键部分,能够提供高速、及时的实时数据服务。将PI系统应用到管道实时监控系统中,其能够提供高速、及时的实时数据服务,其完善的人机界面软件以及管理配置软件完成对数据的采集、存储、查询、显示和分析的功能,使得系统在工控监控中具有着广阔的应用前景。
摘要：针对输油管道的打孔盗油现象,借助VC 6.0软件工具研究并开发了基于PI实时数据库的管道实时监控系统,首先介绍了组态软件中实时数据库的结构,接着分析了管道实时监控系统架构,最后探索了实时数据库在管道实时监控系统中应用的关键技术。
关键词：实时数据库,工业组态软件,实时监控,输油管道
参考文献
[1]实时数据库系统方案的设计与实现[J].电脑知识与技术,2009(26).
[2]于继武.基于GSM短信平台的油田输油管道监控系统的设计[J].电脑知识与技术,2008(27).
[3]余卫江.数据监控系统在海洋石油勘探开发中的应用[J].计算机与应用化学,2011(8).
[4]陈鑫.GIS的输油管道辅助设计系统的关键技术[J].油气储运,2011(12).
实时数据论文 篇10
关键词：数据同步通信,分布式,实时数据库
1 前言
随着信息技术的发展以及国家对企业安全生产信息化要求的提高, 我国大多数企业生产过程中基本都采用了各种各样的监测监控系统, 由于管理和技术的原因, 这些系统分散在各个相关职能部门, 形成了多个“信息孤岛”, 严重影响了企业安全生产管理水平的提高, 阻碍企业信息化进程。
分布式实时数据库系统DRTDBS (Distributed Realtime Database System) 的出现为各种监测监控系统提供了统一的数据平台, 以便数据的查看和使用不受监测监控系统专有技术、网络、协议的制约, 达到实时数据真正共享的目的。并确保所传输数据的实时性、准确性、有效性, 为企业上层应用提供可靠的支持。
DRTDBS按照各监控设备区域分布情况, 将整个企业的实时数据进行区域划分, 由若干实时数据库服务器 (以下简称数据服务器) 加以管理。DRTDBS的网络分布结构如图1所示。
在每个数据服务器管辖区域内, 数据采集工作站将现场设备的物理信息和实时数据上传到数据服务器, 由数据服务器统一管理。区域内的监控站点如监控开发工作站, 监控应用运行服务器、现场监控工作站点等与数据服务器通信, 从中读取所需实时数据。若监控站点想跨区域访问实时数据, 例如, 区域1的监控开发工作站想访问区域2的实时数据, 则通过两区域内数据服务器的数据同步
通信来完成实时数据的访问操作。
由于在DRTDBS中数据不仅具备分布性, 同时还具备实时性, 因此, 如何在有效的时限范围内, 使各分布站点能进行准确无误的数据通信是实现DRTDBS的关键技术之一。但由于DRTDBS数据的双重特性, 迄今为止在这方面的研究还比较薄弱, 所以数据同步通信成为了DRTDBS的一大研究难点。在此背景下, 本文对已有的分布式数据库数据同步技术进行研究, 提出了适用于DRTDBS的数据同步方案, 并给出了较详细的设计步骤。
2 影响数据同步性能的因素
由于DRTDBS中数据具有实时性, 因此衡量数据同步性能的一个重要指标就是系统中所有参与数据同步的服务器完成一次数据同步所需最大时间tmax。又由于DRTDBS处于企业局域网中, 因此本节着重讨论在局域网内影响tmax的因素, 并定性分析这些因素对tmax的影响程度, 以此作为选用数据同步策略的参考。
图2, 给出了参与数据同步的服务器 (以下简称数据服务器或服务器) 的网络链路图。在图中S1、S2、S3……Sn为数据同步服务器。为简化分析, 在此我们仅考虑极端状态即每个服务器都与其它所有服务器进行数据同步的情况。Si代表服务器Sj到服务器Wij的链路带宽。Kij代表每个服务器的数据同步率 (服务器i每次向服务器j提供的同步数据量, 单位bit) 。根据图2可以得出各服务器链路带宽矩阵 (图3) 和各服务器的数据同步率矩阵 (图4) 。
根据服务器Si到Sj的一次数据同步时间, 可得整个局域网内数据同步时间矩阵:
根据图5得整个局域网中所有数据同步服务器一次数据同步后, 所需最大时间为:
即tmax为tij中最大值。可根据tij, 做适当的假设, 分析影响tmax的各大因素, 并定性分析各大因素对tmax的影响程度。假设如下:
(1) 网络稳定, 且每条链路所占带宽相等为2B/n (n-1) , 其中为网络总带宽, n (n-1) /2为网络总链路数。
(2) 在理想情况下, 不考虑网络传输延迟问题, 不考虑主机处理同步数据耗时。则Si到Sj的一次数据同步时间为:
一次数据同步中, Si向其它所有服务器提供同步数据总量为, 那么所有服务器提供同步数据总量为:
由公式 (2) 可得出以下结论:
(1) 当n恒定且K
(2) 当K
从tmax角度分析, 影响数据同步性能主要有3大因素, 数据同步率Kij, 数据同步服务器数目n和网络带宽B。选定局域网后, 在理想状态, 即网络带宽B不变的情况下, 提高数据同步性能集中在数据同步率Kij和数据同步服务器数目n两大因素上。由结论 (1) 可以总结出, 在设计数据同步方案时, 要尽量减少数据同步率, 但前提是不
会造成主机处理时间延长, 以至成为影响数据同步性能的主要因素之一。由结论 (2) 可以总结出, 在设计同步方案时, 应根据公式 (2) 估计在一次数据同步过程中能允许的数据同步服务器数目, 然后根据实际情况对服务器数进行适当控制调整。
3 数据的同步策略
(1) 为方便起见, 定义如下概念:
(1) 主服务器:是指那些提供同步数据的服务器, 如图8所示。
(2) 从服务器:指引进同步数据的服务器, 如图4-11中的服务器A, B, C和D。
(2) 主服务器和从服务器之间具有如下关系:
(1) 主服务器和从服务器都是数据同步服务器;
(2) 一个主服务器可以拥有多个从服务器, 因为它可以向多个从服务器提供同步数据;
(3) 一个从服务器可以有多个主服务器, 因为它可能拥有来自不同服务器的数据备份;
(4) 一个主服务器即可以是某些数据的主服务器, 也可以是另一些数据的从服务器, 即它可以向其它数据同步服务器提供同步数据, 也引进其它数据同步服务器提供的同步数据。
(3) 完全同步法 (Completion Synchronization, C_Syn)
完全同步法是指每次进行同步操作的时候, 主服务器都将生成完整的同步数据集合MD={MR1, MR2……, MR3, }, 并用M D完全刷新从服务器上的同步数据集合SD={SR1, j, SR2, j, ……, SR3, j}, 使主服务器与从服务器的数据同步起来。其优点是实现简单;缺点是数据同步率Kij增大时, 同步时间正比增加, 当存在大量同步数据时, 采用完全同步法效率低下, 对数据同步性能影响较大。若数据同步服务器数量n也增加时, 完全同步法将严重影响数据同步性能。
因此, 该方法仅适用于主从服务器之间需同步的数据量较少的情况。
(4) 差异同步法 (Difference Synchronization, DS)
为了克服完全同步法每次同步操作都完全刷新同步数据集的缺陷, 差异同步法并不将整个同步数据集应用于从服务器, 而是不停地监视自上一次同步操作以后主服务器同步数据集的变化, 在下一次同步操作的时候, 将这些变化应用到从服务器。
与完全同步法相比, 差异同步法最大的好处在于只需要同步变化了的数据即可, 从而大大减少了数据同步率Kij, 提高了数据同步的效率。
为实现差异同步法, 本文为每个需要同步的实时数据添加了跟踪因子, 每个负责监视一个同步数据的的更新情况。=实时数据索引号nm+更新标志。每经历一次实时数据更新, 每个实时数据值都要和上一次更新时的值进行比较, 若有更改则跟踪因子的更新标志置1, 若无更改, 则置0。之后把凡是置1的实时数据发送给相应的从服务器。
4 数据同步实现
每个服务器既可是主服务器又可是从服务器, 因此, 每个服务器数据同步模块功能相同, 由两大模块组成:通信处理模块、通信接收模块。
(1) 通信处理模块
主要负责命令、配置数据、实时数据的传输与相关处理。
(2) 通信接收模块
主要负责对命令、配置数据、实时数据的接收工作。该模块采用DCOM Server形式, 可被远程调用。
4.1 协议说明
要完成整个数据的访问通信需要以下几条最基本的命令:
(1) 请求命令:有关远程实时数据访问的请求命令。
(2) 回复命令:对远程实时数据访问的有关回复命令。
(3) 数据传输命令:实时数据、配置数据及配置数据修改信息的发送。
(4) 数据传输应答命令:数据接收方的应答命令, 表明是否接收到数据。
协议制定时应考虑到协议要包含必要信息, 简洁、清晰、易于处理。协议定义如下:
Cmd ID;Local ID, Cmd, Time;
Cmd ID:命令的标识, “Request”表示请求命令;“Response”表示回复命令;“Req Data”表示数据发送;“Res Data”表示数据接收应答。
Local ID:命令发送方标识。
Cmd:具体命令内容, 可以带参数, 详细Cmd命令如下:
Time:命令发送的系统时间。
4.2 通信连接建立
用户只需选择主服务器和具体请求命令, 按发送键即可, 剩下的工作都由通信处理模块和通信接收模块完成。在数据同步之前, 因各服务器处于非连接状态, 这就需要建立通信连接。通信建立过程如图9所示。
这里服务器A为主服务器, 服务器B为从服务器。因各从服务器与主服务器通信连接建立过程相同, 故仅讨论一个从服务器与主服务器通信连接建立过程。
1.首先从服务器B向主服务器A发出“请求查看配置表”RT命令;
完整的命令为:Request;2, RT, 2008-1-23 14:3:0 (其中2为服务器B标识) 。其命令解读为在2008-1-23 14:3:0, 服务器B向A发送了“请求查看配置表”命令。
2.服务器A通信接收模块接收到请求命令后, 由通信处理模块识别发送方, 并对其命令作出回应:
(1) 若服务器A允许服务器B查看配置表 (YRT命令) , 则服务器A与服务器B间通信连接建立成功。完整命令为:
Response;1, YRT, 2008-1-231 4:4:10 (其中1为服务器A标识) 。解读为在2008-1-2 314:4:10, A向B作出回应, 允许B查看配置表。
(2) 若服务器A不允许服务器B查看配置表 (NRT命令) , 则通信连接建立失败。完整命令为:Response;1, NRT, 2008-1-2314:4:10。
4.3 配置数据的选取
当通信连接建立后, 从服务器即可访问主服务器A的配置数据库。因各从服务器的访问过程相同, 故也仅讨论从服务器B对主服务器A配置数据库选取过程。服务器B从主服务器A的配置数据库中选择感兴趣的数据, 在内存中建立临时配置信息库, 暂存相关同步配置信息, 并在本服务器配置数据库中做好备份, 然后把指定的配置信息自动发送给服务器A。A收到后, 也在内存中建立临时配置信息库, 暂存B选定的配置数据, 并在自己的配置数据库中做好指定配置数据备份工作。最后A向B发送“YSTD”选定配置信息已收到命令。实现过程如图10所示。
具体命令为:
ReqData;2;SSTD, 1, a, 2, b 3, c…….;20 0 8-1-2314:5:12 (其中1, a, 2, b 3, c……为选定的配置信息) 。在2008-1-2314:5:1 2, B向A发送选定配置信息1, a, 2, b, 3, c……。
Res Data;1;YSTD;2006-5-20 15:31:24, 解读为在2008-1-23 14:5:20, A向B发送配置信息已收到命令。
4.4 多服务器实时数据同步更新
在此, 所谓多服务器实时数据同步更新是指以服务器数据更新周期为期限, 当主服务器数据更新后, 在不超过主服务器数据更新周期的时间内, 对从服务器上的引进实时数据进行更新。
首先, 服务器间要进行时钟同步操作, 统一各服务器时钟, 然后按照图11进行多服务器实时数据同步更新操作。
(1) 主服务器A实时数据库通知通信处理模块实时数据已更新 (1) 。
(2) 根据同步数据量多少分两种情况讨论:
(1) 若同步数据量较少时, 采用完全同步法。通信处理模块读取临时配置信息库中的配置数据 (2) ;接着根据配置数据, 读取相应实时数据 (3) ;然后发送各从服务器指定的实时数据 (4) ;
(2) 若同步数据量较大时, 采用差异同步法。通信处理模块读取临时配置信息库中的配置数据 (2) , 根据配置数据, 仅读取数值有更新的实时数据并发送给相应的从服务器。
(3) 各从服务器定时判断是否收到实时数据, 分别向主服务器A发送“YRTD/NRTD收到/未收到实时数据”命令, 由服务器A通信接收模块接收命令 (5) 。
(4) 通信处理模块定时从通信接收模块读取命令, 若有从服务器未收到实时数据, 并且服务器A实时数据库未进行下一次更新, 则重新发送指定的实时数据到相应从服务器。
以上整个过程应在主服务器下一个数据更新周期前完成。若某从服务器数据更新超时, 则舍弃接收到的实时数据。
5 结论与展望
本文从分析影响DRTDBS数据同步通信的因素入手, 根据DRTDBS的实际情况采取了两种数据同步策略, 并给出了差异同步法的实现方法。最后提出了设计实现DRTDBS数据同步的详细方案。实践证明该方案已取得了初步的成效。
今后应在DRTDBS的时钟同步、实时事务的并发控制等方面进行深入研究, 逐步完善DRTDBS数据同步功能。
参考文献
[1]闫晓多.非连接分布式数据库环境下的数据同步策略[D].青岛海洋大学硕士学位论文, 青岛海洋大学图书馆, 2002.
[2]王岳斌, 潘久辉.分布式环境下数据同步技术的设计与实现[J].南京大学学报 (自然科学) , 2001年10月, 37卷:276-279
[3]丁鲲, 严浩, 刁兴春.分布式数据库数据同步技术研究[J].海军工程大学学报, 2004年9月, 1卷5期:100-104
[4]谢坤武.基于组件技术的数据同步分析[J].武汉科技学院学报, 2004年6月, 3期:46-48
数据控制器在实时数据库中的应用 篇11
工业控制系统中的实时数据库对流程工业生产现场信息的采集、装置监控以及历史数据管理等功能,己成为控制系统中的重要组成部分。由于控制系统需要长期运行,其保存的历史数据量非常大,实时数据库对于历史数据的存储容量成为实时数据库性能的一个重要指标。然而,由于常见的商业数据库,如Oracle、SQL Server和DB2等,这些数据库并非专为实时数据而设计的,其并发性、吞吐性满足不了现场的实时性要求,不适用处理不断更新快速变化的数据及具有时间限制的事务,经测试关系型数据库通常每秒存储约千余条记录,这严重影响了数据的实时性。基于此,采用了基于COM中间件技术,利用面向对象语言C++开发了数据控制器,利用数据控制器提供的数据缓冲池,不仅可以将瞬态实时数据实时地显示,而且提供的应用程序接口,如API(Application Programming Interface)显示历史数据(如趋势图),可以很好实现对实时数据有效地管理,满足实时系统的要求。
2实时数据库存储数据的两种方法
目前,主流实时数据库就存储方式而言,通常分为两种,一是采用独立的文件I/O管理,如OSI公司的PI;另一种是采用嵌入式关系型数据库,如Wonderware公司的IndustrialSQL(InSQL)。由于大多数的连续生产型企业中已成熟地的部署了关系型数据库,同时,这些数据库提供完善的管理工具,编程人员可以很方便的定义实时数据以及能利用SQL语言进行访问和存储,很容易实现对实时数据的修改和查询,因此,在满足企业生产现场要求的前提下,宜充分发挥、利用现有的资源。
3数据控制器的设计
3.1中间件的定义
中间件是介于应用系统和系统软件之间的一类软件。它使用系统软件所提供的基础服务,衔接网络上应用系统和各个部分或不同的应用,能够达到资源共享和功能共享的目的。中间件抽象了典型的应用模式,应用软件制造者可以基于标准的形式进行开发,利用现有的软件构件装配适用于不同领域、功能各异的应用软件。在具体实现上,中间件是一个用应用程序接口定义的分布式软件管理框架,具有强大的通信能力和良好的可扩展性。
3.2中间件分类
中间件具有易集成、易移植、易演进、高可靠和易使用的优点。目前主流的中间件技术主要有微软公司的COM/COM+/DCOM,对象管理组织(Object Management Group,OMG)的CORBA,和Sun公司的J2EE技术。
按照IDC的分类方法,中间件可分为6类。分别是:终端仿真/屏幕转换;数据访问中间件;远程过程调用中间件;消息中间件;交易中间件;对象中间件等。
本文是基于数据访问中间件和交易中间件的思想,采用COM技术实现数据控制器。
3.3数据控制器的设计
数据控制器依据现场的具体情况可采用灵活的数据存储管理方式,如文件方式,基于数据库方式,本文将着重讨论数据库方式。
商品化的实时数据库通常以时间做为实时数据(历史数据)的主要识别标志,即时标,然而在大多数情况下,实时数据源,如电厂的DCS系统,在提供实时数据时,通常采用UDP广播方式,即将多个实时数据以特定的格式组织起来,形成一个(或多个)大的数据包,用户通过拆分数据包以得到目标数据,由于UDP协议包(帧)大小的限制(通常小于1K字节),经现场实测,发送5000点的实时数据需要2-3秒(同时受网络环境制约),因此DCS发送数据的时间与最终实时数据库的记录时标必然不符,显然,时标在这种情况下意义已经不是很大。
数据控制器根据这种情况,在组织实时数据时,采用二次拼接的方法,即将目标数据拆分后,再全部重新组织起来,形成新的数据包统一进行存储管理,因此,数据控制器的时标是针对某一时间的全部实时数据,而不是独立的单个实时数据,因而在某种程度上讲,它比较真实的反映了时间与实时数据之间的同步。
数据控制器需安装于WinNT操作系统下,它只提供异种操作系统的数据访问功能。
数据控制器的工作原理如图1所示。
(1)数据采集端。
在一个数据采集周期内,数据采集端将首次获取到数据包的时间做为时标,余下的数据包在采集时将忽略接收时间,直到该数据采集周期结束,在此周期中,数据采集端需同步完成全部实时数据的二次拼接,即数据采集周期结束后,数据采集端需按约定的格式同时生成一个包含全部实时数据的数据池。
依据应用要求的不同,必要时,数据采集端可以对数据池进行实时无损压缩或实时编码,这两种方式相比较而言,尽管采用实时编码后的数据池将会增大,但用户可通过数据库系统的SQL语句对实时数据进行各种操作。
在形成最终的数据池后,数据采集端需依照数据链路协议的约定将数据池中的数据进行组织并将其发送到数据控制器。
(2)数据链路。
数据链路可依据实际情况采用不同的网络传输协议,如TCP/IP,NETBIOS等,由于数据量较大且采集频率较高,因此,数据链路不宜采用实时连接的方式,即在传送数据时实时建立网络接连,传输完毕后再断开连接,尽管这样做可以减少网络带宽消耗,但由于需要频繁建立连接,因此效率反而不高。
(3)数据链路接口。
数据链路接口负责建立数据链路,同时维护管理多个数据采集端发送的实时数据。
(4)数据缓冲池。
由于在实际应用中,瞬态实时数据(如组态图)的访问量要远远大于历史数据(如趋势图)的访问量,因此,设立数据缓冲池可大幅提高实时数据的访问效率,其工作原理如下: 实时数据进入中间件后,首先在数据缓冲池中生成一个唯一的样本,同时对这个样本进行还原,如解压或解码。 当需要访问瞬态实时数据时,中间件将直接从数据缓冲池(内存)中读取目标值并将其返送到数据申请方,由于避免了磁盘I/O及管理维护这些数据的额外消耗,因此效率很高,且提供了100%的访问命中率。 数据缓冲池中的样本是唯一的,它只保留接收到的最新的瞬态实时数据。
(5)事务及负载平衡处理。
实际应用中历史数据(趋势)的访问是整个中间件的性能瓶颈,数据控制器提供了事务及负载平衡处理。 同关系数据库不同,由于目的单一,因此中间件的事务及负载平衡处理相对简单的多,它主要通过大容量的缓存来提高历史数据的访问命中率,同时尽量避免磁盘I/O处理。
(6)数据库接口。
数据控制器支持全部主流的关系型数据库,如ORACLE,SQL Server,DB2等。 数据控制器通过数据库接口实现历史数据的存储与读取。
(7)应用接口。
数据控制器提供了二种显式外部接口(Window操作系统),可覆盖绝大多数应用系统的要求。
①常规应用接口,即API方式;②WEB应用接口,即Active Server Page对象。 中间件同时提供了标准TCP/IP协议接口,当上面两种接口不能满足应用的需求时,可通过TCP/IP协议进行编程访问。
(8)B/S应用。
通过ASP对象接口,用户可在支持ASP对象的浏览器中访问实时数据。
(9)C/S应用。
用户可通过编程导入接口API函数实现实时数据的访问。
(10)数据库。
即用于存储管理实时数据的关系型数据库,视现场情形而定。
(11)异种平台应用。
通过TCP/IP协议访问实时数据。一般而言,只要支持IEEE浮点数格式的应用无需改动即可直接访问实时数据。
4数据控制器接口示例
int DC_Init ; //初始化
5性能分析
经在发电厂现场运行测试,数据控制器的主要技术参数见表1。
6结束语
基于中间件技术的数据控制器与数据库技术相结合方法,不仅能满足实时系统对实时数据管理的要求,而且与国内外的实时数据库系统相比,具有投资小、效率高、实时性强等特点。该系统在我区某发电厂运行以来,运行状态良好。
参考文献
[1]宋清昆等.组态软件实时数据库系统的设计.计算机应用,2008,27(1):55～57
[2]陆桂明,郑忠洋.组态软件实时数据库研究.微计算机信息,2007,23(11):157～159
[3]宋利康等.权限管理中间件的研究与实现.南京航空航天大学学报,2007,39(4):481～484
[4]蔡瑞强,程浩忠.基于中间件技术的电力市场辅助服务实时数据库设计.继电器,2007,35(12):15～17
[5]吴德州,武君胜.面向电力系统的分布式实时数据库设计.科学技术与工程,2008,8(4):929～934
【实时数据论文】推荐阅读：
实时数据仓库06-30
远程数据实时采集07-18
数据实时性05-27
实时历史数据07-10
实时/历史数据平台07-17
实时协议数据通信应用05-25
实时优化论文07-03
实时显示控制论文05-14
实时故障诊断论文06-02
实时信息搜索技术论文06-06