22-23 June 2005 RNAV Procedure Coding Workshop 1

Introduction to ARINC 424

Amsterdam
22-23 June 2005
22-23 June 2005 RNAV Procedure Coding Workshop 2

Flash Back (1)

• ARINC - Aeronautical Radio, Inc. - a cooperation of a variety of
stockholders such as airlines, aircraft manufactures and other air
transport companies.

• ARINC activities include operation of land radio stations, the

allocation and assignment of frequencies and the exchange of
technical information.

• ARINC sponsors the Airlines Electronic Engineering Committee

(AEEC).

• AEEC formulates standards for electronic equipment and systems

for airlines.
22-23 June 2005 RNAV Procedure Coding Workshop 3

Flash Back (2)

Purpose of ARINC Specifications
1. Indicate new equipment requirements to the
manufacturers of electronic equipment based upon the
considered opinion of the airline technical experts.

2. Influence new equipment designs in order to achieve the

maximum possible standardisation of those physical and
electrical characteristics which affect equipment
interchangeability.
22-23 June 2005 RNAV Procedure Coding Workshop 4

Flash Back (3)

• The requirement for on-board navigation data bases was identified in
the 1970s with the development of the first Flight Management Systems
(FMS).

• ARINC 424 - first edition was published in May 1975 and adapted by
the industry in July 1975. At this stage the ARINC 424 document was
developed to support conventional Navigation.

• With the implementation of the area navigation methods, and the

capability to use inputs from different sensors, the requirement to have
access to a sophisticated on-board navigation data base became
mandatory (TGL 10).

• ARINC 424 has been continuously improved and adjusted over the
years in order to accommodate new navigational procedures,
capabilities, standards and technical characteristics.
 22-23 June 2005 RNAV Procedure Coding Workshop 5

ARINC 424 – a Specification for Navigation System Data Bases

ARINC 424 - is a standard for the preparation and transmission of

data for assembly of airborne navigation system data bases

• The ARINC 424 document enables data

base suppliers, avionics systems and
other users of the data bases to fly and
flight plan procedures as prescribed by
designers. The document is not meant
to be a prescriptive document for
procedure design experts.

• Currently ARINC 424-16 is in use

• ARINC 424-17 is under development

22-23 June 2005 RNAV Procedure Coding Workshop 6

Aeronautical Data Processing Steps

1. Assemble a data bank.

2. Produce electronic media meeting the operational requirements of
the next link in the data chain (avionics manufacturer, airlines,
ATC).
3. Merge the data with the operational software of airborne navigation
computers.
4. Produce electronic media containing the merged data for use on
individual aircraft.
Participants in the data processing chain are public organisations,
States, avionics manufacturers, datahouses and various end-users.
Any participant in the data chain may originate, transmit, assemble,
prepare or integrate aeronautical data.
 22-23 June 2005 RNAV Procedure Coding Workshop 7

Differences in Avionics Systems

• Individual navigation systems require different formats for navigation
reference data.

• The available storage in many avionics systems prevents all

procedures or data elements from being loaded into the airborne
database.

• Airlines are cost driven and hence do not upgrade equipment unless
there is a clear benefit.

• The system life cycle of most avionics equipment is 15 to 20 years.

• Over the years, different earth models, geodesic calculations and uses
of variables such as magnetic variation have been used.

Differences in avionics systems need to be considered during the

processing of aeronautical data. As a result, databases from different
datahouses may not always be consistent.
 22-23 June 2005 RNAV Procedure Coding Workshop 8

Navigation System Data Base File Content

Sorting Process
• Sorted in alpha/numerical order
• Divided into standard (S) and tailored
(T) records
• S records ordered by Area Code
• T records ordered by Airline Code
• Individual records divided in
sections/sub-sections of max. 132
characters
– Record: A single line of computer data
made up of the fields necessary to define
fully a single piece of information

– Field: The collection of characters

needed to define one item of information

• Each record uniquely defined and

stored in the master user file
22-23 June 2005 RNAV Procedure Coding Workshop 9

Geographical Area Codes

 22-23 June 2005 RNAV Procedure Coding Workshop 10

Access to Navigation Data

• An aeronautical database is a collection of data that is arranged for ease of
electronic storage and retrieval in a system that supports airborne or ground
based aeronautical applications.

• The database structure, sorting rules and the relationships between data
elements, laid down in ARINC 424 standard are indispensable prerequisites
for the function of such systems.

• Each primary record, completed by additional primary and continuation

records, covers all required data elements.

• Basic principles of databases is that information need to be entered,

corrected, changed or deleted only once.

• On-board RNAV systems have access to pre-programmed routes, the

airspaces concerned, the navaids serving this airspace, the airports along the
route including departure and destination airports.

• The system identifies the next waypoint, calculates the aircraft position and
provides inputs to the flight control systems.
22-23 June 2005 RNAV Procedure Coding Workshop 11

Master Airline User file

Alternative paths to individual master airline files

 22-23 June 2005 RNAV Procedure Coding Workshop 12

Data Record (1) Layout

– VHF NAVAID
Contains:

• customer/area code,

• station identifier,

• navaid name,

• co-ordinates,

• frequency,

• elevation (DME),

• variation,

• datum code etc.

 22-23 June 2005 RNAV Procedure Coding Workshop 13

Data Record (2)

Layout – Waypoint
Contains:
• Waypoint ID
• Co-ordinates
• Type
° ENR or Terminal
° RNAV
° IAF/IF/FACF/FAF/MAPt
° Stepdown (Terminal only)
° Arc centre (Terminal only)
° SID/STAR/APP/Multiple
• Usage
° RNAV airway
° Terminal
 22-23 June 2005 RNAV Procedure Coding Workshop 14

Data Record (3)

Layout – Holding
Contains:
• Region Code
• Fix Identifier
• Inbound Course
• Turn Direction
• Leg Length
• Leg Time
• Holding Speed
• Min Altitude
• Max Altitude
• Cycle Date
 22-23 June 2005 RNAV Procedure Coding Workshop 15

Data Record (4)

Layout – Airport
Contains:
• Airport ICAO Identifier
• ATA/IATA Designator
• Longest Runway
• Magnetic Variation
• Airport Elevation
• ARP
• Speed Limit
• Transition Level/Altitude
• Airport Name
• Datum Code etc.
 22-23 June 2005 RNAV Procedure Coding Workshop 16

Data Record (5)

Layout – Gate
Contains:
• Airport Identifier
• Customer Area Code
• Gate Identifier
• Latitude
• Longitude
• Notes etc.
 22-23 June 2005 RNAV Procedure Coding Workshop 17

Data Record (6)

Layout – SID/STAR/App_1
Contains:
• Procedure Identifier
• Route Type
° SID/STAR
- Runway Transition,Enroute
Transition, Common Route
° App
- App Transition, GPS App, RNAV
App, Primary MISAP, Secondary
MISAP, Circling App, Straight-in
App, Helo to RWY
• Transition Identifier
• Sequence Number
• Waypoint Identifier etc.
 22-23 June 2005 RNAV Procedure Coding Workshop 18

Data Record (6)

Layout – SID/STAR/App_2
Contains:
• Waypoint Descriptor
° Essential
° Fly-over waypoint
° Stepdown fix
° Pathpoint
° IAF/IF/FAF/FACFMAPt
° Holding
• Turn Direction
• Path and Termination
• Recommended Navaid
• Arc Radius
• Theta
• Rho
• Magnetic Course
• Route/Holding Distance/Time
• Altitude1, Altitude 2,
• Vertical Angle
 22-23 June 2005 RNAV Procedure Coding Workshop 19

Data Record (7)

Layout – Runway
Contains:
• Runway ID
• Runway Length
• Runway Magnetic Bearing
• Threshold Co-ordinates
• Runway Gradient
• Threshold Elevation
• Threshold Crossing Height
• Displaced Threshold Distance
• LOC/MLS/ILS Ref Path ID
• LOC/MLS/ILS Categroy/Class
• Runway Description
 22-23 June 2005 RNAV Procedure Coding Workshop 20

Data Record (8-29)

NDB Navaids GRID MORA
Localiser and Glide Slope/MLS/GLS Enroute Airways
Company Route Enroute Airways Restrictive
Localiser Marker Enroute Communications
Path Points Preferred Routes
Airport Communications Controlled Airspace
MSA
Airways Marker
Cruising Tables
FIR/UIR
22-23 June 2005 RNAV Procedure Coding Workshop 21

Design and Coding Issues

• Waypoint Classification
• Rho-Theta Values
• Recommended NAVAID
• Co-located VOR/DME
• Speed Restrictions
• Altitude Restrictions
• Waypoint, NAVAID and Fix
Coordinates
• Naming Conventions
• Path Terminator Concept
22-23 June 2005 RNAV Procedure Coding Workshop 22

Waypoint Classification
The enroute waypoint subsection file should contain all named
intersections defined in the enroute structure. As a minimum all
waypoints referenced in sections...... should be available in the
enroute subsection.

The terminal waypoint subsection file should contain those waypoints

necessary to support SIDs and STARs and approach procedures.

If a waypoint is used in both the terminal and enroute areas, it should

appear in both the terminal and enroute subsection file.

In order to achieve consistent coding, State sources must clearly

classify any multiple use of waypoints in the respective AIP sections.
22-23 June 2005 RNAV Procedure Coding Workshop 23

Rho-Theta Values
“Rho” is defined as the geodesic distance in miles to a
waypoint. Source: official government sources when available.

“Theta” is defined as the magnetic bearing to a waypoint.

Source: official government sources when available.

If a procedure leg requires Rho-Theta information e.g. from a

recommended navaid, it must be published in AIP.

The content is controlled through requirements of the path

terminators and coding rules contained in ARINC 424.
22-23 June 2005 RNAV Procedure Coding Workshop 25

Co-located VOR/DME
NAVAID file contains details of all VOR, VOR/DME, VORTAC and
TACAN stations within a geographical area of interest.

For VOR/DME and VORTAC facilities, if the identification code of

the VOR and DME components is the same, the DME identifier
will be blank.

If they are not the same, the DME identifier field will carry the
identification of the DME component.

According to ICAO Annex 10 co-located means that the latitude

and longitude of the two facilities differ by no more than 1/10 arc
minutes (6 seconds).

If either the latitudes and/or longitudes of a VOR and TACAN or

DME components of a frequency-paired VHF NAVAID differ by
1/10 arc minutes or more the character “N” needs to be
entered into column 32 on VHF NAVAID record (navaid
22-23 June 2005 RNAV Procedure Coding Workshop 26

Speed and Altitude Restrictions (1)

Speed Restrictions

The speed limit will be derived from official government source and
shown in knots on a SID/ STAR record.

On SIDs, the speed limit will apply to all legs up to and including the
terminator of the leg on which the limit is encoded from the
beginning of the procedure.

If a second speed limit is coded on a subsequent leg, the limit will be

applied from that leg backwards to the previous terminator which
contained a speed limit.

On STARs, the speed limit will be applied forward to the end of

arrival unless a second speed limit is encoded.
 22-23 June 2005 RNAV Procedure Coding Workshop 27

Speed and Altitude Restrictions (2)

According to ARINC 424 speed limitations can be coded in
different ways by using different path terminators. In order to
achieve consistency all speed restrictions in RNAV procedures
should be applied at specific waypoints.

Speed restrictions that are only applied during specific time periods
are not coded in database.

Some legacy systems can only process speed restrictions in

combination with an altitude restriction.

.
 22-23 June 2005 RNAV Procedure Coding Workshop 28

Speed and Altitude Restrictions (3)

Altitude Restrictions
The altitude description field will designate whether a waypoint
should be crossed “at”, “at or above” or “at or below” specified
altitudes.

The conditional termination altitude can be coded in columns 90 through 95

of the SID record. If a “+”, “-” or blank is coded in the altitude description
field, input of a second altitude must imply a conditional altitude
termination.

If a published take-off requires a turn greater than 15 degrees from the

runway heading without an altitude specified before the turn.....a CA, VA,
or FA on the runway heading to an altitude of 400 feet (or as specified by
source) must be coded before the turn or as first leg of the departure.
22-23 June 2005 RNAV Procedure Coding Workshop 29

Speed and Altitude Restrictions (4)

ARINC 424 provides a number of ways to code altitude

restrictions. For simplification and to avoid coding inconsistencies
altitude restrictions should be applied at waypoints wherever
possible.

Altitude restrictions in the terminal area that are only applied

during specific time periods will not be included in the airborne
database.
22-23 June 2005 RNAV Procedure Coding Workshop 30

Waypoint, Navaid and Fix Coordinates (1)

The geographic position of waypoints, intersections, navaids,

runway thresholds etc. is defined in the latitude/ longitude fields.

Nine alpha/numeric characters define the latitude in degrees,

minutes, seconds, tenth of seconds and hundredths of seconds:
N45562518

Ten alpha/numeric characters define the longitude in degrees,

minutes, seconds, tenth of seconds and hundredths of seconds:
E015523622.

This resolution reflects the airlines desire for the use of best
available data.
22-23 June 2005 RNAV Procedure Coding Workshop 31

Waypoint, Navaid and Fix Coordinates (2)

Aviation industry requirements for accuracy and resolution for
elected data elements.

These industry requirements represent the resolutions that can be used by the
various avionics systems.

Many numerical values used in describing procedures are

calculated values e.g. fixes, TMA entry or exit points etc.
22-23 June 2005 RNAV Procedure Coding Workshop 32

Waypoint, Navaid and Fix Coordinates (3)

The accuracy of calculated values is limited by the accuracy of the

values used in the calculation.

The designer should be aware of all the navaids that an aircraft flying a
certain procedure may use.

This includes navaids located in nearby TMAs or in neighbouring

countries. Special agreements with host countries may be required.

The navaid function and reliability and the consequences of navaid

outages need to be addressed during design (operating hours,
maintenance status, required flight checks, emergency power supply etc)
22-23 June 2005 RNAV Procedure Coding Workshop 33

ARINC 424 Naming Convention (1)

ICAO Annex 11 defines the international standards for the coded
designators of NAVAIDs, waypoints, airways, SIDs and STARs.

Track change points or turning points should be named and defined

by co-ordinates in the AIP.

ARINC 424 establishes coding rules for identifiers and name fields
when the government source does not provide identifiers or names
in accordance with Annex 11.

Example: ARINC naming rule for RNAV waypoints, intersections and

reporting points if the name/identifier is more or less than five
characters:

- if five or less characters, use the full name

- if more than five characters, eliminate double letters, keep the first
letter, first vowel and last letter, drop other vowels from right to left, drop
consonants, starting from right to left
22-23 June 2005 RNAV Procedure Coding Workshop 34

ARINC 424 Naming Convention (2)

Any planned deviation from the ICAO naming convention should be avoided.
Deviations create additional workload, cause misinterpretations and
encourage errors.

If required waypoints e.g. turning points are not named and defined by
coordinates in database, these points must be identified in an RNAV
database. The so called Computer Navigation Fixes (CNFs) will be created
by the datahouses. In certain cases, ATC is unaware that these fixes exist.

A serious safety problem can arise when a pilot needs to select a navaid
from the database by identifier and the database has multiple navaids with
the same identifier.
22-23 June 2005 RNAV Procedure Coding Workshop 35

The Path Terminator Concept (1)

The Path and Terminator concept was developed to permit coding of
terminal area procedures, SIDs, STARs and approach procedures
without proliferating the number of waypoints.

The two elements Path and Terminator prescribing the way in which a
path is to be flown and how the path is to be terminated.

Over the years and in particular with the introduction of RNAV new leg
types were added.

Currently, the ARINC 424 document describes 23 path terminators.

Certain limitations such as leg sequence or fly-by/ fly-over rules must be

considered by procedure designers.
Database suppliers must be accomplished using path/terminators most
appropriately reflecting the government source.
 22-23 June 2005 RNAV Procedure Coding Workshop 36

Summary and Conclusions (1)

ARINC 424 is an industry standard for the preparation and transmission of data
for the assembly of airborne navigation system data bases.

Each navigation element in the database is uniquely defined and stored in the master
user file and can be accessed for any intended navigation purpose.

Historically, the ARINC 424 document was developed to support conventional

navigation.

Most aeronautical data originates from state agencies and is published in AIPs.

RNAV airborne navigation systems are capable of using multiple sources of navigation
data and operating within very closely defined limits.

RNAV systems are dependent on the availability of accurate latitude and longitude
coordinates for lateral aircraft positioning.

A designer should not overlay RNAV procedures on existing conventional procedures.

22-23 June 2005 RNAV Procedure Coding Workshop 37

Summary and Conclusions (2)

Procedure Designers should be aware of the capabilities and performance
criteria of the aircraft flying the procedure.

Keep things simple. Complex solutions are difficult to validate and open to
misinterpretation.

Aircraft may use all navaids which are within the reception range.

Differences in avionics systems need to be considered during the

processing of aeronautical data.

The Path and Terminator concept was developed to permit coding of

terminal area procedures.

Database suppliers are committed to using the path/terminators that most

appropriately reflect the government source.

Although not developed for design of flight procedures, sufficient

background information about ARINC 424 will enable procedure
designers to perform their tasks so that misinterpretations and errors
are significantly reduced.
22-23 June 2005 RNAV Procedure Coding Workshop 38

QUESTIONS?