Failure Manager

From FlightGear wiki
Revision as of 21:54, 6 February 2014 by Hooray (talk | contribs) (Created page with "{{Template:Non-stable}} {{infobox subsystem <!-- |image =MapStructureDialog.png --> |name =Failure Management |started= 02/2014 |description = Failure Management Framework |...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3).
You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: .

This feature is scheduled for FlightGear (unknown). 10}% completed

If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Failure Management
Started in 02/2014
Description Failure Management Framework
Maintainer(s) galvedro, Necolatis, Hooray
Contributor(s) User:galvvedro (since 01/2014),
Status Under active development as of 02/2014
Topic branches:
fgdata soon

Targeted FlightGear versions: 3.10+

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

  • 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. 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.

Status

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. 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

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.

I have not touched this code yet, but the way I see this working with the general systems modeling framework is something like this:

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.

Related