First things first, we can't beat passengers to Twitter. The people on trains are seeing things in real time. Trains stop, they tweet.
But what do we see in the control room?
So let's consider a door fault as our example.
Typically, a door fault means the ERO cycles the doors manually and the fault clears. This is the outcome 99% of the time. Maybe a 60 second delay. Train moves, we all flag it for tracking. No comms needed.
The next escalation is that the door doesn't clear. So, the next step is door isolation. This typically takes about 3-4 minutes. The ERO leaves the cab, pushes the doors closed, locks them with an isolation switch. The controller notifies comms that trains are held for maybe 4min
By this time, Twitter is afire. The event train has been stopped for 3-4 minutes, and now there are trains being held further down the line by us in the control room because the possibility exists that diversions may be needed.
What comms are needed here, at this point? Delays, yes. A diversion is a possibility, but not imminent. We don't want to send out a diversion message yet because that decision isn't made, but we've notified the bus side to consider options for R1.
The decision on diversions doesn't get made until the isolation process fails. That's already 3-4 minutes into the event, and let's face it, the ERO will try for a few extra minutes before we evacuate a train and start diverting train traffic. Diversion isn't a snap decision.
At this point, people in my job make the decision that the trains must divert to keep moving. The event train has moved from troubleshooting to obstacle. Time to get the diversion message out about an event that has been on Twitter for 6-10 minutes already. Trains are backed up.
Diversions mean single tracking, moving people from one platform to the other, and getting that messaging out about where you need to go to catch your train. In certain sections and certain times, it means R1.
The R1 decision may come 6-8 minutes into the event because it's a last resort solution. It takes time to get buses to R1 stops. As an example, last week during the medical at PIM, R1 arrived just as the medical cleared up. These buses need to drive to R1 stops.
Many times, R1 is pulled from existing service. So they have to organize this when we first call about the fault. The planning begins, but the buses still need time to get there.
So you can see how the passenger experience differs from the operator's experience. A passenger sees the stoppage, then after waiting gets new information that may change in minutes because resolution has occurred.
The controller sees escalation of the event with each passing minute, and each escalation has it's own response, meaning the information we want to push out is changing with each change in event status.
It's difficult to figure out what to tell our customer service department to push out. What we predict will happen in any given event changes by the minute. Our decisions have real consequences, and as controllers, we don't take that lightly.
One door fault is resolved in 60 seconds. The next time it's 3 minutes. This is supposed to be the worst case scenario every time. Then one occurs that results in a train not being able to move for 10 minutes or longer.
Comms isn't easy when this happens. Especially with moving targets and the public's ability to see things before they can.
Posted 1 year ago