News:

Precision Simulator update 10.173 (24 February 2024) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

simulating an obstructed static port

Started by Balt, Sun, 4 Nov 2018 04:35

Balt

Hi Hardy (and all),

the only pitot/static fault simulation I seem to be able to find is an obstructed pitot tube. I think a far more nefarious failure (because it survives a takeoff undetected) is a static port obstruction/failure.

Have I missed this? If not, could that be built into a future release? I think that would make for some very interesting training.

forgot to add: Page 334 in the ops manual suggests that static port failures are not simulated - lending credence to my suspicion that this failure indeed cannot be simulated (yet).

Thanks!

Balt

Hardy Heinlin

Hi Balt,

maybe in the distant future ...


Regards,

|-|ardy

Balt

I am in the distant future - time zone wise. So it's not going to be long. Thanks! :-)

Aonang

That is a very interesting and relevent question given the recent Lion Air accident at Jakarta.

Mike

Balt

Was my agenda that transparent? ;D

Although a tech note released by Boeing today reminds operators of the 737 MAX to remember how to deal with a runaway speed trim systems (STS) due to faulty AOA sensors. There's probably more to the Lion Air story than we think at this point...

United744

Remember, Boeing denied the rudder PCU fault for years, until they couldn't any longer...

Aonang

Quote from: United744 on Sun, 11 Nov 2018 02:07
Remember, Boeing denied the rudder PCU fault for years, until they couldn't any longer...
I agree, if the problem was the result of a defective or blocked pitot and or static vent then it points to a problem with management.
I remember way back to my PPL training days ( a long time ago) that emphasis was given to the issue of blocked pitot and static vents and indeed the PPL exam included questions on the very subject (draw a diagramme showing the basics of an ASI system and know the symptoms of a blocked tube and vent)
On the face of what we have been told to date it would seem that apart from the maintenance issue (or possibly  the lack thereof) the Lion Air crew did not know how to handle a system blockage therefore suggesting that there is a training problem in the airline's management system.

Balt

Well, we do know a lot more after the emergency AD... faulty AOA input to the STS requires actions by pilots against the background of a very busy and noisy cockpit. Confusion abounds if not methodically worked through. I already hear some people cry for a "kill all automatics" switch and revert to basic cables pulling on flight surfaces. When all this appears to show for now is a high likelihood of insufficient or poor training standards.

Jeroen Hoppenbrouwers

Really an industry that needs  to come to terms with reality.

To exaggerate:

Either you highly train pilots and take away low-level automatics, so they are forced to hone their skills each and every flight, and you lose an aircraft when they get themselves just over the edge of what they can handle in bad weather and with bad luck,

Or you automate the low-levels so you don't need to train the pilots so well, at the expense of losing an aircraft when the low-levels fail and the pilots cannot cope.

The latter option is commercially much more attractive.

Hoppie
(I have not made up my mind which extreme I like best -- middle ground obviously is sane, but hey, this world and middle ground seem incompatible)

Hardy Heinlin

The latter option will be the future because the trend in the industrial world is to add robot work and to reduce human work. Not only in aviation. In all job categories, including banking, teaching, driving, building, and so on ...


|-|ardy

Will

In places like the Unites States, a common pathway to being an airline pilot involves working for several thousand hours in entry-level flying jobs where there is no automation. (Pipeline patrol, air ambulance, sightseeing tours, flight instruction, and so on, often in a Cessna 172 with no autopilot and nothing but steam gauges.) I'd like to think that someone with that kind of background would do better, in an extreme situation, than someone who goes from basic flight school right into the right seat of a jumbo.

(I understand that the United States is close to unique in this, though, as those kinds of entry-level aviation jobs don't exist in many places.)
Will /Chicago /USA

emerydc8

#11
QuoteOr you automate the low-levels so you don't need to train the pilots so well, at the expense of losing an aircraft when the low-levels fail and the pilots cannot cope.

There's no way to realistically automate the lower levels. While it may sound like a simple thing to do, there are times when the automation just can't cope with what needs to be done and if you lack the skills to fly the airplane by hand then you shouldn't be in the cockpit to begin with.

Going into KATL last month is a good example. We're getting vectors for the ILS RW08L and we're at our max landing weight. The weather was not good. After the last fix on the arrival we started slowing to 220 to get to flaps 5 and a Delta 777 behind us blows a 250-knot crossing speed restriction on the arrival and we're asked if we can keep our speed up because the controller says, in a worried voice, that he's "eating us up." I reluctantly agreed to do 240 as long as I could in order to get the spacing required. Approach hands us off to tower and we're cleared to land.

At glideslope intercept (CF) we had the gear down, flaps 20 at 200 knots, trying to slow down and go down. Speedbrakes fully deployed and at that weight there was no way we were going to follow the glideslope and decelerate to 170 to get flaps 25. Inside the FF, I had to stay a dot high to get to the flap 25 speed, while the F/D pitch bar was indicating almost full scale nose down. Once we hit 170, we got flaps 25. Full speedbrakes gave us the drag we needed to get back onto the glideslope (luckily there is no limit on speedbrake usage with flaps like the 744).

As we got back to the glideslope between 160 and 150 knots (our target approach speed), I had to do within a few seconds what the automation could probably never do: Go to flaps 30, smoothly retract the spreedbrakes, deal with the huge pitch change and start feeding in thrust to 70% N1 as the flaps went to 30 and we stabilized at 150 knots.

It all worked out in the end, but it made me think there is no way in hell any automation could have dealt with that. Following the F/D in that case would have resulted in a missed approach. As long as there is the real world where things don't work out as planned (they rarely do), no amount of automation is going to be able to cope with it, no matter how much the engineers wish it so. Better not lose the pilot skills because it's going to be a long time -- if ever -- that these airplanes will be fully automated.

I have a friend at the FAA who is heading up the unmanned program and he agrees that the whole program is a farce. Most of it is politically-driven by the industry but he raised a good point when we were discussing my situation: Even if they could get to an acceptable level of automation in the air, can you imagine what an automated ground/taxi operation would look like during rush hour at JFK or ORD?


Jeroen Hoppenbrouwers


Hardy Heinlin

I too think that the jobs of airline pilots won't be completely done by robots till the end of this century. That's probably one the few conventional jobs that will remain for a while.

The actual point, however, is not that you need humans to solve unusual problems; the point is that robots are supposed to make less errors than humans, and so you need less humans to solve human errors. It's the assumption that a robot won't overshoot a 250 speed limit, for example. So this problem which only a human can solve will not even occur. Human ATC is then superfluous as well. (In the very distant future.)

But then there is weather. And malfunctions. That's why I think we still need humans as backups for the next 50 years. At least one pilot per aircraft.

emerydc8

#14
QuoteIt's the assumption that a robot won't overshoot a 250 speed limit, for example.

I can attest that VNAV on every 767 we have regularly overshoots the speed restrictions on STARs (e.g., leaves you 2 miles from the fix at 310 knots when you're supposed to be at 280). Then it leaves you a nice little DRAG REQUIRED message after it's too late. That's probably what happened to Delta.

Going into MSP a few weeks ago, they changed our descent speed on the arrival and as soon as we insert the new speeds it dumps VNAV for almost two minutes while it recomputes the profile. During that time, VNAV goes from SPD | VNAV PTH to IDLE | VNAV SPD and you are basically in a dive-and-drive configuration. So, most of us set the bottom altitude on the MCP when we're cleared to "descend via" the arrival.

While our TRS-80 was recomputing the fixes, we saw that we were going to descend below a 17,000' at-or-above fix, so we disconnected everything and leveled off. A few minutes later, we heard Delta, behind us, confessing that they had gotten low on the STAR and were at 16,500. They asked ATC if they wanted them back up to 17,000. They gave Delta the same clearance they gave us. That's what the automation will do for you. I suspect those guys filed a NASA report on that one.

So, there's still a long way to go with the automation even under the best of circumstances.


torrence

Re: AI running things

A somewhat whimsical take on this dialog is that the proponents of self-driving cars are fond of pointing out that studies show that most accidents are caused by human error - but one of those errors might be turning over total control to AI!

I ran a test the other day, asking Alexa and Siri what the Laws of Robotics were (Issac Asimov's - condensed version "No robot can by action or inaction cause harm to a human, but must obey humans if it does not conflict with the above.").  Both AI's were word-perfect in retrieving the relevant 'laws' - Great.  But when I asked " Are you designed to obey the laws of robotics?", both replied with "I don't know about that" or equivalent.  Disturbing.

Cheers
Torrence 
Cheers
Torrence

emerydc8

Quote
A somewhat whimsical take on this dialog is that the proponents of self-driving cars are fond of pointing out that studies show that most accidents are caused by human error - but one of those errors might be turning over total control to AI!

+1!

Hardy Heinlin

Quotewe were going to descend below a 17,000' at-or-above fix

Could this error be related to an internal FMC calculated transition-level/QNH change-over point which the FMC profile prediction might have ignored for too long after passing FL190? What was the QNH at that time? When something like this happens, does it usually happen near the TL?


Quote"No robot can by action or inaction cause harm to a human, but must obey humans if it does not conflict with the above."

Why did Asimov wrote "but"? With the "if ... not" thereafter, the "but"-addition doesn't look contradictory to me.
What am I missing? :-)


Cheers,

|-|ardy

emerydc8

#18
The VNAV path uses my altimeter and I always set QNH prior to descending out of FL180, so it wasn't a factor. MSP does this just about every time we go in there and I don't know if they realize what it does to the Boeing FMS when they ask you to maintain a different speed not prescribed on a STAR like the MUSCL 3 with multiple speed and altitude points. It totally confuses the FMC for what seems to be an eternity.

That is an interesting point though about the QNH, because if the QNH is really high and I turn the QNH knob up too fast when I set it, it can drop out of VNAV PTH. As I rotate the knob up, it has the effect of putting the aircraft above the predicted path. When it gets more than 150' above the path it goes to VNAV SPD. It's not an issue climbing out but on the descent I try to do it slow enough to stay in PTH.

Hardy Heinlin

Quote from: emerydc8 on Thu, 15 Nov 2018 03:25
The VNAV path uses my altimeter ...

Sure, there are two things: First the VNAV path, secondly your altimeter. Your altimeter is correct. But what I mean is the first thing, the VNAV path. The FMC predicts this path using the data on the FMC FORECAST page (wind, TAI ON alt, TL) etc. The deviation indicator refers to the difference between your altimeter and the FMC's predicted path. If the prediction sets the barometric 17000 constraint at a true geometric 17000 altitude while the QNH is non-ISA, the prediction is incorrect. I don't know the 767 modes, but on the 744, as we know, you get VNAV ALT or VNAV PTH when an altitude is captured. If the MCP ALT lies within ca. 100 feet of the FMC constraint, you get VNAV PTH, not VNAV ALT. So there is an internal FMC logic that decides which VNAV level-flight pitch mode is to be used. I can imagine if this logic fails along with a failure of the path prediction, you won't get VNAV ALT when passing the MCP ALT, and you will level off at an incorrectly predicted profile level-off segment. I have no idea. I'm just explaining the thought that led me to the above question :-)