puffernutter wrote:
On Tuesday, 4 August 2020 12:39:24 UTC+1, Recliner wrote:
On Mon, 3 Aug 2020 08:24:43 -0700 (PDT), puffernutter wrote:

On Monday, 3 August 2020 15:50:23 UTC+1, Robert wrote:
On 2020-08-03 08:19:24 +0000, puffernutter said:

On Sunday, 2 August 2020 15:56:53 UTC+1, Anna Noyd-Dryver wrote:
Robert wrote:
On 2020-07-29 16:22:34 +0000, Recliner said:

Roland Perry wrote:
In message , at 15:26:14 on
Wed, 29 Jul 2020, Recliner remarked:

I wondered if anyone knew what the software fault was that's caused
all 9-car 345s to have to be withdrawn? Some have been re-reformed as
7-car units, and can then operate.

Something to do with SDO? Or is it some power supply issue that they
might pop the fuses if driven too enthusiastically.

I have no clue, and didn't think they needed SDO. All they say is that it's
a(nother) software issue.

The withdrawal was done so quickly that I assume it's safety-related. I
think the 9-car sets had been running for a while, so I don't know why the
problem has suddenly come to light.


Only 9-car units can operate to Heathrow, so all testing on that
branch has had to be suspended.

Why can't a 7-car unit operate to Heathrow?

Apparently something to do with the signalling. Again, another mystery.

This article
https://www.railengineer.co.uk/crossrails-signalling-challenge/
although it doesn't answer your query directly, gives some useful
background.


Thanks, that's educated me as to why one part of the system which should be
simple, is causing problems. I'd assumed that the AWS and TPWS equipment
would sit there, passive but operational, regardless of what other mode was
engaged at the time. However, rather than the conventional AWS sunflower
and TPWS control panel, it appears that 345s display this on the cab
signalling display also used for the other signalling systems. Anna
Noyd-Dryver

As I understand it (happy to be corrected)!

It is a complicated set up to meet the European Requirements.
CrossRail is classed as a mainline railway and thus has to be
interoperable. The primary safety system on the train therefore has to
be by law ETCS. This means that the ETCS European Vital Computer (EVC)
is responsible for applying brakes (even when in TPWS/AWS and in fact
Siemens CBTC - so new interfaces required!). So there is an interface
between ETCS EVC and TPWS (and the TPWS/AWS antennae) as well as the
Siemens CBTC.
Also at the time, due to headway requirements, although now proved
wrong by Thameslink, it was not thought possible to have an ETCS ATO
system, so the Siemens CBTC had to be brought into the mix to provide
ATO and Siemens CBTC controls the train (CBTC ATO overseen by Siemens
ATP) through the central section, but the CBTC has to provide the brake
commands to the ETCS EVC which actually applies the brakes. Throw into
this an upgraded TMS on the train and we have real joy!

So a lot of new interfaces and systems that haven't talked to each
other previously! I'd call it self-inflicted!

Puffer

Your timelines are twisted!

At the time Crossrail was being specified the ERTMS/ETCS could not meet
some of Crossrail's requirements such as very high train frequencies,
ATO and auto-reverse. In the meantime an ATO overlay on ETCS has been
shown to work (on one occasion in passenger service?) but is still
cannot drive a driverless train from Paddington low level to the
Westbourne Park reversing sidings so it can pick up a return working.
The article I quoted earlier also has this to say:

QUOTE
Could the signalling have been simpler? The Thameslink solution using
ETCS with an ATO overlay was considered, but modelling indicated that
this would be unlikely to achieve the 30tph requirement when used in
conjunction with platform screen doors.
END QUOTE

I have not come across any reference which suggests that this
conclusion was, or is, incorrect. Thameslink is pushing for a maximum
of 24 trains per hour, somewhat fewer than Crossrail's target.

Crossrail made its decision for the central section signalling on the
basis of information available at the time.

It is also not clear to me that the central section of Crossrail is
classified as a mainline railway in the sense of the European
regulations - it is sufficiently different that it is a metro. The
operator has exclusive use of the tunnels and only the captive trains
can use it.

If I understand the EU regulations correctly ERTMS/ETCS is only
mandated for new /high speed/ lines - for all other uses the
operator/network provider may make their own choice. But the point of
ERTMS/ETCS is that it is an open standard - the aim is that by defining
the interfaces between the functions the train operators and network
administrations would not be locked in to a proprietary solution. The
insides of the black boxes from different manufacturers may work
differently but they should all play together - although as I
understand it such perfection has not yet been reached! Having a choice
of suppliers will be beneficial.

This approach of only defining the interfaces between the functional
units is one of the main reasons the GSM mobile phone technology was so
succesful and it spawned a series of developments and has now reached
the fifth generation, but it took some time to get there. Getting
Siemens databases to work reliably with Ericsson infrastructure and
Alcatel handsets was also a bit nerve wracking in the early days - but
it all took place away from public sight so it never hit the headlines.

ERTMS/ETCS is becoming the de-facto standard signalling system,
certainly across Europe and also in other parts of the world. Using it
reduces the amount of time and energy that would otherwise be necessary
for the now international train and infrastructure manufacturers if
each railway demanded its own system. And these days, because of the
building block approach, it makes perfect sense that ETCS and the TMS
of that particular train manufacturer are the backbone of the train's
driving and braking system and that the inputs from the various
signalling systems are treated purely as inputs from different black
boxes.

What would seem to have been underestimated is the quantity of systems
integration work that was necessary - but the system will work because
it will have to work. What the railways are rediscovering is the
complications of getting started - just as fly-by-wire in the aerospace
business took a long time coming.

I'll reply in depth later, but CrossRail is not classed as a metro,
therefore as a new railway it has to meet the interoperability requirements.

Who's decision that was or whether the size of trains etc., is the
reason I don't know, but as it is NOT a metro it has to be signalled by
ERTMS or have a derogation.


Would such a derogation have been difficult to obtain, had they
decided not to use ECTS? I assume not. The EU had made it clear that
the UK was free to continue to have its own standards in many areas.
The ECTS/ERTMS decision is generally driven by costs, as it's cheaper
than conventional signalling. NR needs to use ETCS to catch up with
its signalling backlog.

Like everything else, it was not simple! Also this goes back 10 years or so!

Crossrail was going to run to Heathrow and that was (at the time)
protected by GW ATP and it was a requirement (by ORR) to have something
better than TPWS for the signalling in the Heathrow tunnels. It would
have been difficult (if not unwise) to fit Crossrail trains with an old
(obsolescent?) ATP system. So ETCS was the logical solution as it was a
requirement for Crossrail anyway and (again at that time) the plan was to
fit ETCS on the GWML, so it all seemed as they say "a good idea at the time".


More info in
https://www.londonreconnections.com/2020/crossrail-finally-reaches-stage-2-of-opening/

I'd not realised that the 7-car trains run a patched version of the old
Electrostar software platform (which can't support ETCS), whereas the 9-car
trains run the all-new, multi-signalling Aventra software platform. I had
thought both variants ran versions of the old software platform.