PDA

View Full Version : A320 GPWS MODE 2 Excess terrain closure rate


timmyEGCC
12th Sep 2013, 01:47
Hi all,

Is anyone able to tell me, how long a duration (eg 2 sec) the "RA rate of change" must remain in the Warning Envelope range for, in order for the aural warnings to sound?

I understand some airlines do suffer nuisance warnings at some otherwise flat enviornment because of small rising hills etc just before the threshold.

Surely it wont sound if the instantaneous RA change at 500' RA is 3000 ft/min for 0.1 second due to a sloping roof of a house located short of the runway...

I just thought if I knew roughly how long that rate must be sustained, I could somewhat anticipate the coming of the warning that's all... May be too inpractical and academic but worth asking what with all the bus experts on pprune :}

Cheers

Ex Douglas Driver
12th Sep 2013, 02:45
From http://www51.honeywell.com/aero/common/documents/Mk_VI_VIII_EGPWS,P-Ns_965-1176-XXX.pdf

6.2.2 Mode 2 -- Excessive Terrain Closure Rate

Differentiating and scaling radio altitude generates closure rate. As the closure rate term is inherently noisy, especially over irregular terrain, extensive rate limiting and filtering must be used to obtain an accurate closure rate value for computation. The computer uses a number of different sets of sophisticated rate limits and filter methods to allow maximum sensitivity during cruise, while providing progressively less sensitivity during the landing phases of flight. These rate limits vary as a function of gear and flap position, aircraft speed, and whether or not the aircraft is on an ILS approach. It is this rate limiting and filtering that determines the effectivity of Mode 2 in providing advance alerts, while avoiding unwanted or nuisance alerts.

Altitude rate is combined with closure rate in the filtering method to provide “lead” information. Increasing the altitude descent rate will tend to speed up the alert occurrence. Reducing the altitude descent rate, or initiating a climb, will tend to delay the alert occurrence, or reduce the time that the alert is on.

So, if following its "extensive rate limiting and filtering", the GPWS algorithm generates a closure rate value in the caution or warning area of the graph, it will instantly provide the appropriate GPWS response.

rudderrudderrat
12th Sep 2013, 07:14
Hi TimmyEGCC,
I could somewhat anticipate the coming of the warning that's all.
Does your company not produce briefings for all your airports?
E.g.
Bilbao.
"RWY 10 requires careful handling to avoid GPWS activation on short finals due to the 372ft asl ridge at 1.25nm finals."

timmyEGCC
17th Sep 2013, 10:38
Thanks all for your input.

rudderrudderrat, yes they do but notices normally come out only after an unexpected event.

underfire
18th Sep 2013, 15:51
With the A320's, there is an unusual issue. For some reason, the system on the older A320 uses a 400' ROC value at the FAF, rather than 500' on the newer systems, (and on the 737).
The older A320's had been flying the procedure with no warnings, but the newer models would have a warning. It is very noticeable when the aircraft are on a coded procedure

How the system handles the 200' ROC at threshold, backing it off to where the ROC surface intercepts ground has differences over time and manufacturer.

Capn Bloggs
18th Sep 2013, 23:41
"RWY 10 requires careful handling to avoid GPWS activation on short finals due to the 372ft asl ridge at 1.25nm finals."

Only out of curiosity and at the risk of thread drift, what do you guys do as far as "special handling" goes to avoid GPWS warnings at Bilbao?

PEI_3721
19th Sep 2013, 01:08
Underfire, the differences you quote are interesting.
Is it possible that aircraft systems have different EGPWS software mod states; or are there a differences in actual equipment / manufactures – EGPWS vs T2CAS(TAWS)?
Another alternative is if the navigation procedures have different (even erroneous) coding?

Re special handing; from my ancient experience these were very rare situations and often only temporary until the EGPWS database had the necessary fix. The other extreme was to inhibit the advanced features at certain locations; obvious not favoured. Thus more permanent fixes were sort, provided the EGPWS manufacture was informed of the problem.
If problems are continually encountered ask the manufacturer to investigate; an EGPWS memory download should provide all necessary information – the storage capacity is very large and includes all alerts and the immediately preceding flight paths.

rudderrudderrat
19th Sep 2013, 08:53
what do you guys do as far as "special handling"
Stay on the glide profile, don't go low with a higher than normal ROD.

Capn Bloggs
19th Sep 2013, 09:04
Thanks Rudder.

underfire
19th Sep 2013, 16:07
PEI,

We did the forensics and the issue was the different ROC values in the system, and the associated difference in the angle of the surface to the 200' ROC, just happened to pick up some terrain. Rather than null, just bumped the procedure over a little
Its always interesting to see how the different manufacturers equipment works and calculates.
It also shows, that even though a 0.3RNP or 0.1 RNP procedure works just fine, some of the systems on the ac just wont play.

PEI_3721
19th Sep 2013, 17:28
Thanks, my interest is if the Honeywell EGPWS modification programs, introduced in the last 7-10 years, now create unforeseen or unforeseeable problems pre RNP.
One of the safety objectives of the modifications was to tighten up the final approach warning profile in order to identify the ‘duck-under’ / land short type of incidents.
Previously did crews subconsciously fly a bit higher on NPA approaches (level at MDA to VDP), whereas RNP (VNAV) now provides a precision glidepath, but perhaps lower than previously flown.

underfire
19th Sep 2013, 20:49
Interesting. RNP is very precise horizontally, but with un-comp baro vnav, there is quite a bit of vertical leeway with temperatures.
While the criteria (FAA) allows the 3 degree GPA to only go to 2.71 GPA, the custom criteria has been driven down to 2.5 GPA. This gets you quite a bit more access with lower temps, but with the understanding that the terrain/obstacles have been surveyed to this level.

In regards to your Honeywell, or for that matter, any of the manufacturers prox systems, there last few years have evolved. By this I mean the electronics capability, data storage and the software.
Unfortunately, I have noted many discontinuities in the transitions. I look at this much the same as any other software, you have to keep bringing the old calculations forward, for compatibility issues. This is very much like being able MSFT Word being able to read a 2001 version document, and convert it to 2013 and then back.
In aviation, this is more based on the expense and time of certification, allowing to add to a cert, rather than get a new one.

more on this later...

PEI_3721
19th Sep 2013, 22:21
Thank you again. Re “the understanding that the terrain/obstacles have been surveyed to this level”. Might that be an assumption too far?

Another aspect might be that human perception of an acceptable flight path over ‘difficult’ terrain during a visual approach might result in a higher glideslope than that allowed by VNAV, thus alerts were not as frequent before VNAV.

Just found a Honeywell briefing which discussed proposed mods – circa 2004/2005. Note the changes below 400ft RA: is this relevant?

http://oi39.tinypic.com/2dam6bc.jpg

underfire
20th Sep 2013, 16:24
Good find! That appears to sum up the issue.

I believe recent changes have gone from 400 foot at 4.5nm to 500 feet at 5nm, but that may be only working with coded procedures, and the mode changes to the sloped TCF when crossing the coded FAF.

For the survey, yes, a very detailed survey database is required, with terrain, canopy, and obstacle additives, culminating with a ground and flight validation.