Disclaimer...
 

Quote from amos2:
Chris Scott, an A320 driver, is one of very few current pilots on this thread who knows what caused this prang... as most current professional pilots do!

Sorry to disappoint you, but I:
(1) retired some years ago;
(2) do not know the cause of this accident (yet);
(3) doubt that "most current professionals do".

In air-transport operations, finding yourself flying with someone with a tendency to arrogance and closed mindsets can be very tricky indeed, as many of us know from our own and others' experiences. In the latter decades of the last century, we made some progress in eliminating those attitudes from airline cockpits. Fortunately, their prevalence in PPRuNe is unlikely to be a threat to air safety.

With no offence intended,
Chris

john_tullamarine:

Your colleague is absolutely right, though I suspect that syseng68k was not so much being optimistic as playing to the layman crowd on this thread. I think if the average person heard from the engineer's point of view that there was any chance of failure in the things we design and build (something generally accepted by engineers) they would never get in a car, work in a tall building or even cross a bridge, let alone board an aircraft! Engineers amongst themselves tend to be more openly realistic, if not pessimistic, about the chances of failure - which is why dyed-in-the-wool engineers tend to make lousy salespeople and managers!

As I've said before, complexity is the enemy of any engineered system, whether that be civil, mechanical, or software. So we're all trying to strike a balance between enough complexity to get the job done versus making it so complex that the odds of Byzantine failure become unacceptable.

With every new generation of technology, engineers are being asked to extend the feature set and improve performance, all the while having to keep an eye on the complexity of the system - in much the same way that aeronautical engineers forty years ago were being asked to design aircraft that were larger, faster, flew further and could carry more cargo and passengers. By and large the solutions worked, but there were always issues that crept out of the woodwork, some of them many years - even a decade or more - after the aircraft entered service.

So, in terms of the software we all use at home everyday, some developers were quite happy to simply cram features in with minimal testing - the most notorious example of this being the state that the Microsoft Office suite had got itself into at the turn of the century. In terms of the real-time safety-critical software used in aviation, that is and has always been verboten. It's not perfect and it never will be, but ultimately this is something common to all aspects of engineering and always has been.

It seems that your coffee displeased you this morning sir ? http://images.ibsrv.net/ibsrv/res/sr...ilies/evil.gif.

There will always be a proportion of noise in an open forum like this, but there are many, other than professional pilots reading this thread who would really like to know what happened.

Enquiring minds want to know etc...

DozyWannabe, #2114:

Interesting report and just confirms what I had seen in terms of rigorous development standards. Interesting set of references at the end as well. From the description, it looks like the code was not running continuously, but was run in a strict sequence with each module running to completion. Started by a system tick clock and probably no rtos. In those days, probably no interrupt driven hardware and no stack usage either. Effectively, a hardware state machine equivalent...

Good stuff and thanks...

Details leaked
 

The German news magazine Der Spiegel claims that they have some inside information from the investigation. Afaict with my knowledge of German the article says:

The first pilot was not in the cockpit at first when the catastrophic events started, but he came running in, shouting instructions.

The speedometer ("Geschwindigkeitsmesser" they write in the article) was iced over (I suppose this is the pitot tube, but aren't there several?)

The plane did a steep pull-up, not clear if this was pilot induced or computer induced

No severe turbulence preceded the catastrophic events

I didn't say that the design of the ADIRU was supposed to isolate signals. I said "the system" didn't isolate the signals. Read my lips. Given your "no fault found" comment, you obviously have little real-world aviation experience, especially with computerised aircraft.

To put your mind at rest, that I was telling the truth, I quote from one of the ATSB reports (Interim factual tab on this page):

As I said: ADIRU 1 sent dud signals to the system (FCCs), which didn't compare dud signals with the two sets of good signals and then made the aircraft uncontrollable - twice.

gums said,

gums is right and I stand corrected! I am not sure which missing brain cell prompted me to say aft stickforce of one lbf/g for the F/A-18. I am far removed from those days. On reflection I think it was closer to 6 lbf.

If you knew where I was coming from, you would understand my extreme embarrassment!

The philosophy underlying all this increased technology is a bit of a challenge to come to terms with isn't it? There are a lot of agendas and factors at play.

1. Accident investigations repeatedly cite human factors (decision making, knowledge, communication, CRM etc) as the most common contributor to the accident. It therefore makes sense to try and reduce this dependence on humans as much as possible. And overall, safety appears to have increased in line with this.

2. At the same time, we have ever-increasing technology allowing us to go down this route. And huge corporations with vested interests in promoting this expensive technology as the way forward.

3. So far, so good. But (and there is always a but), this will inevitably lead to an increasing and insidious disconnect between the pilot and the aircraft. Manual flying skills have likely degraded somewhat. Pilots now may have less situational awareness than in years gone by. There is perhaps a tendency for them to not fully understand all the systems - they know how to operate them under normal conditions sure, but is it possible for them to really understand what is happening when a serious problem suddenly appears out of routine. I accept that all this is a generalization and a gross over-simplification. But even so, is there some truth in this?

4. If these systems fail, then control is thrown back to the pilots. Presumably you would then want the interface between the pilot and the aircraft to be as intuitive as possible, you would want full control authority, and you would want to encourage the pilot to actually fly the aircraft. Is this what the pilot gets however? Or do they get pages of warnings on their displays, information overload, confusion about what is happening, and some unfamiliar degraded flight law?

Overall, the statistics suggest that we are on the right track. But every now and again (and almost at random) the holes will all line up.

Fact Sheet
 

http://i56.tinypic.com/qqo94j.jpg

Just a little reminder, as I stated yesterday, we do not really know much more than three months ago.

Who knows what happened?
 

I am sure Chris and the other professionals on this thread are flattered by the confidence shown but I doubt any of us would claim to 'know' what happened. We don't even 'know' that the aircraft was in extreme turbulence, or that it was involved in a 'super stall', as many seem to believe. Sure, we have a few hunches and most of us would guess that the combination of unreliable airspeed, surprise, an orchestra's worth of warnings, night, and presumably turbulence, could easily overwhelm the best.

For my part I suspect that when the facts of what happened are revealed (not long now) the discussion will then dwell on how well prepared the crew (any crew) were for such an event. Most pilots learn their trade on light aircraft with straight wings, direct controls and modest performance; the transition training to high performance swept wing jets spends most of the time on systems issues, and relatively little (none?) on the subtleties of the new environment in terms of basic handling. I have said in earlier posts, on the previous 447 thread and the A320 crosswind landing event, that the outward similarity of the basic C* control laws on the later Airbuses to earlier conventional controls disguises some even more subtle differences that demand changes in the way pilots react when left in sole charge of the beast. I don't believe adequate consideration is given to these matters in training. I hope people will consider that before condemning the unfortunate AF crew.

Do you really know the fault logic of the ADIRU, Takata? You're saying that faulty airspeed is turns off all air data and AOA outputs from the ADR? I think you have confused ACARS report with reality. The ACARS report is to aid the tech at destination in troubleshooting to the level of the offending LRU, Line Replaceable Unit.

Arinc 700 design was finalized in the late 1970s, and first adopted on a whole airframe in the 767. That design mandates multiple sensors; simple sensors if you will. The Sensors, such as LRRA, ILS receiver, ADR, IRU, etc., put out data words with Sign Status Matrix of Normal, or No Computed Data, or Fail Warn. Filtering and judgements within the sensors are not as extensive as they could be. It is up to the user of this data, FD, AP, display, to filter and compare the data from multiple sensors.

LRUs often contain unrelated functions to minimize the number of LRUs and associated wiring. The VOR receiver, for example, also contains the Marker Beacon receiver, which was a separate LRU prior to Arinc 700.

The LRU is required to put out valid data for each function when it is available. The ADR shutting off its altitude and AOA outputs when it suspects its airspeed input is faulty, is nonsensical, and would be unsafe. AOA is needed more than ever when the airspeed is faulty.

BEA stated that the TCAS Fail on 447 was due to its internal monitoring of altitude. That altitude comes from the transponder. BEA doesn't explain why there wasn't also ATC Fail. There should have been, if the altitude it received from the ADR was faulty.

Yes, my knowledge and experience suggests BEA was mistaken on its assessment of the TCAS Fail.

ARINC 700 doesn't have a VOR Receiver. It has a VOR/ILS Receiver and it makes perfect sense to include a Marker Receiver………it’s hardly ‘unrelated’ as you claim.

amos2:

Presumably you will deign to climb off your (almost insurmountably) high horse and put us, the BEA and Airbus out of our misery? Not only will that save additional "100's of pages" of PPRuNe being wasted, but also a sizable chunk of change being spent poncing around in the middle of the Atlantic pulling pieces of a plane out of the Ocean.

After all Chris has 'admitted' that he does not know the cause of this accident yet, nor does he believe "most current professionals do".

Let's just see how jolly clever you are?

Failure mechanisms
 

Svarin,

And the "coincidence" of this in that critical moment?

The models i imagine are "hardware based" and that was the reason of my question on "system bus wiring fault".

I don´t believe too in a "lightning issue". I asked because always we must consider everything (plausible, of course).

syseng68,
Would be useful to the thread to make a short briefing on "Finite State Machines", for me a fascinating issue.

I hope the main cause(s) of this crash are simple ones, as the leaks are suggesting. But the possibilities (failure mechanisms) we have in "complex Systems" are always a concern for us. (Hardware, Software, Interfaces and "last but no least" the "way the crew" could interact with these "fascinating" Systems during a crisis). Again, there are no ways, in design phase to simulate what could happen in the real world. (The Testability issue).

Such tools exist.
Never seen the animations for the Concorde crash, or the one for the "Hudson glider"?

Hi Bear,

The DC-10 incident at O'Hare was the result of the #1 engine and nacelle separating from the pylon attachment points to the wing causing the engine to flip over top of the wing. In doing so, major hydraulic and electrical lines were either damaged or severed and the wing itself was damaged. The Captain did not know the engine separated (couldn't be seen from the cockpit) and thought it was just an engine failure and therefore followed an emergency engine out procedure. This procedure called for reduction of air speed from the 165 knots they were at to 153 knots. However, the slats on the damaged wing retracted with the loss of hydraulic fluid and pressure as there was no mechanical lock on the DC-10. When the slats retracted, the stall speed on the wing increased from 124 knots to 159 knots, so that the wing went into a full aerodynamic stall. To make matters worse the Captain's slat disagreement and stick shaker (stall warning) was knocked out by the electrical failure and American Airlines had decided not to include a stick shaker on the FO's control column. So with the loss of left wing lift, the aircraft rolled left and went down. This stick shaker arrangement changed after the accident.

I recall there being Simulator studies conducted which basically indicated, more or less, the aircraft was not recoverable once into the wing stall phenomenon.

It was a black day for AA and the FAA when the NTSB released its findings. The change in engine removal along with the pylon using a forklift truck in place of designed rigging to first remove only the engine to save 200 man-hours of labor (cost reduction) was determined to be the root cause, all accomplished under FAA surveillance or non-surveillance depending on how you want to look at it. The same procedure was incorporated at Continental and UAL where the other damaged pylon to wing mounts were found.

Crisis administration
 

slats11, posted:

I think so: QF-32 (VH-OQA) incident may be is a good example. I wonder if even a design team member of the craft could understand what was going on.

And the plane was flying "normally". Suppose if it entered "strange behavior" like JAL 123 (extreme case, i agree)

Perfect!

AF447 perhaps presented to the (2)* crew a "strange behavior". Did they "understand" it timely during the "short" crisis? I repeat: Was possible even to understand? Just CVR probably will answer.

* Considering Capt. Marc "out of the loop". And (if entered) presenting extra "components" to the "crisis administration" resources.

In JAL123 they were able to fly during ~30 minutes.

Real world situations presents "masks" to the real causes". Perform precisely and timely (crisis administration) was transformed in a "highly complex challenge". Even for a pilot with (hypothetically) "the design in his mind". And i suspect is becoming "increasingly difficult" despite the "friendly Systems help".

TurbineD

gums has shown how an asym slats can be survived. AA could have survived.
The Falcon needs only a glance to note the control failure, and I think the Captain could see the slats retracted, though not the engine. Hind sight is somewhat easier then real life. When the roll became unrecoverable was a perceptible event, at which time one could chop #3, and fly at whatever speed necessary to avoid stalling. Better to land straight ahead than upside down with one's foot still planted against the firewall. The tragic outcome was not avoidable. Its reality can still help others fly safer. Nothing is gained by being reluctant to look at what if?

At the risk of taking this too far afield, I'll add the following about the AA DC-10.

I remember following the NTSB proceedings following the accident. A lot of discussion was on forklift leakdown rates. I don't know if it was discussed, as I learned elsewhere that the engine was suspended by the forklift, still attached to the wing at the rear point, when the lunch bell rang. The forklift ran out of gas while they were on break. They heard it crack, like a gunshot.

All DC-10 were delivered with dual stall warning computers, but only one was required for dispatch. Upon delivery of a new DC-10, AA pulled the #2 (right) and put it in stores. That's why there was no stall warning; it was unpowered.

AA engine-out procedure called for the Capt to take over flying, and to fly at two engine centering speed. The FO already had it above that speed, and just may have made it around the circuit.

Small Correction for Turbine D re: DC10 slats.
 

Not that this is relevant to anything, but DC10's slats were cable driven (from a pair of actuators in the CEC that drove a large cable drum with 3/8ths" cable going outboard to the slats... The engine and pylon's departure took out that cable (on that wing)
Bear, once that wing had stalled -which happened very quickly- the only hope for recovery would have been to get it flying again -ie accelerate. There simply wasn't enough altitude for that. It was unrecoverable!

If I understand these latest leaks/rumors is that Capt Dubois travels up to the cockpit after presumably noticing the engines spooling down/noise and/or the AoA/deck angle increasing.

He then presumably instructs his colleagues to go max thrust to prevent an impending stall due to iced pitots misleading the Airbus AT to reduce thrust for overspeed protection.

The max thrust causes a pitching moment, it also makes the Airbus Flight protections kick in for overspeed protection resulting in a hard pitch up. Aggravated stall?

Presumably this is where the AP and AT would give up and say YOUR AIRPLANE.

I think the ORD engine loss is instructive here re: 447. It may not seem so, but the AA pilots were doomed by something irrelevant to their predicament. Procedure. GB puts it well, the FO had a handle on the situation, ostensibly, and if something is flying, and something bad has happened, change is not always good. Many perspectives are served by what if. FO had the power on his side, the control, and had some stasis. Other than SOP, why would the Captain takeover? With 447, the same possibility presents itself. duBois may have been alarmed at a too steep deck angle. With engines perhaps hushed, that would be an eerie concern to have, returning to a cruise cockpit. Perhaps he takes a grok at the panel, hears the cavalry and the lady, some bells, and figures, "Let's have a talk with the lads."

Then-AA policy sounds outdated, a Captain can (should) accept a peaceful "mutiny" when things are stable in the weeds?

3holelover. point taken, and a good one, but see Graybeard. It still occurs to me that the Captain had a foot issue at changeover, (possibly), perhaps even due to "SeatBias". Not command, but an ergonomic thing.

Beyond recreated animations, it might be desirable to take specific FDR data and input it into a FFS to duplicate a particular profile to completion or to some point where thereafter pilot freeplay inputs could be made. Right now my understanding is that all the data parameters required to drive the FFS may not necessarily be available in the FDR. If they were, the specific data point frequency in the FDR may not be the same as the FFS, but the associated computations in an FFS between FDR data points could be interpolated.

The knowledgeable people I’ve talked to say even if all the data necessary to drive the FFS were available, the setup process would still take months.

John, #2155

You can thank your colleague for an excellent set of links. Having
re-read my own post though, I stand by what I said. I'm far from
complacent, but all engineers know that engineering is and always
has been a devil's compromise between speed/functionality, reliability
and cost. Pick any two. Engineered products are designed to meet the
requirements for the particular application and there is rarely any
incentive to gold plate a product, especially if it shows
no improvement in performance, or results in a lower price or cost of
ownership. While big improvements can be made by a more rigorous
specification and process, the law of diminishing returns applies
in terms of cost / benefit. Engineers therefore accept that nothing
in the real world is ever perfect. You can get close and a product
made fit for purpose with a high degree of confidence, by carefull
risk assessment, design, implementation and validation.

What I was trying to illustrate earlier was that avionics software
development has some of, if not the most, rigorous processes applied to
it to tilt the balance in favour of reliability, rather than cost.
Sure, it may never be perfect, but in comparison to consumer or even
industrial application software, the expected reliability should be
orders of magnitude better due to the processes used.

Experience over many projects suggests that code is not usually the main
problem, as coding errors are readily found using code review,
software tools and other techniques. If not, then the development process
is seriously at fault and should be revised. More likely culprits are
inadeqate requirements capture, lack of awareness of possible
problem scenarios and incomplete visualisation of the big picture as it
applies to the problem at hand.

Which leads us to:

> Summary: Five errors is as good as it gets in software with many tens of
> thousands of LOC. This is the order of the first civil aircraft flight
> control systems a quarter-century ago (Airbus A320, 1988, about 60,000
> LOC).

Sorry, but nitpicking, generalisations are dangerous :-). Are we talking
about typo's, or the failure to trap bad args to functions, algorithmic
errors, non compliance with original spec or what ?. That is, some
"errors" have serious effect and some are benign, with no effect at all...

It is real-time control software, after all. (I wasn't involved in the design, but talked to some of the people during development.) Not as simple as you present it, but yes... no relation to PC or Mac software whatsoever.

The problem with generating a viable flight simulator run is that there is no reliable data for the bulk of the AF447 AOA ranges that it appears to have utilized on its way down. Some fairly good data may be obtained regarding this area of the "envelope" from the data record, but it is unlikely that Airbus has anything more than basic wind tunnel data for the A330 at high AOA. I doubt that dependable pitching moment curves exist currently in the deep stall AOA ranges.

Depending on what the AF447 crew did with the controls, we may learn more about that area of the envelope in the next few months than was ever known about it in the operational history of the aircraft. Being a pioneer can be painful.:ooh:

sidestick
 

I have always wondered about the position of the sidestick. This of course is one of the other differences to keep in mind when comparing F-16 type HOTAS and Airbus sidestick. When I first started flying it took me some time to condition my reflexes to operate the stick with my weaker hand even with the stick positioned in my trainer between the legs. It is not a problem anymore after years of training, but I often wondered about the wisdom of having arguably the most important control on the "wrong" side of the captain (given the majority of us are right-handed). It would be interesting to study the "reversion modes" of the human brain much as the a/c in high stress situations when you are asked to make precise controls with your weaker hand.

Hi Khashoggi,
If one follow "DerSpiegelLeaks", Captain was not on the deck when the event "started" after the "pitots iced", hence 0210 as it is said also that it takes a little over four minutes to go down (0214+). But, his voice was heard later shooting orders.
But when?
0210... 0211... 0212... 0213... 0214?
Your proposition is 0210, as he was just behind the door.

Of course, now this will be fully coherent with a sequence starting after those "iced pitots" (Der Spiegel) detected by the system (0210) while the aircraft has switched to ALT2 (prot lost: no overspeed protection, nor autothrust, nor autopilot...); I'm not even mentioning that its airspeed was more likely droping due to ice crystals instead of increasing.
But who care?

Good catch: max thrust (manualy applied as no autothrust) can cause a pitching moment that no ammount of autotrim can stop without any stick impulses from the pilot (as no autopilot). But why --beside the paradoxal use of a lost protection in the first place-- would another "overspeed protection" kicks by now a "pitching up" (instead of reducing thrust --without autothrust!) like above?
Reasons: an "aggravated stall" is where an Airbus would better go --without any help from its pilots-- to make a good drama for Hollywood.

You certainly MUST BE RIGHT: After making all those nasty things, such a nasty aircraft would of course give up the very first things it already gave up (autopilot and autothrust, including its flight envelope protections) when pitot icing was first detected. Go figure!

Good try anyway if your post was not sarcastic.

Is that any different than flying a 727 with the left hand on the control wheel and right hand on the throttles?

I've never flown a/c with control wheel, so can't comment on the ergonomics. Sorry. But presumably, the control wheel is also designed for two handed control unlike the sidestick. I don't intend to take this in stick vs. control wheel or A v B discussion. Just answering the question honestly. I'm more interested in the the effect of pilot stick input vis-a-vis AF447. DFDR data will tell.

DozyWannabee, syseng68k was describing something close to what is done with the shuttle's code. The people writing the software are looking over each other's shoulders looking for faults. The attitude is high fives for everybody if somebody finds a bug, even the person who created the bug. It's one less problem the shuttle will face.

This process is extraordinarily difficult and costly. I suspect what goes on is a subset of the shuttle's process.

And I note a software bug is a bug. A design bug is a bug. All bugs are not one of them. And designers will split the design phase into smaller pieces to decide where the bug happened. All of them will then try to make sure the process makes those bugs harder to find.

Of course, if the customer specifies it wrong and won't budge.... It ain't us software folks, at least. But we still feel line poo when people die.

syseng68k, PLCs are slow, dumb, ladder logic tools that are dumb enough to be 100% predictable in their operation. That is why they are used in industry and safety critical applications. You seem to be telling me that modern aircraft software is falling into feature creep to the point they're using multi-tasking and priorities. Please tell me I'm not putting my life in the metaphorical hands of a potential priority inversion or interrupts left off for too long. And I hope the CPUs and hardware on the flying planes are used at about 10% of their ultimate capacity if they are using multi-tasking.

Dumb silly state machines do have a wonderful place in safety applications.

6 million lines of code in A320 class a/c !!! :eek:

Bear in mind that he's probably talking about the current modern interfaces to the flight management software, not the control logic itself. I wouldn't like to try to implement a touch-screen interface (as used on the A380 and B787) using a finite state machine!

Er, no - 60,000. You're off by a factor of 100 (or two orders of magnitude, depending on how you want to look at it).

Marc Dubois "in CVR" around 01:35Z
 

Hi,

Source: LF

Reminder

At 01:35:43 after a SELCAL test the crew thanked and at :46 (3 seconds later) they no longer replied 4 msgs from ACC-AO. No further SELCAL was attempted.

Note: IIRC just two RMP were operational. For LH and RH seats

Question:

When was made (if) a decision to maintain course . Ie, how long after Capt. Dubois left cockpit? Considering Intol reported at 01:33, M.82 and "location of WX" pattern?

The author claims A320 in 1988 (a quarter century ago) had 60,000 lines of code. And since then the size has increased by two orders of magnitude. So a comparable a/c today has 6 million lines of code. What am I missing?

Edit: I suspect the author may be talking about all software on the a/c. 6 million lines of control automation code seems like a bit much. Nevertheless, when the code is in millions of lines, the control automation is attempting to go well beyond simply assisting the human pilots. If the author is to be believed (and I see no reason not to), at some point in the last quarter century, the roles on the flight deck have reversed.

An Old Fuddy Duddy Agrees
 

Well said Slats. :D Just what an old Fuddy Duddy (according to Amos) like me is concerned about.

*Or*, as I said, we're including in that number things like the new graphical touch-screen interfaces that have cropped up on the most recent generation of jets - completely separate from the control logic, which in real terms hasn't really had to change that much. The post you quote does not make the distinction.

OTOH the post is about mission critical software. I don't see why, say, the inflight entertainment system code needs to be "ultrareliable". If someone in the know can comment on the control logic code metrics in modern a/c, it will be enlightening for the pilot types on the forum.

Sidestick
 

CogSim, quote:
"Chris Scott's notes on sidestick technique are worth a read even for non-FBW pilots."
http://www.pprune.org/tech-log/31609...ml#post3979423
Glad it's of interest, thanks.
Quote:
"When I first started flying it took me some time to condition my reflexes to operate the stick with my weaker hand even with the stick positioned in my trainer between the legs."
Sounds like your "strong" hand was on the throttle?
Quote:
"It is not a problem anymore after years of training, but I often wondered about the wisdom of having arguably the most important control on the "wrong" side of the captain (given the majority of us are right-handed)."
You raise an interesting point. For me, from conversion on the A320, the vast majority of flights were from the L/H seat, and I'm right-handed. My occasional handling sectors in the R/H seat usually started with a tendency to over-rotate on take-off! You don't need a strong hand for the sidestick, but it has to be reasonably dexterous (sorry if that's oxymoronic). Most of us droitiers seem to be able to create and send (cellphone) text messages with our left thumbs...

PJ2, quote:
"...the experience I've had in heavy turbulence is that, even when the elbow and lower arm are planted firmly on the armrest and the sidestick is moved only through the wrist or more likely through just the fingers, it is difficult to not "stir the pot" or more importantly to achieve consistent, steady inputs in one direction, (subtle or large inputs).
The inertia of the arm/hand responds as one would expect in heavy turbulence, and if the stick is gripped firmly instead of being ridden loosely, (while trying to achieve steady inputs in one general direction), the stick inputs will follow the movements of the hand/arm."
My post with the above link was "in the pipeline" when you posted the above. Notwithstanding my contention (see the link) that the fingers/thumb should not be touching the stick except when a movement is required, your point is particularly relevant for the AF447 case, where stick displacements lasting for many seconds are likely to have been necessary.
In normal operations, I guess the longest-time stick displacements are on rotation and flare. These can include roll inputs in turbulence, if a wing-drop persists, or in ground-mode (crosswind). In the simulator, we used to practise the entry to an emergency descent without AP – normally involving roll as well as pitch. However, it was soon decided that, being such a good AP, the exercise would be more realistic and productive with the AP engaged.
So long-term pitch commands, coupled with brief roll demands, are not often practised. And, as you imply, the combination of the two is something not as easy as when you have the stick between your legs, or in the case of a conventional control-wheel/column. Turbulence would exacerbate the difficulty, as you suggest.

Discussing the above reminds me of the matter of whether, in ALT2 Law (pitch-alternate with roll-direct), the A330 still provides bank-angle pitch-compensation (including the case of a descending turn).