A400m New strategic and tactical airlifter for the RAF
Discussion
Ginetta G15 Girl said:
Red555 said:
Uncommanded deployment of reverse thrust in the air, particularly of an outboard engine?
How would that happen on a Turboprop?Scuffers said:
...seriously, what the hell were they thinking when they spec'ed all this? did nobody do the 'what if?' scenarios?
Trouble is software is seen as a cheap and easy way to handle edge cases, but every time you add a behaviour the 'what if's' double and it doesn't take long before it's simply impossible to understand all the possible software states.Disclaimer - I've never programmed anything that could kill people, the worst I've done is lost a few million pounds down the back of a processor (I got it back).
Ok, in the back of my mind I keep coming round to this one.
the A400M is a military aircraft, it's not a civilian airliner.
As part of it's job, it's likely to have to enter war zones and thus get shot at.
At what point in the design of the various systems to you have to accept that the pilots are the only ones in a position to make decisions and that second-guessing them using predefined decisions is potentially going to get them killed (as well as losing the plane)?
What I am getting at here is that what would be for a civilian aircraft perfectly logical and sensible, might well be a death sentence.
So here we have a 4 engined plane where 3 of the engines effectively shut down with no way for the pilots to override the software protection.
nearest incident I can think of to this is the A380 that had the uncontained engine failure out of singapore, part of the damage to the plane severed the control links to engine No.1, now, if that engine had gone to flight idle, they would likely have lost control of the plane, it didn't, it just stayed at the power setting it was on until they drowned it on the ground.
Now, I assume that somebody in designing the FADEC operating logic made a decision that this is how it would work (in that situation), and, given the outcome, it was the right decision.
So, you're in a hostile environment, you're taking off in an A400M with a compliment of 100+ troops onboard, you get off the ground ASAP only to find that some decision made years before in the design logic decides that it does not like the look of something and locks out the engine(s) with no way for the pilots to override it.
How is that remotely logical or sensible?
This A400M went down with arguably the best pilots (for the type) at the controls, in an open, non-threatening environment, and yet they had no chance to recover the plane.
Somebody managing this project needs to take several steps back and instigate a review of all the systems of this plane to identify just how many of these 'decisions' have been programmed into the various systems and re-evaluate them in the context of not just this accident, but how they could work together to cause another situation where the pilots are 'locked out'.
The point I am getting at is this, this accident was not the result of a single mistake/failure, but the cascading failure of the design in the way it reacted to a problem.
the problem was missing table in the FADEC's, the catastrophic failure was in the systems responses to this.
The Airbus analogy is the FBW avionics, if all goes wrong, the pilots can revert to 'direct-law' and fly it themselves, sadly for this plane, the FADEC S/W had nothing like this.
(the CV-22 crash where the engines were in 'maintenance mode' has parallels here)
the A400M is a military aircraft, it's not a civilian airliner.
As part of it's job, it's likely to have to enter war zones and thus get shot at.
At what point in the design of the various systems to you have to accept that the pilots are the only ones in a position to make decisions and that second-guessing them using predefined decisions is potentially going to get them killed (as well as losing the plane)?
What I am getting at here is that what would be for a civilian aircraft perfectly logical and sensible, might well be a death sentence.
So here we have a 4 engined plane where 3 of the engines effectively shut down with no way for the pilots to override the software protection.
nearest incident I can think of to this is the A380 that had the uncontained engine failure out of singapore, part of the damage to the plane severed the control links to engine No.1, now, if that engine had gone to flight idle, they would likely have lost control of the plane, it didn't, it just stayed at the power setting it was on until they drowned it on the ground.
Now, I assume that somebody in designing the FADEC operating logic made a decision that this is how it would work (in that situation), and, given the outcome, it was the right decision.
So, you're in a hostile environment, you're taking off in an A400M with a compliment of 100+ troops onboard, you get off the ground ASAP only to find that some decision made years before in the design logic decides that it does not like the look of something and locks out the engine(s) with no way for the pilots to override it.
How is that remotely logical or sensible?
This A400M went down with arguably the best pilots (for the type) at the controls, in an open, non-threatening environment, and yet they had no chance to recover the plane.
Somebody managing this project needs to take several steps back and instigate a review of all the systems of this plane to identify just how many of these 'decisions' have been programmed into the various systems and re-evaluate them in the context of not just this accident, but how they could work together to cause another situation where the pilots are 'locked out'.
The point I am getting at is this, this accident was not the result of a single mistake/failure, but the cascading failure of the design in the way it reacted to a problem.
the problem was missing table in the FADEC's, the catastrophic failure was in the systems responses to this.
The Airbus analogy is the FBW avionics, if all goes wrong, the pilots can revert to 'direct-law' and fly it themselves, sadly for this plane, the FADEC S/W had nothing like this.
(the CV-22 crash where the engines were in 'maintenance mode' has parallels here)
But for ever crash/incident where 'the software' made a decision that is seen as the reason for the crash there will be many where 'the software' prevented a crash. We just don't hear about these ones.
Simply suggesting that the software is trying to be too clever, and everything should be left to the pilot to 'decide on' is a rather Luddite attitude, and the massive improvements in aircraft safety in last 2-3 decades overall show that, I believe, we are heading down the right path.
Two quick examples where if 'the software' had been allowed to make decisions (ie to auto retard and apply fire extinguishers) many people would still be alive:
1) Kegworth 'M1' crash
2) Recent Trans-asia turbo-prop crash
Simply suggesting that the software is trying to be too clever, and everything should be left to the pilot to 'decide on' is a rather Luddite attitude, and the massive improvements in aircraft safety in last 2-3 decades overall show that, I believe, we are heading down the right path.
Two quick examples where if 'the software' had been allowed to make decisions (ie to auto retard and apply fire extinguishers) many people would still be alive:
1) Kegworth 'M1' crash
2) Recent Trans-asia turbo-prop crash
hantsxlg said:
Simply suggesting that the software is trying to be too clever, and everything should be left to the pilot to 'decide on' is a rather Luddite attitude, and the massive improvements in aircraft safety in last 2-3 decades overall show that, I believe, we are heading down the right path.
I doubt very much that it's anything to do with software, but more to do with an understanding of Human Factors and better training.hantsxlg said:
Two quick examples where if 'the software' had been allowed to make decisions (ie to auto retard and apply fire extinguishers) many people would still be alive:
1) Kegworth 'M1' crash
2) Recent Trans-asia turbo-prop crash
In both those cases had the pilots sat on their hands until sure neither a/c would have been lost.1) Kegworth 'M1' crash
2) Recent Trans-asia turbo-prop crash
Specifically in the second case, as discussed on this very Forum, the failed engine had already autofeathered. The crew then shut down the remaining live engine. Please explain how software could have prevented that?
The point is moot anyway since we are discussing a Military airlifter and not an airliner.
Edited by Ginetta G15 Girl on Friday 10th July 11:45
hantsxlg said:
But for ever crash/incident where 'the software' made a decision that is seen as the reason for the crash there will be many where 'the software' prevented a crash. We just don't hear about these ones.
Simply suggesting that the software is trying to be too clever, and everything should be left to the pilot to 'decide on' is a rather Luddite attitude, and the massive improvements in aircraft safety in last 2-3 decades overall show that, I believe, we are heading down the right path.
Two quick examples where if 'the software' had been allowed to make decisions (ie to auto retard and apply fire extinguishers) many people would still be alive:
1) Kegworth 'M1' crash
2) Recent Trans-asia turbo-prop crash
neither of these two would have been solved using SW.Simply suggesting that the software is trying to be too clever, and everything should be left to the pilot to 'decide on' is a rather Luddite attitude, and the massive improvements in aircraft safety in last 2-3 decades overall show that, I believe, we are heading down the right path.
Two quick examples where if 'the software' had been allowed to make decisions (ie to auto retard and apply fire extinguishers) many people would still be alive:
1) Kegworth 'M1' crash
2) Recent Trans-asia turbo-prop crash
from memory, the Kegworth one was not helped by the indicators being close together making it hard (in a shaking plane) to identify which engine it was, but that was considered a minor contributor to the events.
As GGG said, both would have been better off doing nothing.
one of the problems with bringing up alarms is that people feel pressured into reacting to them ASAP, and whilst in some cases that's right a proper, acting in haste without assessing the situation often leads to the wrong action(s).
What you have to remember here is that it was not a single failure that led to the crash, arguably the first failure was on powering up the aircraft, the FMS did not identify problems with the FADEC's on 3 engines.
the next was the engines all started,
Next that they could be throttle up to taxi
Next that the 3 'bad' engines could be throttle up to take-off power
Next that once the plane was in the air, they 'stuck' on take-off power
Next the pilots having managed to gen them to flight idle, then got locked out of exiting flight idle.
I am sure there's probably at least another few steps in there too that we are unaware of, however, the basic point is that the plane should never have even got to starting the engines without major warnings to the pilots.
these are basic design failures as opposed to S/W faults IMHO
S/W faults are things like the interger overflow on the 787's
http://www.engadget.com/2015/05/01/boeing-787-drea...
I can imagine the programmer never considered it possible having a plane powered up for 248 days...
I think you both just back up my point. In both the incidents I mentioned IF the s/w was designed to auto-feather/retard and apply extinguishers and the flightcrew trained to follow the procedures (ie let the a/c sort it out and monitor) they WOULD have sat on their hands.
I agree that the A400m incident seems to be a c8ck up on the s/w installation side that caused people to die. But we have seen c8ck ups on the mechanical side of design and construction as well and no one jumps to the conclusion that robots should do all construction as a number of people in a chain all made mistakes.
I agree that the A400m incident seems to be a c8ck up on the s/w installation side that caused people to die. But we have seen c8ck ups on the mechanical side of design and construction as well and no one jumps to the conclusion that robots should do all construction as a number of people in a chain all made mistakes.
hantsxlg said:
I think you both just back up my point. In both the incidents I mentioned IF the s/w was designed to auto-feather/retard and apply extinguishers and the flightcrew trained to follow the procedures (ie let the a/c sort it out and monitor) they WOULD have sat on their hands.
err.. no.the prop one, the engine had throttled back and fathered all on it's own, the pilots then shut down the other one!
the difference is they were not locked out of effecting a change (and in their case, the wrong change!)
hantsxlg said:
I agree that the A400m incident seems to be a c8ck up on the s/w installation side that caused people to die. But we have seen c8ck ups on the mechanical side of design and construction as well and no one jumps to the conclusion that robots should do all construction as a number of people in a chain all made mistakes.
that's not the point I am getting at, namely, how did the plane ever get into the air without the issue being picked up? right from power on, to take off.for the system checks NOT to pick up something as fundamental as this is a huge design failure.
Yes, it only came and bit them when a production line failure occurred, but even if this accident never happened, the design flaw would still be there waiting for the holes to line up in some other circumstance...
RWD cossie wil said:
Ginetta G15 Girl said:
Beyond Rational said:
Aren't there quite a few cases where the working engine has been shut down by the crew though?
Yes, because they were Edited by Ginetta G15 Girl on Thursday 9th July 23:49
Scuffers said:
Ok, in the back of my mind I keep coming round to this one.
the A400M is a military aircraft, it's not a civilian airliner.
As part of it's job, it's likely to have to enter war zones and thus get shot at.
At what point in the design of the various systems to you have to accept that the pilots are the only ones in a position to make decisions and that second-guessing them using predefined decisions is potentially going to get them killed (as well as losing the plane)?
What I am getting at here is that what would be for a civilian aircraft perfectly logical and sensible, might well be a death sentence.
So here we have a 4 engined plane where 3 of the engines effectively shut down with no way for the pilots to override the software protection.
nearest incident I can think of to this is the A380 that had the uncontained engine failure out of singapore, part of the damage to the plane severed the control links to engine No.1, now, if that engine had gone to flight idle, they would likely have lost control of the plane, it didn't, it just stayed at the power setting it was on until they drowned it on the ground.
Now, I assume that somebody in designing the FADEC operating logic made a decision that this is how it would work (in that situation), and, given the outcome, it was the right decision.
So, you're in a hostile environment, you're taking off in an A400M with a compliment of 100+ troops onboard, you get off the ground ASAP only to find that some decision made years before in the design logic decides that it does not like the look of something and locks out the engine(s) with no way for the pilots to override it.
How is that remotely logical or sensible?
This A400M went down with arguably the best pilots (for the type) at the controls, in an open, non-threatening environment, and yet they had no chance to recover the plane.
Somebody managing this project needs to take several steps back and instigate a review of all the systems of this plane to identify just how many of these 'decisions' have been programmed into the various systems and re-evaluate them in the context of not just this accident, but how they could work together to cause another situation where the pilots are 'locked out'.
The point I am getting at is this, this accident was not the result of a single mistake/failure, but the cascading failure of the design in the way it reacted to a problem.
the problem was missing table in the FADEC's, the catastrophic failure was in the systems responses to this.
The Airbus analogy is the FBW avionics, if all goes wrong, the pilots can revert to 'direct-law' and fly it themselves, sadly for this plane, the FADEC S/W had nothing like this.
(the CV-22 crash where the engines were in 'maintenance mode' has parallels here)
Who turns the osprey flight/maint selector to the desired selection?the A400M is a military aircraft, it's not a civilian airliner.
As part of it's job, it's likely to have to enter war zones and thus get shot at.
At what point in the design of the various systems to you have to accept that the pilots are the only ones in a position to make decisions and that second-guessing them using predefined decisions is potentially going to get them killed (as well as losing the plane)?
What I am getting at here is that what would be for a civilian aircraft perfectly logical and sensible, might well be a death sentence.
So here we have a 4 engined plane where 3 of the engines effectively shut down with no way for the pilots to override the software protection.
nearest incident I can think of to this is the A380 that had the uncontained engine failure out of singapore, part of the damage to the plane severed the control links to engine No.1, now, if that engine had gone to flight idle, they would likely have lost control of the plane, it didn't, it just stayed at the power setting it was on until they drowned it on the ground.
Now, I assume that somebody in designing the FADEC operating logic made a decision that this is how it would work (in that situation), and, given the outcome, it was the right decision.
So, you're in a hostile environment, you're taking off in an A400M with a compliment of 100+ troops onboard, you get off the ground ASAP only to find that some decision made years before in the design logic decides that it does not like the look of something and locks out the engine(s) with no way for the pilots to override it.
How is that remotely logical or sensible?
This A400M went down with arguably the best pilots (for the type) at the controls, in an open, non-threatening environment, and yet they had no chance to recover the plane.
Somebody managing this project needs to take several steps back and instigate a review of all the systems of this plane to identify just how many of these 'decisions' have been programmed into the various systems and re-evaluate them in the context of not just this accident, but how they could work together to cause another situation where the pilots are 'locked out'.
The point I am getting at is this, this accident was not the result of a single mistake/failure, but the cascading failure of the design in the way it reacted to a problem.
the problem was missing table in the FADEC's, the catastrophic failure was in the systems responses to this.
The Airbus analogy is the FBW avionics, if all goes wrong, the pilots can revert to 'direct-law' and fly it themselves, sadly for this plane, the FADEC S/W had nothing like this.
(the CV-22 crash where the engines were in 'maintenance mode' has parallels here)
How on earth can the operation of a selector between modes be a design failure?
Mojocvh said:
Who turns the osprey flight/maint selector to the desired selection?
How on earth can the operation of a selector between modes be a design failure?
When it still allows the pilot to attempt a take off unaware of being in said mode.How on earth can the operation of a selector between modes be a design failure?
(To be clear, this costs people their lives)
Mojocvh said:
Who turns the osprey flight/maint selector to the desired selection?
How on earth can the operation of a selector between modes be a design failure?
Because when you are designing something, you start with the requirements. Some of those requirements relate to safety. Some of those safety requirements relate to human factors. If your design doesn't adequately meet, or trade between those requirements, then it's a design failure.How on earth can the operation of a selector between modes be a design failure?
Mave said:
Mojocvh said:
Who turns the osprey flight/maint selector to the desired selection?
How on earth can the operation of a selector between modes be a design failure?
Because when you are designing something, you start with the requirements. Some of those requirements relate to safety. Some of those safety requirements relate to human factors. If your design doesn't adequately meet, or trade between those requirements, then it's a design failure.How on earth can the operation of a selector between modes be a design failure?
I'll just let you ponder that.
Mojocvh said:
Mave said:
Mojocvh said:
Who turns the osprey flight/maint selector to the desired selection?
How on earth can the operation of a selector between modes be a design failure?
Because when you are designing something, you start with the requirements. Some of those requirements relate to safety. Some of those safety requirements relate to human factors. If your design doesn't adequately meet, or trade between those requirements, then it's a design failure.How on earth can the operation of a selector between modes be a design failure?
I'll just let you ponder that.
I'll leave you to also ponder what was said about the design at the time;
"(The commanding officer) also targeted the design of the aircraft made by a Bell and Boeing joint-project, and oversights by naval air safety officials, saying: “It is inexplicable that an aircraft systems design would allow a crew to take an aircraft flying with a potential degradation in engine power of 20 percent without providing a caution or warning alerting them of the situation. This poor design, and the fact there is no documentation to warn the crew of this design in (naval operating procedures) is a contributing factor to this mishap.”
And if there was no design failure, why was the software redesigned and implemented within 3 months to prevent a recurrence? And why did the report also say "a design flaw in the
tiltrotor aircraft, since corrected, deprived the engines of enough flight power."?
Edited by Mave on Saturday 11th July 17:22
Edited by Mave on Saturday 11th July 17:47
Mave said:
And if there was no design failure, why was the software redesigned and implemented within 3 months to prevent a recurrence?
It's not neccessarily referred to as a 'failure' otherwise no-one would own up to it and try to fix them.If the so called 'silly pilots'
have made an error due to the way the kit has been arranged or operates, it's not only a good idea to change it so it doesnt happen again, but also look at the design process so the same error isn't made in another system on another planeThe kegworth crash similarly they changed the instruments to avoid another pilot making the same mistake
What about the Lowestoft Harrier with the two useful controls placed close each other but not so usefully
However those were where pilots made a mistake based on whats presented to them
If the reports are right the pilots had no choice in the matter on this one. Each engine shut down because it thought it was ok as the other 3 engines would be ok. Each engine thought the same.
Why did no-one think the pilots would prefer to have a ropey engine they could work with, than no engines?
What about the Lowestoft Harrier with the two useful controls placed close each other but not so usefully
However those were where pilots made a mistake based on whats presented to them
If the reports are right the pilots had no choice in the matter on this one. Each engine shut down because it thought it was ok as the other 3 engines would be ok. Each engine thought the same.
Why did no-one think the pilots would prefer to have a ropey engine they could work with, than no engines?
Scuffers said:
that's not the point I am getting at, namely, how did the plane ever get into the air without the issue being picked up? right from power on, to take off.
for the system checks NOT to pick up something as fundamental as this is a huge design failure.
Yes, it only came and bit them when a production line failure occurred, but even if this accident never happened, the design flaw would still be there waiting for the holes to line up in some other circumstance...
Precisely. I would have expected this sort of thing to have some kind of emergency ROM backup in the FADEC so that the plane could be flown even without the software installed (that could be a big issue if you needed to move the plane in an emergency), as well as a flashing light and a buzzer to let everyone know there was an issue. for the system checks NOT to pick up something as fundamental as this is a huge design failure.
Yes, it only came and bit them when a production line failure occurred, but even if this accident never happened, the design flaw would still be there waiting for the holes to line up in some other circumstance...
For something like a FADEC the error checking and trapping should be incredibly robust, but it sounds like they didn't program it to check if all the files are present and correct before taking to the air. That seems incredibly basic to me, and the sum of my programming experience is Excel macros.
Gassing Station | Boats, Planes & Trains | Top of Page | What's New | My Stuff