But are you seriously telling me that when an automated system disconnects in flight, the reason for the disconnect cannot be accurately communicated to the pilots?
Accurately - for sure it can. Briefly, in a relevant and non-cryptic manner - not sure.
I have no experience with automated systems used in flight, and cannot competently answer this question. But in general, complex software tends to be modular, each module doing a rather narrow task, and communicating with others according to a formalized protocol.
As a result, an error happening in a module will be propagated through the system, but the final recipients of the error may be completely unaware of its original cause.
You may get something like "Autopilot disconnect. Reason: error in flight data processing module"... how helpful is that?
Or even worse, a stream of error messages from all internal levels of the system: "Error in flight data processing module: Incorrect airspeed. Autopilot disconnect. Reason: error in flight data processing module"...
From Part 2 of the final report (mainly based on the results of the work of the Human Factors group):
Quote:
2.1.2.3 Control of the flight path
(...) Although the PF’s various roll inputs indicate his intention to keep the wings horizontal, it is not possible to determine what the PF’s target was in the longitudinal axis.
It would also seem unlikely that the PNF could have determined the PF’s flight path stabilisation targets. It is worth noting that the inputs applied to a sidestick by one pilot cannot be observed easily by the other one and that the conditions of a night flight in IMC make it more difficult to monitor aeroplane attitudes (pitch attitude in particular).
The first sentence is a logical consequence of the first quote, but what are they adding in the second?
At the very least, this data would be accurate enough for the flight director to apply power and pitch within known safe ranges for the altitude (e.g. N= 85% and pitch = +5 degrees), keeping the aircraft in normal law rather than just "giving up".
The real underlying issue is the failure of the actual pilots to apply this same fundamental logic. At the end of the day the inability of a "trained" flight crew to keep a perfectly functional airplane from crashing due to a known and relatively minor technical malfunction is simply unacceptable. The answer is not in better automatics but in better truly qualified flight crews.
The answer is not in better automatics but in better truly qualified flight crews.
Surely in true "belt-and-braces" fashion, it would be best for us to strive for both, no?
Paramount for me is getting it into the skulls of airline management that this is not a zero-sum game, and that the advances in automation are not and have never been an excuse to cut corners on crew training.
@Linktrained - the crucial factor with the Air Transat incident is that both pilots were fully aware of their situation and planned their glide path thoroughly. If the Air Transat crew had made the same inputs as the unfortunate Air France crew in 447, the aircraft would have dropped like the proverbial brick.
Flight Directors Off, Bird ON, The bird shows you where the aircraft is actually going....level, climbing or descending, the ac attitude on the PFD shows where the ac is pointing in pitch and roll in relation to the horizon. if the ac is pointing up but going down?
What is the usual range of positions for the THS in normal cruising flight ?
Quick and very oversimplified answer :- It depends on the CofG.
Less simple but still incomplete :-
[ Airbus drivers please feel free to correct this explanation ]
First you need to forget the concept of a stick and trimwheel as seen on light aircraft where the stick can move the elevators from full up to full down and the trim wheel is a fine control used to unload forces fed back to the stick.
In an airliner with a THS there is no separate elevator or trim tab, the entire horizontal stabiliser is moved by jacks. In the Airbus the side stick is effectively a fine control which moves the THS within a limited range. The trim wheel is effectively the coarse control with full authority from full up to full down. If sidestick inputs reach the limit of their effective range the autotrim system system acts, think of this as moving the small window of movement available to the sidestick up and down within the full THS range.
If a pilot holds the sidestick in the full up or full down position the autotrim will obey and drive the THS to its limit. Note that if the pilot now releases the sidestick to its neutral position the sidestick now has a small window of effectiveness at the limit of THS travel.
To get the aircraft back from this extreme situation the pilot must either hold the opposite input for a long time or start winding the trim wheel. Thus in the case of AF447 it would have taken a long time to get the nose back down from where the idiot pilot had driven it.
Flight Directors Off, Bird ON, The bird shows you where the aircraft is actually going....level, climbing or descending, the ac attitude on the PFD shows where the ac is pointing in pitch and roll in relation to the horizon. if the ac is pointing up but going down?
FPV (aka 'the bird') was inhibited in this case due to the presence of untrustworthy data. Search the Tech Log AF447 threads for a more thorough dissection of this topic.
FPV (aka 'the bird') was inhibited in this case due to the presence of untrustworthy data. Search the Tech Log AF447 threads for a more thorough dissection of this topic.
Thx.
But do this "untrustworthy data" happen only on ADIRS equipped aircraft?
Discret systems, ADC plus IRS would not f*** off simultaneously with blocked pitot.
As far as I'm aware it's not a technical limitation of having AD and IR computation in the same unit, so much as a design decision to supply only verified good data to the crew if at all possible.
What we have to bear in mind at all times here is that the situation the aircraft ended up in was completely off the beaten track in terms of the flight envelope - using the FPV to aid recovery from a stall following UAS was probably considered a very improbable edge case when the system was specified.
Remember that one of the AoA vanes in this case was in fact frozen and providing bad data too (and in fact was out of action for longer than the pitot tubes).
The new BUSS system is intended to use other data sources to provide airspeed data, among other things, but it was not fitted to this aircraft.
Last edited by DozyWannabe; 8th Aug 2012 at 19:06.
FPV (aka 'the bird') was inhibited in this case due to the presence of untrustworthy data
- to search is a daunting task. Can you recall where this discussion took place? What would the "untrustworthy data" be in the case of 447? Is there any IAS input into the AB FPV? I guess this is irrelevant since they did not try to select it as far as we know.
But the short summary is that the Honeywell systems used by Airbus and Embraer use baro data to calculate the FPV - if air data is unreliable then FPV is unavailable.
But the short summary is that the Honeywell systems used by Airbus and Embraer use baro data to calculate the FPV - if air data is unreliable then FPV is unavailable.
If this is the case, and I believe you, again it shows how complex airbus systems are designed.
I'm pretty sure, on the 1st generation airbus (A300/310) FPV was solely IRS related...
Cheaper, smaller, etc. that's what counts.... Taking in to acount a very complex system which may, and this is the case right here, fail to give appropriate infos to the pilots.
The FPV is elaborated in the IR part of the ADIRU which, for this purpose, uses inertial parameters and also an anemometric parameter: the barometric vertical speed. It is thus necessary for the IR to have at least one valid ADR at its disposal. From the perspective of the IR, an ADR is valid if the three parameters, altitude, barometric vertical speed and true airspeed are valid
(SSM status is NO) If the three ADRs are considered invalid by the IR it is no longer possible to calculate the FPV and the red FPV flag appears on the PFD.
If this is the case, and I believe you, again it shows how complex airbus systems are designed.
It's not just Airbus though - note NSEU's experiment on the FPV thread I linked earlier (bolding mine):
Quote:
Originally Posted by NSEU
There's an easy way to prove that the FPV does or does not ADC data. Pull the CBs for the ADCs (well, at least this is possible on the Boeings which don't have ADIRUs).
Quote:
Originally Posted by NSEU
On the 747-400 (at least) Baro from the ADCs is fed into the IRUs. The IRU's then mix baro and IRU info and send this as IVSI information to the PFD. This is why the IVSI information disappears when either the ADC or IRS CBs are pulled.
...
If the FPV is removed if I pull the ADC CB's, I will be suitably humbled. I'll also check for the presence of the FPV during ATTitude mode.
Quote:
Originally Posted by NSEU
OK, I'm suitably impressed. I still don't understand it, but the FPVs did disappear when I pulled all the ADC CBs.
As always, the guys who fix the aircraft are the last to know.
So it seems that at least some Boeing FPVs also disappear when air/baro data goes away.
Last edited by DozyWannabe; 8th Aug 2012 at 20:32.
