Airbus Calculation of Final Path Profile

[Friendly Pelican]

Hello everyone,

I have to admit that this hasn't been a big one for me as a 'classically-experienced' driver: the approaches I most usually fly are ILS or overlay VOR/NDB, where raw data are available and authoritative.

By that I mean, particularly for the overlay approaches, the not-below heights derive from primary altimeter and raw data fix. If the target profile has put you low against the raw data, well, you don't continue descent. Cold weather and nav accuracy without GPS spring to mind as possible factors.

But, as my new airline starts to do RNAV/RNP approaches, I need to revisit how the aircraft derives its target profile, to achieve the same sort of interdependent 2D/ALT crosscheck. I'm thinking of the old presentation slide where the FMGC defines its end-of-approach point as a fix and altitude and then projects a 3deg slope backward from that point in space.

What I want to know is whether the FMGC takes current primary altimeter QNH into account when calculating the fix and derived profile, or whether the FMGC looks at QNH set in the APP page. (I have my thoughts, but I'd like them confirmed...)

FCOM states that the APP page QNH is used for repressurisation profile, but seems (to my research, anyways) to be silent as to how it derives the target profile.

You can see how this becomes problematic when the GNSS approaches have no raw data fixes to trap errors in altimeter setting. (I know: they should be trapped by SOPs; but, but, but...)

This is actually the first part of a (possible) two part question. Thanks, in advance.

As an aside, it also makes a very good case for compensated altimeters in any Airbus, as of - I don't know - 30 years ago...

[Friendly Pelican]

Nearly 300 views and no bites. I'm not really sure what to make of that.

Okay: I'll go first. It's primary altimeter QNH - always was, always will be; for any number of reasons, including the failure cases.

Why I asked the question is that my new airline has recently adopted a procedure at transition where the primary altimeters and ISIS are simultaneously set to QNH extracted from the FMGS Perf App page. Bear in mind that we operate exclusively under radar control, and most if not all destinations provide METAR/ATIS by ACARS or Voice. And, we've been given QNH when cleared to first altitude below transition. And, we could always ask if we're not sure.

So, I wanted to confirm my belief that QNH on the Perf App page was like a kiss from your sister - nice, but ultimately useless.

Essentially, my new lot are using the App page as a scratchpad - to which I say, why not use the QNH you've just received or written down as basis for the crosscheck, and cut out all that extra button pushing. That's a good reason, right there.

But the problem is deeper than that: we're now using an input to error-check another input.

I gather this new procedure is in response to a small number of mis-sets under workload; but I really think that the procedure makes things just that little more complex, doesn't trap the error correctly, and has no basis in system design, anyways.

I leave the floor open...

[pineteam]

What I want to know is whether the FMGC takes current primary altimeter QNH into account when calculating the fix and derived profile, or whether the FMGC looks at QNH set in the APP page. (I have my thoughts, but I'd like them confirmed...)

Hello,

No it does not look at the QNH set in the perf page and nor the temperature. That’s why when using Final APP you have a low temperature limitation. It’s critical you set the correct QNH on EFIS as a wrong QNH will put you high or low on profile.
The QNH you insert on the perf page is only used for cabin repressurisation segment.

[KingAir1978]

Agreed with pineteam. With regards to temperature compensation, unless your airline has the optional FMS landing system approach (FLS approach) installed, the approach is not compensated for cold (or hot!) weather. The chart usually specify a minimum temperature for using LNAV/VNAV minima. If the temperature is below that value, you can fly the approach using corrected LNAV minima and an adjusted vertical path, using NAV and FPA to fly it. Hopefully this helps.

[dream747]

I am not well versed with the design criteria of RNP approaches, are there any upper temperature limits? I recall coming across documentation stating there if there’s an upper temperature limit for the approach, it’d be stated but I’ve never seen one.

The region I operate in, OATs are often above 30 degrees celsius, sometimes hitting the 40s. A few RNP approaches flown in FINAL APP it is not uncommon to see 4 whites on the PAPI as we are high (opposite of cold weather). How does one manage this? Imagine doing the approach in inclement weather breaking out of cloud and in rain late at minima only to see 4 whites!

[pineteam]

I’m not aware of high temperature limit.
If you are 4 whites, then just aim for 1000 feet/min ROD which is still acceptable below 1000 feet and you should be back on 2 whites 2 reds in no time. Not a big deal really.

[sonicbum]

dream74

Check Abu Dhabi (OMAA) RNP approaches. Don’t have the charts handy right now but IIRC the temperature limit is +49 or so.

[vilas]

I think FLS is going to be standard equipment soon. FLS does use the temperature inserted in the PERF page and corrects for it.

[Rt Hon Jim Hacker MP]

Next time you go to the sim ask your mate in the back seat to demo a QNH setting error. Set the sim cloud base at 500’ agl. Set the airfield QNH of 1013 but an “error” between ATC and your ears mean the crew set 1003.

A non radar airfield won’t pick up the fact that you are flying around 300’ below any cleared or procedural altitude. Think small Greek islands. The very clever Airbus/Boeing flies a perfect approach exactly as depicted on the plate. Spot on at every fix. RNP AR, GNSS, overlay. Makes no difference. Your range/altitude checks down the approach are all exactly as on the plate. Until you get visual. It’s a real sobering exercise that demonstrates how important the basics are.

[Friendly Pelican]

That was the hidden thrust of my question. In effort to avoid this exact error, my new mob has come up with the idea of inserting QNH in the PERF APP page and using it as some sort of gross error check at transition. That is, not before...

Only, by that stage, it's likely going to be the same (misheard) QNH and won't alert a ship-coherent mis-set, anyway. In other words, if the (erroneous) source is the same, the error won't be trapped. And, at transition, it's too late anyways.

That's why QNH readback at altitude assignment is now a thing: it wasn't when I started a very long time ago - at least, not in my neck of the woods. Whenever you transition to QNH, then the setting needs to be verified by readback, or by reference to latest METAR or ACARS or similar data - but not from what you or Bloggs has inputted in the box.

If readback procedures are failing, then that's a whole safety of air navigation problem - not just an altimeter problem - and it needs to be addressed with requisite vigour, rather than by imposition of SOP 'band-aids'.

Cheers and thanks everyone, so far...

[KingAir1978]

Wow, Friendly Pelican... Like you're saying. There is NO WAY to catch that error at, before or past transition level. Garbage in is garbage out... If you're new to the bus it is worth noting that the FMG(E)C has a model of the standard atmosphere incorporated into it. Hence the 36090' for the tropopause on the init page. That's also why ISA deviation is only showing when the Captain's altimeter is set to STD (A320, A330, A340). When descending the level at which the STD box starts blinking is dependant on the QNH input on the PERF page.

[pineteam]

Rt Hon Jim Hacker MP

Very good point. I never realized that actually. I always preset the destination airport QNH early during the flight to minimize this kind of mistake. At least when approaching the TL and ATC gives us the QNH, I know it will be close to the one I inserted earlier and it’s unlikely to set a wrong QNH of 10hpa. I guess a crosscheck with the RA is the last line of defense assuming the ground is relatively flat below. But just to confirm: If airport QNH is 1013 but the crew set by mistake QNH 1003, they will fly 300 feet too high and not too low.

[TeeS]

Hi Dream747, there isn’t a maximum temperature limit published for Baro-VNAV; however, there should be a temperature published at which the vertical path angle (VPA) will exceed 3.5 degrees.

[Check Airman]

pineteam

What we do (purely as technique) is set the destination QNH before pulling STD as we climb through transition altitude.

[Rt Hon Jim Hacker MP]

pineteam. My apologies, you are absolutely correct. I had it the wrong way around. I have demoed this to crews a number of times. The whole approach looks spot on until they go visual.

[EK380]

For info, FLS is only temperature corrected for COLD and not for Hot.