Advanced Question Random Failures Logic

[Max-Q]

I am working on a spaceplane project and want to have support for random failures. This is a fairly complicated vehicle (over 11,000 lines of code), with a fully functional VC featuring 6 MFDs, realistic electrical system, etc. The code to actually do the failures is already in place and working, now I just need to trigger the failures randomly. What I was thinking is that if the vehicle is left on orbit longer than it’s intended orbital life the rate of random failures would increase dramatically. I want each system to have a different reliability, like an RCS jet failure is much more likely than a fuel cell failure. I have a MET timer variable.

Here are the failures I support now: (I may add more)
RCS Jet fail
RCS Jet stuck on
Main engine failure
MFD failure
Fuel cell offline

Thoughts/Comments/Advice?

 

[n72.75]

Random isn't always the way to go with stuff like this. If you can, base failure on causes. If you want to simulate wear, it might be better to base it on the accumumated time that the system was used, rather than the overall age of the system.

RCS Jet fail total time that the thruster was on exceeds some value. low temperature or high temperature could also do this
RCS Jet stuck on total number of times the thruster was fired exceeds some value+small random variation
Main engine failure some combination of the above
MFD failure total time on+small random variation
Fuel cell offline too cold, or total number of amp-hours exceeds some value+small random variation

From the standpoint of a user, it should also feel like a system failure, not a bug. By that I mean that I mean users should have a sense that "oh, this broke because it was used too much/was old". If you've ever used any A2A Simulations FSX addons, you'll know what I mean.

 

[jedidia]

I'd recommend the following steps:

• Listen to the orbiter damage simulation flag. Orbiter has actually a global flag to turn on/off damage simulation, but most vessels implementing damage simulation seem to ignore it.
• Provide the possibility to trigger failure on demand in the scenario, for example "in this much sim-time, fail this-and-that". Since orbiter is mostly used scenario/challenge based, and not as a continuous experience, scripted behaviour usually fits the bill better than randomness.
• If you want to provide the option of random failures, make it optional, and make it parametrizable, so players may adjust the probability of failure to suit their needs. You could also provide options like "constant probability" or "increase by 1% per hour of simtime" or things like that. Overall, I do think the most important thing is options.

 

[Max-Q]

Random isn't always the way to go with stuff like this. If you can, base failure on causes. If you want to simulate wear, it might be better to base it on the accumumated time that the system was used, rather than the overall age of the system.

RCS Jet fail total time that the thruster was on exceeds some value. low temperature or high temperature could also do this
RCS Jet stuck on total number of times the thruster was fired exceeds some value+small random variation
Main engine failure some combination of the above
MFD failure total time on+small random variation
Fuel cell offline too cold, or total number of amp-hours exceeds some value+small random variation

I like where you are going with this. I might need to do a combination of both system age and random failures... Gemini 8 thruster wasn't that old!
Age based failures would be a lot easer to implement then totally random, so probably go with that for a start. No one says you can't add features after release...

• Listen to the orbiter damage simulation flag. Orbiter has actually a global flag to turn on/off damage simulation, but most vessels implementing damage simulation seem to ignore it.
• Provide the possibility to trigger failure on demand in the scenario, for example "in this much sim-time, fail this-and-that". Since orbiter is mostly used scenario/challenge based, and not as a continuous experience, scripted behaviour usually fits the bill better than randomness.
• If you want to provide the option of random failures, make it optional, and make it parametrizable, so players may adjust the probability of failure to suit their needs. You could also provide options like "constant probability" or "increase by 1% per hour of simtime" or things like that. Overall, I do think the most important thing is options.

Great ideas! I am already reading the damage flag.

 

[Max-Q]

So I decided to go with a totally scenario based approach. Failures can be "scheduled" for a specific MET, or have a random MET.
Here are the options, all done in the scenario:

• Fail a specific item (MFD 2, Thruster 7, etc) at a specified time
• Fail a specific item at a random time
• Fail an item (any MFD, any thruster, etc) at a specified time
• Fail an item at a random time
• Fail something (anything on the vehicle that could fail) at a specified time
• Fail something at a random time

If the damage flag is set to disabled, no failures will happen even if they are scheduled in the scenario.

I really like the idea of system wear based failures, but that would be a heck of a lot of work, and not quite as flexible. Maybe in the future...

 

[Linguofreak]

Random isn't always the way to go with stuff like this. If you can, base failure on causes. If you want to simulate wear, it might be better to base it on the accumumated time that the system was used, rather than the overall age of the system.

Random failure is best for covering things like defects in manufacturing or mishandling of equipment during maintenance: stuff that happens to the vehicle between scenarios.

An interesting use of scenario-configurable random failures would be an "acceptance trials" or "breaking in" mission: stress-test a new vehicle to force any defects to show themselves, with a high failure rate specified in the scenario file to simulate being early on the bathtub curve.

 

[Max-Q]

Random failure is best for covering things like defects in manufacturing or mishandling of equipment during maintenance

Like that darn thruster on Gemini 8.

An interesting use of scenario-configurable random failures would be an "acceptance trials" or "breaking in" mission: stress-test a new vehicle to force any defects to show themselves, with a high failure rate specified in the scenario file to simulate being early on the bathtub curve.

I think you could do this with my current system, however there is no way to specify a random number of failures. The best that can be done the way I have it set up is to schedule a lot of random failures at random times. If the planned mission is, say a 4 day orbital test flight, you could schedule a number of failures that might happen as late as maybe 10 days in. That way, all the scheduled failures might or might not happen during your 4 day mission.

 

[Urwumpe]

One other option you would have, is assigning a "damage" factor to each component that can fail, and that drops over time, with the rate depending on how it is used, so effects like using a thruster repeatedly at bad temperatures could for example easily shorten the lifetime of a thruster, while never using it at all would only have a small rate of damage.

The big advantage is, that this doesn't get you into problems with probability functions (For example: The chance that something fails in a year is not the sum of it failing during a day), while still having a fairly realistic behaviour for many kinds of failures.

 

[Max-Q]

One other option you would have, is assigning a "damage" factor to each component that can fail, and that drops over time, with the rate depending on how it is used, so effects like using a thruster repeatedly at bad temperatures could for example easily shorten the lifetime of a thruster, while never using it at all would only have a small rate of damage.

I like where you are going with that, however it would be a lot of work to code. I did actually look at usage based failures (see n72.75's post above) but I couldn't decide where/how to store the usage data. External CFG? Scenario? Something else? Each has advantages... Definitely something to look long and hard at later.

 

[Urwumpe]

I like where you are going with that, however it would be a lot of work to code. I did actually look at usage based failures (see n72.75's post above) but I couldn't decide where/how to store the usage data. External CFG? Scenario? Something else? Each has advantages... Definitely something to look long and hard at later.

It was never claimed it is easy. ?

 

[Max-Q]

It was never claimed it is easy. ?

Yeah, I agree. Doing good quality addons sure isn't easy, but a lot of fun...

All I meant by that was that I have a lot of other things I need to do with the project before release, so I think my time would be better focused elsewhere. Later on, I would definitely like to go this direction with the failures logic.

 

[Urwumpe]

Yeah, I agree. Doing good quality addons sure isn't easy, but a lot of fun...

I never thought I would learn THAT much about nuclear reactors... and still keep on going with them, despite only finding ways to fail most of the time without a lot of plot armor. ? Luckily, its Orbiter.

 

[Max-Q]

I never thought I would learn THAT much about nuclear reactors... and still keep on going with them, despite only finding ways to fail most of the time without a lot of plot armor. ? Luckily, its Orbiter.

Huh?

 

[Urwumpe]

Huh?

See here about where it started:

Vessel - Transorbital tug / Hauler

We have quite a few really cool spaceplanes with decent simulations. The XR-series most of all, but also the DG IV, the starliner, and there might be some I've missed. We have nothing comparable for purely orbital operations like transfers. There's the dragonfly, which has electric and...

www.orbiter-forum.com

Im still deep in the systems design for the powerplant section, but at least things go on slowly despite family and working overtime for over a month now.

 

[Max-Q]

Ok, that makes sense now. Glad to hear that project is still alive... The thread went silent for a long time. Maybe someday my spaceplane can launch astronauts to the
transorbital tug!

 

[Urwumpe]

Ok, that makes sense now. Glad to hear that project is still alive... The thread went silent for a long time. Maybe someday my spaceplane can launch astronauts to the
transorbital tug!

It is not dead yet. Just has to fit into one hour time slots instead of 3 hour time slots...

Luckily it is not a real spacecraft, so only I feel bad, when I do something really unrealistic for taking a short cut. New engine model revision is coming.