Slashdot Mirror
Missing Files Blamed For Deadly A400M Crash
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.
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.
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.
Have gnu, will travel.
Depressingly, that might actually be true.
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.
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.
Where are we going and why are we in a handbasket?
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.
If you want news from today, you have to come back tomorrow.
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.
+ http://en.wikipedia.org/wiki/T...
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. ^_^
You would be sadly mistaken.
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.
Do not look into laser with remaining eye.
" The more they overthink the plumbing, the easier it is to stop up the drain. " - Montgomery Scott, Star Trek III
WTF? No automated system check to determine if all needed files are present before flying??!
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
WTF? No automated system check to determine if all needed files are present before flying??!
Sure there is.
We call it 'gravity'.
So it would probably have worked, and not crash because someone was using tr(1) to parse some output in an overly complicated shell startup system...
This is why Dr. McCoy didn't trust the transporter.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.