15.1 Flight Management System and Control Display Unit

15.1 Flight Management System and Control Display Unit

Current Appendix I gives only the broad 5.15 heading and level 1 for every licence category. The pre-12 June 2024 detailed description named the Flight Management System (FMS) among its typical systems, so this section uses FMS as a representative study example. Level 1 is familiarisation: a certifying technician must recognise the general arrangement, the role of the Control Display Unit (CDU) or Airbus Multipurpose Control Display Unit (MCDU), and the associated Built-In Test Equipment (BITE). This section stays at that depth. It does not retell Chapter 12's software-classification and data-loading theory, but it does show why the navigation database is a controlled load whose effectivity must be confirmed before dispatch.

General arrangement of the FMS

A transport-category FMS is almost always a dual installation, and some types add a third computer. Each Flight Management Computer (FMC) is a software-loaded Line Replaceable Unit (LRU) on the avionics data buses — commonly ARINC 429 on older fleets and AFDX/ARINC 664 on later integrated architectures. The FMC is the navigator and performance computer. Typical inputs include:

• present position, track and ground speed from the Inertial Reference System (IRS) or, on many types, the inertial channel of an air-data/inertial unit;
• satellite position, velocity and time from the Global Positioning System (GPS) receiver named in 5.15;
• air data (pressure altitude, Mach, true airspeed, temperature) and fuel quantity or fuel-flow from the fuel system;
• selected radio-navaid data (VOR, DME, ILS) for autotuning and, on older installations, radio updating of position.

Typical outputs are lateral navigation (LNAV) and vertical navigation (VNAV) commands to the flight director and autopilot, a map and flight-plan overlay on the EFIS navigation display, predicted times and fuels, and fault or status words to the central maintenance computer. Cross-talk between left and right FMCs keeps the active plans identical. A persistent mismatch is annunciated so the crew can isolate a failed computer — the same dual-channel idea already met in Module 5 computer-structure topics.

The CDU/MCDU is the human interface, not the navigator. Each pilot station has a unit. Entries are typed into a scratchpad and inserted with line-select keys. Function keys open pages such as INIT, F-PLN, DIR, PERF, RAD NAV and PROG on an Airbus MCDU, or RTE, LEGS, DEP/ARR, VNAV, HOLD and INIT REF on a Boeing CDU. On Airbus types the MCDU is genuinely multipurpose: besides flight management it can present centralised fault-display pages, ACARS and other selected systems, which is why a technician in the hangar may use the same box the crew used in flight. On Boeing types a dedicated CDU is usual, with maintenance access through IDENT/MAINT pages or a separate central maintenance computer.

[!NOTE] Replacing a CDU or MCDU restores the keyboard and display. It does not load a new navigation database. The operational program, navigation database and performance database reside in the FMC (or in the hosted FMS partition of an integrated modular cabinet).

Flight plan and performance

The active flight plan is a time-ordered sequence of legs. A complete company route typically contains the origin airport and departure runway, a Standard Instrument Departure (SID) with its speed and altitude constraints, en-route waypoints or airways, a Standard Terminal Arrival (STAR), the instrument approach including missed-approach legs, and the destination runway. An alternate may sit in a secondary plan.

The FMC builds each leg from the navigation database — industry coding follows the ARINC 424 template — plus crew modifications such as a direct-to, a hold, a lateral offset or a waypoint speed/altitude/time constraint. It then computes track, distance, estimated time of arrival and fuel remaining. When VNAV is used, it also builds a vertical path that honours those constraints. RNAV legs do not have to overfly a ground beacon; they require a valid FMS position, which on current types is a hybrid of inertial and GPS data.

Performance initialisation is a separate crew task on the PERF or INIT pages: zero-fuel weight, centre of gravity, block fuel, cruise flight level, cost index, reserves, and forecast winds and temperatures. From the performance database — a type-specific aerodynamic and engine model, not the 28-day navigation file — the FMC predicts take-off and approach speeds, climb/cruise/descent profiles and fuel at destination. Wrong weights produce wrong speeds. That is an operational data error, not evidence that the FMC hardware has failed.

On many Boeing installations a modification sits in a pending state until the crew presses EXEC; Airbus insertions are typically immediate on the line-select. Technicians do not need those type details as a memory list, but they must recognise that an FMC with a healthy IDENT page and a crew-reported 'wrong routing' is more often a data or procedure issue than a blank CDU.

Navigation database effectivity and software control

World-wide aeronautical data are issued in 28-day AIRAC (Aeronautical Information Regulation And Control) cycles. Each navigation database cartridge, data-loader file or datalink package is labelled with an effectivity window — start and end UTC dates. An expired or not-yet-effective database can display withdrawn SIDs, missing runways or incorrect navaid frequencies, so operators treat effectivity as a dispatch item.

This is the contact point with Chapter 12 (Software Management Control) without repeating that chapter. The navigation database is loadable software/data. It has a part number, a media identity and an integrity check applied at load. Loading an unapproved, expired or corrupted database is an unapproved software change in the 5.13 sense: the crew may be given a plausible procedure that is wrong. The technician therefore:

1. confirms that the FMC operational-program part number matches the approved aircraft configuration;
2. loads only the operator-authorised navigation-database media for the current AIRAC cycle;
3. reads IDENT or NAV DATA pages to verify database name, part number and effectivity dates;
4. runs the required BITE or status check and records the load in the technical log.

The performance database does not follow AIRAC. It changes when the airframe or engine model changes (thrust rating, wingtip devices, flap or speed schedules). Left and right FMC operational programs must be a matched pair. Mixing software standards is a configuration-control defect, not a cockpit convenience.

Associated BITE

Power-up self-test of the FMC and of each CDU/MCDU is standard. Continuous monitoring watches bus inputs (IRS, GPS, air data, fuel) and internal memory. Maintenance pages list current faults, database identifiers and input validity. A CDU TEST illuminates keys and checks the display; FMC BITE reports to the Central Maintenance Computer (CMC) or Centralised Fault Display System (CFDS). A useful diagnostic pattern:

• one blank CDU with the opposite unit live points at that CDU or its interface;
• both CDUs blank, or identical FMC faults on both sides, point at the computer, its power or the data load;
• FMS position disagree with a healthy IDENT page points at a sensor (IRS/GPS) rather than the CDU.

Level 1 does not require a type-rating of every MCDU page. It does require you to know which box computes, which box displays, which file is on a 28-day cycle, and how BITE plus IDENT pages prove that a load was the approved one.