赵 刚 林炳跃 崔莹莹 王 飞

目前，国内动车段、动车运用所调车计划的编制，主要利用Excel表格工具完成，并通过传真与各检修车间以及运输部门交互。这种计划编制方式工作效率低、信息不能共享、计划变更流程繁琐。随着全国高铁线路的不断建设，动车组开行数量不断增加，上述缺点越发突出，寻求行车指挥计划的信息化、智能化方案，辅助目前的检修作业和调车作业的计划编制非常必要。

动车段 （所）调车计划辅助编制系统 （以下简称系统），使用信息化方式存储和共享计划数据，调度人员使用定制的计划软件，编制和录入计划数据。数据通过以太网传输到服务器，持久化存储为某一版本的文件。通过服务器，其他终端可获取这一版本的数据，并可对其进行修改和再次提交。为了满足用户现有的使用习惯，兼容现有作业流程，系统软件针对不同段 （所）的特点进行定制化设计，可提供计划冲突判断、股道运用提示等智能辅助功能，并以现有Excel格式打印。

1 系统结构

系统由前台终端和后台服务器设备构成，主要包括：计划编制终端、计划接收终端、消息服务器、应用服务器和网络设备等。系统结构设计如图1所示。

计划编制终端具有获取计划、编制计划和提交计划3种权限。计划接收终端只具备获取计划功能。消息服务器作为数据转发的核心节点，管理所有计划软件连接，并处理计划软件的相关数据请求。应用服务器是计划数据的业务核心节点，提供计划数据的解析、版本管理、数据持久化等。作业图表软件将计划以计划线的形式展现，如果配合上接发车计划数据，可以形成完整的动车组移动轨迹。

图1 系统结构图

2 系统软件设计

2.1 计划编制软件设计

计划编制软件是前台，提供计划编制、计划发布、保存模板、导出Excel以及股道占用时间和冲突提示等功能。主要采用表格控件实现计划数据展示功能，通过自定义的编辑区域，对数据进行编辑和修改，同时通过图形方式提示股道运用冲突。软件界面示意如图2所示。

图2 计划编制软件界面

不同动车段 （所）在计划编制流程和使用习惯上存在差异，软件设计既要支持界面布局和数据修改项的灵活变换，又要兼容到统一的后台计划数据结构中。因此，软件要有很高的适应性，这样才能在大规模的部署应用中，既使用户感受到定制化开发带来的良好用户体验，又降低了多分支开发的复杂度和维护难度。

2.2 消息服务器设计

消息服务器主要采用TCP消息协议来完成数据转发的功能。消息服务器只负责业务数据转发，不对传输的数据进行分析和修改，其功能示意图如图3所示。

图3 消息服务器功能示意图

消息服务器处于星状拓扑接口的中心位置，对多条链接有集中控制的功能，包括链接状态信息的显示和不同业务数据转发控制的功能。为了提高数据转发效率，采用了环形接收缓冲和异步数据发送技术。

2.3 应用服务器设计

应用服务器主要完成数据的版本管理和终端数据版本同步。当数据从消息服务器传输过来，应用服务器将数据解析，组装成数据对象，并在其中增加版本信息，之后将数据对象序列化成二进制文件，保存在本地磁盘中待用，应用服务器功能示意如图4所示。

版本的定义方式是采用本机时间加数据班次信息。应用服务器会从终端的心跳信息中判断是否要将数据推送给某个终端。当心跳中带有的数据信息版本低于应用服务器当前的数据版本，应用服务器会主动将最新的计划数据发送给该终端。

图4 应用服务器功能示意图

2.4 计划数据的持久化问题

计划数据作为系统的核心数据需要持久化存储。一般的持久化存储方案是采用数据库，但本系统如采用数据库存储，会遇到数据表格式和数据访问层接口的维护问题。因为当系统部署到不同动车段 （所），各个软件版本不尽相同，使用数据库存储计划数据时，不同版本软件的数据库表结构将会存在差异，从而导致数据访问层代码也会有不同版本，这在一定程度上增加了开发和维护成本。

为了回避以上问题，系统采用二进制序列化的持久化数据存储方式。二进制序列化是.Net平台下稳定的、抽象层次更高的、与对象结构无关的通用方法。采用该方式可以不用编写大量的数据访问层代码，并且当计划数据对象变更时，不用改变任何持久化逻辑代码。当然该方式有存储的数据文件无法直接阅读、文件的检索效率不如数据库高的缺点，但对系统应用影响不大。

2.5 计划数据的版本管理

每个班次制定本班次时间内的调车计划，计划数据需要根据调度班次划分版本。随着作业计划不断执行，当发生检修超时或者临时变更检修计划等情况，以及其他不可控因素，都会使最终的实际调车作业偏离计划预期，一般这种偏离被控制在本班次可以控制的范围内。当班次更换时，上一个班次的计划就过期了。新班次的计划是将最新的变化因素考虑进去并制定之后的计划，这样本来应该是连续不间断的调车计划，将被分解为按班次划分的白班和夜班计划。而当同一个班次内的计划也需要重新编排时，班次内的计划也将形成新的版本。不断更新的计划版本，给计划系统带来多版本计划融合的难题。

解决方案是由系统的应用服务器产生计划版本号，所有的新计划都是通过应用服务器打上版本号后才能被发布。版本号由时间戳和班次类型2个关键词构成，同时也是计划数据序列化为二进制文件的文件名。系统维持最新的一套计划数据在各个终端同步和传输。当计划预期与实际执行结果的偏差在可控范围内时，只需在执行时对当前计划稍作调整，等待下一个班次计划纠正之前的偏差即可。当计划接收终端需要对新的计划和现有计划进行融合时，软件提供了计划数据字段比对提示功能，由用户手动融合相同车组的不同调车数据，简化了人工比对的工作量，并且保证不会造成数据错误和数据冗余。

3 总结

该系统已经成功应用在北京、武汉和广州动车段。从实际应用情况看，基本满足了设计的要求，提供了友好的用户交互界面，并且可以实现界面功能定制开发。以TCP协议为基础的数据传输结构稳定而高效，计划数据结构扩展性强，基于版本控制的计划管理和序列化数据存储设计，降低了开发和维护成本。随着动车段 （所）检修业务量的不断增长，业务流程的不断优化，该系统在多终端分布式结构扩展、数据并发修改、多数据版本智能融合等方面还要继续研发和改进。

［1］ 苏庆，李忠良，吴伟民.在C＃.NET下实现数据导入Excel的方法研究［J］.计算机与现代化，2011（4）.

［2］ 飞颉经纬.基于C＃的自动生成 Word文档的开发［J］.科技创新导报，2010（3）.

［3］ 黎浩东.铁路编组站阶段计划编制研究综述［J］.铁道学报，2011（8）：15.

［4］ 蒋继磊，杨志杰.动车组运用计划编制及其优化［J］.铁道运输与经济，2010（4）.

［5］ 丁昆，崔磊.铁路调车计划图形编制法［J］.铁道货运，2006（6）：10.

［6］ 王雅琳，周颖，雷友诚，等.基于 MVC的调车作业计划辅助编制系统［J］.计算机工程，2010（11）：05.

［7］ 史建中，周通.编组站综合自动化系统的信息共享平台建设［J］.铁道通信信号，2011（3）：65－67.

［8］ 宋鹏飞，魏博.动车段编组系统于CTC接口的实现［J］.铁道通信信号，2011（6）：17－20.

［9］ 王俊.动车段调车防护系统设计方案［J］.铁道通信信号，2012（8）：13－14.