轨道交通综合监控系统接口标准化

陆艮峰 ，徐宏伟 ，梁 奕

（1. 南瑞集团国网电力科研究院有限公司，南京 211000；2. 国电南瑞科技股份有限公司，南京 210061）

随着我国各大城市轨道交通建设步伐的加快以及计算机和网络技术的发展完善， 轨道交通综合监控系统(ISCS)应运而生，通过采用先进的计算机技术和控制技术实现城市轨道交通控制系统的集成化、数字化和智能化，大大提高了城市轨道交通运营的安全性和高效性，已然成为当前城市轨道交通控制系统中的首选方案[1]，经过多年的发展，其功能已经日趋成熟和完善。ISCS集成和互联了众多的子系统如电力监控(PSCADA)、环控系统(BAS)、广播系统(PA)、乘客信息系统(PIS)、列车监控系统(ATS)、视频监控(CCTV)、门禁系统(ACS)、火灾报警系统(FAS)等，ISCS由于涉及的子系统接口众多，各专业接口实现方式差异较大，互通性差，导致系统接口协调、开发、调试等环节任务繁重，直接影响接口的实施进度，因此必须尽早通过可行的方法和手段解决以上问题。

1 接口分析

1.1 接口过程

接口管理涉及业主、设计院、系统集成商及接口子专业供应商等多方利益，与各子系统接口是 ISCS设计、开发和调试的重要组成部分，也是实际工程项目中耗时耗力的一环，关系到 ISCS整体功能、性能等是否达到设计要求，最终影响到 ISCS的实现以及系统的工期与质量[2]。ISCS接口工作主要步骤如图1所示，从接口启动到现场验收一般经历设计联络、接口协调、协议测试、现场大联调[3]等过程，中间过程可能反复多次，可以看出接口规范在整个过程中至关重要，多个环节都和接口规范有关，接口规范是接口内容核心所在，接口双方应尽早形成一致的接口详细规范文件，并将此文件作为双方接口开发的指导。

图1 ISCS接口实施过程Fig.1 ISCS interface working process

1.2 存在问题

ISCS建设管理过程实质上是系统接口对接与实现的过程[4]。传统ISCS接口实施的复杂性很大程度上是没有贯彻标准化的理念，不同系统的接口没有形成统一的接口规范，有的接口由 ISCS供应商牵头，有的接口由子系统供应商牵头，各方提供的接口功能类似，但接口协议实现方式不统一，导致相互协调工作量大。因此 ISCS实施的过程中最突出的问题主要集中在接口管理。纵观目前国内已建成的城轨综合监控系统项目，部分因接口管理或建设进度等原因而暂缓甚至取消原设计方案中部分功能，从而影响了综合监控系统总体效能的发挥[5]。

ISCS应对每个子系统进行接口标准化和规范化，适时制定城市轨道交通监控系统的接口标准，使得每个系统接口规范在不同工程项目中能够复用，不仅可大幅度减少设计和开发工作量，而且能极大地减少接口调试和协调工作量。

以功能为导向的接口标准化应主要在物理接口分界、接口责任、冗余要求、测试方法、接口功能、接口协议等方面做标准化定义，其中接口协议是实现数据接口标准化的关键所在。

1.3 接口分类

目前ISCS和集成/互联子系统之间接口根据数据流信息相关性特点，可分为基于点的数据和基于过程的数据。基于过程的数据也可能存在基于点的数据，例如设备状态、告警等信息。

1.3.1 基于点的数据接口

基于点即系统之间交互数据主要以数字量、模拟量以及电度量等点信息为主，控制方式也是对单点进行数字量或者模拟量控制，每一个信息元独立，典型子系统如PSCADA，BAS，FAS、集中告警等。PSCADA系统接口目前主要约定采用 IEC 61870—104协议规约，只需提供信息点表以及相关通信配置信息即可实现信息互通，随着智能数字化变电站的广泛应用，IEC61850标准规约也开始在轨道交通PSCADA监控上试点应用，互通性得到进一步加强，PSCADA接口基本做到接口的标准化设计。BAS系统为基于点数字量和模拟量数据，但关于时间表功能实现例外，时间表为一组相关数据序列，可以在指定时间自动控制一批设备的起停[6-7]。目前，BAS子系统通信主要采用工业控制领域已经广泛应用的工业标准 MODBUS-TCP规约，在时间表实现方面目前多个供应商基本已经形成一套约定俗成的交互方法，包括时间表编辑、下发执行、读回、删除、校验等操作流程，将来也可总结升级为标准规范。其他基于点的子系统大多是基于MODBUS、OPC等工业标准协议，只需定义数据点表和通信配置即可，已实现接口数据便捷的互联互通。

1.3.2 基于过程的数据接口

基于过程的系统除了少量的单点信息数据外基本都为过程控制流程，典型子系统如PA、PIS、CCTV、ATS等接口都是基于过程为主的数据交互，例如给PA下发播放预录制语音操作，其中可包括控制类型、播放区域、时间、优先级等信息，还有可能包含TTS文本信息，CCTV的摄像头调用、镜头缩放、云台控制、轮询序列控制等操作，ATS列车位置信息、到站信息等，这些操作都有共同特点，即需要一组约定的数据格式的数据才能完整表达交互内容，需要事先对每个数据域进行约定。一组数据放在一起才具备完整意义，且信息内容、形式多样化，这一块目前尚无统一标准，因此存在多种实现方式。每个子系统供应商接口实现机制和交互方式差距较大，数据定义较灵活，这就给ISCS系统接口互通增加了难度，在不同的项目需分别进行接口协商，在很大程度上影响了工程项目开发调试进度。

2 CCTV案例分析

闭路电视系统CCTV是城市轨道交通运行安全和维护的重要保障，是城市轨道交通运营现代化的重要手段[8-9]。CCTV系统接入ISCS有集成和互联两种方式，考虑到目前视频传输带宽和编解码等因素，目前CCTV主要采用互联的方式。CCTV作为一个独立的子系统，有一整套完整的设备和网络布局，ISCS通过接口通信方式完成对CCTV子系统的控制，根据协议设定命令格式发送操作命令；CCTV前端服务器收到相应命令后执行预定的动作，ISCS还可以采集CCTV系统的设备状态和故障情况。

目前CCTV实现的功能主要包括摄像头切换、变焦、云台控制、时序编辑和调用、设备故障和占用状态、预置位设定和调用等。以下结合北京、重庆、昆明3种典型的通信协议方案做进一步对比分析。

2.1 重庆3号线通信协议

重庆 3号线 ISCS与 CCTV采用的协议方案由CCTV供应商牵头提供，为基于TCP/IP的XML可扩展标记语言的通信协议[10-12]。在信息传输中为了防止传输失败，协议均采用一问一答的形式，即 ISCS向CCTV发送控制与询问报文，CCTV收到报文后给予相应的回复，在没有控制情况下每隔一定时间传送心跳信息，心跳信息只是作为检测链路通断的标志，协议通信内容作结构描述，可根据功能定义出所有其他类型控制操作数据结构。

例如ISCS向CCTV系统发出摄像机切换请求报文如下：ISCS-＞CCTV消息格式描述：

＜ACTION＞

＜sessionid＞ ID＜/sessionid＞//由CCTV 授权的通信 id

＜seqno＞xxx＜/seqno＞//通信序号，保证顺序

＜name＞ VEDIO _SWITCH_＜/name＞//功能码

＜params＞//操作参数

＜param name=”cameraid”＞摄像头编号＜/param＞

＜param name=”decodertype”＞目标地类型＜/param＞

＜param name=”decoderid”＞目标地编号＜/param＞

＜/params＞

＜/ACTION＞ //结束

CCTV-＞ISCS返回消息格式描述：

RESPONSE消息

＜RESPONSE＞

＜seqno＞xxx＜/seqno＞//通信序号，校验

＜code＞xxx＜/code＞//返回代码

＜results＞xxx＜/results＞//执行结果

＜/RESPONSE＞

2.2 北京房山线通信协议

北京房山线采用的是由CCTV供应商牵头提供的一套基于RS485串口的私有协议信息指令集合。信息集主-从关系：ISCS发送控制命令为主方，CCTV控制器为从方，来自主方的命令称为“请求”(REQ)，来自从方的命令称为“响应”(RSP)；一帧报文通常分为包头、指令、数据以及校验四部分，定义结构见表 1。包头为预定义的开头和总包长度等信息，具体的操作类型，如获取摄像头信息、切换视频等；数据内容是基于操作类型，描述操作的内容；校验部分通常采用CRC校验实现。同时根据实现功能可定义多种指令类型，指令类型下定义其数据类型，表2为选择摄像机命令数据域定义。

表1 报文结构定义Tab.1 Definition of the message structure

表2 摄像机选择数据定义Tab.2 Definition of the camera selection data structure

2.3 昆明地铁6号线通信协议

昆明地铁6号线由ISCS供应商牵头提供，采用基于标准MODBUS-TCP的协议方法，ISCS系统配置为主机，CCTV系统的通信服务器配置为从机，严格一问一答方式，ISCS通过读写CCTV寄存器的方式完成对 CCTV状态数据的采集和控制指令的下发，空闲时ISCS每隔一定时间向CCTV发送一次轮询报文，亦作为心跳报文。表3为从机定义的读寄存器区域表示的摄像机状态，一个字节表示一个摄像机状态，主机通过轮询该寄存器得到详细的摄像机状态数据。表4为CCTV定义的写寄存器信息，ISCS通过写入相应的寄存器实现对 CCTV的控制操作。

表3 CCTV摄像机状态寄存器定义Tab.3 Definition of the CCTV camera status register

表4 CCTV写寄存器定义Tab.4 Definition of the CCTV write register

2.4 方案比较

通过上述对不同项目典型接口协议的介绍，最后进行各自的优缺点分析比较，分析结果见表5。

表5 接口特点分析对比Tab.5 Analysis and comparison of interface characteristics

3 总结与展望

着重分析综合监控系统接口协议标准化，对责任划分、接口边界、测试方法等差异和争议较小部分没有做过多说明。目前基于点的数据接口已经基本做到通信协议标准化，但在基于过程的数据接口标准化方面还需要进一步推进。通过对CCTV接口案例比较分析，可以得出各自的利弊，鉴于当前子系统接口所具备的功能基本一致，接口协议标准化时机已然成熟。

根据通信技术、编程技术发展，服务器和网络设备等性能不断提升，同时标准文献[13]中要求ISCS系统应提供对各种系统的信息接入机制，应以标准的、可扩展的方式通过接口进行访问。XML语言具备自描述性、内容和形式分离、结构清晰、扩展性强、报文可视化等特性，用户可按照需要来制定标记元素，不同的专业子系统接口也可以在彼此协议的基础上自由制定适用的标记进行功能扩展增减，因此适用于如PA、PIS、ATS等专业信息交互。笔者推荐基于XML语言的接口协议可作为基于过程数据通信载体进行标准化推广，工程实施只需维护点表和配置数据。标准化设计可以大大节约接口时间，显著提高接口效率，最终实现系统间信息互通，也是综合监控系统接口通信发展的必然趋势。