[hatcravat]

No, they really shouldn't. Autopilots are very good at handling routine, monotonous tasks and very bad at handling unusual or unexpected tasks. See, for example, Air Canada 143, British Airways 38, Air France 447 (admittedly, the crew human crew didn't handle that one so well, but only after the automated system completely gave up), US Air 1549. The BA 38 flight in particular highlights why you really, really want a human crew on board. The pilots of that flight had to over-ride the autopilot, and turned what would have been a complete disaster with everyone killed into a mere total write-off with less than 50 injuries and no fatalities.

[aaronbrethorst]

Wow, I hadn't heard about this before: http://en.wikipedia.org/wiki/British_Airways_Flight_38

[jacquesm]

What impressed me most about that entry is how they managed to trace it back to the root cause (besides, obviously managing to do as well as they did).

[marshallp]

What were the things an autopilot couldn't handle. If more engineering effort were spent, couldn't those also be automatically handled. Plus, couldn't airplanes be remote controlled.

[jacquesm]

> What were the things an autopilot couldn't handle.

Anything unforeseen. Aviation is still a craft, not a science even if a very large number (a huge number, actually) of hours have gone into making it a science. The basic problem here is that you're dealing with chaotic natural systems on one end and machinery at the other. All it takes is a flight of geese or some unusual weather pattern and all your careful programming is worth zip. In situations like that humans tend to do better than computers.

[Daniel_Newby]

That's because the current software intentionally uses very simple cookbook algorithms for flying the plane. Proper software would simulate thousands of scenarios when an anomaly occurs and pick one that gives the least bad result.

The BA 38 example highlights why we need to get humans out of the loop. Good software would have instantly detected the uncommanded loss of power, and immediately started raising the flaps and landing gear. In fact, good software would probably have exercised the control surfaces and engines before descent and diagnosed the problem then, when the aircraft had tens of kilometers of glide remaining.

[olego]

Would you, by any chance, share any links regarding "proper software would simulate thousands of scenarios"? Genuinely interested, how are these kinds of problems solved in real life.

[Daniel_Newby]

I was thinking of automated trial and error using a simulator. Try a bunch of variations in the simulator and pick the one with the best simulated results.

Approaches like that are common for playing board games like chess, for finding clever transfer orbits for spacecraft, etc.

[jcoby]

Really? Because BA 38 shows to me why software has a long way to go before it can replace pilots.

So you want to detect a fail to spool? OK you need to put a sensor on the engine to detect speed. And one on the throttle to detect position. Maybe there is another way to detect fail to spool but this is what we're going with because linear and rotational sensors are pretty common and well sorted.

Now you need to make sure that those sensors are 100% correct before factoring it into your code. So you add another of each sensor. But what if one of those sensors is out of calibration or broken? You need another one to vote for majority. Ok so now you've got 3 sensors on both the throttle and engine shaft.

Nothing really crazy here and pretty common.

Now you've got to build the software to model the engine. Jet engines have a delay in spool times that depends on air speed, how fast you feed in the throttle, how fast the engine is already turning, and other factors I have no clue about.

Now that you've got the model setup you have to add in some hysteresis to keep things nominal and to deal with glitches in readings due to iPods and cosmic radiation and vibration.

And then you have to remodel the whole thing depending on which engine is fitted (there are 3 available for the 777 plus variations). And then you've got to test it.

Now that you've tested that you are able to detect a fail to spool situation you have to generate the model of what to do in various flight modes. And that depends on how much thrust was lost, air speed, altitude, attitude, rate of decent, wing configuration, weight, landing gear configuration, etc.

And then you have to test the flight model. And then you have to update the operational handbook to inform the pilot of what to do if the above fails to work. You also have to amend the inspection and maintenance books to inform the A&P how to test and verify the sensors. You also have to modify the flight recorder to record the sensor positions and software behavior. And you have to modify the sat recording and playback software to handle the new data.

You have to do all of the above because if the fail to spool code activates on a normal approach it can very easily lead to a stall and kill 200+ people. You want to be 99.99999% sure your code is correct.

You've now spent millions of dollars and years of development to replace something a pilot can detect in 3 seconds by simply listening and feeling to what the plane is doing. AND you have created a liability if a bug crops up.

[Daniel_Newby]

Loss of power can be detected by measuring combustor heat output inside the engine, which you need to do anyway to detect flame out and to adjust the engine for best efficiency.

The control software does not need to know about the different models of engine. Each engine should measure its own performance and report the results to the self-fly software.

In the case of BA 38, this was done: the aircraft automatically detected the loss of power. Unfortunately the (dumb) autopilot had used a flight profile that was unsalvageable if loss of power had occurred at that point.

The future of travel is self-controlling vehicles. We have usable self-driving cars today. Airplanes are easier to control than cars, and the aviation market has a huge pent up demand for short hop travel that cannot be met by the heavily crewed business model.