Are PIS malfunctions monitored?

[TUC]

For over three weeks, the PIS display on platform 2 at Sowerby Bridge has been displaying service information for totally the wrong times of day (See photo).

Having such an error for so long makes me wonder whether any error messages are sent to Control (or elsewhere) when they occur, or are they totally reliant upon someone reporting them? (I also noticed that I was not the only passenger taking a photo of the display, presumably for reporting to Northern, so it does beg the question whether any action is taken, even when reported?)

 

[Undiscovered]

Usually the guard will send a quick email to Control, notifying them of the fault. That relies in the guard being in a position, on the platform during dispatch, to see the PIS is faulty, or a passenger informing them of the issue.

 

[The exile]

For over three weeks, the PIS display on platform 2 at Sowerby Bridge has been displaying service information for totally the wrong times of day (See photo).

Having such an error for so long makes me wonder whether any error messages are sent to Control (or elsewhere) when they occur, or are they totally reliant upon someone reporting them? (I also noticed that I was not the only passenger taking a photo of the display, presumably for reporting to Northern, so it does beg the question whether any action is taken, even when reported?)

Presumably the error here is that it is showing “17” instead of “07”. Not sure otherwise how it knows that a train is going to be a few minutes late 10 hours in advance.

 

[greatkingrat]

It appears to be showing yesterday's data, when the 1757 did run a few minutes late.

 

[Crossover]

It may be worth (if you are on the platform) popping a message to Northern on Facebook or similar. I did only the other day, as it seems like at my local station, the announcements are playing on the wrong platform. Something which rail staff won't be aware of either.

 

[skyhigh]

Not sure otherwise how it knows that a train is going to be a few minutes late 10 hours in advance.

It's showing old data, not predicting the future.

That particular screen is always getting stuck.

I have no idea if it's included in the current CIS upgrade programme, but I would assume so as the similar screens at other stations have been done.

 

[Horizon22]

I would suggest that they are not without being actively monitored on the ground.

Often frustrating to find a fault has been going on for days and the response has been “oh we thought someone knew”. It’s a local failure which is unlikely to flag to Control.

Sometimes screens get ‘stuck’ and need nothing more than a reboot (I.e turn them off and on again) to resolve.

 

[CharlieSpotted]

Then there's the one above the gateline in Wolverhampton which has been showing, sideways, "Welcome to Birmingham Snow Hill" for the last week or more...

 

[Fasty]

Then there's the one above the gateline in Wolverhampton which has been showing, sideways, "Welcome to Birmingham Snow Hill" for the last week or more...

There's another in Gatwick airport just after the gateline that says 'Refer to Timetables'. I have been to Gatwick many times in the past couple months and have seen no timetables.

 

[TUC]

It does seem another of those examples where, because our own phones and laptops give live alerts of any system error they encounter, as are IT alerts a core part of IT systems at work, we assume that electronic ‘live’ rail information systems do the same. The reality is different.

 

[Horizon22]

There's another in Gatwick airport just after the gateline that says 'Refer to Timetables'. I have been to Gatwick many times in the past couple months and have seen no timetables.

That basically means the screen has lost connection.

 

[yrreb]

The simple answer is yes, even if screens appear to have had issues for a longer period of time. These things are picked up through service quality audits as well as whether it’s picked up by conductors on the platform.

 

[saismee]

Often frustrating to find a fault has been going on for days and the response has been “oh we thought someone knew”.

This is one of the most important things in QA... if something is broken, report it! Still broken the next day? Report it again. If you pester them enough, it'll get fixed more quickly. Otherwise it will certainly get forgotten about.

 

[DynamicSpirit]

I would suggest that they are not without being actively monitored on the ground.

Often frustrating to find a fault has been going on for days and the response has been “oh we thought someone knew”. It’s a local failure which is unlikely to flag to Control.

Sometimes screens get ‘stuck’ and need nothing more than a reboot (I.e turn them off and on again) to resolve.

It does seem astonishing if there is no automatic mechanism for whoever is responsible for maintaining the screens to become aware if a fault develops preventing a screen from displaying the correct information. I mean, in these hyper-connected days, it's hardly rocket science for some software running on a client to be able to regularly inform a central server of its status. Even a lost connection should in principle easily be detectable by the absence of regular status reports, or requests for updated departure info, from a screen. The only thing that I could imagine would realistically require manual monitoring would be a fault in the display itself (pixels unable to show) etc. But that's not the case in the examples in this thread, which are clearly examples of faults in the software that works out what to display.

 

[norbitonflyer]

Not a malfunction of the screen. but of the software driving it, is a train remaining on the screen, showing "on time" or "expected at ....." long after that time has passed. Which means it was on time (or x minutes late) at the last timing point before it was diverted via another route, and therefore never passed the next timing point, and will never arrive.

Also a glitch is to show "delayed" (ie not yet left the terminus) trains in the order they would be were they on time, even though other trains are close at hand and obvkioously going to get to you sooner. eg 1st train 1 minute, 2nd train delayed (in fact at least fifteen minutes away), 3rd train 5 minutes. leads to confusion as the trains appear to leapfrog each other (at least the 1st train is usually right)

 

[johntea]

They might have alerts set up, but in my many years of IT I've come across many, many alerting systems that have been set up only for nobody to have the time to actually monitor them so all a bit of a waste of time really (or where they've been set up to log absolutely EVERYTHING so the important stuff just gets lost in a sea of other alerts)

Also I suspect their repair priority is far greater for TVMs out of action costing them £££ in lost sales every minute rather than dodgy departure screens

 

[DynamicSpirit]

Also a glitch is to show "delayed" (ie not yet left the terminus) trains in the order they would be were they on time, even though other trains are close at hand and obvkioously going to get to you sooner. eg 1st train 1 minute, 2nd train delayed (in fact at least fifteen minutes away), 3rd train 5 minutes. leads to confusion as the trains appear to leapfrog each other (at least the 1st train is usually right)

I was under the impression that 'delayed' doesn't necessarily mean, not yet left the terminus, but simply could mean that they don't yet know how late it's going to be. I'm pretty sure I've seen trains showing for a few minutes as 'delayed' then their status changing to something like '2 minutes late' - so the delay was evidently not serious, but for a short period that wasn't known. Having said that, you're right that it would be good if the software system could distinguish serious delays such as, not yet left the terminus which is quite a long way away.

 

[Horizon22]

It does seem astonishing if there is no automatic mechanism for whoever is responsible for maintaining the screens to become aware if a fault develops preventing a screen from displaying the correct information. I mean, in these hyper-connected days, it's hardly rocket science for some software running on a client to be able to regularly inform a central server of its status. Even a lost connection should in principle easily be detectable by the absence of regular status reports, or requests for updated departure info, from a screen. The only thing that I could imagine would realistically require manual monitoring would be a fault in the display itself (pixels unable to show) etc. But that's not the case in the examples in this thread, which are clearly examples of faults in the software that works out what to display.

But sometimes the system/software is working as intended, it is the local hardware that is playing up. This is why prompt reports from station staff (or train crew, or hell even the public via social media) are important so the fault gets resolved as soon as possible.

Also a glitch is to show "delayed" (ie not yet left the terminus) trains in the order they would be were they on time, even though other trains are close at hand and obvkioously going to get to you sooner. eg 1st train 1 minute, 2nd train delayed (in fact at least fifteen minutes away), 3rd train 5 minutes. leads to confusion as the trains appear to leapfrog each other (at least the 1st train is usually right)

"Delayed" is where the train has not departed from the last point (usually TD/berth) in 3 minutes. This is what the system defaults to when it has no other inputs.

For example train running from A-H, you are standing at B and the train has not departed origin (A) with no manual delay added. It is not a "glitch"; it is intended behaviour.

 

[TUC]

The simple answer is yes, even if screens appear to have had issues for a longer period of time. These things are picked up through service quality audits as well as whether it’s picked up by conductors on the platform.

How often do service quality audits take place? I suspect not often enough to deal with faults in a live service.

As said above, so much of our world is built around technology and automated updates/fault reporting, it seems a little surprising that PIS don't have the same by default.

 

[Skie]

Email northern or use their websites contact us form. I reported poor PA on a station a while back (Not Northern, but basically an old speaker near the booking office was all it had) and they acknowledged it quickly, had someone from Network Rail out a week later who confirmed what I’d reported and a few months later the platform had a load of new speakers along its length.

It can be incredibly difficult to have a way to monitor failures on IT systems.

For things like hardware where off = bad then you have an easier job, but when it’s displaying dodgy info like this you have a challenge: what exactly constitutes a failure? And how can you identify it without picking up on all the other variables as false positives?

Sometimes the Mk.1 eyeball is the best tool for the job.

 

[norbitonflyer]

This morning at Kingston, there were no trains to Waterloo and (by either route) until 1011 because Control, in their wisdom, had sent most of the Sheppertons via Richmond and Brentford (the Richmond route was closed for engineering work, so the loop[ service was only running between Kingstin and twickneham, and most of them were cancelled anyway). Not that the PIS was telling us this. We were waiting for the 0734 (trying to get to Euston for an 0840 departure, and already having had the 0719 cancelled), and the first anyone knew anything was wrong was when I checked OTT and saw it had turned left at Fulwell.
Both RTT and the PIS still showed it as merely a few minutes late, when in fact it was never coming at all.
According to RTT, the next train to leave platform 3 at Kingston was over two hours later. [EDIT - now I'm on my home computer instead of a mobile connection I see it eventually left from platform 2 and went via Twickenham (reverse) and Brentford)

Don't the operators realise that people up and about at that time on a weekend are probably on a time-critical journey?

Is no-one held responsible for the misinformation given out by these automated lying machines?

The staff at the station were doing their best, but they apparently had even less information than I (using OTT Maps) had.

 

[lookapigeon]

Following on from this, what happens at a major railway station (such as Waterloo, Victoria etc) if the PIS plays up?

I noticed whilst rushing for my train this week one of the subsequent departures pages on the orange LED screens was jammed to the one from earlier in the afternoon. Does the entire board get rebooted/attended to after hours, or is there a mechanism to sort the invidual screen? I can understand if it is the former that it's left, but it does look odd and is unhelpful as it also means half the information disappears.
I presume the colourful ones are just one giant computer monitor, driven by a PC and can be easily reset if the software plays up, although you may see a Windows bootscreen (!).

 

[Annetts key]

There are various types of CIS (Customer Information Screens). Some are directly controlled by a computer running Windows, but not all are. Some use specialist computer boards running software appropriate for that board and the wanted display.

Similarly, there are a number of different methods that are used to get the information to the CIS.

I can't speak about the type in the OP, but certainly many of the older types have no in built fault monitoring as I understand it. Certainly the types used when B.R. existed didn't have this. If it wasn't included in the requirements when the system was specified, it won't exist.

As suggested earlier on, if you find a faulty or malfunctioning CIS, please report it.

I don't know how the TOCs or Network Rail treat these nowadays. B.R. engineering staff where I worked did try to at least attend on the same day that the report came in. Unless it was after mid afternoon or a over a weekend, in which case it was a job for the following working day.

 

[TUC]

There are various types of CIS (Customer Information Screens). Some are directly controlled by a computer running Windows, but not all are. Some use specialist computer boards running software appropriate for that board and the wanted display.

Similarly, there are a number of different methods that are used to get the information to the CIS.

I can't speak about the type in the OP, but certainly many of the older types have no in built fault monitoring as I understand it. Certainly the types used when B.R. existed didn't have this. If it wasn't included in the requirements when the system was specified, it won't exist.

As suggested earlier on, if you find a faulty or malfunctioning CIS, please report it.

I don't know how the TOCs or Network Rail treat these nowadays. B.R. engineering staff where I worked did try to at least attend on the same day that the report came in. Unless it was after mid afternoon or a over a weekend, in which case it was a job for the following working day.

Interesting. I assumed that modern day CIS were on far more recent operating systems and software, but it appears not. That's frustrating because, as sites like RTT demonstrate, there is far more up to date data available to passengers on their phones than that on many station screens.

 

[norbitonflyer]

Gunnersbury yesterday morning, about 9am.
2nd and third northbound trains shown as on time, but the first train was the 05-something to Upminster, running 1245 minutes late!
Which is very odd as that is about 21 hours, suggesting it would arrrive at 2am the next morning.

Whatever drives the CIS on the Richmond branch (which is of course signalled by Network Rail) does not interface well with LUL's systems. And vice versa, once a Richmond train leaves Turnham Green, it seems to dissappear off the face of the Earth as far as LUL are concerned until it magically pops up again half an hour of so later.

None of the (Southern Region/ SWT/SWR) staff at Richmond have ever seemed to know what's going on on the bay platforms, and seem surprised anyone askimng for information should think they might. (Same at Wimbledon - although the only staff are SWR, Thameslink, District Line and the Trams are "not their problem")

 

[josh-j]

Interesting. I assumed that modern day CIS were on far more recent operating systems and software, but it appears not. That's frustrating because, as sites like RTT demonstrate, there is far more up to date data available to passengers on their phones than that on many station screens.

RTT can be incorrect during disruption though, apps and official sites (not RTT) generally will be using Darwin data; I'd have thought even older station screens yse that, and it is supposed to be the primary source of passenger information.

The control software might be old but so is Darwin, and that's fine.

RTT doesn't know about cancellations as quickly necessarily because often the changes are only reflected in Darwin since that's the passenger source, and therefore shown on screens and 'the apps'. RTT is still great in other ways obviously, slightly different use case.

Someone else can probably explain properly but that's my understanding anyway.

Slightly more on topic - I've reported a faulty screen showing out of date information and it has taken weeks to resolve only to fail again exactly the same shortly after. But now the screens have all been replaced by new ones so maybe the underlying problem wasn't worth fixing it they were all about to be renewed anyway. Still a bit frustrating.

 

[kevjs]

It does seem astonishing if there is no automatic mechanism for whoever is responsible for maintaining the screens to become aware if a fault develops preventing a screen from displaying the correct information. I mean, in these hyper-connected days, it's hardly rocket science for some software running on a client to be able to regularly inform a central server of its status. Even a lost connection should in principle easily be detectable by the absence of regular status reports, or requests for updated departure info, from a screen. The only thing that I could imagine would realistically require manual monitoring would be a fault in the display itself (pixels unable to show) etc. But that's not the case in the examples in this thread, which are clearly examples of faults in the software that works out what to display.

One of the features of the 2nd Generation Nottingham City's Real Time Passenger Information Displays is that they have 4G onboard for more reliable comms than the radio network the first gen used, and are also able to report back diagnostics which the first generation couldn't. Doesn't stop them being misconfigured and thinking they are a different stop mind!

I wonder if the older ones on the national rail network are similar and don't have the capability to feed information back.

 

[lookapigeon]

There are various types of CIS (Customer Information Screens). Some are directly controlled by a computer running Windows, but not all are. Some use specialist computer boards running software appropriate for that board and the wanted display.

Similarly, there are a number of different methods that are used to get the information to the CIS.

I can't speak about the type in the OP, but certainly many of the older types have no in built fault monitoring as I understand it. Certainly the types used when B.R. existed didn't have this. If it wasn't included in the requirements when the system was specified, it won't exist.

As suggested earlier on, if you find a faulty or malfunctioning CIS, please report it.

I don't know how the TOCs or Network Rail treat these nowadays. B.R. engineering staff where I worked did try to at least attend on the same day that the report came in. Unless it was after mid afternoon or a over a weekend, in which case it was a job for the following working day.

Thanks for the insight, it's interesting to know. I was in Waterloo the other day and the screen I mentioned previously in the thread appeared to be unfrozen and working as normal, I guess someone either saw it malfunctioning, or this thread (!) and pressed the right buttons/people to get it sorted.

Years ago in SWR land the departure boards had the chunky CRT screens used to operate with a Windows software programme that would display each board fullscreen, each screen was driven with an output from the computer as part of the desktop and presumably when the software was working fine it would expand to display the departure board maximized in the relevant screen output.
You always knew when the software had gone awry as when it crashed each screen would display a chunk of the Windows desktop and whatever was on there, along with the Windows error message box.