Airborne Navigation Databases (Part Three)

Path and Terminator Limitations

How a specific RNAV system deals with Path and Terminators is of great importance to pilots operating with airborne navigation databases. Some early RNAV systems may ignore this field completely. The ILS or LOC/ DME RWY 3 approach at Durango, Colorado, provides an example of problems that may arise from the lack of path and terminator capability in RNAV systems. Although approaches of this type are authorized only for sufficiently equipped RNAV systems, it is possible that a pilot may elect to fly the approach with conventional navigation, and then re-engage RNAV during a missed approach. If this missed approach is flown using an RNAV system that does not use Path and terminator values or the wrong leg types, then the system will most likely ignore the first two legs of the procedure. This will cause the RNAV equipment to direct the pilot to make an immediate turn toward the Durango VOR instead of flying the series of headings that terminate at specific altitudes as dictated by the approach procedure. [Figure 6-28]

Pilots must be aware of their individual systems Path and Terminator handling characteristics and always review the manufacturer’s documentation to familiarize themselves with the capabilities of the RNAV equipment they are operating. Pilots should be aware that some RNAV equipment was designed without the fly-over capability which can cause problems for pilots attempting to use this equipment to fly complex flightpaths in the departure, arrival, or approach environments.

Role of the Database Provider

Compiling and maintaining a worldwide airborne navigation database is a large and complex job. Within the United States, the FAA sources give the database providers information, in many different formats, which must be analyzed, edited, and processed before it can be coded into the database. In some cases, data from outside the United States must be translated into English so it may be analyzed and entered into the database. Once the data is coded, it must be continually updated and maintained.

Once the FAA notifies the database provider that a change is necessary, the update process begins. The change is incorporated into a 28-day airborne database revision cycle based on its assigned priority. If the information does not reach the coding phase prior to its cutoff date (the date that new aeronautical information can no longer be included in the next update), it is held out of revision until the next cycle. The cutoff date for aeronautical databases is typically 21 days prior to the effective date of the revision.

The integrity of the data is ensured through a process called cyclic redundancy check (CRC). A CRC is an error detection algorithm capable of detecting small bit-level changes in a block of data. The CRC algorithm treats a data block as a single, large binary value. The data block is divided by a fixed binary number called a generator polynomial whose form and magnitude is determined based on the level of integrity desired. The remainder of the division is the CRC value for the data block. This value is stored and transmitted with the corresponding data block. The integrity of the data is checked by reapplying the CRC algorithm prior to distribution.

Role of the Avionics Manufacturer

When avionics manufacturers develop a piece of equipment that requires an airborne navigation database, they typically form an agreement with a database provider to supply the database for that new avionics platform. It is up to the manufacturer to determine what information to include in the database for their system. In some cases, the navigation data provider has to significantly reduce the number of records in the database to accommodate the storage capacity of the manufacturer’s new product, which means that the database may not contain all procedures.

Another important fact to remember is that although there are standard naming conventions included in the ARINC 424 specification, each manufacturer determines how the names of fixes and procedures are displayed to the pilot. This means that although the database may specify the approach identifier field for the VOR/DME Runway 34 approach at Eugene Mahlon Sweet Airport (KEUG) in Eugene, Oregon, as “V34,” different avionics platforms may display the identifier in any way the manufacturer deems appropriate. For example, a GPS produced by one manufacturer might display the approach as “VOR 34,” whereas another might refer to the approach as “VOR/DME 34,” and an FMS produced by another manufacturer may refer to it as “VOR34.” [Figure 6-29]

These differences can cause visual inconsistencies between chart and GPS displays, as well as confusion with approach clearances and other ATC instructions for pilots unfamiliar with specific manufacturer’s naming conventions. The manufacturer determines the capabilities and limitations of an RNAV system based on the decisions that it makes regarding that system’s processing of the airborne navigation database.

Users Role

Like paper charts, airborne navigation databases are subject to revision. According to 14 CFR Part 91, § 91.503, the end user (operator) is ultimately responsible for ensuring that data meets the quality requirements for its intended application. Updating data in an aeronautical database is considered to be maintenance and all Part 91 operators may update databases in accordance with 14 CFR Part 91, § 43.3(g). Parts 121, 125, and 135 operators must update databases in accordance with their approved maintenance program. For Part 135 helicopter operators, this includes maintenance by the pilot in accordance with 14 CFR Part 43, § 43.3(h).

Pilots using the databases are ultimately responsible for ensuring that the database they are operating with is current. This includes checking Notices to Airmen (NOTAM)type information concerning errors that may be supplied by the avionics manufacturer or the database supplier. The database user is responsible for learning how the specific navigation equipment handles the navigation database. The manufacturer’s documentation is the pilot’s best source of information regarding the capabilities and limitations of a specific database. [Figure 6-30]

Flight Literacy Recommends