The Example Of Navigation Database

Published Date: 02 Nov 2017

prerequisites for replacing the existing interchange standard with the XML-

based standard are discussed. The advantages of such turnabout, the hard-

ware constraints associated with the usage of the new standard and the ability

to overcome these constraints using binary encoding are important points of

this chapter.

2.1 Flight Management System

Flight Management System (FMS) and airplane ight systems associated

with it are the fundamental navigation tools for modern commercial air-

planes. FMS provides functionality in eight key areas: airplane performance,

ight planning, Lateral NAVigation (LNAV), pre-ight initialization, radio

tuning, route planning, thrust management, Vertical NAVigation (VNAV)

[43]. In order to perform all these functions, FMS has to interact with some

other avionic systems. The implementation of these interfaces may vary be-

cause of the various aviation markets they are intended to serve but generally

it will fall into the categories shown on Figure 2.1. Each FMS consists of

two basic entities: Flight Management Computer (FMC) and Control Dis-

play Unit (CDU). The FMC is the core unit which manages and processes

all subsystems of the FMS whereas the CDU is the pilot's interface to FMC

(see Figure 2.2) [43].

6

Figure 2.1: Typical FMS Interface Block Diagram. Source: own diagram

based on [43].

The FMC was _rstly introduced with the Boeing 767 aircraft in the early

1980s [9]. Typically, the FMC contains the basic Operational Flight Plan

(OFP) and three databases [1]

_ Software options database { activates company-speci_c functionality

contained in the OFP that is required by the operator.

_ Model and engine performance database { holds all the performance

data such as vertical speeds, minimal and maximal speeds in climb,

fuel consumption etc., which allows the FMC to compute, for example,

fuel burn or optimum altitudes and airspeeds.

_ NDB { contains information necessary for building a ight plan and

processing that plan during the ight, in particular, runways, airports,

airways, waypoints/intersections, holding patterns, Standard Termi-

nal Arrival (STAR), Instrument Approach Procedure (IAP), Standard

7

Instrument Departure (SID), and radio navigation aids. NDB is the

subject of interest in this chapter and other parts of the thesis as well.

All three databases are stored on Electrically Erasable Programmable Read-

Only Memory (EEPROM) and may be updated via a data loader.

Figure 2.2: Control Display Unit. Source [1]

2.2 NDB: Structure and Data Transfer

The structure of a typical NDB is divided into several levels each containing

di_erent types of information. This layering structure is shown on Figure

2.3. The highest level (1) accommodates Flight Plans (FP), also called com-

pany routes { the information about route, estimated ight time, alternate

airports, estimated fuel needs, etc. speci_ed in a unique sequence [43]. The

second level (2) includes route information such as airways, SIDs, STARs

and approaches. The next down level (3) includes geographical _xes and

navigational aids on the surface of the earth. At the very bottom of the

structure there are some individual database elements performing di_erent

types of functions [2].

Each NDB comprises permanent, supplemental and temporary data. For

8

example, the permanent database includes waypoint, navigational aid, air-

port and runway. It cannot be modi_ed by the crew. Supplemental data

is entered on the ground and stored inde_nitely. It can be manipulated by

the crew. All existing supplemental data has to be checked by both crew

members before the ight for completeness and accuracy. Temporary data is

erased automatically after the ight is _nished [1].

Figure 2.3: Navigation Database Structure. Source: own diagram based on

[2].

The preparation and transmission of airborne navigation system database

are regulated by ARINC (Aeronautical Radio, Incorporated) 424 speci_ca-

tion which was _rst introduced in 1975 [10] as a support for conventional

navigation. The standard outlines also the content to be included into the

NDB for each speci_c navigation entity (for example, airports, airways, nav-

igational aids, approaches) as well as the encoding format for that data and

designating conventions. The speci_cation has been constantly improved and

adjusted over the years in order to be compatible with new standards, in-

9

creased capabilities of equipment, technical characteristics and navigational

procedures. Some aircraft FMCs operate with databases built under supple-

ment 11, while others may use various supplements 12-17 [33]. The newest

supplement is ARINC 424-20 launched in December 2011 [11]. Supplement

424-21 is currently under development. NDB in ARINC 424 format accom-

modates ten geographical zones each designated with a 3-letters code (Table

2.1).

Geographical Zone Code

Africa AFR

Middle East MES

Canada CAN

Paci_c PAC

Eastern Europe EEU

South America SAM

Europe EUR

South Paci_c SPA

Latin America LAM

United States of America USA

Table 2.1: ARINC 424 Geographical Zones. Source: [5]

Navigation information included in the NDB is organized into ARINC

424 records which make up complex descriptions of each navigation entity.

These records have a _xed length of 132 ASCII symbols. Not all of the 132

character positions have to be used for each record; some of them are left

blank to allow similar information to appear at the same positions of di_er-

ent records, and others are reserved in case of the necessity of future record

expansion [38].

There are three primary commercial companies in the world providing, main-

10

taining and updating a worldwide NDB encoded into ARINC 424 format:

the European Aeronautical Group located in United Kingdom and owned by

NavTech, LidoFMS in Switzerland owned by Lufthansa Systems and Jeppe-

sen Sanderson in the United States owned by Boeing [33]. The navigation

data is collected from the Aeronautical Information Publications (AIP) of

each member of the International Civil Aviation Organization (ICAO). This

data is updated via a 28-day single Aeronautical Information Regulation and

Control (AIRAC) cycle described at greater length in a speci_c ICAO doc-

ument [33].

As soon as the NDB is updated by primary commercial providers, the master

data _le in ARINC 424 format is sold to the avionics manufacturers produc-

ing ight management computers. These manufacturers then pack the data

in their own branded format, to function in their speci_c FMC. As di_er-

ent commercial airlines may have contracts for NDBs with any of the three

primary data providers, each FMC producer must have three di_erent data

sets [33]. For example, Thales has its FMCs installed in the Airbus 340 se-

ries aircraft [12] but, depending on the airline, it may have to provide Lido

NDB for Lufthansa, Jeppesen NDB for Delta and EAG data sets for Cathay

Paci_c [13]. The NDB data-transferring process is illustrated in Figure 2.4.

Figure 2.4: ARINC 424 NDB Processing. Source: own diagram based on [3].

2.3 Issues of ARINC 424 Speci_cation

The NDB processing model represented in Figure 2.4 illustrates two major

issues. The _rst of them concerns the fact that airlines operating various

11

aircrafts and data integrators have to deal with a signi_cant amount of dif-

ferent NDB packages, which are delivered and updated every 28 days. This

issue requires signi_cant logistic e_orts and costs. The second problem with

the current model is restricted NDB capacity on most FMCs [33]. Over the

years, the amount of available navigation data has grown exponentially and

not all FMC manufacturers were able to keep up with extended database

sizes. Many of the hardware limitations of older systems have resulted into

limited data storage capacity and put avionics producers and individual air-

lines into a situation where they have to make a decision about what type

of data should be extracted from the ARINC 424 master _le and included

into their system. Even some modern FMCs with increased NDB capacity

are not capable to accommodate all the data that is available from primary

database providers. The manufacturers often choose not to include some

types of data which they consider as not being relevant or useful for their

systems, and airlines later-on may decide to exclude certain data depending

on their operation area and route structure [38].

2.3.1 NDBX Concept

In 2006, the Airlines Electronic Engineering Committee(AEEC), through

the initiative of Lufthansa German Airlines, started the project intended to

solve the issues mentioned above. This project obtained the name \Naviga-

tion Data Base Open Standard" (NDBX) [38]. It is based on the idea that

navigational data should be initially prepared in the XML format and con-

verted afterwards into binary XML for smaller size and easier parsing. Such

approach would de_ne an open standard database which is readable by any

FMC without additional conversion. In other words, the roles of the data

supplier and the data integrator are combined; hence, airlines will be exempt

from the need to communicate with both entities [38]. The NDBX concept

is illustrated in Figure 2.5.

In order to minimize the size of the NDBX package, it was decided to restrict

NDBX records to data required by FMC only. It means that, for example,

ight planning or simulation records are not covered. Such an approach

has its drawback as FMC vendors have di_erent opinions on what is \FMC-

required data" [38]. Another issue is the fact that the NDBX concept creates

the second exchange standard for navigation data with quite a few elements

di_ering from the ARINC 424 standard. This would force the avionic indus-

try to manage two parallel lines of development and documentation for the

12

same data [38].

Figure 2.5: NDBX Data Transmission. Source: own diagram based on [38].

2.3.2 ARINC 424A Concept

In 2008 [14], AEEC has made a decision to merge both ARINC 424 and

NDBX in order to combine the advantages of both speci_cation and, in par-

allel, to solve the issues caused by NDBX. This e_ort is still in development

under the working title ARINC 424A \Navigation Database Standards" [38].

Whereas ARINC 424 and NDBX standards involve only one output format

each (ASCII representation and Binary XML representation respectively),

the ARINC 424A concept implies three output formats. It adopts both for-

mats comprising ARINC 424 and NDBX and introduces, as a third format,

XML containing the full 424 content instead of only the FMC-required data

[38]. The data ow process for the ARINC 424A concept is shown on Figure

2.6. Such an approach enables three di_erent scenarios of data transmission

between the data supplier and the FMC.

_ The _rst scenario simply reproduces the current data ow. One of

three primary data suppliers provides navigational data in ASCII for-

mat which is later-on converted into proprietary binary format by the

data integrator. In this case, no changes are required for any partici-

pant [38].

_ The second option implies that the data supplier provides navigation

data in XML format which is again converted later-on into a speci_c

binary format by the data integrator. The important advantage of this

approach is that the XML format is generally much easier to change or

13

to extend than _xed-length ASCII data. At the same time, the FMC

data formats remain unchanged [38].

_ Data ow suggested by the third scenario is, in principle, identical to

the one suggested by the NDBX concept. The primary data supplier

provides data in the binary XML format which is loadable directly into

the FMC, thereby the role of the data integrator is eliminated [38].

Figure 2.6: ARINC 424A Data Transmission. Source: own diagram based

on [38].

2.4 Conclusion

While the ARINC 424A speci_cation suggests the XML format as an alter-

native or substitute to current in-use ASCII representation of NDB data,

other working groups [15] are de_ning new concepts that would allow the

exchange of additional data in XML format, for instance, terrain, obstacles

or airport mapping data.

Although using the XML ensures numerous bene_ts for the aviation industry

such as easier extensibility and exibility of data, the format also brings cer-

tain drawbacks. XML is very verbose and requires additional physical space

and computational resources for data parsing while the CPU performance,

storage and datalink bandwidth are severely restricted for avionic hardware

[36]. Although both NDBX and ARINC 424A speci_cations suggest binary

14

encoding of XML data as a method of coping with these restrictions, at the

moment, no agreements exist relating to the single standard for binary XML

format.

15