地鐵火車相撞事件(2019年3月18日上午)
(此分析是基於2019年3月的公開信息。當調查報告公開時，將會有另一次分析。)
·
港鐵在測試新信號系統期間，發生兩列列車相撞嚴重事故，車廂嚴重損壞，荃灣線往來中環站至金鐘站的服務因而停駛。
港鐵的處理
·
因自動「防撞系統」並無發揮作用，車長要以人手煞車。由於距離太短，結果兩車相撞, 但這已不是最壊情況。
·
港鐵與系統承辦商迅速重組事故，初步確認有軟件問題。
·
港鐵表示，使用真實列車的測試時，之前已獾供應商發出安全證明書(safety certificate)。
1. 港鐵第一時間已找系統承辦商作出深入調查。很快用了模擬器作了案情重組，確認了模擬器找到同樣情況。
2. 極速完成後續工作，例如更換車
轆和檢查路軌受損情況。第一時間回服正常運作。
3. 車長以人手操作煞車。結果傷亡和減至最少。（有關最壞情況）
1. 新系統設計有問，未能做好獨立而有效的「防撞功能」。
2. 軟件設計和測試不全面。結果是有盲點。
3. 「安全證明書」未能全面反映系統安全性。沒有制定一個比較全面及要求高的安全性測試要求。
1. 除了以專業軟件工程師和信號系統專家的團隊，重建系統，作出「比較全面測試」。
2.
建做「獨立」有效的「防撞系統」。「獨立」系統是最理想的，但不容易實現。另一種方法是確保現有系統完全實現此功能。證明這一點也很困難。
3. 向市民證明系統是安全的。一語寄之若「獨立和全面」。只是「口說」安全不能令系統安全。（工程師對安全產品的要求）
·
以今次為例，如果後面車的車長沒有或沒能煞車，車頭便會早一些遇到另一車頭。很有機會兩車會「頭撞頭」，後果嚴重。
·
如果載滿人，列車重量增加，衝力大，煞車時間更長，後果不堪設想。
安全證明書
·
安全證明書問題對運行真實列車的測試「似乎是」安全的。但在這次事件的種情況下，事實並非如此。
·
疑問是安全證明書有多少來自於供應商之外的人的意見。
供應商是否有一個獨立的機構和部門來檢查其產品的安全性？
·
另一疑問是港鐵有多大參與測試以及制定測試標準？
防撞功能
·
信號系統軟件，防撞是「靈魂」。不允有任何妥協。即使意外地輸入不當數據，系統也應該進入「默認模式」，火車必須自動停止。
·
當感應到有任何可疑物接近，「防撞系統」就要把列車都會剎停。如果未能做到，等同「危險駕駛」。
·
上一世紀，港鐵也試出現過因爲有事故而兩車幾乎相撞，最後就是靠「防撞系統」把車剎停。
·
該系統其中一要求是要與列車控制系統完全格離。只要用最少和最重要數據作決定。我不相信事發時該性能/系統是獨立的。
「獨立」和「全面」的「防撞系統」
·
該系統應「獨立」於控制系統，因為這是處理不可預見情況的最後一步。
·
一種方法是在當前系統之上，通過收集所有實時數據和新的附加軟件來建立風險警報系統，以確保系統的安全。
·
這個專業工作，是要那些沒有參與系統設計的軟件工程師和信號專家組成的團隊執行。
軟件問題:-
有兩個主要問題:
系統設計和比較全面測試
系統設計
·
似乎信號系統存在盲點。隨著盲點的存在，下一個問題是：
·
還有其他盲點嗎？
·
如何解決這個盲點的問題？
·
如何確保系統仍然安全。
·
所以，除了找出事故出問題的地方外，還要做全面的檢視
(structured
walk-through)。這個專業工作，是要「獨立的」軟件工程師和信號專家組成的團隊執行。
·
在事前進行模擬測試時，要注意「測試情況」的「代表性」和「覆蓋性」。目的是把測試做到比較全面。
·
我們做軟件發展時一個常用的招數是用「極瑞情況」來測試。舉例，我要求學生寫一個軟件把n個數字排序，而n 可能是1 至到10。通常做了一些測試，n 是2， 3， 等等都沒有問題時，我便要他試n=1, 和 n=10, 往往學生交的軟件就是過不了關。另有數過類似的經驗：
·
田北辰議員問過「有沒有試過一分鐘內，系統裏有可容許最多車時的情況？（大概意思）」問得合理，但現在還未有資料。如果做夠代表性測試，就算是沒這一個測試，也可推算出來。
·
香港國際機場開的時候，軟件沒有在極端情況下測試，所以沒有想過系統處理大量數據時的情況。所以就出事。
·
還有其他類似的案例。將來會在其他場合再分享。
工程師應該建立一個安全的產品，並確保它看起來安全。
建造一座橋樑，即使它是安全的，除非市民認為它是安全的，沒有人會使用它。