列车全自动洗车的异常处理闭环与集中

最近，我正在根据大佬们各方讨论的列车全自动洗车方案进行编码，其中踩了几个比较简单的坑，但是也衍生出一些对洗车流程方案的思考，引发自己对面向过程的异常进行总结。

洗车流程

首先我先对列车洗车的过程做一些介绍

1、中心下发洗车计划
2、列车进路到达，自动运行到请求洗车点
3、允许洗车，换弓，运行到前端洗车，踩个刹车
4、洗完前端，暂停一下执行换弓，行驶到洗后端
5、退出洗车，折返

这个流程太简单了，我这个组件只有700多行，让我这个萌新，感到了事情不简单呐。

整个流程中，对异常的监督极其简单，这是极其违背我车载防护系统天赋使命的。

我司对洗车有两个监督，一个是由联锁转发给VOBC的洗车机故障码位，二是洗车机由Ci转发给VOBC的禁止指令。

大家发现了，两个退出洗车原因都是来自洗车机。

但是，作为全自动驾驶，权力最高的还是控制中心吧，应该没有考虑到，当这个由PLC控制的机械怪兽一旦总线断了或者本身逻辑死锁（PLC还是很可靠的）,这个车就只有一泡在洗车机里把车皮都洗烂。

全自动，意味着控制中心必须要了解一切情况与告警，否则还是叫半自动好一点。

问题

整个方案中，没有一处对洗车超时进行控制，我认为从车一开始接收到ATS下发的洗车指令，就应该开始计时，以保证车不会因为洗车机的故障而非正常停车在洗车库中，从而延误了整个排好的洗车计划。

思考-问题的升华与总结

在流程处理中，异常处理往往是这种高安全系统最需要考虑的，不仅仅是洗车，ATP这几十万行代码来说，就是要求整个列车在对的时间做保证安全的事情，保证安全。而这里就对整个流程的时间从而抛弃，可能PLC的洗车内部有时间计时从而向ATP汇报故障，但是，作为最重要的车载设备，我们必须重视超时所带来的异常。这个总结可以上升到面向过程的各种异常处理机制，过程都是时间线的，我们只有把控好时间，才能最大化收益，最小化风险，毕竟，时间能带给我们什么，是神秘的。