轨道交通数据的分层结构
地铁运营监控的数据来源跨越多个子系统，数据特征差异显著。按系统划分，包括CBTC（基于通信的列车控制）信号系统的列车位置与速度、牵引供电系统的电压电流、车辆系统的车门与空调状态、站台门与自动扶梯状态、环控系统（车站温湿度、CO2、隧道通风）、轨道电路状态。这些数据分属不同专业，采集设备与协议各异。这一多源异构特征对时序数据库的接入与组织能力提出了较高要求。
从数据用途看，可分为行车控制数据与运营监控数据。行车控制数据直接参与列车运行控制，要求高实时性与高可靠性，采集频率高；运营监控数据用于状态监视、统计分析、故障预警，采集频率相对宽松。两类数据对存储系统的延迟、吞吐、保留周期要求不同。
轨道交通的一个显著特征是安全等级差异。行车控制数据属于安全相关数据，需要严格的完整性保证与审计追溯；运营监控数据属于一般数据，可靠性要求相对宽松但数据量大。存储架构需要按安全等级分区，避免不同等级数据的相互影响。
采样频率的分层
车载数据的采样频率最高。CBTC系统的列车位置（基于应答器与无线定位）、速度、加速度数据需要毫秒级采集以支撑精确的列车控制与移动闭塞。牵引/制动电流、轮速、轴温等车辆状态数据采集频率在10-100ms。车载数据总量与列车数量、每列车采集点数相关。
车站侧数据的采样频率为秒级。车站的站台门状态、自动扶梯与电梯状态、环控系统参数、客流检测数据以秒级采集为主。车站设备数量多但单体数据量小，全线数十个车站的数据量合计可观。
区间设备（轨道电路、信号机、转辙机、计轴设备）的数据采集频率在秒级至事件触发。转辙机的动作电流曲线需要较高频率采集以判断转换是否到位；轨道电路状态通常是事件触发的离散数据。
数据层级 | 典型系统 | 数据项 | 采集频率 | 安全等级 |
车载 | CBTC/车辆 | 位置/速度/电流/轴温 | 毫秒-100ms | 安全相关 |
区间 | 信号/轨道电路 | 轨道电路/转辙机/计轴 | 秒级/事件 | 安全相关 |
车站 | 机电/环控 | 站台门/扶梯/温湿度 | 秒级 | 一般 |
线网 | 运营管理 | 客流/运行图/能耗 | 分钟级 | 一般 |
故障录波与安全事件追溯
轨道交通的故障分析依赖事件录波与数据追溯。当列车发生牵引故障、通信中断、紧急制动时，车载系统生成的故障录波文件包含故障前后的高频数据，用于事后分析原因。
录波数据的特征是高频、突发、短窗口。一次故障录波可能包含数十个通道、数秒至数十秒的数据、采样频率1-10kHz。这些录波文件通常以二进制格式（COMTRADE标准，IEEE C37.111）保存，与常规时序数据格式不同。存储系统需要同时支持常规时序数据与录波文件的管理，或通过统一的时间戳索引关联两类数据。
安全事件追溯的合规要求严格。轨道交通行业对行车事故、设备故障的分析有明确的记录与追溯要求，不仅需要记录事件本身，还需要保留事件前后的运行数据。部分运营单位要求运行数据保留数年以上，以一条线路数十列车、数百个车站的规模估算，多年运行数据可达数百TB，传统关系型数据库难以承载，需要专门的时序数据库承担长期存储。
数据类别 | 典型格式 | 保留要求 | 追溯粒度 |
常规监控数据 | 时序记录 | 3-5年 | 设备/秒 |
故障录波 | COMTRADE(IEEE C37.111) | 长期 | 事件/通道 |
事件日志 | 结构化日志 | 长期 | 事件 |
运行图数据 | 结构化记录 | 3-5年 | 车次 |
CBTC信号系统的数据接口
CBTC系统是轨道交通的核心安全系统，由车载控制器（CC）、区域控制器（ZC）、联锁（CI）、数据通信系统（DCS）组成。CBTC对外提供的数据接口通常是只读的监控接口，用于向综合监控系统（ISCS）或运营管理系统提供列车位置、速度、运行状态等数据。
接口协议多为专用协议或定制化的数据服务。部分厂商提供基于OPC UA或私有TCP的服务，数据频率为秒级。CBTC的原始高频数据保留在车载与地面安全系统中（受安全认证约束不可随意导出），对外接口输出的是处理后的监控数据。
这意味着运营监控平台的数据来源是CBTC的监控输出而非原始控制数据。数据接入的实时性受限于接口频率与网络状况，通常为秒级至亚秒级。运营监控平台的核心价值不在于复现控制过程，而在于跨系统的数据融合——将信号、供电、车辆、环控系统的数据在同一时间轴上关联，分析系统间的相互影响。
标签模型适配线路-车站-列车-系统
轨道交通的数据层级为：线网→线路→车站/区间→系统→设备。轨道交通的多级标签结构适合用时序数据库的标签模型表达。
标签设计上，线路ID、车站ID、列车ID、系统类型（信号/供电/车辆/机电/环控）作为标签维度，测点作为列。列车是移动对象，其标签包含当前运行线路与编组号，跨线运行的列车标签需要支持线路变更。查询某列车在某区间的位置与速度曲线时，按列车标签与区间标签交叉过滤。
TDengine的标签模型支持列车这类移动对象的数据组织。将列车ID作为标签，每列车的数据按标签分区存储，避免了单一超宽表在列车数量增长时的性能衰减。当线路扩展、列车数量增长时，按列车标签的分区可以平滑扩容。时间分区配合秒级采样，使”查询某列车某天某区间段的运行数据”这类追溯查询只需扫描少量分区。
数据分级存储是轨道交通的常见需求：近期数据（热数据）用于实时监控与快速查询，需要高性能存储；历史数据（冷数据）用于追溯与统计，对性能要求低但容量需求大。分层存储（热数据SSD、冷数据HDD或对象存储）配合统一查询接口，是平衡性能与成本的有效手段。
结语
轨道交通的数据架构受到安全等级与合规要求的强约束，通用IT系统的存储方案难以直接套用。运营监控平台的定位是跨系统数据融合分析，这一职责决定了它需要一个能承载海量多源数据、支持多级标签组织、满足长周期追溯的存储底座。从演进方向看，轨道交通的数据平台正在从各专业独立监控走向线网级统一数据服务，数据的价值从事故追溯扩展到运行优化与预测性维护。TDengine在列车标签建模、时间分区与分层存储上的适配能力，为线网级数据汇聚提供了一条可行的技术路径。
