4. TCMS软件架构与数据流

TCMS（列车控制与管理系统）的软件并不是一整块“大程序”，而是按职责分成若干层，层与层之间通过明确的接口交换数据。理解这套分层结构和数据流，是读懂TCMS报文、排查显示异常、分析控制输出是否正确的基础。本节从车载软件的分层讲起，沿着“数据采集→逻辑处理→显示/记录→控制输出”这条主链路，把关键变量和接口概念串起来。

一、车载软件的分层结构

从工程视角看，TCMS车载软件通常可以划分为四层，自下而上依次是：硬件与驱动层、底层通信层、应用软件层、人机接口与记录层。这种划分的核心思想是“下层屏蔽细节、上层专注业务”。

• 硬件与驱动层：直接面对车载硬件，包括数字量输入输出板卡、模拟量采集通道、MVB/以太网通信控制器、继电器驱动等。它负责把物理电平、总线电信号转换成软件可读的原始值，例如把24V输入通道读成0/1，把4～20mA传感器电流换算成原始码值。
• 底层通信层：负责协议处理与报文收发，典型对象包括MVB总线管理、以太网UDP/TCP通信、与牵引、制动、车门、空调等子系统之间的周期数据交换。它把“总线上的一帧报文”翻译成“某个变量等于某个值”，并处理超时、校验、端口配置等细节。
• 应用软件层：TCMS的“大脑”，实现列车级逻辑，例如牵引制动互锁判断、车门使能条件、空调启停策略、故障分级与降级运行。应用软件不直接操作硬件寄存器，而是读写底层通信层提供的变量接口。
• 人机接口与记录层：面向司机和维护人员，负责HMI画面刷新、报警提示、事件记录与故障日志存储。它从应用软件层获取显示数据，同时把司机的操作指令（如开关门按钮、模式选择）回传给应用层。

需要强调的是，分层是逻辑划分，实际工程中可能由多个处理器、多个任务甚至多块板卡共同实现。例如通信层可能运行在通信板卡上，应用软件运行在主控单元中，二者通过内部总线或共享内存交换数据。分层的意义在于：当某个子系统更换通信协议时，只需改动底层通信层和接口映射，应用逻辑可以基本不动。

二、应用软件与底层通信的接口关系

应用软件与底层通信之间最重要的概念是变量接口。底层通信层把总线上的数据组织成一张“变量表”，每个变量有名称、数据类型、方向（输入/输出）、周期、有效范围和超时判定。应用软件只面对变量名编程，不关心它来自MVB端口还是以太网报文。

以车门状态为例，底层通信层从车门控制单元周期接收一帧数据，解析出“车门关闭且锁闭”信号，映射为变量 Door_Closed_Locked（布尔型，周期100ms，超时判定300ms）。应用软件读取该变量参与“牵引允许”逻辑判断；如果该变量超时无效，应用软件应按预设策略处理，例如禁止牵引或降级提示，而不是简单当作“车门未关”。这就是接口概念中“有效性”与“值”必须分开处理的原因。

三、数据采集→逻辑处理→显示/记录→控制输出链路

TCMS的一个完整工作周期可以概括为一条链路：采集、处理、呈现与记录、输出。下面结合一个“空调启停控制”的教学示例（参数为合理假设，非实测数据）说明各环节。

数据采集：底层通信层周期读取空调机组送来的状态字，包括“机组可用”“当前车厢温度”“故障标志”；同时采集司机室设定的目标温度。假设采集周期为200ms，温度原始值为0.5℃分辨率。

逻辑处理：应用软件按控制策略计算，例如“当车厢温度高于目标温度2℃且机组可用无故障时，请求制冷”。这里涉及阈值判断、延时确认（如持续5s满足条件才动作）和互锁条件（如制冷与制热不同时输出）。

显示与记录：处理结果一方面送到HMI，显示当前温度、目标温度、机组状态；另一方面写入事件记录，例如“10:32:15 触发制冷请求”。记录的意义在于事后复盘控制动作是否合理。

控制输出：应用软件把“制冷请求”写入输出变量，底层通信层将其打包成报文发给空调控制单元，或通过数字量输出驱动相关继电器。输出后还需回读确认，形成闭环。

四、关键变量与接口概念

在TCMS工程中，变量不是随手起的名字，而是有明确属性的接口对象。常见属性包括：

• 变量名与含义：应能自解释，如 Traction_Enable、Door_Closed_Locked，避免使用含义模糊的缩写。
• 数据类型与量纲：布尔、整型、浮点；温度是0.5℃分辨率还是0.1℃，必须与发布方一致，否则会出现“显示温度偏差一倍”的典型问题。
• 方向：输入（本单元接收）、输出（本单元发送）、内部变量。方向搞反会导致逻辑永远不动作。
• 周期与超时：周期决定刷新快慢，超时决定失效判定。控制类变量周期通常较短，状态监视类可适当放宽。
• 有效范围与默认值：超时或越界时用什么值参与逻辑，必须事先定义。

接口概念上还要区分“物理接口”和“逻辑接口”。物理接口是端口、连接器、总线介质；逻辑接口是变量表、报文格式、数据字典。排查问题时，先确认物理链路是否正常（端口指示灯、总线终端电阻），再确认逻辑接口是否匹配（变量名、字节序、缩放系数）。很多“数据对不上”的问题，根源在缩放系数或字节序，而不是逻辑本身。

五、一个可操作的排查思路

当HMI显示某子系统状态异常时，可以沿链路自下而上逐段确认：先看底层通信层的该变量是否在刷新、是否超时；再看应用软件层读取到的值是否与原始值一致（排除缩放和字节序问题）；然后看逻辑判断条件是否满足；最后看输出变量是否真正发出并被回读。把这条链路走一遍，大多数“显示不对、控制不动”的问题都能定位到具体层，而不是在应用逻辑里反复改代码。

掌握本节的分层结构、主链路方向和变量接口属性后，后续学习具体子系统报文、故障诊断和HMI组态时，就能清楚每个数据“从哪来、经过谁、到哪去”，为读懂更复杂的TCMS功能打下基础。