基于TDCS/CTC生产系统的车站数据查询方案研究

曹亚辉，王亚飞

（卡斯柯信号有限公司，上海 200071）

1 概述

随着TDCS/CTC 系统在全路的大规模使用，车站用户从实际工作需要出发，提出越来越多对行车日志、速报、站存车、报警、调度命令及事件数据的查询需求。现有的车站终端程序满足了生产需求，但无法满足查询需求，为应对车站用户的需求，考虑利用现有的系统架构，在不影响在用系统功能的前提下，设计一套实用的车站数据查询系统。

目前路局在用的TDCS/CTC 生产系统整体架构如图1 所示。

从图1 中可以看到，目前TDCS/CTC 系统分为中心和车站两大部分，各服务器及车站终端间通过网络相连，车站系统连接通信前置机服务器，通过通信前置机与中心系统进行数据交互，车站现在只有LiRC 和车务终端软件，没有数据查询终端，而且生产数据都存储在中心数据库服务器中。所以要满足车站查询生产数据的需求，又不影响现有软件架构和功能，就要解决3 个问题：数据源的问题；查询端的问题；查询端与数据源交互的问题。

图1 TDCS/CTC生产系统结构示意图Fig.1 Basic structure diagram of TDCS/CTC production system

2 方案选择

对于数据源的问题，必须要实现生产数据的存储；对于查询端的问题，必须要不影响现有LiRC和车务终端软件的正常使用，而且方便车站用户使用；查询端与数据源交互的问题，必须要不影响现有软件架构，即不经过通信前置机服务器进行数据交互。

基于以上分析，车站查询数据需求可以通过以下两种方案实现。

1）在车站部署数据源，实现生产数据存储，开发数据查询端软件，部署在车站，开发后台服务，访问数据源，响应查询端的请求，通过网络连接实现查询端与数据源的直接交互。

2）利用中心系统数据库服务器作为数据源，开发数据查询端软件，部署在车站，开发后台服务，访问数据源，响应查询端的请求，通过网络连接实现查询端与数据源的直接交互。

两种方案的核心区别是，是否利用既有中心数据源。

对于车站部署数据源的方案，存在以下缺点：部署成本高，每个车站都要单独部署数据源；要求车站人员对数据源有较高的维护水平；需要修改软件实现生产数据的入库，而且不便于功能扩展。

结合TDCS/CTC 生产系统的实际情况，用户要求车站生产数据查询方案要部署灵活，使用方便，维护简单，且不影响现有系统架构及功能，这都是车站部署数据源方案实现不了的，因此只能采用利用现有数据库服务器作为数据源的方案。

利用现有数据库服务器作为数据源的方案，具有以下优点。

1）部署成本低

本方案使用现有的数据库服务器作为数据源，不用考虑新增数据源，而且现有数据库中已经包含所有需要的生产数据，不用考虑修改软件实现生产数据的入库问题，降低了方案的复杂性，使得部署成本非常低廉。

2）对维护人员要求低

本方案的数据库服务器位于中心机房，所有车站可以共用，不会增加中心和车站维护工作量，且方案执行过程易于理解，维护简单。

3）部署灵活

本方案只用开发数据查询端软件，部署在车站，开发后台服务，访问数据源，响应查询端的请求。车站查询终端增加，只用多部署查询端软件即可。车站需求增加，只用修改新增的查询端软件和后台服务即可，不需要修改现有软件架构和功能，部署灵活性比较高。

3 设计与实现

3.1 方案设计

基于成本和灵活性的考虑，本文选择利用现有TDCS/CTC 系统数据库服务器作为数据源，实现车站用户的生产数据查询需求，整体方案架构如图2所示。

图2 增加查询功能后TDCS/CTC生产系统结构示意图Fig.2 Basic structure diagram of TDCS/CTC production system after adding query function

对比图1、2 的系统架构，增加数据查询功能后，增加响应查询的后台服务软件，可以新加设备，也可以部署在现有应用服务器中。在车站设备中增加查询端软件，并未改变现有软件架构及功能。这样不仅实现车站用户查询行车日志、速报、站存车、报警、调度命令及事件数据的需求。即使日后车站用户需要查询更多的信息，包括以后生产系统扩展新业务的信息，都可以通过该方式简单修改后台服务软件和查询端软件实现。

考虑到车站用户查询需求差异性，查询端提供的查询功能可以通过配置文件灵活配置。

3.2 实现过程

方案的实现过程如图3 所示。

图3 实现过程图Fig.3 Realization process diagram

其中，车站查询端，根据用户在界面中输入的查询条件，生成查询请求，然后同后台服务建立Web Service 通信，向后台服务发送查询请求，后台服务收到查询请求，根据查询条件从数据库中获取相应数据，再发送给查询端，查询端接收到数据，在界面中进行展示。整个过程由查询端发起，顺序进行。

方案的实现难点包括以下几点。

1）配置灵活简易性的保证

车站用户查询需求多样，因此方案通过灵活配置满足车站用户的个性需求，另外从维护角度考虑，车站配置要尽可能少，因此方案通过将公用配置放置于后台服务端的方式，车站查询端启动时，从后台服务获取公用配置，减轻了车站查询端配置工作量。而且后台服务收到查询端的请求，才会读取公用配置，即使公用配置有变化，可以直接修改，不用重启后台服务，减轻了对正常使用的影响。

2）查询反馈时效性的保证

车站查询端发起查询请求后，如果网络条件不好，或者查询结果比较多，接收很慢，如果不做考虑，会造成界面卡顿，影响使用效果。因此方案通过设置超时参数的方式，卡控反馈的时效性，对于超时未收到查询结果的情况，会提醒用户重新发起请求。

3）查询结果传输准确性的保证

车站查询端发起查询请求后，如果协议设计不好，在网络通信质量不好，或者查询结果较多的情况下，可能会导致查询结果在传输过程中部分丢掉或异常。因此方案在设计通信协议时，通过将所有查询结果放入一条消息中，且在查询结果消息头上包含结果条数的方式，在查询端进行结果校验，对于不完整的消息直接丢弃，避免传输过程中数据异常造成的结果不准确。

4）通信连接质量的保证

由于TDCS/CTC 系统现在普遍采用双网，因此查询端发送Web Service 连接时，如果一路网络有问题，要能够切换使用另一路网络。否则会导致无法完成连接。方案在设计时，考虑了这种情况，查询端程序可以配置双网，在网络通信不好的情况下，可以自动切换网络，保证功能的正常使用。

3.3 关键技术

1）Web Service 通信技术

为了不影响在用软件的功能及架构，且实现功能独立，因此不能采用现有的连接结构，即连接通信前置机，通过通信前置机与中心后台服务通信，必须采用另一种简单独立的技术，经过查阅相关资料，并结合易用性、可维护性的需求，本方案选择Web Service 通信技术，后台服务只用开放Web Service 查询服务，车站查询终端可直接通过后台服务的ip 和端口与之进行数据交互。使用Web Service 技术，车站查询端与后台服务不需要维持常连接，发送查询请求时，才会建立连接，这样大大减轻对现有网络通信的影响，且数据交互采用XML 格式，扩展简单，使用灵活，保证了方案的可行性。

2）Oracle 数据库技术

由于TDCS/CTC 系统采用Oracle 数据库，因此在后台服务中采用Oracle API 直接方位数据库并获取数据。Oracle 自带的API 使用广泛，查询速度快，简单且可靠性高的优点，保证方案的可行性。

3）QT 界面开发技术

由于车站查询端程序要跟用户进行交互，因此需要设计友好的人机界面，车务终端原有MFC 界面不够友好美观，且技术陈旧。在查阅资料的基础上，方案选择QT 界面开发技术，利用QT 界面美观友好，且开发简单，易于维护的特点，满足车站用户的需求，提高方案的可用性。

4）多用户并发访问技术

为响应多用户同时查询，后台服务采用并发访问技术，当查询端发起查询时，动态的为每个查询端单独分配一个通信线程，处理查询请求，查询结束，释放资源。可根据硬件资源配置后台服务能分配的最大通信线程数。

4 总结

本文设计方案易于实现且简单灵活，在既有硬件条件及软件架构和功能不变的前提下，开发后台服务和车站查询端程序，实现车站用户对生产数据的查询需求，降低了接管单位运营成本和运维复杂性，提高了方案的可用性和易用性。

目前该数据查询方案已在多个铁路集团公司TDCS/CTC 生产系统中运用实现，包括广铁集团有限公司（车站查询行车日志、调度命令和报警数据），济南局集团有限公司（车站查询调度命令和报警数据）等，至今运行稳定可靠，实现方案的设计目标，满足了车站用户对查询生产数据的需求，提高了系统的可用性，同时对其他系统中的类似需求也有一定的参考价值。