Missing Files Blamed For Deadly A400M Crash 253
An anonymous reader writes: Think you had a bad day when your software drivers go missing? Rejoice, you get to live! A fatal A400M crash was linked to data-wipe mistake during an engine software update. A military plane crash in Spain was probably caused by computer files being accidentally wiped from three of its engines, according to investigators. Plane-maker Airbus discovered anomalies in the A400M's data logs after the crash, suggesting a software fault. And it has now emerged that Spanish investigators suspect files needed to interpret its engine readings had been deleted by mistake.This would have caused the affected propellers to spin too slowly causing loss of power and eventually, a crash.
Good god. (Score:5, Insightful)
Is it so hard to have a integrity check and diagnostic set run as part of the preflight checks? If you can place hundreds of miles of wire and know what's what, surely they have computer engineers competent enough to make something like this to catch such glaring errors.
Re:Good god. (Score:5, Insightful)
Re:Good god. (Score:5, Insightful)
Re:Good god. (Score:4, Funny)
I heard the first patch recommendation came from the marketing department, but management refused their idea of cutting one leg of each Toyota owner.
Re:Good god. (Score:5, Insightful)
Re: (Score:3)
Incorrect. They provided the requested firmware and it proved to be robust. The only way the investigators could make it fail was to use the debugger to very carefully manipulate data in RAM in a very specific way. The probability of that happening in real life is vanishingly smaller. Your car is more likely to be hit by a falling meteorite.
There were some other vague claims, but the investigators were hampered by the fact that the source code was in Japanese and they couldn't read it, only copy/paste it in
Re:Good god. (Score:5, Interesting)
You mean, people accidentally mashing both pedals at the same time?
Possibly. But there was a published third-party analysis of Toyota's ECU software which made me reluctant to buy one:
http://embeddedgurus.com/barr-... [embeddedgurus.com]
I was glad to see that my new SUV automatically cuts the gas if it detects you pressing both pedals at the same time, even if due to a bad sensor or crashed throttle-monitoring process (yeah, I know, that means no left-foot braking, but if you're doing that in an SUV, you're probably doing it wrong).
Re: (Score:2, Insightful)
>(yeah, I know, that means no left-foot braking, but if you're doing that in an SUV, you're probably doing it wrong).
Sooooooo... no offroading for your SUV?
Re: (Score:2)
Sooooooo... no offroading for your SUV?
It's not designed for serious offroading like a Jeep, and the stability control automatically brakes individual wheels when you put it in off-road mode.
Re:Good god. (Score:5, Informative)
>(yeah, I know, that means no left-foot braking, but if you're doing that in an SUV, you're probably doing it wrong).
Sooooooo... no offroading for your SUV?
SUV's arent built to go off road.
They dont have locking diffs, a low range gearbox and often, not even underside protection. Most SUV's dont even have full time AWD as they dont have a centre diff, they use systems like the Haldex Traction to transfer power from a latitudinally mounted engine (transverse mounted, AKA: east-west) that drives the front wheels 99% of the time.
Most SUV's are no more suited to going off road than your average Camry and get stumped by the first slightly damp grassy slope they come across.
And yes, if you're left foot braking you're doing things horribly, horribly wrong. Doubly so for heel-toe. There are very few times when you need to left foot brake or heel-toe and none of them are on the road. Keep the fancy foot work for the track and dance floor, drive properly on the road.
Re: (Score:3)
OK, I've read some of the following discussion and you're all making interesting points. But in the world of "Everyone has an anecdote" I have an anecdote: My current car, a Mazda RX-8 was bought used, and the synchros in second and third gear were knackered. Second was essentially unsynchronized and third was
Re: (Score:3)
And yes, if you're left foot braking you're doing things horribly, horribly wrong.
Says you. Left foot braking has been proven to be quicker, therefore improves stopping distance and reduces chances of a crash.
Citation.
Here are the reasons you dont use left foot braking, especially in an emergency situation.
1. In an emergency, you use the left foot to brace yourself against the body of the car to prevent injury (for those of us who can drive properly, this means dont clutch in when you're going to crash for the same reason).
2. You're less likely to mistake the brake for the accelerator.
3. You're less likely to press the brake as you're accelerating. In the olden days, this only meant that the brake light
Re: (Score:3)
No, it really is the other way around. In an emergency situation, the action that requires the least thought is always least likely to fail. Consider the difference:
Re: (Score:3)
Wait, are you here suggesting that you can use one foot to brace your body against a car to prevent injury?
Do you at all comprehend the forces involved? Your entire musculature in this kind of situation is utterly miniscule and irrelevant.
Re: (Score:3)
And yes, if you're left foot braking you're doing things horribly, horribly wrong.
Says you. Left foot braking has been proven to be quicker, therefore improves stopping distance and reduces chances of a crash.
Citation.
Er every professional racing car driver that needs to stop in a hurry...
Oh but if you need a link to some website then try this: http://jalopnik.com/why-you-sh... [jalopnik.com]
If you can't do it properly that's fine, but it doesn't make to wrong for those of us that can.
Re: (Score:3, Insightful)
You clearly have not done the SAAB slide to get around a corner faster. You do not press the clutch or change gears during the maneuver as the whole point is to apply power during the turn. Although heel-toe, or fat-footing works to apply both throttle and brake, it is not as controllable.
Sadly many use the left foot for braking under normal circumstances as they are unfamiliar with a manual transmission.
Re: (Score:3, Informative)
That was toyota's excuse. In reality it actually *was* a software error (actually several)
Re:Good god. (Score:5, Insightful)
We've lost that kind of 'slow down and make sure it's right' attitude that engineers really need to have. In this fast-paced road of cutting costs and letting the marketing group run the show, the pressure to get product out the door as quickly as possible no matter what is unstoppable for software in particular, but really almost anything that is able to be 'patched' later. Making consumers into your beta testers is douche-y enough, but doing it when lives are at stake should be punished as criminal and in an extremely harsh and public way.
As far as I know aerospace software is far away from what you describe. Of course you're right if you say that these things are a reason for problems, but THIS is very well understood and usually software for planes is nothing like a consumer product.
They screwed up, yes, but if they would be "punished as criminal and in an extremely harsh and public way" nobody would ever do anything useful anymore. The problems leading to this crash have to be analyzed and understood and then they have to make sure that the same thing can't happen again.
But of course: If this was due to someone not following procedures or messing around with maintenance this can (and will) have consequences. I'm also pretty sure that one or more people will lose their job over that.
But if you really think you can make shit never happen and things working 100% all the time by "hard punishment" you're just wrong.
Re:Good god. (Score:5, Insightful)
You know, when an accident happens, the safety board (NTSB, TSB, BEA, etc) interviews are actually privileged information. As in, if you're being interviewed by the safety board, anything you say cannot be used as evidence against you.
It's a privilege that the safety boards all fight for.
The reason for this is the safety board's goal is to not find fault, but to find solutions to preventing it from happening again. Doesn't matter if someone hit a button that said "Crash this plane" and pushed it on purpose. They know that if the interviews were not privileged communications, no one would speak to them for fear of self-incrimination. And when that happens, everyone clams up, and you can't figure out why an accident happened or make recommendations to prevent the issue the next time it happens.
This is especially more so when most complex accidents are a chain of events - this happened, then that happened, then this next thing, plus X, Y and Z and if any of them didn't occur, the accident wouldn't have happened. Almost never is it the result of one definitive action.
Re: (Score:2)
If someone was deliberately messing around with the files when they weren't meant to, that would be grounds for criminal negligence. They could end up in front of a court, not just out of work. But I agree with your point, harsh punishments dont work as much as people pretend they do. But thi
they slowed down alright (Score:2)
We've lost that kind of 'slow down and make sure it's right' attitude that engineers really need to have.
Oh, they slowed down alright, but the attitude was not right.
this would have caused the affected propellers to spin too slowly causing loss of power and eventually, a crash.
Re: (Score:2)
Re:Good god. (Score:5, Insightful)
If the calibration data are nice, good for fuel economy, improve reliability, etc. you'd expect things to continue working without them, albeit possibly not as well as the manual specifies.
If the calibration data are Absolutely Vital Lest The Engine Throw A Propellor Right Through The Cockpit, or something of that nature, how did the aircraft allow you to take off with 75% of the data missing? An actual error handling arrrangement would, of course, be in good taste; but even without one I would have (naively, apparently) expected the situation to take one of two courses: if the data are semi-optional, things would work, if perhaps not well. If they are Vital, attempting to get off the ground would have failed. Successful takeoff, followed by shutdown and fiery death, though, seems weird.
Re:Good god. (Score:4, Insightful)
On this type of safety critical application, it's a key design aim to avoid code which might fail or throw an exception at runtime. So, rather than load data from a file, which could fail due to a memory allocation failure, a file system failure, etc. the relevant data is static linked, so if the executable successfully launches, it cannot fail to have the data available.
I don't know what these tables might have been mapping, but conceivably if they torque tuning parameters, the engine might still have run if the data was all NULLs, but delivered the incorrect torque in response to control inputs. Of course, if the missing data was things like fueling data, then the engine may have failed to start.
Re:Good god. (Score:5, Informative)
if the calibration data are so important that the engine shuts down without them, how did the aircraft take off?
One engine delivering full power and 3 engines running at low RPM would be enough to take off, since the plane was empty and probably had a small fuel load as well.
Wiki has an article on the crash: http://en.wikipedia.org/wiki/2... [wikipedia.org]
Looks like they took off, but noticed a problem with the engines, turned around to do an emergency landing, but hit an electrical pylon and crashed. So it's not like they lost all power and fell out of the sky, they had some power and were doing an emergency landing when they hit an object on the ground just before touchdown. 2 of the 6 people on the plane survived.
Re:Good god. (Score:5, Informative)
Re: (Score:3)
This is pretty bad bit of piloting then. There are at least two ways they should have known something was wrong if the engines where not producing enough power.
1. The engine gauges should be abundantly clear between the RPM and pressure ratio. Both are an excellent indicator of how much power you are getting and if either was incorrect or unsteady after throttle up from flight idle, in ANY of the engines you DON'T proceed but abort your takeoff. You NEVER take an airplane airborne with an engine problem
Re: (Score:3)
It is possible though that the engine uses two sets of tweak parameters, a "default" one during take-off and the "optimized" one when altitude hits 400ft. Everything went downhill (bad pun) when the empty LUT was switched in (at 400ft) and only then the 3 engines lost their thrust.
Re: (Score:2)
If that's true, this this is an incredibly bad design flaw by Airbus, something on par with forgetting to connect the emergency break handle to the devices designed to stop the wheels from turning.
Re: (Score:2)
This is pretty bad bit of piloting then...
Do us all a favor. When the full accident report comes out and you find out you had your head in your ass, please try to learn from it. Then apologize to the families of those you've slandered.
I wouldn't fault your ignorance of how transport category aircraft are operated if you didn't try to pass judgement on men who are/were far more accomplished than you will ever be.
Re: (Score:3)
My 2001 Jeep has a base "go home mode" if there is a problem to where the normal engine parameter look up tables can't be used. This way you can still drive the thing to a shop even if some sensors, etc are shot. I know this is a pretty primitive comparison but, at the very least, you'd think the A400M engine software would have a *baked in* "go home without crashing" dataset.
Re: (Score:3)
Re: (Score:2, Interesting)
limp mode also governs engine RPM to a rather low threshold (sometimes it will simply force the vehicle to a high idle and ignore the throttle entirely if it's drive-by-wire). It is activated if the ECU detects significant engine issues, most especially extreme knocking. It is not limited to the transmission. I've had that mode happen to me on the highway when I only half-way plugged in a MAF sensor and the ECU received significantly faulty data causing wildly incorrect fuel-air mixture ratios. Rather f
Re: (Score:3, Informative)
Re:Good god. (Score:5, Informative)
... you'd think the A400M engine software would have a *baked in* "go home without crashing" dataset.
From how I read the article, it does have a default dataset that it switches to when it detects a problem. From TFA:
Limiting the speed of a ground vehicle is safe. However, limiting the speed of an aircraft causes a crash. It sounds like they need to reevaluate their "limp home" calibration, as we call it in the industry.
Re: (Score:2)
The problem here was 3 faulty engines, for which there was insufficient redundancy - in this case a "common cause" failure that's a much more difficult problem to deal with.
Re:Good god. (Score:5, Insightful)
Read the article... the warning was not designed to kick in until the aircraft was at an altitude of 400ft (120m).
Not only do you not know you have a problem until are in the air. You don't know you have a catastrophic problem until you are at an unsurvivable altitude. Too low to effectively use a parachute. Too high to just 'jump out' or belly-land it.
The worst thing is... a committee signed off that this was an 'acceptable risk'. Members of that committee should be brought of up on criminal negligence and manslaughter charges.
Not a Luddite, but give me my bicycle back...
Re: (Score:2)
Re: (Score:2)
I'm thinking that if they build these decisions into the software then they should also build a couple of test scenarios into the flight simulator and have a pilot fly them a bunch of times to see what happens. Especially the ones where you decide to have them kick in at 120m.
Re: (Score:2)
Re: (Score:3)
Perhaps we should limit your statement to "developers who create applications intended to be used in a setting which may critically impair a human or endanger their life". You can still build all sorts of things privately (performing engineering activities) without ever selling it to anyone or placing anyone's life in jeopardy--and without being licensed. I see no reason for software to be different.
Re: (Score:2, Insightful)
Impractical.
Suppose a developer uses GCC to compile code. Does the developer need to prove the correctness of GCC?
What about the Windows OS? Or the Linux OS?
And software moves so readily from place to place and is so easily incorporated into other projects that it's difficult to imagine a project in a safety critical environment being written completely de novo.
Had the software (and hardware, for that matter) industry been held accountable from the beginning, we wouldn't have these problems today.
It's time
Re: (Score:2, Insightful)
Re: Banking, saying "simplified" is over-simplifying. Oversight by the CFTC was effectively removed by the Bush administration. That's what gave the banks free reign to give million dollar mortgages to Walmart greeters. Then they sliced and diced that crap with good loans, packaged it up as investable instruments on Wall St. and then sold it to the nice folks in Iceland (among many others).
Of course Iceland didn't know that the ratings agencies were also in on the scam. And not many knew about the $500T
Re: (Score:2)
Programmers should have to justify their code and prove its correctness before it's allowed out in the wild.
"Proof of correctness" of code is a bit of nonsense. Practically it comes down to "rite the code in two languages and prove they're equivalent", which does nothing for bad design assumptions. For some components, the firmware is already developed by 2 teams isolated from one another who work in different languages, and you use components from both teams together in a failsafe way. That has at least a chance of protecting you from bad design assumptions. It's quite expensive, however.
For commercial fligh
BIST - Built In Self Test (Score:5, Insightful)
My printer at home does it every time it starts up.
Too bad the airplane doesn't.
I guess production delays are more expensive than debugging-by-crash. Sad.
Re: (Score:2)
More expensive to mgmt.'s bonuses, for sure.
Re: (Score:2)
#!/bin/ksh
if [[ ! -r $config_file ]] ; then
abort "Cannot find engine configuration files"
fi
Well... (Score:2)
Tuesday is crash-day, oops I meant patch-day.
FMEA (Score:2)
Re: (Score:2)
Re: (Score:2)
The article said 3 of the engines "hunkered down" not shut themselves off. They stopped responding to input and stayed at their current power.
They did turn around and attempt to land the plane, but hit a pylon in the process.
Re: (Score:2)
The FMEA's I was party to were basically to give cover. "We had an FMEA, and it still managed to fail." When usually it was actually managed into failure despite engineers asking for more time and less feature creep, and specification uncertainty.
Re: (Score:2)
Re: FMEA (Score:5, Informative)
I've seen software writers follow RFC and ONLY RFC for communications protocols, to the point that anything not explicitly expected per the newest standard of RFC will cause the daemon to crash hard. Doesn't matter if it's garbage on accident, garbage on purpose to try to cause a buffer overflow, or even deprecated commands from previous RFCs, the daemon should handle unexpected input gracefully even if it throws a 500 and closes the connection. To do otherwise (as was done) is irresponsible, but all too common.
Re: (Score:2)
Re: (Score:2)
I expect every engineer to assume human error is guaranteed to happen.
We do\/P>
Except we hide the real problem
.by deeply bring it in bulleted text that is so dense
and full of DOPO between the JIC and JAC
that is so obfuscated and lost in the dense text in 8 point type that things are
fu
bar
Re: (Score:2)
So, how did ... (Score:5, Interesting)
Come on, folks. Turn the power on to the engine controllers at the flight line and the status display should have been flashing warnings. Nobody should have even started this thing.
Re:So, how did ... (Score:5, Informative)
The story seems to massively simplify how the ECUs work. Each engine needs to be calibrated after production so that the sensor data it hands to each ECU is actually meaningful due to the way it's actually acquired in the engine. The parameter set isn't stored in the engine, but in the associated ECU. To prevent them from getting out of sync, the engine itself contains a little register with the checksum of the parameter set. If that checksum doesn't match, the ECU shouldn't power up the engine. However, the register and the ECU are initially loaded with a default parameter set used in testing scenarios. Looks like that one might have been untouched for the engines on that flight. Now, this is bad because the ECU now misreads the true engine status in various ways and can even think that an engine which is otherwise running fine is seemingly in some critical condition - e.g. power output too high, which causes an immediate shutdown to prevent engine damage. A jet engine that fails by disintegration has a high chance of slicing other airplane parts with ripped off fan blades. This is why hard engine shutdowns do make sense. But when putting the pieces of this puzzle together, this is starting to look similar to how Murphy's law came to be: an exceptionally unlikely chain of human errors ruining everyone's day.
Re: (Score:2)
You forget where you are posting..
Every accident in the private market is always the fault of the free market and money hungry CEOs.
Re:So, how did ... (Score:4, Interesting)
A jet engine that fails by disintegration has a high chance of slicing other airplane parts with ripped off fan blades.
It's actually exceedingly rare for there to be an uncontained failure.
That engine shroud is intended to handle catastrophic failures at full throttle.
This video is a test of the Rolls-Royce Trent 900 engine that went into the Airbus A380. The test starts ~3:25 in.
https://www.youtube.com/watch?v=j973645y5AA [youtube.com]
Then again, this is the same engine after an oil leak led to an internal engine fire
https://www.atsb.gov.au/media/2891294/vh-oqa-fig7.jpg [atsb.gov.au]
https://www.atsb.gov.au/media/4173628/ao-2010-089_vh-oqa.jpg [atsb.gov.au]
The Australian Transport Safety Bureau (ATSB) found that a number of oil feed stub pipes within the High Pressure / Intermediate pressure (HP/IP) hub assembly were manufactured with thin wall sections that did not conform to the design specifications. These non-conforming pipes were fitted to Trent 900 engines, including the No. 2 engine on VH-OQA. The thin wall section significantly reduced the life of the oil feed stub pipe on the No. 2 engine so that a fatigue crack developed, ultimately releasing oil during the flight that resulted in an internal oil fire. That fire led to the separation of the intermediate pressure turbine disc from the drive shaft. The disc accelerated and burst with sufficient force that the engine structure could not contain it, releasing high-energy debris.
Most of the shroud's strength is focused around the main fan blades instead of the turbine blades that are much deeper in the engine.
Re: (Score:2)
I dunno, the asshole in me thinks this sounds like one of those Microsoft Validation things.. Free Engine Software for 500 miles, then activation required!
Re: (Score:2, Funny)
It was written in Java. The program caught the exception and moved on.
Re: (Score:2)
But then the Ask Toolbar tried to find a solution to the problem.
Strange... (Score:2)
You'd think there would be some kind of checks in place that wouldn't allow the plane to operate when critical files are missing. Or that the files couldn't be deleted.
Stories like these are the reason I can't believe auto manufacturers are even considering being able to push updates to cars. The checks in place for aircraft hardware is extremely rigorous. Pretty much every nut and bolt has a complete history log. If this kind of thing can happen on an aircraft, what happens when some weird conditions occu
Many regs trace back to accidents (Score:3)
The checks in place for aircraft hardware is extremely rigorous.
Yes, but how many of those regulations and checks trace back to accidents versus an engineer's foresight? I'd expect that most items in a pilot's pre-flight checklist do trace back to accidents. And it seems the computer's pre-flight checklist will too.
I once heard that the expression "Navy regulations are written in blood" was used to explain to new sailors why so many tasks are to be performed exactly the way the regs say and in no other manner. The phrase was then elaborated on explaining to the sailo
Re: (Score:2)
Can throw an exception but will anyone catch it ? (Score:2)
Besides, being well into the era of malware I'm surprised that files aren't delivered as a complete image. Complete with a manifest of files and version numbers and each file being digitally signed.
Or maybe some developer did have such a manifest, his/her code detected the error, reported the error, but the error/exception was handled in a way that didn't rise to the pilot's attention nor prevent engine startup.
I want to see a list of catastrophes (Score:2)
Separated by cause: Software bug vs Hardware bug.
Re: (Score:2)
That would depend who you ask. If you ask the hardware guys, it's always a software problem and vice versa. At least that's the way it is with the hardware guys I work with ;)
Big fail from the software engineering standpoint. (Score:5, Interesting)
Just my take as a software engineer and current DoD employee that works with C17...
There should have been some process on firing up the jet / avionics / computers that ran checks to see that even if software was not latest, was it CONSISTENT?
Big fail from the software engineering standpoint.
Return codes? (Score:5, Insightful)
This is a tragedy, but since we're on a tech site, lets talk tech.
Return values are handled oddly in pretty much every major language. Many API calls want to return something simple- int or bool- and if anything is more complex than that, generally require an actual data structure to be returned, often as a reference. This means that the "I didn't do this" action has a variety of ways to be be passed back- none of them even close to standard.
If something returns a distance, magnitude, or size, "0" normally means "Error, nothing happened" which is often the same as "Sure, I wrote 0 bytes. Really."
If something needs to distinguish between success ("I did the thing 0 times as requested" and failure "I couldn't do the thing because of an error condition"), then sometimes a -1 is returned, or an exception thrown, or something else.
In this plane, something was, at some point, responsible for getting data about the engines. Likely, this happened in layers, each one having access to the results of the lower pieces. One of those pieces had the task of parsing those files.
So EITHER someone (process, program, whatever) meant to say "This is a problem" and instead said "Here's some default data", OR someone ELSE in that chain of commands (process, program, whatever) has a default for a "This is a problem" result to use as a failsafe, and it was never tested or never communicated up.
We probably won't get the technical details that go from "files missing" to "engines don't work". Certainly, several level of software or hardware could allow for any number of workarounds in this case, and I'm sure they have a complex system and this was some eventuality that was hard to test for.
Still, interesting to think about the error return methodology, and how it's so different everywhere in CS.
Missing calibration data, not drivers (Score:2)
The summary, as usual, is terrible. The missing files were calibration data for the engine controllers, not executables of any kind.
However, the article says some astonishingly stupid things, like: "'Nobody imagined a problem like this could happen to three engines,' a person familiar with the 12-year-old project said."
Well, duh.
Since the human imagination is known to be almost completely useless as a tool for understanding reality or predicting the future, this has to be the most obvious observation since
Re: (Score:2)
However, the article says some astonishingly stupid things, like: "'Nobody imagined a problem like this could happen to three engines,' a person familiar with the 12-year-old project said."
If it was a mechanical issue, then yes, I would believe it would be a billion to one chance for something to happen to all three engines. On the other hand, since it is software, I would say that it is a billion to one chance that it would NOT happen to all three engines.
Does the Therac-25 ring a bell for anyone? (Score:5, Informative)
+ http://en.wikipedia.org/wiki/T... [wikipedia.org]
The first computer controlled X-ray machine.... which accidentally irradiated some people to death...
due to *gasp* software faults! (say it ain't so!)
I first heard about the Therac-25 during my "Ethics in Computer Science" class many years ago - it made an excellent case study... about problems just like this one.
Once the textbooks get updated, Therac-25 will be replaced with a case study about the a400m roll out. ^_^
Re: (Score:2)
Will the case study say when a risk is identified and a manual procedure put in place to mitigate the risk is specified, don't be surprised when the procedure fails?
Too much automation by computers (Score:3)
FTFA: "...Without the vital data parameters, information from the engines is effectively meaningless to the computers controlling them. The automatic response is to hunker down and prevent what would usually be a single engine problem causing more damage. This is what the computers apparently did on the doomed flight, just as they were designed to do."
So, in other words, each engine did exactly what is was designed to do, which is to act independently and shut itself down. There's no executive override function that says "hmmm, maybe we shouldn't shut down 3 engines at the same time!" The crew had no chance against an obviously buggy software implementation. Pilots need more control to override complex software like this in emergencies.
Too Slowly? (Score:2)
Re: (Score:2)
A throttle is of no use when the engines can't respond to it. The engines (3 out of 4) initially did not respond to the pull-back from takeoff power at around 1500 feet. The pilot then pulled back to flight idle, and the engines dropped to flight idle. Unfortunately they then did not respond to the throttle back up, and remained stuck at flight idle. You can't keep a plane in the air with 3 out of 4 engines at idle for very long at 1500 feet. (You also can't fly a plane very well with the engines stuck
Re: (Score:2)
Apparently the engines did not turn off. They just didn't respond to an increase in power.
When the airflow meter in a car spits out invalid date, the engine ECU doesn't shut the engine off. It logs a check-engine code and ignores data from that sensor and runs in a safe mode, using parameters it knows will not result in catastrophic failure.
Same thing happens in automatic transmissions, they'll stick themselves in 2nd or 3rd gear and refuse to shift to any others except N or R (Park is still a mechanical se
The last word... (Score:4, Insightful)
Something smells fishy and it's not the fish. (Score:2)
The high tech word of aviation is at least 30 years old. There is a reason for that, it works and it rarely fails. All the fancy stuff is bolted on top of the bombproof legacy gea
Re: (Score:2)
The maintenance software is probably used to load the software on the ECU.
It was ECU software configuration that caused the failure.
Perhaps that's why they're telling their customers not to use the maintenance software.
With 20-20 hindsite (Score:2)
The pilots should have reasoned: "Engines not responding to control. Since the engines are still at least giving us high power, we should climb to a height that gives us options, then try some things to fix the problem, or figure out how to cut the engines completely and glide in, having enough height to get the setup of the difficult approach just right."
Of course the maintenance program manager for the aircraft manufaturer should have reasoned: "All maintenance procedures should be performed by checking o
Left Hand vs Right Hand (Score:3)
Engineer 1: "Hey, I know, I'll build in a function that wipes the entire control system when it starts a firmware update so that no old software gets left behind after the update."
Engineer 2: "It'll save a ton of time on this firmware update if I leave out the engine control functions, since those aren't being updated. My bosses will love me!"
Re: (Score:2)
Except it wasn't engine control functions in the firmware, it was engine-specific calibration data.
Rope and pulley broke a lot, too (Score:2)
I like reminiscing about the rope-and-pulley days but i've been stranded with a broken clutch steel-rope cable, I've had another one snap on a bike, and points-and-condenser ignitions are inhumane and intolerant of lapses in maintenance. That peculiar smell that old cars and old planes had? incomplete combustion.
I like this computer-controlled world. Things work much better.
The rope-and-pulley analog here would be "Hey Bertie, did you put the cotter pin on that rod?" "Ya ya, sure sure!"
Meanwhile, as the
Re:This is what happens when you use Luddite softw (Score:5, Interesting)
Not because of 'apps' of course; but because no self-respecting consumer OS would fail to cryptographically verify the execution environment(lest some precious 'premium content' be absconded with by pirates) and an entire missing file probably would have caused the aircraft to refuse to move until taken back to Airbus HQ for re-blessing by the vender.
They don't succeed against motivated pirates, of course; but this is one area where consumer software vendors do actually give a fuck. If people believed that a sabotaged voting machine or a defective ECU could pirate Blu-rays, we'd live in a safer world.
Re:This is what happens when you use Luddite softw (Score:5, Insightful)
WTF? No automated system check to determine if all needed files are present before flying??!
Re: (Score:3, Funny)
WTF? No automated system check to determine if all needed files are present before flying??!
Sure there is.
We call it 'gravity'.
Re: (Score:2)
Re: This is what happens when you use Luddite soft (Score:4, Funny)
This is why Dr. McCoy didn't trust the transporter.
Re: (Score:3)
Don't starve the trolls.
Re: (Score:3)
If the plane had used apps, it would have systemD!
Re:This is what happens when you use Luddite softw (Score:4, Insightful)
Re: (Score:3)
I hate squirrels!
Re: (Score:2)
Yep.
Yesterday it was a chain that connected A to B.
Today it's a modified ethernet cable running a custom protocol designed in Korea connecting software component A that was designed and built in Germany, tested in Sweden and validated by Japan. Software component B was reverse engineered and written by Joe in a shed.
The chain was probably easier to work with.
Correction: The chain did not create jobs.
All of this other bullshit did.
Mordac did it (Score:3)
Dilbert explains:
http://dilbert.com/strip/2000-... [dilbert.com]
Re: (Score:2)
Re: (Score:3)
Engines did not quit abruptly or kill any crew.
3 out of 4 engines stopped responding to changes in power level and continued to run as they were.
The pilot noticed this, talked to air traffic control and requested to make an emergency landing.
They plan was turned around and headed back to the airport.
The plane crashed into a pylon while attempting the emergency landing.