PIREP

Editor’s Note: The series title highlights the inspiration for each article: every issue covered was reported to Honeywell by a pilot. The series looks at the things a system can’t do, either because of procedure design, database coding, the FMS, or physics. The hope is that pilots will begin to recognize and understand these limitations.

Curious why certain details of a charted procedure differ from those in the electronic navigation database (NDB)? And what about charted procedures that aren’t available for retrieval in the NDB at all. This article will discuss the particular nuances of converting published charts into the database file used by the FMS, and how the aforementioned issues can present themselves to a crew.

A two-step process exists to code a procedure for use in a NDB. First, the Aeronautical Information Publication (AIP) text and charted procedure must be translated into ARINC-424 text files using strict formatting standards (lines of 132 alphanumeric characters) by commercial data supplies such as Jeppesen, LIDO, etc. Then, Honeywell packing software is used to compile and convert these ARINC-424 files into binary datasets that are tailored to a specific FMS for loading.

It is the strict standards of ARINC-424 file conventions that allow for safe and successful translation from charted data to the NDB for FMS loading. It is also what prevents portions of a procedure (or even entire procedures) that cannot be accurately described using ARINC-424 standards from being included in the NDB.

Examples

The VOR Rwy 25L approach at EDDF/FRA (Figure 1) is an example of a procedure that should not be retrievable in the NDB; it has a turn inside the final approach fix (FAF) that is not a step-down fix and not the end of a radius-to-fix (RF) leg. Since ARINC has not established rules for these types of fixes, they cannot be coded into the ARINC-424 text files using present convention. As such, the procedure will not be included in the NDB for retrieval in the FMS. In this instance, the approach would have to be flown using conventional navigation.

Copyright Jeppesen, Inc. - Used by Permission - Not for Navigation

This next example, if one does not thoroughly brief the SID, can result in the dreaded query from ATC to “say airspeed”. The GLDMN5 RNAV Departure (Figure 2) has a max speed associated with a fix as well as a max speed associated with an altitude (dependent on which fix the flight is filed over).

The speed restriction associated with the fix MASTT (Figure 2 & Figure 3) is codable because AIRINC-424 standards can accept a speed limit associated with a specific fix. The restriction associated with the fix will be shown on the FLT PLAN page (Figure 4). The AIRINC-424 database standard cannot, however, accept a speed limit associated with an altitude (in this example “Traffic filed over BIGGY, ELIOT, LANNA, NEWEL, PARKE, ZIMMZ do not exceed 250 KT until reaching 11000.”)

Figures 2 & 3 Copyright Jeppesen, Inc. - Used by Permission - Not for Navigation

One technique for this departure would be to switch from FMS Speeds to Manual Speeds and set 250 KT upon passing MASTT and then switch back to FMS Speeds upon reaching 11,000 ft. Another technique is setting the climb SPD/ALT LIM on the PERFORMANCE INIT page to 250/11000. Understanding the types of speed restrictions that can and cannot be coded into the NDB will help you to better setup and brief these types of departure procedures.