5 Intro to ARINC424

22-23 June 2005 RNAV Procedure Coding Workshop 1

Introduction to ARINC 424

Amsterdam22-23 June 2005


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.


Flash Back (2) Purpose of ARINC Specifications1. 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.


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.


ARINC 424 - is a standard for the preparation and transmission of data for assembly of airborne navigation system data bases

ARINC 424 – a Specification for 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


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.

Aeronautical Data Processing Steps


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 8Navigation 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


Geographical Area Codes


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.


Master Airline User file

Alternative paths to individual master airline files


Data Record (1) Layout – VHF

NAVAIDContains:

• customer/area code,

• station identifier,

• navaid name,

• co-ordinates,

• frequency,

• elevation (DME),

• variation,

• datum code etc.


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


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


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.


Data Record (5)Layout – Gate

Contains:• Airport Identifier• Customer Area Code• Gate Identifier• Latitude• Longitude• Notes etc.


Data Record (6)Layout –

SID/STAR/App_1Contains:• 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.


Data Record (6)Layout –

SID/STAR/App_2Contains:

• 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


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


Data Record (8-29)NDB Navaids

Localiser and Glide Slope/MLS/GLS

Company Route

Localiser Marker

Path Points

Airport Communications

MSA

Airways Marker

Cruising Tables

FIR/UIR

GRID MORA

Enroute Airways

Enroute Airways Restrictive

Enroute Communications

Preferred Routes

Controlled Airspace


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


Waypoint ClassificationThe 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.


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.


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 class).


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 27Speed 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 28Speed and Altitude Restrictions (3)

Altitude RestrictionsThe 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.


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.


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.


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.


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)


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 34ARINC 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.


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.


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.


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.


QUESTIONS?

5 Intro to ARINC424

Documents

Transcript of 5 Intro to ARINC424