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.
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 occur that cause brakes to fail in an automotive update? That's a a rhetorical question. The answer is the manufacturer will deny everything and make counter accusations, and hope they can fix the problem before anyone finds out.
I'm all for moving forward with technology, but sometimes it seems we're creating more dangerous problems with our solutions.
I hate squirrels!
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.
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 sailors that when things were done otherwise sailors sometimes died, for small things like failing to properly secure a hatch (door).
+ 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. ^_^
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.
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.
Dilbert explains:
http://dilbert.com/strip/2000-...
Some drink at the fountain of knowledge. Others just gargle.
" The more they overthink the plumbing, the easier it is to stop up the drain. " - Montgomery Scott, Star Trek III
If the plane had used apps, it would have systemD!
Get free satoshi (Bitcoin) and Dogecoins
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.
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!"
Nobodies Prefect
Tidbits for Techs Technology Blog
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'.
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.
Don't starve the trolls.
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.
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...
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.