ETCS affected by a Train Management System software change: surely should be impossible?

[AHBD]

I recently read of a made for UK Train* whose ETCS operation was affected by a Train Management System software change (and so was unusable until a fix):

but surely such a thing should be impossible?.. surely a safety critical signalling system such as ETCS should be airgapped / not run on same co.puter hardware as other train software?

Also, if ETCS is a separate box, rather than train specific equipment surely that makes maintentenance/retrofitting etc⁸ simpler (as Thales are experimenting with on the Tornado).

*I think it was in modern railways, the one with a digital railway section.

 

[HSTEd]

Air gapping and modularity are not in the interests of private-sector rolling stock manufacturers, who are strongly incentivised to generate the greatest amount of lock-in possible.

In theory an awful lot of the software on a train is safety critical, so there would be little disadvantage in safety-case terms to running it on the same safety critical hardware as the ETCS implementation.

 

[AHBD]

1 Air gapping and modularity are not in the interests of private-sector rolling stock manufacturers, who are strongly incentivised to generate the greatest amount of lock-in possible.

2 In theory an awful lot of the software on a train is safety critical, so there would be little disadvantage in safety-case terms to running it on the same safety critical hardware as the ETCS implementation.

1) a) But if the systems are entangled, a mistake in the Train Management System (which might anyway be changed more frequently for 'trivial' reasons) will then require an expensive extensive retest of the entangled ETMS system, so that mistake/tms upgrade could be very expensive for the train manufacturer.

1 b) But if the modular Thales system(or an eqiivalent) becomes commercially available, could it not be specified that space for such an agnostic system is provided, along with the setup info.

1c) perhaps the committee? In charge of ETCS or just at least one big purchasers Government should require modularity, as not having it doesn't seem in the interests of rail users/providers or the future of ETCS (what if a train company goes bust and an ETCS update is required for its proprietary to their trains ETCS software?)

2 ) If they are interlinked then changing the non-ETCS code surely means retesting all (and perhaps vice versa), again expensive for the train manufacturer.?

 

[WatcherZero]

Often happens with software standards when something has been written for one version (e.g 1.3 of the standard) and something else for another version (1.5 of the standard). While both software are in theory backwards compatible and should work together, one developer may have implemented it in such a way (creating a shortcut to improve performance, adding a bit of their own code that uses function call names not present in the earlier code but used by the later version, using different byte lengths, function calls that wernt very widely used/supported have been deprecated, some variable it treated as writable memory address is now read only protected or hidden in the later version) that its then falling over when interacting with later versions of the standard or vice versa.

 

[bahnause]

ETCS in a seperate Box only works in simple systems. In modern EMU/DMU however it is usually connected to the TMS. There are specifications for the interface, so it is not a black hole that has to be reinvented for every train. The systems exchange data like train number, brake data, diagnosis etc. It makes it more convinient to, I only have to enter the train number once in ETCS and it will send it to the CAB-Radio and the PIS automatically.

If needed you can even use the ETCS data to control the speed of the train via the TMS. Otherwise all ETCS can domismto apply a system brake or an emergency brake.

 

[800301]

I recently read of a made for UK Train* whose ETCS operation was affected by a Train Management System software change (and so was unusable until a fix):

but surely such a thing should be impossible?.. surely a safety critical signalling system such as ETCS should be airgapped / not run on same co.puter hardware as other train software?

Also, if ETCS is a separate box, rather than train specific equipment surely that makes maintentenance/retrofitting etc⁸ simpler (as Thales are experimenting with on the Tornado).

*I think it was in modern railways, the one with a digital railway section.

There are a few components of ETCS and the TMS in a 387 for sure that will need to communicate or the TMS would be blind to what’s happening to the train in regards to TPWS and AWS and I’m sure a few other bits of data are shared but it’s the same way in a non ETCS fitted 387 the TMS must know certain things about the train. ETCS is a system that is a separate box and quite a big one in a 387, it doesn’t run the same software as the train but the software is designed to work with each other

 

[D365]

The initial comments seem to suggest that there are some ETCS implementations where a separate EVC (European Vital Computer) is not provided. I would be very surprised at this, as the ETCS software/hardware interfaces are vastly different to that of a TMS.

Also, if ETCS is a separate box, rather than train specific equipment surely that makes maintentenance/retrofitting etc⁸ simpler (as Thales are experimenting with on the Tornado).

It's a Network Rail job, Thales are just supplying the hardware.