实时分布系统（精选9篇）
实时分布系统 篇1
1 DRTDebug设计
1.1 调试工作
DRTDebug设计的调试工作一般包括了两个方面。第一是关于收集分布式同时执行时间信息的工作。其中的作用机理就是通过一个初步的整理进而保障调试工作的确定性, 最终实现再执行工作。在这个过程中, 并不需要额外的对特定事项进行调试, 从而可以尽可能的减缓调试对用户的原程序造成各种干扰的程度[1]。第二是关于进程程序的再调试。这个阶段需要根据不同用户的不同调试要求, 对于收集到的事件信息进行精加工和处理的同时, 使用模拟环境下的确定性再现分布式程序的原程序进行整个过程的执行。在完成调试工作后, 将相关的信息告知用户。最终实现用户不仅充分获取相关信息, 而且还可以保障其程序不受到分布式系统执行过程中相关变动因素的影响, 实现调试工作的顺利开展[2]。
1.2 不确定性问题的解决
事件信息的不对称引起的不完整是不确定性问题解决的关键所在。在一般情况下, 对于一个确定的进程执行, 只有在完全确定了关于进程切换的时间、撤销时间、其他进程相关信息与实践等等事件信息之后, 才可能确定好整个进程中关于执行过程以及结果的实际情况。如果每一个进程的执行过程及结果都可以明确的确定, 那么随后的若干并发事件序列也就可以确定整个分布式程序的执行行为了[3]。另外, 通过DRTDebug设计可以将每一个节点处的进程执行和处理情况反映出来, 来源于调试程序的事件信息之后。这种调试次序可以由IPC执行, 同时可以获取事件信息中包含进程执行人口数据、事件达到数据, 最终可以实现进程节点的执行行为。此外, 根据IPC及RPC下的调试可以尽可能的确定执行的顺序和同步之间的关系, 保障结点之间进程的执行次序。在这样一种情况之下, 可以不用考虑全局时钟同步的问题, 从而就可以快速的完成整个实时系统执行行为的确定化问题。
1.3 实时性能的调试工作
实时性能的调试工作按照实践经验, 可以根据收到的关于事件信息的时间属性来判断进程以及线程执行的情况是否满足实时性能调试的问题。在这种方式下, 对于同样顺序的进程调试工作基本一致, 分布式实时系统的再调试可以细化分为依断点执行、单步性的执行等等。在实践操作过程中, 往往习惯将事件定为一种再执行的基本单元, 执行的过程也往往定为事件发生的过程[4]。另外, 作为一种调试系统性的控制面板, DRTDebug的调试界面不仅可以接受用户的各种预置上的关联条件, 而且还可以通过特定的方式将系统的实际运行以及相关联的数据信息完全展示给用户, 提升了用户找出分布式实时系统中存在的漏洞和错误点的效率。其中, 用户的各种预置关联性条件包括了监控的客体、断言、断点等等。
2 信息收集工作
信息的收集工作不但要借助于监控通讯获取相关联的传递信息实现, 而且必须要参考进程之间通信信息的传递模式进行[5]。信息收集的事件类型包括了消息接受、进度调度、主外内存交换以及页代替等等。另外, 对于信息收集工作而言, 一般不是直接在源语言的基础之上进行。相反, 而是要对源语言进行相关的预处理、扩充等等工作。具体到预处理器的选择需要根据特定的事件跟踪产生的相关指令完成。预处理工作是借助于源代码中插入相关的指令而完成的, 跟踪事件是由ETR记录以及保存在数据库之中完成的。在经过了一定时间的处理后, 方可开展一系列的信息收集工作[6]。另外, 进程之间的通信必须要依赖于通信信息的传递方式进行。对于后期特定进行状态下的IPS, 包括了本地性的变量值以及程序的计数器。而GSS包括了整个系统中每一个进程的状态变化的信息。
3 事件的定义工作
对于一个事件而言, 一般包括了两种类型, 即IPS和GSS。而对于GSS事件来说, 包括了例示/停止特定的进程, 发送/接受消息或者是队列的调度。IPS事件包括了变量的修改和可达方面的标记。需要特别注意的是, 对于特定的GSS事件, 需要进行一个跟踪。其主要的原因在于通过利用其分析和挖掘并发程序的具体情况后, 可以为后期单个进程的时间提供一个双向性的关联性因果顺序, 从而实现执行效的最佳效果。最后, 每个纪录的事件信息包括了以下几个方面的内容:事件的类型、进程的表示、源代码的行数以及时间邮戳。
4 结语
在实践操作过程中发现, 分布式实时程序运行具有非常大的波动性, 给再现分布式实时程序的运行带来了诸多的不变。本文从DRTDebug设计出发, 包括了调试过程、不确定性问题的解决以及实时性能调试三个方面, 然后对信息收集及事件定义方面的具体问题进行了深入的分析。在很大程度上本文研究得到的结论可以直接用于分布式实时计算系统的实践调试工作中去。
参考文献
[1]罗星原, 李青山, 叶宏, 崔西宁, 陈威.一种面向分布式应用的调试代理[J].航空计算技术, 2010, 40 (3) :13-15.
[2]王普玉, 叶善椿, 甘卫华.农产品加工企业入库流程的数据统计改进[J].物流科技, 2010, 33 (6) :33-35.
[3]李青山, 李珺, 叶宏, 杜林.分布式调试中基于事件模型的确定性重演策略[J].西安电子科技大学学报 (自然科学版) , 2010, 37 (05) :54-56.
[4]闫海珍, 李绪成.基于统计的大型网站智能导航系统研究[J].福建电脑, 2010, 26 (3) :23-25.
[5]陈文宇, 桑楠, 屈鸿.分布式对象调试中的事件模型[J].电子科技大学学报, 2005, 34 (3) :21-24.
[6]张定群.分布式共享主存结构动态检查点技术的应用研究[J].计算机与现代化, 2008, 10 (8) :10-13.
实时分布系统 篇2
在使用了两个星期后，谈谈David Yin自己的体会。
Woopra的客户端可以运行在目前99%的平台，包括Windows，Mac，和Linux。界面非常华丽。
目前虽然还是Beta测试版，已经可以实时查看访问流量、搜索关键字、访问来源等常规信息外，你还进行搜索、查看实时分析数据及图表、创建事件提醒等功能，
非常有特色的一个地方就是，你可以通过客户端自带的IM系统同正在访问你的网站的用户实时沟通。这个功能是目前的统计系统都没有的功能。
可以对特别的用户用tag来表示，并且可以查看历史上他所访问的记录。
还有很多很多的特别的功能。其实最大的特色就是三点：
丰富的界面
实时通讯
实时统计
官方网址
分布式实时数据库系统技术研究 篇3
1.1分布式数据库系统的特点。
分布式数据库由一组数据组成, 从物理层面看这些数据分布在计算机网络的不同结点上, 从逻辑层面看这些数据属于同一系统。网络中每个结点都具有独立执行局部应用程序的功能, 也能通过网络通信子系统在全局范围内执行应用程序。也就是说, 分布式数据库系统的数据库、终端、中央处理器、局部DBMS运行、局部应用程序执行等都是独立的, 但又可相互协作形成整体, 其用户可以实现在任何场地执行全局应用程序[1]。
1.2实时数据库的特点。
实时数据库系统是管理有时间限制的数据和事务, 强调调度机制和事务管理上对传统数据库的优化, 可设定事务的截止时间特征, 最大限度地满足事务起讫时间限制, 保证数据库内数据在逻辑和时序上完整一致。
1.3分布式实时数据库的优势。
现代数据库需求要求实时数据库与分布式数据库在功能特性上实现有效集成, 由分布式实时数据库管理系统统一调度管理, 其方法是在实时数据库的事务处理层基础上实现分布式事务处理, 即将具有执行期限的数据和事务分布在不同结点上。
二、分布式实时数据库的事务管理机制
2.1分布式高优先级两阶段锁定并发控制协议。
数据库系统的事务管理机制包括分布式事务并发控制机制、提交机制、避免或解决死锁及日志管理机制等, 分布式实时数据库是在分布式高优先级两阶段锁定协议基础上加入优先级因素考虑。在这一新型协议中, 优先级将由事务最后期限和紧迫性的初始状态调整为将事务进入系统的时间追加到初始状态的实时状态。以此实现每个站点上的锁管理器为站点上各个事务的子事务要访问的数据对象进行枷锁。其中, 当事务之间按照优先级的高低对占锁产生申请冲突时, 低优先级事务将被重启, 重启范围和事务自身全局或局部性质保持一致, 以此保持分布式实时数据库的优先级次序与加锁、解锁实现优化。
2.2附带终结协议的两阶段提交协议。
分布式数据库系统在出现协调站故障或通信链路问题时, 可能导致个体参与者不能及时收到协调者的提交决定, 导致参与者在结束投票阶段发生延迟, 子事务因此错过截止期, 附带影响其下关联事务执行。分布式实时数据库系统对此加入了终结协议, 以提高两阶段协议发生故障时的应急处理能力, 实现实时事务管理。
所谓终结协议即协调站在向若干参与者发送投票信息时同时附带提供所有参与站地址, 当出现上述异常情况时, 问题参与站可利用附带地址沟通信息。其实施办法是, 在参与站与恢复站的信息设计上分三种情况考虑:一是参与站有明确提交命令时则发送给恢复站相同信息, 恢复站执行协调者决策, 并发送信息至不确定站点;二是提交了信息却未收到命令则发送给恢复站不确定信息, 则恢复站继续询问;三是提交信息夭折则发送恢复站夭折信息, 恢复站自行回滚并将发送回滚命令至所有参与站。
2.3减少协议依赖性。
分布式数据库的协议模式虽实现了冲突模式下的数据共享, 却导致冲突事务之间相互依赖, 限制了提交顺序, 一旦协议出现故障且无法迅速恢复, 则其下依赖事务都将错过截止期。数据库通常依据事务在投票子阶段的时间长度是否超出无故障事务时限来断定该事务是否正常执行。因此分布式实时数据库对此协议形式改为弱依赖协议类型, 即维持执行冲突的协议解决方式不变, 而将既有的依赖性用依赖集实现其可串行性, 保证并发数据方位的数据库一致。当事务在提交后严重超出无故障事务时限则作回滚处理, 并顺次执行到该事务其下的连带事务上。由此只要有需要, 前期其提交事务都能被立即产生依赖性, 在依赖过程中可依据具体状态随时决定是否取消其被依赖资格。
总结
长久以来, 国内众多计算机应用行业文献都致力于对传统协议进行改进, 但多停留在或改善并发控制协议的并发度、或改良提交协议来提高食物管理的实时水平等单向度改进层次上, 分布式实时数据库在此问题改进上集成了二者优势, 令使协议适用于分布式实时系统环境, 设计了基于分布式实时数据库系统环境下, 并行交融并发控制和提交处理两个工作阶段的新协议方案, 解决了单向度改进协议无法全面解决的截止期问题。
参考文献
[1]庞惠, 翟正利.论分布式数据库[J].电脑知识与技术, 2011, 02:271-273.
基于Web的实时答疑系统 篇4
针对基于Web方式的实时答疑系统的功能及实现方法进行了讨论,并给出了实际的`解决方法.
作 者：刘超群 赵然 罗晓东 作者单位：刘超群(湖南大学,计算机与通信学院,湖南,长沙,410082)赵然(山东理工大学,科研处,山东,淄博,255049)
实时分布系统 篇5
关键词：数据同步通信,分布式,实时数据库
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
实时分布系统 篇6
电力能源作为国民经济发展的“三大命脉”之首,其发展水平、运行可靠性、自动化程度的提高直接影响着整个国民经济的发展步伐。而随着计算机软硬件、网络等技术的高速发展,电力系统的自动化水平也在不断提高,其中电力调度自动化系统(EMS)在保障电力系统的安全、稳定运行中起着越来越大的基础作用。
数据库技术产生于20世纪年代后期,其理论与技术发展极为迅速,应用也日益广泛,在当今的信息社会中,它几乎无所不在;其支持的数据模型,已经历了层次、网状、关系和面向对象模型等几个阶段,技术上逐渐走向成熟,在传统的应用领域获得了极大成功。然而,它们在现代的工程和时间关键型应用面前,却显得软弱无力,面临着新的严峻的挑战。由此而导致了实时数据库(Real-timeDatabase,RTDB)技术的产生和发展。实时数据库作为数据库技术的一个重要分支已有20多年的发展历史,随着网络技术迅速发展,实时数据库技术也得到很大发展。在电力系统方面,随着国内外对一体化系统(SCADA/EMS/DTS)的研究深入及用户需求的增加,如何设计与实现一个能较好支持一体化系统的实时数据库管理系统,也已成为调度自动化领域的一个重要课题[1]。本文介绍的这套系统已开发成功,并在多个实际工程中应用。
1 面向电力系统实时数据库的特点
作为一个面向电力系统调度一体化的实时数据库,它除了应符合作为数据库的一般要求外,还需要满足SCADA/EMS/DTS系统的应用要求。因此,实时数据库应具备以下重要特点:
(1)数据访问快速,能满足系统的实时性要求;
(2)具备完备的数据处理和管理功能,有效的恢复和重载机制;
(3)满足电力系统网络分析的要求,确保数据的实时性和一致性;
(4)高效的数据分布性能,支持数据的分布存储和访问;
(5)多任务的并发处理机制;
(6)支持多个工程的数据库并存机制,数据库间的数据方便切换,以提高工程管理效率;
(7)支持数据库的镜像功能机制,满足不同应用间的数据快速切换;
(8)提供数据库访问的规范接口,具有良好的数据安全性;
(9)开放性好,提供与其他系统数据交换机制[2]。
2 分布式数据库的特点
分布式数据库系统有两个方面的含义:一是存储分散性,数据库中的数据存储在不同的计算机存储设备上;二是逻辑整体性,这些存储在不同地方的数据在逻辑上是互相联系的,共为一个整体[3]。分布式数据库系统不是简单地把集中数据库分散地实现,而是具有下面这些特点和性质:
1)透明性:用户不必关心数据的逻辑分片,也不必关心数据物理位置分布的细节;
2)数据冗余度的适度增加:在集中数据库系统中,尽量减少数据的冗余度是系统的设计目标之一。而在分布式数据库系统中却需要一定的数据冗余,在不同的地方存储同一数据的多个副本;
3)全局的一致性、可串行性和可恢复性;
4)集中与自治相结合的控制结构。在分布式数据库中,数据重复和合理的分配是关键[3,4]。
目前,分布式数据库技术研究的热点是客户/服务器技术。对于多服务器系统而言,系统的数据分布在多个服务器中,多个客户共享多个数据库中的数据,服务器间协同工作,支持对数据的透明访问。
3 电力系统典型运行结构
通过对实时数据库和分布式数据库的特点分析,我们提出了一种结合二者优点的分布式实时数据库管理系统,它采用客户/服务器结构,并以内存数据库为基础,充分体现了网络条件下控制系统实时性的要求,为数据库技术在自动化系统中的应用提供了新的思路。下面设计的分布式实时数据库系统就采用了这样的一些设计理念,并在充分利用网络系统带宽的同时,做到负载均衡和双机双服务热备用。
图1给出了电力调度系统一种典型的运行结构图。
从图1可以看出,在电力调度系统中包含了各种应用服务器,每种应用服务器上部署有不同的服务进程和内存数据库,同时各种服务器之间也进行大量的数据交换以保持同步和一致性,客户节点也需要访问各种应用服务器上的服务和数据。
4 面向电力系统的分布式实时数据库系统的结构设计
这里所设计的实时数据库系统是面向电力调度系统的一种专用的实时内存数据库(MMDB)系统,考虑到电力系统运行的数据访问要求,把所有的数据分成三类:动态数据、静态数据和统计计算数据。由此,衍生出了两种数据存储要求,提取频繁访问的动态数据、计算数据以及部分必要的静态属性信息,按照设计的内存数据库结构生成内存映像文件,称作动态库;而按照关系模式在商用数据库中保存所有动态数据和静态数据,形成静态库。商用数据库中表关系的设计在此不再赘述,下面重点介绍实时数据库的内存结构设计。
4.1 结构设计
内存数据的组织结构在MMDB系统设计时,使用了现代操作系统提供的共享内存机制,系统初始化时将整个内存数据库映像文件装入一块共享内存区,运行时应用进程可以把整个数据库或一部分映射到自己的虚地址空间进行直接访问。针对关系和索引数据全在内存中这一特点,在数据结构和数据访问中广泛使用指针。应用进程可以通过指针,也可以通过位置独立的数据库偏移量访问数据,无需像DRDB那样与缓冲区管理器交互。另外,由于指针长度固定,因此可以很好地解决变长字段问题。其次,若一个大的数据对象在数据库中多次出现,则内存中只需存储一次,其他地方使用指针来引用。
本系统的内存数据库结构通常由四个相互独立的共享内存区组成,分别是数据库模式信息区、数据段索引区、数据段信息区和数据区,其中数据段信息区和数据区成组出现,映射为电力系统数据库中的各个数据关系。有时候对于常用的数据表也会再增加一个内存区域,或称数据记录HASH信息区,利用哈希函数直接查询到相应的数据记录,以加快访问记录的速度。数据区中包含的每个记录的属性由数据结构进行指定,为了加快访问的速度和减少内存中指针的移动次数,一些常用的信息通常也会进行冗余配置。同时,由于电力系统中许多应用软件采用连续内存进行数据处理,并且连续内存有利于提高系统的实时性,因此在镜像内存映像的时候,每个关系表的数据空间均进行连续内存分配。本系统的物理内存组织结构如图2所示。
4.2 内存数据库结构说明
下面给出内存数据库部分结构的C语言说明:
1)内存数据库头信息结构
2)数据段索引信息结构
5 分布式机制的实现
在电力调度自动化系统中包含了各种应用服务器,每种应用服务器上有相应的处理软件和数据,同时各种服务器之间进行大量的数据交换。而客户节点又需要同时访问各种应用服务器上的数据。由于电力调度自动化系统对系统的稳定性、可靠性、实时性要求比较高,因此对于关键部分均采用冗余配置。比如网络采用双网、各种应用服务器均为冗余配置。因此,数据库管理系统的设计围绕物理存储管理、网络信息共享、服务器冗余管理等方面进行。
在数据库底层网络功能的实现上,本文采取数据分流与冗余多网络的可靠通信,即系统中配置了多个相互独立的局域网,只要一条通信回路正常就可保证数据正确到达。这在实时监控系统中很有意义,因为实时系统要求数据具备高可靠性,数据丢失在这种应用中是不能接受的。
5.1 实时数据库的分布式部署
5.1.1 双机双服务的硬件分布部署
在系统运行图1中,可以看到主要的服务节点都采用双机热备的部署方式,它不但实现内存数据库实时复制备份,还同时起到了负载均衡的作用。例如在前置服务器A、B双机中,正常时A、B服务器分别负责各自直接配属的下级网络采集终端(RTU)的数据报文传输和解析,起到了数据流和访问服务的均衡负载。而当其中一个服务器发生宕机后,另一个服务器马上接管对方名下的服务,实现无缝的热备。而当故障解除之后,A、B服务器又重新接管各自的服务,达到网络和访问的均衡处理。具体的实现原理,参见下面的心跳服务和总裁选举。
5.1.2 内存数据库文件的分布式部署
从图2的电力系统运行结构图可以看出在电力系统的应用中存在着多个主要的数据处理服务,分别是前置数据采集通信服务、SCADA服务、PAS应用服务和DTS应用服务。不同的服务进程对于数据的要求不同,这样就可以根据部署服务节点的不同而生成不同的内存数据库映像文件,需要访问这些数据映像的时候分别进行加载即可实现数据的访问。
分布式实时数据库管理按照客户/服务器模式构建,对于某一个分布式实时数据库,整个系统内只有一个节点的数据库为参考,其他节点的数据库进行以该节点为基准,其数据自动向参考点的数据统一,以达到数据一致。因此,我们把部署在主机上的内存数据称作参考库(REFMAP),把部署在备机上的称作复制库(REPMAP)。
5.2 实现分布部署的关键技术
5.2.1 数据库自动复制技术
数据库自动复制技术(DatabaseAutomatedReplication,DAR)是用来保证参考库和复制库数据一致的关键技术。根据数据更新的不同,DAR提供了更新和下载数据库的三种技术。这三种技术分别是:
1)非优化的更新/下载技术:该技术包括下载表的全部项。对相对小的数据库来说,此技术是可行的。对大的数据库,完全下载的持续时间使此技术无法让人接受,特别是当数据库仅有一小部分被修改,而复制库节点请求下载时。
2)基本更新/下载优化技术:它有选择的下载复制库请求的、并发生了改变的表。mod count字段是一个表的修改计数,正常时每当参考数据库更新器对XXX Table表进行一次修改,mod count字段加1而且该字段的新值(与XXX Table1表所做的修改一起)被传播给所有复制数据库,所有的数据库就被同步更新了。而当复制数据库需要主动下载时,复制数据库首先向参考数据库下载服务器发送mod count,当下列条件满足时,参考数据库下载服务器下载该表:
下载目录表的num records、extent和mod count字段。END IF
3)增强更新/下载优化技术:此项更新/下载技术是基本更新/下载优化技术的增强。它允许下载与复制库请求相关表中被修改的记录。为了更好地检测修改,此技术需要增加一个更改计数表来存放基本表项的更改次数。由于存在额外的内存开销,此技术最适用于经常需要更改一些基本项的超大表。
5.2.2 心跳报文广播服务
上文论述了要在双机服务过程中实现网络访问和服务的负载均衡,这里双机所处的地位虽然是平等的,但是在任一时刻,在双机或者多机部署的情况下,系统中总存在一台作为主机服务,其余作为备机服务。首先,根据服务进程的配置参数选出一台作为主服务器使用,对它赋予比较高的优先级别,赋予其余的服务器不同的,或者相同稍低的服务级别。这样,首先由最高级别的服务器充当主机使用,主机和备机通过广播的心跳报文来保持通信的同步和服务的监控以及切换。
心跳报文广播采用UDP通信协议,它的特点是效率高但不可靠,适合于网络拓扑结构未知情况下的应用。在系统测试过程中发现,当系统发生连续的报文广播时,报文的丢失率高达20%以上。分析发现,报文丢失主要发生在接收端,而不是在网络上,可能是网卡的中断处理效率不够,以及接收线程来不及处理连续的报文,导致报文接收队列溢出所致。为提高可靠性,本系统采取对小报文缓存合并,每个报文发送之间采取一定间歇及采取双收策略,实际应用表明这样可基本消除报文丢失现象。
5.2.3 总裁选举协议
虽然心跳报文的广播服务解决了双机的同步和服务的监控问题,但是必须防止出现因主机宕机或者掉线而丢失主机心跳广播报文的情况发生,为此,引入了总裁选举协议来进行主机的推选工作。
总裁选举协议提供了一种机制,保证在任意时刻在一组分布式应用中只存在一个主服务,其他的应用为备用服务。该协议利用点对点通信服务中的数据报通信端点在各协作进程间交换信息。该总裁选举协议的选举策略就是:
6 结论
本文分析了面向电力调度系统的专用的分布式实时数据库的特点,以及在设计中面临的难点,对实现实时数据库所需要的关键技术进行了详细的阐述并给出解决方案。根据上述的原理实现的电力调度的分布式实时数据库系统已经成熟地运用在多个省地级的电力调度系统中,有力地支援了我国的电力调度事业的建设和发展。从总体和应用情况看,本系统提高了电力调度自动化系统的实时性、扩展性、通用性,缩短了电力调度自动化系统的开发周期,降低了系统开发的复杂程度和开发费用。同时,系统规模可灵活配置,适应多变的用户需求。此外本系统做一些适应性修改,便可应用于其他实时监控系统,从而显示了广阔的应用前景。
参考文献
[1]于尔铿,刘广一,周京阳.能量管理系统(EMS).北京:科学出版社,1998
[2]吴文传,张伯,王鹏.一体化系统的分布式实时数据库管理系统.中国电力,2000;33(10):85—89
[3]杨武军,张继荣,屈军锁.内存数据库技术综述.西安邮电学院学报,2005;10(3):95—99
[4]叶建位,苏宏业.实时数据库系统关键技术及实现.计算机应用研究,2005;(3):45—47
实时分布系统 篇7
1 MDE介绍
在分布式实时嵌入式系统开发中, 应用MDE模型驱动工程方法, 不仅可以提高系统的服务质量, 也可以提升系统的耦合性。MDE模型作为驱动架构, 是一个软件开发框架, 基于UML标准框架, 支持软件设计模型可视化、存储与交换, 创建出机器可读的高度抽象模型, 并且这些模型将会独立于实现技术, 以标准化方式储存。MDE通过相关工具, 给系统开发提供一个规范化独立平台, 为系统设计选择一个特定实现平台, 通过架构性分离, 提升系统开发设计的轻便性、互操作性以及可重用性。
2分布式实时嵌入式系统特点
在计算机软件设计中, 会涉及到分布式实时嵌入式系统的应用, 该系统对系统的硬件以及软件程序都有很强的依赖性, 并且在设计该系统时, 还需要保持系统的实时控制优势。 在分布式实时嵌入式系统设计中, 用缓存机制、动态分配方式以及预测指令提高软件实时处理功能, 使得分布式软件的可靠性得到提升。分布式实时嵌入式系统设计中, 嵌入式微处理器作为系统的核心, 应具备对系统多任务的实时支持能力, 可以积极响应较短时间内的中断, 并及时完成多任务的操作, 提高系统的实用性。
3基于MDE开发分布式实时嵌入式系统的方法
应用MDE模型理论方法, 在开发分布式实时嵌入式系统中, 一定要合理规划系统中软件与硬件间的关系, 确保分布式实时嵌入式系统设计质量。
3.1满足系统层次化结构
应用MDE模型来设计开发分布式实时嵌入式系统, 在系统层次化模块结构设计中, 实现系统中软件应用程序与底层硬件的结合, 使硬件可以依靠软件来完成系统的实时任务。 在应用层、物理层、数据链路层设计中, 应强化系统编程与人机界面的友好度, 并且能够确保部分微处理器与I/O端口的完整性, 提升嵌入式系统的易控性与可操作性。
3.2系统功能面向对象
应用面向对象方法, 在分布式实时嵌入式系统设计中, 将实时处理技术应用到系统开发中, 应用MDE模型实现对系统功能的总体规划。面向对象开发程序, 同时在分布式实时嵌入式系统设计中, 组件可以被视为通过接口向外界提供服务或者请求服务的黑盒, 其中多个组件也可以被组成更高层次组件, 分布式实时嵌入式系统内部的组件, 应具备独立性与重用性, 从而可以提升嵌入式系统的独立性。
3.3实时调度算法
在分布式实时嵌入式系统中, 应用MDE模型, 明确系统调度的重要性, 可以保证在多任务环境下, 完成实时调度系统任务。分布式实时嵌入式系统设计中, 截止时间优先调度算法中, 应用RMS调度算法, 可调度上限为68%。例如, 在分布式实时嵌入式系统中需要执行3个进程, 分别是P1、 P2、P。
执行周期为3、5、4, 在时间单位4时, 因为P1的执行时限为6, P2的执行时限为10, P3的执行时限为8, 所以P1的优先级最高, 进程切换到P1;在时间单位6时, 因为P1的执行时限为9, P2的执行时限为10, P3的执行时限为12, 所以P1的优先级最高, 进程又再次切换到P1, 而非P2;在时间单位7时, 因为P1的执行时限为12, P2的执行时限为10, P3的执行时限为12, 所以P2的优先级最高, 进程切换到P2。后续流程以此类推。可达截止期最早优先算法, 也可以应用EDF算法是最优的单处理器动态调度算法, 其可调度上限为100%。
4应用MDE开发分布式实时嵌入式系统的方法
在开发分布式实时嵌入式系统时, 应用MDE模型, 有助于提高系统应用性能与服务质量, 提升嵌入式系统的可扩展性, 使系统可以在实际中稳定运行。以下在智能手机的分布式实时嵌入式系统开发中, 应用MDE模型方法, 对系统开发设计的整个过程进行分析, 具体内容如下。
4.1分布式实时嵌入式系统MDE模型框架
在分布式实时嵌入式系统开发设计中, 基于硬件与软件开发, 将会涉及到如数字信号处理器、微机保护系统、IO设备、C++ 语言、ARM系统等多个部分, 设计出MDE模型框架, 如图1所示:
4.2系统硬件设计
在分布式实时嵌入式系统硬件设计中, 分布式实时嵌入式系统的处理器, 应具备多任务响应能力, 同时也应具备很强存储能力与可扩展性, 降低功耗。应用AT91RM9200处理器, 同步控制事件突发访问, 提高系统响应时间。同时, 在系统中各个功能模块的设计中, 应确保系统各模块接口的耦合性, 实现系统硬件与软件之间的交互。
4.3分布式实时系统驱动设计
系统驱动设计中, 应用虚拟存储管理机制管理内存, 采用静态内存分配方式, 为用户提供实时数据信息, 实现系统间任务的通信。设置高精度的时钟, 负责管理与时间有关的任务, 采取计时、时间片轮转调度的方法, 应用事件驱动方式, 实现定时中断驱动。并且在嵌入式系统设计中, 简化实时任务间的控制流程的设计, 使系统内部可共享驱动资源。嵌入式系统中实时任务调度流程如图2所示:
4.4系统软件设计
分布式实时嵌入式系统设计中, 应划分清楚系统中任务间的职责, 并且赋予每个任务独立唯一的地址, 采用优先级调度的模式, 提高分布式实时嵌入式系统对事件的响应时间。 分布式实时嵌入式系统中, 也应尽量避免软件设计与硬件设计结构间脱离, 提高软件系统实时性。以下是基于MDE的分布式实时嵌入式系统软件代码。
分布式实时任务调度中, 可以使用RMA_Feasible函数, 循环查询判断任务的调度状态:
判断系统实时任务调度成立核心算法代码:
4.5取得的成果
运用MDE模型设计开发分布式实时嵌入式系统, 将其应用到系统开发设计的整个过程之中, 不仅可以提升系统实时调度的准确性, 同时也可以提升系统的可扩展性, 使得系统在后续维护中更方便。同时基于MDE的分布式实时嵌入式系统, 提高时钟中断程序精度, 提高任务相应时间, 较传统分布式实时嵌入式系统有极大改进, 值得在实际分布式实时嵌入式系统开发中推广。
5结语
综上所述, 在分布式实时嵌入式系统设计中, 利用MDE方法管理系统发展的整个过程, 不仅可以解决系统需求同系统开发脱节的问题, 也可以利用MDE方法, 渗入到分布式系统开发整个生命周期内, 满足分布式实时嵌入式系统开发中需求, 提升分布式实时嵌入式系统的性能, 具有实际应用价值。
参考文献
[1]胡华平, 张文强, 金士尧.分布式实时系统测试平台的研制[J].测控技术, 2000 (2) :55-58.
[2]毛羽刚, 金士尧.分布强实时系统的可预测性研究[J].计算机研究与发展, 2000 (6) :661-667.
[3]董剑, 左德承, 刘宏伟, 等.一种基于无效链路的分布式故障诊断一致性协议[J].计算机研究与发展, 2007 (6) :914-923.
[4]贾文涛, 张春元, 付剑, 等.一种高可靠双机温备星载计算机的设计与实现[J].计算机研究与发展, 2010 (S1) :127-132.
[5]胡华平, 金士尧.分布式系统可靠性模型[J].计算机工程与应用, 1999 (8) :1-3.
[6]孙燕, 田俊峰, 王凤先.分布式冗余管理系统可靠性的设计与实现[J].计算机工程与应用, 2003 (15) :140-142.
实时分布系统 篇8
随着电厂综合自动化水平的不断提高,可编程逻辑控制器( PLC) 、集散控制系统(DCS) 等在电厂的生产过程自动化中得到了广泛应用,现场运行着多个分布式变电站控制系统。各系统运行着不同的电机、变压器、压缩机等机电设备,缺乏公共一致的通信基础设施,导致各种子控制系统和上层管理系统之间的数据访问、管理、集成十分困难,所以需要数据访问中间件为控制系统集成和企业信息化提供解决方案。而过程控制对象链接与嵌入(OPC)恰恰提供了工业控制的接口标准,有效解决了控制系统的“信息孤岛”,便于实现管控一体化。
OPC(OLE for process control)是OPC基金会组织倡导的工业控制和生产自动化领域中使用的硬件和软件接口标准,它基于Microsoft 的OLE、COM (component object model)和DCOM 技术。组态王是北京亚控公司生产的一款全中文的工控组态软件,具有组态灵活,可生成友好的交互式图形界面,提供各种现场设备的驱动,广泛应用于工业控制系统的数据采集及监控[1]。本文在VC环境下开发了访问设备OPC服务器的OPC客户端软件,利用组态王和OPC技术实现了变电站现场电气设备运行信息的采集,并应用于组态监控系统中,改变了用电管理、调度、运行的传统工作方式,为实时数据的深层次应用提供了便利。
1 系统总体设计
本系统由数据采集模块、监控图模块、网络安全模块、组态王和OPC数据交互模块等组成,其中数据采集模块是核心。通过对罐区1#、酸碱、江边1#和6#变电所综合保护系统数据集成接口进行改造,数据采集模块将远程综合保护动作时的数据和4个分散的高压变电所的4套直流屏的实时信息集成到本地系统,供监控系统使用。我们利用组态王的组态工具和控件绘制出变电所的一次系统图、报警、报表等监控图,通过与OPC的数据交互和编写脚本来获取实时数据,构建内网监控平台。为了保证电气PLC控制系统的绝对安全,利用现有的硬防火墙,将电气监控网与管理网隔离开来,并对网络地址和WAN口LAN口的链接方式重新配置,以提高数据传输的安全性。实时信息系统简图如图1所示。
变电站远程监控系统实时信息获取流程如图2所示。
2 OPC客户端软件的设计
本文的OPC Client程序LeadOPC.Center是利用Wintech公司的WtOPCSvr.DLL在VC环境下开发的,充当组态王的数据服务器。WtOPCSvr.DLL作为一个快速开发OPC服务器的工具包,封装了所有关于COM和OPC的技术细节,使开发OPC服务器的工作集中在特定的数据采集任务上来。该工具包就是一个动态链接库,支持OPCl.0和OPC2.0定义的所有接口,使用它可以迅速地开发OPC数据存取服务器。它提供了一些把定制数据集成到OPC服务器的易于使用的API函数,开发该客户端时利用了其中的数据访问规范,支持的接口和API函数。下面详细介绍LeadOPC.Center开发步骤,并给出关键源代码:
1)创建新的工程,编辑StdAfx.h文件,加载opcda.h,opccomn.h,opcerrors.h,opcprops.h,opcquality.h以及opcda_i.c,opccomn_i.c文件,将它们存入工程文件夹中。
2)初始化COM库。由于是远程监控,需要远程访问OPC服务器,所以在使用接口类之前必须首先使用CoInitializeEx()函数对COM库进行初始化。
3)通过OPC服务器的ProgID查询注册表中相关CLSID,用CLSIDFromProgID( )函数实现ProgID到CLSID的转换。
4)连接远程OPC服务器,查询对象的IID_IOPCServer接口。
5)创建OPC组,查询IOPCItemMgt接口。IOPCServer接口的AddGroup()方法可以创建一个有指定名称和属性的OPC组。
6)添加OPC数据项。使用IOPCItemMgt接口的AddItem()方法可以添加具有特殊属性的指定数量的数据项。
7)OPC的数据项读写。本客户端程序同时编写了同步和异步读写代码,既支持数据存取规范1.0,也支持版本2.0,所以必须实现IOPCSyncIO接口、IOPCAsyncIO(old)接口和IOPCAsyncIO2接口,这里仅给出IOPCAsyncIO2接口的异步读写代码实现:
8)OPC连接断开,释放接口指针。当程序退出或停止服务器时,依次删除Item、Group,释放资源。
程序代码编写完成后,执行程序,得到OPC客户端软件如图3所示。
3 变电站实时信息的采集
该公司分布式变电所采用ABB的电气设备,现场电气监控系统SE-900C为力导公司的产品,作为数据采集前端,已将各种油泵、压缩机、变压器等电参数数据通过PLC采集上来,但各个数据采集机分布在各个厂区,采用不同的系统。为了构建厂网统一监控平台,在办公室电脑上监控现场的运行状况,就要将远程不同变电所的电气设备运行参数集成到统一的数据平台,我们通过开发的OPC客户端结合MatrikonOPC Tunneller获取现场运行数据。
OPC仅仅支持OPC服务器与OPC客户之间的数据通信,如果数据需要在OPC服务器或OPC客户之间传输,标准的OPC是无能为力的[2]。为此,Matrikon公司开发了OPC数据通讯软件MatrikonOPC Tunneller,功能相当于通讯网关,起到数据采集和转发等功能,扮演了OPC服务器和OPC客户端的角色,可以从OPC服务器取得数据,自己再作为OPC服务器提供给别的OPC客户端,配置简单,数据通信可靠高效,该软件作为一个OPC客户端解决了OPC服务器或OPC客户之间不能进行数据交换的问题[3,4]。
MatrikonOPC Tunneller包括运行于本地的Tunneller客户端网关和远程的Tunneller服务器端网关两部分,服务器端网关作为一个服务安装并运行在远程计算机即现场后台数据采集机上,它负责和远程OPC服务器通讯;客户端网关安装在OPC客户端所在的计算机即办公室监控机上,和OPC客户端通信把从远程采集的数据转发给OPC客户端。远程通信前,先要启动Tunnellel Client Config,添加远程Tunnellel连接,设置远程服务器的主机名或IP地址、端口号、连接超时、重连次数,然后建立连接,下载远程OPC服务器程序标识清单,为本机OPC客户端要连接到的服务器建立本地镜像[5],过程如图4所示。
该公司有灌区、火炬、江边1#和6#等4个变电所,而且都在分离的地方,各个变电所的断路器、接地开关、小车位置等遥信和母联、电机、变压器等遥测数据量较多,所以采取批量存取,建立了OPC数据库文件(*.csv)。我们在现场统计了4个变电所的遥信和遥信数据的点号表即guanqu.csv,huoju.csv,jiang1#.csv,jiang6#.csv。以灌区变电所为例(共108个点号),如图5所示。
打开LeadOPC.Center,新建OPC服务器,弹出服务器标识列表,选中Tunneller客户端中列出的远程OPC服务器,新建数据组,然后将OPC数据库文件*.csv导入组中,相当于添加数据项标签,就可看到遥信和遥测数据被存取出来,通过Tunneller转发通信正常稳定。以灌区变电所为例,图6显示了LeadOPC.Center对服务器KingView.View.1的通信界面,可以看到实时的遥信和遥测数据点号、类型、时间戳、数据质量、值等。
4 厂网监控系统设计与实现
我们使用的是亚控公司的组态王6.51设计变电站监控组态画面,设计时首先新建组态王工程,组态时可以使用工具箱里面的工具快速创建组态画面,由于远程数据已经通过OPC客户端存取到本机,故不需定义IO设备[6]。然后要构造数据库,数据库是“组态王”软件的核心部分,为便于设计,在数据字典里我们将各个变电所的遥信和遥测数据变量名定义为LeadOPC.Center中的相应点号如yc01_128,yx01_182等,这样就可以保证连接组态王服务器时数据的寄存器设备名和变量名一致,如yc01_128和yc01_128.Value对应,还可以防止大数据量时因数据的漏定义而导致监控的不准确。数据库定义完成后,建立动画连接,对遥测数据文本框定义其模拟值输出连接表达式,和我们事先定义的数据变量关联,对遥信数据的监控设计时,由于它是开关量,有状态切换,所以我们需定义画面上开关的状态连接表达式。详细的组态设计这里不再详述,具体可参考组态王的帮助文档。
为了实现数据显示和监控,组态王软件必须从OPC客户端获取数据,实现数据交互,这样OPC客户端充当组态王的服务器,组态王充当了新的OPC客户端[7]。在组态王工程浏览器中,点击“OPC服务器”,然后在右边双击图标,在出现的窗口中选择OPC服务器为LeadOPC.Center.1,其他默认,然后确定。打开数据字典,将每一个实时数据变量与LeadOPC.Center.1中相应的寄存器关联起来。由于上面提到数据变量的巧妙命名,寄存器名应该是和变量名一致的,以数据字典中一个变量为例,可以看到它的属性如下:
然后打开LeadOPC.Center.1,通过Tunneller通信远程的OPC服务器,运行组态王工程,就可以实现变电站的远程监控,在办公室查看变电站的实时运行状况,可以实时监控进线、母联、断路器、接地开关、三相电流、功率等。以灌区变电所监控为例,图7显示了实时刷新的变电所监控运行画面。
5 结束语
为了提高该公司的管理水平和运作效率,方便工作人员和管理层及时高效地了解现场的运行状况,我们利用OPC 技术和组态王结合MatrikonOPC Tunneller构建了厂部内网监控平台。我们采用VC[8]开发了OPC 客户端程序,利用Tunneller稳定高效的网关通信和数据采集转发能力,基于OPC数据存取规范将分布在不同区域的4个变电站的遥信和遥测实时信息统一存储到本机的OPC 客户端LeadOPC.Center,利用组态王和OPC的数据交互,成功地实现了变电站运行系统的远程监控,这套系统已经在该石化公司投入了运行。变电站远程监控系统有助于供电质量实时分析,保障了用电设备的安全,提高了工厂的自动化水平,为实时数据的统计管理、故障诊断、性能分析等深层次应用和变电站综合自动化奠定了基础。
参考文献
[1]亚控科技.组态王Version6.5用户手册[M].北京:北京亚控科技发展有限公司,2005.
[2]OPC Foundation.Data Access Custom Interface StandardVersion 2.04[Z].2000:97-138.
[3]王端喜.OPC在华能东西关水电厂辅机控制系统改造中的应用[J].水电自动化与大坝监测,2008,32(1):55-57.
[4]余秋霞,廖常初.基于OPC的电厂控制信息集成[J].电力自动化设备,2004,24(2):67-69.
[5]MatrikonOPC.Matrikon OPC Tunneller-User′s Manual[EB/OL].http://www.matrikonopc.com/downloads/174/index.aspx,2008-10-25.
[6]张琦,张泰鸣.基于OPC的变电站自动化监控主站软件的设计思想[J].电力系统自动化,2002,27(3):61-63.
[7]罗粮,石锐,英振华,等.工控组态软件对外集成方式的研究与设计[J].计算机工程与设计,2005,26(12):3387-3388.
实时分布系统 篇9
数据库和数据库系统如今已成为人们日常生活中的一部分，以处理海量交易信息为特征的现代电子服务业和电子商务应用离不开计算机系统和数据库技术的支持。数据库系统在管理和处理不断增长的数据发挥着重要的作用。新的应用领域的出现对数据库系统提出了新的功能需求，其不仅要求数据库系统处理数据，而且应提供新的处理策略。
实时数据库系统(Real-Time Database System, RTDBS)是数据和事务都有显示定时限制的数据库系统。系统的正确性不仅依赖于逻辑结果，而且依赖于逻辑结果产生的时间[1]。许多实时应用系统(如先进指挥和控制系统)本质上是分布的，分布式实时数据库系统(Distributed real-time database systems)允许事务通过网络在场点之间存取共享的数据。由于其事务调度是有时限的(通常表示为截止时间)，且必须维护数据库全局和局部的一致性，决定了分布式实时数据库系统在执行事务的场点间交换需包含调度信息的消息[2]。因消息交换导致通信的延时使得系统对事务响应时间的开销大增，反过来使得分布式实时数据库满足时限的要求难度增加。
是否能在截止时间到达前完成事务是衡量分布式实时数据库系统最重要的性能指标之一，影响该性能指标的因素很多，执行事务过程中的发生的数据冲突则是主要原因。数据冲突将导致事务出现执行—提交冲突，为了解决执行—提交冲突，保证事务的原子性，大量的专家学者提出了诸多实时并发控制算法[3,4,5,6,7,8,9,10,11]，而很少关注事务调度的优先级分配策略。我在此则在优先级分配策略方面做出初步探讨。
2. 分布式实时数据库系统模型
在分布式实时数据库系统中，信息存储在由可靠通讯网络连接的场点中。每个场点唯一标识，彼此间发送消息通讯，所有的消息均要求在规定的时间按照发送顺序到达。各场点内部具有逻辑时钟，是松弛同步的，系统则根据场点的标识和场点的本地时钟产生时间戳。
分布式事务可视为由执行在不同场点的子事务的集合，每个事务根据各自的实时约束指定一个全局唯一优先级，其子事务的优先级相等。事务以一定顺序执行，且每次执行一个事务，各事务的子事务存取数据对象和执行处理过程是相互独立的。
事务的执行分三个阶段(如图1所示)[11]：读阶段、验证阶段、写阶段。在读阶段，从数据库读取被请求的数据对象，写操作在其他事务不可访问的私有空间执行。在验证阶段，确保待验证的事务可串行化。在写阶段，完成更新操作，使得更新后的结果对其他事务可见。
事务根据获取资源(如CPU，数据对象等)的优先级进行调度，事务的优先级与优先级的分配策略紧密相关。事务的优先级分配策略既可以是静态的也可以是动态的[12]。文献[13]通过实验说明大多数情况下动态的优先级分配策略比静态的优先级分配策略获得更佳的系统性能。最佳的优先级分配策略之一是基于事务的截止时间，本文采用此方法。
分布式实时数据库的模型(如图2所示)由8部分组成：事务生成器TG、事务管理器TM、事务调度器TS和并发控制器CC(由就绪队列RQ和阻塞队列BQ组成)、数据管理器DM、资源管理器RM、数据库DB，以及网络管理器NM。
3. 分布式实时数据库系统仿真实验
在实验过程中，选取EDF[14]、UD[15]、ED[15]、GDPA[16]共4个基于截止时间的优先级分配策略进行对比分析。其中，GDPA的算法描述如下：
算法描述中，computeDistance (Ji, k) 函数计算Disti与动态失败状态的距离，sortByShortestDistanceFirst (ζ) 函数按照ζ的距离由小到大排序，insertByEarliestDeadlineFirst (Ji, k=σ2)函数表示按照截止时间的先后顺序插入事务Ji, k到调度σ中，isJobFeasible (Ji, k) 函数返回布尔值，表示 (Ji, k) 是否超过截止时间，remove (J i, k, σ) 函数表示从σ中移除Ji, k, headOf (σ) 函数返回σ中的首个Ji, k。
3.1 实验参数
根据实验建议和经验[17,18]，实验的基本参数设置如表1所示，事务的截止时间(Deadline)由以下公式(1)求得。Tgen表示生成事务的时间，Texe表示执行事务的估计时间，SF表示松弛因子，均匀分布在选择的范围内。
3.2 实验结果
分布式实时数据库系统性能主要以失误率(Miss Rate)来衡量，失误率表示在截止时间内未完成事务的概率，由公式2求得。Nmissed表示在截止时间内未完成事务的数量，Ncommitted表示提交事务的数量。实验统计结果如图3所示。
从图3可以看出，无论是系统工作在正常负荷状态还是超负荷状态(通常认为Miss Rate在0%～20%范围内系统工作在正常负荷状态，21%～100%系统工作在超负荷状态)，随着arriva rate的减少，有利于系统性能的改善。在正常负荷状态时4种算法的性能相差很小，但在超负荷状态下性能差异较大。总体而言，在选择的4个基于截止时间的优先级分配策略中，性能最好的是GDPA，其次是ED、UD，经典的EDF则需改进。
4. 结语