Failure Manager: Difference between revisions

Jump to navigation Jump to search
no edit summary
m (haha, already supported by Template:Git link :)
No edit summary
Line 8: Line 8:
|started= 02/2014  
|started= 02/2014  
|description = Failure Management Framework
|description = Failure Management Framework
|status = Under active development as of 04/2014
|status = Under active development as of 05/2014
|maintainers  = galvedro, Necolatis, Hooray
|maintainers  = galvedro, Necolatis, Hooray
|developers = [[User:galvedro]] (since 01/2014),
|developers = [[User:galvedro]] (since 01/2014),
Line 69: Line 69:
;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.
;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.


;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 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.
;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 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.
;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.
Line 77: Line 77:
== 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|70}}
# 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|90}}
# Help the Canvas team to develop an abstract Nasal GUI API that can support both Canvas and PUI.
# Help the Canvas team to develop a Nasal GUI API.
# Replace the hardcoded dialogs with dynamic ones using whatever comes out from the step above.
# Replace the hardcoded dialogs with dynamic ones using whatever comes out from the step above.
# Do not load the compatibility layer globally (i.e. by default), but rather load it explicitly from every aircraft (this is gonna be some seriously boring and tedious work).
# Do not load the compatibility layer globally (i.e. by default), but rather load it explicitly from every aircraft (this is gonna be some seriously boring and tedious work).
# 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).
Under consideration
# Generalize the trigger system and make it available as a global service. Might be useful for missions/adventures, AI agents, etc.
# Introduce the concept of ''Wear Models''.


== Related ==
== Related ==
60

edits

Navigation menu