ICAO PANS-ATM defines Area navigation (RNAV) as:
'A method of navigation which permits aircraft operation on any desired flight path within the coverage of ground- or space-based navigation aids or within the limits of the capability of self-contained aids, or a combination of these.'
Put differently, area navigation permits point-to-point navigation without forcing the route to or from ground-based navigation aids.
An RNAV system is “A navigation system which permits aircraft operation on any desired flight path within the coverage of station-referenced navigation aids or within the limits of the capability of self-contained aids, or a combination of these. An RNAV system may be included as part of a flight management system (FMS).” (ICAO Doc 9613)
Conventional Navigation
Before navigation computers arrived on the flight deck, aircraft used to fly conventionally flying from one ground-based navigation aid (NAVAID) to another as required by the ATS route placement. Where there was no terrestrial NAVAID possible/available, then a 'fix' (range and bearing) from a close NAVAID could be defined. Protection along that route was driven by the performance and distance from the NAVAID in use. Conventional navigation was not very flexible if an airspace redesign was required.
The Role of Digital Avionics
In the 1970s the first digital avionics arrived on commercial aircraft flight decks. This simple computer enabled the flight crew to manually insert the coordinates of the NAVAIDs and the computer, using inertial navigation, would provide guidance to the active ‘waypoint’.
Pilots started to use the guidance from the computer, provided on a Course Deviation Indicator (CDI), to fly the conventional ATS routes by manually inserting the coordinates of the navigation aids defining that route. Provided the coordinates of the NAVAID and the physical location were the same, the computer enabled the flight crew
to establish and fly the flight plan route automatically. Where there was a discrepency between the published coordinate and the actual position of the NAVAID, the pilot could resolve this by flying the required radial defining that ATS route.
It was rapidly recognised that a coordinate did not have to be co-located with a terrestrial navigation facility, the waypoint could be at any location. This technique of flying to a coordinate and not to a specific NAVAID was called ‘Area Navigation’.
Area Navigation
Area navigation is enabled by a navigation computer, which allows the aircraft to fly from point-to-point. Today, the navigation computer is fed with positional information from the navigation sensors fitted to the aircraft. The computer estimates its position, based on the most accurate sensor available, and then provides guidance to the next active waypoint. If a required navigation performance is stipulated along the path the aircraft is flying, provided the aircraft has the appropriate sensors to deliver the desired accuracy, the aircraft will follow the path with that level of performance
or better, 95% of the flight time. In the very high majority of the aircraft today, the navigation data we employ is held in the computer’s navigation database.
Area navigation gives airspace designers and planners flexibility to place ATS routes where they wish and provides the planners the ability to strategically deconflict flows of traffic where necessary. These routes can be protected linearly as the aircraft is expected to deliver a known lateral performance which it has been certified to.
How is Area Navigation Enabled?
Area navigation can only be achieved with the use of a navigation computer on-board the aircraft.
This computer may be a simple 'stand-alone' computer providing its output to the pilot on its own 'built in' Course Deviation Indicator; a good example of this would be a commercially bought GPS receiver. Alternatively, the navigation computer may be integrated into a Flight Management System (FMS) and the computer has multiple position sensors feeding into it and, possibly, information from an Air Data Computer, which would allow the computer to calculate both horizontal and vertical position relative to a defined path. This information could then be presented to the flight crew on Primary Flight Displays (PFD) and Navigation Displays (ND).
The pilot will create the route by either manually inserting the waypoint coordinates or, more commonly today, by extracting the waypoints from the computer's Navigation Database (DB). Most PBN navigation specifications require the computer to have a DB; the data held in the DB must come from an 'approved supplier' (see the Aeronautical Data section for further information on approved suppliers) and that database must be kept up-to-date in accordance with the ICAO Annex 15 Air Regulated Cycle (ARAC cycle). PBN Navigation Applications applied in terminal airspace do not allow the pilot manually to create waypoints.
The computer will connect those waypoints together, in order, and calculate a geodetic (great circle) path between them. This ‘defined’ path will be shown to the pilot on the navigation display (if one is fitted to the aircraft).
The computer will then estimate the position of the aircraft and compare that to the defined path. Deviation between the estimate position and the defined path will create guidance information, which will be displayed on the aircraft’s ND (if fitted) and on the Course Deviation Indicator (CDI). Guidance is commonly referred to as Path Steering.
Most navigation specifications require the navigation computer to have a navigation database containing the elements that are needed to construct the flight plan.
The data is sourced from States' Aeronautical Information Publications (AIPs) by professional third parties, known as ‘Data Houses’, who prepare and code the required information for the on-board database which is updated every 28 days under a scheme known as the AIRAC cycle. The coding of the data is based on the industry standard ARINC 424.
Once the aeronautical data has been coded, it is then passed to the data packer, who is generally the company that built the navigation computer. The ‘data packer’ then prepares the ARINC 424 coded data into the format and elements suitable for use by the specific target computer.
Some older RNAV systems, built in the 1980 and 90s may not have a database and waypoints must be manually loaded. This could potentially lead to data entry errors. The majority of Nav Specs require an on-board navigation database, however, RNAV 5 is the exception.
Whilst a small number of conventional procedures still exist, the vast majority of operations today are PBN, whether that is flying on an ATS route or flying point-to-point in a route free airspace. When there are no prescribed routes, then no performance criteria are coded into the computer's database. In such a case on-board systems default to a value which has not been harmonised between the different systems.
European Certified Data Suppliers
Since March 2017, aeronautical database suppliers require certification by EASA as a competent authority for the provision of data services (DAT). This certification replaced the EASA practice of issuing voluntary Letters of Acceptance (LOA).
As of January 2019, European organisations processing aeronautical data for use on aircraft (DAT providers) are required to be certified in accordance with EU 2017/373 by EASA.
There are two types of DAT Providers: Type 1 and Type 2. See below for an explanation of each type.
Currently, the origination and publication of aeronautical data undertaken by each Member State is done through the Air Navigation Service Provider's Aeronautical Information Service (AIS). To ensure the quality of the data at State level, the EU originally laid out an Implementing Regulation on Aeronautical Data Quality in 2010 (ADQ IR 73/2010). That regulation (EU 73/2010) was superseded by 2017/373 following the finalisation of the AIS Annex and today ANSPs and DAT providers are required to be certified against 2017/373.
Type 1 DAT Provider
A data provider that processes aeronautical data for use on aircraft and provides an aeronautical database meeting the data quality requirements (DQRs), under controlled conditions, for which no corresponding airborne application/equipment compatibility has been determined.
Provision of Type 1 DAT does not authorise the supply of aeronautical databases directly to end-users/aircraft operators.
The three most common aeronautical data providers in Europe are Jeppesen, Lufthansa Systems (often known as LIDO) and NAVBLUE.
As of 1 January 2019 all three European datahouses have been certified in accordance with EU 373/2017.
A list of Type 1 DAT Providers can be found at:
https://www.easa.europa.eu/download/atm-ans/List-of-approved-ATM-ANS-organisations.pdf
Type 2 DAT Provider
A data provider that processes aeronautical data and provides an aeronautical database for use on certified aircraft application/equipment meeting the data quality requirements (DQRs) for which compatibility with that application/equipment has been determined.
Provision of Type 2 DAT does allow the supply of aeronautical databases directly to end-users/aircraft operators.
These data providers will include the manufacturers of flight management computers such as Honeywell, Garmin, Rockwell Collins, General Electric, CMC Marconi, Universal etc.
A list of Type 2 DAT Providers can be found at:
https://www.easa.europa.eu/download/atm-ans/List-of-approved-ATM-ANS-organisations.pdf
Third Country Qualified Data Suppliers
As EU 2017/373 is a European regulation, global third country data suppliers are not required to comply with this IR. Therefore the old LOA process is still used as one method used by operators to demonstrate that their data supplier is an approved supplier in other parts of the world. EASA provides mutual recognition of Third Country Letters of Acceptance.
To require aircraft to operate on PBN routes and procedures they must be published in accordance with the requirements of ICAO Annex 15, Annex 4, Annex 11 and PANS-AIM (ICAO Doc 10066).
If an Airsapce Concept requires a lateral performance along the PBN route, then this performance requirement must be coded into the navigation database. For a datahouse to code an airway or IFP record, the route must be designated in accordance with Annex 11 Appendix 1 or 3 and that route or procedure must be published in the AIP. If these two conditions are not met then there is no guarantee at what stage, if at all, that the pilot will be alerted if the aircraft deviates from the route.
The notion of PBN specifications requires that on-board equipment be certified, that the aircraft be certified for the target operation, and that the crew be appropriately qualified. A certified aircraft whose crew do not hold PBN privileges on their IR licence cannot operate on the targeted PBN application. The converse is equally true. The navigation performance requirements published in the AIP and ‘cleared’ by ATC, must be matched by the air crew and the aircraft being qualified to execute the clearance.
For more information on: