Connections between coaches

[fairysdad]

While sitting at Exeter St Davids one day recently waiting for a train, I found myself looking at the connections between the coaches on an HST, and got to wondering, what connections must be between the coaches?

This is the list I can think of at the moment, not just for HSTs but for any type of train:

• Electricity (for passenger sockets and for depot use)
• PA
• Displays (eg, 'The next station is...')
• Emergency cord or newer equivalent
• Control signals between cabs/power units (inc. MUs)
• the guard's buzzer
• Plumbing? (or does each coach have a separate water supply?)
• Door locking

 

[Murph]

I'm not certain of the details, but I read something a while back about a move towards using Ethernet for many services on trains. With modern industrial Ethernet implementations and proper QoS on the switches, that could ultimately end up with there just being power, air, and network between coaches. I'm not sure just how far the industry has gone with that so far, as it will take some time before safety-critical things can move to a network based system.

Water plumbing is always a per-coach thing, I believe. Mark 3s, for example, have a water tank above each vestibule (and dump onto the track in their original form).

 

[WatcherZero]

Yes on modern trains its Ethernet with each component having an IP address, in fact ultra lightweight designs are going even further and replacing cabling with Wi-Fi, all the compnents talk to a single router on a carriage and that router then talks to the neighbouring carriages.

 

[hacman]

Ethernet backbone is the way things are going, with dedicated jumpers between cars. This can either be copper or fiber.

Using WiFi for such things is possible, but is just not effective. Some older installs will use wireless links between the cars, but such a solution is filled with problems and often performs poorly. Where this exists it's often being removed in favor of a wired solution as the equipment becomes life expired.

Ethernet can ultimately carry passenger WiFi, CCTV, PA (audio and visual), OTMR/TMS/black box, passenger entertainment and many more services on a single set of cables, so represents a very cost effective solution.

 

[headshot119]

I'm not certain of the details, but I read something a while back about a move towards using Ethernet for many services on trains. With modern industrial Ethernet implementations and proper QoS on the switches, that could ultimately end up with there just being power, air, and network between coaches. I'm not sure just how far the industry has gone with that so far, as it will take some time before safety-critical things can move to a network based system.

Water plumbing is always a per-coach thing, I believe. Mark 3s, for example, have a water tank above each vestibule (and dump onto the track in their original form).

Water plumbing is not always a "per-coach" thing....

At least some class 108s (and I would presume other first gen units had this as well) had a water pipe between the two car for the cab heating system.

 

[scotraildriver]

Don't forget the 2 most important ones - brake pipe and main reservoir pipe!

 

[Murph]

Ethernet backbone is the way things are going, with dedicated jumpers between cars. This can either be copper or fiber.

Using WiFi for such things is possible, but is just not effective. Some older installs will use wireless links between the cars, but such a solution is filled with problems and often performs poorly. Where this exists it's often being removed in favor of a wired solution as the equipment becomes life expired.

Ethernet can ultimately carry passenger WiFi, CCTV, PA (audio and visual), OTMR/TMS/black box, passenger entertainment and many more services on a single set of cables, so represents a very cost effective solution.

Yeah, I wouldn't recommend standard WiFi for anything important, as there's a limited set of radio channels for it, and it's quite possible for you to lose significant performance due to external conditions (such as people in the vicinity saturating the capacity of the radio channels). Basically, lots and lots of factors outside your control which could make it unreliable or even unusable in extreme circumstances. Overall, quality of service guarantees can't be provided for WiFi.

Yup, the key benefit of moving to Ethernet is that it's an IEEE open standard which can basically carry an unlimited number of services, including those not yet invented, over a single low cost link (which can be doubled for redundancy, if you need that for safety-critical systems, etc). Equipment manufacturers just have to work to the IEEE standards, and they can be confident that their systems will attach to Ethernet (leaving aside software issues). Modern Ethernet equipment provides Quality of Service (QoS) capabilities, so that you can guarantee that there's sufficient performance reserved for important things, while also using it to carry things like streaming media for passengers.

 

[fairysdad]

Don't forget the 2 most important ones - brake pipe and main reservoir pipe!

Being a (beginner!) AV and Broadcast engineer, that was where my train of thought was going; didn't think about those!

The discussion about things being transferred to Ethernet is interesting though, how widely used is this? Is it only on new trains, or are older ones being converted?

 

[455driver]

Don't forget the 2 most important ones - brake pipe and main reservoir pipe!

Not if its fitted with EP brakes!

 

[hacman]

Some new, some old.

New trains are starting to be constructed with the backbone already there - but as WiFi and other systems are retrofitted the infrastructure is being installed onto older vehicles too. In theory it's possible (funds permitting) to put a backbone into any train type, so long as there is a reason to do so.

On projects I've worked on we've even seen a few TOCs both at home and further afield install the system for one purpose, then realise they can do other things with it.

It's certainly an interesting and exciting aspect of the industry, that few would have suggested could have existed only a few years ago!

 

[flash]

Water plumbing is not always a "per-coach" thing....

At least some class 108s (and I would presume other first gen units had this as well) had a water pipe between the two car for the cab heating system.

First gen units had a hot air system driven by a diesel fuelled heater in each coach. They had 2 vacuum pipes between each coach, one a brake pipe, one a 'reservoir' pipe.
--- old post above --- --- new post below ---

Not if its fitted with EP brakes!

EPBS (old slam door stock) had a brake pipe and reservoir pipe - dont forget they still had an auto brake, later units with 'westcode' type brakes don't have the brake pipe.

 

[SpacePhoenix]

Does the use of Ethernet have any bearing on the maximum number of cars a train could be formed of (ignoring the length of signalling blocks or available power supply)?

 

[dgl]

Does the use of Ethernet have any bearing on the maximum number of cars a train could be formed of (ignoring the length of signalling blocks or available power supply)?

I suppose the real limiting factor is the braking system if is controlled by the front coach only this could cause a delay in the brakes operating on the further away vehicles but as there are really long breaked freight trans (a few miles long in some cases) this should not be a limiting factor although it would be sensible for the brakes to be locally controlled on each coach with the normal brake pipes used as a safety backup.

Also if using wired ethernet just having a network switch in each coach is enough to make ethernet cable length limits well within the maximum.

 

[krus_aragon]

Does the use of Ethernet have any bearing on the maximum number of cars a train could be formed of (ignoring the length of signalling blocks or available power supply)?

It certainly did in older bus-based implementations of Ethernet (and in hub-based twisted pair varieties) because of the need to guarantee collision errors would propagate the entire network in a given time. If the network makes use of switches instead (as many networks are these days) there would be no need to worry.

 

[Murph]

It certainly did in older bus-based implementations of Ethernet (and in hub-based twisted pair varieties) because of the need to guarantee collision errors would propagate the entire network in a given time. If the network makes use of switches instead (as many networks are these days) there would be no need to worry.

I'd be extremely surprised if they were using any bus or hub type Ethernet on trains. Switching technology is long established now, it would be quite crazy if they didn't use switches, in my opinion. Switches also carry the key advantages of enabling redundancy and QoS, which in turn moves towards being able to trust it for important or possibly even safety-critical services.

If it's "layer 2" switched, there's an old recommendation of 7 "hops" max, but it would not be very difficult to engineer it to allow use on a longer chain of switches. If it's "layer 3" switched, the limit would be either 63 or 255 "hops" (it's really 255, but some systems default to 63). A "hop" is each link in the network chain, which would likely be a carriage. That's based on IEEE 802.1 and 802.3, it would be quite possible for equipment manufacturers to augment or adapt the IEEE standards for railway use. Ethernet is a hugely adaptable technology, one of the major reasons why it has basically dominated the marketplace.

Obviously, for anything important or safety-critical, you'd have to defer to the manufacturer's stated maximums (which would presumably be the largest configurations that they had properly tested and were willing to guarantee). The above is just the theoretical limits of the base technology.

 

[DownSouth]

Does the use of Ethernet have any bearing on the maximum number of cars a train could be formed of (ignoring the length of signalling blocks or available power supply)?

Freight trains would use the AAR standards for ECP and not Ethernet which simply isn't robust enough for freight usage.

ECP is limited to 180 network devices (i.e. wagons and locos) which allows a maximum length of about four kilometres if the wagons are married pairs sharing a car control device between the pair.

The longest trains with ECP on the Australian national network (i.e. not the privately-owned iron ore lines in the Pilbara region of Western Australia which are not connected to the rest of the nation) are 1800 metre iron ore trains operated on part of the route used by The Ghan, restricted to 1800 metres by the length of passing loops. These trains use 160 hopper wagons (80 married pairs) and four locomotives, two at the front and two at the back. The ECP system is used for not only controlling the brakes and hopper doors, but also the rear locomotives including putting them offline when not needed.

Yeah, I wouldn't recommend standard WiFi for anything important, …

In the freight world, the development of radio-based ECP is progressing along a path completely independent of WiFi. There are other data link standards which are much more appropriate.

 

[hacman]

The number of actual direct-attached devices are usually very small in such implementations, therefore the collision issues are somewhat offset. There are also other technologies and approaches that can be used to mitigate this issue without the need for layer 3 switching.

Normal Ethernet backbone tech uses a switch in each car as a minimum, therefore there is no maximum train length imposed by the backbone. It's actually nearly impossible to get hubs these days! Freight tends to not have an Ethernet backbone - only the locomotive will be "smart".

It's also possible for the backbone to be formed of technology that is not IEEE 802.3 Ethernet in the traditional sense, such as LRE, yet still present an Ethernet interface to each device at the demarcation point between the backbone and the serviced hardware. Ultimately each deployment warrants its' own approach based on the scenario, but standards-based solutions are preferred for obvious reasons.

It's worth pointing out that traction control and braking are not controlled by anything that runs over the Ethernet backbone yet - so this is something of a moot point. Such systems are directly safety critical, so are (rightly so) relegated to their own communication/control lines.

 

[Murph]

Normal Ethernet backbone tech uses a switch in each car as a minimum, therefore there is no maximum train length imposed by the backbone. It's actually nearly impossible to get hubs these days! Freight tends to not have an Ethernet backbone - only the locomotive will be "smart".

802.1D (Spanning Tree Protocol) has an old recommendation of 7 hops max. Going beyond 7 is quite possible, just needs engineering consideration and testing/validation. Only really a concern if you're engineering it for multiple redundant paths, and ideally it should really be engineered to use something more modern than STP, such as RSTP. In the old days, the latency added by each bridge hop could end up being troublesome in a long chain, but switches should largely eliminate that concern these days.

 

[hacman]

802.1D (Spanning Tree Protocol) has an old recommendation of 7 hops max. Going beyond 7 is quite possible, just needs engineering consideration and testing/validation. Only really a concern if you're engineering it for multiple redundant paths, and ideally it should really be engineered to use something more modern than STP, such as RSTP. In the old days, the latency added by each bridge hop could end up being troublesome in a long chain, but switches should largely eliminate that concern these days.

Though Spanning Tree is largely not required since trains are line shaped and not toroid

 

[edwin_m]

I suppose the real limiting factor is the braking system if is controlled by the front coach only this could cause a delay in the brakes operating on the further away vehicles but as there are really long breaked freight trans (a few miles long in some cases) this should not be a limiting factor although it would be sensible for the brakes to be locally controlled on each coach with the normal brake pipes used as a safety backup.

Most modern passenger trains use ECP (Electrically Controlled Pneumatic) brakes as mentioned by some other posters. These apply the brakes by means of an electrical signal so they are effectively simultaneous all the way down the train.

As mentioned by others, something similar is now used on the really long freight trains that run in some countries, but the ones in the UK probably aren't long enough to benefit much.

 

[455driver]

EPBS (old slam door stock) had a brake pipe and reservoir pipe - dont forget they still had an auto brake, later units with 'westcode' type brakes don't have the brake pipe.

So the 455s, 150s etc are actually fitted with a westcode brake which is (I assume) a type of an EP brake!

we just refer to it as an EP brake.

Edit-
Just read the later reply from Edwin which answers my question!

 

[DownSouth]

As mentioned by others, something similar is now used on the really long freight trains that run in some countries, but the ones in the UK probably aren't long enough to benefit much.

UK freight trains certainly would benefit from adopting ECP even if they are rarely longer than about 600 metres.

Faster (and more precise) applications are good even for 500 metre trains.

Faster brake releases are good - even more so for the UK where freight trains are second-class citizens on mixed traffic lines dominated by passenger trains.

Self-testing and reporting of faults is good.

Reducing the wear and tear inflicted on wagons as the rear of the train runs in is good.

Reducing the wear and tear on the track is good.

Active train proving is good.

Proper distributed power working on the heaviest trains using two locomotives is good - it makes for better train handling and could eliminate the need to run the locos around the train on flows where there's no balloon loop.



The only real problem is that, like the Marathon system under development in Europe when they should have just used the proven Locotrol system, there's a fair chance of "not invented here" syndrome striking and a huge amount of money being ****ed away to develop a unique UK ECP system when AAR ECP systems are already in widespread use. An attitude change to "proudly invented elsewhere" is needed instead - that the hard work of development, testing and introduction has already been done by others allowing the UK railways to enjoy an off-the-shelf product should be celebrated, not seen as a source of shame.

 

[harz99]

EPBS (old slam door stock) had a brake pipe and reservoir pipe - dont forget they still had an auto brake, later units with 'westcode' type brakes don't have the brake pipe.

From what I remember the EPB stock used EP braking in normal service and pure Westinghouse air brake as back up. Very similar, maybe even the same as, LT 1938/1959 tube stock and O/P/Q/R and A60 surface stock.

Not sure about BRB rules, but on LT the Motorman was supposed to use the Westinghouse brake to stop at the station before the terminus, except where that had a controlled junction beyond the platform end so you did that one stop earlier.

 

[Juniper Driver]

Computer Stuff on newer stock.
Data Recorder(s).At a guess.

 

[MarkyT]

It's worth pointing out that traction control and braking are not controlled by anything that runs over the Ethernet backbone yet . . . Such systems are directly safety critical, so are (rightly so) relegated to their own communication/control lines.

"Yet" being the interesting word. Signalling technology, with similar fail-safe requirements, is already moving over to more open shared networks both wired and wireless, albeit track-side rather than on board the train. The signalling equipment itself at each end of a link negotiates all the fail-safe attributes of an exchange so transmission becomes transparent and only needs to meet a performance specification.

 

[Murph]

"Yet" being the interesting word. Signalling technology, with similar fail-safe requirements, is already moving over to more open shared networks both wired and wireless, albeit track-side rather than on board the train. The signalling equipment itself at each end of a link negotiates all the fail-safe attributes of an exchange so transmission becomes transparent and only needs to meet a performance specification.

Yup, and it's really not all that difficult to engineer "yet" into "now" with current technology. The real obstacle will be to convince safety authorities, insurers, etc that it has been properly engineered and tested, and actually can be trusted.

1. All Ethernet components duplicated. 2 physical links between carriages, 2 switches per carriage, etc.
2. Ethernet spanning tree technology (the modern fast variants of it) to give automatic redundancy at interconnection points between the A and B systems, and localise the scope of any failures (the A switch failing in 1 car should only break the links directly connected to it, not the entire A network along the train, for example). A&B cross-connected in each car.
3. Ethernet Quality of Service (QoS) and VLAN to ensure that train and passenger systems are protected and isolated from each other while being able to share the network infrastructure.
4. Ethernet link and switch monitoring performed by the TMS in the active cab, to detect failed components.
5. All important and safety critical end-points connected to both A & B networks at their nearest switches.
6. An "if all else fails" E-STOP facility, either traditional dump a Westinghouse brake pipe, or a round-train electrical circuit serving the same purpose. Traction automatic cut-out linked to the E-STOP.

Even on a very long train, modern switched Ethernet should keep the max latency down to just 10s of milli-seconds, which should be quite adequate. It should be possible to engineer the redundant networks to recover from single failure in less than 1s.

That's the high level overview. 1001 little details in there for the engineers actually building it to address, but extremely feasible.

 

[edwin_m]

Is Ethernet used for vital controls on aircraft? That would be a more critical application than trains, given that on an aircraft you usually can't just dump the brakes and stop if you are in trouble.

 

[Murph]

Is Ethernet used for vital controls on aircraft? That would be a more critical application than trains, given that on an aircraft you usually can't just dump the brakes and stop if you are in trouble.

I'm not sure, but I've never heard of it being used for important or critical services on a plane, and I frankly would be very uncomfortable flying on such a plane. I've no doubt that there are some networks on modern "digital" planes, but using them for critical systems is a step too far in my opinion. Personally, given the choice between the latest and greatest Airbus and an old 737 or 747, I'd rather be on the old Boeing, where I know that there's not any complex software interfering in the relationship between controls and control surfaces, only the proven FADEC for the engines.

Additionally, the benefits are not really there on a plane in the way that they are on a train. There's no coupling, no controlling from another cab, no routine reconfiguration.

 

[BestWestern]

An HST has - Main Air (both sides, yellow cocks), Brakes (both sides, red cocks), 36-way jumper (power car to power car communication), Train Supply (power; a very large three pin plug) and Central Door Locking (throughout the coaches only, not into the power cars).

 

[hacman]

Is Ethernet used for vital controls on aircraft? That would be a more critical application than trains, given that on an aircraft you usually can't just dump the brakes and stop if you are in trouble.

I've not heard of such a thing either.

My thoughts are that the answer is likely no, as the aviation industry has developed fly-by-wire tech of their own long before the concept of using off-shelf systems.

The "yet" part is exactly it for rail though. The technology exists, the main issue is in convincing those who make the decisions that it is suitable and worth the effort.

It's safe to say though that we'll be waiting a good while yet before anything safety critical shares an Ethernet network with passenger accessible traffic, even with VLANs and other tech.

The approach everyone likes at present is separate systems, as the additional cost of doing this vs the theoretical ever so slight chance of problems is just not worth it.