Gents,

In breaking with the Great tradition of not commenting on these things,  I will actually comment on this one.  This actually took a lot of digging to uncover but the System Schematics for the ASCTU do contain a "Close command override" circuit that will allow the activation of the High Stage valve to allow air to the Thrust Reverser CDU PROVIDED that the Overheat condition is not ACTIVE.  As the Good Dr Watson previously noted,  the overheat switch sends the command to the ASCTU which will close the PRV and HPV valves and latch them closed.   This allows the air in the Engine bleed air ducting to the Overtemp switch to cool (since no air is being provided any longer) and actually reduces the temperature in the circuit without resetting the valves (Due to a Latch circuit in the ASCTU) but it does allow the Close Command Override circuit to Open the High Pressure Valve on Reverse Thrust command and allows the Reverser to operate since the Overheat Switch is not Actively sensing an Overheat condition (since the bleeds were closed on initial sense).   As modeled our Bleed Air Overtemp failure is not a Switch Failure but an actual Bleed Overtemp condition which will after closing the Engine Bleeds (Automatically from the ASCTU) will allow the system to cool and reset.  However if the Bleed is reset the fault will re-occur and lock the valves closed again.  Hopefully this clarifies the issue once and for all.  Any concerns please contact your local Boeing Rep,

As soon as I saw Jet Tech reply, I ran to read the post. I wasn't disappointed lol. Nice work. 

Gents,

I don't think most of you have an appreciation for just how in depth the simulation goes in your PMDG product- and this thread gives you a pretty good indication.  I have mentioned many many times that the entire airplane is simulated at a level of granularity that is very very fine.  You can see the results here in this thread- a thread which I hope has educated a few of you on some new aspects of how this particular system works and is protected from failure.

It is no simple task to create a simulation that is able to accurately match the behavior of a machine as complex as an airliner.  Our team goes to ridiculous lengths to make sure that we provide this level of detail to you.  So much so, that it simply isn't possible for any one member of the team to fully comprehend every aspect of behavior that is exhibited by our simulation- and as such it requires a significant amount of interaction between developers to accurately lay out the behavioral simulation for each of our products- and it takes a number of years to do it to this level of detail.

As an example: A few months ago we had a user write in with a support request indicating that after failing a certain DC bus on the airplane, he was unable to turn a particular item off, even though, as far as he could tell the piece of equipment in question driven by AC power provided by a bus that was still in service.  What he didn't know, was that, while the device itself was indeed AC powered, the switch controlling that device was powered by a single source of DC power and in the configuration of failures he had chosen the switch lost all of it's available sources of DC power, thus taking the switch itself out of action...   A very rare, but very interesting failure mode experienced by one of our customers that was only explainable by advanced knowledge of the airplane.

So please allow me to let you in on a dirty little secret:  Airliners are not terribly sophisticated.  Complex, maybe- but not sophisticated.

I realize that it SEEMS like they are magical marvels- but when you boil it down to the stock, you find that they are largely just a conglomeration of relatively predictable mechanical, physical, control and software logical behaviors bolted together (or sometimes woven, with the new plastic ones!) to create a machine capable of performing it's specific mission effectively and with a high degree of safety.  While not SOPHISTICATED, they are COMPLEX, which is an entirely different realm because it requires that you understand how all of these predictable pieces bolt together and interact with one another to create the final outcome.

This is what we do at PMDG, and this is why it takes us so long to create simulations of individual airplanes.

When you push a switch or pull a lever in a PMDG simulation, there is an entire logical process that engages to simulate the results onboard the actual airplane.  There are mechanical outcomes, monitoring systems, logical processes, indicating systems, power and motive sources to consider- as well as failure modes, positive and negative interactions between systems...  and we simulate darned near all of them.

Most developers wouldn't dare dive in to the detail level that we approach- and most would drown having to do it across a dozen airframe types as we have done with the 747-400, with hundreds of options each changing the airplane slightly, and three different engine types adding exponential levels of complexity to the final product.  And we do all of this while putting an equal amount of time and effort into preserving processor cycles and draw calls within the simulator in order to give you the best performance possible. 

So next time you see someone spouting some nonsense about how our products have good performance because we "don't simulate things in depth" just smile and walk away- because you are being fed a bunch of marketing hogwash.  Or simply come back here and read this thread as a reminder of how things should be when they are done properly.

Yes, that is the level to which we go.  We do it because we genuinely enjoy providing you with the experience and we do so without giving it whizbang brand names, dressing up "accuracy" as an excuse for poor performance or otherwise grand standing bragging points that nobody would be able to verify for veracity in the first place.

Instead, we just focus on on what we think is just plain, old, good simulation.  It is what we do.

 

 

 

 

As always, well spoken RSR.

Thanks, gents.

Of course you could go even deeper than this. Will the reopening of the valves for thrust reverse trigger the overheat again or do the temperature sensors have enough latency to allow reverser deployment and stowing? I'll have to look into the reverser circuits and override circuits to see if the valves reopen only during reverser sleeve operation (or whenever the reversers are deployed).

Is the overheat rpm dependent? Low thrust may reduce bleed air temperatures. e.g. reverse idle may not trip the overheat sensors.

So how does one solve the BLD # OVHT/PRV ? 

10 hours ago, BreezyPointDeparture said:

So how does one solve the BLD # OVHT/PRV ? 

As with any non-normal you simply run the associated QRH. There are two checklists associated with the BLD OVHT/PRV EICAS message in the PMDG QRH (2.8/2.9) -- one will be associated with the GE model and the other I assume associated with the PW model (as the RR engines do not have PRVs and there is no such EICAS message in the RR aircraft - the equivalent is BLD FWSOV OFF).

Either way, it's pretty straightforward: it's ultimately going to direct you to turn off the bleed switch, or on the aircraft with hydraulically actuated reversers (PW?) it is simply going to tell you that you won't have any nacelle anti-ice on the affected engine. Not a lot else you can do, and not in itself too much of an issue as there is no landing distance penalty for one reverser inop (though if you are going to need to descend through an icing layer that might give you pause for thought).

6 hours ago, skelsey said:

 

Posted in error.

13 hours ago, skelsey said:

As with any non-normal you simply run the associated QRH. There are two checklists associated with the BLD OVHT/PRV EICAS message in the PMDG QRH (2.8/2.9) -- one will be associated with the GE model and the other I assume associated with the PW model (as the RR engines do not have PRVs and there is no such EICAS message in the RR aircraft - the equivalent is BLD FWSOV OFF).

Either way, it's pretty straightforward: it's ultimately going to direct you to turn off the bleed switch, or on the aircraft with hydraulically actuated reversers (PW?) it is simply going to tell you that you won't have any nacelle anti-ice on the affected engine. Not a lot else you can do, and not in itself too much of an issue as there is no landing distance penalty for one reverser inop (though if you are going to need to descend through an icing layer that might give you pause for thought).

I did have to descent through an ice layer - I did so anyway, but yes, there were a few pauses for thought during the end of the cruise.

Many thanks - Happy New Year!

Max Castro