Failure Manager: Difference between revisions

Jump to navigation Jump to search

Failure Manager (view source)

Revision as of 20:22, 16 February 2014

156 bytes added ,  16 February 2014
→‎Implementation Details
Line 61: Line 61:
The current prototype implementation includes three components:
The current prototype implementation includes three components:


* A FailureMgr Nasal submodule.
* A Failure Manager Nasal submodule.
* A Nasal library of useful objects to be used by aircraft authors, the GUI, etc to program the Failure Manager.
* A Nasal library of utilities for programming the Failure Manager, intended for aircraft authors and GUI dialogs.
* A compatibility script that replicates the former behavior.
* 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.
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 modes. They store a current "failure level" that is a number in the range [0, 100]. So yes, non boolean failure states are supported.
;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 the specific way to activate the failure simulation. They can be simple as wrappers that change a property value, but they can also implement be more complex operations. By encapsulating the way failure modes are activated, the Failure Manager does not depend on conventions like the "serviceable" property.
;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 represent a condition that make a given failure mode become active. The current prototype supports the following types: altitude, waytpoint proximity, timeout, mtbf, mcbf. More can be implementing by extending the FailureMgr.Trigger Nasal interface.
;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.
;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.
Galvedro
60

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/67733"

Navigation menu