Class 345 progress

Peter Sarf · 18 Nov 2020

Horizon22 said:
You've done the maths the wrong way around there - 0.09 every 60 minutes. So according to their data that's 1 reset approximately every 600 minutes (10 hours).

Yes, the penny dropped as I read the posts that just got in before me. Elementary mistake - I was out by a factor of 100 give or take !. I have altered/corrected the post but you were too quick for me :oops:

. Been too many long days just recently but I cannot complain as its better than being layed off - I think.

Assuming a 24 hour service that is roughly two and a half per day. How long does a reset take ?. Thought I read it somewhere but it helps if it is not on a busy stretch/junction.

RailUK Forums

JonathanH · 18 Nov 2020

Horizon22 said:
My experience would suggest more like 5-6 a day. Often its the same unit although MTR seem to be applying a "3-strikes-and-out" approach before returning the affected unit to the depot.

'JN114' suggested upthread that Network Rail had imposed the 3-strikes rule. I wonder if some units are worse than others.

Peter Sarf said:
Assuming a 24 hour service that is roughly two and a half per day. How long does a reset take ?. Thought I read it somewhere but it helps if it is not on a busy stretch/junction.

It isn't 24 hours - first departure is 0442 off Paddington, last arrival at Paddington is 0040 - the third starter does one less cycle and so finishes first.

Horizon22 · 18 Nov 2020

JonathanH said:
'JN114' suggested upthread that Network Rail had imposed the 3-strikes rule. I wonder if some units are worse than others.

Possibly. If the 0.09 rate is to be taken literally it must be something else, because there's no way there's only 2-3 ETCS incidents a day.

JonathanH · 18 Nov 2020

SeaKing said:
Have anymore entered service or testing recently, not been able to pick numbers up on Slough Railcams of late.

No, there's been no change to the units in service.

The only units to pass Slough in service (or indeed in daylight) are the fourteen 7-car units on the west side - 006/07/13/20/39/44/47/49/51/52/57/63/64 - once you know that it is still possible to distinguish them on the Railcam feed, particularly if you know whether the 3409xx vehicle is at the west end 07/13/29/40/44/52/63 or at the east end 06/20/47/49/51/57/64.

I haven't noticed 345026, 345045 or 345046 being used for anything since they have been moved to Old Oak Depot. My guess is that 345002 is the unit which gets hauled to Heathrow every other Friday night but I could be wrong.

345023 seems to be involved in the empty runs to Heathrow (afternoon / evening) and Reading (overnight) at the moment alongside one of the eight (021/27/28/53/54/58/60) that haven't been used for passengers since June.

SeaKing · 18 Nov 2020

JonathanH said:
No, there's been no change to the units in service.

The only units to pass Slough in service (or indeed in daylight) are the fourteen 7-car units on the west side - 006/07/13/20/39/44/47/49/51/52/57/63/64 - once you know that it is still possible to distinguish them on the Railcam feed, particularly if you know whether the 3409xx vehicle is at the west end 07/13/29/40/44/52/63 or at the east end 06/20/47/49/51/57/64.

I haven't noticed 345026, 345045 or 345046 being used for anything since they have been moved to Old Oak Depot. My guess is that 345002 is the unit which gets hauled to Heathrow every other Friday night but I could be wrong.

345023 seems to be involved in the empty runs to Heathrow (afternoon / evening) and Reading (overnight) at the moment alongside one of the eight (021/27/28/53/54/58/60) that haven't been used for passengers since June.

Many thanks for update.

rebmcr · 19 Nov 2020

Horizon22 said:
Possibly. If the 0.09 rate is to be taken literally it must be something else, because there's no way there's only 2-3 ETCS incidents a day.

It's per unit.

Horizon22 · 19 Nov 2020

rebmcr said:
It's per unit.

That's much more understandable, thanks. Yesterday I noticed the 3 strikes rule applied to one set arriving late from Heathrow - each consecutive trip had an ETCS failure.

Snow1964 · 20 Nov 2020

The Elizabeth line Board papers for meeting 26 November now available, and seems to refer to central core (phase 3) opening first half 2022, agenda item 11, sections 3.3 & 3.4 say even this (6 month window) is not confirmed. No indication when phases 4 and 5 will be

More relevant to this thread (class 345 trains), agenda item 7, section 3.2 refers to software patch in October to reduce signalling resets in full length (9car) units, with software upgrade in December 2020

Agenda item 7, section 4 (rolling stock reliability) suggests reliability growth will be through mileage accumulation

http://content.tfl.gov.uk/elc-20201126-agenda-pack-public-web.pdf

Due to length of Board papers I don’t think it is sensible to copy and paste chunks, so just leaving as a link

samuelmorris · 20 Nov 2020

Given the uncertainty of covid and its impact on productivity still remains, I think it's probably a fair bet to assume the project is as-was, about 5 years behind at this point. If we're somehow miraculously out of the pandemic in 6 months time then perhaps it'll come sooner, but I still think that's a bit much to expect at this point.

hwl · 20 Nov 2020

samuelmorris said:
Given the uncertainty of covid and its impact on productivity still remains, I think it's probably a fair bet to assume the project is as-was, about 5 years behind at this point. If we're somehow miraculously out of the pandemic in 6 months time then perhaps it'll come sooner, but I still think that's a bit much to expect at this point.

Given my background in expressing doubts on opening dates for the last 5+ years you'll probably be surprised that I'd agree with their H1 2022 opening date so about 3 to 3.25 years behind.
Buried in the small print is the news that they have got Bond Street sorted as regards emergency evacuation which makes testing (especially large scale) a whole lot easier.

JonathanH · 23 Nov 2020

Some problem at Old Oak Depot late last night and this morning causing delays in getting units in and out of the sidings.

Yesterday, the advertised running of Hayes & Harlington terminators to Maidenhead to reverse proved not to be necessary with the units terminating alternately in platforms 4 and 5 at Hayes & Harlington instead with layovers of around three quarters of an hour. However, the first two terminators did terminate on the main line and go to Maidenhead and back for reversal. The first was a 7-car, the second brought the unusual sight of a 9-car unit in daylight beyond West Drayton, the first I think since 345068 worked Reading services on 29 August, albeit not in service on this occasion. The disruption from 1730 led to two units being parked in the bay and loop at Hayes & Harlington and the service never restarted.

Hayes & Harlington shuttles cancelled today due to a block on the main line after disruption yesterday. One wonders how such things would be handled with Crossrail actually operating, whether the contingency will be to increase the number of services terminating in the sidings at Westbourne Park, whether the core service gets chopped or whether they will need to run empty to and from the depot sidings.

kevin_roche · 24 Nov 2020

The latest monthly report from Mark Wild has been posted on the TfL website. http://content.tfl.gov.uk/alison-moore-montly-update-23-november-2020.pdf

This paragraph on Software Upgrades could be bad news since there were previous mentions in response to Jacobs reports of there being new releases due in November and January.

Further software upgrades are being introduced in early December for the 9-Car Class 345 trains that operate to Heathrow which should improve the reliability of this part of the fleet, with a further major software release due at the beginning of February 2021.

There is good news though on the Abbey Wood branch:

For the first time, on 5 November, Crossrail saw the operation of six Class 345 trains in the central operating section (Abbey Wood -Paddington). These trains were controlled with the signalling system at line speed and in close headway. This is an important step in demonstrating performance of our systems and building the necessary reliability.

Crossrail plans to begin Systems Integration Dynamic Testing (SIDT) on 3 December after a review was held and passed on 5 November. Testing will take place in the central operating section with an increasing number of Class 345 trains, ramping up to eight trains. This will provide an opportunity to test how well the railway systems work in operational-like situations and will continue until the railway comes under The Railways and Other Guided Transport Systems (Safety) Regulations 2006 (ROGS).

JonathanH · 24 Nov 2020

kevin_roche said:
This paragraph on Software Upgrades could be bad news since there were previous mentions in response to Jacobs reports of there being new releases due in November and January.

Seems to me plausible that the earliest we'll be seeing 9-cars to Reading in service again will be March then although overnight running seems to be ongoing. Presumably 345018 won't be allowed out of Ilford for 9-car testing on the east side just yet.

kevin_roche · 24 Nov 2020

JonathanH said:
Presumably 345018 won't be allowed out of Ilford for 9-car testing on the east side just yet.

That might be allowed since there is no transition involved. It is possible judging from what you and other's have said about faults that they occur when a transition from ETCS to TPWS happens. Though I don't know that.

On the GWML the first half of the ETCS is being implemented between Airport Junction and Paddington and that may have caused the problem since a trip to Reading in a 9 Car would possibly start in TPWS then go to ETCS then back to TPWS.

I think there is a need to test the selective door opening with the 9-car units on the GEML since some stations have shorter platforms. I can't remember when the longer platforms at Liverpool St are supposed to be ready.

goldenarrow · 24 Nov 2020

kevin_roche said:
I think there is a need to test the selective door opening with the 9-car units on the GEML since some stations have shorter platforms. I can't remember when the longer platforms at Liverpool St are supposed to be ready.

Planned handover for 10 May 2021 with a critical deadline set for 31 May 2020 so as not to interfere with operational activities.

kevin_roche · 25 Nov 2020

The Jacobs report for 2020/1 Period 6 (23 August 2020 – 19 September 2020) is now published on the TfL web site. http://content.tfl.gov.uk/project-representative-periodic-report-period-6-2020.pdf

It contains confirmation of the delay to the new versions of software:

A service to Heathrow with FLUs operating at 2 TPH started on 14 September 2020, which allows RfLI to surrender its lease of the Class 360 fleet. The 5 FLUs are currently limited on the GWML, due to train software control issues; these prevent services operating 4TPH to Heathrow and serving Reading. The two software fixes needed for these issues have both slipped a month, meaning full deployment of FLU services on the GWML is likely to be delayed to mid-December 2020.

The Crossrail response to the Jacobs report says:

There are two tests planned for the weekend commencing 31 October 2020 to complete the testing. In addition to this, eight have failed or only partially passed. A further point release (PR6) and a subsequent Bombardier release of TCMS (7.6.2) is scheduled for January 2021 and it is expected that following these releases, majority of tests will be passed for Trial Running.

gordonjahn · 26 Nov 2020

kevin_roche said:
The Jacobs report for 2020/1 Period 6 (23 August 2020 – 19 September 2020) is now published on the TfL web site. http://content.tfl.gov.uk/project-representative-periodic-report-period-6-2020.pdf

It contains confirmation of the delay to the new versions of software:

The Crossrail response to the Jacobs report says:

Anyone else actually want to get involved with this software and actually see what they're dealing with?

I mean, I've plenty of software to maintain as it is, but I can't help thinking this would be pretty interesting.

kevin_roche · 27 Nov 2020

gordonjahn said:
Anyone else actually want to get involved with this software and actually see what they're dealing with?

I do find this interesting. Many years ago, at the start of my career in computing, I was involved with Air Traffic Control software. It was rather similar but in 3 dimensions rather than 2.

Now I'm near retirement and like you have plenty of maintenance work.

samuelmorris · 27 Nov 2020

Latest MTIN figures from this month's Modern Railways:

https://i.imgur.com/axFbFe4.png

Roast Veg · 28 Nov 2020

gordonjahn said:
Anyone else actually want to get involved with this software and actually see what they're dealing with?

I mean, I've plenty of software to maintain as it is, but I can't help thinking this would be pretty interesting.

Yes deeply. There's an argument to be made of course that software used in a public service ought to be made open source...

JonathanH · 28 Nov 2020

Roast Veg said:
Yes deeply. There's an argument to be made of course that software used in a public service ought to be made open source...

There is a limit to that though isn't there. It isn't as if a public body is writing is it. While it may be of interest to someone who understands it, it is also intellectual property of the company that has written it and even if it was open source, it wouldn't be much use from a practical perspective. It is hardly as if someone is modelling the interations between the signal systems on their model railway in the attic.

matt_world2004 · 28 Nov 2020

The software is likely used in train systems around the world too. Some of whom isn't public and I'm sure bombardier would not appreciate rival companies being able to steal their code.

Signalling systems code has to be perfect as a bug could lead to an fatal accident.

coppercapped · 28 Nov 2020

Roast Veg said:
Yes deeply. There's an argument to be made of course that software used in a public service ought to be made open source...

Is there?

While I can see that there might be an argument that software used for office work (letter and report writing, spreadsheets and the like) could be open source as the range of hardware and the associated operating systems are very limited and they are all to a standard pattern. There are effectively only three major operating systems for office computers, the various varieties of Windows, Linux and the MacOS.

This limited range of computing hardware does not hold true for rolling stock and signalling as each implementation is very specific - there is no general case that the open source community can design for. I can just see Bombardier or Siemens making a train available for the open source community to use for development work... The number of items involved is measured in the hundreds (for example, how many Class 66s are there?), not the millions which makes open source attractive. And as the developers interests shift to newer and whizzier challenges who will maintain the software in 30 years time?

Won't happen.

dm1 · 28 Nov 2020

The argument for open source software likely relates less to it being expected that the open source community develop their own software, and more to enable competition between manufacturers.

One of the reasons that relay-based signalling solutions are still being installed today in certain situations , rather than microcontroller or software based solutions, Is that they can be modified and maintained by anyone with the right education. Whereas software is generally proprietary and the manufacturer/developer effectively has a monopoly on modifications and updates, which they can therefore charge through the nose for.

In an open source world, that would not be possible.

The alternative approach is standardising the interfaces, which is how ETCS came into existence.

rebmcr · 29 Nov 2020

dm1 said:
The argument for open source software likely relates less to it being expected that the open source community develop their own software, and more to enable competition between manufacturers.

One of the reasons that relay-based signalling solutions are still being installed today in certain situations , rather than microcontroller or software based solutions, Is that they can be modified and maintained by anyone with the right education. Whereas software is generally proprietary and the manufacturer/developer effectively has a monopoly on modifications and updates, which they can therefore charge through the nose for.

In an open source world, that would not be possible.

The alternative approach is standardising the interfaces, which is how ETCS came into existence.

Once the interfaces are standardised, replacing each component with open-source becomes feasible. Until then, it's too much of a proprietary tangle which produces two barriers: open-source work is close to useless; and licencing issues are probably insurmountable.

It will just take time. If you told an engineer in the 1990s that in 20 or so years Microsoft would be embracing open-source and the Linux ecosystem, they'd have thought you completely bananas — yet here we are.

ijmad · 29 Nov 2020

The UK gov puts plenty of its source code in the open these days, including code built by private sector contractors, for example the new COVID-19 NHS app is open source.

However there are concerns around open sourcing software that is directly responsible for safety critical systems - no software is bug free, and unfortunately given the era we live in, there are plenty of potentially interested parties looking to exploit bugs to cause chaos and death, including terrorist groups and other nation states.

ISIS and similar groups have plenty of recruits with software engineering backgrounds among their ranks (they run very sophisticated online recruitment via social media) and I'm sure would love to mount an attack that causes trains to crash into each other just by connecting a smartphone to a diagnostic port found behind a panel locked with an easily obtainable T key or similar.

This may sound fanciful but we've already seen flaws used to stop a Jeep driving on the highway, wirelessly.

Peter Sarf · 29 Nov 2020

ijmad said:
The UK gov puts plenty of its source code in the open these days, including code built by private sector contractors, for example the new COVID-19 NHS app is open source.

However there are concerns around open sourcing software that is directly responsible for safety critical systems - no software is bug free, and unfortunately given the era we live in, there are plenty of potentially interested parties looking to exploit bugs to cause chaos and death, including terrorist groups and other nation states.

ISIS and similar groups have plenty of recruits with software engineering backgrounds among their ranks (they run very sophisticated online recruitment via social media) and I'm sure would love to mount an attack that causes trains to crash into each other just by connecting a smartphone to a diagnostic port found behind a panel locked with an easily obtainable T key or similar.

This may sound fanciful but we've already seen flaws used to stop a Jeep driving on the highway, wirelessly.

That is rather worrying !. Best to avoid all these remote connection features all together is my feeling. That is despite the advantages.

rebmcr · 29 Nov 2020

ijmad said:
The UK gov puts plenty of its source code in the open these days, including code built by private sector contractors, for example the new COVID-19 NHS app is open source.

However there are concerns around open sourcing software that is directly responsible for safety critical systems - no software is bug free, and unfortunately given the era we live in, there are plenty of potentially interested parties looking to exploit bugs to cause chaos and death, including terrorist groups and other nation states.

ISIS and similar groups have plenty of recruits with software engineering backgrounds among their ranks (they run very sophisticated online recruitment via social media) and I'm sure would love to mount an attack that causes trains to crash into each other just by connecting a smartphone to a diagnostic port found behind a panel locked with an easily obtainable T key or similar.

This may sound fanciful but we've already seen flaws used to stop a Jeep driving on the highway, wirelessly.

The whole point of open-source is to have exponentially more eyes and brains looking for security holes before any bad actors find them. That benefit far, far outweighs the drawback (and an attacker can find flaws without source anyway, while a researcher needs source to fix holes).

What you're describing is "security through obscurity" which is a recognised fallacy — it just means that any exploit which is discovered enjoys the cover of secrecy.

dm1 · 29 Nov 2020

rebmcr said:
The whole point of open-source is to have exponentially more eyes and brains looking for security holes before any bad actors find them. That benefit far, far outweighs the drawback (and an attacker can find flaws without source anyway, while a researcher needs source to fix holes).

What you're describing is "security through obscurity" which is a recognised fallacy — it just means that any exploit which is discovered enjoys the cover of secrecy.

The question is. whether there are enough people qualified and interested enough for that benefit to outweigh the risk of publishing source code. I don't think it's that certain that that's the case. Signalling systems (and train control systems) are extremely complicated.

rebmcr · 30 Nov 2020

dm1 said:
The question is. whether there are enough people qualified and interested enough for that benefit to outweigh the risk of publishing source code. I don't think it's that certain that that's the case. Signalling systems (and train control systems) are extremely complicated.

'Security through obscurity' is a fallacy because it's always outweighed. The same factors which affect contributors' capability equally affect the malicious.

Class 345 progress

Established Member

RailUK Forums

Veteran Member

Established Member

Veteran Member

Member

Established Member

Established Member

Established Member

Established Member

Established Member

Veteran Member

Member

Veteran Member

Member

Member

Member

Member

Member

Established Member

Established Member

Veteran Member

Established Member

Established Member

Member

Established Member

Established Member

Established Member

Established Member

Member

Established Member