城市轨道交通综合指挥调度系统中全景化事故反演的设计与实现

华寅飞，高 昕

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

0 引言

城市轨道交通综合调度指挥系统(TIDS)是基于系统工程理论,将信号、通信、机电、供电等各种监控系统集成于一体化的自动化平台,从而实现在一个调度平台上对车、机、电的统一监控和管理。 TIDS 集成了列车自动监控系统(ATS)、电力监控系统(PSCADA)、环境与设备监控系统(BAS)、网络管理、仿真及培训管理等业务功能,可以为用户提供集运营监控、运营管理、调度指挥为一体的运营调度指挥平台,近年来常应用于有轨电车及地铁监控项目。

TIDS 系统对事故反演提出了较高的要求,其中,调度员的所有操作、列车运行状况、设备工作状态能自动或按调度员的指令进行回放。 回放数据需包括已记录的轨道、道岔、信号机等信号设备的状态信息,列车位置信息,中央调度员执行的各种操作命令和各种报警信息。 同时,在回放过程中对回放软件进行的各种操作不能对正在运营的线路和TIDS 的各种既有功能产生影响,即用户可在监控工作站对正常监控状态和反演回放状态一键切换。 为满足上述需求,需要搭建全景化事故反演回放系统［1］。

1 全景化事故反演回放系统的需求

系统具备全部采集数据(模拟量、开关量、设备状态信息、列车位置信息等)的追忆能力,可以全方位地记录、保存系统监视对象的事故状态,并且能够真实、完整地反演系统监视对象事故过程,即使系统监视对象已经发生了很大的变化,也能够真实地反映当时的情况。

系统根据给定的事故反演时刻自动匹配并调出相应的系统模型断面,再调出事故发生前的数据断面以重构当时的场景,在此基础上反演当时发生的事件序列,并由用户控制反演的进度。 事故反演数据能在工作站屏幕上重放整个事件过程,并能以图表等多种方式重新显示扰动数据的变化。 事故反演能够以设定的刷新周期在人机界面上一步一步重新显示,并能由操作员任意控制［2］。

2 全景化事故反演回放系统的设计

全景化事故反演回放系统主要依赖“回放态”设计与切换,全景采样数据存储和高效的全景数据查询与数据断面获取,实现事故录制和事故反演过程,具体内容如下。

2.1 “回放态”的概念与切换

为了保证用户监控的应用数据可在正常监控状态和反演回放状态之间切换,当某一个应用如列车自动监控(ATS)需要反演时,需要建立一个新的应用名为“ATS＿PDR”,这个应用即称为列车自动监控“回放态”应用。 回放状态下的所有监控的设备都属于这个“ATS＿PDR”的应用。

当用户在工作站人机界面内切换到反演回放状态时,该工作站监控画面的所有数据联点自动切换到“ATS＿PDR”回放状态应用下,接收回放数据；当用户在人机界面内切换到正常监控状态时,监控画面的所有数据联点自动切换回ATS 应用下,接收实时数据。 这样既实现了正常监控状态和反演回放态的一键切换,又不会在回放过程中影响正常实时数据的处理与TIDS系统正在运营线路的各种既有功能［3］。

2.2 基于Bekeley DB 的全景采样数据存储

Bekeley DB 可简称为bdb,是一种以key-value 为结构的嵌入式数据库,介于关系数据库与内存数据库之间,使用方式与内存数据库类似,它有以下两个基本特征。

(1)嵌入式:bdb 提供了一系列应用程序API 接口,调用这些接口很简单,应用程序和bdb 所提供的库一起编译/链接成为可执行程序。

(2)NOSQL:bdb 不支持SQL 语言,它对数据的管理很简单,bdb 数据库包含若干条记录,每条记录由关键字和数据(key-value)两部分构成。 数据可以是简单的数据类型,也可以是复杂的数据类型,例如C 语言的结构体,bdb 对数据类型不作任何解释,完全由程序员自行处理。

TIDS 系统依赖Bekeley DB 的上述特性,构建全景采样数据库。 在TIDS 系统中,点(point)是数据管理的基本单元,任何专业可测量的设备属性都可以被定义成point,点类型主要包括数字量和模拟量。 TIDS 系统的各监控专业变化数据都可以存储在全景采样数据库中,在全景采样数据库中,对数据的各种操作都是以点为单位进行的,任何采样点都进行了变化采样,以“点标签+时间戳”为key,采样值和状态为value,数据点变化后实时存入bdb 数据库。

2.3 高效的全景数据查询与数据断面获取

由于全景采样数据存储的是点在最近某一时刻的瞬时值,是与时间有关的数据。 每一个数据记录上都有一个时间戳,记录实时数据变化的采样时间。 一条采样数据记录包括点标签、时间戳、状态、数值4 个组成部分。 为了方便采样点查询,全景采样数据库采用了HASH 表的索引方式进行点查询,并设计了缓存机制,可以快速高效地查找到指定点信息,支持数据断面获取。 即用户想要获得某一时刻的TIDS 系统的数据断面,可以通过获取所有采样数据点在该时刻或该时刻之前最近的一个时刻的变化采样值,快速构建成为数据断面。

2.4 事故录制与反演

全景化事故反演回放系统包括事故录制和事故反演两个过程。

事故录制过程比较简单,即用户指定了某个时间段(如A 时刻至B 时刻)的事故录制任务,后台回放服务接收到命令后从全景采样数据库中获取A 时刻数据断面,获取A 时刻到B 时刻所有数据点的变化采样值和时间戳,以及获取A 时刻到B 时刻历史数据库所有的历史事件,以文件方式录制保存,如图1 所示。 用户可选择任意时间段进行事故录制,生成不同的录制文件。

图1 录制操作

在事故反演过程中,用户通过人机界面可以看到之前所有录制的文件记录,当用户选择某个录制文件下达反演回放命令后,人机界面首先切换至“回放态”,后台回放服务从录制文件中读取数据断面、数据变化记录、历史事件记录,先发送数据断面,然后按照时间戳间隔和指定的播放速度发送变化报文、报警信息、事件信息给人机界面HMI、报警窗和事件窗,仿真真实的数据变化过程,实现全景化事故反演,如图2 所示。

图2 回放操作

3 全景化事故反演回放系统的具体实现

全景化事故反演回放系统由事故录制、事故反演操作人机界面和后台回放服务replay＿server 组成,回放服务承载了主要的事故录制与反演功能。 由于系统要求操作人员能够任意控制回放过程,随时启动、暂停、倍速观看回放过程,使回放服务面临很多的人机交互,设计更为灵活,回放服务的功能设计如下［4-7］。

3.1 回放服务设计

回放服务replay＿server 包含回放主线程和事故录制子线程、录制文件管理子线程和心跳子线程,实现功能分别如下。

(1)事故录制子线程:与事故录制界面的交互,实现事故录制过程。

(2)录制文件管理子线程:与录制文件管理界面的交互,处理录制文件的显示、删除。

(3)心跳子线程:维护回放管理的回放进度。

(4)回放主线程:与回放管理界面的交互,处理事故反演过程。

3.2 事故录制与录制文件管理实现

事故录制与录制文件管理界面如图3 所示。

图3 录制操作界面

用户打开【数据管理】TAB 页,向后台回放服务录制文件管理子线程请求并获取录制文件列表,可以手动删除任意录制文件。 用户在该界面点击【新建】按钮,选择【新建名称】【开始时间】与【结束时间】,向后台回放服务事故录制子线程发送了录制命令,录制子线程向全景采样数据库和历史数据库获取该时间段内的数据断面、采样数据和历史事件,完成后生成新命名的录制文件,显示在录制文件列表中。

3.3 事故反演实现

事故反演操作界面如图4 所示。

图4 回放操作界面

用户打开【回放管理】TAB 页,向后台回放服务录制文件管理子线程请求并获取录制文件列表,可以选择任意录制文件进行事故反演,点击【开始】按钮,即向后台回放服务回放主线程发送了回放命令,后台回放服务从录制文件中读取数据断面、数据变化记录、历史事件记录,先发送数据断面,然后按照时间戳间隔和指定的播放速度发送回放变化报文、报警信息、事件信息给人机界面。 人机界面切至“回放态”接收所有的回放数据,回放数据包括系统已记录的轨道、道岔、信号机等信号设备的状态信息、列车位置信息、中央调度员执行的各种操作命令和各种报警信息,回放流程如图5所示。

图5 回放流程

后台回放服务的心跳子线程向回放管理界面持续发送心跳报文,用于显示回放进度。 用户可以随时暂停回放,以及修改倍速加速回放或减慢回放,后台回放服务随时响应界面操作,直到回放结束［8］。

4 结语

本文介绍了一种在城市轨道交通综合指挥调度系统(TIDS)中进行全景化事故反演的实现方式,针对该系统对事故反演的要求,介绍了一种基于Bekeley DB的全景采样数据库,将TIDS 系统的各监控专业变化数据都存储在全景采样数据库中,该全景采样数据库支持基于时间戳的数据存储,高效的数据查询、数据断面获取以及“回放态”的概念和切换过程,并据此设计完善的事故录制与事故反演实现方案。 本方案能够让用户在正常监控过程中随时切换至回放状态,查看以前任意时间断面的列车运行情况,设备工作状态以及调度员的所有操作、历史事件,方便操作员反演事故过程,且回放过程中对回放的各种操作对正在运营的线路和TIDS 的各种既有功能不产生任何影响。 目前,该设计方案已经安全稳定的运行在苏州有轨电车2 号线综合指挥调度系统中。