感謝關注天善智慧型，走好資料之路↑↑↑
歡迎關注天善智慧型，我們是專注於商業智慧型bi，人工智慧ai，大資料分析與挖掘領域的垂直社群，學習，問答、求職一站式搞定！
這是乙個令人著迷的訊息，表現出緊密的團隊合作精神，睿智的分析，以及乙個永不言敗的態度。這就是#smartnation應該如何使用資料來解決現實問題！
——李顯龍 新加坡總理臉書狀態
新加坡地鐵環線近幾個月來發生了一系列不明原因的故障，給上千名乘客造成了困擾和麻煩。和我的大多數同事一樣，我每天早上都要搭乘環線去上班。前不久，當我們組被任命調查故障原因時，我毫不猶豫地報名參與其中。
從地鐵運營方smrt和道路管理局之前的調查中，我們已經知道這些故障是由於會引發訊號丟失的訊號干擾所導致的。訊號丟失會觸發列車的緊急制動安全系統從而致使列車不規律地停止行駛。但是這些發生自八月份的故障看起來都是隨機發生的，這給調查組的原因排查帶來了不小的困難。
我們從smrt獲得的資料可以提供如下資訊：
·每一起故障的日期和時間
·每一起故障的發生地點
·故障列車的編號
·故障列車的行駛方向
我們從清理原始資料入手。我們使用的軟體是jupyter notebook，它是一款非常流行的用於編寫和歸檔python**的工具。
—— 最基本的視覺化 ——
從如下這些基本的分析處理中，我們無法確定故障的明確原因：
1.故障發生的時間遍及全天，並且早晚高峰的故障發生次數呈映象對稱。
2.故障發生在環線沿線多處地點，在西部發生的次數略多。
3.訊號干擾影響到多列列車。「pv**」代表列車編號。
—— marey圖：對時間、地點、行駛方向的視覺化 ——
分析處理的下一步是綜合考慮多個維度的資訊。我們受到marey圖的啟發，marey圖是edward tufte在2023年經典的「量化資訊的視覺化表達」一文中提出的。最近，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，一列從2023年起投入執行的列車。
—— 驗證假設 ——
11月6日（週日），道路管理局和smrt在非高峰期時段進行測試來判定pv46是否是故障的源頭。測試結果表明我們是正確的——pv46確實引起了鄰近車輛的訊號丟失從而觸發了那些車輛的緊急制動系統。在pv46執行之前，並沒有相關故障發生。
11月7日（周一），我們團隊分析處理了pv46的所有關於地點的記錄資料，發現從八月至十一月的95%的故障可以用我們的假設來解釋。剩下的一些案例可能是由於在正常狀況下偶發的訊號丟失導致。
這一規律在某些日子特別明顯，例如9月1日。從下圖可以清晰地看出故障均發生在pv46執行的時間區間內。
—— 總結 ——
當我們剛開始調查故障原因時，我的同事和我都希望能找到使跨機構調查組感興趣的原因，這包括道路管理局，smrt和國防科技局。由smrt和道路管理局提供的清晰明了的故障日誌給我們的調查鋪平了道路，因為我們不需要在分析資料之前花費時間和精力來清理原始資料。我們也對道路管理局和國防科技局的後續調查表示滿意，他們證實了故障確實是來自pv46的硬體問題。
從資料科學的角度來看，我們非常幸運，因為故障發生的時間和地點很接近。這使我們能夠在很短的時間內確定問題和罪魁禍首。如果這些故障更加孤立，其中的規律和關聯就不那麼明顯了，我們將需要更多的時間和資料來解決這個謎題。