DESIGN A FAILURE EXERCISE THAT CAN ANSWER A QUESTION
Start with a testable objective: recognise a particular state, make a defined decision or follow a specified recovery path. Establish the aircraft, loaded options, mass, fuel, weather, route, initial modes and panel state before arming a failure. Keep the relevant current procedure available and define the point at which the scenario will be stopped or repeated. This is an author-proposed training design using the documented Fenix controls. It avoids treating a random collection of alerts as evidence that the entire system model has been assessed. [127, Manual and random failures; interface scope] [61, Panel-state application and initial-state transition]
The documented manual interface distinguishes immediate failure from an armed condition. Its available conditions include indicated speed, altitude above mean sea level, an event and elapsed time. Those references matter: an AMSL altitude is not a height above the runway. Where conditions can be combined, establish the actual logic and confirm which were met at the trigger. Read the Armed and Failed states after the event. A scenario that did not trigger at the intended point cannot be used to judge the aircraft response expected from that failure. [127, Manual failures: immediate selection, armed conditions and state tabs]
Use random failures for a different objective from a tightly controlled demonstration. The documented model offers categories and rate choices; an individual flight's result is not a reliable estimate of the underlying probability. A long period without an obvious alert can coexist with a modelled failure that was not relevant to the equipment being observed. Retain the selected settings and inspect the actual failed state afterwards. Avoid changing failure rates or repeatedly triggering random events while also trying to determine whether an unrelated hardware or rendering problem is present. [127, Random failures: type, rate, trigger and model description]
Distinguish clearing a manual injected condition from requesting simulated maintenance. The support guide documents manual removal through the failed-item state and a separate maintenance function available on the ground. Use each for its intended exercise purpose, then verify the resulting aircraft state. A cleared injection does not automatically establish that all consequences or configuration changes have been reversed. Before reusing the aircraft, review the appropriate normal preparation, relevant STATUS and any controls changed by the procedure. The completion criterion is a known starting point for the next test. [127, Manual failure removal and ground maintenance] [21, PDF pp. 65–73]
Record enough evidence to distinguish procedure execution from simulator behaviour: build, platform, livery/options, scenario definition, actual trigger, indications, inputs and result. Preserve the original observation before reloading the panel or application. Repeat the same narrow case before changing another variable. For a support report, separate reproducible facts from the explanation you suspect. A useful failure exercise ends with one defensible conclusion about the observed branch, plus any implementation question that remains open. It need not claim that every adjacent failure combination has been validated. [135, Official fault-reporting route] [127, Documented scenario and recovery controls]