The failure cases are the architecture read backwards, and the syllabus asks for the implications of each:
Failure of one FMC — the other computer carries the whole job: navigation, plan and predictions survive on the healthy side, but the redundancy is gone, both pilots now depend on one computer, and its outputs deserve closer monitoring for the rest of the flight.
Failure of one CDU/MCDU — the computers are healthy but one pilot’s window into them is dark: entries and checks run through the remaining unit, single-keyboard, with the workload and cross-checking reshuffled accordingly.
Failure of the cross-talk bus — both sides live, but they stop agreeing: each FMC runs independently on its own inputs, and small disagreements in position and predictions can grow unnoticed. The implication is vigilance about which side is coupled to the automatics, and deliberate comparison between the two sides where the bus used to compare for free.
Integration
The FMS is the course’s great integrator: it gathers data from the aircraft’s other systems and returns outputs whose reach depends on the installation’s complexity. In come the air data of module 2, the inertial and radio positions of module 5, fuel and engine data, and the crew’s entries; out go the map and predictions on the displays, and, on the more capable installations, the steering and speed targets that LNAV, VNAV and the autothrust fly. A simple installation may only navigate and display; a full one manages the flight.
The syllabus names three functions the FMS may provide:
navigation — knowing the position, the next lesson’s subject in depth.
lateral and vertical flight planning — the route and the profile, held as a plan the automatics can fly.
performance parameters — the speeds, altitudes and fuel figures computed from the databases this lesson turns to now.
The navigation database
The navigation database is the FMS’s stored world: waypoints, airways, radio navigation aids with their frequencies and positions, airports and runways, and the coded departure, arrival and approach procedures, everything the flight plan is built from. Its currency is managed on the 28-day aeronautical information regulation and control (AIRAC) cycle, the worldwide rhythm on which navigation data changes. The FMS therefore carries two navigation databases, one active and one standby: the next cycle is loaded ahead of its effective date and waits as the standby, and on swap day the crew activates it. The implication for the pilot is the date check that begins every pre-flight set-up: confirm the active database’s validity period covers today, and swap deliberately, on the ground, when it does not.
On top of the stored world the crew can define waypoints of their own, and the syllabus lists the typical user-defined waypoint forms:
a raw latitude/longitude position.
place/bearing/distance (PBD) — a point at a bearing and distance from a known place.
place-bearing/place-bearing (PBX) — the intersection of two bearings from two places.
place/distance (PD) — the point on the route at a distance from a place.
Two protections guard the stored world. First, the pilot cannot change or overwrite any data in the navigation database: user-defined waypoints live alongside the database, never inside it. Second, the boundary at activation: activating a different database erases the user-defined waypoints, routes and entered data, which is why the threats of changing the database in error are taken seriously in both places it can happen. On the ground, an erroneous swap wipes the entries and, if the wrong cycle ends up active, quietly builds the flight on out-of-date procedures. In flight, the same action erases the active flight plan under an aircraft that is following it: navigation reverts to raw sources while the plan is rebuilt by hand, exactly the workload nobody wants airborne.
The second database describes the aircraft itself: the aircraft performance database holds the aerodynamic model and the engine model, the speed schedules, and the aircraft’s limits: drag as a function of configuration, thrust and fuel flow as functions of the engine’s state, climb, cruise and descent speeds, weight and altitude limits. Every performance figure the FMS ever shows is computed from this description, which makes its identity critical: the pilot must verify the database is based on the correct data, the right engine type and the right aircraft variant, because a description of the wrong aeroplane computes confident numbers for an aircraft that is not the one flying. And like its navigation sibling, the contents cannot be modified by the pilot.
Two tuning knobs sit on top of the fixed description. The performance factor corrects the model to the individual airframe: engines and airframes age, real fuel burn drifts away from the book, and the operator’s monitoring distils the drift into a factor that adjusts the fuel and performance calculations to match the aircraft as it actually is. The cost index (CI) tunes the economics: it is the ratio of the cost of time to the cost of fuel, and it shapes the speeds the FMS computes. A cost index of zero says fuel is everything: fly slow, burn least. A high cost index says time is everything: fly fast, spend fuel to save minutes. The airline picks the number; the FMS turns it into the economy speeds it targets.