1.城市地铁综合监控自动化系统的应用特点

    地铁综合监控自动化系统所有的技术和处理特点都基于其应用特点，这种应用特点主要包括以下几个方面：
    1.地理分散，集中监控。从监控中心全局看，监控对象分散在沿线甚至多条线的各个车站，操作员站设在监控中心，操作员要集中监控和管理全部车站的所有监控对象；从车站看，监控对象分散在各个专业的设备房，操作员站设在车站综合控制室，操作员要集中监控和管理本车站的所有监控对象。

    2.处理规模大，事件驱动。一个地铁综合监控自动化系统的处理规模如果以I/O点来衡量，至少应支持100，000个I/O点。数据规模的扩大使一般控制系统中常用的周期处理方式变得不再有效，因此“事件驱动”成为地铁综合监控自动化系统的主要处理方式。

    3.大量的与第三方子系统或设备进行信息集成，在同一平台上实现各专业之间的相互协调，相互闭锁和信息共享。
监控自动化系统的软件平台要适应上述应用的特点，在软件开发的实践中，着重要解决几个关键技术问题，即软件体系结构、实时数据库和系统数据流、接口通信框架和骨干网数据实时性、可靠性设计。

2.基于中间件技术的分层分布式系统结构

    地铁综合监控自动化系统的每一个车站都有相对对立的监控系统，监控本站的所有设备，在骨干网中断的情况下，车站系统不会受到影响并可以作为备用投入运行。中心集中了所有车站的监控，在正常情况下，所有的监控在中心完成。从而形成了中心和车站两级监控一体化的模式，从物理上骨干网形成了车站和中心的纽带。这种模式及其地铁的其它应用特点使得我们在体系结构设计方面将所关心的问题主要集中在基于网络的跨车站应用集成上，设计具有大规模处理能力的系统。软件组件可以灵活的部署于一个车站或通过骨干网灵活的部署于车站和中心。

    在本设计中，软件体系结构设计的关键是采用了中间件组件技术。分布在网络计算机上中间件提供了一个编程抽象，对底层网络、硬件、操作系统和编程语言异构性的屏蔽。中间件技术的透明分布解决了服务器软件模块之间耦合过紧的问题，从而将软件体系结构从对硬件体系结构的严重依赖中解脱出来，将软件系统从集散型处理过渡到分布式处理。

    在本系统设计中,以客户形式出现的操作员站应用程序和以资源管理者形式出现的服务器程序使用中间件层进行交互，中间件提供了分布于全线广域网各节点中对象或进程间的远程调用。在监控中心，以软件多机服务器群实现中央服务器的功能。中间件技术的采用，使得系统基本结构由以服务器为中心的集散型结构转变为以网络为中心的系统。建立中间件层使得真正的客户应用专心于应用本身，而不用关心数据来自哪里，也无须考虑网络层的应用协议。

    基于中间件组件技术的地铁综合监控自动化系统软件结构示意如下图1：

    中间件的使用解决了操作系统和硬件的不同。虽然在该系统的设计中，UNIX操作系统和WINDOWS PROFESSIONAL 2000操作系统都要实现TCP/IP协议，但它们没有必要提供相同的协议接口。如UNIX中消息交换的调用方法与WINDOWS PROFESSIONAL 2000的调用方法不同。

3.分布式数据库和系统数据流

    本设计的实时数据库以分布形式存在，系统没有一个实体化的相对集中的数据中心，而是网上多个数据中心。通过“代理”中间件的路径选择，使一个地理或功能上分散的系统的全部信息形成一个全局数据库，任一操作站都可以访问任何一个服务器，实现本地或远程的监视和控制。

    中间件技术的采用，同时使得实时数据库的分布由集散转向了以网络为中心，同时数据的上传和访问方式也发生了很大的变化。一般原则是域内服务器与I/O站之间采用复制性上传，而在监控中心服务器与各域之间采用订阅/发布方式。通过中间件可以访问系统的任何数据，可以是同步读写或订阅。中间件负责将应用请求定位于可用的服务对象。正常情况下，首先选择本域服务器，如本域服务器故障，则旁路本域服务器，将请求转向下一级服务器。同时对服务器的旁路能力也使各级服务器不再成为瓶颈，即使服务器故障，也不影响人机界面对设备的直接访问。
这种实时数据的访问模式如下图2所示：

4.接口通信框架

    不同的现场的设备是通过特定的通信协议接入系统的，因此系统必须实现各种不同通信协议处理的开放性。如果我们能够构造这样一种通信协议的开发平台，使得不同人开发的通信协议处理程序通过一定的固定步骤，方便地集成到系统中来，即通信处理任务的开发者只需要关注通信协议本身，而不必关心数据的应用，那么我们就可以极大的提高通信协议开发的方便性，而且不会影响系统的稳定性。

    要达成上述目标，将I/O站软件采用层次化结构，将应用层和协议驱动层分开，将会是一种比较理想的解决方案。如图3所示：

    本设计的关键是在将应用层和接口层分开并使得应用层软件组件保持相对稳定的基础上，在接口层建立这样的一种框架，即驱动的公共部分，如动态连接库、数值工程转换，跟协议的个性特征分开，使得公共部分保持相对稳定。这种接口框架在集成系统的数据采集层上，协议开发者只要关注通信协议的特有属性本身，即接口层的通信协议处理层。接口框架还为接口开发提供了统一的格式和步骤，以一致的方式处理通信接口，并为统一的开发模式提供支持。系统针对不同的通信协议，启动不同的协议处理任务，每个协议处理任务实现自我管理，主动完成对公共部分的链接和调用。

    本设计强调I/O站内核和应用的相对稳定性，在这基础上强调接口编成模式的统一，工程管理的规范，从而实现方便的接入多种子系统或设备的目标。

5.骨干网数据实时性、可靠性设计

    由于新建的地铁系统中通常建有骨干网，作为地铁全线所有信息的传输通道。综合监控自动化系统被分配使用其中的一部分带宽，因此综合监控自动化系统是骨干网基于宽带广域网开发的，并作为整个系统的“内网”，而通信前置机位于各远方站/子系统，因此来自外部系统的数据实际进入到以骨干网为核心的跨越较大地理位置的分布式数据库中。为达到系统的实时性、可靠性和数据一致性，本设计中除了底层网络协议采用了高可靠性的TCP/IP协议外，高层通信协议中还采用订阅-发布技术。该技术是由客户应用一次性向本域实时数据库服务器发出订阅数据请求，服务器登陆该请求，并周期性将实时数据的最新值发布给客户，直到客户应用取消订阅。当服务器本身不能提供所订阅的实时数据时，则再向下级服务器或数据源站订阅，这种逐级订阅能力使得监控中心操作员站也能读到最底层的I/O站实时数据。服务器可以归并应用请求，如当两个操作员站显示同一画面而服务器仍需向下层数据源站订阅时，相同点数据只发送一次。

    中央服务器是通过动态的订阅/发布机制向各域服务器请求自己想要的数据，而不是规定全部数据都要上传。采用这种方式旨在减少通过系统骨干网的无谓的数据传输，仅当当前使用的数据才传上来，从而大大减少骨干网的负荷。这种方式极限情况下才等同与全部数据上传，通过骨干网的数据流量如下图4：

6.结论

    软件体系结构、实时数据库结构、接口通信框架和骨干网数据实时性、可靠性设计，是城市轨道交通综合监控自动化系统的关键。采用基于中间件组件技术的分布式处理；采用实时分布式数据库技术，使一个地理或功能上分散的系统的全部信息形成一个全局数据库；采用I/O站内核和应用的相对稳定性，在这基础上强调接口编成模式的统一，工程管理的规范，从而实现方便的接入多种子系统或设备的目标；采用逐级订阅、动态的订阅/发布机制，提高骨干网数据传输的实时性和可靠性等。以上关键技术的解决，是开发安全、可靠的城市轨道交通综合监控自动化系统软件平台的基础。

缩写：

CORBAR: 公共对象请求代理体系
PSCADA: 电力监控系统
EMCS: 机电设备监控系统
FAS: 防灾报警系统
SCR: 车站控制室