Failure Manager: Difference between revisions

Jump to navigation Jump to search
Line 59: Line 59:
== Implementation Details ==
== Implementation Details ==


The current prototype includes three components:
The current prototype includes three components (i.e. three separate Nasal scripts):


* A Failure Manager Nasal submodule.
# A Nasal submodule that implements the core Failure Manager.
* A Nasal library of utilities for programming the Failure Manager, intended for aircraft authors and GUI dialogs.
# A Nasal library of triggers and actuators for programming the Failure Manager.
* A compatibility script that programs the Failure Manager to emulate previous behavior.
# 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.
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.
;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 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.
;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.
;Trigger: A Trigger represents a condition that makes a given ''FailureMode'' become active. The current prototype 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. 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. The FailureMgr can be enabled and disabled on command.
;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 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. The FailureMgr can be enabled and disabled on command, both from Nasal and the property tree.


== Roadmap ==
== Roadmap ==
60

edits

Navigation menu