城市轨道交通综合监控自动化系统平台设计技术的论文

-本文为网络收集精选范文、公文、论文、和其他应用文档，如需本文，请下载-城市轨道交通综合监控自动化系统平台设计技术的论文本文从网络收集而来，上传到平台为了帮到更多的人，如果您需要使用本文档，请点击下载按钮下载本文档（有偿下载），另外祝您生活愉快，工作顺利，万事如意！摘要基于轨道交通各类自动化与信息化系统拓广性、集成性及开放性需求,提出了一种基于分组、分层、分块的平台体系及构件化结构的,用于轨道交通综合监控自动化等系统设计的平台建设技术,详细阐述了三个软件子平台的结构及功能,指出在构造轨道交通各应用系统及其互连集成中,此平台技术体现更大的开放度及持续可扩性。关键词综合监控自动化系统,开放平台,软件子平台,开放度,可扩性随着轨道交通自动化系统,如电力、环境、保安、辅助设施、列车监督等的应用范围不断拓广,自动化系统本身与应用多样化的适配性、系统向更大集成度发展所需的一体化互连性,以及互操作的低效与高成本等的不足体现得日趋明显。从自动化系统的开放系统环境(ose) 考虑,上述不足可定位于ose 的各项子集:应用的互操作性/ 互连性,应用的可移植性/ 可伸缩,以及应用的集成性/ 拓广性中。因此, 必须将一个轨道交通综合监控自动化的全方位开放系统定位于建设目标,以更大开放度地支持系统的支撑与应用,以及轨道交通企业网的横向与纵向建设。此举将是今后轨道交通及其他自动化应用系统的根本途径所在,也是当今国内外同类轨道交通综合监控自动化系统所应完备的定位目标。1 平台建设内涵传统基于功能应用设计的轨道交通自动化系统的有限的开放度,约束了系统的持续拓展。问题的本质是这类系统无体现开放性的平台建设,系统总体结构不清晰,导致了系统的不可扩性。这里需要澄清的一个概念是,一个轨道交通综合监控自动化系统并不是基于了哪类世界级的计算机系统、网络设备、控制及执行设备就具备开放性。系统底层的开放性仅是其中一部分,更应注重中层及上层的开放性,特别强调以中层开放驱动上层应用级与用户级开放,从而以更大开放的综合自由度满足轨道交通综合监控自动化不断拓广的应用需求及企业网的建设。对于轨道交通综合监控自动化系统,真正的开放性体现在该系统的最上层,即应用层。通过应用层的可视化交互界面( gu i) 定义自己的各类应用,包括轨道交通综合监控自动化各系统的互连通信则是最为理想的。然而,应用层开放并不是空中楼阁,它必须要有位于其下的建设支撑。之所以称为建设支撑,是要体现建筑结构的层次化概念。这就是本文的平台建设内涵。2 平台建设框架平台总体设计为分层支撑模式。为使平台持续可扩,以及具有清晰的可用性及可复用性,可将其分为三个包容关系:组层-子平台(subplatform) 、子层(layer) 以及块层-组件/ 构件(component) 。每层相对独立,无严格的依附关系,且均为积木模块化的组件/ 构件单元构成。上层任一单元均体现与相对下层1n 的支撑关系。系统平台必须从过去的单一系统或单一网络的概念,提升到跨越网络透明访问异构设备的网络分布计算的高度,且此应作为轨道交通综合监控自动化系统平台建设的重点 1 ,2 。基于一个轨道交通综合监控自动化系统的分层定义,系统主要描述在现场操作层、设备/ 控制层及信息系统层中。现场操作层由各类位于现场的智能化仪表、传感器、执行机构及交互装置构成;在设备/ 控制层中,主要包括运程终端设备(r tu) 系统、电气控制系统、环境/ 保安/ 辅助设施分散控制系统、可编程逻辑控制(pl c) 总线/ 网络分布系统等;信息系统层主要含有控制中心等监控与信息管理系统。整个系统按控制要求配置冗余交换以太网、冗余总线、环形网等网络结构。基于轨道交通自动化系统的应用与网络分划, 建立一个统一的硬件及软件平台体系,以支持上述多类不同应用系统的技术支持。系统平台层次结构见图1 。图1 轨道交通综合监控自动化系统平台层次结构图1 中最上层为面向轨道交通各类应用而生成的应用系统。中间为三个子平台层,以及支持子平台建设的构件层。构件层亦可称为中间件层,它又由n n 阶矩阵形式的各构件组成。构件层与子平台层之间可形成具有特定意义的构件库(图中未标出) 。图中央处的双箭头即代表构件对子平台层的支持关系,又代表构件和子平台层对硬件平台的支持与映射关系。图右方处的双箭头即代表硬件平台、构件及子平台层对各应用系统的支持关系,又代表应用层对硬件平台的支持与映射关系。平台在不同层次上体现网络、图形、gu i 、dbms 、os 、应用系统构架技术等,与当今世界最新工业及国际标准相适应,并考虑扩充,从而为底层多平台及跨平台(如一个网段上不同操作系统、不同gu i 、异构数据库的各节点间) 的平滑应用奠定基础。构件化是广义的概念,它包括原始设备制造商(oem) 的核心应用构件及开发工具构件。基于这些符合国际及工业标准的开放核心构件来实施自己的平台构件/ 构件组件建设,是保证平台开放性、可持续拓展的关键。3 软件子平台的建设通过对图1 系统平台结构的共性分析,可以归纳出3 个软件子平台:数据管理子平台,可视化交互子平台和网络通信子平台,以下详细阐述3 个子平台的建设。需要说明的是,对于轨道交通综合监控自动化系统而言,硬件平台具有与软件平台同等重要的意义。况且嵌入式软件必须要有硬件平台的良好支撑。现场操作层及设备/ 控制层中,存在多种类型i/ o 卡件、i/ o 智能设备、数据采集与处理装置、保护装置、电气与光纤网络集连/ 交换装置、可编程控制器、智能通信控制装置等。这些低端智能装置的基本属性是板卡件逻辑电路、网络/ 总线通信接口、电源模块、嵌入式软件、全球定位系统( gps) 、箱体结构件组成。将它们按独立分类的硬件子平台分划,并在每个子平台中构造基于组装模式的硬件构件,含与之相关连的嵌入式软件类及版本。在当今工业以太网向传统工业控制领域推进应用趋势下, 基于工业以太网及常规can 、profibus 等现场总线的互连硬件平台的建设十分必要。但硬件平台及其构件不作为本文讨论重点。3. 1 数据管理子平台建设数据管理子平台设计应以支持轨道交通综合监控自动化系统的高可靠性、高集成性和高性能运行为准则。高可靠性是基本要素;高集成性体现轨道交通综合监控自动化不同分布系统异构数据库(实时与历史库) 的互连共享;高性能则要体现数据访问、存储、动态触发的高效率。为此,该平台及其构件的生成工具必须具备开放性、成熟性,平台基于构件的层次尽可能少。数据管理子平台不仅由数据管理自身构件支持,且还由构件层与子平台层之间可形成具有特定意义的构件库支持(如数据访问网络通信构件库), 从而构成分布数据管理子平台。数据管理构件应是基于核心层数据库,如商用数据库sybase 、db2 等的标准内涵和外包(shell) ,采用如多线索结构、内部并行机制和有效的查询优化技术等,并充分利用sql 、j ava 等开放的开发环境来构造。轨道交通综合监控自动化系统的实时库分布接口构件亦可按此模式建设,从而为不同系统实时数据的访问与维护创造一致的支撑环境。建立或利用java 或其它虚拟机,可在数据库中编写、存储与执行java 代码。可利用j ava 类,它们可在不对j ava 或数据库做任何修改下运行。基于此强大的标准编程语言来定义过程逻辑构件,如存储过程或触发器等,亦可包括自定义函数构件。此类构件在sql 表的列中以j ava 类的实例形式存储,并支持实例的方法调用。基于数据库中支持的扩展标记语言(xml) ,可制作xml 文档管理形式下的各类构件,如数据库的备份与恢复、永久存储与复制等。这样在web 开发下使用xml , 则无须进行数据库编程,即可访问数据。数据库中的xml 和ht tp 支持构件将大大简化数据访问与交换。从而为轨道交通综合监控自动化系统间,以及轨道交通综合监控自动化系统与其它信息系统间的web 交互提供支持。建立分布式分区视图构件,将数据按应用分布到多个服务器上,并协调查询过程,从而实现数据库扩展的分布应用,这对轨道交通自动控制的多样性应用的集中数据源的一致性与分布应用数据的管理很有必要。3. 2 可视化交互子平台建设平台建设建立在两个层面上:一是基于任务的流程管理,二是基于对象的单元管理;两者更高层次的组合形成可视化交互子平台。此举体现了面向对象的逻辑与过程一体化软件工程,即过程的实现是对轨道交通自动化控制的可视化方式的具体映射。广义组态是为适合于更广的轨道交通综合监控自动化应用对象面定义的。控制语言是广义组态工具。控制语言是一种类j ava 等的开放语言,它可体现与过去常规组态工具的不同点,即异种机或异构网的互操作性。为适应系统应用更大程度上的系统开放,除设计通常的计算语言系统外,还应具备面向上层应用的计算与控制表达定义以及解释的多样化应用的组态环境。如提供下述语言元语: 计算、 逻辑、 控制、 过程, 可生成上层的计算库(l ib) 、逻辑l ib 、过程控制l ib , 以及知识l ib 。这些l ib 即为构件库。例如通过逻辑定义语言,可自定义智能化过程;通过控制定义语言,可自定义控制序列过程,并将其包装在数据库外层,用于轨道交通系统各类操作命令序列控制、智能操作票的生成、培训仿真等应用。3. 3 网络通信子平台建设网络通信子平台建设之目的在于形成网络级中性服务平台,或称之为抽象服务映射平台,服务于主动发出及客户请求的中性数据,而无须考虑数据的应用,使应用者可自行灵活定义拓广的应用,并自动接入各系统及实现系统间通信。需要指出的是,网络通信平台的概念反映了以往轨道交通自动化控制装置与现在乃至今后轨道交通综合监控自动化系统的关键不同点。将过去的通信架构直接应用于现在的多应用、多控制、多互连的集成系统,将导致潜在的系统运行与拓展问题,因为本质上它是一个面向具体单项应用的非面向对象机制的集中式系统。中间件技术是网络环境下的通用规则、转换及服务的“软集合体”。中间件技术提供了非直接(大于两层) 的分布式计算环境下的客户/ 服务器跨平台及跨网络的透明通信框架,为系统的可扩性、安全性、透明性、灵活性、规范性奠定基础。其构架应为分层的构件化平台,平台的层次化由系统支撑平台、系统应用平台及网络逻辑平台三大组类构成。前一组应采用不同类别的商用/ 标准中间件:数据库访问中间件(odbc 、sql) 、群件中间件与面向对象中间件(corba 、j ava) 、网络协议中间件等,以构成对不同硬件、操作系统、数据库和网络之间差异的屏蔽;后两组则为应用于不同的任务需求所定义的客户端访问数据源的中间件。该层中间件提供了两个基本接口: 客户应用程序接口,定义应用程序与中间件的交互,包括编程语言、系统环境等; 对数据源接口,定义数据格式、存取机制和异构数据源透明访问。采用分布对象通信机制是一种好的途径。它是建立在分层构件概念之上。构件对象是一个封装的代码和数据的集合体。不同的应用可构造不同的对象,对象的操作能对各自的数据进行响应的操作。这种构件分层对象技术可令用户构建自己的应用: 网络通信接口,实现无缝连接的目标。从而提高系统互连的透明性、交互友好性及可靠性,实现真正意义上的分布分散式轨道交通综合监控自动化与信息化应用系统。对于轨道交通综合监控自动化系统而言,网络通信子平台建设的好坏将直接影响系统总体规划与运行。网络通信子平台应支持的系统纵向上尽可能扁平化,横向尽可能分段化。通俗讲,这是网络通信(内部网及外部网) 的软总线(sof tbus) 模式。网络通信子平台构件可建立多样化模式,如商用数据库固有网络客户/ 服务口( cl ien t/ serv2 er) 通信模式、实时库sql 访问模式以及无数据结构的外层应用模式。即按应用分布,建立分布及可互操作的对象机制。分布于网上的全部资源是可共享的对象集合,网上客户可通过系统所定义接口构件或自定义接口构件访问系统分布对象。为此要建立系统分布对象模型、对象请求代理的分层中间件及应用层交互对象模型。网络通信的gu i 形象化交互可以透明地体现一对多的开放关系。一个网络子平台的应用示例是轨道交通电力监控自动化系统实时数据的传输。同一系统中的不同节点,以及不同网段异构系统,都会要求不同节拍的数据断面。常规简易的做法是,实时数据采集通信服务节点按采集节拍向全网乃至通过网关向其它网段发送广播数据。此举不仅增大网络负担,且随节点及网段增多极易形成网络风暴。实际中,各应用节点及网段所要求的数据断面从秒级到分钟级不尽相同。这里设计一个基于标准sql 及开放语言的网络通信代理(agent) 构件,并贴附于实时数据库服务器内。服务网络通信代理通过实时数据库外包应用接口(api) 构件访问实时数据库。这样无论本地或其它网段客户只要通过定义并激活服务网络通信代理进程,即可得到实际所需的数据断面。访问历史数据库亦可通过此方式实现。图2 为一个网络通信代理示例。图2 网络通信agent 示例为适合现场设备与控制的多样性通信需求,作为联结监控系统与现场工业过程端的中间层,即数据采集、处理与网络通信的分散处理单元的上端,为tcp/ ip/ et hernet 冗余网络接口, 下端应建立一个集成工业总线和系统网络的统一接口平台。该平台可含profibus 、can 、工业以太网等接口,接口以模块构件形式构造,便于随应用可选及可维护。以太网技术与应用快速发展已对传统工业控制网络架构(设备层与控制层) 提出挑战,因此接口构件还可做成工业以态网物理硬接口与现场总线协议软接口混合模块。4 结语本文提出了一种开放度持续可扩的轨道交通综合监控自动化系统平台建设模式。总的原则是,分组、分层、分块的平台体系结构,具有结构清晰性、易扩性;网络平台体系应体现自适应网络互连性;分层各构件/ 中间件,应为应用层提供薄的透明的应用支持及“一对多”应用开放性,即一个平台多项应用,以适应应用不规范性与需求动态性。重要的是