RECORDING, FAULT MEMORY AND CROSS-SYSTEM DIAGNOSIS
Recorded maintenance information is a different product from the warning presented during flight. In the supplied CFDS architecture, system built-in test equipment feeds the Centralized Fault Display Interface Unit, which supports MCDU reports and printing. Its in-flight reporting mode and on-ground interactive mode serve different tasks. The wider maintenance/recording architecture also identifies a digital flight-data recorder and interface, with optional quick-access and condition-monitoring equipment. A preserved fault occurrence, the present system state and a recorded parameter history are distinct evidence; clearing an ECAM line does not repair the initiating condition. [98, PDF pp. 2–8] [87, PDF pp. 215–217]
A useful failure account follows a resource and information chain. For example, loss of a normal electrical source can reconfigure buses, remove consumers and change control capability. Loss of bleed supply can affect conditioning and other pneumatic users; a hydraulic quantity loss can remove actuation despite an available electrical control. A sensor fault can leave power and actuators healthy while invalidating the command/reference used by multiple systems. Identify the initiating event and the dependencies rather than counting every downstream message as an unrelated failure. [62, PDF pp. 10–15] [67, PDF p. 2] [71, PDF pp. 2–7] [65, PDF pp. 3–5]
The Fenix product’s failure and working-circuit-breaker claims establish substantial implemented scope, but they do not make every real maintenance test or reset a supported cockpit procedure. Use the documented failure interface and applicable procedure for the actual scenario. Reset policy and operational decisions are addressed separately in this companion. Repeatedly changing several systems at once destroys the ability to relate a response to its cause and can remove useful evidence. Preserve the last understood configuration, exact messages, source selection and the action that preceded the first unexplained state. [1, Current product scope: failures and circuit breakers] [86, Failures Guide; available management interface] [88, ECAM philosophy; action and resulting state]
The coverage matrix is part of that evidence record. It identifies the source mechanism, airframe/equipment scope, known developer confirmation and implementation details not established by the available evidence. A real-aircraft architecture explanation remains useful when it is honestly labelled; a simulated function becomes stronger evidence when it can be reproduced in the named build. This approach gives the Pro Companion depth without pretending that a combined set of older manuals constitutes one universally current airframe. It also leaves a clear place for later verified observations to refine the system description. [70, Documented configuration/effectivity register] [83, Dated24–25 October 2026 implementation snapshot] [87, Front matter, September 1998 informational scope]