Odds of engine failure

[kontiki]

Common words heard on a CVR in the events leading up to a crash: "WTF is it doing now?"

That's true too, but not exactly what I was referring to. I was speaking to software version control for a fleet of large jets. Software lives in everything any more. Version control, release issues, software data management, data base management, etc is a huge PIA.

They eventually created a separate ATA Chapter in the IPC just for software versions. Even simpler systems like fire suppression systems get software updates now.

Any given LRU is likely to have operational software, firmware (for many of the internal logic chips, VLSIC), aircraft configuration files (that ideally live in onboard personality modules), databases, etc. The CMM for a complex LRU could list a dozen files that the OEM could issue a revision too. The LRU itself could easily have the processing power of a dual processor desktop computer.

Sometimes you load via an onboard HDD, notebook computers, a data loader, or by inserting media directly into the face of the box.

We get a lot of calls for software version questions, boxes not taking loads, boxes not working after software loads etc.

When it comes to forward looking implementations for things like integrated avionics modules where there is a single ubiquitous computing platform running software modules in protected partitioned calculating space (software LRUs) each developed by different vendors for the functions they specialize in, it sounds like the stuff nightmares are made of.

Conceptually (and maybe from a marketing standpoint), it sounds nice, but sounds impossible to maintain over decades of use. There is no bug free software.

Early hybrid attempts toward that model have been in service now for decades.

I understand, in one case, the OEM farmed the development of the platform software to a company in another country, and that company has at least once, gone out of business or been purchased by other companies. There is no way to completely test the software for anything that involves so many other systems from other manufacturers on a hot bench anywhere. Every new release brings with it troubleshooting for new bugs.

 

[Henning]

Lotsa 'what if's' here.

First, a turbine is NOT inherentlymore reliable than a piston. Turbines do fail.
They do, however, being very, very, very expensive get a lot more maintenance - much of it driven by regulation. More maintenance and iron clad regulation over parts inspection/replacement based on time and hours, adds greatly to reliability.

Next a piston engine is not inherently unreliable. It all depends on whose engine it is.
If it is mine it is not going to launch a piston out the side of the jug even if the logbook shows 6400 hours since new.
If it is yours (shrug) who knows?
The difference is:
I am fanatical about maintenance
The jugs are (currently) less than 200 hours since new
It is a low compression engine(s)
I use a synthetic blend oil to avoid scuffing during cold starts
I don't flog the crap out of them (other than take off)

The bottom line is that if an owner starts with a standard engine (not souped up) in good shape and maintains it to the standards of a turbine it will be as reliable as far as internal catastrophic failure. The loose nut on the yoke however

Actually a turbine is somewhat more inherently reliable since there are no reciprocating parts and considerably fewer moving parts and no ignition system.

 

[Frank]

That's true too, but not exactly what I was referring to. I was speaking to software version control for a fleet of large jets. Software lives in everything any more. Version control, release issues, software data management, data base management, etc is a huge PIA.

They eventually created a separate ATA Chapter in the IPC just for software versions. Even simpler systems like fire suppression systems get software updates now.

Any given LRU is likely to have operational software, firmware (for many of the internal logic chips, VLSIC), aircraft configuration files (that ideally live in onboard personality modules), databases, etc. The CMM for a complex LRU could list a dozen files that the OEM could issue a revision too. The LRU itself could easily have the processing power of a dual processor desktop computer.

Sometimes you load via an onboard HDD, notebook computers, a data loader, or by inserting media directly into the face of the box.

We get a lot of calls for software version questions, boxes not taking loads, boxes not working after software loads etc.

When it comes to forward looking implementations for things like integrated avionics modules where there is a single ubiquitous computing platform running software modules in protected partitioned calculating space (software LRUs) each developed by different vendors for the functions they specialize in, it sounds like the stuff nightmares are made of.

Conceptually (and maybe from a marketing standpoint), it sounds nice, but sounds impossible to maintain over decades of use. There is no bug free software.

Early hybrid attempts toward that model have been in service now for decades.

I understand, in one case, the OEM farmed the development of the platform software to a company in another country, and that company has at least once, gone out of business or been purchased by other companies. There is no way to completely test the software for anything that involves so many other systems from other manufacturers on a hot bench anywhere. Every new release brings with it troubleshooting for new bugs.

I have been encouraging NTSB staffers to compare notes across modes for transportation accidents in which the microprocessor based system has been part of the causal chain. I know of at least one maritime accident, one aviation accident and one highway-rail grade crossing accident where a failure of system integration or version control was part of the causal chain. Microprocessor based systems can fail because of hardware failures, software failures, especially logic errors, because of installation errors or because of integration errors. It is impossible a priori to estimate the likelihood of system failure in a condition not part of the specifications and testing. Integration errors, logic errors and installation errors are not random or predictable.

I believe it is impossible at present and that it may be proved to be impossible mathematically to estimate the likelihood of failure of processor based systems.

I wonder though, if this thread has not become different enough from the original post, which referred to the likely failure rate of engines, that it deserves a new heading.

 

[Dan Thomas]

Actually a turbine is somewhat more inherently reliable since there are no reciprocating parts and considerably fewer moving parts and no ignition system.

And the parts under stress don't see rapid, repeated on-off load cycles, so fatigue takes a lot longer to happen.

The Electras I used to work on were all built between 1958 and 1961 and they were still using engines built around that time, though they'd been overhauled a few times. Most were at 50,000 hours TT or more. I was surprised that most of the maintenance involved inspecting stuff and finding little wrong, and replacing stuff that had to be replaced yearly no matter what even if it was working fine.

Turbines made helicopters commercially viable; before that their useful load was too small because the engines weighed 2 pounds per horse or more, while a turbine can weigh a quarter of that. Same thing for airliners. And reliability and TBO increased enormously compared to the old radials, at the cost of fuel consumption.

Dan

 

[Skylane81E]

Yep, even a simple recip has lots of parts moving in different directions, at different speeds and some slamming back and forth

A turbine can be as simple as one part smoothly spinning in one direction. Once metallurgy got to the point where materials could handle the heat soaking from the combustion always going on in the same place turbines took over the big engine market