Failure Manager: Difference between revisions

Jump to navigation Jump to search

Failure Manager (view source)

Revision as of 19:40, 16 February 2014

1,023 bytes added ,  16 February 2014
no edit summary
m (catsort: Failure Management Framework for FlightGear)
No edit summary
Line 10: Line 10:
|status = Under active development as of 02/2014
|status = Under active development as of 02/2014
|maintainers  = galvedro, Necolatis, Hooray
|maintainers  = galvedro, Necolatis, Hooray
|developers = [[User:galvvedro]] (since 01/2014),
|developers = [[User:galvedro]] (since 01/2014),
|topic-fgdata= soon
|topic-fgdata= soon
}}
}}
Line 17: Line 17:


== Objective ==
== 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).
 
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 ==
== Current Situation ==
Hardcoded instruments generally use the "serviceable" property to enable/disable the update() method (function) - sometimes, there's additional support for certain types of failures.


== Limitations ==
All systems and most instruments supported from the C++ core support basic failure simulation that is controlled by 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.
* The problem is that the dialog is hard-coded, so it wouldn't be reflected there. It would be nice to generate the dialog procedurally instead...
* The GUI dialog is currently static, i.e. it not possible to add failures dynamically - or aircraft-specific failures.


I think you could add a section detailing ideas for future improvements, such as creating the dialog procedurally - galvedro will probably also have a few ideas related to this.
Other than this convention of using a "serviceable" property, there is no other support on the C++ side with regards to failure simulation.
If the two of you should get stuck somewhere related to Nasal/Canvas etc, get in touch with me so that I can provide some help.
Like Philosopher said previously, we will want to create the dialog dynamically and introduce support for galvedro's framework.
For testing purposes, I would prototype things using the c172p or some other well-developed aircraft that has different instruments and systems (electrical, pneumatics, hydraulics).
We had quite a few folks here interested in systems modeling, so having a tutorial on how to use galvedro's system would probably help them use it for these purposes.


Personally, I do like the MTBF-based system, but I would like to see this separated, so that the same failure code could also be used by people to explicitly fail something, i.e. via an instructor console/station - or even just remotely via telnet/httpd.
There is, however, a Nasal submodule that can can generate random failures by taking user input from the GUI and controlling the relevant properties.


== Status ==
=== Limitations ===
galvedro was interested in working out some scripting-space failure system - you may want to get in touch with him. That said, I do agree with Philosopher that the dialog should be turned into a Nasal submodule so that it can be created procedurally.


It definitely is overlapping with galvedro's plans on coming up with a scripting space framework for instrument modeling, and his contributions are remarkably clean and extensible already. I think the only thing missing here are a handful of hooks and of course some automated/procedural dialog generator.
The main problem of the current implementation is that the supported types of failures are hardcoded both in the Nasal module and the GUI. This has several limitations:
I would prefer the latter to be based on abstract classes, so that future updates (once we start ripping out PUI and only use Canvas dialogs) are straightforward.
And I can help with the details here, because we started doing the same thing for the wizard framework.


galvedro actually looked at the failure.nas script a couple of months ago while researching existing functionality for systems modeling. I definitively need to allocate a slot for writing wiki page about the framework I am working on  
* 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.
* Failures are considered boolean by the framework, i.e. 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.


Basically, I think the failure functionality should be a central facility provided by the sim. It should definitively _not_ implement any particular system failure by default, but provide the logic for managing MTBF 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.
== Proposed design ==


I have not touched this code yet, but the way I see this working with the general systems modeling framework is something like this:
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.


1. A system that implements failure modes provides InputPorts for triggering them. On aircraft loading, those ports subscribed to a "Failure Manager" provided by the sim.
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.
 
Related forum discussions:


* http://forum.flightgear.org/viewtopic.php?f=66&t=21855&hilit=failures&start=15#p198524
* http://forum.flightgear.org/viewtopic.php?f=66&t=21855&hilit=failures&start=15#p198524
* http://forum.flightgear.org/viewtopic.php?f=66&t=21855&hilit=failures&start=15#p198529
* http://forum.flightgear.org/viewtopic.php?f=66&t=21855&hilit=failures&start=15#p198529
== Implementation Details ==
The current prototype implementation includes three components:
* A FailureMgr Nasal submodule.
* A Nasal library of useful objects to be used by aircraft authors, the GUI, etc to program the Failure Manager.
* A compatibility script that replicates the former 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 modes. They store a current "failure level" that is a number in the range [0, 100]. So yes, non boolean failure states are 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.
;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.
;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 ==
== Related ==
* [[Aircraft Failure System]]
* [[Aircraft Failure System]]
* [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&hilit= How does serviceable and failures work?]
* [http://forum.flightgear.org/viewtopic.php?f=66&t=21855&hilit= How does serviceable and failures work?]


[[Category:Development projects|Failure Management Framework for FlightGear]]
[[Category:Development projects|Failure Management Framework for FlightGear]]
Galvedro
60

edits

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

Navigation menu