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个月左右节省了大量的资源投入。随着轨道交通等复杂装备持续向数字化、智能化发展软件规模还将继续增长系统之间的联系也会更加紧密。软件验证需要关注的也不再只是某项功能是否正确而是当异常真正发生时整个系统能否按照设计完成检测、响应、切换和恢复。