60
edits
Failure Manager: Difference between revisions
Jump to navigation
Jump to search
→Proposed improvements
(Switch from {{git link}} to {{fgdata source}} and {{gitorious source}} to provide functional links pointing to the correct infrastructure.) |
|||
| Line 55: | Line 55: | ||
* GUI dialogs should be generated procedurally, based on the set of supported failure modes that has been declared by the aircraft. | * GUI dialogs should be generated procedurally, based on the set of supported failure modes that has been declared by the aircraft. | ||
== Design == | |||
The compat layer makes things rather confusing since, right now, there is an unhealthy mixture between stiff legacy behaviour and latent potential. Lets forget about the compat layer for now, including the PUI-GUI, and lets go over how the system is designed to work. | |||
Without the compat layer, the FailureMgr starts empty: there is no failure registered in the system. The system is designed so that it is the aircraft itself who subscribes all failure modes that it is capable of simulating. This is important: it is not an external system who subscribes stuff, it is the aircraft model itself. So what exactly is a ''failure mode''? A failure mode is something that has a failure/damage/wear level, whatever you want to call it, which makes the aircraft behave differently depending on its state. | |||
* A "broken altimeter" is a failure mode that makes the aircraft incapable of displaying altitude through the instrument. | |||
* A "stuck aileron" is a f.m. that makes the aircraft incapable of moving that aileron. | |||
* A "leaking fuel tank" is a f.m. that makes the aircraft loose fuel at a certain rate. | |||
* "Bug pollution" is a f.m. that makes an aircraft loose aerodynamic performance. | |||
* A "broken wing" is a failure mode that makes an aircraft fly in funky ways. | |||
Now, FlightGear is capable of simulating a wide range of flying machines, not only aircraft. Helicopters, hang-gliders, balloons and space vessels are also part of the hangar, so assumptions should not be made for the system to be equally valid for the whole spectrum of simulated thingies. This is the reason why the FailureMgr expects each model to declare the collection of failure modes supported. | |||
The purpose of the FailureMgr as a core module is to keep all this information together in one place and in a uniform format. This should make it easier for model developers to add support for failure simulation by delegating on the FailureMgr some of the boiler-plate duties, but it should also make it simpler for end users to interact with the system, for example, by being able to disable failure simulation completely from a single place, or by being able to control it from a uniform interface, e.g. Nasal & the property tree. | |||
'''Actuators'''. Actuators do not "decide", actuators "do". An ''Actuator'' is a little script with a defined interface that is used by the FailureMgr to apply a level of failure to the simulation. Every failure mode must have one actuator associated to it for the FailureMgr to do something useful. There are a few implemented in a library, but the Actuator concept is open for aircraft modellers to do whatever they need in order to recreate a failure simulation. Some examples: | |||
* A simple type of actuator can just set a property to a certain value. This is used to "actuate" on systems that simulate failures by means of a "serviceable" property. | |||
* A more complex actuator could tweak certain parameters in the FDM to modify aerodynamic performance. | |||
* An even more complex one could play some sounds, trigger animations and tweak certain performance parameters. | |||
So far, we have a collection of ''failure modes'' and one ''actuator'' for each of them. This is sufficient for having a usable failure simulation, albeit, it has to be manually controlled, which is one of the use cases that should be supported. At this point, the FailureMgr has created a normalized interface in the property tree and also allows you to control the failures at individual level from Nasal, e.g. FailureMgr.set_failure_level(mode_id, level). | |||
The final elements in the mix are '''Triggers'''. Triggers know nothing about FailureModes nor Actuators. They are independent entities whose sole purpose in life is to flag when certain conditions are met. An ''AltitudeTrigger'' flags when certain altitude conditions are met, a ''WaypointTrigger'' flags when the current position is within range of a certain waypoint, and so on. The FailureMgr allows you to attach one Trigger to each FailureMode. You can do it, but you don't have to, it's a feature added for convenience that opens the door for different use cases: | |||
* An instructor could attach a certain trigger to a failure mode for simulating an emergency scenario in defined conditions. | |||
* A user can set up randomized triggers (like MTBF or MCBF) to certain failure modes to spice up a flight. | |||
* An author can use the trigger system to create a realistic failure simulation where failure modes are fired when certain flight conditions are met. | |||
== Implementation Details == | == Implementation Details == | ||