Failure Manager

From FlightGear wiki
Jump to navigation Jump to search
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear (unknown). 10}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Failure Management
Started in 02/2014
Description Failure Management Framework
Maintainer(s) galvedro, Necolatis, Hooray
Contributor(s) User:galvedro (since 01/2014),
Status Under active development as of 02/2014
Topic branches:
fgdata soon

Targeted FlightGear versions: 3.10+

Objective

Come up with a framework that allows modeling instrument/equipment failures for systems implemented in scripting space and C++, focus on airborne equipment and prepare hooks for also supporting ground equipment failures such as navaids.

Current Situation

All systems and most instruments implemented in the C++ core support basic failure simulation by means of a "serviceable" property. Generally, when this "serviceable" property is set to false, the system will stop updating itself. Some of these systems may support additional, more elaborate types of failures.

Other than this convention of using a "serviceable" property, there is no framework on the C++ side with regards to failure simulation. There is, however, a Nasal submodule that can generate random failures by taking user input from the GUI and controlling the relevant properties.

This approach good, but the main problem is that the supported types of failures are hardcoded both in the Nasal module and the GUI.

Limitations

  • The GUI presents a fixed set of failures that can be simulated, regardless of what systems are actually implemented in the aricraft.
  • Aircrafts can not add their own implemented failures to the set in a clean way.
  • Failures are considered boolean by the framework, i.e. either serviceable or not serviceable. There is no way to express intermediate states of failure.
  • Only random failures based on time or usage cycles are supported.
  • In general, the framework is not extensible.

Proposed design

The proposal is to maintain the current schemma of having a Nasal submodule dedicated to failure simulation, but overhaul it to overcome the limitations stated above. In order to accomplish that, we will raise its status from script to a full fledged Failure Manager.

Here are some desirable traits for the new module:

  • To start with, the failure manager should definitively _not_ implement any particular system failure by default, but provide the logic for managing random events or on demand failure mode activation.
  • It should also provide a subscription interface so aircraft systems can register their own failure modes. After all, only the aircraft "object" is really aware of what systems are being modeled.
  • It should not make any assumptions on how to trigger failure modes (i.e. do not assume a serviceable property). Instead, the Failure Manager should use an opaque interface for setting a "failure level" and leave the details of activation to user scripts.
  • The Failure Manager should also support a flexible set of trigger conditions, so failure modes can be programmed to be fired in different ways, for example at a certain altitude.
  • GUI dialogs should be generated procedurally, based on the set of supported failure modes that has been declared by the aircraft.

Related forum discussions:

Implementation Details

The current prototype implementation includes three components:

  • A Failure Manager Nasal submodule.
  • A Nasal library of utilities for programming the Failure Manager, intended for aircraft authors and GUI dialogs.
  • A compatibility script that programs the Failure Manager to emulate previous behavior.

The design revolves around the following concepts, all of them implemented as Nasal objects.

FailureMode
A failure mode is one way things can go wrong, for example, a blown tire. A given system may implement more than one failure mode. They store a current "failure level" that is a number in the range [0, 100] so non boolean failure states can be supported.
Actuator
Actuators are attached to FailureModes and encapsulate a specific way to activate the failure simulation. They can be simple wrappers that change a property value, but they can also implement more complex operations. By encapsulating the way failure modes are activated, the Failure Manager does not depend on conventions like the "serviceable" property, and can be easily adapted to control systems designed in different ways.
Trigger
A Trigger represents a condition that makes a given failure mode become active. The current prototype supports the following types: altitude, waytpoint proximity, timeout, MTBF (mean time between failures), MCBF (mean cycles between failures). More can be implemented by extending the FailureMgr.Trigger Nasal interface.
FailureMgr
The Failure Manager itself. Keeps a list of supported failure modes that can be added or removed dynamically. It also keeps a list of triggers associated to each mode. While running, it keeps an eye on triggers, and fires the relevant failure modes through their actuators.

Roadmap

  • Replace Nasal/failures.nas with a new module implementing the design proposed above. Wire it to the exising GUI dialogs and ensure backwards compatibility.
  • Generate the GUI dialog procedurally by getting the list of supported failure modes from the Failure Manager.

Related