Comparing speed and efficiency of introducing planes and ships (etc) to new train classes

[BayPaul]

I have always wondered about this, and as there is a slightly off topic discussion on the Class 484 thread, I think it is a topic that is worthy of its own debate - hence this thread.

Below are all the relevant posts

I think it's a poor excuse to blame "race to the bottom", and looking at some of the prices paid we are anyway a long way from The Bottom. But each one seems to have separate excuses, sometimes multiple ones. It seems almost standard now for manufacture and delivery to be fully completed before the first one turns a wheel in revenue service. In the airline world, if an airliner gets delivered on the Friday it's in full moneymaking service on the Monday, not people standing round saying "Ooooh, nasty", or "Gosh, never thought of that" for months if not years.

There is a bit of a difference, not least it takes many years to get a civilian aircraft type approved for use. Then you've got the whole training issue to consider. It's why Boeing went down the 737 Max route - because a new aircraft would have taken at least 10+ years to develop, would have required full re-training of all the type approved pilots to fly it a combination of which would probably have bankrupted both Boeing and a few airlines along the way.

I do find it amazing that this seems to be the case in the rail industry - for almost every new build fleet. I'm in the shipping industry, where very complicated vehicles, often one of a kind, are routinely* delivered on time, to spec, on budget with crew already trained (crew training normally happens whilst the ship is still owned by the shipyard, and then on passage from the yard to the home port), and the ship enters service a few days after delivery. No doubt there is a good reason why this doesn't happen for trains, but as an outsider looking in it is difficult to see what it is.
*There have been a couple of high-profile exceptions recently - Caledonian MacBrayne's Glen Sannox is a good example of what happens if you let politics mix with shipbuilding (perhaps it helps explain the issues for trains, and recent deliveries from Flensburger shipyard, but since delays to Honfleur and WB Yeats led to the collapse of the yard, it perhaps just underlines the point.

What's the lead time on a new ship from design to delivery and entering service?

I made this point when somebody else mentioned aviation - but look at the Airbus A380 as an example - project announced in 1994, first prototype unveiled in 2005 (11 years later) with first (test) flight in 2005 - there was a 2 year delay due to wiring problems - it finally received its type approval from the EASA and FAA (European and US regulators) at the end of 2006 and the first delivered aircraft was in October 2007.

Compare that with the 230s - 2014 the D78s were bought by Vivarail, 2015 a prototype was produced and in 2016 mainline testing on the Coventry - Nuneaton line, ordered by WMT in October 2017 and entered service in April 2019.

Though I think it's fair to say that designing a new airliner from scratch and making modifications to an existing train are in totally different levels of complexity.

But with very different safety standards built in - both airlines and ships have *far* more rigorous safety standards than rail, for the simple virtue that a failure is far more likely to kill those on board - i.e. an engine failure on a train will probably inconvenience a couple of hundred people. An engine failure on an aircraft at 30,000 feet stands a good chance of killing all on board.

The rail industry *could* mandate much higher reliability at day one - but the additional cost of achieving this along with the extended time-frame to deliver the new units would render it somewhere between a waste of money and uneconomic.

________________________________________________________________________________________

What's the lead time on a new ship from design to delivery and entering service?

In general, around 3-4 years for a new prototype. P&O's LNG powered cruise ship Iona had her keel laid (start of major construction) in June 2019, was launched in February 2020, delivered in October 2020, so around 18 months construction, with a similar amount of time for design work. At this time, she would have been ready to enter service, though Covid meant she was laid up until this summer.
This is for a 5000 passenger, 340m, 180,000 tonne ship (the largest ever built in Germany), costing around $1 Billion, with hundreds, if not thousands of suppliers, and literally millions of individual components.

Off the top of my head: ”interfacing” with water, and with a handful of ports, seems less technically challenging* than interfacing with a pair of steel rails, conductor, signalling system, platforms...

*Not saying that the shipping industry doesn’t have its own challenges to contend with. But the amount of complexity (mechanical, electrical, software) that exists in the railway is staggering.

The interfaces are a reasonable point, but it's surely something that is known when the spec is written.

A ship is indeed a standalone beast, whilst a train is effectively a component of the network, but that doesn't make it less complex. There are thousands of sensors, a dozen different major safety critical 3rd party software control systems (Machinery automation, navigation, fire & safety, communications, property management, planned maintenance, CCTV, crew management etc) , linked to hundreds of individual systems, all of which are made by different suppliers, normally using a basic platform that is highly customised to the ship. And it works. Day 1,out of the box, the ship is handed over to her crew, who have been standing by the ship for a couple of months, doing training and helping supervise the final stages of build, and within hours she'll put to sea, in a fully working and certified condition. Generally it will be only the 2nd or 3rd voyage, with just a week or two of sea trials where the builders put her through her paces.

She'll just have to have her final (very thorough) inspections by the certifying authorities, and a couple of test cruises to make sure that the passenger service side is up to scratch, then it's the maiden passenger carrying voyage, followed by continual service every day for the next 5 years, when she'll get a 7-14 day refit.

Yes, there are teething troubles, but generally pretty minor, and it's very rare to see a show stopper.

To me, it sounds at least as complex as putting a new train class into service!

 

[Nicholas Lewis]

You make a very valid view here and we do seem to have gone backwards over the last few years in getting new trains into service. Why this is isn't so easy to answer but for me the obsession to control everything through software is causing the bulk of the delays as trying to fix one problem may cause an issue somewhere else and this is leading to elongated testing. There's not a lot of explanation in the public domain but Bombardier have suffered more than others with UK build as well as European trains were equally delayed. I do wonder whether the lack of prototyping is an underlying cause as we go straight into new builds.

Personally im in awe of these huge cruise ships engineering and construction but are they built using tried and tested technology or are they always seeking to use unproven technology that needs extensive testing to prove its safety and reliability?

 

[BayPaul]

.
Personally im in awe of these huge cruise ships engineering and construction but are they built using tried and tested technology or are they always seeking to use unproven technology that needs extensive testing to prove its safety and reliability?

There's a lot of new tech. LNG is a particular new thing at the moment, which makes for a massive redesign of the ship due to the size of fuel tanks, and number of new safety critical systems. Technical IT systems tend to be evolution rather than evolution of existing stable platforms, but still with a lot of new functionality - things like remote monitoring are being added in to a lot of systems, and of course there is a lot of new equipment to control.

I don't think it is massively different to the technology leaps that are required for a train to be honest, so I'm fascinated why it seems to be such a cumbersome process to get a new train to work.

 

[Nym]

Except that when we make technology leaps in trains (in this and other countries), and learn all the mistakes during the introduction, they're all forgotten by the time it's time to design the next fleet. See: Aventura, etc.

As well as, of course, an over-reliance and dependency on software based systems in applications where it's completely unnecessary.

 

[Dai Corner]

As well as, of course, an over-reliance and dependency on software based systems in applications where it's completely unnecessary.

Although a faulty software based system is potentially quicker and easier to fix by amending and reloading the program than redesigning, manufacturing and swapping out a mechanical component.

 

[AM9]

Except that when we make technology leaps in trains (in this and other countries), and learn all the mistakes during the introduction, they're all forgotten by the time it's time to design the next fleet. See: Aventura, etc.

As well as, of course, an over-reliance and dependency on software based systems in applications where it's completely unnecessary.

Although, much of the role for software is to monitor running systems and detect failures/warn of urgent preventative action being required. To do that with an all-hardware solution would not only be expensive in production terms but also less reliable in creating failures in itself. That was revealed in aviation some time ago.

 

[Bletchleyite]

I think one aspect of this is that you tend to buy one ship at a time, because they are rather big and expensive. Whereas you buy a fleet of trains.

So if there's a problem with a component of your ship, you fix it. If there's one with a component of your train, you have to replace it many times over.

 

[BayPaul]

I think one aspect of this is that you tend to buy one ship at a time, because they are rather big and expensive. Whereas you buy a fleet of trains.

So if there's a problem with a component of your ship, you fix it. If there's one with a component of your train, you have to replace it many times over.

True, but it really should be better and easier procuring a fleet - you build a couple, test them, iron out the flaws, and then build the remainder to an improved spec. OK, that wouldn't catch issues like the lifting points on the 80x series, but that didn't lead to a delay in entry into service.

Ships, like trains, tend to be built on standard platforms - even if they look very different, technically they are similar, so fairly large fleets can be built. Traditionally the 3rd ship in a series is the best - all the flaws on the 1st ship have time to be ironed out, and the shipyard haven't yet got bored and lazy with the design! Many classes of ships do have large numbers of the same design - P&O's Iona is one of 9 so far to be ordered, with further orders likely, so not like a train class, but not small numbers.

 

[Nym]

Although, much of the role for software is to monitor running systems and detect failures/warn of urgent preventative action being required. To do that with an all-hardware solution would not only be expensive in production terms but also less reliable in creating failures in itself. That was revealed in aviation some time ago.

That's as may be. But I did say "over reliance". Software systems have their place, but it's gone too far with the level of available control in the industry.

 

[AM9]

That's as may be. But I did say "over reliance". Software systems have their place, but it's gone too far with the level of available control in the industry.

So how would you propose that potentuial failure detection under operational conditions would be provided. The driver has enough distractions such that adding yet more direct indicators would risk lapses of attention to primary tasks. Much of the monitoring software in modern equipment is designed to detect irregularities and determine whether they are 1) of immediate safety significance, 2) of operational importance -e.g. the vehicle may not complete its duty, or 3) logging for maintenance action. Something has to filter the raw information and it seems that the driver might not be the best person to deal with 2) and definitely not 3).

 

[Nym]

I said too far. Not that failure reporting should be part of a software system.

 

[Nicholas Lewis]

Although, much of the role for software is to monitor running systems and detect failures/warn of urgent preventative action being required. To do that with an all-hardware solution would not only be expensive in production terms but also less reliable in creating failures in itself. That was revealed in aviation some time ago.

Until computers appeared on trains there were minimal systems that provided interlocked control over the traction system outside of deadmans handle and those that did were simple systems like reliable micro switches ie sufficient air pressure obtained before traction control circuit could be energised were actually very simple to implement so I would contest that hardware solutions are too expensive. That said they were binary systems and largely operated to prevent catastrophic failure but without warning. With the advent of computers and more importantly sensor that can measure electrical, mechanical, temperature etc that could be interfaced to them the potential to gather vast amount data became possible. This allowed provision of information to both driver and maintenance teams so issues could be detected and interventions taken before failures occurred. As these sensors were spread down the length of the train a data system had to be used along the length of the train to transmit all this data and this then allowed control of discrete items on the train ie doors, lights, air con etc. Of course we now come to the glue that pulls this all together the software and this where the achillies heel has shown itself especially with Aventra in UK but there not alone. Software used in these trains needs to achieve SIL2 levels of reliability which takes a lot of testing to demonstrate that. Furthermore when you change the software you have to recertify the whole system so im not so sure that mechanical solutions are that bad after all.

Ultimately though the prize of being able to monitor the health of the train is worth striving for but perhaps spending sensible amount of times to prototype and test the systems and software would have paid dividends especially as Bombardier has delivered the software and systems integration itself rather than using an established systems integrator like EKE.

 

[BayPaul]

The debate above on to what extent computers are needed does deflect from the question, why are train manufacturers so bad at implementing them. Again taking a typical cruise ship, the It systems listed below are extremely complex, come from multiple suppliers and are highly safety critical, but work properly on delivery.

A typical modern cruise ship will have:
- An integrated machinery control and automation system, (IMACS) often from a company like Siemens or Kongsberg, that is connected to every piece of engineering equipment on the ship, from main engines to air conditioning to fuel supply to ballast treatment. This allows everything to be controlled and monitored from a central location, as well as managing many processes automatically.
- Safety Management System. This monitors all the fire detectors, fire and watertight doors, flooding sensors etc around the ship, managing the central alarm system, and activating pre-planned actions like shutting down ventilation and making phone calls to cabins.
- Integrated Bridge System. Wartsila Nacos is almost universally used. Combines radars, electronic charts, autopilot and other systems into a single box
- Property Management System. Something like Fidelio. Runs all the passenger facing side of the ship, especially payments, bookings and reservations. Also is normally the crew management system, looking after hours of work, wages, certification etc, and has safety critical roles in managing gangway security and the lists of passengers and crew on board.
- Planned maintenance system, normally Amos, set up with all the scheduled maintenance of equipment and increasingly linked to equipment monitoring too
- Gmdss - the emergency communication system, mainly standalone
- Satellite Communication - and associated WiFi, phone network, TV network etc. Remote monitoring is becoming more common on systems. One peculiarity of ships is that Internet is expensive and unreliable, which impacts how many other systems on board are built.
- Passenger Muster System - for checking off passengers and crew in an emergency
- Electronic logbook
- Stability computer
- Individual control system for each piece of equipment, all connected to the IMACS
- And loads more smaller systems, from CCTV and medical systems to interactive TV and theatre control systems.

 

[Domh245]

The debate above on to what extent computers are needed does deflect from the question, why are train manufacturers so bad at implementing them. Again taking a typical cruise ship, the It systems listed below are extremely complex, come from multiple suppliers and are highly safety critical, but work properly on delivery.

I expect those systems are generally all standalone however - I imagine that the IMACs does its own thing and only pulls in certain interface with other relevant software, based on what you've written. With rail, the impression I get is that there is usually just one "software" which handles everything from PIS and CCTV to signalling interface and traction equipment management

It would seem to me that the scale of the ship when compared to a train is a key factor - in the same way that you generally don't have one piece of software/controls in an office building that does the fire alarm, HVAC, CCTV, access control, room booking (though you can make them all talk to each other) you wouldn't have such a single system on a ship. A train on the other hand isn't big enough to necessarily justify individual software for each system

Additionally, it would seem that the supply of software and systems for ships is well established - you can just buy the solution off the shelf assuming that all of the equipment you're putting in is suitably interfaced and can be connected in. Rail doesn't seem to have that same supply of "off-the-shelf" software

 

[AM9]

The debate above on to what extent computers are needed does deflect from the question, why are train manufacturers so bad at implementing them. Again taking a typical cruise ship, the It systems listed below are extremely complex, come from multiple suppliers and are highly safety critical, but work properly on delivery.

My experience is with aircraft, both civil and military. Clearly they are vehicles with higher capital be cost than trains, and in some cases rival those of ships, but train designers certainly don't have any less of a safety brief. Both are designed to have fail-safe characteristics and with both protective and informative monitoring systems operating autonomously whilst in operational service.
The contrast between aircraft and rail vehicles is however that the former generally uses subsystems that use industry-standard protocols and interfaces that in themselves have fail-safe and duplicated operating modes. These are usually sourced from multiple specialist suppliers and interoperability is generally presumed and verified. It is normally only the monitoring and protection systems that operate at aircraft level rather than attempting to have a single master program overseeing all operational aspects of the aircraft.
Trains on the other hand, as you seem to say, are designed to hand all control over to a single computer. The problem seems to be that all of the function is handed over to a single running program, because it is more 'cost effective', as a design exercise. When some part of the gets out of step, e.g. PIS features*, the software interface that is 'woven' into the main software red rather than communicating via a common proven protocol, problems arise that sometimes require withdrawal of units from service.
This blurring of functionality, (and ultimately responsibility) of software sub-programs is not unique to trains, I believe that as cars are being delivered with much of their functions delivered by software communication through CAN bus networks, some manufacturers are now controlling safety-critical needs such as brakes and steering over the same multiplexed bus to keep manufacturing costs competitive.

* I do not have any absolute knowledege of these issues but literature and some comment here seems to indicate trends in train controls systems are going in that direction, and I agree with @Domh245's view of on-train software when compared with other large transport vehicles.

 

[TravelDream]

It's an interesting topic and I think some of the comparisons are valid.

However, there are also vast differences compared to the aviation sector.

I think one of the biggest is if there's a problem. In a train, generally you're able to stop. You can't exactly stop a plane at 38,000 feet.

Another example is the time period between beginning design and entry into service for aircraft.
The Boeing 787 was publicly launched* in January 2003, was certified to fly by EASA and the FAA in August 2011 and entered into service with ANA in October 2011.
The Airbus A380 was publicly launched* in December 2000, was certified to fly by EASA and the FAA in December 2006 and entered into service with Singapore Airlines in October 2007.
*Note that market analysis, the design concept and a lot of contracts are already put in place when a design is publicly launched. Initial work on the 787 began in early 90s and A380 in the late 80s.
Two decades from initial concept and 7-8 years from concrete concept and public launch is pretty standard.

The OP mentioned the 737-Max, but there are a lot of other reasons to keep the 737 line going rather than launch a replacement programme outside of initial certification and its huge capital outlay.
One of the really big ones is the grandfathered rights which means the 737 is still certified in many areas to 1960s standards. One basic example most people would understand is the doors. All four main and four emergency doors are too small to be certified today (compare an A320 and 737 door). The emergency doors also lack slides which is also uncertifiable today. Changing this would require a whole fuselage redesign affecting almost every system on the aircraft.
Can you imagine a 'Pacer 2' being designed with 80s standards in mind? No PRM requirements etc. etc.
It also more than possible for two aircraft to have the same type-rating so that was not a reason to keep with the 737. The 757/767 do. The 777/787 do. The A330/A340/A350 do. Cockpits are designed to be the same and only very minor differences training is required.

It's difficult to compare computers as Boeing and Airbus have two very different design philosophies when it comes to pilot-aircraft interaction.
However, modern aircraft have multiple computer systems which are typically both internally fail-safe and have back-up computers which make them fail-safe in series. Aircraft control systems also have different laws based on which systems are operating.

Sometimes things slip through certification and design (penny-pinching management) like the 737 Max's Maneuvering Characteristics Augmentation System (MCAS) system. In layman's terms, the 737 is too low to the ground and has too poor engine clearance for its length (compare an A320 and 737 next to each other). This causes the nose to push up during take-off meaning a possible tail-strike. The MCAS system was designed to stop this and cause the Max to take-off like the previous generation by using the horizontal stabilizer to push the nose down during take-off.
Boeing managed to get the system removed from manuals as they wanted both the Max and the previous generation to have exactly the same type-rating with no differences training required so a pilot could fly the Max with no additional training at all which meant pilots didn't know the system existed. The other issue is it relied on only one angle of attack sensor which means it definitely wasn't fail-safe.
Even so, I think a skilled, competent and well-training pilot should have been able to control the plane when the system went haywire (as the Lion Air captain did using the engines to control climb descent before the FO took over (not to absolve the captain as he didn't communicate how he was controlling the aircraft)).

 

[AM9]

It's an interesting topic and I think some of the comparisons are valid.

However, there are also vast differences compared to the aviation sector.

I think one of the biggest is if there's a problem. In a train, generally you're able to stop. You can't exactly stop a plane at 38,000 feet.

Another example is the time period between beginning design and entry into service for aircraft.
The Boeing 787 was publicly launched* in January 2003, was certified to fly by EASA and the FAA in August 2011 and entered into service with ANA in October 2011.
The Airbus A380 was publicly launched* in December 2000, was certified to fly by EASA and the FAA in December 2006 and entered into service with Singapore Airlines in October 2007.
*Note that market analysis, the design concept and a lot of contracts are already put in place when a design is publicly launched. Initial work on the 787 began in early 90s and A380 in the late 80s.
Two decades from initial concept and 7-8 years from concrete concept and public launch is pretty standard.

The OP mentioned the 737-Max, but there are a lot of other reasons to keep the 737 line going rather than launch a replacement programme outside of initial certification and its huge capital outlay.
One of the really big ones is the grandfathered rights which means the 737 is still certified in many areas to 1960s standards. One basic example most people would understand is the doors. All four main and four emergency doors are too small to be certified today (compare an A320 and 737 door). The emergency doors also lack slides which is also uncertifiable today. Changing this would require a whole fuselage redesign affecting almost every system on the aircraft.
Can you imagine a 'Pacer 2' being designed with 80s standards in mind? No PRM requirements etc. etc.
It also more than possible for two aircraft to have the same type-rating so that was not a reason to keep with the 737. The 757/767 do. The 777/787 do. The A330/A340/A350 do. Cockpits are designed to be the same and only very minor differences training is required.

It's difficult to compare computers as Boeing and Airbus have two very different design philosophies when it comes to pilot-aircraft interaction.
However, modern aircraft have multiple computer systems which are typically both internally fail-safe and have back-up computers which make them fail-safe in series. Aircraft control systems also have different laws based on which systems are operating.

Sometimes things slip through certification and design (penny-pinching management) like the 737 Max's Maneuvering Characteristics Augmentation System (MCAS) system. In layman's terms, the 737 is too low to the ground and has too poor engine clearance for its length (compare an A320 and 737 next to each other). This causes the nose to push up during take-off meaning a possible tail-strike. The MCAS system was designed to stop this and cause the Max to take-off like the previous generation by using the horizontal stabilizer to push the nose down during take-off.
Boeing managed to get the system removed from manuals as they wanted both the Max and the previous generation to have exactly the same type-rating with no differences training required so a pilot could fly the Max with no additional training at all which meant pilots didn't know the system existed. The other issue is it relied on only one angle of attack sensor which means it definitely wasn't fail-safe.
Even so, I think a skilled, competent and well-training pilot should have been able to control the plane when the system went haywire (as the Lion Air captain did using the engines to control climb descent before the FO took over (not to absolve the captain as he didn't communicate how he was controlling the aircraft)).

Thanks for the updated info there, I haven't been involved with Civil aircraft technology for many years but the same principles are there as was when air travel started in earnest in the late '50s/60s. It seems that the pressures of commerce have corrupted some of the good practice on safety qualification, especially where grandafather rights are manipulated to keep costs down. These come to a head every few years (the most appalling example being the 737MAX MCAS) which totally compromised both fail-safe operation as well as deliberately denying critical information to pilots to save on training costs. No doubt Boeing have had time to rue the wisdom of this move.
The use of multiple (including back-up) computers for safety critical control and monitoring systems is further enhanced by ensuring that the computers do not have a common architecture, and by careful design, are unlikely to suffer the same failure modes.
Of course, the end to end development of rolling stock is generally far shorter, and to a degree relies on safety of mechanical structure established over many decades. However, the proliferation of computers on board does seem to be going the same way of some road vehicles where safety critical equipment relies on multiplexed comms. buses, typically CAN in cars, probably Ethernet in trains presumably because of the greater distances between parts of the system. That is coming to ahead in cars where brakes are sometimes operated electrically via the CAN bus, reliable most of the times byt with a catastrophic failure mode, especially where there isn't a backup comms channel. Are train manufacturers going to look at the databus running the length of the train and decide that it is cheaper, lighter and theroetically less likely to fail than a compressed air line or even discrete hard wiring?