以行车指挥为核心的综合监控系统软件集成方案研究

谢红兵，刘小树，智艳利（北京和利时系统工程有限公司，北京 100176）

以行车指挥为核心的综合监控系统软件集成方案研究

谢红兵，刘小树，智艳利（北京和利时系统工程有限公司，北京 100176）

1　引言

城市轨道交通综合监控系统ISCS（Intergrated Supervisory Control System）是通过建立一套统一的软硬件网络平台，对地铁机电设备系统进行协调、管理、监督和控制。ISCS将各自独立的机电设备控制系统通过网络有机地联结在一起，目的是由ISCS监控和协调各相关子系统设备的工作，充分发挥各种机电设备的效率，降低地铁运营成本，提高设备管理水平，节约资源（人力和物力资源），并为OCC控制中心和乘客提供一个便利快捷舒适的工作环境和乘车环境以及在灾害发出的情况下最大限度地保护人的生命和财产安全。目前国内的综合自动化普遍采用的是以电调、环调为核心的综合监控系统方案，即综合监控系统与信号系统中的ATS（自动列车监督）子系统互联，进行信息交换。这种方案没有将地铁运行中最重要的环节“行车调度指挥”真正集成，使得综合自动化系统最重要的系统联动功能难以充分发挥作用。[1]

以行车调度为中心的综合监控系统这一课题在国内已经开展了几年的研究，并有不少论文发表，比如文献[2]研究了综合监控系统集成ATS的优缺点及可行性，得出综合监控系统集成ATS具有一定的实施基础并可大幅度提升运营管理效率的结论；文献[3]则给出了戴帽、内嵌和完全集成3种实施方案，并在集成系统的接口范围、接口划分和功能设置上都给出了具体的方案；而南瑞和卡斯科已经在北京地铁6号线实现了一个集成后的系统，并取得了不错的效果。但是，以上的研究和实施更偏重于认为传统综合监控系统与信号系统是两个厂家提供的两套系统，强调接口分开，这就使最终系统的集成度取决于两家软件的开放程度，因此是一种“有缝”的集成。这对于以后系统功能的扩展，特别基于联动的列车事故管理功能的逐步增加是不利的。比如新的功能可能要求双方的接口都要修改，协调起来比较困难。

本文通过对传统综合监控系统和ATS系统的软件特点和功能分析，从软件体系结构的角度提出一种基于OPC基金会发布的最新国际标准OPC UA的“无缝”集成解决方案，期望能有助于解决上述问题。

2　功能分析

2.1传统综合监控系统

传统以电、环为核心的综合监控系统通常是一个地理分散分层分布式系统，通过功能集成和技术集成将地铁日常运营和辅助运营的各个自动化子系统集成在一起，实现集中化和一体化协调运作。其主要特征是统一的人机界面（HMI）和统一的体系结构。综合监控系统的核心是一个运行在通用硬件平台上的SCADA软件，该软件通常具有基于中间件和组件结构的客户/服务器体系，分布式面向对象编程结构，高效的、支持层次化对象的实时数据库、事件驱动和周期调度的计算引擎，可插拔的接口I/O驱动（以接入外部子系统），全套的实时、历史数据和事件的管理等，还融合了大量COTS软件，比如关系数据库。此外，还要包括一组支持扩展的API，这是SCADA软件能成为综合监控软件平台的一个基本条件。其功能主要包括数据采集、远程控制、报警管理、历史趋势和统计、报表生成、二次计算、运营记录和事故回放等。

传统综合监控系统所集成的自动化专业的共同特点大都是基于测点的。但是在监控特点上，实际被集成或互联的不同专业子系统并不完全相同，比如电力专业，其三级监视（变电所、车站和控制中心）、二级控制（中心、变电所）是比较典型的SCADA监控方式，强调正常运营时的全局性协调和事故情况下的本地直接控制；而面向车站和区间机电设备监控的环控（BAS）专业，其在控制中心更像是采用了一种所谓的Observer（观察者）模式，其主要的控制点在车站一级；而互联的某些子系统，比如AFC，则呈现一种“反向”的Observer模式，即中心作为数据接入点，车站作为观察者。以上这些均要求SCADA软件平台能够通过适当的配置和部署自动适应。

因此，作为综合监控系统核心的SCADA软件，往往强调的是它的通用性和开放性。

2.2ATS（列车自动监督）

ATS系统传统上属于信号系统，位于整个ATC系统的最上层，是地铁信号系统的指挥中枢，是集自动监控、信息管理和综合决策为一体的综合系统。主要实现对列车运行及道岔、信号等设备状态的监督与控制，给行车调度人员显示出全线列车的运行状态，监督和记录运行图的执行情况，在列车因故偏离运行图时及时做出调整，按照计划自动完成对全线列车运行的管理。在系统故障或其他特殊情形下，使调度员可通过ATS人机界面进行人工干预等。其典型功能包括列车追踪和识别、自动调度、自排进路、自动列车调整和控制请求确认。此外还包括一些常规的监视系统功能如报警处理、历史记录等。在系统体系结构上，根据信号系统厂家的不同，大体上有集中式、分散自律式和分层分布式几种。

相比于以电、环为核心的综合监控系统，ATS系统有以下几个特点：

（1）ATS是特定的业务系统，强调的是专用性而不是通用性；

（2）ATS有自动控制功能，例如自排进路、自动调整等，自动命令与底层列控系统构成控制回路，这与综合监控其他专业偏重人工或半自动的开环控制有所不同；

（3）ATS属于安全相关系统，如文献[4]中列出的中途停车、取消临时限速、解除区间封锁或施工区等可能潜在地导致系统危害的操作，故其安全完整性等级是SIL2级。此外，从系统集成国际标准IEC62264（GBT20720）《企业控制系统集成》的分层模型角度看，ATS并非同综合监控系统其它典型专业那样完全属于面向过程的控制系统，而是有相当一部分功能类似于制造业工厂中的MES系统，典型就是运行图相关功能，包括编制、执行、执行过程监控、计划调整和实绩的统计，以及设备的维修等，唯一不同的是制造业中围绕的是生产计划，而轨道交通围绕的是运输计划。这就表明ATS系统本身不是铁板一块，而是可以拆分的。

3　建议的解决方案

3.1功能分布

根据前面的分析，我们提出的解决方案是将目前地铁多数信号标中要求的ATS系统功能拆分为两部分：基本监控和行车指挥，基本监控包括对列车和信号设备（道岔、轨道区段、站台设备、信号等）的监视和人工控制（道岔、进路控制等），这部分由综合监控的SCADA软件平台实现。而行车指挥部分则作为监控软件平台之上的应用程序，通过读写综合监控数据平台中的数据，实现ATS的列车跟踪、自动控制和自动调整功能。ATS部分的功能运行中，实时数据取自综合监控系统数据平台，静态或实时数据（如轨道数据、运行图数据等）仍取自关系数据库。集成后的系统使用原来综合监控系统提供的统一风格的HMI，由SCADA平台实现站场图列车跟踪显示，ATS系统专用对话（如运行图等）以控件形式嵌入到该HMI中。示意图如图1所示：

图 1 ATS应用程序与综合监控平台的关系

本方案中，综合监控的通用SCADA软件平台直接与底层信号系统中的ATP、CBI、VOBC等接口，实际截断了原来ATS与底层信号系统之间的数据传输通道，并起到一种底层信号系统的代理作用。它向ATS应用软件提供实时的、原始的信号设备状态，所有ATS产生的命令，都经由综合监控系统的实时服务器和前端机（FEP）输出，使得ATS能够控制相关的现场设备。

融合了ATS基本监控能力的综合监控软件平台与原来相比，需要增加一个至为重要的功能，即人工控制命令与自动控制命令互锁，适用于任何列车和信号系统设备以确保：

• 受ATS基本监控影响的所有操作员请求控制的优先级都比ATS应用程序的自动命令优先级高；

• 所有操作员控制请求都被直接发送给现场，并遮蔽ATS应用程序产生的现场命令；

• 所有ATS应用程序产生的命令都不能遮蔽操作员命令。

例如，对ATS应用程序建立的进路请求，有权限的操作员可以取消该进路并请求设置另一条进路，并且后一条人工建立的进路不能被自动进路所取消。

3.2数据存储

本方案中，ATS应用程序与自含的行车调度所需的静态数据和运营数据一起工作，大体包括：物理轨道拓扑（防护范围内的车站、站台、停车点信息、道岔信息、坡度、限速、线路长度、上下行股道信息、信号机及左右线路等）、运营网络（正常运行交路、降级运营交路、调整规则）、进路表、运行时刻表、发车列表等。

综合监控数据平台则包含所有来自现场的信息（道岔、轨道占用、站台占用、信号等）以及HMI站场图列车移动动画所需要的由ATS处理后的信息（如列车识别号、逻辑区段的占压等）。

3.3数据交互

ATS应用程序通过访问综合监控数据平台获得如下信息：

• 物理轨道占压状态；

• 进路情况；

• 道岔状态；

• 信号情况等。

ATS应用程序将处理过的如下信息写入综合监控数据平台的实时数据库中，或穿过综合监控数据平台的提供人工/自动命令互锁机制输出到底层信号系统。

• ATS占压状态；

• 轨道上的列车数量；

• 进路排列命令；

• 区间列车速度命令；

• 站台停靠时间命令。

ATS应用程序周期读出（例如每秒）综合监控数据平台中相关监控设备的状态，执行运输管理的处理（列车跟踪、车站发车管理、列车进路的选定及在线调整等）以及写入动画显示所必需的结果；ATS周期性（例如每10秒）监督旅行信息的显示并核查列车到站，以便修改预报时间。

4　软件体系结构

4.1中间件服务总线

与其它类型的分布式应用程序一样，现代SCADA软件也广泛采用基于中间件和基础件的面向组件的软件架构方法。这种方法是将以前的客户端/服务器两层结构扩展为三层，把业务逻辑的处理抽象成一个个基础组件，然后把这些组件用一个中间层组件（中间件）进行协调，由中间件负责各个组件所需要的事务和安全等公共基础服务以及组件的管理和监控等，这就使中间件成为一条类似硬件总线的软件总线。基于软件总线，任何应用程序或软件系统就能方便地集成到以该中间件为核心的系统中，在“软件总线”之上实现“即插即用”。软件总线机制使得基于中间件开发的系统具有良好的可扩展性，使得系统结构的差异对应用层透明。

在选定了一种中间件技术之后，所有的软件组件都在这个选定的中间件平台上面搭建。曾经流行的中间件平台包括：SUN公司主导的J2EE平台，微软主导的COM/DCOM平台以及OMG主导的CORBA平台。目前在地铁综合监控系统的SCADA软件平台中运用比较广泛的是CORBA和DCOM。一个典型的ISCS软件包的体系结构如图2所示。

图 2 一种ISCS软件体系结构

基于这种中间件技术的接口技术具有3个特点：（1）通信方式以同步调用方式为主；（2）网络环境以局域网为主；（3）集成层面以数据层和方法层为主。位于某个安全边界之内的单条线路的综合监控系统采用这样的软件总线还是比较合适的，这也是目前国内地铁综合监控系统的主流。

但是从未来发展趋势看，综合监控系统必然在垂直方向和水平方向参与更大范围的系统集成。水平方向上，目前在路网层面考虑问题比较少，对于路网线路间的灾害信息互传及联动控制配合的接口方案普遍没有进行深入研究，比如换乘站发生灾害时，对相关各线均有影响，须各条线路共同管理。从地铁运营角度看，要求整个车站的防灾设备统一调度，这就需要不同线路的综合监控系统之间的集成互操作。垂直方向上，综合监控系统也需要向信息化层面扩展。

因此，我们认为目前采用的基于现有的中间件平台的开发的产品还是存在一些弊端。

（1）耦合度过高。客户端和服务器必须是相同的中间件平台，双方使用相同的接口IDL，IDL定义的任何改变都会引起互联双方的软件重新编译，并且这中间没有一种中间件技术可以完全盖过其它技术。不同厂家的软件产品在集成时可能会因选择的技术平台不同而形成新的“信息孤岛”。

（2）安全性困难。一个系统的安全性是指其可以免受非授权访问和操作的特性，具体包括身份认证、授权、保密性、数据完整性等。上述中间件平台也都提供了相应的安全机制，例如CORBA的安全服务，但都不是固有的，并且设置起来比较困难。

（3）防火墙不友好。上述中间件平台普遍采用通讯端口动态分配，比如基于DCOM的OPC客户端首先通过TCP 135端口向OPC 服务器发送连接请求，由OPC服务器动态分配一个1024~65536之间的动态端口号返回给OPC客户端，然后OPC客户端再通过这个动态端口向OPC服务器发送数据请求，并获得对应的控制数据。因此如果防火墙隔开了客户端和服务器，因端口不固定，通讯就难以完成。

（4）除非采用传统OPC，否则接口定义没有统一的标准。其接口的应用层语义是厂家各自规定的，所以并不稳定，导致无法适应不断变化或增长的应用软件需求。

因此分布式应用之间的互通互操作问题依旧存在。为避免上述问题，建议方案是采用的国际标准OPC UA来取代上述中间件作为综合监控系统平台的软件总线，使该平台成为具有安全性、可扩展性、实时性、支持事件聚合和过滤的SOA（面向服务体系结构）的系统，并能融合基于扫描和事件驱动的子系统。

4.2OPC UA功能特征

OPC UA是OPC基金会提出的一个较新的规范，并已由IEC62541[5]标准化，用于工业系统中应用之间的数据交换，基于Web服务的概念。OPC UA的设计目标之一是使用标准的网络基础设施访问大量实时数据，同时保持足够高的性能。OPC UA指定了一个客户机/服务器模型进行信息交换，客户端可以访问、读取和修改的服务器的地址空间。该规范为服务器上的信息表示定义了对象模型，以及一个预定义的服务集，用于浏览、查询、创建和操纵地址空间中的对象。信息是用OPC UA和供应商定义的数据类型、编码和传输映射来通讯的。目前OPC UA被普遍认为是互联网时代的工业控制标准协议。

OPC UA在几个重要方面扩展了先前的传统OPC工业标准，如平台独立、可伸缩性、高可用性和互联网能力。其以下重要技术特征可以为综合监控系统的通讯骨架和软件的互操作带来诸多好处。

（1）平台中立。通讯技术独立于厂商、行业、操作系统和编程语言。对主流的操作系统和编程语言都有相应的协议栈版本。OPC基金会为它的成员提供了以3种不同的编程语言编写的通信协议栈形式的实现——ANSI C、C＃和Java 。而协议栈是由OPC基金会维护的，这样可以确保采用OPC UA的不同产品之间能互联互通。

（2）面向服务的架构。OPC UA定义了一组粗粒度的通用服务，对于不同的功能（读/写/发信号/执行、导航/搜索、连接/会话/安全），OPC UA定义了不同的服务集。这些服务集完全覆盖和扩展了传统的OPC DA、A&E和HDA的功能，并已经标准化，因此相互是兼容和可互操作的，无须调用者对某个特定的服务的结构和行为有专门的了解，也不需要像经典Web Service那样定义WDSL。

（3）可穿越防火墙。OPC UA采用了一种基于TCP的、优化了的二进制协议，只在4840端口进行数据交换，该端口已在IANA（The Internet Assigned Numbers Authority，互联网数字分配机构）中注册，因此在防火墙中只需要开辟这一个端口。与信息系统互联时，也可以选择支持Web Service和HTTP。集成的加密机制可确保在互联网上的安全通讯。

（4）固有的安全性。OPC UA的安全模型完全把其适用场景定位在一个开放的网络环境下，因此采用了成熟的安全理念，包括用户身份验证、消息签名和传输用户数据的加密等选项。技术上采用基于安全的互联网通信已经证明了的标准，如SSL、TLS和AES等标准，使用X509证书、Kerberos或用户/口令字方式进行应用程序的认证，以确保防止未经授权的访问或过程数据的破坏，以及因操作不慎所产生的错误。并且安全机制是标准的一部分，对厂商是强制性的。用户可以按照自己的使用情况并入各种安全功能。此外还提供安全审计功能。

（5）高可用性。OPC UA定义了一个健壮的体系结构，具有可靠的通信机制、可配置的超时和自动错误检测和恢复机制。OPC UA客户端和服务器之间的通信连接可以被监控。OPC UA还提供了可应用于服务器和客户端应用程序的冗余功能，以防止数据丢失，从而实现最大正常运行时间的高可用性系统。

（6）可伸缩性。OPC UA可以在不同方向上控制规模，伸缩幅度相当大，既可以在硬件资源有限的嵌入式设备，也可以在非常强大的主机上应用。目前既有实现在芯片级的用例，也有实现在Amazon云中的项目。

（7）支持信息建模。OPC UA定义了基于“节点”和“引用”的抽象数据模型，服务器可以在它的地址空间中暴露某种类型的访问节点的实例。该地址空间可以按层次化或非层次化方式组织节点，并由引用相互连接形成一个完整的网状网络。 使用OPC UA通讯的厂家或其他标准化组织可以基于该数据模型定义和扩展自己的信息模型，形成自定义类型。客户端可以在权限许可的情况下仅通过不变的标准服务沿着某种引用发现或浏览服务器中存放监控对象的实例和类型系统。目前如IEC、EDDL、PLCOpen、ISA95等国际标准化组织均依据OPC UA发布了定义本应用领域信息模型的配套规范。

（8）发现机制。OPC UA定义了不同的“发现”机制，可以通知到所有具有OPC UA能力的设备及其在子网内的功能/特性。因此，挂接在这条软件总线上的组件和业已提供的功能（服务）之间的通讯是自组织的，可以“即插即用”地参与到“智能”的、网络化的组件编排/组合中。

4.3OPC UA的运用

本节提出的以行车指挥为核心的综合监控系统建议方案和上面介绍的OPC UA的功能特征进行分析，以说明给出的软件体系结构的适用性。

4.3.1SOA架构

采用这种架构潜在的含义是采用面向消息和异步通讯，服务在形式上被界定为服务提供者和消费者之间的消息交换。这就比一般中间件技术偏重于同步执行的远程过程调用（RPC）有更大的可伸缩性，可以避免数据访问时某个耗时长的事务阻塞客户端其他任务的执行，从而可以支持更多的客户端。同时OPC UA还支持服务等级和负载平衡的概念，这一点非常有利于综合监控系统的数据平台未来向IT层开放，以及支持当前数目不定的复示工作站的需求，通过工程配置可以在这些数据访问需求和面向过程的操作员工作站之间取得性能的平衡。

4.3.2安全性

ATS原本属于信号系统中的一个子系统，一般认为其应处于一个封闭的网络环境内，但是，当采用完全集成方案与综合监控系统进行软硬件一体化后，这一前提是否还能成立？从综合监控系统发展趋势看，通过深度集成无线通信系统，有可能实现现有综合监控系统的可移动化和远程服务能力，从而改变以往系统只能在车站和中心调度室固定终端上操作和使用的缺点。针对地铁维修人员提供移动维修功能，针对地铁火灾等紧急情况下提供应急预案管理、指挥和决策辅助功能等[6]。这一趋势对以行车指挥为核心的综合监控系统同样适用。因此，此时必须按照开放网络环境来考虑，即最终的系统应按照EN50159-2而不是EN50159-1的环境要求来进行安全认证。这其中的主要区别就在于开放网络环境中，“具有未知、可变或非受信属性且数量未知的参与者”可能对安全相关系统带来的信息安全风险。对此，我们认为OPC UA提供的安全机制可以给予足够的防护，因为OPC UA是在开放的企业内联网和互联网的场景下建立的安全模型。目前OPC UA在同样高安全完整性等级的核电站上已有应用。

4.3.3高可用性

与一般WebSeverice的“无状态”模型不同的是，OPC UA要求一个“有状态”模型作为增强通讯健壮性的一个特征。状态信息被保存在应用程序的会话内。状态信息的一个例子是订阅，用户凭证和延续点可以在操作上跨越多个请求。 OPC UA通信遵循客户-服务器模式，客户端发送一个异步服务请求，并从服务器接收响应。每一个服务调用包含一个可配置的超时时间，客户端将等待直到响应到达。这确保了一个高度响应性系统。序列号用于识别对应的请求/响应消息配对。当订阅事件或值变化通知时，每个发布的数据响应由客户端用下一个发布请求进行确认。万一连接中断或传送失败，服务器保留未确认的消息，并在连接再次恢复时重新发送他们。在此期间收集的数据将被服务器缓冲或排队，使得在短暂的网络中断不丢失任何数据。OPC UA保证可靠的数据传输而不丢失数据，即使是在不可靠的传输媒介上。这种机制可以有效防御EN50159-2之附录D[7]中列出的大多数如下基本消息错误：消息重复、删除、插入、重排序、损毁、延迟和伪装（除延迟外）。由于建议的以行车指挥为核心的综合监控系统方案将原来ATS中的基本信号监控功能转移到综合监控软件平台，因此相应的通讯环节的RAMS要求需要基础平台来承担。

4.3.4支持信息建模

OPC UA不仅是一个通讯协议，同时也提供了一套信息建模的规范，从而使系统集成更具“智能性”。如果地铁综合监控所集成的大量子系统都能统一到此规范（尽管目前还不现实），则可大大缩短工程实施阶段的设计联络和接口谈判时间，从而缩短建设周期。作为客户端的集成系统只需要持有被集成系统的授权证书，即可访问被集成系统数据库中的所有数据类型，并浏览所有的监控对象实例，根据自己的监控或查询要求选择，而无需集成系统的厂家再提供如测点清单之类的文档。

支持信息建模的另一个好处是对紧密集成的互操作软件，如本文所涉及的综合监控系统平台软件与ATS软件的集成的用例，接口更加清晰和标准。如前所述，综合监控系统平台软件强调的是它的通用性，其本质上仍属于一种通用的组态软件，而这种“通用性”更多指的是面向测点的工控系统，其所监控的对象状态最终会落在如模拟量、开关量上。而ATS并非典型的工控系统，其核心数据结构与常规的工控系统并不完全相同。例如一个轨道区段（计轴区段）可能会表示成如下的一个复杂数据结构：

该区段对象的每个状态元素都不构成典型的模拟量、开关量。运用OPC UA扩展性和信息建模，就可以解决这一问题，使得该轨道区段对象在保持原有信息结构的前提下，能够存入具有OPC UA地址空间格局的综合监控数据平台的实时数据库中，还能用通用的服务接口访问。方法是综合监控系统平台软件可以按照“抽象工厂”设计模式为应用程序（这里是ATS），提供一个“工厂”模板，该“工厂”的职能是将具有一定复杂数据结果的监控对象定义加载到综合监控数据平台的实时数据库中。而作为ATS一方，仍可保留其原有的数据配置工具（比如站场图编辑器）和工作方式，只需要实现基于该“工厂”模板编写一个具体的“工厂”，按照OPC UA规范的地址空间数据模型的要求把站场图编辑器产生的、有必要存入实时数据库的数据结构和实例加载到同样符合OPC UA地址空间要求的实时数据库中即可。这样ATS软件就可以在运行时通过标准服务访问具有自己设计并熟悉的数据结构的实时信息。图1中的“联动应用程序”也类似。

4.3.5发现机制

目前国内地铁建设的一大特点是一条线路分期施工、分批开通，发现机制很适合这种系统不断“生长”的过程。新开通车站的综合监控系统所涉及的服务器可以自然地融入已投运的那部分车站的系统，而没有硬性的如工程重构、倒切等人工干预过程，最终规模不断扩展的服务器集群形成整个系统的服务云。

5　结语

本文从功能分析出发，探讨了以行车指挥为核心的综合监控系统软件的集成方案，给出了一个建议的体系结构，并对该结构所涉及的关键技术OPC UA在城市轨道交通自动化乃至信息化体系中的作用和应用前景进行了分析。我们的判断是，集成与开放是未来必然的发展趋势，因此以开放的、成熟的商用化和标准化技术取代专有技术应成为新一代城市轨道交通自动化系统的基本设计理念。

[1] 周庭梁, 孙军峰, 孙春荣. 谈以行车指挥为核心的城轨交通综合监控系统[J]. 现代城市轨道交通, 2009, (3).

[2] 郭永泉. 城市轨道交通综合监控系统集成信号ATS的研究[J].现代城市轨道交通, 2008, (6).

[3] 魏祥斌. 集成信号列车自动监控子系统的综合监控系统方案[J]. 现代城市轨道交通, 2012, (8).

[4] IEEE Std 1474.1-1999 IEEE Standard for Communications-Based Train Control(CBTC) Performance and Functional Requirements[S].

[5] International Electrotechnical Commission: 62541-1 Ed. 1.0: OPC Unified Architecture Specification -Part 1: Overview and Concepts. IEC Std, 2008[S].

[6] 李天辉.城市轨道交通综合监控系统的技术发展[J]. 自动化博览, 2013, (10).

[7] EN50159-2: 2001 Railway applications-Communication, signalling and processing systems -Part 2: Safety related communication in open transmission systems[S].

Integration Solutions Research for Urban Rail Transit Integrated Supervisory Control System with Traffic Control as the Core

本文从功能分析出发，研究了以行车指挥为核心的综合监控系统的软件集成方案，给出了一个建议的软件体系结构，并对该结构所涉及的关键技术OPC UA在城市轨道交通自动化乃至信息化体系中的作用和应用前景进行了分析。

综合监控系统；信号系统；ATS；OPC UA

Based on the functional analysis this paper introduces the the software integration solutions for Urban Rail Transit Integrated supervisory control system with traffic control as the core. One kind of software architecture is also recommended. The key technology OPC UA related to this architecture in urban rail transit automation and its application prospects are analyzed.

Integrated supervisory control system (ISCS); Signal system; Automatic train supervision (ATS); OPC Unified Architecture (OPC UA)

B 文章编号：1003-0492(2015)01-0090-06 中图分类号：TP273

谢红兵（1962- ）男，江苏南京人，研究员级高级工程师，本科，现就职于北京和利时系统工程有限公司，主要研究方向为分布式控制系统及其应用。

刘小树（1982- ）男，江西吉安人，工程师，硕士，现就职于北京和利时系统工程有限公司，主要研究方向为城市轨道交通综合监控。

智艳利（1982- ）女，河南郑州人，工程师，硕士，现就职于北京和利时系统工程有限公司，主要研究方向为城市轨道交通综合监控。