新加坡地鐵環(huán)線近幾個月來發(fā)生了一系列不明原因的故障，給上千名乘客造成了困擾和麻煩鹊碍。和我的大多數(shù)同事一樣僵缺，我每天早上都要搭乘環(huán)線去上班胡桃。前不久，當(dāng)我們組被任命調(diào)查故障原因時磕潮，我毫不猶豫地報名參與其中翠胰。
從地鐵運(yùn)營方SMRT和道路管理局之前的調(diào)查中容贝，我們已經(jīng)知道這些故障是由于會引發(fā)信號丟失的信號干擾所導(dǎo)致的。信號丟失會觸發(fā)列車的緊急制動安全系統(tǒng)從而致使列車不規(guī)律地停止行駛之景。但是這些發(fā)生自八月份的故障看起來都是隨機(jī)發(fā)生的斤富，這給調(diào)查組的原因排查帶來了不小的困難。
我們從SMRT獲得的數(shù)據(jù)可以提供如下信息：
·每一起故障的日期和時間
·每一起故障的發(fā)生地點
·故障列車的編號
·故障列車的行駛方向
我們從清理原始數(shù)據(jù)入手锻狗。我們使用的軟件是Jupyter Notebook茂缚，它是一款非常流行的用于編寫和歸檔Python代碼的工具。
—— 最基本的可視化 ——
從如下這些基本的分析處理中屋谭，我們無法確定故障的明確原因：
1.故障發(fā)生的時間遍及全天脚囊，并且早晚高峰的故障發(fā)生次數(shù)呈鏡像對稱。
2.故障發(fā)生在環(huán)線沿線多處地點桐磁，在西部發(fā)生的次數(shù)略多悔耘。
3.信號干擾影響到多列列車∥依蓿“PV**”代表列車編號衬以。
—— Marey圖：對時間、地點校摩、行駛方向的可視化 ——
分析處理的下一步是綜合考慮多個維度的信息看峻。我們受到Marey圖的啟發(fā)，Marey圖是Edward Tufte在1983年經(jīng)典的“量化信息的可視化表達(dá)”一文中提出的衙吩。最近互妓，Marey圖被Mike Barry和Brian Card用于波士頓地鐵系統(tǒng)的可視化項目中：
在這幅圖中，縱軸代表時間——從上到下按照時間順序——橫軸代表地鐵沿線各個站點坤塞。其中對角線代表地鐵的行進(jìn)狀態(tài)冯勉。
我們先按照我們要研究的問題畫好坐標(biāo)軸：
在正常情況下，一列從港灣站行駛至多美歌站的列車將會按照下圖的路線運(yùn)行摹芙，每一趟單程僅需一小時灼狰。我們研究的目的是在該圖中用點而非直線來描繪故障的發(fā)生狀況。
—— 準(zhǔn)備用于可視化的數(shù)據(jù) ——
首先浮禾，我們把由三個字母代表的站名轉(zhuǎn)化為數(shù)字：
·濱海灣至寶門廊：0至1.5
·多美歌至港灣：2至29
如果故障發(fā)生在兩站之間交胚，我們將用0.5加上兩站中較小的數(shù)字來表示故障地點。舉例來說盈电，如果故障發(fā)生在港灣（29）和直落布蘭雅（28）蝴簇，那么故障發(fā)生地點為“28.5”。這使我們在橫軸上的標(biāo)注變得簡單明了挣轨。
基于處理之后的數(shù)據(jù)军熏，我們在圖中繪制出了所有緊急制動故障的散點圖。每一個點代表一起故障卷扮。然而荡澎，我們還是無法歸納出明確的故障發(fā)生原因均践。
接下來，我們加入列車行駛方向這一因素摩幔。我們用指左或指右的三角形符號來代表列車的行駛方向：
然而彤委，它看起來還是相當(dāng)隨機(jī)。但是當(dāng)我們放大至一些局部細(xì)節(jié)或衡，一些規(guī)律似乎浮出水面：
如果你仔細(xì)研究這幅圖焦影，你會發(fā)現(xiàn)：列車故障是依序發(fā)生的。當(dāng)某一列車發(fā)生信號干擾封断，緊隨其后開往同一方向的列車將會很快也遭遇相同的干擾斯辰。
—— 信號干擾是如何發(fā)生的？ ——
至此坡疼，我們?nèi)匀徊磺宄欠衲骋涣熊囀钦厥略獌幢蛏搿Ｎ覀兡軌虼_定的是在時間和地點的分布上一些規(guī)律有跡可循：故障是依次交替在相反方向上發(fā)生。會不會是一些無法在數(shù)據(jù)集中體現(xiàn)的原因?qū)е逻@些故障呢柄瑰？
這些假想的連接各點的虛線看起來與Marey圖中的直線很相似闸氮。那些沿相反方向行駛的列車會不會是造成信號干擾的原因呢？我們決定去測試一下“肇事列車”這一假設(shè)教沾。
我們已經(jīng)知道環(huán)線每兩站之間的時間間隔大約是2-4分鐘蒲跨。這意味著我們可以把四分鐘之內(nèi)發(fā)生的緊急制動故障歸為一組。
然后授翻，我們使用不相交的數(shù)據(jù)結(jié)構(gòu)將所有的故障事件對組合成較大的集合或悲。這使我們能夠?qū)⒖赡芘c同一列肇事列車掛鉤的故障進(jìn)行分組。
我們把這一算法運(yùn)用在數(shù)據(jù)集上藏姐，如下是我們找出的一些歸類的集群及相應(yīng)結(jié)果：
這一結(jié)果表明：在數(shù)據(jù)集中包括的259起故障中隆箩，189起——或73%的故障——可以用“肇事列車”這一假設(shè)來解釋。這讓我們覺得我們的分析方向是正確的羔杨。
我們根據(jù)聚類結(jié)果對故障點進(jìn)行著色。同一顏色的三角形來自同一集群杨蛋。
—— 有多少列肇事列車兜材？ ——
從前文可知，環(huán)線每一單程大約耗時一小時逞力。我們按照正常運(yùn)行的列車Marey圖中的直線來擬合故障散點圖曙寡。從下圖可以清晰地看出只有一列肇事列車。
我們還可以得出：那列未知的肇事列車自身并沒有出現(xiàn)任何信號故障寇荧，因為它并沒有出現(xiàn)在我們的散點圖中举庶。
—— 找出肇事列車 ——
日落之后，我們前往金泉地鐵車輛段試圖找出肇事列車揩抡。由于SMRT需要更多時間來導(dǎo)出當(dāng)日數(shù)據(jù)户侥，我們無法查看列車日志的詳細(xì)記錄镀琉。所以我們決定用老式的方法，通過審查故障發(fā)生時到達(dá)和離開各車站的列車的錄像記錄蕊唐。終于在凌晨三點鐘屋摔，團(tuán)隊發(fā)現(xiàn)了頭號嫌疑犯：PV46，一列從2015年起投入運(yùn)行的列車替梨。
—— 驗證假設(shè) ——
11月6日（周日）钓试，道路管理局和SMRT在非高峰期時段進(jìn)行測試來判定PV46是否是故障的源頭。測試結(jié)果表明我們是正確的——PV46確實引起了鄰近車輛的信號丟失從而觸發(fā)了那些車輛的緊急制動系統(tǒng)副瀑。在PV46運(yùn)行之前弓熏，并沒有相關(guān)故障發(fā)生。
11月7日（周一）糠睡，我們團(tuán)隊分析處理了PV46的所有關(guān)于地點的記錄數(shù)據(jù)硝烂，發(fā)現(xiàn)從八月至十一月的95%的故障可以用我們的假設(shè)來解釋。剩下的一些案例可能是由于在正常狀況下偶發(fā)的信號丟失導(dǎo)致铜幽。
這一規(guī)律在某些日子特別明顯滞谢，例如9月1日。從下圖可以清晰地看出故障均發(fā)生在PV46運(yùn)行的時間區(qū)間內(nèi)除抛。
—— 總結(jié) ——
當(dāng)我們剛開始調(diào)查故障原因時狮杨，我的同事和我都希望能找到使跨機(jī)構(gòu)調(diào)查組感興趣的原因，這包括道路管理局到忽，SMRT和國防科技局橄教。由SMRT和道路管理局提供的清晰明了的故障日志給我們的調(diào)查鋪平了道路，因為我們不需要在分析數(shù)據(jù)之前花費(fèi)時間和精力來清理原始數(shù)據(jù)喘漏。我們也對道路管理局和國防科技局的后續(xù)調(diào)查表示滿意护蝶，他們證實了故障確實是來自PV46的硬件問題。
從數(shù)據(jù)科學(xué)的角度來看翩迈，我們非常幸運(yùn)持灰，因為故障發(fā)生的時間和地點很接近。這使我們能夠在很短的時間內(nèi)確定問題和罪魁禍?zhǔn)赘核恰Ｈ绻@些故障更加孤立堤魁，其中的規(guī)律和關(guān)聯(lián)就不那么明顯了，我們將需要更多的時間和數(shù)據(jù)來解決這個謎題返十。
*本文用到的Python源代碼請點擊閱讀原文獲取妥泉。全文翻譯自新加坡GovTech發(fā)布在Medium上的官方博客How the Circle Line rogue train was caught with data.
