PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Tech Log (https://www.pprune.org/tech-log-15/)
-   -   CFIT Risk 3D BARO-VNAV & 2D Approaches (https://www.pprune.org/tech-log/653019-cfit-risk-3d-baro-vnav-2d-approaches.html)

SAM 2M 1st Jun 2023 09:04

CFIT Risk 3D BARO-VNAV & 2D Approaches
 
1 Attachment(s)
The UK CAA has promulgated Safety Notice 2023-003 on this subject.

The Safety Notice is accompanied by a short Video

and a CAA Safety Files Podcast https://podcasts.apple.com/gb/podcas...=1000615112984

As with so many things the first step is to understand WHY this Threat Exists, WHEN it can occur and HOW to trap/prevent it.

As well as making sure the QNH is correct, monitoring the Radio Altimeter (especially in the last few miles of the Approach) is a key component.

Proactive and informed Threat and Error Management (TEM) is vital to this case and the management of Flight Operations hazards and threats in general.

NUTA

N - Notice
U - Understand
T - Think
A - Ahead

Another point to be mindful of is that SOME aircraft are configured such that the ‘ONE THOUSAND’ and ‘FIVE HUNDRED’ Mode 6 audio calls are not RAD ALT DRIVEN, but are merely a calculation of the Height above the Runway based on the BARO Setting and known Runway Elevation. Just make sure you know how your a/c is configured in this respect. A comforting ‘ONE THOUSAND’ or ‘FIVE HUNDRED’ may not mean what you think it does!

For this reason, it is important that - inter alia - Flight Crew know what data source(s) ‘drive’ the various Audio Call-outs on approach and also what effect being in a Landing Configuration has on the protections offered by the TAWS.

MechEngr 1st Jun 2023 12:33

I suggested before that the QNH/runway barometric pressure be hashed by an aircraft computer for read back to the tower, preferably to an alphabetic code. This would require two separate values to be said and agreed upon to avoid errors due to swapped digits or misunderstood duplicated digits - 1023 vs 1032 and 1022 vs 1012. Getting the original value and the hash to have matching errors are infinitesimal and, with a properly designed hash, the hash could have only increasing values and never duplicate values.

1023 readback might be AD and 1032 might be AG,

It is important that the hash is not originally told by the tower to the plane; the tower sends pressure, the crew enters pressure, the computer generates hash, the crew respond to the tower with the hash, the tower reads back the hash and compares it to the hash they have. The goal is to prevent confirmation bias in parroting back what the crew thinks they hear and the tower hearing what they originally said.

Field In Sight 1st Jun 2023 21:34

I don't know why we don't crosscheck the indicated altitude with the GPS altitude for non-ILS approaches.

It would guard against large incorrect pressure settings (which I have done before).

This wasn't mentioned as a mitigation in the CAA video, which was actually quite good I thought.

deltahotel 1st Jun 2023 22:26

A lot of ac don’t have GPS altitude. Ours don’t, but when the Radalt comes live at 2500’ we do a Qnh cross check along with a ‘does that make sense with the BARO alt’ check.

k.swiss 2nd Jun 2023 00:25


Originally Posted by Field In Sight (Post 11444421)
I don't know why we don't crosscheck the indicated altitude with the GPS altitude for non-ILS approaches.

It would guard against large incorrect pressure settings (which I have done before).

This wasn't mentioned as a mitigation in the CAA video, which was actually quite good I thought.


Originally Posted by deltahotel (Post 11444434)
A lot of ac don’t have GPS altitude. Ours don’t, but when the Radalt comes live at 2500’ we do a Qnh cross check along with a ‘does that make sense with the BARO alt’ check.


The GPS altitude can be wildly inaccurate at times, errors of 300FT-500FT, check it out next time if your AC has it.

One thing I am confused by, the good captain explains that even if incorrect QNH is set, the height/distance reading still comes across as correct. Surely it would appear incorrect if the wrong QNH was set, hence this is our first line of defense?

AerocatS2A 2nd Jun 2023 03:35

The height/distance reading appears to be correct. When you do a height/distance check on an NPA you are just checking that the barometric altitude indication is correct for the distance. It cannot check that the altitude indication itself is correct because you’re not using an additional independent source for the height check. A height/distance check works on an ILS because the ILS GP is an independent source of height. For an NPA it works as a check against human error flying the approach itself but does not detect underlying problems with the data used.

Capn Bloggs 2nd Jun 2023 06:20


Originally Posted by k.swiss
One thing I am confused by, the good captain explains that even if incorrect QNH is set, the height/distance reading still comes across as correct. Surely it would appear incorrect if the wrong QNH was set, hence this is our first line of defense?

In this case, the "glidepath" is determined by the box using the set QNH, so all will appear well. The only time an altitude check will really be correct is when you check your altitude while following an externally-generated glidepath such as an ILS or GLS.

I understand that is one advantage of RNAV LPVs (Localiser Precision with Vertical guidance) using a SBAS or WAAS: a vertical profile is generated by the GPS, based on the satellites only and is therefore immune to QNH mis-setting errors, as occurs with an ILS glideslope. As per an ILS, if you mis-set the QNH, you will be closer or further away from the runway when you reach the DA, but at least you will still be on the GPS-derived GP. The worst that can happen is you'll hit the 300m markers. And, of course, if you do an altitude check somewhere on the glidepath, the error will be obvious.

Luc Lion 2nd Jun 2023 11:20

It may be a stupid question, but in what way is an altimeter setting error in a non-LPV RPN approach different from an altimeter setting error in a VOR or NDB approach ?

I probably have a less sophisticated GPS equipment in my small aircraft than a liner's equipment but I don't have any glide slope indication during non-LPV RPN approaches and I have to guard my descent with "gates" as for old fashioned non precision approaches.
Of course, the security brought by these gates is only real if the QNH setting is correct.

22 years ago my instructor trained me to ask, before reaching the FAF on a non precision approach, "LX-xxx, please confirm QNH 1012?" and to systematically set the radio-altimeter alarm to decision height.

k.swiss 2nd Jun 2023 14:22


Originally Posted by AerocatS2A (Post 11444493)
The height/distance reading appears to be correct. When you do a height/distance check on an NPA you are just checking that the barometric altitude indication is correct for the distance. It cannot check that the altitude indication itself is correct because you’re not using an additional independent source for the height check. A height/distance check works on an ILS because the ILS GP is an independent source of height. For an NPA it works as a check against human error flying the approach itself but does not detect underlying problems with the data used.


Originally Posted by Capn Bloggs (Post 11444527)
In this case, the "glidepath" is determined by the box using the set QNH, so all will appear well. The only time an altitude check will really be correct is when you check your altitude while following an externally-generated glidepath such as an ILS or GLS.

I understand that is one advantage of RNAV LPVs (Localiser Precision with Vertical guidance) using a SBAS or WAAS: a vertical profile is generated by the GPS, based on the satellites only and is therefore immune to QNH mis-setting errors, as occurs with an ILS glideslope. As per an ILS, if you mis-set the QNH, you will be closer or further away from the runway when you reach the DA, but at least you will still be on the GPS-derived GP. The worst that can happen is you'll hit the 300m markers. And, of course, if you do an altitude check somewhere on the glidepath, the error will be obvious.

Cheers a little better understood now!

TeeS 2nd Jun 2023 21:02

I'm not entirely convinced that the use of either radio altimeter or GPS altitude is going to be the total answer to the problem.

If we are talking about an RNP LNAV approach and decide to publish a radio altimeter height to be expected at the FAF then we would have to be confident that the terrain variation within a rectangle 0.6 NM wide and 0.48NM along track wouldn't change that value by a significant amount.
With reference to using GPS elevation, the FMS system that I am most used to (Garmin 750) calculates Geometric Height as an approximation to mean sea level. The Geometric Height is based on the WGS84 geoid EGM96 which is a global geoid model giving a 'best fit' for the whole globe rather than a more accurate 'local geoid' model. As an example my old hunting ground of Gloucestershire Airport publish a 'geoid undulation' (variation from EGM96) of 161ft in the AIP. Would that difference in your GPS elevation be enough to give you confidence in the barometric altitude indication?

Cheers
TeeS

AerocatS2A 2nd Jun 2023 22:58


Originally Posted by Luc Lion (Post 11444679)
It may be a stupid question, but in what way is an altimeter setting error in a non-LPV RPN approach different from an altimeter setting error in a VOR or NDB approach ?

There's no difference.




22 years ago my instructor trained me to ask, before reaching the FAF on a non precision approach, "LX-xxx, please confirm QNH 1012?" and to systematically set the radio-altimeter alarm to decision height.
We do the same but we don't say the QNH we would just say "Confirm QNH". The idea being that we want ATC to tell us the QNH without being primed by whatever we've just said to them.

None of this helps if you have a French controller giving a QNH of 1011 in English to English speaking pilots and 1001 in French to French speaking pilots.

rudestuff 3rd Jun 2023 04:03


Originally Posted by Luc Lion (Post 11444679)
I probably have a less sophisticated GPS equipment in my small aircraft than a liner's equipment...

If only you knew 🤣

Luc Lion 5th Jun 2023 11:16

Thanks AerocatS2A.

I reread the BEA report about the Airhub Airlines 9H-EMU incident.
I wanted to know if, in all cases, the control was spelling all 4 digits separately.
In my opinion, the language should not make any difference when spelling the digits separately.
Unfortunately, the report was not specific about this point.

Another puzzling point (for me) is that the approach was not flown as an LPV-RNP approach.
I checked the charts for LFPG and, of course, an LPV approach is available for runway 27R.
I then noticed that the chapter 2.3 of the report states that "the aircraft was not equipped to perform RNP (LPV) approaches,"
How is it possible?
Is that because this A320 plane is older than the EGNOS start of operation on October 1st 2009?
Has there been no mandatory update of the GPS receivers for CAT operation in the 13 years that EGNOS has been active and in the 20 years of WAAS?

Fursty Ferret 5th Jun 2023 11:35

A very quick fix would be to publish a radio altimeter check height on the chart.

Eg, when you go through 5D instead of referencing a largely useless baro indication you're shown what your rad-alt should be indicating. If it's wildly different, you know you've got a problem and go around.

Having said that Airbus already have a software solution. Nothing that GPWS manufacturers couldn't install either. I'm assuming that Boeing will continue to bury their heads in the sand when it comes to safety-related software improvements.

alphacentauri 5th Jun 2023 20:55

Lu Lion,

To my knowledge, much of the modern commercial airliner fleet are not WAAS/SBAS capable. At least that has been my experience in Australia/Asia regions. This is slowly changing with A350/B787 but its still not standard equipment, you have to ask and pay for it when you order.

Alpha

AerocatS2A 5th Jun 2023 21:57


Originally Posted by Luc Lion (Post 11446098)
Thanks AerocatS2A.


Another puzzling point (for me) is that the approach was not flown as an LPV-RNP approach.
I checked the charts for LFPG and, of course, an LPV approach is available for runway 27R.
I then noticed that the chapter 2.3 of the report states that "the aircraft was not equipped to perform RNP (LPV) approaches,"
How is it possible?
Is that because this A320 plane is older than the EGNOS start of operation on October 1st 2009?
Has there been no mandatory update of the GPS receivers for CAT operation in the 13 years that EGNOS has been active and in the 20 years of WAAS?

Agree with alphacentauri , though I'm in the same geographical area so might have the same location bias. My employer's A320 fleet has LPV capability (GLS) on some aircraft but not all. As said above it is an option.

Escape Path 8th Jun 2023 04:20


Originally Posted by Luc Lion (Post 11446098)
Thanks AerocatS2A.
Has there been no mandatory update of the GPS receivers for CAT operation in the 13 years that EGNOS has been active and in the 20 years of WAAS?

Not in my area of operation (CAR-SAM). Mind you, I've been flying the A320 for 7 years now and I'm yet to see an A320 equipped with WAAS in the two different companies I've flown for in that period of time.

Hence the "if you only knew..." remark some posts above. I'd reckon a high percentage of modern GA aircraft are better equipped than most airliners, other than the most recent ones

Luc Lion 8th Jun 2023 11:23

Thank you all.
I see an issue though, in the fact that many medium size airport operators view RPN approaches as a convenient replacement to costly ILS equipment.
Their main argument is that LPV-RPN gives same precision and minima than ILS CAT I.

pineteam 8th Jun 2023 16:35

This serious incident is referred as a « QNH blunder error » and one way to avoid being in that situation is to always preselect your destination QNH and when tower gives you the QNH, pilots should also crosscheck with the last ATIS.
Mentour Pilot did a very good video about this incident —>
Airbus also released an article on this case in their Airbus safety First #35.

rudestuff 9th Jun 2023 04:39

Setting the wrong QNH, being given the wrong QNH or not setting QNH at all will always be a threat, especially to NPA but even to a precision approach. Even with a glide slope you could have a decision height below the runway elevation, which would only leave the radalt, assuming you have one, to save you from a surprise no-flare landing.
With nothing to cross check against, perhaps the easiest solution is for the pilot to read the QNH with the landing clearance if not visual, giving the tower controller a final chance to catch an error.


All times are GMT. The time now is 21:57.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.