Randomly enable the built-in IXEG failures - LUA script

[Tom Stian]

Just now, Cosmopilot said:

Well, I was lucky (or maxbe not),

IXEG Failure triggered: --------------------------
IXEG Failure triggered: Time: 14:55:23 - 31 May 2017
IXEG Failure triggered: Failure happend after: 12 minutes
IXEG Failure triggered: Failed System: EDP B FAST LEAK
IXEG Failure triggered: Failures left: 1
IXEG Failure triggered: --------------------------
IXEG Failure triggered: --------------------------
IXEG Failure triggered: --------------------------
IXEG Failure triggered: Time: 15:46:27 - 31 May 2017
IXEG Failure triggered: Failure happend after: 63 minutes
IXEG Failure triggered: Failed System: ELECTRIC HYD PUMP B
IXEG Failure triggered: Failures left: 0
IXEG Failure triggered: --------------------------
IXEG Failure triggered: --------------------------

Holly crap. I think I never had a double failure

 

[Tom Stian]

Just a small (but semi important) update

0.110
- Made variables and datarefs unique to avoide conflict with other lua scripts.
- You can now enable or disable the script with FlyWithLua menu. Thanks for this suggestion @Cosmopilot

Edited June 1, 2017 by Tom Stian

[dr_nerdrage]

Thanks for this, Tom. The newfound stability with 1.1 should make using actual failures more fun. Installed, we'll see what happens

[BenAugust]

how do you deal with the "AC/DC eletronic"fails, once AC eletronic 1 fails during my flight.so  a lot of instruments were powered off.shown as the picture,no lights on the transponder pannel(so i have no idea whether it was still work).

And I look for help from my QRH,but nothing find from it,no checklist about eletronic items.

so i want to know how do you deal with the eletronic fails?

many thanks.

[mfor]

You can switch the transponder to feed off of Bus #2 using the 1-2 switch at the bottom. Other than that I don't think you can do much about it in that case.

Also I'm not sure what exactly fails with the "AC Electronic 1" entry. Tried consulting this schematic from http://www.b737.org.uk/ but there are some issues I couldn't explain.

This failure seems to affect the "No1 EL. 115v" box in the lower left, as GWPS and the Captain's altimeter failed with that "AC Eletronic 1" failure. 

Auto-throttle however seemed functional and instead the box on the FO's side went dark, the yaw damper tripped and the No1 Mach warning test failed.

This would indicate a problem in "No1 Elec DC" but from the schematics I can't really tell why those two should be related and whether this a is problem with the failure modeling, the schematic or my understanding of those things

Edited June 4, 2017 by mfor

[mfor]

@Tom Stian Thank you for providing this script and a question/suggestion if I may:

Have you considered using an MTBF number instead of an arbitrary FailFactor, that get's checked twice (against 1..2000 and 1..100) giving it some odd squared characteristic up to a value of 100?

local mtbf_hours = 2.5
local test = math.random (1 , mtbf_hours*360)
if test == 1 then ...

I think this should give you the failure chance for a MBTF of mtbf_hours if called every 10 seconds, which would make it easier to estimate what amount of failures to expect.

 

Edited June 4, 2017 by mfor

[Ben Russell]

 

This was generated with php rand() on Windows which probably calls the same base functions as math.random() for plugins on Windows.

As you can see the distribution isn't very random.

[mfor]

That's why they're called pseudo-random numbers

However calling the function twice (as the script does now) doesn't improve the "randomness".

As long as the function roughly follows the expected distribution it doesn't really matter in this case though, as we're not building a crypto application where true randomness is essential, but just a "random failure" feature where inspiring the feeling of randomness in a human observer is sufficient.

 

Edit: IIRC rand() in php is/was notoriously bad, which is why mt_rand() was introduced and made an alias for rand in php 7.1.

Also Windows actually offers CryptGenRandom if you need a fairly good random generator, which would be overkill in this case though.

Edited June 4, 2017 by mfor

[Tom Stian]

Im no hardcore programmer. Last time I did "serious" programming was with Turbo Pascal 7.0

When I made this script I had some issues with getting the failures in the same order every time. So this is what I came up with.

But your right, my random rutine can be much better. And a good MTBF would be awesome.
I will try out your example for the MTBF and see if I can get it to work in my script.

[mfor]

 

36 minutes ago, Tom Stian said:

Im no hardcore programmer. Last time I did "serious" programming was with Turbo Pascal 7.0

Those were the days

Getting the same failures over and over again would be a sign of using the same random seed for each run (which would produce the same number sequence every time).

Edited June 4, 2017 by mfor

[Tom Stian]

@mfor

I did test out your MTBF rutine and got this result

 

 

The code I tested with was this

local mtbf_hours = 2.5
local counter_WIZVAR = 1

math.randomseed( os.time() )

function failedMTBF()

	test_WIZVAR = math.random (1 , mtbf_hours*360)

	if test_WIZVAR == 1  then 
	print ("Failure after " .. math.floor (( counter_WIZVAR * 10 ) / 60 ) .. " min" .. ""  )
	LogWrite = io.open("MTBF.txt", "a")
	LogWrite:write( math.floor((counter_WIZVAR * 10) / 60) , "\n" )
	LogWrite:flush()
	LogWrite:close()
	
	counter_WIZVAR = 1
	else
	counter_WIZVAR = counter_WIZVAR + 1
	end
			
end

do_every_frame ("failedMTBF()")

 

I think this looked good.. Will do some more testing and probably include it in the next version. 

[mokny]

You could also implement some kind of failure level. Maybe 1,2,3 where 3 triggers the badass failures. 1 triggers the "light" ones and 2 the "medium" ones. This ensures that the user can finish his flight when chosing the lower levels. Sometimes you want to reach your scheduled location :-)

Edited June 4, 2017 by Cosmopilot

[mfor]

Nice testing - looks like it's working as intended.

Probably a good idea to make the test variable local as well (or get rid of it) just in case - forgot that in my suggestion... LUA is weird 

[Tom Stian]

56 minutes ago, Cosmopilot said:

You could also implement some kind of failure level. Maybe 1,2,3 where 3 triggers the badass failures. 1 triggers the "light" ones and 2 the "medium" ones. This ensures that the user can finish his flight when chosing the lower levels. Sometimes you want to reach your scheduled location :-)

Yeah.. That could be a good idea. Thanks for your suggestion.

 

45 minutes ago, mfor said:

Nice testing - looks like it's working as intended.

Probably a good idea to make the test variable local as well (or get rid of it) just in case - forgot that in my suggestion... LUA is weird 

Everything is local in the script. Learned that the hard way

Also did some more MTBF testing, now with 10 hours.

 

I see a tendency that the average is slightly below the MTBF. But could be the low amount of samples maybe.

I have implemented this in my script now, so only some internal testing left 

 

[mfor]

Just now, Tom Stian said:

I see a tendency that the average is slightly below the MTBF. But could be the low amount of samples maybe.

Most likely - I did a quick test on the online lua site (https://www.lua.org/cgi-bin/demo) and with 100 samples I would see numbers from 7.5 to 12.5 hours within a few clicks.

OTOH I don't know how good the lua rand function really is.

[Tom Stian]

On 4.6.2017 at 5:29 PM, Cosmopilot said:

You could also implement some kind of failure level. Maybe 1,2,3 where 3 triggers the badass failures. 1 triggers the "light" ones and 2 the "medium" ones. This ensures that the user can finish his flight when chosing the lower levels. Sometimes you want to reach your scheduled location :-)

I have tried to rank the failures. 

Light	
	BATTERY BUS
	DC BUS 1 and 2
	DC STANDBY BUS
	GENERATOR BUS 1 and 2
	MAIN BUS 1 and 2
	ENGINE HYD PUMP A and B
	ELECTRIC HYD PUMP A and B
	EDP A and B FAST and SLOW LEAK
	SYSTEM A and B Fast and SLOW LEAK
	
Medium	
	AC STANDBY BUS
	AC ELECTRONIC 1 and 2
	DC ELECTRONIC 1 and 2
	ENGINE 1 and 2 FIRE
	ENGINE 1 and 2 FAILURE
	OIL PUMP ENGINE 1 and 2
	
BADASS	
	TRANSFER BUS 1 and 2
	HOT BATTERY BUS
	SWITCHED BATTERY BUS

This is what I came up with so far.

Im a bit unsure about the HOT BATTERY BUS. Not sure really what the failure do.
And if ENGINE FIRE and FAILURES  and OIL PUMP ENGINE 1 and 2 should be on medium. All results in engine stop.

[mokny]

32 minutes ago, Tom Stian said:

Im a bit unsure about the HOT BATTERY BUS. Not sure really what the failure do.
And if ENGINE FIRE and FAILURES  and OIL PUMP ENGINE 1 and 2 should be on medium. All results in engine stop.

Hm, after thinking a little bit about it, the classification into 2 categories would make more sense. Just "Flight can be continued if the failure occures" and "Divert to neares suitable".

[Tom Stian]

On 5.6.2017 at 6:30 PM, Cosmopilot said:

Hm, after thinking a little bit about it, the classification into 2 categories would make more sense. Just "Flight can be continued if the failure occures" and "Divert to neares suitable".

Ill think I go for the 3 failure levels as I ranked above.  so basicly level 1 is "You can continue without major issues", 2 is "You should divert ASAP", 3 is "You should divert ASAP, and good luck"  

[Tom Stian]

New version is up

0.111
- Changed the "Chance of failure" to a MTBF logic.
- Added a new setting, Failure Severity. 1 = Minor failures, 2 = Minor and Major failures, 3 Minor, Major and Critical failures.

[daemotron]

On 26.5.2017 at 6:07 PM, Tom Stian said:

A little story from my last flight.

Had a interesting flight yesterday between LSZH (Zurich) and ESSA (Arlanda) during a VATSIM event, when a failure was triggered.

Its fun to (try) troubleshooting and find out what has happend without looking at the logfile or the failures menu.

[...]

 

Coincidently, Jan once did a video with a Hyd B leakage... (it was a slow leak, but with the same final results )

 

[Tom Stian]

26 minutes ago, daemotron said:

Coincidently, Jan once did a video with a Hyd B leakage... (it was a slow leak, but with the same final results )

 

Nice one.. I have seen all the videoes pre the release. But actually forgot that one.. So I guess you have the answer how it should be done there

One difference was that I was setting the VREF to + 15 knots for the flaps 15 landing. Maybe I did misunderstand the QRH checklist.

[daemotron]

To quote Mike Ray:

Quote

REF - this is the speed for a specific flap configuration (for example Flaps 30 = 30 REF)

TARGET SPEED - this is the REF speed corrected for the wind component. It is the speed that we use to fly the approach. It is equal to: REF + 1/2 the STEADY WIND component + FULL GUST value. The maximum correction for the wind is not to exceed 20 Kts.

TOUCHDOWN SPEED - this is the speed at which we LAND the airplane. That is, after the flare and approaching the runway. It is equal to: REF + the FULL GUST value. The maximum gust correction not to exceed 20 Kts.

So if you're flying without any wind, the correction would be zero => you set the REF speed on the MCP (plus a gust margin).

[Litjan]

11 hours ago, daemotron said:

To quote Mike Ray:

So if you're flying without any wind, the correction would be zero => you set the REF speed on the MCP (plus a gust margin).

Not sure about other airlines but we used a minimum correction of 5 knots. So no wind target is Vref+5.

Cheers Jan

[daemotron]

Hi Jan,

I'm not sure I really understand the story of wind correction. Does it mean you apply min +5 Kts for gust precaution, and more if heavier gusts are announced?

For the gust margin, it seems conceptually obvious to me (to avoid dropping below VREF due to wind gusts). But for the steady wind correction, I'm not really sure what the purpose is - the VREF is indicated airspeed after all (at least I thought so), so why is there such a correction to be applied? Can't be to ensure hitting the right IAS...

Cheers
Jesco

[Tom Stian]

22 minutes ago, daemotron said:

Hi Jan,

I'm not sure I really understand the story of wind correction. Does it mean you apply min +5 Kts for gust precaution, and more if heavier gusts are announced?

For the gust margin, it seems conceptually obvious to me (to avoid dropping below VREF due to wind gusts). But for the steady wind correction, I'm not really sure what the purpose is - the VREF is indicated airspeed after all (at least I thought so), so why is there such a correction to be applied? Can't be to ensure hitting the right IAS...

Cheers
Jesco

Im not sure at all. But I think it I read somewhere that one reason for this is that the autothrottle is certified for +/- 5 knots. So setting speed to VREF +5 will avoid getting below VREF  when autothrottle are engaged.

Edited July 13, 2017 by Tom Stian