Thursday, November 18, 2010

The loudest noise at 60 MPH is the ticking of the clock

So went the Rolls Royce car ads years ago, back when Rolls actively marketed cars in the US. They used to do TV ads for Rolls. Haven't seen one for 30 years.
Actually, Rolls Royce sold off the car operation and makes its money on jet engines. And they are in trouble now. Aviation Week has a writeup on the catastrophic engine failure on the Quantas A380. Apparently the intermediate speed turbine failed, and flung turbine buckets out thru the engine casing, punching holes in the wing, a fuel tank and damaging hydraulic lines. Engine failure doesn't get worse than this.
Even worse, the Quantas engine failure looks to be related to the engine failure on Boeing's 787 program. Rolls-Royce may be in for an expensive recall and redesign.
Other problems showed up. The crew attempted to shut down the blown engine by closing a fuel valve. The digital engine control would not let them, it was programmed to keep the valve open in flight, lest the engine shut down for lack of fuel. Microprocessors can be really stupid sometimes.
Jet engine design is always a compromise between stoutness and lightness. The engine has to contain enormous forces and extreme temperatures. This calls for stout. To save on fuel, the engine wants to be as light as possible. Lightness reduces stoutness. It could be that the Rolls designers went too far in the lightness direction. This might be hard to fix, short of a complete redo.
What's worse for Rolls, is the A380 and the 787 can accept American engines and the airplane customer can order the planes with Rolls engines or American engines. Guess which engine maker is not going to be specified on future airliner orders?

3 comments:

DCE said...

It's not the microprocessors that are the problem. It's the code running in them.

This is not the first time Airbus has had problems with software on their aircraft. I seem to recall an AirBus A320 that was doing a slow flyby at an airshow in Europe, with flaps and gear down as if it were going to land. When the pilot hit the "Go around" button on his control stick - which was supposed to increase engine power and raise the gear and flaps - the aircraft continued as if it was going to land. Manually increasing the throttles had no effect (all of the flight controls were fly-by-wire, meaning computers ran everything). The A320 ended up crashing past the end of the runway when it stalled.

Hardware guys usually have a handle on things like that. Software is only as good as those who wrote it.

dstarrboston@roadrunner.con said...

I'm a switch hitter, I do hardware design and I also write code, usually to run in my hardware. Without a program, a microprocessor just draws power, it doesn't do anything. So most of us in the industry tend to think of the uP and the code in its PROM as a single "thing". Especially when it does something bad.
I gotta admit that the hardware guys have a better track record than the software guys. Probably the hardware guys went into hardware 'cause they are interested in the hardware, they will take it out in the field, run it, tinker with it and read up on it. Software guys have it harder in the practical experience dept. They manipulate pure thought stuff, stuff that has no real existence out side of the uP. So they don't get the practical common sense experiences.

DCE said...

I, too, am a hardware guy and write my own code to test portions of my designs, but I rarely write code that will be used in production units. (What code that did make it to production was written in Assembler, making it far more compact than that written in C.)

For things as critical as flight control, the code has to be robust and fault tolerant. As flight control systems are 'expert' systems they tend to be fragile, meaning that if they come across a condition outside their logic tree, they break. For flight systems that can be fatal.

If I recall correctly, another Airbus crashed on a flight from South America to Europe when its pitot tube sensors failed because the heaters hadn't been reconnected after maintenance. The flight control computers weren't able to sense the speed of the aircraft and in the end caused the flight crew to lose control as the system made inappropriate flight control adjustments. If the system had been able to access the GPS system to read the aircraft's speed, it's likely it wouldn't have crashed. (The ground speed isn't the same as air speed, but at least with the GPS data it would have known it was moving at close to 600MPH and not zero!)