TDCS/CTC综合管理系统总体方案研究

张辉东

作为基本覆盖全路的行车调度指挥系统，TDCS/CTC系统已经成为运输指挥中必不可少的行车设备。随着数量的增多和功能的日渐丰富，日常的维护工作量越发繁杂。目前铁路局在用的TDCS/CTC维护系统，仅限于监测和维护操作系统状态信息和网络状态信息，还没有一个专门针对部署在不同物理位置上的TDCS/CTC设备、网络状态、软件业务状态，以及相关故障报警统计管理的综合性监控维护系统，维护人员难以在第一时间获取这些设备的运行状态信息。为此，由太原铁路局电务处和卡斯柯信号有限公司联合研制了一套TDCS/CTC设备综合监控维护系统。

TDCS/CTC综合管理系统 (以下简称 CMS)是从现有TDCS/CTC系统结构、设备配置、网络架构和业务软件应用等层面，集设备监控、网络监控和应用程序状态监控于一体，而且还能对记录的相关报警、故障等情况进行分类统计，实现TDCS/CTC系统全面的、立体化的综合监控。

1 系统设计原则

CMS系统既可以监控部署在TDCS/CTC系统中的所有PC服务器、UNIX/Linux小型机服务器、图形工作站等计算机设备;也可以监控部署在站段的车站分机/自律机、车务终端 (信号员终端、电务维护终端)等设备。它将被监控对象的静态信息 (包括IP地址、设备型号、操作系统版本等)、动态信息 (包括CPU、内存、磁盘动态使用情况以及操作系统进程列表，并可以性能曲线的方式呈现)、网络状态 (包括端口速率、端口的连通情况、端口是否存在收发错误)、TDCS/CTC系统软件业务状态 (包括各业务系统/进程程序的版本信息、运行状态、相互之间的通信连接状态)等进行数据搜集，当设备性能出现异常时，能够向指定的管理维护终端发送报警提示。

从系统的监控对象和用户群体角度出发，系统设计遵循以下原则。

1.与TDCS/CTC系统的高效兼容性。CMS系统既要从 TDCS/CTC软件获取数据，也要向TDCS/CTC软件发送数据，其数据包格式应遵守TDCS/CTC原有协议格式，这样可以避免因增加监控系统接口而对原有软件结构造成较大改变，增加开发工作量;同时也避免TDCS/CTC系统向CMS系统发送大量状态数据而消耗较大资源，保证有足够的计算资源处理核心业务。

2.通信的实时性。CMS系统要实现对TDCS/CTC软件状态及时、有效的监控，必须从TDCS/CTC系统快速获得大量实时数据，这是CMS系统进行计算和异常判断的基础，因此必须保证CMS系统获得数据的实时性。

3.报警的有效性。收到TDCS/CTC软件发来的数据后，CMS系统需要将接收到的状态信息进行筛选、过滤后展示给用户，同时还必须判断出监控对象的异常，向用户推送报警信息。报警阈值设置要准确，在数据收发任务和报警计算任务之间合理分配计算资源，实现报警的及时性和有效性。

4.数据的持久性。CMS系统接收到的属性状态数据和由CMS系统计算的报警信息需要持久保存，以便数据备份和事后查询。CMS系统提供了一种数据持久化的手段，将数据存储在数据库中，并提供查询手段。

5.界面的友好性。CMS系统以图形、文字、声音3种方式向用户展示监控对象的状态信息，同时接受用户对监控对象的主动查询任务，响应用户特殊查询需求。

6.系统的可扩展性。支持用户灵活增加和减少监控对象。提供一种监控对象动态配置手段，用户随时可改变其监控对象，并以重启程序的方式使其修改生效。

7.系统健壮性。系统具有较强的容错能力。在发生错误时，能够较友好的提示错误信息，即使遇到不可排除的错误，也要保证系统能够及时重新启动。

8.数据安全性。CMS系统保证只有合法且授权的用户才能使用系统。

9.可维护性。对于系统的错误或者异常，能够记录错误，方便追踪系统故障，保证可维护性，对于关键信息写入文件，要做到所有信息事后可查。

2 系统结构方案

2.1 系统硬件结构

CMS系统是由监控系统服务器 (CMSS)、数据库系统服务器 (DB)、监控系统终端 (CMSC)和数据配置工具 (CMST)组成。如图所示，一般设置监控系统服务器1套，数据库服务器1套，客户端可以根据需要设置多套，配置工具1套，也可以不单独设置配置工具终端，将它和客户端安装在同台设备上。

图1 CMS系统硬件结构图

2.2 系统软件结构

CMS由8个软件模块和1个数据库组成，系统总体的软件结构图如图2所示。

图2 CMS系统软件结构图

1.CMSS负责完成对目标设备的状态轮询和状态处理，对状态报警信息进行逻辑判断，对状态信息和报警信息进行存储，将属性信息和报警信息推送客户端等。CMSS还为CMSC提供查询代理服务。

2.CMSC是用户接口程序，将CMSS发送来的状态信息以图形化方式展示给用户。CMSC提供基础配置数据和历史状态信息的查询手段，可将CMSS作为查询代理向TDCS/CTC软件获取状态信息。

3.CMST仅与数据库接口，用于维护数据库中的基础配置数据和监控图绘制。

4.数据库保存目标设备信息、目标设备状态信息和系统配置信息等。

3 系统设计

3.1 系统总体设计

CMSS通过2种方式从目标设备获取设备状态信息:①使用定时逻辑向目标设备发送轮询消息，目标设备响应后，反馈设备属性状态消息;②定期向目标设备发送登记消息，向目标设备注册CMSS通信IP和端口，当目标设备检测到自身设备状态变化时，主动向已注册的CMSS发送属性变化消息。

CMSC直接与用户接口，提供2种信息表示方式:①监控图界面。可根据不同用户的需求，绘制不同的监控图，显示目标设备的主备状态和通信连接状态，并且在监控目标设备发生状态异常时，在相应的设备图标上有明显的声光报警提示。监控图中设备状态的更新方式为CMSC定期向CMSS发注册消息 (注册消息中包括监控图中所有设备和连接属性)，CMSS根据注册列表主动将设备状态推送给CMSC。②设备详细状态列表。在设备报警时，或用户想了解设备的详细状态时，可针对某一个设备打开详细状态列表，显示某一个设备的所有监控属性，设备状态的更新由用户的刷新操作驱动。用户执行刷新操作后，CMSC向CMSS发送探测请求，CMSS由独立线程对目标设备进行探测，得到结果后反馈给CMSC。

3.2 系统接口设计

1.用户接口。CMSC和CMST提供图形界面用户接口。

2.外部接口。即 CMS的维护系统与既有TDCS/CTC各软件之间的接口。接口通信采用UDP协议。

CMSS根据预先设置的轮询间隔，定时向TDCS/CTC发送属性查询消息，消息中包含查询ID、设备实体号、AB机标识、属性类型、属性索引、属性值等信息。当TDCS/CTC子系统收到属性查询消息后，会立即向CMSS系统返回所请求的属性应答消息。

3.内部接口。CMSS向CMSC发送通用单属性应答消息、通用组属性应答消息及动态队列属性应答消息等，并且CMSS收到CTC子系统发送的报警消息，或检查到监控属性状态异常时，主动向已注册的CMSC推送报警消息，CMSS收到此消息后，在用户界面上以声光报警的形式进行提示。

3.3 系统数据结构设计

CMS系统的数据结构组成部分如图3所示。各部分的主要职责分别为:①设备属性列表DEV_ATTR_LIST，记录所有目标设备，及其监控属性的静态信息和当前状态信息;②客户端注册列表CMSC_REG_LIST，记录客户端的监控注册信息，用于记录每个CMST软件向CMSS发来的注册信息;③客户端探测列表DETECT_LIST，记录CMSC发起的探测请求;④监控图列表MONITOR_GRAPH_LIST，维护监控图对象 MONITOR_GRAPH的链表。

图3 CMS系统数据结构图

3.4 系统存储设计

1.目标设备信息，包括目标设备实体号、名称、IP地址、监控UDP端口号等，存储在设备表中。

2.监控属性信息分2张表存储，一张表存储主属性，另一张表存储子属性。主属性包括设备，属性名称、属性类型。子属性表存储属性索引。一个设备的某一类型属性可能有多个子属性。

3.属性的状态存储在属性状态表中。

4.报警记录信息，记录各目标设备主动发送的报警，以及系统自动判断出的异常报警。

5.用户信息，包括系统的用户登录名与密码。

6.监控图及与该监控图有关联的所有图元均存储在数据库中，图元类型包括设备、端口、连线、文字、图片等，用单个图元的记录关联监控图主键的方式表示所属关系。

CMST向数据库中写入基础设备配置数据、监控图信息和用户信息。

CMSS从数据库中读取基础配置数据，同时CMSS向数据库中写入状态数据和报警数据。

4 关键技术方案

4.1 TDCS/CTC系统安全接口

TDCS/CTC作为列车调度指挥系统，实现了铁路各级运输调度对列车运行的透明指挥、实时调整、集中监控，因此，它关系到列车安全运行，必须保证其独立性和安全性，避免其他系统对其影响。TDCS/CTC安全接口实现了从TDCS/CTC获取数据，综合维护系统从TDCS/CTC系统获取数据采用独立的UDP协议，不影响TDCS/CTC系统的原有功能。

要保证TDCS/CTC安全接口达到预定的网络安全目标，TDCS/CTC安全接口技术需满足以下条件。

1.有限数据集合。TDCS/CTC安全接口输出的所有数据必须是确定的、有限的。为了防止TDCS/CTC系统的保密或者非公开数据的流出，影响列车的安全运行，TDCS/CTC安全接口对发出的数据和数据帧做出了严格的限定，只有属于有限数据集合的数据才能发送到外部系统。

2.特定数据传输。TDCS/CTC安全接口与外部系统采用严格的单向传输协议，防止外部信息对TDCS/CTC调度指挥系统的可能干扰。数据的传输方向严格限定为特定消息交互。

4.2 基于多Agent的监测方案

多Agent系统是一个能够感知外界环境，并具有自主行为能力的，以实现其设计目标的自治系统。在多Agent系统中，每一个Agent都具有自治性，其内部数据分为private级别和public级别，外部系统只能获取public类型的信息，不能访问private类型的信息，其内部状态不受外界访问的影响。每个Agent都具有主动性，可以将其内部状态的变化主动向外推送。Agent之间可以相互通信，实现信息汇总计算。多Agent系统是一个交互式系统，多个分散控制的Agent组成一个整体系统。

CMS系统和TDCS/CTC系统组成一个多Agent系统。每个TDCS/CTC软件能感知其内部运行状态的变化，主动的将其内部状态发送给CMSS。每个TDCS/CTC软件是一个独立的计算体，其内部状态不受CMSS的影响。CMSS自身具备属性状态计算功能，将计算结果主动提供给用户。CMSS和其监测对象组成的多Agent系统实现对监测目标状态的监控。

5 结束语

TDCS/CTC维护管理系统于2014年8月6日通过太原铁路局科委组织的技术评审 (太铁局技审字〔2014〕第20号)，并在大西高铁太原南至永济北间13个车站进行了试验、测试和试运行。通过现场的实施运行，更好地提高了TDCS/CTC系统的完整性，加强了TDCS/CTC系统的可维护性，极大地提高了维护人员的工作效率。伴随着TDCS/CTC系统在全路的广泛应用，CMS系统也一定拥有非常广阔的前景和推广空间。

［1］ 中华人民共和国铁道部.科技运函［2004］15号.分散自律调度集中系统技术条件［S］.2004.

［2］ 崔贵志.关于TDCS系统维护管理问题的探讨.铁道通信信号［J］.2006，42(9)，23-24.

［3］ 中华人民共和国铁道部，运基信号［2009］676号.列车调度指挥系统(TDCS)、调度集中系统(CTC)组网方案和硬件配置标准(暂行)［S］.2009.