实时历史数据库（共8篇）
实时历史数据库 篇1
1 历史数据库
在工业生产中,要维护大量共享数据和控制数据;又需要实时处理来支持其任务与数据的定时限制[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)的核心。历史数据是系统定时从实时数据库中采样,保存到历史数据库中的数据,用户需要时可随时从历史数据库中访问历史数据。历史数据库包含内存历史数据库和磁盘历史数据库。内存历史数据库关注的是测点近期数据的组织方式;磁盘历史数据库管理的对象是历史数据文件和管理信息文件。对磁盘历史数据库的文件结构、缓冲区进行了描述,并详细阐述了其总体架构及重要功能模块(读/写操作、压缩、数据页存取)的实现技术。
关键词：实时数据库,内存数据库,历史数据处理,磁盘历史库,数据存储
实时历史数据库 篇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
浙江省电力公司作为国家电网公司系统内较早开展实时/历史数据平台研究的网省公司, 率先实现了公司范围内统一技术平台、统一运维管理、统一实施、技术规范的实时/历史数据应用。自平台建成以来, 陆续接入了生产、调度和营销等业务150余万测点实时/历史数据, 开发了上千个应用, 并广泛应用于发、输、变、配、用、调度、营销等环节, 取得了丰硕的成果[1,2,3]。
随着国家电网公司智能电网建设的快速推进, 越来越多的智能电网业务管理系统需要接入实时/历史数据平台, 以便集中存储、分析和共享电力生产实时/历史数据[4]。但是现有的平台在部署架构、应用拓展等方面已不能满足浙江电网的发展需要, 亟需构建新的实时/历史数据平台。
1 实时/历史数据应用现状
1.1 国家电网公司实时/历史数据应用现状
近年来, 国家电网公司加大实时/历史数据库技术应用力度, 特别是随着智能电网建设的发展, 亟需加强对电网海量实时/历史数据的管理与应用。国家电网公司于2011年发布了《国家电网公司海量历史准实时数据管理平台典型设计》, 对系统内海量实时/历史数据管理平台在系统架构、功能、数据交互等方面给出了规范性建议。
在此基础上, 国家电网公司开展了实时/历史数据应用平台试点研究与实施工作, 确定华东分部、上海电力公司等5个网省公司开展试点实施工作, 并在2011年底先后完成试点验收。
1.2 浙江电力实时/历史数据应用现状
浙江省电力公司于2005年经过充分选型论证, 确定了依托美国OSI公司PI实时/历史数据库建立了浙江电网实时/历史数据平台。PI数据库是当时技术先进、稳定成熟的实时/历史数据库产品之一, 广泛应用于电力、石油、化工和通信等领域。浙江省电力公司也是国家电网公司系统内最早将PI数据库引入到电网生产管理、建设和研究实时/历史数据平台的网省公司, 历经7年的建设和发展, 建成了省、地二级部署的平台, 发挥了积极的作用[5]。
PI平台架构如图1所示。省公司与地区局各自部署一套PI系统, 由PI数据库服务器、应用服务器、数据接入接口服务器和数据访问接口服务器组成。各级PI数据库服务器分别接入各自区域内的数据, 上下级PI数据库服务器通过数据复制进行数据共享[6,7]。
PI平台的建设应用, 使浙江省电力公司在实时/历史数据应用方面走在国家电网公司的前列。通过在平台上进行技术研究、应用开发和业务竞赛, 打造和培养了实时/历史数据应用技术的科技创新团队, 取得了大量技术成果和专利。
但由于浙江电网实时/历史数据平台建设起步较早, 对照国家电网公司后续制定的技术规范与要求, 存在一定差异, 同时在PI应用上也暴露出一些问题, 主要表现在以下2个方面。
1) 部署架构与国家电网公司典型设计要求存在差异。PI平台建设初期, 为了加快推进业务应用, 鼓励地区局发展个性化应用, 减小应用对网络带宽压力, 系统架构采用了省、地两级部署模式;另外, 当时PI数据库稳定版本仅有15万测点规模, 也很难支撑全省集中部署, 现有部署架构与国家电网公司典型设计方案要求的网省一级部署模式存在差异。
2) 平台业务应用发展不平衡。平台在应用过程中, 全省建成了1 000多个业务应用系统。各单位应用发展水平参差不齐, 造成平台业务应用重叠, 不利于平台的统一运维管理。
在这一背景下, 如何构建符合浙江电网应用发展需求的新的实时/历史数据平台, 成为当前面临的重要问题。
2 基于海迅数据库的实时/历史数据平台
2.1 平台价值
基于海迅数据库的实时/历史数据平台作为浙江省电力公司管理信息大区唯一的实时/历史数据管理平台, 通过统一的数据接入、存储和访问管理, 为业务应用提供公共数据服务, 降低信息安全风险, 提升信息综合利用和统一管理水平。
1) 统一的数据接入和访问。统一的数据接入和访问可以消除现有业务系统点对点直连方式带来的信息安全隐患, 并改变现有数据接口种类繁杂的现状, 降低运维工作量。
2) 规范化的数据管理。规范化的数据管理可以提升实时/历史数据共享和综合利用水平, 为各业务部门实施综合分析应用提供全面的数据支撑, 而不需要再从其他业务系统中获取所需数据。
新的基于海迅数据库的实时/历史数据平台可以有效整合实时/历史数据资源, 标准化的应用建设方式, 为国家电网公司探索实时/历史数据管理模式和应用建设提供经验。
2.2 部署架构
遵循国家电网公司SG-ERP总体规划, 按照国家电网公司典设中各网省公司应采用集中部署模式的要求, 以及浙江省电力公司制定发布的《实时/历史数据平台技术导则 (试行) 》的建设原则, 新平台采用全省集中式部署模式, 统一使用, 统一管理。基于海迅数据库的实时/历史数据平台部署架构如图2所示。
1) 在省公司集中部署数据库服务器和应用服务器, 从而做到数据和应用的集中部署, 符合国家电网公司典设要求。
2) 核心数据库 (海迅数据库) 支持分布式部署, 方便平滑升级扩容, 能满足浙江电网未来全省测点规模上千万乃至上亿的海量数据规模, 有效解决测点资源瓶颈限制。
该部署方式便于进行全省的统一数据规划、统一数据模型和统一数据标准, 同时便于基于新平台应用的全省推广。
2.3 统一数据接入和访问控制
基于海迅数据库的实时/历史数据平台横跨调度、营销、生产等多个部门, 集中存储SCADA、电量系统、用电信息采集、营销、在线监测等多数据源实时/历史数据, 业务应用将更趋向于综合应用。基于海迅数据库的实时/历史数据平台业务架构如图3所示。
作为浙江电网管理信息大区唯一的实时/历史数据管理平台, 调度、营销、生产等部门带有时标的、连续性的数据原则上都应按照统一的规范接入到平台中, 同时各业务部门的应用通过标准的数据访问服务直接从平台中获取所需的数据, 而非通过自行开发的非标准的数据接口从源系统获取数据, 从而实现新平台对数据接入和访问的统一控制, 降低信息安全风险。
平台提供标准的数据接入方法, 参考不同系统的实际状况, 遵循DL/T860、DL/T890等标准规约或以UAPI、E格式等方式, 将各类实时/历史数据接入到平台中。标准的数据接入接口应具备历史数据接入、异常处理等功能, 按照国家电网公司典设对数据接入的要求, 新平台应提供接口集中管理工具, 统一管理数据接入接口。
平台不仅提供多种形式的、符合DL/T 890组件接口规范 (Component Interface Specification, CIS) 的数据访问服务, 还通过Web Service技术提供了标准的、通用的实时/历史数据平台测点配置信息以及测点实时/历史数据访问方法[8]。常用的访问方法有服务器连接与身份验证、测点属性查询、实时数据查询和历史数据查询等。
2.4 平台应用
浙江省电力公司目前采用标准化和个性化应用并举的模式, 充分发挥一线员工的创新精神。因此, 新平台应支撑这两大类应用的开展。基于海迅数据库的实时/历史数据平台应用体系架构如图4所示。
个性化应用是指由公司各业务部门的基层人员根据自身需求自主进行开发的应用。利用平台提供的组态、报表、计算等二次开发工具来进行快速的界面开发, 底层则通过SDK等方式访问海迅实时/历史数据库中的测点信息和实时/历史数据, 一般为C/S架构。
标准化应用是指公司各业务部门提出具体需求, 由专业的技术人员进行系统化的应用开发。利用ASP、JSP或J2EE等技术进行Web应用开发, 通过CIS规范的数据访问服务或标准Web Service接口访问海迅实时/历史数据库中的测点信息和实时/历史数据, 一般为B/S架构。
由于新平台应用进行了省级集中部署, 为了能更方便地集中管理和发布这些应用, 需要提供以下相应的技术保障, 从而满足应用管理、访问权限管理、应用集中展示等用户需求。
1) 新平台应提供统一的用户管理和权限管理。
2) 新平台应提供应用展示模板和统一门户管理工具, 用于标准化应用的快速开发和集中展示。
3) 新平台应提供个性化应用开发管理工具, 用于开发、发布、部署和管理个性化应用。
2.5 基于CIM的数据管理
作为浙江电网管理信息大区唯一的实时/历史数据管理平台, 来源于SCADA、电能量、在线监测、用电信息采集等大量电力生产信息化系统或装置的实时/历史数据, 都将集中存储在新的数据平台中。
但这些数据是以数据测点的形式离散地存储在平台中, 既浪费了大量的基础平台测点资源, 也加大了综合利用业务数据资源的难度。因此, 通过电网资源公共信息模型 (Common Information Model, CIM) 对这些测点进行统一管理, 成为新平台建设的重要基础工作。
为了有效管理和综合利用这些实时/历史数据, 以DL/T890、DL/T860等标准为基础, 同时结合浙江省电力公司实际业务应用需要, 统一和整合各业务系统的CIM, 形成浙江省电力公司标准的数据模型, 通过企业数据访问总线的方式, 提供给各业务应用系统使用[9,10,11]。
新平台实现了CIM的管理和维护功能, 在统一管理和维护电网资源命名规则和量纲的同时, 兼顾测点数据的统一管理, 将测点数据与具体的电网资源绑定, 有利于合理规划和利用新平台测点资源。同时提供了通用的建模工具来创建数据模型, 考虑到公共信息模型数据之间关联性较强, 模型管理数据与测点管理数据存放在关系型数据库中, 以方便模型的管理和维护。
33平平台迁移技术策略
由于PI平台已经在浙江电力运行多年, 沉淀了海量实时/历史数据, 开发了大量实时业务应用, 因此平台迁移的过渡时期会存在PI平台和新平台共存的情况, 如何解决2个平台共存运行、平稳过渡的问题, 是平台迁移的关键点之一。在实时数据接入方面, 同时运行PI平台和新平台的数据接入接口, 分别保存数据, 使得2个平台相对独立, 互不影响;在历史数据接入方面, 新平台提供方便快捷的PI2HS数据迁移工具, 支撑数据的安全高效迁移;在应用迁移方面, 新平台提供组态、报表、计算等工具来替代PI平台原有的PI-Datalink、PI-Processbook、PI-ACE等工具, 同时还提供了PI平台所没有的工具, 如PI2HS图形迁移, 从而加快应用迁移的速度, 保证平台平稳过渡。
新平台采用了与PI平台不同的集中部署模式, 需重点解决测点规模、网络带宽等方面的关键问题。
1) 采用网省集中部署方式, 全省实时/历史数据汇集在一起, 存储数据量将非常庞大, 测点数据规模将高达上千万, 需要考虑数据库产品的测点规模问题。目前, 海迅实时/历史数据库支持稳定的1 000万测点版本, 并可通过分布式部署方式, 实现动态扩容, 满足大规模测点需求。
2) 采用网省集中部署方式, 各地市直接访问省公司的应用, 从地市到网省会不间断地传输实时数据, 势必对网络带宽造成一定压力。参照国家电网公司典设对网络压力进行理论估算, 若新平台同时有100万测点在进行数据查询操作和数据写入操作, 频率都为5 s/次, 占用的网络流量约为119 Mbit/s, 目前浙江省电力公司千兆级信息网络可以承受该情况下的实时数据传输压力。
同时在实际的网络环境中, 模拟大量客户端并发读写的情况, 对新平台的网络压力、并发事务的处理效率等进行了测试。参照PI平台中的压力情况, 模拟并发读写的客户端数量维持在800个左右, 数据读写频率达到秒级时, 服务器硬件资源基本达到饱和 (CPU占用持续超过85%) , 查询事件率为11.2万/s, 写入事件率为137.5万/s, 此时网络带宽占用约为17.8 Mbit/s。在这种压力条件下, 浙江省电力公司现有的骨干网网络能够支撑其正常运行。平台测试结果如图5所示。
4 结语
随着业务应用领域的拓展和大量业务应用的部署及数据接入, PI平台资源不足、应用水平发展不一以及部署架构与国家电网公司典设存在差异等因素都在制约着实时/历史数据应用的发展。围绕着坚强智能电网发展的总体目标, 密切结合浙江电网现状和发展需求, 通过基于海迅数据库的实时/历史数据平台的构建和平台迁移技术策略的研究, 为解决PI平台存在的问题提供了一个有效的手段和方法。
基于海迅数据库的实时/历史数据平台的建立, 为浙江电网海量实时/历史数据提供了一个标准规范的管理平台, 统一采集和接入、存储实时数据并提供标准的数据访问服务, 提升了信息共享和统一管理水平, 同时为浙江省电力公司各业务部门的应用提供了一个应用管理平台, 全面支撑业务应用, 为推动浙江电网实时/历史数据应用、挖掘实时/历史数据价值打下坚实的信息化基础。
参考文献
[1]田家英, 赵舫.PI实时数据库在供电企业中的应用[J].电力系统保护与控制, 2006, 34 (15) :46–49.TIAN Jia-ying, ZHAO Fang.Application of PI real-time database in power supply enterprise[J].Power System Protection and Control, 2006, 34 (15) :46–49.
[2]刘岩, 姚峰.PI实时/历史数据库在智能变电站的应用[J].浙江电力, 2011, 30 (8) :5–8.LIU Yan, YAO Feng.Application of plant information database in smart substation[J].Zhejiang Electric Power, 2011, 30 (8) :5–8.
[3]蔡振华, 李丰伟, 王亦勤, 等.PI数据库系统在无功电压管理中的应用[J].浙江电力, 2011, 30 (8) :24–26.CAI Zhen-hua, LI Feng-wei, WANG Yi-qin, et al.Application of plant information database to management of reactive power and voltage[J].Zhejiang Electric Power, 2011, 30 (8) :24–26.
[4]陈树勇, 宋书芳, 李兰欣, 等.智能电网技术综述[J].电网技术, 2009, 33 (8) :1–7.CHEN Shu-yong, SONG Shu-fang, LI Lan-xin, et al.Survey on smart grid technology[J].Power System Technology, 2009, 33 (8) :1–7.
[5]方明霞.PI数据库在浙江电网的应用现状与展望[J].浙江电力, 2010, 29 (4) :51–54.FANG Ming-xia.Application situation and prospect of PI in zhejiang power grid[J].Zhejiang Electric Power, 2010, 29 (4) :51–54.
[6]陶敏, 郭宁.PI实时/历史数据库系统平台架构优化[J].浙江电力, 2011, 30 (8) :1–4.TAO Min, GUO Ning.Optimization of platform architecture for plant information database[J].Zhejiang Electric Power, 2011, 30 (8) :1–4.
[7]王俏文, 陶文伟, 丁坚勇, 等.基于PI数据库的供电企业实时数据中心的设计与实现[J].电力系统自动化, 2009, 33 (6) :99–103.WANG Qiao-wen, TAO Wen-wei, DING Jian-yong, et al.Design and development of power supply enterprise real-time data center system based on PI database[J].Automation of Electric Power Systems, 2009, 33 (6) :99–103.
[8]周升, 陶敏.实时/历史数据库平台通用访问方法研究[J].浙江电力, 2012, 31 (12) :94–98.ZHOU Sheng, TAO Min.Study of universal access method in real-time/historical database platform[J].Zhejiang Electric Power, 2012, 31 (12) :94–98.
[9]张慎明, 黄海峰.基于IEC61970标准的电网调度自动化系统体系结构[J].电力系统自动化, 2002, 26 (10) :45–47.ZHANG Shen-ming, HUANG Hai-feng.Architecture of power dispatching automation system based on IEC61970 standard[J].Automation of Electric Power Systems, 2002, 26 (10) :45–47.
[10]张慎明, 卜凡强, 姚建国, 等.遵循IEC61870标准的实时数据库管理系统[J].电力系统自动化, 2002, 26 (24) :26–30.ZHANG Shen-ming, BU Fan-qiang, YAO Jian-guo, et al.Realtime database management system that conform to IEC61970standard[J].Automation of Electric Power Systems, 2002, 26 (24) :26–30.
实时历史数据库 篇4
随着电网企业坚强智能电网建设的逐步推进, 产生了大量的实时数据, 继而沉淀生成海量的历史数据, 这些海量实时/ 历史数据都是电网企业生产运行过程中的重要财富, 是实现精益化管理的重要信息基础。在这一背景下, 浙江省电力公司积极探索和尝试, 初步建立了以国产实时数据库为基础的实时/ 历史数据平台, 以满足各业务应用对实时/ 历史数据进行存储、整合、共享以及统一和标准访问的需求。但目前平台在应用层面仍缺少统一规划, 亟需形成一个统一的应用技术架构。
1 现状分析
实时/ 历史数据平台是对电网生产运行过程中各业务应用形成的实时/ 历史数据进行存储、集中、整合、共享和分析的场所, 同时提供标准统一的访问方式, 是为智能电网和SG-ERP各业务应用——特别是跨专业、跨部门的综合业务应用在实时/ 历史数据层面提供技术支撑的信息基础设施[1,2]。
《国家电网公司海量历史准实时数据管理平台典型设计》中对实时/ 历史数据平台进行了明确定位:一方面是SG-ERP的实时数据中心, 与结构化数据管理平台、空间数据管理平台和非结构化数据管理平台共同构成SG-ERP数据中心;另一方面, 也是各业务构建实时/ 历史数据计算分析应用的基础支撑平台。根据国家电网公司典设要求, 实时/ 历史数据平台在数据管理和应用管理上都要具备良好的可扩展性和可维护性, 以支撑各业务应用持续发展的需要。同时要求在实时/ 历史数据平台建设过程中, 确保业务应用规范化实施和统一化管理。
目前, 国内外针对实时/ 历史数据应用的技术框架主要偏重于数据管理方面, 如数据接入、存储、访问等方面的技术框架和技术标准较多[3,4,5]。对于应用技术框架, 则没有相关的规范和标准。
从国家电网公司内部来看, 华北、上海等实时/历史数据管理平台建设试点单位偏重于数据管理方面规范和技术的研究, 在应用规划和应用实现技术框架上, 都没有深入的研究和成型的成果。
浙江电力在2012 年开展了实时/ 历史数据平台验证性研究和建设工作, 制定了实时/ 历史数据平台技术规范, 初步在实时/ 历史数据的接入、存储和访问方面制定了相应的技术规范, 并在此基础上构建了浙江电网实时/ 历史数据平台。但在平台应用规范化管理方面, 尚未制订相关的标准和技术规范, 大多地市局个性化应用使用平台提供的二次开发工具实施, 少量全省标准化应用沿用相关厂商各自的技术框架, 并且按照各自的应用实施方案设计、开发和运维具体业务应用, 且独立部署。这与全省“统一平台”理念相背离, 也不符合国家电网公司典设方案中实时/ 历史数据及其应用的集中、统一管理要求。
因此, 从平台应用集中、统一和标准化管理要求出发, 综合考虑平台应用的可持续发展, 在“统一平台”应用规范化管理层面应对平台应用技术框架规范进行统一。
2 统一应用技术架构
2.1 总体架构
根据国家电网公司典设要求, 浙江电网实时/ 历史数据平台采用全省大集中的部署模式。为了促进平台上应用的规范化发展, 尤其是省级综合应用的统一规划和实施, 应采用统一的应用技术架构, 即参与平台上应用建设的开发单位必须遵循统一的应用技术框架实施平台标准化应用, 使得不同的业务功能模块将打包合并到一个运行环境中。应用平台总体架构如图1 所示。
该架构主要有以下特点。
1) J2EE架构。应用平台基于J2EE架构, 所有应用模块将运行在一个统一的Web APP中。
2) 数据库。业务应用基于实时数据库和关系型数据库, 实时/ 历史数据都存放在实时数据库中, 各业务应用通过实时数据库提供的API、SDK等实现对实时/ 历史数据的访问。应用平台中用户、组织结构、应用权限及元数据 (测点属性中与具体业务密切相关的元数据) 管理等采用关系型数据库进行存储和管理。
3) 系统鉴权服务。业务用户对应用系统的访问必须通过平台提供的鉴权服务, 只有合法的用户能够访问相应的业务模块。
4) 单点登录。系统实现与企业门户系统的集成, 并实现用户单点登录, 用户登录企业门户后, 无需输入用户名和口令, 可直接访问集成的各应用系统。
5) 基础业务应用。应用系统平台的基础应用主要包括组织人员管理、应用权限管理、系统管理、个人主页设置和测点管理等功能模块。1组织人员管理:主要用于提供覆盖全省的各业务单位的组织结构, 以及与之相对应的用户信息。2应用权限管理:提供对系统用户的角色分配功能, 并对所有业务模块相关功能进行权限的配置和绑定。3系统管理:为具体业务应用系统提供服务监控、日志记录、活动审计和系统参数配置等。4个人主页设置:主要提供用户个性化的主页设置, 包括一些用户个性化参数设置。5测点管理:是对实时/ 历史数据平台原测点管理功能的扩展, 在关系型数据库中维护测点的基本信息, 提供实时数据库测点与运检、营销、调控等专业平台中设备的对应关系, 同时提供测点关联关系的维护, 并可绑定相关权限。
6) 按专业分类业务应用。未来应用平台将广泛应用于运检、调控、营销、规划辅助以及信息资源监控等业务的信息化管理, 这些业务功能模块将基于实时/ 历史数据平台, 采用统一的基础架构, 包括组织、人员、权限、测点管理等, 为各专业定制功能。
7) 系统接口服务。应用平台中将提供统一的系统接口服务, 对外部业务系统 (如运检、营销、调控等系统) 提供实时/ 历史数据和相关业务功能的访问。同时提供对接口服务的监控和审计。
2.2 应用权限管理
在实时/ 历史数据应用平台中, 采用基于角色的访问控制 (Role-Based Access Control, RBAC) 方法进行应用权限控制。在RBAC中, 包含用户、角色、许可权等基本数据元素, 权限被赋予给角色, 而不是用户, 当某个角色被指定给某个用户时, 此用户就拥有了该角色所包含的权限[6,7,8]。会话Sessions是用户与激活的角色集合之间的映射。RBAC3 模型如图2 所示。
RBAC3 模型在传统的RBAC模型上引入了角色继承和责任分离2 种特性, 采用RBAC3 模型的权限控制具有以下特点。
1) 权限指派关系可以根据需求和临时情况动态调整和修改。由于权限与角色相关联, 用户通过成为适当角色的成员而得到这些角色的权限, 这极大地简化了权限的管理。在一个组织中, 角色可根据业务工作而被建立, 用户则依据相应的责任和资格来指派相应的角色, 用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而被赋予新的权限, 而权限也可根据需要而从某角色中回收。
2) 角色可继承。除了具有自身的属性与权限之外, 还可以继承其他角色, 从而自动拥有被继承角色的属性与权限。如付费用户可以继承普通用户的属性与权限, 超级管理员可以继承普通管理员的属性与权限。
3) 角色可约束。约束原则将在权限被赋予角色时, 或角色被赋予用户时, 以及当用户在某一时刻激活一个角色时被强制性遵循。约束原则包括角色的互斥关系, 即互斥角色不能同时处于活动状态, 以及角色的最大活动会话数量受限规则等。
4) 提供对实例级别对象控制权限。在RBAC模型中, 资源对象是权限控制的目标, 将资源与角色指派关系绑定后将决定用户对资源的操作权限[9,10], 因此在应用平台中资源的定义及划分的颗粒度决定了系统权限控制的精细程度。权限设置方法见表1 所列。
2.3 个人主页设置
实时/ 历史数据应用平台为用户提供灵活的页面展示方式, 除了默认的主页外, 用户还可以自定义个人主页, 并可选择登录后采用何种主页模式。
1) 缺省主页展示。系统默认为每个用户提供应用访问主页, 根据权限设置情况, 每个用户的主页中只展示允许该用户访问的业务功能模块, 每个应用模块提供一个入口链接, 用户通过入口可进入系统, 每个业务应用具有独立的页签展示导航菜单和数据视图。当管理员重新分配用户权限后, 用户默认主页中相应业务模块展示将进行调整。用户可在工作台页面上查看业务模块的属性, 主要包括业务模块相关的权限设置情况。如果该用户具有该模块的管理权限, 可进行角色添加和用户指派。
2) 个性化主页定制。用户可以对个性化主页的布局进行选择, 系统支持多种布局方式。用户选定的布局方式将作为用户的个性化参数之一, 可以自行进行维护。用户可以在选定的布局中, 设置需要展示的内容组件。每个业务应用都可以配置作为展示的资源 (可以在应用权限模块中由管理员进行配置) , 如果用户具有这些资源的访问权限, 即可选择并放置到个人主页中。用户可对个人主页中的内容组件进行维护, 包括增加或删除, 同时也可在页面中拖拽调整各内容组件的位置。用户设置完成个性化主页后, 登录系统时将默认打开该页面。
2.4 测点管理
应用平台中的测点管理主要是为了建立实时数据库测点与外部其他业务系统设备模型之间的对应关系, 并建立相关的设备对象元数据。设备模型对应关系如图3 所示。
目前外部业务系统主要有生产系统、营销系统和调度系统等, 这些系统均有自身独立的设备管理模型, 当实时/ 历史数据平台接口服务器接入设备测点数据时, 如果只建立设备和测点的对应关系, 则最终无法形成不同业务系统之间设备模型的对应, 而通过设备元数据 (包括设备类型、电压等级、所属单位、变电站、间隔、设备名称等) 的维护管理, 可以判定重要元数据一致的测点所采集的数据来自于同一台设备资源, 为将来跨业务系统进行业务功能设计提供基础。同时通过建立对象元数据, 可以更方便地对测点对象根据元数据 (如按电压等级、设备类型等) 进行分类统计和查询。
此部分的主要功能如下。
1) 自动建立测点对应关系。当系统从接口采集数据时, 根据预先建立的设备匹配原则, 对满足条件的设备自动创建测点和设备对应关系, 并提取设备元数据信息。设备元数据信息包括设备类型、电压等级、变电站、所属单位、数据所属业务系统、设备名称等。
2) 提供手动方式对测点关联信息和设备元数据进行维护, 包括信息的增加、删除、修改和查询。
3) 提供对测点数据的分类统计报表, 用于分析测点建设情况。
4) 提供对测点对应关系和元数据的导入和导出, 数据格式可采用CSV或XML。
2.5 系统接口服务
实时/ 历史数据平台需要为外部系统提供一系列数据访问服务, 涉及的数据范围包括电网数据、电量数据、设备监测数据、用电运行数据、电能质量数据、环境气象数据、雷电监测数据、发电运行数据以及其他历史/ 准实时数据等。
应用平台向外部业务系统提供Web Service服务, 采用标准的跨平台的方式提供数据访问服务[11,12], 具体功能如下。
1) 提供的Web Service服务支持用户验证, 通过验证的用户在访问相关数据时需要满足应用平台中数据访问权限设置, 用户无法访问未经授权的数据。
2) 提供各类历史/ 实时数据的查询服务, 包括最新数据查询、历史数据查询、历史数据统计、报警时间查询等。
3) 可以通过设置启用或禁用指定的数据访问服务。
4) 可以对服务的访问者进行启用或禁用管理。
5) 可以对数据访问情况进行统计分析, 对可能造成性能问题的服务进行分析并实施控制。
3 结语
实时/ 历史数据平台应用技术架构是实时/ 历史数据平台研究的一个重要领域, 与核心基础数据库产品以及数据规范化接入、存储、访问的研究有着同等重要的意义。通过对实时/ 历史数据平台上应用现状的分析, 研究满足各业务应用需求的统一技术构架, 一方面可以提升实时/ 历史数据平台应用的整体管控能力, 改变现有平台上业务应用缺少统一规划和规范化技术架构的现状, 改变现有应用技术支持厂商各自为政、存在技术壁垒的现状, 形成平台应用建设的良性生态链;另一方面可以提升实时/ 历史数据平台应用的信息化水平, 有效地沉淀和积累技术及业务能力, 提升应用的实用化水平, 有利于平台应用能力的可持续发展。
参考文献
[1]方明霞.PI数据库在浙江电网的应用现状与展望[J].浙江电力, 2010, 29 (4) :51–54.FANG Ming-xia.Application situation and prospect of PI in Zhejiang power grid[J].Zhejiang Electric Power, 2010, 29 (4) :51–54.
[2]王俏文, 陶文伟, 丁坚勇, 等.基于PI数据库的供电企业实时数据中心的设计与实现[J].电力系统自动化, 2009, 33 (6) :99–103.WANG Qiao-wen, TAO Wen-wei, DING Jian-yong, et al.Design and development of power supply enterprise real-time data center system based on PI database[J].Automation of Electric Power Systems, 2009, 33 (6) :99–103.
[3]樊勇, 徐孝忠, 严浩军, 等.电网企业实时数据管理方法和工具的探讨[J].华东电力, 2012, 40 (3) :485–487.FAN Yong, XU Xiao-zhong, YAN Hao-jun, et al.Real-time data management methods and tools for power grid enterprises[J].East China Electric Power, 2012, 40 (3) :485–487.
[4]张鹰, 汤磊.SCADA与PI间的数据接口及通信规约设计[C]//2006电力系统自动化学术交流研讨大会论文集, 2006:195–197.
[5]田家英, 赵舫.PI实时数据库在供电企业中的应用[J].电力系统保护与控制, 2006, 34 (15) :46–49.TIAN Jia-ying, ZHAO Fang.Application of PI real-time database in power supply enterprise[J].Power System Protection and Control, 2006, 34 (15) :46–49.
[6]张燕燕.基于角色访问控制的实现研究[J].网络安全技术与应用, 2006 (8) :53–54.ZHANG Yan-yan.Implement of role-based access control[J].Network Security Technology and Application, 2006 (8) :53–54.
[7]姜宇锋, 付钰, 吴晓平.基于RBAC的权限系统设计与实现[J].计算机与数字工程, 2009, 37 (6) :98–101.J I A N G Yu-f e n g, F U Yu, W U X i a o-p i n g.D e s i g n a n d implementation of authorization system based on RBAC[J].Computer and Digital Engineering, 2009, 37 (6) :98–101.
[8]董永峰, 陆军, 刘建波, 等.改进的RBAC模型在信息服务平台上的应用[J].计算机应用与软件, 2012, 29 (5) :99–103.DONG Yong-feng, LU Jun, LIU Jian-bo, et al.Application of improved RBAC model to information service platform[J].Computer Applications and Software, 2012, 29 (5) :99–103.
[9]吴江栋, 李伟华, 安喜锋.基于RBAC的细粒度访问控制方法[J].计算机工程, 2008, 34 (20) :52–54.WU Jiang-dong, LI Wei-hua, AN Xi-feng.Method of finely granular access control based on RBAC[J].Computer Engineering, 2008, 34 (20) :52–54.
[10]赵卫东, 毕晓清, 卢新明.基于角色的细粒度访问控制模型的设计与实现[J].计算机工程与设计, 2013, 34 (2) :474–479.ZHAO Wei-dong, BI Xiao-qing, LU Xin-ming.Design and implementation of fine-grained RBAC model[J].Computer Engineering and Design, 2013, 34 (2) :474–479.
[11]陶敏, 郭宁.PI实时/历史数据库系统平台架构优化[J].浙江电力, 2011, 30 (8) :1–4.TAO Min, GUO Ning.Optimization of platform architecture for plant information database[J].Zhejiang Electric Power, 2011, 30 (8) :1–4.
实时历史数据库 篇5
关键词：海量历史/准实时数据管理平台,实时数据,深化应用,一发两收
0 引言
国家电网公司海量历史/准实时数据管理平台是对电力生产运行过程中各业务应用生成的历史/准实时数据进行按需存储、整合、 共享和分析的场所。 2010 年, 国家电网公司启动了 “海量历史/准实时数据管理平台”项目, 接入大部分业务应用准实时数据[1]。 截止2014 年6月, 该平台已接入96个系统的2 807万测点, 同时为54个系统提供数据访问服务。
深化应用建设全面继承海量历史/准实时数据管理平台已有建设成果, 并开展海量历史/准实时数据管理平台完善提升工作。其重点包括完成海量历史/准实时数据管理平台设备模型构建、多通道数据访问、平台数据综合展示、应用开发数据质量检测和审计等业务组件的研发工作, 完成计算服务模块的完善提升工作, 同步开展相关前沿关键技术的研究。
1 深化应用建设内容
1.1 新增基于电网设备的海量历史/准实时数据管理平台设备模型
结合江苏海量历史/准实时数据管理平台对平台设备模型的试点实用化建设成果, 对运行、检修和营销设备进行整合, 以构建基于电网设备的海量历史/准实时数据管理平台设备模型 (如图1 所示) , 形成海量历史/准实时数据管理平台数据字典, 提升业务系统数据访问的便捷性, 满足运检部PMS2.0等业务系统通过设备方式访问及二次加工历史/准实时数据的需求 (如图2 所示) 。 其主要内容包括:
(1) 研究电网设备存储模型、数据源自动同步方式。
(2) 基于设备命名的测点命名方式。
(3) 设备树与测点的自动挂接技术。
(4) 基于设备树的访问方法和计算加工功能。
(5) 基于设备树的测点管理与维护。
(6) 设备信息相关集成接口的开发。
(7) 新增历史/准实时数据多通道访问模式。
1.2 新增历史/准实时数据多通道访问模式
为了满足PMS2.0通过设备全路径名访问, 适应一体化电量与线损管理系统通过设备台账信息访问, 同时支撑其它不同业务系统对历史/准实时数据的多形式数据访问需求, 完成数据混合模式访问模块开发, 提升海量历史/准实时数据管理平台数据访问的便捷性。 其主要内容包括:
(1) 提供基于设备的海量历史/准实时数据管理平台数据访问服务。
(2) 提供基于相关台账信息 (如区域代码、用户号、表计号和功能编码访问用电信息采集数据) 的数据访问服务。
(3) 提供设备全路径名数据访问服务。
(4) 提供基于设备模型的数据访问服务。
(5) 提供其它类型数据访问服务。
1.3提升海量历史/准实时数据管理平台计算能力, 新增平台数据可视化综合展示和应用开发业务组件
基于运监中心 “量价费损”等业务应用对数据二次加工的需求, 提升海量历史/准实时数据管理平台计算能力;新增海量历史/准实时数据管理平台数据可视化综合展示业务组件, 支撑不同层次人员对数据综合展示的需求;基于基层班组个性化创作需求, 新增基于海量历史/准实时数据管理平台的应用开发业务组件, 完成基层班组信息化工作推进。
(1) 提升海量历史/准实时数据管理平台计算能力, 支撑运监中心 “量价费损”等复杂业务应用对历史/准实时数据的电量与负荷计算、区域的电量与负荷计算等二次加工需求, 为构建复杂分析类应用提供工具保障。其主要内容包括:研究基于海量历史/准实时数据管理平台的分布式并行计算框架;开发分布式多节点并行计算模块;开发计算过程统一调度控制模块;开发计算资源池管理模块;开发支持复杂计算的计算过程模块;开发支持二次开发的IDE。
(2) 完成海量历史/准实时数据管理平台数据可视化综合展示业务组件开发, 实现海量历史/准实时数据管理平台海量数据多维度、多形式综合展示, 解决运维中心对平台可视化监控的需求, 适应管理人员对数据可视化综合分析的需求, 满足不同层次人员对数据展示的需求。其主要功能包括:提供数据不同属性 (如区域属性、 设备类型、测点类型、数据源等) 的多维度展示;提供数据多形式 (如表格、饼图、柱状图等) 展示; 提供数据不同属性的数据健康状况 (中断、漏点等) 综合展示;提供数据审计情况综合展示;提供平台运行指标 (数据访问率、测点活跃率等) 综合展示。
1.4 实现海量历史/准实时数据管理平台对用电信息采集系统准实时类数据的直接采集接入
用电信息采集系统数据量大, 数据提供及时性不高, 对 “量价费损”等业务应用中用户表计电量偏差、用户表计断流等复杂计算的及时性有较大影响。结合需求, 采用用电信息采集系统前置机 “一发两收”机制 (如图3 所示) , 在传输数据解析后写入用电信息采集系统数据库的同时向海量历史/准实时数据管理平台推送相同的原始时标数据, 以保证用电信息采集数据的及时性, 减轻用电信息采集系统的接口压力, 并为其提供数据备份。
1.5 新增平台数据质量监测和审计组件
研发海量历史/准实时数据管理平台数据质量监测和审计模块, 通过数据质量检测、数据质量审计、数据质量反馈及解决, 形成数据质量问题跟踪解决闭环, 提升海量历史/准实时数据管理平台数据的有效性、 适用性和及时性, 以满足省公司营销部需求侧分层分区决策管理系统、调控中心大屏展示系统等业务系统对历史/准实时数据数据质量的需求。其主要功能包括:
(1) 数据质量监测 (重点是FTP中断, 漏点, 数据为空, 数据为0, 网络中断等) 。
(2) 基于数据质量监测, 结合现场实际情况, 综合评价分析数据质量。
(3) 将评价结果反馈给数据管控部门, 协助解决数据质量问题, 形成数据质量跟踪解决闭环。
(4) 提供数据质量咨询服务。
1.6 部署分布式实时计算组件
平台分布式实时计算组件[3,4]研究, 实现了对历史/准实时数据的分布式并行内存计算[5], 提升了数据加工计算的效率;流计算和内存计算, 可提升加工数据的实效性;开发集成IDE, 可使数据加工计算变得更便捷; 支撑了“电网规划深化应用”、运监中心 “量价费损”和 “一体化电量与线损管理” (如图4 所示) 等复杂业务应用对历史/准实时数据的电量与负荷计算、 区域的电量与负荷计算、运行数据分析等二次加工需求, 提升了海量历史/准实时数据管理平台分布式实时计算能力, 为构建复杂分析类应用提供了工具保障。总之, 平台分布式实时计算组件研究, 为后续基于平台二次加工计算类应用开发提供了便捷。其具体研发内容如下:
(1) 研发分布式多节点并行计算引擎。 基于上述研究内容研发海量历史/准实时数据管理平台分布式多节点并行计算引擎, 计算引擎通过时间、优先级等配置策略, 调用脚本引擎执行对应的计算算法, 生成计算结果, 并作为测点的结果值和状态转存到数据库中。公式解析采用脚本引擎提供的方式。
(2) 研发分布式多节点并行计算的统一调度控制模块。该模块通过统一配置时间、优先级等策略, 实现控制调度各分布式节点计算任务的执行。
(3) 研发计算资源池管理模块。 该模块用于管理所有分布式节点的计算任务。
2 主要应用成效
通过海量历史/准实时数据管理平台提供的设备模型和对混合数据访问方式的研发, 提升了数据访问的便捷性, 提高了集成的工作效率, 减少了集成工作时间;通过对海量历史/准实时数据管理平台关键技术的研究, 提升了平台的容错性、可靠性和可用性;通过对数据质量检测和审计功能的开发, 可提供数据质量检测、 数据质量确认、数据质量反馈及协助解决机制, 形成数据质量解决闭环, 从而有效提升平台数据质量, 减少数据质量跟踪解决成本。海量历史/准实时数据管理平台的建设响应了国家电网公司坚强智能电网的建设目标, 为国家电网公司智能电网建设在历史/准实时数据存储、 加工、 交换等方面提供了有力支撑。
3 非功能需求
3.1 性能与可靠性
(1) 海量历史/准实时数据管理平台支持100TB级规模的历史/准实时数据管理以及10 个以上的历史/准实时数据库构建统一访问群集。
(2) 在带宽允许情况下, 时间序列数据的事务吞吐率不低于10万事务/s。
(3) 日常平均CPU占用率小于40%, 忙时小于75%;内存占用率小于50%, 最大并发时小于75%。
3.2 信息安全
为了保证系统安全[5], 海量历史/准实时数据管理平台的安全级别为信息系统等级保护二级。其在应用和数据方面需符合以下要求:
(1) 提供身份鉴别机制。 使用平台服务需进行基于用户密码的身份鉴别, 密码登录失败3次结束会话。
(2) 提供访问控制。平台业务用户无法直接访问文件和数据库, 默认只有最小权限, 超级管理员外的用户资源权限有限。
(3) 具备安全审计功能。 平台提供覆盖每个用户的安全审计功能, 审计记录无法被删除, 记录信息包括时间、用户、类型、级别、结果等。
(4) 提供资源控制机制。 在通信双方中的一方未作响应时, 另一方能自动结束会话;能限制系统与单个用户的最大连接数。
(5) 通信保密。 在通信双方建立连接前, 利用密码技术进行会话初始化验证。
4 结束语
海量历史/准实时数据管理平台深化应用建设结合“量价费损”等业务应用对准实时数据的需求, 完成海量历史/准实时数据管理平台计算加工能力提升, 支撑复杂分布式并行计算业务需求;完成平台设备模型业务组件、可视化综合数据展示业务组件、多通道数据访问服务、关系数据处理模块、应用开发业务组件与数据质量检测和审计服务的开发, 提升了平台数据质量, 满足了多形式的数据访问需求, 支持关系数据的储存和处理, 为不同层次人员提供多样化综合展示平台;实现平台对用电信息采集系统准实时类数据的 “一发双收”直接采集数据接入, 提升了平台历史/准实时数据实时性, 满足了 “量价费损”等业务应用对用电信息采集数据的实时性要求;开展海量历史/准实时数据管理平台接口和应用服务的故障转移技术、平台内部关系型数据存储与处理技术、时序型数据和关系型数据的统一查询机制技术等研究, 提高了平台的容错性, 保障了平台的高可用性。
参考文献
[1]曹强, 黄建忠, 万继光, 等.海量网络存储系统原理与设计[M].武汉:华中科技大学出版社, 2010
[2]张云勇.中间件技术原理与应用[M].北京:清华大学出版社, 2004
[3]蔡瑞端, 程浩忠.基于中间件技术的电力市场辅助服务实时数据库设计[J].继电器, 2007 (12) :12~15
[4]何江, 吴杏平, 李立新, 等.基于组件技术的电力系统实时数据库平台[J].电网技术, 2002 (3) :64~67
实时数据库设计关键技术研究 篇6
关键词：实时数据库,RTDBS,关键技术
引言
在传统的数据库系统中, 其设计与开发主要强调维护数据的正确性、保持系统代价低、提供友好用户接口。关于数据库的工作, 集中于查询与事务处理及数据的正确性及一致性上, 这种数据库系统对传统的商务 (Business) 和事务型应用是有效的, 也是成功的, 但它不适合实时应用。最关键的是因为它不考虑与数据及其处理相联系的定时限制 (TimingConstraint) , 系统的性能目标是以吞吐量和平均响应时间来表示的, 而不是各个事务的限制来表示的, 所以系统作调度决策时根本不管各种实时限制, 为此需要提出一种具有高实时性、大数据容量和访问量的新的数据库理论。在这样的背景下, 实时数据库系统应运而生, 它既可作为独立的系统而存在, 又可作为大型数据库系统中的嵌入部件。
实时数据库的研究起源于20世纪80年代中期。1988年发表的ACM SIGMOD Record实时数据库专刊, 揭示了实时数据库系统研究领域的诞生, 特别是1988年3月召开的第一届国际实时数据库系统的专题研讨会以后, 很多学者都对其进行了大量的研究。
一、实时数据库系统的内涵及体系结构
1、实时数据库的内涵
实时数据库系统 (简称RTDBS:Real Time Database System) 就是其事务和数据都可以具有定时特性或显式的定时限制的数据库系统, 系统的正确性不仅依赖于逻辑结果, 而且还依赖于逻辑结果产生的时间。实时数据库系统是在传统关系数据库理论上增加了时间限制的要求, 这使得数据库的设计变得更加复杂, 复杂的算法使系统资源的开销加大, 这些又影响了系统的实时性, 又需要对实时数据库的技术进行简化。这些矛盾使得实时数据库的发展远远落后于非实时数据库系统。目前对RTDBS的研究主要集中在利用数据库技术的特点来解决实时系统中的数据管理问题或为RTDBS提供时间驱动调度和资源分配算法。
时间特性是实时数据库系统不同于其它关系数据库的特点之一。数据、事件、活动都有与之相联系的时间限制。设计实时数据库系统时一定要充分考虑时间特性, 考虑外部环境所施加的时间限制、系统性能所决定的时间限制、数据的时间一致性所要求的时间限制以及其它的时间限制。另外, 由于时间限制的存在, 实时数据库中的数据还存在除数据逻辑一致性和事务逻辑一致性外的两种一致性约束条件:数据时态一致性、事务时态一致性。
2、实时数据库系统的体系结构
同传统的数据库一样, 实时数据库仍然是一种三级模式的结构体系, 即用户模式、逻辑模式和存储模式。实时数据库不是数据库和实时系统的简单结合, 它需要在数据模型、体系结构、事务处理模式、数据存储方式等诸多方面重新进行研究和开发。
(1) 实时性
RTDBS作为外部系统的一个客观反映, 它表示了外部系统的当前状态, 只有数据与外部系统的实际情况相吻合时, 数据才有意义。所以要求RTDBS必须高效, 能够实现实时反应。
(2) 稳定性和可靠性
任何数据库系统都要求稳定性, 但考虑到基于RTDBS的应用往往同样强调实时性 (基于RTDBS的典型应用包括先进控制软件和实时数据优化等) , 所以系统的稳定性被提到了更高的高度, 要求RTDBS须具备一定的容错性, 防止出现数据败坏 (Data Corrupt) 。
(3) 开放性
实时数据库作为实时数据服务的基础构件必须具有良好的开放性和扩展性, 使用户能在实时数据库上方便地进行二次开发和数据连接。为此实时数据库应该提供多种标准数据接口, 包括对外数据服务和采集不同各种数据源的能力, 以供各种主流的开发工具使用。实时数据库系统同时应该提供可编程能力, 使得用户能够在此基础上定制开发。
二、实时数据库的设计的关键技术
1、系统的高可靠性技术
可靠性设计主要有优化设计和容错设计两个方面。通常采用下面的技术提高实时数据库系统的可靠性:
(1) 基于模块化设计“微内核”设计
实时数据库核心结构的设计不仅要考虑实时数据库的核心结构, 还要考虑应用支持所需要的功能模块。由此, 基于模块化的微内核设计思想把实时数据库的运行内核部分分成任务队列和任务调度两个部分, 其中任务调度中包含事务调度、资源管理和负载管理等部分, 其中的任务调度模块和任务队列管理提供实时数据库所有的活动都需要的核心功能, 它是保证实时数据库时间特性的前提和基础, 将其分离出来使其相对独立, 实现过程中可以在充分保证实时数据库系统运行核心健壮的基础上, 方便地添加其它功能模块。在实时数据库的核心结构中要处理来自接口软件管理模块的数据采集任务、实时数据内部触发器产生的任务, 同时还要处理数据客户端的数据访问任务和系统的命令, 数据在存入数据库之前和被访问之前都要通过相应模块的逻辑处理。历史数据归档、故障处理等模块由于其处理内容的特殊性, 这些任务需要任务调度模块提供特殊的支持和处理。
(2) 容错设计
对于一个实时系统, 有时很难分清故障是由软件还是硬件引起的。要完成这些功能需要综合应用以下的容错技术:
(1) 检错技术
在软件中插入检错程序, 定期定点对软件运行中的输入数据、操作指令、关键信息和系统中的各种状态进行合理性、逻辑性检查和再确认, 目的是及时发现错误和确定出错部分。
(2) 分离和保护技术
分离和保护技术都需要使用检错程序和相应的处理程序, 分离技术是指在错误已发生, 且无法屏蔽的情况下, 为了防止系统停机, 对错误部分进行隔离, 使错误的影响局部化, 让系统在功能上降级运行的一种技术。安全保护有两方面的工作, 一是在发现重大错误, 即将发生危险时, 为了防止造成更大的损失, 强制系统停止运行, 并把系统转为预先规定的安全状态, 二是防止非法用户的侵入和操作人员的非法操作已经计算机病毒的侵害。
2、提高实时数据库实时性的技术——内存数据库技术
由于一些先进控制和实时任务的需要, 采用内存来进行数据的存储提高运行速度和实时性能的重要手段, 因此在我们的实时数据库中参考了内存数据库技术, 尤其是内存数据库的数据管理技术, 这也是内存数据库的主要内容。
对于数据库系统中使用大内存, 人们通常使用两种方法。在关系数据库中, 缓冲池很大, 以至使每一事务所需数据的大部分甚至全部都保持在内存, 这种方法中, 数据常驻磁盘, 数据库的磁盘版本是主版本或是工作版本。采用这种方法时, 使磁盘存取最少。另一种方法是内存常驻数据库法, 它使用内存作为数据库的主要存储, 即数据库的内存版本是主版本或工作版本, 磁盘是作为后备。这样关于查询处理、并发控制和恢复等的算法与数据结构的设计以CPU和内存的高效使用为目标, 而不是磁盘的存取和存储为目标, 两种方法在数据格式和数据结构及用来访问、查找和操纵数据的算法等方面不一样。内存数据库管理方式同磁盘数据库管理方式有显著的不同:
(1) 内存和磁盘在存取时间上有若干数量级的差别。内存的存取时间在10E-8s的数量级, 而磁盘在5×10E-3数量级。
(2) 内存数据具有易失性, 关于故障和备份需要着重加以考虑。
(3) 数据存储格式不同。内存是字节或字编址的, 而磁盘是块存储设备。
(4) 数据的存储组织方法对性能影响不同。不同的组织方式对磁盘而言的性能影响远比对内存影响大, 如顺序存取与随机存取的时间对内存没有什么变化, 而对磁盘则几乎有数量级的差别。
(5) 存取方式不同。内存可由处理机直接存取, 磁盘则不能;但内存比磁盘更易于受到来自程序错误的直接数据破坏。
3、数据备份和恢复技术
内存数据库把数据全部驻留在内存中, 消除了传统的磁盘数据库系统中事务运行的I/O瓶颈, 并且获得CPU直接访问数据库数据的极高存取速度, 极大地提高了系统的性能和吞吐量。但由于所有操作直接作用于内存中的数据库拷贝上, 数据库极易受到操作系统和应用软件错误造成的破坏, 因此MMDB (Main Memory Data Base) 的故障恢复技术十分关键。数据和系统的安全对本系统非常重要, 这也是企业中实时数据库系统选择的一个重要方面。
总结
为了提高RTDBS的可靠性、实时性等性能, 本文提出了基于模块化设计的“微内核”设计、容错设计、内存数据库技术, 这些技术使系统获得更强的功能和更高的性能。RTDBS已发展成现代数据库研究的重要方向之一, 在数据库研究领域越来越备受关注, 有很好的发展前景。
参考文献
[1]漆婧:《组态软件实时数据库系统研究及设计》, 《软件导刊》, 第8卷第9期。
[2]叶建位:《大型实时数据库关键技术及系统构架》, 《浙江大学》, 硕士学位论文, 2005年2月。
[3]徐国凤:《实时数据库关键技术研究》, 西安建筑科技大学硕士学位论文, 2006年6月。
[4]王成光:《流程工业大型实时数据库理论、技术与应用》, 浙江大学博士论文, 2003年2月。
实时历史数据库 篇7
关键词：关系数据库,实时数据,数据压缩,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.
组态软件实时数据库的构建 篇8
关键词：组态,实时,数据库
1 组态软件的总体结构
组态软件是通过事先定义对象的组态信息完成运行过程中对象的监视和控制功能, 并提供动态界面显示的软件, 一般监控组态软件从结构上可以分为设备接口 ( 含通讯接口) 、实时数据库和界面显示系统3 个部分, 设备接口与现场设备及控制装置通讯, 界面显示根据实时数据库中的数据生动形象地再现现场状况。
2 组态软件中数据处理的特点
组态软件中的数据必须能反映现场设备的 “当前”状态, 其数据处理有3 个特点:
2. 1 实时性, 这是组态软件必须满足的要求, 及时有效的监控现场设备的状态是组态软件的主要功能。因此系统应尽可能快地处理和传输数据。
2. 2 时间特性, 组态软件中处理的数据都带有时间标记, 要求软件必须在可预测的时间内将数据处理完成。
2. 3 实时中断, 更新的数据是组态软件需要处理的主要数据, 在新的数据到来时, 应中断当前的数据处理, 否则将出现所有数据的延迟。
3 组态软件中实时数据库的功能
实时数据库位于设备接口和界面显示的中间层, 是组态软件中数据的管理者, 实时数据库主要完成组态策略的存储, 通讯数据管理, 实时数据的处理和计算, 控制策略及算法的计算和下载, 历史数据的转化、存储和查询及实时曲线的生成, 监控软件在运行的过程中需要频繁读取组态信息, 处理和保存实时数据, 实时数据库的性能将直接决定整个组态软件的可用性。
4 商用数据库的特点
组态软件运行期间将产生大量数据, 这些数据需要进行分类整理并作为历史数据保存, 如果将大量的数据存储在几个文件中, 将不利已数据查找, 商用数据库的目标就是对大量数据进行有效管理, 成熟的关系型数据库在关系存储, 数据查找、恢复, 数据库备份及复杂的事务处理, 并发控制, 完整性、一致性的实现等方面都已经相当完善, 具有管理数据的优势, 随着商用数据库价格越来越低, 将商用数据库作为组态软件的后台数据库管理数据十分可行。
5 商用数据在组态软件中的局限性
5. 1 大量的I / O操作造成系统长时间的等待, 由于监控系统定时采集和输出数据的特点会引起软件频繁地读写数据、更改日志等大量磁盘操作, 这些操作带来大量的磁盘I/O读写, 造成系统长时间等待, 这对于实时性要求很高的控制系统来说是无法忍受的。
5. 2 事务的不可预测性, 组态软件的事务必须在可预测的时间内完成, 否则可能会影响整个系统的工作或者产生错误数据, 而商用数据频繁的I/O磁盘操作不能保证在规定的时间内完成规定的操作, 导致其在组态软件中应用受到一定的限制。
5. 3 实时数据库的框架结构
充分发挥商用数据库管理数据的优势, 将商用数据库与内存数据库相结合实现组态软件中的实时数据库是一个较好的解决方案, 内存数据库主要完成实时数据的处理, 商用数据库则完成历史数据的管理和分类。
6 实时数据库总体结构
根据设计方案, 实时数据库的实现分为内存管理、内存访问、流程实现、接口管理、数据库访问等几个主要部分。
6. 1 内存管理。内存中存放的数据主要是组态信息和实时数据, 在运行过程中, 组态信息的数据不再变化, 但是需要频繁的被查询, 查询的方法将直接影响系统的效率, 监控系统实时数据需要对内存频繁的进行更改、插入、删除和查询操作, 如何在内存中规划出有效的数据存储结构以快速执行这些操作将直接影响系统的性能。
6. 2 内存访问。在组态软件中, 底层设备接口的访问、显示界面读数据、远程网络监控修改和读取数据等任务都需要对内存数据进行读写, 提供不同的内存访问接口实现这些功能; 组态软件采用多线程的工作机制, 如果多个线程同时对同一块数据区进行读写将产生不正确数据, 影响监控软件的稳定性; 数据更改的触发器特性要求相关变量根据组态时提供的公式进行计算, 变量之间有一定的约束条件; 所有这些特性在读写数据时都应当处理, 为此在管理内存之外增加了访问层来处理这些操作, 确保访问的安全和系统的稳定。
6. 3 流程实现。流程包括定时对数据进行采集、报警计算、数据的非线性计算、控制逻辑的实现、运算变量的计算等, 这些都是监控软件中必须实现的功能, 也是监控软件区别于其它软件的主要特征, 在软件中必须有特定的模块来支持, 同时, 这些操作有一定的顺序, 必须按照步骤依次进行计算。