GNSS NPA's are dangerous
Thread Starter
Join Date: Aug 2006
Location: Suitcase
Posts: 234
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Grandpa Aerotart
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
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
Join Date: Nov 1999
Location: Beverly Hills
Posts: 10
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Last edited by 404 Titan; 5th Oct 2006 at 16:29.
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).
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.
some FMC coding issues
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.
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.
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. 
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.
Does the navigation data have product approval in accordance with ED76/DO200A ?
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.
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.
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.
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?
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?
Join Date: Mar 2001
Location: Dunnunda & Godzone
Age: 74
Posts: 4,275
Likes: 0
Received 0 Likes
on
0 Posts
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
SE Woomera
Join Date: Mar 2006
Location: Australia
Posts: 68
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Nov 1999
Location: Beverly Hills
Posts: 10
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.