时速 350 公里的高铁，最怕出错的竟然不是刹车片？

本文来自微信公众号： 宇众不同的露萱 ，作者：宇众不同的露萱，原文标题：《时速 350 公里的高铁，最怕出错的竟然不是刹车片？》

如果把时速350公里的复兴号比作一把飞在钢轨上的重型武器，那留给司机反应的时间，其实是零。

在这个速度下，列车每秒钟就要向前狂飙将近100米。

你可能在电视上见过高铁驾驶室的画面：司机端坐在台前，眼神坚毅，偶尔伸手按压一下警惕按钮。

但后来我找做列控系统的老工程师聊过才明白，很多人都误会了——在今天的高铁上，司机的眼睛和手，根本不是第一道安全线，甚至连刹车的主导权都不在他手里。

如果前面的轨道上突然掉落了异物，或者两车距离靠得太近，根本不等司机抬手踩刹车，整台列车就已经被系统强行锁死，在几公里外开始急停。

把这几百吨重的庞然大物、以及上面上千名乘客的生死死死卡住的，并不是什么神奇的机械机械闸，而是一套挂在机箱里、二十多年前就开始写的工业软件。

更离奇的是，这套代码的编写逻辑，和我们今天做互联网、做App的思路完全相反。

互联网代码讲究的是“出错了赶快重试”；

而这套控制高铁的代码，第一条铁律却是：“只要我觉得自己可能要出错了，我必须立刻主动把系统搞瘫痪。”

事情得从很久以前的绿皮车时代说起。

以前的火车怎么跑？靠看信号灯。

轨旁立个路灯，红灯停，绿灯行。两列火车之间，必须隔着几公里的固定铁路线，这段铁路线叫“闭塞分区”。前一列车没走出这个分区，后一列车绝对不许进去。

这叫“固定闭塞”。

笨是笨了点，但很直观。可等到了高铁时代，这套玩不转了。

时速350公里，刹车距离动辄三四公里。如果还靠司机用肉眼去瞅几百米外的路灯，等他看清红灯的那一瞬间，车早就过界了。

更要命的是，如果分区定得太长，轨道利用率低得让人吐血；如果分区定得太短，后面车一不小心就会追尾。

“怎么办？把信号灯拆了，把轨旁机械锁拆了。”

几十年前，一群搞列控软件的工程师提出了一个在当时听起来像天方夜谭的想法：把信号灯直接搬到驾驶舱的电脑屏幕上，甚至——让信号灯自己会跑。

这就是后来的移动闭塞（Moving Block）与ATP（列车超速防护系统）。

写这套软件的程序员，做了一件极其疯狂的事。

他们在每辆列车的车轮上装上测速雷达和编码器，在轨道底下埋上应答器。列车每往前跑一米，车载计算机就在实时计算自己的位置、速度、刹车曲线。

随后，这台车会通过专用的无线网络，把自己的数据扔给地面控制中心。

控制中心拿到前后所有车的实时位置后，在软件里给每一列车实时画出一个“透明泡泡”。

这个“泡泡”的前端，叫移动授权（MA）；“泡泡”的后端，叫危险点。

前车的屁股在哪里，后车那个“透明泡泡”的终点就在哪里。

后车跟着前车跑，前车加速，“泡泡”就变大，允许后车开快点；前车减速，“泡泡”瞬间缩短，后车如果不跟着减速，车载ATP软件会直接越过司机，强行拉动电空制动！

以前是车找灯，现在是灯跟着车跑。

这直接把铁路的运输效率提了整整三倍。

但看到这里，你可能会起一身鸡皮疙瘩：

把几百吨重、时速三百多公里的铁疙瘩，完全托付给一段跑在无线网络里的代码？

万一软件卡死怎么办？

万一内存泄漏了怎么办？

万一无线信号断了半秒钟怎么办？

互联网公司服务器宕机，最多是页面打不开、用户骂两句；

高铁控制软件要是卡死了一毫秒，那可能就是惨绝人寰的悲剧。

老工程师告诉我，当年他们刚开始写这种系统时，每天晚上做梦都是代码越界。为了防止软件“作妖”，他们引入了一套在软件工程里近乎变态的哲学——Fail-Safe（故障导向安全）。

什么意思？

在我们平时写代码的逻辑里，如果一个接口调用失败了，常见的做法是：捕获异常，重试三次，或者降级返回一个空数据，尽量保证服务“别崩”。

但高铁列控代码不行。

在Fail-Safe哲学里，任何未知的状态，都被等同于危险。

如果无线网络丢包超过预设阀值，软件不会去“顽强重试”，而是认为通信被截断，瞬间触发最高级别的紧急制动（EB）；

如果测速雷达的数据出现了一丝矛盾，软件不会去“猜测哪个是对的”，而是直接判定速度异常，停车；

甚至，如果负责计算的两台计算机得出的结果不一样，它们不会去“少数服从多数”，而是两台机器同时切断输出，再次停车！

简而言之：我不允许自己有任何“不确定”的时刻。我只要有一丝丝怀疑自己可能出错了，我就立刻把车停下。

宁可把乘客颠醒、宁可让整条线路延误，也绝不带病往前跑一厘米。

“把最坏的情况当成默认情况”，这是工业级代码对物理世界最死板、但也最沉重的敬畏。

而且，你以为这套代码是跑在什么高性能服务器上的吗？

说出来你可能不信。

在很多列控系统的核心机箱里，跑着的CPU性能可能还不如你十年前买的一款低端智能手机。

因为在工业控制领域，大家根本不追求“算得有多快”，大家近乎病态地追求“可预测”。

现在的消费级CPU，为了追求速度，加了各种乱序执行、分支预测、多级缓存。这些在普通人眼里是黑科技，但在列控工程师眼里全是噩梦——因为它们带来了“不确定性”。

他们宁可用极为古老、架构极简单、被验证过千百万次无误的处理器，跑着最简洁的实时操作系统（RTOS）。

不仅如此，机箱里通常不是一台电脑在跑，而是三台。

这就是经典的三取二（2-out-of-3）硬件冗余架构。

三台一模一样的计算机，跑着一模一样的逻辑，处理一模一样的传感器数据。

每算出一组刹车指令，三台机器必须进行“投票”。如果机器A算出来的结果和B、C不一样，机器A会瞬间被硬件逻辑直接剥夺控制权，并被踢出系统，由另外两台继续维持运转，同时向地面报警。

你以为这就完事了？

有些极其变态的安全等级系统，甚至要求这三台机器的芯片不能来自同一个厂家，代码不能由同一组程序员编写！

为的就是防止同一个编译器Bug，或者同一个芯片物理缺陷，同时毁掉所有备份。

后来我查资料才发现，今天我们习以为常的“坐着高铁半天跨越大半个中国”，背后竟然悬挂着这么一套近乎偏执的软件工程体系。

它没有炫酷的UI界面，没有动辄几百亿参数的大模型，甚至连代码量都少得可怜。

但它却在毫无声息的毫秒碰撞中，把物理世界的惯性、摩擦力、加速度，以及最不可控的人性，全部用死板的逻辑锁在安全线之内。

当你在350公里时速的列车上安然喝着咖啡，看着窗外飞速倒退的风景时，在车头下方那个冰冷的机箱里，正有几台计算机在以每秒几百次的频率，疯狂地进行着投票与自我怀疑。

它们随时准备着，为了你的安全，按下那个让整个系统轰然停下的开关。