Signals - Weird but wonderful questions

[ComUtoR]

As usual I come with some technical questions from a professional perspective. These don't often end well but cheers in advance for those who may understand the limitations.

Signal testing.... I often hear that signals can be 'downloaded' and that they have data logging. Possibly, maybe, hopefully, pretty please.. Does anyone have an example of what it shows or could explain what is logged ? I also hear that signals are 'destruction tested' I'm not sure if that is the correct term but it is a phrase I've heard *recently.... What does this involve please ? I'd be VERY, VERY interested to know what that's all about. Are there limitations based on the box type and interlocking ?

I appreciate that this may cross some industry boundaries and anyone outside looking in, please forgive me. Suffice to say 'Brown stuff, blowy thing, lots of mess'






*nudge nudge, wink wink...

 

[godfreycomplex]

As usual I come with some technical questions from a professional perspective. These don't often end well but cheers in advance for those who may understand the limitations.

Signal testing.... I often hear that signals can be 'downloaded' and that they have data logging. Possibly, maybe, hopefully, pretty please.. Does anyone have an example of what it shows or could explain what is logged ? I also hear that signals are 'destruction tested' I'm not sure if that is the correct term but it is a phrase I've heard *recently.... What does this involve please ? I'd be VERY, VERY interested to know what that's all about. Are there limitations based on the box type and interlocking ?

I appreciate that this may cross some industry boundaries and anyone outside looking in, please forgive me. Suffice to say 'Brown stuff, blowy thing, lots of mess'






*nudge nudge, wink wink...

I will endeavour my best explanation however I am very willing to be corrected if I’ve got something wrong, I’m from an operational background rather than a maintenance one so I’m a fellow student of these things more than an expert, but anyway AIUI

Any piece of signalling equipment operated electrically has a level of voltage that it draws when it is used. Essentially a voltimeter is attached to each of the pieces of equipment under advisement, which takes a near constant reading and sends a trace to a computer program. Downloading signalling equipment essentially entails taking a voltage trace (or indeed current trace in certain scenarios) over a specified period of time to see if the equipment has operated or not operated a particular way.

Two hypothetical examples of this are

1 - if a driver, having been reported as having passed a signal at danger, alleges that the signal was in fact off (showing a proceed aspect for the uninitiated). In that case the traces for the aspects of the signal in question can be downloaded to show, with certainty, what voltage was being directed to what aspect (all aspect in signals have discrete electrical supply to reduce the risk of displaying the wrong aspect), and therefore finding out with certainty what aspect the signal was displaying at any given time

2 - If a track circuit or axle counter should fail, the voltage and current to that track circuit can be monitored in the same way to illustrate the precise time and nature of the failure, which can save a good amount of time in narrowing down the nature of the response

In terms of destructive testing I know less about this I’m afraid, but it most often comes up in the case of wrong side failures. Say for example a track circuit fails wrong side (again for the uninitiated, essentially a train disappears from the signalling system, allowing other trains to be signalled into the area that that train occupies, obviously a very grave and thankfully very rare occurrence that is taken very seriously). If one or multiple pieces of electrical equipment were suspected to be at fault, in order to check this is the case (and therefore eliminate other possible causes and speed the repair process) that piece of equipment would have to be tested. Typically this would be performed in the first instance using normal levels of voltage and current that would be expected for that piece of equipment (a process known as non destructive testing). If there are still doubts after this process, the levels of voltage and current would be increased to the point that they would damage the piece of equipment to the extent that it could not be used again (destructive testing).

As I say corrections welcomed, and HTH

 

[endofthetunnel]

Again I’m no technical expert at all but am often on one end of the process:

Depending on the complexity of the area, and age of system, most of the data downloads mentioned are now combined into a remote software system which then basically shows a live graphic representation of what the signalling should be doing, with track circuits, points positions and signal aspects etc. The detailed readings are all contained within for the really technical stuff, but it allows a quick look over the whole area and is easy to understand and watch in real time if trying to fault find, for example.

This is all recorded can also be replayed back to show what actually happened - like an aircraft black box. Every lever pull/button push/track circuit occupation is recorded and in the case of incidents is easily watched.
Slightly off topic but all voice communications are recorded also, as well as the more ‘public’ data of Train descriptions, TRUST etc, so all can be used together to investigate issues and incidents.

Usually ‘destructive testing’ is the phrase used for trying to make something fail (though doesn’t normally mean it is forever broken)
So if it’s alleged for example a signal showed the wrong aspect, every single possibility will be tested in every condition - occupying tracks, moving points, trying different sequences- doing everything possible to create the failure to prove beyond doubt if it works or not.

Hope that’s helpful

 

[eman_resu]

Ive been involved in a few different methods of logging.

#1 Most computer based train control systems will record both the actions of the signaller and the inputs from the field equipment as it displays these on the signallers screen. That way, for example if there is contention re a SPAD for instance, the log can be replayed on the same system as the signaller uses to observe any issues arising. We used this system to diagnose an issue with level crossing tail ringing a while ago when a specific route was set and the replay showed the route set, tracks dropping and picking as the train moved through, and the crossing activating.

#2 Some level crossing predictors (I'm sure the GCP does this) log certain parameters, such as track voltage levels, and actual approach timings, both to for fault diagnosis as well as condition monitoring for maintenance purposes.

#3 There are also separate loggers that have specific inputs assigned to functions, for instance with a level crossing logger it may record the track relay for the initial strike in, the stage 1 bell activation relay dropping etc, and is also configured to send an alarm for instance if the crossing doesn't recover within a specified period after the island track has cleared, or the approach track(s) not picking in the correct order (or before the island track). Siemens SEARS II and Broderson are examples of these.

#4 Certainly Frauscher have their own logging equipment which will record certain parameters for review when required.

It is much simpler nowadays with computer based systems, however there are many products out there that can monitor outputs from relay based equipment, and can do clever things with the information they receive.

 

[JN114]

Destructive/Non-Destructive Testing

Non-Destructive testing preserves the thing being tested, exactly as it is (putting a meter on contacts for example).

Destructive testing might involve removing/replacing components, cutting/replacing leads etc. What you’re left with afterward isn’t precisely what you started off testing.

 

[John Webb]

I'm uncertain that 'destructive testing' is carried out once equipment is installed. A small sample from a production run may well be tested in the factory to destruction eg over-voltages, high and low temperatures and the like; this assumes that a random sample represents the behaviour of the whole batch. Such tests therefore can't be done 'lineside' as they require specialist facilities. So if a piece of lineside equipment needs testing because it may be faulty, it might well be replaced and tests carried out elsewhere.

 

[The Planner]

Instead of destructive testing, do you mean soak testing?

 

[endofthetunnel]

‘Destructive testing’ is definitely the railway term for the S&T testing done after incidents where the function of signalling is questioned (as opposed to non destructive, which as said, leaves things intact and as was) and that’s what the OP was after an explanation of, presumably after hearing the term.

This is what has been explained in a couple of ways, presumably due to slight differences in understanding but effectively the same process - trying to prove everything worked correctly by doing everything you can to check.

As always, there may of course be other definitions in other worlds, and other terms for types of testing, but that is for another thread.

 

[Tim M]

Signalling products and systems are designed to specific national and international standards, that includes environmental, mechanical and Electromagnetic Compatability (EMC) requirements. This following only touches on the subject.

At Westinghouse (now Siemens) in Chippenham new electronic and computer based products were (when I retired a few years ago) put through the environmental test chamber to ensure they worked at the requisite minimum and maximum temperatures (say -30 degrees C to plus 70 degrees C for trackside modules). In addition rigorous EMC testing was carried out, the railway, particularly when electrified, being a very dirty EMC environment. Such testing might need to be redone to suit new applications, e.g. for European railways using 16 2/3 Hz traction or 60Hz in the America’s.

Mechanical and other testing would be carried out where necessary, for example a level crossing barrier system from a sister company in the USA was put through cyclical testing, barriers going up and down every few minutes for what seemed like years!

Additional testing may be required in the field, one small example from my own experience being EMC tests being done on train carried ATP installed on some battery electric locos used on Singapore MRT.

Some testing would also be carried out in soak chambers in the factory for production units, this being designed to weed out equipment that didn’t meet the stringent design requirements that could lead to lower levels of availability.

This doesn’t cover functional testing of a installed systems, that’s a big topic in itself.

 

[niggill617@gma]

1 - if a driver, having been reported as having passed a signal at danger, alleges that the signal was in fact off (showing a proceed aspect for the uninitiated). In that case the traces for the aspects of the signal in question can be downloaded to show, with certainty, what voltage was being directed to what aspect (all aspect in signals have discrete electrical supply to reduce the risk of displaying the wrong aspect), and therefore finding out with certainty what aspect the signal was displaying at any given time

Are all signals fitted with data recorder equipment?

 

[alxndr]

The “destruction” referred to in destructive testing is that of evidence/the fault condition. The equipment may well still be serviceable afterwards, and it may appear at first glance that a specific test step has been erroneously categorised as destructive, but there will be an element of risk that the condition will be destroyed by the testing. For example, a wire count* is generally, but not always, classified as a destructive test as it's possible that in the process of moving wiring to be able to view them properly something could be disturbed.

The official word on destructive testing is that they "can sometimes alter the electrical, mechanical or physical state of the equipment. This disturbance might make a repeat of the fault impossible." They require authorisation beyond the usual competence of faulting and maintenance staff, and the authority should only be given once it has been determined that as the fault has not been identified and there is no further non-destructive testing that would be able to locate it. The authority to move to destructive testing should be given by an independent mind (e.g. not someone previously involved in the testing) to cast a second eye over the findings up until that point.


* A wire count is a visual examination to determine how many wires are present at each termination, and whether this matches with the wiring diagrams.

 

[ComUtoR]

do you mean soak testing?

Nope (but I did google that. Cheers for the additional knowledge)

‘Destructive testing’ is definitely the railway term for the S&T testing done after incidents where the function of signalling is questioned (as opposed to non destructive, which as said, leaves things intact and as was) and that’s what the OP was after an explanation of, presumably after hearing the term.

Yep


Thank you to everyone.

 

[Horizon22]

Yes I've often seen details of whereby non-destructive testing takes places, which is logs, meter readings, visual inspection, resets etc. which has essentially left the infrastructure "undisturbed" in an attempt to diagnose and resolve the fault. Whereby this is unsuccessful - or the parameters/scenario that was attempting to be recreated couldn't be replicated - destructive testing ensues which normally means physically altering the equipment / dismantling / cutting cables as those above have said. This normally requires an escalation to a higher level of management.

Normally where there is a report of some sort of operational incident and the infrastructure is believed to be at fault (either fully or partly) or is suspected to be is when destructive testing gets undertaken.

 

[MarkyT]

Are all signals fitted with data recorder equipment?

Not the signals as such, but interlockings and level crossings have been equipped with data loggers for years. Processor-based interlockings since SSI in the late 1980s have included such logging built in, while with relay systems, the loggers are connected to voltage-free contacts of the 'primary relays' for each function in the particular relay room. The diagnostic tools available today for use with such gathered data continue to improve to assist technicians with their routine fault finding and prediction and with post-incident investigations.

 

[TSG]

Signal testing.... I often hear that signals can be 'downloaded' and that they have data logging. Possibly, maybe, hopefully, pretty please.. Does anyone have an example of what it shows or could explain what is logged ? I also hear that signals are 'destruction tested' I'm not sure if that is the correct term but it is a phrase I've heard *recently.... What does this involve please ? I'd be VERY, VERY interested to know what that's all about. Are there limitations based on the box type and interlocking ?

There are 3 main types of monitoring fitted to signalling:

• Condition monitoring - This typically uses current transducers to measure current going to point motors or track circuit relays. A data logger will upload this constantly to a central server. Deviations such as a slower throw of points or low current to a track relay will alert infrastructure controllers to a possible imminent fault. A graph of the current over time can be seen, perhaps alongside other relevant data. This data would be also available for analysis after an incident of course.
• Event recording - Where relays are used a data logger can be fitted. Most relays have some unused contacts. Each of the important relays (e.g. the HR which allows a proceed aspect when its up) will have a spare contact connected to the data logger (note that this does not connect the data logger to the signalling circuits). This sends a wetting voltage over the contact and detects if is open or closed. It doesn't record a voltage trace, just a timestamp and HR up or down each time a relay operates. Again this will often be sent in near real time to a central server. You can view a time ordered list of all the relay operations
• Built in condition monitoring/event recording - This covers pretty much any thing with a processor in it. All Computer Based Interlockings, some axle counters, some track circuits and even some point machines and barrier machines have built in facilities. These can either be downloaded on site as needed or, more typically now, are uploaded to a central server constantly. This information varies with the equipment but it will usually be very comprehensive.

Limitations are that some places may still not have a data logger fitted, or there won't be spare relay contacts for everything to be monitored.

Any piece of signalling equipment operated electrically has a level of voltage that it draws when it is used. Essentially a voltimeter is attached to each of the pieces of equipment under advisement, which takes a near constant reading and sends a trace to a computer program. Downloading signalling equipment essentially entails taking a voltage trace (or indeed current trace in certain scenarios) over a specified period of time to see if the equipment has operated or not operated a particular way.

Two hypothetical examples of this are

1 - if a driver, having been reported as having passed a signal at danger, alleges that the signal was in fact off (showing a proceed aspect for the uninitiated). In that case the traces for the aspects of the signal in question can be downloaded to show, with certainty, what voltage was being directed to what aspect (all aspect in signals have discrete electrical supply to reduce the risk of displaying the wrong aspect), and therefore finding out with certainty what aspect the signal was displaying at any given time

2 - If a track circuit or axle counter should fail, the voltage and current to that track circuit can be monitored in the same way to illustrate the precise time and nature of the failure, which can save a good amount of time in narrowing down the nature of the response

We do not typically measure voltage with data loggers. That would require connecting data logging equipment directly to signalling equipment. If you can get voltage out you can put voltage in, so its not a great idea. Almost everything can be done with spare contact monitoring or current transducers.

 

[MarkyT]

...

• Event recording - Where relays are used a data logger can be fitted. Most relays have some unused contacts. Each of the important relays (e.g. the HR which allows a proceed aspect when its up) will have a spare contact connected to the data logger (note that this does not connect the data logger to the signalling circuits). This sends a wetting voltage over the contact and detects if is open or closed. It doesn't record a voltage trace, just a timestamp and HR up or down each time a relay operates. Again this will often be sent in near real time to a central server. You can view a time ordered list of all the relay operations.

These are the voltage-free contacts of primary relays I mentioned in my comment above

We do not typically measure voltage with data loggers. That would require connecting data logging equipment directly to signalling equipment. If you can get voltage out you can put voltage in, so its not a great idea. Almost everything can be done with spare contact monitoring or current transducers.

A very good point. Loggers are not safety verified to the same level as the interlocking itself so could potentially introduce some degradation to the equipment integrity if electrically connected directly to any active circuit.

 

[4COR]

Instead of destructive testing, do you mean soak testing?

Approaching this from a non railway background, but with a fairly strong background in software testing (including non functional and performance/load testing) - does soak testing mean the same thing here as it would to me?

I may define it as "testing that involves a typical production load/user journeys over a continuous period to evaluate the long term behaviour of a system to ensure there is no degradation to service over time."

 

[2192]

Ive been involved in a few different methods of logging.

#1 Most computer based train control systems will record both the actions of the signaller and the inputs from the field equipment as it displays these on the signallers screen. That way, for example if there is contention re a SPAD for instance, the log can be replayed on the same system as the signaller uses to observe any issues arising. We used this system to diagnose an issue with level crossing tail ringing a while ago when a specific route was set and the replay showed the route set, tracks dropping and picking as the train moved through, and the crossing activating.

What's "level crossing tail ringing" ? (thanks).

 

[Tim M]

Are all signals fitted with data recorder equipment?

Can I rephrase your question, ‘Are signalling systems fitted with data recorder equipment?’.

Others may know if relay based or mechanical signalling systems have been retrofitted with data recording equipment. However Computer Based Interlockings (SSI, Westlock, WESTRACE, Smartlock etc.) do log data recording facilities. Typically these record changes of state within the interlocking data, for example occupation and clearance of track circuits, route setting, point movement, signal aspect changes etc. etc.. It is possible to analyse these logs manually, and maybe on a playback simulator for test purposes or following an incident. Note also control centre systems have logging capabilities.

Separate data logging may be provided on specific elements of the signalling system. The Frauscher axle counter system includes a technician terminal to assist in fault finding and maintenance. Point machine monitoring independent of the interlocking can be added to record operating times, a trend towards longer ‘throw’ time would suggest maintenance is required.

All this information can be used by technicians to support fault finding, maintenance and repair.

 

[E27007]

Yes, Solid State Interlocking had a Flight Recorder Black Box from the same company who supply to aircraft. It is called a Black Box, but they are painted orange.
The Relay interlocking systems, from about 1995, had independent monitoring systems added on, the monitoring circuits were wired into the unused contacts in the relays. The Signalbox Techs could review / playback the status of the relays for the purpose of faultfinding and maintenance, such as timing the points as they swung across, a slow swing indicating trouble.

 

[TSG]

Approaching this from a non railway background, but with a fairly strong background in software testing (including non functional and performance/load testing) - does soak testing mean the same thing here as it would to me?

I may define it as "testing that involves a typical production load/user journeys over a continuous period to evaluate the long term behaviour of a system to ensure there is no degradation to service over time."

With new equipment, if the opportunity exists to soak test the equipment by powering it all up in situ and perhaps even allowing it to run in parallel to an extent (e.g. axle counters work whether the interlocking is looking at them or not) this will be done. Typically this is for new schemes. With hardware of course this is mainly to pick up faults in manufacture/install, those at the the front of the bathtub curve. Arguably, in the software engineering context, soak testing is to make up for inadequate test coverage of the design since software does not suffer random faults .

As has been pointed out 'destructive' in the context of Signal Maintenance testing means potentially destructive of evidence of cause, not the equipment itself.

 

[niggill617@gma]

Not the signals as such, but interlockings and level crossings have been equipped with data loggers for years. Processor-based interlockings since SSI in the late 1980s have included such logging built in, while with relay systems, the loggers are connected to voltage-free contacts of the 'primary relays' for each function in the particular relay room. The diagnostic tools available today for use with such gathered data continue to improve to assist technicians with their routine fault finding and prediction and with post-incident investigations.

Interesting thanks.

I just wonder how RAIB came up with 20 mph past a red signal for 200 m. This written fact must have come from signal data recording equipment, as the OTDR was not milked.

This fact if correct opens a can of worms, regards the investigation.

 

[4COR]

With new equipment, if the opportunity exists to soak test the equipment by powering it all up in situ and perhaps even allowing it to run in parallel to an extent (e.g. axle counters work whether the interlocking is looking at them or not) this will be done. Typically this is for new schemes. With hardware of course this is mainly to pick up faults in manufacture/install, those at the the front of the bathtub curve. Arguably, in the software engineering context, soak testing is to make up for inadequate test coverage of the design since software does not suffer random faults .

Thanks for the explanation! (Soak testing in the context of software performance often also allows you to pick up items like memory leaks which may occur/accumulate slowly during usage, but otherwise wouldn't be picked up by, say, functional tests - but yes, with the exception of defects like reading from un/de-allocated memory or issues around threading, software doesn't tend to randomly fail - cosmic rays aside )

 

[alxndr]

I just wonder how RAIB came up with 20 mph past a red signal for 200 m. This written fact must have come from signal data recording equipment, as the OTDR was not milked.

I have no idea what incident you're referring to, but if the area had a separate track circuit for the signal overlap and this was monitored, then it could be easily worked out by measuring the time elapsed from the track circuit occupying to clearing.

 

[niggill617@gma]

I have no idea what incident you're referring to, but if the area had a separate track circuit for the signal overlap and this was monitored, then it could be easily worked out by measuring the time elapsed from the track circuit occupying to clearing.

That is what I understand as well. The report is 10/2020, paragraph 3 calculates out to less than half the trains emergency braking rate, the report also states 20 seconds at para 31, makes no sense.

 

[rower40]

RAIB report 10/2020 (SPAD at Loughborough) states:

RAIB’s analysis of signalling data indicates an average speed around 70 mph (113 km/h), and lineside equipment recorded the train passing a point around two miles (3.2 km) before the red signal, at just over 75 mph (121 km/h) (paragraph 28).

The East Midland Control Centre's equipment will have logged the times of each track section going occupied and clear. Signalling plans of the area will give the lengths of each track section, so it's straightforward to calculate average speeds.

 

[niggill617@gma]

RAIB report 10/2020 (SPAD at Loughborough) states:

The East Midland Control Centre's equipment will have logged the times of each track section going occupied and clear. Signalling plans of the area will give the lengths of each track section, so it's straightforward to calculate average speeds.

RAIB will have presumably milked the signal data recorder, and track plans etc? So, 200 m for 20 seconds is approximately 44 mph past the red signal. The report states 20 mph past the Spad signal.

 

[GC class B1]

RAIB report 10/2020 (SPAD at Loughborough) states:

The East Midland Control Centre's equipment will have logged the times of each track section going occupied and clear. Signalling plans of the area will give the lengths of each track section, so it's straightforward to calculate average speeds.

The concern I have with this report is that in the absence of OTDR data, the conclusions as to the sequence of events must have been based predominantly on the signal system timings, supported by the drivers recollection. The report stated that the train passed the red signal at 20MPH but from earlier posts it appears that the signalling system doesn’t provide this information.
Using the data in the report, it appears that the speed the train passed the red signal at considerably more than 20 MPH. I have calculated that in order to recreate the circumstances of the incident I.e. passing the red signal by 200 metres, with a Full Service brake application, as determined by the post incident stopping distance tests, the train would have passed the red signal at about 28MPH and not 20MPH as suggested in the findings. If the speed of the train at the SPAD signal was 20MPH then the train braking performance on the day of the incident was much less than found in the post incident testing - possibly only about 50% of the post incident Full Service brake force.

 

[alxndr]

RAIB will have presumably milked the signal data recorder, and track plans etc? So, 200 m for 20 seconds is approximately 44 mph past the red signal. The report states 20 mph past the Spad signal.

An average speed of 22mph is needed to cover 200m in 20s.

Furthermore, it report only states about 20 seconds and approximately 200 metres. It's likely that the only data that exists will be for the average speed over the first 183m past the signal.

 

[GC class B1]

An average speed of 22mph is needed to cover 200m in 20s.

Furthermore, it report only states about 20 seconds and approximately 200 metres. It's likely that the only data that exists will be for the average speed over the first 183m past the signal.

Are you surmising that RAIB derived the speed passing the red signal by calculating the average speed over the 183 metres (overlap distance?) and that the average speed has been derived from the signal timings. If the average speed over this distance was 22MPH then the train cannot have passed the red signal at 20MPH.