地铁动应力测试数据管理与数据可视化系统研究

2022-10-10赵光伟刘志明

计算机应用与软件 2022年9期

赵光伟刘志明陈羽

1(中国铁道科学研究院集团有限公司铁道科学技术研究发展中心北京 100081) 2(北京交通大学机械与电子控制工程学院北京 100044)

0 引言

自1965年北京建设第一条地铁至今，我国地铁建设已有50多年的历史[1-2]。截至2019年12月，我国地铁运营总里程已超过6 600公里。然而，随着运营里程的不断增长，地铁转向架构架的关键部位如空气弹簧附加室、电机吊座、轴箱吊座等部位的焊缝处会产生裂纹[3]，最终导致构架疲劳失效。因此需要对地铁车辆关键部件进行动应力测试，获取车辆在运行过程中各疲劳薄弱部位的应力变化和损伤情况，并以测试结果为依据进行寿命预测和疲劳评估，最终提出合理的结构改进方案，延长地铁的运营寿命。动应力测试通常采用SoMat eDAQ动态数据采集系统对构架疲劳薄弱部位的应变[4]、轴箱和构架侧梁上方的加速度、列车速度、车体摇头角速度进行同步采集，测试通道往往多达上百个。为了保证动应力测试数据的可靠性和完整性，测试过程中通常需要在运营线路上进行多个往返的测试，并持续数天，个别情况下需要对构架进行长期跟踪测试。面对如此大规模的测试数据，仅简单地将数据按照测试时间存储在磁盘，可能会存在文件缺失、管理混乱的现象，不利于科研人员将测试结果同历史数据进行比对分析和数据挖掘。因此，如何合理地管理数据、高效地查询数据已成为十分重要的研究方向。

近年来，计算机数据库技术得到飞速发展，并广泛应用于各个领域。黄挺等[5]针对地铁车辆现场数据进行了数据库搭建。陈晴等[6]收集了多个来源的环境气象数据并搭建了环境气象数据库。Plana等[7]建立了面向水质的数据库，并利用大数据手段开展数据挖掘。数据库种类繁多，并向多方向发展。伴随互联网技术的发展，XML数据库逐渐成为了一种数据存储方式[8]。此外为了追求更加完善且符合现实生产的数据模型，研究人员还提出了一种非结构化数据库，支持重复字段和任意变长数据。这些技术的发展，弥补了关系型数据库的一些不足，但由于关系型数据库具备深厚的技术基础、使用经验、大量的市场占有额，本文选择关系型数据库进行数据管理。

本文首先提出针对动应力测试数据集的存储方案，并研究了格式转换的相应工具；其次，提出试验和测试两个数据颗粒度，并设计关系型数据库模型，同时开发相应软件界面；本文的最后利用AnyCAD控件提供的API处理地铁车辆转向架模型，采用以抽样因子为核心的数据抽样显示算法绘制了二维波形，实现了查询结果的可视化。

1 数据存储

原始数据采集后，可能存在因信号断采产生的尖峰信号或是因传感器温度上升引起的零点漂移[9]，不能直接用于分析，需要利用数据采集系统的配套软件进行读取和处理。然而，当需要深入挖掘信号文件内的信息时，由于不清楚配套软件生成的文件结构，给研究带来一定难度。本节对该软件中的.dac格式文件进行了解析和转换，提出了便于检索的测试信号存储格式并开发了相应的.dac格式转换工具。

.dac文件是每个采集通道单独存储的数据文件，利用二进制文件查看器对.dac文件进行逐字节解析，发现该格式的文件以小端模式存储，由三部分构成，分别为：文件头区、数据块区、文件尾区。表1展示了.dac文件结构中的关键信息。其中：m指代数据区结尾的最后一个字节地址；L指代文件总长度。

表1 .dac文件内部结构

在解析的基础上，本文抽取.dac文件中的数据块区，以小端模式、单精度浮点类型、单通道独立存储的方式保存在后缀名为.mdta的二进制文件中，以此作为信号文件的存储格式。为了保证.dac文件中重要的元数据信息(如：最大值、采样频率等)不丢失，将单次测试的所有通道文件的重要元数据信息抽取并以.xml格式聚合在后缀名为.meta的文本文件中。其中，单通道文件的.xml格式为：

E:channel1.mdta

478350

601195

478350

可以看到，通过将数据区与元数据分离，不仅使得数据信号文件体积得到了压缩，文件结构变得十分简单，而且元数据信息也保留了。

多通道的.dac文件在转换过程中需要进行大量的磁盘IO操作，若全部运行在UI线程，则将阻塞UI界面直至崩溃，为了提升转换效率，基于.Net Frame-work 4.5并行任务框架设计了.dac文件转换工具。该工具的核心算法如算法1所示。

算法1文件格式转换算法

1. var lists=new List();

//变量初始化

var scheduler=new LimitedConcurrencyLevelTaskScheduler(16);

2. for(int i=0;i

//创建任务

{

Task t=new Task(()=>

{

Read_Header();

//读文件头

If(Header_Over)

{

Write_Data();

//写数据

If(Data_Over)

{

Read_Foot();

//读文件尾

Write_Xml();

//写xml

}

},cts.token,TaskCreation.LongRunning);

t.Start(scheduler);

lists.Add(t);

}

3. Task.WhenAll(lists).ContinueWith(_=>{

Report_Finish();

//报告UI线程任务结束

})

在算法1中创建了任务调度者，控制同时并发的最大线程数为16，每个任务转换一个.dac文件。当并发任务数量大于16时，多个工作线程抢占调度队列空间。调度队列中的任务执行完毕，按照FIFO的顺序退出队列，剩余线程继续抢占调度空间，直至结束。在与UI界面交互时，由于开启任务数多于进度条数目，为了避免多个任务共同刷新一个进度条，按照多任务抢占控件的设计思路进行设计：抢占成功的工作者线程对控件封送消息，而未抢占成功的线程则阻塞，直至有进度条空闲。进度条控件获取算法如算法2所示。

算法2进度条控件获取算法

1. Progressbar pb;

//声明待返回的进度条

Int check_index=0;

//指示当前进度条索引序号

2. lock(progressbars)

//锁定进度条组

{

while(true)

{

If(check_index

{

If(progressbars[check_index].Value==0)

{

pb=progressbars[check_index];

check_index++;

return pb;

}

else

//超出进度条组界限

{

check_index=0;

}

为了测试文件格式转换算法的执行效率，向转换工具中导入了22个独立采集通道的.dac数据文件，每通道文件内包含60万个数据采样点。连续转换5次，并与传统单线程转换算法的执行效率进行了对比，测试结果如表2所示。

表2 两种转换算法执行效率对比单位:s

文件格式转换算法较传统算法的执行效率提升约67.3%。转换工具界面如图1所示，界面左侧为8个通道并行转换进度，右侧记录了各通道文件的详细转换情况。

图1 转换工具界面

2 数据管理

信号文件按照定义的格式存储后，还需要在磁盘中存储试验数据之间的约束关系，以保证数据文件能够正确、快速地被检索出来。本节设计了针对动应力测试数据的关系型数据库并搭建了数据管理的软件界面。

2.1 关系模型设计

在关系型数据库中，信息是以二维表格模型的形式存储，表单中的字段信息是对现实世界的高度抽象和归纳，明确每一张表、每一个字段的实际意义，合理地与应用程序功能对接，这样设计出的表和字段才是有意义的[10]。除了考虑表与字段的含义，还应充分考虑表格反映的实体之间的对应关系，良好的关系设计能够降低数据冗余，提高查询的速度。另外，功能需求并不是一成不变的，当用户需求发生改变时，关系模型应当具备良好的可扩展性，表与表之间的耦合性要低[11]。

动应力测试数据关系模型设计前，需要提出数据划分依据，并以该依据为基础，研究数据间的归属关系：

定义1地铁动应力试验：自测点位置确定起至车辆布置传感器全部拆除，其间进行的全部数据采集工作集合。

定义2地铁动应力测试：自车辆离开车辆段起至再一次回到车辆段，其间进行的所有线路往返测试集合。

由定义1、定义2可以看出，试验数据共由两个颗粒度组成，这两个颗粒度的对应关系为：一次完整的动应力试验对应多次动应力线路测试，而一次测试对应唯一一个试验；一次线路测试对应着多个线路往返，每次往返属于唯一一次线路测试。基于这两个关系，将试验中产生的所有数据依次对应。本节基于MySQL 5.5环境搭建了数据库模型，模型如图2所示。

图2 数据库模型

模型共由19个表单组成，表单名称与表单含义如表3所示。

表3 数据库表单名称及含义

整个模型以测试和试验两个表单为核心进行扩展，表与表之间仅通过ID进行约束。ID字段既作为一个表的主键，又与其他表格中的相应字段共同构成外键约束，在保证信息完整性的同时正确地反映了试验与测试之间的映射关系。另外，以单独ID字段作为主键便于对数据库进行扩展，因为只需要研究新增信息所属数据级别以及相应的对应关系后，在试验表或测试表中增加能够表示新表单的ID的字段即可，大大提升了动应力测试数据库的可维护性和存活周期。

2.2 软件功能设计

地铁动应力测试数据管理系统的主要需求包括：数据录入、数据查询、数据整理、数据导出、申请新用户等，针对以上功能需求，本节基于.Net Framework 4.5框架，目标平台为x86架构搭建了用户使用界面。

为了保证测试数据的安全性，管理系统利用MySQL中的权限隔离机制，对不同访客开放不同的功能：数据管理者具备root权限，能够对数据库进行CRUD、导出表单信息、创建新用户操作。所有的普通访客账户均由管理者创建和分发，普通访问者能够查询数据信息、导出表单、下载数据，但禁止写入和更新操作。所有使用者在进入管理系统前均需要身份验证，用户登录界面如图3所示。

图3 用户登录界面

登录成功进入数据管理主界面，主界面如图4所示。

图4 数据管理系统主界面

主界面共分为三块区域：数据库结构树、数据库表单、功能区。数据库结构树展示了数据库中的所有表单，双击可以查看表中的所有记录。数据库表单是展示区，用于显示表单中的所有内容，单页限制显示1 000条记录。功能区是软件的核心部分，按照高内聚、低耦合的设计原则，将相似的功能模块聚合在同一功能页内，而模块之间仅开放少量接口以供调用。在功能页中：基本功能页面向数据管理者，主要以录入信息、维护信息为主；数据检索面向所有访客，以检索和下载数据库中存储的文本信息与数字信号文件为主，是最重要的功能模块之一。结合2.1节中的数据库模型，以查询某次试验中某天测试工况信息为例，介绍查询流程。具体查询过程如图5所示。

图5 工况信息查询流程

查询过程中相邻环节之间相互嵌套，内层返回的查询结果作为外层的查询条件。经过测试，利用该流程能够快速地查询出某一次测试中指定站点的工况信息，验证了此查询流程具备普适性。以上仅以查询工况信息为例，对于其他任意颗粒度的信息均可按照类似流程进行嵌套查询，在满足准确性的同时避免了大量表连接操作，提升了查询效率和准确率。

3 数据可视化

3.1 三维模型可视化

地铁动应力测试的主体之一是转向架构架，理解构架的结构细节有助于试验的开展和后期的结构优化设计。数据库中存储的构架模型是.stp格式文件，因此如何将.stp格式模型显示并集成至管理系统中是本节研究的重点。为了使可视化工具内嵌于数据管理系统中，本节基于AnyCAD.Net SDK中开放的API实现了构架模型的可视化。

通过查阅API文档，解析和显示.stp文件需要使用多个命名空间、类，其包含关系如图6所示。

图6 命名空间、类之间的所属关系

命名空间AnyCAD共由三个子命名空间组成，分别为：Exchange、Platform、Presentation。其中：Ex-change命名空间主要作用是解析.step、.iges、.dfx格式的模型文件；Platform提供了描述、管理和显示模型中各种点线面以及拓扑关系的类和方法；Presentation主要作用是管理显示场景，如设置背景颜色、设置相机视角等。在理解了各个命名空间的主要作用后，引用AnyCAD.Exchange.Net.dll、AnyCAD.Foundation.Net.dll、AnyCAD.Presentation.Net.dll，编写相应的调用代码即能够实现.stp格式模型的可视化。

在三维控件绘图过程中，核心是获取SceneNode对象，通过载入模型，将模型转换为场景节点，并调用RequestDraw方法发出绘制请求，模型才能被绘制出来。模型显示支持Edge、Surface、Vertex、Realistic共四种显示模式，可以根据具体需求选择不同的显示模式。软件整体界面如图7所示。

图7 三维查看器整体界面

总体来看，模型加载速度快，模型细节表达清晰，且能够很好地与管理系统集成为一个整体，基本符合设计要求。

3.2 测试信号可视化

前文提到，测试信号文件最终的存储格式是以小端模式、单精度浮点类型、单通道独立保存的二进制文件格式，后缀名为.mdta，各通道元数据以.xml格式保存在后缀为.meta的元数据文件中。基于以上存储格式，本节利用.Net Framework 4.5 Winform框架下的chart控件实现了测试信号文件波形可视化。

在二维波形的显示算法方面，在各领域均取得了一定的研究成果：何瑞昊[12]采用C#中多线程ManualRestEvent框架实现了实时采集、波形显示和存储功能；陈羽[13]研究了基于像素点显示方案的工程数据快速处理软件。针对地铁动应力测试领域，数字信号的显示方案共分为两种：一种是基于数据点显示，即将所有采集点用折线段连接显示；另一种是基于像素点显示，即根据窗口像素点数，按照一组固定抽样率1/m(平均每m点抽取1点)抽样显示[14]。第一种方案适用于采样率低、数据点少的应用场景，比如一些采集时间间隔较大的实时采集系统；第二种方案适用于采样频率高、数据点多的应用场景。针对地铁信号采集，为了保证时域信号信息不丢失，采样频率一般设为主频的10倍以上，通常为1 000 Hz，数据点总量庞大，适宜采用抽样显示。然而以固定抽样率抽样意味着无论信号长度如何均会削减采样率，若对一段时域长度较短的信号进行抽样显示，波形会失真。故本节结合两种算法，提出以抽样因子为核心、动态计算抽样率的波形显式算法。波形显示算法执行流程如图8所示。

图8 波形显示算法

抽样因子的计算方法为：

factor=2×total/width

(1)

式中：factor指抽样因子；total指数据文件的总点数；width指当前窗口宽度的像素值。

抽样因子的实际含义为：在抽样过程中将数据文件中的所有数据点构造为一个大数组，将大数组划分为了width/2个小数组，每个小数组中的容量即抽样因子。抽样因子控制着波形的显示方式，当抽样因子数值大于2时，采用抽样显示，为了保证抽样过程中尽可能保留原始信息，抽取小数组内的最大值和最小值，读取的信号长度或窗口宽度的不同都将会影响抽样因子大小；当数值小于2时，大数组的总点数较少，此时采用数据点显示方案，将大数组内的数据全部输出，不再执行抽样过程，此时抽样率为零。利用抽样因子实现了动态计算抽样率的效果，确保无论数据长度如何，波形均不失真。

由于抽样过程十分耗时，为了不卡顿主界面，利用C#多线程框架中的BackgroundWorker类构造了一个工作者线程对象，所有抽样、读取元数据等操作均安排在工作者线程中进行。波形显示窗口如图9所示。

图9 波形显示窗口

波形显示模块支持数据框选和数据回放功能，数据框选与数据回放共同维护一个字典，字典中记录着每次框选时波形的起点与终点时刻，并以LIFO的顺序进行动态维护。每框选一次波形，向字典末尾添加一条记录，相反，每回放一次将末尾的记录弹出，并读取更新后字典的最后一条记录。每次框选、回放均调用波形显示算法重构波形，以确保每一屏的波形光滑、不失真的同时能够快速响应用户的各种操作，提升用户体验。波形框选后的重构波形如图10所示。