文/Daniel Sim 等
軌道交通事故頻發， 但真正原因卻不得而知。 本文資料俠通過科學的資料分析， 為我們提供了更多排查方法， 一起來漲漲姿勢吧~
本文轉自公眾號DataGirls（ID：DataGirls）
新加坡地鐵環線近幾個月來發生了一系列不明原因的故障， 給上千名乘客造成了困擾和麻煩。 和我的大多數同事一樣， 我每天早上都要搭乘環線去上班。 前不久， 當我們組被任命調查故障原因時， 我毫不猶豫地報名參與其中。
從地鐵運營方SMRT和道路管理局之前的調查中， 我們已經知道這些故障是由於會引發信號丟失的信號干擾所導致的。 信號丟失會觸發列車的緊急制動安全系統從而致使列車不規律地停止行駛。 但是這些發生自八月份的故障看起來都是隨機發生的， 這給調查組的原因排查帶來了不小的困難。
我們從SMRT獲得的資料可以提供如下資訊：
每一起故障的日期和時間
每一起故障的發生地點
故障列車的編號
故障列車的行駛方向
我們從清理原始資料入手。 我們使用的軟體是Jupyter Notebook， 它是一款非常流行的用於編寫和歸檔Python代碼的工具。
最基本的視覺化從如下這些基本的分析處理中， 我們無法確定故障的明確原因：
1. 故障發生的時間遍及全天， 並且早晚高峰的故障發生次數呈鏡像對稱。
2. 故障發生在環線沿線多處地點， 在西部發生的次數略多。
3. 信號干擾影響到多列列車。 “PV**”代表列車編號。
分析處理的下一步是綜合考慮多個維度的資訊。 我們受到Marey圖的啟發， Marey圖是Edward Tufte在1983年經典的“量化資訊的視覺化表達”一文中提出的。 最近， Marey圖被Mike Barry和Brian Card用於波士頓地鐵系統的視覺化專案中：
在這幅圖中， 縱軸代表時間——從上到下按照時間順序——橫軸代表地鐵沿線各個網站。 其中對角線代表地鐵的行進狀態。
我們先按照我們要研究的問題畫好坐標軸：
在正常情況下，一列從港灣站行駛至多美歌站的列車將會按照下圖的路線運行，每一趟單程僅需一小時。我們研究的目的是在該圖中用點而非直線來描繪故障的發生狀況。
準備用於視覺化的資料首先，我們把由三個字母代表的站名轉化為數字：
濱海灣至寶門廊：0至1.5
多美歌至港灣：2至29
如果故障發生在兩站之間，我們將用0.5加上兩站中較小的數位來表示故障地點。舉例來說，如果故障發生在港灣（29）和直落布蘭雅（28），那麼故障發生地點為“28.5”。這使我們在橫軸上的標注變得簡單明瞭。
基於處理之後的資料，我們在圖中繪製出了所有緊急制動故障的散點圖。每一個點代表一起故障。然而，我們還是無法歸納出明確的故障發生原因。
接下來，我們加入列車行駛方向這一因素。我們用指左或指右的三角形符號來代表列車的行駛方向：
然而，它看起來還是相當隨機。但是當我們放大至一些局部細節，一些規律似乎浮出水面：
如果你仔細研究這幅圖，你會發現：列車故障是依序發生的。當某一列車發生信號干擾，緊隨其後開往同一方向的列車將會很快也遭遇相同的干擾。
信號干擾是如何發生的？至此，我們仍然不清楚是否某一列車是肇事元兇。我們能夠確定的是在時間和地點的分佈上一些規律有跡可循：故障是依次交替在相反方向上發生。會不會是一些無法在資料集中體現的原因導致這些故障呢？
這些假想的連接各點的虛線看起來與Marey圖中的直線很相似。那些沿相反方向行駛的列車會不會是造成信號干擾的原因呢？我們決定去測試一下“肇事列車”這一假設。
我們已經知道環線每兩站之間的時間間隔大約是2-4分鐘。這意味著我們可以把四分鐘之內發生的緊急制動故障歸為一組。
然後，我們使用不相交的資料結構將所有的故障事件組合成較大的集合。這使我們能夠將可能與同一列肇事列車掛鉤的故障進行分組。
我們把這一演算法運用在資料集上，如下是我們找出的一些歸類的集群及相應結果：
這一結果表明：在資料集中包括的259起故障中，189起——或73%的故障——可以用“肇事列車”這一假設來解釋。這讓我們覺得我們的分析方向是正確的。
我們根據聚類結果對故障點進行著色。同一顏色的三角形來自同一集群。
從前文可知，環線每一單程大約耗時一小時。我們按照正常運行的列車Marey圖中的直線來擬合故障散點圖。從下圖可以清晰地看出只有一列肇事列車。
我們還可以得出：那列未知的肇事列車自身並沒有出現任何信號故障，因為它並沒有出現在我們的散點圖中。
找出肇事列車日落之後，我們前往金泉地鐵車輛段，試圖找出肇事列車。由於SMRT需要更多時間來匯出當日資料，我們無法查看列車日誌的詳細記錄。所以我們決定用老式的方法，通過審查故障發生時到達和離開各車站的列車的錄影記錄。終於在淩晨三點鐘，團隊發現了頭號嫌疑犯：PV46，一列從2015年起投入運行的列車。
驗證假設11月6日（周日），道路管理局和SMRT在非高峰期時段進行測試來判定PV46是否是故障的源頭。測試結果表明我們是正確的——PV46確實引起了鄰近車輛的信號丟失從而觸發了那些車輛的緊急制動系統。在PV46運行之前，並沒有相關故障發生。
11月7日（週一），我們團隊分析處理了PV46的所有關於地點的記錄資料，發現從八月至十一月的95%的故障可以用我們的假設來解釋。剩下的一些案例可能是由於在正常狀況下偶發的信號丟失導致。
這一規律在某些日子特別明顯，例如9月1日。從下圖可以清晰地看出故障均發生在PV46運行的時間區間內。
當我們剛開始調查故障原因時，我的同事和我都希望能找到使跨機構調查組感興趣的原因，這包括道路管理局，SMRT和國防科技局。
由SMRT和道路管理局提供的清晰明瞭的故障日誌給我們的調查鋪平了道路，因為我們不需要在分析資料之前花費時間和精力來清理原始資料。我們也對道路管理局和國防科技局的後續調查表示滿意，他們證實了故障確實是來自PV46的硬體問題。
從資料科學的角度來看，我們非常幸運，因為故障發生的時間和地點很接近。這使我們能夠在很短的時間內確定問題和罪魁禍首。如果這些故障更加孤立，其中的規律和關聯就不那麼明顯了，我們將需要更多的時間和資料來解決這個謎題。
注：本文編譯自新加坡GovTech發佈在Medium上的博客《How the Circle Line rogue train was caught with data》. 文章僅為作者觀點，不代表DT財經立場。
題圖 | 視覺中國
期待更多資料俠乾貨分享、話題討論、福利發放？在公眾號DT資料俠（ID：DTdatahero）後臺回復“數據社群”，可申請加入DT數據社群。
資料俠門派本文資料俠Daniel Sim, Lee Shangqian 和 Clarence Ng，他們是來自新加坡政府技術機構（GovTech）的資料科學家。
加入資料俠“資料俠計畫”是由第一財經旗下DT財經發起的資料社群，包含資料俠專欄、資料俠實驗室系列活動和資料俠聯盟，旨在聚集大資料領域精英，共同挖掘資料價值。瞭解資料俠計畫詳情請回復“資料俠計畫”，投稿、合作請聯繫datahero@dtcj.com。
在正常情況下，一列從港灣站行駛至多美歌站的列車將會按照下圖的路線運行，每一趟單程僅需一小時。我們研究的目的是在該圖中用點而非直線來描繪故障的發生狀況。
準備用於視覺化的資料首先，我們把由三個字母代表的站名轉化為數字：
濱海灣至寶門廊：0至1.5
多美歌至港灣：2至29
如果故障發生在兩站之間，我們將用0.5加上兩站中較小的數位來表示故障地點。舉例來說，如果故障發生在港灣（29）和直落布蘭雅（28），那麼故障發生地點為“28.5”。這使我們在橫軸上的標注變得簡單明瞭。
基於處理之後的資料，我們在圖中繪製出了所有緊急制動故障的散點圖。每一個點代表一起故障。然而，我們還是無法歸納出明確的故障發生原因。
接下來，我們加入列車行駛方向這一因素。我們用指左或指右的三角形符號來代表列車的行駛方向：
然而，它看起來還是相當隨機。但是當我們放大至一些局部細節，一些規律似乎浮出水面：
如果你仔細研究這幅圖，你會發現：列車故障是依序發生的。當某一列車發生信號干擾，緊隨其後開往同一方向的列車將會很快也遭遇相同的干擾。
信號干擾是如何發生的？至此，我們仍然不清楚是否某一列車是肇事元兇。我們能夠確定的是在時間和地點的分佈上一些規律有跡可循：故障是依次交替在相反方向上發生。會不會是一些無法在資料集中體現的原因導致這些故障呢？
這些假想的連接各點的虛線看起來與Marey圖中的直線很相似。那些沿相反方向行駛的列車會不會是造成信號干擾的原因呢？我們決定去測試一下“肇事列車”這一假設。
我們已經知道環線每兩站之間的時間間隔大約是2-4分鐘。這意味著我們可以把四分鐘之內發生的緊急制動故障歸為一組。
然後，我們使用不相交的資料結構將所有的故障事件組合成較大的集合。這使我們能夠將可能與同一列肇事列車掛鉤的故障進行分組。
我們把這一演算法運用在資料集上，如下是我們找出的一些歸類的集群及相應結果：
這一結果表明：在資料集中包括的259起故障中，189起——或73%的故障——可以用“肇事列車”這一假設來解釋。這讓我們覺得我們的分析方向是正確的。
我們根據聚類結果對故障點進行著色。同一顏色的三角形來自同一集群。
從前文可知，環線每一單程大約耗時一小時。我們按照正常運行的列車Marey圖中的直線來擬合故障散點圖。從下圖可以清晰地看出只有一列肇事列車。
我們還可以得出：那列未知的肇事列車自身並沒有出現任何信號故障，因為它並沒有出現在我們的散點圖中。
找出肇事列車日落之後，我們前往金泉地鐵車輛段，試圖找出肇事列車。由於SMRT需要更多時間來匯出當日資料，我們無法查看列車日誌的詳細記錄。所以我們決定用老式的方法，通過審查故障發生時到達和離開各車站的列車的錄影記錄。終於在淩晨三點鐘，團隊發現了頭號嫌疑犯：PV46，一列從2015年起投入運行的列車。
驗證假設11月6日（周日），道路管理局和SMRT在非高峰期時段進行測試來判定PV46是否是故障的源頭。測試結果表明我們是正確的——PV46確實引起了鄰近車輛的信號丟失從而觸發了那些車輛的緊急制動系統。在PV46運行之前，並沒有相關故障發生。
11月7日（週一），我們團隊分析處理了PV46的所有關於地點的記錄資料，發現從八月至十一月的95%的故障可以用我們的假設來解釋。剩下的一些案例可能是由於在正常狀況下偶發的信號丟失導致。
這一規律在某些日子特別明顯，例如9月1日。從下圖可以清晰地看出故障均發生在PV46運行的時間區間內。
當我們剛開始調查故障原因時，我的同事和我都希望能找到使跨機構調查組感興趣的原因，這包括道路管理局，SMRT和國防科技局。
由SMRT和道路管理局提供的清晰明瞭的故障日誌給我們的調查鋪平了道路，因為我們不需要在分析資料之前花費時間和精力來清理原始資料。我們也對道路管理局和國防科技局的後續調查表示滿意，他們證實了故障確實是來自PV46的硬體問題。
從資料科學的角度來看，我們非常幸運，因為故障發生的時間和地點很接近。這使我們能夠在很短的時間內確定問題和罪魁禍首。如果這些故障更加孤立，其中的規律和關聯就不那麼明顯了，我們將需要更多的時間和資料來解決這個謎題。
注：本文編譯自新加坡GovTech發佈在Medium上的博客《How the Circle Line rogue train was caught with data》. 文章僅為作者觀點，不代表DT財經立場。
題圖 | 視覺中國
期待更多資料俠乾貨分享、話題討論、福利發放？在公眾號DT資料俠（ID：DTdatahero）後臺回復“數據社群”，可申請加入DT數據社群。
資料俠門派本文資料俠Daniel Sim, Lee Shangqian 和 Clarence Ng，他們是來自新加坡政府技術機構（GovTech）的資料科學家。
加入資料俠“資料俠計畫”是由第一財經旗下DT財經發起的資料社群，包含資料俠專欄、資料俠實驗室系列活動和資料俠聯盟，旨在聚集大資料領域精英，共同挖掘資料價值。瞭解資料俠計畫詳情請回復“資料俠計畫”，投稿、合作請聯繫datahero@dtcj.com。