Airbus crash/training flight
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes
on
0 Posts
what are the switch selections which have to be made (on the overhead panel i assume) to fly the aircraft in normal law?
NoD
Guest
Posts: n/a
for Aquadalte
In a general way, I mean to contrast the fundament and perspective of failure.
The Culture of automation seems to be up for criticism here. Likewise the Stick and Rudder brigade. What is important is the Interface twixt the two. Calling a "sidestick" a Stick is presumptuous to some, myself included. The Bus isn't a video game per se, but some pilots are offended by its "arrogance". It's a machine. So is a Boeing.
No Human can leverage the control surfaces on a modern jet, hence boosted controls. It is the motivation for and "thought" behind that impetus that fuels the argument. I tend to favor Red Button, a return to all human pilotage innovating and "creating" a solution in an emergency.
There would be no controversy if many pilots didn't consider the Bus an attempt in some fashion to usurp a pilot's ultimate COMMAND.
AF
The Culture of automation seems to be up for criticism here. Likewise the Stick and Rudder brigade. What is important is the Interface twixt the two. Calling a "sidestick" a Stick is presumptuous to some, myself included. The Bus isn't a video game per se, but some pilots are offended by its "arrogance". It's a machine. So is a Boeing.
No Human can leverage the control surfaces on a modern jet, hence boosted controls. It is the motivation for and "thought" behind that impetus that fuels the argument. I tend to favor Red Button, a return to all human pilotage innovating and "creating" a solution in an emergency.
There would be no controversy if many pilots didn't consider the Bus an attempt in some fashion to usurp a pilot's ultimate COMMAND.
AF
Guest
Posts: n/a
Here's the Rub
Depends on your POV. Some would have the "auto" revert to "manual", some would have it revert to more "auto". If on the one hand, auto can be overridden and hand flown, the hand fly folks would say, why the auto in the first place? I have two recent incidents to fall back on.
BA038. Engines were running, but refused commanded thrust.
1549. Engines were running, but idling. Both are odd results given a qualified crew on deck. Suspicion falls on FADEC.
If engines are spooling and burning fuel, why aren't they increasing when "commanded". The 64 $ question, perhaps. Time will tell.
BA038. Engines were running, but refused commanded thrust.
1549. Engines were running, but idling. Both are odd results given a qualified crew on deck. Suspicion falls on FADEC.
If engines are spooling and burning fuel, why aren't they increasing when "commanded". The 64 $ question, perhaps. Time will tell.
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes
on
0 Posts
BA038. Engines were running, but refused commanded thrust.
....
If engines are spooling and burning fuel, why aren't they increasing when "commanded".
....
If engines are spooling and burning fuel, why aren't they increasing when "commanded".
To increase thrust requires increased Fuel Flow... and if the (extra) fuel cannot get there, no increase in thrust 
NoD
Join Date: Aug 2005
Location: fl
Posts: 2,525
Likes: 0
Received 0 Likes
on
0 Posts
The United 232 DC10 that landed using differential thrust would have been flown as they did whether or not the check airman in back had come up to the cockpit or not. They had no choice and the only solution to get it on the ground under control was using that technique.
For some reason the captain elected to let the pilot sitting in the jumpseat operate the throttles to line up with the runway. All went well until the power was reduced for touchdown and it cartwheeled off into the corn field. A lot of people survived so the teqhnique worked but the captain might have had a better perspective from his normal flying position making the final adjustments from his seat in my opinion.
For some reason the captain elected to let the pilot sitting in the jumpseat operate the throttles to line up with the runway. All went well until the power was reduced for touchdown and it cartwheeled off into the corn field. A lot of people survived so the teqhnique worked but the captain might have had a better perspective from his normal flying position making the final adjustments from his seat in my opinion.
Join Date: Jan 2009
Location: 3 bed semi, nice garden
Posts: 9
Likes: 0
Received 0 Likes
on
0 Posts
thanks nigel - my mistake, i was referring to direct law. what is the sequence you follow to engage that?
i always imagined it would be easy to make this transfer (if you ever had to do it, it would be in a confusing situation, where the flight control logic wasnt responding as you expected or the instruments were giving strange indications).
is this an emergancy drill?
i always imagined it would be easy to make this transfer (if you ever had to do it, it would be in a confusing situation, where the flight control logic wasnt responding as you expected or the instruments were giving strange indications).
is this an emergancy drill?
Direct law is a failure mode that is a consequence of certain failures, such as dual hydraulic loss or a loss of both radio altimeter systems. It is not something that the crew will "select" all on their own when they "think" they need it.
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes
on
0 Posts
There is no button or drill that the crew perform to "select" a different Law specifically... the aircraft systems determine which Law you are in.
There are drills / buttons / levers that have the effect of changing the Law e.g. lowering the Gear in Altn law will put you in Direct law... but you lower the gear so you can land, not to effect the change There are even some drills where you deactivate systems etc. for the purpose of a law change.
In general, the law changes are transparent to the pilots in flying terms, and I can see no great need to wish to fly in 1 Law or another...
NoD
There are drills / buttons / levers that have the effect of changing the Law e.g. lowering the Gear in Altn law will put you in Direct law... but you lower the gear so you can land, not to effect the change
There are even some drills where you deactivate systems etc. for the purpose of a law change.In general, the law changes are transparent to the pilots in flying terms, and I can see no great need to wish to fly in 1 Law or another...
NoD
Join Date: Oct 2006
Location: Gone Flying...
Age: 63
Posts: 270
Likes: 0
Received 0 Likes
on
0 Posts
Coming back to subject
I think the problem here is that, regarding Flight Controls Laws, it is the aircraft logics that "decides" when the bird is sick. It then downgrades the Law to a certain level. The pilot has nothing to do with it (except when performing ECAM actions or selecting some systems off, or selecting Gear Down).
If, by any chance, (coming back to this thread's subject), ADR's got (all of them) the same erroneous information - leading to high speed wrong indication, followed by automatic speed protection - one may think that, there was nothing a pilot could do to counteract the automatic pitch up inputs, except by using non-standard procedures (like inducing the aircraft to an Anternate or a Direct Law) and this is really against all of the Airbus philosophy and formation.
If, by any chance, (coming back to this thread's subject), ADR's got (all of them) the same erroneous information - leading to high speed wrong indication, followed by automatic speed protection - one may think that, there was nothing a pilot could do to counteract the automatic pitch up inputs, except by using non-standard procedures (like inducing the aircraft to an Anternate or a Direct Law) and this is really against all of the Airbus philosophy and formation.
Someone suggested a Red Button. I suggested a change in the software/logics of the use of the instinctive disconnection push button, located in the side stick, to "bring" the aircraft into a "status" (Alternate Law 1) which would bring the aircraft back to manual, although maintaining a great deal of protections. This would be a pilot friendly status, once he could effectively handle and override aircraft built-in protections in case a serious situation arises. Once the problem was solved, he could return to Normal Law (provided certain conditions met) by switching the Auto Pilot ON.
Regarding some comments I've seen here in this thread, I'd like to leave a small message: Please don't play with our intelligence and don't play the role of those guys who think we don't know enough of the aircraft to even make any type of suggestion. Just give us the benefit of doubt, to someone who flies airbuses for almost 20 years, who has studied the system and who has, at least, looked at the Manuals, before coming to this thread making "suggestions"...
Please do not infer from my words any agenda against Airbus. My sole agenda is against arrogance and for flight safety.
As I said before: Airbuses are great aircraft, but they could be better.
Fly Safe
Regarding some comments I've seen here in this thread, I'd like to leave a small message: Please don't play with our intelligence and don't play the role of those guys who think we don't know enough of the aircraft to even make any type of suggestion. Just give us the benefit of doubt, to someone who flies airbuses for almost 20 years, who has studied the system and who has, at least, looked at the Manuals, before coming to this thread making "suggestions"...
Please do not infer from my words any agenda against Airbus. My sole agenda is against arrogance and for flight safety.
As I said before: Airbuses are great aircraft, but they could be better.
Fly Safe
The subject of this thread is the accident of which next to nothing is known, yet many a post is written as if protection gone awry has been proven to cause the crash.
Join Date: Feb 2000
Location: asia
Posts: 542
Likes: 0
Received 0 Likes
on
0 Posts
There are usually only 2 reasons why computers and automation go haywire:
- The program has become corrupted
- The program didn't cater for a particular situation.
As for wanting a big red button to kill the automation and revert to hand flying, there is not and can never be such a thing. You could have a button that would cut out some of the automation, but to cut it all out is impossible - the physical links between the pilot and the things he needs to control are no longer there, having been replaced by electrical signals.
stickyb
Well here I was agreeing with aguadalte and you come in with an authorative sounding statement that doesn't seem to me to match the discussion.
Perhaps there is a misunderstanding among us of the meanings.
Could you precise a little more why/how the aguadalte statement is flawed?
Quote:
Originally Posted by aguadalte
"I think the problem here is that, regarding Flight Controls Laws, it is the aircraft logics that "decides" when the bird is sick. It then downgrades the Law to a certain level. "
Speaking not as a pilot but as a computer boffin, I think that statement is fatally flawed. No computer yet in use aloft has an "adaptive" or "evolutionary" capability. All the computers used aloft run according to very strict rules - those in the program laid down by the software writers.
Originally Posted by aguadalte
"I think the problem here is that, regarding Flight Controls Laws, it is the aircraft logics that "decides" when the bird is sick. It then downgrades the Law to a certain level. "
Speaking not as a pilot but as a computer boffin, I think that statement is fatally flawed. No computer yet in use aloft has an "adaptive" or "evolutionary" capability. All the computers used aloft run according to very strict rules - those in the program laid down by the software writers.
Perhaps there is a misunderstanding among us of the meanings.
Could you precise a little more why/how the aguadalte statement is flawed?
Join Date: Jan 2007
Location: San Jose
Posts: 727
Likes: 0
Received 0 Likes
on
0 Posts
What can happen, and I know it occurs with anti-lock brakes on both aircraft and cars, is that if the computer systems receive a set of conflicting inputs, there can be a deliberate decision on the part of the software to drop out and let the pilot/driver do the work without software interference/assistance. As such, it's similar to option 2 from stickyb's post although it's not going haywire, it's deliberately giving up control.
If there's a bug in the software then it may do strange things if it receives an unusual combination of inputs, either by something crashing or (more subtle) causing an overflow in an intermediate part of the software that produces incorrect output. I think they lost an Ariane rocket to this one once.
If there's a bug in the software then it may do strange things if it receives an unusual combination of inputs, either by something crashing or (more subtle) causing an overflow in an intermediate part of the software that produces incorrect output. I think they lost an Ariane rocket to this one once.
Join Date: Apr 2007
Location: moraira,spain-Norfolk, UK
Age: 82
Posts: 389
Likes: 0
Received 0 Likes
on
0 Posts
ariane V failure
to llondel...
Ariane V failure was definately a software failure.
Without going into details the onboard computers
contained inertial reference software which was not
needed after launch. On Ariane IV which it was designed for
it was normally left running, this practice also used on V.
Due (I remember) to higher slew rate of the short fat Ariane V
some kind of data conversion error occured. This caused
an error to be presented to the flight computer, which in turn
demanded full delection of the motors, ie game very over.
Someone will correct me I'm sure.
Lessons to be learned....
At least try to validate under flight conditions, but I'm not
sure how that would relate to aviation software
Ariane V failure was definately a software failure.
Without going into details the onboard computers
contained inertial reference software which was not
needed after launch. On Ariane IV which it was designed for
it was normally left running, this practice also used on V.
Due (I remember) to higher slew rate of the short fat Ariane V
some kind of data conversion error occured. This caused
an error to be presented to the flight computer, which in turn
demanded full delection of the motors, ie game very over.
Someone will correct me I'm sure.
Lessons to be learned....
At least try to validate under flight conditions, but I'm not
sure how that would relate to aviation software
Guest
Join Date: May 2008
Location: Somewhere between E17487 and F75775
Age: 80
Posts: 725
Likes: 0
Received 0 Likes
on
0 Posts
Changing ze software
esa-aardvaark wrote "someone will correct me I'm sure".
Not really, old colleague, but I'd say the failure was caused by using segments of software from an earlier ARIANE in a later model where it wasn't appropriate.
And here's another one: when commissioning a new spacecraft in orbit, instead of action 'A' happening when command 'A' was transmitted, action 'B happened when 'A' was transmitted and action 'A' happened when 'B' was transmitted.
Representatives of the French constructor of the spacecraft who were present were asked to explain. Pulling out an old envelope and consulting notes written on the back, the French engineer squinted at the scruffy paper and said "we 'av changed ze software just before launch..."
Not a rumour, I was present when it happened.
Not really, old colleague, but I'd say the failure was caused by using segments of software from an earlier ARIANE in a later model where it wasn't appropriate.
And here's another one: when commissioning a new spacecraft in orbit, instead of action 'A' happening when command 'A' was transmitted, action 'B happened when 'A' was transmitted and action 'A' happened when 'B' was transmitted.
Representatives of the French constructor of the spacecraft who were present were asked to explain. Pulling out an old envelope and consulting notes written on the back, the French engineer squinted at the scruffy paper and said "we 'av changed ze software just before launch..."
Not a rumour, I was present when it happened.
Join Date: Oct 2006
Location: Gone Flying...
Age: 63
Posts: 270
Likes: 0
Received 0 Likes
on
0 Posts
llondel...? stickyb...?
What can happen, and I know it occurs with anti-lock brakes on both aircraft and cars, is that if the computer systems receive a set of conflicting inputs, there can be a deliberate decision on the part of the software to drop out and let the pilot/driver do the work without software interference/assistance. As such, it's similar to option 2 from stickyb's post although it's not going haywire, it's deliberately giving up control.
If there's a bug in the software then it may do strange things if it receives an unusual combination of inputs, either by something crashing or (more subtle) causing an overflow in an intermediate part of the software that produces incorrect output. I think they lost an Ariane rocket to this one once.
If there's a bug in the software then it may do strange things if it receives an unusual combination of inputs, either by something crashing or (more subtle) causing an overflow in an intermediate part of the software that produces incorrect output. I think they lost an Ariane rocket to this one once.
Join Date: Feb 2000
Location: Perth, Western Australia
Posts: 16
Likes: 0
Received 0 Likes
on
0 Posts
"Could you precise a little more why/how the aguadalte statement is flawed? "
Speaking as another computer boffin (and one who has been responsible for software where failure could result in loss of life) I read it as stickyb actually agreeing with the main assertion -- as I understand it -- that it is *really* hard for a computer to know when it is incapable of producing the correct outputs for a given set of inputs. aguadalte suggests a "big red button" (BRB), which stickyb claims is not feasable.
I tend to agree with both of them :-)
Where I disagree with stickb is in his assertion that a BRB is not feasible. If the software already has the ability to gracefully degrade the level of automation, then another input that forces it to do so is an increased complexity, but one not nearly as large as the complexity involved in "knowing" all the exceptions that should cause this to happen automatically.
What worries me, however, is whether such a manual override would lead to more or less problems. The obvious example is where some un-commanded pitch up or down is overridden by flying more "manually". However in other cases where a pilot is under extreme stress, or where (s)he becomes situationally unaware, the BRS usage or the actions taken thereafter may be inappropriate and lead to a worse outcome.
From my reading here, some pilots are of the view that they should be given the opportunity to overstress an aircraft if flying within the limits will result in a less desirable outcome. I understand (poorly, probably) that Airbus' attitude is that the automation should help prevent you getting into that place between a rock an a hard place -- which does not directly address the issue.
In my case, the operators of the software were (are) not in personal danger, and the additional cost of dealing with tricky cases was considered unwaranted, so we opted for a system that simply suggested the "correct" action, but left the operator to manually move the controls (in a manner of speaking) and hence with the ultimate authority and ability to override the automatic suggestions. I am in awe of the software which runs aboard modern aircraft, as in many cases other design decisions have been taken (and with great success).
An interesting question from my perspective is "How often do the various protections governing (say) Normal law get triggered in a way that protects the pilot and aircraft from a negative outcome vs how many times have there been incidents where these protections or the erroneous triggering of them has resulted in a negative outcome?" (I ask this because I have no idea)
I've been trying to write this last paragraph for some time. Please excuse me if I express myself poorly. Even if it were shown that pilots were statistically a far worse bet than potentially failing computers, I would hate to be the pilot who may meet his fate *knowing correctly* that all he needed to do was override a computer :-(
Speaking as another computer boffin (and one who has been responsible for software where failure could result in loss of life) I read it as stickyb actually agreeing with the main assertion -- as I understand it -- that it is *really* hard for a computer to know when it is incapable of producing the correct outputs for a given set of inputs. aguadalte suggests a "big red button" (BRB), which stickyb claims is not feasable.
I tend to agree with both of them :-)
Where I disagree with stickb is in his assertion that a BRB is not feasible. If the software already has the ability to gracefully degrade the level of automation, then another input that forces it to do so is an increased complexity, but one not nearly as large as the complexity involved in "knowing" all the exceptions that should cause this to happen automatically.
What worries me, however, is whether such a manual override would lead to more or less problems. The obvious example is where some un-commanded pitch up or down is overridden by flying more "manually". However in other cases where a pilot is under extreme stress, or where (s)he becomes situationally unaware, the BRS usage or the actions taken thereafter may be inappropriate and lead to a worse outcome.
From my reading here, some pilots are of the view that they should be given the opportunity to overstress an aircraft if flying within the limits will result in a less desirable outcome. I understand (poorly, probably) that Airbus' attitude is that the automation should help prevent you getting into that place between a rock an a hard place -- which does not directly address the issue.
In my case, the operators of the software were (are) not in personal danger, and the additional cost of dealing with tricky cases was considered unwaranted, so we opted for a system that simply suggested the "correct" action, but left the operator to manually move the controls (in a manner of speaking) and hence with the ultimate authority and ability to override the automatic suggestions. I am in awe of the software which runs aboard modern aircraft, as in many cases other design decisions have been taken (and with great success).
An interesting question from my perspective is "How often do the various protections governing (say) Normal law get triggered in a way that protects the pilot and aircraft from a negative outcome vs how many times have there been incidents where these protections or the erroneous triggering of them has resulted in a negative outcome?" (I ask this because I have no idea)
I've been trying to write this last paragraph for some time. Please excuse me if I express myself poorly. Even if it were shown that pilots were statistically a far worse bet than potentially failing computers, I would hate to be the pilot who may meet his fate *knowing correctly* that all he needed to do was override a computer :-(
...and what happens, when all the sensors receive the same information (pressure lines frozen with water, leading to wrong - but not abnormal - parameters messages to flight computers?