60
edits
Failure Manager: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 55: | Line 55: | ||
* GUI dialogs should be generated procedurally, based on the set of supported failure modes that has been declared by the aircraft. | * GUI dialogs should be generated procedurally, based on the set of supported failure modes that has been declared by the aircraft. | ||
== Structure == | |||
The new module includes three components: | |||
# A Nasal submodule that implements the core Failure Manager ({{fgdata source|Nasal/FailureMgr|pre=$FG_ROOT}}). | |||
# A Nasal library of triggers and actuators for programming the Failure Manager. | |||
# A compatibility script that programs the Failure Manager to emulate previous behavior. Currently loaded by default on startup. | |||
The design revolves around the following concepts, all of them implemented as Nasal objects. | |||
;FailureMode: A failure mode represents 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 represented by a floating point number in the range [0, 1] so non boolean failure states can be supported. | |||
;FailureActuator: 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 could 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 ''FailureMode'' become active. The failures.nas library currently supports the following types: altitude, waytpoint proximity, timeout, MTBF (mean time between failures) and MCBF (mean cycles between failures). More can be easily 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 using a Nasal API. It also offers a Nasal interface for attaching triggers to failure modes (one trigger per failure mode). While enabled, the FailureMgr monitors trigger conditions, and fires the relevant failure modes through their actuators when their trigger becomes active. The FailureMgr can be enabled and disabled on command, both from Nasal and the property tree. | |||
== Design == | == Design == | ||
The | The compatibility layer makes things rather confusing since, right now, there is an unhealthy mixture between stiff legacy behaviour and the new functionality. Lets forget about the compat layer for now, including the PUI-GUI, and lets go over how the system is designed to work. | ||
Without the compat layer, the FailureMgr starts empty: there is no failure registered in the system. The system is designed so that it is the aircraft itself who subscribes all failure modes that it is capable of simulating. This is important: it is not an external system who subscribes stuff, it is the aircraft model itself. So what exactly is a ''failure mode''? A failure mode is something that has a failure/damage/wear level, whatever you want to call it, which makes the aircraft behave differently depending on its state. | Without the compat layer, the FailureMgr starts empty: there is no failure registered in the system. The system is designed so that it is the aircraft itself who subscribes all failure modes that it is capable of simulating. This is important: it is not an external system who subscribes stuff, it is the aircraft model itself. So what exactly is a ''failure mode''? A failure mode is something that has a failure/damage/wear level, whatever you want to call it, which makes the aircraft behave differently depending on its state. | ||
| Line 85: | Line 103: | ||
* A user can set up randomized triggers (like MTBF or MCBF) to certain failure modes to spice up a flight. | * A user can set up randomized triggers (like MTBF or MCBF) to certain failure modes to spice up a flight. | ||
* An author can use the trigger system to create a realistic failure simulation where failure modes are fired when certain flight conditions are met. | * An author can use the trigger system to create a realistic failure simulation where failure modes are fired when certain flight conditions are met. | ||
== Roadmap == | == 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 {{Progressbar|100}} | # Replace Nasal/failures.nas with a new module implementing the design proposed above. Wire it to the exising GUI dialogs and ensure backwards compatibility {{Progressbar|100}} | ||
# Replace the | # Replace the hard-coded dialogues with a dynamic one that reflects the set of supported failure modes. | ||
# Do not load the compatibility layer globally (i.e. by default), but rather | # Design an XML format so aircraft can declare their support for failures from XML instead of programmatically. | ||
# Do not load the compatibility layer globally (i.e. by default), but rather, only for those models that do not have a failures.xml. | |||
# Aircraft authors can now start customizing the failure features for their crafts in a clean way. | # Aircraft authors can now start customizing the failure features for their crafts in a clean way. | ||
# Extend the feature set as needs arise (instructor console, additional triggers, ground equipment failure simulation, etc). | # Extend the feature set as needs arise (instructor console, additional triggers, ground equipment failure simulation, etc). | ||