Randomly enable the built-in IXEG failures - LUA script

[mmerelles]

VREF is the computed airspeed by the FMC (derivates from gross weigh & flaps selected) for the final approach speed you should cross over the runway threshold for safety, maneuverability and landing distance.

 

VREF + corrections is what you need for landing under normal conditions.

 

Corrections:

-Auto-throttle accuracy +5 knots

-Severe icing +5 knots (for avoiding icing formation on non heated parts)

-If winds are present (winds present means >5 knots) then +half knots of the head steady winds + full knots gusts (note is HEAD wind component, not any wind speed, head steady wind +50%, 45 degree 35%, 90 full crossed 0%, subsequent angles interpolation)

 

Rules for corrections:

1. Resulting corrections can not be greater than +20 knots in any case or landing flap placard -5 knots, whichever is lower (so maximum is VREF +20 or lower)

2. If you already had to apply > +5 knots due to icing or winds, you ignore +5 knots for auto-throttle accuracy.

3. Gust correction has to be maintained till touchdown! corrections due to auto-throttle or steady winds or icing bleed off from the threshold.

4. Tail wind conditions. Set vref + 5 knots. Check maximum aircraft tail wind allowed (typically 15 knots of max tail wind present conditions)

[daemotron]

12 hours ago, mmerelles said:

-If winds are present (winds present means >5 knots) then +half knots of the head steady winds + full knots gusts (note is HEAD wind component, not any wind speed, head steady wind +50%, 45 degree 35%, 90 full crossed 0%, subsequent angles interpolation)

[...]

4. Tail wind conditions. Set vref + 5 knots. Check maximum aircraft tail wind allowed (typically 15 knots of max tail wind present conditions)

Hi, thanks for this comprehensive explanation. What I'm still wondering about is why a steady head wind component has to be balanced - normally, a steady head wind should allow for a slower landing ground speed, preserving tires and brakes. Using this correction partly gives away the advantage of a steady head wind. However, it is not needed to avoid dropping below critical air speed... so why is it done? Courtesy for ATC to avoid snailing on final, or...?

[Litjan]

1 hour ago, daemotron said:

Hi, thanks for this comprehensive explanation. What I'm still wondering about is why a steady head wind component has to be balanced - normally, a steady head wind should allow for a slower landing ground speed, preserving tires and brakes. Using this correction partly gives away the advantage of a steady head wind. However, it is not needed to avoid dropping below critical air speed... so why is it done? Courtesy for ATC to avoid snailing on final, or...?

Simply a safety addition. If there is a lot of wind, chances are it may get gusty/turbulent near the ground (buildings,trees,etc.). More speed also enhances controllability, provides more stall margin/better energy reserve for a go-around and lessens WCA.

Jan

[BaBene]

Hey,

haven't tried your script yet but thanks in advance for your work. I was just wondering why such a script is necessary. Doesn't the default failure system of X-Plane work with the IXEG B733? I never tried it, but it also has the same features I guess. In any case your script seems to be a plug and play solution which is nice, but I'm a fan of utilizing available options as much as possible

Best regards,

Bene

[Tom Stian]

On 10.8.2017 at 4:16 PM, BaBene said:

Hey,

haven't tried your script yet but thanks in advance for your work. I was just wondering why such a script is necessary. Doesn't the default failure system of X-Plane work with the IXEG B733? I never tried it, but it also has the same features I guess. In any case your script seems to be a plug and play solution which is nice, but I'm a fan of utilizing available options as much as possible

Best regards,

Bene

Hello

My script was created for randomly enable the failures that IXEG have made for us (+ some extra failures as engine fire). Check first post for available failures.

The IXEG 737-300 have custom made systems and logics that are not covered by X-Planes failure model.

[BaBene]

Yes I did notice that the X-Plane 11 default failure system does not work. Tried your script and works flawlessly, great work!

[Tom Stian]

27 minutes ago, BaBene said:

Yes I did notice that the X-Plane 11 default failure system does not work. Tried your script and works flawlessly, great work!

Good to hear..:)

If you think you get failures to often, change the  MTBF_hours to 20. That will be the default in next update

 

[BaBene]

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert

Regards,

Bene

[Tom Stian]

9 minutes ago, BaBene said:

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert

Regards,

Bene

There is no history/logging between flights.. So the MTBF is "resetted" everytime you load the aircraft. 

So the MTBF just say something how often the failure can occur.

But maybe some logging between the flights would be something for the next version. Thanks for the idea

 

[mfor]

3 hours ago, BaBene said:

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert

You are confusing MTBF and lifetime expectancy.

The former is about random failures of a device while the latter is about how long a device is expected to last. Those two can be very different.

For example given the 2003 "life table" for the US - a 30-year old has a ~0.1% chance to die in that year - this translates to a MTBF of roughly 1000 years, however even the best wear out long before that - their lifetime expectancy is a mere 49 years. 

So MTBF expresses really just a random chance to fail and thus does not require any life time tracking.

If you were to implement some form of that (e.g tires lasting only X landings), then you'd need indeed some form of air frame state save.

 

In reality, you'd also hope that maintenance is aware of the lifetime expectancy of the various devices and replaces them before that.

So I don't think you would gain much by tracking stuff across flights, unless you want to implement some sort of maintenance simulation, i.e. replace engines after X hours (depending on usage), etc. along with the financial impact to enable some kind of "running an airline" experience.

 

In this simulation MTBF is really just there to give you a better idea of what to expect, i.e. a MTBF of 20h would mean you should expect one failure in 20h of flight (or 5% per hour, or adhering to how it's programmed: 0.0139% per 10s ) regardless of how those 20h are composed. Since it IS random however, you might experience 20 faults in 10 hours or none in 100h.

In reality the MTBFs are much higher of course and vary from system to system as well, while here it's all combined into one.

Edited August 15, 2017 by mfor

[Tom Stian]

3 hours ago, BaBene said:

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert

Regards,

Bene

After some thinking about logging the cycle between flights its giving no sense. Since each cycle have the equal chance to fail

 

[Tom Stian]

Testing out some new tweaks on the MTBF-code.

This is for now just a test, but I tried to smooth out the MTBF a little.

So what I have done is to make the failures less chance to happend if your flight time is below the MTBF you have set, and equal higher chance when you are above the MTBF.

 

What do you think ? 

The result is this

 

OLD:

 

NEW:

 

Edited August 20, 2017 by Tom Stian

[mfor]

Well I'd prefer it to be constant to be honest or even an increased chance at the start, as a failure shortly after takeoff is more uhmm.. intense.

Also unless you set the MTBF really low you're not really going to hit the "above MTBF" phase.

So instead I'd suggest some button (or dataref) that you can hit to cause a random failure in the next 5 or 10 minutes or so. That way you do have a way to trigger a fault quickly (if you are bored or want an interesting takeoff/landing) but still be somewhat surprised by it and don't have to lower the MTBF to ridiculous levels.

[Tom Stian]

22 hours ago, mfor said:

So instead I'd suggest some button (or dataref) that you can hit to cause a random failure in the next 5 or 10 minutes or so. That way you do have a way to trigger a fault quickly (if you are bored or want an interesting takeoff/landing) but still be somewhat surprised by it and don't have to lower the MTBF to ridiculous levels.

Do we need to request a "Red button" from Jan ? 

 

Anyway, something like this ?

If you set the service interphone to "ON" you force the MTBF to 5 minutes in this test. I could maybe increase it to 10min.

[mfor]

         

[Tom Stian]

New version is out.

See first post for updated details about the imminent failure option.

Changelog:

0.112
- Added option 'Imminent Failure'.
- Changed default MTBF from 10 to 20 hours.

[Iain]

Looks great Tom, will test it out next week when I'm back from holiday, got a feeling my flights are going to get much more interesting!

 

[Tom Stian]

Update is available

0.113
- Added failures for landing gear.