实时历史数据库（精选10篇）
实时历史数据库 第1篇
文件映射又叫内存映射文件。与虚拟内存相似,内存映射文件允许开发人员预订一块地址空间区域并给区域调拨物理存储器。不同之处在于,内存映射文件的物理存储器来自磁盘上已有的文件,而不是来自系统的页交换文件。一旦把文件映射到地址空间,我们就可以对它进行访问,就好像整个文件都已经被载入内存一样[1]。
与常规地使用文件I/O系统函数进行文件操作相比,分析使用文件映射的优势如下。
1)所有文件I/O系统函数均涉及到磁盘的操作以及磁盘与内存之间的数据交互,直接对磁盘内容的操作比进程地址空间的操作效率要低很多,且处理函数涉及到文件内容的缓存,执行起来消耗时间较长;而文件映射到地址空间后,所有对文件内容的操作都是在进程地址空间中进行的,文件内的数据可以用内存操作来操纵文件,而不是用读写文件的I/O系统函数在文件里来回地读、写、移动文件指针,从而提高了文件的存取等处理速度[2]。不必对文件执行I/O操作,不必对文件内容进行缓存。尤其在频繁读写文件的情况下,文件映射在处理效率方面优势明显,而利用实时历史数据库查询历史数据的过程就属于此种情况。
2)文件内容处理相关的I/O系统函数比较有限。而文件一旦映射到进程地址空间中,文件内容的操作是通过调用内存读写指令来访问的,内存读写指令调用的是程序语言函数库中的函数,函数种类丰富,处理方便。
3)文件缓存需要对文件分配适当大小的内存,在大型文件处理过程中,由于操作系统会限制应用程序调拨物理存储器的大小,需要通过多次的定位文件指针、读取文件等操作,将文件的指定内容读取到文件缓存中来,执行时间较长;而文件映射虽然也受操作系统应用程序调拨的物理存储器大小的限制,但其提供了将文件中的指定部分映射到进程地址空间中的功能,减去了多次定位文件指针的过程。
2 实时历史数据库中文件映射的应用
实时历史数据库是非安全级DCS平台Nic Sys1000系统软件的重要组成部分,它相当于一个数据处理中心,起到数据交换区的作用。实时历史数据库维护系统调用时产生的动态数据和系统调用所需的各种内部信息,保证实时数据的完整性和实时性以及时间一致性,是控制器与客户端之间数据交互的桥梁。
实时历史数据库对历史数据的查询过程,需要对文件进行多次打开、关闭和读写的操作。为实现历史数据的快速查询,设计了下面的历史数据文件的文件结构和处理机制。
2.1 历史数据文件结构的设计
Nic SysTM1000实时历史数据库的历史数据文件的结构可分为三部分:文件头、变量索引、变量值,如图1所示。表2列出了三部分的数据结构体的各成员变量的含义。
2.2 历史数据文件的处理机制的设计
Nicsys 1000系统实时历史数据库中有多种查询模式:单点时刻查询、单点时间段查询、多点时间段查询、单点时间间隔查询、多点时间间隔查询,每一种查询模式都需要对历史数据文件进行打开、读取和关闭的操作。利用文件映射机制,并对历史数据文件的处理机制进行合理地设计,尽可能地缩短历史数据文件的处理时间,从而得到较快的历史数据查询速度。
下面基于历史数据文件的结构,并利用文件映射机制,设计单点时刻查询模式和多点时间段查询模式下的历史数据文件的处理机制。
2.2.1 单点时刻查询
单个变量某一历史时刻的值的查询过程中,数据库对历史文件的处理过程如图2所示。其中,步骤2、9利用文件映射的基本使用过程(见表1),步骤3、5、6、7将直接在进程地址空间中完成,计算出所需取出的信息所在的地址后,直接得到并进行处理。若利用文件I/O系统函数,这4个步骤将包含大量的移动文件指针和读取文件的操作,会降低处理速度,影响查询效率。
2.2.2 多点时间段查询模式
多点时间段查询是用于在DCS上位机HMI生成多条历史趋势曲线。其原理是对查询时间段进行平均插值计算,得到多个时刻值,依次对每个变量点和每个时刻做单点时刻查询,得到多点多个时刻的历史值,将同一变量点的所有历史值连接形成该变量的历史趋势曲线。
实时历史数据库从上位机HMI发送过来的数据报中解析得到多个变量名和1个时间段。图3表示了两种历史数据文件的操作过程,都是用来实现多点时间段查询的,但它们的使用范围和执行效率有所不同。
两个操作过程都是以单点时刻查询模式的文件处理机制为基础,打开文件和关闭文件都利用了文件映射机制,分别包含了使用文件映射基本步骤的1、2、3和5、6、7(见表1)。其中,步骤1和8仍然需要调用文件I/O系统函数。因此,应尽量减少打开和关闭文件的次数已达到缩短处理时间的目的。
处理过程1:打开单个文件后,取出其中的变量值,则马上关闭该文件,再打开下一个文件进行处理。n个变量名的查询,文件打开次数、即调用文件I/O系统函数的次数将成倍增加。此过程同一时间只有1个文件被打开,即只有一个文件映射在进程的地址空间中,占用系统内存资源较少,但耗时较长。
处理过程2:在读取第1个变量的历史值后则打开了所有需要打开的文件,这些文件全都映射在进程的地址空间中,在读取第2n个变量的值时都不需要执行打开文件的操作。此过程处理耗时较短,但随着打开的文件数量的增多,所占系统内存也将增多,而Windows操作系统对应用程序调拨物理存储器的大小是由限制的。当查询时间段足够长,需要打开的文件数足够多,进程中的文件映射的大小会超过操作系统的限制,将无法打开新的文件。这相当于在利用此过程查询时,操作系统自动给查询时间段设置了上限。
所以目前的Nic Sys 1000平台的实时历史数据库采用两种文件处理过程的结合的方案来实现历史数据的多点时间段查询。当查询时间段低于临界值,则执行过程2;当查询时间段高于临界值,则执行过程1。
3 应用示例
利用秦山二扩安全壳泄漏率在线监测系统[3]从2010年7月至2010年10月的历史数据,通过系统DCS平台Nic SysTM1000的实时历史数据库,进行了多点时间段查询两种处理过程的比较试验,得到两种文件处理过程的性能参数。表3给出了多点时间段查询1个变量的比较试验结果,表4列出了多点时间段查询10个变量的比较试验结果。
由表3和表4可看出,当查询1个变量时,打开文件的次数对查询消耗的时间不明显,处理过程1和处理过程2的性能区别不大。当查询多个变量时,打开文件的次数越多,查询消耗的时间越长,内存使用量区别更明显。查询消耗时间是用户在查询过程中最直接关注的参数之一,而查询内存使用量则需考虑操作系统指定的上限值。在查询内存使用量低于操作系统指定的上限值时,应使用处理过程2,当内存使用量高于操作系统指定的上限值时,应将两者结合使用,尽可能地缩短查询消耗时间。
4 结束语
通过将文件映射机制应用到实时历史数据库的单点时刻查询模式和多点时间段查询模式中,可以大大减少查询过程中打开文件、移动文件指针、读写文件等文件处理操作,缩短查询时间,提高了实时历史数据库查询历史数据的执行效率。
参考文献
[1]Jeffrey Richter.Windows核心编程[M].北京:机械工业出版社,2008.
[2]Stephen Prata.C Primer Plus(第五版)中文版[M].北京:人民邮电出版社,2005.
[3]900MW压水堆核电站系统与设备(下册)[M].北京:原子能出版社,2004.
天猫双十一销售额实时数据 第2篇
为了全面直观展现当天消费者购物场景和节日气氛，水立方会议报告厅搭建起了实时直播数字大屏，相比去年的13米长、6米高，今年的显示屏升级到了20米长、10米高。
直播大屏将提供实时信号，包括数据大盘、全球交易图、热卖品牌榜、菜鸟物流雷达预警等。
1分12秒交易额过10亿元
现场大屏幕提供的实时数据：
开场18秒，天猫交易额超过1亿元。
1分12秒，交易额就突破10亿，去年这个时间，交易额刚突破1亿元，今年第一分钟的交易额度增长了10倍。
1分45秒，数据显示天猫跨境贸易的交易额超过去年双11全天的数据。
5分钟，交易超过43亿元，是去年同期交易额的一倍多。
12分28秒，天猫交易额就超过了100亿元，而去年这个数字用了38分钟28秒。
31分钟，达到191亿元，是双11全天的交易额。
33分53秒，交易额超过200亿元。
1小时13分59秒，交易额突破300亿元。
环境信息化中的实时数据库应用 第3篇
实时数据库的优势
大多数环境信息化系统的数据量都较为庞大，以环境监测和污染源监控管理系统为例，系统需要接入大量实时的污染源自动监控数据和环境质量自动监测数据，而常规数据处理方式会带来数据存储时间不长、精度不高、存取效率低下等诸多问题，而与此同时，数据量的增长与系统运行效率成反比，大幅增长的数据会逐步影响平台的正常运行。
为解决上述矛盾，人们在技术层面上一般采取构建分布式关系数据库集群的方案，这无疑会增加硬件构架的复杂性，并增加维护管理和设备投资成本。
针对以上问题，系统构架者可选择采用成熟的实时数据库产品及相关技术解决方案。实时数据库构建树状数据模型，能够提供大量、不间断的存储，支持多种压缩，存储容量大，提供大量数据挖掘分析功能，在高速、大量的存储时能够提供多并发的高速查询，弥补关系数据库在实时数据存储、分析、查询方面的不足，改善关系数据库应用过程中系统响应速度下降、系统崩溃等问题，大幅提高系统安全性和运行效能。
污染源在线监测与分析系统
“污染物治理设施过程（工况）在线监测及分析系统”（简称“污染源在线监测与分析系统”）是污染源自动监控系统的进一步深化，其从原有的“末端监测”基础，深入到污染治理设施的运行，通过抽取出代表设施运行的模型和工况参数，精确描述设施运行的状态，为提高自动监控数据有效性、优化治污设施运行，及环境监察执法、总量减排、排污收费等各种管理应用提供可靠的数据支撑，该系统采用的正是实时数据库产品及解决方案。
工况在线监测及分析系统是对污染治理设施运行全过程进行实时监控、分析、预警、核查和管理的一体化环保信息化管理平台。系统结构分为四层：采集层、网络层、数据层和应用层，数据直接来源于生产控制系统、治污设施控制系统和自动监控系统。
工况在线监测及分析系统主要满足了环境监管部门日常监管工作需要，可以实现重点污染企业污水、废气过程参数的实时查看、分析、报警和辅助决策，过程参数与污染源自动监控数据可进行一致性校验分析，支持环境执法、总量核定和排污统计等环保业务。
污染物治理设施过程（工况）在线监测及分析系统以实时数据库为基础，在工况验证分析、工况数据统计两个基础平台的支撑下，实现对工况数据的分析和应用，主要包括系统管理、实时监视、趋势分析、报警、工况统计、工况核定、总量核定、企业交互及报表分析等功能。
数据库结构设计
工况在线监测与分析系统数据库结构
工况在线监测及分析系统数据库按照分布式多级数据库方式进行设计，主要分为三个层次：前端工况过程数据库层、中心工况过程数据库层、中心工况应用数据库层。
前端工况过程数据库和中心工况过程数据（原始库与分析库）采用实时数据库，由于工况系统需要存储大量的数据，因此需在存储前进行数据压缩。实时数据库具有数据压缩功能，可以用非常小的空间来存储大量的数据，而且还能保持相当不错的数据精度。
前端工况数据库层由布置企业前端的工况现场前端工况数据库组成，它是分布式过程数据库的基础层。前端工况数据库的作用是在企业前端将全厂的工况数据做汇总，由于其布置在前端现场，存储数据只受现场采集设备、采集网络及现场供电情况的影响，故其完整性在整个系统中是最高的。
前端工况过程数据库还有一个重要的功能是通过数据转发模块向中心工况过程数据转发实时工况数据，转发模块在网络出现异常时会记录最后发送的记录情况，在网络恢复时会将网络中断时间内的历史工况数据回补到中心工况过程数据库中，从而保证中心工况过程数据库中工况数据的完整性。
中心工况过程数据库层由原始库和分析库两个工况过程数据库组成。原始库主要是存储、汇总与前端工况数据库一致的工况过程数据，同时采集参数名称也与工况现场完全一致。分析库主要是将原始库中的数据依据一定的标准化规则转换成工况分析所需要的数据，包括采集测点的标准化、采集参数的实时计算（换算）、实时分析结果的存储等。
实时数据库应用情况
实时数据库在数据采集、存储、显示、分析方面拥有显著优势，所以在工况在线监测与分析系统中得到了广泛应用。
数据处理能力：工况在线监测与分析系统数据庞大，要求数据库读取数据和存储数据的能力能跟上节奏，实时数据库具有海量数据处理能力，读取实时数据库的时间是毫秒级，同时支持百万级单数据库的容量。
实时工况监控：工况监测的一个重要功能就是实时监测，即将工况的实时数据真实准确地反映在工况实时图形界面上。工况实时图形界面不但要具备实时显示模拟量的数值变化，还要能显示开关量的变化情况，系统通过红、绿、黄颜色分别代表运行、停运、故障。
火电厂工况实时图形界面
趋势分析：实时数据库能准确记录数据的变化趋势，方便监测人员查询调阅历史数据变化趋势。实时数据库提供实时数据对比分析、历史数据对比分析、自定义趋势组、表格显示数据、数据导出、前进、后退、放大、缩小和打印等功能。
数据查询：主要针对采集的排污数据、状态数据、过程数据进行综合查询。
报表系统：报表工具基于J2EE的B/S报表平台，能够实现统计参数的在线配置、数据自动统计、报表模板定制及发布等功能。
工况报警：实时及历史报警可视化工具可以显示当前或过去某段时间内的报警详细信息，提供报警过滤、报警数据导出、报警鸣笛等功能。在火电厂工况系统中，报警主要分为网络报警、机组停运报警、脱硫设施停运报警、污染物偷排报警、超标报警报警、脱硫设施低负荷运行报警、脱硫系统参数异常报警。
工况数据关联性分析：主要依据实现定义的分析模型对工况进行综合分析，以电厂为例，可以判断发电机组、治污设施的运行情况是否正常、污染源监测数据是否可靠，及时发现发电机组生产过程、治污设施、监测系统中可能存在的异常情况，如偷排、治污设施虚假运行等。
关系数据库与实时数据库结合
当前，很多项目的数据层设计都采用关系数据库与实时数据库相结合，工况在线监测与分析系统中，前端工况过程数据库和中心工况过程数据（原始库与分析库）采用的是实时数据库，中心工况应用数据库层由通用关系型数据库来承担。
对于实时采集的数据需要能够进行数据分析，并与关系数据库进行数据交换，能够根据业务需求配置相关数据统计规则，定期统计、抽取实时数据库数据至关系数据库中，实时数据库的测点能够与关系数据库进行映射，构建实时数据库的横向业务关系模型，能够根据业务需求，实时地组织实时数据，构建关系模型，并提供给业务系统。
实时数据库是采用实时数据模型建立起来的数据库，用于处理不断更新、快速变化的数据，以及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术相结合的产物，利用数据库技术来解决实时系统中的数据管理问题，同时利用实时技术为实时数据库提供时间驱动调度和资源分配算法，其主要应用于自动连续数据的监控，如电力、环保、石化、化工、钢铁、冶金、造纸、交通控制和证券金融等领域。
实时数据库与关系数据库的结合解决了连续自动数据采集所带来的并发性、高速存取、数据存储、系统性能等问题，同时也能利用关系数据中的对象关系、事务处理、自定义结构等来优化系统数据的利用。
实时历史数据库 第4篇
关键词：面向对象,链表,管道腐蚀检测,数据展示,数据回放
1 问题提出
当前,已有第三方控件[5,6,7,8]可以实现对数据进行图形展示,但在实现数据图形展示与回放方面面临诸多困难[9,10]:
(1)图形展示过程中海量数据存储对计算机内存的消耗瓶颈问题。
(2)图像历史回放过程中坐标变换问题。
(3)数据图形展示过程中局部图形縮放与关键时间段图形趋势追踪与切换问题。
(4)数据图形关键点搜索与定位回放问题。
(5)程序运行稳定性欠佳,内存“溢出”现象时常发生。
为此,基于Microsoft Visual C++平台,设计了一系列关键数据结构与算法,经实际运行测试,能较好解决上述设计中存在的技术问题。
2 系统体系结构[11,12]
管道腐蚀检测系统基于客户/服务器(Client/Server)结构,以MySQL作为数据存储,采用面向对象可视化编程工具Microsoft Visual C++6.0作为开发平台,其主要组成包括:服务器端的监控器(Monitor)和用户端的浏览器(Viewer),如图1所示。
监控器(Monitor)主要实现实时数据采集、存储、显示和管理最多可达247个监测点的金属损失、温度、腐蚀率数据,并图形化展示多监测点金属损失、温度、腐蚀率发展趋势,如图2所示;浏览端(Viewer)主要实现在接入局域网或因特网的计算机上浏览监测数据曲线,主要功能界面与监控器(Monitor)相似,不仅可以同步展示监控器(Monitor)当前状态,实现所有图形展示功能,还可对历史数据进行回放、縮放、定点搜索与定位回放等,以实现系统分析功能。
3 关键数据结构设计
3.1 公共对象类设计
Monitor和Viewer两大子系统在功能实现上有很多相似之处,因此本系统将相似功能抽象成若干公共对象类,主要包括:
3.2 关键数据结构设计
传统图形展示数据存储依赖于所用开发工具封装的相关数据控件,其数据存储、置换策略与交互性能取决于控件封装性能特征,本系统曾基于第三方控件进行开发设计,面临的问题主要表现为:
(1)图形变化迟缓,个别应用屏幕图形刷新耗时过长,不能满足工程要求。
(2)图形刷新数据交换频繁,内存消耗过高,时常出现死屏现象。
(3)图形回放、縮放效果低下,乱屏现象时常发生。
(4)图形定位、拐点搜索、特征点跟踪效果较差,实现复杂。
为此,本系统采用经典链表数据结构实现关键图形数据存储、动态分配与释放,同时也便于进行图形定位及搜索,链表数据结构为:
其中Data为数据节点结构描述,用于存储图形展示数据,LNODE为实时链表节点结构描述,用于提供对数据节点进行遍历所需相关信息支持,以实现文中相关算法,其节点结构示意图如图3所示。
为便于数据图形展示,方便图形回放、数据追踪、图形局部縮放等操作,设置特征值时间链表,其结点结构为:
为便于实现数据图形刷新,通过设置链表头节点指针等指针变量,并设置用于记录当前数据图形展示状态的相关指针数组,从而根据图形展示需求,实现数据图形的快速定位回放与追踪。本系统设置的主要链表节点指针变量有:
4 实现技术
4.1 实时图形展示和历史图形回放切换
正常情况下,Monitor端主要用于实时展示腐蚀趋势。但是,当实时展示图形出现异常时,也要求能进行历史数据回放,以反映图形变化的趋势特征。
本系统主要采用3条链表,即链表Drawhead、链表Head和链表p,如图4所示。
(1)Drawhead链表。主要用于保存当前接收的数据,该链表数据随着检测仪不断检测数据而增加,始终保存当前选择显示时间范围数据,如果数据个数超过显示时间范围个数,接收到新数据就丢弃(置换)旧的。
(2)Head链表。对于向后查看历史数据问题,链表Head用于保存查看历史数据时当前选择的显示时间范围所显示数据,从数据库中读取数据。
(3)p链表。链表p用于保存当前在屏幕上显示的数据,根据实际情况显示当前数据或者历史数据,从前面两条链表接收数据。
显示当前数据还是历史数据,由一个开关backorforward决定。当backorforward为0时,当前为实时展示,否则为历史展示,从而切换当前所使用链表数据。
当重新设置了显示时间范围,如果当前Backorforward值为0,则按实时展示处理;如果当前Backorforward值为1,则按单击“前进”按钮事件处理;当前Backorforward值为-1,则按单击“后退”按钮事件处理。
4.2 历史数据回放
本方案采用链表totalhead保存所有数据,即每次读数据库都将所有数据读取出来,如图3所示。用Timelink[i]链表组表示每一个时间坐标所在区间的结点,其中i根据具体时间坐标设定,一般与时间坐标一致。用Currenttime[i]指向第i个链表的当前结点。
例如,如果Timelink[j]当前显示时间范围为1天,则时间区间为2个小时,那么Timelink[j]每个结点就指向Totalhead中每隔2个小时的第一个结点。如果Timelink[j]当前显示时间范围为1年,则时间区间为一个月,那么Timelink[j]每个结点就指向Totalhead中每隔一个月的第一个结点。这样,当选择后退或者前进时,根据Timelink[j]就能直接找到下一区间所指第一个结点,然后再寻找“正确”的当前结点。通过该方法,可节省结点查找时间开销,只需要查找少量结点,即可查找到正确的点。关键算法如下:
4.3 腐蚀趋势变化曲线绘制
监控端曲线绘制主要在于实时显示监测到的数据变化趋势,而且同时可以回退查看以前历史数据变化曲线。所以,曲线绘制难点在于实时数据变化曲线和历史数据变化曲线之间的切换,下面给出本系统解决方法。
创建三条链表,分别为currentlink链表、historylink链表和drawlink链表。
(1)currentlink链表。用于保存当前实时监测得到的数据,该链表数据量随着不断监测到数据而增加,如果链表不存在空单元,则接收到新的腐蚀数据就丢弃旧腐蚀数据,但该链表始终保存某一设置时间区域范围内腐蚀数据。
(2)historylink链表。用于保存绘制历史数据变化曲线时某一设置时间区域范围内数据,历史腐蚀数据来自数据库。
(3)drawlink链表。用于保存当前屏幕上显示腐蚀变化曲线的数据,根据实际操作情况保存当前实时监测数据或者是历史监测数据,该链表数据来自前面两条链表。
参考文献
[1]张慧敏,潘家祯,孙占梅.现有埋地管道腐蚀检测方法比较[J].上海应用技术学院学报,2004,4(2):104-110.
[2]杨永,何仁洋,杨剑锋,等.埋地钢质管道腐蚀防护综合评价系统研究[J].管道技术与设备,2004,(2):11-14.
[3]李岩,屈祖玉,罗德贵等.埋地钢管牺牲阳极保护计算机辅助设计与实现[J].腐蚀科学与防护技术,2005,17(5):345-348.
[4]罗金恒,王曰燕,赵新伟等.在役油气管道土壤腐蚀研究现状[J].石油工程建设,2004,30(6):1-7.
[5]韩林,王海文,陈镭.VB中使用Tee Chart Pro4控件实现绘制和打印坐标图功能[J].计算机系统应用,2001,(9):67-69.
[6]朱玲,武玉强,张启宇.Tee Chart实现工控领域的实时曲线和历史曲线的方法[J].工业控制计算机,2005,18(8):39-40.
[7]赵树强.基于Tee Chart控件的外测数据图形分析系统的开发[J].飞行器测控学报,2005,24(2):88-92.
[8]王瑞荣,王建中,薛安克.面向虚拟仪器的图形化语言开发环境设计[J].计算机工程与应用,2005,(23):105-108.
[9]金安,姚建刚,葛亮等.Java数据流技术在远程实时数据图像处理中的应用[J].现代计算机,2004,201(12):73-76.
[10]丁益祥.如何用Delphi存取Microsoft SQL Server中的图像数据[J].武汉科技学院学报,2005,18(11):107-109.
[11]封亚斌.采用串口通信技术实现Modbus数据通信[J].自动化仪表,2004,25(10):56～58.
飞机实时监控数据挖掘方法研究 第5篇
飞机实时监控数据挖掘方法研究
通过数据挖掘技术分析与飞机运行和维护相关的.数据资源来研究一套能及时察觉、分类并预报故障的飞机实时监控系统(Aircraft Real-Time Monitoring & Troubleshooting System,AMTS),使其能够在优化飞机关键部件寿命的同时减少飞机运行和维护的费用.分析着手于历史维护经验库,结合飞机维护技术文档和相关数据挖掘算法,介绍了构建该系统的原理和方法,并初步实现利用飞机实时故障报文对飞行状态进行实时监控及故障诊断.
作 者：朱睿 郭隐彪 ZHU Rui GUO Yin-biao 作者单位：厦门大学机电工程系,福建,厦门,361005刊 名：厦门大学学报(自然科学版) ISTIC PKU英文刊名：JOURNAL OF XIAMEN UNIVERSITY(NATURAL SCIENCE)年，卷(期)：46(5)分类号：V267 V247.5关键词：数据挖掘 实时监控 技术文档 历史经验
实时数据库RTDB的研究 第6篇
1 实时数据库及其特征
实时数据库系统 (RTDBS) 中事务和数据都可以具有显式的定时限制, 系统的正确性不仅依赖于事务执行的逻辑结果, 还依赖于逻辑结果产生的时间。它已经引起了数据库和实时系统两个领域里的研究工作者们的极大关注。数据库研究工作者旨在利用数据库技术来解决实时系统中的数据管理问题, 实时系统研究工作者则致力于为RTDBS提供时间驱动调度和资源分配算法。
下面分析传统数据库、实时系统 (RTS) 和实时数据库 (RTDB) 彼此间的联系与差别以说明什么是RTDB、为什么要研究RTDB。
1.1 数据库与实时系统
传统数据库系统组合了多种功能:数据描述 (模型、模式) ;数据正确性维护 (完整性、一致性控制) ;有效的数据库存取 (数据库组织、操作与存取方法) ;查询与事务的正确执行 (查询处理、事务管理、调度与并发控制) ;数据的安全与可靠性保护 (安全性检验、恢复) 。
随着当今实时系统处理的信息量越来越大, 对这些功能的要求也越来越迫切。但在传统的数据库系统中, 其设计与开发主要强调维护数据的正确性、保持系统代价低、提供友好用户接口等。这种数据库系统对传统的商务和事务型应用是有效的, 但它不适合于实时应用, 关键在于它不考虑数据、事务及其处理相关的定时限制 (timing constraint) 。系统的性能目标是吞吐量和平均响应时间, 而不是各个事务的定时限制。
相反, 实时系统 (RTS) 所支持的应用具有很强的时间性要求, 其处理活动与数据都具有定时性。然而传统的实时系统典型地处理具有简单和可预报数据 (或资源) 要求的简单任务, 不涉及维护共享数据的一致性问题。
数据库与实时系统的结合导致了实时数据库的产生, 它集成两者的概念与要求以同时处理实时性与一致性, 这使得事务的调度与处理等问题要复杂和困难得多。
1.2 传统数据库与RTDB
传统数据库与RTDB在许多方面都不同, 最重要的是RTDB有不同的性能目标、正确性标准和关于应用的假定。不像传统数据库系统以快的平均响应时间为主要目标, 评价一个RTDBS是以其事务超截止期的比率、平均延迟度和承受的代价、数据的时间一致性为指标。
对于传统数据库, 其事务具有ACID (Atomicity, Consistency, Isolation, Durability) 特性。在RTDBS中, 则有根本的不同, 其事务由下列特性 (概念) 确定:
(1) 可见性:事务执行时可查看另一事务的能力。
(2) 正确性:事务的时间正确性、事务本身的逻辑正确性及事务提交时数据库状态的一致性。
(3) 可恢复性:发生故障时使数据库成为某种被认为是正确状态的能力。
(4) 永久性:事务记录其结果到数据库及识别其中数据的有效期的能力。
(5) 可预报性:事先预测一个事务是否会满足其时限的能力。
(6) 不可逆性:有些事务的执行不能像传统意义上那样ABORT和RESTART, 事务执行的失败可能需要别的事务来“补偿”或“替代”。
因此, 在实时应用环境下, 数据库的处理必须支持:
(1) 传统的平坦原子事务模型已不适用, 要求“复杂事务”。
(2) 事务的合作、协调而并发地执行, 即要求事务间的直接交互作用和通讯。
(3) 及时性比正确性更重要的性能标准, 有时宁愿要及时而部分正确的信息, 而不愿得到完全正确但是过时 (无效) 的信息。
(4) “识时”协议和“时间正确”的调度与并发控制, 至于对传统数据库最重要的可串行化调度与并发控制倒不一定必需。
(5) 数据的时间相关性, 即数据存储、组织与存取都是“识时”的。并非所有数据都是永久的, 许多是短暂的, 甚至不一定要求所有结果都记录到永久数据库中。
(6) 恢复不一定就是数据库状态的完全复原, 要特殊的提交与恢复机制。
所以RTDB与传统数据库在概念、原理、结构、算法等方面都存在着很大的差别, 最根本的区别就在于数据与事务的定时限制。这里要指出的是, “实时”并非简单地意味着快, 快固然需要, 但对RTDBS而言, 实时指的是能施加和处理“显式”的定时限制, 即使用“识时协议” (time-cognizant protocol) 来处理有关的截止时间或定时限制。
2 RTDB中的时间
RTDB系统要使用有效时间和事务时间, 有效时间用于在现实世界中有直接匹配对象的数据, 对应于改变这些物理对象的外部事件需要严密监视, 一旦发生, “输入接受”事务 (只写) 立即记录其变更值到数据库。事务时间用于借助RTDB和专门的输出设备给实时系统设置参数的“控制”事务、事件和导出数据的值, 与导出值相联的一般是事务的提交时间。
实时数据库涉及的时间信息与时态数据库 (TDB, Temporal Database) 中的有联系又有区别。时态数据库旨在包含随时间变化的信息, 它维护数据库中数据对象经历的变化历史, 外部环境的一个对象在数据库中可能存在多个对应不同时刻的映像值, 现实世界对象状态的变化并不一定引起数据库中对应者的修改, 而是在数据库中增加一新项, 用户可以查询对象的历史。在TDB中存取数据的事务并没有“显式”的时间限制。
相反, RTDB提供维护数据有效性和事务及时性的设施, RTDB对象因现实世界中对应者的状态改变而适时地相应修改, 其历史状态依应用可以保留也可不保留, 而且一般只允许事务存取数据库中当前 (有效的) 信息。事务必须维护数据库对象的“时间一致性”, 同时事务本身还有来自应用语义的定时要求, 故事务有时间限制与之相联。这就是RTDB与TDB的最大区别之所在。
由于所存取的数据的时间一致性要求和物理世界施加于控制系统的反应时间要求, 实时数据库系统中事务存在各种各样的定时限制, 典型地表现为事务的截止期 (deadline) , 它定义为事务t在能给系统带来最大价值的前提下能最晚提交的时间, 记为dl (t) , 即
式中, V (t, τ) 表示事务t在时刻τ提交时给系统带来的价值, MAX_V (t) 表示事务t能带来的最大价值。
3 RTDB的数据、事件及活动的时间限制
RTDBS就是其事务与数据都可以具有定时特性和/或显式的定时限制的数据库系统。故首先讨论RTDBS的数据、事件及活动 (事务) 的时间特性。
3.1 数据的时间限制
在RTDBS中, 数据只在一定时间 (外部有效期) 内是当前有效的, 所以我们不能只考虑数据库内部状态的一致性, 还必须考虑外部世界与内部状态的一致性, 同时也必须考虑不同数据间的相互时间一致性。
在RTDBS中, 与每一数据相联的有一“外部有效期” (或简称有效期) 。按这种时间分类, 数据可以是非实时数据和实时数据。传统数据库中的数据即为非实时数据, 可认为它是“有效期”任意长的实时数据;实时数据的采样 (或计算) 值有效性在其“当前值”建立以后不应超过一指定的时间。RTDB中有两类实时数据, 一类是由传感器事务自外部环境直接写入数据库的, 我们称这类数据对象为“映像”对象;另一类是由映像对象推导出来的数据对象称为导出对象。
定义1.1一个RTDB的数据对象为一个三元组d:
定义1.2 (内部一致性) 当且仅当d满足所有预先定义的完整性和一致性限制时, 数据d是内部一致的。
内部一致性概念相当于传统数据库的正确性或完整性概念。
数据库的变更都是以事务的形式进行的, 因而操作的完整性和可串行化能提供内部一致性保证。
在RTDBS中, 数据库依靠逻辑世界与外部环境频繁地交互作用来获取准确、及时的数据, 所以一个正确的数据库状态必须与外部环境当时的实际状态一致。
定义1.3 (外部一致性) 数据d是外部 (或绝对) 一致的, 当且仅当 (τc-dtp) τdevi (τc为当前或检测时间) 。
当一组相关数据对象被使用时, 它们之间存在着时间上的相互 (或相对) 一致性问题。如两个传感器分别独立地读取飞行器的x坐标与y坐标的信息, 这两个值往往不会在完全相同的时刻进入系统。使用它们的事务必须知道它们是否对应对象在同一时刻或彼此充分接近的时刻的采样值。
定义1.4 (相互一致集) 用来作决策或导出新数据的一组数据对象称为一个相互一致集, 记为R。每一这样的R都有一与之相联的有效期, 记为Rmvi。
定义1.5 (相互一致性) 设R是一个相互一致集, d∈R。d是相互 (或相对) 一致的, 当且仅当:
实时数据库事务的执行不仅要考虑事务的截止期, 同时还应考虑事务所用数据的有效性 (外部一致性) 及不同数据间的相互一致性, 它们都与时间相关, 统称为时间一致性。
定义1.6 (时间一致性) 若一个数据既是外部一致的又是相互一致的, 则说它是时间一致的。
定义1.7 (数据的正确状态) 当且仅当一个数据同时是内部一致和时间一致的, 才说它具有正确的状态。每一数据都具有正确的状态, 则说数据库有正确状态。
在RTDBS中, 不光是数据存在时间限制, 还存在与事件相联的时间限制及与活动 (事务) 相联的时间限制。
3.2 事件的时间限制
在实时应用中, 各种活动一般由相关事件的发生所触发, 即与每一活动相联的是一个事件的发生, 因此, 施加于活动上的某些类型的时间限制来自于触发这些活动的事件的定时限制, 故先要弄清有关事件的定时特性。基本上有3种这样的时间限制: (1) 最大:两事件之间的最大时差。例如一旦一目标进入雷达的视野, 目标识别的完成必须在τ1 s内。 (2) 最小:两事件间的最小时差。例如两个飞机的着陆必须至少隔τ2 s。 (3) 持续:一个事件经历的时间长度。例如在“请系好安全带”信号关停前飞机必须经历至少τ3 s无颠簸平稳飞行。
在上述讨论中, 事件可以视为一种行为的瞬时发生, 也可作为一种有限的短暂行为过程, 若是行为的瞬时发生, 则在上第3例中的事件持续经历可看作为以简单事件来标志它本身的开始和结束的复杂事件;若是行为过程, 则上述第1、2例中的瞬时事件可看作其行为过程极短的事件。
3.3 活动的时间限制
在讨论了关于事件和数据的时间限制以后, 现在不难明确关于活动的时间限制的语义, 因为事件发生要由与之相联的活动来处理, 故关于事件的时间限制将直接作用于这些活动, 如重复发生的事件的时间限制则转换成相应活动的周期性要求;输入或激发事件与其响应 (或输出) 事件之间的“最大”时间限制则决定相应活动的截止期等。换句话说, 关于事件的时间限制将转换成处理这些事件的活动的时间限制。关于活动的时间限制归纳有:
(1) 外部环境行为所决定的时间限制限制输入的频率与到达系统的时间。例如, 在空中交通管制系统中, 飞行指挥员必须到距机场10 min的飞行距离时请求允许着陆。
(2) 系统性能规定的时间限制决定系统对输入的响应。例如发出允许着陆请求后, 系统必须在30 s内作出响应。
(3) 数据的时间一致性所施加时间限制限定感知外部环境并更新系统数据库的活动。例如更新飞机的各种动态参数的活动必须以指定的周期执行, 这种活动有截止期, 它依数据的外部有效期而定。
(4) 此外, 还有一种解决问题方法可行性所决定的时间限制, 它限定系统内部行为以使有关解决问题方法能成立。例如, 在分布式系统中, 各种结点状态的相互同步通信的及时性常常用来作系统故障的检测。若在给定的时间范围内, 一个结点未收到另一正常结点的“我是正常的”消息, 则可能出故障, 要调用代价高的故障诊断程序来进一步诊断。
基于上述原因, 实时事务也有外部一致性和相互一致性, 外部一致性指满足外部环境所施加的定时特性, 包括数据的外部一致性转换而来的限制。相互一致性就是涉及事务正确性的各事务有效时间之间的相关性, 包括数据的相互一致性。
3.4 RTDB的事务特征
传统的并发控制技术和事务处理方法能够保证数据库的内部一致性, 而为了保证数据库的时间一致性, 必须采用“识时” (time-cognizant) 事务处理技术, 对传统的并发控制技术和事务处理方法进行改造。为此, 必须明确RTDBS的事务特征。
传统事务具有ACID特性, 前三者分别为“故障原子性”、“并发原子性”和“执行原子性”, 统称原子性, 故原子性和可串行化是事务正确性的通用准则。而在RTDBS中, 有以下方面必须考虑:宁愿要部分正确而及时的数据而不愿要绝对正确但已过时 (无效) 的数据, 系统可以忍受短暂的数据库状态在一定范围内的不一致性以提高并发度, 满足事务的截止期;事务之间有联系, 事务执行过程中的结果对某些其它事务是可见的;并非所有数据都具有永久性。
在RTDBS中, 事务最重要的特性是定时性, 它包含两方面的含义:定时限制事务的执行具有显式的定时限制, 典型为截止期。事务 (或系统) 的正确性不仅依赖于其逻辑结果的正确性, 还依赖于逻辑结果产生的时间。这是由于系统需要随时跟踪外部环境而引起的。定时正确性事务能按合适的时间要求正确执行。这是由于要求数据对于系统的各种决策活动随时有效所引起的, 它要求权衡定时限制与数据一致性等多方面因素, 提供合适的调度算法。
由此可见, 事务的时间限制来自于数据的时间一致性要求和/或施加于系统反应时间的要求。
4 结语
实时数据库系统 (RTDBS) 与传统关系数据库相比, 其事务和数据都可以具有显式的定时限制, 系统的正确性不仅依赖于事务执行的逻辑结果, 还依赖于逻辑结果产生的时间。因此它更适应于目前高速发展的移动计算技术和移动通信需求。
参考文献
[1]刘云生.现代数据库技术.第1版.北京国防工业出版社, 2001
[2]U.Dayal, B.T.Blaustein, A.P.Buchmann, et al.The HiPAC project:combining active database and timing constraints.ACM SIGMOD Record, 1988, 17 (1) :51～70
[3]N.W.Paton, O.Díaz.Active database systems.ACM Computing Surveys, 1999, 31 (1) :63～103
[4]R.Rifaat, S.L.Argue.Developing an engineering database for rural underground distribution projects.in:P.Kindred, D.Harley, eds.IEEE Western Canada Conference on Computer, Power and Communications Systems in a Rural Environment Regina, Sask, Canada.1991.New York:IEEE Computer Society Press, 1991.171～178
实时数据库设计的关键技术 第7篇
关键词：实时数据库,事务模型,事务规划,并发控制,I/O规划
1引言
和传统的数据系统一样, 实时数据系统的功能是数据的知识库, 提供高效率的数据存储, 完成信息的查询和操作。实时事务是实时数据库的基本单元，按照完成点的不同，事务可以分成硬、软和严格实时事务。硬完成点的事务必须满足它们的完成点，否则系统不能满足性能指标。软实时事务有时间约束，但是当一个事务通过它的完成点而没有执行时，可以有一些时间余量来完成这个事务。和前两类事务相比，严格实时事务一旦通过它的完成点，则这个事务不再被考虑。因而，作为实时系统的一部分，实时数据库的各项任务是和时间约束密切相关的。用当前的技术很难提供一个满足事务完成点的绝对可靠的方法。因此实时数据库被大部分限制在软实时系统。有几个因素使得实时数据库很难满足所有时间约束。首先，数据库事务的执行通常是数据和资源相关。为了满足事务完成点需要大量的额外资源去适应最高的系统负载。再者，完全的事务支持包括许多数据库协议，而这些协议的执行时间很大程度上是不可预测的。最后，基于磁盘的数据库系统和I/O子系统频繁相互作用。如磁盘寻找时间变化、缓存管理和导入导出页失败等问题，引起平均和最差的执行时间变化很大。所有这些增加了事务的不可预测性。
2实时数据库设计的主要问题
事务模型：
在一个实时事务的属性中，完成点是最重要的一个属性。其被应用于实时数据库系统的许多方面，如并发控制、规划、不精确的计算等。通常一个事务的完成点被设计人员指定。但是，如果事务模型支持嵌套或子事务，有一个问题是在父事务的完成点要求下约束如何被赋给单个的子事务。
到目前为止，我们假定实时约束专用于事务。Korth等人提出了一个不同的模型完成点和一致性约束相关。在他们的模型中除了维持系统正常状态的事务以外，事务可以被激活以记录产生在系统外部的一些外部时间的影响。在数据库状态的真实改变可以产生一个一致性约束无效。这个一致性约束可以需要在一个特定的完成点被恢复。但是不一致性被检测到，一个补丁事务被激活试图纠正这个错误。但是这个补丁事务可能违背其它的一致性约束。这可能导致一个事务触发链。
一致性恢复的方法如下：首先分析实时系统，构建一个预测优先级图（PPG）。当一个约束被违背时，通过分析预测优先级图，一个补丁计划被构建。这个计划可用PPG的一个不一致性的解子图（IRS）所表示。直观上讲，一个不一致解子图给出事务执行的部分序列, 使得一致性约束被恢复。
事务规划：
实时系统研究的一个主要工作是多用户程序环境下工作的规划。事务规划的工作, 包括CPU、数据、I/O、内存等。在这里主要讨论事务的优先级如何分配及CPU调度。
实时规划算法优先处理关键的任务。一个通常的做法是根据任务的紧急程度赋给不同的优先等级。如下列公式所示：
其中γ是事务的重要度，w i是加权值，a是事务的优先级，d是事务完成点，c是已经完成的工作数量，l是未完成的工作数量。优先级计算的实时规划算法是基于未完成工作的数量和延迟，要求有一个好的事务时间预测。
并发控制：
并发控制是指并发事务中的一种交互控制方式，使得保持数据库的一致性。两个碰到的主要问题是优先级转换的可能性和死锁。解决优先级转换的方法之一是有条件启动重新算法。
其中：EH:=估计剩余运行时间TH
SR:=估计延迟时间TR pr (TR) >pr (TH)
如果TR的延迟时间更长超过TH的运行时间, TH允许被完成不损失TR的完成点。
死锁是可能碰到的第二个问题。当一个事务的集合在一个环路等待，一个死锁发生。这种情况下，在死锁中的一个事务被选择终止，选择终止事务的策略包括：
(1）、终止一个已经通过它的完成点的事务。
(2）、终止一个最长完成点的事务。
(3）、终止一个最次要性的事务。
实验证明，当死锁发生时，通常死锁内仅包含两个事务。因此使用复杂但是昂贵的解决死锁冲突算法是不明智的。
I/O规划
在基于磁盘的数据库系统中，磁盘I/O占据了事务执行时间的大部分。考虑时间的磁盘规划算法极大地改进了实时系统性能。常用的算法如电梯算法和先执行最高优先级组的算法。
先执行最高优先级组算法是模糊了优先级的边界，磁盘请求被分成几组小的优先级，磁盘被规划首先去服务最高优先级的组，如果最高优先级的组中超过一个请求，电梯算法被用于内部组。
实验表明先执行最高优先级组算法（HPGF）在满足完成点方面的性能超过电梯算法，但这是以加长平均反应时间为代价。研究显示反应时间主要对低优先级请求方面的影响较差，而对高优先级的反应时间非常接近电梯算法。
缓存管理和缓存驻留数据库
缓存影响事务反应时间存在两种方式。首先，在一个事务开始它的执行以前，缓存必须被分配到事务，这些缓存被用于存储磁盘上的执行代码，文件拷贝和数据页以及一些临时文件，一定数量的缓存必须被分配以防止事务花费大量的时间从磁盘交换数据。当缓存容量低时，一个事务可以分块执行。一个系统中可得到的内存数量因此限制了并发执行的事务数量。再者，一些高容量的缓存应用中，如果缓存数量有限，经常的内存交换引起事务执行速度的大幅度下降。
缓存管理的工作是去分配内存缓冲区给所要执行的事务，使得高优先级的事务享有更短的反应时间，一个缓冲管理器的工作通常按照它的允许和缓冲替换的时间决定。当一个事务T被发布的时候，缓冲管理器将决定是否允许去执行事务，这个决策被称为事务允许策略。常用的事务允许策略是挂起最低优先级事务直到：（1）.足够容量的缓存被释放给T去执行。（2）.没有更多挂起的事务，其优先级小于事务T。第一种情况，释放的内存被分配给T, T执行。第二种情况，由于缺乏内存T被锁。
替换缓冲的选择被称为缓冲替换策略，传统的替换策略包括最近最少使用策略（LRU）, 最少经常使用策略以及带优先级的最近最少使用策略。
内存驻留数据库
跟磁盘比较而言，主存访问时间更快也更具有预测性，这些特点对于严格规定事务完成时间的实时数据库系统而言是非常必要的。但是，放所有数据到内存也有它的不利之处。其一，价格比基于磁盘的系统更昂贵。其二，主存的易失性问题。存储在主存中的数据当停电或CPU出现故障时会丢失。其三，驻留内存的设计目标和传统的基于磁盘的系统不同，传统数据库系统的数据结构和查询处理算法是减少访问磁盘的次数，而驻留内存的系统而言，当数据被驻留内存时查询优化和数据结构设计以最小化CPU处理时间和使用的内存容量。传统的访问方法和数据结构被修改。最后，小的数据访问时间也影响一个并发控制机制的选择。没有I/O延迟，事务执行时间将是很小的。由于数据锁的块延迟也将减少，我们因此有一个更粗糙的粒度为了数据锁以减少内存和处理器负载。
结束语
本文讨论了实时数据库和事务处理设计的相关问题。实时数据库区别于数据库系统和实时系统是它的更多需求目标限制在时间约束内。因此，子事务的合适完成点赋值对许多实时数据库协议而言是至关重要的。当实时数据库不断发展时，这方面的工作将有很大的空间。
参考文献
[1]D.Hong, S.Chalravarthy, T.johnson.AlternativeVersionConcurrencyControlforfirm real-timedatabasesystems.Tech.report UF-CIS-TR-95-031, 1995
[2]BenKao, HectorGarcia-Molina.An OverviewofReal-TimeDataBaseSystems.NJ, USA:Prentice-Hall.Inc, UpperSaddleRiver, 1995.463-486.
实时数据库数据压缩算法探讨与改进 第8篇
实时数据库 (RTDB) 作为组态软件的核心, 保存着系统运行时产生的各种数据和信息。这些信息对管理层及时了解生产现场的实时情况、实现上层信息系统与底层控制系统的集成都具有重要意义。随着RTDB应用领域的不断扩展, 对它的研究也越来越深入, 其中如何存储与管理实时数据库中大量历史数据的问题也受到了更多的关注。
参考文献
[1]方来华, 吴爱国, 何熠.组态软件核心技术研究[J].化工自动化及仪表, 2004, 31 (1) :33-35.
[2]王伟, 刘文怡, 秦丽, 等.遥测数据实时压缩技术的设计与实现[J].仪器仪表学报, 2006, 27 (6) :2467-2469.
[3]张景涛, 王华, 王宏安.实时数据的存取与压缩[J].化工自动化及仪表, 2003, 30 (3) :47-50.
[4]徐新.增强型矢量数据压缩算法的设计与实现[J].计算机应用研究, 2007, 24 (12) :393-395.
[5]WELCH T A.A Technique for High Performance Data Com-pression[J].IEEE Computer, 1984, 17 (6) :8-18.
[6]黄豪佑, 董辉, 卢建刚.历史数据压缩算法在DSP上的实现[J].计算机测量与控制, 2006, 14 (12) :1686-1688.
QCS实时数据库系统的研发 第9篇
工业自动控制的飞速发展, 呼吁与之配套的数据库技术的发展。传统数据库在非传统的工程和时间关键型应用方面显得力不从心, 而实时数据库在这里显示了它蓬勃的生命力。下文将结合一个开发的定量水分控制系统 (QCS) 实时数据库的实例对它进行研究。
2、实时数据库简介
2.1 实时数据库的发展与特征
数据库的应用正向新的领域扩展, 如过程控制、数据通信、电子银行事务、电子商务等。这些应用与传统应用有着不同的特征: (1) 要维护大量共享数据和控制数据; (2) 其应用活动有很强的时间性, 要求在规定的时刻或时间内完成;同时, 所处理的数据有一定的时效性。
实时数据库的基本特征恰好能满足这些应用特征, 这就是就它的时间相关性。实时数据库在如下两方面与时间相关: (1) 数据与时间相关; (2) 实时事务有定时限制。
2.2 实时数据库的应用领域
实时数据库有以下几个方面的应用:记录实时过程的历史数据;连接各类自控设备, 实现自动监控;通过数据库网络通信功能构建分布式应用系统;运行在控制系统的位机中, 实现可扩展的先进控制或优化控制目标。“定量水分控制系统数据库”主要是前两应用的体现。
3、实时数据库的结构
3.1 实时数据库的体系结构和系统结构
从系统的体系结构来看, 实时数据库与传统数据库区别不大。同样把数据库分成3个级别:内部级、概念级和外部级。数据库的3级结构是数据的3个抽象级别。
下表1以“定量水分控制系统数据库”为例, 描述了一个典型实时数据库系统结构。
“定量水分控制系统实时数据库”结构实现的部分代码如下:
3.2 实时数据库的数据结构
实时数据库与其它一般数据库一样, 包含一组对象及其结构。但目前对它还没有提出统一的数据模型。“定量水分控制系统数据库”采用了Access关系数据库的数据结构。以定量水分测量值数据表为例, 其数据结构 (即逻辑结构) 如下:
4、实时数据库系统的功能
实时数据库除具有一般DBMS的基本功能, 还具有以下三个功能特性:
(1) 数据库状态的最新性;
(2) 数据值的时间一致性;
(3) 事务处理的“识时”性。
“定量水分控制系统实时数据库”的功能有: (1) 定量水分实时数据采集、统计、显示、绘图、存储等; (2) 定量水分历史数据查询、绘图、打印; (3) 浓度、流量、压力、车速实时数据的采集、显示、存储等; (4) 浓度、流量、压力、车速历史数据的查询、绘图、打印。
下面结合“定量水分控制系统数据库”, 对实时数据库系统的主要功能进行介绍。
4.1 I/O设备的数据采集与回送
它是实时数据库的一个最基本的功能。本实例支持的I/O设备有DCS、PLC。用户可以任意指定各种数据的采样周期。本实例中浓度、流量、压力、车速数据的采样周期为2秒, 定量、水分的采样周期由扫描架运动周期决定。
4.2 输入输出处理
任何数据在进入数据库前, 均可先进行来源检查, 上下限检查, 并进行量程转换、简单滤波、开方等处理后再进入数据库。输出处理用于在数据库向外部设备进行数据回送前, 对发往现场的数据进行输出上限、下限检查和限值变化率检查, 并进行输出记录。
本实例在输出历史记录时用到曲线图的方法, 下面举出部分定量、水分历史曲线制作部分代码 (注:RS为记录指针) :
4.3 统计
设置了自动统计功能时, 数据库自动对PV值 (过程值) 的变化进行累计运算, 可提供小时、班、日、月、年的累计值。自动计算时间段内的平均值、最大/小值, 形成统计历史数据。
“定量水分控制系统实时数据库”中对定量、水分的采样值进行了统计, 下面仅举出部分求横向定量值的平均值、偏差、最大值的算法 (注:arr1 (i) 为动态存储定量采样值的数组) 。
4.4 在线组态与查询
以上各种内置的数据处理功能, 均是由组态数据进行管理的。用户可以用任何一个访问数据库的应用程序在线修改这些参数, 当然也可以在数据库上直接修改或查询。
下面列出了“定量水分控制系统数据库”中对浓度、流量、压力测量值查询的部分算法。
4.5 保存历史数据
各实时数据库均可保存历史数据, 且可任意指定保存时间, 中间可随时停止和恢复。“定量水分控制系统数据库”保存历史数据用到几个自定义函数, 下面给出保存定量水分的函数。
4.6 其它功能
实时数据库系统的其它功能有:数据累计处理、运算和控制、事件管理、网络通信及并发处理等。
5、结语
实时数据库能同时处理大批实时的数据和库存的静态数据, 使得它同时具有传统数据库和实时数据库的双重功效, 这种特性必然使它将成为数据库的主流。随着自动控制的深入发展, 必将促进实时数据库的研究和发展。
参考文献
[1]马国华.监控组态软件及其应用.北京:清华大学出版社, 2001.
[2]刘焕彬.制浆造纸过程自动测量与控制.北京:中国轻工业出版社, 2003.
[3]清宏计算机工作室.Visual Basic编程技巧—网络与数据库篇.北京:机械工业出版社, 2001.
[4]温贤发.Visual Basic数据库程序设计高手.北京:科学出版社, 2001.
实时历史数据库 第10篇
荆门石化实时数据库系统简介
荆门分公司实时数据库系统采用Honeywell公司的Uniformance PHD202版本实时数据库系统软件,网页发布是WPKS 2.11版本。本系统由四台服务器组成,分别是域名服务器JMPHD、数据库服务器PHDORACLE、主服务器PHDMAIN和网页发布服务器PHDWPKS。
荆门分公司的DCS系统主要由Honeywell、Foxboro、横河、和利时、浙大中控等厂商提供。Honeywell采用APP节点,此APP为缓存服务器与Uniformance连接;Foxboro采用OPC DA Server作为数据采集通道,OPC RDI与PHD Server软件安装在PC上作为Uniformance缓存服务器,与Uniformance连接;横河、和利时、浙大中控采用标准OPC Server接口与Uniformance连接。
实时数据库系统在生产管理上的应用
通过实时数据库系统的网页发布,可对生产进行实时监管。网页发布服务器能够形象描绘出生产装置的流程图,实时显示流程控制点的温度、压力、流量等生产工艺参数,还能掌握各控制点某一时间段的数据趋势图。这有利于生产调度部门实时了解生产动态,指挥生产;便于车间技术人员实时掌控装置生产情况,对装置操作的稳定性进行分析评价,及时发现、分析和处理装置生产过程出现的异常,预防事故的发生。
另外,车间对班组、职能处室对车间的生产指标考核,可方便地通过实时数据库的数据提取来实现。通过提取需考核时间段数据,计算出工艺参数上下限范围内符合要求的数据,得到该时间段达到控制要求的数据比例,从而科学定量地反映出该装置生产的稳定状态。这种情况下数据的查看和读取方式往往采用Microsoft Excel,其优点是能够对生产数据进行分析处理,还可以直接形成生产报表。
实时数据库系统维护管理中几点经验
1.加强部门间沟通
由于实时数据库系统涉及到的部门比较多,信息管理中心、仪表车间、计量中心与生产车间等部门要经常沟通协调,以确保实时数据库系统的取数准确性。如在装置检修或改造时,仪表人员有可能改变DCS组态,就会改变实时数据库系统与DCS系统同步,一旦两个系统之间出现不同步,就可能出现实时采集的数据不可靠。有时仪表、计量人员校表时,也会改变DCS组态文件。车间生产工艺人员发现实时数据库系统数据有误差时,要马上与信息管理中心联系,中心与仪表部门沟通,及时更新与DCS相连的OPC(buffer机)组态文件。因此,多方要保持沟通渠道的畅通才能保证系统数据的真实可靠。
2.保证数据的连续性
为确保生产管理,必须保证数据的连续性。实时数据库系统的主服务器PHDMAIN是影响历史数据的重要原因,此服务器一旦出现故障,可能会中断部分历史数据,修复后也可能存在历史数据断点。所以此服务器必须保持冗余,即备份服务器,一旦出现故障就立即启动;同时对正在运行的服务器做好数据备份,以确保数据的连续;另外,经常对所有装置上传数据进行检查,一旦某套装置的DCS与OPC中断,要及时启动该套装置的OPC,保持与DCS的连接。
3.保障生产管理人员的PC机正常使用
对生产管理人员的PC机安装实时数据库系统Microsoft Excel取数客户端时,软件安装较多,影响因素也较多,用户在使用时稍不注意就有可能不能正常读取系统数据,诸如以下几种情况:
取数客户端系统安装完成后,进入域JMPHD用户TEST,能够正常读取系统数据。但操作人员以后在PC机使用过程中把IP地址改变,就有可能不能再次进入域用户,导致读不了实时数据。这种情况下需要重新注册域用户。
计算机安装Oracle数据库客户端,必须选择Oracle客户端其中六个功能:Oracle Network Utilies 9.2.0.1.0、SQL*Plus 9.2.0.1.0、Oracle Windows Interfaces 9.2.0.1.0、Oracle Call Interfaces 9.2.0.1.0、Oracle9i Windows Documentation 9.2.0.1.0、Oracle Universal Intaller 2.2.0.12.0,安装完成后,用户在使用过程中若有更改,就可能造成用户PC客户端读取数据不正常。
安装Excel取数客户端,需安装补丁程序Unf_202.1.2_Desktop.msp。进入Excel后,还要添加Uniformance宏。如果用户丢掉Uniformance宏,客户端就不能正常读取系统数据。
还要注意的是,有的用户重装Office系统后,必须再重新安装Unf_202.1.2_Desktop.msp补丁程序,否则此PC客户端就不能读取系统数据。另外,用户PC客户端系统必须是2003版Office系统,2007版的也取不出数据,许多用户因为Office系统升级而不能读取数据。
4.实时数据库系统中的时钟错乱问题
该版本Honeywell实时数据库系统的每一个数据都有一个时间戳,精确度达到秒级。实时数据库系统在采集DCS系统数据时,采用了DCS系统的时钟,如果DCS系统的时钟不校准的话,与北京时间不相符。实时数据库系统服务器时钟不校准,也可能与北京时间不同步。如果不注意,在服务器发布流程图时,实时数据的时间戳就会出现不同生产装置的流程图时间戳不同,有的相差几分钟,有的甚至超过半个小时。实时数据库时间戳应以北京时间为准,对DCS系统、实时数据库系统服务器时钟均要进行时钟校对。
5.实时数据库系统中用户计算机重名问题
近年来荆门分公司不断更新用户PC机,安装过程中遇到一些新问题,如计算机重名问题。分配新PC机后,在为生产管理人员安装实时数据库Excel取数客户端时,有些用户开始使用正常,过了一段时间后,却不能正常读取系统数据。
经过原因查找和分析,发现影响用户PC机正常读取数据的原因是重名问题。新PC机是用GHOST安装操作系统,有些用户拿到后更改了计算机名,使用正常;而有些用户没有更改,随着更新的PC机数量增多,导致PC机重名现象出现,影响了用户正常读取数据。解决的办法是注销原用户域名,更改计算机用户名后,再重新注册计算机域名。
6.利用补丁软件提高系统网页发布的兼容性
随着操作系统的发展,IE不断更新,实时数据库网页发布客户端只能在IE6.0、IE7.0这两个版本下运行。通过实践探索,可安装办公自动化系统的两个软件IEcfg.exe和Indi Doc X.exe打补丁,以提高其兼容性。
