1. GENERAL
Although many elements of the system are subject to certification criteria meeting high levels of integrity, the total system may, due to its complexity, show shortcomings.
Even with modern, highly sophisticated systems navigation procedures should be followed strictly to ensure that the aircraft’s true position remains within applicable limits.
RNAV System Error
2. DATABASE
The RNAV database is complex. Due to its magnitude, complexity and open structure (the 4 weekly AIRAC updating cycle) errors may creep into the system.
Critical elements of the database must be produced and checked according to very strict standards, specifying the data handling process in order to prevent corruption of data during that process.
The sheer amount of data necessary for RNAV operations may, especially in older systems, cause storage problems.
Database coding has become a major issue. Initially simple, the complexity of route design created a need for more complex coding rules.
Design of conventional routes have a high degree of flexibility and attempts to ‘translate” these routes into FMS coding, using only 23 Path and Terminators, has, under certain conditions, resulted in unexpected aircraft behaviour.
For design of specific RNAV routes, only a limited amount of rules are allowed; as much as possible based on point to point navigation. This simplicity should prevent unexpected results under difficult conditions and make the database better controllable but effectively reduces system sophistication.
3. WAYPOINTS
Flight characteristics of aircraft limit the location of waypoints, and minimum distances between them must be adhered to. Waypoints, located too close together, (‘too’ depends on course change, fly-by or fly-over and ground speed) may lead to unexpected aircraft behaviour.
Minimum leg distance between waypoints.
As airspace is becoming increasingly more congested there is a need to define the lateral path over the ground more accurately and to have more control over the accuracy of the path to be flown. These requirements lead to a tendency to design tight and complex routes. In case of specifically designed RNAV routes, system limitations must be adhered to and the ability of different airframe/FMS combinations to correctly fly those routes must be checked. Additional buffers for high winds and lesser bank angles must be accounted for.
4. UPDATE LOGIC IN RELATION TO GROUND BASED STATION UPDATES (DME AND VOR/DME STATIONS)
VOR and DME stations used for updating are flight checked to verify accuracy requirements. Terrain characteristics may have an effect on the emitted signal and signal usage may therefore be limited to certain areas around the station. These sectors however, can not be stored in the database.
Therefore the FMC uses a filtering program, which rejects stations that may cause incorrect updates. Before accepting a newly tuned station, the resulting position is compared to a predicted position and if the difference exceeds a certain tolerance, that station is not accepted for updating. Additionally, it is flagged as such in the update file for the remainder of the flight.
This tolerance depends on the environment. After operating in a no-radio environment, IRS drift is taken into account. To prevent a situation where all radio stations are assumed to be out of tolerance because of this increased position inaccuracy, tolerance to accept radio updates has to be increased.
This may lead to the acceptance of radio updates which would not have been accepted if the flight had been operating in an uninterrupted radio environment.
5. CAPTURE LOGIC
Although a certain level of standardisation is assured, differences are experienced between different systems, especially under extreme conditions.
RNAV unfriendly or tightly designed routes may reveal hidden, unexpected or unknown logic, especially with overlay procedures, as their design does not account for RNAV system limitations.
The database can cause unexpected interaction due to the amount of data to be handled and the complex FMC software.
For specifically designed RNAV routes however, the limitations of the RNAV system is the starting point of the route design.
6. ACCURACY LIMITATIONS
For traffic separation purposes, ATC expects aircraft to fly similar lateral and vertical paths. Flight prediction is an important tool for traffic flow and airspace capacity management. A high level of repeatability is required and ATC needs sufficient confidence to rely on it for traffic separation.
Accuracy of RNAV routes has shown to be very high, especially on straight segments but less so during turns. During turns, most systems still use an open loop logic. As only limited, or no position updating is possible, lateral track deviations may occur. Steering commands to follow pre-calculated tracks are limited due to the limiting flight physics during such a manoeuvre. The emerging fixed radius turn (RF leg) has been designed to solve this problem but is difficult to code and is yet to be tested.
7. IRS
As IRS accuracy degrades with time, in case of IRS only, the route can be continued only for a limited time. Based on the maximum drift rate for a single system, the maximum IRS only time is set by the ICAO Obstacle Clearance Panel to:
− 12 minutes for the approach phase of flight,
− 25 minutes within the TMA
− 50 minutes when en-route, where the route is designated RNAV.
8. PILOT MONITORING ROLE
Current navigation systems are capable of high performance standards. However it is essential that stringent crosschecking procedures be employed, both to ensure that these systems perform to their full capabilities and to minimise the consequences of equipment failures and possible human errors.
Regardless of how sophisticated or mature a system is, it is still essential that stringent navigation and crosschecking procedures are maintained if Gross Navigation Errors (GNEs) are to be avoided.
9. CHARTING ISSUES
For procedures as in step 1 and 2 of table 1 RNAV is used as a supporting tool and there is no relation between coding and charting.
In step 3, additional to the underlying conventional route, specific waypoints are provided to support RNAV. They are State controlled and part of the official procedure. To be able to verify RNAV operation by conventional means, waypoint location is published on the charts as well.
In steps 4 and 5, higher integrity of the RNAV route is to be assured. Procedures must be specifically identified as such: RNAV or RNP. In case of sensor specific RNAV, the required sensor will be identified on the chart. E.g.: RNAV (DME/DME) or RNAV (GNSS).
The design caters for an airspace related to these sensors. If no sensor is specified with the procedure, (RNAV), all sensors are used for the design of the route and any downgrading to an alternate sensor is allowed as it is catered for in the design.
In case of RNP, no sensors will be identified as it is assumed that they are available. The provision of the required infrastructure (input to the sensors) is a State responsibility. Based on the available sensors, a State can declare the minimum RNP value for each segment of the route.
10. WAYPOINT NAMING AND DESIGNATORS
Flight Management Computers are still limited in storage capacity. ICAO Annex 11 specifies a naming convention based on 5 letter names. 5 Letter pronounceable names may not be so pronounceable in all languages and there is a drive to apply alphanumeric names instead. These are based on a simple logic AAXNN where AA contains the last two characters of the aerodrome location indicator, X is a numeric code from 4 to 9 (to prevent confusion with course information) and NN a numeric code from 00 to 99.
Example EH638 (Note the Netherlands apply the first two letters of the FIR code instead, but this is due to the fact that Schiphol was the first airport in applying this logic. This may be changed in the future when the alphanumeric system becomes a global standard).
The amount of characters of SID, STAR, Transition and Airway designators are limited.
ICAO designators of SIDs and STARs are based on a 5-letter name, a validity indicator and a route indicator (if applicable)1. However, the FMC database is limited to 6 characters only for SIDs, STARs and Airway designators and to 5 letters for Arrival and Departure Transitions.
Therefore the database supplier will apply a contraction technique if needed, skipping the last letter or letters of the ICAO 5 letter pronounceable name: LEKKO1S becomes LEKK1S (6 characters), a RIVER 1A transition becomes RIV1A (5 characters).
- A validity indicator number can be used to verify that the correct version of the procdure has been stored, the route indicator distinguishes a SID or STAR having the same basic indicator (name), but different route.
Source: FCRG
See also:
History of RNAV
Area Navigation Definitions
RNAV System Description
Required Navigation Performance (RNP)
RNAV Development
RNAV System Limitations
Global Positioning System (GPS)