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.
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?
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.
" 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.
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 computer engineering grew up. Sure, regulation will slow the pace of progress and make things difficult for entrepreneurs, but programmers shouldn't make their money off the backs of those injured by their incompetence. Other industries labor under very strict regulation. There are literally thousands of regulations just for banking, and we saw what happened when things were simplified.
Only strict government oversight of the software industry can prevent injuries to the public.
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 in notional value swaps that leveraged the crap at 100:1 ratios. Much of which still sits as off-balance sheet assets that will never be unwound.
That's why you regulate the piss out of the banks and Wall St. It's really not about politics, it's about keeping the cobra in a closed box and never trust him outside of it.
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...