Databases, Configuration, and Loading

Article 01 made the point that an FMGEC's behaviour is only half software; the other half is data. The same computer with a different database set has a different personality — how accurate the predictions are, whether an approach may be flown in managed modes, which AOC functions exist. This article closes the architecture group by opening the FMGEC's data bay: the five databases, the three layers of "configuration", loading and crossloading, and what an out-of-date navigation database does and does not permit. The RNAV/RNP usage limits are developed in article 34 and the dispatch detail in article 32.

1. The data manifest

The FM will not run on an incomplete manifest. The mandatory loadable elements are the FMS operational software, the navigation database, the OPC file, the performance database and the magnetic variation database (the AMI and a flight-test file are loadable options — a default AMI is embedded in the operational software). Per AMM 22-70-00:

The following list gives the loadable elements that are necessary for normal FM operation. On either side, the FMS displays only the P/N STATUS pages and any MCDU mode key button push relative to the FMS is ignored as long as all the following loadable elements have not been correctly loaded

And a fact that surprises most crews — the FMS software does not know what aircraft it is in:

- FMS software: this software will be common to all Airbus aircraft families. Aircraft specificities (such as aircraft type or engine type identification) are indicated to the FMS via hardware program pins wired on the FMGC box,

The software is a fleet-common part; the airframe's wiring is its identity card. Replacing an FMGEC never involves "telling it this is an A330" — the rack's program pins already say so (the same philosophy as the MCDU's two identity pins in article 03).

2. The five databases

① Navigation database (NDB). Per AMM 22-00-00:

The navigation data base includes: - Airports and procedures, - Company routes, - Airways, - Navaids, - Waypoints, - Holding patterns, - Grid MORA (Minimum OFF Route Altitude).

The navigation data base can be updated every 28 days by a data loader as defined in ARINC 615.

Twenty-eight days is the AIRAC rhythm; a full load takes 20 minutes, a crossload from the opposite FMGEC 5 minutes (article 01). Each FMGEC holds its own set, independently loadable — which is precisely why "the two sides disagree" is a failure shape that exists (the mismatch gates in section 4, and one trigger of INDEPENDENT operation in article 19).

② AMI — the FM Airline Configuration file. Per FCOM DSC-22_10-10:

The Airline Modifiable Information (AMI), also decribed as the FM Airline Configuration file, contains: ‐ Airline policy values: THR RED altitude, ACC altitude, EO ACC altitude, PERF factor, and IDLE factor. ‐ Fuel policy values: Fuel for taxi, percentage of route reserve, maximum and minimum values of route reserve, etc. ‐ AOC functions customization.

Those default values that "just appear" — the thrust-reduction and acceleration heights on the PERF TAKEOFF page, the taxi fuel and route-reserve percentage on INIT B (article 30), the datalink function switches (article 28) — are all airline policy written into the AMI. Changing them is an engineering-department act, not a cockpit one.

③ Aircraft performance database (PDB). Per FCOM DSC-22_10-10:

The Aircraft Performance Database includes the Engine model, Aerodynamic model, and Performance model. The airline cannot modify this database.

And per AMM 22-70-00:

- Performance Data Base file: this database is no longer considered as part of the operational software in the objective of independent update and certification.

The PDB was deliberately carved out of the operational software so it can be updated and certified on its own. Keep the three-layer answer to "the FMS predictions are off": the models (PDB — untouchable), the coefficients (PERF/IDLE factors in the AMI — the airline's), and the inputs (wind, temperature, weight — yours). Article 25 builds prediction calibration on exactly this split.

④ Pilot-stored elements. Capacity is a vendor tell — 99 stored waypoints on the Thales FMS2, 20 on the Honeywell (article 01). Their lifetime is an AMI choice. Per AMM 22-00-00:

These specific data items are automatically cleared: - Either at the end of each flight, - When a new data bank is selected, depending on the airline choice (Airline Modifiable Information (AMI) file)

A source note worth teaching in its own right: the AMM's general chapter states the pilot can enter 20 waypoints, 20 navaids, 10 runways and 5 company routes manually — matching the Honeywell figure, not the Thales 99. The general chapter prints one number; only the configuration-specific FCOM page prints your number. When manuals disagree, the configuration page wins — the same lesson as article 01's three-step options check.

⑤ Magnetic variation database. Per AMM 22-70-00: - Magnetic Variation Data Base file: this database contains one magnetic variation model only. Its operational appearance is in article 34: a few degrees' difference between an MCDU track and the chart may simply be FMS magnetic variation versus chart magnetic variation — with no effect on the actual lateral path flown.

3. Three layers of configuration

"Configuration" on this aircraft means three different mechanisms. Per AMM 22-85-00:

The pin program consist in : - to determinate the aircraft or motorization versions, - to provide more possibilities for identification of FM performance models. - to active some functions (FM configurations).

For the new-generation FM, some of these functions can no longer be activated by pin programming, but they are activated by reading a soft file: OPC (Operational Program Configuration).

And per AMM 22-70-00: - OPC file: this database contains the software pin programs used to activate software options,

Now connect this to article 01's options matrix: most of those Yes/No lines are, physically, a bit in the OPC file (plus any required hardware). "FLS function in the FMS — No" does not mean an antenna was removed; it means the software option was never granted. Two airframes in one fleet can differ in installed functions by nothing more than a file version — which is why the FCOM GEN differences table splits Yes/No by airframe groups.

4. Loading and crossloading

Crossload (XLOAD) copies loadable elements from one FMGEC to the other. Per AMM 22-70-00:

The Cross-load function is available if all the following conditions are met: - No data-load operation is in progress or armed on the FMS, - The FMS source select switch is set to NORMAL if the aircraft is fitted with this switch, - Current flight phase is PREFLIGHT or DONE, - Aircraft is on the ground, - P/N discrepancy exists.

Note the last two conditions together: on the ground, in PREFLIGHT or DONE — there is no in-flight database change on this aircraft. All seven loadable elements can be crossloaded, item by item, from the P/N STATUS pages (START XLOAD, then CONFIRM; the side that presses START is the sender). While it runs:

During the processing, both FMS are effectively suspended and any MCDU FM mode key selection on either side is ignored and results in the display of the NOT ALLOWED scratchpad message.

The CROSSLOAD COMPLETE message is displayed in the scratchpad of both MCDUs at the end of the full crossload.

Compatibility is enforced by three gates — at power-up, before loading, before crossloading. Per AMM 22-70-00:

At power-up, if a mismatch of loadable elements is detected between the two FMS, both sides revert to the relevant P/N STATUS page.

Cross-load of data file elements cannot be initiated until the FM software of the two FM matches.

A failed transfer announces itself as XLOAD PROBLEM INFO with a reason. Step back and see the design intent: this version-consistency machinery is the ground-side prevention of exactly the condition the MEL refuses to dispatch — AUTO FLT FMGEC VERSIONS DISAGREE (article 01, article 32). The system is built to deny you the option of "making do" with two different standards.

What the crew sees while maintenance loads (awareness, from the AMM loading tasks): during a crossload the MCDUs show the amber IND light and INDEPENDENT OPERATION in the scratchpad — expected, the two FMs really are working separately; when both sides already match, the P/N page simply says FM1/FM2 IDENTICAL. A portable-data-loader upload runs about 12 minutes per complete component, and reloading the FM operational software obliges reloading everything else (NDB, AMI, OPC, PDB, magnetic variation — they are subordinate to it). Load media carry digital signatures: a wrong or corrupted signature blocks the upload and is reported to the operator's aviation-information-security focal point — the FMS is a cyber-security controlled item by design. And loading always ends with an FMGEC reset plus ground safety tests, including a BITE download window of about 5 minutes during which both FMGECs are unavailable — not the moment to press for release.

5. How far may you trust the database

The airworthiness approval of managed-mode approaches rests on an assumption: the database is good. The FCOM turns that assumption into requirements. Per FCOM LIM-AFS:

To fly an approach in lateral managed mode or lateral and vertical managed mode, the approach stored in the Navigation Database must be either: ‐ Produced by an approved supplier compliant with ED76/DO200A or DAT Type 2 requirements, or ‐ Validated and approved by the Operator.

To fly an RNAV(RNP) procedure (departure, approach, missed approach), the procedure stored in the Navigation Database must be both:

Read the conjunctions: ordinary managed approaches demand either pedigree or validation; RNAV(RNP) demands both. The higher the precision claim, the more the trust chain doubles up (article 34 carries the full limitation set).

6. Flying with an expired database

An expired navigation database is not "all wrong" — it has merely stopped guaranteeing agreement with reality. Some operators' MEL reflects that logic: dispatch is permitted for up to ten consecutive calendar days past expiry, under conditions that amount to line-by-line verification — procedures that the new cycle has changed must not be used from the expired database (unchanged ones may); database navaids and waypoints (coordinates, frequencies, status) and the facilities required for the intended route are checked against current aeronautical information (charts); and the entire PBN family is prohibited — RNP AR, RNP APCH, RNP 1/2/4, RNAV 1/2/5/10. The associated operational practice: coordinate with the operator's dispatch/operations control, check each intended procedure against the latest charts; where a procedure no longer matches, fly the conventional SID/STAR/approach with manually tuned navaids, and rebuild changed airway segments by inserting waypoints from current data.

Why the blanket PBN ban when individual procedures can be verified? Because section 5's airworthiness premise — a validated, current database — is exactly what expiry dissolves. Conventional navigation can fall back on raw data; PBN cannot.

Daily habit to build (synthesis): at every cockpit preparation, give the A/C STATUS page three looks — the active NDB cycle and validity window (especially when the second database spans the changeover), the engine/aircraft-type line (after component changes), and the IDLE/PERF factors (the thing to re-check after an FMGEC swap). If the database expires mid-trip, settle the changeover plan with dispatch before departure — section 4 already told you there is no changing it airborne.

[!warning]- Six misconceptions this article corrects (1) The FMS software doesn't know it's in an A330 — identity comes from hardware program pins on the rack; fleet-common software, airframe-specific wiring. (2) Poor predictions rarely mean broken software — check the three layers: PDB models (fixed), AMI factors (airline), your inputs (wind/temp/weight). (3) "FLS = No" removes no hardware — most options-matrix lines are bits in the OPC file; two airframes can differ by a file version. (4) There is no in-flight database swap — loading and crossloading require ground + PREFLIGHT/DONE. (5) An expired database is not all invalid — unchanged procedures verified against current charts remain usable; but PBN is barred outright because its approval premise (validated currency) is gone. (6) When the AMM general chapter and your configuration's FCOM page disagree (20 vs 99 stored waypoints), the configuration page wins — general chapters print one number, not necessarily yours.

Self-test

[!note]- Q1. Name the five databases. Which one can the airline not modify, and why was the PDB separated from the operational software?

Navigation database, AMI, aircraft performance database, pilot-stored elements, magnetic variation database. The PDB (engine/aero/performance models) is closed to the airline — and it was carved out of the operational software so it can be updated and certified independently.

[!note]- Q2. Who wrote the default THR RED/ACC altitudes that appear on the PERF TAKEOFF page — and who do you call to change them?

The AMI — the FM Airline Configuration file — carries the airline policy values (THR RED, ACC, EO ACC, PERF factor, IDLE factor) and fuel policy. Changing them is the airline engineering department's act, not a cockpit entry.

[!note]- Q3. What do the three configuration layers each decide, and which layer answers "FLS = No"?

Hardware pins: identity (aircraft/engine version, performance model, side). OPC: whether a software function exists. AMI: policy parameters for how functions behave. "FLS function in the FMS = No" is an OPC-layer fact — the software option is not activated.

[!note]- Q4. The five availability conditions for XLOAD — and what happens if you press F-PLN during a crossload?

No load in progress or armed; FMS source selector at NORMAL (if fitted); flight phase PREFLIGHT or DONE; aircraft on ground; a P/N discrepancy exists. During the transfer both FMS are suspended — any FM mode key returns NOT ALLOWED in the scratchpad.

[!note]- Q5. The two FMGECs carry different FM software versions — can you crossload the navigation database first? And what does the system do at power-up on a mismatch?

No — data-file crossload cannot start until the FM software of both sides matches: software first, then data. At power-up a detected mismatch drops both sides to the P/N STATUS pages, putting the problem in front of you.

[!note]- Q6. Day 8 past database expiry: may you fly an RNAV 1 departure? A conventional VOR approach unchanged by the new cycle?

RNAV 1 — no: the whole PBN family is prohibited on an expired database. The unchanged conventional approach — yes, provided it has been verified against current charts per the operator's procedure (changed procedures are barred; manual tuning covers the rest).

[!note]- Q7. The AMM general chapter says 20 pilot-stored waypoints; the Thales FCOM page says 99 — which is right for your aircraft?

The configuration-specific FCOM page. The AMM general text matches the Honeywell figure; on a Thales FMS2 airframe the answer is 99. General chapters give a number; configuration pages give your number.

Key takeaways

References

Database set and AMI/PDB definitions per FCOM DSC-22_10-10; navigation-database contents, 28-day ARINC 615 cycle and stored-element clearing per AMM 22-00-00; mandatory loadable elements, common-software/hardware-pin identity, OPC definition, crossload conditions and sequencing, suspension behaviour, and the mismatch gates per AMM 22-70-00 (Honeywell-configuration chapter, description common in substance); pin programming and OPC evolution per AMM 22-85-00; loading-task visibility (IND light, durations, signature control, post-load resets and BITE window) per the AMM 22-70-00 loading tasks. Database validation requirements per FCOM LIM-AFS. Expired-database dispatch reflects some operators' MEL practice (10-day allowance with verification conditions and PBN prohibition) — operator-specific, verify your own. The three-layer configuration table and the expiry logic narrative are integrative syntheses of the sources above. Maintenance-layer loading procedure steps are intentionally excluded.

Independent study material, not an Airbus publication and not endorsed by the manufacturer. Always defer to the current operator FCOM, FCTM, and QRH for operational use.