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.
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.
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 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.