信号系统"云化"革命：当列车控制从车站机房搬进云端(信号与系统系列科普)

你有没有走进过地铁站的设备机房？

一排排铁柜子嗡嗡作响，风扇转个不停，指示灯闪烁不停。每个车站都有这么一间屋子，里面塞满了联锁设备、区域控制器、服务器、交换机——少说几十台，多则上百台。它们是列车安全运行的大脑，每一条进路的排列、每一列车的速度防护，都从这些柜子里发出指令。

这套架构运行了几十年，稳定、可靠、经过充分验证。但你有没有想过一个问题：一座城市几十条线路、几百个车站，每个站都堆一套几乎一模一样的设备，这到底是在保障安全，还是在制造冗余？

2026年8月中旬，中国城市轨道交通协会标准认证部在北京组织了一场"信号系统云化技术专题座谈研讨会"。来自北京、上海、杭州、青岛等地的行业专家，以及城轨企业、科研院校、设计单位和装备制造商的代表坐到了一起。会议讨论的核心问题只有一个——信号系统，能不能上云？

这个问题，看似技术问题，实则牵动着整个城轨行业未来十年的走向。

先说一个大家心知肚明但很少摊开讲的事实。

传统CBTC信号系统采用"站级分散部署"——每个集中站配置独立机房、独立服务器、独立网络、独立供电和散热。这套架构的逻辑很清楚：信号系统涉及行车安全，必须就近部署、就近控制，减少通信链路带来的不确定性。

逻辑没问题。但代价是什么？

拿一个标准地铁站举例。一套完整的联锁设备加区域控制器，硬件投资动辄数百万。一个城市如果有200个车站，光信号系统的硬件堆叠就是一笔天文数字。更关键的是，这些设备的平均利用率并不高——有行业研究指出，传统架构下服务器CPU利用率长期徘徊在10%到20%之间。剩下的算力，就这么空转着，消耗着电力，占据着机房空间。

这像什么？像每家每户都自建一个发电厂。能用吗？能。有必要吗？未必。

2020年3月，中国城市轨道交通协会发布《中国城市轨道交通智慧城轨建设纲要》，首次以行业顶层设计的形式提出"城轨云"概念。2026年4月，协会又发布了修订版V2.0，将"1-8-1-1"架构写进了未来十年的发展蓝图——一张蓝图、八大智能体系、一个城轨云数智融合平台、一套自主技术标准体系。纲要明确提出，到2035年城轨云数智平台要实现100%覆盖。

可问题来了。综合监控、乘客信息、自动售检票这些管理系统上云，行业已经趟出了路——近年来80%以上的新建线路业务上云，线网运营指挥中心（XOCC）更是100%采用云化方式建设。但信号系统呢？它可是SIL4安全等级的"安全苛求系统"，列车能不能安全跑、能不能精准停，全靠它。

管理系统上云是锦上添花，信号系统上云是动心脏。

心脏能动吗？

信号系统上云，难在哪？行业里讨论了很多年，总结下来主要是三道坎。

第一道坎：实时性。

列车运行控制对时延的要求极其苛刻。车地通信时延要求在100毫秒以内，车车通信要求低于5毫秒。传统架构下，控制逻辑在车站本地完成，物理距离近，响应快。一旦搬到云端，控制指令要从中心机房经过传输网络到达车站，再下发到轨旁设备和车载设备。链路变长了，任何一个环节的抖动都可能导致通信超时。

这不是理论上的担忧。城轨业务云化后，南北向流量（中心到车站）占到总带宽的70%以上。如果信号系统的控制指令要和视频监控、乘客信息等业务共享带宽，怎么保证确定性时延？

第二道坎：安全认证。

城轨信号系统的安全完整性等级是SIL4——这是功能安全的最高等级。按照EN 50716（EN 50128的最新修订版）和EN 50129等国际标准的要求，SIL4级软件的开发流程、测试验证、质量保证都有极其严格的规定。

传统的物理隔离架构，安全边界清晰——每个车站的设备是独立的，一个站出问题不影响其他站。但上云之后呢？多个安全等级不同的业务跑在同一套物理资源上，虚拟化层本身的隔离性够不够强？一个虚拟机的故障会不会波及另一个？这些都是安全认证需要回答的新问题。

业内有专家说得直白："信号上不上云，本质上不是技术能不能做的问题，而是云平台的安全性能不能被认证机构认可的问题。"

第三道坎：冗余与可用性。

传统信号系统采用"二乘二取二"或"三取二"的冗余架构，硬件层面做到极致。上云之后，冗余逻辑变了——从硬件冗余变成虚拟化冗余、从物理备份变成快照迁移。这种架构下的故障切换时间够不够短？恢复机制够不够可靠？

有人说，云计算厂商不是天天喊"五个九"（99.999%）的可用性吗？可那是IT系统的标准。信号系统的可用性要求不一样——它不是服务中断了刷新一下页面就行，它是列车停在隧道里、乘客被困在车厢里的安全问题。

三道坎摆在那里，但行业并没有停下脚步。

事实上，信号系统上云这件事，技术路径正在逐渐清晰。

首先，架构层面，并非简单地把信号系统搬到传统IT云上。行业正在探索的是面向安全关键场景的专用云化平台——采用Type-1裸机虚拟化技术，虚拟化层直接运行在硬件之上，减少宿主操作系统带来的额外开销和调度不确定性。这种架构的特点是微秒级调度延迟、强隔离、低攻击面，专门为轨道交通、工业控制这类对实时性和安全性要求极高的场景设计。部分平台已计划于2026年通过EN 50716功能安全认证，这意味着虚拟化层本身将获得SIL4级的安全背书。

其次，部署模式上，不是"非此即彼"。行业正在形成"中心云+边缘云"的两层架构共识。控制逻辑的核心部分集中到中心云平台，而对实时性要求极高的安全防护功能则保留在边缘节点——也就是车站侧的轻量化计算平台上。这种"云边协同"的模式，既实现了资源集约化，又没有牺牲安全底线。

再看通信网络。过去几年，城轨行业在5G、TSN（时间敏感网络）等技术上的投入，正在为信号上云铺路。TSN技术可以实现多业务数据在同一条网络上的确定性传输，保证信号控制指令的优先级和时延不受其他业务干扰。简单说，就是在同一条"高速公路"上，给信号系统开辟了一条专属车道。

还有一个容易被忽视的变化——信号系统本身的架构也在"瘦"。

从第三代CBTC到第四代FAO（全自动运行），再到第五代VBTC（基于车车通信的列车控制系统），信号系统的演进方向一直是"精简轨旁设备、增强车载智能"。VBTC把大量轨旁设备的功能分散到列车上，实现列车间的直接"对话"，后车能获取前车的状态信息并自主调节速度。这意味着，需要部署在车站机房里的设备本就在减少。设备少了，上云的难度自然降低了。

打个比方：以前是把一整座工厂搬上云端，现在只需要搬一间办公室。

谈到这里，有一个绕不开的话题——标准。

你可能觉得标准离自己很远，是行业专家开会讨论的东西。但说实话，标准才是决定信号系统上云能不能真正落地的"最后一公里"。

为什么？因为没有标准，就没有验收依据。

一个信号厂商开发了一套云化信号系统，技术指标很好看，演示也很流畅。但地铁公司敢用吗？运营方敢验收吗？监管部门敢放行吗？没有标准，这些问题都没有答案。

2025年11月，中国城市轨道交通协会通信信号分技术委员会（SC15）启动了《城市轨道交通 信号系统改造 技术规范》团体标准的编制工作。2026年4月，协会又就CBTC信号系统测试方法的五项团体标准公开征求意见。这些标准的密集出台，背后是一个明确的信号——行业正在从"做产品"转向"立规矩"。

信号系统上云同样需要标准。在8月中旬的那场研讨会上，与会代表在标准建设方面达成了几项共识：

一是信号上云需要明确的定义，避免歧义；

二是标准可以分阶段推进，先对原则性、程序性内容形成基本约束；

三是要研究借鉴国际相关标准，同时厘清与现有规范的融合边界。

协会标准认证部主任任健在总结发言中提出了三个方向：严守安全底线、深化产学研用协同、加快团体标准编制。翻译成大白话：先画红线，再建通道，最后立规矩。

有人可能要问：为什么是团体标准先行，而不是直接上国家标准？

这其实是行业的一个务实选择。信号系统云化还在探索阶段，技术路线尚未完全收敛。团体标准的优势在于灵活、快速，可以在实践中迭代完善，等到技术成熟、路径清晰之后，再上升为行业标准乃至国家标准。这种"团标先行、行标跟进、国标兜底"的路径，在城轨行业已经有成熟的经验。

回到文章开头的问题：信号系统能不能上云？

我的判断是——能，但不是今天，也不是明天。

这不是一个非黑即白的技术命题。信号系统上云不是一个"开关"，按下去就完成了。它是一个渐进的过程：先上非安全苛求的部分（监测、诊断、运维），再上安全等级较低的部分（ATS、ATO），最后才轮到SIL4级的核心控制逻辑。每一步都需要技术验证、安全认证和标准支撑。

有人可能会失望——这也太慢了。但我想说，信号系统控制的是满载乘客的列车。快，从来不是这个行业的第一优先级。

19世纪中叶，英国的铁路工程师们为了统一轨距争论了二十年。今天回头看，那二十年的"慢"，换来了英国铁路网百年安全运行的"稳"。信号系统上云也是同样的道理。

而且，慢不代表没进展。2020年呼和浩特地铁率先实现城轨云平台落地运营，到今天全国已有26座城市完成或在建城轨云项目。2026年发布的智慧城轨发展纲要V2.0，把城轨云数智融合平台写进了"1-8-1-1"架构的核心位置。信号系统上云的技术储备、标准体系、产业生态，都在加速成熟。

更重要的变化是心态。过去行业讨论信号上云，第一反应是"不可能"。现在讨论的焦点已经变成了"怎么才能做到"。从"不可能"到"怎么才能"，这本身就是最大的进展。

中国城轨信号系统的发展史，说白了就是一部不断"打脸"的历史。

2010年前后，CBTC核心技术被国外厂商牢牢攥在手里，行业里弥漫着一种"中国人自己搞不出来"的氛围。结果呢？交控科技率先突破，众合科技、中国通号相继跟上。到了FAO阶段，中国已经和国际巨头站在同一条起跑线上。再往后VBTC、AVCOS，中国厂商反而跑到了前面。

从跟跑、并跑到领跑，每一步都伴随着质疑。

信号系统上云，不过是这条路上的下一个节点。

但我想提醒的是，这个节点和之前的每一个都不一样。之前的每一次技术迭代，改变的是信号系统本身——架构更先进、功能更强大。而"上云"改变的是整个行业的底层逻辑——从分布式部署到集中化管控，从硬件堆叠到软件定义，从各自为战到统一平台。

这种变革的深度，远超技术本身。它需要标准体系的重构，需要安全认证体系的更新，需要运维模式的变革，需要产业链的重新洗牌。每一样都不是一两年能搞定的事。

所以，与其问"信号系统能不能上云"，不如换一个问题：

当信号系统的控制逻辑从车站机房搬进云端的那一天，我们的标准、认证、运维和产业链，准备好了吗？