1. TCMS系统架构与数据流

列车控制与管理系统（TCMS）是城轨车辆的“神经中枢”，它把分散在各车厢的牵引、制动、车门、空调、辅助供电、信号接口等子系统连接成一张可观测、可控制、可追溯的网络。做数据诊断与工单处理，第一步不是急着看故障码，而是先建立一张“数据地图”：清楚系统由哪些部分组成、网络如何分层、关键数据从哪个源产生、经过哪条路径到达诊断终端。只有知道数据“从哪来、怎么走、在哪停”，后续的故障定位和工单描述才有依据。

一、TCMS的组成：从中央到末端的四级对象

典型城轨车辆的TCMS可归纳为四类实体。第一类是中央控制单元（CCU/VCU），通常设于带司机室的头车，负责列车级逻辑控制、模式管理、故障汇总与事件记录，是诊断数据的主要汇聚点。第二类是车辆控制单元（VCM）或本地控制单元，按车厢分布，承担本车子系统数据采集与命令下发。第三类是子系统控制单元，如牵引控制单元（DCU）、制动控制单元（BCU）、车门控制单元（EDCU）、空调控制单元（HVAC）、辅助逆变器（SIV）等，它们是原始数据的真正产生者。第四类是人机接口与维护设备，包括司机室显示屏（HMI）、维护用便携终端或车载维护屏，用于数据呈现与故障读取。

这四类实体之间不是简单的上下级关系，而是“中央协调、本地汇聚、子系统执行、接口呈现”的分工结构。诊断时若把CCU当作唯一数据源，就容易忽略子系统内部更细的原始状态量。

二、网络拓扑：三层总线与两条关键路径

城轨车辆TCMS普遍采用分层总线结构。列车级通常使用列车通信网络（TCN），由绞线式列车总线（WTB）连接各车厢，实现跨车通信与列车编组识别；车辆级使用多功能车辆总线（MVB），连接本车CCU、VCM及各子系统控制单元，是诊断数据最密集的一段；设备级则常见CAN、RS-485或以太网，用于车门、空调、照明等低速或专用设备。部分新车型在维护网络上叠加以太网，便于大容量日志下载。

由此形成两条关键数据路径：其一是实时控制路径，命令从CCU经MVB下发至DCU、BCU，周期通常在毫秒到数十毫秒级；其二是诊断维护路径，子系统把故障码、状态字、里程、温度等写入本地缓存，再由CCU周期轮询汇总，或由维护终端通过维护接口按需读取。两条路径的时效性和完整性不同，诊断时必须区分“实时值”和“记录值”，不能混用。

三、关键数据源：诊断真正要盯住的量

建立数据地图，核心是识别“关键数据源”。按诊断价值排序，通常包括以下几类：

• 故障码与事件记录：由各子系统控制单元产生，带时间戳、故障等级、发生次数，是工单的第一手依据。
• 状态字与模式字：如牵引使能、制动施加、车门关闭到位、列车零速等，反映系统当前处于什么状态。
• 模拟量：牵引电机电流、制动缸压力、母线电压、设备温度等，用于判断劣化趋势而非仅看有无故障。
• 里程与时间基准：故障发生时的累计里程和系统时间，是跨系统关联分析的关键索引。
• 网络通信状态：端口丢帧、总线负载、节点在线状态，用于区分“设备真故障”与“通信假故障”。

以车门为例，EDCU上报的“关门到位”状态字与门控器内部的电机电流曲线，诊断含义完全不同：前者是结果，后者能反映门机阻力增大等早期征兆。数据地图要标注每个量的来源设备和更新周期，避免把慢速轮询值当作实时值使用。

四、传输路径与诊断数据地图的落地用法

把上述组成、拓扑和数据源串起来，就得到一张可操作的诊断数据地图。实际排障时可按“由果溯因”的顺序使用：先在HMI或维护终端看到某条故障提示，确认它来自哪个子系统；再判断该数据是子系统本地记录、经MVB汇总到CCU，还是通过维护以太网单独读取；然后核对该路径上的中间节点是否正常，例如CCU是否收到该子系统心跳、MVB端口是否在线。若中间节点异常，问题可能出在通信而非设备本身。

下表给出一份简化的数据地图字段示例，可作为日常诊断记录的参考结构（示例字段，实际车型以车辆技术文件为准）：