7.23事故原因基本明了——安全被效率打败的又一个例子

以下分析基于官方公布原事故原因
http://bbs.ourail.com/thread-126260-1-1.html

因天气因素，7月23日晚上，永嘉——温州南之间的某一条或某几条区间轨道电路出现故障，温州南的列控中心读取了两站之间的多条区间轨道电路的信息，未作深度检查、判断、校验，将其当作正确的信息进行计算并按结果点灯控车，于是给后车发出了绿灯，导致追尾事故的发生。

问题就出在这里：当某一条或某几条区间轨道电路故障后，传给列控中心的信息必然是存在矛盾的，逻辑上不一致的。这种情况下，如果列控中心没有检测到这些逻辑不一致，或检测到了但无视之，那么计算结果就可能包含了错误，甚至可能导致发生危险。
有人要问了，既有线C0和C2跑了很多年，怎么很少发生这种情况？我是这么看的，既有线多条相邻轨道电路之间通过继电器和收发码实现点灯计算，算法固化在电路当中，目前来看是成熟的，除非通过人为跳线改变电路来改变算法和结果（规章明令禁止），否则是没有问题的。而客专C2不同，客专C2取消了区间轨道电路之间的继电器等电路，改由列控中心计算机来实现计算和点灯，算法体现在列控中心计算机的软件中。软件代替了固化的硬件，可以实现更加复杂的逻辑判断，也可以更灵活的进行更改，这一方面是好事儿，可以更方便的进行控制，另一方面也是坏事儿，太容易改动就造成了算法受人的影响更大，将人的失误无意识的带进去。

由于轨道电路经常出故障，如果对输入列控中心的轨道电路信息进行严格检查、判断、校验，那么发生故障时多处矛盾的轨道电路信息就无法通过列控中心的检查、判断、校验，那么列控中心就会自动导向安全——点起红灯，让线路停止运行。如果频繁出现这种状况，会极大的影响运输效率，让乘客感到不满与，让领导也感到不满意，然而不幸的是，轨道电路的故障率无法降低，那么只好从列控中心的算法入手，放宽对输入的轨道电路信息的逻辑一致性的限制，减弱检查、判断、校验的强度，将某些看起来危险性不大的轨道电路信息组合视为安全状态，于是列控中心不轻易导向安全了，线路停运的次数减少了，运输效率上去了，乘客、领导都开心了。谁知道，7月23日晚上，轨道电路再次出现故障，该故障产生的轨道电路信息通过了列控中心校验，系统没有导向安全，于是发生了事故。

7月24日，铁路局和通号公司很快查明出原因，针对故障时这种轨道电路信息的组合，增加了特别的判断和校验，使得列控中心导向安全。通号很快发布了软件，并升级到同类车站的列控中心当中，于是动车又开始欢快的跑起来了。
你说，这是编写轨道电路信息检查、判断、校验算法的程序员的错吗？我觉得也不能完全这么说，他本可以采用更加严格的检查、判断、校验，但如果导致频繁停运，乘客必然会发怒，领导必定会干涉，要求提高运输效率，提高列车准点率，于是他只好放宽校验限制。虽然领导是出于一片好心，但无人能评估放宽校验限制后，有多大的概率会遇到危险。这里，安全屈服于效率，最终酿成了事故。
现在列控中心升级后的软件肯定加强了这种检查、判断、校验，但有用吗？我不知道，如果非常严格，那么安全是没问题的，只是正点率又无法保证了，如果不是非常严格，那么还是存在发生事故的概率，尽管很小。
所以我们看到，千错万错，还是轨道电路的错。如果输入信息给列控中心的轨道电路能更可靠一些，不要总出故障，那么列控中心的检查、判断、校验算法就可以做的很严格，偶尔轨道电路的故障导致列控中心导向安全，线路停运，影响也不是很大。可惜，自2002年5月决定大规模推广ZPW2000以来，近十年了，轨道电路的可靠性依然无法大幅提高，这就是摆在面前的现实。

以下分析基于官方公布原事故原因
http://bbs.ourail.com/thread-126260-1-1.html

因天气因素，7月23日晚上，永嘉——温州南之间的某一条或某几条区间轨道电路出现故障，温州南的列控中心读取了两站之间的多条区间轨道电路的信息，未作深度检查、判断、校验，将其当作正确的信息进行计算并按结果点灯控车，于是给后车发出了绿灯，导致追尾事故的发生。

问题就出在这里：当某一条或某几条区间轨道电路故障后，传给列控中心的信息必然是存在矛盾的，逻辑上不一致的。这种情况下，如果列控中心没有检测到这些逻辑不一致，或检测到了但无视之，那么计算结果就可能包含了错误，甚至可能导致发生危险。
有人要问了，既有线C0和C2跑了很多年，怎么很少发生这种情况？我是这么看的，既有线多条相邻轨道电路之间通过继电器和收发码实现点灯计算，算法固化在电路当中，目前来看是成熟的，除非通过人为跳线改变电路来改变算法和结果（规章明令禁止），否则是没有问题的。而客专C2不同，客专C2取消了区间轨道电路之间的继电器等电路，改由列控中心计算机来实现计算和点灯，算法体现在列控中心计算机的软件中。软件代替了固化的硬件，可以实现更加复杂的逻辑判断，也可以更灵活的进行更改，这一方面是好事儿，可以更方便的进行控制，另一方面也是坏事儿，太容易改动就造成了算法受人的影响更大，将人的失误无意识的带进去。

由于轨道电路经常出故障，如果对输入列控中心的轨道电路信息进行严格检查、判断、校验，那么发生故障时多处矛盾的轨道电路信息就无法通过列控中心的检查、判断、校验，那么列控中心就会自动导向安全——点起红灯，让线路停止运行。如果频繁出现这种状况，会极大的影响运输效率，让乘客感到不满与，让领导也感到不满意，然而不幸的是，轨道电路的故障率无法降低，那么只好从列控中心的算法入手，放宽对输入的轨道电路信息的逻辑一致性的限制，减弱检查、判断、校验的强度，将某些看起来危险性不大的轨道电路信息组合视为安全状态，于是列控中心不轻易导向安全了，线路停运的次数减少了，运输效率上去了，乘客、领导都开心了。谁知道，7月23日晚上，轨道电路再次出现故障，该故障产生的轨道电路信息通过了列控中心校验，系统没有导向安全，于是发生了事故。

7月24日，铁路局和通号公司很快查明出原因，针对故障时这种轨道电路信息的组合，增加了特别的判断和校验，使得列控中心导向安全。通号很快发布了软件，并升级到同类车站的列控中心当中，于是动车又开始欢快的跑起来了。
你说，这是编写轨道电路信息检查、判断、校验算法的程序员的错吗？我觉得也不能完全这么说，他本可以采用更加严格的检查、判断、校验，但如果导致频繁停运，乘客必然会发怒，领导必定会干涉，要求提高运输效率，提高列车准点率，于是他只好放宽校验限制。虽然领导是出于一片好心，但无人能评估放宽校验限制后，有多大的概率会遇到危险。这里，安全屈服于效率，最终酿成了事故。
现在列控中心升级后的软件肯定加强了这种检查、判断、校验，但有用吗？我不知道，如果非常严格，那么安全是没问题的，只是正点率又无法保证了，如果不是非常严格，那么还是存在发生事故的概率，尽管很小。
所以我们看到，千错万错，还是轨道电路的错。如果输入信息给列控中心的轨道电路能更可靠一些，不要总出故障，那么列控中心的检查、判断、校验算法就可以做的很严格，偶尔轨道电路的故障导致列控中心导向安全，线路停运，影响也不是很大。可惜，自2002年5月决定大规模推广ZPW2000以来，近十年了，轨道电路的可靠性依然无法大幅提高，这就是摆在面前的现实。