倍可親

中國鐵道部副部長回應動車事故熱點

作者:light12  於 2011-7-31 19:51 發表於 最熱鬧的華人社交網路--貝殼村

通用分類:熱點雜談|已有17評論

中國鐵道部副部長回應動車事故熱點 時間:2011-07-30 23:33:29 來源: 新聞縱橫
 

據中國之聲《新聞縱橫》報道,北京時間30日,鐵道部副部長陸東福接受了中央台記者的採訪,就甬溫線「7·23」事故中公眾關心的熱點問題,進行了回應和解答。

事故發生后,外界有質疑認為:當時鐵路部門為了搶通線路,沒有把救人放在第一位,實際的情況到底怎樣?記者的提問也從這裡開始。

記者:在整個救援過程中,是否存在為了儘快搶通線路,而沒有把救人放在第一位的現象?如何解釋沒有生命跡象了,又搜救出小伊伊?

陸東福:這個問題的提出,我們感到深深傷害了在事故救援第一線2000多名鐵路職工,3000多名地方的公安、駐軍、武警、消防、衛生等部門、群眾的感情,他們為事故救援救人付出了辛勤的勞動。

在事故救援現場,鐵道部和地方領導協同指揮,列車工作人員及鐵路幹部職工人、當地公安、駐軍、武警、消防、衛生等部門及群眾投入搶險救援,大家爭分奪秒、密切配合,對事故現場尤其是車廂進行全面搜救,將傷員以最快速度送至醫院。在救援過程中,橋上有三節車廂擠壓在一起,中間車廂變形嚴重,救援人員無法對該車廂進行徹底清查搜救。按照指揮部確定的把救人放在首位的救援方案,在橋下使用大噸位汽車吊精準、平穩地將兩端車廂移開,公安武警、救援人員得以對該車廂實施全面搜救,在移出數具遺體后,小伊伊在這裡獲救了。

直至24日23時30分左右,在確認沒有倖存者,並對遺物、車體進行清理收集完后,救援工作結束。在此之前,鐵路部門指揮人員從未說過「停止搜救」這樣的話。

記者:被毀的車廂和車頭是分析事故原因的主要依據,為什麼要匆忙對列車的車頭「挖坑填埋」呢?

陸東福:這一說法不屬實。在救援過程中,橋上有三節車廂積壓在一起,為使救援人員對中間一節受擠壓變形嚴重的車廂進行徹底搜救,必須把兩端車廂移開。為使汽車吊進入場地作業,須對橋下較完整的車廂整體外移,對散落的部件,包括撞碎的車頭部件,採取外移並集中堆放在土坑中,為吊車作業騰出場地。所以部件和車體絕沒有實施掩埋,更不存在銷毀證據的問題。現場搜救工作結束后,車體和集中在取土坑中的零散部件,被統一轉運至溫州西站,做進一步調查處理。

「7·23」事故發生時,D301次列車追尾撞上了D3115次列車,而根據鐵路列車時刻表,應該是D3115次列車在前,D301次列車在後,為什麼會出現列車行駛順序顛倒的情況,是不是當時車站調度出了問題呢?對此,鐵道部副部長陸東福是這樣回答的:

陸東福:D301次列車晚點,導致D301次列車行使在正點運行的D3115次之後。後方運行的D301次列車由於信號顯示錯誤與D3115次發生追尾。這起事故也反映出現場作業控制不力,人員應急處理的素質有待進一步提高,說明有些鐵路企業的安全基礎還比較薄弱,鐵路部門一定要吸取血的教訓,切實加強安全管理。

記者:動車上裝有「自動停車系統」,遇有險情列車會自己緊急停車以避免相撞,但「7·23」事故發生時相關自動系統為何沒有發揮作用?

陸東福:事發當時,由於雷擊造成溫州南站的信號設備故障,正常行駛的D3115次列車列控車載設備由於接收的碼序不穩定,造成停車后按規定緩行。此時,防護D3115次列車的後方信號由於列控中心的數據採集板軟體設計嚴重缺陷,造成本應顯示紅燈的信號錯誤升級為綠燈,致使列車運行控制系統沒有發揮作用,造成D301次列車按照錯誤顯示的綠燈進入區間,與前行的D3115次列車發生追尾事故。


高興

感動

同情

搞笑
1

難過

拍磚

支持
2

鮮花

剛表態過的朋友 (3 人)

發表評論 評論 (17 個評論)

回復 trunkzhao 2011-7-31 20:29
說了一個謊,就要撒十個謊去圓。
信不信由你,反正我不信。
回復 light12 2011-7-31 20:39
trunkzhao: 說了一個謊,就要撒十個謊去圓。
信不信由你,反正我不信。
ZT 供參考 ATP應該是不能人為關閉的,太危險。

ATP與ATC及民鐵之事故原因推測      時間: 29 7 2011 23:55   

作者:妖刀

看了一些網文,認為ATP問題是這次高鐵追尾事故的原因
歐的認識,直接原因或許是ATP的問題,但應該有更深層的問題,當然不是指政治體制上的原因。


看介紹中國ATP好像是這樣的工作原理
1。通過前車向軌道傳送自己位置/狀態的信號(或安放在軌道邊的感測器監測出列車位置/狀態,向軌道發送信號)
2。後車從軌道檢測出前車信號
3。如果2車有可能進入同一閉塞區間,控制裝置就會控制信號機給出紅燈,提示停車
4。後車監測到進入前車的閉塞區間后,自動停車/提示停車 --- 這點沒有看到介紹。但估計應該有這功能。

這次事故的原因,與其說是3沒有起作用,不如說4
因為高速運行中信號機的信號不容易辨別,即便辨別無誤緊急剎車的,高速列車一般會滑行1km以上
所以下面說過,這信號燈的紅綠燈,只是輔助性質,不能當作防止事故的主要手段。
當然,紅綠燈故障本身確實是重大問題---不是事故的直接/主要問題

問題是4。首先4究竟有沒有。歐的估計應該有的。有3個原因:
1。很容易預見依賴信號燈控制的巨大危險性
2。技術上不複雜
3。國外也有現成的技術廣泛的應用
以這前提說事故的最大原因,應該是4的失效
至於失效的原因,可能是因為維修控制系統故障時,誤將ATP控制裝置關閉 --- 軌道邊的裝置;
也可能是後車司機關掉了接收裝置 --- 這點有些不可思議。不至於讓司機有手段切斷這裝置功能的8
雖然不可思議,但假設是司機關掉了ATP接受裝置---注意,不是ATP本身
原因會是什麼?
當然有可能是誤操作 --- 10天培訓
有可能是根本不懂是什麼裝置 --- 10天培訓

歐的胡思亂想:
可能是這ATP性能比較差技術水平低,容易誤動作導致意外停車
高鐵的牛皮已經吹上天,而開業來故障多多,上面的面子掛不住嚴厲要求準時運行---不是安全運行
司機就關掉這麻煩的ATP接受器,正常情況下規定速度行車是不會撞車追尾的;加上據說有紅綠燈
--- 不幸的是前車發生停車了。紅綠燈也故障了。


所以覺得這次拋出信號機故障作為事故原因,純粹是替罪羊。決無此可能。
事故的直接原因,是複合性的。

深層原因另外



日本鐵道使用的是ATC。原理上說是ATP的發展型。主要原理如下:
1。安放在軌道邊的感測器檢測出列車位置/狀態,向軌道發送信號
2。後車從軌道檢測出前車信號
3。後車根據自己的速度和位置,與前車的距離,與檢出的前車信號進行計算,提示允許的最大速度。根據情況自動降速
4。如果進入同一閉塞區間,自動停車
5。如果有車停止,全線路的列車自動停車。
---紅綠燈只是輔助作用---比如發車停車等
信號的傳輸不僅僅依靠軌道,也有將無線作為backup通道的

這僅僅是防止撞車的手段而已



下面有文好像說ATP安裝在車上,這應該是誤解
如果真是安裝車上,那才真是太原始了


---------------------------------------------------------------------------------------------------------

隨便亂說
回復 yulinw 2011-7-31 21:18
   再問下去就要大表彰了~·
回復 light12 2011-7-31 22:46
yulinw:    再問下去就要大表彰了~·
「列控中心的數據採集板軟體設計嚴重缺陷」。ATP出了問題,牛皮吹破了
回復 Matney 2011-8-1 00:01
悲哀 .
回復 light12 2011-8-1 00:06
Matney: 悲哀 .
這問題用不著用人命來找吧?
回復 awang9988 2011-8-1 00:50
應該開表彰大會,中國又一個奇迹。
回復 light12 2011-8-1 01:02
awang9988: 應該開表彰大會,中國又一個奇迹。
瞎整
回復 nsa130 2011-8-1 01:50
無語!
回復 light12 2011-8-1 02:01
nsa130: 無語!
"列控中心的數據採集板軟體設計嚴重缺陷"就敢上路
回復 whyuask 2011-8-1 02:12
bullshit
回復 kissmyass 2011-8-1 04:02
鐵道部是典型的官老爺作風, 根本沒把人民大眾, 即它的客戶, 當成服務的對象。 一切都是從官本位的原則出發來辦事, 因此被廣大的客戶不信任也是不無關係的。
回復 light12 2011-8-1 06:32
whyuask: bullshit
  
回復 light12 2011-8-1 06:32
kissmyass: 鐵道部是典型的官老爺作風, 根本沒把人民大眾, 即它的客戶, 當成服務的對象。 一切都是從官本位的原則出發來辦事, 因此被廣大的客戶不信任也是不無關係 ...
回復 Giada 2011-8-1 13:17
  
回復 Matney 2011-8-1 14:52
light12: 這問題用不著用人命來找吧?
對,
回復 light12 2011-8-1 17:09
Giada:   
  

facelist doodle 塗鴉板

您需要登錄后才可以評論 登錄 | 註冊

關於本站 | 隱私權政策 | 免責條款 | 版權聲明 | 聯絡我們

Copyright © 2001-2013 海外華人中文門戶:倍可親 (http://big5.backchina.com) All Rights Reserved.

程序系統基於 Discuz! X3.1 商業版 優化 Discuz! © 2001-2013 Comsenz Inc.

本站時間採用京港台時間 GMT+8, 2024-4-23 07:15

返回頂部