FCU Altimeter Setting
At my last airline the PF never touched the altitude selector. On AP of course he did everything else. We had AB and Boeings and it was the same. Boeing's procedures are for PF to handle all selections also. We just did it differently. Whether to use 100 or 1000 was up to the pilot.
Just to make an important point:
The FCU altitude readout is the INPUT to the computer. The PFD altitude readouts are what the computer has received. The three should of course always be the same, but if there was a fault somewhere, they might not be.
Therefore, as has been said the only place for Airbus pilots to confirm the selected level/altitude is on their PFDs.
Our SOP's are for PF to make all selections unless they are hand flying, in which case PNF makes selections on request for them. If a new Alt/FL is selected, whoever made the selection calls what they see on their PFD, including the colour of the digits*. The other pilot looks at their own PFD and also calls what they see. The two should of course be the same, but this is an extremely important check to make, because it can catch incorrect selections, computer faults and therefore Alt busts.
*Because on Airbus, constrained intermediate altitudes are coloured magenta, unconstrained ones are Cyan (though we say "blue").
The FCU altitude readout is the INPUT to the computer. The PFD altitude readouts are what the computer has received. The three should of course always be the same, but if there was a fault somewhere, they might not be.
Therefore, as has been said the only place for Airbus pilots to confirm the selected level/altitude is on their PFDs.
Our SOP's are for PF to make all selections unless they are hand flying, in which case PNF makes selections on request for them. If a new Alt/FL is selected, whoever made the selection calls what they see on their PFD, including the colour of the digits*. The other pilot looks at their own PFD and also calls what they see. The two should of course be the same, but this is an extremely important check to make, because it can catch incorrect selections, computer faults and therefore Alt busts.
*Because on Airbus, constrained intermediate altitudes are coloured magenta, unconstrained ones are Cyan (though we say "blue").
FMA Calls
Hello Uplinker,
You make a very good point about the greater integrity of the indications on the PFDs.
Your fleet's SOP for FCU selections sounds similar to our A320 fleet's, although things may have changed in the 12 years since I retired (after doing the first 14).
The main difference was/is that the pilot who made the selection did NOT make the FMA call - the non-selecting pilot did it, unprompted. The logic for this is threefold, and designed to address human fallibility in high (and even very low) workload situations:
(1) the pilot making the selection may "see" and call what (s)he thinks (s)he has selected, or even call before fully completing the selection;
(2) to force the other pilot to pay full attention to monitoring the mode change, rather than (perhaps) merely parroting what the selecting pilot has called;
(3) to halve the number and duration of calls.
Re (2): occasionally the non-selector will miss a mode-change and/or fail to call; due to other tasks or distractions, or ATC calls. The selecting pilot is then tempted to make the call, but I advised people where practicable to choose a suitable moment and ask something like: "Check your FMAs?"
Including all mode changes involving manipulation of the ALT knob, our FMA calls were strictly limited to those that are safety-critical. When we started A320 ops in 1988, several of us, including the chief training captain, had previously been on the BCAL A310, which has an AFS nearly as complex as the A320. On that fleet, we had called every mode change, but it was realised that to do so on the A320 - with considerably more of them - would be counter-productive.
You make a very good point about the greater integrity of the indications on the PFDs.
Your fleet's SOP for FCU selections sounds similar to our A320 fleet's, although things may have changed in the 12 years since I retired (after doing the first 14).
The main difference was/is that the pilot who made the selection did NOT make the FMA call - the non-selecting pilot did it, unprompted. The logic for this is threefold, and designed to address human fallibility in high (and even very low) workload situations:
(1) the pilot making the selection may "see" and call what (s)he thinks (s)he has selected, or even call before fully completing the selection;
(2) to force the other pilot to pay full attention to monitoring the mode change, rather than (perhaps) merely parroting what the selecting pilot has called;
(3) to halve the number and duration of calls.
Re (2): occasionally the non-selector will miss a mode-change and/or fail to call; due to other tasks or distractions, or ATC calls. The selecting pilot is then tempted to make the call, but I advised people where practicable to choose a suitable moment and ask something like: "Check your FMAs?"
Including all mode changes involving manipulation of the ALT knob, our FMA calls were strictly limited to those that are safety-critical. When we started A320 ops in 1988, several of us, including the chief training captain, had previously been on the BCAL A310, which has an AFS nearly as complex as the A320. On that fleet, we had called every mode change, but it was realised that to do so on the A320 - with considerably more of them - would be counter-productive.
Chris, many thanks for the thoughtful explanation.
This is much as I had imagined, although the operational description highlights the biases of my dated experience. With the (then) relatively new 2 crew flightdeck, including early EFIS, AFCS, and FMS, the systems did not have such an extensive suit of controls and displays.
Subsequently, although the number of controls has been limited (occasionally and hazardously dual purpose) the automated systems capability has undergone significant expansion enabling a range of operations which require greater clarity in depiction / annunciation. This has led to complexity, which generally has been managed with training and procedure.
My concern is twofold:
First; that reliance on training and procedure to manage increasing complexity is approaching a limit – particularly in combination with situational/task workload and organisational/systemic demand, e.g. complex GA procedures, path and communication demands with extensive dependence on cross monitoring – see BEA AGASA study.
Second; that extending or changing the methods of managing with procedures (however well intended) might encounter situations which have not have been considered, neither during design or procedure change. These may generate some surprising incidents, often cited by modern SMS views as emergent hazards, as they are a property of the total system in which we operate (Man, Machine, and Environment).
Thus although a procedure has been well considered for ‘normal’ operation, the demands on human performance, due to the developing and complex operational environment, and interwoven safety responsibilities (regulator, operator, airport, ATM), can change the ‘normal’ to that requiring exceptional human capability (again see BEA AGASA study).
Thanks again.
This is much as I had imagined, although the operational description highlights the biases of my dated experience. With the (then) relatively new 2 crew flightdeck, including early EFIS, AFCS, and FMS, the systems did not have such an extensive suit of controls and displays.
Subsequently, although the number of controls has been limited (occasionally and hazardously dual purpose) the automated systems capability has undergone significant expansion enabling a range of operations which require greater clarity in depiction / annunciation. This has led to complexity, which generally has been managed with training and procedure.
My concern is twofold:
First; that reliance on training and procedure to manage increasing complexity is approaching a limit – particularly in combination with situational/task workload and organisational/systemic demand, e.g. complex GA procedures, path and communication demands with extensive dependence on cross monitoring – see BEA AGASA study.
Second; that extending or changing the methods of managing with procedures (however well intended) might encounter situations which have not have been considered, neither during design or procedure change. These may generate some surprising incidents, often cited by modern SMS views as emergent hazards, as they are a property of the total system in which we operate (Man, Machine, and Environment).
Thus although a procedure has been well considered for ‘normal’ operation, the demands on human performance, due to the developing and complex operational environment, and interwoven safety responsibilities (regulator, operator, airport, ATM), can change the ‘normal’ to that requiring exceptional human capability (again see BEA AGASA study).
Thanks again.
After that explanation from Chris, It's Boeing for me. PF does it all, the PM checks it all. Surely the operation isn't so bad/incompetent that the PM has to call the result of a selection by the PF? Surely the PF isn't going to call something incorrectly from the FMA, followed by the PM also not checking that what has just been said is actually correct?
As for:
The obvious solution is that, if the PF doesn't get the answer he needs from the PM eg "Track 270 selected", then he simply repeats the original statement and waits for the PM to respond correctly. "Check your FMAs?" What for? The PM obviously missed your first call so now he has to play the mind game trying to work out what has changed on his FMA?
Aviate, Navigate, Communicate comes to mind...
That's getting a bit paranoid, isn't it, creating an SOP just in case the hard-wiring might be faulty? I fully agree with the PM checking (calling what he actually sees if you insist) what he sees on his PFD but using a possible system fault as a reason for a SOP is going a bit over the top IMO.
As for:
occasionally the non-selector will miss a mode-change and/or fail to call; due to other tasks or distractions, or ATC calls. The selecting pilot is then tempted to make the call, but I advised people where practicable to choose a suitable moment and ask something like: "Check your FMAs?"
Aviate, Navigate, Communicate comes to mind...
Originally Posted by Uplinker
The three should of course always be the same, but if there was a fault somewhere, they might not be.
...The two should of course be the same, but this is an extremely important check to make, because it can catch incorrect selections, computer faults...
...The two should of course be the same, but this is an extremely important check to make, because it can catch incorrect selections, computer faults...
Last edited by Capn Bloggs; 10th Feb 2014 at 23:52. Reason: Added comment re Uplinker's post
Join Date: Mar 2006
Location: USA
Posts: 2,527
Likes: 0
Received 0 Likes
on
0 Posts
PF handles FCU unless he is flying manually or in some extra ordinary case. If your company wants PM to handle FCU even on AP then your company procedure is against the principle of Airbus flying. Since you are not AB pilot you may have misunderstood.
1. Altitude busts are always a hot topic here. The PM is kept in the loop. This is particularly true with level changes at the pilot's discretion, where the PF may opt to level off at an intermediate altitude.
2. Consider a clearance I was given last week "you're 6 from the marker, fly heading 120, maintain 3000 until established, cleared ILS runway 9. 170 or better to the marker."
As I'm making mode selections for speed and lateral path, the PM is taking care of the altitude. One less thing for the PF to do. Not much extraneous talking either. The only required callout in this case would be "3000" by both pilots. As a technique, one pilot may state "cleared for the approach", but that's about it.
If instructions from ATC are so complex (5 instructions in this case) they require both crew members to "do their own thing" and then have a conference after it's all set to confirm that what they just did individually is actually what is required, there is something wrong.
What's wrong with write it all down, then execute in a methodical, controlled way with ordered setting and cross-checking by the crew, together?
What's wrong with write it all down, then execute in a methodical, controlled way with ordered setting and cross-checking by the crew, together?
Join Date: Feb 2005
Location: Tracy Island
Posts: 114
Likes: 0
Received 0 Likes
on
0 Posts
It's a UK / USA thing. I have both licences and if I fly with an American pilot our hands will often meet at the Alt selector as a lifetime of SOP is hard to break.
Same as V bars and cross pointer flight directors.......just different but the same job is being achieved.
Same as V bars and cross pointer flight directors.......just different but the same job is being achieved.
Hi Chris, that is an interesting thought, and I see where you are coming from. I've just double checked our SOP's and it says that all boxed or Alt changes are called by PF and confirmed by PNF.
Capn Bloggs, you might characterise it as 'paranoid' but I wouldn't. It probably came in when Airbus were new and not fully 'trusted', if I can put it that way - however, I personally think it is a very sensible check. Too many people don't understand this input/output distinction with computers, and you do still see pilots looking only at the FCU alt readout. Remember garbage in - garbage out? Now that computers are in the loop as opposed to just 'switches and wires', things may not be what you expect. I have never seen it go wrong in an Airbus, but if a wiring fault or a computer fault occurred one day which dropped a digit and the computer saw your selected 17,000 feet as 7,000 feet or 1,700 feet, you might be in trouble - and well on the way to an alt bust if you hadn't checked and noticed the discrepancy.
Capn Bloggs, you might characterise it as 'paranoid' but I wouldn't. It probably came in when Airbus were new and not fully 'trusted', if I can put it that way - however, I personally think it is a very sensible check. Too many people don't understand this input/output distinction with computers, and you do still see pilots looking only at the FCU alt readout. Remember garbage in - garbage out? Now that computers are in the loop as opposed to just 'switches and wires', things may not be what you expect. I have never seen it go wrong in an Airbus, but if a wiring fault or a computer fault occurred one day which dropped a digit and the computer saw your selected 17,000 feet as 7,000 feet or 1,700 feet, you might be in trouble - and well on the way to an alt bust if you hadn't checked and noticed the discrepancy.
Last edited by Uplinker; 11th Feb 2014 at 09:11.
Hello Capn Bloggs,
It probably looks complex because I tried to cover all the scenarios. Re Boeing, there's nothing in the system I describe that cannot be applied in any 2-pilot EFIS cockpit with an FCU, provided it also has a full suite of FMAs and selected parameters displayed on the PFDs. (Wouldn't work on a B757/767, for example.) I'll try and answer your points one at a time. I see that most of them seem to relate to operation with AP, where the PF makes his/her own selections?
"Surely the PF isn't going to call something incorrectly from the FMA..."
Wanna bet?
"...followed by the PM also not checking that what has just been said is actually correct?"
If you are constantly spoonfeeding him, he might do just that - through sheer boredom, or even the assumption that the boss (or hit-shot youngster) always knows what's best and gets it right. To pay full attention to cross-monitoring, he or she needs to be motivated. Puttting the onus on him/her to read his FMAs unprompted gets him back into the loop. Some call it CRM.
"The obvious solution is that, if the PF doesn't get the answer he needs from the PM eg "Track 270 selected", then he simply repeats the original statement and waits for the PM to respond correctly."
What "original statement"? I infer your scenario is that the PF has made a selection, and has already announced the FMA change. In "my" system, the PF would never have made that "statement". It's the responsibility of the PM (the non-selector) to make the FMA call, to avoid being suckered into the same mistake already made by the PF. The pilot who has made the bad selection is likely to call what he thought he had set. He and the PM are more likely to notice the error if the PM reads his PFD and makes the call unprompted. And what's the point of BOTH pilots making the call? Just adds to the noise.
"...'Check your FMAs?' What for? The PM obviously missed your first call so now he has to play the mind game trying to work out what has changed on his FMA?"
No, he simply has to read his pitch-control FMA, plus the selected altitude. We did not call A/THR or roll-control FMAs; except on take-off, go-around and localiser intercept.
"It's Boeing for me. PF does it all, the PM checks it all."
Surely that only applies when the PF is using an AP? I presume that, also on your a/c, when the PF is handflying with FD, the PM becomes the selector, and normally has to wait for the PF to call for what (s)he wants?
In "my" system, the PF calls for what he wants, monitors the PM's selections, and then calls the result. The PM says nothing, unless he requires clarification.
"Aviate, Navigate, Communicate comes to mind..."
Precisely. Keep verbage to a minimum. Avoid duplication, or mere rhetoric. Ensure that all commands, responses, and standard calls are as concise, unambiguous, and effective as possible.
It probably looks complex because I tried to cover all the scenarios. Re Boeing, there's nothing in the system I describe that cannot be applied in any 2-pilot EFIS cockpit with an FCU, provided it also has a full suite of FMAs and selected parameters displayed on the PFDs. (Wouldn't work on a B757/767, for example.) I'll try and answer your points one at a time. I see that most of them seem to relate to operation with AP, where the PF makes his/her own selections?
"Surely the PF isn't going to call something incorrectly from the FMA..."
Wanna bet?
"...followed by the PM also not checking that what has just been said is actually correct?"
If you are constantly spoonfeeding him, he might do just that - through sheer boredom, or even the assumption that the boss (or hit-shot youngster) always knows what's best and gets it right. To pay full attention to cross-monitoring, he or she needs to be motivated. Puttting the onus on him/her to read his FMAs unprompted gets him back into the loop. Some call it CRM.
"The obvious solution is that, if the PF doesn't get the answer he needs from the PM eg "Track 270 selected", then he simply repeats the original statement and waits for the PM to respond correctly."
What "original statement"? I infer your scenario is that the PF has made a selection, and has already announced the FMA change. In "my" system, the PF would never have made that "statement". It's the responsibility of the PM (the non-selector) to make the FMA call, to avoid being suckered into the same mistake already made by the PF. The pilot who has made the bad selection is likely to call what he thought he had set. He and the PM are more likely to notice the error if the PM reads his PFD and makes the call unprompted. And what's the point of BOTH pilots making the call? Just adds to the noise.
"...'Check your FMAs?' What for? The PM obviously missed your first call so now he has to play the mind game trying to work out what has changed on his FMA?"
No, he simply has to read his pitch-control FMA, plus the selected altitude. We did not call A/THR or roll-control FMAs; except on take-off, go-around and localiser intercept.
"It's Boeing for me. PF does it all, the PM checks it all."
Surely that only applies when the PF is using an AP? I presume that, also on your a/c, when the PF is handflying with FD, the PM becomes the selector, and normally has to wait for the PF to call for what (s)he wants?
In "my" system, the PF calls for what he wants, monitors the PM's selections, and then calls the result. The PM says nothing, unless he requires clarification.
"Aviate, Navigate, Communicate comes to mind..."
Precisely. Keep verbage to a minimum. Avoid duplication, or mere rhetoric. Ensure that all commands, responses, and standard calls are as concise, unambiguous, and effective as possible.
Last edited by Chris Scott; 11th Feb 2014 at 15:39.
Thread Starter
Thanks for all the considered replies. Ultimately, it doesnt matter how you twiddle the ALT selector, the FMA is there to confirm its been set as you want. It seems that our Co have just made the process that much more fiddly under the flag of "safety", when there is no such justification. KISS... Onwards and upwards!
