地铁故障频发，看数据如何找到肇事元凶

“

轨道交通事故频发，但真正原因却不得而知。本文数据侠通过科学的数据分析，为我们提供了更多排查方法，一起来涨涨姿势吧~

本文转自公众号DataGirls（ID：DataGirls）

新加坡地铁环线近几个月来发生了一系列不明原因的故障，给上千名乘客造成了困扰和麻烦。和我的大多数同事一样，我每天早上都要搭乘环线去上班。前不久，当我们组被任命调查故障原因时，我毫不犹豫地报名参与其中。

从地铁运营方SMRT和道路管理局之前的调查中，我们已经知道这些故障是由于会引发信号丢失的信号干扰所导致的。信号丢失会触发列车的紧急制动安全系统从而致使列车不规律地停止行驶。但是这些发生自八月份的故障看起来都是随机发生的，这给调查组的原因排查带来了不小的困难。

我们从SMRT获得的数据可以提供如下信息：

我们从清理原始数据入手。我们使用的软件是Jupyter Notebook，它是一款非常流行的用于编写和归档Python代码的工具。

▍最基本的可视化

从如下这些基本的分析处理中，我们无法确定故障的明确原因：

1. 故障发生的时间遍及全天，并且早晚高峰的故障发生次数呈镜像对称。

2. 故障发生在环线沿线多处地点，在西部发生的次数略多。

3. 信号干扰影响到多列列车。“PV**”代表列车编号。

分析处理的下一步是综合考虑多个维度的信息。我们受到Marey图的启发，Marey图是Edward Tufte在1983年经典的“量化信息的可视化表达”一文中提出的。最近，Marey图被Mike Barry和Brian Card用于波士顿地铁系统的可视化项目中：

在这幅图中，纵轴代表时间——从上到下按照时间顺序——横轴代表地铁沿线各个站点。其中对角线代表地铁的行进状态。

我们先按照我们要研究的问题画好坐标轴：

在正常情况下，一列从港湾站行驶至多美歌站的列车将会按照下图的路线运行，每一趟单程仅需一小时。我们研究的目的是在该图中用点而非直线来描绘故障的发生状况。

首先，我们把由三个字母代表的站名转化为数字：

如果故障发生在两站之间，我们将用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的硬件问题。

从数据科学的角度来看，我们非常幸运，因为故障发生的时间和地点很接近。这使我们能够在很短的时间内确定问题和罪魁祸首。如果这些故障更加孤立，其中的规律和关联就不那么明显了，我们将需要更多的时间和数据来解决这个谜题。

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。