基于TCMS落地数据的存储、检索、显示软件平台

2023-06-09蒋陵郡周黎明朱少华

现代计算机 2023年7期

蒋陵郡，周黎明，吴强，朱少华

（中车南京浦镇车辆有限公司电气研发部，南京 210000）

0 引言

城市轨道交通行业业内传统的调试和故障分析方法是“黑匣子”策略，即将故障本身和引起故障相关的信号信息存储在固定的符合行业标准的车载设备中，该设备一般称为EVR（Environment Variable Record）。该方式存在的弊端是必须在列车返库时，由工程师上车下载数据并使用特定的解析工具分析。其一，增加人工及维护成本，各列车数据都要人工下载且需要安装了特定解析工具的维护电脑；其二，数据实时性低，无法第一时间获取相关信息；其三，解析工具软件为C/S架构，同时只能单台电脑单人分析。

该平台采用车地无线传输方式将关键数据落地，考虑到运营中列车存在频繁切换通信基站导致丢包的场景。第一，为保证故障数据传输实时且准确，设计具备以太网传输能力的车载设备DDU（driver display unit）作为中间设备，接收数据并判断故障发生和消失状态，并以TCP 报文将故障信息发送至地面服务器；第二，为保证环境变量数据（即导致故障发生的变量）的完整性与准确性，牺牲一定的实时性，在车载设备中每存满一包固定大小的数据再通过FTP/SFTP 的形式下发至地面服务器，该方式支持断点续传；最后，根据配置文件在地面服务器绑定故障信息与环境变量并生成FDL（Fault Data Logger）存储至数据库软件，地面服务器再对外提供可视化的Web应用服务。

1 设计方案

1.1 数据落地方案

DDU 实时接收来自VCU 的周期性故障数据（UDP报文）。故障数据中每bit代表一个故障，当且仅当连续两包数据中相同bit位由0跳变为1表示该故障发生，由1 跳变为0 表示该故障消失。故障发生或消失均触发TCP报文。如图1所示。

图1 故障数据传输流程

DDU 实时接收来自VCU 的周期性环境数据（UDP报文）。DDU将接收到的环境数据每18000个采样点（按100 ms 的周期即30 分钟，可配置）缓存成一个文件。该文件命名格式如下：<线路号>_<列车号>_<源设备>_<文件创建时间>.cache，如: 0001_10_VCU1_2020_9_17_14_27_34_245.cache。当缓存文件写满后即通过FTP/SFTP 上传到地面服务器，上传完成后将地面服务器上的缓存文件的扩展名由cache 改为dat，并删除DDU中的缓存文件。

1.2 数据存储方案

故障记录落地后存储在关系数据库（如MySQL）中的“近期故障表”，环境数据落地后存储在时序数据库（如InfluxDB）［2］。如图2 中①所示。

图2 数据存储方案

当DDU 启动后，开始接收来自VCU 的UDP报文，其中的“列车号”或“源设备”发生变化则向地面服务器发送一个故障ID为0xFFFF的表示列车上电的报文。地面服务器在接收到该报文后，将对应“列车号”和“源设备”的当前故障设置为历史故障，即使有些故障仍未消失，这些故障也会被设置为历史故障，并且地面服务器将该“列车上电”报文作为一条故障记录记录到数据库。同时，对于UDP 报文中故障数据为1 的故障，DDU 会重新发送表示这些故障发生的报文给地面服务器。

地面服务器每天定时将“近期故障表”中3个月外的故障记录转移到“历史故障表”。同时也会将时序数据库中与这些故障相关联的环境数据一起存储到“历史故障表”中。并删除时序数据库中3个月外的环境数据。如图2中②所示。

1.3 数据检索和显示方案

数据的检索和显示功能的实现采用B/S 架构［3］。主要实现以下功能：

（1）当前故障和所有故障

故障的检索、显示、处理建议和分类统计。

（2）环境数据

以图形或表格的方式显示任意时段用户选取的环境数据，图形方式如图3所示。

图3 查看环境数据

1.4 项目配置方案

项目配置包括该项目对应的故障清单、环境变量清单以及故障与环境数据的绑定关系（下称绑定关系）。只有地面服务器需要配置，DDU等其他设备无需配置。项目配置保存在地面服务器关系数据库的“故障清单表”和“环境变量清单表”中。故障清单保存在“故障清单表”中，环境变量清单保存在“环境变量清单表”中。绑定关系保存在“故障清单表”的“绑定关系”列。

故障序号即VCU 发送给DDU 的故障数据中对应位的位偏移。DDU 发送到地面服务器的故障信息TCP 报文中通过故障序号标识故障。这样DDU 无需项目配置，即可完成故障信息的发送。在后期的故障清单维护过程中，故障序号不能复用。已删除故障的序号不能再分配给其它新的故障使用，以免出现数据解析错误。

环境变量序号与环境数据中的环境变量一一对应。在后期的环境变量清单维护过程中，环境变量序号不能复用。已删除环境变量的序号不能再分配给其它新的环境变量使用，环境变量的偏移、大小以及数据类型都不能修改，以免出现数据解析错误。

关系数据库的“历史故障表”中也有“绑定关系”列。当有新的故障记录写入到“历史故障表”，此时该故障对应的绑定关系也和对应的环境数据一起保存。如果后期该故障的绑定关系发生改变，“历史故障表”中的环境数据也可以依赖之前的绑定关系成功解析。

1.5 司控台模拟功能方案

司控台模拟功能采用B/S架构。地面服务器实时接收来自VCU（或通过DDU 中转）的周期性司控台状态数据（UDP 报文）。用浏览器访问地面服务器提供的相应Web 服务，页面会根据最新的司控台状态数据实时刷新显示内容。

当用户点击菜单栏“司控台”选项，将打开一个“列车列表”界面，其中显示列车的概要信息：列车号、在线状态、信息更新最后时间，当前故障和历史故障总数。效果如图4所示。

图4 列车列表页面

在“列车列表”界面单击某一列车的图标，进入到该列车的“列车状态”界面。该界面上半部分内容固定，包括列车速度、牵引级位、制动级位、驾驶模式、下一站、总风缸压力、网压。下半部分内容分为以下三个板块：按钮状态、指示灯状态、旁路开关状态。如图5 所示，其中按钮、指示灯和开关可在数据库中由TCMS（train control and management system）开发人员自行配置［4］。

图5 列车状态页面

1.6 重大故障弹框方案

当有重大故障发生时，浏览器弹出重大故障弹框。该弹框采用Bootstrap 中的模态框，每个重大故障对应一个弹框。当有多个重大故障发生时，浏览器会弹出相同数量的弹框，且最新发生的重大故障位于最上方。当有重大故障弹框弹出时，用户不能操作该页面其它部件，但不影响其他标签页或浏览器实例的操作。

Web前端和后端之间采用WebSocket方式通讯。前端作为客户端，后端作为服务器端。服务端周期性每隔5秒钟查询一次数据库中未消失且未确认的重大故障推送给所有的客户端［5］。一条推送消息中可能包含多个重大故障的信息。当客户端连接上服务端后，即可接受到推送消息。两次推送消息中可能有重复的重大故障，客户端需要去重。接收到的每个重大故障弹出一个弹框。

当弹框被用户确认，客户端发送一个响应消息给服务端，响应消息中包含用户信息以及对应的故障信息。服务端向MySQL 数据库中写入对应的确认记录。该条故障后续将不会再向客户端推送。客户端在没有收到重大故障或均已被确认的情况下，一旦再次收到重大故障，则同时触发警示音。一旦有一个重大故障被确认，表示已经有人处理时，则同时消除警示音。

1.7 历史数据清理方案

应用软件EDCleaner 将遍历某个时间点（可通过命令行参数配置）之前的所有故障，将这些故障对应的环境数据由InfluxDB 保存到MySQL的fault 表的envData 字段。envData 字段中保存的环境数据为json 格式，包含时间和各环境变量的变量名以及值。MySQL 的fault 表的envData字段的初始值都是null。检索环境数据时，如果envData 字段的值为null 则直接从InfluxDB 调取环境数据，如果非null 则直接从该字段调取环境数据。