城市轨道交通信号系统在线监测系统信息集成化平台方案研究

许华阳 李润锦

(广州铁科智控有限公司，510308，广州//第一作者，助理工程师)

目前，我国城市轨道交通信号系统的在线监测系统呈现多样化发展趋势。为了建设信息集成化平台(以下简称“平台”)，实现对各监测系统分散异构的数据源进行统一访问，本文通过对现有的监测模式进行改良升级，利用不同通信接口、多线程并发技术实时采集不同信号监测系统的数据，并将数据按前期数据库设计统一整合到研究上。本文所提出的监测模式打破了原模式中各在线监测系统的封闭性，使用户能够更便捷高效地获取信息。

1 信号监测系统现状分析

不同信号系统厂商的信号在线监测系统的信息格式定义虽然各不相同，但其都是对生产网内信号专业设备进行监测。信号专业传统故障监测模式为：故障信息只显示在特定工控机上；设置OCC(运营控制中心)调度和值班人员全天候值守观察；监测系统一旦出现故障提示，调度员或值班人员通过手持电台或电话通知现场维修人员，现场维护人员收到通知后对现场故障进行确认、处理、跟进。

城市轨道交通信号系统传统故障监测模式主要存在以下不足：

1) 监测系统较为封闭。各监测系统相互独立，相关信号系统的数据只存活在封闭的生产网络中，一些用户 (如使用办公网的管理人员) 想获取数据，必须到现场工控机上查看。随着线路增多，及时获取所有线路实时监测数据将变得十分困难。

2) 数据利用率低。相关数据 (如报警信息) 的利用场景单一，主要应用于响应故障，故障处理后的数据再利用率较低;并且数据在磁盘存放的周期较长，一定程度上造成了资源浪费。

3) 现场信息传递效率低。监测系统信息数据的传递方向是单方向性的，即用户从系统获取信息。故障信息与现场故障处理人员故障处理信息的传递通道上多了调度员和值班人员一环，这消耗了一定的信息传输时间，导致信息传输成本增大、时效性降低。

4) 对故障处理的指向性不高。传统监测模式下的故障处置流程主要为：值班人员通过在Glink(地铁内部通信软件) 生产群上人工填报故障信息，现场维修人员处理后在群上汇报进度以便相关人员跟进。若出现生产群信息较多 (特别是一定时间段多起故障发生时)的情况，生产群上的其他信息会对跟进某个特定故障的用户造成干扰。

另外，部分员工故障处理经验不足，而且又缺乏全面的故障处理指引手册，这也影响故障的处理效率。

2 信号监测系统信息集成化平台方案

2.1 解决方案

2.1.1 监控系统封闭性问题解决方案

通过自主研发、与厂商合作等方式开发相关接口，将各监控系统的数据整合到平台上，实现生产网内的数据实时传输到办公网络。用户无需在本地安装其他软件，通过浏览器登录平台、验证身份后即可获取用户想要的信息，大大提高了数据获取的便捷性。

2.1.2 数据利用率过低问题解决方案

在实现在线应急响应的基础上，平台能够实时地、智能地将有价值的数据传送给相关的分析系统或其他应用系统，进行信息的进一步智能分析管理 (如可靠性评估、专家诊断等)。通过对现有设备的可靠度进行评估，找出设备存在的薄弱环节，然后有针对性地制定预警机制、维修策略及整改措施来提升设备质量和服务可靠度。

2.1.3 信息传递效率过低问题解决方案

1) 方案1。监测系统自发地向用户推送信息，用户手机等便捷移动终端可实时接收到新消息。该方案的优点是：减少了调度员和值班人员这个中间环节，用户可以更及时地获取报警信息，降低了传输成本。该方案的缺点：对原有系统改动较大；因数据量较大，因此有大量的非关键信息需要用户筛选，增加了用户的操作成本。

2) 方案2。实现信息的多向传递。重点关键信息主动向用户推送，用户亦可从监测系统获取其他想要的信息。该方案的优点是：监测系统主动将信息推送给用户；而且已对数据做好分类，免去用户筛选信息的过程，提高了数据的时效性。该方案的缺点是：需前期制定相关信息推送规则；因数据处理量较大，因此对服务器的处理性能要求较高。

方案1和方案2都是监测系统主动向用户推送信息，使得信息源就在用户身边， 用户可以非常方便地获取到信息。综合考虑，方案2不过多地改变原有模式，而是在原有的成熟模式下进行优化，因此更贴合实际工作需求，有助于提高企业效益。

接送端通过办公网将串口或网络接口收到的数据上传到服务器，考虑到实时数据量较大，服务器的数据处理速度可能跟不上传输速度，因此需要设置一定的缓存机制。服务器端一般已有一些成熟的缓存机制(如Redis等)，通过多线程并发建立数据队列线程及处理线程， 利用本地内存或磁盘做缓存，以避免传输过程中的数据丢失。

2.1.4 故障处置指向性过低问题解决方案

通过研究发现：可与移动通信软件建立接口，实现故障自动推送；可通过优化人员配置提高信息传达准确度。本文提出了故障处理分类跟进的新思路：在对话窗口的每条故障皆为一个指令，点击指令可跳转到相应的对话框中；每个指令对话框只讨论该故障，降低了无关信息对技术人员判断故障的干扰；针对每个故障会自动推送相应的故障处理指南，供处理故障的技术人员参考；采集相关故障处理进度信息。优化后的故障分类跟进处理方式如图1所示。

图1 优化后的故障分类跟进处理方式示意图

2.2 关键技术方案

本次研究的关键技术方案包括跨网通信、在线监测、推送方式、多终端展示和应急等方案。

1 )跨网通信。针对不同线路特征，不同网络间数据的传输方式主要包括串口通信和HTTP(超文本传输协议)通信。

(1) 串口通信。对于一些版本较旧、扩展性较差的系统，升级整套信号系统的成本巨大，因此可以另外开发一套发送端程序，用以监测本地数据变化，当有新增数据通过串口时将该数据传送给接受端程序。

(2) HTTP通信。对于一些扩展性较高的系统，通过合作开发网络接口，使接收端程序能够直接访问对应的IP及端口，从而获取数据。

2) 在线监测技术方案。用户想通过客户端实时获取数据，需要与服务端建立连接，通过客户端与服务端互相通信以获得最新的数据。客户端与服务器网络通信的技术目前主流的有AJAX和WebSocket。WebSocket是一种长连接，对一些只需请求一次的操作，保持长连接会占用资源；对服务器的配置要求较高，不支持旧版本浏览器。AJAX作为一种成熟的技术，有较多框架支持，相对更加通用，可以进行与服务器异步通信；在请求数据的时候不刷新整个页面，可进行其他操作；数据返回后只改变局部内容。因此，本项目在线监测系统页面客户端与服务器选择AJAX轮询的方式进行通信。

3) 推送方式技术方案。用户获取信息的主要载体是手机和邮箱。基于现有的平台，研究将服务器与邮箱接口、手机APP程序接口进行对接，当服务器接收到新数据时，通过相关索引找到相应的联系人及联系方式，然后进行推送。采用这种推送方式可实现外网实时接收故障信息。

4) 多终端展示技术方案。在线实时监测系统的客户端可通过 CSS3的 Media Query和页面的 Viewport实现不同尺寸的终端展示不同的布局样式。一些界面交互控制可通过Javascript脚本进行操作。数据图表采用Html5的Canvas画布实现取代Flash，通过操作Canvas可实现响应的缩放。

5) 应急技术方案。故障应急处置是现场最有意义的一环，是最能改善企业效益的关键点。可通过以下方式优化原有模式的故障处理流程。

(1) 加强故障的指向性。监测系统对故障类型进行关联索引，当收到相应故障信息时，除了推送故障信息之外，同时推送相应故障的处理指南，方便依照规范处理故障。

(2) 减少无关信息干扰。平台通过Glink的开发指令功能在Glink群上为每个故障设置一个指令，点击相应的指令则跳转到相应故障的对话框，每个指令下只回复相应故障的信息。

3 应用情况及分析

本文所研究的城市轨道交通信号系统在线监测信息集成化平台目前已应用于广州地铁5号线，试运行至今效果明显：故障数据及列车状态等信息能在界面上实时正确地显示；报警信息能及时推送到用户终端上，有效提高了技术人员与管理人员对现场情况的把控；现场维修人员也能及时收到故障处理指南推送，提升了故障处理的时效性。本研究改善优化了原有的信号系统监测模式， 平台具有灵活性、扩展性等特点，目前处于示范应用阶段，平台将陆续接入广州地铁4、6、7号线的数据。

平台的科学性、先进性和创新性主要体现在：①可通过PC、平板、手机等终端实时获取信号系统的相关信息；②能够采集整合不同线路信号系统的故障信息，典型关键设备的故障信息采集准确率达到92%以上；③故障信息推送至用户手机和邮箱，用户可实时接收到最新的故障通知；④推送故障信息的同时推送故障处理指南，并针对每个故障建立了相应的故障对话指令，便于跟踪故障情况。

4 结语

本研究解决了城市轨道交通信号系统各监测系统的封闭性问题，实现了管理信息共享，提高了各级组织内部的有效协作性和快速反应能力。通过多接口、多线程、多终端等技术实现了主动向用户推送故障信息的监测新模式，减少了用户的信息筛选时间，优化了人员配置，提高了信息传送准确度。利用大数据技术可开展故障点分析、设备可靠性评估、优化应急处置等研究。平台目前仍处于不断优化调整阶段，数据源庞大，开发难度高，因此实现城市轨道信号系统在线监测平台化需要各信号系统厂商积极配合，以不断创新监测模式。