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).