GNSS NPA's are dangerous
 

As a pilot who regularly uses GPS NPA's in a two-crew RPT aircraft,
I am not alone in finding the chart presentation confusing, difficult to read and easy to misinterpret.
I am not alone in suggesting that these charts and the approach design had crucial significance at Lockhart River, the information to support this lost on the CVR.
I have only asked other pilots about what they think. I haven't asked ATSB or CASA.

I think they need redesigning. Most importantly, the distance to several waypoints must be changed so that the distance to go is related to the last missed approach waypoint only.

This needs to fixed now before it causes another accident.:uhoh:

duplicate post

Could not agree more about changing the Distance reference.

This has been discussed here several times.

The certification criteria on which GPS NPA approaches are based alledgedly requires the Foxtrot waypoint.

All that means of course is the original designer had no idea what he was doing.

The Foxtrot waypoint is dangerous...the GPS NPA is essentially the only approach where the final descent profile, in its entirety, is not based on a distance to a MAP.

It is a sick joke...I would bet folding money this is a significant contributing factor in a least one fatal crash I am aware of....there will be more.

If the certification basis for GPS NPA 'requires' this idiocy then CHANGE THE CRITERIA:ugh:

Gentlemen,

My vague recollection is that the original AsA chart layout did display "Distance to MAP", but this was LESS intuitive because most modern GPS/FMS displays only present "Distance to Next Waypoint" in the primary field of view. Dist to MAP (or any other selected W/P) may be presented in another area of the CDU, if required.

I fall into the same Cat. of Operation you mentioned above. I'd suggest that the Lockhart River accident, as sad as it was, resulted from more than just procedure design.

If there isn’t something wrong with the way GPS NPA approaches in Australia are designed then can someone please tell me why there is a ban at my airline (and I assume others) doing such an approach in Airbus aircraft (not sure about Boeing) using “Managed” vertical guidance. This ban is world wide but the problem lies in the design of the approaches in Australia. I have seen one demonstrated in the sim for BNE rwy 19 and the bl**dy thing tries to land you several miles short in the water. I believe there are many other airports in Australia with the same problem. So far no other airports anywhere else in the world have been identified with this same problem.

There are some FMC coding issues with one major Australian airport approach for the 777 but other than that we have no restrictions ie the FMS flies the approach fine and safely. Have flown a lot of the Aust ones in the 73 ans no problems there either.

I agree Foxtrot is a crock. OzExPat blames the manufacturers for not wanting to/not able to remove Foxtrot because of scaling issues but I simply don't understand that.

Now that these approaches have allegedly killed more people than an NDB or VOR for years, it's about time CASA changed the design standard in the light of better technology.

If I understand it, CASA was the world leader in GPS NPA design and the concept is great. However, the waypoint at 5nm was a mistake IMO and that should be designed out post-haste.

read "stuffups by Honeywell/Jeppesen". I wonder when they will ever get their act together. Considering millions of people the world over are putting their lives in the hands of their product every day, it's a wonder they can't do a better job (or the regulator doesn't jump on them).

Capn Bloggs

I have been lead to believe the coding issues are a direct result of the design of GPS NPA approaches in Australia compared to the rest of the world. While no one is 100% sure, hence the world wide ban, all indications are something isn’t right with how Australia designs its GPA NPA approaches and it needs to be looked at.

I agree with you on the stuffups by Honeywell/Jeppesen by the way.

Does the navigation data have product approval in accordance with ED76/DO200A ?

Would explain a lot if it does not, been problems with data that is not as the FMGC assumes the MAPt is 50ft over threshold stuffing up the whole computed vertical profile.

In any case, before flying the in FINAL APP the operator has to validate the approach in the database.

swh

say again in English. :confused:

The notice to crew at our company advising of this problem states the auto pilot will fly the aircraft below the profile and it thinks the thresh hold is well before the real one. Again from my understanding there isn’t any way of really telling if the aircraft is going to stuff up the profile in “Managed” vertical guidance by simply checking what is in the MCDU. It’s a case of eliminating them one by one in the sim which I believe has been done for Auckland when the runway works are in progress.

This thread is also running in D & G.

Anybody???

Copied only to Tech Log for input from there!

This thread remains active. :ok:

Our SOP's require pilot validation of the approach in the FMC, which means:
Approach must be line selectable, No Vertical or Lateral mod of points beyond the FAF (speed constraints OK), Final course and distance tolerances within 1 deg/1nm, No min x-ing alt infringed, App Angle >= charted angle, Alt at RWY/MAPt appropriate, RNP 0.3 or better, and when avail AP/FD coupled.
All this is done as part of the brief and easily checked in about 30 secs in the FMC. Have flown many GNSS/RNAV approaches and never had a problem.
Interesting to note that from previous comments some of this is not possible on Airbus - or have I misinterpreted.

.. probably more appropriate in D&G .. perhaps it can be joined with the other ?

JT I beg to differ; the subject deserves a wide audience as it poses significant threats which all pilots should be aware of.
The Australian theme probably stems from
Perceived Pilot Workload and Perceived Safety of RNAV (GNSS) Approaches.

My experience and informal investigations indicate that GPS approaches have been over-sold as an answer to the hazards of NPAs. In general GPS/VNAV approaches are much safer, but to the unwary there are several pitfalls.
The most significant issue is that most (all) vertical profiles depend on QNH, and thus a simple mis-setting or crew error in crosschecking can lead to a hazardous situation. Several EGPWS incidents involving large commercial aircraft were reported in a recent FSF presentation; although none were proven to be due to GPS/VNAV, the circumstances and nature of the errors would apply equally to GPS approaches.

I comment on an interesting incident involving QNH (not GPS) here, what if the MD 11 was IMC and it was using VNAV?

alf ... JT concurs .. following liaison with me (simultaneously with your sage advice), we have merged the threads here ... and put a sticky in Tech Log to direct attention to the active thread .. if no other benefit accrues, at least the commentary will be in the one place for convenience.

SE Woomera

GPS NPAs had so much promise so it is a great shame they have turned out this way. But, all is not lost - the deficiencies can be rectified.

I am a professional pilot (not GPS NPA endorsed) and also a software developer. Back in 1992, I had to write a GPS based navigation system for a survey company. The survey "runs" consisted of up to a dozen waypoints that were roughly aligned.

Before the software even flew, it was obvious to all of us that the crew, once established on the run, were not interested in the intermediate waypoints - they only wanted to know the distance to the final waypoint.

So, I altered the software to the effect that the intermediate waypoints were effectively hidden. And, if the track from one segment to another changed too much (requiring a significant turn), extra waypoints could be inserted on either side of the transition so as to "smooth out" the change from segment to segment.

The crew had only an across-track display and a distance to run (to the final waypoint of the run). If we had wanted to, we could have easily added turn guidance info for those moments when transitioning from one segment to another.

All very easy. The end result, for the pilot, was one apparent segment that would occasionally change track slightly. We could have flown perfect figure 8's if we had wanted - all as one apparent segment.

So, don't let anyone tell you that the GPS NPAs we have today must work the way they do.

If I had designed them, the pilot would see only 2 waypoints - the IAF and the MAP. Upon activating the approach, the GPS would guide him to the IAF. After passing the IAF, the guidance would then be to the MAP, via several (invisible) intermediate points, with the displayed distance being the track miles to the MAP. The FAF would just be a published distance from the MAP.

To avoid stepped descents and limiting altitudes, vertical guidance (via a glideslope like indication) would be provided and the descent path would be a constant angle. Tricky terrain around the airport would be accommodated via curving approaches. For altimeter check purposes, the altitude the aircraft should be at would be continuously updated and displayed.

Flying one would feel like flying an ILS that changes heading occasionally.

Great
 

This is exactly the sort of thing that is needed. If you could get an accurate GPS determined altitude, this would expose and avoid pressure altitude errors.

From APMR's and other replies, I believe that the problem is less about procedure design and all about aircraft equipment. Aircraft with basic displays do not have any form of vertical representation of glidepath, while the suggestion of a continuous (digital) display of correct procedural altitude would probably add more to pilot workload than a simple glideslope indicator.

Problems associated with incorrect setting of altimeter only strengthens the case for the FAF to remain:
1. To act as a final crosscheck of altitude/glide path and highlight altimeter setting errors prior to the MAP, bearing in mind that altimeter errors are not linear and a final crossheck as close as possible to the MAP is desirable.
2. To provide another critical step for obstacle clearance, where obstacles in the approach path may be limiting.

On both these points, I fail to understand how the FAF in an RNAV/GNSS approach differs from any limiting altitude step in a DME/GPS Arrival procedure or from the FAF/glideslope height check in an ILS approach.

On Point 2, should the FAF be removed from an RNAV/GNSS approach where there are obstacle limitations, the minima may be raised and the benefits of this type of approach unnecessarily restricted.

Jethro.........

Point 1 - I don't believe anyone is suggesting we rid ourselves of the FAF, just that it be a distance which is referenced to the same point as all the others. Just like in the ILS or DGA scenarios you mentioned. That's the simple difference, they don't have a distance to run to anything other than the one point during the whole of the approach. Thus, one cannot mistakenly identify one segment for another!!!

Point 2 - FAF or no FAF, as a separate waypoint or otherwise..........Limiting altitudes, obstacles and descent points can occur either before, at, or after the FAF. The manner of representation of this Fix is an entirely independent consideration of the step-down issue.

Hope I've cleared that rather than muddied it. :)

In response to APMR's comments there is no major technical reason why a GPS box couldn't give distance to MAPt. However, unfortunately these issues go back to the start of the product development cycle and require changes to international and industry standards to resolve. Mind you, that is not to say that making the changes would not be a worthwhile endeavour.

Many of the problems go back to DO-208 the industry standard for aviation GPS receivers. It is an engineers paradise, contains 214 pages of acronyms, test procedures and equations of which 1.25 pages are dedicated to 'operational characteristics' - in other words how the avionics should interface to the pilot. :ugh: Neither the FAA/EASA Technical Standard Order (TSO-C129) or the airworthiness requirements (e.g. FAA AC-20-138) required a GPS box to provide anything other than distance to the next waypoint to the pilot. Hence, when the manufacturers have produced their equipment they have complied with the standard. Also any assumptions made by IAP designers are based upon the functional performance outlined in the technical standards which are then reflected in PANS-OPS.

The problem is that even if we go back to sort out the equipment standards there will still be kit around for a long time that only displays distance to next waypoint. So what do you PPruners think we should do to make the best of the situation? In the Australian research mentioned above the specific problems related to workload/confusion seem to be:

1. No flight deck presentation of distance to MAPt (from the GPS),
2. Too many waypoints on the approach too close together with inconsistent leg lengths,
3. Presentation/interpretation of the charts themselves.

Given that (without investment in additional airfield infrastructure - e.g. a DME) the first may take a while to resolve how best should we address the latter 2 points in the IAP design? Also in the opinion of the PPruners would solving 2 & 3 be enough to provide requisite safety levels?

Apologies for the waffling post, but this is something of real interest right now.

Cheers, NM.

PS. As an aside I have sat through and participated in the international standardisation of these units for a number of years and its only recently that I have heard any mention of this distance to waypoint issue being a problem. There was flight crew participation in the standardisation process (albeit limited). I'm not saying that it isn't an issue - because it clearly is, I'm just wondering why no one spotted it before and could it be related specifically to the Australian IAP design?

Surely a programming and database update would resolve the hardware issues in any IFR TSO compliant GPS?

It would then simply be a case of a comprehensive reissue of the required IAL plates sans the Foxtrot waypoint.

The one step of removing the Foxtrot waypoint would bring GPS NPA approaches in line with every other IAL procedure...all of which, in the final descent phase, are referenced to a single point in space, a MAP.

For a GPS which is positioned within the radio stack a remote reading display would be required, as is the case now. The GPS signal is coupled to the HSI/CDI, as is now the case, and above the ADI is a small display with waypoint name and distance to it, as is now the case. On the approach plate would be a table with distance/altitude AND a profile which represents that table. For instance the profile may be 3xGPS distance + 100'= profile altitude.

The PIC has now all the information required to fly a safe final approach...he tracks the CDI the way he would for an ILS, either manually or coupled, and simply looks at the distance to the named MAPt in the window a few cm above his ADI as says to himself "3x6+100' = 1900'...on profile".

3x5+100=1600'..50' high (adjust ROD slightly)
3x4+100=1300'...on profile (adjust ROD slightly)
3x3=1000' on profile, gear down.
3x2=700'..approaching minima.
3x1=400' level..MAPt, not visual going around.

And his/her eyes never leave the instruments until he/she looks for visual reference, his scan and SA are maintained.

As it currently stands he is required to be looking at the chart constantly and comparing his altitude and distance from 'a' waypoint..."Hmm 3 miles from F waypoint (which is probably 8nm from the MAPt waypoint) and I should be..where isn it...ok 2500'..ok now 1nm I should be 1800'...now 4nm from the next waypoint I should be..umm...oh 1300'."

In the first example the PIC has no requirement to reference the approach plate at all after briefing and setting up the navaids in the cruise. The way it is at present he must constantly reference the approach plate, during the most critical phase of flight, to have any chance of remaining situationally aware...when he should just be flying the aeroplane.:ugh:

Augmentation
 

Are there any USA counterparts reading this thread that may be able to comment on LPV approaches used in the US with regard to WAAS augmentation capability? This then allows a glideslope indicator to be used for vertical guidance and has in fact lead to lower minimums throughout the US.

I believe AirServices have been considering for some time this method, but are undecided about whether to use the US, Japanese or Euro's augmentation system.

This has got to be a much safer system and we can only hope that the procrastination ends before another tragedy results.:ugh:

JT

I'm not sure that the Dist-to-next-waypoint issue is really a newly recognised problem. I recall when GPS NPA's were first introduced in Oz all the guidance material implicitly recognised the problem by emphasising the waypoint distance difference.

Perhaps back then it wasn't realised just how much it's at odds with convention?

the problem with the procedures you've identified are to do with the acft equipment. the honeywell fmc in airbus acft does not comply with the ARINC424 standard [let alone the current standard]. it assumes that ALL missed approach waypoints are at the threshold and as such assumes you want to be at 50' abv thr ht at this point. if your MAPt is not at the THR due ATC or climb or turn requirements then ANY app which is coded as an RNAV will fly the same profile to a point short of the rwy. if it were coded as GPS rather than RNAV [as they used to be] then they will fly correctly!!
The ARINC424 standard states where the MAPt is not coincident with the RWY THR then a calculated xing ht must be inserted at the MAPt. Honeywell FMCs don't do this! Jeppesen have confirmed that they have coded the procedure in accordance with the ARINC standard.

Can't help myself: Boeing superior to Airbus AGAIN!!! (Ducks for cover :) )

as you've been told before [and you "simply don't understand that"] the design of GPS NPAs is forced by the US military [the owners of the GPS system] not the manufacturers, nor the procedure designers.

although i personally don't have a problem with the concept of distance to next wpt, i can understand that some might, and would prefer a distance to THR [not MAPt as this can be up to 3km fm THR].

what you are looking for is a presentation which will allow you to do some simple mental math to improve your situational awareness. A laudable concept, lord know when ur bouncing around SP IFR on a dark stormy night you don't want to add complexity to what is a difficult time at best.
this does not equate with the REQUIREMENTS of the procedure design to track you from one waypoint to the next [this is what a GPS receiver does - from the manufacturer] whilst keeping you clear of terrain [what the procedure designer does].

your statements are futile. unless the US military amend their specification, the manufacturers won't change their software/hardware, and procedure designers can't change procedure steps.
if you think there is a way to change the procedure plate presentation such that you will be better able to use that information AS IT RELATES TO THE WAY THE DATA IS PRESENTED ON THE GPS UNIT {this bit can't be changed without telling the USM} then, by all means, talk to CASA.
this means the presentation on the GPS won't change as it is not controlled by AsA nor CASA. the procedure plate, either AsA or Jepp version, can be changed. if you reckon there can be an improvement, let someone who can do something about that know. else stop persisting with ur drivel


like all big business, they don't respond to governments just $$$

interesting comments.
however i'll tell you that RNAV (GNSS) [aka GPS NPAs] do have to be designed the way they are currently.
whatever programming you have done was not done for any of the current certified RNAV receivers [GPS or otherwise].
as i've stated in other posts today, the US military gave a spec to which manufacturers created their receivers. the procedures are then just following the MINIMUM spec available as TSO129C. ICAO spelt out how that is done and your regulator will insist how that is implemented.
if there had been input in the late '70s when the spec was created, maybe things would have been different. hindsight is wonderful!

Hot buoy, if you are doing any other approach with a FAF, I agree its a requirement to know where it is and to track over it. You just use a DME distance or a Marker or whatever to give you its position relative to the MAPt.

:rolleyes:
OK, I new someone would bring this up. Whatever the manufacturer says, whatever the procedure designer wants, whatever the regulator requires, whatever the tea lady prefers....etc etc.

I'll keep it simple...As a pilot of a multi-crew RPT aircraft, regularly conducting GPS NPAs into various airports, in various weather conditions day and night...

In my opinion, they are dangerous - they need to be fixed now.

I don't give a flying f#$% what it takes, just fix it now.

Not later, now.

:*

The US Mil may own the satelites but that is all...how the TSO spec came to be is a completely separate issue.

I agree!

Are you for real? I get the impression that those in the "technically impossible, too expensive" camp have given up on this one. All the passengers and crew who may have to eat dirt as a direct result of this hazard probably would beg to differ.

really?
TSO129C is a direct derivative of RTCA DO-208
TSO145/6 are derived from RTCA DO-229C

The TSO's are developed by the FAA (and copied by the EASA and others) to augment the requirements in the RTCA docs.

The RTCA docs are developed by (usually large) committees composed of airframers, avionics manufacturers, ANSP's, CAA's and others from around the world.

The only military connection in any of this is that GPS is being used and the performance of the SPS element of the GPS service has been specified by the US DoD. All of the aviation receiver functionality be it the HMI, how integrity is provided, how to generate a nav solution, how to generate guidance for an RNAV route are the product of the RTCA committees, not DoD.

I haven't had any bad experience with them in many years of extensive exposure to them, in all climates.

Situational awareness AND good multi crew support is the key.

Can't comment on jet software (Airbus)...suffice to say Boeings BDFW is good (Box t'Does Fuggin Wonders).

Requests previously did go in to modify the Jepp plates, re distance to MAP not next WPt and graphic MSA floors for better comprehension (Eastern/QF, I believe)... many have been adjusted.

Found them safe and no probs with them myself but interesting to read.

This will become a hot topic in the UK next year
 

UK CAA are currently conducting a GNSS NPA trial which was due to end this month, but I hear is to continue to the end of the year.
I flew a couple a while back and was thrown by the Step Down Fixes (SDW) and tempo lost spatial awareness.
I agree that the presentation of distance to go from GPS and conventional RNAV is an issue that needs to be addressed.
What ever the answer is it should be adopted world wide. Over to you ICAO:rolleyes:
Sir George Cayley
ps Funny in here. All the alcohol rushes to me 'ed:oh:

Good thread, this is something I've had a problem with since I started using this type of approach.

The main point seems to be that GPS distance to next approach waypoint can be confusing.

The fix seems obvious: Publish both distances. Not ideal of course, but you could make use of the distance to MAPt and use the distance to next waypoint to crosscheck - this would stop any waypoint confusion.

Most GPS units are able to display total distance to each waypoint, and this page is only required until you reach the final approach fix, where the distance becomes intuitive.

Altitude awareness?
 

And while you are concentrating on all this, it is easy to lose altitude awareness. I reckon this sort of thing has killed a few already. So far, only in small numbers.
The technology is there to fix it.

Hot Boy,
You can call it what you like mate, the fact is that people are having problems with GPS NPAs because of the difficulty caused by Foxtrot and it is likely that the design contributed to the deaths of 19 people. And yes, you'll be pleased to know that I have had quite a lot of success in forcing Jepp/Honeywell to change their database programming, which just goes to make the whole situation more pathetic: it could be done properly but it wasn't.

As you know I have said before (how many Prune guises do you have?), the box doesn't give two hoots about where the waypoints are for tracking or mode changes. One of our boxes starts scaling down to APPR 2nm before it gets to Foxtrot so it's pretty obvious in doesn't need to fly over a waypoint to start doing something different.

IF your theory about the design criteria is correct (and NavMonkey's answer above casts doubt on that) then the design criteria, allowing one waypoint at ~10nm, should be changed and the Foxtrot "point" should become a distance from Mike (as it is with every other non-precision approach). I simply do not accept that the technology to do this cheaply doesn't exist. NavMonkey might have to redraw all the approach charts, but that'll give him something to do! :}

Bloggs,

I'm with you 2,000% on this one!!:D

Loss of altitude awareness as you struggle through the segments is a major problem. Not only for a newbie [to this approach], but even a reputable [?] operator at my home GA port; the EGPWS doesn't work in the landing configuration!:uhoh:

G'day ;)