从软件设计的角度看动车出轨事故

2011年7月23日20点34分，杭深线永嘉至温州南间，北京南至福州的D301次动车与杭州至福州南的D3115次动车，发生追尾事故，6节车厢脱轨，至少两节掉落高架，截止到24号凌晨2：50分，事故已造成32人死亡，171人受伤。

到目前为止我们所知道的原因是：D3115次动车遭遇雷击之后失去动力，在缓慢行驶的过程中，被后上的D301次动车追尾撞上，导致列车脱轨多节车厢翻落铁路高架。

抛开雷击、设备质量、调度管理人员等方面的因素不谈，从软件设计的角度来看，我们应该可以避免这种悲剧的发生。

列车和各地的调度中心通过网络同步，可以彼此确认所有的故障点和车辆行使情况。列车运行时，车辆间隔的时间至少超过2分钟以上，即3-10公里，而中国铁线路不超过10万公里，同时运行的列车怎么也不会超过3万个。即使以20年前的设备性能来看，都有足够的能力实施全线路的实时信息化。任何一个节点或是列车需要实施上传各自的状态信息，如果每3秒一次，3次信息丢失则确认为故障的话，系统可以在9秒之内确认发生故障，然后通知故障节点（列车）的后续列车减速并逐步停止运行。而如果一个列车在9秒内确认自己无法和系统通讯，则自动减速停车。

如何确认故障？这个不能采用通常的网络通讯方案，即简单的向对方发送信息，对方只要收到就认为没有故障。这种设计方案的缺点是如果网络退化到半双工工作状态，即单向可通讯的时候，一方可能认为对方没有故障，但是对方却不这么认为。比如列车向调度中心发送工作信息，调度中心收到了，认为列车运行正常，而调度中心给列车发送的信息，列车并未收到，则列车确认故障并逐步停车，会导致后方的列车追尾。在需要较高可靠性的领域，我们可以采用这种方法：每次发送信息的时候，需要携带上次对方发送信息的cookie，这样可以尽快的诊断到是否出现单通的问题。

为了防止调度中心过于拥堵（如果有100万个节点加3万列车，每3秒发送256字节，则平均每秒88Mbytes），或调度中心出现了故障导致全国列车停止运行，调度应该设计为分网独立运行。每个网络只覆盖附近若干公里区域即可。调度中心无需设计为级联式的控制结构，否则根节点故障会导致所有下属控制节点失效。各个调度中心可以采用协作的方式，一辆运行的列车同时和附近的所有调度中心通讯。除了在某些特别的交叉区域可能会出现需要和2、3个调度中心通讯的情况，一般来说列车只需和1个调度中心同步即可，因此并不会带来额外的通讯负担。

简单来说，合理的设计方案，完全可以避免列车追尾、相撞这种事故的发生，这是最容易控制，最不应该发生的事故。

题外话：

我们很难有合理的设计方案，甚至很难有一个“完整”的、“系统化”的设计方案。由于铁路涉及到国家安全，我们不可能让一两家外企去部署整个系统的信息化解决方案。实际工程往往是七国八制、层层转包，在这种指导思路下，一个可靠的，完整的信息化解决方案，不知道在哪一天才会出现。