They were overwhelmed when the timetable was entered in the CIS months ago? Linking arrivals and departures should be standard.
No it shouldn’t because it makes far too many assumptions. I don’t think diagram information is typically uploaded into CIS anyway.
The timetable being entered in CIS ages ago has nothing to do with it. I can offer an explanation if you are happy to listen to it, having done the job for 8 years rather than just criticise staff without knowing how the systems work, I completely understand why you have to make out why all staff are lazy and should be replaced by robots. But let me explain first.
Arrivals and Departures are linked in CIS and they are called “associations” most operators have these, however some don’t. Northern have them enabled however not for all services.
Associations only work when there is a
delay. That’s a system feature, nothing to do with Controllers input
. However controllers can manually add and break associations
Let’s use the example of Buxton like here. Trains at Buxton will generally have a 52 minute turnaround. If there is a delay on the inbound service, CIS will automatically cascade the next workings delay by 3 minutes. So if a train was planning to arrive at Buxton 52 minutes late then automatically CIS would show the next working as departing 3 minutes late.
However, this doesn’t account for Traincrew PNB and this has to be manually inputted if the Traincrew are due PNB at Buxton then this automatic information is wrong. Therefore controllers would need to go into another program Tyrell which feeds Darwin which feeds CIS. Controllers would need to input a reason from a pre-select enter the headcode and apply a manual delay based on the Traincrew PNB. This then displays on CIS.
So that’s associations explained.
At the same time Controllers have to create a route disruption that’s the “Due to trespassers on the railway at Manchester Piccadilly, all lines are blocked” message which feeds the likes of JourneyCheck is disseminated to NRE, front line staff and to the media. For an incident like this clearly a CSL2 the core disruption message has to be updated
every 20 minutes. That’s the principles set out by PIDD guidelines.
At the same time with I’d say within that disruption and the amount of trains involved then the Controller would have had to manually input around 50-100 trains into Tyrell cancel them using the pre-selected reason once they are cancelled this is fed to CIS/Darwin and appears on the departure boards. And that’s why yesterday so some services may not have been cancelled because it has to be done manually.
While all this is happening the Controllers phone is ringing non-stop no sooner do you put the phone down it rings again and again and again, so they are trying to get the information out, answer the phone, listen to conversations within the ROC for information to keep the Customer Info updated and cancellations updated.
And guess what like any other part of the railway, Control are under resourced and sometimes it may go unnoticed the job might just tick along but you may be in the chair for 12 hours and be lucky if you get to go for a break or go to the toilet or make a cuppa. We can’t just down tools and go for a break. You take your break if you get one around how the network is performing. Eating at your desk in between answering the phone and doing work it’s all normal. Some days the under-resourcing will go unnoticed but on days like yesterday it gets highlighted.
However, it’s a job I love, I’m passionate about and show a genuine interest. Improving customer info and having got to know the intricate details of each of the systems I’m a massive advocate of it and what we can do better. It’s a very rewarding job but can be a stressful job at times.
I’m sure there will be some clever responses about automation, and like anything else when it comes to the railway and automation we’ll just laugh.