区间信号系统测试平台专用数据库论文

导语：区间信号系统测试平台专用数据库论文一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

摘要介绍了城市轨道交通区间信号系统测试评估平台的研制背景,给出平台的硬件分布式系统和软件系统结构。简要介绍了平台软件系统各个子系统的功能。阐述了平台专用数据库的设计过程,以及前台VC6开发的应用程序与后台数据库服务器SQLServer接口的实现方法。

关键词安全管理,区间信号,数据库设计,计算机辅助测试

城市轨道(简称城轨)交通区间信号系统是安全性苛求系统。在区间安全性控制和防护设备的研制、生产、使用过程中,运用现代技术手段对设备的可靠性和安全性进行科学、高效、全面、按标准的检测和评估,以取代目前国内主要依靠专家经验进行的手工测试和实际线路试运行的非完善的方法,是十分迫切和必需的。在我国城市轨道交通领域,这方面的研究尚处于起步阶段。本文的研究正是基于这一背景。文中所建测试平台对城际铁路同样适用。

1区间信号系统测试平台的结构

城轨交通区间信号系统测试评估平台(以下简称平台)硬件采用分布式结构,如图1所示。平台由主控机、数据库机和仿真机组成[1]。被测系统通过网络与平台互联。网络通信采用TCP/IP协议。

图1平台分布式硬件结构示意图

平台软件系统结构框图如图2所示。其中:主控及测试案例自动生成子系统一方面向仿真子系统发送区间状态的仿真设置命令,另一方面动态监控现场信号状态等,实现测试案例的动态扩展和连续加载、测试结果的动态判定,并将测试结果存入数据

图2区间信号测试系统的软件结构库。传输信道仿真及区间现场仿真子系统为被测系统提供了一个模拟的传输仿真及现场环境。数据采集与处理子系统在被测系统与仿真信道之间进行数据处理及转换。测试用基础数据生成子系统通过读取区间拓扑数据文件,生成区间测试用基础数据。专用数据库子系统负责存储各种测试用基础数据和测试结果。本文重点阐述平台专用数据库子系统的研究与实现。

2平台专用数据库设计

平台的数据库不仅是一般意义上的数据库应用,它还负责协调各个子系统之间的数据联系。平台数据的类型与结构在一定程度上反映了整个平台的测试水平。基于对平台数据以及平台分布式结构的考虑,经过深入的比较,选择SQLServer作为平台的数据库开发工具。数据库设计一般分为四步:需求分析、概念设计、逻辑设计和物理设计。应用数据库设计理论,平台专用数据库设计的具体步骤如图3所示。

图3数据库的设计过程

2.1需求分析

平台的数据按其对时效性的不同要求可以分为动态数据和静态数据两大类[2]。动态数据是指具有严格时效性的数据,并且随着时间推移而动态刷新;静态数据则指相对稳定,不随时间变化的数据。

2.1.1动态数据及其传输

平台动态数据是维持平台正常运行的基础,主要包括下列3类数据:

·列车运行仿真命令、故障及干扰仿真命令。由主控机发出,用于控制仿真子系统进行相应仿真活动。

·区间信号设备状态及动作信息。指仿真机所模拟的实际区间信号设备的状态(如轨道区段是否有车占用等),主控机采集这些信息用于动态判定及显示测试过程的实际状态。

·测试结果信息。平台的测试结果记录是一种比较特殊的动态数据,包括经信道传输前后的实时电信号(数据)。它们是评价被测系统的重要依据,必须完整、正确地记录。

动态数据传输首先必须满足实时性要求,当不能及时传送时,根据数据特性的不同,或丢弃,或重发。例如被测系统发送的数据如不能及时传送,或数据有误,则该数据必须丢弃。主控机发给仿真子系统的故障及干扰仿真命令、列车运行仿真命令,在网络传输出现差错的情况下,为了确保命令被正确执行,必须重发。

2.1.2静态数据及其复制

生成和校验正确后的静态数据,在平台对被测系统进行测试的过程中不再变化,具有相对的稳定性。同样需要对静态数据进行存储、查询、校验和修改等操作。平台静态数据可分为以下几类:

·信号设备数据。记录发送端、接收端、闭塞分区的排序序列号与设备名称之间的映射关系,设备的一些属性特征。例如:闭塞分区的编号、名称、位置、长度,道岔的编号、名称、位置、类型等。

·基本数据。包括区间基本特征、钢轨线路的一次参数、钢轨线路四端网参数、列车运行线路等重要数据。其中区间基本特征数据包括闭塞制式、轨道电路类型、道碴与枕轨类型、坡度、曲线及长度等。列车运行线路数据包括线路运行方向、经由闭塞分区编号、经由发送端、接收端编号。

·区间现场拓扑数据。包括闭塞分区、发送端、接收端的位置和相互关系。这种描述有两方面用途,一方面用于现场仿真的动态显示,另一方面是作为测试用基础数据生成的原始依据。静态数据的复制是通过开放式数据库互连(ODBC)机制实现的。

2.2概念设计

在数据库设计中,笔者使用实体-联系(ER)模型作为概念设计的工具,得到概念设计的E-R图。E-R图由实体、联系和属性3个基本成分组成。测试用基础数据所处理的基本实体是城市轨道交通区间的信号设备:接收端、发送端、闭塞分区;设备之间的关系也就是最直接的实体间联系。通过E-R图,可以十分清楚地描述测试用基础数据的结构。图4为列车运行线路数据的E-R图。

图4列车运行线路ER图

2.3逻辑设计

关系数据库的逻辑设计过程是把概念设计的结果(如E-R图)转换成关系模式的过程。为了消除关系模式的存储异常问题,需要对其进行规范化。

在本子系统数据库模式的规范化设计过程中,既要考虑减少数据冗余、消除存储异常情况,也要考虑现场仿真、主控等子系统读取数据及运算的花费。规范化测试用基础数据的关系子模式包括:发送端表、接收端表、闭塞分区表、列车运行线路表、区间基本特征表、钢轨线路一次参数表、钢轨线路四端网参数表等。

2.4物理设计

物理设计要根据具体的数据库管理系统(DBMS)和相应的操作系统、计算机硬件所能支持的存储结构、存取方法以及资源来进行设计。SQLServer提供索引或表键机制来帮助SQLServer优化对查询的响应。在测试平台上,对结果数据的查询,是将记录计数号与测试项目的组合作为索引。这是因为大多数的查询都要直接或间接地将该两项作为SQL语句中WHERE子句后的首列。

3平台专用数据库接口的实现

平台采用客户端/服务器体系,后台数据库服务器采用SQLServer,前台应用程序开发工具采用VisualC++。前台应用程序对数据库的访问是通过ODBC机制实现的。

VisualC++对ODBC提供了两种支持:一种是API函数[3];另一种是对API函数进行封装的MFCODBC类,包括CDatabase(数据库类),CRecordSet(记录集类)和CRecordView(可视记录集类)。两种方式在平台上分别应用于不同的场合。

·ODBCAPI使客户应用程序能够从底层设置和控制数据库,完成一些高层数据库技术无法完成的功能。例如检测数据库是否连接、数据源配置是否正确等。

·MFCODBC类封装了多种数据库访问功能,使用简单方便。平台专用数据库定义了11个CRecord2Set类的子类,每一个子类对应专用数据库中的一个表,例如,B-JSSet类对应接收端表,B-BSFQSet类对应闭塞分区表。

4结语

建立在SQLServer上的平台专用数据库要兼顾通用数据库的设计要求和区间测试平台的特殊性。只有综合考虑这两方面的因素,才能使专用数据库既高效又安全。当然,随着平台水平的不断提高,专用数据库的功能必将随之扩展,日趋完善。

参考文献

1吴芳美.铁路安全软件测试评估.北京:中国铁道出版社,2001.23

2荆剑.基于计算机联锁安全软件测试评估平台的CLIENT/SERVER数据库[学位论文].上海:上海铁道大学电信系,1999:23

3丁宝康.数据库实用教程.北京:清华大学出版社,2001.2744王鸿,吴芳美.区间信号仿真系统中干扰仿真的建模研究.城市轨道交通研究,2003(1):42