1. RNAV PROGRESS STEP BY STEP
Transition from conventional terminal airspace procedures to RNP-RNAV procedures is envisaged to take place in several steps. The steps below can be seen as the path towards the end goal of a route structure based completely on RNP-RNAV.
Table 1 RNAV
| Phase | Route design |
|---|---|
| 1 | Conventional procedure A conventional procedure design (VOR radials, NDB bearings and DME fixes/arcs, ILS, MLS) flown with conventional means (VOR, ADF, ILS and MLS). |
| 2 | Conventional procedure flown with an RNAV system A conventional procedure design as in phase 1 stored in a navigation database utilising the full set of ARINC 424 Path and Terminators. NOTE: Legal issues are not involved, as the route runs along conventional routes and the pilot has the capability and the obligation to monitor flight progress by conventional means. |
| 3 | Conventional procedure meeting RNAV criteria A conventional procedure designed specifically to meet RNAV criteria using sensors such as GNSS, DME/DME and VOR/DME. This procedure is published as a conventional procedure, which may refer to radials, bearings, and fixes but will have waypoints to define the RNAV track. This removes the ambiguity / approximations associated with phase 2 and ensures repeatability of the intended ground track. Waypoints are published in the AIP, which may also contain guidelines for database coding. NOTE: This is the first step towards achieving predictable track keeping and can be considered a learning period for route designers, chart producers and AIS providers. Schiphol SIDs as from 1996 are of this design type. |
| 4 | RNAV procedure (Not being RNP) A procedure designed specifically for RNAV, using sensors such as GNSS, DME/DME and VOR/DME. The procedure is identified on the chart as an RNAV procedure and the sensor used for its design (if required) must also be published. The procedure must be flown using an RNAV and/or RNP certified system. |
| 5 | RNP procedure A procedure designed according to RNP criteria. It is identified as RNP and is useable for all applicable sensors. The applicable airspace protects against obstacles and other routes. It may only be flown with systems, which are specifically RNP certified. |
The conventional procedure (phase 1) was originally designed for manual flight and does not always lend itself to the use of RNAV systems. Database providers have to interpret the procedure using the leg types from ARINC 424 (phase 2). This has resulted in the need for additional fixes to be created by the database supplier to enable a best fit to the procedure path. Although generally transparent to ATC, path deviations can occur depending on aircraft type, weight, C/G, FMS type and wind. The RNAV system, whilst commanding path steering, may have bank angle or performance limits built in. The consequence of such limits may be a path deviation, which may be recovered automatically or may require pilot intervention.
Conventional procedures, whether coded to ARINC 424 or not, shall be monitored by means of raw data. Consequently, the integrity of the database is not really an issue (legally). The major concern with these procedures is their compatibility with the RNAV systems and flyability of the procedure under all conditions for all aircraft types.
It is therefore preferable that conventional procedures be designed according RNAV criteria (phase 3).
When RNAV is subsequently mandated, the underlying conventional procedure can be withdrawn, leaving a stand-alone RNAV procedure (phase 4). RNP procedures (phase 5) are expected to be introduced initially only to take advantage of the reduced obstacle clearance requirements associated with RNP ≤1.
2. FROM RNAV TO RNP
RNP can be considered to be the last stage of RNAV development.
The ever-increasing technological possibilities and resulting diversification in flight guidance systems have made it impossible for Regulators to keep pace with all developments. Instead of specifying and certifying many different types of sensors and/or equipment, an amount of airspace (e.g. 1 NM) around a nominal track and a containment level (95% of the flight time) is specified and the system must prove to meet the requirements (normally via a statement in the AFM).
RNP assumes a multi-sensor system. The monitoring system is self-contained and independent from environmental influences. The entire system must meet high standards of accuracy, integrity, availability and continuity of service.
As RNP philosophy comprises the whole system, all separate elements must meet a certain level of safety that will not compromise the total safety level of the RNP system if one of the components fails. The probability of multiple failures and the effect thereof on the system’s outcome must be taken into account.
3. DEVELOPMENTS IN EUROPEAN AIRSPACE
The application of RNAV gave an opportunity to reorganise the route structure more in line with the actual traffic flow. First step in the restructuring of European airspace was the implementation of the European Trunk Route network above FL 300 in 1993.
At the time airborne requirements for RNP were not yet finalised and therefore application of the RNP concept was still a bridge too far. As an intermediate step Eurocontrol prepared a derivative function of RNP: Basic Implementation was planned according to the following schedule:
− 1993: Implementation of BRNAV above FL 300 to support the Trunk route system.
− 1995: Implementation of Random RNAV airspace’s where random flights could be carried out.
4. B/P RNAV vs. RNP 5/1
In European airspace there has long been a strong demand for the use of RNAV, but the timing of its implementation was inappropriate for the environment. Aircraft could not comply with the more stringent RNP requirements and the (ground) infrastructure could not cope with the effects of the increased navigation accuracy.
To be able to utilise most of the benefits of RNAV, BRNAV and PRNAV were developed as a transition towards the (ICAO) RNP philosophy: RNP 4 and RNP 1.
Airborne requirements for both systems (RNP and RNAV) are different; those for RNAV being more relaxed, as shown by some examples below:
− RNP 4/5 requires a database for en-route and for the TMA; BRNAV does not.
− Fixed radius turns en-route are required for RNP4/5; not for BRNAV.
− Fixed radius turns en-route and in the TMA are required for RNP 1; not for PRNAV.
− System integrity is defined for RNP; not for B/PRNAV.
Implementation of the RNP concept is effectuated in a step by step process. New aircraft are RNP certified while (in Europe) BRNAV has been implemented as a forerunner for RNP (5). PRNAV as a forerunner for RNP 1 is also emerging gradually.
Certification of RNP means that the aircraft is capable of meeting the certification criteria under controlled conditions only. A fundamental element of RNP is the capability of the environment to support such operation. E.g.: In European airspace, sufficient DME stations, approval of GPS as a sensor, and JAA approval guarantee this support for BRNAV for the en-route phase of flight.
ICAO criteria specify the RNP value as part of the airway segment designation, e.g.: UL207 (5).
With this value stored in the database the FMS would be able to identify the RNP requirements for the applicable route segment and automatically set the ANP/EPE value (see below).
Database suppliers, are still unable to provide this service, so desired entries must be made manually.
5. ANP / EPE
As RNP operation is ‘sensor independent’ by definition, operational criteria specify the need for the crew to monitor the RNP capability during flight.
As mixed sensors can be used and there is no need for an underlying conventional route, this monitoring could be very difficult without an automatic RNP accuracy warning system.
Such a system, whether called Actual Navigation Performance (Boeing) or Estimated position Error (Airbus) gives an estimate of the aircraft position as calculated by using all available sensors. If the system assumes that the actual position does not meet the RNP requirement for the applicable phase of flight, a warning will be generated.
Be aware however, that a flight technical error is not included in the ANP/ENE value. Also, incorrectly accepted updates, e.g. after a period out of range of update facilities, may not be detected, as the FMS ‘thinks’ that it is in the right position. Increased use of GPS will reduce this problem.
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)