-
Our booking engine at tickets.railforums.co.uk (powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!
Train Describers and the Internet
- Thread starter ewsclass
- Start date
- Status
Sponsor Post - registered members do not see these adverts; click here to register, or click here to log in
R
RailUK Forums
Tempest Malice
Member
- Joined
- 12 Dec 2018
- Messages
- 39
All TD's that you see on the internet (regardless of their age) have a pair of diverse serial links to NR's SMART system, and it is from there that the messages are packed into some IP based packaging and forwarded to everywhere else. Most of the 70s/80s PSB'S that show up would have had their TD'S upgraded at some point to slightly more recent one's capable of the PS9 serial protocol used on serial links to smart; but this is the same protocol and link type all TD's no matter how new (or IP capable for links inside the signalling system) they are, will be using.
Thank you, sure:
IP - Internet Protocol (the set of rules for transporting data over a network)
ODF - Open Data Feeds (the free Network Rail data outputs that allow for seeing the position of trains and basic state of the signalling system among other features)
CCF - Control Center of the Future (An internal Network Rail tool used at various places such as signalling centers and route control to show the real time status of the signalling system. It also shows the performance of the trains by highlighting headcodes based on their timeliness)
Interesting thank you, how do the physical TD units get the inputs from the interlocking? I assume with CBI it can be done via networking and SSI via the data link? Is it a case of reading the outputs of the relays for RRI?
Tempest Malice
Member
- Joined
- 12 Dec 2018
- Messages
- 39
Sorry it's taken me while to get back to you both, it's been a busy week, anyway;
As for the other industry term which managed to escape into my message, I namedropped the PS9 serial protocol, originally intending to link to some online source about it, but all I could find was this one and as I do not suggest anyone from here actually pays to read the standard I didn't include a link but forgot to remove the name so I might as well explain it now; anyway PS9 is a standard controlled by network rail which gives a description of how train describers (and other similar systems) should talk to each other. The message type lists that the open data wiki has here and here describe what sort of data is transmitted on a PS9 link (though it describes it wrapped in the few extra layers that the open data feeds use) with the PS9 standard just describing how you encode those messages on a serial cable (see here for those unfamiliar with the parts of the 80s IT industry that the UK railway system is prolonging the survival of), anyone working with TD's back in the late 80's or early 90's would have known the standard by the name British rail gave it ("BR1810", and ok there are slight differences to the new version, but they at a level of detail that really don't matter if you aren't actually buildinng a TD).
There are yet more serial protocols used for communications are direct from SSI to TD for use when a panel is involved instead of a workstation. And in the SSI world, the term "data links" typical refer to the trackside connections, and also the connections between interlocking connections when multiple SSI's are in one location, but not to the connections out to the control system.
As for When a Relay Interlocking is involved then it is the TDM (Time-Division Multiplexer, the bit of kit which converts each individual relay's single wire of electrical signal into a serial protocol stream of all the data in one single cable to send the interlocking states back the control room) at the control room end which talks to the TD, once again using some form of serial cable based communication, (I don't imagine it has ever been economic to have A TD directly wired into a relay interlocking, but this being the railways I wouldn't rule out it happening once anyway.)
Of the terms added in my post, only SMART is an acronym, officially it stands for Signal Monitoring And Reporting to TRUST (and with TRUST and TOPS within it being acronyms, we could be here for days decomposing things.) but simply put, SMART is NR's system for collecting train describer step messages and sending the onward to other systems. the name also refers to the dataset that smart uses for it's other job of working out the delay of trains at locations from a small number of those train describer messages and sending that delay information to be recorded in TRUST, TRUST being defined by wikipedia (who can come up with a one sentence description better than me) as
wikipedia said:
As for the other industry term which managed to escape into my message, I namedropped the PS9 serial protocol, originally intending to link to some online source about it, but all I could find was this one and as I do not suggest anyone from here actually pays to read the standard I didn't include a link but forgot to remove the name so I might as well explain it now; anyway PS9 is a standard controlled by network rail which gives a description of how train describers (and other similar systems) should talk to each other. The message type lists that the open data wiki has here and here describe what sort of data is transmitted on a PS9 link (though it describes it wrapped in the few extra layers that the open data feeds use) with the PS9 standard just describing how you encode those messages on a serial cable (see here for those unfamiliar with the parts of the 80s IT industry that the UK railway system is prolonging the survival of), anyone working with TD's back in the late 80's or early 90's would have known the standard by the name British rail gave it ("BR1810", and ok there are slight differences to the new version, but they at a level of detail that really don't matter if you aren't actually buildinng a TD).
SSI (and most newer forms of computer based interlocking) link to the control systems using another different serial protocol, with the link to the TD being via a conversion in the control system in nearly all modern workstation based cases (sometimes networks are involved for TD to workstation links, but often it could still be serial).
There are yet more serial protocols used for communications are direct from SSI to TD for use when a panel is involved instead of a workstation. And in the SSI world, the term "data links" typical refer to the trackside connections, and also the connections between interlocking connections when multiple SSI's are in one location, but not to the connections out to the control system.
As for When a Relay Interlocking is involved then it is the TDM (Time-Division Multiplexer, the bit of kit which converts each individual relay's single wire of electrical signal into a serial protocol stream of all the data in one single cable to send the interlocking states back the control room) at the control room end which talks to the TD, once again using some form of serial cable based communication, (I don't imagine it has ever been economic to have A TD directly wired into a relay interlocking, but this being the railways I wouldn't rule out it happening once anyway.)
Thanks for the info, very interesting. I visited a PSB a while back and whilst in the interlocking room I couldn't find the TD/s. I easily found the various SSI cabs and lamp proving relays for the local diagnostics panel (all RRI was remotely controlled via TDM), do you have any photos or information on what the TDs actually look like? For local relay interlockings where no TDM is used, how does the TD hooked up then? For modern control systems like MCS and IECC scalable, is the TD built into those workstations or is it handled by a separate unit?
there is Open Train times which shows trains on a track diagram. But the cover isnt 100%. Seems older signalling isnt supported. Like between Skipton and Carnforth/Carlisle.
There is raildar which seems to cover everywhere, I think.
I assume they both get their data from SMART.
So is SMART only for modern installations?
And how does raildar locate trains for areas where Open Trains Times doesnt?
There is raildar which seems to cover everywhere, I think.
I assume they both get their data from SMART.
So is SMART only for modern installations?
And how does raildar locate trains for areas where Open Trains Times doesnt?
Freightmaster
Established Member
- Joined
- 7 Jul 2009
- Messages
- 3,495
Same as RTT - by using 'manual' TRUST reports which come through the TM (Train Movement) data feed.
As the name implies, these reports are manually input by signallers, so on lines like the S+C
the only 'actual' reports available are for locations with signalboxes:
Realtime Trains - FRGT 1246 Carlisle N.Y. to Crewe Bas Hall S.S.M.
Realtime Trains provides live realtime running information for the Great British railway network using open data.
www.realtimetrains.co.uk
MARK
edwin_m
Veteran Member
Certainly for the original IECC there was no separate TD system. The Signaller Display System would generate the TD steps and broadcast them over a Local Area Network to the other systems that needed it, including a portal (whose name I forget) to the wider area systems via BR1810. I don't imagine they would have split these functions out in Scalable.
Tempest Malice
Member
- Joined
- 12 Dec 2018
- Messages
- 39
The portal whose name you forget would I assume be the ECS ("External Communication Sub-system") (though IECC also has something called the GWS ("Gateway Subsystem") which as far as I can tell is used to synchronise TD steps between separate workstations within the IECC, so I suppose you may also have been thinking about that one). As an aside I would also be careful using the word "network" for communications within an IECC; whilst you are completely correct that "network" is the wording used in the IECC world and it's documentation, "network" nowadays is often assumed by most people to mean something internet protocol based, whilst the IECC classic's internal networks are not (Of course scaleable has mostly moved to IP networking internally as I understand, it but I assume it's external interfaces will almost certainly have to still behave the same to remain compatible with the unchanged outside world), they are instead serial based (using the protocol I know by the name railtrack re-christened it with as 17503 (but I believe in the day it had the number BR1631 or something like that))
It does seem that train describers and other associated electronic equipment get photo'ed even less than the interlockings as things in equipment rooms go, so I'm afraid I'm struggling to find anything online to link you to; though generally whilst each brand of TD will have it's own preferred hardware, generally speaking they won't look to different to most other industrial card based PC's of the era they were installed in, so in your example they probably blended in well with the TDMs that you did spot.
As for hooking up TD's to local interlockings, I have looked into things a little more and now realise that I may have been a little hasty when I said that you would always borrow an output from the TDM, as it does seem that for smaller schemes then most older TD's were built with a few direct inputs that could be wired straight onto the relays. Though if the local interlocking was big enough then you would probably still use the hardware of one end of a TDM system to read the larger number of inputs and send it on to the TD as if it was the other end even though both might be even in the same cubicle and there is no remote system (In this case the TDM hardware used might not be labelled as a TDM on site, but might sit under a nameplate calling it all manner of names, FEP ("Front End Processor") being a common-ish one, but many others are available ).
As for modern systems, edwin_m has already provided the answer for IECC, and I believe MCS to be mostly similar. I should also make sure you don't forget WESTCAD, even if it wasn't on your list, given that it is more flexible than the two you named given that WESTCAD can support both, working with legacy external TD systems when it is acting as a like for like panel replacement, or it can as you suggest run with TD functionalities built into the same box, and additionally it can also be used as a standalone Train describer driving the displays in a panel where it is not being used as a workstation.
edwin_m
Veteran Member
The original IECC had two rings, each duplicated for reliability. They may or may not have been called networks but they each interconnected a series of nodes from a company called Nine Tiles, which were connected to the subsystems via serial links. The Signalling ring had the interlockings, workstations (SDS), Automatic Route Setting and the GateWay System (GWS) and carried the most detailed and time-critical information including the state of all trackside equipment. The GWS filtered the most relevant of that information to the Information ring which basically carried TD-level information only. The ECS (Enhanced or Extended Converter System? Replacing the original and rather inflexible Protocol Converter System) would have sent this out to external subsystems including TRUST, and received data from nearby boxes for transfer of cross-boundary TDs and for the limited selection of out-of-area maps that the signaler could display on their general purpose screen. I don't remember how TD information near workstation boundaries was transmitted between workstations.
YorksLad12
Established Member
Wonder if that's the same Nine Tiles as the one that developed Sinclair Basic for the ZX80/81/Spectrum...
Belperpete
Established Member
- Joined
- 17 Aug 2018
- Messages
- 1,650
In old PSBs, the train describers were usually located in the telecoms room, not the interlocking room, as train describers came under telecoms rather than signalling. S&T was effectively two completely separate departments, with one chief.
In the days of cathode ray tube (CRT) displays, the train describer equipment could be located in the panel itself, or in the panel room (e.g. behind the panel), as it had to be relatively close to the CRTs. I recall one panel, I forget which now, where the train describers were housed in a very low-height mezzanine floor, between the interlocking on the ground floor and the panel on the first floor.
On the Western Region at least, the panel signalling technicians looked after the TDs. Telecoms experience from inside or outside the railway would have been very handy in this role however as the early electromechanical TDs were built wholly from equipment derived from the traditional 'strowger-type' telephone exchanges. There were bespoke prewired relay sets made for the task with rotary selectors and PO3000 relays that were connected up based on the layout rather like geographical interlocking units with cabling and external strapping to enable desired functionality. Certain trigger functions for stepping were free-wired to the panel indication relays that were usually output from a TDM remote control cabinet, or to a local interlocking at the panel. The setup for the signallers to input a headcode employed standard rotary telephone dials. When I joined BR as a trainee in the early 80s, most of the 60s and 70s TDs still had this equipment, although often the original rotary mechanical displays themselves had been replaced by various technologies. In the signalling drawing office I designed a few alterations on this equipment for layout changes. It was a hybrid approach involving some free wired circuit drafting and filling in endless schedules of strapping for the relay sets. It was a steep learning curve as a junior staff member! Over the following decades the electromechanical TDs were gradually replaced by electronic and processor based designs, and many of the original retro atomic age PSBs have also now gone. Here's a video of a Sodeco electromechanical display as originally installed for WR TDs and now being restored by the Swindon Panel Society for display at Didcot.
Thanks for the info very interesting! What manufacturers make train describers I can't find any info on them?
Belperpete
Established Member
- Joined
- 17 Aug 2018
- Messages
- 1,650
As a previous poster noted, with VDU control systems (such as IECC) the train describer is an inherent part of the VDU control system.
For panels, there have been many TD manufacturers over the years in the UK (including some in-house BR systems), but latterly Vaughan Harmon (now part of Alstom?) and Westinghouse (now part of Siemens).
Alstom acquired rail signalling activities of US conglomerate General Electric who had previously bought out Harmon Industries after they had acquired Vaughan Systems. The last major Vaughan-Harmon developed product offered well into GE days was the MCS control centre technology, but I can't find any mention of that now on Alstom's website. 'Iconis mainline' is their 'Seamless supervision and control' solution today, which may be related but probably derives more from previous continental European (i.e French) products. Vaughan was a pioneering UK computer company formed by early computing superstar Dina St Johnstone (née Vaughan) and her husband in 1959, subsequently acknowledged to be the very first independent UK software developer. In the 1990s they offered some very useful small TD units based on a small computer. These were installed en mass at minor signal boxes all around the Southern Region primarily to enable automatic cab secure radio switching across the region. This work had been planned for years but was expedited after the Cowden collision.
Here's the wikipedia page about the founder of Vaughan systems: https://en.wikipedia.org/wiki/Dina_St_Johnston
- Status