Assume UAS. Without Airdata, the a/c cannot be autoflown. A new Flight Law is entered, and the PF is the only way to get home (if but temporarily).
Fine. This aircraft has a reputation for being docile, easy fly, and hand flying no problemo. So why no auto flight? Again, no reliable Airdata.
So on the one hand, UAS is not a 'big' deal, but big enough that the a/c cannot do it. Just fly Pitch and Power, one hears.
Fine. Isn't Pitch and Power the easiest (basic) way to fly? So why no auto P/P?
At altitude, in those conditions, PJ2's post describes the hazards of flight re: control damping and authority.
Fine. With turbulence, the a/p has the same airmass to deal with as the Pilots, subject to overcontrol, sensitivity, g and PITCH. So the a/p can do these, but not something so simple as PnP? PnP is what it has been doing since ORARO, with flourishes, and a nice ride?
It is the fundamental duty of autoflight to keep the a/c stable and consistent. What about the challenge of UAS has nothing to do with what an a/p needs to do every day, all day long?
Because, in foreseeble future AP must be kept simple. AP and similar software (it's now software thing) is, compared to many other software systems, quite simple. And if it's going to be certified to fly 400+ pax in crowded skies over densely populated areas it must be kept simple. The key feature of such life critical systems (like AP, FBW controls, dangerous industrial processing controls, like chemical or atomic) is traceability. I.E. each action of the hardware must be clearly traceable to particular instructions in software source code. Then the thing must be proven (often formally, mathematically) that it faightfully represents it's specification.
You want P'n'P of that software, but now how to solve such things like P'n'P while climbing, while descending, while keeping altitude (esp. in reduced vertical separation space), etc. Then if there is UAS AP must be sure it is isolated and is not a sign of some other bigger problem. The human interface would also get more complicated and hard to grasp.
And there is one thing to all that -- the software is deterministic (and in transport planes it will for some significant time into the future). It's meant to always behave the same given the same situation. It has no second thoughts. It has no thoughts at all to begin with. It is preprogrammed for particular behaviours in particular situtations. If situation is not fully understood beforehand the best action is to disconnect the thing. Otherwise it could turn into garbage in - garbage out and you don't want garbage out while moving at Mach 0.8 at FL350.
But there are those two guys (or gals) in front. They're not there to just monitor all that machinery -- with current technology they could better monitor it from some warm place on the ground (as it happens with spacecraft, for example). They're there to handle all the situations which could develop.
Yet the PF has no access to the accelerometers (except by display), and has to deal with natural conditions that don't affect the a/p one bit?
IE Dark, no constant updata, distraction, and ECAMs?
Yes, because those guys and gals are not preprogrammed. AP has no thoughts no understanding. None, nada, nil. All additional conditions like ECAMs etc would add exponentially to complexity of preprogrammed AP.
For once and all, can someone address why it is impossible to consider that the autoflight couldn't (keep up) even with reliable a/s, and UAS may have been the result of insufficient response in the auto regime? (turbulent air mass, discrepant instant baddata?)
UAS could not have been the result of insufficient response. Air which would be 60kts on one side and 180 on the other would simple tear airplane apart. UAS was due to pitot fail not due to turbulence causing reliable but discrepant measurements.