铁路工务检测数据管理信息化研究及应用

邵轶琦 秦宪国

（1.北京交通大学轨道交通控制与安全国家重点实验室 北京100044；2.中国神华神朔铁路分公司河西运输段 陕西 榆林719316）

1 工务检测数据内容

1.1 数据分类

工务设备检测是利用一定工具和仪器对工务设备状态参数进行量测的活动，此过程产生的数据即为工务设备检测数据，包括线路检测数据和桥隧建筑物检测数据2大类。其中，线路检测数据又分为静态检测数据、动态检测数据、钢轨检查和春秋检数据。静态检测是利用手工检测工具沿线路逐点进行或用静态仪器进行检测；动态检测则是在给轨道产生动态荷载的情况下对轨道进行的检测，为简便，钢轨检查中的小型探伤仪检测划分为静态检测，探伤车检测划分为动态检测。桥隧建筑物检测主要分为经常检查、定期检查、水文观测、临时检查和专项检查等。

1.2 数据来源

目前我国工务生产实际工作中，各种检测方式得到的数据大致有2种格式：①检测仪器通过本身自带的计算机分析系统得到的电子数据，通过编写特定的数据入库程序导入数据库中；②人工检测过程中的数据，手动记录至纸质文件中。工务检查方式多以静态检测为主，因此形成的数据格式也多为纸质格式，见表1。

表1 工务检测数据来源Tab.1 Data sources of inspections

2 数据标准化与整合分析

2.1 数据编码标准

铁路工务设备及其检测数据种类繁多，目前尚未对其进行统一编码，有些编码虽然已经制定，但编码不具有惟一性，容易对日常生产管理产生不利影响。本文遵循科学的编码原则，结合现场设备编号和检查习惯制定一套“专业代码＋分类代码＋序列码”为主体的顺序层次编码方案，对检测数据管理相关的数据进行统一分类、编码与标识，从而达到整合、共享现有资源的目标。表2展示的是划分到第2个层次后的编码示例。

表2 数据分类编码示例Tab.2 Subclass code for data

用这样的编码方式，结合考虑相应的业务特点，把每一大类逐步往下细分，最后每一种原始入库数据在综合数据平台中拥有惟一编码。

2.2 检测数据维度的确定

铁路线路呈空间线性分布，线路上的每一个设备的位置都是通过里程来确定的。根据这个特点，工务检测数据主要包括3个维度：时间维、地理维、设备维，各维度的内容见图1。

图1 工务检测数据维度Fig.1 Data dimension of railway maintenance inspections

因此工务检测数据构成了如图2所示的多维数据立方体，对工务检测数据的业务整合，可以从时间维度、地理维度、设备类型维度对数据进行不同角度的整合。

图2 工务检测数据维度多维立方体Fig.2 Inspection data multidimensional cube

2.3 检测数据整合方法

2.3.1 检测数据切片

例（1）中买方加入模糊限制语a little bit想还价，但又不敢肯定卖方能否接受议价。此外，买方也不完全确定这个产品当下最低的市场价格时，使用模糊限制语，可以使得还价的话说得更得体一些，与实际情况更符合一些，从而避免说话武断，使话语更准确、更客观，更能被卖方所接受。

切片分析是指在多维数组中的某一维上选定一维成员的动作。对于图2所示的多维数据立方体，选定时间维上某一维成员的具体取值（如“20121206”）时，多维立方体转变为二维数据，此时可以获得在这个日期的所有空间范围（工务段、领工区、工区）内任何检查方式、检查设备的检测值，得到当日检测超限数据情况。

2.3.2 检测数据切块

切块分析是指在多维数据的某一维上选定某一区间的维成员的动作。切片分析是从多维立方体的某一方面对数据进行整合，切块分析则是从多个维度、同一维度的值区间的角度对数据进行整合，从而将立方体转化为较小的立方体。利用这种整合分析方法，在分析数据时考虑了更多的因素，能够更准确地把握数据的信息。

2.3.3 检测数据钻取

钻取分析是通过改变统计数据的维度层次来实现由统计数据到细节数据的过渡，它是聚合分析的逆操作。以人工道岔检查为例，通过向下钻取某工务段人工道岔检测的超限统计数目，可以获取该段管内的所有领工区的超限分布情况，再向下钻取某一领工区超限统计数目，可以获取所有工区的超限分布情况，最终可以获取超限点都分布在哪些车站的道岔测点上。通过这种钻取方式，可以使数据显示更简洁，按不同的需求将大量数据以不同的形式展现出来，既能整体把握数据的情况，又能方便、快捷地查看细节数据。

3 应用实例

笔者在铁路工务检测数据管理需求分析和数据整合分析的基础上，采用Java技术以及Oracle 11g数据库，以神朔铁路工务生产数据为对象进行了应用实践，构建了工务检测数据管理信息系统，实现了工务检测数据的数字化管理。

3.1 系统总体设计

系统采用B／S结构及3层网络架构，即用户表示层、业务逻辑层和数据服务层，见图3。用户服务层主要是对信息的表示，业务逻辑层与用户表示层、数据服务层分离，被所有客户机所共享，在部署阶段将采用Weblogic应用服务器。

在此3层结构系统中，中间层（应用服务器）是整个系统的核心。用户服务布置在客户端，主要是利用网页浏览器。应用服务根据业务逻辑被划分为不同的组件并且被封装。在使客户机请求某种应用服务时，只与应用服务器上对应的被封装的应用组件通信。

图3 系统总体结构Fig.3 Design of overall system structure

3.2 数据库设计

在关系型数据库中，由于星型模型可以为本系统的功能处理优化数据，通过数据预连接和建立有选择的冗余，为访问和分析过程缩短了数据库的查询响应时间，提高查询性能。系统数据库采用星型模型进行设计，见图4。在星型结构的中央是事实表，事实表可以被看作是由2部分组成，一部分是用于和维表连接的外键，另一部分是包含了有关数据的数值测量值。事实表是数据的主体，维表处于事实表的周围，提供维的相关信息，如专业数据、作业项目数据等等，其数据量一般较小。事实表和维表之间是以关系来连接的。

图4 数据库星型结构模型Fig.4 Star schema of database

在逻辑结构设计的基础上，把每种检查方式作为一个主题，将各个相关数据表通过主键和外键关联起来，图5以动态检查方式中的添乘仪检查为例，进行数据库表间关系的设计。

图5 添乘仪检查数据库表间关系Fig.5 Links of tables for portable inspection devices

3.3 系统主要功能

3.3.1 超限统计

该模块将各种检查方式产生的数据进行切块和钻取的处理，以单位和线别为维度，对每次检查或任意时间段内的每个超限等级的超限个数和单位公里超限个数进行统计。在统计结果的基础上，该功能还对统计出的超限在直属管辖单位或线路区间（股道）上的分布情况进行分析。另外，该功能还提供了以上统计结果表和分析结果表中每一个超限问题的详细清单。

3.3.2 超限重复点

该模块根据检测数据，以单位和线别为维度，对相邻2次检查的重复超限（例如从II变化到II，从II变化到III，从III变化到II和从III变化到III）的个数进行统计。在统计结果的基础上，该功能还对统计出的重复超限在直属管辖单位或线路区间上的分布情况进行分析。另外，该功能还提供了以上统计结果表和分析结果表中每一处重复超限问题的详细清单。

重复超限点个数统计的考察对象是连续2次检查中的重复超限点，表3显示了2011年3月4类超限重复点的个数分布，可以看到上行轨道重复点较多，这些反复出现超限的地点需要在工作中加以关注。

表3 超限重复点统计的界面图Tab.3 Interface of overrun repeat points 2011年3月份添乘仪检查重复超限点统计

3.3.3 问题库模块

问题库管理以工务各类检测数据为基础，对发生在同一设备上的不同检查结果进行整合，对设备问题进行统一的描述，通过对问题的跟踪管理实现设备状态的监控，具体的功能设置如下：

1）最新设备问题展示。展示任意时间段内检查发现的设备问题列表。

2）问题数量统计查询。通过选定日期范围查询统计各单位该时间段内检查发现的线路设备问题数量。

问题库根据各种检查方式产生的数据，对任意时间段内的每个设备的检查情况进行汇总，以设备为中心，显示围绕此设备产生的各种检测数据。

4 结束语

本文针对铁路工务检测的数据内容和利用现状，提出了用数据库来管理海量的多源异构数据，最终实现数据之间的物理和逻辑上深层次整合的方法，达到数据的集中式存储管理、互联共享和多维分析。基于该理论研究，笔者以神朔铁路为背景，对数据管理模型加以验证并在系统中进行了实际应用，为神朔铁路生产管理和养护维修提供了辅助决策支持。

［1］ 中华人民共和国铁道部.铁路线路修理规则［M］.北京：中国铁道出版社，2010.

［2］ 孔昱戈.数据仓库和OLAP技术概述［J］.计算机光盘软件与应用，2010（11）：24－28.

［3］ Kyte T.Effective oracle by design ［M］.USA：McGraw－Hill Osborne Media，2003.

［4］ 张和生，张 毅，胡东成，等.海量数据管理框架与方法研究［J］.计算机工程与应用，2004，40（11）：26－29，131.

［5］ 刘荣凤.浅谈铁路工务线路设备管理对安全生产的作用［J］.山西建筑，2010，36（2）：348－349.

［6］ 戴国华，董宝田，李明辉，等.铁路数据资源整合的分析与设计［J］.铁路计算机应用，2009，18（11）：7－10.