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
Hi Balt,
maybe in the distant future ...
Regards,
|-|ardy
I am in the distant future - time zone wise. So it's not going to be long. Thanks! :-)
That is a very interesting and relevent question given the recent Lion Air accident at Jakarta.
Mike
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...
Remember, Boeing denied the rudder PCU fault for years, until they couldn't any longer...
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.
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.
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)
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
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.)
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?
Or something like this:
http://avherald.com/h?article=4c04438e
Brrrrr.
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.
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.
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
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!
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
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.
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 :-)
You are right -- theoretically if you had a crossing restraint at 17,000 and you had a really low QNH it could put you below the 17,000 as you are setting the QNH, but in this case, I am pretty sure that what happened to the Delta flight behind us was exactly what happened to us because we were given the same speed amendment. I don't remember that the QNH was particularly low that day, if at all.
QuoteI 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.
I think most US carriers will set the bottom altitude for a descend-via STAR, so there is no MCP to back you up in the event VNAV puts you low. And when the FMC is re-calculating a new path, VNAV is out to lunch during that period, so it won't stop you from crossing a fix below the published altitude either.
In our case (and I think Delta's too), we were on the MUSCL 3 arrival between JERMN and MUSCL. We were at 280 knots and told to maintain 250 knots. When we overrode the STAR speeds on the LEGS page with the ATC speed, the VDI disappeared from the ND as the FMC calculated the new path. During that time, we were effectively descending at what we had in VNAV 3/3 (310 in this case), so the FMA went from SPD|VNAV PTH to IDLE|VNAV SPD. Since we had 310 in the VNAV page, the aircraft pitched for 310 and started to go below the path. With 7000' set in the MCP, there was nothing to stop us from crossing MUSCL below 17,000'. At that point, we disconnected the A/P and A/T and leveled off at 17,000'.
(http://www.hoppie.nl/forum/var/muscl-3.jpg)
Quote from: Hardy Heinlin on Wed, 14 Nov 2018 23:41
At least one pilot per aircraft.
Working on that... one pilot aboard, one backup pilot somewhere in a room in a building, attending to 5-10 other flights that are routine and don't need attention except for cruise monitoring (all green? ok) and assistance when requested. It obviously requires full remote control capability. That is an issue. But there are airlines preparing for the principle as of today. Like, changing procedures and acquiring tech that would allow relaxed one-pilot ops in legal emergencies without causing undue stress (call it "legally emergency" just as calling mayday gives you prio, but does not mean you are about to crash, unlike what many media think).
Hoppie
Quote from: emerydc8 on Wed, 14 Nov 2018 23:55
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.
...snip...
So, there's still a long way to go with the automation even under the best of circumstances.
Funnily enough, this is something that if a pilot calculated manually on an E6B, or even with a bit of quick mental math, would not happen. I've seen what you describe happen more times than I can count. To the point where I always verify with an E6B or mental math before T/D to make sure that speed is actually going to be possible.
If the idea behind VNAV is to save fuel, it has failed miserably. There is almost no leg where speed brakes are not required because VNAV will almost always leave you high or fast. Think about that when you get on a passenger flight and see the speedbrakes used as regularly as a primary flight control. As soon as you pull out the boards, you've just lost the fuel you've ostensibly saved using VNAV.
The DC-8 never had VNAV, and it didn't have speedbrakes either, but we were able to operate that fine just by multiplying the altitude we needed to lose by 3 when passing every thousand feet. We didn't need an E6B. For every 50 knots of tailwind you would add ten miles and also add 10 miles to slow from 300 to 250. Worked better than any VNAV I've ever used.
Jon