博文
温州动车追尾事故两个月（110923）
精选
||
温州动车追尾事故两个月（110923）
闵应骅
723温州动车追尾事故到今天，整整两个月了。昨天，由于一位网友的博文，引导我看到“新世纪周刊 723动车追尾事故怎样祸起信号"(http://tech.sina.com.cn/t/2011-08-29/12155994259.shtml)。这篇1万1千多字的长文使我自认为事故原因已经搞清楚了，与两月来事态的发展相符合，即使是最后的调查报告出来，可能也不会有如此详实。本人认为的结论如下：
1.从技术层面讲，主要有两个问题：
①系统设计未能做到故障-安全(fail-safe)
站与站之间被分成若干闭塞分区。每个闭塞分区的长度为1.4公里。用无绝缘轨道电路区别列车的占用与空闲。每段分区一次只允许一趟列车通行。它后面的灯是一个红灯。紧接着的一个闭塞分区是黄灯，其次是黄绿灯，再后面才能是绿灯。而轨道电路的占用信息要通过信号采集、应答器才能传给司机、传到车上。这样长的信号通路，其中如果某环节故障，都可能丢失信息。而对于列车占用这样重要的信息，如果丢失，就会造成严重事故。这是不符合故障-安全原则的。应该是轨道电路占用信息可以直接控制后面的红灯，并令后续列车制动，不需要经过调度中心，无条件执行。
②列控中心产品LKD2-T1的信息采集板软件可靠性不高
采集板的采集电源被雷击坏，但逻辑电源仍在，老的区间空闲数据一直保持。这就让成大错。正确的做法应该是动态地不间断地采集轨道继电器节点信息，既要采集上节点的信息，也要采集相应下接点的信息；而且应该采集两套接点的信息，完全一致以后，才能确认信息无误。这好像是采集了多余的信息。这种信息冗余恰恰是容错技术中保证信息安全可靠的手段，不可或缺的。
2.从管理层面讲，调度、电务人员沟通不够
在系统发生故障以后，车站联锁显示的是红光带，而列控中心反映的是正常。转为非常站控后，调度员、车站值班员、司机信息交流失误是事故最终未能幸免的关键。如果调度中心、车站调度和维修人员能够很快协商一致，还是可以命令后续列出停车的。可惜没有能这样做。7月23日从19时27分至事故发生，温州南站和永嘉站先后三次转为非常站控，主要的行车指挥随之三次转换，造成调度员、车站值班员、司机三方对车所处位置互相沟通错误，并严重违反规定，在前车还未越过区间故障点时，后车就进入了故障区间。
3.从领导层面讲，边科研、边生产的方式不可取
“CTCS2的研发必须跟上提速的进程。试验中出现的所有问题，铁道部都要求专家们必须在极短的时间内解决。2006年底，在铁道部进行的动车组拉通检查和牵引试验中，应答器报文变差引起了列车紧急制动26次，常规制动25次。2007年4月18日铁路第六次大提速开始后，列控车载设备又暴露出设备软件 和应答器信息接收单元不稳定等多种问题。”而列控中心、CTC和车站联锁等CTCS2子系统，于2008年1月通过铁道部组织的可行性审查和技术鉴定，并获得2008年度中国铁道学会科学技术奖一等奖。2008年7月底，全新的客专CTCS2系统在合宁线上第一次应用。这就是说，成果刚得奖，就已经上到线路上去了。这中间，要经过科研-产品-施工设计-施工-测试这么多环节，却逼其功于一役，仓促上马。这使我想起1958年大跃进的时候，所谓“边设计、边施工”，造出了很多“豆腐碴”工程。
从科研到产品，是一个很长的过程。像系统设计、软件可靠性这样的问题都是重大的科学问题。在上世纪八、九十年代，IEEE国际容错计算会议（FTCS）几乎每年都有欧美等国关于铁路信号方面的论文。交流这些论文实际上就是请世界的专家看看他们考虑的铁路信号系统在安全可靠方面是否还有问题。而在我国，不但不到国际学术界去交流，而且，“肥水不流外人田”，把科研经费全投给路内单位，不让路外插手。一个科研项目，不怕别人提问题，就怕有问题，没提出来、没有解决。最后，变成产品就跟你算总帐了。
对于系统测试，绝不能只要表演给领导看了，一切正常就行了。绝不是这样。从设计验证、产品测试、系统联调、到现场测试验收，整套都要讲究故障覆盖率，也就是你检测了多少故障不存在。不是说，只要检查在正常情况下没有问题就行了。
至于合资，我觉得，不能迷信外国，尤其不能迷信外国的铁路信号公司。因为外国没有我们这么发达的铁路，他们也没有很好的成功经验，而且，这些公司在电子、控制技术方面也算不得太权威。我很欣赏西门子的态度：“2007年，中铁建电气化局在承接郑西客运专线四电系统集成时，曾邀请西门子提供技术支持，但被其拒绝，理由之一即是郑西高铁四电系统部件供货商分散在世界各地，“用的是不同国家不同企业的东西，这样的集成我们做不了”。”
以上观点，欢迎批评，也将由后续事态发展来斧正。
关注“温州动车追尾事故”
https://blog.sciencenet.cn/blog-290937-489491.html
上一篇：从温州动车追尾事故想到的(5)（110918）
下一篇：人机和谐（110925）
闵应骅
723温州动车追尾事故到今天，整整两个月了。昨天，由于一位网友的博文，引导我看到“新世纪周刊 723动车追尾事故怎样祸起信号"(http://tech.sina.com.cn/t/2011-08-29/12155994259.shtml)。这篇1万1千多字的长文使我自认为事故原因已经搞清楚了，与两月来事态的发展相符合，即使是最后的调查报告出来，可能也不会有如此详实。本人认为的结论如下：
1.从技术层面讲，主要有两个问题：
①系统设计未能做到故障-安全(fail-safe)
站与站之间被分成若干闭塞分区。每个闭塞分区的长度为1.4公里。用无绝缘轨道电路区别列车的占用与空闲。每段分区一次只允许一趟列车通行。它后面的灯是一个红灯。紧接着的一个闭塞分区是黄灯，其次是黄绿灯，再后面才能是绿灯。而轨道电路的占用信息要通过信号采集、应答器才能传给司机、传到车上。这样长的信号通路，其中如果某环节故障，都可能丢失信息。而对于列车占用这样重要的信息，如果丢失，就会造成严重事故。这是不符合故障-安全原则的。应该是轨道电路占用信息可以直接控制后面的红灯，并令后续列车制动，不需要经过调度中心，无条件执行。
②列控中心产品LKD2-T1的信息采集板软件可靠性不高
采集板的采集电源被雷击坏，但逻辑电源仍在，老的区间空闲数据一直保持。这就让成大错。正确的做法应该是动态地不间断地采集轨道继电器节点信息，既要采集上节点的信息，也要采集相应下接点的信息；而且应该采集两套接点的信息，完全一致以后，才能确认信息无误。这好像是采集了多余的信息。这种信息冗余恰恰是容错技术中保证信息安全可靠的手段，不可或缺的。
2.从管理层面讲，调度、电务人员沟通不够
在系统发生故障以后，车站联锁显示的是红光带，而列控中心反映的是正常。转为非常站控后，调度员、车站值班员、司机信息交流失误是事故最终未能幸免的关键。如果调度中心、车站调度和维修人员能够很快协商一致，还是可以命令后续列出停车的。可惜没有能这样做。7月23日从19时27分至事故发生，温州南站和永嘉站先后三次转为非常站控，主要的行车指挥随之三次转换，造成调度员、车站值班员、司机三方对车所处位置互相沟通错误，并严重违反规定，在前车还未越过区间故障点时，后车就进入了故障区间。
3.从领导层面讲，边科研、边生产的方式不可取
“CTCS2的研发必须跟上提速的进程。试验中出现的所有问题，铁道部都要求专家们必须在极短的时间内解决。2006年底，在铁道部进行的动车组拉通检查和牵引试验中，应答器报文变差引起了列车紧急制动26次，常规制动25次。2007年4月18日铁路第六次大提速开始后，列控车载设备又暴露出设备软件 和应答器信息接收单元不稳定等多种问题。”而列控中心、CTC和车站联锁等CTCS2子系统，于2008年1月通过铁道部组织的可行性审查和技术鉴定，并获得2008年度中国铁道学会科学技术奖一等奖。2008年7月底，全新的客专CTCS2系统在合宁线上第一次应用。这就是说，成果刚得奖，就已经上到线路上去了。这中间，要经过科研-产品-施工设计-施工-测试这么多环节，却逼其功于一役，仓促上马。这使我想起1958年大跃进的时候，所谓“边设计、边施工”，造出了很多“豆腐碴”工程。
从科研到产品，是一个很长的过程。像系统设计、软件可靠性这样的问题都是重大的科学问题。在上世纪八、九十年代，IEEE国际容错计算会议（FTCS）几乎每年都有欧美等国关于铁路信号方面的论文。交流这些论文实际上就是请世界的专家看看他们考虑的铁路信号系统在安全可靠方面是否还有问题。而在我国，不但不到国际学术界去交流，而且，“肥水不流外人田”，把科研经费全投给路内单位，不让路外插手。一个科研项目，不怕别人提问题，就怕有问题，没提出来、没有解决。最后，变成产品就跟你算总帐了。
对于系统测试，绝不能只要表演给领导看了，一切正常就行了。绝不是这样。从设计验证、产品测试、系统联调、到现场测试验收，整套都要讲究故障覆盖率，也就是你检测了多少故障不存在。不是说，只要检查在正常情况下没有问题就行了。
至于合资，我觉得，不能迷信外国，尤其不能迷信外国的铁路信号公司。因为外国没有我们这么发达的铁路，他们也没有很好的成功经验，而且，这些公司在电子、控制技术方面也算不得太权威。我很欣赏西门子的态度：“2007年，中铁建电气化局在承接郑西客运专线四电系统集成时，曾邀请西门子提供技术支持，但被其拒绝，理由之一即是郑西高铁四电系统部件供货商分散在世界各地，“用的是不同国家不同企业的东西，这样的集成我们做不了”。”
以上观点，欢迎批评，也将由后续事态发展来斧正。
关注“温州动车追尾事故”
https://blog.sciencenet.cn/blog-290937-489491.html
上一篇：从温州动车追尾事故想到的(5)（110918）
下一篇：人机和谐（110925）
