Will Northerns new 195s and 331s be compatible?

[James James]

Why would requiring people to comply with a pre existing standard put up stock procurement and maintenance costs a lot?

One modern IP (if we are going to go modern and have a generational break in compatibility) based system will be entirely compatible with another.
Any datagrams not understood by a vehicle would simply be ignored but passed down the chain unaltered.

You then specify a basic control set at the beginning that all vehicles must understand, and a basic PIS standard based on similar standards for messaging that are used elsewhere.

If we are standardising on the Dellner we should fit the locos only with Dellners and abolish buffer type couplings entirely.

Manufacturers existing traction control systems don't speak a "standard" yet. So, first off, you'd have to spend time and money developing a standard that can fulfill the needs of a modern train (remember, we now have things like regenerative braking, hybrid trains, etc.). Developing standards is slow and expensive - that's the first chunk of money neeed.

Once that's done, every manufacturer has to build new traction control systems that can speak this standard. That costs more time and money, which translates into higher rolling stock prices. Past evidence (e.g. SBB DPZ/DTZ) suggests that manufacturers aren't able to build systems that can speak to older existing trains - that should be easier with a formal standard, but not significantly easier.

This isn't consumer software development, things are slow and expensive when building safety-essential software. Just like avionics, train systems aren't cheap. And every one of these systems will need to go through a lot of testing and certification. You don't want some edge case to cause the emergency brakes to not activate on half your train...

 

[edwin_m]

I've a feeling someone in the EU is working on a standard for wireless coupling.

The big issue is liability. If there was any sort of problem caused by incompatiblity between two suppliers' trains, there would be a big techno-legal bunfight about whose fault it was.

 

[HSTEd]

Manufacturers existing traction control systems don't speak a "standard" yet. So, first off, you'd have to spend time and money developing a standard that can fulfill the needs of a modern train (remember, we now have things like regenerative braking, hybrid trains, etc.). Developing standards is slow and expensive - that's the first chunk of money neeed.

I would argue that such a standard would be worth it in the long run though.

Especially if it can be electrically derived from an existing standard - perhaps an early one like the Sprinter standard but with added connections for ethernet that would be to support secondary functions that are not critical to safety, like climate control, maintenance and PIS and such.

Once that's done, every manufacturer has to build new traction control systems that can speak this standard. That costs more time and money, which translates into higher rolling stock prices.

Yes, but once its done once, the software and control systems can be reused for years as required.
And the software development for a design with hundreds of vehicles costing billions of pounds is still only going to cost a few million in all likelihood.
Especially if we have a hybrid standard that avoids the need for safety grade IP connections.

Past evidence (e.g. SBB DPZ/DTZ) suggests that manufacturers aren't able to build systems that can speak to older existing trains - that should be easier with a formal standard, but not significantly easier.

Well we have counter evidence that they can in the form of every US locomotive manufacturer.... but yeah.

This isn't consumer software development, things are slow and expensive when building safety-essential software. Just like avionics, train systems aren't cheap. And every one of these systems will need to go through a lot of testing and certification. You don't want some edge case to cause the emergency brakes to not activate on half your train...

Which is why we would likely use a hybrid system which has a proven electrical standard for the core functionality.
And in coupling terms we would probably want to adopt an air-electrical-autocoupler derivative of the C-AKv.

 

[Roast Veg]

The only way I can see inter-compatible digital connections happening is if they move to a standard TCP/IP stack and the coupler becomes a glorified Ethernet connector. A coupled train would become its own local area network and intermediate carriages wouldn't need to do anything about messages they don't understand. Sorting out inter-compatibility in software would presumably be much easier than electro-mechanically. When a new train coupling standard comes along, the new manufacturer could write a software package to be run on the older trains to make them able to understand one another. Aircraft are moving to Ethernet for critical systems so I can't see rail having much of an excuse.

Ethernet ports are already used in some cases (such as between the two halves of a class 700 I believe). You're definitely correct in so far as resolving software incompatibilities is easier than both software and physical incompatibilities, but let's not underestimate how deep the rabbit hole can go with regards to incompatibility. Let's say for instance that I have one vehicle that is attempting to log a fault with one of its components so that the driver can take steps to rectify or isolate the faulty component, but the driver is in a vehicle designed and built by a different manufacturer that cannot interpret and display the fault message because it is of an unknown format. What about if both the driving and faulty vehicle should be able to communicate that information, but cannot because a different vehicle marshalled between them has intercepted and destroyed what it has identified as useless information? You are now operating a degraded service because of an insistence on compatibility that could be avoided by using closed compatible systems instead.

Given that every unit will have to be fitted with a GSM-R radio as a matter of course now, the question is whether on train system modelling actually needs to be passed over couplings at all.
Or climate adjustment.

You don't want trains to be able to report issues to drivers when coupled together? You don't want settings designed to increase passenger comfort to be variable rather than fixed?

To my mind, it would be a lot easier for a class 153 to be able to report a door fault to the driver of a joined 170 over the BSI coupler - but perhaps your preference is for that information to wait until it can be looked at directly?

 

[HSTEd]

Ethernet ports are already used in some cases (such as between the two halves of a class 700 I believe). You're definitely correct in so far as resolving software incompatibilities is easier than both software and physical incompatibilities, but let's not underestimate how deep the rabbit hole can go with regards to incompatibility. Let's say for instance that I have one vehicle that is attempting to log a fault with one of its components so that the driver can take steps to rectify or isolate the faulty component, but the driver is in a vehicle designed and built by a different manufacturer that cannot interpret and display the fault message because it is of an unknown format.

There would be a standard header format for packets that should be transmitted over the GSM-R radio to the depot or similar where fitters can look at it, or to the TOC control room where control operators can look at it.

What about if both the driving and faulty vehicle should be able to communicate that information, but cannot because a different vehicle marshalled between them has intercepted and destroyed what it has identified as useless information? You are now operating a degraded service because of an insistence on compatibility that could be avoided by using closed compatible systems instead.

In what universe would the standard permit a vehicle to destroy messages that it doesn't understand?
The practice in all similar systems in other industries would be for the unknown packet to be carried forward to the next vehicle, but for the current vehicle not to act on it since it doesn't know what it is.

Hell even PNG files do this.

And even if it did do that for some unknown reason, the train will still move if there are no faults - which is not something possible with a "closed compatible system" since there would be absolutely no functionality at all.

You don't want trains to be able to report issues to drivers when coupled together? You don't want settings designed to increase passenger comfort to be variable rather than fixed?

No, I want the driver to concentrate on driving the train - that is his job.
I would want units to use their inbuilt GSM-R radio set to transmit and recieve commands from control or from the relevant fitters directly and not bother the driver at all, so he can continue driving the train.
We don't need absolute and safety grade control of air conditioning settings at all times.

To my mind, it would be a lot easier for a class 153 to be able to report a door fault to the driver of a joined 170 over the BSI coupler - but perhaps your preference is for that information to wait until it can be looked at directly?

Even leaving aside that any reasonable ethernet standard would have messages for all these obvious faults written into it, the door fault should report to the driver as a failure to gain interlock, which is the important thing.
If there is a GSM-R signal the unit could then report the fault code to the fitters, or the driver/guard can read it out over the connection using the standard fault-code packet format provided for the purpose.

It would be a text message transmitted over the bus and displayed on the drivers console (and if possible transmitted to control) reading something like:

"Vehicle 69052 [195/2] Reports Error Code 3002-3325-9617 - Critical Failure, No Door Interlock"