4. 运维数据平台与数据管理

城轨车辆智能运维的起点不是算法，而是数据。列车在正线运行时，TCMS、走行部监测、车门控制、空调、制动等系统持续产生状态量、报警量、累计量和事件记录。这些数据先要在车载侧完成采集与落地，再经车地通道传到地面，最终进入可查询、可分析、可追溯的数据平台。本节围绕这条链路，讲清车载数据落地、地面平台架构、时序数据库与数据湖的分工，以及数据质量检查与预处理的实际做法。

车载数据落地：先保证“存得住、对得上”

车载数据落地指数据在车辆侧被采集、缓存并可靠保存的过程。工程上通常由车载网关或边缘计算单元承担：它通过MVB、CAN、以太网等接口周期读取各子系统变量，按预设的采样周期（例如状态量1 s、模拟量100 ms～1 s、故障事件按触发记录）形成带时间戳的数据帧，写入本地存储。这里有两个关键约束：一是时间基准统一，所有变量应打上同一时钟源的时间戳，避免不同子系统各用各的时钟导致后续无法对齐；二是断点续传，车地无线链路在隧道、库内常会中断，车载侧需用本地队列缓存，链路恢复后按序补传，并记录传输状态，防止数据静默丢失。

落地策略上常见“全量+抽稀”并存：高频模拟量在车载侧做短时缓存和特征抽取（如均值、峰值、均方根），原始波形仅在触发条件（如冲击超限、故障报警）时完整保存，以控制存储与流量。这一取舍直接决定地面平台能拿到什么粒度的数据。

地面数据平台架构：分层解耦

地面平台一般分为接入层、存储层、计算层与应用层。接入层负责协议解析、消息队列缓冲和入库分发；存储层按数据形态分库存放；计算层承担清洗、特征计算、指标聚合与模型推理；应用层面向检修、调度和健康管理提供查询、报表与告警。下图给出这一架构及数据流向。

时序数据库与数据湖：各管一段

时序数据库面向“按时间连续写入、按时间区间查询”的场景，数据模型通常是测点标识、时间戳、数值三要素，配合标签（如车号、系统、设备）建立索引。它的优势在于高写入吞吐、按时间窗口聚合和自动降采样，适合查询“某车某轴位近7天轴温趋势”这类问题。数据湖则面向原始与多形态数据，把车载原始报文、振动波形文件、故障日志、检修记录按主题和时间分区存放，保留原始细节，供离线回溯、模型训练和审计。二者不是替代关系：时序库存“可快速查询的指标化数据”，数据湖存“不可轻易重造的原始证据”。实践中常用统一测点编码把两边关联起来，保证同一变量在两侧可对应。

数据质量检查与预处理流程

原始数据几乎不可能直接可用。常见问题有三类：缺失（链路中断、采集丢帧、传感器掉线）、异常（野值、跳变、量程越界、冻结值）、时间不对齐（不同采样周期、时钟漂移、传输延迟）。预处理的目标是在不歪曲物理事实的前提下，把数据整理成可分析的一致序列。

缺失值处理要先判断缺失类型。短时单点缺失可用线性插值或前值保持；连续缺失超过阈值（例如超过3个采样周期）不宜插值，应标记为无效段，避免“造数据”。对状态量（如车门开关）不能用插值，应保持上一有效状态并标注置信度下降。

异常值处理常用物理量程约束加统计判据。例如轴温合理范围可设为环境温度至120 ℃，超界直接判无效；对缓变量再用滑动窗口的3σ或中位数绝对偏差（MAD）识别跳变。发现野值后，可置为缺失再按缺失规则处理，而不是简单替换为均值，以免掩盖真实故障前兆。

时间对齐是三者中最容易被忽视的一步。不同系统采样周期不同，需先统一到同一时间基准，再按分析需求重采样：趋势分析可对齐到1 s或1 min网格，冲击分析则保留原始高频。对齐时常用“最近邻取值”或“区间聚合（均值/最大值）”，并明确聚合窗口。若发现某车时钟相对基准持续偏移，应先做时钟校正再对齐，否则对齐结果会整体错位。

可执行的质量检查清单

把上述规则固化为可重复执行的检查项，才能保证不同批次数据口径一致。下面是一份可直接参考的检查表结构，字段按本节任务设定：

执行时建议保留“处理前—处理后”的对照记录和每类问题的计数，形成数据质量报告。这样当后续模型输出异常时，能快速判断是数据问题还是设备问题。数据平台的价值，最终体现在这条从车载落地到质量可控、再到可分析应用的链路上是否闭环。