随着城市轨道交通发展，各大城市快速呈现轨道交通网络化趋势，对线网运营综合效益提升和安全保障能力提出了更高要求。各大城市轨道交通运营经验证明，线网设施设备的正常运转是城市轨道交通安全运营的前提条件^[1-2]。已有统计资料表明，设施设备故障是引发城市轨道交通事故和故障的主要原因，占所有事故和故障起因约70%以上的比例^[3]。

城市轨道交通线网设施设备包括车辆、供电、环境与建筑设备自动化系统（BAS，Building Automatic System）、通信系统、信号系统、自动售检票系统（AFC，Automatic Fare Collection system）、火灾自动报警系统（FAS，automatic Fire Alarm System）、站台门等^[4-5]。传统的线网监视模式逐一对单一实体设备的状态进行实时监视^[6]，通过串行通信协议（MODBUS等）获取各条线路机电设备实时状态数据，真实显示设备当前的状态属性。对于各线路调度人员此模式可以详细掌握线路运营内各类设备运行状态，但线网层面更多关注的是影响到实际运营安全的报警事件，及时调动全线网资源进行应急处理，如把精力过多放在单一的设备运行状态变化，无疑对各项资源都是一种过度消耗。

目前，国内外对城市轨道交通监测预警的研究已经取得了一定成果。王征通过分析城市轨道交通设施设备故障综合评估预警需求，建立一套从单因素预警指标、设施设备综合子系统到线路综合系统的三级综合评估预警指标体系^[7]；李俊辉等人通过构建城市轨道交通车站安全预警指标体系及其阈值，实现对城轨车站安全状况进行预警分析^[8]；李曼等人通过分析闸机客流、通道客流等因素之间的关联关系，形成基于方程的关联预警分析流程^[9]；谢征宇通过对枢纽视频监控采集点间的关联度和客流参数预测方法的研究，提出基于空间的客流参数预测算法和基于时空的客流参数预测模型^[10]。通过对上述相关文献的分析发现，现有文献主要侧重于研究预警指标体系，安全评估体系，对于设备设施数据如何从单一状态采集监视到分级分类展示预警信息的业务流转体系和应急联动方面研究较少。

本文通过研究已有线网监视模式和应急管理模式（人工报送的“被动”应急模式），针对能够通过监测设备感知到的应急事件，如车站火灾报警、车站照明失电等，采取主动监测应急模式。通过分析线网综合监控专业、信号专业、通信专业等各设备数据的采集监视、逻辑处理、报警服务数据流转流程，形成基于“数据采集−逻辑判断−故障报警−应急值守”4步骤的监测预警方案，提前判断出影响运营安全应急事件的发生，帮助运营单位主动协调应对各类突发事件，及时处理潜在的故障威胁。

1   监测预警方案

线网运营下的各线路、各专业设备数据实时运行状态经过采集处理，通过计算服务平台输出符合业务逻辑需求的报警点，传送至报警服务存储更新，在报警客户端区分不同级别不同类型的报警点展示。

1.1   数据采集

采集线网各专业设备实时运行状态，采集的源数据包括城市轨道交通每条线路的综合监控、信号、通信集中告警和车辆等专业的设备信息^[11]。每个专业下细分各类系统，如供电系统、FAS、BAS同属于综合监控专业，源系统将需要采集的数据封装至相应的接口服务器，接入承载网的防火墙对流入承载网的数据进行安全检查，通过防火墙之后传输至接入交换机，接入交换机与汇聚交换机连接，汇聚交换机处理来自接入层设备的所有通信量，并最终将数据传输至数据库服务器存储。数据架构，如图1所示。

图  1  数据采集架构

下载: 全尺寸图片 幻灯片

对于网络化运营的城市轨道交通设有多条地铁线路，每条线路各专业的设备系统建设程度不同，接入原则也不同。单条线路的控制中心建有综合监控系统和通信集中告警系统时，统一从综合监控系统和通信集中告警系统采集数据；反之，则单独与FAS、电力监控系统、BAS、站台门系统、广播系统、时钟系统和无线系统等专业系统进行接口，采集数据。

1.2   逻辑计算

逻辑计算过程独立于报警服务，构建计算服务逻辑处理平台，实现数据逻辑处理与报警服务的松耦合管理。计算服务平台针对从源系统采集的数据进行筛选，对监测到的设备故障数据进行计算逻辑处理。通过MQ消息中间件接收数据，在计算服务平台中配置逻辑表达式进行运算处理。

1.2.1   计算过程

输入数据包含实时接收的设备状态点数据，需要配置的参数值数据以及运算逻辑数据。在数据库中通过配置计算逻辑表达式存储报警业务逻辑规则，计算服务平台通过Redis缓存方式接收所有计算逻辑表达式。平台实时接收设备状态点数据自动匹配业务表达式进行计算处理，如经计算后符合报警业务规则，则自动输出报警点数据。

1.2.2   时钟同步机制

部分专业设备报警点需要设定时间限制范围。时钟同步周期性发送报警时间范围参数及当前时间参数至计算服务平台，计算服务平台如需处理时间范围限制的报警计算，依托时钟同步传送的时间参数判断设备报警传送时间是否符合报警时间范围区间，最终将符合需求的报警点传送给报警服务。

计算服务平台逻辑架构，如图2所示。

图  2  计算服务平台逻辑架构

下载: 全尺寸图片 幻灯片

1.3   报警服务

1.3.1   报警服务端

通过ActiveMQ方式接收计算服务平台已经判断好的业务报警点，分发给各个客户端。记录每个客户端调度人员对报警的确认、消除等操作，再将最新数据分发给客户端，保证多个客户端报警数据展示同步。

1.3.2   报警客户端

接收服务端传送的报警消息，分级分类展示报警消息，供线网调度人员接收处置。

1.3.3   消息传送形式

报警服务端和报警客户端之间的消息传送均采用ActiveMQ方式，报警服务端通过发布/订阅方式向客户端分发消息，确保每个报警客户端都能够接收到消息；报警客户端通过点对点方式向服务端传送消息。消息传递，如图3所示。

图  3  消息传送

下载: 全尺寸图片 幻灯片

消息传送操作分为4类：初始化操作，新报警消息操作，报警确认操作和报警恢复操作。

（1）初始化操作。报警客户端初始运行时需要向报警服务端发送初始化消息，通知报警服务有新客户端开启，报警服务端接收到消息后将当前存在的报警发送给所有报警客户端。

（2）新报警消息操作。报警服务端接收到计算服务平台传递的新消息，将新报警消息入数据库，同时向客户端发布新消息，客户端接收订阅消息，展示报警数据。

（3）报警确认操作。报警客户端确认报警消息，向报警服务端发送确认操作。报警服务是更新数据库实时报警表该条报警记录确认状态，同时将确认消息发布给所有报警客户端，所有客户端界面进行报警的确认展示。

（4）报警恢复操作。报警服务端接收到计算服务平台传递的某一条已存在报警的恢复信息后，数据库实时报警表更新该条报警状态为已恢复，同时向所有报警客户端发布恢复消息，所有客户端界面不再显示该报警信息。

2   分级分类预警研判

针对监测到的各条线路所有设备故障状态，全部启动应急处置流程显然是不现实的。通过对我国各大城市轨道交通运营流程的调研，分析其监测设备数据类型以及突发事件应急预案类型，提出一套分级分类预警研判规则，划分一级、二级、三级报警等级，对不同级别的预警制定不同级别的响应方案。针对低级别、风险可控的事故预警，仅报送至线网调度员，调度员依据实际情况决定处置方案；针对高级别、严重影响车站安全运营的预警，直接启动应急处置流程，调配相应资源快速开展应急指挥流程，最大程度地降低突发事件带来的损失。

（1）一级预警。严重影响车站运营，涉及到行车安全、乘客安全级别的报警。大致包括：环控专业突发事件预警（车站火灾预警等）、行车专业突发事件预警（道岔故障、集中站信号失电、中心通信中断等）、电力专业突发事件预警（车站照明失电、主变电站失电、触网失电等）以及其他类型预警（车站大客流事件等）。响应方案：报送至报警客户端，同时启动应急处置流程。

（2）二级预警。影响行车或设备正常工作的报警。例如扶梯急停故障、整侧屏蔽门无法开启或关闭、车站闸机大面积故障等。响应方案，报送至报警客户端，报警消息置顶，直至线网调度人员确认报警，进行相应处置。

（3）三级预警。一般的设备故障或电气特性超限。响应方案：报送至报警客户端，提示线网调度人员查看处置。

3   结束语

通过分析网络运营模式下设备数据故障预警需求，构建“数据采集−逻辑判断−故障报警−应急值守”4步骤监测预警方案，实现多线路、多专业设备数据的重点监测和分级预警，为突发事件应急处置提供数据支撑和辅助决策依据，为城市轨道交通线网运营下如何实现大量设备数据的采集监测及预警研判提供一种研发模式。方案已经在天津市轨道交通应急指挥中心系统中初步应用，经验证，系统信息采集更新时间及报警响应更新时间均在1 s以内，具有可靠性，能在保证设备全面监测的同时及时发现设备运营中的故障隐患，帮助运营公司主动应对设备运营事故，为车站安全运营提供辅助决策数据支持。本文对于设备监测预警后的故障诊断维修方面还缺乏研究，后期需要进一步研究设备运维处置模式，实现设备全生命周期的运营管理。