Software bug brought down A400m in Spain.

Long Time Lurker

Article says that a software bug sent conflicting messages between each engines ECU and essentially shut three motors down.

http://www.theregister.co.uk/2015/05/20/airbus_warns_of_a400m_software_bug/

Jimmy444

Long Time Lurker wrote: »

Article says that a software bug sent conflicting messages between each engines ECU and essentially shut three motors down.

So whatever happened the concept of "fail-safe", i.e. Computer, if you can't figure out what's going on, hand it back to me, don't just shut down my engines?

PukkaStukka

If this is true, it is utterly shocking.

man98

Pity such a basic issue brought about the crash. Is it a systemwide issue or just that one aircraft?

eatmyshorts

man98 wrote: »

Pity such a basic issue brought about the crash. Is it a systemwide issue or just that one aircraft?

That aircraft was the first to fly with new trial software that enabled "military manoeuvres" from take off by using new fuel trimming and pumping laws.

Test flying is dangerous. Things go wrong, we learn, we improve and continue.

PukkaStukka

PukkaStukka wrote: »

If this is true, it is utterly shocking.

Having said the above, I'd wait for a more official confirmation of the cause before passing judgement on this. But I stand by what I said if the cause does indeed turn out to be primarily software related

murphaph

Sorry it's only in German but Der Spiegel magazine is reporting that the Luftwaffe are not convinced by Airbus' likely cause and believe something more fundamental is wrong with the flight management system. They are apparently waiting for the Spanish air accident investigators to deliver their report before allowing their A400Ms to fly again, at the very earliest.

Deep Thought

man98 wrote: »

Pity such a basic issue brought about the crash. Is it a systemwide issue or just that one aircraft?

Software is not a basic issue. Its a complex system and very very difficult to test and validate

man98

Deep Thought wrote: »

Software is not a basic issue. Its a complex system and very very difficult to test and validate

Well I'd have said knowing you'd software definitely works is one of the most basic rules for flying an aircraft, even on a test flight. That said, am above user did point out the dangers.

percy212

I would never put my life entirely in the control of software. It is impossible to completely validate. Things will go wrong.

L1011

percy212 wrote: »

I would never put my life entirely in the control of software. It is impossible to completely validate. Things will go wrong.

I'd advise you not to fly, drive a new car, take a recent train, or a recent lift in a building, or ever get ill and need any medical devices then

murphaph

percy212 wrote: »

I would never put my life entirely in the control of software. It is impossible to completely validate. Things will go wrong.

Mechanical systems fail too. As already pointed out, you likely depend on software not to kill you everyday already.

John_Mc

percy212 wrote: »

I would never put my life entirely in the control of software. It is impossible to completely validate. Things will go wrong.

Nonsense. As a developer myself, I can tell you categorically that it is possible to fully test and validate the correctness of logic in software. It takes a lot more time and effort to get 100% code coverage but it's not that difficult.

Lockheed

Could this not have been prevented if they programmed an error handler for this? Or was the error handler to shut off the engines?

percy212

I was a developer too John_Mc, for almost 30 years. Unless you are using some kind of "formal method" approach for testing, and using that approach on a system that runs in complete isolation, something WILL go wrong at some point. Its just a matter of time. It may not be the code you wrote yourself, but a patch that was added by a vendor, or a third party plugin update, or some kind of incompatibility with systems that communicate with yours, or possibly a hardware swapout. There are many points of potential failure and some will be unknown until you watch them happen in astonishment on your live system.

John_Mc wrote: »

Nonsense. As a developer myself, I can tell you categorically that it is possible to fully test and validate the correctness of logic in software. It takes a lot more time and effort to get 100% code coverage but it's not that difficult.

percy212

All of those provide for human override. We are talking about a system that does not allow intervention by a human.

L1011 wrote: »

I'd advise you not to fly, drive a new car, take a recent train, or a recent lift in a building, or ever get ill and need any medical devices then

John_Mc

percy212 wrote: »

I was a developer too John_Mc, for almost 30 years. Unless you are using some kind of "formal method" approach for testing, and using that approach on a system that runs in complete isolation, something WILL go wrong at some point. Its just a matter of time. It may not be the code you wrote yourself, but a patch that was added by a vendor, or a third party plugin update, or some kind of incompatibility with systems that communicate with yours, or possibly a hardware swapout. There are many points of potential failure and some will be unknown until you watch them happen in astonishment on your live system.

Not if all code is rigorously tested using well designed test plans. It's easy to identify what code is tested and what isn't using modern development tools and ultimately, all functions have inputs and expected outputs that are easy to test against. It either produces the correct output, it doesn't, or it fails in some way. Good code handles all 3 scenarios.

About the patching and updates - that's precisely why unit and integration testing exists.

To clarify, I'm saying that errors like this can be avoided with the right approach and execution. It's not easy but certainly not impossible like you are suggesting.

percy212

Thats all fine and well until something goes wrong, which it always does.

L1011

percy212 wrote: »

All of those provide for human override. We are talking about a system that does not allow intervention by a human.

Medical devices, aircraft engine FADECs, automated railways and lifts (pretty much my entire list of examples) don't.

percy212

Ok. Keep on believing that.

L1011

percy212 wrote: »

Ok. Keep on believing that.

Explain what on earth you're trying to claim here?

Where's the human override in a pacemaker? A FADEC? And so on.

John_Mc

I wouldn't bother L1011 - Percy knows not what he is talking about and won't listen to reason

Deep Thought

John_Mc wrote: »

Not if all code is rigorously tested using well designed test plans. It's easy to identify what code is tested and what isn't using modern development tools and ultimately, all functions have inputs and expected outputs that are easy to test against. It either produces the correct output, it doesn't, or it fails in some way. Good code handles all 3 scenarios.

About the patching and updates - that's precisely why unit and integration testing exists.

To clarify, I'm saying that errors like this can be avoided with the right approach and execution. It's not easy but certainly not impossible like you are suggesting.

Well said...i'm CSV myself and its difficult trying to explain this stuff to people