跳到主要內容

發表文章

目前顯示的是有「mtr crash」標籤的文章

18 March 2019 TWL MTR crash report, from EMSD

Background The signalling system contractor Alstom-Thales DUAT Joint Venture (ATDJV) has been carrying out tests of the new signalling system during non-traffic hours at different sections of the Tsuen Wan Line by phases since late 2016. The ATDJV commenced full-line train tests in early 2018, and had subsequently completed the tests on site, which lasted for more than two years, in Feb 2019 On 16 Feb 2019, the MTRCL commenced a series of drills and exercises before putting the new signalling system into revenue service. Analysis According to our investigation findings, the cause of the incident was a programming error introduced during software rectification of the new signalling system at the design and development stage. This programming error caused a failure to re-create the data of the crossover track at the Central Station after switch-over from the primary zone controller (ZC) to the warm-standby tertiary ZC. Hence the Automatic Train Protection (ATP) system co...

18 March 2019 TWL MTR crash report, from MTR

Background The new signalling system of TWL developed by the contractor is divided into two control zones. In each control zone, it comprises three signalling zone controller computers, namely the Primary("A), Hot-standby("B"), and Warm-standby("C") computers. Computers A, B and C are of the same hardware and loaded with common software. They are configured to perform functions of Computer A, B and C through a hardware identity plug, which allows the common software to process dynamic data among the three computers correspondingly. Computer C only receives selected dynamic data from Computers A/B so as to avoid common mode failure. This configuration aims to improve system availability and service recovery through high resilience Computer C is housed at a different station which enhances system security through access control and diverse power supply. The Panel agrees the warm-standby arrangement is novel in contractor's signalling system app...

MTR blamed the 18 March crash due to software glitch

glitch a sudden, usually temporary malfunction or fault of equipment. Mar 2015 Press Release:  MTR Officially Awards HK$3.3 Billion Signalling System Replacement Contract to Alstom-Thales DUAT JV:  As  it  is  critically  important  that  we  maintain  normal  train  service  during  the  replacement  programme, the railway lines will be upgraded progressively with trackside works being done during the short overnight non-service hours. As the providers of existing signalling systems in our network, both Alstom and Thales know our railway well, which gives us greater assurance that any inconvenience caused to passengers would be kept to a minimum,” added Mr Leong. 18 Mar 2019:  The contractor has confirmed that a software problem in the new signaling system caused two trains to collide in Central during a test early this morning, Jacob Kam Chak-pui, who will be chief executive officer of M...

2019年 3月18 地鐵相撞 mtr crash

金澤培指出,事發在路軌「渡線(道岔)」 位置junction,正常一列列車要經過渡線,需要經過「攞路」程序,在保護系統automatic train protection system 中「最重要是兩列車 不能『攞路』 limit of movement authority 令它們(不能))同時在同一個地方出現、經過」;但昨晚事發時,電腦為兩列涉事列車「攞路」後,正正令兩列車同時在同一地方經過,「在安全來說是絕對不可以接受」。他稱昨晚新信號系統正測試當主、副系統失效時,第三套後備系統可否正常運作,結果轉換第三套後備系統後出事。 金續說,新信號系統的供應商在多倫多總實驗室,用模擬系統成功重組事故經過,初步發現是系統的軟件有問題。供應商將盡快從多倫多派軟件專家等來港協助調查;亦正下載事發過程的數據及資料,檢視所有涉事部件在事發時的情況。 金澤培表示,調查內容包括事故成因、軟件開發及系統保障程序,預期情況較複雜,故需時最少兩三個月才能有初步結論。 港鐵兩列空載列車昨(18日)凌晨測試新信號後備系統期間,信號軟件出錯致兩列車相撞,荃灣線金鐘至中環今早(19日)仍未能恢復服務。港鐵車務工程總管李家潤表示,雖然該新信號系統的承辦商Alstom-Thales 也有向新加坡地鐵提供信號系統,並在當地曾發生列車相撞事故,但兩套系統完全不同,至於是否重新考慮繼續聘用該承辦商,他指要完成調查後再決定下一步行動。 他又指,過去曾經獨立測試新信號系統的主電腦、副電腦及後備電腦,均無發現問題,但昨晚模擬主、副電腦失靈,轉換到後備電腦去測試時就發生兩列車相撞,自動制動系統並無發揮作用,車長要以人手煞車,而由於距離太短最終兩車相撞,已責成系統承辦商調查為何會出現軟件問題,專家小組其中一個調查方向是了解輸入的數據有否出錯。 立法會鐵路事宜小組委員會成員田北辰指,鐵路系統在遇到行車問題時應馬上停車,批評今次港鐵測試時發生撞車意外是十分荒謬,他估計或與輸入資料有誤有關。 列車信號系統建基於「自動故障保護」(Fail-Safe)的設計理念,一旦出現任何信號不穩情況,所有相關信號設備便會自動進入安全模式,暫停所有相關行駛列車,以策安全。信號系統亦設有後備裝置,一旦發生故障,後備裝置會自動啟動,務求保持列車服務運作。 rthk news hkra...