1月22日下午，上海地铁15号线发生严重事故，在祁安路站站台上，一名乘客下车时，被正在关闭的屏蔽门夹住，车辆突然启动，致乘客被带倒挤压，被救出后送医抢救无效身亡。
据悉，上海地铁15号线是2021年1月开通的全自动驾驶线路，是国内具备最高等级(UTO)全自动驾驶的轨道交通线路，信号系统基于无线通信，满足全自动驾驶最高等级，而此次的事故无疑再一次将「自动驾驶」推向了风口浪尖。
在地面交通中，自动驾驶需要面对人、车、复杂路况等诸多环境因素，但在轨道交通中，环境相对封闭、路况简单且有严格的时间把控，为自动驾驶的落地创造了良好的“温室”环境，如今却也出现了重大事故，不禁令人对其安全性产生怀疑与担忧，但此番上海地铁事故真的该问责自动驾驶吗?
事故复盘
在为这场悲剧惋惜之余，广大网友针对事故责任归属，围绕乘客、站台工作人员、自动驾驶系统展开了激烈讨论。
诚然，当列车车门、屏蔽门灯闪烁、警示声鸣响时，乘客应停止上车，并退至安全区域，但在实际场景中，经常会出现因人多拥挤推搡、或乘客反应不及时而来不及退出候车黄色安全线以外的情况。而在突发状况发生时，站台工作人员与列车自动控制系统又是否做出了正确的反应呢?
从目前网络上曝光的视频可以看出，在发现乘客被屏蔽门夹住后，工作人员立即上前帮助其脱困，并进行了一系列“操作”，但并未及时救出乘客，而自动驾驶系统也并没有检测到这起车门外的突发事件，反而启动行驶，导致乘客被挤压。
针对这起事故与网络上的种种猜测，笔者咨询了业内人士，诸如此类的突发状况究竟应该如何处理。
据这位业内人士介绍，站台均设置了紧急停车按钮，而工作人员在接发车时也应站在紧急停车按钮下，以防紧急情况发生时可以快速做出反应，叫停运行中的列车后再进行相应处理。此外，正常情况下，屏蔽门的开合状态是随列车门开合而自动控制的，但当发生异常情况时，每个站台的综合控制室则可以通过IBP盘(综合后备盘)接管屏蔽门的状态控制。
IBP 盘由 IBP 面板、 PLC ( BAS 专业提供)、人机界面终端(其它专业提供并安装)、监控工作台构成。当车站综合监控系统设备服务器或者人机界面出现故障时，通过 IBP 盘对本车站进行应急管理;或在紧急情况下直接操作 IBP 盘上按钮、钥匙开关等，采用人工介入方式进行运行模式操作和某些设备的远程单动操作。
基于当前的列车自动控制系统，无论是否为自动驾驶，列车在出站前均会自动检测屏蔽门状态，来判断是否具备发车条件。当屏蔽门出现机械故障或因通信故障无法正确向列车自动控制系统发送屏蔽门关好信号时，工作人员可以手动切除屏蔽门与车门的联动状态，从而使列车能够正常发车，避免列车晚点。
而这也恰恰是本次事故引发争议的焦点——有网友通过视频判断，工作人员当时可能是误操作，切断了屏蔽门信号，才导致列车发车。
当然，截止发稿，官方尚未发布具体的事故情况说明。
悲剧已然发生，分析事故原委的目的不应是恶意指责与谩骂，而是为了警醒市民与工作人员，更是为地铁自动驾驶敲响警钟，应提升突发事件应对能力，从人、车以及硬件、软件不同角度制定相应解决方案。
全自动驾驶却离不开人?
自动驾驶技术虽然在地面交通处处掣肘，仍处于试点阶段，但地铁自动驾驶已然实现了规模化落地，而上海地铁正是国内第一批“吃螃蟹的人”，同时也是目前正式运行的自动驾驶路线最多的城市。
早在2014年8月，上海地铁10号线便实现了无人驾驶运行。截至2021年12月30日，上海地铁已经拥有5条全自动驾驶线路，包括10、14、15、18号线、浦江线。其中，上海地铁14、15、18 号线均是GOA4 等级全自动驾驶，实现了完全的无人化自动驾驶，取消了驾驶舱。
图源：中铁十四局
逐本溯源，通信系统无疑是地铁自动驾驶的基本盘。据业内人士介绍，目前的全自动驾驶普遍采用车地通信，基于CBTC系统的LTE通信可以实现车—地的双向通信，一方面可以把车载数据向车站、车辆段、停车场等属地进行及时传输，以实现地铁运营方对乘客状况、列车设备及运行状态、隧道及弓网等情况的监测;另一方面可以将前车状态、站台环境等可能影响列车运行的信息实时反馈至自动驾驶系统中，以便系统据此调整运行状态。
业内人士分析，未来的全自动驾驶通信将会向车车通信过渡，通过列车之间的直接信息交互，提升数据传输时效性与运营能力。2020年6月，卡斯柯信号有限公司基于车车通信的列车自主运行系统完成现场多车无人驾驶测试验证，实现了全国首例基于车车通信的UTO无人驾驶。
回归到本次事故中，上海轨道交通15号线是在上海市轨道交通领域首次将LTE异网融合技术应用于地铁通信系统，通信带宽更高、连接更快、承载能力也更强。而目前看来，15号线也并未出现通信问题而引发的驾驶失误。
归根究底，目前的全自动驾驶地铁虽然将驾驶员“赶”下了列车，但在面对突发情况时却还是要依赖站台的工作人员来紧急制动。对此，也有不少网友发出质疑，地铁车门与屏蔽门为何不能像电梯门一样有防夹机制?
据业内人士介绍，目前的城市规定交通车辆的车门和屏蔽门均设置防挤压功能，当车门或屏蔽门关闭过程中夹人或夹物时，该功能生效，车门或屏蔽门会自动尝试关闭三次，若仍无法正常关门，车门或屏蔽门会保持打开状态。
值得注意的是，即便车门完全打开，目前的自动驾驶系统也并不会向相关人员发出指令或警告，而是由列车自动控制系统发出警告，IBP盘上的指示灯亮起，需要站台工作人员上前解决。这也是大家上班通勤经常会遇到的场景——工作人员或志愿者上前劝阻那些试图挤上车的乘客……
据业内人士介绍，也正是因为类似事件的发生概率过高，所以才没有在软件层面设置相应的突发情况报警，而当真正的突发事件发生时，这无疑也在某种程度上影响了综控室、站台与列车之间的协作。
写在最后
诚然，地铁自动驾驶从底层的数据通信，到列车行驶与后期运营都已经形成了相当成熟、完备的体系，并且在随着通信技术、大数据、AI的发展而持续迭代。但此次事故无疑也为一路高歌猛进的全自动驾驶地铁降了降温，面对突发事件，系统除了做好自己的本职工作——驾驶，能否为工作人员施救提供帮助?
毫无疑问，我们不能因单一事件而否定成熟技术的应用前景，但是，作为乘客，我们也应该明晰，全自动驾驶并没有想象中那么“聪明”。
参考资料：
1.《全国首例!卡斯柯基于车车通信的列车自主运行系统完成现场多车无人驾驶测试验证!》，中国通号
2.《上海地铁乘客被夹身亡，全自动驾驶足够安全吗?》，电子发烧友网
3.《国内首条+最高等级+全自动驾驶!这条轨道交通厉害了》，中铁十四局
