一次GSM-R故障，看局部异常如何拖垮复杂铁路系统

​2026年6月23日晚，德国铁路经历了一场罕见的大规模停运。当天，德国铁路用于列车司机与控制中心通信的GSM-R数字铁路通信系统发生全国性故障。出于安全考虑，客运列车被要求停靠在车站，货运列车暂停运行，全国铁路运输一度陷入停滞。经过两个多小时的紧急处理，列车才逐步恢复运行。

 

▲2026年6月23日，德国慕尼黑中央火车站，两列火车并排停靠

GSM-R即铁路全球移动通信系统，是专门用于铁路运营的移动通信系统，承担列车司机与调度员之间的语音通信，以及运行指令、安全信息和故障情况传输等任务。虽然这一系统基于2G移动通信技术，但长期以来一直以稳定可靠著称。如今，GSM-R已经成为欧洲铁路运行的重要基础设施，一旦通信中断，列车运行安全也会受到直接影响。

 

▲GSM-R铁路通信系统工作示意图

 

后续调查显示，问题与GSM-R系统核心组件的一次计划性更换有关。在更换网络交换设备后，系统出现软件错误，而原本应触发备用系统切换的自动故障告警没有正常出现，导致备用系统未能及时接管，需要在完成进一步排查后人工切换。这场故障再次提醒人们：随着软件与硬件、通信网络及控制系统的耦合不断加深，一个局部软件异常，也可能沿着系统关联迅速扩散，最终演变为系统级影响。

当下的轨道交通系统，本质上已经是一个由大量软硬件共同组成的复杂信息物理系统。一列现代列车内部，牵引、制动、车门、通信、信号、列车控制、故障诊断等功能背后，都运行着复杂的嵌入式软件。列车之外，还有地面控制中心、通信网络、联锁设备、轨旁设备以及其他列车共同参与系统运行。

但这些系统并不是彼此独立的：一条通信链路的中断，可能造成状态信息无法及时上传；一个控制节点的异常，可能影响其他设备的判断；一项软件更新，可能改变原有的数据交换关系；一个本应被检测到的错误，如果没有触发预定的处理流程，还可能沿着系统之间的关联不断扩散。此次德国铁路故障中，真正值得关注的也正是这一点。因此，最关键的问题是：当通信系统和其他软件、处理器、传感器以及控制节点连接起来之后，系统是否仍然能够按照设计运行？

传统软件测试通常从正常功能开始：输入一组数据，查看输出是否正确；执行一个操作，判断软件是否完成预期功能。这类测试当然重要，但对于轨道交通、航空航天、汽车电子等安全关键领域的嵌入式系统而言，仅验证正常情况下能够运行远远不够，还需要面对大量异常问题。比如，通信延迟、节点掉线、数据重复发送或主备切换异常，单独看可能只是一次超时或通信错误，但在完整系统中，却可能沿着多个节点、处理器和通信链路不断传递。最终导致系统异常的，往往不是某一个明显错误，而是特定时间、状态和数据组合共同作用的结果。

但这些异常并不容易在真实设备上进行充分验证。一方面，复杂装备研制过程中，软件开发与硬件研制往往并行推进，真实处理器、控制器或完整系统可能尚未到位，大量软件测试只能等待硬件条件成熟后再开展。另一方面，很多异常场景本身就难以主动制造。通信中断、数据延迟、设备异常、节点掉线等问题，很难在真实系统中按照指定时间、指定状态反复触发，大量时间因此被消耗在故障复现上。

因此，越来越多的嵌入式软件验证工作开始向数字环境前移。通过对处理器、外设、总线和其他关键硬件进行数字化建模，工程人员可以在真实硬件尚未完全具备之前，提前构建能够运行目标软件的虚拟环境，并开展软件开发、调试和测试。

天目全数字实时仿真软件SkyEye正是面向复杂嵌入式软件开发与验证需求的工具。SkyEye通过对处理器、外设、总线及其他硬件资源进行数字化建模，构建可运行真实目标软件的虚拟硬件环境，使软件能够摆脱对真实硬件的完全依赖，提前开展开发、调试和测试。

 

▲SkyEye界面图

 工程人员可以基于SkyEye观察处理器运行、外设访问和通信交互过程，并根据测试需求构造不同异常场景。对于涉及多个处理器、控制节点和通信网络的复杂系统，还可以进一步开展多节点协同验证，分析局部异常发生后其他软件和系统功能的响应过程。

2023年2月，基于SkyEye的仿真控制器已在上海地铁3号、4号线的改造项目中成功落地试运行，研发人员得以在真实OC硬件未制造时提前验证OC系统的硬件设计、软件功能和系统性能，在发现设计缺陷后及时优化，减少了产品研发的迭代次数，将研发时间从半年缩短至2个月左右，节省了大量的资源投入。

随着轨道交通等复杂装备持续向数字化、智能化发展，软件规模还将继续增长，系统之间的联系也会更加紧密。软件验证需要关注的，也不再只是某项功能是否正确，而是当异常真正发生时，整个系统能否按照设计完成检测、响应、切换和恢复。​